Sektion 43: Microsoft 365 Apps Deployment: Office CSP vs. Win32 & Update-Kanäle

Kaum eine Anwendung ist in Unternehmen so allgegenwärtig wie Microsoft 365 Apps – und kaum eine wird so oft unterschätzt. Wenn hier etwas schiefgeht, steht nicht eine Abteilung, sondern das ganze Unternehmen. Trotzdem wird die Office-Bereitstellung oft mit ein paar Klicks erledigt und nie wieder angefasst. Spätestens beim ersten Kanalwechsel, bei Altlasten aus MSI-Zeiten oder bei einem hängenden Autopilot-Enrollment rächt sich das.

In Sektion 42 haben wir gesehen, dass „Evergreen“-Apps eine eigene Update-Logik brauchen. Microsoft 365 Apps ist das Paradebeispiel dafür: Die Suite wird nicht als Paket verteilt, sondern über Click-to-Run direkt aus dem Office CDN installiert und aktualisiert sich anschließend selbst. In dieser Sektion schauen wir uns an, welche Bereitstellungswege Intune bietet, wann Sie welchen nutzen sollten und wie Sie Update-Kanäle sauber steuern.

Grundkonzepte: Wie Intune Microsoft 365 Apps ausrollt

Click-to-Run statt MSI

Microsoft 365 Apps basiert auf der Click-to-Run-Technologie (C2R). Anders als bei einer klassischen Win32-App lädt der Client die Installationsdateien nicht aus Intune, sondern von officecdn.microsoft.com. Gesteuert wird das Ganze über das Office Deployment Tool (ODT) und eine XML-Konfiguration, die festlegt, welche Apps, welche Architektur, welche Sprachen und welcher Update-Kanal installiert werden.

Wichtig: Click-to-Run und MSI-basiertes Office vertragen sich nicht. Liegt auf dem Gerät noch ein Office 2016 MSI oder ein altes Visio/Project als MSI, schlägt die Installation fehl, solange Sie diese Altlasten nicht entfernen.

Die zwei Bereitstellungswege

Intune bietet Ihnen zwei grundlegend verschiedene Wege:

• App-Typ „Microsoft 365 Apps (Windows 10 und höher)“: Der eingebaute Weg. Intune übergibt die Konfiguration über den Office CSP an das Gerät. Sie konfigurieren die Suite entweder über den Configuration Designer (Klick-Oberfläche) oder per eigenem XML. Die Installation läuft dabei nicht über die Intune Management Extension (IME).
• Win32-App mit ODT: Sie verpacken setup.exe aus dem Office Deployment Tool zusammen mit Ihrer XML-Datei als .intunewin und rollen das Ganze wie jede andere Win32-App aus (siehe Sektion 31 und 32). Die Installation läuft dann über die IME – mit Detection Rule und Return Codes.

Welcher Weg passt wann?

Der eingebaute App-Typ ist schnell eingerichtet und für einfache Szenarien völlig ausreichend. Microsoft empfiehlt jedoch ausdrücklich, Microsoft 365 Apps als Win32-App auszurollen, wenn die Suite während der Enrollment Status Page (ESP) bei Windows Autopilot als blockierende App getrackt werden soll. Der Grund: Da der Office CSP nicht über die IME läuft, kann die Office-Installation parallel zu einer Win32-Installation starten. Diese Gleichzeitigkeit führt im schlimmsten Fall dazu, dass die ESP fehlschlägt.

Außerdem gilt: Pro Gerät wird nur eine Microsoft-365-Apps-Bereitstellung ausgeliefert, und bei eigenen XML-Konfigurationen zeigt der Status nur das Ergebnis des Installationsversuchs – nicht, ob Office aktuell wirklich installiert ist.

Praxis-Implementierung: Schritt für Schritt

Variante 1: Der eingebaute App-Typ

Im Intune Admin Center finden Sie den App-Typ unter Apps > Alle Apps > Erstellen > Microsoft 365 Apps > Windows 10 und höher. Im Configuration Designer legen Sie die wichtigsten Parameter fest:

• Office-Apps: Wählen Sie gezielt aus. OneDrive (Groove) und Skype for Business (Lync) brauchen die meisten Umgebungen nicht mehr.
• Architektur: 64-Bit ist heute der Standard. 32-Bit nur, wenn alte Add-ins oder VBA-Makros mit 32-Bit-Abhängigkeiten das zwingend erfordern.
• Update-Kanal: Für die meisten Unternehmen ist der Monthly Enterprise Channel die richtige Wahl (mehr dazu unten).
• Andere Versionen entfernen: Auf „Ja“ setzen, wenn noch MSI-Office auf den Geräten liegen kann. Achtung: Dabei werden alle Office-MSI-Produkte entfernt, nicht nur die ausgewählten.
• Gemeinsame Computeraktivierung: Nur für Shared Devices, Terminalserver oder AVD-Hosts.

Variante 2: Win32-App mit dem Office Deployment Tool

Aus dem Office Deployment Tool benötigen Sie nur die setup.exe. Die XML-Datei erstellen Sie per Hand oder über das Office Customization Tool unter config.office.com.

Eine praxistaugliche Installations-XML (install.xml) sieht so aus:

<Configuration>
  <Add OfficeClientEdition="64" Channel="MonthlyEnterprise" MigrateArch="TRUE">
    <Product ID="O365ProPlusRetail">
      <Language ID="MatchOS" Fallback="de-de" />
      <ExcludeApp ID="Groove" />
      <ExcludeApp ID="Lync" />
    </Product>
  </Add>
  <Property Name="SharedComputerLicensing" Value="0" />
  <Property Name="FORCEAPPSHUTDOWN" Value="FALSE" />
  <Updates Enabled="TRUE" />
  <RemoveMSI />
  <Display Level="None" AcceptEULA="TRUE" />
  <Logging Level="Standard" Path="%windir%\Temp\M365Apps" />
</Configuration>

Für die Deinstallation legen Sie eine zweite Datei uninstall.xml mit <Remove All="TRUE" /> und demselben <Display>-Element ins Paket.

Packen Sie den Ordner mit setup.exe, install.xml und uninstall.xml wie in Sektion 32 beschrieben mit dem IntuneWinAppUtil.exe. Da die eigentlichen Office-Dateien aus dem CDN kommen, bleibt das Paket nur wenige Megabyte groß. In Intune hinterlegen Sie dann:

• Installationsbefehl: setup.exe /configure install.xml
• Deinstallationsbefehl: setup.exe /configure uninstall.xml
• Installationsverhalten: System

Die Detection Rule für Office

Eine Datei-basierte Erkennung auf WINWORD.EXE funktioniert zwar, sagt aber nichts über Architektur oder Produkt aus. Zuverlässiger ist ein Custom Detection Script, das die Click-to-Run-Konfiguration in der Registry auswertet (zu den Grundlagen siehe Sektion 33):

# Detection Script: Microsoft 365 Apps for enterprise (x64)
$c2rPath = "HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration"

$c2r = Get-ItemProperty -Path $c2rPath -ErrorAction SilentlyContinue
if ($null -eq $c2r) {
    exit 1
}

$products = $c2r.ProductReleaseIds -split ","
if (($products -contains "O365ProPlusRetail") -and ($c2r.Platform -eq "x64")) {
    Write-Output "Microsoft 365 Apps $($c2r.VersionToReport) ($($c2r.Platform)) gefunden."
    exit 0
}

exit 1

Bewusst prüfen wir keine exakte Version: Office aktualisiert sich selbst, eine Versionsprüfung würde nach dem ersten Update eine Neuinstallation auslösen. Genau das ist der Unterschied zu den Win32-Updates aus Sektion 42.

Update-Kanäle: Das Herzstück der Office-Strategie

Die Kanäle im Überblick

Microsoft 365 Apps kennt drei primäre Kanäle: Current Channel (Current, neue Features ohne festen Termin), Monthly Enterprise Channel (MonthlyEnterprise, einmal im Monat am Patch Tuesday) und Semi-Annual Enterprise Channel (SemiAnnual). Dazu kommen CurrentPreview, SemiAnnualPreview und BetaChannel für Ihren Test-Ring.

Wichtig: Die Kanal-Zusammenführung seit Juli 2026

Mit Version 2606 (Patch Tuesday am 14. Juli 2026) hat Microsoft den Semi-Annual Enterprise Channel und den Monthly Enterprise Channel zusammengeführt. Geräte, die auf SAEC konfiguriert sind, erhalten seitdem dieselben monatlichen Feature- und Sicherheitsupdates wie MEC und erscheinen nach der Installation von Version 2606 in Office selbst als Monthly Enterprise Channel. Bestehende Richtlinien greifen weiter, eine Migration ist nicht nötig.

Für Sie heißt das: SAEC ist keine „Bremse“ für Feature-Änderungen mehr. Prüfen Sie Berichte und Skripte, die auf „Semi-Annual“ filtern. Für neue Deployments ist MonthlyEnterprise die klare Standardempfehlung.

Kanäle per Settings Catalog steuern

Der Kanal aus der Installations-XML legt nur den Startpunkt fest. Für die dauerhafte Steuerung und spätere Kanalwechsel nutzen Sie den Settings Catalog unter Microsoft Office 2016 (Machine) > Updates. Die wichtigsten Einstellungen:

• Update Channel: Legt den Kanal fest und überschreibt die Installationskonfiguration. So lassen sich Kanalwechsel später ohne Neuinstallation durchführen.
• Update Deadline: Anzahl der Tage, bis ein Update erzwungen wird. Benutzer erhalten vorher Hinweise, danach werden die Apps geschlossen.
• Target Version: Pinnt die Geräte auf eine bestimmte Version – nur für Notfälle und mit klarem Enddatum.

Diese Einstellungen dürfen dem Kanal oder der Version im Deployment selbst nicht widersprechen – laut Microsoft drohen sonst unerwartetes Verhalten bis hin zur Neuinstallation. Und noch ein Stolperstein: Ist Ihr Tenant für Cloud Update im Microsoft 365 Apps Admin Center aktiviert, hat Cloud Update Vorrang vor anderen Management-Tools.

Best Practices für die Office-Bereitstellung

Das Ring-Modell aus Sektion 42 funktioniert auch hier, nur über Kanäle statt Supersedence: IT auf Current Channel (Preview), Pilot auf Current Channel, der Rest auf Monthly Enterprise mit einer Update Deadline von z.B. 7 Tagen. Dazu ein paar feste Regeln:

• Eine Konfiguration pro Gerät: Vermeiden Sie parallele Office-Deployments (App-Typ und Win32). Entscheiden Sie sich für einen Weg.
• MSI-Altlasten zuerst: Prüfen Sie vor dem Rollout, ob noch MSI-Versionen von Office, Visio oder Project im Bestand sind. <RemoveMSI /> entfernt sie, aber nur, wenn Sie das bewusst einplanen.
• Architektur nicht mischen: Einen 64-Bit-Client über eine 32-Bit-Installation zu legen, endet mit Fehler 1603. MigrateArch="TRUE" in der XML löst einen sauberen Architekturwechsel aus.
• Netzwerk mitdenken: Office kommt aus dem CDN. Leiten Sie diesen Traffic nicht durch zentrale Proxys.

Troubleshooting: Wenn Office nicht ankommt

Schritt 1: Wurde die Installation überhaupt gestartet?

Beim eingebauten App-Typ ist der erste Blick in C:\Program Files entscheidend. Tauchen dort die Ordner Microsoft Office und Microsoft Office 15 auf, hat Intune die Bereitstellung erfolgreich angestoßen. Beobachten Sie zusätzlich C:\Program Files\Microsoft Office\Updates\Download: Wächst dieser Ordner nicht oder nur sehr langsam, liegt das Problem bei Netzwerk oder Bandbreite.

Bei der Win32-Variante prüfen Sie wie gewohnt das IntuneManagementExtension.log (siehe Sektion 41) und zusätzlich das ODT-Log im Pfad aus dem <Logging>-Element.

Reicht das nicht, aktivieren Sie mit reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3 das ausführliche Click-to-Run-Logging. Nach einem erneuten Versuch liegen die Logs unter %temp% und %windir%\Temp als {Computername}-{Zeitstempel}.log. Danach den Wert wieder löschen.

Schritt 2: Die häufigsten Fehlercodes

• 1603: Eine Voraussetzungsprüfung ist fehlgeschlagen – meist liegt noch MSI-Office auf dem Gerät oder es soll 64-Bit über eine vorhandene 32-Bit-Installation installiert werden.
• 17002: Szenario nicht abgeschlossen. Typische Ursachen: Installation vom Benutzer oder einer anderen Installation abgebrochen, zu wenig Speicherplatz oder eine unbekannte Sprach-ID.
• 17004: Unbekannte Produkt-ID (SKU) in der Konfiguration.
• 0x8000ffff: Deinstallation angefordert, obwohl kein Click-to-Run-Office installiert ist.

Schritt 3: Kanal und Version per PowerShell prüfen

Gerade nach der Kanal-Zusammenführung ist die Frage „Auf welchem Kanal ist dieses Gerät wirklich?“ häufig. Dieses Skript liest Version, Architektur und Kanal aus der Click-to-Run-Konfiguration:

# Microsoft 365 Apps: Version und Update-Kanal auslesen
$c2rPath = "HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration"

$channelMap = @{
    "492350f6-3a01-4f97-b9c0-c7c6ddf67d60" = "Current Channel"
    "64256afe-f5d9-4f86-8936-8840a6a4f5be" = "Current Channel (Preview)"
    "55336b82-a18d-4dd6-b5f6-9e5095c314a6" = "Monthly Enterprise Channel"
    "7ffbc6bf-bc32-4f92-8982-f9dd17fd3114" = "Semi-Annual Enterprise Channel"
    "5440fd1f-7ecb-4221-8110-145efaa6372f" = "Beta Channel"
}

$c2r = Get-ItemProperty -Path $c2rPath -ErrorAction SilentlyContinue
if ($null -eq $c2r) {
    Write-Output "Kein Click-to-Run-Office gefunden."
    exit 1
}

# UpdateChannel (per Richtlinie gesetzt) hat Vorrang vor CDNBaseUrl
$channelUrl = if ($c2r.UpdateChannel) { $c2r.UpdateChannel } else { $c2r.CDNBaseUrl }
$channelId  = ($channelUrl -split "/")[-1]
$channel    = if ($channelMap.ContainsKey($channelId)) { $channelMap[$channelId] } else { "Unbekannt ($channelId)" }

Write-Output "$env:COMPUTERNAME | $($c2r.VersionToReport) | $($c2r.Platform) | $channel"
exit 0

Mit kleinen Anpassungen eignet sich das Skript auch als Detection Script für eine Remediation, um Kanal-Abweichungen in der ganzen Flotte sichtbar zu machen.

Fazit

Microsoft 365 Apps ist keine App wie jede andere. Wer sie wie ein klassisches Win32-Paket mit fester Version behandelt, kämpft gegen die eingebaute Update-Logik statt sie zu nutzen. Der Schlüssel liegt in einer klaren Entscheidung für einen Bereitstellungsweg und einer bewussten Kanalstrategie.

Zusammenfassend für Ihren Workflow:

• Nutzen Sie den eingebauten App-Typ für einfache Szenarien, die Win32-Variante mit ODT für Autopilot/ESP und volle Kontrolle.
• Räumen Sie MSI-Altlasten vor dem Rollout auf.
• Setzen Sie auf den Monthly Enterprise Channel und steuern Sie Kanäle im Betrieb über den Settings Catalog.
• Berücksichtigen Sie die Kanal-Zusammenführung seit Juli 2026.

Mit diesem Setup wird Office vom unberechenbaren Dauerbrenner zu einer der stabilsten Komponenten in Ihrer Umgebung.

Quellen

• Microsoft Learn: Hinzufügen von Microsoft 365 Apps zu Windows-Geräten mit Microsoft Intune
• Microsoft Learn: Konfigurationsoptionen für das Office-Bereitstellungstool
• Microsoft Learn: Übersicht über die Updatekanäle für Microsoft 365 Apps
• Microsoft Learn: Zusammenführung von Semi-Annual Enterprise Channel und Monthly Enterprise Channel

Weiterlesen: Sektion 40: LOB Apps vs. Win32 Apps · Sektion 42: App-Updates & Versioning-Strategien · Sektion 45: App Assignment mit Filtern