Top 5 DirectAccess Troubleshooting PowerShell Commands

Top 5 DirectAccess Troubleshooting PowerShell CommandsNative 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.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 1. DirectAccess Client Settings group policy successfully applied.

Top 5 DirectAccess Troubleshooting PowerShell Commands

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.

Top 5 DirectAccess Troubleshooting PowerShell Commands

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.

Top 5 DirectAccess Troubleshooting PowerShell Commands

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.

Top 5 DirectAccess Troubleshooting PowerShell Commands

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.

Top 5 DirectAccess Troubleshooting PowerShell Commands

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

 

 

Leave a comment

10 Comments

  1. Solo

     /  November 8, 2019

    What 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

    Reply
    • Set-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.

      Reply
  2. Solo

     /  November 13, 2019

    Thank you for your replay 🙂 I think so too.

    Reply
  3. Hello,
    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

    Reply
  4. Fraser

     /  November 16, 2020

    Hi 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.

    Reply
    • If 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.

      Reply
  1. PowerShell Recommended Reading for DirectAccess and Always On VPN Administrators | Richard M. Hicks Consulting, Inc.
  2. Renew DirectAccess Self-Signed Certificates | Richard M. Hicks Consulting, Inc.

Leave a Reply to najki Cancel reply

%d bloggers like this: