How to Set Up DirectAccess on Windows Server 2019

March 15, 2026
Tutorials
Comment off

How to Set Up DirectAccess on Windows Server 2019

DirectAccess provides seamless, always-on VPN-like connectivity for domain-joined Windows clients without requiring the user to manually initiate a VPN connection. Unlike traditional VPN, DirectAccess establishes an encrypted IPv6-over-IPv4 tunnel automatically whenever a managed client device has internet connectivity. This enables remote management, Group Policy application, and access to corporate resources as if the device were on the internal network. Windows Server 2019 supports DirectAccess with improvements to load balancing and multisite deployments.

Prerequisites for DirectAccess

DirectAccess has specific requirements. The DirectAccess server must have two network interfaces: one connected to the internet (or a DMZ) and one connected to the internal network. The server must be domain-joined. Clients must be running Windows 10 Pro/Enterprise or Windows 8.1 Enterprise (Home editions are not supported). An internal PKI (AD CS) is required for certificate-based authentication. You need at least one consecutive public IPv4 address or a single public IPv4 address with NAT.

# Verify the server has two network adapters
Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, MacAddress

# Install the Remote Access role with DirectAccess
Install-WindowsFeature -Name DirectAccess-VPN, Routing -IncludeManagementTools

# Verify installation
Get-WindowsFeature -Name DirectAccess-VPN, Routing

Configuring the Network Adapters

Before running the DirectAccess setup wizard, ensure the adapters are correctly identified as Internet-facing and Internal-facing:

# Set meaningful names for the adapters
Rename-NetAdapter -Name "Ethernet" -NewName "Internal"
Rename-NetAdapter -Name "Ethernet 2" -NewName "Internet"

# Configure the Internet-facing adapter with a public IP
New-NetIPAddress -InterfaceAlias "Internet" -IPAddress 203.0.113.1 -PrefixLength 29 -DefaultGateway 203.0.113.254
Set-DnsClientServerAddress -InterfaceAlias "Internet" -ServerAddresses 8.8.8.8

# Configure the Internal adapter
New-NetIPAddress -InterfaceAlias "Internal" -IPAddress 192.168.1.5 -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Internal" -ServerAddresses 192.168.1.10, 192.168.1.11

Running the DirectAccess Configuration Wizard

Use the Remote Access Management console or PowerShell to configure DirectAccess. The wizard approach covers most scenarios:

Import-Module RemoteAccess

# Configure DirectAccess using PowerShell
# This configures a basic DirectAccess deployment

# Set the DirectAccess server's external address (public IP or FQDN)
$externalAddress = "203.0.113.1"

# Set the internal network prefixes that clients will route through DA
$internalPrefixes = "192.168.0.0/16","10.0.0.0/8"

# Configure DirectAccess with default settings
Install-RemoteAccess `
    -VpnType DirectAccess `
    -DAInstallType FullInstall `
    -InternetInterface "Internet" `
    -InternalInterface "Internal" `
    -ConnectToAddress $externalAddress `
    -NlsUrl "https://nls.corp.example.com/nls/" `
    -Force

Configuring the Network Location Server (NLS)

The Network Location Server is a critical component of DirectAccess. Clients probe the NLS URL to determine if they are on the corporate network or on the internet. When the NLS is reachable, the client knows it’s internal and does not use the DirectAccess tunnel. The NLS must be an internal-only server with a valid HTTPS certificate:

# The NLS can be a simple IIS site on an internal server
# Install IIS on a highly available internal server
Install-WindowsFeature -Name Web-Server -ComputerName "nls.corp.example.com"

# Request a certificate for the NLS URL
$nlsCert = Get-Certificate `
    -Template "WebServer-2Year" `
    -SubjectName "CN=nls.corp.example.com" `
    -DnsName "nls.corp.example.com" `
    -CertStoreLocation "Cert:LocalMachineMy" `
    -ComputerName "nls.corp.example.com"

# Create a simple IIS site for the NLS (returns 200 OK)
New-Website -Name "NLS" `
    -PhysicalPath "C:inetpubnls" `
    -Port 443 `
    -HostHeader "nls.corp.example.com" `
    -ComputerName "nls.corp.example.com"

# The NLS must NOT be accessible from the internet
# Configure firewall rules to block external access to nls.corp.example.com

Configuring DirectAccess Client Settings via GPO

DirectAccess deploys automatically generated GPOs to configure client settings. These GPOs are applied to computers in the security groups you specify during setup:

# Create a security group for DirectAccess clients
New-ADGroup `
    -Name "DirectAccess-Clients" `
    -GroupScope Global `
    -GroupCategory Security `
    -Path "OU=Groups,DC=corp,DC=example,DC=com"

# Add computers to the group
Add-ADGroupMember -Identity "DirectAccess-Clients" -Members "LAPTOP01$","LAPTOP02$"

# Set the client security groups in DirectAccess configuration
Set-DAClient -SecurityGroupNameList "CORPDirectAccess-Clients" -OnlyRemoteComputers Disabled

# View client configuration
Get-DAClient

Configuring IP-HTTPS (NAT Traversal)

When 6to4 and Teredo tunneling protocols are blocked by NAT, DirectAccess falls back to IP-HTTPS, which encapsulates IPv6 traffic over an HTTPS connection on port 443. This works through most firewalls and NAT devices:

# Configure IP-HTTPS with a certificate
$cert = Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -like "*directaccess.corp.example.com*"}

Set-DAServer `
    -IPHttpsCertificate $cert `
    -IPHttpsUrl "https://directaccess.corp.example.com/IPHTTPS" `
    -TeredoState Enabled

# Verify DirectAccess server configuration
Get-DAServer

Configuring Multisite DirectAccess

Multisite DirectAccess allows clients to connect to the nearest DirectAccess server based on geographic proximity, improving performance for global organizations:

# Enable multisite and create the first entry point
Enable-DAMultiSite `
    -Name "Global DA Deployment" `
    -EntryPointName "New York" `
    -GslbFqdn "global.da.corp.example.com"

# Add a second entry point (London office)
Add-DAEntryPoint `
    -EntryPointName "London" `
    -RemoteAccessServer "da-london.corp.example.com" `
    -GslbIP 203.0.113.50 `
    -ConnectToAddress "da-london.corp.example.com"

# View all entry points
Get-DAEntryPoint

Verifying DirectAccess Connectivity from a Client

# On the DirectAccess client (run as administrator)
# Check DirectAccess connectivity status
netsh dnsclient show state

# Use the DirectAccess connectivity assistant or check via PowerShell
Get-DAConnectionStatus

# Check the DirectAccess tunnel interfaces
Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like "*IPHTTPS*" -or $_.InterfaceAlias -like "*Teredo*"}

# Force a DirectAccess connection
netsh interface teredo set state enterpriseclient

# Check event logs for DirectAccess events
Get-WinEvent -LogName "Microsoft-Windows-OtpCredentialProvider/Operational" -MaxEvents 10

Monitoring DirectAccess on the Server

# View active DirectAccess connections
Get-RemoteAccessConnectionStatistics

# View connected clients
Get-RemoteAccessConnectionStatisticsSummary

# Check DirectAccess server health
Get-RemoteAccessHealth

# View connection status in real time
Get-DASession

# Check the Remote Access Management event log
Get-WinEvent -LogName "Microsoft-Windows-RemoteAccess-RemoteAccessServer/Operational" -MaxEvents 30 | `
    Select-Object TimeCreated, LevelDisplayName, Message

DirectAccess provides transparent, always-on remote access for managed Windows clients without the user experience friction of traditional VPN. However, it requires careful planning: maintain a healthy PKI, ensure the NLS is highly available (NLS failure causes all clients to think they are remote and use DA tunnels even when on-premises), and monitor the DA server logs regularly for authentication failures that might indicate certificate expiration or policy issues.

How to Set Up DirectAccess on Windows Server 2019