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
Jon Lind commented
That's what we will be doing, as that is the only option we have. The problem is that manually deleting old emails defeats the purpose of having a retention policy. In this example, I have to remove and delete email stores older than 5 years. Then for the next 5 years while the retroactive scan catches up, I have to make sure I've scheduled time at the start or end of the year to delete the store that is now 5 years old. After all of that I have to check on the 6th year to make sure that the retention policy I set up actually works in correctly deleting 5 year old emails. If something was wrong with the policy, then the cycle starts over. Hence the need for a flat global retention policy and for retroactive scans to run from the received date of the emails.
There are many other possibilities for situations where I could see this being useful. What if my company decides 7 years into storing emails that they certain emails to be deleted after 2 years to save on storage space. In this situation, it would take 2 years for the retroactive scan to remove any old emails to see how much storage space was freed up.
Probably the biggest issue I have with this whole problem is that I couldn't find anything stating clearly how retroactive scans work, and that they simply wouldn't work how everything I've read implies that they should. I was unable to find anything stating that they use the date of the retroactive scan as the time for counting how many days before deleting. Logically if I am setting up a retention policy, it makes sense that its looking at the received date of the email. When I called support, it took several phone calls, multiple uploaded logs, and then finally a database technician to tell me that it works the way that it does. No one knew how it worked and no one could provide any reason to why it works this way.
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.