Important! Updated July 15, 2019 to support all versions of Windows Server including Windows Server 2012 and 2012 R2. Also added functionality to renew self-signed certificates individually.
When DirectAccess is deployed using the Getting Started Wizard (GSW), sometimes referred to as the “simplified deployment” method, self-signed certificates are created during the installation and used for the IP-HTTPS IPv6 transition technology, the Network Location Server (NLS), and for RADIUS secret encryption. Administrators may also selectively choose to use self-signed certificates for IP-HTTPS, or when collocating the NLS on the DirectAccess server. The RADIUS encryption certificate is always self-signed.
Certificate Expiration
These self-signed certificates expire 5 years after they are created, which means many DirectAccess administrators who have used this deployment option will need to renew these certificates at some point in the future. Unfortunately, there’s no published guidance from Microsoft on how to accomplish this. However, the process is simple enough using PowerShell and the New-SelfSignedCertificate cmdlet.
PowerShell Script on GitHub
The PowerShell script to renew DirectAccess self-signed certificates has been published on GitHub. You can download Renew-DaSelfSignedCertificates.ps1 here.
Important Considerations
When the IP-HTTPS and NLS scripts above are executed, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy (the RADIUS encryption certificate can be updated without impacting users). This will require connecting to the internal network locally or remotely using another VPN solution. In addition, internal clients that are not online when this change is made will be unable to access internal resources by name until they update group policy. If this happens, delete the Name Resolution Policy Table (NRPT) on the client using the following PowerShell command and reboot to restore connectivity.
Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Confirm:$false
Additional Information
PowerShell Recommended Reading for DirectAccess Administrators
Top 5 DirectAccess Troubleshooting PowerShell Commands
Configuring Multifactor Authentication (MFA) is an excellent way to ensure the highest level of assurance for Always On VPN users. 
Once Windows 10 Always On VPN has been deployed in production, it may be necessary at some point for administrators to deny access to individual users or computers. Commonly this occurs when an employee is terminated or leaves the company, or if a device is lost, stolen, or otherwise compromised. Typically, this means that user accounts and computer accounts in Active Directory are disabled, and any issued certificates are revoked. However, additional steps may be required to disconnect current VPN sessions or prevent future remote connections.
A longstanding issue with Windows 10 Always On VPN is that of VPN tunnel connectivity reliability and device tunnel/user tunnel interoperability. Many administrators have reported that Always On VPN connections fail to establish automatically at times, that only one tunnel comes up at a time (user tunnel or device tunnel, but not both), or that VPN tunnels fail to establish when coming out of sleep or hibernate modes. Have a look at the comments on this post and you’ll get a good understanding of the issues with Always On VPN.
The 
When an Always On VPN connection is provisioned to a Windows 10 client, there’s nothing to prevent a user from disconnecting or even deleting the connection. Some administrators have expressed concern about this, fearful that users may disable the VPN to improve performance or circumvent access controls when force tunneling is enabled. Also, administrators may wish to prevent users from accidentally or purposefully making changes to the configuration, or even deleting the connection entirely.
I’m pleased to announce that I’ll be delivering two technical training sessions at this year’s TechMentor Redmond event. This event takes place on the Microsoft campus in Redmond, WA August 5-9, 2019. I’ll be presenting two sessions on Thursday, August 8. They are:
A while back I described in detail how to 
I’m pleased to announce that I’ll be bringing my popular 
