Having already blogged about this subject, a question I frequently get asked is “how can I patch my [single] SharePoint farm with no or minimal down-time?”
Well let’s cut to the chase; it’s not possible to patch a SharePoint farm without any downtime, and the absolute minimum time you’re looking at is the time it takes PSConfig/”the config wizard” to patch all the SharePoint databases.
That said dear readers, that doesn’t mean we can’t do something, but that’s only assuming we have a minimum of x2 SharePoint in our single farm. If you only have the one SharePoint server, stop reading now or go build yourself another SharePoint server.
You might just have the one SharePoint farm but what we’re going to do will split those machines into two farms, as that’s kinda key to this whole trick working. For this example we’re going to pretend that we have one SPFarm (SPFarm1) made of two servers (SPServer1, SPServer2).
In this setup the stages of this process are:
Creating SharePoint “farms” is pretty trivial as a SharePoint farm is just technically a configuration database and presumably 1+ servers using it. We want a new fresh SPFarm, with all our service-applications on top, first of all.
Now let’s get our business data replicated to the secondary site as that’s what users will most visibly see. At a certain point users will have to use SharePoint in read-only mode as we don’t want to lose any changes they upload when we’re running off a temporary backup farm.
…and now we’re ready for the magic…
This bit will vary depending on how your farm is setup. Hopefully you’ll have some kind of network-load-balanced (NLB) IP address which we can drain-stop & start SharePoint WFE hosts in; there’ll of course be a second or two while this reconfigure happens during which the crossover isn’t complete but, well, advise users this might happen as it’s for the most part unavoidable without serious planning I don’t have time for here.
Try and confirm everyone’s off farm1 1st – IIS/ULS logs are a good way but at a certain point farm1 should go idle.
Having successfully patched farm1 & sent everyone back there, you now need to patch server2 at least, and probably farm2 also just in case you need it again, even if it will effectively be redundant. Without patching server2 binaries you won’t be able to add it back to farm1.
Well done on patching SharePoint without hacking off all your users! Sure this is a hassle if you’re not used to it but this could be easily scripted if you wanted a quicker turnaround. The point is that where there’s a will, there’s a way, and I’ve just give you a way J.