The Active Directory Logical Structure Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

The Active Directory is defined as: A directory of network information about users, computers, and applications that links multiple domains together. (Byron Wright, 2008) The structure of the Active Directory is very scalable and can grow and shrink as companies and organizations grow and consolidate. TechNet at Microsoft states that:

Designing your Active Directory logical structure involves defining the relationships between the containers in your directory. These relationships might be based on administrative requirements, such as delegation of authority, or they might be defined by operational requirements, such as the need to control replication. In general, forests are used as security boundaries, domains are used to control replication, and OUs are used to delegate administration.

Step 1: Identifying the deployment participants - There are a few key roles that need to be filled in order to successfully deploy an Active Directory, these are:

1. The Active Directory Architect The person responsible for the overall design of the Active Directory making sure that the deployment is technically sound and reflects the goals of the business.

2. The Active Directory Manager The person who oversees the deployment and budget of the Active Directory and insures that the needs of each user group is met in accordance with the IT policies.

3. Service and Data Owners Service Owners are responsible for the long-term care of the Active Directory infrastructure, Data Owners are responsible for the data stored in the Active Directory.

4. Service and Data Administrators Service Administrators handle the daily tasks of maintaining the Active Directory service and infrastructure throughout the forest, Data Administrators maintain the computers and data within their domain.

5. Forest Owner - A Service Owner that is ultimately responsible for the entire forest, the Forest Owner sets the policies and chooses the system administrators.

6. Active Directory DNS Owner A Service Owner with a deep understanding of the DNS and namespace infrastructure of the company.

7. Site Topology Owner A Service Owner that understands the physical network and subnets within the company.

8. OU Owner A Data Owner responsible for managing the data in accordance with the security settings in place on the network.

Step 2: Forest design When designing the forest there are many factors to take into account: Where the forest will be hosted from, the number of forests within the organization, special needs of different groups within the forest, the possibility of public access to part of the forest through the use of the internet, the isolation or autonomy of particular users and/or data. Forest designs can fall under three basic models:

1. Organizational Forest Model - Every Active Directory must have at least one Organizational Model Forest. Within this forest; service autonomy, service isolation, or data isolation can be provided.

2. Resource Forest Model - These are used to make alternative paths to resources for the Organizational Forests and to provide service isolation.

3. Restricted Access Forest Model Used to contain highly sensitive material, sometimes these exist on completely separate infrastructures for security purposes.

Step 3: Domain Design within the forest The Forest Owner is responsible for creating the Domain design taking into regard the infrastructure in place and replication requirements. The forest must have at least one domain, however, more domains may be added to help load balance or if there are multiple locations replicating over WAN. The first domain that is deployed is the forest root, so it should be decided beforehand if this will be a dedicated domain for that function or if the root will reside in one of the regional domains.

Step 4: Design DNS structure to support Active Directory Active Directory requires the use of DNS for name resolution, so it must be determined if the organization already has a DNS service or if the service will be rolling out with the deployment of Active Directory. Regardless of which case is in effect, careful consideration must be used in naming conventions.

Step 5: Design Organizational Units The design, creation and assignment of ownership of an Organizational Unit is the Forest Owners responsibility. Once the OU is created with proper administrative properties in place, the OU Owner can create OU structures for user accounts and resource data.

Step 6: Group policy services and device installation Now that the backbone of the Active Directory is in place, the OU Owner(s) now sets up their individual group policies and device installation policies which may differ from the domain policies or forest policies. If there are conflicting policies the policy that takes precedent is the policy of the parent. The order of precedent from lowest to highest would be: User policy, Computer policy, OU policy, Domain policy, Forest policy.

These are the basic steps for designing an Active Directory logical structure. It takes a team of people and a lot of resources to successfully roll out an Active Directory deployment.

Part 2: Step-by-step guide to migrate to Windows Vista through the User State Migration Tool.

The User State Migration Tool (USMT) is much like Windows Easy Transfer, but without the wizard that guides the user through the process. Instead the USMT is a graphical tool or command line tool that can be used to script migrations for larger organizations. This can be used to simply copy the entire user profile and data from one machine to a new machine (side-by-side), or to move the user profile and data to the existing computer with a new operating system (wipe-and-load). The steps for a successful migration are as follows:

1) Plan the migration Determine what data is to be included in the migration. This data can be user settings, registry keys, operating system settings, application settings, files and folders. The administrator should also plan for intermediate storage of the migration information.

2) Back up the old system This falls under best practices for any major change in environment.

3) Scan the old system once all of the applications are closed out the administrator can use the ScanState command line to copy all of the data that is to be migrated. If some applications are running during ScanState or LoadState, USMT may not migrate some data. (technet, 2003)

4) Prepare the new computer Whether it is a completely new machine or an existing machine that has been wiped clean, make sure that the operating system is installed along with all applications that will be used on the machine (installing applications after the migration can have unexpected results). Even though applications should be installed, the applications should not be running during migration.

5) Load the new system once the system has been prepped it is ready for loading all of the data that will migrate from the old system. The administrator can use the LoadState command line with the same set of XML files used in the ScanState.

If a large scale exodus is to be implemented it is very important to first start with one computer to insure migration integrity, then move to a pilot group to insure that script deployment is working. After that it is best migrate groups of users rather than a global migration, that way if there are issues with the migration it is easier to manage and fix a few machines rather than possibly hundreds or thousands depending on the size of the organization.

While these steps are relatively straight forward as far as how to execute user migration, there are many variables that must be accounted for that can be handled by the User State Migration Tool. This can be a very powerful tool to use when a simple upgrade to workstation operating systems are not feasible.