Azure Stack PDF / MOC / Exam

Der Themenbereich Azure Stack nimmt nun (langsam) fahrt auf. Microsoft hat interessante Materialien veröffentlicht. Zum einen das PDF Azure Stack Building an end-to-end validation environment. Auf 46 Seiten werden die Basics beschrieben. Am Ende finden sich Links mit weiterführendem Material.

https://azure.microsoft.com/de-de/resources/azure-stack-building-end-to-end-validation-environment/en-us/

Daneben ist der Course 20537A: Configuring and Operating a Hybrid Cloud with Microsoft Azure Stack seit Ende September fertig und wird ab Anfang 2018 bei verschiedenen Schulungsanbietern zur Verfügung stehen. Der MOC Kurs bereitet auf die Zertifizierung 70-537 vor. Die Prüfung kann bereits als Beta Prüfung abgelegt werden und wird Anfang 2018 final. Microsoft hat zudem die Bedingungen für Beta Examen geändert. Diese sind nicht wie früher komplett kostenfrei, sondern werden teilweise verrechnet. Alle Infos dazu unter dem Link.

https://borntolearn.mslearn.net/b/weblog/posts/updates-on-microsoft-beta-exam-program-read-this

Azure Stack Deployment Kit, One Node & Azure Stack Installer?!

Seit einigen Tagen ist Azure Stack nun verfügbar. Für mich direkt ein Grund mein LAB wieder neu aufzubauen. Letztlich hat sich zwischen der TP3 R1 und der GA funktionell nicht mehr viel geändert. Jedoch gibt es neue Begrifflichkeiten über die ich informieren möchte.

Azure Stack Deployment Kit / One Node

Bei dem Azure Stack Deployment Kit handelt es sich um die One Node / POC Variante bzw. die gleiche Art, wie auch die Technical Previews aufgebaut war. Ob die Hardwarehersteller auch vorkonfigurierte Deployment Kits liefern bleibt abzuwarten.

Azure Stack Installer

Der Aufruf des Installer Skriptes hat sich im Laufe der TPs immer etwas verändert. Microsoft hat für die Installation des Stacks in der GA eine kleine GUI entwickelt. Diese heißt Azure Stack Installer. Das Skript muss vor dem Setup aus Github heruntergeladen werden.

Immerhin prüft der Installer nun ob das Passwort der Policy entspricht. In der TP ist das Deployment fehlgeschlagen, wenn das Passwort nicht der Richtlinie entsprach. Leider gibt das Eingabefeld keine Fehlermeldung aus. Das Feld wird dann Rot, aber die Bedingungen zur Bildung werden nicht genannt.

Am Ende der GUI wird der Skriptaufruf samt Parameter erzeugt. Natürlich hätte man das auch direkt ohne GUI eingeben können 😉

Es besteht nun auch die Möglichkeit mit einem Klick nach der Installation Logs zu generieren. Ein knappes GB kommt direkt nach der Basisinstallation zusammen.

Wie auch bei allen anderen Azure Themen empfiehlt es sich die Docs Dokumentation zu lesen. Hier finden sich viele hilfreiche Themen wie bspw. die Architektur des Kits.

https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-architecture

Meine weiterführenden Skripte aus TP3 R1 kann ich auch alle in der GA verwenden. Viel Spaß beim develop’en.

Azure Stack TP3 keine User Subscription sichtbar

Eine kleine Sache hat mich heute etwas Zeit gekostet, vielleicht hilft es dem einen oder anderem. In der TP3 hat sich etwas Entscheidendes geändert, es gibt nun zwei Portale.

Portal URL API endpoint URL
Administrator https://portal.local.azurestack.external https://api.local.azurestack.external
User https://publicportal.local.azurestack.external https://publicapi.local.azurestack.external

Dummerweise ist das Administrator Portal für User nicht gesperrt. Ich habe einen Moment nicht aufgepasst und mich gewundert warum mir nachdem Erstellen einer Subscription als User keine Subscription angezeigt wird. Die Subscription selbst sah doch im „Offer“ gut aus.  Der Fehler war die Nutzung des falschen Portals. Leider merkt man es erst hinterher, da sich die Subscription zunächst problemlos erstellen lässt. Hätte ich mal besser gleich ordentlich die Schritte der TP3 Doku gelesen 😀

https://docs.microsoft.com/de-de/azure/azure-stack/azure-stack-manage-portals

Eindrücke vom Event Azure Certified for Hybrid Cloud Airlift

In Bellevue, Washington, USA unweit entfernt vom Microsoft Campus Redmond findet derzeit das „Azure Certified for Hybrid Cloud Airlift“ Event statt. Ich verfolge das Event vor Ort. In dem viertägigen Event dreht sich alles um Microsofts neue Plattform Azure Stack. Allein die Teilnehmeranzahl von über 900 zeigt wie groß das Interesse ist. Dabei ist der Fokus der Teilnehmer gut durchmischt, vom ISV (Independent Software Vendor) über System Integratoren (SI) bis hin zu Cloud Solution Providern (CSP) ist alles vertreten. Die zum Marktstart Mitte 2017 verfügbaren Hersteller Dell, HPE und Lenovo stellen Ihre Systeme im Foyer zur Schau. Passende Breakout Sessions inkl. technischen Deep Dive ergänzen des Wissensdurst.

Das Puzzle fügt sich zu einem großen Gesamtbild zusammen. Mit der Teilnahme habe ich allerdings einer Verschwiegenheitsvereinbarung zugestimmt, sodass ich jetzt leider noch keine Details preisgeben darf. Besonders gut gefällt mir die Darstellung der ersten Use Cases und die Zusammenfassung der PoC Implementierungen. Hier einige Eindrücke vom Event.

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