Das Updatemanagement für iOS und macOS via Intune oder anderen MDM-Systemen war bislang im Vergleich zu Windows recht starr und unflexibel. In vielen Firmen war eine Mischung aus den MDM-Updaterichtlinien und Compliance-Richtlinien für das Updatemanagement im Einsatz. Die User wurden über interne Kommunikationswege auf das neue Update aufmerksam gemacht und zu einem bestimmten Datum wurde die Compliance-Richtlinie mit der neuen Version versehen. Das Gerät wurde so noncompliant und die User haben durch Conditional-Access-Richtlinien den Zugriff auf Unternehmensressourcen verloren, bis das Betriebssystem auf die gewünschte Version gepatcht wurde. Im Rahmen eines Kundenprojekts habe ich in den letzten Wochen ein vollständiges macOS-Management mit Intune implementiert – einschließlich einer vollständigen Neuausrichtung der Updaterichtlinien mittels Declarative Device Management (DDM). Diese Erfahrungen möchte ich mit diesem Blogartikel teilen. Denn die Dokumentationen von Apple und Microsoft zu dem Thema sind leider lückenhaft und ich musste einiges an Wissen durch aufwendige Tests erarbeiten. Speziell ging es hier um das Zusammenspiel der einzelnen Settings und des daraus resultierenden Best Practice.
🚨 Deprecation-Warnung für klassische MDM-Updates 🚨
Apple hat in einem Video1 der WWDC 2025 angekündigt, dass die 26er-Versionen von iOS/iPadOS und macOS nicht mehr per MDM-Updaterichtlinien verwaltet werden können. Auch Microsoft weist in einem Artikel2 darauf hin. Deshalb ist ein Wechsel auf die hier beschriebenen DDM-Richtlinien zwingend notwendig, wenn man ab Herbst weiterhin Updates für die Geräte mit Intune verwalten will.
Herkömmliche MDM-Updatepolicy
Mit der alten Möglichkeit, dem Updatemanagement über MDM-Richtlinien, ist man sehr beschränkt gewesen. Man konnte nur einen bestimmten Updatezeitraum definieren und welche Version installiert werden soll. Updates konnten bis zu 30 Tage zurückgestellt werden und das war es dann eigentlich schon. Was dabei fehlt: die Flexibilität für den Nutzer.
Vergleich zwischen DDM und klassischem MDM-Updateverfahren
Beim traditionellen Mobile Device Management (MDM) melden sich Geräte regelmäßig beim Management-Server (z. B. Intune), um neue Richtlinien oder Befehle abzurufen. Dieses ständige Abfragen („Polling“) erzeugt eine gewisse Verzögerung und belastet Server sowie Geräte.
Im Gegensatz dazu ermöglicht das moderne Declarative Device Management (DDM) eine deutlich autonomere Steuerung: Geräte erhalten deklarative Richtlinien, die das gewünschte Verhalten klar definieren. Anschließend setzen sie diese selbstständig und unmittelbar um, ohne ständiges Nachfragen beim Server.
In der nachfolgenden Tabelle habe ich die Unterschiede zwischen DDM und MDM Updatemanagement dargestellt.
| Feature | DDM Managed Software Update | Herkömmliche MDM-Updatepolicy |
|---|---|---|
| Unterstützt iOS/iPadOS | ✅ ab 17.0 | ✅ (ältere Versionen) |
| Unterstützt macOS | ✅ ab 14.0 | ❌ nur ab macOS 12 mit eingeschränkten Optionen |
| Spezifisches Targetging (Version/Build) | ✅ möglich | ❌ überwiegend unflexibel |
| Deadline Enforcement | ✅ erzwingbare Updates | ❌ keine zwingende Deadline |
| Verweis-URL / Info-Links | ✅ Details-URL möglich | ❌ nicht vorhanden |
| Sichtbarkeit des Updates kontrollierbar | ✅ über integrierte Verzögerungen (Deferrals) | ✅ über Einstellungen, aber mit geringer Priorität |
| Priorität gegenüber anderen Policys | ✅ DDM hat Vorrang, blockiert MDM-Policies | ✅ je nach Konfiguration, aber weniger deterministisch |
Best-Practices für macOS & iOS Updatemanagement via DDM
Die Updaterichtlinien sind weitestgehend gleich bei iOS und macOS, mit ein paar Besonderheiten bei den Deferral-Zeiten. Diese kann bei macOS für Major-, Minor- und System-Updates einzeln gesteuert werden. Das ermöglicht einem, Security-Updates (Minor-Updates) automatisiert deutlich früher für den User freizugeben. Major-Updates sollen z.B. möglichst spät bzw. von der IT-Abteilung gesteuert freigegeben werden. Folgende Wünsche erfüllt mein Best-Practices-Ansatz:
- ✅ Automatische Freigabe von Minor-Versionen
- Minor-Updates (Sicherheitsupdates, Bugfixes, Stabilitätsverbesserungen) werden spätestens 7 Tage nach Veröffentlichung automatisch für Nutzer bereitgestellt.
- Vorteil: Balance aus Aktualität und Stabilität.
- ✅ Zeitverzögerte Freigabe von Major-Versionen
- Neue Major-Versionen (z. B. iOS 19, macOS 26) werden standardmäßig möglichst spät freigegeben, sofern nicht explizit früher von der IT freigegeben.
- Vorteil: Umfangreiche Tests und Risikominimierung bei großen Updates und Möglichkeit des Überspringens der x.0-Version.
- ✅ Forcierte Installation zu einer definierten Deadline
- Kritische oder festgelegte Versionen können per DDM zu einer verbindlichen Frist erzwungen werden, um Compliance und Sicherheit zu gewährleisten.
- Vorteil: Schnellstmögliches Durchpatchen bei sicherheitsrelevanten Updates.
- ✅ Flexible Update-Installation durch Nutzer
- Nutzer erhalten bis zur definierten Deadline maximale Flexibilität, um das Update zu einem günstigen Zeitpunkt selbst zu installieren.
- Vorteil: Hohe Nutzerakzeptanz und minimale Arbeitsunterbrechungen.
- ✅ Pilotgruppen vor breitem Rollout
- Neue Updates werden zuerst in Pilotgruppen getestet, um mögliche Probleme frühzeitig zu erkennen und zu beheben.
TL;DR Infobox
Für die Ungeduldigen hier kurz und knapp die empfohlene DDM-Konfiguration für produktive Apple-Geräte (ab iOS 17 / macOS 14):
- ✅ Minor Updates Deferral: automatische Freigabe nach 7 Tagen
- ✅ Major Updates Deferral: verzögerte Freigabe, z. B. 90 Tage
- ✅ Zielversion: definiert über „Target OS Version“ (z. B. 15.6)
- ✅ Deadline: erzwungene Installation per „Target Date“ (z. B. 05.08.2025, 19:00 Uhr)
- ✅ Flexibilität: Nutzer:innen können das Update bis zur Deadline manuell starten
- ✅ Rollbacks und Sicherheitsreaktionen (RSR): aktiviert
- ✅ Automatic Actions: Alle auf AlwaysOn stellen
- ✅ Beta Enrollment: Mit AlwaysOff deaktivieren
Allgemeine Updatesettings
Zunächst erstelle ich eine Settings Catalog Richtlinie für die allgemeinen Updateeinstellungen für alle Clients. Diese dienen dazu, bestimmte Einstellungen fest einzuschalten, damit der User diese auch nicht deaktivieren kann.
- Allow Standard User OS Updates: Allowed
→ Wichtig, sofern die macOS-User keine Adminrechte haben (unbedingt empfohlen!) - Automatic Actions (AlwaysOn bedeutet, dass der User diese Einstellung nicht deaktivieren kann)
- Download: AlwaysOn
→ Updates werden automatisch heruntergeladen, sobald sie verfügbar sind. - Install OS Updates: AlwaysOn
→ Betriebssystem-Updates werden automatisch installiert, ohne dass der Nutzer aktiv werden muss. - Install Security Update: AlwaysOn
→ Sicherheitsupdates werden automatisch installiert
- Download: AlwaysOn
- Program Enrollment: AlwaysOff
→ Die Teilnahme an Beta-Programmen (z. B. iOS Public Beta) ist deaktiviert. Das verhindert instabile Pre-Release-Versionen in der Unternehmensumgebung. - Rapid Security Response (RSR)
- Enable: Enabled
→ Schnelle Sicherheitsmaßnahmen (RSR) werden unterstützt. Apple kann so kritische Sicherheitslücken ohne vollständiges OS-Update schließen. - Enable Rollback: Enabled
→ Bei Problemen mit RSR-Updates ist ein Rückgängigmachen (Rollback) möglich – erhöht die Betriebssicherheit.
- Enable: Enabled
- Notifications: Enabled
→ Nutzer erhalten Benachrichtigungen über verfügbare Updates, Deadlines oder erforderliche Installationen. Wird dieser Punkt auf Disabled gesetzt, erhält der User erst eine Minute vor der Installation eine Benachrichtigung. Kann sinnvoll für unbeaufsichtigte Shared Devices sein.
🚨 Achtung bei Assignment Filtern 🚨
Bei DDM-Policies werden Assignment-Filter nicht unterstützt. Teilweise funktioniert es zwar trotzdem, aber bei User-Assignments funktioniert es definitiv nicht! Das musste ich nach einigem Troubleshooting selbst feststellen.🙂
Quelle: https://learn.microsoft.com/en-us/intune/intune-service/protect/managed-software-updates-ios-macos#configure-the-automatic-ddm-software-updates-policy
Zusammenspiel der Updatesettings & Ablauf
Ein Punkt hat mich ziemlich viel Arbeit gekostet. Und zwar das Zusammenspiel der Deferrals & Target OS Version herauszufinden. Es ist in den Dokumentationen von Apple und Microsoft nicht genau ersichtlich, wie sich was bedingt. Dazu habe ich zahlreiche Tests durchgeführt, um dies zu erarbeiten. Im Wesentlichen sind die im nachfolgenden Screenshot abgebildeten Settings wichtig. An einem Beispiel möchte ich diese erklären und erstelle dafür eine separate Policy, damit ich diese jeweils für eine Pilot- und Broad-Gruppe separat einstellen kann. Das ist aber Geschmackssache und nicht zwingend so umzusetzen.
Wir gehen von den nachfolgenden Daten aus: Die macOS-Version 15.6 ist am 29.07. erschienen. Am 01.08. werden die Settings Target OS Version (15.6) und Target Date Time (5.8.2025 19:00:00) gesetzt.
🕒 Hinweis zur Zeitzone:
Bei klassischen MDM-Updateeinstellungen wurde die Uhrzeit für Installationen stets in einer festen Zeitzone definiert. In Umgebungen mit Clients über mehrere Zeitzonen hinweg führte das dazu, dass mehrere Update-Richtlinien gepflegt werden mussten, um Installationen zuverlässig außerhalb der lokalen Arbeitszeiten auszuführen.
Mit DDM entfällt diese Komplexität: Die konfigurierte Zeit gilt immer in der lokalen Zeitzone des Geräts. Das vereinfacht das Richtlinien-Management erheblich, insbesondere in globalen oder verteilten Organisationen.
Ab 1.08. wird dem User in den Updatesettings angezeigt, dass die Version 15.5 die neuste von der IT-Abteilung freigegebene Version ist. Er kann also keine neuere Version als 15.5 installieren. Ab dem zeitpunkt des setzens von Target OS Version und Target Date Time passiert Folgendes: Die eingestellte Deferral-Zeit von 7 Tagen für die Minor-Version wird ignoriert und dem User wird das Update 15.6 in den Updatesettings angeboten. Je nach sonstiger Konfiguration wird es auch bereits im Hintergrund heruntergeladen und installiert. Die Benachrichtigungen für den User folgen dem nachfolgenden Schema. Die Benachrichtigungen für den User werden dabei immer häufiger und „penetranter“ um den User vor dem automatischen Neustart zum Update anzuregen. Bei weniger als 14 Tagen erhält der User täglich eine Benachrichtigung. 24 Stunden vor Deadline wird die Meldung selbst bei aktiver „Nicht stören“ Funktion angezeigt.
Eine Stunde vor Erreichen der Target Date Time erhält der User die Information darüber, dass ein Update installiert werden muss. Diese Meldung erscheint erneut 30, 10 und 1 Minute vor erreichen der Zeit. Dann läuft ein Countdown, der nicht abgebrochen werden kann. Um spätestens 19 Uhr am 5.8. startet das System automatisch neu und installiert das Update selbstständig.
Am nächsten Tag kann die IT-Abteilung die Version in der Compliance-Richtlinie auf 15.6 erhöhen, um ausgeschaltete Geräte ab diesem Zeitpunkt für Conditional Access am Zugriff auf Unternehmensressourcen zu hindern, bis das Update installiert ist. Ein Client, welcher nach Erreichen der Frist gestartet wird, hat von da an genau eine Stunde Zeit, das Update zu installieren, und startet dann ebenfalls automatisch neu.
Was passiert ohne gesetzte Target OS Version und Target Date Time?
Wird die IT-Abteilung nicht aktiv, so wird 7 Tage nach Release der Minor-Version das Update erstmalig dem Client angeboten. Sind automatische Updates konfiguriert, wird das Update ebenfalls automatisch installiert, aber ohne erzwungenen Neustart. Der User wird dann regelmäßig über den nötigen Neustart informiert und muss zum Abschließen des Updates den Client neustarten. Man hat also ein gewisses Fallback implementiert, um Sicherheitsupdates notfalls als Self-Service für den User freizugeben.
Gleiches gilt, wenn vom letzten Update noch alte Werte gesetzt sind, also zum Beispiel Version 15.5 zum 1.Mai. um 19 Uhr, gesetzt ist. Das Setting muss also nicht entfernt werden und sollte es auch nicht. Denn neu in Betrieb genommene Geräte werden so innerhalb einer Stunde nach der Installation auf die dort definierte Version hochgezogen.
Was ist mit der Enforce Latest-Einstellung?
Wer sich bereits mit dem Updatemanagement per DDM beschäftigt hat, wird sich nun fragen, wieso man nicht einfach die Enforce Latest Einstellung nutzt? Natürlich ist das auch eine Option, vor allem für kleinere Firmen mit wenigen Geräten und ohne eigene IT-Abteilung. Aber diese Möglichkeit hat für mich (aktuell) einen großen Nachteil: Wird eine neue Major-Version von Apple veröffentlicht, dann wird auch dieses Update nach Erreichen der Delay in Days Einstellung sofort installiert. Nicht selten ist es vorgekommen, dass die x.0-Versionen einige Fehler enthalten haben, und erst ab der x.1-Version das Update empfehlenswert war. Man muss sich also entscheiden, ob man Minor-Updates möglichst schnell, oder Major-Updates möglichst spät installiert haben will.
Aktuell können keine gesonderten Zeiten für Major- & Minor-Versionen eingestellt werden. Deswegen benutze ich dieses Setting nicht, sondern baue auf Interaktion der IT-Abteilung. Sofern Apple bzw. Microsoft dies implementiert und die Target OS Version und Target Date Time dieses Setting überschreibt, wäre es eine echte Alternative zu den Deferrals.
In Summe ergeben sich folgende drei Policies, die im Zusammenspiel einwandfrei funktionieren und mit kleinen Anpassungen auch für iOS genutzt werden können.
Fazit
Mit Declarative Device Management (DDM) via Microsoft Intune lässt sich das Update-Management für iOS 17+ und macOS 14+ deutlich effizienter und skalierbarer gestalten. DDM ermöglicht es, Geräte autonom Updates nach definierten Regeln durchzuführen – von der automatischen Freigabe von Minor‑Updates (z. B. 7 Tage nach Release) über verzögerte Major‑Rollouts (z. B. 90‑Tage Deferral) bis hin zur forcierten Installation zur Deadline.
Der kombinierte Ansatz aus Flexibilität für Endnutzer und Kontrolle für die IT führt zu hoher Akzeptanz und verringerter manueller Steuerung. Meldungen und Statusreports der Geräte geben unmittelbare Transparenz über den Compliance‑Status.
Im Vergleich zum traditionellen MDM‑Updateverfahren bietet DDM deutlich präzisere Steuerung, niedrigere Infrastrukturbelastung, bessere Skalierbarkeit und ein stabileres Nutzererlebnis.
Für Unternehmen mit klaren Sicherheits- und Compliance-Anforderungen ist DDM der empfohlene Standard – DDM-Policies haben Priorität vor älteren MDM-Richtlinien, sodass eine konsistente und konfliktfreie Umsetzung gewährleistet ist.
