Home > Articles > Microsoft > MCSE

MCSE Exam 70-297: Creating the Active Directory and Network Services Conceptual Designs

This chapter is from the book

Chapter 3: Creating the Active Directory and Network Services Conceptual Designs

Terms you'll need to understand:

  • Scope

  • Administrative model

  • Kerberos

  • Trust

Techniques you'll need to master:

  • Designing the Active Directory infrastructure to meet business and technical requirements

  • Designing the network services to meet business and technical requirements

  • Analyzing the impact of the infrastructure design on the existing technical environment

Designing an infrastructure that will properly support Windows Active Directory requires a large amount of pre-planning. Many organizations will be upgrading their current infrastructure. With that in mind, the organization will likely have in mind certain requirements for the new infrastructure. An important part of the design phase is to identify the business and technical requirements, and then use the information to design an Active Directory hierarchy that meets these requirements.

Designing the Active Directory Infrastructure to Meet Business and Technical Requirements

You need to begin your analysis of the business and technical requirements by addressing the organization's administrative model.

Designing the Envisioned Administrative Model

During this phase of the Active Directory design, you assess the current administrative model that is being used by an organization. This information has a major effect on the Active Directory structure that will be put into place—for example, the number of domains that are created.

Determining the Administrative Model

Determining the administrative model that a business has implemented is important to the Active Directory design process. The administrative model basically determines who holds the decision-making authority within a business and who is responsible for implementing these decisions. There are basically three administrative models that can be implemented: centralized, decentralized, and mixed mode. Table 3.1 summarizes these three administrative models.

Table 3.1 The Three Administrative Models




A central group holds all the decision-making authority within an organization.


Different units within a business are responsible for their own administration.


A central group maintains some level of decision-making or mixed mode authority, but certain administrative tasks are assigned to each business unit.

Identifying Responsibilities for Administering Resources

After the administrative model within the organization has been identified, the next step is to identify who is currently responsible for administering network resources. When determining administrative responsibilities, consider the following questions:

  • Who is responsible for what?

  • Determine which individuals or groups within the business should have administrative privileges and what their responsibilities are. For example, a group of individuals might have been given the responsibility of administering user accounts, whereas another group might have administrative privileges over network printers.

  • Where do these privileges apply?

  • Do the permissions apply throughout the organization or only to certain areas? For example, in an enterprise network, if a user has been given administrative authority over user accounts, should this privilege apply to all domains and organizational units (OUs) or just specific ones? In other words, what is the scope of the administrative privilege?

  • What type of privilege is assigned?

  • Does the individual or group have full administrative privileges or control over only certain aspects? For example, what level of control does the individual or group have over user accounts? Does the individual or group have full control or control over only certain aspects of user accounts?

Determining the answers to these questions will help you develop a delegation plan that can easily integrate into the business's current administrative model and its current way of distributing administrative tasks among its employees.

Determining the Type of IT Organization

To effectively design an Active Directory hierarchy, the current structure of the IT organization within the business must be assessed. After the current structure has been documented, the design team can work with the company to determine whether there are any areas that need improvement or areas that can be restructured for easier administration. This information will assist in creating a design that meets the requirements of the business.

When assessing how the IT organization within a business is structured, determine the model that is currently in place. Is the network administration centralized or does the business allow for distributed administration (decentralized)? Determining this will ensure that the needs of the IT organization are identified and reflected in the administrative model that is developed.


An organization can also have decentralized management but a centralized IT function, and vice versa. Do not assume that decentralized management means decentralized IT.

The centralized model is hierarchical in structure. It is characterized by one individual or group overseeing all network development and administration to whom the IT organization would report. Some of the day-to-day administrative tasks might be assigned to select individuals or groups outside the IT organization, but most network administration remains centralized. The IT organization maintains decision-making authority as well as the responsibility for ensuring that all decisions are implemented throughout all levels within the business.

There is also a slight variation to this model in which the IT group is still centralized, but some of the day-to-day management tasks are decentralized. The central IT organization is responsible for overseeing network development and possibly implementing organization-wide policies, and the IT groups within the different business units are responsible for the day-to-day administrative tasks, such as creating user accounts.

With decentralized management, one person or group no longer holds all the decision-making and network administrative authority; in other words, no hierarchy or central IT organization oversees all network development. Each business unit maintains its own IT organization and implements its own IT model based on its needs. When it comes to technical issues affecting the entire organization, the different IT groups from each of the business units would have to work together. For example, if a business is planning a rollout of Windows Server 2003, each of the IT groups from the different business units would have to be involved.

The type of IT management structure that a business implements will not have a direct effect on the Active Directory structure. It is still crucial to characterize the current IT organization that a business has implemented because this information helps the design team determine the administrative model to use. However, the administrative model directly affects the organization of the different elements within the Active Directory structure.

Developing a Model for Administration

After you've characterized the type of IT organization that a business has in place, the next step is to develop a model for its administration. The administration model that is chosen determines the organization of the Active Directory structure. The type of model that is developed should be based on the structure of the IT organization (centralized versus decentralized). There are basically four models for administration:

  • Geographical (location)

  • Organizational (business unit or department)

  • Functional (role)

  • Hybrids (combinations of the preceding types)


The administrational model chosen directly affects the Active Directory design—particularly the creation of top-level domains or organizational units.

Geographical (Location)

If you choose to implement an administration model that's based on geographical location, the Active Directory structure will be organized around the different locations within the business. This type of model is well suited for a business that maintains a central IT organization but decentralizes management by assigning the responsibility of performing day-to-day administrative tasks to the different IT groups within the business units.


Before implementing this type of model, make sure that an individual or a group of individuals at the different locations is capable of performing these day-to-day tasks.

One of the positive features of an administrative model based on location is that it is fairly immune to reorganization and expansion. When a company changes its structure, it most often reorganizes departments but not the geographical locations of the business. Accommodating expansion can be as simple as creating a new domain or OU for the new location.

Organizational (Business Unit or Department)

If a business has implemented a decentralized IT organizational model and allowed the different departments to maintain localized control, a model for administration that is organizational (based on business units or departments) might be best. The organization of the Active Directory structure would be based on the different business units or departments within the company.

One of the nice features of this model is that it allows a business to maintain its departmental divisions. Each business unit maintains control over itself. However, in a model based on departments, if the departments are reorganized, it could mean a reorganization of the Active Directory structure.

Functional (Role)

This type of model is based on the different job roles within a business, without consideration of the different geographical locations and departments. For businesses that implement a decentralized IT organization and have job roles that span multiple divisions, the functional model might be more suited to their administrative needs than an organizational model.

This model is more manageable within a smaller business because users are more easily grouped into general functions. The larger the business, the more variance in job roles and the harder it is to group users. However, large organizations with many mobile users might find this model very attractive.

Because this model is based on the different roles within the business, it is essentially immune to reorganization. Reorganizations within a business most often affect departments, whereas job roles are not usually affected.

So far, we've covered three different administration models that a business could implement. The fourth model is a combination of those three models.


To design an Active Directory structure that meets the administrative needs of the IT organization, it might sometimes be necessary to combine several models. This type of models is known as a hybrid. Two of the common hybrid designs are "geographical, then organizational" and "organizational, then geographical."

In a "geographical, then organizational" model, the upper layers within the Active Directory structure are based on location, and the lower layers are organized around business units. This type of model is well suited for a business that spans geographical locations. Because the lower levels of the structure are based on business units, it also allows a business to maintain departmental independence.

Because the upper layers of the Active Directory structure are organized around the geographic locations of the business, it is immune to company reorganizations. However, a reorganization of the company might result in some restructuring of the lower layers because they are based on departments. Nonetheless, restructuring of OUs is simpler than the restructuring of domains.

The second type of hybrid model is the opposite of the one we just discussed: The upper levels of the hierarchy are based on the different business units or departments within the company, and the lower levels are based on the geographical locations. This model is ideal for businesses that need to maintain independence between the different departments for security purposes. Basing the lower levels on the physical structure (geography) also allows a business to distribute administration among the IT groups in different locations.


You might recall the discussion about models for administration based on departments and how they are affected by reorganization. This model will be affected by any reorganization that occurs within the business and might result in an entire restructuring of the Active Directory.

Creating the Conceptual Design of the Active Directory Forest Structure

In most cases, a single-forest structure should be sufficient. You also want to keep your Active Directory design as simple as possible. With that in mind, a single-forest structure is usually recommended for administrative purposes. However, in some instances, it will be necessary to consider a multiple-forest environment to meet the requirements of a business. This type of model is one of the most difficult to design and administer, so when you're considering the forest structure, keep the following topics in mind:

  • Business reasons

  • Trusts relationships

  • Schema issues

Business Reasons

Before designing an elaborate structure that includes multiple forests, be sure to assess the business to determine whether there is an actual need for more than one forest. Consider a multiple-forest structure if a business has any of the requirements discussed in the next few paragraphs.

Does the business maintain partnerships or have subsidiaries with which it needs to maintain a very limited partnership? One of the most common reasons why you would create a multiple-forest environment is to meet an organization's need to maintain a limited trust with another organization or its subsidiaries. A situation such as this might arise when a business establishes a limited partnership with another organization or when an organization includes subsidiaries gained through corporate acquisitions. Separate forests might need to be created for security purposes, and when multiple forests are established, the scope of the trust relationship can be limited and closely monitored.

Does the business need multiple global directories? The global directory maintains a listing of all objects within the forest as well as certain attributes pertaining to each object, and all domains within a forest have access to a common global directory. If a business does not want one global directory for its entire organization, a multiple-forest structure must be implemented.

You'll recall from Chapter 2, "Gathering and Analyzing Business and Technical Requirements," that the schema maintains a list for the entire forest of all objects that can be stored within Active Directory as well as the attributes associated with each object (see Figure 3.1). A default schema policy comes with Windows Server 2003, but it can be modified if it does not meet your business's requirements. If an organization requires different schema policies for its various business units or if the administrators from the different business units cannot agree on a schema policy, multiple forests must be created.

Figure 3.1Figure 3.1 The Active Directory schema.

Partitions are applied at the forest level, so all domains within a forest will be affected by the same partition. If a business plans to make changes to the default schema but does not want its entire organization to be affected by changes, a multiple-forest structure should be considered. An appropriate partition could then be implemented for each forest. Because partitions are not replicated between forests, schema changes in one forest do not affect other forests.


Make sure you understand the circumstances under which it is appropriate to create multiple forests. Be prepared to encounter exam questions in which you must determine whether multiple forests are necessary based on a given scenario.

Creating the Conceptual Design of the Active Directory Domain Structure

As you've probably already noticed, assessing the needs of the business is crucial in all aspects of designing an Active Directory infrastructure. The needs of the business should also be the first thing considered when designing a domain. The infrastructure created by the design team should reflect the current structure of the business. When assessing the business, you need to detail the administrative requirements as well as the security requirements. Both of these requirements have a major effect on the domain and OU structure that will be planned for the business.

Administrative and Security Requirements

When designing a domain, the first thing that should be documented (or reviewed, if it has already been determined) is the administrative strategy that the business has implemented. The type of administrative structure that a business has in place determines the creation and organization of domains within the Active Directory. Does the business implement a centralized or decentralized strategy for administration? Knowing how the administrative tasks are distributed throughout the business helps determine the model for administration that will best meet the needs of the business. The administration model implemented should allow the business to distribute administrative tasks in a way that meets its administrative requirements. The administration model will also determine the organization of domains and OUs in the Active Directory hierarchy.


Recall that there are essentially four models that can be implemented for administration: geographical (location), organizational (business unit), functional (role), and hybrid models. The domain design should be based on the administrative model.

After you've determined the administrative requirements of the business, the security requirements have to be assessed. (Security within a business is usually crucial, so be sure that the assessment is thorough.) When assessing the security requirements, you need to determine who is responsible for administration within the business (delegation of authority). Documenting this information ensures that the proper permissions are assigned to the proper individuals. Use the following questions as a guide when performing the assessment:

  • Who in the business requires administrative privileges?

  • What are they responsible for?

  • What type of administrative privileges do they require to do their jobs?

  • What is the scope of their responsibilities?

  • Will their privileges apply at the site, domain, or OU level?

After the administrative and security requirements of the business have been determined, you should have a good understanding of the domain structure that best meets the business's needs. Your next step is to plan the creation of the first domain within the Active Directory structure.

Creating the First Domain in Active Directory

The first domain created within Active Directory becomes the forest root domain. This is the domain that represents the entire business. It is important to plan which domain will become the forest root domain because it can be difficult to restructure the Active Directory hierarchy if this domain must be renamed.

Careful planning is required when choosing a name for the forest root domain because other domains added to the structure might inherit a portion of their namespace from the root domain.

When deciding what to name the first domain in Active Directory, keep the following points in mind:

  • Choose a name that will not change in the near future; that is, choose a name that is static. Changing the name of the forest root domain is not easy, so try to choose a name that will not be change in the next 3 to 5 years.

  • Choose a name that is meaningful to the business, its employees, and its clients. When naming the forest root, consider using the name of the business.

  • Make sure that the name is available for use on the Internet. Even if the business has no intention of using its name on the Internet, make sure that the name is registered in case the business changes its mind in the future.

  • The internal namespace can be, and often is, different from the company's external namespace, but it can still cause problems if it is the same as a name already being used on the Internet.

When creating the forest root domain, the design team might determine that the business's name is an appropriate choice (as long as the business has no intention of changing the company name in the near future). The company name provides a general representation of the business and an appropriate namespace for child domains within the forest. The company name is meaningful to employees and clients and makes the domain easily identifiable.

Several elements make up an Active Directory infrastructure. When you're planning for each element, different aspects of the business must be assessed to ensure that each element is implemented in a way that meets these business requirements. When you're designing a domain tree, one of the first things that must be done is an assessment of the business. When you're designing a domain structure, keep in mind that a single-domain model is simpler to implement and easier to administer than a multiple-domain model. There will definitely be times when a single-domain model is not suitable for a business, but only a thorough assessment of the business can determine whether a multiple-domain model is necessary.

Requirements for Multiple Domains

There are some instances in which a single domain will not meet the requirements of an organization. In other words, certain situations might result in the creation of multiple domains. If one of the requirements discussed in this section is met, consider implementing multiple domains.

Does the business want to maintain decentralized administration among its business units or geographical locations? If the business requires each division or geographical location to be responsible for its own administration, multiple domains might need to be created.

Is there a need to maintain a distinct administrative boundary between different areas within the business? If so, multiple domains should be considered. Domains determine both the security and administrative boundaries within an Active Directory hierarchy. When multiple domains are created in a forest, the Domain Admins group within each domain has privileges only within its own domain unless permissions to another domain are explicitly granted.

Does the business require multiple security policies? Remember that in an Active Directory hierarchy, the domain is the security boundary. In some cases, a single security policy can meet the security needs of an entire business. For cases in which a company has to create multiple security policies for different areas within the business, a multiple-domain structure is needed.

Does the business have subsidiaries that need to maintain separate and distinct namespaces? For those businesses that have established partnerships and need to be included in the Active Directory structure, a multiple-domain structure is necessary, especially if a separate namespace is required.

Does the physical structure of the current network present a need for multiple domains? Replication within a domain occurs between all domain controllers. If there are locations within a business that are connected by physical links that are slow or unreliable, multiple domains can be created to optimize replication.


Be sure that you understand when to create multiple domains. You're likely to encounter exams questions in which you must decide whether to implement a single domain or multiple domains based on a specific scenario.

Planning Domain Trees

So far, we've been talking about creating a single forest with a single tree. However, there could also be instances in which you need to create multiple trees within a single forest. To create a domain structure that meets the business requirements, it's crucial that you first have a thorough understanding of how certain operations occur between domains (certain operations that occur within a domain might occur differently between domains). When you're planning domain trees, an understanding of the following topics is necessary:

  • Accessing resources between domains

  • Authentication across domains

  • Types of trust relationships

  • Creating an empty root domain

Accessing Resources Between Domains

Windows Server 2003 provides support for the Kerberos version 5 protocol (an industry-supported authentication protocol), which is responsible for the authentication of users across domains. One of the features of the Kerberos version 5 protocol is transitive trusts. In a multiple-domain structure, two-way transitive trusts are automatically configured between parent and child domains within a forest. This enables users to be granted permissions to resources throughout the forest. When a user attempts to access a resource located within another domain in the forest, the transitive trust path is followed.

Authentication Across Domains

Authentication is the process of confirming the identity of the user attempting to gain access to network resources. Before a user in one domain can access resources in another domain within the forest, that user must be authenticated. As already mentioned, the Kerberos version 5 protocol is responsible for authentication across domains. Because support is included for this industry-standard security protocol, users need only provide a single username and password at logon to gain access to resources throughout the forest.

Before a user is granted access to resources in another domain, the key distribution center (KDC) from each domain in the trust path must first authenticate the user. The KDC has two roles: It is responsible for authenticating users and for issuing session tickets to users so that they can identify themselves to other domains.

Types of Trust Relationships

Three types of trust relationships can be implemented in Windows Server 2003 to enable users to gain access to resources located in other domains: transitive, shortcut, and external trusts. Transitive trusts are automatically established, whereas shortcut and external trusts must be explicitly defined. Within a single forest, no trust relationships have to be explicitly defined. This is due to the fact that two-way transitive trusts are automatically established between parent domains and child domains, thereby creating a trust path throughout the forest. Shortcut trusts can be established between two domains to shorten the trust path. However, the trust exists between only the specified domains.

Creating an Empty Root Domain

In an Active Directory hierarchy where there are multiple domains, the design team might choose to create an empty forest root domain. That domain would not contain any OUs, and the only users in the domain would be the members of the Enterprise Admins group. The empty forest root domain establishes the namespace that will be inherited by child domains (see Figure 3.2). Creating an empty forest root domain would be appropriate for a business that wants to maintain a contiguous namespace throughout the organization and allow for decentralized administration.

Now that you've familiarized yourself with how some of the operations occur within a multiple-domain structure, let's take a look at some of the guidelines that you must consider when designing multiple domains.

Figure 3.2Figure 3.2 A forest root domain with its child domains.

Domain Design Issues

When planning a multiple-domain structure, keep the following design issues in mind:

  • Security

  • WAN or LAN bandwidth constraints

  • Legal issues

  • Domain-wide policies


One of the reasons why a multiple-domain structure might be created is to meet the security requirements of a business. If the business implements decentralized administration and needs to maintain a distinct security boundary between its different business units, a multiple-domain structure should be established. Creating a separate domain within the forest for each business unit allows each business unit to maintain its own administration.

If the different locations or departments within a business have different security needs (such as password requirements) or if a single security policy for the entire organization cannot be agreed upon, multiple domains might have to be created. That way, the administrators from each domain can establish security policies that meet their specific requirements.

Also keep in mind that the more domains you create, the more Domain Admins groups there are to monitor. This adds administrative overhead and might become difficult to track (especially for security purposes).

WAN or LAN Constraints

Replication is based on the multi-master replication model. All domain controllers within a domain are equal and all maintain an up-to-date working copy of the directory database. That means there will be more replication traffic within a domain (as opposed to between domains) because any changes made to the directory will be replicated throughout the domain to all domain controllers.

Also keep in mind that every attribute associated with an object is replicated throughout the domain, which adds to network traffic. On the other hand, only certain attributes are replicated to Global Catalog servers in other domains.

The point of this discussion is that if there are LAN or WAN links within the organization that are slow, unreliable, or already heavily used, they might not be able to support the amount of replication traffic that will be generated within a domain. In cases such as this, multiple domains must be created to optimize replication.


The use of site links within a single domain can also provide the same control over replication as creating multiple domains.

Legal Issues

In today's world of enterprise networks that span different countries, there might be legal issues to consider when planning domains that could result in the implementation of a multiple-domain structure. For example, a business that has an international presence might be required to maintain separate domains for its overseas locations. An organization might need to keep employee information for its European subsidiaries separate from U.S. employees because the European Union has much more stringent confidentiality requirements than the United States. To meet the security requirements of different countries, separate domains would have to be created.

Domain-Wide Policies

If there is a need to create different security configurations for different groups of users and computers throughout the business, it might be necessary to create more than one domain. Only a thorough assessment of a business's security requirements can determine whether more than one domain will be needed. The following are some security options set on a domain basis:

  • Password policy—Password policies determine the requirements for user passwords, such as a minimum password length.

  • Account lockout policy—An account lockout policy determines the guideline for locking a user account out of the system.

  • Kerberos policy—A Kerberos policy determines the settings pertaining to Kerberos security, such as session ticket expiration time.

Multiple-Tree Forests

A forest is established when the first Active Directory domain is created; this domain is known as the forest root. Within a forest, any domains that share a contiguous namespace form a tree (see Figure 3.3). After a tree has been established within a forest, any new domain added to an existing tree inherits a portion of its namespace from its parent domain. Any domain that is added to the forest and maintains a unique namespace forms a new tree. Therefore, it's possible to have more than one tree within a single forest, and there might be instances in which multiple trees are required to meet the needs of a business.

Figure 3.3Figure 3.3 A multiple tree forest.

Business Requirements

Remember that when you're planning a domain structure, simplicity is always best. If a business does not require multiple trees, don't make things more difficult by creating an elaborate multiple-tree structure. However, there will be instances when multiple trees are required. Again, only a thorough assessment of the business can determine whether this is necessary. When considering a multiple-tree structure, keep the requirements discussed in the following subsections in mind. If a business requires any one of the following, you might need to design a multiple-tree structure.

DNS Names

If a business is comprised of different subsidiaries or has partnered with other businesses that need to maintain their distinct public identities as well as separate (noncontiguous) DNS names, multiple trees might have to be created within a single forest.


If an organization has subsidiaries with unique DNS domain names, the organization can create a domain tree for each namespace to maintain the subsidiaries' individual DNS identification.

Central Directory Information

All trees within a single forest share the same schema, configuration container, and Global Catalog. If an organization wants to have centralized administration of these and maintain a single schema, configuration container, and Global Catalog for the entire organization and all its business units, a single forest with multiple trees can be implemented.

One of the nice features of being able to create a distinction between business units while keeping them within the same forest is that users within different trees can still easily search for objects forest-wide because all objects share a common Global Catalog.

Trusts Between Trees

When a new tree is established within a forest, a two-way transitive trust is automatically established between the two root domains. This two-way trust creates a trust path that enables users from one tree to access resources located within another tree in the same forest. The really nice thing about this is that a path is created throughout the Active Directory hierarchy without any administrative effort.

Creating the Conceptual Design of the Organizational Unit Structure

The OU structure that is designed should reflect the administrative needs of the business. The OU structure is irrelevant to the regular users within the business—it is created for the purpose of administration. The design should enable administrators to easily delegate control over groups of objects to the appropriate user or group. The OU hierarchy should also allow for the linking of group policies. The following topics are covered in this section:

  • Starting with administrative requirements

  • Tailoring for group policy application

Starting with Administrative Requirements

When you're creating an OU structure, remember that it must meet the needs of administration (this cannot be emphasized enough). The structure you design should be based on the administrative model that the business implements. The OU structure should allow the business to continue to delegate authority and distribute administrative tasks in a way that meets its needs.

As the OU structure is being designed, keep in mind that the upper layers of the hierarchy are based on the model for administration. If the design team determines that a model based on geographical location is needed for administration, the upper layers of the OU hierarchy will reflect this model.


Be sure to base the structure of the upper layers of the OU hierarchy on something that will remain static (for example, geographic location as opposed to department or business unit). Doing so will help to avoid a reorganization of the Active Directory hierarchy in the future.

The lower levels within the OU hierarchy should be created with specific administrative tasks in mind; in other words, what types of objects will users and groups be responsible for administering? How can these objects be grouped to allow for this administration? For example, if a group is to be responsible for printer administration within its location, an OU could be created for printer objects and delegation of authority can be assigned to that group. By nesting OUs within one another, you can create an OU structure that meets the specific administrative requirements of the business.


Although nesting OUs is a good thing, the hierarchy can become difficult to administer and troubleshoot if it is too deep.

After you've determined that the administrative requirements have been met by the OU structure, you also need to determine how it will be affected by the application of group policies.

Tailoring for Group Policy

Group Policy is used to administer the computing environment of users and computers within a business (which is further discussed in Chapter 4, "Creating the Logical Design for an Active Directory Infrastructure"). A Group Policy object can be linked to different levels within the Active Directory hierarchy, and the level at which it is linked determines the scope of the policy. Group policies are most commonly linked to the OU level because doing so provides administrators with the most control over the computing environment and allows for the delegation of authority to users and groups, thus eliminating the need to give them administrative privileges at the domain level.

The lower levels of the OU hierarchy should enable administrators to apply specific group policies to the necessary objects. For example, if a group policy needs to be applied to a group of specific users, a lower-level OU could be created for this group and linked to the appropriate group policy.

Remember that GPOs are applied from the top level down, and if the OU structure is too deep with GPOs at different levels, it might result in poor network performance. However, it is the number of GPOs, not the OU depth, that affects logon times.

Pearson IT Certification Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Pearson IT Certification and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Pearson IT Certification products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.pearsonitcertification.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020