DirectAccess vs. VPN


DirectAccess vs. VPNMany IT professionals mistakenly believe that DirectAccess is just another VPN solution. While there are some similarities between these technologies, both in terms of the underlying technology and function, there are some significant differences between the two. If you’re comparing DirectAccess to VPN, here are some essential points to consider.


Virtual Private Networking (VPN) has been around for ages. VPN is a mature, well understood technology that has been widely deployed, and today remains the de facto standard for providing secure remote access. VPN has broad client support, on both traditional computing platforms and mobile operating systems. VPNs today include support for modern protocols and integrate with numerous multifactor authentication platforms.

VPN Challenges

There are some serious drawbacks to implementing traditional client-based VPN. VPN connections are user initiated and therefore optional. It is up to the user to decide if and when they connect to the corporate network. Many VPNs require additional software to work, which must be deployed and maintained. Establishing connections is potentially problematic too, as some VPN protocols aren’t firewall friendly and don’t work in many locations.

DirectAccess vs. VPNFrom a security perspective, because anyone can attempt a connection to the VPN from any client, strong authentication becomes an essential requirement. Integrating multifactor authentication makes the implementation more complex and difficult to support. It often requires additional hardware, licensing, and support costs.

VPNs can be costly to implement and support. They typically require expensive proprietary hardware and dedicated management skill sets. Many VPN solutions also have additional licensing costs associated with them. Scaling a VPN solution requires additional investments in hardware devices, adding to the overall cost of the solution.


DirectAccess is a relative newcomer to the world of secure remote access. First introduced with Windows Server 2008 R2, DirectAccess differs fundamentally from VPN by virtue of its seamless and transparent, always-on connection. DirectAccess connections are established by the machine, not the user. They are secure and authenticated, and are established automatically whenever the DirectAccess client has an active Internet connection. DirectAccess connections are also bidirectional, which is an important distinction. The ability to “manage out” to remote connected DirectAccess clients enables compelling new uses cases for IT administrators.

Addressing VPN Pain Points with DirectAccess

DirectAccess vs. VPNDirectAccess connections are inherently more secure than VPN. Unlike VPN, DirectAccess clients must be joined to the domain and, in most configurations, they must also have a certificate issued by the organization’s private, internal Public Key Infrastructure (PKI). This essentially serves as a type of multifactor authentication for the connecting device, resulting in a much higher level of assurance for remote connections. DirectAccess can also support integration with many existing multifactor authentication providers to provide strong authentication for the user, if desired.

DirectAccess is very firewall friendly and works anywhere the user has an active Internet connection. It requires no additional software to be installed, and the seamless and transparent nature of DirectAccess makes it much easier to use than VPN. All of this improves end user productivity and reduces associated management overhead for the solution.

DirectAccess is a more cost-effective alternative to VPN. DirectAccess can be deployed on existing infrastructure (physical or virtual) and does not require proprietary hardware. This makes it much easier and far less expensive to add additional capacity, if required. DirectAccess can also be managed using existing systems management tools and Windows administration skills and does not have any per-user licensing requirements, which results in additional cost savings over VPN.

DirectAccess Limitations and Drawbacks

DirectAccess is not a comprehensive remote access solution. It is designed for managed (domain-joined) Windows clients only. In addition, DirectAccess clients must be provisioned with the Enterprise edition SKU. Also, there are a few cases in which applications may not be compatible with DirectAccess. In addition, there is no support for DirectAccess on non-managed Windows machines, non-Enterprise SKUs, or any devices using non-Windows operating systems, so a VPN might still be required.

DirectAccess vs. VPN

DirectAccess or VPN?

You might be asking yourself, “DirectAccess or VPN?” Why not both? After all, DirectAccess and VPN aren’t mutually exclusive. They are, in fact, quite complimentary. DirectAccess can be used to provide secure remote access and enhanced management for Windows laptops managed by IT, while VPN can be deployed for non-managed devices. While you may not be able to entirely eliminate VPN with DirectAccess, it will certainly allow you to decrease the number of existing VPN licenses and reduce your investment in proprietary hardware, management tools, and dedicated administrators, all of which translates in to reduced capital investment and operational costs.


DirectAccess is not simply another VPN solution. While it does provide secure remote corporate network connectivity, it does so more securely and more cost effectively than traditional VPN does. DirectAccess is unrivaled in its security and ease of use, dramatically improving end user productivity and reducing associated infrastructure and support costs. DirectAccess can be deployed on current physical and virtual infrastructure, and can be managed using existing Windows systems management tools and skill sets.

DirectAccess Consulting ServicesIf you’d like to learn more about how DirectAccess can benefit your organization, or you would like some assistance with a DirectAccess proof of concept implementation, consider a DirectAccess consulting engagement today. I’m here to help plan, design, implement, and support DirectAccess and ensure the best chance of success for your deployment.

IPv6 Recommend Reading

IPv6 Recommended ReadingDirectAccess uses IPv6 exclusively for communication between the DirectAccess client and server. The DNS64 and NAT64 services running on the DirectAccess server allow the client to connect to IPv4-only resources on the corporate network. Although no IPv6 knowledge is necessary to implement DirectAccess, it is most certainly required to support it going forward. A fundamental understanding of IPv6 is vital when it comes to troubleshooting DirectAccess connectivity issues, so learning IPv6 is critically important for the DirectAccess administrator.

To help you learn more about IPv6, here are three essential resources I think you will find helpful!

Understanding IPv6 Practical IPv6 for Windows Administrators IPv6 Address Planning

Understanding IPv6
(Joe Davies) – This is an excellent reference for the IPv6 protocol and should be on every DirectAccess administrator’s desk. This book provides detailed documentation and explanations for the IPv6 protocol including IPv6 transition protocols, which are commonly used with DirectAccess.

Practical IPv6 for Windows Administrators (Ed Horley) – Another essential title for learning IPv6. This book focuses on the use of IPv6 for a variety of popular Windows workloads, including DirectAccess.

IPv6 Address Planning (Tom Coffeen) – This book is an optional read for DirectAccess administrators, but a recommended one still. There is no IPv6 address planning required to implement DirectAccess, as most commonly IPv6 addressing happens automatically. However, this book will help you understand IPv6 subnetting, which can be helpful for fully understanding DirectAccess.

If you prefer video training, be sure to check out this great course on Pluralsight from Ed Horley. Don’t be afraid of IPv6. Embrace it! Start learning IPv6 today!

DirectAccess SQL Server High CPU Usage


DirectAccess SQL Server High CPU UsageRADIUS and Inbox accounting are the two supported logging options for DirectAccess in Windows Server 2012 R2. When Inbox accounting is selected, a Windows Internal Database (WID) is provisioned. Part of the base operating system, WID is functionally similar to SQL Server Express.

SQL Server Utilization Issues

Over the last few months I’ve had a few customers reach out to me with a peculiar performance issue. For customers with very busy DirectAccess servers, where those servers have also been configured to use Inbox accounting, they’ve reported observing unusually high CPU utilization on the sqlservr.exe process.

DirectAccess SQL Server High CPU Usage
Image courtesy Thomas Vuylsteke. Used with permission. –

As luck would have it, Thomas Vuylsteke, a Microsoft Platforms Premiere Field Engineer (PFE), had already identified the issue and a workaround. Thomas traced the source of high CPU utilization on the sqlservr.exe process to a missing index on a session state table in the DirectAccess accounting database. If you are interested in learning how he performed the troubleshooting to identify and resolve this problem, you can read his entire blog post here.


To resolve this issue, create an index on the Session Table in the DirectAccess database. Changes to WID must be made locally, as it is not remotely manageable. WID does not include a management interface, which means the SQL Server management tools would normally have to be installed. However, I’m not a fan of installing any extraneous software on the DirectAccess server, so thankfully one of the readers of Thomas’ excellent article on this subject, Fredrik Elmqvist, provided a very helpful alternative. Fredrik suggesting using the HeidiSQL tool, for which a fully portable version exists. This allows for changes to be made to the WID database without having to install any additional software.

Changes to WID

Begin by downloading the portable version of HeidiSQL here. Next, log on to the DirectAccess server as the local administrator. It is crucial that you must be the local administrator, not just a local or domain user with local administrator privileges. Extract the files from the download and copy them to the DirectAccess server, then follow these steps:

  1. Double-click heideisql.exe to launch the management tool.
  2. Click on New and then for the Network Type select Microsoft SQL Server (named pipe).
  3. For the Hostname / IP: enter \\.\pipe\MICROSOFT##WID\tsql\query.
  4. Select the option to Use Windows Authentication.
  5. Click Open to continue.DirectAccess SQL Server High CPU Usage
  6. Click the Query tab in the center console window and enter the following commands:
    Use RaAcctDb
    Create NonClustered Index IdxSessionTblSessionState on SessionTable (SessionState,ConnectionID)
  7. Click the Run icon in the tool bar or press F9. This will execute the code and create the missing index on the Session Table in the DirectAccess database.DirectAccess SQL Server High CPU Usage
  8. Confirm the index was created by clearing the previous query or creating a new query and then entering the following commands:
    select * from sys.indexes
    where name like ‘idx%’
    order by name ascDirectAccess SQL Server High CPU Usage

Once the change has been made, sqlservr.exe CPU utilization should return to normal. If you have multiple DirectAccess servers configured in a load-balanced array or in a multisite configuration, be sure to repeat these steps on each DirectAccess server in the organization.

DirectAccess and Windows 10 Professional

Does Windows 10 Professional Support DirectAccess?

This is a question I’ve received on more than one occasion. For some reason there seems to be a persistent rumor on the Internet that Windows 10 Professional is now a supported client for DirectAccess. I’m not sure where this rumor got started, but I’ll put it to rest right now – Windows 10 Professional is NOT a supported DirectAccess client! DirectAccess still requires Enterprise edition (with two exceptions) to take advantage of DirectAccess for secure remote access.

Supported DirectAccess Clients

The following is a complete list (as of this writing) of client operating systems that support DirectAccess.

  • Windows 10 Enterprise
  • Windows 10 Education
  • Windows 8.1 Enterprise
  • Windows 7 Enterprise
  • Windows 7 Ultimate

DirectAccess and Windows 10 Professional

If you are running a version of Windows that is not Enterprise edition (with the exception of Windows 7 Ultimate and Windows 10 Education) DirectAccess will not work. Be careful, because you can still provision non-Enterprise SKUs such as Windows 10 Professional for DirectAccess. All of the DirectAccess settings will be applied without issue and everything will look perfectly normal, but DirectAccess won’t work. The telltale sign on Windows 8.x and Windows 10 clients is that you won’t be able to start the Network Connectivity Assistant (NCA) service (NcaSvc). When you attempt to do so you will receive the following error message:

Failed to start service 'Network Connectivity Assistant (NcaSvc)'

DirectAccess and Windows 10 Professional

Identify OS Version

You can verify the operating system SKU by looking at the output of systeminfo.exe or by going to the control panel under System and Security and clicking System.

DirectAccess and Windows 10 Professional

DirectAccess and Windows 10 Professional

Upgrade from Windows 10 Professional to Enterprise

A new feature introduced in Windows 10 allows you to easily upgrade the product SKU without having to perform an in place upgrade or reinstall the entire operating system from scratch. So, if you have Windows 10 Enterprise licenses and you want to upgrade a Windows 10 Professional device to Enterprise (for example you want to enable your new Surface Pro 4 to use DirectAccess!) you can simply provide the enterprise product license key in Windows 10 to upgrade. You can provide a new product key by navigating to Start | Settings | Update & Security | Activation | Change Product Key, or run changepk.exe from the Run dialog box or the command line.

DirectAccess and Windows 10 Professional

Enter your Windows 10 Enterprise product key and then click Start Upgrade.

DirectAccess and Windows 10 Professional

After the system reboots it will have been upgraded to Enterprise edition and now work as a DirectAccess client.

DirectAccess and Windows 10 Professional

DirectAccess and Windows 10 Professional

With Windows 10, it’s easy to upgrade from Professional to Enterprise edition by simply providing the Enterprise edition product key. This works great if you have just a few machines to upgrade, but if you are planning to upgrade many machines I would recommend creating a deployment package using the Windows Imaging and Configuration Designer (ICD), which is included with the Windows 10 Assessment and Deployment Kit (ADK) and can be downloaded here. Once you’ve upgraded your Windows 10 Professional devices to Windows 10 Enterprise you can begin provisioning them for DirectAccess!

DirectAccess consulting services now available! Click here for more details!

DirectAccess Deep Dive Training at TechMentor Las Vegas 2016

TechMentor Las Vegas 2016Looking for in-depth DirectAccess technical training? Join me at the TechMentor Conference March 7 to 11, 2016 at the Bally’s Hotel in Las Vegas, Nevada. There I will be delivering a three-hour deep-dive DirectAccess training session covering installation, configuration, and troubleshooting of DirectAccess on Windows Server 2012 R2. The conference also features many other excellent training sessions by industry experts like Don Jones, Greg Shields, Jeff Hicks, Ed Horley, and many more. Register now and save!

DirectAccess IP-HTTPS Discovery Script for Nmap

DirectAccess IP-HTTPS Discovery Script for NmapWhen troubleshooting DirectAccess connectivity issues, the popular Nmap network mapping and discovery tool is an invaluable resource for verifying the communication path to the DirectAccess server from outside the network. However, just verifying that ports are open and listening often isn’t sufficient. In the case of IP-HTTPS, for example, the tried and true method of using telnet to verify that the port is open might be misleading. For instance, telnet might indicate that TCP port 443 is open and responding, but DirectAccess connectivity can still fail. This often happens as a result of a network configuration error that allows another network device other than the DirectAccess server to respond to HTTPS requests, which results in a false positive.

In an effort to conclusively determine that the DirectAccess server is responding, I’ve often relied on the SSL Labs Server Test site. Here I will enter the DirectAccess server’s public hostname and run the test, and from the results I can easily determine if indeed the DirectAccess server is responding by verifying that the HTTP server signature is Microsoft-HTTPAPI/2.0.

DirectAccess IP-HTTPS Discovery Script for NMAP

This usually works well, but it takes a few minutes to run the test, and there are a few scenarios in which it doesn’t work. For example, I might be working with a customer to perform some initial testing by using a local HOSTS file entry for the public name before the DNS record has been created. Also, if the SSL certificate on the DirectAccess server uses an IP address instead of a hostname (not recommended, but it is supported!) the SSL Labs server test won’t work.

Fortunately, the latest release Nmap (v7.00) now includes a script that enables the detection of Microsoft DirectAccess responding on TCP port 443. With the IP-HTTPS discovery script, it is now possible to determine not only if the port is open, but if the DirectAccess server is actually the service responding. The syntax for conducting a port scan using the IP-HTTPS discovery script for NMAP is as follows:

nmap.exe –n –Pn –p443 [directaccess_public_fqdn] –script [path_to_nmap_iphttps_discovery_script]

Here’s an example:

nmap.exe –n –Pn –p443 –script c:\tools\nmap\scripts\ip-https-discover.nse

DirectAccess IP-HTTPS Discovery Script for NMAP

Now it is possible, using just Nmap, to not only determine if the IP-HTTPS communication path is functioning, but to definitively determine that the DirectAccess server is the device responding.

Happy troubleshooting!

SSH Administration over a DirectAccess Connection

SSH Administration over a DirectAccess ConnectionFrom a client perspective, DirectAccess is an IPv6 only solution. All communication between the DirectAccess client and server takes place exclusively over IPv6. This can make things challenging for network engineers tasked with administering network devices using SSH over a DirectAccess connection. Often network devices don’t have corresponding hostname entries in DNS, and attempting to connect directly to an IPv4 address over a DirectAccess connection will fail.

To resolve this issue, it is necessary to create internal DNS records that resolve to IPv4 addresses for each network device. With that, the DNS64 service on the DirectAccess server will create an IPv6 address for the DirectAccess client to use. The NAT64 service will then translate this IPv6 address to IPv4 and connectivity will be established.

However, for many large organizations this might not be feasible. You may have hundreds or thousands of devices on your network to administer, and creating records in DNS for all these devices will take some time. As a temporary workaround, it is possible to determine the NAT64 IPv6 address for any network device and use that for remote network administration.

The process is simple. On a client that is connected remotely via DirectAccess, resolve the name of a known internal server to an IP address. The quickest and easiest way to do that is simply to ping an internal server by its hostname and note the IPv6 address it resolves to.

SSH Administration over a DirectAccess Connection

Now copy the first 96 bits of that address (everything up to and including the 7777::) and then append the IPv4 address of the network device you wish to manage in familiar dotted-decimal notation. The IPv6 address you create should look something like this:


Enter this IPv6 address in whichever tool you use to manage your network devices and it should work. Here’s an example using the popular Putty tool connecting via SSH to a network device in my lab.

SSH Administration over a DirectAccess Connection

Figure 1 – DirectAccess Client IPv6 Prefix w/Appended IPv4 Address

SSH Administration over a DirectAccess Connection

Figure 2 – Successful connection over DirectAccess with Putty.

Going forward I would strongly recommend that you make it part of your normal production implementation process and procedures to create DNS records for all network devices. In the future you’ll absolutely have to do this for IPv6, so now is a good time to get in the habit of doing this. It will make your life a lot easier, trust me!

Please note that adding entries to the local HOSTS file of a DirectAccess client does not work! The name must be resolved by the DNS64 service on the DirectAccess server in order to work properly. Although you could populate the local HOSTS file with names and IPv6 addresses using the method I described above, it would cause problems when the client was on the internal network or connected remotely using traditional client-based VPN, so it is best to avoid using the HOSTS file altogether.

DirectAccess and Windows Server 2012 R2 Core


DirectAccess and Windows Server 2012 R2 Core

Windows Server Core is an operating system configuration option that does not include a Graphical User Interface (GUI). Server Core was first introduced with Windows Server 2008 and originally included only a limited number of supported roles. With each subsequent release, Microsoft continues to add support for additional roles on Server Core. Beginning with Windows Server 2012, the Routing and Remote Access (RRAS) role, which includes DirectAccess, is a supported workload on Server Core.

Advantages of Server Core

There are a number of important advantages that come with running DirectAccess on Server Core. Server Core has a greatly reduced attack surface compared to the full GUI version, which is positive from a security perspective. Server Core also features a dramatically reduced footprint, consuming less RAM and disk space. System startup times are faster, and this refactored installation option also reduces servicing requirements (patching), eliminating many reboots and increasing availability and overall system uptime.

DirectAccess and Windows Server 2012 R2 Core

Figure 1 – Windows Server 2012 R2 Core Desktop (Yes, that’s it!)

Server Core Configuration

DirectAccess is a workload that lends itself well to running on Server Core, and I highly recommend leveraging this configuration whenever possible. Based on my experience, I suggest performing initial configuration and testing of the DirectAccess solution with the GUI installed, and then removing the GUI just before placing the DirectAccess server in to production. Removing the GUI can be accomplished by executing the following PowerShell command:

Remove-WindowsFeature Server-Gui-Mgmt-Infra –Restart

Once the server has been converted to Server Core, all administration must be performed at the command line on the server, or remotely from a management server or workstation using the command line or GUI administration tools. You can install the Remote Access Management console on any Windows Server 2012 R2 server using the following PowerShell command:

Install-WindowsFeature RSAT-RemoteAccess

Optionally you can download and install the Windows Server Remote Administrations Tools (RSAT) on a Windows client workstation, if desired.

Minimal Server Interface Configuration

If you prefer to be able to manage the DirectAccess server locally using the GUI, consider enabling the Minimal Server Interface. Minimal Server Interface is a configuration option that lies between Server Core and the full GUI interface. It features some of the benefits of Server Core, while at the same time providing local access to GUI management tools such as the Remote Access Management console. You can configure Minimal Server Interface using the following PowerShell command:

Remove-WindowsFeature Server-Gui-Shell -Restart

You can access the Remote Access Management console by entering RaMgmtUI.exe from the command line.

Revert to Full GUI

If at any point in the future you require the GUI for some reason, re-installing it can be accomplished using the following PowerShell command:

Install-WindowsFeature Server-Gui-Shell –Restart


With the Unified Remote Access role supported on Windows Server Core, consider implementing DirectAccess using this option to improve the security and increase the availability of your remote access solution. You’ll find that almost all ongoing server maintenance and support can be accomplished remotely using GUI tools, or locally using PowerShell. And if you ever need the GUI again, you can always add it back if necessary!

Windows 10 November Update Available Today

Windows 10 November Update Available TodayToday Microsoft announced the availability of the November Update (formerly Threshold 2) for Windows 10. With this update, Microsoft is now touting Windows 10 build 1511 as “enterprise ready”, with a number of key features and enhancements designed to drive enterprise adoption for the client operating system.

  • Performance Improvements – According to Microsoft, the Windows 10 November Update includes important improvements in performance, improving boot time almost 30% over Windows 7 installed on the same system.
  • Windows Update for Business – Windows Update for Business enables IT to control Windows update within their organization, allowing administrators to roll out updates on their schedule. New features with this service include creating device groups and enabling phased deployment of updates across the organization
  • Windows Store for Business – The Windows Store for Business provides IT with a mechanism to provision and manage apps for Windows 10 devices, both from the Windows Store and their own line-of-business apps.
  • Telemetry Control – Beginning with Windows 10 build 1511, enterprise customers will now have the ability to completely disable all Windows telemetry. Although not recommended, this feature is essential for many organizations to maintain the highest levels of security.

Since Windows 10’s release in late July of this year, enterprise customers have deployed Windows 10 on more than 12 million business PCs. Many organizations who have not yet upgraded are in the planning and pilot stages today, or will be soon. The enterprise adoption rate for Windows 10 continues to accelerate, and no doubt will do so even more with the release of Windows 10 build 1511.

Don’t forget that Windows 10 already includes a number of important security advancements such as Credential Guard to mitigate various credential theft attacks, Device Guard to prevent installation of malicious software, and Windows Hello to strengthen authentication with the use of biometrics. These features, along with the new capabilities and services introduced today, continue to make Windows 10 a compelling client operating system in the enterprise.

Of course the perfect complement to Windows 10 in the enterprise is DirectAccess. To learn more about how to maximize your investment in Windows 10 with DirectAccess, here are some essential references.

In addition, DirectAccess consulting services are also available. More details here.

Windows Clients Do Not Receive DirectAccess Configuration Changes

Windows Clients Do Not Receive DirectAccess Configuration Changes

A scenario can occur in which changes to the DirectAccess configuration made using the Remote Access Management console or at the command line using PowerShell are not reflected on the DirectAccess client, even after receiving the latest group policy updates. The issue occurs for DirectAccess clients that are provisioned with the Offline Domain Join (ODJ, or djoin.exe) tool.

When the ODJ provisioning package is initially created, it does not add the new computer account to the DirectAccess security group. The ODJ-provisioned client receives all DirectAccess configuration settings at the time of provisioning, but it will not receive subsequent changes to the DirectAccess configuration made after it was originally provisioned.

To resolve this issue, be sure to proactively add the DirectAccess client’s computer account to the appropriate DirectAccess security group in Active Directory after provisioning with ODJ using Active Directory Users and Computers (ADUC), the Active Directory Administrative Center (ADAC), or by executing the following PowerShell command:

Add-ADGroupMember -Identity [DirectAccess Client Security Group] -Members [computername]

Once the DirectAccess client has been added to the security group and restarted, it will then receive DirectAccess configuration settings changes going forward.


Get every new post delivered to your Inbox.

Join 107 other followers

%d bloggers like this: