Monthly Archives: June 2014

“DirectAccess server GPO settings cannot be retrieved” received from Remote Access Management Console

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.
GPO Remote Access Error

 

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):
OU Layout

 

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?

  1. Link the DirectAccess Client Settings policy to the top level of active directory OUs and not to individual OUs
    GPO OU Setting
  2. 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!)
    GPO Filtering

Remove / Reset DirectAccess Name Resolution Policy on DA clients

DirectAccess is a very cool technology!  But, as with all cool technologies, sometimes things go wrong.
And with DirectAccess, when things go wrong, your DirectAccess clients can find themselves in a very broken state.

Some of our favorite symptoms of a broken client include:

  • Unable to resolve names via the internal name server
    I.E. no more ping to internal resources
  • Clients can’t update policies
    (This  one is really nasty if you have a new DirectAccess policy and your clients are difficult to get onto the internal network without the help of FedEx)
  • User’s screams of “I can’t get on the network”

In many instances, these symptoms are a direct result of a broken Name Resolution Policy via a bad (or outdated) entry in the Name Resolution Policy Table (NRPT).
Never fear, removing those entries is very simple!

Removing NRPT policy on Windows 7 clients

  1. Navigate to Start and enter the following text into the search box to launch the Group Policy Editor
    GPEDIT.MSC
  2. Once the Group Policy Editor has launched, navigate to
    Local Computer Policy –> Windows Settings –> Name Resolution Policy
    GPEdit Navigation
  3. In the right hand pane, scroll to the bottom of the pane and locate the Name Resolution Policy Table
    NRPT
  4. Delete BOTH entries
  5. Restart your client

 

Removing NRPT policy on Windows 8 and Windows Server 2012

  1. Navigate to Start and enter the following text into the search box to launch the Register Editor
    REGEDIT.EXE
  2. Navigate to the following registry node
    HKEY-LOCAL-MACHINE –> Software –> Policies –> Microsoft –> Windows NT –>DNS Client –>DnsPolicyConfig
    2012 Register Edit
  3. Locate and delete the entries below DnsPolicyConfig which have the format of DA-{GUID} (There should be two entries)
  4. Restart your client

 

Now, you can rollout new domain policies to your client as needed.
Please remember that you will need an alternate method of connecting to your internal network such as a standard VPN or a very long network cable.