Tuesday, February 25, 2014

User and Mailbox Migration – Part I (Introduction)

I am creating a few blogs about user and mailbox migration.  The plan is to explain different migration scenarios which exists in real world.  So far, I have 4 scenarios (listed below).  I may include a few more later. 

We can achieve all these migrations by using a free tool or a third party migration tool.  Since, a third party migration tools can provide more options and flexibility, I am planning to use Quest Migration Manager (QMM) for AD and Exchange for these migration scenarios. 

If you are not familiar with migration process, you can read my previous blogs from the following location:

ADMT and Migration Details

  1.  http://portal.sivarajan.com/search?q=user+migration&x=0&y=0
  2. http://portal.sivarajan.com/search?q=admt&x=0&y=0
  3. http://portal.sivarajan.com/search?q=migration&x=0&y=0

QMM and Migration Details

  1.  http://portal.sivarajan.com/search?q=QMM&x=0&y=0
  2. http://portal.sivarajan.com/search?q=Quest&x=0&y=0

Scenario #1 One-To-One

This is a straight forward migration.  You will be migrating resources from a source forest to a target forest  (one-to-one).

image

Scenario #2 One-To-Many

In this scenario, you will be migrating user account to an Account Forest and Mailboxes to a Resource Forest (one-to-many).  There mailboxes will be linked mailbox.

image

Scenario #3 Many-To-One

In this scenario, you will be going from a resource forest model to a single forest model (many-to-one).  AD and Exchange will be in the target forest.

image

Scenario #4 Many-To-Many

Here you will be moving users from source account forest to a target account forest and mailboxes from source resource forest to a target resource forest (many-to-many). 

image

 

The details and step-by-step instructions will be included future part of this blog. 

Basic Mail Routing Configuration to QMM for Exchange

Here are some of the basics Exchange configuration you need to complete before you can start migrating mailboxes using QMM.  My assumption is that you are going from Exchange2000/2003 to Exchange 2007/2010.

Source - Exchange 2003

  1. Create a RUS policy to allow the Exchange to be authoritative for the QMM EX SMTP Namespace (you can use any name space like source.qmm, source1.qmm etc).
    1. Create a new Recipient Update Policy.
    2. Name - Source.qmm or Source1.qmm
    3. Filter - Leave this blank. Anything configured here will cause the RUS policy to stamp addresses on the objects. QMM will stamp this value during the migration.
    4. Add the SMTP Address of "Source.qmm" or Source1.qmm and check the box "This Org is authoritative for this namespace"
    5. Click OK, to save the Policy.
  2. Create a new SMTP Connector as follows
    1. Name - Target.qmm or Target1.qmm (target name space for QMM internal mail routing)
    2. Assign the Exchange SMTP server that will service this connector as "SOURCE-EX01" (Source EX Server)
    3. Set the connector to forward all e-mail to a smart host (or use your current mail routing configuration)
    4. Set the Address space to "Target.qmm" or Target1.qmm with a Cost of 1
      Note 1: The cost of this connector must be lower than the internet connector. If the cost of the internet connection (*) is set to the same value as this connector, both the internet connector and the Target.qmm connector will service the Target.qmm SMTP namespace.
    5. Click ok to save the connector
      Note 2: The Routing Engine will have to be stopped and started for these changes to take effect. If not, they will take effect on the next refresh cycle (15 min default)
  3. Reconfigure the SMTP Virtual server to "Resolve to GAL: for all incoming mail and to allow the Target bridgehead to submit SMTP mail (if restricted)
    1. From the protocols node of Exchange server ->properties on the Default SMTP Virtual server, Click the Resolve to GAL check box.
    2. Verify that the SMTP Virtual server is not restricted to what IP addresses can submit mail, if it is Add the IP address on the Target bridgehead.
    3. Click ok to Save the connector.
    4. Note: The SMTP Virtual server will have to be stopped and started for this change to take effect.

Target - Exchange 2010

1. Create an Accepted Domain for the Target QMM Exchange SMTP Namespace (you can use any name space like Target.QMM, Target1.QMM etc) .

2. Create a Send Connector for the Source QMM Exchange SMTP Namespaces (Source.QMM or Source1.QMM)

3. Configure it to forward all messages to the Source Exchange bridgehead's IP Address or FQDN.

a. Set the namespace to Source.QMM or Source1.QMM with a cost of 1.

4. Create a Receive connector on Target Exchange.

    1. Click on Create new Receive connector.
    2. Define as Custom.
    3. The IP/Port it listens on will be unchanged. The same IP address that services port 25 must be used.
    4. The IP that will submit messages should be defined.
    5. Commit the changes.
    6. Edit the connector to the following security settings:
    7. Externally Secured ONLY
    8. Exchange Servers ONLY

 

 

  1. Part1 - User and Mailbox Migration (Introduction)
  2. Part2 - Scenario #1 (One-To-One)
  3. Part3 - Scenario #2 (One-To-Many)
  4. Part4 - Scenario #3 (Many-To-One)
  5. Part5 – Scenario #4 (Many-To-Many)

2 comments:

Why are you migrating from here? Many readers like your content, and they want to increase their knowledge which is necessary for spending a good life. Dissertation writing service.

The quickbooks user need to install various software which get affected by the bugs so it can be fixed by the quickbooks diagnostic tool

Post a Comment

Popular Posts

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites More