The goal of this post is to highlight some caveats I’ve found upgrading System Center 2012 to service pack 1, in this installment the focus will be on Operations Manager.
This post is not intended in any way to substitute the upgrade guide and the release notes, rather it tries to integrate and highlight what I consider hot points.
Servcie Pack 1 for System Center 2012 is juch like an R2 rather than a simple service pack, focusing on Operations Manager it introduces:
- Full support for Windows Server 2012
- APM dramatically extended to Windows Services and WCF web services
- Integration between IT Pros and Dev via Team Foundation Server synchronization
- Global Service Monitoring (see http://blogs.technet.com/b/momteam/archive/2013/01/14/system-center-global-service-monitor-getting-started.aspx)
For a complete list of new features, take a look here:http://technet.microsoft.com/en-us/library/jj656650.aspx.
Before event thinking about an upgrade, you must read the sequencing guide “Upgrade Sequencing for System Center 2012 SP1”. Service Pack 1 has a mandatory upgrade order, so even if this post is about Operations Manager you must remember System Center is now a single product with different components.
Failure to follow the correct upgrade sequence might result in component failure for which no recovery options exist. The affected System Center components are:
2. Service Manager
3. Data Protection Manager (DPM)
4. Operations Manager
5. Configuration Manager
6. Virtual Machine Manager
7. App Controller
Returning to Operations Manager the main entry point to plan for an upgrade is the “Upgrading System Center 2012 – Operations Manager to System Center 2012 SP1” guide on Technet. Based on the guide and my expericne I want to point out what I consider not intuitive caveats
SP1 adds several new alert resolution states.
247 – Awaiting Evidence
248 – Assigned to Engineering
249 – Acknowledged
250 – Scheduled
254 – Resolved
These states are used for Team Foundation Server (TFS) and Intellitrace integration, two new features of SP1.
Now, what happens if you are using these states for your own alert processing logic?
If you’re not going to use these new features then you can safely ignore the new status and rename them as you like. In fact upgrade will override custom-defined description for the previous states. The impact will be minimal since you can always restore back the custom definition. However, the conflict with TFS + Intellitrace will remain if you’re using the same resolution state code for something else.
If you want to use TFS + Intellitrace then there’s no other way than changing your custom alert resolution states.
Al in all this must be known and managed before the upgrade, even if you’re not going to use them your operators will have them in their resolution status list.
Contrary to the Opsmgr 2007 to OpsMgr 2012 migration, the SP1 is once again a top down approach: first infrastructure servers then agents.
Remember you need 50% of free space in your Operational DBs, the last thing you want is a failed upgrade ‘cause a DB went full, the only recovery solution in that case is a complete restore.
ACS forwarder are disabled by the upgrade process (sigh), so you must re-enable them after the upgrade has completed. On the ACS side there’s a nasty bug you can read about here SysCtr 2012 SP1 – ACS upgrade error (#scom #sysctr).
SP1 upgrade must be performed by an elevated command prompt, the msp doesn’t elevate itself.
If you made changes after you set up your web console to either enable or disable Secure Sockets Layer (SSL), the SSL settings will be reset during upgrade.
Finally, once SP1 is up and running, you can configure TFS and Intellitrace integration and incidentally alerts file attachments. But this is good topic for another post.
This posting is provided “AS IS” with no warranties, and confers no rights.