Share via

365 Retention Compliance policies not deleting items

RobinCM 91 Reputation points
2021-10-29T16:55:50.043+00:00

I've got two retention policies configured via compliance.microsoft.com that are configured to retain items for a period of time and then delete them. However I'm finding items that are significantly older than should be present when I run a user data search from the compliance center.

There are no other holds on the mailboxes, and this (from some spot checks) seems to be affecting all users. Affected users have E5 licences.

The retention compliance policies have been enabled since February this year.

One policy targets Email items, the other targets Teams Chat items. The email policy keeps items for 455 days then deletes, the Teams one keeps items for 30 days then deletes.

As of right now, I am seeing every teams message back to 1st June. A few days ago it was back as far as 26th May. So it seems like instead of 30 days I have ~5 months being kept. The majority of those messages are in the SubstrateHolds folder (which sits under Recoverable Items). Teams messages as seen in the Teams client are only available back to 30 days ago (i.e. items in the TeamsMessagesData folder from a user data search point of view).

Any suggestions would be very welcome. a) how do I get this working properly, or b) is there a (workable) way to remove the messages that shouldn't be there any more?

Presumably this functionality does work as expected at the moment?

Output from assorted useful (I think) PowerShell commands is below.

Exchange Online
Exchange Online
A Microsoft email and calendaring hosted service.
6,187 questions

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. RobinCM 91 Reputation points
    2022-06-16T16:02:08.35+00:00

    Well, after much to and fro with the support team, this is now mostly resolved, but not quite, in a compliance-busting way.

    I had several responses from support of "this is by design", which seems to be a standard way for 365 support to try and fob off customers with tricky problems. It isn't by design, and if it is, the design is so badly flawed it should never have made it through the approval process to get built.

    If you find that items in your SubstrateHolds folder aren't being purged correctly please reference ticket number 27728613.

    Everything should now be working for everyone in the world (so I was told) APART from items in the Deleted Items folder. Despite my strong objections to the contrary, apparently it really is by design that the date used to purge items from the Deleted Items folder is completely different and (effectively) arbitrary to items in ANY other folders. I've been told that I need to file a design change request including a business impact statement to get this fixed. So if you do business in the EU or anywhere else covered by ISO27001, GDPR etc. I suggest you check into this by running some tests on your own tenancy, as 365 is currently probably not doing you any favours in regards these standards/regulations.

    For the Deleted Items folder, the Retention Date is stamped onto the item when it is deleted and the item is copied to Deleted Items. When the MFA processes items for the first time it stamps the current date as the retention start date, the setting you chose when configuring the policy is ignored.

    1 person found this answer helpful.
    0 comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.