Avoiding trouble with Windows Updates
Do you ever wonder why there are so many sporadic one-off problems with Windows Update? Someone runs a .Net update and it breaks a lot of things, even though thousands of other admins have run that same patch without problems?

I think I might have an inkling why.

How many times have you been checking on a server right before lunch and saw an optimization you could easily make, made the change and then saw that the server wanted a reboot? It wasn't that critical a change, and you can't restart the system during business hours, so you add a task to your list to restart the server that evening. Or do you? Did you ever actually get around to it?

Maybe you download a patch for a known issue and then it calls for a reboot, and you decide that you might as well run some other updates before the reboot to get your downtime's worth.

Both of these situations are much more likely to result in failed Windows Updates, since there are unresolved .dll, file and registry changes underway.

The best practice is to restart a server BEFORE you run Windows Update or any significant patches. You would do this in order to ensure that there are no subsystems that can't be patched properly due to their already holding their breath for a reboot. So a good Windows Update procedure would involve at least two server restarts: one before the updates are run, and another after.

The truth is, if your servers run for 30+ days between reboots, it's fairly common for them to begin to accumulate some of these "pending reboot" situations, and if you don't resolve those before doing any serious patching, you may end up with unpredictable results.  ¶ 3:03 PM