Cloud Proxy ist eine neue Funktion in 1606 Technical Preview, die mobilen Geräten eine einfache Verbindung zum ConfigMgr ermöglicht. Dabei ist On-Premise keine DMZ notwendig.
Der Cloud Proxy wird durch den ConfigMgr selber installiert. Dazu muss der Server auf das entsprechende Azure Konto zugreifen können. Klassisch und auch in diesem Fall erfolgt dies über ein Management Zertifikat. Der Public Key dieses Schlüssels wird in Azure hochgeladen und jeder mit dem Privat Key kann administrativ auf das Konto zugreifen.
Managementzertifikat erstellen
Falls noch kein passendes Zertifikat verfügbar ist, kann dieses als Selbstsigniertes erstellt werden. (Anmerkung: In einem Unternehmensumfeld sollte ein passendes Zertifikat von einer Zertifizierungsstelle (CA) ausgestellt werden)
Eine Beschreibung dazu ist unter https://azure.microsoft.com/de-de/documentation/articles/cloud-services-certs-create/ zu finden.
Zertifikate zum Management können nur noch im klassisches Azure Portal über https://manage.windowsazure.com/ hinterlegt werden.
Dazu geht man auf Einstellungen und wählt den Punkt Verwaltungszertifikate aus:
In diesem einfachen Fall nutze ich ein selbstsigniertes Zertifikat auf den Namen “managed-by-cm01”, da es von meinem ConfigMgr Server mit dem Namen cm01 verwendet werden soll:
$cert = New-SelfSignedCertificate -DnsName manage-by-cm01 -CertStoreLocation “cert:\LocalMachine\My”
$password = ConvertTo-SecureString -force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath “d:\configmgr\certificates\manage-by-cm01.pfx” -Password $password
Export-Certificate -Type CERT -Cert $cert -FilePath d:\configmgr\certificates\manage-by-cm01.cer
Nach einem erfolgreichen Hochladen der exportierten CER Datei (beinhaltet nur den öffentlichen Schlüssel), sieht dies so aus:
Cloudapp.net Zertifikat erstellen
Der Zugriff über den Cloud Proxy erfolgt über eine eigene URL, die mittels HTTPS abgesichert wird. Hier reicht ein selbst-signiertes Zertifikat nicht aus, da dieses bei meinen Tests nicht akzeptiert wurde, d.h. der nachfolgende Wizard hat es genutzt (wenn man es auch als Root Zertifikat hinterlegt), aber es konnte nicht nach Azure hochgeladen werden. Daher nutze ich eine eigene Root CA, die mir das Zertifikat ausstellt. Die einzelnen Schritte sind IDentisch mit dem Cloud-Based Distribution Point: https://technet.microsoft.com/en-us/library/mt627852.aspx#BKMK_clouddp2008_cm2012
Die vom Web-Server geklonte Zertifikatsvorlage heißt MB…:
Der private Schlüssel darf exportiert werden:
Der Subject Name darf/muss im Request mitgegeben werden:
Und die Gruppe MB ConfigMgr Site Server, in der mein ConfigMgr Server cm01 enthalten ist, darf dieses Zertifikatsvorlage nutzen:
Zugeordnet ist diese Vorlage dann meiner Online CA:
Über die Zertifikats-MMC mit Verbindung zum lokalen Server wurde dann ein neues Zertifikat auf den DNS Namen mbcloudproxy.cloudapp.net ausgestellt:
Dieses Zertifikat wurde nach d:\configmgr\certificates inkl. privaten Schlüssel exportiert. Ebenso wurde das Root Zertifikat als root.cer abgelegt.
Erstellen des Cloud Proxys über den ConfigMgr
Die notwendigen Zertifikate liegen jetzt im entsprechenden Ordner bereit:
Wie bereits Eingangs erwähnt, wird der Cloud Proxy direkt über den ConfigMgr Server erstellt. Dazu startet man den entsprechenden Wizard über die ConfigMgr Konsole im Administrativen Bereich:
Im ersten Schritt wird die Subscription ID (=Abonnement-ID in den Abonnements des Azure Portals) und das Managementzertifikat eingetragen:
Danach werden die Einstellungen für die Cloud-VMs hinterlegt:
Anmerkung: Alle Einstellungen (bis auf die Subscription) sind im nachhinein über die Eigenschaften des Cloud Proxies anpassbar, dies bezieht sich auch auf die Anzahl der VMs, die sich darüber problemlos hoch unter herunterskalieren lassen.
Direkt nach dem beenden des Wizards beginnt das Anlegen der VM(s):
Zuständig dafür ist die Cloud Manager Komponente mit dem Log cloudmgr.log:
(Wenig) Fehler im Log sind am Anfang normal, da er regelmäßig überprüft, ob die Bereitstellung bereits erreichbar ist.
Im Azure Portal wird eine neue Ressourcengruppe mit dem angegebenen Namen angelegt. Diese erhält die im Zertifikat hinterlegte URL und eine öffentliche IP. Zusätzlich werden in ihr die hinterlegte Anzahl von VMs angelegt, die später in unterschiedlichen Fault Domänen abgelegt sind:
Sobald eine VM gestartet ist, sollte die Anzeige in der ConfigMgr Konsole auf Provisioning completed wechseln.
Kommunikation zwischen Cloud Proxy und ConfigMgr einrichten
Mittels einer neuen Site Rolle kann definiert werden, welcher Server die Verbindung zum Cloud Proxy aufbaut und hält. Dazu fügt man zu dem gewünschten Site Server eine neue Rolle hinzu. In diesem einfachen Beispiel nutze ich den Primary Site Server, auf dem alle Rollen vereint sind:
Die neue Rolle heißt Cloud proxy connector point:
Und benötigt nur die Information, mit welchem Cloud Proxy er sprechen soll. Auch hier zählt wieder der Cloud Gedanke: Es ist möglich Cloud Proxies über die ganze Welt innerhalb von Azure zu verteilen und am jeweiligen Standort vor Ort einen entsprechenden Cloud Proxy Connector einzurichten, der die Kommunikation aufbaut:
Zusätzlich muss in den Eigenschaften des Management Points auf dem Cloud Proxy Connectors eingestellt sein, dass er Cloud Proxy Traffic erlaubt:
Der Cloud Proxy Connector benötigt für den Aufbau der Verbindung ein Zertifikat mit Client Authentication, d.h. im Allgemeinen ein ConfigMgr Client Certificate.
Im Log der Cloud Proxy Connector Komponente sollte danach ein erfolgreicher Verbindungsaufbau sichtbar sein:
Aktuell unterstützt der Cloud Proxy folgende Rollen/Funktionen:
Zusätzliche werden folgen. Im nächsten Blog Eintrag werde ich die Client Seite beleuchten.
