Correcting Direct Access Configuration Errors
Correcting Direct Access Configuration Errors
One of the labs within the Configuring Windows 8/8.1 course (20687D) enables students to experience Microsoft Direct Access. Admittedly the virtual environment is pre-staged and the experience is more truly designed to help participants understand the steps required to use Windows 8.1 as a Direct Access Client. The challenge in this case is aiding students who typically lack both administrative experience and Windows 8/8.1 exposure to configure both a Windows Server 2012R2 and a Windows 8.1 client to facilitate a relatively complex interaction.
The Server 2012R2 Direct Access configuration wizard vastly simplifies the process that existed in Windows Server 2008R2, albeit handles some tasks as background efforts without indicating intended completion or suggesting comprehensive alternatives during execution. As such, if an error occurs the potential cause is not as readily identified.
Even the step-by-step lab instructions in the 20687D course are subject to error. The smallest error can cause the entire sequence to fail. As luck would have it, only one student in a recent class was able to successfully complete the Direct Access lab in a single pass. Fortunately, the Hyper-V environment enables one to revert a system and try again. That is, if you can determine the cause of your initial error and avoid it during the second pass.
The complexity of the Direct Access service environment lends itself to configuration errors. In actual application, system reversion, particularly for an active server, is not an option. We spent an hour attempting to recover lab errors without reverting, and ultimately identified the root cause, though not an obvious and simplified repair.
Thanks to Rick Trader, one of the Interface Staff Instructors with extensive server and Direct Access experience, we were able to resolve the configuration issues for future classes. The lessons learned might be useful, so I am sharing them in this blog.
As basic background Microsoft Direct Access requirements for Server 2012R2 offer a variety of configuration scenarios. Minimally, the solution requires:
- A Windows (2008 SP2, 2008R2, 2012, or 2012R2) Domain controller with a security group into which Direct Access clients become members (e.g. DA_Clients).
- A DNS system, that may run on one of the above systems or be implemented separately, to resolve required server names and aliases.
- Windows 7 Enterprise or Ultimate, Windows 8 or Windows 8.1 Enterprise clients. The client needs to be joined to the domain, added to the DA_Clients group, and receive relevant Group Policy while within the network.
- A PKI infrastructure for Windows 7 clients, although the PKI infrastructure is not required for Windows 8/8.1 clients.
- Windows Firewall with protocols properly enabled for connectivity between servers and client components.
- A Windows 2008R2, 2012, or 2012R2 server with the Routing and Remote Access role and related Direct Access features enabled and properly configured. This server is typically placed at a network Edge, and requires two Network Interface Cards, one internal and one external.
- IPv6 and IPSEC enabled on both the Direct Access Server and the Windows 8/8.1 client. These are default features and need to remain enabled.
- Additional protocol, network, and interface configuration elements depending upon one of several modes of operation selected from amongst the requirements.
All of the required components are available in the 20687D virtual lab environment, and were correctly enabled. With one exception. The Windows Server 2012R2 virtual image settings enable two NICs. An early step, documented within the lab overview, although omitted in the step-by-step instructions, requires the student to enable the secondary NIC (which is by default disabled) using Powershell or the Control Panel.
NIC in Disabled State
NIC in Enabled State
Since the systems are preconfigured for the lab including static IP addresses, DNS names, Domain generation, and default Group Policy creation, the only root cause in this instance, was a failure to enable the NIC prior to enabling the Remote Access role and configuring the Direct Access feature.
Once properly configured, and rebooted once, the Direct Access Feature Dashboard (using Server Manager > Tools > Remote Access Management Con sole) should look like the following exhibit. The highlighted IP-HTTPS status should also be green as shown.
Once a student identifies the NIC as being disabled, typically while running the Direct Access Configuration Wizard, it is a simple task to enable the NIC and continue the wizard. But wait! The status of the IP-HTTPS element presented in bold red preceded by a red X. Attempts to re-run the wizard generate additional error messages or result in incompatible default values when viewed through either the wizard or the manual configuration panels. Several different setting errors were identified, and even a full feature roll back in one instance, due solely to the step in the sequence at which the NIC is enabled. An attempt to remove the role and start anew created the same error. We checked every value, running step by step through the manual configuration panels for Remote Access Setup. To no avail.
An exhibit of the interface showing steps 2 through 4 of the manual configuration process is shown below.
Then we requested Rick’s assistance.
We followed the entire course of recommendations for correcting the IP-HTTPS: Not working scenario as recommended on Technet DirectAccess Setup – IP-HTTPS: Not working properly. This includes a manual Registry edit. Again to no avail.
Symptoms suggested firewall setting errors, failure to establish domain connections, no IIS service. All working.
I looked through several TechNet and support articles looking for possible solutions, including:
- Cannot Run the Direct Access Setup Wizard
- Direct Access Configuration Load Error
- Direct Access Deployment Guide
- Enable DirectAccess on Windows Server 2012 Essentials
Many alternatives and considerable redirection to alternative content.
And now the simple solution – thank you again, Rick – Select the Remove Configuration settings wizard.
Allow the configuration software to undo all of the settings, including the background elements not visible or configurable through the manual interfaces.
Despite page after page of internet searching, and lots of complicated manual changes and corrections, I didn’t find any recommendations that suggest using the Remove Configuration Settings wizard first. Then correct the root cause elements.
Then rerun the Run the Getting Started Wizard.
Voila! Following a few minutes and selecting refresh once or twice, the connections were configured and established as expected.
Sometimes you can learn more in the classroom than through volumes of online materials.
You May Also Like
Direct Access, Direct Access Server, IP-HTTPS, IP-HTTPS error, Microsoft Direct Access requirements, remote access, Remote Access Configuration Error, Remove Configuration Settings, Rick Trader, Routing and Remote Access, Windows 2012R2, Windows 8, Windows 8.1
In this video, you will gain an understanding of Agile and Scrum Master Certification terminologies and concepts to help you make better decisions in your Project Management capabilities. Whether you’re a developer looking to obtain an Agile or Scrum Master Certification, or you’re a Project Manager/Product Owner who is attempting to get your product or … Continue reading Agile Methodology in Project Management
In this recorded Windows 10 webinar from December 1,2015, Windows Instructor Steve Fullmer presents the navigation and some of the new features associated with Windows 10 including Sysinternals Tools for Windows Client, Windows core concepts, exploring Process Explorer as well as some of the features that are not yet ready for prime time but will … Continue reading Windows 10 Features and Navigation – December 1, 2015
How does an investigator hunt down and identify unknown malware? In this recording of our IT Security training webinar on April 21, 2015, Security expert Mike Danseglio (CISSP / CEH) performed several malware investigations on infected computers and identify symptoms, find root cause, and follow the leads to determine what’s happening. He demonstrated his preferred … Continue reading Detailed Forensic Investigation of Malware Infections – April 21, 2015