Native PowerShell commands in Windows 10 make DirectAccess troubleshooting much easier than older operating systems like Windows 7. For example, with one PowerShell command an administrator can quickly determine if a DirectAccess client has received the DirectAccess client settings policy. In addition, PowerShell can be used to view the status of the connection and retrieve additional information or error codes that can be helpful for determining the cause of a failed connection. Further, PowerShell can also be used to review configuration details and perform other troubleshooting and connectivity validation tasks.
Here are my top 5 PowerShell commands for troubleshooting DirectAccess on Windows 10.
1. Get-DAClientExperienceConfiguration
Ensuring that the DirectAccess Client Settings group policy has been applied to the client is one of the first steps in troubleshooting failed DirectAccess connections. While it is possible to use gpresult to do this, using the Get-DAClientExperienceConfiguration PowerShell command is much simpler. If DirectAccess client settings have been applied, the output of the command will include information such as the IPsec tunnel endpoint IPv6 addresses and the Network Connectivity Assistant (NCA) corporate resource URL. If DirectAccess client settings have not been applied, this information will be missing.
Figure 1. DirectAccess Client Settings group policy successfully applied.
Figure 2. DirectAccess Client Settings group policy not applied.
2. Get-NetIPHttpsState
Performance improvements first introduced in Windows 8 have made IP-HTTPS the IPv6 transition technology of choice when it comes to supporting DirectAccess client connectivity. Also, if the DirectAccess server is located behind an edge device performing Network Address Translation (NAT), IP-HTTPS is the only supported transition technology. Using the Get-NetIPHttpsState PowerShell command, the DirectAccess administrator can quickly determine if the IP-HTTPS connection was successful. If it was not, the command will return an error code and interface status that will indicate why the IP-HTTPS connection was unsuccessful.
Figure 3. Get-NetIPHttpsState
3. Get-NetIPHttpsConfiguration
When troubleshooting IP-HTTPS connection failures, it is necessary to obtain additional information to continue the troubleshooting process. Using the Get-NetIPHttpsConfiguration PowerShell command, the DirectAccess administrator can obtain the public hostname for the DirectAccess server and ensure that the name resolves to the correct IP address in DNS and that it is reachable on TCP port 443.
Figure 4. Get-NetIPHttpsConfiguration
4. Resolve-DnsName
Using the Resolve-DnsName PowerShell command is crucial when performing any name resolution tasks on the DirectAccess client. This is because Resolve-DnsName is aware of the Name Resolution Policy Table (NRPT) and will direct name resolution requests accordingly. Tools like nslookup are DNS server testing tools and are unaware of the NRPT. Typically they do not yield expected results when testing name resolution on a DirectAccess client.
Figure 5. Name resolution results from Resolve-DnsName and nslookup.
5. Get-DnsClientNrptPolicy
Often the cause of DirectAccess client connectivity issues is a misconfigured NRPT. Using the Get-DnsClientNrptPolicy PowerShell command the DirectAccess administrator can validate that name resolution requests for host names in any internal namespaces are being sent to the DirectAccess DNS64 IPv6 address.
Figure 6. Get-DnsClientNrptPolicy
Additional Resources
Top 5 DirectAccess Troubleshooting Tips
Troubleshooting Name Resolution Issues on DirectAccess Clients
Learn PowerShell in a Month of Lunches Book by Don Jones and Jeff Hicks
Implementing DirectAccess with Windows Server 2016 Book
Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course
Managing and Supporting DirectAccess with Windows Server 2016 Video Training Course
Solo
/ November 8, 2019What do you think about this case?
You have a DirectAccess server that is accessible by using the name directaccess.abc.com. On the DirectAccess server you install a new server certificate that has the same subject name. You then configure the DNS records for directaccess.abc.com. What cmdlet should you run if you need to change the endpoint name for DirectAccess to directaccess.abc.com?
A. Set-DaServer -ConnectToAddress directaccess.abc.com
B. Set-DaEntryPoint -EntrypointName directaccess.abc.com
C. Set-DaEntryPoint -ComputerName directaccess.abc.com
D. Set-DaClient -ComputerName directaccess.abc.com
Richard M. Hicks
/ November 10, 2019Set-DaServer -ConnectToAddress would be the correct PowerShell command. If there’s an SSL certificate in the certificate store that matches the FQDN it will be used. If not, you’ll be prompted to create a self-signed certificate. If you are, don’t choose that option! Using a public TLS certificate is recommended.
Tyler
/ October 20, 2023You would not recommend using a self-signed certificate for the connect to? Can we have two domains in Direct Access, one will strictly be for the Connect To public site name?
Richard M. Hicks
/ October 22, 2023No. You should try to use public certificates for public-facing services as much as possible for many reasons. It’s easy enough, and cheap enough (some are free!) and it will make your life much easier, trust me. 😉 And yes, you can use a separate domain for the ConnectTo address. It just needs to resolve to the public IP address of the DirectAccess server and match the subject name on the certificate, that’s all.
Solo
/ November 13, 2019Thank you for your replay 🙂 I think so too.
Richard M. Hicks
/ November 13, 2019👍
najki
/ September 1, 2020Hello,
I need to check if clients are connecting via DA. Is the command Get-DAClientExperienceConfiguration and looking on tunnel info etc. telling me that device is connecting via DA? My point is if that can be only enabled and configured but device will be using some “local” network and not connect via DA?
Thank you in advance for any advice
Jiri
Richard M. Hicks
/ September 1, 2020You’ll need to use the PowerShell command Get-DaConnectionStatus to see DirectAccess connectivity status from the command line.
Fraser
/ November 16, 2020Hi Richard,
Not sure if you remember, but some time ago I reached out to you about a specific strange issue. The issue being that clients trying to connect with DA would fail to do so with one specific ISP (Virgin Media for those in the UK that might be reading this at a later date).
Until Friday, I was totally fine using DA at home with Virgin Media (VM) then all of a sudden it stopped. What seems to work for some is connecting a different router to the one provided by VM, and the VM one being put into Modem mode.
This unfortunately does not work for me. Do you have any good resources on how to make use of the DirectAccess logs as well as the DA Client Troubleshooter tool.
We are using IP-HTTPS for DA. If I look at the status of DA on my laptop I can see its in a permanent state of Connecting.
If I try and resolve the dns name it only comes back with the A record and not the AAAA one. I can’t ping google when it does not work, I can’t tracert to the DNS when it is not working. If I run netsh int httpstunnel show int then it shows last error code as 0x0 and IPHTTPS interface deactivated. I’ve checked teredo and that is not enabled.
Any advice on what we can check would be hugely welcome. We’re pretty sure at this stage it’s an issue with the ISP but we can’t account for the fact the majority of people with VM don’t have this problem. We also don’t know why this is not an issue on another domain we have which is for Education and is not as strict in terms of security compliance.
Richard M. Hicks
/ November 17, 2020If you don’t have an IP-HTTPS interface, I would suspect that perhaps VM is somehow interfering with SSL/TLS traffic on your connection. Are they inspecting TLS? Is there some software on your client that is doing this? IP-HTTPS usually works everywhere so I’m surprised to hear it isn’t working for you.