[English]Noch eine kurze Information für Administratoren, die Windows 11-Clients in Unternehmensumgebungen verwalten. Mit dem April 2024 Preview-Update KB5036980 hatte Microsoft Administratoren ein Problem beschert, die von Windows 11 Pro auf Windows 11 Enterprise umstellen wollten und dazu AutoPilot verwendeten. Rudy Ooms hat das Thema analysiert und einen Fix entwickelt. Microsoft ist sich des Problem bewusst und will einen Fix veröffentlichen – momentan ist mir unklar, ob das schon mit dem Mai 2024-Updates passiert ist.
Anzeige
Windows 11 23H2/22H2: Preview Update KB5036980
Microsoft hat zum 23. April 2024 das Preview Update KB5036980 für die aktuelle Windows 11-Version 22H2 – 23H2 freigegeben (siehe Windows 11 23H2/22H2: Preview Update KB5036980 (23. April 2024)). Im Support-Beitrag für Update KB5036980 werden eine Reihe Qualitätsverbesserungen und Fixes aufgelistet.
Enterprise-Upgrade kaputt
Administratoren in Unternehmensumgebungen werden Windows 11 Pro auf Windows 11 Enterprise aktualisieren. Das kann mittels AutoPilot erfolgen, sofern die betreffenden Abos für Enterprise vorhanden sind. Wer eine Microsoft 365 E5-Lizenz hat, ist zu einem Upgrade auf Windows 11 Enterprise berechtigt. Dieses Abonnement-Upgrade sollte automatisch erfolgen, wenn sich der Benutzer am Gerät anmeldet – sofern die Abonnementaktivierung funktioniert.
Ich bin aber bereits vor einigen Wochen, im Mai 2024 auf Tweets von MVP Rudy Ooms gestoßen, der berichtet, dass genau das nicht funktioniert und es Probleme mit der Aktivierung des Enterprise-Abonnements während des Updates von Windows Pro auf Enterprise gibt, wenn dies per AutoPilot passiert.
Rudy Ooms hatte bereits zum 3. Mai 2024 den Blog-Beitrag The KB5036980 breaks the Windows 11 Enterprise Subscription Activation zum Thema veröffentlicht. Mit dem erwähnten Preview Update KB5036980 für die aktuelle Windows 11-Version 22H2 – 23H2 hat sich ein Bug eingeschlichen. Die Aktivierung von Upgrade auf Windows 11 Enterprise-Lizenzen für Windows 11 Pro-Maschinen klappt nur, wenn das verwendete Konto ein Mitglied der lokalen Administratorgruppe ist. Meldet sich ein Standardbenutzer an, wirft ein automatisch ausgeführter Task LicenseAcquisition den Fehler 0x80004005 (Access is denied).
Anzeige
Ooms hat es genauer analysiert und im obigen verlinkten Blog-Beitrag dokumentiert: Das Problem ist, dass einem Standardnutzer die Berechtigung zum Anlegen von Schlüsseln in der Registrierung fehlt, die aber zum Upgrade benötigt werden. Daher hat Ooms einige Workarounds entwickelt, die die Berechtigungen zum Zugriff auf die benötigten Schlüssel auf "Jeder" setzen. Das ist mit einem PowerShell-Script beispielsweise möglich.
In einem Nachtrag vom 22. Mai 2024 erwähnt Ooms nun, dass Microsofts Produktteam bereits zum 3. Mai in einem Post schreibt, dass man sich des Problems bewusst sei. Es gibt wohl bereits einen Fix, aber Anfang Mai 2024 war unklar, wann dieser mit einem Update ausgerollt wird. Zum Mai 2024-Patchday am 14.5. scheint dies noch nicht der Fall gewesen zu sein – oder ist das Problem behoben?
Anzeige
Profis!
Erst testet man Update nur in "rein" englischen Installationen, achtet aber nicht auf Sprach Unabhängigkeit, so das "rein" "rest-der-Welt" oft scheitert. Ddann testet man Upgrades nur Usern die lokale Admin-Rechte haben.
So etwas will man haben.
Back to the 80th.
Damals war jedes Update ein hohes Risiko und wurde am liebsten nur gemacht, wenn es ein konkretes aktuelles Problem offensichtlich verbesserte und auch nur nach tests.
Bis Gates den Sauhaufen aufgeräumt hat.
Und siehe da. Nach 2 Jahren konnte man automatisches Einspielen von Updates riskieren.
Gates ist in Rente.
Eines gehört auch noch dazu: Die testen nie mit Roaming-Profilen. Anders ist es nicht zu erklären, dass z.B. der Teams-Client gigabyteweise Daten in den 'Roaming'-Teil unter username/appdata schaufelt, was bei einer Anmeldung auf einem anderen Rechner zu erheblichen Wartezeiten führt, da die ganzen Kleindateien erstmal abgeglichen werden müssen.
Witzigerweise kann man die problemlos löäschen, bei der näüchsten Team-Sitzung werden sie dann wieder angelegt. Könnte man also problemlos unter dem lokalem Profilteil ablegen, aber dazu müsste man ja mitdenken…
Ist der Client nicht am LAN, sondern am WAN, kann das mitunter zur Unbenutzbarkeit führen.
Da bin ich komplett bei Dir, hatte das Problem auch bei einem Kunden. Zum Glück kannst Du die entsprechenden Teams-Ordner per GPO von der Synchronisation mittels Roaming-Profiles ausschließen.
Ansonsten ist es ein Trauerspiel, was Microsoft da abliefert.