Session för konfiguration av virtuell värddator

  • Artikel

Viktigt!

Det här innehållet gäller för Azure Virtual Desktop med Azure Resource Manager Azure Virtual Desktop-objekt. Om du använder Azure Virtual Desktop (klassisk) utan Azure Resource Manager-objekt kan du läsa den här artikeln.

Använd den här artikeln om du vill felsöka problem som du har när du konfigurerar Azure Virtual Desktop-sessionens värd för virtuella datorer (VM).

Ge feedback

Besök Azure Virtual Desktop Tech Community för att diskutera Azure Virtual Desktop-tjänsten med produktteamet och aktiva communitymedlemmar.

Virtuella datorer är inte anslutna till domänen

Följ dessa instruktioner om du har problem med att ansluta virtuella datorer till domänen.

Fel: Felaktiga autentiseringsuppgifter

Orsak: Ett skrivfel gjordes när autentiseringsuppgifterna angavs i korrigeringarna för Azure Resource Manager-mallgränssnittet.

Åtgärda: Vidta någon av följande åtgärder för att lösa problemet.

Fel: Tidsgräns väntar på användarindata

Orsak: Kontot som används för att slutföra domänanslutningen kan ha multifaktorautentisering (MFA).

Åtgärda: Vidta någon av följande åtgärder för att lösa problemet.

  • Ta tillfälligt bort MFA för kontot.
  • Använd ett tjänstkonto.

Fel: Kontot som användes under etableringen har inte behörighet att slutföra åtgärden

Orsak: Kontot som används har inte behörighet att ansluta virtuella datorer till domänen på grund av efterlevnad och regler.

Åtgärda: Vidta någon av följande åtgärder för att lösa problemet.

  • Använd ett konto som är medlem i gruppen Administratör.
  • Bevilja nödvändiga behörigheter till det konto som används.

Fel: Domännamnet löser inte

Orsak 1: Virtuella datorer finns i ett virtuellt nätverk som inte är associerat med det virtuella nätverk (VNET) där domänen finns.

Korrigering 1: Skapa VNET-peering mellan det virtuella nätverk där virtuella datorer etablerades och det virtuella nätverk där domänkontrollanten (DC) körs. Se Skapa en peering för virtuella nätverk – Resource Manager, olika prenumerationer.

Orsak 2: När du använder Microsoft Entra Domain Services har det virtuella nätverket inte sina DNS-serverinställningar uppdaterade så att de pekar på de hanterade domänkontrollanterna.

Korrigering 2: Information om hur du uppdaterar DNS-inställningarna för det virtuella nätverket som innehåller Microsoft Entra Domain Services finns i Uppdatera DNS-inställningar för det virtuella Azure-nätverket.

Orsak 3: Nätverksgränssnittets DNS-serverinställningar pekar inte på rätt DNS-server i det virtuella nätverket.

Korrigering 3: Utför någon av följande åtgärder för att lösa problemet genom att följa stegen i [Ändra DNS-servrar].

  • Ändra nätverksgränssnittets DNS-serverinställningar till Anpassad med stegen från Ändra DNS-servrar och ange de privata IP-adresserna för DNS-servrarna i det virtuella nätverket.
  • Ändra nätverksgränssnittets DNS-serverinställningar till Ärv från virtuellt nätverk med stegen från Ändra DNS-servrar och ändra sedan det virtuella nätverkets DNS-serverinställningar med stegen från Ändra DNS-servrar.

Azure Virtual Desktop-agenten och Azure Virtual Desktop Boot Loader är inte installerade

Det rekommenderade sättet att etablera virtuella datorer är att använda mallen för att skapa Azure-portalen. Mallen installerar automatiskt Azure Virtual Desktop Agent och Azure Virtual Desktop Agent Boot Loader.

Följ de här anvisningarna för att bekräfta att komponenterna är installerade och för att söka efter felmeddelanden.

  1. Bekräfta att de två komponenterna har installerats genom att checka in Kontrollpanelen> Programprogram>och funktioner. Om Azure Virtual Desktop Agent och Azure Virtual Desktop Agent Boot Loader inte visas är de inte installerade på den virtuella datorn.
  2. Öppna Utforskaren och gå till C:\Windows\Temp\ScriptLog.log. Om filen saknas indikerar det att PowerShell DSC som installerade de två komponenterna inte kunde köras i den angivna säkerhetskontexten.
  3. Om filen C:\Windows\Temp\ScriptLog.log finns öppnar du den och söker efter felmeddelanden.

Fel: Azure Virtual Desktop Agent och Azure Virtual Desktop Agent Boot Loader saknas. C:\Windows\Temp\ScriptLog.log saknas också

Orsak 1: Autentiseringsuppgifterna som angavs under indata för Azure Resource Manager-mallen var felaktiga eller så var behörigheterna otillräckliga.

Korrigering 1: Lägg till de saknade komponenterna manuellt till de virtuella datorerna med skapa en värdpool med PowerShell.

Orsak 2: PowerShell DSC kunde starta och köra men kunde inte slutföras eftersom det inte kan logga in på Azure Virtual Desktop och hämta nödvändig information.

Korrigering 2: Bekräfta objekten i följande lista.

  • Kontrollera att kontot inte har MFA.
  • Bekräfta att värdpoolens namn är korrekt och att värdpoolen finns i Azure Virtual Desktop.
  • Bekräfta att kontot har minst deltagarbehörigheter för Azure-prenumerationen eller resursgruppen.

Fel: Autentiseringen misslyckades, fel i C:\Windows\Temp\ScriptLog.log

Orsak: PowerShell DSC kunde köras men kunde inte ansluta till Azure Virtual Desktop.

Korrigering: Bekräfta objekten i följande lista.

  • Registrera de virtuella datorerna manuellt med Azure Virtual Desktop-tjänsten.
  • Bekräfta att kontot som används för att ansluta till Azure Virtual Desktop har behörighet för Azure-prenumerationen eller resursgruppen för att skapa värdpooler.
  • Bekräfta att kontot inte har MFA.

Azure Virtual Desktop-agenten registreras inte med Azure Virtual Desktop-tjänsten

När Azure Virtual Desktop-agenten först installeras på virtuella sessionsvärddatorer (antingen manuellt eller via Azure Resource Manager-mallen och PowerShell DSC) innehåller den en registreringstoken. I följande avsnitt beskrivs felsökningsproblem som gäller för Azure Virtual Desktop-agenten och token.

Fel: Statusen i cmdleten Get-AzWvdSessionHost visas som Ej tillgänglig

Get-AzWvdSessionHost cmdlet shows status as Unavailable.

Orsak: Agenten kan inte uppdatera sig själv till en ny version.

Åtgärda: Följ de här anvisningarna för att uppdatera agenten manuellt.

  1. Ladda ned en ny version av agenten på den virtuella sessionsvärddatorn.
  2. Starta Aktivitetshanteraren och stoppa RDAgentBootLoader-tjänsten på fliken Tjänst.
  3. Kör installationsprogrammet för den nya versionen av Azure Virtual Desktop-agenten.
  4. När du uppmanas att ange registreringstoken tar du bort posten INVALID_TOKEN och trycker på nästa (en ny token krävs inte).
  5. Slutför installationsguiden.
  6. Öppna Aktivitetshanteraren och starta TJÄNSTEN RDAgentBootLoader.

Fel: Azure Virtual Desktop Agent-registerposten IsRegistered visar värdet 0

Orsak: Registreringstoken har upphört att gälla.

Åtgärda: Följ de här anvisningarna för att åtgärda agentregistrets fel.

  1. Om det redan finns en registreringstoken tar du bort den med Remove-AzWvdRegistrationInfo.
  2. Kör cmdleten New-AzWvdRegistrationInfo för att generera en ny token.
  3. Bekräfta att parametern -ExpriationTime är inställd på tre dagar.

Fel: Azure Virtual Desktop-agenten rapporterar inte pulsslag när get-AzWvdSessionHost körs

Orsak 1: RDAgentBootLoader-tjänsten har stoppats.

Korrigering 1: Starta Aktivitetshanteraren och starta tjänsten om fliken Tjänst rapporterar en stoppad status för RDAgentBootLoader-tjänsten.

Orsak 2: Port 443 kan vara stängd.

Korrigering 2: Följ dessa instruktioner för att öppna port 443.

  1. Bekräfta att port 443 är öppen genom att ladda ned PSPing-verktyget från Sysinternal-verktyg.

  2. Installera PSPing på den virtuella sessionsvärddatorn där agenten körs.

  3. Öppna kommandotolken som administratör och utfärda kommandot nedan:

    psping rdbroker.wvdselfhost.microsoft.com:443

  4. Bekräfta att PSPing tog emot information från RDBroker:

    PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 13.77.160.237:443:
5 iterations (warmup 1) ping test:
Connecting to 13.77.160.237:443 (warmup): from 172.20.17.140:60649: 2.00ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60650: 3.83ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60652: 2.21ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60653: 2.14ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60654: 2.12ms
TCP connect statistics for 13.77.160.237:443:
Sent = 4, Received = 4, Lost = 0 (0% loss),
Minimum = 2.12ms, Maximum = 3.83ms, Average = 2.58ms

Felsöka problem med Azure Virtual Desktop sida vid sida-stack

Det finns tre huvudsakliga sätt som stacken sida vid sida installeras eller aktiveras på virtuella datorer i sessionsvärdpoolen:

  • Med mallen för att skapa Azure-portalen
  • Genom att inkluderas och aktiveras på huvudbilden
  • Installeras eller aktiveras manuellt på varje virtuell dator (eller med tillägg/PowerShell)

Om du har problem med Stacken för Azure Virtual Desktop sida vid sida skriver du qwinsta-kommandot från kommandotolken för att bekräfta att stacken sida vid sida är installerad eller aktiverad.

Utdata från qwinsta visar rdp-sxs i utdata om stacken sida vid sida är installerad och aktiverad.

Side-by-side stack installed or enabled with qwinsta listed as rdp-sxs in the output.

Granska registerposterna nedan och bekräfta att deras värden matchar. Om registernycklar saknas eller om värdena är felmatchade kontrollerar du att du kör ett operativsystem som stöds. Om du är det följer du anvisningarna i Registrera sessionsvärdar till en värdpool för att installera om stacken sida vid sida.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
    Server\WinStations\rds-sxs\"fEnableWinstation":DWORD=1

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
    Server\ClusterSettings\"SessionDirectoryListener":rdp-sxs

Fel: O_REVERSE_CONNECT_STACK_FAILURE

O_REVERSE_CONNECT_STACK_FAILURE error code.

Orsak: Stacken sida vid sida är inte installerad på den virtuella sessionsvärddatorn.

Åtgärda: Följ de här anvisningarna för att installera stacken sida vid sida på den virtuella sessionsvärddatorn.

  1. Använd Remote Desktop Protocol (RDP) för att komma direkt till den virtuella sessionsvärddatorn som lokal administratör.
  2. Installera stacken sida vid sida genom att följa stegen för att registrera sessionsvärdar till en värdpool.

Så här åtgärdar du en Azure Virtual Desktop-stack sida vid sida som inte fungerar

Det finns kända omständigheter som kan orsaka att stacken sida vid sida fungerar dåligt:

  • Följer inte rätt ordning på stegen för att aktivera stacken sida vid sida
  • Automatisk uppdatering av Windows 10 Enhanced Versatile Disc (EVD)
  • Saknar rollen Värd för fjärrskrivbordssession (RDSH)

Anvisningarna i det här avsnittet kan hjälpa dig att avinstallera Azure Virtual Desktop sida vid sida-stacken. När du har avinstallerat stacken sida vid sida följer du stegen för att registrera sessionsvärdar till en värdpool för att installera om stacken sida vid sida.

Den virtuella dator som används för att köra reparation måste finnas i samma undernät och domän som den virtuella datorn med den felaktiga stacken sida vid sida.

Följ de här anvisningarna för att köra reparation från samma undernät och domän:

  1. Anslut med RDP (Standard Remote Desktop Protocol) till den virtuella datorn där korrigering tillämpas.

  2. Ladda ned och installera PsExec.

  3. Starta kommandotolken som lokal administratör och navigera sedan till mappen där PsExec har packats upp.

  4. Använd följande kommando från kommandotolken, där <VMname> är värdnamnet för den virtuella datorn med den felaktiga stacken sida vid sida. Om det är första gången du kör PsExec måste du också godkänna Licensavtalet för PsExec för att fortsätta genom att klicka på Godkänn.

    psexec.exe \\<VMname> cmd

  5. När kommandotolken öppnas på den virtuella datorn med den felaktiga stacken sida vid sida kör du följande kommando och bekräftar att en post med namnet rdp-sxs är tillgänglig. Annars finns inte en stack sida vid sida på den virtuella datorn, så problemet är inte kopplat till stacken sida vid sida.

    qwinsta

    Administrator command prompt

  6. Kör följande kommando, som visar Microsoft-komponenter installerade på den virtuella datorn med den felaktiga stacken sida vid sida.

    wmic product get name

  7. Kör kommandot nedan med produktnamn från steget ovan, till exempel:

    wmic product where name="<Remote Desktop Services Infrastructure Agent>" call uninstall

  8. Avinstallera alla produkter som börjar med Fjärrskrivbord.

  9. När alla Azure Virtual Desktop-komponenter har avinstallerats startar du om den virtuella dator som hade den felaktiga stacken sida vid sida (antingen med Azure-portalen eller från PsExec-verktyget). Du kan sedan installera om stacken sida vid sida genom att följa stegen för att registrera sessionsvärdar till en värdpool.

Licensieringsläget för fjärrskrivbord är inte konfigurerat

Om du loggar in på Windows 10 Enterprise multi-session med ett administrativt konto kan du få ett meddelande om att licensieringsläget för fjärrskrivbord inte är konfigurerat. Fjärrskrivbordstjänster slutar fungera om X dagar. På Anslut ion Broker-servern använder du Serverhanteraren för att ange licensieringsläget för fjärrskrivbord."

Om tidsgränsen går ut visas ett felmeddelande om att fjärrsessionen var frånkopplad eftersom det inte finns några licenser för klientåtkomst till fjärrskrivbord som är tillgängliga för den här datorn.

Om du ser något av dessa meddelanden innebär det att avbildningen inte har de senaste Windows-uppdateringarna installerade eller att du ställer in licensieringsläget för fjärrskrivbord via en grupprincip. Följ stegen i nästa avsnitt för att kontrollera grupprincipinställningen, identifiera versionen av Windows 10 Enterprise multi-session och installera motsvarande uppdatering.

Kommentar

Azure Virtual Desktop kräver bara en LICENS för RDS-klientåtkomst (CAL) när värdpoolen innehåller Windows Server-sessionsvärdar. Information om hur du konfigurerar en RDS CAL finns i Licensiera din RDS-distribution med klientåtkomstlicenser.

Inaktivera grupprincipinställningen licensieringsläge för fjärrskrivbord

Kontrollera grupprincipinställningen genom att öppna grupprincipredigeraren på den virtuella datorn och gå till Administrativa mallar Windows-komponenter>Fjärrskrivbordstjänster>Fjärrskrivbordssession>Värdlicensiering>>Ange licensieringsläge för fjärrskrivbord. Om grupprincipinställningen är Aktiverad ändrar du den till Inaktiverad. Om den redan är inaktiverad lämnar du den som den är.

Kommentar

Om du anger grupprincip via domänen inaktiverar du den här inställningen på principer som är avsedda för dessa virtuella Windows 10 Enterprise-datorer med flera sessioner.

Identifiera vilken version av Windows 10 Enterprise-multisession som du använder

Så här kontrollerar du vilken version av Windows 10 Enterprise multi-session du har:

  1. Logga in med ditt administratörskonto.

  2. Ange "Om" i sökfältet bredvid Start-menyn.

  3. Välj Om datorn.

  4. Kontrollera numret bredvid "Version". Talet ska vara antingen "1809" eller "1903", enligt följande bild.

    A screenshot of the Windows specifications window. The version number is highlighted in blue.

Nu när du känner till versionsnumret går du vidare till relevant avsnitt.

Version 1809

Om versionsnumret är "1809" installerar du KB4516077 uppdatering.

Version 1903

Distribuera om värdoperativsystemet med den senaste versionen av Windows 10 version 1903-avbildningen från Azure-galleriet.

Det gick inte att ansluta till fjärrdatorn på grund av ett säkerhetsfel

Om användarna ser ett fel med texten "Det gick inte att ansluta till fjärrdatorn på grund av ett säkerhetsfel. Om detta fortsätter att hända ber du administratören eller den tekniska supporten om hjälp", verifiera alla befintliga principer som ändrar standardbehörigheter för RDP. En princip som kan orsaka att det här felet visas är "Tillåt inloggning via fjärrskrivbordstjänsters säkerhetsprincip".

Mer information om den här principen finns i Tillåt inloggning via Fjärrskrivbordstjänster.

Jag kan inte distribuera den gyllene avbildningen

Gyllene avbildningar får inte innehålla Azure Virtual Desktop-agenten. Du kan bara installera agenten när du har distribuerat den gyllene avbildningen.

Nästa steg