none
Autodiscover pointing to web site

    Frage

  • For some unknown reason, sometimes my Exchange 2010 users get a Certificate error when using Outlook Anywhere.  Just sometimes.  After much hair pulling, I got one of the users to open the certificate, and it is a Plesk certificate.  Oddly enough, I get the exact same certificate if I point to https://www.companyname.com.  I am at a loss as to how this happens.  I can only assume it is being directed there by AutoDiscover, but I have no idea why or how to fix this.

    Any help is appreciated.

    Sonntag, 17. Juni 2012 18:36

Antworten

  • Do you have a NLB or application firewall (TMG) between the clients and Exchange? Either of these could be configured incorrectly.

    Are client internal and joined to a domain in the same forest as Exchange 2010? 

    Do you have autodiscover.company.com setup in external DNS?

    Does EMS return the correct value when you run: Get-ClientAccessServer | ft name, AutoDiscoverServiceInternalUri

    • The above cmdlet will return the URL that domain joined clients will use

    External clients will use DNS to find the autodiscover URL, the addresses they try are hard coded to:

    • https://<smtp domain of user's primary e-mail address>/autodiscover/autodiscover.xml
    • https://autodiscover.<smtp domani>/autodiscover/autodiscover.xml

    Here's some good articles on how Autodiscover works and should help in troubleshooting the issue


    If this post helps to resolve your issue, please click the "Propose as Answer" If you find it helpful , mark it as helpful by clicking on "Vote as Helpful" button at the top of this message. By marking a post as Answered, or Helpful you help others find the answer faster. If you need an expert migration consultant to assist your organization feel free to contact me directly.

    Jason Sherry | Blog | Hire Me | Twitter: @JasonSherry
    Microsoft Infrastructure Architect, MCSE: M, MCTIP, Microsoft Exchange MVP

    Sonntag, 17. Juni 2012 19:22

Alle Antworten

  • Do you have a NLB or application firewall (TMG) between the clients and Exchange? Either of these could be configured incorrectly.

    Are client internal and joined to a domain in the same forest as Exchange 2010? 

    Do you have autodiscover.company.com setup in external DNS?

    Does EMS return the correct value when you run: Get-ClientAccessServer | ft name, AutoDiscoverServiceInternalUri

    • The above cmdlet will return the URL that domain joined clients will use

    External clients will use DNS to find the autodiscover URL, the addresses they try are hard coded to:

    • https://<smtp domain of user's primary e-mail address>/autodiscover/autodiscover.xml
    • https://autodiscover.<smtp domani>/autodiscover/autodiscover.xml

    Here's some good articles on how Autodiscover works and should help in troubleshooting the issue


    If this post helps to resolve your issue, please click the "Propose as Answer" If you find it helpful , mark it as helpful by clicking on "Vote as Helpful" button at the top of this message. By marking a post as Answered, or Helpful you help others find the answer faster. If you need an expert migration consultant to assist your organization feel free to contact me directly.

    Jason Sherry | Blog | Hire Me | Twitter: @JasonSherry
    Microsoft Infrastructure Architect, MCSE: M, MCTIP, Microsoft Exchange MVP

    Sonntag, 17. Juni 2012 19:22
  • There is a load balancing router in front of our Sonicwall TZ190.  It is managed by AT&T, so I have no visibility into it.

    Internal clients are in same domain as the exchange server

    Get-ClientAccessServer |fl shows proper server URL.

    External DNS is setup correctly and retuens the paths you mention.

    Remote Connectivity Alnalyser passes the Autodiscover check, but the one thing that it complains about, is that domainname.com isn't listed in the certificate.  Otherwise it passes.  It has a UCC certificate, and all other names are listed on it.  Is this likely the cause of this intermittent error? 

    Sonntag, 17. Juni 2012 19:38
  • If RCA is saying the certificate doesn't contain the name then external clients should be getting a certificate warning.

    Does your UC contain autodiscover.company.com?

    Do only internal or external clients get the error intermittently?  If it's an intermittent issue with only external clients I would suspect a firewall or LB issue, unless all client traffic is going though the NLB & FR.

    On your LAN, for the URL returned by Get-ClientAccessServer does the FQDN resolve to an internal IP, or does all client traffic go out and back though the NLB & FW?

    Do you only have 1 2010 CA server? If you have multiples do you also have an internal NLB in front of the CAS roles?


    If this post helps to resolve your issue, please click the "Propose as Answer" If you find it helpful , mark it as helpful by clicking on "Vote as Helpful" button at the top of this message. By marking a post as Answered, or Helpful you help others find the answer faster. If you need an expert migration consultant to assist your organization feel free to contact me directly.

    Jason Sherry | Blog | Hire Me | Twitter: @JasonSherry
    Microsoft Infrastructure Architect, MCSE: M, MCTIP, Microsoft Exchange MVP

    Sonntag, 17. Juni 2012 19:50
  • The external clients are Sometimes getting a certificate error, and it is a Pleask certificate, which has the sam exact dates, and match up with the certificate on the www site, which does not use SSL at all.

    The UC contains autodiscover.

    Only external clients ever get the cert error, but I can verify that the firewall is only forwarding ports to the exchange server.  The NLB, as I said, I have no visibility into.  I heve to do my best to clean my own house before I complain about someone elses house.

    On the LAN side, it gets the URL of Exchange10.domain.com, because we have split DNS.  The machine has the same internal and external names.

    We currently have only one exchange server.  We phased out a 2007 server about a year ago.  It's name was exchange.domain.com, and I just forwarded ports for that IP address to the new exchange server, for the sake of legacy web access.  (Easier than reteaching end users).

    Sonntag, 17. Juni 2012 20:00
  • I suspect it's a NLB issue. Many NLBs support SSL off-loading and therefore can be configured to intercept and modify SSL sessions, which can lead to certificate issues like you are having if configured incorrectly.

    Since you have split DNS and one Exchange I would assume all FQDN resolve to the single Exchange server and if no internal users are having the issue then it has to be the config of the NLB or FW.

    If possible have the network team configure the external address for Exchange to bypass the NLB and just go though the firewall to eliminate the NLB as the possible cause.

    If there are more than one NLBs it's possible one is configured incorrectly and is causing the intermittent issue. If there are more than 1 NLB see if you can get the network team to configure the rules so only one NLB handles the Exchange traffic, while troubleshooting the issue.


    If this post helps to resolve your issue, please click the "Propose as Answer" If you find it helpful , mark it as helpful by clicking on "Vote as Helpful" button at the top of this message. By marking a post as Answered, or Helpful you help others find the answer faster. If you need an expert migration consultant to assist your organization feel free to contact me directly.

    Jason Sherry | Blog | Hire Me | Twitter: @JasonSherry
    Microsoft Infrastructure Architect, MCSE: M, MCTIP, Microsoft Exchange MVP

    Sonntag, 17. Juni 2012 20:11
  • Actually, when I look at the certificate on the server, domain.com is actually listed, along with autodiscover, and the server FQDN.  But RCA doesn't see it.
    Sonntag, 17. Juni 2012 20:12
  • There is only one NLB, and there is no way to bypass it.  I guess I have to open a ticket with AT$T.  I hate that.  I went back and forth with them for 2 years with a customer whose PTP T1 failed every time it rained.  They kept saying it was my equipment, even though Cisco certified my config in writing.  Finally turned out to be a bad ground and 2 green hornets on their lines, and they ahd to replace the whole wire.
    Sonntag, 17. Juni 2012 20:18
  • Still say it's a NLB issue.

    If this post helps to resolve your issue, please click the "Propose as Answer" If you find it helpful , mark it as helpful by clicking on "Vote as Helpful" button at the top of this message. By marking a post as Answered, or Helpful you help others find the answer faster. If you need an expert migration consultant to assist your organization feel free to contact me directly.

    Jason Sherry | Blog | Hire Me | Twitter: @JasonSherry
    Microsoft Infrastructure Architect, MCSE: M, MCTIP, Microsoft Exchange MVP

    Montag, 18. Juni 2012 17:54
  • AT&T disagrees.  I think I have narrowed down the possible issue, but don't know exactly how to go about fixing it.  The external DNS has a wildcard - "*" that points to the www address, which is off-site.  When Autodiscover tries the wildcard, it goes to the web site, instead of to the exchange server.  I could point the wildcard to the Exchange server, but things like Google will often link to "domain.com", so that would break that, and the last thing we want is broken Google links and things.


    Any advice?

    Dienstag, 19. Juni 2012 16:11
  • DNS doesn't do anything with "wildcards" nor does Autodiscover goto a "wildcard" nor does Exchange not does Google. So don't follow what you are saying above.

    Certificates are loaded into NLB and computers. DNS controls what IP the FQDN will resolve to. When the component responding to the HTTPS session sees a connection coming it will response to the request with an SSL session. The client will validate (in most cases) that the FQDN being used is included in the SSL certificate that is being used to encrypt the HTTPS session.

    So Outlook Anywhere will start a session trying to contact Exchange at  https://company.com/autodiscover/autodiscover.xml, if that fails it will then try https://autodiscover.company.com/autodiscover/autodiscover.xml, if that fails it will then query DNS for an SRV record. (It will also try http:// for the 1st two)

    So the host (NLB or FW) or server responding needs to have the SSL cert loaded on it that included the FQDN the client is using. If using a SRV record the FQDN it is pointing to needs to be in the SSL cert.

    So from a client with an issue does autodiscover.company.com resolve to the IP of the firewall, that then sends the SSL traffic to the NLB which then sends traffic to Exchange?

    There could also be an issue with external DNS where it is returning the wrong IP address (ie for the main website) for autodiscover.company.com instead of the IP for the firewall that is handling the Exchange traffic.

    Clients will cache the IPs for a FQDN period of time, as will their ISP's DNS servers. So if you are testing this from a client you can do IPCONFIG /FlushDNS to refresh the client DNS cache, but you have no control over their ISPs DNS caching. So keep this in mind when testing. Do a ping or NSLOOKUP test from a client and then try it again 15+ minutes later. AT&T has multiple DNS servers so there could be one DNS server that has bad record for autodiscover.company.com that is causing the problem to be very intermittent. I have never seen this type of issue before, but that doesn't mean it's not possible.


    If this post helps to resolve your issue, please click the "Propose as Answer" If you find it helpful , mark it as helpful by clicking on "Vote as Helpful" button at the top of this message. By marking a post as Answered, or Helpful you help others find the answer faster. If you need an expert migration consultant to assist your organization feel free to contact me directly.

    Jason Sherry | Blog | Hire Me | Twitter: @JasonSherry
    Microsoft Infrastructure Architect, MCSE: M, MCTIP, Microsoft Exchange MVP

    Dienstag, 19. Juni 2012 16:34