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.

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.

DirectAccess Manage Out from Windows 10 Does Not Work

For DirectAccess manage out deployments using ISATAP, you may encounter a scenario in which you are unable to initiate outbound connections to connected DirectAccess clients from a Windows 10 computer. Outbound connections using ISATAP from Windows 7, Windows 8, Windows Server 2008/R2, or Windows Server 2012/R2 systems work without issue.

DirectAccess Manage Out from Windows 10 Does Not Work

As it turns out, there is a bug in the Windows 10 DNS client code that prevents manage out using ISATAP from a Windows 10 client from working correctly. Thanks to the diligent effort of DirectAccess administrators Mike Piron and Jason Kuhns, a workaround has been identified. To deploy the workaround, it will be necessary to implement registry changes to alter the default behavior of the DNS resolver in Windows 10. You can implement these changes on a Windows 10 DirectAccess manage out machine by using the following PowerShell commands:

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 1 -Force

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 1 –Force

Once these registry changes have been made, you should now be able to use ISATAP for DirectAccess manage out connections from a Windows 10 machine.

Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess


DirectAccess and Windows 10 - Better Together

The Microsoft Surface Pro 4 was made available for sale to the public on October 26, 2015. The latest in a line of powerful and flexible tablets from Microsoft, the Surface Pro 4 features a full version of the Windows 10 desktop client operating system and includes more available power, memory, and storage than previous editions. Significant improvements were also made to the keyboard and pen. The Surface Pro 4 is designed to be an all-in-one laptop replacement, enabling users to carry a single device for all of their needs.

Surface Pro 4 and the Enterprise

Microsoft is pushing the Surface Pro 4 heavily to large enterprise organizations by expanding the resale business channel and offering the device through companies like Dell and HP. In fact, Microsoft has made the Surface Pro 4 available through more than 5000 business resellers in 30 global markets. This new enterprise sales initiative strives to deliver world class service and support for enterprise customers adopting the new Surface Pro 4, and includes a new warranty offer and a business device trade-in program designed to promote the adoption of Surface and Windows 10 in the enterprise.

Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess

In addition, Microsoft will have a training program for IT management and support professionals as well as new Windows users that will help streamline the deployment of the Surface Pro 4 and Windows 10. Organizations are rapidly adopting the Surface Pro 4 and Windows 10, as Microsoft has already signed on a number of high-profile companies in the retail, financial services, education, and public sector verticals. Today, Microsoft has deployed Windows 10 to over 110 million devices since it was released in late October 2015, making it the most rapidly adopted operating system in their history.

Enterprise Requirements

One of the primary motivating factors for enterprise organizations migrating to the Surface Pro 4 is cost reduction. The Surface Pro 4 functions as both a full PC and a tablet, eliminating the need for users to carry two devices. More importantly, it eliminates the need for IT to procure, manage, and support two different hardware and software platforms (for example a Windows-based laptop and an iPad). Additionally, IT organizations can leverage their existing Windows systems management infrastructure and expertise to deploy and maintain their Surface devices.

DirectAccess and the Surface Pro 4

For organizations seeking to maximize their investment in the Surface Pro 4 with Windows 10, implementing a secure remote access solution using Windows Server 2012 R2 DirectAccess is essential. DirectAccess provides seamless and transparent, always on secure remote corporate network connectivity for managed (domain-joined) Windows clients. DirectAccess enables streamlined access to on-premises application and data, improving end user productivity and reducing help desk costs. DirectAccess connectivity is bi-directional, making possible new and compelling management scenarios for field-based assets. DirectAccess clients can be managed the same way, regardless if they are inside or outside of the corporate network. DirectAccess ensures that clients are better managed, consistently maintained, and fully monitored.

Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess

Windows 10 and DirectAccess

The Surface Pro 4 with Windows 10 provides full support for all enterprise features of DirectAccess in Windows Server 2012 R2, including automatic site selection and transparent fail over for multisite deployments, as well as scalability and performance improvements. In addition, supportability for Windows 10 clients is much improved with DirectAccess GUI integration and full PowerShell support. Additional information about how DirectAccess and Windows 10 are better together, click here.

Additional Cost Savings

Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess

DirectAccess does not require any additional software to be installed on the client, and does not incur per user licensing to implement. Another benefit is that DirectAccess can easily be deployed on most popular hypervisors such as Hyper-V and VMware, eliminating the need for expensive proprietary hardware-based remote access solutions and taking full advantage of current investments in virtual infrastructure. Additionally, existing Windows systems management skill sets can be leveraged to support a DirectAccess implementation, eliminating the need for expensive dedicated administrators.

Note: Windows 10 Enterprise edition is required to support DirectAccess, and it is assumed that large organizations will be deploying Surface Pro 4 with Windows 10 Enterprise.


The Surface Pro 4 is the thinnest, lightest, and most powerful Surface tablet ever. It features Windows 10, and it can run the full version of Office and any other applications you need. The Surface Pro 4 is aimed squarely at large enterprises, governments, and schools. Not coincidentally, these verticals are also excellent uses cases for DirectAccess. DirectAccess is the perfect complement to the Surface Pro 4 and Windows 10 in the enterprise, as it helps organizations address the unique pain points of large scale enterprise adoption of Windows devices. DirectAccess allows the Surface Pro 4 to be much more effectively managed, while at the same time significantly improving the end user experience.

To realize the full potential of your Windows 10 and Surface Pro 4 deployment, consider a DirectAccess consulting engagement. By leveraging our experience you’ll have the peace of mind knowing that you have deployed DirectAccess in the most optimal, flexible, secure, and highly available manner possible. For more information about a DirectAccess consulting engagement, click here.

Configuring Multicast NLB for DirectAccess


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.

DirectAccess, Windows 10, and Network Access Protection (NAP)

Windows 10, DirectAccess, and NAPFirst introduced with Windows Server 2008, Microsoft Network Access Protection (NAP) is a technology that allows IT administrators to create and enforce system health requirements that must be met before a computer can connect to the network. Common NAP enforcement points include Ethernet switches (802.1x), DHCP, IPsec, remote access VPN, and Terminal Services Gateway (TS Gateway) connections. DirectAccess also supports NAP integration, which allows administrators to extend this solution to include their DirectAccess clients.

Unfortunately, NAP has proven not to be very popular, and the adoption rate for this technology has been quite minimal. With that, Microsoft formally deprecated NAP in Windows Server 2012 R2, and removed it completely from Windows Server 2016.

Crucially the plumbing for NAP integration in the Windows 10 client operating system has also been removed. For DirectAccess deployments that have been configured to use NAP, this obviously presents a problem. In this scenario, Windows 7/8 clients will function normally. However, Windows 10 clients will not be able to connect. Since NAP integration with DirectAccess is a global setting, all clients must conform to NAP. There is no option to exclude only Windows 10 clients from NAP.

DirectAccess, Windows 10, and NAP

There are two ways in which to resolve this problem. The first is simply to disable NAP integration. However, if you still want to enforce NAP requirements for Windows 7/8 clients, but at the same time also want to allow Windows 10 clients to use DirectAccess, a separate dedicated DirectAccess deployment without NAP integration configured will have to be deployed to support Windows 10 DirectAccess clients.


Get every new post delivered to your Inbox.

Join 95 other followers

%d bloggers like this: