![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(179.20000000000002, 32%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECM%3C/text%3E%3C/svg%3E)
Hello Corey,
Thank you for posting your question on the Microsoft Windows Forum!
Thank you for providing such detailed troubleshooting information. You've already completed many of the steps that would normally be recommended for an update failure of this type, which helps narrow the investigation considerably.
The most important finding
The most significant detail in your investigation is that:
CBS consistently reports 0x80073701 (ERROR_SXS_ASSEMBLY_MISSING)
The missing assembly is NetworkController-Server-Deployment version 10.0.20348.3932
The corresponding manifest is absent from WinSxS
DISM and SFC both report no corruption
This combination suggests that the issue may not be traditional component store corruption, but rather a servicing inconsistency where a package remains registered in the servicing stack while one of its required deployment manifests is no longer available.
What your findings already tell us
A few of your observations are particularly valuable:
The failure occurs with both Windows Update and standalone. MSU installation.
The affected package is present and registered as Staged.
Newer NetworkController manifest versions exist.
DISM completes successfully but explicitly states that no corruption was detected.
Because DISM doesn't believe the component store is corrupt, it would also explain why:
DISM /RestoreHealth
is not restoring the missing deployment manifest even when a repair source is supplied.
Regarding targeted CBS repair
From a supported servicing perspective, manually copying manifests into:
C:\Windows\WinSxS
would not be recommended.
The servicing stack maintains package metadata, catalog relationships, and component identities that are not fully repaired by manually restoring individual files, even when the correct manifest has been extracted from a Microsoft package.
One area that may be worth investigating further
Since the package is currently reported as:
Staged
I'd be interested in whether the servicing registration and package state are still internally consistent.
If you haven't already reviewed it, it may be helpful to compare the package state for:
NetworkController-Server-Package
and its related deployment package versions using:
DISM /Online /Get-Packages
to determine whether an earlier package revision remains partially staged or superseded.
Considering the server role
You also mentioned that this server is:
The only domain controller
DNS server
File server
Given those responsibilities, I appreciate your desire to avoid an in-place upgrade or rebuild unless absolutely necessary.
At this stage, based on the information provided, I'm hesitant to recommend invasive servicing modifications without a clearer understanding of the package registration state.
One clarification
Corey, were you able to identify whether the missing:
NetworkController-Server-Deployment
10.0.20348.3932
assembly is referenced by only a single package, or do the CBS logs show multiple package families attempting to resolve that same deployment identity?
That detail may help determine whether we're looking at a single damaged package registration or a broader servicing-stack inconsistency.
Thank you again for the thorough investigation and for sharing your findings. Your analysis has already ruled out many of the common causes of update failures, and any additional package-registration information you can provide would be very helpful in narrowing down the next step.
I hope this information is helpful. If so, please click on Accept Answer and consider upvoting it. Doing so helps other community members identify useful solutions to similar issues.