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.
Is there a way to use the "Clear permissions" recursive on subfolders ?
No there isn't. Do you actually have an environment where there's a whole tree of folders in this state?
I've posted this to technet (after scouring and trying every solution out there) but non one can help, you're the last hope...
I'm getting a The ACL for object <user> is not in canonical order (Deny/Allow/Inherited) and will be ignored/
When I try and change the permission/send-as.
We're on Exchange 2010 sp1.
You're trying to change mailbox permissions (i.e. Add-MailboxPermission), correct? If so, I don't know of any tool for that on 2010 (you can use FixMailboxSD on 2007/2003). The easiest fix is probably export to PST, mail-disable the user, mail-enable the user, import from PST. Not fun.
Do you know how the mailbox got into this state? If you're able to reproduce it, I would love to know the steps needed to create a non-canonical mailbox ACL.
Thanks anyway Bill.
I, too, am confused as to how it became unsorted.
I'll try try to kill.re-create.
Will you make a new version of this tool for SP2 or it's fully compatible ?
The SP1 version works for SP1 and later, so there's no separate version for SP2.
I also have a single user mailbox that I am unable to modify permissions on because of a non-canonical ACL warning. I have no idea how the mailbox ACL got in that state either.
Is there a way to call the "clear permissions" bit through scripting (i.e. PowerShell).
We have a recurring problem in a hosted environment and would love to automate this!
It is possible to do this with scripting? as we have at least 10.000 folders with this issue.
Wow, do you have any idea how that happened to all those folders? I'd be very curious to know.
You can run this against a whole tree of folders, but the option is sort of hidden.
1. Go to Tools->Custom Bulk Operation.
2. Click Add.
3. Choose "Clear Folder Permissions" and click OK.
4. Leave the checkbox to "Restore previous permissions" checked, otherwise all permissions will be lost when you do this. Click OK.
5. In the Custom Bulk Operation window, click OK to start the operation.
This is dangerous, so please export the permissions first and make a backup.
How to we see this ACL table ?
mfcmapi doesn't show the proper order of ACL's in ACL Table
none of the windows ACL tools works or probably we don't know how to use those tools against PF
only cmdlet we know is get-publicfolderclientpermissions,
trying to understand how to retrieve the ACL table, in EX2013
Normally, you want to interact with folder permissions via PR_ACL_TABLE as described in support.microsoft.com/.../297493. If you use this approach, you don't have to worry about the proper order of ACEs, because Exchange handles it for you.
If you want to make things very difficult, you can use the PR_NT_SECURITY_DESCRIPTOR property. In that case, it's up to you to order the ACEs properly and make sure the other rules of Exchange canonical order are followed. This is generally a bad idea.
Both properties are exposed in MfcMapi.
I tried to use the exfolders tool to propagte the folderpermissions of a folder to all subfolders. The goal ist to give the subfolders the same rights as the main folder has. If the subfolder has additional userrights - they should be deleted. I tried with Tools | Custom Bulk Operation | Folders Permission | Replace. But that seemed to does not work.
Is there way to do this with exfolders?