Always On VPN Hands-On Training Classes for 2018

Windows 10 Always On VPN Hands-On Training Classes for 2018I’m pleased to announce I will be delivering Windows 10 Always On VPN hands-on training classes in various locations around the U.S. this year. As Microsoft continues to move away from DirectAccess in favor of Windows 10 Always On VPN, many organizations now must come up to speed on this new technology. Spoiler alert…it’s not trivial to implement! There’s lots of moving parts, critical infrastructure dependencies, and many configuration options to choose from. Additionally, Windows 10 Always On VPN is managed in a completely different way than DirectAccess, which is sure to present its own unique challenges.

Comprehensive Education

My Windows 10 Always On VPN hands-on training classes will cover all aspects of designing, implementing, and supporting an Always On VPN solution in the enterprise. This three-day course will cover topics such as…

  • Windows 10 Always On VPN overview
  • Introduction to CSP
  • Infrastructure requirements
  • Planning and design considerations
  • Installation, configuration, and client provisioning

Advanced topics will include…

  • Redundancy and high availability
  • Cloud-based deployments
  • Third-party VPN infrastructure and client support
  • Multifactor authentication
  • Always On VPN migration strategies

Upcoming Training Classes

Reservations are being accepted immediately for classes held on March 27-29, 2018 in Southern California and April 10-12 in Chicago. The cost for this 3 day hands-on, in-depth training class is $4995.00 USD. Later this year I’ll be delivering classes in other parts of the country as well. Those locations will be chosen based on demand, so if you can’t make this first class, please register anyway and let me know your location preference. If there’s enough interest in a specific locale I will schedule a class for that region soon. Although I currently have no plans to deliver my training classes outside the U.S., I’m more than happy to consider it if there is enough demand, so let me know!

Windows 10 Always On VPN Hands-On Training Classes for 2018

Reservations Available Now

Reservations are being accepted now! The cost for this 3-day hands-on training class is $4995.00 USD. Space is limited, so don’t wait to register! Fill out the form below to save your seat now.

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

Migrating DirectAccess from NLB to External Load Balancer


Introduction

Migrating DirectAccess from NLB to External Load BalancerMultiple DirectAccess servers can be deployed in a load-balanced cluster to eliminate single crucial points of failure and to provide scalability for the remote access solution. Load balancing can be enabled using the integrated Windows Network Load Balancing (NLB) or an external physical or virtual load balancer.

NLB Drawbacks and Limitations

NLB is often deployed because it is simple and inexpensive. However, NLB suffers from some serious drawbacks that limit its effectiveness in all but the smallest deployments. For example, NLB uses network broadcasts to communicate cluster heartbeat information. Each node in the cluster sends out a heartbeat message every second, which generates a lot of additional network traffic on the link and reduces performance as more nodes are added. Scalability is limited with NLB too, as only 8 nodes are supported, although the practical limit is 4 nodes. Further, NLB supports only round-robin connection distribution.

External Load Balancer

A better alternative is to implement a dedicated physical or virtual load balancing appliance. A purpose-built load balancer provides additional security, greater scalability (up to 32 nodes per cluster), improved performance, and fine-grained traffic control.

Migrate from NLB to ELB

It is possible to migrate to an external load balancer (ELB) after NLB has already been configured. To do this, follow the guidance provided in my latest blog post on the KEMP Technologies blog entitled “Migrating DirectAccess from NLB to KEMP LoadMaster Load Balancers”.

Migrating DirectAccess from NLB to External Load Balancer

Additional Resources

DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

Migrating DirectAccess from NLB to KEMP LoadMaster Load Balancers

Load Balancing DirectAccess with KEMP LoadMaster Load Balancers

DirectAccess Load Balancing Tips and Tricks Webinar with KEMP Technologies

DirectAccess Single NIC Load Balancing with KEMP LoadMaster Load Balancer

Configuring the KEMP LoadMaster Load Balancer for DirectAccess NLS

Enable DirectAccess Load Balancing Video

Implementing DirectAccess with Windows Server 2016 Book

Implementing DirectAccess with Windows Server 2016 Pre-Order

Update: My new DirectAccess book is now available for purchase. Details here.

I am pleased to announce that my new book, Implementing DirectAccess with Windows Server 2016 from Apress Media, is now available for pre-order on Amazon.com!

Implementing DirectAccess with Windows Server 2016

This book contains detailed and prescriptive guidance for the planning, design, implementation, and support of a DirectAccess remote access solution on Windows Server 2016. It also includes valuable insight, tips, tricks, and best practice recommendations gained from my many years of deploying DirectAccess for some of the largest organizations in the world.

Current DirectAccess administrators will also find this book helpful, as the majority of content is still applicable to DirectAccess in Windows Server 2012 and Windows Server 2012 R2. In addition, the book also includes essential information on the design and deployment of highly available and geographically redundant DirectAccess deployments.

Troubleshooting DirectAccess can be a daunting task, so I’ve dedicated an entire chapter in the book to this topic. For those responsible for the maintenance and support of DirectAccess in their organization, this chapter alone will be worth the investment.

Be sure to reserve your copy today!

DirectAccess Load Balancing Video

DirectAccess Load Balancing VideoConfiguring load balancing in DirectAccess is essential for eliminating single points of failure and ensuring the highest level of availability for the solution. The process of enabling load balancing for DirectAccess can be confusing though, as it involves the reassignment of IP addresses from the first server to the virtual IP address (VIP) for the cluster.

In this video I demonstrate how to enable DirectAccess load balancing and explain in detail how IP address assignment works for both Network Load Balancing (NLB) and external load balancers (ELB).

Configure Citrix NetScaler for DirectAccess NLS

DirectAccess and Citrix NetScaler WebinarIntroduction

The Network Location Server (NLS) is a crucial DirectAccess supporting infrastructure component. It is secure web server that DirectAccess clients use to determine if they are inside or outside of the corporate network.

NLS Availability

The NLS should be highly available. If this service is not available, DirectAccess clients on the internal network will think they are outside and attempt to establish a DirectAccess connection. Typically, this results in the DirectAccess client not being able to reach internal resources by hostname. Full connectivity for DirectAccess clients on the internal network will not be restored until the NLS is online.

It is recommended that the NLS be deployed in a load-balanced cluster for high availability. However, this requires deploying multiple servers, adding more cost, complexity, and management overhead to the solution.

NLS and Citrix NetScaler

Configuring the Citrix NetScaler to serve as the NLS is an attractive alternative to deploying additional servers for this role. Using the NetScaler for the NLS reduces costs by leveraging existing infrastructure. In addition, the NetScaler requires less servicing than a typical Windows server, and is often itself already highly available.

Configure Citrix NetScaler

To configure the NetScaler to serve as a DirectAccess NLS, open the NetScaler management console, expand AppExpert, and then select Actions. Click Add, provide a descriptive name for the responder action, and then enter the following in the Expression field and click Create.

"HTTP/1.0 200 OK" +"\r\n\r\n" + "DirectAccess Network Location Server (NLS)" + "\r\n"

Configure Citrix NetScaler for DirectAccess NLS

Select Policies, click Add, and then provide a descriptive name for the responder policy. Enter HTTP.REQ.IS_VALID in the Expression field and click Create.

Configure Citrix NetScaler for DirectAccess NLS

Expand Traffic Management, expand Load Balancing and select Services. Click Add, provide a descriptive name for the service, choose New Server, and enter the IPv4 loopback address 127.0.0.1. Select SSL for the Protocol, enter a random port number for the Port and then click More.

Configure Citrix NetScaler for DirectAccess NLS

Uncheck the box next to Health Monitoring and click Ok and Done.

Configure Citrix NetScaler for DirectAccess NLS

Select Virtual Servers and click Add. Provide a descriptive name for the virtual server, select SSL for the Protocol, enter an IP address for the virtual server and click Ok.

Configure Citrix NetScaler for DirectAccess NLS

Under Services and Service Groups click No Load Balancing Virtual Server Service Binding.

Configure Citrix NetScaler for DirectAccess NLS

Click to select a service, choose the service created previously and click Ok, Bind and Ok.

Configure Citrix NetScaler for DirectAccess NLS

Under Certificates click No Server Certificate.

Configure Citrix NetScaler for DirectAccess NLS

Click to select a server certificate, choose the SSL certificate to be used by the NLS and click Ok, Bind, and Ok.

Configure Citrix NetScaler for DirectAccess NLS

Under Advanced click Policies, and then click the + icon. From the Choose Policy drown-list choose Responder and click Continue. Click to select a Policy Binding and choose the responder policy created previously. Click Ok, Bind, and Done.

Configure Citrix NetScaler for DirectAccess NLS

Testing NLS Functionality

Open a web browser on a client connected to the internal network and browse to the NLS URL. Ensure that there are no certificate errors and that the NetScaler is responding with the configured web page.

Configure Citrix NetScaler for DirectAccess NLS

Summary

The Network Location Server (NLS) is an important, and often overlooked, supporting infrastructure component for DirectAccess. It is used by DirectAccess clients to determine their network location. If it is unavailable for any reason it can be very disruptive. Ensuring that the NLS is highly available is critical. Configuring the NLS on the Citrix NetScaler can be a cost-effective alternative to deploying additional servers, while at the same time reducing the chance of an outage due to NLS failure.

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 Multicast NLB for DirectAccess

Introduction

DirectAccess in Windows Server 2012 R2 includes support for load balancing using either Windows Network Load Balancing (NLB) or an external physical or virtual load balancer. There are advantages and disadvantages to each, but NLB is commonly deployed due to its cost (free!) and relative ease of configuration. NLB has three operation modes – Unicast, Multicast, and IGMP Multicast. It may become necessary to change the NLB operation mode depending on the environment where DirectAccess is deployed. This article describes when and how to make those changes.

Default Configuration

When NLB is first configured, the default cluster operation mode is set to Unicast. In this configuration, all nodes in the NLB cluster share the same MAC address. The NLB kernel mode driver prevents the switch from learning the MAC address for any node in the cluster by masking it on the wire. When a frame is delivered to the switch where the NLB cluster resides, without a MAC address to switch port mapping the frame is delivered to all ports on the switch. This induces switch flooding and is by design. It is required for all nodes in the cluster to “see” all traffic. The NLB driver then determines which node will handle the request.

NLB on Hyper-V

Unicast NLB typically works without issue in most physical environments. However, enabling NLB when the DirectAccess server is running on a virtual machine requires some additional configuration. For Hyper-V, the only thing that is required is to enable MAC Address Spoofing on the virtual network adapter as I discussed here. No other changes are required.

NLB on VMWare

For VMware environments, it will be necessary to change the cluster operation mode from unicast to multicast. This is because the VMware hypervisor proactively informs the virtual switch of the virtual machine’s MAC address on startup and during other virtual networking events. When this occurs, all traffic for the NLB Virtual IP Address (VIP) will be delivered to a single node in the cluster. In multicast operation mode, all nodes in the NLB cluster retain their original MAC address and a unique MAC address is assigned to the cluster VIP. As such, there’s no need to prevent the switch from learning the virtual machine’s MAC address.

Configuring Multicast NLB

To enable Multicast NLB, first enable load balancing for DirectAccess using the Remote Access Management console as usual. DO NOT perform the initial configuration of NLB outside of the Remote Access Management console! Before adding another member to the array, open the Network Load Balancing Manager, right-click the cluster and choose Cluster Properties. Select the Cluster Parameters tab and change the Cluster operation mode to Multicast.

Configuring Multicast NLB for DirectAccess

When opening the Network Load Balancing Manager locally on the DirectAccess server, you may receive the following error message:

“Running NLB Manager on a system with all networks bound to NLB might
not work as expected. If all interfaces are set to run NLB in “unicast”
mode, NLB manager will fail to connect to hosts.”

Configuring Multicast NLB for DirectAccess

If you encounter this error message it will be necessary to run the NLB Manager on another host. You can install the NLB Manager on a Windows Server 2012 R2 system by using the following PowerShell command.

Install-WindowsFeature RSAT-NLB

Optionally you can download and install the Windows Remote Server Administration Tools (RSAT) on a Windows desktop client and manage NLB remotely.

Once this change has been made you can add additional DirectAccess servers to the array using the Remote Access Management console.

Additional Configuration

If you cannot communicate with the cluster VIP from a remote subnet, but can connect to it while on the same subnet, it might be necessary to configure static ARP entries on any routers for the subnet where the NLB cluster resides. Often this is required because routers will reject responses to ARP requests that are from a host with a unicast IP address but have a multicast MAC address.

WEBINAR: Maximize Your Investment in Windows 10 with DirectAccess and the Kemp LoadMaster

Kemp Technologies LoadMaster Load BalancerWith the recent release of Microsoft’s Windows 10 client operating system, many organizations are now planning their migration to Windows 10 from previous versions. For those organizations looking to maximize their investment in Windows 10, many are considering the deployment of DirectAccess with Windows Server 2012 R2.

DirectAccess and Windows 10 - Better TogetherDirectAccess and Windows 10 are much better together. Windows 10 includes full support for all of the important enterprise features of DirectAccess in Windows Server 2012 R2, including geographic redundancy, transparent site selection, and IP-HTTPS performance improvements. The Kemp LoadMaster load balancer can be used to extend and enhance the native high availability features of DirectAccess, and it can be used to reduce supporting infrastructure requirements.

To learn more about maximizing your investment in Windows 10 with DirectAccess and the Kemp LoadMaster load balancer, be sure to attend our upcoming webinar on Thursday, October 15 when I’ll discuss in detail and demonstrate the advantages of Windows 10 and the Kemp LoadMaster load balancer.

You can register for the Windows Server 2012 R2 DirectAccess and Kemp Technologies LoadMaster webinar here.

Kemp Technologies LoadMaster Load Balancer

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.

%d bloggers like this: