When configuring Windows Server 2012 R2 DirectAccess with a dedicated network location server, the Remote Access Setup Wizard may fail with the following error:
The configuration was rolled back successfully. The URL specified for the network location server cannot be resolved to an IP address.
However, the name can be resolved successfully and when stepping through the remote access setup, validation of the network location server is successful.
This has been identified as an issue with the DNS client in Windows Server 2012 R2. Microsoft has now released a hotfix to resolve this problem. For more information, click here.
After configuring a Windows Server 2012 DirectAccess server to use an intranet-based Network Location Server (NLS), you may notice that the operations status in the remote access management console indicates a critical problem with NLS, when in fact you can browse the NLS server from the DirectAccess server.
The issue here is that the DirectAccess server, in addition to being able to successfully connect to the NLS using an HTTP GET, must also be able to ping the NLS server. However, inbound ICMP is often blocked on web servers which results in the DirectAccess server marking the service as failed. The issue can be quickly resolved by modifying the host firewall policy to allow inbound ICMPv4 echo requests. For example, in my test lab I’m using a Microsoft Windows Server 2012 server with Internet Information Services (IIS) installed. A new access rule can be added to the Windows Firewall with Advanced Security (WFAS) by executing the following PowerShell command:
Note that my lab server is domain joined, so I’ve specified the WFAS profile to be the Domain profile. In addition I’ve included the IPv4 addresses assigned to the internal network interfaces of my two DirectAccess servers. You’ll need change the command as required to work in your environment.
