Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Issues with implementing SPO/ODFB Retention Policies based on Last Modified Date

Iron Contributor

Since this is a common means of implementing retention/destruction policies, I'd like to share some issues/frustrations I've had and hopefully spur some discussion.


1) The Sync Client/Windows Explorer loophole. When users upload a document to ODFB or SharePoint via the browser, the modified date (crawled property: ows_Modified, which is the property respected by retention policies, and is the one displayed in the interface in SPO/ODFB) is automatically updated to the time of upload. However, when documents are uploaded via the Sync Client in Windows Explorer, the modified date simply inherits the existing internal document modified date. This can lead to older documents being deleted immediately upon upload if the internal modified date is prior to the destruction policy date. More significantly, it is confusing to the end user to have two different retention experiences based on the method of upload. There needs to be a way to ensure the modified date is consistently applied across both methods of upload. It is not realistic to expect users to know not to upload via the Sync client.


2) Content Search and Last Modified Date. The managed property LastModifiedTime is mapped out of the box to show internal document date crawled properties instead of the ows_Modified property. In practical terms this means that searching SPO/ODFB for documents last modified more than five years ago will return many documents which in fact have a more recent ows_Modified date, and therefore it is not an accurate way to audit documents subject to destruction. If you change the mapping of the LastModifiedTime managed property it will work, but you first need to reindex every single site, including each ODFB site, in the tenant. Oddly, there is a system managed property in SharePoint search, LastModifiedTimeForRetention, which is mapped only to ows_Modified crawled property, and thus should work, but it is not recognized by Content Search in testing - searching against it returns every item in the search scope. Ideally there would be a way to search ows_modified in Content Search OOTB without resorting to a full, cumbersome reindex in order to understand documents subject to retention policies.


Would be interested to hear others' experiences and thoughts on implementing such a policy. Thanks!

0 Replies