Out of Office error: 'Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later.'

Question

Hi,
This is my first post in the forums. Please forgive me if it's in the wrong category or if it's not posted correctly in any way.
I'll try and give you below as much information about the problem we have here as I can.
What we have:
- an on-premises Windows 2012 Standard server that is the PDC, DNS and DHCP server;
- a second Windows 2012 Standard server with the sole purpose of hosting our Exchange 2013 CU7 server;
- Windows 7 PCs with Office Home and Business 2010 v.14.0.7143.5000 (32-bit);
- Outlook 2010 connects through Outlook Anywhere (mail.ourdomain.com).
The problem:
If trying to set up Out of Office through Outlook on the client PCs, we'd get an error message: 'Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later.' Interestingly, it does work normally for some users.
It works fine for all users if done through OWA.
Tests performed:
User 1 on PC1 has the problem. User 2 on PC2 doesn't have the problem. Both users are members of the same security groups.
- setting up User 2 on PC 1: the problem exists;
- setting up User 1 on PC 2: the problem exists;
- setting up a second Outlook profile on PC2 within User 2's domain account (the one that works), for the same User 2: the problem still exists!
I haven't been able to set up an Outlook account that works since this issue was discovered, although there are existing Outlook accounts that do not have the issue.
Let me also point out we have another issue we are working on and which may or may not be related: the Autodiscover function in Outlook doesn't work. Test E-mail AutoConfiguration results in 'Autoconfiguration was unable to determine your settings!'.
I can see postings in the Internet of other people having the same problem with OoO, but couldn't see a solution that fits my case: some existing accounts in Outlook are fine, other are not and newly created profiles of aforementioned working accounts do not
work. The majority of the articles/threads I read suggest recreating the Virtual Directories in Exchange, but we did that just a month ago (when troubleshooting the Autodiscover problem) and besides if the problem is in the Virtual Directories, I would expect
it to affect all accounts.
Any help in resolving this problem would be greatly appreciated. Please let me know if you need other details.
Apologies if the posting is not in the right place or not done properly - I'm still learning.

Answer 1

The IIS log files on the CAS might tell you something. Depending on how your proxy server handles NAT the IP address of your connection might be from the proxy server instead of your client.
In any case, a tool like Fiddler (http://www.telerik.com/fiddler) can be extremely helpful in working on problems like this because it can decode the SSL traffic on the client and you can see what's being sent
and what's being received.
Another thing to check (although it's unlikely to be your case) is whether or not your browser (when you try connecting to the autodiscover URL) thinks it's in the "Internet" zone. the "Local intranet", or at a "Trusted" site.
The domain names you use on machines on your LAN should be excluded from being proxyed. Anything with "." in the name will be set, unless excluded, to the proxy server.
Is the time correct on the client machine? Is it more than 5 minutes different to the Exchange machines and domain controllers? That'd be something that would cause Kerberos to fail.
A certificate can be a problem if its expired or if it doesn't have the correct names. But I wouldn't worry about the uglog.com domain just yet. Until you get the Autodiscover working with the SCP you have bigger problems.
If you've never used a WPAD file then don't worry about it. It's very useful if you have a complex network and you want to manage how browsers connect to servers. For example, if you have multiple proxy servers the each manage a different set of names, an/or
if some names should bypass proxy servers entirely and just connect directly. If run a strictly Microsoft network with only Microsoft product that you can manage with GPOs (and you can enforce those GPOs on every machine -- even the BYOD ones) you probably
don't need a WPAD.
--- Rich Matheisen MCSE&I, Exchange MVP