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 Beta.Exchange@mydomain.com -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 ">">">Beta.Exchange@ –Server "CRP-exht-01" -EventID "SEND" -Start "23/11/2008 00:08:00" -End "23/11/2008 23:1 8:00" -Recipients ag014w3520@blueyonder.co.uk | 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 - +<60EC2C04361E5E468C6C02D4A09745230DE9AC7C@CRP-CCREVS-01.mydomain> 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):+ag014w3520@blueyonder.co.uk 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):+ag014w3520@blueyonder.co.uk 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.