Home > Articles

This chapter is from the book

This chapter is from the book

Active Directory Connector Operation

One of the challenges in making the transition to Exchange 2003 consists of extracting all the operational parameters for e-mail recipients, distribution lists, custom recipients, public folders, address lists, and message routing parameters from the existing legacy Exchange directory service and putting that information into Active Directory. You as the administrator can move mailboxes and connectors off the old Exchange 5.x servers and onto sleek, new Exchange 2003 servers with minimal service disruption.

The tool Microsoft supplies to perform this operation is called the Active Directory Connector, or ADC. As illustrated in Figure 12.1, the ADC locates objects of interest in both directory services—legacy Exchange and Active Directory—and copies attributes for those objects back and forth to keep the objects in sync. An exception would be a one-way Connection agreement, used in specialized circumstances.

  • Legacy mailbox owners replicate to Active Directory as mailbox-enabled user objects.

  • Legacy distribution lists become mail-enabled Universal Distribution Groups, which get promoted to Universal Security Groups if used to control access to public folders or user mailboxes.

  • Legacy custom recipients become mail-enabled contacts.

12fig01.gifFigure 12.1 Diagram of object replication to and from the legacy Exchange directory service and Active Directory.migration from legacy ExchangeADCone-way Connection agreementsADC (Active Directory Connector)migration from legacy Exchangeone-way Connection agreements

With the ADC working in the background, you can manage legacy Exchange objects from the Active Directory Users and Computers console. Once all mailboxes, public folders, and connectors have been moved, you can decommission the legacy servers and remove the ADC from service.

Don't use the ADC that comes on the Windows 2000 or Windows Server 2003 Setup CD. That version of ADC does not map special attributes required by Exchange recipients and public folders. If you have already installed the operating system version of the ADC, remove it before installing the Exchange version. Also, unlike the Exchange files themselves, you can do the initial installation of the ADC using the Exchange service pack files.

Connection Agreements

The ADC stores configuration parameters in Active Directory objects called Connection Agreements (CAs). A CA defines object types for the ADC to copy, the source and target containers for the objects, a replication schedule, credentials to use for making inter-server replication connections, and the name of an Exchange server to act as an endpoint on the legacy side of the CA.

The ADC uses LDAP to query and update servers on both sides of a CA, so the legacy Exchange server must run Exchange 5.5 SP3 or higher to support LDAP writes and paged results.

Exchange servers that do not form the endpoint of a CA can run earlier versions of Exchange, but you should try to run the same version on all servers to minimize potential compatibility issues and increase flexibility.

The ADC uses three types of CAs:

  • Recipient. This CA maps the attributes of User, Group, and Contact objects in Active Directory with Recipient, Distribution List, and Custom Recipient objects in the legacy Exchange directory service.

  • Public Folder. This CA maps legacy public folders with Public Folder objects in Active Directory to permit Exchange 2003 to accept e-mail on behalf of the public folders.

  • Configuration. This CA maps some of the objects in the legacy Configuration container with objects in the Exchange 2003 Organization container in Active Directory. You cannot create this CA manually. Exchange Setup configures the CA as part of installing the first server in each legacy site.

Because each site forms a separate naming context in the legacy Exchange directory service, you must create a separate User and Public Folder CA for each site. The Connection Agreement Wizard in Exchange 2003 automates this process. You can use the same ADC for multiple sites. Consider installing multiple ADCs if you have large geographical separations or so many sites that you would overload a single ADC server.

ADC Mailbox Mapping

To build a mental picture of the way the ADC operates, it helps to understand the function of certain critical attributes that tell the ADC how to select objects and which e-mail parameters to copy between the objects.

Let's assume that you do an in-place upgrade of an NT4 domain to Active Directory. This transfers user account information from the PDC's SAM into Active Directory, including the users' original SIDs and passwords. As shown in Figure 12.2, a user's SID provides the initial link between the user's domain account and the user's legacy Exchange mailbox. Legacy Exchange stores this SID in the Primary Windows NT Account attribute. Active Directory stores the SID in an attribute called ObjectSID.

12fig02.gifFigure 12.2 Initial linkage of user object in Active Directory to legacy mailbox via user SID.SIDs (Security IDs)ADC mailbox mappingmigration from legacy ExchangeADCmailbox mappingADC (Active Directory Connector)migration from legacy Exchangemailbox mappingmailboxesADC mapping

Initial ADC Attribute Copy

When you configure a Recipient Connection Agreement, the ADC makes an LDAP connection between the two directory services and, for each recipient object in the legacy Exchange directory service, it reads the Primary Windows NT Account attribute and then searches for a user object in Active Directory with a matching ObjectSID attribute.

Once the ADC makes this match, it copies the e-mail attributes from legacy Exchange to the Active Directory object. Figure 12.3 shows a few of the copied attributes. An ADC Policy object in Active Directory determines which attributes to copy and maps the legacy Exchange attribute names to their Active Directory equivalents.

12fig03.gifFigure 12.3 Following initial ADC replication, e-mail attributes copied to Active Directory object and ADC-Global-Names created.legacy Exchange serversmigration to Exchange 2003ADC operations

ADC-Global-Names Attribute Creation

In addition to copying attributes from legacy Exchange, the ADC assigns a new attribute called ADC-Global-Names to the Active Directory object. This permits the ADC to store detailed matching information that simplifies subsequent searches and reduces the LDAP traffic required to perform object mapping. The initial content of the ADC-Global-Names attribute includes two elements:

  • EX5. This element contains the Distinguished Name and object class of the legacy Exchange object along with a timestamp of the last update and a set of flags that control the update methods used by the ADC.

  • Forest. This element contains the Distinguished Name of the Active Directory forest along with an update timestamp and some flags.

The next time the Connection Agreement runs, the ADC looks for User objects that have an ADC-Global-Names attribute, uses the EX5 element to locate the complementary object in legacy Exchange, and then replicates any updated e-mail attributes to the legacy object. This transaction also replicates the ADC-Global-Names attribute.

After this replication, as shown in Figure 12.4, the ADC then adds two elements to the legacy Exchange copy of ADC-Global-Names:

  • NT5. This element contains the Globally Unique Identifier (GUID) of the legacy Exchange organization along with an update timestamp and some flags.

  • FOREST. This element contains the GUID of the Configuration container in Active Directory along with an update timestamp and some flags.

12fig04.gifFigure 12.4 Following replication back to legacy Exchange, the ADC-Global-Names provides all mapping information needed to keep objects in sync.legacy Exchange serversmigration to Exchange 2003ADC operations

The next time the Connection Agreement runs, these new elements replicate from legacy Exchange to Active Directory. At this point, the ADC can match users to mailbox owners based solely on their ADC-Global-Names attributes and no longer needs their SIDs.

NT Account Migrations

Not all transitions from NT to Active Directory involve an in-place upgrade of the PDC, though. Many organizations create a pristine Active Directory domain and then use a utility such as the Active Directory Migration Tool (ADMT), or a third-party migration utility, to move user, group, and computer account information into the Active Directory domain.

Unlike an in-place upgrade, which retains the users' original domain SIDs, a migration creates new user accounts with new SIDs. It also saves the original NT domain SIDs into a special Active Directory attribute called SIDHistory.

When a user authenticates in the Active Directory domain, the SIDHistory value gets included in the user's access token. Essentially, this gives the user two account identities: the new Active Directory account, represented by the ObjectSID attribute, and the old NT account, represented by the SIDHistory attribute.

In a migration involving Exchange, first create the user accounts in Active Directory using the migration utility of your choice, and then install and run the ADC to populate these objects with e-mail attributes. As shown in Figure 12.5, the ADC starts off by matching a mailbox owner's SID with a SID stored in SIDHistory. Once the ADC completes this initial match and copies the e-mail attributes, it can then use ADC-Global-Names to permanently link the two objects.

12fig05.gifFigure 12.5 Migrated user maps to legacy Exchange mailbox via SIDHistory attribute.migration from legacy ExchangeADCNT domainsADC (Active Directory Connector)migration from legacy ExchangeNT domainsADMT (Active Directory Migration Tool)NT domainsmigration from legacy ExchangeNT domainsmigration from legacy Exchangelegacy Exchange serversmigration to Exchange 2003ADC operations

Invalid User Accounts

The ADC matching process might seem straightforward, but if you read between the lines, you'll see that the ADC makes a couple of critical assumptions:

  • Valid mailbox owner. Every mailbox in the legacy Exchange directory service has an owner that exists in Active Directory.

  • Unique mailbox owner. No two mailboxes have the same owner.

One or both of these assumptions might prove invalid in a production environment. For example, although it's unusual to have a mailbox with no owner, it's possible for someone to create a mailbox and deliberately not put an entry in the Primary Windows NT Account field. Or the mailbox owner might be assigned to a group, something not supported by Active Directory. Missing owners can also occur in domain migrations, where an NT account might not successfully copy to Active Directory for one reason or another. Keep in mind that a mailbox can be assigned only to a single user.

If a legacy mailbox owner does not exist as a user object in Active Directory, the ADC creates a disabled user object to represent the recipient. As shown in Figure 12.6, this disabled user object has no legacy NT domain SID, so the ADC creates an attribute called msExchangeMasterAccountSID and populates it with the user's legacy SID. It then uses this attribute as the initial match between the disabled user object and the legacy mailbox owner so it can populate the object with e-mail attributes and set up the ADC-Global-Names link.

12fig06.gifFigure 12.6 ADC creates a disabled user object when confronted with a legacy Exchange mailbox without a direct match in Active Directory.legacy Exchange serversmigration to Exchange 2003ADC operations

Don't Enable the Disabled User Objects

A disabled user object created by the ADC acts solely as a placeholder. It has no authentication functions. As shown in Figure 12.7, the disabled object has a scrambled logon name and no User Principal Name (UPN), indicating that it should not be used for logon purposes. (You can't see it in the user interface, but the account also gets a randomly generated complex password.)

12fig07.gifFigure 12.7 Disabled mailbox created by ADC not intended for authentication purposes. It's simply a placeholder for a resource mailbox.

If you do a thorough job of migrating user accounts from each NT domain to Active Directory, you should not see any disabled user accounts after installing the ADC. If you do get a disabled user account, don't simply change the logon name and enable the account. Determine why the legacy mailbox did not have a valid owner, correct the condition, and then delete the disabled user account and let the ADC find the correct object. Microsoft Knowledge-Base article 316047 discusses the various negative effects of enabling a disabled ADC placeholder account and offers several workarounds.

Multiple Mailbox Owners

Another common ADC matching issue involves so-called resource mailboxes. These mailboxes don't represent users. Instead, they represent conference rooms, projectors, audio equipment, laptop computers, and so forth. By creating mailboxes for these items, you can use the free/busy information in Outlook calendars to schedule access to the resources.

Resource mailboxes tend to have the same owner. For example, a single admin assistant in an office might own all the resource mailboxes for the conference rooms and audio-visual equipment. This presents a problem for the ADC, because Exchange 2003 permits users to have only one mailbox. You can resolve this problem using an ADC feature called NTDSNoMatch. Here's how it works.

Consider a user who has ownership of a primary mailbox and several resource mailboxes. The ADC Tools has a Resource Mailbox Wizard that looks for multiple mailboxes owned by the same user. It presents these mailboxes in a tree with the suggested primary mailbox shown in bold, as shown in Figure 12.8.

12fig08.gifFigure 12.8 Primary mailbox can be mapped to user account separately from resource mailboxes using Resource Mailbox Wizard in ADC Tools.mailboxesmultiple ownersResource Mailbox wizardmultiple mailbox owner

The wizard determines its candidate for the primary mailbox by matching the mailbox alias to the user name. If the wizard makes a mistake, you can highlight the actual primary mailbox and click Set as Primary. (The Resource Mailbox Wizard in the ADC Tools replaces the NTDSNoMatch utility described in Microsoft Knowledge-Base article 274173.)

The wizard takes the settings you configure in the tree and marks each resource mailbox by placing the word NTDSNoMatch in Custom Attribute 10 of the mailbox object in legacy Exchange. Figure 12.9 shows an example.

12fig09.gifFigure 12.9 Resource mailboxes marked with NTDSNoMatch entry in Custom Attribute 10 of legacy Exchange object.migration from legacy ExchangeADCinvalid user accountsADC (Active Directory Connector)migration from legacy Exchangeinvalid user accountsinvalid user accountsmigration from legacy Exchangeuser accountsmigration from legacy Exchangeinvalid accountslegacy Exchange serversmigration to Exchange 2003ADC operations

When the ADC runs the Recipient Connection Agreement the first time, it copies the e-mail attributes from the primary mailbox to the matching user object in Active Directory. It then creates disabled user accounts for each resource mailbox and places the original owner on the permission list for those mailboxes, so the original owner retains the ability to open the mailboxes, even though they are now owned by the disabled user accounts.

Active Directory Account Cleanup Wizard

If you should accidentally or deliberately use the ADC to create a set of disabled user accounts in Active Directory prior to migrating users from one or more legacy domains, you can recover full functionality in two stages.

  • First, migrate user accounts using ADMT or a third-party migration tool. Because the migrated accounts have actual logon names, not the scrambled logon names assigned by the ADC, the migration succeeds so long as you don't target the new user objects to the same container that holds the disabled user objects.

  • Second, use the Active Directory Account Cleanup Wizard that accompanies the ADC to merge the e-mail attributes from the disabled user objects to the actual user objects and then delete the disabled objects.

The AD Account Cleanup Wizard is installed along with Exchange 2003 and can be accessed via the Start menu using the path Start | All Programs | Microsoft Exchange | Deployment. Run the Active Directory Cleanup Wizard as follows:

  1. At the initial welcome screen, click Next. The Identify Merging Accounts window opens, as shown in Figure 12.10.

    12fig10.gifFigure 12.10 AD Cleanup Wizard showing Identify Merging Accounts window where you select a search container for the cleanup.migration from legacy ExchangeADCAD Account Cleanup wizardADC (Active Directory Connector)migration from legacy ExchangeAccount Cleanup wizarduser accountsmigration from legacy ExchangeAD Account Cleanup wizardAccount Cleanup wizard (Active Directory)migration from legacy Exchange

  2. Leave the Search Entire Directory or Selected Containers option selected along with the Search Based on Exchange Mailboxes Only.

  3. Click Next. After a period of searching, the Review Merging Accounts window opens to display the list of disabled accounts that match enabled accounts. Figure 12.11 shows an example.

    12fig11.gifFigure 12.11 Review Merging Accounts window gives side-by-side comparison of disabled user object and live user object.migration from legacy ExchangeADCAD Account Cleanup wizardADC (Active Directory Connector)migration from legacy ExchangeAccount Cleanup wizarduser accountsmigration from legacy ExchangeAD Account Cleanup wizardAccount Cleanup wizard (Active Directory)migration from legacy Exchange

  4. Click Next. The Begin Merging Accounts window opens, as shown in Figure 12.12.

    12fig12.gifFigure 12.12 Begin Merging Accounts window provides options to do the merge or save to a file.legacy Exchange serversmigration to Exchange 2003ADC operations

  5. Check the Begin the Merge Process Now box.

  6. Click Next to begin the merge. Acknowledge the warning that pops up.

  7. Once the merge has completed, a Summary window opens. If you see any errors, follow up by checking the Adclean.log file in the \Exchsrvr\bin folder.

Now check the Recipients folder that originally held the disabled user accounts and verify that the accounts have disappeared. You might need to press F5 to refresh the display. Check the Properties window of a user account to verify the presence of the Exchange tabs and that the Exchange information looks correct.

As a recap, you should not need to use the Active Directory Cleanup Wizard if you perform the migration steps in the proper order (migrate and then install the ADC.) If you have a few accounts that did not migrate the first time, you can use the Active Directory Cleanup Wizard to merge the e-mail attributes and avoid a remigration. You can also run Adclean.exe from the command line. The utility has several switches. See Microsoft Knowledge-Base article 270655 for details.

ADC and Distribution Lists

Exchange 2003 uses Distribution groups and Security groups in Active Directory to represent distribution lists. When the ADC encounters a distribution list in the legacy Exchange directory service, it creates a Universal Distribution Group in Active Directory.

The ADC creates Universal groups so that the members can get mail from any user in any domain in the forest. Universal group membership replicates in the Global Catalog so that membership expansion works correctly.

The ADC creates Distribution groups rather than Security groups just in case the target domain has not been upgraded to Windows 2000 Native functional level or higher. Distribution groups have an SID, but they cannot be used on Access Control Lists (ACLs) for security objects such as NTFS files and folders, Registry keys, and Active Directory objects. Creating Universal groups also avoids conflict with Windows administrators, who might not want a pile of new Security groups to appear in Active Directory following the e-mail migration.

Automatic Security Group Upgrades

Populating Active Directory with Universal Distribution Groups can lead to a problem, though. Legacy Exchange allows distribution lists to control access to resources such as public folders and user mailboxes.

In Exchange 2003, MAPI permissions on a public folder correspond to Access Control Entries (ACEs) on an ACL for the folder. Figure 12.13 shows a comparison of the MAPI permissions and ACEs for an example public folder. The example shows that a group called TucsonDistro1 appears on the MAPI permission list with the Author role, and that Exchange converts this to a set of ALLOW and DENY entries for two ACEs in the ACL for the folder.

12fig13.jpgFigure 12.13 MAPI role corresponds to a set of Allow and Deny permissions in standard Windows ACL.Security groupsmigration from legacy Exchange

It's this correlation of MAPI permissions to ACL entries that causes a problem when the ADC creates a Universal Distribution Group. If the distribution list represented by that group appears on the MAPI permissions of a public folder, then the Exchange 2003 Information Store can't create an Access Control Entry for the group to put on the ACL for the folder.

Exchange 2003 resolves this in the same way that your mother resolved arguments with you. It doesn't take no for an answer. If the Information Store sees that a Universal Distribution Group has been placed on the MAPI permissions for a public folder or user mailbox, it automatically promotes the group to a Universal Security Group and then puts the SID of the group in the ACL.

Distribution List Membership

When the ADC creates a new Universal Distribution Group, it populates the group with members based on the membership of the legacy Exchange distribution list.

For example, if the legacy Exchange directory service contains a distribution list called South Park that holds a recipient named Kenney, the ADC creates a Universal Distribution Group called South Park and links the group's Member attribute to the Kenney object.

If a distribution list contains an invalid recipient—for example, if someone deletes the Kenny object from Active Directory (the b#*$%ds)—the ADC would create a disabled user account to represent the recipient and then would create the Universal Distribution Group with a link between the Member attribute and the disabled account.

Subsequent changes to the group membership in Active Directory replicate to legacy Exchange as a change to the distribution list members.

If you permanently delete the newly created Kenny account from Active Directory and remove him from the membership of the South Park group, then the ADC removes him from the legacy distribution list, as well.

InformIT Promotional Mailings & Special Offers

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

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about 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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. 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.informit.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.

Links


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