For those who struggle with the problem:
Sometimes when a Windows8 client starts to connect to DirectAccess from the outside, you notice that the GUI show "Connecting" and will never connect.
But if you test to connect to your internal network resources, you'll notice that you indeed can connect to those internal resources. How come?
There are most likely 2 causes for this:
The icon you see, is actually the DCA (DirectAccess Connectivity Assistant) that is now built-in in Windows 8 and later. On Windows 7, you had to manually install it or deploy it with SCCM.
And DCA is not really needed, unless you need to support OTP on Windows7. You could do without, but of course that makes troubleshooting the clients much harder.
Alright, so DA is working, DCA is not.
Let us check what the DCA is checking. As the name indicates, it is purely an cosmetic connectivity check, unless you are using OTP. On of the things the DA wizard do when you setup DA, is to specify in Step 1 what DCA should check for.
And if you notice this screen:
You would see that the DA wizard adds directaccess-WebProbeHost.yourinternaldomain.local and creates an A record in DNS for this. This points to the same IP as your webprobe addresse (which is NOT your NLS server).
So if your Win8 client hangs forever connection to DA, it means that one of those tests here are failing.
In one case, a customer of mine had actually shutdown the DA server and the IIS server hosting the webprobe site for an extended period due to some internal maintenance. In that meant more then 7 days, which is the default scavenging interval if you have enabled scavenging in Windows Server 2008/2012. And the directaccess-WebProbeHost record has a lower TTL then this. So it meant that the A record was automatically deleted.
I just manually created a static A record in DNS for directaccess-WebProbeHost, so I made sure that it will never happen again.
Another reason, might be if you have enabled ELB with BIG-IP/Kemp or something similar. See the excellent blog of Richard Hicks for this scenario. http://directaccess.richardhicks.com/2014/08/12/directaccess-clients-in-connecting-state-when-using-external-load-balancer/
Sometimes when a Windows8 client starts to connect to DirectAccess from the outside, you notice that the GUI show "Connecting" and will never connect.
There are most likely 2 causes for this:
The icon you see, is actually the DCA (DirectAccess Connectivity Assistant) that is now built-in in Windows 8 and later. On Windows 7, you had to manually install it or deploy it with SCCM.
And DCA is not really needed, unless you need to support OTP on Windows7. You could do without, but of course that makes troubleshooting the clients much harder.
Alright, so DA is working, DCA is not.
Let us check what the DCA is checking. As the name indicates, it is purely an cosmetic connectivity check, unless you are using OTP. On of the things the DA wizard do when you setup DA, is to specify in Step 1 what DCA should check for.
And if you notice this screen:
You would see that the DA wizard adds directaccess-WebProbeHost.yourinternaldomain.local and creates an A record in DNS for this. This points to the same IP as your webprobe addresse (which is NOT your NLS server).
So if your Win8 client hangs forever connection to DA, it means that one of those tests here are failing.
In one case, a customer of mine had actually shutdown the DA server and the IIS server hosting the webprobe site for an extended period due to some internal maintenance. In that meant more then 7 days, which is the default scavenging interval if you have enabled scavenging in Windows Server 2008/2012. And the directaccess-WebProbeHost record has a lower TTL then this. So it meant that the A record was automatically deleted.
I just manually created a static A record in DNS for directaccess-WebProbeHost, so I made sure that it will never happen again.
Another reason, might be if you have enabled ELB with BIG-IP/Kemp or something similar. See the excellent blog of Richard Hicks for this scenario. http://directaccess.richardhicks.com/2014/08/12/directaccess-clients-in-connecting-state-when-using-external-load-balancer/
No comments:
Post a Comment