Architecting, Deploying and Operating Direct Access (Part 2)

If you would like to read the other parts in this article series please go to:


In the previous article in this column, you read about planning for Direct Access, the new ‘anywhere access’ solution from Microsoft. We covered the initial organizational plan that should be laid out prior to starting any of the technical work, the pre-requisites for the solution and the different access modes that are available in Direct Access. In this article we’ll go into depth on the capacity planning to accurately size your deployment and beginning the deployment process.

As we’ve emphasized in previous articles, Direct Access is an extremely powerful solution, but must be appropriately sized and deployed in a step-by-step manner. Many organizations are deploying Direct Access ‘side by side’ with a traditional VPN solution and gradually phasing out their older ‘legacy’ solution as the user base becomes more familiar with the new technology.

Sizing and Capacity Planning

Sizing is a tricky thing for many organizations to wrap their head around; the paradigm has shifted quite a bit and making the justification to support additional connections may be difficult. In a ‘legacy’ VPN deployment, there was a concept of concurrent user licensing and sizing. The rationale was that in a deployment of, say, 1000 mobile users perhaps 150 or 200 might be connected at one time. Perhaps there’d be higher concentrations during off-peak times (e.g.: on the weekend) or during inclement weather preventing users from coming into their local office, especially in geographically concentrated companies with only one or two offices. Network VPN providers would issue a license, say, for 250 concurrent users with some exception-based overages for these types of emergency situations.

With Direct Access, the VPN paradigm has shifted and thinking needs to be updated accordingly. In an organization with the same 1000 mobile users, those devices could potentially be engaging the Direct Access tunnel no matter where they are and no matter what time they’re connected. Even if they’re not ‘leveraging’ the solution to actively establish remote connections, the ability to have the client pull down security updates, anti-virus definitions, etc. warrants the background use of the corporate network. Furthermore, if the solution is set up in ‘full tunnel’ mode, all Internet-bound traffic will route through Direct Access and this may require additional resources. We will explore the full tunnel configuration in greater depth in a future article. Make sure that you’ve got a solid use case as you request additional hardware and software to support your user base. Since Direct Access licensing is a subset of the Windows Client and Server licensing, there is potential cost savings available in the licensing cost and hardware management cost currently expended with a ‘legacy’ VPN solution once the Direct Access deployment is complete.

Factors to consider in sizing your deployment

Top factors to consider for the appropriate sizing of a new deployment are as follows:

  • Availability: Is 100% uptime required for the entire environment?
  • Peak Access: How does the network environment peak? Have you measured network traffic and number of connections, concurrent and total? Have you measured trends in the network traffic to identify when and where traffic patterns peak in the current VPN solution deployment?
  • Performance: How important is performance to the user experience? Users execute many applications remotely; with Direct Access, the expectation will be that the experience is similar between a remote connection and a corporate network connection. Consider bandwidth-intensive applications like CAD programs that pull large data files from a backend environment. This is particularly important when forcing all IP traffic through the Direct Access tunnel.

By default, a Direct Access server will support 256 concurrent ‘Teredo’ (reference the previous article for a refresher on Teredo versus native IPv6) clients for Direct Access. This number can be scaled up or down by using the netsh interface ipv6 set global neighborclient=X instruction from the command line. Beware of randomly guessing at this number; oversaturating a single Direct Access server role can cause performance issues that render many remote access functions unusable for the entire client base. A common tactic when sizing the deployment is to understand how many servers are available to be dedicated to Direct Access and breaking out the individual server roles required for the solution. Server roles as assigned during the setup wizard include:

  • IP Security (IPsec) Gateway.
  • Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) server.
  • Native Internet Protocol version 6 (IPv6) router.
  • Intra-Site Automatic Tunnel Advertising Protocol (ISATAP) router.
  • IP 6to4 relay.
  • Teredo Server and Relay.

An example of where this may be effective is using one server as the IPSec Gateway to encrypt and decrypt the traffic, possibly with the use of more CPU cores and/or an SSL offload accelerator card installed.

Further server scaling can be achieved by using Microsoft Forefront Unified Access Gateway (UAG) with network load balancing. While this may not be required in every deployment, it merits consideration, particularly if your organization owns Unified Access Gateway in the Enterprise Client Access License Suite. UAG provides three key pieces of functionality that may be a factor in sizing Direct Access for your environment:

  • Access to IPv4 resources. If there are any non-IPv6 capable devices in your environment, UAG will allow you to transition from IPv6 to IPv4. Unless you have a Windows Server 2008 R2 native server environment, this is probably a requirement.
  • Scalability. UAG integrates with Network Load Balancing (NLB) in Windows, which allows you to scale to a much greater number of clients. While Microsoft has not released specific numbers regarding scalability, UAG may be compelling if you’re supporting more than 10,000 clients.
  • Management. In addition to the UAG console, there’s also a management pack for System Center Operations Manager (SCOM) if you use System Center in your environment.

 Stay tuned for more information about integrating UAG into your Direct Access deployment in a future article.

Another capacity planning technique that’s leveraged during a Direct Access deployment is leveraging Hyper-V failover clusters – two (or more) Hyper-V hosts with failover clustering that may support a single Direct Access ‘resource’. This allows for virtualization of the Direct Access environment but does have some requirements of its own: the hardware must be identical in each Hyper-V server, for example. Consider this if you are a heavily virtualized environment or short on physical hardware capacity – all of the Direct Access roles are fully support in a Hyper-V environment.

Microsoft has published a blog detailing some factors to consider when deploying Direct Access in a Hyper-V environment, you can read more here.

Beginning the Deployment

Now that you have a solid understanding of your remote access strategy, the pre-requisites understood and the appropriate number of servers stood up with Windows Server 2008 R2 SP1 installed on them, we’re ready to begin deployment of the solution to your selected Windows 7 SP1 Enterprise clients that are in the ‘pilot’ or test group.

One of the first decisions that need to be made during deployment is selecting which of the access methods makes the most sense for your organization:

Many organizations begin with a ‘Selected Server Access’ strategy, with certain resources published and available via Direct Access, working their way up to an end-to-end access strategy or potentially full intranet depending on what your requirements are and how that aligns with the remote access strategy. For the purposes of this article series, this is the strategy we’ll follow.

Prepare the Direct Access Server

Preparing the server prior to configuration of the Direct Access options can be complex; luckily, Microsoft provides a comprehensive set of ‘checklists’, which we’ll leverage throughout this article series. You can review these checklists here. First steps required include:

  • Installing two network adapters and configuring the IP addressing, making sure the drivers are up-to-date, etc. (Start -> Control Panel -> Network and Sharing Center -> Change Adapter Settings)
  • Ensure the internal interface is an IPv4 addressed resource. (Start -> Control Panel -> Network and Sharing Center -> Change Adapter Settings)
  • Join the Direct Access server to the domain.
  • Connect the second adapter to the Internet.
  • Ensure that packet filtering is appropriately configured on the external interface. In-depth information can be found here
  • Install an SSL certificate for IP-HTTPS authentication and network location server. (Start -> Run ->certsrv.msc)

In the Server Manager tool (Start -> Run ->servermanager.msc) under ‘Features Summary’, click ‘Add Features’. On the ‘Select Features’ page, select ‘Direct Access Management Console’. In the ‘Add Features Wizard’ window, click ‘Add Required Features’ and finish the installation process. You’ve now got the Direct Access Management Console, used to manage and configure connectivity for Direct Access in your deployment.


Sizing and planning a deployment is critical to ensure that there’s no over-investment in server resources. Understanding the different server roles and beginning with the requirements and access methods that are required for Direct Access to be successful in your environment is critical to a successful experience.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top