Microsoft Dev Box-Netzwerkanforderungen
Microsoft Dev Box ist ein Dienst, mit dem Benutzer eine Verbindung mit einer cloudbasierten Arbeitsstation herstellen können, die in Azure über das Internet ausgeführt wird, von jedem beliebigen Gerät aus. Um diese Internetverbindungen zu unterstützen, müssen Sie die in diesem Artikel aufgeführten Netzwerkanforderungen erfüllen. Sie sollten mit dem Netzwerkteam und dem Sicherheitsteam Ihrer Organisation zusammenarbeiten, um den Netzwerkzugriff für Dev-Boxes zu planen und zu implementieren.
Microsoft Dev-Box ist eng mit den Windows 365- und Azure Virtual Desktop-Diensten verknüpft und in vielen Fällen sind die Netzwerkanforderungen identisch.
Allgemeine Netzwerkanforderungen
Dev-Boxes erfordern eine Netzwerkverbindung für den Zugriff auf Ressourcen. Sie haben die Wahl zwischen einer von Microsoft gehosteten Netzwerkverbindung und einer Azure-Netzwerkverbindung, die Sie in Ihrem eigenen Abonnement erstellen. Die Wahl einer Methode für den Zugriff auf Ihre Netzwerkressourcen hängt davon ab, wo sich Ihre Ressourcen befinden.
Bei Verwendung einer von Microsoft gehosteten Verbindung:
- Microsoft stellt die Infrastruktur bereit und verwaltet sie vollständig.
- Sie können die Sicherheit von Dev-Boxes über Microsoft Intune verwalten.
Um Ihr eigenes Netzwerk zu verwenden und die in Microsoft Entra eingebundenen Dev-Boxen bereitzustellen, müssen Sie die folgenden Anforderungen erfüllen:
- Virtuelles Azure-Netzwerk: Sie müssen über ein virtuelles Netzwerk in Ihrem Azure-Abonnement verfügen. Die Region, die Sie für das virtuelle Netzwerk auswählen, ist der Ort, an dem Azure die Dev-Boxen bereitstellt.
- Ein Subnetz innerhalb des virtuellen Netzwerks und verfügbarer IP-Adressraum.
- Netzwerkbandbreite: Siehe Netzwerkrichtlinien von Azure.
Um Ihr eigenes Netzwerk zu verwenden und Microsoft Entra Hybrid-Hybrid-Dev-Boxen bereitzustellen, müssen Sie die oben genannten Anforderungen sowie die folgenden Anforderungen erfüllen:
- Das virtuelle Azure-Netzwerk muss in der Lage sein, DNS-Einträge (Domain Name Services) für Ihre Active Directory Domain Services (AD DS)-Umgebung aufzulösen. Um diese Auflösung zu unterstützen, definieren Sie Ihre AD DS-DNS-Server als DNS-Server für das virtuelle Netzwerk.
- Das virtuelle Azure-Netzwerk muss über Netzwerkzugriff auf einen Unternehmensdomänencontroller verfügen, entweder in Azure oder lokal.
Wenn Sie eine Verbindung mit lokalen Ressourcen über die Hybridverknüpfungen von Microsoft Entra herstellen, arbeiten Sie mit Ihrem Azure-Netzwerktopologieexperten zusammen. Bewährte Methode ist die Implementierung einer Hub-and-Spoke-Netzwerktopologie. Der Hub ist der zentrale Punkt, der eine Verbindung mit Ihrem lokalen Netzwerk herstellt. Sie können eine Expressroute, ein Site-to-Site-VPN oder ein Point-to-Site-VPN verwenden. Die Speiche ist das virtuelle Netzwerk, das die Dev-Boxes enthält. Sie verbinden das virtuelle Netzwerk der Dev-Box mit dem angeschlossenen virtuellen Netzwerk vor Ort, um den Zugriff auf Ressourcen vor Ort zu ermöglichen. Hub- und Spoke-Topologie können Sie beim Verwalten von Netzwerkdatenverkehr und Sicherheit unterstützen.
Wichtig
Wenn Sie Ihr eigenes Netzwerk verwenden, unterstützt Microsoft Dev Box derzeit nicht das Verschieben von Netzwerkschnittstellen in ein anderes virtuelles Netzwerk oder ein anderes Subnetz.
Netzwerkkonnektivität zulassen
In Ihrer Netzwerkkonfiguration müssen Sie den Datenverkehr an die folgenden Dienst-URLs und Ports zulassen, um Bereitstellung, Verwaltung und Remote-Konnektivität von Entwicklungsfeldern zu unterstützen.
Erforderliche FQDNs und Endpunkte für Microsoft Dev Box
Um Dev-Boxen einzurichten und Ihren Benutzern die Verbindung zu Ressourcen zu ermöglichen, müssen Sie den Datenverkehr für bestimmte vollqualifizierte Domänennamen (FQDNs) und Endpunkte zulassen. Diese FQDNs und Endpunkte können blockiert werden, wenn Sie eine Firewall wie Azure Firewall oder einen Proxydienst verwenden.
Sie können überprüfen, ob Ihre Dev-Boxen eine Verbindung zu diesen FQDNs und Endpunkten herstellen können, indem Sie die Schritte zur Ausführung des Azure Virtual Desktop Agent URL-Tools in Zugriff auf erforderliche FQDNs und Endpunkte für Azure Virtual Desktop überprüfen ausführen. Das Azure Virtual Desktop Agent URL Tool validiert jeden FQDN und Endpunkt und zeigt an, ob Ihre Dev-Boxen darauf zugreifen können.
Wichtig
Microsoft unterstützt keine Dev-Box-Installationen, bei denen die in diesem Artikel aufgeführten FQDNs und Endpunkte blockiert sind.
Obwohl die meisten Konfigurationen für das cloudbasierte Dev Box-Netzwerk vorgesehen sind, erfolgt die Endbenutzerkonnektivität von einem physischen Gerät aus. Daher müssen Sie auch die Verbindungsrichtlinien für das physische Gerätenetzwerk befolgen.
| Gerät oder Dienst | Erforderliche URLs und Ports für die Netzwerkkonnektivität | Beschreibung |
|---|---|---|
| Physisches Gerät | Link | Remote-Desktopclientkonnektivität und -updates. |
| Microsoft Intune-Dienst | Link | Intune-Clouddienste wie Geräteverwaltung, Anwendungsbereitstellung und Endpunktanalysen. |
| Virtueller Azure Virtual Desktop-Sitzungshostcomputer | Link | Remote-Konnektivität zwischen Dev-Boxes und dem Back-End-Azure Virtual Desktop-Dienst. |
| Windows 365-Dienst | Link | Bereitstellungs- und Integritätsprüfungen. |
Erforderliche Endpunkte
Die folgenden URLs und Ports sind für die Bereitstellung von Entwicklungsfeldern und die Integritätsprüfungen der Azure Network Connection (ANC) erforderlich. Alle Endpunkte verbinden sich über Port 443, sofern nicht anders angegeben.
- *.infra.windows365.microsoft.com
- cpcsaamssa1prodprap01.blob.core.windows.net
- cpcsaamssa1prodprau01.blob.core.windows.net
- cpcsaamssa1prodpreu01.blob.core.windows.net
- cpcsaamssa1prodpreu02.blob.core.windows.net
- cpcsaamssa1prodprna01.blob.core.windows.net
- cpcsaamssa1prodprna02.blob.core.windows.net
- cpcstcnryprodprap01.blob.core.windows.net
- cpcstcnryprodprau01.blob.core.windows.net
- cpcstcnryprodpreu01.blob.core.windows.net
- cpcstcnryprodpreu02.blob.core.windows.net
- cpcstcnryprodprna01.blob.core.windows.net
- cpcstcnryprodprna02.blob.core.windows.net
- cpcstprovprodpreu01.blob.core.windows.net
- cpcstprovprodpreu02.blob.core.windows.net
- cpcstprovprodprna01.blob.core.windows.net
- cpcstprovprodprna02.blob.core.windows.net
- cpcstprovprodprap01.blob.core.windows.net
- cpcstprovprodprau01.blob.core.windows.net
- prna01.prod.cpcgateway.trafficmanager.net
- prna02.prod.cpcgateway.trafficmanager.net
- preu01.prod.cpcgateway.trafficmanager.net
- preu02.prod.cpcgateway.trafficmanager.net
- prap01.prod.cpcgateway.trafficmanager.net
- prau01.prod.cpcgateway.trafficmanager.net
Verwenden von FQDN-Tags und Diensttags für Endpunkte über Azure Firewall
Die Verwaltung von Netzwerksicherheitssteuerelementen für Dev-Boxes kann komplex sein. Um die Konfiguration zu vereinfachen, verwenden Sie vollqualifizierte Domänennamen-Tags (FQDN) und Diensttags, um Netzwerkdatenverkehr zu ermöglichen.
FQDN-Tags
Ein FQDN-Tag ist ein vordefiniertes Tag in der Azure Firewall, das eine Gruppe vollqualifizierter Domänennamen darstellt. Mithilfe von FQDN-Tags können Sie ganz einfach Ausgangsregeln für bestimmte Dienste wie Windows 365 erstellen und verwalten, ohne jeden Domänennamen manuell anzugeben.
Nicht von Microsoft stammende Firewalls unterstützen in der Regel keine FQDN-Tags oder Diensttags. Möglicherweise gibt es einen anderen Begriff für die gleiche Funktionalität. Überprüfen Sie ihre Firewall-Dokumentation.
Diensttags
Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen aus einem bestimmten Azure-Dienst. Microsoft verwaltet die Adresspräfixe, für die das Diensttag gilt, und aktualisiert das Tag automatisch, wenn sich die Adressen ändern. Auf diese Weise wird die Komplexität häufiger Updates an Netzwerksicherheitsregeln minimiert. Diensttags können sowohl in der Netzwerksicherheitsgruppe (Network Security Group, NSG) als auch in Azure Firewall-Regeln verwendet werden, um den ausgehenden Netzwerkzugriff einzuschränken, und in der benutzerdefinierten Route (User Defined Route, UDR) zum Anpassen des Datenverkehrsroutingverhaltens.
Die aufgeführten FQDNs, Endpunkte und Tags beziehen sich nur auf Azure Virtual Desktop-Websites und -Ressourcen. FQDNs und Endpunkte für andere Dienste wie Microsoft Entra ID sind nicht enthalten. Diensttags für andere Dienste finden Sie unter Verfügbare Diensttags.
Azure Virtual Desktop verfügt nicht über eine Liste mit IP-Adressbereichen, die Sie anstelle von FQDNs entsperren können, um Netzwerkdatenverkehr zuzulassen. Wenn Sie eine Firewall der nächsten Generation (Next Generation Firewall, NGFW) verwenden, müssen Sie eine dynamische Liste verwenden, die für Azure-IP-Adressen erstellt wurde, um sicherzustellen, dass Sie eine Verbindung herstellen können.
Weitere Informationen finden Sie unter Verwenden von Azure Firewall zum Verwalten und Schützen von Windows 365-Umgebungen.
Die folgende Tabelle ist die Liste der FQDNs und Endpunkte, auf die Ihre Dev-Boxes zugreifen müssen. Alle Einträge sind ausgehend. Sie müssen keine eingehenden Ports für Dev-Boxes öffnen.
| Adresse | Protokoll | Ausgehender Port | Purpose | Diensttag |
|---|---|---|---|---|
| login.microsoftonline.com | TCP | 443 | Authentifizierung bei Microsoft Online Services | |
| *.wvd.microsoft.com | TCP | 443 | Dienstdatenverkehr | WindowsVirtualDesktop |
| *.prod.warm.ingest.monitor.core.windows.net | TCP | 443 | Agent-Datenverkehr Diagnoseausgabe | AzureMonitor |
| catalogartifact.azureedge.net | TCP | 443 | Azure Marketplace | AzureFrontDoor.Frontend |
| gcs.prod.monitoring.core.windows.net | TCP | 443 | Agent-Datenverkehr | AzureCloud |
| kms.core.windows.net | TCP | 1688 | Aktivierung von Windows | Internet |
| azkms.core.windows.net | TCP | 1688 | Aktivierung von Windows | Internet |
| mrsglobalsteus2prod.blob.core.windows.net | TCP | 443 | Agent- und parallele (Side-by-Side, SXS) Stapelupdates | AzureCloud |
| wvdportalstorageblob.blob.core.windows.net | TCP | 443 | Unterstützung des Azure-Portals | AzureCloud |
| 169.254.169.254 | TCP | 80 | Azure-Instanzmetadatendienst-Endpunkt | N/V |
| 168.63.129.16 | TCP | 80 | Sitzungshost-Systemüberwachung | N/V |
| oneocsp.microsoft.com | TCP | 80 | Zertifikate | N/V |
| www.microsoft.com | TCP | 80 | Zertifikate | N/V |
In der folgenden Tabelle sind optionale FQDNs und Endpunkte aufgeführt, auf die Ihre Sitzungshost-VMs möglicherweise für andere Dienste ebenfalls zugreifen müssen:
| Adresse | Protokoll | Ausgehender Port | Zweck |
|---|---|---|---|
| login.windows.net | TCP | 443 | Anmelden bei Microsoft Online Services und Microsoft 365 |
| *.events.data.microsoft.com | TCP | 443 | Telemetriedienst |
| www.msftconnecttest.com | TCP | 80 | Ermittelt, ob der Sitzungshost mit dem Internet verbunden ist. |
| *.prod.do.dsp.mp.microsoft.com | TCP | 443 | Windows Update |
| *.sfx.ms | TCP | 443 | Updates für die OneDrive-Clientsoftware |
| *.digicert.com | TCP | 80 | Überprüfung der Zertifikatsperre |
| *.azure-dns.com | TCP | 443 | Azure DNS-Auflösung |
| *.azure-dns.net | TCP | 443 | Azure DNS-Auflösung |
Diese Liste enthält keine FQDNs und Endpunkte für andere Dienste wie Microsoft Entra ID, Office 365, benutzerdefinierte DNS-Anbieter oder Zeitdienste. Microsoft Entra FQDNs und Endpunkte finden Sie unter ID 56, 59 und 125 in Office 365 URLs und IP-Adressbereichen.
Tipp
Sie müssen das Platzhalterzeichen (*) für FQDNs für Dienstdatenverkehr verwenden. Falls Sie für Agent-Datenverkehr kein Platzhalterzeichen verwenden, können Sie spezifische FQDNs, die zugelassen werden müssen, wie folgt ermitteln:
- Vergewissern Sie sich, dass die virtuellen Sitzungshost-Computer in einem Hostpool registriert sind.
- Öffnen Sie auf einem Sitzungshost die Ereignisanzeige, navigieren Sie zu Windows-Protokolle>Anwendung>WVD-Agent, und suchen Sie nach der Ereignis-ID 3701.
- Heben Sie die Blockierung von FQDNs auf, die Sie unter der Ereignis-ID 3701 finden. Die FQDNs unter der Ereignis-ID 3701 sind regionsspezifisch. Sie müssen diesen Vorgang mit den entsprechenden FQDNs für jede Azure-Region wiederholen, in der Sie Ihre Sitzungshost-VMs bereitstellen möchten.
Remote-Desktopprotokoll (RDP)-Broker-Dienstendpunkte
Direkte Konnektivität mit Azure Virtual Desktop RDP-Broker-Dienstendpunkten ist für die Remote-Leistung für ein Entwicklungsfeld von entscheidender Bedeutung. Diese Endpunkte wirken sich sowohl auf Konnektivität als auch Latenz aus. Um den Prinzipien der Microsoft 365-Netzwerkkonnektivität zu entsprechen, sollten Sie diese Endpunkte als Optimierungsendpunkte kategorisieren und einen Remote Desktop Protocol (RDP) Shortpath von Ihrem virtuellen Azure-Netzwerk zu diesen Endpunkten verwenden. RDP Shortpath kann einen weiteren Verbindungspfad für verbesserte Dev Box-Konnektivität bereitstellen, insbesondere bei suboptimalen Netzwerkbedingungen.
Um die Konfiguration von Netzwerksicherheitssteuerelementen zu vereinfachen, verwenden Sie Azure Virtual Desktop-Diensttags, um diese Endpunkte für direktes Routing mithilfe einer benutzerdefinierten Azure-Netzwerkroute (USER Defined Route, UDR) zu identifizieren. Ein UDR führt zu einem direkten Routing zwischen Ihrem virtuellen Netzwerk und dem RDP-Broker für die niedrigste Latenz. Weitere Informationen über Azure-Diensttags finden Sie unter Azure-Diensttags im Überblick. Das Ändern der Netzwerkrouten einer Dev-Box (auf der Netzwerkebene oder auf der Dev-Box-Ebene wie VPN) kann die Verbindung zwischen der Dev-Box und dem Azure Virtual Desktop RDP-Broker unterbrechen. Wenn dies der Fall ist, wird der Endbenutzer von seiner Dev-Box getrennt, bis eine Verbindung wiederhergestellt ist.
DNS-Anforderungen
Im Rahmen der Microsoft Entra-Hybridbeitrittsanforderungen müssen Ihre Dev-Boxes in der Lage sein, lokalem Active Directory beizutreten. Dev-Boxes müssen in der Lage sein, DNS-Einträge für Ihre lokale AD-Umgebung aufzulösen.
Konfigurieren Sie Ihr virtuelles Azure-Netzwerk, in dem die Dev-Boxes wie folgt bereitgestellt werden:
- Stellen Sie sicher, dass Ihr virtuelles Azure-Netzwerk über Netzwerkkonnektivität mit DNS-Servern verfügt, die Ihre Active Directory-Domäne auflösen können.
- Wählen Sie in den Einstellungen des virtuellen Azure-Netzwerks die Option DNS-Server> Benutzerdefiniert.
- Geben Sie die IP-Adresse von DNS-Servern ein, die Ihre AD DS-Domäne auflösen können.
Tipp
Durch das Hinzufügen von mindestens zwei DNS-Servern wie bei einem physischen PC können Sie das Risiko eines einzelnen Fehlerpunkts bei der Namensauflösung verringern. Weitere Informationen finden Sie unter Konfigurieren von Azure Virtual Networks-Einstellungen.
Herstellen einer Verbindung mit lokalen Ressourcen
Sie können es Dev-Boxes ermöglichen, eine Verbindung mit lokalen Ressourcen über eine Hybridverbindung herzustellen. Arbeiten Sie mit Ihrem Azure-Netzwerkexperten zusammen, um eine Hub- und Spoke-Netzwerktopologie zu implementieren. Der Hub ist der zentrale Punkt, der eine Verbindung mit Ihrem lokalen Netzwerk herstellt. Sie können eine Expressroute, ein Site-to-Site-VPN oder ein Point-to-Site-VPN verwenden. Die Speiche ist das virtuelle Netzwerk, das die Dev-Boxes enthält. Hub- und Spoke-Topologie können Sie beim Verwalten von Netzwerkdatenverkehr und Sicherheit unterstützen. Sie verbinden das virtuelle Netzwerk der Dev-Box mit dem angeschlossenen virtuellen Netzwerk vor Ort, um den Zugriff auf Ressourcen vor Ort zu ermöglichen.
Technologien zur Überwachung des Verkehrs
Einige Unternehmenskunden verwenden Abhörmaßnahmen, SSL-Entschlüsselung, Deep Packet Inspection und andere ähnliche Technologien für Sicherheitsteams zur Überwachung des Netzwerkverkehrs. Für die Bereitstellung von Dev-Boxes benötigen Sie möglicherweise direkten Zugriff auf den virtuellen Computer. Diese Technologien zur Überwachung des Datenverkehrs können zu Problemen bei der Ausführung von Azure-Netzwerkverbindungsprüfungen oder der Bereitstellung von Dev-Boxes führen. Stellen Sie sicher, dass für Dev-Boxes, die mit Microsoft Dev Box bereitgestellt werden, keine Überwachung des Netzwerks erzwungen wird.
Technologien zur Überwachung des Datenverkehrs können die Latenzprobleme noch verschärfen. Sie können einen Remotedesktopprotokoll (RDP)- Shortpath verwenden, um Latenzprobleme zu minimieren.
Endbenutzergeräte
Alle Geräte, auf denen Sie mit einem der Remotedesktopclients eine Verbindung mit Azure Virtual Desktop herstellen, müssen auf die folgenden FQDNs und Endpunkte zugreifen können. Das Zulassen dieser FQDNs und Endpunkte ist für einen zuverlässigen Clientbetrieb von entscheidender Bedeutung. Das Blockieren des Zugriffs auf diese FQDNs und Endpunkte wird nicht unterstützt und beeinträchtigt die Dienstfunktionalität.
| Adresse | Protokoll | Ausgehender Port | Zweck | Clients |
|---|---|---|---|---|
| login.microsoftonline.com | TCP | 443 | Authentifizierung bei Microsoft Online Services | All |
| *.wvd.microsoft.com | TCP | 443 | Dienstdatenverkehr | All |
| *.servicebus.windows.net | TCP | 443 | Problembehandlung für Daten | All |
| go.microsoft.com | TCP | 443 | Microsoft FWLinks | All |
| aka.ms | TCP | 443 | Microsoft-URL-Verkürzung | All |
| learn.microsoft.com | TCP | 443 | Dokumentation | All |
| privacy.microsoft.com | TCP | 443 | Datenschutzbestimmungen | All |
| query.prod.cms.rt.microsoft.com | TCP | 443 | Laden Sie eine MSI-Datei herunter, um den Client zu aktualisieren. Erforderlich für automatische Updates. | Windows Desktop |
Diese FQDNs und Endpunkte gelten lediglich für die Clientstandorte und -ressourcen. Die Liste enthält keine FQDNs und Endpunkte für andere Dienste wie Microsoft Entra ID oder Office 365. Microsoft Entra-FQDNs und -Endpunkte finden Sie unter den IDs 56, 59 und 125 in URLs und IP-Adressbereiche von Office 365.
Problembehandlung
In diesem Abschnitt werden einige häufige Verbindungs- und Netzwerkprobleme behandelt.
Verbindungsprobleme
Anmeldeversuch fehlgeschlagen
Wenn der Dev-Box-Benutzer Probleme bei der Anmeldung hat und eine Fehlermeldung sieht, die besagt, dass der Anmeldeversuch fehlgeschlagen ist, stellen Sie sicher, dass Sie das PKU2U-Protokoll sowohl auf dem lokalen PC als auch auf dem Sitzungshost aktiviert haben.
Weitere Informationen zur Problembehandlung von Anmeldefehlern finden Sie unter Problembehandlung von Verbindungen mit Microsoft Entra beigetretenen VMs – Windows-Desktopclient.
Gruppenrichtlinienprobleme in Hybridumgebungen
Wenn Sie eine Hybridumgebung verwenden, treten möglicherweise Gruppenrichtlinienprobleme auf. Sie können testen, ob das Problem mit der Gruppenrichtlinie zusammenhängt, indem Sie die Dev-Box vorübergehend von der Gruppenrichtlinie ausschließen.
Weitere Informationen zur Problembehandlung bei Gruppenrichtlinien finden Sie unter Anwenden von Leitfäden zur Problembehandlung für Gruppenrichtlinien.
IPv6-Adressierungsprobleme
Wenn IPv6-Probleme auftreten, überprüfen Sie, ob der Microsoft.AzureActiveDirectory-Dienstendpunkt im virtuellen Netzwerk oder Subnetz nicht aktiviert ist. Dieser Dienstendpunkt konvertiert IPv4 in IPv6.
Weitere Informationen finden Sie unter Dienstendpunkte im virtuellen Netzwerk.
Aktualisieren von Image-Problemen mit der Dev-Box-Definition
Wenn Sie das in einer Dev-Box-Definition verwendete Image aktualisieren, müssen Sie sicherstellen, dass sie über ausreichende IP-Adressen in Ihrem virtuellen Netzwerk verfügen. Für die Integritätsprüfung der Azure-Netzwerkverbindung sind zusätzliche kostenlose IP-Adressen erforderlich. Wenn die Integritätsprüfung fehlschlägt, wird die Dev-Box-Definition nicht aktualisiert. Sie benötigen eine (1) zusätzliche IP-Adresse pro Dev Box und zwei IP-Adressen für die Integritätsprüfung und Dev-Box-Infrastruktur.
Weitere Informationen zum Aktualisieren von Dev-Box-Definitionsimages finden Sie unter Aktualisieren einer Dev-Box-Definition.
Zugehöriger Inhalt
- Überprüfen des Zugriffs auf erforderliche FQDNs und Endpunkte für Azure Virtual Desktop
- Wie Sie die Blockierung dieser FQDNs und Endpunkte in Azure Firewall aufheben können, erfahren Sie unter Verwenden von Azure Firewall zum Schutz von Azure Virtual Desktop.
- Weitere Informationen zur Netzwerkkonnektivität finden Sie unter Grundlegendes zur Azure Virtual Desktop-Netzwerkkonnektivität.