Guten Tag,% Benutzername%!
In jedem großen Unternehmen (und nicht nur in einem großen) möchten die Mitarbeiter jederzeit und so einfach wie möglich Zugriff auf Unternehmensinformationen (Arbeitspost, Kalender, interne Ressourcen) haben. Für die Bereitstellung und Verwaltung dieser Zugriffe wurden separate Lösungen namens Mobile Device Management erstellt.
In der Vergangenheit haben wir in unserem Unternehmen verschiedene Lösungen für die Verwaltung mobiler Geräte verwendet. Zuerst war es eine auf einen bestimmten Hersteller zugeschnittene Lösung, dann wechselten wir zu einem anderen Produkt, mit dem wir sowohl iOS- als auch Android-Geräte unterstützen konnten. Anschließend wurde beschlossen, auf eine Lösung von Microsoft umzusteigen.
Microsoft intune
Zum Zeitpunkt der Analyse der Lösungsfunktionalität enthielt die Cloud-Version eine relativ kleine Liste von Funktionen, sodass beschlossen wurde, Intune Hybrid zu verwenden.
Was ist ein Intune Hybrid?
Dies ist der gute alte System Center Configuration Manager, der in Microsoft Intune integriert ist. Diese Lösung hat ihre eigenen Eigenschaften:
- Die gesamte Verwaltung mobiler Geräte erfolgt über SCCM.
- Alle Sicherheitsrichtlinien und -konfigurationen werden über SCCM erstellt und verwaltet.
Im Großen und Ganzen unterscheidet sich die Verwaltung mobiler Geräte nicht von der Verwaltung von Arbeitsstationen. Der Cloud-Teil wird nur für die Kommunikation zwischen Geräten und SCCM verwendet.
Zusammen mit der Entscheidung, zu MS Intune zu wechseln, wurde es notwendig, alle Benutzer auf die neue Plattform zu übertragen. Leider hatten wir nur 5 Monate Zeit für die Migration und 28.000 Benutzer weltweit.
Für den Anfang wurde der am wenigsten zerstörerische Ansatz für die Migration verwendet, und den Benutzern wurde empfohlen, Geräte für die Arbeit mit dem neuen Dienst neu zu konfigurieren.
Dieser Ansatz funktionierte zu einem bestimmten Zeitpunkt nicht mehr und die Benutzer wurden gezwungen, die Verbindung zum vorherigen Dienst zu trennen, da die Möglichkeit zur Konfiguration des Geräts parallel blockiert wurde. Dies führte zu bestimmten Schwierigkeiten und einer zusätzlichen Belastung des Desktop-Dienstes. Die Grafik der offenen Vorfälle im Dienst mobiler Geräte zeigt deutlich den Zeitraum der aktivsten Migration.
Glücklicherweise war der Übergang erfolgreich - pünktlich und ohne unerwartete Probleme.
Wie ist das Leben auf dem Mars mit Microsoft Intune?
Während der Migration war es für alle Supportteams ziemlich schwierig, sich anzupassen, da die Funktionen zum Verwalten mobiler Geräte viel umfassender und bequemer waren als in SCCM. Nachdem wir jedoch einige Funktionen geopfert haben, haben wir eine deutlich höhere Stabilität des Dienstes und weniger Vorfälle im Allgemeinen. Zum Vergleich: Mit der vorherigen Lösung für 28.000 Benutzer hatten wir ungefähr 700 Vorfälle pro Monat, aber jetzt wird das Niveau bei ± 350 Vorfällen gehalten.
Mit den neuen SCCM-Versionen fügt Microsoft neue Funktionen hinzu, und ich hoffe, dass weiterhin in eine Hybridlösung investiert wird.
Was ist neuDie Migration auf das neue Produkt bot auch neue Funktionen für die Zugriffskontrolle, da Intune nur ein Teil des Enterprise Mobility + Security-Dienstes ist. Die wichtigsten und interessantesten Funktionen für uns sind der
bedingte Zugriff und das
Management mobiler Anwendungen .
Der bedingte Zugriff ist eine Richtlinie zur Dienstzugriffskontrolle. Angenommen, ein Benutzer möchte eine Verbindung von einem persönlichen Telefon zu Exchange Online herstellen. Für die Zugriffsrichtlinie muss auf Ihrem Gerät Microsoft Intune ausgeführt werden, um auf EXO zugreifen zu können. Wenn dieser Benutzer versucht, das Postfach über die Standard-Mail-Anwendung unter iOS zu konfigurieren, wird nur eine Meldung angezeigt: "Der Administrator verlangt, dass das Gerät über Microsoft Intune gesteuert wird." Ebenso können Sie den Zugriff auf jede in Azure AD registrierte Anwendung steuern.
Mobile Application Management ist die Verwaltung von Unternehmensdaten innerhalb der Anwendung. Diese Einstellung bestimmt, ob es möglich ist, Arbeitsdokumente im Telefonspeicher zu speichern, in Anwendungen von Drittanbietern zu kopieren usw.
Beide Funktionen ermöglichen eine flexible und schmerzlose Benutzerkonfiguration der Sicherheitseinstellungen.
Migration zu Intune Standalone
Nachdem wir uns für neue Lösungen von Microsoft interessiert hatten, insbesondere für Co-Management und Autopilot, stellten wir fest, dass es notwendig war, auf eine vollständig Cloud-basierte Lösung (die sogenannte Intune Standalone) umzusteigen.
Zum Zeitpunkt der Entscheidung hatte Microsoft bereits schrittweise Anweisungen zur Migration von Benutzern von SCCM zu Intune Standalone veröffentlicht:
- Exportieren Sie Konfigurationen aus SCCM und importieren Sie sie in Intune.
- Migration von Testbenutzern.
- Migration aller Benutzer.
- Wechseln Sie die MDM-Berechtigung von SCCM zu Intune.
In der Export- / Importphase wurde eine
Lösung von Microsoft selbst verwendet . Leider verlief der Import nicht sehr gut und nicht nur bestimmte Anwendungen wurden aus SCCM migriert, sondern alle Bereitstellungstypen, wodurch separate Anwendungen in Intune erstellt wurden.
Es sah ungefähr so aus:
Darüber hinaus wurde aus irgendeinem Grund die Anwendungsversion auch nicht korrekt importiert, und aus diesem Grund mussten alle Anwendungen manuell veröffentlicht werden. Mit dieser Konfiguration und Richtlinien wurden ohne Probleme migriert.
TestgruppenmigrationDie Testgruppe bestand zunächst aus meinen Kollegen und mir. Wir hatten Angst, dass Benutzer bemerken, dass sie migrieren. Dies könnte eine Welle von Anrufen beim Desktop-Dienst hervorrufen. Tests haben jedoch gezeigt, dass Benutzer mangels unterschiedlicher Konfigurationen und veröffentlichter Anwendungen nichts bemerken.
Was war der Migrationsmechanismus? Der erforderliche Benutzer wurde aus der SCCM-Sammlung entfernt, die in den Intune-Abonnementeinstellungen verwendet wurde. Dies geschah durch eine exklusive Sammlung, die wiederum an eine Gruppe in Active Directory gebunden war. Um den Benutzer zu migrieren, müssen Sie ihn daher nur der erforderlichen AD-Gruppe hinzufügen.
Unerwarteterweise gab es jedoch Probleme bei der Bereitstellung des Service Desk-Zugriffs zur Verwaltung migrierter Geräte. Ich habe eine besondere Rolle geschaffen, die nur die für ihre Aufgaben erforderlichen Rechte hatte. Die Rolle wurde der erforderlichen Gruppe zugewiesen, aber für einige Personen wurde kein Zugriff angezeigt. Analystenlizenzen und ihre Konten wurden überprüft, aber alles umsonst. Das Überprüfen der effektiven Rollen über die Graph-API ergab, dass eine Rolle vorhanden ist, die Person jedoch noch keinen Zugriff hatte. Nach einer langen Untersuchung wurde zusammen mit dem Microsoft-Support festgestellt, dass für Analysten eine Lizenz (Intune in EMS E3 oder EMS E5) erforderlich ist. Außerdem müssen Analysten wiederum auf Intune Standalone migriert werden. Der Bedarf wurde nicht dokumentiert und es dauerte einige Wochen, bis er behoben war.
Gleichzeitig zog ich eine Gruppe von Vertriebsmitarbeitern aus einem europäischen Land für die Migration an, die den VPN-Dienst aktiv in ihrer täglichen Arbeit nutzen und die Migration selbst ausführen, sowie den
Server , der separat für Intune Standalone
NDES konfiguriert wurde . In diesem Schritt wurde die Migration fast abgebrochen, und alle Benutzer kehrten zurück.
Damit der Benutzer den VPN-Dienst verwenden kann, wird ihm ein Profil geliefert, mit dem der VPN-Client mithilfe des angegebenen SCEP-Zertifikats konfiguriert wird, das sich auf die Stammzertifizierungsstelle bezieht. Dementsprechend muss für den Betrieb ein Paar Zertifikate vorhanden sein.
Wir hatten nur ein Zertifikat (Stammzertifizierungsstelle).
Am einfachsten ist es anzunehmen, dass das Problem auf dem NDES-Server liegt. Aber es funktionierte perfekt und erhielt nicht einmal Anfragen nach Zertifikaten. Bei der Prüfung der Protokolle von den Geräten selbst stellte ich fest, dass das Gerät nicht einmal die erforderlichen Einstellungen zum Anfordern eines SCEP-Zertifikats erhalten hat. Microsoft hat dieses Problem an Intune-Entwickler weitergeleitet, die festgestellt haben, wie wichtig es ist, nicht nur alle Zertifikate zu haben, sondern auch, dass alle Zertifikate und Einstellungen an dieselben Benutzergruppen und Geräte gesendet werden müssen. In unserem Fall wurde die Stammzertifizierungsstelle an alle Geräte und SCEP nur an bestimmte Geräte gesendet.
Und so begannen wir mit der Migration von 1000 auf 4000 Benutzer in einer Welle. Der Vorgang dauerte 4 Wochen. Wir waren zu allem bereit (wir alle wissen, dass sehr selten alles nach Plan verläuft). Aber alles verlief reibungslos, ohne dass die Anrufe beim Desktop-Service zunahmen.
Veraltete Geräte
In Übereinstimmung mit unseren Standards streben wir die Mindestversionen von mobilen Betriebssystemen an:
· T-1 für iOS.
· T-2 für Android.
* T ist momentan die neueste Version.
In geringerem Maße gilt dies für iOS, as Apple unterstützt seine Geräte seit langem. Dies gilt eher für Android-Geräte. Beispielsweise verwenden Benutzer immer noch Android 4.4.2 auf Geräten, die älter als 4 Jahre sind.
In diesem Fall führen wir einen Dialog mit dem lokalen IT-Team, um den Zeitpunkt für den Austausch von Geräten zu bestimmen, da ein Gleichgewicht zwischen der Sicherheit und dem Geld für deren Aktualisierung gefunden werden muss.
Was weiter?
Die Änderung der Entscheidung hat zu internen Änderungen geführt. Beispielsweise gab es Skripte zum Bereinigen von SCCM von veralteten Geräten, die in PowerShell geschrieben wurden und jetzt nicht mehr verwendet werden können. In all seinen neuen Lösungen fördert Microsoft die Graph-API, die beherrscht werden muss.
Die Berichterstellung wurde bis vor kurzem auf der Grundlage von SSRS erstellt. Jetzt verwenden wir Power BI + oData Feed mit Daten aus dem Intune Data Warehouse.
Ich habe bereits Conditonal Access und Mobile Application Management erwähnt. Die erste Lösung wurde bereits implementiert, jetzt arbeiten wir an der zweiten. Wir testen Azure Application Proxy auch als Ersatz für VPN auf Mobilgeräten. Wenn es interessant ist, werde ich gerne in neuen Artikeln darüber berichten.