In my first Windows 2000 Ready column, I wrote about the three-phase approach to migrating to Windows 2000 (Win2K). This week I turn to phase 2—the planning phase, which can require a lot of thinking. Let’s discuss some of the major areas that you’ll want to focus on during the planning phase.
Active Directory and Domain Model
Your major task in phase 2 is designing your domain model and Active Directory (AD) structure. Do you need several domains, trees, or forests in your design? A lot of us are used to thinking in terms of the Windows NT domain models. We assume that the larger an enterprise, the greater the number of domains, trees, and forests we’ll need. Well, that’s not necessarily true with Win2K. As a general rule, always plan for a single Win2K domain with organizational units (OUs), unless you’re convinced that you need more than one domain. Multiple domains may be desirable under certain circumstances. Typically, you’ll want to create multiple domains to reduce network traffic, decentralize administration, and enforce separate security or account policies. Companies involved in joint ventures or partnerships can also benefit from multiple domains.
Can you have a single domain with 100,000 users? You bet. NT 4.0 doesn’t scale well for large enterprises. NT’s SAM has a recommended limit of 40,000 objects (e.g., computers, users, groups) and can’t exceed 40MB (I say recommended because these are not hard-coded limits). Win2K’s AD domains have a 17TB limit for object databases, which in theory should let you store at least 10 million objects per domain. Compaq has successfully tested 16 million objects in a domain.
Site Topology
The next step is to plan your site topology. In Win2K’s AD context, a site is a collection of machines in one or more IP subnets, connected by a high-speed link. What constitutes a high-speed link depends on whom you talk to—but it’s as fast as 512Kbps to T3 (or faster). Before we argue about what constitutes a fast link, consider this: When designing sites, it doesn’t matter what others consider a high-speed network connection—you need to look at your fastest link and plan your sites accordingly. But for what it’s worth, Win2K’s online Help says that if a ping to your server takes less than 2000 milliseconds, you’ve got a high-speed link.
Creating sites gives you several advantages. You can control how changes in AD replicate to domain controllers in other sites, which lets you optimize replication traffic based on your business needs. When planning sites, keep in mind that when users log on, they try to locate a domain controller at their own sites first, which increases workstation logon traffic. Sites can also be useful in optimizing access to your fault-tolerant DFS. You can use the data you gathered in phase 1 to look at your link speed between various locations and create a site structure that serves as a good balance between workstation logon requirements and replication traffic for your network.
Operations Masters
Certain Win2K servers will play important roles, and you’ll need to decide where to place them. AD supports multimaster replication for updating databases, but certain changes don’t work well in multi-master fashion, so a single domain controller must perform them. These domain controllers are known as Operations Masters (formerly Flexible Single Master Operations—FSMOs). Some roles, such as Schema Operations Master and Domain Operations Master, are forest-wide (i.e., there’s only one per forest). Other roles, such as Relative Identifier (RID) Operations Master, PDC Emulator, and Infrastructure Operations Master, are domain-wide (i.e., there’s one for each domain).
Schema Operations Master manages changes to the schema and replicates the schema to other domain controllers. Domain Operations Master adds and removes domains. When planning for these roles, you can place both roles on the same domain controller. Ideally, you want to place these roles on machines that are close to the people responsible for updating your schema and creating and deleting domains. A RID Operations Master manages a pool of SIDs for its domain. A PDC Emulator is a domain controller that acts as a PDC for downlevel domains in the same network and handles password changes and account lockouts. Unless you have a very large network, you can place RID Operations Master and PDC Emulator on the same domain controller.
Group Policies
Planning your group policies is probably the most difficult of the phase 2 tasks. Group policies let administrators control users’ desktop environments and implement security. Incorrect implementation of group policies can have disastrous effects. I recommend that you designate someone to specialize in this area. You can apply Group Policy Objects (GPOs) to a site, domain, or OU—in that order. You can also use GPOs to filter objects based on the security group membership. Here are some other GPO issues you need to consider:
- How are you going to apply the GPOs?
- Who will manage the GPOs?
- Are you going to apply them at the site, domain, or OU level?
- Will you be modifying the administrative templates?
- Do you need to use the Block Inheritance feature to prevent group polices applied at the site or domain level from being applied to the OU level?
- Is the No Override feature of group policies useful in your organization?
Organizational Units
Finally, you need to plan your OUs. In AD, OUs delegate authority. Decide which objects (e.g., users, computers, shared folders) you want managed and place them in different OUs depending on who will manage them. To avoid complication, you’ll want to assign control to users or groups at the OU level—instead of the object or attribute level. You will also need to consider how you’ll handle any possible movement of objects between OUs. When an object moves, it retains the security permissions assigned explicitly to that object. The object inherits OU level permissions from the destination OU, so permissions inherited from the previous OU will not have any effect on the moved object.
Although you can nest OUs, you might want to keep the number of OU layers to a minimum if you’re new to OU administration delegation under Win2K. Multiple layers (or nesting) of OUs could prove to be a nightmare for administrators. You can use OUs not only to delegate control to users managing the AD objects, but also to apply group policies.