I installed a number of updates on 12/22 and apparently one of them has broken the Out of Office functionality through Outlook. Out of Office works fine through OWA however. All client machines use Outlook 2007 or Outlook 2010 and the error message between these two is slightly different but essentially says the same thing. The Outlook 2010 error message states “Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later.” The Outlook 2007 error message states “Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later.” So far I am not aware of a single user who does not have this issue so it appears to be affecting everyone. The server is running Server 2003 and Exchange 2007 SP2. Some of the updates I installed were server updates and some were Exchange updates. I researched this and I found some reference to various DNS issues for autodiscover but since this worked before installing updates I am not inclined to think that DNS is the issue. I also found some older posts about this referencing .NET issues and some of the updates that installed were .NET updates, however those older posts also suggested that those issues were resolved with later .NET updates so I don’t know if that is the culprit here. Test email autoconfiguration results: <?xml version="1.0" encoding="utf-8"?> <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"> <User> <DisplayName>Matthew</DisplayName> <LegacyDN>/o=Our Business Name/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=matthew</LegacyDN> <DeploymentId>de4d494b-4833-44bd-a663-06ddcf735d26</DeploymentId> </User> <Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>EXCH</Type> <Server>ExchangeServer.OurDomain.local</Server> <ServerDN>/o= Our Business Name/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=ExchangeServer</ServerDN> <ServerVersion>720280B0</ServerVersion> <MdbDN>/o= Our Business Name/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=ExchangeServer/cn=Microsoft Private MDB</MdbDN> <PublicFolderServer> ExchangeServer.OurDomain.local </PublicFolderServer> <AD>dc1.OurDomain.local</AD> <ASUrl>https://webmail.OurPubliclyAccessibleDomainName.org/ews/exchange.asmx</ASUrl> <EwsUrl>https://webmail. OurPubliclyAccessibleDomainName.org/ews/exchange.asmx</EwsUrl> <OOFUrl>https://webmail. OurPubliclyAccessibleDomainName.org/ews/exchange.asmx</OOFUrl> <UMUrl>https://webmail. OurPubliclyAccessibleDomainName.org/unifiedmessaging/service.asmx</UMUrl> <OABUrl>https://webmail. OurPubliclyAccessibleDomainName.org/oab/91e015e8-66fb-430a-8328-637afc913182/</OABUrl> </Protocol> <Protocol> <Type>EXPR</Type> <Server>webmail. OurPubliclyAccessibleDomainName.org</Server> <SSL>On</SSL> <AuthPackage>Ntlm</AuthPackage> </Protocol> <Protocol> <Type>WEB</Type> <External> <OWAUrl AuthenticationMethod="Fba">https://webmail.OurPubliclyAccessibleDomainName.org/owa</OWAUrl> </External> <Internal> <OWAUrl AuthenticationMethod="Basic, Fba">https://webmail.OurPubliclyAccessibleDomainName.org/owa</OWAUrl> <Protocol> <Type>EXCH</Type> <ASUrl>https://webmail. OurPubliclyAccessibleDomainName.org/ews/exchange.asmx</ASUrl> </Protocol> </Internal> </Protocol> </Account> </Response> </Autodiscover> I am able to browse to the OOF URL https://webmail.OurPubliclyAccessibleDomainName.org/ews/exchange.asmx and the XML page loads after I supply my credentials (which incidentally are the same credentials I am using to login to the computer). It also appears that I am not the only one having this issue: http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/45bf7bfa-65f0-4371-82a7-7f173f04981a/ This may be relevant so I will mention it. Some time ago when I installed SP2 for Exchange 2007, my BIS blackberrys would no-longer validate. After researching the issue online I came upon a solution which was to change the authentication method on the EWS virtual directory from integrated to basic. It has been like that ever since (probably 8 months now) and the blackberrys have been working (and OOF was working as well). For testing purposes I did try changing this back and restarting IIS but this did not resolve these OOF issues so currently I have it set to basic again. Also, my internal domain name is of the format <CompanyInitials.local> (for example abc.local) and the publicly accessible domain name is <FullCompanyName.org> (for example ABigCompany.org). I have my autodiscover URL’s pointing at the public URL because the SSL cert for the default website has that public name and not the internal name. So for example if you browse to the internal URL https://ExchangeServer.abc.local/owa you get a certificate error since the certificate is for the public URL. I have the public name (ABigCompany.org) pointed to the Exchange server in my internal DNS. Maybe the problem is related to this?

Hi, Could you post the KB number of the installed updates? Please first follow these steps to narrow down the root cause: Step 1: ============== a. Open Outlook, on the windows notification area, right click outlook icon and choose "Test E-mail AutoConfirguation" b. Uncheck the options "Use Guessmart" and "Secure Guessmart Authentication". Click test. c. In Log tab, if outlook always fails to connect to autodiscover URL. Please move to the steps 2. d. If you are sucessfully connect to the Autodiscover service. Please click the Result tab and check the "OOF URL". Step 2: ============== a. Open EMS, type: Set-ClientAccessServer -Identity "YourCASserver" -AutoDiscoverServiceInternalUri https://cas01/autodiscover/autodiscover.xml Note; Please use the netbios name of the cas server as the url. b. Test the auto-configuration once again. If the issue persists, please help me to collect the following information for further research: ================= 1. Open Exchange Management Shell, type: get-exchange certificate |fl |out-file c:\certificate.txt get-webservices VirtualDirectory |fl |out-file c:\webservices.txt get-clientAccessserver |fl |out-file c:\cas.txt Then go to C drive, and send these three TXT files to me at v-genli#microsoft.com Gen Lin TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Thanks Gen Lin-MSFT

Based on what I have discovered this morning I may well be mistaken about the source of this issue being from updates. I may also be mistaken as to how long this has been broken. I had not had occasion to use it myself and I know people had been setting their OOF, but they may have been doing it through OWA for a long time now and only recently someone informed me about it not working in Outlook. But here is the information about the recently installed updates as far as I can tell. I misread the dates and had thought that .NET 2.0 and .NET 3.0 updates had been installed but the dates indicate that no updates were done for those two versions. The .NET framework 3.5 stuff doesn’t have install dates so I don’t know if anything was updated on that. Nor can I tell if any of the update rollups for Exchange Server 2007 Service Pack 2 were installed at that time since they do not have installation dates either. However since there are 5 of them and I installed SP2 for exchange on this server myself and I have only run updates on it 4 times since then, I suspect one or more of them may have been. Server updates that show that they were installed at that time are listed below by KB number. 2467659, 2443685, 2443105, 2440591, 977290, 2436673, 2423089, 2296199, 981550 Probably irrelevant but one IE 8 update was installed: KB2416400 So this morning I have discovered how to fix the original issue of the Outlook error messages when trying to use OOF. I re-enabled integrated authentication on the EWS virtual directory in IIS and changed it from accepting client certificates to ignoring them. As I mentioned in my original post I had changed this to basic months ago when I installed SP2 for Exchange 2007 which had broken the BIS blackberry synchronization. By changing the authentication method from integrated to basic, the blackberrys were able to validate once more but I now suspect that is when the OOF actually stopped working through Outlook. So between re-enabling the integrated authentication method and ignoring client certificates it seems to have fixed the OOF issues. Since I now have both integrated and basic authentication checked it looks like the BIS blackberrys are still working too thankfully.