A SharePoint Update in September? Really?

Microsoft issues dozens of updates to SharePoint each year, but it always issues them at set intervals in cumulative updates. However, the SharePoint update issued in the latest patch on Tuesday isn’t at one of these set intervals. Its exceptional for Redmond to vary from the pattern, so don’t miss this one. Let’s learn more.

By now, Microsoft has settled into a familiar rhythm for maintaining SharePoint.

·  Internal engineering develops individual, on-request incident hot fixes (not public.)

·  Every two months Microsoft collects all the interim hot fixes into a cumulative update patch, or “CU” (Feb., April, June, Aug., Oct., Dec.)

·  Every six to eighteen months, all the updates and other fixes are aggregated into a Service Pack.

If you’ve read my personal blog, you may already know I’m a tad obsessive about tracking and logging all the updates issued for SharePoint.  You might even guess at my usual guidance:

·  Service Packs are heavily regression-tested and can usually be deployed as part of the ordinary course of IT maintenance.

·  Cumulative updates should only be deployed if they have a fix that relates to an issue in your environment, or when requested by Microsoft Support or a partner.

·  Always test before putting a fix into production.

So why, today, am I interrupting our regularly scheduled programming? 

Because Microsoft just issued a critical security update for SharePoint 2007-2013 without waiting for the next round of CU’s or Service Packs to catch it. It’s exceptional for Redmond to vary from the pattern. The security hole is noteworthy, and especially so for enterprises that haven’t yet upgraded to 2013. Security and compliance are valid reasons to accelerate standard patch deployment programs.

If you’re a diligent SharePoint engineer, download the patch, install and deploy. No big deal, it’s probably already finished.

OK, you’re still here. For the rest of you, what should you do?

First, you may have your production services set to automatically download and install Microsoft updates. That’s a bad idea for a whole bunch of reasons. It completely skips over the need to test and control fixes before going into production, so Microsoft patches (which are occasionally buggy) hit production instantly without taking a moment to prepare. Don’t do this in production, it’s the opposite of best practices. Don’t. Promise me now.

Second, even if you do turn on “auto-install” for Microsoft Updates, it doesn’t help.  Even if you do, SharePoint is different from all other Microsoft enterprise servers–SQL, Active Directory, etc. Patch installations require TWO steps:

1. Install the patch on all servers

2. Deploy them into the SharePoint schema using PSCONFIG, PowerShell or the SharePoint Products Technologies “gray” wizard.

And it’s that last step that Microsoft Update doesn’t do. So, if you’re using auto deploy:

1. Again, don’t.

2. It doesn’t help with SharePoint.

I can’t tell you how many times I’ve been onsite for a new engagement where the engineer assured me everything was current because of Microsoft Update. It assuredly wasn’t.

Don’t count on Microsoft Update – and don’t wait for the October 2013 Cumulative Updates. Download the patch, test, and deploy it now.