What about applications that don't work with DirectAccess? That's a good question. But before we go there, we have to think about connectivity between the DirectAccess server and the DirectAccess client. The DirectAccess client always communicates with the DirectAccess server using IPv6. There is no IPv4 application traffic moving between the DirectAccess client and DirectAccess server. This means that the client side applications running on the DirectAccess client must be IPv6 aware. On the server side it doesn't matter - you can run IPv4 only server applications on an IPv6 capable operating system, or you can run server applications on an IPv4 only operating system. IPv4 isn't an issue when using UAG DirectAccess, because we have the DNS64/NAT64 feature to support IPv4 communications between the DirectAccess server and the destination server on the intranet. This means that if your client side applications don't support IPv6, you're going to have to think about a solution. Some things to consider include: Check with the vendor to see if they have an updated client side application that is IPv6 aware Check with the vendor to see if the application can be made IPv6 aware by editing a configuration file or setting a Registry entry. In some cases the client side applications might appear to not work with DirectAccess, but if you make a configuration change, they suddenly start working If the vendor doesn't have an IPv6 capable application and there are no client side tweaks that you can use to make it IPv6 capable, investigate alternate vendors of the same solution and see if they have products that are IPv6 aware. Let your current vendor know that you are thinking about switching vendors due to lack of IPv6 compliance - this might provide the vendor motivation to update the client, in which case you won't have to incur the costs involved with deploying a new application If there is no client side fix that works for you, you might then check to see if there is some external Internet facing proxy or relay you can use for your application. When you use an external proxy or relay, the connections to the service will not be through the DirectAccess tunnels. Instead, they will go out through the Internet to the application gateway you configure them to use If there is no proxy, relay or application gateway option available to you, then you can use an SSTP VPN connection to connect to the UAG server. You can co-locate the DirectAccess and SSTP roles, so if the user needs to use an applciation that isn't IPv6 aware, the user can start an SSTP connection, complete the work that needs to be done with that application, and then close the SSTP connection if they want, or wait for the SSTP connection to time out after they're done with the application that required the connection. When the SSTP starts, the DirectAccess configuration will turn itself off, and when the SSTP drops, the DirectAccess configuration will be automatically enabled again. Not an ideal solution, but hopefully this scenario will be rare as application vendors realize that they're in the 21st century. If your clients don't support SSTP (SSTP is supported only with Vista SP1 and above), then you can fall back to publishing applications using the SSL VPN components of the UAG server. While not as transparent as the DirectAccess solution, and limited to only web applications (with some support for file share access over the SSL VPN), it does provide access for antiquanted Windows operating systems and non-Windows operating system through the UAG server. If you want clients to connect over PPTP or L2TP/IPsec network level VPNs, then UAG will not be the VPN server of choice. In this scneario, your best remote access VPN solution is the Forefront Threat Management Gateway. There is one important issue that you should be aware of, and this relates to those organizations that plan on using Force Tunneling. By default, UAG DirectAccess (as well as the Windows DirectAccess) enables a form of split tunneling, by virtue of the fact that requests for non-intranet resources are sent directly to the Internet server, and not tunneled through the DirectAccess links to the DirectAccess server and out through the corporate firewall or proxy. Some IT groups are hesitant to support split tunneling based on assumptions made during the 1990s and VPN client connectivity and the nature and capabilities of malware at that time in history. The networking and threat management landscape is very different now and issues that we're important in a split tunneling configuration 15 years ago are no longer extant. However, not all IT groups have caught up with this, and therefore may choose to disable the split tunneling configuration by enabling Force Tunneling. If you do enable Force Tunneling, be aware that all communications will be sent through the DA tunnels. This means you will not have the option to use a Internet gateway for your non-IPv6 compliant client applications and you will not be able to fall back to using an SSTP VPN. The decision to use Force Tunneling should be made with the knowledge that your client side applications all must be IPv6 aware - as they will not be able to use any fall back mechanism that requires them to connect to the Internet.