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:

 

1. Problems with Run As Accounts
2. Issues with the Agent Proxy setting
3. 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.