I had a similar issue on a server 2022 install where the updates would fail at 5% and 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
There are many threads on this topic and they often include a recommendation for an in-place upgrade as a fix, as I was dealing with a production server hosting 100 VMs, this was not a preferred option
Initial windows update error:
Some update files are missing or have problems. We'll try to download the update again later. Error code: (0x8007000d)
DISM.exe /Online /Cleanup-image /scanhealth
Result:
C:\Windows\system32>DISM.exe /Online /Cleanup-image /scanhealth
Deployment Image Servicing and Management tool
Version: 10.0.20348.681
Image Version: 10.0.20348.2762
[==========================100.0%==========================] The component store is repairable.
The operation completed successfully.
C:\Windows\system32>
DISM.exe /Online /Cleanup-image /Restorehealth
defaults to using windows updates as the source,
Result:
C:\Windows\system32>DISM.exe /Online /Cleanup-image /Restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.20348.681
Image Version: 10.0.20348.2762
[==========================100.0%==========================]
Error: 0x800f081f
The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see https://go.microsoft.com/fwlink/?LinkId=243077.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Mounting the source ISO also did not solve the issue
Mapping in the install ISO to the d Drive:
Find the correct index in install.wim dism
in PowerShell:
/Get-WimInfo /WimFile:D:\sources\install.wim
(Standard/Datacenter, GUI/Core, etc.)
DISM /Online /Cleanup-Image /RestoreHealth /source:WIM:D:\Sources\Install.wim:4 /LimitAccess
Result:
Deployment Image Servicing and Management tool Version: 10.0.20348.681
Image Version: 10.0.20348.2762
[==========================100.0%==========================] Error: 0x800f081f
The source files could not be found. Use the "Source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see https://go.microsoft.com/fwlink/?LinkId=243077.
This is where diving in to the DISM & CBS logs can provide insight into what the actual corrupt/mising file is
c:\windows\logs\dism
c:\windows\logs\cbs
In my instance, reading the DISM & CBS log files showed that the corrupt/missing file was: InkObj.dll
Hunting through the DISM and CBS log files showed it was looking for:
Info CBS (p) CSI Payload Corrupt (n) amd64_microsoft-windows-t..platform-comruntime_31bf3856ad364e35_10.0.20348.1850_none_72d42ded696bf4dd\InkObj.dll
After searching a working server I found the file located in :
wow64_microsoft-windows-t..platform-comruntime_31bf3856ad364e35_10.0.20348.2849_none_7d270cd39dce815 under the WinSxS folder
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
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
If you can locate the correct version ISO you should be able to create a VM with the correct version of files
In my case I happen to maintain a set of VM templates for different months of windows updates,
- this is not a common practice
I deployed the template, copied the WinSxS folder from the good source VM to the faulty server under C:\Repair_source\WinSxS
Carried out dism commands again:
DISM.exe /Online /Cleanup-image /Restorehealth /source:C:\Repair_source\WinSxS /LimitAccess
Result:
Deployment Image Servicing and Management tool
Version: 10.0.20348.681
Image Version: 10.0.20348.2655
[==========================100.0%==========================] The restore operation completed successfully.
I then ran:
sfc /scannow
Result:
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.
After this I was able to run windows updates again and successfully install the updates