This chapter is from the book
This chapter is from the book
This chapter is from the book
Domain Design Considerations
In this section we look at some principles of domain design.
AD Designs
Put users into a user's OU, and then you can assign them group policy. Maybe do users, machines, and printers and assign group policy.
For remote branch offices, maybe create a branch office domain, and then you can isolate them from a lot of the replication traffic.
May very well need country domains due to differences in laws and stuff.
With your OUs, follow your support structure. Can just move containers around, and do not have to re-ACL, and not redo a lot.
Can rename, reorganize.
All divisions have no more than 3–5 OUs in depth.
If the division is sold, then you can use scripts.
The OU structure follows the support structure (still keeping shallow, but deep enough that you will be grouping accounts instead of having a flat user list).
The delegation is used at OU, and ACLs and security groups handle exceptions.
OU-users: Change sales password group—allow
User—manager: Change sales password—denied
User—manager: Change manager password—allow
Windows 2000 can support 23 languages, and 128 dialects out of the box. It can also name the machine in local languages, Kanji or simple Chinese. Windows 2000 DNS supports Unicode-based characters. It all inserts into the directory.
What is the support structure? Does it support Japanese? Make sure support staff will be able to find the machine, and the OU. On these, servers can ship international English, and install all the language packs, and then the display will appear in English when the support remotes into the machine. You can also install the MUI pack, which allows you to change the tool bars of the operating system. It will also change the help files into the local language. You can use international English when remoting in to a server in France, but the local machine is in French. France will not buy an English application (particularly if it is government).
If you purchase international English, and add the multilanguage user interface (mui), is one service pack. But if you purchase a localized language, then it is a different service pack.
Deployment considerations
Number of domains
Domain controllers and GC placement
Amount of data to replicate
Language
Encryption laws
Telecommunication designs
Any political issues
Review current and future support structure, company, divisions, and departments (help desk, data access, etc.)
Review international requirements
Review current and future telecommunications designs for WAN support
Best design includes helpdesk, Human Resources, and security in same room. HR should know the international considerations
International considerations
You cannot just do one domain if international. If there are 300 to 600 sites, Windows 2000 has problems with the KCC: One is for intra, and one is for inter. KCC is responsible for when and how to do this. On inter, it will go out and look at the container, go and see size of the pipe, and dynamically build a replication cycle. If you change phone numbers, or a backup link comes up, then it will change dynamically. The replication cycle is 15 minutes by default. If it has to talk to 300 servers or so, it will have trouble talking to all 300 in 15 minutes. It uses default 445 new SMB interface; the same type of thing is used to determine a slow link from the desktop. There are no special protocols to monitor. It can use intra KCC alone, and uncheck the automatic inter KCC. Then build the site connector from remote sites, and assign costs to it. It can manually load balance, and provide alternates. But you do not want the alternate to be the same for all. There are some vbscripts you can use.
Using a Single Domain
There are several good reasons to choose a single domain when planning our Windows 2000 migration strategy. These include:
- Flexibility
- Easier delegation
- Ease of management
- Fewer domain admins
- Object capacity is the same as multiple domains
- Less planning
AD is very flexible, much more so than the NT 4 domain structure. One of the elements that contributes greatly to this flexibility is the OU. An OU is really nothing more than a container within AD that allows us to organize elements such as users, groups, and computers. We can, by using OUs, divide our organization into a combination of departments and geography. There is really no right answer to the organization question in Windows 2000. The path we choose is solely dependent upon administration needs, and political considerations. Perhaps one of the more common implementations is to divide things up along departmental and geographical lines (see Figure 2–1).
)
Figure 2-1 By using OUs, we can divide our company into a combination of departments and geography.
If our departmental structure or geographical organization changes in the future, then it is really easy to move objects from one OU to another. If, for instance, our company decides to consolidate its sales efforts, then we simply move the sales OUs from their geographical counterparts in Figure 2–1 to a new sales OU that we created in AD (see Figure 2–2).
)
Figure 2-2 If our company restructures, then it is very easy to move objects around in AD. In this diagram, we consolidated all our sales efforts into a single OU.
If we have a user or group of users that move from one location in the world to another location—for instance, our company decides to close down a regional office and transfer everyone to a new centralized office—then all IS needs to do is to select the users, right click on them and select move from the action menu (see Figure 2–3). If, however, the users were in a different domain, then we would have to go through a domain restructuring (read domain migration) in order to save the accounts and associated ACLs. This is a much more complicated scenario, and a very good reason for developing a single domain model in Windows 2000. Even with domain migration, we are much more able to handle this scenario than we were in the NT world. So our goal in designing a Windows 2000 network is to create an infrastructure that is very flexible, one that will both grow and morph with the dynamic environment of today's business needs.
)
Figure 2-3 In order to move users from one OU to another, we simply right
click on the users affected, and select move from the action menu.
Ease of delegation
In a single domain model, we can easily delegate control to the various OUs in a very granular fashion. We can also limit the membership of the domain admins group. Since domain admins can take control of every object in the domain, and have greatly enhanced power in the domain, we want to control tightly who is a member of that group. By using the OUs, we can delegate control down to the lowest level in our organizational structure. One no longer needs to be a domain admin to be able to create users, and assign permissions. We will delegate administrative control to the down level groups so that we have a decentralized environment. Of course, delegation of control can occur at any level in the AD hierarchy—domain, site, OU, object, and object attribute level—but it is generally a best practice to delegate at the OU level.
Ease of Management
From a management perspective, a single domain is a lot easier to control. There is only one strategy to plan for administration, security, and support. With a single domain, all of these functions only have to be done once. This can save you a ton of time, as much of the time for a Windows 2000 migration is spent on the planning side of things. If you have multiple domains, then you have to create administration, security, and support plans for each domain. This can translate into a very complex and unwieldy scenario. It is very important to question critically for multiple domains, as there are huge benefits in fitting into a single domain strategy. There is less hardware to purchase (fewer domain controllers); this will lower licensing costs, and means less downtime and fewer upgrades. Each domain will require at least two domain controllers, which translates into more down time for upgrades, service packs, and those kinds of things. It is true that when compared to multiple domains, you will more than likely have bigger machines for single domains; there will be less labor involved in maintaining fewer servers. There are no trusts to maintain, as it is a single domain. I ran into one client that had a full time administrator whose main function in life was to maintain trusts among their highly distributed NT 4 domain—talk about an exciting job! In a Windows 2000 environment, that administrator will get to do something else.
There are fewer numbers of domain admin groups in a single domain model than in a multiple domain model. This means there are fewer domain admin groups to monitor and to keep an eye on. In general, you want to place a very select number of individuals into the domain admin group, and then all the other network administrative types are delegated authority at either the site or the OU level of the hierarchy.
The directory information tree can hold four billion objects. It does not matter if it is single domain, or multiple domain; a forest can only hold four billion objects. For the global view of all these objects, we look at the global catalog server. It holds a copy of all the objects in the forest, and a subset of the attributes. So what we are concerned about is the size of the global catalog server, which is a function of the size of the forest as a whole—not the number of domains, or the number of trees we have in the forest. So if we have more than four billion objects then we will have to have more than one forest. However, it is highly unlikely that a company would reach the four-billion-object limitation.
Less planning
In a single domain hierarchy, you still have to do a lot of planning, but it is only done once. This translates into the following advantages:
- Simplified namespace planning
- Simplified DNS design
- Simplified forest design
- One delegation of administration plan
- One group policy plan
- One security policy plan
- One OU hierarchy plan
- Simplified maintenance and support plan
Using Multiple Domains
Since we have spent the last few pages harpooning the multidomain model for your forest design, let us now look at some of the reasons you might want to implement multiple domains in your forest. Remember, when designing for multiple domains, there is a very real cost associated with each additional domain. These costs come in the form of money for server hardware and software, management overhead, and increased risk due to complexity. So what we are looking for in the design phase are compelling reasons—justifiable business reasons—such as cost justification and administrative requirements. There may be legal reasons that require multiple domains, while in other situations, there may be a simple management inclination due to a lack of understanding of how security in Windows 2000 actually works.
There is a need to shift the paradigm from the way things worked in NT 4. Then we needed to create divisional domains in order to restrict administrative control, or to delegate control. In addition, if we had a decentralized administrative model, it required multiple domains. If we wanted to ensure the availability of PDCs due to a distributed environment and slow WAN links we also needed multiple domains. If the link was unreliable, we would create separate domains, to make sure the domain was available for our users to be able to change passwords, or for administrators to update access to resources. In Windows 2000 with AD, any domain controller can accept password changes; we are much more reliable across slow WAN links. In NT 4 there were size limitations of around 40,000 objects in the SAM database. In Windows 2000 we can have 4 billion objects in AD so there are not the same size limitations we had in the old days. For some large international organizations, language was a problem in NT 4. We did not have multilingual versions available. In order for administrators to work with a Japanese version of NT, it had to be in a different domain. With Windows 2000 we have multilingual versions. So Japanese administrators can make changes to AD in their native language, and US administrators can do the same. Since these changes are stored in Unicode, the underlying support is the same.
When add domains are due to political reasons, you have a very real problem. These domains are the ones most likely to change, as the politics are constantly shifting. Companies get bought out, or there are mergers, departmental lines fluctuate; all of these conditions combine to create a mess. Often, when politics come into play, you are not dealing with the right people. Political considerations are the most expensive, as they are unnecessary, and do not add value to the overall Windows 2000 design. Combine this with the fact that these are also the areas most likely to change; it behooves the designer to attempt to find ways around these often-inane considerations. If someone simply wants control of users, hardware, or security, then the Windows 2000 AD design can accommodate those concerns without incurring the added expense of additional domains.
Domain administrators can take ownership of any object in their domain; they can take control of resources. It is not a good idea to create a separate domain to restrict access to objects because I can take that ability away by removing their right to take ownership of AD objects. This is not a valid reason for creating additional domains. We can control who can take ownership of AD objects and resources.
Then what are some of the real reasons for creating additional domains? For one thing, if we want to create distinct domain level policies, we will need an additional domain. For instance, if we want to have a domain level policy with different password lengths, expiration dates, account lockout, account lockout length, and user ticket lifetime, then we will need additional domains. This is a carryover from NT 4. These kinds of things are still with us. For instance, if you want the most users to have a rather lax password policy, and you have a division that requires higher security (perhaps the engineering, or research and development, departments) then you will need to create an additional domain for them. Account policies cannot be applied through group policy; they are specified at the domain level. In order to have separate account policies, you must create additional domains. Do not be confused by this: You can set account policies at the OU level, but nothing happens.
There may be compelling business needs. For instance, there may be legal restrictions that need to be implemented through different domains. These may be banks, financial intuitions, military organizations, and the like. You can provide legal boundaries and security boundaries by implementing multiple domains. There may be requirements to maintain multiple namespaces.
A dedicated root
The dedicated root is the first domain in the forest. It is empty. There is nothing in it except for the domain controller objects that you place there, the default group and user accounts, an operations master or two, a couple of DNS servers, the global catalogue server, and the forest-wide administrative groups. Forest-wide administrative groups are enterprise-wide admins and schema admins. These two groups have forest-wide administrative power. These are very powerful, and so you want to make sure the wrong people do not get put into them. Members of the domain admins in the forest root define the membership of enterprise admins and schema admins. A domain admin in the forest root can determine who controls the forest. While this may seem a little scary, the solution is actually very simple. You set up an empty root to the forest. It's the first domain you create in the forest. One benefit of this is it never becomes obsolete. In Windows 2000 you cannot rename domains without uninstalling and re-doing everything because you lose all of your objects. So this solution is actually pretty elegant. There is a lot of complexity surrounding this. It is very important to make sure that whatever domains you do define are well thought out, and designed in such a way so they do not become obsolete. A dedicated root, because there is nothing really in it, is simply a placeholder; therefore, it does not become obsolete.
Use of Additional Domains
Another reason for creating additional domains is to optimize replication. Inside our domain, we are replicating all objects and their associated attributes to all domain controllers in the domain. If the domain spans a wide area network that is connected with slow, unreliable links then it could cause problems. Simple directory replication could bring the link to a crawl, and prohibit users from accessing a critical line of business applications. Between two domains, however, replication is a lot different. The only things that are replicated are changes to the global catalog, changes made to the configuration container, and changes made to the schema. There will be few changes made to the schema and to the configuration container. The only reason the schema would change would be if you installed a schema aware application (such as Exchange 2000). The configuration container should stabilize once the forest is installed and all the domains are set up. So, most of the traffic would be global catalog traffic. Therefore, you could just create sites, instead of multiple domains.
There are some limitations. For instance, while sites allow you to schedule when replication occurs, doing this does not modify the number of changes that must be replicated. We must use domains to control the amount of traffic that is replicated. If we simply need to control when replication occurs, then we can use sites to make sure that replication does not occur during times of peak link utilization. Of course, the down side to this is currency. By delaying our replication traffic, we can cause users to have out of date information. Just because we have slow links does not mean that we have to have multiple domains. In order to make an intelligent decision about this, we have to look at both reliability of the link and net available bandwidth—not just bandwidth, but how much bandwidth is available at the time we need to do replication. It is entirely possible that by scheduling replication between sites at a time when the link is underutilized, we can avoid creating an additional domain. We can use the AD Sizer to assist us in making these calculations. We can also use REPLMON.EXE to work with replication.
Another reason for using multiple domains is for separation or control of affiliate relationships with other companies, such as might arise out of a joint venture. This provides users in other companies with access to internal resources in a cohesive and secure manner. Of course, we could achieve about the same thing by creating a separate OU and then delegating administrative control to it. However, for internal business reasons, we may wish to create a separate domain to allow for greater isolation and administration. If the company has the money to spend on a couple of extra servers, then this is a very acceptable solution. It allows us to isolate administration and provide security (see Figure 2–4).
)
Figure 2-4 Use separate domains to provide for control of relationships
with other companies.
If we want to restrict administrative control in a high security environment, then we may also wish to consider an additional domain. When it comes to file resources, file shares, and NTFS permissions that have been assigned—we cannot take these away from domain admins. AD permissions are different than NTFS permissions. NTFS permissions are stored in the file system, and cannot be controlled through AD: They are two separate things. So, if we have really confidential information, and the company is really concerned about controlling access and protecting from domain admins, then it may make sense to create a separate domain. Of course, we need to say, "It depends." There is no single right answer.
Let's look at the cost of adding additional domains. There are more domain admin groups that need to be monitored. There is more hardware that must be purchased, there are more trusts to manage, and there is the increased chance that objects will have to be moved. Moving accounts and resources around in multiple domains takes a lot of planning, and there is a greater chance of impact end users. Remember, end users are the reason for providing network resources in the first place. Group policy cannot flow across domains, nor can I make delegation flow across domains; therefore, access control management is more complicated and more labor intensive. There is a greater chance of errors when you increase the complexity of administration. In addition, the DNS infrastructure will need to be more complex as well.
There are some restrictions that we need to be aware of in considering to add additional domains:
- Cannot rename the domain.
- Cannot create a parent to an existing domain.
- Cannot remove a domain that has children.
- Cannot easily merge or split domains.
One huge potential problem is that rogue departments could begin their own implementation of Windows 2000, and not take into account the complexity of the product. Then all of a sudden, users cannot get to their data, computers cannot resolve names, and servers start going down. One way to get around this is to create a new domain, give it the correct name, and then move those accounts over to it.
When you create a new domain, and it is the first domain in the forest, then it becomes the root of the forest. You cannot create another domain above it: It is the root. By the same token, even if you go down the tree, to any level in the organization, you cannot create a parent to an existing domain. This highlights the need for well thought out planning, and the need to have a drawing or a diagram of the desired end result. It must take into account existing needs and future expansion plans. This is one migration that the IT department probably will not be able to complete entirely on its own. Upper management must be brought into the planning process.
Structuring the domain
In view of the restrictions that were listed in the previous section, it is incumbent upon us to make sure we plan the structure of our domain in advance. To this end, we will look at several items that we need to take into account during this process: creating an OU hierarchy, creating OUs to facilitate delegation, group policy considerations, and combining delegation and group policy.
OUs can be nested; this allows us to create a hierarchy. Then we can apply group policy and allow it to flow completely through the hierarchy, or we can apply group policy at every level in the nested structure.
OUs, however, are not security principles. This means that they cannot be directly assigned permission. Security principles in Windows 2000 are users, computers, or groups, but not OUs.
Users will not navigate the OU structure. There are two ways the users will actually see the OU structure. One is if they go into my network places and get to the directory icon. There is really no reason for end users to go to this trouble if AD is properly implemented. It is much better for a company to hide this icon from the users, as they do not need to be confused by it; there are better ways for them to gain access to resources.
The other way users would see the OU structure would be if they actually installed the administrator tools. However, if security were properly implemented, the end user would not be allowed to use these tools on the network. End users do not come into the picture when the OU structure is created. OUs are for delegation, grouping objects, and group policy administration—it is for network administrators, not for end users. Administrators are the ones we worry about when creating the OU hierarchy. End users will be taken care of through many of the new tools and features we will make available to them; the OU is not one of them.
Creating OUs for delegation involves several areas of attention:
- Change container properties.
- Create, change, or delete objects.
- Update object attributes.
- Create new users or groups.
- Manage an object class or an object class attribute.
Delegation can be applied at the site, the domain, or the OU level. You can allow a user to create user objects only in the OU. They do not have to have the ability to modify the user attributes, only to create. When devising the delegation scheme, break it into small pieces. There are different strategies we can use for this. We can create task-based administrators to reset passwords or to manage printer queues. There can also be object-based administrators. These admins may have control over a specific OU. Grant the ability to reset a password at the highest level of the OU. This keeps you from having to dive into multiple levels for troubleshooting. Create OUs to support administrative needs or models. OUs can be based on location, department, or resources. This makes delegation easier, and makes group policy easier to implement. Centralize first level OU support. Grant administrative control at the OU level. Security, if you are delegating at the OU level, then all the objects at the OU will inherit. Document how security is applied. This can be very complicated when there are 14 different group policies, share level permissions, and NTFS permissions.
Design Walkthrough
In this section we will walkthrough the development of a design.
Server hardware evaluation
One of the first steps that must be completed before actual deployment is a physical hardware evaluation. Proper planning at this level can pay great dividends in helping to ensure a successful migration. This comes into play in several arenas. For instance, it can help you to make sure your project comes in on budget. You do not want to be in the middle of your deployment and realize you do not have enough RAM in your servers. This would cause you to stop deployment, run out to the store, and buy a few hundred GB for your 50 servers. In addition to putting your project several thousand dollars over budget, you can also put yourself behind schedule if the store does not happen to have several hundred GB of RAM lying around (with my luck, it would be backordered). Here are a few things you want to pay attention to when doing the physical hardware evaluation:
- Is the server on the Hardware Compatibility List for Windows 2000?
- Does the server have enough RAM?
- Does the server have enough free disk space?
- Does the server have a powerful enough CPU?
- Does the server have a good network interface card?
In addition to these questions, you will want to pay attention to the physical location of the servers, the users that are defined on the machines, the current role the machines play in the network, and the IP addressing scheme.
Networking environmental evaluation
You need to look at the following items:
- Network infrastructure
- DNS infrastructure
- File, print, and Web server services
- Line of business applications
- Security
- Information store
- Hardware and software
Physical Network Topology
In order to design our new Windows 2000 network, we must have a physical topology map of our existing network. A physical network topology map will include the following information:
- Site names
- Bandwidth of the connectors between sites
- Number of users at each site
- Backup links
- Type of connector
The network topology map will be crucial for us when we design replication. It is also useful when designing the forest structure, group policy, and domain structure. It is important that this document is a high level overview. We do not want to mask the layout of our network with too much detail. This is not a troubleshooting document, it is a planning document. An example of a good network topology map is shown in Figure 2–5.
)
Figure 2-5 A good physical network topology map details site locations,
bandwidth of connectors, and users in each location. This crucial planning
document must be completed prior to the Windows 2000 design phase.
Current Domain Map
Another map that must be completed prior to the Windows 2000 design phase is a map of the existing NT domain structure. This will include the following types of information:
- Each of the domains that exist in your organization
- The number of trust relationships that are in place
- The direction of the trust relationships
- The number of domain controllers in each domain
- The location of the existing domain controllers
- The people that are administrators in each domain
More than likely, if your company is large you will be doing some type of domain restructuring as you move to Windows 2000. How you will carry this out is a subject for consideration later in this book. At this point, you really need a map that is like the one in Figure 2–6. If you have a very complicated domain structure, then you will probably want to flatten out your design for Windows 2000 to enable you to take advantage of some potential cost savings. Of course, these cost savings come with a price tag: The migration is going to take longer, especially in the planning stages. But the savings will be real, and the resulting ease of troubleshooting and administration will pay great dividends.
)
Figure 2-6 A map of your existing domain structure will help you evaluate
what your domain migration strategy will be.
Evaluating the logical structure
One item that is often overlooked in preparing for a Windows 2000 deployment is the logical structure. This includes items like the users' environment and the placement of trained network administrators. It is possible that some remote locations that had part-time administrators will no longer need to be administrators. For instance, you may have a resource domain that had a part-time administrator that was responsible for password assigning security to shares. In a Windows 2000 environment, you may want to make that resource domain an OU and you may want to administer it remotely. In addition, with the implementation of administrative terminal services, you can perform a lot of administrative tasks remotely. This frees up the part-time administrators to perform their normal duties (instead of monkeying around with the server). In addition to freeing up personnel resources, you have also heightened security on the network by removing someone from the administrators group. Some of the things we need to track:
- User profiles
- Desktop configuration
- Applications and storage of application data
- Administrator locations
- Administrator skill set
- Administrator assignments
Looking at the company organization
We can follow the company organization chart as a guideline to help us create the OU structure for our Windows 2000 design. We do not want to create domains based on this structure, as it will change too often. It is very difficult to move and manage multiple domains; however, it is very easy to move and manage multiple OUs. It is also possible that based upon the organization chart review, some companies may revise their structure.
Putting together a design team
A design team will have the following types of people:
Management sponsor: Someone with single signature authority. Someone to talk to upper management to gain support for the project.
Project manager: Someone to guide the project and to watch the timeline.
Technology groups: DNS, administrators
Project leads
Windows 2000 proponents: People that are convinced of the value of Windows 2000.
Business Justification
Set specific milestones. Do not try to tackle the entire project at one time. There are just too many options to deploy, and too much planning involved. Instead, as you plan the deployment, focus on a specific problem. The specific problem to solve should be something that will improve the business flow, and something that you can guarantee success with. Nowadays, most businesses are looking to the IT department to provide an ROI. In addition, they are looking at real savings, not just fuzzy intangibles. We must be able to define the business reasons for making the switch to Windows 2000.
Restrict the scope of the project
In order to help assure the success of the project, it is important to define what will not be addressed in the initial phase of the migration. Are there parts of the company that will not be migrated? Are there projects that will not be tackled? Are there applications that are reaching the end of their useful life and therefore will not be upgraded?
Develop the logical design
Once you have completed the evaluation of your existing infrastructure, the next step is to define the logical design. In this step, we will be utilizing all of the information gathered from our evaluation. Steps involved in deriving the logical design:
Namespace design: There are several critical decisions that need to be made about the namespace: naming issues, single or multiple forests, domain trees, and OUs.
FSMO planning and placement
GC placement (authentication and replication issues)
Group policy: Aspects of group policy to deploy; applications, security, and the effects of namespace on the group policy design
Security: The use of built-in and custom groups; the application of public key infrastructure and certificates
One way to derive the logical design for your Windows 2000 network is to create a placeholder domain at the top that contains administrator accounts (enterprise administrators, domain administrators, and the like). Below that, you have geographical based child domains (see Figure 2–7).
)
Figure 2-7 By creating a placeholder domain at the top, and organizing the
logical domain into geographical child domains, you can vastly simplify the
structure and facilitate application of group policy.
Inside the child domains, you then create your OU structure. Split out the user accounts and the computer accounts to reduce the number of group policies you need to create. Under each, you can create OUs based upon either function or location (see Figure 2–8).
)
Figure 2-8 By creating OUs for both users and computers, you can reduce
the number of group policies you need to create for your organization. This will
simplify troubleshooting later on.
Physical Design
After the logical design has been created, the next step is to define the physical design of the new network. Items that must be considered at this stage of the game:
- Physical network equipment upgrades
- WINS
- DNS
- DHCP
- RAS
- IPSEC
One way an organization may want to deploy the infrastructure services is to place the WINS and DHCP servers into a centralized network location (see Figure 2–9).
)
Figure 2-9 By centralizing WINS and DHCP servers, a company can reduce
hardware costs and simplify infrastructure administration.
Due to its importance to the performance and reliability of Windows 2000, DNS needs special consideration. Many companies already have a DNS infrastructure in place. In most instances, this will be on Unix boxes running some version of BIND. It is easiest to migrate the existing DNS infrastructure to the new Windows 2000 network. However, in most instances this simply will not fly. For one thing, most NT administrators do not understand DNS well, and DNS is too important to get messed up while the NT admin team comes up to speed on this crucial technology. For another thing, there is the attitude that if something is not broken—don't try to fix it. In addition, there are the internal politics to consider (e.g., I do not want to be holding the bag if something goes wrong). So, perhaps it is best to allow the Unix team to keep DNS, and we simply work around it. This is, in fact, what I have been doing with the majority of my medium and enterprise level clients. So how do we work around it? The solution is amazingly simple. Figure 2–10 illustrates one approach to the problem. We delegate the ownership of the crucial AD zones: _TCP, _UDP, _sites, and _msdcs. We turn these into AD integrated zones with dynamic updates.
)
Figure 2-10 By delegating ownership of the four crucial AD zones, we can
easily coexist with a Unix BIND DNS server.
Replication design
In Windows 2000 you need to design the network topology to reflect the actual physical topology. There are site structure limitations you will need to be aware of, as well as domain structure limitations. Once these are factored in, you will need to examine the scheduling of replication to account for network traffic and bandwidth.
There are at least seven different replication topologies you could come up with, each of which may be more or less applicable to your particular physical network design. Most of my clients use either the hub and spoke topology or a variation of the hub and spoke design. The hub and spoke replication topology is illustrated in Figure 2–11. In the hub and spoke design, you have a core site where the majority of the domain controllers are located. Remote sites connect via WAN links to the core site in order to perform replication. The basic premise is that the remote WAN sites have good connectivity to the "core site" that enables replication to occur. In addition, it is important to realize that Exchange 2000 will cause a need for additional global catalog servers.
)
Figure 2-11 The hub and spoke replication topology works well for a wide variety of network designs.
There is a practical limitation of around 300 sites in Windows 2000 that is due in part to the amount of time it takes the knowledge consistency checker (KCC) to generate the replication topology. What happens is there is a processor spike in the ISMSRV and the LSASS processes that will eat up all the CPU time while the KCC is running. If there are more than 300 sites, then it is possible the KCC could never finish. It is possible to mitigate this effect by utilizing multiple processor domain controllers (a good idea anyway.)
There is a concept of a virtual site that can work around the site limitation. In this concept, you combine well-connected physical locations into a single logical site. Then from the logical site, you connect one domain controller back to the core site location. The well-connected domain controllers are then able to replicate to the other remote physical locations and reduce the KCC load. The important point is to realize that a site does not have to be a physical location. In much of the literature a site is defined as a location with good connectivity. We can play with this concept, create our own definition of a site, and then reduce the replication load on our remote links. A site can be a region, a campus, or a group of buildings. Sites do not need to be physically next to one another. With the virtual site concept, we are taking several remote locations, creating an ad hoc grouping, and calling it a site.
Additional considerations
Make sure you obtain updates for tools: backup software, antivirus software
Design your time services: ws32time
File and print services: folder redirection, published shares in AD, published printers in AD, and maintaining availability during the migration
Sample plan
Build a small pilot and grow to the corporate infrastructure. You can do this in a permanent fashion, so that as pilot users are migrated, you are chipping away at the whole. As an alternative to the permanent pilot you can build a disposable pilot where the machines are rebuilt after the pilot phase is complete. This is more labor intensive and costly, but is a safer pilot program.
Collapse and consolidate the NT4 resource domains, and import them into organizational units in AD.
Implement Dynamic DNS as the name resolution mechanism for Windows 2000 clients.
Establish an environment to support the eventual migration of the Exchange 5.5 global address list into AD. Exchange will make about 162 new object classes with attributes to the AD Schema.
In order to migrate the resource domains, perform the following steps:
Establish the resource domain trusts to the NT4 master user domains (these trusts should already be in place; you just need to verify that they are).
Upgrade the domain to Windows 2000 beginning with the PDC. You will not be able to name the new Windows 2000 domain the same as the old NT4 domain due to NETBIOS conflicts. For instance, if you have a NT4 domain named MRED, you will not be able to name the new Windows 2000 domain mred.com because Windows 2000 also creates a "NETBIOS compatible" name, which in this case would be MRED.
Clone all the local groups to the parent domain.
Demote the old BDCs to member servers, by using DCPROMO.exe. Remember to keep one BDC off line for disaster recovery. You will also want to bring the BDC on line every couple of days during the migration plan to make sure the SAM database is updated.
Move all member servers to an OU in the parent domain.
Run DCPROMO to demote the last BDC, destroying the old NT4 domain and moving the last BDC into an OU in the parent domain.
You are now ready to begin the deployment of the users' workstations. Here is how one client did it: Send the users to class, and when they get back from class send them an email. Have them respond to the email when they are ready for the new OS, and boom using Intellimirror when they get the new desktop. In this way, the end user becomes part of the deployment team.