Environment Details Source OS: Windows 10 Pro 22H2 (Build 19045.6036) Target OS: Windows 11 Pro (latest .iso) Hardware: TPM 2.0 enabled, Secure Boot enabled, UEFI Domain: Workgroup (local machines) Upgrade Method: Setup.exe /auto upgrade /eula accept LOGS from installation - OneDrive Logs Problem Statement Windows 11 in-place upgrade consistently fails after a third-party service was initially configured with user account authentication and later reconfigured to LocalSystem. Despite complete service removal, the upgrade process fails during compatibility assessment. Service Configuration Timeline Original Working State Service: [ThirdPartyService] Log On As: Local System account Result: Windows 11 upgrade succeeds Problem Configuration Service: [ThirdPartyService] Log On As: This account Username: [local user account] Password: [provided] Result: Windows 11 upgrade fails Current State (Still Failing) Changed back to: Local System account Service stopped and disabled Service completely uninstalled and removed Result: Windows 11 upgrade still fails What I've Already Tried Please assume I've applied every solution from the first 20 pages of Google, Bing, DuckDuckGo and Yandex. I'm not a novice and have exhausted standard troubleshooting procedures including: ✅ sfc /scannow and DISM /RestoreHealth ✅ Windows Update troubleshooter and reset ✅ Manual Windows Update service restart/reset ✅ Registry cleanup of obvious service entries ✅ Temp file cleanup and disk cleanup ✅ Antivirus disabling during upgrade ✅ All Windows 11 compatibility requirements verified ✅ Memory test and hardware diagnostics ✅ Different upgrade methods (/auto upgrade, /eula accept, compat /ignorewarning, migneo /disable and many others, various combinations) ✅ Upgrade advisor tools and PC Health Check ✅ Event log analysis for obvious error patterns ✅ Even debugging windows kernel while upgrading through network Core Technical Question What persistent authentication artifacts remain in Windows after changing a service from user account authentication back to LocalSystem that could block Windows 11 upgrade compatibility assessment? I suspect the issue relates to: LSA Secrets - encrypted service account credentials persisting in registry Security Identifier (SID) artifacts - service-specific SIDs remaining in system databases File system ACL modifications - NTFS permissions retaining references to deleted service accounts Authentication context inconsistencies - security token artifacts causing compatibility assessment failures But i'm more Linux guy and i don't have deep knowledge about how Windows actually works. And the issue is very strange for me - please help.

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

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

Anonimowe

Environment Details

Source OS: Windows 10 Pro 22H2 (Build 19045.6036)
Target OS: Windows 11 Pro (latest .iso)
Hardware: TPM 2.0 enabled, Secure Boot enabled, UEFI
Domain: Workgroup (local machines)
Upgrade Method: Setup.exe /auto upgrade /eula accept

LOGS from installation - OneDrive Logs

Problem Statement

Windows 11 in-place upgrade consistently fails after a third-party service was initially configured with user account authentication and later reconfigured to LocalSystem. Despite complete service removal, the upgrade process fails during compatibility assessment.

Service Configuration Timeline Original Working State

Service: [ThirdPartyService]
Log On As: Local System account
Result: Windows 11 upgrade succeeds

Problem Configuration

Service: [ThirdPartyService]
Log On As: This account
Username: [local user account]
Password: [provided]
Result: Windows 11 upgrade fails

Current State (Still Failing)

Changed back to: Local System account
Service stopped and disabled
Service completely uninstalled and removed
Result: Windows 11 upgrade still fails

What I've Already Tried

Please assume I've applied every solution from the first 20 pages of Google, Bing, DuckDuckGo and Yandex. I'm not a novice and have exhausted standard troubleshooting procedures including:

✅ sfc /scannow and DISM /RestoreHealth
✅ Windows Update troubleshooter and reset
✅ Manual Windows Update service restart/reset
✅ Registry cleanup of obvious service entries
✅ Temp file cleanup and disk cleanup
✅ Antivirus disabling during upgrade
✅ All Windows 11 compatibility requirements verified
✅ Memory test and hardware diagnostics
✅ Different upgrade methods (/auto upgrade, /eula accept, compat /ignorewarning, migneo /disable and many others, various combinations)
✅ Upgrade advisor tools and PC Health Check
✅ Event log analysis for obvious error patterns
✅ Even debugging windows kernel while upgrading through network

Core Technical Question

What persistent authentication artifacts remain in Windows after changing a service from user account authentication back to LocalSystem that could block Windows 11 upgrade compatibility assessment?

I suspect the issue relates to:

LSA Secrets - encrypted service account credentials persisting in registry
Security Identifier (SID) artifacts - service-specific SIDs remaining in system databases
File system ACL modifications - NTFS permissions retaining references to deleted service accounts
Authentication context inconsistencies - security token artifacts causing compatibility assessment failures

But i'm more Linux guy and i don't have deep knowledge about how Windows actually works. And the issue is very strange for me - please help.

Pytanie zablokowane. To pytanie zostało zmigrowane ze społeczności pomocy technicznej firmy Microsoft. Możesz zagłosować, czy pytanie jest pomocne, ale nie możesz dodawać komentarzy ani odpowiedzi, ani też śledzić pytania.

Komentarze: 0

Odpowiedzi: 11

Anonimowe

2025-07-05T03:53:17+00:00
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
Czy ta odpowiedź była pomocna?

Komentarze: 0 Brak komentarzy