Outlook Unable To Connect To Exchange –Default Gateway Not Found

When doing some recent customer work for Exchange 2013, I ran into an annoying issue in one of my labs.  Outlook 2013 refused to connect to Exchange 2013.   A witch hunt then ensued to ensure that all of my Outlook Anywhere, Autodiscover and authentication settings were correct.  Well it turns out that they were, and this was just a client side issue.  Legacy IIS permissions when coexisting with Exchange 2013 are covered here for example.

The symptom was that Outlook would not connect using an existing profile, and was unable to create a net new profile.  When creating a new profile the error received was “The action cannot be completed.  The connection to Microsoft Exchange is unavailable.  Your Network Adapter does not have a default gateway”.

Since this entire lab exists on a single flat subnet ( ) I foolishly, ignored the default gateway bit of the error message and focussed on client connectivity.   Why would it want a default gateway when all machines are on a single subnet, the network is a private Hyper-V switch and all machines resolve names perfectly……

Let’s look at what was going on and then remediate manually and how to automate the fix.

Running Outlook  Auto Account Setup

Trying to create a new Outlook 2013 profile with pre Outlook 2013 SP1 and then Outlook 2013 SP1 both resulted in the same issue.

Firing up Outlook initiated the Auto Account setup.  As expected we hit up AD to get the SMTP address and then query AD for the Autodiscover SCP endpoints.  For details on Autodiscover please see this post.

Creating New Outlook 2013 Profile - Auto Account Setup

All normal so far.  We issued the LDAP query to AD, did the Autodiscover SCP query, and start to process the Autodiscover response.

Creating New Outlook 2013 Profile - Searching For Settings...

Then the wheels fall off the wagon……

The action cannot be completed.  The connection to Microsoft Exchange is unavailable.  Your Network Adapter does not have a default gateway

Clicking OK, shows the below dialogue box.

Mailbox GUID Displayed in Exchange Server Name Field

Couple of things to mention about the content of the above window.  Note that the Exchange server field does not state the name of any of the Exchange servers.  Is this something to be worried about? The answer is no.  This was a deliberate design change in Exchange 2013 to provide a single consistent identity that Outlook could store.  The intent was to minimise the occurrences of “Your administrator has made a change that requires you to restart Outlook”.  We can talk more about that with MAPI/HTTP.

You will note that the information specified in the Exchange server name is the ExchangeGUID of the mailbox.  This can be seen below:

Get-Mailbox Administrator | Select Name, *GUID*

Checking Mailbox's ExchangeGUID

You will note that the ExchangeGUID does not show up in the ADDS cmdlet:

Get-ADUser Administrator | Select Name, *GUID*

ExchangeGUID Is Not Present Within ADDS Get-ADUser Cmdlet

Going back to the error screen again…..

Clicking Check Name again, just shows the previous error – The connection to Microsoft Exchange is unavailable.  Your network does not have a default gateway.

What’s up with this?

Correcting The Issue By Disabling Outlook Connection Optimisation

In this case we are using a pretty rare scenario.  All of these test machines exist on an isolated segment with no other network access whatsoever.  Typical client machines have a default gateway configured to allow IP traffic to flow correctly in the environment.  Outlook 2007 will typically look for a machine to have a default gateway set so they can perform some more advanced connection optimisation compared to Outlook 2003.  In this case it this which is getting in the way.  As described in KB 913843, this is disabled in the registry.  The registry keys and values to set will depend upon the version of Outlook that you have installed.    The registry keys are:

Outlook Version Registry Path
2007 HKEY_CURRENT_USERSoftwareMicrosoftOffice12.0OutlookRPC
2010 HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0OutlookRPC
2013 HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0OutlookRPC

Which contains a  REG_DWORD called  DefConnectOpts  = 0

Note that the RPC key may not currently exist.  If it does not you can manually create it or use the automated solution below in this post.

This registry data disables the new Outlook 2007 connection logic and forces Outlook 2007 to use the same connection logic available in Outlook 2003.  One check that gets disabled is  the step to validate if a default gateway is present.

Please note that there are multiple reasons Outlook 2013 may not want to connect to Exchange 2013.  This is just one of them.  A couple of the other recent ones that I have see are:

KB 2264398 Outlook Unable to perform a Check Name or connect to an Exchange mailbox may get these errors:

KB 2934750 Outlook 2013 cannot connect after an Exchange Server 2010 mailbox is moved to Exchange Server 2013

If you want to automate this via a script, logon script or just don’t want to have to browse the registry, we can use the venerable reg.exe tool.

To Set The Outlook 2013 DefConnectOpts  Registry Value

Reg.exe Add HKEY_CURRENT_UserSoftwareMicrosoftOffice15.0OutlookRPC  /T REG_DWORD  /V DefConnectOpts  /D “0”

To Check For The Outlook 2013 DefConnectOpts  Registry Value

Reg.exe Query HKEY_CURRENT_UserSoftwareMicrosoftOffice15.0OutlookRPC /V DefConnectOpts

Funnily enough, after the fact I remembered that I’d seen this previously, about 5 years ago.  Those who forget the past certainly do repeat the same mistakes!



Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *