• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1143
  • Last Modified:

SBS 2008 / Exchange 2007 - Autodiscover error 500

I am trying to get auto discovery up and working to sync with iPhones. However, we are getting an error : The remote server returned an error: (500) Internal Server Error.

We have a (bought) certificate for our external facing server (remote.domain) and installed. When running >test-outlookwebservices|fl it gives:

Id      : 1003
Type    : Information
Message : About to test AutoDiscover with the e-mail address Joe@domain.com

Id      : 1007
Type    : Information
Message : Testing server ABC.domain.local with the published name https://remote.domain.com/EWS/Exchange.asmx & https://remote.domain.com/EWS/Exchange.asmx.

Id      : 1019
Type    : Information
Message : Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://remote.domain.com/Autodiscover/Autodiscover.xml.

Id      : 1013
Type    : Error
Message : When contacting https://remote.domain.com/Autodiscover/Autodiscover.xml received the error The remote server returned an error: (500) Internal Server Error.

Id      : 1006
Type    : Error
Message : The Autodiscover service could not be contacted.

Likewise when we try going to: https://remote.domain.com/autodiscover/
this also shows server error in /autodiscover' application

When using https://testconnectivity.microsoft.com this gives:

An ActiveSync session is being attempted with the server.
       Errors were encountered while testing the Exchange ActiveSync session.
      Test Steps
      Attempting to send the OPTIONS command to the server.
       Testing of the OPTIONS command failed. For more information, see Additional Details.
      Additional Details
       An HTTP 500 response was returned from Unknown.
Headers received:
Content-Length: 4283
Cache-Control: private
Content-Type: text/html; charset=utf-8
Date: Wed, 18 Sep 2013 01:05:02 GMT
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET

Does anyone have any suggestions on what next to fix this?

  • 4
  • 3
1 Solution
Hmm, just to make sure, please run in exchange power shell:
>get-webservicesvirtualdirectory |fl  url*

Also what are the subjects name in your  certificate .. only remote.domain.com ?

If the email of your users is set like user@domain.com, this will not work because autodiscover will look for domain.com and not remote.domain.com

if your only name is remote.domain.com then you will need to put an SRV record in your external DNS

The SRV record should look like this :
_autodiscover._tcp IN SRV 0 0 443 remote.domain.com
Service: _autodiscover
 Protocol: _tcp
 Port Number: 443
 Host: remote.domain.com
hopvineAuthor Commented:
Running: get-webservicesvirtualdirectory |fl  *url*
InternalNLBBypassUrl : https://MYSERVER.domain.local/ews/exchange.asmx
InternalUrl          : https://remote.domain.com/EWS/Exchange.asmx
ExternalUrl          : https://remote.domain.com/EWS/Exchange.asmx

And yes, the only names in the certificate is remote.domain.com

I should also note we do have a certificate which covers www.domain.com and domain.com. This is currently only installed to our external web server.

On the SBS 2008 server, there is an entry in the DNS -> MYSERVER -> Forward Lookup Zones -> MYSERVER.local

This has an entry of:
Domain: MYSERVER.local
Service: _autodiscover
Protocol: _tcp
Port: 443
Host offering service: remote.domain.com

Is there another place we should be putting this? Our website is hosted externally which uses cpanel to control it. This does not have an ability to add a SRV record.
In your internal DNS there is no point to put an SRV record because domain joined machines are querying the AD directly and your phones are always external anyway. You should delete that record.

So how and where did you register remote.domain.com to point to your exchanche server ?
Normally it should be an external DNS record and there you can register the SRV record as well.

If its to much of trouble, you could disable SSL on the EWS virtual directorie and then instruct your cients to enter directly remote.domain.com and uncheck "my server require SSL"

To disable SSL > open IIS console > EWS > SSL > uncheck require SLL > run iisreset in CMD

*** Note that the above will work for mobile phones but will never work for Outlook Anywhere i.e external Outlook clients.

In my opinion if you already bought a certificate you should try to fix this correctly in your external dns, so your  Outlook and mobile clients enjoy autodiscover :)
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

hopvineAuthor Commented:
Thanks. I have now removed the SRV records from the SBS server.

Currently on the external site's web host, there are 2 records which relate to this:

remote.domain.com.      14400      IN      CNAME      DYNAMIC.DNS
autodiscover.domain.com.      14400      IN      A      <domain static IP address>

In the meantime, in IIS,  under Sites -> SBS  Web Applications -> EWS we have turned off SSL.

Certificate was purchased just for the remote.domain.com (SBS 2008) server). It has been installed only onto this server. Is there something else missing?

Meanwhile now when we try with the MS network analyser, with manual settings of:
remote.domain.com this does succeed! [using the autodiscover settings however still does not]

remote.domain.com.      14400      IN      CNAME      hopvine.dyndns.org      Edit   Delete
autoconfig.domain.com.      14400      IN      A      Edit   Delete
autodiscover.domain.com.      14400      IN      A

The Microsoft Connectivity Analyzer is testing Exchange ActiveSync.
       Exchange ActiveSync was tested successfully.
      Test Steps
      Attempting to resolve the host name remote.domain.com in DNS.
       The host name resolved successfully.
      Additional Details
       IP addresses returned: A.B.C.D
      Testing TCP port 443 on host remote.domain.com to ensure it's listening and open.
       The port was opened successfully.
      Testing the SSL certificate to make sure it's valid.
       The certificate passed all validation requirements.
      Test Steps
      The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server remote.domain.com on port 443.
       The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
      Additional Details
       Remote Certificate Subject: CN=remote.domain.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.SSL.com/resources/cps (c)11, OU=ABC123, O=remote.domain.com, C=GB, SERIALNUMBER=ABC Issuer: CN=SSL CA, O="SSL Inc.", C=US.
      Validating the certificate name.
       The certificate name was validated successfully.
      Additional Details
       Host name remote.domain.com was found in the Certificate Subject Common name.
      Validating certificate trust for Windows Mobile devices.
       The certificate is trusted and all certificates are present in the chain.
      Test Steps
      The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=remote.domain.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.SSL.com/resources/cps (c)11, OU=ABC123, O=remote.domain.com, C=GB, SERIALNUMBER=ABC.
       One or more certificate chains were constructed successfully.
      Additional Details
       A total of 1 chains were built. The highest quality chain ends in root certificate CN=SSL CA, O=SSL Inc., C=US.
      Analyzing the certificate chains for compatibility problems with Windows Phone devices.
       Potential compatibility problems were identified with some versions of Windows Phone.
        Tell me more about this issue and how to resolve it
      Additional Details
       The certificate is only trusted on Windows Mobile 6.0 and later versions. Devices running Windows Mobile 5.0 and 5.0 with the Messaging and Security Feature Pack won't be able to sync. Root = CN=SSLl CA, O=SSL Inc., C=US.
      The Microsoft Connectivity Analyzer is analyzing intermediate certificates sent by the remote server.
       All intermediate certificates are present and valid.
      Additional Details
       All intermediate certificates were present and valid.
      Testing the certificate date to confirm the certificate is valid.
       Date validation passed. The certificate hasn't expired.
      Additional Details
       The certificate is valid. NotBefore = 7/7/2011 4:21:28 PM, NotAfter = 7/8/2016 7:51:34 AM
      Checking the IIS configuration for client certificate authentication.
       Client certificate authentication wasn't detected.
      Additional Details
       Accept/Require Client Certificates isn't configured.
      Testing HTTP Authentication Methods for URL https://remote.domain.com/Microsoft-Server-ActiveSync/.
       The HTTP authentication methods are correct.
      Additional Details
       The Microsoft Connectivity Analyzer found all expected authentication methods and no disallowed methods. Methods found: Basic
      An ActiveSync session is being attempted with the server.
       Testing of an Exchange ActiveSync session completed successfully.
      Test Steps
      Attempting to send the OPTIONS command to the server.
       The OPTIONS response was successfully received and is valid.
      Additional Details
       Headers received:
MS-Server-ActiveSync: 8.3
MS-ASProtocolVersions: 1.0,2.0,2.1,2.5,12.0,12.1
MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy,CreateCollection,DeleteCollection,MoveCollection,FolderSync,FolderCreate,FolderDelete,FolderUpdate,MoveItems,GetItemEstimate,MeetingResponse,Search,Settings,Ping,ItemOperations,Provision,ResolveRecipients,ValidateCert
Content-Length: 0
Cache-Control: private
Date: Wed, 18 Sep 2013 12:15:10 GMT
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET

      Attempting the FolderSync command on the Exchange ActiveSync session.
       The FolderSync command completed successfully.
      Additional Details
       Number of folders: XY

<FolderSync xmlns="FolderHierarchy:">
</Add>LIst of folders
      Attempting the initial sync to the Inbox folder. This initial sync won't return any data.
       The Sync command completed successfully.
      Additional Details
       Status: 1
      Attempting to test the GetItemEstimate command for the Inbox folder.
       The Microsoft Connectivity Analyzer successfully received the GetItemEstimate response from the server.
      Additional Details
       Estimate: XYZ messages
Well, not having a fixed IP and a CNAME to point to  your server might give you weird results.It should be an  A record like
The autodiscover record in your DNS is also useless because you dont have in your SAN certificate the name autodiscover.domain.com

Like I said , you need an SRV record on the external DNS.
The way you should think is :
1) I have only 1 name in my certificate > remote.domain.com
2)How I can tell clients to connect automoatically to remote.domain.com

Without getting into details, Outlook and phones using autodiscover are hardcoded to look for specific DNS record names in order to resolve your server
Those names are:
1) domain.com
2) autodiscover.domain.com
For each name (record) it checks if the corresponding name is in the certificate, if its not  then it will continue with the next one.
If all fails, it check for the existence of a SRV record
3) srv record >http://support.microsoft.com/kb/940881

Therefore you have 2 choices. Either put an SRV record or purchase another certificate with the autodiscover.domain.com name inside.
Here is a similair question I answered before :

Also  my article about autodicover might bring some light in the tunnel :)
hopvineAuthor Commented:
We are currently working with our hosting company to get a SRV record in place (we use cpanel and this does not have this as an option for us to do alas).

Else we will also be looking at plan b - getting an autodiscover cert.

Will post later on progress on this and how resolved, so can help others too.
hopvineAuthor Commented:
We have succeeded in getting our hosting company to add a SRV record. This does now appear to be filtering in - which is now able to traverse the tree using the M$ connectivity check, which I can see the SRV record is being used. This is:

We may still look to get another certificate, but getting the SRV added (which also then picks up and shows as valid remote.domain.com's certificate) is looking good.

Thank you.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now