Now that our network traffic is flowing, we need to finalize a couple of other regular items on the DirectAccess server. First is setting the hostname. While this seems like a menial, regular task, don't take it lightly. It is recommended that once your hostname is set, it should not be changed in the future. So choose the name carefully, and choose a name that meets your naming standards. It is not recommended to change the hostname of a DirectAccess server, because there are items external to the server itself which are bound to that particular name, such as Group membership, Group Policy Objects (GPOs) filtering, and certificates. A change in the hostname of a DirectAccess server will result in a number of external factors needing to be changed, adjusted, or reissued, and there is a huge potential for problems. So all that to say—choose your name wisely and don't think you can name it DA-Test for now, and simply rename it later.
Once your name is set, it is time to join it to the domain. This is required for DirectAccess to work, as the solution is tightly integrated with Active Directory. You do not have to join it to the same domain as the rest of your internal network or the same domain as the DirectAccess client machines, but whatever domain you join it to must have a two-way trust to those domains, so that traffic can flow successfully between the DirectAccess server and the resources with which it is going to interact.
I highly recommend prestaging the computer account for your DirectAccess server(s) in Active Directory before you join them to the domain. This is not required, but I recommend it because I have seen many cases where upon joining the domain, a DirectAccess server had some existing GPOs applied to it which disabled items in Windows that are necessary for DirectAccess to function. What I see most often are GPOs in place on the network which disable or make changes to the Windows Firewall, and if any of these policies get applied to your DirectAccess servers, it will certainly interfere with operability.
Try your best to make sure that no existing polices get applied to the servers at all. It is best to create a separate Organizational Unit (OU) for them to reside in, which blocks the inheritance of existing policies. In the end, there are going to be policies that need to apply to them, the actual DirectAccess Server policy for example, but try to keep them as clean as possible from changes. Once you have DirectAccess connectivity established and working, you can try applying your policies one at a time if you so choose, but keep in mind that if a GPO gets applied and changes are made, then simply removing the device from that GPO's filtering doesn't always reverse the settings that were changed. It is possible that you could break the DirectAccess server to the point that the quickest resolution is to re-prep the server and start over, so tread lightly here.