Mind you all these steps take place AFTER the new SCOM Management Server is installed. Also good to know, this To Do List is based on OM12 SP1.
A BIG word of thanks to Bob Cornellissen for updating this posting with many new items for this list.
- Antivirus exclusions
Please make sure the new SCOM Management Server uses the same AV policy as the other SCOM Management Server. So the correct folders and processes are excluded from AV scans. Check KB975931 for more information.
When using Gateway Servers and/or monitoring servers using certificates, make sure the new SCOM Management Server gets a valid certificate as well. And don’t forget to configure it properly.
Make sure all the firewalls, either running on your Windows Server hosting the new SCOM Management Server role and the dedicated network firewalls, accept the traffic coming from the new SCOM Management Server. Also read this posting of my fellow MVP buddy Bob Cornelissen since it might prevent a lot of hassle.
- Resource Pools
Make sure the new SCOM Management Server is added to the proper Resource Pools so it adheres to the original design.
- UNIX/Linux monitoring
When monitoring UNIX/Linux systems and the new SCOM Management Server will become a member of that Resource Pool, make sure it has the proper certificates in place. Not only its own certificate but also the certificates of all the other Resource Pool members. Also the other Resource Pool members must get the certificate of the new SCOM Management Server as well. Kevin Holman wrote an excellent posting about it, to be found here. Look for the header Configure the Xplat certificates.
- Special MPs
Sometimes special MPs are in place, requiring additional actions on the new SCOM Management Servers. Examples are the NetApp MP, SharePoint 2013 MP.
- Console extensions
Some third party tools extend the SCOM Console, like Savision Live Maps. So install those Console extensions on the new SCOM Management Servers as well.
- Registry and/or config file modifications
If you have implemented custom registry or config file settings on your management servers, don’t forget to implement those as well. Often it is advisable or required to have these settings the same on all management servers in the resource pool or management group.
- Run As Accounts & their related Run As Profiles
It could be that certain runas accounts are set to more secure distribution and you had selected the initial Management Server(s). If so make sure you add the new Management Server as well to the distribution of such accounts.
- Custom scripts modifications
If you are using custom scripts running on management servers for custom monitoring or command based notification channels, remember to copy those to the new management servers.
- Custom MP modifications
You could have custom management packs, such as Backup Unsealed MP’s, which are set to backup to a directory on disk. In these kind of cases confirm that files and directories exist and that overrides which were set to target specific management servers are also applied to the new management servers if applicable. There could be some overrides you have made in management packs which target specific management servers. These need to be evaluated if those are needed on the new Management Server as well.
- Custom monitoring modifications
Check other custom monitoring you have implemented that uses certain management servers as monitoring agents, such as web page checks. Of course only in case you want the new server to do the same kind of workflows, or if a new management server is eventually going to replace an existing one.
This covers it all and enables you to enroll successfully an additional SCOM Management Server to an existing MG without bumping into issues after it.