Direct Access Easy Step 5: Windows 8 Client and troubleshooting

Back to Direct Access main menu

That's it. We have finished the configuration. Now we will verify the Direct Access connectivity using  a Windows 8 client.

We enable Direct Access for a client device by adding the computer account to the Active Directory Security Group we previously created.

While connected to the Corporate LAN

Restart the test computer so that the computer account permissions can be updated and run gpupdate/force to update Group Policy.

No further configuration is necessary. The rest of our work is verification and troubleshooting.

Verify Group Policy on the test computer. Open the Registry > HKEY_LOCAL_MACHINE

See the Network Connectivity Assistant Registry keys.

Disconnect from the Corporate LAN

At this point you will see the new Workplace Connectivity icon (click on the network icon in the system tray).

The status of the Workplace Connection should say "Connected" (if you have an Internet connection).

If it is you can now browse corporate resources.

Type ipconfig/all in a command prompt. See that the iphttpsinterface is active.

Ping a resource using NetBIOS name only.

Troubleshooting

If the Workplace connection is not available but Group Policy has been updated.

Verify that the Network Connectivity Assistant Service is started

If you cannot start this service look in the Event log for errors. You may see an error that "This request is not supported".

In that case run msinfo32 command to look at the computer properties. Verify that the OS version is indeed Windows 8 Enterprise (not Windows 8 Pro).


If the Workplace connection is available but not connected (status Connecting) there are a couple of troubleshooting steps to take.

1. DirectAccess log file

Right click the Workplace Connection and click "View Connection Properties".

See the DirectAccess Properties.

 
Click "Collect Logs" for advanced troubleshooting.

You can now "View logs" to open the file location (or email logs to a System Admin for assistance). We configured this email address in Step 4.

Open the Log file.

The log file contains extensive configuration information.

2. DNS

Verify that the following A records have successfully been created in DNS

Remote Access creates a default web probe that is used by DirectAccess client computers to verify connectivity to the internal network. During configuration of the single server the following names should have been registered in DNS:

directaccess-WebProbeHost—should resolve to the internal IPv4 address of the Remote Access server, or to the IPv6 address in an IPv6-only environment.

directaccess-CorpConnectivityHost—should resolve to a localhost (loopback) address (either ::1 or 127.0.0.1, depending on whether IPv6 is deployed in the corporate network).

3. Windows Firewall.

When a Windows 8 device cannot connect to Corporate Resources via Direct Access this is normally the culprit.

The Windows Firewall MUST be enabled and it is configured by Group Policy to allow the connections.

Windows Firewall MUST be enabled.

Verify the Connection Security rules. Note the DirectAccess Policy - ClientToCorp.

Open the policy and view the Authentication tab. Note that first authentication is computer certificate and the second authentication is the user account (both Kerberos).

See the Main mode

and Quick Mode details of a successful Direct Access connection.

4. External Firewall.

In Step 1 we created a DNS record (eg da.contoso.com) and this was configured to direct https traffic (port 443) to one of our Public IP addresses. Our firewall was configured to allow this traffic and a NAT rule was configured to divert this traffic to the Direct Access sever.

Test this configuration by using telnet at a command prompt.

telnet da.contoso.com 443

If the firewall has been configured correctly a connection will be made (you will be presented with a blinking cursor but a connection has been made).

If you cannot make a connection then the firewall is not configured correctly.