When using Direct Access; it is best practice to harden your Direct access server.
You can find them here via this link.
Watch out when disabling transition techniques
One of them is to disable transition techniques that you are not using; for example 6to4 tunneling and Teredo tunneling.
Only I found out you should do this only on your Clients, not your Direct Access servers. This because it will raise errors in your event log on the DA servers about disabled transition technologies and will show an error in the remote dashboard.
It is OK to disable unused transition technologies via a separate group policy, but not by altering the Direct Access Client policy that was created during the installation of Direct Access. This is because your adjustments are overwritten when you alter your direct access configuration when you change it via the Remote Access snap -in on of your Direct Access servers.
The below figure you can see that an error on one of my direct access servers. The error states that the retrieved configuration for server <server name> could not be applied. It suggests that the Direct Access policy cannot be applied. In my case, the policy actually did apply, but not fully apply. So there is no problem with ACL rights or what so ever on the GPO.
The problem lies in the fact that the direct access GPO tried to do something with a transition technique, like 6to4 or Teredo tunneling. But it couldn't do that, because I disabled it via another policy, thus getting this error.
On the following TechNet article you can find all the configuration statusses that are available.
If you look at the table, you can find the one that describes my problem.
Error |
Configuration for server [server name] retrieved from the domain controller cannot be applied. |
The configuration in the GPO reached the server but is not successfully applied, and more than 15 minutes have passed since the configuration was changed. |
This could happen in one of the following scenarios: |
From <https://technet.microsoft.com/en-us/library/jj574221(v=ws.11).aspx>
Looking at the task sequence like the TechNet article suggested. It is important to notice that the return code (check the figure below) is 0. That means no error was found and everything is honky dorry.