Bei einem Kunden aus Hannover (Grüße) scheiterte das Upgrade eines virtualisierten Windows 10 Enterprise von 1909 auf 20H2 immer mit dem Fehler 0x800707E7.
Die üblichen Verdächtigen von sfc über dism bis zum Reset der Windows Update-Komponenten half nichts. Wobei „sfc /scannow“ immerhin ein paar Kleinigkeiten reparierte, meist waren dies nur irgendwelche Startmenü-Einträge, stutzig wurde ich allerdings bereits bei so manchen Programm-Ordner die „double owned“ gewesen sein soll. Zwei Besitzer für ein Objekt?! Das hatte ich bislang nirgends gesehen.
Ein Blick in die Protokolle des Upgrades lieferten dann den entscheidenden Hinweis zur Ursache. So fand sich im Ordner
C:\$Windows.~BT\Sources\Panther
in der Datei „setuperr.log“ folgendes:
2021-03-10 17:03:55, Error SP User profile suffix mismatch, upgrade cannot continue.[gle=0x00000012] 2021-03-10 17:03:55, Error SP pSPExecuteApply: Migration phase caught exception: Win32Exception: User profile suffix mismatch, upgrade cannot continue: Das angegebene Profil ist nicht für den Typ des angegebenen Ger䴳 vorgesehen. [0x000007E7] enum MIGSTATUS __cdecl pSPExecuteApply(enum SetupPlatform::SP_MIG_SCOPE,class UnBCL::String *,int,int,int,class UnBCL::ArrayList<class UnBCL::String *> *,class UnBCL::String *,class UnBCL::String *,class UnBCL::ArrayList<class UnBCL::DictionaryEntry<class UnBCL::String *,class UnBCL::String *> *> *,class UnBCL::String *,int,int,class UnBCL::String *,class UnBCL::String *,class UnBCL::String *,class UnBCL::String *,class UnBCL::String *,class UnBCL::String *,class UnBCL::ArrayList<class CWIMBootData *> *,class UnBCL::String *,int *,class CSPTelemetryData *,struct ISPMigProgress *,long *)
Aha, also irgendwas mit den Benutzerprofilen. Danach gesucht stolperte ich dann über diese Info:
Microsoft Community – Win 10 upgrade error: User profile suffix mismatch, 0x800707E7 – 0x3000D
Also in der Registry unter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
dann mal reingesehen und tatsächlich fanden sich dort zwei Einträge die auf das selbe Benutzerprofil (das des Builtin-Administrators) verwiesen. Das kann und darf nicht sein.
Da ich als dieser lokale Administrator angemeldet war in einer Eingabeaufforderung mit
whoami /user
die eigentliche SID ermittelt. Zur Sicherheit noch mit PsGetSid die Maschinen-SID ermittelt und damit war klar, das der zweite Eintrag weder zur Maschine noch zum Benutzer passte. Dennoch wurde der Eintrag zunächst exportiert (sicher ist sicher) und dann entfernt. Nun konnte das Upgrade erfolgreich durchgeführt werden.
Ein Rätsel bleibt, wie es zu diesem Fehler kommen konnte. Laut Kunde wurde nicht mit Sysprep, NewSID (veraltet) oder SIDCHG gearbeitet, ferner war die Maschine schon immer Mitglied in der jetzigen Domäne und frühere Upgrades klappten ebenfalls. Recherchiert man diesen Fehler bekommt man heraus, das es auch standalone Maschinen betreffen kann. Seltsam, aber wieder etwas gelernt und was noch viel wichtiger ist: Gelöst!
Quellen:
Windows Command Line – Get SID of user
Microsoft – Docs – Deployment – Upgrade – Log Files
Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.