Today, I’m just going to be brief for a change, and discuss what we refer to as “Managed Out” scenarios.

I want to thank Pat Telford a consultant in Microsoft, specializing in DirectAccess deployments among other things, for helping with this subject.

Like I mentioned in one of my first posts, one of the big advantages of the DirectAccess technology over traditional VPN service is that DirectAccess clients can be managed anytime they are connected to the Internet. We like to refer to that scenario as “manage out.” This means that the client’s computer is “always managed” – there is an IPsec channel that enables the infrastructure and management servers to have access to the client’s computer, even when a user is not logged on.

There are two ways manage out can be accomplished:

• Client-initiated: Where the DirectAccess client initiates the communication to a server on the intranet, and then “pulls” it down:
• In this case the intranet server can be an IPv4 server, and UAG DirectAccess uses it's NAT64/DNS64 capabilities to compensate for the lack of IPv6 connectivity to the intranet server
• The following are examples of Client-initiated management traffic:
• System Center Configuration Manager
• Windows Server Update Service
• System Center Operation Manager (Most of the time)
• Updating Anti-Virus definitions
• Applying Group Policy Objects
• Intranet -initiated: Where the resource in the intranet initiates the communication to a DirectAccess client on the Internet:
• The host initiating the connection must be able to determine the IP address of the remote DirectAccess client. This means that the Remote DirectAccess client must register its FQDN and IPv6 address in the internal DNS servers.
• The client can register its IPv6 address dynamically, if dynamic DNS updates are enabled, and the DNS server supports AAAA records.
• The DNS server must be reachable from IPv6 DirectAccess clients. If you aren’t routing native IPv6 in your network, you can use an ISATAP generated IPv6 address for the DNS server.
• Using a Windows Server 2008 or Windows Server 2008 R2 based DNS Server is the best option here, since they natively support both of the above.
• The second best option would be to use Windows Server 2003 DNS servers With UAG DirectAccess. The built-in NAT64/DNS64 will still provide connectivity to IPv4 only DNS servers.
• UAG DirectAccess supports using NAT64/DNS64 to register DirectAccess clients on a Windows 2003 Active Directory infrastructure.
• The host initiating the connection must be IPv6 able – Our NAT64 implementation doesn’t translate connections initiated from the intranet.
• The following are examples of traffic that is initiated by resources inside the intranet:
• Protocols that may be used by IT personnel (“Peer to peer”)
• Remote Desktop
• SMB – for reaching out to files on the user’s machine
• Endpoint vulnerability scans

That’s all for today, just remember, if you have protocols that initiate connections to DirectAccess clients, you’ll need the DNS infrastructure to be set correctly for it to work with UAG DirectAccess. In addition, don’t forget to specify relevant management servers in the Management Servers and DCs page in the Forefront UAG DirectAccess Configuration Wizard, if you want managed out communications between the client and the management servers, even when the no one is logged on to the client computer.

Thanks

Ben Bernstein