NinjaOne bringt Apples deklarative Geräteverwaltung in die App-Bereitstellung

Der Mechanismus der Selbstreparatur für Geräte

Die Beweiswand

• Apples deklarative Geräteverwaltung (DDM) erstreckt sich nun auch auf die App-Bereitstellung und ermöglicht es Geräten, fehlgeschlagene Installationen selbst zu erkennen und zu beheben, ohne dass ein Techniker eingreifen muss.
• Statt dass ein Server wiederholt den Status abfragt, vergleicht sich das Gerät selbst mit seinem eigenen Manifest und meldet sich in dem Moment zurück, in dem sich etwas ändert.
• Die neuen Kontrollen für verwaltete Apps bieten Administrator:innen automatische Updates, Installationen ausschließlich über WLAN oder auch über Mobilfunk sowie Sperr-/Ausblendfunktionen, allesamt über dieselbe Richtlinien-Engine, die sie bereits benutzen.
• Sind automatische Updates auf „Immer aktiviert“ gesetzt, setzt sich diese Einstellung über die persönlichen Geräteeinstellungen des Endanwenders hinweg, sodass eine App nicht aufgrund einer persönlichen Präferenz veralten kann.
• Diese Funktionen setzen voraus, dass Geräte in DDM registriert sind und mit OS 26 oder höher laufen. Ältere Geräte funktionieren weiterhin genau wie bisher.
• Kommt es zu einem Konflikt zwischen einer DDM-Deklaration und einem herkömmlichen MDM-Befehl, setzt sich stets die DDM-Deklaration durch.

Jeder IT-Administrator kennt einen ähnlichen Fall aus eigener Erfahrung. Eine Richtlinie stößt die Verteilung einer App an, und irgendwo zwischen dem Befehl und dem Gerät geht etwas schief. Irgendwo auf dem Weg verliert sich die Spur: eine abgebrochene Verbindung, ein ausgelastetes Gerät, und die Installation findet einfach nicht statt. Keine Warnmeldungen, keine Alarmsignale, kein Pfeifen. Die App ist schlicht nicht auf dem Gerät vorhanden und verharrt still und heimlich außerhalb der Compliance, bis jemand es bemerkt. Das können Endanwender:innen sein, die ein Ticket eröffnen oder eine Nachricht schreiben, oder ein/e überlastete/r IT-Administrator:in, dem/der auffällt, dass einem Teil des Gerätebestands eine kritische App fehlt. In der Regel sind es jedoch Anwender:innen, sodass IT-Administrator:innen reaktiv in der Schnittstelle nachforschen müssen, was eigentlich passiert ist.

Multipliziert man dies über Tausende von Geräten im Bestand, mit zahlreichen unterschiedlichen Betriebssystemversionen und Apps, hat man es längst nicht mehr mit einem bloßen Rätsel zu tun, sondern mit einer ernsthaften Compliance-Abweichung, die genauestens untersucht werden muss, um ihr auf den Grund zu gehen. Es ist ein schleichender Prozess, den niemand im Blick hat, während reaktive IT-Detektive dem Fall nachgehen und den Übeltäter aufspüren, um herauszufinden, warum etwas nicht einfach so „funktioniert“, wie es eigentlich sollte. Das hier ist kein Detektivfilm, es ist das Jahr 2026, und Geräte sollten eigentlich keinen Menschen benötigen, der über ihnen wacht, um ein Problem zu erkennen, bevor sie es selbst beheben.

NinjaOne hat etwas Neues zu bieten. Jetzt kann das Gerät seinen eigenen Fall proaktiv lösen. Es ist bereits im Einsatz.

Der Fall für eine neue Art von Detektivarbeit

Um den Wandel zu verstehen, lohnt sich ein Blick darauf, wie dieser Prozess früher ablief.

Apple hat die deklarative Geräteverwaltung (DDM) als Erweiterung des bestehenden MDM-Protokolls entwickelt, nicht als deren Ersatz. Es funktioniert im Zusammenspiel mit der Geräteverwaltung, die NinjaOne bereits durchführt, doch die Art, wie ermittelt wird, unterscheidet sich grundlegend!

Früher war der „Detektiv“ der MDM-Server. Er sendete einen Befehl und befragte anschließend das Gerät. Immer wieder. Ständig die Fragen: „Wurde installiert?“ „Wurde installiert?“ oder „Wie ist der Status?“ Dieses Vorgehen ist reaktiv und erzeugt mit der Zeit, bei Hunderten von Geräten, eine erhebliche Bandbreitenbelastung. Es ist ein mühsamer und wenig produktiver Prozess, bei dem eine Abfrage nach der anderen erfolgt. Mit DDM wird das Gerät selbst zum Detektiv. Es vergleicht seinen eigenen Zustand mit einer Manifestdatei und prüft, ob es dem entspricht, wie es eigentlich aussehen sollte. Stimmt etwas nicht, greift es quasi zum „roten Telefon“ und meldet sich über den dafür vorgesehenen Statuskanal, sobald sich etwas ändert, beim MDM zurück. Elementar, mein lieber Watson.

Für Apps bedeutet das: Das Apple-DDM-Protokoll übernimmt die Verteilung und Durchsetzung für jede App, die in einer NinjaOne-Richtlinie definiert ist, auf Geräten, die DDM unterstützen. Schlägt die App-Installation fehl, wartet das Gerät nicht ab. Es geht der Sache selbst nach. Das Gerät öffnet die Dateien erneut und versucht es eigenständig noch einmal. Sollten ein herkömmlicher MDM-Befehl und eine DDM-Deklaration jemals widersprüchliche Anweisungen liefern, besteht keine Unklarheit darüber, wer der ranghöhere Detektiv in diesem Fall ist: Die DDM-Deklaration setzt sich stets durch.

Der entscheidende Durchbruch im Fall: Kontrollen für verwaltete Apps

Jede gute Detektivgeschichte braucht neue Tools, und dieses Release stellt Administrator:innen gleich mehrere davon zur Verfügung, darunter:

• Automatisches Update, damit Apps aktuell bleiben, ohne dass ein Techniker neue Versionen ausrollen muss. Auf „Immer aktiv“ gesetzt, setzt sich diese Funktion sogar über die persönlichen Geräteeinstellungen des Endanwenders hinweg, sodass eine App nicht heimlich veralten kann, nur weil jemand eine persönliche Präferenz gewählt hat.
• Installationen ausschließlich über WLAN oder auch über Mobilfunk schützen die Datentarife auf Mobilfunkgeräten.
• Sperr- und Ausblendfunktionen ermöglichen es Administrator:innen zu entscheiden, wie viel Kontrolle Endanwender:innen über verwaltete Apps haben.

Die Methoden sind denkbar einfach. Ein Administrator legt die Richtlinie fest und konfiguriert diese Optionen. Von diesem Punkt an übernimmt das Gerät den Fall und arbeitet auf den gewünschten Zustand hin. Fehlgeschlagene Installationen wiederholen sich von selbst, Updates werden nach Zeitplan angewendet, und die Compliance bleibt gewahrt, ohne dass jemand mit der Lupe danebensteht oder nachfragen muss. Wenn dieser Abschnitt einen Slogan hätte, dann wäre es: Das Gerät verwaltet sich selbst.

Ein kurzer Hinweis zu den Voraussetzungen: Diese deklarativen Funktionen setzen voraus, dass Geräte in DDM registriert sind und mit OS 26 oder höher laufen. Geräte mit früheren Versionen funktionieren weiterhin genau wie bisher, ganz ohne Unterbrechung, sie erhalten lediglich den neuen Mechanismus für Selbstreparatur noch nicht.

Drei Fälle wurden gelöst, ohne dass ein Techniker vor Ort war

Fall 1 – Die manuelle Neusynchronisierungsschleife. Früher war ein Techniker das gesamte Detektivbüro in einer Person. Man musste ein Gerät außerhalb der Compliance aufspüren, der Ursache nachgehen, manuell resynchronisieren und hoffen, dass es funktioniert. Jetzt erkennt das Gerät eine fehlgeschlagene Installation selbst und versucht es erneut, ohne dass jemand nachfassen oder nachhaken muss. Das Fazit: Keine manuelle Resynchronisierung mehr erforderlich. Dies gilt für neue und geänderte App-Zuweisungen ab sofort. Apps, die bereits vor der Aktivierung von DDM installiert wurden, benötigen weiterhin eine einmalige Richtlinien-Resynchronisierung, um unter die DDM-Verwaltung gestellt zu werden.

Fall 2 – Die App, die nie aktualisiert wird. Der Detektiv muss sich nichts merken oder nachfragen: Automatische Updates halten Geräte per Richtlinie auf dem neuesten Stand. Das verkürzt den Zeitraum, in dem ein Gerät mit veralteter, potenziell anfälliger Software läuft, und führt zu weniger Tickets mit der Frage: „Warum läuft das noch auf einer alten Version?“ Das Fazit: weniger anfällige Geräte, weniger Tickets.

Fall 3 – Der MSP, der ein Dutzend „Tatorte“ gleichzeitig verwaltet. Jede Kundenumgebung hat ihre eigene Bandbreitenrealität. Installationen ausschließlich über WLAN schützen mobilfunkverbundene Geräte vor ungewöhnlichen Datenkosten. Automatische Wiederholungsversuche sorgen für eine konsistente Compliance über sämtliche Kunden hinweg, ohne dass Techniker:innen fehlgeschlagene Installationen einzeln oder Standort für Standort nachverfolgen müssen. Das Fazit: Konsequente Compliance, ohne manuelles Nachverfolgen.

Wo sich das alles in die größere Ermittlung einfügt

Diese Steuerungsfunktionen sind Teil derselben Richtlinien-Engine, die Administrator:innen bereits für die übrige Apple-Geräteverwaltung benutzen. Es müssen keine neuen Konsolen oder Workflows erlernt werden. Es ist ein weiteres Indiz dafür, wohin die Apple-Verwaltung von NinjaOne führt: zu einem Modell, in dem Geräte zunehmend ihre eigenen Fälle untersuchen und lösen, während Techniker:innen weniger Zeit damit verbringen, nach Hinweisen auf Probleme zu suchen, die sich bereits von selbst erledigt haben.

Der Fall ist (vorerst) abgeschlossen

Die deklarative Geräteverwaltung verteilt nicht einfach eine App auf ein Gerät und hofft auf das Beste. Es stattet das Gerät mit einer Dienstmarke, einer Fallakte und der Befugnis aus, seine eigenen Ermittlungen abzuschließen, ganz ohne Rückendeckung.

Die App-Bereitstellung ist erst die erste Fallakte. Bleiben Sie gespannt, denn die deklarative Geräteverwaltung wird im Rahmen der Apple-Verwaltung weitere Fälle eröffnen.

Die deklarative Geräteverwaltung ist ab Version 15.0 für NinjaOne MDM verfügbar.