1

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

3 Answers 3

5

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!

1

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.

1

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.

You must log in to answer this question.

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