DirectAccess is a new remote access technology enabled by the combination of Windows Server 2008 R2 and Windows 7. Unlike other remote access technologies such as reverse proxy, reverse NAT, SSL VPN gateways, and network layer VPNs, the goal of DirectAccess is to extend your network to any location in the world, so that your domain member client systems are always connected to the corpnet.

Think about the mix of remote access technologies you use now. Some of them might be in place to support partners, for which you want to provide very limited network access. But what about your employees? If you’re like me, you’ve probably spent most of your professional life trying to figure out how to give employees the information they need, in the most efficient way possible, so as to create the least frustration for both the employee and the Help Desk and IT overall. Most of all, you want to make sure this access is secure and that security doesn’t interfere with productivity.

There have always been two major stumbling points when providing productivity-enabling remote access to employees:

• Employees often found it difficult to get the remote access solution working, or when they did, found the experience limiting in some way and therefore became less productive compared to when they were in the office
• IT found it difficult to manage the security of the devices their employees were connecting from. Even in the ideal situation where you gave an employee a laptop with the corporate “golden image”, that image often fell out of compliance because the client system was not connected to the corpnet often enough to have the appropriate configuration settings applied through Group Policy or other desired configuration methods, such as System Center Configuration Manager. In addition, it was difficult to keep track of your off-campus fleet, since you never knew when they were going to connect to the corpnet again, if ever.

When you think about it, neither you nor your users ever wanted to use VPN. You never really wanted your employees to have to use SSL VPN gateways. You never actually wanted your users to have to gain access to resources over reverse proxies and NAT devices. You never really wanted to use any of the myriad number of remote access “artifices” that you’ve put in place.

But you did, because your goal was to provide your business an advantage by delivering out of office users access to information so that they could get their work done from anywhere.

But these solutions didn’t really didn’t do what they were supposed to do – at least not for you and your employee users:

• How many times have you gone to a hotel an found out that it did not support PPTP or L2TP/IPsec?
• How many times have you had all VPN access denied to you from your out of office location?
• How many times have you had to deal with network ID collisions between the network you were on the corpnet ?
• How many times did you need to use a web version of the application you wanted to use, because you couldn’t establish a VPN?
• How many times have users called you or your help desk because the VPN connection did not work from the hotel room, conference center, partner network or customer’s office?
• How many times did your users call regarding forgetting which name to use to connect to a resource when they’re out of the office, which of course is a different name when connected to the corpnet?
• How many times did you wish that you had the same command and control over all your managed, domain member computers, regardless of their location?
• How many times did you wish that all you had to do is turn on your computer, and you could connect to all the resources you were authorized to connect to, regardless of your location – the only thing you had to remember is to turn your computer on and enter your credentials?

No, we didn’t want these remote access solutions for our employees, but they were the best we could do.

What we actually wanted all this time was DirectAccess.

I can tell you that as a user, DirectAccess becomes a transformational experience. It completely changes the way I approach my work. In the past, if I left the office, I anticipated the traditional road warrior’s “negotiations with the remote access gods”.

The negotiations went something like this:

• Please don’t assign me an address on the same network ID as my office
• Please let L2TP/IPsec work
• Please let PPTP
• Please let secure Exchange RPC work
• Please allow RDP to work
• Please allow more than just HTTP/HTTPS outbound

You just never knew what the computing experience was going to be. If the network layer VPN worked, then almost everything worked. Of course, I’d have to fire off the VPN client first, and make sure the client was configured correctly (easy for me, not so easy for the average or even above average user). If neither network layer VPN protocol worked, then I spend my time living the second-class life of browser based applications. And file access experiences ranged from problematic to catastrophic.

There were often workarounds, but I could employ them because I’ve been doing networking for a long time. Average users would give up, call the Help Desk or try their best to do what they could with what they had – with the end result being a significant compromise in productivity and a flagging faith in the entire remote access experience and reduced expectations for what could be done when away from the office.

DirectAccess changes the game. Not only the game, but the entire playing field. So many of the problems related to remote access technologies that I’ve described so far are due to the users “location awareness”. While location awareness in the software is a very useful thing (and used by DirectAccess in the background), it’s not something you and your users want to worry about.

It’s the entire “location awareness” issue that creates problems for users:

• Am I going to be able to use VPN?
• What Web site URL do I use?
• Am I going to have to reconfigure my application to work on the outside?
• I’m going to have to do things differently when I’m on the outside

This “location awareness” creates both conscious and unconscious friction with the surface of user productivity. Energy is wasted and productivity is reduced. With DirectAccess, the entire “location awareness” issue is a non-issue. When you and your users connect with DirectAccess – the experience is the same all of the time.

• The computing experience at work is the same
• The computing experience at the ball game is the same
• The computing experience at the hotel is the same
• The computing experience at the conference center is the same
• The computing experience at the customer site is the same

How is the computing experience the same in each of these scenarios? Because the following describes the computing experience for all five of the scenarios listed above:

• Turn power on or wake the computer from sleep
• Log on with your user name and password, or smart card and pin
• Connect to corporate file shares, web sites, SharePoint sites, SQL servers, Exchange Servers, and just about any other server you can think of using their native application layer protocols
• Close the computer lid and put the computer to sleep

Notice there was no “starting the VPN connection” or “connecting to the SSL VPN portal page” or anything else that required the user to be “location aware”.

This is what makes DirectAccess the paradigm shifting, transformational technology it is. And what really proves the point is how quickly you will take it for granted. That is a key component of what I consider to be transformational technology – you take it for granted because it was always supposed to be this way. In fact, you’ll find that the technology, over time, will seem boring to you. And for new computer users who have never experienced DirectAccess , they will find it really boring – or at least not exciting or transformational, because they will assume that is how remote computing should have always been done.

The story on the IT side of the house is just as compelling. Now you have access to the DA clients anytime a DirectAccess client is turned on; the user doesn’t even need to be logged on. You can apply patches, do “just in time” updates, install software, remove software, perform real-time remote management and configuration or assistance over RDP, and many more management tasks because the connection between DA clients and management servers is  bidirectional and always available between the management servers and DA clients.

Your DA clients will be in the same state of compliance as machines that never leave the corpnet and they have access to all the management, command and control systems you use to manage any machine on the corpnet.

The reason is that DirectAccess allows you to extend the corpnet and its management infrastructure to the DA client.

I know that you’ve heard about “paradigm shifts” and “transformational technologies” in the past. IPsec server and domain isolation had that potential. But it never caught on. Network Access Protection, something I can remember hearing a number of people at TechEd 2004 demand “I need it now!” But after it was released, sort of “hung in the stretch” (to use a horse racing term). Why? I don’t know if there are any official reasons why, but I suspect that these two fantastic, potentially game changing technologies were just too complex and the expected return on investment for dealing with such a level of complexity ended up being too low.

This can’t and must not happen to DirectAccess – there are two main reasons why I don’t see DA “dying on the vine”:

• Although some in the media have communicated that it is complex, in fact, there are far fewer moving parts that you might think – most who consider it overly complex have not tried to set it up
• Many of the moving parts are already deployed on your network and you can easily integrate them into your DirectAccess deployment
• The gains in improved manageability will more than pay for the time it takes to learn the new technology
• The gains in end user satisfaction and increased productivity will not be incremental, they will be differential – meaning that end user productivity will increase significantly after DA is deployed, and will continue to increase over time as the frictionless DirectAccess experience is fully integrated into the computer users’ ways of working

So there you have it – my reasons why DirectAccess will change the world, and it’s a world that both IT and end-users have always wanted to live in.

It’s also a world that I want to help you get to. In the following months this blog will be dedicated to UAG DirectAccess and provide you hints, tips, tricks, ideas, opinions, workarounds, designs, and experiences that will speed your path to DirectAccess deployment. Because the only way you’ll really know the joy of the DirectAccess experience is to experience it. And after that, you’ll take it for granted – but you’ll be taking for granted an all new world of computing – one that allows you to get more done faster without ever needing to think about where you are.

HTH,

Tom

Thomas W. Shinder MD

Microsoft ISDUA – UAG DirectAccess – Anywhere Access Team (AAT)

tomsh@microsoft.com

As a member of the Anywhere Access Team with a primary focus on UAG DirectAccess (DA), one of the questions that I hear a lot relates to the security of the solution, due to the fact that split tunneling is enabled by default.

If you’re a VPN guy, you are probably aware of the issue of split tunneling. When split tunneling is disabled, the VPN client uses the VPN gateway as its default gateway, so that all off subnet communications must go through the VPN gateway. It also prevents the the VPN clients from potentially routing communications between two networks, such as the client’s network and the corporate network.

For this reason, most experienced VPN admins disable split tunneling by default. This has become a habit for VPN admins and they don’t think twice about it. However, what they gain in security is lost in performance for the corporate Internet connection.

The reason for this is that the VPN client must go through the VPN gateway to access Internet content, so that the request/response path for Internet content is from the VPN client, to the VPN gateway, to an Internet gateway on the corpnet, to the Internet, and then the response is returned using the same path in the opposite direction.

As you can imagine, if you have more than a few VPN clients, this could become a major bottleneck on your Internet bandwidth.

The DA team understands this problem very well. If the DA client connection isn’t highly performant, users will likely be unsatisfied with the solution. The productivity gains you expected will evaporate, as users won’t use DA to connect to the corpnet, and they’ll return to their old inefficient ways of working.

So, DirectAccess by default enables split tunneling. All traffic destined to the corpnet is sent over the DA IPsec tunnels, and all traffic destined for the Internet is sent directly to the Internet over the local interface. This prevents DA clients from bringing the corporate Internet connection to its knees.

However, it has left the issue of potential risks of split tunneling in the minds of admins who are considering DA. One option is to use “force tunneling”. You can find out more about force tunneling at http://technet.microsoft.com/en-us/library/dd637812(WS.10).aspx One of the primary disadvantages of force tunneling is reduced performance, especially in the context of reaching IPv4 only resources.

But this begs the question: is DA split tunneling really a problem? The answer is no.

Why? Because the risks that exist with VPNs, where the machine can act as a router between the Internet and the corporate network is  not valid with DirectAccess. IPsec rules on the UAG server require that traffic be from an authenticated source, and all traffic between the DA client and server is protected with IPsec.

Thus, in the scenario where the DA client might be configured as a router, the source of the traffic isn’t going to be the DA client, and authentication will fail – hence preventing the type of routing that VPN admins are concerned about.

HTH,

Tom

Tom Shinder
Microsoft ISDUA
Anywhere Access Team/UAG DirectAccess

Andrew Garcia over at eWeek has written an excellent article describing his experience testing Microsoft Forefront UAG 2010's capabilities for assisting deployment of Microsoft Windows' DirectAccess.  I thought I'd add a little color commentary to the deployment topic..

A little over a year before the release of Windows 7 and Windows Server 2008 R2 the UAG team looked at what it could do to incorporate DirectAccess as a technology in its overall "access" mission.  Later, a Microsoft-wide virtual team looked into what we could do to accelerate DirectAccess deployment.  These two activities have already born fruit, both in new features in UAG 2010 and the new DirectAccess Connectivity Assistant.

As an example, one of the key features UAG brings to the DirectAccess deployment story is support for the DNS64 and NAT64 IPv6 transition technologies.  The "64" refers to "6-to-4", as in IPv6 to IPv4 (as oppsed to the common usage implying something to do with 64-bits).  DNS64 and NAT64 are the latest technologies for allowing IPv6 clients to communicate with IPv4 servers.  They are in the process of replacing the earlier DNS-ALG and NAT-PT technologies that were found to be flawed and moved to historical status by the Internet Engineering Task Force (IETF).  As a result of DNS-ALG/NAT-PT's status customers may not be willing to deploy them and vendors (some of whom already support these technologies in shipping products) may not want to advocate their use.  That left a big gap for customers considering deployment of DirectAccess, how to enable communications with servers that only support IPv4?  UAG 2010 stepped in to help and is the first product to bring the newer DNS64 and NAT64 to market.  Others will certainly follow as the need to enable transition to IPv6 becomes more urgent. 

Although not part of UAG, the Microsoft DirectAccess Connectivity Assistant (DCA) is another important part of our efforts to accelerate DirectAccess deployment.    One piece of feedback we received from early adopters of DirectAccess was that their end-users loved DirectAccess so much that when it didn't work they were quite vocal about their frustration.  Perhaps it worked just fine from their home or hotel, but not when they were in their favorite coffee shop.  The lack of an indicator that DirectAccess was "on" and working properly added to end-user frustration.  The lack of an easy way to gather and deliver diagnostic information to IT, so they could help solve the problem, raised support costs.  DCA displays the status of DirectAccess connections in the Windows 7 notification area, gives the end-user assistance in solving connectivity problems, and provides diagnostic information should IT need to get involved in resolving connectivity problems.  DCA is now available for download on TechNet.

Making products easily deployable is a major focus for the Identity and Security Division and customers should start to see the result as we roll out new products.  For DirectAccess we continue to drive a Microsoft-wide effort to accelerate deployment.  In the short run you'll notice an increasing amount of deployment guidance becoming available.  I urge you to keep an eye on the Forefront UAG Product Team Blog for announcements as well as for hints and deep dives to help with your UAG deployments (DirectAccess and otherwise).

^{This recent article was published at Tales from the Edge, that explains how to configure Exchange Sync with Forefront TMG 2010, here it is the link for it: http://technet.microsoft.com/en-us/library/ee513174.aspx. Also, here is a reminder about the supported scenarios with Forefront TMG 2010 and Exchange 2007 Edge role, for the support matrix click here.}

^{From: http://blogs.technet.com/isablog/archive/2009/11/10/email-protection-in-forefront-tmg-2010-release-candidate.aspx}

^{The * on this table says:}

^{Recently a blog post was published by the Exchange team saying that they reconsidered and are planning to support Windows Server 2008 (SP2). To read more about it please follow this link: http://msexchangeteam.com/archive/2009/11/04/453026.aspx}

^{There is a newer update on that, which is the one below:}

^{“…we will be adding support for Exchange 2007 on the Windows Server 2008 R2 platform.   While we had hoped to add this application/operating system combination quickly, unfortunately adding this support requires code changes to setup in Exchange 2007.  Therefore, our vehicle for adding this support will be via a third Service Pack for Exchange 2007 in the second half of calendar year 2010.”}

^{From: http://msexchangeteam.com/archive/2009/11/30/453327.aspx}

^{In other words: If you want to deploy Exchange 2007 Edge role on Forefront TMG 2010 you will need to:}

• ^{Windows Server 2008 SP2}
• ^{Exchange 2007 SP2}

^{If you already installed Forefront TMG 2010 on Windows Server 2008 R2 and want to install Exchange Edge role to enable EMail Protection feature your current supported options are:}

• ^{Install Exchange 2010 Edge Role}
• ^{Wait for Exchange 2007 SP3 to come out so you can install Exchange 2003 Edge Role on Windows Server 2008 R2}

^Author

^{Yuri Diogenes
Sr Security Support Escalation Engineer
Microsoft CSS Forefront Edge Team}

^{Technical Review}

^{Noam Ilovich
Program Manager
Microsoft Forefront Edge Team}