Note: Need help with DirectAccess troubleshooting? Use the contact form at the end of this post to request assistance!
To aid in troubleshooting Windows DirectAccess client configuration and connectivity, Microsoft recently made available the Windows DirectAccess Client Troubleshooting Tool. The tool, which is a portable executable based on the .NET Framework and does not require installation, operates by performing a series of tests and health checks on a connected DirectAccess client. As of this release, the troubleshooting tool checks network interface configuration, Network Location Server (NLS) reachability, IP connectivity and the status of transition technologies, Windows Firewall with Advanced Security configuration, computer certificate status, as well as network connectivity over the infrastructure and user IPsec DirectAccess tunnels.
The tool also features an optional debug mode that provides highly detailed information gathered from each of the tests executed.
The tool is supported on both Windows 7 and Windows 8.x clients. If you implement or support DirectAccess, this utility will certainly speed up your troubleshooting by providing deep insight in to the configuration and current connectivity status for your DirectAccess clients. You can download the Microsoft DirectAccess client troubleshooting tool here.
Additional Resources
Planning and Implementing DirectAccess with Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book
Need Help with DirectAccess Troubleshooting?
If you’d like some help with your DirectAccess troubleshooting efforts, feel free to drop me a note! Fill out the contact form below and I’ll get in touch with you.
Victor Solis
/ February 25, 2014Thanks for the tip about the DA Client Troubleshooting Tool. When I ran it on a DA client, it failed a section of the User Tunnel Tests, specifically it “Failed to connect to HTTP probe at…” However, it appears that DA is working because I can access my company’s resources. What does the User Tunnel test do?
Richard Hicks
/ March 3, 2014The user tunnel test makes a connection to the “web probe host”, which is the internal network interface of the DA server. There are a number of factors that might prevent this from working while DA does work. If DA is working, I’d disregard it.
Xavier Ponard
/ March 7, 2014At this point, trying to evaluate this tool,
But don’t seems to work when online LAN or online using WWAN/DA
When i ran DirectAccess Client Troubleshooting Tool on W7.
It failed after Running IP connectivity tests.
> Check not run yet. twice and error popup appear.
on the log file:
Extract when laptop is connected to LAN.
07/03/2014 10:25:03[P:4528 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TeredoChecker] Info: netsh int teredo sh st returned:
ParamŠtres Teredo
———————————————
Type : client
Nom du serveur : teredo.ipv6.microsoft.com.
Interv. d’actual. du client : 30 secondes
Port client ÿ: unspecified
Statut ÿ: offline
Erreur ÿ: le client est dans un r‚seau administr‚
07/03/2014 10:25:03[P:4528 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TeredoChecker] Info: Teredo interface type: client.
07/03/2014 10:25:03[P:4528 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TeredoChecker] Info: Teredo interface is enabled.
07/03/2014 10:25:03[P:4528 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] Info: Check not run yet.
07/03/2014 10:25:03[P:4528 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: RootNode IPConnTestsNode found at index 2.
07/03/2014 10:25:03[P:4528 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: The RootNode IPConnTestsNode has already 1 ChildNodes.
07/03/2014 10:25:03[P:4528 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: Added ChildNode IPConnTestsNodeChild1.
07/03/2014 10:33:01[P:4528 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] ERROR: An Exception was thrown – details below:
07/03/2014 10:33:01[P:4528 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] ERROR: Object reference not set to an instance of an object.
07/03/2014 10:33:01[P:4528 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] ERROR: DAClientTroubleshooter
07/03/2014 10:33:01[P:4528 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] ERROR:
at MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.WorkHorse(CancellationToken token)
Extract on laptop when DA is fully operationnal (WWAN/DA)
07/03/2014 10:42:07[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TeredoChecker] Info: netsh int teredo sh st returned:
ParamŠtres Teredo
———————————————
Type : client
Nom du serveur : teredo.ipv6.microsoft.com.
Interv. d’actual. du client : 30 secondes
Port client ÿ: unspecified
Statut ÿ: qualified
Type de client : teredo host-specific relay
R‚seau : unmanaged
NAT : symmetric (port)
Comportement sp‚cial NAT : UPNP: Non, PortPreserving: Non
Mappage local : 100.113.229.163:50486
Mappage NAT externe : 92.90.17.16:14117
07/03/2014 10:42:07[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TeredoChecker] Info: Teredo interface type: client.
07/03/2014 10:42:07[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TeredoChecker] Info: Teredo interface is enabled.
07/03/2014 10:42:07[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TeredoChecker] Info: Teredo interface type: teredo host-specific relay.
07/03/2014 10:42:07[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TeredoChecker] Info: Teredo interface is enabled.
07/03/2014 10:42:07[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] Info: Check not run yet.
07/03/2014 10:42:07[P:6208 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: RootNode IPConnTestsNode found at index 2.
07/03/2014 10:42:07[P:6208 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: The RootNode IPConnTestsNode has already 1 ChildNodes.
07/03/2014 10:42:07[P:6208 T:1] [MicrosoftServices.WS2012DA.ClientTroubleshooter.TreeViewHandler] Info: Added ChildNode IPConnTestsNodeChild1.
07/03/2014 10:42:14[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] ERROR: An Exception was thrown – details below:
07/03/2014 10:42:14[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] ERROR: Object reference not set to an instance of an object.
07/03/2014 10:42:14[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] ERROR: DAClientTroubleshooter
07/03/2014 10:42:14[P:6208 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] ERROR:
at MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.WorkHorse(CancellationToken token)
Richard Hicks
/ March 10, 2014Interesting. I’m wondering if this is a localization issue? I’ve not tried running the tool on non-US language versions of Windows. Anyone else have this issue?
Fabien SCHWARTZ
/ March 21, 2014Had the same issue with Windows 8.1 in French: it failed after Running IP connectivity tests.
Extract of issue:
[MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm] Info: Trying to ping IPv6 address 2001:4860:4860::8888.
21/03/2014 10:24:24[P:2452 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.NetworkHelper] Info: Trying to ping 2001:4860:4860::8888.
21/03/2014 10:24:24[P:2452 T:6] [MicrosoftServices.WS2012DA.ClientTroubleshooter.NetworkHelper] ERROR: An Exception was thrown – details below: Une exception s’est produite lors d’une demande PING.
System à System.Net.NetworkInformation.Ping.Send(IPAddress address, Int32 timeout, Byte[] buffer, PingOptions options) …
=> Change language to English, tested on LAN and on Internet (DA client active), and it works.
Richard Hicks
/ March 24, 2014Thanks for sharing that information. Sure looks like it is an issue with localization. Hopefully that gets fixed in the near future. 🙂
Dan A
/ March 21, 2014Tried the tool to troubleshoot some issues we’ve had with new clients, the tool fails after IP Connectivity tests with the message “DAClientToubleshooter encountered and error while processing and needs to close”
Windows 7, SP1 Danish lang.:
System.AggregateException: Der opstod en eller flere fejl. —> System.ApplicationException: An Exception occurred in the work horse thread.
ved MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.WorkHorse(CancellationToken token)
ved MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.b__0()
ved System.Threading.Tasks.Task.InnerInvoke()
ved System.Threading.Tasks.Task.Execute()
— Slut på staksporing af indre undtagelser —
ved System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
ved System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
ved System.Threading.Tasks.Task.Wait(CancellationToken cancellationToken)
ved MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.CancelButton_Click(Object sender, EventArgs e)
ved System.Windows.Forms.Control.OnClick(EventArgs e)
ved System.Windows.Forms.Button.OnClick(EventArgs e)
ved System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
ved System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
ved System.Windows.Forms.Control.WndProc(Message& m)
ved System.Windows.Forms.ButtonBase.WndProc(Message& m)
ved System.Windows.Forms.Button.WndProc(Message& m)
ved System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
ved System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
ved System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
—> (Indre undtagelse #0) System.ApplicationException: An Exception occurred in the work horse thread.
ved MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.WorkHorse(CancellationToken token)
ved MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.b__0()
ved System.Threading.Tasks.Task.InnerInvoke()
ved System.Threading.Tasks.Task.Execute()<—
Richard Hicks
/ March 24, 2014This appears to be a localization issue. English users are working fine, but other readers of this blog are reporting similar problems with non-English installations. Hopefully this issue will be resolved in a future release of the tool.
Dominik
/ March 26, 2014Yep, the current buildjust works with EN-US or installed MUI, there are many known localization issues. But, it’s on the to-do list for vNext. 🙂
Richard Hicks
/ March 27, 2014Thanks for confirming that Dominik. Be sure to let us know when vNext is released. I’m sure you’ve gotten a lot of feedback so far. 🙂
Simon
/ April 10, 2014Hello Richard,
Thank you very much for your blog, I am setting up my first DA environment at the moment and gotten the server up and running Win2012R2 but the test client (Win8.1) is not connecting. Server side, the Operational Status is all green. Server is sitting in a DMZ with
On the client, in the IP connectivity tests I am seeing the IPHTTPS interface is not operational and also Error – no IPv6 transition technology is operational!
I have installed a Public certificate in the server with the subject field set with the public hostname of the server.
i think I am close to getting this working, but need a bit of guidance on getting it working correctly.
Any advice would be greatly welcomed.
Richard Hicks
/ April 16, 2014Since your DirectAccess server is located behind a NAT device, I’d suggest starting by disabling the 6to4 and Teredo IPv6 transition protocols as described here – http://directaccess.richardhicks.com/2013/08/27/disabling-unused-ipv6-transition-technologies-for-directaccess-clients/. Next, have a look at the output of Get-NetIPHttpsConfiguration and make sure the hostname resolves correctly. Also, make sure the hostname matches on the SSl certificate assigned to the IP-HTTPS interface on the DirectAccess server. If everything looks good, make sure that the IP-HTTPS interface on your client has a Unique Local Address (ULA) IPv6 address assigned (should begin with fd).
Jens
/ May 19, 2014Hi Richard,
I’ve read through numerous blog posts of yours regarding DirectAccess but have yet to find an answer to my problem. I’ve setup a DirectAccess server, it is running on a 2012 R2 VM inside of a 2012 R2 Host Machine. The client machine is a Windows 7 PC and the DirectAccess Connectivity Assistant shows everything is working. Network shares work remotely and it “appears” to be working fine, however there are issues when trying to access a core webapp that we used called AMS360.
When remotely connected via VPN AMS360 works, and when in the office with DA Configured and Disabled AMS360 works, however as soon as DA is Configured and Enabled this web application stops functioning. Have you run across anything similar with specific web applications that use a .NET back-end ceasing to function? I am hoping there is something missing in our DA configuration, but the only thing that errors when I run the DirectAccess Client Troubleshooting Tool is the User Tunnel Tests which show a TimeOut on the two DTEs, which above you state can be ignored if DA seems to be working otherwise.
If you have any suggestions let me know.
Thanks,
Richard Hicks
/ June 9, 2014It is entirely possible that your application is making a call directly to a resource via its IP address and not its hostname. You’ll probably have to profile the application by watching network traces taken while on the internal network and compare that to traces taken from the client when it is outside of the network. Most often that’s the source of trouble for applications that fail to work properly over a DirectAccess connection.
Lemuel Gulliver
/ June 3, 2014See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.AggregateException: One or more errors occurred. —> System.ApplicationException: An Exception occurred in the work horse thread.
at MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.WorkHorse(CancellationToken token)
at MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.b__0()
at System.Threading.Tasks.Task.Execute()
— End of inner exception stack trace —
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.CancelButton_Click(Object sender, EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
—> (Inner Exception #0) System.ApplicationException: An Exception occurred in the work horse thread.
at MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.WorkHorse(CancellationToken token)
at MicrosoftServices.WS2012DA.ClientTroubleshooter.MainForm.b__0()
at System.Threading.Tasks.Task.Execute()<—
************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
—————————————-
DAClientTroubleshooter
Assembly Version: 1.4.4.39291
Win32 Version: 1.4.4.0
CodeBase: file:///C:/Users/Administrator/Desktop/DirectAccessClientTroubleshooter/DAClientTroubleshooter.exe
—————————————-
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
—————————————-
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
—————————————-
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
—————————————-
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
—————————————-
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
—————————————-
System.Management
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18408 built by: FX451RTMGREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Management/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Management.dll
—————————————-
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
Lemuel Gulliver
/ June 3, 2014:)) crap my text is gone,.. anyway maybe somebody will paste here some learning books to solve it
SImon
/ June 4, 2014Hi RIchard, I got my DirectAccess up and running, I have since added 2 more entry points around the world and have been testing quite successfully with a handful of Windows 8 and 8.1 clients.
I am now looking to roll out Windows 8.1 via WDS and at the same time, give DirectAccess to all the mobile clients. It is these new machines that are failing. At first I thought it was a problem with the IntelProSet wireless software in my Windows 8.1 build so I created a brand new image and deployed to 2 computers for testing. They refuse to connect. In the troubleshooting tool, they pass everything up to the 2 tunnel tests.
All of the other machines are working, so I am stumped as to why computers based on my new image are failing. Is there a windows update that is causing problems for 8.1 Enterprise Clients?
Simon
/ June 4, 2014An update;
I ran netsh int https show int on an affected computer and got the error code 0x0 iphttps interface active,
The troubleshooting tool fails the Infrastructure test, so I thought the IPHTTPS wasn’t working.
So I think it might be the computer certificate that is installed on the clients.
They are creating the certificate from GP, I followed your guide on that, and it was working for other computers.
The strange thing it that on the server, I don’t see any incoming connections. I will check the user tunnel tests
Simon
/ June 5, 2014Further troubleshooting seems to have found a solution. My testing shows that only newly deployed Windows 8.1 machines are affected.
The logs are identical, the IPHTTPS tunnel throws no errors and reports being connected, but no infrastucture servers are reachable. The only difference is that the IPSEC quick and main mode tunnels were not connecting.
I found that running in an admin level command prompt the following 2 commands fixes DirectAccess. Several reboots later and it is still working.
sc config ikeext start= auto
net start ikeext
Richard Hicks
/ June 9, 2014Glad you were able to resolve that. Thanks for sharing the resolution steps!
D_A-
/ July 22, 2014We have an interesting situation with DA 2012 in our company. Our DA works perfectly, but we cannot access one spesific file server share (non-domain file server, 2008 R2 server).
Clients can ping the server, and we can access the server via http, but for some reason we cannot connect the file share? We have tried to connect the share with every possible way, but just cannot connect…. most interesting is that DA-server can connect this spesific shared folder just fine, but client’s cannot.
Have you seen any situations like this?
Richard Hicks
/ July 25, 2014That’s unusual. Perhaps it is an authentication issue? I’d suggest taking a network trace from the file server side to see what it looks like.
Jason
/ August 8, 2016We’re currently seeing a similar issue. Its affecting all File Shares for 1 remote client. Ping, HTTP etc all work, but file shares just wont connect (and thus no group policy updates too).
Found this – https://engineeringit.wordpress.com/2014/07/28/directaccess-unable-to-access-fileshares/ – & giving it a shot… Its a little risky though given our user is located about 12 hours from the nearest office.
Richard M. Hicks
/ August 9, 2016Good luck. Be sure to let me know what the outcome is. 🙂
Jason
/ August 9, 2016It worked a charm.
I had connected remotely (via SCCM Remote running on the DA Server itself, since we’re not setup for Multi-Site Manage Out yet), did a “shutdown -r -t 60”, uninstalled the IPHTTPSInterface from device manager (at which point the remote control was lost obviously) and crossed my fingers… After about 10 minutes the machine had rebooted & initiated a new DA connection. I took control again & confirmed File Shares worked.
Richard M. Hicks
/ August 11, 2016Great to hear! 🙂
Geoff
/ September 25, 2014Trying to figure out the Win7 side, we have DA working between our 2012 R2 DA server and 8.1 clients, but Win7 is showing the following. Not sure why the DNS portion is failing, hoping you may have some insight. Thank you in advance:
[9/25/2014 2:24:50 PM]: In worker thread, going to start the tests.
[9/25/2014 2:24:50 PM]: Running Network Interfaces tests.
[9/25/2014 2:24:50 PM]: Local Area Connection (Intel(R) PRO/1000 MT Network Connection): fe80::183f:69dd:8ff8:a607%11;: 204.179.192.43/255.255.255.240;
[9/25/2014 2:24:50 PM]: Default gateway found for Local Area Connection.
[9/25/2014 2:24:50 PM]: isatap.{5B4C0CEE-8016-4CC8-A6BF-1732E66DDB12} (Microsoft ISATAP Adapter): fe80::200:5efe:204.179.192.43%13;
[9/25/2014 2:24:50 PM]: No default gateway found for isatap.{5B4C0CEE-8016-4CC8-A6BF-1732E66DDB12}.
[9/25/2014 2:24:50 PM]: iphttpsinterface (iphttpsinterface): fdf1:6d08:e313:1000:15a1:9457:b994:f055;: fdf1:6d08:e313:1000:41e6:8ef8:8ccb:4b37;: fe80::15a1:9457:b994:f055%14;
[9/25/2014 2:24:50 PM]: No default gateway found for iphttpsinterface.
[9/25/2014 2:24:50 PM]: Local Area Connection has configured the default gateway xxx.xxx.xxx.xxx.
[9/25/2014 2:25:02 PM]: Warning – default gateway xxx.xxx.xxx.xxx for Local Area Connection does not reply on ICMP Echo requests, the request or response is maybe filtered?
[9/25/2014 2:25:02 PM]: Received a response from the public DNS server (8.8.8.8), RTT is 23 msec.
[9/25/2014 2:25:02 PM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[9/25/2014 2:25:02 PM]: Running Inside/Outside location tests.
[9/25/2014 2:25:02 PM]: NLS is https://DirectAccess-NLS.company.com:62000/insideoutside.
[9/25/2014 2:25:02 PM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[9/25/2014 2:25:02 PM]: NRPT contains 3 rules.
[9/25/2014 2:25:02 PM]: Found (unique) DNS server: fdf1:6d08:e313:3333::1
[9/25/2014 2:25:02 PM]: Send an ICMP message to check if the server is reachable.
[9/25/2014 2:25:14 PM]: DNS Server fdf1:6d08:e313:3333::1 does not reply on ICMP Echo requests.
[9/25/2014 2:25:14 PM]: Running IP connectivity tests.
[9/25/2014 2:25:14 PM]: The 6to4 interface is disabled.
[9/25/2014 2:25:14 PM]: Teredo inferface status is offline.
[9/25/2014 2:25:14 PM]: The configured Teredo server is the public Microsoft Teredo server teredo.ipv6.microsoft.com..
[9/25/2014 2:25:14 PM]: The IPHTTPS interface is operational.
[9/25/2014 2:25:14 PM]: The IPHTTPS interface status is IPHTTPS interface active.
[9/25/2014 2:25:14 PM]: IPHTTPS is used as IPv6 transition technology.
[9/25/2014 2:25:14 PM]: The configured IPHTTPS URL is https://da.company.com:443.
[9/25/2014 2:25:14 PM]: IPHTTPS has a single site configuration.
[9/25/2014 2:25:14 PM]: IPHTTPS URL endpoint is: https://da.company.com:443.
[9/25/2014 2:25:14 PM]: Successfully connected to endpoint https://da.company.com:443.
[9/25/2014 2:25:14 PM]: No response received from company.com.
[9/25/2014 2:25:14 PM]: Running Windows Firewall tests.
[9/25/2014 2:25:14 PM]: The current profile of the Windows Firewall is Public.
[9/25/2014 2:25:14 PM]: The Windows Firewall is enabled in the current profile Public.
[9/25/2014 2:25:14 PM]: The outbound Windows Firewall rule Core Networking – Teredo (UDP-Out) is enabled.
[9/25/2014 2:25:14 PM]: The outbound Windows Firewall rule Core Networking – IPHTTPS (TCP-Out) is enabled.
[9/25/2014 2:25:14 PM]: Running certificate tests.
[9/25/2014 2:25:14 PM]: Found 1 machine certificates on this client computer.
[9/25/2014 2:25:14 PM]: Checking certificate CN=DA-CLIENT7.company.com with the serial number [XXXXXXXXXXXXXXXXXXXX].
[9/25/2014 2:25:14 PM]: The certificate [XXXXXXXXXXXXXXXXXXXX] contains the EKU Client Authentication.
[9/25/2014 2:25:17 PM]: The trust chain for the certificate [XXXXXXXXXXXXXXXXXXXX] was sucessfully verified.
[9/25/2014 2:25:17 PM]: Running IPsec infrastructure tunnel tests.
[9/25/2014 2:25:17 PM]: Failed to connect to domain sysvol share \\company.com\sysvol\company.com\Policies.
[9/25/2014 2:25:17 PM]: Running IPsec intranet tunnel tests.
[9/25/2014 2:25:28 PM]: Failed to connect to fdf1:6d08:e313:1000::1 with status TimedOut.
[9/25/2014 2:25:40 PM]: Failed to connect to fdf1:6d08:e313:1000::2 with status TimedOut.
[9/25/2014 2:25:40 PM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.company.com.
[9/25/2014 2:25:40 PM]: Running selected post-checks script.
[9/25/2014 2:25:40 PM]: No post-checks script specified or the file does not exist.
[9/25/2014 2:25:40 PM]: Finished running post-checks script.
[9/25/2014 2:25:40 PM]: Finished running all tests.
Geoff
/ September 25, 2014I just wanted to add the ‘netsh namespace show policy’ for our company (.company.com) shows the DA DNS server to match the above IPv6 address (fdf1:6d08:e313:3333::1)
Richard Hicks
/ September 30, 2014I’m assuming you have selected the option to provide support for Windows 7 clients in the remote access management console DirectAccess configuration?
D L
/ April 27, 2015When running this tool the Interface Test consistently reports that multiple default gateways were found. I have confirmed it shows an IPv4 and IPv6 address for the gateway. The DA client seems to be working properly as I am able to access company resources. Since this shows up as a yellow exclamation point I would like to confirm whether it is a concern or if I need to make a change. Your feedback is appreciated.
Richard Hicks
/ April 27, 2015There are a number of issues with this tool, and it is quite likely that your specific configuration isn’t recognized as valid and correct by the utility. If everything is working correctly, I think you can safely ignore the error.
Omid
/ June 26, 2015Dear Richard,
We are so lucky we have you as an expert in DA. I reviewed most of your posts and videos.
I have a problem I got this error from debug:
[6/26/2015 8:13:05 AM]: IPHTTPS has a single site configuration.
[6/26/2015 8:13:05 AM]: IPHTTPS URL endpoint is: https://da.xxxxxxxxxxx:443.
[6/26/2015 8:13:05 AM]: Failed to connect to endpoint https://da.xxxxxxxxxxxx:443.
Would you please help me on this issue?
Regards,
Omid
Richard Hicks
/ June 26, 2015Hi Omid. Thanks for the kind words! As for your issue, it seems pretty self explanatory. The endpoint can’t connect to your public address on TCP port 443. Assuming that DNS is correctly configured and your public name resolves to the correct IP address, the only other thing it can be is a NAT or firewall rule missing or incorrect. If you’ll send me the full public hostname I’d be happy to confirm that for you.
Omid
/ June 26, 2015Hi Richard,
Thank you so much fro quick response. Here is the log(inside network).
Note- I did port forwarding on sonicwall for 443(da.lynxinnovation.com)
[6/26/2015 8:13:05 AM]: In worker thread, going to start the tests.
[6/26/2015 8:13:05 AM]: Running Network Interfaces tests.
[6/26/2015 8:13:05 AM]: Wi-Fi 2 (Broadcom 802.11n Network Adapter): fe80::f4d3:55cc:3924:a8c7%11;: 10.0.10.44/255.255.255.0;
[6/26/2015 8:13:05 AM]: Default gateway found for Wi-Fi 2.
[6/26/2015 8:13:05 AM]: isatap.{DE14690B-46AB-4282-8741-4D090E6AE52D} (Microsoft ISATAP Adapter): fdff:eb85:2cbf:1:0:5efe:10.0.10.44;: fe80::5efe:10.0.10.44%8;
[6/26/2015 8:13:05 AM]: Default gateway found for isatap.{DE14690B-46AB-4282-8741-4D090E6AE52D}.
[6/26/2015 8:13:05 AM]: Wi-Fi 2 has configured the default gateway 10.0.10.1.
[6/26/2015 8:13:05 AM]: Default gateway 10.0.10.1 for Wi-Fi 2 replies on ICMP Echo requests, RTT is 2 msec.
[6/26/2015 8:13:05 AM]: isatap.{DE14690B-46AB-4282-8741-4D090E6AE52D} has configured the default gateway fe80::5efe:10.0.1.18%8.
[6/26/2015 8:13:05 AM]: Default gateway fe80::5efe:10.0.1.18%8 for isatap.{DE14690B-46AB-4282-8741-4D090E6AE52D} replies on ICMP Echo requests, RTT is 3 msec.
[6/26/2015 8:13:05 AM]: Received a response from the public DNS server (8.8.8.8), RTT is 38 msec.
[6/26/2015 8:13:05 AM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[6/26/2015 8:13:05 AM]: Running Inside/Outside location tests.
[6/26/2015 8:13:05 AM]: NLS is https://DirectAccess-NLS.LynxInnovation.com:62000/insideoutside.
[6/26/2015 8:13:05 AM]: NLS is reachable via HTTPS, the client computer is connected to the corporate network (internal).
[6/26/2015 8:13:05 AM]: NRPT contains 3 rules.
[6/26/2015 8:13:05 AM]: Found (unique) DNS server: fdff:eb85:2cbf:3333::1
[6/26/2015 8:13:05 AM]: Send an ICMP message to check if the server is reachable.
[6/26/2015 8:13:05 AM]: DNS server fdff:eb85:2cbf:3333::1 is online, RTT is 1 msec.
[6/26/2015 8:13:05 AM]: Running IP connectivity tests.
[6/26/2015 8:13:05 AM]: The 6to4 interface service state is default.
[6/26/2015 8:13:05 AM]: Teredo inferface status is offline.
[6/26/2015 8:13:05 AM]: The configured DirectAccess Teredo server is win8.ipv6.microsoft.com..
[6/26/2015 8:13:05 AM]: The IPHTTPS interface is operational.
[6/26/2015 8:13:05 AM]: The IPHTTPS interface status is IPHTTPS interface not installed..
[6/26/2015 8:13:05 AM]: Teredo is used as IPv6 transition technology.
[6/26/2015 8:13:05 AM]: The configured IPHTTPS URL is https://da.LynxInnovation.com:443.
[6/26/2015 8:13:05 AM]: IPHTTPS has a single site configuration.
[6/26/2015 8:13:05 AM]: IPHTTPS URL endpoint is: https://da.LynxInnovation.com:443.
[6/26/2015 8:13:05 AM]: Failed to connect to endpoint https://da.LynxInnovation.com:443.
[6/26/2015 8:13:05 AM]: Received response from LynxInnovation.com, RTT is 71 msec.
[6/26/2015 8:13:05 AM]: Running Windows Firewall tests.
[6/26/2015 8:13:05 AM]: Warning – the current profile of the Windows Firewall is Domain.
[6/26/2015 8:13:05 AM]: The Windows Firewall is enabled in the current profile Domain.
[6/26/2015 8:13:05 AM]: The outbound Windows Firewall rule Core Networking – Teredo (UDP-Out) is enabled.
[6/26/2015 8:13:05 AM]: The outbound Windows Firewall rule Core Networking – IPHTTPS (TCP-Out) is enabled.
[6/26/2015 8:13:05 AM]: Running certificate tests.
[6/26/2015 8:13:05 AM]: No usable machine certificate found.
[6/26/2015 8:13:05 AM]: Found 0 machine certificates on this client computer.
[6/26/2015 8:13:05 AM]: Running IPsec infrastructure tunnel tests.
[6/26/2015 8:13:09 AM]: Successfully connected to domain sysvol share, found 36 policies.
[6/26/2015 8:13:09 AM]: Running IPsec intranet tunnel tests.
[6/26/2015 8:13:09 AM]: Successfully reached fdff:eb85:2cbf:1000::1, RTT is 27 msec.
[6/26/2015 8:13:09 AM]: Successfully reached fdff:eb85:2cbf:1000::2, RTT is 2 msec.
[6/26/2015 8:13:09 AM]: Successfully reached HTTP probe at http://directaccess-WebProbeHost.LynxInnovation.com.
[6/26/2015 8:13:09 AM]: Running selected post-checks script.
[6/26/2015 8:13:09 AM]: No post-checks script specified or the file does not exist.
[6/26/2015 8:13:09 AM]: Finished running post-checks script.
[6/26/2015 8:13:09 AM]: Finished running all tests.
Regards,
Omid
Richard Hicks
/ June 27, 2015As I suspected, the public address is not reachable on TCP port 443. It resolves to 98.189.221.229, so if that is correct I would take a close look at your edge firewall configuration. I have to assume there’s an issue with its configuration that isn’t allowing this traffic.
Alex
/ November 22, 2016Hi Richard,
We are having the same issue – DirectAccess works, but the Client Troubleshooting Tool brings up the same error. In our case, if I browse for our Webserver on Port 443 with Internet Explorer, the Website of IIS will be shown – that means for me that it should actually work. The website shows in IE with DirectAccess connected and without. Do you have any idea why I get this error?
Thanks, Alex
Richard M. Hicks
/ November 28, 2016The DCA tool is not always entirely accruate. 😉 It is indeed possible that the tool will report a problem where there actually isn’t one. If DirectAccess is working for you, you can probably disregard any errors it returns. 🙂
Marry
/ July 26, 2015Hi Richard, how DA client will react in a network with disabled ICMP? Do you have any observations?
Cheers,
Marry
Richard Hicks
/ July 29, 2015You won’t be able to use the Teredo IPv6 transition protocol for sure. Other than that I’m not aware of any other limitations.
Pavel
/ December 17, 2015Hi Richard!
Thank you for yout blog, its very usefull.
But i can’t find answer on my problem.
All DA clients(Win 10) stopped receiving ipv6 prefix via ip-https connection from DA server.
Tunnel adapter iphttpsinterface:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::b522:5e57:3a80:f63e%18
Default Gateway . . . . . . . . . :
Client:
Interface IPHTTPSInterface (Group Policy) Parameters
————————————————————
Role : client
URL : https://da.domainname.ru:443/IPHTTPS
Last Error Code : 0x0
Interface Status : IPHTTPS interface active
Server:
Interface IPHTTPSInterface Parameters
————————————————————
Role : server
URL : https://daakros-llc.lancloud.ru:443/IPHTTPS
Client authentication mode : none
Last Error Code : 0x0
Interface Status : IPHTTPS interface active
Do you ever met something like this in your practice?
Thanks.
Richard M. Hicks
/ December 18, 2015Can’t say I’ve ever encountered that issue. Typically once the IP-HTTPS tunnel is established, the IPv6 address configuration works without issue. However, if it is not working, I would suspect it might be related to IPv6 being disabled, or perhaps the firewall on either the server or the client is not allowing all required IPv6 protocols. Look closely there.
Pavel
/ December 20, 2015netsh interface ipv6 reset and netsh winsock reset
resolve this, now I am looking for the cause of this problem.
Richard, сould you advise some materials about, how DA clients regitering they AAAA records in DNS?
I make records manualy for manage-out DA сlients, because they do not do this automatically. It’s very unconfortable.
Thank you!
Richard M. Hicks
/ December 22, 2015Hi Pavel,
Clients register their IPV6 AAAA records in DNS the same way they do for IPv4. No difference. If they aren’t registering successfully, I’d suggest checking the event logs for clues as to why they are failing.
Pavel
/ December 22, 2015Oh, i found answer in your blog.
Our administrator use internal corporate DNS server in configuration. I change it on DA server ip and now clients registering successfully.
Thanks for your blog Richard!
Jan
/ January 26, 2016Any update on the localization bug? Cant produce ENG DA logs with DAC on localized workstations and this tool stilll doesnt work as well.
Richard M. Hicks
/ January 26, 2016Not to my knowledge, and I don’t expect anything soon either. :/
DonLapeno
/ March 5, 2016Hello Richard,
Came across your post as i am having some issues with an existing DA deployment that I believe i broke, perhaps you can give some insight towards my issue?
I had to update a AV management console that was not working, just so happened to also be the same server hosting DA which i did not know.
The AV console was binding to ipv6 address (network is all ipv4) so i unchecked IPv6 from the main NIC..
Suprise, it seemed to have broken DA as now systems will not connect. Running this tool and reviewing the trace logs i see most things work but some don’t, if you can review this and provide any feed back it would be awesome. Nothing else in this confioguration changed, no DNS records, no internal LAN IP’s, all the system is pushed out via GPO configs for both server and client which also have not changed..
The only thing done was IPv6 option removed from the NIC…This is the results from Client side.
The company has a .local internal domain and a .com for external, with external .com DNS set on the internal AD/DC for office users.
Debug Log:
=====================================================================
[3/5/2016 5:04:33 PM]: In worker thread, going to start the tests.
[3/5/2016 5:04:33 PM]: Running Network Interfaces tests.
[3/5/2016 5:04:33 PM]: Ethernet0 (Intel(R) 82574L Gigabit Network Connection): fe80::98e1:9d5a:3e38:3bcb%3;: 10.19.79.80/255.255.255.0;
[3/5/2016 5:04:33 PM]: Default gateway found for Ethernet0.
[3/5/2016 5:04:33 PM]: Teredo Tunneling Pseudo-Interface (Teredo Tunneling Pseudo-Interface): 2001:0:5ef5:79fd:1454:1521:b9b6:c72b;: fe80::1454:1521:b9b6:c72b%5;
[3/5/2016 5:04:33 PM]: No default gateway found for Teredo Tunneling Pseudo-Interface.
[3/5/2016 5:04:33 PM]: iphttpsinterface (iphttpsinterface): fd84:d8b7:1606:1000:6928:a0a1:f970:8d74;: fd84:d8b7:1606:1000:84c7:14ce:3a79:5076;: fe80::6928:a0a1:f970:8d74%8;
[3/5/2016 5:04:33 PM]: No default gateway found for iphttpsinterface.
[3/5/2016 5:04:33 PM]: Ethernet0 has configured the default gateway 10.19.79.1.
[3/5/2016 5:04:33 PM]: Default gateway 10.19.79.1 for Ethernet0 replies on ICMP Echo requests, RTT is 0 msec.
[3/5/2016 5:04:33 PM]: Received a response from the public DNS server (8.8.8.8), RTT is 32 msec.
[3/5/2016 5:04:33 PM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[3/5/2016 5:04:33 PM]: Running Inside/Outside location tests.
[3/5/2016 5:04:33 PM]: NLS is https://DirectAccess-NLS.myIntDomain.local:62000/insideoutside.
[3/5/2016 5:04:33 PM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[3/5/2016 5:04:33 PM]: NRPT contains 2 rules.
[3/5/2016 5:04:33 PM]: Found (unique) DNS server: fd84:d8b7:1606:3333::1
[3/5/2016 5:04:33 PM]: Send an ICMP message to check if the server is reachable.
[3/5/2016 5:04:45 PM]: DNS Server fd84:d8b7:1606:3333::1 does not reply on ICMP Echo requests.
[3/5/2016 5:04:45 PM]: Running IP connectivity tests.
[3/5/2016 5:04:45 PM]: The 6to4 interface service state is default.
[3/5/2016 5:04:45 PM]: Teredo inferface status is online.
[3/5/2016 5:04:45 PM]: The configured DirectAccess Teredo server is win8.ipv6.microsoft.com..
[3/5/2016 5:04:45 PM]: The IPHTTPS interface is operational.
[3/5/2016 5:04:45 PM]: The IPHTTPS interface status is IPHTTPS interface active.
[3/5/2016 5:04:45 PM]: IPHTTPS is used as IPv6 transition technology.
[3/5/2016 5:04:45 PM]: The configured IPHTTPS URL is https://remote.myIntDomainp.com:443.
[3/5/2016 5:04:45 PM]: IPHTTPS has a single site configuration.
[3/5/2016 5:04:45 PM]: IPHTTPS URL endpoint is: https://remote.myIntDomainp.com:443.
[3/5/2016 5:04:45 PM]: Successfully connected to endpoint https://remote.myIntDomainp.com:443.
[3/5/2016 5:04:45 PM]: No response received from myIntDomain.local.
[3/5/2016 5:04:45 PM]: Running Windows Firewall tests.
[3/5/2016 5:04:45 PM]: The current profile of the Windows Firewall is Public.
[3/5/2016 5:04:45 PM]: The Windows Firewall is enabled in the current profile Public.
[3/5/2016 5:04:45 PM]: The outbound Windows Firewall rule Core Networking – Teredo (UDP-Out) is enabled.
[3/5/2016 5:04:45 PM]: The outbound Windows Firewall rule Core Networking – IPHTTPS (TCP-Out) is enabled.
[3/5/2016 5:04:45 PM]: Running certificate tests.
[3/5/2016 5:04:45 PM]: No usable machine certificate found.
[3/5/2016 5:04:45 PM]: Found 0 machine certificates on this client computer.
[3/5/2016 5:04:45 PM]: Running IPsec infrastructure tunnel tests.
[3/5/2016 5:04:45 PM]: Failed to connect to domain sysvol share \\myIntDomain.local\sysvol\myIntDomain.local\Policies.
[3/5/2016 5:04:45 PM]: Running IPsec intranet tunnel tests.
[3/5/2016 5:04:46 PM]: Successfully reached fd84:d8b7:1606:1000::1, RTT is 96 msec.
[3/5/2016 5:04:46 PM]: Successfully reached fd84:d8b7:1606:1000::2, RTT is 46 msec.
[3/5/2016 5:04:46 PM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.myIntDomain.local.
[3/5/2016 5:04:46 PM]: Running selected post-checks script.
[3/5/2016 5:04:46 PM]: No post-checks script specified or the file does not exist.
[3/5/2016 5:04:46 PM]: Finished running post-checks script.
[3/5/2016 5:04:46 PM]: Finished running all tests.
=====================================================================
Richard M. Hicks
/ March 8, 2016IPv6 must be enabled on the DirectAccess server and on all DirectAccess clients. DirectAccess will not function without it.
liew
/ July 3, 2017Hi, is IPv6 needed for intranet servers after DirectAccess connection is established? My IPv6 is enabled for DA server and DA clients now.
Richard M. Hicks
/ July 10, 2017No, IPv6 is not required on the intranet for DirectAccess clients to access them. The DirectAccess server translates all client IPv6 traffic to IPv4, so there’s no need to have IPv6 deployed on the internal network at all.
Matthew
/ March 8, 2016Any thoughts for this?
My test machine
“Successfully connected to endpoint https://remote.mydomain.com:443.
No response received from mydomain.local?
Not knowing a server was hosting the DA role, i disabled the Ipv6 option on the NIC because ESET Management console for AV kept binding to it, i was then informed people could not connect to network resources. I re-enabled Ipv6 but DA has not come back up…..
Richard M. Hicks
/ March 8, 2016IPv6 must be enabled on the DirectAccess server and all DirectAccess clients for it to work. Often third-party AV solutions interfere with DirectAccess, so if that’s the case you’ll have to contact the vendor for interoperability guidance. If at all possible, installing any third-party software on the DirectAccess server should be avoided.
Matthew B
/ March 8, 2016Thank you for the reply, i removed the AV and had enabled the Ipv6 again, all clients do have IPv6 enabled, but still a no go. It does say it can not find a client computer certificate, but from the configuration, it doesnt look like this was ever set up for this system.
I did create this post on spiceworks..
https://community.spiceworks.com/topic/1485483-microsoft-direct-access-not-being-so-direct
Richard M. Hicks
/ March 11, 2016Client certificates aren’t required in all scenarios, but the troubleshooting tool still checks for it so it can report a false positive. I would need a lot more information to continue troubleshooting. If you reach out to me directly I’ll be happy to assist.
Matthew B
/ March 16, 2016I really appreciate that Richard, what is the best way to contact you?
Richard M. Hicks
/ March 18, 2016Email. 😉 You can find my email address on the “About Me” page on this web site.
JohnR
/ June 24, 2016One of the better resources on DA. Thank You!
We have DA functioning but the Client Troubleshooting Tool is throwing a warning on DNS Server fdd0…. does not reply on ICMP Echo Request. Can you give any hints where I may look. We are using IP-Https with 2xnics in the DA Server and a stand alone NLS server. We can access resources but cannot ping our DA server from the client?
Thanks
Richard M. Hicks
/ June 30, 2016I can only assume that ICMP is not allowed on the DirectAccess server’s firewall…
ramesh Sakthivel
/ August 26, 2016Hi Rickard,
First of all, I would like to Thank you for giving your great support.
One of my DA clients is facing an intermittent connectivity issue over DA while working from home network. However, other clients were stay connected for long hours without any issue.
Also, I could see that specific client connection was dropping and gaining connection in DA console.
Would you please help me to overcome this issue.
Regards,
Ramesh
Richard M. Hicks
/ August 26, 2016I don’t know if there’s much I can do for you here. The only thing I can suggest is that you take a network trace on the client and see who is terminating the connection. In these cases it is commonly an intermediary device like a router or firewall that is forcibly closing connections after a period of time. Watch closely for that.
calaggan
/ August 29, 2016Hi and many thx for Blog,
in my society i’v deployed Direct access, all work fine. but in three week i replace the root CA by another CA. (microsoft work on this project not me)
But the client computer must be connected on local network for receive a new computer client certificate, it is possible to force generated computer client certifcate when a user is connected ?
Thx
Richard M. Hicks
/ September 3, 2016You can always perform the enrollment of certificates manually, but it is best to use automatic enrollment to ensure that they are automatically provisioned and, importantly, that they don’t expire. Details here: https://directaccess.richardhicks.com/2013/08/08/directaccess-computer-certificate-auto-enrollment/.
Dav
/ September 23, 2016Hi Richard, thank you for the blog. Our users have been using Direct Access for the past 2 years, but we seems to be getting a report of users have issues with their connection disconnecting intermittently. We are trying to diagnose any trends but receive the following when running the DA Tool – “DAClientToubleshooter encountered and error while processing and needs to close” “A log file was created”. OS: Windows 7 Enterprise SP1. We are trying to check if issues are with the ISP/Router being used by users or an issue with our DA setup. Would appreciate any support. Thanks
Richard M. Hicks
/ September 24, 2016Sorry you are having trouble with the DirectAccess client troubleshooting tool. If you are trying to run the tool on a localized version of Windows, it will fail. This is a known issue. You’ll have to run it on a client configured to use U.S. English, unfortunately. As for intermittent connectivity issues, those are always difficult to troubleshoot. I’d suggest taking network traces on the DirectAccess server and client at the same time. If/when the connection drops, hopefully a review of the network trace will provide some clues for you to locate the source of the problem.
Craig Ward
/ October 30, 2016Hi Richard, My clients can connect and use DA successfully but when I run the DA troubleshooting tool some of the user tunnel tests fail. It’s always the IPv6 addresses of the IPHTTPS interface of the other multi site server. ie the client cant succesfully each 2 x of the 4 IPv6 addresses that are configured. If I disconnect and connect to the other site it’s the opposite IPs that fail. Is this by design and is it really an issue? Thanks heaps, Craig.
Richard M. Hicks
/ November 2, 2016Expected and by design. The tool is pretty rudimentary and doesn’t take in to account that you can’t ping the DTE IPv6 addresses of an endpoint you aren’t connected to. You can safely disregard those error messages.
Dietmar
/ December 27, 2017This tool still not works on german clients.
Richard M. Hicks
/ December 27, 2017Not surprised. This is an unsupported tool from Microsoft and I’m certain they have no plans to fix it now that they are moving to Always On VPN. Sorry about that!