Determining the Scope of Active Directory

One of the most important steps in any project is to define a project scope. The project scope helps to define at what point the project is complete, and it helps to define if the project is successful.

A project scope should be static. Sure, there are changes to technology and requirements that can force project scope change, but to keep the project on course and on budget, the project scope should not change much without a change to the overall focus of the project.

For these reasons, determining the scope of the Active Directory phase of a Windows 2000 project is important. What's more, it is important to choose a scope for which there is a good chance of success. Depending on the size of the organization, there can be several phases in which Active Directory is deployed across the organization. However, in smaller to medium-sized organizations, deploying Active Directory might be completed in one step. Which approach you should take is a function of time, budget, and resources.

Determining the Initial Scope of Active Directory

When determining the initial scope of your Active Directory project, remember the following points:

• If possible, create a design that includes the entire organization.

• Use project management techniques to budget resources within your desired timeline. If you do not have enough resources, change the timeline, increase resources, or reduce the project scope.

• Make sure your team's areas of influence, or political leverage, have clout in each area of the organization included in the project scope. If possible, recruit sponsors from each area of the organization to represent you and your project's interests.

To illustrate this topic consider our imaginary company, Wadeware, which has chosen to migrate from Windows NT 4.0 to Windows 2000. They hope to be done with their migration by the end of the year. Wadeware has built a project team with a dozen members, each representing an area of the company or a department within Information Systems (IS). Wadeware also has selected several contractors that they plan to use for the deployment.

The Wadeware organizational structure can be seen in Figure 7.1.

Based on this organizational structure, the number of resources Wadeware has, and the timeline they have chosen, Wadeware has decided to focus on the following areas of the organization during the initial design and rollout of Windows 2000 and Active Directory (see Figure 7.2).

It is important to reiterate that despite the scope of the Active Directory project being limited to only a portion of the organization, the design decisions should be based on the entire enterprise.

Determining Which Portions of the Organization Participate in Active Directory

Which portions of the organization should participate in Active Directory is really a two-part question. First, which portions of the organization should initially participate in Active Directory? Second, are there any portions of the organization that will not eventually participate in Active Directory, and if so, why?

If you choose to do a staggered, multi-phase rollout of Active Directory, you should, if possible, first choose those groups or departments in the organization that are sympathetic to your project. By working with cooperative groups or departments first, the project starts on the right foot.

Unfortunately, it might not always be possible to start with cooperative groups or departments. For those portions of the organization that participate in the initial rollout of Active Directory, another starting point is to choose a Windows NT domain that has limited user and computer objects.

If there are areas of your organization that you do not plan to include in your Active Directory, there should be a good reason. Try to include all parts of your organization in your Active Directory namespace design.

Delegating Administrative Functions

One of the reasons for implementing Windows 2000 and Active Directory is the directory's capability to delegate administrative tasks. Part of defining the scope of your Active Directory, and therefore its namespace, is to identify which administrative tasks are delegated to which groups. Identifying the amount of delegation goes a long way toward determining the complexity of the Active Directory domain and OU structure.

A good example of where administrative tasks can be delegated is the Helpdesk. When users dial the Helpdesk on the phone and the automated operator answers, they might be presented with a menu that allows them to navigate to the type of support they need. In the same way, specific administrative permissions can be delegated to the groups that perform these support tasks:

• Change or Reset Password —This group of Helpdesk support can be granted permissions to change passwords without having permissions on other attributes of the user object.

• Create or Remove Network Accounts —This Helpdesk group can create and delete users, but they cannot change preexisting user object attributes.

• Enable RAS Access —This group of Helpdesk can guide users through setting up their RAS services and enabling their Active Directory account for RAS access.

• Change User Name —Perhaps an administrative assistant for every group is granted the ability to change user names.

• Change Directory Information —Users can be granted the right to maintain their own Active Directory object information.

Human Resources (HR) is a department in many organizations that could assume much of the maintenance responsibility for the network account. HR manages user benefits, payroll, and personnel files—why not their network accounts too? When users are added to the HR system, a process or script could start that would create an Active Directory account in an OU and domain that is appropriate for the user as well as an Exchange mailbox on the appropriate Exchange server. This would go a long way toward alleviating IS from these day-to-day administrative tasks and freeing up resources for head-count to improve the IS infrastructure, not just maintain it.

Determining Which Applications Depend on Active Directory

Many directory-enabled applications depend on the directory for their functionality. It is important to know the requirements for the directory-enabled applications in your environment.

It is just as important to ensure that current applications with their own directory will have the same functionality after they rely on Active Directory. For example, an organization might use Microsoft Exchange on Windows NT 4.0. Microsoft Exchange versions 5.5 and earlier has its own directory service that users can access for directory information. After the next version of Exchange (which no longer has its own directory but uses Active Directory) is released, it is important that Active Directory provides users the same look and feel as they had with the Exchange directory. This might not be as easy as it sounds. With Exchange, each Exchange server hosts a complete copy of the Exchange directory. With Active Directory, each Active Directory Domain Controller (DC) only hosts object information for the objects that are in its domain. A Global Catalog (GC) server is the only server that contains partial object information for every object in Active Directory. Therefore, a user looking up detailed information from the Exchange directory might have a different experience when looking up the same data from Active Directory, especially for a user who exists in a different domain.

One of the primary reasons for implementing Windows 2000 is Active Directory's capability to interact with applications. Active Directory provides a solid foundation of organizational data from which many applications draw. Therefore, it is important that the namespace is designed so that applications can take full advantage of this Active Directory feature.

Applications that store directory data within Active Directory are also able to change the Active Directory schema. If an application is installed and makes modifications to the schema, those definitions describe the classes of objects being used by the application, thus enabling other applications can use that information.

Determining the Future Scope of Active Directory

Although in small, and even medium-sized, organizations the scope of the initial Windows 2000 deployment might encompass the entire organization, in larger organizations there will probably be a staged rollout that might take several months or even years. Whatever scenario fits your organization, it is important to remember that although the initial rollout of Windows 2000 might only be to a portion of the organization, the Active Directory design should consider the entire organization, because you don't know what the future might hold.

Determining Which Portions of the Organization Should Eventually Participate in Active Directory

Your organization might choose to only include North American locations in its first Windows 2000 design and deployment. You have taken the initiative and are designing a namespace and Active Directory that will eventually meet the needs of the entire organization. You might not know all the requirements of your European and Asian locations, but you have built in enough flexibility so that what ever their requirements turn out to be, you are going to be able to accommodate them. However, unbeknownst to you, the networking services group is implementing Active Directory-enabled network routers. These routers provide a Quality of Service (QoS) based on Active Directory users and groups. These routers can also restrict access to areas of the network depending on the user. Not knowing these new requirements has tested the flexibility of your namespace and directory. What you have learned is that there are not only vertical areas of the organization, such as line-of-business, departments, regions, and groups, that need to be considered, but that there are horizontal areas of the organization, such as networking services, data services, and telecom, which also might eventually participate in your Active Directory. Hence, if possible, look at the organization from 20,000 feet, speculating on the future direction of both the vertical and horizontal areas of your organization.

Determining Which Administrative Functions Will Eventually Be Delegated

One of the other primary reasons organizations implement Windows 2000 and Active Directory is the capability to delegate the management of resources out from IS to the departments where they belong. For example, many organizations reorganize frequently. Other organizations frequently move people and resources from office to office or building to building. Other organizations do both, by constantly reorganizing and moving. In the middle of this chaos, the IS group has trouble keeping up with new office numbers, printer locations, and even telephone numbers. Most IS groups quit managing this directory information because of the overhead involved with keeping up with the organization. If, however, the management of this data could be delegated out to the groups or departments that move, part of the move process could be for a group or department administrator to update the directory information. By delegating administrative authority for specific object attributes to departmental administrators, IS no longer needs to spend resources managing this ever-changing information.

Determining Which Applications Will Eventually Depend on Active Directory

It is a valuable exercise to try to determine which applications will eventually depend on Active Directory. The reasons for this are twofold: to be proactive in your namespace and Active Directory design (taking into consideration an application that will rely on Active Directory), and to help further legitimize the project as having benefit now and in the future. Chapter 18, "Windows 2000 and Exchange Server," describes the design considerations placed on Active Directory by Exchange 2000, (an Active Directory-enabled and dependent application). By acknowledging both current and future applications that are supported by Active Directory, those applications are more easily implemented, and Active Directory is more justified.