My firm has been running Small Business Server 2003 for a few years now, and there’s no question that it’s been a life saver for us. SBS is a critical product for the industry.

But, in retrospect, given the nature of our business (Windows security development), we sort of outgrew SBS before we’d even deployed it. That is, our infrastructure demands have always been a little too sophisticated (e.g. too many client machines; need an enterprise CA; etc). It was the right decision at the time, though.

This post is really a continuation of a recent one in which I described the successful migration of a physical file server over to Hyper-V (HV).

One side note to that post: after that migration, the domain machine account of that server somehow got whacked, so I had to disjoin and rejoin that machine to the domain. Not a big deal, but I have no idea why that happened. Let me know if anyone else has seen that.

Anyway, that file server migration was really just a practice session for migrating the SBS machine. This is for the same big reason that I mentioned before: disaster recovery. The SBS is actually already protected by two separate backup solutions, one of which is offsite. But the machine itself is old, and system restoration is notoriously sensitive to hardware changes (i.e. in case I couldn’t find the same replacement hardware in a pinch).

Plus, the ultimate goal, once everything’s in HV, is to protect the VM images two ways: first, an onsite copy on a network share. This is for rapid recovery in a “minor” disaster scenario. Importantly, there’s no dependency on finding the same hardware. In theory, this should yield a full recovery in at most a few hours, probably much less.

The second backup plan is to mirror the VM images in the cloud, such as on Amazon’s S3 storage service. This addresses the major disaster scenario. While it might take a few days to copy the latest VM images down to a new location from the cloud (once the new location exists), that’s likely better than starting over, due to reasons discussed in my previous post.

One problem, though: for the life of me, I could not get the existing SBS image running in HV. I tried several different things, but I think it boils down to these two roadblocks:

First, the primary disk on the SBS is SCSI, and Dell (like many manufacturers) uses a small hidden EISA partition for configuration. The problem is that, contrary to what’s implied in the online forums regarding the behavior of VMware Converter, that tool doesn’t handle the EISA partitions correctly, in that the resulting primary partition isn’t bootable.

If you do decide to try that route, be sure to not attempt to convert the EISA partition and do fix-up the boot.ini in the resulting primary partition image. You’ll at least get as far as I did. But even after that I couldn’t get past a BSOD 0x7b in text mode boot.

The second roadblock is the affinity that SBS has for physical NICs and TCP/IP settings. There are lots of reasons for this, including the use of features such as Remote Access. To summarize, after giving up on VMware Converter, I tried setting up a clean SBS instance within HV and doing an NT restore of system files plus AD data.

If you happen to try that route, be prepared to reboot your system many times, since you’ll need directory restore mode for the AD restore, Safe Mode to get the virtual devices detected again, and possibly directory restore mode again in order to fix-up the network settings (see this post). The other hazard with this approach is that I found it difficult to troubleshoot the VM without it having access to the LAN, which is a problem since it implies the the original physical/production server must be off the LAN and its IP address temporarily migrated.

Ultimately, with the second approach, I couldn’t get the SBS VM to be fully responsive on the virtual NIC. I also noticed that the Windows networking subsystem still had hidden references to the old physical NICs, even though that hardware was no longer connected. More experienced SBS administrators may have work-arounds for either or both of those problems.

Also, for posterity, it’s possible that you could have greater success in only restoring AD data, but excluding system files. If you try that, you should probably run completly through SBS setup before doing the AD restore (rather than cancelling SBS setup and doing the full restore after the first logon, which is what the docs recommend). Potentially, that approach would give you all of the system files you need, while minimizing the risk of bringing in conflicting settings.

Anyway, I gave up on that approach. Instead, I introduced a separate (VM-based) Server 2008 DC into the existing SBS domain. These two posts (here and here) tell you pretty much everything you need to know.

This “extra DC” approach at least gives us some redundancy in case the SBS dies.

1 Comment »