Troubleshooting bei DirectAccess und der DirectAccess Connectivity Assistant

Ich hatte letzte Woche einen Anruf von einem Techniker, der bei sich in der Firma DirectAccess einsetzen möchte. Die Einrichtung wurde anhand unseres Howtos “Einrichtung von DirectAccess” durchgeführt. Nach Fertigstellung der Einrichtung wurde der erste Test-Client zur Gruppe “DirectAccess_Clients” hinzugefügt und die Gruppenrichtlinien wurden per “gpupdate” aktualisiert. Nach einem Neustart hatte der Client das Problem, das er zum einen nicht per DirectAccess eine Verbindung aufbauen konnte, zum anderen sich aber auch nicht mehr an der Domäne anmelden konnte, wenn er mit einem Kabel an das Unternehmensnetz angeschlossen war. Abhilfe konnte nur ein Entfernen der Domänen-Mitgliedschaft und eine erneute Aufnahme schaffen inkl. Entfernen des Computer-Kontos aus der Sicherheitsgruppe.

Nachdem ich mich dann per Fernwartung bei dem Kunden aufgewählt habe und wir uns die Umgebung gemeinsam angeschaut haben stelle sich relativ schnell heraus, dass die Veröffentlichung der Sperrlisten nur für intern gemacht wurde und nicht öffentlich. Dies bewirkte, das der Client an einem Nicht-Firmen-Anschluss (in diesem Fall wurde die Internetverbindung über UMTS aufgebaut) die Sperrliste nicht abrufen bzw. verifizieren konnte. Die Einstellung wurde in den Eigenschaften der CA geändert, dies hatte allerdings zur Folge, dass alle bisher ausgestellten Zertifikate erneut ausgestellt werden mussten. Nachdem alle benötigten Zertifikate aktualisiert wurden und das Computer-Konto erneut in die Sicherheitsgruppe aufgenommen wurde konnte der Client eine 2001-Adresse beziehen und ein Ping auf die IPv6-Adresse des DirectAccess-Servers funktionierte ebenfalls. Was nicht funktionierte war eine DNS-Auflösung.

Der Kunde hat dann bemerkt, das auf dem DirectAccess-Server in den eigenen Zertifikaten nur ein Zertifikat hinterlegt war. Hier müssen allerdings zwei Zertifikate eingetragen sein, einmal für den Computer und einmal für die externe Adresse, unter der der DirectAccess-Server erreichbar ist. Hier ein Bild unseres Servers:

DirectAccess-Troubleshooting-01

Nachdem dies nun gemacht wurde, funktionierte die Verbindung allerdings immer noch nicht. Ein Aufruf der beiden Befehle

netsh advfirewall monitor show mmsa

und

netsh advfirewall monitor show qmsa

im “DirectAccess-Mode” (also Einwahl des Clients per UMTS) zeigten keine Ausgabe. Bei meinem Client sieht die Ausgabe wie folgt aus:

DirectAccess-Troubleshooting-02

Nachdem nun alle Zertifikate auf den beteiligten Servern überprüft wurden stellte sich heraus, das bei zwei Zertifikaten falsche Sperrlistenverteilungspunkte angezeigt wurden, und zwar cls.contoso.com. Nach einer Neuerstellung der Zertifikate funktionierte die Einwahl sofort, inkl. DNS-Auflösung.

Ein weiteres sehr interessantes Tool ist der “DirectAccess Connectivity Assistent”. Mit Hilfe des Assistenten ist der Client in der Lage den Status der Verbindung anzuzeigen. Vorher gab es für den normalen Benutzer wenig Möglichkeiten sich anzeigen zu lassen, ob DirectAccess nun funktioniert oder nicht. Weiterhin war es für den Administrator ziemlich schwierig herauszufinden, warum die Verbindung nicht geht, gerade wenn sich der Client außerdem des Unternehmens befindet. Um diese Probleme zu beseitigen hat Microsoft einen Assistenten herausgebracht, ein kleines Tool welches den Status unten rechts durch ein kleines Icon anzeigt.

In dem Download-Paket befinden sich mehrere Dateien:

  • Eine .ADMX-Datei und eine .ADML-Datei, diese beiden Dateien werden benötigt um die Gruppenrichtlinienverwaltung zu erweitern und um Optionen hinzuzufügen.
  • Das Deployment-Guide, ein Word-Dokument mit der Erklärung wie das Programm gesteuert und ausgerollt werden kann
  • Die Release-Notes, eine kleine HTML-Datei mit weiteren Informationen und Voraussetzungen für die Installation
  • Der DirectAccess Connectivity Assistent, sowohl in der x86 als auch in der x64-Variante

Laut dem Guide sollen die ADMX und die ADML-Dateien unter “%systemroot%\PolicyDefinitions” eingefügt werden, dies hat bei unserer Umgebung allerdings nicht funktioniert. Ich musste die Dateien auf einem der drei Domänencontroller bei uns im Verzeichnis “C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions” einfügen. Danach erschien die Erweiterung in der Gruppenrichtlinienverwaltung.

Ich habe das schon vorhandene DirectAccess-Objekt erweitert, während ich diese Zeilen allerdings schreibe fällt mir auf das ich nicht weiß was passiert wenn man per DirectAccess-Konsole Änderungen an der Konfiguration vornimmt und dann automatisch das Gruppenrichtlinienonjekt aktualisiert. Möglicherweise werden alle Änderungen, die manuell vorgenommen wurden, wieder gelöscht. In diesem Fall wäre es sinnvoll ein neues Objekt zu erstellen und die Einstellungen dort einzutragen. Das ganze sieht wie folgt aus:

DirectAccess-Troubleshooting-03

Unter “Support Email” kann die Email-Adresse eingetragen werden, an die die gesammelten Logfiles des Programms gesendet werden.

DirectAccess-Troubleshooting-04

Unter “DTEs” werden die beiden IPv6-Adressen des DirectAccess-Servers eingetragen. Diese findet man heraus, indem man auf dem DirectAccess-Server ein “ipconfig /all” ausführt. Die beiden Adressen stehen unter “Tunneladapter 6TO4 Adapter”, in dem Feld unten MUSS ein PING: vor den beiden Adressen stehen.

DirectAccess-Troubleshooting-05

Bei “Corporate Resources” muss eine oder mehrere FQDN-Namen von Systemen innerhalb der Domäne angegeben werden. Diese werden von dem Programm angepingt (Hier ebenfalls das PING: vor der Adresse nicht vergessen!) um zu schauen ob die Verbindung aufgebaut werden kann. Laut dem Deployment-Guide können hier auch IPv6-Adressen eingetragen werden, es wird aber empfohlen das man den Namen des Systems verwendet. Falls eine DNS-Auflösung nicht möglich ist (wie in dem Problemfall oben) würde sich dies hier bemerkbar machen.

DirectAccess-Troubleshooting-06

Nun kann das Programm entweder per GPO verteilt werden, oder man installiert es manuell auf dem oder den Client(s). Nach dem Ausführen erscheint ein kleines Icon in der Taskleiste. Ein einfacher Klick auf das Icon zeigt den Status der Verbindung:

DirectAccess-Troubleshooting-08

Ein Rechtsklick öffnet ein Menü mit einem einzigen Menüpunkt, “Advanced Diagnostics”. Bei Aufruf dieses Punktes öffnet sich das Programm und generiert ein Logfile:

DirectAccess-Troubleshooting-09

Nachdem das Logfile erstellt wurde, bekommt man angezeigt wo die Daten gespeichert wurden. Falls man nun in dem Gruppenrichtlinienobjekt eine Email-Adresse hinterlegt hat kann man auf den Button “Email Logs” klicken und es öffnet sich ein Mailclient mit einer neuen Email, an die das generierte Logfile direkt angehängt wurde.

DirectAccess-Troubleshooting-10

Teilen:

Jan Kappen

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitet seitdem bei der Rachfahl IT-Solutions GmbH & Co. KG. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure. Im April 2015 wurde Jan Kappen im Bereich "File System Storage" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

5 Kommentare:

  1. Vielen Dank für den Beitrag zum Direct Access Connectivity Assistant. Hat mir sehr geholfen.

    MFG

  2. Thomas Kronthaler

    Sehr schöner Beitrag!
    Informativ und verständlich geschrieben.

    MFG

  3. Hallo,

    es geht schon von Windows 7 aus wenn man tut was im Guide steht und RSAT installiert hat.Außerdem stimmen deine Pfade nicht :

    Copy the DirectAccess Connectivity Assistant GP.admx file to the folder %systemroot%\PolicyDefinitions.

    Copy the DirectAccess Connectivity Assistant GP.adml file to the folder %systemroot%\PolicyDefinititions\language

  4. Warum ich andere Pfade nehmen musste habe ich geschrieben…
    Cheers, Jan

  5. Danke für den guten Beitrag!

    Kleine Anmerkung, sofern der Ordner “C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions” angelegt wird, setzt er sich immer vor dem Ordner “%systemroot%\PolicyDefinitions” durch. D.h. alle adml- & admx-Vorlagen werden nur noch aus dem neuen Pfad bezogen.

    Besten Gruß

    Jan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.