This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(64, 85%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMW%3C/text%3E%3C/svg%3E)
Im doing the Exchange hybrid migration and there is 1 mailbox which giving me error of AggregateMailboxFolderConflictPermanentException. The folder that conflict is ‘Files’.
As checked, I believe this is a system folder and not visible to user. How come it will be conflict and asking me to move the files to other folder?
I used MFCMAPI to show the content tables for Files folder but nothing showing inside there as well as hidden items. I can’t proceed with the migration now for this mailbox.
Any impact if I rename the source Files to Files_Legacy and retry the migration? Or any better way to resolve this?
I have tested renaming the Files folder and migrate with a test mailbox. After migrating the mailbox I dont see a new Files folder being populated. And according to this link, seems like it serves for attachment cache purposes.
Whats the impact without this folder and how do I recreate it ?
I managed to solve the issue by changing my outlook profile to online mode, open the Files folder again in mfcmapi and found the email. Deleted it and recreated the migration batch. Thanks
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(227.2, 9%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMN%3C/text%3E%3C/svg%3E)
Hi @Marcus W
Thank you so much for contacting Microsoft Q&A Forum.
Based on your description, I understand you're facing an AggregateMailboxFolderConflictPermanentException for a single mailbox during an Exchange hybrid migration. The conflict is with the 'Files' folder, which you've correctly identified as empty using MFCMAPI.
You've encountered a known issue that occurs during hybrid migrations. Exchange Online (EXO) reserves the folder name 'Files' for its own protected, system-level folder. This folder is used internally by features like cloud attachments from OneDrive.
When the migration process tries to move a mailbox from your on-premises server that already contains a folder named 'Files', a conflict arises. The migration service cannot create or merge your source folder because the destination name is protected. As you discovered with MFCMAPI, even if your on-premises 'Files' folder is completely empty, the name collision itself is enough to trigger the error and halt the migration.
Based on my research, renaming the folder is the recommended solution. This should resolve the naming conflict and allow the migration to proceed.
-Impact Analysis
Data Integrity: Since you have mentioned the folder is empty (containing no items, hidden or otherwise), there is zero risk of data loss.
Post-Migration State: The renamed folder, 'Files_Legacy', will simply be created in the target mailbox in Exchange Online. The new, system-reserved 'Files' folder will also be present.
On-Premises System Impact: For an empty folder, the risk of affecting any on-premises processes is extremely low. It's highly unlikely that any active application or rule is targeting an empty, hidden folder.
Based on this, there is no significant impact. After renaming, please retry the migration batch for this specific user.
If you have any problems, please let me know. I will continue to support you.
If the answer is useful, please click on "Accept Answer" and kindly vote for it. If you have any further questions about this answer, please click on "Comment".
Note: Follow the steps in our documentation to enable email notifications if you would like to receive an email notification regarding this discussion.
Just to update, I've tested rename the Files to Files_Legacy and attempted to migrate the problematic mailbox again. Unfortunately, it failed with the same error message. From mailboxfolderstatistics, I can see below:
ContainerClass : IPF.Files
Flags :
TargetQuota : System
StorageQuota : 20 GB (21,474,836,480 bytes)
StorageWarningQuota : 20 GB (21,474,836,480 bytes)
ItemsInFolder : 1
DeletedItemsInFolder : 0
FolderSize : 23.04 KB (23,590 bytes)
ItemsInFolderAndSubfolders : 1
DeletedItemsInFolderAndSubfolders : 0
FolderAndSubfolderSize : 23.04 KB (23,590 bytes)
CurrentSchemaVersion : 0.174
But after I unhid the Files, in Outlook I don't see anything inside this Files folder.
Hi @Marcus W
Thank you for updating.
I understand that renaming the folder, unfortunately, did not resolve the issue and the migration failed with the same error. I am continuing to look for more suitable directions based on this new feedback.
The output you provided is very insightful. Please try the following methods to address this hidden item.
1.Delete the Folder (Preferred if Truly Empty): Since MFCMAPI shows no contents, delete it entirely via MFCMAPI (right-click > Delete Folder, choosing "Hard Delete" to ensure it's gone).
2.Export and Reimport (If You Suspect Hidden Data): Though you've checked, for extra caution: Export the mailbox (or just the 'Files' folder) to a PST via Outlook or New-MailboxExportRequest in on-prem PowerShell. Delete/rename the folder, migrate, then import any exported data (if any) into a new non-conflicting folder in EXO.
3.Check for Folder Type Mismatch: In MFCMAPI, inspect the folder's PR_CONTAINER_CLASS property. If it's IPF.Files (system type) instead of IPF.Note (standard mail folder), change it to IPF.Note after renaming. This prevents hiding issues post-migration, as EXO treats IPF.Files specially. Tools like MFCMAPI allow editing this property.
4.General Troubleshooting Steps Before Retrying: Run Get-MailboxFolderStatistics -Identity <user> -FolderScope All | Where {$_.Name -eq "Files"} in on-prem Exchange Management Shell to confirm details. Ensure no other reserved folder conflicts. Validate the migration endpoint and hybrid config via the Hybrid Configuration Wizard or Test-MigrationServerAvailability. If the error persists, capture full logs from the migration batch in the EXO admin center and check for sub-errors.
Thank you for your patience.
Hi @Marcus W
That's wonderful that you were able to solve this issue. If you found my answer to be at least partially helpful, I hope you will consider marking the response as helpful. This greatly benefits others who may be facing the same problem.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 46%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EER%3C/text%3E%3C/svg%3E)
I have the same issue with 2 accounts. Used mfcmapi to rename the files folder. Checked on premise through exchange powershell and files folder is no longer there.....yet I try to rerun the migration same error. I read a forum that running outlook.exe /resetfolders is a option that may resolve this. Just not sure how/why the migration is still complaining about the folder after it has been renamed...Anyone out there have any recommendations or guidance?