Dépannage de RDP

Dans certains cas, il est possible que vous ne puissiez pas vous connecter à votre instance de machine virtuelle (VM) Windows Compute Engine avec RDP. Cela peut être dû à des erreurs de configuration, à des erreurs réseau ou à une erreur du processus de démarrage.

Ce document propose des conseils et des approches pour dépanner et résoudre les problèmes RDP courants.

Vérifier que la VM est en ligne et prête

Une fois le démarrage de la VM terminé, ce qui peut prendre quelques minutes, confirmez son état via l'une des méthodes suivantes :

Port série 1

Le port série 1 permet de consigner l'activité du système et des applications. Consultez ses résultats pour déterminer si le démarrage de votre VM est terminé et si les services ont démarré correctement.

  1. Dans la console Google Cloud , accédez à la page Instances de VM.

    Accéder à la page "Instances de VM"

  2. Cliquez sur le nom de la VM pour laquelle vous souhaitez afficher les journaux. La page "Informations sur l'instance de VM" s'affiche.

  3. Sous journaux, sélectionnez Port série 1.

  4. Examinez la sortie du port série 1 et recherchez un résultat semblable à celui-ci :

    BdsDxe: loading Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi

UEFI: Attempting to start image.
Description: Windows Boot Manager
FilePath: HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
OptionNumber: 3.

2021/04/13 10:50:22 GCEGuestAgent: GCE Agent Started (version 20210128.00)
2021-04-13T10:50:23.4621Z OSConfigAgent Info: OSConfig Agent (version 20210217.00.0+win@1) started.
2021/04/13 10:50:42 GCEMetadataScripts: Starting startup scripts (version 20200129.00).
2021/04/13 10:50:42 GCEMetadataScripts: No startup scripts to run.

Une sortie contenant GCEGuestAgent ou GCEMetadataScripts confirme que Windows a démarré correctement. Essayez de vous reconnecter à votre VM à l'aide du protocole RDP.

Port série 2

Le port série 2 fournit une connexion interactive à la VM et affiche également le résultat de la console d'administration spéciale (SAC, Special Administrative Console). Vous pouvez utiliser la console série 2 pour déterminer si les services système ont démarré correctement.

  1. Dans la console Google Cloud , accédez à la page Instances de VM.

    Accéder à la page "Instances de VM"

  2. Cliquez sur le nom de la VM pour laquelle vous souhaitez afficher les journaux. La page "Informations sur l'instance de VM" s'affiche.

  3. Sous Journaux, développez Plus, puis cliquez sur Port série 2 (console).

  4. Examinez la sortie du port série 2 et recherchez un résultat semblable à celui-ci :

    BdsDxe: loading Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0003 "Windows Boot Manager" from HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi

UEFI: Attempting to start image.
Description: Windows Boot Manager
FilePath: HD(2,GPT,DD3FB000-7000-4000-8000-3977378A7000,0x0000,0x00000)/\EFI\Microsoft\Boot\bootmgfw.efi
OptionNumber: 3.

<machine-info>
<name>WINDOWS</name>
<guid>b7ab5000-4000-e000-e000-bc5a738da000</guid>
<processor-architecture>AMD64</processor-architecture>
<os-version>10.0</os-version>
<os-build-number>17763</os-build-number>
<os-product>Windows Server 2019 Datacenter</os-product>
<os-service-pack>None</os-service-pack>
</machine-info>
Computer is booting, SAC started and initialized.
Use the "ch -?" command for information about using channels.
EVENT: The CMD command is now available.
SAC>

Une sortie contenant SAC started and initialized ou CMD command is now available confirme que Windows a démarré correctement. Essayez de vous reconnecter à votre VM à l'aide du protocole RDP.

Capture d'écran de la VM

Les captures d'écran de VM fournissent une représentation visuelle de l'état d'une VM, semblable à celle d'un écran d'ordinateur.

  1. Avant de pouvoir effectuer une capture d'écran de votre VM, vous devez activer son affichage virtuel. Si vous n'avez pas encore activé l'affichage virtuel, consultez la section Activer les affichages virtuels.

  2. Faites une capture d'écran. Pour en savoir plus, consultez Effectuer une capture d'écran à partir d'une VM.

  3. Examinez la capture d'écran pour vérifier si l'instance est prête.

Comparez votre capture d'écran aux éléments suivants pour déterminer l'état actuel :

Si Windows n'a pas démarré correctement après quelques minutes, consultez le guide de Dépannage de Windows.

Vérifier la connectivité entre votre station de travail et l'instance de VM

Si vous rencontrez des problèmes lors de la connexion de votre VM Windows, il est recommandé de déterminer si le problème concerne la station de travail que vous utilisez pour vous connecter ou la VM à laquelle vous vous connectez. Vérifiez la connectivité entre votre poste de travail et la VM en exécutant la commande suivante à partir de votre poste de travail Linux, macOS ou Windows :

curl -v telnet://DESTINATION_IP_ADDRESS:PORT

Remplacez les éléments suivants :

  • DESTINATION_IP_ADDRESS : adresse IP de votre VM Windows
  • PORT : port configuré pour se connecter via RDP sur votre VM Windows.

Vous pouvez également utiliser les tests de connectivité pour une vérification plus approfondie de la connectivité entre l'instance de VM et d'autres produits et services Google Cloud . En outre, il peut également être utile de configurer un hôte bastion sur le même sous-réseau pour isoler les problèmes de connectivité RDP sur l'instance de VM.

Vérifier la connectivité au serveur de métadonnées

La connectivité au serveur de métadonnées (169.254.169.254 ou fd20:ce::254) est essentielle au bon fonctionnement d'une instance Windows. Si l'instance perd l'accès au serveur de métadonnées, les applications risquent de ne pas pouvoir obtenir d'identifiants et vous ne pourrez peut-être pas vous connecter à l'instance à l'aide du protocole RDP.

Les messages des journaux de la console du port série 1 peuvent fournir des indices sur les défaillances du réseau ou du service lors du démarrage. Par exemple, recherchez les erreurs indiquant que l'instance ne peut pas se connecter au serveur de métadonnées (169.254.169.254 ou fd20:ce::254).

Si les vérifications de l'instance réussissent, mais que vous ne parvenez toujours pas à accéder au serveur de métadonnées, suivez les étapes de la section Résoudre les problèmes d'accès au serveur de métadonnées pour tester et résoudre la connexion.

Utiliser le script de dépannage RDP

Les instances de VM Windows fournies par Google incluent un script de diagnostic qui automatise de nombreuses vérifications décrites dans ce document.

  1. Se connecter à la console d'administration spéciale (SAC) d'une VM Windows
  2. Ouvrez PowerShell en saisissant powershell.

  3. Exécutez la commande suivante pour lancer le diagnostic :

    powershell -file "C:\Program Files\Google\Compute Engine\diagnostics\rdp_status.ps1" | more

  4. Examinez le résultat pour détecter les résultats "FAIL" et appliquez les solutions suggérées.

Vérifier le mot de passe de votre instance Windows

Chaque instance Windows Compute Engine doit être associée à un mot de passe local si elle ne fait pas partie d'un domaine ou si elle n'a pas été déployée à partir d'une image personnalisée. Vérifiez que vous avez défini le bon mot de passe en vous connectant à la VM via l'outil de ligne de commande Google Cloud CLI ou la console Google Cloud . Pour en savoir plus, consultez Se connecter à la console d'administration spéciale (SAC) d'une VM Windows.

En cas de problème de connexion, essayez de créer ou de réinitialiser le mot de passe. Pour en savoir plus, consultez Gérer les comptes et les identifiants sur des VM Windows.

Vérifier si vous utilisez Windows Server Core

Lors de la connexion via RDP, si une fenêtre d'invite de commande s'affiche sur un arrière-plan vide, cela signifie probablement que vous utilisez Windows Server Core. Pour confirmer cela, exécutez la commande suivante :

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v InstallationType

La présence de Server Core dans votre résultat confirme que vous utilisez bien l'édition Windows Core.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    InstallationType    REG_SZ    Server Core

Si vous avez besoin d'une interface utilisateur graphique pour votre charge de travail, découvrez comment créer une instance Windows Server, qui contient l'édition Expérience utilisateur, au lieu d'une instance Windows Server Core. Vous pouvez également consulter la documentation Microsoft sur la gestion du serveur Windows Core.

Vérifier vos règles de pare-feu VPC

Google Compute Engine applique automatiquement une règle de pare-feu autorisant le trafic RDP aux nouveaux projets. Si vous avez un projet existant ou si avez modifié les configurations, il est possible que la règle de pare-feu par défaut qui autorise RDP n'ait pas été activée. Vérifiez l'activation de la règle autorisant le trafic RDP à se connecter au réseau sur lequel se trouve l'instance concernée.

Pour vérifier si la règle de pare-feu default-allow-rdp existe dans le projet, consultez la page Règles de pare-feu ou exécutez la commande gcloud CLI suivante :

gcloud compute firewall-rules list

En l'absence de règle vous pouvez en créer une nouvelle à l'aide de la commande suivante :

gcloud compute firewall-rules create allow-rdp --allow tcp:3389

Vérifier l'adresse IP externe

Veillez à vous connecter à l'adresse IP externe qui correspond à l'instance. Affichez l'adresse IP de l'instance à partir de la page d'instance de VM ou à l'aide de la commande gcloud CLI suivante :

gcloud compute instances list

Résoudre les problèmes liés à RDP sur les VM sans accès à Internet direct

Lorsque vous vous connectez à une VM Windows qui ne possède pas d'adresse IP externe, la connexion RDP peut cesser de répondre à l'invite Sécurisation de la connexion à distance ou Configuration de la session à distance, puis expirer. Ce problème se produit généralement lorsque vous vous connectez via un tunnel de transfert TCP Identity-Aware Proxy (IAP) à une VM qui ne dispose pas d'un accès à Internet sortant direct.

Lors du handshake TLS pour l'authentification au niveau du réseau, l'API cryptographique Windows (CAPI) valide le certificat X.509 utilisé par l'écouteur RDP. Pour valider ce certificat, CAPI envoie des requêtes HTTP sortantes aux points de terminaison de la liste de révocation de certificats (CRL), du protocole OCSP (Online Certificate Status Protocol) ou de Windows Update. Étant donné que le service TermService et la validation du certificat s'exécutent dans le contexte du système, ils utilisent les paramètres proxy WinHTTP à l'échelle du système plutôt que les paramètres proxy au niveau de l'utilisateur. Si la VM ne dispose pas d'une route Internet sortante directe ou d'une configuration de proxy WinHTTP, ces requêtes HTTP expirent après 15 à 30 secondes et entraînent l'échec de la connexion RDP.

Pour résoudre ce problème, connectez-vous à la console d'administration spéciale (SAC) de la VM Windows et utilisez l'une des méthodes suivantes en fonction de vos exigences de réseau et de sécurité :

Configurer un proxy HTTP à l'échelle du système à l'aide de WinHTTP

Si votre réseau achemine le trafic Internet sortant via un proxy HTTP, configurez le proxy au niveau de WinHTTP afin que les requêtes de validation de certificat au niveau du système utilisent le proxy :

  • Pour spécifier directement un serveur proxy WinHTTP, exécutez la commande suivante à partir d'une invite de commande avec des droits d'administrateur :

    netsh winhttp set proxy PROXY_SERVER:PORT

    Remplacez les éléments suivants :

    • PROXY_SERVER : adresse IP ou nom d'hôte de votre serveur proxy HTTP
    • PORT : numéro de port de votre serveur proxy HTTP

  • Si un proxy au niveau de l'utilisateur est déjà configuré dans Windows, importez les paramètres au niveau de l'utilisateur dans WinHTTP en exécutant la commande suivante :

    netsh winhttp import proxy source=ie

Désactiver les mises à jour automatiques des certificats racine

Si votre VM s'exécute dans un environnement isolé sans accès Internet sortant ni proxy HTTP, désactivez les mises à jour automatiques des certificats racine afin que Windows ne valide les certificats qu'à l'aide des certificats racine installés localement :

Registre

Exécutez la commande suivante à partir d'une invite de commande avec droits d'administrateur ou d'une session PowerShell SAC :

reg add "HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot" /v DisableRootAutoUpdate /t REG_DWORD /d 1 /f

Stratégie de groupe

Si vous gérez la VM à l'aide d'une stratégie de groupe, procédez comme suit :

  1. Ouvrez l'éditeur de stratégie de groupe locale en exécutant la commande gpedit.msc.
  2. Accédez à Configuration ordinateur > Modèles d'administration > Système > Gestion de la communication Internet > Paramètres de communication Internet.
  3. Définissez l'option Désactiver la mise à jour automatique des certificats racine sur Activé.
  4. Facultatif : Si les retards de connexion persistent parce qu'un certificat personnalisé inclut des points de terminaison d'accès aux informations d'autorité ou de liste de révocation de certificats, réduisez le délai avant expiration de la récupération du réseau CAPI :
    1. Dans l'éditeur de stratégie de groupe locale, accédez à Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies de clé publique.
    2. Ouvrez Certificate Path Validation Settings (Paramètres de validation du chemin d'accès au certificat) et sélectionnez l'onglet Network Retrieval (Récupération réseau).
    3. Sélectionnez Définir ces paramètres de stratégie et définissez les deux valeurs de délai avant expiration de récupération sur 1 seconde.
  5. Pour appliquer les modifications, exécutez la commande gpupdate /force à partir d'une invite de commande avec des droits élevés.

Configurer l'accès à Internet sortant à l'aide de Cloud NAT

Si vos exigences de sécurité autorisent le trafic Internet sortant de la VM, configurez une passerelle Cloud NAT avec une route Internet par défaut 0.0.0.0/0 afin que la VM puisse accéder directement aux points de terminaison de validation de certificat externes.

Utiliser les services Bureau à distance de Windows

Si les services Bureau à distance de Windows (anciennement Terminal Services) sont installés sur votre instance, les conditions des licences d'accès client (CAL, Client Access License) s'appliquent. Avec ces CAL, les connexions RDP échoueront dans l'une des conditions suivantes :

  • Vous avez utilisé toutes vos licences disponibles.
  • Votre licence est installée, mais elle n'a pas été configurée ou activée correctement.
  • Votre période d'essai pour les services Bureau à distance de 180 jours a expiré.

Les symptômes indiquant que vous ne disposez peut-être pas de suffisamment de licences valides incluent des messages tels que :

  • Cette session à distance a été interrompue, car aucun serveur de licences Bureau à distance n'est disponible pour fournir une licence.
  • La session à distance a été interrompue en raison d'une erreur liée à la gestion des licences sur le serveur Terminal Server.
  • La session à distance a été interrompue, car aucune licence d'accès client Bureau à distance n'est disponible pour cet ordinateur.

Si vos connexions RDP échouent, vous pouvez utiliser le commutateur administrateur pour vous connecter à l'instance à des fins administratives. Vous pouvez effectuer cette opération sur une machine Windows en utilisant le client Connexion Bureau à distance intégré.

%SystemRoot%\System32\mstsc.exe /admin

Deux sessions simultanées de bureau à distance pour l'administration sont incluses dans l'image Windows Server et SQL Server à la demande.

Pour résoudre les problèmes liés aux connexions RDP, achetez de nouvelles licences pour les services Bureau à distance pour votre instance. Pour plus d'informations sur les CAL, consultez la documentation Microsoft. Sinon, si les services Bureau à distance ne sont pas requis, désinstallez-les et utilisez les connexions RDP classiques.

Valider la configuration et les ressources au niveau du système d'exploitation

Si l'environnement et les configurations invités de l'instance sont corrects, il se peut que le système d'exploitation de l'instance soit mal configuré. De plus, sans ressources adéquates, il est possible qu'une connexion RDP ne soit pas établie. Pour valider la configuration au niveau du système d'exploitation, connectez-vous à Windows SAC :

Vérifier que la VM dispose des ressources nécessaires

Vérifiez que l'utilisation du processeur, de la mémoire, du disque et de l'espace disque disponible n'atteint pas leurs limites. Ces données peuvent être inspectées en affichant les métriques d'observabilité dans la console Google Cloud . Certaines métriques ne sont disponibles que pour les VM sur lesquelles l'agent Ops est installé. Si l'agent Ops n'est pas installé, utilisez les commandes suivantes lorsqu'il est connecté à SAC :

Utilisation du processeur, de la mémoire, du disque et de la capacité du disque

  • Utilisation du processeur : 
    typeperf "\Processor(_Total)\% Processor Time" -sc 5
  • Utilisation de la mémoire : 
    typeperf "\Memory\% Committed Bytes In Use" -sc 5
  • Espace disque utilisé :
    typeperf "\LogicalDisk(*)\% Idle Time" -sc 5
  • Capacité du disque : 
    fsutil volume diskfree C:

Voici les utilisations de ressources recommandées pour une connexion RDP. Toutefois, il ne s'agit que d'estimations, qui peuvent varier d'une instance à l'autre.

  • Processeur : < 80%
  • Mémoire : < 80%
  • Espace disque : > 20%
  • Disque inactif : > 50%

Si l'une des estimations suggérées atteint ses limites, vous pouvez modifier cette ressource pour l'instance de VM. Pour modifier les propriétés d'une VM, découvrez comment modifier le type de machine d'une instance de VM et augmenter la taille d'un disque.

Vérifier la configuration de l'OS

Connectez-vous à la SAC de la VM et exécutez les commandes suivantes pour vous assurer que l'instance accepte les connexions :

  1. Vérifiez que l'adaptateur Ethernet est activé :

    • Commande : 
      netsh interface show interface
    • Réussite : l'état de l'administrateur est défini sur Activé pour le nom d'interface Ethernet.
    • Échec : l'état de l'administrateur est défini sur Désactivé pour le nom d'interface Ethernet.
    • Solution : activez l'adaptateur Ethernet : 
      netsh interface set interface Ethernet admin=enabled

  2. Vérifiez que l'instance possède une configuration IP valide :

    • Commande : 
      ipconfig /all
    • Réussite : l'adaptateur Ethernet Ethernet affiche une adresse IPv4 du sous-réseau auquel l'instance est attribuée.
    • Échec : aucune adresse IPv4 ou une adresse qui ne correspond pas à celle affichée dans la console Google Cloud .
    • Solution : passez à l'étape suivante.

  3. Vérifiez que DHCP est activé sur l'instance :

    • Commande : 
      netsh interface ipv4 show addresses
    • Réussite : le résultat sous Ethernet contient DHCP Enabled: Yes.
    • Échec : le résultat sous Ethernet contient DHCP Enabled: No.
    • Solution : activez le protocole DHCP sur l'adaptateur Ethernet : 
      netsh interface ipv4 set address Ethernet dhcp

  4. Vérifiez que le service Bureau à distance ("Remote Desktop Service") est en cours d'exécution :

    • Commande : 
      net start | find "Remote Desktop Services"
    • Succès : Remote Desktop Service
    • Échec : ("Remote Desktop Service" n'est pas dans la sortie)
    • Solution : démarrez les services Bureau à distance : 
      net start "Remote Desktop Services"

  5. Vérifiez l'activation des connexions à distance :

    • Commande : 
      reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
    • Succès : fDenyTSConnections REG_DWORD 0x0
    • Échec : fDenyTSConnections REG_DWORD 0x1
    • Solution : activez les connexions de bureau à distance dans le registre : 
      reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /f /v fDenyTSConnections /t REG_DWORD /d 0

  6. Assurez-vous que les connexions de bureau à distance sont activées au niveau du pare-feu Windows :

    • Commande : 
      netsh advfirewall firewall show rule name="Remote Desktop - User Mode (TCP-In)"

    • Succès : Enabled:Yes, Direction: In, Profiles: Public, Grouping: Remote Desktop, LocalIP: Any, RemoteIP: Any, Protocol:TCP, LocalPort: 3389, RemotePort: Any, Edge traversal: No, Action: Allow

    • Échec : (résultats inattendus, tels que "Enabled = no")

    • Solution : activez la règle de pare-feu "Bureau à distance" par défaut dans le pare-feu Windows : 

      netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

      Sur les VM Windows clonées, la carte réseau virtuelle peut être définie par défaut sur le profil de pare-feu de réseau Public. Si vos règles de pare-feu bloquent le port 3389 sur le profil Public, exécutez la commande suivante dans SAC pour basculer le profil réseau sur Private : 

      powershell -Command "Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private"

  7. Consultez le numéro de port configuré pour les connexions RDP sur l'instance distante :

    • Commande : 
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
    • Succès : PortNumber REG_DWORD [PORT NUMBER]
    • Échec : (numéro de port inattendu)

    • Solution : Configurez le numéro de port dans le registre requis pour RDP : 

      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /f /v PortNumber /t REG_DWORD /d [PORT NUMBER]

  8. Vérifiez qu'une autre application n'essaie pas d'utiliser le même port :

    • Commande : 
      netstat -ano | find "3389"
    • Réussite : Recherchez une entrée pour le port RDP attribué avec l'état Écouter. Vous pouvez trouver le service correspondant à l'aide de l'identifiant de processus (PID) en utilisant la commande suivante : 
      tasklist /svc | find ""
       où PID est l'identifiant de la commande précédente. La sortie ne doit renvoyer que TermService.
    • Échec : tout élément, à l'exception de TermService, utilise le port attribué, ou aucun processus n'écoute sur le port 3389, même si TermService est en cours d'exécution.

    • Solution : Configurez l'application ou le service pour utiliser un autre numéro de port.

      Si TermService s'exécute sur une VM Windows clonée, mais que le port 3389 n'écoute pas, vérifiez si une opération Sysprep incomplète a laissé le système d'exploitation dans un état de configuration inachevé :

      1. Interrogez les indicateurs d'état de généralisation et de configuration de Sysprep : 
        reg query "HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus" /v GeneralizationState
         
        reg query "HKEY_LOCAL_MACHINE\SYSTEM\Setup" /v SystemSetupInProgress
         
        reg query "HKEY_LOCAL_MACHINE\SYSTEM\Setup" /v OOBEInProgress
      2. Recherchez l'ID d'événement 34 dans le journal opérationnel du gestionnaire de session local, qui indique que l'écouteur RDP est supprimé lorsque la configuration du système est marquée comme étant en cours : 
        wevtutil qe "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" /q:"*[System[(EventID=34)]]" /f:text /c:1
      3. Si SystemSetupInProgress ou OOBEInProgress est défini sur 0x1, ou si GeneralizationState n'est pas défini sur 0x7 une fois la configuration terminée, réinitialisez les indicateurs de configuration bloqués et redémarrez TermService, ou recréez la VM à partir d'une image de l'OS où GCESysprep s'est terminé correctement : 
        reg add "HKEY_LOCAL_MACHINE\SYSTEM\Setup" /v SystemSetupInProgress /t REG_DWORD /d 0 /f
         
        reg add "HKEY_LOCAL_MACHINE\SYSTEM\Setup" /v OOBEInProgress /t REG_DWORD /d 0 /f
         
        reg add "HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus" /v GeneralizationState /t REG_DWORD /d 7 /f
         
        powershell -Command "Restart-Service -Name TermService -Force"

  9. Assurez-vous que le compte d'utilisateur connecté dispose des autorisations de connexion à distance :

    • Commande : 
      net localgroup "Remote Desktop Users"
    • Succès : ("target local or domain username" dans la liste obtenue)
    • Échec : ("target local or domain username" est manquant)

    • Solution : ajoutez la règle "Utilisateurs du Bureau à distance" à un utilisateur du domaine : 

      net localgroup "Remote Desktop Users" /add [DOMAIN\USERNAME]

      Le domaine n'est requis que pour les comptes utilisateur d'un système joint à un autre domaine. Pour les comptes locaux, spécifiez uniquement le nom d'utilisateur.

  10. Vérifiez que la négociation de sécurité client ou serveur est définie sur sa valeur par défaut :

    • Commande : 
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
    • Réussite : SecurityLayer REG_DWORD 0x1
    • Échec : SecurityLayer REG_DWORD 0x0 (ou 0x2)
    • Solution : définissez la valeur de négociation du niveau de sécurité dans le registre : 
      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 1 /f

  11. Lorsque votre instance est connectée à un domaine Active Directory, mais que la connexion n'a pas pu être établie, vous pouvez recevoir le message d'erreur suivant lorsque vous essayez d'accéder à votre instance :

    The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA.

    Vérifiez que l'authentification au niveau du réseau (NLA) est définie sur sa valeur par défaut :

    • Commande : 
      reg query "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
    • Réussite : UserAuthentication REG_DWORD 0x0
    • Échec : UserAuthentication REG_DWORD 0x1
    • Solution : définissez la valeur d'authentification au niveau du réseau dans le registre : 
      reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f

  12. Vérifiez que la taille du MTU ne dépasse pas celle du MTU réseau :

    • Commande : 
      netsh interface ipv4 show subinterfaces
    • Réussite : lorsque le nombre qui suit MTU correspond au MTU du réseau VPC.
    • Échec : lorsque le nombre qui suit MTU est supérieur au MTU du réseau VPC.

    • Solution : définissez le MTU de l'interface sur le MTU du réseau VPC : 

      netsh interface ipv4 set subinterface Ethernet mtu=MTU_OF_VPC_NETWORK

      Pour plus d'informations sur les incompatibilités de taille du MTU, consultez notre documentation sur la fragmentation des paquets.

  13. Si vous essayez de vous connecter à la VM à l'aide du protocole RDP et que la VM affiche l'écran de disposition du clavier, vous devez sélectionner une langue en vous connectant à Windows SAC. Pour sélectionner une langue, procédez comme suit :

    1. Se connecter à la SAC
    2. Ouvrez Powershell en saisissant powershell.

    3. Obtenez la chaîne de langue appropriée.

      Get-WinUserLanguageList

    4. Définissez la mise en page. Remplacez LANGUAGE_TAG par la mise en page de langage souhaitée (par exemple, en-US).

      Set-WinUserLanguageList -LanguageList LANGUAGE_TAG -force

    5. Redémarrez votre instance.

      shutdown -r -t 0

  14. Erreurs RDP sur l'écran de connexion mentionnant you need the right to sign in through Remote Desktop Services ou you must be granted the Allow log on through Terminal Services right, le groupe Utilisateurs ou Administrateurs à distance a été supprimé du paramètre de stratégie d'ordinateur local trouvé dans Autoriser la connexion via les services de bureau à distance ouSeRemoteInteractiveLogonRight.

  15. Vérifiez qu'aucune autorisation ne bloque l'authentification des certificats :

    • Commande : 
      icacls.exe "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys"
    • Réussite : Le résultat ressemble à Tout le monde:(R,W) BUILTIN\Administrateurs:(F).
    • Échec : La sortie ne correspond pas à Tout le monde:(R,W) BUILTIN\Administrateurs:(F)

  16. Assurez-vous que les paramètres de protection antivirus/des points de terminaison du client permettent d'utiliser le numéro de port et les services configurés.

  17. Erreur de correction de l'oracle de chiffrement CredSSP : si vous recevez une erreur mentionnant "Correction de l'oracle de chiffrement CredSSP", assurez-vous que les dernières mises à jour Windows sont installées sur votre poste de travail et sur l'instance de VM.

  18. Code d'erreur interne 0x4 : si votre connexion échoue avec le code d'erreur 0x4, assurez-vous que TLS 1.2 est activé sur le serveur. Vous pouvez consulter ce registre sur HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client.

  19. Code d'erreur 0x108 : si vous recevez le message "Code d'erreur : 0x108 (les deux ordinateurs n'ont pas pu se connecter dans le délai imparti)", vérifiez les métriques d'observabilité pour détecter une utilisation élevée du processeur ou de la mémoire. Si les ressources sont épuisées, envisagez de modifier le type de machine.

Vérifier les limites d'expiration des sessions

Si vous êtes en mesure d'établir une connexion RDP, mais que vous êtes déconnecté après un certain temps avec un message indiquant que votre session a expiré, vérifiez que les valeurs suivantes sont celles attendues :

Chemin du registre : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Clés de registre :

  • MaxDisconnectionTime
  • MaxIdleTime
  • MaxConnectionTime
  • MaxDisconnectionTime
  • RemoteAppLogoffTimeLimit

Ces valeurs sont définies en millisecondes. Si ces clés ne figurent pas dans votre registre, il n'y a pas de limite de session sur votre instance de VM. Si ces clés sont présentes dans votre registre, mais que leurs valeurs sont définies sur 0, votre session n'expirera jamais.

Résoudre les problèmes liés au démarrage de Windows

Si les étapes de dépannage précédentes n'ont pas résolu votre problème de connexion RDP, votre instance Windows risque de ne pas démarrer ou de ne pas s'exécuter correctement. Dans ce cas, consultez notre guide de dépannage de Windows.

Étapes suivantes