Are you currently running Operations Manager 2012 or earlier and interested in getting to Operations Manager 2012 R2? If so, this blog post should help you to identify which path to take and key tips and tricks to consider in the process.
There are three approaches which can be used for deployment or migration of Operations Manager to 2012 R2. These are:
- Fresh installation: This is used for a new installation of Operations Manager 2012 or when the existing Operations Manager 2007 R2 environment is either non-viable or unused.
- In-place upgrade: This is used to upgrade an existing OpsMgr 2007 R2 environment to OpsMgr 2012. This approach requires that the management server are on Windows Server 2008 R2 or higher and that the database is on SQL Server 2008 R2 or higher. This approach should work but we have seen that when it fails it fails in a way that the environment needs to be restored back to a backup. The benefits to an in-place upgrade are retention of the existing data in the data warehouse, and potentially a shortened coexistence timeframe since the migration is completed when the upgrade is completed. I only recommend this approach when it is required to maintain the data in the data warehouse or when the management group name must remain the same as it currently is.
- Multi-homed migration: This approach installs a new OpsMgr 2012 environment, upgrades agents to OpsMgr 2012 and the agents report to both the original OpsMgr 2007 R2 environment and the OpsMgr 2012 R2 environment. This works well for environments where there can be no down time to monitoring and where a longer co-existence period is acceptable. By moving sealed management packs between the environments, most of the overrides which were created can be moved to the OpsMgr 2012 R2 environment.
For further information on the options available for upgrade I recommend John Joyner’s article available at http://www.techrepublic.com/blog/data-center/upgrade-paths-to-system-center-2012-operations-manager/5650/, and the Operations Manager Unleashed book available at http://tinyurl.com/OM2012Unleashed.
For an existing Operations Manager 2007 customer, there are several steps required to upgrade:
- SCOM 2007 -> SCOM 2007 R2 CU#7
- SCOM 2007 R2 CU#7 -> SCOM 2012 RTM
- SCOM 2012 RTM -> SCOM 2012 SP1
- SCOM 2012 SP1 -> SCOM 2012 R2 RTM
The key to be aware of during this upgrade process is that a failure in the upgrade process will likely result in a non-functional Operations Manager environment. So if you must upgrade, be certain to fully backup all required servers (management servers, gateway servers, database back-end servers for Operations Manager, reporting, ACS servers, etc) after each step of this process. Virtual Machine snapshots/checkpoints are a viable option if they are virtualized systems.
For insights into the upgrade I recommend Marnix’s articles at:
Or our blog post on the topic available at: https://www.catapultsystems.com/cfuller/archive/2013/10/25/upgrading-operations-manager-from-2012-sp1-to-2012-r2-step-by-step-upgrading-to-2012-r2-series.aspx
The following is not a step-by-step process. This is a series of tips, tricks, and blog posts that I have used to make this process more efficient.
1. Upgrade the existing Operations Manager 2007 to the current revision: By upgrading the current Operations Manager environment to the latest version for 2007 (2007 R2 CU#7) both for the Operations Manager servers and for the agents I have seen a significant number of issues addressed before performing the upgrade to 2012 R2. We often identify problems with agents which would have surfaced later in the upgrade process and it’s better to take them on now than later. By bringing the full environment to the latest 2007 R2 revision we simplify the multi-home migration process.
2. Design and install the Operations Manager 2012 R2 environment: Spend the time to properly design the new Operations Manager 2012 R2 environment, being sure to use a different management group name than what is currently used in the Operations Manager 2007 environment. Additionally this name cannot conflict with any Service Manager management group names. Install UR1 on the Operations Manager 2012 R2 environment or the latest update rollup prior to starting any multi-homed efforts. Be sure to add the license for Operations Manager to the environment (see https://www.catapultsystems.com/cfuller/archive/2012/04/24/q-a-opsmgr-2012-eval-version-product-keys-and-powershell-sysctr-scom.aspx). Also be sure to re-configure your anti-virus exclusions to consider the new service name and folder structure for Operations Manager 2012 R2 (Marnix documents this well at http://thoughtsonopsmgr.blogspot.com/2011/11/with-scom-one-had-to-exclude-certain.html).
3. Export the management packs from the 2007 environment: Tao’s management pack provides an easy way to do this by adding his two management packs (the sealed on and the unsealed one) and enabling the rule to backup management packs daily (http://blog.tyang.org/2014/02/23/opsmgr-2012-self-maintenance-management-pack-update-version-2-3-0-0/). Additionally you can do this as a once off using PowerShell (I think this reference is good for the topic: http://www.toolzz.com/?p=153).
4. Compare Microsoft management packs in the environment and move Microsoft standard management pack: Next we need to assess what management packs exist in both environments. This utility (https://www.catapultsystems.com/cfuller/archive/2013/11/19/how-to-use-the-management-pack-compare-util-to-identify-management-pack-version-differences.aspx) provides a way to graphically see the differences in management packs. There is also a report option available discussed in the comments. Create a list of standard Microsoft management packs used in the 2007 R2 environment and download and install the same management packs in the 2012 R2 environment. By moving these core management packs (most likely SQL server, IIS, Core Operating System and such) we can get the environments more close to being in sync. There will be new versions of the System Center Operations Manager built-in management packs which will be different between the environments but these can be ignored.
5. Identify and remove obsolete management packs. There should be several management packs which are no longer required from the Operations Manager 2007 R2 environment. This is a great time to get rid of the old management packs which are no longer required and make a cleaner Operations Manager 2012 R2 environment. Examples include Windows 2000, backward compatibility management pack, etc. To identify these use the existing views in the Operations Manager 2007 R2 environment to see if severs still exist in any of these views. The backward compatibility management pack should be removed unless there is no other choice as these packs are MOM 2005 converted management packs which should hopefully be obsolete by this point in time. See this article (https://www.catapultsystems.com/cfuller/archive/2013/11/11/removing-obsolete-references-in-custom-management-packs-step-by-step.aspx ) for step-by-step directions to remove obsolete management pack references when moving between environments. This is where the bulk of the work needs to occur during a multi-homed migration.
6. Moving third party management packs: Contact any third party vendors which you are using currently in your Operations Manager 2007 R2 environment to identify if updated versions of the management pack are required. Most Operations Manager 2007 management packs will work in Operations Manager 2012 with the exception of any management packs which use SNMP (which was re-written in Operations Manager 2012).
7. Moving special Microsoft management packs: There are a few management packs which are not available in the catalog within the Operations Manager console. These three require different approaches to add the management pack:
- The VMM management packs are added from VMM not directly into OpsMgr
- The DPM 2012 management pack is on the DPM media (\SCDPM\ManagementPacks\en-US)
- The Exchange 2010 MP is only available from the online catalog
8. Moving custom management packs: When moving management packs it is important to implement a naming convention and stick to it. My general recommendations is to prepend any custom developed management packs with the name of the company ("Catapult" as an example) and to append the word Overrides to any override management packs ("SQL 2012 Overrides" as an example). If these management packs are already named in a different naming convention you can rename them within the Operations Manager console (note, this doesn’t change the underlying XML so it’s not as clean to rename them but it makes it appear more consistent when trying to find management packs). Management packs should already have been updated to remove any obsolete management pack references but if errors occur when importing management packs see the earlier post on removing obsolete references in custom management packs.
9. Upgrading agents: Identify a list of agents which can be upgraded to the Operations Manager 2012 R2 agent as part of the multi-homed migration. Agent deployments from Operations Manager 2012 R2 need to be performed for the agents currently in Operations Manager 2007 R2 (this upgrades the agent and makes it multi-homed to both environments). As a quick trick, you should be able to highlight all of the computers in the Windows Computer or agent views and copy and paste these into excel to get a list of the agents currently in Operations Manager 2007 R2. Remove any management servers and gateways and any non-required fields and this list can be pasted into the discovery wizard in Operations Manager 2012 R2 to minimize any typing required for the agent names.
10. Migrating subscriptions and notifications: Subscription information including notifications are stored in a management pack which can be exported, updated and imported into the new environment. Details are available at http://www.systemcentercentral.com/quicktricks-migrating-subscriptions-between-operations-manager-environments-scom-powershell-sysctr/.
11. Migrating runas accounts: From what I have seen so far each of the required runas accounts will need to be manually added into the Operations Manager 2012 R2 environment as this information appears to be stored in the database and not in any of the management packs as far as I have been able to determine.
12. Moving report subscriptions: Report subscription information uses SQL Reporting Services to deliver the reports and stores this information in the reporting database. For small numbers of report subscriptions, manually viewing each in the Operations Manager 2007 R2 environment and re-creating them in the Operations Manager 2012 R2 environment appears to be the best option. When moving scheduled reports, use the last execution date to determine what scheduled reports are still being used and check with the users to see if they are still using these reports before spending time moving them between your environments. For massive numbers of report subscriptions the following URL’s discuss a process which may work to move these but it may not as our goal is not to move the reports but only to move the subscriptions for the reports: http://sqlmag.com/sql-server-reporting-services/reporting-services-scripter, http://www.mssqltips.com/sqlservertip/2627/migrating-sql-reporting-services-to-a-new-server/.
13. Maintenance Mode: If you are using Tim McFadden’s remote maintenance mode scheduler utility (http://www.scom2k7.com/scom-remote-maintenance-mode-scheduler-20/) you will need to move the scheduled tasks between the environments. John Savill’s article has an article on copying scheduled tasks between machines which is available at http://windowsitpro.com/systems-management/how-can-i-move-or-copy-scheduled-tasks-between-machines. Additionally Tim has a new version of his utility which is available for 2012 for a nominal cost. Details are available at http://www.scom2k7.com/scom-2012-maintenance-mode-scheduler/.
14. Decommissioning Operations Manager 2007 R2: Once the Operations Manager 2012 R2 environment is functional, you can start to decommission the 2007 R2 environment by uninstalling the agents from the Operations Manager 2007 R2 environment (test this with a single agent first – it should remove the multi-home to the Operations Manager 2007 R2 environment, but leave the agent in place to communicate with the Operations Manager 2012 R2 environment). Once the agents have been decommissioned, the Operations Manager 2007 R2 servers can be decommissioned.
Overrides and multi-homed migrations: https://www.catapultsystems.com/cfuller/archive/2013/03/06/multi-homed-migrations-from-opsmgr-2007-r2-to-opsmgr-2012-and-overrides-scom-sysctr.aspx.