Sign in
 
HomeProductsLibraryLearnDownloadsSupportForums
Microsoft Forefront TechCenter >
> 
> 
Direct Access 2012 - Connectivity verifiers

Answered Direct Access 2012 - Connectivity verifiers

  • Tuesday, February 12, 2013 12:50 PM
     
     
    Sign In to Vote
    0

    Hi

    Can anyone advise how one would create additional Connectivity verifiers in Direct Access 2012, what are the pre-requisites, does a resource simply need to be a webserver?


    Thanks
    • Edited by Hutchnet Tuesday, February 12, 2013 12:50 PM
    •  
     

All Replies

  • Tuesday, February 12, 2013 2:34 PM
     
     
    Sign In to Vote
    0
    When you run through the real DirectAccess configuration wizards (don't use the Getting Started Wizard, that makes all kinds of assumptions that you don't want it to make) then you will have the option to define connectivity verifiers inside Step 1, under the "Network Connectivity Assistant" screen. You can add multiple verifiers if you want, you can do HTTP or PING connections.
     
  • Tuesday, February 12, 2013 2:41 PM
     
     
    Sign In to Vote
    0

    Thanks for your reply. Sorry I may not have been clear, I understand where the web probes are configured in the management console, but how should the web probe itself be configured, for example is it just a server running IIS?

    Also I'm not 100% clear the difference between the web probe and the NLS server they seem to provide the same service.

    Thanks

     
  • Tuesday, February 12, 2013 2:53 PM
     
     Answered
    Sign In to Vote
    0

    They actually provide the opposite service :)

    The NLS website is a site that the DirectAccess client computers will look for whenever they get a network connection. If they see it, they know they are inside the network and they disable DirectAccess name resolution. If they cannot see the NLS website, then they assume they are outside the network and turn on their DirectAccess name resolution settings. NLS is critical to the correct functionality of DirectAccess.

    The Connectivity Verifiers are not critical to the working of DA at all. The Connectivity Verifiers are simply things that the NCA tool will query, and if it sees them it reports that it is successfully connected, and if it doesn't see them it reports that it has a problem. This has nothing to do with whether or not DirectAccess is actually working, but simply a reporting mechanism for the users to be able to see whether or not its connected. You can point these probes at anything that is already running in your network. You can enter an HTTP site (you could enter www.microsoft.com if you wanted to, but that wouldn't be a very good test to see whether or not you had internal connectivity), or you can simply enter a server name that the NCA tool will ping.

    You cannot input the NLS website as a connectivity verifier, because by design the NLS website is NOT accessible from a DirectAccess connection, and therefore the NCA tool would always report that it had a problem. I typically setup just one Connectivity Verifier, an HTTP connection, and I just point it at an existing SharePoint or Intranet site that you have running inside the network. No need to change anything on that webserver.

    • Marked As Answer by Hutchnet Tuesday, February 12, 2013 4:26 PM
    •  
     
  • Tuesday, February 12, 2013 3:34 PM
     
     
    Sign In to Vote
    0

    Excellent analogy, thank you!

    So for example a highly available CAS array could be used as a probe in addition to the standard probe. Do you know what happens if either are unavailable?

    I'm looking at moving the NLS away from the Direct Access server to a website, do you know what the requirements are for this?

     
  • Tuesday, February 12, 2013 4:26 PM
     
     
    Sign In to Vote
    0
    Forget that I've tested it now, it just needs to be a web server with a valid SSL certificate. Thanks again for your help.
     
  • Wednesday, February 20, 2013 9:02 PM
     
     
    Sign In to Vote
    0

    Guys

    What is corpconnectivityhost?  Where is best location for webprobehost?  Inside the network?

    Should webprobehost be accessible just inside or from inside and outside?  In the intranet tunnel or the infrastructure tunnel? (we are using NAP, full enforcement)

    Thanks



    • Edited by RessyR Wednesday, February 20, 2013 9:23 PM
    •  
     
  • Thursday, February 21, 2013 8:17 AM
     
     
    Sign In to Vote
    0

    Guys

    What is corpconnectivityhost?  Where is best location for webprobehost?  Inside the network?

    Should webprobehost be accessible just inside or from inside and outside?  In the intranet tunnel or the infrastructure tunnel? (we are using NAP, full enforcement)

    Thanks



    Hi Ressy

    The corpconnectivity host is a loopback address as per below:

    Connectivity verifiers—Remote Access creates a default web probe that is used by DirectAccess client computers use to verify connectivity to the internal network. To ensure the probe works as expected the following names must be registered manually in DNS:
    1. directaccess-webprobehost—should resolve to the internal IPv4 address of the Remote Access server, or to the IPv6 address in an IPv6-only environment.
    2. directaccess-corpconnectivityhost—should resolve to localhost (loopback) address. A and AAAA record should be created, A record with value 127.0.0.1 and AAAA record with value constructed out of NAT64 prefix with the last 32 bits as 127.0.0.1. The NAT64 prefix can be retrieved by running the cmdlet get-netnattransitionconfiguration.
      noteNote
      This is valid only in an IPv4-only environment. In an IPv4+IPv6, or IPv6-only environment, only a AAAA record should be created with the loopback IP address ::1.

    The webprobe is set in the DirectAccess Client Setup part of the Remote Access Setup, its a connectivity verifier, as stated by Jordan above.

    It should be internal as it validates connectivity to internal resources, in my case I now have 2 web probes, one that connects to the actual RAS server and one that connects to a Exchange 2010 CAS array, both HTTP.