Skip to main content

Microsoft

Unable to Move Mailboxes from Exchange 2003 to Exchange 2010

Background
I recently struggled with the inability to move mailboxes from Exchange 2003 to Exchange 2010 while helping one of my customers. The environment consisted of a Single Exchange Organization residing in a Single Forest with Multiple Domains within the Forest. The Exchange 2003 Servers and the Exchange 2010 Servers resided in the same Forest, but Different Domains.
The challenging part about this issue was the fact that 80% of my mailbox moves completed successfully while 20% were failing with the following error:

Log Name: Application

Source: MSExchange Mailbox Replication

Event ID: 1100

Description:

Request ‘domain1.test.com/Users/TestUser1’ (13db0622-cd2b-4d79-8a12-6170d494cc66) failed.

Error code: -2147221246

MapiExceptionNoSupport: IExchangeFastTransferEx.TransferBuffer failed (hr=0x80040102, ec=-2147221246)

See screen shot of the error below:

I did manage to find some blog posts and a Microsoft forum that contained suggestions from others who have received a similar error. One such blog can be found here, and a helpful Microsoft forum discussion can be found here. I include them as references because the forum contained a suggestion that did actually resolve my problem, even though I tried it last because I never thought the suggestion would work. Since this was such a strange issue, I thought I’d share the one solution that resolved my problem in the end. Before I do that, I’ll list everything I tried that did not resolve my problem. Here’s what I tried that did not work:

  1. Moved problematic mailbox to another Exchange 2003 database and retried mailbox move command
  2. Moved problematic mailbox to another Exchange 2003 database on a different Exchange 2003 Server and retried mailbox move command
  3. Moved problematic mailbox to a newly created, empty Exchange 2003 database and retried mailbox move command
  4. Dismounted newly created Exchange 2003 database, ran ISINTEG with the ‘repair all errors’ switch, remounted the database, and retried the mailbox move command
  5. Used PFDavAdmin to check and fix DACLs on problematic mailbox and retried the mailbox move command
  6. Validated all Active Directory and Exchange permissions on problematic mailbox (ensured that all AD and Exchange permissions were identical on a mailbox that failed and a mailbox that moved successfully)
  7. Deleted all search folders in the problematic mailbox and retried the mailbox move command
  8. Deleted all calendar permissions on the problematic mailbox and retried the mailbox move command
  9. Detached the problematic mailbox from its primary Active Directory account, reattached the mailbox to a different account, and retried the mailbox move command

Resolution
If you read through the Microsoft forum that I mention earlier, you will find that some of the remedies I tried actually worked for some other people experiencing a similar issue. Using PFDavAdmin seemed to do the trick for quite a few people, but it did not work for me. In the end, after exhausting every other possibility, I finally did the following:

  1. Downloaded Exchange 2010 RTM (I found it here on Microsoft’s website)
  2. Installed Exchange 2010 RTM on a virtual server with the Mailbox and CAS Roles
  3. Created a database on the Exchange 2010 RTM Server
  4. Used the Exchange 2010 RTM Management Console to move the problematic mailbox to the database residing on the Exchange 2010 RTM Server
  5. Moved the problematic mailbox from the database on the Exchange 2010 RTM Server to a database on an Exchange 2010 SP1 Server

A few things to note about my solution:

  • I had to use the Exchange 2010 RTM Server to move the mailbox from Exchange 2003 to Exchange 2010
  • I was able to use any Exchange 2010 Server (RTM or SP1) to move the mailbox from Exchange 2010 RTM to Exchange 2010 SP1
  • Initially, I could not get the Exchange 2010 RTM Server to move any mailboxes. The issue stemmed from the fact that my 2003 and 2010 Servers resided in different Domains and I needed to add the fully qualified DNS Search Suffix for each Domain to each server. For example:
    • Here are the FQDNS of my servers:
      • EX2003.domain1.test.com
      • EX2010.domain2.test.com
    • I had to add DNS Search Suffixes in the following manner:
      • On EX2003.domain1.test.com make sure to add domain2.test.com as a DNS Search Suffix
      • On EX2010.domain2.test.com make sure to add domain1.test.com as a DNS Search Suffix
      • The rationale for this is that my testing indicates that the Mailbox Replication Service (which is the service responsible for moving mailboxes) performs Exchange Server name lookups using NetBIOS name resolution instead of FQDN resolution. Without proper DNS Search Suffixes defined on your Exchange 2010 RTM Server, mailbox moves fail.

Discussion
I have performed over a dozen Exchange 2010 SP1 deployments for my various customers ranging in size from 1,000 to 30,000 seats and until now I have never run into this problem before. I don’t like this solution because it requires adding an additional server to a customer’s production Exchange environment. Not only that, but it just seems wrong to install Exchange 2010 RTM (released in November 2009) into a production Exchange 2010 SP1 environment to resolve a mailbox migration issue. Nonetheless, this is the only acceptable solution that I have found for my customer.
My Exchange 2010 SP1 Servers are running Roll Up 3 Version 3. Roll Up 3 Version 3 is the only difference between my past Exchange 2010 deployments and this current deployment. With the challenges Microsoft had with Roll Up 3, I wouldn’t be surprised if something within Roll Up 3 is causing this issue. That’s just a theory on my part so if you have had similar challenges moving mailboxes to Exchange 2010 SP1 please add a comment and let me know. This migration is currently ongoing, so if I learn any new information I will post an update.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram