4

Our IT department is rolling out a set of patches via WSUS this weekend and will reboot all of our Win2k3 servers on Sunday. Due to production work which must continue uninhibited, we cannot allow this reboot to occur. The exact line we have been given is:

The command to download the patches and reboot on Sunday has been sent by WSUS already and cannot be taken back. The servers will reboot on Sunday automatically.

How can we go about stopping this from happening? It set some flag saying it should reboot, so what flag do we unset? One strategy proposed was to roll back the system clock, however, this will likely cause some processes to fail.

user7116
  • 237
  • 3
  • 11
  • 2
    This isn't an answer, but your IT department has failed you spectacularly in this instance - they're supposed to help the business, not disrupt it! I would definitely take it up with your manager (and probably theirs too) and get somebody's ass kicked into line. Not my usual style, but it sounds like they totally deserve it this time round. – Ben Pilbrow Feb 11 '11 at 23:01
  • Well, at any Fortune N company (N < 100), IT is generally setup as a series of holes for square pegs. Anybody not a square peg gets beaten through the hole. – user7116 Feb 12 '11 at 16:42

4 Answers4

8

If you really do not have control over containers and GPO settings, then you're out of luck. The system is designed to prevent local admins from changing that kind of thing.

I have users in the exact situation you are, so we've had to create processes to allow exceptions to the everyone-must-apply-updates-at-$DateTime rules. We have a group of OU's for machines that need hand-holding through the update process, and people move machines in there if they need it. The machines in there get audited once in a while to verify that they NEED to be in there, we don't want end-user workstations in there because they hate having to log out of Outlook once a month.

After your production is horribly disrupted because of this weekend's patches, you can take that (and possibly the irate managers it'll cause) and press for some kind of exceptions policy.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • There is an exceptions policy, we were unaware the deadline was Wednesday. This will not be the first, second, nor third time production will be impacted. We've gone nuclear on any windows service related to patching in a last ditch effort to kill that. – user7116 Feb 12 '11 at 16:40
  • As a follow-up, turning off the service was detected, it was restarted and the servers were patched and rebooted as you described. Good times. – user7116 Feb 14 '11 at 14:25
3

In the Group Policy editor go to Computer Configuration > Administrative Templates > Windows Components > Windows Update and choose No auto-restart for scheduled Automatic Updates installation.

You can also completely disable Windows Update at the Group Policy level.

George
  • 185
  • 1
  • 2
  • 8
Luke99
  • 694
  • 5
  • 7
2

Temporarily setup a group policy that changes the windows update auto install settings from "Download and schedule the installation" to "Download only". Then strip the group policy after this weekend.

Jason Berg
  • 18,954
  • 6
  • 38
  • 55
0

I'm not sure if this fits the bill for you but there is a setting that prevents the reboot if a user is logged into the machine. Perhaps you can have someone logged in to the server until you're done your work, log out, server reboots?

Mitch
  • 1,127
  • 11
  • 19
  • We'd considered that, but we uh, would have to stay logged into 21 servers and be active :) – user7116 Feb 11 '11 at 20:15
  • Ya, not good for that many machines, one or two maybe. 21, not so much. What are the chances of getting a new container created to move your servers into as a temporary measure until you can apply the patches? – Mitch Feb 11 '11 at 20:18
  • I have no control over WSUS/containers/etc. I am merely a local admin on those machines. – user7116 Feb 11 '11 at 20:30