When the BizTalk Management Pack for Operations Manager does… well, nothing.
The following article applies to the BizTalk 2009, BizTalk 2010 and BizTalk 2013 management packs, as well as SCOM 2007 R2, SCOM 2012 and SCOM 2012 R2. In the interest of generically referring to all versions of the management pack, and of Operations Manager, I will refer to the management pack as the BizTalk management pack regardless of version, and to Operations Manager as SCOM or OM regardless of version, since all information here applies to all versions mentioned above.
So you have imported the BizTalk management pack, and are eagerly awaiting the results when… well, nothing happens. When you go to the various BizTalk views, nothing shows up. No BizTalk groups were discovered, no send ports, receive locations, orchestrations, hosts or host instances show up at all. What is going on?
Fortunately I have had a great deal of experience with this management pack, and with both Operations Manager and BizTalk. In my many travels I have learned that issues with the discovery of BizTalk artifacts generally fall into one of three categories, listed here in order of likelihood:
- Problems with Run As Accounts
- Issues with the Agent Proxy setting
- Discovery execution machine.
Let's take a look at each of the three causes, and how to properly resolve them so as to ensure the BizTalk discoveries run, and run successfully.
Note: For the purposes of this discussion we will assume that all BizTalk servers in the group, and all servers hosting BizTalk components have been provisioned with appropriate SCOM agents to monitor the servers. The BizTalk Management Pack does not support agentless monitoring, so an agent installed on every role server is required.
Problems with Run-As Accounts
Operations Manager monitors computers through the use of a local monitoring service known as the SCOM Agent or the Health Service. That service runs under the identity of the Default Run-As Account, which is typically Local System. The Default Run-As Account, whatever it is, probably has no privileges in BizTalk, so when SCOM tries to run discovery workflow against the BizTalk databases, and servers, the discovery will fail to get the information it is looking for. The Default Run-As Account, however, does have all the necessary rights and privileges to monitor the operating system, and the core components of the server. So what we need to do is to provide SCOM with a different set of credentials to use whenever executing discoveries or monitoring of BizTalk components.
The first step in doing so is to identify or create an account which holds all the necessary privileges for the monitoring of BizTalk Server. I like to create a brand new account, rather than using an existing service account, so as to keep separation between actions SCOM is performing and actions performed by say a BizTalk Admin. To that end, we go to Active Directory Users and Computers, and provision a new domain service account. For the purposes of this discussion let's call it the BizTalkMonitoringUser, as seen here:
BizTalk monitoring requires very specific privileges, so the next step is to make sure the account we created is member of the right groups. The BizTalkMonitoringUser account we created must:
- Be a member of each monitored server's local Built-in Administrators group
- Be a member of the SSO Administrators group
- Be a member of the SSO Affiliate Administrators group
- Be a member of the BizTalk Administrators group
- Be a member of the BizTalk Application groups
- Be a member of the BizTalk Operators group
- Have the SysAdmin role on the SQL instance or instances where BizTalk databases and jobs are located.
Here is how my BizTalkMonitoringUser is provisioned:
And on the SQL Server we have:
Once the account has these privileges, we need to go tell Operations Manager about the account, including the user name and password, the distribution of the credentials, and which workflows the account should be associated with. The management pack guide has a section on how to do this, but some visual help might be better.
In the Operations Manager admin console go to the Administration workspace, and click on the Accounts node under Run As Configuration. Right click on Accounts and select Create Run As Account. From the Run As Account Type drop down make sure Windows is selected, as the account we are using is a Windows account. Give the account a name, and a description, and your configuration should look something like this:
Click the Next button and type in the user name and password, making sure to configure the right domain option:
Click the Next button to navigate to the Distribution Security screen. Here we tell Operations Manager how "loose" to be with the credentials we give it. Less secure will distribute the credentials to all managed computers, while More secure will send the credentials only to the servers the administrator selects. The More secure option may be a little bit more work, but it is well worth the effort, so let's choose More secure, and click Create.
At this point SCOM know about the account, but we must arrange for its proper distribution and then associate it with the workflows in the BizTalk Management Pack. To arrange the distribution, just right-click on the Run-As account you just created and select Properties as shown below.
From the properties dialog box, click on the Distribution tab, and click the Add button. In the Computer Search box, search for and find each and every server hosting BizTalk components, including all servers in the BizTalk group, servers with portal components, HTTP receive locations, SharePoint adapter servers, and the servers hosting SQL instances which have BizTalk related databases. Ensure each server is in the Selected Objects list and click OK. The list in my environment looks like this:
Next we need to associate the account, with SCOM workflows from the BizTalk Management Pack. To do this we have to associate the Run-As account with Run-As Profiles. When the BizTalk management pack is imported, two profiles are created out of the box under Run As Configuration -> Profiles. The two profiles created are:
We must associate the account we created with each of these two profiles. We will start by right-clicking on BizTalk Server Discovery Account, and selecting Properties, then selecting the Run As Accounts tab on the left. Click the Add button and from the Run As account dropdown box select the BizTalk Monitoring Account we created above. You may leave the radio button selected for All Targeted Objects, unless you have a need to monitor multiple BizTalk environments using different credentials (a topic for another day).
Click OK and then Save, to complete the configuration of the BizTalk Server Discovery Account Run-As Profile. Perform the same steps, to configure the same account to be used by the BizTalk Server Monitoring Account Run As Profile. When both profiles have been configured to use the Run As account with the appropriate privileges, you are done with this part of the configuration.
Enable Agent Proxy
Operations Manager, as it turns out, has a security constraint enabled by default. A SCOM agent running on a server is, by default, only allowed to submit information to SCOM about objects contained or owned, or hosted by the server where the agent is running. If the agent submits data (discovery or monitoring data) to a management server about objects it doesn't own then Operations Manager simply drops it.
This is a problem for some technologies. Think Active Directory, for example. Which domain controller hosts or owns or contains the domain? Clearly none of them. A domain is an entity larger than any one domain controller, and no one domain controller owns it. So for concepts such as these, we have to tell Operations Manager to disregard its normal security constraint. We have to tell Operations Manager to allow the agent on a server to act as a proxy and submit information about objects on computers other than where the agent is running.
Well, this applies to BizTalk, since no one BizTalk server owns the BizTalk group/deployment. A BizTalk Host is a group-wide execution framework, not owned by any one machine in the group. Sure, instances of a host are local to a machine, but not the host itself. The same goes for a Receive Port or Orchestration. If we do not allow the agent to submit information about objects its server doesn't own, you will see errors such as this in the Operations Manager event log:
Event Type: Error
Event Source: Health Service Modules
Event Category: None
Event ID: 10801Discovery data couldn't be inserted to the database. This could have happened because of one of the following reasons:
- Discovery data is stale. The discovery data is generated by an MP recently deleted.
- Database connectivity problems or database running out of space.
- Discovery data received is not valid.
The following details should help to further diagnose:
DiscoveryId: 8123404a-b439-49d8-1234-6c8c22d12345
HealthServiceId: 4de5edba-368e-5de2-c831-d35fec214cc8
Health service ( BTSLIT.Litware.com ) should not generate data about this managed object ( Microsoft.BizTalk.Server.2013.BAMRole ).
So on any and all servers hosting BizTalk artifacts we need to enable the SCOM agent to act as a proxy and allow it to submit information about objects on servers other than where it is running (even on the SQL server or servers where BizTalk databases and jobs are hosted).
To enable this functionality, open the Operations Manager console and navigate to the Administration workspace. Select the Agent Managed section on the left-side pane, and find each of the servers hosting BizTalk components. On the first one, right-click on the server, and select Properties. Click on the Security tab, and make sure the checkbox is checked for Allow this agent to act as a proxy and discover managed objects on other computers. Click OK to complete the configuration, and repeat these steps for every server hosting any BizTalk components.
Discovery Execution Machine
The initial discovery of BizTalk artifacts, as documented in the Management Pack Guide, only occurs on a single BizTalk server in the group. As it turns out, out of the box, the management pack looks for the first server where the group was created, and executes discoveries of artifacts there. After all, an Orchestration or Receive Location or Host is a group-wide concept, not really owned by each machine individually, and no differently configured on each machine in the group. When one creates a Send Port, the configuration for said port is the same in each machine in the group, and the port is really hosted in the Configuration database, so it makes sense to discover artifacts only on one machine in the group.
However, I have seen a couple of occurrences where the first machine to join the group is no longer in the group. I have had a couple of customers who simply shut down the old server and wheeled it away, so the group still "thinks" that machine is part of the group. And when Operations Manager goes to execute discoveries there, the machine cannot be found so they never execute.
The Management Pack Guide mentions that one can change this default configuration through an Operations Manager override. An override is a way to "supersede" the default behavior and replace it with custom behavior we desire. Unfortunately the Management Pack Guide then fails to tell us which discovery to override. Let me walk you through the correct, and complete process.
First we need to open the Operations Manager Administration Console, logged in with an account which has either Administrator or Author privileges, and navigate to the Authoring workspace. Expand the Management pack objects node, and click on Object Discoveries. If you see a yellow band across the top of the middle pane of the console, as shown below, click the "X" on the right side of the band to remove the scoping of the objects in the view.
Once the scoping has been removed, in the Look For text box type "BizTalk Group Discovery" as shown above, and click Find Now. This might take a moment, but soon the rest of the discoveries will be filtered out and only the discovery called BizTalk Group Discovery will be left. Right-click on BizTalk Group Discovery and select Overrides, then Override the Object Discovery and then select For all objects of class: BizTalk Run-Time Role.
Note: This last part is important as it "targets" the override to any and all servers of that class. If you have multiple BizTalk groups you are monitoring with Operations Manager, you will want to create a group containing the servers where the setting needs to be changed, excluding the ones where it does not need to change, and then target the override at the group.
The overrides properties for this discovery provide a setting for us to specify the computer where we would like discoveries to execute. Click the Override checkbox on the left-most column on the first row, with the Parameter Name of Computer Name, and then type the name of the computer you wish to execute discoveries on in the Override Value column.
Click the Edit link in the top right of the Details box, and provide a justification for the change. This is useful from an auditing perspective.
Finally select your unsealed management pack to store BizTalk customizations. Remember NOT to use the Default management pack for this, and if you don't have a management pack in which to store all BizTalk Management Pack related overrides, simply create one by clicking the New button and following the wizard. Once you have selected the management pack from the dropdown box, click OK and the change will take place.
Comments
- Anonymous
May 23, 2014
Fantastic Post! - Anonymous
May 24, 2014
Pingback from Blog Post: When the BizTalk Management Pack for Operations Manager does… well, nothing. | NextOff - Anonymous
June 19, 2014
Just what I was looking for. Thank you! - Anonymous
August 26, 2014
Execellent Post. Couldn't have done this without this post. Thanks - Anonymous
September 15, 2014
Hi, a small question on what MPs of BizTalk Server need to be installed to be able to monitor a big landscape with different versions of BizTall ? do I install all MPs or just the latest ? - Anonymous
October 16, 2014
@StefVB... To answer your question, the BizTalk 2009 management pack monitors BizTalk 2006 R2 and BizTalk 2009. The BizTalk 2010 Management pack can monitor BizTalk 2006R2, 2009 and 2010. The BizTalk 2013 management pack monitors ONLY BizTalk 2013. - Anonymous
January 05, 2015
the "BizTalk server installation" discovery targets windows computer, and just uses a simple registry query to find out if BizTalk is installed, right? so the local system should be able to discover it. also, a domain account that is a local admin on the machine ---with no BizTalk permissions-- should still be able to find it. where would I start troubleshooting if I don't even have any "BizTalk server installation" instances in discovered Inventory? - Anonymous
January 05, 2015
one more thing: the "BizTalk installation" discovery targets the registry keys hklm/software/microsoft/BizTalk/productversion and hklm/software/microsoft/businessrules. I don't have either one of those keys, because i'm running on 64-bit windows. so the businesrules key is under hklm/software/wow6432node/microsoft/businessrules. so the BizTalk discoveries are definitely "doing nothing." is that expected? am I missing something? - Anonymous
January 29, 2015
I have tried everything you suggested but still.. Nothing.
We use SCOM 2012 R2 and BizTalk 2013 with its database running on sql 2014.
Is SQL 2014 supported by BizTalk management pack?
One last question should I aim the discovery against the BizTalk server or the BizTalk database? - Anonymous
January 29, 2015
http://banthuocmoi.com
http://banthuocmoi.net
http://banthuocmoi.com.vn
http://banthuocmoi.vn
http://banthuocchuot.com
http://banthuocchuot.net
http://banthuocchuot.org
http://banthuocchuot.info
http://banthuocchuot.vn
http://banthuocchuot.com.vn
http://banthuocmuoi.com
http://banthuocmuoi.net
http://contrung.com.vn
http://contrung.vn/
http://dietmoivietnam.com
http://dailythuocdietchuot.com
http://dailythuocdietchuot.net
http://dailythuocdietchuot.com.vn
http://dailythuocdietchuot.vn
http://dailythuocdiet - Anonymous
January 29, 2015
http://dichvuthamtuhanoi.net
http://thuethamtu.net
http://trungtamdieutra.net
http://vanphongdieutra.net
http://dieutradansu.net
http://diepviensaigon.com
http://diepviensaigon.net
http://diepvien007.net
http://dichvudieutra.info
http://dichvudieutra.org
http://dichvudieutra.com.vn
http://dichvudieutra.vn
http://dieutradansu.com.vn
http://dieutradansu.vn
http://vanphongthamtusaigon.net
http://vanphongthamtusaigon.com
http://vanphongthamtutu.net
http://vanphongthamtuvietnam.com
http://vanphongthamtuvietnam. - Anonymous
April 21, 2015
I apologize as I know this may not be the correct place to ask this question. Does the BizTalk 2010 Monitoring Mgmt Pack work with SCOM 2012 R2? I see the requirements are SCOM 2007...however want to ensure we can utilize for SCOM 2012 R2 as this is the version I have in my environment.- Anonymous
April 26, 2016
I am a year late in replying since I've ignored the blog for too long. All management packs which work in SCOM 2007R2 will work in SCOM 2012 and SCOM 2012 R2. So yes, the MP you asked about will work in SCOM 2012 R2.
- Anonymous
- Anonymous
May 22, 2015
Hi i am creating aggregate roll up monitors for BizTalk Host instances. below steps i took but Monitor still shows unmonitored
Task.
Monitoring of BizTalk Clustered Host Instances will generate an alert only if both the clustered host instances are stopped. The following approach will be taken to configure monitoring in clustered host instances.
o Leave the default monitoring for non-clustered Host Instances.
o Create a group (BizTalk Clustered Host Instance) with static membership configuration for twelve clustered host instances and save into custom management pack (clustered Host Instance override)
o Go to monitor and create override for (Host instance availability monitor) is equal to false
o Configure override for host instance which targeted to the group Clustered host instance
o Set generate alert is equal to False.
o Create 6 aggregate roll up monitors, ( example:BizTalk RecDeviceTxnHost Cluster Aggregate Monitor) one per Host instance cluster and configure the health rollup policy set for best state of any member, under ,,,,, management pack
- Enable alerting.
- Include clustered in Alert
- Write alert description
Please provide help
- Anonymous
April 26, 2016
Not sure what you are trying to accomplish here. If you're trying to create a group of BizTalk Host instances to aggregate their health, you can define health for a SCOM group as described in this article: https://sites.google.com/site/scomblogs/journal-blog/monitoringtheavailabilityandhealthofagroupinscom
- Anonymous
- Anonymous
June 03, 2015
Hi Andres Naranjo, it was an Excellent Post. I have a few doubt to ask,
I have BizTalk 2013 R2 Environment of 5 BizTalk Servers with 2 SQL 2014 databases,
Also I had imported Biztalk 2013 MPs and Configured BizTalk Admin account as Run as Account, But still
all MP Views and values are completely Empty.
1. Can you Please suggest a solution for this ?
2. Is there any criteria that Biztalk 2013 MP doesn't support SQL 2014 database ?
Thanks in Advance- Anonymous
April 26, 2016
The best advice I can give you is to review the BizTalk 2013 Management Pack guide carefully and assign the permissions EXACTLY as described in the guide.
- Anonymous
- Anonymous
June 04, 2015
Can anyone Suggest a solutions for my questions...Its too urgent..
Thanks all - Anonymous
August 11, 2016
Hi Andres, Thanks for this post, This post helped me to solve my issue about adding BizTalk servers on SCOM.However, I am wondering if there is a possibility of monitoring multiple BizTalk groups (Different environments) on the same SCOM server with multiple custom BizTalk management packs. If so any idea how we implement that. Thanks for your help.- Anonymous
August 12, 2016
The comment has been removed
- Anonymous
- Anonymous
April 26, 2017
Very detailed and explanatory post! Thanks. - Anonymous
March 07, 2018
Hi Andres,I'm wondering if you are able to help. I see some strange things within the BizTalk 2013 management pack which I imported into our SCOM 2016 system.We have three BizTalk 2013 systems and monitoring works ok. I can see all of the applications, groups, ports, etc.However, underneath the BizTalk Group Deployment I see all of the various host for BizTalkLogging, BizTalkServerApplication, BizTalkSAP. In each of those hosts all of the corresponding objects from ALL of our servers are listed. The obvisously have the same names and to me it looks like the managementpack cannot tell them apart and mixes things up. This means that monitoring becomes a mess as we get alerts for the wrong objects....Do you have an idea on how to fix that or how to report that bug ?Thanks in advanceThorsten- Anonymous
March 30, 2018
The comment has been removed
- Anonymous