none
Outlook out of office issue - RESOLVED RRS feed

  • Question

  • 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?


    • Edited by Someguy_ Friday, June 10, 2011 9:50 AM
    Friday, May 20, 2011 9:52 AM

Answers

  • SOLVED!

     

    I am extremely happy to announce that we found the solution to the problem. The excessive prompting for credentials disappeared with the SP3 update, and with some further troubleshooting we were able to track down why the out of office settings didn't show up.

     

    To recap:

     

    Firstly we checked a client PC after the update to verify if the settings were available, and  https://remote.[domain].eu/EWS/Exchange.asmx was readily accessible from the machine. This had not been possible prior to the update. Now, when we were able to access the information within the xml file, the out of office settings also started working.

    After verifying that this was not all just a fluke by sending multiple mails and receiving the automatic replies, we went on to see why one of the clients still could not get it to work.

    The  https://remote.[domain].eu/EWS/Exchange.asmx url was still prompting a password, which was very strange, since it didn't do so for the other client we checked.

     

    The solution was this:

     

    In the password vault for the working client, there was nothing saved. This made it possible for the windows authentication setting in IIS to function properly and log the user in using their already entered windows credentials. The faulty client however, had something saved in the password vault which pointed towards remote.[domain].eu!

    After comparing the two vaults, we came to the realization that the issue must be with the saved password entry which points toward the URL in question. And as stated, once the faulty entry was removed, the OOF settings started working again.

     

    It has been a great pleasure working with you, Fiona, thanks for all the help! I'm glad this could finally be solved once and for all.

     

    Regards,

    Christopher




    • Marked as answer by Someguy_ Friday, June 10, 2011 9:45 AM
    • Edited by Someguy_ Friday, June 10, 2011 9:49 AM Formatting
    Friday, June 10, 2011 9:45 AM

All replies

  • 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?

    Friday, May 20, 2011 11:36 AM
  • 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.
    Monday, May 23, 2011 9:16 AM
    Moderator
  • 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!


    Monday, May 23, 2011 2:30 PM
  • 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.

    • Proposed as answer by Fiona_LiaoModerator Wednesday, May 25, 2011 6:44 AM
    • Unproposed as answer by Someguy_ Wednesday, May 25, 2011 9:01 AM
    Tuesday, May 24, 2011 6:31 AM
    Moderator
  • 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?
    Wednesday, May 25, 2011 9:02 AM
  • 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.

    Wednesday, May 25, 2011 9:20 AM
    Moderator
  • 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

    Thursday, May 26, 2011 6:27 AM
  • 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

    Tuesday, June 7, 2011 6:47 AM
  • 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.
    Tuesday, June 7, 2011 8:22 AM
    Moderator
  • 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.

     

    -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.
    Friday, June 10, 2011 7:50 AM
    Moderator
  • SOLVED!

     

    I am extremely happy to announce that we found the solution to the problem. The excessive prompting for credentials disappeared with the SP3 update, and with some further troubleshooting we were able to track down why the out of office settings didn't show up.

     

    To recap:

     

    Firstly we checked a client PC after the update to verify if the settings were available, and  https://remote.[domain].eu/EWS/Exchange.asmx was readily accessible from the machine. This had not been possible prior to the update. Now, when we were able to access the information within the xml file, the out of office settings also started working.

    After verifying that this was not all just a fluke by sending multiple mails and receiving the automatic replies, we went on to see why one of the clients still could not get it to work.

    The  https://remote.[domain].eu/EWS/Exchange.asmx url was still prompting a password, which was very strange, since it didn't do so for the other client we checked.

     

    The solution was this:

     

    In the password vault for the working client, there was nothing saved. This made it possible for the windows authentication setting in IIS to function properly and log the user in using their already entered windows credentials. The faulty client however, had something saved in the password vault which pointed towards remote.[domain].eu!

    After comparing the two vaults, we came to the realization that the issue must be with the saved password entry which points toward the URL in question. And as stated, once the faulty entry was removed, the OOF settings started working again.

     

    It has been a great pleasure working with you, Fiona, thanks for all the help! I'm glad this could finally be solved once and for all.

     

    Regards,

    Christopher




    • Marked as answer by Someguy_ Friday, June 10, 2011 9:45 AM
    • Edited by Someguy_ Friday, June 10, 2011 9:49 AM Formatting
    Friday, June 10, 2011 9:45 AM
  • Great to hear that the issue is resolved successfully.

    thanks for your udpate, and havea nice day:)


    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.
    Monday, June 13, 2011 3:00 AM
    Moderator
  • Hi, We are also experiencing the issue of users constantly getting prompted for credentials and OOF not working from with Outlook 2007 (works from owa).

    Here is an output of Test-OutlookWebServices

     

    Id      : 1003
    Type    : Information
    Message : About to test AutoDiscover with the e-mail address Administrator@mydomain.com.

    Id      : 1007
    Type    : Information
    Message : Testing server server.mydomain.com with the published name https://outlook.mydomain.com/EWS/Ex
              change.asmx & https://outlook.mydomain.com/.

    Id      : 1019
    Type    : Information
    Message : Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://outlook.mydomain.com/Autodiscover/Autodiscover.xml.

    Id      : 1013
    Type    : Error
    Message : When contacting https://outlook.mydomain.com/Autodiscover/Autodiscover.xml received the error The server commit
              ted a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

    Id      : 1006
    Type    : Error
    Message : The Autodiscover service could not be contacted.

     

    My autodiscover tests look alright, with the below URL's returning a "https://outlook.mydomain.com/EWS/Services.wsdl" in IE ok.

    Exchange RPC:

    Availability Service URL:  https://outlook.mydomain.com/EWS/Exchange.asmx

    OOF URL:  https://outlook.mydomain.com/EWS/Exchange.asmx

     

    Exchange HTTP:

    Availability Service URL:  https://outlook.mydomain.com/

    OOF URL:  https://outlook.mydomain.com/

     

    I have applied the .Net patch as below and scheduled a restart after this weekend, however most ppl seem to think an iisreset is enough after applying the patch in 958934? (Our issue still remains, will report back after a restart).

    http://support.microsoft.com/kb/958934

     

    Should the next move be to re-create the EWA/Autodiscover virtual directories?

     

    Any assistance would be greatly appreciated, am getting a lot of heat from bosses/staff about the annoying pop-ups and OOF not working natively.

     

    Thanks,

     

    Nick

     

     

     

    Thursday, November 10, 2011 9:00 AM
  • I am getting a similar problem here.  What do you mean by the passowrd vault?

    my client cannot access the url either but if i insert the IP it does connect (but with the normal certificate warning).

    cheers

    Friday, April 11, 2014 3:31 PM