Why public folder compliance gets no respect

Microsoft’s July 2 announcement of a “compliance toolset” for public folders appears to have fallen flat in terms of the excitement generated in the Exchange community.  At least, I never hear anyone talking about it or receive any questions about why Microsoft’s compliance toolset for the cockroaches of Exchange is so limited. Let’s debate why this might be so.

Compliance means different things to different people. In terms of Exchange, I think a fair definition is that compliance functionality helps companies ensure that users retain or preserve information needed for the business while removing information that is not required. Compliance also extends into the realm of data handling to ensure that sensitive information is handled properly. Finally, search functionality enables information to be recovered when required.

Microsoft has invested heavily to build compliance technology into Exchange since the first iteration of Managed Folders appeared in Exchange 2007. That effort crashed and burned (like so many first runs at a problem), but more success has since been experienced with:

Office includes even more compliance functionality through its Compliance Center, including compliance searches (faster and more scalable than Exchange eDiscovery), preservation policies, and supervisory review. Best of all, Microsoft is building compliance across all of Office 365, Exchange is very well covered at this point and SharePoint and OneDrive for Business are improving, but there’s still room to improve in areas like Office 365 Groups, Yammer, and the Video Portal.

Public Folders have been around for 20 years now and, in some companies, have accumulated a great deal of information. Although many would like to move the information out of public folders, there isn’t a great choice in terms of destinations. We’ve been down the road of looking at SharePoint as a replacement and that option crashed into the rocks many moons ago. Site mailboxes were part of the SharePoint vision but withered on the vine because of customer disinterest and the advent of better technology in Office 365 Groups (but only in the cloud). However, although moving public folders to Office 365 Groups seems like a nice option, the tooling for such a migration doesn’t exist today.

For many reasons, Public Folders have remained stuck in their own time warp for many years. Even the modern version, which delivered the benefit of moving from separate databases and an obscure replication model to public folder mailboxes and reliable high availability, didn’t do much for functionality. In fact, the hiatus caused by the poor performance of the initial modern public folder architecture set things bad a tad because all available attention turned to fix performance and left no time or interest available to update features.

In that light, we should be happy that the compliance toolset for public folders enables public folders to be included in eDiscovery searches and now support in-place holds. The hold process works in much the same way as when items are held in user mailboxes and any attempt to remove items from an on-hold public folder are copied and retained in such a way that they remain indexed and discoverable.

What has been delivered is better than nothing, even if public folders remain aloof from DLP and don’t support retention policies either. It would have been nice to see the old-style item age-out mechanism used since the year dot replaced by being able to assign retention policies to public folders. Perhaps by applying a default tag to the entire public folder hierarchy and personal tags to individual folders or folder trees. In any case, we can’t. And by the way, none of this stuff works if you still run the old-style public folders with on-premises servers. You have to migrate to the modern variety or use Exchange Online, which only knows about modern public folders.

Behind the scenes, the New-MailboxSearch (for Exchange 2016) and New-ComplianceSearch (for Exchange Online) cmdlets support the PublicFolderSources parameter to allow administrators to define whether public folder should be included in the set of sources scanned by a search. The value passed is “All” to include public folders. In other words, every search that includes public folders has to scan all folders, which might not be a good thing in large deployments. However, the indications are that Microsoft will allow more granular searches in the future. Another parameter (PublicFolderLocationExclusion) is supported by New-Compliance Search but is marked for internal Microsoft use only.

I suspect that the news about the public folder compliance toolset has not yet penetrated the consciousness of Exchange administrators. Maybe it’s because they really just want to get rid of public folders or that they’re busy migrating from old to modern and will think about compliance later. Or perhaps it’s that public folders, compliant or not, simply get no respect. It’s always been that way.

Follow Tony @12Knocksinna