Windows 11 In-Place Upgrade Blocked After Service Authentication Context Change

Hi Patryk,

Thank you for your detailed findings you're clearly handling this with great care.

Based on your results, it seems the upgrade failure is tied to residual artifacts from when the service used a local user account. Even after reverting to Local System, traces like registry keys under HKLM\SYSTEM\CurrentControlSet\Services[ServiceName]\Security, lingering SIDs, or WMI entries might still be triggering the block. Try to remove any stale service-related keys or SIDs from the registry and NTFS. Then Running SetupDiag.exe for hidden upgrade errors. Clearing WMI repository with winmgmt /salvagerepository. and reviewing CompatAppraiser.log for unseen flags.

Warm regards,

Cherrelyn

Hi Cherrelyn,

Thanks for the suggestions. Here's the implementation status:

1. Compatibility Logs Analysis

Status: No blocking issues found

Checked all files in C:\$WINDOWS.~BT\Sources\Panther\:

• All CompatData*.xml files show BlockingType="None"
• Setupact.log only shows generic failure at the end: 2025-07-05 00:04:51, Info MOUPG **************** SetupHost Logging End **************** 2025-07-05 00:05:14, Info SP WINDEPLOY error code is 0x8007139F. Will not attempt uninstall

Result: Error 0x8007139F provides no meaningful diagnostic information - it's a generic "something went wrong" code.

2. Residual ACLs Check

I added:icacls_findstr_after.txt

icacls_findstr_before.txt

to logs in OneDrive folder.

3. Setup Compatibility Engine Bypass

Status: Already extensively tested

I've tried all possible combinations from Windows Setup Command-Line Options | Microsoft Learn including:

• /compat ignorewarning
• /migratedrivers all
• /dynamicupdate disable
• Various combinations of the above
• Multiple other parameter combinations

Result: None of the setup parameters resolve the issue.

4. Clean Install/Imaging Approach

Status: Not feasible

Clean installs or custom imaging are not viable for our use case:

• a lot of computers requiring upgrade via MDM
• Enterprise environment requiring in-place upgrades
• Business continuity requirements

Current Situation

We have a very specific issue where service configuration determines Windows 11 upgrade compatibility.

Through systematic testing on clean .iso installations, I discovered:

Configuration A (Working):

• Service configured as Local System Account
• Result: Windows 11 upgrade succeeds

Configuration B (Failing):

• Service configured with local user account authentication
• Result: Windows 11 upgrade fails consistently

Key finding: This is not about "switching back and forth" between configurations. It's about specific configuration patterns that trigger upgrade compatibility assessment failures.

Critical issue: The problematic Configuration B has already been deployed to a lot of production computers. Simply changing the configuration back to Local System Account does NOT resolve the upgrade failure - some persistent artifacts remain that continue blocking the upgrade process.

The compatibility logs show no blocking issues, yet upgrade consistently fails with generic error codes when service uses local user authentication.

Any ideas for deeper forensic analysis or alternative approaches?

Let's not be afraid of breaking system, i have this machine virtualized with a lot of snapshots.

Best regards, Patryk

Hi Patryk, thank you so much for providing the extra detail and logs. I truly understand how complex and frustrating this is.

Please try these suggestion:

1. Focus on Compat Logs Again

Even if nothing changes in the snapshot, Windows Setup might still reference legacy policy or service traces. Please open the files inside:

C:\$WINDOWS.~BT\Sources\Panther\
- CompatData*.xml  
- Setupact.log

Search for:

-BLOCK

-the service name

-or anything pointing to Appraiser or MigSetup.

2. Strip Residual ACLs (Just in Case)

Run this in elevated PowerShell to look for orphaned SIDs:

icacls C:\ /T /C | findstr /i "S-1-5"

If any old user SIDs appear that aren’t in use anymore, you can remove them using:

icacls "C:\Path" /remove "S-1-5-xxxxxxxxxx"

3. Disable Setup Compatibility Engine Temporarily (Advanced)

You can try launching the upgrade with:

setup.exe /auto upgrade /eula accept /compat ignorewarning

Or even:

setup.exe /auto upgrade /eula accept /migratedrivers all /dynamicupdate disable

4. Final Option

If the service leaves no trace, yet triggers a block, you may be able to:

-Create a clean Win11 VHD on another machine

-Sysprep and generalize it

-Inject drivers + updates manually

-Then image it to your device using DISM or deployment tools

Let me know these suggestion, I'm here to help.

Warm regards,

Cherrelyn

The SECURITY is totally empty, Btw SAM is empty too, no entries.

But it's not blocking the Windows update - it's snapshot before running problematic service. After running nothing changes

whoami /groups

It's not changing after running service, i don't see / understand what SID should i check with icacls /findsid

I also added output from regshot comparision between not running / running service and output from procmon filtered out to problematic service to OneDrive - Logs

Hi Patryk,

I'm Cherrelyn, I'm happy to help and I completely understand how frustrating this issue is.

Please try these suggestion:

1.Clear LSA Secrets (Stored Service Passwords)

Run from elevated Command Prompt:

reg delete HKLM\SECURITY\Policy\Secrets /f

2.Remove Residual SIDs

Use whoami /groups and icacls C:\ /findsid <SID>

Then manually strip old SIDs from:

-Registry (HKEY_USERS)

-NTFS permissions (use icacls recursively)

3.Audit Remaining Service Traces

-Run sc queryex type= service and Get-WmiObject win32_service to confirm no ghosts

-Use Autoruns from Sysinternals to see hidden autostart remnants

4.Check Compatibility Logs

Look in:

C:$WINDOWS.~BT\Sources\Panther\Compat*.xml

and

%WINDIR%\Panther\setupact.log

for service or authentication-related upgrade block

If nothing works, the only workaround may be:

-Do a clean install of Windows 11 (back up apps/data first)

-Or use deployment tools like MDT/SCCM with a sysprepped image to bypass compatibility checks

Let me know about my suggestion, I'm here to guide for further assistance.

Warm regards,

Cherrelyn