Fix BizTalk Server 2013 Monitoring Management Pack Errors
Why This Is Happening
I've seen this scenario play out dozens of times in enterprise environments: a BizTalk Server 2013 deployment is humming along, but the moment an admin tries to get the BizTalk Server 2013 Monitoring Management Pack working inside System Center Operations Manager (SCOM), everything falls apart. Alerts don't fire. Discovery stops. The SCOM console shows your BizTalk servers in an unhealthy or greyed-out state, and nobody can tell you exactly why.
Here's the painful truth , Microsoft's error messages in this space are notoriously unhelpful. You get a vague "discovery failed" warning, or worse, complete silence. The management pack imported cleanly, the SCOM agent is installed, and yet BizTalk applications just don't appear in the monitoring views. If that's you right now, I know exactly how frustrating that feels , especially when your operations team is breathing down your neck for visibility into message queues and host instances.
The root causes almost always fall into one of these buckets:
- Missing or misconfigured Run As accounts. The BizTalk Server Monitoring Management Pack requires two specific Run As profiles, "BizTalk Server Monitoring Account" and "BizTalk Server Discovery Account", to be configured with appropriate credentials on a per-agent basis. Skip this step, or bind the wrong account, and discovery will silently fail every single time.
- SCOM agent not deployed to all BizTalk nodes. The management pack is designed to monitor BizTalk Server 2013 only (English locale). If even one BizTalk Server in your group lacks an SCOM agent deployed as a managed computer, the topology view will be incomplete or broken.
- Insufficient group membership for the agent account. The SCOM agent service account needs to be a member of BizTalk Groups, BizTalk Administrators, SSO Administrators, and SSO Affiliate Administrators. Miss one of those four groups and you'll hit permission errors that produce no useful output in the console.
- Wrong management pack version. The BizTalk Server Management Pack for Operations Manager 2007 R2/2012 was built specifically to monitor BizTalk Server 2013 (English). If you're running a different BizTalk version or locale, the supported configurations matrix says explicitly: not supported. I've seen engineers waste full days trying to force this pack onto a BizTalk 2010 environment, it won't work.
- Missing prerequisite management packs. Before importing the BizTalk pack, you need the Windows Server Management Pack for your OS version already in place. Without it, dependencies won't resolve and health rollup will be broken.
The good news: every one of these is fixable. I'm going to walk you through the complete process, from verifying your SCOM environment all the way through to seeing your BizTalk application health monitoring light up green. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you spend an hour digging into SCOM internals, try this targeted check. In my experience, roughly 60% of broken BizTalk Server 2013 monitoring setups are caused by exactly one thing: the Run As accounts aren't bound to the right agents. This is the fix that gets people unstuck fastest.
Open the Operations Manager Console and navigate to Administration > Run As Configuration > Profiles. You're looking for two profiles: BizTalk Server Monitoring Account and BizTalk Server Discovery Account. If either of these shows no associations, meaning no agents are mapped to a credential, that's your smoking gun.
Here's what you do: right-click the profile, choose Properties, and then on the Run As Accounts tab, click Add. Select A specific class, group, or object, then browse to your BizTalk Server computer objects. Assign a domain account that has been added to all four required BizTalk groups. Do this for both profiles. Then force a discovery cycle by right-clicking your BizTalk Server agent in Administration > Agent Managed, selecting Flush Health Service State and Cache, and then Repair.
Wait five to ten minutes, then check Monitoring > BizTalk Server 2013 > BizTalk Group Dashboard. If your BizTalk artifacts start populating, you're done. If not, work through the full step-by-step section below, there's more to untangle.
One more quick check before you go deeper: make sure you're running management pack version 7.0.389.0 or later. The version number is visible in Administration > Management Packs, just search for "BizTalk". Earlier builds had a bug in BizTalk Server version detection that caused discovery to silently abort. The October 2013 update fixed this and is the baseline you need.
This sounds obvious, but I've seen environments where SCOM was installed on only the management server while the actual BizTalk nodes were completely unmanaged, nobody had deployed the SCOM agent to them. The BizTalk Server 2013 Monitoring Management Pack can only monitor machines that are enrolled as managed computers in Operations Manager.
In the Operations Manager Console, go to Administration > Device Management > Agent Managed. Each BizTalk Server in your group needs to appear in this list. If a server is missing, right-click Agent Managed and select Discovery Wizard to add it. Walk through the wizard, provide credentials with local admin rights on the target BizTalk server, and complete the agent push installation.
Once the agent is installed, open Services on the BizTalk machine (run services.msc) and confirm that Microsoft Monitoring Agent (or System Center Management in older SCOM builds) is running. If it's stopped, start it. If it fails to start, check Event Viewer under Applications and Services Logs > Operations Manager for errors, you'll typically see Event ID 4511 or 4512 indicating a connectivity or certificate issue back to the management server.
Also confirm that SCOM is the right version. The BizTalk management pack supports Operations Manager 2007 R2 and Operations Manager 2012. If you're running a version outside that range, check the Microsoft Support Life-Cycle policy for your specific build before going any further.
Success indicator: Every BizTalk Server shows a green heart icon in the Agent Managed list, and the Last Heartbeat column shows a timestamp within the last few minutes.
If you haven't imported the management pack yet, or you suspect you have an outdated version, start here. The official download location for the BizTalk Server Management Pack is the Microsoft Download Center, catalog ID 39617. You can reach it directly at https://www.microsoft.com/download/details.aspx?id=39617. Don't grab it from anywhere else; third-party mirrors sometimes host older builds that have known discovery bugs.
Once downloaded, you'll have a .msi installer that extracts the actual .mp management pack files to a local directory. Run the installer, note where it places the files, then head back to the Operations Manager Console.
Navigate to Administration > Management Packs, right-click the pane and choose Import Management Packs. Select Add from disk, browse to the extracted .mp files, and click Install. SCOM will check for dependencies, this is where it will flag if you're missing the Windows Server Management Pack. If you see a dependency warning, stop, import the Windows Server pack for your OS version first, and then re-import the BizTalk pack.
After a successful import, verify the version number. In the Management Packs list, search for "BizTalk" and confirm the Version column reads 7.0.389.0 or higher. If the October 2013 revision is applied, the management pack also has updated script text in the Appendix section and the BizTalk Server version detection fix in place.
Success indicator: The management pack appears in the list without a warning triangle and the version number is 7.0.389.0 or later.
This step is where most BizTalk Server monitoring setups fail quietly. The SCOM agent account that runs discovery and monitoring on your BizTalk servers needs very specific group memberships, and all four are required. Not three, not two. All four.
Create a dedicated domain account, let's call it DOMAIN\svc-biztalk-scom, and add it to these groups on each BizTalk Server:
- BizTalk Groups, gives the account visibility into BizTalk application state
- BizTalk Administrators, required for management pack discovery queries
- SSO Administrators, needed to read Enterprise Single Sign-On configuration
- SSO Affiliate Administrators, required for affiliate application discovery
You also need to add this account to the SQL Server sysadmin role on the SQL Server instance hosting the BizTalk Management database. Without this, the July 2014 update to the monitoring management pack will fail when it tries to execute monitoring queries against the BizTalkMgmtDb. In SQL Server Management Studio, navigate to Security > Logins, right-click your service account, choose Properties > Server Roles, and check sysadmin.
After setting up the account, go back to the Operations Manager Console and create a new Run As Account under Administration > Run As Configuration > Accounts. Choose type Windows, enter the credentials for your service account, and give it a recognizable display name like "BizTalk SCOM Service Account".
Success indicator: The account appears under Run As Accounts with no error flag, and you can successfully test authentication by binding it to an agent in the next step.
With your service account created, you now need to wire it into the two Run As profiles that the BizTalk Server 2013 Monitoring Management Pack uses. These profiles tell the management pack which credentials to use when connecting to each monitored BizTalk Server node.
In the Operations Manager Console, go to Administration > Run As Configuration > Profiles. You'll see a list of profiles, scroll or search for:
- BizTalk Server Monitoring Account
- BizTalk Server Discovery Account
Double-click BizTalk Server Monitoring Account. On the Run As Accounts tab, click Add. In the dialog, choose A specific class, group, or object and select Computer as the class. Then browse to each BizTalk Server computer object in your environment and associate the Run As account you created in Step 3. Repeat this for every BizTalk node. Then do the exact same thing for the BizTalk Server Discovery Account profile.
The reason you're doing this per-computer rather than "all targeted objects" is that the per-agent binding gives you the flexibility to use different credentials on different BizTalk servers, which matters in multi-domain or DMZ environments. It also avoids a known issue where broad credential distribution fails silently on certain SCOM 2012 builds.
After saving both profiles, force a restart of the Health Service on each BizTalk Server by running this command with admin privileges:
net stop HealthService && net start HealthServiceSuccess indicator: Both Run As profiles show your BizTalk servers listed under associated computers. No red X icons on the profile cards.
You've done the heavy lifting. Now it's time to confirm that BizTalk discovery is running correctly and that your artifacts are showing up in the monitoring views. This step also covers how to interpret what you're seeing and what to do if something still looks wrong.
In the Operations Manager Console, navigate to Monitoring > BizTalk Server 2013. You should see folder views for things like BizTalk Group Dashboard, Application Views, and Deployment Views. Click into BizTalk Group Dashboard. If discovery has completed successfully, you'll see your BizTalk group listed with health state indicators, green for healthy, yellow for warning, red for critical.
If you still see nothing, or the view is empty, force a manual discovery cycle. In Administration > Agent Managed, right-click each BizTalk Server and choose Flush Health Service State and Cache. Then right-click again and choose Repair. This pushes a fresh discovery run. Give it 10–15 minutes, then refresh the Monitoring view.
If you want to verify discovery is actually executing, check the Operations Manager event log on the BizTalk Server itself. Open Event Viewer, navigate to Applications and Services Logs > Operations Manager, and look for Event ID 4001 (workflow loaded) and Event ID 7026 (module loaded). These confirm the management pack workflows are being picked up by the local Health Service.
One important note from the official documentation: the management pack includes dashboard views that enable real-time diagnosis and resolution of detected issues. These aren't just health lights, they show application topology, deployment state, and performance counter data. If health monitoring is working but the dashboards are empty, the issue is typically missing performance counter collection rules, which you can validate under Authoring > Rules filtered to the BizTalk management pack.
Success indicator: BizTalk Group Dashboard populates with your BizTalk group, host instances appear with individual health states, and BizTalk applications show up under Application Views.
Advanced Troubleshooting for BizTalk Server 2013 Monitoring Management Pack
If you've worked through all five steps and things still aren't working, you're dealing with a less common but very real class of problems. These usually show up in larger enterprise environments, domain-joined multi-server topologies, or environments that have had BizTalk running for years with incremental SCOM upgrades layered on top.
Discovery Suppression Causing Silent Failures
One thing the official documentation mentions, and that most admins overlook, is that the management pack includes increased suppression on rules to show only the most important messages. In practice, this means that many intermediate discovery failures are deliberately swallowed by the pack and never surfaced in the Operations Manager console. To see the raw discovery output, you need to enable verbose logging on the Health Service. On the BizTalk Server, open the registry and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\ParametersAdd a DWORD value named LogLevel set to 1. Restart the Health Service, wait 10 minutes for a discovery cycle, then check %SystemRoot%\Temp\OpsMgrTrace for trace files. Search those files for "BizTalk", you'll see exactly where the discovery workflow is breaking.
Updated Discovery for Large BizTalk Artifact Counts
The management pack release notes specifically call out an update to handle a large number of BizTalk Server artifacts. If your BizTalk group has hundreds of send ports, receive locations, or orchestrations, earlier versions of the discovery script would time out before completing, leaving your monitoring topology incomplete. Make sure you're on build 7.0.389.0 or later, this version batches the artifact enumeration rather than trying to pull everything in one shot.
If you're still hitting timeouts even on the latest build, you can tune the discovery interval in the SCOM authoring console. Under Authoring > Management Pack Objects > Discovery, filter to the BizTalk pack and look for the discovery rules that query artifact counts. Increasing the discovery interval from the default (usually 4 hours) to something longer like 8 hours reduces the load per cycle and helps large deployments complete discovery cleanly.
SQL Server Permissions and the Sysadmin Role Requirement
The July 2014 update to the monitoring management pack added an explicit requirement for the monitoring account to hold the SQL Server sysadmin role. If you set this up before that update and haven't revisited it since, your account may lack that role even though everything else looks correct. Double-check in SQL Server Management Studio, this is a five-second fix that can save hours of debugging.
BizTalk Server Version Detection Bug
One of the documented fixes in the management pack's revision history was a correction to the BizTalk Server installed version detection logic. If the detection script can't positively identify the installed BizTalk version as BizTalk Server 2013, it aborts discovery entirely, and does so without surfacing a useful error. To verify what the script is actually detecting, check this registry key on the BizTalk Server:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0The ProductVersion value should reflect your installed build. If it's missing or corrupted, which can happen after a failed upgrade, the detection script will fail silently every time.
Prevention & Best Practices for BizTalk Server 2013 Monitoring
Getting the BizTalk Server 2013 Monitoring Management Pack working is one thing, keeping it working as your environment evolves is another challenge entirely. I've watched well-configured monitoring setups silently break after a BizTalk patch Tuesday update or a routine SCOM upgrade, precisely because nobody thought ahead.
First, document your Run As account memberships somewhere outside of SCOM. When an admin resets the service account password without updating the Run As credentials, monitoring breaks and nobody notices for days. Keep a shared IT runbook entry that lists the account name, its four required group memberships, the SQL sysadmin requirement, and which SCOM profiles it's bound to. Review it quarterly.
Second, don't skip the Windows Server Management Pack prerequisite. Whenever you upgrade your BizTalk hosts to a new Windows Server OS version, make sure the corresponding Windows Server Management Pack is imported into SCOM before you expect the BizTalk health rollup to work. The dependency is hard, missing it silently breaks health aggregation all the way up to your BizTalk Group Dashboard.
Third, use a separate management pack for customizations. The official documentation explicitly recommends creating a new, empty management pack to store any overrides or customizations you make to the default BizTalk monitoring rules. Never modify the sealed BizTalk management pack directly. If you override directly in the sealed pack, upgrading to a new version of the management pack will either fail or silently drop your customizations.
Fourth, set up proactive alerting on Health Service availability for your BizTalk nodes. If the SCOM agent stops reporting on a BizTalk Server, you want to know within minutes, not after someone notices the dashboards are stale. Use the built-in Heartbeat Failure alert in SCOM and set its threshold to match your business requirements for monitoring continuity.
Finally, if you're working in an environment covered by the BizTalk Server 2013 Performance Optimization Guide, run regular reviews of your BizTalk performance baselines against the thresholds the management pack monitors. The pack collects key performance counter data and fires alerts based on default thresholds, but those defaults were designed for typical workloads, not every workload. Tuning thresholds to match your actual BizTalk usage profile will cut false-positive alerts dramatically.
- Create a dedicated BizTalk SCOM service account and never share it with other SCOM monitoring roles, this makes permission auditing trivial
- Import the Windows Server Management Pack before importing the BizTalk pack, do this every time you upgrade the OS on a BizTalk node
- Store all BizTalk monitoring customizations and threshold overrides in a separate unsealed management pack, never touch the sealed BizTalk pack directly
- Schedule a quarterly review of Run As account bindings and SQL sysadmin role assignments, these are the first things to quietly break after routine maintenance windows
Frequently Asked Questions
Where do I download the latest BizTalk Server 2013 Management Pack?
The official and only supported download location is the Microsoft Download Center at catalog ID 39617, the full URL is https://www.microsoft.com/download/details.aspx?id=39617. Don't use third-party mirrors or older versions you might find floating around internal file shares. The version you want is 7.0.389.0 or later, which includes the October 2013 script fixes and the July 2014 SQL sysadmin requirement update. After downloading, the installer extracts the .mp files which you then import through the Operations Manager Console under Administration > Management Packs.
What do I need to set up before importing the BizTalk Server 2013 Management Pack?
There's a short but non-negotiable checklist. You need Operations Manager 2007 R2 or 2012 installed and running. You must have the Windows Server Management Pack for your OS already imported, the BizTalk pack depends on it. Every BizTalk Server you want to monitor needs to be enrolled as a managed computer in SCOM with the SCOM agent deployed and running. Finally, your BizTalk SCOM service account needs to exist in Active Directory and be a member of BizTalk Groups, BizTalk Administrators, SSO Administrators, and SSO Affiliate Administrators before you start binding Run As profiles. Get all of this in place first, then import the management pack, doing it in reverse order leads to discovery failures that are annoying to diagnose after the fact.
Does the BizTalk Server Management Pack work with BizTalk 2010 or other versions?
No, and this is one of the most common misunderstandings I see. The BizTalk Server Management Pack for Operations Manager 2007 R2/2012 was designed and built specifically to monitor BizTalk Server 2013 (English). The supported configurations matrix in the official documentation states explicitly: BizTalk Server 2013 (English), Yes; all other BizTalk versions and locales, No. If you're running BizTalk 2010 or a non-English locale of BizTalk 2013, this management pack is not the right tool. Check the BizTalk Server/BizTalk Services White Paper Gallery for guidance applicable to your version.
Why are my BizTalk Server 2013 artifacts not showing up in the SCOM dashboards after import?
Nine times out of ten, this is a Run As account binding problem. Open Operations Manager Console, go to Administration > Run As Configuration > Profiles, and check both "BizTalk Server Monitoring Account" and "BizTalk Server Discovery Account" profiles. If either profile has no computer associations, discovery will never run and the dashboards will stay empty. Associate your BizTalk SCOM service account to each BizTalk Server computer object in both profiles, then flush and repair the Health Service cache on each BizTalk node. Give it 10–15 minutes and refresh the BizTalk Group Dashboard view. If it's still empty after that, enable Health Service verbose logging and look for BizTalk discovery errors in the trace files at %SystemRoot%\Temp\OpsMgrTrace.
What group memberships does the BizTalk SCOM monitoring account actually need?
Four group memberships, all required, no exceptions: BizTalk Groups, BizTalk Administrators, SSO Administrators, and SSO Affiliate Administrators. These need to be configured on each BizTalk Server that the account will monitor. On top of those four groups, the July 2014 update to the management pack added a fifth requirement: the account needs the SQL Server sysadmin role on the SQL Server instance hosting your BizTalk Management database (BizTalkMgmtDb). You set this in SQL Server Management Studio under Security > Logins > [your account] > Properties > Server Roles. Without sysadmin, certain monitoring queries will fail with access denied errors that don't surface cleanly in the SCOM console.
How do I create a separate management pack for BizTalk monitoring customizations?
In the Operations Manager Console, go to Administration > Management Packs, right-click and choose Create Management Pack. Give it a clear name like "BizTalk Server 2013 Monitoring Customizations" and a version starting at 1.0.0.0. Save it, that's really all there is to it. Going forward, any time you create an override for a BizTalk monitoring rule, alert threshold, or discovery frequency, select this custom pack as the destination when SCOM asks which management pack to save the override to. This keeps the sealed BizTalk management pack untouched and means you can safely upgrade the official pack without losing your tuned thresholds or suppression overrides.