Migrate Exchange 2010 SP1 to another Domain in same Forest
So we were recently acquired by a large company and they no longer have a need for one of our domains. As it so happens that is the domain that our Exchange 2010 SP1 environment is on.
As it stands we have a single forest and exchange is serving 2 domains within that forest. We have domain 1, we'll call it ITS1.COM, which is also the forest. Then we have domain 2, we'll call it MTC2.COM. The exchange environment was originally built in the MTC2.COM domain. It was built as Exchange 2003 and was upgraded to 2010 almost a year ago now. I walked into the mix about 5 months ago to take over for a guy who was retiring. He retired a month ago.
We originally had 2 CAS/HUB servers (CAS Array, hardware load balanced), 2 MBX servers (DAG), and 1 MBX server for archiving only. We have a 3rd party solution out in the DMZ for filtering/bridgehead/edge (SonicWall). All servers are members of the MTC2.COM domain.
Since servers in a DAG have to be in the same domain it created a brain teaser of how we would accomplish the task at hand. What we did was we recreated/rebuilt all of the servers on the ITS2.COM domain, same site as before, new server names of course. The new servers were all immediately recognized in the exchange environment. I created new DB's, in a new DAG. Before there was no real rhyme or reason to which mailboxes went in which DB, so I took the opportunity to make one A-M and the other N-Z. Configured the CAS's for the new domain and load balancer/Virtual IP (mail.its1.com), complete with new SSL certs by the same name. I haven't created the new CAS Array yet, but the new CAS's were immediately added to the old CAS Array (mail.mtc2.com) because they're in the same site. The DB's and CAS's have been configured with the appropriate Client Access settings. Talk about a pain trying to sort that out, cert errors everywhere at first. The external DNS records have been configured. I have yet to finish the updates of our internal DNS records, though a few basic changes were made (mail.its1.com points to VIP of new CAS). I performed a few local mailbox moves from the old DB's to the new ones, making use of new storage scheme, and they have been functioning with no issues for nearly a month.All archiving has been turned over to the new servers and the old archive MBX has been turned. And, I copied all the receive connectors over to the new CAS's.
I'm sure there's more that's been done I just can't remember right now, feel free to ask...
What I'm looking for is confirmation that this was a good course of action and what my next steps should be. From what I can figure we still need to:
1- Move all of our mailbox users from the old DAG to the new one.
2- Create new CAS Array.
3- Move a whole DB from the old DAG to the new one in the most efficient manner.
4- Config Edge servers (SonicWall) to point to new CAS/VIP Load Balancer
5- Update/Change internal DNS
6- Hunt down/find applications using old IP's to use CAS relays or anything else.
Not necessarily in this order...
Can anybody think of anything else I may be missing? I don't want to forget something and then when it comes time to bring all the old servers down email goes down with it and I have no clue why.
Also, any advice on the above steps would be great as well. I'll share my initial thoughts on them for your advice, and anybody else who finds this topic and could possibly benefit from it.
1- Move mailbox users - I haven't created any DB copies in the new DAG yet so that the mailbox moves are quicker and the effort isn't duplicated on both servers. I've been using the EMC. Under Recipient Configuration > Mailbox I use the filter to only show me mailboxes on the DB's I want to move from. Sort by Display name. At the end of the day before I go home I'll select 60 or so mailboxes and do a New Local Move Request... A-M go to one new DB and N-Z go on another one. I also select Suspend this move when it is ready to complete... this pre-stages the mailbox on the new DB without actually cutting over to the new DB/Mailbox or disturbing the users. When my manager says it's time within the next week or two and we schedule a maintenance period I'll just select them all, or rather large groups of them at a time, and select Complete Move Request. At that point it'll just be a sync of changes since the pre-stage, and then cut-over.
2- New CAS Array - I was going to create the new one with the new name, the same name as the Load Balancer VIP (mail.its1.com), same site as the other. Then delete the old one (mail.mtc2.com). Can two CAS Arrays exist for the same site? Any conflicts or problems with that.
3- Move DB to new DAG - I'm not really sure of an efficient manner to move a whole DB. I was reading something about moving a database using database portability (linky), and that looked like a good idea but wasn't sure if this is what I was looking for or if there was a better way. Could really use some advice on this...
4- Config SonicWall - This should be pretty straight forward, but I'm going to call tech support just in case.
5- Internal DNS changes - I need to update the MBX records and an alias for mail.mtc2.com to point to mail.its1.com ... Probably something else I can't remember too...
6- PIN IN THE BUTT!!! I think I'll just end up switching over and seeing if anything stops working. I'm fairly confident that everything is using DNS.
I hope this helps some other people out there in the same situation and thanks for any help and advice.
James
As it stands we have a single forest and exchange is serving 2 domains within that forest. We have domain 1, we'll call it ITS1.COM, which is also the forest. Then we have domain 2, we'll call it MTC2.COM. The exchange environment was originally built in the MTC2.COM domain. It was built as Exchange 2003 and was upgraded to 2010 almost a year ago now. I walked into the mix about 5 months ago to take over for a guy who was retiring. He retired a month ago.
We originally had 2 CAS/HUB servers (CAS Array, hardware load balanced), 2 MBX servers (DAG), and 1 MBX server for archiving only. We have a 3rd party solution out in the DMZ for filtering/bridgehead/edge (SonicWall). All servers are members of the MTC2.COM domain.
Since servers in a DAG have to be in the same domain it created a brain teaser of how we would accomplish the task at hand. What we did was we recreated/rebuilt all of the servers on the ITS2.COM domain, same site as before, new server names of course. The new servers were all immediately recognized in the exchange environment. I created new DB's, in a new DAG. Before there was no real rhyme or reason to which mailboxes went in which DB, so I took the opportunity to make one A-M and the other N-Z. Configured the CAS's for the new domain and load balancer/Virtual IP (mail.its1.com), complete with new SSL certs by the same name. I haven't created the new CAS Array yet, but the new CAS's were immediately added to the old CAS Array (mail.mtc2.com) because they're in the same site. The DB's and CAS's have been configured with the appropriate Client Access settings. Talk about a pain trying to sort that out, cert errors everywhere at first. The external DNS records have been configured. I have yet to finish the updates of our internal DNS records, though a few basic changes were made (mail.its1.com points to VIP of new CAS). I performed a few local mailbox moves from the old DB's to the new ones, making use of new storage scheme, and they have been functioning with no issues for nearly a month.All archiving has been turned over to the new servers and the old archive MBX has been turned. And, I copied all the receive connectors over to the new CAS's.
I'm sure there's more that's been done I just can't remember right now, feel free to ask...
What I'm looking for is confirmation that this was a good course of action and what my next steps should be. From what I can figure we still need to:
1- Move all of our mailbox users from the old DAG to the new one.
2- Create new CAS Array.
3- Move a whole DB from the old DAG to the new one in the most efficient manner.
4- Config Edge servers (SonicWall) to point to new CAS/VIP Load Balancer
5- Update/Change internal DNS
6- Hunt down/find applications using old IP's to use CAS relays or anything else.
Not necessarily in this order...
Can anybody think of anything else I may be missing? I don't want to forget something and then when it comes time to bring all the old servers down email goes down with it and I have no clue why.
Also, any advice on the above steps would be great as well. I'll share my initial thoughts on them for your advice, and anybody else who finds this topic and could possibly benefit from it.
1- Move mailbox users - I haven't created any DB copies in the new DAG yet so that the mailbox moves are quicker and the effort isn't duplicated on both servers. I've been using the EMC. Under Recipient Configuration > Mailbox I use the filter to only show me mailboxes on the DB's I want to move from. Sort by Display name. At the end of the day before I go home I'll select 60 or so mailboxes and do a New Local Move Request... A-M go to one new DB and N-Z go on another one. I also select Suspend this move when it is ready to complete... this pre-stages the mailbox on the new DB without actually cutting over to the new DB/Mailbox or disturbing the users. When my manager says it's time within the next week or two and we schedule a maintenance period I'll just select them all, or rather large groups of them at a time, and select Complete Move Request. At that point it'll just be a sync of changes since the pre-stage, and then cut-over.
2- New CAS Array - I was going to create the new one with the new name, the same name as the Load Balancer VIP (mail.its1.com), same site as the other. Then delete the old one (mail.mtc2.com). Can two CAS Arrays exist for the same site? Any conflicts or problems with that.
3- Move DB to new DAG - I'm not really sure of an efficient manner to move a whole DB. I was reading something about moving a database using database portability (linky), and that looked like a good idea but wasn't sure if this is what I was looking for or if there was a better way. Could really use some advice on this...
4- Config SonicWall - This should be pretty straight forward, but I'm going to call tech support just in case.
5- Internal DNS changes - I need to update the MBX records and an alias for mail.mtc2.com to point to mail.its1.com ... Probably something else I can't remember too...
6- PIN IN THE BUTT!!! I think I'll just end up switching over and seeing if anything stops working. I'm fairly confident that everything is using DNS.
I hope this helps some other people out there in the same situation and thanks for any help and advice.
James
You cannot move mailboxes between Exchange Servers that are not in the same Exchange Org,....it sounds to me like the old Exchange Org is being wiped out and a new Exchange Org is being built..
ASKER
Perhaps "Move" would be a more appropriate word. Though moving all data from one set of servers to another and then shutting down the old servers sounds more like a migration. But that's just my opinion.
Technically the Exchange Organization isn't going anywhere. It's staying the same. The Exchange Organization is based on the Active Directory Forest and Schema (which is very different in 2010 vs 2003). For the most part, and I think as with 2003, all of the Exchange Org information is stored in Active Directory. We're just adding new Exchange servers to the Exchange Org that are joined to a different domain, same forest, and then moving all data and settings over.
Building an all new Exchange Org sounds completely unnecessary, especially considering the fact that I've almost completed the move with not too many issues without doing that. Perhaps I misunderstood your posts, maybe you pointed out a reason why what I have done so far isn't going to work and I missed it, or perhaps the differences in Exchange 2003 and 2010 are to blame.
I would assume that when trying to accomplish a migration or a move, whether that's what I'm doing or not, the steps that I mentioned are definitely not outside the scope of that. The steps are very necessary to have a completely functioning solution once the task is complete. Which of course is exactly the scope of my question. I am asking what steps I may be missing to make sure my exchange environment functions exactly as it did before I made the move/migration. Which is usually the point of a tasking of this nature.
Thanks for your response, pwindell, and taking the time to read my insanely long post. Whether I agree with what you say or not doesn't mean I don't appreciate your effort and input. Any more responses are completely welcome.
James
Technically the Exchange Organization isn't going anywhere. It's staying the same. The Exchange Organization is based on the Active Directory Forest and Schema (which is very different in 2010 vs 2003). For the most part, and I think as with 2003, all of the Exchange Org information is stored in Active Directory. We're just adding new Exchange servers to the Exchange Org that are joined to a different domain, same forest, and then moving all data and settings over.
Building an all new Exchange Org sounds completely unnecessary, especially considering the fact that I've almost completed the move with not too many issues without doing that. Perhaps I misunderstood your posts, maybe you pointed out a reason why what I have done so far isn't going to work and I missed it, or perhaps the differences in Exchange 2003 and 2010 are to blame.
I would assume that when trying to accomplish a migration or a move, whether that's what I'm doing or not, the steps that I mentioned are definitely not outside the scope of that. The steps are very necessary to have a completely functioning solution once the task is complete. Which of course is exactly the scope of my question. I am asking what steps I may be missing to make sure my exchange environment functions exactly as it did before I made the move/migration. Which is usually the point of a tasking of this nature.
Thanks for your response, pwindell, and taking the time to read my insanely long post. Whether I agree with what you say or not doesn't mean I don't appreciate your effort and input. Any more responses are completely welcome.
James
In your subject line it is basically saying "different Domain, same Forest" but I had first interpreted it to be "different Domain, different Forest". Sorry for the misunderstanding.
Since you are staying in the same Forest and then staying in the same Exchange Org,..then yes the "Move Mailbox" functionality that is within Exchange would move the mailboxes. After all the mailboxes are moved this way be sure to leave the old Exchange functional for several days or even longer,...it will take time for Outlook to auto-adjust tot he new "homing" of the mailboxes (perhaps more time than you may expect). Then when you think it is ready power off the old Exchange (or just unplug the Nic cable) and let it go for a few days again,...this will root out any unexpected Outlook Clients that did not adjust properly.
As far as Migration or not a migration,...the MS MVP that I got most of my ideas from on moving from Exhc2003 to Exch2007 or 2010 defines it as a Transistion and not a migration,...he had specific reasons for that but I don't remember what they were. Here below is a link to his articles that you might find useful. Even though you are going to 2010 rather than 2007 in the articles, everything should still apply.
http://www.msexchange.org/tutorials/transitioning-exchange-2000-2003-exchange-server-2007-part1.html
http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server-2007-Part2.html
http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server-2007-Part3.html
Since you are staying in the same Forest and then staying in the same Exchange Org,..then yes the "Move Mailbox" functionality that is within Exchange would move the mailboxes. After all the mailboxes are moved this way be sure to leave the old Exchange functional for several days or even longer,...it will take time for Outlook to auto-adjust tot he new "homing" of the mailboxes (perhaps more time than you may expect). Then when you think it is ready power off the old Exchange (or just unplug the Nic cable) and let it go for a few days again,...this will root out any unexpected Outlook Clients that did not adjust properly.
As far as Migration or not a migration,...the MS MVP that I got most of my ideas from on moving from Exhc2003 to Exch2007 or 2010 defines it as a Transistion and not a migration,...he had specific reasons for that but I don't remember what they were. Here below is a link to his articles that you might find useful. Even though you are going to 2010 rather than 2007 in the articles, everything should still apply.
http://www.msexchange.org/tutorials/transitioning-exchange-2000-2003-exchange-server-2007-part1.html
http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server-2007-Part2.html
http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server-2007-Part3.html
ASKER
Thanks. I'll take a look at these, and will leave the old environment up for a while after the transition is done like you suggested.
Any more advice or response to my questions?
Anybody Else?
Any more advice or response to my questions?
Anybody Else?
ASKER
So two CAS Arrays cannot exist for the same site... so I'll have to delete the old one then create the new one. Any thoughts or suggestions on this?
Anything about database portability?
Anybody?
Anything about database portability?
Anybody?
Sorry,...I'm acronymed to death. I don't remember what C.....A....S even means anymore.
If this is a "different domain, same forest" then would it not be a different Site? Is a Site tied to a Domain or to a Forest? If Domain then this would be a different Site and would work. Maybe someone who knows more about that specific thing can jump in here.
Or maybe create a new question in a relevant Forum for just that CAS aspect of this.
Or maybe create a new question in a relevant Forum for just that CAS aspect of this.
ASKER
CAS = Client Access Server
Sites are per Forest. So multiple domains, same forest, same site(s). Sites are used for routing.
Sites are per Forest. So multiple domains, same forest, same site(s). Sites are used for routing.
Ok. Well maybe you might want to create a new question for just that aspect of it. When people look at these questions they go for the ones that 0, 1, or 2 replies. When they have a lot more replies than that they tend to skip them an go tot he next question figuring it already has progressed and gotten answers. So I think at least part of what you were asking has been dealt with here, so I would shrink the question down and narrow the focus to CAS and post a new question to cover that,...you'll probably get better responses that way.
Sorry I couldn't deal with all of it, but you had a pretty broad scope here.
Sorry I couldn't deal with all of it, but you had a pretty broad scope here.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I followed my own advice.
You create a New Exchange in a New Exchange Org in a New Domain and it will generate New "empty" mailboxes.
You then copy the mailbox contents from the old mail system into the empty mailboxes in the new system.. With Exchange2003 that was done by Exmerge which exported the contents into PST files that would then be transported to the new system and the using Exmerge again would import them in. With Exchange newer than 2003 you can't use Exmerge and have to use a command line process,...I don't personally have any details on that (I still use Exchange2003).
A lot of the other stuff you are asking is way way way outside the scope of just simply "migrating" Exchange that your subject line is implying. You're asking about an entire restructuring of everything that exists in the facility,..I can't deal wit that.