I'm having trouble getting through the Direct Access wizard.  It gets to "Updating Network Connectivity Assistant settings" and dies with the error "No such host is known."  It'd be nice if it gave a few more details on what host it's talking about but I was wondering if maybe it might be because our Internet facing NIC's IP address and the public IP that it's NAT-ed to have the same name in DNS but they point to different IP addresses depending on whether you're trying to resolve it from the Internet or from the private side of the network.  (For example if I were to ping daserver.mydomain.com from inside I'd get the private IP 10.0.0.10 and if I would ping it from a box that is on the Internet I get a public IP like 164.123.145.160.)  

I've tried entering just the public IP of the DA server and the DNS name into the "Type the public name or IPv4 address used by clients..." field of the wizard and the result is the same.  I also installed KB2929930 and the only difference I noticed is that the public IP is entered in the wizard by default now.

This is a Server 2012 R2 dual NIC DA installation behind a NAT and an edge firewall with only port 443 open to the Internet.

Hi Matt.. why is the internal DNS pointing to the internal NIC (private IP) of the DA server rather than the public address? NLS is used to determine whether the client is on the corporate network.

Do you have split-brain DNS? You should have 2 different hostnames since it is actually 2 different IP's and locations (public and inside). Assume da.domain.com points to the public IP (ie 8.8.8.8) , and make another hostname for the internal server IP (da-internal.domain.com -> 10.0.0.10). You also have to create an exeption in NRPT for da.domain.com so clients on the outside can connect to your DA server from the outside. If not, clients on the outside will try to go to your DA server for DNS resolution, which it can't, since it hasn't started the DA infrastructure tunnel at all from the outside.

Anyway, NLS is the server DA clients are trying to access and determine if the clients are inside or outside.

NCA on the other hand, also need another host similar to the NLS server on the inside, and this should not be the same server as the NLS server. It's purpose is to determine if the client is inside or outside for the NCA only. If your NLS server is an internal IIS server, you could create a second site in IIS with a second IP and then co-locate NLS and NCA probe on the same server. NLS requires a HTTPS connection, and the NCA host can be plain HTTP.

That means NLS is critical for DA to work, the NCA probe host is not so critical. DA will still work if the NCA probe host is down, but it will show an error that DA is not working (altough DA actually indeed IS working, confusing you and making troubleshooting more difficult). On Win7 clients you will see a red mark on the NCA icon.

So the wizard dies when it's applying the NCA host settings, and it indicates you have to change your setup a little bit. Note that you should use hostname rather than an IP address, even if the wizard allow you to add an IP address.

Yes, it is split-brain DNS.  I'll have them change the entry for the internal IP to something different and see if that helps.

I had them remove the internal DNS entry for the public IP of the DA server and it still fails at the same place with "No such host is known."  I can no longer ping that IP by name from the DA server so I added the public IP to the hosts file with the same name and it also fails at the same place in the wizard.  Is there some kind of debug logging I can turn on so I can see more details on what the error is?

You should really just get rid of that internal record anyway. The only time that you want DA clients contacting the public DNS name of your DNS server is when they are outside the network, on the internet. No reason to have it resolve to anything from your internal DNS servers.

You should really just get rid of that internal record anyway. The only time that you want DA clients contacting the public DNS name of your DNS server is when they are outside the network, on the internet. No reason to have it resolve to anything from your internal DNS servers.

It is removed.

Whoops, sorry I didn't see your last reply. :) Have you re-visited the NCA settings screen inside Step 1 to see what is listed as probes there? Since that is the area where your rollout is failing, I would start by focusing there. Maybe try removing any probes in there now and adding a new, simple PING probe to test and see if it gets any further. Make sure to remove the "webprobehost" probe that the wizard loves to self-insert into the NCA properties (if it exists), that one always seems to cause trouble. Not necessarily the trouble you are seeing, but other problems down the road.

Whoops, sorry I didn't see your last reply. :) Have you re-visited the NCA settings screen inside Step 1 to see what is listed as probes there? Since that is the area where your rollout is failing, I would start by focusing there. Maybe try removing any probes in there now and adding a new, simple PING probe to test and see if it gets any further. Make sure to remove the "webprobehost" probe that the wizard loves to self-insert into the NCA properties (if it exists), that one always seems to cause trouble. Not necessarily the trouble you are seeing, but other problems down the road.

When I open the settings for "DirectAccess Client Setup" and click the "Network Connectivity Assistant" section the "Resources that validate connectivity..." section is blank.  I double click inside the table and in the "Configure Corporate Resources for NCA" change the type to PING and set the address to a server that is only accessible from the private network, click "validate" and get the OK and then click Add.  Unfortunately the wizard still fails at the same place.  Should I be putting in an IP that can be pinged from both the private network AND the Internet?  The verbiage is for an IP or URL that is ALWAYS accessible which would lead me to think that it should be something that is pingable from both the inside and the outside but I wonder how much value that would have for the client to determine which network it's on. 

No, you are doing it properly with adding in just a resource that is available internally. The idea is that the client needs to validate connectivity to the internal network by looking for this probe, so that NCA properly reports "connected" once DA is really connected.

So the GPO rollout is not failing because of NCA settings it would seem, but I'm not sure what section it jumps to next in the GPO settings rollout. When the rollout fails, do you have any further information listed if you click on the step that failed? Sometimes it will give more detailed info about what is going on under the hood if you try to expand that.

Also, if your NCA screen was blank, does that mean you had not seen that screen before? I only ask because that would imply that you are using the "Getting Started Wizard" to setup DirectAccess, is that accurate? In my opinion you should really stay away from using the GSW and setup DirectAccess using the full set of real wizards. GSW takes all kinds of shortcuts that are not good practices. You'll likely end up with weaker authentication and self-signed certificates. If you have been using the GSW, I recommend removing the Remote Access role altogether, deleting the GPOs, and reinstalling the Remote Access role. Then when you launch it for the first time, make sure to choose the option to run the full wizards, not the Getting Started Wizard.

If you've not been using GSW, then I apologize for that rant :)

Just a quick note:
Make sure that the tests that you specify in the NCA settings, also include a HTTP test and not a PING only.

I have been using the GSW, the idea was to get something working with the minimum complexity and then start adding from there.  So far the $*#@&* thing doesn't work at all so I'm not terribly confident!  I'll give it a go without the GSW and see if that helps.

So how do I get it to do the full wizards instead of the Getting Started Wizard?  Also - no log files for the wizard at all?

Unfortunately the GSW takes every shortcut it possibly can for the sake of saving time, and your DA environment turns out sub-par when finished. Some of the items that GSW puts into place are only reversed by PowerShell commands.

Right after you install the Remote Access role, the first time you open up the Remote Access Management Console, you have a choice. There are two links that you can click on, one says "Run the Getting Started Wizard", and the other says "Run the Remote Access Setup Wizard" - you definitely want to choose the second one.

There is a webinar I run pretty regularly here at work for potential DA customers, and I have a whole slide dedicated to "Don't use the Getting Started Wizard" :)

Sadly I'm still stuck at the same place even after using the regular (non-GSW) Wizard and configuring a http based web probe.  It would be helpful to know what bleeping host the error message is referring to!

In Step 2, where you specify the public DNS name of your DirectAccess environment, is that public DNS record in place and working to point the name specified there to the primary public IP address being used by the DirectAccess server? Typically if this is not done you will have trouble, usually the trouble presents itself right on the Step 2 screen when you specify the DNS name, but it's possible if that record isn't in place yet that it might be failing to validate the name at this point.

Also, when you went back and ran the real wizards, did you fully remove the Remote Access role and then reinstall the role? Make sure to do that so that it clears anything out (manually get rid of any DA GPOs that might have gotten left in AD as well)

Oddly enough this issue seems to be domain related.  The powershell command that is failing is

Set-DAClientExperienceConfiguration -FriendlyName 'Workplace Connection' -PreferLocalNamesAllowed $False -PolicyStore 'OURDOMAIN.LOCAL\DirectAccess Client Settings' -CorporateResources @('HTTP:http://ourwebserver.ourdomain.local/')

The error is happening when attempting to access the policy store.  There is a section of the documentation for the Set-DAClientExperienceConfiguration cmdlet that states you can use a "session" from Open-NetGPO instead of using the -PolicyStore option and I can't get that one to work either.

Are there any firewalls between the DirectAccess server and the corporate network at all? You typically want to make sure that the DA server has access to any of your domain controllers. Also, if you are running DA in two-NIC mode, make sure all of your static routes are in place so that it can contact any of the DCs that it might be trying to. Trouble contacting the domain can definitely be related to a missing route, even if one or more DCs are actually available.

And of course, you want to make sure that your user account which you are using to log into the DirectAccess server has rights to create and modify GPOs?

Other than the software firewall there are none in between the DA server and it's domain controllers, they are on the same subnet so it shouldn't even need a route.  I can ping them both from the DA server also.  My user account is a domain admin and I've used it to create a policy in the past so I don't think that's the issue.

I am running in dual-NIC mode and I have default gateways set up on both NICs.  Is this wrong?

That is wrong, only one NIC should have a default gateway, and that is the external facing NIC.

The internal NIC (that is on the same subnet as your DC's) should not have a gateway, but static routes to other internal network if needed.
In your case, your DA and DC is on the same subnet and therefore do not need to add static routes. That is, unless you have other subnets the DA clients on the outside needs to access. Can you please post an ipconfig /all ?

Yeah, you definitely need to re-visit your network config on that box. And best would be to remove the role, fix the network config, and then reinstall the role, otherwise you may have left-overs that will come back and haunt you.

External NIC:
Gateway = Yes
DNS servers = No

Internal NIC:
Gateway = No
DNS servers = Yes

And as Steve said, not having a default gateway on the internal NIC means that any subnets which you need to contact inside your network need to be configured as static routes into the Windows routing table.

External NIC:
Gateway = Yes
DNS servers = No

Internal NIC:
Gateway = No
DNS servers = Yes

I changed the config to reflect this and removed the role then added it back in and I'm still at the same spot.  I'm still stumped as to why it would be failing at the part where it's trying to get the group policy store.  The only thing I can think of right now is that it's some kind of odd DNS misconfiguration or that the AD "database" is corrupted somehow.

Just to wrap this one up the issue turned out to be a corrupted group policy that was preventing the DA setup wizard from completing.

• Marked as answer by Matt Br 12 hours 7 minutes ago

Just to wrap this one up the issue turned out to be a corrupted group policy that was preventing the DA setup wizard from completing.

• Marked as answer by Matt Br Monday, May 04, 2015 7:15 PM

Just to wrap this one up the issue turned out to be a corrupted group policy that was preventing the DA setup wizard from completing.

• Marked as answer by Matt Br Monday, May 04, 2015 7:15 PM

Just to wrap this one up the issue turned out to be a corrupted group policy that was preventing the DA setup wizard from completing.

• Marked as answer by Matt Br Monday, May 04, 2015 7:15 PM