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.
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.
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
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.
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.
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.
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.
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).
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.
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!