- Breaking Mirrors -

Windows Software Mirroring - workaround for getting rid of it

• Why no longer needed

If you are a system administrator then every once in a while you will have to handle some badly or improper configured machines. Some of them are the result of inexperienced or uninterested people but sometimes it's the passing of time and advancing of technology that renders previously good solid solutions to a state of being impractical or worthless.

Back in the days when hardware was high priced there were many people or even small businesses that didn't afford to buy fully configured servers. Disk Controllers with RAID capability were among the expensive hardware. So Microsoft took advantage of this fact and came with a basic software based solution for data redundancy: disk mirroring.

I suppose that by reaching this page you already know the background so I will not insist writing about what mirroring does, pros and cons of the software approach or how it can be implemented.

The actual hardware advances of today give us plenty of RAID controllers that fit or are even embedded in workstation motherboards and all that come at modest prices. Moreover, virtualization and cloud technologies are providing us with all the scalability and redundancy we need, to obtain previously unexpected up-times.
So, having a machine that uses Windows software based mirroring will prove today to be more of a drag and it should be replaced with a more solid and up-to-date solution.

• Particular example

My example will follow a real life case that I had to handle about a year ago and I had no time until now to share it. I will of course skip or blur some sensitive info that I am not supposed to disclose but I will try to provide all the technical info needed to understand the procedure and successfully apply it if needed. Of course it will not have a lot of pictures, just a few that I found in my archive, but I hope it will help you as much.

First we need to define the general conditions that brought us the necessity to apply such measure.

So, I happened to stumble upon an old machine running Windows 2008 R2. This machine used to be a real, physical machine, a desktop based one that had two disks that were mirrored using the Windows software mirroring solution, in spite of the fact that those disks were of different capacities (150GB and 500GB).
Then, sometime in the past somebody thought it better be converted to virtual using VMWARE technology. And of course the P2V process was conducted using the magical, never failing "next-next-finish" style, replicating the exact improper disk configuration and having the following result:

Of course the virtual machine was migrated on a real server and the virtual disks are stored on a Data Storage with a huge number of disks, high level RAID array, hot spares, so the software redundancy became so called excessive redundancy that beside unnecessary consuming storage space is also slowing down the machine by using resources to emulate the mirroring process.
The target was to get rid of the bigger disk (500GB) , since the lesser one (150GB) was better calibrated and the used/available space was never an issue.

• Hands-on, first trial

Since I never used software RAID on Windows platforms before I thought I should first go to our friend that lately holds all the answers, meaning some web search.

There were two approaches given for a software mirrored array, to break or to remove. The difference between them is: breaking holds the info on both sides while the remove option keeps only one volume and releases the space on the secondary disk, making it "unallocated free space". So I decided to stick with the safer one, breaking the mirror. The most clear and quick explanation came from Symantec so I have to quote here.

Most inspiring before making any decisions was taking a snapshot of the machine. That snapshot was reverted a lot of times and I advise you to do the same even if this document will spare you of all the setbacks that turned me around.

If you run a quick search about "breaking" a mirror the solution will be repeatedly obvious, within a few clicks' reach but not satisfactory in this particular case. It was something like going to Disk Management, right click on a mirrored volume and choose "break mirrored volume",

 followed by a warning:

But, no matter which of the corresponding volumes I was selecting, I was stuck with the wrong bigger disk remaining the boot one even if in theory the ideea of a mirror is to be able to use any of its members in case the other fails.

The next trial consisted on "physically" removing the 500GB disk from the machine, but that was part of the snapshot and I was not ready to give it up. Next step was to switch places between disks from BIOS, but Windows remembered its preferred disk and booted from it and it was all the same.

There were a lot of trials and fails, I don't remember all of them since a lot of time passed.

After a while I decided to use the msconfig tool to switch from the main boot device to the alternate one and set it as default boot device,

This way we make sure the 500GB disk will no longer be the primary disk from which the operating system will boot. Of course this operation needs a restart and after that we have the alternate system in charge, booting from the secondary disk. After this step any "mirrror breaking" using the GUI resulted in a new error:

• The real catch

Was when I started browsing again for answers. Nothing could be done using the GUI so DISKPART seemed to be the answer. It is a long time since I used command line "fdisk" for dealing with disks and partitions. Since nobody seemed to point in the right direction I started to RTFM, keeping the idea that alternate boot from the disk I wanted to preserve was the line to follow.

So the next step is opening a command line using administrative rights (you should make sure you have that on the currently logged on user or use ) and then use DISKPART:

Here we can select and then see and operate on properties of disks, volumes and partitions.

What we have to do is list the disks, in case we don't know them yet:

list disk

And retrieve any useful info about them:

As we can see, the named DISK0 has 500GB capacity, holds volumes 0,1,2 and has no longer the boot disk attribute.
We can do the same for  DISK1 and get the following info:

As we can see, the named DISK1 has 150GB capacity, holds volumes 0,1,2 as well (mirrored) and also has the boot disk token.

First we tend to get remove of the boot mirror (volume 0), the operation that previously di not work from GUI so we go for it:

And the result can be seen from the GUI as following:

So it is, at least apparently a success. we can do the same with the data volume. But what about the hidden, letterless, puny 100MB partition that doesn't want to be rendered useless ?

I have a limited screenshots reserve from back then so I have to remember and stick to the given scenario. So after this first success we have to gather data:

As you can see the former volumes 0,1,2 are now 1,2,4, so disk0/volume0 was split from the mirror and became disk0/volume4, no longer linked to its twin volume located on disk1. It also holds the data from disk1/volume0 but it is no longer in sync and can be treated as a separate disk from the original.

The same operation will work on the "Data" volume, breaking it the same as we did before.

And here it is:

So the former volume1 on disk0 is now volume5.

But switching the boot from the Disk0 to Disk1 doesn't switch the "System" attribute from the hidden partition (as you can see above). So if we try to apply the same procedure it fails, giving us the same GUI error, "The specified plex is a the current system or boot plex.", this time in console mode, with no further details. No matter if you move the boot partition, the boot info stays in the same place.

So, it is about "boot" or "system"... but the boot part we've taken care of, now we got to bring the system down and put it into the right place which in our case is the secondary disk. If you simply remove the 500GB disk, even if you managed to move the boot in the right place, the system will not be present so it will not boot, no screenshot available for that.

After loads of searching, trying and reverting the snapshot I had to resume to a more careful studying of the DISKPART command. This command designed to work with: disks, volumes, partitions. Since all the operations until now were done at disk and volume level I was suspecting our next step should be about partitions.
If we retrieve the info about the second disk, the one we want to keep, we notice the second volume is still the one being of the type "Mirror" so this volume is still based on both drives but we will try to split them.

Remembering the error message, we have to remove the "System" attribute from the...  plex. So guessing along and passing the disk and volume level, I had to look closer to the partitions. First we have to render them inactive. You can see below that the mirrored single system partition is marked as active:, after breaking

What we have to do is deactivate it then break the mirror. In order to keep the system bootable after splitting the mirror we have to be sure we have at least one active, system partition. And, to be sure of it we must do it before deactivating the system partition. This can be done by using the bcdboot command (full syntax and examples if you follow the link).

bcdboot c:\windows /s X:

To deactivate the partition we run the following DISKPART commands:

- work in progress -

sample text
    sample text 2