For the purposes of this book, I do not have plans to walk through all of the configuration wizards and explain each and every step that will be taken while walking through those wizards. What I do want to accomplish is to take a minute and point out one critical note. Many of the DirectAccess "walk-through" or "Test Lab Guide" documents that exist will tell you at this point in the process to run the Remote Access Management console and launch that great Getting Started Wizard. You know, the one where you can "install DirectAccess in 3 clicks!" Please don't do this! I understand why they included this option, so that literally anybody with a mouse could get some semblance of DirectAccess up and running, but running this wizard follows zero best practices, and I would hope that anyone reading this guide about best practices in your DirectAccess environment would have no interest in taking shortcuts during your install.
I have spoken with many new DirectAccess administrators who didn't actually know they had a choice. It's pretty easy to glaze over the option and just follow whatever quick-start guide you are using and choose the Getting Started Wizard. So, I want to point out the way to launch the real wizards instead. After you add the Remote Access role, your next step is configuring DirectAccess. To do that, while you are still inside Server Manager, you can navigate to the Tools menu and choose Remote Access Management from the menu.
The first screen you encounter here is your fork in the road. Clicking the top link here obviously launches the Getting Started Wizard. The second link listed under it, Run the Remote Access Setup Wizard, is the link that takes you into the full configuration wizards, and is absolutely the way that you want to go.
I cannot tell you to stay away from the Getting Started Wizard without backing that up with a little bit of data, so let's talk about some of the reasons that I recommend handling this wizard with a ten-foot pole.
Hopefully, now that you have read the beginning of this chapter, you know that you should input your certificates onto the server before you even add the roles. Unfortunately, most DirectAccess admins are not aware of this, and so the roles get added and the wizards run before the certificate is in place. When you run the Getting Started Wizard, if your certificate for IP-HTTPS is in place, it will recognize and use it, but if you do not have a valid certificate in place, it will generate and use a self-signed certificate for this purpose. The wizard will also generate and use a self-signed certificate for the Network Location Server (NLS) website. Using self-signed certificates is fine for a Proof-of-Concept or a Test Lab, but they are obviously a very bad practice for a production environment. Using a self-signed certificate means that your DirectAccess server can be easily spoofed, and the old 1024-bit key length used by self-signed certificates is no longer considered to be strong enough.
As we will discuss more in Chapter 3, Configuring Manage Out to DirectAccess Clients, a DirectAccess environmental best practice is to host the NLS website externally to the DirectAccess server. When you use the Getting Started Wizard, for the sake of saving mouse clicks, it assumes that you want to host the NLS website on the DirectAccess server. It also issues a self-signed certificate for this site.
Running the Getting Started Wizard also assumes that you are not interested in using any transition protocol other than IP-HTTPS, and disables them. We will talk some more shortly about the reasons that you want Teredo available to you if possible in your environment, so this again works against best practices in an effort to make implementation as automated as possible.
Yikes! If you have ever run through the real DirectAccess wizards, or have been through the UAG DirectAccess wizards, you know that the client-side GPO settings are filtered out to only the actual DirectAccess client computers by way of Active Directory group membership. During the wizards, we define the group or groups in Active Directory that are going to contain our DirectAccess client computers, and the wizard defines security filtering on the client-side GPO, so that those settings only come down to the actual DirectAccess computers. This is a great idea! You, of course, don't want a bunch of remote access connectivity settings distributing themselves around your internal desktop computers, or worse yet servers in your network. The Getting Started Wizard has the potential to do just that. When you click on this mini-wizard, it flags the GPO to apply to all domain computers. Now, it does set a WMI filter on this so that it only applies to mobile computers as defined in the Windows WMI filter, so chances are that if you have already run the Getting Started Wizard in your network, at least these settings aren't running rampant, but those WMI filters are far from 100 percent accurate, and I just dread thinking about all of those networks out there where the link in their DirectAccess GPO right now says "Domain Computers".
This one is pretty obvious, but I'll state it nonetheless. If you run the Getting Started Wizard, you won't encounter all of the optional settings that DirectAccess has available, so you may miss out on some advanced implementation of which you want to make use. If you have already implemented DirectAccess by using the Getting Started Wizard and are in production and don't want to start over on your configuration, you can still make adjustments to your settings and overcome the limitations that were put into place by the wizard. Inside Remote Access Management, you can head into the Configuration section and gain access to the individual steps of the real wizard here to make adjustments after the fact. Keep in mind though, that you do not have the option to change GPOs afterwards, and that running the Getting Started Wizard disables Teredo at a lower level that cannot be overcome by the wizards. You must use PowerShell to enable it, and that process is detailed in the last chapter of this book, when we discuss some specific troubleshooting scenarios.