WSUS not downloading to client

[bswhipp]

(Unable to Find Resource ReportingEvent.Client.167; Parameters: 2024-11 .NET 6.0.36 Update for x64 Server (KB5047486)

This is the error on the WSUS server Update Services Console. On the client, under the softwaredistribution download folder, I can see the correct filename but it is 0 kb. I can also get the file location from the WSUS server and put it into the browser of the client and it will download correctly but it will not download and rename the file and update the client. Deleted softwaredistribution and catroot2 folder to no fix.

 

[ChatGPT]

Your issue is a classic scenario where the WSUS clients can resolve the WSUS server and even access the update manually (via browser), but the automatic download and rename of the update file fails. The error Unable to Find Resource on the WSUS console and the 0 KB file in the client softwaredistribution folder typically indicates one of the following:

1. Content Distribution Issues:
   • WSUS is improperly delivering update content to clients, despite metadata synchronization being successful.
2. Permissions or Settings Problems:
   • There might be access or configuration constraints preventing the client from downloading the file correctly via the Automatic Updates service.
3. Network or IIS Configuration Problems:
   • IIS may not correctly serve update content, especially under WSUS configuration.

Let’s troubleshoot and resolve this step-by-step.

---

Steps to Fix the WSUS Client Not Downloading Issue​

Step 1: Verify WSUS Content Delivery Settings​

WSUS downloads and delivers updates using its Content directory and HTTP/HTTPS endpoints configured via IIS.

1. Check WSUS Content Directory:
   • Navigate to the WSUS Content folder (D:\WSUS\WSUSCONTENT or the equivalent path).
   • Look for the file corresponding to KB5047486 (search by partial filename).
     • Example: <GUID>.cab for .NET 6.0 Update.
   • Ensure the content exists and is non-zero in size.
2. Test IIS Delivery:
   • Open a browser on the client machine.
   • Paste the WSUS server URL for the content, such as:
     

          http://<WSUS-Server>:8530/Content/<GUID>.cab

   • If the file downloads successfully in the browser but not via the Windows Update client, the issue likely lies with IIS permissions or WSUS client-side configurations.

---

Step 2: Test Connectivity Between Client and WSUS​

The client must be correctly configured via Group Policy or Local Policy to communicate with the WSUS server.

1. Run wuauclt or usoclient Sync Command:
   • On the affected client, force synchronization:
     

     bash
          wuauclt /reportnow
          wuauclt /detectnow

   • Alternatively, on newer builds:
     

     bash
          usoclient StartScan

2. Inspect WindowsUpdate.log:
   • Use PowerShell to read the logs:
     

     bash
          Get-WinEvent -LogName Microsoft-Windows-WindowsUpdateClient/Operational | Select-String -Pattern "Error|Warning"

   • Look for errors related to downloading files or connecting to the WSUS server.
3. Confirm WSUS Server is Configured:
   • Verify the WSUS configuration on the client using PowerShell:
     

     bash
          Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate\

   • Ensure the following keys are correct:
     • WUServer: Points to your WSUS server (e.g., http://<WSUS-Server>:8530).
     • WUStatusServer: Same as WUServer.

---

Step 3: Check IIS Logs for WSUS Content Errors​

Since IIS serves update content, ensure content requests are working correctly.

1. Enable IIS Logging:
   • Navigate to IIS Manager.
   • Select the WSUS Administration site > Enable Logging.
2. Analyze IIS Logs:
   • Logs are located at:
     

          C:\inetpub\logs\LogFiles\W3SVC__

     • Search for 404 (Not Found) or 401 (Unauthorized) errors related to the content request.
3. Resolve common IIS errors:
   • 404 Not Found: Ensure the content file exists in the WSUSContent folder.
   • 401 Unauthorized: Verify permissions (see Step 4).

---

Step 4: Validate IIS Permissions​

Permissions issues frequently block WSUS clients from accessing content.

1. Confirm Default Application Pool Settings:
   • Open IIS Manager and look under Application Pools > WsusPool.
   • Ensure:
     • Identity: ApplicationPoolIdentity.
     • Managed Pipeline Mode: Integrated.
2. Fix File System Permissions:
   • Navigate to the WSUS Content Directory (e.g., D:\WSUS\WSUSCONTENT).
   • Add the following permissions:
     • IIS_IUSRS: Read & Execute.
     • NETWORK SERVICE: Read & Execute.
3. Restart IIS:
   

   bash
      iisreset

---

Step 5: Reset Windows Update Client​

If behavior persists, reset the client-side configuration and cache.

1. Stop Services:
   • On the client, stop the Windows Update services:
     

     bash
          net stop wuauserv
          net stop cryptsvc

2. Delete Cache:
   • Delete the SoftwareDistribution folder:
     

     bash
          del /f /s /q C:\Windows\SoftwareDistribution

   • Delete the catroot2 folder:
     

     bash
          del /f /s /q C:\Windows\System32\catroot2

3. Restart Services:
   

   bash
        wuauclt /reportnow
        wuauclt /detectnow

   0
4. Resync the Client:
   

   bash
        wuauclt /reportnow
        wuauclt /detectnow

   1

---

Step 6: Check WSUS Server Health​

If the issue persists across multiple clients, confirm the WSUS server's health and functionality.

1. Reindex the WSUS Database:
   • Open SQL Server Management Studio.
   • Run the spReIndexAllIndexes script to optimize the SUSDB database.
2. Perform Postinstall Repair:
   Run the WSUS utility (especially useful for IIS reconfiguration):
   

   bash
        wuauclt /reportnow
        wuauclt /detectnow

   2

---

Expected Outcomes​

• After completing these steps, the client should successfully download the update file from the WSUS server and apply it.
• If client behavior persists with 0 KB files being created, it may indicate deeper IIS or WSUS database corruption.

Let me know which steps resolved the issue (or if you hit additional errors during testing). I’m happy to assist further!

 

[bswhipp]

To much to do in this step lets slow down so I can let you know where information is
Step 1 is OK
Step 2 is OK but no information when I use Get-WinEvent -LogName Microsoft-Windows-WindowsUpdateClient/Operational | Select-String -Pattern "Error|Warning"
Step 3 nothing in the logs about 404 error
Step 4 . 1 Identity is NetworkService

 

[ChatGPT]

Got it—thanks for the feedback, and it’s great to have this narrowed down. Based on your steps, Step 1 and Step 2 are OK, and there’s no 404 error in IIS logs (Step 3). However, your application pool's identity is NetworkService instead of ApplicationPoolIdentity in Step 4.1, which might contribute to the issue.
Let’s now slow down and focus on the areas that matter to further troubleshoot and ensure WSUS clients can properly download updates.

---

Updated Steps Based on Your Feedback​

---

Step 4.1: Change Application Pool Identity​

The WsusPool application pool should use ApplicationPoolIdentity as its identity for proper functionality.

1. Switch Identity to ApplicationPoolIdentity:
   • Open IIS Manager (inetmgr).
   • Navigate to Application Pools and select WsusPool.
   • Right-click and select Advanced Settings.
   • Find Identity under Process Model.
   • Change the value from NetworkService to ApplicationPoolIdentity.
   • Click OK and restart the application pool:
     • Right-click the pool > Recycle.
2. Restart IIS services:
   

   bash
      iisreset

---

Step 4.2: Validate File System Permissions​

Misconfigured permissions could still prevent WSUS clients from receiving files.

1. Navigate to your WSUS Content Folder:
   • Example: D:\WSUS\WSUSCONTENT
2. Add or Confirm Permissions for Key Groups:
   • Right-click the folder, go to Properties > Security, and ensure the following groups have Read & Execute:
     • IIS_IUSRS
     • NETWORK SERVICE
   • If missing, add them manually:
     • Click Edit > Add..., enter the group name (e.g., IIS_IUSRS), and grant the proper permissions.
3. Apply Permission Changes:
   • Back in the Security tab, click Advanced, then enable "Replace all child object permissions with inheritable permissions from this object."
4. Test Download Again:
   • On the client machine, verify downloading the file through Windows Update or by synchronizing to WSUS.

---

Step 5: Retest Client Sync​

After making these changes, retest the WSUS update download process on the affected client.

1. Force the client to resync:
   

   bash
      wuauclt /reportnow
      wuauclt /detectnow

2. Verify if update downloads are now completing (non-zero size) in the client's C:\Windows\SoftwareDistribution\Download folder.

---

If it Still Fails​

If the 0 KB issue persists, we’ll need to dive deeper based on these results:

1. Confirm if the permissions/identity changes resolved the issue.
2. Share any updates from Step 4 or if further feedback from the client (e.g., error logs) reveals new clues.

We’re close—please let me know after testing!

 

[bswhipp]

Changing Identity to ApplicationPoolIdentity now I can not access the WSUS Console with Connection Error

 

[ChatGPT]

Changing the WSUSPool's identity to ApplicationPoolIdentity and encountering a Connection Error in the WSUS console means that the IIS Application Pool no longer has sufficient permissions to access critical WSUS resources, such as the content directory, database, or configuration files.
By default, WSUS uses the NetworkService identity for the WSUSPool because it has broader permissions on the local system for database and content access. Since WSUS relies on that setup, changing it to ApplicationPoolIdentity may break access.
Here’s how to get WSUS working again, while keeping the correct identity or reverting to the previous configuration.

---

Steps to Fix the WSUS Connection Error​

Step 1: Revert the Identity to NetworkService​

Switching the WSUSPool identity back to NetworkService should restore default permissions.

1. Revert the Identity:
   • Open IIS Manager (inetmgr).
   • Navigate to Application Pools > WsusPool.
   • Right-click and select Advanced Settings.
   • Under Process Model, change the Identity back to NetworkService.
   • Click OK.
2. Recycle the WsusPool:
   • Right-click WsusPool > Recycle.
3. Restart IIS:
   • Open Command Prompt as Administrator and run:
     

     bash
          iisreset

4. Test the WSUS Console:
   • Reopen the WSUS console to confirm connectivity.

---

Step 2: Test Functionality for Clients​

After reverting the identity:

1. Force a WSUS resync on a client with:
   

   bash
      wuauclt /resetauthorization /detectnow

2. Check if updates are still stuck at 0 KB in SoftwareDistribution.

---

What If It’s Still Necessary to Keep ApplicationPoolIdentity?​

If using ApplicationPoolIdentity is mandatory (e.g., per your setup policies), you need to manually grant the correct permissions to the WSUSPool user.

---

Step 3: Manually Grant Permissions for ApplicationPoolIdentity​

If you decide to keep the identity as ApplicationPoolIdentity, ensure it has the necessary permissions.

1. Understand What ApplicationPoolIdentity Maps To:
   • ApplicationPoolIdentity maps to the IIS APPPOOL\<PoolName> account. For WSUSPool, this would be:
     

          IIS APPPOOL\WsusPool

2. Grant Permissions to WSUS Resources:
   • Add IIS APPPOOL\WsusPool to key areas with proper permissions:
     • WSUS Content Folder (D:\WSUS\WSUSCONTENT):
     • Add IIS APPPOOL\WsusPool with Read & Execute permissions.
     • WSUS Configuration Files:
     • Add IIS APPPOOL\WsusPool with Read and Write permissions to:
       

                C:\Windows\System32\inetsrv\config\applicationHost.config

     • Database Access:
     • Navigate to SQL Server Management Studio.
     • Ensure that the database login for WSUS (NT AUTHORITY\NETWORK SERVICE) is replaced or supplemented with:
       

                IIS APPPOOL\WsusPool

3. Recycle the Application Pool:
   • Right-click WsusPool > Recycle.
4. Restart IIS Services:
   

   bash
      iisreset

---

Step 4: Revalidate WSUS Connectivity​

After adjusting permissions:

1. Test WSUS Console access.
   • Open WSUS and ensure it connects successfully.
2. Test the ability to download updates again.

---

When Should You Revert to NetworkService?​

If granting manual permissions doesn’t fully resolve the WSUS issue or introduces new errors, revert to NetworkService, as it’s the default identity for WSUS and seamlessly integrates with its components.

Steps to Revert Back:​

1. Change WsusPool identity in IIS to NetworkService.
2. Restart IIS and confirm the WSUS Console is operational.

---

Let me know how these steps work out or if additional errors appear after applying permissions adjustments!

 

[bswhipp]

I will change the pool information tomorrow but not sure why I would need to if Networkservice is the default. Everything else looks OK but still can not download the updates. File is still 0 in the Downloads folder of the client

 

[ChatGPT]

Thanks for the update! If NetworkService is the default identity for the WsusPool, there might not be a need to change it to ApplicationPoolIdentity unless you’re troubleshooting or following specific best practices and custom setups. For now, we’ll focus on resolving the core problem: clients downloading updates as 0 KB files. Since everything else looks OK, let’s refine the focus on what might still cause the failure.

---

Next Steps to Resolve WSUS Client’s 0 KB File Issue​

Focus on Key Sources of the Problem​

Given that the updates display as 0 KB in the SoftwareDistribution folder, it typically points to:

1. WSUS not properly serving the file (IIS content or file access issue).
2. WSUS database inconsistencies (incorrect metadata about the updates).
3. Client-side cache or communication issues (even if logs currently show no client errors).

Let’s drill deeper into the server servicing aspects and recheck the client-side download path.

---

Step 1: Test Content Access from the Client via Browser​

Since the client can download updates manually, we need to double-check automated accessibility.

1. Open a browser on the client machine.
2. Navigate to the expected content path using the WSUS server URL. For example:
   

      http://<WSUS-Server>:8530/Content/<GUID>.cab

   • Replace <WSUS-Server> with your server name or IP.
   • Replace <GUID>.cab with the actual file GUID (corresponding to KB5047486 or similar) from the WSUSContent folder.
3. Results:
   • File Successfully Downloads: Proceed to Step 2 to confirm WSUS fulfills HTTP/HTTPS requests correctly.
   • File Fails or Errors: Check IIS or permissions for serving WSUS content.

---

Step 2: Double-Check IIS Directory Browsing​

WSUS relies on proper IIS folder permissions and configuration to serve files.

Verify WSUS Content Folder in IIS:​

1. Open IIS Manager (inetmgr).
2. Expand WSUS Administration > Content.
3. Test virtual directory permissions:
   • Select Content, click Browse in the right-side Actions pane.
   • Ensure it loads the directory.
4. If Permissions Seem Fine:
   • Check the C:\inetpub\logs\LogFiles IIS log files for entries related to requests for WSUS content.
   • Look for HTTP error codes like 403 (Forbidden) or 401 (Unauthorized).

---

Step 3: Test the File’s Database Metadata in WSUS​

Sometimes clients receive metadata-only access but can’t get the actual file delivered. This can happen if WSUS's internal database references the update incorrectly.

1. Resynchronize WSUS Updates:
   • From the WSUS console:
     • Go to Options > Synchronization.
     • Click Syncronize Now to fetch metadata again.
   • Test whether clients download updates after metadata refresh.
2. Verify Update Approval:
   • Go to the WSUS console > Updates.
   • Find KB5047486 in the update list.
   • Ensure the update is approved for the matching target group of the client.
   • If necessary, select the update, and click Approve for All Computers (or the correct group).
   • Click "Run Server Cleanup Wizard" under Options to remove old/unused update metadata.
3. Test Client Resync:
   On the affected client:
   

   bash
      wuauclt /reportnow
      wuauclt /detectnow

---

Step 4: Manually Reindex SUSDB​

Database fragmentation can cause WSUS content delivery failures.

1. Open SQL Server Management Studio (SSMS).
2. Connect to the WID instance (or SQL Server instance hosting WSUS):
   • Use:
     

          \\.\pipe\MICROSOFT##WID\tsql\query

     Or your SQL instance (e.g., MY-SQLINSTANCE\WSUS).
3. Run the Standard Reindex SQL Script:
   

   sql
      USE SUSDB;
      EXEC spReindexAllIndexes;

4. Restart IIS and Test:
   

   bash
      iisreset

---

Step 5: Clear the Client SoftwareDistribution Folder and Retry​

Ensure the client starts with a clean slate for downloads.

1. Stop Update Services:
   On the client, run:
   

   bash
      net stop wuauserv
      net stop cryptsvc

2. Clear Caching Folders:
   • Delete contents of:
     

     bash
          C:\Windows\SoftwareDistribution
          C:\Windows\System32\catroot2

3. Restart Services:
   

   bash
      net start wuauserv
      net start cryptsvc

4. Retry the Update:
   • Force detection and reporting:
     

     bash
          wuauclt /resetauthorization /detectnow

---

Step 6: Check WSUS Logs​

If the updates still aren’t downloading, deeper analysis of WSUS logs on the server is the next step.

1. WSUS Logs on the Server:
   • Check the following:
     

          C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log

   • Look for errors related to:
     • Database querying issues (e.g., missing files or update ID).
     • Access failures.
2. Client Logs:
   • Inspect the client logs for download errors:
     • Use:
       

       bash
          wuauclt /reportnow
          wuauclt /detectnow

       0
   • Look for errors like network timeouts or file request failures.

---

Step 7: Test WSUS with Another Client​

Sometimes WSUS issues are isolated to a specific group policy or client device misconfiguration. Use a different client to test updates to rule out server issues entirely:

1. Set the Same WSUS Settings and Test:
   • Temporarily point another client to the same WSUS server.
   • Resynchronize the updates as done before.

If the second client works, the issue lies with the original client's local software or policies. If the second client also experiences 0 KB downloads, this confirms the issue is server-side.

---

Next Steps​

Let me know how these additional steps go, especially:

• After Step 4 (Reindex) or Step 5 (SoftwareDistribution reset).
• Any specific log errors or behavior changes.

If updates are still failing, we’ll pivot to deeper IIS or WSUS database diagnostics!

 

[bswhipp]

Step 2.3 403.1 - Forbidden error

 

[bswhipp]

OK, I had to enable scripts in the Handler Mappings, now I can see it when I browse

 

[ChatGPT]

Great work pinpointing the issue and enabling scripts in the Handler Mappings! Now that you're able to browse the WSUS update files through IIS, this confirms that IIS is properly serving the content, resolving the core permissions/configuration problem. However, let’s ensure that the clients can now successfully download updates and apply them.

---

Next Steps to Confirm Full Client Functionality​

---

Step 1: Force the Client to Re-Synchronize​

Now that the server is properly serving content, let’s clear out the client’s inconsistent state and force synchronization.

1. Stop Update Services:
   • On the affected client machine, open an elevated Command Prompt and stop the Windows Update services:
     

     bash
          net stop wuauserv
          net stop cryptsvc

2. Clear Update Cache:
   • Manually delete the contents of the following folders:
     • C:\Windows\SoftwareDistribution
     • C:\Windows\System32\catroot2
3. Restart Update Services:
   

   bash
      net start wuauserv
      net start cryptsvc

4. Force Detection and Reporting:
   • Trigger a manual Windows Update detection cycle:
     

     bash
          wuauclt /resetauthorization /detectnow
          wuauclt /reportnow

   • On newer builds:
     

     bash
          usoclient StartScan

5. Check if updates are downloading and their file sizes in:
   

      C:\Windows\SoftwareDistribution\Download

   • A non-zero file size for the updates indicates success.

---

Step 2: Test Browser Access from Client​

Double-check that the content directory is accessible from the client directly.

1. On the client machine, open a web browser.
2. Navigate to the URL of a known file from the WSUS content directory. For example:
   

      http://<WSUS-Server>:8530/Content/<GUID>.cab

   • Replace <WSUS-Server> with your WSUS server’s hostname or IP.
   • Replace <GUID>.cab with the actual filename of a .cab file stored in the WSUSContent directory.
3. Expected Outcome:
   • The browser should download the file successfully.
   • If this works but Windows Update on the client still doesn’t function, the issue is on the client’s configuration (Step 4).

---

Step 3: Synchronize WSUS Content​

If updates still fail despite IIS being fixed, ensure WSUS metadata and update content are fully synced.

1. Force a WSUS sync on the server:
   • Open the WSUS Console > Options > Synchronization Schedule.
   • Click Synchronize Now.
2. WSUS Cleanup Wizard:
   • Run the Server Cleanup Wizard to remove stale or incomplete updates.
     • Go to Options > Server Cleanup Wizard > Select all options and clean up the server.
3. Verify Update Approval:
   • Ensure the update is marked as Approved for the correct group (e.g., All Computers) in the WSUS console.

---

Step 4: Recheck the Client’s WSUS Configuration​

1. Verify GPO or Registry Settings:
   • Confirm that the client’s WSUS server settings are correct using this PowerShell command:
     

     powershell
          Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate

     • Ensure these keys are properly set:
     • WUServer: http://<WSUS-Server>:8530
     • WUStatusServer: http://<WSUS-Server>:8530
2. Test Automatic Updates:
   • Ensure Windows Update is enabled and not configured to bypass WSUS.

---

Step 5: Monitor Logs for Errors​

If updates still fail after all steps, examine logs for specific errors.

1. On the WSUS Server:
   Check the following logs:
   • IIS Logs:
     

          C:\inetpub\logs\LogFiles

     • Look for HTTP error codes (e.g., 404, 401) while trying to serve the desired updates.
   • WSUS Logs:
     

          C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log

2. On the Windows Client:
   • Open the Event Viewer (eventvwr.msc).
   • Check under:
     

          Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational.

   • Look for errors related to update downloads.

---

Let Me Know the Result​

• If updates are now downloading successfully after these steps, you’re all set!
• If updates are still not being applied or you're encountering new issues (e.g., new errors in the logs or incomplete downloads), share those details, and we’ll continue debugging.

You’re nearly there—well done resolving the 403.1 problem!

 

[bswhipp]

Still Same issue

 

[ChatGPT]

Thank you for testing and for your patience! Since the 403.1 - Forbidden issue was resolved and WSUS content is now browseable, but clients still cannot download updates (remaining at 0 KB), we need to dig deeper into client-to-server interaction and ensure there isn’t a lingering issue related to metadata, synchronization, database integrity, or client-side configuration. Let’s refine and focus on resolving this for good.

---

Updated Steps to Address Downloads Stuck at 0 KB​

---

Step 1: Confirm WSUS Server is Serving Content Properly​

Now that IIS is serving files, let’s confirm both WSUS metadata and content are intact at the server level.

1. Recheck Content Path:
   • Navigate to your WSUS content storage folder:
     

          D:\WSUS\WSUSCONTENT

   • Identify the file associated with the update in question (e.g., .cab file for KB5047486).
   • Confirm:
     • The file actually exists.
     • The file size is non-zero.
2. Reapprove the Update for All Clients:
   • In the WSUS console:
     • Locate the update in Updates View > All Updates.
     • Verify the Approval Status. Approve the update for the client’s group (e.g., All Computers).
3. Test the Following Browser Download from the Client:
   

   bash
      http://<WSUS-Server>:8530/Content/<GUID>.cab

   • Replace <WSUS-Server> with your hostname or IP address.
   • Replace <GUID>.cab> with the update filename.
   • Successful Test: The browser downloads the file without issues.
   • Failure: There’s still something preventing access (permissions, network, or translation issues).

---

Step 2: Fix Potential Metadata Mismatches​

Sometimes, WSUS’s content database doesn’t line up with the actual files/content directory. Let’s sync them.

1. Run wsusutil.exe reset:
   This ensures all metadata and update files are re-verified:
   

   bash
      wsusutil.exe reset

2. Clean WSUS Metadata:
   • Inside the WSUS console, run the Server Cleanup Wizard:
     • Go to Options > Server Cleanup Wizard.
     • Check Remove unused updates and update revisions, Delete unneeded update files, and other options.
     • Run the cleanup.
   • Restart WSUS and IIS:
     

     bash
          iisreset
          net stop "Windows Server Update Services"
          net start "Windows Server Update Services"

3. Test if clients begin downloading updates after this step.

---

Step 3: Reindex the WSUS Database​

Fragmentation or corruption in the WSUS database can cause updates to be improperly referenced or fetched.

1. Open SQL Server Management Studio (SSMS) or connect to the WID database.
   • For WID:
     

     bash
          \\.\pipe\MICROSOFT##WID\tsql\query

   • For SQL Server:
     Connect to <SQL_Server_Instance>.
2. Execute the following reindexing script:
   

   sql
      USE SUSDB;
      EXEC spReindexAllIndexes;

3. Restart IIS and WSUS Services:
   

   bash
      iisreset

4. Confirm Content Metadata Alignment:
   Rerun:
   

   bash
      wsusutil.exe reset

---

Step 4: Investigate Client Configuration​

If the server-side synchronization was fixed but the client still can’t download updates, confirm the client’s configuration is correct.

4.1: Verify WindowsUpdate GPO or Registry Settings​

1. Run the following command to verify the client’s settings:
   

   powershell
      Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate

   • Expected keys:
     • WUServer: http://<WSUS-Server>:8530
     • WUStatusServer: http://<WSUS-Server>:8530
2. If settings are missing or incorrect:
   • Update via Local Group Policy or registry:
     • Location: Computer Configuration > Administrative Templates > Windows Components > Windows Update.
     • Set:
     • Specify intranet Microsoft update service location: http://<WSUS-Server>:8530.
3. Force a sync on the client:
   

   bash
      wuauclt /resetauthorization /detectnow
      wuauclt /reportnow

---

Step 5: Analyze Logs for Errors​

Logs often reveal what's breaking the process.

5.1: Check IIS Logs​

1. Navigate to:
   

   bash
      http://<WSUS-Server>:8530/Content/<GUID>.cab

   0
2. Open the most recent log file (associated with WSUS Admin).
3. Search for the client’s IP or requests related to .cab or other update files.
   • Common Issues:
     • 404 Errors: File not found in WSUSContent folder.
     • 401/403 Errors: Authentication or permissions issues.

5.2: Check Client-Side Logs​

1. Open Event Viewer (eventvwr.msc).
   • Navigate to:
     

     bash
        http://<WSUS-Server>:8530/Content/<GUID>.cab

     1
2. Look for errors related to downloading updates or network communication.

---

What to Do Based on the Logs​

Scenario 1: Files Not Found (404 Errors in IIS Logs)​

• The file isn’t in the Content folder, or metadata points to the wrong location.
• Solution:
  • Run wsusutil.exe reset again to verify/update content.

Scenario 2: Authentication (401 or 403 Errors):​

• Client cannot authenticate with IIS.
• Solution:
  • Verify IIS Anonymous Authentication is enabled (Step 2).

Scenario 3: Timeout or Network Issues:​

• Check if:
  • Files are larger and timing out.
  • Firewall or proxy is interfering with traffic.

---

Recap and Next Steps​

• Focus Areas: IIS permissions, content metadata alignment, client settings, and logs.
• Key Commands:
  

  bash
     http://<WSUS-Server>:8530/Content/<GUID>.cab

  2

If updates still fail after this, let me know what errors (if any) are appearing in the client-side or IIS logs—this will provide deeper clues!

 

[bswhipp]

No change. the only log I can find is on the WSUS Server Event Viewer Server Roles Windows Server Update Services Event ID 13002
Client computers are installing updates with a higher than 25 percent
failure rate. This is not normal.

And
On the Client Computers under C:\Windows\SoftwareDireibution\ReportingEvents.log


{F45B4ED3-6492-4FB3-9692-398B4F5F5661} 2025-01-22 10:19:51:585-0500 1 161 [AGENT_DOWNLOAD_FAILED] 101 {BDAAB34A-FB09-4A7E-A130-4DC032AE012A} 200 80d02002 MoUpdateOrchestrator Failure Content Download Error: Download failed. mcbv0vHzQ0aNrnsE.18.1.10.0
{77B7C09E-3A98-4E36-869F-65740FE76ACD} 2025-01-22 11:20:36:666-0500 1 161 [AGENT_DOWNLOAD_FAILED] 101 {BBB22535-4167-49A5-AD01-834BB5E6A8E5} 200 80d02002 MoUpdateOrchestrator Failure Content Download Error: Download failed. 9qCH1cz9/Eq/DkBp.12.1.10.0

 

[ChatGPT]

Thank you for providing these logs! The Event ID 13002 on the WSUS server combined with Error Code 0x80d02002 on the client indicates that content download failures are still occurring, most likely due to:

1. Communication or content delivery issues between the WSUS server and the clients.
2. Mismatched or corrupt WSUS metadata.
3. A potential problem with the WSUS content folder or IIS setup.

Let’s break this down further and resolve the issue step by step.

---

Decoding the Logs and Error Codes​

WSUS Server: Event ID 13002​

• This message indicates high failure rates on client updates, typically pointing to server-side content delivery or metadata issues.

WSUS Client: Error Code 0x80d02002​

• Meaning of 0x80d02002:
  • This error indicates a content download failure, suggesting the client is unable to fetch the update files from the WSUS server due to:
  • IIS issues (i.e., serving the files).
  • Corrupt or incorrectly approved metadata.
  • Patch content missing from WSUS folder (WSUSCONTENT).
  • Network timeout, proxy, or authentication issues.

---

Action Plan to Resolve the Issue​

---

Step 1: Reconfirm IIS Content Configuration​

Although you've previously fixed IIS Handler Mappings, double-check other critical areas specific to WSUS content delivery.

1.1 Test File Download Again​

• On the client machine, try directly downloading a known file again:
  

  bash
    http://<WSUS-Server>:8530/Content/<GUID>.cab

  • If the file fails to download, IIS or file-system permissions need further adjustments.
  • If downloads succeed in a browser, move to client-side or metadata issues.

1.2 Validate IIS Logs​

• Check the IIS logs for WSUS content requests:
  

    C:\inetpub\logs\LogFiles

• Look for HTTP codes (like 403, 404, or timeouts) related to the failed client requests.

1.3 Permissions on WSUS Content Folder​

Verify that the WSUSCONTENT folder has the correct NTFS permissions:

1. Navigate to D:\WSUS\WSUSCONTENT or your equivalent path.
2. Permissions Required:
   • NETWORK SERVICE: Read & Execute
   • IIS_IUSRS: Read & Execute

---

Step 2: Check WSUS Approvals and Content Integrity​

1. Re-approve Any Stuck Updates:
   • Open the WSUS console and search for updates with KB5047486 or the problematic update GUIDs listed in ReportingEvents (e.g., {BDAAB34A-FB09...}).
   • Un-approve the update, then re-approve it for the relevant groups (e.g., All Computers).
2. Force WSUS to Verify Content with Metadata:
   • Run the following to re-check and re-download required files:
     

     bash
          wsusutil.exe reset

3. Run the Server Cleanup Wizard:
   • In WSUS console, go to Options > Server Cleanup Wizard and select all categories.
   • This ensures orphaned or corrupt updates are removed.

---

Step 3: Client-Side Diagnostics​

1. Clear and Reset Windows Update Cache:
   On the client machine:
   

   bash
      net stop wuauserv
      net stop cryptsvc
      rmdir %Windir%\SoftwareDistribution /s /q
      rmdir %Windir%\System32\catroot2 /s /q
      net start wuauserv
      net start cryptsvc

2. Check Logs for Networking Issues:
   • Open Event Viewer:
     

          Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational

   • Look for errors like timeout, authentication, or network failure.
3. Force a New Synchronization on the Client:
   

   bash
      wuauclt /resetauthorization /detectnow
      wuauclt /reportnow

4. Confirm:
   • Check C:\Windows\SoftwareDistribution\Download for downloaded update files.
   • Verify they are non-zero in size.

---

Step 4: Debug and Reindex WSUS Database​

1. Verify SUSDB Integrity:
   • Open SQL Server Management Studio (SSMS) and connect to your WSUS database (WID or SQL Server).
   • Run:
     

     sql
          USE SUSDB;
          SELECT * FROM tbSchemaVersion;

     • Ensure it returns valid version info. If errors appear, the WSUS database is likely corrupted.
2. Reindex the Database:
   • Run:
     

     sql
          USE SUSDB;
          EXEC spReIndexAllIndexes;

3. Restart IIS and WSUS Services:
   

   bash
      iisreset
      net stop "Windows Server Update Services"
      net start "Windows Server Update Services"

---

Step 5: Test WSUS Connectivity​

1. Verify WSUS Client Configuration:
   • Run on the client machine:
     

     powershell
          Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate\

   • Confirm these values:
     • WUServer: http://<WSUS-Server>:8530
     • WUStatusServer: http://<WSUS-Server>:8530
2. Ping and Connectivity Test:
   • From the client, verify there’s no network issue:
     

       C:\inetpub\logs\LogFiles

     0

---

Step 6: Final Debugging​

If updates still fail:

1. Check detailed errors for any failed request logs in IIS (C:\inetpub\logs\LogFiles).
2. Reconfigure WSUS completely and refresh the service:
   

     C:\inetpub\logs\LogFiles

   1

---

Expected Outcomes​

After these steps:

• Clients should start downloading updates (non-zero file sizes).
• IIS should successfully serve both update metadata and content files.

Let me know the results! If updates still fail, share additional IIS logs, WSUS errors, or detailed failures on the client. We’ll get this fixed!

 

[bswhipp]

Everything looks good but still no download. in the event viewer on the client under Applications and Services Logs &gt; Microsoft &gt; Windows &gt; WindowsUpdateClient &gt; Operational ther is evetn ID 31 Error Windows Update failed to download an update.

 

[ChatGPT]

The Event ID 31: "Windows Update failed to download an update" error from the WindowsUpdateClient - Operational log indicates that while the WSUS client sees the update and tries to download it, something prevents the client from fetching or saving the file. Since everything else on the WSUS server and IIS looks correct, the problem is now more likely tied to:

1. Client communication with the WSUS server, such as timeouts or blocked downloads.
2. File retrieval issues on the client side, possibly related to access, corruption, or download service problems.
3. Permissions or network-related errors during the file handling process.

Here’s how to proceed step by step to pinpoint and fix the error.

---

Steps to Resolve Event ID 31: Windows Update Failed to Download​

---

Step 1: Recheck IIS Logs for Server Response to Client Requests​

The WSUS client logs the download failed error because it was unable to retrieve the update file. Let’s confirm the server provided the correct response.

1. Check IIS Logs:
   • Navigate to:
     

          C:\inetpub\logs\LogFiles

   • Open the logs for the WSUS Administration site (associated with port 8530).
   • Look for the corresponding timestamp when the client attempted to fetch the update file.
2. Identify Error Codes in the Logs:
   • HTTP 404 (Not Found): The WSUSContent folder is missing the requested file.
   • HTTP 401/403 (Unauthorized/Forbidden): A permissions issue is blocking content delivery.
   • HTTP 50X (Server Errors): IIS or WSUS misconfiguration related to the application pool.

---

Step 2: Test WSUS Content Access from the Client (Again)​

We need to verify that the client can truly fetch the update file being referenced.

1. Identify the GUID and File Path:
   • Locate the GUID for the update file by checking the metadata or logs (e.g., from ReportingEvents logs or WSUS logs).
2. Access the File Using a Web Browser on the Client:
   • Navigate to the URL:
     

          http://<WSUS-Server>:8530/Content/<GUID>.cab

     • Replace <WSUS-Server> with the hostname or IP of your WSUS server.
     • Replace <GUID>.cab with the file reference.
3. Outcomes:
   • File Downloads: Confirms a server-to-client issue during Windows Update operations but not manual downloads.
   • File Fails: Check server-side configurations (WSUSContent) or IIS permissions (go back to Steps 2–4 of earlier troubleshooting).

---

Step 3: Verify the Client Update Logs​

The Event ID 31 and ReportingEvents.log point to file retrieval failures on the client. Let’s analyze them further.

1. Check Recent Errors in ReportingEvents.log:
   • Open:
     

          C:\Windows\SoftwareDistribution\ReportingEvents.log

   • Look for recent download failure events. Common flags include:
     • Error code 0x8024400e or similar: Metadata mismatch.
     • Error code 0x80d02002: Content inaccessible or download block.
2. Clear Cache and Force a Retry:
   • On the client:
     

     bash
          net stop wuauserv
          net stop cryptsvc
          rmdir %Windir%\SoftwareDistribution /s /q
          net start wuauserv
          net start cryptsvc

   • Force detection:
     

     bash
          wuauclt /reportnow
          wuauclt /resetauthorization /detectnow

---

Step 4: Temporarily Enable Logging for BITS​

The Background Intelligent Transfer Service (BITS) is responsible for Windows updates' download and transfer. If the BITS service has an issue, this could explain the failure.

1. Enable Verbose BITS Logging:
   • Run this command in an elevated Command Prompt:
     

     bash
          bitsadmin /reset /allusers
          bitsadmin /SetNotifyCmdLine /allusers "%SystemRoot%\System32\Notepad.exe"

2. Run a Download Retry:
   • Trigger a sync and rescan for updates:
     

     bash
          wuauclt /resetauthorization /detectnow

3. Check if any update download attempts succeed or if additional BITS errors appear.
4. Reset Logging Configuration After Troubleshooting:
   

   bash
      bitsadmin /SetNotifyCmdLine /allusers ""

---

Step 5: Further Troubleshoot Client-Specific Issues​

1. Check Proxy, Firewall, and Network Restrictions:
   • If the client is behind a proxy, ensure it can contact the WSUS server:
     

     bash
          netsh winhttp show proxy

   • Disable proxy temporarily for testing:
     

     bash
          netsh winhttp reset proxy

2. Verify Windows Update Service:
   • Ensure there are no failures for:
     • wuauserv (Windows Update).
     • cryptsvc (Cryptographic Services).
     • Use:
       

            http://<WSUS-Server>:8530/Content/<GUID>.cab

       0

---

Step 6: Inspect or Rebuild WSUS​

If everything else looks correct, but the client is still stuck, the issue could lie in the WSUS server itself.

1. Synchronize Updates:
   • From the WSUS console, run the following to verify metadata updates:
     • Options > Synchronization > Synchronize Now.
2. Revisit WSUS Approvals:
   • Un-approve the problematic update and re-approve it for the proper target group.
3. Rebuild WSUS Data:
   • Run:
     

          http://<WSUS-Server>:8530/Content/<GUID>.cab

     1

---

If Download Still Fails​

If after following these steps the Windows Update still fails to download updates:

• Let me know:
  1. If manual browser downloads (Step 2) work for .cab files from the WSUS content directory.
  2. Any new errors appearing in:
     • WindowsUpdate.log or client Event Viewer.
     • IIS logs on the WSUS server.

We’re close to a resolution—thanks for sticking with this troubleshooting process!