SCOM 2012: What’s new: Maintenance mode changes

This post is part of a series What’s new: Check here for the other parts.

In the second part of this series of what’s new in SCOM2012 I’ll be highlighting a small change with big implications in SCOM 2012 in the maintenance mode department.

image_2It was kind of frustrating to see that a lot of issues at customer sites had to do with the fact that the RMS or MS (or even worse both) were put in maintenance mode and never came out of it until manually removed.

Putting your RMS in maintenance mode is a big no no as this is the pounding heart of your environment and can cause serious issues.

But hey enough said about the past… let’s talk about the future! Fortunately the future is bright in the SOCM 2012 world concerning maintenance mode.

These are in fact the changes in maintenance mode:

  • When a management server in SCOM 2012 (remember no more RMS) is placed in maintenance mode the System Center Management Configuration Service will act up and make sure that the agents are forced to failover to another management server so no data loss will occur. This is of course possible by bundling the management servers in resource pools.
  • The far most important change in maintenance mode is the fact that when you put a management server in maintenance mode the workflow to get that particular management server out of maintenance mode is actually moved to another management server which is not in maintenance mode. This way the command to get the server out of maintenance mode is triggered from another server. Finally…

Why is this such a huge improvement?

In SCOOM2007R2 if you for one reason or another find your RMS in maintenance mode the workflow to actually get it out of maintenance mode was also fired from the RMS. Which of course will not fire because… yeah it’s in maintenance mode. This can keep your RMS in maintenance mode without you even knowing it. The only possible way to get it out is to manually remove the maintenance mode.

So this is resolved in SCOM2012 by moving the workflow to get the management server out of maintenance mode to another management server in the resource pool. Another cool feature of the resource pools where the different management servers are residing in.

The only catch is that to have this new approach working you’ll need at least 50% of your management servers out of maintenance mode. So take this in account when you decide on update strategies to divide your management servers in at least 2 different patch groups with different action times.

Enough talk, let’s build
Something together.