Warum deine Intune-Architektur wahrscheinlich Müll ist – und wie man sie sauber baut
Die meisten Intune-Umgebungen funktionieren, aber sie sind nicht gut. Sie sind schwer zu verstehen, schwer zu warten und brechen bei jeder etwas größeren Änderung an Stellen, an denen es eigentlich gar nicht spannend sein sollte. Dann sitzt man wieder im Tenant, klickt sich durch Policies mit komischen Namen, schaut in Assignments, vergleicht zehnmal dieselbe Einstellung und fragt sich zum dritten Mal an dem Tag, warum etwas auf diesem einen Gerät greift und auf dem anderen nicht.
Das Problem ist dabei erstaunlich selten Intune selbst. Das Problem ist fast immer die Architektur. Intune ist kein besonders geheimnisvolles Tool. Aber es ist ein Tool, das schlechte Struktur langfristig gnadenlos sichtbar macht. Am Anfang läuft so ein Tenant oft noch irgendwie. Ein paar Policies hier, ein paar Apps da, schnell etwas für einen Sonderfall gebaut, dann noch eine Ausnahme für einen Standort, dann noch eine Testgruppe, die nie wieder weggeräumt wurde. Ein Jahr später versteht niemand mehr sauber, was dort eigentlich das Zielmodell war.
Woran du erkennst, dass dein Tenant architektonisch schief ist
Bevor man über Best Practices redet, lohnt sich der ehrliche Blick auf die Symptome. Denn schlechte Intune-Architektur kündigt sich selten mit einem großen Knall an. Sie zeigt sich eher in diesem dauerhaften Grundrauschen aus Unsicherheit, Workarounds und Seiteneffekten, das viele Teams irgendwann schon für normal halten.
Wenn in deinem Tenant mehrere dieser Punkte bekannt klingen, ist das kein kleiner Schönheitsfehler mehr, sondern ein Architekturthema:
| Symptom | Wie es im Alltag aussieht | Was eigentlich dahintersteckt |
|---|---|---|
| Zu viele Policies ohne Modell | Es gibt 100+ Policies, aber keiner kann in zwei Minuten erklären, welche davon Baseline, Spezialfall oder Altlast ist | Es wurde im Tenant additiv gearbeitet, aber nie architektonisch aufgeräumt |
| Doppelte oder widersprüchliche Settings | Dieselbe Konfiguration taucht in mehreren Policies auf, teils mit unterschiedlichem Wert | Verantwortlichkeiten und Layer sind nicht getrennt |
| User- und Device-Logik ist gemischt | Ein Teil läuft sauber beim Gerät, der andere Teil erst nach User-Login, und keiner weiß mehr, was bewusst so gebaut wurde | Es gibt kein klares Kontextmodell für Zuweisungen |
| "Warum greift die Policy nicht?" ist Dauerthema | Support und Plattformteam verlieren regelmäßig Zeit mit Scope-, Timing- und Konfliktanalyse | Die Umgebung ist nicht deterministisch genug aufgebaut |
| Änderungen haben Nebenwirkungen | Eine kleine Policy-Anpassung trifft plötzlich mehr Geräte oder User als geplant | Assignments und Scoping sind zu grob oder nicht sauber lesbar |
| Niemand kennt die "richtige" Policy | Neue Kollegen und selbst erfahrene Admins suchen erstmal nach der Quelle der Wahrheit | Naming, Ownership und Struktur fehlen oder sind verrottet |
Der Punkt daran ist wichtig: Solche Symptome wirken im Tagesgeschäft oft wie lauter einzelne Probleme. Mal ein Assignment-Fehler, mal eine Policy, die scheinbar random greift, mal ein Sonderfall, der wieder Debugging frisst. In Wahrheit ist das oft dieselbe Ursache in verschiedenen Kleidern. Der Tenant ist nicht sauber modelliert, also verhält er sich auch nicht sauber lesbar.
Die häufigsten Architekturfehler in Intune
Die meisten kaputten Intune-Umgebungen sind nicht deshalb kaputt, weil die Leute dumm wären oder nichts könnten. Fast immer ist es einfach gewachsene Komplexität ohne klares Zielmodell. Jemand musste schnell liefern, ein Projekt hatte Druck, eine Migration lief parallel, ein alter Sonderfall wurde übernommen und niemand hatte das Mandat, den ganzen Laden einmal sauber geradezuziehen. Genau deshalb wiederholen sich die Fehler auch so zuverlässig.
Keine Trennung von Verantwortlichkeiten
Das ist einer der Klassiker. Security, Konfiguration, Compliance und manchmal noch App-spezifische Dinge hängen wild durcheinander in denselben Policies oder zumindest in einem Setup, das keine klare fachliche Grenze mehr erkennen lässt. Dann liegt BitLocker an drei Stellen, Defender-Settings tauchen in verschiedenen Profilen auf, irgendwelche Explorer-Einstellungen hängen plötzlich in einer Security-Policy und am Ende weiß keiner mehr, welches Objekt überhaupt die führende Instanz sein soll.
Das Problem daran ist nicht nur ästhetisch. Es macht die Wirkung deines Tenants unklar. Sobald mehrere Policies fachlich dasselbe Terrain bearbeiten, bekommst du keine saubere geistige Landkarte mehr hin. Debugging wird dann zur Hölle, weil du nicht mehr von einer Einstellung aus denken kannst, sondern immer den kompletten Policy-Wald im Kopf halten musst. Sobald du für eine einzelne Frage drei oder vier Policies vergleichen musst, ist die Architektur schon zu weit entglitten.
User und Device komplett vermischt
Das ist wahrscheinlich der häufigste Fehler überhaupt, weil er am Anfang harmlos aussieht. Eine App mal auf User, mal auf Device. Eine Konfiguration hier noch schnell an eine User-Gruppe, dort an eine Device-Gruppe, weil es in dem Moment praktischer wirkte. Irgendwann existiert dann kein konsistentes Modell mehr, sondern nur noch historisch gewachsene Entscheidungen.
Das Problem ist tiefer, als viele im ersten Moment denken. User Context und Device Context sind in Intune nicht einfach zwei verschiedene Wege zum gleichen Ergebnis. Sie unterscheiden sich in Timing, Evaluierung, Anwendung und Troubleshooting teilweise massiv. Was im Device-Kontext beim Enrollment oder vor dem ersten Login relevant ist, verhält sich ganz anders als etwas, das erst im Benutzerkontext sauber einzieht. Wenn diese Trennung nicht bewusst modelliert ist, wirkt der Tenant für Benutzer irgendwann random, obwohl das System technisch genau das tut, was du ihm beigebracht hast.
Gerade hier entstehen dann diese Sätze, die man in schrägen Umgebungen ständig hört: "Auf meinem Testgerät ging es noch", "Beim zweiten Login war es plötzlich da" oder "Bei User A greift es, bei User B auf demselben Modell nicht". Das sind oft keine einzelnen Bugs. Das ist vermischte Architektur.
Keine klare Naming Strategy
Wenn ein Tenant Policies mit Namen wie Policy1, Baseline-Test, Final_Final_v2, Config Neu, Security Copy, Prod-Neu-Wirklich oder ähnlich kaputtem Zeug enthält, ist das nie nur ein kosmetisches Problem. Schlechte Namen sind ein direktes Symptom dafür, dass die Umgebung nicht wie ein System gebaut wurde, sondern wie ein Haufen einzelner Arbeitsergebnisse.
Naming ist in Intune keine Nebensache, weil Namen dort permanent Teil der Navigation und des Denkmodells sind. Du suchst nach Policies, vergleichst Zuweisungen, filterst Objekte, sprichst im Team über Änderungen und onboardest neue Kollegen fast immer über das, was im Portal sichtbar benannt ist. Wenn die Namen keinen Zweck, keine Schicht und keine Zielplattform erkennen lassen, muss jede Person im Team ständig zusätzliche Denkarbeit leisten, nur um die Umgebung lesen zu können. Das ist vergeudete mentale Energie und skaliert miserabel.
Assignments sind pures Chaos
Viele Umgebungen kippen nicht an der Policy selbst, sondern am Scoping. Dann hängt viel zu viel auf All Users oder All Devices, Ausnahmen werden irgendwo daneben gepflastert, Testgruppen leben ewig weiter, Filter werden gar nicht genutzt oder nur so halb verstanden, und dynamische Gruppen existieren wenn überhaupt nur für ein paar einzelne Bereiche. Solange wenig los ist, fällt das noch nicht brutal auf. Sobald der Tenant wächst, wird es richtig teuer.
Denn ohne sauberes Assignment-Modell hast du praktisch keine Kontrolle über Reichweite. Du kannst Änderungen nicht vernünftig testen, du kannst Nebenwirkungen schlechter eingrenzen und du weißt bei Problemen oft nicht, ob der Fehler in der Policy, im Timing oder schlicht im Scope liegt. Das ist der Moment, in dem aus Verwaltung Glücksspiel wird. Intune fühlt sich dann willkürlich an, obwohl die Ursache in Wahrheit nur schlampiges Scoping ist.
Copy-Paste aus der GPO-Welt
Auch das ist ein Dauerbrenner. Alte GPO-Welten werden gedanklich oder ganz praktisch nach Intune umgezogen, oft fast 1:1. Settings, die man seit Jahren hatte, werden übernommen, ohne ehrlich zu prüfen, ob sie im heutigen Cloud-Kontext überhaupt noch sinnvoll sind. Hauptsache, erstmal alles wieder irgendwie abgebildet. Das fühlt sich nach Kontrolle an, ist aber häufig nur konservierte Altlast.
Die eigentliche Frage müsste immer sein: Brauche ich diese Einstellung heute wirklich noch, und braucht sie einen Platz in Intune? Nicht jede alte Steuerung aus der On-Prem-Welt ist in einer modernen Endpoint-Architektur noch relevant. Wenn man das nicht hinterfragt, entsteht schnell Overengineering. Der Tenant wird voller unnötiger Komplexität, aber nicht voller echter Qualität. Und schlimmer noch: Jede unnötige Policy ist später wieder eine zusätzliche Variable im Troubleshooting.
Wie eine saubere Intune-Architektur aussieht
Der Gegenentwurf ist nicht kompliziert. Er verlangt nur Disziplin. Gute Intune-Architektur beginnt nicht mit einem exotischen Feature und auch nicht mit irgendeinem geheimen Trick, sondern mit einem simplen Prinzip: Jedes Objekt im Tenant braucht einen klaren Zweck, einen klaren Kontext und ein klares Scope. Sobald du das ernst nimmst, wird die Umgebung nicht nur wartbarer, sondern auch mental deutlich leichter.
Klare fachliche Trennung
Ein sauberes Modell trennt mindestens diese Schichten klar voneinander:
| Layer | Worum es dort geht | Was dort nicht hinein sollte |
|---|---|---|
| Security Layer | Defender, BitLocker, Firewall, Sicherheitsbaselines, harte Schutzmechanismen | Allgemeine UX- oder Explorer-Konfiguration |
| Configuration Layer | OS-Verhalten, Explorer, Browser-Grundeinstellungen, Gerätekonfiguration, Plattformsteuerung | Compliance-Logik und Sicherheitsbewertungen |
| Compliance Layer | Regeln zur Bewertung, ob ein Gerät als compliant gilt oder nicht | Technische Konfiguration, die das Gerät erst compliant machen soll |
Das muss nicht dogmatisch oder übertheoretisch sein. Es geht einfach darum, dass eine Policy genau einen erkennbaren Hauptzweck hat. Wenn du beim Öffnen eines Objekts nicht in einem Satz sagen kannst, warum es existiert, dann ist die Trennung wahrscheinlich schon verloren gegangen.
Deterministische Assignments statt Zufall
Saubere Architektur bedeutet auch, dass Zielgruppen bewusst modelliert werden. Nicht "passt schon irgendwie", sondern wirklich nachvollziehbar. Also klare Device Groups für gerätebezogene Steuerung, klare User Groups für benutzerbezogene Zielbilder und dort, wo es Sinn ergibt, Assignment Filter statt noch einer weiteren Gruppe, die am Ende doch wieder nur eine kleine Variantenschublade ist.
Der entscheidende Punkt ist nicht, ob du eher mit Gruppen oder mit Filtern arbeitest. Der entscheidende Punkt ist, dass du ein Modell hast, das du erklären kannst. Wenn dein Scoping nicht vorhersagbar ist, dann ist dein Tenant auch nicht vorhersagbar. Architektur lebt davon, dass Wirkung nicht überraschen sollte.
Konsistentes Naming
Gute Namen sind in Intune keine Formalität, sondern Werkzeug. Wenn du ein Objekt im Portal siehst, solltest du im Idealfall sofort drei Dinge erkennen: welcher Layer es ist, für welche Plattform es gedacht ist und wofür es fachlich da ist.
Ein simples Schema reicht oft schon völlig:
| Beispiel | Bedeutung |
|---|---|
SEC-WIN-Defender-Baseline | Security-Policy für Windows mit klarer Defender-Baseline |
CFG-WIN-Explorer-Settings | Konfigurationspolicy für Windows-Explorer-Verhalten |
CMP-WIN-Compliance-Standard | Standard-Compliance-Regelwerk für Windows |
Du musst nicht genau dieses Präfixschema nehmen. Aber du brauchst irgendeines, das konsequent verwendet wird. Der Gewinn daraus ist riesig: Die Umgebung wird sofort lesbarer, Suchvorgänge werden einfacher und neue Leute können den Tenant deutlich schneller verstehen.
Weniger Policies, mehr Klarheit
Einer der gefährlichsten Irrtümer in Intune ist die Annahme, dass mehr Policies automatisch sauberer oder granularer seien. Das Gegenteil ist oft wahr. Viele kleine Policies ohne Konzept erzeugen meist mehr Reibung, nicht mehr Qualität. Dann zerfällt dein Tenant in dutzende Mini-Objekte, die jeweils für sich plausibel wirken, zusammen aber keine starke Struktur ergeben.
Besser sind weniger Policies mit sauberem fachlichem Schnitt. Nicht riesige Monsterobjekte für alles, aber eben auch nicht 30 Kleinst-Policies, die nur deshalb getrennt sind, weil irgendwann mal jemand schnell eine Ausnahme bauen wollte. Granularität ist nur dann gut, wenn sie einem nachvollziehbaren Modell folgt. Sonst ist sie einfach nur Lärm.
Architektur ist wichtiger als das Tool selbst
Hier liegt der eigentliche Kern: Intune zwingt dich nicht zu einer guten Architektur. Du kannst dir im Tool erstaunlich viel Wildwuchs leisten, ohne dass dich die Plattform sofort stoppt. Aber genau das ist die Falle. Intune erlaubt dir schlechte Struktur relativ lange, und danach bestraft es dich schleichend. Erst mit längeren Troubleshooting-Zeiten, dann mit Seiteneffekten, dann mit Team-Reibung und irgendwann mit einem Tenant, den niemand mehr anfassen will, ohne vorher zehnmal tief Luft zu holen.
Das Tool ist also nicht der Held und auch nicht der Bösewicht. Die Architektur entscheidet, ob Intune später leicht oder unerquicklich wird.
Realität schlägt Idealbild
Natürlich sieht kein echter Tenant so sauber aus wie eine Architekturfolie. Migrationen sind messy, Firmen kaufen andere Firmen, Altlasten hängen länger mit als geplant, lokale Anforderungen drücken rein, Sicherheitsvorgaben ändern sich und manchmal musst du pragmatisch liefern, bevor du elegant aufräumen kannst. Das ist normal. Perfekte Architektur gibt es in der Praxis selten.
Der wichtige Punkt ist nur: Zwischen perfekter Architektur und komplettem Chaos liegt eine ziemlich große Zone, in der man schon sehr viel gewinnen kann. Du musst nicht jeden Altfehler in einer Woche beseitigen. Aber du solltest anfangen, wieder Struktur einzuziehen. Klare Benennung, sauberes Scoping, definierte Layer, weniger Dopplungen, bewusstes User-vs-Device-Modell. Diese Dinge machen einen Tenant nicht perfekt, aber massiv besser.
Runbook: Einen kaputten Intune-Tenant wieder lesbar machen
Fazit
Intune ist kein kompliziertes Tool. Schlechte Architektur macht es kompliziert. Wenn ein Tenant schwer zu verstehen, schwer zu debuggen und voller Seiteneffekte ist, dann liegt das meistens nicht an einer geheimen Eigenheit der Plattform, sondern an fehlender Struktur. Die gute Nachricht ist nur: Genau das kann man ändern. Nicht über Nacht und nicht perfekt, aber Schritt für Schritt.
Und meistens reicht schon eine ehrliche Erkenntnis als Anfang: Das Problem ist nicht, dass der Tenant "gewachsen" ist. Das Problem ist, dass niemand entschieden hat, wie er eigentlich sauber aussehen soll.