Outlook 2013 Your automatic reply settings cannot be displayed because the server is currently unavailable.

You do not have an Autodiscover record setup. This needs to be in place for out of office to work. In your internal DNS you need an A record for autodiscover.domain.com to point to your exchange server's IP address. Externally you need the same thing. This can also be done by a PTR record and a SRV record but A record is the easiest to setup. If you don't have an SSL cert for your external access with autodiscover.domain.com then you will get a warning about this but an SRV record will no create a warning if you set it up correctly so it depends on your setup.

Unless your clients are not on the same domain as the Exchange server, the above answer is incorrect - an Autodiscover record is not required.
Internally clients do not use Autodiscover the same way as the do externally.

Internally they use the value of

get-clientaccessserver | select identity, autodiscoverserviceinternaluri

Check the host name on that result
a. resolves to Exchange.
b. is a host name on the SSL certificate
c. the ssl certificate is trusted.

If any of those are not correct then things will start to fail - such as OOTO.

OOTO is controlled by the availability service, which Outlook finds using Autodiscover.

Simon.

Sembee2, sorry but autodiscover is always used for out of office. Doesn't matter if the client is internal or external.

When outlook 2010 wants to set OOF, it communicates with 'Exchange Web Servises' (EWS) virtual firectory in IIS. Outlook 2010 does not know path to EWS virtual directory in IIS so it queries the autodiscover service on Exchange server 2010.

I think you may have misunderstood what i was saying. If they have an internal exchange server they need an internal autodiscover record for internal use and an external dns record for external use. If they do not have their own exchange server you are correct they don't need an internal record unless their domain is the same as their email domain. It is very situational.

I am able to switch to out of office mode in outlook 2010 though. but does not work in outlook 2013.

Start Here:

https://testconnectivity.microsoft.com/

Post whether results are successful or not.

"Sembee2, sorry but autodiscover is always used for out of office. Doesn't matter if the client is internal or external. "

I know that.

"I think you may have misunderstood what i was saying. If they have an internal exchange server they need an internal autodiscover record for internal use and an external dns record for external use. If they do not have their own exchange server you are correct they don't need an internal record unless their domain is the same as their email domain. It is very situational. "

That is wrong.
You need to read about how Autodiscover works.
Internal clients that are ON THE DOMAIN DO NOT USE AUTODISCOVER DNS RECORDS.
External clients who do not have their own Exchange server may well need internal DNS records for Autodiscover. However for most implementations it simply isn't required.
You can do it, it does no harm to do it, but it will not be used by the clients unless the value I have stated above is set to Autodiscover.example.com instead of the default of server.domain.local.

I hate to wave my credentials around, but in case you haven't noticed, I am an Exchange MVP, I am also the lead Exchange expert on this site, having clocked up over 25 MILLION points in the product. I know what I am on about.

Simon.

i ran the microsoft remote connnectivity analyer for outlook discover. it all failed.
Clipboard01.jpg

You need to get an autodiscover record added to your external DNS

Beware that the latest patch Tuesday (Automatic Reply / out of office)for OL2013 breaks that functionality,along with IMAP and free busy..

Thank you once again M$,for your stellar QA!

guys, when i do a test email autoconfiguration on OL2013 with only use autodiscover. everything passes.
please view screenshots
Clipboard01.jpg
Clipboard02.jpg
Clipboard03.jpg

anyone??

It is possible that your IIS settings are not correct. on the EWS site check your IIS settings to make sure they are correct.

I am not near my exchange server right now so i don't know what the correct settings are by default but make sure your auth settings are correct, you don't have an http redirect enable and ssl settings are correct. Sorry i can't be more help on this one but some research should dig it up.

Sembee2 ,being a MVP and all,are you guys giving M$ an earful on the last couple of patch Tuesdays that have so screwed up Ol2K13?

I spent about 10 hours trying to fix these past couple of lousy patches that I will never get paid for by my customers.

i removed those KB2837643 and KB2837618. rebooted and fired up the OL2013 again and still could not access OOO. but when I blew away the outlook profile and created a new profile, i was able to access OOO.

i have 200 users using OL2013 and i really dont want to recreate everyones profile again.

With 200+ users i would suggest only fixing those who really complain and just instruct everyone else to use OWA until Microsoft releases a fix for their crappy patch.

>i have 200 users using OL2013 and i really don't want to recreate everyone's profile again.

That's when something like Altiris or Zenworks comes in handy.

They revert back the patched dll that is causing the issue and you can automate the recreation of the users mail profiles.

I am Exchange MVP, not an Outlook MVP and therefore issues with Outlook aren't always on my radar.
This is a good write up on the problem:
http://helpdesk.missouristate.edu/news/two-microsoft-updates-cause-problems-with-outlook-2013

However it isn't widespread - I have two clients with Outlook 2013 deployed widely and they haven't reported any issues and these updates are installed.

Simon.

You guys (MVP's),might have a little more of MS's ear than myself (a lowly reseller),but it has reached a point where it is more likely that a patch Tuesday will disrupt my customers businesses more than the likely hood of a malware attack.

Susan Bradly sent a post  to Balmer after the last "black patch Tuesday" asking M$ to get their @#$$ together.

I have worked with a couple of MVP's in the past (Susan,Doug Spindler, Harry Brelsford and Ed Horley) and will be asking them to ratchet up the  pressure to provide real,stable patches and not some glorified hotfixes that you cross your fingers to and hope that they won't destabilize your IT infrastructure.

thank you so much

i dont get it. with the removal of those KBKB2837643 and KB2837618 and new profile. it was working and this week and stopped working again. i double checked to see if those KB was installed again and they are not.

Today is patch Tuesday,did anything install that was new?

You need to monitor this KB article:
http://support.microsoft.com/kb/2837618

The problems with Autodiscover are in the known issues. Another client has been told by Microsoft support that a fix is in the works, but it isn't public yet.

It is also listed in the known issues of the earlier update:
http://support.microsoft.com/kb/2825677

Simon.

The above "solution" worked for me as I had the same issue.

In case people are still having issues with this, you can try what i did to fix in my case:

User has two accounts with different domains.  OOO would work for the first account until I added the second account.  Then even after removing the second account it would display the subject message when trying to click automatic replies.  Finally I went to Credential Manager and deleted all the stored data that had to do with the second domain account.  After this, and recreating the profile with the first account, OOO now works.

Then I added the second account and it stored 3 different credentials in Credential Manager.  Two Windows crendentials and one generic.  I removed the one enterprise Windows credential that related to their autodiscover record (example.domain.com) and now it works.