Indeed in order to check if it's on the corporate network or not the Windows 7 Enterprise/Ultimate or Windows 2008 R2 client will make the following tests:
- Is it possible to resolve nls.security.lab?
- Is it possible to join the IP address through https?
- Is there a page on the website: is the website return the HTTP code 200 OK?
Logically this is a critical server and it's highly recommended to deploy it with high availability with fault tolerance.
First scenario: NLS loss when the client is on the Internet
When we look at the DirectAccess configuration:
It's make sense because if the client could resolve it then the DirectAccess is disabled and it's like a snake eating its own tail...
Take care of not mutualize the NLS server on a resources that must be available through DirectAccess like:
- An intranet portal like SharePoint
- A Web service like Outlook Web Access or Communicator Web Access
Second scenario: NLS loss when the client is on the corporate network
If we look at how Windows see the network in this case it's a public one and not a domain network.
In this case we are in big trouble, the Windows client will not be able to solve any FQDN.
If the server falls down there is two scenarios:
- If the client is already connected to the corporate network nothing happen until a reboot or when the network cable is unplugged.
- If the client reboot or the state of the network change everything goes wrong. But in this case at regular intervals the client try to contact the NLS server and change it's state alone.
In this case the end user could through the DirectAccess Connectivity Assistant to disable manually the NRPT. In order to do that on the contextual menu choose the option Prefer Local DNS Names.