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, Thanks again for the detailed follow-up your methodical approach is truly commendable. You've done a fantastic job clearing out the unnecessary SIDs and verifying the profile registry keys. You're right at this point, we've exhausted the surface-level cleanup and it's clear the issue is rooted deeper. Since the upgrade still fails after ACL and registry sanitization, I agree it’s time we pivot our strategy. Here’s what I recommend next: 1.In-Place Upgrade with Full Logs Captured Use the Windows 11 ISO and perform an in-place upgrade (not via Windows Update), while enabling logging: -Run the setup.exe from the ISO and choose keep files and apps -Let it fail again, then check C:$WINDOWS.~BT\Sources\Panther\setuperr.log and setupact.log These logs often hold exact blockers like driver compatibility, app reparse points, or permission issues. 2.DISM Log Deep Dive Since DISM /RestoreHealth hasn’t shown corruption, check %windir%\Logs\DISM\dism.log for suppressed errors or missing manifest issues. Occasionally, minor inconsistencies don't show up unless viewed here. 3.Offline Servicing (Optional but Advanced) If logs show a specific issue, we might prep the install image offline with DISM and inject fixes before the upgrade attempt. 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-06T13:27:19+00:00

Hi Patryk,

Thanks again for the detailed follow-up your methodical approach is truly commendable. You've done a fantastic job clearing out the unnecessary SIDs and verifying the profile registry keys. You're right at this point, we've exhausted the surface-level cleanup and it's clear the issue is rooted deeper. Since the upgrade still fails after ACL and registry sanitization, I agree it’s time we pivot our strategy.

Here’s what I recommend next:

1.In-Place Upgrade with Full Logs Captured

Use the Windows 11 ISO and perform an in-place upgrade (not via Windows Update), while enabling logging:

-Run the setup.exe from the ISO and choose keep files and apps

-Let it fail again, then check C:$WINDOWS.~BT\Sources\Panther\setuperr.log and setupact.log

These logs often hold exact blockers like driver compatibility, app reparse points, or permission issues.

2.DISM Log Deep Dive

Since DISM /RestoreHealth hasn’t shown corruption, check %windir%\Logs\DISM\dism.log for suppressed errors or missing manifest issues. Occasionally, minor inconsistencies don't show up unless viewed here.

3.Offline Servicing (Optional but Advanced)

If logs show a specific issue, we might prep the install image offline with DISM and inject fixes before the upgrade attempt.

Warm regards,

Cherrelyn
Czy ta odpowiedź była pomocna?

Komentarze: 0 Brak komentarzy