One major annoyance I ran into recently
occurred with a new, out-of-the-box machine
running Windows Vista Business. The machine
correctly received the Group Policy Object
(GPO) containing its update settings, including
the correct WSUS server. However, the
machine refused to download any updates.
Searching the WindowsUpdate.log file, then
searching the Microsoft Support Knowledge
Base for the error code, I found the solution—
stop the Automatic Updates service, empty
the SoftwareDistribution directory under the
Windows installation directory, then restart the
Automatic Updates service.
When a Patch Is Too Big
The problem of a patch being too big
drove me up a wall. I had purchased
an HP server and was eager to get it
up and running to test Microsoft
Forefront Client Security. The
server hardware was running
flawlessly, as was Windows. I had
no trouble installing many of the base
components required for Forefront Client
Security, including WSUS 3.0 and Microsoft
SQL Server 2005. Before I installed Forefront
Client Security itself, I decided to take one
more trip to Microsoft Update to ensure
that none of the products I had just installed
required any updating.
As it turned out, part of the SQL Server 2005
installation included some Microsoft Visual
Studio 2005 components. Visual Studio 2005
SP 1 was available, so I fired off the download
and installation. The installation failed. I didn’t
bother to note the error code, figuring it was a
transient error. It was the end of the day so I
decided to shut the server down and try again
the next morning.
The definition of insanity is performing
the same task repeatedly and expecting different
results, yet insanely I repeated the same
steps the next morning, in hopes of a different
outcome. I got the same results, of course.
Thinking it might be a problem with Microsoft
Update, I downloaded VS SP1 directly from
the Microsoft Download Center, bypassing
Microsoft Update entirely.
As you might have guessed, installing
VS SP1 by this method produced the same
result. Having installed VS SP1 several times
previously on machines that were far less
“clean” than this one, I was perplexed. I
did, however, wisely note the error code I
had been repeatedly given: Error 1718. File
[.msp filename of SP1] was rejected by digital
signature policy.
The error code was even more perplexing
as I was certain this machine had no policy
on it that would prevent this installation.
Furthermore, I couldn’t imagine that this
file wasn’t correctly signed by Microsoft.
Off to the Microsoft Knowledge Base I went,
where I found the Microsoft article (support
.microsoft.com/kb/925336/en-us) detailing
my exact problem and offering a link to the
hotfix that corrects it. In short, Windows
Installer attempts to load the entire .msp
package to verify the digital signature but
can’t allocate enough contiguous memory
and fails with the error above.
Sometimes a transient error isn’t transient at
all. When a patch is annoying you, save yourself
a heap of time by taking five minutes to research
it before you wildly try to fix the problem.
Update Déjà Vu
I’ve seen another problem occur numerous
times, and it’s still as annoying as it was the first
time I encountered it. Here’s what happens:
You download updates via Windows Update.
You restart with a heavy sigh, then return to
Windows Update only to find the exact same
update offered to you again. Thinking the
update didn’t install properly, you install it
again and restart. Windows Update continues
to offer you the same update. What gives?
In some cases, the update truly isn’t
installed. Verify that the update is indeed
installed by looking in your update history at
the Windows Update site. The update status
column should read “successful.”
In other cases, the detection logic that
Microsoft provided for this particular update
has a problem that is causing Windows
Update to think that you haven’t installed
the update when you already have. Although
you can’t fix this yourself—Microsoft has
to correct the detection logic—the update
was successfully installed and is working,
but Windows Update doesn’t realize it. The
MSRC blog is a good first stop if you think
you’re having this problem, as members
of the MSRC team will almost always drop
a note indicating that the detection logic
needs to be changed.
Computers Missing in
Action
The problem of computers missing in action is
only slightly less annoying than the repetition
of updates. You’re missing one or more computers
in your WSUS console. You know the
settings have been correctly deployed with
Group Policy as some computers are showing
up, but some never appear no matter what
you try.
Computers can go missing if a Windows
installation wasn’t prepared for image duplication
by using Sysprep. Subsequent images
therefore have a duplicate SusClientID in
the registry. It’s unlikely that you’ll run into
this problem on a regular basis and the
fix for it is relatively easy. First, stop the
Automatic Updates service on the computer
experiencing the problem. Then, start the
registry editor and navigate to the HKEY_
LOCAL_MACHINE\SOFTWARE\Microsoft Windows\CurrentVersion\WindowsUpdate
subkey and delete the PingID, AccountDomainSid
and SusClientId entries. Restart the
Automatic Updates service, then run the following
from a command prompt:
wuauclt.exe /resetauthorization /detectnow
You can also use the /detectnow switch (without
/resetauthorization) if you’ve recently
approved updates on your WSUS server and
want to force a machine to run a detection
cycle prior to the next scheduled cycle.
The Long Haul
No piece of software is perfect. Despite the
annoyances they cause, patches are here to
stay. The trick to managing them is to be
informed, stay vigilant, and get up-to-date!
End of Article
Prev. page
1
[2]
next page -->
