Vor kurzem bin ich bei der Installation eines neuen CMG über ein Problem beim Verbindungsaufbau eines neuen Site System Server mit installierter CMG Connection Point Rolle und dem zugehörigen CMG gestoßen. Das CMG wurde laut Konsole erfolgreich installiert, allerdings blieb der Connection Status des Connection Point Servers auch nach einiger Wartezeit mit Status "Getrennt" stehen. 

Ein erster Blick in das für die Verbindung zuständige Log File (SMS_CLOUD_PROXYCONNECTOR.log) lieferte den Hinweis, dass das entsprechende Zertifikat der Rolle nicht vorhanden war.

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.

For an english version please scroll down... ;-)

Durch den Anruf eines alten Bekannten und weil dieses Thema offensichtlich genau den Nerv der heutigen Zeit trifft, möchte ich meine kleine Exkursion in die Welt der CSPs fortsetzen und noch ein bisschen tiefer gehen. Bei dem besagten Anruf bin ich gefragt worden, ob es nicht eine Möglichkeit gibt, CSPs auch ohne Intune und Configuration Profiles nutzen bzw. setzen zu können. Schließlich sind diese ja Bestandteil von Windows 10/11 und bieten durchaus auch Abseits von Intune ein gewisses Potential.

Also gilt zunächst zu klären ob diese wirklich nur auf Intune beschränkt sind, was mit einem eindeutigen "Nein" beantwortet werden kann. Wie bereits in meinem ersten CSP Artikel beschrieben, handelt es sich hierbei lediglich um eine Schnittstelle die auch von anderen MDM Plattformen wie z.B. MobileIron (welches seit Dezember 2020 zur Ivanti Familie gehört) genutzt werden kann.

In meinem heutigen Artikel möchte ich zeigen, wie das Ansprechen und Verwenden von CSPs via WMI und PowerShell lokal am Client betrieben werden kann.

Mit der Veröffentlichung von DSM 2022.1 wurde auch der neue Microsoft Intune Konnektor veröffentlicht. Dieser Konnektor, welcher mittels Azure App Registration über die Graph API mit Intune kommuniziert, ermöglicht unter anderem einen direkten Upload des DSM Agents zur Verteilung via Intune.

Prinzipiell bietet dieser Konnektor natürlich vor allem für hybride Client Management Ansätze ein sehr großes Potenzial. Da sich der Funktionsumfang der Seitens Ivanti zum aktuellen Zeitpunkt mitgeliefert wird jedoch noch in Grenzen hält, möchte ich heute zeigen wie Sie sich mit wenig Aufwand und DSM Bordmitteln auch jetzt bereits interessante Infos aus der Cloud in Ihre DSM Umgebung syncen können.

Aber was wäre denn interessant zu wissen? Ob es sich bei einem Client um ein AAD-Only oder ein Hybrid-Joined Gerät handelt? Oder vielleicht die Geräte-ID aus Intune? Kurz gesagt, eine Art "DSM Basis Inventarisierung" für Intune wäre doch toll.

Wie bereits in meinem letzten Blog zum Thema Configuration Service Provider (CSP) angeschnitten, verwenden Microsoft Intune Custom Configuration Profiles sogenannte OMA-URI-Einstellungen. OMA-URI steht in diesem Fall für "Open Mobile Alliance Uniform Resource Identifier" und könnte vereinfacht gesagt auch als Pfad zu einer bestimmten CSP Konfiguration oder Einstellung bezeichnet werden.

Heute möchte ich etwas genauer auf den Aufbau und die Verwendung von OMA-URI eingehen. Sehen wir uns hierfür zunächst einmal den Kommunikationsweg an.

Wie ebenfalls im oben verlinkten Artikel erwähnt, verwendet Microsoft für die Kommunikation "SyncML" und "OMA DM". Die Intune Policy wird hierbei in einer Art XML Format via OMA DM auf den Client übertragen und zeigt dort auf einen CSP, der wiederum mit einer Datei oder einem RegKey verbunden ist. Die folgende Grafik aus der entsprechenden Microsoft Referenz (https://docs.microsoft.com/de-de/troubleshoot/mem/intune/deploy-oma-uris-to-target-csp-via-intune) soll dies veranschaulichen. 

 Nach mehreren erfolgreichen Jahren im Home Office und der Tatsache, dass uns dieses nicht mehr komplett verlassen wird, kommen auf viele Kunden ganz neue Herausforderungen bzgl. der Verwaltung ihrer Clients zu. Da ich diesbezüglich sehr viele Fragen von Kunden auch abseits der klassischen Softwareverteilung erhalte, möchte ich in diesem Artikel speziell auf die Frage nach GPOs in einer Cloud-Welt und wie man seine bestehenden On-Premises GPOs am sinnvollsten Richtung Microsoft Intune migrieren kann eingehen.

Doch sehen wir uns zunächst noch einmal etwas genauer an welche Vor- und Nachteile beide Welten mit sich bringen.

Da ich bereits in mehreren Kundenprojekten gefragt wurde wie man nun über die MEMCM Konsole am besten herausfinden kann welcher Client gerade über das CMG mit der Umgebung kommuniziert und da diese Information etwas versteckt zu finden ist, möchte ich in diesem Artikel kurz zwei Möglichkeiten aufzeigen wie diese Anforderung realisiert werden kann.

Die aktuelle Corona-Situation zwingt immer mehr Menschen ins Home Office und damit natürlich auch in die ein oder andere Videokonferenz. Bei einigen mag das "Home Office" vielleicht gar nicht mal in einem eigenen Büro sondern am Esstisch, Küche oder Wohnzimmertisch sein. Da kommt sehr schnell der Wunsch nach ein bisschen Professionalität bei Terminen mit Kunden oder Kollegen.

Aus diesem Grund gibt es seit letzter Woche nun auch in Microsoft Teams die Möglichkeit, neben dem bisher bekannten "Weichzeichnen", den Hintergrund durch mitgelieferte Bilder komplett zu ersetzen. Ebenfalls besteht die Möglichkeit die Auswahl der Bilder durch eigene zu Erweitern. Da diese Funktion jedoch nicht ganz intuitiv über die GUI lösbar ist, möchte ich hier kurz zeigen wie Sie eigene Bilder in Microsoft Teams einfügen können. 

Eines der mit Sicherheit spannendsten Features in SCCM 1906 ist das "Install Application" Feature mit dem der Administrator in der Lage ist, Software adhoc auf einem Gerät zu installieren. In diesem Beitrag möchte ich das neue Feature kurz etwas genauer beleuchten und starte zunächst mit den Voraussetzungen.

Die erste Voraussetzung ist sicherlich eine aktualisierte SCCM Umgebung mit Version 1906. Allerdings gibt es noch weitere Bedingungen die erfüllt sein müssen, bevor eine Applikation auf ein Gerät gepusht werden kann.