Partager via


Instructions de résolution des problèmes de DirectAccess

Essayez notre agent virtuel : il peut vous aider à identifier et à résoudre rapidement les problèmes courants liés à DirectAccess.

Ce guide fournit des informations de dépannage pour DirectAccess dans les systèmes d’exploitation Windows. Il est conçu pour vous aider à identifier et résoudre les problèmes en rapport avec DirectAccess.

Liste de contrôle pour la résolution des problèmes

À jour

Conservez les serveurs DirectAccess et les appareils clients DirectAccess mis à jour. Vous devez régulièrement mettre à jour Windows, les pilotes, les microprogrammes, les composants d’intégration Hyper-V et les outils VMware. Le cas échéant, vous devez également mettre à jour l’hyperviseur qui exécute les machines virtuelles.

Version du système d’exploitation

Utilisez une version actuelle du système d’exploitation : au moins Windows Server 2016 ou Windows Server 2019 pour les serveurs DirectAccess. Les clients DirectAccess doivent exécuter une version récente de Windows 10 ou Windows 11.

Monitor

Utilisez la surveillance des serveurs DirectAccess. Au minimum, les métriques suivantes doivent faire l’objet d’un monitoring :

  • Utilisation du processeur
  • Utilisation de la mémoire
  • Performances des disques
  • Espace disque disponible
  • Disponibilité de la carte réseau
  • Débit de la carte réseau et ports NetNat.

Conservez également un historique des rapports de performances. Ces rapports pourront vous être utiles pour résoudre les problèmes liés aux performances.

Composants d’infrastructure

DirectAccess s’appuie sur des pare-feu de périmètre ou internes, des équilibreurs de charge, des routeurs, des commutateurs, et ainsi de suite. Ces composants doivent également faire l’objet d’un monitoring. Par exemple, un équilibreur de charge à pleine capacité affecte DirectAccess. Toutefois, dans le contexte de DirectAccess, il n’y a pas grand-chose à faire pour atténuer cette situation.

Sauvegarde

DirectAccess stocke tous les paramètres dans les stratégies de groupe. Il est essentiel de conserver une sauvegarde à jour et valide de tous les paramètres de stratégie de groupe DirectAccess.

Bonnes pratiques

Dimensionnement et planification de la capacité

La meilleure approche de résolution des problèmes est la méthode « ramp, test et monitor » incrémentielle. Le nombre de serveurs DirectAccess dépend beaucoup de ce que font les utilisateurs. Cela inclut l’utilisation d’applications client ou serveur, l’exploration de sites web internes et l’utilisation ou la copie de fichiers volumineux (comme des fichiers de CAO).

Un bon point de départ consiste à utiliser au moins quatre processeurs et plus de 8 Go de RAM. Pour de meilleurs résultats, utilisez huit processeurs, plus de 12 Go de RAM et plus de 80 Go d’espace disque. Il n’y a pas de préférence programmatique pour les serveurs physiques ou virtuels. Chaque type de serveur fonctionne bien s’il est correctement dimensionné.

Pour plus d’informations, consultez Planification de la capacité DirectAccess.

Limite

Il n’existe aucune limite connue pour le nombre de connexions qu’un serveur DirectAccess peut accepter, en dehors des contraintes de ressources (processeur, mémoire, espace disque, débit réseau, et ainsi de suite) et des ports NETNat (NAT64).

NetNat (NAT64) est utilisé sur les serveurs DirectAccess pour effectuer la conversion entre IPv6 et IPv4. Par défaut, 40 999 (6 001-49 000) ports NetNat sont disponibles quand vous utilisez une seule adresse IP sur la carte réseau interne.

Note

Le nombre de connexions actives DirectAccess n’est pas nécessairement lié au nombre de ports NetNat utilisés. En fonction de ce que font les utilisateurs et du nombre de ports utilisés par un client DirectAccess, il est possible qu’un petit nombre de clients DirectAccess épuise tous les ports NetNat.

Pour examiner la configuration de NetNat, vous pouvez exécuter la commande Get-NetNatTransitionConfiguration.

Problèmes courants et solutions

Consultez les articles suivants pour résoudre les problèmes de console de serveur DirectAccess :

Collecte de données

Avant de contacter le support Microsoft, vous pouvez collecter des informations sur votre problème.

Prerequisites

  1. TSS doit être exécuté par des comptes disposant de privilèges d’administrateur sur le système local, et le CLUF doit être accepté (une fois que l’CLUF est accepté, TSS n’invite pas à nouveau).
  2. Nous recommandons la stratégie d’exécution powerShell de l’ordinateur RemoteSigned local.

Note

Si la stratégie d’exécution PowerShell actuelle n’autorise pas l’exécution de TSS, effectuez les actions suivantes :

  • Définissez la RemoteSigned stratégie d’exécution pour le niveau de processus en exécutant l’applet de commande PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
  • Pour vérifier si la modification prend effet, exécutez l’applet de commande PS C:\> Get-ExecutionPolicy -List.
  • Étant donné que les autorisations au niveau du processus s’appliquent uniquement à la session PowerShell actuelle, une fois que la fenêtre PowerShell donnée dans laquelle TSS s’exécute est fermée, l’autorisation affectée pour le niveau de processus revient également à l’état précédemment configuré.

Collecter les informations clés avant de contacter le support Microsoft

  1. Téléchargez TSS sur tous les nœuds et décompressez-le dans le dossier C :\tss .

  2. Ouvrez le dossier C :\tss à partir d’une invite de commandes PowerShell avec élévation de privilèges.

  3. Démarrez les traces sur le client et le serveur à l’aide des applets de commande suivantes :

    Note

    Si vous utilisez un scénario d’équilibrage de charge réseau, démarrez les journaux sur tous les serveurs.

    • Client DA :

      TSS.ps1 -Scenario NET_Dacli
      
    • Serveur DA :

      TSS.ps1 -Scenario NET_DAsrv
      
  4. Acceptez le CLUF si les traces sont exécutées pour la première fois sur le serveur ou le client.

  5. Autoriser l’enregistrement (PSR ou vidéo).

  6. Reproduire le problème avant d’entrer Y.

    Note

    Si vous collectez des journaux sur le client et le serveur, attendez ce message sur les deux nœuds avant de reproduire le problème.

  7. Entrez Y pour terminer la collection de journaux une fois le problème reproduit.

Les traces sont stockées dans un fichier zip dans le dossier C :\MS_DATA , qui peut être chargé dans l’espace de travail à des fins d’analyse.

Référence