none
Public folder Hierarchy not synchronizing to secondary RRS feed

  • Question

  • Hello,

    We have migrated from Exchange 2007 to Exchange 2013 CU1

    All mailboxes have been migrated including all public folders. Public folders have been split in several mailboxes.
    The problem we are experiencing is that the master contains the correct hierarchy and the secondaries do not have any hierarchy. The public folders simply show up as individual folders without hierarchy for users that have DefaultPublicFolderMailbox set to anything else than the master.

    I have verified that there is no hierarchy with MFCMAPI (it throws an error).
    When I try the following: Update-PublicFolderMailbox -InvokeSynchronizer:$true" I get the following error which doesn't tell me where the error is:

    Failed to sync public folder hierarchy. Cannot set folder security descriptor with non canonical ACL. Error information
    : (A;S-1-5-21-xxxxxxxxxxx-500;Folder;1FC9BF;UserAllowFull;User)(A;S-1-5-21-xxxxxxxxxxxxx-500;Message;1F0FBF;UserAllowFull;User)
    Stack trace:
       at Microsoft.Exchange.Data.Storage.AclModifyTable.BuildAclTableBlob(StoreSession session, RawSecurityDescriptor secu
    rityDescriptor, RawSecurityDescriptor freeBusySecurityDescriptor)
       at Microsoft.Exchange.RpcClientAccess.Handler.FolderSecurityDescriptorConversion.ConvertValueFromClient(StoreSession
     session, ICorePropertyBag propertyBag, Object propertyValue)
       at Microsoft.Exchange.RpcClientAccess.Handler.PropertyConversion.TryConvertPropertyValueFromClient(StoreSession sess
    ion, ICorePropertyBag propertyBag, PropertyValue& propertyValue)
       at Microsoft.Exchange.RpcClientAccess.Handler.PropertyConverter.ConvertPropertyValueFromClient(StoreSession session,
     ICorePropertyBag propertyBag, PropertyValue& propertyValue)
       at Microsoft.Exchange.RpcClientAccess.FastTransfer.Handler.CorePropertyBagAdaptor.SetProperty(PropertyValue property
    Value)
       at Microsoft.Exchange.RpcClientAccess.FastTransfer.Handler.FolderPropertyBagAdaptor.SetProperty(PropertyValue proper
    tyValue)
       at Microsoft.Exchange.RpcClientAccess.FastTransfer.Parser.FastTransferPropertyValue.UploadImpl.<DeserializeVariableS
    izeProperty_CreateDisplayClass>d__20.MoveNext()
       at Microsoft.Exchange.RpcClientAccess.FastTransfer.FastTransferStateMachine.Step()
       at Microsoft.Exchange.RpcClientAccess.FastTransfer.Parser.FastTransferContext`1.Process(TDataInterface dataInterface
    )
       at Microsoft.Exchange.RpcClientAccess.FastTransfer.Parser.FastTransferUploadContext.Process(IFastTransferReader data
    Interface)
       at Microsoft.Exchange.RpcClientAccess.FastTransfer.Parser.FastTransferUploadContext.PutNextBuffer(ArraySegment`1 buf
    fer)
       at Microsoft.Exchange.MailboxReplicationService.StorageFxProxy`1.Microsoft.Mapi.IMapiFxProxy.ProcessRequest(FxOpcode
    s opCode, Byte[] data)
       at Microsoft.Exchange.MailboxReplicationService.FxProxyBudgetWrapper.Microsoft.Mapi.IMapiFxProxy.ProcessRequest(FxOp
    codes opCode, Byte[] request)
       at Microsoft.Exchange.MailboxReplicationService.ExecutionContext.Execute(Action operation)
       at Microsoft.Exchange.MailboxReplicationService.FxProxyWrapper.Microsoft.Mapi.IMapiFxProxy.ProcessRequest(FxOpcodes
    opCode, Byte[] request)
       at Microsoft.Exchange.MailboxReplicationService.BufferedReceiver.Microsoft.Exchange.MailboxReplicationService.IDataI
    mport.SendMessage(IDataMessage message)
       at Microsoft.Exchange.MailboxReplicationService.RemoteDataExport.ExportRoutine(IMailboxReplicationProxyService mrsPr
    oxy, Int64 dataExportHandle, IDataImport destProxy, DataExportBatch firstBatch, Boolean useCompression)
       at Microsoft.Exchange.MailboxReplicationService.RemoteSourceFolder.Microsoft.Exchange.MailboxReplicationService.ISou
    rceFolder.CopyTo(IFxProxy destFxProxy, CopyPropertiesFlags flags, PropTag[] excludeTags)
       at Microsoft.Exchange.Servicelets.JobQueue.PublicFolder.PublicFolderSynchronizer.CoreSyncFolderUpdate(PublicFolderRe
    c sourceFolderRec)
       at Microsoft.Exchange.Servicelets.JobQueue.PublicFolder.PublicFolderSynchronizer.CoreSyncFolderUpdate(Byte[] folderI
    d, PublicFolderRec& sourceFolderRec)
       at Microsoft.Exchange.Servicelets.JobQueue.PublicFolder.PublicFolderSynchronizer.<>c__DisplayClass7.<CreateWlmAwareE
    xecutor>b__5(TimeSpan delay)
       at Microsoft.Exchange.Servicelets.JobQueue.PublicFolder.WlmAwareBatchExecutor.<Execute>b__1()
       at Microsoft.Exchange.MailboxReplicationService.CommonUtils.ProcessKnownExceptions(Action actionDelegate, FailureDel
    egate failureDelegate)
        + CategoryInfo          : NotSpecified: (Microsoft.Excha...derSyncJobState:PublicFolderSyncJobState) [Update-Publi
       cFolderMailbox], PublicFolderSyncPermanentException
        + FullyQualifiedErrorId : FEA9409C,Microsoft.Exchange.Management.MapiTasks.UpdatePublicFolderMailbox
        + PSComputerName        : servername.domain.local
    There were no errors about ACLs during migration.

    I'm not sure how I can proceed to fix this since there is no tool for Exchange 2013 to manage public folders.
    The only thing I can do is set the master mailbox as default for all users.

    Has anyone else come up with this issue?

    For me it would be ok if it was possible to export all permissions (without errors), remove all permissions, and then restore them.

    Regards,

    Gen


    • Edited by Geno D Wednesday, July 10, 2013 12:03 PM
    Wednesday, July 10, 2013 11:17 AM

Answers

  • Hi Gen,

    You have ran over a known issue where, in some situations, permissions are saved to the folder in an order different from the expected (thus the complaint about non-canonical form).

    In order to work it around before a fix becomes available, you can reset all permissions in the master hierarchy by running the following Powershell script:

    $allPublicFolders = @(Get-PublicFolder -Recurse) + @(Get-PublicFolder -Recurse \NON_IPM_SUBTREE\DUMPSTER_ROOT);

    foreach ($publicFolder in $allPublicFolders)
    {
        $allPermissions = Get-PublicFolderClientPermission $publicFolder;
        foreach ($permission in $allPermissions)
        {
            Remove-PublicFolderClientPermission $publicFolder  -User $permission.User -Confirm:$False;
            Add-PublicFolderClientPermission $publicFolder  -User $permission.User -AccessRights $permission.AccessRights;
        }
    }

    After running that, please try "Update-PublicFolderMailbox -InvokeSynchronizer:$true" again to force synchronization if you don't want to wait for the replication schedule.

    Another way for you to find out if hierarchy is present on a secondary mailbox is to use -Mailbox parameter when you run Get-PublicFolder.

    Please let us know if that fixes your issue.

    Fred

    • Marked as answer by Geno D Friday, July 19, 2013 9:12 AM
    Wednesday, July 10, 2013 5:28 PM
  • Gen,

    Would you mind pasting the entire error message from the SyncInfo? The non-canonical ACL should be right there. If it is not, look at the full log file on Logging\PublicFolder\Microsoft.Exchange.ServiceHost_PublicFolderSyncLog<datestamp>.txt and you'll find it.

    And before trying that, would you mind running the Get/Set ClientPermission again for that specific folder, just to make sure it was really processed by the script?

    To answer your question, you can determine the dumpster folder from the regular folder and vice-versa:

    PS C:\Users\Administrator> get-publicfolder \Foo | fl *entry*

    EntryId         : 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EF90000
    DumpsterEntryId : 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EFA0000

    PS C:\Users\Administrator> get-publicfolder 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EFA0000 | fl *entry*

    EntryId         : 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EFA0000
    -->DumpsterEntryId : 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EF90000

    PS C:\Users\Administrator> Get-PublicFolder 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EF90000 | fl name

    Name : Foo

    • Marked as answer by Geno D Friday, July 19, 2013 9:12 AM
    Tuesday, July 16, 2013 6:53 PM

All replies

  • Hi Gen,

    You have ran over a known issue where, in some situations, permissions are saved to the folder in an order different from the expected (thus the complaint about non-canonical form).

    In order to work it around before a fix becomes available, you can reset all permissions in the master hierarchy by running the following Powershell script:

    $allPublicFolders = @(Get-PublicFolder -Recurse) + @(Get-PublicFolder -Recurse \NON_IPM_SUBTREE\DUMPSTER_ROOT);

    foreach ($publicFolder in $allPublicFolders)
    {
        $allPermissions = Get-PublicFolderClientPermission $publicFolder;
        foreach ($permission in $allPermissions)
        {
            Remove-PublicFolderClientPermission $publicFolder  -User $permission.User -Confirm:$False;
            Add-PublicFolderClientPermission $publicFolder  -User $permission.User -AccessRights $permission.AccessRights;
        }
    }

    After running that, please try "Update-PublicFolderMailbox -InvokeSynchronizer:$true" again to force synchronization if you don't want to wait for the replication schedule.

    Another way for you to find out if hierarchy is present on a secondary mailbox is to use -Mailbox parameter when you run Get-PublicFolder.

    Please let us know if that fixes your issue.

    Fred

    • Marked as answer by Geno D Friday, July 19, 2013 9:12 AM
    Wednesday, July 10, 2013 5:28 PM
  • Fred,

    Thank you for your quick reply. I haven't gotten back to you because the script starts to slow down after about 1000 permissions.
    There are about 9000 public folders and around 6 permissions each.

    I will export the permissions to multiple files and run it that way. I will get back to you in a couple of days.

    It has done about 2000 folders from "\" but none from the dumpster root. If I check the syncinfo it still says 0 synchronized.

    Regards,

    Hakan

    Friday, July 12, 2013 2:58 PM
  • Hello Fred,

    I had fed the script all the public folders. But I still get the same error message.

    All I can make from the syncinfo is where it fails.

    2013-07-14T02:45:50.572Z,,Verbose,,17862861-0163-4587-85ac-132407e7a49c,00000000DE85
    6BE7637BAA42BEAAF2F682735F6801001075372D287BA745B2DA843245F85CF90000000000080000 is
    updated,,c9b3006c-8b87-45be-be5e-408f3e570b57
    2013-07-14T02:46:23.832Z,,Error,,17862861-0163-4587-85ac-132407e7a49c,"[ErrorContext
    :UPDATING:00000000DE856BE7637BAA42BEAAF2F682735F680100E2292BA2EF997C4E91D8EC0339FD31
    2900000076A70B0000] [Message:Cannot set folder security descriptor with non canonica
    l ACL. Error information: 

    When I look for the string "00000000DE856BE7637BAA42BEAAF2F682735F680100E2292BA2EF997C4E91D8EC0339FD312900000076A70B0000" in my PF export file I come to this: "\NON_IPM_SUBTREE\DUMPSTER_ROOT\60c56831-e05f-47f5-988e-de0438947d52"

    When I request the permissions for this I only come up to:

    FolderName           User                 AccessRights
    ----------           ----                 ------------
    60c56831-e05f-47f... Default              {Author}
    60c56831-e05f-47f... Anonymous            {None}

    Does this PF in the dumpster link to an existing PF where the permissions issue occurs?
    I wish there was a tool like EXFolders right now..

    Any other suggestions?

    Regards,
    Gen

    Sunday, July 14, 2013 3:13 AM
  • Gen,

    Would you mind pasting the entire error message from the SyncInfo? The non-canonical ACL should be right there. If it is not, look at the full log file on Logging\PublicFolder\Microsoft.Exchange.ServiceHost_PublicFolderSyncLog<datestamp>.txt and you'll find it.

    And before trying that, would you mind running the Get/Set ClientPermission again for that specific folder, just to make sure it was really processed by the script?

    To answer your question, you can determine the dumpster folder from the regular folder and vice-versa:

    PS C:\Users\Administrator> get-publicfolder \Foo | fl *entry*

    EntryId         : 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EF90000
    DumpsterEntryId : 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EFA0000

    PS C:\Users\Administrator> get-publicfolder 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EFA0000 | fl *entry*

    EntryId         : 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EFA0000
    -->DumpsterEntryId : 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EF90000

    PS C:\Users\Administrator> Get-PublicFolder 00000000FD4B076B565FE64B915914D1FFB6C75501007D6BAD0AAF15A14EAE42FD4D7411785D000002088EF90000 | fl name

    Name : Foo

    • Marked as answer by Geno D Friday, July 19, 2013 9:12 AM
    Tuesday, July 16, 2013 6:53 PM
  • Fred, I'm sorry I didn't get back sooner. Somehow I didn't get alerted about your reply.

    Anyway. I did what you asked and searched for the PF with

    Get-PublicFolder 00000000DE856BE7637BAA42BEAAF2F682735F680100E2292BA2EF9974E91D8EC0339FD312900000076A70B0000 | fl *entry*
    
    EntryId         : 00000000DE856BE7637BAA42BEAAF2F682735F680100E2292BA2EF997C4E91D8EC0339FD312900000076A70B0000
    DumpsterEntryId : 00000000DE856BE7637BAA42BEAAF2F682735F680100E2292BA2EF997C4E91D8EC0339FD312900000076A70C0000

    And then:

    [PS] C:\Migration>Get-PublicFolder 00000000DE856BE7637BAA42BEAAF2F682735F680100E2292BA2EF9974E91D8EC0339FD312900000076A70B0000
    Name                                                        Parent Path
    ----                                                        -----------
    Test                                                        \NON_IPM_SUBTREE\AsyncDeleteState

    I have no idea what that folder is doing there. But it was skipped since we only included the dumpster from NON_IPM_SUBTREE.
    After I knew what folder was the culprit. I ran your script again solely on this folder and ran the Update-PublicFolderMailbox -InvokeSynchronizer on all the secondary hierarchy mailboxes.
    And then this happened: LastSuccessfulSyncTime           : 19/07/2013 10:16:30!

    This is what it looked like after the first mailbox sync.

    NumberOfBat NumberOfFol BatchSize   NumberOfFol DisplayName LastSyncFai LastAttempt LastSuccess LastFailedS NumberofAtt
    chesExecute dersToBeSyn             dersSynced              lure        edSyncTime  fulSyncTime yncTime     emptsAfterL
    d           ced                                                                                             astSuccess
    ----------- ----------- ---------   ----------- ----------- ----------- ----------- ----------- ----------- -----------
                                                    Public F...
    20          9947        500         9947        Public F... [Message... 19/07/20... 19/07/20... 19/07/20... 0
    0           9947        500         0           Public F... [Message... 19/07/20...             19/07/20... 1335
    0           9947        500         0           Public F... [Message... 19/07/20...             19/07/20... 1414
    0           9947        500         0           Public F... [Message... 19/07/20...             19/07/20... 144
    0           9947        500         0           Public F... [Message... 19/07/20...             19/07/20... 771
    0           9947        500         0           Public F... [Message... 19/07/20...             19/07/20... 474

    And this is what I have now:

    NumberOfBat NumberOfFol BatchSize   NumberOfFol DisplayName LastSyncFai LastAttempt LastSuccess LastFailedS NumberofAtt
    chesExecute dersToBeSyn             dersSynced              lure        edSyncTime  fulSyncTime yncTime     emptsAfterL
    d           ced                                                                                             astSuccess
    ----------- ----------- ---------   ----------- ----------- ----------- ----------- ----------- ----------- -----------
                                                    Public F...
    20          9900        500         9900        Public F... [Message... 19/07/20... 19/07/20... 19/07/20... 0
    20          9947        500         9947        Public F... [Message... 19/07/20... 19/07/20... 19/07/20... 0
    20          9947        500         9947        Public F... [Message... 19/07/20... 19/07/20... 19/07/20... 0
    20          9947        500         9947        Public F... [Message... 19/07/20... 19/07/20... 19/07/20... 0
    20          9947        500         9947        Public F... [Message... 19/07/20... 19/07/20... 19/07/20... 0
    20          9947        500         9947        Public F... [Message... 19/07/20... 19/07/20... 19/07/20... 0

    No errors.
    I didn't check why that PF appeared there, but that's ok.
    Thank you very much Fred!

    Regards,

    Gen


    • Edited by Geno D Friday, July 19, 2013 9:13 AM Update
    Friday, July 19, 2013 9:11 AM
  • That's cool, glad to hear that you were able to fix the synchronization issue.

    Thanks for letting me know about the AsyncDeleteState, I thought that folder didn't exist anymore... I'll have to circle this information with the experts on my side before giving you more details, but that will be a good addition to the permission repair script.

    Friday, July 19, 2013 5:35 PM
  • That's cool, glad to hear that you were able to fix the synchronization issue.

    Thanks for letting me know about the AsyncDeleteState, I thought that folder didn't exist anymore... I'll have to circle this information with the experts on my side before giving you more details, but that will be a good addition to the permission repair script.

    Ok, here is the confirmed information about AsyncDeleteState: it is not actively used anymore, but still supported.

    To give you more details, AsyncDeleteState was folder created in RTM to support asynchronous folder delete, so to make the client calls to return quickly, even when you are removing a folder with thousands of items in it. If the call was synchronous, you would have to wait until every single item was purged from the deleted folder before returning control to the caller and that would be a bad user experience. The implementation at that time was that a folder removal was translated into moving that folder under AsyncDeleteState and returning immediately. A background task would come back later and clean up AsyncDeleteState periodically.

    After CU1, with the support of client-initiated (Outlook) folder recovery, deleted folders started to be moved directly under their parent's dumpster folder instead. AsyncDeleteState isn't used anymore, although the cleanup logic was preserved for backwards compatibility.

    Friday, July 19, 2013 6:10 PM