Active Directory Group Policy Security Groups Differ From User's Groups

I've been having some weird group policy issues lately, so I wanted to test on a clean setup and haven't had any luck, so I'm hoping someone else can shed some light. This is on Windows 2003 R2.

I created a test user and added it to a test global group. I then set up a GPO linked to the root of the domain that has security filtering to only apply to the test group and tried to see if my settings applied.

If I use Group Policy Modeling, everything looks correct, but when I do Group Policy Results or check the actual machine, nothing gets applied. I first thought I had GP issues and tried the usual with rebooting, gpupdate, waiting a day hoping things would apply, etc. I then tried created a different user, tried a different machine, even tried adding the Administrator account to the test group and nothing worked.

Then I noticed that under "Security Group Membership when Group Policy was applied" in GPMC and "The user is a part of the following security groups," the test group is not listed as a group the user is a member of.

I've tried creating a different domain local group. I've tried adding Administrator to the groups and seeing of the GPs will apply to that account, but it doesn't.

However, if I create a share on the domain controller and only give that group access to it, the test user can access it fine, so I know the user is definitely a member of that group.

How can I convince GP that my user is really a member of those groups?

From serverfault Dave

• Have you checked your eventvwr logs? Do you have other Domain Controllers (DCs) in this domain? Which one is the Global Catalog (GC) FSMO? Try running

  dcdiag.exe
  

  and check the output for problems, especially with the SYSVOL and/or replication with other DCs.

  THIS CAN BE DANGEROUS: If this is not the only DC in the directory, and the event logs don't reveal anything, try making a copy of the sysvol\domain\policies and place it elsewhere on the hard drive of the server. Make sure you do this during off hours and make sure you perform a complete AD backup using:

  ntbackup.exe backup systemstate /J "pre-delete-ad-backup" /F "c:\adbackups\ForestBackup.bkf" /V:yes /M normal
  

  Copy the ForestBackup.bkf off of the server after the backup is complete.

  After you create the backup and copy it elsewhere, delete the sysvol\domain\policies directory. Then force a replication with another DC in the Directory using replmon.exe

  Check the FRS eventlog and see if you get messages about a successful sysvol replication. Keep in mind that until Sysvol is restored in complete, your server will not be able act as a DC, so make sure that another DC is available to your clients...

  Dave : I have one other DC. I have run dcdiag and looked through the event logs and everything seems clean. The only issue is an event log entry we have gotten for years: Warning, NtFrs, ID 13562. "Following is the summary of warnings and errors encountered by File Replication Service while polling the Domain Controller for FRS replica set configuration information." When I Google for the error, no one else has an empty message and so I've assumed there's nothing wrong, but maybe there is. I've never seen a "successful replication" message.

  Dave : Actually, using replmon I *do* see "The last replication attempt was successful" on both my DCs, so maybe replication is fine.

  Scott Lundberg : If you manually compare the directory sizes of sysvol\domain\policies between your DCs, are they the same? Same exact number of bytes? Same timestamps on the subfolders within policies directory? If so, then I would say that replication is not the problem... Do you have any Restricted Groups in any of your linked policies? Run the Group Policy results to check...

  Scott Lundberg : Also see this URL for info on your eventID http://support.microsoft.com/kb/312862

  Dave : Sizes are exactly the same down to md5 sums and I don’t have any restricted groups. Thank you for the URL though, because I discovered that I do have a big problem where one of my DC’s distinguished names does not match the server name. No idea how it happened, but I bet that is causing at least some of the problems and I need to fix that first.
  From Scott Lundberg

• Sounds like GPO inheritance might be a possible cause. Have a look here: http://technet.microsoft.com/en-us/library/cc739343%28WS.10%29.aspx

  Dave : I was actually just at that page yesterday. I've moved the users and groups and OUs and GPO links and everything around to try to make sure there are no inheritance issues and at this point, I can’t imagine inheritance being the problem. I see the policies listed, just that they’re denied because of security filtering.
  From mh