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 ( 10.0.0.0/8 ) 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.
All normal so far. We issued the LDAP query to AD, did the Autodiscover SCP query, and start to process the Autodiscover response.
Then the wheels fall off the wagon……
Clicking OK, shows the below dialogue box.
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*
You will note that the ExchangeGUID does not show up in the ADDS cmdlet:
Get-ADUser Administrator | Select Name, *GUID*
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_USER\Software\Microsoft\Office\12.0\Outlook\RPC |
| 2010 | HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\RPC |
| 2013 | HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\RPC |
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_User\Software\Microsoft\Office\15.0\Outlook\RPC /T REG_DWORD /V DefConnectOpts /D "0"
To Check For The Outlook 2013 DefConnectOpts Registry Value
Reg.exe Query HKEY_CURRENT_User\Software\Microsoft\Office\15.0\Outlook\RPC /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!
Cheers,
Rhoderick
