Windows Server 2016 Workgroup Cluster ohne DNS

Die neue Funktion in Windows Server 2016 einen Hyper-V Cluster auch in einer Workgroup zu betreiben ist besonders für DMZ Szenarien interessant. In der Regel ist man in der DMZ bestrebt, die Abhängigkeiten zu anderen Diensten zu minimieren. Für Active Directory geht das nun, warum also nicht gleich auch für DNS? In dem bisher einzigen Artikel zum Workgroup Cluster wird die Anforderung zum DNS mit „sollte“ beschrieben. In der Praxis funktioniert der Cluster auch wunderbar, wenn die Namen der Knoten und des Clusters je in der Host Datei aufgenommen werden. Ist zwar etwas Oldschool aber der Cluster startet ohne jede Abhängigkeit. Microsoft zögert aktuell noch, dass als offiziell supported zu bezeichnen, da versuche ich gerade noch der Produktgruppe ein Statement abzuringen. Es wird aber auch nicht als unsupported bezeichnet. Dazu noch folgende Hinweise.

  • entfernt die DNS Registrierung in den TCP/IP Einstellungen, sonst meldet der Cluster ständig Fehler
  • verwendet ein Quorum

In DMZ Szenarien

  • überprüft welche der Windows Firewall Regeln noch geschlossen werden können
  • trennt das Management Netz vom VM Netz
  • entfernt die GUI nach der Konfiguration, oder lieber gleich Nano Server 😉

144 145 146

Werbeanzeigen

Azure Active Directory Domain Services ARM Network – Gateway oder VNet-Peering

Zwischen den Feiertagen stand das Thema Azure Active Directory Domain Services auf dem Aufarbeitungsplan. An sich ist das ja keine komplizierte Sache, nur wird aktuell der Service komplett in ASM (manage.windowsazure.com) bereitgestellt. Der Service setzt ein verbundenes VNet voraus. Nun erratet Ihr schon das Problem, es können natürlich direkt keine ARM VNets angebunden werden. Die Kritik dazu ist in den Foren und Blogs schon relativ hoch. Verständlich, warum announced Microsoft im Oktober einen Service GA, der letztlich nur im alten Deploymentmodel zur Verfügung steht. Das es auch anders geht zeigt bspw. der Service StorSimple. In diesem kann man direkt aus ASM – ASM und ARM Speicherkonten hinterlegen.

Generell gibt es zwei Möglichkeiten den Services mit ARM zu verheiraten. Entweder über ein Gateway oder über VNet-Peering. Der Unterschied liegt vor allem in den zusätzlichen Gateway Kosten, auch ist die Einrichtung des Gateways wesentlich komplexer. Dafür kann über das Gateway eine Verbindung zwischen Regionen aufgebaut werden, währenddessen sich VNet-Peerings nur für Verbindungen innerhalb einer Region eignen. In der Doku wird das Thema leider gar nicht behandelt. Es gibt bisher in den offiziellen Microsoft Blogs nur einen Artikel der das Szenario mit Gateway beschreibt. Auch liefert Google nicht gleich den gewünschten Treffer, was mit letztlich zum Schreiben des Beitrages animiert hat.

https://blogs.technet.microsoft.com/markrenoden/2016/06/10/using-azure-active-directory-domain-services-with-arm-vnets/

Die Schritte für das VNet-Peering sind sehr einfach. Nachdem der Azure Active Directory Domain Services komplett samt VNet im ASM erstellt wurde, wechsle ich ins Azure Portal und erstelle ein zweites VNet in einem anderen Adressbereich und verbinde die VNets miteinander. Danach noch der Domain Join und fertig.

143

144

145

147

146

148

Hier auch nochmal die Azure Dokumentation dazu.

https://docs.microsoft.com/de-de/azure/virtual-network/virtual-network-peering-overview

Ob man den Services aktuell produktiv ausrollen sollte ist zumindest fragwürdig. Zum einen holt man sich wieder unnütze ASM Altlast in das Deployment, zum anderen stehen die ganzen modernden Funktionen wie bspw. Role-Based Access Control nicht zur Verfügung.