Erforderliche FQDNs und Endpunkte für Azure Virtual Desktop

Um Azure Virtual Desktop bereitzustellen und Ihren Benutzern die Möglichkeit zu geben, eine Verbindung herzustellen, müssen Sie bestimmte FQDNs und Endpunkte zulassen. Benutzer müssen auch in der Lage sein, eine Verbindung mit bestimmten FQDNs und Endpunkten herzustellen, um auf ihre Azure Virtual Desktop-Ressourcen zugreifen zu können. In diesem Artikel werden die erforderlichen FQDNs und Endpunkte aufgeführt, die Sie für Ihre Sitzungshosts und Benutzer zulassen müssen.

Diese FQDNs und Endpunkte könnten blockiert werden, wenn Sie eine Firewall wie Azure Firewall oder einen Proxydienst verwenden. Anleitungen zur Verwendung eines Proxydiensts mit Azure Virtual Desktop finden Sie unter Proxydienstrichtlinien für Azure Virtual Desktop.

Sie können überprüfen, ob Ihre Sitzungshost-VMs eine Verbindung mit diesen FQDNs und Endpunkten herstellen können, indem Sie die Schritte zum Ausführen des URL-Tools für den Azure Virtual Desktop-Agent in Überprüfen des Zugriffs auf erforderliche FQDNs und Endpunkte für Azure Virtual Desktop. Das URL-Tool für den Azure Virtual Desktop-Agent überprüft jeden FQDN und Endpunkt und zeigt an, ob Ihre Sitzungshosts darauf zugreifen können.

Wichtig

Microsoft unterstützt keine Azure Virtual Desktop-Bereitstellungen, bei denen die in diesem Artikel aufgeführten FQDNs und Endpunkte blockiert sind. Dieser Artikel 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 den IDs 46, 56, 59 und 125 in Office 365-URLs und IP-Adressbereichen, die in eingeschränkten Netzwerkumgebungen möglicherweise erforderlich sind.

Diensttags und FQDN-Tags

Diensttags stellen Gruppen von IP-Adresspräfixen eines bestimmten Azure-Diensts dar. Microsoft verwaltet die Adresspräfixe, die von der Service-Tag-Nummer umfasst werden, und aktualisiert die Service-Tag-Nummer automatisch, wenn sich die Adresse ändert. Dadurch wird die Komplexität der häufigen Aktualisierungen der Netzwerksicherheitsregeln minimiert. Diensttags können in Regeln für Netzwerksicherheitsgruppen (NSGs) und Azure Firewall verwendet werden, um den ausgehenden Netzwerkzugriff einzuschränken. Service-Tags können auch in benutzerdefinierten Routen (UDRs) verwendet werden, um das Routingverhalten des Datenverkehrs anzupassen.

Azure Firewall unterstützt auch FQDN-Tags, die eine Gruppe vollqualifizierter Domänennamen (Fully Qualified Domain Names, FQDNs) darstellen, die bekannten Azure- und anderen Microsoft-Diensten zugeordnet sind. Azure Virtual Desktop verfügt nicht über eine Liste von IP-Adressbereichen, die Sie anstelle von FQDNs entsperren können, um Netzwerkdatenverkehr zuzulassen. Wenn Sie eine Next Generation Firewall (NGFW) verwenden, müssen Sie eine dynamische Liste für Azure-IP-Adressen verwenden, um sicherzustellen, dass Sie eine Verbindung herstellen können. Weitere Informationen finden Sie unter Verwenden von Azure Firewall zum Schutz von Azure Virtual Desktop-Bereitstellungen.

Für Azure Virtual Desktop sind sowohl ein Diensttag als auch ein FQDN-Tageintrag verfügbar. Es wird empfohlen, Diensttags und FQDN-Tags zu verwenden, um Ihre Azure-Netzwerkkonfiguration zu vereinfachen.

Virtuelle Computer mit Sitzungshost

In der folgenden Tabelle sind die FQDNs und Endpunkte aufgeführt, auf die Ihre Sitzungshost-VMs für Azure Virtual Desktop zugreifen müssen. Alle Einträge sind ausgehend; Sie müssen keine Eingangsports für Azure Virtual Desktop öffnen. Wählen Sie die relevante Registerkarte basierend auf der verwendeten Cloud aus.

Adresse Protokoll Ausgehender Port Zweck Diensttag
login.microsoftonline.com TCP 443 Authentifizierung bei Microsoft Online Services AzureActiveDirectory
51.5.0.0/16 UDP 3478 Weitergeleitete RDP-Konnektivität WindowsVirtualDesktop
*.wvd.microsoft.com TCP 443 Dienstdatenverkehr einschließlich TCP-basierter RDP-Konnektivität WindowsVirtualDesktop
catalogartifact.azureedge.net TCP 443 Azure Marketplace AzureFrontDoor.Frontend
*.prod.warm.ingest.monitor.core.windows.net TCP 443 Agent-Datenverkehr
Diagnoseausgabe		 AzureMonitor
gcs.prod.monitoring.core.windows.net TCP 443 Agent-Datenverkehr AzureMonitor
azkms.core.windows.net TCP 1688 Windows-Aktivierung Internet
mrsglobalsteus2prod.blob.core.windows.net TCP 443 Agent- und Parallel-Stack-Updates (SXS) Storage
wvdportalstorageblob.blob.core.windows.net TCP 443 Azure-Portalunterstützung AzureCloud
oneocsp.microsoft.com TCP 80 Zertifikate AzureFrontDoor.FirstParty
www.microsoft.com TCP 80 Zertifikate Nicht zutreffend
*.aikcertaia.microsoft.com TCP 80 Zertifikate Nicht zutreffend
azcsprodeusaikpublish.blob.core.windows.net TCP 80 Zertifikate Nicht zutreffend
*.microsoftaik.azure.net TCP 80 Zertifikate Nicht zutreffend
ctldl.windowsupdate.com TCP 80 Zertifikate Nicht zutreffend
aka.ms TCP 443 Microsoft URL-Shortener, der während der Sitzungshostbereitstellung in Azure Local verwendet wird Nicht zutreffend
*.service.windows.cloud.microsoft TCP 443 Dienstdatenverkehr WindowsVirtualDesktop
*.windows.cloud.microsoft TCP 443 Dienstdatenverkehr Nicht zutreffend
*.windows.static.microsoft TCP 443 Dienstdatenverkehr Nicht zutreffend

Kommunikations-IP-Adressen für Azure Fabric

Sitzungshost-VMs und Cloud-PCs benötigen Zugriff auf zwei IP-Adressen der Azure-Plattform, um VM-Metadaten abzurufen und Integritätsüberwachungssignale zu senden. Diese Adressen funktionieren anders als die in der vorherigen Tabelle aufgeführten FQDNs und erfordern eine spezielle Netzwerkkonfiguration.

Wichtig

Bei diesen IP-Adressen handelt es sich um Azure-interne Plattformendpunkte. Datenverkehr an diese Adressen darf nicht abgefangen, weitergeleitet oder umgeleitet werden. Netzwerkkonfigurationen, die diesen Datenverkehr blockieren oder umleiten, verursachen Bereitstellungsfehler, Systemüberwachungsprobleme und Verbindungsprobleme sowohl für Azure Virtual Desktop als auch für Windows 365.

Adresse Protokoll Ausgehender Port Zweck Diensttag
169.254.169.254 TCP 80 Azure Instance Metadata Service (IMDS) Nicht zutreffend
168.63.129.16 TCP/UDP 80, 32526 (TCP), 53 (TCP/UDP) Konnektivität mit Azure Platform Service Nicht zutreffend

Warum diese Adressen unterschiedlich sind

  • 169.254.169.254 (IMDS): Eine verbindungslokale Adresse, die VM-Metadaten und Identitätsinformationen bereitstellt. Der Datenverkehr ist nur innerhalb des virtuellen Computers zugänglich und verlässt nie den Host.

  • 168.63.129.16 (WireServer): Wird vom Azure-VM-Agent für Integritätssignale und die Kommunikation der Kernplattform verwendet, einschließlich DNS (bei Verwendung des von Azure bereitgestellten DNS) und DHCP. Port 53 (UDP/TCP) für diese IP-Adresse ist nur erforderlich, wenn das von Azure bereitgestellte DNS verwendet wird. Wenn benutzerdefiniertes DNS konfiguriert ist, werden DNS-Abfragen stattdessen dorthin weitergeleitet, und Sie müssen sicherstellen, dass Konnektivität mit Ihren DNS-Servern auch innerhalb des VNet möglich ist.

Diese Adressen sind in allen Azure-Regionen und -Clouds verfügbar. Azure Plattformrouting schützt diesen Datenverkehr auf der Fabric-Ebene, sodass standardmäßige Netzwerksicherheitsgruppenregeln und benutzerdefinierte Routen die Konnektivität standardmäßig nicht beeinträchtigen. Es gibt jedoch bestimmte Konfigurationen sowohl in der Einrichtung Ihres Azure-Netzwerks als auch auf dem Sitzungshost oder auf dem Cloud-PC selbst, die es unbedingt zu vermeiden gilt. Weitere Details finden Sie in diesem Dokument .

Andere Endpunkte

In der folgenden Tabelle sind optionale FQDNs und Endpunkte aufgeführt, auf die Ihre virtuellen Sitzungshostcomputer möglicherweise auch für andere Dienste zugreifen müssen:

Adresse Protokoll Ausgehender Port Zweck Diensttag
login.windows.net TCP 443 Anmelden bei Microsoft Online Services und Microsoft 365 AzureActiveDirectory
*.events.data.microsoft.com TCP 443 Telemetriedienst Nicht zutreffend
www.msftconnecttest.com TCP 80 Erkennt, ob der Sitzungshost mit dem Internet verbunden ist. Nicht zutreffend
*.prod.do.dsp.mp.microsoft.com TCP 443 Windows Update Nicht zutreffend
*.sfx.ms TCP 443 Updates für OneDrive-Clientsoftware Nicht zutreffend
*.digicert.com TCP 80 Zertifikatsperrprüfung Nicht zutreffend
*.azure-dns.com TCP 443 Azure DNS-Auflösung Nicht zutreffend
*.azure-dns.net TCP 443 Azure DNS-Auflösung Nicht zutreffend
*eh.servicebus.windows.net TCP 443 Diagnoseeinstellungen EventHub

Tipp

Sie müssen das Platzhalterzeichen (*) für FQDNs verwenden, die Dienstverkehr beinhalten.

Wenn Sie für den Agent-Datenverkehr keine Platzhalter verwenden möchten, finden Sie hier die folgenden spezifischen FQDNs, die Sie zulassen können:

  1. Stellen Sie sicher, dass Ihre Sitzungshosts in einem Hostpool registriert sind.
  2. Öffnen Sie auf einem Sitzungshost die Ereignisanzeige, wechseln Sie dann zu Windows-Protokolle>,Anwendung>WVD-Agent, und suchen Sie nach der Ereignis-ID 3701.
  3. Heben Sie die Blockierung der FQDNs auf, die Sie unter der Ereignis-ID 3701 finden. Die FQDNs unter Ereignis-ID 3701 sind regionsspezifisch. Sie müssen diesen Vorgang mit den entsprechenden FQDNs für jede Azure-Region wiederholen, in der Sie Ihre Sitzungshosts bereitstellen möchten.

Intune Remotehilfe Endpunkte

Wenn Sie Intune Remotehilfe verwenden, um Remoteunterstützung (Sitzungsspiegelung) für Ihre Azure Virtual Desktop-Umgebung bereitzustellen, müssen Ihre Sitzungshosts zusätzlich zu den in diesem Artikel aufgeführten Azure Virtual Desktop-Endpunkten auch in der Lage sein, die Netzwerkendpunkte zu erreichen, die Remotehilfe benötigt. Die erforderlichen Remotehilfe-Endpunkte sind identisch, unabhängig davon, ob Sie vollständige Desktopsitzungen oder RemoteApp-Sitzungen unterstützen. Diese Endpunkte werden von Intune verwaltet. Die Liste finden Sie unter "Netzwerkendpunkte in der Remotehilfe".

Endbenutzergeräte

Jedes Gerät, auf dem Sie einen der Remotedesktopclients zum Herstellen einer Verbindung mit Azure Virtual Desktop verwenden, muss Zugriff auf die folgenden FQDNs und Endpunkte haben. Das Zulassen dieser FQDNs und Endpunkte ist für eine zuverlässige Kundenerfahrung unerlässlich. Das Blockieren des Zugriffs auf diese FQDNs und Endpunkte wird nicht unterstützt und wirkt sich auf die Dienstfunktionalität aus.

Wählen Sie die relevante Registerkarte basierend auf der verwendeten Cloud aus.

Adresse Protokoll Ausgehender Port Zweck Client(s)
*.service.windows.cloud.microsoft TCP 443 Dienstdatenverkehr Alle
*.windows.cloud.microsoft TCP 443 Dienstdatenverkehr Alle
*.windows.static.microsoft TCP 443 Dienstdatenverkehr Alle
login.microsoftonline.com TCP 443 Authentifizierung bei Microsoft Online Services Alle
51.5.0.0/16 UDP 3478 Weitergeleitete RDP-Konnektivität Alle
*.wvd.microsoft.com TCP 443 Dienstdatenverkehr Alle
*.servicebus.windows.net TCP 443 Problembehandlung bei Daten Alle
go.microsoft.com TCP 443 Microsoft FWLinks Alle
aka.ms TCP 443 Microsoft URL-Shortener Alle
learn.microsoft.com TCP 443 Dokumentation Alle
privacy.microsoft.com TCP 443 Datenschutzerklärung Alle
*.cdn.office.net TCP 443 Automatische Updates Windows Desktop
graph.microsoft.com TCP 443 Dienstdatenverkehr Alle
windows.cloud.microsoft TCP 443 Connection center Alle
windows365.microsoft.com TCP 443 Dienstdatenverkehr Alle
ecs.office.com TCP 443 Connection center Alle
*.events.data.microsoft.com TCP 443 Clienttelemetrie Alle
*.microsoftaik.azure.net TCP 80 Zertifikate Alle
www.microsoft.com TCP 80 Zertifikate Alle
*.aikcertaia.microsoft.com TCP 80 Zertifikate Alle
azcsprodeusaikpublish.blob.core.windows.net TCP 80 Zertifikate Alle

Wenn Sie sich in einem geschlossenen Netzwerk mit eingeschränktem Internetzugang befinden, müssen Sie möglicherweise auch die hier aufgeführten FQDNs für Zertifikatsprüfungen zulassen: Details zur Azure-Zertifizierungsstelle | Microsoft Learn.

Nächste Schritte

  • Zuletzt aktualisiert um