Einleitung
In einem vorherigen Venting Wednesday Beitrag ging es um eine Frage, die wahrscheinlich jeder Intune-Admin kennt:
Warum fühlt sich Intune oft so langsam an?
Statt dabei zu bleiben, habe ich mir die zugrundeliegende Mechanik genauer angeschaut.
Denn der entscheidende Punkt ist:
Das Verhalten ist in den meisten Fällen kein Bug, sondern eine direkte Folge davon, wie Intune technisch aufgebaut ist.
Und genau hier liegt das Missverständnis.
Viele erwarten ein System, das Änderungen aktiv verteilt.
Intune funktioniert jedoch anders:
Der Client holt sich den Zustand selbst, nicht umgekehrt.
Dieser Artikel erklärt sauber, wie die Synchronisation tatsächlich funktioniert, welche Zeitfenster realistisch sind und warum sich Änderungen oft verzögert anfühlen, obwohl technisch alles korrekt läuft.
Short answer
Intune arbeitet pull-basiert. Geräte synchronisieren sich nicht kontinuierlich, sondern in Intervallen:
- Standard Sync: ~alle 8 Stunden
- Manual Sync: sofort (User oder Admin ausgelöst)
- Policy Verarbeitung: meist 5–15 Minuten nach Sync
- Win32 Apps (IME): komplett asynchron, stark verzögert möglich
Das ist der Hauptgrund, warum Änderungen in Intune oft „langsam“ wirken.
Key facts
- Kein Push-System: Intune sendet keine Änderungen aktiv an Geräte
- Client entscheidet: Das Gerät holt sich selbst Updates
- Mehrere Pipelines: MDM, IME und Compliance laufen getrennt
- Timing ist nicht deterministisch: Verzögerungen sind normal
Intune Sync Frequencies im Detail
| Komponente | Typisches Intervall | Beschreibung |
|---|---|---|
| MDM Sync | ~8 Stunden | Gerät fragt neue Policies vom Intune Service ab |
| Manual Sync | Sofort | Wird durch User oder Admin ausgelöst (Company Portal / Settings) |
| Policy Verarbeitung | 5–15 Minuten | Nach dem Sync werden Policies lokal angewendet |
| Compliance Check | Variabel (ca. 8–24h) | Status wird regelmäßig neu berechnet |
| IME (Win32 Apps) | Unregelmäßig | Eigenständiger Agent, komplett asynchron |
Warum Intune nicht „instant“ ist
Das Kernproblem ist die Architektur:
- Kein permanenter Socket / Push Channel
- Geräte sind oft offline oder im Sleep
- Skalierung über Millionen Devices notwendig
👉 Deshalb ist das Modell bewusst:
Client pulls state when available
Was passiert bei einer Änderung wirklich?
Beispiel: Du änderst eine Policy.
- Änderung wird im Intune Backend gespeichert
- Nichts passiert sofort
- Gerät synced beim nächsten Intervall
- Policy wird heruntergeladen
- Verarbeitung startet lokal
- Status wird zurückgemeldet
👉 Jeder dieser Schritte kann verzögert sein.
Häufige Missverständnisse
- „Ich hab doch Sync gedrückt“
→ Der Sync ist nur der Start, nicht die komplette Verarbeitung - „Policy ist assigned, warum passiert nichts?“
→ Assignment ≠ Anwendung - „Intune ist langsam“
→ Meistens Architektur, kein Bug
Wann ist Intune wirklich langsam?
Es gibt echte Fälle, wo es nicht nur „normal langsam“ ist:
- IME hängt → Win32 Apps kommen nie an
- Gerät synced nicht → keine Updates
- Azure AD / Entra Issues → Token Probleme
- Große Deployments → Queueing Effekte
Praktische Debug-Checks
Wenn etwas „zu lange“ dauert:
Fazit
Intune ist nicht langsam – es ist asynchron und skalierbar gebaut.
Wenn man das versteht, ändern sich zwei Dinge:
- Erwartungen werden realistischer
- Troubleshooting wird deutlich einfacher
TL;DR
- Intune synced standardmäßig alle ~8 Stunden
- Änderungen sind nicht sofort sichtbar
- Architektur ist bewusst nicht „real-time“
- Verzögerungen sind normal, nicht die Ausnahme