Planning a Migration to Windows 2000
This chapter is from the book
This chapter is from the book
This chapter is from the book
Many computer professionals have described the migration to Windows 2000 as one of the most difficult migrations they have encountered in their careers. Depending on the scenario, the path to a completely native Windows 2000 network can be a long one, and it is fraught with myriad potential gotcha's. The reason for this may not be immediately obvious to the uninitiated. After all, they may reason, it is a Microsoft product, and we are already running Windows NT, so how hard can it be? But Windows 2000 is a nearly complete rewrite of its predecessor, and it is one that impacts nearly all aspects of the network. As we will see in this chapter, everything must be examined in excruciating detail. The planning approaches the magnitude of a Napoleonic campaign. The cost can be considerable, so companies must approach the migration event with a sense of foreboding, respect, and anticipation.
Relationship of Namespace
As you are designing the namespace, keep in mind the relationship to other (non-MS) DNS systems that may already be in operation on the network. Think of the tree/namespace design from all angles: admin, user, scaling, replication/network impacts, performance, policies. The namespace design is extremely important, and will provide the framework for your entire enterprise. It must be correct.
Namespace design
The namespace is like the skeleton of an apatosaurus: It controls the outcome.
As you are trying to design the global catalog, take a look at the existing Exchange deployment; it is a good indicator of how the company thinks about directory issues. In addition, it can provide a pointer to how the namespace can be designed. In all cases, design and implement both the namespace and the directory before deploying client machines. This will keep you from having to play catchup on the desktop later in the game. Your goal is to touch the workstations only once and avoid the trap, so common in poorly planned deployments, of making repeated trips to the desktop machines. Not only does it annoy users to be uprooted from their computers, it sends a bad message to management. Sooner or later the question is going to come up, "Why didn't you do that the last time you were at my machine?" The only exception to this is the case of smaller organizations—those with fewer than 1,000 machines. For these smaller networks, the desktop machines can more easily be deployed first. This will allow the company to reap the benefits more readily from the more stable Windows 2000 professional client platform.
Five Key Steps in Design
There are five key steps in the design of a Windows 2000 migration that will greatly influence the success of the project. The completion of each of these steps results in a document that describes a particular portion of the process.
- Forest plan document
- Domain plan
- OU plan
- Site topology plan
- DNS plan
First Domain on Site
In this section we will look at considerations involving the first domain in a site.
forest/domain/sites/ou/
The forest is the largest area in Windows 2000 enterprises. When you bring up the first Windows 2000 domain controller on your network, you automatically have a forest. You also have a domain, and you have a site. All this resides on a single box, and it was all created at the same time. The important thing to remember is that there is but one schema for one forest. If you need to have multiple schemas, then you will need multiple forests. In addition, you need to agree on a schema change policy at the outset. Who owns the schema in the enterprise? Due to the importance of the schema (you can hose the entire enterprise with a single click of the mouse—the mouse that roared), most companies have a dedicated person in charge of the schema.
Inside the forest we also have a domain tree. It is a boundary within the forest; the domain is a boundary for AD. All objects and attributes live inside the domain. Within the domain you can have sites. You can put policy on the domain, site, or OU.
A site is a well-connected network. Typically, a site is a physical location that has one or more subnets associated with it. Sites are used primarily to control replication. A well connected network is usually defined as LAN speeds, but is commonly extended to include T-1 speeds as well. The definition of well connected is, of course, user defined, and has been expanded in some instances down as far as 128K (dual band ISDN).
An OU is a feature of Windows 2000 management that allows the grouping of related resources or users to simplify the application of policies and security settings. There are several methods by which OUs can be structured. For instance, some organizations will use OUs to group users and resources according to geography. Other companies, however, may decide to use OUs to group their users according to functionality, i.e., accounting, engineering, maintenance, information services, purchasing, and the like.
Single forest–single schema
If more than one schema is needed, then it is a multiple forest design.
Trust plan
What are the costs of additional forests? For one thing, it requires more hardware, additional servers, and maybe more networking equipment. One of the qualifying questions: What groups have the business authority to override and make changes in schema?
Domain planning
A domain is a partition of the forest. It is a physical partition, a portion of the forest namespace. In addition, a domain is a logical partition. As such, it forms an administrative boundary. The domain is used as a policy boundary, and provides a unit of authentication. As you are doing your domain planning for a migration to Windows 2000, start by considering a single domain. Remember, there are compelling reasons for staying with a single domain design, and it can accommodate really large networks. Ease of administration and reduction of equipment costs are two really strong arguments in favor of a single domain forest.
If you start with a single domain design, then make sure you justify additional domains as (or if) they are incorporated into the domain plan. Some reasons to add additional domains to the domain plan:
- Upgrade existing domains in place
- Logical partitioning: Admin/policy
- Physical partitioning: Optimize replication
So we can see, there are valid reasons that exist for adding additional domains to our namespace. There are also obsolete reasons you need to be aware of. These may have been valid in the NT 4 days; however, they no longer exist as valid reasons for additional domains in the Windows 2000 world because of:
Recommended 40K object SAM size: AD scales to millions of objects.
PDC availability requirements: AD is multimaster.
Delegation of admin (resource domains): Delegate within domain using OUs.
OUs allow granularity; an OU is a container within a domain and, as such, it can be nested. An OU, however, is not a security principal. OUs are used to delegate administration, and are used to apply group policy. The OU hierarchy may or may not reflect business hierarchy; it maps to business rules instead. Users will not navigate the OU hierarchy; in fact, most users will never even be aware of the OUs, nor do they use the OUs to find network resources. Administrators use OUs to facilitate security and user administration. OU depth does not impact performance: On the contrary, network performance is more affected by group policy. However, names should make sense to the administrators, and are best if kept short (makes certain Lightweight Directory Access Protocol (LDAP) tools easier to use).
Site topology
Site topology is a logical representation of the physical network infrastructure. As we develop our site topology, sites are connected by links. Within Windows 2000, sites are used to route query and replication traffic efficiently.
A site is a set of networks with fast, reliable connectivity. Essentially, it is a collection of subnets. A site link is a network that connects two or more sites that may have low effective bandwidth or intermittently available (demand dial) bandwidth. In many instances, these links are characterized by low reliability.
DNS planning
DNS planning is the most difficult and political area of a Windows 2000 AD migration for large organizations. It is a paradigm shift. Many companies are still stuck in a combination of current DNS and WINS support models. Keep in mind that many versions of Unix BIND do not support SRV resource records. Of the ones that do, however, SRV support must be specified at compile time.
In Windows 2000, DNS is the preferred name system and is the DC locator. The DNS server in use on a Windows 2000 network must support SRV records or things simply will not work. In addition DNS should support dynamic update for proper AD support. Windows 2000 DNS server (of course) provides all the necessary support for AD.
Distributed security planning
Do not let planning for the implementation of distributed security delay your migration. Part of the problem can simply be unfamiliarity with distributed security on the part of the implementation team. There is a tendency to delay the migration, or to slow planning, until all participates come up to speed on distributed security. This is not required: PKI can be implemented at any time; Kerberos with Unix interoperability can be rolled out at any time; EFS can be turned off for the domain and deployed later; IPsec or L2TP/IPsec is not required. In most deployments, these items are held for Phase II. Unless there is a compelling business reason, there are enough things to worry about in a Windows 2000 migration without the increased complexity of deploying distributed security systems.
Production rollout planning
In the deployment phase, most large customers will implement their AD structure first to get the biggest bang for the bucks. Smaller customers can deploy clients first and then upgrade the network infrastructure and member servers. For smaller networks, the deployment of AD seems to be the last step in the migration.
Remember, domains cannot be renamed and the domain hierarchy cannot be restructured. Domains cannot be merged or split after they are in place on your Windows 2000 network. If you have to reorganize you will be limited to moving objects. You will be able to do a bulk import and export operation via ldifde.exe. In addition, you can use movetree for intra-forest moves. However, at best it will be rip and replace procedure. In many aspects it will seem like another migration. The moral of the story is in order to avoid all this pain, do the domain planning well up front, and strongly resist any temptation to restructure domains after they are deployed.
Decide in advance how you will break down system administration responsibilities for your network, and even for a specific application. This planning can influence the organization of your OUs. Identify early who will be given administrative permissions. Remember that in Windows 2000 we can become very granular in assigning certain administrative permissions. It is a best practice to severely curtail membership in the administrative groups. Determine what policies are going to be enforced on a user's system; this will have a direct impact on how group policy is applied. Make sure you identify an education and training plan as well.