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:
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.
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.
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.
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.
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.
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.
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.
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.
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
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
——————————
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.
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.
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
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 – 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
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.
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.