I came across a very weird problem this past week that had me scratching my head for a bit. 

I had just finished helping a non-profit customer migrate to a net-new Windows domain after they had suffered through a “broken” migration from SBS2003 to SBS2011.  As we all know, things change rather dramatically from Exchange 2003 to Exchange 2010 (the version included with SBS2011) and that includes how Exchange recognizes and handles “internal” email addresses.  For those of you who don’t know, Exchange has always handled internal email (email between internal Windows domain users) rather differently form email that goes out of house.  In Exchange 2003 and earlier, internal email would be routed by the X400 address attached to each users Exchange/AD profile.  The X400 address looks something like this:

C=US;A= ;P=MYDOMAIN;O=Exchange;S=Doe;G=John;

As you can see, it does NOT look anything at all like a normal SMTP address such as johndoe@mydomain.com.  Starting with Exchange 2007, internal email is routed by the regular SMTP address.  User profiles created as net-new in Exchange 2007 or 2010 will not have an X400 address attached although both versions can accept migrated in user profiles that have X400 addresses as part of their profile and both can still route email using the X400 address in the background.  However, X400 use is not required.

OK, all of this is by way of setting up the scenario of what was happening at the non-profit.  We spent the weekend migrating everything over to the the new domain on their new SBS2011 server.  ALL user email was migrated using exported PST files generated at the user workstations, Exmerge was not used.  All user accounts were created cleanly in the new domain as well as their associated Exchange profiles/mailboxes.  In other words, we did the migration as cleanly as we possibly could and, yes, it was labour intensive to do so.  The PST’s were reconnected to each users new Exchange profile and the contents imported into their Outlook which, in turn, imported into the new Exchange mailbox.  We verified the Global Address List, we verified publication of address lists, we verified email flow internally and externally.  Everything was “green” and good to go.  I was a happy camper as it looked to be a successful and clean migration.

A couple of days later my contact at the customer called to let me know that there was an email issue.  Lots of users were getting email bounce notifications when then emailed internal users.   There were no problems with mailing externally, only internally.  Curious.  He passed on some bounce messages and they didn’t look quite right to me so we did some more digging.  If email was generated and addressed using the “TO:” button in Outlook and addresses were selected form the GAL then all was good.  Now I was really confused, how could it work from the GAL but not when a user selected the Contact?  Then it hit me – Contacts!  We did some more digging and discovered that  almost ALL Outlook users inside the organization had replicated the internal contact list from the old Exchange 2003 GAL into their personal Contacts (I have no idea why ….).  That meant they were sending out internal emails with the original X400 address from the OLD domain even though the “alias” listed in their Contacts list was the valid SMTP address.  Exchange 2010 in the new domain was attempting to deliver the email based on the X400 address from the OLD domain which failed miserably.  Users needed to clean up their Contacts (when they looked at their contact listing the “bad” addresses would be listed as “EX=”) in order to eliminate the problem.

Obviously, this is not a problem that most of you will ever see as it was created by a unique set of circumstances.  But it might occur if you migrate to a hosted Exchange service like Office365 and your users have replicated ancient address lists (I’m just saying ….) that follow the migration.  And, of course, if you perform a migration between differing domains like we did then you might also see the problem.  The big problem is that users themselves don’t necessarily see all of this happening because they only really see the SMTP address on an Outlook contact.  The X400 address, if stamped into an Outlook contact, is only visible in certain views and users almost never see those views.  If they do see the view then they certainly don’t register the fact that the email address for the contact starts with “EX=”.  Believe me, this was a hard, hard thing to explain to the users at my customer.

 

Outlook users can wreak havoc when you move to new Exchange
Tagged on:         

3 thoughts on “Outlook users can wreak havoc when you move to new Exchange

  • It´s worse than that. Even after cleaning the Contact List, just replying an old email can cause the problem to happen.

  • We just migrated from one domain to another and one exchange server to another. Nk2edit can help correct the issue by editing the autocomplete stream. Still painful to explain to users.

    1. Interesting. Not heard of the tool before but if it helps then it is good to know about. It never fails to amaze me how ignorant users can be of how their Outlook actually works. Worse, how they will argue that black is white and that “it has always worked like this” when you try to explain the situation. But, we are the admins; it’s our job to suck it up!

      Thanks for sharing, hopefully it will help another of our brethren (and sisters) in the trenches!

      Robert

Comments are closed.