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.

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.

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!