Mark Minasi's Windows Networking Tech Page
Issue #38 January 2004

To subscribe, visit To unsubscribe, link to To change e-mail address, switch between HTML or text format, etc., link to  Visit the Archives at  Please do NOT reply to this mail; for comments, please link to  Document copyright 2004 Mark Minasi.

What's Inside

  • News: 
    • Seminars: XP and Active Directory Classes: Charlotte Next Week, Philly & Chi Next
    • Microsoft Security Roadshow Version 2:  All New Stuff!
  • Tech Section
    • A Free RAM Tester From Microsoft
    • DNS Mystery:  "It Works For Most Sites, But Not Yahoo or Microsoft..."
    • Active Directories Do Not Like One-Part Names
    • Feature Article:  Software Update Service: Patch Management From A to Z
  • Conferences
  • Bring a Seminar to Your Site


Hello all

This month I've got several tips and a big article on Software Update Service, Microsoft's free tool that lets you create a Windows Update server of your own.  A lot of you have asked me to explain more of what SUS does and how to install it -- I hope this article answers your questions and, more important, that it inspires you to go get it (or some other patching solution!) up and running.  Believe me, if you don't have a patching system yet, you'll regret it!

I've also got some great news about completely new Security Roadshow, a reminder that the Charlotte classes are next week! and we still have a few seats left, and ...

Seminars: XP and Active Directory Classes: Charlotte, Philly, Chicago, Dallas, LA

Next week I'm coming to Charlotte, NC to teach my "XP Support" Monday and Tuesday and "Running a 2003/2000-Based Active Directory," seminars on Wednesday and Thursday, held at the Hilton Charlotte Executive Park.  There's no faster way to become expert in desktop or network support.  And don't forget we're coming to Philly in February, Chicago (O'Hare area) in March, Dallas in April and LA in July.  Find out about the XP seminar at,  the Active Directory/Group Policy seminar at, and the schedule of seminars at

All-New! Microsoft Security Roadshow Version 2

Thousands of you attended the first series of Security Roadshows created by Windows and .NET Magazine and sponsored by Microsoft, NetIQ and others.  And so many of you asked for more details that Microsoft requested us to do a second series.

This second set of 20 shows started last week in Fort Lauderdale and continues until May, going to Tampa, Seattle, Atlanta, Honolulu, Denver, Dallas, Cedar Rapids, Minneapolis, Cleveland, Chicago, New York (midtown), DC (Tyson's area), Philadelphia, Phoenix, Anaheim, San Mateo, Woodbridge NJ, Albany NY, and Nashua.  There's a sign-up page with more details at

In the first series of road shows, I did a talk with a dozen or so tips that you can quickly use to shore up your network's security.   This time I offer a new set of useful things that you can quickly do to strengthen your network from attackers both inside and out.  I find that most of us have heard of the kinds of things that we're supposed to do to secure our nets -- concepts like LM hashes, LM and NTLM authentication, SMB signing, IPSec, Internet Connection Firewall, SYN flood protection, null sessions, proper password policies, EFS and others -- but lack the time to research these things.  What do they protect us from?  How large a threat to we face if we ignore these tools? What breaks if we enable these protections? In this talk, I cover those concepts and more.  In every case, you'll first learn why you care about these things, then you'll get a tested set of step-by-steps to implement them and some cautions about their potential down-sides.

But that's just the start.  This show is a day long and includes speakers on hardening client and server systems, intrusion detection and patch management.  The cost is the same as the previous one -- there isn't any -- and I think you'll find it a worthwhile use of your time.  I hope to see you there!

Tech Section

A Free RAM Tester From Microsoft

Back before NT 3.1 first shipped, I had a chance to talk with Dave Cutler, NT's original chief architect.  I commented to him that I believed that many people who thought that OS/2, Windows and inevitably NT were unstable were blaming the wrong guy.  The right guy to blame, I opined, was RAM.  I argued to him that if he really wanted NT to be perceived as the rock-solid OS that he claimed that it would be that he needed to give users a really good tool to test their RAM.

I still believe that.  A good number of the mysterious blue screens that I've diagnosed over the years came down to some kind of RAM problem -- mismatched memory modules, overheated memory in systems with faulty or inadequate fans, or systems with flaky power.  (Notice that the latter two aren't really memory problems, but they show up as bad memory -- and are as hard to track down as "real" RAM failures.)  I've played with a number of RAM testers and I haven't liked any of the inexpensive ones and couldn't afford the expensive ones.  Now, however, Microsoft's giving away a RAM tester program.  (Perhaps they recalled my conversation with Cutler from 12 years ago?  Yeah, sure, Mark.)

You can find it at -- an URL that you may recognize as being in, their "online crash analysis" site.  If you've bluescreened an XP system then you'll recall that a message offers to analyze it for you -- it's that contains the code that does that.

Anyway, the RAM tester seems fairly thorough and helped smoke out a mismatched RAM problem in one of my systems.  Give it a try!

DNS Mystery:  "It Works For Most Sites, But Not Yahoo or Microsoft..."

Now that the world is more firewall-aware (due to the increased activity of cyber-criminals) and DNS-aware (due to the increased use of Active Directory) I've been getting a particular DNS question frequently.  It runs something like this:

"Our network guys did something recently and now DNS is screwed up.  We can resolve your site and most other sites, but we can't resolve Yahoo!, Microsoft and some others.  What could this be?"

The answer is that the network guys opened UDP port 53 for DNS, but not TCP port 53.

DNS uses port 53 with UDP if it can (because of UDP's speed), and TCP if it can't.  The question of "can" or "can't" is decided by the maximum size of a UDP datagram.  (I was surprised to learn years ago that DNS uses port 53 both as a source and destination port, unlike other protocols wherein you talk to the server on one port and it responds to you on some higher-numbered port.  For example, if you want to see my home page then you query my Web server on port 80 and it responds to you on some port numbered above 1023, a so-called "high port.")  Now, if you query my site asking "what's the IP address of" then you get just one IP address -- a small answer, and it fits into UDP with no problem.  But try it with sites like or which have a number of IP addresses associated with their names, then DNS can't fit the whole answer into one UDP packet, so DNS switches over to TCP.

Now, 99.9 percent of the Web sites out there seem to return no more than one or two IP addresses, and so are candidates for UDP when DNS-ing.  For that reason, the firewall guys probably tried opening just UDP port 53 and tested it with a bunch of DNS lookups, all of which succeeded.  But if they left TCP port 53 closed, then they'd see this once-in-a-while DNS failure.  The answer is to open TCP port 53.

This can also affect zone transfers, which are often large enough to require a TCP connection.

Active Directories Do Not Like One-Part Names

Once an Active Directory designer understands the nature of DNS and split-brain DNS in particular then she soon realizes that it's theoretically possible to have a domain name without a period in it.  For example, while most of us think that domain names look like "" it is quite possible to have a domain named "com," and of course such a domain exists on the public Internet DNS hierarchy -- it's the one that Network Solutions controls and that my domain is a child domain of.  (And that every other domain whose name ends in "com" is a child of.)

But Windows DNS code isn't really built to handle one-part, no-period DNS names.  Apparently the dynamic DNS client is the culprit -- it doesn't register names correctly for systems whose DNS suffix is just one part like "com" or "local" instead of multi-part DNS suffixes like "" or ""  So, the bottom line is:  make sure there's at least one period in your DNS suffixes.

Software Update Service: Patch Management From A to Z

While I wish I didn't have to patch my Windows systems, patching is clearly a necessary evil these days.  So I visit Windows Update ( pretty frequently to ensure that I've got the latest patches so I don't end up the victim of The Worm Of The Month.  Of course I'm simplifying here, as in reality I don't blindly apply every patch that Microsoft offers as soon as they're released.  But let's assume for a while that we want to roll out MS patches quickly and uniformly across our enterprise.  Certainly there's at least one Microsoft patch that fits that description a couple of times a year.

I want to roll out patches, but the Windows Update site is an inadequate tool for three reasons.  First, not all of my users are technical enough to get to Windows Update and apply patches.  (Or they might be too lazy to bother patching.  Of course, my users don't have that problem.  But I know some other folks and I'll bet you do too...)  Second, there are patches that aren't relevant for me and my organization -- I'm a big patching nut, but even I don't need the Chinese language patch for the .NET programming framework -- and I'd rather that my users didn't even see them and waste time wondering if they need them.  Third and perhaps most significant there's the bandwidth issue.  A while back Microsoft released a service pack for Internet Explorer 6 that ran a bit over 10 MB in size.  Suppose I had 1000 users (I don't, thank God) and they each visited Windows Update to get this IE service pack; that'd be ten gigabytes' worth of downloads over my expensive Internet connection -- essentially Windows Update would sort of become an unintentional denial of service attack!

SUS Basics:  What it Can and Can't Do

In July of 2002, Microsoft offered an alternative called Software Update Service.  Basically it lets you set up your own private Windows Update on a server inside your organization, and then lets you configure all of the systems inside your organization to look at that private SUS server for patches instead of Microsoft's Windows Update server.  With SUS, you can

  • Control which patches your users see
  • Cause their systems to download and apply patches without the need for user intervention, and
  • Greatly reduce the patching burden on your Internet bandwidth, as users grab patches over your LAN -- in my previous example you'd just download that IE service pack once over the Internet, install it on your internal SUS server, and then your 1000 users would get their patch over your internal network, with no extra load on your Internet connection.

But SUS won't do everything.  The price is right, but it's limited in what it'll let you do.

First of all, SUS only handles the critical updates.  Look at Windows Update and you'll see three sorts of downloadable items:  "critical updates," which are OS patches that fix some security problem, "updates," which are patches that either fix a non-security-related problem or that add some value to your system, like a recent XP patch that adds support for IPv6, and "drivers," which are obviously updated hardware drivers.  SUS only distributes critical updates, and there's no way to use it to locally host updates and drivers.

Second, SUS only delivers patches for the Windows 2000, XP and 2003 operating systems.  Windows 9x and Windows NT 4 patches can't be delivered with SUS.  Nor does SUS deliver patches for Office, SQL Server, Exchange, ISA Server, etc -- only the stuff "in the box" with 2000, XP and 2003.  (Good news, though -- Microsoft will fix this with SUS 2.0, which will appear sometime in the middle of this year.)  There is also no way to use SUS to deliver your own non-Microsoft patches.

Third, while SUS takes the place of Windows Update, it doesn't present the same user interface as Windows Update.  As you'll see, the SUS client wants to work in the background, unobtrusively downloading patches and then, if those patches require a reboot, to do that reboot at some scheduled time.  Windows Update can work like as well, but what if you've just installed a system and you want to go get all of your patches and install them immediately?  Well, with Windows Update, you can do that -- you just go to the Windows Update Web site, select your patches, pull them down, install them, reboot and you're done.  But there's no similar way to just fire up a Web browser, point to a given SUS server and just tell it to get you up to date with patches now -- there is no interactive, browsable interface for SUS clients and no way to speed up SUS's patch application.

Fourth, there is similarly no way for an administrator to sit at some central location and instruct the SUS server to force some new patch on every client, now.  You can sort of help the process along, but you can't say "do it now" as you can with Windows Update.  With SUS, "patience is a virtue."

SUS Install Overview

Simplified, you set up SUS with these steps:

  • Start from a machine running either 2000 Server or Server 2003
  • Install Internet Information Service on the server
  • Download and install SUS on the server
  • Once SUS is installed, connect the server to the Internet and download all of the patches on Windows Update (over a half gigabyte) using SUS's Web-based administrative interface
  • Approve all patches that you want your systems to receive
  • Install the SUS client on any 2000, XP or 2003 systems that need it (most will not)
  • Configure the SUS client either via the Registry or with local or domain policies 

SUS Server Setup Steps

You'll use a system running either Windows 2000 Server (SP2 or later) or Windows Server 2003 to act as the SUS server; as far as I can see you can't make a Professional system with its cut-down IIS a SUS server.  First put IIS on the server (take a look at Chapter 17 in either the Mastering 2000 or Mastering 2003 books if you're not sure how).

A look at the literature on SUS shows a lot of people recommending strongly against running SUS on a domain controller, advice that is a bit hard to understand at first -- what does whether a system is a DC or not got to do with SUS?  What the authors really mean in that case is that because SUS requires IIS, and it's common wisdom not to run IIS on a domain controller, that SUS on a DC is a bad idea.  Personally I don't see it as all that big a deal, provided it's a server that isn't directly connected to the public Internet.  Basically all they're saying is that in general it's probably not a good idea to expose a DC to the whole wide world.  If you only have one server, then, and you want to run SUS on it then go ahead, even if it is a DC.  (Don't expose the system to the Internet, though.)

Download the Software Update Services 1.1 server piece from Microsoft's Web site at details.aspx?FamilyID=a7aa96e4-6e41-4f54-972c-ae66a4e4bf6c&DisplayLang=en.  But if that link doesn't work then don't worry, just do what I'd do, which is just to search for "Software Update Services."  (It seems as if there's someone at Microsoft whose job is to rearrange the Web site daily.)  The download is about 30 MB.

You can probably do a "typical" install.  Even if you choose the custom install, you only have to answer a few easy questions:

  1. Where shall SUS put the patches ("content")?  The default of c:\sus\content is probably fine.
  2. When Microsoft issues a patch that is really an old patch with corrections, should SUS automatically approve it?  Normally you'll set up SUS so that you have to review and approve any new patches.  But now and then Microsoft tweaks an existing patch and the reasoning is that if you liked the old one then the even-more-debugged version will be to your liking also, so should SUS just roll it out without bothering you?  This is a matter of taste -- personally I accept this option, but that might not make sense for your organization.  I'm told that every single server reboot is a "mark of shame" for some administrators, and so you might not want what is essentially a "patch for a patch" for an innocuous, low-probability attack triggering an extra reboot.
  3. What is your favorite color?  (Oops, never mind, sorry -- that was a question from something different.)

Once you've got SUS installed, you control it via a Web interface.  Just open up IE and enter the SUS server's name followed by "/susadmin" -- for example, if your SUS server is named then open up IE and put "" in the address bar -- and you'll be asked to present administrative credentials.  You'll then see a Web page welcoming you to SUS.  We're about to ask Windows Update for every critical update that it knows of, so you'll probably want to stem the tide of updates by restricting the language or languages that SUS cares about.  On the left-hand side of the page, click the "Set options" link and scroll down on the right-hand side to "Select where you want to store updates:," then check only the boxes for the languages that you care about and click Apply.  (While you're here, note the other options available as well -- proxy server configuration, the servers's name, what server the SUS server should get patches from, and how to handle updated versions of previously-approved patches.  You probably won't need to fiddle with them right now unless you've got to go through a proxy to get to the Internet, but it's nice to know where they are, should you want to reconfigure your server.)

At this point, you need first to get some patches to deliver, so click the "Synchronize server" link on the left-hand side of the page.  That presents two buttons -- "Synchronize Now" and "Synchronization Schedule."  Click the first and then go get lunch.... and maybe dinner and possibly all three of the Lord of the Rings movies, as your SUS server then downloads every patch known to Microsoft relevant to 2000, XP or 2003.  As I write this in January 2004, the sum total of the download is a bit over 600 MB.

Once the download's finished, SUS automatically moves you to the "Approve Updates" page.  Go through them -- there are a lot the first time -- and approve the ones that you want by checking the boxes next to each update.  When you're done, click "Approve" and you'll get an are-you-sure dialog box; click Yes and you'll get a "do you agree to the license agreement that our lawyers wrote up that absolves us from all blame?" dialog box.  I particularly like the part of a license that appears in a recent Update:

"You may not disclose the results of any benchmark test of the .NET Framework component of the OS Components to any third party without Microsoft's prior written approval."

Pretty neat, eh?  Makes you wonder why Honda and Toyota are working so hard on their fuel-electric hybrid cars to achieve better gas mileage.  All they'd have to do would be to take their biggest SUV, leave it unmodified and claim that it gets 150 miles per gallon, and then make every customer sign an agreement about disclosing benchmark results...  Anyway, back to SUS installs, I have had a bit of trouble finding the "I agree" button on these dialog boxes, I think because I run my screen at 1600 x 1200 resolution in combination with large fonts -- apparently the programmers at Microsoft set the dialog box to a particular size without first checking the size of the fonts, and so the buttons basically fall off the bottom of the dialog box.  (Great Scott!  I hope that's not a benchmark value of the .NET Framework that I've just revealed!  If it is, then I guess I'm cooked!)  I've found that pressing the Tab key several times scrolls the contents of the dialog box around and reveals the "Accept" and "Don't Accept" buttons.  You'll see a progress gauge run for a bit and you'll get a confirmation that All Is Well and that your PCs can now get updates from this computer.

Before leaving the server, return to the "Synchronize Server" link and click "Synchronization Schedule" button.  That lets you tell the SUS server how often to check Windows Updates for new patches.  I have mine check Microsoft every day at 2 AM.  But I don't have my server automatically approve all updates, which means that I've got to check my SUS server every day to see if there are new updates to approve.  It'd be nice if I could say to the SUS server, "e-mail me if there are any new patches from Microsoft the next time you look," but there isn't.  (Maybe SUS 2.0?)

Installing the SUS Client

In any client-server system there are two pieces:  the server piece, which runs on the server, and the client piece, which runs on the clients.  Oftimes the server piece is the uglier of the two, but fortunately you only have to install it on a server or two.  The client piece, in contrast, may be simpler in nature but -- and here's the really ugly part -- you have to install it on every client, and there are usually tons of them.  Here, "client" means every machine running 2000, XP or 2003, whether they're workstations, member servers, or domain controllers.

Microsoft offers a SUS client at downloads/recommended/susclient/default.asp.  It's shipped as an MSI file and so can be delivered automatically, hands-off through an Active Directory and and a group policy-based software installation -- look at the Software Deployment chapters of the 2000 and 2003 server books for step by steps on rolling out software with group policies.  But the good news is that you probably needn't roll out a SUS client because Microsoft included the client with Windows 2000 SP3 and SP4, XP SP1, and 2003 from the very beginning.  That, then, is the really good news -- the chances are that you don't have to install any client software, as you've probably already got an up-to-date SUS client.  (Up to date, that is, until mid-year, when Windows Update becomes Microsoft Update, and SUS 2.0 comes out.)  

In any case, if you must roll out a SUS client, then just download the above file and either use group policies to deliver it or just go machine by machine to install it.  Just double-click on the MSI file to install or use msiexec /i, there aren't any questions in the install.

Configuring the SUS Client 

Wondering why Microsoft went to the trouble to install a SUS client on your systems before you got SUS?  In fact you've probably already met this client.  It's the Windows Update client that puts the globe with the Windows flag in your system tray and bugs you to get your updates from Windows Update whether you've got a SUS server or not.  By default, the Windows Update Automatic Updates Client (called "WUAU" or "AU" for short -- it shows up in Services as "Automatic Updates"; do you think they pronounce it "wow-OW!" in Redmond?) waits until you've established a connection out to the Internet, waits about 24 hours and then starts bugging you to allow Windows Update to grab updates for you from Microsoft's Windows Update site.  But we want AU to get its updates from our friendly neighborhood SUS server instead.  To do that, we need only reconfigure AU with a few Registry hacks or group policy settings. 

I'll tell you a secret about SUS.  SUS is deceptive -- like group policies, we tend to think that it's a server-centric tool.  The secret is that neither group policies nor SUS are primarily server-centric; in reality they're both client-centric.  All of the interesting action in SUS is on the client, AU.

You can do all of AU's initial configuration from group policies, whether local or domain-based.  You could do the client configuration with just Registry hacks, but the group policy route's usually a bit easier.  To use GPedit, the group policy editor, to control AU you must add a new administrative template named wuau.adm, which you can download at http:// /2dc07364- 2fcb-4b82-adc7-2553915997b3/wuau.adm and that's an easy download, about 25KB.  (Note that if you installed SUS 1.0 back in July 2002 then there is a new and improved wuau.adm -- you really should get it.)  Install it on a system like so:

  1. Copy the wuau.adm file to either the \windows\inf directory or the \winnt\inf directory, depending on which your OS uses, to the client machine that you want to configure.  Note that the INF directory is hidden so you'll need to make hidden files and directories visible.  If you're going to create a domain-based group policy then ensure that the wuau.adm file is in the INF directory of your domain's PDC emulator FSMO.  For my example I'll discuss local policies, as they're easier to play with, but the process is the same to create domain policies except that if you create a domain-based policy then you need not put the wuau.adm file on any system except the PDC FSMO.  (See how much easier domains make your job?)
  2. Open the group policy editor by clicking Start/Run and filling in "gpedit.msc" then clicking OK.
  3. Open up Computer Configuration, then Administrative Templates.
  4. Right-click Administrative Templates and choose "Add/Remove Templates..."
  5. Click Add... and select wuau.adm, then click the Open button, followed by the Close button.  That tells gpedit.msc about the template and you needn't do that again -- it'll remember the next time that you run gpedit.msc.
  6. Under Administrative Templates, open the Windows Components folder and you'll see a folder named "Windows Update."  Open that folder.

In that folder, you'll see four policy settings: Configure Automatic Updates Properties, Specify intranet Microsoft update service location, Reschedule Automatic Updates scheduled installations, and No auto-restart for scheduled Automatic Updates installations.

First is Configure Automatic Updates Properties.  It lets you enable or disable AU.  You enable AU either through the gpedit.msc interface, or you can enable it with a REG_DWORD Registry entry in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate called NoAutoUpdate; set it to 1 to disable AutoUpdate or 0 to enable AU.  (Of course, I recommend 0.)

Assuming that you enable AU, you can then set three parameters.  The first is an overall options setting called "Configure automatic update" which actually sets a Registry entry in the above key named AUOptions.  It's a REG_DWORD that can take three values:

  • 2 = run AU, but ask the user before downloading or installing patches
  • 3 = run AU and download patches without asking, but ask the user before installing those patches
  • 4 = almost fully automated:  download and install the patches without asking

You'll almost certainly want to choose option 4, where AU doesn't bother the users, but instead just downloads and installs the patches that you've approved on your SUS server automatically.  If you've chosen option 4 then you've also got to tell AU how often to look for patches, and what time of day to start installing them.  The group policy editor calls those settings "Scheduled install day" and "Scheduled install time" and they are stored in the Registry as REG_DWORD values in the same WindowsUpdate key as AUOptions and are named ScheduledInstallDay and ScheduledInstallTime.  ScheduledInstallDay takes eight possible values:

  • 0 = check every day
  • 1 = check once a week every Sunday
  • 2 = check once a week every Monday, and so on until ...
  • 7= check once a week every Saturday

I'd suggest setting 0, every day, as the overhead to go ask if there's any new patches is not great.  On that day (or days), AU goes to your SUS server and asks, "are there any new updates?"  If there are, then the AU client uses the Background Intelligent Transfer Service (BITS) to download the patches, which uses bandwidth throttling to ensure that those downloads don't hog your LAN capacity.  In Newsletter #36 I covered a program included in Support Tools called bitsadmin.exe that you can use to see what BITS download "jobs" you have running.  Assuming that you've installed bitsadmin.exe, you can find out what's pending at the moment by opening a command line and typing

bitsadmin /list /allusers /verbose

You usually won't see anything, as most patches are really small and of course LANs run at a minimum of 10 Mbps.  But set up a system to suck down XP SP1 and you might have a chance to see bitsadmin in action.  Or you might get to use bitsadmin to find out when an update is "stuck in the drain," as I'll discuss later.

AU stores patches in C:\WUTEMP or C:\ProgramFiles\WindowsUpdate\wuaudnld.tmp while waiting to install the patches.  (It uses C:\WUTEMP if you're downloading from the Microsoft Windows Update site, or wuaudnld.tmp if you're downloading from a SUS server.  I'll say "WUTEMP" from this point on but remember, the specific location will vary depending on whether you're using the Windows Update site or a SUS server.)  As installing patches may change the computer's behavior and may require a reboot, AU needs to know when to start installing the patches and, if necessary, to automatically reboot the system.   But don't assume that every patch involves a reboot.  For example, July 2003's MS03-026 patch against the Blaster worm did not require a reboot.  The ScheduledInstallTime value, another Registry REG_DWORD, tells AU when to start applying patches.  It takes an integer value from 0 to 23 corresponding to an on-the-hour time between midnight (0) and 11 PM (23).  You can't tell it to start installing on a partial hour, like 3:30 AM or 10:45 PM.  The default is 3 AM and that's probably a good one.  Note that setting an install time of 3 AM doesn't mean that your systems will reboot every day at 3 AM, as Microsoft doesn't release patches every day (yet), and even on days when you get some new patches then it might take AU a while to actually install the patches.  Only then, assuming that the patches need a reboot, will AU reboot the system.  Think of AU as having several phases:

  • Detect: the client asks the SUS or Windows Update Server, "do you have any new updates for me?"  You affect that with ScheduledInstallDay.
  • Download:  the client downloads the patch to C:\WUTEMP or C:\Program Files\Windows Update\wuaudnld.tmp.
  • Install: the client takes the patch files and overwrites their old versions.  You affect that with ScheduledInstallTime.
  • Reboot: if necessary, the client reboots.  As you'll see a bit later, you affect this with a Registry entry NoAutoRebootWithLoggedOnUsers or a policy "No auto-restart for scheduled Automatic Updates installations"

You won't be able to predict exactly when the "detect" phase happens.  Within the day or days that you've configured AU to check for updates, it waits 17 to 22 hours -- "17 to 22" because AU chooses a random number so that every system in your network doesn't hammer your SUS server at the same time.  As you've already read, if the SUS server says that yes, it does indeed have patches, then AU starts downloading them immediately.  You can, however, goose AU into re-detecting and downloading with a bit of Registry hacking.

Type these two commands at a command prompt:

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v LastWaitTimeout /f
net stop "automatic updates" & net start "automatic updates"

Zapping the LastWaitTimeout and restarting the Automatic Updates service seems to cause AU to say "oh, no, I have no idea when I last detected, I'd better do it now!"  That starts a detect and a download, but does not force the install phase to happen.  As I said, I'm not sure how to force that.  But if you think that this partial process would be useful -- and it could be, as it ensures that any new-to-SUS updates will be immediately downloaded and will get installed at 3 AM or whenever you set ScheduledInstallTime for, instead of your patches waiting another day or even a week to be downloaded.  And if that looks like a lot of typing, then you can always type those two commands into Notepad and save them as a file named "restartau.cmd" to create a quite convenient batch file.

And speaking of predictability, let me stress something:  you can't exactly predict when the AU client will cause your system to reboot.  I mention this because if you're like me then you'll want to test SUS before rolling it out, and so you'll probably set up a little test network and see the thing actually work.  In my case I created a SUS server on a VMWare virtual machine and downloaded all of the Microsoft patches to the SUS server, and then configured an XP virtual machine to look to the SUS server and commence installing at 3 PM.  I then left the VMWare setup alone, set a reminder for myself to check it at 3 PM and went off to do some other work.

As 3 o'clock neared, I pulled up the XP virtual machine and waited for the second hand to reach the 12.  It did, and no reboot.  A minute went by and no reboot.  And another.  Just what the heck is going on, I thought... and it rebooted.  There had been so many patches that it took the machine a few minutes to install them, and it rebooted at 3:05 PM.  So don't panic if your test systems don't reboot at your configured "install" time -- "install" doesn't mean "reboot," it means "start copying the patch files to their destinations and then reboot."

This all sounds good so far, but wait a minute... what if you set the ScheduledInstallTime to, say, 3 AM, but your users turn their systems off every night?  That would mean that their systems are never turned on at install time!  Or, what if you don't want AU to reboot your system without your permission?  Those are the jobs of the "Reschedule Automatic Updates scheduled installations" and "No auto-restart for scheduled Automatic Updates installations policy settings."  (I know I skipped one of the policy settings, "Specify intranet Microsoft update service location," and I'll come back to it in a minute.)

The first one, "Reschedule Automatic Updates scheduled installations," tells AU to wake up whenever the computer's rebooted and ask:  do I have some patches to install, and if I do, is it after the install time?  So if I've set my workstation to install patches at 3 AM but the workstation was off from 8 PM to 8 AM, then when my system wakes up then AU says "gosh, I've had all these patches that I was supposed to install at 3 AM, but it's five hours after that!  I'd better get on the ball and start installing!" and this policy setting, if enabled, tells AU how many minutes to wait after system startup to begin the tardy install.  When you set that policy it's stored in the same Registry key as the other settings we've seen so far and is a REG_DWORD entry called RescheduleWaitTime.  I set this to a small value -- 1 is the smallest, 0 doesn't work and negative numbers would be quite interesting if possible -- because it appears to me that users tend to turn on their computers in the morning and then go get some coffee.  I figure that if the system's got to boot up, install a patch or two quickly and then reboot, then the users might not even notice the extra reboot.

If you don't want AU to reboot a system automatically, then look at the policy "No auto-restart for scheduled Automatic Updates installations."  Enable it to strip AU of the power to reboot your system (I don't recommend that), or disable it to let AU do reboots when it needs to.  That setting lives in the Registry as NoAutoRebootWithLoggedOnUsers as, again, a REG_DWORD.  1 means don't let AU reboot, 0 means let AU reboot.

Finally, you've got to tell AU not to look to Microsoft's Windows Updates web site and instead to your SUS server.  You do that with the "Specify intranet Microsoft update service location" policy.  It wants two URLs:  the URL of the SUS server, and the URL of a "statistics" server.  In most cases you'll set these URLs to the same value.  The "statistics" (they're pretty weak) are actually information stored in the Web server's IIS log.  I say they're pretty weak, but they're about the only centralized SUS reporting tool around.  If you do want to try to squeeze some data out of your SUS server's log, then a kind soul named Wayne Flynn has written a program that will read your log and put it in a somewhat more useful format.  You can find his analyzer at and it's free.

Three Registry entries correspond to this policy.  The first, in the same key as the others, is the REG_DWORD setting UseWUServer.  Set it to 1 to tell AU to use your SUS server, or remove the entry to tell your system to go to the Microsoft Windows Update site.  Then, in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate key, create REG_SZ values WUServer and WUStatusServer and fill them with the URLs of the SUS server and the statistics server.  Again, in most cases they'll be the same.  The server name should be an entire URL, as in "http://mysusserver" or "" for things to work right.

Keeping Track of SUS

How do we know if our client systems are getting any patches and not running into trouble?  Here are a few ways to keep tabs on your Automatic Update clients.

First, there's Wayne Flynn's SUS log analyzer, as I mentioned earlier.

Second, you can visit a client machine and look in either \winnt or \windows for a file called WindowsUpdate.Log.  It's a text file and tracks the client activity.  When you come across a "FAILURE" line, then here are some of the most common errors you might see:

  • 0x80190194:  this is like a regular "unable to find page" or "404" error.  It arises because SUS's list of available patches is the same list as Windows Update's list.  But remember, Windows Update has more than just critical updates -- it's got drivers and non-critical updates.  So your AU client says "hey, SUS server, that new driver sounds cool, can I have it?" and your SUS server has to respond "uh, actually no, you can't have it, I don't have it" and you get the error.  The bottom line is:  when you see this error, you probably don't have anything to worry about.  Note any AU error starting with 0x8019 are actually re-packaged HTTP errors.  Take the rightmost three digits -- 194 in this case -- and convert them from hex to decimal.  "194" hex converts to "404" in HTTP.  Thus, 0x80190193 is a 403 error, 0x80190191 is a 401 error, and so on.
  • 0x80070052:  updates are delivered in a "cab" file format and must be "un-cabbed," but for some reason AU couldn't open the file.  Permissions, disk space or file corruption are the likely causes.
  • 0x80072EE7: name resolution problem.  A misspelled URL or a failure in DNS or WINS can cause this.  Or you could just punch the IP address of the server into the policy/Registry setting -- "" instead of "http://sus1," for example.
  • 0x800704c7: the update was cancelled by the user.

You can find a complete list in Microsoft's white paper on SUS deployment at http:// windows2000/ docs/SUS_Deployguide_sp1.doc on pages 81-82.

Third, you can use bitsadmin as I've already said to examine the states of any download jobs.  These jobs should not in general remain in your system for very long -- yes, BITS does bandwidth throttling, but you're downloading over a LAN, which should be pretty fast, particularly as most patches are small.  (Service packs notwithstanding.)  A job that's been around for a while probably indicates trouble.  You can also examine a Registry entry called AUState in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update.  It takes a numeric value between 1 and 8:

  • 1 means "Automatic Updates is waiting for the user to run the AU setup wizard."  It's relevant for people who are running AU but not SUS.  When AU's detected that you have an Internet connection and it starts bugging you, then AUState is 1.
  • 2 means, according to the documentation, "detect pending," which is technically accurate but not too helpful.  "Detect pending" refers to the fact that AU is idle for 17 to 22 hours, and then it goes out and checks for new updates.  The process of asking about new updates is apparently also known as "detecting."  "Detect pending," then, means "AU has downloaded and installed all of the updates that it found last time and waiting for some time before checking with its update server again."
  • 3 means "AU has detected available updates and has asked the user if it can update them but the user either hasn't responded or hasn't allowed it yet."
  • 4 means "AU is downloading patch(es) right now."
  • 5 means "AU has downloaded patches to the WUTemp directory and is waiting to install them.  It is either waiting for approval from the user via the Automatic Updates user interface, or it is waiting for the scheduled hour of day to begin installing."
  • 6 means "Patches installed."
  • 7 means "Disabled."
  • 8 means "Patches installed that need a reboot but the user told Auto Updates not to reboot; AU will do nothing 
    until the next reboot."

If that sounds like too much trouble to remember then you're welcome to run a little VBScript that I wrote to read the local system's Registry and report its status.  It's at  You may also like a short batch file at http:// which dumps the three Registry keys relevant to the Automatic Update client.

SUS Tips and Tricks

As you use SUS you'll find that certain techniques can be valuable and puzzling things that occur.

Even though AU's set to "4" (do everything automatically, don't ask the user) it's prompting me whether or not it can start installing

AU's option 4 behaves a bit strangely when a local administrator is logged in.  If you're sitting at a system and AU is thinking that it'd like to install some patches, it stops until the user okays the installs.  This seems a goofy thing -- why should it forgo its nice automatic operation just because an admin's sitting at the computer? -- but it's a fact.  There doesn't seem to be a way around it, short of logging off and letting AU do what it normally does, or just putting up with it and responding to the wizard.  It's also kind of a bummer for those folks who give all of their users local administrative powers.

If a patch requires a reboot and you've forestalled a reboot, then no more updates get downloaded

Suppose you're one of those folks for whom server reboots are verboten, no matter what time of day.  So you deny AU the ability to initiate a reboot.  On Day 1 a patch comes down that requires a reboot.  AU downloads and installs it, but can't reboot and you don't reboot the server.  On Day 2 another patch appears on SUS, a patch that does not require a reboot.  Oddly enough, the AU client ignores it and all other new patches.  AU doesn't bother asking SUS if there are new patches ("detecting,") and therefore does not download or install any other patches.  Just another reason to let AU reboot your system when necessary!

Un-approving an update doesn't remove it

Unlike group policies, removing your approval for a patch doesn't cause the AU client to uninstall it.

Set your SUS server's install times different from other systems'

This wasn't my idea and I forget where I read it -- if the author's reading this, my apologies -- but remember that "statistics server" function that SUS includes?  Well, some of the most interesting statistics are the "such-and-such system installed XYZ patch without trouble."  But recall that some patches involve a reboot.  Which means that if your SUS server is installing patches at the same time as every other system on the network then there's a good chance that it is rebooting at the same time that some client is reporting trouble... and so it loses the client report.  Thus, it might make sense to install patches on the SUS server at different times than other systems.

SUS doesn't recognize domains or, really, even security

Note that there isn't any "security" built into SUS servers in the sense that by default any SUS server will accept requests from any AU client.  Thus, if for some reason you wanted to, you could put a SUS server on the Internet, advertise its URL and anyone could set their systems up to suck patches off it.  For example, I meet a lot of consultants who make a living installing and then remotely supporting a few dozen Small Business Server (SBS) networks.  Such a consultant might want their clients to remain up to date patch-wise but might not feel that those clients are expert enough to pick and choose among all of the patches out there, and so I suppose that such a person might host an IIS box on the Internet.  He or she could then set up an HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate key and export it as a .REG file and from there could apply that REG file to any system on a client site.  From that point on, the client's machine would visit the consultant's IIS/SUS server and remain in a state of grace patch-wise.

If your client's clock is off, AU might not work

Paul Bowles of the University of Georgia related an interesting story to me a while back.  Apparently he had some systems that weren't getting updates.  The problem?  Their clocks were way off.  So if you're not running an AD -- which includes time synchronization automatically -- then you should do something to ensure that your network's clocks are all roughly in sync.

Is SUS Right For You?

SUS isn't a complete solution for anyone because, as I've already said, it handles only critical OS patches for 2000 and later.  A more complete solution might include products like Shavlik's HFNetChkPro, NWTech's UpdateExpert, Systems Management Server or some other tool.  But as a quick and (relatively) easy way to roll out Windows patches I'd recommend it to even the smallest businesses.

No, it's not a perfect tool.  But the prevalence of the Blaster worm last year despite entreaties from Microsoft, the US Office of Homeland Security, and many industry experts to get and apply the MS03-026 patch demonstrated that far too many people don't patch, and from my point of view that's just plain terrible.

When I issued a bulletin of my own last July suggesting that folks get and apply the patch, four readers e-mailed me and angrily excoriated me for suggesting that people use this "untested" patch.  I frankly have trouble understanding that.  The MS03-026 patch clearly said that the risk was "run code of attacker's choice."  In other words, someone exploiting this bug could do anything that he or she wanted on your computer.  Delete your files.  Publish your PST on the Internet.  Send embarrassing e-mail in your name.  Anything.  It's hard to understand what could be worse than that.  Other folks argued that the patch wasn't that important, as they had a firewall in place.  That's a common thought, so permit me to take a moment and make an important (well, okay, maybe just important to me) point:

Firewalls don't protect you as much as many people think they do.

You probably know that the SQL Slammer worm that hit the Internet in January 2003 crashed the network at a nuclear power plant outside Columbus, Ohio.  (It was down for maintenance at the time, so nothing ... interesting ... happened.)  How could it happen, one network manager was quoted as saying?  Simple:  someone brought in a laptop infected with Slammer.

Yes, firewalls have their value -- they slow down the bad guys.  But they don't stop them.  Firewalls are Maginot Lines.  All you need is for one person to set up a wireless network without proper protection, or one person to bring an infected laptop inside the network, and in a twinkling the firewall's been neutralized.

Yes, it doesn't always make sense to apply every patch that comes out of Redmond blindly.  But once or twice a year you see a patch for an "run code of attacker's choice" bug and in that case I'd say patch... and patch quickly! ... and that's when you'll like having SUS around.

I've been a big SUS fan since it first came out; I hope these tips included something for both SUS vets and tyros!


Join me at one of these great shows.

Microsoft Security Roadshow, Version 2

With 19 cities to go, there's probably one near you.  All new stuff, no re-runs, a longer show and more information.  See the notes above for more details.

Windows Connections April 4-7, Las Vegas

The magazine that I write for, Windows and .NET Magazine, holds its next Windows Magazine Live! conference in Sin City this April.  It's a jam-packed set of great talks by some great speakers including of the Microsoft tech world's foremost megacephaloids like Mark Russinovich, IIS Answer Man Brett Hill, Uberscripter Bob Wells, Steve Riley and Mike Danseglio (imagine, they got all three of Microsoft's best speakers) and more great speakers all and really smart guys.  I'm also doing three talks, more details on that as the show gets closer.  Watch for more info on this show, coming to The Land Of Wayne Newton.

Help Desk International Annual Conference and Expo April 17-21, Orlando

HDI has always been the place to go for help desk and support folks and this year's 15th gathering is no exception.  I'm doing a half-day version of my Securing Microsoft Networks talk, a short version of the talk and passing along the latest on Longhorn, as well as a few other talks.  Visit for more info.

Bring Mark to your site to teach

I'm keeping busy doing Active Directory and XP seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000, XP, Active Directory and 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, and other organizations that I've assisted, either take a peek at the course outlines at, mail our assistant Jean Snead at, or call her at (757) 426-1431 (only between 11-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I'd like very much to expand this periodical into a useful source of NT/2000/2003/XP information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 30,000 subscribers and I hope to use this to get information to every single Mastering 2003, XP, NT and 2000 Server reader. Thanks for letting me visit with you, and take care.  Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at and please join us at the Forum with technical questions at

To subscribe, visit To change e-mail, format, etc., link to  To unsubscribe, link to Visit the Archives at Please do NOT reply to this mail; for comments, please link to

All contents copyright 2004 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.