Windows 8 DirectAccess Client Quick Tip

On a Windows 8 or 8.1 DirectAccess client, issuing a Get-DAConnectionStatus may return the following error:

Get-DAConnectionStatus : Network Connectivity Assistant service is stopped or not responding.
At line:1 char:1
+ Get-DAConnectionStatus
+ ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MSFT_DAConnectionStatus:root/StandardCi...onnectionStatus) [Get-DAConnect
   ionStatus], CimException
    + FullyQualifiedErrorId : Windows System Error 1753,Get-DAConnectionStatus

DirectAccess Connectivity Assistant Error

This issue is easily resolved by starting the Network Connectivity Assistant service by issuing the following PowerShell command:

Start-Service ncasvc

Get-DAConnectionStatus should now respond normally.

DirectAccess Connectivity Assistant Error

Windows Server 2012 DirectAccess Session at TechEd 2013

Are you planning to attend Microsoft TechEd this year? If so, I’m happy to announce that I’ll be delivering a session entitled “The Future Is Now! Next Generation Remote Access Today with Windows Server 2012 DirectAccess”. I’ll be presenting at both TechEd North America in New Orleans, LA, and at TechEd Europe in Madrid, Spain. Looking forward to seeing you there!

Microsoft TechEd North America 2013

Microsoft TechEd Europe 2013

DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

%d bloggers like this: