Exchange 2007 And 2013 Outlook Anywhere Co-Existence

Since we are still in the early stages of the year, and Exchange 2013 SP1 is now available, we will see lots of migrations to Exchange 2013.  Exchange 2013 can be deployed into an existing Exchange organisation where Exchange 2007 SP3 RU10 + and/or Exchange 2010 SP3 exists.

Let's look at an issue that can arise in an Outlook Anywhere co-existence scenario with Exchange 2007 and 2013.  After walking through the scenario we will see what can be done about it and review  a couple of other issues that will probably crop up, for example IIS permissions.

Update 27-3-2014:   Added link to TechEd 2013 Outlook Anywhere session.  Tightened up client auth wording.

Update 12-11-2014: Updated reference to OA traffic flow from Gavin's feedback.

Update 12-11-2014: Updated reference for disabling IPv6

Update 16-6-2016: Updated PowerShell Example to use code formatting, and to also set client auth to be NTLM.

Since some customers may not already have Outlook Anywhere (OA) enabled, and are lighting it up to permit co-existence with Exchange 2013, they may run into issues if the required OS bits are not deployed on the older versions of Exchange.  You may receive EventID 2003 stating that the RPC over HTTP proxy component is not installed of is not configured correctly. Note that enabling OA on the legacy Exchange servers is not a requirement unless you want to start using OA for legacy mailboxes as well as Exchange 2013 mailboxes.

It is possible to install Exchange 2007 and enable Outlook Anywhere without installing the required underlying OS component.  This is the RPC/HTTP proxy component that was introduced in Windows 2003 and allowed for the introduction of RPC/HTTPS.  Since Exchange 2007’s Outlook Anywhere requires the RPC/HTTP component, it will not work without it.  Funny that, eh?


Install Exchange 2007 Sans RPC/HTTP

We start this scenario with a base Windows 2008 R2 SP1 Installation.  The telnet client is installed, and nothing else just to prove that the Get-WindowsFeature cmdlet is working. :

Starting OS Components


Since we are using Exchange 2007 on Windows Server 2008 R2 SP1, we will not be prompted to download and install additional hotfixes. So let’s focus on installing Exchange! 

Slapping in the CD, and the splash screen launches.

Exchange 2007 Install Splash Screen

The familiar Exchange 2007 introduction screen appears, and after reading it fully we move on to the next screen:

Exchange 2007 SP3 Install

And we choose the typical installation type.  There is a reason for not splitting the roles, and we shall get to that at the end of the post!   Then we click Next.

Exchange 2007 SP3 Typical Install Selected

As expected since this is a base OS, the Exchange readiness check fails as we are missing IIS and other OS bits.

Exchange 2007 SP3 Typical Install Readiness Check Failed

To install the missing OS bits, we can grab the pre-canned OS requirement commands from TechNet. Since we are installing a server with CAS, Mailbox and HUB these OS bits must be installed:

ServerManagerCmd -i Web-Server

ServerManagerCmd -i Web-ISAPI-Ext

ServerManagerCmd -i Web-Metabase

ServerManagerCmd -i Web-Lgcy-Mgmt-Console

ServerManagerCmd -i Web-Basic-Auth

ServerManagerCmd -i Web-Digest-Auth

ServerManagerCmd -i Web-Windows-Auth

ServerManagerCmd -i Web-Dyn-Compression


If the server will support Outlook Anywhere clients, install the RPC over HTTP proxy feature by running the following command:

ServerManagerCmd -i RPC-over-HTTP-proxy

For ease we will typically use something like the below which is one line.  Please beware that it does not wrap:

ServerManagerCmd -i Web-Server, Web-ISAPI-Ext, Web-Metabase, Web-Lgcy-Mgmt-Console, Web-Basic-Auth, Web-Digest-Auth, Web-Windows-Auth, Web-Dyn-Compression, RPC-over-HTTP-proxy

Since folks may copy the above to install a server, the command is complete and includes the RPC/HTTP proxy component.  However note that in the below example I have deliberately omitted the RPC/HTTP proxy Windows component, else our scenario will not play out!

Installing Exchange 2007 SP3 OS Components - Less RPC/HTTP

Groovy, so we have the OS bits installed, and after a swift reboot we can then go and resume our Exchange installation.  Again choosing the same options as before, the readiness check now passes.  Green ticky-ticky all around!

Exchange 2007 SP3 Readiness Check Now Passes

Note that the RPC/HTTP proxy component is not installed.  This can be verified by the Get-WindowsFeature output in the background.

Exchange 2007 SP3 Readiness Check Now Passes - Note In Background RPC/HTTP Is Not Present

One Exchange installation completes, the server should be restarted, and the latest RU installed.  At the time of writing this was Exchange 2007 SP3 RU13.

As you saw, it is possible to install Exchange 2007 CAS role, without installing the RPC/HTTP proxy.  Let’s move on to enabling Outlook Anywhere on the server, and see what happens!


Enabling Outlook Anywhere Sans RPC/HTTP

Exchange 2007 will not check that the RPC/HTTP proxy component has been installed prior to enabling Outlook Anywhere.

Thus after Exchange 2007 is installed, we can enable Outlook Anywhere on this server, even without the RPC/HTTP component being installed:

Enabling Outlook Anywhere Without RPC/HTTP OS Component Installed


Impact of Enabling Outlook Anywhere Sans RPC/HTTPS

In a nutshell, it is not good!

Exchange does not have a mechanism to convert the HTTPS traffic to RPC, so Outlook Anywhere will not work at all on this server.

If you are monitoring the event logs (as you should be) Exchange does detect that something is not right. Exchange will check and realises the RPC/HTTP component is not present.  This generates the error 2003 stating that the RPC over HTTP component is not installed or is not configured correctly.

EventID 2003 - Exchange Detected RPC Over HTTP Proxy Component Is Not Installed

If you do open up Exchange Management Shell and look for the Outlook Anywhere settings, you will see that the Get-OutlookAnywhere cmdlet discovers that the /RPC virtual directory is not present since the RPC/HTTP component is not installed.  For details on checks (and the time taken) made to virtual directories when running cmdlets, please also see this post.

Get-OutlookAnywhere Shows Missing RPC Virtual Directory

Exchange 2013 CAS will also detect that something is amiss and write an error to its application event log.  This will manifest itself as error 3005 from MSExchange Front End HTTP Proxy stating which server that it found an issue with.  There are a few variants of this, with errors ranging from 404 to other HTTP error codes depending upon the issue at hand.  In this case the error is a 404 since the RPCProxy.dll is not present.

EventID 3005 MSExchange Front End HTTP Proxy

Note that the error string states that this is a Client Access 2010 server, but in fact this is an Exchange 2007 box.  Don't let that confuse you!

One other thing that you may notice for Exchange 2013’s proxy and redirection behaviour is the URL that is used to connect to legacy Exchange servers.  Exchange 2013 will build a URL to match the FQDN of the server in question.  I’ll save the details on that for a later post as it would add too much here.

Exchange 2007 & 2010 Required IIS Permissions

If you are currently using Outlook Anywhere in your Exchange 2007 or 2010 environments, in order to allow your Exchange 2013 Client Access Server to proxy connections to your Exchange 2007/2010 servers, you must enable and configure Outlook Anywhere on all of the Exchange 2007/2010 CAS in your organization.

When configuring Exchange 2007 Outlook Anywhere or Exchange 2010 Outlook Anywhere using the Exchange Management Console there are  options to enable either basic or NTLM authentication. 

Enabling Outlook Anywhere Exchange 2007 Management Console

The one originally chosen when deploying those servers depended upon your design which was in turn influenced by factors like client authentication requirements and NTLM support (or rather lack of) on any device that publishes Outlook Anywhere to the Internet.

If you configured Exchange 2007 Outlook Anywhere to use Basic auth, then you will see this in PowerShell:

Exchange 2007 Outlook Anywhere Basic Authentication Set

Note that this is a separate server.  This one is imaginatively called E2K7-2.  If NTLM was used:

Exchange 2007 Outlook Anywhere NTLM Authentication Set

Note the two different authentication settings that are listed.  ClientAuthenticationMethod and IISAuthenticationMethods.   For the detail oriented people out there, you saw that one was plural and the other singular.

If you configure OA for Basic auth, then the ClientAuthenticationMethod and IISAuthenticationMethods are both set to Basic.  The same is true for when OA is set to NTLM auth.  In that case ClientAuthenticationMethod and IISAuthenticationMethods are both set to use NTLM.

When co-existing Exchange 2007 and 2010 with Exchange 2013, we need to ensure that the correct authentication settings are in place.  There are two things that we need to pay attention to.  Authentication at the IIS layer and authentication at the client layer.  This is the IISAuthenticationMethods and   ClientAuthenticationMethod  properties respectively.

The Exchange Server Deployment Assistant notes that to allow CAS 2013 to proxy Outlook Anywhere connections to Exchange 2010 and 2007, Outlook Anywhere must be enabled and properly configured on Exchange 2007 and 2010.  If Outlook Anywhere was previously deployed, then ensure that their configuration will support Exchange 2013.   The follow permission considerations need to be addressed:

  • Client authentication, which is used to allow clients like Outlook 2013 to authenticate with Exchange is properly configured.  The same consistent NTLM OA client authentication scheme should be deployed on legacy CAS and CAS 2013.
  • Internet Information Services (IIS) authentication, which is used to allow Exchange servers to communicate must include NTLM auth.

As an example to set NTLM client auth on Exchange 2007.  The required permissions on Exchange 2007 and 2010 can be set using Set-OutlookAnywhere:


 Set-OutlookAnywhere -Identity 'ServerName\Rpc (Default Web Site)' -ClientAuthenticationMethod NTLM -SSLOffloading $False –ExternalHostName -Exchange2013HostName -IISAuthenticationMethods NTLM, Basic 


Setting multiple permissions on the IISAuthenticationMethods is probably a bit of a change compared to how we were previously configuring Outlook Anywhere.  There have also been some interesting discussions on this topic in the past.

Permissions for Outlook Anywhere coexistence were also discussed by Greg Taylor, in a style that only Gregg manages to get away with, at Tech Ready 2013 NA in session OUC-B313.   We should shoot who names these sessions…..   The video, PowerPoint and podcast for this and all the other available Exchange TechEd 2013 sessions are here.

Without getting into the entire CAS namespace discussion, if you want all Outlook Anywhere traffic to flow via CAS 2013 a critical point is that the Exchange 2007 Outlook Anywhere external URL is set to the external hostname of the Exchange 2013 server.  This is discussed in great detail in this post on EHLO by Ross.


Disabling IPv6 On Exchange 2007

Before you install Exchange 2013, you might need to disable IPv6 on some of your Exchange 2007 servers. Some connections between Exchange 2007 and Exchange 2013 don't work correctly when IPv6 is enabled and an Exchange 2007 server has both the Mailbox and Client Access server roles installed.

If you have Exchange 2007 servers that have both the Mailbox and Client Access server roles installed, complete the following steps on each of those servers to disable IPv6 on them.  To do so

  1. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
  2. If the DisabledComponentsentry doesn’t exist, do the following to create it:
    1. In the Edit menu, click New, and then click DWORD (32-bit) Value.
    2. Type DisabledComponents and then press enter.

  3. Double-click DisabledComponents.
  4. In the Value data field, enter 0xFF

Note that the recommendation is not to use 0xFFFFFFFF nowadays, and 0xFF should be used instead.  Please see this post on disabling IPv6.

Alternatively, if you want to automate this, you can use something like the following.

To Set The DisabledComponents Registry Key

Reg.exe Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /T REG_DWORD  /V DisabledComponents  /D "0xFF"

To Check For The DisabledComponents Registry Key

Reg.exe Query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /V DisabledComponents

This issue is discussed in the Exchange Deployment Assistant and also KB 2794253.




Comments (17)

  1. anonymouscommenter says:

    Thanks for sharing this info
    I am wondering if you even have to enabled outlook anywhere if the organization you are migrating from never used it at all?(lets say some military or government agency or just people that for security reasons used vpn only)

  2. Charles Derber says:

    Thanks & Its informative..!

  3. Hi Meagain,

    You could leave the legacy boxes as-is if you don’t want to flow the OA traffic through CAS 2013.

    You could also have totally separate CAS namespaces for legacy and CAS 2013 for OA. As long as the client gets the right URLs back through AutoD and the CAS servers are correctly published that should work. It’s more complex which is why you see CAS 2013 being the OA endpoint for the purposes in the coexistence scenario.


  4. anonymouscommenter says:

    When doing some recent customer work for Exchange 2013, I ran into an annoying issue in one of my labs

  5. anonymouscommenter says:

    Estou tendo um problema de configuração do outlook com servidor exchange 2013 que fica pedindo autenticação quando habilito o cache. Acredito que seja algo relacionado ao outlook anywhere. Quando desabilito o cachê ele não pede autenticação. Saberia me dizer o que pode estar de errado? Minha estrutura está com coexistência com o exchange 2007 pois ainda estou em transição.

  6. anonymouscommenter says:

    Hi Rhoderick,
    is there any need to Keep OA active on Exchange 2007 during the Migration to 2013 if it is not needed by any Client (Outlook 2007 -> Exchange 2007)?

    If not, how can it be deactivated in the best way? (without deleting Outlookprovider or sth. like it 🙂

    best regards,

  7. Andy – if you want to disable OA you could use the GUI or disable-OutlookAnywhere -Server:’ServerName’ to disable it for the 2007 box.


  8. anonymouscommenter says:

    Hi Rhoderick,
    thanks a lot for your reply!
    I understand you right that Outlook Anywhere is not needed to be active on Exchange 2007 to migrate and coexist with Exchange 2013?
    We want to disable it due to unnecessary authentication windows. It is clear that Exchange 2013 supports only "MAPI via HTTP".

    best regards,

  9. anonymouscommenter says:

    Hi Rhoderick,
    we disabled Outlook Anywhere on Exchange 2007. Then the Exchange 2013 comes back in the autoconfiguration as Exchange HTTP Server. Webservice are still pointing to 2007. This works for us, fine.

    We also tested(!) "Set-CASMailbox –Identity idenitity –MAPIBlockOutlookRpcHttp $True". This prevents Outlook from accessing a shared Mailbox on Ex2013. So it seems that Outlook does not distinguish between "RPC over HTTP" and "MAPI over HTTP". At least for
    that Setting 🙂

    best regards,

  10. Thanks Andy,

    I was planning to write more on this topic, though you can probably guess with some of the recent posts that I’ve been busy on ADFS….

    EWS is *VERY* version specific and OWA is version specific too so the recommendation is to use the 2007 legacy URL for those services. For 2007 OAB also recommended to download via 2007 CAS. There is work going on in the 2013 OAB space so that may change, but
    that’s what I’m being told right now.

    I assume that you are running 2013 CU5 since there was an issue where 2013 was not correctly generating the autoD XML for 2007 mailboxes prior to that.


  11. anonymouscommenter says:

    Hi Rhoderick,

    You may want to update the screenshots on this page, as they refer to a legacy namespace for Outlook Anywhere which is incorrect. Anyone not reading the whole article might miss this:

    "Without getting into the entire CAS namespace discussion, another critical point is that the Outlook Anywhere external URL is set to the external hostname of the Exchange 2013 server."

    Of course, people should read and not just look at pictures but that doesn’t always happen!


  12. Mike Crowley says:

    Rhoderick, could you get this page updated? It doesn’t explain that both authentication types are supported, or that there is iis vs client. Instead it states "Make sure that when you enable Outlook Anywhere on the Client Access Server, choose NTLM for
    IIS authentication."

  13. Hi Mike,

    There is mention of the IIS and client auth – its towards the bottom. You want to see that further up?


  14. Hi Gavin – sorry for not seeing your comment. I saw this when Mike added his today.

    Thanks for the feedback – have tweaked that for the scenario of CAS13 being responsible for all OA traffic flow.


  15. anonymouscommenter says:

    Please provide perfect solution for error code 3005.

  16. anonymouscommenter says:

    Hi Rhoderick

    We are in the process of 2007-2013 coexistence setup.
    The OA Authentication on 2007 was only NTLM before.

    Now this is configured.

    Exchange 2013 OA IISAuthenticationMethods basic, ntlm

    Exchange 2007 OA IISAuthenticationMethods basic, ntlm

    After this change some Outlook 2013 and 2007 clients cant connect with https?

    Any solution?

    Best regards

  17. Simon – what’s the client auth? Set that to be NTLM. The screenshots above are just an example.

    Also what are the OA namespaces here?


Skip to main content