BizTalk Server Logic App Adapter Configurations strange behaviors – #3 Incorrect Sign-In account information

BizTalk Server Logic App Adapter Configurations strange behaviors – #3 Incorrect Sign-In account information

In the last blog post of this series I address a “strange” behavior – maybe strange is not the best work. They are not issues, but definitely, they could have a better user experience – about Sign-in to Azure doesn’t respond.

Today we are going to address a new one, make note that all of them will be related to the Logic App Adapter Azure Authentication (Sign-in to Azure) that you can find on the Endpoint Address Configuration Logic App Details Page.

Incorrect Sign-In account information

In the first blog post, we address the behavior of No user is logged in. Although the lack of this information is not critical to the send port’s correct functioning, I mention that it would be helpful for those who manage the platform to have this information available. 

In this case, let’s assume that after a while (one week or one month later), we go to that send port, and what we see is No user is logged in…

Or even we create the port, and there is an account defined there, let’s say my email account.

If we click on Sign-in to Azure once again, no matter if there is an account display there or not. This will pop up a Log in to your account window and let’s assume:

  • Initial we had authenticate using my account: [email protected]
  • but now we are going to select a different account

Note: sorry for the picture to be in Portuguese ?

After we select the account the password will be asked. You type the password and click begin log in (begin session) and for some reason, a screen asking additional information will be showed to define phone number, email, and security questions.

If you don’t want to define this information, or you are not responsible to perform this configuration and decide to abort this process by click Cancel.

Once you get back to the Logic App Details Page on the BizTalk Server Administration Console the account you try to define to authenticate on Azure to define this port will sow the user you define on the process you just aborted. Despite being strange is not incorrect because in fact, you did authentic on Azure and you are able to see different subscription:

  • The Resource, Logic App and Trigger are gray because the user I used doesn’t have access to that subscription but instead to a different one

Now, if I say: upps!! I made a mistake. Let’s cancel this process and click three times on the cancel button to be sure I discard any change I did. Once we go again to the configuration of that port, what we will see is precisely the previous account being display there!

Again, this is not entirely wrong. What is displaying there is the last user you used to authenticate on Azure… but it is not correct in terms of user experience and it may induce BizTalk Server Administration in error. It was not that user that we used to define the configuration of that port, and neither this account has access to that subscription!

In my opinion, the last user account that successfully defined or made chances on the port should always be displayed.

And the only way to not see that information on that port is to close the Administration Console and open it again. After that at least you will see No user is logged in. This is also not an ideal situation, and it could mislead administrators once again.

The post BizTalk Server Logic App Adapter Configurations strange behaviors – #3 Incorrect Sign-In account information appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server Logic App Adapter Configurations strange behaviors – #2 Sign-in to Azure doesn’t respond

BizTalk Server Logic App Adapter Configurations strange behaviors – #2 Sign-in to Azure doesn’t respond

On the first blog post of this series I address a “strange” behavior – maybe strange is not the best work. They are not issues, but definitely, they could have a better user experience – about No user is logged in.

Today we are going to address a new one, make note that all of them will be related to the Logic App Adapter Azure Authentication (Sign-in to Azure) that you can find on the Endpoint Address Configuration Logic App Details Page

Sign-in to Azure doesn’t respond

I work a lot with several clients in Portugal and outside Portugal. If it was already expected before this COVID-19 pandemic, it is now almost mandatory to work with several VPNs tools and configurations to access their environments.

Some of these VPN configurations allow me to continue to have internet access on my laptop. Others have this annoying behavior to cut access to the internet. In the current world situation with homework that we are, or need to be, online to speak with the team and clients, having no internet access because of a VPN is not a good situation. To avoid this situation or have a better experience, aka not stay offline, I usually install these VPN tools on my Virtual Machines. By doing this strategy, my laptop stays with internet access, but my VM doesn’t have. And it was in one of these situations I found this “strange” behavior.

When I access my Logic App Send Port configuration details on BizTalk Server Administration Console, I try to click several times on the Sign-in to Azure button:

But to my surprise, without any response or action to be presented. It seems that the button was not responding. Sometimes, after a few minutes, a blank pop-up window appears, but it disappears after a minute or so. And this without presenting any error or warning message!

I then realized that I was connected to a VPN, and my machine was without internet access:

Of course, when I turned off the VPN and my VM had access to the internet again, everything started to work as expected.

This is simply a bad user experience implementation. It should at least pop up a warning message that couldn’t connect with Azure or to the internet.

The post BizTalk Server Logic App Adapter Configurations strange behaviors – #2 Sign-in to Azure doesn’t respond appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server Logic App Adapter Configurations strange behaviors – #1 No user is logged in

BizTalk Server Logic App Adapter Configurations strange behaviors – #1 No user is logged in

After working with BizTalk Server Logic App Adapter for a while, I saw some configurations “strange” behaviors – maybe strange is not the best work. They are not issues, but definitely, they could have a better user experience.

All of them are related to the Logic App Adapter Azure Authentication (Sign-in to Azure) that you can find on the Endpoint Address Configuration Logic App Details Page

No user is logged in

Once you configure the Logic App port, in this case, a send port, you need to sign in to Azure. This will pop up a window where you need to enter your account and password (Multi-factor Microsoft Authenticator). After that, you will see an identical configuration to what is shown in the picture below:

  • Account
  • Subscription
  • Resource Group
  • Logic App
  • and Trigger

If you then finish the configuration of the port, everything will be ok, and if you return later to the configurations onto that same send port, you will still be able to see that the account that I used to authenticate was my personal account:

However, if you close the BizTalk Server Administration Console, once you open again and access the configuration of that send port, you still be able to see the following information:

  • Subscription
  • Resource Group
  • Logic App
  • and Trigger

But you no longer be able to identify what account that was used to authenticate on Azure.

Although the lack of this information is not critical, I think it would be helpful for those who manage the platform to have this information available.

The post BizTalk Server Logic App Adapter Configurations strange behaviors – #1 No user is logged in appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Administration Console: Internal error: No transaction is active

BizTalk Administration Console: Internal error: No transaction is active

Once again, it is time to get back to one of my favorite topics, error and warnings, cause, and solutions blog post. This time with a different error regarding one of the most critical components in BizTalk Server: Microsoft Distributed Transaction Coordinator (MSDTC).

Last week a client call me that their production environment was entirely down; nothing was working. I accessed the server and realized that all services were stopped, and we were not able to start them. Long story short, and after I made the common question: “Did someone made any changes on the environment?”, to which I received the usual response: “No, we didn’t”. They had made some changes on the network level blocking port communication between BizTalk Server and SQL Server that supports BizTalk Server.

After I asked them to restore the previous settings and open all communication between BizTalk Server and SQL Server, I could start the BizTalk Services on the machine. However, when I open the BizTalk Server Administration Console to see if everything was working correctly, I got the following error while refreshing the BizTalk Group:

TITLE: BizTalk Server Administration
——————————
The Microsoft Distributed Transaction Coordinator (MSDTC) may not be configured correctly. Ensure that the MSDTC service is running and DTC network access is allowed on the BizTalk, SQL and SSO Master servers. For more information, see “MSDTC Configuration settings required for BizTalk Server” in the BizTalk Server Help.

Internal error: “No transaction is active.” (WinMgmt)
——————————
BUTTONS:
OK
——————————

Cause

Without a doubt that this error is still related to communication restrictions between the BizTalk Server machine and the SQL Server machine that hosts BizTalk Server databases, and especially with MSDTC ports. So I ask them if they disable all restrictions between the machines: from BizTalk to SQL Server and also from SQL Server to BizTalk Server because, for example, RPC ports need to be bi-directional, so if you have firewalls or network port restrictions you need to allow inbound and outbound exclusions for these ports.

And the reason for this error was that they only had disabled network restrictions from BizTalk Server to SQL Server, not the other way.

Solution

Once they disabled all network restrictions from SQL Server to BizTalk Server, this problem was solved.

Note: if you want to implement communication port restrictions between BizTalk Server and SQL Server, be sure that you are following the right procedures and ensuring that the required ports are open on the firewalls so that the BizTalk Server components can communicate with each other.

For more information check my white paper about Installing BizTalk Server 2020 in a Basic Multi-Computer Environment

The post BizTalk Administration Console: Internal error: No transaction is active appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Administration Console Error: The snap-in performed a non-valid operation and has been unloaded. To continue working with this snap-in, restart MMC or try loading the snap-in again

Recently a
client call me reporting a strange behavior on the BizTalk Server Administration
Console. Based on what was reported to me, some updates were applied to the
server at the level of the operating system and that after installation, they
would have performed a controlled restart to the environment. However, after
the environment is back once again online when trying to access the
administrative console, they got the following error:

The snap-in performed a non-valid
operation and has been unloaded. To continue working with this snap-in, restart
MMC or try loading the snap-in again.

Machine generated alternative text:
Eile Action giew Window 
Console Raat 
BizTaIk Server Administration 
BizTaIk Health Monitor 
Event Viewer (Local) 
BizTalk Server Administration Console 
Help 
Snap -in Unavailable 
This snap-in performed a nan-valid operatian and has been unlaaded. Ta continue working with this 
snap-in, restart MMC ar try Iaading the snap-in again. 
Exceptian Type: System.NuIIReferenceExceptian 
Exceptian Message: Object reference nat set ta an instance af an abject. 
Microsoft. BizTaIk.ExceptianMessageBax.BtsExceptianMessageBax.RepracessManagementExceptian(Exceptia 
exceptian, Exceptian newInnerExceptian) 
Microsoft. BizTaIk.ExceptianMessageBax.BtsExceptianMessageBax.RepracessSpecificExceptians(Exceptian 
exceptian, Exceptian newInnerExceptian) 
Microsoft. BizTaIk.ExceptianMessageBax.BtsExceptianMessageBax.RepracessExceptianRecursive(Exceptian 
exceptian) 
at Microsoft.BizTaIk.ExceptianMessageBax.BtsExceptianMessageBax..ctar(Exceptian exceptian, 
ExceptianMessage8ax8uttans buttans, ExceptianMessage8axSymbaI symbal) 
at Microsoft.8izTaIk.SnapIn.Framewark.FramewarkNatificatian.Shaw(Exceptian exceptian, String captian, 
Message8ax8uttans buttans, Message8axIcan ican, Contral staMarshaIIer, IWin32Windaw parent) 
at Microsoft.8izTaIk.Administratian.SnapIn.GraupNade.FuIIRefresh(Object a, ResultsChangedEventArgs e) 
at Microsoft. BizTaIk.Administratian.SnapIn.GraupNade.OnExpand(AsyncStatus status) 
at Microsoft.ManagementCansaIe.NadeSyncManager.PracessRequest(NadeRequestInfa infa, 
IRequestStatus requestStatus) 
at Microsoft. ManagementCansaIe.NamespaceSnapInBase.PracessRequest(Request request) 
at Microsoft.ManagementCansaIeSnapIn.PracessRequest(Request request) 
Micr asaft. ManagementCansaIe. nter nal Snapl nCIient. Microsoft. ManagementCansaIe. nter nal. MessageCIier 
al 
View 
New Window fram Here 
Help

Just for curiosity, BizTalk Health Monitor, worked perfectly fine. And the BizTalk Server engine was working properly also. It was just a matter of UI.

Cause

I don’t really know the specific reasons that cause this problem, and to be honest, being a production environment, the important was to put everything working again. But in a simple way, this error message normally means that the MMC or one of the snap-ins, in this case, BizTalk Server Administration snap-in did not load correctly.

Restarting the machine again, or even restart
the BizTalk Server Administration console doesn’t solve the issue.

Solution

You can troubleshoot fudder this problem and use
a tool like System File Checker to scan and see if you find the root of the
issue and probably the fix.

However, the simple way to solve this is to:

  • Repair
    BizTalk Server installation;

Once you repair the installation, everything
should be working fine again.

Notice: don’t forget to reinstall the last Cumulative
updates.

The post BizTalk Administration Console Error: The snap-in performed a non-valid operation and has been unloaded. To continue working with this snap-in, restart MMC or try loading the snap-in again appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Administration Console Error: The target principal name is incorrect. Cannot generate SSPI context

BizTalk Administration Console Error: The target principal name is incorrect. Cannot generate SSPI context

Without a doubt, today I encountered one of the most bizarre situations in the BizTalk Server Administration Console: The target principal name is incorrect.  Cannot generate SSPI context. (Microsoft SQL Server, Error: 0). And believe me, I been here along time.

Everything
was working fine, and I was normally working on the environment until I try to
refresh the BizTalk Server Administration Console and I got the following
error:

TITLE: BizTalk Server Administration

——————————

Failed to load Group [SQLSERVERNAMEINSTANCE:BizTalkMgmtDb] data providers. (Microsoft.BizTalk.Administration.SnapIn)

For help, click: http://go.microsoft.com/fwlink/?LinkId=47400&ProdName=Microsoft+BizTalk+Server+2016&ProdVer=3.12.774.0&EvtSrc=Microsoft.BizTalk.Administration.SnapIn.Properties.Errors&EvtID=FailedLoadingGroupProviders&EvtChain=Microsoft.BizTalk.Administration.SnapIn.Properties.Errors+%2cFailedLoadingGroupProviders%3bMicrosoft.BizTalk.Administration.SnapIn.Properties.Errors+%2cFailedLoadingGroupProviders%3bMSSQLServer+%2c0

——————————

ADDITIONAL INFORMATION:

Failed to load Group [SQLSERVERNAMEINSTANCE:BizTalkMgmtDb] data providers. (Microsoft.BizTalk.Administration.SnapIn)

For help, click: http://go.microsoft.com/fwlink/?LinkId=47400&ProdName=Microsoft+BizTalk+Server+2016&ProdVer=3.12.774.0&EvtSrc=Microsoft.BizTalk.Administration.SnapIn.Properties.Errors&EvtID=FailedLoadingGroupProviders&EvtChain=Microsoft.BizTalk.Administration.SnapIn.Properties.Errors+%2cFailedLoadingGroupProviders%3bMSSQLServer+%2c0

——————————

Failed to load Group [SQLSERVERNAMEINSTANCE:BizTalkMgmtDb] data providers. (Microsoft.BizTalk.Administration.SnapIn)

For help, click: http://go.microsoft.com/fwlink/?LinkId=47400&ProdName=Microsoft+BizTalk+Server+2016&ProdVer=3.12.774.0&EvtSrc=Microsoft.BizTalk.Administration.SnapIn.Properties.Errors&EvtID=FailedLoadingGroupProviders&EvtChain=MSSQLServer+%2c0

——————————

The target principal name is incorrect.  Cannot generate SSPI context. (Microsoft SQL Server, Error: 0)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=0&LinkId=20476

——————————

BUTTONS:

OK

——————————

But let me give some context because problems
will not happen without any reason. I was normally working with the BizTalk
Server Administration Console until I got a notification that my password would
expire in 5 days and at the same time suggesting for me to change right away
and… I did that for once in my life, I follow the recommendation and do not
wait any longer to change the password.

Once I successfully update my password and remote
access once again to my environment I started getting this issue in the admin
console.

Cause

In a way, unfortunately, after I successfully update my password and remote access once again to my environment, I didn’t go directly to the BizTalk Server administration console. I was doing some configuration in IIS regarding SSL and only after a few minutes I went to the admin console and got this bizarre issue.

I did the basic tasks you normally do in these
situations, nothing related to this particular error but in general:

  • Restart
    the host instances and Enterprise Single sign-on;
  • Check
    if the WMI service is running or Restart WMI service;
  • Close
    the BizTalk Administration Console and open again;
  • Open
    the SQL Server Management Studio and try to connect to the BizTalk SQL Instance

The curious is that all host instances and ESSO
service was working fine, and they were able to restart successfully, and I was
able to connect to the BizTalk SQL Server Instance from the BizTalk Server
machine using SSMS, but none of them resolved the issue with the BizTalk admin
console.

And this error may happen for other different
reasons, but you have to understand my scenario:

  • in one minute, everything was working fine, and now it was failing.
  • And the only difference was I had to change my password.

I do not know to explain better the cause of
the issue in my case, but, in simple words, it was related to some bizarre system
credential cache.

Solution

I was able to fix this issue by simply:

  • logging
    out of the BizTalk Server machine where I was executing the BizTalk Server
    Administration Console
  • and
    logging back in again.

Once I log in back in the BizTalk Server
machine I was able to work normally with the BizTalk Administration Console once
again.

The post BizTalk Administration Console Error: The target principal name is incorrect. Cannot generate SSPI context appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt) fixed by July 30, 2018 Microsoft Security Updates

BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt) fixed by July 30, 2018 Microsoft Security Updates

Last month I wrote a blog post regarding the “An internal failure occurred for unknown reasons (WinMgmt)” error in the BizTalk Server Administration Console caused by the July 10, 2018 Microsoft Security Updates, you can see the entire blog post here: July 10, 2018 Microsoft Security Updates cause errors on the BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt). In which I document a workaround to solve the following problem:

TITLE: BizTalk Server Administration

——————————

Failed to create a BizTalkDBVersion COM component installed with a BizTalk server.

Class not registered (WinMgmt)

——————————

BUTTONS:

OK

——————————

An internal failure occurred for unknown reasons (WinMgmt)

And based on that you wouldn’t be able for example to: restart the host instances from the BizTalk Server Administration console.

Happy to inform you that Microsoft already released a new security update that will fix this problem.

Cause

As official documentation (https://support.microsoft.com/en-gb/help/4345913/access-denied-errors-after-installing-july-2018-security-rollup-update) state: Applications that rely on .NET Framework to initialize a COM component and that run with restricted permissions may fail to start or run correctly after you install the July 2018 Security and Quality Rollup updates for .NET Framework.

Microsoft .NET Framework runtime uses the process token to determine whether the process is running within an elevated context. These system calls can fail if the required process inspection permissions are not present. This causes an “access denied” error.

After you install any of the July 2018 .NET Framework Security Updates, a COM component fails to load because of “access denied,” “class not registered,” or “internal failure occurred for unknown reasons” errors.

So, the cause of these problems was security updates that were released by Microsoft on July 10, 2018.

Solution

On July 30, 2018 Microsoft released new Security Updates https://www.catalog.update.microsoft.com/Search.aspx?q=4346877 that will fix these issues.

An internal failure occurred for unknown reasons (WinMgmt) fixed

To solve my problem, I:

  • Applied/installed all the possible available updates on my BizTalk Server machine;
  • I manually download and installed the Security Update marked in the picture above;

After I restarted my BizTalk Server machine, this problem was fixed.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

July 10, 2018 Microsoft Security Updates cause errors on the BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt)

July 10, 2018 Microsoft Security Updates cause errors on the BizTalk Administration Console: An internal failure occurred for unknown reasons (WinMgmt)

If you follow the BizTalk Server hashtag #msbts on social media like twitter or if you follow BizTalk Server MSDN forum, you will notice one disturbed thread recently: Security Updates released by Microsoft in July 10, 2018 will break you BizTalk Server Administration Console and as a result, you will not be able to access to BizTalk Server “Platform Settings”, getting the following error:

TITLE: BizTalk Server Administration

——————————

Failed to create a BizTalkDBVersion COM component installed with a BizTalk server.

Class not registered (WinMgmt)

——————————

BUTTONS:

OK

——————————

An internal failure occurred for unknown reasons (WinMgmt)

You will not be able for example to: restart the host instances from the BizTalk Server Administration console.

As far as I notice in my clients and in my dev machine, the BizTalk Server engine will still work properly as if nothing happened, it will still be able to receive, process and send all your messages.

Cause

The cause of the problem is still unclear, and Microsoft is still working on how to solve it. And this problem will happen depending in witch SO or BizTalk Server you will have. It has already been registered problems in BizTalk Server 2010, 2013, 2013 R2 and/or BizTalk Server 2016.

What is causing the problem are security updates that were released by Microsoft on July 10, 2018.

Solution

For now, there isn’t a fancy solution, Microsoft is working on a resolution and estimates a solution will be available mid-July.

With that said, the only “solution” or let us call workaround to solve this issue is to uninstall all the “critical” security updates that were installed: in my case, uninstalling the “KB4284833” solved my case.

An internal failure occurred for unknown reasons (WinMgmt) KB4284833

To do that you need to:

  • Press the “Windows key” to open the Start menu and type “Control Panel” and click on “Control Panel” option from the Search window
  • On the “Control Panel” windows, select “Programs” and then “Programs and Features” option.
  • On the “Programs and Features” panel, select “View installed updates” option.

An internal failure occurred for unknown reasons (WinMgmt) uninstall security updates

  • And then you just need to select the update you want to uninstall and then right-click and select “Uninstall”.

In the end, you will need to reboot your machine.

You can always check this forum thread: Microsoft Security Updates cause BizTalk Admin Console errors: An internal failure occurred for unknown reasons (WinMgmt) to check to have an idea what updates you should uninstall depending on your OS version:

  • BizTalk Server 2013 R2: KB4338600 and/or KB4338601
  • BizTalk Server 2010: KB4338602
  • Others: This includes KB4338600, KB4338605, KB4338613, KB4338614, KB4338424, KB4338419

All of them to be checked in your environment and analyzed by your internal teams.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk Server Administration Console: Concurrency Violation encountered while Updating the ReceivePort. The local, cached version of the BizTalk Server group configuration is out of date.

BizTalk Server Administration Console: Concurrency Violation encountered while Updating the ReceivePort. The local, cached version of the BizTalk Server group configuration is out of date.

The funniest part of having an intern working and learning from you, especially for a person like me that really love to write about “Errors and Warnings, Causes and Solutions”, is that they are able to make the funniest and unexpected questions, they will find things that because we are so accustomed to doing the job and to avoiding them, that we do not even realize anymore that they exist and they are there.

So yesterday, after a solution deployment, my intern was complaining that he was always receiving the following error while creating a receive port:

TITLE: BizTalk Server Administration
——————————
Concurrency Violation encountered while Updating the ReceivePort ‘rprtReceive’. The local, cached version of the BizTalk Server group configuration is out of date. You must refresh the BizTalk Server group configuration before making further changes. (Microsoft.BizTalk.ExplorerOM)

For help, click: http://go.microsoft.com/fwlink/?LinkId=47400&ProdName=Microsoft+BizTalk+Server+2016&ProdVer=3.12.774.0&EvtSrc=Microsoft.BizTalk.ExplorerOM.Resources&EvtID=IDS_ERR_OBJECT_CONCURRENCY
——————————
BUTTONS:
OK
—————————–

Cause

While open and navigating in the BizTalk Administration Console you will notice that the first request on expanding the navigation tree or open a BizTalk Server Application or Host Instance will take longer time that further interactions, this because in the first request the Administration Console will query your BizTalk databases for information and after that in cache the result.

So, unless you force a refresh it will use that cache information, nevertheless it will have some kind of mechanism (like a hash) to verify if the cache is updated will the current BizTalk Server Configuration on the database when you try to perform an operation like create or change a Receive Location.

Assuming that you deploy a new version or new artifact to a BizTalk Application, you need to refresh that Application before you perform any kind of operations, otherwise, you will receive this or similar errors.

The reason for this error to happen was that my intern already had the BizTalk Administration Console running and he was already focused (selected) the Application in concern before he went and deploy a new version of the solution from Visual Studio. After he deploy

SOLUTION

This is, in fact, a simple problem to solve:

  • Concurrency Violation encountered while Updating the ReceivePort – Option 1:
    • Close the BizTalk Administration Console and open again (stupid and simple)
  • Concurrency Violation encountered while Updating the ReceivePort – Option 2:
    • Right-click on the BizTalk Application you want to refresh, and then select the “Refresh” option

Concurrency Violation encountered while Updating the ReceivePort: BizTalk Application Refreshed

  • Concurrency Violation encountered while Updating the ReceivePort – Option 3:
    • Select the resource inside your BizTalk Application you want to refresh, for example, “Receive Locations” and press F5

There are several alternatives. The important is to refresh the BizTalk Administration Console if something had changed in your BizTalk Server environment.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

Introducing BTFGui

Today I published one of my little projects on GitHub. It’s called BTFGui and in essence it is just a simple GUI around the BizTalkFactory Management Automation (SDK) to do some basic BizTalk Administration.

Currently it has the following features:

  • Stop/Restart HostInstances
  • Stop/Restart Applications
  • Remote Applications
  • Export Application Bindings
  • Terminate Suspended Instances

You can find It here on GitHub.

The main reason why I put this little thing together is simple: the BizTalk Administration Console can be very slow and time wasting if you just want to restart a hostinstance or export a binding. Therefore I created BTFGui and I can tell you that it saves me a lot of time when developing on my local BizTalk Server instance.