In the last year or so, hardware-independent imaging has received increasing attention. The idea is that you can create an image of a live server and restore it to another machine, updating device information in the process. This promises to be much simpler and faster than having to build a new machine from scratch, add it to the domain, elevate its role, etc.

A client recently agreed to replace their five-year-old Dell PowerEdge 1500SC with a new Dell PowerEdge 1900. This small organization uses one server running Windows Server 2003 R2. It acts as a domain controller, web server, file server, print server, and (non-Exchange) mail server.

I decided to give the hardware-independent option a try. StorageCraft's ShadowProtect seems well-respected in the Small Business Specialist community, so that is the product I used.

With maybe eight to ten hours of preparation, I was able to successfully migrate the server in about five and a half hours. While not as fast and easy as I had hoped, it is still nice to have the new server in place with all of its unique enhancements and configurations fully implemented. Remember, to do this manually would mean not only installing and configuring the operating system, but also UPS software, anti-virus management and client software, backup software, printers, file shares with permissions, Services for Macintosh, IIS, web sites and applications, mail server software, line-of-business applications like QuickBooks, etc. With a manual migration, I would expect there to be ongoing issues regarding things that didn't get configured correctly, or that I forgot to configure. With this approach, I feel more confident that the project is actually completed (knock on wood!).

Notes for Next Time

Rather than publish eight pages of notes on all my trials and errors during the project, I thought I would try to summarize the things that I want to remember next time I do this.

ShadowProtect Editions

I used ShadowProtect IT Edition 3.0.0.5 for my initial testing, then thought I would try ShadowProtect Server Edition 3.0.0.3 for the actual deployment. Both editions let you boot from a CD into a recovery environment where you can create and restore images. However, when I tried to do a hardware-independent-restore (HIR) using the Server Edition, in spite of the green check mark indicating that the operation completed, there was this obscure warning:  "HIR Configuration Status: stopped (target is not a supported Windows volume).” Sure enough, the new machine would not boot successfully:  as soon as it tried to start Windows, it immediately rebooted the server in a continuous loop.

StorageCraft's knowledge base does not list this error. Google led me to a forum posting with the answer:  “The HIR functionality that ships inside the Desktop/Server Edition 3.0 Recovery Environment can only be applied toward supported OS volumes on which ShadowProtect itself is installed. The HIR functionality in IT Edition 3.0 has no such limitation.” In other words, it was failing because I had not installed ShadowProtect Server on the server before creating the image. Switching to the IT Edition allowed me to successfully complete the hardware-independent restore.

Moral:  be sure to select View Details so you can check whether the HIR really worked!

ShadowProtect Environments

ShadowProtect has developed a new environment based on VistaPE. In the Server Edition, this is simply called the "Recommended" environment, while the previous environment, based on WinPE, is called the "Legacy" environment. However, in the IT Edition, these are labeled "Vista" and "XP/2003" respectively. This led to some confusion, as I thought I needed to use the "XP/2003" environment to image and restore a Windows 2003 machine. It turns out that the Vista environment can be used for imaging and restoring any supported operating system. There are a few "gotchas" in both environments:

• In either environment, if you are not seeing your disks, click on Refresh Volumes Info a couple times.
• I found that the Legacy environment would only recognize the PERC 5/i RAID controller in the PowerEdge 1900 if I enabled network support. Since I was working with physically-attached drives, I had no need for network support, but every time I chose not to enable it, the PERC 5/i disk (and hence the volumes to which I needed to restore) was not visible. This was not a problem in the Vista environment.
• The Disk Map feature is identified in the ReadMe file as experimental. I found the version in the Legacy environment to be more stable. On at least two occasions, Disk Map in the Vista environment produced flaky results:  a partition re-appeared after it had been deleted, and an attempt to format a partition with a non-default cluster size failed.

Drivers, Drivers, Drivers

It makes sense that during a hardware-independent restore, ShadowProtect needs drivers for the new hardware. I was prepared to provide drivers for the network and RAID cards. I was surprised that it also needed much more common drivers like various USB and disk support drivers. Some tips on getting the drivers ready as quickly as possible:

• You cannot remove the ShadowProtect CD during a restore, nor can you add and recognize a USB drive once ShadowProtect starts complaining about drivers. If you start getting missing driver messages and the drivers aren't already available on media that is currently attached to the server, just note the driver name and ignore the error. Do this for each missed driver (11 of 63 in my case) and you will have a complete list ready for your next attempt.
• Once you know the drivers that you need, copy all of them to a USB hard drive or thumb drive. I found that I needed not only the PowerEdge 1900 drivers (extracted via a rather arcane command line from the CD that came with the server), but also the drivers for a SIIG eSATA card, and the Windows Server 2003 R2 install CD #1. Add paths to the specific .inf files when you specify that you want to do a hardware-independent restore. Once I added the Win2003 \I386 path, all of the warnings about missing USB and disk drivers went away.
• The new server uses USB for keyboard and mouse. I was glad when I got to my first logon prompt, but then panicked when I could not type or move the mouse. I went away for a minute to look for answers. By the time I came back, the mouse and keyboard were working. Apparently Windows 2003 just needed a minute to install those drivers, which it fortunately could do even before I logged on.
• Even after doing the HIR, when you first log in to the operating system on the new server, it will do lots of its own hardware installation, in some cases prompting you for driver files. Lucky you, you already have the driver files in an attached USB drive, so just point it there and you're good to go!

After the Restore

Following the practice that Handy Andy published, I used Directory Service Restore Mode (DSRM) for initial server configuration of this domain controller. These are the tasks that I had to complete after the restore (many of them specific to this environment):

1. Install hardware drivers as prompted.
2. Set the correct time.
3. In Add/Remove Programs, uninstall hardware-specific programs, e.g. old Dell DRAC and OpenManage software.
4. In Disk Manager, make sure that the new drive mappings match the old, and correct if necessary.
5. In Device Manager, uninstall a duplicate COM1 port, and update the Display Adapter driver from Standard VGA to the display driver from the server's driver CD.
6. In Network Connections, duplicate the settings in the new network card that you had on the old card, including the fixed IP address and DNS server. Even if you told ShadowProtect to uninstall the old network card, it apparently doesn't do that, because I got a warning about creating an IP address that duplicated a hidden adapter. You have to choose No, do not use a different IP address.
7. In Computer Properties > Advanced > Performance > Advanced, Change Virtual Memory, set your virtual memory based on the size of RAM in the new machine.
8. Under Administrative Tools > Routing and Remote Access, reconfigure AppleTalk on the new network adapter.
9. The new machine does not have a parallel port. To stop the "service failed to start" message, disable the parallel port in the registry. From regedit, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parport \Start to 4 (Disable).
10. The old Shadow Copy configuration is now invalid. In Task Manager, delete the existing ShadowCopyVolume task. Then in Explorer drive D Properties, enable shadow copies on D. Set schedule to run Daily (not just Monday through Friday) at 7:00am and 12:00pm. Leave Storage area limit at default 10% of drive size.
11. Reboot into normal mode. Check event logs for services that failed to start. PowerAlert (UPS monitor) service fails to start; let's hold off on that.
12. Test line-of-business applications and locally-hosted web site.
13. Unplug the router from the Internet. Connect the server to the LAN. Test workstation logon and access to the server. Test a Terminal Services connection from a workstation to the server.
14. Install new Dell OpenManage. Install Broadcom Drivers and Management Applications. Configure the Broadcom offload engine (TOE).
15. Make sure anti-virus software is running. Connect router to the Internet. Test web access. Test incoming and outgoing email. PowerAlert is happy now that it has network connectivity.
16. Go home!

P.S. The day after the restore, I was getting some unusual Srv 2021 errors in the event log. These were probalby due to the new hardware, not the restore itself. But in the process of working through Microsoft KB 317249, I discovered that both of the volumes were fragmented. Also, even though I had formatted drive D with 16KB clusters, it was back to 4K clusters. Apparently ShadowProtect does a cluster-level restore, duplicating the format of the source volume. So I defragmented both volumes, then ran chkdsk /r, which found and cleaned up several minor inconsistencies. So, another note for next time:  run defrag and chkdsk before capturing the image, and to be safe, again after the restore.

I've been learning about so many development strategies in the last few months that my head is spinning! My journey has taken me in two main directions:

1. Learning about concepts like object-oriented programming (OOP), design patterns, test-driven development, and agile development.
2. Learning about tools that support #1.

This article makes no attempt to be comprehensive about either point; it's mostly just a list of resources that I'm using and may need to refer to again.

Concepts

New books on my bookshelf:

• Head First Object-Oriented Analysis & Design, recommended by Eric Kaufman. I found the cartoonish style of the book distracting, but it still has some good information especially about how to tackle a new project.
• Martin Fowler's UML Distilled: A Brief Guide to the Standard Object Modeling Language. Fowler, I've learned, is one of the OOP and architecture gurus that every other guru cites. Once I read this book, I realized why--he writes well, and one has the sense that his ideas have evolved from experience, not in an ivory tower.
• Martin Fowler's Patterns of Enterprise Application Architecture. Still waiting to receive this one. Fowler has ingeniously posted summaries of the patterns in the book, so all kinds of web articles refer to his summaries, and each summary says, "For a full description, see P of EAA page nnn." Okay, already, I'll buy it!

Relevant articles and blogs:

• Billy McCafferty's NHibernate Best Practices with ASP.NET. According to reader rankings, this is the #1 article in the CodePlex Design and Architecture section. I didn't learn much about NHibernate in this article, but I learned a lot about architecting web applications. He goes into great detail about separation of concerns, keeping the data layer from depending on the domain (business) layer, etc. Downloadable files include a basic sample and an enterprise sample. It's rare to come across someone who knows his stuff and knows how to explain it in writing. McCafferty has both. Tons of links to other resources, as well as over 700 follow-up comments with lots of helpful answers.
• Billy McCafferty's blog. Maybe I should have started here. It sounds like McCafferty's group has decided to abandon the (somewhat complex) techniques laid out in the preceding article and convert their current development to Castle MonoRail. I've been considering MonoRail; I must say that McCafferty's enthusiastic endorsement after several months of use is encouraging.

Tools 

As usual, Microsoft is doing a great job of promoting upcoming technologies like LINQ and Silverlight, and I've spent some time researching those. But I need something I can work with now, not something in beta. So my attention has turned towards more established technologies, even though they are not from Microsoft.

Object-Relational Mapping (ORM)

It didn't take me long to realize that I did not want to hand-code all the data access logic for my program. It turns out that linking classes to database objects has developed into quite an industry. There are dozens of Object-Relational Mappers (ORMs) out there (Wilson's O/R Mapper and Entity Spaces, for example), but the one I heard about most often was NHibernate. NHibernate is the .NET version of Hibernate, a "persistence engine" for Java. Unlike many free open-source tools, this one seems to have a wide following and to have proven itself in many large, real-world applications.

Built on NHibernate is Castle ActiveRecord, which hides a lot of the complexity of NHibernate but supposedly lets you get to it if you need it.

Web Development Frameworks

Visual Web GUI is a really fascinating framework that lets you build a web app that looks almost exactly like a WinForms app. It's tempting to go down this road, as I would like to do something of a Rich Internet Application (RIA). However, this is a fairly new framework, and seems to be lacking integration experience with ActiveRecord, for example, so I'm currently leaning towards the more established MonoRail.

Castle MonoRail is a .NET approach to Rails(TM) development, popularized by the Linux-based Ruby on Rails. The main benefit here seems to be a pre-built framework that simplifies developing with the Model-View-Controller (MVC) design pattern. It integrates with Castle ActiveRecord, and it supports test-driven development. And, well, Bill McAfferty thinks that the Castle Project is cooler than Jerry Springer. 

The Castle

So in short, it's starting to look like the Castle Project is my new best friend...unless of course I come across the next great thing tomorrow!  

Today as I was pondering some modern architectural paradigms, I got to thinking about my procedural programming roots, which led me down memory lane to my early computing days.

Basement Computing

Back at university, my computer science classes taught me about bubble sorts and data structures like linked lists and b-trees. We learned to write a structured FORTRAN program when the compiler didn't enforce the structure. We learned Pascal, which did enforce the structure. We did a little assembler on PDP 8s and PDP 11s, pressing a toggle switch and watching the registers change. To use the bigger CDC computer, we descended to the basement of the Technical Institute to submit our programming lessons as batches of card. We waited impatiently until the traction-fed output was wrapped around the card deck and stuffed in pigeon-hole style mail slots. One of the student employees placed a sign above the window that promised, "A $5 bill behind the job card reduces turnaround time." Eventually we progressed to a room full of data terminals.

Once I got into the real world in 1979, this all proved pretty much useless; I was asked instead to use COBOL to read in magnetic tapes full of historical accounting data and print various reports.

That company used a water-cooled IBM 370/168 that looked a lot like the one pictured above. What is not shown in the picture is the raised floor required for all the cables, nor the the garage-sized room full of backup batteries. Of course mere mortals were not allowed to touch the computer; the computer room, with its arctic air conditioning, was secured behind keycard-locked doors and took up a goodly portion of the building's basement. Unescorted programmers could get as far as an outer lobby and peer through the glass at the humming blue monster. The machine's operations manual lined the side of this outer vestibule in a five-foot-wide binder rack.

Punch Drunk

Actually, we programmers didn't have to go down to the basement that often. A team of half a dozen key punch operators sat in a small room adjacent to the computer room. We could write our programs out on wide coding pads with a small block for each letter, then send them via inter-office mail for keying. They would then take these pads and create stacks of punch cards for us.

I don't think many people today fully appreciate how a key punch machine works. Every time you press a key, it punches a hole in the card. Well actually by this time, the IBM 129 Card Data Recorder was in use, which held an entire card (80 characters) in a buffer so that it was possible to back space if one made an error. When you finished the card, you pressed a Release key to punch the entire card. To ensure accuracy, each coding pad (or data entry sheet, as this is also how customer data got into the system) was keyed in twice, by different operators. The first operator punched from blank cards. The second operator re-entered the same data but with the already-punched cards in the hopper; if a discrepancy was found, the operator rejected that card and created a new one.

Even with turnaround of only a few hours, this process of dropping off coding pads for punching was rather laborious, especially when the only change required was to add one of those pesky periods that COBOL was always complaining about. So we also got a card punch machine for the programmers to make minor modifications. I remember how excited I was that we got one with an LED display that actually allowed looking at the text before punching it.

Winds of Change

By the time I left that company in 1984, we had advanced to IBM 3270 display terminals connected directly to the mainframe. Although some "old school" programmers didn't like the thought of having to type in their own programs, I thought it was great. I loved the powerful editor (XEDIT) on those terminals that could do things like display only the lines containing a certain string.

Also by 1984, we had started getting into a revolutionary relational database from Germany called Adabas. The concepts I learned then about database normalization still apply today. We were starting to plan for interactive programs that would actually allow end users to look up and enter data on demand. We were reading Tom De Marco's Structured Analysis and System Specification. There was even a PC or two knocking around, mostly used for word processing. I remember one of my colleagues who was convinced that the PC was going to revolutionize computing. He planned to buy one, quit his job, and start his own computing company. I thought he was a little crazy.