3 Important Things You Need to Know about Windows 10 and DirectAccess

DirectAccess and Windows 10 - Better TogetherDirectAccess 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.

  1. 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.
  2. 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.
  3. 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.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

DirectAccess in Windows Server 2012 R2 supports many different deployment configurations. It can be deployed with a single server, multiple servers in a single location, multiple servers in multiple locations, edge facing, in a perimeter or DMZ network, etc.

Global Settings

There are a number of important DirectAccess settings that are global in scope and apply to all DirectAccess clients, such as certificate authentication, force tunneling, one-time password, and many more. For example, if you configure DirectAccess to use Kerberos Proxy instead of certificates for authentication, Windows 7 clients are not supported. In this scenario it is advantageous to have a second parallel DirectAccess deployment configured specifically for Windows 7 clients. This allows Windows 8 clients to take advantage of the performance gains afforded by Kerberos Proxy, while at the same time providing an avenue of support for Windows 7 clients.

Parallel Deployments

To the surprise of many, it is indeed possible to deploy DirectAccess more than once in an organization. I’ve been helping customers deploy DirectAccess for nearly five years now, and I’ve done this on more than a few occasions. In fact, there are some additional important uses cases that having more than one DirectAccess deployment can address.

Common Use Cases

QA and Testing – Having a separate DirectAccess deployment to perform testing and quality assurance can be quite helpful. Here you can validate configuration changes and verify updates without potential negative impact on the production deployment.

Delegated Administration – DirectAccess provides support for geographic redundancy, allowing administrators to create DirectAccess entry points in many different locations. DirectAccess in Windows Server 2012 R2 lacks support for delegated administration though, and in some cases it may make more sense to have multiple separate deployments as opposed to a single, multisite deployment. For example, many organizations are divided in to different business units internally and may operate autonomously. They may also have different configuration requirements, which can be better addressed using individual DirectAccess implementations.

Migration – If you have currently deployed DirectAccess using Windows Server 2008 R2 with or without Forefront UAG 2010, migrating to Windows Server 2012 R2 can be challenging because a direct, in-place upgrade is not supported. You can, however, deploy DirectAccess using Windows Server 2012 R2 in parallel to your existing deployment and simply migrate users to the new solution by moving the DirectAccess client computer accounts to a new security group assigned to the new deployment.

Major Configuration Changes – This strategy is also useful for scenarios where implementing changes to the DirectAccess configuration would be disruptive for remote users. For example, changing from a single site to a multisite configuration would typically require that all DirectAccess clients be on the LAN or connect remotely out-of-band to receive group policy settings changes after multisite is first configured. In addition, parallel deployments can significantly ease the pain of transitioning to a new root CA if required.

Unique Client Requirements – Having a separate deployment may be required to take advantage of the unique capabilities of each client operating system. For example, Windows 10 clients do not support Microsoft Network Access Protection (NAP) integration. NAP is a global setting in DirectAccess and applies to all clients. If you still require NAP integration and endpoint validation using NAP for Windows 7 and Windows 8.x, another DirectAccess deployment will be required to support Windows 10 clients.


To support multiple Windows Server 2012 R2 DirectAccess deployments in the same organization, the following is required:

Unique IP Addresses – It probably goes without saying, but each DirectAccess deployment must have unique internal and external IPv4 addresses.

Distinct Public Hostname – The public hostname used for each deployment must also be unique. Multi-SAN certificates have limited support for DirectAccess IP-HTTPS (public hostname must be the first entry in the list), so consider using a wildcard certificate or obtain certificates individually for each deployment.

Group Policy Objects – You must use unique Active Directory Group Policy Objects (GPOs) to support multiple DirectAccess deployments in a single organization. You have the option to specify a unique GPO when you configure DirectAccess for the first time by clicking the Change link next to GPO Settings on the Remote Access Review screen.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

Enter a distinct name for both the client and server GPOs. Click Ok and then click Apply to apply the DirectAccess settings for this deployment.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

Windows 7 DirectAccess Connectivity Assistant (DCA) GPOs – If the DirectAccess Connectivity Assistant (DCA) v2.0 has been deployed for Windows 7 clients, separate GPOs containing the DCA client settings for each individual deployment will have to be configured. Each DirectAccess deployment will have unique Dynamic Tunnel Endpoint (DTE) IPv6 addresses which are used by the DCA to confirm corporate network connectivity. The rest of the DCA settings can be the same, if desired.

Supporting Infrastructure

The rest of the supporting infrastructure (AD DS, PKI, NLS, etc.) can be shared between the individual DirectAccess deployments without issue. Once you’ve deployed multiple DirectAccess deployments, make sure that DirectAccess clients DO NOT belong to more than one DirectAccess client security group to prevent connectivity issues.


DirectAccess with Windows Server 2012 R2 supports many different deployment models. For a given DirectAccess deployment model, some settings are global in scope and may not provide the flexibility required by some organizations. To address these challenges, consider a parallel deployment of DirectAccess. This will enable you to take advantage of the unique capabilities of each client operating system, or allow you to meet the often disparate configuration requirements that a single deployment cannot support.

Troubleshooting Name Resolution Issues on DirectAccess Clients

When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:


Troubleshooting Name Resolution Issues on DirectAccess Clients

You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:

netsh namespace show policy

Troubleshooting Name Resolution Issues on DirectAccess Clients

Here you’ll notice that the namespace .lab.richardhicks.net is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host nls.lab.richardhicks.net is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.

A Working Example

With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for app1.lab.richardhicks.net would be sent to the DNS64 service on the DirectAccess server. A name resolution request for technet.microsoft.com would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host nls.lab.richardhicks.net is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.


The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.

Troubleshooting Name Resolution Issues on DirectAccess Clients

This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.

Resolve-DNSName –Server <DNS64_IPv6_Address> app1.lab.richardhicks.net

Troubleshooting Name Resolution Issues on DirectAccess Clients

Forefront UAG 2010 End of Life Statement

Today, Microsoft announced the end of life for the Forefront UAG 2010 product. Microsoft will continue to provide mainstream support for UAG until April 14, 2015, and extended support until April 14, 2020. Existing customers with active Software Assurance on their existing UAG licenses as of December 1, 2013, may add new UAG server instances, users, and devices without having to purchase additional UAG licenses. In addition, existing customers who have purchased Forefront UAG server licenses will be given upgrade rights to Windows Server 2012 R2, which provides some of the remote access features found in Forefront UAG. For example, Windows Server 2012 R2 supports DirectAccess, client-based VPN, and reverse web proxy with new Web Application Proxy role.

With regard to license upgrade rights, users are entitled to a Windows Server 2012 R2 license for each Forefront UAG server license (or External Connector license) they currently own. Software Assurance for UAG can still be purchased until January 1, 2014. Forefront UAG 2010 will be removed from the pricelist on July 1, 2014. Forefront UAG 2010 will continue to be available from Microsoft OEM hardware partners like Iron Networks for the foreseeable future, however.

Forefront UAG Service Pack 4 Now Available for Download

Good news! Service Pack 4 (SP4) for Forefront Unified Access Gateway (UAG) 2010 is now available for download. This latest service pack for UAG includes updates to support Windows 8.1 client devices using Internet Explorer 11, the native mail app, and Remote Desktop Connection (RDC) 8.1 client. In addition, SP4 for Forefront UAG 2010 also includes support for publishing RemoteApps from a Remote Desktop Session Host running on Windows Server 2012 or 2012 R2. The service pack also includes fixes for various reported issues.

KB2907776 – The UserMgrCom service crashes intermittently in Forefront UAG 2010

KB2909151 – Trunk authentication fails when the global catalog server is unavailable in Forefront UAG 2010

KB2909168 – The W3wp.exe process randomly stops and causes all sessions to disconnect in Forefront UAG 2010

KB2909182 – “The URL contains an invalid path” error occurs when you try to access an Exchange 2013 OWA website

KB2909191 – You cannot connect to corporate IPv4 resources by using DirectAccess after Forefront UAG 2010 Service Pack 3 is installed

KB2909350 – An SSL VPN application that has the Socket Forwarding mode set to Disabled uses 100 percent of the CPU’s time in Forefront UAG 2010

KB2909353 – You have to authenticate again to the ADFS server when the published server is configured for single sign-on in Forefront UAG 2010

KB2909356 – A detailed HTTP 403.14 error message occurs when you go to a specific InternalSite URL in a Forefront UAG 2010 environment

KB2909365 – A memory leak in W3wp.exe occurs when Outlook Anywhere is published through a Forefront UAG 2010 trunk

KB2909367 – Intermittent HTTP 500 error codes when you access a Forefront UAG 2010 portal

KB2909376 – File uploads do not occur to SharePoint Server 2013 or SkyDrive Pro through Forefront UAG 2010

KB2910407 – An internal 500 error occurs if a custom URL logoff page is configured in Forefront UAG 2010

KB2910413 – Multiple 4625 event IDs are logged when a user logs on in Forefront UAG 2010

KB2910467 – Configuration activation fails on some servers in a large array in Forefront UAG 2010

KB2910498 – A handle leak occurs in Lsass.exe in Forefront UAG 2010

KB2910506 – An authentication prompt is received even though a user is successfully authenticated in Forefront UAG 2010

KB2910517 – An incorrect domain password policy may be used if Active Directory integrated authentication is configured in Forefront UAG 2010

You must have Forefront UAG 2010 SP3 hotfix rollup 1 installed prior to installing SP4. You can download SP3 rollup 1 here. You can download Forefront UAG 2010 SP4 here. Once the update is installed the new Forefront UAG 2010 build number will be 4.0.4083.10000.

Forefront UAG 2010 Video Training Course Now Available

I’m happy to announce that my latest Trainsignal video training course is now available! This new video training course is on Forefront Unified Access Gateway (UAG) 2010. It is an introductory course on Forefront UAG designed to teach network engineers and security administrators the basic essentials of planning, preparing, installing, configuring, monitoring, and maintain a Forefront UAG 2010 remote access solution. In the course I demonstrate how to publish popular Microsoft on-premises applications like SharePoint and Exchange Outlook Web App (OWA). In addition I cover publishing Remote Desktop Services and VPN remote access. I also provide a high level explanation of endpoint detection and endpoint policy enforcement and demonstrate how to provide high availability for the solution. Here is the entire course outline:

Lesson 1 – Introduction and Course Outline
Lesson 2 – Forefront UAG 2010 Overview
Lesson 3 – Planning to Deploy Forefront UAG 2010
Lesson 4 – Installing and Configuring Forefront UAG 2010
Lesson 5 – Configuring a Portal
Lesson 6 – Publishing Exchange Outlook Web App
Lesson 7 – Publishing SharePoint
Lesson 8 – Publishing Remote Desktop Services
Lesson 9 – Configuring VPN Remote Access
Lesson 10 – Enabling Endpoint Detection
Lesson 11 – Configuring High Availability
Lesson 12 – Web Monitor Overview
Lesson 13 – Forefront UAG Backups

Once again I had the opportunity to work with my good friend and fellow Microsoft MVP Jordan Krause on this course. As he did in my previous Trainsignal video training course on Windows Server 2012 DirectAccess, Jordan served as the technical reviewer and provided valuable insight that ultimately made the course better. If you’re planning to implement Forefront UAG 2010 to provide secure remote access to both managed and non-managed systems and devices, be sure to sign up for a subscription at Trainsignal.com today! Not only will you have access to this video training course on Forefront UAG 2010, you will gain access to the entire Trainsignal library of content, including my course on Windows Server 2012 DirectAccess, all for just $49.00 per month!

TrainSignal Windows Server 2012 DirectAcess Video Training Course

Forefront UAG 2010 Service Pack 3 Hotfix Rollup 1 Now Available

Hotfix rollup 1 for Forefront Unified Access Gateway (UAG) 2010 Service Pack 3 is now available for download. Hotfix rollup 1 for Forefront UAG SP3 addresses the following issues:

KB2810229 – You cannot redirect local computer resources in remote desktop session after you disable the client endpoint components in Forefront UAG 2010 SP3

KB2831570 The URL you requested cannot be accessed error message may be returned when a client sends an HTTP POST request to a portal in Forefront UAG 2010 SP3

KB2831573 – Traffic is not forwarded or you receive an error message about ADVAPI32.dll when you use a Windows XP client to start an application from a Forefront UAG 2010 SP3 portal

KB2831865 – The endpoint policy expression Any Personal Firewall (Windows) is incorrect for Windows 7 and Windows 8 in Forefront UAG 2010 SP3

KB2831868 – Endpoint policies for existing trunks are not updated after you install service pack 3 for Forefront UAG 2010

KB2832679 – You receive a 500 Internal Server error when you run the File Access application from the Forefront UAG 2010 SP3 portal trunk

KB2832681 – You receive a script error that prevents file access configuration in the Management Console in Forefront UAG 2010 SP3

KB2832685 – The Forefront UAG 2010 portal may intermittently become unresponsive to clients after Service Pack 2 is installed

You can download hotfix rollup 1 for Forefront UAG 2010 SP3 here. After installation the Forefront UAG 2010 build number will be 4.0.3206.10100.

Forefront UAG 2010 DirectAccess Clients and Repeated OTP Prompts

In a very specific DirectAccess deployment scenario it is possible that users may be prompted repeatedly for One-Time Password (OTP) credentials. Specifically this may occur when you have Windows 7 clients accessing a Forefront UAG 2010 DirectAccess server with two-factor authentication enabled with OTP, along with forced tunneling required and the client configured to use a corporate web proxy server. The root cause of the issue has to do with Network Connectivity Status Indicator (NCSI) probes and security permissions on the private key of the certificate used for OTP authentication. To resolve the issue will require creating a custom certificate template for use with two-factor authentication and setting key permissions for the NETWORK SERVICE on the certificate template. You can also workaround this issue by disabling forced tunneling or disabling the 6to4 and Teredo adapters, which will stop the NCSI probes from occurring. For more detailed information read Microsoft KB article 2797301.

DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

Features Deprecated in Forefront UAG Service Pack 3

With the recent release of Service Pack 3 (SP3) for Microsoft Forefront Unified Access Gateway (UAG) 2010, Microsoft has published a list of features in UAG SP3 that have been deprecated. To be clear, this does not mean these features cease to function after you install SP3 on UAG! It is simply meant to give network engineers and security administrators an idea about what features are likely to be removed from future releases of Forefront UAG. Some of the deprecated features should come as no surprise. For example, DirectAccess support in Forefront UAG is now deprecated in favor of DirectAccess in Windows Server 2012. Also, features such as Secure Sockets Tunneling Protocol (SSTP) for client-based remote access are better handled using the remote access role in Windows Server 2012. Other deprecated features may present more of a challenge if you’ve been relying on them to provide secure remote access to applications, such as the deprecation of support for some authentication repositories (e.g. Novell Directory, Notes Directory, TACACS) or the Java-based Session Cleanup tool. For a complete list of deprecated features in Forefront UAG SP3, click here.

%d bloggers like this: