Hyper-Ventilation, Act II

Outside, the snow lies deep, crisp, and even. Inside, the continuing quest to achieve calm and serenity through the application of virtuality. Noticeably, without much sign of virtuosity. I know that a "Minister of the Church" is somebody who ministers to the poor and sick as well as the good and the godly. I wonder if, being surrounded by all my very old and somewhat sick machines, I am really a "Network Ministrator". So far, "Administration" doesn't seem to be one of my latent talents. Still, onwards ever onwards...

Scene I, "Reality Begins to Bite"

Today, set up the external Web sites on a separate Hyper-V instance that will sit in the DMZ. I run the old DaveAndAl site that still contains the support stuff for books Dave and I wrote before I drifted into the arms of MS as an employee, and I wanted to keep that available. I also run the local village information site that contains news, events, activities, and other resources for the village action group (based on the ASP.NET "Club" Starter Kit).

This all went reasonably well, except for some hassle figuring out that you have to install the SMTP service separately and use IIS 6.0 Manager to manipulate it. However, the Web app just drops messages into the Pickup folder, and the SMTP service instantly sweeps them up and tosses them out onto the Internet. Installing the SMTP role automatically adds a suitable rule to Windows Firewall; however - if you are only sending mail (and have a suitable return address configured for the messages that is on a different and valid mail server) - you can disable this rule to prevent inbound access to the SMTP server. And I did remember to remove all the default exception rules for other services (except for HTTP and HTTPS, of course).

Final check, get few port scans done from various sites (such as Shields UP and Audit My PC), and go live. Wow, maybe I really can be a network administrator after all! While I've got a couple of hours left I'll prepare the old Windows 2000 box for migration of the domain to Server 2008....

So I read the docs about this process, and start to feel the Hyper Ventilation coming on again. If you have installed Exchange Server 2000 (I have), it will have corrupted three attributes in Active Directly that you "should" (it says) resolve before running ADPREP. But elsewhere it says that these are not really important attributes, and it even says you can resolve them after you run ADPREP. Maybe you can on Windows 2003 Server. On Windows 2000, ADPREP simply won't run at all until you fix them. Time, I think, for bed.

Scene II: "Reshaping History"

I've been following the "migration" approach to domain upgrades that Microsoft seem generally to recommend. You prepare the Active Directory forest and domain using ADPREP to get it up to the target version (2008 in this case), then join the new machine to the domain and use DCPROMO to promote it to a second domain controller. Finally, you move the global roles (such as FSO) to the new DC and then demote the old one.

This process worked reasonably well with the internal Windows 2003 domain, but it was looking like being a bit of an awkward task for the old Windows 2000 domain. Especially as I'd suddenly remembered while watching TV the night before that this machine and its domain started life under Windows NT4 running Exchange Server 5.5. Ah, what wondrous history doth permeate and perfuse my historic domain... and might be an additional cause of my problems. Strangely, I can't find any Microsoft KB articles that describe moving from NT4 to Server 2008...

But I did read up on the schema issues with Exchange Server 2000, and created and ran the scripts to fix the incompatibilities. Or rather, I tried to. None worked. In the end, I resorted to using AdsiEdit to manually change the LDAPDisplayName attributes in the AD schema (see https://support.microsoft.com/kb/314649). After that the ADPREP process succeeded and updated the forest and the domain to the Windows 2008 schemas. Four hours gone so far.

Next, join the new Windows 2008 box to the existing domain. No problem - worked a treat. Then install the Active Directory role and promote the new box to a domain controller. Oh dear - "Failed to modify the necessary properties for the machine account. Access is denied." So, off to search for more help and apply the user rights delegation permission configuration specified in https://support.microsoft.com/kb/232070. After these fixes, DCPROMO ran fine and I had a new domain controller. And it only took seven hours in total.

Scene III: "The Plan? What Plan?"

You see, I thought I had this all planned out. Virtualize my three important and complicated servers so I can keep backup copies of the VHDs and just fire the appropriate one up if the active one throws a software wobbly. Or even run all three on the second identical (cold-swap) backup server if bits start falling off the active box.

Except, now, things are starting to look a bit less well planned. For example, if I need to shut down the host box to fix something, or just to copy the VHD off as a backup, I have no domain controller or internal DNS. So all the other machines on the network start wandering aimlessly around like lost souls. And the same will happen with the virtualized external domain controller once I get that part of the network upgraded...

Worse still, the base machine that hosts the VM that is the domain controller complains when it boots that it "...cannot find a controller for the domain..." (not surprising I guess), and so it gets all huffy about doing even ordinary stuff. Probably the worse huff is that it can't access the Hyper-V Manager service. So you are in the interesting position of not actually being able to talk to your VMs, one of which is the domain controller. OK, so if the VM is set to auto-start, things will sort themselves out after about half an hour. But what happens if it isn't set to auto-start? Or if it falls over when starting? In the end, it looks like I need a physical (rather than virtual) domain controller that starts up before the Hyper-V host machine...

And, again, it seems I should have ordered bigger (or more) disks. Turns out you can't just copy a VM file and the corresponding config file to another Hyper-V enabled server and run it, because that screws up the network configuration (see Hyper-V Export and Import Part 1 and Part 2). You need to use the Export command in Hyper-V Manager, but that only works when exporting to the same physical host machine.

I suggest you become familiar with Ben Armstrong's blog at https://blogs.msdn.com/virtual_pc_guy/, 'cos he does document many of these kinds of issues. For example, whether to virtualize domain controllers, how to manage VMs with script, how to export VMs, and much more. He also references other blogs that describe import/export work-rounds, though none are officially supported. I used an old spare machine to expose backup storage space for exported VMs and used the process described in the comments to Brian Ehlert's blog post to export them to that machine. But make sure you read the security caveats.

And if you intend to make backup copies of VMs to run on another machine should a hardware disaster occur, check out John Howard's blog as well - especially Why is networking reset in my VM when I copy a VHD? and MAC Address allocation and apparent network issues MAC collisions can cause.

More next week...