I have been working on the installation of a few new CCR Clustered Database servers where I work, which has been pretty cool (I have some scripts heading your way when I am done). Whilst doing this, I thought that it might be a good idea to implement the latest Roll up for Exchange 2007 Service Pack 1 (Roll up 7) on the other servers within my configuration - which included my Hub Transports.

Things were working quite well until I noticed that when using Delivery reports at indeed at what seemed to be random intervals the DSN for a Successful delivery would come back as:

At the time I did not make the connection between this and Roll up 7 - however one quick Google later led me to the following article on the Roll Up 7 forum: http://social.technet.microsoft.com/Forums/en-US/exchangesoftwareupdate/thread/d0f601ab-4b57-4972-af89-cd76f2d4d4a8 this (and indeed a number of other articles) suggested to me that this was a fairly widespread issue - and Microsoft was looking into it.
Now like some of the people within the forum (and indeed some of the folks whom had posted on the MSExchange teams blog) I really needed to get this fixed - as I was in catch 22 situation - Roll up 7 fixed something quite important for me - but, alas by buggering up the DSN display name would not doubt throw my Exchange user community into the very depths of despair, whereby not being told by the wonderful Exchange Postmaster that there message arrived correctly would not doubt end in a slow and painful death.

So - as a start I decided that I would try to find the file which changed between Roll Up 6 and Roll Up 7 which messed things up. After a few hours of what upon reflection was a pretty pointless amount of reading on the Internet - I gave up on this approach - as unsurprisingly I could not find the required files - it also occurred to me that even if I did find the file in question it would cause issues later on down the line so I decided on another approach.

From the details that I found in the forums I knew that the recipient address remained constant across all installations of Exchange - therefore I was looking for something within my configuration which matched the following Display Name:

MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@<mydomain.com>

So it struck me that a good place to start would be within Active Directory.

At first I focussed on the "329e71ec88ae4615bbc36ab6ce41109e" as it looked like a GUID (initially I surmised a Mailbox GUID) to me so I arranged it into the correct format of: "329e71ec-88ae-4615-bbc36ab6ce41109e", I then opened up an Exchange Management Shell command window and typed in the following command:

get-mailbox -ResultSize unlimited | where {$_.GUID -eq "329e71ec-88ae-4615-bbc36ab6ce41109e"}

Alas the above command returned no results (which I had to admit I was not really that surprised by) - so slightly puzzled I decided to Google the actual Display Name of MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@<mydomain.com>

This retuned some very interesting results - as it would seem that this address is pre-configured by Exchange as part of the Organisational Configuration - see below:

The value of most interest is the "MicrosoftExchangeRecipientPrimarySMTPAddress" - which as you can see has the same format that was now being used for my delivery reports - the description of this value according to Microsoft is:

"This parameter specifies one or more e-mail addresses for the Microsoft Exchange recipient. All valid Exchange 2007 e-mail address types may be used. You can specify multiple values for this parameter as a comma-delimited list. If the MicrosoftExchangeRecipientEmailAddressPolicyEnabled parameter is set to $True, the e-mail addresses are automatically generated by the default e-mail address policy. You can't use the MicrosoftExchangeRecipientEmailAddresses parameter.

E-mail addresses that you specify by using the MicrosoftExchangeRecipientEmailAddresses parameter replace any existing e-mail addresses that are already configured."

I thought that considering that this was the only place where I had found the address I would change it to something that reflected the correct address so I executed the following Powershell command from the Exchange Management Shell:

Set-OrganizationConfig -MicrosoftExchangeRecipientEmailAddressPolicyEnabled $false

Set-OrganizationConfig -MicrosoftExchangeRecipientPrimarySmtpAddress This e-mail address is being protected from spambots. You need JavaScript enabled to view it

I then performed a directory replication and restarted the Transport Services located on my Hub Transports - and low and behold all of my delivery reports now come from postmaster@<mydomain.com>

Now I acknowledge that the above is a workaround - and indeed the MSExchange team are working on a fix for this issue - but if you are desperate this might be the solution for you.