Random Musings of Jeremy Jameson : WSUS

Forced to Decline KB948014 and KB972493 in WSUS

Jeremy Jameson — Tue, 08 Dec 2009 15:48:00 GMT

In last night's post, I discussed the solution for an issue I encountered installing KB 970892 on one of my servers. Thankfully, this morning I confirmed the server no longer increments the Computers with Errors column in the daily report I receive from Windows Server Update Services (WSUS).

I should also mention that in order to get my WSUS report to come up completely clean, I had to decline the the following updates:

Description of the Windows Server Update Services 3.0 Service Pack 1 package
http://support.microsoft.com/kb/948014
Windows Server Update Services 3.0 SP2 Dynamic Installer for Server Manager
http://support.microsoft.com/kb/972493

To be perfectly frank, I am actually rather disappointed that there doesn't seem to be any alternative to declining these updates altogether.

Up until I declined these two updates, my WSUS server complained each morning that four of my servers were not 100% patched (even though I have configured a Group Policy to automatically download and install updates every morning). The four servers that it complained about are all running Windows Server 2008.

Apparently there are known issues with these two updates -- both of which are for WSUS -- that cause them to be detected for install even on servers that are not running WSUS. [I suppose to be perfectly fair, the whole point of KB972493 is to allow you to more easily install WSUS by simply enabling a server role.]

The problem with KB 972493 started after installing Windows Server 2008 Service Pack 2 (SP2), because that includes the prerequisite patch (KB 940518).

My initial attempt at resolving the warnings in WSUS was to create a separate computer group under my existing Technology Toolbox group called WSUS Servers. I then moved COLOSSUS (my one and only WSUS server) to this new group and approved the aforementioned patches on that group alone.

Sadly, the current version of WSUS does not provide a way to decline updates for a specific group only. Instead the approval field is simply Not Approved for all computers groups except WSUS Servers.

Consequently, Windows Update would detect these two patches for install, but the subsequent install would refuse to actually apply the patches -- thus perpetually leaving all of my Windows Server 2008 SP2 servers that are not running WSUS with a "99%" Installed/Not Applicable Percentage (and also causing them to appear in the Computers Needing Updates columns in the daily WSUS report).

I really wish there were some other way to resolve the issue without declining the updates altogether -- but I certainly couldn't find one, and based on a number of support cases I read regarding similar issues, this seems to be the recommended solution.

Enforcing Windows Update via Group Policy

Jeremy Jameson — Thu, 15 Oct 2009 12:15:00 GMT

Another Group Policy object that I use in the "Jameson Datacenter" (a.k.a. my home lab) is one to automatically configure Windows Update on all computers in the domain. This ensures that each server or workstation downloads updates from COLOSSUS (one of my VMs that is running Windows Server Update Services) rather than having each computer download, for example, a 577 MB service pack directly from the Internet. It also ensures that only the updates that I have approved through WSUS are applied.

To automatically configure Windows Update in the "Jameson Datacenter", I have defined a Group Policy (named Default Windows Update Policy) with the following settings:

Computer Configuration
- Policies
  - Administrative Templates
    - Windows Components
      - Windows Update
        
        Configure Automatic Updates
        
        Enabled
        
        Configure automatic updating: 4 -Auto download and schedule the install
        
        Scheduled install day: 0 - Every day
        
        Scheduled install time: 03:00
        
        Specify intranet Microsoft update service location
        
        Enabled
        
        Set the intranet update service for detecting updates: http://colossus
        
        Set the intranet statistics server: http://colossus

By linking this Group Policy to the entire domain (i.e. corp.technologytoolbox.com) Windows Update is automatically configured as soon as new computers are joined to the domain and rebooted.

This enables me to spin up new VMs with very little effort. More importantly, it takes less than a half hour to get a new Windows Server 2008 VM with all the latest patches (since I start from a SysPrep'ed VHD with Windows Server 2008 Service Pack 2).

Errors Installing Windows Server 2008 SP2

Jeremy Jameson — Mon, 01 Jun 2009 17:14:00 GMT

Last week I approved Windows Server 2008 Service Pack 2 (SP2) and Windows Vista SP2 on my local WSUS (Windows Server Update Services) server. My expectation was that the various physical and virtual machines in the "Jameson Datacenter" would subsequently install the update around 3:00 AM the following morning.

Unfortunately when I examined the WSUS console this morning, I found a number of computers reporting errors. After selecting one of the failed computers, I discovered the following:

Windows Server 2008 Service Pack 2 Standalone x64-based Systems (KB948465) - English, French, German, Japanese, Spanish

Event reported at 6/1/2009 3:02 AM:

Installation Failure: Windows failed to install the following update with error 0x80070643: Windows Server 2008 Service Pack 2 Standalone x64-based Systems (KB948465) - English, French, German, Japanese, Spanish.

A quick search for 0x80070643 led to the following KB article:

You receive error code 0x80070643 or error code 0x643 when you use the Windows Update or Microsoft Update Web sites to install updates

http://support.microsoft.com/kb/958052

Unfortunately, this error code indicates "generic errors that basically state that an error was encountered by Windows Installer." Rather than immediately following the steps in the KB article to enable logging and try to reproduce the problem, I decided to take a quick look at the event logs and discovered the following:

Log Name: System
Source: Microsoft-Windows-Service Pack Installer
Date: 6/1/2009 3:02:00 AM
Event ID: 8
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: dazzler.corp.technologytoolbox.com
Description:
Service Pack installation failed with error code 0x800f0826.

Another quick search for 0x800f0826 suggested that the problem might be due to insufficient disk space. However, I checked the free space on DAZZLER and observed that it had 4.09 GB free. Surely, 4 GB of disk space is sufficient to install Windows Server 2008 SP2!

Then I came across the following:

Windows Server 2008 SP2 Deployment Guide

http://technet.microsoft.com/en-us/library/dd351467(WS.10).aspx

Here are the disk space requirements according to the deployment guide:

Disk Space Requirements for Windows Server 2008 SP2
Installation method	Approximate disk space requirements
Stand-alone installation	x86-based: 1.8 GB to 2.9 GB x64-based: 3.2 GB to 4.9 GB ia64-based: 2.9 GB to 3.2 GB
Windows Update	x86-based: 350 MB x64-based: 600 MB ia64-based: 2.25 GB
Integrated installation	x86-based: 9 GB x64-based: 12 GB ia64-based: 13 GB

Crikey! According to this table, DAZZLER needs up to 4.9 GB of free space in order to install the Service Pack (since it is an x64 VM). Wow!

This, quite honestly, seems absolutely absurd!

However, given that it is relatively easy to expand a VHD, I decided to just go ahead and add another 2 GB to the system drive on the VM and see if that eliminated the issue. After all, as long as SP2 doesn't actually use 4.9 GB of space, then the actual physical space consumed by the VHD should be significantly less than 5 GB.

Using Hyper-V Manager, I expanded the VHD from 20 GB to 22 GB and then started the VM up again. I then logged into the VM and used the Disk Management console to extend the volume to include the additional 2 GB of available storage.

Next, I kicked off the installation of Windows Server 2008 SP2 again. This time the installation completed without error. Woohoo!

Note that DAZZLER is a dedicated Team Foundation Server "build server" -- so I didn't expect that it would need lots of disk space. In fact, it didn't -- at least not until Windows Server 2008 SP2 came along.

Now all I have to do is add some more disk space to the other servers that are failing to install SP2.

WSUS Server Cleanup Wizard Hangs on "Deleting unused updates..."

Jeremy Jameson — Sat, 28 Mar 2009 15:20:00 GMT

While cleaning off my Desktop this morning, I came across a file that I created back in December capturing my notes from a problem I was having with Windows Server Update Services (WSUS). Evidently I intended to blog about the issue, but apparently this task kept getting pushed to the back burner. Before moving on to more fun things today, I thought I should get this off my to-do list.

Back in December, I noticed that my local WSUS server showed that I had 24,890 updates downloaded and available for install. I remember thinking something to the effect of: "Wow, that's a lot of updates!"

Looking at my C:\WSUS folder (where the updates are downloaded), I found that it contained the following:

51.4 GB of content
6,509 files in 258 folders

I then ran the WSUS Server Cleanup Wizard as I had attempted (unsuccessfully) on several occasions in the past, selecting all of the options:

Unused updates and update revisions
Computers not contacting the server
Unneeded update files
Expired updates
Superseded updates

As with my previous attempts, the cleanup appeared to hang on the following step:

Deleting unused updates...

I decided that I should try to show a little more patience than I had in the past and consequently let it run for over 24 hours (thinking it might eventually finish). You can imagine my frustration when I came back the next morning only to find that it was still "Deleting unused updates..."

I then tried running the WsusDBMaintenance SQL script -- hoping that might somehow help the situation. Unfortunately, when I ran the Server Cleanup Wizard again, I got the same result (i.e. it hung on the "Deleting unused updates..." step).

I then ran the Server Cleanup Wizard once again, but this time only selecting the first option (Unused updates and update revisions). While it was still very, very slow on the "Deleting unused updates..." step, I was able to verify (via the progress bar) that it was in fact progressing. I let it run to completion and observed the following results when it was finished:

Unused updates deleted 3082
Unused update revisions deleted: 5448

I then ran the Server Cleanup Wizard again, but this time only selecting the third option (Unneeded update files). When that was finished, I observed the following:

Disk space freed by deleting unused content files: 15441 MB

I confirmed this by rescanning my C:\WSUS folder:

36.3 GB of content
4,285 files in 258 folders

Since December, I have been able to run the Server Cleanup Wizard repeatedly with all of the options selected, and it usually completes in a matter of minutes. For some reason, it was only that first time through that I needed to run the steps individually to avoid the hang. Go figure.

Backing Up User Databases in SQL Server (and SQL Server Express)

Jeremy Jameson — Fri, 30 May 2008 17:22:00 GMT

Since I appear to be on a roll with my blog this morning, I figured that I should write one more post about SQL Server before I get back to my "day job."

I typically use SQL Server Management Studio to configure and schedule database backups, because the Maintenance Plan Wizard makes it very quick and easy to click through a few screens and select the appropriate options. However, on some of the servers running in the "Jameson Datacenter" (a.k.a. my basement), I only have SQL Server Express installed, not the full SQL Server product. For example, on my server that runs Windows Server Update Services (WSUS), I use SQL Server Express as the "backend" storage solution, because for this particular scenario, I want to keep the database local instead of relying on a separate server. However, I still want to ensure that I have periodic backups of the databases.

In order to make this as painless as possible, I wrote the following script:

USE [Tools]
GO
/****** Object:  StoredProcedure [dbo].[BackupUserDatabases]    Script Date: 03/15/2007 07:55:44 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROC [dbo].[BackupUserDatabases]
(
    @backupType VARCHAR(15)
)
AS

DECLARE @backupFolder VARCHAR(255)

SET @backupFolder = 'C:\BackedUp\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\' + @backupType

DECLARE @timestamp DATETIME
DECLARE @dateString VARCHAR(8)
DECLARE @timeString VARCHAR(12)

SELECT @timestamp = GETDATE()

SELECT @dateString = CONVERT(VARCHAR(8), @timestamp, 112)

SELECT @timeString = CONVERT(VARCHAR(12), @timestamp, 14)

-- Remove seconds from timestamp
SET @timeString = LEFT(REPLACE(@timeString,':',''), 4)

DECLARE @databases TABLE
(
    ID INT IDENTITY ( 1, 1 )
    , DatabaseName SYSNAME
)

INSERT INTO
    @databases 
    SELECT name
    FROM master.dbo.sysdatabases 
    WHERE name NOT IN ( 'master', 'model', 'msdb', 'tempdb' )

DECLARE @id TINYINT
SELECT @id = MIN ( ID ) FROM @databases

WHILE @id IS NOT NULL BEGIN
    DECLARE @databaseName SYSNAME
    SELECT @databaseName = DatabaseName FROM @databases WHERE ID = @id

    DECLARE @backupFileName VARCHAR(512)
    SELECT @backupFileName = @databaseName + '_backup_' +@dateString + @timeString + '.bak'

    IF @backupType = 'Full'
    BEGIN
        EXEC ('BACKUP DATABASE [' + @databaseName + '] TO DISK =''' + @backupFolder + '\' + @BackupFileName + '''')
    END
    ELSE IF @backupType = 'Differential'
    BEGIN
        EXEC ('BACKUP DATABASE [' + @databaseName + '] TO DISK =''' + @backupFolder + '\' + @BackupFileName + ''' WITH DIFFERENTIAL')
    END
    ELSE IF @backupType = 'Transaction Log'
    BEGIN
        DECLARE @recoveryModel SQL_VARIANT

        SELECT @recoveryModel = DATABASEPROPERTYEX(@databaseName, 'Recovery')

        IF @recoveryModel <> 'SIMPLE'
        BEGIN
            EXEC ('BACKUP LOG [' + @databaseName + '] TO DISK =''' + @backupFolder + '\' + @BackupFileName + '''')
        END
    END
    ELSE
    BEGIN
        RAISERROR ('Invalid backup type', 16, 1)
    END

    DELETE FROM @databases WHERE ID = @id

    SELECT @id = MIN ( ID ) FROM @databases
END

Well, technically, it's a stored procedure, but nevertheless I still keep the script to generate the sproc in my toolbox: BackupUserDatabases.sql. Notice that I create the sproc in a separate database (I arbitrarily chose the name Tools).

I can then schedule full, differential, and transaction log backups using scheduled tasks, as shown below.

Figure 1: Scheduled tasks for backing up databases

See full-sized image.

Here is the command behind one of the scheduled tasks (you can easily deduce the others):

"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE" -S .\SQLExpress -d Tools -Q "EXEC BackupUserDatabases @backupType='Full'"

Lastly, note that I have a separate server periodically ROBOCOPY the backup files off of this server to another location -- just in case the WSUS server happens to catch on fire or some other act of God completely wipes out the local database backups ;-)

WSUS Clients Failing with Error 0x80244019 After Installing WSUS SP1

Jeremy Jameson — Tue, 08 Apr 2008 15:04:00 GMT

Last week I discovered that many of my servers were no longer updating successfully from my intranet Windows Server Update Services (WSUS) server. Looking in WindowsUpdate.log file, I noticed errors similar to the following:

2008-03-22 18:53:24:377 808 ba0 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190194 2008-03-22 18:53:24:377 808 ba0 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190194 2008-03-22 18:53:24:377 808 ba0 Misc WARNING: DownloadFileInternal failed for http://colossus:8530/selfupdate/wuident.cab: error 0x80190194 2008-03-22 18:53:24:377 808 ba0 Setup FATAL: IsUpdateRequired failed with error 0x80244019 2008-03-22 18:53:24:377 808 ba0 Setup WARNING: SelfUpdate: Default Service: IsUpdateRequired failed: 0x80244019 2008-03-22 18:53:24:377 808 ba0 Setup WARNING: SelfUpdate: Default Service: IsUpdateRequired failed, error = 0x80244019 2008-03-22 18:53:24:377 808 ba0 Agent * WARNING: Skipping scan, self-update check returned 0x80244019 2008-03-22 18:53:25:002 808 ba0 Agent * WARNING: Exit code = 0x80244019

Upon troubleshooting the problem, I discovered that the SelfUpdate virtual directory was not configured on my WSUS server (i.e. the server named COLOSSUS). To resolve the issue, I used IIS Manager to create the SelfUpdate virtual directory (using the local path C:\Program Files\Update Services\Selfupdate). I then used wuauclt /detectnow to force an update on one of my servers to confirm that this resolved the issue.

A little post mortem analysis further revealed the following event on COLOSSUS:

Event Type: Information
Event Source: MsiInstaller
Event Category: None
Event ID: 11724
Date: 3/22/2008
Time: 7:17:29 AM
Computer: COLOSSUS
Description:
Product: Microsoft Windows Server Update Services 3.0 -- Removal completed successfully.

Ah, yes...now it was all coming back to me. On the morning of March 22nd, I decided to install WSUS Service Pack 1 (SP1). Since I did not encounter any errors during the install, it appears that WSUS SP1 is the likely culprit for the missing SelfUpdate virtual directory.

Perhaps this only happens when you have WSUS installed on a non-standard port or when you have SharePoint installed on the WSUS server. As you can see in the excerpt from WindowsUpdate.log above, I am using port 8530 for the WSUS Web site. This is because COLOSSUS is currently running both WSUS and MOSS 2007.