2 New Servers and New Storage Migration (Full Version)

All Forums >> [Microsoft Exchange 2003] >> Migration



Message


taga_ipil -> 2 New Servers and New Storage Migration (16.Nov.2010 11:45:01 AM)

Hi Guys,

Good Day.

Needed some directions on how to correctly execute the migration.

- We have 2 new servers and a new storage.
- We have 2 current node (WS2003 Ent) Exchange 2003 Clustered. S1a and S1b


Here's my take, assuming all new Disks are visible on the Resource.
and visible to nodes. Lets name it S2a and S2b

1. Install the 2 new servers. Updated and Patched.
2. Join S2a and Join to Cluster. Which make Cluster node a total of 3.
3. Move the Quorum to new specified disk.
4. Offline all Servers and move Transaction Logs to a new Disk.
5. Move those EDB and STM to new Disk.
6. Unmount, Point the Mailbox Store EDB and STM to the new Location. Remount.

7. Make S2a the owner
8. Evict S1a
9. Join S2b
10. Evict S1b
11. Test Failover.


Hope to hear from you guys, Thanks




mark@mvps.org -> RE: 2 New Servers and New Storage Migration (16.Nov.2010 11:57:58 AM)

I would disagree with all of this.
Make a brand new two node cluster and do everything Exchange-y to those boxes.
Set up public folder replication and a couple of  test mailboxes.
Once PF replication is perfect set up all the new mailbox stores you need on the new storage.
Execute mailbox moves in the quiet hours.
After a couple of weeks of parallel running you will be ok to decommission the old cluster.
Physically moving stores is bad because it means complete store outages.
Physically moving stores in this case is bad because you have to connect the existing cluster to two separate storage systems which can lead to HBA compatibility issues.




taga_ipil -> RE: 2 New Servers and New Storage Migration (5.Dec.2010 1:35:01 PM)

Successfully Migrated to the 2 new servers, and new SAN Storage.

1. Add the two new nodes. this will make it four. N3 and N4 (N1 and N2 are old node)
2. Install Exchange Server Ent. Update MS Security Patches. Installed AV.
3. I make sure that N3 and N4 sees the cluster resource.
4. Test Failover to make sure N3 and N4 can handle Exchange before evicting the 2 old nodes N1 and N2.
5. Failover successful.
6. N3 owned the Exchange for 1 week.
7. N4 owned the Exchange for 1 week. just to check for errors.
8. Evict N1 and N2.

New SAN Arrived. (was delayed due to shipping)
Presentation of the new SAN Storage was Successfull.

Shutdown the 2 new nodes.

Power  On one node leaving one Node Off.

10: Go to Computer Management for Disk Assignment.
11. Format Disk.
12. Add new Specified Disk as Resource while Old SAN still holding the Exchange Data.
- Add all disk to System Attendant Dependencies.
- Power On N4 for Failover Test
13. Test Failovers by creating a New Group for the new Drives, so that not to affect the Exchange services when testing failovers for the new Disk Drives to both nodes.

CRITICAL PART:

14. Move Quorum Logs to New Storage Drive.
a. Test Failovers.
15. Move Transaction Logs to New Storage Drive.
a. Test Failovers.
16. Move .EDB and .STM to New Storage Drive.
a. Test Failovers.

17. Migration Successful.

Every successful Mailbox Store Transfer, I performed Backup to Tape.

So far So Good.. Running on Two New Nodes. Passive/Active
Running on New SAN Storage.

NOTE:
I Just summarize the steps I did.




marcovk -> RE: 2 New Servers and New Storage Migration (7.Dec.2010 7:52:50 AM)

I would have to agree with Mark here, we always do our migrations that way, cause its 'safer' and not error prown...
Messing with your production environment should always be avoided if possible.

But i guess its very balzy of you to get everything working the way you did.... Props for that...




taga_ipil -> RE: 2 New Servers and New Storage Migration (9.Dec.2010 6:42:15 PM)

@marcovk - Thanks
@mark - I read you comment before I started the migration and thanks for that, but I only have limited time. it was risky but I'm up for the challenge.
-------------------------------------------------------------------------------------
For Those who will take this path, just a warning you need to take note about.

These Two services will fail and you need to be familiar with ADSI and Registry editing to work this out.

First to fail after the transfer.
- MS Search Assistance

Resolution:
Run this command.
net stop mssearch
net start mssearch


Then recreate your Microsoft Exchange System Attendant, Add These Resource.
- All New Disk that will hold the data.
- EVS IP Address
- EVS Network Name

Referrence:
(I don't follow all instruction, I just extract what is needed)
http://support.microsoft.com/kb/830189


Second to Fail after old San Disk was put offline.
- Exchange Message Transfer Agent Instance

Resolution:
Just Copy the MTADATA located inside the default Exchange Installer Folder.
C:\Program Files\Exchsrvr\mtadata
to
San Storage who hold MTADATA.

Referrence: (I don't follow all instruction, I just extract what is needed)
http://support.microsoft.com/kb/162384


Note:
The reason I took this path because I don't have much time to wait for parallel running and our EVS is also part of our applications, renaming the EVS might cause issues when we scrape emails going to our company wide application, and we are not hosting our Exchange locally, this is done remotely since our datacenter is in LA, this has been done together with our Web Server Upgrade. Our goal is to replace our Old SAN Storage with new one, our LA team are there to help us onsite to present the disk and reconnect cables, they too has limited time to stay in LA.


The only time that I have is on weekend but it is also limited (Sat and Sun 12am-4am) Intermittent Outlook Disconnection, server need to be online during the weekdays which is our busy days. considering we are serving branches in different timezone.

If you have all the time, DO NOT ATTEMPT TO FOLLOW THIS!


So Far So Good on My Side... You just need to be prepared and be familiar with all functions of the Services in Exchange for easier Troubleshooting.


Merry Christmas! and a Prosperous New Year!





mark@mvps.org -> RE: 2 New Servers and New Storage Migration (9.Dec.2010 7:26:25 PM)

Whatever gets the job done!
Glad it all worked out right for you.




Page: [1]