Ah, the joys of pulling a 15 hour day yesterday… it wasn’t all bad; if it was, I wouldn’t have been able to throw down a couple of posts.  That said, I’m rather ridiculously tired, so if today’s post veers towards incoherency, there’s probably a really good reason for that.

The 15 hour day was the direct result of a customer’s Exchange (e-mail, among other things) server going down.  That this particular customer was located about an hour away from where I live and normally work certainly didn’t help matters any.  However, I learned about a couple of interesting toys that can make a restore go sooooooooo much smoother.  First, though, I wish to rant for a bit about Windows, and why it absolutely sucks when it goes down.  I’ve done this before, of course, but I want to expand on it a little today.

One of the nasty side-effects of some of Microsoft’s choices in the past is that Windows is arguably much more difficult than it needs to be to restore, which means that it’s much more difficult than it really should be to back up.  The culprit, as always, is Active Directory, which, in any Windows-centric office, is essentially the glue that holds the world together.  Without Active Directory, you don’t have user accounts, which means people can’t log into their workstations, which means nothing gets done.  If Active Directory comes up missing, you are hosed.  Active Directory stores its information on a server known as a Domain Controller.  You can have just about as many Domain Controllers as you want, practically speaking, which is a very good thing - if you have more than one, you can just replicate the information to the other domain controller(s) and almost never worry about restoring Active Directory from scratch.  If you have to restore from scratch… well, let’s just say that Microsoft was apparently staring long and hard at Schrödinger’s cat; in a vain attempt at creating (or, at least, inspiring) a Heisenberg Compensator, Microsoft created a backup and restore scheme that requires your server to know not only what it was at the precise time of that backup, but also precisely where it was going to go next.  It’s a rare company that would dare laugh at quantum physics, but I suppose you can get away with it when you’re worth billions of dollars.  Needless to say, this makes my job damn near impossible… or, at least, it did, until I learned about a new toy…

That’s right - the VMWare Converter.

Now, how would this piece of software unravel quantum mechanics as we know it?  Easy - by effectively creating a byte-level backup of the server and converting it into a VMWare image, which, in turn, can be launched in VMWare as a virtual machine should the source server go down.

(Right about now is when I lost about half of the few regular readers I have around here.  It’s okay - you can come back when Rachel links to me again.  She’s a little busy with Rupert right now, though, so it’s going to be a while.)

First, a quick primer on virtual machines…

A virtual machine is a machine-in-a-machine.  To help conceptualize this, pretend that you are a computer.  Now, let’s pretend that we installed a second personality inside of you (a second soul, if you will).  It will only have access to the body parts that you grant it when and where you choose to grant it, and, if you’d like, you may grant it complete control over everything.  You may decide after a while that you want control back - if you do, you may take it back.  The result is something similar to a split personality, only you can talk with the split personality, switch them at your choosing, and it’s only as hostile to your personality’s ability to perform in the real world as you choose to let it be.

Now, let’s pretend that somebody close to you dies (say, that friendly server above you that keeps you warm at night).  Using the VMWare Converter (were you a computer, of course), we could create an image of that server before it dies and install it into you; once that server dies, we could then turn that virtualized version of the server on.  Whenever someone tries to call that server (Hey, Johnny!), instead of the dead server responding (or, for that matter, failing to respond), the new alternate personality in your head would respond (Hi!  I’m over here!).  Now, as I’m sure you can imagine, if a lot of people used to talk to this server, things are going to be a little slow for both you and your new alter-ego.  Even so, it’s sometimes better to be able to talk to the dead slowly than to not talk to them at all.

(Thus endeth the most confusing and metaphysical explanation of server virtualization ever.)

Now, the cool part for me yesterday was that, since my problem server wasn’t dead - just slowly dying - I still had time to run the VMWare Converter on it (or, as the case may have been that night, run ShadowProtect on it, then convert the resulting ShadowProtect image - it was faster than running the converter directly, believe it or not), which is why, instead of having no e-mail at all, that particular customer now has slow e-mail, a slower SQL server (it had the most free resources and was the newest server in the office), and a new server on order… and they were back up to fully functional by the end of the night, at least until I logged out, at which point I learned another important lesson:

“Always run mission-critical virtual servers as Local System, not administrator… at least not if you plan on logging out at all.”

Ah, c’est la vie.

You may now return to your regularly scheduled blogging.

Trackback URI | Comments RSS