Apple MDM-Migration: Ein Leitfaden für IT-Administratoren

Der Wechsel des MDM-Anbieters bei Hunderten oder Tausenden von Apple-Geräten im produktiven Einsatz ist eines der betrieblich komplexesten Projekte, die ein IT-Team bewältigen muss. Die native Migrationsfunktion von Apples OS 26 verändert die Situation erheblich, doch eine reibungslose Migration erfordert nach wie vor sorgfältige Planung, Konfigurationsdokumentation und einen soliden Validierungsworkflow nach der Migration.

Dieser Leitfaden deckt alles ab, von der Bestandsaufnahme vor der Migration bis hin zur Überprüfung der Compliance nach der Migration, wobei ein besonderer Schwerpunkt auf den Szenarien liegt, die den meisten Teams Schwierigkeiten bereiten: die Erhaltung von App-Daten, die Synchronisierung von FileVault-Wiederherstellungsschlüsseln und die Verwaltung von Geräten, die nicht für den neuen Migrationspfad unter OS 26 in Frage kommen.

Was sich bei der MDM-Migration unter Apple OS 26 geändert hat

Vor OS 26 bedeutete die Migration überwachter Apple-Geräte zwischen MDM-Lösungen fast immer ein Zurücksetzen auf die Werkseinstellungen, eine erneute Registrierung und die Neuinstallation jeder verwalteten App. Bei einer Flotte von 500 MacBooks ist das ein mehrwöchiges Projekt, das jeden Nutzer betrifft.

Apples OS 26 führt einen nativen Migrationsablauf ein, der über Apple Business (ehemals Apple Business Manager/ASM) verwaltet wird. Der Mechanismus funktioniert wie folgt:

1. Ein Administrator ordnet Geräte direkt in Apple Business von einem MDM-Server einem anderen zu.

2. Der Quell-MDM-Server sendet eine Migrationsbenachrichtigung an die registrierten Geräte.

3. Die Nutzer erhalten eine Aufforderung mit einer konfigurierbaren Frist, um die Umstellung abzuschließen.

4. Das Gerät wird automatisch vom Quell-MDM abgemeldet und beim Ziel-MDM angemeldet, ohne dass die Daten auf dem Gerät gelöscht werden.

Für Apple-Geräteverwaltungsteams, die vollständig über Apple Business mit ADE-registrierten Geräten arbeiten, ist dies eine bahnbrechende Neuerung. Die wichtigste Einschränkung: Sowohl der Quell- als auch der Ziel-MDM-Server müssen die OS 26-Migrations-API unterstützen, und auf den Geräten muss OS 26 oder höher installiert sein.

Geräte und Szenarien, die von der OS 26-Migration nicht abgedeckt werden:

• Geräte mit iOS/iPadOS/macOS unter OS 26 (diese erfordern weiterhin eine Abmeldung und manuelle Neuregistrierung oder eine Löschung)
• Bereitstellungen mit gemeinsam genutzten iPads
• Geräte, die bei Apple Business Essentials registriert sind
• Geräte, die nicht in Apple Business oder Apple School Manager registriert sind
• Vom Benutzer registrierte (BYOD-)Geräte, für die ein separater Prozess gilt

Wenn Ihr Gerätebestand einen nennenswerten Anteil an Geräten mit einer Version unter OS 26 umfasst, planen Sie einen parallelen Migrationspfad ein. Lassen Sie sich nicht von den Schlagworten täuschen – eine Umgebung mit gemischten Betriebssystemen erfordert einen gemischten Ansatz. Wenn Sie BYOD-Geräte neben firmeneigener Hardware verwalten, benötigen diese eine völlig eigene Migrationsplanung.

Planung vor der Migration: Was Sie dokumentieren sollten, bevor Sie irgendetwas anfassen

Die häufigste Ursache für eine mühsame MDM-Migration ist nicht die Migration selbst. Es ist die mangelhafte Dokumentation dessen, was das Quell-MDM tatsächlich tut. Bevor Sie irgendetwas in Apple Business oder Ihrem Ziel-MDM einleiten, exportieren und dokumentieren Sie Folgendes:

Konfigurationsprofile

• Exportieren Sie jedes Konfigurationsprofil aus dem Quell-MDM, einschließlich Payload-Typ, Geltungsbereich und etwaiger gerätespezifischer Ausnahmen.
• Kennzeichnen Sie Profile, die sicherheitsrelevante Einstellungen verwalten: FileVault, Bildschirmsperre, Firewall, Zertifikatsvertrauen und Inhaltsfilterung.
• Notieren Sie, welche Profile vom MDM bereitgestellt wurden und welche manuell installiert wurden. Manuell installierte Profile werden nicht automatisch migriert und können möglicherweise ohne Benutzereingriff nicht erneut bereitgestellt werden.

App-Bestandsaufnahme und VPP-/„Apps and Books“-Zuweisung

• Rufen Sie eine vollständige Liste der verwalteten Apps ab, einschließlich der über „Apps und Bücher“ zugewiesenen App-Store-Apps sowie aller benutzerdefinierten oder Unternehmens-Apps, die über MDM sideloaded wurden.
• Dokumentieren Sie, welche Apps Geräten und welche Benutzern zugewiesen sind.
• Stellen Sie sicher, dass Ihr „Apps and Books“-Token Ihrem Apple Business-Konto zugeordnet ist und nicht fest an den ursprünglichen MDM-Anbieter gebunden ist. Sie müssen das Token im Ziel-MDM widerrufen und erneut einladen.

Registrierungs- und Überwachungsstatus

Dokumentieren Sie für jedes Gerät:

• Registrierungstyp (ADE/Benutzerregistrierung/manuell)
• Überwachungsstatus
• Betriebssystemversion
• Seriennummer und Registrierungsstatus bei Apple Business

Dies ist auch ein guter Zeitpunkt, um Ihren MDM-Gerätebestand mit Ihren Aufzeichnungen zur Hardware-Bestandsverwaltung abzugleichen. Geräte, die in einem System erscheinen, im anderen jedoch nicht, sind ein Problem, das vor der Migration und nicht erst danach gelöst werden muss.

Sicherheitsrichtlinien

Ordnen Sie Ihre aktuellen Konfigurationsprofile den von ihnen durchgesetzten Sicherheitskontrollen zu. Wenn Ihr Unternehmen die CIS-Benchmarks für macOS oder die Empfehlungen des NIST SP 800-179 befolgt, dokumentieren Sie, welche Profile welcher Kontrolle entsprechen. Sie benötigen diese Zuordnung, um Ihre Sicherheitslage im Ziel-MDM nach der Migration zu überprüfen.

Einrichtung des Ziel-MDM vor dem Tag der Migration

Das Ziel-MDM sollte vollständig konfiguriert und getestet sein, bevor auch nur ein einziges Produktionsgerät migriert wird. Eine Migration in ein unvorbereitetes MDM führt dazu, dass Geräte zwar registriert, aber nicht verwaltet werden.

Erforderliche Konfiguration im Ziel-MDM

Apple Push Notification Service (APNs)-Zertifikat: APNs-Zertifikate sind herstellerspezifisch. Das APNs-Zertifikat Ihres Quell-MDM kann nicht übertragen werden. Erstellen Sie über das Apple Push Certificates Portal mit der Apple-ID Ihrer Organisation ein neues Zertifikat und laden Sie es anschließend in das Ziel-MDM hoch. Das Zertifikat muss jährlich erneuert werden; dokumentieren Sie daher das Ablaufdatum und die verwendete Apple-ID.

ADE-/Automated Device Enrollment-Integration: Weisen Sie in Apple Business das Ziel-MDM als Server für die zu migrierenden Geräte zu. Dieser Schritt richtet den Migrationsablauf für OS 26 ein. Geräte, die dem neuen MDM-Server zugewiesen sind, erhalten die Migrationsaufforderung, sobald Ihr Quell-MDM diese auslöst.

Konfiguration der PreStage-Registrierung: Konfigurieren Sie im Ziel-MDM Ihr PreStage-Profil (oder ein gleichwertiges Registrierungsprofil), bevor die Geräte eintreffen. Dazu gehören:

• Konfiguration des „Setup Assistant“-Fensters
• Erste Profilzuweisungen
• Einstellungen für die Installation von MDM-Profilen

Apps- und Bücher-Token: Widerrufen Sie das Token im Quell-MDM und laden Sie es erneut zum Ziel-MDM ein. Beachten Sie, dass durch das Widerrufen des Tokens im Quell-MDM die Möglichkeit, neue VPP-App-Zuweisungen von diesem System aus zu übertragen, sofort entfällt; stimmen Sie diesen Zeitpunkt daher mit Ihrem Migrationszeitfenster ab.

Konfigurationsprofile: Erstellen Sie alle erforderlichen Konfigurationsprofile im Ziel-MDM neu. Kopieren Sie nicht einfach die Profilarchitektur des alten MDM eins zu eins. Nutzen Sie die Migration als Gelegenheit, Ihre Richtlinienstruktur zu straffen. In älteren MDM-Umgebungen sammeln sich oft über Jahre hinweg überlappende, widersprüchliche oder redundante Profile an. Eine Migration ist ein natürlicher Anstoß, dies zu bereinigen.

Durchführung der Migration: Der OS 26-Ablauf Schritt für Schritt

Nachdem das Ziel-MDM konfiguriert und die Geräte in Apple Business zugewiesen wurden, sieht der Ablauf wie folgt aus:

1. Starten Sie die Migration vom Quell-MDM. Das Quell-MDM sendet einen MDM-Befehl an die registrierten Geräte, um die Migration anzukündigen. Der genaue Mechanismus variiert je nach Anbieter, das Ergebnis ist jedoch dasselbe: Auf dem Gerät erscheint eine Benachrichtigung.

2. Die Benutzer erhalten eine Aufforderung zur Migration. Die OS 26-Migration von Apple umfasst eine konfigurierbare Registrierungsfrist. Sie können eine Nachfrist festlegen (üblicherweise 24–72 Stunden für verwaltete Unternehmensgeräte), nach deren Ablauf das Gerät die Migration automatisch durchführt. Informieren Sie die Benutzer, bevor die Aufforderung erscheint. Ein unerklärter Systemdialog, der zur Änderung der Geräteverwaltung auffordert, führt zu Supportanfragen.

3. Das Gerät meldet sich vom Quell-MDM ab. Das Gerät entfernt das Verwaltungsprofil des Quell-MDM sowie alle von diesem MDM bereitgestellten Konfigurationsprofile.

4. Das Gerät registriert sich beim Ziel-MDM. Das Gerät stellt eine Verbindung zu den Apple-Servern her, ruft das zugewiesene Registrierungsprofil für das Ziel-MDM ab und schließt die Registrierung ab.

5. Das Ziel-MDM stellt Konfigurationsprofile und Apps bereit. Das Gerät empfängt die ihm zugewiesenen Profile und beginnt mit der Installation der verwalteten Apps. Die Geräte werden nicht gelöscht. Benutzerdaten, lokal installierte Apps und Einstellungen, die nicht mit der vom MDM bereitgestellten Konfiguration in Zusammenhang stehen, bleiben erhalten.

Hinweis zur Beibehaltung von Apps: Verwaltete Apps, die über „Apps und Bücher“ zugewiesen wurden, bleiben bei der Migration auf OS 26 erhalten, wenn das Ziel-MDM so konfiguriert ist, dass es die Verwaltung dieser Apps beansprucht. Wenn das Ziel-MDM die Apps nicht beansprucht, wechseln sie möglicherweise vom Status „verwaltet“ in den Status „unverwaltet“, was Auswirkungen auf die Daten verwalteter Apps und das Verhalten beim selektiven Löschen hat. Überprüfen Sie vor der Migration die Konfiguration der App-Verwaltungsansprüche Ihres Ziel-MDM.

Kontinuität bei FileVault und Sicherheitskonfiguration

FileVault-Wiederherstellungsschlüssel werden vom Quell-MDM gespeichert. Wenn ein Mac zum Ziel-MDM migriert, verliert das Quell-MDM seine Verwaltungsverbindung, und der dort gespeicherte Wiederherstellungsschlüssel wird verwaist.

So gewährleisten Sie die Kontinuität des FileVault-Wiederherstellungsschlüssels:

• Nach der Migration sollte das Ziel-MDM einen Befehl zur Rotation des FileVault-Wiederherstellungsschlüssels ausführen. Dadurch wird ein neuer Wiederherstellungsschlüssel generiert und beim Ziel-MDM hinterlegt.
• Bis diese Rotation erfolgt, ist der zuvor im Quell-MDM gespeicherte Schlüssel für die Wiederherstellung weiterhin gültig, wird jedoch nicht mehr verwaltet.
• Priorisieren Sie Macs mit aktiviertem FileVault in Ihrer Checkliste zur Migrationsvalidierung. Vergewissern Sie sich, dass der neue Wiederherstellungsschlüssel für jedes Gerät im Ziel-MDM hinterlegt ist.

Überprüfen Sie für andere Sicherheitskonfigurationen nach der Migration Folgendes im Ziel-MDM:

• Durchsetzung der Richtlinien für Bildschirmsperre und Passwort
• Firewall-Status
• Status des Systemintegritätsschutzes (SIP) auf Intel-Macs
• Gatekeeper-Konfiguration
• Zertifikatsvertrauensprofile

Wenn Ihr Unternehmen ein Compliance-Rahmenwerk befolgt, ist dies der richtige Zeitpunkt, um für jedes Gerät eine Compliance-Prüfung durchzuführen. Das Verständnis von Geräteverwaltung und Sicherheit als integrierte Disziplin statt als getrennte Arbeitsbereiche ermöglicht eine systematischere Validierung nach der Migration.

Migrationsstrategien für Geräte mit Betriebssystemversionen unter 26

Für Geräte mit iOS/iPadOS oder macOS unter Version 26 stehen Ihnen drei Vorgehensweisen zur Verfügung:

Option 1: Aktualisieren Sie auf OS 26 und führen Sie anschließend die Migration durch. Wenn das Gerät OS 26 unterstützt, übertragen Sie das Update über das Quell-MDM, bevor Sie die Migration starten. Dies ist der einfachste Weg für kompatible Hardware.

Option 2: Abmeldung vom Quell-MDM, erneute Anmeldung beim Ziel-MDM. Bei ADE-registrierten Geräten können Sie die Registrierung beim Quell-MDM aufheben; das Gerät registriert sich dann entsprechend seiner Apple Business-Zuweisung automatisch beim Ziel-MDM neu. Dies erfordert keine Löschung, allerdings muss der Benutzer die Schritte des Einrichtungsassistenten durchführen, sofern Sie diese nicht so konfiguriert haben, dass sie übersprungen werden.

Option 3: Auf Werkseinstellungen zurücksetzen und neu registrieren. Für Geräte, die nicht bei „Apple Business“ registriert sind, oder für Geräte mit komplexen lokalen Konfigurationen, die gelöscht werden müssen, ist ein Löschen und eine Neuregistrierung die sauberste Option. Diese Option erfordert die größte Koordination mit den Endnutzern.

Dokumentieren Sie bereits frühzeitig in der Planungsphase die Verteilung der Betriebssystemversionen in Ihrem Gerätepark. Wenn 30 % Ihrer Macs unter macOS Sequoia laufen und nicht für OS 26 qualifiziert sind, ist dies ein wesentlicher operativer Aspekt, der separat geplant werden muss.

Planung von Rollbacks und Notfallmaßnahmen

Die meisten Migrationsanleitungen überspringen diesen Abschnitt. Tun Sie das nicht.

Legen Sie vor Beginn einer Produktionsmigration Ihren Rollback-Schwellenwert fest: Ab welchem Punkt unterbrechen oder kehren Sie die Migration um? Häufige Auslöser sind:

• Mehr als X % der migrierten Geräte erhalten innerhalb von Y Stunden keine Konfigurationsprofile
• Der Verlust verwalteter Apps überschreitet einen festgelegten Schwellenwert
• Meldungen über Lücken bei FileVault-Wiederherstellungsschlüsseln, die einen festgelegten Prozentsatz überschreiten
• Die Bereitstellung von Sicherheitstools (EDR, Endgeräteschutz) kann auf migrierten Geräten nicht installiert werden

Ein Rollback für den OS 26-Migrationsablauf bedeutet, dass Geräte in Apple Business wieder dem ursprünglichen MDM-Server zugewiesen werden und eine Rückmigration ausgelöst wird. Dies ist technisch möglich, setzt jedoch voraus, dass der ursprüngliche MDM-Server noch aktiv und lizenziert ist. Kündigen Sie Ihren Quell-MDM-Vertrag erst, wenn Sie eine erfolgreiche Migration bestätigt und die Validierung nach der Migration für die gesamte Geräteflotte abgeschlossen haben.

Bei großen Geräteflotten ist eine schrittweise Einführung gängige Praxis: Migrieren Sie zunächst eine Pilotgruppe von 10–20 Geräten aus einem nicht kritischen Team, führen Sie eine gründliche Validierung durch und fahren Sie dann in Chargen fort. Für jede Charge sollte ein Validierungskontrollpunkt vorgesehen sein, bevor die nächste Charge beginnt.

Validierung nach der Migration und Überprüfung der Compliance

Die Validierung nach der Migration ist ein Bereich, in den viele Teams zu wenig investieren. Ein Gerät, das im Ziel-MDM als registriert erscheint, ist nicht unbedingt konform. Überprüfen Sie bei Ihren migrierten Geräten jeweils Folgendes:

• Konfigurationsprofile wurden bereitgestellt und angewendet (abgefragt über die installierten Profile auf dem Gerät)
• Verwaltete Apps sind installiert und befinden sich im verwalteten Zustand
• FileVault-Wiederherstellungsschlüssel im Ziel-MDM hinterlegt
• Sicherheitstools (EDR-Agent, Endgeräteschutz) sind installiert und melden Daten
• Gerät entspricht allen erforderlichen Richtlinien
• Zertifikatprofile sind installiert und gültig

Erstellen Sie daraus eine formelle Validierungscheckliste und führen Sie diese für jeden Migrationsstapel durch, bevor Sie diesen als abgeschlossen markieren. Wenn Ihr Ziel-MDM über ein Compliance-Dashboard oder eine Berichtsansicht verfügt, nutzen Sie diese. Geräte, die als registriert, aber nicht konform angezeigt werden, erfordern sofortige Nachverfolgung.

Wie Iru die Apple-MDM-Migration angeht

Eine Migration ist oft der Moment, in dem Teams ihre gesamte Richtlinienarchitektur überdenken – nicht nur ihren MDM-Anbieter. Iru basiert auf einem Konzept namens „Assignment Maps“, mit dem Sie eine strukturierte Richtlinienhierarchie definieren können, die Geräte- und Benutzerattribute Konfigurationssätzen zuordnet. Bei der Migration von einem älteren MDM-System ist dies besonders nützlich, da es eine bewusste Richtliniengestaltung erzwingt, anstatt eine 1:1-Nachbildung dessen, was sich im alten System über Jahre hinweg angesammelt hat.

Speziell für die App-Bereitstellung ist die automatische App-Bereitstellung von Iru so konfiguriert, dass verwaltete Apps bereitgestellt werden, bevor der Befehl „DeviceConfigured“ abgeschlossen ist. Das bedeutet, dass Geräte, die den Migrationsablauf für OS 26 durchlaufen, ihre Apps im Rahmen der anfänglichen Registrierungssequenz erhalten und nicht als Hintergrundprozess, den Nutzer möglicherweise als Lücke wahrnehmen würden.

Iru stellt für die ADE-Integration und die APNs-Verwaltung eine direkte Verbindung zu Apple Business her, wodurch der Migrationsablauf unkompliziert bleibt. Sie weisen Geräte im Apple Business dem Iru-MDM-Server zu, konfigurieren Ihre Registrierungsprofile und Zuordnungskarten, und die Migration verläuft über den Standardablauf von Apple.

Zur Überprüfung des Sicherheitsstatus nach der Migration enthält die Compliance-Bibliothek von Iru vorgefertigte Elemente, die den CIS-Benchmarks für macOS und gängigen NIST-Kontrollen zugeordnet sind. Nach der Migration können Sie einen Compliance-Bericht für Ihren gesamten Gerätebestand erstellen und sofort erkennen, welche Geräte Korrekturmaßnahmen erfordern, anstatt diese Zuordnung von Grund auf neu erstellen zu müssen.

Für Teams, die von komplexen Legacy-Plattformen migrieren, ist die Benutzeroberfläche von Iru genau auf die tatsächliche Funktionsweise der Verwaltungsframeworks von Apple zugeschnitten. Dies verkürzt die Einarbeitungszeit für Administratoren, die jahrelang mit den Abstraktionen anderer Tools gearbeitet haben.

So machen Sie Ihre Apple-MDM-Migration zu einem Erfolg

Eine Apple-MDM-Migration ist per Definition mit Umbrüchen verbunden. Die Teams, die daraus am besten hervorgehen, betrachten sie als gezielte Neugestaltung ihrer Verwaltungsarchitektur und nicht nur als einfachen Anbieterwechsel. Das bedeutet, dass Sie Ihre Profilstruktur rationalisieren, Ihre Sicherheitsgrundlagen anhand eines echten Frameworks überprüfen und sicherstellen müssen, dass jedes Gerät tatsächlich konform ist, bevor Sie das Projekt als abgeschlossen erklären.

Die native Migrationsfunktion von OS 26 macht bei geeigneten Geräten ein Zurücksetzen auf die Werkseinstellungen überflüssig, wodurch die größte Störung für die Nutzer beseitigt wird. Die Planungsarbeit, die Dokumentation vor der Migration und die Validierung nach der Migration bleiben jedoch unabhängig vom Migrationspfad unverzichtbar.

Wenn Ihr Team einen Wechsel zu Iru in Erwägung zieht oder eine Migration von einem anderen Apple-MDM-Anbieter plant, fordern Sie eine Demo an, um zu sehen, wie „Assignment Maps“ und die Apple-native Architektur von Iru sowohl die Migration als auch die anschließende laufende Verwaltung vereinfachen können.