This error can take several different forms. Some of the most common versions are listed below but not all versions are covered below. If you have received one not listed below, contact Support.
Your migration failed while checking destination credentials. Http POST request to 'autodiscover-s.outlook.com' failed - 401 Unauthorized: The credentials used to access the configured mailbox are invalid, or the credentials specified do not have access to the configured mailbox, or you may have overutilized resources.
DatabaseNotFoundException - 401 Unauthorized - Http POST request to 'autodiscover-s.outlook.com' failed: MigrationWiz was not able to locate/access the mail database.
401 Unauthorized - Http POST request to 'autodiscover-s.outlook.com' failed - Basic Auth Disabled: MigrationWiz has detected that Basic Authentication is not enabled for the tenant.
This is a common suite of errors which may be referencing several endpoint issues. The most common instances are listed below, with suggested resolutions. Note that there may be variations which are not listed here, or are errors from your source or destination environments.
This error most commonly occurs in Office 365 or On-Prem Exchange migrations. You can determine from the error message itself whether this is occurring on the source or destination environment.
Troubleshooting 401 Unauthorized
401 Unauthorized is an authentication error and is generally the result of MigrationWiz being unable to connect to the specified environment using either the admin credentials within your endpoint or the end-user credentials. The following steps will go through each of the most common causes of this error.
- Identify which endpoint is failing authentication by reviewing the MigrationWiz project user line item error history. Often either the source or destination is called out in the error text itself, but should also be located in a box in the bottom left corner of the error.
- Log in to the environment using the endpoint admin information and password.
- When logging in, check for any unexpected input. Any requirements other than username and password can cause this issue.
- If there are no issues found during login, ensure that the Admin account has the necessary permissions.
- If the login attempt succeeds on both endpoints but the migration continues to fail, attempt to login using the EWS URL: Example: https://webmail.sample.com/EWS/Exchange.asmx. Additionally, testing EWS access using Microsoft’s Connectivity Analyzer will often reveal the exact point of failure.
Note: For newly created accounts within Office 365, it will sometimes take up to 24 hours for the accounts/mailboxes to fully provision. During this period, it is possible that everything will look good within the Office 365 UI, but MigrationWiz will still fail when attempting to access them programmatically.
Username and/or Password incorrect
One of the most common causes of this is that the username or password (or both) have been entered incorrectly into the project. This can be caused by a typo or a recently changed password. The best way to check this is to attempt to log into your environment using the credentials you have entered. If you are able to successfully log in, please re-enter the username and password into your endpoint settings, ensuring that they are exactly the same as what you were able to log in with.
You can update the endpoint settings by clicking on Edit Project > Edit Project and then selecting either the Source or Destination Settings tab. Once there, click on “Edit Endpoint”.
If you are using end-user credentials, these can be checked and edited by clicking on the icon next to the user within your project.
Unexpected Input During Login
When logging into the environment, be aware of any input requirements. You should only be prompted for the username and password when logging in. If there are any other requirements, it would cause a 401 error since MigrationWiz is not prepared for such requirements.
These requirements can include:
- 2-Factor Authentication or Multi-Factor Authentication: MigrationWiz is not able to connect to any accounts that have such authentication enabled.
- Expired Password or Requirement to Change Password: Since MigrationWiz is not able to make these types of changes to the environment, any requirement to update or change the password will cause the migration to fail.
- Prompt to Select Which Account: It is possible to link different accounts to the same login (such as work, home, and school accounts). If you are prompted to select which account you are wanting to log into, it can cause this error.
Azure Security Default Settings
Sometimes the 401 error occurs days after a pre-stage or full migration. In this case, the security default policy in favor of 2-factor authentication is getting triggered, which causes the servers to fail authentication.
Logging into the destination Office 365 admin portal during migration set up triggers a pop-up prompting you to set up 2-factor authentication. You may skip to continue without 2-factor authentication, but this is only valid for 14 days. After that, the migration project still fails to verify the credentials, triggering the error.
To resolve this, disable the Enable Security Defaults option, following the steps below, to allow MigrationWiz servers to authenticate without triggering the 2-factor authentication set up.
To disable security defaults
- Log into Azure using the destination admin account and password by going to https://portal.azure.com
- Click on the Menuicon in the upper left corner
- Click on Azure Active Directory
- Click Properties
- Make sure "Access management for Azure resources" is set to No
- Click Manage Security Defaultsand set Enable Security Defaults to No
- Save the settings and log off
- Run verify credentials for the user again
If you are using an administrator login for migration, and have verified that the credentials are correct, but are still encountering the 401 Unauthorized issue, you may need to look into the administrator account's permission.
Follow the directions outline in the grant the administrator permission article. This should solve the issue. Note that if you are using Impersonation, you will want to follow the steps in the Impersonation Guide as well.
Basic Authentication is Disabled
In this case, you are able to log in to OWA with your MigrationWiz credentials, but MigrationWiz is generating the error.
The issue is likely caused by Modern Authentication. If Basic Authentication has been disabled for the tenant, you will either need to enable it (see steps below) or you will need to follow the steps in our Modern Authentication guide in order to be able to connect. Please note that this will only work for mailbox migrations; for any other migration type, we are unable to connect using Modern Authentication.
To check your permissions in EWS, execute the following remote PowerShell commands:
$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication Basic -AllowRedirection
Verify that your Basic Authentication for EWS is enabled for the associated account, using the following commands in Powershell.
Get-User -Identity "email@example.com" | fl *auth*
Get-OrganizationConfig | fl *defaultauth* | fl Oauth*
Enabling BASIC Authentication in EWS via Powershell
New-AuthenticationPolicy -Name "Enable Basic Auth for EWS"
Set-AuthenticationPolicy -Identity "Enable Basic Auth for EWS" -AllowBasicAuthWebServices -AllowBasicAuthOutlookService -AllowBasicAuthAutodiscover
Set-User -Identity "firstname.lastname@example.org" -AuthenticationPolicy "Enable Basic Auth for EWS" (replace Admin_or_user@domain.com with your own address, using this sample address will not succeed. ).
Set-OrganizationConfig -DefaultAuthenticationPolicy "Enable Basic Auth for EWS
If AD Connect is used to create the mailboxes.
If you have used AD Connect or AD Sync to create the mailboxes on the destination, it is sometimes the case that the mailboxes were not created properly, or with the settings that are needed in order for MigrationWiz to connect.
- Attempt to login to Office 365 OWA portal as the mailbox.
- Verify user is in AAD Connect state (admin > users > active users > open user > Mail setting > "user mailbox has not been migrated" is present. If that is not the case, mailbox is not instantiated on provisioning, user can contact Microsoft or recreate the object.
- Mailbox is not instantiated (AAD Connect GUID not set to NULL)
- Mailbox is not fully provisioned or is corrupt in the tenant.
- For item 1 above, set the needed GUID in AAD Connect to NULL: https://help.bittitan.com/hc/en-us/articles/115008109087-How-can-I-set-msExchMailboxGUID-attribute-to-null-
- For item 2 above, delete and recreate mailbox object or user in Office 365.
This is often the result of an outdated server. If you have validated that your credentials are working properly, and are on a platform such as Exchange 2010, Lotus Notes, or another older system, it may not have the resources necessary for the current migration.
To check resource utilization, first attempt to open your OWA URL from an external network from a system that is not joined to your domain. If OWA loads in a timely manner, check your server resources:
- Check server CPU usage
- Check memory usage
- Check disk I/O usage using performance monitor
- Check for overutilization of the network resources
- Lower the number of mailboxes you are migrating simultaneously and try again