Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have one server - 2008 R2 Enterprise, running WSUS and our KMS server - which is failing to apply any group policies from the domain. I'm out of ideas of how to get this to process. Any ideas?

My steps so far have included the following.

  1. verified that the secure channel is good via netdom verify myhost
  2. tried gpupdate /force
  3. Reviewed the gpresult /v output - which shows no computer policies what so ever
  4. Poked through the registry. HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\GPOLink-List only shows an entry for the local policy.
  5. Rename the folder C:\ProgramData\Microsoft\Group Policy
  6. Remove the key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
  7. Apply the steps outlined at KB310741
  8. triple check the event log (application, system, group policy operational) all of which don't show problems.
  9. triple check the location in AD computer and group membership settings - there should be about 30 policies applying.

Anything more obvious I've missed?


I did notice one additional item of some interest - the Distinguished-Name value on the State\Machine key described above is coming back blank. Not sure how or why. I tried pasting the correct value in but it didn't work.

share|improve this question
Check the Group Policy event log on the server for clues. – joeqwerty Oct 7 '13 at 20:25
@joeqwerty I already looked at the operational event viewer for group policy. Nothing showed up. Any other thoughts? – Tim Brigham Oct 7 '13 at 20:58
Is this a new server? When you run gpresult, is it actually enumerating the policies? – Colyn1337 Oct 8 '13 at 21:06
@Colyn1337 - it was not. I answered a couple minutes ago detailing what the problem was and how to fix it. – Tim Brigham Oct 8 '13 at 21:08
up vote 4 down vote accepted

After all the headaches and problems that this has caused for the last several weeks it looks like the problem was how our windows server was activated. Looks like someone inadvertently put in a KMS key via the GUI.

This resulted in the OS not activating correctly and not being fully (?) joined to the domain. This filtered down to not being able to interact with the domain controllers properly - the join domain box was greyed out - and the DN entry required for group policy to work not being populated. In the end the greyed out join domain box was the clue I needed, indicating a problem with the windows license.

When I punched in a MAK key and put in our KMS information via cscript cscript slmgr.vbs /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx as it should have been everything started working exactly the way you would expect.

Hopefully this'll help another poor soul out of a month worth of extra work.

share|improve this answer

You don't mention whether you've run RSoP, but that would be my first step. Also, does the server show any sign of "applying computer policy" during start-up?

Once you've got your RSoP results, you can at least see whether the server believes it should be applying policies (if nothing else, the default domain/user policies).

--Begin Edit-- Just re-read, and noticed you've run GPRESULT. I'd therefore continue with process monitor (below). --End Edit--

My next step would be to use Microsoft SysInternals Process Monitor in boot logging mode to see what's happening.

Also, another thing I've tried in the past is to use PsExec to launch a command prompt, running as the local SYSTEM account. You can then perform a simple directory listing of the policies area in SYSVOL. Bearing in mind that policy application/filtering is controlled by good-old NTFS ACLs. If you're able to see the policies* (and these will be the computer policies), you have another issue.

*Policies are listed in SYSVOL using their GUIDs, but these can be resolved by querying AD (or browsing around using ADSIEDIT, or similar). If you need the LDAP path, shout.

share|improve this answer
Thanks Simon. I thought about the NTFS ACLs as a potential issue as well but I'd expect that to be more of an 'access denied' error rather then not having the policies show up as linked at all. Process monitor did find a potential orphaned file that might be causing this. – Tim Brigham Oct 7 '13 at 18:23
I'm able to list the contents of all of the directories in the sysvol share as I expect I should be able to use as the computer account. Looks like that isn't it. – Tim Brigham Oct 8 '13 at 18:46
Sorry, don't quite understand your comment. You can list the contents using the local system account? Ignore - just noticed you've found the problem! – Simon Catlin Oct 11 '13 at 20:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.