NDR from Weird address
- I am setting up a new environment with CCR mailbox roles and 2 hub\cas servers. I installed Update rollup 7 for E2K7SP1 and was testing mail flow when I noticed that my NDR messages are coming from a weird email address. Usually NDRs are generated from Microsoft Exchange but now they are being generated by MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@mydomain.com[MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@mydomain.com] which I find VERY weird!
Digging around the configuration, I ran GET-ORGANIZATIONCONFIG and noticed that the MicrosoftExchangeRecipientEmailAddresses and MicrosoftExchangeRecipientPrimarySmtpAddress attributes have this value!
Has anyone seen this before? How do I change this back to Microsoft Exchange? What is this value and where is it coming from?
Thanks in advance
Risposte
Hi,
All right, I have confirmed with the PG (Product Team), this is the product issue after installing Rollup 7, we will be fixing this for the next rollup with the highest priority. A KB has also been documented for this. http://support.microsoft.com/kb/969690.Unfortunately there is no workaround to get the sender address to what it was before. We aplogize for the inconvenience cause.
Allen- Contrassegnato come rispostaAllen SongMSFT, Moderatoremartedì 7 aprile 2009 3.46
- Proposto come rispostaAmit TankMVP, Moderatorelunedì 6 aprile 2009 4.17
A workaround has been explained in below article by Andy Grogan so temporary you can specify some smtp address like postmaster@yourdomain.com in OrganizationConfig, however we need to relay on permanent fix which will be given by Microsoft in next rollup.
Amit Tank | MVP - Exchange | MCITP:EMA MCSA:M | http://ExchangeShare.WordPress.com- Contrassegnato come rispostaAllen SongMSFT, Moderatoremartedì 7 aprile 2009 3.46
- Proposto come rispostaAmit TankMVP, Moderatorelunedì 6 aprile 2009 4.17
Tutte le risposte
- Hi, since I applied Rollup 7 I too have been getting Spam messages and NDRs from the
MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@mydomain.com address
Before today with just rollup 6 applied this didn't occur so it is obviously something to do with one of the new hotfixes in Rollup 7. - This is a known issue and relates to this fix was included in RU7
http://support.microsoft.com/default.aspx/kb/956455
lasse at humandata dot se, http://anewmessagehasarrived.blogspot.com - That article says Rollup 7 fixes the problem when in fact it started after rollup 7 was applied (as both ibenna & I said) also, I don't have hidden mailboxes to which this article refers.
- I agree with Maurice_Reed. As I stated, this is a new environment and I only have 2 users in it that I use for testing purposes. This is holding up my migration because I do not want to move users over with issues like this occuring. What is that address? obviously with 2 mailboxes only, I do not have any hidden mailboxes.
- ibenna this sounds a bit of a hack fix but can you just use a Schema tool such as LDP.exe or ADSIEdit to search the configuration partition for MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@mydomain.com. Seeming Exchange 2007 stores pretty much all its configuration information under:
CN=Microsoft Exchange,CN=Services,CN=Configuration,${BASEDN}
If you search all attributes for MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@mydomain.com you will probally it, then try manually changing it. Seeming its not in production you have nothing to loose? If it messes things up change it back!
Just an idea...
Clint Boessen MCSE, MCITP: Messaging
L7 Solutions, Microsoft Gold Partner
Perth, Western Australia Hi,
Please try to use ADSI.Edit tool, then expand Expand Configuration, expand CN=Configuration,DC=contoso,DC=com, expand CN=Services, expand CN=Microsoft Exchange, expand CN=<OrganizationName>, and then expand CN=Transport Settings.
In the details pane, right-click CN=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e, and then click Properties.
Check the displayName, then change it to Microsoft Exchange. Click OK.
After that, please check this issue.
Allen- Tried to do that and failed as it comes back that the object is owned by the system and cannot be changed.
Not causing any real problem for me so will wait and see if an answer appears sometime. - Hi,
Whether your acccount have the Administrator permission, please understand the account you use must be delegated the Exchange Server Administrator role and membership in the local Administrators group for the target server.
Thanks
Allen - Yes, I was logged in as Administrator which is both Domain and Exchange admin. Still rejects the change. personally this doesn't seem to be a serious problem so I am not too worried about it but ibenna does seem concerned.
If you read this ibenna did you manage to make the edit in AD as suggested? - Hi,
Of course, I can modify the attribute on my lab without any issue. And the result is gotten as expected.
Thanks
Allen HHMmmmm...well I went into ADSIEdit and guess what?! The value for the DisplayName IS "MICROSOFT EXCHANGE"!! I compared the settings with another environment running UR6 and the values look the same. I even restarted all my exchange servers but still getting the same results.
I am not really concerned with this issue but here is the thing. I am a consultant and am setting up a migration from Domino to Exchange. We are currently working in a lab environment to test the migration and this is one of the things my client noticed. Obviously I do not want them to have a negative experience with Exchange before it is introduced to the production.
Any more ideas? :)- I had the same experience as Maurice_Reed: I was using an account with domain admin and exchange admin rights and got the same error: The attribute cannot be modified because it is owned by the system. My only concern is that Outlook tends to dump any mail from this address in the Junk Mail folder and I am concerned some users may not see the messages.
TBrennan Hi,
All right, I have confirmed with the PG (Product Team), this is the product issue after installing Rollup 7, we will be fixing this for the next rollup with the highest priority. A KB has also been documented for this. http://support.microsoft.com/kb/969690.Unfortunately there is no workaround to get the sender address to what it was before. We aplogize for the inconvenience cause.
Allen- Contrassegnato come rispostaAllen SongMSFT, Moderatoremartedì 7 aprile 2009 3.46
- Proposto come rispostaAmit TankMVP, Moderatorelunedì 6 aprile 2009 4.17
A workaround has been explained in below article by Andy Grogan so temporary you can specify some smtp address like postmaster@yourdomain.com in OrganizationConfig, however we need to relay on permanent fix which will be given by Microsoft in next rollup.
Amit Tank | MVP - Exchange | MCITP:EMA MCSA:M | http://ExchangeShare.WordPress.com- Contrassegnato come rispostaAllen SongMSFT, Moderatoremartedì 7 aprile 2009 3.46
- Proposto come rispostaAmit TankMVP, Moderatorelunedì 6 aprile 2009 4.17
- I am running RU5 in a single-server environment and am getting spam from this address. So far just a single specimen that came in this morning.
An NDR was delivered to a user mailbox, with the To and From being MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e. It was an NDR from a spam message to (and from) a non-existent account in our domain.
Is it possible someone spoofing our domain bounced this off an Exchange server running RU7? That's my best guess at this point.
