Hyper-V failed to enable replication

Diese Meldung deutet auf ein Problem mit der Version der Virtuellen Maschine (VM) beim Einrichten einer Hyper-V Replica hin.

image

 

Was ist denn die Version einer VM genau?

Mit Windows Server 2012R2 wurden VMs der Generation 2 ermöglicht, eine Version der VMs trat aber bisher explizit nicht in Erscheinung, obwohl sie schon vorhanden war. Erst seit Windows Server 2016 ist es möglich die Version der VM im Hyper-V Manager als Spalte anzeigen zu lassen und darüber hinaus beim Erstellen der VM konkret die Version vor zu geben.

An einer Version, hängen Features von Hyper-V wie zum Beispiel die Möglichkeit eine VM in den Hibernation-Mode zu schicken. Daher muss ein Hyper-V Host die Version einer VM, die auf ihm ausgeführt werden soll auch unterstützen. Welche Version das ist, kann mit dem PowerShell-Befehl Get-VMHostSupportedVersion, ab Windows Server 2016 herausgefunden werden.

image

Get-VMHostSupportedVersion

Ob die Version in der Hyper-V MMC (Hyper-V Manager) angezeigt wird oder nicht, hängt vom verbundenen Hyper-V Host und nicht von der Version des Hyper-V Managers ab. Die folgende Abbildung zeigt das Hyper-V Management unter Windows 10 Build 1903 (neuer geht es aktuell nicht mehr) und einen dahinter liegenden Microsoft Hyper-V Server 2012R2.

image

Die nächste Abbildung das gleiche Hyper-V Management und einen damit verbunden Hyper-V Server 2016, inklusive der Möglichkeit die Configuration Version an zu zeigen.

image

Ähnlich verhält es sich in PowerShell, beim Anlegen einer VM. Das für Windows Server 2012R2 und älter zu verwende Hyper-V PowerShell-Modul, unterstützt den Parameter Version nicht, die VM muss also ohne diesen erstellt werden, bekommt aber trotzdem eine Version zugewiesen.

image

image

# Entladen des Hyper-V Modules
Remove-Module Hyper-V

# Import des aktuellen Hyper-V Modules
Import-Module Hyper-V

# Erstellen einer VM der Generation 2 mit Version 5.0
New-VM -ComputerName skye.whisky.local -VMName Linux -Generation "2.0" -Version "5.0"

Legt man nun auf einem Hyper-V Server 2016 oder neuer eine VM mit der Version 5.0 an, so ist die “kompatibel” mit Hyper-V 2012R2 und es kann auch eine Hyper-V Replica eingerichtet werden.

image

Import-Module Hyper-V -RequiredVersion 1.1

Get-VM -ComputerName nevis.whisky.local -VMName "_caolila.whisky.local" | fl Name, Generation, Version

Ein Version-Downgrade ist zum heutigen Stand nicht möglich, hier ist also Vorsicht geboten.

Enjoy it, b!

WinDBG aus dem Microsoft Store

Schon vor knapp 2 Jahren hatte ich auf die Verfügbarkeit des Windows Debuggers (als Preview) im Microsoft Store hingewiesen.

image

Der Windows Debugger ist dort immer noch zu haben uns als Preview vom 28.08.2017 ausgewiesen, was aber nicht korrekt ist. Die App hat im Lauf der Zeit einige Updates erfahren und wird von Microsoft auch offiziell im Download gelistet.

An der Installation über den Microsoft Store schätze ich vor allen die Geschwindigkeit, da nicht das komplette SDK besorgt werden muss.

Die Symbole lassen sich dann übrigens wie gewohnt konfigurieren.

image

image

Der zu verwendende Symbolpfad kann entweder von hier:

http://msdl.microsoft.com/download/symbols

oder von der Microsoft Webseite verwendet werden.

Happy Debugging, b!

Event 4121, Data Deduplication

Auf einem Windows Server 2012R2 ließ sich die Konfiguration für die Deduplizierung der Volumes nicht mehr starten, ebenfalls zeigte der Servermanager keine Informationen über deren Zustand an. Im Eventlog (Application and Services/Microsoft/Windows//Deduplication/Operational) waren viele Einträge mit dem Event 4121 zu sehen.

image

Alle Einträge mit dem Event 4121 deuteten auf eine korruptes XML-Datei im Laufwerk D: hin:

D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml

Zumindest ich habe im Web keinen wirklich guten Vorschlag zur Lösung des Problems gefunden. Maßnahmen wir die Deinstallation der Deduplizierung, brachten ebenso wenig Erfolg wie ein Chkdsk auf dem Volume.

Das Problem habe ich nach einigem Überlegen wie folgt gelöst.

Analyse der dedupConfig.02.xml

Dazu habe ich die XML-Datei nach C:\Temp kopiert, da aber auf die Datei nur der SYSTEM Account Zugriff hat musste ich dazu eine cmd.exe mit PSEXEC starten.

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

Damit konnte ich die XML-Datei sehen und auch kopieren.

dir "D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml" /ah

xcopy /h  "D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml" C:\Temp

Im Verzeichnis C:\Temp habe ich erst einmal alle Attribute entfernt und versucht die Datei mit NotePad++ zu öffnen,

attrib -s -h -a dedupConfig.02.xml

Die Datei ließ sich mit keinem Editor öffnen, bzw. in einer sinnvollen Form lesen. Die Idee, wie das Ganze nun in den Griff zu bekommen sei, war von einem anderen Server (und hier ebenfalls von Laufwerk D die XML zu kopieren.

Dazu war der Ablauf wie folgt.

  1. Kopieren der neuen dedupConfig.02.xml nach C:\Temp (auf dem Quellsystem ist dazu ebenfalls eine cmd.exe unter dem SYSTEM Account notwendig, also wieder PSEXEC verwenden
  2. Setzen des Data Deduplication Service auf deaktiviert (im Service-Manager)
  3. Kopieren der Datei nach D:\System …
  4. Setzen des Data Deduplication Service auf manuell und starten des Deduplication Settings Wizards im Servermanager – Fertig!

image

Danach war wieder eine Konfiguration der Einstellungen möglich und es wurde sofort wieder der korrekte Status der Deduplizierung angezeigt.

Enjoy it, b!

Rücksetzen des lokalen Administrators

Im Blog vom 15.05.2019 (Death man walking) hatte ich die Deaktivierung des lokalen Administrators empfohlen. Vergisst man nun einen alternativen Administrator an zu legen oder hat dessen Passwort beziehungsweise des lokalen Admins vergessen, kann der Zugriff auf das System nur noch über einen Umweg erfolgen.

Was wollen wir eigentlich machen?

Um den Administrator durch die Hintertür zu öffnen, verschaffen wir uns über eine Sitzung der CMD.EXE Zugriff, welche unter dem Local System Account des Betriebssystems läuft und über den Anmeldebildschirm (LogonUI.exe) gestartet wird.

Der Anmeldebildschirm (LogonUi.exe) bietet nämlich die Möglichkeit ein Hilfsprogramm, den Utility-Manager (Utilman.exe) über ein Icon zu starten.

image

Ersetzt man nun die Utilman.exe durch die CMD.EXE, öffnet sich anstatt des Utility-Managers die Eingabeaufforderung. Doch was ist dafür notwendig?

Hilfsmittel und Voraussetzungen

Als Hilfsmittel verwenden wir ein Windows 10 Installationsmedium, dass entweder von einer DVD, USB-Stick oder im Falle einer VM also ISO zum Start des Rechners / Systems verwendet wird.

Die Info, wie wir an ein Windows 10 ISO kommen habe ich in diesem Blog beschrieben.

Dazu muss unter Umständen im BIOS des Rechners die Startreihenfolge geändert werden, so das vom Windows 10 Installationsmedium gestartet werden kann. Einige Motherboards und Notebooks erlauben hier auch durch Drücken einer Taste, dass Startmedium aus zu wählen. Im Falle einer VM unter Hyper-V sieht das dann wie folgt aus.

clip_image004

Der Ablauf

Nach einem erfolgreichen Start erscheint auf dem Bildschirm der folgende Dialog, an dem wir lediglich das passende Layout für die Tastatur auswählen (man muss sich das Leben nicht immer schwerer machen, als es ist).

clip_image006

Nach einem Klick auf Next / Weiter öffnen wir im folgenden Dialog mit SHIFT+F10 eine Eingabeaufforderung. Es soll ja gar keine Installation erfolgen, sondern wir benötigen Zugriff auf das Experten-GUI (die Eingabeaufforderung, CMD.EXE) Smile

clip_image008

Typischer Weise liegt das Betriebssystem auf Laufwerk C, insofern keine vorhandenen USB-Sticks, externe Festplatten oder andere Geräte es auf einen anderen Bezeichner verschoben haben. Dann gilt es einfach danach zu suchen.

Das Ersetzen der Utilman.exe erfolgt mit den nun folgenden Schritten:

  1. Wechsel in das Laufwerk C: nach \Windows\System32
  2. Umbenennen von Utilman.exe nach Utilman.bak
  3. Kopieren der CMD.EXE nach Utilman.exe
  4. Rechner neu starten (und davor noch das Installationsmedium entfernen), dass kann auch mit shutdown /r erfolgen.

Die Abbildung unten zeigt zusammenfassend alle Schritte.

image

Nach dem erfolgten Neustart, erscheint bei einem Klick auf das Ease of Access Symbol rechts unten die Eingabeaufforderung. Von der wir schon aus dem Titel des Fensters sehen können das es sich um die als Utilman.exe umbenannte CMD.EXE handelt.

clip_image012

Die Eingabeaufforderung läuft wiederum unter dem Local System Account und hat damit das Recht den lokalen Administrator zu bearbeiten.

image

Falls der Administrator deaktiviert ist, kann dennoch das Passwort gesetzt und anschließend dieser aktiviert werden.

net user administrator 1n$Höllen?Schwieriges!Passw0rd
net user administrator /active:yes

Das sieht dann nochmals wie folgt aus …

clip_image014

Zum Schluss gilt es dann nochmals die Sache mit der umbenannten Utilman.exe wieder auf zu räumen.

Aufräumen

Nach erfolgter Anmeldung, als Administrator in das Verzeichnis C:\Windows\System32 wechseln und dort die Utilman.bak nach Utilman.exe kopieren oder umbenennen.

copy /b /v utilman.bak utilman.exe

Wichtig für das Umbenennen ist, dass Windows dazu neu gestartet wird. Da die Utilman.exe sonst im Zugriff ist.

Enjoy it, b!

Das Windows Server Essentials Dashboard lässt sich nicht öffnen

Für einen neu angelegten Administrator war es nicht möglich das Dashboard des Windows Server Essentials 2016 zu öffnen. Der Versuch wurde mit der folgenden Fehlermeldung quittiert. Das folgende Bild zeigt die Meldung unter 2016 …

image

… oder wie im nächsten Bild zu sehen ist, die des Windows Server Essentials 2012R2.

image

Für die Fehleranalyse von Essentials spezifischen Funktionen sind die Logfiles im folgenden Verzeichnis ein guter Startpunkt:

C:\ProgramData\Microsoft\Windows Server\Logs

Dort befinden sich eine Reihe von Dashboard*.log Dateien, welche Informationen zur Ausführung des Dashboards gespeichert haben.

---------------------------------------------------------
[5016] 190312.115710.7435: General: Initializing...C:\Windows\system32\Essentials\Dashboard.exe
[5016] 190312.115711.4899: General: Failed to open ADTestHook registry key.
[5016] 190312.115711.4899: General: Failed to open ADTestHook registry key.
[6880] 190312.115711.6419: General: Color branding started
[6880] 190312.115711.6419: General: Processing Microsoft default SKU branding colors XML
[6880] 190312.115711.8369: General: Branding colors XML parsing started
[6880] 190312.115711.8659: General: Branding colors XML parsing ended
[6880] 190312.115711.8659: General: Looking for OEM branding colors XML
[6880] 190312.115711.8669: General: No OEM informations available
[6880] 190312.115711.8669: General: Color branding complete
[5016] 190312.115712.3499: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.3499: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.5779: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.5779: General: Failed to open ADTestHook registry key.
[5016] 190312.115720.1563: Dashboard.Forms: Dashboard: Non domain admin cannot access dashboard.
---------------------------------------------------------

Besonders interessant fand ich die letzte Zeile mit dem Hinweis:

Non domain admin cannot access dashboard … der angelegte Admin war aber ein Domain Admin, sonst würde das auch keinen Sinn ergeben. Da die Mitgliedschaft über Gruppen geregelt wird, habe ich einen funktionierenden Domain Admin mit dem neuen Benutzer vergleichen und keinen Unterschied in den vorhandenen Gruppen feststellen können, bis ich im AD Objekt des Benutzers auf die Primäre Benutzergruppe (Primary group) gestoßen bin. Diese war bei dem funktionierendem Admin Domain Users und nicht Domain Admins wie bei dem Benutzer wo der Start des Dashboard fehlgeschlagen ist.

Eine Änderung von Domain Admins auf Domain Users, hat das Problem gelöst.

image

Das Dashboard konnte wieder geladen werden.

Enjoy it, b!

Windows 10 Update 1903 und der Essentials Connector – Fix

Zumindest aus Sicht des Windows Server Essentials Connector ist jedes Update von Windows 10 spannend. Der seit gestern offiziell verfügbare Build 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. Diese sind nach dem Update einfach 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.

<#     Disclaimer     The author isn't responsible or gives any warranties in cases of data loss or unwanted modifications!

#>

<#   .SYNOPSIS
Fix Windows Server Essentials Launchpad for Windows Build 1903 get the Windows Server Essentials Launchpad back working on an Upgraded Windows 10 1903 client.

.DESCRIPTION
Adds missing Registry Keys to enable the Windows Server Essentials Launchpad again.

.NOTES

File Name : Fix-WSELaunchpad-1903.ps1
Authors : Bernd Pfann (sbsland@outlook.de)
Version : 0.01.0 (24/05/2019)

.LINK
none

.EXAMPLE
Fix-WSELaunchpad-1903.ps1         Adds missing registry to bring Windows Server Essential Services back on the client.

#>

<#

History
0.01, initial version

#>

# Parameters

# Setting Debug Level

Set-PSDebug -Trace 0

# Variables
[string]$Log = $env:temp + "\Fix-WSELaunchpad-1903.log"
[string]$Msg = "Fixing Windows Server Essentials Launchpad on Windows 10 Client Build 1903, Copyright sbsland.me 2019"
[int]$Build = 1903

# Start of output logging and error handling
$ErrorActionPreference = "Continue"
Start-Transcript -Path $Log | Out-Null

# Header
Write-Output`n$msg`n

# Main Program
If ($Build -eq (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name ReleaseID -ErrorAction Stop).ReleaseID) {     Write-Output " Windows 10 is running on build $Build ..."     Write-Output " Adding missing Registry Keys ..."     reg import .\ServiceProviderRegistry.reg     reg import .\WseClientMgmtSvc.reg     reg import .\WseClientMonitorSvc.reg     reg import .\WseHealthSvc.reg     reg import .\WseNtfSvc.reg     Write-Output " Registry Keys have been added, please reboot your Computer."
} Else {     Write-Output " Windows 10 isn't running on build $Build, no action is required."
}

Write-Output " Script finished!"
Stop-Transcript | Out-Null

# Resetting Debug Level
Set-PSDebug-Trace 0

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 Build 1903 handelt, nur dann werden die REG-Dateien in die lokale Registry des Rechners 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.

Enjoy it, b!

Death man walking

Hallo zusammen, das hier ist genau genommen kein Artikel wie ein Problem gelöst werden kann. Vielmehr soll es darum gehen wie ein Problem erst gar nicht entsteht, konkret geht es um einen potenziellen Angriffsvektor der nur zu gerne übersehen und vergessen wird – der lokale Admin!

Installiert man einen Windows Server neu, dann muss im Verlauf des Setups das Admin Passwort vergeben werden … der sich immer in Eile befindliche Admin (Installateur) verwendet hier gerne mal etwas Einfaches wie admin, 1234, … und vergisst nachdem der Server in die Domäne integriert wurde den lokalen Admin zu ändern oder zu deaktivieren. Bei Windows 10, also mit dem Client verhält es sich nicht viel anders, hier muss ein Benutzer angelegt werden und fällt die Wahl auf admin/admin dann ist hier ebenfalls ein Angriffsvektor vorhanden.

Erfolgt dann eine Exposition des Servers per RDP ins Internet, steht der lokale Administrator mit seinem trivialen Passwort eine leichte Aufgabe für Hacker dar.

Darum an dieser Stelle der Rat, ein schwieriges Passwort zu verwenden und im Nachgang den lokalen Administrator zu deaktivieren. Sollte ein lokaler Administrator zwingend benötigt werden, dann lege ich immer einen weiteren Admin, der dann auch nicht Administrator sondern irgendwie anders heißt.

image

Das sieht dann wie oben aus.

Enjoy it, b!