Backing up the RMS encryption keys for System Center Operations Manager 2007

This excerpt from "System Center Operations Manager 2007 Unleashed" explains how to backup RMS encryption keys using the SecureStorageBackup tool, plus how to recover from losses.


System Center Operations Manager 2007 Unleashed  

This chapter excerpt from System Center Operations Manager 2007 Unleashed, by Kerrie Meyler, Cameron Fuller, John Joyner and Andy Dominey, is printed with permission from Sams Publishing, Copyright 2008.

Click here for the chapter download or purchase the entire book here.


Microsoft provides the SecureStorage Backup tool (SecureStorageBackup.exe) to back up the RMS encryption keys. The syntax is as follows:


SecureStorageBackup.exe <Backup|Restore><BackupFile>
Backup Backs up encryption keys to file specified as <BackupFile>
Restore Restores encryption keys stored from <BackupFile>
BackupFile Specifies file name where the keys will be backed up to and restored from

The SecureBackupStorage utility is located on the Operations Manager installation media in the \SupportTools folder and should be copied to the Operations Manager installation folder (%ProgramFiles%System Center Operations Manager 2007).

The following procedure backs up the encryption key:


  1. Log on to the RMS using an account that is a member of the Administrators group.
  2. Select Start → Run →; then type cmd, and click OK.
  3. At the command prompt, navigate to %ProgramFiles%\System Center Operations Manager 2007. The utility must be run from the OpsMgr installation directory. Remember, you must first copy this file from the installation media. NOTE: Directory for Running the SecureStorageBackup Utility -- If you do not run SecureStorageBackup.exe from the OpsMgr installation directory, you will get errors about dlls that are not registered.
  4. Back up the encryption keys by typing the following:
    SecureStorageBackup Backup c:\backups\BackupKey.bin
  5. You are prompted to enter a password (twice to confirm). This password is used for storage/retrieval, and must be at least eight characters.
  6. The encryption key is saved to the folder and file you specify (c:\backups\BackupKey.bin, in this example). Be sure to remember the retrieval password!

To restore the encryption keys, open a command prompt and navigate to the Operations Manager installation folder (%ProgramFiles%\System Center Operations Manager 2007), and execute SecureStorageBackup Restore <BackupFile>. You will be prompted to enter the retrieval password. Using the backup key file we created, the syntax for the restore command would be as follows:

SecureStorageBackup Restore c:\backups\BackupKey.bin

You can also use the SecureStorageBackup utility to move the RMS capability to another management server, which we discuss in the next section.

Recovering from a RMS Loss

The RMS has a unique role in an OpsMgr environment. Although you can have multiple management servers accepting data from agents, only the RMS communicates directly with the OpsMgr databases. Given the importance of this role, it is not only important to back up the RMS encryption keys (see the "Backing Up the RMS Encryption Keys section"), but also to be able to transfer the RMS role to another management server if this server will be unavailable for a period of time. This section discusses the steps to restore the RMS role to another management server, as follows:

  1. Confirm you have a working RMS and second management server. Figure 12.15 shows our RMS (Hydra) and a management server (DeathSting) in the Operations console.
  2. Copy the SecureStorageBackup.exe and ManagementServerConfigTool.exe utilities to the Operations Manager installation folder on the RMS (%ProgramFiles%\System Center Operations Manager 2007). These files are available on the Operations Manager installation media in the \SupportTools folder. For our environment, the RMS is Hydra.
  3. Run the SecureStorageBackup.exe tool, exporting the encryption keys file to a file share. The tool is run by opening a command prompt (Start → Run → and then type cmd), navigating to %ProgramFiles%\System Center Operations Manager 2007, and typing the following command:
    SecureStorageBackup Backup <BackupFile>
    where <BackupFile> is the shared path and filename of the backed up encryption key.
  4. You are prompted to enter a password (twice to confirm). This password is used for storage/retrieval, and must be at least eight characters.
  5. Be sure that the keys file is on a file share accessible from the other management server (DeathSting).
  6. Copy the SecureStorageBackup.exe and ManagementServerConfigTool.exe utilities to the Operations Manager installation folder on the other management server (%ProgramFiles%\System Center Operations Manager 2007). These files are available on the Operations Manager installation media in the \SupportTools folder.
  7. FIGURE 12.15

7.From the command prompt in the %ProgramFiles%\System Center Operations Manager 2007 folder, run the SecureStorageBackup.exe tool to restore the key, using the following syntax:

SecureStorageBackup Restore <BackupFile>

where <BackupFile> is the shared path and filename of the previously backed up encryption key. Enter the password you entered when you created the keyfile.

8. At the command prompt, run the ManagementServerConfigTool.exe utility to promote the management server:

ManagementServerConfigTool.exe PromoteRMS /DeleteExistingRMS:true

You will receive a warning message:

Running this tool can cause irreversible damage to your Operations Database.
Type Y to continue to promote the Management Server to become the Root Management Server.
  1. 9.Type Y (yes) to continue. The utility completes and displays the information in Figure 12.16.
  2. FIGURE 12.16

10. Restart the Health Service on the original RMS. From the command prompt window in step 3, type the following commands:

Net Stop OpsMgr Health Service
Net Start OpsMgr Health Service


11. On the newly promoted RMS, open the Operations console. You are prompted for the name of the new Root Management Server to connect to.

Figure 12.17 shows the server roles reversed. The original RMS server is now a management server and the management server is now the RMS.

The full syntax for the ManagementServerConfigTool is included in Chapter 10.

Other Components to Update After Moving the RMS

When you move the RMS to another management server, you will also need to update the Reporting Server and the Web Console Server with the new location of the RMS.

FIGURE 12.17

Perform the following steps on the Reporting Server:

  1. On the Reporting Server, navigate to %ProgramFiles% \Microsoft SQL Server\MSSQL.2\Reporting Services\ReportServer.
  2. Open the rsreportserver.config file using Notepad.
  3. Find the two entries for <ServerName> and change it to the new RMS name.

Now perform the following steps on the Web Console Server:

  1. On the Web Console Server, navigate to %ProgramFiles%\System Center Operations Manager 2007\Web Console.
  2. Open the Web.config file using Notepad.
  3. In the <configuration> section, find the following:

    <!--This is internal connection between the web server and the MOM server .-->
    <add key= "MOMServer" value=""/>

  4. Change the contents of value from the old RMS name (using the Fully Qualified Domain Name) to the new RMS name (specify the Fully Qualified Domain Name)— for example, value= "".

See KB article 555950 for additional information, at 555950.

The rsreportserver.config and web.config files will now contact the new RMS.

For pre-SP 1 OpsMgr 2007 environments, Microsoft confirms there are additional issues with promoting a management server to the RMS role, as the data warehouse processing is still on the old RMS after the promotion. The data warehouse operations code and promotion code have a "misunderstanding" such that the data warehouse operations are not moved to the new RMS. The synchronization process assumes the SDK is local, but it actually is not—as the RMS has moved and the SDK service is stopped on the old RMS. (The SDK service moves management pack information between the operational and data warehouse databases.)

There is no "easy" fix except for starting the SDK service on the old RMS, which takes care of the data transfer. Once SP 1 is in place, you can promote some other management server to be the RMS and then back to move your data warehouse processing to the real RMS.

Restoring a Clustered RMS

If your RMS is on a cluster, the disaster recovery process is a bit more interesting, as you will be reinstalling the RMS and the Operational database. The high-level recovery steps are as follows:

  1. Back up the Operations Manager database to a separate system (disk or tape). See the "Database Backups" section of this chapter for specific steps.
  2. Back up the RMS Encryption key, which we describe in the "Backing Up the RMS Encryption Keys" section.
  3. Create a new clustered RMS configuration in the same fashion as the previous management group:

    • Reinstall the Operations Database Server Component using the same management group name as was originally used.
    • Reinstall management servers on all cluster nodes.
    • Back up the new encryption key from the new RMS (this is the first cluster node on which a management server was installed), in order to create the new clustered RMS.
    • Restore the new encryption key on all the other cluster nodes.
    • Run the ManagementServerConfig.exe tool using the InstallCluster action (this tool is documented in Chapter 10).

      Specifying InstallCluster removes all the local changes on the cluster nodes that will compromise its recovery. Running this tool requires that all OpsMgr services are stopped on all management servers.


  4. Drop the new Operational database and restore the original database (see the "Database Restores" section for additional information).
  5. Restore the original encryption key on all cluster nodes using the SecureStorageBackup.exe tool.
  6. Using the Cluster Administrator, bring the clustered RMS back online.
  7. In SQL Server Management Studio, run the following query:
    SELECT is_broker_enabled FROM sys.databases WHERE name-'OperationsManager'
  8. If the returned value is "0," you will need to reset the broker service, using these SQL queries:

    Close SQL Management Studio and reopen it; then run this query:

  9. Restart the SQL services if they are stopped; then restart the SDK service.




This was first published in June 2008

Dig Deeper on Microsoft System Center



Find more PRO+ content and other member only offers, here.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:









  • VDI assessment guide

    Wait! Don't implement VDI technology until you know your goals and needs. A VDI assessment should consider the benefits of a VDI ...

  • Guide to calculating ROI from VDI

    Calculating ROI from VDI requires a solid VDI cost analysis. Consider ROI calculation models, storage costs and more to determine...

  • Keep the cost of VDI storage under control

    Layering, persona management tools and flash arrays help keep virtual desktop users happy and VDI storage costs down.