Exchange hardware migration

[ Edited ]

We currently have an exchange 2003 server running Snapmanager for Exchange, as well as Open Systems Snapvault.

We are in the process of upgrading the hardware that the runs this server. Specifically we are going from an old HP LC2000 server to a newer HP/Compaq DL380 server. At this point in time we do not plan to upgrade to Exchange 2007, we simply want to upgrade the hardware to a newer more reliable server.

I also know that we are running an older release of Snapmanager, and OSSV than what is currently available, so after the hardware migration I plan to update both to the latest releases.

So here lies the issue.

I'm currently investigating what the easiest transition is going to be for moving the Exchange Server over to the "new" replacement hardware. I'm looking at the possibility of several different options at this point in time. I was wondering if you have ever done something like this, and if you had any recommendations of what might work best. Here are the current options that I'm looking at, and some questions that I have about the process...

1.) Use Open System Snapvault to "restore" the exchange server onto the new hardware...

a.) How does OSSV work with dissimilar hardware?, I'm going from an old Compaq LC2000 to a newer HP DL380 server..

2.) Do a new install of Windows and Exchange in a "Recovery" environment as documented in, then mount the existing message store and log file from the filer..

a. How do I handle this type of thing with SnapManager for Exchange, and Snapdrive? I've seen restoring, backingup,

and moving the Message store from local disk to the Filer, but I'm not really sure how I would go about pointing it to the existing LUN's on the Filer...

3.) Using some type of third party software such as Acronis True Image that specifically support "dissimilar hardware" to image the existing server and restore onto the new hardware.

4.) Some other method that you think would work better?

If you were doing this migration how would you go about it?

I really appreciate your time and advice.

Re: Exchange hardware migration

Hi Jonathan...

I can't answer the OSSV question...but I do believe it'll work with dissimilar hardware. I think that's the whole idea of Open tries to be as hardware agnostic as possible. I haven't had the chance to play with OSSV that much, so I can't say for certain that this is the case.

As for SME and restoring to the new server...a few questions to start though...

  1. Is Microsoft Clustering in the picture here?
  2. Will the new DL380 have the same name as the LC2000?
  3. Are the storage systems that contain the backups being upgraded as well?

Once I have the answers to those questions, I can better answer how to handy this with SME.



Re: Exchange hardware migration

OSSV leverages a software VSS provider to do a block level of the partition. This is great for situations where a LUN you want to protect is not on NetApp storage. In your case, it sounds like you're using OSSV to protect the boot LUN. I would reccomend going with a /disasterrecovery setup of Exchange, then mount the LUNs for the store and logs. The problem is that this is a block level copy of the boot LUN, and you can't be sure that image has the drivers loaded for the new hardware. I't's more complicated but far safer to go the /disasterrecovery build.

Re: Exchange hardware migration

FYI: For anyone else contemplating a similar migration. After consulting with a PS engineer at Netapp here is the basic outline of the proceedure I followed to successfully migrate the exchange server in my environment.

1.) Run an SME verified backup

2.) Disable the Snapmanager for Exchange backup jobs

3.) Shutdown all exchange related services on the "old Server"

4.) Disconnect the LUNS from the "old server' after verifying the exact path to the LUNS.

5.) Shutdown the old server.

6.) Follow the KB article I referenced earlier.

With the following modifications:

a.) Note that renaming the server and joining it to the domain is a two step process requiring two separate reboots, don't try to rename and join to the domain all in one step it *will* fail.

b.) Make sure iSCSI sessions or FC zoning is configured. All software versions (MS and NetApp) should be same between servers. Also include installation of Windows Host Utilities, MPIO, MS hotfixes, etc.

c.) Install SnapDrive and Reconnect same LUNs on new server (make sure you've reset the computer account and given new server the same name prior to this step)

d.) Run Exchange /disasterrecovery setup

e.) Install any Exchange service pack with /disasterrecovery setup

f.) Install any Exchange Hotfixes.

7.) Install SME and Run SME Configuration Wizard

8.) Databases should be mounted

9.) Since running the Config Wizard will mount the databases, this next step is optional - however, I add it because if there were any uncommitted t-logs, they will be played into the database during this restore. Open and run SME restore for each storage group. Perform from most recent snapshot, do up-to-minute recovery, do not run exhaustive restore, let SME mount databases at conclusion.

10.) Verify Exchange health and verify client connectivity

11.) Run SME backup

12.) Schedule new SME backups with SnapMirror update. Validate SnapMirror destination is updated.

I ran through this process afterhours one day last week, and brought the new server online with not a single support call involving exchange issues the next day.

Re: Exchange hardware migration

Thanks for the steps. Couldn't you have just installed a new Exchange server, procured the new volumes and luns (with Snapdrive), ran the snapmanager config wizard to map the empty Exchange db's, logs to the new Netapp luns, joined this Exchange server to the existing Exchange org and use the native Exchange move mailbox tool to move mailboxes from the old server to the new server.

Once the moves are complete you could then decommision the old Exchange server.


Re: Exchange hardware migration

Yes, you can do mailbox moves - this is what we recommend for Exchange 2003 to 2007 migrations (there's really no other choice).

However, by doing a mailbox move, you lose the advantage of the Single Instance Storage - you may see your mail databases grow because of all the duplicated mail.

The Exchange 2003 /disasterrecovery setup option is a fairly common method of doing Exchange 2003 disaster recovery - or moving an entire server to a new box.

You're keeping the same information store structure, and the /dr option allows the new server to take over the Active Directory server properties for Exchange.

Re: Exchange hardware migration

You do lose the SIS on the mailbox move, but you recapture it by turning on ASIS on the volume(s). Actually, you get better dedupe this way then what you get with Exchange SIR.

I do have a question about SnapManager Exchange (SME). I was recently at a customer site. They have an existing Exchange 2003 solution sitting on direct attached disk (DAS). They want to move to Exchange 2007. So, they went ahead and installed Exchange 2007 on DAS, joined it to the exisiting Exchange org and used Exchange mailbox move to move a few mailboxes to Exchange 2007. So, they have Exchnage 2003 and 2007 on DAS.

Now, they want to procure luns on the Netapp for Exchange 2007. We went ahead and setup the luns for the Exchange 2007 db's, logs and snapinfo (via snapdrive 6.0.1 and iSCSI). At this point the Exchange 2007 box sees these new luns.

What I wanted to do now was to install SME on the Exchange 2007 box in order to migrate the Exchange 2007 database, logs from DAS to the Netapp newly provisioned luns. When I fire up SME configuration wizard and specifiy the Exchange 2007 server I'm presented with ALL of the Exchange storage groups that Exchange 2007 sees. This includes the storage groups from Exchange 2003.

Problem is that I don't want to migrate the Exchange 2003 databases/logs over to the Netapp at this point. Mainly because of maintenence window issues. The plan was to migrate the Exchange 2007 DAS databases/logs (which consisted of about 5 mailboxes) and then use Exchange mailbox move to schedule mailbox moves to Exchange 2007.

Why does the configuration wizard list all Exchange storage groups and not just the Exchange 2007 storage group? It won't let me just map the Exchange 2007 databases and move on to the next screen. It expects everything to get mapped before moving on.

How can I get around this issue? It would seem to me that enterprises with many Exchange servers might not want or need them all to be migrated to their Netapps at the same time. How would these organizations handle the above situation if they had 10 Exchange 2003 servers and a single Exchange 2007 server that they wanted to migrate to the Netapp?


Re: Exchange hardware migration

I'm a little confused - is Exchange 2003 and Exchange 2007 both running on the same physical server?

I didn't think that was possible..

The SME Configuration wizard operates at the Exchange server name (or virtual server name), and so it expects that ALL of the storage groups on that server must be migrated to NetApp storage... there are a few exceptions with things like Exchange 2007 CCR clustering..

Can you provide a screen shot of the SME Config Wizard where it's showing the storage groups?

Expanded out, if it can.

Re: Exchange hardware migration

Hehe...I didn't think it was possible either. I've done many Exchange SnapManager installs before and never run into this before - although it was my first Exchange 2007 endeavour.

Two separate Exchnange servers on separate hardware. The Exchange 2007 server is part of the Exchange 2003 organization. If you open up Exchange system Manager you see one Exchange org with 2 servers. Exchange 2007's system manager is called systems management console. When I open that up I see all the storage groups between both servers listed.

Yup, the first thing that SME config wizard asks for is the server name. I made sure to select the Exchange 2007 server.

I'll ask the client to supply me with a screenshot as I don't have remote access.

Re: Exchange hardware migration

Move mailbox checks the unique messageid of every message and preserves SIS if possible.