Hello, According to your description, I suggest that using a good machine OS image to repair or copy all Winsxs fold from the good machine to repair by using dism command. It means that the machine will check the good image or good WinSXS file to scan the package. Just like below: DISM /Online /Cleanup-Image /RestoreHealth /Source:G\Sources\install.wim /LimitAccess DISM /Online /Cleanup-Image /RestoreHealth /Source:G\WinSXS /LimitAccess Some information below may helpful. https://www.windowscentral.com/how-use-dism-command-line-utility-repair-windows-10-image Best Regards, Hania Lian

If the Answer is helpful, please click "Accept Answer" and upvote it.

I had a similar issue: windows update gets to 5% then fails error code 0x800f081f

Using DISM /Online /Cleanup-Image /ScanHealth - reports there is an error
DISM.exe /Online /Cleanup-image /Restorehealth always gave the error source not found

Further reading shows the DISM.exe /Online /Cleanup-image /Restorehealth defaults to using windows updates as the source

it is possible to point DISM to differing source locations

mounting various version of the install ISO to the d drive of the affected system:
DISM /Online /Cleanup-Image /RestoreHealth /source:WIM:D:\Sources\Install.wim:1 /LimitAccess
I found that it did not matter what I used to as the source for the dism command, it always came back as source not found

In my instance, reading the DISM & CBS log files showed that the corrupt/missing file was: InkObj.dll

c:\windows\logs\dism

c:\windows\logs\cbs

After searching a working server I found the file located in :

wow64_microsoft-windows-t..platform-comruntime_31bf3856ad364e35_10.0.20348.2849_none_7d270cd39dce815

However trying to use that version of the file for the repair did not work - it gave an error of an invalid hash, meaning it was not the version of the file that was required to fix the error

deleting the folder and re-running dism then gave the error that it could not find the source files ( this was what it was doing every time)
Hunting through the DISM and CBS log files showed it was looking for:

amd64_microsoft-windows-t..platform-comruntime_31bf3856ad364e35_10.0.20348.1850_none_72d42ded696bf4dd\InkObj.dll

The clue to which version is in the folder name: 10.0.20348.1850 is the specific version of the operating system that is required

a google search gave this as the July 2023 version
In my case I happen to maintain a set of VM templates for different months of windows updates, I deployed the template, copied the winsxs folder to the faulty server under C:\Repair_source\WinSxS

Carried out dism commands again:

C:\Windows\system32>DISM.exe /Online /Cleanup-image /Restorehealth /source:C:\Repair_source\WinSxS /LimitAccess

Deployment Image Servicing and Management tool

Version: 10.0.20348.681

Image Version: 10.0.20348.2655

[==========================100.0%==========================] The restore operation completed successfully.

The operation completed successfully.

I then ran sfc to complete the repair

C:\Windows\system32>sfc /scannow

Beginning system scan. This process will take some time.

Beginning verification phase of system scan.

Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.

For online repairs, details are included in the CBS log file located at

windir\Logs\CBS\CBS.log. For example C:\Windows\Logs\CBS\CBS.log. For offline

repairs, details are included in the log file provided by the /OFFLOGFILE flag.

This resolved the issue and I was able to run windows updates If you have access to older version ISO files it should be possible to build the required version folders and files

1  What the logs tell us

Symptom in the logWhat it really meansFAILED [80070003] …SusMoveOrCopyDirectoryContentsHelper…Windows Update (WU) can’t find or copy files it just downloaded – the local SoftwareDistribution cache is broken.*FAILED* [80070003] …SusMoveOrCopyDirectoryContentsHelper…Windows Update (WU) can’t find or copy files it just downloaded – the local SoftwareDistribution cache is broken.hr=0x8024500C on many WSUS callsThe client is talking to WSUS, but WSUS is refusing certain service calls (often because the update metadata is stale).Do not connect to Windows Update Internet locations: **Yes**A GPO or registry value forces the server not to go to Microsoft’s public update/repair endpoints, so DISM cannot download replacement component files, which leads to 0x800f081f.Packages that repeatedly download but never commit, e.g. KB5049608The same cumulative updates are cycling, indicating the component store is corrupt.Putting those pieces together:

• DISM fails with 0x800f081f because it is blocked from fetching repair payloads.
• WU fails at 5 % because the local cache is already damaged and WSUS cannot supply the missing components.

2  Step-by-step repair

Do the steps in order; reboot where indicated.

2.1  Get a clean component source (critical)

1. Mount Windows Server 2022 ISO that exactly matches the build on the box (e.g. 20348.x).
2. From an elevated PowerShell prompt:

1. If the ISO contains install.esd, substitute that file.

2.2  Temporarily bypass WSUS & let DISM/WU reach the ISO or Microsoft

You only need this until the image is healthy again.

# Save current WSUS configuration
reg export "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" %temp%\wsus.reg

# Disable WSUS & allow Internet repair
reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /f
gpupdate /force

Or use GPMC ➜ Computer Config → Administrative Templates → System → Specify settings for optional component installation and component repair  ✔ “Download repair content from Windows Update”.

2.3  Reset the local WU cache

You have done most of this; add the DataStore wipe and make sure services stay stopped while renaming:

net stop wuauserv & net stop cryptSvc & net stop bits & net stop msiserver
rd /s /q %windir%\SoftwareDistribution
rd /s /q %windir%\System32\catroot2
net start wuauserv & net start cryptSvc & net start bits & net start msiserver

2.4  Repair the system files

sfc /scannow
# If SFC says files were repaired, run it a second time – it must return 100 % clean

2.5  Install the stuck updates manually (optional but quicker)

Download each CAB/MSU from the Microsoft Update Catalog (bypasses WSUS):

wusa Windows10.0-KB5049608-x64.msu /quiet /norestart
wusa Windows10.0-KB5058392-x64.msu /quiet /norestart
wusa Windows10.0-KB4589208-v2-x64.msu /quiet /norestart
wusa Windows10.0-KB4577586-x64.msu /quiet /norestart

2.6  Re-enable WSUS (after everything succeeds)

reg import %temp%\wsus.reg
gpupdate /force

Then:

wuauclt /detectnow /reportnow

3  If problems persist

• Check WSUS – run Server Cleanup Wizard, then synchronize so the catalog contains the latest Server 2022 updates.
• Disk space / antivirus – ensure at least 10 GB free on the system drive and exclude C:\Windows\SoftwareDistribution from real-time AV scanning.
• In-place “repair-install” – running setup.exe from the same ISO and choosing Keep everything refreshes the component store without touching roles or data.
• Open a support case – Microsoft still covers Server 2022 mainstream; have the latest CBS.log and Get-WindowsUpdateLog output ready.

4  Why this works

• DISM can now find the files it needs (so 0x800f081f / 0x8007000d disappear).
• A fresh SoftwareDistribution cache removes the 80070003 file-not-found condition.
• Letting the server talk directly to Windows Update – even briefly – clears the 8024500C federated-service failures and refreshes WSUS data when you re-enable it.

Hand these notes over, and your colleague should be able to bring the server fully current without re-imaging it.

# Find the correct index in install.wim
dism /Get-WimInfo /WimFile:E:\sources\install.wim
# Replace <Index#> with the right number (Standard/Datacenter, GUI/Core, etc.)
dism /Online /Cleanup-Image /RestoreHealth `
     /Source:E:\sources\install.wim:<Index#> `
     /LimitAccess