Further to my recent article about OOF (or OOO) functionality not working in Exchange 2007 – I have found out another little nugget of truth which might be of use to you all. As my previous article explains I had a problem with Exchange 2007 OOO messages being synchronised and indeed not being sent within my organisation, which after a lot of research I managed to track down the problem to a specific service – however I then further found out that even though I had managed to fix the problem detailed in my first article – Exchange 2007 OOO replies were not sending to internet based recipients – to make matters more complicated – Exchange 2003 based users in the Interop environment COULD send OOF to internet based recipients . The diagram below depicts the issue that I was now having: The best way to troubleshoot this was to use the message tracking features within Exchange to see exactly where the OOF message was get lost within my organisation – now at this stage we should bear in mind that my Exchange Organisation is in Interop mode with Exchange 2003 – where the Exchange 2003 part of the configuration is still setup to relay mail to the Internet – so any message tracking to the web is a two stage process.

Step 1 – Track the OOF message from the 2007 based sender via the Exchange Management Shell

In order to do accomplish this I opened up a new Exchange Management Shell command window and entered in the following command: get-messagetrackinglog –Sender –Server –EventID –Start –End – Therefore – get-messagetrackinglog -Sender [email protected] -Server "CRP-HUB-01" -EventID "SEND" -Start "23/11/2008 00:08:00" -End "23/11/2008 23:18:00" The above command gave me a list of mails sent within the time period that I required – see below: From the list above I identified the e-mail that I was interested in and then modified my command to look like the following: get-messagetrackinglog -Sender ">">">[email protected] –Server "CRP-exht-01" -EventID "SEND" -Start "23/11/2008 00:08:00" -End "23/11/2008 23:1 8:00" -Recipients [email protected] | fl Which produced the following output (key information about my setup has been removed): The information that I was interested in from the above output was as follows:

• ServerHostName – this is the next hop server that I would expect the OOF to take – this should be the Exchange 2003 bridge head
• ConnectorID – This should tell me that the transport was an Intra-Organisational Send Connector

This with the above information being correct I knew that to all intents and purposes the OOF was getting out of the Exchange 2007 side of my organisation and was being passed to the Exchange 2003 side.

Step 2 – track the OOF message from the Exchange 2003 organisation to the end recipient:

As Exchange 2007 cannot track Exchange 2003 messages I had to jump onto one of my Exchange 2003 servers and fire up the message tracking from the Exchange 2003 Management Console. The results of which are displayed below: Now the interesting part of the above is that I would normally expect to see a final entry just under the “SMTP: Message Routed and Queued for Remote Delivery” telling me that the OOF had been passed out to our External messaging suppliers (for example Message Labs) – however it was missing. I found this strange so I decided to turn on SMTP logging on the Virtual SMTP server on my mail relay – which produced the following output – this example will look different as I had to send a new mail item to ensure that it was added to the SMTP logs and I have replaced the IP addresses with bogus entries):

#Software:  Microsoft Internet Information Services 6.0 
#Version: 1.0 
#Date:  2008-11-23 19:11:15 
#Fields: c-ip cs-username s-sitename s-computername s-ip  s-port cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status cs-host  
10.1.1.2 crp-exht-01.mydomain.comSMTPSVC3 CRP-RELAY-01 10.1.1.3 0 EHLO -  +crp-exht-01.mydomain.com 250 0 - 
10.1.1.2 crp-exht-01.mydomain.comSMTPSVC3  CRP-RELAY-01 10.1.1.3 0 MAIL - +FROM: 250 0 - 
10.1.1.2  crp-exht-01.mydomain.comSMTPSVC3 CRP-RELAY-01 10.1.1.3 0 RCPT - +TO: 250 0 -  
10.1.1.2 crp-exht-01.mydomain.com SMTPSVC3 CRP-RELAY-01 10.1.1.3 0 BDAT -  +<[email protected]ydomain> 250 0 -  
10.1.1.2 crp-exht-01.mydomain.com SMTPSVC3 CRP-RELAY-01 10.1.1.3 0 QUIT -  crp-exht-01.mydomain.com240 328 - 
194.116.199.78 OutboundConnectionResponse  SMTPSVC3 CRP-RELAY-01 - 25 - - 220+gse-mta-08.emailfiltering.com+emfmtad+182 0 0  - 
194.116.199.78 OutboundConnectionCommand SMTPSVC3 CRP-RELAY-01 - 25 EHLO -  crp-relay-01.mydomain.com 0 0 - 
194.116.199.78 OutboundConnectionResponse  SMTPSVC3 CRP-RELAY-01 - 25 - -  250-gse-mta-08.emailfiltering.com+Salutations+214.56.211.0+[214.56.211.0]. 0 0 -  
194.116.199.78 OutboundConnectionCommand SMTPSVC3 CRP-RELAY-01 - 25 MAIL -  FROM: 0 0 - 
194.116.199.78 OutboundConnectionResponse SMTPSVC3 CRP-RELAY-01  - 25 - - 250++accepted 0 0 - 
194.116.199.78 OutboundConnectionCommand  SMTPSVC3 CRP-RELAY-01 - 25 RCPT - TO: 0 0 - 
194.116.199.78  OutboundConnectionResponse SMTPSVC3 CRP-RELAY-01 - 25 - -  550+Relaying+not+permitted+(3.7):[email protected] 0 0 -  
194.116.199.78 OutboundConnectionCommand SMTPSVC3 CRP-RELAY-01 - 25 RSET - -  0 0 - 
194.116.199.78 OutboundConnectionResponse SMTPSVC3 CRP-RELAY-01 - 25 -  - 250+OK 0 0 - 
194.116.199.78 OutboundConnectionCommand SMTPSVC3  CRP-RELAY-01 - 25 QUIT - - 0 0 - 
194.116.199.78 OutboundConnectionResponse  SMTPSVC3 CRP-RELAY-01 - 25 - - 221+Bye+for+now 0 0 -

The key point of interest in the log above was the following line:

194.116.199.78  OutboundConnectionResponse SMTPSVC3 CRP-RELAY-01 - 25 - -  550+Relaying+not+permitted+(3.7):[email protected] 0 0 -

This suggested to me that our e-mail filtering service was blocking the OOF messages from Exchange 2007 based recipients but not Exchange 2003 based ones for some reason. I decided to do a little more research which opened up the following article on TechNet: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3370071&SiteID=17 – Hmmmm. I fired an e-mail off to our Messaging Scanning company whom made a change to the way in which outbound relay is handled – and low and behold it now works! So the moral to this story – (if there is one) is that if you use a third party e-mail scanning company – or indeed appliance and your Exchange 2007 OOF messages seem to be going no where – then have a look at the tracking logs to see if the new way in which OOF messages are handled in Exchange 2007 is causing you issues.