Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

Organizations are rapidly deploying Windows server infrastructure with public cloud providers such as Amazon Web Services (AWS) and Microsoft Azure. With traditional on-premises infrastructure now hosted in the cloud, DirectAccess is also being deployed there more commonly.

Supportability

Interestingly, Microsoft has expressly stated that DirectAccess is not formally supported on their own public cloud platform, Azure. However, there is no formal statement of non-support for DirectAccess hosted on other non-Microsoft public cloud platforms. With supportability for DirectAccess on AWS unclear, many companies are taking the approach that if it isn’t unsupported, then it must be supported. I’d suggest proceeding with caution, as Microsoft could issue formal guidance to the contrary in the future.

DirectAccess on AWS

Deploying DirectAccess on AWS is similar to deploying on premises, with a few notable exceptions, outlined below.

IP Addressing

It is recommended that an IP address be exclusively assigned to the DirectAccess server in AWS, as shown here.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

Prerequisites Check

When first configuring DirectAccess, the administrator will encounter the following warning message.

“The server does not comply with some DirectAccess prerequisites. Resolve all issues before proceed with DirectAccess deployment.”

The warning message itself states that “One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

IP addressing for virtual machines are managed entirely by AWS. This means the DirectAccess server will have a DHCP-assigned address, even when an IP address is specified in AWS. Assigning static IP addresses in the guest virtual machine itself is also not supported. However, this warning message can safely be ignored.

No Support for Load Balancing

It is not possible to create load-balanced clusters of DirectAccess servers for redundancy or scalability on AWS. This is because enabling load balancing for DirectAccess requires the IP address of the DirectAccess server be changed in the operating system, which is not supported on AWS. To eliminate single points of failure in the DirectAccess architecture or to add additional capacity, multisite must be enabled. Each additional DirectAccess server must be provisioned as an individual entry point.

Network Topology

DirectAccess servers on AWS can be provisioned with one or two network interfaces. Using two network interfaces is recommended, with the external network interface of the DirectAccess server residing in a dedicated perimeter/DMZ network. The external network interface must use either the Public or Private Windows firewall profile. DirectAccess will not work if the external interface uses the Domain profile. For the Public and Private profile to be enabled, domain controllers must not be reachable from the perimeter/DMZ network. Ensure the perimeter/DMZ network cannot access the internal network by restricting network access in EC2 using a Security Group, or on the VPC using a Network Access Control List (ACL) or custom route table settings.

External Connectivity

A public IPv4 address must be associated with the DirectAccess server in AWS. There are several ways to accomplish this. The simplest way is to assign a public IPv4 address to the virtual machine (VM). However, a public IP address can only be assigned to the VM when it is deployed initially and cannot be added later. Alternatively, an Elastic IP can be provisioned and assigned to the DirectAccess server at any time.

An ACL must also be configured for the public IP that restricts access from the Internet to only inbound TCP port 443. To provide additional protection, consider deploying an Application Delivery Controller (ADC) appliance like the Citrix NetScaler or F5 BIG-IP to enforce client certificate authentication for DirectAccess clients.

Network Location Server (NLS)

If an organization is hosting all of its Windows infrastructure in AWS and all clients will be remote, Network Location Server (NLS) availability becomes much less critical than with traditional on-premises deployments. For cloud-only deployments, hosting the NLS on the DirectAccess server is a viable option. It eliminates the need for dedicated NLS, reducing costs and administrative overhead. If multisite is configured, ensure that the NLS is not using a self-signed certificate, as this is unsupported.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

However, for hybrid cloud deployments where on-premises DirectAccess clients share the same internal network with cloud-hosted DirectAccess servers, it is recommended that the NLS be deployed on dedicated, highly available servers following the guidance outlined here and here.

Client Provisioning

All supported DirectAccess clients will work with DirectAccess on AWS. If the domain infrastructure is hosted exclusively in AWS, provisioning clients can be performed using Offline Domain Join (ODJ). Provisioning DirectAccess clients using ODJ is only supported in Windows 8.x/10. Windows 7 clients cannot be provisioned using ODJ and must be joined to the domain using another form of remote network connectivity such as VPN.

Additional Resources

DirectAccess No Longer Supported in Microsoft Azure

Microsoft Server Software Support for Azure Virtual Machines

DirectAccess Network Location Server (NLS) Guidance

DirectAccess Network Location Server (NLS) Deployment Considerations for Large Enterprises

Provisioning DirectAccess Clients using Offline Domain Join (ODJ)

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

DirectAccess SSL Offload and IP-HTTPS Preauthentication with F5 BIG-IP

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course

Implementing DirectAccess with Windows Server 2016 Book

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Introduction

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic ManagerTo provide geographic redundancy, DirectAccess can be deployed in a multisite configuration. In this scenario, Windows 8.x and Windows 10 clients are aware of all entry points in the enterprise and will automatically select the nearest available entry point to connect to. The nearest entry point is defined as the one that responds the quickest. When a Windows 8.x or Windows 10 client attempts to establish DirectAccess connectivity, an HTTP GET is sent to all entry points and the client will select the one with the shortest Round Trip Time (RTT) for the request.

Note: Windows 7 clients can be provisioned when DirectAccess is configured for multisite access, but they must be assigned to an individual entry point.

Challenges

There are a number of challenges that come with the default multisite configuration. Choosing an entry point based solely on network latency is rather simplistic and can often produce unexpected results. It also lacks support for granular traffic distribution or active/passive configuration.

GSLB

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic ManagerFor the best experience, DirectAccess can be configured to use a Global Server Load Balancing (GSLB) solution to enhance transparent site selection and failover for Windows 8.x and Windows 10 clients. Commonly this is implemented using an on-premises appliance (Citrix NetScaler, F5 Global Traffic Manager, Kemp LoadMaster, A10 Thunder, etc.). These solutions offer exceptional control over DirectAccess traffic distribution, but they add expense and complexity.

Azure Traffic Manager

Azure Traffic Manager is a cloud-based GSLB solution that is a simple and cost-effective alternative to dedicated on-premises appliances. While it does not offer all of the features that GSLB appliances provide, it does provide better traffic distribution options than the default configuration. Importantly, it enables active/passive failover, which is a common requirement not supported natively with DirectAccess.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Traffic Manager Configuration

In the Azure portal (the new one, not the old one!) click New, Networking, and then Traffic Manager profile.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Provide a name and select a Routing method.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Routing method options are Performance, Weighted and Priority.

  • Performance. Select this option to enable clients to connect to the entry point with the lowest network latency.
  • Weighted. Select this option to enable clients to prefer some entry points more than others. Assign a weight value of 1 to 1000 for each entry point. Higher values have more preference. Values for entry points can be the same, if desired.
  • Priority. Select this option to enable clients to connect to a primary entry point, then fail over to a secondary or tertiary entry point in the event of an outage. Assign a priority value of 1 to 1000 for each entry point. Lower values take precedence. Each entry point must be assigned a unique priority value.

Click Create when finished. Next click Settings for the new traffic manager profile and click Configuration. Change Protocol to HTTPS, Port to 443, and Path to /IPHTTPS. Click Save when finished.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Next click Endpoints and click Add. Select External endpoint from the drop down list, provide a descriptive name, and then enter the Fully-Qualified Domain Name (FQDN) of the first DirectAccess entry point. When using the Performance routing method, choose a location that best represents the geography where the DirectAccess entry point is located. When using the Weighted or Priority routing methods, specify an appropriate value accordingly. Click Ok when finished. Repeat these steps for each entry point in the organization.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

DirectAccess Configuration

In the Remote Access Management console, highlight DirectAccess and VPN below Configuration in the navigation tree and then click Configure Multisite Settings below Multisite Deployment in the Tasks pane. Click Global Load Balancing and choose Yes, use global load balancing. Enter the FQDN of the Azure Traffic Manager profile and click Next, and then click Commit.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Note: An SSL certificate with a subject name matching that of the GSLB FQDN is not required.

In some cases, the management console may report that global load balancing addresses cannot be identified automatically for some or all entry points.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

If this occurs, it will be necessary to run the Set-DAEntryPoint PowerShell cmdlet to assign GLSB IP addresses to each entry point. The GSLB IP address is the public IPv4 address that the entry point public hostname resolves to.

Set-DAEntryPoint -Name [entrypoint_name] -GslbIP [external_ip_address]

For example:

Set-DAEntryPoint -Name "US West" -GslbIP 203.0.113.195
Set-DAEntryPoint -Name "US East" -GslbIP 198.51.100.21

Summary

DirectAccess includes native functionality to enable geographic load balancing for Windows 8.x and Windows 10 clients. The site selection process used by DirectAccess clients in this scenario is basic, and has the potential to yield unexpected results. Azure Traffic Manager is a simple, cost-effective alternative to dedicated on-premises GSLB appliances. It can be integrated with DirectAccess to address some of the shortcomings with the native entry point selection process.

Additional Resources

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Introduction

When preparing a DirectAccess server, an SSL certificate is required for the IP-HTTPS IPv6 transition technology. This certificate is often issued by a public Certification Authority (CA), but it can also be issued an organization’s internal Public Key Infrastructure (PKI).

SSL Certificate

Commonly an SSL certificate is issued for a single hostname, or subject. As long as the hostname matches the subject, everything works fine.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Multi-SAN SSL Certificate

To ease the management burden of using multiple certificates, or reduce the expense associated with using a wildcard certificate, organizations can request a multi-SAN (Subject Alternative Name) certificate, which matches more than one subject. The additional subjects are included in the Subject Alternative Name field on the SSL certificate.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS
A single multi-SAN certificate can be installed on multiple hosts and will work without issue as long as the hostname matches one of the SAN entries.

DirectAccess and Multi-SAN Certificates

When implementing DirectAccess in a multisite configuration, each entry point in the organization will have a unique public hostname. Instinctively, using a multi-SAN SSL certificate in this scenario would seem ideal.

Unfortunately, support for multi-SAN SSL certificates with DirectAccess is limited. To use a multi-SAN certificate for DirectAccess IP-HTTPS, the public hostname must match the name listed in the Subject field. In the example above, the subject is da.richardhicks.net, with SAN entries for da-west.richardhicks.net and da-east.richardhicks.net.

In this scenario, only the public name da.richardhicks.net is supported for use with DirectAccess. It will not work for any of the SAN entries. For example, attempting to configure DirectAccess to use this certificate with the public hostname da-west.richardhicks.net will fail with the following error message.

The subject name of certificate CN=[certificate subject name] is invalid.
Select a certificate with a valid subject name.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Attempting to work around this issue by using the Set-DAServer PowerShell cmdlet also fails to recognize the SSL certificate correctly.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Summary

Using a multi-SAN SSL certificate for the DirectAccess IP-HTTPS IPv6 transition technology is only supported when the public hostname matches the subject name of the certificate. Configuring DirectAccess with a public hostname listed in the SAN list is not supported. For multisite DirectAccess deployments, individual certificates must be issued for each entry point. Alternatively, a wildcard certificate can be used.

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.

Requirements

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.

Migration Process

Moving DirectAccess client computers from the old security group to the new one is all that’s required to migrate clients from one DirectAccess deployment to another. Client machines will need to be restarted to pick up the new security group membership, at which time they will also get the DirectAccess client settings for the new deployment. This works seamlessly when clients are on the internal network. It works well for clients that are outside the network too, for the most part. Because clients must be restarted to get the new settings, it can take some time before all clients finally moved over. To speed up this process it is recommended that DirectAccess client settings GPOs be targeted at a specific OUs created for the migration process. A staging OU is created for clients in the old deployment and a production OU is created for clients to be assigned to the new deployment. DirectAccess client settings GPOs are then targeted at those OUs accordingly. Migrating then only requires moving a DirectAccess client from the old OU to the new one. Since OU assignment does not require a reboot, clients can be migrated much more quickly using this method.

Summary

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.

DirectAccess and Windows 10 Better Together

With the release of Windows 10, many organizations who chose to skip Windows 8 are now beginning to deploy this new client operating systemn. To maximize investment in Windows 10, DirectAccess can be leveraged to provide employees with seamless and transparent, always on, secure remote corporate network connectivity. DirectAccess has been around for many years, and today the most popular DirectAccess client is Windows 7. However, Windows 10 provides better support for DirectAccess features that enhance performance and availability, while at the same making it easier to implement and support. Windows 10 opens up many new and compelling deployment scenarios for small businesses to large scale enterprises.

Full Support for Geographic Redundancy

Without a doubt the most important DirectAccess feature Windows 10 supports is automatic entry point selection and transparent failover for multisite deployments. DirectAccess multisite deployment provides essential geographic redundancy for organizations with multiple physical locations. Windows 7 has only minimal support for multisite deployment, with clients required to be assigned to a single entry point. Windows 10 clients are aware of all entry points and will intelligently select the closest entry point when establishing a DirectAccess connection. If the entry point becomes unavailable during the connection, Windows 10 clients will transparently connect to another entry point automatically.

Better Scalability and Performance

Windows 10, like Windows 8 before it, includes support for IP-HTTPS null encryption. This feature greatly improves scalability on the DirectAccess server by eliminating the needless double encryption that Windows 7 clients perform. This reduces resource consumption on the server and enables the server to support many more DirectAccess client connections.

DirectAccess and Windows 10 Better Together

Enhanced Supportability

Many will also appreciate Windows 10’s built-in DirectAccess connectivity status indicator. No longer will administrators have to deploy, manage, and maintain additional software to provide this essential functionality.

To access DirectAccess information in Windows 10, press Window Key + I, click Network & Internet, and then click the DirectAccess tab. Here you will find vital details about DirectAccess configuration and status such as connection state, currently connected entry point, and a site selection drop down box (if manual site selection is enabled by an administrator). In addition you can generate and collect log information for troubleshooting purposes.

DirectAccess and Windows 10 Better Together

Native PowerShell Support

Anyone tasked with troubleshooting DirectAccess configuration and connectivity issues will appreciate the native PowerShell integration with DirectAccess in Windows 10. With just a few commands a wealth of information about DirectAccess configuration and connectivity status can be obtained.

Need to quickly determine if a Windows 10 client has been provisioned for DirectAccess successfully?

Get-DAClientExperienceConfiguration

DirectAccess and Windows 10 Better Together

Has the Windows 10 client connected successfully? If not, why?

Get-DAConnectionStatus

DirectAccess and Windows 10 Better Together

Need to identify the Network Location Server (NLS) the client is configured to use?

Get-NCSIPolicyConfiguration

DirectAccess and Windows 10 Better Together

Looking for DirectAccess multisite entry point details and connection status?

Get-DAEntryPointTableItem

DirectAccess and Windows 10 Better Together

PKI Optional (But Recommended)

Finally, when Windows 10 (and Windows 8.x) clients are supported exclusively a Public Key Infrastructure (PKI) is optional. Here instead the Kerberos Proxy is leveraged to perform DirectAccess client authentication, which reduces infrastructure requirements by eliminating the need for a PKI. However, this configuration offers only limited support for DirectAccess features. For example, a PKI is still required if any Windows 7 clients are deployed. Also, PKI is required to support features such as one-time password (OTP) authentication, Microsoft Network Access Protection (NAP) integration, load balancing (integrated or external), force tunneling, and multisite configuration.

DirectAccess and Windows 10 Better Together

For optimum security and maximum deployment flexibility it is recommended that PKI be used to manage certificates for all DirectAccess deployments including those supporting only Windows 8.x and Windows 10 clients.

Summary

DirectAccess and Windows 10 are much better together. Windows 10 provides full support for the geographic load balancing features of DirectAccess and at the same time offers improved scalability and performance. Windows 10 also makes supporting and troubleshooting DirectAccess clients much easier. And for smaller deployments, Windows 10 can lower the barrier to entry for organizations considering DirectAccess by eliminating the need for a full PKI deployment.

Additional Resources

Video: DirectAccess and Windows 10 in Action
DirectAccess and Windows 10 in Education
Implementing DirectAccess with Windows Server 2016 Book
Implementing DirectAccess with Windows Server 2016 Video Training Course
DirectAccess Consulting Services

More Information

Have a question about DirectAccess? Fill out the form below and I’ll get in touch with you.

DirectAccess Consulting Services Now Available

Microsoft Certified Solutions Associate (MCSA)For the last five years I’ve been helping organizations large and small deploy DirectAccess. During that time I have amassed a wealth of knowledge and experience with this unique technology. DirectAccess is not trivial to install, configure, or troubleshoot. Also, it’s easy to make mistakes in the planning and design phase that can turn in to serious issues later in the deployment. To make matters worse, many organizations are deploying DirectAccess for the first time, and without essential guidance they are prone to making common mistakes or choosing configuration options that are less than optimal both in terms of supportability and performance.

Having deployed DirectAccess for some of the largest companies in the world, there isn’t much I haven’t already encountered. If you are looking for the best chance of success for your DirectAccess deployment, consider a consulting engagement with me. I can provide assistance with all facets of DirectAccess implementation including planning and design, installation, configuration, and troubleshooting. Consulting services at reasonable rates are available for all types of DirectAccess work including:

  • New DirectAccess installations
  • Migration from previous versions of DirectAccess
  • Upgrade or expansion of existing DirectAccess deployment
  • Enterprise planning and design for large-scale, multisite DirectAccess deployments
  • DirectAccess high availability (local and geographic)
  • Manage-out for DirectAccess with external hardware load balancers and/or multisite configuration
  • Multisite DirectAccess with geographic redundancy for Windows 7 clients
  • Existing DirectAccess design review and security assessment
  • Windows Server 2012 R2 client-based VPN configuration
  • DirectAccess client connectivity troubleshooting
  • DirectAccess training

Additionally, consulting services are available for a variety of security solutions as well as on-premises and cloud networking technologies such as:

  • Azure networking and infrastructure
  • Cross-premises connectivity to Azure
  • Certificate services (PKI)
  • IP address management
  • ISA Server and Forefront Threat Management Gateway (TMG) migration

All services can be performed on-site or remotely. If you are interested in obtaining my services, fill out the form below and I’ll contact you.

DirectAccess DNS Records Explained

After installing and configuring DirectAccess with Windows Server 2012 R2, several new host records appear automatically in the internal DNS (assuming dynamic DNS is supported, of course). One of them is directaccess-corpConnectivityHost and the other is directaccess-WebProbeHost. These DirectAccess DNS entries are used by Windows 8 and later clients for connectivity checks at various stages of DirectAccess connection establishment.

DirectAccess DNS Records Explained

Figure 1 – DirectAccess DNS records for IPv4-only network.

DirectAccess DNS Records Explained

Figure 2 – DirectAccess DNS records for dual-stack IPv4/IPv6 network.

Here is a detailed description for each of these DirectAccess DNS entries.

directaccess-corpConnectivityHost – This DNS host record includes both A and AAAA records when deployed on IPv4-only networks. Its A host record resolves to 127.0.0.1, which is the IPv4 loopback address. Its AAAA host record resolves to an IPv6 address that is a combination of the DirectAccess NAT64 IPv6 prefix and 7F00:1 (the hexadecimal equivalent of 127.0.0.1). When DirectAccess is configured on a network with native IPv6, the directaccess-corpConnectivityHost DNS record will only include a single AAAA record resolving to ::1.

This host record is used by the DirectAccess client to determine if name resolution for the corporate namespace is working after the IPv6 transition tunnel (6to4, Teredo, or IP-HTTPS) has been established. It does this by attempting to resolve the hostname directaccess-corpConnectivityHost.<corp_fqdn> (e.g. directaccess-corpConnectivityHost.corp.example.net) to an IPv6 address that it expects (the organization’s NAT64 prefix + 7F00:1 or ::1). If it does not resolve, or resolves to a different address, the client will assume that the transition tunnel was not established successfully and, if possible, fall back to another IPv6 transition protocol and repeat the process until it is successful.

Note: The DirectAccess client does not attempt to connect to the IP address resolved by directaccess-corpConnectivityHost. It simply compares the IP address returned by the query to the expected address (NAT64 prefix + 7F00:1 or ::1).

directaccess-WebProbeHost – This DNS host record includes only A records and resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. If load balancing is enabled, this host record will resolve to the virtual IP address (VIP) of the array. For multisite deployments there will be directaccess-WebProbeHost A host records for each entry point in the organization.

This host record is used by the DirectAccess client to verify end-to-end corporate network connectivity over the DirectAccess connection. The client will attempt to connect to the directaccess-WebProbeHost URL using HTTP. If successful, the DirectAccess connectivity status indicator will show Connected.

If any of these DirectAccess DNS records are missing or incorrect, a number of issues may arise. If the directaccess-corpConnectivityHost host record is missing or incorrect, DirectAccess IPv6 transition tunnel establishment may fail. If the directaccess-WebProbeHost record is missing or incorrect, the DirectAccess connectivity status indicator will perpetually show Connecting. This commonly occurs when an external load balancer is used and a virtual server isn’t created for the web probe host port (TCP 80). In addition, these DirectAccess DNS entries are not static and may be deleted if DNS scavenging of stale resource records is enabled on the DNS server.

DirectAccess Load Balancing and Multisite Configuration Options Unavailable

Looking for more information about DirectAccess load balancing? See my post entitled DirectAccess Deployment Guide for Kemp LoadMaster Load Balancers.

DirectAccess in Windows Server 2012 R2 supports load balancing and multisite configuration options to provide both local and geographic redundancy, respectively. To configure either of these options, open the Remote Access Management console, expand Configuration in the navigation tree, highlight DirectAccess and VPN, and then select either Enable Multisite or Enable Load Balancing in the Tasks pane.

DirectAccess Load Balancing and Multisite Configuration Options Unavailable

Depending on your configuration you may encounter a scenario in which these features do not appear in the Remote Access Management console.

DirectAccess Load Balancing and Multisite Configuration Options Unavailable

This occurs when the Web Application Proxy (WAP) role is installed on the DirectAccess server. Although this is a supported configuration, enabling load balancing or multisite on a DirectAccess server with WAP installed requires additional configuration. Specifically, load balancing and/or multisite must be configured before installing the WAP role.

To restore support for load balancing and multisite configuration options, remove the WAP role using the GUI or with the Uninstall-WindowsFeature Web-Application-Proxy PowerShell command.

DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

DirectAccess Deployment Guide for Kemp LoadMaster Load BalancersA few months ago I had the opportunity to work with the folks at KEMP Technologies to document the use of their LoadMaster load balancers for Windows Server 2012 R2 DirectAccess deployments. DirectAccess has several critical single points of failure which can benefit from the use of a load balancer. Typically Windows Network Load Balancing (NLB) is used in these scenarios, but NLB suffers from some serious limitations and lacks essential capabilities required to fully address these requirements. The use of an external third-party load balancer can provide better load distribution and more granular traffic control, while at the same time improving availability with intelligent service health checks.

Working with the LoadMaster was a great experience. Installation was quick and simple, and their web-based management console is intuitive and easy to use. The LoadMaster includes essential features that are required for load balancing DirectAccess servers, and advanced capabilities that can be leveraged to enhance geographic redundancy for multisite deployments.

DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

KEMP offers the widest platform coverage with their solutions, including dedicated hardware appliances, virtual appliances for multiple hypervisors including Hyper-V, cloud-based including Microsoft Azure, as well as bare metal support for installation on your own hardware. You can download a fully functional free trial here.

You can view and download the Windows Server 2012 R2 DirectAccess Deployment Guide for the KEMP LoadMaster load balancing solution here.

Additional Resources

Video: Enable Load Balancing for DirectAccess

Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)

DirectAccess Single NIC Load Balancing with KEMP LoadMaster Load Balancers

DirectAccess and the Free KEMP LoadMaster Load Balancer

Webinar Recording: DirectAccess Load Balancing Tips and Tricks

Webinar Recording: DirectAccess Multisite with Windows 10 and KEMP LoadMaster GEO

Webinar Recording: Maximize Your Investment in Windows 10 with DirectAccess and the KEMP LoadMaster Load Balancer

Implementing DirectAccess with Windows Server 2016 book

 

%d bloggers like this: