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