Smoother SharePoint Server Patching
Something that’s always been a challenge in SharePoint on-premises, and 2013 in particular is deploying patches across the farm. SharePoint patches, updates and service-packs typically take a literal age to install during which time whatever services that are in the farm will all have to come down eventually (in 2016 this is greatly improved). In short patching SharePoint is generally a nail-biting experience for any SharePoint admin whose job revolves around keeping SharePoint running.
There are some other workarounds too, like disabling services before upgrading but here’s a new take on how to mitigate the SharePoint patching pain. There are several options to help alleviate SharePoint patching stress:
Divide up SharePoint Farm into Smaller Interconnected Farms
I’m increasingly coming to the opinion that a heterogeneous, or “all in one” SharePoint farm is a bad idea for various reasons. In other words, SharePoint farms will all the services are bad and the upgrading experience is a perfect example why.
When you upgrade SharePoint it’s an all-or-nothing game; either all servers have to be on the same binary bits or nothing will work. Want to patch a search issue? That’ll mean patching user-profile servers, web-front-end servers, and all the others that are lumped into the same farm too. There’s no getting round it.
We have to patch all servers in the farm, regardless of whether the patch addresses services the server is running or providing. So…
Solution: have multiple farms that publish & consume services between them. That way you can roll-out your patches in stages to relieve the pressure a bit.
Not to mention, for backend patching you can build a failover farm to cover while your normal service farm is patching – switching between the two is a simple PowerShell script.
The point here is we don’t need to patch all SharePoint servers in order to be running a supported configuration; we can segment up the patches if we want, thus reducing the downtime.
Template SharePoint Server Virtual Machine
Patching a joined SharePoint server can take ages if services are running especially if you have to update server-by-server which is how it’s normally done.
Solution: destroy & recreate the SharePoint servers from an updated template image.
This is quite the nuclear option and it’s not possible with anything search-service related but it can save a lot of time. The idea is you have a sys-prepped template virtual-machine that you use to create your SharePoint servers from. When a new patch is released, you fire up the template; patch it, and then sys-prep it again. The existing servers are then disconnected & destroyed with new servers created from the server image & connected to the farm.
At some point the farm will need upgrading but you’ve basically skipped over the binary installation pain – patching a single disconnected SharePoint server is much lighter work that patching each & every active member of a SharePoint farm.
Again, don’t try with search-servers as reconfiguring a search service application without the original search admin component/server is just not something I would recommend, or am even sure is possible for that matter.
Disconnecting Content Databases Pre-Upgrade
Content-databases can take a while to upgrade, which PSConfig will try and do while upgrading everything else. The problem is that PSConfig will drop the entire upgrade like a hot-potato if for any reason it finds a critical error, including all the other upgrade tasks that aren’t content-database related if something critical goes wrong with the content DB upgrade. This leaves you with a half-upgraded farm and basically in no-mans-land in terms of upgrade state.
Solution: before any upgrade, disconnect from the SharePoint applications any content databases so PSConfig just focuses on all the other upgrade tasks to at least have the farm upgraded ASAP. Once done, reattach the content databases and complete the upgrade with Upgrade-SPContentDatabase.
Again, the point is to better stage the upgrade; get the core farm upgrade 1st while running content-databases in compatibility mode, then finish the content databases once everything’s stable.
Important: you will need to complete the upgrade on the content-databases to be in a supported configuration; this is just a way of getting the base infrastructure upgraded 1st & foremost, and as quickly as possible.
Wrap-Up
That’s it – I hope this helps smooth-over patch-time for any admins looking for a better way of installing SharePoint patches.
Cheers,
// Sam Betts