Setting up three Windows 2008R2 servers in similar configuration to the DiretAccess Getting started guides and the Test lab for DA docs. I have DA talking to the DC, DA talking to the FS (App1) and the client is able to access the resources of the servers on the intranet side. When the client is Outside the network, I can access the webpages of the DA and ping the DC via 2002: ISATAP addresses. I can't ping the DA or the FS from outside the intranet. The nls record is on the FS, the crl is published to the DA on the intranet side and an A record is published at the domain registrar's records. Inside the network (intranet) I can ping IPv4 and IPv6 fe80: and 2002: from servers to servers, servers to client and client to servers. Using the DA Connectivity Assistant tool, probes are: Ping: 2002:42xx:70xx:1:0:5efe:c0a8:6507 (DA server) and File: \\2002:42xx:70xx:1:0:5efe:c0a8:6507\test\Example.txt. DTE List: Ping: 2002:42xx:70xx:1:0:5efe:c0a8:6507 Inside connectivity passes tests, outside connectivity fails the File: test and passes the Ping: tests.

If you haven't already, definitely check out this link: http://technet.microsoft.com/en-us/library/ee624058(WS.10).aspx I follow it all the time and 99% of the time I figure out the issue between step 5 and 16. You said you can't ping the DA or the FS from outsite of the network, but you can the DC? I'd start with that. Have you tried by name and IPv6? What address are you getting on the client, 6to4, teredo, or IP-HTTPS? You can see this by running an ipconfig /all and looking at the adapter that has a network address. I'm assuming you're trying to access a file on the FS for the file test (I see the IPv6 address above) so I'm wondering if because it fails the ... Oh wait...I wonder if you just have the infrastructure tunnel setup but not the intranet tunnel. Check this link out too: http://technet.microsoft.com/en-us/library/ee844114(WS.10).aspx ...and in this article make sure to check this out (certificate type stuff): http://technet.microsoft.com/en-us/library/cc737812(WS.10).aspx I hope this helps!

Hi Customer, Please check your DA client status in Internet subnet (outside the network) with command like "netsh dnsclient show state", "netsh namespace show effectivepolicy" mentioned in DA troubleshooting article. Post the abnormal command result and "IPconfig/ all" result to us. Troubleshoot DirectAccess http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0f049be7-8842-4c9d-9929-e0493b599319&displayLang=enRegards, Rick Tan

Going thru the (WS.10) doc was showing inconsistent results during initial troubleshooting. Seems that sometime during my troubleshooting for the past few days, the DA server lost connection with the DC server. So I started re-entering the DA configuration and verifying the connection to the DC server. During my resetting of the parameters for the DA configuration (applying the same settings that worked before) the DA monitoring page kept showing an X in the DNS row. Then I noticed that the DA server configuration was requesting the SUFFIX of the server whereas I was putting the full server URL in that DNS field. So I was using the DC1.domain.com address before and it was working. But for some reason it decided to stop working. So I entered the domain.com suffix, verified connectivity to the DC server, saved and applied the changes and DA server was working to the DC server. Or so I thought... Back to step three of the WS.10 doc, Verified my GP got applied to the DA server, but now my client workstation lost access to the DA and the rest of the system on both the LAN and WAN side according to DA Connectivity Assistant. Gotta change my GP on that now. Two steps back, one step forward... Still plugging away.

Windows IP Configuration Host Name . . . . . . . . . . . . : ST41 Primary Dns Suffix . . . . . . . : SCFD4.ORG Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : SCFD4.ORG PPP adapter Verizon Wireless - VZAccess: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Verizon Wireless - VZAccess Physical Address. . . . . . . . . : DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 70.197.22.208(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : 0.0.0.0 DNS Servers . . . . . . . . . . . : 66.174.92.14 66.174.95.44 NetBIOS over Tcpip. . . . . . . . : Disabled Wireless LAN adapter Wireless Network Connection: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Meridian2.local Description . . . . . . . . . . . : Intel(R) WiFi Link 5300 AGN Physical Address. . . . . . . . . : 00-21-6A-B9-0E-9E DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Ethernet adapter Local Area Connection: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : scfd4.org Description . . . . . . . . . . . : Intel(R) 82567LM Gigabit Network Connection Physical Address. . . . . . . . . : D8-D3-85-9B-80-12 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Tunnel adapter isatap.{34A07BE3-C2F4-4643-8C36-014B80FBEFD5}: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::200:5efe:70.197.22.208%19(Preferred) Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 66.174.92.14 66.174.95.44 NetBIOS over Tcpip. . . . . . . . : Disabled Tunnel adapter isatap.Meridian2.local: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Tunnel adapter isatap.scfd4.org: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter #4 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Default Gateway . . . . . . . . . : NetBIOS over Tcpip. . . . . . . . : Disabled Tunnel adapter 6TO4 Adapter: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft 6to4 Adapter Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2002:46c5:16d0::46c5:16d0(Preferred) Default Gateway . . . . . . . . . : 2002:42ef:7032::42ef:7032 DNS Servers . . . . . . . . . . . : 66.174.92.14 66.174.95.44 NetBIOS over Tcpip. . . . . . . . : Disabled Tunnel adapter Teredo Tunneling Pseudo-Interface: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2001:0:42ef:7032:24d0:60d:b93a:e92f(Preferred) Link-local IPv6 Address . . . . . : fe80::24d0:60d:b93a:e92f%21(Preferred) Default Gateway . . . . . . . . . : NetBIOS over Tcpip. . . . . . . . : Disabled Tunnel adapter iphttpsinterface: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : iphttpsinterface Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Name Resolution Policy Table Options -------------------------------------------------------------------- Query Failure Behavior : Always fall back to LLMNR and NetBIOS if the name does not exist in DNS or if the DNS servers are unreachable when on a private network Query Resolution Behavior : Resolve only IPv6 addresses for names Network Location Behavior : Let Network ID determine when Direct Access settings are to be used Machine Location : Outside corporate network Direct Access Settings : Configured and Enabled DNSSEC Settings : Not Configured DNS Effective Name Resolution Policy Table Settings Settings for .scfd4.org ---------------------------------------------------------------------- Certification authority : DC=ORG, DC=SCFD4, CN=SCFD4-SCFD4-DC1-2K8-CA DNSSEC (Validation) : disabled IPsec settings : disabled DirectAccess (DNS Servers) : 2002:42ef:7032:1:0:5efe:192.168.101.3 DirectAccess (Proxy Settings) : Bypass proxy

Holy Cow!! While generating the text for the above request, I had the client on the WAN link, and just for S&G I decided to save the file to the FS server via the WAN link, figuring What the Heck... Lo and behold, the dang thing showed up on my list from the start line. IE: \\FS1\resource and I copied the file to the file server!!! Just goes to show that head banging on the wall does sometimes pay off. Now I'll run thru the remainder of the troubleshooting steps just to make sure that this wasn't a glitch. Bob

Ok Rick, now I'm just stumped! Here's the latest. Had the client accessing the resources on the Intranet properly after I reset the DA server's configuration as noted earlier (suffix, not FQDN), restarted the DC partly just because and partly because of DA inability to ping DNS names. So, client is accessing resources via DA connection. Log my results from the "General Methodology for Troubleshooting DirectAccess Connections" article, disconnect the DA connection and plug in the LAN connection inside the Intranet. I was expecting to have access to the intranet resources again, but the DA Connectivity Assistant tool shows a big red X on the icon. So I look at the logs. Corporate connectivity is now working it says. Fails on accessing the FILE test, but passes the PING tests. So I manually browse on the client to where the FILE is located via Windows Explorer, and it's there in all it's glory. Start of scratching my head. So i run thru the troubleshooting instructions and get to Step 8 where the client must determine if it's inside or outside the network, and sure enough it thinks it's outside the network. So this is where it gets screwy. The LAN adapter has determined that it's on a "WORK" network, not the domain which is was before I connected to the DA connection. I can't get it to switch no matter what troubleshooting I do. I've even gone so far as to remove the route 0.0.0.0 as described in another forum here, but that just switches it into a "Public" profile. So last resort I un-join the domain, reboot, re-join the domain, reboot and all is fine. I'm on the Domain connection via the LAN, all tests pass with the troubleshooting article. Then I disconnect the LAN, atttach the DA connection (Verizon phone with data plan), look at my DA tool and it says I'm connected to the Intranet properly. Sure enough I can access the FS, DC and DA shares with no problems. Ran thru the troubleshooting article to confirm all steps are good and log the results. Then I disconnect the DA connection, plug inn the LAN connection again, hoping that it'll work and notice the BIG RED X again on the DA tool. Now for more head scratching. Looking at my LAN adapter, once again it's back to showing "Work" instead of "Domain". I can't help feeling that I'm close, but this ones got me stumped. I know that it's not seeing the DC for the NLS record resolution, but why? What would cause the client to be good on the domain at first, good on the DA side of the domain, then loose it on the reconnect to the LAN side? I have tons of logs if you would like to sift thru them. Bob

Additional note: if I reconnect to the DA side, access to the intranet resources is available again. Seems that the DA is working, just the disconnect and LAN goes sideways. Bob

Hi Bob, I guess it maybe something else wrong with your DA configuration cause this phenomenon. From your description, "The nls record is on the FS, the crl is published to the DA ". According to DA two guide, there are two crl published from DC, crl.corp.contoso.com(for Internal, Internet, Homenet with teredo) and crl.contoso.com (for Homenet with IP-HTTPS) Please ensure nls.SCFD4.ORG record point to FS IP in internal DNS server, Please ensure crl.SCFD4.ORG published to FS server, crl.SCFD4.ORG CRL shared on FS server, IIS website bind nls.SCFD4.ORG on FS server. Please ensure crl.(not SCFD4).ORG published to DA server, crl.(not SCFD4).ORG CRL shared on DA server, IIS website bind IP-HTTPS FS.(not SCFD4).ORG on DA server. Regards, Rick Tan

Thanks for the update Rick, Ok. Might be some wording going on here that is confusing me. The DNS is on the DC server. DNS has records for crl.scfd4.org pointing to the DA server and nls.scfd4.org pointing to the FS server. Internally if I ping crl or nls they resolve to the aformentioned servers. These are also only setup with IPv4 addresses. "Please ensure crl.SCFD4.ORG published to FS server," The best practices guide for setting up the "Test Lab" environment refers to publishing the crl to the APP1 (FS) where the DA Configuration Guide refers to the crl being published to the DA server. Do I need the crl published to both or just one, and if so, which one? " crl.SCFD4.ORG CRL shared on FS server" Same question. Both or just one? CRL is published to the DA server currently per DA Configuration Guide. My understanding is that the CRL has to be seen on the internet for revocation as well as internally on the DA intranet side for the same purpose. In my case the crl is on the DA server in c:\CRLDist with the $ for hidden share per DA docs. I then have the DC point to the DA with the crl.scfd4.org to the IPv4 address of the DA server. Outside I have a crl.scfd4.org at the registrar (where our other records are at) pointing to the first consecutive external IP for our DA pipe. Am I understanding this properly? " IIS website bind nls.SCFD4.ORG on FS server." The FS does have the nls.scfd4.org bound on the 443 port per documentation. " Please ensure crl.(not SCFD4).ORG published to DA server, crl.(not SCFD4).ORG CRL shared on DA server, IIS website bind IP-HTTPS FS.(not SCFD4).ORG on DA server." If I'm understanding you, the "not SCFD4" would put crl.org on the DA server? How's that going to resolve? IIS bind IP-HTTPS only shows the DA server as one with a certificate. It's not installed though. No 443 binding is done at this time. Do I need to create an IP-HTTPS cert on the FS server, publish it and attach it to the DA IIS for binding to get something to work? Once the DA client is connected at this time, the server resources are available to the client from the FS thru the DA connection. Since this should be a End-to-Edge configuration, isn't the IP-HTTPS from the FS to the DA unnecessary? Thanks for your time. Bob

Hi Bob, Sorry for my unclear expression and any inconvenience it has brought. First, for the two guides (Test lab guide and DA guide), every step needs to be configured during DA deployment. Like two crl, two crl share. Second, internal DNS records crl.corp.contoso.com point to APP1 IP in test lab guide, external DNS records crl.contoso.com(not crl.corp.contoso.com) point to EDGE1 IP in DA guide. So I meant to say that crl.(not SCFD4).ORG could be crl.da.SCFD4.ORG or crl.vpn.SCFD4.ORG. You need to set up related DNS zone on external DNS Server INET1(ISP) and add external crl DNS record. Third, in DA setup wizards step3, Network Location server points to nls.corp.contoso.com (App1 server). NL server is separated from DA server for high performance, so crl and crl share should be on App1 server. App1(FS) obtains an additional certificate and binds HTTPS website mentioned in DA guide step4. At last, crl.(not SCFD4).ORG and IP-HTTPS related setting on DA server just do work when Homenet without NAT scenario. You could skip configuring them first and just configure IP-HTTPS certificate in DA setup wizards. Test Lab Guide: Base Configuration http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=ab6c61af-9c34-4692-815c-4396b482d31b Test Lab Guide: Demonstrate DirectAccess http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=8d47ed5f-d217-4d84-b698-f39360d82fac Regards, Rick Tan

Thanks for the clarification Rick. Going thru the guides again step by step again in order this time and correcting my missteps. Quick question. Since my internal suffix matches the outside suffix, will the CRL pointing to the inside FS conflict with the outside CRL pointing to the external DA connection on the Internet from the DA clients point of view? Will the NLS record prevent this confusion? Thanks again, Bob

Update for you Rick, Ok so I installed the missing crl distribution setting for the \\fs1\crldist$ on the DC. Changed internal DNS record for CRL to point to FS, not DA as before. Added the FS IIS CRLD virtual dir and pointed to C:\CRLDist on the FS. Bound the FS with the HTTPS certificate. Created the CRLDist$ share, set the DC with allow Full Control on share and security permissions. Published CRL's from DC to FS and verified existance of CA and CA+ on FS. Question: I noticed that the SSL certificate on the FS was only valid for 1 year. Does that mean in 1 year time I'll have to regenerate the SSL for the FS? Since the computer certificate setup on the DC in previous steps does Auto-Enrollment, will this be taken care of by the DC/FS automatically? While configuring the crl entries in the DA Guide I finally noticed the ever so slight difference in the http:// line. One has the crl.CORP.contoso.com entry for the Base configuration and the other has crl.contoso.com entry for the DA configuration. No CORP entry on the DA guide. Didn't even see it the many times i read it. Now what you posted makes sense. Wasn't sure which one of lost their mind on that statement! ;-) Disregard my previous post about the crl being the same now. I understand. Thought that since the base configuration had listed that CRL distribution settings already, the DA guide was rehashing the same information. Guess I needed a finer tooth comb. My bad. NLS was already pointing to FS. Published an external crl.da.scfd4.org DNS zone record at the registar's records as recommended. Gotta love it, while redoing step 3 in the DA setup wizard where you set the nls location, I had previously used http: vs https:. That's another one that might have bit me later. Oh Happy Day!!! It bloody works. Inside tests work perfectly, outside Internet tests work perfectly, reconnecting to the LAN and the Domain shows up as the active network connection again. DA Connectivity Assistant works perfectly. Only test I can't do here is the home net tests. Thats for this weekend, at home. Thanks again for another set of eyes. Now Excedrin can make their money off of some other poor soul. Bob.

Hi Bob, According to the DA guide, the SSL certificate on FS has 2 year validity period based on web server certificate template. The auto-enrollment policy has setup is for computer template certificates. You could setup certificate auto-enrollment via another group policy for all certificate renewal. Configure Certificate Autoenrollment http://technet.microsoft.com/en-us/library/cc731522.aspx Regards, Rick Tan