New R2 Deployment Complex Scenarios (Adding Clustered RMS and Upgrading to SQL 2008)

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. 

Supported

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.

Procedure:

1. Backup the OM DB
2. Setup Cluster Disk, IP and Network Name
3. Install OM R2 Management Server on all Nodes
4. Restore encryption on all nodes
5. Create cluster service resources (HS, CS, SDK) (Leave resources offline)
6. On active node set config and sdk services to manual
7. On active node, run ManagementServerConfigTool w\ “InstallCluster” switch

Note: Go here for detailed instructions on creating the RMS cluster group.
Note 2: If OM Reporting is installed to redirect it to the new RMS cluster see the following article - http://technet.microsoft.com/en-us/library/cc540401.aspx

Additional Info:

A Few things to note:

• 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.

Known Issues:

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:

1. Open Microsoft SQL Server Management Studio, and in the Object Explorer pane, navigate to Security and then expand Logins.
2. Locate the SDK Account, and add the account if it is not listed.
3. Right-click the SDK Account, and select Properties.
4. In the Login Properties dialog box, in the Select a page pane, select User Mapping.
5. In the Users mapped to this login list, in the Map column, select the box that corresponds to OperationsManager (default name).
6. In the Database role membership for: OperationsManager list, ensure that the following items are selected: configsvc_users, db_datareader, db_datawriter, db_ddladmin, and sdk_users.
7. Click OK to save your changes and to close the Login Properties dialog box.
8. Recycle RMS Health Service

Note

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.

Unsupported:

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 order:

1. Upgrade all OM DB roles to OM2007R2 (OMDB, OMDW, ACSDB, OM Reporting)
2. Backup all DB’s
3. Upgrade Operational DB to SQL 2008 with SP1
4. Upgrade OM DW to SQL 2008 with SP1
5. Upgrade ACS DB to SQL 2008 with SP1
6. Upgrade OM Reporting according to the instructions in the upgrade guide, (Note: Reporting is the only role that requires following a set of procedures)

New Tools for Reporting upgrade:

• SRSUpgradeTool.exe
• 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.
• SRSUpgradeHelper.msi
• 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:

1. Run the SRSUpgradeTool with the “PreSQLUpgrade” switch
1. 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
2. Upgrade to SQL 2008
   Note: Do not apply SP1 of SQL 2008 our tool will not run on SP1
3. Once SQL Upgrade is complete, run SRSUpgradeTool with the “PostSQLUpgrade” switch
1. This will update the registry entries for installed components of OM reporting to point to new SRS folder location
4. Run SRSUpgradeHelper.msi tool to place the OM reporting related files on new SRS folder and set the SRS configuration
5. 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

Disclaimer:

This posting is provided "AS IS" with no warranties.
Use of included tools and reports are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm