Freigeben über

Anleitung zur Problembehandlung für DirectAccess

Testen Sie unseren virtuellen Agent: Der Agent kann Sie dabei unterstützen, häufige DirectAccess-Probleme schnell zu erkennen und zu beheben.

Dieser Leitfaden enthält Informationen zur Problembehandlung für DirectAccess in Windows-Betriebssystemen. Er soll Ihnen beim Identifizieren und Lösen von Problemen im Zusammenhang mit DirectAccess helfen.

Checkliste zur Problembehandlung

Aktuell

Halten Sie DirectAccess-Server und DirectAccess-Clientgeräte auf dem neuesten Stand. Sie müssen Windows, Treiber, Firmware, Hyper-V-Integrationskomponenten und VMware-Tools regelmäßig aktualisieren. Falls zutreffend, müssen Sie auch den Hypervisor aktualisieren, auf dem die VMs ausgeführt werden.

Betriebssystemversion

Verwenden Sie eine aktuelle Betriebssystemversion: mindestens Windows Server 2016 oder Windows Server 2019 für die DirectAccess-Server. DirectAccess-Clients sollten eine aktuelle Version von Windows 10 oder Windows 11 ausführen.

Monitor

Verwenden Sie die Überwachung für die DirectAccess-Server. Überwachen Sie mindestens die folgenden Metriken:

  • CPU-Auslastung
  • Speicherauslastung
  • Datenträgerleistung
  • Freier Speicherplatz
  • Verfügbarkeit von Netzwerkadaptern
  • Netzwerkadapterdurchsatz und NetNat-Ports.

Behalten Sie außerdem einen Verlauf der Leistungsberichte bei. Die Berichte können hilfreich sein, wenn Sie leistungsbezogene Probleme behandeln.

Infrastrukturkomponenten

DirectAccess basiert auf Umkreis- oder internen Firewalls, Lastenausgleichsmodulen, Routern, Switches usw. Diese Komponenten sollten ebenfalls überwacht werden. Wenn beispielsweise ein Lastenausgleichsmodul die Kapazitätsgrenze erreicht, wirkt sich dies auf DirectAccess aus. Aus Sicht von DirectAccess gibt es jedoch nicht viel, was Sie unternehmen können, um diese Situation zu entschärfen.

Backup

DirectAccess speichert alle Einstellungen in Gruppenrichtlinien. Es ist wichtig, dass Sie eine aktuelle und gültige Sicherung aller DirectAccess-Gruppenrichtlinieneinstellungen verwalten.

Bewährte Methoden

Größen- und Kapazitätsplanung

Der beste Problembehandlungsansatz ist die Methode "inkrementelle Rampe, Test und Überwachung". Die Anzahl der DirectAccess-Server hängt stark davon ab, welche Aktionen Benutzer ausführen. Dazu zählt die Verwendung von Client- oder Serveranwendungen, das Durchsuchen interner Websites und das Arbeiten an oder Kopieren von großen Dateien (z. B. CAD-Dateien).

Ein guter Ausgangspunkt ist die Verwendung von mindestens vier CPUs und mehr als acht GB RAM. Eine bessere Wahl wären acht CPUs, mehr als 12 GB RAM und mehr als 80 GB Speicherplatz. Es gibt keine programmgesteuerte Bevorzugung von physischen oder virtuellen Servern. Beide Optionen funktionieren gut, wenn die Dimensionierung angemessen ist.

Weitere Informationen finden Sie unter DirectAccess-Kapazitätsplanung.

Begrenzung

Es gibt keinen bekannten Grenzwert für die Anzahl der Verbindungen, die ein DirectAccess-Server akzeptieren kann, abgesehen von Ressourceneinschränkungen (CPU, Arbeitsspeicher, Speicherplatz, Netzwerkdurchsatz usw.) und NetNat(NAT64)-Ports.

NetNat (NAT64) wird auf den DirectAccess-Servern für die Übersetzung zwischen IPv6 und IPv4 verwendet. Standardmäßig sind 40.999 (6001bis 49000) NetNat-Ports verfügbar, wenn Sie eine einzelne IP-Adresse für den internen Netzwerkadapter verwenden.

Notiz

Die Anzahl der aktiven DirectAccess-Verbindungen bezieht sich nicht unbedingt auf die Anzahl der verwendeten NetNat-Ports. Eine kleine Anzahl von DirectAccess-Clients kann sämtliche NetNat-Ports auslasten, je nachdem, welche Aktionen Benutzer ausführen und wie viele Ports von einem DirectAccess-Client verwendet werden.

Die NetNat-Konfiguration kann durch Ausführen des Befehls Get-NetNatTransitionConfiguration angezeigt werden.

Bekannte Probleme und Lösungen

Lesen Sie die folgenden Artikel, um Probleme mit der DirectAccess-Serverkonsole zu beheben:

Datensammlung

Bevor Sie sich an den Microsoft-Support wenden, können Sie Informationen zu Ihrem Problem sammeln.

Voraussetzungen

  1. TSS muss von Konten mit Administratorrechten im lokalen System ausgeführt werden, und EULA muss akzeptiert werden (sobald EULA akzeptiert wurde, wird TSS nicht mehr aufgefordert).
  2. Wir empfehlen die PowerShell-Ausführungsrichtlinie des lokalen Computers RemoteSigned .

Notiz

Wenn die aktuelle PowerShell-Ausführungsrichtlinie das Ausführen von TSS nicht zulässt, führen Sie die folgenden Aktionen aus:

  • Legen Sie die Ausführungsrichtlinie RemoteSigned für die Prozessebene fest, indem Sie das Cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSignedausführen.
  • Führen Sie das Cmdlet PS C:\> Get-ExecutionPolicy -Listaus, um zu überprüfen, ob die Änderung wirksam wird.
  • Da die Berechtigungen auf Prozessebene nur für die aktuelle PowerShell-Sitzung gelten, sobald das angegebene PowerShell-Fenster, in dem TSS ausgeführt wird, geschlossen ist, wird die zugewiesene Berechtigung für die Prozessebene auch wieder in den zuvor konfigurierten Zustand zurückgesetzt.

Sammeln sie wichtige Informationen, bevor Sie sich an den Microsoft-Support wenden

  1. Laden Sie TSS auf allen Knoten herunter, und entzippen Sie es im Ordner "C:\tss ".

  2. Öffnen Sie den Ordner "C:\tss" über eine PowerShell-Eingabeaufforderung mit erhöhten Rechten.

  3. Starten Sie die Ablaufverfolgungen auf dem Client und auf dem Server mithilfe der folgenden Cmdlets:

    Notiz

    Wenn Sie ein NLB-Szenario verwenden, starten Sie die Protokolle auf allen Servern.

    • DA-Client:

      TSS.ps1 -Scenario NET_Dacli

    • DA-Server:

      TSS.ps1 -Scenario NET_DAsrv

  4. Akzeptieren Sie die EULA, wenn die Ablaufverfolgungen zum ersten Mal auf dem Server oder dem Client ausgeführt werden.

  5. Aufzeichnung zulassen (PSR oder Video).

  6. Reproduzieren Sie das Problem, bevor Sie Y eingeben.

    Notiz

    Wenn Sie Protokolle sowohl auf dem Client als auch auf dem Server sammeln, warten Sie auf diese Meldung auf beiden Knoten, bevor Sie das Problem wiedergeben.

  7. Geben Sie Y ein, um die Protokollauflistung abzuschließen, nachdem das Problem reproduziert wurde.

Die Ablaufverfolgungen werden in einer ZIP-Datei im Ordner "C:\MS_DATA " gespeichert, die zur Analyse in den Arbeitsbereich hochgeladen werden können.

Verweis