- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
Upgrading to Operations Manager 2012
Only SCOM 2007 R2 can be upgraded to Operations Manager 2012 so if you’re on an earlier version you have to upgrade to this level first. If you’re an early adopter and trialled the beta it can be upgraded to the current Release Candidate and it in turn is supported for upgrade to RTM. You can’t however upgrade from the beta directly to RTM, nor can you upgrade to RC from a SCOM 2012 beta that was originally upgraded from SCOM 2007 R2.
The most important prerequisite however is that all SCOM 2007 R2 management servers that you want to upgrade are 64 bit on x64 hardware and run 2008 R2 SP1 as the OS. If this isn’t the case in your environment, fear not, you can spin up a new server and start the upgrade from there. If you’re doing your upgrade this way back up your encryption keys from the current RMS and restore them on the new SCOM 2012 server.
The general sequence for an upgrade is: secondary management servers, gateways and agents first, then the Root Management Server (RMS). If any management servers or gateways are still 2007 R2 the final RMS upgrade will be blocked. If agents are still 2007 R2 this will be highlighted during the RMS upgrade but it won’t block the upgrade. Be aware that these agents won’t be able to report to SCOM until they have been upgraded to SCOM 2012 agents.
If yours is a smaller environment with a single SCOM 2007 R2 server you can either upgrade in place (provided your server meets the hard- and software requirements) or you can set up another management server and start the upgrade from there. If you upgrade in-place be aware that you have to upgrade all the agents before they’ll report to SCOM 2012.
To assist with your upgrade plan there are clickable flow diagrams on TechNet that clarifies what options you have, the same page also provides links to checklists with step by step instructions. There’s also an upgrade helper Management Pack (MP) that walks you through the upgrade and gives you an overview of what parts of your infrastructure has been upgraded.
Once your environment has been upgraded to Operations Manager 2012 you can take advantage of the new reporting functionality.
Further points for your upgrade planning includes backing up the databases, disabling notifications to prevent false alarms and stopping connectors to avoid false tickets being generated as well as making sure agents don’t report directly to the RMS as your upgrading it. Most importantly, check the event log for any problems, you can’t upgrade away from problems so ensure your SCOM environment is healthy before you upgrade.
If you used Operations Manager to deploy agents they will show up as pending upgrade in the console and you can push out the upgrade from SCOM; if you use an alternate method of deploying agents (such as SCCM) you have to upgrade them using your chosen deployment method but it’s simple MSI file so that should be easy. The native consoles are version specific so if you need both the old and the new console on a machine upgrade to the SCOM 2012 console and then reinstall the SCOM 2007 R2 console afterwards.
Depending on the size of your environment you may have a mix of SCOM 2007 R2 and SCOM 2012 management groups and servers in your environment for some time so be aware that the SCOM 2012 agent will communicate with SCOM 2007 R2 servers. The reverse isn’t true however so an important step in your upgrade process will be upgrading agents to the 2012 version. The new Control Panel applet makes it easy to identify which management groups an agent reports to and adding and removing of management groups from agents can now be centrally controlled via scripts.
The new scriptable control over agent assignments will be a boon in large environments as will the Control Panel applet for troubleshooting.
Management packs that work in SCOM 2007 R2 should work in Operations Manager 2012 because the MP schema is unchanged. The few exceptions are where third party management packs require new modules on the agent, new MP templates or new view types due to API changes; or if they attempt to create or update other MPs or elements within other MPs.
In the next part of this series we’ll look at PowerShell enhancements in SCOM 2012, interoperability with other platforms as well as improvements in the Console.