Azure Stack TP2 Failed to load the Marketplace

In der aktuellen TP2 von Azure Stack kann es zu einem unschönen Fehler kommen. Zunächst funktioniert die Struktur nach dem Deployment wunderbar. Nach einiger Zeit kann auf einmal der Marketplace nicht mehr geladen werden und auch beim klick auf die Ressource Provider passiert nichts mehr.

158

Ein neues Deployment löst den Fehler zwar, ist aber kein wirklicher Workaround. Die Fehlerursache liegt an der VM MAS-BGPNAT01. Wird die 2016 Eval nicht aktiviert, verweigert die VM und damit AzureStack nach 30 Tagen den Dienst.

159

Ein „normales“ aktiveren der VM ist dann auch nicht mehr möglich. Das Problem haben mittlerweile schon einige Kunden, sodass von einem generellen Fehler auszugehen ist. Nun hat man drei Möglichkeiten.

  1. AzureStack neu deployen und diesmal die VM sofort manuell nachaktivieren
  2. slmgr / rearm (das läuft allerdings nur 4 mal je 10 Tage)
  3. einen MSDN 2016 Datacenter Key über dism einspielen

160

161

Change RDS Certificate Parameter Invalid

Es gibt solche und solche Tage. In einer Kundensituation baue ich gerade eine sehr große RDS Landschaft auf Basis Windows Server 2016 auf. In der Umgebung arbeiten wir mit vielen verschiedenen RDP Client Versionen und verschiedenen Plattformen. Als wir einen Zertifikatsfehler nicht lösen konnten, entschloss ich mich testweise das RDP Zertifikat an einigen Sessionhosts zu tauschen. Normalerweise spielt das Session Host Zertifikat ab RDP 8.0 keine Rolle mehr. Microsoft ermöglichte die Änderung bis 2008R2 in der GUI, ab 2012 nur noch per Powershell. Dazu gibt es mittlerweile auch einen Hilfeartikel von Microsoft. Im Bild zu sehen ist die Änderung vom Self-Signed RDP Zertifikat auf das Externe.

153

Nachdem der Tausch auch keine Lösung für das ursprüngliche Problem brachte, war klar dass es wieder zurück gerollt werden musste. Der erste Befehl liest den Zertifkatsfingerabruck aus dem Zertifikat im Speicher Remotedesktop aus. Der zweite Befehl soll das verwendete Zertifikat tauschen.

$Thumb = (Get-ChildItem -Path ‚Cert:\LocalMachine\Remote Desktop‘).Thumbprint
$path = (gwmi -class „Win32_TSGeneralSetting“ -Namespace root\cimv2\terminalservices -Filter „TerminalName=’RDP-tcp'“).__path
swmi -Path $path -argument @{SSLCertificateSHA1Hash=“$Thumb“}

Leider hat das zurückändern nicht mehr funktioniert. Obwohl der Zertifikat im Speicher war, erschien die Fehlermeldung swmi : Invalid Parameter

155

Das Internet und die Blogs sind voll von Empfehlungen, andere Schreibweise des Thumbs, CMD statt Powershell, aber auch viele Artikel ohne Lösung. So erging es auch mir, keine Lösungsempfehlung half. Neuaufbau beim Kunden war keine Option. Nach einer langen Nacht konnte ich den Fehler in der Windows Registry ausfindig machen. Dort wird ein fehlerhafter Wert generiert und verhindert dann sämtliche Änderungsversuche. Nachdem der Wert SSLCertificateSHA1Hash aus der Registry gelöscht wurde, klappte auch die Änderung auf ein neues RDS Zertifikat. Der Fehler tritt aktuell unter Windows Server 2012 bis 2016 auf.

156 157

RemoteDesktop Gateway Farm Unreachable / Firewall

Bei der Einrichtung einer RemoteDesktop Gateway Farm unter Windows Server 2016 (sicherlich auch 2012R2) gibt es eine Besonderheit zu beachten. Entgegen des restlichen Setups werden die Regeln in der Windows Firewall zwar erstellt aber nicht aktiviert. Damit der gegenseitige Zugriff klappt, müssen die Regeln im Nachgang aktiviert werden. Etwas unschön finde ich, dass die Ports beidseitig dynamisch geregelt werden.

147 148 149 150

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

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.

Azure Stack TP2 – Error Directory Services Restore Mode Password

Invoke-EceAction : Verification of prerequisites for Domain Controller promotion failed. The Directory Services Restore Mode password does not meet the password complexity requirements of the password policy.

Ein weiterer Fehler der mir in der Installation der TP2 aufgefallen ist, bei der Eingabe des Passwortes im Step 1 wird keine Validierung durchgeführt, ob das Passwort den Anforderungen im Deployment genügt. In der Dokumentation sind die Anforderungen des Passwortes derzeit falsch hinterlegt.

142

Lösung:

  1. Änderung des lokalen Administrator Passwortes des Hyper-V OS (übliche Active Directory Passwortrichtlinie)
  2. Config.xml umbenennen
  3. VM MAS-DC01 löschen
  4. VM Switche löschen
  5. neues Deployment starten (nicht rerun, da hier das Passwort als Variable gespeichert wurde)

143

144

146

145