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 |
| Real World—Always Back Up Encryption Keys! |
| If you lose your RMS and have not backed up the encryption keys, you must reinstall
the RMS and your management group (Service Pack 1 incorporates some relief for this,
see the "Recovering from a RMS Loss" section).
Also, be aware that after you upgrade your OpsMgr infrastructure to Service Pack 1,
your previous RMS key backups will not work. An organization in Texas testing the
service pack was bit by this when their RMS failed and the recovery did not work since
the keys were backed up from prior to SP 1!
Microsoft plans to make it easier to backup the RMS key after your SP 1 upgrade by
including a step in the upgrade wizard prompting you to do the backup at the end of
the upgrade. |
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:
- Log on to the RMS using an account that is a member of the Administrators group.
- Select Start → Run →; then type cmd, and click OK.
- 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.
- Back up the encryption keys by typing the following:
SecureStorageBackup Backup c:\backups\BackupKey.bin
- You are prompted to enter a password (twice to confirm). This password is used for
storage/retrieval, and must be at least eight characters.
- 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:
- 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.
- 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.
- 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.
- You are prompted to enter a password (twice to confirm). This password is used for
storage/retrieval, and must be at least eight characters.
- Be sure that the keys file is on a file share accessible from the other management
server (DeathSting).
- 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.
FIGURE 12.15
- 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.
- 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.
- Type Y (yes) to continue. The utility completes and displays the information in
Figure 12.16.
FIGURE 12.16
- 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
- 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.
| TIP |
Creating a New RMS Encryption Key with SP 1
With OpsMgr 2007 Service Pack 1, Microsoft includes a CREATE_NEWKEY command
line switch that allows you to recover a lost RMS without a backed up encryption key.
The switch is used when running MOM.msi on the management server that will
become the new RMS.
J.C. Hornbeck of Microsoft provides preliminary documentation about this switch at
http://blogs.technet.com/smsandmom/archive/2007/12/05/opsmgr-2007-what-if-ilose-
my-rms-encryption-key.aspx. You should still backup your encryption key, but this
new capability gives you a way to recover without having to rebuild. |
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:
- On the Reporting Server, navigate to %ProgramFiles% \Microsoft SQL
Server\MSSQL.2\Reporting Services\ReportServer.
- Open the rsreportserver.config file using Notepad.
- Find the two entries for <ServerName> and change it to the new RMS name.
Now perform the following steps on the Web Console Server:
- On the Web Console Server, navigate to %ProgramFiles%\System Center Operations
Manager 2007\Web Console.
- Open the Web.config file using Notepad.
- In the <configuration> section, find the following:
<!--This is internal connection between the web server and the MOM server .-->
<add key= "MOMServer" value="Hydra.Odyssey.com"/>
- 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= "DeathSting.Odyssey.com".
See KB article 555950 for additional information, at http://support.microsoft.com/kb/
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:
- Back up the Operations Manager database to a separate system (disk or tape). See the
"Database Backups" section of this chapter for specific steps.
- Back up the RMS Encryption key, which we describe in the "Backing Up the RMS
Encryption Keys" section.
- Create a new clustered RMS configuration in the same fashion as the previous
management group:
- Drop the new Operational database and restore the original database (see the
"Database Restores" section for additional information).
- Restore the original encryption key on all cluster nodes using the
SecureStorageBackup.exe tool.
- 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'
If the returned value is "0," you will need to reset the broker service, using these SQL
queries:
ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE OperationsManager SET ENABLE_BROKER
Close SQL Management Studio and reopen it; then run this query:
ALERT DATABASE OperationsManager SET MULTI_USER
- Restart the SQL services if they are stopped; then restart the SDK service.
Home: 
