Windows Server 2012: Direct Access causes name resolution problems

In this article I’d like to tell you about setting up my test Windows Server 2012 Direct Access server. Direct Access in the new version of Windows Server has been improved greatly and I was keen to implement it in my test lab. Let’s go through the full setup procedure step by step and see what can be the results.
For my tests i’m using a very simple configuration: the two MS Hyper-V virtual machines as the domain controller (dc.test.com, 10.3.5.1) and the member server (srv2.test.com, DA = edge type, local network adapter = 10.3.5.2 and “internet” network adapter = 130.1.1.1). The firewall on both servers are TURNED OFF (that’s why I won’t create ICMPv6 PING rules in a GPO). These two virtual machines will be enough to show you the problem I’ve been keeping bumping into for already a week.
  
Here is my DC configuration:  
  
Fig.1  AD01
Fig.2  DNS02
  
Fig.3  CA03
  
Fig.4  CA Properties04

Fig.5  GPO05

Now let’s look at DA server (srv2.test.com) settings before we start setting up Direct Access.

Fig.6  SRV2 CRLD virtual directory (used for checking crl, maps to \\srv2\crld as shown in Fig.4)06

Fig.7  SRV2 CRL share (\\srv2\crld)07

Fig.8  SRV2 certificates08

Fig.9  SRV2 Network Settings09

Fig.10  SRV2 Network Adapters10

“TEST” adapter is connected to the Test.com domain; “INTERNET” adapter simulates Internet.
Now when our infrastructure is ready for installing Direct Access I will run Network Monitor, start capturing packets, ping dc and make sure the name resolution works properly:

Fig. 11  Ping dc works correctly11

Fig.12 When pinging host “”DC” the server SRV2 requests the resolution of the name “DC.TEST.COM” on its configured DNS server (DC=10.3.5.1). The same process occurs when pinging any other host that is a member of the TEST.COM domain.12

Now we can move on to the Remote Access role installation. Let’s get started!

Fig.13  Starting the wizard13

Fig.14  Finishing the installation14

Fig.15  DA setup: post deployment configuration 115

Fig.16  DA setup: post deployment configuration 216

Fig.17  DA setup: post deployment configuration 317

Fig. 18 DA setup: post deployment configuration finishes successfully18

Now let’s run Remote Access Management Console, check the DA server’s operational status and try to ping the dc server once again:

Fig.19  RAMC19

Look! The installation of the DA server with the default settings HAS NOT affected the general name resolution process (I won’t publish here another screen shot of the NetworkMonitor as the ping dc ends up successfully). Please take note of the time when we first checked the operational status of the DA server.

 As you already may know the Direct Access setup wizard configures only mobile computers as the DA clients by default – that’s what I’d like to change in the real-world scenario. All I need to do is to switch to the configuration page of the Remote Access Management Console and uncheck the corresponding checkbox in the Step1 section:

 Fig. 20  Step 120

Fig. 21  Step 1 – Uncheck the checkbox “Enable DirectAccess for mobile computers only”21

Fig. 22  Step 1 – Applying changes22

If we return to the Operational Status window right now and ping dc we’ll see the following:

Fig. 23  RAMC still shows operational status as OK but the name resolution is already not working23

Forward from this moment (12:34 PM) no domain host names can be resolved on SRV2:

Fig. 24  There’s no DNS name resolution requests coming from this DA server (srv2.test.com) to the DC.TEST.COM 24-2

A few minutes later the Remote Access Management Console shows “Configuration Load Error”.

Fig.25  RAMC error25

Nevertheless, ip to name resolution still works correctly:

Fig.26  NSLOOKUP26

So DA server becomes unmanageable and there’s not much we can do to fix it. I know there are other DA configurations that works perfect but in my test lab this simplest DA configuration leads to the fatal error in 100% of cases! I’d like to have a clear understanding what’s the cause of this issue prior to deploying DirectAccess in my organization.

Download this article in doc format.

Advertisements

12 responses

  1. thekillerwolf@web.de | Reply

    Seems like a Certificate Error. In my case I test to change the CA in the direct access Configuration. After Loading the new settings and Refresh the Management, I got the same Error like you.
    So check out to have a clean CA distribution.

    greetz wolle

    1. Thekillerwolf, thank you for the reply!
      What settings do you mean? To load another certificate? Of course, I’ll try to check it, but in any case it would be rather strange given that DA wizard shows operational status as OK and does not detect the misconfiguration.

      Regards,
      Michael

  2. Hi Michael,

    Found the root issue ?

    1. Hi Robson,
      No… Frankly speaking I absolutely don’t want to deploy DA in my company: it has too much real and potential issues (not speaking of this one) that make all DA’s advantages useless (of course it’s my point of view) and I have no intention to change VPN to DA.

      I think a CA or a certificate problem (as thekillerwolf@web.de said) may be the cause of my issue, but the way DA server let me know that something is wrong makes me shiver: DA wizard passes all checks and says everything is OK, and just some minutes later starts complaining…but NOTHING can be done to fix it – at least I didn’t find a way other than a to rebuild it fresh. Either DA can’t properly analyze its configuration settings or the issue really appears just minutes after the correct setup. In any case I wouldn’t like to have a deployment that can fail anytime even when all its configurations show OK.

      Regards,
      Michael

  3. Hi Michael,

    I am facing the EXACT same issue on my test setup. My configuration is a follows. I have the following DCs –
    DC1.mydomain.local (GC, DNS, DHCP)
    DC3.mydomain.local

    I a server called memser1.mydomain.local which NOT a DC. This server is configured as the DA server. I am using the “Two network cards behind a NAT” setup. I have a NIC with a private IP address but connected to a router which has NAT enabled & the server is able to access internet through this interface. The other NIC is configured to be the interface for the internal network. I have a DHCP server running on DC1 which doles out IPv4 address (192.168.5.x range) & an IPv6 scope which doles out addresses in the FEC0:: range. I am using self signed certificates to keep matters simple. The remote access server itself is the NLS. I am using a simple internet page on DC1 as a resource for DA

    I configure the DA using the Remote access management tool. Everything goes through fine, but then BOOM, the DC1 is not accessible by any of the clients. The remote access management gives an error saying A domain controller for mydomain.local could not be reached. This is the case even though I have two DCs for this domain. I can’t make any sense of what is going on. I can’t even do a gpupdate /force on any of the clients. They simply don’t seem to be able to locate a DC. I found this article (http://support.microsoft.com/kb/2845152) & update ALL my machines with all the updates & patches. No luck.

    Does NOT seem to be a certificate issue. Why will I be unable to ping or gpupdate a DC due to a certificate?.

    1. Hi rihan,
      Thank you for sharing your test results!
      “Why will I be unable to ping or gpupdate a DC due to a certificate?.” – firstly, are you pinging a DC by namr or by ip? In my case the problem is caused by the name resolution process: it stops working after changing the DA setting (namely, unchecking ~”for mobile computers” checkbox).
      In any case it’s definitely a bug because (even if a certificate is wrong for some reason) all checks in a DA wizard are passed successfully.
      “Everything goes through fine, but then BOOM, the DC1 is not accessible by any of the clients.” -am I getting it right that the DC becomes inaccessible not only from the DA server itself but from the clients as well?

      Regards,
      Michael

      1. 1. I am able to ping the DC using it’s IP address from all the machines, but not using the hostname. This is true of all the clients & not just the DA server. No one is able to ping the DC using the hostname. I also had the mobile computers checkbox UNCHECKED on all the different attempts that I made.

        2. GPupdate from any of the clients also does not seem to work (even though I have 2 DCs). The command errors out stating that it could not find a DC for the domain.

        I am going to try to set it up with the NLS on a different server (not the DA server). Let me see how that would go through. Will keep you posted.

        Also do you know of any way of testing DA on a completely simulated network?. I mean, by not being connected to the internet at all in any way.

  4. Thank you rihan,
    Regarding the testing DA without Internet connection: I do my tests on the separate testing network that’s connected to my production network with a router. In this configuration this enterprise network serves as internet for the testing network.

    https://social.technet.microsoft.com/Forums/en-US/04a84f17-d5a9-4b63-8cb3-44886afa98be/direct-access-name-resolution-fails-after-unchecking-enable-da-for-mobile-computers-only-checkbox?forum=winserver8gen

    Regards,
    Michael

  5. Trenton Chance | Reply

    So did anyone fix this? I’m setting up DA for my company and it will work great for a while then I get the gpo issues and have to start from scratch. Doesn’t make any sense.

    1. Hello Trenton,
      “So did anyone fix this?” – Presumably yes, but I decided to keep away from Direct Access.

  6. The firewall must be enabled on the DA server, when you install the DA role. DA requires the firewall to be enabled.

    1. Hello Mike,
      Thank you for the suggestion!
      “DA requires the firewall to be enabled.” – if this is the cause of the problem DA installation should not have completed successfully, but the final checking had all setting displayed as OK.

      Regards,
      Michael Firsov

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: