Windows Server 2025 Standard – DISM 0x800F0915 prevents RDS update installation; component store corruption

I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!

Hi Gabriel Shibata,

I’ll go through your five questions in order, then give you a suggested order of operations at the end.

1. Is there a known servicing issue affecting LServer_PKConfig.xml and tls_branding_config.xml?

I can’t point you to a published Microsoft known issue that names these specific files, so I wouldn’t treat it as a confirmed product defect yet. That said, the identical SHA-256 hash showing up on a different edition (Azure Edition) is a meaningful clue. It suggests the same bad or mismatched payload came through a common servicing path rather than random disk or memory corruption on your server. That’s exactly the kind of evidence Microsoft Support can check against their internal servicing data, so I’d open a support case and attach your CBS excerpts plus a link to the other Q&A thread. If it is a known pattern, they can sometimes supply the correct payload directly, which is the cleanest fix of all.

2. What’s the supported repair procedure when both Windows Update and a WIM source fail with 0x800F0915?

0x800F0915 means DISM found the corruption but couldn’t find a matching replacement in any source it was given. Your repair failed because the source didn’t match, not because the procedure is wrong. DISM needs content that matches your installed edition, build, servicing level and language resources exactly, and an Evaluation image fails on several of those counts. The supported approach is still DISM /RestoreHealth with /Source and /LimitAccess. You just need a better source, which brings us to question 3.

One thing worth checking first: you mentioned the servicing state shows component versions newer than your running build. Open CBS.log and note the exact component versions DISM is asking for (search for lines mentioning missing or failed payloads). Your repair source has to contain those versions, not just 26100.33438. If they belong to a later cumulative update that partially staged, your source needs that update applied too.

3. Is there a validated repair source for Server 2025 Standard with pt-BR?

There are two good options, and I’d go with whichever is easier for you to stand up:

• A healthy running server (usually the easiest). Build a Windows Server 2025 Standard (Desktop Experience) VM from licensed media, not Evaluation. Add the pt-BR language pack and patch it to the same level as production, including any newer LCU that CBS.log shows partially staged. Then share it and run: DISM /Online /Cleanup-Image /RestoreHealth /Source:\\HealthyServer\C$\Windows /LimitAccess Microsoft supports using the Windows folder of a running installation as a repair source, and this is often the fastest way to get a perfect match.
• A serviced offline image. Take install.wim from the licensed Server 2025 ISO, use DISM /Get-WimInfo to find the Standard (Desktop Experience) index, and mount that index. Add the pt-BR language pack from the Languages and Optional Features ISO, then the cumulative updates from the Microsoft Update Catalog. Server 2025 uses checkpoint cumulative updates, so apply any required checkpoint package before the latest LCU. Then point /Source at the mounted \Windows folder.

4. Can the RDS cumulative update be installed while the store is in this state?

Technically you can try installing the .msu from the Update Catalog directly with DISM /Online /Add-Package, because a newer LCU sometimes carries the payload that replaces the damaged files. With 0x800F0991 already being reported, though, I wouldn’t count on it. On a production DC, a half-applied LCU can leave you worse off than you are now. My honest recommendation is to repair the component store first, then install the update. In the meantime, your current workaround (restarting the Remote Desktop Services service when Event 20498 appears) is a reasonable stopgap. Just do it during quieter periods, since it drops active sessions.

5. Can this be fixed without touching WinSxS, reinstalling, or doing an in-place upgrade?

Yes, in most cases, as long as you can provide a matching source as described above. That’s precisely what /RestoreHealth with /Source is designed for, and you were right not to hand-edit WinSxS, because that isn’t supported. If even a correctly matched source fails, Microsoft’s supported fallback is an in-place repair install from same-version media, keeping files and apps. It preserves roles and data, and Microsoft documents it for domain controllers, but I understand why it’s your last resort.

Suggested order of operations

1. Take a full bare-metal backup and a System State backup. This is a DC, so this step isn’t optional.
2. Pull the exact required component versions from CBS.log.
3. Build the matching repair source (healthy VM or serviced WIM) with pt-BR and the right update level.
4. Run /RestoreHealth with that source and /LimitAccess, then sfc /scannow.
5. Install the cumulative update containing the RDS fix, and watch for Events 20498, 6006 and 7031 over the next few days.
6. Open a Microsoft Support case in parallel, so you have a fallback if the source repair still comes up short.

One longer-term note: running RDS Session Host on a domain controller isn’t recommended. Session load and service instability like this end up affecting AD and DNS too. Once things are stable, I’d plan to move RDS to its own server.

Hope this helps you get servicing working again with minimal disruption. If it does, I’d really appreciate it if you could hit “Accept Answer” so others running into the same error can find it quickly

Jason