Name resolution and proper DNS server configuration is vital to the functionality of DirectAccess. When performing initial configuration of DirectAccess, or making changes to the DNS server configuration after initial configuration, you may notice the operations status for DNS indicates Critical, and that the operations state shows Server responsiveness.
Highlighting the DNS server on the Operations Status page and viewing the details shows that DNS is not working properly with the following error message:
None of the enterprise DNS servers <IPv6_address> used by DirectAccess clients for name resolution are responding. This might affect DirectAccess client connectivity to corporate resources.
There are a number of things that can contribute to this problem, but a common cause is an error made when assigning a DNS server to a specific DNS suffix. An inexperienced DirectAccess administrator might specify the IPv4 address of an internal corporate DNS server, which is incorrect. The DNS server IPv4 address should be the address assigned to the DirectAccess server’s internal network interface.
The best way to ensure that the DNS server is configured correctly for DirectAccess is to delete the existing entry and then click Detect.
An IPv6 address will be added automatically. This is the IPv6 address of the DNS64 service running on the DirectAccess server, which is how the DNS server should be configured for proper DirectAccess operation.
Once the changes have been saved and applied, the DNS server should once again respond and the status should return to Working.
Kaspars
/ September 22, 2015My DA server shows error where it complains about IPv4 internal DNS server , but in domain suffix DNS configuration I have IPv6 DA server address. This DNS error is from the begining and DA works somehow. I have one NIC behind NAT. I can ping internal DNS servers from DA server. Before deletion I see ipv4 of DA server, detection inserts ipv6 and after hitting apply and properties again I can see the same ipv4 of DA server and in suffix list I see ipv6 address. So deletion do nothing in my case error remains.
Richard M. Hicks
/ October 1, 2015That’s very unusual. This blog post was to bring attention to a specific and common configuration error, that being the specification of internal DNS servers instead of using the DNS64 service on the DirectAccess server. Unfortunately it sounds like there’s something else causing this error on your server.
jamesdelbridge
/ November 7, 2016Hello Kaspars I am having exactly the same issue I believe? Did you ever get this resolved? Thanks
Phil
/ September 23, 2015I’ve had an odd DA DNS issue occur a couple of times, apparently at random (at least – no *known* changes made..!), still haven’t worked out the cause – same error as above but the DNS64 IP is set correctly, nothing informative in the event log.
Of all things, running the DA Best Practice Analyzer in Server Manager was how I found the issue – “The IP Address on the interface where DirectAccess is listening is not correct”
Running:
Set-NetDNSTransitionConfiguration -State Disabled
on each node and then restarting RAMgmtSvc seems to fix it, but I’d love to know what triggered it…
2 node farm using Windows NLB, edge deployment, no NAT – has otherwise worked fine for 2-3 years
Richard M. Hicks
/ October 1, 2015Very odd. I wouldn’t rule out some detection logic in the Remote Access Management console not functioning correctly either.
Matthew B
/ March 8, 2016Thank you for the quick and easy clarification!
Alan
/ June 18, 2016Hi Richard
I wonder if you can help me please with my problem, my setup is behind edge with 2 nics no public IP’s configured both are private. On step 3 of remote Access configuration for some reason it is picking the IPV6 Address of the DA servers and not the Enterprise DNS Server. The Enterprise DNS is a domain controller with ipv6 enabled but no static address assigned in TCP/IP & has no AAAA record in the DNS. This is causing the client to look at wrong DNS server how can i resolve the issue my ipv6 skills are lame else I would have added a record in the dns and tested that way. My problem is similar issue to “Kaspars”, I have reinstalled everything a few times cant understand the issue any help will be really appreciated – Thanks
Richard M. Hicks
/ June 20, 2016I’d suggest manually entering the DNS64 IPv6 address for the DNS server and see if that works. The DNS64 address is the IPv6 address that ends in 3333::1 on your DirectAccess server.
Linton Harris
/ June 29, 2016Hello,
I’m getting a DNS error complaining about “Enterprise DNS servers (8.8.8.8) used by DirectAccess clients for name resolution are not responding. This might affect DirectAccess client connectivity to corporate resources. Please advise
Richard M. Hicks
/ June 30, 2016Sounds like your DNS configuration is incorrect. I’m confident that 8.8.8.8 is not the IP address of one of your internal domain DNS servers. 🙂 Follow the guidance in this post and you should be able to resolve this issue.
Thorsten Frohberg
/ August 2, 2016Hello Richard,
i have 2 directaccess server w2k12r2 behind edge with one nic. after i configure the first server for directaccess all works fine, then i build a cluster for external load balancing. After that on the first da server i have a DNS Error “Server unavailable, server responsivness.” On the second server in the Cluster all works fine. How i can find the logs for DNS, what can i check ?
Richard M. Hicks
/ August 2, 2016That’s odd, for sure. When you configured the DNS servers for the internal namespace, did you follow the guidance here to automatically detect?
Ian Randall
/ October 6, 2016Richard,
Have a 2012 DA Environment setup using an ELB and just added the second node into the cluster, everything has started okay, green ticks across the board except for DNS, which is complaining that none of the enterprise DNS servers can be reached, odd thing is that the one its noted is the 3333::1 address, which I believe is a loopback to the DNS6to4 service on the DA box.
The first node which was created is fine, i can nslookup – and it works fine, i get results back for any site i throw at it, but do that on node 2 and i get request timed out.
Iv checked firewall logs and i see allow for ICMP and DNS (53) inbound and outbound.
I checked the dns settings within step 3 of the setup wizard, and although during the initial setup these did resolve to IPv4 addresses, they do now all read as the correct 3333:1 record, which is the same as on node 1.
Im a little stumped now, any ideas where to look next ??
Richard M. Hicks
/ October 19, 2016The 3333::1 address is expected, as it is the address of the DNS64 service running on the DirectAccess server. Make sure the second node can resolve internal names via its configured DNS servers, which should be your corporate DNS servers. If it fails, ensure that you have connectivity to/from those servers. Things to check are routes, subnet masks, and internal firewalls.
Suresh Gowda
/ February 17, 2017We have DA server successfully its working fine for some time
all clients are able to connect,
Now we are finding DNS status warning error in DA status .when turn of windows firewall all DA status are Green , if firewall is ON, DA DNS status will be error , I have allowed ports . still same error persisit
Richard M. Hicks
/ February 21, 2017That’s certainly unusual, but I have no idea what could be the root cause might be. You might want to try disabling the Remote Access Management console connectivity check to see if that helps. You can do this by selecting Operations Status and then clicking Disable Connectivity Check (PING) in the Monitoring section of the Tasks pane.
Michael M
/ March 27, 2017Richard, your tech bulletins have come in handy in setting up DA server. I however am running into a small issue. My DA server internally can not resolve DNames. Have you come across this? Not sure if that is a DA design or i am truly missing something. All other records are resolvable. Any ideas.
Richard M. Hicks
/ March 28, 2017If the DirectAccess server can’t resolve internal hostnames, obviously you’d have to look the DNS settings on the DirectAccess server itself to ensure that it is using the right DNS servers (should be internal Active Directory domain servers) and that it can reach those servers on the network. After that, make sure the internal DNS servers are configured correctly.
Raymond Tsang
/ March 31, 2017Hi Richard:
The domain I use to detect the DNS server come back with an address that do not validate. But my operation status are all green. The da client troubleshooter I ran on the client have 2 errors:
1. cannot connect to domain sysvol share.
2. cannot connect to http://directaccess-webprobehost.bcclsp.org
How is that relate the DNS6s service. How Can I fix this ?
Richard M. Hicks
/ March 31, 2017If you specify the wrong DNS servers, DirectAccess clients won’t be able to connect but the Remote Access Management console can still show healthy. If you’ve followed the steps outlined in this post and it isn’t working, something is wrong with your configuration. The DNS64 service IPv6 address (typically ending in 3333::1) should always validate.
Raymond Tsang
/ March 31, 2017My da server is a VM. I moved the VM from one hist to another and it lost the domain trust relationship.so I take out the domain and rejoin and the da server breaks. I go through the wizard many time and the same dns domain name it used to validate do not validate anymore.
The da client troubleshooting also said could not find gateway for iphttpsinterface.
Can you point me to the right direction?
Richard M. Hicks
/ April 1, 2017Moving the DirectAccess server is generally not advisable, as there are known issues with this especially if you change IP addresses. I would recommend removing the DirectAccess configuration completely and starting from scratch, but only after you’ve resolved any and all domain authentication and name resolution issues for the server first.
Raymond Tsang-Bellwoods
/ April 3, 2017I am not able to find instructions on cleanly remove direct access configuration. Do you have any link I can go ?
Richard M. Hicks
/ April 13, 2017You’ll find detailed guidance for uninstalling and removing DirectAccess here: https://directaccess.richardhicks.com/2017/04/13/uninstalling-and-removing-directaccess/
Ngoug
/ July 3, 2017Allo Richard,
I have a problem with my environnement which include a direct access server on 2012(not R2).
All are green on configuration statut and the IPv6 retrieve by wizard is fd09:233b:4999:3333::1 and i cannot ping this address from internet.
Conclusion direct access client do not connect to internal ressources
Richard M. Hicks
/ July 10, 2017Often the DNS64 IPv6 address (ending in 3333::1) does not respond to ping because the firewall doesn’t allow it. On the DirectAccess server, ensure that ICMPv6 Echo Request is allowed inbound from all networks on all profiles. If it still fails after that then you likely have a networking issue of some sort.
Paul
/ November 9, 2017Hey Mr Hicks,
I have recently decommissioned an old server, Direct access is still hung up on it. Telling me clients are still using the older server. I cant see where to change this. Any ideas?
Thanks
Paul
/ November 9, 2017Sorry DNS Server to be clear, not sure how to tell DA that it has a new DNS server. Everything elseis fine.
Richard M. Hicks
/ November 9, 2017If you retired the DirectAccess server without first removing the DirectAccess client settings policy from your client machines you’ll have to manually delete the NRPT to restore internal domain connectivity. Run the following command in an elevated PowerShell command window and then restart the client. Hopefully that helps. 🙂
Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Confirm:$false
Paul
/ November 9, 2017Hey Richard,
Sorry my post was rushed and unclear. I have retired a DNS server, I have changed the address on all server nic’s and ensured all machines are using the new DNS server. However the DA server has told me clients are still using the old DNS servers IP. It’s now unreachable. I wonder if it just needs a restart?
We also are also thinking about your consultantly services I would be greatful if perhaps we can chat via mail?
Many Thanks
Paul
Richard M. Hicks
/ November 9, 2017Ok, that’s definitely different. 🙂 If you aren’t using IPv6 on your internal network, all of your clients should be using the DNS64 service running on the DirectAccess server. The DirectAccess server will then use whatever DNS servers are configured on its network interface. Assuming that is correct, everything should work fine. 🙂
Feel free to send me an email. Happy to work with you to get this resolved!
Jorge Mario
/ December 27, 2017Hello Richard,
First of all I’d like to wish you a Happy Christmas and Happy new year entrance.
I’ve a DirectAccess server LAB environment (Windows Server 2012 R2) under VMware and I’ve setup the Windows NLB. I joined the first node to the array and everything was working well so far(DA client connectivity working as well). Then I followed up the guidance regarding VMware and NLB considerations on the DA2016 Book and changed both Internal/External interfaces of node1 to multicast mode. After that I started to experiencing exactly the same error of this post. I followed the provided guidance but unlucky. I understand that VMWare solution is something similar when applying the solution for Hyper-V and NLB(MAC address spoofing), and there would be no reason for this to be failing. So I would like to think the issue ain’t linked to that change. Could you please advise any other workaround I could try in order to get this problem fixed.
Thanks in advance.
Kind regards.
Richard M. Hicks
/ December 27, 2017Getting DirectAccess NLB to work correctly in VMware can be really challenging. If you’ve followed the guidance in the book and also here then it should work. However, I can’t tell you how many times I’ve done this and it still fails! Sometimes I’ve been successful after several tries, other times I’ve had to resort to using a virtual load balancer like the KEMP LoadMaster load balancer. They have a free version that will run in VMware and it often ends up being the easiest way to get things working. 🙂
Jorge Mario
/ January 1, 2018Hi Richard,
Many thanks for your heads up. I followed the Load Balancing DirectAccess with the KEMP Loadmaster Load Balancer guidance and got the issue fixed with the ELB alternative.
Secondly, I started to experiencing the connecting state issue on my client and I worked out with the procedure 4.3.2 Configure an Additional Virtual Service for the DirectAccess Server. Now I have my DA environment operational.
Many thanks for your help and this incredible DirectAccess blog
Kind regards.
Richard M. Hicks
/ January 2, 2018Great to hear! Thanks for the update! 🙂
Liam
/ July 9, 2018Hi Richard,
I have two direct access servers using Multisite.
the NRPT table which been configured by DA automatically contains only 4 records. da1.company.com (cannot be edited), da2.company.com (can be edited) and nls.company.com.
on DA1.company.com operation status im recieving warning (enterprise DNS servers (::1) used by directaccess clients for name resolution are not responding.
I tried to delete and represent (using detect) da2.company.com in the NRPT table but i recieve an error
“exemption entry da1.company.com cannot be modified or deleted in the NRPT”
“exemption entry da2.company.com cannot be modified or deleted in the NRPT”
any ideas?
Richard M. Hicks
/ July 10, 2018Likely an issue with the GPOs themselves. Might be corrupt, or simply not fully replicated. Have a close look at that and see what you can find.
Liam
/ July 10, 2018Hi Richard,
I also suspected that there is problem with GPOs themselves but how can i find out that there is a problem with the GPOs? i checked the GPOs both for the first DA server and the second entry Point and i can open both of them without any problems.
Richard M. Hicks
/ July 13, 2018I’ve encountered scenarios in the past where only some DCs had corrupted GPOs. Look closely at the files in the SYSVOL folder to ensure they are all valid. Other than that, not sure what the problem might be. :/
Bhupesh
/ November 10, 2020Hi Richard,
I configured a DA environment with ipv6 unchecked on the Internal Nic. I now need manually need to enter this in. Any idea where I can obtain the address from? I understand that this is automatically configured with ipv6 is checked before the deployment.
Thanks
Barry
Richard M. Hicks
/ November 10, 2020If you look at the NRPT on a Windows 10 client you’ll see the DNS64 address there. Use Get-DnsClientNrptPolicy and you should find it there.
Justin
/ January 10, 2022I’m not having this specific issue. All in green on my end. The issue I suffer from, time to time, is I’ll find a DirectAccess client hasn’t had its AAAA record updated. I’ll find an old no good IPv6 address in my DNS, delete it, tell the user to reboot and…nothing. No new records added to DNS. To make this even more strange is after a few weeks it’ll sort itself out. But until then the user suffers from random issues. We don’t have a full blown IPv6 setup so I’m using the IPv6 router that sits on the same machine at the DA manager. It’s my understanding that the DA manager/router machine is what’s responsible for registering the DNS records and not the client itself. Anyway to diagnose this? I’m not seeing anything in the logs that show what’s going on. Is there a way to force the DA Manager/router to register a specific client?
Server 2016
All client are 21H2
Thanks for your time and any insight!
Richard M. Hicks
/ January 10, 2022Microsoft made a change in the way Windows clients registered their IP addresses when using the NRPT. You will need to enable a registry setting to restore this functionality. Details here.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/directaccess/directaccess-known-issues#dns-registration-of-directaccess-client-ipv6-addresses
Justin
/ January 10, 2022Many thanks for that! I’ll get it deployed right away.
However this issue of mine goes back to windows 1809 and further. Hopefully this plus a combination of updates since then resolves the issue permanently.
Justin
/ January 12, 2022I was able to delete all clients from DNS and they slowly got added back. So this certainly fixed an issue I was about to have as we just updated to 21H2. Lots of clients must have some how kept their existing IP so it wasn’t noticed yet.
However the issue I mentioned is on going. The one client that’s acting up right now cannot register it’s IP. The only thing I see on the client is Event 8018 claiming it can’t register to server – server: (?)
Eventually in a few weeks this client will sort itself out but not without issues until then. Then flash forward a few months into the future and some other random client will have the same issue for a few weeks.
The one thing I tried was blowing out the NRPT entries at – HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DNSPolicyConfig
But that didn’t help. The client has no issue connecting to any internal systems and once I get the users IP (ipconfig) I am able to access the client for management just fine.
Any ideas on how to debug why the DA client can’t register it’s IP?
Thanks again for the previous info, that would have drove me nuts once it became an issue.
Richard M. Hicks
/ January 12, 2022I don’t have anything solid for you on DirectAccess client IP address registration, unfortunately. Principally it should be no different than troubleshooting IP address registration on-premises. The only difference here is the DirectAccess client doesn’t use DHCP and must register its IPv6 address itself. If that’s not allowed on your DNS servers (sometimes it is not) that could certainly be the problem.
Justin
/ January 13, 2022That’s I would think too. That’s why I started to wonder if the server was doing anything. Well, thanks for that clarification! At least I can stop wandering around and focus on the clients when they eventually do this.
I greatly appreciate your time Richard!
On a side note I think it’s time we dump this and transition to Always On VPN.
Richard M. Hicks
/ January 13, 2022Always On VPN is certainly less complex, which is always a good thing. 🙂