none
Autodiscover throwing 404 through Reverse Proxy

    Question

  • Single 2010 CAS in the Organization.

    Using F5 BigIP for the Reverse Proxy (not ISA).   I have unchecked 'Require Client SSL' on Autodiscover, Microsoft-Server-ActiveSync and OWA.  Then on the BigIP, created a VIP and SSL terminated it.  Plain HTTP is passed back to the CAS.


    No other changes to the CAS. 

    Internal URL is E14-CAS.domain.com
    External URL is mail.domain.com

    ActiveSync works
    OWA works
    Autodiscovery Internal (SCP and DNS SRV record) is working.
    Autodiscovery External (DNS SRV Record) is NOT working.  

    https://www.testexchangeconnectivity.com/ throws the following error:

    - DNS passes (Via DNS SRV)
    - Cert passes
    - Autodiscover POST fails

    >>> Attempting to send AutoDiscover POST request to potential autodiscover URLs.
    >>> Failed to obtain AutoDiscover settings when sending AutoDiscover POST request.
    >>> Attempting to Retrieve XML AutoDiscover Response from url https://mail.domain.com/Autodiscover/Autodiscover.xml for user TestUser1@domain.com
    >>>>>> Failed to obtain AutoDiscover XML response.
    >>>>>> A Web Exception occurred because an HTTP 404 - NotFound response was received from Unknown 


    Any ideas?
    Monday, December 07, 2009 7:41 AM

All replies

  • Are you setting up a client using Microsoft's Online Service or BPOS? They current have an Autodiscover related outage that is prevent client from being able to be setup. No ETA yet.

    ND
    Monday, December 07, 2009 10:10 PM
  • No, this is my own lab Infrastructure.
    Monday, December 07, 2009 10:59 PM
  • Any fix to this issue. We are experincing the same problem with our f5 load Balancer.  I set the autodiscoverinternaluri as well to use autodiscover url that is loadbalanced.  Its clearly a problem with autodiscover trying to use https.. and the load balancer reverse proxy down to autodiscover failing.  The web.config file pretty much has a https configuration using selfsigned cert.  I'm considering creating one ssl and load it into both cas servers and see if that helps and modify the reverse proxy on the loadbalancer.  This will cuase some overhead to dycrypt apply cookie persistenc and re-encrypt. 

    Again did you find a solution? We have been playing with this for a week now.

    Monday, February 15, 2010 9:57 PM
  • Found the fix.

    The issue boils down to a certificate error with the selfsigned certificate on the CAS servers.  We have our entire exchange (MBX,CAS,EDGE,HUB) in a private network behind F5 LB.  So all our traffice ie imap,pop3,rpc,rpc/http/,owa etc.. is passes through load balancers.  So finding a solution to the issue was very important. 


    1. Re-issued cert for outlook.contoso.com added altnernate domain autodiscover.contoso.com
    2. created a new f5 configuration  for autodiscover.contoso.com passing SSL all the way to CAS servers/pool
    3. assigned new cert to f5 autodiscover config
    4. exported certificate from f5
    5. imported certificate to cas servers
    6. modified host header to outlook.contoso.com
    7. assinged cert binding for 443 to cas server
    8. added dns A record autodiscover.contoso.com
    9. Modified SCP record in AD to https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml

    After making the above changes all autodisocver issues disappeard.  This fixed our calendar issues and downloading offline address book.  Prior to making the above changes we validated our suspicions by:
        -  connecting to a exchange behind the loadbalancer
        -  setting the host file entry for outlook.contoso.com
        -  ran the command line test "test-outlookwebservices -identity <mbx of 2010 recipient>
        -  the test will return a SSL warning about mismatched certs... but the autodiscover will work against the desired FQDN
        - We then imported the cert and re-ran the test...
        - Cert error went away and test was still succesful

    We had other minor issues around
        - public folders not fully replicated for Free/Busy
        - moving ownership of OAB
        - Moved Recipient policies to 2010 as well

    The Above did not affect the 404 errors but were done as part of our on going migration to 2010


    Now on to our next phase integrate 3 data centers.  Two local on one DR site 700miles away.  Hope this help other folks struggling with F5 config.

    • Proposed as answer by necroferret Thursday, February 18, 2010 12:47 PM
    Thursday, February 18, 2010 12:41 PM
  • We have the same issue, I'm glad your works, but it sounds more like a work around than a fix. We want the F5's to do the full SSL offloading, so we do not wish to pass the SSL right through.

    We do already have the autodiscover.company.com Alternate name on the cert, and we do not have the external SRV record out there yet (I wonder how much this has to do with it). Our client has a call opened with MS, but right now I'm guessing it's some sort or permissions to the directory structure. Right now OWA works but we get the same error for Active-Sync:

    https://mail.company.com/Microsoft-Server-Activesync/ A Web Exception occurred because an HTTP 440 - 440 response was received from Unknown

     

    Still working it.

     

    Bob James

    Tuesday, June 29, 2010 7:55 PM
  • If you are wanting to pass HTTP traffic back to the CAS servers (SSL Offloading), read the following article.  In order to get EWS and Autodiscover to play nice, you have to edit the web.config file.

    http://howdouc.blogspot.com/2010/06/ssl-offloading-in-exchange-2010.html

     


    Tim Harrington - Catapult Systems - http://HowDoUC.blogspot.com
    Tuesday, June 29, 2010 8:02 PM
  • I am also using F5s to offload SSL and have the same issue you are describing.  Its like the "test-outlookwebservices" is not paying attention to what is defined when using:

    "set-clientaccessserver -AutoDiscoverServiceInternalUri https://F5VIP.domain.com/autodiscover/autodiscover.xml"

    or when using

    "set-autodiscovervirtualdirectory -internalurl https://F5VIP.domain.com/autodiscover/autodiscover.xml -externalurl https://F5VIP.domain.com/autodiscover/autodiscover.xml"

    When I run the test, it returns https://computername.domain.com:443/autodiscover/autodiscover.xml received the error The remote server returned an error: (404) Not Found.  I just dont know why it is using the actual CAS computer name instead of the URLs I have defined (shown above). I know it is doing this because I have ssl disabled and offloaded to the F5s as required by what TWHarrington suggested in his link. 

    So has anybody been able to fix this?  Is very annoying because 2007 was not like this.

    Tuesday, August 10, 2010 8:13 PM
  • A couple of questions for you...

    1) Did you run the set-clientaccessserver -AutoDiscoverServiceInternalUri https://F5VIP.domain.com/autodiscover/autodiscover.xml command against each CAS server?

    2) You mentioned 2007, do you still have 2007 CAS servers in the environment?  If so, in the same AD site?

    3) Did you create a CAS Array and update all your MB databases to use that?: Set-MailboxDatabase DBName -RPCClientAccessServer NameOfCASArray

    4) Did you modify the web.config file on every CAS server as described in the article? (change httpsTransport to httpTransport)


    Tim Harrington - Catapult Systems - http://HowDoUC.blogspot.com
    Tuesday, August 10, 2010 8:42 PM
  • 1. yes, and even verified the value using adsiedit on the SCP object.

    2. yes & yes

    3. yes, and there are no MB databases created yet.

    4. yes

    Like I said, its like the "test-outlookwebservices" isnt paying attention to what I have defined mentioned in my first post.  It just uses the host name of whichever CAS server I am running the test on.  In the end when everything is in production and working this likely will not come up as an issue...its just bugging me the test is failing and its failing because its not reading the URLs I have defined.

    Tuesday, August 10, 2010 11:01 PM
  • You haven't created any MB databases, so no users are homed on 2010?  Create a database, enable a user, and test with Outlook Autodiscover test: See if profile gets auto-generated correctly.  Check all URLs given to Outlook via Crtl-right click Outlook icon in system tray and select Test Email AutoConfiguration.  Uncheck the two Guessmart boxes.
    Tim Harrington - Catapult Systems - http://HowDoUC.blogspot.com
    Wednesday, August 11, 2010 12:36 AM