Softwareverteilung mit Intune und SCCM/MECM

Warum das Thema komplizierter ist, als es aussieht

“Installier mal die neue Version auf allen Rechnern” klingt nach einer Zeile PowerShell. In der Praxis steckt dahinter ein ganzes Regelwerk: Wie stellst du sicher, dass die App nicht doppelt installiert wird? Wie erkennst du, ob eine Installation wirklich erfolgreich war und nicht nur “exit code 0, aber trotzdem kaputt”? Wie rollst du eine fehlerhafte Version aus, ohne gleich die ganze Firma lahmzulegen? Und wie belegst du gegenueber Geschaeftsleitung oder Revisor, dass alle Clients wirklich gepatcht sind?

Genau das ist der Unterschied zwischen “Software verteilen” und “Softwareverteilung als Prozess betreiben”. Intune (cloud-nativ, Teil von Microsoft Endpoint Manager) und SCCM/MECM (on-prem, heute offiziell “Microsoft Configuration Manager” genannt) loesen das mit unterschiedlichen, aber konzeptionell verwandten Mechanismen. In vielen Schweizer KMU laeuft heute ein hybrides Modell: Co-Management, bei dem SCCM/MECM die Workloads schrittweise an Intune abgibt, bis am Ende ein reiner Cloud-Client uebrig bleibt.

Dieser Artikel geht davon aus, dass du Intune-Grundlagen bereits kennst und jetzt tiefer in die eigentliche Softwareverteilung einsteigen willst.

Architekturueberblick: Wo laeuft was

Fuer ein Schweizer KMU mit 50-500 Clients, die vorwiegend im Homeoffice oder an mehreren kleinen Standorten sitzen, ist Intune heute meist die richtige Wahl. SCCM/MECM bleibt sinnvoll, wenn du sehr viele Clients an einem Standort mit begrenzter Internet-Uplink-Bandbreite hast (Distribution Points sparen massiv Traffic) oder wenn du On-Premises-Pflichten hast (z. B. Daten duerfen das Netz nicht cloud-seitig verlassen, auch wenn nur Metadaten betroffen waeren).

Win32-App-Pakete: Das .intunewin-Format verstehen

Intune kennt mehrere App-Typen: Line-of-Business (LOB, einfache MSI/APPX), Store-Apps, Web-Links - und Win32-Apps, die faktisch alles koennen, was ein normales Windows-Setup kann (MSI, EXE, PowerShell-Skript, sogar MSIX). Fuer die meisten “richtigen” Unternehmensanwendungen (7-Zip, Adobe Reader, ERP-Client, CAD-Tools) ist der Win32-App-Typ der Standard.

Damit Intune ein beliebiges Setup verteilen kann, muss es zuerst in ein .intunewin-Paket verpackt werden. Das Tool dafuer heisst IntuneWinAppUtil (Microsoft Win32 Content Prep Tool) und ist ein simples Kommandozeilenprogramm.

Paket erstellen

# Ordnerstruktur vorbereiten
# C:\Pakete\7zip\Source\7z2408-x64.exe
# C:\Pakete\7zip\Output\

.\IntuneWinAppUtil.exe -c "C:\Pakete\7zip\Source" `
                        -s "7z2408-x64.exe" `
                        -o "C:\Pakete\7zip\Output" `
                        -q

Das Tool nimmt den kompletten Quellordner (-c), packt ihn komprimiert und AES-256-verschluesselt, und legt eine .intunewin-Datei im Output-Ordner ab. Diese Datei ist nicht per Doppelklick installierbar - sie ist ein reiner Container, den nur der Intune Management Extension Client auf dem Endgeraet wieder entschluesseln kann.

Beim Erstellen eines MSI-basierten Pakets liest das Tool automatisch den ProductCode aus der MSI-Datenbank aus und schreibt ihn in die .intunewin-Metadaten (<MsiProductCode>). Das macht spaeter die Detection Rule fuer MSI-Pakete trivial.

Install-/Uninstall-Befehle in Intune

Nach dem Upload in Intune (Apps > Windows > App hinzufuegen > Win32-App) traegst du ein:

Installationsbefehl:  msiexec /i "7z2408-x64.msi" /qn /norestart
Deinstallationsbefehl: msiexec /x "{PRODUCT-GUID}" /qn /norestart

Fuer EXE-basierte Installer ist der Deinstallationsbefehl oft der kniffligste Teil, weil viele Setups keinen dokumentierten Silent-Uninstall haben (dazu gleich mehr im Kapitel Silent-Parameter).

Detection Rules: Das Herzstueck der Zuverlaessigkeit

Die Detection Rule beantwortet eine einzige Frage: “Ist die Anwendung auf diesem Geraet bereits (in dieser Version) installiert?” Ohne korrekte Detection Rule installiert Intune die App bei jedem Sync-Zyklus neu, meldet Endlos-Fehler oder - schlimmer - meldet faelschlich “installiert”, obwohl gar nichts passiert ist.

Intune bietet vier Detection-Rule-Typen:

1. MSI-Product-Code - am zuverlaessigsten fuer MSI-Pakete, wird automatisch aus dem Paket vorbefuellt.
2. Datei/Ordner vorhanden - prueft z. B. Version einer EXE/DLL im Installationsverzeichnis.
3. Registry-Wert - prueft Schluessel/Wert, z. B. unter HKLM\SOFTWARE\Vendor\App.
4. Benutzerdefiniertes Skript - PowerShell-Skript, das per Exit Code (0 = installiert) und/oder STDOUT antwortet.

Beispiel: Datei-Detection mit Versionspruefung

# Detection Rule Typ "Datei", Erweiterte Optionen:
# Pfad:  C:\Program Files\7-Zip
# Datei: 7z.exe
# Eigenschaft: Version
# Operator: Groesser als oder gleich
# Wert: 24.8.0.0

Beispiel: Custom-Script-Detection (fuer komplexe Faelle)

Wenn eine App keine verlaessliche MSI-GUID oder Registry-Spur hinterlaesst (z. B. portable Tools oder Apps mit dynamischer Versionierung), hilft ein Skript:

$installPath = "C:\Program Files\Contoso\App\app.exe"
if (Test-Path $installPath) {
    $version = (Get-Item $installPath).VersionInfo.FileVersion
    if ([version]$version -ge [version]"3.2.1.0") {
        Write-Output "Installed"
        exit 0
    }
}
exit 1

Bei SCCM/MECM heisst das Konzept Detection Method und funktioniert im Application Model analog, nur mit mehr Freiheitsgraden (mehrere Regeln kombinierbar mit UND/ODER, siehe naechstes Kapitel).

Intune Deployment Rings: Kontrollierter Rollout statt Big Bang

Ein Deployment Ring ist keine feste Intune-Funktion mit eigenem Blade, sondern ein Konzept, das du ueber Entra-ID-Gruppen, Zuweisungsfilter und zeitversetzte Assignments selbst baust. Fuer Windows-Updates gibt es dedizierte “Update Rings”-Policies, fuer App-Rollouts nutzt du gestaffelte Gruppenzuweisungen.

Typisches 4-Ring-Modell fuer ein KMU

Umsetzung mit dynamischen Entra-ID-Gruppen

# Dynamische Gruppe fuer Ring 1 (Pilot) via Attribut extensionAttribute1
# Regel in Entra ID (Gruppenmitgliedschaftsregel):
(device.extensionAttribute1 -eq "Ring1-Pilot")

In der Intune-App-Zuweisung setzt du dann fuer Ring 0/1 den Verfuegbarkeitszeitpunkt sofort, fuer Ring 2/3 planst du das Assignment mit “Verfuegbar ab” (Available time) einige Tage spaeter. Bei “Erforderlich” (Required) Assignments kannst du zusaetzlich eine Installationsfrist (Deadline) setzen, ab der Intune die Installation erzwingt (auch ausserhalb der Nutzerinteraktion).

Entscheidungsbaum: Wie schnell soll etwas ausgerollt werden?

Ist es ein Sicherheits-Patch mit aktiv ausgenutzter Schwachstelle (0-Day)?
├─ Ja  -> Express-Rollout: Ring 0 sofort, Ring 1+2+3 nach 24-48h zusammengelegt
└─ Nein
   ├─ Ist es ein Major-Feature-Update (z. B. Windows-Featureversion)?
   │  ├─ Ja -> Volles 4-Ring-Modell, mind. 3-4 Wochen Gesamtlaufzeit
   │  └─ Nein
   │     ├─ Ist es eine neue Business-App-Version mit UI-Aenderungen?
   │     │  ├─ Ja -> Ring 0+1 zwingend, Kommunikation an Endnutzer vorher
   │     │  └─ Nein (reines Bugfix-Update) -> Ring 0 kurz, dann Ring 2+3 zusammen

SCCM/MECM Application Model im Detail

Das Application Model in SCCM/MECM (seit ConfigMgr 2012, im Gegensatz zum alten “Package/Program”-Modell) trennt sauber zwischen:

• Application - der logische Container (Name, Icon, Kategorie), den Benutzer im Software Center sehen.
• Deployment Type - die technische Installationsmethode (z. B. MSI fuer x64, ein anderer Deployment Type als App-V-Variante fuer Terminalserver).
• Requirements - Bedingungen, unter denen ein Deployment Type ueberhaupt in Frage kommt (OS-Version, RAM, freier Speicher, Custom-Global-Conditions).
• Detection Method - wie oben beschrieben, prueft Installationsstatus.
• Deployment - die eigentliche Zuweisung an eine Collection mit Zeitplan (Available/Required), Maintenance Windows und User Experience (silent, mit Benachrichtigung, mit Countdown).

Eine App kann mehrere Deployment Types haben - SCCM waehlt automatisch den ersten, dessen Requirements erfuellt sind (Prioritaetsreihenfolge in der Liste). Das ist ein grosser Vorteil gegenueber Intune, wo du fuer unterschiedliche Architekturen (x86/x64/ARM64) meist getrennte App-Objekte pflegst.

# Beispiel: Neue Application per PowerShell-Modul ConfigurationManager anlegen
New-CMApplication -Name "7-Zip 24.08" -Publisher "Igor Pavlov" -SoftwareVersion "24.08"

Add-CMMsiDeploymentType -ApplicationName "7-Zip 24.08" `
    -ContentLocation "\\CM01\Sources$\Apps\7zip\7z2408-x64.msi" `
    -InstallationBehaviorType InstallForSystem `
    -UninstallOption SameAsInstall

Start-CMContentDistribution -ApplicationName "7-Zip 24.08" -DistributionPointGroupName "CH-Alle-DPs"

New-CMApplicationDeployment -Name "7-Zip 24.08" `
    -CollectionName "Ring2-Standort-Zuerich" `
    -DeployAction Install -DeployPurpose Required `
    -UserNotification DisplaySoftwareCenterOnly `
    -TimeBaseOn LocalTime `
    -AvailableDateTime (Get-Date).AddDays(1) `
    -DeadlineDateTime (Get-Date).AddDays(8)

Silent-Install-Parameter finden: Der unterschaetzte Zeitfresser

MSI-Installer sind standardisiert (msiexec /i paket.msi /qn /norestart), aber EXE-Installer (Setup-Wrapper von InstallShield, NSIS, Inno Setup, WiX Bootstrapper) haben keinen einheitlichen Standard. Hier eine Vorgehensweise, die in der Praxis fast immer zum Ziel fuehrt:

Schritt fuer Schritt

1. Hersteller-Dokumentation pruefen. Viele Hersteller (Adobe, Zoom, Google Chrome) veroeffentlichen dedizierte “Enterprise Deployment”-Guides mit fertigen Silent-Switches.
2. Eingebaute Hilfe abfragen.

   setup.exe /?
   setup.exe /help
   setup.exe --help

3. Installer-Typ erkennen. Rechtsklick > Eigenschaften > Details zeigt oft den Compiler. Alternativ mit 7-Zip oeffnen (die meisten Wrapper sind entpackbare Archive) - ein setup.exe, das sich mit 7-Zip oeffnen laesst und eine [Setup].isscript.msi oder Inno-Ordnerstruktur enthaelt, verraet den Installer-Typ sofort.
4. Typische Switches nach Installer-Familie durchprobieren:

5. Tools zur Not verwenden. ORCA (aus dem Windows SDK) zum Inspizieren von MSI-Property-Tabellen, oder Process Monitor (Sysinternals) waehrend einer manuellen Installation, um zu sehen, welche Kommandozeile der Setup-Wrapper intern an die eigentliche MSI weitergibt.
6. Immer mit Logging testen, bevor du breit ausrollst - ein Silent-Install, der “erfolgreich” durchlaeuft, aber im Log Warnungen zu fehlenden Voraussetzungen zeigt, rettet dich vor spaeteren Ring-2/3-Ueberraschungen.

Patch-Compliance-Reporting: Beweisen statt Hoffen

Ein Rollout ist erst abgeschlossen, wenn du belegen kannst, WELCHE Geraete WELCHEN Patchstand haben - nicht nur “Update wurde verteilt”, sondern “Update ist installiert und aktiv”.

Intune: Windows Update for Business Reports

Fuer aggregierte Compliance-Uebersicht ueber Feature- und Qualitaetsupdates nutzt du “Windows Update for Business Reports” (Log-Analytics-basiert, kostenlos, funktioniert auch mit WSUS/SCCM-verwalteten Geraeten als reines Reporting-Layer). Sinnvolle KQL-Abfrage fuer den Log-Analytics-Workspace:

UCClient
| join kind=inner (UCClientReadinessStatus) on Computer
| where OSVersion !contains "22H2" // Beispiel: alle nicht auf aktuellem Feature-Level
| project Computer, OSVersion, LastScan, ReadinessStatus
| order by LastScan desc

Fuer Update-Ring-Compliance direkt in Intune: Geraete > Windows > Update Rings > Ring auswaehlen > “Berichte” zeigt pro Geraet Status (installiert, ausstehend, fehlgeschlagen) inklusive Fehlercode.

SCCM/MECM: Klassisches SQL-Reporting

SCCM speichert alle Compliance-Daten strukturiert in der Site-Datenbank. Eine bewaehrte Abfrage fuer fehlende kritische Updates:

SELECT
    sys.Name0 AS ComputerName,
    ui.Title0 AS UpdateTitle,
    ui.Severity0 AS Severity,
    cs.LastActiveTime
FROM v_R_System sys
JOIN v_CICurrentComplianceStatus ccs ON sys.ResourceID = ccs.ResourceID
JOIN v_UpdateInfo ui ON ccs.CI_ID = ui.CI_ID
JOIN v_CH_ClientSummary cs ON sys.ResourceID = cs.ResourceID
WHERE ccs.Status = 2  -- 2 = Required (fehlt)
  AND ui.Severity0 = 10  -- Critical
ORDER BY sys.Name0;

Compliance-Kennzahlen, die im KMU wirklich zaehlen

Typische Fallstricke im Schweizer KMU-Alltag

• 32-Bit-Reste in 64-Bit-Umgebungen: Detection Rules, die per Registry pruefen, muessen bei 32-Bit-Anwendungen auf 64-Bit-Windows den Pfad HKLM:\SOFTWARE\WOW6432Node\... beruecksichtigen - sonst greift die Regel nie.
• Content Library laeuft voll: Bei SCCM wird Content bei jeder neuen App-Version dupliziert, wenn du nicht sauber alte Deployment-Type-Versionen aufraeumst. Regelmaessige Content-Library-Bereinigung einplanen.
• Intune-Sync-Verzoegerung unterschaetzt: Ein Geraet meldet sich im Schnitt alle 8 Stunden bei Intune - ein “sofortiges” Required-Assignment kann trotzdem erst Stunden spaeter greifen, ausser du erzwingst per Sync in der Company-Portal-App oder per Intune-Aktion “Jetzt synchronisieren”.
• Lizenzpflicht vergessen: Bevor du eine Software breit ausrollst, pruefe die Lizenzbedingungen - siehe Software-Lizenzmanagement und Audit, damit der Rollout nicht zum Compliance-Problem wird.
• Keine Rollback-Strategie: Plane vor jedem grossen Rollout, wie du eine fehlerhafte Version schnell wieder zurueckziehst (Assignment auf “Nicht zugewiesen” setzen reicht bei Intune NICHT, um bereits installierte Software zu entfernen - dafuer brauchst du eine explizite Uninstall-Zuweisung).

Weiterlernen

• Win32 App Management in Microsoft Intune (Microsoft Learn)
• Vorbereiten einer Win32-App fuer den Upload in Microsoft Intune
• Manage Windows Update Ring Policies (Microsoft Learn)
• Create applications - Configuration Manager (Microsoft Learn)
• Reports for Windows Feature Update Policies (Microsoft Learn)
• Befehlszeilenoptionen fuer Microsoft Standard Installer (msiexec)

Videos

YouTube