I'm experiencing some issues with a legacy Windows Server 2003 Std SP2 machine.
Behaviour: Windows Updates are being automatically applied, but failing to finish, due to one or multiple updates not completing in time, and causing the system to fail to reboot by itself.
I can see that in the WindowsUpdate.log:
[Update] took too long (more than 16 hours) and was stopped
Then a series of:
WARNING: SUS Client is rebooting system.
AU invoking RebootSystem (OnRebootRetry)
Every 10 seconds until human intervention.
This is an issue, because the system partially shuts down (monitoring systems shutdown, TS sometimes dies) so the machine hobbles until someone kicks it over manually.
Is there a way to prevent/mitigate this kind of behaviour? I've found that this has happened in the May and July updates for the Windows Malicious Software Tool. Is this a known issue? Would I be better off manually updating the machine to remove the update for the WMST, in order to ensure correct rebooting and continued functionality?
In addition, is it possible to change the 16 hour window to something more manageable? Such as 1 hour?
Yeah, not applying updates automatically as soon as they come out. Installing them manually is one option, setting up a WSUS server and only pushing out updates you've tested and approved is another. You could even do something like set the client to download, but not install, and install the updates manually after a few weeks, to give MS time to catch and correct any issues with their patches.
Whether the extra effort is worth it or not is environment specific.
Typically, (at least when allowed by management) I'll set up a WSUS server, and a week after the monthly updates are released, I'll check around the web to see if anyone's complaining about the latest batch of updates hosing their systems. If not, I'll deploy the updates to a test environment (typically a collection of old servers and workstations running all the OSes and applications I can fit onto whatever spare hardware we have lying around). Do some basic checks to make sure all our "important" software still works afterwards, nothing's in a reboot loop and there doesn't appear to be any impact. Then I'll wait another week and check again, make sure it's still all working. Do a final check online for any known issues or complaints, approve the updates in WSUS for my test group and push the updates out to that test group (usually IT/MIS). If the updates don't cause any problems, a week later, I push to everyone. Obviously, if there are any problematic updates, they get left out until the problem is fixed.
Rinse and repeat every month.
In the almost a decade I've been doing this, I see about a half dozen updates a year that I pass or wait on, though MS has gotten much better about this since the NT and W2k days, and these days most of the updates I pass on are because of one POS legacy system or another that wasn't coded right to begin with, rather than MS botching an update, per se. (Though I did find a botched update back in May for Vista/7 x64, so it still happens from time to time.)
Probably not the answer you want to hear, but this is why you should monitor your servers when you patch or update them, rather than letting it happen automatically, or hitting the button and going home. At the very least, once the updates are done, and they've rebooted, you wait until they come back up before you head home for the day.
Changing that window won't fix the root problem (and I haven't heard of any way to alter it), and will really hurt you next time a .NET service pack, or OS service pack, or other "big" update comes out that takes 80 minutes to complete on your old hardware. (And yes, that does happen).
Like anyone else Microsoft periodically has a bad update. Unfortunatly it's not know until people have problems with it. Thus it is better to disable automatic updates and do it manually so that someone is at the machine if there is a problem.