none
MS Exchange 2007 OOF and Autodiscover Issues RRS feed

  • Question

  •  

    Hi Guys,

     

    I have been having issues setting up and accessing MS Exchange 2007 Webservices, thats is when I try to access OOF from Outlook 2007, It keeps saying, "Server is unavailable", if I try to update the Address book it gives me an object can not be found error (0x8004010f) message. We constantly get pop-ups to type in our Outlook 2007 credentials. The problem first started when the System Admin I took over from tried to set up Outlook Anywhere about 7 weeks ago. At first it was intermittent in the sense that, one could access their OOF spontaneously throughout the day, now everyone in the organistaion can't. I have tried to check the Autodiscover settings but it says Autodiscover has failed for every and any user. Since I took over as Sys Admin I have been trying to get things going but so far no luck.

     

    We have a 3rd Party certificate (In my example I will call our internal domain trev.local and external web as www.trev.com) Our 3rd Party certificate subject name is mail.trev.com - it is issued to trev.local, mail.trev.com, autodiscover.trev.com and our internal FQDN for the exchange server is server.trev.local (assuming Exchange server name is Server). I have checked everything in IIS and all looks fine. Our ISP's who host our www.trev.com site created DNS settings which we set up in our Secondary zone. That is autodiscover.trev.com that points to mail.trev.com and SRV Record autodiscover also. For some reason I think I am missing something. Please can someone assist me.

     

    get-clientaccessserver

    Name
    ----
    Server

    I checked Autodiscover via Outlook's Test email Configuration and it shows the following:

    864    608707102    07/22/11 09:03:30    Attempting URL https://server.trev.local/autodiscover/autodiscover.xml found through SCP
    864    608707102    07/22/11 09:03:30    Autodiscover to https://server.trev.local/autodiscover/autodiscover.xml starting
    864    608707399    07/22/11 09:03:30    Autodiscover to https://server.trev.local/autodiscover/autodiscover.xml FAILED (0x80072F0C)

     

    test-outlookwebservices

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

    Id      : 1007
    Type    : Information
    Message : Testing server server.trev.local with the published name https://server.trev.local/EWS/Exchange.asmx & https://mail.trev.com/EWS/Exchange.a
              smx.

    Id      : 1019
    Type    : Information
    Message : Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://server.trev.local/autodiscover/autodiscover.xml.

    Id      : 1006
    Type    : Information
    Message : The Autodiscover service was contacted at https://server.trev.local/autodiscover/autodiscover.xml.

    Id      : 1016
    Type    : Success
    Message : [EXCH]-Successfully contacted the AS service at https://server.trev.local/EWS/Exchange.asmx. The elapsed time was 65 milliseconds.

    Id      : 1015
    Type    : Success
    Message : [EXCH]-Successfully contacted the OAB service at https://server.trev.local/EWS/Exchange.asmx. The elapsed time was 0 milliseconds.

    Id      : 1014
    Type    : Success
    Message : [EXCH]-Successfully contacted the UM service at https://server.trev.local/unifiedmessaging/service.asmx. The elapsed time was 999 milliseconds.

    Id      : 1013
    Type    : Error
    Message : When contacting https://mail.trev.com/EWS/Exchange.asmx received the error The request failed with HTTP status 401: Unauthorized.

    Id      : 1016
    Type    : Error
    Message : [EXPR]-Error when contacting the AS service at https://mail.trev.com/EWS/Exchange.asmx. The elapsed time was 499 milliseconds.

    Id      : 1015
    Type    : Success
    Message : [EXPR]-Successfully contacted the OAB service at https://mail.trev.com/EWS/Exchange.asmx. The elapsed time was 0 milliseconds.

    Id      : 1014
    Type    : Success
    Message : [EXPR]-Successfully contacted the UM service at https://mail.trev.com/unifiedmessaging/service.asmx. The elapsed time was 42 milliseconds.

    Id      : 1013
    Type    : Error
    Message : When contacting https://mail.trev.com/Rpc received the error The remote server returned an error: (403) Forbidden.

    Id      : 1017
    Type    : Error
    Message : [EXPR]-Error when contacting the RPC/HTTP service at https://mail.trev.com/Rpc. The elapsed time was 101 milliseconds.

    Id      : 1006
    Type    : Success
    Message : The Autodiscover service was tested successfully.

    Id      : 1021
    Type    : Information
    Message : The following web services generated errors.
                  As, in EXPR
                  Contacting server in EXPR
              Please use the prior output to diagnose and correct the errors.

    The online www.testexchangeconnectivity.com shows the following errors:

    1.)

    Testing the SSL certificate to make sure it's valid.
      The SSL certificate failed one or more certificate validation checks.
     
    Test Steps
     
    ExRCA is attempting to obtain the SSL certificate from remote server trev.com on port 443.
      ExRCA wasn't able to obtain the remote SSL certificate.
     
    Additional Details
      The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
    Attempting to test potential Autodiscover URL https://autodiscover.trev.com/AutoDiscover/AutoDiscover.xml
      Testing of this potential Autodiscover URL failed.

    2.) Attempting to test potential Autodiscover URL https://mail.trev.com/Autodiscover/Autodiscover.xml
         Testing of this potential Autodiscover URL failed.
        
        Test Steps
        
        Attempting to resolve the host name mail.trev.com in DNS.
         The host name resolved successfully.
        
        Additional Details
         IP addresses returned: 1xx.xxx.xxx.xxx
        Testing TCP port 443 on host mail.trev.com to ensure it's listening and open.
         The port was opened successfully.
        Testing the SSL certificate to make sure it's valid.
         The SSL certificate failed one or more certificate validation checks.
        
        Test Steps
        
        ExRCA is attempting to obtain the SSL certificate from remote server mail.trev.com on port 443.
         ExRCA wasn't able to obtain the remote SSL certificate.
        
        Additional Details
         The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.

     

    A test Exchange Certificate returns:

    AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccess
                         Rule}
    CertificateDomains : {mail.trev.com, autodiscover.trev.com, trev.com, trev.local, remote.trev.com, server.trev.local}
    HasPrivateKey      : True
    IsSelfSigned       : False  

    Can someone please tell me what the problem is? Is it a SSL Certificate misconfiguration or Autodiscover. Do I have to create any autodiscover record in the local trev.local DNS Zone? Pleasekindly assist.

    If you notice I change the Autodiscover Internal Url and webservicesvirtualdirectory to https://server.trev.local from mail.trev.com is this right? We are using a 3rd party certie as mentioned above with IMAP, POP, SMTP and IIS services.

    Please kindly assist. Thank you in advance


    Monday, July 25, 2011 3:50 PM

Answers

  • Hi Fiona,

    Apologies for the late response. Thank you very much for your assistance. I eventually resolved the issue by deleting the SBS Web App Virtual Directories in IIS and recreated them from scratch.

    The settings where messed up and the directories were corrupt. I used the following guide: How to recreate Exchange Virtual Directories.

    Post can be closed

     

     

     

     

     


    TechnoTrev
    • Marked as answer by Trevor Murimba Wednesday, August 17, 2011 11:00 AM
    Wednesday, August 17, 2011 11:00 AM

All replies

  • Hi,

     

    Here are my finds and suggestion:

     

    1.    The autodiscover service internal URL https://server.trev.local/autodiscover/autodiscover.xml was found through SCP; this is correct.

     

    2.    The internal URL above is resolved successfully but not accessible due to error 0x80072F0C, which means ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED; what’s why you are not able to access OOF and OAB in Outlook.

     

    However, you asked about if you should create a DNS record, so I guess the URL is pointing to another server instead of your CAS server.

     

    Therefore, I suggest you ping the URL above and make sure it is pointing to your CAS server’s internal IP address.

     

    3.    Regarding the Online test, it is a normal test and we need to analize the outcome with other test.

     

    I tested the URL https://trev.com & https://autodiscover.trev.com/AutoDiscover/AutoDiscover.xml; it returned different web pages, which are NOT expected.

     

    Moreover, it displays a certificate mismatch error, where *.gridserver.com is used.

     

    My suggestion is:

     

    a). Verify your External DNS record, and make sure the URL https://trev.com & https://autodiscover.trev.com/AutoDiscover/AutoDiscover.xml is pointing to the external IP address of your CAS server.

    b). Verify your CAS server’s virtual directory, make sure there is no any redirection or web application. Note that, an Exchange server should not contain any web application.

    c). Verify the certificate installed on your CAS server. See step5.

     

    4.    You received error 1016, 1013 & 10017, which is pointing to the external URL of the availability service and the URL of Outlook Anywhere; this may occur if the virtual directories is not correctly setup, or the certificate related issue.

     

    So, I’d suggest you verify the permission settings. See “Default settings for Exchange-related virtual directories in Exchange Server 2007”.

     

    Besides, verify and make sure the certificate for mail.trev.com is installed on the CAS server.  

     

    5.    The outcome returned by the certificate test appears normal, the CN name is correct. However, there is not service items displays.

     

    So, run Get-ExchangeCertificate again on the CAS server, make sure this certificate with the CN names listed is enabled for IIS service. 

     

     

    Good luck.

     


    Fiona

    Wednesday, July 27, 2011 8:36 AM
    Moderator
  • Hi Fiona,

     

    Thank you for taking the time to assist me resolve my problem. I clicked on quote so I can basically tell you what I have done so far at/ for each point you mentioned earlier.

     

     

    "Hi,

     

    Here are my finds and suggestion:

     

    1.    The autodiscover service internal URL https://server.trev.local/autodiscover/autodiscover.xml was found through SCP; this is correct.

     

    (Okay, I wasn't really sure whether the Internal URL should point to the Internal CAS Server or external (that which is hosted by our ISP)) But basically I configured it to point to the FQDN that is running our Exchange Server - Please Note: We only have one physical server that runs everything, by everything I mean its roles are A.D, DNS, DHCP, Exchange (CAS, Mailbox, Hub & Unified Messaging Roles) I can browse to the link which after logging in with Admin credentials for testing purposes it shows me the following below: What does this mean?

     

     

    <?xml version="1.0" encoding="utf-8" ?>
    - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    - <Response>
    - <Error Time="14:02:43.7280000" Id="2177044700">
      <ErrorCode>600</ErrorCode>
      <Message>Invalid Request</Message>
      <DebugData />
      </Error>
      </Response>
      </Autodiscover>


    2.    The internal URL above is resolved successfully but not accessible due to error 0x80072F0C, which means ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED; what’s why you are not able to access OOF and OAB in Outlook.


     

    However, you asked about if you should create a DNS record, so I guess the URL is pointing to another server instead of your CAS server.

     

    (Basically we have 2 Zones in DNS (trev.local & trev.com) - One had its entries created by our service provider (trev.com is the Secondary DNS Zone) - that has records that point to our External Domain (Our Domain is accessible on the internet via www.trev.com) which points to their external I.Ps to ISP who host our site. We requested them to created an Autodiscover SRV record that is under Secondary Domain Zone trev.com and whose offering service is mail.trev.com and CNAME Record whose alias is autodiscover - FQDN is autodiscover.trev.com and target host mail.trev.com, that is externally. (we can't create any records under this zone that is why we asked our ISP DNS Admins to do it for us)

     

    At the moment we do not have any autodiscover entries residing on our local DNS Zone (trev.local). That is the reason why I was asking whether I should create a an Autodiscover SRV record that is under the AD local Domain Zone trev.local and whose offering service is  server.trev.local (The server running our Exchange) and CNAME Record whose alias is autodiscover - FQDN is autodiscover.trev.local and target host server.trev.local? Am I right by saying this. I tried it for testing purposes but did not come out right.

     

    Therefore, I suggest you ping the URL above and make sure it is pointing to your CAS server’s internal IP address.

     

     What do you mean ping the url above? I can ping the server, that is  server.trev.local  but not https://server.trev.local/autodiscover/autodiscover.xml  I can only browse to it like I mentioned in point 1.  


     

    3.    Regarding the Online test, it is a normal test and we need to analize the outcome with other test.

     

    I tested the URL https://trev.com & https://autodiscover.trev.com/AutoDiscover/AutoDiscover.xml; it returned different web pages, which are NOT expected.

     

    *********(About the two links https://trev.com & https://autodiscover.trev.com/autodiscover/Autodiscover.xml) the name trev.com is fictitious I mentioned that before and had it look like this for security reasons but if you need the actual domain name let me know and I can send you the actual details. I basically substituted the actual server name with server & the actual domain name with trev Apologies for that*********

     

    Moreover, it displays a certificate mismatch error, where *.gridserver.com is used.

     

    (My bad, let me know if you need the actual domain name and the original logs, you can drop me an email at hontaz@yahoo.com and I will send you the actual logs)

     

    My suggestion is:

     

    a). Verify your External DNS record, and make sure the URL https://trev.com & https://autodiscover.trev.com/AutoDiscover/AutoDiscover.xml is pointing to the external IP address of your CAS server.

     

    The External DNS Record points to our ISP who have MX Records that point to us


    b). Verify your CAS server’s virtual directory, make sure there is no any redirection or web application. Note that, an Exchange server should not contain any web application.

     

    Our Exchange server also runs IIS, I am not sure what you mean by should not contain any web Application.


    c). Verify the certificate installed on your CAS server. See step5.

     

    The Certificate is installed fine on our Server. If I run the Powershell Get-ExchangeCertificate is shows that the following:

     

    9786534ECCC7299161B7B48DC6F9  IP.WS      CN=mail.trev.com (Please Note: CN note the actual one and the Thumbprint) but as you can see is meant for SMTP, WEB e.t.c

     

    4.    You received error 1016, 1013 & 10017, which is pointing to the external URL of the availability service and the URL of Outlook Anywhere; this may occur if the virtual directories is not correctly setup, or the certificate related issue.

     

    So, I’d suggest you verify the permission settings. See “Default settings for Exchange-related virtual directories in Exchange Server 2007”.

     

    Though I would try this after more suggestions from you, as I have to rectify point 1,2 & 3 first

     

    Besides, verify and make sure the certificate for mail.trev.com is installed on the CAS server.  

     

    The Certificate for mail.trev.com is Installed, I also see it under Certificates in IIS

     

    5.    The outcome returned by the certificate test appears normal, the CN name is correct. However, there is not service items displays.

     

    We purchased a 3rd party Certificate via Entrust. It is issued to trev.local, mail.trev.com, autodiscover.trev.com and our internal FQDN for the exchange server - server.trev.local (assuming Exchange server name is Server).


    So, run Get-ExchangeCertificate again on the CAS server, make sure this certificate with the CN names listed is enabled for IIS service. 

     

    I checked IIS certificates it is added and also binded to the SBS Web App Site

     

     

    Good luck.

     


    Fiona



    TechnoTrev
    Thursday, July 28, 2011 1:45 PM
  • Hi TechnoTrev,

     

    Thanks for your update.

     

    Do you mean the Exchange 2007 server is installed on SBS server? If it is the scenario, you need to submit a new thread for this issue in SBS forum here. . As you may see that there are many error related to certificate, to install the certificate correctly, we need to use SBS wizard, which is not familier in this forum. Your understanding would be appreciated.

     

    If the Exchange server is not install on SBS server, let’s start from internal to troubleshoot the OOF and Autodiscover issue. And my suggestion is:

     

    1.    Error code 600 for Autodiscover URL is expected result, we don’t need to worry about it.

    2.    Verify the virtual directories to make sure the correct permission settings.

    3.    Verify the certificate via cmdlet Get-ExchangeCertificate. You might get one or more certificates returned. Locate the certificate with the name of mail.trev.com and check to see the service, make sure it contains IIS service (if the service is not enabled, you may see there is …).

     

    Hope it is useful.

     

    Regarding the WEB page, it is not recommended to install other web application in CAS server, since it might cause confusions and make it complex for troubleshooting. If it is a SBS server (or it is limit for internet-facing server), create a new web site and bind to another IP address to separate different web applications.

     


    Fiona
    Friday, July 29, 2011 3:26 AM
    Moderator
  • Hi Fiona,

    Apologies for the late response. Thank you very much for your assistance. I eventually resolved the issue by deleting the SBS Web App Virtual Directories in IIS and recreated them from scratch.

    The settings where messed up and the directories were corrupt. I used the following guide: How to recreate Exchange Virtual Directories.

    Post can be closed

     

     

     

     

     


    TechnoTrev
    • Marked as answer by Trevor Murimba Wednesday, August 17, 2011 11:00 AM
    Wednesday, August 17, 2011 11:00 AM
  • Hi,

    Thanks  for your update and sharing with  your experience. It is good to know the issue is resolved.

    Have a nice day.


    Fiona
    Thursday, August 18, 2011 5:56 AM
    Moderator