I’m not an Orchestrator guy by any means, but I do have to pretend to be one on occasion when the customer asks. I ran into an interesting issue during the initial connection of SCOM to Orchestrator that turned out to be rather painful to troubleshoot. We had the SCOM console deployed on the Runbook server and deployed/registered the Integration pack for SCOM 2016. The console itself worked fine, but when testing the connection between Orchestrator and SCOM, we kept getting the following error:
Missing sdk binaries. Install System Center 2016 Operations Manager Operations Console first
The text might be a bit off, as I don’t have a screenshot, but that was effectively the gist of it. I did a lot of scouring online in order to find something, but I really didn’t find much. After digging around internally, I did learn a few things worth sharing on this blog:
- Order is important.
- The SCOM console isn’t necessarily necessary. That depends on what activities you use.
- Those DLLs need to be present in the assembly folder, but this info is also not easily available.
The first think you’ll want to do to troubleshoot is to make a small tweak to the registry:
Create a dword named “DisableCacheViewer” without quotes under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion” Hexadecimal value “1”
What this does is slightly reorganize the assemblies in the C:\windows\assemblies folder. If you navigate there, what you’re supposed to see is in the screenshot below. Each of the highlighted folders represents one of the SCOM SDK DLL files. If you drill into any of them, you’ll see another folder indicating a version number, and inside of that will be a copy of the DLL.
That’s all pretty straight forward. In my case, the issue was order. The SCOM console had been installed first. While the instructions say nothing, that apparently matters, so the fix is rather easy. Uninstall the SCOM console. Uninstall and unregister the integration pack… And then reboot.
Once it’s back up, deploy and register the IP. There’s no need for the console. In my case, that was enough, though sometimes you’ll have to go more drastic. One option is to try this script (obvioulsy changing the path as needed):
[System.Reflection.Assembly]::Load(“System.EnterpriseServices, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”)
$publish = New-Object System.EnterpriseServices.Internal.Publish