Migrating from one Microsoft Exchange organization to another Exchange organization is always a troublesome task. There’s free/busy time, public folders, the Global Address List (GAL), permissions, mailbox data, etc., to be worried out during the migration. With recent versions of the Outlook client, there’s also the nickname cache to worry about, too.
The nickname cache is that functionality in Outlook that lets you start typing a recipient’s name (one that you’ve used before) and Outlook will “auto-complete†the name for you. It’s a pretty handy feature, to be honest, and I’m sure that quite a few users out there rely on this functionality. In fact, I’ve had people tell me that their nickname cache is more important than their contacts folder!
In a straight STMP-only situation, the nickname cache can be quite harmless during the migration. In an Exchange migration, however (such as when migrating from one organization to a new organization, perhaps due to acquisition, rebranding, whatever), the nickname cache can be quite a pain in the rear. Why? Because the nickname cache doesn’t store the SMTP address of the Exchange recipients to which you’ve been sending e-mail; instead, it stores the X.500 address.
For example, when you mailbox-enable (i.e., create a mailbox for) a user object, Active Directory and Exchange will stamp the legacyExchangeDN attribute with an address that looks something like this:
/o=VMware Test Lab/ou=Raleigh/cn=Recipients/cn=scott.lowe
This is an X.500 address, and if an Outlook user sends an e-mail to this mailbox-enabled user object, this X.500 address will get added to the nickname cache. For an Outlook user creates a contact for an Exchange recipient from the GAL, this X.500 address will be the address that is saved with the contact. If this mailbox is moved to a new organization, this X.500 address—by default—won’t go with it, and that is the root cause of the most of nickname cache problems in a migration.
So how do we fix it? Easy, actually. Let’s say that you want to represent John Doe, who has a mailbox in Organization B, in the GAL for Organization A. You create distinct SMTP namespaces for the two organizations, create SMTP connectors with the appropriate namespaces, and you test mail flow between the two. Everything works fine, and so you create contacts in the GAL for Organization A to be able to send e-mail messages to those recipients in Organization B.
Thinking you’re pretty clever (which you likely are, since you’re visiting this site), you create contacts in Organization A to represent users in Organization B and vice versa. Since these contacts are all SMTP based, routing messages based on the SMTP namespace, all should be well, right? Nope.
Unfortunately, because these contacts were created on the server (we’re talking Active Directory Contact objects here, not Outlook contacts), users sending e-mail messages to them will be adding the X.500 address of the contact to their nickname cache, not the SMTP address. When these users migrate from Org A to Org B and send mail to these recipients again, the system will generate an NDR (non-delivery report). Why? Because the nickname cache has the X.500 address for the Contact object in the source AD tree.
But enough of the background. How do we fix the problem? Check out these steps:
- Review the legacyExchangeDN attribute on the target mailbox.
- Add the value of legacyExchangeDN (on the target mailbox) to an X.500 address on the Contact object in the source domain. To create an X.500 address, select the “Custom Address†and specify the address type as “X500†(no quotes).
That’s it! When users send e-mail to the Contact objects, the X.500 address will be stored in the nickname cache. The Contact object’s targetAddress attribute will, of course, point to an SMTP address assigned to the target mailbox; that’s what allows Exchange Server to route the e-mail messages appropriately. After the users are migrated to the new Exchange organization, the X.500 address for the users to which they used to send mail will still be the same as the Contact objects they used to use. Perfect!
-
Pingback from subject: exchange : Weekend reading on Monday, February 19, 2007 at 4:39 am
-
I am involved in a org to org migration. In the past the companies were using the Galsynch part of MIIS to create contact objects for newly created mailbox accounts in each domain in the opposite domain. Each domain shares the same domain name: @company.com
Scenario:
Mailbox user1 in Domain/Org A sends mail to mailbox user2 in Domain/Org A
Mailbox user1 is migrated to Domain/OrgB
Mailbox user2 replies to an old email from Mailbox user1
Mailbox user2 gets the following error:Subject: Undeliverable: Delivery failure (IMCEAex-_O=COMPANY_OU=COMPANYSJ_CN=RECIPIENTS_CN=[email protected])
Your message did not reach some or all of the intended recipients.
Any help would be greatly appreciated
Subject:
The following recipient(s) could not be reached:
IMCEAex-_O=COMPANY_OU=COMPANY_CN=RECIPIENTS_CN=[email protected] on 4/10/2007 10:30 AM
Mailbox user 2′s outlook cache on the old message has: /O=COMPANY/OU=COMPANYSJ/CN=RECIPIENTS/CN=YDAGAN in the Display field
Solutions tried:
Added x.500 address to Mailbox User1′s new contact in Domain/Org A that matches that listed in Mailbox user2 outlook cache for user1.
Added x.500 address in Mailbox user1′s new contact in Domain/Org A that matches that listed in the NDRStill getting NDR’s
-
Graeme,
Let me restate the problem to make sure I understand correctly. User 1 in Org A (we’ll call the source organization) sends an e-mail to User 2, also in the source organization. User 1 is then migrated, and his/her user object is replaced with a mail-enabled contact so that users in the source organization can still send e-mail to him/her. User 2, still unmigrated, replies to an e-mail from User 1 and gets an NDR.
The easiest way to handle this situation is to leave the original user object in place and modify the targetAddress attribute to point to a secondary SMTP address on the user’s mailbox in Org B (which we’ll refer to as the target organization). You won’t be able to do this through the UI; you’ll need to use something like ADSI Edit, dsmod, or admod. This allows the original user’s legacyExchangeDN to remain intact and sends all mail across to the target mailbox.
In theory, you should be able to add an X.500 address to the mail-enabled contact that matches the legacyExchangeDN of the original user object for User 1 in Org A and preserve the cache, but it sounds like you have already tried that. Verify that the X.500 address on the mail-enabled contact matches the legacyExchangeDN for the corresponding user object and let me know what you find.
-
I want to have your babies!
I am amazed how difficult it can be to get this simple piece of information from Microsoft which makes ALL OF THE DIFFERENCE in an Exchange migration. Where did you get it from?! I must be blind…
-
Matthew,
Um, I’ll have to pass on the whole babies thing….
The information actually came out of a failed attempt to use some Quest tools for an Exchange migration from one organization to a new organization. Along the way, we were able to glean a couple of useful little nuggets of information such as this one.
In the end, one of the guys working with me on the project wrote a totally kicking script that used the Microsoft Exchange Migration Wizard to handle the whole thing, and we ditched the Quest tools.
Glad you found this information helpful!
-
Ok, so here is a question then, although it doesn’t pertain directly to this posting…
How did you deal with Delegates? This is the last thing I need to figure out and I don’t want to use some mig tool.
If a userA has perms on the Inbox of userB and you migrate userA to the new Org, userA can no longer access userB’s inbox. How did you manage to get around this? Was your script capable of setting perms on userB’s inbox to reflect the newly migrated userA?
-
Matthew,
Honestly, I don’t recall exactly how we handled delegates. We had a complex dependency checker that attempted to map out relationships between users and the mailboxes–theirs or others–they accessed, including delegate relationships. But I don’t recall how we handled the permissions. Sorry!
-
Well according to MS, there is nothing you can do to make that work! I too am in the process of using output from PFDAVAdmin to get a web of permissions so I can see who has dependencies.
Thanks again,
-
Yes there is, use the Quest migration tools and hey presto, delegate access is retained.
But to use the Quest tools You MUST install them and configure them correctly, otherwise you will not be successfull. Better still – engage a Quest PS engineer! -
Allen,
Rather than a shameless plug for your product, how about contributing some useful information?
-
I know this thread is a little dead but i’m desperate. I have a exchange config pulling pop3 from my webhost for all my users in central office. It works great I can send, use OWA, receive, etc. I can NOT however figure out how to send to people outside my intranet with the same @domain.com address. ie i have assigned emails to people through the webhost outside central office and the exchange server. so when i try to send to [email protected] it won’t puch through the smtp. It’s almost like it doesn’t see the name in the pop connecter list and it just defaults to “The following recipient(s) cannot be reached:”.
I can send email to [email protected] and it goes imediately. Thus proving that mail sent to *@domain.com is not using smtp otherwise it would be checked ever fifteen minutes like all the other pop email. -
Jamey,
It sounds to me like you need to modify your Recipient Policy for @domain.com and make sure that the “This Exchange organization is authoritative” check box is NOT checked. Then ensure that you have an SMTP Connector ONLY for that address space that forwards all messages to the external mail host. That _should_ take care of the problem.
Good luck!
-
in Exchange 2007 can’t you just add an X500 address with these attributes to the migrated group’s recipient policy? Will this have any adverse affect?
-
Regarding J’s question:
1.) If that does work, the recipient policy would use the mailbox alias to form the X500 address, i.e., /O=Your-Exch-Org/cn=Recipients/cn=JDoe. That new X500 address might not match some migrated users’ legacyExchangeDN if the users had their aliases changed because of a name change.
If JDoe got married prior to the migration and her SMTP address and alias were changed to JSmith, her legacyExchangeDN would still be /O=Your-Exch-Org/cn=Recipients/cn=JDoe. If you migrated her mailbox and then applied the recipient policy to add the X500 address, it would use her NEW alias of JSmith to form the X500 address. So her new X500 address would not match her old legacyExchangeDN because different alias names were used. So that would defeat the purpose of this article.
2.) No, I don’t believe that adding the X500 address would have an adverse effect. If you have a lot of users, that would eat up some storage in your AD ntds.dit, but it should be negligible.
On another note, I’m getting ready to do a very small migration and don’t have a lot of time to test out other tools so I’ll have to do some things manually. Part of what I will do is use CSVDE to get information from the Exchange org that will bet migrated over.
I will run the command below with the specific user container in the -d switch. The export will get the mailbox alias, primary e-mail address, legacyExchangeDN (X500 address), and any additional addresses.
CSVDE -f C:\ExchageExport.csv -d “OU=Some-OU,DC=Some-Domain,DC=net” -r “(&(objectClass=user)(objectCategory=person))” -l “mailNickname, mail, legacyExchangeDN, proxyAddresses”
-
Does this problem affect Outlook Web Access users as well?
I did an address book sync from Domino to Exchange recently but before I did that I deleted all the contacts from the previous sync first. Once in a while users are getting an NDR with the IMCEAEX message and #550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##.
Users who have complained are only using OWA. Does OWA cached the original LegacyExchangeDN as well?
Thanks! a bit desperate for answer now…
Neil
-
I have a similar problem with Exchange 2007, the big difference is there havent been real migration, there was an “organization moving” process. Tho it causes the same issue. Some background:
There was FirmA and FirmB on the same Exchange 2003 server, same network. They splitted, FirmB got a new server at a remote site, on a different network with Exchange 2007. New domain, new users, new mailboxes. Data was exported to PSTs, and imported into the new mailboxes. Some users from FirmB remained in the office of FirmA, tho they have an IPSec VPN tunnel to the new network, so they can access everything there. There is a terminal server on the new network, if any user log into it from FirmB, set up Outlook to use the exchange 2007, everything’s fine. But if the leftbehind users from firmB (from completly new profiles on the same computer, with fresh Outlook settings) trying to send mails to any other FirmB recipient, they get the NDR. And yet, mystically sometimes some emails find their way thru. 1 out of 10 approx.
Any ideas about this?
Thanks
Ramon -
Always appreciate a nice ” totally kicking” script using the native tools. Any chance you might post it?
-
Recently ran into a problem with moving a company from one Exchange 2003/domain to different Exchange 2007/domain. I’ve had the same problem in the past but usually just deleted Outlook’s NK2 file which would do the trick. This company was using Apple Mail and Entourage and using the built-in clear autocomplete cache function did not resolve the issue. I went into ADSI Edit on their old server and found their legacyExchangeDN. You can’t copy this to the legacyExchangeDN on the new server which I’ve seen some people post. Instead, you can use this to create a string like ‘X500:/o=FIRST ORGANIZATION/ou=FIRST ADMINISTRATIVE GROUP/cn=Recipients/cn=[email protected]’. I used excel (concatenate fuction) to come up with a list of the new X500 addresses to create as they had multiple domains and aliases. Small number of users so the manual approach was fine. I wanted to create an Email Address Policy but apparently this reqiures a DLL for the Exchange Management Console to recognize X500. Exchange 2007 does of course support this function at a lower level so I just added this to ProxyAddresses in ADSI. A script would be nice for a larger number of users.
-
fyi I don’t think this still applies to Outlook 2007. I note that since I upgraded the client it shows ‘new’ entries in the autocomplete drop-down as
User <SMTP>
rather than
User <CN>
I checked in my NK2 file and sure enough whereas a pre-2007 contact has the X500, a ‘new’ one has the SMTP e.g.
Smith, John /O=org/OU=etc/CN=johnsmith Exchange Smith, John
Jones, Dave [email protected] Exchange Jones, DaveAnd someone whom I first emailed using 2003 but have since emailed using 2007 looks like this
Green, Bob [email protected] Exchange Green, Bob
i.e. has the autocomplete ‘display’ still left as user but actually uses the SMTP to send the email. So if your org started off using office 2007, or has been using it for a long period, then this probably won’t matter.
Dan
-
Hey,
Have anyone found a solution for this problem that actually work? We have a customer we moved into our exchange environment and whenever they reply on an old mail from an internal user they get the NDR problem.
Kalle
-
Exchange Issue
Here is my scenerio, I think it might be quite simple but I cant seem to figure it out.
I have a new hire lets call him David, mailbox has been created with no Issues so I thought. He comes up to me and says his display name is now David2.. I do have another David who has left the company and his account is disabled, I can’t delete it at this time. So does anyone why the new one was renamed David2 if the other(David) is no longer active? Or how to resolve this? Any help would be greatly appreciated.
-
Phillip, I believe that even if an account is disabled it will still enforce unique names. Perhaps this is the source of your issue?
-
I have a very similar problem. We had our exchange 2007 server crash so I built a new exchange 2007 server and created new users and imported old email from .pst and now it won’t let me reply to any old email. My LegacyDNS Settings are below from the old and new. What do I need to do to allow my users to reply to thier old emails?
Old: /o=First Organization/ou=Exchange Administrative Group(28FYDIBOHF23SPDLT)/cn=sherryg
New: /o=mincotech/ou=Exchange Administrative Group(28FYDIBOHF23SPDLT)/cn=sherryg
Any help would be Greatly appreciated.
Thanks,
Rex
-
Rex, it looks like you already have the information you need; you should be able to add an X.500 address using the LegacyDNS information to the newly rebuilt Exchange environment. Of course, keep in mind that this article is 5 years old, so things might have changed in that time…
Good luck!
-
I have a similar problem, but in our case we are migrating to Google, anyone knows how to add an X.500 adress in Google?
Thanks
Site Sponsors
25 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2007/02/15/preserving-nickname-cache-in-exchange-migrations/trackback/