Folder Permission Migration Troubleshooting in Office 365

1. Common Causes of Folder Permission Migration Issues

   1. The destination recipient cannot be resolved

   Each permission entry refers to a user or group. If that principal is absent, duplicated, renamed, or not fully provisioned in the destination, Exchange cannot apply the entry. Check the intended target by primary SMTP address or user principal name rather than relying on the display name alone.

   • The delegated user or shared mailbox has not been created.
   • A mail-enabled security group or contact is missing.
   • The source and target addresses differ and no correct mapping is available.
   • A recently provisioned object is not yet visible to Exchange Online.
   • The source permission refers to a deleted or obsolete principal.

   2. The destination folder is missing or has a different path

   Folder permissions attach to a folder, so the destination hierarchy must exist before the permission is written. A custom folder that was excluded, renamed, placed under another parent, or created with a different localized name can cause a folder-not-found result.

   3. The issue belongs to another permission layer

   Folder roles do not provide Full Access, Send As, or Send on Behalf. A user may be able to open a shared mailbox but still lack access to a specific folder, or may have folder access but be unable to send from the mailbox. Test each permission layer separately.

   4. Source entries are stale or incompatible

   Older Exchange environments can contain permissions for deleted accounts, unresolved security identifiers, or custom access-right combinations that do not map cleanly to a supported destination role. Record these entries before cleanup and decide whether to remove or recreate them.

   5. Public folder hierarchy or principals are incomplete

   Public folder client permissions depend on the destination public folder hierarchy and resolvable users or groups. Validate public folders separately from mailbox folders, including Default and Anonymous entries where they are in scope.

   6. Access or service limits interrupt the operation

   An account or application that can read mailbox data may still lack the access required for a particular permission operation. Temporary Exchange Online throttling or a recently provisioned mailbox can also lead to delayed or retried entries. Use the migration report to distinguish an access error from a transient service response.

2. Troubleshooting Folder Permission Migration

   1. Capture one affected example

   Start with one mailbox, folder, assigned principal, and expected access level. Record whether the problem affects a mailbox folder, mailbox-level delegation, or a public folder. This keeps unrelated permission types out of the investigation.

   2. Confirm the target user, group, and mailbox

   • Verify that the destination mailbox or shared mailbox is provisioned and accessible.
   • Confirm that the assigned user, contact, or mail-enabled security group resolves to the intended destination object.
   • Check for duplicate proxy addresses, renamed accounts, or an incorrect source-to-target mapping.
   • Allow directory and Exchange provisioning to complete before retrying a recently created object.

   3. Confirm that the destination folder exists

   Compare the source and destination path for the affected folder. Check the parent folder, nested path, folder type, and localized default-folder name. If the folder data was excluded or failed to migrate, correct that issue before retrying its permissions.

   4. Compare folder permissions with Exchange PowerShell

   In Exchange Online PowerShell, use the destination folder's actual identity to view its entries:

   Get-EXOMailboxFolderPermission -Identity "user@contoso.com:\Inbox"

   For on-premises Exchange, use:

   Get-MailboxFolderPermission -Identity "user@contoso.com:\Inbox"

   For a public folder, use:

   Get-PublicFolderClientPermission -Identity "\Finance"

   Run the corresponding command against the source and destination, then compare the principal and access-right values. Use the actual folder name in each environment, especially for localized Calendar or Inbox folders.

   5. Review the migration report at entry level

   A completed mailbox migration can still contain permission warnings. Look for the affected mailbox and folder, then record the reported principal and error. Common results include recipient not found, folder not found, access denied, unresolved identity, throttling, and timeout.

   6. Correct the dependency before retrying

   Create or map the missing recipient, migrate the missing folder, correct the job access, or remove an obsolete source entry. Retry the appropriate folder permission operation only after the dependency is visible in the destination. Review the new report instead of assuming a retry applied every entry.

   7. Test with the affected user

   Confirm that the user can open the intended folder and perform only the actions allowed by the assigned role. Test sending separately when Send As or Send on Behalf is required. Outlook may cache access information, so compare the result with Outlook on the web before changing permissions again.

3. Best Practices Before Folder Permission Migration

   • Inventory delegated folders: Export or record representative folder permissions, including Default and Anonymous entries.
   • Prepare destination principals: Provision the users, shared mailboxes, contacts, and mail-enabled security groups referenced by valid source entries.
   • Clean stale assignments: Review deleted accounts, unresolved identifiers, and obsolete delegates before migration.
   • Complete the folder hierarchy first: Include the required custom and nested folders so the destination paths exist before permissions are applied.
   • Keep permission types separate: Plan folder roles, Full Access, Send As, Send on Behalf, and public folder permissions as distinct validation items.
   • Run a representative pilot: Include a standard mailbox, a shared mailbox, nested folders, a group assignment, and a public folder when those scenarios are in scope.
   • Retain a comparison record: Save the source permission output and the initial migration report for post-migration checks.

4. Best Practices After Folder Permission Migration

   • Review warnings and skipped permission entries for every migration batch.
   • Compare source and destination permissions for high-use and sensitive folders.
   • Test access with representative users instead of relying only on an administrator account.
   • Validate shared mailbox folder access separately from Full Access and sending permissions.
   • Check public folder client permissions across representative levels of the hierarchy.
   • Document manual corrections and repeat the check after any follow-up migration.

   Avoid removing the source environment or permission inventory until the destination checks are complete and the relevant users have confirmed access.

Conclusion

Most folder permission migration problems come from an unresolved destination principal, a missing folder path, an access problem, or confusion between folder permissions and mailbox-level delegation. Check one affected folder end to end, correct the dependency shown in the report, and verify the result through PowerShell and user testing.