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.