I'm seeing a variation on the original theme. I used the migration tool to move a machine from one domain to another and to migrate one user. The user cannot launch Outlook, because access is denied to the .ost file. Disabling ADAL might fix it for others, but isn't an option (nor a good idea). I haven't tried renaming the broker folder in this instance, because I don't think that is the issue, although I have used that fix on another machine that had a TPM issue. But what I noticed in this users's case is that the path to the Outlook.ost file looking something like this:

"\\?\C:\Users\userid\...."

A profile with a working data file path does not have the "\\?\" and I'm wondering if there is some sort of escape code that is getting added to paths via the migration tool?

Perhaps not coincidentally, I have seen similar access denied issues post-migration using the User Profile Transfer tool. The message there is in the Application event log:

ShellExperienceHost (9772,P,98) TILEREPOSITORYSID-Removed: An attempt to open the device with name "\\.\C:" containing "C:\" failed with system error 5 (0x00000005): "Access is denied. ". The operation will fail with error -1032 (0xfffffbf8).

Having the same issues. New profile works fine. Ran Office manual uninstall tool and reinstalled, cleared keys via ospp.vbs file. We don't show an ADAL registry entry. This is a huge issue as we have 100+ users that will need to be migrated. Get it together Microsoft!

So I finally figured this out. Such a PITA. The reason I couldn't log out of any office app had to do with a previously unknown O365 install. I noticed that none of the New O365 installs were registering on the O365 portal. IE, when I looked at the "Office Installs" for each user they said no installations or whatever. It was odd because they appeared to activate but it said no installations.

I only had to do steps 1 and 3. I did not do anything in the registry. After all this I could then log out and stay logged out of all Office apps. I did a manual migration and it worked as expected. I also confirmed with Microsoft that this is the recommended method to fix the issue. Didn't want to break anything else.

Now I need to figure out how to map the local profile names to new domain profile names while doing an scripted migration. I tried but it wasn't working.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot delete your posts in this forumYou cannot edit your posts in this forumYou cannot create polls in this forumYou cannot vote in polls in this forum