· Potential issues when using the BizTalk Management Pack in System Center Operations Manager (SCOM)
· Additional Issues
· Available Hotfixes
Issue 1: Expanding BizTalk Group causes the MMC to stop responding.
- Confirm the BizTalk Management Pack is configured correctly. For example, you must specify a Run As Account for the BizTalk Server Monitoring Account and BizTalk Server Discovery Account profiles within SCOM. For the specific details, refer to the BizTalk Server Management Pack Guide available at the link below:
Microsoft BizTalk Server Management Pack for System Center Operations Manager 2007
- The BizTalk Management pack runs a script for every artifact type (send port, receive port, receive location, send port group, orchestration, etc) per host. If there are 50 hosts, then there will be 50 scripts executed against WMI per artifact type. In this scenario, WMI can become overloaded. This querying may keep the BizTalk WMI provider running continuously.
To prevent this, increase the monitoring intervals within SCOM to a higher value. For example, increase the monitoring intervals by picking a random 5-7 minute difference between the scripts:
Script Time (seconds) Adapter Availability Monitor 420 Host Availability Monitor 780 Host Instance Availability Monitor 1140 Orchestration Availability Monitor 1500 Receive Location Availability Monitor 1860 Receive Port Availability Monitor 2220 Send Port Availability Monitor 2580 Send Port Group Availability Monitor 2940
Issue 2: Clicking Refresh or expanding Handlers may return the following error message:
Unable to load adapter handlers for Adapter adapter. (Microsoft.BizTalk.Administration.SnapIn)
Failed to create a CLSID_BiztalkPropertyBagFactory COM component installed with a BizTalk server. A dynamic link library (DLL) initialization routine failed. (WinMgmt)
Resolution: BizTalk Server Administration relies on Windows Management Instrumentation (WMI); more specifically, the BizTalk WMI Provider (BTSWMIProvider.dll).
The BizTalk WMI Provider relies on the ClearAfter property within the WMI root namespace. The default ClearAfter property is 30 seconds (00000000000030.000000:000). If this value has been changed to a larger value, like 500 seconds (00000000000500.000000:000), then this error may be returned.
To set the ClearAfter property, use wbemtest on all BizTalk servers in the group using the steps below:
a) Go to Start, Run and type wbemtest.
b) Click the Connect button and change the Namepace to root. Click Connect.
c) Click the Query button and type: select * from __CacheControl. Click Apply.
d) Double click each item and select the ClearAfter property. Confirm they have the following values:
If any value exceeds the values listed above, click the Edit Property button to change it. Click Save Property. Click Save Object.
e) Restart the Windows Management Instrumentation service.
Issue 3: On the SCOM server, you attempt to stop an orchestration. This may return the following error message:
Error encountered when attempting to stop orchestration processing.
Could not stop orchestration 'Orchestration, Version=220.127.116.11, Culture=neutral, PublicKeyToken=1710edac7131301e'. A database failure occurred due to database connectivity problems. (HRESULT: 80131600).
On the BizTalk Server around the same time as the SCOM server error, the following error message is logged:
Event Type: Error
Event Source: COM+
Event Category: (98)
Event ID: 4791
The COM+ Services DLL (comsvcs.dll) was unable to load because allocation of thread local storage failed.
Process Name: wmiprvse.exe
Error Code = 0x80070008 : Not enough storage is available to process this command.
COM+ Services Internals Information:
File: d:\nt\com\complus\src\comsvcs\comsvcs\comsvcs.cpp, Line: 334
Comsvcs.dll file version: ENU 2001.12.4720.4045
Resolution: To resolve this, follow the steps in the link below to modify the registry key and install the appropriate hotfix:
Troubleshooting Issues When Monitoring BizTalk Server Using System Center Operations Manager 2007
1. Many common tasks like creating a BizTalk host or stopping a send port require specific rights within BizTalk and SQL Server. If you are unable to perform certain functions within BizTalk Administration, you may be missing membership to a BizTalk group. For the specific details of the group or role requirements, visit the following link:
Minimum Security User Rights
2. If SQL Server is configured to listen on a port other than 1433, you may see the following behavior:
· Expanding BizTalk Group takes longer than expected and shows a red circle.
· Expanding Applications takes longer than expected.
· Adding a Resource takes longer than expected.
· Selecting Send Ports takes longer than expected for them to display.
· Expanding All Artifacts shows a red circle.
Resolution: Confirm the SQL Server Browser service is started on all the BizTalk servers in the group. Also on all BizTalk servers in the group, open SQL Server Configuration Manager and create an Alias:
a) Expand SQL Native Client Configuration and select Aliases.
b) Right-click Alias and choose New Alias. Enter the following:
|Alias Name||SQL Server name|
|Port No||TCP port used by SQL Server|
|Server||SQL Server name|
For example, if your SQL Server computer is named MySQL and listening on port 40090, then you would specify the following:
c) Click OK.
Note In this scenario, a Network Monitor capture may show connections to port 1433 continually being reset. This typically occurs if SQL Server is not listening on port 1433. To confirm the SQL Server port, run netstat -ano on the SQL Server. Look for the sqlservr.exe Process ID (PID) in the netstat output to determine the port number.
3. When BizTalk and SQL Server are remote, the network layer could be responsible for some delays. Consider the following:
- If there are any delays or issues with name resolution within DNS, the BizTalk Administration console will be impacted. As a work-around, you can add the SQL Server IP address to the hosts file on all BizTalk servers in the group. The hosts file is located in the following directory:
32-bit server: %systemroot% \system32\drivers\etc
64-bit server: %systemroot% \SysWOW64\drivers\etc
For example, the SQL Server IP address is 18.104.22.168 and the SQL Server name is MySQL. You would add the following to the hosts file:
BizTalk Administration runs as a 32-bit process on a 64-bit server. As a result, the issue described in KB article 973839 may impact the MMC:
973839 32-bit applications do not use the Domain Name System (DNS) cache on a computer that is running an x64-based version of Windows Server 2003 or of Windows XP
If a remote server is specified in a receive location or a send port that is running in a 32-bit host, the DNS query for this server could also be impacted. In this scenario, you can add the remote server to the hosts file. For example, the remote server IP address is 22.214.171.124 and the remote server name is MyServer. You would add the following to the hosts file:
To reset the hosts file back to the default, refer to the following KB article:
972034 How do I reset the hosts file back to the default?
- The Speed & Duplex value on the Network Interface Card (NIC) and additional network layers (e.g. router) can impact performance. If the Speed & Duplex value on the SQL Server NIC is set to 100 MB Half and the Speed & Duplex value on the BizTalk Server NIC is set to 1GB Full, then a delay will probably occur.
Confirm the Speed & Duplex value of all network layers involved (NIC, router, etc) are the same. In the scenario above, configure the SQL Server NIC and the router to 1 GB Full.
To test this scenario, copy/paste a file from the BizTalk Server to a folder on the SQL Server, and vice versa. If this copy process takes awhile, then something in the network layer is causing an issue.
- When connecting to the SQL Server Database Engine, a network protocol must be enabled. For BizTalk, confirm the TCP/IP protocol is enabled.
Choosing a Network Protocol
4. You may get an OutOfMemory exception when working within BizTalk Administration. WMI has a __ProviderHostQuotaConfiguration class that applies to the BizTalk WMI namespace. This class consists of the following properties:
To check the MemoryPerHost value, use wbemtest on all BizTalk servers in the group:
a) Go to Start, Run and type wbemtest.
b) Click the Connect button and change the Namepace to root. Click Connect.
c) Click the Enum Instances… button and enter __ProviderHostQuotaConfiguration. Click OK.
d) Double-click __ProviderHostQuotaConfiguration=@.
e) If the MemoryPerHost value is less than 512 MB (536870912), double-click MemoryPerHost and set the value to 536870912. Click Save Property, click Save Object and Exit.
f) Restart the Windows Management Instrumentation service.
For more information, refer to the links below:
Memory and Handle Quotas in the WMI Provider Service
|2431466||Error message when you run a WMI process in Host Integration Server 2009, in Biztalk Server 2009, or in Biztalk Server 2006 R2: "Unable to load because allocation of thread local storage failed"|
|2028814||FIX: A BizTalk Server Group Hub page takes a long time to refresh after one node goes offline in a BizTalk 2009 & BizTalk Server 2006 R2 host clustering environment|
|981960||FIX: Changes that are made to adapter handlers are not displayed unless you restart BizTalk Server 2009 Administration Console|
|981327||FIX: Resource artifacts may take very long time to load in BizTalk Server 2009 Administration Console|
|977141||FIX: "Tracked message with id: <message id> should not exist in multiple locations" error message when you try to view message details for a tracked message event in BizTalk Server 2009|
|976927||FIX: SQL connections to BizTalk databases are not cleaned up or reused when you use the BizTalkOperations class in BizTalk Server 2006 R2|
|954906||FIX: The number of connections to SQL Server may increase to over 500 when you try to import the same BizTalk application .msi file again in BizTalk Server 2006 R2|
|954814||FIX: Importing an .msi file may take a very long time or you may get a "Timeout expired" error|
|952947||FIX: A user in the BizTalk Server Operators group cannot enable or disable a SQL Server or MSMQ receive location in BizTalk Server 2006 R2|
|952310||FIX: BizTalk Server Administration displays incorrect or blank application name for some orchestration instances after you add a new MessageBox database in BizTalk Server 2006 R2|
|942966||Error message when you try to create a new host in the BizTalk Administration console in BizTalk Server 2006 R2: "The parameter is incorrect (WinMgmt)"|
|942251||Error message when you perform a task in BizTalk Server 2006 R2: "Not Enough storage is available to complete the operation"|
If BizTalk support assistance is needed, please collect the following data while reproducing the issue:
1. Capture a BizTalk trace using the -all option while reproducing the issue. The steps in KB article 835451 provide the specific steps:
835451 How to use the BizTalk Adapter Trace Utility in BizTalk Server
2. Configure the PrivateTrace registry key to enable WMI tracing in the BizTalk Administration console using the steps below:
a) Open the registry and go to the following key:
32-bit server: HKEY_LOCAL_MACHINE\Software\Microsoft\BizTalk Server\3.0\Administration
64-bit server: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\BizTalk Server\3.0\Administration
b) Create a new DWORD value named PrivateTrace and set it to 1.
c) Restart the Windows Management Instrumentation service.
This creates the "c:\BizTalkAdminDbgLog.txt" log file. The log file path and file name cannot be changed.
3. Capture a SQL Server Profiler trace with the following Events:
|Errors and Warnings||All events|
|Security Audit||Audit Login|
Audit Login Failed
4. Capture simultaneous Network Monitor captures on the BizTalk and SQL servers while reproducing the issue. More information on Network Monitor 3 is available at the link below:
933741 Information about Network Monitor 3
Article ID: 2449532 - Last Review: Oct 25, 2012 - Revision: 1