As more companies adopt Windows 2000 Server, many IT managers have found it hard to deploy, let alone plan, the migration. The reason: Windows 2000 isn't just the next version of Windows NT Server 4. It introduces many new standards that require knowledge that's new to NT 4 engineers. Standards like the Lightweight Directory Access Protocol, Dynamic Domain Name Server (DNS), IPSec, Quality of Service, public-key infrastructure and Kerberos authentication provide the gateway to the integration of Windows 2000 in a heterogeneous environment.
The availability of these standards in Windows 2000 opens many possibilities. But they also create problems. First, these features require specific knowledge that's difficult to acquire. Second, experienced professionals with the necessary skills and experience with large projects are hard to find. Therefore, the biggest challenge to a Windows 2000 project is to have the knowledge and skills in place in order to build the foundation for an effective implementation.
My focus in this two-part series is to show you as an IT professional how to plan for a successful deployment.
Why Windows 2000?
Windows 2000 offers many advantages over Windows NT 4.0, and many of these fall under reducing Windows' total cost of ownership. These include:
- Vertical scalability, meaning the ability to consolidate servers and reduce the number of Windows NT 4 domains.
- Horizontal scalability, or the ability to address the needs of the largest companies, unify replication requirements and provide a single repository to store enterprise information.
- Delegation of administration through Windows 2000's ability to accommodate a distributed management model.
- Integration of services through Windows 2000's extensible and programmable Active Directory service. The extensibility of Active Directory means you can integrate information provided by other directory services used in your organization.
Before attempting to start a Windows 2000 migration, however you must establish a proper methodology, create a proper project plan and form a project team.
A Quick Overview
Putting together a Windows 2000 project requires a thorough understanding of the big picture. Companies have different requirements, and it's crucial to understand the business drivers for your migration.
Some companies need a foundation to run their mission-critical applications. Without these applications, which require a time investment to understand, a company's business will be seriously affected. In my experience, the most common business drivers for using Windows 2000 are the following:
- Cost reduction, by using Windows 2000 and Active Directory to consolidate servers and domains to reduce operating, administration and troubleshooting costs.
- Application requirements: Windows 2000 is a necessary building block for Exchange 2000, which requires a full-blown Active Directory implementation to operate efficiently.
- Organizational change: Active Directory eases the management of organizational changes that can occur in a merger or restructuring. It provides an easier path to accommodate changes and lets administrators execute those changes in a shorter time than does Windows NT.
- Need for increased performance and stability: Windows 2000 protects its own operating system files and device drivers better and requires fewer administrative reboots.
- Innovation: Windows 2000 may be required to exploit the power of new hardware such as storage-area networks, four-node clustering and active-active clustering.
Once you've established the business requirements and project scope, you'll need to perform an assessment of the current environment. This step is essential. In this phase, you must assess which servers can be reused and which infrastructure building blocks must be redesigned. You'll pay special attention here to DNS, the Windows Internet Name Service (WINS), the servers, the clients and the applications.
Form the Teams
Once you have a general idea where you stand and what the future infrastructure should look like, it's time to put a team in place. Given the complexity of the task, you should divide the Windows 2000 project team into several subteams. These should include the following:
- Steering committee: the executive sponsors for the project (CIO, chief technology officer, IT directors).
- Project management team: responsible for the quality of and timeliness of the solution provided. This team ensures that the project is conveniently staffed and that there are good communication channels between the team members.
- Solutions architect team: This is usually a single member or a few people, depending on the size of the project, who are responsible for the technical accuracy of the implementation.
- Review board: responsible for the quality assurance of the project and validating the design. This team may consist of architects from other projects, consultants and company executives who want to influence the design phase.
- Active Directory team: in charge of the design of the Active Directory, from the content of the schema and its integration with other directory services to the definition of the namespace for the directory objects such as forests, domains, organizational units, replication topologies and so on.
- Networking team: responsible for the network services that will be used by the Active Directory: DNS, WINS, Dynamic Host Configuration Protocol, time services and Remote Access Services.
- Security team: affects all components of the project, from network elements to the users of the infrastructure. This team defines the policies, systems, network elements and users as well as the authentication requirements and confidentiality needs and how they are implemented.
- Migration team: looks at the migration strategy, tools and contingency plans during the migration phase.
- Basic platform team: defines the capacity planning and sizing of the servers and clients for the new infrastructure.
- Application deployment team: looks at application deployment for both clients and servers and provides different alternatives such as Routing Information Service, group policy objects, Short Messaging Services and third-party vendor solutions.
- Application migration team: identifies all applications that must be migrated; defines those that are already supported on Windows 2000 and those that require a development cycle that could spin off into new projects.
- Operations and management team: looks into the operational procedures currently in place. The Active Directory will affect these procedures, and one team goal is to identify which procedures to automate. The team will also examine disaster-recovery procedures, schema change procedures, and backup and restore procedures.
This project structure can accommodate a large number of companies, although in some cases additional teams may be required to address specific requirements such as a Lotus Notes, Novell Directory Services or Exchange 5.5 migration.
Getting the Big Picture
Once you've identified your project teams, you need to define the big picture. You do this through high-level design workshops. Each team leader must agree on the number of forests and domains, the organizational unit structure, naming conventions and the overall security strategy. It's also important to define the global namespace for Active Directory objects and the relationship with other namespaces such as DNS at this time. In fact, you should identify an overall DNS strategy as early as possible.
In many cases, companies wish to integrate the needs of Active Directory with their current DNS infrastructure. However, Active Directory requires Service Resource Records, which are only available in the most recent of the DNS implementations, such as BIND 8.
Logical vs. Physical Design
A high-level design consists of a logical and physical design phase. The former defines what can be created in the Active Directory and each object's structure in the namespace. The latter defines where the Active Directory servers are available and how they maintain replication consistency.
One approach is to use an iterative methodology, where once you select several logical models and identify their physical implications, you can start discarding some models in favor of a few that will be selected in the project's detailed design phase. As you identify several models, the team can assess the pros and cons of each and choose an ideal model.
You can use specific criteria to select logical models, such as business, geographical, political and physical (replication) considerations. The logical models provide a potential structure for your Active Directory structure. But it isn't possible to determine how effective they will be in the new infrastructure before analyzing their physical implementation.
In order to effectively examine the physical model of the Active Directory, you'll need information concerning the available bandwidth between the various physical locations and the amount of people working at those locations. As the big picture comes together, important aspects, such as the implementation of Exchange 2000, will drive the replication topology requirements for the Active Directory. Exchange 2000, for example, stores routing information and its Global Address List in the Active Directory, so each Exchange server requires a Global Catalog nearby.
Physical high-level design also includes placing specific servers and asking important questions about disaster recovery. For example, if a server unexpectedly shuts down, what would the implications be? Where would the users be redirected for authentication needs? In some cases, placing a second domain controller in a site can alleviate this risk and ensure the availability of the Active Directory if something were to happen to one of the servers.
Upgrade or Restructure?
Once you understand the current environment and your vision of the future infrastructure takes form, you can turn your attention to the steps required to implement Windows 2000. It's at this point that you define your migration strategy.
There are two main possibilities here:
- An in-place upgrade, which upgrades the existing environment without making physical changes.
- A restructuring, which involves creating a new parallel infrastructure and migrating everything into the new architecture.
That, in a nutshell, is the big picture. Next time, I'll talk about creating the detailed design for your migration project, whether you're restructuring or doing an in-place upgrade. I'll also share some practical advice that comes from my experiences as a consultant performing Windows 2000 migrations.
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 a Windows migration? Join the author in the Computerworld Windows 2000 Forum to discuss the issues.