Netadmin: Using diskpart to extend a volume onto a new disk

To follow-up on a comment in a previous post, Teo Heras makes the point that you can use basic or dynamic disks to dynamically extend the file system of the of an existing volume onto a different disk. As he points out, Microsoft uses this in support of their "just-in-time" storage provisioning , which basically allows them to provision capacity on-demand and without downtime.

Which is a good point - just throw a few drives in, provision them in a supportable hardware RAID configuration (using your Dell, HP, etc. management tools), then you can use diskpart to extend the filesystem of one of your volumes onto the new capacity of the additional disk. And since the RAID configuration is invisible to the OS, drives can still be failed/replaced without the OS complaining, or your extended file system caring.

You can find a good KB article here if you're interested. Otherwise, the short of it is as follows...

1) Add drives to server.
2) Configure drives in a supportable hardware RAID configuration.
3) Open a command prompt, and launch "diskpart".
4) Type "list volume", and find the volume you want to extend.
5) Type "select volume 1" where 1=the volume you want to extend (let's call it "e").
6) Type "list disk" (let's assume disk 2 is the new disk that you just added).
7) Type "extend disk=2". This will extend the filesystem of volume 1 ("e") onto the additional capacity of the new drive.

That's all there is to it. You can extend the capacity of the drive the OS resides on as well if needed. Just keep in mind that if you're using a hardware RAID, you're not looking to use dynamic disks for the software RAID functionality, rather you're using diskpart to extend the filesystem and provision storage.

Netadmin: Basic vs. Dynamic disks

I fielded a question about dynamic disks today - "If I'm using a hardware RAID configuration, is there any advantage to converting from a basic to dynamic disk configuration?".

The short answer is No.

Dynamic disks essentially provide for a software RAID solution. They change the partitioning table, and were introduced in the Windows 2000 timeframe. If you have a hardware RAID solution, there's no reason to convert to dynamic disks. Step back and for a second and think about it for yourself... if the hardware RAID is transparent to the OS (and it is); adding a software RAID on top of the hardware RAID would serve what purpose? Added complexity, increased risk of corruption, and decreased performance.

If you have a hardware RAID controller use it. Pass on the dynamic disks.

More information in a KB article can be found here.

Hardware: Adding drives to a PE2650 with hot-swappable bays takes how many reboots?

The answer is 6.

Okay, I’ll be fair… 4.

So we have a new client that initially involved us because one of their Dell PowerEdge 2650’s with 2003 was “running slowly”…, after an initial review we could better phrase that as… “out of drive space”… but otherwise at first glance it was none too interesting.

So after verifying that we have good backups of the box, and freeing up enough space to start working we checked the server’s application stack to make sure it was supportable, applied SP1 and rebooted. Then with the intention of configuring two new drives in a RAID1 configuration, we installed the Dell Open Manage Administrator (OMSA) 5.1.0 with the Storage Manager component, and rebooted. After logging into OMSA interface, we checked on the Storage component, clicked the Information/Configuration tab, and got… nothing. Under Global Tasks, it said “No Task Available”, and no storage controllers were visible. Which isn’t’ good. So we talked to Dell Open Manage Support, and they knew exactly what it was… the server wasn’t using the Dell driver for the PERC3/Di controller… fair enough. After talking to support, we came up with a path-forward …

1) Download latest driver then reboot
2) Update the firmware then reboot
3) Apply a patch to “make the warning icon in device manager go-away” (uh-huh…), reboot…

So that’s pretty reasonable for the most part, right?

Well, because the Dell PE2650 isn’t ours, and isn’t a box that we’ve standardized on, we talked to tech support a bit more about the process of adding the new drives. Well, the process really wasn’t what I expected. It turns out that even after doing the driver, firmware, and patch updates, we still won’t be able to configure the drives using the web-based OMSA. Which sounds a bit out of sorts… isn’t the whole point in having OMSA and hot-swappable bays to minimize reboots, keep people out of the RAID controller BIOS, and meet SLAs? Now maybe I’m not adding drives to a PE2650 everyday… but that just doesn’t sound right to me.

Well, if we take the Dell recommended approach we’re going to have to do the following:

1) Shutdown the server
2) Remove the existing drives, and add the new drives
3) Use the RAID controller BIOS to configure the new drives
4) Turn off the server. Add the original drives back in.
5) Enter the RAID controller BIOS, and accept the notification that “Changes have been made”
6) Reboot. The server should then boot normally.

So all things considered that’s more risk than we really anticipated, not to mention time and reboots. Granted, we probably wouldn’t had been in this situation if whomever built the box had used the Dell drivers, and installed OMSA during the initial install, but we don’t want to point fingers. Further, we could have noticed the driver issue before going to Dell support… ultimately, we want to show-value to this new client, and start building trust. With the server about to go out of warranty, we’ve decided to use the drives that had been purchased in a different server, move a couple of shares around, and recommend that the server be repurposed out of the business critical role that it currently occupies.

How to handle a similar situation better in the future? If this were an existing client, we probably would have managed the issue differently. Certainly if we envision working with the PE2650 line more, or the Dell PERC controllers more, we need to come up with some internal procedures for working in the BIOS. Otherwise, we’d be accepting too much risk on behalf of our client – which we really shouldn’t be doing in the first place.

Let me know if you have any thoughts on this process, and if we had any major misses that we could have addressed.

Patching: Not relying on a RAID 1 configuration to test patches

The few responses I got to yesterday’s post weren’t very positive.

I know it’s not an “enterprise” solution. But it wasn’t targeted at enterprise customers. In any case, I’m in general agreement that it’s not ideal (And yes, you certainly should make certain that you have a good backup in place before attempting any of this.)

So what are the risks?

Data loss.

Make a mistake, and say, regenerate onto the wrong drive and you out of luck.

Performance impact.

Regenerating can take time, and degrade the performance of your machine (especially an SBS server, if the regeneration extends into business hours).

Loss of fault tolerance.

When you break that mirror, you’re loosing the benefits of having it. Have a failure before you regenerate, and you’re once again, out of luck.

But is it a bad idea for the SMB market?

I still don’t know. I think it’s a completely unnecessary risk in a larger environment, and I'd never recommend it as an option on the enterprise side of the business. Certainly it has the potential to do more harm than good. But assuming you create a good procedure, and follow it to the letter, then things should go well.

And I guess that’s the real sticking point. Having something that “should” work isn’t the same as having something that does work. If you can afford a “test” server, then it might be worthwhile to save you some time testing patches. But even in the SMB world it might just be too much unnecessary risk.

Patching: Using a RAID 1 configuration to test patches?

I came across an interesting post about patch testing that I thought deserved more attention. The question seemed reasonable enough… effectively, “Does it make sense to use a RAID1 configuration for patch testing and roll-back?” (Or, in other words, pull a hard drive out of the RAID 1 configuration and use it as a roll-back option if something blows-up).

Well, the short answer is that microsoft.public.windows.server.sbs seems to say “No”.

Skim the thread… there were some reasonable alternative suggestions in there about third-party solutions; cloning, livestate backups, and the like. And some good observations about the potential risks of reverting back to an older DC image (that might be worth further discussion). But when it comes down to it, no one liked the idea. And what concerns me is that I’m not sure why.

Can it be tedious?
Sure.

Is it high-risk?
Maybe. Certainly if you haven’t tested it, and created a procedure it’s high-risk.

But is it a bad idea?
I don’t know.

This is just the thing I think an SMB customer would go for. They’ve already paid for the RAID controller and SCSI hard drives, why not leverage them? Why not develop a procedure, and use it when testing things like SP1, Exchange SP2, and the like.

I want to say that it seems like a viable solution.

What do you think? What would be a good patch-testing methodology that allowed for a reproducible roll-back scenario that an SMB-sized customer could get behind?