DirectAccess and FRS are not friends

File Replication Services (FRS) is something that Microsoft has been trying to get customers to stop using for many years. The newer DFS-R is superior in every way, and the migration from FRS to DFS-R is now quite a simple process, everyone should be making the switch. But of course as we always see with every outdated technology, some of us still love what we know, or for whatever the reason there are still enough customers using FRS right now that Microsoft has decided to update the DirectAccess unsupported configurations article in TechNet to address problems they have seen with this coexistence:


File Replication Service (FRS) distribution of Group Policy objects (SYSVOL replications)

Do not deploy DirectAccess in environments where your domain controllers are running the File Replication Service (FRS) for distribution of Group Policy objects (SYSVOL replications). Deployment of DirectAccess is not supported when you use FRS.

You are using FRS if you have domain controllers that are running Windows Server 2003 or Windows Server 2003 R2. In addition, you might be using FRS if you previously used Windows 2000 Server or Windows Server 2003 domain controllers and you never migrated SYSVOL replication from FRS to Distributed File System Replication (DFS-R).

If you deploy DirectAccess with FRS SYSVOL replication, you risk the unintentional deletion of DirectAccess Group Policy objects that contain the DirectAccess server and client configuration information. If these objects are deleted, your DirectAccess deployment will suffer an outage, and client computers that use DirectAccess will not be able to connect to your network.

If you are planning to deploy DirectAccess, you must use domain controllers that are running operating systems later than Windows Server 2003 R2, and you must use DFS-R.


This isn’t to say that it won’t work, for a while at least, but it is now officially unsupported. I have personally installed DirectAccess into Server 2003 domain environments numerous times and have never seen this problem firsthand, but it’s possible those orgs were simply not using FRS.

Jordan Krause
Microsoft MVP | Enterprise Security

Microsoft Ignite 2015!

So this post is a few days later than intended, but it seems like I hit the ground running and haven’t stopped since setting foot in Chicago! The first-ever Ignite conference is going very well, with an astounding 23,000 of us in attendance! “Mobile First, Cloud First” is our motto here and while I don’t work as regularly today with Azure as I’m sure I will over the coming years, I couldn’t agree more with the “mobile first” message. Enabling users to work from wherever they are has been the focus of IVO Networks for many years, and I am super excited to soak up as much knowledge here at Ignite as possible.

I also want to put out a public congrats and recognition to my friends Idan and Ohad whose company Aorato was recently acquired by Microsoft and was mentioned in the Keynote address on Monday! If you haven’t heard of it, be sure to check out Microsoft Advanced Threat Analytics. This promises to be an amazing technology that is going to save plenty of business’s bacon.

Well, that’s it for now. Off to another session and then some back to back after-hours events to fill in the night. Never a dull moment at these conferences.

Jordan Krause
Microsoft MVP | Enterprise Security

DirectAccess advanced features disable IP-HTTPS null encryption

If you’ve ever attended one of our “DirectAccess: Best Practices” webinars, or read anything that I have written regarding the DirectAccess transition technologies, you know I am an absolute advocate of keeping Teredo enabled whenever possible. The premise for this recommendation is simple: improved performance. There are a number of different possible client/server combinations in a DirectAccess connection, and depending on what combination is used, you may or may not be running as efficiently as possible. I come across many DirectAccess implementations in the wild that were configured in a way where Teredo is disabled, and so all client connections are being made via the IP-HTTPS transition tunnel. Technically this is fine, as all clients are able to make IP-HTTPS connections, but depending on what operating systems you are running, you may be double-encrypting every packet that flows in or out of every DirectAccess client computer. This makes for slower connections on the client side, and heavier resource utilization on the server side, resulting in slower speeds and fewer users that you can squeeze onto that DA server.

To give a little background, the reason your traffic might be doubly encrypted is because all DirectAccess traffic is encrypted with IPsec all the time. In addition to that encryption, when certain operating system combinations are in effect in a DA connection, your IP-HTTPS tunnel might also be encrypting that traffic stream a second time with TLS. Think of it this way, your transition tunnel (Teredo or IP-HTTPS) is like a conduit flowing through a wall. Inside that conduit run your individual networking cables, which are akin to your DirectAccess IPsec tunnels. Your IPsec tunnels that flow inside the conduit are already encrypted, so there is no need to encrypt the conduit itself. However, that is exactly what IP-HTTPS does in many circumstances. This is the core reason why we keep Teredo enabled when possible, so that any users which can connect using Teredo do so, and lessen the encryption processing load on both the clients and the DirectAccess servers. Here are some examples of IP-HTTPS connections that will help to show in what cases you are experiencing double encryption:

Client/Server operating system combinations when connecting via IP-HTTPS:
Windows 7 / UAG DirectAccess: Yes, double encryption.
Windows 7 / 2012 DirectAccess: Yes, double encryption.
Windows 8 / UAG DirectAccess: Yes, double encryption.
Windows 8 / 2012 DirectAccess: No, only the IPsec encryption is happening here, at least in most cases.

In the event that your client computer is running Windows 8 or higher, and the DirectAccess server is running Server 2012 or higher, then we are finally in a position where the negotiations of the tunnel are smart enough to negotiate null encryption on the IP-HTTPS tunnel itself. Because all DirectAccess traffic is already secured inside IPsec, we can safely negotiate NULL, and take some of the processing load for the IP-HTTPS tunnel off the client and the server. This is great news, and as the newer operating systems roll out further and further, this will help to speed up DA connections and reduce the load on DA servers everywhere!

BUT…there’s a catch, which is the purpose of this article. If you enable some of the advanced features on your Server 2012 DirectAccess server, namely VPN or OTP, your NULL encryption negotiation option will be gone. There is nothing in the wizards or GUI which tells you this is going to happen, but as soon as you enable OTP or add the VPN role to a DirectAccess server, the ability for your IP-HTTPS tunnels to connect using NULL vanishes, and all of your IP-HTTPS connections, even those between Windows 8 and Server 2012, are always double encrypted. This happens namely because you don’t want OTP credentials which are used as part of the IPsec tunnel authorization to be sent clear-text across the internet, and if you have users connecting via SSTP VPN, same is true. You certainly wouldn’t want their VPN tunnels to be able to authenticate and pass credentials over that null stream, sending critical information via clear text across the internet.

So while NULL encryption for IP-HTTPS tunnels gets disabled for very good reasons, the fact that this happens is not advertised anywhere for the administrator to see, and so you may be caught off guard to find that you have enabled VPN only to experience higher CPU load on your DA server, or complaints from users about having slightly slower connections than they used to have.

Jordan Krause
Microsoft MVP | Enterprise Security

Windows Server 2012 R2 Administrator Cookbook – New Book!

We are happy to announce that IVO Network’s own Microsoft MVP, Jordan Krause, has had an opportunity to put together and publish a second book!

This publication is designed to help both new and experienced server administrators to better understand and utilize Microsoft Windows Server 2012 R2 in their corporate environments.


Enabling new columns in Remote Access Management Console | Remote Client Status

I recently helped a customer roll out DirectAccess on a couple of load balanced Server 2012 boxes. It is pretty common to get some questions after we finish installing, but I was asked something that (surprisingly) I haven’t ever been asked before. Specifically, his question was “When I am viewing the currently connected DirectAccess computers inside the Remote Access Management Console, how can I see what DirectAccess server they are connecting through without having to go into the details of each connection?”

“There’s a column right in there that shows you” was my response. But indeed, there was not. I checked some of my own servers, and sure enough there was a Server column right there where I could identify and even sort the connections by which node they were connecting through. But this column was not showing up in his console. Then we checked his other server, and the Server field was visible on that one! But still not on the first DirectAccess server.

It seems like we poked and prodded around every inch of the interface, but couldn’t find a menu that let us choose which columns were visible and which were not. Then just as I hung up the phone with him (isn’t that how it always happens?), I accidentally clicked on it. All you have to do is right-click on one of the Titles of the existing columns, and you see a list of available columns to select or de-select. The important part is that you must right-click on the name (right on the text) of one of the columns that is already being shown. Right-clicking anywhere else in the Console will not get you this selection.


So there was our answer. We simply checked the Server box in this list, and the new column was immediately available for viewing and helping us to manipulate the data as needed. Sometimes the simplest options are the hardest to find!

Jordan Krause
Microsoft MVP | Enterprise Security

Forefront TMG SP2 Rollup 5 available for download

Hotfix Rollup 5 for Microsoft Forefront TMG SP2 was recently released, and can be downloaded here:

This rollup includes the following hotfixes:

2963805 – Account lockout alerts are not logged after you install Rollup 4 for TMG 2010 SP2

2963811 – The TMG Firewall service (wspsrv.exe) may crash when the DiffServ filter is enabled

2963823 – “1413 Invalid Index” after you enable cookie sharing across array members

3963834 – HTTPS traffic may not be inspected when a user accesses a site

2967726 – New connections are not accepted on a specific web proxy or web listener in Threat Management Gateway 2010

2965004 – EnableSharedCookie option doesn’t work if the Forefront TMG service runs under a specific account

2932469 – An incorrect value is used for IPsec Main Mode key lifetime in Threat Management Gateway 2010

2966284 – A zero value is always returned when an average counter of the “Forefront TMG Web Proxy” object is queried from the .NET Framework

2967763 – The “Const SE_VPS_VALUE = 2″ setting does not work for users if the UPN is not associated with a real domain

2973749 – HTTP Connectivity verifiers return unexpected failures in TMG 2010


Can’t disable the NRPT? New hotfix available for Windows 8.x clients

When running through the DirectAccess configuration wizards, a handy option that is often chosen by DA admins is “Allow DirectAccess clients to use local name resolution”. You can see this option on the screen where you configure settings for your Network Connectivity Assistant (NCA), inside Step 1. When enabled, this setting allows a DirectAccess user to click on their DirectAccess network connection from the systray, and choose “Disconnect”.

What this Disconnect button really does is temporarily disable the NRPT. This stops DNS requests from attempting to flow over the DirectAccess tunnels, and instead places those DNS requests on the locally configured DNS server of the user’s current network connection.

The problem with this Disconnect button is that it only shows up once the NCA tool has successfully “Connected”. So if NCA never goes to a Connected status, the Disconnect button is not available. One scenario where this will cause grief is when users are inside the corporate network, and there is something wrong with the NLS website. If you have a problem with NLS, it can cause all kinds of name resolution problems for your DirectAccess client computers which are inside your network. A nice workaround to this problem, until you fix the NLS of course, is to have everyone click on their Disconnect button. But wait, since there is a problem with NLS, DirectAccess tunnels are trying to build but never can, so your NCA tool in the systray continually says “Connecting” instead of flipping over to “Connected”. Since we are stuck on Connecting, the Disconnect button is not available to click on. So even if you have the option selected where users should be able to turn off the NRPT and resolve their DNS name resolution issues, the button will not be available to them.

The good news is that this bug in the NCA has now been resolved, courtesy of the following hotfix:

Simply install this hotfix on your Windows 8 and Windows 8.1 clients, and should you have the unfortunate event of your NLS website going down, you can at least get folks inside the network back to work by being able to temporarily Disconnect the NRPT.

Server 2012 DirectAccess – Hotfix available for Remote Access Management Console memory leak

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:

DirectAccess Client Troubleshooting Tool

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.

UAG SP4 is available for download

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.