cancel
Showing results for 
Search instead for 
Did you mean: 

Greenfield Migration of AD and Exchange

Mike_Dowling
Level 4
Here's the scenario.

Current environment:

One Domain (Windows 2000 AD)
Two Exchange Sites (Exchange 5.5)
Archiving is complete and no longer running, it was a one time archive. So if I need to keep archiving I just zap the mailbiox and create a second vault for the new mailbox in the new domain and Exchange server. I'm more concerned with being able to have the users pull up their data from a shortcut.

Going to:

Completely new Forest, Domain, upgraded to Windows 2003 AD, Exchange 2003

Users will be migrated with SID history via Quest migration tool.

First pahse

Users accounts and mailboxes are migrated to the new AD and Exchange environment via Quest. Vault, SQL Servers reside in the old domain. All trusts are completely set up. Users will only need to bring up archived messages via the shortcut in their inboxes from the vault in the old domain. Users do not use the web application, it is removed.

Second phase:

Archiving servers and SQL servers will be moved into the new environment (same domain as the 2003 Exchange servers, and AD where the users reside). A new service account will be set up.

Silly question but anyone do this before? And what complciations do you guys foresee?Message was edited by:
Mike Dowling
1 ACCEPTED SOLUTION

Accepted Solutions

Tremaine
Level 6
Employee Certified
Loads of complications here dude.
1. Mapping of permissions from the new domain onto your existing Exchange servers so as to sync the AD user perms across to the vault server (Additional MBX owner - one on one mapping). EV will not know that the users have been migrated to a new domain so you need to tell it.

2. Mapping the new mailboxes to the existing vaults if the EV hidden message is not migrated across (Although I believe the quest SW can do this) and also if the legacyDN changes -- ouch. (Got to be real careful here)

3. Making sure that EV still has access to SQL DB's as owner after the account change. (You will need to remap the dbo to the new account for each EV DB)

View solution in original post

5 REPLIES 5

Tremaine
Level 6
Employee Certified
Loads of complications here dude.
1. Mapping of permissions from the new domain onto your existing Exchange servers so as to sync the AD user perms across to the vault server (Additional MBX owner - one on one mapping). EV will not know that the users have been migrated to a new domain so you need to tell it.

2. Mapping the new mailboxes to the existing vaults if the EV hidden message is not migrated across (Although I believe the quest SW can do this) and also if the legacyDN changes -- ouch. (Got to be real careful here)

3. Making sure that EV still has access to SQL DB's as owner after the account change. (You will need to remap the dbo to the new account for each EV DB)

Mike_Dowling
Level 4
"1. Mapping of permissions from the new domain onto your existing Exchange servers so as to sync the AD user perms across to the vault server (Additional MBX owner - one on one mapping). EV will not know that the users have been migrated to a new domain so you need to tell it. "

This is my biggest worry, the Quest software apparently keeps SID history, so to the vault it will think the new mailbox is the old mailbox. If this doesn't work, I believe I can zap the users then re-enable them and map them to their original vault (display names will be the same). Worst case I can have two vaults for each user. On the users end they only have the shortcut which will be migrated to the new mailbox. All rights to the vault server will be set up, as will the new service account in the SQL db's.

Can you expand on the legacy DN issue? I am not sure if this applies to me or not. I have a lab set up exactly like this scenario, I'm migrating a user next week, I'll probably have more questions after that.

David_Messeng1
Level 6
Are you going to try to move the X500 address with the mailbox?

You will need to map the old Vaults to the new DNs otherwise arhciving will fail. You then will need to reenable them if Quest has not taken over the EV settings properly. Don;t know if it can do this.

SID history won't help much and if you want to preserve it make sure EV does not synch against the server you have moved mailboxes off

Off the top of my head:

InBox rules
Auto sigs and other profile stuff
OAB expansion server
Replies to old emails
Custom Recpients
MAPI profile won't auto-remap
SMTP domain
Knackered mailboxes that just refuse to move

I guess Quest copes with this stuff ok?

Have fun :)

Mike_Dowling
Level 4
Are you going to try to move the X500 address with the mailbox?

Quest will move the original x.500 address, as well associate the old SID with the new mailbox.

You will need to map the old Vaults to the new DNs otherwise arhciving will fail

The beauty of this and probably my saving grace, is there is no more archiving. We archived 30,000 users for legal retention reasons of older mail residing in the users mailboxes. (I also have a large journaling system set up) but the archive was to grab everything that was prior to journaling being set up. But archiving is finished for these mailboxes. So the only thing I need is user X double clicks a shortcut in the new environment and his mail w/attachment pops up.

You've been very helpful, I'll leave this as unanswered just so others can give their $0.02, thanks...

David_Messeng1
Level 6
OK. Watch out for the PAB continuing to point at the old server. This one's caught a few people I know of.