16

I'm finding that most users ignore the "There are updates ready to be installed, click here to install" message that WSUS pushes out. Until now we haven't forced the install but I'm thinking about changing the group policy to enforce updates nightly. This will sometimes require a reboot which I want to enforce through GP as well.

I know there will be push-back from the users but am wondering if this is defendable best practice. It seems like the right thing to do to ensure PCs are up to date and secure.

Improve this question
1
  • Someone should probably edit the question to be "Should you force a reboot after pushing out Windows updates?"
    – Ward - Trying Codidact ♦
    Jun 24, 2009 at 4:13

9 Answers 9

Reset to default
10

I would just like to get on my auto-reboot soapbox for a second: it's been my experience that automatically/forcing a reboot is generally a bad idea.

We system admins often have somewhat of a complex about making sure the latest patch has been applied the second it's installed because OMG until then the system is unpatched. However, you must realize that system admins at least theoretically are there to enable the people who use the system to do their work.

If you automatically reboot once a patch is installed, and, say, the workstation's system clock has been reset, thinking it's 2 AM, and some poor Dilbert loses work, you've made a huge gaff. In my opinion, it's a much bigger gaff than having a temporarily unpatched system on the network.

In my experience, having some sort of un-dismissable message telling the user to reboot is usually a better idea. Let them finish their work and reboot over lunch, or ask them to shut down their workstation at night, or something that fits into your organization nicely.

That being said, when I helped to administer 12 computer labs in a college, we had defined downtime when we knew for certain that nobody was going to be using any of the machines because the doors were locked. That is a situation in which autorebooting is surely ok; it's just the autonomous forced automatic work stoppage that irks me.

Improve this answer
2
  • 1
    I agree here, excepting the one point that if a system clock is wrong on your network, it's your fault. :)
    – mhud
    Jun 24, 2009 at 2:50
  • Yes quite right! I'm just saying... ;)
    – msanford
    Jun 24, 2009 at 4:48
8

We auto install then delay the restart for the install for 30 mins - prompts the user to reboot now and if there is no response in 30 mins then it reboots the machine. There was some initial grumbling but that have gotten used to it. If they are in the middle of something they can click "reboot later" to delay the reboot until a good time. But they will be prompted every 30 mins. It is a nice balance between just rebooting on the users and having them never install the updates.

EDIT:

Update - sorry missed the setting when i was double checking my GPO setting, the Re prompt for reboot is independently configurable. So you can set the delay before it prompts again. Also this is for a 2003 enviroment, they may have added/changed options in 2008

Improve this answer
2
  • It's the "no response in 30 minutes" part that scares me (see my rant below ;) Maybe they're on a conference call and just ignored their machine? Maybe they're in the restroom, or out to lunch, and left all their work open, say, one of which is a manual diff that requires user intervention to save?
    – msanford
    Jun 23, 2009 at 23:06
  • 2
    Yes, it's a configureable options, you can set it to 5 hours if you want. 30 mins is what has worked in our enviroment - also you can do it by OU so admins/developers can have a 2 or 3 hour timeout, and regular staff can have 30 mins or an hour. Like most other things like this "depends on your enviroment" Also they do it once and they no longer leave work open without at least hitting 'save' before going to lunch :)
    – Zypher
    Jun 23, 2009 at 23:32
4

Because you do test the patches first (dont you?) you know which ones require a reboot of the system.

You could create a schedule that says every last wed or thur of the month you send out an email saying you need to deploy X patches that require machines to be rebooted. Please leave your machines on overnight.

Granted this is not a green solution but it does enable you to work around your users needs and the need to keep the systems up-to-date.

For the other patches you could go with the solution that Zypher posted.

Improve this answer
1
  • This isn't a bad idea at all. I agree that it may not seem green, but one of the institutions I worked at (I was a user, not an admin) had a policy of mandating that all workstations were left on 24/7/365 in case a patch came in, or something needed to be Ghosted, or what not. That was decidedly not green...
    – msanford
    Jun 23, 2009 at 23:04
2

I'd be interested in other peoples answers to this also. I'm unable to implement auto rebooting, its been in "bad practice" for far to long and people wouldn't adapt. People leave their emails they need to respond to open etc, suddenly loosing them would very annoying.

Improve this answer
2

If you are looking for a technical reason, yes, it is "technically" best practice to ensure that the machines are patched immediately and that users cannot delay or circumvent the proper application of patches (including required reboots).

However, I would state that the decision to autoreboot after patch installs is a business decision, not a technical one. I think the main reason system admins tend to favor it is that if some unpatched systems get infiltrated, it usually requires long hours to get things cleaned up without a proper quarantining system in place. However, the forced reboot may affect productivity or be unacceptable depending on the usage of the machines (examples would be point of sale machines or on-air machines).

You may find that you can force autoreboot to one segment of your target machines but other machines have a legitimate business reason NOT to autoreboot. As always, the business is your customer so you lay out the pros and cons with your "technically best practice" recommendation and let them make a decision.

Improve this answer
1
  • +1 for mentioning business vs technical decisions (something that may be overlooked in the quest for running a technologically-perfect network).
    – msanford
    Jun 24, 2009 at 4:54
2

In some cases, you absolutely can not force a reboot. We have people who run simulations that run for a few days on several machines. The simulation software has a big problem: it doesn't save interim results. So if there's a reboot during a run, a big chunk of work is lost and has to be done over. There's currently no viable alternative to using this simulation program, so we in IT have to work around it. In this case, we created a new OU that doesn't get updates pushed out to it and we moved all the PCs that get used for these simulations into it.

Improve this answer
1
  • +1 Also, your simulations stations won't respond to "Hey, can I reboot now" message since there's likely no user sitting at the keyboard.
    – msanford
    Jun 24, 2009 at 4:52
1

One thing I try and do with the forced reboot, is check the patches each month and if any require a reboot send out a reminder email the morning the patches are being pushed out. We have a lot of staggered lunches throughout the day, so the 30 minute window isn't long enought(wish it could be longer, but that is all microsoft allows).

Improve this answer
1

If you are deploying updates, allow them to be pushed ASAP. If the machine requires a reboot, push that off until the night or early morning. If people shutdown their computers, you can prevent shutdown of the machine or put enforce a delay of the earliest time to reboot when the user power ups their PC again.

Improve this answer
0

We 'encourage(d)' shutting the down the computers at the end of the day for power consumption reasons (save $), thus updates would be applied at shutdown. Of course there are some that decide to never shutdown, but we didn't have too many computers in the office (About 80 clients now mostly moved to thin-clients).

Since the title of the question is "best practices" specific for WSUS, I would suggest (and this is totally off-the-wall) to make sure you enable only the necesary updates and not enable the download process during work-hours. One of our techs found out the wrong way NOT to enable all updates on a site with a T1 WAN connection, ouch!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .