Tutorial: Deploying Windows 2000 -- Part Two

In the second of a two-part series, an experienced consultant explains how he plans for a Windows 2000 and Active Directory migration.

Last week, I reviewed the advantages of Windows 2000 over NT. I also discussed the objectives of a Windows 2000 migration, the tasks involved, how to set up your teams and how to sort out the big-picture issues such as number of forests and domains, the organizational units structure, naming conventions and the overall security strategy you should use.

Once you've made it through all those steps, you're ready for the detailed design.

The Devil's in the Details

The detailed design phase uses your high-level design conclusions and requirements to build the final design. In this phase, you study every aspect of the new infrastructure and the steps required to implement it in detail. The interaction between teams increases substantially, as each one requires input from the others.

For example, the Active Directory team will need to know the conclusions of the networking team in order to define the physical replication topology for the Active Directory. This team will also need to know the conclusions of the security team to identify the structure of the organizational units and their policies (group policy objects).

This means that while each team has a specific task to accomplish, the overall project structure and the communication established must be well defined, since the overall system will consist of interlacing components created by all team members.

Depending on the scope of the project, the design team could include up to 30 members working together to produce a document in excess of 300 pages. Therefore, as the project progresses, it's crucial that the project manager and chief architect provide the necessary communication and technical feedback to the team members. This isn't a challenge inherent in Windows 2000 projects. It is a challenge inherent in all large projects; Windows 2000 is no exception.

The detailed design phase also establishes the types of objects that you can create in the Active Directory by determining what's available by default in the Active Directory schema and how you can provision those objects. In some cases, you can design automation tools (or scripts) to integrate the Active Directory with other directories, such as IBM's Resource Access Control Facility, Novell Directory Services or Sun Microsystems Inc.'s iPlanet.

The Active Directory team also creates a site topology design, which considers the current network infrastructure, the number of users at various physical locations and potential future changes. This design defines the location and the number of servers required to keep the Active Directory consistent and will provide a fail-over scheme for when servers shut down. The team also defines the location of servers with roles such as "flexible single master operations," as well as bridgehead servers and their backup strategies.

The security team creates the model for delegation of administration, inheritance of permissions, default policies and all authentication aspects, such as a public-key infrastructure (PKI) or interrealm authentication with Kerberos. This team establishes the required trust relationships with down-level domains and other forests and creates shortcut trusts within the forest to speed up and optimize access traffic.

The networking team defines the Domain Name System (DNS) infrastructure and its integration with the Dynamic Host Configuration Protocol and Windows Internet Name Service. This team will define the networking needs and assess the current networking infrastructure. This isn't an exhaustive list; there are many other aspects of the infrastructure that this team will design.

The availability of a testing laboratory is essential. The laboratory is also a good way to transfer knowledge to the systems administrators by allowing them to test specific aspects of Windows 2000 and gain experience. The configuration of the laboratory should reflect the conclusions of the high-level design.

Depending on the scope of the project, planning the migration phase can be a challenge. The team must list and verify that each application running on Windows NT will run on Windows 2000. Microsoft has a lengthy list of applications supported. But in many cases, companies have thousands of applications and this task may become particularly long. Homegrown applications must go through lengthy tests before you migrate them.

Another challenge comes with the migration of Windows NT 4.0 domains. You should carefully plan the migration of each domain and include contingencies at every step. Test everything before implementation, including your fallback scenarios.

The biggest challenge in a migration is the coexistence between the old and new infrastructures. In the case of a parallel migration, where you create a pristine Windows 2000 forest, the additional servers and domains require additional administrative efforts. The typical duration of a migration is between one and two years, potentially more for the largest organizations.

To mitigate the risks, you should always implement a pilot first. This is a semiproduction environment where users volunteer to be the pioneers. As more users migrate, the pilot can become the production environment.

Learning From Experience

Those are the basics, but there's no substitute for experience. The following are some tips for success that come from my own experiences:

  • Understand and educate executive sponsors. Executives don't necessarily understand the challenge of a Windows 2000 migration. In many executive meetings, I have been asked by CIOs whether a migration is a mere upgrade that would require no more than two months to perform. I had to explain that IT must use a proper methodology and that the design phase shouldn't be underestimated. On the other hand, it's also important to understand the business goals for the new infrastructure to be able to create the best solution.
  • Take an enterprise approach. In many cases, particularly in an environment where administration is distributed across organizations, you may face a substantial political challenge to creating a single domain infrastructure. If your company doesn't adopt an enterprise approach, you'll end up with many forests with a higher cost of ownership, higher administrative and support costs, and reduced flexibility to adapt the infrastructure to organizational changes and disseminate applications and policies.
  • Surround yourself with knowledgeable people. Unless a company is very proactive, the IT staff managing the current infrastructure won't be skilled enough to design and implement a new Windows 2000 infrastructure. I have seen companies starting again from scratch after having spent months trying to fix what they had done. The help of professionals who have real experience in the field with Windows 2000 design is crucial to reduce the risks of a migration to a minimum.
  • Involve many groups in the design phase. A Windows 2000 design requires input from people who didn't necessarily work together in the past. For example, the networking team in charge of DNS will provide the foundation for the Active Directory in terms of namespace and name resolution. If a PKI must be designed, the security team will need to work with the Active Directory staff to allow the integration credentials in the Active Directory. Involving several teams will allow a truly common environment to evolve where services will combine to provide the necessary functionality despite the distributed architecture.
  • Master politics and conflicting requirements. Even with its benefits, a common infrastructure can create a political conflict that may slow down the decision cycle and ultimately hinder the system design. As several groups share a common environment, their needs may be in conflict with the needs of other groups. This at first may appear daunting, but understanding these needs and providing a design fit for all is possible.

    In many cases, it is simply a matter of communicating how the technology can be applied to the business requirements of these groups. For example, Active Directory has the ability to delegate administrative rights, which allow an organization to manage a collection of objects without having to worry about the complexity of the underlying technology, such as DNS and Active Directory replication. Hence, the infrastructure maintains the consistency of the objects it contains, and various organizations can simply retain the power of securely managing their objects. In other words, these organizations manage the objects logically, and an enterprise group of administrators manages the physical infrastructure.

    The enterprise administrators may not be allowed to manage the delegated tree of objects, and the various organizations may not be allowed to modify the infrastructure. This results in a secure environment where the stability of the infrastructure is maintained by a group of people with enterprise administration rights.
  • Understand what server consolidation means. Collapsing domains and consolidating servers is a nice idea, but once this is done, the implications of a problem are much higher. In the past, if a server providing access to 100 people went down, only those people were affected. But in a consolidated environment, if a server supports 5,000 people, the cost of downtime is much higher.

    You should consider disaster-tolerant systems implemented on both the server side, with clusters, and the storage side, with redundant storage-area networks and RAID configurations. Also, as your servers host a large number of users, backups and, more important, restores must be well tested.
  • Get your applications ready. Many companies have developed their own applications for a Windows NT environment. In many cases, these applications may not run in a Windows 2000 environment, resulting in an additional application development cycle. Attempting to certify applications will ensure that they are written in a way that will maintain the stability of the servers on which they run. This will reduce costs by keeping troubleshooting and support time to a minimum.
  • Decide on which technologies to implement. Many independent software providers are proposing tools to manage, secure, troubleshoot, migrate, monitor and back up the infrastructure, to name a few of the functions provided by software vendors. I highly recommend that you test these tools in a laboratory to assess whether they're effective. In many cases, several tools solve the same problem, so it's a good idea to evaluate them carefully.

Ready to Roll

The ability of a Windows 2000 implementation to adapt to the most demanding environments is directly related to the ability of its designers to understand the requirements in terms of drivers, politics and security needs. By applying a consistent methodology and understanding the complexity of the task, your company can create a Windows 2000-based foundation for future business needs while optimizing operating costs.

Micky Balladelli is a fellow at Avanade Inc. (Sophia Antipolis, France) focusing on Windows 2000 services. He is a speaker at various Microsoft- and Windows 2000-related conferences and has worked with multiple companies on the design of their Windows 2000 infrastructures. He can be reached at mickyb@avanade.com.

Have questions about this story or your Windows migration? Head to the Computerworld Windows 2000 Forum to discuss them with the author or your peers.

Copyright © 2001 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon