In OM2007R2, we have introduced two new complex deployment scenarios we did not support in OM2007SP1. I am going to take a few minutes here and outline the new scenarios and procedures.
Adding Clustered RMS to an Existing Deployment
In OM2007SP1, clustering a Root Management Server (RMS) was only supported during the initial deployment of a management group. If you were to install a clustered RMS you needed to do this as the very first thing after deploying the first management server. If you later decided to cluster RMS (after you have deployed agents) the ManagementServerConfigTool would detect every Health Service in the management group and add them to the RMS cluster in the Operational Database. Basically, leaving your management group in a broken state. At this point,you would be forced to restore from backup.
In OM2007R2, we have made some changes to the ManagementServerConfigTool to support adding a new RMS cluster to an existing management group.
What we have done here is added two new management server to the management group, setup the RMS cluster group, and ran our ManagementServerConfigTool with the “InstallCluster” switch.
Backup the OM DB
Setup Cluster Disk, IP and Network Name
Install OM R2 Management Server on all Nodes
Restore encryption on all nodes
Create cluster service resources (HS, CS, SDK) (Leave resources offline)
On active node set config and sdk services to manual
On active node, run ManagementServerConfigTool w\ “InstallCluster” switch
This will demote the existing RMS to a MS during the process.
All agents and management servers reporting to the existing RMS will be redirected to the new clustered RMS. If you are planning on keeping the old RMS as a MS you should redirect all agents back . Gateway assignment will not change.
If creating a new RMS cluster where the current RMS is x64 and the new RMS cluster will be x86. You will need to manually demote the x64 RMS. (this will be rare). You will receive instructions from the managementserverconfitool with the command you will need to run.
If your current RMS OMSDK or OMCFG account is “Local System” you will need to switch to using a domain account before proceeding with adding the RMS Cluster.
On the new server hosting the OperationsManager database, add the correct permission for the login of the root management server on which the SDK Account is running, as follows:
Open Microsoft SQL Server Management Studio, and in the
pane, navigate to
and then expand
and add the account if it is not listed.
, and select
dialog box, in the
Select a page
Users mapped to this login
list, in the
column, select the box that corresponds to
Database role membership for: OperationsManager
list, ensure that the following items are selected:
to save your changes and to close the
Recycle RMS Health Service
Before you can use discovery, you must restart the following services: System Center Data Access, System Center Management Configuration, and System Center Management Services. You might also need to restart the following services: SQL Server and SQL Server Agent.
Below I have highlighted some of the most common unsupported scenarios. If your scenario does not match the one highlighted above it is not supported.
Upgrading SQL From SQL Server 2005 to SQL Server 2008
In OM2007R2, we are supporting a new installation of OM on SQL 2008 as well as upgrading your SQL 2005 Server to SQL Server 2008.
Upgrade all OM DB roles to OM2007R2 (OMDB, OMDW, ACSDB, OM Reporting)
Backup all DB’s
Upgrade Operational DB to SQL 2008 with SP1
Upgrade OM DW to SQL 2008 with SP1
Upgrade ACS DB to SQL 2008 with SP1
Upgrade OM Reporting according to the instructions in the
Note: Reporting is the only role that requires following a set of procedures
New Tools for Reporting upgrade:
This does a basic config file restore and registry updates of SCOM Reporting’s MSI components. This tool has to run before and after SQL instance upgrade.
This tool needs to be run after the SQL 2008 upgrade is complete and you have run the SRSUpgradeTool tool with the “postSQLUpgrade” switch
Reporting Upgrade Procedure:
Run the SRSUpgradeTool with the “PreSQLUpgrade” switch
This will basically restore the three config files we backed up during the initial installation of OM. This is necessary because SQL 2008 install detects are custom security extensions and blocks upgrade until they are removed
Upgrade to SQL 2008
Note: Do not apply SP1 of SQL 2008 our tool will not run on SP1
Once SQL Upgrade is complete, run SRSUpgradeTool with the “PostSQLUpgrade” switch
This will update the registry entries for installed components of OM reporting to point to new SRS folder location
Run SRSUpgradeHelper.msi tool to place the OM reporting related files on new SRS folder and set the SRS configuration
Upgrade to SQL 2008 SP1 (Remember to apply SP1 of SQL 2008, SQL fixed some report rendering issues for us in this service pack)
Rob Kuehfus | System Center Operations Manager | Program Manager