none
DirectAccess Client Manage Out Issues with Remote Control and DNS RRS feed

  • Question

  • We are testing out DirectAccess on 2016 in a lab and so far everything has been working pretty well. Clients are connecting in, getting GPO, accessing files shares, RDP works, etc. Inbound is great. However, outbound/manage out is proving to be a problem. I have gotten it to work a few times but it looks like I have DNS issues based on the behavior. In this scenario my manage out internal server is an SCCM system. I'd like to be able to remote control DA clients like we do internally.

    I have a 2 NIC DirectAccess server in the DMZ. We NAT to the DMZ interface, 443 inbound. The interface also holds the default gateway (second NIC is blank on the gateway). It's configured to use certs + AD auth. We're not doing force tunnel (yet). My infrastructure server is the SCCM server in question. I have specified my internal domain search suffix as well. We have an NSL web server running internally as well.

    For the manage out clients I have configured ISATAP using a DNS alias + GPO to enable it on the SCCM server. This appears to be working for the most part but this is where it gets murky.

    I bring my DA system online. It registers in DNS on the domain controllers with the IPv6 address. At first I am completely unable to ping that system from SCCM. If I do an NSLOOKUP <client host name>. It resolves (doesn't matter if I use the host name or FQDN for nslookup). If I ping that hostname it will fail. If I ping the FQDN AFTER doing an NSLOOKUP it fails on the first attempt. If I ping it a second time it responds. This second ping situation happens pretty consistently. Sometimesafter pinging the FQDN successfully I can then ping the host name. If I leave it for awhile (15-30 minutes) I won't be able to ping anymore. I can then do the nslookup and repeat the process. Like there's some odd failure to cache long term. See below;

    At this point it is very hit or miss if I will be able to remote control the client from SCCM. But one thing is consistent, if I remote control the host name it fails. If I manually type in the FQDN using the File > Connect option it generally work. That's why I don't believe it's firewall related. Though I have turned on logging dropped packets on the client just in case.

    I saw this similar post but it dead ended. This gentleman was having a very similar remote control + FQDN issue.

    I feel like we're close but need some help getting this last bit of DNS weirdness sorted out. Thanks in advance for any feedback.

    Tuesday, May 9, 2017 2:33 PM

Answers

  • Hi,

    There's an issue when using a manage-out computer running Windows 10 / Windows Server 2016.
    To fix it, open an elevated PowerShell command window and run the following command:

    New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\" -Name AddrConfigControl -PropertyType DWORD -Value 0 -Force


    Gérald

    • Marked as answer by 00Shep Monday, May 15, 2017 2:35 PM
    Monday, May 15, 2017 9:15 AM

All replies

  • Hi,

    There's an issue when using a manage-out computer running Windows 10 / Windows Server 2016.
    To fix it, open an elevated PowerShell command window and run the following command:

    New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\" -Name AddrConfigControl -PropertyType DWORD -Value 0 -Force


    Gérald

    • Marked as answer by 00Shep Monday, May 15, 2017 2:35 PM
    Monday, May 15, 2017 9:15 AM
  • Thanks Gerald! My testing has been limited but so far this looks promising. 2 things;

    1. I was struggling with what I thought was a different issue. Mapping drives wasn't working properly on the client. We use DFS for a few drives that did map and a direct map on home drives to the server name. That home drive mapping failed because I couldn't ping the file server consistently. So I decided to add your DWORD on the client and that issue appears to be resolved.

    2. I added this to the server and I was immediately able to ping the client via NETBIOS name and FQDN from my SCCM server.

    I've noticed that DNS registration takes a few minutes so be patient when testing. I had to flushdns a few times to move things along.

    Remote Control continues to be a problem. It only works when using the FQDN. It doesn't seem to be able to handle NETBIOS + IPv6 as I pointed out with that other similar thread. Does anyone have any way to get Remote Control working this way??

    Monday, May 15, 2017 2:34 PM
  • I'm still having some issues with name resolution from my DA client. It seemed like the AddrConfigControl entry fixed the client at first. However, I've noticed a couple of things today;

    1. The value was missing this morning and I had to replace it. There are other entries for DA in the parameters key. I'm guessing that change to the DA GPO cause that key to be rewritten. If so, it's going to make it tricky to keep DNS working properly.
    2. Even with the value, I lost access to my home drive while connected to DA. I did an ipconfig /flushdns and it started working again.

    It just seems a little finicky and I'm not sure where to look as it is working for the most part.

    Update: I did find references to having to do ipconfig /flushdns periodically. Apparently there are other cache parameters in the same key as AddrConfigControl. I'm going to do some testing with MaxCacheTtl and MaxNegativeCacheTTL. Hopefully one of those will eliminate this. I've been connected all morning and randomly dropped RDP sessions to 3 different servers and lost my home drive for a bit. /flushdns fixed it each time.

    Shep


    • Edited by 00Shep Thursday, June 1, 2017 2:50 PM
    Thursday, June 1, 2017 2:22 PM
  • Worked with Microsoft support and they confirmed my suspicion. MaxNegativeCacheTTL was required to prevent the client from going into a 15 minute delay resolving addresses. It fails the first attempt. Caches a negative response. Doesn't try again for 15 minutes. So basically drives would fail to map and scripts/home drives don't retry. I did also need AddrConfigControl on the client. So now I have a GPO that sets both values to "0".
    Tuesday, June 13, 2017 1:22 PM
  • Thank you all so much for posting the issue and posting the solution.  Huge fix and win, thanks!!!!
    Friday, January 24, 2020 1:09 AM