• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Physical to Virtual to Physical

USMCGrunt

2[H]4U
Joined
Mar 19, 2010
Messages
3,103
Hey guys...not sure where to put this as it spans a couple different subjects but I guess this is as good a place as any.

I have a physical Exchange server that is going to be getting a new RAID controller and hard drives. Right now, its setup as a RAID 1 with two drives using the motherboard chipset. I am installing a dedicated RAID controller and going with RAID 10 across four drives.

I'd like to minimize downtime as much as possible during the installation so here's what I was thinking. Using Backup Exec 2014 I have the option of creating a backup to go from physical to virtual. So I was going to run that backup type and immediately restore it to a pre-configured VM using Hyper-V 2012. Once the restore is complete onto the VM, I would then shutdown the physical server, upgrade the hardware and build the array. Once the physical hardware is ready, I'd then create another backup of the VM Exchange and then restore it to the new physical hardware.

One, is that going to introduce any difficulties and two, are there simpler ways to do this that I am overlooking?
 
How about just hot plugging the card?

The other option is just to stay late one night and take the server down and put in the card. The next day get the drives up and bring up new databases and start migrating over the mailboxes.
 
Yeh, id rather try putting the card in and installing the drivers late one night, then moving datastore files the next day after creating the R10 array
 
A couple problems there....

1st, This is just a bandaid fix for a terrible throughput issue and reduction of drive failure risks. The original drives are tiny 150GB drives with one operating at SATA I speeds and the other reporting in at SATA II speeds. Additionally, there is only a single logical drive that stores everything...the OS, Exchange...everything. On top of that, the system digs into the page file for normal operations (8GB of RAM on 120 mailboxes). It's been this way since, I'm assuming, day one for the last 4-5 years...however long the server has been functional and I'm betting those hard drives are near their breaking point. So I wouldn't be moving just the database...I'd be moving everything.

2nd, I don't know jack and or shit about Exchange (yet I'm in charge of the shit :rolleyes: )...well I know how to add remove accounts, create distro groups, etc simple ass stuff... so I'm not sure how to even go about migrating anything in Exchange nor do I even like to touch it, lol. A new server will be getting purchased and installed in the new fiscal year with an Exchange specialist providing his services for the migration.
 
I would install the card and load the drivers. Shut it down mount the new drives in the server, power it on and create the array. Then you could take something like Macrium Reflect Server and clone the current drives to the new array. Once completed, shut the server down, disconnect the old drives, power it back on and see what you get. I'm not sure of the OS level, so that may be a factor in considering this option.
 
I would install the card and load the drivers. Shut it down mount the new drives in the server, power it on and create the array. Then you could take something like Macrium Reflect Server and clone the current drives to the new array. Once completed, shut the server down, disconnect the old drives, power it back on and see what you get. I'm not sure of the OS level, so that may be a factor in considering this option.

What do you mean "...not sure of the OS level..."?

What about using Acronis True Image boot disk....that could move everything right? I didn't think OS/applications really mattered with cloning software...why does Macrium have versions separated for different OSes/applications (Exchange)?
 
I was stating something about the OS level because in my experience Server 2003 can be finicky when being imaged.
 
I see, well this is Server 2008...hopefully it's in better shape. I think I'll try your suggestion Peanuthead, thanks.
 
Should be less finicky. You are welcome. if all runs well you should move the Pagefile.sys over to the old SATA drives that you'll be taking out. If you REALLY wanted to have some fun (in a sick, wanting punishment way) you could set that drives in a RAID0 and put the pagefile.sys on them. I personally wouldn't though. Hopefully this drive swap will buy you some time. You would think they would let you slap some RAM in it just to help in case the new server is on backorder, has issues, etc.and you have delays.
 
You're making this way too hard on yourself. Shut the server down one night, pop in the card, pop in the drives configure the array and get back into windows (add some more ram while you're at it). Open Disk manager, add the new drive into windows.

Create a new db with log files on the new drive: http://nightfox14.blogspot.com/2010/03/exchange-server-2010-create-new-mailbox.html

Migrate the mailboxes over to the new db.

RAID 1 should be fine for running the OS and Exchange, you're running into issues because of the Exchange DB and Logs, once you move them to their own disk, it'll be fine.
 
That is even better, ND40oz. We like things hard! Isn't this the [H]ardforum? :)
 
You're making this way too hard on yourself. Shut the server down one night, pop in the card, pop in the drives configure the array and get back into windows (add some more ram while you're at it). Open Disk manager, add the new drive into windows.

Create a new db with log files on the new drive: http://nightfox14.blogspot.com/2010/03/exchange-server-2010-create-new-mailbox.html

Migrate the mailboxes over to the new db.

RAID 1 should be fine for running the OS and Exchange, you're running into issues because of the Exchange DB and Logs, once you move them to their own disk, it'll be fine.

My only concern with this is that the existing hard drives are most likely on their last leg. What has spurred action is the fact that users are reporting, infrequently, delayed message delivery and....phantom mail delivery....they send an email through Outlook, it says it was sent (moved from outbox to sent folder) but the recipient, within the organization, doesn't receive the email until up to a week later...like the message just got lost in the wires, lol. I ran the diagnostic test that comes with Exchange 07 and it found a HDD and a memory bottleneck. Unfortunately, the server doesn't support more than 8GB of RAM (age of server indicator) so I can't really address the memory shortfall. With the hard drive capacities being SATA II interfaces at 150GB in capacity, it tells me that they are some old ass drives that are probably bumping up against their MTBF. These are also not enterprise level hard drives, they're off the shelf consumer drives. They had the server custom built by a local company that half assed the shit out of it.

So, if I move just the database and logs to the new volume, and the existing volume shits the bed, I'm then stuck with purchasing additional hard drives and a more complex restore process...all for a band aid solution.
 
If you're worried about the hard drives, replace them one at a time. They're in RAID 1, yank one, rebuild, yank the other, rebuild and you have two new hard drives running the OS and Exchange.

All of that other stuff is most likely related to the DB and logs, which moving to new hard drives will fix. The 8GB of ram is the minimum for running Exchange 2010 with CAS/HUB/Mailbox roles, but not much you can do about that unless you're ready to move to all new hardware now.
 
What about:

1) Throw the new RAID controller in the system, configure your RAID10
2) Use Windows Disk Management to create an OS based R1, where one "disk" is your existing R1 and the second is your new R10 array (if the motherboard is doing this pre-OS). If it's doing it in the OS, add the new R10 as your third mirror.
3) Wait for all of the data to seed
4) Pull the old two drives and break the mirror, leaving everything on your new R10

Not sure if I'm overlooking any critical details.

I'd either do that or ND40oz's plan. Leaving the system on two old drives R1'd for a few more months doesn't sound like that huge of a risk, and putting the mailbox DB and/or logs (yes, you ideally don't want them on the same medium but this setup isn't ideal) should help alleviate your IO throughput issues.

Just be aware that if you migrate the mailboxes to a new DB, you're going to generate transaction logs at a 1:1 ratio with the data being migrated. E.g. if you migrate 50GB of mailboxes, you're going to need space to store an additional 50GB of transaction logs. You can migrate mailboxes in batches and use your backup software to purge the logs if you don't have enough space, just make sure you don't fill the drive.
 
What about:

1) Throw the new RAID controller in the system, configure your RAID10
2) Use Windows Disk Management to create an OS based R1, where one "disk" is your existing R1 and the second is your new R10 array (if the motherboard is doing this pre-OS). If it's doing it in the OS, add the new R10 as your third mirror.
3) Wait for all of the data to seed
4) Pull the old two drives and break the mirror, leaving everything on your new R10

Not sure if I'm overlooking any critical details.

I like this idea, question though. If it's an OS based RAID, when I physically disconnect the old array, what will happen? Will the OS boot normally and inform me of a degraded array? When I go to Disk Management and break the array in software, will it attempt to run off the old array that was the original 'master', so to speak? I have VMs setup that I could go into and test this method to see how it behaves I guess.
 
Is it UEFI or standard bios?
Do not attempt the raid1 migration with UEFI and 2008.
 
As this is a production system with some level of uncertainty with regard to its stability, my advice is to absolutely minimize stress to the system. This advice would naturally be markedly different were you building a new pre-production system, as that you would probably want to stress-test. Also, full credit to ND40oz, as his have been the best suggestions I've thus far read. My apologies if any of this reads as overly simplistic/obvious; I'm not meaning to talk down to you (or anyone else), just a habit I've developed after writing instructions for too many O1s.

My suggested process to minimize risk of data loss (which is always a risk when breaking RAID sets):

0) Before you do anything, make sure that you have a good backup. Also, if you can, try to set expectations for anyone relying on this system that there may be lengthy downtime if any hardware fails during the upgrade.

1) Power the system down, add the RAM, RAID card, and new HDDs.
2) Boot into the RAID card BIOS, create your new RAID10.
* Note: the RAID controller should continue any creation/scrubbing even if you reboot
3) Reboot back into Win2k8.
4) If the RAID controller does a scrub of the array, wait for that to complete before doing anything else with the new RAID set.
5) Open Disk Manager, initialize the new disk (the one the RAID controller is presenting to the OS) as a basic disk, then partition that basic disk out as needed.
* Absolutely do not run software RAID on top of hardware RAID or fake/driver RAID
6) Create a new database with log files on a partition you just created.
7) Migrate your mailboxes to the new database.
* After this point, your system should be much more stable, with the C: drive RAID1 not as heavily tasked
8) Power the system down.
9) If you have time, boot to a HDD diagnostic CD and test both drives. If either shows SMART errors or fails a quick test, make sure that is the drive which you remove first. If you don't have time or they both pass those tests, remove the older drive first.
10) Remove whichever drive you decided was appropriate to remove first, use a sticky note to label it as "old_raid1_a" (or whatever, but labels can be a lifesaver when juggling RAID drives), and put it somewhere safe.
11) Power the system back on.
* The RAID should now be reporting as degraded. NOTE: Do not plug both old drives back in at the same time after this point.
12) Ensure that everything in the OS appears to be operating properly. Check to make sure all services started, etc.
* If you encounter any problems or any evidence of corruption, power back down, remove the current drive, label it "old_raid1_b", and plug old_raid1_a back into the system. Boot the system and check the OS again. If both drives are corrupt, I would suggest removing them, installing the new RAID1 drives, reinstalling the OS, reinstalling Exchange, restoring any needed data from the backups, and pointing the new Exchange install to the mailbox stores on the RAID10.
13) Power the system down. Plug one of your new hard drives into wherever the old drive was.
14) Boot into the RAID firmware, and start a rebuild of the array if one has not begun automatically.
* If you have the time to let the rebuild complete in the firmware, do so. Doing so should help rebuild faster since the OS is not also trying to use the drives, and reduce the risk of corruption during the rebuild process for the same reason.
15) Reboot back into the OS. Once the rebuild is complete, ensure that everything in the OS appears to be operating properly. Check to make sure all services started, etc.
16) Power the system down.
17) Remove the remaining old RAID1 drive.
18) Power the system back on.
* The RAID should now be reporting as degraded. NOTE: Do not plug either of the old drives back in after this point.
19) Ensure that everything in the OS appears to be operating properly. Check to make sure all services started, etc. This gets tedious, believe me, I know. But it allows you to notice corruption as early as possible, which can easily spare you from finding out that you've wasted hours of effort and allow you to take appropriate action as soon as possible.
20) Power the system down. Plug the remaining new hard drive into wherever the old drive was.
21) Boot into the RAID firmware, and start a rebuild of the array if one has not begun automatically.
* Again, if you have the time to let the rebuild complete in the firmware, do so.
22) Reboot back into the OS. Once the rebuild is complete, ensure that everything in the OS appears to be operating properly. Check to make sure all services started, etc.
23) At this point you should now be running on all new hard drives, and your Exchange database should be living on a RAID10 completely seperate from the OS and applications.
24) Crack open a bottle of something strong and old. Holy shit, you just earned it.
 
As this is a production system with some level of uncertainty with regard to its stability, my advice is to absolutely minimize stress to the system. This advice would naturally be markedly different were you building a new pre-production system, as that you would probably want to stress-test. Also, full credit to ND40oz, as his have been the best suggestions I've thus far read. My apologies if any of this reads as overly simplistic/obvious; I'm not meaning to talk down to you (or anyone else), just a habit I've developed after writing instructions for too many O1s.

My suggested process to minimize risk of data loss (which is always a risk when breaking RAID sets):

0) Before you do anything, make sure that you have a good backup. Also, if you can, try to set expectations for anyone relying on this system that there may be lengthy downtime if any hardware fails during the upgrade.

1) Power the system down, add the RAM, RAID card, and new HDDs.
2) Boot into the RAID card BIOS, create your new RAID10.
* Note: the RAID controller should continue any creation/scrubbing even if you reboot
3) Reboot back into Win2k8.
4) If the RAID controller does a scrub of the array, wait for that to complete before doing anything else with the new RAID set.
5) Open Disk Manager, initialize the new disk (the one the RAID controller is presenting to the OS) as a basic disk, then partition that basic disk out as needed.
* Absolutely do not run software RAID on top of hardware RAID or fake/driver RAID
6) Create a new database with log files on a partition you just created.
7) Migrate your mailboxes to the new database.
* After this point, your system should be much more stable, with the C: drive RAID1 not as heavily tasked
8) Power the system down.
9) If you have time, boot to a HDD diagnostic CD and test both drives. If either shows SMART errors or fails a quick test, make sure that is the drive which you remove first. If you don't have time or they both pass those tests, remove the older drive first.
10) Remove whichever drive you decided was appropriate to remove first, use a sticky note to label it as "old_raid1_a" (or whatever, but labels can be a lifesaver when juggling RAID drives), and put it somewhere safe.
11) Power the system back on.
* The RAID should now be reporting as degraded. NOTE: Do not plug both old drives back in at the same time after this point.
12) Ensure that everything in the OS appears to be operating properly. Check to make sure all services started, etc.
* If you encounter any problems or any evidence of corruption, power back down, remove the current drive, label it "old_raid1_b", and plug old_raid1_a back into the system. Boot the system and check the OS again. If both drives are corrupt, I would suggest removing them, installing the new RAID1 drives, reinstalling the OS, reinstalling Exchange, restoring any needed data from the backups, and pointing the new Exchange install to the mailbox stores on the RAID10.
13) Power the system down. Plug one of your new hard drives into wherever the old drive was.
14) Boot into the RAID firmware, and start a rebuild of the array if one has not begun automatically.
* If you have the time to let the rebuild complete in the firmware, do so. Doing so should help rebuild faster since the OS is not also trying to use the drives, and reduce the risk of corruption during the rebuild process for the same reason.
15) Reboot back into the OS. Once the rebuild is complete, ensure that everything in the OS appears to be operating properly. Check to make sure all services started, etc.
16) Power the system down.
17) Remove the remaining old RAID1 drive.
18) Power the system back on.
* The RAID should now be reporting as degraded. NOTE: Do not plug either of the old drives back in after this point.
19) Ensure that everything in the OS appears to be operating properly. Check to make sure all services started, etc. This gets tedious, believe me, I know. But it allows you to notice corruption as early as possible, which can easily spare you from finding out that you've wasted hours of effort and allow you to take appropriate action as soon as possible.
20) Power the system down. Plug the remaining new hard drive into wherever the old drive was.
21) Boot into the RAID firmware, and start a rebuild of the array if one has not begun automatically.
* Again, if you have the time to let the rebuild complete in the firmware, do so.
22) Reboot back into the OS. Once the rebuild is complete, ensure that everything in the OS appears to be operating properly. Check to make sure all services started, etc.
23) At this point you should now be running on all new hard drives, and your Exchange database should be living on a RAID10 completely seperate from the OS and applications.
24) Crack open a bottle of something strong and old. Holy shit, you just earned it.

This is what we in the Marine Corps. would call Barney Style, lol. Actually, I am a bit confused in that it sounds like I should have 6-8 drives. Four to create the RAID 10 that will be created initially and have the database migrated to, and then an additional 2-4 to replace the existing worn out drives, is that correct? I only have four drives to work with...granted your method would definitely work in replacing the RAID 1 array by doing a single drive at a time and needing to rebuild the array twice but, if possible, I'd like to drop everything onto a single RAID 10 and be done with it until the server gets replaced.
 
Install New raid card
Add new drives
Add more Ram
OBR10 (one big raid 10)
install ESXI
import created VM
Use ESXI Free
User Veeam Free to backup VM for recovery if ever needed.
WIN!

Exchange 2013 is not as resource intensive as past versions, it can run fine with 120 mailboxes on SATA drives and 4 of them in raid 10 should be fine.....i run 180 mailboxes on a HP 2u=U with 8 x 1TB WD Blacks in a raid 10 with several other VM's with no performance issues, but i also have 20G of ram for my exchange alone.
 
Install New raid card
Add new drives
Add more Ram
OBR10 (one big raid 10)
install ESXI
import created VM
Use ESXI Free
User Veeam Free to backup VM for recovery if ever needed.
WIN!

Exchange 2013 is not as resource intensive as past versions, it can run fine with 120 mailboxes on SATA drives and 4 of them in raid 10 should be fine.....i run 180 mailboxes on a HP 2u=U with 8 x 1TB WD Blacks in a raid 10 with several other VM's with no performance issues, but i also have 20G of ram for my exchange alone.

Unable to add more RAM, the server motherboard doesn't support more than 8GB. We have Backup Exec 2014 that could backup the VM, non-profits pay $115 for a copy that has everything enabled :D...software discounts available to NPOs are ridiculous...or is it the markup for everyone else that's ridiculous?
 
One has to wonder, if you have temporary resources to P2V your Exchange, why not shuffle the virtualized environment and keep Exchange virtualized permanently?
 
One has to wonder, if you have temporary resources to P2V your Exchange, why not shuffle the virtualized environment and keep Exchange virtualized permanently?

The resources available are on one of the domain controllers that handles most of primary network functions....dhcp, print server, DC duties, file server, etc...The resources in terms of RAM and processing power are there but the storage speeds would prove to be a bottleneck still. It's only got a simple RAID 1 array for the O.S. and another for the network shares. I could create a VM and throw Exchange on there at the sacrifice of performance to both Exchange and File Server performance. It could be an acceptable hit for a short term solution but long term I think the users would notice a slowdown in file access responses or DFS replication.
 
This is what we in the Marine Corps. would call Barney Style, lol. Actually, I am a bit confused in that it sounds like I should have 6-8 drives. Four to create the RAID 10 that will be created initially and have the database migrated to, and then an additional 2-4 to replace the existing worn out drives, is that correct? I only have four drives to work with...granted your method would definitely work in replacing the RAID 1 array by doing a single drive at a time and needing to rebuild the array twice but, if possible, I'd like to drop everything onto a single RAID 10 and be done with it until the server gets replaced.

Yes, the process I described would require 6 drives at a minimum. And yeah, pretty much any tech instructions I write, I tend to write Barney style, mostly as a result of what I could most politely call "excessive creativity" when I didn't. If you only have 4 to work with, I'd still suggest doing pretty much the same thing, except adding in just two of the new drives as a RAID1 for the new Exchange DB rather than a RAID10. Or, if possible, just buy a couple cheap replacement drives for the RAID1. Could probably even go with SSD replacements for those two drives for under $150, which might put a bit more pep in your system.

Going physical to virtual to back to physical really is begging for trouble and instability down the line. I'd suggest avoiding that path if possible.

Going with two RAID1s shouldn't be limiting for you, since it doesn't really sound like drive space is a limiting factor for you. But if at any point you find yourself filling up that drive, you can always add more to the RAID set and expand your partition (don't do dynamic disks though).
 
Yes, the process I described would require 6 drives at a minimum. And yeah, pretty much any tech instructions I write, I tend to write Barney style, mostly as a result of what I could most politely call "excessive creativity" when I didn't. If you only have 4 to work with, I'd still suggest doing pretty much the same thing, except adding in just two of the new drives as a RAID1 for the new Exchange DB rather than a RAID10. Or, if possible, just buy a couple cheap replacement drives for the RAID1. Could probably even go with SSD replacements for those two drives for under $150, which might put a bit more pep in your system.

Going physical to virtual to back to physical really is begging for trouble and instability down the line. I'd suggest avoiding that path if possible.

Going with two RAID1s shouldn't be limiting for you, since it doesn't really sound like drive space is a limiting factor for you. But if at any point you find yourself filling up that drive, you can always add more to the RAID set and expand your partition (don't do dynamic disks though).

Hey, I don't mind having my hand held through situations that I'm unfamiliar with, especially when its a production environment. Thanks for the help gentlemen.
 
Hey, I don't mind having my hand held through situations that I'm unfamiliar with, especially when its a production environment. Thanks for the help gentlemen.

No worries. Best of luck to you, and please report back with your results, I curious to know what you elect to do and how it turns out. :)
 
Back
Top