Folder Exists
Has correct privileges
sqlcmd -S Instancename -E returns 1>
wsusutil.exe postinstall SQL_INSTANCE_NAME="Instance name" CONTENT_DIR="D:\WSUS\WSUSCONTENT" still returns Fatal Error: The system cannot find the path specified.
The log file indicates issue with IIS

2024-12-06 09:02:59 Configuring IIS...
2024-12-06 09:02:59 Start: ConfigureWebsite
2024-12-06 09:02:59 System.Runtime.InteropServices.COMException (0x80070003): The system cannot find the path specified.
 


Thanks for providing the additional details—this now points to an IIS configuration issue during the WSUS installation. The error 0x80070003 ("The system cannot find the path specified") suggests that WSUS is having trouble with IIS during the website creation process. This could happen if there’s a missing or broken IIS configuration, incorrect bindings, or a corrupted WSUS virtual directory setup.
Let’s address the problem step by step.

Step 1: Check IIS Installation and Features

WSUS relies heavily on IIS, so it's essential that IIS and its required features are correctly installed and functional.
  1. Verify IIS is Installed Properly:
    • Open Server Manager > Roles and Features.
    • Expand Web Server Role (IIS) and ensure the following are installed:
      • Web Server > Common HTTP Features:
      • Static Content
      • Default Document
      • Web Server > Application Development:
      • ASP.NET
      • .NET Extensibility
      • ISAPI Extensions
      • ISAPI Filters
      • Security:
      • Windows Authentication
      • Management Tools
      • IIS Management Console
    If any required features are missing, install them using Server Manager or:
    Code:
    bash Install-WindowsFeature -Name Web-Server, Web-Common-Http, Web-Dyn-Compression, Web-Basic-Auth, Web-Windows-Auth, Web-Mgmt-Console
  2. Restart IIS:
    Run the following commands:
    Code:
    bash iisreset

Step 2: Verify WSUS Virtual Directories

WSUS uses several virtual directories under IIS. If these are broken, corrupted, or misconfigured, WSUS setup will fail.
  1. Open IIS Manager:
    • Run inetmgr to open the IIS console.
    • Look for a WSUS Administration site under Sites.
  2. Verify Virtual Directories:
    • Expand WSUS Administration and look for these directories:
      • Content
      • SelfUpdate
      • ApiRemoting30
      • ClientWebService
      • ServerSyncWebService
      • DssAuthWebService
    • If one or more directories are missing, proceed to recreate them manually (details below).

Step 3: Delete and Recreate WSUS IIS Web Site

  1. Delete the Current WSUS Website (If Exists):
    • In IIS Manager, right-click WSUS Administration and delete it.
  2. Recreate WSUS Configuration:
    Run the following command to reset WSUS and recreate the IIS site:
    Code:
    bash wsusutil.exe postinstall SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
    If it fails again, IIS may need to be manually configured for WSUS.

Step 4: Manually Configure IIS for WSUS

  1. Manually Create the WSUS Site:
    • In IIS, right-click Sites > Add Website:
      • Site Name: WSUS Administration
      • Physical Path: D:\WSUS\WSUSCONTENT
      • Binding:
      • Type: http
      • IP Address: All Unassigned
      • Port: 8530
  2. Add Virtual Directories:
    For each path required by WSUS (listed below), add a Virtual Directory:
    • Right-click the WSUS site > Add Virtual Directory:
      • Alias: Content
      • Physical Path: D:\WSUS\WSUSCONTENT
    • Repeat this process for:
      • SelfUpdate > Path: C:\Program Files\Update Services\SelfUpdate
      • ApiRemoting30, ClientWebService, ServerSyncWebService, DssAuthWebService > Path: C:\Program Files\Update Services\WebServices\
    • Restart IIS:
      Code:
      bash iisreset
    • Retry the wsusutil.exe postinstall command.


Step 5: Check WSUSSetup.log

Since the log already pointed to IIS issues, continue monitoring WSUSSetup.log after the above steps. Look for any additional errors related to missing paths or permissions.

Step 6: Reapply Permissions

After completing the steps above, ensure NETWORK SERVICE and the WSUS server account have sufficient access to:
  • The WSUS content folder (D:\WSUS\WSUSCONTENT).
  • Relevant WSUS folders (e.g., C:\Program Files\Update Services).
Grant Modify permissions where necessary.

Let Me Know

Once you’ve addressed the IIS issues and re-run the post-install configuration, let me know if the problem persists. The logs and setup behavior will help pinpoint additional issues (if any). Together, we’ll untangle this for good! 😊
 


Everything is already installed.
I am hesitant to recreate the WSUS Administration site since I also have SCCM installed and there are CCM and SMS in the WSUS Administration site.
 


Ah, that’s a fair point—when SCCM (System Center Configuration Manager) is in the mix, WSUS becomes more sensitive since it's integrated into the WSUS Administration site for managing updates. Deleting and recreating the WSUS site can accidentally disrupt SCCM functionality if we’re not careful. We’ll proceed cautiously and avoid outright deletion unless it’s absolutely necessary!
Let’s troubleshoot and resolve the IIS-related error while keeping your SCCM configuration intact.

Step 1: Validate WSUS-SCCM Integration

Since SCCM is involved:
  1. Open IIS Manager and expand the WSUS Administration site.
  2. Check the virtual directories:
    • Do you see the required WSUS folders (like Content, ApiRemoting30, SelfUpdate, ClientWebService)? Are the CCM and SMS folders visible as well?
    • If all folders are intact, the issue might be with permissions or bindings.
  3. Confirm SCCM's Integration:
    • Open your SCCM Console.
    • Navigate to Administration > Site Configuration > Servers and Site System Roles.
    • Select your WSUS server and confirm the Software Update Point role is present and functioning.
If the SCCM integration points to IIS issues, correcting IIS without deletion is essential.

Step 2: Test the WSUS Administration Site

Let’s confirm if the WSUS Administration site is working properly:
  1. Open a browser and navigate to:
    • http://:8530/ClientWebService/client.asmx
      • http://:8531/ClientWebService/client.asmx (if HTTPS is enabled).
    • You should see the WSUS Web Service page. If it doesn’t load:
      • IIS bindings may be broken, misconfigured, or blocked by a port conflict.


Step 3: Validate Bindings

WSUS often fails to configure IIS correctly if the bindings are incorrect or another service is conflicting with the ports WSUS/SCCM uses (e.g., 8530, 8531, or 80).
To fix this:
  1. In IIS Manager, select WSUS Administration Site:
    • Verify bindings for:
      • http on 8530
      • (Optional) https on 8531 (if SSL is enabled).
    • Ensure no binding conflicts (e.g., check that SCCM isn’t reserving the same ports).
    If the bindings look normal but the site doesn’t work:
    • Reset the bindings:
      • Temporarily remove them, then re-add:
      • Type: http; Port: 8530.
      • Type: https; Port: 8531 (if appropriate).
  2. Restart IIS:
    Code:
    bash iisreset

Step 4: Verify File Paths and Permissions

The error 0x80070003 ("System cannot find the path specified") might occur in IIS if:
  1. The virtual directories are pointing to invalid/missing folders.
  2. WSUS/SCCM don’t have permissions to access the correct directories.

Fix Missing Path Issues:​

  1. Open WSUS Administration Site in IIS.
  2. Verify the physical paths for all virtual directories:
    • For example:
      • Content > D:\WSUS\WSUSCONTENT
      • SelfUpdate > C:\Program Files\Update Services\SelfUpdate
    • If a path is missing, restore/recreate the folder.
  3. Test Access:
    • In IIS, click on each virtual directory > Browse (e.g., browse Content or SelfUpdate).
    • If any folder fails to browse, correct the folder path.

Step 5: Incorporating SCCM-Sensitive Fix

If no physical paths or permissions are missing, reconfigure WSUS without impacting SCCM:
  1. Re-run the postinstall command without overwriting the site:
    Code:
    bash wsusutil.exe postinstall SQL_INSTANCE_NAME="YourSQLInstance" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
    • This will skip IIS website recreation but update WSUS’s back-end settings.
  2. If the IIS issue persists during postinstall, use IISRESET carefully:
    Code:
    bash iisreset /noforce
  3. Check SCCM Software Update Point Logs:
    • Look at WCM.log and WSUSCtrl.log (on the SCCM server under Logs) for any WSUS-related issues.

Step 6: Troubleshoot Further Without SCCM Impact

If neither WSUS nor the SCCM components respond:
  1. Back up the existing IIS configuration:
    • Export the IIS configuration using:
      Code:
      bash appcmd add backup "PreWSUSFix"
    • If anything breaks, restore it using:
      Code:
      bash appcmd restore backup "PreWSUSFix"
  2. Only as a last resort, manually repair/add virtual directories one at a time to avoid affecting the SCCM-created directories.

Next Steps

  • Let me know if SCCM and WSUS components are responding, and we’ll proceed slowly to avoid overwriting any SCCM integrations.
  • If there’s any output from WCM.log or WSUSSetup.log, share that to refine further fixes.
We’re juggling WSUS and SCCM here, but as long as we proceed cautiously, we can isolate and resolve this IIS issue without disrupting your environment. Let me know how it goes! 😊
 


1. is OK
2. is OK but Cert is expired.
3. is OK
4. I can righ tclick and explore both folders ok but if I browse I get HTTP Error 403.14 - Forbidden.
5. Can not complete the postinstall remember
 


Thanks for the detailed updates! Key points stand out here:
  1. The certificate being expired is significant for WSUS/SCCM integration if you're using HTTPS on port 8531. We'll address that, as it could cause access and configuration issues.
  2. HTTP Error 403.14 - Forbidden while browsing to the WSUS virtual directories typically indicates a misconfiguration of directory browsing permissions in IIS. This would explain why WSUS is failing to configure IIS during the postinstall process.
  3. The repeated postinstall failure continues to revolve around these IIS access issues, so that's where we’ll focus.
Let's systematically resolve these issues without disrupting your SCCM setup.

Step 1: Renew/Replace the Expired Certificate

If you're using HTTPS for WSUS, an expired cert will break key functionality.
  1. Renew the Certificate:
    • If the original certificate is renewable, reissue it through your Certificate Authority (CA).
    • Once issued, install it on the server via the Certificates MMC (certlm.msc):
      • Place it in Personal > Certificates.
      • Ensure it includes the correct Subject Name (CN) and is trusted by clients and SCCM.
  2. Rebind the New Certificate in IIS:
    • Open IIS Manager.
    • Select WSUS Administration > Bindings.
    • Edit the https binding (port 8531) > Choose the new certificate.
  3. Restart IIS:
    Code:
    bash iisreset
  4. Verify the Certificate:
    • Navigate to:
      Code:
       https://:8531/ClientWebService/client.asmx
      • The page should load without a certificate error. If it doesn't, resolve the HTTPS configuration.


Step 2: Fix 403.14 - Forbidden (Directory Browsing Issue)

This error occurs because IIS is preventing directory browsing or cannot find the proper default document for your WSUS virtual directories (e.g., Content, SelfUpdate).
  1. Enable Content Access in IIS:
    • Open IIS Manager.
    • Navigate to the virtual directory that’s causing the error (e.g., Content or SelfUpdate) under WSUS Administration.
    • Go to Directory Browsing (middle pane).
      • Enable Directory Browsing if disabled.
    • Restart IIS and test browsing the folders.
  2. Ensure the Virtual Directory Has a Default Document:
    • Navigate to the same virtual directories.
    • Open the Default Document feature in IIS.
    • Ensure there’s a valid document listed (or add one if needed).
For example:
  • Virtual Directory: D:\WSUS\WSUSCONTENT should serve static content, so Directory Browsing may need to be enabled temporarily.

Step 3: Rerun postinstall Safely

Once certificate and IIS content issues are fixed, retry the WSUS postinstall.
  1. Use this command (ensure the corrected SQL instance and folder path):
    Code:
    bash wsusutil.exe postinstall SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
  2. If you want to prevent WSUS from overwriting SCCM-related virtual directories, include -skipIISConfig:
    Code:
    bash wsusutil.exe postinstall SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT" -skipIISConfig
    • This avoids modifying the IIS site but won’t fix IIS issues on its own, so it’s more of a safe-testing option.

Step 4: Analyze Logs if Postinstall Fails Again

If you still can’t complete postinstall, grab the logs for analysis:
  1. WSUSSetup.log:
    • Located at:
      Code:
       C:\Program Files\Update Services\LogFiles\WSUSSetup.log
    • Look for specific errors tied to:
      • IIS calls (System.Runtime.InteropServices.COMException).
      • SQL database connectivity issues.
  2. IIS Logs:
    • Check the relevant logs under:
      Code:
       C:\inetpub\logs\LogFiles\W3SVC1
The logs will point to the current culprit, and we can fine-tune fixes.

Step 5: Confirm SCCM Components After Changes

  1. Ensure SCCM's Software Update Point role remains functional:
    • Check the WCM.log and WSUSCtrl.log in SCCM logs for any WSUS-related errors post postinstall.
    • Test synchronization in SCCM to confirm everything is working properly.

Let me know where things stand after these steps. If there’s still a blocker, share snippets of the WSUSSetup.log or describe persistent issues! We’ll get this resolved without causing chaos in your SCCM setup. 😊
 


OK Cert updated but still get the Not secure because it is self cert.
Directory browsing is enables on both.
Default Document list is there.

Same error when run post install command
2024-12-06 11:05:10 Starting service W3SVC
2024-12-06 11:05:10 Configuring IIS...
2024-12-06 11:05:10 Start: ConfigureWebsite
2024-12-06 11:05:10 System.Runtime.InteropServices.COMException (0x80070003): The system cannot find the path specified.

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_AdsObject()
at System.DirectoryServices.PropertyValueCollection.PopulateList()
at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
at Microsoft.UpdateServices.Administration.UseCustomWebSite..ctor()
at Microsoft.UpdateServices.Administration.PostInstall.ConfigureWebsite(Int32 portNumber)
at Microsoft.UpdateServices.Administration.PostInstall.Run()
at Microsoft.UpdateServices.Administration.PostInstall.Execute(String[] arguments)
 


Thanks for the detailed update, and this error clearly points to IIS struggling during the WSUS post-installation due to a missing or misconfigured component or path. The System.DirectoryServices.DirectoryEntry error often occurs because WSUS or IIS cannot find a critical configuration during the website setup phase.
Let’s tackle this comprehensively without disrupting your SCCM environment.

Key Issues to Address:

  1. Self-Signed Certificate and HTTPS Warnings:
    • A self-signed certificate is fine initially, but it’s worth replacing with a CA-issued certificate later for proper client trust.
    • This won't block postinstall, so we can revisit this after resolving the current issue.
  2. Critical Error During IIS Configuration:
    • WSUS fails to properly configure IIS because it can’t find a path. This could be:
      • A missing registry key indicating where WSUS expects virtual directories.
      • A mismatched IIS configuration (possibly due to SCCM virtual directories).
      • A corrupted WSUS Administration setup.

Step-by-Step Solution

Step 1: Validate WSUS Admin Site Configuration in IIS

Since you’re seeing a path issue, confirm whether WSUS is attempting to configure existing or missing virtual directories.
  1. List Current Virtual Directories:
    • Open IIS Manager, expand WSUS Administration, and confirm the presence of:
      • Content
      • ApiRemoting30
      • ClientWebService
      • ServerSyncWebService
      • DssAuthWebService
      • SelfUpdate
    • If any are missing:
      • Note which ones are absent.
      • We may need to manually recreate them later.
  2. Check WSUS Bindings:

Step 2: Validate WSUS-Related Registry Keys

WSUS relies on several registry keys during IIS configuration. Let’s check these paths are correct.
  1. Open Registry Editor (regedit).
  2. Navigate to:
    • HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup
  3. Validate these keys exist and point to valid locations:
    • ContentDir: Should match the CONTENT_DIR path you provided (e.g., D:\WSUS\WSUSCONTENT).
    • WebSite:
      • Value 1: Custom WSUS website (port 8530).
      • Value 0: Default website.
    If ContentDir or WebSite are missing/corrupt:
    • Add or correct them:
      • ContentDir:
        Code:
        text D:\WSUS\WSUSCONTENT
      • WebSite:
        Code:
        text 1
  4. Restart the server after updating.

Step 3: Check IIS Metabase Permissions

The error indicates WSUS can’t bind IIS directories through the IIS metabase.
  1. Grant WSUS Proper Access:
    • Ensure the WSUS Administration application pool runs with sufficient permissions:
      • Open IIS Manager > Application Pools > Locate WsusPool.
      • Set Identity to NetworkService.
  2. Reset IIS Configuration:
    If permissions seem correct but WSUS is still failing, reset IIS configurations:
    Code:
    bash iisreset /noforce

Step 4: Clean Up Leftover WSUS Configurations

The error might also be caused by remnants of an earlier WSUS configuration attempt that didn’t fully clean up.
  1. Remove WSUS Virtual Directories in IIS:
    • Manually delete the WSUS Administration site in IIS:
      • Right-click > Remove.
  2. Reset WSUS components:
    • Run:
      Code:
      bash wsusutil.exe deletecontent wsusutil.exe reset
  3. Recreate the WSUS Site:
    • Re-run postinstall to recreate the IIS configuration:
      Code:
      bash wsusutil.exe postinstall SQL_INSTANCE_NAME="YourInstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
    • If you need to skip IIS reconfiguration, try:
      Code:
      bash wsusutil.exe postinstall -skipIISConfig SQL_INSTANCE_NAME="YourInstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"

Step 5: Escalate with Logs

If the issue persists after all this, detailed logs will help pinpoint the exact failure point.
  1. Gather the following:
    • WSUSSetup.log:
      Code:
       C:\Program Files\Update Services\LogFiles\WSUSSetup.log
    • Change.log:
      Code:
       C:\Program Files\Update Services\LogFiles\Change.log
    • IIS logs:
      Code:
       C:\inetpub\logs\LogFiles
  2. Look for:
    • Errors related to paths (ContentDir, SelfUpdate).
    • Missing virtual directories.

Let me know where things stand after these steps. If logs or specific directories are issues, share findings, and I’ll provide more targeted fixes. We’re close to resolving this! 😊
 


1 is good.
2. Missing Website. Do I add this as a DWORD? and the vlaue 1 or is a string value
3 is OK
4 We should not do this because of SCCM correct?
5 Only the error in any logs is in the postinstall logs

Should I do a dsim ?
 


Thanks for the clarification! We’re narrowing this down, and your notes are super helpful. Let’s break things down and address Website (registry key), SCCM concerns, and whether DISM is worth running now.

1. Missing WebSite Registry Key

The WebSite registry key is critical for WSUS because it tells the postinstall process whether to use WSUS’s custom site (port 8530) or bind to the default IIS website (port 80). Since it's missing, WSUS cannot complete its IIS configuration. Let’s add it.

How to Add the WebSite Registry Key (DWORD):​

  1. Navigate to:
    Code:
     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup
  2. Create a new DWORD (32-bit Value):
    • Name: WebSite
    • Value:
      • 1 = Use a custom WSUS site (on port 8530).
      • 0 = Use the default IIS site (not recommended for SCCM setups).
  3. Restart IIS:
    Code:
    bash iisreset
  4. Test the wsusutil postinstall command again:
    Code:
    bash wsusutil.exe postinstall SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
This should fix the IIS configuration error unless another dependency is still misconfigured.

2. SCCM Concerns (Why We’re Avoiding Full IIS Reset/Cleanup)

You’re correct—we should not delete/rebuild the WSUS Administration site outright because SCCM relies on WSUS for its Software Update Point (SUP) role. Removing the IIS site could break SCCM's integration.
Instead, we’re focusing on:
  • Patching WSUS and IIS settings without destroying SCCM’s configuration.
  • Skipping modifications to existing SCCM folders like SMS and CCM.
If the postinstall fails, we'll escalate with manual fixes for specific virtual directories without deleting.

3. Running DISM – Should You?

Yes, it’s a good idea now that we’re double-checking key components. Your component store may have corruption impacting system configurations, including IIS or WSUS dependencies.

Steps for DISM Repair:​

  1. Run DISM Repair:
    Code:
    bash dism /online /cleanup-image /restorehealth
    • If this fails with an error (0x800f081f or missing source files), mount the Windows Server 2022 ISO and specify the source:
      Code:
      bash dism /online /cleanup-image /restorehealth /source:WIM:\Sources\install.wim:1 /limitaccess
      Replace with the ISO's mounted drive letter.
    • Run SFC (System File Checker):
      After DISM, verify all system files:
      Code:
      bash sfc /scannow
    • Restart the server if corruption is repaired and rerun postinstall.


4. Logs - Root Cause Narrowing

Since the only useful log error is from WSUSSetup.log, let’s re-confirm the context of relevant failures in:

WSUSSetup.log:​

Key line causing failure:
Code:
System.Runtime.InteropServices.COMException (0x80070003): The system cannot find the path specified.
This means WSUS is still pointing to:
  • An invalid/missing directory.
  • A missing registry key.
  • A broken IIS binding.
Recheck These After Adding WebSite Key:
A. ContentDir registry key (ensure exact match with D:\WSUS\WSUSCONTENT).
B. Bindings and virtual directories for SCCM/WSUS coexistence (port conflicts?).

Next Steps to Try Sequentially:​

  1. Add Missing WebSite Key:
    • Test WSUS functionality with WebSite=1 in the registry.
  2. Run DISM & SFC:
    • Focus on repairing any corruption blocking IIS or WSUS components.
  3. Retry Postinstall:
    • Rerun the safe postinstall command:
      Code:
      bash wsusutil.exe postinstall SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
    • If it still fails, add -skipIISConfig (this skips configuring the IIS website altogether):
      Code:
      bash wsusutil.exe postinstall -skipIISConfig SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
  4. Log Analysis:
    If errors persist, focus on gathering details from:
    • WSUSSetup.log
    • IIS logs:
      Code:
       C:\inetpub\logs\LogFiles\W3SVC1
Let me know how step-by-step attempts go—this narrowed issue can now be fixed for good. We’ve nearly got WSUS behaving as it should! 😊
 


To directly address your questions:

1. Do I add WebSite as a DWORD or String?

  • WebSite in the registry should be created as a DWORD (32-bit Value), not a string.
  • Set its value to:
  • 1 if you want WSUS to use a Custom Website (on port 8530, which is typical for WSUS).
  • (Optional) 0 for the default IIS website instead (not recommended, especially with SCCM).

Steps to Add:​

  1. Navigate to:
    Code:
     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup
  2. Right-click in the right pane > Select New > DWORD (32-bit) Value.
  3. Name it WebSite and set the Value to 1.

2. Should I Avoid Full IIS Recreation Due to SCCM?

You're correct to avoid recreating/removing the entire WSUS Administration site because SCCM depends on it. Removing or recreating it entirely could break SCCM's Software Update Point (SUP) role.
Instead:
  • Focus on correcting the registry keys (WebSite and ContentDir) and IIS settings without deleting anything.
  • If postinstall still struggles specifically in IIS, try running:
Code:
bash wsusutil.exe postinstall -skipIISConfig SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
This skips WSUS modifying IIS and might help move past the error.

3. Should I Run DISM?

Yes, absolutely. DISM helps repair core servicing components (IIS, Windows Update services, etc.), which could still be affecting WSUS.

DISM Command:​

Start a basic repair:
Bash:
dism /online /cleanup-image /restorehealth
If this fails due to missing source files, mount your Windows Server 2022 ISO and reattempt:
Bash:
dism /online /cleanup-image /restorehealth /source:WIM:\Sources\install.wim:1 /limitaccess

  • Replace with the path where your Windows Server 2022 ISO is mounted.

Follow this with:
Bash:
sfc /scannow
This ensures no system files are corrupted.

4. Retry wsusutil postinstall After Fixing Registry

Once registry corrections (WebSite=1) and DISM repairs are done:
  1. Re-run:
    Code:
    bash wsusutil.exe postinstall SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
  2. Monitor if IIS configurations still fail. If so, try with:
    Code:
    bash wsusutil.exe postinstall -skipIISConfig SQL_INSTANCE_NAME="InstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"

5. What's in the WSUSSetup.log?

The log is key for debugging! If postinstall keeps failing, look for:
  • Exact paths it says are not found (e.g., specific virtual directories).
  • Permissions-related errors.
Let me know if anything turned up in the log beyond the failure we’ve seen so far—or feel free to share snippets, and I’ll help analyze further!

Moving Forward

  1. Add WebSite as a DWORD and retry.
  2. Run DISM and SFC to clean up any servicing or component issues.
  3. Retry wsusutil with and without -skipIISConfig.
We’re zeroing in on this issue now, and each log or test helps refine the solution. WSUS and SCCM will cooperate again soon—I’m here for any updates! 😊
 


I am going to create a backup of what we have right now first then do the DSIM and update you after that. So probably on Monday.
 


That sounds like a perfect plan! Creating a backup now ensures you’ve got a solid fallback while we continue troubleshooting and refining with DISM over the next steps on Monday. Enjoy the weekend and come back refreshed—we’ll get WSUS playing nicely with IIS and SCCM soon enough. I’ll be here ready to assist whenever you’re back. Take care! 😊
 


Great! Running DISM is a solid step towards cleaning up any underlying issues in Windows that could be impacting WSUS and IIS configurations. This process should help restore any missing or corrupted system files that might be causing problems with key services.

Next Steps After Running DISM:​

  1. Monitor the DISM Output:
    • Once DISM completes, check for any warnings or errors.
    • If it reports successful repairs, that's a good sign!
  2. Run System File Checker (SFC):
    • After DISM, run the following to ensure all integrity issues are fixed:
      Code:
      bash sfc /scannow
  3. Reset IIS:
    • After running both DISM and SFC, it's good practice to reset IIS:
      Code:
      bash iisreset
  4. Retry WSUS Configuration:
    • Once everything is completed, try to run the WSUS postinstall command again:
      Code:
      bash wsusutil.exe postinstall SQL_INSTANCE_NAME="YourInstanceName" CONTENT_DIR="D:\WSUS\WSUSCONTENT"
  5. Check Logs Again If It Fails:
    • If it still doesn’t work, check the WSUSSetup.log and IIS logs for any new errors related to paths or service failures.

Let me know how the DISM process goes, and if it clears up issues! If any errors—especially those affecting WSUS—show up, feel free to share them for further analysis. I’m here to help! 😊
 


After 100% Error: 0c800f081f and at the end of the DSIM log there is

2024-12-09 07:29:39, Info DISM DISM Package Manager: PID=570048 TID=568028 CBS is being initialized for online use. More information about CBS actions can be located at: %windir%\logs\cbs\cbs.log - CDISMPackageManager::Initialize
2024-12-09 07:29:39, Info DISM DISM Package Manager: PID=570048 TID=568028 Loaded servicing stack for online use only. - CDISMPackageManager::CreateCbsSession
2024-12-09 07:29:39, Info DISM DISM Package Manager: PID=570048 TID=565732 Processing the top level command token(cleanup-image). - CPackageManagerCLIHandler::Private_ValidateCmdLine
2024-12-09 07:29:39, Info DISM DISM Package Manager: PID=570048 TID=565732 Attempting to route to appropriate command handler. - CPackageManagerCLIHandler::ExecuteCmdLine
2024-12-09 07:29:39, Info DISM DISM Package Manager: PID=570048 TID=565732 Routing the command... - CPackageManagerCLIHandler::ExecuteCmdLine
2024-12-09 07:29:39, Warning DISM DISM Package Manager: PID=570048 TID=565732 CBS AddSource failed with HRESULT=0x8007007b! - CDISMPackageManager::Internal_Finalize
2024-12-09 07:29:39, Info DISM DISM Package Manager: PID=570048 TID=565732 CBS session options=0x20100! - CDISMPackageManager::Internal_Finalize
2024-12-09 07:43:20, Info DISM DISM Package Manager: PID=570048 TID=568028 Error in operation: source for package or file not found, ResolveSource() unsuccessful. (CBS HRESULT=0x800f081f) - CCbsConUIHandler::Error
2024-12-09 07:43:20, Error DISM DISM Package Manager: PID=570048 TID=565732 Failed finalizing changes. - CDISMPackageManager::Internal_Finalize(hr:0x800f081f)
2024-12-09 07:43:20, Error DISM DISM Package Manager: PID=570048 TID=565732 The source files could not be found; their location must be specified using the /source option to restore the feature. - GetCbsErrorMsg
2024-12-09 07:43:20, Error DISM DISM Package Manager: PID=570048 TID=565732 Failed processing package changes with session option CbsSessionOptionRepairStoreCorruption - CDISMPackageManager::RestoreHealth(hr:0x800f081f)
2024-12-09 07:43:20, Error DISM DISM Package Manager: PID=570048 TID=565732 The source files could not be found; their location must be specified using the /source option to restore the feature. - GetCbsErrorMsg
2024-12-09 07:43:21, Error DISM DISM Package Manager: PID=570048 TID=565732 Failed to restore the image health. - CPackageManagerCLIHandler::ProcessCmdLine_CleanupImage(hr:0x800f081f)
2024-12-09 07:43:21, Error DISM DISM Package Manager: PID=570048 TID=565732 Failed while processing command cleanup-image. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x800f081f)
2024-12-09 07:43:21, Info DISM DISM Package Manager: PID=570048 TID=565732 Further logs for online package and feature related operations can be found at %WINDIR%\logs\CBS\cbs.log - CPackageManagerCLIHandler::ExecuteCmdLine
2024-12-09 07:43:21, Info DISM DISM Package Manager: PID=570048 TID=565732 Finalizing CBS core. - CDISMPackageManager::Finalize
2024-12-09 07:43:21, Info DISM DISM Manager: PID=569404 TID=569932 Closing session event handle 0x240 - CDISMManager::CleanupImageSessionEntry
2024-12-09 07:43:21, Info DISM DISM.EXE: Image session has been closed. Reboot required=no.
2024-12-09 07:43:21, Info DISM DISM.EXE:
2024-12-09 07:43:21, Info DISM DISM.EXE: <----- Ending Dism.exe session ----->
2024-12-09 07:43:21, Info DISM DISM.EXE:
 


Thank you for sharing the detailed DISM log output. The 0x800f081f error indicates that DISM was unable to find the required files to restore the image, which usually means that something's amiss in the component store or that the necessary source files weren’t provided during the command execution.
Let's dig into the details and consider our approach moving forward.

Key Log Messages to Note:​

  1. CBS AddSource failed with HRESULT=0x8007007b: This error means there was a problem accessing the specified source path.
  2. Failed processing package changes with session option CbsSessionOptionRepairStoreCorruption: This indicates that the repair attempt couldn't find or access the files it needed.

Steps to Resolve the Issue​

Step 1: Specify the Source Location

When running DISM, if the system can’t retrieve the required files from Windows Update (or through local sources), you should explicitly tell it where to find the installation files.
  1. Prepare a Windows Server 2022 ISO that matches your OS build:
    • Mount the ISO to a drive (e.g., D:).
  2. Run DISM Command with Source Parameter:
    If your data from the ISO is at D:\, use this command to run DISM:
    Code:
    bash dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:1 /limitaccess
    • This directs DISM to pull the necessary files from the mounted ISO.
    • Ensure the install.wim is present in the \sources directory.
  3. Be sure to replace drive letters based on how your system recognizes the mounted ISO.

Step 2: Review the CBS.log for Further Insight

If the DISM command fails again:
  • Check the CBS.log for additional detailed errors:
    Code:
     C:\Windows\Logs\CBS\cbs.log
  • It can provide more granular insight into what specific files or components are causing issues.

Step 3: Attempt SFC Again

After performing the DISM repair:
  • Run the System File Checker:
    Bash:
    sfc /scannow
  • This command checks for and attempts to repair any corrupted system files.

Step 4: Validate IIS and WSUS Configuration

While these DISM operations are ongoing, let’s ensure that the IIS and WSUS configurations are aligned for when the repairs complete.
  • Verify that the IIS virtual directories that WSUS uses are still present and correctly pointed to the content directory you specified.

Need for Backup & Reinstallation

If continuous errors occur despite following the corrective measures:
  1. Backup your WSUS Database:
    • As you noted earlier, ensure you have backups even before considering cascading changes.
  2. Consider In-Place Repair:
    • If repair efforts continually fail, an in-place upgrade repair might be the last resort. This involves running setup from the ISO and choosing the upgrade option to retain configurations:
      Code:
      bash D:\setup.exe

Conclusion​

  • Retry using the ISO for the DISM command to address the current corruption issues.
  • Keep analyzing the logs for specific errors that could be resolved independently.
  • Let me know the outcomes after trying these steps or if you need additional guidance; I’m here to help you through this! 😊
 


CBS.log several errors about hashes does not match and several Failed to GetFile from WIM sandbox process [HRESULT = 0x80070003 - ERROR_PATH_NOT_FOUND]
 


The logging from CBS.log indicating "hashes do not match" and "Failed to GetFile from WIM sandbox process [HRESULT = 0x80070003 - ERROR_PATH_NOT_FOUND]" underscores that there's an underlying issue with the WIM file you're pulling from, potentially corrupting files or misunderstanding paths during the DISM sessions.

Steps to Troubleshoot and Resolve​

  1. Verify the Integrity of the Mounted ISO:
    • Make sure that the Windows Server 2022 ISO you’re using is not corrupted. You can validate its integrity by checking the hash:
      Code:
      bash certutil -hashfile  SHA1
      • Compare the hash with the value provided by the source you downloaded from to ensure it's intact.
    • Remount the ISO:
      • Remount the ISO to ensure there’s no glitches:
        1. Unmount it from the current drive.
        2. Remount the ISO.
        3. Run the DISM command again using the correct path:
          Code:
          bash dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:1 /limitaccess
    • Select the Correct WIM Index:
      • If your ISO contains multiple editions, you might need to specify the right index if 1 isn’t valid:
        Code:
        bash dism /Get-WimInfo /WimFile:D:\sources\install.wim
      • Check the index number for the correct version of Windows Server 2022.
    • Using Different Sources for Repair:
      If the ISO continues to show issues:
      • You might want to try using another Windows Server 2022 installation medium (whether it’s another download or an installation CD/USB).
      • Alternatively, if you have an available source in a shared network folder that hasn’t shown problems, use that path.
    • Repairing Windows:
      If you confirm WIM integrity and still encounter issues, and if the system files can't be repaired using the methods discussed:
      • Consider performing a full repair via in-place upgrade with fresh installation ISO files. This method stabilizes potential corruoptions, while preserving settings and files:
        Code:
        bash D:\setup.exe

Handling CBS.log and Further Analysis​

  • Check for specific lines in CBS.log and correlate errors with the system. Focus on entries that detail failing hashes or specific components and gather the relevant output to provide deeper insights.

Final Note​

Discrepancies in WIM or ISO integrity can be responsible for cascading errors in both the DISM and CBS logs. Please update me after you try remounting or using a different source—especially if DISM still raises those errors while trying to repair. We’ll keep navigating this until we restore proper functionality! 😊
 


Sha1 or sha256? The hash on the download site state SH?A256 hash.
 


Back
Top