WSUS not downloading to client

Updated Steps Based on Your Feedback​

Step 4.1: Change Application Pool Identity​

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:
   
   Code:

   bash iisreset

Step 4.2: Validate File System Permissions​

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​

1. Force the client to resync:
   
   Code:

   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​

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.

Steps to Fix the WSUS Connection Error​

Step 1: Revert the Identity to NetworkService​

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:
     
     Code:

     bash iisreset

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

Step 2: Test Functionality for Clients​

1. Force a WSUS resync on a client with:
   
   Code:

   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?​

Step 3: Manually Grant Permissions for ApplicationPoolIdentity​

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

      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:
       
       Code:

        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:
       
       Code:

        IIS APPPOOL\WsusPool

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

   bash iisreset

Step 4: Revalidate WSUS Connectivity​

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?​

Steps to Revert Back:​

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

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

Focus on Key Sources of the Problem​

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).

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

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

    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​

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​

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:
   
   Code:

   bash wuauclt /reportnow wuauclt /detectnow

Step 4: Manually Reindex SUSDB​

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

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

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

   sql USE SUSDB; EXEC spReindexAllIndexes;

4. Restart IIS and Test:
   
   Code:

   bash iisreset

Step 5: Clear the Client SoftwareDistribution Folder and Retry​

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

   bash net stop wuauserv net stop cryptsvc

2. Clear Caching Folders:
   • Delete contents of:
     
     Code:

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

3. Restart Services:
   
   Code:

   bash net start wuauserv net start cryptsvc

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

     bash wuauclt /resetauthorization /detectnow

Step 6: Check WSUS Logs​

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

      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:
       
       Code:

       bash wuauclt /reportnow wuauclt /detectnow

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

Step 7: Test WSUS with Another Client​

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

Next Steps​

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

Next Steps to Confirm Full Client Functionality​

Step 1: Force the Client to Re-Synchronize​

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

     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:
   
   Code:

   bash net start wuauserv net start cryptsvc

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

     bash wuauclt /resetauthorization /detectnow wuauclt /reportnow

   • On newer builds:
     
     Code:

     bash usoclient StartScan

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

    C:\Windows\SoftwareDistribution\Download

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

Step 2: Test Browser Access from Client​

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:
   
   Code:

    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​

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:
     
     Code:

     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​

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

      C:\inetpub\logs\LogFiles

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

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

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

      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.

Updated Steps to Address Downloads Stuck at 0 KB​

Step 1: Confirm WSUS Server is Serving Content Properly​

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

      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:
   
   Code:

   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​

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

   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:
     
     Code:

     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​

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

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

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

   sql USE SUSDB; EXEC spReindexAllIndexes;

3. Restart IIS and WSUS Services:
   
   Code:

   bash iisreset

4. Confirm Content Metadata Alignment:
   Rerun:
   
   Code:

   bash wsusutil.exe reset

Step 4: Investigate Client Configuration​

4.1: Verify WindowsUpdate GPO or Registry Settings​

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

   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:
   
   Code:

   bash wuauclt /resetauthorization /detectnow wuauclt /reportnow

Step 5: Analyze Logs for Errors​

5.1: Check IIS Logs​

1. Navigate to:
   
   Code:

   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:
     
     Code:

     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:
  
  Code:

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

  2

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.

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​

1.1 Test File Download Again​

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

  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:
  
  Code:

   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​

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:
     
     Code:

     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:
   
   Code:

   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:
     
     Code:

      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:
   
   Code:

   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:
     
     Code:

     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:
     
     Code:

     sql USE SUSDB; EXEC spReIndexAllIndexes;

3. Restart IIS and WSUS Services:
   
   Code:

   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:
     
     Code:

     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:
     
     Code:

      C:\inetpub\logs\LogFiles

     0

Step 6: Final Debugging​

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

    C:\inetpub\logs\LogFiles

   1

Expected Outcomes​

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

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.

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

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

1. Check IIS Logs:
   • Navigate to:
     
     Code:

      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)​

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:
     
     Code:

      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​

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

      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:
     
     Code:

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

   • Force detection:
     
     Code:

     bash wuauclt /reportnow wuauclt /resetauthorization /detectnow

Step 4: Temporarily Enable Logging for BITS​

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

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

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

     bash wuauclt /resetauthorization /detectnow

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

   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:
     
     Code:

     bash netsh winhttp show proxy

   • Disable proxy temporarily for testing:
     
     Code:

     bash netsh winhttp reset proxy

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

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

       0

Step 6: Inspect or Rebuild WSUS​

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:
     
     Code:

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

     1

If Download Still Fails​

• 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.