SCOM 2012 - RMS Emulator Role

I have had the question asked a few times recently, what does the RMS do?

So with that, I thought I would put together a little segment to lay out the highlights. The Root Management Server or RMS in 2007 and 2007R2 was the master monitoring server in the environment. It provided oversight to all the servers being monitored as well as the functionality of the other servers in the SCOM build out. In 2007 and 2007R2 the RMS was the key management server and the single point of failure within the SCOM. The only way to make this functionality highly available was to use clustering technology. Which ended up being a painful waste of system resources.

The RMS role has significantly changed with the release of SCOM 2012, Microsoft spent a lot of time talking to users as they were developing the System Center 2012 suite and this is one of the things they heard loud and clear. If the RMS goes down SCOM goes down. So in response to this the RMS role has been deprecated. It is now called RMSE or Root Management Server Emulator.

With the redesign of System Center 2012, Ops Manager will now utilize a pool of servers to co-manage all the functions that were done by the RMS server in 2007 and 2007R2. They will rely on one server in the pool, however, to manage and run the RMSE role. What the RMSE server does will vary depending on the types of application management packs that are installed in your environment.

What does the RMSE do?
It is important to understand what RMSE is and what it does in your SCOM infrastructure so you can successfully architect your System Center Operations Manager 2012 deployment correctly.

In short the RMSE runs the management pack functionality specifically targeted to the Root Management Server class in 2012. For the most part these would be legacy management packs, i.e. 2007 and 2007R2 that have not been upgraded to the new 2012 standard which does not target the RMS class.

The image below is from SCOM 2012. You can see that there are still a few management packs that still rely on the RMSE functionality to run properly. In this example you can see that Active Directory and Exchange 2007 roles still need RMSE to operate.

You can determine which MP's you have in your environment depend on RMSE by going to the Authoring space, Click on Management Pack Objects then Object Discoveries. Do a Find on root management server and it will filter all the MP's you have that still use it.

This will be the complete list of MP's that will stop functioning in the event of a failure or the loss of the RMSE server. Fortunately if you have architected your 2012 environment with at least two pool servers (which I would never recommend less than two), you can easily promote the other server to the RMSE role and resume normal monitoring until the primary RMSE server can be brought back online.

Recovering From Disaster:
In the event of a failure or total loss of the RMSE server you can follow the steps provided to promote another server to the RMSE role.

1. Open Operations Manager Shell, Start > All Programs > Microsoft System Center 2012 > Operations Manager Shell and run the following command

Get-SCOMManagementServer -Name "FQDN of the new RMSE Server" | Set-SCOMRMSEmulator

2. Build a new server with the same IP address and FQDN of the original RMSE server
3. Delete the origional RMSE server from SCOM in the Managment Servers list under the Administration space > Device Management. 
4. Install SCOM 2012 as outlined in SCOM 2012 - Installing Additional Management Servers
5. Promote the RMSE role back to the original box as outlined in Step 1

More to come!