Mit dem Windows 11 Update KB5009566 keine L2TP VPN Verbindungen mehr möglich

Im Moment bin ich über das folgende Problem gestolpert. Nach der Installation von KB5009566 unter Windows 11 schlägt der Aufbau einer VPN-Verbindung mit L2TP fehl.

"The L2TP connection attempt failed because the security layer encountered a 
processing error during initial negotiations with the remote computer"

Eine Deinstallation des Updates bringt die verlorene Funktionalität zurück, diese kann über die Eingabeaufforderung (als Admin, also elevated / mit erhöhten Rechten) mit dem folgenden Befehl durchgeführt werden.

# Deinstallieren von KB5009566
wusa /uninstall /kb:5009566

Mal schauen, wann und wie Microsoft hier reagiert und hoffentlich nachbessert.

Update: Unter Windows 10 ist es wohl das Update KB5009543.

Enjoy it, b!

SBE: Howto fix Client Computer Backup

Die Annahme, dass das Laufwerk mit den Client Computer Backups auf dem SBE (Windows Server 2012R2 oder 2016 mit der Small Business Essentials Role) nicht wichtig ist, hat sich in meinem letzten Support-Fall als nicht korrekt herausgestellt.

Die Geschichte hat natürlich einen Anfang. Wird eine hinreichend große Anzahl von Clients (PCs im SBE Netzwerk) gesichert, kann das Laufwerk das den Sicherungsordner Client Computer Backup bereitstellt schon mal auf 1TB anwachsen. Der Kunde (oder dessen Administrator) dachte nun, dass er einigen Platz sparen kann, wenn er das Laufwerk nicht sichert und auch nicht in die Hyper-V Replikation aufnimmt. Durch einen Defekt der Server-Hardware musste auf einen anderen Hyper-V Host umgeschaltet werden und der SBE “erwachte” aus der Replika ohne die Client Computer Backups, beziehungsweise ohne das passende Laufwerk.

Gleiches kann natürlich auch passieren, wenn das Laufwerk versehentlich gelöscht wird oder auf einem anderen Wege kaputt geht.

Die Ausgangssituation

Vollständiger Verlust der Client Computer Backups mit samt des bereitstellenden Laufwerks. Damit werden die Clients nicht mehr gesichert und der SBE zeigt eine Reihe von Fehlermeldungen im Dashboard und auch in der Ereignisanzeige.

image

Nun stellt sich die Frage, wie diese Funktionalität wieder hergestellt werden kann und ob sich das überhaupt reparieren lässt?

Die Wiederherstellung der Client Computer Backup Funktionalität

Damit das nochmals klar wird, es geht hier nicht darum die Backups selbst wiederherzustellen, sondern die Funktionalität des SBE damit dieser wieder Backups der Clients anfertigen kann.

In einem ersten Schritt wird dem SBE wieder ein passendes Laufwerk bereitgestellt. Das geschieht in virtuellen Umgebungen durch Anhängen einer neuen VHD oder auf einem physikalischen Server durch Einbau einer neuen Platte.

Das neue Laufwerk erscheint unter dem Laufwerksbuchstaben I und wird mit NTFS formatiert. Nun dachte ich, dass es ausreichen würde die Funktion Repair backups / Repair now zu verwenden und der Rest passiert dazu im Hintergrund, dass war aber eine falsche Annahme. Es ist nämlich so, dass die Clients durch die Installation des Client Connectors in die Datenbank des Client Computer Backups eingetragen werden. Die existiert aber nicht mehr und muss darum neu angelegt und danach noch die Client Computer zugeordnet werden.

image

Ein Repair now … meldet zwar Erfolg, aber funktionieren tut hinterher das Client Computer Backup nicht.

Eine Reparatur erfolgt mit den folgenden Schritten:

Bereitstellen eines hinreichend großen Laufwerks, das einen Bezeichner besitzt und mit NTFS formatiert ist.

# Stopping Windows Server Essentials Computer Backup
Stop-Service -Name WseComputerBackupSvc -Force
# Create missing directories
New-Item -Type Directory -Path 'I:\ServerFolders\Client Computer Backups\'
# Starting Windows Server Essentials Computer Backup
Start-Service -Name WseComputerBackupSvc

image

Eigentlich legt der Windows Server Essentials Computer Backup Service beim Start, falls noch nicht vorhanden, seine Datenbank an. Ich habe aber schon gesehen, dass das nicht passiert ist. Darum lohnt sich nochmals das Ausführen der Reparatur (Repair now …)

image

Nun sollten die drei folgenden Dateien im Verzeichnis vorhanden sein.

image

  • Commit.dat
  • ConsistencyInfo.cc
  • DatabaseInfo.dat

Seitens des Servers ist nun alles eingerichtet, nun müssen wir noch die Clients zurückbringen.

Das habe ich bisher nur über eine De-Installation und Neu-Installation des Client Connectors hinbekommen. Zwischen den beiden Schritten, ist kein Neustart notwendig. Einfach den Connector deinstallieren und im Anschluss sofort wieder installieren und fertig.

image

Danach läuft das Backup wieder ohne Probleme.

image

Die drei oben genannten Dateien nehme ich darum auch in die Datensicherung auf.

image

Damit spart man sich zumindest die Arbeitsschritte auf dem Server.

Enjoy it, b!

Windows 11 | Stop Code PAGE_FAULT_IN_NONPAGED_AREA (50)

Heute Morgen hat sich mein Arbeitspferd, ein Lenovo P1, mit einem BSOD (Blue Screen of Death) verabschiedend.

Der STOP-Code lautete PAGE_FAULT_IN_NONPAGED_AREA und deutete gefühlt auf ein Treiber Problem hin. Da Windows den Memory-Dump (MEMORY.DMP) sauber geschrieben hat, war mein erster Weg sich die Sache einmal mit WinDBG (den Windows Debugger) anzuschauen.

image

WinDBG identifiziert hier schnell den Nvidia-Treiber als Verursacher.

nvlddmkm.sys

image

Und auch der Stack zeigt den Treiber, kurz vor der Exception. Diesen (also den Stack) liest man übrigens von unten nach oben.

image

Das Problem konnte ich durch ein Update des Nvidia-Treibers lösen. Installiert war die folgende Version.

image

Die Nvidia Homepage bietet dagegen schon einen neueren WHQL zertifizierten Treiber an.

image

Nach dem Update zeigt auch der Geräte Manager eine neuere Version an.

image

Vielen Dank für das Vorbeischauen.

!analyze –b Smile

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!

LANCOM – Dead Peer Connection Timeout

Nach einem Abbruch einer VPN-Verbindung eines Windows Clients, konnten mit einem LANCOM Router keine VPN-Verbindungen mehr aufgebaut werden. Um eine Lösung für dieses Problem zu finden, war ich mit dem Hersteller mehrere Wochen in Kontakt. Starten möchte ich aber mit dem Setup der Umgebung.

Ausgangsituation

LANCOM 1781VA Router mit mehreren VPN-Verbindungen. Zwei davon sind permanente VPN-Tunnels zu Partnern und Standorten, dazu existiert für 5 Clients die Möglichkeit sich über VPN in das Firmennetzwerk einzuwählen.

Die folgende Abbildung zeigt aktuell drei Verbindungen mit den folgenden Funktionen.

image

  • HI-VPN stellt eine von Router ausgehende Verbindung zu einem Partner-Netzwerk dar
  • LC-1781VAW ist die eingehende Verbindung einer Zweigstelle
  • XX-NBK-<?>-VPN die Einwahl der Mitarbeiter aus dem Homeoffice durch den LANCOM Advanced VPN Client

Problem

Wurde von einem der Mitarbeiter im Homeoffice die Verbindung nicht ordentlich getrennt, sondern das Notebook nur in den Sleepmodus gesetzt. Dann zeigte nach ungefähr 2min das VPN auf dem LANCOM 1781VA Router einen Fehler mit einem “Dead Peer Connection Timeout”.

Keine der vorhandenen VPN-Verbindungen (sowohl Partner als auch Zweigstelle) konnte danach aufgebaut werden.

Beheben ließ sich dieses Problem nur, durch einen Neustart des Routers. Dieser funktionierte dann wieder problemlos, bis der nächste Mitarbeiter das Notebook schlafen legte.

Lösung

Der Verursacher des Problems war,  das sowohl im IDS und im DoS die Option Lock target port aktiviert war. Anscheinend erkennt der LANCOM Router den Abbruch der Verbindung als IDS/DoS und sperrt daraufhin die Ports welche für das VPN notwendig sind.

image

image

Nachdem die Option Lock target port deaktiviert wurde, läuft der Router wieder ohne Probleme wie ein Schweizer-Uhrwerk.

Enjoy it, b!

Windows SBE remotewebaccess.com Update schlägt fehlt

Mit dem Beginn dieser Woche (KW11/2021) waren einige meiner auf Windows Server 2012R2 basierenden Small Business Essential Server nicht mehr in der Lage ihre für den Anywhere-Access notwendige Sub-Domain unter remotewebaccess.com zu aktualisieren. Genau genommen betrifft das Problem alle SBE, aber manche haben eine statische IP-Adresse und was sich nicht ändert, muss man auch nicht aktualisieren. Die Problem-Kandidaten waren also Kunden (Telekom- und 1&1 ) die täglich eine neue dynamische IPv4-Adresse vom Provider bekommen.
image

Damit klappte natürlich auch der Zugang auf https://sbe.remotewebaccess.com/remote nicht mehr. Da hinter dem Zugang über remotewebaccess.com ein Zertifikat steckt, hat auch ein Zugang über “nur” die IP nicht gut funktioniert.

Das Fehlerbild war dubios, bis ich die Idee hatte das möglicher Weise der auf dem SBE laufende Update Client ein Problem mit der Verschlüsselung haben könnte. Stichwort TLS 1.0, TLS 1.1 Deaktivierung durch Microsoft.

Wenn man einen Blick auf die Release Documentation for Windows Server Essentials wirft, findet man zum eine Aktualisierung von 10.03.2021 …

image

… und dazu den folgenden Absatz.

image

Auch der Windows Server Essentials soll TLS 1.2 nutzen, Nach diesem Absatz dachte ich, OK – das ist es nicht, der Windows Server 2012R2 und neuer verwenden automatisch TLS.

image

Diese Aussage trifft zwar auf den Windows Server selbst zu, aber für das .Net Framework war dennoch ein wenig Nacharbeit notwendig und damit war ich auch auf die Lösung des Problems gestoßen.

Für beide auf dem Server installierten .Net Versionen (v2.0.50727 und v4.0.30319) mussten die folgenden Einträge in die Registry zusätzlich eingetragen werden.

# 64-bit OS
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
# 32-bit Applications running on 64-bit OS
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Mit PowerShell geht das sehr einfach die Befehle müssen als Administrator in PowerShell (elevated Session) ausgeführt werden.

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

Danach noch den Server neu starten (Restart-Computer).

Update 20.03.2021
Für den Windows Server 2012 (OHNE R2) sind neben den oben beschriebenen Einträgen noch die folgenden Keys in der Registry zu setzen

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value '0xAA0' -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value '0xAA0' -PropertyType DWORD -Force

Microsoft bietet hier auch ein eigene Lösung an um den Fix zu installieren. Dazu gibt es weitere Infos hier.

Update 22.03.2021
Das Problem tritt natürlich auch auf dem Windows Server 2016 SBE auf, und kann mit den gleichen Einträgen in der Registry wie für Windows Server 2012R2 behoben werden.

image

Die Abbildung oben zeigt den Fehler des Update-Mechanismus auch im Windows Eventlog unter Microsoft-Windows-ServerEssentials/Admin.

Enjoy it, b!

SQL Server Configuration Manager [0x80041010]

Nachdem ich auf einem Microsoft SQL Server eine Instanz deinstalliert hatte, wurde Start des SQL Server Configuration Manager, mit der folgenden Fehlermeldung quittiert und ich eine Konfiguration war nicht mehr möglich.

image

Microsoft selbst beschreibt in diesem Artikel sehr gut, wie das Problem gelöst werden kann. Da bei mir die Datei sqlmgmproviderxpsp2up.mof  fehlte, kam ich um eine Reparatur des SQL Server nicht umhin.

image

Dazu ist im übrigen das SQL Server Installationsmedium notwendig (bei mir lag das ISO-File noch im Verzeichnis c:\temp\sql2019).

Nach der Reparatur und einem Neustart, funktioniert auch der Sql Server Configuration Manager wieder.

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!

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!

Windows 10 Upgrade schlägt fehl

Beim Upgrade von zwei Windows 10 PCs wurde ich von der folgenden Fehlermeldung überrascht.

image

Windows kann mithilfe von Setup nicht auf einem USB-Speicherstick installiert werden.

Windows war der Meinung, dass die interne Festplatte (eine SSD) ein USB-Stick wäre. Lösen lässt sich dieses Problem, indem in der Windows Registry der folgende Wert auf 0 gesetzt wird.

image

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
PortableOperatingSystem = 0

Damit konnte Windows ohne Probleme auf die gerade aktuelle Version 20H2 aktualisiert werden.

Enjoy it, b!