Sometimes we can be guilty of making assumptions. We can enable a remote access technology without much concern for impacting operations on the internal network right? Wrong!
Because DirectAccess modifies the behaviour of the Windows7 machine you need to make absolutely certain all the ducks are in a line or you risk internally connected users being denied access to the internal network.
When you set up DirectAccess is forces you to select a control group (an Active Directory group). This control group is used to decide which machines get the DirectAccess policy. If you apply the policy to machines that do not have dependencies met those machines will be unable to fully access the network internally. And as they are not fully on the network it makes rollback a real challenge.
The symptoms include the inability to resolve the machines domain FQDN name via ping but strangely can resolve via NSlookup. The laptop will log on via cached credentials. Network resources will not be accessible and as Group Policies will not apply it becomes hard to reverse the change. Probably more than one way to reverse this, I hit this in the lab so I simply dropped the machine out of the domain and back in again – not such any easy step with many machines to worry about i’m sure.
One of the fundamental dependencies is a trusted machine certificate on the laptops that get the policy. Having CRL and AIA paths that are accessbile both inside and outside the organisation are also critical (so the certificate validity can be checked and maintained).
Not a short read but the dependencies are detailed within the design and implementation guides on technet http://technet.microsoft.com/en-us/library/cc196387.aspx
