Lenovo T520 “DVD-Laufwerk” ausgeschaltet … Windows 10

Auf dem kürzlich installierten Lenovo T520 hatte ich auf einmal das Problem, dass ein ausgeschaltetes DVD-RW-Laufwerk angezeigt wurde.

dvd

Ich denke, die Meldung muss man gesehen haben um sie zu verstehen Smile Mit einem Doppelklick auf das Laufwerk erschien dann die folgende Fehlermeldung.

Zu dieser gab es zum Glück eine Solution bei Lenovo, die aber leider nicht funktionieren wollte. Weder die Installation des Lenovo Power Manager Driver for Windows 10 (Version 1703 or Later) noch der Lenovo SystemInterfaceFoundation konnten das Problem beheben.

Zusätzlich zu diesen beiden Lenovo Komponenten musste das Verhalten in der Registry von Windows 10 deaktiviert werden. Was über den folgenden Eintrag möglich ist.

# Deaktivieren der DVD-RW Abschaltung
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Lenovo\PWRMGRV\Data]
"AutomaticOddDisable" = dword:00000000

dvd-3

Damit war nach einem Neustart das Problem behoben.

Enjoy it, b!

Installation Lenovo T520 (42404CG) mit Windows 10

Das klingt nun wie ein Beitrag aus der palliativen IT, aber ich bin halt der Meinung das man Hardware nicht einfach wegwerfen darf. Vor geraumer Zeit habe ich ein Lenovo T520 (42404CG), noch mit Windows 7 in die Hände bekommen. Mit den Worten, dass kann weg …

Die Hardware

Über das darauf installierte BIOS bekam ich den Hinweis, dass dieses Gerät mindestens 10 Jahre alt sein musste.

image

Das dann über die Lenovo Support-Webseite immerhin noch auf eine Version aus dem Jahr 2016 aktualisiert werden konnte Smile

Die T-Serie von Lenovo ist für mich immer noch etwas besonders, quasi ein Garant für gute Hardware die lange Zeit ihren Dienst tut. Nachdem ich in meinen Hardware-Kisten gewühlt hatte, fanden sich weitere 4GB RAM (interessanter Weise die gleichen die schon im Gerät verbaut waren) und eine Samsung SSD 750 EVO die einen noch recht neuen Eindruck machte.

image

Erweiterungs-Slot

image

Die Samsung SSD erwies sich dazu als absoluter Glücksgriff, denn sie war mit gerade mal 149 Stunden noch nicht wirklich lange im Betrieb gewesen, zumal sie eine Kapazität von 500GB bereitstellte.

image

Nach dem Einbau der Erweiterungen, hatte ich die folgende Konfiguration.

image 

Lenovo T520

  • Intel Core i5-2410M
  • 8GB (2x 4GB Kingston DDR3 RAM mit 667MHz
  • Samsung SSD 750 EVO mit 500GB
  • BIOS-Version: 8AET65WW 1.45

Nun sollte noch Windows 10 auf der Hardware installiert werden.

Windows 10

Die Installation von Windows 10 lief problemlos ab und die meisten Treiber wurden automatisch über das Windows Update gefunden. Bei alten Geräten habe ich es mir inzwischen zur Gewohnheit gemacht, dass ich mich der Optionalen Updates von Windows 10 bediene, dort sind sehr häufig passende Treiber älteren Datums enthalten.

image

image

Über diesen Weg konnte ich die folgenden Treiber für das Lenovo T520 finden und damit waren auch Treiber vorhanden welche mir über Lenovo Vantage nicht mehr angeboten wurden.

image

Wie hier zu sehen ist, sind fast alle Treiber dabei. Auch der mysteriöse “Biometric Coprocessor” löste sich damit als Fingerprint-Reader auf (DigitalPersona, Inc … 1.7.0.415)

Lenovo Vantage hingegen, wollte mir nur zwei Updates für ohnehin schon installierte Treiber anbieten.

image

Somit blieb am Ende lediglich ein einziges Gerät übrig für das es keinen passenden Treiber zu geben schien. Ich hätte es dabei belassen können, aber ich bin halt ein Freund von sauberen und vollständigen Windows Installation.

image

Für dieses Modem, was ohnehin nicht mehr in Einsatz kommen sollte. Liefert Lenovo immerhin noch einen mit Windows 7 kompatiblen Treiber, denn ich in Ermangelung einer neuen Version installiert habe.

image

Damit war auch der Geräte-Manager vollständig und das Notebook fertig installiert.

image

Ich denke und hoffe, dass dieses Gerät noch einige Zeit zuverlässig seinen Dienst tun wird. Für den Einsatz im Büro, oder auch in der Schule ist es hinreichend dimensioniert.

Enjoy it, b!

Fix: Windows 10 Update 21H2 und der Essentials Connector

Info: Bitte die Update Historie unten lesen, ursprünglich wurde das Script für Windows 10 Version 1903 entwickelt und seitdem immer wieder getestet und aktualisiert. Für alle die nicht lesen wollen, die aktuelle Version des Scripts befindet sich hier .

For the english version, please follow this Link.

Zumindest aus Sicht des Windows Server Essentials Connector ist jedes Update von Windows 10 spannend. Die seit gestern offiziell verfügbaren Version 1903 für Windows 10 versäumt es beim Upgrade, die für die Ausführung des Windows Server Essentials Connectors notwendigen Dienste (Services) zu migrieren. Die sind nach dem Update nicht mehr vorhanden.WSE-1903

Damit ist der Windows 10 Client nicht mehr in der Lage sich am Windows Server Essentials an zu melden um seinen Status zu kommunizieren oder eine Sicherung durch zu führen. Im Dashboard des Server erscheint der Client Offline.

image

Damit das wieder klappt, müssen die Services hergestellt werden. Das geht am einfachsten durch das folgende Script, welches die Services in Form von REG-Dateien in die Registry importiert. Im Anschluss, nach einem Neustart funktioniert der Connector ohne Probleme.

image

Das Script und die dazu notwendigen REG-Dateien sind in der ZIP Datei als Download verfügbar. Für eventuelle Schäden lehne ich jegliche Haftung ab.

  • Die Ausführung des Scripts muss in einer PowerShell-Session als Administrator erfolgen
  • Script und REG-Dateien müssen zwingend im gleichen Verzeichnis liegen
  • Das Script prüft ob es sich um den Version 1903 oder höher handelt. Nur dann werden die REG-Dateien in die lokale Registry des Windows 10 Clients eingetragen

Möglicher Weise können Probleme mit der PowerShell Execution-Policy auftreten, dazu wende ich den folgenden Workaround an.

Get-Content -Path .\Fix-WSeLaunchpad-1903.ps1 | PowerShell.exe -NoProfile -

image

Update 30.05.2019:

Inzwischen ist es mir gelungen, dass Microsoft dieses Problem als Bug (Fehler) betrachtet und an einem Fix arbeitet. Wie schnell damit zu rechnen ist, kann ich nicht sagen melde mich aber wenn ich weiteres weiß.

Update 15.07.2019


Das Script, und damit der Workaround funktionieren mit dem WSE 2016 und dem WSE 2012R2, dass mag im Blog nicht richtig rüber gekommen sein. Für die anderen Versionen (WSE 2011 und 2012) müsste man die Registry-Einträge des Connectors vergleichen.

Update 21.07.2019


Ich hatte nun die Gelegenheit Windows 10 Clients an einem SBE 2012 (ohne R2) um zu stellen und muss gestehen, dass das Script hier definitiv nicht funktioniert. Der Clientconnector dort verwendet wohl andere Einträge in der Registry als unter Windows Server 2012R2/2016.

Update 18.11.2019


Mit dem Update auf Windows 10 1909 gibt es keine Probleme, dass liegt an der von Microsoft geänderten Bereitstellung. Dazu werden vornehmlich nur Features freigeschaltet, die schon in früheren Versionen vorhanden waren.

Update 11.12.2019


Wird ein ISO mit Windows 10 1909 für einen Upgrade, zum Beispiel von Windows 7 auf Windows 10 verwendet. Schlägt der Bug wieder zu und das bisherige Script funktioniert leider nicht. Darum habe ich eine kleine Änderung durchgeführt und eine Version erstellt (steht nun auch in der History), die mit 1903 und neuer funktioniert.

Update 15.05.2020

Auch mit Windows 10 2004 tritt dieses Problem auf und kann über das Script behoben werden. Ich habe an diesem eine Reihe kleinerer Korrekturen durchgeführt und hier zum Download bereitgestellt.

Update 23.10.2020

Seit dem letzten Jahr, oder denken wir in Updates, seit Windows 10 Version 1909, liefert Microsoft das Herbstupdate als normales Windows Update aus, dass Features die im Verlauf der letzten Monate durch Updates (in 2004) installiert wurden aktiviert. Damit funktioniert das Update auf diesem Weg ohne Probleme und das Script ist nicht notwendig. Erfolgt aber ein Upgrade, zum Beispiel der Version 1909, durch das Windows 10 20H2 ISO, kann das Script im Anschluss den Connector reparieren.

Update 05.06.2021

Mit dem Windows 10 21H1 Update funktioniert das Script in der aktuellen Version ohne Änderungen. Wird das Update über den WSUS oder Windows Update installiert, dann funktioniert der Windows Essentials Connector ohne Probleme und das Script ist nicht notwendig. Erfolgt das Update hingegen über eine ISO Datei, die es als Download bei Microsoft gibt, kann der Essential Connector im Anschuss über das Script repariert werden.

Enjoy it, b!

Auslesen der Seriennummer einer SSD mit PowerShell

Nachdem ich in ein Notebook eine neue SSD eingebaut hatte und das Gerät auch schon zuverlässig seinen Dienst tat, fiel mir auf das ich mir die Seriennummer nicht notiert hatte.

Wenn man nochmals, z.B. über die Fernwartung oder RDP Zugriff auf das Gerät erhält kann man die Seriennummer über PowerShell und das WMI auslesen.

# Auslesen der Seriennummer
Get-WmiObject -Class Win32_PhysicalMedia | Format-List Tag, Serialnumber

image

PowerShell braucht dazu nicht einmal mit administrativen Rechten gestartet werden.

Enjoy it, b!

Windows 10 21H1 verfügbar

Hallo zusammen,

für die Besitzer eine Visual Studio Subscription steht Windows 10 21H1 zum Download bereit.

image

Darüber hinaus bietet Microsoft das Windows 10 May 2021 Update, ebenfalls zum Download über seine Webseite an:

https://www.microsoft.com/de-de/software-download/windows10

image

Wer das ISO möchte, dem sei dieser Blog eine Hilfe. Alternativ kann man aber den Microsoft Edge Browser ebenfalls in den Entwicklermodus schalten und damit ebenfalls das ISO herunterladen.

Update 19.05.2021
Zusätzlich zu den ISO-Dateien liefert auch der Windows Update Service und Microsoft Update 21H1 als enablement package aus.

https://support.microsoft.com/en-us/topic/kb5000736-featured-update-to-windows-10-version-21h1-by-using-an-enablement-package-75a01e67-3b5f-4677-8efe-42852e41c7cf

Enjoy it, b!

Windows Update Error 0x80080005

Im Verlauf der letzten Update-Installation, hatte ich einige (drei) Windows Server 2016 die entweder die Updates nicht herunterladen oder sie im Anschluss nicht installieren wollten.

Die Installation blieb dabei bei einem Prozentwert (häufig 9 und 3%) stehen, oder der Download dauerte Stunden!

Ein manueller Versuch die Updates zu installieren endete mit einem 0x80080005 und der Windows Troubleshooter war ebenfalls nicht in der Lage einen von ihm erkannten Fehler im Windows Update zu beheben. Vielleicht habe ich mit 3 Stunden auch nicht lange genug gewartet, aber letztendlich musste eine funktionierende Lösung her.

Das Problem welches hier zu Grunde liegt, ist eine Korruption der Datenbank von Windows Update. Eine mögliche Lösung ist, dass man diese oder genauer gesagt den Ordner in dem diese liegt löscht. Damit geht aber die Option verloren, alte Updates zu entfernen.

Grundlagen

Die Lösung an sich ist recht einfach, den im Betriebssystem müssen lediglich zwei Ordner gelöscht werden:

# Löschen des Ordners SoftwareDistribution
%WINDIR%\SoftwareDistribution
# Löschen des Ordners Catroot2
%WINDIR%\System32\catroot2

Allerding sind die Ordner/Dateien von einer Reihe von Diensten im Zugriff und diese müssen zuerst einmal beendet werden. Darüber hinaus sind diese Dienste (Services) so konfiguriert, dass sie nicht immer laufen, sondern bei Bedarf getriggert werden. Ein simples net stop würde die laufenden Dienste beenden, was aber nicht sonderlich elegant ist.

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

Code / Script

Mit PowerShell lässt sich das auf elegantere Weise lösen, allerdings wollte ich die Prüfung ob noch Dateien im SoftwareDistribution-Verzeichnis geöffnet sind nicht zu komplex gestalten. Darum habe ich handle.exe von Sysinternals als externes Programm verwendet.

Das Script kann über diesen Link heruntergeladen werden.

image

Code [Line 14 – 19]
Im Array $Services (Line 5) werden die zu stoppenden Dienste definiert und im Anschluss erfolgt eine Abfrage ob diese auch wirklich am laufen “Running” sind und nur dann werden sie auch gestoppt.

Code [Line 22]
Handle.exe (optional kann auch handle64.exe hier verwendet werden) liefert die Information zurück, ob eine Datei (die DataStore.ebd) noch geöffnet ist. Damit hat möglicher Weise das Beenden von einem der Dienste nicht funktioniert.

Code [Line 25 – 29]
Für den Fall, dass hier noch einer der Dienste die DataStore.ebd geöffnet hat, wird dessen Prozess über Stop-Process beendet. Spätestens jetzt wurde damit die Grundlage geschaffen das Windows System im Anschluss neu zu starten.

Code [Line 32 – 33]

Die beiden Verzeichnisse SoftwareDistribution und CatRoot2 sollten sich nun ohne Probleme löschen lassen.

Code [Line 36]

Nach einem erfolgtem Neustart werden die Verzeichnisse SoftwareDistribution und CatRoot2 vom Windows Update Dienst wieder angelegt und auch die darin notwendigen Dateien neu erstellt.

Darum können wir auf den Start der Dienste verzichten, sondern überlassen diese Aufgabe dem Neustart des Betriebssystems. Ein Aufruf von Update zeigte dann auch alle notwendigen Updates an und konnte auch diese Installieren.

image

Enjoy it, b!

RSAT und Windows 10 20H2

Mit jeder neuen Version von Windows 10 erfolgt eine weitere und bessere Integration von Funktionen in die neue Benutzeroberfläche. Konnte ursprünglich über die klassische Systemsteuerung die Remote Server Administration Tools (RSAT) installiert oder aktiviert werden, so sind dazu inzwischen die folgenden Schritte notwendig. Ein Download wie bis zum Herbst 2018 ist nicht mehr notwendig, da RSAT inzwischen ein “Feature on Demand” ist.

Nach dem Öffnen der Windows-Einstellungen, wird dort die Option Apps ausgewählt.

image

Innerhalb von Apps & Features die Optionale Features auswählen.

image

Über Feature hinzufügen erscheint ein Dialog, in dem nach dem gewünschten Feature gesucht werden kann.

image

Im Falle der RSAT hier dann die gewünschten Tools auswählen. In diesem Fall waren es die Tools zur Gruppenrichtlinienverwaltung und für die Active Directory Domain Services

image

Dann auf Installieren klicken und die Installation erfolgt.

image

image

Nach dem erfolgreichen Abschluss sind die RSAT im Startmenü von Windows 10 sichtbar und können mit entsprechenden Rechten verwendet verwendet werden.

image

Enjoy it, b!

Windows 10 KB5000802 Update 03/2021

Neben den schon mehrfach publizierten Problemen mit dem März-Update (KB5000802), konnte ich auf zwei PCs ein “Hängen” des Windows Explorers feststellen.

image

Der Explorer selbst oder auch das Startmenü haben nach der Installation des Updates ihren Dienst komplett oder Teilweise eingestellt. Eine Deinstallation des Updates hat das Problem dann wieder behoben.

Da beide PCs eine ähnliche Ausstattung an Hard- und Software hatten (Lenovo L14 AMD), kann ich natürlich nicht zu 100% die Schuld bei dem Update suchen. Es könnte auch ein spezifisches Problem zwischen dieses Notebooks und dem Patch sein.

# Deinstallation ohne Neustart
wusa /uninstall /kb:5000802 /quiet /norestart

# Deinstallation mit Neustart
wusa /uninstall /kb:5000802 /quiet /forcerestart

Da der Windows Explorer nicht richtig mehr funktionierte, aber der Taskmanager noch zu starten war, habe ich von diesem aus eine cmd.exe oder PowerShell.exe mit Administratoren-Rechten gestartet um den Befehl oben auszuführen.

Enjoy it, b!

WinDbg, wie man in einem Dump den Computernamen findet

Vor einiger Zeit war ich damit beschäftigt einige Dumps zu analysieren um nach einem Fehler zu suchen. Dabei hätte mich brennend interessiert auf welchem Computer der Dump geschrieben wurde.

Bis zu Windows 10 war das auch nicht so schwer herauszubekommen, aber Microsoft hat hier etwas geändert. Nach einigem Suchen im Netz bin ich dann auf die folgende Lösung gestoßen, die nebenher noch die Domain/Workgroup, sowie das Betriebssystem ermittelt.

In WinDbg muss dazu der folgende Aufruf erfolgen:
r @$t0 = @@masm(mrxsmb!SmbCeContext); dx (nt!_UNICODE_STRING[4])(@$t0)

# r @$t0 = @@masm(mrxsmb!SmbCeContext); dx (nt!_UNICODE_STRING[4])(@$t0)

2: kd> r @$t0 = @@masm(mrxsmb!SmbCeContext); dx (nt!_UNICODE_STRING[4])(@$t0) (nt!_UNICODE_STRING[4])(@$t0) [Type: _UNICODE_STRING [4]] [0] : "Workgroup" [Type: _UNICODE_STRING] [1] : "NB-LP1-1" [Type: _UNICODE_STRING] [2] : "Windows 10 Enterprise 18363" [Type: _UNICODE_STRING] [3] : "Windows 10 Enterprise 6.3" [Type: _UNICODE_STRING]

[1] liefert dann den Computer auf dem der Dump erstellt wurde.

Enjoy it, b!

BlueScreen / Stopp, Windows 10 CSC reset

Nach dem Update auf Windows 10 Version 20H2, der Herbstversion 2020 hatte ich auf einer Reihe von Lenovo Notebooks und auf zwei Microsoft Surface Pro Tablets das Problem, dass sich im Verlauf der Anmeldung das Betriebssystem mit einem Bluescreen (BSOD, Stopp-Fehler) verabschiedete.

IMG-20201209-WA0000_ON1_Cloud

Für alle die hier nicht mehr weiterlesen wollen, könnte das Setzen des folgenden Parameters in der Registry von Windows 10 und ein damit verbundener Neustart das Problem beheben.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001

Neustart nicht vergessen Smile

Alle Interessierten dürfen gerne den Rest des Beitrags lesen.

Fehlerbild(er)

Eine Reihe mir zugesandter Screenshots die von den Anwendern mit dem Smartphone erstellt wurden, zeigten ein diffuses Fehlerbild.

Unterschiedlich war dabei immer die Fehlerursache, dabei tauchten verschiedene Komponenten des Betriebssystems auf:

  • mrxsmb20.sys (7x), mountmgr.sys (1x) und auch der volume.sys (1x)
  • Lenovo L460, L470 und T14L
  • Surface Pro 4 und Surface Pro 7

Gleich waren auf allen Windows 10 Systemen die folgenden Parameter

  • Der BSOD tauchte immer während der Anmeldung auf
  • Windows 10 Version 20H2
  • kürzlich auf die Version 20H2 aktualisiert
  • Nach dem Update lief der Computer im Netzwerk (Firma) stabil!
  • Der Computer ist Mitglied einer Domäne, aber die Anmeldung erfolgte ohne Verbindung zum Domain Controller im HomeOffice
  • Konfiguriertes OneDrive for Business

Workarounds

Eine schnelle Lösung brachte die Verwendung eines lokalen Benutzers auf den Endgeräten. Der Computer war zwar nach wie vor Mitglied der Domäne, aber von Benutzer wurde im HomeOffice ein lokales Konto verwendet. Dieses hatte ich entweder im Vorfeld schon angelegt, konnte es über Teamviewer “nachrüsten” oder der Anwender war dazu selbst in der Lage.

Damit war ein Zugang per RDP auf den eigentlichen PC innerhalb der Firma möglich und der Druck erst einmal weg.

Darüber hinaus brachte das Zurücksetzen von Windows auf die vorherige Version bei allen Surface Geräten Abhilfe. Der BSOD war verschwunden! Ich muss aber gestehen, dass ich das auf den Lenovo Notebooks nicht in Betracht ziehen wollte.

Zusammenfassend konnte das Problem schnell mit den beiden folgenden Ansätzen gelöst werden.

  1. Verwenden eines lokalen Benutzers (den ich inzwischen generell immer anlege, zusätzlich zu einem lokalen Admin) und auch einrichte (Outlook, OneDrive, …)
  2. Rückkehr auf die vorherige Version von Windows 10

Zufrieden war ich aber mit beiden Lösungen nicht. Zum einen führen lokale Benutzerprofile dazu, dass irgendwann Daten darin verschwinden und nicht mehr auf dem Server gespeichert werden. Eine Rückkehr auf die vorherige Version von Windows kann nur temporär eine Lösung sein, das nächste Update kommt bestimmt. Also musste dafür eine ordentliche Lösung gefunden werden und kein Workaround. Durch die Workarounds konnten alle Anwender zunächst einmal arbeiten.

Die eigentliche Lösung

Durch das Auftauchen von Komponenten die mit dem Speicher (Festplatte) und Cache von Windows zu tun hatten, dachte ich zuerst an einen Defekt des Notebooks. Da der BSOD aber nach der Verwendung des lokalen Benutzer-Kontos nicht mehr auftrat, konnte ich diesen Verdacht beiseitelegen und außerdem hatte ich inzwischen das Problem auf mehreren Geräten.

Geblieben waren aber der mrxsmb20.sys und das der STOPP-Fehler der generell bei einer Anmeldung ohne Domain Controller erfolgte.

Das zeigte mir auch ein Blick in den memory.dmp (PROCESS_NAME: winlogon.exe ist der Anmelde-Prozess von Windows)image

Dazu bekommen wir gleich zu Beginn der Analyse den Hinweis, dass etwas beim Zugriff auf das Dateisystem schief gegangen ist, nämlich als eine RDR (ReDirection) stattgefunden hat.

image

Das ist der Fall, wenn ein Computer sich Offline anmeldet. Inzwischen konnte ich nachvollziehen, dass die Anmeldung direkt im Firmennetzwerk ohne Probleme funktioniert und lediglich im HomeOffice der BSOD auftritt.

Im ersten Screenshot des Debuggers ist zu sehen, dass es sich um einen ExceptionCode c0000005 handelt und der Zugriff auf den Offline Cache fehl schlägt. Der entsprechende Ordner dafür liegt im Windows Verzeichnis mit dem Namen CSC.

# Windows Client Side Cache Ordner (Offline Files)

%WINDIR%\CSC

Die Berechtigungen auf diesen sind einfach gehalten und mit SYSTEM:F überschaubar. Allerdings lassen sie sich nur im passenden Kontext überprüfen. Ich verwende dazu Psexec.exe von Sysinternals, welches mit dem Parameter –s im Systemkontext gestartet werden kann.

# Start von Psexec.exe unter Local System

C:\Temp> "\Program Files (x86)\Windows Sysinternals Tools\psexec.exe" -s cmd.exe

# Kontrolle der Berechtigungen

C:\Windows> cacls csc /t

image
Nachdem die Berechtigungen richtig angezeigt wurden, erinnerte ich mich an frühere Migrationen von Dateiservern wo im Anschluss der CSC Cache Probleme gemacht hat und zurück gesetzt werden musste. Korrekter Weise dessen Datenbank und ein Upgrade von Windows 10 auf eine höhere Version könnte hier durchaus ebenfalls zu Problemen oder Inkompatibilitäten führen.

Ein Rücksetzen des CSC ist über den folgenden Registry-Eintrag möglich. Natürlich verbunden mit einem notwendigen Neustart des Computers.

image

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001

Damit war auch eine Anmeldung im HomeOffice möglich und damit die Lösung des Problem gefunden.

Alle nun folgenden Notebooks habe ich gleich im Anschluss nach dem Upgrade ebenfalls mit diesem Eintrag versehen und die CSC Datenbank gelöscht. Das Problem ist danach nicht mehr aufgetreten.

Enjoy it, b!