Public Folder Migration to Exchange Online (500k Folders) Part 10— Post-Migration Issues (Access Denied Deleting)
Quick Jump Guide
Part 1 — Preparing for Migration (1/2)
Part 2 — Preparing for Migration (2/2)
Part 3 — Starting the Migration Request
Part 4 — Monitoring and Fixing the Sync (1/3)
Part 5 — Monitoring and Fixing the Sync (2/3)
Part 6 — Monitoring and Fixing the Sync (3/3)
Part 7 — Completing the Batch
Part 8 — Testing & Unlocking Public Folders
Part 9 — Post-Migration Issues (Hierarchy Update)
Part 10 — Post-Migration Issues (Access Denied Deleting)
Part 11 — Post-Migration Issues (Add/Remove Permissions)
Part 12 — Decommissioning on-premises Public Folders
Part 13 — Troubleshooting Hierarchy Issues
Continuing on with our post-migration issues, we have run across a new issue where all users are unable to delete any email or folders from Public Folders. We also ran into this problem when we were trying to re-hydrate all Enterprise Vault archived emails (in our case we use SimplyMigrate). The issue is that because we can’t delete the EV pointer file, the email is restored over and over until it hits the pre-configured retry limit. This results in a bloated mailbox.
After investigation, all which had mixed results, I finally opened a case with Microsoft Premier. The answer came back very quickly, and it wasn’t one that I liked. It appears that this is a very common issue when migrating from legacy Public Folders (Exchange 2007/2010).
The Access Control List (ACL) for each Public Folder needs to be updated to use the equivalent Modern Public Folders ACLs. The only way to fix this is to remove and reapply all permissions for all folders. This is a daunting task for a migration of nearly 500k folders.
We actually were suffering from two issues, but the second one would fix itself within a month or two, and it’s caused by Outlook not updating the cached files on the users machines. Updates will trickle down however because of our size, this will take longer then expected.
A workaround is to force an Outlook update by adding in the ExcludeLastKnownGoodURL registry key, information found here.
As I said, this won’t fix the main issue. You can verify which issue you have by trying to delete the emails from OWA, if you can, you have the above issue. If not then you have the permission issue that I’ll now explain how to fix…
A simple test to confirm whether you are affected by the permissions issue, is it simply remove your permissions on one folder and reapply them. If it works afterwards, you are affected.
I wrote the below script to fix ours. You may look at this and think it’s very long, and it is. The reason for this is that I have to work around Microsoft’s throttling and timeouts… Therefore you’ll notice that every 100 folders I remove the O365 session and reconnect it, and I also have checks in there to detect if the session becomes disconnected, if so it’ll reconnect and carry on.
Line 1 and 2 are my script I use to connect to Exchange Online, so I suggest you link that to your script you use to connect to Exchange Online, as I invoke that script a number of times.
19/07/2018 - I’ve updated this script a few times to catch O365 connection issues. Recent updates include:
- Amended to use Functions. This means any failures will automatically retry
- Hierarchy errors (so far three different errors have been caught)
- More increased session checks and reconnection
- Improved logging
On speaking to Microsoft about this very issue, they said it was caused the legacy Exchange migrations and it won’t be effected if you do a Modern Public Folder migration to Exchange Online. This I guess we’ll have to wait and see…
What I have discovered and what I think the issue is, from running my script it seems the folders suffering from this issue are the folders that had disabled (or leaver accounts if you missed any during the cleanup). Disabled accounts will still exist in AD and are synced to Azure, however between the migration starting and cutover they have been deleted.
If you look in the ACLs you will see the user listed, and it still shows as a valid user — not the NT USER: xxxxx. So Azure believes the account it still valid when in fact the account no longer exists. It seems that every folder that has one of those users, is effected. As our Public Folder tree has hundreds and hundreds of subfolders, one user is in loads of folders.
Fun times ahead…
