Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1169
  • Last Modified:

Activesync Autodiscover failing

My Activesync Autodiscovery is failing (Both in real life, and at testexchangeconnectivity.com.

The failure at testexchangeconnectiivty.com is:
 
Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
       Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
       
      Test Steps
       
      ExRCA is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com/AutoDiscover/AutoDiscover.xml for user username.com
       ExRCA failed to obtain an Autodiscover XML response.
       
      Additional Details
       None of the expected XML elements were found in the XML response.


Test-outlookwebservices gives no errors.
Test-activesynconnectivity does give an error.


Error                       : An incorrect HTTP response was received for user domain.internal\username@domainname.com, HTTP code = MovedPermanently.


Further info:
Windows 2008 R2, Exchange 2010 SP1 (Installed as /hosting which may be relevant). There are two CAS using MS NLB - however, I get precisely the same results when the firewall points to either of the CAS directly.

Any ideas?
0
nphsmith
Asked:
nphsmith
  • 15
  • 12
  • 2
  • +2
1 Solution
 
suriyaehnopCommented:
Are you using credential format correctly? domain.com\username NOT domain.com\username@domain.com
0
 
nphsmithAuthor Commented:
Thanks, I have tried both, with the same result (Though I believe the UPN should work fine?)
0
 
noifenCommented:
Make sure your autodiscover.domain.com DNS entries are pointing to the correct server (the one with autodiscover in IIS)
0
Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

 
Lance_PCommented:
I had faced a similar issue and just reset the Virtual directories and everything worked fine.

http://technet.microsoft.com/en-us/library/ff629372.aspx
0
 
nphsmithAuthor Commented:
Yup, they are. I should mention that it passes the Outlook Autodiscovery test just fine, so it is unlikely to be a DNS/firewalling/certificate issue. The activesync autodiscover finds the correct server, connects to SSL, passes certificate, fails on the POST request. Full 'log' below:

Testing of this potential Autodiscover URL failed.
       
      Test Steps
       
      Attempting to resolve the host name autodiscover.domain.com in DNS.
       The host name resolved successfully.
       
      Additional Details
      Testing TCP port 443 on host autodiscover.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
      Checking the IIS configuration for client certificate authentication.
       Client certificate authentication wasn't detected.
       
      Additional Details
      Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
       Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
       
      Test Steps
       
      ExRCA is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com/AutoDiscover/AutoDiscover.xml for user nick.smith@domain.com.
       ExRCA failed to obtain an Autodiscover XML response.
       
      Additional Details
       None of the expected XML elements were found in the XML response.
0
 
nphsmithAuthor Commented:
I'd prefer not to reset the Virtual Directories except as an absolute last resort. These are newly configured pre-production servers, so really shouldn't have any corruption or weirdness, and if there is, i'm likely to reintroduce the problem on recreation. Thanks though.
0
 
Lance_PCommented:
If you dont want to reset them, then you will have to verify the permissions on each virtual directory.

In your case the authentication settings on the autodiscovery and OAB folder.

http://autodiscover.wordpress.com/2010/05/16/exchange-20102007-virtual-directory-default-permissions/
0
 
Lance_PCommented:
And with all due respect, when dealing with a Microsoft product, no matter even if it is a 'Vanilla' installation, you will still find 'some' errors.
0
 
Lance_PCommented:
Also please confirm that you have the certificate installed on TMG listener and the Exchange servers.
0
 
nphsmithAuthor Commented:
The certificate is installed on the CAS servers, we don't use TMG. Checking permissions now, thanks for the link.
0
 
nphsmithAuthor Commented:
I can confirm permissions on Autodiscover and OAB  are correct.
0
 
Lance_PCommented:
How exactly are you publishing Exchange?
0
 
nphsmithAuthor Commented:
Not entirely sure what you mean by Publish in this context (I'm mainly a Terminal Services guy, so publish usually means something else to me ):).

I have a Sonicwall (Hardware firewall) which Nats HTTP and HTTPS request through to the internal NLB IP Number (NB, I have also tried Natting direct to the CAS Servers 'normal' Ip number, to try and avoid any possible NLB complications. Results are the same).

Is that what you mean?
0
 
Lance_PCommented:
That would work fine. I have used it in smaller offices, but prefer something like TMG/UAG in between to strengthen the security.

Also Its is VERY important to note if you have WAN management enabled on your sonic wall the default port is ALWAYS 443 if using SSL. You might want to change this since when you publish Exchange, it needs to use 443 if you have SSL enable for publishing.

Also if you are just forwarding, then the permissions should resolve the issue.
0
 
nphsmithAuthor Commented:
No Wan management on the Sonicwall, I can see that would cause issues.

I sort of incline to thinking it is IIS-related, but maybe not permissions. The error:

HTTP code = MovedPermanently

Suggests some sort of redirection issue, but I can't find anything :(
0
 
Lance_PCommented:
Where did you get the certificates for exchange from? did you re-verify that they are installed correctly on both CAS?
0
 
nphsmithAuthor Commented:
Digcert, and yes as far as tests I have run can see they are indeed correctly installed. The exchange-connectivity tests are happy with the certificates (In fact, they do throw a warning that older versions of Windows Phone may not understand the certs, but I don't care about that, and can't think that's germane).
0
 
vishalvasuCommented:
There seems to be some issues when ExRCA is attempting to retrieve the XML Autodiscover response from the URL. Try the autodiscover URL into a browser. You should be asked for credentials. Provide the credentials for your mailbox and log in. Let us know the results.
0
 
nphsmithAuthor Commented:
Yes, I am asked for credentials:
<?xml version="1.0" encoding="UTF-8"?>
-<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> -<Response> -<Error Id="2027028260" Time="21:25:22.2860966"> <ErrorCode>600</ErrorCode> <Message>Invalid Request</Message> <DebugData/> </Error> </Response> </Autodiscover>
0
 
vishalvasuCommented:
Can you try "ignore" client certificates and disable require SSL in IIS 7 settings?
0
 
Lance_PCommented:
Hi nphsmith,
   Just need to reconfirm, did you verify the permissions on the Autodiscover virtual directory? and the others just to make sure?

Also did you change any default settings on ASP?
0
 
nphsmithAuthor Commented:
Yes, verified permissions on Autodiscover virtual directory.
No changes made to ASP - I actually wouldn't know how :).

@Vishal, I think this is thecase already,but will confirm when I get back to civilization (Still on Easter break with wibbly internet right now).
0
 
nphsmithAuthor Commented:
Vishal, I can confirm that SSL is not required, and Client certificates ignored,  on Default, web sites and Autosidscover & OAB Virtual directories. Any other Virtual Directories I should check?
0
 
Lance_PCommented:
Recheck the RPC and RPC proxy as well.
0
 
nphsmithAuthor Commented:
Rechecked RPC and RPCwithCert. There is no RPCProxy virtual folder - should there be?
0
 
Lance_PCommented:
RPCwithCert is the right folder. RPCproxy is the dll file within the directory.
0
 
nphsmithAuthor Commented:
Following Microsoft Patch Thursday and subsequent reboot last week, it is mysteriously working. <shrug> as to why and <worried> as to it breaking again.

Points awarded to Lance_P for continuing efforts to be helpful.
0
 
Lance_PCommented:
Thanks nphsmith. Everyday is a mystery with Microsoft. (Unless you browse through their endless bulletins )

Glad its resolved with the patch. Should be a good heads up for anyone who has the same issue.
0
 
nphsmithAuthor Commented:
Except...it broke again :(
0
 
Lance_PCommented:
This time round I'd say follow the first step and reset it. (with all updates since you have already patched)
0
 
nphsmithAuthor Commented:
That's current p[lan :)
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 15
  • 12
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now