Retention policies need some rework.
Currently if you set up a new retention policy, it uses the time that the policy was created/run as the start date for counting the days till deletion. Meaning setting up a 5 year policy will not delete emails in stores that are older than 5 years, it will wait 5 years from the day it was run to delete them. If you ever need to change a long retention policy or add a new one, it simply isn't going to function correctly on existing databases.
Additionally, the condition requirements are mediocre. Why is there no option to not have any condition and simply have a global retention policy? There isn't an option for folder/user/group based retention, nor an option to set conditions using anything other than AND operaters between conditions.
Thanks for your suggestion
I suggest having a look at Retroactive Retention
yes, that's how it works, however, if you simply want to delete older emails why not just disconnect the respective Archive store and delete the search indexes?
All emails should be correctly located in the respective database.
Jon Lind commented
Running the retention policy retroactively against the existing archives is exactly what I was doing and how this was discovered as an existing problem. I've spent hours over the past few weeks working with GFI support trying to get this to work as it sounds like it was intended to. However, retroactively running a new retention policy (in my case, delete everything older than 1825 days) does not actually remove any emails at all. The retroactive scan runs, flags the emails with the policy, but it uses the date that the scan ran as the start of the 1825 day counter. Meaning my archived emails from 2009-2013 that should be deleted immediately (or flagged for deletion for the 11pm maintenance job) instead are flagged for deletion 5 years from the day i ran the retroactive scan.
That is how it was explained to me from GFI support after working with their 1st tier and 2nd tier (database?) support.