Another interesting issue I ran in to a few weeks ago was issues when trying to create a new GPO via AGPM which included wireless settings. Upon trying to check the policy in I would find it would error and then the GPO would be removed. Not exactly what I need.
Further investigation show due to the way the GPO settings are stored for wireless settings, there is a known issue if you create a policy and attempt to deploy straight away.
Whereas most GPO settings are stored in SYSVOL (due to size and they would bloat AD), the wireless settings are still stored within the AD.
There error you see within AGPM is due to the two of these clashing when you attempt to check-in (if replication has not occurred). This is down to how AGPM works, and the temporary policy which is created when a GPO is checked out.
When you check out a policy AGPM creates a temporary policy called [AGPM] POLICY NAME. If AGPM does not have time to replicate this information when you come to check in the GPO the settings no longer match between the version you’ve been editing and the temporary GPO.
As you can see below I have checked out my GPO but it’s not appearing.
This causes a clash and removes the GPO from AGPM. This then creates a conflicted GPO record with AD (notice CNF after the policy GUID)
If you allow time for AD replication to occur you will noticed the policy does appear under the GPO objects:
You can now safely edit the policy, and check-in the GPO
And you should now be able to deploy the GPO OK
IF you need to edit the GPO again PLEASE make sure the [AGPM] POLICY NAME is no longer present. If I was to attempt to edit the policy straight away after checking in I would get an error and another conflict due to the Temp policy still being present