In Operations Manager 2007, Microsoft introduced the concept of the root management server, also known as the RMS. The RMS had a unique role among management servers, as it was the only one running the System Center Data Access Service and System Center Management Configuration services.
The Data Access Service provides database access for the console, enables viewing the current state of a monitored object, importing management packs, storing management packs, and storing management group configuration information. It also writes event, state, and performance counter information to the database. The Management Configuration service manages relationships and topology of the OpsMgr environment. In addition, the RMS is responsible for dependency monitors, availability calculations, notifications, and group calculations.
Basically, if the RMS is down, your management group isn’t very functional. The RMS is a single point of failure. This can be alleviated by clustering it or promoting another management server to the RMS should the RMS be unavailable, but it is not an optimal architecture.
Microsoft takes a different approach in Operations Manager 2012, and removes the
RMS role. Instead, there is a pool of management servers. The work previously performed by the RMS is managed by this pool, which is a logical grouping of multiple health services instances. In this peer-to-peer topology, all management servers act as equals. The workload is distributed across multiple management services. Should a management server in the pool become unavailable, its workload is moved elsewhere in the pool. This gives automatic fault tolerance and load balancing.
Operations Manager 2012 provides topology simplification by removing the RMS and introducing of the All Management Servers Pool. We look forward to its release!