Brad; I am not following exactly what you are looking for.  Purge old Settings from where? On the MSP Server, there will only every be ONE version of a given Settings.  When you edit it, it will increment a number to indicate that it HAS been changed.  This is critical in driviing Policy Compliance. The way Settings Packages are handled is that the Package Name is the Settings Class.  So, for example, if the Settings Class is Agent.30, then ALL Settings created of that Class will have the identical Package Name of "Agent.30".  The Package Version of a Settings Package will be the concatenation of the Settings Object Name and the sequence number.  For example, the Package Version of an Agent.30 Settings Object might be MyObject_123, indicating it was created from a Settings Object named "MyObject" and that it was assigned a unique number 123 to distinguish it from all other edits of that same Object. Now, any one device can only have at most ONE Version of any given named Package.  So, that means that if a Settings Package of a given Settings Class is deployed to a device, it will replace any prior Settings Package of that same Settings Class.  This is referred to as Single Instance and is intentional.  So, you can have only ONE Agent.30 Settings Object applied on a device at once.  It does not matter whether it is a different Object Name or a different edit of the SAME Object Name (resulting in a different appended number).  Both will result in the SAME Package Name and a different Package Version and hence will be treated by the Agent as a replacement of the prior Version of that Package with the new version of that Package. The MSP Server will keep ONE edit of a given named Settings Object (the most recent) and can keep any number of different named Objects of a given Settings Class.  When a Settings Object is edited, the unique number is updated and any prior edit of that same named Settings Object is discarded.  Any Bundle that references a Settings Object always references the ONE version that the MSP Server keeps.  Since the Settings Package for that Settings Object DOES change version due to the edit number appended to the Package Version, any Policy that references that Bundle will become Non-Compliance because devices have the OLD Version of that Settings Package (the one with the old edit number).  This will ensure that the newly edited Settings Object will be sent out to all devices.  As Jobs are sent out and executed, the devices will become compliant as they report that they now have the latest version of the Settings Object. The only place that multiple versions of the Settings Object can accumulate is on the Relay Server, which will have every version of the Settings Package that has been deployed to devices via that Relay Server.  But that will NOT affect Policy Compliance, since the MSP Server will only have ONE version and will always base Policy Compliance on that ONE Version.  If there is a need to clean up the Relay Server (for size reasons) you can set up the Relay Server Optimization Service to remove old versions just to keep things clean. Allan