IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Happy last Friday of January to all that read our Ask PFE Platforms blog! This afternoon’s post is based on a submission to the Ask PFE Platforms Mail Bag. The chosen question was submitted using the Contact tile just to the right of this article when viewed from our TechNet blog.
Is it necessary to restart a server as soon as possible after installing updates or is it safe to suppress the restart for a day, week, month, or longer?
Thoughts regarding the question
Within Windows, there are many features and capabilities. Restart suppression when applying updates is just such a feature. The ability to suppress a system restart following the application of an update or other system configuration change exists so that additional changes may be performed prior to restart. While the option exists to suppress a restart, keeping the restart suppressed for extended time may not be the best option and may carry more risk. This reminds me of a prior blog post of mine where I discussed the effect of using 512 byte clusters on a system disk, the potential side effects with VSS and system performance, and the additional administrative overhead involved to keep things functioning at a healthy level. Point being, there are configuration options like restart suppression. However, just because it appears you could suppress an update related restart for extended periods of time, doing so is likely not a best practice and may have side effects.
First, let’s revisit updates. Some updates or security hotfixes require a system restart after application. Many times accompanying bulletins or KB articles indicate the requirement of a system restart following the application of the update. Those are the cases where the need to restart is known. For example, if the update replaces NTOSKRNL.EXE, that definitely requires a restart. There are other situations where a restart may be required because the update process needs access to the files already in use by the system that may be blocked for unexpected reasons (Anti-virus filter driver has it blocked, etc…) Starting with Windows Server 2008, many times DLLs in use by running processes may often be updated without need to restart, and sometimes without the need to restart applications or services. On occasion, files that need to be updated may be locked and need to be replaced prior to shut down or as part of system startup…and thus, the system must be restarted to apply the update. Also, it is important to note that updates may be to other aspects of the operating system than just binaries. Some updates may add or remove registry settings, change registry permissions, or even apply permissions to changed files. In some cases, replaced files are not protected until after a restart takes place. Some components load settings at boot time and are cached, therefore a restart must be performed in order for those components to have updated settings. After restart, advanced installers for components may perform a variety of tasks to complete the installation of components. Pending.xml gets populated with files and registry values needed to install updates. For more information about pending.xml or how service packs are handled by Windows, the following link is a great reference:
If you suppress a restart after applying an update, then the update is not completely in place. If this update were a security update, the system would remain vulnerable until the restart and completion of the update after boot. How long should the restart be suppressed? How long should a system remain vulnerable? Further, group policy can influence application of updates and handling of restarts. For more information on Windows Update and group policy, consult this post on the Microsoft Update Product Team Blog:
In theory, you could apply updates, suppress the reboot, and wait an infinite period of time. However, the longer the restart suppression, the higher the chance that unpredictable things could happen…especially if we’re talking about multiple updates. While suppressing a restart, there is no guarantee that there won’t be side effects based on what changes were applied and those that remain pending. At least, I’m not aware of any. I certainly have observed system hangs or other odd behavior with systems of my customers when they’ve suppressed restarts. However, I’ve seen these issues less with Windows Server 2008 and later as compared to Windows Server 2003 or older versions. The moral of the story here is to restart as soon as you can after updates or changes that require it. My own conservative approach is to apply updates during a window of opportunity for restart and not to suppress them for extended periods.
Windows Server 2012 Pending Restart Notifications
Windows Server 2012 does indicate pending restarts in Server Manager. When I first saw this my thought was that it was annoying. However, if you think about this notification in the context of a datacenter where an administrator updated something, suppressed the restart, and then left for the day and otherwise forgot to complete the job and you’re now troubleshooting strange server behavior a month later…it is nice that a notification like this could clue you in that maybe a simple restart is all the system needs to complete pending changes. I can think of at least one all day troubleshooting call within the last year that this type of notification would have prevented on an older system where an admin updated things a month before and never restarted the system.
I hope this post addresses concerns and helps shed some light on why restarts after updates are good to provide sooner than later and perhaps why restarts need to happen with some updates. Until next time!