Today was the third SCOM 2012 CEP meeting.
I will list some notes I took during the meeting. It doesn’t cover everything, but of course the recording will be available soon.
Nishtha Soni and Rob Kuehfus were presenting again.
High Availability
The RMS is no more. So no need to cluster anymore either for high availability or to manually move the RMS role to another MS. No parent-child model for RMS to MS anymore.
Config service
runs on all mgmt servers.
store config data in db in stead of memory.
faster startup.
smaller demand on local resources.
sdk service
runs on all mgmt severs.
scom console can connect to any MS.
Resource Pools
There is a notifications resource pool that authomatically contains all management servers, but this can be changed.
For cross plat agents it is possible to change an agent to another resource pool from the admin pane in scom.
.\GetUXMonPool.ps1 “nameofpool”
Will show which agents are linked to which pool members. Can show you what happens if you turn off a MS from a resource pool.
RMS Emulator
Workflows that are targetted to the RMS.
The RMS Emulator role got added on one of the management servers. There are powershell commandlets to find, change and remove the role. Get-SCOMRMSEmulator Set-SCOMRMSEmulator and Remove-SCOMRMSEmulator
Product team is looking into ways to make moving of RMS emulator an automatic process if something goes wrong with the RMS Emulator through a management pack they will provide in a few weeks.
Maintenance mode:
Workflows and agents running on a Management Server are failed over to another MS when it is put in maintenance mode.
Removing an MS from MM is more reliable.
Best practice is to never place more then 50% of your management servers into maintenance mode at once.
High availability with scom 2012
Reduces TCO and deployment friction.
Increases scale and simplicity
Out of the box high availability
Homework
Build management group with separate SQL server and two management servers. Place agent on the database server. Import the internal tasks mp from the \\cdimage\support tools\amd64 folder.
Validating the resource pool. There is a resource pool watcher where you can target the discovered inventory to (and you can create a state view for this as well).
Rob has us make a service monitor for the print spooler service through the Windows Service management pack templates in the Authoring pane of the SCOM console.
Rob shows us the notification channels. Through the show running rules and monitors task when running it against the management server you can see if it running the notification service or not (and which server of course).
SCOM admin pane. Resource pools. Notification resource pool. If you want to force notifications to one MS you can change membership to manual on that resource pool. Next you remove the MS from that pool that you dont want it to run notifications.
It is possible to use a runas account for notifications as well.
Dependency monitors.
They used to get calculated at the RMS. Now the RMS is no longer needed for this to work. You can try this by shutting down one of the management servers.
Task validations and validations that with one MS turned off everything still works.
FAQ
Load gets balanced throughout the resource pool. Size per workload is not taken into account in this. All members are treated equally. SCOM takes care of this. Hardware and strength of server is not taken into account with this algorithm. When a MS comes back from down state the load will be distributed to that machine as well.
RMS Emulator. If it is down and you have workloads targetting the RMS those will have problems with those workflows. RMS Emulator role failover will be made in a MP coming from the product team in about 6 weeks time
Gateway server resource pools are possible as well.
After answering some questions this was the end of the session.
The next meeting is on 20 September and covers the subject of Dashboards.
Hope to see you next time!
Bob Cornelissen