Of course, saying you can update Windows without rebooting is a bit of a misnomer. Some updates don’t require a reboot, but with the ones that do, there isn’t really any getting around it. You can delay the reboot, but if you never get around to rebooting, you have a partially applied update indefinitely.
But here’s how I used to use delayed reboots to help me get more done in my maintenance window.
Not quite updating Windows without rebooting, but using the delayed reboot to your advantage
I used to use the delayed reboot to my advantage. My maintenance window almost always started on Monday. But I would get final approval sometime Thursday or Friday. So I would blast out my updates and suppress the reboot first thing after the meeting was over. And then I would note any errors, fix anything I could, and then I spent my maintenance window performing reboots.
After I rebooted a group of servers, I would rescan them with my deployment tool and try to correct any errors. If I was lucky, and extra reboot would clear the error. When I wasn’t lucky, I had to do some forensics. I didn’t call it forensics, but one an update wouldn’t apply, I would dig into logs to figure out what failed, and hopefully find a clue so I could get the update to apply.
I applied an average of 200 updates a year to my fleet of servers and my success rate was 100%. I missed exactly one deadline in 48 months. So I wasn’t perfect, but I was pretty good.
What happens if you don’t reboot every time?
If you miss a system, or you miss a reboot on all of your systems, you have incomplete updates. You won’t have clean scans either. Your patching tool may or may not give any indication that anything is wrong, because it didn’t get an error from any of the systems. So you’re patching tool and your vulnerability scanner will probably disagree. But it’s not a false positive. The file didn’t update, and the system is still vulnerable.
I had a hotshot system administrator argue this point with me a few years ago, but with more respect than he’s due, he didn’t know what he was talking about. I don’t normally do this, but I found an exploit and ran an exploit against the system to prove that it was still vulnerable. Then I ran the same exploit against a system that Qualys said was clean, and the exploit didn’t work.
Sometimes rebooting the system once cleared the backlog and we got a clean scan. Some of the systems had to be rebooted a dozen times to clear the backlog.
Both Qualys and Tenable have findings to indicate when a system has a pending reboot. But it’s just a yes or no flag in the Windows registry. So Windows has no way of telling the scanner how many times it needs to reboot.
Estimating how many reboots you need
I typically look at how many monthly updates the system is missing to try to estimate the number of reboots needed. It’s a crude measure, since the updates are cumulative, and if you skipped any of those updates, the system probably doesn’t need to reboot for them.
But it’s the best estimator we’ve got.
Something else you can try is rebooting the system once, then rescanning it to see what’s still missing. If only one of the monthly updates went away, that’s a reasonable indicator that you have a backlog.
Cheating at the reboots definitely helped me patch more productively. But you do have to learn what you can get away with.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.