Microsoft recently announced the availability of Windows 8.1 Enterprise preview. If you’ve downloaded the software to evaluate DirectAccess, you may be wondering where the DirectAccess connection properties have gone. In Windows 8, the DirectAccess connection properties can be accessed by pressing Window Key + I, clicking the active network icon, and then right-clicking Workplace Connection.
To access the DirectAccess connection properties in Windows 8.1, press Window Key + I, click Change PC Settings, and then click Network.
Highlight Connections and click Workplace Connection.
miles267
/ October 19, 2013Sadly Win 8.1 Enterprise appears to break DirectAccess connectivity. A Win 8 Ent PC with working DirectAccess can no longer establish a DA connection when 8.1 Ent installed.
Richard Hicks
/ October 21, 2013Are you saying that upgrading to Windows 8.1 broke DirectAccess connectivity for you?
miles267
/ October 21, 2013Correct. After upgrade, the DirectAccess network connection config was still present but hung on a “connecting” status when attempting to connect to the Windows Server 2012 Essentials R1 DirectAccess server.
Upon rolling the Win 8.1 Ent PC back to a previous client backup to Win 8 Ent, DA connectivity was restored.
Even a clean install of Win 8.1 Ent to same PC (not an upgrade) and joining to the domain successfully received the client Directaccess config, however it too hung at connecting status.
MC
/ October 22, 2013Seems to me that with the 8.1 release, I can no longer right click on the DA icon to turn on the “use local DNS resolution” option. Is another piece of software needed for that?
Richard Hicks
/ October 26, 2013No, I think where you select that option in Windows 8.1 has changed. Read this… http://directaccess.richardhicks.com/2013/08/14/windows-8-1-directaccess-connection-properties/
MC
/ October 26, 2013You added a link back to this same blog post 🙂
I don’t see where I can select “use local DNS resolution”.
Richard Hicks
/ November 6, 2013Sorry about that. 😉 I’ll do some investigating and get back with you…
Richard Hicks
/ November 6, 2013Ok, had to spin up a Windows 8.1 DirectAccess client to double check for you. To use local name resolution, hit Window Key + I and click your active network connection. Click on your DirectAccess connection and click “Disconnect”. 🙂
Ambers
/ October 24, 2013Mine was working for 4 days after the upgrade and stopped last night. Troubleshooting now. Any upgrade requirements for the DA servers? 2012 R2?
Richard Hicks
/ October 26, 2013No. Windows 8.1 clients work with Windows Server 2012, and Windows 8 clients work with Windows Server 2012 R2.
Jeffrey Peters
/ November 15, 2013I had the same issue and it turned out to be that the on the Windows 8.1 upgrade the certificates issued for client authentication stop working. I deleted them out of the Personal store for the Machine and then re-enrolled. Everything started working immediately after that.
miles267
/ November 15, 2013Can you provide instructions on how to do this? Specifically where and which to delete as well as how to re-enroll? This is very intriguing.
Jeffrey Peters
/ November 15, 2013You will need to be on the corporate LAN to do this and have all of the PKI requirements completed for DirectAccess.
From the computer, open an mmc console as administrator
Add the snap-in Certificates
When the dialog pops up and says “This snap-in will always manage certificates for:”
Select Computer account
On the next screen, make sure local computer is selected.
Expand Certificates -> Personal -> Certificates
Delete the certificate that is based off of the certificate template “DirectAccess IPsec Client”
Right click on the Certificates folder in the mmc under Personal.
Select All Tasks -> Request New Certificate
On the second screen, make sure Active Directory Enrollment Policy is selected and click next.
On the next screen checkmark DirectAccess IPsec Client and click enroll.
This should create the certificate for you. This fixed my specific scenario, but yours may be different.
Richard Hicks
/ November 15, 2013Are you using self-signed or PKI-issued certificates?
Jeffrey Peters
/ November 15, 2013I am using PKI assigned certificates. The upgrade from 8 to 8.1 seems to have invalidated them. This was the only change that I performed on the upgraded machine and it fixed access.
Richard Hicks
/ November 15, 2013Got it. The certificate template names are unique to your deployment then. Just an FYI for those reading this thread who don’t see a certificate template named “DirectAccess IPsec Client”. 🙂
Ambers
/ October 25, 2013After upgrading Servers to 2012 R2 instead of getting a “can’t connect to DirectAccess server” message I have reached the “can’t connect to network resources” error. DNS isn’t resolving anything. Pressing on.
Ingvar
/ October 25, 2013I’ve got the same thing here with 5 different machines. 3 fresh installs and two upgrades. I get the following error message: Error: Corporate connectivity is not working. Windows is unable to resolve DNS names for probes.
Nothing has changed on the DA server (running Server 2012) and it’s still working for Windows 8 and 7.
Richard Hicks
/ October 26, 2013Interesting. I’ve not performed any testing with clients that have been upgraded. Can’t imagine why that shouldn’t work, however. When I get some time I’ll conduct some testing to confirm.
Ingvar
/ October 31, 2013So after monkeying about for a few hours last night I finally figured out why Direct Access broke when I upgraded to Windows 8.1.
On the Group policy object that contains the direct access settings there was a WMI filter set saying that only laptops should be affected by the group policy. Also inside of this filter it seems to me that it’s filtering out which versions of windows should be included.
Filter looks like this:
Select * from Win32_OperatingSystem WHERE (ProductType = 3) OR (Version LIKE ‘6.2%’ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 72 OR OperatingSystemSKU = 84)) OR (Version LIKE ‘6.1%’ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 70 OR OperatingSystemSKU = 1 OR OperatingSystemSKU = 28 OR OperatingSystemSKU = 71))
As I don’t really need the filter for laptops only I just removed the filter and now Windows 8.1 Direct Access works.
I assume that somewhere during the installation there was an option to turn this on and probably some other settings (I can’t really remember), one this is for sertain I did not write that filter cause that I would have remembered.
Bartpe
/ November 2, 2013Testing Win To Go with a new Win81 corp image. Seem to have the same issue as Miles267. Client stays in “connecting” status. No access to corp resources.
DMS
/ February 19, 2014Did anyone manage to resolve this. I am also encountering the same issue
Steff
/ March 26, 2014Same issue here. New Windows 8.1 installations all stuck in the “connecting” state. GPO is applied, but DNS resolutions do not work.
The same settings work fine for Windows 7 machines.
Steff
/ April 1, 2014Replying to my onw post…
It looks like McAfee VirusScan Enterprise (8.8.0.1247) was the culprit. This was added at staging time to the machine. By removing VSE the client was able to connect without issue. Moreover reinstalling VSE and still everything is fine…
MC
/ March 27, 2014What I’ve noticed is that you need to change one of the IPSec services as it is set to Manual. I can’t remember right now and I’ll have to provision a new one to confirm but it was either IPsec Policy Agent or the IKE and Auth… service.
MC
/ March 27, 2014Got a chance to test. The service is “IKE and AuthIP IPsec Keying Modules” and by default it is set to “Manual (Trigger Start). I had to change it to “Automatic”.
Hamilton
/ June 14, 2014Hello everyone,
Has anyone figured this Windows 8.1 Ent continuous “connecting” status? On the client when I use the DA connectivity tool I get: Error: Corporate connectivity is not working. Windows is unable to contact some remote resources due to network authentication failure.
All resources are available. I uninstalled virus scan app and the “IKE and AuthIP IPsec Keying Modules” is set to automatic as suggested.
Why cant Microsoft fix these things?
Thanks!!!
Richard Hicks
/ June 22, 2014This usually happens because the web probe host URL is not reachable via the DirectAccess tunnel. Make sure the name resolves correctly and that it can be reached via the DirectAccess tunnel. The DirectAccess client troubleshooting tool might also shed some light on this.
Greg Melnyk
/ September 10, 2014Spent a couple of hours working on this last night (unable to resolve DNS). It looks like the Windows firewall needs to be turned on on the server.
Richard Hicks
/ September 15, 2014Absolutely. The Windows Firewall must be enabled on both the client and the server. The IPsec connections are established using the connection security rules of the firewall.
Michael
/ November 11, 2014Hello! I have the same problem, Win 7 and Win8 working perfect, but Win 8.1 not working with DA 2012 R2, only says “Connecting” when i do cmdlet in powershell: Get-DAConnectionstatus: I get: Error, Could not contact DA Server… I have spent Hours of troubleshooting, DA 2012 R2 server is mac updated also the win 8.1 client what can be a problem?
Richard Hicks
/ November 21, 2014That is certainly puzzling. You’ve confirmed all the prerequisites? Are you able to get an IPv6 address on one of the transition interfaces? Are there any IPsec SAs established at all?
harveyharpal
/ November 17, 2014I’ve got Direct access working for a mixed client environment (win 7 and win 8). Then we implemented OTP/RSA and everything works fine on windows 7 but on windows 8.1 enterprise I cant seem to find the “DA media manager” to enter the otp. Cant right click on the connection either. Any one got any tips?
Thanks
harveyharpal
/ November 17, 2014I’ve got Direct access working for a mixed client environment (win 7 and win 8). Then we implemented OTP/RSA and everything works fine on windows 7 but on windows 8.1 enterprise I cant seem to find the “DA media manager” to enter the otp. Cant right click on the connection either. Any one got any tips?
Thanks
Richard Hicks
/ November 21, 2014In Windows 8.x I believe you get a notification in the system tray. I don’t do many DirectAccess deployments with OTP, so it’s been a while since I’ve tested.
Stewart Hamblet
/ January 29, 2015For those that are having issues with DirectAccess connecting to network resources, troubleshoot your tunnels be it IPSEC, Toredo or 6to4. Most of the time it is down to improperly configured DA server firewalls, check the profile your connection security rules apply and ensure that firewall profile is on.
Richard Hicks
/ January 29, 2015Thanks for the tip, Stewart! DirectAccess has a lot of moving parts, and when it doesn’t work it is important to understand in detail how the DirectAccess connection is established. This includes the IPv6 transition protocols and IPsec. And yes, the Windows firewall is a critical piece that is often overlooked. 🙂
miles267
/ January 29, 2015Has anyone else experienced intermittent connectivity between Windows 8.1 Enterprise DA client and the server? Am experiencing this periodically with my DA client where it shows Workplace Connection “Connecting” but is resolved by rebooting the DA client.
Richard Hicks
/ January 29, 2015Interesting. When the DCA reports “connecting” do you actually have DirectAccess connectivity at the time?
Ryan Schauer
/ September 1, 2015Did you ever figure this out? We are having the same exact problem. And to answer Richard’s question, we do not have DA connectivity when in the “connecting” state.
Vali Basha
/ April 24, 2015Richard, Please help me to resolve one of the strange issue, I am struggling from last 1 year, I have raised a call with MS but no luck. My issue is NAT64 going unhealthy state randomly, again after some time it comes to healthy. We set up is multisite, 7 servers at one region and 4 servers at other, My set up is Behind an edge device with 2 network cards. Please help Richard.
Richard Hicks
/ April 27, 2015I can’t imagine what would be causing the NAT64 service state to report as unhealthy. The only thing I can suggest is that you ensure that your DirectAccess servers are completely up to date. Also, be sure that any and all DirectAccess and remote access related hotfixes that pertain to your OS version are installed. You can find a list of recommended hotfixes here: https://support.microsoft.com/en-us/kb/2883952/.