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
+ CategoryInfo : NotSpecified: (MSFT_DAConnectionStatus:root/StandardCi...onnectionStatus) [Get-DAConnect
+ FullyQualifiedErrorId : Windows System Error 1753,Get-DAConnectionStatus
This issue is easily resolved by starting the Network Connectivity Assistant service by issuing the following PowerShell command:
Get-DAConnectionStatus should now respond normally.
Posted by Richard M. Hicks on October 1, 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!
Posted by Richard M. Hicks on May 9, 2013
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.
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.
Posted by Richard M. Hicks on March 19, 2013
I’m pleased to announce that my Windows Server 2012 DirectAccess video training course is now available from TrainSignal! The course covers planning, installing, and configuring DirectAccess in Windows Server 2012 in a variety of different deployment scenarios. Here’s the course outline:
Lesson 1 – Introduction
Lesson 2 – DirectAccess Overview
Lesson 3 – Planning for DirectAccess
Lesson 4 – Configuring DirectAccess (Simplified Deployment)
Lesson 5 – Configuring DirectAccess (Complex Deployment)
Lesson 6 – Configuring DirectAccess (Multi-site Deployment)
Lesson 7 – Enabling Support for Windows 7 DirectAccess Clients
Lesson 8 – Enabling High Availability with Network Load Balancing
Lesson 9 – DirectAccess Monitoring and Reporting
Lesson 10 – DirectAccess Troubleshooting
Lesson 11 – Enabling Legacy Remote Access VPN
Special thanks goes to my friend and fellow MVP Jordan Krause who served as the technical reviewer for this series and provided valuable input and feedback during the production of the course. Before you implement DirectAccess with Windows Server 2012, be sure to sign up for a subscription at Trainsignal.com and not only will you receive this great DirectAccess training course, you’ll have access to the entire TrainSignal library of content for just $49.00 per month!
Posted by Richard M. Hicks on March 11, 2013
With the recent release of Service Pack 3 (SP3) for Microsoft Forefront Unified Access Gateway (UAG) 2010, Microsoft has published a list of features in UAG SP3 that have been deprecated. To be clear, this does not mean these features cease to function after you install SP3 on UAG! It is simply meant to give network engineers and security administrators an idea about what features are likely to be removed from future releases of Forefront UAG. Some of the deprecated features should come as no surprise. For example, DirectAccess support in Forefront UAG is now deprecated in favor of DirectAccess in Windows Server 2012. Also, features such as Secure Sockets Tunneling Protocol (SSTP) for client-based remote access are better handled using the remote access role in Windows Server 2012. Other deprecated features may present more of a challenge if you’ve been relying on them to provide secure remote access to applications, such as the deprecation of support for some authentication repositories (e.g. Novell Directory, Notes Directory, TACACS) or the Java-based Session Cleanup tool. For a complete list of deprecated features in Forefront UAG SP3, click here.
Posted by Richard M. Hicks on February 26, 2013
This month Microsoft released an important hotfix to address a DirectAccess connectivity issue for Windows 7 clients connecting to a Windows Server 2012 DirectAccess Server. The hotfix specifically resolves an issue where Windows 7 clients face a very long delay reestablishing a DirectAccess session using the IP-HTTPS IPv6 transition protocol after recently disconnecting from a VPN session. In this scenario, Windows 7 DirectAccess clients may take as long as 15 minutes to automatically reestablish a DirectAccess session using IP-HTTPS. During this time the IP-HTTPS adapter state is displayed as disconnected. Refer to Microsoft KB 2796313 more information and to download the hotfix.
Posted by Richard M. Hicks on February 17, 2013
With Windows Server 2008 R2, IP-HTTPS used standard SSL cipher suites to encrypt sessions. However, those sessions are already encrypted using IPsec, which is needlessly redundant. The protocol overhead for this double encryption placed an extreme burden on the DirectAccess server in terms of CPU utilization and memory consumption. Throughput and performance suffered greatly in large deployments. To address this issue, Microsoft included two new SSL cipher suites in Windows Server 2012 and Windows 8 that use NULL encryption. IP-HTTPS sessions are fully authenticated, but encrypted only once using IPsec. This significantly reduced resource demand on the DirectAccess gateway and improves performance greatly. Unfortunately, only Windows 8 clients can take advantage of this new IP-HTTPS functionality in Windows Server 2012 DirectAccess. When Windows 7 clients establish an IP-HTTPS session with a Windows Server 2012 DirectAccess gateway they will still request the use of fully encrypted cipher suites, as shown here:
Windows 7 IP-HTTPS Client Hello
Windows 8 IP-HTTPS Client Hello
Windows 8.1 IP-HTTPS Client Hello
So, if you want to take advantage of the IP-HTTPS performance improvements in Windows Server 2012 DirectAccess, be sure to use Windows 8 clients!
Update: Recently with the help of the folks at F5, I developed a solution to emulate Windows 8 client behavior for Windows 7 DirectAccess clients using the F5 BIG-IP Local Traffic Manager (LTM). Using this technique allows you to *effectively* offload SSL for Windows 7 DirectAccess clients. Fore more details click here.
Posted by Richard M. Hicks on February 15, 2013
With the recent release of the Microsoft Surface Pro, many people have been asking me about DirectAccess connectivity for these devices. One of the requirements for DirectAccess connectivity is that the device be joined to a domain, a capability that the Surface RT lacked. Although the Surface Pro runs the full version of Windows 8, it is Windows 8 Professional. Sadly, DirectAccess connectivity is only supported for Windows 8 Enterprise edition clients, along with Windows 7 Enterprise and Ultimate editions.
So, if you have just purchased a new Microsoft Surface Pro and are hoping to configure it as a DirectAccess client, I’m afraid you’re out of luck. In my opinion, the lack of DirectAccess support for Windows 8 and Windows 7 Professional is a serious flaw, especially when you consider all of the great use cases you can imagine when you have a full featured tablet with always-on, secure remote network connectivity. It’s a shame, really. Let’s hope this changes in the future!
Update: Read my post on how to install Windows 8 Enterprise and configure DirectAccess on the Microsoft Surface Pro here.
Posted by Richard M. Hicks on February 10, 2013
Microsoft recently released a Monitoring Pack for System Center Operations Manager 2012 specifically targets the Remote Access role in Windows Server 2012. With this new monitoring pack, a systems management engineer can monitor a Windows Server 2012 server with the remote access role installed for the following conditions:
- Network interface connection and settings issues
- IPv6 transition protocol configuration
- DoS, spoof, and replay attack heuristics
- IPsec state
- DNS and management server configuration
- Underlying service status
- OTP-related heuristics
Remote Access and Site-to-Site VPN
- Connection failures
- Improper configuration
- Hardware device and IPsec related failures
- Monitoring of performance counters and instrumentation
This management pack leverages PowerShell cmdlets such as Get-RemoteAccess, Get-DAMultisite, and Get-RemoteAccessHealth. As such, only Windows Server 2012 is supported by this management pack. You can download the System Center Operations Manager 2012 Monitoring Pack for the Windows Server 2102 Remote Access role here.
Posted by Richard M. Hicks on January 31, 2013