Seit der Version 2107 bietet der Microsoft Endpoint Configuration Manager die Möglichkeit, Cloud Management Gateways die über den "Classic" Cloud Service erstellt wurden, in eine VM Skalierungsgruppe zu migrieren. Mit der Version 2203 wurde dann der offizielle Support für die Bereitstellung via classic service entfernt. Da viele Kunden nach wie vor jedoch mit älteren CMGs arbeiten und die Migration nur unter bestimmten Voraussetzungen möglich ist, möchte ich heute auf die Frage eingehen wie man ein bestehendes CMG am besten migrieren kann und was die Migration für bestehende Clients bedeutet, die aktuell nur über das Internet mit der MEMCM Umgebung kommunizieren.

Voraussetzungen/Überlegungen für die Migration/Konvertierung

1. ​Feature Aktivieren

Sehen wir uns zunächst die zu erfüllenden Bedingungen für eine erfolgreiche Migration an. Sofern noch nicht geschehen muss das entsprechende Feature in der Konsole aktiviert werden. Hierdurch wird einerseits die Funktion "Konvertieren" am CMG in der Ribbon Bar sichtbar und zum anderen können auch neue CMGs direkt in einer VM Skalierungsgruppe installiert werden.

2. Ressourcen Anbieter überprüfen

Möchte man nun entweder ein bestehendes CMG konvertieren oder ein neues erstellen, sollte an der verwendeten Azure Subscription vorher überprüft werden ob folgende Ressourcen Anbieter registriert sind, um sich im späteren Verlauf der Bereitstellung Ärger zu ersparen:

• Microsoft.Network
• Microsoft.KeyVault
• Microsoft.Compute
• Microsoft.Storage
  
  

3. Verwendeter Dienstname/Domäne

Selbst mit der Erfüllung der bereits genannten Voraussetzungen kann es passieren, dass nach einem Neustart der Configuration Manager Konsole immer noch keine "Konvertierungs" Option für das bestehende CMG angeboten wird. Sollte dieser Fall auch bei Ihnen eintreten, kann es am verwendeten Dienstnamen liegen. Ein Blick in die Microsoft Dokumentation gibt hier den entscheidenden Hinweis:

Um dieses Verhalten zu überprüfen habe ich in meiner Testumgebung zwei CMGs über den Classic Cloud Service installiert. Wirft man einen Blick auf die Ribbon Bar des CMG mit Dienstname ".cloudapp.net" stellt man fest, dass es wie im Hinweis von Microsoft geschrieben, keine Möglichkeit einer direkten Konvertierung für solche Maschinen gibt.

Auf dem CMG mit Custom Domain ".bgu.nwc-labs.de" hingegen, kann eine direkte Konvertierung durchgeführt werden.

Es empfiehlt sich also durchaus darüber nachzudenken zukünftig einen Custom Domain Name für die Bereitstellung zu verwenden. (Sofern möglich)

Migration/Austausch eines bestehenden CMG 

Bei der Migration oder Konvertierung kommt es also stark darauf an, mit welchem Namen das alte CMG installiert wurde. Da sich die Konvertierung eines bestehenden CMG mit Custom Domain Name über den mitgelieferten Wizard ausgesprochen einfach gestaltet, möchte ich heute vor allem auf den Fall eingehen ein CMG zu tauschen, welches nicht konvertiert werden kann. Hierfür muss zunächst ein neues CMG in einer VM Skalierungsgruppe installiert werden.

Da natürlich Änderungen an den Regionen bzw. den Domain Namen bei Microsoft auch in Zukunft nicht ausgeschlossen sind empfiehlt sich, wie bereits weiter oben erwähnt, an dieser Stelle die Umstellung auf einen Custom Domain Name. Hierfür wird ein entsprechendes Zertifikat benötigt, welches auf den gewünschten Namen zeigen muss. Wie im Screenshot zu sehen ist und wie ebenfalls weiter oben im Microsoft Hinweis erwähnt wurde, muss nun ein CNAME Alias am externen DNS eingetragen werden der vom gewünschten Namen "xxx.bgu.nwc-labs.de" auf den bei Microsoft verwendeten Namen "xxx.westeurope.cloudapp.azure.com" zeigt.

Nach der erfolgreichen Installation des CMG sollte sich folgendes Bild ergeben.

Spätestens jetzt wird sich dem ein oder anderen Leser die Frage stellen, warum zum einen des zweite CMG parallel installiert wurde und was nun mit den Clients geschieht, die ggf. nur via Internet mit der Umgebung kommunizieren. Um den Clients mitzuteilen, dass ein zweites CMG existiert, muss diese Information zunächst über das bereits existierende CMG "gepushed" werden. (Clients die direkt bzw. on-prem kommunizieren sind hiervon natürlich nicht betroffen.)

Um dies zu erreichen muss nun ein weiterer CMG Connection Point auf einem separaten Site System installiert werden und auf das neue CMG zeigen.

Nach einiger Zeit ist an einem via Internet angebundenen Client zu sehen, dass dieser nun potenziell mit beiden CMGs kommunizieren kann.

Nachdem sich die Internet Clients diese Informationen gezogen haben, kann das alte CMG bedenkenlos aus der Umgebung entfernt werden. Ein erneuter Blick ins Configuration Manager Applet verrät ebenfalls, welches CMG gerade verwendet wird.

Als abschließende Maßnahme bleibt zu bedenken, dass bei existierenden Apps in Intune, welche den MEMCM Agent installieren, die Command-Line aktualisiert werden muss um das neue CMG per default verwenden zu können. Dies muss spätestens nach entfernen des alten CMG passieren um neue Clients nicht mit Falschinformationen zu versorgen.