(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)
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:
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:
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:
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:
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.
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:
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”:
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.
Thomas W. Shinder MD
Microsoft ISDUA – UAG DirectAccess – Anywhere Access Team (AAT)
<p>On the reasons Microsoft DirectAccess represents a real paradigm shift... it lays the groundwork for anytime access to all devices, including those embedded in human beings. Security is not an option in that environment, it is a necessity. Thanks Tom!</p>
<p>Please see the Technet Blog on Autolaw Matrix network architecture objectives and updates here: <a rel="nofollow" target="_new" href="http://social.technet.microsoft.com/wiki/contents/articles/matrix-autolaw-dangers-network-architecture-considerations-protocols-rulemaking-records-and-identity.aspx?wa=wsignin1.0&CommentPosted=true#commentmessage">social.technet.microsoft.com/.../matrix-autolaw-dangers-network-architecture-considerations-protocols-rulemaking-records-and-identity.aspx</a></p>