Windows 10 Home, Password will never expire …

Oft bekomme ich eine Home-Edition von Windows 10 in die Finger, meistens erfolgt gleich ein Upgrade auf Windows 10 Professional da eine Mitgliedschaft in einer Domäne notwendig ist. Kürzlich war es aber mal wieder soweit und dieses System sollte auf Windows 10 Home belassen werden, damit wollte auf das in diesem Blog beschriebene Script zurück greifen, um das Passwort auf nicht ablaufend zu setzen. Bei einer Passwortlänge von 16 Zeichen, halte ich diese Einstellung für vertretbar.

Gleich vorneweg, ja das Script funktioniert nach wie vor. Mir ist aber aufgefallen, dass ich zum einen weitere Parameter für das Benutzer-Konto setzen will und darüber hinaus PowerShell das doch noch viel besser machen kann  Thumbs up Dazu muss aber mindestens die Version Windows 10 1607 oder neuer im Einsatz sein. Das Script unter der Verwendung von WMIC wurde davor entwickelt.

Aufgabe

Ein Benutzer mit dem, zugegebenen Maßen kurzem Namen “kn” soll erstellt werden. Ich mache das auf Home Systemen oder auch in kleinen Netzwerken gerne da damit der Name des Windows Benutzer Profils hinreichend kurz wird und z.B. OneDrive ein paar Zeichen mehr im Pfadnamen hat. Durch das zusätzliche Setzen eines vollen Namens, erscheint dann dieser am Anmeldebildschirm.

  1. Benutzername = kn
  2. Vollständiger Name = “Karl Napf”
  3. Passwort-Ablauf = nicht ablaufend / never expires

PowerShell Befehle

Mit dem PowerShell-Befehl New-LocalUser erfolgen. Vor dem eigentlichen Befehl, besteht die Möglichkeit das Passwort vertraulich an der Eingabeaufforderung mit Read-Host einzulesen.

Alle PowerShell-Befehle mitt in einer PowerShell-Sitzung mit erhöhten Rechten ausführen.

# Einlesen des Passworts
$Password = Read-Host -AsSecureString

# Anlegen des Benutzers
New-LocalUser -Name 'kn' -FullName 'Karl Napf' -Password $Password -PasswordNeverExpires -Description 'Karl Napf, der Erfinder der Brotsuppe'

Die Kontrolle mit net user, zeigt ein zufriedenstellendes Ergebnis.

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 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!

SYSVOL-Migration von FRS auf DFSR

Microsoft empfiehlt schon seit langer Zeit die Replikation des SYSVOL von FRS (File Replication Service) auf DFSR (Distributed File Service Replication) umzustellen. Um genau zu sein, kam diese Empfehlung mit Windows Server 2003R2 🙂 .  Das ist auch sinnvoll, da DFSR stabiler arbeitet und FRS mit dem Windows Server 1709 nicht mehr unterstützt wird.

Ich habe dann eine Reihe meiner Small Business Domains durchgeschaut und noch eine gefunden in dieser FRS zur Replikation verwendet wird. Das ist immer dann der Fall, wenn von sehr alten Versionen (hier ein Windows Server 2000 basiertes Active Directory) immer wieder auf neue Versionen migriert wurde. Die Historie in dieser Domain ist:

  • Windows Server 2000
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2012R2

In Domains mit nur einem Domain Controller (DC), wie das bei dem Small Business Server oder Small Business Essentiales üblich ist, kommt es in der Regel zu fast keinen Problemen mit der Replikation. Denn es gibt nur einen DC, das bedeutet aber nicht das hier keine Replikation stattfindet, sondern dass der Server in der Regel sich selbst immer erreichen kann.

FRS oder DFSR?

Wie stellt man überhaupt fest, ob innerhalb des Active Directory (AD) mit FRS oder DFSR repliziert wird? Das kann über mehrere Möglichkeiten herausgefunden werden.

Im Ereignis-Protokoll auf einem (in einer SBS/SBE Domain auf dem einem) DC sind aktuelle Einträge vorhanden.

image

Im DFS Management wird KEINE Gruppe angzeigt, wie im folgenden Bild zu sehen ist. Darunter das Domain System Volume wenn auf DFSR umgestellt wurde.

FRS (File Replication Service)

image

DFSR (Distributed File System Replication)

image

Voraussetzungen

Damit eine Migration ohne Probleme läuft, sollten ein paar Bedingungen im Vorfeld erfüllt sein.

FRS muss fehlerfrei arbeiten, dass kann man gleich prüfen wenn man einen Blick in das Ereignisprotokoll des FRS wirft

Bei mehreren DC, erstelle ich eine Datei im NETLOGON-Verzeichnis und schaue ob diese auf den anderen DCs zeitnah auftaucht.

C:\Temp> echo "Test" > \Windows\SYSVOL\domain\scripts\test.txt

Zusätzlich muss die Domain im Domain-Mode mindestens auf Windows Server 2008 laufen.

image

Das kann mit PowerShell und Get-ADDomain geprüft werden.

# Den Befehl als Administraor in einer PowerShell-Sitzung ausführen
(Get-ADDomain).DomainMode
Windows2012R2Domain

Nun können wir die Migration starten.

Migration von FRS auf DFSR

Bevor die Migration gestartet wird mache ich, wenn nur ein einziger DC vorhanden und dieser virtualisiert ist, einen SnapShot. Darüber hinaus ist ein aktuelles Backup obligatorisch.

image

Bei einem Snapshot (oder Checkpoint) ist es wichtig, dass falls dieser in Anspruch genommen wird, alle Daten die seit dem Checkpoint erstellt wurden verloren gehen. Darum ist eine Migration des SYSVOL etwas fürs Wochenende.

Die Migration selbst erfolgt mit dem Tool dfsrmig.exe das in einer, als Administrator gestarteten CMD- oder PowerShell-Sitzung auf dem DC ausgeführt wird, der die PDC-Emulator Rolle besitzt. Bei nur einem Server / DC ist die Rollenverteilung klar, ansonsten kann diese wie folgt mit PowerShell geprüft werden.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
(Get-ADDomain).PDCEmulator
mt-sbs-1.DOMAIN.local

Wird nur Get-ADDomain verwendet, findet man den PDC-Emulator hier.

image

Die Migration selbst verläuft in vier Stufen mit dem folgenden Status von 0 … 3, die Informatik beginnt halt gerne bei 0 Smile

Status Start 0

Mit dfsrmig /setGlobalState 0 werden die Domain Controller auf Start gesetzt und die Migration kann beginnen.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 0

Die Meldung Invalid state change requested, rührt daher das auf diesem DC der Befehl schon im Vorfeld abgesetzt wurde und dieser sich schon im Status Start befindet.

image

Kontrollieren, ob alle DC sich final im Status Start befinden kann und sollte man mit dfsrmig /GetMigrationState.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /GetMigrationState

image

Bei mehreren DCs kann das schon seine Zeit dauern, letzte Woche habe ich bei zwei Servern ca. 10min gewartet bis dieser Status erreicht war. Hier ist ein wenig Geduld angebracht.

Status Prepared (Vorbereitet) 1

Mit dfsrmig /setGlobalState 1 wird nun im nächsten Schritt der DC in den Status Prepared versetzt und mit dfsrmig /GetMigrationState kann der Status wiederholt abgefragt werden.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 1

Wie im folgenden Bild zu sehen ist, benötigt auch ein einzelner DC seine Zeit. Dazu einfach einen Kaffee holen und mit dfsrmig /GetMigrationState den Status abfragen.

image

Status Redirected (Umgeleitet) 2

Mit dfsrmig /setGlobalState 2 wird nun die Phase 2 eingeleitet und alle DC in den Status Redirected gesetzt, was ebenfalls seine Zeit dauern kann.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 2

Natürlich liefert dfsrmig /GetMigrationState den aktuellen Zustand.

image

Damit ist die Phase 2 beendet und wir können uns der Phase 3 zuwenden und die Migration damit abschließen.

Status Eliminated (Entfernt) 3

Mit dfsrmig /setGlobalState 3 wird nun die Phase 3 und damit der Abschluss der Migration eingeleitet und alle DCs in den Status Eliminated gesetzt.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 3

Wie schon vorher liefert dfsrmig /GetMigrationState den Zustand und Status der Migration, im folgenden Bild waren wir nach gut 2min fertig.

image

So nun sind wir fertig, alle vier Schritte / Phasen sind durch.

Wie kontrollieren wir nun, ob alles sauber läuft?

Vertrauen ist gut, Kontrolle ist besser

Im DFS Management wird nun das Domain System Volume angezeigt und man kann es auch als Replikationsgruppe hinzufügen.

image

Dort sehen wir auch den migrierten SYSVOL-Ordner.

image

Zusätzlich verabschiedet sich der FRS mit einem “letzten” Eintrag im Ereignisprotokoll.

image

Im DFS Replication Ereignisprotokoll finden wir ebenfalls einen Eintrag, dass nun mit DFSR repliziert wird.

image

Bei mehr als einem Domain Controller, erstelle ich immer eine Datei im NETLOGON-Verzeichnis und schaue ob diese repliziert wird. Das Verzeichnis heißt ja nun auch nicht mehr SYSVOL, sondern SYSVOL_DFSR.

image

Wird nun ein weiterer DC hinzugefügt, dann verwendet dieser wie vor das Verzeichnis SYSVOL.

image

Die beiden ersten Server wurden „migriert” und der letzte in der Liste (blau umrandet) wurde nach der Migration hinzugefügt.

Enjoy it, b!

WSUS zusammen mit der WID auf Laufwerk D

Fügt man den Windows Server Update Service (WSUS) auf einem Windows Server (2016 oder 2019) hinzu, dann werden weitere für die Rolle notwendigen Dienste und Funktionen hinzugefügt.

image

Darunter auch die Windows Internal Database (WID), als SQL-Server für die Bereitstellung der WSUS-Datenbank.

image

Die WID ist nur zur Verwendung von Windows eigenen Diensten, wie dem WSUS gedacht und nicht zur Bereitstellung von Datenbanken für externe Anwendungen.

Neben dieser Einschränkung hat die WID einen großen Vorteil: Im Gegensatz zur kostenlosen SQL Server Express Edition besitzt sie keine Begrenzung der maximalen Größe einer Datenbank auf 10GB (bis zum SQL Server 2008R2 war das Limit sogar nur 4GB).

Wird der WSUS über PowerShell hinzugefügt, erfolgt ebenfalls die Installation und Verwendung der WID.

image

Hier die Installation über PowerShell:

Install-WindowsFeature UpdateServices -Restart -IncludeManagementTools -Restart

Wird die WID mit dem WSUS verwendet, dann unterliegt dessen Datenbank, die SUSDB, nicht der 10GB Begrenzung wie das bei der Verwendung der SQL Server Express Edition der Fall ist.

Das ist ein Vorteil, da die SUSDB gerne mal die 10GB Grenze, vor allem wenn die Wartung vernachlässigt wird, übersteigt.

Der Haken an der Sache ist, dass die WID nach ihrer Installation auf dem Laufwerk C liegt und dort will ich sie nicht haben.

Umkonfigurieren der WID auf ein anderes Laufwerk

Die WID muss daher nicht auf Laufwerk C verbleiben, sondern kann auf ein anderes Laufwerk gelegt werden. Dazu sind die folgenden Tools und Schritte notwendig.

  • Nachdem der WSUS und damit die WID hinzugefügt wurde, aber noch bevor eine Konfiguration des WSUS erfolgt, sollte die WID auf ein passendes Laufwerk gelegt werden. Ich nehme dazu gerne Laufwerk D, dass ich in Form einer 256GB großen Platte bereitstelle
  • Damit die WID auf Laufwerk D verschoben werden kann, empfiehlt es sich das ohnehin für die Wartung der SUSDB hilfreiche SQL Server Management Studio zu installieren
  • Nicht notwendig, aber für mich immer praktisch ist Notepad++ oder Visual Studio Code als Editor auf dem Server

Damit die WID Laufwerk D: verwendet, sind die folgenden Schritte notwendig.

Start der Windows Internal Database über die Services oder PowerShell

image

image

# Starten der WID
Start-Service -Name 'MSSQL$MICROSOFT##WID'
# Ändern des StartupTypes auf Automatic (delayed)
Set-Service -Name 'MSSQL$MICROSOFT##WID' -StartupType Automatic

Nun ist es möglich, mit dem folgenden String eine Verbindung zur WID über das SQL Server Management Studio (SSMS) herzustellen.

np:\\.\pipe\MICROSOFT##WID\tsql\query

Das SSMS muss dazu mit administrativen Rechten (rechte Maustaste Run as Administrator) gestartet worden sein.

image

Der weitere Ablauf ergibt sich aus den folgenden Schritten.

  • Stoppen der WID, durch das SSMS, PowerShell oder auch den Services Manager
  • Anlegen des Data und Log Verzeichnisses auf Laufwerk D (als Administrator)

image

  • Verschieben des Inhalts von C:\Windows\wid\data und C:\Windows\wid\log nach Laufwerk D:

image

Verschieben von Data und Log auf Laufwerk D
move C:\Windows\wid\data\* 'D:\Microsoft SQL Server\WID\Data\'
move C:\Windows\wid\log\* 'D:\Microsoft SQL Server\WID\Log\'
  • Ändern der folgenden drei Einträge in der Registry, für die Lokation der master. mdf, master.ldf und error.log Dateien

image

  • Der neue Pfad geht auf Laufwerk D mit den Unterverzeichnissen

image

  • Danach folgt die Berechtigung des WID Service Accounts auf die Verzeichnisse auf Laufwerk D … der Einfachheit nehme ich hier immer das WID-Verzeichnis selbst.

image

NT SERVICE\MSSQL$MICROSOFT##WID 
  • Danach kann die WID gestartet werden und die Verbindung über das SSMS klappt auch ohne Probleme.

image

Die Installation des WSUS erfolgt über den Post-Configuration Task oder kann über den folgenden Aufruf erfolgen.

# wsusutil.exe liegt im Verzeichnis C:\Program Files\Update Services\Tools
.\wsusutil.exe postinstall SQL_INSTANCE_NAME="LOCALHOST" CONTENT_DIR=D:\WSUS

image

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!

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!