Windows Update, Autopilot und Intune-Enrollment durch die Firewall: welche Endpunkte auf müssen

Autopilot-Firewall-Endpunkte und Intune-Enrollment-Freigaben — wer danach sucht, hat meist gerade ein Notebook vor sich, das im Einrichtungskreisel hängt, und die Kurzantwort vorab: Autopilot bricht selten laut, meist leise — weil einer von rund einem Dutzend Endpunkten fehlt oder durch die TLS-Inspection gequält wird, und Windows quittiert das nicht mit einer klaren Fehlermeldung, sondern mit »kein Internet«, endlosen Kreiseln oder einem Gerät, das trotzig als Privat-PC startet. Die Lösung ist unspektakulär: eine vollständige, gepflegte Freigabenliste für Enrollment, Windows Update und Delivery Optimization, umgesetzt als FQDN-Gruppen auf der XGS, ergänzt um die Inspection-Ausnahmen für Gerätedienste und zwei gern vergessene Winzlinge — Zeitsynchronisation und Konnektivitätsprüfung. Dieser Artikel liefert genau das: die beteiligten Dienste, den Autopilot-Ablauf mit seinen Kontaktpunkten, die Update- und DO-Steuerung, die XGS-Umsetzung, die Ausnahmenliste — und die Diagnose-Systematik für den Rollout, der trotzdem hängt.

Die beteiligten Dienste und ihre Endpunkte

Modern Management ist ein Ensemble aus mehr Diensten, als die Intune-Konsole vermuten lässt — und jeder hat eigene Endpunkte. Die Hauptdarsteller: die Entra-Anmeldedienste (login.microsoftonline.com und Verwandte) für jede Authentifizierung; die Geräteregistrierung (enterpriseregistration.windows.net) für den Entra-Join; der Intune-Dienst (*.manage.microsoft.com mit enrollment.manage.microsoft.com als Enrollment-Tür) für Verwaltung und Richtlinien; der Autopilot-Bereitstellungsdienst (ztd.dds.microsoft.com, cs.dds.microsoft.com) für den Profilabruf; Windows Update (*.windowsupdate.com, *.update.microsoft.com) für die Update-Metadaten; die Inhaltsauslieferung (*.delivery.mp.microsoft.com) samt Delivery-Optimization-Steuerung (*.do.dsp.mp.microsoft.com) für die eigentlichen Pakete — Updates wie Win32-Apps. Und dann die Nebendarsteller, deren Fehlen ganze Rollouts stoppt: die Konnektivitätsprüfung NCSI (www.msftconnecttest.com — ohne sie meldet Windows »kein Internet«, egal was geht), die Zeitsynchronisation (time.windows.com auf UDP 123 — der Faktenkasten im nächsten Kapitel), der Push-Dienst WNS (*.notify.windows.com) für zeitnahe Richtlinien-Syncs. Die Endpunkt-Tabelle fasst alles zusammen — sie ist das Arbeitsdokument dieses Artikels.

Der Autopilot-Ablauf und seine Netzwerkanforderungen

Warum diese Liste vollständig sein muss, zeigt der Ablauf in der Skizze: Autopilot ist eine Kette von sieben Schritten, und jeder hat seinen Netzwerk-Kontaktpunkt. Das frisch ausgepackte Gerät verbindet sich, prüft per NCSI, ob »Internet« da ist, stellt seine Uhr (dazu gleich mehr), holt beim Autopilot-Dienst sein Bereitstellungsprofil, authentifiziert den Benutzer gegen Entra, registriert sich als Gerät, enrollt sich in Intune — und arbeitet dann im Registrierungsstatus-Bildschirm (ESP) Richtlinien und Pflicht-Apps ab, wofür die Inhalte über die Delivery-Endpunkte fließen. Zwei Konsequenzen für die Firewall ergeben sich direkt aus dieser Kette. Erstens: Alles bis zur Benutzeranmeldung läuft ohne angemeldeten Benutzer — Firewall-Regeln für die Geräte-Netze müssen ohne Benutzerauthentifizierung greifen, und ein authentifizierungspflichtiger Proxy ist der natürliche Feind der OOBE (die Proxy-Frage vertieft die FAQ). Zweitens: Ein fehlender Kontaktpunkt erzeugt keinen sauberen Fehler, sondern eines der drei leisen Fehlerbilder — »kein Internet«, ein Gerät ohne Firmenprofil oder der ewige ESP-Kreisel; die Diagnose-Tabelle in Kapitel 6 ordnet sie den Ursachen zu.

Skizze 1: Sieben Schritte, sieben Kontaktpunkte — und die zwei Firewall-Konsequenzen: keine Benutzerauth vor Schritt 4, Inspection-Ausnahmen für die empfindlichen Ziele.

Windows Update und Delivery Optimization steuern

Beim Thema Update-Verkehr lohnt die Unterscheidung zweier Ströme: Die Update-Erkennung (klein, häufig, über die windowsupdate- und update-Endpunkte) und die Inhaltsauslieferung (groß, stoßweise, über delivery.mp.microsoft.com) — und für Letztere hat Microsoft mit Delivery Optimization einen Mechanismus gebaut, der in Firmennetzen viel zu oft ungenutzt bleibt oder, schlimmer, halb blockiert vor sich hin scheitert. Das Prinzip zeigt die Skizze: Ein Client lädt die Inhalte aus der Cloud, die übrigen holen sich die Blöcke von ihm — Peer-to-Peer im LAN über TCP 7680, gesteuert vom DO-Cloud-Dienst. Die sinnvolle Konfiguration im Firmennetz: DO-Modus auf LAN- beziehungsweise Gruppen-Peering stellen (per Intune-Richtlinie), die DO- und Delivery-Endpunkte ausgehend freigeben — und, der gern vergessene Teil, den Peer-Port TCP 7680 zwischen den Client-Segmenten intern erlauben, denn in segmentierten Netzen sitzt die XGS auch zwischen den VLANs. Der Faktenkasten erklärt, warum sich das doppelt auszahlt.

Skizze 2: Einmal übers WAN, danach unter Nachbarn — und die zweiteilige Firewall-Konsequenz: Endpunkte ausgehend, TCP 7680 intern.

Umsetzung als FQDN-Gruppen auf der Sophos XGS

Die Umsetzung folgt demselben Muster, das sich beim M365-Verkehr bewährt hat ([LINK: A7]): FQDN-Hostgruppen statt Einzelregeln. Konkret drei Gruppen, wie die Skizze zeigt: »MS-Enrollment-Auth« (Anmelde-, Registrierungs-, Intune- und Autopilot-Endpunkte), »MS-Update-Delivery« (Update-, Delivery- und DO-Endpunkte) und »MS-Zeit-Konnektivität« (NTP, NCSI, WNS, Gerätemetadaten). Darauf eine Firewall-Regel je Geräte-Zone: Quelle Geräte-VLANs, Ziel die Gruppen, Dienste 443 plus UDP 123 — und ausdrücklich ohne Benutzerauthentifizierung als Regelbedingung, denn die OOBE kennt noch keinen Benutzer; wer benutzerbasierte Regelwerke fährt, stellt diese Freigaben als IP-/Zonen-Regeln vor die Benutzerregeln. Dazu die interne Regel für den DO-Peer-Verkehr (TCP 7680 zwischen den Client-Segmenten) und die SSL/TLS-Ausnahmeregel für die markierten Gruppen — die begründet das nächste Kapitel. Der Pflege-Gewinn der Bauweise: Ändert Microsoft Endpunkte, wird die Gruppe angepasst, die Regeln bleiben stehen — und die Gruppen sind gleich das Inventar, das die FAQ-Frage nach der Aktualität beantwortet.

Skizze 3: Drei Gruppen, eine Regel je Zone, eine interne 7680-Regel — und die Inspection-Markierung gleich im Modell.

TLS-Inspection-Ausnahmen für Gerätedienste

Die zweite Zutat neben den Freigaben: Mehrere dieser Dienste vertragen keine TLS-Inspection — nicht aus Prinzip, sondern aus Technik. Die MDM-Kommunikation authentifiziert sich mit Gerätezertifikaten; schiebt sich die Firewall mit ihrer Inspection-CA dazwischen, bricht diese gegenseitige Authentifizierung, und das Enrollment scheitert oder der Sync verstummt. Die Anmeldedienste reagieren je nach Client-Bibliothek mit Zertifikatsbindungs-Prüfungen empfindlich auf fremde Ketten. Und die Update-Inhalte sind signierte Großpakete — ihre Entschlüsselung kostet Firewall-Durchsatz, prüft aber nichts, was die Signaturprüfung des Clients nicht ohnehin besser prüft; im schlechtesten Fall reißen große Downloads mitten im ESP ab, was exakt das Fehlerbild der Praxis-Geschichte ist. Die Ausnahmenliste deckt sich deshalb weitgehend mit den Gruppen aus Kapitel 4: Enrollment-Auth und Update-Delivery komplett von der Entschlüsselung ausnehmen, die Zeit- und Konnektivitätsziele ebenso — technisch als SSL/TLS-Ausnahmeregel auf die FQDN-Gruppen, exakt nach dem Muster der M365-Optimize-Ausnahmen aus [LINK: A7]. Der Grundsatz dahinter ist derselbe: Inspiziert wird Benutzer-Surfverkehr, nicht die Maschinenkommunikation der Plattform — dort erzeugt der Mittelsmann nur Fehlerbilder ohne Sicherheitsgewinn.

Diagnose hängender Rollouts

Wenn es trotz allem hängt, schlägt Systematik jedes Raten — und die Systematik hat drei Werkzeuge. Erstens das Fehlerbild als Wegweiser: Die Symptom-Tabelle unten übersetzt die typischen Hänger in ihre wahrscheinlichste Ursache; »kein Internet« in der OOBE, das fehlende Firmenprofil und der ESP-Kreisel zeigen auf drei verschiedene Stellen der Kette. Zweitens der Blick von der Firewall-Seite — der unterschätzte Konsultanten-Trick: Während ein Testgerät die OOBE durchläuft, im XGS-Protokoll live auf dessen IP filtern; jedes verworfene Ziel und jeder Inspection-Abbruch fällt sofort ins Auge, und die Freigabenliste korrigiert sich quasi von selbst. Drittens die Client-Seite für die Tiefe: Das eingebaute MDM-Diagnosewerkzeug erzeugt einen Bericht über Enrollment und Richtlinien, die Ereignisanzeige führt unter der Geräteverwaltungs-Diagnostik die sprechenden Fehlercodes, und das Intune-Portal zeigt den Bereitstellungsstatus je Gerät. Der Hinweis-Kasten bündelt die Griffe — und die Reihenfolge lautet immer: erst Fehlerbild einordnen, dann Firewall-Live-Blick, dann Client-Tiefe. In neun von zehn Fällen ist nach Schritt zwei klar, welche Zeile in welcher Gruppe fehlt.

FAQ — häufige Fragen zu Autopilot, Intune und Update-Freigaben

Welche URLs braucht Windows Autopilot?

Die Kernliste für den reinen Autopilot-Durchlauf: die Anmeldedienste (login.microsoftonline.com, login.live.com und Verwandte), die Geräteregistrierung (enterpriseregistration.windows.net), den Autopilot-Bereitstellungsdienst (ztd.dds.microsoft.com und cs.dds.microsoft.com), die Intune-Endpunkte (enrollment.manage.microsoft.com und *.manage.microsoft.com) — plus die drei Voraussetzungs-Winzlinge, ohne die nichts startet: die Konnektivitätsprüfung (www.msftconnecttest.com), die Zeitsynchronisation (time.windows.com über UDP 123) und für die ESP-Phase die Inhaltsendpunkte (*.delivery.mp.microsoft.com samt DO-Steuerung *.do.dsp.mp.microsoft.com), über die Win32-Apps und Updates kommen. Alles jeweils ausgehend auf 443, die Zeit auf UDP 123 — eingehend braucht Autopilot nichts. Zwei Einordnungen dazu: Erstens ist diese Liste die praxisbewährte Essenz, nicht die juristisch vollständige — Microsofts offizielle Endpunktdokumentation für Autopilot und Intune bleibt die verbindliche Quelle und gehört bei der Ersteinrichtung einmal abgeglichen. Zweitens gehört die Liste nicht in Einzelregeln, sondern in die FQDN-Gruppen aus dem Artikel — dann ist die nächste Endpunkt-Änderung ein Gruppen-Edit statt einer Regelwerks-Operation.

Warum hängt das Intune-Enrollment hinter der Firewall?

Weil einer von vier Kandidaten den Weg versperrt — in dieser Reihenfolge prüfen. Kandidat eins: die Uhr. Ein frisch ausgepacktes Gerät mit falscher Zeit scheitert an jeder Token-Ausstellung, und wenn UDP 123 zu time.windows.com blockiert ist, bleibt die Uhr falsch — die Fehlermeldungen zeigen dann irreführend auf Zertifikate und Anmeldung statt auf die Ursache. Kandidat zwei: die Benutzerauthentifizierung im Regelwerk. Die Enrollment-Kommunikation läuft im System- beziehungsweise Gerätekontext; Regeln oder Proxys, die einen angemeldeten Benutzer voraussetzen, blockieren genau diesen Verkehr — die Gerätedienst-Freigaben müssen als Zonen-/IP-Regeln vor den benutzerbasierten greifen. Kandidat drei: die TLS-Inspection. Die MDM-Kommunikation authentifiziert sich mit Gerätezertifikaten, und eine dazwischengeschaltete Inspection-CA bricht diese gegenseitige Prüfung — enrollment.manage.microsoft.com und *.manage.microsoft.com gehören auf die Ausnahmenliste. Kandidat vier: schlicht eine fehlende Freigabe, meist enterpriseregistration.windows.net. Der schnellste Weg zur Antwort ist der Firewall-Live-Blick aus dem Diagnose-Kapitel: Testgerät durchlaufen lassen, auf dessen IP filtern — das verworfene Ziel steht dann wörtlich im Protokoll.

Muss ich Delivery Optimization zulassen?

Streng genommen nein — praktisch: unbedingt, und zwar aus Eigeninteresse. Ohne die DO-Endpunkte fällt die Inhaltsauslieferung auf einfaches HTTP-Herunterladen je Gerät zurück; funktionieren tut das, aber jedes Gerät zieht dann jedes Update und jede Win32-App einzeln über die WAN-Leitung — beim Rollout-Tag mit dreißig Geräten und beim nächsten Feature-Update ist die Leitung damit zuverlässig dicht. Mit freigegebenem DO passiert das Gegenteil: Die Steuerung über *.do.dsp.mp.microsoft.com organisiert das Peering, die Inhalte kommen einmal über *.delivery.mp.microsoft.com, und die Geräte reichen sich die Blöcke über TCP 7680 im LAN weiter — der WAN-Anteil schrumpft drastisch, und die Freigabenliste bleibt klein und stabil, weil DO die gesamte Auslieferung über definierte Endpunkte bündelt. Die Voraussetzungen für den Nutzen: der passende DO-Modus per Intune-Richtlinie (LAN- oder Gruppen-Peering), die interne 7680-Freigabe zwischen den Client-Segmenten — in segmentierten Netzen sitzt die XGS auch dazwischen — und die Inspection-Ausnahme für die Inhaltsendpunkte. Blockieren ließe sich DO also schon; man bezahlt es nur doppelt: mit Bandbreite und mit Pflegeaufwand.

Dürfen Update-Endpunkte durch die TLS-Inspection?

Sie dürfen nicht — und sie müssen auch nicht, das ist die beruhigende Hälfte der Antwort. Das Müssen zuerst: Update-Pakete sind von Microsoft signiert, und der Client prüft diese Signaturen ohnehin vor der Installation — eine Entschlüsselung durch die Firewall prüft nichts zusätzlich, was diese Kette nicht besser prüft; der Sicherheitsgewinn ist null. Das Dürfen: Die Auslieferung großer Pakete verträgt den Mittelsmann schlecht — Multi-Gigabyte-Downloads durch die Inspection kosten massiv Firewall-Durchsatz und reißen im schlechtesten Fall ab, was den ESP-Kreisel und hängende Updates produziert; einzelne Auslieferungswege reagieren zudem empfindlich auf fremde Zertifikatsketten. Deshalb gehören *.windowsupdate.com, *.update.microsoft.com, *.delivery.mp.microsoft.com und die DO-Steuerung komplett auf die SSL/TLS-Ausnahmenliste — technisch als Ausnahmeregel auf die FQDN-Gruppe, nach demselben Muster wie die M365-Optimize-Endpunkte. Der Grundsatz dahinter gilt für die ganze Gerätedienst-Familie: Inspiziert wird das Surfen der Benutzer, nicht die Maschinenkommunikation der Plattform — dort erzeugt die Inspection ausschließlich Fehlerbilder, die dann fälschlich Intune oder Windows angelastet werden.

Wie halte ich die Endpunktlisten aktuell?

Mit drei Gewohnheiten statt mit Heldenmut. Gewohnheit eins: die richtige Bauweise — alle Freigaben leben in den FQDN-Gruppen aus dem Artikel, nie in Einzelregeln; damit ist jede Endpunkt-Änderung ein Eintrag in einer Gruppe, und das Regelwerk bleibt unberührt. Gewohnheit zwei: die richtige Quelle — Microsofts offizielle Endpunktdokumentation für Intune, Autopilot und Windows Update ist die verbindliche Referenz; ein halbjährlicher Abgleich der Gruppen gegen diese Listen ist ein Kalendereintrag von dreißig Minuten, idealerweise zusammen mit dem M365-Endpunkt-Abgleich, den der Cluster ohnehin pflegt. Gewohnheit drei: das Frühwarnsystem — hängende Rollouts und der Firewall-Live-Blick aus dem Diagnose-Kapitel zeigen fehlende oder geänderte Ziele im Moment des Auftretens; wer nach jedem größeren Windows- oder Intune-Funktionsschub einmal ein Testgerät durch die OOBE schickt und dabei aufs Protokoll schaut, findet neue Endpunkte vor der Belegschaft. Und die ehrliche Zusatzempfehlung: Die Wildcard-Einträge der Gruppen (*.manage.microsoft.com, *.delivery.mp.microsoft.com) fangen die meisten Microsoft-internen Umbauten bereits ab — die Pflege betrifft in der Praxis vor allem die punktgenauen Einzelnamen wie die dds-Dienste und die Konnektivitätsprüfung.

Funktioniert Autopilot über den Proxy?

Grundsätzlich ja — aber nur, wenn der Proxy zwei Eigenschaften hat: Er verlangt keine Benutzeranmeldung für die Gerätedienste, und er wird vom Gerät ohne Handarbeit gefunden. Die Anmeldungsfrage ist die härtere: Die OOBE läuft im Systemkontext vor jeder Benutzeranmeldung, und ein authentifizierungspflichtiger Proxy blockiert damit die komplette Kette ab der Konnektivitätsprüfung — der Warn-Kasten im Artikel widmet sich diesem Klassiker. Die Auswege: Ausnahmen von der Authentifizierungspflicht für die Gerätedienst-Gruppen, oder — meist sauberer — die Geräte-Netze gar nicht durch den klassischen Proxy führen, sondern über den DPI-Modus der XGS filtern, der ohne Client-Konfiguration und ohne Authentifizierungszwang auskommt; die Abwägung der Betriebsmodi steht im Proxy-Artikel des Clusters. Die Auffindbarkeitsfrage: Ein expliziter Proxy müsste dem Gerät in der OOBE bekannt gemacht werden — manuell je Gerät ist das der Tod jedes Zero-Touch-Anspruchs; automatische Verteilung (etwa per WPAD/DHCP) funktioniert, ist aber eine eigene Fehlerquelle mit Sicherheitsbeigeschmack. Das ehrliche Fazit: Autopilot und expliziter Auth-Proxy sind Gegner. Wer Zero-Touch will, führt die Gerätedienste transparent an der Proxy-Welt vorbei — genau dafür sind die Gruppen und Regeln dieses Artikels gebaut.

Fazit: Zwölf Zeilen Freigaben — und der Karton wird zum Arbeitsplatz

Modern Management scheitert im Netzwerk selten an großen Dingen — es scheitert an einem geblockten Konnektivitätstest, einem zu-gebliebenen UDP 123, einer inspizierten Enrollment-Verbindung oder einem fehlenden internen 7680. Die Gegenmittel sind unspektakulär und in einem Nachmittag gebaut: drei FQDN-Gruppen mit der Endpunkt-Tabelle dieses Artikels, eine Regel je Geräte-Zone ohne Benutzerauthentifizierung, die Inspection-Ausnahmen für die Maschinenkommunikation, die interne Peer-Freigabe für Delivery Optimization — und ein halbjährlicher Abgleich gegen Microsofts Listen als Kalendereintrag. Wer das stehen hat, erlebt Autopilot so, wie es gedacht ist: Karton auf, Anmelden, Kaffee holen, Arbeitsplatz fertig — und die Firewall ist dabei das, was sie sein soll: unsichtbar, weil sie das Richtige durchlässt und das Falsche nicht.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Das Ausnahmen-Handwerk der TLS-Inspection samt M365-Endpunkten vertieft [LINK: A7]. Ob auf den frisch bereitgestellten Geräten Intercept X oder Defender laufen soll, klärt die Endpoint-Strategie in [LINK: B13]. Und die Betriebsmodi des Web-Filters — inklusive der Frage, warum der DPI-Modus für Geräte-Netze der freundlichere ist — erklärt [LINK: A6].