Archiv der Kategorie: Hyper-V Replikation

Synology Directory Server | Hyper-V Replica schlägt fehl–Kerberos Fehler

Veröffentlicht am von
Antwort

Ich arbeite bei kleinen Projekten gerne mit dem Synology Directory Server als Ersatz für das Microsoft Active Directory (AD). Bei ein paar Benutzern, lassen sich hier doch einige Kosten sparen. Nun kommt aber auch dort gelegentlich die Anforderung eine Virtuelle Maschine (VM) hochverfügbar bereitzustellen. Dafür habe ich bisher immer den Microsoft Hyper-V Server (2019) in Verbindung mit der Hyper-V Replica verwendet.

Das klassische Setup, hat auch bis zur Aktivierung der Hyper-V Replication problemlos funktioniert.

  • Join der beiden Hyper-V Hosts in die Domain des Synology Directory Servers
  • Öffnen der Firewall auf den Hyper-V Hosts um über Port 80 der 443 zu replizieren
  • Verwendung der Kerberos Authentifizierung (HTTP) für die Replikation
  • Einrichten der Hyper-V Replica für eine oder zwei VMs

Allerdings wurde ich am Ende der Konfiguration mit dieser Fehlermeldung konfrontiert und konnte auf Anhieb nichts damit anfangen.

image

Ja klar, es gibt ein Problem mit Kerberos … aber wieso?

Die Namensauflösung funktionierte und auch die ServicePrincipalNames sind registriert.

image

Auch die Ports 80 und 443 sind über die Firewall geöffnet und antworten wie erwartet.

Mein Verdacht fiel nach einiger Zeit auf dem Synology Directory Server, dieser stellt quasi eine Domain mit dem folgendem Functional-Level bereit.

  • Domain functional level: Equal to Windows Server 2008 R2

Die Hyper-V Replica wurde mit Windows Server 2012 vorgestellt, was aber nicht zwingend heißen muss, dass die Domain ebenfalls auf diesem Level sein muss. Ich denke aber das darin und vielleicht in Verbindung mit der Tatsache, dass hier eigentlich Samba 4.10 läuft, hier das Problem liegen könnte.

Als Alternative wollte ich die Authentifizierung per Zertifikat verwenden.

image

Dabei bin ich über eine Reihe von Herausforderungen gestolpert, die sich aber letztendlich lösen ließen. Als Grundlage habe ich diese Anleitung verwendet, die aber nur mit kleineren Modifikationen funktionierte.

Ein wichtiger Unterschied ist auf jeden Fall, dass meine beiden Hyper-V Hosts in der Domain verbleiben sollen, also nicht in einer Workgroup betrieben werden.

  • Insgesamt werden n+1 (N = Anzahl der Hyper-V Hosts die an der Replikation teilnehmen) Zertifikate erstellt. Für jeden Hyper-V Host eines (das Server-Zertifikat) und das Root-Zertifikat. Bei zwei Hosts, haben wir damit drei Zertifikate
  • Während das Root-Zertifikat auf jedem der Hyper-V Hosts installiert wird, bekommt jeder Host ein eigenes Server-Zertifikat

Auf dem ersten Knoten wird eine PowerShell-Sitzung als Administrator gestartet und dazu die folgenden Variabel angelegt.

image

Danach wird das Root-Zertifikat erstellt. Dazu habe ich die folgenden Punkte geändert (Zeile 26).

  • KeyUsage CertSign  in
  • KeyUsage CertSign, CRLSign, DigitalSignature

Darüber hinaus in Zeile 27

  • KeyLength 2056 in
  • KeyLength 4096

image

Der Server auf dem das Root-Zertifikat erstellen, muss diesem ebenfalls vertrauen. Darum wird das Zertifikat von Personal nach Trusted Root Certification Authorities kopiert.

image

Nun wird auf demselben Knoten sowohl das Root-Zertifikat exportiert als auch die Server-Zertifikate erstellt.

image

Auch bei der Erstellung der Server-Zertifikaten habe ich ein paar Änderungen vorgenommen.

Hinzufügen eines weiteren Parameters (Zeile 64), wobei ich dazu (Zeile 60) den FQDN erstelle

  • DnsName $fqdn, $name
  • KeyLength 4096

image

Auf allen Hyper-V Hosts muss nun die Prüfung der Zertifikate abgeschaltet werden.

image

Nun werden die Zertifikate auf die anderen Knoten (hier nur einer) verteilt.

image

Kleiner Tipp, der “\” am Ende des Pfads erstellt das Verzeichnis automatisch.

Nun wird auf dem 2ten Knoten sowohl das Root- als auch der Server-Zertifikat importiert

image

Das sieht dann auf jedem Hyper-V Host wie folgt aus.

image

image

So, damit sollte die Hyper-V Replikation eigentlich funktionieren, was aber nicht der Fall war. Zusätzlich zur certificate-based Authentification (HTTPS), musste ich auch noch die Verwendung von Kerberos (HTTP) aktivieren! Warum, kann ich nicht genau sagen und muss hier nochmals mit einem Netzwerk-Trace der Sache auf den Grund gehen.

image

Mit dieser Konfiguration funktioniert nun die Hyper-V Replikation auch mit Hyper-V Hosts die in einer Samba-Domain und dem Synology Directory Server Mitglied sind.

Enjoy it, b!

Hyper-V Replication State Critical

Veröffentlicht am von
Antwort

Nach dem Update einiger Hyper-V Hosts wollte die, für einige VMs eingerichtete Hyper-V Replication nicht mehr starten. Der Replication Health stand auf Critical und das Übliche, über das Menü des Hyper-V Manager verfügbare Resume Replication funktionierte nicht.

image

Eine Abfrage mit PowerShell stellte die Situation wie folgt dar.

image

Zusätzlich wurde im Hyper-V Manager die folgende Information bereitgestellt.

image

Das Problem war, dass ein Resync der Hyper-V Replication notwendig war. Dieser aber über den Hyper-V Manager nicht zur Verfügung stand, also in der GUI nicht angeboten wurde.

Die Lösung stellt hier, wie so oft unter Windows, PowerShell bereit. Hier besteht explizit die Möglichkeit einen Resync der VM anzustoßen.

# Hyper-V Replication, resync einer einzelnen VM
Resume-VMReplication -VMName 'mt-app-2.testlab.local' -Resynchronize

Sollten mehrere VMs von dem Problem betroffen sein, können alle mit dem gleichen Health State über die Kombination der folgenden Befehle zu einem Resync bewegt werden.

# Hyper-V Replication, resync aller VMs eines Hosts im Zustand "critical"
Get-VMReplication | Where-Object { $_.Health -eq 'Critical' } | Resume-VMReplication -Resynchronize

Bei einem Resync geht einiges an I/O über die Leitung und abhängig von der Größe der VMs kann das durchaus einige Zeit in Anspruch nehmen.

image

image

In diesem Fall waren es gut 5 Stunden. So, läuft wie man heute gerne dazu sagt.

image

image

Enjoy it, b!

Hyper-V failed to enable replication

Veröffentlicht am von
Antwort

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!

Moving Hyper-V Replikas

Veröffentlicht am von
Antwort

Seit der Hyper-V Version in Windows Server 2012 R2 lassen sich VMs im laufenden Betrieb auch ohne Failover Cluster verschieben. Das ist ziemlich Klasse und aus Sicht eines Schwaben schon ein Mega-Lob Winking smile Darüber hinaus gibt es noch die Möglichkeit eine Hyper-V Replikation zu erweitern (Extended Hyper-V Replication), also eine replizierte VM nochmals auf einen weiteren Hyper-V Host zu replizieren. Man hat damit also zwei Kopien einer VM.

Will man nun eine dieser Kopien verschieben, muss man auf eine Kleinigkeit aufpassen. Nach dem Verschieben muss nämlich, der Replica-Server angepasst werden. Ich zeige den Ablauf an einem Beispiel, damit klarer wird was ich meine.

Allgemein

Ich benenne meine Hyper-V Replikas immer um, indem ich ein “!” voran stelle. Die erste Replikation bekommt ein ! und die zweite Replikation !!, also:

  1. vm.sbsland.local (aktive VM)
  2. !vm.sbsland.local (erste Replika)
  3. !!vm.sbsland.local (zweite Replika)

Ausgangsituation

Wir haben eine VM (vm.sbsland.local) welche über insgesamt 3 Hosts repliziert wird.

image

Die VM (vm.sbsland.local) läuft auf dem Hyper-V Host 1 (cnoc.whisky.local) und wird von dort auf den Hyper-V Host 2 (nevis.whisky.local) repliziert. Auf diesem Host (nevis.whisky.local) wurde dann wiederum eine erweiterte Replikation (Extended Replication) auf den Hyper-V Host 3 (skye.whisky.local) eingerichtet.

Auf den Hyper-V Hosts sieht das nun wie folgt aus. Neben PowerShell habe ich noch jeweils den Hyper-V Manager / Replikation für die VM dargestellt.

cnoc.whisky.local:image

image

nevis.whisky.local:
image

image

Hier sehen wir neben der ersten (primary) Replikation auch die erweiterte (extended) Replikation.

skye.whisky.local:
image

image

Zielumgebung

Nun wollen wir den Hyper-V Host 2 (nevis.whisky.local) durch einen neuen Hyper-V Host ersetzen (mull.whisky.local). Eine erste Idee wäre natürlich einfach die Hyper-V Replikationen neu ein zu richten, das wollen wir aber nicht! Wir verschieben einfach die erste Replika der VM (!vm.sbsland.local) auf den neuen Hyper-V Host (mull.whisky.local).

image

Wie in der Abbildung zu sehen ist, wird die erste Replika (!vm.sbsland.local) der VM auf den neuen Host verschoben. Das kann über das Hyper-V Management oder aber über den folgenden PowerShell-Befehl erfolgen.

Move-VM -Name !vm.sbsland.local -DestinationHost mull.whisky.local -IncludeStorage -DestinationStoragePath 'd:\replicated virtual machines'

image

Nun haben wir auf dem Hyper-V Host 2 NEU (mull.whisky.local) die VM, aber noch mit dem alten Hyper-V Host 2 (nevis.whisky.local) eingetragenen Replika Server. Nach Ablauf des Intervalls für die Hyper-V Replikation geht diese in den Zustand Warning bzw. Critical.

image

Damit die Replikation wieder in Gang gesetzt werden kann, muss in der Konfiguration der !vm.sbsland.local der alte Hyper-V Host 2 (nevis.whisky.local) gegen den neuen Hyper-V Host (mull.whisky.local) ersetzt werden. Was über das Hyper-V Management oder über den folgenden PowerShell-Befehl erfolgen kann:

Set-VMReplication -VMName vm.sbsland.local -ReplicaServerName mull.whisky.local

Der Befehl muss dazu auf dem Hyper-V Host 1 (cnoc.whisky.local) ausgeführt werden.

image

Danach recht ein Resume-VMReplication um die Replikation wieder in Gang zu setzen.

image

image

So, nun läuft es wieder.

Enjoy it, b!

Hyper-V Replika und Configuration Version

Veröffentlicht am von
Antwort

Auf einem Hyper-V Host hatte ich das Problem, dass die Hyper-V Replikation einfach nicht mehr in Gang zu bekommen war. Gewundert hat mich das schon, da diese coole Technologie seit dem Windows Server 2012R2 problemlos funktioniert hat. Unter Windows Server 2012 hatte ich gelegentlich kleinere Probleme, die aber mit dem R2 Release verschwunden waren. Doch zurück zum Problem …

Die Hyper-V Replication war im Status Critical und ließ sich auch manuell nicht mehr zur Arbeit bewegen.

Ich habe ein wenig herum gesucht, bis mir auffiel das beide VMs welche an der Replikation teilnehmen unterschiedliche Hyper-V Configuration Versionen hatten! Hier wurde wohl die Version der einen VM aktualisiert und dabei die Replika vergessen.

Damit man an die Hyper-V Configuration Version kommt, muss man diese im Hyper-V Management einblenden.

image

VMs welche auf einem Windows Server 2016 (oder auch Hyper-V 2016) angelegt werden, haben die Version 8. VMs welche auf so einen Host verschoben werden, können im ausgeschalteten Zustand auf diese Version aktualisiert werden. Das muss dann auch auf allen Replikas gemacht werden. Ist das nicht möglich, da z.B. Replikations-Hosts noch alle eine “alte” Hyper-V Version haben, muss die VM solange auf Version 5 bleiben, bis ein Upgrade stattgefunden hat. Dann klappt es auch wieder mit der Replikation.

Enjoy it, b!

NTDS Backup Error 1168 (1032)

Veröffentlicht am von
2

Manche Fehler sind schon fieß! Auf einem Windows Server 2012 R2 DC (Windows Server 2012 R2 mit installierter Small Business Essential Rolle) hatte ein Kunde seit einiger Zeit den folgenden Fehler im Health Report des Servers.

image

Analog dazu die entsprechende Meldung im Ereignisprotokoll (der Health Report holt diese auch nur dort heraus).

image

Um diesen Fehler zu reparieren gibt es hinreichend viele Links, Artikel und Blogs im Web:

https://support.microsoft.com/de-de/kb/280364

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1a0d9633-c497-4cab-bbff-053e2a056f6d/event-id-1168-active-directory?forum=winserverDS

Welche aber alle nicht funktionieren (zumindest in diesem Fall hat das nicht geklappt). Im Application Eventlog habe ich dann immer die folgenden Einträge gefunden…

image

… die auf ein Problem mit dem VSS Writer hindeuten.

image

Eine Abfrage der Registry ergab aber, dass die Einstellungen passen müssten.

C:\Temp>reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Para
meters

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    Src Srv objectGuid    REG_BINARY    08E518AF5742FA48ACCAFDAD6F518DE4
    System Schema Version    REG_DWORD    0x45
    Root Domain    REG_SZ    DC=xxx,DC=local
    Configuration NC    REG_SZ    CN=Configuration,DC=xxx,DC=local
    Machine DN Name    REG_SZ    CN=NTDS Settings,CN=WP-SBS-1,CN=Servers,CN=Stan
dardname-des-ersten-Standorts,CN=Sites,CN=Configuration,DC=xxx,DC=local
    Src Root Domain Srv    REG_SZ    WP-SBS-2.xxx.local
    DsaOptions    REG_SZ    1
    IsClone    REG_DWORD    0x0
    ServiceDll    REG_EXPAND_SZ    %systemroot%\system32\ntdsa.dll
    DSA Working Directory    REG_SZ    C:\Windows\NTDS
    DSA Database file    REG_SZ    C:\Windows\NTDS\ntds.dit
    Database backup path    REG_SZ    C:\Windows\NTDS\dsadata.bak
    Database log files path    REG_SZ    C:\Windows\NTDS
    Hierarchy Table Recalculation interval (minutes)    REG_DWORD    0x2d0
    Database logging/recovery    REG_SZ    ON
    DS Drive Mappings    REG_MULTI_SZ    c:\=\\?\Volume{ca08668b-ea69-4e87-a59a-
c848a2f1fea5}\
    DSA Database Epoch    REG_DWORD    0x2ba5
    Strict Replication Consistency    REG_DWORD    0x1
    Schema Version    REG_DWORD    0x45
    ldapserverintegrity    REG_DWORD    0x1
    Global Catalog Promotion Complete    REG_DWORD    0x1

Das Volume für das DS Drive ist korrekt und die anderen Einträge stimmen auch, allerdings hatte der VSS Writer ein Problem …

c:\temp> vssadmin list writers
...

Writer name: 'NTDS'
   Writer Id: {b2014c9e-8711-4c5c-a5a9-3cf384484757}
   Writer Instance Id: {f86a8c78-c7e5-4f16-b1fd-09abd7eaff32}
   State: [11] Failed
   Last error: Non-retryable error

...

… das sich auch nicht durch einen Neustart beheben ließ. Daraufhin habe ich die VM auf dem Hyper-V Host exportiert und in meiner Testumgebung wieder importiert und gestartet … der Fehler war weg! Ein Vergleich der beiden Hosts / VMs ergab, dass auf dem Host welcher die VM mit dem Fehler bereit stellt die Hyper-V Replikation aktiv war. Per se, ist das kein Problem da auch im Testlab eine Replika am Laufen war – nur eben mit einer anderen Einstellung!

image image
Fehler 1168 im Eventlog vorhanden KEIN Fehler im Eventlog vorhanden

Nachdem auf dem produktiven Hyper-V Host die Replikation entsprechend angepasst wurde, war dort der Fehler verschwunden.

Enjoy it und noch ein gutes Neues Jahr 2017, b!