Discover more from Mike McBride on M365
Collecting the Shared Version of Cloud Attachments in M365
The first question everyone had when I showed them how to collect cloud attachments - which version is it collecting?
In the earliest days of Microsoft’s eDiscovery tool having the ability to “Collect cloud attachments”, whenever I would demonstrate this feature it would take anywhere from 30 seconds to 5 minutes, but there was one question that ALWAYS got asked.
“Which version is it collecting?”
At the time, of course, I would go on to describe how the tool was simply recognizing a link in the Teams chat message, or email, to the M365 environment, following the link, and collecting what it found at the link today. If a document was shared in the message 6 months ago or longer, it was entirely possible that the document they were discussing in those messages has been edited dozens of times. It might not even resemble the document that was shared at the time.
This question came up often enough that, eventually, Microsoft developed some new features that would enable customers to collect the document as it existed when it was shared. Alas, getting the environment properly set up to handle this feature is not so simple.
Actually, let me take that back. It is pretty simple, but it requires some collaboration between various roles.
Think of it this way. My eDiscovery team would like to collect the version of the document that was shared 6 months ago, as opposed to the document that currently sits in my M365 environment that has been edited numerous times. In order to do that, the environment has to be set up to retain a copy of the document when it is shared. That’s a Records Management function.
And so the solution to this customer complaint is going to involve setting up a retention policy for documents that are shared as cloud attachments in Teams, Outlook, or Viva Engage (formerly Yammer).
This is a classic example of the interplay between various tools and functions in the M365 environment. What starts out as a legal request for eDiscovery quickly turns into a Records Management requirement that the team may be wholly unaware of. You’ll see this as a recurring theme in my newsletter. This feature also touches on another recurring theme - this all requires an e5 license. e3 customers will not be able to retain or collect the shared version of a document.
Rather than take up space in this newsletter to describe how to set up an auto-labeling policy for cloud attachments, I’ll refer you over to their documentation - https://learn.microsoft.com/en-us/microsoft-365/compliance/apply-retention-labels-automatically?view=o365-worldwide#auto-apply-labels-to-cloud-attachments
What I want to focus on is what happens when this policy is implemented when it’s time for me to collect the messages that were sent with the cloud attachments in Purview eDiscovery Premium and what you’ll want to be thinking about as you look at implementing this feature.
In my example, I have configured the policy to apply prior to sending a Teams message.
The document in question has been edited a few times since it was shared over the course of about 24 hours.
When we run a collection in Premium eDiscovery targeting my mailbox and choosing the default option to “Collect cloud attachments”, the eDiscovery tool will take advantage of that auto-labeling policy and find the labeled version as well as the current version.
As Microsoft’s documentation mentions, the older one has SHAREPOINT\system as the author and the date matches the last time it was modified before being shared. It also has a GUID for a title, while the current version has the correct document title.
The metadata will also make it clear that this version is coming from the Preservation Hold Library:
What we see is the evidence of that document having a label applied at the time it was shared and that label policy setting a retention period that caused this version to be sent to the Preservation Hold Library. (Note that subsequent edits were not saved in the PHL because they were not shared. Had one, or more, of those been shared they would be the version that was collected with the message they were shared in, but not in this message.)
This is going to be the final thing we need to consider - training our document reviewers to recognize when this is happening and which version is which.
Why do I say it’s the final thing we need to consider? Because there’s a long list of things we need to consider before we even start this auto-labeling policy. In no particular order of importance, we also need to consider:
Do we feel like this is necessary, legally?
This wouldn’t be for me to say, but like many clients I’ve worked with, there is a desire to have this feature act similarly to what we have grown accustomed to with documents that are actually attached to emails. Your legal team may decide this is the route to take.
In light of the Noom decision last year, your legal team might not feel this is necessary. It would seem courts are not exactly settled on the best approach going forward, so I’d expect not everyone will be making the same decision with their M365 data.
We should also at this point make note of the fact that this only works going forward. If you’ve been in Teams and using cloud attachments for years without this feature, those cloud attachments have not been labeled and preserved. This could sway the decision.
The retention period for cloud attachments.
Microsoft recommends matching the retention for the “parent” messages but doesn’t acknowledge that for many organizations there may be wildly different retention periods for email vs. Teams 1 on 1 chats, versus channel posts. This may require a couple of different auto-labeling policies for locations, but the reality is Teams chats and emails both use OneDrive to store cloud attachments so you’ll have to choose one. Most likely I think many would match the longer period of the two to ensure the availability of the version as shared for all.
We probably want to take a look at our overall retention strategy as well, and how this might fit in. Remember that if we have a 7-year retention policy for all SharePoint and OneDrive sites, the auto-labeling policy may set a shorter one for cloud attachments, but it would not override the longer retention period.
Where should this apply?
Do we apply this to everyone? Or only our higher litigation risk custodians?
Do we apply this broadly to all SharePoint locations?
What are our preservation and production requirements?
This is going to also be a big deciding factor in how you might roll this out. What have you promised to produce in an ESI protocol? Do your existing protocols need to be updated?
This is especially true when it comes to which version you’ll produce, the shared version, the current version, or both. What is your legal team’s thinking on this?
How do we adapt our eDiscovery processes to account for the extra documents and extra complications? You’re talking about double the number of attachments for many of your messaging platforms. You’re talking about the possibility of having two versions of a document both shown as attachments that may be years apart in age. How do you plan to handle that?
Lastly, take a really good look at that MS documentation again, especially the section where it talks about the delay in a label being available and the auto-labeling policy activating. This is one of those tests that may take a few days as you await the policy to become active. And, regardless of what your teams decide, you want to test. Always test.
And then retest, frequently. Just to make sure nothing changes even when you are paying close attention to the message center for potential changes. Things have been known to change outside of what is communicated in the past.
What have your legal teams decided to do with cloud attachments? I’d love to hear about your experience in the comments.