Intune und MECM: Wann Co-Management trägt – und wann nicht

Co-Management ist ein Betriebsmodell

Die technische Aktivierung ist der kleinste Teil von Co-Management. Der schwierige Teil beginnt danach: Ein Gerät empfängt weiterhin Funktionen aus MECM und zugleich Vorgaben aus Intune. Teams müssen verstehen, welche Plattform für welchen Zustand verantwortlich ist, welche Gruppe eine Änderung erhält und wie sich ein Problem auf die richtige Quelle zurückführen lässt. Ohne dieses Modell entsteht keine Modernisierung, sondern zusätzliche Mehrdeutigkeit.

Die zentrale Entscheidungsfrage lautet daher nicht: Können wir Co-Management einschalten? Sie lautet: Welcher konkrete betriebliche Zweck rechtfertigt die parallele Steuerung, und können wir diesen Zustand messen, unterstützen und zurücknehmen? Ein möglicher Zweck ist die schrittweise Verlagerung ausgewählter Workloads. Ein anderer ist ein bewusster längerer Mischbetrieb, weil vorhandene MECM-Fähigkeiten für bestimmte Anwendungen oder OSD-Prozesse weiterhin benötigt werden.

Beide Varianten können tragfähig sein. Problematisch ist der unentschiedene Zwischenzustand, in dem niemand weiß, ob eine Policy aus dem alten oder neuen Weg stammt, ob ein fehlgeschlagenes Deployment in MECM oder Intune nachgearbeitet wird und welche Statusquelle für eine Freigabe zählt.

1. Der Ausgangszustand muss bekannt sein

Vor der ersten Workload-Verschiebung braucht das Team ein ehrliches Bild der MECM- und Intune-Umgebung. Dazu gehören Clientgesundheit, Geräteeinbindung, Grenzen und Collections, Gruppenlogik, Policy-Landschaft, Anwendungen, Updateprozesse, Content-Verteilung, Reporting und Supportabläufe. Historische Ausnahmen werden nicht automatisch zu Anforderungen; sie müssen aber sichtbar sein, bevor eine neue Plattform auf denselben Geräten wirkt.

Besonders wichtig ist die Identität eines Geräts. Doppelte oder veraltete Objekte, unklare primäre Nutzer und inkonsistente Gruppenmitgliedschaften machen Pilotierung unzuverlässig. Ein Gerät kann technisch verwaltet erscheinen und dennoch in einer falschen Zielgruppe landen. Co-Management verstärkt solche Datenprobleme, weil zwei Plattformen ihre Entscheidungen auf unterschiedliche Objekt- und Gruppensichten stützen können.

Ein MECM- und Intune-Health-Check ist dann sinnvoll, wenn der Ist-Zustand nicht mit ausreichender Sicherheit beschrieben werden kann. Der Health-Check trennt akute technische Fehler, strukturelle Schulden und bewusste Grenzen, bevor sie in einen Übergang übernommen werden.

2. Workloads brauchen eine fachliche Begründung

Ein Workload wird nicht verschoben, weil er in einer Konsole auswählbar ist. Die Entscheidung sollte einen beobachtbaren Nutzen und einen klaren Owner haben. Beispiele sind ein besser geeigneter Policy-Weg für mobile Geräte, eine standardisierte Bereitstellung für eine bestimmte Anwendungsklasse oder die Reduktion eines alten Betriebsprozesses. Die Wirkung muss sich an Geräten und Abläufen prüfen lassen.

Für jeden Workload werden mindestens Zielgruppe, Vorbedingungen, bestehende MECM-Regeln, neue Intune-Regeln, Überschneidungen, Pilotdauer, Erfolgskriterien und Rückfall beschrieben. Erst diese Matrix macht eine technische Aktivierung zu einem kontrollierten Change. Sie verhindert auch, dass mehrere Teams gleichzeitig verwandte Einstellungen verändern, ohne voneinander zu wissen.

Die Reihenfolge hängt von der Umgebung ab. Ein scheinbar einfacher Workload kann hohe betriebliche Abhängigkeiten haben; ein technisch komplexer Bereich kann gut eingegrenzt und deshalb kontrollierbar sein. Starre universelle Sequenzen sind weniger hilfreich als eine Bewertung nach Auswirkung, Reversibilität, Datenqualität und Supportfähigkeit.

3. Gruppen sind Teil der Architektur

Pilotgruppen dürfen nicht bloß bequem klein sein. Sie müssen die Eigenschaften enthalten, an denen der Workload scheitern könnte: Gerätetypen, Standorte, Netzwerkbedingungen, Nutzerprofile, Anwendungen und Supportwege. Eine Gruppe nur aus IT-Geräten erzeugt häufig ein beruhigendes, aber schwaches Signal.

Gruppenmitgliedschaft muss nachvollziehbar sein. Dynamische Regeln, verschachtelte Gruppen, Collections und Synchronisationswege können Verzögerungen oder unerwartete Zugehörigkeiten erzeugen. Für den Pilot braucht es deshalb eine überprüfbare Liste der tatsächlichen Zielgeräte und einen Zeitpunkt, zu dem diese Liste als Bezugsmenge gilt. Sonst ist eine Erfolgsquote nicht interpretierbar.

Auch Ausschlüsse gehören in dasselbe Modell. Ein Ausschluss ohne Owner und Begründung wird leicht dauerhaft. Ein guter Ausnahmeprozess dokumentiert, warum ein Gerät nicht dem Standard folgt, wann die Entscheidung erneut geprüft wird und welcher alternative Betriebsweg gilt.

4. Policy-Konflikte sind kein Randfall

MECM, Gruppenrichtlinien und Intune können denselben fachlichen Zustand auf verschiedenen Wegen beeinflussen. Ein Konflikt zeigt sich nicht immer als klare Fehlermeldung. Er kann als wechselnde Einstellung, verzögerte Anwendung oder scheinbar zufällige Abweichung auftreten. Deshalb muss vor dem Pilot bekannt sein, welche vorhandenen Regeln den neuen Workload berühren.

Policy-Design in Microsoft Intune sollte Ziele und Verantwortlichkeiten erkennbar machen. Große Sammelprofile sind schwerer zu testen und zurückzunehmen als klar geschnittene Konfigurationen. Gleichzeitig führt eine zu starke Fragmentierung zu unübersichtlichen Zuweisungen. Der sinnvolle Schnitt orientiert sich an fachlichem Zweck, gemeinsamem Lebenszyklus und Owner – nicht an der Anzahl sichtbarer Einstellungen.

Für Konflikte braucht der Betrieb eine Diagnosefolge: Welcher Zustand wird erwartet? Welche Quellen können ihn setzen? Wann haben sie zuletzt gewirkt? Welche Gruppe und welcher Filter waren maßgeblich? Wie wird ein Gerät kontrolliert neu bewertet? Diese Fragen gehören ins Runbook, bevor die Breite erreicht wird.

5. Anwendungen benötigen mehr als einen Upload

Anwendungsbereitstellung ist häufig ein Prüfstein für Co-Management. MECM verfügt möglicherweise über etablierte Pakete, Abhängigkeiten und Reports; Intune eröffnet einen anderen Bereitstellungsweg, aber macht komplexe Fachanwendungen nicht automatisch einfacher. Installationskontext, Detection, Rückgabecodes, Neustarts, Benutzeranteile und Deinstallation bleiben dieselben technischen Fragen.

Anwendungen sollten deshalb nach Klassen bewertet werden. Standardsoftware mit geeignetem Katalog- oder Herstellerweg kann anders behandelt werden als Fach- und Legacy-Anwendungen. Für letztere ist eine reproduzierbare Paketierungs-Factory oft der wichtigere Modernisierungsschritt als der bloße Wechsel der Konsole.

Während eines Übergangs muss eindeutig sein, welcher Bereitstellungsweg für eine Anwendung gilt. Doppelte Angebote oder Deployments können Nutzer verwirren und den Zustand schwer messbar machen. Eine Anwendungsmatrix mit Plattform, Version, Zielgruppe, Detection und Owner verhindert diese Doppelsteuerung.

6. Reporting muss Entscheidungen ermöglichen

MECM und Intune können denselben Client mit unterschiedlichen Zeitständen und Statusbegriffen darstellen. Ein gemeinsames Managementbild darf diese Unterschiede nicht einfach nebeneinanderstellen. Es muss erklären, welche Bezugsmenge gilt, wie alt ein Status ist und welche Aktion aus einer Fehlerklasse folgt.

Für jeden Ring werden deshalb wenige, aber belastbare Kennzahlen festgelegt: tatsächliche Zielgeräte, erreichte Geräte, erwarteter Zustand, technische Fehler, organisatorisch blockierte Fälle und offene Ausnahmen. Die zugrunde liegenden Gerätelisten müssen verfügbar bleiben. Eine hohe Prozentzahl ohne die blockierten Kategorien kann einen kritischen Sonderfall verdecken.

Reporting ist auch ein Übergabeartefakt. Wenn nur das Projektteam die Rohdaten interpretieren kann, ist der neue Betriebsweg nicht fertig. Betrieb und Service Desk brauchen eine gemeinsame Sprache für Status, Diagnose und Eskalation.

Entscheidungscheckliste für einen Workload

Ein Workload ist bereit für einen Pilot, wenn die folgenden Punkte nicht nur besprochen, sondern belegt oder bewusst entschieden wurden:

• [ ] Der betriebliche Zweck der Verlagerung ist in einem Satz beschrieben.
• [ ] Ein fachlich und technisch handlungsfähiger Owner ist benannt.
• [ ] Die aktuelle MECM-, GPO- und Intune-Wirkung auf denselben Zustand ist dokumentiert.
• [ ] Die Pilotgruppe bildet relevante Geräte, Nutzer, Standorte und Anwendungen ab.
• [ ] Die tatsächliche Zielmenge kann zu einem festen Zeitpunkt überprüft werden.
• [ ] Neue Policies oder Anwendungen haben klare Namen, Scope und Änderungsverantwortung.
• [ ] Überschneidungen und Ausschlüsse sind sichtbar und begründet.
• [ ] Erfolg, Warnung, Abbruch und Rückfall sind als beobachtbare Kriterien formuliert.
• [ ] Logs und Statusquellen sind dem Betrieb zugänglich und verständlich.
• [ ] Service Desk und Betrieb besitzen Diagnose- und Eskalationsschritte.
• [ ] Die Beobachtungszeit deckt Neustart, Policy-Aktualisierung und reale Nutzung ab.
• [ ] Nach dem Pilot ist eine konkrete Entscheidung vorgesehen: ausweiten, nacharbeiten, zurücknehmen oder Ausnahme bilden.

Fehlt bei einem Punkt nur eine Information, kann sie vor dem Pilot ergänzt werden. Fehlt ein Owner oder ein Rückfallweg, ist das ein struktureller Blocker. Der Unterschied ist wichtig: Nicht jede Lücke rechtfertigt Stillstand, aber manche Lücken machen einen kontrollierten Versuch unmöglich.

Wann Co-Management trägt

Ein tragfähiger Zustand hat vier Merkmale. Erstens ist die Zuständigkeit je Workload und Zielgruppe eindeutig. Zweitens sind Gruppen und Geräteobjekte zuverlässig genug für eine begrenzte Steuerung. Drittens kann der Betrieb den erwarteten Zustand und seine Quelle diagnostizieren. Viertens führt jeder Pilot zu einer dokumentierten Entscheidung statt zu einem dauerhaften „läuft erst einmal so“.

Co-Management trägt auch dann, wenn nicht sofort alle Workloads wechseln. Ein bewusst beibehaltenes MECM-Verfahren kann sinnvoll sein, solange sein Zweck, seine Schnittstellen und sein Ende oder seine Dauerentscheidung dokumentiert sind. Modernisierung bedeutet nicht, vorhandene Fähigkeiten um jeden Preis abzuschalten. Sie bedeutet, unklare Abhängigkeiten in steuerbare Entscheidungen zu überführen.

Wann es nicht trägt

Problematisch wird der Ansatz, wenn Co-Management als Ausweg aus einer ungepflegten MECM-Umgebung dienen soll. Historische Collections, fehlerhafte Clients und unklare Anwendungen verschwinden nicht durch eine zweite Plattform. Sie können sogar schwerer diagnostizierbar werden. Ebenso riskant ist eine große Pilotgruppe ohne repräsentative Struktur: Sie erzeugt viel Aktivität, aber wenig Erkenntnis.

Ein weiterer Warnhinweis ist fehlende Betriebsverantwortung. Wenn ein Projekt neue Policies ausrollt, der Service Desk aber weder Status noch Rückfall kennt, ist die technische Funktion noch keine betriebliche Fähigkeit. Gleiches gilt für Reports, die nur in einer Projektpräsentation verständlich sind.

Co-Management trägt außerdem nicht, wenn jede Ausnahme still verlängert wird. Dann entstehen zwei Standards und ein wachsendes Sonderfallregister. Ausnahmen brauchen Entscheidung, Owner und einen alternativen Supportweg.

Ein kontrollierter Übergang in Ringen

Der erste Ring bleibt klein genug für direkte Beobachtung, aber breit genug für relevante Unterschiede. Nach der Aktivierung wird nicht nur geprüft, ob der Workload „grün“ erscheint. Geräte werden auf tatsächlichen Zustand, Konflikte, zeitliche Verzögerung und Supportfälle untersucht. Befunde fließen in Policy, Gruppenregel, Runbook oder Entscheidung zurück.

Der nächste Ring startet erst nach dem vorgesehenen Review. Dabei ist Rücknahme kein Scheitern. Ein sauber zurückgenommener Pilot kann mehr Wert liefern als eine breite Aktivierung mit ungeklärten Fehlern. Die Organisation lernt, welche Voraussetzung fehlte, und erhält einen klaren Weg für den nächsten Versuch.

Fazit: Parallele Plattformen brauchen eindeutige Entscheidungen

Intune und MECM können sich in einem kontrollierten Modell ergänzen. Dafür müssen sie nicht dieselben Dinge tun, sondern ihre jeweiligen Aufgaben nachvollziehbar erfüllen. Workload-Matrix, Gruppenarchitektur, Policy-Hygiene, Anwendungsstandard, Reporting und Betriebsübergabe bilden den eigentlichen Co-Management-Entwurf.

Wer den Ausgangszustand und die Konflikte zuerst klären möchte, beginnt mit dem MECM- und Intune-Health-Check. Wer bereits einen klaren Workload und eine repräsentative Pilotgruppe hat, kann direkt einen begrenzten Übergang planen. In beiden Fällen gilt: Wo Standard-IT endet, fangen wir an – mit eindeutiger Verantwortung statt paralleler Unklarheit.