Mark Minasi's Windows Networking Tech Page
Issue #38 January 2004
To subscribe, visit http://www.minasi.com/nwsreg.htm.
To unsubscribe, link to http://www.minasi.com/unsubs.htm.
To change e-mail address, switch between HTML or text format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.
Visit the Archives at http://www.minasi.com/archive.htm.
Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp. Document
copyright 2004 Mark Minasi.
- 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
- Active Directories Do Not Like One-Part Names
- Feature Article: Software Update Service: Patch Management From
A to Z
- 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 http://www.minasi.com/xpsupport.htm,
the Active Directory/Group Policy seminar at http://www.minasi.com/2003outln.htm,
and the schedule of seminars at http://www.minasi.com/pubsems.htm.
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
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
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
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 http://oca.microsoft.com/en/windiag.asp
-- an URL that you may recognize as being in oca.microsoft.com, 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
oca.microsoft.com 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
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
"Our network guys did something recently and now DNS is screwed
up. We can resolve your www.minasi.com
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
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 www.minasi.com?" then you get
just one IP address -- a small answer, and it fits into UDP with no
problem. But try it with sites like www.yahoo.com
or www.microsoft.com 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 "minasi.com" 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
"minasi.com" or "eastcoast.bigfirm.biz." So, the
bottom line is: make sure there's at least one period in your DNS
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 (http://windowsupdate.microsoft.com)
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
- Configure the SUS client either via the Registry or with local or domain
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
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 http://www.microsoft.com/downloads/ 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
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:
- Where shall SUS put the patches ("content")? The default
of c:\sus\content is probably fine.
- 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.
- 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 webserv2.bigfirm.biz then open up IE
and put "webserv2.bigfirm.biz/susadmin" 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
- "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
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 http://www.microsoft.com/windows2000/ 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
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:// download.microsoft.com/download/2/d/c
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:
- 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
- Open the group policy editor by clicking Start/Run and filling in "gpedit.msc"
then clicking OK.
- Open up Computer Configuration, then Administrative Templates.
- Right-click Administrative Templates and choose "Add/Remove
- 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
- Under Administrative Templates, open the Windows Components folder and
you'll see a folder named "Windows Update." Open that
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
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
- 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
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
- Download: the client downloads the patch to C:\WUTEMP or C:\Program
- 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
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
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 http://www.pdxconsulting.com/sus/
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 "http://sus.bigfirm.biz" 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
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
- 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
- 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 --
"http://10.10.14.44" instead of "http://sus1," for
- 0x800704c7: the update was cancelled by the user.
You can find a complete list in Microsoft's white paper on SUS deployment at http:// www.microsoft.com/ 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
- 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 http://www.minasi.com/seeau.vbs.
You may also like a short batch file at http:// www.minasi.com/aureg.cmd
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
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
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
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 www.winconnections.com
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 http://www.thinkhdi.com/trainingEvents/annualConference/
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 www.minasi.com/presentations.htm,
mail our assistant Jean Snead at Assistant@Minasi.com,
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 http://www.minasi.com/gethelp and
please join us at the Forum with technical questions at www.minasi.com/forum.
To subscribe, visit http://www.minasi.com/nwsreg.htm.
To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.
To unsubscribe, link to http://www.minasi.com/unsubs.htm.
Visit the Archives at http://www.minasi.com/archive.htm.
Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.
All contents copyright 2004 Mark Minasi. You are encouraged to quote this
material, SO LONG as you include this entire document; thanks.