For anyone running DirectAccess that is based on Server 2012, you probably know that your Remote Access Management Console has the nice feature of showing you what users and computers are currently connected, and even what resources they are touching. This is a very nice feature, but there has recently been a problem discovered with this part of the console, that it continues to hold onto this information until the service is restarted. Microsoft has released a hotfix to be installed on the DirectAccess server to resolve this Remote Access Management Console memory leak:
News & Notes from IVO Networks
April 2nd, 2014
February 27th, 2014
Microsoft has recently released an interesting new tool for DirectAccess admins. The DirectAccess Client Troubleshooting Tool is a small, easy to use utility that can help diagnose DirectAccess connections gone wrong. Development is still happening on this tool, so expect more versions, but it’s a nice way to run a quick check on the status of DA components on a client machine, especially if you aren’t yet familiar with browsing through the log files.
You can run the DA Troubleshooting Tool on Windows 7, 8 or 8.1 – and you don’t even have to install it! Just download and run, and as long as you’ve got .NET 4, you’re in business.
The existence of this tool certainly doesn’t mean that you can spend your DirectAccess administration career without understanding the real log files, but it can give a nice summary. Also keep in mind that this initial version isn’t perfect, I expect they will be making some changes to help the tool accommodate better for things like a DirectAccess computer being inside the corporate network, or for a DA environment that makes use of OTP.
December 3rd, 2013
Microsoft has released SP4 for UAG! I know there are plenty of people out there who have been waiting for this one, as it incorporates support for Windows 8.1 clients, and the Internet Explorer 11 browser. You can also now make use of the built-in Mail app in Windows 8.1 through UAG, and Remote Desktop 8.1.
Learn more about the new features as well as the included KB fixes that are rolled into this new Service Pack, here:
And feel free to download SP4 here:
Installation note: Make sure that you are already running UAG SP3 Rollup 1 before installing SP4.
October 31st, 2013
Last night while working with one of my favorite customers to replace a NIC on a DirectAccess server, we discovered that the internal network was configured with a “global” approach to using ISATAP. I have seen this many times over the past couple of years, anyone who has stood up a DirectAccess environment following one of the Test Lab Guides out there most likely ends up with their network in this state, with a DNS host record for the word ISATAP. This is exactly what the TLGs tell you to do, but is actually not a good practice. I believe that some of the documentation out there specifies to take this approach because it’s easy to setup, and also because back when DirectAccess was new, we really didn’t know any better.
What is ISATAP?
Let’s back up a little. The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is an IPv6 tunneling technology. Most DirectAccess admins are familiar now with 6to4, Teredo, and IP-HTTPS. These three technologies are also IPv6 tunneling technologies, designed to take IPv6 packets and encapsulate them inside IPv4 headers, so that those packets can successfully transport across an IPv4 network. (aka the Internet for these three transition technologies). ISATAP does essentially the same thing, but for the inside of your network. I like to think of ISATAP as a “virtual IPv6 cloud” inside your corporate network. Once your internal computers/servers have set themselves up as ISATAP clients, they will receive an IPv6 address and routing information from the DirectAccess server. When this happens, because Windows prioritizes IPv6 over IPv4, whenever ISATAP host computers communicate with each other, they will do so using their ISATAP IPv6 tunnels, instead of their regular IPv4 LAN transport.
Why is this a problem?
If ISATAP is enabled globally in your environment, that means that any ISATAP capable host system will automatically become an ISATAP connected host system. Any Server 2008, Server 2012, Windows 7 or Windows 8 boxes inside your corporate network will automatically set themselves up with one of these ISATAP IPv6 addresses. When this happens, as stated above, all traffic between these hosts is now going to prefer to use that IPv6 tunnel rather than the regular IPv4 network. Well, it’s technically still using the IPv4 network, but is pushing encapsulated packets across the network now, instead of native IPv4. This means that if you are using an IDS/IPS to monitor traffic inside your network, you probably won’t be able to see this traffic. It will also make troubleshooting network issues inside the network quite a bit harder, because you’re going to notice all of these IPv6 addresses and packets flowing around, and it’ll take a lot longer to identify a connectivity problem with a system inside the network. Finally, you only have one ISATAP router when you setup this global approach, which is the DirectAccess server. This means that your DirectAccess server is now doing all the grunt work of being an ISATAP relay (sort of a DHCP server) for all of these internal hosts, sometimes thousands of them. It also means that the DirectAccess server is now the default router for all of the internal hosts traffic! This is obviously going to put unnecessary load on the DirectAccess server and the network where it resides. In the worst cases, using global ISATAP can cause connectivity issues and even network flooding.
History of ISATAP, as it relates to DirectAccess
So if it has the potential for so many problems, why is it the default implementation path in the Test Lab Guides? This answer goes all the way back to Server 2008 R2’s release. This operating system was the first time that the word DirectAccess appeared. Most folks are familiar with UAG DirectAccess and Server 2012 DirectAccess, now that it’s becoming more and more popular. But there was another version of DirectAccess, back in Server 2008 R2’s native operating system, and it came with some hitches. The biggest requirement was that the internal network had to be IPv6. This just isn’t a reality for customers, even today, and so it would have been a complete showstopper. Cue ISATAP. In Server 2008 R2 DirectAccess, you could use ISATAP to easily spin up a virtual IPv6 environment that ran on top of your internal IPv4 network, and then you could easily make use of DirectAccess! In the newer versions of DirectAccess, both UAG and Server 2012, there are some new components called NAT64 and DNS64 that work together to ensure that you don’t have any IPv6 requirements anymore. In Server 2008 R2, to be able to get those client IPv6 packets into the network, you needed an IPv6 network inside to send them to. With NAT64 and DNS64, the DirectAccess server now has the ability to take those client IPv6 packets and spin them down into IPv4 packets, so you can simply leave your internal network all IPv4. So back in the beginning it was standard practice to enable ISATAP globally. Today, because of the known issues, it is recommended not to use ISATAP at all, unless you have a specific reason for needing it…
In what cases would I actually want ISATAP?
Now you know the history on ISATAP and the fact that we no longer implement it unless needed, but how do you know whether or not you need it? If you have IPv6 inside your network, you definitely do NOT need ISATAP. I just wanted to start by saying that. However, almost nobody has IPv6 inside their network yet. So assuming that your internal network is IPv4, as we talked about already DirectAccess will work just fine, because of the new NAT64 and DNS64 technologies. So with no ISATAP in your environment, we can absolutely get DirectAccess connected and working. However, what happens if you have the need to send packets outbound toward your DirectAccess client machines? I’m not talking about things like updates or Group Policies or anything like that, because those items are all client-side pulls, and they will work over DirectAccess with no ISATAP or any special considerations. But if you have the case where you need to do a true “manage-out” to the DirectAccess client machines, like an internal helpdesk computer needing to RDP into a DirectAccess client computer, this requires the helpdesk computer to have an IPv6 layer of transport available with which to contact the IPv6 DirectAccess client. This is where the need for ISATAP comes in.
How to configure ISATAP
If you do determine that ISATAP could benefit the way that you use DirectAccess, DO NOT CREATE A DNS HOST RECORD CALLED ISATAP. Doing so will turn ISATAP on globally, and I direct you back to the beginning of this article. You will want to create a “Selective ISATAP” environment, where you get to determine manually which internal machines will take advantage of ISATAP and set themselves up as ISATAP hosts. This will leave the majority of your internal network on IPv4, business as usual, and will be a much, much safer way of implementing. Here are a couple of web links that will assist with your ISATAP configuration:
First, Jason Jones has a great article on setting up a Selective ISATAP environment: http://blogs.technet.com/b/jasonjones/archive/2013/04/19/limiting-isatap-services-to-directaccess-manage-out-clients.aspx
And I had the opportunity recently to put an extensive step-by-step together on this topic, in one of the chapters of this book: http://www.packtpub.com/microsoft-directaccess-best-practices-and-troubleshooting/book
October 18th, 2013
If you’re running Server 2012 DirectAccess and have enabled Reporting inside the Remote Access Management Console, you already know that you can head into that GUI and search historically for DirectAccess and VPN connections. This works well and is nice because of the Search function near the top of the page, where you can sort by dates and type in just about any criteria that you may want to filter the data down into. The interface looks nice and works well. Sometimes though, you may want to send this data out to a file/spreadsheet to be able to email it to someone, to automate some kind of weekly or monthly report, or for further data manipulation purposes. There is an option to configure Reporting to send data to a RADIUS server, but unfortunately that option logs less data than the default internal WID reporting does, so it will be most beneficial to you to use WID (which is the same information that shows up in the Remote Access Management Console), and extract the data from there.
You can do just about anything with PowerShell these days, so let’s explore the commands that we can use to pull useful DirectAccess usage reporting out of a Server 2012 DirectAccess box. Here are the two commands we are going to use, and links to their official TechNet documentation:
Get-RemoteAccessConnectionStatistics – http://technet.microsoft.com/en-us/library/hh918379.aspx
Get-RemoteAccessConnectionStatisticsSummary – http://technet.microsoft.com/en-us/library/hh918386.aspx
I’ll let the documentation speak for itself on all of the different ways that these commands can be used, but here is the procedure (and sample scripts) that I most commonly use for pulling out statistics for a particular date range, which is the most common request that I receive from customers:
You can, of course, modify these scripts in many different ways, including new variables for filtering and giving it a different file name or path in which to store the CSV files. Also, you will need to modify the script whenever you want to change the date ranges that you want reporting information for. This is just a simple example with some step-by-step direction on getting you to a starting point, and you can tweak your implementation of these scripts as needed in your own environment.
September 6th, 2013
A new book about DirectAccess has recently been authored by none other than our very own Microsoft MVP – Jordan Krause!
This book focuses on DirectAccess provided by Server 2012 (or Server 2012 R2), but most of the best practice and troubleshooting steps and solutions provided are also applicable to UAG DirectAccess for those of you using it.
August 27th, 2013
Anyone who has worked with UAG DirectAccess is probably familiar with the DirectAccess Connectivity Assistant (DCA), a small systray tool that installs onto the Windows 7 clients. This tool is very useful for generating log files in case you need to troubleshoot a DA connection, and it’s just a nice reference for users to be able to see whether or not their DirectAccess connection is working. In the UAG interface, there was a nice, easy way in the wizards for you to configure the DCA so that it knew what to look for in your environment and therefore report back to the user whether or not it was working properly based upon whether or not it could see those things which you defined.
In Server 2012 DirectAccess, there is no way to configure the Windows 7 DCA from inside the configuration wizards. Instead, Server 2012 DirectAccess focuses more on the Windows 8 clients, and the new version of DCA, now called NCA, which is built into Windows 8. During the Server 2012 DA wizards you define the same sort of criteria, basically telling the NCA tool what to look for, but when you are finished with these wizards and your settings are populated to the GPOs, these settings only apply to the NCA inside Windows 8. If you setup a Server 2012 DirectAccess environment, add a Windows 7 client to it, and install the DCA onto that client, it will not be configured. In this case the DCA can still be used to generate log files, but since it is not configured properly with a probe to go looking for, it will always show a status of “Not Working” with a red X.
So, by running through the Server 2012 DA wizards we have the NCA in Windows 8 working properly, but how do we get DCA in Windows 7 also configured? We basically just need to give it the same configuration settings as our NCA, but we have to do it manually, by hand, by way of a GPO.
Note: When you are sending Windows 7 clients through Server 2012 DirectAccess, you should be using DCA version 2.0 on your client machines.
Get your Active Directory ready for this new GPO
The settings for DCA are not part of Group Policy by default. You need to give one of your Domain Controllers the file that contains the settings so that when you go to configure your GPO, the settings you are looking for will exist. When you download the DCA 2.0 from Microsoft, here, it comes with a couple of files other than the installer itself. Log into a Domain Controller and do the following:
Create the GPO
Now let’s go ahead and create a new GPO for these settings. I try not to touch the existing DirectAccess Clients GPO which contains all of the existing DirectAccess connectivity settings, because this GPO is managed by the DirectAccess server’s wizard and any changes you make in here could potentially be overwritten by the wizard. After you create your GPO and link it wherever you would like, I recommend setting Security Filtering on that GPO (just like the DA Clients GPO does) so that it only applies to your Windows 7 DirectAccess client computers, since these are the only guys who are going to need or care about these settings.
Configure the GPO
Right-click on the GPO and “Edit”. Here are the items that we want to configure:
That’s it! Those are the important settings for making the DCA work correctly on a Windows 7 computer that is connecting in through a Server 2012 DirectAccess environment. There is one more setting in that GPO that we occasionally set, but is optional. If you enable this setting, it basically allows the users to be able to turn off DirectAccess by right-clicking on the DCA and choosing a new option called “Prefer Local DNS Names”. If you enable this setting and the user clicks on it, it will temporarily disable the NRPT on their computer, which will cause name resolution requests to stop going through the DirectAccess tunnels. There aren’t many good use-case scenarios where this option would actually be feasible, and so it is quite rare that I see it used in the wild. However, if this option sounds appealing to you, here it is:
July 31st, 2013
This blog post is no earth-shattering revelation, but it was certainly the first time I have run across this particular scenario and I think it serves as a good reminder to check your certificates, check your certificates, check your certificates!
I had just finished an install and successfully tested with a few client machines. It happened to be an install of the original Server 2008 R2 DirectAccess which was quite interesting in its own right, but that doesn’t have any bearing on what I experienced here. DirectAccess was working! Except on one laptop. I checked over everything on the machine and it all looked good. All of the Group Policy settings were in place, the certificate was in place, the components were turning themselves on successfully, the transition tunnels were establishing, but no IPsec tunnels. The worst part was that right after we first joined this laptop to the group, it did work, but following a reboot it stopped and wouldn’t come back online.
Then, I’m not sure why, I happened to look down at the corner of the screen. And I noticed the year was 2009. I don’t remember dates very well, but this didn’t seem right. As it turns out, this laptop’s CMOS battery was bad causing the date and time to be lost after every shutdown. Nothing else in Windows hinted at the date being so far off, and most of the components of DirectAccess were working, but the machine certificate that had just been issued to the computer the day prior was displaying as “Expired or not yet valid”. I always wondered in what situation the certificate might “not yet be valid”, but here you go. When the system date is years behind schedule, the certificate doesn’t check out just like if it had been expired.
I remind folks all the time to check their certificates for expiration dates. I guess we also need to make sure that we keep the DirectAccess laptops away from DeLoreans.
Jordan Krause | Microsoft MVP
June 13th, 2013
I recently had the opportunity to acquire a Microsoft Surface Pro. My everyday laptop has a fairly small screen, I did this on purpose for traveling and ease of use, and so at first I was a little skeptical that I would make much use of the Surface. It seems I was wrong. The Surface is considerably easier to take with me, and much faster to pop open and quickly check on emails or documents or whatever I need to do on a PC. “On a PC” That is the key here. This is no standard data consumption tablet device that is really only built for reading emails and news feeds and playing games (you know what I’m talking about). This is full Windows, and as such I am able to install and run anything that I would on my laptop. It could truly replace it.
Because I’m running full Windows, I can also use it to VPN into work. Nice, but who wants to launch a VPN??? Lame. Since I have pretty much a one-track mind, that track being DirectAccess, I of course had to find out whether or not I could get my Surface Pro to be continually connected to work without needing to do anything. The only problem that I could see? This is a “Surface Pro”, not a Surface Enterprise. Unfortunately the Pro version of Windows 8 does not comply with the requirements for DirectAccess connectivity, and even more unfortunately they have done away with the Ultimate SKU in Windows 8, so no joy there. My only shot at getting DirectAccess connectivity is to bring this Surface up to Windows 8 Enterprise.
I did a little research, and found some folks who had done it. It didn’t look like the most fun thing I have ever done, but I was ready to give it a shot. I happened to be traveling at the TechEd show when I got the Surface, and I had with me a Windows 8 Enterprise x64 ISO file as well as a USB stick. I was fully prepared to create a bootable USB and completely reload Windows to bring it up to Enterprise. I even found a link to Surface drivers and had them with me as well, because I figured it would struggle to recognize all the hardware in that guy.
Before starting that whole process, just for fun I attempted to run the feature in Windows where you can simply enter a new product key and Windows will do an in-place upgrade. I have done this successfully on Windows 7 Home Premium machines before to bring them up to Ultimate for the purposes of DirectAccess, and while I didn’t think that it would work for Enterprise, it was worth a few seconds to give it a shot. This option is the one inside System Properties, where you click on the Get more features with a new edition of Windows link.
“This key won’t work. Check it and try again, or try a different key.” This is the message I got. I tried multiple keys for Windows 8 Enterprise, but they all did the same thing. So this wasn’t going to work. At this point I copied the Windows 8 Enterprise ISO that I had with me onto the Surface in preparation to use it while creating my bootable USB. Then, almost by accident, I double-clicked on the ISO file. Inside the ISO, I looked at the file called “Setup”. I double-clicked on it. It launched.
I clicked on the Install now button, and setup started rolling! I was still hesitant that this was actually going to do anything in the end, but I went along with it. After accepting terms, I was presented with the “Upgrade or Custom Install” screen. I chose Upgrade, and voila.
Setup ran through some screens, it took maybe five minutes, and after rebooting, my System Properties now show that I am running Windows 8 Enterprise, on my Surface Pro!
Boy, that was easier than I thought it was going to be. Now that I was running Enterprise, all I have to do is join it to the domain and get the DirectAccess connectivity settings onto it. Since I was sitting in a hotel room at this point, I used VPN to connect, and over that VPN I was able to successfully join the Surface to my domain, grab a certificate from my CA server (we require cert authentication for DirectAccess), and pull down my Group Policy settings. After one more restart, DirectAccess is live on my Surface Pro!
And of course since DirectAccess is so awesome and seamless, I was immediately able to log in as my domain account while I was sitting right there in the hotel room. Nice!
May 7th, 2013
If you’ve ever worked with Microsoft DirectAccess, you know that at its core, DirectAccess runs on IPv6. In the early days of DirectAccess this was a blocker for implementation for many companies, because the only resources that your DirectAccess clients could communicate with were IPv6 resources, and there are very few companies running IPv6 inside their networks even today. In 2010 the implementation of DirectAccess was made significantly easier by removing all IPv6 requirements. This was accomplished by a couple of new technologies that were placed inside the Unified Access Gateway (UAG) platform that could handle translating the DirectAccess IPv6 packets into IPv4 packets when needed. These translation technologies are called NAT64 and DNS64, and they exist out of the box in any UAG DirectAccess deployment, as well as any Server 2012 DirectAccess deployment. This means that DirectAccess traffic comes in over the internet as IPv6 traffic, but when the internal resource that you are trying to contact is IPv4, those packets get translated on the fly by the DirectAccess server into IPv4 packets so that they can make their way successfully across the internal network. This all works great out of the box, with no extra configuration steps needed.
However, the key statement above is that “DirectAccess traffic comes in over the internet as IPv6 traffic”. No matter what version of DirectAccess you are running or how you have configured your settings, the DirectAccess traffic that is going over the internet, between the client computers and the DirectAccess gateway server, is always IPv6. So if your users are launching an application, and that application on the client machine is not capable of generating IPv6 packets, that application will not work over a DirectAccess tunnel. Most client-side applications these days are capable of generating both IPv4 and IPv6 packets, and so no matter what the network looks like, those applications will just push out whatever packets they need to make a connection. As DirectAccess becomes more popular, we are discovering that not all applications are coded equally, and there are many out there that are incapable of talking IPv6. Some software vendors are working on new releases of their software to make it IPv6 compatible, but many companies use applications that are homegrown, or customized, or legacy to the point where the software vendor just doesn’t exist anymore, and some of these apps are never going to be IPv6 capable.
IVO Networks has developed a solution to this problem that we call App46. App46 (pronounced App-four-to-six) is an agent that when incorporated into any DirectAccess environment, whether it be UAG or 2012 based, can intercept traffic from these IPv4-only applications, flip those packets into IPv6, and then send them on their way successfully across the DirectAccess tunnels! We have used App46 to successfully fix numerous applications that could not previously function over DirectAccess.
Autonomy’s WorkSite over DirectAccess – Using App46
Probably the most popular uptake of App46 so far has been in the legal industry, specifically for an application called WorkSite. WS also goes by a couple of other names, depending on how you use it – FileSite, iManage, iManage WorkSite. It is a document management system that many law firms use, and it is not truly IPv6 capable, and therefore does not work over DirectAccess natively. We now have WorkSite functioning over DirectAccess in numerous organizations by using App46.
If you have any questions regarding App46, or DirectAccess in general, always feel free to reach out to me directly. Thanks!
For IVO Networks – Software Sales, please contact: