Packaging-Wissen
SCCM-Pakete nach Intune überführen
Was aus einem SCCM-Paket in Intune erhalten bleibt, was neu gebaut werden muss und welche Reihenfolge den Rollout nicht blockiert.
Zwei Modelle, ein Ziel
Configuration Manager und Intune können dieselben Geräte parallel verwalten. Microsoft nennt das Co-Management: Das Gerät hat den ConfigMgr-Client und ist bei Intune registriert, und du entscheidest pro Workload, welche Seite die Autorität hat. Das ist der übliche Weg, wenn nicht alles an einem Tag umziehen soll.
Für die Paketierung heißt das: Du baust nicht sofort alles neu, sondern verschiebst die App-Verwaltung, wenn die Basis steht.
Was übernommen wird
Der Installer bleibt derselbe. Was neu entsteht, ist die Verpackung: Installationsbefehl, Deinstallationsbefehl, Detection und Rückgabecodes. Ein SCCM-Paket, das nur einen Befehl und eine Programmdatei kennt, hat oft keine brauchbare Detection — die muss neu definiert werden.
Der Payload und die stillen Parameter sind dagegen meist direkt weiterverwendbar.
Was neu entsteht
Vier Dinge entstehen neu: die Zuweisung (Gruppen statt Sammlungen), die Detection, die Rückgabebehandlung und die Dokumentation. Wer diese vier Punkte als „Migration" versteht, unterschätzt den Aufwand; wer sie als Neubau versteht, macht zu viel.
Reihenfolge und Rückfallebene
Zuerst Geräte in einen verwaltbaren Zustand bringen, dann eine kleine Pilotgruppe, dann Workload für Workload. Bei Apps: mit Paketen beginnen, die keine Abhängigkeiten haben und deren Deinstallation sauber läuft.
Die alte Zuweisung bleibt verfügbar, bis die neue auf einer ausreichenden Zahl Geräte nachweislich funktioniert.
Erste Pakete auswählen
Gute Kandidaten: kleine MSIs, klare Detection, keine Abhängigkeiten. Schlechte Kandidaten: Pakete mit unbekannter Skriptlogik, Pakete ohne dokumentierte Deinstallation, Pakete, die niemand mehr zuweist.
---