OpsMgr 2007 introduced the concept of a Root Management Server and Secondary Management Servers. In OpsMgr2007 the RMS comprised 3 services providing the following functionality:

1) SDK Service

• Console access and role based access control
• Connectors to other management systems

2)Health Service

• Notifications
• Group Calculations
• Availability
• Dependency Monitor
• Health aggregation
• DB Grooming

3) Configuration Service

• Distribution of configurations to agents

The RMS was both a single point of failure and a potential bottleneck.

In SCOM 2012 the Root Management Server was removed but an RMS Emulator role (RMSE) has been retained. These seem to be logical next-step questions to ask based upon the new RMSE:

• What do we know about the RMS Emulator?
• Does the RMS Emulator do all of the same items that the RMS originally provided?
• Are there other things we should be aware of related to resource pools?
• What classes should be used to target instead of using the RootManagementServer class?

Questions/answers below to these are below:

What do we know about the RMS Emulator?

The RMS Emulator Role is assigned to the first Management Server installed in the management group. This role can be moved to another Management Server using PowerShell:

• To find out the current RMS Emulator – Get-SCOMRMSEmulator
• To move the RMS Emulator role, you need to use the Set-SCOMRMSEmulator

§ Get-SCOMManagementServer –Name <New RMS Emulator> | Set-SCOMRMSEmulator

From – http://blogs.technet.com/b/momteam/archive/2011/08/22/topology-changes-in-system-center-2012-operations-manager-overview.aspx – In order for us to not to break backwards compatibility and provide support for legacy management packs we decided to leave the Root Management Server instance and add a special role to one of the management servers in the Management group called the RMS Emulator. This RMS Emulator is only for backwards compatibility to legacy management packs and is in no way required for the management group to function correctly.” An example of a management pack which contains a workflow which would require the RMS Emulator is shown below:

The RMS Emulator Role is only necessary to trick those workflows that were targeted to the RMS into thinking that the RMS still exists.

Subset from http://blogs.technet.com/b/momteam/archive/2011/08/22/topology-changes-in-system-center-2012-operations-manager-overview.aspx “At this point you may be wondering about workflows targeted to the RMS that are outside of the OpsMgr product groups control (other management packs from different Microsoft teams or third party vendors). They have all been moved to target Resource Pools OR singleton objects (that also live in the “all management servers” pool). Other applications management packs or custom management packs might still want to find that object, and that is the only reason why this object exists. The OpsMgr management packs don’t target the RMS object anymore which brings us onto Resource Pools.

Does the RMS Emulator do all of the same items that the RMS originally provided?

The majority of the services previously provided by the RMS can now be performed by any management server and as a result inherently provide redundancy when multiple management servers exist in the appropriate management server resource pool.

The services which were previously managed by the RMS are listed below with their new homes:

· Console access: Role based access control is done by ANY SDK Service when you connect to it. Any management server although you can control which management server (as with some other SDK activity) via Load Balancing. To use load balancing provide users with the virtual name of the Management Server load-balancing pool and just add management servers into and out of the resource pool on the load balancer.

· Role based access control: Role based access control is done by ANY SDK Service when you connect to it

· Distribution of configurations to agents: Distribution of configurations to agents is done by any MS for its agents (“federated config service”)

· Connectors to other mgmt systems: Connectors to other mgmt systems can “talk to” any MS they like – like consoles

· Alert notifications: Alert notifications is a workflow, runs in a pool [Notifications Resource Pool]

· Group Calculations: Group Calculations is a workflow, runs in pools and or distributed across MS’s depending on which MS owns which group/container [All Management Servers Resource Pool]

· Availability: Availability – runs distributed as usual – pieces on the agent, pieces on the MS’s, depending on which MS owns which group/container/singleton object [All Management Servers Resource Pool]

· Dependency Monitor: Dependency Monitor – runs where the corresponding objects live… on one of the servers in the “all management servers” pool

· Health aggregation: Health aggregation is a workflow, runs in pools and or distributed across MS’s depending on which MS owns which container [All Management Servers Resource Pool]

· DB Grooming: DB Grooming – runs in a pool [All Management Servers Resource Pool]

· Enables model based mgmt: While the RMS handed some of the model based management

Are there other things we should be aware of related to resource pools?

· Resource pools only cover Health Service functionality.

· Resource pools do not cover Config service – There is now a distributed configuration with a Configuration Service on every management server. Failover and assignment works as it did in OpsMgr 2007 R2.

<side-bar of extra cool OpsMgr goodness

The config service was rewritten almost from scratch. It has a new service name – the original was OMCFG and the new is CSHOST. The data is now federated among management servers, all contributing to the configuration. A new set of tables were created in the OpsDB (CS.*) to persist the instance space (as opposed to having it all in memory like the old config service did). The “new set of tables” is called the Configuration Store (hence the CS.* schema), and was initially meant to be a separate database, but was then collapsed into OpsDB after it was understood that it really would not impact performance to keep the two together – as it is one less DB to maintain and backup, so easier for the user.

</side-bar of extra cool OpsMgr goodness

· Resource Pools don’t cover SDK functionality which you demo by connecting to a management server or reporting through a console. If you stop the sdk service on the management server you are connected to then the console or reporting won’t failover to another management server. But you can leverage load balancing to achieve this.

What classes should be used to target instead of using the RootManagementServer class?

This will vary depending upon the requirements for the management pack which is being developed but primarily the Microsoft.SystemCenter.AllManagementServersPool class from the Microsoft.SystemCenter.Library management pack would be used for a ‘general’ server-based workflows. Another option is to create your own singleton class that “makes sense” for your application, and target that one. Many other workflows will need a different pool as a target (like a “user pools” or a pools for network device monitoring or a pool for Linux/Unix monitoring).

Summary: The RMS Emulator only provides backward compatibility to management pack using things which target the ‘Root Management Server’ class instance (Target=”SC!Microsoft.SystemCenter.RootManagementServer). The RMS emulator is hosted on a management server and as such it does a lot of activities that aren’t specific to the RMSE role. Everything else the RMS used to be responsible for is managed by the “All Management Servers Resource Pool”, the “Notifications Resource Pool” and the “AD Assignment Resource Pool”.

I owe a huge thanks to the entire OpsMgr MVP community for their assistance in dumbing this down to my level! Specific thanks to: (alphabetically since so many folks helped with this!)

• Alexey Zhuravlev
• Daniele Muscetta
• Gordon McKenna
• Graham Davies
• Łukasz Rutkowski
• Kerrie Meyler
• Marcus Oh
• Marnix Wolf
• Yann Gainche