Fix for 0x8024400E Errors on WSUS Clients

I've seen this happen with two customers over the past few weeks, so I figure it might be prevalent enough to blog about it.

Symptom:
Some, but not all, WSUS clients begin to fail when checking for updates. The %windir%\WindowsUpdate.log file shows errors such as:

• WARNING: SyncUpdates failure, error = 0x8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200


• WARNING: PTError: 0x8024400e


• WARNING: Failed to synchronize, error = 0x8024400E


• WARNING: WU client failed Searching for update with error 0x8024400e

According to the Comprehensive List of WSUS Codes page hosted on this blog, the 0x8024400e error means "SUS_E_PT_SOAP_SERVER: The message was OK but server couldn't process at the moment. Same message *may* succeed at a later time." Huh? I already took a shower this morning! What's with this SOAP business?

The Fix:
This problem is due to problem with a recent revision to the Office 2003 Service Pack 1 update on the WSUS server. It results in some WSUS 3.X servers syncing that revision to an inconsistent state. When computer with products related to Office 2003 communicate to one of these WSUS servers, the web service is unable to process the approvals resulting in detection failure.

In order to reset the approvals to a consistent state on the WSUS server, follow these steps from the WSUS Administration Console:

1. Find the 'Office 2003 Service Pack 1' update in the updates list. This may involve changing the Approval and Status filters in the update UI (set the Status to "Any" and the Approval to "Declined" -- if you don't see it then set the Approval to "Any except Declined"


2. Perform the following steps:


• First, make sure the update is declined. If the update is not yet declined, right-click on the update and decline it.


• Next, approve the update:


• Right-click on the update and select the 'Approve...' option in the context menu.


• In the 'Approve Updates' dialog that opens, just click 'OK'. Dismiss the 'Approval Progress' dialog that appears.


• Next, decline the update.


• Right-click on the update and select the 'Approve...' option in the context menu.


• In the 'Approve Updates' dialog that opens, just click 'OK'. Dismiss the 'Approval Progress' dialog that appears.

The computers that were failing detection will now successfully complete detection against the server and receive any applicable updates.

Note: If you have a hierarchy of WSUS servers, these steps must be performed on each server, starting with the top-level server. If one of the servers is a replica child, one must first change it to be autonomous, then perform the steps above, then change it back to being a replica. This can be done from the Options/Update Source and Proxy Server Dialog.

Read more ...

MDOP Charter Member

I passed the 70-656 Microsoft Desktop Optimization Pack, Configuring exam this weekend. This exam covers the value-add features for Microsoft customers who have Windows Vista Enterprise with Software Assurance.

Windows Vista Enterprise and the Microsoft Desktop Optimization Pack (MDOP) provides powerful technologies that will help you secure, efficiently manage, and lower the costs of your organization's desktop infrastructure.

MDOP Dynamic desktop management technologies will enable you to control your software assets, simplify desktop deployments, and create a optimized infrastructure with centrally managed services:

Microsoft Desktop Optimization Pack for Software Assurance includes the following features and enhancements:

• Microsoft SoftGrid Application Virtualization (formerly Softricity SoftGrid) transforms applications into network-available services
• Microsoft System Center Desktop Error Monitoring provides IT with awareness and insight into application and operating system failures
• Microsoft Asset Inventory Service (formerly AssetMetrix) delivers a comprehensive view of your customers' enterprise desktop software environment
• Microsoft Diagnostics and Recovery Toolset (formerly Winternals Administator’s Pak) accelerates desktop repair
• Microsoft Advanced Group Policy Management (formerly DesktopStandard GPOVault) enhances administrators' control over enterprise desktops
• Enterprise Desktop Virtualization minimizes Application to OS Compatibility Issues

Read more ...

So THAT'S the problem...

Good thing we have logs to tell us when something's CRAPI.

Read more ...

Fix for Large Framework.log files

The WMI service maintains text log files for all operating systems earlier than Windows Vista and Windows Server 2008. These log files are stored in the %SystemRoot%\System32\WBEM\Logs folder. The log files include:

• Wbemcore.log


• Wbemess.log


• Mofcomp.log


• Wmiadap.log


• Wbemprox.log


• Framework.log


• Winmgmt.log

Most of these log files are configured to automatically wrap every 64KB. When the log file reaches this limit, it is renamed to logfile.lo_ and a new log file is created. Unfortunately, this does not happen with the Framework.log file - it will continue to grow indefinitely. This came to light recently at a client site when the backup team noticed that this file was taking a very long time to back up on Exchange servers. The Framework.log files on these servers exceeded 800MB.

Microsoft wrote a TechNet support article, "The Framework.log file grows larger than 64 KB when you use WMI on a Windows Server 2003 or Windows XP computer," which explains that this is due to permissions problem with the Network Service. As the article explains, the fix is to grant the Network Service account the Delete right on the %SystemRoot%\System32\WBEM\Logs folder.

Here's how to do this for all machines in the domain using Group Policy:

1. Edit the appropriate Group Policy object for the managed computers. I used the Default Domain Policy.
   
2. Navigate to Computer Configuration, Windows Settings, Security Settings, File System
   
3. Right-click File System and select Add File...
   
4. Navigate to the %SystemRoot%\System32\WBEM\Logs folder and click OK. A security window will appear.
   
5. Add the LOCAL SERVICE and NETWORK SERVICE accounts, giving both accounts only Read and Write permissions.
   
6. Click the Advanced button.
   
7. Clear the "Inherit from parent the permission entries that apply to child objects" checkbox.
   
8. Select the NETWORK SERVICE account and click Edit.
   
9. Check Delete under the Allow column and click OK. Repeat for the LOCAL SERVICE account.
   
10. Click OK four times to close all the dialog boxes.

The new security settings will be enforced on target computers on the next Group Policy refresh. After that, the large Framework.log file will be renamed to Framework.lo_ and a new Framework.log file will be created. Once that new logfile grows beyond 64KB it will replace the large file.

Read more ...

Unlocked Workstation

I found this great graphic at http://www.unlockedworkstation.com/.

Next time you come across an unlocked workstation, just open a browser on it and go to the website. Don't forget to lock the workstation when you're done.

Read more ...

Fix for "Could not start the Automatic Updates service on local computer"

You may find that the Automatic Updates service on Windows XP is stopped with the following error:

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

This can happen when Windows XP clients attempt to start the Automatic Updates service and is due to a permissions issue. The quickest and the easiest solution would be to reset the permissions for the Automatic Updates service on the client and then start the service.

To display the current permissions of the Automatic Updates service and fix them:

1. Click Start, Run and type “cmd” to launch the Command prompt
2. From the command prompt, type: SC sdshow wuauserv
   The output will look like: D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)
3. Now, reset the permissions as follows from the command prompt (single line, wrapped for clarity):
   SC sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

We can now start the service and try to detect the Automatic Updates from the command prompt:

C:\>wuauclt.exe /detectnow

This should fix the problem.

Read more ...

Microsoft Chats with Hyper-V Unleashed Authors

A chat with the authors of Hyper-V Unleashed

Last week I attended the Windows 7 TAP Summit (TAP = Technology Adoption Program) in Redmond, WA. I'd love to tell you about all the cool things in store for Windows 7, but then I'd have to kill you.

While I was there, co-author Rand Morimoto and I were interviewed at the Microsoft campus about our book, Windows Server 2008 Hyper-V Unleashed.

Read more ...