This is a common practice for rotating old physical servers coming off lease, or when moving VM based management servers to a new operating system.
There are some generic instructions on TechNet here: https://technet.microsoft.com/en-us/library/hh456439.aspx however, these don’t really paint the whole picture of what all should be checked first. Customers sometimes run into orphaned objects, or management servers they cannot delete because the MS is hosting remote monitoring activities.
Here is a checklist I have put together, the steps are not necessarily enforced in this order… so you can rearrange much of this as you see fit.
- Install new management server(s)
- Configure any registry modifications in place on existing management servers for the new MS
- Patch new MS with current UR to bring parity with other management servers in the management group.
- If you have gateways reporting to old management servers, install certificates from the same trusted publisher on the new MS, and then use PowerShell to change GW to MS assignments.
- Inspect Resource pools. Make sure old management server is removed from any Resource pools with manual membership, and place new management servers in those resource pools.
- If you have any 3rd party service installations, ensure they are installed as needed on new MS (connector services, hardware monitoring add-ons.
- If you have any hard coded script or EXE paths in place for notifications or scheduled tasks, ensure those are moved.
- If you run the Exchange 2010 Correlation engine – ensure it is moved to a new MS.
- If you use any URL watcher nodes hard coded to a management server – ensure those are moved to a new MS. (Web Transaction Monitoring)
- If you have any other watcher nodes – migrate those templates (OLEDB probe, port, etc.)
- If you have any custom registry keys in place on a MS, to discover it as a custom class for any reason, ensure these are migrated.
- If you have any special roles, such as the RMSe - migrate them.
- Ensure the new MS will host optional roles such as web console or console roles if required.
- Migrate any agent assignments in the console or AD integration.
- Ensure you have BOTH management servers online for a considerable time to allow all agents to get updated config – otherwise you will orphan the agents until they know about the new management server.
- If you perform UNIX/LINUX monitoring, these should migrate with resource pools. You will need to import and export SCX certs for the new management servers that will take part in the pool.
- If you use IM notifications, ensure the prerequisites are installed on the new MS.
- Ensure any new management servers are allowed to send email notifications to your SMTP server if it uses an access list.
- If you have any network devices, ensure the discovery is moved to another MS for any MS that is being removed.
- If you are using AEM, ensure this role is reconfigured for any retiring MS.
- If you are using ACS and the collector role needs to be migrated, perform this and update the forwarders to their new collector.
- If you have customized heartbeat settings for the management server, ensure this consistent.
- If you have any agentless monitored systems (rare) move their proxy server.
- If you were running a hardware load balancer for the SDK service connections – remove the old management servers and add new ones.
- Review event logs on new management servers and ensure there aren't any major health issues.
- Uninstall old management server gracefully.
- Delete management server object in console if required post-uninstall.
If you have any additional steps you feel should be part of this list – feel free to comment.