Patch Management With WSUS
Q: How do you maintain the patches on your Windows PC?
A: You don't. Get Microsoft to do it for you.
Windows Server Update Service
WSUS is a free download from Microsoft that installs on a Windows 2000 or 2003 server and an Active Directory domain. If you are running Windows Server 2003, sign up for the release candidate of WSUS 3.0. It sounds like the reporting and administrative aspects have greatly improved. Unfortunately, I won't have a 2003 server to try this on until summer. I'm making do with 2.0.
Installation is easy. You'll need IIS installed on your server, then install MS SQL. For Windows 2000, you'll need MSDE Release A. For Server 2003, you'll need MS SQL 2005 (the Express version will work). Run the IIS Lockdown tool to harden your web server.
Once everything is set up, WSUS will use AD to find all the Windows computers in your domain. It then checks each computer for Microsoft patches. It lists all installed and missing patches for each computer. It also lists patches that failed to install. All patches can be allowed or denied by you, so you can block patches until you have had a chance to evaluate them.
I tried using ScriptLogic's DesktopAuthority patch management option. The big problem there was that patches could not be scheduled to occur overnight. Patching only occurred when the people were logging in or when they were logging out. This is a big problem in a school environment where students are logging in and out all day long. Some of the patches took so long to install, the class was over before anyone was able to use the computer. The best feature (IMHO) of WSUS is the scheduling of updates. I can have the computers patch overnight and the computers are ready to go when classes start in the morning.
So, there's another free offering that you really need to take advantage of in order to keep control of security in your organization. Hopefully, I'll be able to do a write-up on version 3.0 this summer.
del.icio.us
6 comments:
Hi Dave,
You are correct Desktop Authority patch management does not support scheduled patching. However, ScriptLogic does offer a standalone patch management tool that may be more suitable for your needs as it includes scheduled patch installation. See http://www.scriptlogic.com/products/patchauthorityplus/.
Regards,
Ben
Thanks, Ben. That actually looks like a pretty nice product. Right now WSUS is covering us for the big problems. I would like to get Adobe & RealPlayer patches automated, though. I'll have to test it out this summer.
Hi Dave! We use both WSUS an desktop authority patch management feature. Two root offices and so the specificity… At the first time you see no scheduler it gets you confused a bit. But when you reveal the inactivity feature you find yourself thinking like it can be better then standard time scheduling. At least that's how it was with me. Scheduler functions like a static hard-defined table of predefined events. So it implies you must see for sure what will happen in the future. Say, Microsoft released security update which should be applied to all computers on the corporate net. Then you decide to deploy patch or a set of patches on Friday evening or right on this evening. And here we get our evening, we're fully prepared for deployment and at the end we realize that we cannot deploy it for all computers because some departments or projects are still here in the office. They decided to work right today when you decide to deploy patches to them. Here the inactivity feature within desktop authority gives the answer to solve the difficulty. In such cases I define the allotted time slot on when to monitor user inactivity. This is needed to prevent fault positives and avoid trigger on log off or shutdown events during the work day. Then I assign the event (usually restart or shutdown) that desktop authority would invoke when it will detect that user no longer uses his machine. And then I define a patching queue to be executed on the defined event.
@Craig: I think I see what you are doing. I've not messed with the timing validation, but I see some good possibilities there. You've also got a good plan for making sure your patches don't kick in in the middle of someone's session. I think you've got a good system for an organization with users that log in once and stay logged in most of the day.
My main problem is that someone has to log in or log off to trigger the patch update with DA. (Well, now it could probably happen on a refresh, but I digress.) People log on and off all day long in a school environment. By the time the updates finish, my students have lost the time they are allotted to use the computer. Sure, it's only the first student to log in that has the problem but I have no way to know when they will log in during the day. Whenever they do log in, they are guaranteed to lose at least 15 minutes out of 20-30 minutes available to them.
I need a way to have the updates occur overnight. Patch Authority Plus might be a better fit for our purposes.
That's why I recommend applying updates on computer shutdown event and force the shutdown when user inactivity is discovered. Thus updates will be installed on the time when it is guaranteed that use is no longer uses computer. By the way the mentioned refresh event can also be good here. You update policy on fixed time slot and execute the update on this period only.
But yeah, in such a way, then I agree seemingly patch authority can fit here better. As I see in their comparison table (Thanks to Bob for the link) it can schedule deployments at the defined time point. Interesting. Hope they'll add this feature to DA too although, repeating again, personally I like floating user-independent time slots best.
I was preparing a comment for you, Craig, when it finally hit me as to what you are saying. Let me put it in my own words and you can tell me if I am on the right track here.
You are suggesting that we set the validation for patch management to only run on shutdown. Then we can force the shutdown at night. Am I getting it now?
The only problem with this is if the computer is shutdown between classes. Then it will not likely be ready in time for the next class.
That should be resolvable be removing students' rights to shut off the computers. You have definitely given me something to think about, Craig!
Post a Comment