Uninstalling and Removing DirectAccess

Uninstalling and Removing DirectAccess 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.

Uninstalling and Removing DirectAccess

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

Implementing DirectAccess with Windows Server 2016

Leave a comment

8 Comments

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

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

      Reply
      • Yes, 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.

      • That 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. 🙂

      • Yes, 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?

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

  2. Thanks 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!

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

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: