In this four part series I will be going through implementing Microsoft Remote Access Server /VPN only solution on Windows Server 2016 and integrating it with RADIUS / NPS server for Authentication then add on it Azure MFA implementation for second/Multi Factor authentication for VPN Users as sending message or getting a call on your cell phone.

Few users reported recently that their DirectAccess is not working on their Laptops and its displaying the message "your computer is not configured correctly for directaccess. ipv6 is not enabled correctly"

I got couple of users using Windows 7 reporting that they can't connect using Direct Access anymore whether its HTTPS or Teredo, DA just won't work. Upon further discussing the issue with them they mentioned that they enabled and disabled the Direct Access Connectivity assistant (DCA) Use Local DNS couple of times in an effort to work it out.

We started troubleshooting by checking the Name Resolution Policy table and we noticed that the NRPT was not getting applied on the DA client as shown below.





The next step was checking the DA resolution using the netsh dns show state command and it turned to be disabled.




The DA client already has the correct group policies, certificates but its disabled.

The next step was checking the below registry key:

"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient EnableDAForAllNetworks"

Good news for all Microsoft UAG 2010 users, Service Pack 4 (SP4) was released officially yesterday to support Microsoft Latest Operating system Windows 8.1 and Internet Explorer 11 (IE 11). This new SP4 provides other important features as the support of Remote Desktop Connection RDC 8.1 and the Remote Apps published from Remote Desktop session Host on Windows 2012 or 2012 R2.

The Link to download the Latest SP4 is as follows:

https://www.microsoft.com/en-us/download/details.aspx?id=41181


For More details about features and fixes included in this Service Pack, please check the following link:

https://support.microsoft.com/kb/2861386


Service Pack 4 includes some other fixes as well as stability and performance enhancements, I will give it a try and hopefully it will be smooth operation.

I Purchased few weeks ago the Microsoft Surface Pro tablet, its a very nice production tablet that really enables remote users to run their production applications and workloads. There are still some room of improvement to get promoted as the number one choice of tablets for business users. From my point of view the three main things that need improvement are the Battery Life, 3G/4G connectivity option and better Camera.

Surface Pro comes with windows 8 Professional which is very nice and allows you to join your corporate network however it lacks a great feature which is Direct Access ! So I decided to turn it to fully productive device and install windows Enterprise on it. Its very simple as if you are building a new normal fresh computer.

I formatted the Surface drive however I kept the recovery image (for any future need), after finishing Windows Enterprise I installed the latest Surface Pro Firmware and Driver Pack http://www.microsoft.com/en-eg/download/details.aspx?id=38826

Finally I got my DirectAccess working on my Surface. That was really an exciting moment. Th next challenge was joining my domain MBAM/Bitlocker policy. Our MBAM / Bitlocker policy requires the use of a PIN while booting the computer. When the MBAM encryption wizard started I got the error 0x803100B7 Group Policy settings require the creation of a startup PIN, but a pre-boot keyboard is not available on this device and by checking the event viewer the following details were provided as per attached image

1. Type GPEDIT.MSC in the Run bar to access the local Group Policy Editor
2. Drill down to Computer Configuration - Administrative Templates - Windows Components - BitLocker Drive Encryption - Operating System Drives
3. Enable both "Require Additional Authentication at Startup" and "Enable use of BitLocker authentication requiring preboot keyboard input" - Check below image.

After upgrading our domain Controllers, DNS and DHCP servers to the latest Windows Server 2012, I noticed that our Windows 7 UAG DirectAccess clients are not able to RDP (Remote Desktop/MSTSC) to the new Server 2012 Domain Controllers. The same client can ping the 2012 Domain Controller and 2012 DNS server without any problem however all RDP traffic fails.


The weird thing was that at the same time these clients (Windows 7 DirectAccess UAG clients) can ping and RDP/MSTSC any other Windows 2012 member server without any problem at all.

I did some intensive checks and research on the Internet but could not find anything regarding Server 2012 domain controllers issues with UAG based Direct Access, As per Microsoft Escalation team recommendation we did a full tracing scenario on both the UAG and Windows 7 client. 

I tried to reproduce the problem while turning simultaneous capture on both the client and the UAG server using the below Scenario

I am a big fan of Microsoft DirectAccess technology, for those who are not aware of DirectAccess, Its Microsoft new Remote connectivity solution where users on the Internet get Intranet connectivity to their corporate network without installing any client or initiating any software like old traditional VPN.

Microsoft DirectAccess is purely based on IPV6 and Lync 2013 is fully supporting IPV6 and Lync 2013 clients using DirectAccess should work without any problem.

If any one encountered problems making Lync calls or connecting to Lync on a DirectAccess Computer then you need to ensure that IPV6 is enabled on the Lync 2013 Server as per the below image.




This can be achieved as follows:

1. Open the Lync 2013 Topology Builder from an old file or download the topology
2. Edit the properties of the Lync server and in the General Properties ensure that IPV6 is enabled.
3. These settings need to be published from the Action Menu - Topology - Publish

1. Configure the UAG server to have an IPV4 route to the new acquired network(s). 
2. Make sure that the new acquired Network(s) are added to the UAG internal Networks. This can be done from the UAG Admin Menu – Network Interfaces – Define Internal network IP address range.
3. The DNS servers used by the UAG and DirectAccess clients should be configured to resolve the acquired/Partner Domain either by having their DNS zone or by using conditional Forwarders.
4. Configure your DirectAccess clients to use a DNS suffix search list. This list should include their current original company domain and the newly acquired domain. You may want to test it manually to ensure its working however its preferred to be done on the UAG DirectAcccess clients OU using Group policy as per attached.

5. Microsoft UAG need to be configured to ensure that the client’s NRPT (Name Resolution Policy Table) instructs the client to contact UAG for name resolution of the acquired domain. This will be done from the DirectAccess UAG configuration Step 3 (Infrastructure Servers – DNS Suffixes) as shown below

6. Apply the new config/policy and Activate the UAG.
7. Finally run gpupdate /force on the client to refresh the client group policy. To ensure that the policy is updated on the DirectAccess client you can run the “netsh namespace show pol”.

Its been noticed on several Direct access deployments that the Client IPHTTPS interface gets connected first over the Teredo interface although nothing is preventing the Teredo interface to get activated. Most of the clients won't prefer the IPHTTPS because of its high overhead and low performance compared to Teredo or 6to4. After some investigation and consulting Microsoft esclation engineers it turned out that its a well known issue on several clients where the Teredo and IPHTTPS race together and IPHTTPS wins at the end due to timing issues. This is elaborated in details on the following Microsoft Technet article http://technet.microsoft.com/en-us/library/ee844161(WS.10).aspx


As per that attached below image extracted from the above mentioned article that this issue can occur and IPHTTPS will win and get qualified first.


 To test whether my client is in this condition, i ran IPCONFIG /ALL on my client machine and i noticed that i have public addresses on both my Teredo and IPHTTPS interface as per attached.

To make sure you are using always Teredo you can implement one of the following workarounds:

1. Disable IPHTTPSinterface from the Device Manager - View Hidden devices - Network adapters (unless you need IPHTTPS in locations where Teredo UDP port is blocked)
2. After logging and connecting using the IPHTTPS, Restart the "IP Helper" Service.

For more information about this issue please check Tom Shinder article http://blogs.technet.com/b/tomshinder/archive/2010/08/24/why-are-both-the-teredo-and-ip-https-interfaces-active.aspx

Also its recommended to patch the UAG/Direct Access server with the latest fixes related to Direct Access, the most recent updates/fixes are as follows:

http://support.microsoft.com/kb/2686921
http://support.microsoft.com/kb/2633127
http://support.microsoft.com/kb/2680464

During the past few months I was heavily engaged with different DirectAccess implementations and passed by several interesting issues/problems. The Direct Access Wizard is so simple and normally things get working from the first time however sometimes things can go wrong.

In this article series I will try to go through several troubleshooting items moving from the basic commands to more advanced issues.
First of all we need to ensure that the Direct Access components on the Windows 7 client are running and functioning normally. The basic steps are as follows:

1. From the Start Menu - Right Click Computer Object – Properties – Device Manager – View (Show Hidden Devices) – Expand Network Adapters – Ensure the “IPHTTPSinterface” and “Teredo Tunneling Pseudo-Interface” are enabled.
2. From the Services, Check the “IP Helper” service startup type is Automatic and the status is up and running.
3. IPconfig /all to check which interfaces are up and which interfaces have IPV6 address.
4. Ensure the Machine is located outside the Corporate Network by running the following command:

Recently I tried publishing the UAG Web Monitor on my External HTTPS Web Portal, the UAG web monitor is very useful monitoring and reporting web application which gives you the ability to view different UAG sessions, applications, Direct Access and the UAG event viewer.

When the UAG Web Monitor is published on the UAG Portal Trunk everything works fine except the Direct Access section (Current Status and Active Sessions). When you try to open the Current Status or Active Sessions you get the below error screen.

1. Go to the Trunk Configuration - Configure Trunk Settings - Configure - URL set.
2. Copy any Web Monitor default rule and paste it 5 times
3. Modify/Add the URL in the 5 rules as follows:
1. /damonitor\.asp
2. /damonitorcurrentstatus\.asp
3. /damonitorcurrentstatusrefresh\.asp
4. /damonitoractivesessions\.asp
5. /damonitoractivesessionsrefresh\.asp
4. Save- Activate and this should fix the issue.