I agree with the notion that going with WSUS is the best route...to a point. I manage a 1200-desktop environment of NT4, 2000, and XP machines. It's like 80% XP, 15% 2000, and 5% NT. I am currently looking at WSUS but it has a few fairly major (in my opinion) limitiations. The one thing that I find to be a real issue for me is the way patches are pushed out. It requires you to schedule a specific time that patches are installed.

What if I want patches installed at startup, before the user even logs on? WSUS cannot do that. The best it can do (that *I* see) is to schedule pacthes for install at 2:00am, and then when the user logs on in the morning you tell it to make up the missed install within 1 minute of logon. That is kludgy to me.

Our policy where I work is this:

"No workstation will log onto our enterprise network without being fully patched. Ever. Period."

WSUS cannot enforce that policy. With WSUS in place, a staff member could install a gold-level Windows XP, add the PC to the domain, and this unpatched/vulnerable machine will sit on our network for possibly an entire day before WSUS would deploy. Or am I wrong about this?

What we have been doing since 2003 is using a custom scripting solution. It runs as a service account and does not require the user to be a local admin. A startup script runs on all machines. It runs MBSACLI (currently 2.0) which scans the machine and produces an XML output. The XML gets parsed, and an array of all needed patches is built. A report of this scan is dropped on the network for future reading. Then that array is for-each'ed and each patch is applied from a file share on the network. Error codes are recorded and a report is generated. Missed error codes will generate an email. The machine is rebooted. Next reboot, it gets scanned again (this takes about 10 seconds)....if it passes, the user can log on.

If the machine is still missing one of the same patches (meaning one didn't apply) an email is sent to the help desk, and only an administrator is allowed to login to the machine. (the logon script detects the partial install and immediately logs a normal user off).

If a workstation simply refuses to install a particular patch, one of the support staff can exclude that patch for that workstation via a central INI file that controls the patches. Then somebody can figure out the incompatibility or whatever.

So under normal day-to-day conditions (when no new patches are released), the net impact is that the workstation startup is delayed by about 10 seconds while the MBSACLI scan runs. Not a big deal. We also run an hourly scheduled task. This task checks to see when the last reboot was. If it was more than 12 hours, it will run the MBSACLI scan itself and apply the patches. By changing an INI setting we can have all machines scanned (and consequetly patched) every hour if we wanted.

Patches are downloaded by a scheduled server script simply by parsing the XML inside Microsoft's WSUSSCAN.CAB file and HTTP GET'ing all EXE's applicable to our environment. As each is downloaded, the script looks at the file properties and determines what kind of patch it is (update.exe, etc) and depending on the patch type will generate an INI containing the switches to use (usually "/quiet /norestart", "/q", or "/q:a". Some of the older NT patches will use "-qmz".) I will admit that this step does sometimes require some human intervention...Sometimes we need to manually run a patch with /? to figure out its command line parameters. Once in a while we find a patch that will ONLY work interactively....and we have to look at other ways of deploying.

Is this complicated? Somewhat. Am I the only one who can support it? Unfortunately, yes. I have INI-ized most of the configurable options. Any workstation can be exempted from one or all patches based on any number of conditions, simply by using basic INI settings. There are also AD groups which can be used to apply test patches before general relase, etc. So the support staf can run this thing without my help. But if Microsoft were to change their XML file format or something, it would require a kix coding change.

So while our solution works very well (for now at least) I definitely WISH I could use WSUS for patch management. I just don't feel it offers the kind of enforcement and flexibility we have with our scripted solution. Also, I don't like knowing that with WSUS my patch management system is reliant on an IIS and MSDE backend. Either one of those pieces breaks, and patches don't happen.

At the moment I am looking at a WSUS backend with a much simpler client-side startup script similar to the one linked to above. (on the innotech site I think it was). WSUS is a very nice step in the right direction, but it still needs some more deployment flexibility before I am ready to use it.

Long-winded...but those are my thoughts on the issue of WSUS vs. scripted solution.

Edited by sixdoubleo (2005-11-16 06:42 AM)