Jamf macOS, Intune Windows und Kandji in einer deterministischen Dispatch-Ebene — circuit-broken, mit Evidenz erfasst, WORM-protokolliert. Natives MDM statt passivem Inventar-Dashboard.
Generische Endpunkt-Konsolen färben ein Gerät grün, sobald der letzte Inventar-Pull grün war — auch wenn die Live-MDM-API den Write gerade abgelehnt hat. Fragt der Prüfer „ist dieses Kommando wirklich angekommen?", hat das Dashboard keine Antwort, nur eine Farbe. Die Lojycal-Ebene liefert diese Mehrdeutigkeit nicht aus.
[ DISPATCH-ANFRAGE ] ──> [ CIRCUIT-BREAKER + EVIDENZ ] ──> [ WORM-AUDIT-LEDGER ]
- 5 Fehler OPEN / 60s HALF-OPEN - mdm_dispatch_failures
- Vendor-Rohevidenz erfasst - signierte audit_log-ZeileAdmin oder Automation löst eine MDM-Aktion aus. Pro Plattform wird die Erreichbarkeit vorab geprüft, bevor parallel ausgeliefert wird (max. 5 gleichzeitig pro Hersteller).
withCircuitBreaker kontrolliert den Aufruf. Die Rohantwort des Herstellers (Classic + v2 bei Jamf) wird pro Gerät im Dispatch-Flight-Panel festgehalten.
Erfolg schreibt die Aktion per AFTER-Trigger ins audit_log. Fehler schreiben nach mdm_dispatch_failures. Beide Zeilen sind unveränderlich — worm_block_mutation-Trigger lehnen UPDATE und DELETE für alle ab, auch für Plattform-Admins.
Jeder MDM-Write an Jamf, Intune oder Kandji läuft durch einen Circuit-Breaker — 5 aufeinanderfolgende Fehler öffnen ihn, ein 60-Sekunden-Cooldown erzwingt einen HALF-OPEN-Probe-Versuch, bevor die Ebene weiterläuft. Tote Vendor-APIs können nicht still in eine Flotte hineinwiederholt werden.
Scheitert der Live-Write beim Hersteller, zeigt die UI den Fehler mit der rohen Classic- und v2-Evidenz. Gecachte config_profiles, lastContactTime oder der letzte bekannte Gerätestatus überschreiben niemals ein rotes Verdikt. Diese Regel ist in den Jamf- und Kandji-Adaptern fest verdrahtet.
Fehlgeschlagene Dispatches landen über recordDispatchFailure in der WORM-Tabelle mdm_dispatch_failures — Hersteller, Kommando, Versuch, Rohantwort, Breaker-Status. Dieselbe Zeile speist das Dispatch-Board und das Evidence-Pack für Prüfer.
Jamf-Inventar läuft über eine verwaltete jamf-recon-Policy (der Hersteller hat bestätigt, dass Classic- und v2-API keine Remote-Inventory-Writes akzeptieren). Kandji nutzt natives blankpush, Intune Windows eine verwaltete Entra-Gruppe, ephemere deviceManagementScripts und syncDevice.
Der Kandji-Webhook verlangt HMAC-Verifikation, UNIQUE(org, event_id)-Dedupe und ein occurred_at-Zeitfenster von ±5 Minuten. Replays und gefälschte Payloads werden verworfen, bevor eine Zeile mutiert.
kandji-blueprint-verify-daily läuft um 03:30 UTC, schreibt eine Verifikationszeile und emittiert ein kandji.blueprint.drift_detected-Audit-Event, sobald ein Blueprint vom Sollzustand abweicht.
Eine Dispatch-Ebene über Jamf, Intune und Kandji. Ein Ledger, das Prüfer wörtlich zitieren können. Kein Raum für eine grüne Kachel, die einen gescheiterten Write verdeckt.