Scripted provisioning of multiple Central Admin web applications

After reading some other posts about setting up the SharePoint Central Admin Web Application on multiple servers I thought it would be useful to post just a little more information on the topic.

The From the Field blog covered this topic really well. I then read a post by Spence Harbar on Central Admin high availability, load balancing, security and general recommendations. You must read that one!

My day to day work has recently had a focus on automating the deployment of SharePoint farms. So in the spirit of automation, here's how to approach the basic provisioning of Central Admin (CA) on multiple servers in a SharePoint farm.

Farm Topology
Server1: CA, Web App (WFE)
Server2: Indexer
Server3: Web App (WFE), Query
Server4: Web App (WFE), Query

Server3 and Server4: NLB

You have CA provisioned on Server1 (http://server1:1234) and you'd like to provision CA on Server2 (http://server2:1234) for redundancy.

Quick Answer
Logged on to Server2 cmd line, run the following commands:

psconfig -cmd adminvs -provision -port 1234 –windowsauthprovider onlyusentlm

stsadm -o deletealternatedomain -incomingurl http://server1:1234

stsadm -o addalternatedomain -url http://server2:1234 –incomingurl http://server1:1234 -urlzone intranet


Now you can browse to either http://server1:1234 or http://server2:1234 and you'll have a CA web application.

Note: Here’s where my experience has differed from other posts on this topic. If you launch SharePoint Central Administration from the "Start > Program Files..." shortcut you will always go to http://server2:1234   i.e. the last CA wins, it’s the one that gets put in the registry on all servers.  This is because others start the CA service on a new server via the existing CA web page, whereas I provision the CA on the new server by using the above psconfig command.

I encourage admins to script their tasks where ever possible as it leaves a clear record of the action taken. Provisioning a redundant CA will most likely be done as a part of the initial farm build, in which case you should definitely be scripting the farm configuration.

Some more information 
After running through the commands above you're left with the most recent CA server being the "primary" CA. What I mean by “primary” is that every server in the SharePoint farm now has a registry entry for THE CA server and it points to the new one (Server2).

Why is this?

Well it makes sense.  If you have CA running on a single machine and it goes down, you'll want to put the CA on another server in the farm. 

After installing the CA on the new server SharePoint updates all servers in the farm and says "hey... this new server is THE CA, forget about the old one".  If it didn't do that you would need to manually update every server in the farm so it no longer points to the non-existant, original, CA server (the dead one).

But what if you want to add CA to another server in the farm for redundancy but you still want the original CA server to be the "primary" CA, the one in the registry and hence the one that the link in the Start menu takes you to?

Well, you can do it a few ways:
1. You can modify the registry on all servers currently in the SharePoint farm. The problem is that when you add a new server to the farm it's registry entry will still point to the latest CA server.
2. You can unprovision CA from your original server and then provision it again, making it the latest CA server added and therefore the one in the registry and start menu on every server in the farm.

I like number 2.  It's an extra few commands to run in the command line, but it does the job well and handles new servers being added to the farm in the future.

Given that I usually have a SharePoint Admins team site with links to the Central Admin web applications directly, I don’t feel the need to have the registry updated on each server running CA to point to it’s own url.  My second CA in the farm is just there in case something happens to my primary CA server.  If it goes down I’ll browse directly to the second url. I don’t need the start menu link.  You may work differently.

Wrapping up
So, read the two great posts I mentioned at the beginning and then put the commands above into a script to get the job done. Test it and refine the scripts until they fit your own scenario.