I'm in the process of replacing an old 2012 DirectAccess server with a new 2012 R2 server. I have a Win 7 x64 SP1 test machine that will bring back the old servers NRPT entries when I run a gpupdate /force, which breaks DirectAccess due to incorrect name resolution. When I run gpresult to find the source of the entries, "Local Group Policy" is listed.

I can go into Group Policy Editor for local machine manually delete the entries, apply the settings, and see the entries disappear from the registry under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig when I refresh the registry editor. At this point, if I reboot the machine and log back in, DirectAccess will connect. However, if I gpupdate /force, the entries come back again citing local group policy. There does not appear to be a group policy from the domain creating the entries as extra registry settings. Has anyone experienced or fixed similar behavior?

* The NRPT entries were previously imported using a reg script. However, even using a new reg script to clear all existing entries and generate new ones does not change the gpupdate behavior. Gpupdate without the force parameter does not exhibit the issue.

Hi,

This seems really strange because a Domain GPO always win over a Local GPO.
To be sure of your settings, launch a RSOP.MSC then check in "Computer Configuration --> Administrative Templates --> Extra Registry Settings"

You'll find there the DNSClient settings from your DirectAccess infrastructure and to the right, the GPO name.

Gerald

It's not an issue of which policy is winning because the application of the NRPT settings in this case are cumulative. It's adding the entries from both the GPO and local policies. The result is that both sets of entries appear in the NRPT and have different DNS servers defined for the same group of names and keep DirectAccess from working correctly. I can understand that part. What I don't understand is why I can see them in local policy, delete them from the local policy using the local security policy editor, close/reopen to be sure they're gone, see that they're gone from the registry, but watch gpupdate /force restore them from where? I can even reboot the PC after they're gone from local policy and the registry, but a gpudate /force is restoring them from somewhere. I have two Windows 7 SP1 test boxes. One does it and the other doesn't. It may just be a fluke on the box displaying the problem.

• Edited by AMReagan 13 hours 16 minutes ago

Just an idea but if someone put these NRPT registry settings in the Group Policy Preferences of a GPO for test, that could explain why you receive them back each time the system refresh the group policies.

You could list the current GPOs applied to your computer, isolate the computer account in a new OU, then  apply the GPO one by one to see if one is pushing theses settings.

• Edited by Gerald Mathieu 11 hours 8 minutes ago

It's not an issue of which policy is winning because the application of the NRPT settings in this case are cumulative. It's adding the entries from both the GPO and local policies. The result is that both sets of entries appear in the NRPT and have different DNS servers defined for the same group of names and keep DirectAccess from working correctly. I can understand that part. What I don't understand is why I can see them in local policy, delete them from the local policy using the local security policy editor, close/reopen to be sure they're gone, see that they're gone from the registry, but watch gpupdate /force restore them from where? I can even reboot the PC after they're gone from local policy and the registry, but a gpudate /force is restoring them from somewhere. I have two Windows 7 SP1 test boxes. One does it and the other doesn't. It may just be a fluke on the box displaying the problem.

• Edited by AMReagan Thursday, April 23, 2015 6:08 PM

Just an idea but if someone put these NRPT registry settings in the Group Policy Preferences of a GPO for test, that could explain why you receive them back each time the system refresh the group policies.

You could list the current GPOs applied to your computer, isolate the computer account in a new OU, then  apply the GPO one by one to see if one is pushing theses settings.

• Edited by Gérald Mathieu Thursday, April 23, 2015 8:16 PM

A quick question, as we were using a REG script to put the settings previously, - Was it configured to run at machine startup - which might be populating the settings over and over?

Usually DA's GPOs will be configured at Domain Level, which will be applied only if the mahcine is part of "DA_Clients" group.

Since we are seeing this as a local GPO, and this gets applied only after GPUpdate /force - I suspect if some startup script is populating reg file or something. 

It's not being applied at start up in any capacity. We use a reg script to apply the same settings DirectAccess pushes from GPO as a repair tool. If a user is out in the field and DirectAccess stops working, the help desk can run the ip6 reset to reinstall the iphttpsadapter, and then run the reg script to remove and reapply all of the DirectAccess settings, which fixes the majority of machines and avoids the need to enable a VPN or return to the office. On the machine in question, it can keep the correct settings of the new DirectAccess for days, through multiple reboots and even with gpupdate. However, a gpupdate /force will return the settings from the old server. It's weird, and may just be this one machine. I was mainly curious if any group policy gurus know what could be causing this. Does force somehow look to a backup .pol file for local policy when the force parameter is used?