So I’ve been away for awhile working on new things (HGS, you should take a look at it) and haven’t been able to mess with Orchestrator for some time. After watching a TechReady video I got inspired to build out a runbook for integrating workflows into HPSM and SCOM using Azure.
Building out a basic runbook to create some alerts to test the integration I discovered an annoying issue that never occurred before the upgrade. The error:
Failed to create alert. The exception was “Cannot load the management pack from the specified sealed assembly file: C:\Program Files (x86)\Common Files\Microsoft System Center 2012\Orchestrator\Extensions\Support\SCOM2012\Microsoft.SystemCenter.Orchestrator.Integration.Library.mp.”.
So I grabbed that MP from the Orchestrator server and tried to load it manually into SCOM 2016 and discovered that the MP wasn’t signed correctly. If you’re not aware, the first time the create alert activity runs it loads a MP into SCOM, so if you ever noticed or wonder why the create alert runbook fails the first time and works after that, that’s why. The MP that is loaded is version 7.3. I hit the internet and some inside resources and discovered the workaround for this issue is to load the MP from Orchestrator 2012 that is in the same location but this version is 7.0. Manually load that MP into SCOM 2016 and that will clear the alert. Great!! That issue is fixed so moving on with my project.
Now I need to update an alert with a ticket number and BAM another error. Now I’m about to pull my hair out. This has never been an issue before. The strange thing about this issue is it would update the alert as expected but it would fail with the following error
Failed to update alert. The exception was “[A]System.Collections.Generic.List`1[Microsoft.EnterpriseManagement.Monitoring.MonitoringAlertUpdateStatusIndigo] cannot be cast to [B]System.Collections.Generic.List`1[Microsoft.EnterpriseManagement.Monitoring.MonitoringAlertUpdateStatusIndigo]. Type A originates from ‘mscorlib, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089’ in the context ‘LoadNeither’ at location ‘C:\Windows\assembly\GAC_32\mscorlib\220.127.116.11__b77a5c561934e089\mscorlib.dll‘. Type B originates from ‘mscorlib, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e089’ in the context ‘LoadNeither’ at location ‘C:\Windows\assembly\GAC_32\mscorlib\22.214.171.124__b77a5c561934e089\mscorlib.dll‘.”.
Obviously the issue with this is anything after that activity wouldn’t run even though technically it didn’t fail. The workaround stated online for this is to build a link filter to allow the runbook to keep running after the error. To me this is not an acceptable workaround. What if the IP gets updated and fixed then that workaround would break after the fix. Also, this just doesn’t look good to a customer at all. After several days of trying to figure this out I got my fellow coworker and SCOM expert Kevin Holman on the phone to help troubleshoot this. After going through some logs and monitoring the SDK traffic we discovered that you need to install the SCOM 2012 console and the error disappeared. Now the confusion that can come into play is that the website to download the System Center 2016 IPs states no SCOM console is required to be installed on the runbook servers. On top of that installing the SCOM 2016 console does not work. It has to be the SCOM 2012 console.
And that should fix the issues with the SCOM 2016 IP and Orchestrator. Hopefully this helps someone else not waste a week trying to figure these issues out.