This web site is primarily dedicated to installing, configuring, managing, and troubleshooting DirectAccess on Windows Server 2012 R2 and Windows Server 2016. However, there’s little documentation on how to properly uninstall and remove DirectAccess. This post provides guidance for gracefully uninstalling and removing DirectAccess after it has been deployed.
DirectAccess Clients
It is recommended that all clients be deprovisioned prior to decommissioning a DirectAccess deployment. This is especially true if the Network Location Server (NLS) is hosted on the DirectAccess server itself. Remove all client computers from the DirectAccess client security group or unlink DirectAccess client settings GPOs (but don’t delete them!) from any OUs where they are applied. Allow sufficient time for all clients to process security group membership changes and update group policy before uninstalling DirectAccess.
Network Location Server
If the NLS is installed separate from the DirectAccess server, it is recommended that it remain online for a period of time after DirectAccess has been decommissioned. Clients will be unable to access local resources if they still have DirectAccess client settings applied and the NLS is offline. Keeping the NLS online prevents this from happening. If this does happen, you’ll need to delete the Name Resolution Policy Table (NRPT) on the client to restore connectivity. To do this, run the following command in an elevated PowerShell command window and restart the computer.
Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Confirm:$false
Uninstall DirectAccess
It is not recommended to decommission DirectAccess by simply turning off all DirectAccess servers and manually deleting all of the associated group policy objects (GPOs) in Active Directory. A better way is to gracefully remove DirectAccess using the GUI or PowerShell.
To uninstall DirectAccess using the GUI, open the Remote Access Management console, highlight DirectAccess and VPN, and then click Remove Configuration Settings in the Tasks pane.
Alternatively, DirectAccess can be removed by running the following command in an elevated PowerShell command window.
Uninstall-RemoteAccess -Force
Additional Resources
DirectAccess Network Location Server (NLS) Guidance
DirectAccess Network Location Server (NLS) Deployment Considerations for Large Enterprises
Martin
/ April 13, 2017Hi Richard.
Thanks for the post, good job as always!
One question which is somehow related to “removing”: How clients can configured, in case the DA server isn’t reachable? The biggest problem is on internal network in case of DA unavailability, because all DNS request are forwarded to the IPv6 interface of the DA server based on the NSPT. The AD becomes unavailable then and all kerberos auth. fails. I tried to add the IPv4 addresses of the internal DNS servers to the policy table (in second/third oder), but it does not seem to work. Any ideas? I don’t want to build a HA configuration.
Thanks!
Martin
Richard M. Hicks
/ April 13, 2017Hi Martin,
I believe you are talking about a scenario in which the DirectAccess server (with NLS hosted on the DirectAccess server) is offline, clients on your internal network are unable to connect to local resources by name. This happens because the NLS is unreachable (along with the DirectAccess server) so the client *thinks* it is outside. The NRPT is now in effect, so name resolution requests are sent over the DirectAccess connection, which of course fails because the DirectAccess server is offline! The best way to prevent this from happening is to host the NLS somewhere else internally. That way when the DirectAccess server is offline, the NLS remains up and your internal clients won’t be affected.
Martin
/ April 13, 2017Yes, you’re right. But lets assume, i would like to have a single server deployment (small customer). Why it’s not possible to configure the name resolution policy table in a way, that the client tries to use the internal name servers in case the NLS/DA server ist down? When i delete the policy on the client, the client comes back online.
Richard M. Hicks
/ April 14, 2017That would prevent the client from being able to establish a DirectAccess connection in the first place. A DirectAccess connection is only established *after* NLS reachability is checked. 🙂
Martin
/ April 16, 2017Yes, i know. But my question is: When a client is connected to the INTERNAL network, no DA connection is nessecary. Does there a “fallback” scenario exist for clients connected to internal network in case DA/NLS is down?
Richard M. Hicks
/ April 18, 2017If the option to “Allow DirectAccess clients to use local name resolution” is enabled (Step 1, Network Connectivity Assistant) then you should be able to disconnect DirectAccess on the client. You’ll do this by opening the control panel and clicking Network & Internet, then clicking DirectAccess. Clicking on Workplace Connection (status should be Connecting…) and there you’ll see a Disconnect button. That will restore normal internal network connectivity. If the client restarts and the NLS is still unavailable, you’ll have to repeat this process.
Ryan Arnold
/ July 27, 2017Thanks for the info Richard. I have a question about this, we had a domain controller go down and it happened to be the DC where the DA servers where trying to contact to retrieve policy settings. We have since migrated to a new Server 2016 DA setup, but when I try to uninstall the role from the old 2012 servers, I get “Domain Controller XXXX cannot be reached for localhost.” Is my only option to manually delete the GPO settings or is there a way I can tell the DA servers to look at a different DC for configuration settings? Thank you!
Richard M. Hicks
/ July 29, 2017Manually removing the DirectAccess server and deleting all associated components (GPOs, DNS entries, etc.) is probably ok in your scenario. You might be able to update the management servers using the UI or the Update-DaMgmtServer PowerShell command and see if that helps. But honestly, it’s probably easier and quicker to remove everything manually.
Michael
/ July 3, 2018Hi Richard,
Thanks for sharing your experiences and knowledge. Most importantly thanks for your time.
I was looking for something else actually when I’ve come across this. One of our clients decommissioned the DA server, simply turned off and deleted it unfortunately. I was looking for a guide that shows how to remove DA server manually and how to delete all associated components. Is there a proper detailed document/article for this? Because everyone is helping out how to install on the web, even Microsoft itself, I couldn’t find something that shows cleaning up after a DA Server.
Richard M. Hicks
/ July 4, 2018Sounds like a good suggestion for a future post. 🙂 Essentially you’ll need to delete the DirectAccess client and server settings GPOs in Active Directory. You will also need to delete any associated DNS entries (e.g. directaccess-WebProbeHost, NLS, etc.). You can find a list of DNS entries here: https://directaccess.richardhicks.com/2015/07/06/directaccess-dns-records-explained/.
Ricardo Fernandes
/ July 26, 2018One doubt, I had a subdomain removed from our AD but now DA servers keep complaining that they cant reach those subdomain domain controllers. How do I remove that subdomain info? Only on the GPOs? Or is there a better safer way?
Richard M. Hicks
/ July 29, 2018Try updating the infrastructure servers on the DirectAccess server. Run the PowerShell command Update-DaMgmtServer and see if that helps. 🙂
Michael Schindler
/ August 31, 2018I have the same issue (removed subdomain) did the Powershell command fix the issue?
Craig
/ October 8, 2018Hi Richard,
I have a multi-site config with 4 entry points, one DA server in each entry point, one entry point in 4 different countries. I need to decommission the entry points one by one. It is just as simple as going into the GUI, selecting a remote entry point and clicking on “Remove Entry Point” in the task pane and runnig through the wizard?
I have already removed the country specific client machines from the DA security group used for applying the client group policy.
Also, when I get down to just two entry points left, how do i revert back to a single-site configuration?
Richard M. Hicks
/ October 13, 2018That’s correct. Same process for going back to single site too. 🙂
John
/ January 30, 2019Was hoping for some help. Server 2016, VPN was working fine, added Direct Access, then decided I didnt need Direct Access… after uninstalling Remote access (and direct access) using: powershell cmd= uninstall-remoteaccess -force I cannot get Remote Access (vpn only) to work again after reinstalling. I even went the route of the uninstall via powershell and removing the role. No luck. When re-adding the role and reconfiguring using the same install doc I cannot get the client to connect. What might I be missing?
Richard M. Hicks
/ January 31, 2019Can’t imagine why that wouldn’t work! What kind of error(s) are you getting when you try to establish a VPN connection?
John
/ January 31, 2019Thanks for your quick reply. Turns out the “Connect” button on the network system tray icon is buggy. Saw another post that recommended using the “Connect Button” from the VPN Settings window. That did it. Silly waste of an hour troubleshooting thinking it was server related. A good reminder to follow basic troubleshooting steps first.
Nick Nanos
/ July 28, 2019Richard, what is the best way to remove the DirectAccess client from Windows 10? Our DA VM was destroyed in a fire. We moved our users to a new location and now the users have to stop the DiA client from trying to connect for the users to get local resources. Its going to be a long time before we go back to that location so we would like to permanently remove the DA client from about 300 Windows 10 Enterprise laptops, We tried disabling the IPHelper but after you reboot, the local resource are still not available and you removed the option to stop the directacces from trying to connect. What am i missing? A GPO? REG Entry? Service?
Richard M. Hicks
/ July 30, 2019Removing the clients from the DirectAccess client security group is the best way. However, this assumes you have access to the original domain where the client was joined. If not, best thing to do is delete the NRPT table on the client. You can do this by deleting the following registry key:
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig
Hope that helps!
rgsteele
/ November 21, 2020I don’t know if there was a change in PowerShell or what, but the command for removing the DNSPolicyConfig registry key didn’t work for me. This, however, did:
Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Recurse
Richard M. Hicks
/ November 24, 2020Thanks!
Semjon Lick
/ January 31, 2022Hi Richard,
i added two new server in an existing 2 Node DA Cluster and after the two new Servers worked as expected, i shut down the old two. Next step will be to remove the old two servers from the cluster, what would be the best way to do so?
I would imagine, that i remove them from the cluster over the “Remote Access” Tool. Do the old two servers needs to be turned on for removing them from the cluster?
is there any procedure which you would recommend?
Thanks in advance and greets from germany
Richard M. Hicks
/ January 31, 2022To remove the old servers from the cluster they must first be online. So yes, you’ll have to bring them back up. Then go to the load balancing settings and choose ‘Add/Remove Servers’ and remove the two servers there.
Bhupesh K
/ March 8, 2022Hi Richard, some (random) clients in my environment are exhibiting strange behaviour, where the DA reg keys are some how being deleted or modified and in doing so removing most of the DA configuration from the system, during we also observed that we cannot start the NCA service. We are resolving by reconnecting the affected client to the LAN however we cant yet explain why this might be happening, potentially during a GP update but so far nothing conclusive. Any thoughts?
Thanks
BK
Richard M. Hicks
/ March 8, 2022Is it possible the client is reverting back to Windows Professional? When this happens again have a look at the SKU and make sure it is still Enterprise Edition.
Bhupesh K
/ March 8, 2022Hi Richard, thanks for the quick reply!! This was checked as we read some other articles alluding to the same, however the clients were still on Enterprise Edition.
Richard M. Hicks
/ March 8, 2022Ok, that’s good. That’s the most common cause of the issue you described. It could be related to group policy processing somehow, though. Hopefully the event logs on the endpoint will yield some clues there.
scriven_j
/ March 18, 2022We have been trying to remove Direct Access and have removed GPO from OU (but not deleted). Have ran GPUPDATE /FORCE for clients (we have Always ON VPN now). DA still seems to be hanging around though and if VPN gets disconnected, clients try to connect again and I can see things like NRPT and probe hosts in the registry still. Is there something else I can do on the clients to get rid of these references so that everything doesn’t break when I decommission the DA server?
Richard M. Hicks
/ March 18, 2022You can try deleting the NRPT for DirectAccess to see if that helps. However, don’t do this if you are using the NRPT for Always On VPN! Also, this setting will come back if the DirectAccess client settings GPO is still applying. 🙂
Get-Item -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient’| Remove-Item -Confirm:$false
scriven_j
/ March 18, 2022Apologies I posted again as my comments weren’t showing and now they are! Is removing NRPT sufficient to remove DA? (we are not using NRPT on Always On) or are there other traces that might cause a problem?
Richard M. Hicks
/ March 18, 2022Sorry…I have to moderate comments because of spam. :/
So, technically speaking deleting the NRPT does not “remove” or “disable” DirectAccess. However, it *effectively* disables DirectAccess. Although the DirectAccess IPsec tunnels remain, the client can’t resolve names over the tunnel, so no traffic is routed over the tunnel. In this state, it should not interfere with Always On VPN or any other connections.