Failures when proxying HTTP requests from Exchange 2013 to a previous Exchange version

Overview

I’ve seen this issue a few times over the past months & most recently this past week with a customer. Luckily there’s a fairly simple fix to the issue published by Microsoft, but realizing not everyone remembers every Microsoft KB that gets released I thought I’d shine a spotlight on this one.

Scenario

As part of the migration process, when customers move their namespace from either Exchange 2007 or 2010 to 2013, HTTP connections start proxying through 2013 to the legacy Exchange Servers and some users will experience failures. The potential affected workloads are:
AutoDiscover
Exchange Web Services (Free/Busy)
ActiveSync
OWA
Outlook

Test or new mailboxes may not be affected.

Resolution

The cause of this is the age old problem of Token Bloat. Users being members of too many groups or having large tokens.

The fix is to implement the changes in the below Microsoft KB article

“HTTP 400 Bad Request” error when proxying HTTP requests from Exchange Server 2013 to a previous version of Exchange Server
https://support.microsoft.com/en-us/kb/2988444

The interesting thing in this scenario is that the issue was not experienced in the legacy version of Exchange & even if you look at the tokens themselves, they may not seem overly large. It seems that the process of proxying Exchange traffic is much more sensitive to this issue. Also, in a recent case that went to Microsoft, even if you increase the recommended values to a value higher than your current headers it may not have the desired effect. In our case we had to set the MaxRequestBytes & MaxFieldLength values to exactly match the values in the Microsoft KB (65536 (Decimal)).

For further reading, please see the below articles.

Complimentary Articles

“HTTP 400 – Bad Request (Request Header too long)” error in Internet Information Services (IIS)
https://support.microsoft.com/en-us/kb/2020943

How to use Group Policy to add the MaxTokenSize registry entry to multiple computers
https://support.microsoft.com/en-us/kb/938118

Additional Note

As an FYI, another issue I commonly see when namespaces get transitioned to 2013 is authentication popups when connections proxy to the legacy Exchange Servers. Please see the below KB for that issue

Outlook Anywhere users prompted for credentials when they try to connect to Exchange Server 2013
https://support.microsoft.com/en-us/kb/2990117

I also blogged about it here
https://exchangemaster.wordpress.com/2014/10/30/exchange-2010-outlook-anywhere-users-receiving-prompts-when-proxied-through-exchange-2013/

New behavior in Outlook 2013 causing certificate errors in some environments

Posted by Andrew S Higginbotham

Background:

I originally discovered this issue back in early Feb & let a couple people on the Exchange Product Team know about it via the TAP but it seems to be affecting more customers than initially thought so I thought I’d share.

In Outlook 2007 through Outlook 2010 all domain-joined Outlook clients would initially query Active Directory for AutoDiscover information & ultimately find a Service Connection Point (SCP) value that would point them to their nearest Client Access Server’s AutoDiscover virtual directory. If that failed then they would revert to using DNS like any non-domain-joined Outlook client. The order of this non-domain-joined lookup is as follows:

https://company.com/autodiscover/autodiscover.xml

https://autodiscover.company.com/autodiscover/autodiscover.xml

Local XML File

http://company.com/autodiscover/autodiscover.xml (looking for a redirect website)

SCP AutoDiscover Record

Why it ever looked to https://company.com/autodiscover/autodiscover.xml I’ll never really know because honestly I’ve never come across a customer who had it deployed that way; most have https://autodiscover.company.com/autodiscover/autodiscover.xml but I imagine when Exchange 2007 was first being developed they weren’t exactly sure how customers would be implementing AutoDiscover.

Issue:

The above methods have served us well since Exchange 2007 timeframe but for some reason the Outlook team decided to try & implement some giddyup into Outlook & try to speed up the process. They decided to have domain-joined Outlook 2013 clients query both the SCP values in AD as well as the DNS records at the same time. If an SCP record was found it would still be used but in the event it failed then it would already have the DNS response ready to go. Great idea, however there’s one problem in the implementation.

If Outlook 2013 encounters any kind of Certificate error while doing the simultaneous DNS query then you will receive a pop-up in Outlook about the cert.

I actually stumbled upon this while in the middle of the scenario below:

That’s right, I actually get a certificate pop-up for my lab’s domain name (ash15.com) & not autodiscover.ash15.com like one would expect if I were to have a certificate issue on Exchange.

When Outlook 2013 does it’s simultaneous DNS AutoDiscover query the first URL it tries is https://company.com/autodiscover/autodiscover.xml, which in my lab environment resolved to my Domain Controller, which was also serving DNS, as well as a Certificate Authority. Ash15.com resolved to this server because it’s my internal Active Directory domain name & the name server entry resolves to my DC (just ping internaldomainname.local in your AD lab environment & you’ll see the same thing).

Now because I have web enrollment enabled & am listening on 443 in IIS the server responded. Also, because I did not have a cert installed on the server with ash15.com in the Subject or Subject Alternative Name then it gave the certificate error we see above.

Resolution:

The error is easy enough to get through & it only occurred on initial profile creation but this can definitely prove painful for some customers. Obviously my lab environment is a corner case but there have been several other customers report this issue with Outlook 2013 as well.

Here’s an example scenario.

Imagine you have a public website for andrewswidgets.com hosted by a third-party hosting site & you did not pay for HTTPS/443 services. However if you were to query the website using https then it could respond & obviously not return a certificate with andrewswidgets.com on it (because you haven’t paid for it you cheapskate…). Now imagine you begin deploying users using Outlook 2013 in your internal environment. In the past, they would have found the SCP record that would have pointed them to your internal Exchange 07/10/13 server for AutoDiscover & would have been happy as a clam (one Exchange Product Manager’s favorite way to describe Exchange bliss). However, now they may get a certificate pop-up for andrewswidgets.com when creating a new profile.

There are a couple ways around this. Make sure andrewswidgets.com doesn’t listen on 443, or possibly get a proper cert on your website that is listening on 443. Simply put, just make sure whatever andrewswidgets.com resolves to is something that’s not going to throw a certificate error.

I’ve heard nothing concrete or public but the Outlook team is aware of the issue & listening to customer feedback. I suggest contacting Microsoft Support if your organization is running into this issue.

Also, this KB offers methods to control which AutoDiscover methods are used by your Outlook clients

Multi-domain Autodiscover with a shared name spaces

Posted by Jedi Hammond

We had a situation where we needed to get autodiscover to go to a totally different url from the root domain, AND not modify the DNS records for the Root domain where the primary SMTP domain exists.

I want to STRESS that these solutions are for very specific cases and not for the purpose of replacing the primary AutoDutodiscover mechanisms.

Details of the environment:

Exchange 2010 Domain for child company = Parent.child.com (not a typo)
Exchange 2007 Domain for parent company = parent.com
smtp email address for all clients = user@parent.com
all mail is sent to parent.com and then if not resolved on parent.com and if unresolved forwarded to parent.child.com
Mail Flow works fine
Issue is with AutoD connecting to parent.com and unable to get parent.child.com AutoDiscover urls.

2 Solutions

If it’s a 2007\2010 server you can use a contact with the child domain as the target

in the parent domain create a contact for user@parent.com with a target address of user@parent.child.com

Use a local autodiscover.xml file (highlighted values indicate values that may need changing)

Outlook 2007 checks for a Local Autodiscover file based on a registry setting. You can check by using the following information:

Open regedit, and browse to(or use one of the reg files below):

Outlook 2007 Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Autodiscover
Outlook 2010 Key: HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Autodiscover

Add the Dword: PreferLocalXML

Value = 1

Add the STRING: parent.com

Value: %programfiles%\Microsoft Office\Office\parent.xml

MODIFY the xml below with your servern names and URLS
Save the text below as %programfiles%\Microsoft Office\Office\parent.xml

****************************************Copy Below and save as parent.xml************************************************************

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>
      <Protocol>
        <Type>EXCH</Type>
        <Server>internalhost.Parent.child.com</Server>
        <ServerDN>/o=Parent/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=ExServer</ServerDN>
        <ServerVersion>720280FE</ServerVersion>
        <MdbDN>/o=Parent/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=ExServer/cn=Microsoft Private MDB</MdbDN>
        <PublicFolderServer>internalhost.Parent.child.com</PublicFolderServer>
        <AD>internalhost.amer.Parent.child.com</AD>
        <ASUrl>https://mail.Parent.child.com/EWS/Exchange.asmx</ASUrl>
        <EwsUrl>https://mail.Parent.child.com/EWS/Exchange.asmx</EwsUrl>
        <OOFUrl>https://mail.Parent.child.com/EWS/Exchange.asmx</OOFUrl>
        <UMUrl>https://mail.Parent.child.com/UnifiedMessaging/Service.asmx</UMUrl>
        <OABUrl>https://mail.parent.com/oab</OABUrl>
      </Protocol>
      <Protocol>
        <Type>EXPR</Type>
        <Server>mail.Parent.child.com</Server>
        <SSL>On</SSL>
        <AuthPackage>Basic</AuthPackage>
        <OABUrl>Public Folder</OABUrl>
      </Protocol>
      <Protocol>
        <Type>WEB</Type>
        <External>
          <OWAUrl AuthenticationMethod="Fba">https://mail.Parent.child.com/owa</OWAUrl>
          <OWAUrl AuthenticationMethod="Fba">https://mymail.Parent.child.com/owa</OWAUrl>
        </External>
        <Internal>
          <OWAUrl AuthenticationMethod="Basic, Fba">https://internalhost.Parent.child.com/owa</OWAUrl>
          <Protocol>
            <Type>EXCH</Type>
            <ASUrl>https://mail.Parent.child.com/EWS/Exchange.asmx</ASUrl>
          </Protocol>
        </Internal>
      </Protocol>
    </Account>
</Response>
</Autodiscover>

**************************************************************************** Copy above******************************************************

****Outlook 2010 Autodiscover.Reg********************************************************************************************

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover]
"PreferLocalXML"=dword:00000001
"parent.com"="%programfiles%\\Microsoft Office\\Office\\parent.xml"

***************************************************************************************************************************

****Outlook 2007 Autodiscover.Reg********************************************************************************************

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover]
"PreferLocalXML"=dword:00000001
"parent.com"="%programfiles%\\Microsoft Office\\Office\\parent.xml"

***************************************************************************************************************************

Reference locations

http://technet.microsoft.com/en-us/library/cc837949(office.12).aspx

http://www.exchange-genie.com/2007/07/exchange-2007-autodiscover-service-part-1/

http://technet.microsoft.com/en-us/library/bb332063(EXCHG.80).aspx