New Version of ExFolders Fixes Non-Canonical ACLs

When I wrote ExFolders, I thought the non-canonical Exchange ACL problems were permanently behind us in Exchange 2010. For this reason, ExFolders did not include any functionality to deal with non-canonical ACLs. It turns out I was overly optimistic.

In the last few weeks I’ve seen a couple of cases where customers ended up with non-canonical ACLs on public folders in Exchange 2010. They were seeing events like this:

Log Name: Application
Source: MSExchangeIS
Event ID: 9775
Task Category: General
Level: Warning
Description:
The mailbox '' contains a folder 'My Public Folder' with a security descriptor that violates the canonical format.

Trying to modify the permissions with Add-PublicFolderClientPermission would result in this error:

MapiExceptionNonCanonicalACL: Unable to modify table. (hr=0x80004005, ec=2409)

Each affected environment only had one folder in this state, so it does not appear to be a widespread problem, such as when something scanned the M: drive back in the Exchange 2000 days.

Even so, customers need a way to fix these problems. Since PFDAVAdmin fixed this for older versions of Exchange, it made sense to include this functionality in ExFolders for Exchange 2010.

Note, however, that what I’ve added to ExFolders is very different from the “Fix Folder DACLs” option in PFDAVAdmin. “Fix Folder DACLs” would run through your whole folder hierarchy looking for all kinds of problems and adjusting the DACL portion of the ACL.

What I’ve added in the October 20th, 2011 release of ExFolders for 2010 Sp1 is something much more limited in scope. When you right-click on a folder, you’ll see a “Clear Permissions” option. The previous build actually had this option as well, but it would not work on non-canonical ACLs. In this latest version, the “Clear Permissions” option accesses the raw security descriptor (similar to what PFDAVAdmin used to do) so it can clear it even when it’s non-canonical. You can use this to set one specific folder back into a good state and then manually set the permissions to whatever they should be.

This will be good enough to address these one-off non-canonical ACLs. I don’t expect we’ll be seeing widespread problems with this, but I’ll be keeping an eye on it. Hopefully there will be no need to introduce a bulk folder ACL fix again.