none
Exchange 2010 External Out of Office messages not going External

    Question

  • Have recently migrated a client to Exchange 2010 from 2003.  Projected closed out and thinking everything fine. Just got word that the OOF not flowing to external recipients.  Have checked the Remote Domains is configured to allow Automatic Replies  in message type and have tried several Out-Of-Message types as well.  Verified the user is configured to send External for ExternaloofOptions.  Still nothing!

    Any help will be greatly appriciated.
    Monday, March 15, 2010 9:57 PM

Answers

  • Fazal -
    Nothing is actually Published externally; client relies on Citrix for remote access.

    Actually fixed this issue; it was due to Webroot hosted scanning that was blocking the Automatic Replies coming from the clients servers as the automatic replies do not have a "Sender" configured and with TLS and verification enabled they drop un-authenticated messages.  So Webroot was able to make an exception and allow these messages to go external recipients.

    Something to keep in mind for everyone.
    Thursday, March 18, 2010 8:30 PM

All replies

  • can you please verify these Steps

    The Exchange Web Service (EWS) is the web service that allows access to the Out of Office service. If either the internal or external URL for the EWS is missing or incorrect, OOF will fail and other services may not work as expected.

    Using Exchange Management Shell, check the URLs assigned to the web service virtual directory using the Get-WebServicesVirtualDirectory command.  If either the internal or  external URL is missing or incorrect, set them using the Set-WebServicesVirtualDirectory command.

    Get-WebServicesVirtualDirectory

    Type or paste this line into Exchange Management Shell to check the EWS URLs

    Get-webservicesvirtualdirectory | fl identity,internalurl,externalurl

    If the server is configured correctly, the command returns results similar to the following, with URLs in both the InternalUrl and ExternalUrl fields.

    Identity : Server_name\EWS (Default Web Site)
    InternalUrl : https://server_name.your_domain.com/EWS/Exchange.asmx
    ExternalUrl : https://owa.your_domain.com

    Set-WebServicesVirtualDirectory cmdlet

     If the external URL is missing, set it using the Set-WebServicesVirtualDirectory command:

    Set-WebServicesVirtualDirectory -Identity "Server\EWS (Default Web Site)" -InternalURL https://server_name.your_domain.com/EWS/Exchange.asmx -ExternalURL https://owa.your_domain.com -BasicAuthentication:$true

    Verify the server names are correct by running Get-WebServicesVirtualDirectory  | fl identity,internalurl,externalurl again

    (Remember to replace the server names in the Set-WebServicesVirtualDirectory command with the correct server names for your organization.).

    Do Update me on this

    Looking forward to your Reply.

    Regards

    Fazal M khan

    Tuesday, March 16, 2010 5:31 AM
  • Fazal,
    I user are able to set OOF messages thru Outlook 2003 and 2007 clients and OWA.  Internal OOF message work correctly they just are never send to external mail reciepients.

    Tuesday, March 16, 2010 5:34 AM
  • Thank you for your Responce.

    I understand your Concern.

    Have you verified the Above Information ?

    Regards

    Fazal M khan

    Can you please email me the above results on

    fazal2@hotmail.com

    If you have Any Problems or Concern about sharing than information than we can continue Troubleshooting like this but its just if i have the information to look at than it would make my work Easy.
    Tuesday, March 16, 2010 5:45 AM
  • Fazal,
    We did have some issues previously with users being able to access setting OOF info from Outlook clients and worked thru it.  I will not be able to get this info until tomorrow morning and will send.  Sorry didn't answer your direct question but don't think this is the issue as I have seen problems with the EWS and they show up trying to set OOF, but will provide to have to take a second look at the settings.

    Tuesday, March 16, 2010 5:49 AM
  • Hi,

    Please understand that Outlook utilizes hidden messages in your Inbox to store the OOF rule used to trigger the OOF reply and the OOF message template used in the response.

    Now please try the below steps to delete the relevant rules:

    Clear OOF Rule in the mailbox:
    ========================
    1. Turn off OOF on a problem user and close Outlook
    2. Use MFCMapi tool to logon the problem user’s mailbox (by using Online Mode profile)
    3. Expand Root Container->Top of Information Store
    4. Right click Inbox folder and click Open Associated contents table
    5. Delete following messages if exist:

    a. Message class == IPM.Rule.Message
    0x65EB001E == Microsoft Exchange OOF Assistant
    0x65EC001E == Microsoft.Exchange.OOF.InternalSenders.Global

    b. Message class == IPM.Note.Rules.OofTemplate.Microsoft

    c. Message class == IPM.Rule.Message
    0x65EB001E == MSFT:TDX OOF Rules

    d. Message class == IPM.Rule.Message
    0x65EB001E == Microsoft Exchange OOF Assistant
    0x65EC001E == Microsoft.Exchange.OOF. AllExternalSenders.Global

    e. Message class == IPM.Note.Rules.ExternalOOFTemplate.Microsoft

    f. Message class == IPM.ExtendedRule.Message
    0x65EB001E == Microsoft Exchange OOF Assistant
    0x65EC001E == Microsoft.Exchange.OOF.KnownExternalSenders.Global

    6. After that, please start Outlook and configure OOF for the user. Please check whether the issue persists.

    Thanks

    Allen

    Tuesday, March 16, 2010 6:38 AM
    Moderator
  • Hi Allen

    Could you please Elaborate on these Steps that what would the End user acheive by doing this Steps ?

    Regards

    Fazal M khan

    Tuesday, March 16, 2010 7:28 AM
  • Hi,

    Through the above steps, you can delete the corrupted OOF rule and template to make Outlook recreate them when starting up the Outlook.

    Thanks

    Allen
    Tuesday, March 16, 2010 7:40 AM
    Moderator
  • Thank you for your Reply Allen.

    Very useful Suggetion.

    Do check out thes Findings MCSN.

     Looking forward to your Reply

    Regards

    Fazal M khan

    Tuesday, March 16, 2010 8:52 AM
  • Hi,

    Is the issue persist after deleting the rule based on the above suggestions?

    Thanks

    Allen
    Tuesday, March 16, 2010 9:15 AM
    Moderator
  • Ok here is the Get-WebservicesVirtualdirectory output.  DENCAS is an internal Certificate and NLB name for two CAS Servers in a CAS Array

    RunspaceId                    : 61ac485e-c409-476b-907e-5023b9332759
    CertificateAuthentication     :
    InternalNLBBypassUrl          : https://MBHUBCAS01.fqdn.net/ews/exchange.asmx
    GzipLevel                     : High
    Name                          : EWS (Default Web Site)
    InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
    ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
    LiveIdSpNegoAuthentication    : False
    WSSecurityAuthentication      : True
    LiveIdBasicAuthentication     : False
    BasicAuthentication           : True
    DigestAuthentication          : False
    WindowsAuthentication         : True
    MetabasePath                  : IIS://MBHUBCAS01.FQDN.net/W3SVC/1/ROOT/EWS
    Path                          : D:\Program Files\Exchange2010\ClientAccess\exchweb\EWS
    Server                        : DENMBHC01
    InternalUrl                   : https://dencas.fqdn.nett/ews/exchange.asmx
    ExternalUrl                   : https://dencas.fqdn.net/ews/exchange.asmx
    AdminDisplayName              :
    ExchangeVersion               : 0.10 (14.0.100.0)
    DistinguishedName             : CN=EWS (Default Web Site),CN=HTTP,CN=Protocols,CN=DENMBHC01,CN=Servers,CN=Exchange Admi
                                    nistrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=FQDN,CN=Microsoft Exchan
                                    ge,CN=Services,CN=Configuration,DC=FQDN,DC=net
    Identity                      : MBHUBCAS01\EWS (Default Web Site)
    Guid                          : d66de600-21f6-4507-81b3-23e27386ba55
    ObjectCategory                : FQDN.net/Configuration/Schema/ms-Exch-Web-Services-Virtual-Directory
    ObjectClass                   : {top, msExchVirtualDirectory, msExchWebServicesVirtualDirectory}
    WhenChanged                   : 3/16/2010 10:04:19 AM
    WhenCreated                   : 1/14/2010 4:08:14 PM
    WhenChangedUTC                : 3/16/2010 4:04:19 PM
    WhenCreatedUTC                : 1/14/2010 11:08:14 PM
    OrganizationId                :
    OriginatingServer             : dc3.fqdn.net
    IsValid                       : True



    Again I want to reitterate that internal OOF messages are being delivered just fine.  And that no (tested with numerous internal users with OOF configured to send external) OOF messages are being delivered to external recipients 
    Tuesday, March 16, 2010 4:43 PM
  • Thank You for your Reply

    I note that the External url Displays the same name as Internal URL

    InternalUrl                   : https://dencas.fqdn.nett/ews/exchange.asmx
    ExternalUrl                   : https://dencas.fqdn.net/ews/exchange.asmx


    Can you please confirm that you have published CAS using the same name for the internal and external Clients ?

    is this the name you have given on the PUBLIC DNS Server ?

    Reagrds

    Fazal M khan
    Thursday, March 18, 2010 6:16 PM
  • Fazal -
    Nothing is actually Published externally; client relies on Citrix for remote access.

    Actually fixed this issue; it was due to Webroot hosted scanning that was blocking the Automatic Replies coming from the clients servers as the automatic replies do not have a "Sender" configured and with TLS and verification enabled they drop un-authenticated messages.  So Webroot was able to make an exception and allow these messages to go external recipients.

    Something to keep in mind for everyone.
    Thursday, March 18, 2010 8:30 PM
  • Hello MCNS10

    Thank you for your Valuable feedback.

    We would definetly keep in my mind if anyone Reports this Issue.

    If you want to ask any mor questions plpease feel free to mssg back on this forum.

    Regards

    Fazal M Khan

    Friday, March 19, 2010 6:11 AM
  • Hello

    I am having the same issue, everything seems to be setup the right way but External users do not receive OOF auto replies.

    any help will be appriciated

    thanks in advance.

    Tuesday, April 13, 2010 3:06 AM
  • I have the same problem with the same situation !

     

    any idea ?

    Thursday, August 26, 2010 1:22 PM
  • can you explain please how to solve.

    i don't understand.

     

    Thanks shai

    Thursday, August 26, 2010 1:35 PM
  • has anyone been able to resolve this issue?

    I am having the exact same symptoms - can open OOF, but only works internal.

    Thursday, September 23, 2010 2:16 PM
  • Hello everybody

    I experience the same problem.

    I took the following actions (on the Exchange Server itself):

    - Installed Netmon to watch the SMTP traffic.

    - Disabled TLS on the send connector (set-sendconnector -identity .... -IgnoreSTARTTLS:$true (as I suspected TLS to not allow empty SMTP senders (mail from:<>))

    - Deleted and recreated: the send-connector the receive-connector.

    - Allowed ExternalLegacy on the Remote Domain.

    - Tried various version of ExternalURL configurations for the WebServicesVirtualDirectory.

    - Imported the self-generated certificate to the local computer "Trusted root CAs" store (as I suspected authentication problems for the ExternalURL).

     

    Results:

    - Netmon does NOT show any SMTP traffic generated for the OOF message. Hence I conclude that the OOF message is not generated at all.

    Has anyone come to a solution re. this?

    Help is very much appreciated.

    DV.

     

    Thursday, October 14, 2010 4:04 PM
  • Hello again

    I eventually figured that out.

    Recall a very important point:

    OOF messages to the same addressee are sent ONLY ONCE !!!!! until you deactivate & reactivate the OOF setting!

    You cannot change this behaviour.

    I fell into this trap testing over and over again wondering why the OOF message is not generated again.

     

    The other hint:

    Catch the SMTP traffic with Netmon!

    In my case this eventually revealed that the smart host is rejecting messages from empty SMTP senders (mail from:<>).

     

    DV

     

    Sunday, October 17, 2010 10:19 AM
  • Hi,

     

    I seem to be having a simular issue with certain mailboxes on my server.  Most OOF replies go out fine but one account I've been looking at will not send the replies.

    Looking at message tracking, I can see that a message sent to the mailbox from an internal address on the domain shows a Submit (sender= <>), a Receive (sender = primary email address of the account) and a Deliver (sender = primary email address of the account).  On triggering an OOF reply from an external email account I get just the Submit and the Receive with the same senders as before.  The deliver does not occur so I'm assuming there is some rule preventing this from happening?

    I've been trying to follow the MFCMapi instructions but have never used it before so not to sure if I'm doing it quite right...  The mailbox still works and on restarting it I got an error message and had to retype the OOF message, so assuming it went right.  Still the external replies are missing.

    Any advice would be great,

     

    JR

     

    Tuesday, November 23, 2010 3:36 PM
  • Hi,

    PPL experiencing problem with OOO going externally (Out of Office) first eliminate if it is a misconfiguration of exchange 2010 at your site. Maybe your smart host blocks them.

    1

    Enable OOO for mailbox-user and setup OOO for external.
    Send an e-mail from an external, mapi-client using (office 2003-2010) or OWA, e-mail address to your mailbox-user.

    Enable VERBOSE logging on you send connector. investigate the log file; C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpSend\*.log

    Search in the log file : FROM:<>

    No you can see if it is going outside or not, or maybe the logging says if it is bouncing (interpreter the logging)

    2

    For testing OOO functionality make an additional send connector for your testing domain;
    -Name: For testing purposes. anexternaldomain-otherthenyour-owndomain.com
    -Select the intended use: Internet
    -Add SMTP Address; Address space: anexternaldomain-otherthenyour-owndomain.com
    -Add SMTP Address; Cost: 1
    -Network settings: "Use domain name system (DNS) "MX" records to route mail automatically"
    -Source Server: select your Hub transport server

    Now try again OOO to be send externally (don't forget disable en re-enable OOO, OOO-messages will only be sent once.)

    ---

    Did your partner receive your OOO-alert with solution 2? There is a problem with your smart host. Not a misconfiguration at your side.

    I hope this assist you in troubleshooting OOO issues.

    ~JAB

    Tuesday, June 28, 2011 8:09 PM
  • thanks your suggest, I checked my smart host, there is a policy drop no sender email , I canceled this policy and the external recipients can get the OOF messege!
    Thursday, December 29, 2011 2:57 AM