BizTalk Server 2013 R2 BHM toolBizTalk 2013 R2 ships with a new tool called as “BizTalk Health Monitor”. BHM is freely available for all BizTalk 2013 R2 users. More about BHM tool at BizTalkHealthMonitor
This is one common error you might encounter especially if you are into an in-place upgrade activity from BizTalk 2009 or older to BizTalk 2013. There are indeed customers who have run into this even with fresh installations and they do have my consideration here.
Note: For Enterprise Service Bus Took Kit 2.2, this is a recognized bug and has been fixed in CU2 for BizTalk Server 2013. And so no further worries on the ESB front.
Getting back to BizTalk, whilst an in-place upgrade to BizTalk 2013 what most users overlook is the Targeted Framework BizTalk is built against which is .NET 4.0 and a new assembly comes into play. (Keep in mind, older versions use 2.0 based assembly). In a correctly upgraded BizTalk 2013 environment, the SSO (Microsoft.BizTalk.Interop.SSOClient.dll) file version will be 9.0.1865.0 and the .NET version will be 7.0.2300.0 (You could check the version in Registry at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ENTSSO or C:\Program Files\Common Files\Enterprise Single Sign-On). But during the upgrade somehow the SSO assembly fails to update and that causes the system to behave abnormally.
In such a scenario there are 4 things you could try. I have seen articles on the first two, but the third and fourth revealed itself during a recent customer incident I attended to.
Upgrade SSO through Installer
Tweak app pool settings
It could so happen that your IIS upgrade scripts failed to upgrade the application pool which when originally created were set to Classic and targeted against v2.0 framework. BizTalk 2013 being built against the v4.0 framework will fail to load the correct assembly simply because it doesn’t know where to locate the DLL. Alongside, you also need to run aspnet_regiis.exe –I to re-register the asp pages against the updated IIS metabase (v4.0).
Overwrite the WCF Runtime binary DLL.Check the file version of BizTalk.Adapter.Wcf.Runtime.dll in C:\Windows\Assembly. (That’s the WCF-adapter related to binary that references SSOClient.dll). In a failing environment, the file version could be 3.9.469.0 or older and to get it working. We should have 126.96.36.199 version in GAC. So go ahead, copy the newer (188.8.131.52) DLL from a working environment, if you have one and overwrite the older DLL in GAC.
Reexamine your BizTalk Config file
Now this part is fairly intriguing. And this typically comes into play when you attempt to export all your configuration data from BizTalk 2009 to BizTalk 2013 within the BTSNTS*.exe.config files. Most users fail to notice that in due course of updating the configuration file(s), RuntimeActivationPolicy segment gets whacked off. <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0"/> </startup>
This segment is pretty important for your BizTalk services to identify the location where it should look for the assemblies. Effective BizTalk 2010, there are two GACs, one each for .NET 2.0 and 4.0. So if you don’t have these in the config, BizTalk service will look for 4.0 based assemblies in 2.0 GAC, but to no avail. This might cause unpredictable behaviors on your BizTalk servers.
Written BYRajkumar Damodaran
Reviewed ByJainath V R
Microsoft GTSC India