Skip to main content

Microsoft

Access Denied on the Portal and Mailbox is inaccessible after migration to Office 365

We’ve migrated many users from an external messaging system, like Lotus Notes or GroupWise to Office 365.On one of our migrations, we ran in to an issue with a migrated user.When this user tried to logon with their AD credentials (ADFS deployed), they would constantly be prompted for their logon credentials.When we logged on to the Office 365 portal, we immediately received Access Denied for that user.

Initially we thought it was just a bad license assignment.So we removed all of the licenses for this user and reassigned the license… Unfortunately, this was not the fix.The user experienced the same issues, no matter what service or how they tried to logon.We even tried to remove/ add the license, numerous times.

We then tried to contact Office 365 support and worked through all the troubleshooting steps to try to isolate this issue.All the attributes looked great for this user and was similar to all others that were activated.The only unique thing we knew about this user was that their name changed recently.Included in the name change was a user account (UPN user account) change.So we promptly tried to change the user account back to what it was, that didn’t resolve the issue.We even went as far to simulate this issue by created a test account, forcing directory sync, and then changing the user account.After doing so and fully testing the account, we discovered that this test account had no issues.

So what is the problem?Some sort of unique issue exist with this user, but we are unable to isolate it, as comparing this user to the other users proves to show similar settings.Because of this, at this point we are not sure of what the immediate fix can be, but we do have a not so elegant workaround.We finally solved this issue by renaming the existing account to a backup name.We then created a new user object with like settings to the original account.When we activated this account, we were in…The major downfall with this approach is now we have to bring in SID history, ensure the desktop logs on with this new account and existing profile information, etc.It was a bit of a painful process, but really the only work-around until we can isolate if this is a user account issue or an anomaly in Office 365.This work-around is not scalable if a larger number of users experience this issue.If this issue were to propagate at a larger scale, another workaround or fix should be pursued.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

David Greve

More from this Author

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram