Outlook 365 Outlook Install Does Not See Local Exchange Account


Just beginning our Office 365 deployment to the desktops and will migrate to the hosted exchange model after we've deployed the software. But we've run into one caveat.


If we install Office 365 on machines that have had a previous version of Office installed, and an account configured in Outlook, the Office 365 sees that and properly configures Outlook to point to our local exchange server.


If we install Office 365 on a new machine that did NOT have a previous user profile/Outlook configured, it automatically configures the user account to point to the hosted server.


What do I need to do to allow me to properly configure the user account to point to our local exchange server until that point in time when we want to migrate to the hosted exchange?

8 Replies
Can you setup the Outlook profile manually?

See this process for example - just use your Exchange server name and credentials

Best, Chris

HI Chris,


Apologies for the delay. I've attempted to setup the profile manually. Each time I try this and enter the account/email address it then takes over and doesn't allow me to manually add the server.

Maybe this is the norm but my user accounts in O365 are their email addresses. And the email address is the same ID I put in to configure their Outlook.


So once O365 is installed and configured with the O365 account I attempt to modify the account that was created. I've been hesitant to completely remove the account due to the fact that Skype, OneNote & OneDrive all work as anticipated. And Skype works with our on premise Skype server. It's just the Outlook that drives the connection to the hosted exchange server.


The O365 Outlook account for a user, that points to the hosted exchange, points to A user account that points to my local server points to my domain. I searched through the registry between 2 different computers, one presenting the O365 issue and one that works as intended, and found many entries that referenced the I compared the registry entries but was not able to come to a definitive conclusion that would resolve my issue.  As mentioned, there are many entries in the registry I could modify and attempt to resolve this by trial and error. But I'd rather not take that approach.

Hmm. Registry changes are often used in coexistence to force the client to connect to the destination. I used to do this when moving from Multi Tenant Hosted to 365.

There is something less invasive that the registry. Have you tried the Hosts file of the local machine and putting Autodiscover for your Exchange server on that? Once you add it you should be able to use the CMD prompt to see if it takes.

Best, Chris
I had not tried the Hosts file. But that would need to be in place prior to the install. I will try that with any new installs. What can be done post install to remedy this?
Hmm, there isn’t much if it’s already setup. Both registry changes and host files need to be done before the setup of the profile itself.

You could possibly try to put the host file on and then try to setup a second profile. Outlook from 2010 has allowed multiple MAPI mailboxes. If that works then purge the other profile connecting to 365.

Best, Chris
best response confirmed by drawson (Contributor)

I wouldn't advise manual config, as while it's still technically possible, it hasn't been "supported" for a while. I do think I have an idea of what's causing the issue though - the new "Check for Office 365 as priority" step in the autodiscover process, which fires even before the SCP lookup does. The bad news is that the only way to disable this step is via registry changes:

Ah ok. Vasil - do you know when this change came in? Was it recent? Since moving to the role I’m in I don’t manage migrations on a day to day basis anymore and in the later days these were typically to 365 as opposed to configuration back to local exchange so this scenario didn’t apply.

In that case it’ll would then be purging the existing profile and either adding an Autodiscover XML to the local machine modifying the registry settings or modifying the registry directly specifically

ExcludeExplicitO365Endpoint DWORD =1

Best, Chris

Hey Vasil, thanks for that link. Doing a little more digging and this one specific entry resolved this for us as Chris was eluding to.

DWORD: ExcludeExplicitO365Endpoint
Value = 1

Eventually finding that quick answer here as well:


I'd also like to add that the addition of this one reg key was enough to resolve our issue. We didn't need to modify autodiscover.xml or the AutoD.user.xml after adding that.

Thank you Vasil and Chris! Much appreciated.