SharePoint Automatic Updates, Yes or No?

It was recently announced that SharePoint updates will now be released with Windows updates for automatic deployment.  SharePoint Admins everywhere are shaking their heads!  What is Microsoft thinking this time?!  While this seems to be more convenient than having to go out and download those updates manually, there are definitely some considerations all SharePoint admins and server administrators should be aware of.

A little bit of background

Historically, SharePoint updates have been provided separately from Windows update. As in, you have to go out and manually download and install them; they don’t just show up as available updates in the Windows update window. Microsoft wasn’t able to push updates for SharePoint Standard or Enterprise before since you previously had to first apply the update for WSS/Foundation (free) and then layer on top the update for SharePoint Server (paid version). This process was too complex for windows update to run properly and then you still needed to run the SharePoint configuration wizard to complete it.

The Good….

The patching process has (thankfully) improved and this three-step update process is no longer needed, paving the way for patches to be released automatically. Let’s be serious – who actually applies updates to their SharePoint server on a regular basis? Manual processes typically get left to the wayside until you have a *need* to apply a fix or update. Microsoft seems to be aiming at making this a little more convenient.

The Bad…

As someone who has a background in SharePoint administration, I’ve seen many environments blow up over a SharePoint update being applied. Sure, in a perfect world, everyone’s SharePoint environment would follow best practices. Databases would never be over 100GB, everyone would use the proper number of security accounts, and no one would ever apply customizations to the server. In this scenario, rolling out continual SharePoint updates through Windows Update would be no problem! But we live in the real world.

I tend to recommend that you install the cumulative updates only as needed and installing them at a separate time than you are applying new Windows Updates. If the SharePoint update fixes something specific, then apply it. Otherwise, don’t worry about it since it might break something and why “fix” what isn’t broken? In fact, we’ve seen how some cumulative updates flat out break SharePoint and then that cumulative update is re-released later on. If you absolutely have to apply a cumulative update, schedule downtime over the weekend and then apply the update Saturday morning. If anything goes wrong, you have the whole weekend to fix it. The exception here are security updates, you should always apply those when possible.

The Ugly…

Remember how I mentioned we used to have to run the configuration wizard after updates? Well, that requirement isn’t gone. Per this tech-net article, you may still have to run it “from time to time” if you are pushing SharePoint updates automatically through Windows update. http://blogs.technet.com/b/stefan_gossner/archive/2015/02/12/sharepoint-cus-and-windows-update.aspx

Read: If SharePoint doesn’t work after updates are applied, try running the SharePoint Configuration wizard.

Windows updates tend to be harmless. We have seen instances where a security update suddenly prevent a SharePoint service from running correctly but in general things have been pretty tame. Letting those updates run over a weekend is no big deal. However, as I mentioned before, SharePoint updates making changes directly to the software binaries definitely put your SharePoint farm at risk for problems. Running the configuration wizard “time to time” and not consistently also seems to complicate the matter. For those not familiar – the configuration wizard will ensure that your databases are updated to match the binaries on your SharePoint server. Apparently it’s now acceptable to throw this step in as an after-thought? No worries though, those databases *should* run in backwards compatibility mode just fine until you remember to run that wizard. Maybe. Hopefully.

What should I do?

The worst case scenario is that you walk in on Monday morning after a weekend of updates, and SharePoint is down. Not only have a bunch of windows updates been applied, but a SharePoint cumulate update was applied as well. Why is SharePoint down? Hard to tell. Now you’re not troubleshooting this issue during planned downtime over the weekend, you’re now troubleshooting it on Monday morning with the managers wanting to know why their documents aren’t available. Ouch.

Don’t let this happen to you.

Before diving head first into allowing SharePoint updates all the time, whenever they want to download and install, you should definitely be taking a closer look at your Windows Updates settings and WSUS configuration.

  •    *Consider putting your development environments in a separate WSUS group where updates can be deployed first
  •    *Consider delaying the application of the update to allow time for others to confirm that it will not adversely impact SharePoint functionality
  •    *Push SharePoint Updates at a separate time from your Windows Updates.
  •    *Push SharePoint Updates over the weekend or holiday (or whatever your organization’s slow time is)
  •    *Once you allow a SharePoint update to be deployed to your server, especially the first few times you go through this process, you’ll want to closely monitor how it goes
  •    *Check the server following the update
    •     **Always make sure your servers are getting rebooted following the update
    •     **Test SharePoint availability after the update
    •     **Occasionally run that configuration wizard – don’t forget about this step!

As with anything in your server environment, you should make an informed decision on what’s best for your organization’s situation. Good luck, and happy patching!

 

This article was written in response to Todd Klindt’s recently released article discussing some changes with how SharePoint updates are being rolled out.

See here for the article:  http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=552

Leave a Reply

Your email address will not be published. Required fields are marked *