Sektion 44: App Delivery Optimization (Delivery Optimization)

Learning 5. November 2026 15 Min. Lesezeit

Einleitung

Eine neue Business-App mit einer Größe von 2 GB an 250 Geräte auszurollen, klingt in Intune zunächst nach einer einfachen Aufgabe: App paketieren, zuweisen und den Installationsstatus beobachten. Netzwerkseitig entstehen dabei ohne Optimierung jedoch bis zu 500 GB Datenverkehr. In einer Niederlassung mit mehreren hundert Geräten kann eine einzelne Bereitstellung dadurch die Internetanbindung über Stunden belasten. Genau hier setzt Delivery Optimization an.

Delivery Optimization, kurz DO, ist der in Windows integrierte Download- und Peercaching-Dienst. Er kann Inhalte nicht nur aus einer Microsoft- beziehungsweise Intune-Quelle herunterladen, sondern bereits heruntergeladene Teile auch von anderen Windows-Geräten beziehen. Für Intune-Administratoren ist das besonders bei Win32-Apps relevant: Der Intune Management Extension-Agent kann Delivery Optimization für den Download des App-Inhalts verwenden. Auch verschiedene Microsoft-Store-Inhalte und andere unterstützte Microsoft-Workloads nutzen diesen Dienst.

Delivery Optimization ist dabei weder ein Ersatz für eine sauber paketierte Anwendung noch ein universeller WAN-Beschleuniger. Es optimiert den Transport unterstützter Inhalte. Installationsfehler, falsche Erkennungsregeln oder blockierte Installer löst es nicht. Diese Masterclass zeigt, wie du DO gezielt für App-Bereitstellungen konfigurierst, realistisch testest und mit den richtigen Diagnosewerkzeugen betreibst.

Grundkonzepte

Wie eine Win32-App über Intune auf das Gerät gelangt

Bei einer Win32-App lädst du eine Datei mit der Endung .intunewin in Intune hoch. Diese Datei enthält den komprimierten Installationsinhalt. Intune speichert die Inhalte in der Cloud und stellt dem Gerät bei einer erforderlichen Installation die notwendigen Informationen bereit. Die Intune Management Extension verarbeitet anschließend den Auftrag:

Prüfung der Anforderungen und der Erkennungsregel
Ermittlung, ob die App installiert werden muss
Download des Inhalts über Delivery Optimization
Entpacken des Inhalts
Ausführung des konfigurierten Installationsbefehls
erneute Erkennung und Rückmeldung des Installationsstatus an Intune

Delivery Optimization wirkt nur im Downloadschritt. Wenn der Installer danach mit Exitcode 1603 fehlschlägt, war die Ursache nicht automatisch DO. Ebenso kann eine fehlerhafte Detection Rule dazu führen, dass Intune eine erfolgreich installierte App erneut bereitstellt. DO reduziert dann möglicherweise den Datenverkehr, verhindert aber keine Installationsschleife.

Quellen: HTTP, Peers im LAN und Peers im Internet

Delivery Optimization kann einen Download in Teile zerlegen und mehrere Quellen verwenden. Für die Auswertung sind vor allem drei Kategorien wichtig:

HTTP: Inhalt aus der ursprünglichen Cloud- beziehungsweise CDN-Quelle.
LAN-Peers: Inhalt von Geräten im lokalen Netzwerk.
Internet-Peers: Inhalt von Geräten außerhalb des lokalen Netzwerks, sofern dieser Modus erlaubt ist.

Ein Gerät muss nicht zuerst die komplette App besitzen, bevor es für andere nützlich wird. Bereits verfügbare Teile können geteilt werden. Dadurch kann eine Verteilung dynamisch wachsen: Einige Geräte laden zunächst aus der Cloud, weitere beziehen Teile sowohl aus der Cloud als auch von diesen Geräten.

Die Inhalte werden nicht einfach auf Vertrauensbasis von einem fremden Rechner übernommen. Delivery Optimization prüft die Integrität der empfangenen Daten anhand der erwarteten Content-Informationen. Der Cloud-Download erfolgt über die jeweils vorgesehenen gesicherten Verbindungen. DO ersetzt trotzdem nicht die Signaturprüfung, die kontrollierte Paketierung oder die Sicherheitsüberprüfung deiner Anwendung.

Download-Modi und ihre praktische Bedeutung

Der wichtigste Konfigurationswert ist der Download-Modus. Für App-Verteilungen sind insbesondere folgende Modi relevant:

HTTP only, no peering – Wert 0: Delivery Optimization wird als Download-Technologie verwendet, aber ohne Peering. Geeignet für stark isolierte oder regulatorisch eingeschränkte Umgebungen.
LAN – Wert 1: Peering ist auf Geräte im lokalen Netzwerk beziehungsweise hinter derselben öffentlichen NAT-Adresse beschränkt. Das ist für viele Unternehmensstandorte der beste Standard.
Group – Wert 2: Peering wird über eine definierte Gruppierung eingeschränkt. Die Gruppe kann beispielsweise durch eine eigene GUID oder eine unterstützte Gruppenquelle gebildet werden.
Internet – Wert 3: Zusätzlich ist Peering mit geeigneten Internet-Peers erlaubt. Das kann in verteilten Heimarbeitsumgebungen helfen, benötigt aber eine bewusste Netzwerk- und Compliance-Entscheidung.

Der LAN-Modus bedeutet nicht automatisch, dass jedes Gerät jedes andere Gerät im selben Unternehmensnetz erreichen kann. Entscheidend sind unter anderem die DO-Erkennung, die Netzwerktopologie, NAT und die tatsächliche Erreichbarkeit zwischen den Geräten. In WLANs mit Client-Isolation, strikt getrennten VLANs oder über bestimmte VPN-Architekturen kann Peering ausfallen, obwohl alle Geräte technisch am selben Standort arbeiten.

Cache: Voraussetzung für wiederverwendbare Inhalte

Ein Peer kann nur Inhalte anbieten, die noch vorhanden sind. Der DO-Cache ist deshalb ein zentraler Erfolgsfaktor. Eine zu kleine Cache-Größe oder eine zu kurze Aufbewahrungsdauer führt dazu, dass Inhalte gelöscht werden, bevor langsamere Geräte sie benötigen.

Berücksichtige bei der Planung:

Größe der aktuell ausgerollten Apps
Anzahl paralleler App-Wellen
verfügbarer freier Speicher auf den Geräten
Zeit zwischen erstem und letztem Zielgerät
weitere DO-Workloads wie unterstützte Updates und Store-Inhalte

Ein Gerät mit sehr kleinem Systemlaufwerk sollte nicht mit einem überdimensionierten festen Cache konfiguriert werden. Umgekehrt kann ein leistungsfähiger Verteilungsknoten mit ausreichend Speicher durchaus einen größeren Cache erhalten. Konfiguriere die Größe möglichst zentral und einheitlich, statt auf einzelnen Geräten lokale Sonderlösungen aufzubauen.

Abgrenzung zu BranchCache und Microsoft Connected Cache

Delivery Optimization ist nicht dasselbe wie BranchCache. Beide verfolgen Caching-Ansätze, sind aber unterschiedliche Technologien. Für moderne Intune- und Microsoft-Content-Szenarien ist DO die primär relevante Komponente.

Microsoft Connected Cache, kurz MCC, ergänzt DO um einen dedizierten Cache-Server. Geräte können unterstützte Inhalte aus diesem lokalen Cache beziehen, anstatt ausschließlich auf andere Clients angewiesen zu sein. Das ist besonders interessant, wenn Geräte zeitversetzt starten oder kein geeigneter Peer online ist. MCC ist jedoch kein transparenter Proxy für beliebige Softwaredownloads. Der jeweilige Workload und der Content-Endpunkt müssen unterstützt und die Clients korrekt für den Cache-Server konfiguriert sein.

App-Download und Windows Update sind getrennte Konfigurationsbereiche

Dieselbe DO-Infrastruktur kann mehrere Workloads bedienen. Trotzdem solltest du App-Bereitstellung und Updateverwaltung konzeptionell trennen. Intune-Update-Ringe steuern Windows-Updates, während Win32-Apps über App-Richtlinien und Zuweisungen verwaltet werden. Eine gemeinsame Delivery-Optimization-Richtlinie kann beide beeinflussen.

Vermeide daher eine Konfiguration, die ausschließlich für eine App-Rolloutwoche optimiert wurde und danach dauerhaft unerwünschte Effekte auf andere Downloads hat. Dokumentiere, welche Einstellungen bewusst global gelten und welche nur für einen bestimmten Gerätekreis vorgesehen sind.

Praxis-Implementierung

1. Ausgangslage und Rolloutziel erfassen

Beginne nicht mit der Richtlinie, sondern mit einer kurzen technischen Bestandsaufnahme. Für jeden Standort solltest du mindestens folgende Punkte kennen:

Anzahl der gleichzeitig verwalteten Geräte
Internetbandbreite und vorhandene Reserven
WLAN-Client-Isolation und VLAN-Trennung
VPN-Modell, insbesondere Full Tunnel oder Split Tunnel
typische Geräte-Laufzeiten und Docking-Verhalten
Größe und Häufigkeit der App-Bereitstellungen
freier Speicher auf den Clients

Ein Beispiel: In einer Niederlassung arbeiten 200 Geräte. Eine App mit 1,5 GB komprimiertem Inhalt soll innerhalb von zwei Tagen verteilt werden. Ohne Wiederverwendung entstehen bis zu 300 GB Cloud-Download. Mit funktionierendem LAN-Peering kann der externe Anteil deutlich sinken. Es wäre allerdings unrealistisch, pauschal mit genau einem einzigen 1,5-GB-Download zu rechnen: Geräte starten zu unterschiedlichen Zeiten, Inhalte laufen aus dem Cache, und nicht jeder Client findet immer einen geeigneten Peer.

2. Einen kontrollierten Pilotkreis bilden

Erstelle eine Gerätegruppe mit etwa 15 bis 30 repräsentativen Clients. Diese sollten sich am selben Standort befinden und möglichst unterschiedliche Startzeiten haben. Nutze für den ersten Test keine geschäftskritische App mit kompliziertem Installer, sondern eine bekannte, zuverlässig paketierte Anwendung.

Die Pilotgruppe dient zwei Zwecken: Sie erhält die DO-Konfiguration und ist gleichzeitig Ziel der Test-App. Dadurch kannst du Downloadverhalten und App-Installation getrennt bewerten. Nach erfolgreichem Test erweiterst du zunächst die Richtlinienzuweisung und danach die App-Zuweisung kontrolliert.

3. Delivery Optimization über den Intune-Einstellungskatalog konfigurieren

Navigiere im Microsoft Intune Admin Center zu den Gerätekonfigurationsprofilen und erstelle ein Profil für Windows 10 und später vom Typ Einstellungskatalog. Suche nach den Einstellungen für Delivery Optimization. Eine solide Ausgangskonfiguration für einen klassischen Unternehmensstandort kann so aussehen:

Download Mode: LAN
Cachegröße: passend zum freien Speicher und zum App-Arbeitssatz
Maximales Cachealter: ausreichend für den geplanten Rolloutzeitraum
Bandbreitenbegrenzung: zunächst nur so restriktiv wie tatsächlich erforderlich
Peering über Internet: deaktiviert, sofern kein Remote-Szenario dies ausdrücklich verlangt

Weise das Profil zunächst der Pilotgruppe zu. Verwende bevorzugt einen konsistenten Satz von Einstellungen in einem Profil. Vermeide es, denselben DO-Wert gleichzeitig über Settings Catalog, benutzerdefinierte OMA-URI-Profile, Gruppenrichtlinien und lokale Skripte zu setzen.

Für eine einzelne benutzerdefinierte Einstellung ist der zugrunde liegende Policy-CSP ebenfalls relevant. Der Download-Modus wird beispielsweise über diesen OMA-URI adressiert:

./Device/Vendor/MSFT/Policy/Config/DeliveryOptimization/DODownloadMode

Der Datentyp ist Integer; für LAN-Peering lautet der Wert 1. In neuen Umgebungen ist der Einstellungskatalog meist wartbarer. OMA-URI ist nützlich, wenn du eine Einstellung benötigst, die in deiner aktuellen Katalogansicht nicht verfügbar ist, oder wenn du eine bestehende standardisierte CSP-Konfiguration weiterverwendest.

4. Group Mode für komplexe Standorte einsetzen

Der LAN-Modus ist einfach und häufig ausreichend. Bei mehreren Netzen hinter derselben Internetverbindung kann er allerdings zu unerwünschten Peer-Beziehungen führen oder ungeeignete Netze zusammenfassen. Der Group Mode ermöglicht eine bewusstere Segmentierung.

Ein praktikabler Ansatz ist eine eigene GUID pro logischer Verteilungsgruppe, beispielsweise pro Standort. Erzeuge diese GUID einmalig und dokumentiere sie:

$siteGroupId = [guid]::NewGuid().Guid
$siteGroupId

Verwende die zurückgegebene GUID unverändert in der zugehörigen Gerätekonfiguration. Erzeuge nicht auf jedem Client bei jeder Anmeldung eine neue GUID; dadurch würden sich die Geräte niemals einer stabilen Gruppe zuordnen.

Der Group Mode ist kein Ersatz für Firewall-Regeln. Geräte innerhalb derselben DO-Gruppe benötigen weiterhin eine funktionierende Peer-Kommunikation. Umgekehrt solltest du Gruppen nicht so klein wählen, dass häufig nur ein einziges Gerät online ist.

5. Bandbreitensteuerung richtig interpretieren

DO unterscheidet unter anderem Hintergrund- und Vordergrunddownloads. Eine App, die als erforderlich im Hintergrund installiert wird, kann sich anders verhalten als ein vom Benutzer aktiv angestoßener Download. Prozentuale Begrenzungen beziehen sich auf die von DO ermittelte verfügbare Bandbreite und sind nicht mit einer garantierten, festen Mbit/s-Obergrenze am Router gleichzusetzen.

Setze eine dauerhafte Begrenzung erst, nachdem du einen echten Engpass beobachtet hast. Eine zu aggressive Drosselung verlängert die Verteilung und vergrößert das Zeitfenster, in dem Peers und Cache-Inhalte benötigt werden. Wenn 200 Geräte eine App über mehrere Tage laden müssen, ist die Wahrscheinlichkeit geringer, dass die ersten Geräte beim späten Start der letzten Geräte noch geeignete Inhalte vorhalten.

6. App-Paket und Bereitstellung für den Test vorbereiten

DO kann nur dann sauber gemessen werden, wenn die App selbst zuverlässig funktioniert. Prüfe das Paket zunächst manuell in einem Testsystem. Der Installationsbefehl sollte unattended ausführbar sein, einen eindeutigen Rückgabecode liefern und keine Benutzerinteraktion verlangen.

Ein einfacher Installationsbefehl kann beispielsweise so aussehen:

msiexec.exe /i "ContosoClient.msi" /qn /norestart

Die Erkennungsregel sollte einen stabilen Zustand prüfen, etwa eine bestimmte MSI-Produktversion oder eine eindeutige Dateiversion. Eine lose Regel wie „Ordner existiert“ reicht häufig nicht aus, weil ein Ordner auch nach einer unvollständigen Installation vorhanden sein kann.

Starte den Test mit einer erforderlichen Zuweisung an die Pilotgruppe. Vermeide während des Tests parallele Änderungen an Paket, Detection Rule und DO-Richtlinie. Sonst kannst du Verbesserungen oder Fehler nicht eindeutig zuordnen.

7. Richtlinie und tatsächlichen Download prüfen

Prüfe zunächst auf einzelnen Pilotgeräten, ob die Richtlinie angekommen ist. Dafür eignen sich die MDM-Diagnose über „Auf Arbeits- oder Schulkonto zugreifen“, der Intune-Gerätekonfigurationsstatus sowie die lokalen DO-Cmdlets.

Get-DOConfig -Verbose
Get-Service -Name DoSvc
Get-DeliveryOptimizationStatus | Format-List *
Get-DeliveryOptimizationPerfSnap

Get-DOConfig zeigt die effektive Konfiguration. Get-DeliveryOptimizationStatus ist besonders während eines aktiven Downloads hilfreich. Achte unter anderem auf Dateigröße, Status und die Herkunft der empfangenen Bytes. Get-DeliveryOptimizationPerfSnap liefert aggregierte Leistungsdaten und ist für einen Vorher-nachher-Vergleich geeignet.

Mit folgendem Skript kannst du aktuelle Downloads etwas übersichtlicher ausgeben:

Get-DeliveryOptimizationStatus |
    Select-Object FileId, Status, FileSize,
        BytesFromHttp, BytesFromLANPeers,
        BytesFromInternetPeers, BytesFromCacheServer |
    Format-Table -AutoSize

Je nach Windows-Version können einzelne Eigenschaften oder Cmdlet-Ausgaben abweichen. Verlasse dich deshalb nicht blind auf ein festes Ausgabeformat, sondern validiere dein Auswertungsskript auf den tatsächlich eingesetzten Builds.

Best Practices

LAN-Peering als Standard, Ausnahmen bewusst definieren

Für Büros mit mehreren Geräten ist LAN-Peering meist die beste Balance aus Bandbreiteneinsparung und Kontrolle. HTTP only ist sinnvoll, wenn Peer-Kommunikation ausdrücklich untersagt oder technisch unmöglich ist. Internet-Peering sollte nicht allein aktiviert werden, weil „mehr Quellen“ grundsätzlich besser klingen. Bewerte die Anforderungen für Netzwerk, Datenschutz, Sicherheit und Standortüberschreitung.

Bei verteilten Remote-Geräten bringt LAN-Peering naturgemäß wenig, wenn pro Haushalt nur ein verwaltetes Gerät existiert. In solchen Umgebungen ist ein effizienter Cloud-Download häufig realistischer als eine komplizierte Peer-Architektur.

Cache anhand des Arbeitssatzes dimensionieren

Plane den Cache nicht nur anhand einer einzelnen App. Wenn innerhalb einer Woche drei Apps mit 1 GB, 2 GB und 4 GB verteilt werden und weitere DO-Workloads hinzukommen, reicht ein sehr kleiner Cache möglicherweise nicht aus. Berücksichtige außerdem Geräte, die erst nach mehreren Tagen online gehen.

Ein größerer Cache garantiert trotzdem keine bestimmte Peer-Quote. Er erhöht lediglich die Wahrscheinlichkeit, dass relevante Inhalte verfügbar bleiben. Speicherdruck, Cachebereinigung und andere Richtlinien können die tatsächliche Aufbewahrung beeinflussen.

Rollouts staffeln und Autostart-Phasen berücksichtigen

Wenn alle Geräte nach einer Zuweisung gleichzeitig aufwachen, entsteht ein natürlicher Lastpeak. Staffele große Bereitstellungen nach Standorten oder Gerätegruppen. Besonders kritisch ist die erste Bereitstellung während Autopilot und Enrollment Status Page: Hier treffen häufig Windows-Updates, Store-Inhalte, Win32-Apps und weitere Konfigurationen zusammen.

Verschiebe sehr große, nicht sofort benötigte Anwendungen nach Möglichkeit aus der initialen ESP-Phase. Das verbessert nicht nur die Netzwerklast, sondern auch die wahrgenommene Bereitstellungsdauer.

Keine widersprüchlichen Verwaltungsebenen

In Hybridumgebungen kann eine alte Gruppenrichtlinie die MDM-Konfiguration überlagern oder zu uneinheitlichem Verhalten führen. Dokumentiere die Zuständigkeit für Delivery Optimization eindeutig. Bei einer Intune-geführten Strategie sollten lokale Änderungen mit Set-DOConfig nur zur zeitlich begrenzten Diagnose verwendet werden, nicht als dauerhafte Fleet-Konfiguration.

Auch mehrere Intune-Profile mit demselben Setting sind vermeidbar. Nutze Filter und Gruppen so, dass Zielgeräte eindeutig die gewünschte Konfiguration erhalten.

Erfolg anhand mehrerer Kennzahlen bewerten

Eine hohe Peer-Quote ist wünschenswert, aber nicht das einzige Ziel. Bewerte zusätzlich:

externe Downloadmenge am Standort
Zeit bis zur erfolgreichen App-Installation
Installationsfehlerquote
Clientlatenz und verfügbare Bandbreite
Anteil der Geräte ohne erfolgreiche Peer-Verbindung
Cacheverhalten über den gesamten Rolloutzeitraum

Ein Rollout kann mit relativ wenig Peering erfolgreich sein, wenn die Internetleitung ausreicht. Umgekehrt ist eine hohe Einsparung wenig wert, wenn Installationen nun tagelang auf stark gedrosselte Downloads warten.

Troubleshooting

Schritt 1: App-Auftrag und DO-Download voneinander trennen

Prüfe zunächst den App-Status in Intune und anschließend die Logs der Intune Management Extension. Relevante Protokolle befinden sich typischerweise unter:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\

Wichtige Dateien sind insbesondere IntuneManagementExtension.log, AgentExecutor.log und für Win32-App-Workloads AppWorkload.log. Suche nach App-ID, Downloadfehlern, Rückgabecodes und Erkennungsergebnissen. Wenn kein Downloadauftrag erscheint, liegt das Problem möglicherweise bei Zuweisung, Filter, Anforderungsregel oder Sync – nicht bei Peering.

Ein manueller Sync kann die Auftragsverarbeitung beschleunigen. Er erzwingt jedoch nicht, dass eine App ohne passende Zuweisung installiert wird.

Schritt 2: Dienst, Richtlinie und Netzwerk prüfen

Kontrolliere den Dienst und die effektive Konfiguration:

Get-Service DoSvc
Get-DOConfig -Verbose

Get-NetConnectionProfile |
    Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity

Der Dienst DoSvc ist triggerbasiert; sein Zustand muss daher nicht dauerhaft „Running“ lauten, solange kein Download aktiv ist. Entscheidend ist, ob er bei Bedarf startet und Downloads verarbeitet.

Für Cloud-Downloads werden die jeweils erforderlichen Microsoft-Endpunkte über HTTPS benötigt. Verwende die aktuellen Microsoft-Netzwerkanforderungen für Intune, Delivery Optimization und die betroffenen Workloads, statt kurzlebige IP-Adresslisten manuell fest einzutragen. TLS-Inspection, Proxys ohne korrekte Ausnahmen oder blockierte CDN-Endpunkte können Downloads beeinträchtigen.

Für klassisches LAN-Peering ist insbesondere die eingehende Peer-Kommunikation über TCP-Port 7680 relevant. Prüfe die Windows-Firewall sowie zusätzliche Sicherheitslösungen. WLAN-Client-Isolation kann nicht durch eine Intune-Richtlinie aufgehoben werden; hier ist die Netzwerkplattform gefragt.

Schritt 3: Fehlendes Peering systematisch analysieren

Wenn alle Bytes über HTTP eingehen, arbeite folgende Fragen der Reihe nach ab:

Ist der Download-Modus tatsächlich LAN oder Group?
Befinden sich mindestens zwei geeignete Geräte gleichzeitig online?
Hat ein anderes Gerät bereits denselben Inhalt heruntergeladen?
Ist der Inhalt dort noch im Cache?
Können die Geräte einander über das lokale Netz erreichen?
Blockiert eine Firewall oder WLAN-Isolation die Verbindung?
Entspricht die Group ID exakt der dokumentierten GUID?
Werden VPN und NAT so verwendet, wie es für den gewählten Modus erforderlich ist?

Ein Test mit nur einem eingeschalteten Gerät kann kein LAN-Peering zeigen. Ebenso ist ein Test mit unterschiedlichen Apps oder nach einer Paketänderung ungeeignet: Der neue Paketinhalt ist nicht mit dem alten Download identisch.

Schritt 4: DO-Leistungsdaten und Ereignisse auswerten

Der operative Ereignisprotokollbereich befindet sich in der Ereignisanzeige unter „Anwendungs- und Dienstprotokolle“, „Microsoft“, „Windows“ und „DeliveryOptimization“. Nutze ihn zusammen mit den PowerShell-Daten, nicht isoliert.

Für eine einfache Auswertung eines aktiven Downloads kannst du die Bytequellen zusammenfassen:

$status = Get-DeliveryOptimizationStatus |
    Where-Object { $_.FileSize -gt 0 }

$status | ForEach-Object {
    $peerBytes = $_.BytesFromLANPeers + $_.BytesFromInternetPeers
    $knownBytes = $peerBytes + $_.BytesFromHttp

    [pscustomobject]@{
        FileId          = $_.FileId
        FileSizeMB      = [math]::Round($_.FileSize / 1MB, 2)
        HttpMB          = [math]::Round($_.BytesFromHttp / 1MB, 2)
        PeerMB          = [math]::Round($peerBytes / 1MB, 2)
        PeerSharePct    = if ($knownBytes -gt 0) {
            [math]::Round(($peerBytes / $knownBytes) * 100, 1)
        } else {
            0
        }
    }
} | Format-Table -AutoSize

Diese Berechnung ist eine Momentaufnahme und keine vollständige Standortmessung. Für belastbare Aussagen benötigst du Werte von mehreren Geräten, idealerweise vor und nach dem gesamten Rollout sowie ergänzende WAN-Messdaten.

Typische Fehlinterpretationen

„Die App ist installiert, also funktioniert DO perfekt.“ Eine erfolgreiche Installation kann ausschließlich über HTTP erfolgt sein. Prüfe die Downloadquellen.

„Es gibt keine Peers, also ist die Richtlinie falsch.“ Möglicherweise war kein zweites Gerät online, der Cache war leer oder die Geräte waren durch das WLAN isoliert.

„Ich lösche den Cache bei jedem Downloadproblem.“ Dadurch entfernst du gerade die Inhalte, die für Peering und weitere Geräte nützlich wären. Eine Cachebereinigung ist eine gezielte Diagnosemaßnahme bei nachweislich beschädigten oder veralteten Daten, kein Standard-Schritt.

„Eine niedrige Bandbreitenbegrenzung schützt immer das Netzwerk.“ Sie kann lediglich den Download stark verlängern. Bei einem sehr großen App-Rollout ist eine Kombination aus Staffelung, funktionierendem Peering, ausreichendem Cache und angemessener Drosselung meist sinnvoller.

Wenn du einen Dienst während der Diagnose neu startest oder den Cache bereinigst, dokumentiere den Zeitpunkt und wiederhole anschließend den Test mit mindestens zwei Geräten. Andernfalls vermischen sich die Auswirkungen deiner Maßnahme mit dem normalen Rolloutverhalten.

Fazit

Delivery Optimization ist einer der wirksamsten Hebel, um große Intune-App-Bereitstellungen netzwerkschonend zu gestalten. Entscheidend ist aber nicht die Aktivierung einer einzelnen Einstellung, sondern das Zusammenspiel aus Download-Modus, Erreichbarkeit der Peers, Cachegröße, Aufbewahrungsdauer, Geräte-Laufzeiten und kontrollierter Rolloutplanung.

Für die meisten Standorte ist LAN-Peering über ein zentral verwaltetes Intune-Profil ein guter Ausgangspunkt. Group Mode eignet sich für bewusst segmentierte Umgebungen, während HTTP only eine klare Ausnahme für eingeschränkte Netze darstellt. Microsoft Connected Cache kann dort einen zusätzlichen Nutzen bringen, wo zuverlässiges clientbasiertes Peering wegen zeitversetzter Nutzung nicht ausreicht.

Betreibe DO messbar: Teste mit einer fehlerfrei paketierten App, prüfe die effektive Konfiguration, werte die tatsächlichen Downloadquellen aus und trenne Downloadprobleme konsequent von Installer- und Erkennungsfehlern. So wird Delivery Optimization von einer scheinbar automatischen Windows-Funktion zu einem planbaren Bestandteil deiner Intune-App-Strategie.