Microsoft

Craft a detailed plan when migrating to Windows 2000 Server

Moving from Windows NT 4.0 server base to the Windows 2000 platform? These tips on designating your project team and designing your migration plan can help you reduce headaches and ensure success.


Windows 2000 Server offers stability, scalability, and networking benefits. A successful migration, however, involves a lot of planning. This article discusses the planning, design, and deployment issues to consider when moving a Windows NT 4.0 server base to the Windows 2000 platform.

To achieve a successful migration, you need to designate the right technical leads and allow them to concentrate on the research phase with minimal interruptions. It’s better to assign a key person to focus on the architecture of the new environment and place someone else in a temporary role to cover daily tasks, rather than to keep pulling your key resource away to address routine concerns.

After studying the existing environment and the new capabilities of Windows 2000, the team members should meet to consolidate ideas and begin planning the design of the new server environment. The technical lead should be responsible for capturing, distilling, and documenting the architectural design and concerns for the rest of the team. The project manager would be responsible for creating a rough project plan with high-level objectives. The details of these objectives can be formulated with input from the team.

Once the team has outlined business requirements, members will need to analyze the current Windows NT server environment to determine the direction and scope of the effort. This strategy will help expose any potential pitfalls.

Current environment
A detail-oriented administrator of the NT server group should begin by assessing the current environment. The technical lead can work with key architects during this phase to decide how to take advantage of the new features available in the Win2K server and its variations.

Server inventory
A detailed server inventory should be compiled to include the following information.
  • Hardware type and revision levels: Each server type should be checked to determine whether the configuration is supported on the Hardware Compatibility List (available on the Microsoft site).
  • Resources (CPU, disk, and memory)
  • Server functions (file/print, application, Web, database, remote access, etc.)
  • User community served

Make sure that each server has a reliable list of all pertinent data and establish a repository for all server data.

Data/application mapping
Make sure that servers that contain corporate data in databases and files are listed in your server documentation. When you combine this information with the general server inventory above, you can determine whether you should consolidate servers or design a more efficient use of resources. Utilizing SAN technology to consolidate data stores can also facilitate data sharing off the communications networks.

Network topology
The documentation library needs to include an accurate network topology that details server and subnet deployment. The design team can use this documentation to determine whether servers can be consolidated and subnets restructured with reasonable effort and minimal risk.

You should also consider keeping the server-to-server traffic segmented (away from the client workstation traffic) whenever practical. The network (LAN/WAN) team should be intimately involved with the Windows server administration and design team to create a synergistic environment for the new domain structure. This is particularly true if you are adding servers or taking away servers due to consolidation of data and server resources.

For example, with the newest high-power servers, you may be able to replace three or four servers with one larger one that can handle the same workload and lower the administration level required to maintain it.

Another option is to take the 3-4 network ports used by the previous servers and connect them to the larger server using one of the newer multiport LAN switched cards, which will give you several times the bandwidth and no changes to the network except to route the cables to the one server.

Whenever the mix of the server environment changes, it makes sense to get the network folks involved early and at a design level, so they can help you tune the environment. If you just ask for ports, that’s just what you get—nothing more. Don’t assume that the network team will be proactive enough to get involved with a review or redesign unless you specifically ask for their involvement. Generally, a minimum of 100 Mbps per server is needed, so try to keep segments that are required for large server-to-server traffic separate from the segments that service user workstations.

Domain structure
Windows 2000 has a more hierarchical domain structure and allows administrators much more control, flexibility, and decentralization in assigning administrative rights. In the past, Windows NT Server environments had typically used multiple domains for dividing the user bases. This structure can now be done with organizational units.

Project management
An experienced project manager (PM) should be assigned to work with the technical lead and be responsible for providing updates to management on project status or clarifications. This strategy allows the technical lead to focus on the architecture and design/deployment issues.

The PM should be responsible for creating and monitoring the project plan (typically in Gantt Chart format), a responsibility matrix, and resource requirements.

Project plan
The project plan document shows the proposed lifeline of the project and denotes key milestones. The plan should indicate how time and resources have been allocated. It should clearly identify the tasks and assignments that are running behind schedule and what resources are involved in the delay.

The following is an “average” schedule for a server migration.
  • Planning and acquisition of data: 1-3 months
  • Design and preliminary testing: 1 month
  • Final testing and training of administrative and support personnel: 1 month
  • Deployment: 1-4 months

If your company is small (less than 100 employees), this schedule could be considerably lessened. The time frame can also be shortened if your technical staff is already well versed on the issues surrounding the migration to Windows 2000. The time will vary depending on the number of people working on each phase and whether outside consultants are involved.

Responsibility matrix
The responsibility matrix is an overall map that outlines the various assignments and who is responsible for completing them. A team, department, or individual may be designated on the matrix as the responsible party for a particular task. The matrix also designates a “go-to” person for each assignment.

This document is necessary for the technical teams to remain in sync. It’s especially valuable because some people fail to read a detailed project plan and focus instead on completing their particular tasks. If a technical issue needs to be addressed quickly, the responsibility matrix lets team members identify the most knowledgeable resource.

The leads of each team must sign off on this document and the project plan before funding or planning can move forward.

Resource requirements
The work effort is based on the feedback received from team leads in response to the project plan. After reviewing the plan, team members should add more details about each activity—such as the duration of each task and suggested personnel who will be involved. The project manager then integrates this information into the plan and arbitrates with the managers if they are concerned about the time commitment and assignments that are expected of their employees.

These project details are not part of a separate document but are inserted into the project plan after the initial phases of the project, milestones, and high-level tasks are delineated. The respective team leads use the first draft of the project plan to work with the technical staff to define the detailed tasks and subtasks, and give estimates on how long each should take. Team leaders also need to work with the resource managers to get the actual names of the resources and assign them to specific tasks.

Design and deployment
Standard Server configurations
After your staff has taken inventory of the servers, you’ll need to publish and adhere to a basic configuration for the minimal accepted configuration for Windows 2000. This will allow you to identify old servers that will not be viable for migrating to Windows 2000. In addition to the minimal configuration for older servers, you need to determine standard configurations for new acquisitions for file/print, Web, database, and application servers. Be sure to share this information with the project team.

Server consolidation
If there is the possibility of consolidating servers into a more effective and cost efficient environment, now is the best time to plan this consolidation. Perhaps one larger server could address the file/print needs of several departments, which would save network connections and minimize network traffic between servers, especially if the consolidation involves e-mail or database servers.

Domain restructuring
There are a variety of benefits to restructuring the domain(s) when moving to Windows 2000. You may want to move multiple domains to a single-domain model with many organizational units to form the business hierarchy. This strategy simplifies the administration of users and domain trust permissions, and gives even more flexibility with local administration privileges.

If you are planning on moving to a one-domain model and currently have multiple domains with various trusts in place, it would be much easier to migrate to a Windows NT 4.0 single domain before you migrate to Windows 2000.

When upgrading domain controllers, you may want to keep backup domain controllers off-line while you migrate the primary to Windows 2000. If the migration fails on the PDC, you can promote a BDC to Primary and bring it online.

Administrative utilities
Many tools exist that facilitate the planning and deployment of a Windows 2000 migration. There are tools in both the Windows NT 4.0 and 2000 resource kits that will allow you to dump the contents of the user database for use in importation to another. In the Windows 2000 resource kit, the SIDWalker tools are used to migrate permissions from one domain to another.
  • Showaccs.exe (Show access profiles for all files on computer)
  • Addusers.exe (Useful for dumping account information from NT 4.0 servers in order to facilitate migration to Windows 2000)
  • Sidwalk.exe (Used to migrate permissions from one domain to another)
  • Ntrights.exe (Allows modification of user rights from command line)
  • Netdom.exe (Command line utility used for migrating computer and workstation accounts)

Sequence the migration
Depending on your situation, you may decide on a sequence to follow in the migration of your servers to Windows 2000. The decision on whether to deploy Active Directory Services at the initial rollout of Windows 2000 will help you decide which servers go live first. The lead technical person should become well versed in the intricate details of Active Directory Services and Domain Name Service (DNS). This will help ensure that the clients can map to the appropriate servers in order to get to their applications.

Test and validate
Be sure to set up a test domain and go through an entire upgrade/migration in microcosm. Testing should allow you to uncover problems before an actual deployment. You may want to fully test the backing out of a domain using active directory to see if your plan works as anticipated.
What would you recommend to an IT manager who is planning a migration to Windows 2000 servers? Post a comment below or send us a message.

Editor's Picks

Free Newsletters, In your Inbox