Tag Archives: Direct Access

Directaccess in Windows 8 and Server 2012 – Hotfix frenzy

Windows Server 2012 DirectAccess includes a number of enhanced features and improvements as below:
⦁ Direct Access and RRAS coexistence
⦁ Simplified Direct Access management/setup for small and medium organization administrators
⦁ Built-in NAT64 and DNS64 support for accessing IPv4-only resources
⦁ Support for Direct Access server behind a NAT device
⦁ Load balancing support
⦁ Support for multiple domains
⦁ Support for OTP (token based authentication)
⦁ Automated support for force tunneling
⦁ Multisite support
⦁ Windows PowerShell support
⦁ User and server health monitoring

I’ve now done a couple of DirectAccess implementations (both small scale and large scale) and I must say that most things works very well and straightforward.

There are however a couple of hotfixes that you may have to apply, if you for example are enabling external load balancing in your implementation.
Below is a summary of the hotfixes that have been useful in my different implementations of DirectAccess

Windows Server 2012 and Windows 8 – DirectAccess Related Hotfixes:
KB2782560: DNS64 does not resolve computer names when you use DirectAccess and external load balancing in Windows Server 2012.

KB2788525: You cannot enable external load balancing on a Windows Server 2012-based DirectAccess server.

KB2769240: You cannot connect a DirectAccess client to a corporate network in Windows 8 or Windows Server 2012.

KB2748603: The process may fail when you try to enable Network Load Balancing in DirectAccess in Window Server 2012.


SCM 3.0 Windows 8 Baseline breaks Direct Access IPHTTPS Connectivity

When playing with SCM 3.0 and Windows 8 in my lab environment recently, I got an unpleasant surprise with my Direct Access connectivity in the Environment.

The Windows 8 client wouldn’t connect with IPHTTPS. When doing the usual troubleshooting with the netsh commands (netsh interface httpstunnel show interfaces) etc. I got the output “IPHTTPS interface not installed”.

That output usually shows up when you’re inside the corporate network.

When troubleshooting further I found out that the system event log were full with error 36874/Schannel as below.


The setting causing the problem was “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signingunder “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options” .

The setting was Enabled by SCM and is by default Disabled.


After changing back the setting to Disabled I restored the IPHTTPS connectivity in my environment.

I am planning to follow this up as FIPS compliance is important for many organisations.