Behandeln häufiger Probleme mit dem Azure Virtual Desktop-Agent

  • Artikel

Der Azure Virtual Desktop-Agent kann aufgrund verschiedener Faktoren Verbindungsprobleme verursachen:

  • Ein Fehler im Broker, der dazu führt, dass der Agent den Dienst beendet.
  • Probleme bei Updates.
  • Probleme während der Agent-Installation, wodurch die Verbindung mit dem Sitzungshost unterbrochen wird.

In diesem Artikel werden Lösungen für diese gängigen Szenarien vorgestellt, und Sie erfahren, wie Sie Verbindungsprobleme beheben können.

Hinweis

Zum Beheben von Problemen mit der Sitzungskonnektivität und dem Azure Virtual Desktop-Agent empfiehlt es sich, die Ereignisprotokolle auf den Sitzungshost-VMs unter Ereignisanzeige>Windows-Protokolle>Anwendung zu untersuchen. Suchen Sie nach Ereignissen mit einer der folgenden Quellen, um Ihr Problem zu identifizieren:

  • WVD-Agent
  • WVD-Agent-Updater
  • RDAgentBootLoader
  • MsiInstaller

Error: Die Ausführung von RDAgentBootLoader und/oder Remote Desktop Agent Loader wurde beendet

Wenn eines der folgenden Probleme auftritt, konnte der Bootloader, der den Agenten lädt, den Agent nicht ordnungsgemäß installieren, und der Agent-Dienst wird nicht auf Ihrer Sitzungshost-VM ausgeführt:

  • RDAgentBootLoader wurde beendet oder wird nicht ausgeführt.
  • Für Remote Desktop Agent Loader ist kein Status vorhanden.

Zum Beheben dieses Problems starten Sie den RDAgent-Bootloader:

  1. Klicken Sie im Fenster „Dienste“ mit der rechten Maustaste auf Remote Desktop Agent Loader.

  2. Wählen Sie Starten aus. Wenn diese Option abgeblendet dargestellt wird, haben Sie keine Administratorberechtigungen. Sie müssen diese Berechtigungen anfordern, um den Dienst starten zu können.

  3. Warten Sie 10 Sekunden, und klicken Sie mit der rechten Maustaste auf Remote Desktop Agent Loader.

  4. Klicken Sie auf Aktualisieren.

  5. Wenn der Dienst beendet wird, nachdem Sie ihn gestartet und aktualisiert haben, liegt möglicherweise ein Registrierungsfehler vor. Weitere Informationen finden Sie unter INVALID_REGISTRATION_TOKEN or EXPIRED_MACHINE_TOKEN.

Fehler: INVALID_REGISTRATION_TOKEN oder EXPIRED_MACHINE_TOKEN

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn ein Ereignis mit der ID 3277 und INVALID_REGISTRATION_TOKEN oder EXPIRED_MACHINE_TOKEN in der Beschreibung angezeigt wird, wird das verwendete Registrierungstoken nicht als gültig erkannt.

Um dieses Problem zu lösen, erstellen Sie ein gültiges Registrierungstoken:

  1. Führen Sie zum Erstellen eines neuen Registrierungstokens die Schritte im Abschnitt Generieren eines neuen Registrierungsschlüssels für die VM aus.

  2. Öffnen Sie den Registrierungs-Editor.

  3. Navigieren Sie zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent.

  4. Wählen Sie IsRegistered aus.

  5. Geben Sie im Feld Wertdaten: den Wert 0 ein, und klicken Sie dann auf OK.

  6. Wählen Sie RegistrationToken aus.

  7. Fügen Sie im Feld Wertdaten das Registrierungstoken aus Schritt 1 ein.

    Screenshot of IsRegistered 0

  8. Öffnen Sie eine PowerShell-Eingabeaufforderung als Administrator, und führen Sie den folgenden Befehl aus, um den RDAgentBootLoader-Dienst neu zu starten:

    Restart-Service RDAgentBootLoader

  9. Wechseln Sie zurück zum Registrierungs-Editor.

  10. Navigieren Sie zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent.

  11. Stellen Sie sicher, dass IsRegistered auf 1 festgelegt und die Datenspalte für RegistrationToken leer ist.

    Screenshot of IsRegistered 1

Fehler: Agent kann keine Verbindung mit Broker herstellen: INVALID_FORM

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn ein Ereignis mit ID 3277 mit INVALID_FORM in der Beschreibung angezeigt wird, kann der Agent keine Verbindung mit dem Broker herstellen und bestimmten Endpunkt nicht erreichen. Dieses Problem kann durch bestimmte Firewall- oder DNS-Einstellungen verursacht werden.

Um dieses Problem zu beheben, überprüfen Sie, ob Sie die beiden Endpunkte BrokerResourceIdURI und BrokerResourceIdURIGlobal erreichen können:

  1. Öffnen Sie den Registrierungs-Editor.

  2. Navigieren Sie zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent.

  3. Notieren Sie sich die Werte für BrokerResourceIdURI und BrokerResourceIdURIGlobal.

  4. Öffnen Sie einen Webbrowser, geben Sie Ihren Wert für BrokerResourceIdURI in die Adressleiste ein, und fügen Sie am Ende /api/health hinzu, z. B. https://rdbroker-g-us-r0.wvd.microsoft.com/api/health.

  5. Öffnen Sie eine weitere Registerkarte im Browser, geben Sie Ihren Wert für BrokerResourceIdURIGlobal in die Adressleiste ein, und fügen Sie am Ende /api/health hinzu, z. B. https://rdbroker.wvd.microsoft.com/api/health.

  6. Wenn das Netzwerk die Verbindung zum Broker nicht blockiert, werden beide Seiten erfolgreich geladen. In der Meldung RD Broker is Healthy wird mitgeteilt, dass der RD-Broker fehlerfrei ist, wie in den folgenden Screenshots gezeigt:

    Screenshot of successfully loaded broker uri access

    Screenshot of successfully loaded broker global uri access

  7. Wenn das Netzwerk eine Brokerverbindung blockiert, werden die Seiten nicht geladen, wie im folgenden Screenshot gezeigt.

    Screenshot of unsuccessful loaded broker access

    Screenshot of unsuccessful loaded broker global access

    Sie müssen die Blockierung der erforderlichen Endpunkte aufheben und dann die Schritte 4 bis 7 wiederholen. Weitere Informationen finden Sie unter Liste der erforderlichen URLs.

  8. Wenn Ihr Problem durch die vorstehenden Schritte nicht gelöst wird, stellen Sie sicher, dass keine Gruppenrichtlinien mit Verschlüsselungsverfahren vorhanden sind, die die Verbindung zwischen Agent und Broker blockieren. Azure Virtual Desktop verwendet dasselbe TLS 1.2-Verschlüsselungsverfahren wie Azure Front Door. Weitere Informationen finden Sie unter Verbindungssicherheit.

Fehler: 3703

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn Sie ein Ereignis mit der ID 3703 und der Meldung RD-Gateway-URL ist nicht zugänglich in der Beschreibung sehen, kann der Agent die Gateway-URLs nicht erreichen. Um eine Verbindung mit Ihrem Sitzungshost herzustellen, müssen Sie Netzwerkdatenverkehr zu den URLs in der Liste der erforderlichen URLs zulassen. Stellen Sie auch sicher, dass Ihre Firewall- oder Proxyeinstellungen diese URLs nicht blockieren. Damit Azure Virtual Desktop verwendet werden kann, muss die Blockierung dieser URLs aufgehoben werden.

Überprüfen Sie zur Problemlösung, ob Sie auf die erforderlichen URLs zugreifen können, indem Sie das Tool zur Überprüfung einer erforderlichen URL ausführen. Wenn Sie Azure Firewall verwenden, finden Sie unter Verwenden von Azure Firewall zum Schutz von Azure Virtual Desktop-Bereitstellungen und Azure Firewall DNS-Einstellungen weitere Informationen zum Konfigurieren für Azure Virtual Desktop.

Fehler: 3019

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn Sie ein Ereignis mit der ID 3019 feststellen, bedeutet dies, dass der Agent die WebSocket-Transport-URLs nicht erreichen kann. Heben Sie die Blockierung der URLs in der Liste der erforderlichen URLs auf, um erfolgreich eine Verbindung mit Ihrem Sitzungshost herzustellen und zuzulassen, dass Netzwerkdatenverkehr Einschränkungen umgeht. Arbeiten Sie mit dem Netzwerkteam zusammen, um sicherzustellen, dass Firewall-, Proxy- und DNS-Einstellungen diese URLs nicht blockieren. Sie können auch Ihre Netzwerk-Ablaufverfolgungsprotokolle prüfen, um zu ermitteln, wo der Azure Virtual Desktop-Dienst blockiert wird. Wenn Sie einen Microsoft-Support-Fall zu diesem Problem eröffnen, fügen Sie die Netzwerk-Ablaufverfolgungsprotokolle unbedingt an die Anfrage an.

Fehler: InstallationHealthCheckFailedException

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn Sie ein Ereignis mit der ID 3277 und der Meldung InstallationHealthCheckFailedException in der Beschreibung feststellen, funktioniert der Stapellistener nicht, weil der Terminalserver den Registrierungsschlüssel für den Listener gewechselt hat.

So lösen Sie das Problem:

  1. Überprüfen Sie, ob der Stapellistener funktioniert.

  2. Wenn der Listener nicht funktioniert, deinstallieren Sie die Stapelkomponente manuell, und installieren Sie sie neu.

Fehler: ENDPOINT_NOT_FOUND

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn Sie ein Ereignis mit der ID 3277 und der Meldung ENDPOINT_NOT_FOUND in der Beschreibung feststellen, hat der Broker keinen Endpunkt gefunden, mit dem eine Verbindung hergestellt werden kann. Dieses Verbindungsproblem kann aus einem der folgenden Gründe auftreten:

  • In Ihrem Hostpool sind keine Sitzungshost-VMs vorhanden.
  • Die Sitzungshost-VMs in Ihrem Hostpool sind nicht aktiv.
  • Alle Sitzungshost-VMs in Ihrem Hostpool haben die maximale Anzahl von Sitzungen überschritten.
  • Auf keiner der VMs in Ihrem Hostpool wird der Agent-Dienst ausgeführt.

So lösen Sie das Problem:

  1. Stellen Sie sicher, dass die VM eingeschaltet ist und nicht aus dem Hostpool entfernt wurde.

  2. Stellen Sie sicher, dass die VM die maximale Anzahl von Sitzungen nicht überschritten hat.

  3. Stellen Sie sicher, dass der Agent-Dienst ausgeführt wird und der Stapellistener funktioniert.

  4. Stellen Sie sicher, dass der Agent eine Verbindung mit dem Broker herstellen kann.

  5. Stellen Sie sicher, dass Ihre VM über ein gültiges Registrierungstoken verfügt.

  6. Stellen Sie sicher, dass das Registrierungstoken der VM nicht abgelaufen ist.

Error: InstallMsiException

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn Sie ein Ereignis mit der ID 3277 und der Beschreibung InstallMsiException feststellen, wird das Installationsprogramm bereits für eine andere Anwendung ausgeführt, während Sie versuchen, den Agent zu installieren. Es ist auch möglich, dass die Gruppenrichtlinie die Ausführung von msiexec.exe blockiert.

So überprüfen Sie, ob die Gruppenrichtlinie die Ausführung von msiexec.exe blockiert:

  1. Öffnen Sie den Richtlinienergebnissatz, indem Sie rsop.msc aus einer Eingabeaufforderung mit erhöhten Rechten ausführen.

  2. Wechseln Sie im eingeblendeten Fenster Richtlinienergebnissatz zu Computerkonfiguration > Administrative Vorlagen>Windows-Komponenten>Windows Installer>Windows Installer deaktivieren. Falls der Status Aktiviert lautet, arbeiten Sie gemeinsam mit Ihrem Active Directory-Team daran, dass msiexec.exe ausgeführt werden darf.

    Screenshot of Windows Installer policy in Resultant Set of Policy

    Hinweis

    Dies ist keine vollständige Liste aller Richtlinien, es werden nur diejenigen aufgeführt, die uns derzeit bekannt sind.

Error: Win32Exception

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn Sie ein Ereignis mit der ID 3277 und der Beschreibung InstallMsiException feststellen, blockiert eine Richtlinie den Start von cmd.exe. Wenn dieses Programm blockiert ist, können Sie das Konsolenfenster nicht ausführen, das Sie benötigen, um den Dienst nach einem Agent-Update neu zu starten.

  1. Öffnen Sie den Richtlinienergebnissatz, indem Sie rsop.msc aus einer Eingabeaufforderung mit erhöhten Rechten ausführen.

  2. Wechseln Sie im eingeblendeten Fenster Richtliniensatz zu Benutzerkonfiguration > Administrative Vorlagen > System> Zugriff auf Eingabeaufforderung verhindern. Falls der Status Aktiviert lautet, arbeiten Sie gemeinsam mit Ihrem Active Directory-Team daran, dass cmd.exe ausgeführt werden darf.

Fehler: Der Stapellistener funktioniert auf einem Windows 10-2004-Sitzungshost-VM nicht.

Führen Sie auf Ihrer Sitzungshost-VM qwinsta.exe aus, und notieren Sie sich die Versionsnummer, die neben rdp-sxs in der Spalte SESSIONNAME angezeigt wird. Wenn die Spalte STATUS für die Einträge rdp-tcp und rdp-sxs nicht Lauschen lautet, oder wenn die Einträge rdp-tcp und rdp-sxs überhaupt nicht aufgelistet sind, lässt dies auf ein Stapelproblem schließen. Stapelupdates werden zusammen mit Agent-Updates installiert, aber wenn bei diesem Update ein Fehler auftritt, funktioniert der Azure Virtual Desktop-Listener nicht.

So lösen Sie das Problem:

  1. Öffnen Sie den Registrierungs-Editor.

  2. Navigieren Sie zu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations.

  3. Unter WinStations werden möglicherweise mehrere Ordner für verschiedene Stapelversionen angezeigt. Wählen Sie einen Ordner aus, der mit den Versionsinformationen übereinstimmt, die nach der Ausführung von qwinsta.exe an der Eingabeaufforderung angezeigt wurden.

    • Suchen Sie fReverseConnectMode, und stellen Sie sicher, dass der Datenwert 1 lautet. Stellen Sie auch sicher, dass fEnableWinStation auf 1 festgelegt ist.

      Screenshot of fReverseConnectMode

    • Wenn fReverseConnectMode nicht auf 1 festgelegt ist, wählen Sie fReverseConnectMode aus und geben 1 in das Wertfeld ein.

    • Wenn fEnableWinStation nicht auf 1 festgelegt ist, wählen Sie fEnableWinStation aus und geben 1 in das Wertfeld ein.

  4. Wiederholen Sie die vorherigen Schritte für jeden Ordner, der den Versionsinformationen entspricht, die Sie beim Ausführen von qwinsta.exe in einer Eingabeaufforderung gesehen haben.

    Tipp

    Um fReverseConnectMode oder fEnableWinStation für mehrere VMs gleichzeitig zu ändern, können Sie einen der folgenden Schritte ausführen:

    • Exportieren Sie den Registrierungsschlüssel von einem Computer, der bereits funktioniert, und importieren Sie den Schlüssel auf allen Computern, für die diese Änderung erforderlich ist.
    • Erstellen Sie ein Gruppenrichtlinienobjekt (Group Policy Object, GPO), das den Wert des Registrierungsschlüssels für die Computer festlegt, für die diese Änderung erforderlich ist.

  5. Starten Sie die Sitzungshost-VM neu.

  6. Öffnen Sie den Registrierungs-Editor.

  7. Navigieren Sie zu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings.

  8. Suchen Sie unter ClusterSettings nach SessionDirectoryListener, und stellen Sie sicher, dass ihr Datenwert rdp-sxs<version number ist, wobei <version number den Versionsinformationen entspricht, die Sie beim Ausführen von qwinsta.exe in einer Eingabeaufforderung gesehen haben.

  9. Wenn SessionDirectoryListener nicht auf rdp-sxs<version number festgelegt ist, müssen Sie die Schritte im Abschnitt Ihr Problem wird hier nicht aufgeführt oder konnte nicht gelöst werden befolgen.

Error: DownloadMsiException

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn Sie ein Ereignis mit der ID 3277 und der Beschreibung DownloadMsiException feststellen, ist auf dem Datenträger nicht genügend Speicherplatz für den RDAgent vorhanden.

Um dieses Problem zu beheben, geben Sie durch eine der folgenden Aktionen Speicherplatz auf dem Datenträger frei:

  • Löschen von nicht mehr benötigten Dateien
  • Erhöhen der Speicherkapazität der Sitzungshost-VM

Fehler: Agent kann nicht aktualisiert werden: MissingMethodException

Wechseln Sie auf der Sitzungshost-VM zu Ereignisanzeige>Windows-Protokolle>Anwendung. Wenn Sie ein Ereignis mit der ID 3389 und der Meldung MissingMethodException: Methode nicht gefunden in der Beschreibung feststellen, wurde der Azure Virtual Desktop-Agent nicht erfolgreich aktualisiert und auf eine frühere Version zurückgesetzt. Dieses Problem kann auftreten, wenn das derzeit für Ihre VM installierte .NET Framework eine niedrigere Version als 4.7.2 aufweist. Um dieses Problem zu lösen, müssen Sie ein Upgrade von .NET auf Version 4.7.2 oder höher durchführen. Befolgen Sie dazu die Installationsanweisungen in der .NET Framework-Dokumentation.

Fehler: Sitzungshost-VMs verbleiben im Zustand „Upgrade wird durchgeführt“.

Wenn der Status für die Sitzungshosts im Hostpool immer Nicht verfügbar oder Upgrade wird durchgeführt lautet, wurden Agent oder Stapel möglicherweise nicht erfolgreich installiert.

Um dieses Problem zu beheben, installieren Sie zuerst den parallelen Stapel neu:

  1. Melden Sie sich bei der Sitzungshost-VM als Administrator an.

  2. Führen Sie in einer PowerShell-Eingabeaufforderung mit erhöhten Rechten qwinsta.exe aus, und notieren Sie sich die Versionsnummer, die neben rdp-sxs in der Spalte SESSIONNAME angezeigt wird. Wenn die Spalte STATUS für die Einträge rdp-tcp und rdp-sxs nicht Lauschen lautet, oder wenn die Einträge rdp-tcp und rdp-sxs überhaupt nicht aufgelistet sind, lässt dies auf ein Stapelproblem schließen.

  3. Führen Sie den folgenden Befehl aus, um den RDAgentBootLoader-Dienst zu beenden:

    Stop-Service RDAgentBootLoader

  4. Wechseln Sie zu Systemsteuerung>Programme>Programme und Funktionen, oder wechseln Sie unter Windows 11 zur App Einstellungen > Apps.

  5. Deinstallieren Sie die neueste Version des SxS-Netzwerkstapels für Remotedesktopdienste oder die Version, die im Registrierungs-Editor in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations unter dem Wert für ReverseConnectionListener aufgeführt ist.

  6. Führen Sie in der PowerShell-Eingabeaufforderung die folgenden Befehle aus, um den Dateipfad des neuesten Installationsprogramms einer Variablen hinzuzufügen, das auf Ihrer Sitzungshost-VM für den parallelen Stapel verfügbar ist, und geben Sie den Namen an:

    $sxsMsi = (Get-ChildItem "$env:SystemDrive\Program Files\Microsoft RDInfra\" | ? Name -like SxSStack*.msi | Sort-Object CreationTime -Descending | Select-Object -First 1).FullName
$sxsMsi

  7. Installieren Sie das neueste Installationsprogramm, das auf Ihrer Sitzungshost-VM für den parallelen Stapel verfügbar ist, indem Sie den folgenden Befehl ausführen:

    msiexec /i $sxsMsi

  8. Starten Sie die Sitzungshost-VM neu.

  9. Führen Sie in einer Eingabeaufforderung qwinsta.exe erneut aus, und stellen Sie sicher, dass die Spalte STATE für die Einträge rdp-tcp und rdp-sxs ist Lauschen lautet. Andernfalls müssen Sie Ihre VM erneut registrieren und die Agent-Komponente neu installieren.

Fehler: Sitzungshosts verbleiben im Zustand „Nicht verfügbar“.

Wenn Ihre Sitzungshost-VMs im Status „Nicht verfügbar“ verbleiben, hat Ihre VM eine der unter Integritätsprüfung aufgeführten Integritätsprüfungen nicht bestanden. Sie müssen das Problem beheben, das dazu führt, dass die VM die Integritätsprüfung nicht besteht.

Fehler: Sitzungshosts verbleiben im Status „Benötigt Unterstützung“.

Es gibt mehrere Integritätsprüfungen, durch die Ihre Sitzungshost-VMs im Status Unterstützung erforderlich (UrlsAccessibleCheck) hängen bleiben: MetaDataServiceCheck und MonitoringAgentCheck.

UrlsAccessibleCheck

Wenn der Sitzungshost die Integritätsprüfung UrlsAccessibleCheck nicht besteht, müssen Sie ermitteln, welche erforderliche URL durch Ihre Bereitstellung derzeit blockiert wird. Sobald Sie wissen, welche URL blockiert wird, sollten Sie ermitteln, welche Einstellung diese URL blockiert, und sie entfernen.

Es gibt zwei Gründe dafür, dass der Dienst eine erforderliche URL blockiert:

  • Sie verfügen über eine aktive Firewall, die den meisten ausgehenden Datenverkehr und den Zugriff auf die erforderlichen URLs blockiert.
  • Ihre lokale Hosts-Datei blockiert die erforderlichen Websites.

Wenn Sie ein firewallbezogenes Problem beheben möchten, müssen Sie eine Regel hinzufügen, die ausgehende Verbindungen zum TCP-Port 80/443 ermöglicht. Dieser ist mit den blockierten URLs verknüpft.

Wenn Ihre lokale Hosts-Datei die erforderlichen URLs blockiert, sollten Sie sicherstellen, dass keine der erforderlichen URLs auf Ihrem Gerät in der Hosts-Datei enthalten sind. Sie finden den Speicherort der Hosts-Datei im folgenden Registrierungsschlüssel und -wert:

Schlüssel: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Typ: REG_EXPAND_SZ

Name: DataBasePath

MetaDataServiceCheck

Wenn der Sitzungshost die Integritätsprüfung MetaDataServiceCheck nicht besteht, kann der Dienst nicht auf den IMDS-Endpunkt zugreifen. Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

  • Konfigurieren Sie Ihre Netzwerk-, Firewall- oder Proxyeinstellungen neu, um die Blockierung der IP-Adresse 169.254.169.254 aufzuheben.
  • Stellen Sie sicher, dass Ihre HTTP-Clients bei Abfragen von IMDS Webproxys innerhalb des virtuellen Computers umgehen. Es wird empfohlen, die erforderliche IP-Adresse in allen Firewallrichtlinien innerhalb des VM zuzulassen, die mit der ausgehenden Richtung des Netzwerkdatenverkehrs zusammenhängen.

Fügen Sie in der Konfiguration des Webproxys eine Ausnahme für 169.254.169.254 hinzu, wenn Ihr Problem durch einen Webproxy verursacht wird. Öffnen Sie eine Eingabeaufforderung oder PowerShell-Sitzung mit erhöhten Rechten, und führen Sie den folgenden Befehl aus, um diese Ausnahme hinzuzufügen:

netsh winhttp set proxy proxy-server="http=<customerwebproxyhere>" bypass-list="169.254.169.254"

MonitoringAgentCheck

Wenn der Sitzungshost die Integritätsprüfung MonitoringAgentCheck nicht besteht, müssen Sie überprüfen, ob der Remote Desktop Services Infrastructure Geneva Agent auf dem Sitzungshost ordnungsgemäß funktioniert:

  1. Überprüfen Sie, ob der Remote Desktop Services Infrastructure Geneva Agent auf dem Sitzungshost installiert ist. Dies können Sie in der Liste der installierten Programme auf dem Sitzungshost erledigen. Wenn mehrere Versionen dieses Agents installiert sind, deinstallieren Sie ältere Versionen, und behalten Sie nur die neueste Version bei.

  2. Wenn der Remote Desktop Services Infrastructure Geneva Agent nicht auf dem Sitzungshost installiert ist, ermitteln Sie in den Protokollen unter C:\Programme\Microsoft RDInfra\GenevaInstall.txt, ob bei der Installation ein Fehler auftritt.

  3. Überprüfen Sie, ob die geplante Aufgabe GenevaTask_<Version> erstellt wird. Diese geplante Aufgabe muss aktiviert sein und ausgeführt werden. Installieren Sie andernfalls den Agent mithilfe der .msi-Datei Microsoft.RDInfra.Geneva.Installer-x64-<Version>.msi erneut. Diese Datei ist unter C:\Programme\Microsoft RDInfra verfügbar.

Error: Verbindung nicht gefunden: Der RDAgent verfügt nicht über eine aktive Verbindung mit dem Broker

Möglicherweise ist das Verbindungslimit Ihrer Sitzungshost-VMs erreicht und die VM kann keine neuen Verbindungen annehmen.

Führen Sie zum Beheben dieses Problems eine der folgenden Aktionen aus:

  • Verringern Sie das Limit für die maximale Anzahl von Sitzungen. Durch diese Änderung wird sichergestellt, dass die Ressourcen gleichmäßiger auf die Sitzungshosts verteilt werden, und eine Ressourcenknappheit wird verhindert.
  • Erhöhen Sie die Ressourcenkapazität der Sitzungshost-VMs.

Error: Betreiben einer Pro VM oder eines nicht unterstützten Betriebssystems

Der parallele Stapel wird nur von Windows Enterprise- oder Windows Server-SKUs unterstützt, unter Betriebssystemen wie Pro VM nicht. Wenn Sie weder über eine Enterprise- noch über eine Server-SKU verfügen, wird der Stapel auf Ihrer VM installiert, aber nicht aktiviert. Daher wird er nicht angezeigt, wenn Sie qwinsta in der Befehlszeile ausführen.

Um dieses Problem zu beheben, erstellen Sie Sitzungshost-VMs mithilfe eines unterstützten Betriebssystems.

Error: NAME_ALREADY_REGISTERED

Der Name Ihrer Sitzungshost-VM wurde bereits registriert und ist wahrscheinlich ein Duplikat.

So lösen Sie das Problem:

  1. Führen Sie die Schritte im Abschnitt Entfernen des Sitzungshosts aus dem Hostpool aus.

  2. Erstellen Sie eine andere VM. Stellen Sie sicher, dass Sie einen eindeutigen Namen für diese VM auswählen.

  3. Wechseln Sie zum Azure-Portal, und öffnen Sie die Seite Übersicht für den Hostpool, in dem sich Ihre VM befand.

  4. Öffnen Sie die Registerkarte Sitzungshosts, und überprüfen Sie, ob sich alle Sitzungshosts in diesem Hostpool befinden.

  5. Warten Sie 5–10 Minuten, bis der Status des Sitzungshosts Verfügbar lautet.

    Screenshot of available session host

Ihr Problem wird hier nicht aufgeführt oder konnte nicht gelöst werden

Wenn Ihr Problem in diesem Artikel nicht erläutert wurde oder die Anweisungen Ihr Problem nicht lösen konnten, empfiehlt es sich, den Azure Virtual Desktop-Agent zu deinstallieren, erneut zu installieren und erneut zu registrieren. Die Anweisungen in diesem Abschnitt zeigen, wie Sie Ihre Sitzungshost-VM für den Azure Virtual Desktop-Dienst neu registrieren können:

  1. Deinstallieren sämtlicher Komponenten für Agent, Bootloader und Stapel

  2. Entfernen des Sitzungshosts aus dem Hostpool

  3. Generieren eines neuen Registrierungsschlüssels für die VM

  4. Erneutes Installieren des Azure Virtual Desktop-Agents und Starten des Ladevorgangs

Führen Sie diese Anweisungen in diesem Abschnitt aus, wenn mindestens eines der folgenden Szenarien auf Sie zutrifft:

  • Der Status Ihrer Sitzungshost-VM ist als Upgrade oder Nicht verfügbar eingefroren.
  • Der Stapellistener funktioniert nicht, und Sie führen Windows 10 in der Version 1809, 1903 oder 1909 aus.
  • Sie erhalten den Fehler EXPIRED_REGISTRATION_TOKEN.
  • Ihre Sitzungshost-VMs werden in der Liste der Sitzungshosts nicht angezeigt.
  • Sie sehen den Dienst Remote Desktop Agent Loader nicht in der Konsole „Dienste“.
  • Die Komponente RdAgentBootLoader wird in Task Manager nicht als laufender Prozess angezeigt.
  • Sie erhalten den Fehler Verbindungsbroker konnte Einstellungen nicht überprüfen auf VMs mit benutzerdefinierten Images.
  • Die vorherigen Abschnitte in diesem Artikel haben Ihr Problem nicht gelöst.

Schritt 1: Deinstallieren sämtlicher Komponentenprogramme für Agent, Bootloader und Stapel

Bevor Sie den Agent, den Bootloader und den Stapel neu installieren, müssen Sie alle vorhandenen Komponenten auf Ihrer VM deinstallieren. So deinstallieren Sie sämtliche Komponentenprogramme für Agent, Bootloader und Stapel:

  1. Melden Sie sich bei der Sitzungshost-VM als Administrator an.

  2. Wechseln Sie zu Systemsteuerung>Programme>Programme und Funktionen, oder wechseln Sie unter Windows 11 zur App Einstellungen > Apps.

  3. Deinstallieren Sie die folgenden Programme, und starten Sie dann Ihre Sitzungshost-VM neu:

    Achtung

    Beim Deinstallieren des SxS-Netzwerkstapels für Remotedesktopdienste werden Sie aufgefordert, dass Remotedesktopdienste und Dienst „UserMode Port Redirector“ von Remotedesktopdienste geschlossen werden müssen. Wenn Sie über RDP mit der Sitzungshosts-VM verbunden sind, wählen Sie Anwendungen nicht schließen und dann OK aus. Andernfalls funktioniert die RDP-Verbindung nicht.

    Screenshot showing prompt that Remote Desktop Services and Remote Desktop Services UserMode Port Redirector should be closed

    • Remote Desktop Agent Boot Loader
    • Remote Desktop Services Infrastructure Agent
    • Remote Desktop Services Infrastructure Geneva Agent
    • Remote Desktop Services SxS Network Stack

    Hinweis

    Möglicherweise werden mehrere Instanzen dieser Programme angezeigt. Stellen Sie sicher, dass alle Instanzen entfernt werden.

    Screenshot of uninstalling programs

Schritt 2: Entfernen des Sitzungshosts aus dem Hostpool

Wenn Sie den Sitzungshost aus dem Hostpool entfernen, ist dieser Host nicht mehr für diesen Pool registriert. Diese Vorgehensweise fungiert als Zurücksetzung der Sitzungshostregistrierung. So entfernen Sie den Sitzungshost aus dem Hostpool:

  1. Melden Sie sich beim Azure-Portal an.

  2. Geben Sie in der Suchleiste Azure Virtual Desktop ein, und wählen Sie den entsprechenden Diensteintrag aus.

  3. Wählen Sie Hostpools aus, und wählen Sie den Namen des Hostpools aus, in dem sich Ihre Sitzungshost-VM befindet.

  4. Wählen Sie Sitzungshosts aus, um eine Liste aller Sitzungshosts in diesem Hostpool anzuzeigen.

  5. Sehen Sie sich die Liste der Sitzungshosts an, und markieren Sie das Kontrollkästchen neben dem Sitzungshost, den Sie entfernen möchten.

  6. Wählen Sie Entfernen.

    Screenshot of removing VM from host pool

Schritt 3: Generieren eines neuen Registrierungsschlüssels für die VM

Sie müssen einen neuen Registrierungsschlüssel generieren, mit dem Ihre Sitzungs-VM beim Hostpool und beim Dienst erneut registriert wird. So generieren Sie einen neuen Registrierungsschlüssel für die VM:

  1. Melden Sie sich beim Azure-Portal an.

  2. Geben Sie in der Suchleiste Azure Virtual Desktop ein, und wählen Sie den entsprechenden Diensteintrag aus.

  3. Wählen Sie Hostpools aus, und wählen Sie den Namen des Hostpools aus, in dem sich Ihre Sitzungshost-VM befindet.

  4. Wählen Sie auf dem Blatt Übersicht den Registrierungsschlüssel aus.

    Screenshot of registration key in portal

  5. Öffnen Sie die Registerkarte Registrierungsschlüssel, und wählen Sie Neuen Schlüssel generieren aus.

  6. Geben Sie das Ablaufdatum ein, und klicken Sie auf OK.

Hinweis

Das Ablaufdatum darf nicht weniger als eine Stunde und nicht mehr als 27 Tage nach dem Datum und der Uhrzeit der Generierung liegen. Generieren Sie einen Registrierungsschlüssel nur so lange wie nötig.

  1. Kopieren Sie den neu generierten Schlüssel in die Zwischenablage, oder laden Sie die Datei herunter. Sie benötigen diesen Schlüssel später.

Schritt 4: Neuinstallieren von Agent und Bootloader

Durch die erneute Installation der aktuellen Version von Agent und Bootloader werden auch der parallele Stapel und der Geneva-Überwachungs-Agent automatisch installiert. Führen Sie diese Schritte aus, um den Agenten und das Startladeprogramm neu zu installieren. Dies ist die neueste herunterladbare Version von Azure Virtual Desktop-Agent in Nichtvalidierungsumgebungen. Weitere Informationen zum Rollout neuer Versionen des Agents finden Sie unter Neuerungen im Azure Virtual Desktop-Agent.

  1. Melden Sie sich bei Ihrer Sitzungshost-VM als Administrator an und führen Sie den Agent-Installer und Bootloader für Ihre Sitzungshost-VM aus:

    Tipp

    Möglicherweise müssen Sie für die heruntergeladenen Agent- und Startlade-Installationsprogramme die Blockierung aufheben. Klicken Sie mit der rechten Maustaste auf die jeweilige Datei, und wählen Sie Eigenschaften aus. Wählen Sie dann Blockierung aufheben und schließlich OK aus.

  2. Wenn das Installationsprogramm Sie zur Eingabe des Registrierungstokens auffordert, fügen Sie den Registrierungsschlüssel aus der Zwischenablage ein.

    Screenshot of pasted registration token

  3. Führen Sie das Installationsprogramm für den Bootloader aus.

  4. Starten Sie Ihre Sitzungs-VM neu.

  5. Melden Sie sich beim Azure-Portal an.

  6. Geben Sie in der Suchleiste Azure Virtual Desktop ein, und wählen Sie den entsprechenden Diensteintrag aus.

  7. Wählen Sie Hostpools aus, und wählen Sie den Namen des Hostpools aus, in dem sich Ihre Sitzungshost-VM befindet.

  8. Wählen Sie Sitzungshosts aus, um eine Liste aller Sitzungshosts in diesem Hostpool anzuzeigen.

  9. Der im Hostpool registrierte Sitzungshost sollte jetzt mit dem Status Verfügbar angezeigt werden.

    Screenshot of available session host

Entfernen des DisableRegistryTools-Registrierungsschlüssels

Wenn Sie alle vier Schritte ausgeführt haben, aber der Agent immer noch nicht funktioniert, liegt das möglicherweise daran, dass der DisableRegistryTools-Registrierungsschlüssel an einem der folgenden Speicherorte aktiviert ist:

  • HKU:\DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1
  • HKU:\S-1-5-18\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1
  • HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1

Dieser Registrierungsschlüssel verhindert, dass der Agent den parallelen Stapel installiert. Dies führt zu einem Fehler vom Typ „InstallMSIException“. Dieser Fehler führt dazu, dass die Sitzungshosts nicht verfügbar sind.

Um dieses Problem zu beheben, müssen Sie den Schlüssel entfernen:

  1. Entfernen Sie den Schlüssel „DisableRegistryTools“ aus den drei zuvor aufgeführten Speicherorten.

  2. Deinstallieren und entfernen Sie die betroffene parallele Stapelinstallation aus dem Ordner "Apps & Features ".

  3. Entfernen Sie die Registrierungsschlüssel des betroffenen parallelen Stapels.

  4. Starten Sie den virtuellen Computer neu.

  5. Starten Sie den Agent, und lassen Sie ihn den parallelen Stapel automatisch installieren.

Nächste Schritte

Falls Ihr Problem weiterhin besteht, erstellen Sie eine Supportanfrage, und geben Sie detaillierte Informationen zum Problem sowie zu den Aktionen an, die Sie ausgeführt haben, um das Problem zu lösen. Die folgende Liste enthält weitere Ressourcen, die Sie zur Behandlung von Problemen in Ihrer Azure Virtual Desktop-Bereitstellung verwenden können.