Autodiscover and Outlook Anywhere return http status 401

Question

Hi, I'm having issues with Autodiscovery (externally) and Outlook Anywhere for some users on our Exchange 2010 (SP3, RU2) setup. Just for information, we have Exchange servers at two AD sites (same forest / domain) with each site having 2 combined client
access / hub transport servers and 3 mailbox servers (with 2 stretched DAG's across both sites). Site A is internet facing, but site B isn't.
Autodiscovery
Internally, it's working fine (using the Test E-mail AutoConfiguration option within Outlook 2010). But externally (using the Microsoft TestConnectivity site), autodiscovery fails, returning the following:
Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
+Additional Details
   Elapsed Time: 1783 ms.
   + Test Steps
 The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL   https://autodiscover.company.com/AutoDiscover/AutoDiscover.xml
for user [email protected].
 The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
  +Additional Details
  An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you    are attempting to log onto an Office 365 service, ensure you are using your
full User Principal Name (UPN).
  Headers received:
  Content-Type: text/html
  Server: Microsoft-IIS/7.5
  WWW-Authenticate: Negotiate,NTLM,Basic realm="autodiscover.company.com"
The odd thing is, if I browse to the autodiscover file location (externally), then I'm prompted for credentials. When I enter the same credentials that I input into the Microsoft connectivity analyser, I do actually get the correct https status 600 response.
Also, within EMS, when I run "Test-OutlookWebServices" on Client Access servers in site B, I see the following results...
RunspaceId : 5c80ec49-f6f8-4f7a-ae63-4ed61a3c966e
Id         : 1104
Type       : Error
Message    : The certificate for the URL https://ExchServer.domain.local/autodiscover/autodiscover.xml is incorrect. For SSL to work, the certificate
needs
              to have a subject of ExchServer.domain.local, but the subject that was found is webmail.Company.com. Consider correcting service discovery,
             or installing a correct SSL certificate.
RunspaceId : 5c80ec49-f6f8-4f7a-ae63-4ed61a3c966e
Id         : 1113
Type       : Error
Message    : When contacting https://ExchServer.domain.local:443/autodiscover/autodiscover.xml received the error The remote server returned
an error:
 (500) Internal Server Error.
RunspaceId : 5c80ec49-f6f8-4f7a-ae63-4ed61a3c966e
Id         : 1123
Type       : Error
Message    : The Autodiscover service couldn't be contacted.
However - I can't see where Exchange has pulled the "...domain.local" address from for Autodiscovery. Both Get-AutodiscoveryVirtualDirectory and Get-ClientAccessServer both report the correct URLs/URIs with the FQDN of Company.Com (which are on
the GoDaddy certificate we use both internally and externally).
Outlook Anywhere
Whether my issues with Outlook Anywhere are related to Autodiscover, I'm not sure. Users who's mailbox is located at Site A (internet facing) are fine, and Outlook Anywhere works great. But users who's mailbox is at Site B, can't use Outlook Anywhere (Starting
Outlook in RPCDiag mode shows that it tries to connect, and sometimes establishes a connection for a couple of seconds, then disconnects completely).
Running "Test-OutlookConnectivity -Protocol:http" on a Client Access server at Site B, passes all but the last scenario (Mailbox::Logon), which throws up the following error:
RunspaceId                  : 5c80ec49-f6f8-4f7a-ae63-4ed61a3c966e
ServiceEndpoint             : ExchServer.domain.local
Id                          : MailboxLogon
ClientAccessServer          : ExchServer.domain.local.ad.local
Scenario                    : Mailbox::Logon.
ScenarioDescription         :
PerformanceCounterName      : Mailbox: Logon latency
Result                      : Failure
Error                       :
UserName                    : ad.local\extest_a91a4b4076f24
StartTime                   : 14/01/2014 16:33:27
Latency                     : -00:00:00.0010000
EventType                   : Error
LatencyInMillisecondsString : -1.00
Identity                    :
IsValid                     : True
Testing Outlook Anywhere using Microsoft RCA throws up the error:
RPC Proxy can't be pinged.
An HTTP 401 error was received...
Any help is greatly appreciated. Let me know if I've missed any info!
Thanks
Tony

Answer 1

Hi Guys,
My first chance today to respond!
Firstly - thanks for all the information. I really appreciate it.
Well, the good news is that Outlook Anywhere is now working at Site B. It looks like a combination of disabling Outlook Anywhere at Site B (thanks
Jon), and then being patient and allowing replication to do its stuff (thanks Rhoderck).
However RCA is still showing ‘Failed’ with the following error. If it helps to have the full output, please let me know. Just for info, I chose
the option to test using autodiscovery (rather than manually enter it), which passed fine.
Attempting to ping RPC proxy webmail.company.com.
RPC Proxy can't be pinged.
Additional Details
An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password.
If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN). Headers received: Content-Type: text/html Server: Microsoft-IIS/7.5 WWW-Authenticate: Negotiate,NTLM X-Powered-By: ASP.NET Date: Tue, 21 Jan
2014 09:55:41 GMT Content-Length: 58
Elapsed Time: 1063 ms.
RPCProxy - ValidPorts
Thanks for the 'SoundTrackOfMyLife' link... that looks to be almost identical to my scenario (with the exception of the Kemp LoadMasters). Following
through the troubleshooting, my CAS servers at Site A (Internet Facing) are showing the registry key 'ValidPorts' as...
SiteB-ExchCasSvr01:593;SiteB-ExchCasSvr01:49152-65535
So - should this be...
SiteB-ExchMbxSvr01:6001-6002;SiteB-ExchMbxSvr01:6004;SiteB-ExchMbxSvr01.domain.local:6001-6002;SiteB-ExchMbxSvr01.domain.local:6004;
i.e. I only add ports 6001,6002 and 6004 for mailbox servers only? If so, which sites mailbox servers should I put in here?
SSL Off Loading
We've only really implemented SSL Offloading on the advice from Kemp (it's built in to their Exchange 2010 template). Apparently, the advantage
is the LoadMasters have a dedicated hardware processor for decryption/encryption of SSL traffic, thus taking the load off the Exchange servers. Exactly how much of a load this would normally be for our Exchange servers is unknown. We've followed Kemp's documentation
on unchecking 'Require SSL' for the IIS directories on Site A, and also configured Outlook Anywhere with SSL Offloading through the EMC. This was required as the Kemp's are not re-encrypting traffic to the CAS servers (which are on the same site / LAN
segment), and we're not a bank... so don't need encryption between the LoadMasters and the client access servers.
However, Site B (non internet facing) has 'Require SSL' enabled on IIS directories, since (I guess) traffic is encrypted when performing CAS-CAS
proxying?
I am, as ever, open to suggestions on this design... since our original design was to use TMG for reverse proxy. It was only the end-of-life issue
with TMG, and the fact that we opted for the Kemp LoadMasters (which offered ESP as a replacement to TMG) that swung us down this path.
ESP and SSO are implements on the LoadMaster at Site A (internet facing), which is (was!) not the problem site.
Thanks again for your time and assistance guys. We’re almost there!
Tony