Enterprise Mobility Consulting Services" /> Enterprise Mobility Consulting Services" />
The DirectAccess Network Connectivity Assistant (NCA), first introduced in Windows 8, provides DirectAccess connectivity status information as well as diagnostic support on the client. The NCA validates that DirectAccess is working end-to-end by attempting to reach internal resources defined by the administrator during the configuration of DirectAccess. NCA configuration and operation is a source of much confusion. This article serves to provide best practice configuration guidance for the NCA to ensure optimum and reliable operation.
When a DirectAccess client is outside the corporate network, it will attempt to establish a DirectAccess connection any time it has an active Internet connection. After a DirectAccess connection is made, the NCA will attempt to validate DirectAccess connectivity by verifying availability of corporate resources as defined in the DirectAccess configuration (Remote Access Management console, Step 1, Edit, Network Connectivity Assistant).
If the NCA can reach the defined internal corporate resource(s), the DirectAccess connection is verified end-to-end and it will report the connection status as “Connected”. If it fails to connect to any internal corporate resource, it displays “Connecting”.
Figure 1. NCA successfully validated internal corporate resource connectivity.
Figure 2. NCA failed to connect to one or more corporate resources.
When first installing DirectAccess, the Remote Access Setup wizard will collect information to be used by the NCA, including corporate resources, helpdesk email address, and DirectAccess connection name. It will also provide the option to allow DirectAccess clients to use local name resolution.
Note: The NCA settings configured in the Remote Access Management console pertain only to Windows 8.x and Windows 10 clients. They are not used by Windows 7 clients at all.
Intuitively it would appear that information needs to be entered in the Resource and Type fields. However, it is recommended to leave this blank when first configuring DirectAccess. This is because the Remote Access Setup Wizard will automatically populate this field later. Specifying a resource during initial configuration will result in two entries being included, as shown here.
As you can see, the Remote Access Setup wizard automatically added the resource directaccess-WebProbeHost. . A corresponding DNS record is created that resolves this hostname to the internal IPv4 address of the DirectAccess server. In this configuration, the DirectAccess server itself serves as the corporate resource used by the NCA.
Having more than one resource to validate connectivity to the internal network is problematic though. If there are multiple entries specified, they must ALL pass a validation check from the client to report the connection status as “Connected”. Some administrators configure multiple entries with the mistaken belief that it will provide redundancy for the NCA, but it actually has the opposite effect. Having more than one entry only increases the chance of a false positive.
It is recommended that only a single corporate resource URL be defined for the NCA. The default directaccess-WebProbeHost running on the DirectAccess server can be used, or, alternatively, another internal web server can be specified if desired. Any web server will work, including Microsoft Internet Information Services (IIS), Apache, NGINX, and most Application Delivery Controllers (ADCs) or load balancers. HTTPS is not required for the web probe host, only HTTP. If using an internal web server, ensure that it is highly available.
Do NOT use the Network Location Server (NLS) as a corporate resource! The NLS is exempted from the Name Resolution Policy Table (NRPT) on the client and is not reachable over DirectAccess. This will result in the NCA failing and reporting a “Connecting” status perpetually. In addition, avoid the use of PING for validating internal corporate resources. Ping uses ICMP which is inherently unreliable and commonly blocked by host and intermediary firewalls, making it an unreliable indicator of corporate network connectivity over DirectAccess.
The NCA is a crucial and often misunderstood component in the DirectAccess architecture. Follow the guidance outlined here to ensure that the NCA works reliably and effectively in your environment.
Posted by Richard M. Hicks on May 22, 2017
Previous PostNice Post about a network connectivity direct access guide.I learn much new stuff right here about network connectivity.it’s very helpful for me.
When we had support assist us with our DirectAccess Implementation (I would have called you first if I’d known of you then), they had us include a ping to our local domain. We have also the http://directaccess-WebProbeHost.domain and another IIS servers http address in our NCA as well.
Your post alludes that the ping in there is NOT a good idea…
I ask as I’ve seen some of our DA logs on clients not functioning and they show success on the two http addresses, but failing on the ping. Removing the ping should improve connectivity then, correct? Thanks again, your posts are so insightful.
Hello
After the connection is up, how often is the probe checking the nca? And whats the behavior if it cant reach it?
This check is only performed after a network interface status change. If there are no changes, then it doesn’t check again until there is.
Ok, i thought i had a theory of why users are sometimes randomly disconnected and then connection are stuck in connecting (under high load of the DA server) and that was that the nca did not get answer fast enough.
Hello,
We have a problem since the implementation of directaccess. client tries to log in but can’t get there. You will find more information in French the screenshots on the Microsoft forum that I opened. I don’t know if I forgot something? The client was reached by djoin is not on the corporate network. https://social.technet.microsoft.com/Forums/fr-FR/14595c53-9efe-469d-8468-147235bec632/directaccess-problme-de-connexion?forum=ws19fr On the server the email address of the helpdesk and the box Allow DirectAccess clients to use local name resolution is not registered and tick. Thank you for your help
I’d have to assume you are missing some prerequisite. Certificates perhaps? Not sure. You can try running the DirectAccess diagnostic tool and see if that yields any clues.
