(Updated July 21, 2010)

Interesting post on the TechNet forums regarding problems with configuration.exe:

“I currently have a working DirectAccess single server UAG deployment (using at trunk as well). It is working fine and i have updated the deployment to Update roll-up 1.

I am due to demo to a client DirectAccess with UAG and they are also interested in using NAP. So I have built and deployed a NAP server, but now every time I try to change any of the settings in UAG for the "DirectAccess Server" component the console hangs (50% CPU) and i have to kill configuration.exe .... I get this no matter what i edit on the last stage of that screen (i.e smart card auth, certificates etc... it literally hangs the second I click anything!).

I have tried running a procmon trace but without much insight, I've also made sure i disabled any Anti-Virus on the server.”

http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/45a79cc3-da73-460a-a267-6a0d8e59c6a3

===============================

The solution to the problem is to run:

C:\Program Files\Microsoft Forefront Unified Access Gateway\utils\ConfigMgr>configmgrutil -del -

and give it another try.

WARNING:
Be aware that executing this command will delete the entire UAG configuration, including DirectAccess configuration and trunks, and you will need to reconfigure your UAG server manually to its previous configuration. If you have an uncorrupted backup you can restore the configuration from backup.

Apparently, this happens when you select an Intermediate Certificate Authority on the NAP configuration (checkbox) page. You can’t use an Intermediate Certification Authority for IPsec (with UAG, at least at this time).

There is also an issue with NAP enforcement with the RTM version of UAG, so make sure you upgrade to UAG Update 1.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

I hear a lot of folks talking about deploying DirectAccess as a replacement for their current VPN solution. They often want to move large numbers of their users from working at the office to home offices. This is a great idea, as it saves on the infrastructure costs related to heating and cooling offices, fuel costs related to driving back and forth to work, and ideally increase the employees overall productivity because they could use the time they were driving to work to actually get work done.

That’s all consistent with the goal of DirectAccess – to provide your users an intranet computing experience from anywhere in the world. And when I speak of “users” I’m not just talking about end-users - “users” also include IT, as your IT group will be able to have the same connectivity to, and command and control over, DirectAccess clients as they have with any other client they manage on the intranet today.

When talking to people about DirectAccess, it’s best to not think of DirectAccess as a “VPN” solution – since the vision of DirectAccess is to keep the DirectAccess client continuously connected to the intranet – thus bringing the intranet “out” to all DirectAccess clients. In contrast, VPN connections (SSL and network level) are about temporary connectivity that enables the VPN client “into” the intranet. It might seem like hair splitting, but the practical implications are significant, both from the end-user productivity perspective and the IT management and control perspective.

Because this vision is all about highly managed corporate controlled systems, you still might want to provide VPN access for machines that don’t fit into this vision. You might need to enable partners full network access at times, or perhaps the IT group needs VPN access from unmanaged machines of their own to get work done when out of the office. In this scenario, the DirectAccess and VPN solution can site side by side, or if your VPN clients support SSTP as a remote access VPN protocol (clients are Windows Vista SP1 and above), you can co-locate the SSTP VPN server on the DirectAccess server or array.

So when carrying out your DirectAccess deployment planning, remember that VPN is something that you’ll want to bake into the overall remote access solution.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Secure Endpoint: DirectAccess and Microsoft Forefront Unified Access Gateway 2010, the Complete Remote Access Solution

Spend an hour learning about Microsoft's complete remote access vision and how UAG and Direct Access Technology together provide seamless remote access to users while reducing IT risks and costs. This session includes a live demonstration of the features and the remote access solution in action

http://www.msteched.com/2010/NorthAmerica/SIA301

End-to-End Remote Connectivity with DirectAccess

DirectAccess is a new feature in the Windows 7 and Windows Server 2008 R2 operating systems that gives users the experience of being seamlessly connected to their corporate network any time they have Internet access. With DirectAccess, users are able to access corporate resources (such as email servers, shared folders, or intranet Web sites) securely without connecting to a virtual private network (VPN). This chalk talk addresses questions on setup and troubleshoots a DirectAccess infrastructure

http://www.msteched.com/2010/NorthAmerica/WSV207 

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

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 IPv6 aware 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. There are some exceptions to this, such as not being able to initiate a connection from an IPv4 only server or server application to a DirectAccess client, or when there are “call-backs” required or when there are addresses imbedded in the application protocol, but for the most part the IPv4 only server application will not be a problem.

Options for Client-side Application that are not IPv6 Aware

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 Internet facing proxy or relay 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 application 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 network level VPN link. When 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 for some reason 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 scenario, your best remote access VPN solution is the Forefront Threat Management Gateway. Note that this isn’t really a DirectAccess client issue, since DirectAccess clients will always support SSTP. However, I mention it because if you were thinking that you could consolidate all of your remote access VPN clients, including down-level clients, you won’t be able to do that since UAG supports only SSTP and not L2TP/IPsec and PPTP.

We’re Here to Help

Something that I want to make clear is that if you are running into problem with your client-side applications, we’re here to help you. We’ve helped customers get some applications working with DirectAccess that at first didn’t seem to work. If you want to deploy DirectAccess but are facing a difficult application that doesn’t seem to work with DirectAccess, we want to know about your problem and see if we can help you solve it. Please contact me at tomsh@microsoft.com and I will put you in contact with the team who can help you move forward in helping to solve the application issue.

The Force Tunneling Issue

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 regarding VPN client behavior 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 or have their hands forced by other decision makers, 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 facing proxy or relay for your non-IPv6 compliant client applications and you will not be able to fall back to using an SSTP VPN, PPTP VPN, L2TP/IPsec VPN, or even an SSL VPN.

The decision to use Force Tunneling should be made with the knowledge that all your client side applications must be IPv6 aware - as they will not be able to use any fall back mechanism that requires them to connect to the Internet.

HTH,

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder