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.
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.
Modern Authentication has not been configured for your project
The steps listed below apply to both the source and/or destination tenant when they are Exchange Online, in regards to Exchange Web Services (EWS) in mailbox, archive mailbox, and public folder projects. Use a Global Administrator for the configuration steps.
For setup steps that include images, see under Enabling Modern Authentication for EWS between MigrationWiz and your Exchange Online Tenant in the following KB: Authentication Methods for Microsoft 365 (All Products) Migrations
Important: Failure to perform the steps for your Microsoft 365 endpoints, can result in failed jobs with 401 errors like the following in your project: Http POST request to 'autodiscover-s.outlook.com' failed - 401 Unauthorized
The administrator account being used for the project needs to be excluded from any MFA/2FA policies or Conditional Access policies that can block access for the administrator account. This requirement does not apply to the items or users being migrated in the project.
Configuring Modern Authentication to work with MigrationWiz for mailbox, archive mailbox, and public folder projects in Exchange Online is now the default method after Microsoft discontinued support for Basic Authentication in Exchange Online after December 2022. The following Microsoft documentation outlines this change in more detail. Should you have additional questions on how this change may impact your tenant, please contact Microsoft to assist with providing that information: Deprecation of Basic authentication in Exchange Online
The Azure Security Defaults must also be disabled in the tenant. (This is often enabled by default for all new Exchange Online tenants and there is no workaround for this requirement). For steps on where to enable/disable the Azure Security Defaults, see Enabling security defaults in the following Microsoft documentation. To disable, set Enable Security defaults to No: Security defaults in Azure ADModern Authentication Steps
- Log in to the Azure AD admin console with a Global Administrator login.
- Select Azure Active Directory in the Azure Active Directory Admin Center.
- Select App Registrations, which is found under Manage.
- Select New Registration at the top of the screen.
- Give the app a distinct name. You can change this later if necessary.
- Select the Accounts in any organizational directory button.
- Under Redirect Uri, select Public Client (mobile & desktop) and set it to urn:ietf:wg:oauth:2.0:oob
- Click Register.
- Go back to App registrations.
- Select the App you just created.
- In the Overview, you will find a ClientId (aka Application) and Directory (Tenant) ID.
- Copy both of these to another application, such as Notepad, for use later in this process.
- Under the Manage menu, select Authentication.
- Set the option Allow public client flows to Yes.
- Click Save.
- From the Manage menu, select API permissions.
- If API permission named User.Read under Microsoft Graph is already present, this can be removed. The Microsoft Graph API is not applicable to this project type and is not used.
- Select Add a Permission.
Select APIs my organization uses
Scroll down and select Office 365 Exchange Online
Then select Delegated Permissions
- Check the box under EWS for EWS.AccessAsUser.All.
- Click Add permissions. This permission only allows the OAuth application (MigrationWiz) to be associated with EWS.
- Important: This does not grant access to all mailbox data.
- Click Grant admin consent.
- Click Yes to confirm the settings.
- In MigrationWiz, select the project that needs to be configured for Modern Authentication.
- Click the Edit Project menu.
- Select Advanced Options.
- Under Support Options enter the ClientID and TenantID information you saved earlier in the following format:
- If enabling Modern Authentication for the Source:
- If enabling Modern Authentication for the Destination:
- Enter the specific ClientID and TenantID for your tenant in place of the xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
- These options can be entered for either the Source or the Destination, or both, depending on the settings on the tenants.
- These options need to be configured for each MigrationWiz project that needs to have Modern Authentication enabled.
- If enabling Modern Authentication for the Source:
- Run a Verify Credentials to confirm that MigrationWiz can connect using Modern Authentication.
- Click on the item that was verified. There will be a message in the MigrationWiz Migration Information page that Modern Authentication is being used. This message will show in the “Migration Errors” box; however, it is not an error. This is just a message confirming that Modern Authentication is now active and being used for the connection.
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
The Azure Security Defaults are required to be disabled in Office 365 to work with MigrationWiz. 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 Menu icon 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 Defaults and 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 outlined 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.
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 Azure for MigrationWiz.
- For item 2 above, delete and recreate mailbox object or user in Office 365.
401 Unauthorized errors may occur if OneDrive has not been provisioned by the user.
- Create a user in Office 365 and assign a license that includes OneDrive for Business. For step by step instructions, see the Microsoft article Add users individually or in bulk to Office 365.
- Set the administrator privileges. Grant one of the permission levels listed below.
After you perform these steps, the specified user will be visible in the Office 365 administrator center. Full provisioning of the user account can take up to 24 hours.
If the 401 error is for the source OneDrive. Check to ensure that the user is not blocked or disabled and that they are licensed to use OneDrive in the source tenant and have logged into their OneDrive recently.
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.