Deleted GPP Still Applies, even after manually removing from client

[noahmiller]

Hi All -

 

I'm trying to figure out if this is intended behavior, or if something in our AD is broken.

 

We greatly changed our Group Policy structure before the start of this school year to heavily use Group Policy Preferences. For the most part, that has been highly preferable (pun intended) to the previously used scripts. I'm seeing some odd behavior with GPP items (as described in the title) and I'm wondering if something is broken, or this is the way GPPs work.

 

One example is a shortcut I added to the desktop of all users via GPP. It was set up as an "update", but this also applies for creates, deletes, and replaces. After removing this particular GPP shortcut, it still gets created on the desktop of all users. After that GPP item is deleted, I can remove the shortcut from the desktop, and do a gpupdate, and the shortcut is re-created. I can remove all windows profiles from an affected computer, and the shortcut will be recreated at the next login. I can log into a machine I've never logged into before, and the shortcut will be created. I've tried removing "C:\ProgramData\GroupPolicy" on an affected computer, and the shortcut gets recreated. I've tried removing all the Group Policy registry keys from an affected computer, and the shortcut will still get recreated at the next policy refresh.

 

When I do a group policy model, it will NOT show the GPP shortcut, and thus it seems to me it should not be applied, but it gets applied nonetheless. I can even go into the SYSVOL on all the domain controllers, and look at the individual preference XML files inside the policy, and they do NOT show the GPP item. Still, the GPP item gets applied. How? And where is it coming from?

 

The only way I've found to get the shortcut to NOT be recreated when policy is refreshed is to remove the entire GPO that the GPP item lives in, and then perform a gpupdate when the GPO is unapplied. After that, I can reapply the GPO, and the shortcut (or any other previously removed GPP item) will not be applied to the target machine when policy is refreshed.

 

This is OK, but it means if I have to delete any preferences, I will need to unapply the GPO they're in, refresh policy on ALL machines, then reapply the GPO. This will be very problematic in a busy environment.

 

Is there some type of non-tattooing policy I've missed, or that I need to apply somewhere? The "Remove this item when no longer applied" option in each GPP doesn't seem to work, and it requires that all items be configured as "Replace", which can slow down logins and processing.

 

So, intended behavior or broken AD/policy?

 

 

Thanks!

Edited September 30, 2015 by noahmiller

[Oaktech]

That sounds like you've forgotten to take a shortcut out of the old GP, or you've left an old GPO applied somewhere...

 

However...

 

Have you tried it on a fresh machine that has never seen the old GPO structure? Can you add a new machine to an OU that has inheritance blocked and then add in GPOs untill a problem occurs to identify where in your structure the anomaly resides?

 

If nothing goes wrong on a new machine you might need to begin to rebuild your existing machines.

[noahmiller]

Thanks, Oaktech. So, I'm gathering this is NOT the intended behavior of GPP items?

 

I've definitely removed the offending GPP item(s) from everywhere, and only new (this year) GPOs are being applied. I can verify that with Group Policy modeling. The offending GPPs do not appear in the modeling results after they've been deleted, but they still get applied on policy refreshes.

 

Yes, I've tried it on brand new Windows 7 VMs, and the issue is there as soon as I add the machine to AD and log in. The only way to make it not happen is to log in with a user for whom the GPO is not applied.

 

I'm heavily leaning toward an unidentified problem in one or more of our domain controllers.

[Oaktech]

You say you see it as soon as you add the machine to AD, are you adding to an OU with all GPO's applied, or like I suggested adding it to an OU with inheritance blocked and then adding in GPOs one at a time to see if one particular GPO is at fault? What GPO's do you have applied at the domain root level? Usually this should only be the default domain policy and directaccess settings if you use them.

 

I would check and make sure that replication is taking place without errors between your DCs. repadmin.exe is your friend here https://technet.microsoft.com/en-us/library/cc770963.aspx?f=255&MSPPError=-2147217396.

 

If you have the facility to create a test lab, bring up a fresh DC with a fresh domain and export/import GPOs between your live and test domains and see if you get any anomalies.

[noahmiller]

It actually doesn't seem to matter where the machine is in AD or what machine policies are applied to it. The "bad" GPOs are user-only GPOs, so as long as the user logging in is covered by those policies, the problem occurs. The only ones I have applied at the root are the default domain, and a few for a third-party product (PolicyPak).

 

Yes, I can definitely narrow down the GPO where the problem occurs, and it happens with any GPOs that have GPPs configured. The GPPs in them will stick even after being removed (as long as the policy containing them is still applied for the user).

 

That's a good idea to check repadmin. I'll do that and report back. As for the test lab: oh, to have such free time. Maybe in November.

 

Thanks again.