iOS 26: MDM-Migration ohne Factory Reset – Apple beendet den Vendor Lock-in

Apple löst eines der lästigsten Probleme in der Apple-Enterprise-Welt: Mit iOS/iPadOS/macOS 26 könnt ihr eure Geräte direkt im Apple Business Manager zwischen MDM-Lösungen verschieben – ohne Wipe, ohne Nachtschicht, ohne Drama. Fast.

Ab iOS/iPadOS/macOS 26 könnt ihr ADE-enrolled Corporate Devices direkt im ABM einem neuen MDM zuweisen – kein Factory Reset nötig. Ihr setzt eine Deadline, der User bekommt eine Notification, das Gerät enrollt sich neu. Persönliche Daten bleiben erhalten. Managed Apps auf iPhone/iPad werden entfernt und müssen vom neuen MDM neu ausgerollt werden. VPP-Lizenzen wandern nicht automatisch. Vorbereitung ist trotzdem Pflicht.

Was ist neu – und stimmt das wirklich?

In den letzten Wochen macht ein LinkedIn-Post die Runde, der das neue Feature von iOS 26 beschreibt. Kaum gelesen, weckte dieser Post mein Interesse.

Im Kern stimmt er – aber ein paar Details sind ungenau oder fehlen komplett. Ich hab das Ganze gegen die offizielle Apple-Dokumentation, Microsoft Intune Docs und mehrere MDM-Hersteller-Guides gecheckt. Hier kommt der vollständige Faktencheck.

Abb. 1: MDM-Migration bisher vs. ab iOS/iPadOS/macOS 26

Was stimmt (korrekte Claims im Umlauf)

MDM-Migration ohne Factory Reset für iOS/iPadOS/macOS 26 – korrekt
Steuerung komplett über Apple Business Manager – korrekt
Deadline-Feature mit automatischem Erzwingen – korrekt
User-Notifications mit steigender Häufigkeit – korrekt
Persönliche Daten bleiben auf dem Gerät – korrekt

Was fehlt oder ist ungenau (wichtige Details)

„Ohne Datenverlust“ ist nuanciert: Persönliche Daten bleiben, aber MDM-verwaltete Apps werden auf iPhone/iPad beim Unenrollment entfernt – außer das neue MDM liefert sie via await_device_configured rechtzeitig nach.
Nur für ADE-enrolled Corporate Devices: BYOD-Geräte sind komplett ausgeschlossen. Shared iPad und Apple Business Essentials ebenfalls nicht unterstützt.
Einmaliger Reset bei alten ABM-Einschreibungen: Geräte, die ursprünglich mit iOS < 26 in ABM eingeschrieben wurden, benötigen EINMALIG einen Reset zur Re-Registrierung. Danach nie wieder.
VPP-Lizenzen migrieren nicht automatisch: Der Apps & Books Content Token muss manuell aus dem alten MDM entfernt und im neuen registriert werden.
Vorbereitung ist Pflicht: Konfigurationsprofile, Compliance-Policies, Scripts und App-Deployments müssen im neuen MDM vorab nachgebaut werden.

Wie funktioniert das technisch?

Apple hat den nativen MDM-Protokoll-Stack erweitert. Der ABM koordiniert jetzt aktiv den Wechsel zwischen zwei MDM-Servern und kommuniziert gleichzeitig mit beiden. Das Gerät wird vom alten MDM unenrollt und enrollt sich direkt in das neue – alles gesteuert durch das OS, ohne manuellen Eingriff.

Technisch relevant: Das Feature basiert auf Declarative Device Management (DDM). Die Logik läuft direkt auf dem Gerät, wodurch die Abhängigkeit vom MDM-Server reduziert wird. Apple rotiert dabei automatisch sicherheitsrelevante Keys – z.B. den FileVault Personal Recovery Key auf macOS.

Was bleibt auf dem Gerät, was wird entfernt?

Was	iPhone/iPad	Mac
Persönliche Daten	Bleiben vollständig erhalten	Bleiben vollständig erhalten
MDM-Konfigurationsprofile	Werden entfernt	Werden entfernt
Managed Apps (MDM-deployed)	Werden entfernt (*)	Bleiben ggf. erhalten
App-Daten (bei Preservation)	Bleiben bei korrektem Setup	Bleiben bei korrektem Setup
VPP-Lizenzen	Manuell migrieren!	Manuell migrieren!
Activation Lock / Bypass Code	Wird vom neuen MDM neu erstellt	Wird vom neuen MDM neu erstellt
FileVault Key (macOS)	N/A	Wird automatisch rotiert

(*) Managed Apps können bei korrektem Setup preserviert werden: Das neue MDM muss die Apps per await_device_configured installieren, bevor DeviceConfigured gesendet wird. Declarative Managed Apps werden immer behalten.

Voraussetzungen

Bevor ihr loslegt, müssen folgende Punkte erfüllt sein:

Abb. 2: Voraussetzungen auf einen Blick

Gerät läuft auf iOS 26, iPadOS 26 oder macOS 26
Gerät ist per Automated Device Enrollment (ADE) enrolled – kein User Enrollment, kein BYOD
Gerät ist in Apple Business Manager (ABM) oder Apple School Manager (ASM) erfasst
Neues MDM ist als MDM-Server in ABM konfiguriert (Token-Austausch abgeschlossen)
APNs-Zertifikat im neuen MDM ist aktiv
VPP/Apps & Books Token für das neue MDM ist eingerichtet (falls Apps per VPP deployt werden)
Neues MDM ist vollständig vorbereitet: Profile, Policies, Apps und Scripts nachgebaut

Einschränkungen

Nicht unterstützt: Apple Business Essentials, Shared iPad, BYOD-Geräte
Return to Service mit App Preservation (is_return_to_service = TRUE) blockiert die Migration
Geräte offline nach Unenrollment: User wird zur WLAN-Auswahl geleitet, bis Migration abgeschlossen
Bei VPP-Apps: Deadline nicht größer als 30 Tage setzen

How-to: MDM-Migration mit iOS 26 – Schritt für Schritt

Phase 1: Vorbereitung (vor dem ersten Klick in ABM)

Die Migration selbst dauert Minuten – aber die Vorbereitung entscheidet über Erfolg oder Chaos. Hier solltet ihr keine Abkürzungen nehmen.

#	Aufgabe	Prio
1	Vollständiges Inventar aller Geräte exportieren – Seriennummern, OS-Version, Enrollment-Status	Pflicht
2	Alle Konfigurationsprofile dokumentieren: Wi-Fi, VPN, Zertifikate, Restrictions, E-Mail	Pflicht
3	Compliance-Policies, Security-Baselines und Scripts erfassen	Pflicht
4	App-Deployment dokumentieren: Welche Apps, VPP oder direkt, welche Managed Configs	Pflicht
5	Neues MDM vollständig konfigurieren: APNs, ABM-Token, Enrollment Profile, alle Profile nachbauen	Pflicht
6	VPP Content Token: Aus altem MDM entfernen, neues Token im neuen MDM registrieren	Kritisch
7	Pilot-Gruppe definieren (5–10 Geräte) für Testlauf vor Massenrollout	*Empfohlen*
8	User-Kommunikation vorbereiten: Was passiert, wann, was müssen User tun	Empfohlen

Phase 2: Migration in ABM starten

Anmelden bei business.apple.com als Administrator oder Device Enrollment Manager
Im Seitenmenü auf ‚Devices‘ gehen
Geräte suchen und auswählen (Seriennummer, Order-Nummer oder Filter ‚Eligible Devices‘ nutzen)
Auf das Gerät klicken → ‚…‘ (Ellipsis-Menü) oder ‚Edit‘ → ‚Assign Device Management‘
Neuen MDM-Server auswählen
‚Add Deadline‘ klicken und Datum/Uhrzeit setzen (kein Deadline = kein automatisches Erzwingen)
‚Continue‘ → Prompt lesen → ‚Confirm‘

Hinweis: Ohne Deadline kein Zwang!

Wenn ihr keine Deadline setzt, migriert das Gerät nur bei einem nächsten Erase oder wenn ihr manuell den profiles-Befehl ausführt. Für einen kontrollierten Rollout immer Deadline setzen.

Troubleshooting: „Add Deadline“ nicht verfügbar

Wenn der „Add Deadline“-Button im ABM ausgegraut ist oder gar nicht erscheint, liegt das fast immer an einem der folgenden drei Gründe:

Problem	Ursache	Lösung
OS < iOS/iPadOS/macOS 26	ABM zeigt die Option erst ab iOS 26 an – das Feature ist OS-seitig implementiert	Gerät auf iOS 26 updaten, dann erneut in ABM prüfen
Gerät nur „Assigned“, nicht „Enrolled“	Migration setzt aktives, laufendes Enrollment voraus – „Assigned“ allein reicht nicht	Gerät normal enrollen, dann Migration starten
Gerät im Status „Pending“	Gerät frisch ausgepackt oder noch im Setup Assistant – Enrollment-Flow noch nicht abgeschlossen	Setup abschließen und einmalig enrollen, dann Option prüfen
Enrolled, aber Option fehlt trotzdem	Letzter Check-in zu weit zurück oder MDM-Push ausstehend	Force Check-in über MDM senden, ABM-Seite neu laden
Quelle = „Apple Configurator“	Gerät wurde manuell über Configurator 2 in ABM eingebracht – nicht über Reseller/DEP	Siehe nächster Abschnitt

Schnellcheck: Enrolled vs. Assigned

Den Enrollment-Status „Enrolled“ bzw. „Assigned“ findet ihr nicht in ABM, sondern im jeweiligen MDM (z.B. Intune: Geräte → Gerät auswählen → Übersicht). ABM zeigt unter „Geräteverwaltungsdienst“ nur den zugewiesenen MDM-Server – keinen separaten Enrolled/Assigned-Status.

Was ihr direkt in ABM prüfen solltet: das Feld „Quelle“ unter Details. Steht dort „Apple Configurator“ → siehe nächster Abschnitt. Steht dort „Apple“ oder ein Reseller-Name → Migration sollte funktionieren, sofern das Gerät auf iOS 26 läuft und aktiv enrolled ist.

Sonderfall: Quelle „Apple Configurator“ – Migration nicht möglich

Wenn im ABM-Gerätedetail unter „Quelle“ der Wert „Apple Configurator“ steht, wurde das Gerät manuell über Apple Configurator 2 in ABM eingebracht – und nicht automatisch über den Kaufprozess via Reseller oder direkt bei Apple. Die Quelle ist fest gesetzt und lässt sich nachträglich nicht ändern. Die Option „Add Deadline“ erscheint für diese Geräte nicht.

Optionen und Lösungswege

Option 1 – Einmaliger Reset auf iOS 26 (empfohlen): Factory Reset des Geräts auf iOS 26. Beim Neuaufsetzen enrollt es sich sauber im ADE-Flow. Danach funktioniert die nahtlose MDM-Migration – dauerhaft, ohne weiteren Reset. Der einmalige Wipe ist der „Eintrittsbonus“ für den neuen Mechanismus.

Option 2 – Aus ABM entfernen und neu hinzufügen: über Configurator 2 möglich, ändert aber nichts – die Quelle bleibt „Apple Configurator“. Für dieses Problem kein sinnvoller Weg.

Option 3 – Für neue Geräte: Geräte künftig direkt über einen Apple Authorized Reseller oder Apple selbst kaufen. Diese landen automatisch mit Quelle „Apple“ bzw. Reseller-Name in ABM und sind von Anfang an für die nahtlose Migration geeignet.

Phase 3: User-Experience und Monitoring

Was der User sieht, hängt vom Zeitpunkt ab:

Abb. 3: Notification-Verhalten je nach Zeitpunkt bis zur Deadline

Zeitpunkt	Notification-Verhalten
Deadline gesetzt	Tägliche Benachrichtigung
24h vor Deadline	Stündliche Benachrichtigung
Letzte Stunde	Benachrichtigung alle 60, 30, 10 und 1 Minute(n)
Deadline erreicht	Nicht-wegklickbarer Vollbild-Dialog, Enrollment wird erzwungen

Wann erscheint die erste Notification? Kann man das beschleunigen?

Die initiale Notification erscheint bei einem online Gerät in der Regel innerhalb weniger Minuten nach der ABM-Zuweisung. Der Ablauf dahinter: ABM benachrichtigt das alte MDM über das MDM-Protokoll → das alte MDM schickt einen APNs-Push ans Gerät → das Gerät checkt beim alten MDM ein, holt sich die Migration-Instruction und zeigt dem User die Notification an. Ist das Gerät offline, wartet APNs auf die nächste Verbindung.

Wichtig: Die täglichen, stündlichen und minuten-genauen Benachrichtigungen aus der Tabelle oben sind der Reminder-Rhythmus für den Fall, dass der User noch nicht reagiert hat – nicht der Zeitplan für die initiale Erstbenachrichtigung.

Beschleunigen möglich? Ja – aber nur über das alte MDM: einen manuellen Force Check-in / Sync-Befehl ans Gerät schicken. Das triggert sofort ein Check-in, das Gerät holt sich die Migration-Instruction und zeigt die Notification ohne Wartezeit an. Ein ABM-Sync im neuen MDM hat darauf keinen Einfluss – die User-Notification läuft ausschließlich über das alte MDM und APNs.

Phase 4: Was auf dem Gerät passiert (User-Flow)

Auf iPhone/iPad:

User erhält eine Notification ‚Enrollment Required‘
Tippen auf die Notification öffnet Einstellungen → VPN & Geräteverwaltung
‚Enrollment starten‘ antippen
Gerät startet neu – nach dem Neustart enrollt sich das Gerät automatisch im neuen MDM
Alle neuen MDM-Konfigurationen werden direkt im Anschluss OTA verteilt

Auf Mac:

Notification erscheint im Notification Center
Klick öffnet Systemeinstellungen → Geräteverwaltung
‚Enrollment starten‘ → Vollbild-Dialog → ‚Enroll‘
MDM-Profile werden entfernt, Gerät enrollt sich neu
Nach erfolgtem Enrollment: alle neuen MDM-Konfigurationen werden OTA verteilt

Was wenn’s schiefläuft?

Schlägt das Enrollment fehl (z.B. kein WLAN), wird das Gerät nicht mehr vom alten MDM verwaltet und gilt als ‚unmanaged‘. In diesem Fall: Gerät wie ein neu zu enrollendes Gerät behandeln. Es gibt keinen automatischen Rückfall zum alten MDM.

Wie sieht das konkret für Intune und Workspace ONE aus?

Beide Lösungen unterstützen das Feature. Die Vorbereitung auf Intune-Seite laut Microsoft:

APNs-Zertifikat in Intune hochladen
ABM/ASM-Token in Intune registrieren (gegenseitiger Token-Austausch)
Enrollment Profile in Intune erstellen und Geräten zuweisen
Danach in ABM: MDM-Server auf Intune umstellen und Deadline setzen

Für Workspace ONE gilt dasselbe Prinzip. Da ich in nächster Zeit den ganzen Prozess selbst teste, folgt dazu ein detaillierter Praxisbericht – Stay tuned.

Best Practices für die Praxis

Immer mit einer Pilot-Gruppe anfangen: 5–10 Geräte, alles prüfen, dann skalieren.

Separate ABM-Server-Tokens: Für altes und neues MDM je einen eigenen Token verwenden.

await_device_configured nutzen: Dadurch können Apps (inkl. deren Daten) preserviert werden – wichtig für nahtlose User-Experience.

VPP-Migration zuerst planen: Token aus altem MDM ZUERST entfernen, dann im neuen registrieren. Deadline max. 30 Tage bei VPP-Apps.

User-Kommunikation: Vorab informieren, was passiert. Kein Datenverlust, aber der Enrollment-Dialog kommt – das kann erschrecken.

Offline-Fälle einplanen: Geräte ohne WLAN nach der Deadline landen im Setup-Assistant, bis sie sich verbinden.

Wenn man so wie ich, im täglichen Leben als MDM Architekt mit Android und iOS Devices arbeiten muss/darf, kommt man manchmal an Punkte, wo es ganz hilfreich ist, dass jeweilige Device (in meinem Falle Samsung und Zebra Rugged Devices) auf dem Lokalen Rechner zuspiegeln. Da ich aber keinen Windowsrechner benutze, sondern einen Mac, ist es manchmal halt bissel anders als unter dem Fenster-Riesen. Durch ein aktuelles Projekt, welches wir gerade begleiten, bin ich auf das Tool Screen Copy gestossen. Um dieses unter MacOS zu benutzen, mag ich euch heute diese Installationsanleitung näher bringen, da ich keine Deutsche Anleitung gefunden haben (ein Youtube Video in Englisch hänge ich unten dran). 😉

Scrcpy (auch Screen Copy genannt) ist ein OpenSource Projekt welches auf GitHub plaziert wurden. Scrcpy findet Ihr unter DIESEM Link. Scrcpy dient dazu, das Display des Android Devices auf eurem Mac (da es OpenSource ist, auch unter Win, Linux, etc) zu spiegeln und auch zu steuern. Gerade in Zeiten von COVID-19 und Home Office, eine super praktische Sache um in Präsentationen/Meetings den Kollegen/Kunden auch praktisch das Device zu präsentieren, obwohl diese halt nicht direkt vorort sind.

Also fangen wir an. Wir öffnen uns als erstes die Scrcpy Seite und gelangen auf die GitHUB Projekt Seite. Wenn Ihr dort runterscrollt, bekommt Ihr eine kurze Anleitung und Screenshots präsentiert. Für Scrcpy benötigt Ihr als erstes HomeBrew. Diese installiert ihr via:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Um das Script auszuführen, sucht Ihr nach eurer Terminal APP ( COMMAND + SPACEBAR und dann Terminal eingeben) und startet diese.

Hier gebt Ihr nun den Befehl ein und euer Adminpasswort (sudo):

MASCHINE:~ USERID$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" ==> Checking for `sudo` access (which may request your password)... Password: ==> This script will install: . . . . //WAIT JUST A FEW MINUTES ==> Installation successful!

Ist die Installation durch, kommen wir zum nächsten Punkt und installieren Scrcpy über den Terminal. Dazu geht Ihr wieder zurück in den Terminal und gebt dort folgenden Befehl ein:

brew install scrcpy

Der Befehl lädt nun alle benötigten Pakete von Scrcpy herunter und installiert diese. An dieser Stelle keine Panik, die Installation inkl. der Downloads dauert ein bischen was 😉

Ist der Prozess durch, müssen wir noch ADB (Android Debug Bridge) installieren. Dies tun wir über folgendes Kommando im Terminal:

brew install android-platform-tools

Sind wir hier durch, haben wir es endlich geschafft und können scrcpy starten. Dazu schließen wir das Android Device am Mac an und gehen in den Terminal um dort den Befehl einzugeben:

scrcpy

ein.

Wenn Ihr z.B. folgenden Fehler bekommt:
DEM0114:~ u074652$ scrcpy 2021-11-17 10:27:08.774 scrcpy[12412:322834] INFO: scrcpy 1.20 <https://github.com/Genymobile/scrcpy> adb: error: failed to get feature set: no devices/emulators found 2021-11-17 10:27:08.788 scrcpy[12412:322835] ERROR: "adb push" returned with value 1 2021-11-17 10:27:09.170 scrcpy[12412:322834] ERROR: Server connection failed

müsst Ihr auf dem Gerät des Debugging-Modus & adb-Autorisierungs-Timout deaktivieren. Um dies zu ermöglichen, geht ihr wie folgt vor:

EINSTELLUNGEN
TELEFONINFO
SOFTWAREINFORMATIONEN
nun mindestens 7 mal auf BUILDNUMMER tippen

und der Entwichlermodus ist aktiviert.
Danach habt Ihr unter EINSTELLUNGEN den Punkt ENTWICKLEROPTIONEN und könnt hier die oben genannten Optionen aktivieren. Nun könnt Ihr euer Android Device via Mouse steuern und es am Mac darstellen.

Falls Ihr das ganz lieber als Video (in Englisch) sehen wollt, empfehle ich euch folgendes Video auf Youtube:

Viel Spaß

Neueste Beiträge

Archiv

Schlagwort: howto