I was talking with @ShayneRarma today about High Availability of SCSM Management servers and separating Management server across geographic locations and having users connect to their local Management server for improved performance.
Makes sense right?
You have an office in Sydney and one in Adelaide and you want Sydney staff to connect to the Sydney Management server and Adelaide staff to connect to the Adelaide server, but if one of the goes down, everyone shifts to the other automatically.
My initial reaction was “No”.
Management servers just don’t work like that. They are dedicated instances and you manually connect to one or the other. This is hard coded when you manually connect to the server. If you want to change it you have to manually connect to the new server.
SCSM is not designed to be in a Cluster so can’t use typical Microsoft solutions to achieve this.
Even if you could somehow cluster them together the y would both be running the Workflow services and cause all sorts of mischief.
This was until @ShayneRarma started to describe how he approached the idea. Using Citrix Netscalers to take over the console connection.
How would this work:
A client console would connect to a friendly name for the SCSM Console via the Citrix Netscaler via port 5724 which is the default port that the console connects over.
The Netscaler would then ping each of the Management Servers and connect the console to the lowest ping server. This way no matter where the user was they would connect to the best network connected server possible. If one goes down, then the only one remaining would be the fastest.
Simple and genius!
@ShayneRarma has detailed the exact settings to use over on his blog here: https://scucnewcastle.wordpress.com/2015/10/21/configure-service-manager-2012-r2-management-servers-in-ha-with-citrix-netscalers/
Marcel Zehner also has documented a similar solution using Microsoft Network load Balancers here: http://marcelzehner.ch/2012/07/08/dealing-with-multiple-management-servers-23-load-balance-management-servers/
While that solves the console issue it still does not solve the Workflow Server.
The answer, again, is simple. The first Management server in any Management group processes all workflows. Any subsequent Management servers do not process workflows.
Have the server that processes workflows monitored and have an automated task to reassign the workflow service if the workflow server is not available.
Even if this last step is a manual one it is not difficult or time consuming to enable or disable the workflow server.
How do I tell which Management Server is my Workflow Server?
Sometimes you may come in to an environment that you do not know which Management server was installed first and therefore are unable to determine which Management server is processing workflows.
To find out, head to the ServiceManager database and run the following query:
select DisplayName, [PrincipalName] from [MTV_Computer]