Migrating Exchange to a New Domain

When teaching about Exchange Server 2007, many questions about migration and transition from old messaging platforms arise. Coming to Exchange Server 2007 from GroupWise, Notes, and other systems naturally have a number of factors to be considered, yet even coming to Exchange Server 2007 from earlier versions of Exchange Server involves many possible approaches and choices. The following question is not uncommon:

We are in the process of moving to a new domain. I’m being told to look into what would be the best way to move/migrate all the users over to the new domain. One of the recommendations is to build a new Exchange box on the new domain and then move all the mailboxes over to the new Exchange server in the new domain.

My first question is “Is the new domain in the same Active Directory forest as the first?”

My second question is “Will the old domain still exist after the migration?”

Without the answers to these questions, I could describe a few scenarios leading to different directions and rather dissimilar tactics and final solutions.

However for the moment, I’ll assume that you’re talking about using a separate forest and that the original domain (and perhaps forest) will no longer exist after the migration. That’s not all that unusual – I’m not saying that everyone does that, but it’s not uncommon either.

Migrating Mailboxes to Another Forest

When the target domain is in another forest, it is also in another Exchange organization because in Exchange Server 2007 each Active Directory forest can support one Exchange organization and that messaging organization structure is based on and tied to the forest. Also, domain rename of Active Directory is not currently supported with Exchange Server 2007 installed in the forest due to some hard-coded FQDNs. Those are probably some of the reasons such a migration has been recommended to you.

  1. Establish network connectivity between the forests.
  2. Associate the two forests at a domain name system (DNS) level.
  3. Consider trust relationships between the forests.
  4. Establish Exchange Server(s) in the new environment if you haven’t already done so.
  5. Configure the proper connectors for mail flow between the Exchange environments.
  6. Move mailboxes over to the new environment, creating the user accounts along with them.
  7. Move public folders if you have them to the new environment.
  8. Move any relevant connectors from the old environment to the new.
  9. Consider the exit plan for decommissioning the old environment.

This list isn’t a strict guide, just a possible overview of one approach to the process. Let me know if you have questions on details or whether all of these aspects are necessary for your plan. I hope this helps!

-Brad Werner

Related Courses

Microsoft Exchange Server 2007

Ultimate Exchange Server 2007

In this article

Join the Conversation

5 comments

  1. Randy Reply

    Kinda funny I ran into this article now. We just finished a project to migrate from Novell GroupWise to Microsoft Outlook, as well as merging two domains into one.

    1. timatgk Reply

      Glad you found us, Randy!

  2. Steven Scott Reply

    I’ve run into a problem performing a migration from one forest to another. Your step 5 makes reference to configuring mail flow between the Exchange environments, but both servers are to service the same SMTP domain name. How do I route messages when they don’t see the users in each domain. For example, if I try to send an email from bob@domain.com to jim@domain.com and each of the users in the different forest, the email is returned as “unknown mailbox”.

    Please help!

  3. Brad Werner Reply

    Steven,

    Exchange Server 2007 has three kinds of accepted domains: Authoritative, Internal Relay, and External Relay. The problem with authoritative domains is the Exchange takes that “authoritative” designation quite literally – if a mailbox isn’t found in this forest for the local part (e.g. “bob” or “jim”) in that domain, Exchange authoritatively sends a non-delivery report (NDR). Game over.

    Therefore, what it sounds like you want is an Internal Relay domain. Don’t take this name so literally. It could have been called a “maybe some recipients are Internal (in this forest), but if not I won’t send an NDR right away, it might be a Shared domain, therefore I’ll try to Relay to any other messaging systems for which I also have a Send Connector.” That’s a long name, yet that’s how Exchange Server treats an Internal Relay domain.

    In other words, if both forests have domain.com listed as an Internal Relay accepted domain (not Authoritative), then they’ll try to deliver locally but if that fails they’ll try elsewhere too.

    How do you configure where elsewhere is, so that it routes to the other forest? The accepted domain doesn’t specify that! You need Send connectors in each forest with domain.com (with or without subdomains) as the address space of each send connector. The smart host(s) to relay to? That would be the visible gateways to the other forest’s messaging platform (e.g. Exchange).

    I hope this helps.

  4. Andy Fratesi Reply

    I have a question about the last comment

    “How do you configure where elsewhere is, so that it routes to the other forest? The accepted domain doesn’t specify that! You need Send connectors in each forest with domain.com (with or without subdomains) as the address space of each send connector. The smart host(s) to relay to? That would be the visible gateways to the other forest’s messaging platform (e.g. Exchange).”

    If you have both Exchange Server 2007 servers setup as ‘Internal Relay’ and send connectors in each forest using smart hosts how do you deal with NDR? For example, if someone externally sends and email to someone at domain.com; a bogus account it will get stuck in a loop; ” local loop was detected”. How do you take care of this?

    Thanks