DirectAccess has been with us for quite some time know, having been originally introduced with Windows Server 2008 R2, later enhanced with Forefront Unified Access Gateway (UAG) 2010, and finally integrated in to the base operating system in Windows Server 2012 R2. Client support for DirectAccess begins with Windows 7 (Enterprise or Ultimate), and also includes Windows 8.x (Enterprise) and Windows 10 (Enterprise or Education).
Although Windows 7 clients are supported for DirectAccess, Windows 10 is highly preferred. Here are three important things you need to know about using Windows 10 with DirectAccess.
- Windows 10 Provides Improved Performance and Scalability – Windows 10 includes support for null encryption when using the IP-HTTPS IPv6 transition protocol. This eliminates the needless double-encryption performed by Windows 7 clients, and dramatically reduces the protocol overhead for clients connecting behind port-restricted firewalls. DirectAccess servers can support many more concurrent IP-HTTPS sessions with Windows 10, and it has the added benefit of making the more secure perimeter/DMZ deployment behind an edge security device performing NAT much more attractive.
- Windows 10 Supports Geographic Redundancy – Windows 10 includes full support for DirectAccess multisite deployments. Where Windows 7 clients had to be assigned to a single entry point, Windows 10 clients are aware of all entry points in the organization. They are able to automatically select the nearest entry point on startup, and transparently failover to another site if the current site becomes unavailable.
- Windows 10 Features an Enhanced Management Experience – From a troubleshooting and support perspective, Windows 10 makes things much easier. The DirectAccess connectivity assistant, an optional component for Windows 7, is now fully integrated with the Windows 10 UI. PowerShell is greatly improved and now includes many native DirectAccess configuration and troubleshooting commands.
As you can see, there are a number of significant advantages for using Windows 10 with DirectAccess. Windows 10 now supports all of the enterprise features of DirectAccess, including geographic redundancy and performance and scalability improvements. Windows 10 is also easier to troubleshoot and manage. If you’re still supporting Windows 7, DirectAccess in Windows Server 2012 R2 can certainly support them. However, without a doubt the best experience, both from an administrator’s and the end user’s perspective, is with Windows 10. Just one more reason to begin planning your migration to Windows 10 with DirectAccess today!
Need assistance with implementing DirectAccess with Windows 10? I can help! More details here.
Andy King
/ November 11, 2015I’m looking to test this out next week. I have da working with win 7 but never figured out why i couldn’t for windows 8.1. Are you are of any issues using computer certificates that use the md5-rsa algorithm?
Also I was put off using kerb proxy as a solution going forward, one of our partners suggested this is no longer the recommended method. Any views on this?
Richard M. Hicks
/ November 11, 2015As a general rule MD5 shouldn’t be used, but I’m not aware of it breaking DirectAccess on Windows 8 or later clients. It is possible, but I can’t recall having deployed DirectAccess without at least SHA1 in ages. With regard to Kerberos proxy, it does work but it limits deployment flexibility so I don’t recommend it. Also, I like the added security that certificate authentication provides. Makes for a much more secure solution overall that way.
[email protected]
/ November 12, 2015We are using DA Server 2012 R2 with Windows 10 Clients. It is working very good. Based on your article, I have two questions:
You are talking about improved PowerShell commands on Win10 clients. Do you have more details on that? Is there already a documentation from MS about available commands?
Second question: Do you have any information about a new/updated version of the DA Troubleshooting tool? It is working fine on Win 8.1, but always crashes on Windows 10.
Richard M. Hicks
/ November 12, 2015Hi Sebastian,
For clarification, the new DirectAccess PowerShell commands were also included in Windows 8.x. This article was written with folks upgrading from Windows 7 in mind. I did outline some of those DirectAccess PowerShell commands here:
http://directaccess.richardhicks.com/2015/08/04/directaccess-and-windows-10-better-together/
Regarding the DirectAccess Client Troubleshooting tool, I don’t have any information on that. It’s a pretty rough tool and could certainly use some updating, but I’m not sure if/when that is going to happen. :/
toffitomek
/ November 20, 2015Hi Richard – brilliant blog, I find it very informative. I think one subject you may want to touch is struggle we have at the moment – how to obtain Windows Enterprise. There seems to be dozens of options and bundles (ECS etc.) that seems to make things very unclear, especially when you are mid-size business like we are – c. 240 seats. When you are big enterprise DA seems to be easy achievable, but for SMBs it is still huge struggle, so some kind of guide that would clarify, show in simple words ways to obtain Win Enterprise IMHO would be most welcomed.
Richard M. Hicks
/ November 24, 2015Hi Tomasz,
I’ll definitely give that some consideration. Thanks for the suggestion!
Frank van Rijt
/ January 11, 2016Since with the latest cipher updates Windows 7 also supports:
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
Would this bring any relief to have null encryption for Direct Access on Windows 7 clients using IP-HTTPS?
Richard M. Hicks
/ January 11, 2016I don’t think so, but I’ll look in to it. 🙂
Darmien
/ January 15, 2016Hi Richard – Where you say that windows 7 does not support the selection of an entry point and must be assigned to just one. Is this still the case when using a GSLB as my thoughts are that the GSLB decides where to send the traffic?
If not is there a good way to manage a site failure for Win 7 clients? if the site which the Win 7 clients connect to fails then the clients can no longer communicate to the network without the use of a VPN.
Thanks,
Richard M. Hicks
/ January 18, 2016The GSLB decides where to send the IPv6 transition tunnel traffic only. Within that tunnel, the client expects to be connecting to a specific IPv6 address, the one for its assigned entry point. If you swing the transition tunnel (easy enough with GSLB) the client won’t connect because the tunnel endpoint IPv6 address is not correct.
There really is no way to manage an unplanned entry point outage for Windows 7 clients. It if is a planned outage, you can move Windows 7 clients to another entry point by moving them to the security group for the new target entry point. Keep in mind they won’t receive the new settings until they restart and update group policy.
Damien
/ January 26, 2016Lets say that Multisite is not configured, but a cluster using a stretched VLAN across both datacentre’s is. If we point the clients to a GSLB which sends the traffic to either Datacentre’s public IP, which then forwards to the VIP of the cluster. Would this allow the clients to failover and support an Active/Active configuration?
Richard M. Hicks
/ January 26, 2016A cluster on a stretched VLAN will definitely work. If you’re going to do that, be sure to use an external load balalncer. NLB isn’t recommended when using streteched VLANs.
Darmien
/ January 20, 2016So if all Windows clients are being controlled through the GSLB in terms of where the traffic is being sent (site A or Site B). What happens when the GSLB decides to send a Win7 client to Site B when it was previously connected to A? Or does adding the Windows 7 Client to its own security group when setting up multi-site exclude it from going through the GSLB?
Richard M. Hicks
/ January 21, 2016You are correct. Windows 7 clients must be assigned to a specific site in multisite scenarios and are unaware of other sites. They don’t use the global address (FQDN), but the specific site’s FQDN.