First Steps from NT to Server 2003

There are two basic approaches to upgrading from NT to Server 2003. The first is an upgrade, and the second comprises an upgrade and restructuring.

With an upgrade, you keep the same network structure you already have and simply replace your NT servers with a Server 2003. That's the easy way, but it may not be the best way for your customer's overall network performance or IT budget.

You need to think about how your customer's network servers are working now and what could be done to improve them. Can you consolidate servers? Can you replace conventional standalone or rack servers with blade servers such as IBM's eServer hot-swappable blade servers?

Or how about replacing simple file servers with NAS (network-attached storage) devices such as IBM's TotalStorage NAS Gateway 500?

If you elect this path, you're going to be restructuring the network rather than just upgrading the servers. This may be a harder sell to the customer, but if you look closely at the actual costs of a restructure—fewer servers, more centralized management—I suspect you'll find that for both you and your customer, a reorganization may be the best long-term way to spend the customer's IT dollars.

You also need to look closely at your customer's existing applications. Not all of your NT applications are going to run on Server 2003. For example, SQL Server 6.5 and 7.0 and Exchange 5.5 won't run on Server 2003. That means your customer is going to need to budget not only for Server 2003 but for updated applications as well.

For the official list of what will run on Server 2003, check the VeriTest Catalog of Certified Server Applications.

If you're planning to upgrade existing NT servers to Server 2003, you should also take Microsoft's official minimum requirements for Server 2003 and double them. 550MHz and 128MBs of RAM, indeed!

If your customer's NT machines don't run at least at 1.2GHz and have 256MBs of RAM, just retire them out. Your clients won't be happy with their performance if you try to make do with less.

With those issues taken into consideration, you're ready to think about your network design. First with AD, many of your tired and true NT domain design ideas are out of date. For example, for all but the largest networks, you'll only need a single domain, whereas with NT, many environments use two or more domains in a master-resource relationship.

For example, if you've been using a master-resource approach with NT, you can stick with a single domain, but you might want to consider multiple domains. If you're using multimaster server, you're likely to use multiple domains with Server 2003, but you might want to use a single domain with multiple child domains. Finally, if your domain structure was one of complete trust, you can expect to set up multiple domains.

Now, some of you who know AD may be asking, "Multiple domains!? What's he talking about? Isn't one of AD's main selling points that it doesn't need multiple domains?"

Yes, that's true in theory, but in the real world, customers often want multiple domains for external branches, different divisions and so on. You can try to sell them on using Organization Units (OU) instead to keep AD's single-domain, enterprisewide management style, but I've found die-hard NT customers to be reluctant to make this move.

After you've figured out what you're doing with your domains, you must organize them in AD. If you have only a single domain, all you need do is attach it to a single AD tree. You only have to worry about whether a forest or tree layout is preferable if you have multiple domains.

Generally speaking, forests work best for companies that are a conglomeration made of several distinct divisions. The downside is that forest navigation and administration is far more difficult than managing a tree. But with proper organization, you can avoid too much forest administration by making sure that users don't need to access resources outside their own tree.

Ready to do the real work? At this point, I'll turn you over to Microsoft. First, the one essential read for anyone moving from NT to Server 2003 is Microsoft's "Migrating Windows NT Server 4.0 Domains to Windows Server 2003 Active Directory" white paper.

After that, you'll want to grab a copy of Microsoft's Active Directory Migration Tool 2.0. I guess you could do an NT migration with it, but you also could ride a bicycle on the interstate—and neither would be the smartest move in the world.

Next up, I'll take a look at some down-and-dirty details of moving from NT to Server 2003. But I'll save that for next week.

Check out eWEEK.com's Windows Center at http://windows.eweek.com for Microsoft and Windows news, views and analysis.

Be sure to add our eWEEK.com Windows news feed to your RSS newsreader or My Yahoo page