Here is the scenario: You logon to your shiny new DirectAccess server, launch the Remote Access Management Console and click CONFIGURATION from the action pane. A few seconds later you are greeted by the following message
DirectAccess server GPO settings cannot be retrieved. Ensure you have edit permissions for the GPO.
You frantically review your group policies and find that the DirectAccess Server Settings policy is available and applied to your DirectAccess server.
What the? (head banging start here)
The Root Problem
The message is misleading. The real problem is the DirectAccess Client Settings policy!
What is really happening (probably)
If you have an Organizational Unit (OU) based active directory system, you have probably moved the DirectAccess Client Settings policy to the appropriate OUs so the appropriate workstations and laptops receive the policy.
I.E. something like this (where the policy applies to the HQ/Remote OU):
In doing so, you very likely removed the security filtering group the policy was associated to.
It turns out this is a very bad thing in the world of DirectAccess. The DirectAccess Client Settings policy must be available to the DirectAccess server… but should never be applied to the DirectAccess server . In short, DirectAccess computers can only be identified via security filtering and *not* by assigning the policy directly to OUs.
UGH!
So, how do I fix this?
- Link the DirectAccess Client Settings policy to the top level of active directory OUs and not to individual OUs
- Filter where the DirectAccess Client Settings policy gets applied via a security group.
(Remember, you don’t want to apply this policy to your DirectAccess server… or any other servers for that mater!)
Hey, great to see others spreading the word on DirectAccess! I just wanted to let you know that you don’t necessarily have to link your GPOs to the top level of the domain. If you let the DirectAccess wizards handle the creation, linking and filtering of your GPOs (which makes things nice and easy for the Admin) – then yes, they will be linked to the top of the domain and you should not change them. But a lot of companies don’t like them being linked there, even if they are security filtered, and so you can absolutely make use of your own GPOs and link them wherever you want. If you do this, you are then responsible for creating the GPOs, linking them yourself, and filtering them yourself, and the DA wizard will simply populate those GPOs with information. Once created, all you have to do on the DA side is specify your own GPO names after you click the “Finish” button when you are finishing up the DA wizards. Thanks!
Jordan,
We agree, you can place the GPOs anywhere you want (with our without security filtering)… but only if you are willing to forgo having the ability to change the configuration via the DirectAccess management console. I.E. you must then manage your DirectAccess GPOs manually (no more wizards).
I had to add the user I created for monitoring Direct Access to the GPO DirectAccess Client Settings and the DirectAccess Server Settings, after that I restarted the SCOM service on Direct Access, and started to monitoring fine.
Greetings.,
Diego RIos.
We have a client GPO and a Server GPO that the console updates. We then make copies of these GPOs and link them to the appropriate OUs or use security or WMI filtering. This prevents the production GPOs from getting corrupted due to console issues. In a similar case as the issue described in this post the console errored out while attempting to add a 31st server to our DA environment. After the error the da console would no longer load. We discovered that the client GPO had been blanked out. Backed up the production GPO and imported into the blank client GPO . Console came back with no issues.