Background
This story is about implantation of compliance requirements, and the technical changes made that caused some heartburn. In particular Exchange server and retention policies.
Very simple; Compliance, and regulatory practices.
Retention Policy was becoming enforced. As such on Exchange no less, see here for more information on how to configure retention policies on Exchange.
You might notice you have to create tags of time frames. In this case there wasn’t one already pre-populated with my needs. So you have to create those. You may have also noticed that the only name time frame is all defined with number of days.
Human Error
So long story short, I wrongly defined the number of days for the length of period I wanted to defined. Simply due to bad arithmetic, I swear I was an ace at math in school. Anyway, after this small mistake on the tag definition, and it was deployed to all Mailboxes. (Yeap there was steps of approval, and wasn’t caught even during pilot users).
Once it was discovered, there were 2 options. 1) Wait till specific people notice and recover as required, or 2) do it all in one swoop.
Recover deleted messages in a user’s mailbox in Exchange Server | Microsoft Docs
After following this, it was determined that we couldn’t find just the emails from the time frame we needed to restore. This turns out cause all the emails “whenChanged” timestamp all became the same time the retention policy came into effect. So filtering by Date was completely useless.
Digging a Hole
At this point we figured we’d just restore all email, and let the retention policy rerun with the proper time frame tag applied. While this did work, there was a technique or property that was recently added that would have restored the emails into the sub folders in which they were removed from. Instead, all the emails were placed back into users Inbox.
This was a rough burn. Overall it did work, it just wasn’t very clean and there was some fallout from the whole ordeal.
Hope this story helps someone prevent the same mistakes.