Last week’s migrations: 48 users, 20GB

We migrated users with “highly-secured” Active Directory permissions that differed from the rest of our clients’ business.  Being well aware that we may encounter an issue we migrated one user beforehand as a test.  Even though our migration engineers permissions had been changed to allow them to migrate said users they still experienced the following error:

“Active Directory operation failed on onpremiseserver.contoso,com. This error is not retriable. Additional information: Insufficient access rights to perform the operation.

Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0″

The client’s security team were unable to determine the missing permission(s) and were unable to dedicate the resource to find the problem as there were concerns this was a “Cloud” issue.  Therefore we gained permission to move the user into a different Organisation Unit, and glad to say the migration worked immediately.  Some security changes were made to our accounts and we were able to progress.

This is an example of trying to work with technical teams to determine where problems really are.  Often the assumption is, because it’s perceived as being “new”, Office 365 is to blame.  It makes sense, in this situation AD permissions were in force, not special Exchange permissions so why would that be anything to do with the Security Team and their AD?  Yet by demonstrating a move with the test account we were able to show that the OU permissions were causing an issue.

These projects provide visibility of the underlying health of an Enterprise Active Directory. There is a step within the Enterprise Deployment Planning guide recommends rationalising/fixing AD once the planning stages are coming to the end.  It provides this example 12 plan for an 8,000 user roll-out:

We agree some time upfront cleaning up AD will help in the long run.  It will prevent you running post-migration scripts to “fix” mailbox items in the Cloud.  It also makes sense to do some housekeeping as you would for an on-premise project.  Assuming you do not have an automated process or system – deleting old accounts will save on license costs.

But I digress….

Back to this test user.  We found another interesting aspect.  Once we moved the user to the Cloud we were unable to login to OWA.  The message received was “The user name or password is incorrect“.  We tried the usual steps – ensured licensing was correct, changed password, to no avail.  The standard ADFS log in page does not provide very many clues as to what the problem is:

Eventually we learnt that the test user has a legacy AD workstation restriction configured.  The whole department has this configured. A reminder of where that setting is configured is here:

Once the restriction was deleted, the user was able to log in to the Cloud.  This problem was not apparent when the users attached to the on-premise Exchange server.  For now this is a workaround whilst we determine how to enforce workstation restrictions whilst connecting to Office 365.

There’s a good chance this is related to Single Sign-On and ADFS.