Freigeben über

How to Patch a Single SharePoint Farm With Minimal any Downtime

  • Artikel

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.

Two Farms are better than one

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).

image

In this setup the stages of this process are:

Remove a Server from Farm1

  • Move or start all roles & services not on SPServer1 that are on SPServer2.
    • If only SPServer2 serviced user profile applications for example then you need to start the service on SPServer1 and that’s it.
    • For search you’ll need to move any topology components too with PowerShell.
  • Remove SPServer2 from the farm with the config-wizard or PSConfig (remove from the network-load-balancer if necessary 1st of course). Now SPFarm1 has just SPServer1 with all the roles on it.

image

Create Farm2

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.

  • Create a new SPFarm with SPServer2 with the configuration wizard.
    • You’ll need new databases for everything; use either unique names or another SQL Server instance.
    • Create just the SPFarm and service-applications.

Make a Copy of Content Databases

image

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.

  • At this point, we’ll need to put SPFarm1 in read-only mode if we’re not going to log-ship changes across to the other farm, because we’re about to...
  • Restore a copy of your content databases from SPFarm1 to SPFarm2.
    • Setup log-shipping from SPFarm1 to SPFarm2 if you want subsequent updates to propagate to the 2nd farm.
    • We don’t want users to realise they’ve been bumped to a whole new farm/installation; they’ll just think the current one is having “maintenance” – SharePoint displays a nice “the admins are tinkering, please bear with us” message for you in content-DB R/O mode.

image

…and now we’re ready for the magic…

Redirect Users to Farm2

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.

  • Redirect users from the web-application(s) on SPServer1 to SPServer2 via either DNS or an NLB change. Now SPFarm1 will have gone quiet and we can patch it with no stress.
    • Once confirmed nobody’s using SPFarm1 we need to suspend log-shipping to SPFarm2 to avoid sending the patched databases before we’ve patched the binaries on it (which would cause an epic outage).
    • Users won’t be able to add any data but importantly, “SharePoint” will be “online”.

Patch Farm1

image

Try and confirm everyone’s off farm1 1st – IIS/ULS logs are a good way but at a certain point farm1 should go idle.

  • Patch SPFarm1, all one server of it (or more servers if there are more) – the point is that we can run PSConfig to complete the upgrade as SPServer2 is logically part of it any more so we have a nice isolation.
  • Once SPFarm1 is patched & verified, switch users back to SPServer1 to enjoy a fully patch SPFarm in glorious read/write mode.

Patch Farm2 & Reconnect Server2 to Farm1

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.

image

  • Patch SPServer2 binaries (and SPFarm2 with PSConfig/wizard if you want to keep it).
  • Remove SPServer2 from SPFarm2 and re-add it to SPFarm1
  • Move back all the services you moved off SPServer2.
  • Pat yourself on the back for having orchestrated the most blip-free SharePoint upgrade of all time.

That’s it!

image

Congrats, Awesome SPAdmin!

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.

Comments

  • Anonymous
    January 26, 2016
    Nice Blog.. Thanks..