No free\busy information and Automatic replies - Exchange 2010

Posted on 2012-09-13
Last Modified: 2013-06-18
Hi Exchange Experts

I have the following issue and really need some expert advise please..

All Outlook 2007 + 2010 clients cannot view free\busy scheduling when booking meetings – No free\busy information could be retrieved. Your server location could not be determined.
All Outlook 2007 + 2010 Clients cannot set Automatic reply – Your Out of Office settings cannot be displayed, because the server is currently unavailable.

Microsoft Exchange 2010
Version - 14.02.0247.005  
Microsoft Exchange 2010 SP2 rollup 4

Automatic replies and free\busy scheduling works through OWA for all clients, but this cannot continue this way.

Could you please advise.
Question by:Gazza007
    LVL 35

    Expert Comment

    You may CTRL - right click the Outlook tray icon and select  Connection status.
    Check if there are issues...

    Have a look at your OAB (Organisation - Mailbox), where the OAB is published.
    Outllok 2003 SP2 and later can use http, older ones need public folders. If public folders are enabled, but not accessable, you get issues on the client.
    If  Web based enabled, check if the links under
    Server - Client Access  - OAB, if the links are correct there and reachable
    Make sure the link, outlook uses is interpreted as "Intranet". You can not access the link via a browser (acces denied), but you can see, if IE shows "Intranet" or "Internet".
    If the link is interpreted as "Internet", you may have a proxy issue.

    Author Comment

    Thanks, this is what I've checked thus far.

    Ran Get-WebServicesVirtualDirectory | fl   on EXCH Server 1 to verify and confirm output with “Test E-mail Auto-Configuration” from Outlook
    Verified the Availability Service of OOF and OAB Urls – Public Url is http://Company
    Ran the Microsoft Remote Connectivity Analyser on EXCH Server 1: - Web Services test for Synchronisation, Notification, Availability and Automatic replies OOF
    Status: Some Connectivity Tests Failed
    Ran the Microsoft Remote Connectivity Analyser on EXCH Server 2: - Outlook connectivity test for Outlook AutoDiscover
    Status: Failed
    Received AutoDiscover service errors on both connectivity tests.
    Ran Get-AutoDiscoverVirtualDirectory | fl   on EXCH Server 1 to verify if availability info and check if autodiscover has been configured correctly
    InternalUrl  on EXCH Server 1 is displayed but no ExternaUrl
    InternalUrl +ExternalUrl for EXCH Server 1 missing
    InternalUrl +ExternalUrl for EXCH Server 2 missing
    Checking DNS checks from external - Unknown can't find autodiscover - Non existant domain
    I can see that the certificate used for Exchange Outlook Web Access/App is a self signed certificate and has no common name. A SAN cert is required with the common name
    These tests were done from the external network/public internet.

    Hope this helps so far..
    LVL 37

    Accepted Solution


    Your first problem is that you cannot use a self-signed certificate with Outlook Anywhere. You need to purchase a SAN certificate with the following names
    internal name of CAS array

    LVL 35

    Expert Comment

    First at all, you need...
    DNS setting internal
    usually a CNAME record autodiscover --> internal exchange server.
    alternatively a A Record with name "autodiscover" and the IP of the exchange

    DNS setting external (has to be set at your internet provider)
    usually realized by a subdomain and user defined IP address
    register there under your ext_domain.tld the subdomain
    "yourexternalserver" and point the IP to your external IP address

    additionally you may register
    "autodiscover" and point the IP to your external IP address

    Exchange Management Console - Server - CAS
    Use "Configure External Client Access Domains... the result should look like

    internal: https://yourinternalserver.int_domain.tld/owa
    external: https://yourexternalserver.ext_domain.tld/owa
    internal: https://yourinternalserver.int_domain.tld/ecp
    external: https://yourexternalserver.ext_domain.tld/ecp
    internal: https://yourinternalserver.int_domain.tld/Microsoft-Server-ActiveSync
    external: https://yourexternalserver.ext_domain.tld/Microsoft-Server-ActiveSync
    internal: https://yourinternalserver.int_domain.tld/OAB
    external: https://yourexternalserver.ext_domain.tld/OAB

    Outlook AnyWhere

    The gateway (firewall to the external world) has to setup as reverse proxy with link translation configured with all external names. So https://yourinternalserver.int_domain.tld/owa has to be translated to

    Microsoft TMG makes everything automatically, all other firewalls have to translate:

    Translations for OWA:
    /public for public folders
    /Exchange for older clients

    Translations for Active Sync

    Translations for Outlook AnyWhere
    /autodiscover  can not run successfully, if external names are not configured correctly and external DNS names are not set. This tools test the external accessibility. To test internal autodiscover, --> CRTL - Outlook tray icon -- Test E-Mail AutoConfiguration.
    Within the certificates, all used names hast to be there:
    For internal access:
    yourinternalserver (if you want OWA to call it this way...
    autodiscover.int_domain.tld (if you use autodiscover internally)

    For external access:
    autodiscover.ext_domain.tld (if you use autodiscover externally)

    The external certificate names has to be implemented, where the external client accesses you network. I.e. if TMG is used, these names has to be in the certificate, which is connected with the web listener for OWA on TMG.

    Other firewalls depend on the configuration.
    If they just route through, they have to be added on the exchange certificate.
    If the firewall uses a listener port (NAT), you have to add a certificate with these names there (usual case).

    If you don't use external access, leave all the external names and settings out.

    Author Comment

    Thanks Bembi and JJ

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Why You Should Analyze Threat Actor TTPs

    After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

    Article by: Leon
    Software Metering within our group of companies has always been an afterthought until auditing of software and licensing became a pain point. Orchestrator and SCCM metering gave us the answer and it was an exciting process.
    Technology opened people to different means of presenting information, but PowerPoint remains to be above competition. Know why PPT still works today.
    The viewer will learn how to use the =DISCRINV command to create a discrete random variable, use this command to model a set of probabilities and outcomes in a Monte Carlo simulation, and learn how to find the standard deviation of a set of probabil…
    The viewer will learn how to create a normally distributed random variable in Excel, use a normal distribution to simulate the return on an investment over a period of years, Create a Monte Carlo simulation using a normal random variable, and calcul…

    737 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    18 Experts available now in Live!

    Get 1:1 Help Now