Ob bei automatisiertem Deployment oder beim Erstellen eines Load Balancer in Azure. Eine freie IP Adresse zu finden ist leider mit den vorhandenen cmdlets nicht ohne weiteres möglich.

Test-AzureRmPrivateIPAddressAvailability

Eine beliebte Variante ist die Nutzung des cmdlets Test-AzureRmPrivateIPAddressAvailability. Es liefert bei der Angabe des Netzwerks und einer IP Adresse den Wert TRUE oder FALSE zurück. Manche Menschen fangen jetzt an jede Netzwerkadresse in einem Subnets zu testen, bis eine freie IP Adresse mittels TRUE bestätigt wird.

Obwohl Microsoft einen tollen Job mit ihrem AzureRM Modul macht, gibt es immer wieder Gründe diese cmdlets nicht zu nutzen. In den meisten Fällen weil Sie langsamer sind als direkte Anfragen gegen die Azure REST API sind. In anderen Fällen weil bestimme Funktionalitäten noch nicht implementiert wurden.

In diese Lücke positioniert sich das von mir geschriebene Modul AzureSimpleREST

Das Modul beinhaltet z.B. Funktionen wie “Get-AzSRVMProtectionStatus” die zwar einen offiziell dokumentierten REST Call nutzt, mir aber kein AzureRM cmdlet bekannt ist, dass diese Funktion zu Verfügung stellt. So ist es mittels

Mittels Pester Tests lässt sich bei der PowerShell Modul Entwicklung ein Grad an Qualität sicherstellen, die man sonst nur sehr aufwändig manuell erreichen würde. Dabei gilt es zwei wichtige Faktoren zu prüfen. Modul- und Funktions-Integrität.

Funktions-Integrität

Auf diesen Punkt werde ich in einem späteren Blogeintrag genauer eingehen. Kurz gesagt muss die eigentliche Funktion des Moduls sichergestellt werden.

Ein beliebtes Beispiel ist eine Funktion die zwei Zahlen addiert. Pester erlaubt es zu prüfen ob die Funktion bei der Übergabe von 2 + 3 wirklich 5 zurückliefert. Bei einem echtem Modul ist dies schnell komplexer.

Um eine hohe Verfügbarkeit eines Service auf Azure zu garantieren, sind Availability Sets eine beliebte Möglichkeit. Doch welche Anforderung hat diese Konfiguration an das zugrunde liegende virtuelle Netzwerk?

In den meisten Design Dokumenten findet man ein Bild das ähnlich aussieht wie das folgende.

Zwei virtuelle Maschinen in einem Availability Set im selben Subnet eines virtual Networks.

Doch was ist wenn ich die beiden virtuellen Maschinen in unterschiedliche Subnets oder sogar unterschiedliche virtual Networks installieren möchte?

…wer nervt am meisten im ganzen Land.

Proxy Server sind in vielen Enterprise Umgebungen immer noch ein gern genutztes Mittel um den ausgehenden Webtraffic zu kanalisieren, scannen und Gefahren abzuwehren. Leider setzen die wenigsten Unternehmen auf transparente Proxy Lösungen und zwingen einen dazu den Proxyserver in der jeweiligen Applikation zu hinterlegen.

Da die Konfiguration des Proxys für jede Applikation unterschiedlich ist, sammle ich hier einige Beispiele.

Windows

Mit einem systemweitem Proxy macht man Vieles richtig. Dieser ist in Windows mittels netsh einfach gesetzt.

Die Azure REST API ist grundsätzlich gut dokumentiert und dank des REST API Browsers lässt sich auch auf die schnelle etwas ausprobieren. Jedoch gibt es Momente im Azure Portal die zu verwunderten Gesichtern führen und in diesen Fällen helfen die “Developer tools” von Chrome um Licht ins Dunkel zu bringen.

Das Szenario

Einem Benutzer mit “Read Only” Rechten auf der Subscription soll es möglich sein zu sehen ob und wohin eine virtuelle Maschine gesichert wird. Die virtuelle Maschine kann der Benutzer noch ohne Probleme sehen, jedoch erscheint nach dem Klick auf “Backup” die Aufforderung dieses einzurichten.