Exchange 2013: question about migration mechanics
Hi, all! Current environment is two (2) Exchange 2010 stand-alone servers, each in different locations over WAN; three Exchange 2013 servers in DAG in two different locations. Each site has its own database of users. Currently half-way thru migration of Ex2010 users to Ex2013. One of the two 2013 servers at the one location is a virtual (Citrix), the other servers physical.
I've had a number of issues with *extreme* lag as a result of HADuration, and was curious exactly how migrations of individual mailboxes occurred in an environment such as ours. In the first database of users (finished now) migrating from Ex2010 to Ex2013 server (both active databases at a single location), we would see substantial delays of up to 80-90% (I posted an unresolved question about it here).
I'm now in the process of beginning the mailbox moves at the other location from one Ex2010 database to an Ex2013 database (completely different databases from first batch of migrations). My question is basically this: given that I have both the source and target databases at a single location *and* I'm performing the migrations from that site's primary DAG server, how *exactly* are the user mailboxes moved? Will the mailbox be moved from SiteA-Ex2010 to SiteA-Ex2013 (active copy), then SiteA-Ex2013 replicated to SiteB-Ex2013 (passive copy) for the given database? Or does the move go from Ex2010 to PASSIVE Ex2013 copy? Or does activation order of the database play into the sequence?
I ask because on the first database of mailboxes in an attempt to resolve the *heavy* lag issue I stopped replication between the sites, but that caused the migration of select users to not even work at all. [Also shut off indexing, but that had zero effect on the lag issue.] I can't find any documentation on the mechanics that tell me what's what here, and rather than wondering in silence I thought that perhaps documenting it here might help others in the future.
Any thoughts or suggestions welcome! Thanks!
SteveInReno
I've had a number of issues with *extreme* lag as a result of HADuration, and was curious exactly how migrations of individual mailboxes occurred in an environment such as ours. In the first database of users (finished now) migrating from Ex2010 to Ex2013 server (both active databases at a single location), we would see substantial delays of up to 80-90% (I posted an unresolved question about it here).
I'm now in the process of beginning the mailbox moves at the other location from one Ex2010 database to an Ex2013 database (completely different databases from first batch of migrations). My question is basically this: given that I have both the source and target databases at a single location *and* I'm performing the migrations from that site's primary DAG server, how *exactly* are the user mailboxes moved? Will the mailbox be moved from SiteA-Ex2010 to SiteA-Ex2013 (active copy), then SiteA-Ex2013 replicated to SiteB-Ex2013 (passive copy) for the given database? Or does the move go from Ex2010 to PASSIVE Ex2013 copy? Or does activation order of the database play into the sequence?
I ask because on the first database of mailboxes in an attempt to resolve the *heavy* lag issue I stopped replication between the sites, but that caused the migration of select users to not even work at all. [Also shut off indexing, but that had zero effect on the lag issue.] I can't find any documentation on the mechanics that tell me what's what here, and rather than wondering in silence I thought that perhaps documenting it here might help others in the future.
Any thoughts or suggestions welcome! Thanks!
SteveInReno
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I have no idea whether the mailbox content is separated in any way. I suspect the messages are moved as items, with their associated attachments. That is based on errors around individual messages and attachments that have been thrown during the move mailbox.
They also generate the logs in the same way as normal traffic, so you will need to use circular logging if moving a lot of content to keep the logs down.
Simon.
They also generate the logs in the same way as normal traffic, so you will need to use circular logging if moving a lot of content to keep the logs down.
Simon.
ASKER