locked
autodiscover broken since ISA replaced with TMG RRS feed

  • Question

  • Hi there,

    Our ISA server died around a month ago so we replaced it with a new TMG server. Exchange appeared to be running fine until late last week and now it only runs normally internally / while also connected via VPN. Around this time our wildcard cert was replaced with a new one (which has different private key) and this replacement seems to be applied to exchange correctly (shows new freindly name in IIS > RpcWithCert site> properties> certificate).
    I'm not sure if anything else has been changed, and I don't think we had SRV setup when it was working before

    Running the www.testexchangeconnectivity.com tool externally / disconnected from VPN gives the below output which failed on all 5x tests. Where would be the best place to start troubleshooting this?

     

    ExRCA is attempting to test Autodiscover for ouruser@ourdomain.com. Testing Autodiscover failed. 
     
    Test Steps
     	 
    Attempting each method of contacting the Autodiscover service.
     	The Autodiscover service couldn't be contacted successfully by any method.
     	 
    Test Steps
     	 
    Attempting to test potential Autodiscover URL https://ourdomain.com/AutoDiscover/AutoDiscover.xml
    
     	Testing of this potential Autodiscover URL failed.
     	 
    Test Steps
     	 
    Attempting to resolve the host name ourdomain.com in DNS.
     	The host name resolved successfully.
     	 
    Additional Details
     	IP addresses returned: 60. 234. 64. 106
    
     
    Testing TCP port 443 on host ourdomain.com to ensure it's listening and open.
     	The specified port is either blocked, not listening, or not producing the expected response.
    
    
     	 
    Additional Details
     	A network error occurred while communicating with the remote host.
    Exception details:
    Message: No connection could be made because the target machine actively refused it 60. 234. 64. 106 :443
    Type: System.Net.Sockets.SocketException
    Stack trace:
    at System.Net.Sockets.TcpClient.Connect(String hostname, Int32 port)
    at Microsoft.Exchange.Tools.ExRca.Tests.TcpPortTest.PerformTestReally()
    
    
    
     
    Attempting to test potential Autodiscover URL https://autodiscover.ourdomain.com/AutoDiscover/AutoDiscover.xml
    
     	Testing of this potential Autodiscover URL failed.
     	 
    Test Steps
     	 
    Attempting to resolve the host name autodiscover.ourdomain.com in DNS.
     	The host name couldn't be resolved.
    
    
     	 
    Additional Details
     	Host autodiscover.ourdomain.com couldn't be resolved in DNS Exception details:
    Message: The requested name is valid, but no data of the requested type was found
    Type: System.Net.Sockets.SocketException
    Stack trace:
    at System.Net.Dns.GetAddrInfo(String name)
    at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
    at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
    at Microsoft.Exchange.Tools.ExRca.Tests.ResolveHostTest.PerformTestReally()
    .
    
    
    
     
    Attempting to contact the Autodiscover service using the HTTP redirect method.
     	The attempt to contact Autodiscover using the HTTP Redirect method failed.
     	 
    Test Steps
     	 
    Attempting to resolve the host name autodiscover.ourdomain.com in DNS.
     	The host name couldn't be resolved.
    
    
     	 
    Additional Details
     	Host autodiscover.ourdomain.com couldn't be resolved in DNS Exception details:
    Message: The requested name is valid, but no data of the requested type was found
    Type: System.Net.Sockets.SocketException
    Stack trace:
    at System.Net.Dns.GetAddrInfo(String name)
    at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
    at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
    at Microsoft.Exchange.Tools.ExRca.Tests.ResolveHostTest.PerformTestReally()
    .
    
    
    
     
    Attempting to contact the Autodiscover service using the DNS SRV redirect method.
     	ExRCA failed to contact the Autodiscover service using the DNS SRV redirect method.
     	 
    Test Steps
     	 
    Attempting to locate SRV record _autodiscover._tcp.ourdomain.com in DNS.
     	The Autodiscover SRV record wasn't found in DNS.

     



    • Edited by JeremyA6 Monday, May 30, 2011 10:14 PM
    Monday, May 30, 2011 9:17 PM

Answers

  • Hello,

     

    Since the autodiscover works for internal clients, it’s obviously the issue should be more related to the settings on the TMG. Please refer to the following articles to achieve Exchange autodiscover.

     

    http://msexchangeteam.com/archive/2009/12/17/453625.aspx

     

    http://www.isaserver.org/tutorials/Publishing-Exchange-2007-Outlook-Autodiscover-2006-ISA-Firewalls.html

     

    If you need more help to configure the TMG, I suggest we create a new thread to the TMG forum.

     

    http://social.technet.microsoft.com/Forums/en-US/Forefrontedgegeneral/threads

     

    Thanks,

    Simon

    Thursday, June 2, 2011 2:48 AM

All replies

  • On Mon, 30 May 2011 21:17:57 +0000, JeremyA6 wrote:
     
    >
    >
    >Hi there,
    >
    >Our ISA server died around a month ago so we replaced it with a new TMG server. Exchange appeared to be running fine until late last week and now it only runs normally internally / while also connected via VPN. Around this time our wildcard cert was replaced with a new one (which has different private key) and this replacement seems to be applied to exchange correctly (shows new freindly name in IIS > RpcWithCert site> properties> certificate). I'm not sure if anything else has been changed, and I don't think we had SRV setup when it was working before
    >
    >Running the www.testexchangeconnectivity.com tool externally / disconnected from VPN gives the below output which failed on all 5x tests. Where would be the best place to start troubleshooting this?
    >
    > ExRCA is attempting to test Autodiscover for ouruser@ourdomain.com. Testing Autodiscover failed.
    >
    >Test Steps
    >
    >Attempting each method of contacting the Autodiscover service.
    > The Autodiscover service couldn't be contacted successfully by any method.
    >
    >Test Steps
    >
    >Attempting to test potential Autodiscover URL https://ourdomain.com/AutoDiscover/AutoDiscover.xml
    >
    > Testing of this potential Autodiscover URL failed.
    >
    >Test Steps
    >
    >Attempting to resolve the host name ourdomain.com in DNS.
    > The host name resolved successfully.
    >
    >Additional Details
    > IP addresses returned: 60.234.64.106
    >
    >
    >Testing TCP port 443 on host ourdomain.com to ensure it's listening and open.
    > The specified port is either blocked, not listening, or not producing the expected response.
     
    I don't thinkthis has anything to do with your certificate.
     
    The IP address is listening on port 80. It's not listening on port
    443.
     
    The IP address PTR record returns mail dot xmail dot co dot nz.
     
    There's no A record for autodiscover dot xmail dot co dot nz. And your
    domain probably isn't "ourdomain.com". So, unless you're goint to
    state whatr your domain name is, the assumption has to be that you've
    simply neglected to publish the autodiscover dot xmail dot co dot nz
    rule in TMZ and the associated A record in your DNS.
     
    If that's not the case, then you've neglected to publish the xmail dot
    co dot nz / autodiscover URL in TMZ.
     
    Either way, there's "nobody home" to answer the door when somone
    knocks on 60.234.64.106:443.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Monday, May 30, 2011 9:43 PM
  • Thanks Rich - the IP 60. 234. 64. 106 is our spam filtering service in WAN. We did make a change there also around the same time problems occurred with autodiscover / OOF so I'm thinking maybe the firewall there needs additional rules [re]setup..

    Do you have a link to a good succinct guide on configuring this as I'm not an expert on installing exchange and would need to get this sorted quickly?

    I also notice there is no Exchange RPC Server allow access rule setup on our TMG server so what would be theimplecations of this?

    Thanks,
    Jeremy


    Monday, May 30, 2011 10:28 PM
  • On Mon, 30 May 2011 22:28:22 +0000, JeremyA6 wrote:
     
    >Thanks Rich - the IP 60. 234. 64. 106 is our spam filtering service in WAN.
     
    If that's true then there probably isn't any CAS at that IP address.
     
    >We did make a change there also around the same time problems occurred with autodiscover / OOF so I'm thinking maybe the firewall there needs additional rules [re]setup..
     
    Not knowing how your DNS is set up, where you have the different
    services, etc. I can only guess at what to tell you. So, my guess
    would be that you need to put an A record in your DNS for
    autodiscover.yourdomain.com that resolves to the IP address of your
    TMG server.
     
    The TMG probably has a wizard to create the publishing rules for
    Exchange 2010, but it it was working with TMG and then stopped
    working, it's probably a DNS change that's at the root of things.
     
    Based on what you're describing, I'm going to guess again that you
    changed your domain's DNS "A" record from your old ISA server to your
    spam filtering service. You only need the MX record(s) for your domain
    to refer to the spam filtering service. If they also host your
    company's web site then that's probably why they changed the domain's
    A record and killed AutoDiscover (and OWA, Outlook Anywhere,
    Auodiscover, etc.).
     
    >Do you have a link to a good succinct guide on configuring this as I'm not an expert on installing exchange and would need to get this sorted quickly?
    >
    >I also notice there is no Exchange RPC Server allow access rule setup on our TMG server so what would be theimplecations of this?
     
    Running the aforementioned wizard on the TMG will fix that (if you
    haven't already done that) -- once you get your external DNS
    rearranged so the name you use can be resolved to your TMG.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Tuesday, May 31, 2011 2:32 AM
  • Sorry I'm still learning how everything is setup myself..

    Apparently we don't have autodiscovery available externally for security reasons but should still be working internally, so the heading of this discussion is misleading. I'll change it once we've resolved the issue. You're right that we don't have any publishing rules or public DNS records for autodiscover - we may look into setting this up later..

    I believe the replacement wildcard certificate used by exchange was installed via IIS, and I'm told this will cause issues and that we need to install via EMC. I'm digging around how to do this and have only found articles like this on setting up certs with SANs / via PowerShell..

    Tuesday, May 31, 2011 6:08 AM
  • Hi,

    The certificate used is a wildcard cert with no SANs - would this be causing the OOF issue and problem creating new outlook profiles externally?

    Does it still neeed to be loaded into exchange via EMC or powershell cmdlet only (so problem wouldn't been it loaded via IIS)?

    Tuesday, May 31, 2011 9:09 PM
  • On Tue, 31 May 2011 06:08:58 +0000, JeremyA6 wrote:
     
    >Sorry I'm still learning how everything is setup myself..
    >
    >Apparently we don't have autodiscovery available externally for security reasons
     
    What security issues are you worried about?
     
    >but should still be working internally, so the heading of this discussion is misleading.
     
    Start Outlook. Then Ctrl+Right-Click the Outlook icon in the system
    tray. Select the "Test E-mail AutoConfiguration..." choice. Uncheck
    the two "guessmart" boxes and click "Test". The "Results" and "Log"
    tabs will show you where things are failing.
     
    >I'll change it once we've resolved the issue. You're right that we don't have any publishing rules or public DNS records for autodiscover - we may look into setting this up later..
     
    Well, that's a pretty good reason why using
    http://testexchangeconnectivity.com fails. :-)
     
    >I believe the replacement wildcard certificate used by exchange was installed via IIS, and I'm told this will cause issues and that we need to install via EMC. I'm digging around how to do this and have only found articles like this on setting up certs with SANs / via PowerShell..
     
    Use the enable-exchangecertificate cmdlet if the certificate is
    already installed in the certificate store for the system account.
     
    enable-exchangecertificate <thumbprint> -services IIS,SMTP,IMAP,POP
     
    You can add "UM" to the list of services if you're using Unified
    Messaging.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, June 1, 2011 2:21 AM
  • Thanks Rich,

    I tried the
    enable-exchangecertificate <corresponding private key thumbprint> -services IIS,SMTP,IMAP,POP
    with the cert that shows is IIS and also under MMC > certs > computer account > local computer > personal
    This however has a different thumbprint to the widlcard cert used on our TMG server so I'm now suspecting this could be part of the problem..

    I tried replacing TMG lister cert now with newer cert exported from exchange, haven't restarted the exchange server / services, but the OOF problem and external outlook exchange account creation still failed. This also caused our OWA to fail with revoked cert error, so have reverted TMG back to orignal cert thats not used on exchange (as exchnage doesnt have this private key).

    Also the outlook autodiscover test is failing while connected to domain / vpn (don't think it was before)

    Any other suggestions?




    Wednesday, June 1, 2011 9:13 PM
  • On Wed, 1 Jun 2011 21:13:04 +0000, JeremyA6 wrote:
     
    >
    >
    >Thanks Rich,
    >
    >I tried the enable-exchangecertificate <thumbprint> -services IIS,SMTP,IMAP,POP with the cert that shows is IIS and also under MMC > certs > computer account > local computer > personal This however has a different thumbprint to the widlcard cert used on our TMG server so I'm now suspecting this is the problem.. Will try replacing this now
    >
    >Haven't restarted the exchange server / services but the OOF problem and external outlook exchange account creation fails
    >
    >Also the outlook autodiscover test is failing while connected to domain / vpn (don't think it was before)
    >
    >Any other suggestions?
     
    If it was working before you ran the enable-exchangecertificate I'd
    expect that the cerrificate you enabled may be expired.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, June 1, 2011 11:52 PM
  • Hello,

     

    Since the autodiscover works for internal clients, it’s obviously the issue should be more related to the settings on the TMG. Please refer to the following articles to achieve Exchange autodiscover.

     

    http://msexchangeteam.com/archive/2009/12/17/453625.aspx

     

    http://www.isaserver.org/tutorials/Publishing-Exchange-2007-Outlook-Autodiscover-2006-ISA-Firewalls.html

     

    If you need more help to configure the TMG, I suggest we create a new thread to the TMG forum.

     

    http://social.technet.microsoft.com/Forums/en-US/Forefrontedgegeneral/threads

     

    Thanks,

    Simon

    Thursday, June 2, 2011 2:48 AM