Posey's Tips & Tricks
Should You Rethink Your Office Patching Strategy?
Buggy patches are all but inevitable -- especially, it seems, if they're from Microsoft. Maybe the old wait-and-see approach to Office patching is worth a second look.
Over the past few months, Microsoft has withdrawn several patches for Office. Specifically, there were a couple of updates for Outlook 2010 (KB4461522 and KB2863821) that were published in November 2018 and pulled soon thereafter because they were causing Outlook to crash. Another Outlook update published last month was also pulled because there were some issues with the update pertaining to the Japanese calendar.
Although I am sure that many people will disagree with me on this point, I can accept the idea that buggy updates are occasionally released. After all, applications such as those in the Office suite are extraordinarily complicated (at the code level), and it is impossible -- if not completely impractical -- to test every way that the software could potentially interact with the operating system or with other applications that might be installed. Some bugs are bound to remain elusive until after a patch has been deployed across a large number of systems in real-world environments.
Because some buggy patches are inevitable, one has to question how to best protect their organization against buggy patches. Personally, I like the tried-and-true strategy of waiting to see if anyone else has problems.
Back in the mid-'90s, I was working for a large insurance company that had gone all-in on Microsoft products. Back then, update deployment was not a trivial matter. Patches, which were referred to as "service packs" at the time, had to be manually installed from a large stack of floppy disks. It generally took a couple of hours to update each PC, and we had over a thousand PCs in the organization. Thankfully, updates did not get released very often.
Even back then, patch management was a high-stakes game, but the reasons were different than they are today. Today, the biggest reason for applying patches in an expedient manner is, of course, to mitigate security vulnerabilities. Back in the '90s, that insurance company had no connectivity to the outside world, so security breaches were less of a concern.
There were, however, two things that made us all take patch management very seriously.
The first of these issues was the sheer effort involved in applying patches. For those of us on the IT staff, it meant wasting a few perfectly good weekends manually installing patches from a huge stack of floppy disks. For management, the real issue was cost: Most of the people involved were hourly employees, and service pack installation meant that they were working a lot of overtime.
The other reason why service pack installations were such a high-stakes game is because there was no mechanism for removing a service pack. Once a service pack had been applied, the only way to get rid of it was to completely uninstall Office (or format the hard drive, if we are talking about a Windows service pack) and start over.
Given the cost and commitment involved in deploying service packs back then, the company that I worked for adopted a policy of always staying one version behind whatever happened to be current. For example, we wouldn't install Service Pack 2 until after Service Pack 3 was released. The idea was that by the time we were ready to install a service pack, it would have been around for long enough to be proven stable.
Today, patches are released far more frequently than they were in the '90s, and waiting for months to deploy a patch is a really bad idea in today's highly connected world. Even so, I think the basic idea of not immediately applying new patches still has merit. After all, organizations that held off on applying the Office 365 patches mentioned at the beginning of this article dodged a bullet by not applying patches that could have potentially caused serious problems.
This, of course, raises the question of how long you should wait to deploy new patches. I honestly don't think that there is a "one size fits all" answer to this question. Each organization has different needs, and those needs must be carefully considered when formulating patch management policies.
However, I will tell you that in my own organization, I tend to wait about two weeks to deploy new patches. I would probably feel comfortable shortening that to a week if I had the resources to perform rigorous preinstallation testing of new patches. Again, though, every organization's needs are different and what works for me might not necessarily work for someone else.
Regardless, I strongly recommend taking advantage of Windows Server Update Services or something similar so that you can tightly control the patch management process, rather than simply allow Windows Update to do whatever it wants.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.