Partager via

Outlook fails to open with multiple pop ups post migration to Office 365

  • Article

Some users may experience issues with launching Outlook after migrating from a webmail based systems that support IMAP and SMTP, after initial successful profile creation. I’ve seen this most commonly when users are migrated from CPanel system and references to previous email systems in DNS are not removed when adding Office 365 DNS information.

Since Outlook 2016 implemented Direct Connect method, most common behavior seen has been the initial profile setup completes then Outlook is unable to start.

However, if manually creating a new profile, you may see these messages at time of creation.

cpanel2  cpanel1

Outlook Symptom:

When Outlook is launched after a profile is created connecting user to an Office 365 mailbox, error messages are generated:

Error 1: error-1

Outlook cannot log on. Verify you are connected to the network and are using the proper server and mailbox name. The Microsoft Exchange information service in your profile is missing required information. Modify your profile to ensure that you are using the correct Microsoft Exchange information service.

Error 2: error-2

System resources are critically low. Close some windows.

Error 3: error-3

Cannot start Microsoft Outlook. Cannot open the Outlook window. The set of folders cannot be opened. The information store could not be opened.

When you run Support and Recovery Assistant for Office 365, some or all of the following items are detected(logs for Support and Recovery Assistant is located in %USERPROFILE%\appdata\local\SaRAresults"):

Your Outlook problems are happening because your DNS server settings include both a CNAME and SRV record set. To fix this problem, your Office 365 admin needs to change these DNS settings.

Remove SRV record "_autodiscover._tcp.o365tests.net" for domain "O365tests.net". This SRV record, in combination with a CNAME record, prevents Outlook from starting or loading the user's profile

We retrieved user settings (Autodiscover) by using the method: HttpsRootdomain

In addition, hidden autodiscover XML file for user shows non Office 365 mailbox setup information:

xmlbad

To fix this issue for single client, we need to add following keys to the user’s registry to prevent Outlook from attempting to connect to invalid mail service and from using incorrect last known good configuration then recreate user’s profile with a new profile folder.

Step 1: Use ExcludeLastKnownGoodUrl, HTTPSEXCLUDEROOTDOMAIN, and ExcludeSrvRecord to prevent Outlook attempting to connect user to mailbox on previous email service.

Configure following registry subkeys as follows:

HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Autodiscover

DWORD: ExcludeLastKnownGoodUrl

Value: 1

HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Autodiscover

DWORD: EXCLUDEHTTPSROOTDOMAIN

Value: 1

HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Autodiscover

DWORD: ExcludeSrvRecord

Value: 1

Step 2: Rename, backup, or remove the "%USERPROFILE%\appdata\local\microsoft\outlook” folder

Step 3: Recreate user's profile

If you are an administrator or have access to modify tenant’s DNS, follow instruction provided by Support and Recovery Assistance to removed references to Webmail service with IMAP and SMTP in DNS with only necessary records to allow users to connect to new Office 365 mailbox.

Only CNAME record for autodiscover.<domain>.<suffix> to autodiscover.outlook.com is required to connect user to Office 365 mailbox in most deployments.

Support message provided by Support and Recovery Assistant for Office 365:

Only make this change if migration to Office 365 is complete for the organization and that there are no remaining users or applications that utilize IMAP based web mail service utilizing same domain.

This SRV record, in combination with a CNAME record, prevents Outlook from starting or loading the user’s profile. 1. Go to your domain hosting provider’s website (for example, GoDaddy, 1&1 Internet, or Register365). 2. Remove SRV record “_autodiscover._tcp.office365.net”. If you recently modified the DNS records, you need to wait up to 72 hours for the DNS records to fully replicate on the Internet. forblog

Additional Information:

Create DNS records for Office-365 when you manage your DNS records You can’t create new Outlook profiles, view free/busy information, or connect to a shared mailbox or a public folder in Office 365 After migration to Office 365, Outlook doesn’t connect or web services don’t work

Comments

  • Anonymous
    December 09, 2016
    Thankshad similar/same thing yesterday just that it happened because of something diffrentthe host provider put an ssl cert on the "rootdomain" so clients were hittingit before going to 365...EXCLUDEHTTPSROOTDOMAIN took care of that:)running sara also fixed it(no errors in sara , it just configured new profile eventually) but then it came back.
  • Anonymous
    December 09, 2016
    Thanks for the response! I'm surprise it wasn't caught by Support and Recovery Assistant(In the logs, user may not it depending on scenario). If you'd like to message me, I'd be happy to look into it and add more information.In addition, when a host provider adds a SSL cert in on the root domain that does not match the tenant's vanity domain that certain mobile devices does not automatically configure and requires manual setup with account, domain, and server info.
  • Anonymous
    January 16, 2017
    The comment has been removed
  • Anonymous
    April 04, 2017
    The comment has been removed