Latest posts by Paul Schnackenburg (see all)
- Project Honolulu - A new way to manage Windows Server - Wed, Nov 22 2017
- Use Azure Managed Service Identity (MSI) to store passwords in your code securely - Thu, Nov 9 2017
- Azure Data Lake overview - Fri, Sep 22 2017
Root Management Server (RMS) in SCOM 2007 ^
Because of the unique role that the RMS plays in SCOM 2007 R2 it’s a single point of failure. It’s the connection point for consoles / web consoles, it runs the configuration service, it handles connectors and health aggregation as well as role based access control. The way to build High Availability (HA) in SCOM 2007 R2 is to cluster the RMS server which is operationally and technically complex and also relies on an active / passive model with the associated hardware and licensing costs. There’s also the option to manual promote a secondary management server to RMS in a disaster situation but this isn’t straightforward.
SCOM 2012 high availability ^
SCOM 2012 changes the game by doing what Exchange and other Microsoft applications have already done by providing HA out of the box. Management servers are pooled and automatically share the load, no server is more important than any other and simply by having several of them availability is ensured. Each server runs the configuration service and they store their data in the database instead of in an XML configuration file / memory like SCOM 2007 R2 did (this file could be up to several GB in large environments), leading to quicker start-up of each management server.
Failover is not instantaneous and it can take up to two minutes whilst the pool reloads managed instances. All management servers should be located in the same datacentre (less than 5ms latency) and you should deploy Gateway servers in other locations. These servers connect SCOM to branch offices or untrusted domains and can also be in resource pools but you can’t mix Management and Gateway servers in the same pool.
In SCOM 2007 R2 the RMS has special characteristics and some current management packs (Exchange 2007 and 2010 are examples, a full list is forthcoming from Microsoft) rely on a RMS to report to. Since there isn’t an RMS server in SCOM 2012 one management server is assigned the RMS Emulator role to provide compatibility with these MPs. This role can be manually moved between management servers (using the PowerShell cmdlet Set-SCOMRMSEmulator) and there’s a management pack coming that will automate the failover of the role. Management Groups don’t rely on the RMS emulator; it’s there for backwards compatibility with MPs.
SCOM 2012 Resource Pool ^
Know that all management servers are treated as having equal capacity; differences in processors and memory capacity are not taken into account so it’s best to plan on having all servers identical. Different workloads are also not taken into account and are simply distributed amongst the available servers in a pool. There’s are three default pools ; All Management Server Resource Pool, the Notification Pool and an AD Integration pool but you can create your own pools for specific monitoring situations.
The three built in Resource Pools
Roles within a pool can be manually controlled, this is suitable for instance if you have a hardware text/SMS alerting device connected to a particular management server, there’s no point in failing that function over to a server without the hardware attached. Cross platform (Unix/Linux) monitoring and network device monitoring is also targeted at pools rather than individual management servers.
SCOM 2012 maintenance mode ^
An issue in SCOM 2007 R2 is when you put a management server into maintenance mode, because the workflow to take the server out of maintenance mode after the designated time is also running on that server it never automatically comes out of maintenance mode, in SCOM 2012 the workflow is moved to the All Management Servers resource pool negating the need to manually take a server out of maintenance mode.
The new Silverlight based web console is your friend when you’re away from your monitoring station.
The new home on the web for all management packs is http://systemcenter.pinpoint.microsoft.com and for those who’ve been less than impressed by the Pinpoint site and finding management packs in the past it’s good to know that the above address is focused solely on System Center.
In the next part of this SCOM 2012 RC technical review series we’ll look at my favourite new feature: Network Monitoring, what’s required and how it works.