We are experiencing an issue with one of our clients where the out of office service will not function within outlook. This persists throughout the network, and every user seems to have this problem. The message that outlook displays upon trying to access the OOF settings is the following: "Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later." However, OOF works as if there were no issue when accessed from OWA. When running a test-outlookwebservices from the server, the following output is generated: Id : 1003 Type : Information Message : About to test AutoDiscover with the e-mail address [user]@[domain].eu. Id : 1007 Type : Information Message : Testing server SRV01.[domain].local with the published name https://remo te.[domain].eu/ews/exchange.asmx & https://remote.[domain].eu/EWS/Exchange. asmx. Id : 1019 Type : Information Message : Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://remote.[domain].eu/autodiscover/autodisco ver.xml. Id : 1006 Type : Information Message : The Autodiscover service was contacted at https://remote.[domain].eu/aut odiscover/autodiscover.xml. Id : 1016 Type : Success Message : [EXCH]-Successfully contacted the AS service at https://remote.[domain]. eu/ews/exchange.asmx. The elapsed time was 265 milliseconds. Id : 1015 Type : Success Message : [EXCH]-Successfully contacted the OAB service at https://remote.[domain] .eu/ews/exchange.asmx. The elapsed time was 0 milliseconds. Id : 1014 Type : Success Message : [EXCH]-Successfully contacted the UM service at https://remote.[domain]. eu/unifiedmessaging/service.asmx. The elapsed time was 31 millisecond s. Id : 1016 Type : Success Message : [EXPR]-Successfully contacted the AS service at https://remote.[domain]. eu/EWS/Exchange.asmx. The elapsed time was 46 milliseconds. Id : 1015 Type : Success Message : [EXPR]-Successfully contacted the OAB service at https://remote.[domain] .eu/EWS/Exchange.asmx. The elapsed time was 0 milliseconds. Id : 1014 Type : Success Message : [EXPR]-Successfully contacted the UM service at https://remote.[domain]. eu/UnifiedMessaging/Service.asmx. The elapsed time was 31 millisecond s. Id : 1013 Type : Error Message : When contacting https://SRV01/Rpc received the error The server committed a protocol violation. Section=ResponseStatusLine Id : 1017 Type : Error Message : [EXPR]-Error when contacting the RPC/HTTP service at https://SRV01/Rp c. The elapsed time was 15 milliseconds. Id : 1006 Type : Success Message : The Autodiscover service was tested successfully. Id : 1021 Type : Information Message : The following web services generated errors. Contacting server in EXPR Please use the prior output to diagnose and correct the errors.. I’m guessing these error messages have something to do with the issue. The server running exchange is a SBS 2008. Any ideas?

check this http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/94c5828f-07ab-4646-a551-6c4cf868d2d9/

Unfortunately the thread you linked does not solve the issue. Enabling anonymous authentication in EWS only results in more errors when test-outlookwebservices is run, and the out of office issue remains. We have tried a bunch of different things before ending up where we are at the moment, and at this point we're pretty much stumped as to what might be causing the problem. Any other suggestions?

Id : 1019 Type : Information Message : Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://remote.[domain].eu/autodiscover/autodisco ver.xml. Id : 1006 Type : Information Message : The Autodiscover service was contacted at https://remote.[domain].eu/aut odiscover/autodiscover.xml. Id : 1016 Type : Success Message : [EXCH]-Successfully contacted the AS service at https://remote.[domain]. eu/ews/exchange.asmx. The elapsed time was 265 milliseconds. The above information indicates both the Autodiscover service and the availability service is working fine on the server. The issue might be resided on the client side. Please run “Test e-mail AutoConfiguration” in Outlook to see what has been returned. Additionally, launch IE in the client computer to see if the above URLs are available. If the issue continues, let me know how your clients are connecting to Exchange server, internally in LAN, or externally via VPN or RPC over HTTP? And let me know the Exchange server and Outlook version. Regards, Fiona Liao 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.

I ran the Auto-Configuration in Outlook and this is what it returned: http://imgur.com/a/xhSJi#Owg6w (Screenshots) All the censored addresses are Remote.[server].eu, the censorship was maybe a bit too harsh with that. To my surprise there don't seem to be any issues, but alas, I still cannot access the oof settings becuase it claims the server is currently unavailable. Some of urls returned in the Auto-Configuration were browsable in IE, however a few were not. More info below. the OWA URL redirects to the web access service successfully. The Unified messaging service URL is also accessible. The ews/exchange.asmx URL, however, will not stop prompting for credentials. The same thing happens with the /OAB URL. From the Autodiscover URL, this is returned: <?xml version="1.0" encoding="utf-8" ?> - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> - <Response> - <Error Time="16:04:25.4581054" Id="3686046964"> <ErrorCode>600</ErrorCode> <Message>Invalid Request</Message> <DebugData /> </Error> </Response> </Autodiscover> The authentication settings set for the EWS site in IIS are Windows-integrated only. And for the OAB it's both basic and Windows-integrated. Perhaps it's one of these things that's causing the problem to occur? The clients connect to the exchange server via LAN. The Exchange server is running on a SBS 2008. The exchange server itself is 2007. The clients which are experiencing this issue are all running Outlook 2010, but we have also tested it on 2007. Any help would be greatly appreciated! Thanks!

Yes, you are correct. That is the problem that the client could not pass the authentication so Outlook could not use the AV service to retrieve the OOF settings. However, code 600 for autodiscover URL is expected while the Windows-integrated authentication for EWS VD is the default settings (see Microsoft article at: http://blogs.technet.com/b/exchange/archive/2008/02/01/3404755.aspx). Based on the current situation, my suggestion is: 1. Please verify the Default Web Site and make sure Anonymous is enabled. 2. I noticed that the OWA url has been redirect, so just to clarification, please make sure there is no redirection on EWS virtual directory (as a test, we may launch IE on the CAS server and try https://localhost/ews/exchange.asmx, and then verify if the URL has been changed). 3. Verify the local Host file on the client machine, and also the DNS server, make sure the URL is pointing to the CAS server’s internal IP address. 4. If there are more than one CAS server, please make sure the EWS URL returned by Outlook Auto-Configuration is pointing to the correct CAS server you want. 5. search in the IIS log file to see if there is any clue. I hope the above information is useful for you. Regards, Fiona Liao 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 for the reply! I have gone through the checklist you provided, and here are the results: The default web site (in this case it's called SBS web applications, since the server in question is a SBS 2008) already had anonymous auth enabled, so there was no required change there. The EWS virtual directory is not redirected, it can be reached by https://localhost/ews/exchange.asmx without issue, although it does prompt a certificate error, this error doesn't show up when browsing via the normal URL, which I assume is normal. However, instead of prompting for credentials today, it instead states the following: HTTP Error 503. The service is unavailable. The OAB URL fails to accept any credentials like before, though. The hosts file and DNS both seem to be OK. Nslookup on the client returns the correct server IP. There is only a single CAS, the SBS 2008, so the EWS URL returned from the auto-configuration is correct. The IIS logs do not show any particular events that I could make out, unfortunately. I'm curious as to why it doesn't want to accept any credentials, and what could be done to solve this. I'm almost certain that's the cause of the problem, like you said. Is there anything else I could try?

Well, the last thing i can say is rebuild the EWS virtual directory. however, it could be complicated in a SBS system. Can you email to me at V-fiolia@microsoft.com before doing so? You may also send me a MSN message via this account. Let's see if we can have any other method to verify the settings. Regards, Fiona 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.

I talked about this with my colleagues, and we were exploring some options when it turns out that exchange on our SBS is of version 8.1.240.6, which is only service pack 1, with no roll-ups. I've suggested that we try installing service pack 2 with the installation tool for SBS 2008 mcirosoft has provided, to see if it solves any of the issues. I figure it's worth a shot before going as far as rebuilding, rather than rebuilding the EWS first only to have it not working in the first place. I'll return with updates as to whether it solves the problem or not after we've done the update. Regards, Christopher

Hello! Firstly, let me apologise for the long delay in replies to this thread. There's been a week-long holiday, and I haven't had access to the clients server to do a check until today. It seems the issue still persists, even after updating exchange to the latest service pack, which is a shame to say the least. I was hoping it had resolved the issue. Outlook still prompts for a password indefinitely, regardless of which credentials you enter. And OOF is still broken. I think we have to rebuild the EWS virtual directory, I was hoping I could get some assistance with this. I'll send a mail your way, Fiona. If you have any further suggestions. Regards, Christopher

Hi Christopher, You are welcome. I received your email and reviewed the case history, noticed the “Test e-mail AutoConfiguration” screenshot provided (sorry I did not notice the screenshot before). The screenshot was not clear enough. The expected result of “Test e-mail AutoConfiguration” should contain the URL of OOF, OAB, etc, so that Outlook knows “where” to get the OOF settings. It might be a key clue since OOF is working fine in OWA. And I would like to see if we can collect more information for this issue. I have already sent you an email. Let me know if you can receive it. Regards, Fiona Liao 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.

Based on the current situation, I would suggest: 1. Just double confirm that, what URL are you using on the client computer for test? Is it https://remote.[domain].eu/EWS/Exchange.asmx? If so, which IP address does the URL link to? The internal CAS server IP address or the external address? 2. Is there any proxy settings on the client computer? Please verify it in both IE settings and client firewall if there is. 3. On the client computer, try https://<CAS’s internal IP>/ews/exchange.asmx to see if it works. During the test, take a look at the IE address bar to see if the address is changed. 4. Please upload me the IIS log: a. On Outlook, try to launch the OOF assistant to reproduce this issue, and make sure the error message appear. b. Launch IE and try to access the EWS URL (try both URL) and make sure the credential prompt appears at least twice. c. Note down the client computer’s IP address and user ID; d. Go to CAS server, navigate to folder: c:\inetpub\logs\logfiles\W3SVC1, copy the latest log file and then send it to me. Thanks for your time and patience, I look forward to hearing from you. -FionaPlease 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.