After installing and configuring DirectAccess with Windows Server 2012 R2, several new host records appear automatically in the internal DNS (assuming dynamic DNS is supported, of course). One of them is directaccess-corpConnectivityHost and the other is directaccess-WebProbeHost. These DirectAccess DNS entries are used by Windows 8 and later clients for connectivity checks at various stages of DirectAccess connection establishment.
Figure 1 – DirectAccess DNS records for IPv4-only network.
Figure 2 – DirectAccess DNS records for dual-stack IPv4/IPv6 network.
Here is a detailed description for each of these DirectAccess DNS entries.
directaccess-corpConnectivityHost – This DNS host record includes both A and AAAA records when deployed on IPv4-only networks. Its A host record resolves to 127.0.0.1, which is the IPv4 loopback address. Its AAAA host record resolves to an IPv6 address that is a combination of the DirectAccess NAT64 IPv6 prefix and 7F00:1 (the hexadecimal equivalent of 127.0.0.1). When DirectAccess is configured on a network with native IPv6, the directaccess-corpConnectivityHost DNS record will only include a single AAAA record resolving to ::1.
This host record is used by the DirectAccess client to determine if name resolution for the corporate namespace is working after the IPv6 transition tunnel (6to4, Teredo, or IP-HTTPS) has been established. It does this by attempting to resolve the hostname directaccess-corpConnectivityHost.<corp_fqdn> (e.g. directaccess-corpConnectivityHost.corp.example.net) to an IPv6 address that it expects (the organization’s NAT64 prefix + 7F00:1 or ::1). If it does not resolve, or resolves to a different address, the client will assume that the transition tunnel was not established successfully and, if possible, fall back to another IPv6 transition protocol and repeat the process until it is successful.
Note: The DirectAccess client does not attempt to connect to the IP address resolved by directaccess-corpConnectivityHost. It simply compares the IP address returned by the query to the expected address (NAT64 prefix + 7F00:1 or ::1).
directaccess-WebProbeHost – This DNS host record includes only A records and resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. If load balancing is enabled, this host record will resolve to the virtual IP address (VIP) of the array. For multisite deployments there will be directaccess-WebProbeHost A host records for each entry point in the organization.
This host record is used by the DirectAccess client to verify end-to-end corporate network connectivity over the DirectAccess connection. The client will attempt to connect to the directaccess-WebProbeHost URL using HTTP. If successful, the DirectAccess connectivity status indicator will show Connected.
If any of these DirectAccess DNS records are missing or incorrect, a number of issues may arise. If the directaccess-corpConnectivityHost host record is missing or incorrect, DirectAccess IPv6 transition tunnel establishment may fail. If the directaccess-WebProbeHost record is missing or incorrect, the DirectAccess connectivity status indicator will perpetually show Connecting. This commonly occurs when an external load balancer is used and a virtual server isn’t created for the web probe host port (TCP 80). In addition, these DirectAccess DNS entries are not static and may be deleted if DNS scavenging of stale resource records is enabled on the DNS server.
Stefaan Pouseele
/ July 6, 2015Hi Richard
As far as I know, the requirement that the directaccess-corpConnectivityHost should resolve to the NAT64 prefix + 7F00:1 is only valid in an IPv4-only Intranet environment. In an IPv4+IPv6, or IPv6-only Intranet environment, I think that only a AAAA record should be created with the loopback IP address ::1.
Best Regards,
Stefaan
Richard Hicks
/ July 7, 2015You are absolutely right, Stefaan. Thanks for brining that to my attention! I’ll get this post updated to reflect that soon. 🙂
Dietmar
/ July 7, 2015Hi!
How to repair missing DNS entries? I checked our DirectAccess environment and there is only one directaccess-corpConnectivityHost in DNS. Is it possible to repair the missing entries and set them static?
Thanks,
Dietmar
Richard Hicks
/ July 11, 2015Hi Dietmar,
Yes, you can manually recreate the entries statically to prevent them from being scavenged, if necessary.
Fred
/ August 13, 2015Hi Richard,
I think that IPSEC tunnels must work also to success this DNS check.
Fred
Richard M. Hicks
/ August 18, 2015Yes, you are absolutely correct. 🙂
Fred
/ September 30, 2015I think that’s a bit strange to test the corp connectivity in order to switch ipv6 transition protocole with a check that need IPSEC working…
James
/ August 20, 2015Hi Richard,
We’ve configured several independent DirectAccess deployments within a single domain. Currently 6 DA servers, each with its own configuration, policies, etc. I’ve managed to share NLS, and directAccess-WebProbeHost with no difficulty as you mentioned previously. However I’ve noticed the only DNS record for directaccess-CorpConnectivityHost is 127.0.0.1. Since we have multiple deployments with varying IPv6 prefixes how do we create the AAAA records so the DA clients/Servers don’t get confused if they resolve the wrong name for their IPv6 prefix?
-James
James
/ August 20, 2015Forgot to mention, all these deployments are IPv4 IP-HTTPs configurations.
Richard M. Hicks
/ August 24, 2015I think you should be fine with a single directaccess-CorpConnectivityHost DNS record. The DNS64 service will return a AAAA record with the correct prefix for each deployment, so clients should not be confused.
James
/ August 24, 2015Currently I only have the 127.0.0.1 A record for directaccess-CorpConnectivityHost, how will it return a AAAA record when there isn’t one?
Richard M. Hicks
/ September 1, 2015The DNS64 service will create one. 🙂
Dietmar
/ September 1, 2015Hi! Can you please explain how to get the NAT64 IPv6 prefix? Thanks!
Richard M. Hicks
/ September 1, 2015You can find the NAT64 prefix in the registry on the DirectAccess server at HKLM:\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters\Nat64Prefix. If you’ve configured DirectAccess for multisite you can also find it in the Remote Access management console when you select Configuration/DirectAccess and VPN and highlight the individual entry point.
Craig
/ October 6, 2015Richard,
I’ve currently got a 2012 R2 single site IPv4 setup going with only Win 7 clients. It is configured for 6to4, Teredo and IPHTTPS. I have FOUR AAA directaccess-corpConnectivityHost records. That doesn’t seem correct?
They are:
fdc2:a1c5:de93:7777::7f00:1
fd60:4f94:88fb:7777::7f00:1
fde8:8a2a:5a43:7777::7f00:1
fd7e:3fb3:5637:7777::7f00:1
Richard M. Hicks
/ October 7, 2015That’s unusual. The only thing I can think of is that you have installed and then uninstalled DirectAccess a few times and that these are stale records. Each time you install DirectAccess a new ULA IPv6 prefix is created which would explain the multiple records.
Craig
/ October 7, 2015I’ve only installed DA once. If there are 4 records that’s going to be an issue for any Win8+ clients I assume?
I’ve checked the registry and the NAT64Prefix is fde8:8a2a:5a43:7777::/96 so should I just delete the others?
Richard M. Hicks
/ October 12, 2015It shouldn’t cause a problem, but if you decide to remove those other entries be sure you don’t delete the one that matches your NAT64 prefix. 🙂
Matthew Squires
/ April 18, 2016Hi Richard,
You have some wonderful guides. Thank you for your help thus far. I’d like to know if you have any thoughts on how to get DA clients or VPN clients to register their IP addresses in AD. I’ve followed your guides, and have my DA and VPN on the same host (this is a POC). They are configured behind a NAT device with 2 network adapters. Everything seems to work fine with the exception of DNS registration.
Richard M. Hicks
/ April 23, 2016I’ve never run in to this issue, but fundamentally it works the same via DirectAccess as it does on the LAN. If you use the same problem resolution techniques as you would with a LAN client it should resolve the issue for DirectAccess clients.
Jason Hall
/ May 16, 2016If we’re hosting a website for NLS & NCA on external HA servers; would DirectAccess still be using these WebProbeHost DNS records? Or would they be using the records configured for our NCA & NLS (DirectAccess-NCA.blah & DirectAccess-NLS.blah)?
We’ve recently switched from external load balanced configuration to single servers & having issues with one entry point (we have 2 entry points). I can see the WebProbeHost record still have our old Load Balanced addresses; but not sure this is an issue since 1 entry point is working…
Richard M. Hicks
/ May 17, 2016The WebProbeHost is created and used by default by DirectAccess. If you’ve changed it to something else using the Remote Access Management console, then there would be no need for those DNS records to exist.
Jason Hall
/ May 17, 2016Ok cool. Yep, we’re manually setting NCA & NLS addresses in the config,
I think I’ve narrowed down our problem a little more… On Step 3 of the configuration (Infrastructure Servers) when validating the DNS Server Address our ‘broken’ server fails this check saying “The specified DNS server is not responding. Ensure that the DNS Server role is installed and running on the server.”
The address specified is the IPv6 address on the internal NIC (same IPv6 address on both servers); although when you edit the suffix entry it shows as the IPv4 address instead (different depending on which server you run the console on).
Might be time to open a support case with Microsoft…
Jason Hall
/ May 17, 2016Fixed out problem… As part of removing the load balancers, we had also migrated the 2 entry points onto a subnet stretched across both locations. Turns out DA doesn’t like this & a fix is listed here: https://technet.microsoft.com/en-us/library/hh831664(v=ws.11).aspx
Thorsten Frohberg
/ June 20, 2016Hello Richard,
we have 3 different and singe DA Server in one Environment. Can i share the first created directAccess-webprobehost with the other DA servers ? Or how i can use one directAccess-webprobehost with more as one DA Server ? In DNS i can only create one directAccess-webprobehost Host Entry.
Richard M. Hicks
/ June 20, 2016You can share the single URL, but if that server is offline, Windows 8.x/10 clients connected to the other DirectAccess servers will show “connecting” for their connection status. Here, a better alternative is to use another internal web server for the web probe host. It can be any internal web server that uses HTTP (not HTTPS) and it can’t be the NLS.
mike
/ July 8, 2016Hi Richard,
Setting up dual multi-site with two entry points in the same physical location. The multi-site wizard assigned the same IPv6 address to both of the servers, is this expected behavior? IPv4 IP-HTTPS setup. The first DA server seems to work fine, but on the second one clients don’t seem to find a DC after connecting through the tunnel.
Richard M. Hicks
/ July 12, 2016Depending on your network configuration and chosen topology, yes, this can happen. Are your DirectAccess server’s edge facing with public IPv4 addresses?
mike
/ July 12, 2016Thanks for the reply! Yes, they are. I had noticed IP conflict errors while the second DA entry point would not work, but I found this on a TechNet and it seemed to resolve the problem: “Set-NetIPInterface –InterfaceAlias –AddressFamily IPv6 –DadTransmits 0”. They both seem to be working now using the same ipv6 address.
Richard M. Hicks
/ July 13, 2016Excellent. Glad you were able to get things sorted. 🙂
[email protected]
/ September 1, 2016Hi Richard,
Thanks for this post. One thing I am trouble finding the answer on is if multiple web-probe hosts are configured in “step 1” of the DA wizard…. are those hosts treated as an “and” or an “or” ?
I.e. if I leave the default web-probehost configured and add another one, do both need to be available? or only one or the other ?
if this is in the doco and I have missed it, my apologies, but I couldn’t find it.
Richard M. Hicks
/ September 3, 2016It’s “and”. If you have multiple entries defined for the connectivity status indicator, all must pass for the client to show “connected”. If one fails, the client will report “connecting”. That’s why I recommend using just one web probe host URL. 🙂
Aaron Hutchinson
/ November 8, 2016Just going to throw this out there. There is a powershell cmdlet to help get the IPv6 prefix mapping, “get-netnattransitionconfiguration” when run from the DA server.
Richard M. Hicks
/ November 8, 2016Great tip. Thanks Aaron!
Brad
/ January 27, 2017Your blog has been an invaluable resource to me in getting DA working and troubleshooting over the years. Thank you! I’m getting a very strange warning regarding the web probe URL (which hasn’t changed). We are in the process of retiring a DC so we wanted to update the list of DCs in DA (refresh management servers). The warning is:
Warning: One or more IP addresses of management server dc1.example.com cannot be added because they are associated with the web probe URL used to verify DirectAccess client connectivity. The server will be added without the conflicting IP addresses. Ensure that IP addresses associated with the probe URL are not configured on any management servers.
Obviously the IP (internal interface of the DA machine) that the web probe URL points to is different then the IP addresses of any of the 3 dc’s. They are, however, on the subnet. Is this warning benign?
Richard M. Hicks
/ January 30, 2017That’s certainly a strange one. I’ve never seen this message before so I can’t really say it is benign. However, if everything is working ok and you have no other warning or error messages otherwise, perhaps it can be ignored. Keep me posted though!
David Willetts-Smith
/ March 27, 2017Hi Richard, your posts have been most useful in setting up my DirectAccess 2012 R2 Server, I have an issue though, I’m seeing the URL availability error next to Network Location Server but my clients connect fine to DirectAccess and I can access resources on my corp LAN fine?? And secondly when I connect the client directly to the corp LAN they think they’re on a Private Network rather than the Domain and as such I can’t see any servers by name – (I can though by IP) The NLS Web Server (my DA Server) is online and accessible and I have my self cert trusted in Trusted Roots on the client – Could you think of a cause? Thanks David
Richard M. Hicks
/ March 28, 2017NLS reachability would have no affect on DirectAccess clients outside of the network. However, the symptoms you describe indicate that the NLS does have a problem for internal clients. If internal clients can’t successfully connect to the NLS, they will behave exactly as you describe. They will think they are outside the network and won’t be able to access resources by name. Try connecting to the NLS from a client that is not configured for DirectAccess. You should be able to connect without any issues at all. I suspect there’s either a hostanme mismatch or the certificate isn’t trusted. Either way the browser should tell you what the problem is. 🙂
David Willetts-Smith
/ March 29, 2017Thanks for the speedy reply Richard. I trouble-shooted the NLS inc cert, and hostnames (using split DNS & 3rd party Wildcard cert) for the website that was also living on the DA Server that the wizard created but still no luck. Yes the non configured DA clients were able to connect to the DA Server with no problem and didn’t give me any reason for why the DA Clients couldn’t see the website. I then built a new Web Server to use as the NLS, pointed DA Server to use it and now this has resolved in the console and DA Clients are working perfectly – Thanks again for your advice.
Kalaivanan Raju
/ December 6, 2017HI Richard,
We have a multi-site configuration in our environment(2 sites)and had this client saying “connecting” issues and client had issues connecting to the DA server on both the site.So we created “directaccess-corpConnectivityHost” record and issue got resolved.But again after 2 months we are getting the same issue in only one site.Users are getting issue connecting to one site and getting redirected and connect to the other site.Can you assist me with where the problem would be?
Richard M. Hicks
/ December 6, 2017There could be any number of reasons why this is happening, but understand that being connected via DirectAccess and the client showing “connected” are two different things. It is possible that the client is indeed connected, but if it can’t resolve and connect to the corp connectivity host URL (directaccess-WebProbeHost by default) it will show “connecting”. If clients aren’t being moved to another entry point, then I would have to suspect a connectivity issue that resulted in the client believing its entry point was unavailable.
Paraquad, Inc.
/ March 12, 2018No matter how much I’ve re-read all this string and other comments. Just to be sure that I understood what you wrote as well as everyone else regarding the A address that are in the DNS server entry. Is the webprobehost address is supposed to be the same as the Direct Access server since in my case, after doing a lot of investigating I noticed that the server address is different from the webprobehost address?
Thank you in advance.
Ty
Richard M. Hicks
/ March 12, 2018It depends. 😉 Technically speaking the web probe host URL can be any web server that responds on TCP port 80. In fact, you don’t have to use the “directaccess-WebProbeHost” DNS record at all. It could easily be “foo”. As the administrator, you define the web probe host URL. It’s just that when you first install/configure DirectAccess it automatically populates DNS with the A resource record “directaccess-WebProbeHost”. It’s simply convenient to continue using it. The important thing is to ensure that the URL resolves properly and that the server is listening on TCP port 80. Also, obviously, it should be reachable by DirectAccess clients. 🙂
Justin
/ October 23, 2018Having an issue with clients registering their IPv6 to the AD DNS. They keep getting 8018 error events saying the DNS server rejected their request. I can’t seem to narrow down the issue. All works fine internally and if I change the DNS server over to unsecured updates then it works fine. If the clients can access the domain from the outside, browse network, run login scripts, get GP…why would the DNS server deny them as unsecured? Any ideas on how to trouble shoot this? Thanks!
Richard M. Hicks
/ October 23, 2018Not sure what’s up there. Can’t imagine why it would work internally and not over the VPN connection. You might need to get Microsoft involved to assist in troubleshooting. Have to believe something is going on with authentication for remote clients though. :/
John Friel III
/ November 14, 2018Richard, picked up your 2016 book because I’m having problems with Server 2016 and the DA setup. We were running on Server 2012R2 for many years and it had mostly worked fine, but when I switched to the new cluster with S2D on 2016, my old 2012R2 server would not migrate. Fine, I’ll just build a new one with 2016! I had it up and running but still have a couple issues that I can’t find reference to in the book, but your blog is helping.
1. Our internal network is both IPv4 and IPv6 with our internal being fd18:b44f:9055:7200:: and our DHCP hands out both v4 and v6. Our internal domain is corp.companyname.com and external just companyname.com. The server is a VM with two external IPs and one internal. It correctly picked up the external first IP and the internal IPv6 for the adapters. When everything is said and done, it comes up and I get the warning on the corporate network route publish. Not sure what else I need.
2. The directaccess-WebProbeHost does create the A record for the internal v4 address, but the clients always stick in a “connecting” state, but I think that is because DA is running strictly v6 and this DNS entry doesn’t has an AAAA record? Is this possible?
John Friel III
/ November 14, 2018Update, I ran the DA Client Troubleshooter and the client says it successfully reached the HTTP probe at http://directaccess-WebProbeHost.corp.companyname.com yet DA is still stuck “Connecting”. The only caution I received was for the the certificate does not contain the EKU Client Authentication, but DA is up and running.
Still have the caution on the server for the Corporate network route publish.
Richard M. Hicks
/ November 17, 2018You won’t be able to establish a DirectAccess connection without a certificate that has the client authentication EKU. The tool could be reporting erroneously (it often does!) but I’d look at that closely. You can verify the establishment of DirectAccess IPsec tunnels using the Get-NetIPsecMainModeSA PowerShell command. If you have a certificate and network connectivity internally (see my previous reply) then you should have security associations (SAs) established.
Richard M. Hicks
/ November 17, 2018Although DirectAccess uses IPv6 for remote client to gateway communication exclusively, deploying DirectAccess with native IPv6 presents some unique challenges (as you have already found out!). First, you’ll need to ensure that you publish the DirectAccess client IPv6 prefix to the internal network so that DirectAccess client traffic is routed by to the DirectAccess server, not your network’s default gateway. The route publishing error is common when deploying DirectAccess with IPv6 on the internal network. You’ll need to run the following PowerShell commands on your DirectAccess server to resolve that issue.
$Prefix = Get-RemoteAccess | Select-Object -ExpandProperty InternalIPv6Prefix
$IfAlias = Get-RemoteAccess | Select-Object -ExpandProperty InternalInterface
New-NetRoute -DestinationPrefix $Prefix -InterfaceAlias $IfAlias -AddressFamily IPv6 -Publish Yes
As for the webprobehost issue, I’m guessing that’s not working because you don’t actually have an end-to-end connection established yet. Once you’ve verified connectivity to internal resources, then you can come back to troubleshooting webprobehost failures.
Joseph
/ April 8, 2019Hello Richard. I hope you still review this web page and i also hope you have an answer to my question. At my organization, we have enabled HSTS on our Direct Access Servers for the default site. Now the thing is, after enabling HSTS, we are still able to get to the default site over HTTP. The reason for this big push is that we want all of our public facing servers to use HTTPS and nothing else. So after the failed attempt to enable HSTS, i implanted a firewall rule to block all incoming and outgoing traffic on port 80. Now direct access still works, but on the client machines it says that it is always “connecting”. My question is, how does Direct Access exactly determine it need to use the connection settings and does it use port 80 for any of this? Can i change that so it uses only HTTPS?
Richard M. Hicks
/ April 9, 2019I do, and I do. 🙂 DirectAccess uses something called the “web probe host” to validate DirectAccess connectivity. It is defined in the Remote Access Management console on Step 1 – Network Connectivity Assistant. When DirectAccess is first configured the URL http://directaccess-WebProbeHost.[FQDN]/ is created and a DNS entry is added to point this URL to the DirectAccess server. Browsing this URL should return the default IIS web page. While you could configure this to use HTTPS instead of HTTP, you would need to add an SSL certificate with that subject name included on the DirectAccess server (or servers). A better option is to use another internal resource, just not the NLS. Anything that is reachable via HTTPS and is highly available should suffice. You would update your DirectAccess configuration using that URL. 🙂
Richard M. Hicks
/ April 9, 2019One more thing…here’s a good reference article with details on the DirectAccess directaccess-WebProbeHost. https://directaccess.richardhicks.com/2017/05/22/directaccess-network-connectivity-assistant-nca-configuration-guidance/
Joe D.
/ July 16, 2020Mr. Hicks, Thank you for the reply, i realize that its well over a year ago but none the less, thank you!
I knew exactly what you were talking about with the NCA. My problem with this is that it only lets us use either HTTP or PING.
(Another question: If i use PING, will that eliminate the need for IIS on the NCA? If so then i wouldn’t need to enable HSTS at all would I?)
I know the NCA will HAVE to have a SSL cert with the subject name the same as the URL that the DA Clients are using. My question with this is (and this is where i begin to step well outside of my comfort zone) do i use the HTTP redirect and HSTS Response Headers HERE, or on the DA servers? What are the specifics that i should be setting here to force the use of HTTPS and enable HSTS without breaking DA?
Richard M. Hicks
/ July 16, 2020To be clear, the NCA does not require SSL and would then of course not need HSTS. The NCA check is performed by the client after a DirectAccess client connection is established for the purposes of verifying the connection works end-to-end. Although you can configure NCA to use TLS, it isn’t required or recommended. It is best to use HTTP for the NCA health probe. You can use PING, but we recommend avoiding that as well for a variety of reasons. More details on that here.
https://directaccess.richardhicks.com/2017/05/22/directaccess-network-connectivity-assistant-nca-configuration-guidance/
Moudy
/ May 20, 2019Hi Richard
Thanks for sharing all of this knowledge. I have been reading some of your articles related to DA trying to resolve an issue for one of our clients.
They have DA server in place in 1 location and has been working for awhile and it is still working. There is only 2 clients started to experience some DA issues, it’s stuck on connecting and never connects.
I have tried pretty much 95% of the troubleshooting you included in your posts.
– Checked DNS entries.
– Checked the DA url.
– Ran all PS cmdlets related to D.
– Used the DA client troubleshooting tool.
– Checked the DA logs itself.
I narrowed it down to 2 errors I get from the DA troubleshooting tool.
1- Infrasturcture step, it cant connect to the domain share \\xx.com\sysvol\xx.com\policies
2- Failed to connect to HTTP probe at http://directaccess-WebProbeHost.xx.com
My understanding that the second error is because there is no DA established so it can’t resolve ” http://directaccess-WebProbeHost.xx.com“. Again It’s only happening to 2 clients only at this location everyone else is working fine. I have even removed them from the domain and joined them back to get the fresh policies and certs, but still the same exact issue. I hope you can help me out with this one.
Cheers
Richard M. Hicks
/ May 21, 2019When these clients are trying to connect but failing, does the output of Get-NetIpsecMainModeSA report anything? If not, can you confirm the Windows Firewall is enabled on these clients for at least the Public and Private profiles?
Moudy
/ May 21, 2019Hi Richard
Thanks for getting back to me. I have found out today that it was an issue with the IPsec, I used these commands and that was the output.
C:\WINDOWS\system32>netsh advfirewall monitor show mmsa
No SAs match the specified criteria.
C:\WINDOWS\system32>netsh advfirewall monitor show qmsa
No SAs match the specified criteria.
I have tried PS cmdlet you typed and no output at all. I can confirm the firewall is enabled to both public and private profiles, I made sure that the “IKE and AuthIP IPsec Keying Modules” service is running.
I have also checked that the network they are connected to not assigned a domain profile and it’s either public or private.
Richard M. Hicks
/ May 21, 2019Can you make sure these clients are running Enterprise edition? I’m hearing reports that some clients are reverting from Enterprise to Professional after being updated.
Moudy
/ May 21, 2019Yeah Windows 10 Enterprise 1803, it was recently upgraded form 1607 almost 1 month ago.
Richard M. Hicks
/ May 21, 2019Can you confirm it is *still* Enterprise edition? Again, have a few cases where Enterprise got switched to Professional after an upgrade. I’d also check the certificate on the client as well.
Moudy
/ May 21, 2019It’s definitely Enterprise edition, I ignored what it says under settings > about and used this PS cmdlet to report the windows edition
(Get-WmiObject -class Win32_OperatingSystem).Caption, it reported back “Microsoft Windows 10 Enterprise”. The certificate is still valid and will expire on April 2020. What’s interesting is I can’t renew the certificate or request a new one even though I am connected via VPN for my troubleshooting
When I try to renew I get enrollment error Keyset doesn’t exist.
When I try to request a new certificate with new key and go to enroll, I get Error The RPC server is unavaliable 0x800706ba.
I think I need to get the machine on the domain and try to re-enroll. Do you think this could be related to the issue?
Richard M. Hicks
/ May 23, 2019Certainly could be related. A domain-joined client should have no issues requesting a new certificate from your internal CA. Might suggest removing from domain and rejoining.
Moudy
/ May 23, 2019Thanks Richard for replying me, I actually have done this process of removing 1 of the computers of the domain and rejoined it back but didn’t fix the issue.
However I have got in touch with the users when they were in the office. They were connected locally to the domain, I tried to request a new certificate with a new key and BOOM got a new certificate. Asked them to unplug the Ethernet connection and connect to separate wifi network and DA has kicked in, I remotely signed in and checked Direct Access status and it was connected, checked the DA logs and Probe List (Pass) DTE List (Pass).
I guess somehow the certificate got corrupted when the upgrade happened prevented IPSec to do the authentication and caused all of the issues. I never seen this before but hey that’s IT.
Thanks again.
Mahmoud Jamaah
/ October 20, 2020Hello Richard,
we have two Directaccess Servers with NLB Clustering, we have a problem of that some Clients (the Majority)does not register its IPv6 Address (IP-HTTPS) at the internal DNS even when i try to Register it manually using either “ipconfig /RegisterDNS” or “Register-DNSClient”, the problem is that the Record is not sent by the DNSClient(i found nothing Related to the IP-HTTPS IPv6 Address at the event viewer. ifound only the isatap Record and it is being sent). i went through a lot of troubleshooting with no Chance to find a problem.
knowing that all clients can connect to directaccess with no problem.
i have noticed that the two DNS Records of “directaccess-corpConnectivityHost” are missing from the internal DNS. would that be a big issue ? and how can i set the Records manually without Remove the DirectAccess Role from the Servers and Configure it back.
Thanks,
Mahmoud Jama’ah
Richard M. Hicks
/ October 24, 2020The directaccess-corpConnectivityHost DNS record missing should not have any effect on your DNS registration issue. FYI, if you are running Windows 10 1909 or later you’ll need to add the following registry key to get DirectAccess client DNS registration to work again.
HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DisableNRPTForAdapterRegistration DWORD = 0