Back to Direct Access main menu
DirectAccess has become a vital resource in many enterprise environments. We implement High Availability for technologies like SQL and Exchange so why should DirectAccess be any different? The good news is that it's easy to do so.
We've previously deployed a single server DirectAccess solution (lets call this server RAS1). Then we moved the NLS to a remote web server. Now we will implement HA for the solution. The following are the basic steps.
- Add NLB feature to RAS1
- Build new Windows 2012R2 Server RAS2
- Add Remote Access role and NLB feature to RAS2
- Export IPHTTPS listener certificate from RAS1 and import to RAS2
- Enable MAC spoofing on virtual NICs
- Enable Load Balancing
- Add second server to Load Balanced cluster
1. Add NLB feature to RAS1
3. Add Remote Access role and NLB feature to RAS2
4. Export IPHTTPS listener certificate from RAS1 and import to RAS2
Export certificate from RAS1
Import to RAS1
5. Virtual NICs
Enable MAC spoofing
Enable MAC spoofing on the virtual NICs of RAS1 and RAS2
Second NIC
You can implement this solution with a single NIC per server. However it is better practice to use two. The second NIC, for NLB communication, should be configured in separate subnet with no default gateway.
6. Enable Load Balancing
Launch the Remote Access Management console on RAS1.. Open the configuration.
On the bottom right of the window select "Enable Load Balancing".
The "Enable Load Balancing" wizard is launched. Click Next.
Choose NLB as the cluster method (note that you can configure the solution to use an external load balancer).
Enter an available IP address. The wizard is quite smart here. It knows that DirectAccess is already working with a single server solution (RAS1). DNS records and firewall rules have been created and we don't want to have to amend these. Therefore the wizard swaps the IP addresses.
The working dedicated IP address of RAS1 (DIP) becomes the Virtual IP address of the NLB cluster (VIP).
The new available IP address becomes the IP address of RAS1. Pretty clever.....
Verify the settings and "Commit".
Review progress.
Click Close to return to the wizard.
Verify success and close the wizard.
See what has happened. A load balanced cluster has been created with a single node (RAS1).
Note that the IP address of RAS1 has changed.
7. Add second server to cluster
Now, on the bottom right of the Remote Access Management configuration window, choose "Add or Remove Servers".
Select "Add Server".
Browse to choose RAS2.
Ensure that the correct NIC is selected.
Verify the settings and click Add.
Close the wizard.
"Commit" the changes.
Verify progress.
Close the "Adding or Removing Servers" wizard.
See that the second node has been added to the load balanced cluster.
Verify that the nodes are operating correctly.
Issues Encountered
I encountered a couple of issues during this configuration.
Firstly the wizard did not seem to add both nodes to the NLB cluster. When I opened the Network Load BaIancing Manager I noticed that only one node was present. I had to add the second node manually.
Also, my DirectAccess solution broke after I introduced NLB. I found that this was due to the fact that my customer had a series of firewalls with some kind of one-to-one NATing throughout. This played havoc with the NLB traffic. This was solved by introducing Dynamic NAT rules.
Back to Direct Access main menu
Previously we implemented Direct Access in five easy steps using a single server. In production additional configuration is required to implement a best practice solution.
The Network Location Server is a key component of DirectAccess. Its purpose is to detect whether computers configured as DirectAccess clients are located in the corporate network. When clients are in the corporate network, DirectAccess is not used to reach internal resources. Instead, clients connect to internal resources directly.
The network location server is simply a Web site with an HTTPS server certificate. It should be located on a remote web server (not the DirectAccess server - which has the Remote Access role). It is also good practice to have multiple NLS servers in a Highly Available configuration.
This blog post demonstrates how to move the NLS configuration to a remote web server.
First you need a web server. Install IIS as normal.
Next you will need an SSL certificate. Note that you can use a self-signed certificate when the NLS is co-located with the DirectAccess server. However you can't on a remote web server.
In my example I used my Internal CA and requested a certificate using the Web Server template (using the Certificates Snap-In).
See that further information is required.
The Common Name is the FQDN of the web server (eg nlsweb.contoso.local).
Web Server certificate has been installed.
Add https to site binding and configure to use the new certificate.
Now, back at the DirectAccess server, open the Remote Access Management console.
Edit the Infrastructure Servers section (Step 3).
Enter the URL of the remote server (in the format https://nlsweb.contoso.local) and click to Validate. You will not be able to continue if the URL is incorrect and you cannot validate.
Apply the new settings.
Close the wizard.
Now test your configuration. DirectAccess clients should still be able to connect as normal.
Back to ConfigMgr main menu
Back to MDM Menu
Collection of Windows Phone 8 devices
select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System inner join SMS_G_System_DEVICE_OSINFORMATION on SMS_G_System_DEVICE_OSINFORMATION.ResourceID = SMS_R_System.ResourceId where SMS_G_System_DEVICE_OSINFORMATION.Platform like "Windows Phone" and SMS_G_System_DEVICE_OSINFORMATION.Version like "8.0%"
Collection of Windows Phone 8.1 devices
select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System inner join SMS_G_System_DEVICE_OSINFORMATION on SMS_G_System_DEVICE_OSINFORMATION.ResourceID = SMS_R_System.ResourceId where SMS_G_System_DEVICE_OSINFORMATION.Platform like "Windows Phone" and SMS_G_System_DEVICE_OSINFORMATION.Version like "8.1%"
Collection of Windows RT devices
select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Model like "Surface%"
Collection of iPhones
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_DEVICE_COMPUTERSYSTEM on SMS_G_System_DEVICE_COMPUTERSYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_DEVICE_COMPUTERSYSTEM.DeviceModel like "%iphone%"
Collection of iPads
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_DEVICE_COMPUTERSYSTEM on SMS_G_System_DEVICE_COMPUTERSYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_DEVICE_COMPUTERSYSTEM.DeviceModel like "%ipad%"
Collection of Android devices
select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System inner join SMS_G_System_DEVICE_OSINFORMATION on SMS_G_System_DEVICE_OSINFORMATION.ResourceID = SMS_R_System.ResourceId where SMS_G_System_DEVICE_OSINFORMATION.Platform like "Android%"
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.
