Dela via


Azure Virtual Desktop-sessionskonfiguration (klassisk) värd för virtuell dator

Viktig

Det här innehållet gäller för Azure Virtual Desktop (klassiskt), som inte stöder Azure Resource Manager Azure Virtual Desktop-objekt. Om du försöker att hantera objekt i Azure Resource Manager för Azure Virtual Desktop 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: Det gjordes ett skrivfel när autentiseringsuppgifterna angavs i azure Resource Manager-mallgränssnittskorrigeringarna.

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

Fel: Timeout vid väntan på användarindata

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

Fix: 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.

Fix: 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 kan inte lösas

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.

Fix 1: Create VNET peering between the VNET where VMs were provisioned and the VNET where the domain controller (DC) is running. 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.

Fix 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.

Fix 3: Vidta 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 Anpassade 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 det virtuella nätverket med stegen från Ändra DNS-servraroch ä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 skapa virtuella datorer är att använda Azure Resource Manager Skapa och etablera Azure Virtual Desktop-värdpool-mall. 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. Kontrollera att de två komponenterna har installerats genom att checka in Kontrollpanelen>Program>Program och funktioner. Om Azure Virtual Desktop Agent och Azure Virtual Desktop Agent Boot Loader inte visas, installeras de inte 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.

Fix 1: Lägg manuellt till de saknade komponenterna till de virtuella datorerna med hjälp av Skapa en värdpool med PowerShell.

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

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

  • Kontrollera att kontot inte har MFA.
  • Bekräfta att klientorganisationens namn är korrekt och att klientorganisationen finns i Azure Virtual Desktop.
  • Bekräfta att kontot har minst behörighet för RDS-deltagare.

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

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

Åtgärda: 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örigheter på klientorganisationen 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 som har angetts i cmdleten Get-RdsSessionHost visar statusen Ej tillgänglig

Get-RdsSessionHost cmdlet visar statusen Ej tillgänglig.

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

Fix: Följ dessa instruktioner 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 eller har genererats med förfallovärdet 999999.

Å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-RDSRegistrationInfo.
  2. Generera ny token med Rds-NewRegistrationInfo.
  3. Bekräfta att parametern -ExpriationHours är inställd på 72 (maxvärdet är 99999).

Fel: Azure Virtual Desktop-agenten rapporterar inte en pulssignal när den kör Get-RdsSessionHost

Orsak 1: RDAgentBootLoader-tjänsten har stoppats.

Fix 1: Starta Aktivitetshanteraren och starta tjänsten om tjänstfliken rapporterar en stoppad status för RDAgentBootLoader-tjänsten.

Orsak 2: port 443 kan vara stängd.

Fix 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

Azure Virtual Desktop-stackens parallella struktur installeras automatiskt med Windows Server 2019 och senare. Använd Microsoft Installer (MSI) för att installera stacken sida vid sida på Microsoft Windows Server 2016 eller Windows Server 2012 R2. För Microsoft Windows 10 är Azure Virtual Desktop-stacken sida-vid-sida aktiverad med enablesxstackrs.ps1.

Det finns tre huvudsakliga sätt som side-by-side-stacken installeras eller aktiveras på sessionsvärdpoolens virtuella datorer:

  • Med Azure Resource Manager skapa och etablera en ny Azure Virtual Desktop-värdpool med-mallen.
  • 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 sida vid sida-stacken för Azure Virtual Desktop skriver du kommandot qwinsta från kommandotolken för att bekräfta att sida vid sida-stacken ä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 installerad eller aktiverad med qwinsta listad som rdp-sxs i utdata.

Granska registerposterna nedan och bekräfta att deras värden matchar. Om registernycklar saknas eller om värdena är felmatchade följer du anvisningarna i Skapa en värdpool med PowerShell om hur du installerar 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-felkod.

Orsak: Side-by-side-stacken är inte installerad på sessionsvärd-VM:n.

Fix: Följ dessa instruktioner 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. Ladda ned och importera Azure Virtual Desktop PowerShell-modulen att använda i PowerShell-sessionen om du inte redan har gjort det. Kör sedan den här cmdleten för att logga in på ditt konto:

    Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"
    
  3. Installera stacken sida vid sida med hjälp av Skapa en värdpool med PowerShell.

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 den parallella stacken har fel:

  • 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)
  • Köra enablesxsstackrc.ps1 upprepade gånger
  • Köra enablesxsstackrc.ps1 i ett konto som inte har lokala administratörsbehörigheter

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 går du till "Registrera den virtuella datorn med Azure Virtual Desktop-värdpoolen" i Skapa en värdpool med PowerShell 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 kommer att tillämpas.

  2. Ladda ned PsExec från PsExec v2.40.

  3. Packa upp den nedladdade filen.

  4. Starta kommandotolken som lokal administratör.

  5. Navigera till mappen där PsExec har packats upp.

  6. Använd följande kommando från kommandotolken:

            psexec.exe \\<VMname> cmd
    

    Not

    VMname är datornamnet på den virtuella datorn med den felaktiga stacken sida vid sida.

  7. Godkänn Licensavtalet för PsExec genom att klicka på Godkänn.

    skärmbild av licensavtalet för programvara.

    Not

    Den här dialogrutan visas bara första gången PsExec körs.

  8. När en kommandotolkssession öppnas på den virtuella datorn med den felande side-by-side konfigurationen kör du qwinsta och bekräftar att en post med namnet rdp-sxs är tillgänglig. Om inte, finns ingen sida-vid-sida-stack på den virtuella datorn, så problemet är inte kopplat till sida-vid-sida-stacken.

    kommandotolken Administratör

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

        wmic product get name
    
  10. Kör kommandot nedan med produktnamn från steget ovan.

        wmic product where name="<Remote Desktop Services Infrastructure Agent>" call uninstall
    
  11. Avinstallera alla produkter som börjar med "Fjärrskrivbord".

  12. När alla Azure Virtual Desktop-komponenter har avinstallerats följer du anvisningarna för operativsystemet:

  13. Om operativsystemet är Windows Server startar du om den virtuella dator som hade den felaktiga stacken sida vid sida (antingen med Azure-portalen eller från PsExec-verktyget).

Om operativsystemet är Microsoft Windows 10 fortsätter du med anvisningarna nedan:

  1. Från den virtuella datorn som kör PsExec, öppna Utforskaren och kopiera disablesxsstackrc.ps1 till systemdisken på den virtuella datorn med den felaktiga side-by-side stacken.

        \\<VMname>\c$\
    

    Not

    VMname är datornamnet på den virtuella datorn med den felaktiga stacken sida vid sida.

  2. Den rekommenderade processen: Från PsExec-verktyget startar du PowerShell och navigerar till mappen från föregående steg och kör disablesxsstackrc.ps1. Du kan också köra följande cmdletar:

    Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings" -Name "SessionDirectoryListener" -Force
    Remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\rdp-sxs" -Recurse -Force
    Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" -Name "ReverseConnectionListener" -Force
    
  3. När cmdletarna har körts klart, startar du om den virtuella datorn med den felaktiga side-by-side-konfigurationen.

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

Om du loggar in på Windows 10 Enterprise-multisessioner 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å anslutningsutjämningsservern 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.

Not

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>Värd för fjärrskrivbordssession>Licensiering>Ange licensieringsläge för fjärrskrivbord. Om grupprincipinställningen är Aktiveradändrar du den till Inaktiverad. Om den redan är inaktiverad, lämna den som den är as-is.

Notera

Om du konfigurerar gruppolicy via din domän, inaktivera den här inställningen på policyinställningar som riktar sig mot dessa Windows 10 Enterprise-multisession-Virtual Machines.

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.

    En skärmbild av Windows-specifikationsfönstret. Versionsnumret är markerat med blått.

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

Version 1809

Om versionsnumret stå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.

Nästa steg