Windows 2003 Migrations Made Simpler

by Paul Rubens

Whether you've decided to retire a few Windows NT servers or need to migrate a slew of Windows 2000 servers, an extreme makeover is in order -- even if you're staying in the Microsoft fold. What's the best way to go about it, and does it always make sense to dump NT?

As rampant as Windows NT 4 installs remain, it is doubtful many organizations are still running their businesses exclusively on Windows NT servers. By now, most Windows shops are running at least the majority of their computing infrastructure on Windows Server 2000, if not Windows Server 2003.

Discuss this article in the ServerWatch discussion forum

For those enterprises running Windows 2000 with the odd NT server in the mix, it's certainly time to migrate to a new server platform. That's because NT is no longer supported (apart from the horrendously expensive custom support service Microsoft can provide), and the 2000 product is nearing the end of its support life cycle.

As discussed in an earlier article, this presents an opportunity to migrate to an open source server platform, such as one of the Linux distributions, but many organizations — for any number of valid reasons — will prefer to remain in the Windows fold.

Windows Server Longhorn will be out shortly, but for most organizations it would be madness to migrate to this server platform in the near future: If nothing else, the security of the new OS is completely unproven, and until the whole package is better understood, the chances of a trouble-free migration to Longhorn will be pretty slim.

So if you are running a 2000 or mixed 2000 and NT environment, the most sensible migration is to the stable and well-understood Server 2003 platform. But what what is the best strategy to ensure a successful migration?

Windows Server 2003 has more sophisticated Active Directory functions than 2000 and goes far beyond anything offered in Windows NT. To make the migration more manageable, ensure all the domain and Active Directory information being migrated to 2003's Active Directory is correct and up to date.

"Before you start any migration, it's vital that you take control of your existing environment," says Jonathon Southam, a consultant at U.K.-based systems integrator Ancoris. "Most organizations will find they have too many domain admin accounts, that most users have too many permissions — that kind of thing."

Failing to do this, says Southam, is the single biggest pitfall in a migration of this nature. If nothing else, it's a question of risk management, he says. "Taking control of your environment is all about security, and it's vital that you maintain a secure infrastructure. When you redeploy Active Directory (or deploy it for the first time) you can lock down what people can do and see. It's always quite surprising when companies do due diligence on access and find that many people have access to data that they quite simply shouldn't. If you don't take control, then this is a major missed opportunity," he says.

It's also critical to get a clear picture of the scope of the migration project. "This means you need to understand very clearly what you need to migrate and what you can leave behind," says Southam.

The hardware Side of the Software Migration

Windows 2003 is far more scalable than NT, so the less you leave behind, the more likely there will be a very extensive opportunity for server consolidation as part of the migration. According to Microsoft figures, you can get away with half as many 2003 Web application servers as NT based servers, for example, and while 500 users could be supported on a single NT-based Exchange server, 2,000 can be supported on a 2003 Exchange server.

Talking of hardware consolidation, its worth noting that — as always seems to be the case with Windows — Windows 2003 needs far more powerful hardware than NT or 2000. Since the lifetime of a server is only a few years anyway, be prepared to get the Dell or HP catalogs out: You're going to be in the market for some new server hardware when you carry out the migration.

The process of migrating individual servers to 2003 is beyond the scope of this article, but it can be done in any number of ways that may involve in-place upgrades (from at least Windows NT 4 with Service Pack 5 — probably by mirroring the NT server onto newer and more powerful hardware first), retiring Primary Domain Controllers or Backup Domain Controllers and replacing them with fresh installs of 2003 and migrating data into Active Directory, and often reinstalling applications on new or upgraded application servers.

This process will be dictated, at least in part, by your overall migration strategy: Are you going to keep the entire system operational while you migrate in phases, testing each one as you go; or, are you going to set up a completely new system in one fell swoop, test it extensively, and then switch over while decommissioning the old one?

Whichever way you choose, remember that all your endeavors are secondary to the main goal of your organization — carrying out whatever business it is involved in. "Before you do anything, you should be testing as many different variables and factors as you can," says Southam. "You need to be absolutely sure that, however you carry out your migration, all your users can access the resources they need. It needs to be completely seamless, so users can log on and access their directories, applications and email as usual."

Tools and Other Applications

Many tools are available to help automate and speed up the migration process, and these can also help you avoid human errors — if they are configured and set up correctly. It's important to test any under consideration to ensure they behave as expected. It's also worthwhile to carry out a careful cost-benefit analysis. Some tools, such as Microsoft's Active Directory Migration Tool are free. Inevitably, however, these lack the power of some (non-free) third-party tools.

What about the organization's applications? If you are running mainstream packages on NT, there is little doubt that there are subsequent versions that run on Windows Server 2003. But what do you do with bespoke apps? The answer to this depends on many factors, including whether the original developer is known and still available, and what language the software was written in.

Applications written in Visual Basic 6, C++ and other languages can be moved to a 2003 server, unchanged. They can also be rewritten to the .Net framework fairly easily. To run VB6 applications successfully, for example, you must make sure the VB Runtime is installed. To run C++ applications that rely on Microsoft Foundation Class libraries, the correct MFC libraries must be present.

You should certainly factor in extensive testing of any applications you intend to run on 2003, and a number of tools are available from Microsoft and third parties to check and verify the application will perform as expected. It may be necessary to run applications originally designed for NT in NT compatibility mode on Server 2003 to avoid some common problems.

Where it is impractical to move a particular application to 2003, then aside from a rewrite, one option that should not be overlooked is to do nothing and continue running NT, says Southam. "There are security risks associated with this, but the fact is that most hackers don't tend to write exploits for known vulnerabilities in NT. We see many companies keeping their applications on NT — it's just a risk they are willing to take," he says.

One way to lower this risk is to run the applications in virtual Windows NT machines. The technology to do this is available today from VMware. It will also be included in Longhorn, whenever that becomes available. This virtualization solution at least buys some time until the NT application in question can be rewritten or replaced, or is simply no longer needed

There's no doubt that Windows NT is well past its prime, and a migration from it — and Windows 2000 — is due. But don't deplete your pool of Windows NT skills too quickly: You may need it to administer NT servers, perhaps running virtual machines on Longhorn, for several more years to come.

This article was originally published on Thursday Feb 8th 2007
Mobile Site | Full Site