With the release date of System Center 2012 getting closer, it’s time to start to plan for a proper migration to the new version. Every single component of System Center has its own way to perform the upgrade, all of them support a side by side migration, some of them allow for an upgrade. Operations Manager 2012 gives you both opportunities. You can find plenty of information on the topic and I don’t have any value to add to what has already been written or showed (for example check this video by Cameron Fuller).
What I want to write about is Management Pack compatibility, this is going to be a critical issue in any upgrade or migration to Operations Manager 2012, I guess few of you would accept to lose monitoring capabilities moving to the new version.
First of all and generally speaking Management Pack developed for Operations Manager 2007 are compatible with Operations Manager 2012, but, there’s always a but, there are particular cases that need to be seriously investigated during the migration plan effort.
In this post I will try to summarize the caveats I’m aware of today and, at the same time, I want it to become a reference for the topic so I’ll will keep it updated with the new issues I’ll learn during the migration processes I face.
SNMP based Management Pack
Since OpsMgr 2012 SNMP monitoring won’t any longer be based on the OS SNMP services, all the legacy MP based on SNMP needs to be reviewed. Key topics:
- If you’re going to perform an upgrade the discovered instances will be preserved, but you won’t be able to discover any new instance
- If you’re going to perform a migration (side by side upgrade if you want) you won’t be able to use old Management Pack
- In the case you performed an upgrade, workflows functionality should be preserved since new modules are backward compatible, but I will double check trap based monitors and rules. The stack has changed, you know.
- If you use SNMP based Management Pack that are using the SNMP WMI provider, or that are using some sort of proxying where there’s an external service that translates SNMP into something else (typically event log entries) then these cannot coexist on a management or gateway server used to run native OpsMgr SNMP modules. It’s a matter of conflict on SNMP ports between the OpsMgr stack and the OS stack. You need to review your deployment plan and move these proxy services somewhere else or afford new management servers. I must add it’s a good practice to have dedicated gateway / management servers for network monitoring anyway.
To migrate your legacy workflows to the new model take a look at this post.
Typical example of Management Pack relaying on SNMP are server hardware and storage management packs, xSNMP based management packs.
SDK based Management Pack
Here we have a broad spectrum of Management Packs. We can have management packs with external services (think about the infamous Exchange 2012 correlator engine), we can have management packs with custom managed code interacting with the SDK, we can have powershell scripts using cmdlets to query or set values. All these management packs need a thorough review. I’m not saying everyone of them will show incompatibilities, but there’s a fair chance they will. Key topics:
- Powershell based interaction won’t work, the cmdlets have changed, the scripts need to be rewritten. Just to be clear it’s not just about cmdlets naming changes, but even behavior changes. For example the Start-SCOMTask cmdlet now executes task asynchronously while it used to execute them synchronously in OpsMgr 2007.
- It is highly probable external services interacting with the sdk would need to be rewritten, at least to take into account the new high availability model, based on distributed workflows between management servers.
For more info on the new powershell cmdlets see this article by Oscar (System Center Operations Manager 2012 “More that meets the eye” Part 2–SCOM 2007R2–SCOM2012 PowerShell).
Typical examples of these management packs are Exchange 2010, Virtual Machine Manager, hardware vendor integrations, management packs that today require to be installed on the RMS.
Powershell based Management Pack
If you use management packs leveraging powershell modules you must remember now the powershell module needs PowerShell 2.0 (included in Windows 2008 R2 but not in previous releases), if you don’t have powershell 2.0 installed you get the following error and the workflows will be unloaded:
The constructor for the managed module type "Microsoft.EnterpriseManagement.Modules.PowerShell.PowerShellProbeActionModule" threw an exception.
The exception text is:
System.TypeInitializationException: The type initializer for ‘Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceConfigurationContainer’ threw an exception. —> System.TypeLoadException: Could not load type ‘System.Management.Automation.Runspaces.InitialSessionState’ from assembly ‘System.Management.Automation, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35′.
— End of inner exception stack trace —
at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceConfigurationContainer..ctor(List`1 snapIns, List`1 modules)
at Microsoft.EnterpriseManagement.Modules.PowerShell.PowerShellProbeActionModule..ctor(ModuleHost`1 moduleHost, XmlReader configuration, Byte previousState)
Error Code: -2130771961 (Unknown error (0x80ff0007)).
In my experience you must always install .net framework 4.0 on gateway management servers. Before installing the framework I had the following errors:
- powershell workflows not running (without any notice)
- healthservice hang (any task executed would never end / return)
- 0×80131700 Error Code: -2146232576 (Unknown error (0×80131700))
I didn’t find any reference to this requirement in the official documentation except for the dependency for network and xplat monitoring in the release notes (http://technet.microsoft.com/en-us/library/hh561709.aspx) and supported configurations (http://technet.microsoft.com/en-us/library/hh205990.aspx). Anyway my experience is you also need .net framework 4 for powershell modules on gateways.
Lastly we have the unknown and the untested, in OpsMgr 2012 things have changed so it’s possible, even if improbable, that perfectly working management pack in OpsMgr 2007 will exhibit strange behaviors in OpsMgr 2012. Maybe they import well, maybe they upgrade well, but then you start to see inconsistencies. Since luck is blind, but misfortune is sharp sighted, I stumbled into one of these very soon in my management pack porting activities. Anyway this is a list of these subtle incompatibilities I’ve found.
If any workflow has a parameter named Target you’re going to have issues. In OpsMgr 2012 this will conflict with the built-in $Target substitution token. You will need to change the Management Pack and use something different such as <TargetInstance> or <TargetComputer>. Here is a snippet that used to work in OpsMgr 2007 but won’t anymore in OpsMgr 2012:
<WriteActionModuleType ID="QND.PingRemote.WAType" Accessibility="Public" RunAs="SC!Microsoft.SystemCenter.AgentManagementAccount" Batching="false">
<xsd:element name="Target" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
<OverrideableParameter ID="Target" Selector="$Config/Target$" ParameterType="string" />
<WriteAction ID="Ping" TypeID="System!System.CommandExecuter">
<Task ID="QND.RemoteAgent.Task" Accessibility="Public" Enabled="true" Target="SC!Microsoft.SystemCenter.ManagementServer" Timeout="300" Remotable="false">
<WriteAction ID="Ping" TypeID="QND.PingRemote.WAType">
This posting is provided "AS IS" with no warranties, and confers no rights.