So I'm still blessed with a non-Active Directory environment to manage
and it has lots of Windows hosts to keep patched. I do have Active Directory's
to take care of, too, but that old NT domain is still out there being a
management pain. The problem, obviously, is that I have no access to GPOs in
this environment and I'm using WSUS. So, I wrote a tool which, as it turns out,
is a lot more flexible and trouble free even in an Active Directory environment
than scoping all the GPOs you'd need to cover the various and different SLAs
your business customers might have defined for different systems. It's strong
enough that I'm willing to give it away through MouseTrax.com (and trust you all
to realize that support for the tool will be secondary to my day job, right?)
You can download this Excel automation project at:
It is based on the beautiful and (almost) complete information
contained in Deploying_Microsoft_Windows_Server_Update_Services.doc at http://www.microsoft.com/downloads/details.aspx?FamilyId=E99C9D13-63E0-41CE-A646-EB36F1D3E987&displaylang=en . Of specific interest is the section on registry settings for use in
non-Active Directory networks.
Slightly more focused information that led to the creation of this
spreadsheet can be found at http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=594 (Building a Small Office Automated Patching System Without Active Directory) by
Operation is simple and requires you to set your Excel macro security
to Medium. Medium allows you to be prompted about disabling or enabling macros
in an Excel document. The default setting is high and will prevent the VBA code
in the spreadsheet from executing. The macros are Self Certed by me. I'd use a
real cert but they're too darned expensive for me to buy and then give the code
away. To ease suspicion and allow you to better fit your environmental needs,
the macro code has also been left open for your own perusal/entertainment. If
you modify the code, Excel will drop the certificate when you save your changes
so don't do this unless you're willing to lose the certificate.
Open the Excel doc and enable macros when prompted. The AllHosts sheet
is the one in which, starting with row 2, column A, you can list the NetBIOS
names or IP addresses of your individual servers or desktops, read and write
all the WSUS settings to all those hosts. The Individual Host Test sheet is
intended to allow you to list a single host, read its settings, modify them and
then write them back to the host without cycling through all your listed hosts.
So, deal with your complete set of hosts on the AllHosts sheet and with only
one or two on the Individual Host Test sheet.
Once you've listed your hosts, go to the MouseTrax WSUS Client Manager
Menu and choose "Read WSUS Settings From Hosts". This will retreive
any settings you've already configured on the host and write them to the
spreadsheet. For each host, modify whichever settings you need to change and
then, from the MouseTrax WSUS Client Manager menu, choose "Write WSUS
Settings To Hosts". Any errors in either operation will be written back to
the spreadsheet in each host's row in order to aid client troubleshooting.
Note: When you use the "Write Settings..." menu choice, each
host is issued the "wuauclt /resetauthorization /detectnow" command
to initialize a scan from the host to the WSUS server.
This tool requires your hosts meet the following conditions:
- the account you are using has administrative access to the host
- Remote Registry service running on each host
- DCOM is enabled on each host
- WMI is running and you have administrative privileges under
delegation on each host
I hope some of you find this takes the stress out of WSUS Client
configuration. And, for the first time since you started managing patches on
your old NT domain, you can go home one Tuesday (Patch Tuesday) evening per
month and get some sleep!