Microsoft Corp.'s DirectAccess, new to Windows Server 2008 R2, promises connectivity nirvana: an always-on application infrastructure for employees both inside and remote to the organization. But it comes with a very steep cost in terms of IT dollars and time to deploy.
Microsoft has not yet promised an availability date for R2, but a beta version was made available in early February and can be downloaded here.
In the meantime, it's always a good idea to familiarize yourself with new concepts even before they're available. And here's the promise of DirectAccess: Imagine yourself as a field sales representative. After a long flight, you arrive at your hotel at 10 p.m. and want to check your e-mail and log your timesheet hours before bed. Once checked in, you go to your room, plug in your laptop and connect to the hotel's Internet facility. In a matter of seconds, not only does your e-mail update, but your intranet timesheet application opens up automatically -- and you can update it -- without messing with a VPN connection.
The next morning, at a client site, you connect to the client's guest wireless network while in a meeting. Using standard Windows search tools, you search for a document that resides on a SharePoint server internal to your firm. Your computing experience is the same, no matter where you are.
On the flip side, imagine yourself as an IT worker in a large firm. (This one shouldn't be too difficult to envision.) You have a large contingent of telecommuters spread across the world and previously have had no way to enforce that they either come into the office or connect to your VPN at any regular interval. As a result, you didn't have any way to ensure that their machines were properly patched, that they weren't infested with malware, or that they weren't leaking confidential and proprietary company information via peer-to-peer networks or other means.
But now all of these remote users can be managed, secured, patched and trusted -- all via a secure, authenticated connection -- removing any obstacle to administering those machines as if they were hardwired to your internal networks.
DirectAccess is the technology that purports to offer this level of seamless connectivity. In this feature, I'll take a look behind the scenes at the technology that drives it and then walk you through an overview of how to prepare for and deploy DirectAccess.
How does it work?
DirectAccess relies heavily on IPv6. (I can hear the collective groaning throughout the audience.) The reasoning here is that IPv6 (Internet Protocol Version 6) is one of the only transport protocols that supports the addressing needs required from the client through bridges to the corporate network. Of course, migrating to IPv6 is a costly and time-consuming proposition, and thus DirectAccess also supports a variety of transition technologies that make IPv6 work in a world that is still heavily based on IPv4.
These transition technologies essentially carry IPv6 packets across IPv4 tunnels, and sometimes through edge devices that might otherwise interrupt the flow of communications. The technologies in use are:
- Teredo: Teredo helps IPv6 transmission pass through NAT (Network Address Translation) devices, which traditionally allow larger networks to assign private, non-routable addresses behind an edge device that shares one or more public IPv4 addresses. If a client is behind a NAT firewall, Teredo is the preferred DirectAccess connectivity method.
- 6to4: 6to4 is a way to translate IPv6 address into IPv4 addresses, and it works well in scenarios where IPv6 connectivity is needed across the public IPv4 Internet. If the remote clients have public IPv4 addresses, 6to4 is the preferred connectivity method.
- IP-HTTPS: This is a new protocol to Windows 7, and also Windows Server 2008 R2, that tunnels IPv6 packets coming behind an edge device through an HTTPS session. While more accessible than Teredo and 6to4, this method has a significant performance penalty and is meant to be a "last resort" connectivity protocol when Teredo or 6to4 won't connect.
- Native IPv6: Of course, if you have deployed IPv6 and all clients and servers have globally routed IPv6 addresses, then you can work in the native IPv6 protocol without any transition technologies necessary.