Fix for Self-Update is Not Working in WSUS 3.0

I've noticed a number of WSUS 3.0 servers are coming up with the following error in the Application event log:

Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 13042
User: N/A
Computer: WSUS01
Description: Self-update is not working.

To fix the issue, follow these steps:

• Open IIS Manager and ensure there is a Selfupdate virtual directory in the Default Web Site. If not, create it with the Local Path pointing to C:\Program Files\Update Services\Selfupdate


• Click the Directory Security tab and ensure that Anonymous Access is allowed


• Restart IIS

Verify that the problem is fixed by running the following command at the command prompt:

C:\Program Files\Update Services\Tools\wsusutil.exe healthcheck

Then examine the Application event log for the following event:

Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 10000
User: N/A
Computer: WSUS01
Description: WSUS is working correctly.

As background, WSUS clients must connect to the SelfUpdate virtual directory to check for a new version of the WSUS client before checking for new updates. This always happens anonymously over port 80, even if WSUS is configured to use a custom port, such as port 8530.

---

Subscribe to my feed  

Subscribe to The EXPTA {blog} by Email

Fix for Failed Security Update for Microsoft XML Core Services 4.0 Service Pack 2

I recently built up a new Hyper-V virtual domain environment based on a single server image. Unfortunately, my base image had a problem downloading and installing the Security Update for Microsoft XML Core Services 4.0 Service Pack 2 (KB936181). The yellow Windows Update shield would pop up in the notification area to say the update was ready to install. I would install it, but Automatic Updates would download it again and say it needed to be installed again.

Here's what the event logs looked like:

Event Type: Information
Event Source: Windows Update Agent
Event Category: Installation Event
ID: 19
Date: 4/15/2008 Time: 7:11:59AM
User: N/A
Computer: HOSCOM
Description:Installation Successful:
Windows successfully installed the following update: Security Update for
Microsoft XML Core Services 4.0 Service Pack 2 (KB936181)

... and then almost immediately,

Event Type: Information
Event Source: Windows Update AgentEvent
Category: Installation Event
ID: 18
Date: 4/15/2008 Time: 7:12:50AM
User: N/A
Computer: HOSCOM
Description:Installation Ready: The following updates are downloaded and ready for installation. This computer is currently scheduled to install these updates on Wednesday, April 16, 2008 at 3:00 AM: - Security Update for Microsoft XML Core Services 4.0 Service Pack 2(KB936181)

Very annoying. To fix this issue, download the update from Microsoft and manually install it. The update can be found here.

---

Subscribe to my feed  

Subscribe to The EXPTA {blog} by Email

Comprehensive List of WSUS Error Codes

I came across a web page a long time ago that lists all(?) of the cryptic WSUS error codes, such as 0x0000041D. This is extremely helpful when troubleshooting WSUS logs and WindowsUpdate.log files. I've found that it's helpful for lots of other Microsoft products, as well! I saved it as a portable MHT file that you can download.

If I could remember where I found this, I would gladly give them credit.

Please to enjoy. WSUS Error Codes

---

Subscribe to my feed  

Subscribe to The EXPTA {blog} by Email

Fix for Error 0x80004015 on WSUS Clients

When you try to start the Automatic Updates service on a computer you may encounter an error stating,

Could not start Automatic Updates service on the local computer. Error 0x8000415: The class is configured to run as a security id different from the caller

I've found that this is usually caused when the service was previously configured as Disabled via Group Policy.

When you configure a service startup mode in Group Policy (Computer Configuration\Windows Settings\Security Settings\System Services), Group Policy first has you configure the security of the service in the registry. The default security settings (before you configure it in the GPO) normally includes Authenticated Users with Read and Start, Stop and Pause permissions. When you configure the service in Group Policy, Authenticated Users have no permissions. This prevents normal users from reconfiguring the service back to Automatic and starting it.

To fix this issue, set the service permissions so that Authenticated Users have Read and Start, Stop and Pause permissions on the service. This can be done the following ways:

• To reconfigure the service in Group Policy, reconfigure the service startup type to Automatic and click the Edit Permissions button. Add Authenticated Users with Read and Start, Startup and Pause permissions. Run GPUPDATE on the client machine or restart it to get the new GPO settings.


• Manually set permissions on the service using Regedit. Navigate to HKLM\SYSTEM\CurrentControlSet\Services\wuauserv. Right-click wuauserv and select Permissions. Add Authenticated Users with Read permissions.

This tip applies to any other service configured via Group Policy.

---

Subscribe to my feed  

Subscribe to The EXPTA {blog} by Email

Fixing Incorrect Directory Permissions in WSUS 3.0

I have a client with a fairly large WSUS deployment, comprised of 36 WSUS servers servicing over 10,000 computers and servers in a distributed environment. Recently, we upgraded the entire WSUS 2.0 SP1 infrastructure to WSUS 3.0. I noticed the following event on many, but not all, of the WSUS downstream servers:

Event Type: Error
Event Source: Windows Server Update Services
Event Category: Core
Event ID: 10012
Date: 1/2/2008 Time: 7:30:49 AM
User: N/A
Computer: SAFS01
Description: The permissions on directory D:\WSUS are incorrect.
For more information, see Help and Support Center at blah, blah, blah

These servers also suddenly began to fail its synchronization from the upstream server. Strangely, they all had been working fine for a few weeks after the upgrade. The solution is to modify the directory permissions as follows:

• The root folder of the local content directory must have at least Read permissions for the Users security group and the NT Authority\Network Service account. In other words, if the WSUS content directory is D:\WSUS\WSUSContent, the D:\WSUS directory must have the correct permissions. The BITS service will fail if these permissions are not set.
  
• The content directory itself (in the above example, the WSUSContent directory) must have Full Control permissions for the NT Authority\Network Service account.
  
• The temporary ASP.NET directory (%windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files) must have Full Control permissions for the NT Authority\Network Service account.
  
• The system %TEMP% directory (usually %windir%\TEMP) must have Full Control permissions for the NT Authority\Network Service account.

After the permissions have been set correctly restart the Update Services service and check the Application event log for errors. You should be able to perform a synchronization successfully now.

---

Subscribe to my feed  

Subscribe to The EXPTA {blog} by Email

Good Day Today

Today was a good session day. I got to start and end it with Marcus Murray, who finished the day to a PACKED session in the TLC Library showing how easy it is to perform a buffer overrun exploit. Scary, scary stuff. The guy is a rockstar.

Other sessions included Paul Robichaux, talking about Forefront Security for Exchange, and a good session on architecting and upgrading WSUS 3.0.

I got to see our friends at Sam's Publishing in the vendor booth. Sams publishes the Microsoft "Unleashed" series, including Microsoft Exchange Server 2007 Unleashed and Microsoft Exchange Server 2003 Unleashed, both of which I am a cowriter of. Fellow CCO consultant, Michael Noel was there at the Sams booth on Tuesday. Be sure to check out his sessions on SharePoint 2007 here at TechEd!

I'll post a summary of the items discussed at the WSUS session in a future blog. For now, I'm going to get ready for the Microsoft Influencer's Party at Margaritaville and the Double-Take party at the Hard Rock. Woo-hoo!

---

Subscribe to my feed  

Subscribe to The EXPTA {blog} by Email

Fix for Non-Responsive WSUS Clients

WSUS 2.0 Behavior of WUAU
The WSUS 2.0 version of WUAU is version 5.8.0.2607. This version has an issue that causes the CPU to race to 98-100% utilization and causes the machine to become unresponsive during the WUAU detection cycle. The cycle normally runs for about 2 minutes.

The Windows Update Automatic Update service (WUAUSERV) runs under the SVCHOST process, along with many other processes. If you look in Task Manager you may see 5-8 processes named SVCHOST.EXE. To determine which process is running WUAU, enter TASKLIST /SVC at the CMD prompt. Output will look like this:

Image Name PID Services
========================= ====== ============================================
System Idle Process 0 N/A
System 4 N/A
smss.exe 864 N/A
csrss.exe 928 N/A
winlogon.exe 952 N/A
services.exe 1004 Eventlog, PlugPlay
lsass.exe 1016 Netlogon, PolicyAgent, ProtectedStorage,
SamSs
svchost.exe 1200 DcomLaunch, TermService
svchost.exe 1268 RpcSs
svchost.exe 1912 AppMgmt, AudioSrv, CryptSvc, Dhcp, dmserver,
ERSvc, EventSystem, helpsvc, lanmanserver,
lanmanworkstation, Netman, Nla, RasMan,
Schedule, seclogon, SENS, SharedAccess,
ShellHWDetection, srservice, TapiSrv,
Themes, W32Time, winmgmt, wuauserv, WZCSVC
svchost.exe 2040 Dnscache
svchost.exe 480 Alerter, LmHosts, RemoteRegistry, SSDPSRV,
WebClient
spoolsv.exe 664 Spooler
FrameworkService.exe 1568 McAfeeFramework
mcshield.exe 1668 McShield

In this example you can see that PID 1912 is running wuauserv (Windows Update Automatic Update Service).

WSUS 3.0 Behavior of WUAU
The fix for this behavior is to install the new Windows Update Agent 3.0 (WUAU version 7.0.6000.374) and the hotfix KB927891. Both the new agent and the hotfix must be installed to correct the bug. After both updates are installed and the computer is rebooted, SVCHOST will still take 96-99% of the CPU, but the computer will remain responsive. Occasionally, I've seen it perform a little sluggishly, but nothing like it was before the updates. Microsoft says they made "deep architectural improvements" to the WUAU process, which provide greater time slicing in the SVCHOST process. This allows other processes to run while WUAU is performing a detection cycle. This fix has worked for all my clients.

Links to WSUS 3.0 Standalone Agent
http://download.windowsupdate.com/v7/windowsupdate/redist/standalone/WindowsUpdateAgent30-x86.exe
http://download.windowsupdate.com/v7/windowsupdate/redist/standalone/WindowsUpdateAgent30-x64.exe
http://download.windowsupdate.com/v7/windowsupdate/redist/standalone/WindowsUpdateAgent30-ia64.exe

Required KB 927891 Hotfix
http://support.microsoft.com/?kbid=927891

---

Subscribe to my feed  

Subscribe to The EXPTA {blog} by Email

High CPU Utilization on WSUS Clients

High CPU Utilization on WSUS Clients

Clients who uses WSUS may have noticed that when the client checks for updates the CPU climbs to 100% utilization and the computer becomes unresponsive. Microsoft released a two-tier fix for this.

First, install the hotfix listed in KB927891. There are specific versions for x86, x64 and Itanium platforms, as well as Server 2003 and XP.

Next, install the new WSUS 3.0 Agent software. This new agent will work with WSUS 2.0 or 3.0 servers.

After you install the new software you will still see the CPU peg at ~100% while the client checks for updates, but the computer will still be responsive. This is the result of "deep architectural performance optimizations" in the client software. My testing has shown substantial improvements in performance and shorter update times.

---

Subscribe to my feed  

Subscribe to The EXPTA {blog} by Email