Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm developing a plan/strategy to manage patch deployment on Windows Clients using Windows Server Update Services. What are the some important things to consider in developing this plan? For example, auto-rebooting after an update although may seem trivial, may have considerable impact on some machines. So one solution is, to create a separate patch group in WSUS for machines that shouldn't auto-reboot. Tell me some things to keep in mind when developing a patch management plan and how to solve them. Thanks in advance

share|improve this question
up vote 5 down vote accepted

We stay a month behind (it's a nice round number) and also keep a separate group for machines that shouldn't auto-reboot. We also make a specific effort to exclude service packs, new versions of IE, and other major upgrades from the patch management system, taking the view that as these constitute a major upgrade you want to be physically there to see it happening, and respond to anything that needs responding to.

You should certainly consider having a test group of PCs that are a good representation of what's out there that don't stay a month behind (i.e. get their patches immediately). That way, if a patch is going to cause trouble at the PC level, you will find out about it quickly enough and can make a call on how to deal with it without every PC being affected.

Finally, in WSUS "update rollups" is a category separate to "critical and security updates", but yet some vital recent patches (Conficker, anyone?) were classified under that heading, so ensure that you don't miss it!

share|improve this answer

Have a solid plan to revert back. I would say just uninstalling the patch is not a good enough plan. So really this needs to be integrated into your backup plan.

Also, if you think your security can afford it, you might considering being a couple weeks behind. This will give you a chance to read about the patch before applying it, to see if caused issues with any of your applications.

share|improve this answer

For our WSUS server, I created OUs for the workstations, then below that I split it up into regions in the office. We also have one for laptops and member servers and domain controllers. I then created different views of the updates to suite my needs for example, I have a SQL Server update category, and Office category and a 2003 category and a... Sure it gets to the point where I might have too many, but it keeps it easy to read. So if there is a bad patch out there, I don't click approve on accident because I was shift-clicking.

Plus in the long run, I think it'll be easier to keep track of all the patching that is done.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.