Global Address List Synchronization Walkthrough: Administering the GAL Synchronization Infrastructure

Article
10/05/2010

Applies To: Windows Server 2003 with SP1

Previous Steps in This Walkthrough

Administering the GAL synchronization scenario involves synchronizing changes to Active Directory data by using MIIS 2003. In this section, you perform the following operations:

Hide a mailbox from the Exchange Address Book
Display a hidden mailbox in the Exchange Address Book
Delete an account
Delete a synchronized target contact
Delete a mailbox in a the source forest

Only source user objects that have the required attributes appear in the synchronized Contacts organizational unit. The following operation demonstrates what happens when the attributes of a source user object are changed to no longer meet the requirements.

Hide a Mailbox from the Exchange Address Book

At this stage in the walkthrough, all source accounts have been successfully synchronized and appear as contacts in the target domain because the original source accounts were mail-enabled. To demonstrate a source user account modification, hide a mailbox from the Exchange Address Book. This sets the msExchHideFromAddressList attribute to true, which causes the deletion of the corresponding contact in the target domain during the next GAL synchronization cycle.

To hide a mailbox from the Exchange Address Book

On the domain controller for the fabnoa Active Directory domain, in Active Directory Users and Computers, from the View menu, click Advanced Features.
In the Fabrikam organizational unit, choose any user in the Users organizational unit.
Right-click the user and click Properties, and then click the ExchangeAdvanced tab.
Select the Hide from Exchange address lists check box.
Click OK.
Next, run the delta import for the Fabrikam GALMA to import the change. During the synchronization (after the import has occurred) the imported change will cause the corresponding object in the Contoso GALMA connector space to be flagged for deletion. Once this happens, the next export run for the Contoso GALMA will cause the contact object to be deleted in the Connoa domain.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Delta Import run profile of the Fabrikam GALMA.
By running the delta import, you import the disabled user account. After the run is complete, examine the Synchronization Statistics. Under Inbound Synchronization, there is one Metaverse Object Deletes. This is the removal of the metaverse object that corresponds to the user account you just modified. Because the change you made hides the contact information from the address list, MIIS 2003 does not need to synchronize the object data and therefore removes it from the metaverse.
Notice the Outbound Synchronization statistics. There is one Provisioning Disconnect. Because provisioning is enabled, all connectors for this object in the Contoso GALMA connector space are removed by the provisioning rules extension logic. This results in the object stored in the Contoso connector space being flagged for deletion during the next export operation. If you were to run an Export run profile on the Contoso GALMA to push out the deletion, one delete operation would be reported in the export statistics. Then, if you were to run a Delta Import on the Contoso GALMA, the delete operation would be imported into MIIS 2003 again and confirmed. Perform an export and a delta import by using the Contoso GALMA.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Export run profile on the Contoso GALMA.
On the domain controller for the connoa Active Directory domain, in Active Directory Users and Computers, verify the content of the synchronized contact in the Contacts organizational unit in the Fabrikam organizational unit.
Note The corresponding contact for the user you modified should be deleted in the Fabrikam organizational unit.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run a Delta Import on the Contoso GALMA. This imports the delete operation into MIIS 2003 again.

Display a Hidden Mailbox in the Exchange Address Book

Now that you synchronized the hidden mailbox in the Exchange Address Book, you will reverse this setting and synchronize the change.

To display a hidden mailbox in the Exchange address book

On the domain controller for the fabnoa Active Directory domain, in Active Directory Users and Computers, right-click the user whose mailbox was hidden in the previous procedure.
Click Properties and then click the Exchange Advanced tab.
Clear the Hide from Exchange Address lists check box.
Click OK.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Delta Import run profile of the of the Fabrikam GALMA.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Export run profile on the Contoso GALMA.
On the domain controller for the fabnoa Active Directory domain, in Active Directory Users and Computers, verify the content of the synchronized contact in the Contacts organizational unit in the Fabrikam organizational unit. The corresponding contact should be re-created in the Connoa domain.
As a last step, run a Delta Import on the Contoso GALMA. This will re-import the add operation into MIIS 2003.

If the source object is hidden or displayed in the Exchange Address Book, a direct import and export attribute flow rule sequence also hides or displays the synchronized contact.

Delete a User Account

To demonstrate the two-way synchronization of the GAL synchronization scenario, the following operation shows how a contact in the target Active Directory data source is deleted when the associated object in the source Active Directory data source is deleted. In this example, a user account from the Fabrikam forest is deleted and MIIS 2003 removes the corresponding contact in the Contoso forest.

To demonstrate the results of a target source account deletion

On the domain controller for the fabnoa Active Directory domain, in Active Directory Users and Computers, select the user account for fabuser01.
Right-click the user account and then click Delete. Allow Active Directory to delete the mailbox also.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run a Delta Import run profile on the Fabrikam GALMA.
Next, run the Export run profile on the Contoso GALMA.
The export statistics should report one delete operation and the contact should be deleted in the connoa domain. Verify the removal of the contact from the Fabrikam organizational unit in the Connoa domain.
Run a Delta Import on the Contoso GALMA. This imports the delete operation into MIIS 2003 again.

Delete a Synchronized Contact in the Target Forest

When a synchronized Contact is deleted in the target forest organizational unit, MIIS 2003 synchronization creates it again. To demonstrate this event, you delete a contact in the Contoso organizational unit of the fabnoa domain, and then synchronize the GAL synchronization infrastructure to create the object again.

To demonstrate a synchronized contact deletion and recreation

On the domain controller for the fabnoa Active Directory domain, in Active Directory Users and Computers, delete the contact conuser02 from the synchronized Contacts organizational unit in the Contoso organizational unit.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Delta Import run profile on the Fabrikam GALMA. Verify that one delete appears in the import statistics. If you examine the object details, you see that it is the user contact, conuser02, which you just deleted.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Full Synchronization run profile on the Fabrikam GALMA. Examine the Outbound Synchronization statistics. Verify that export attribute flow and provisioning are occurring for the conuser02 object.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Export run profile on the Fabrikam GALMA. Examine the Outbound Synchronization statistics. Verify that one add takes place for the conuser02 object.
On the domain controller for the fabnoa Active Directory domain, in Active Directory Users and Computers, verify that the conuser02 contact has been created again in the Contoso organizational unit.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Delta Import run profile on the Fabrikam GALMA.
This imports the add operation into MIIS 2003 so it can confirm the export was successful.

Delete a Mailbox in the Source Forest

When a mailbox in the source forest is deleted and synchronization is run, the corresponding contact in the target forest is deleted.

To delete a mailbox in a source forest

On the domain controller for the fabnoa Active Directory domain, in Active Directory Users and Computers, select fabuser04 from the Users organizational unit in the Fabrikam organizational unit.
Right-click the user and click Exchange Tasks.
Click Delete the Mailbox and confirm the deletion (Click Next, click Next again to confirm deletion and then click Finish).
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Delta Import run profile on the Fabrikam GALMA. Verify that there is one update.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run the Export run profile on the Contoso GALMA. Confirm that there is one delete.
On the domain controller for the connoa Active Directory domain, in Active Directory Users and Computers, verify the contact for fabuser04 has been removed from the Contacts organizational unit in the Fabrikam organizational unit in the connoa domain. You may need to refresh the view to see the update.
On the domain controller for the connoa Active Directory domain, in Identity Manager, run a Delta Import on the Contoso GALMA.

Optional: Configure GALSync for Live Communications Server

This optional section is intended for customers who want to deploy Live Communications Server 2005 with Service Pack 1 (SP1) in a multiforest environment with Exchange deployed across forests or hybrid topology using MIIS GALSync. For a multiforest environment, Live Communications Server 2005 with SP1 is required to be deployed in a central forest topology. This means you need to select one of the forests to act as the central forest of your Live Communications Server 2005 with SP1 environment. For more information about this topology, refer to the Live Communications Server 2005 Deployment Resources.

In order for Live Communications Server 2005 with SP1 to function in a multiforest environment, users in one forest must be able to see the contact information for users in the other forests. This means that every user in a non-central forest must have their contact information created as a contact object in the central forest and those contact objects must be added to the GAL in the central forest.

In an Active Directory environment where Exchange is deployed, MIIS 2003 can be used to perform GAL synchronization between the forests to synchronize the contact information. This makes the contact information from one forest available to the users in the other forests.

The MIIS GAL synchronization solution was originally designed to synchronize contact information for use by Exchange and its clients. However, the same contact information is also used by Live Communications Server 2005 with SP1, so GAL synchronization can also be used as a solution for synchronizing contact information for Live Communications Server 2005 with SP1.

To use the MIIS 2003 management agent for Active Directory GAL to synchronize the contact information for Live Communications Server 2005 with SP1, you must be running Microsoft Identity Integration Server 2003 Enterprise Edition with Service Pack 1 or the Identity Integration Feature Pack (IIFP) 1a. This is because the management agent for Active Directory GAL in MIIS 2003 SP1 and IIFP 1a has been updated to synchronize the additional attributes needed by Live Communications Server 2005 with SP1. In addition to the new attributes synchronized by GAL synchronization in MIIS 2003 SP1, five additional Active Directory attributes require manual configuration for use by Live Communications Server 2005 with SP1.

Configuration Requirements

To implement the optional Live Communications Server 2005 with SP1 configuration presented in this section, you need to add support for Live Communications Server 2005 with SP1 to your testing environment. In addition to the setup procedures covered in Appendix A: Gal Sync Lab Setup and Requirements, the following additional configuration must be made before continuing with the procedures in this section:

Set up a server running Live Communications Server 2005 with SP1 and two clients in the Contoso forest. Instructions can be found in "Lab Scenario 1: Deploying a Live Communications Server and Enabling Client Access" in the Live Communications Server 2005 Standard Edition Lab Quick Start found at the Live Communications Server 2005 Deployment Resources Web site.

You also have the option of using Live Communications Server 2005 with SP1 Enterprise Edition for this exercise. If you choose to use the Enterprise Edition instead of the Standard Edition, make sure you use the Live Communications Server 2005 Enterprise Edition Lab Quick Start, found at the same location, for the additional configuration instructions.

Important

The GAL synchronization procedures presented earlier in this walkthrough must be completed before proceeding with the optional Live Communications Server 2005 with SP1 section. The procedures in the Live Communications Server 2005 with SP1 section assume the GAL synchronization procedures are complete.

Implementing the LCS Configuration

To add support for Live Communications Server 2005 with SP1to the GAL synchronization deployment you already have in place, perform the following steps:

Select which forest will act as the central forest for Live Communications Server 2005 with SP1.
Extend the Active Directory schema in the central forest.
Configure one-way, outgoing trusts from the central forest to every other forest.
Configure the management agent for the central forest.
Configure the management agents for the non-central forests.
Synchronize the Live Communications Attributes.

Select the Central Forest

In a Live Communications Server 2005 with SP1 deployment, one forest must be selected to act as the central forest. The central forest requires some additional configuration and is the forest that hosts the server running Live Communications Server 2005 with SP1. The configuration requirements listed earlier state that the server running Live Communications Server 2005 with SP1 should be installed in the Contoso forest. Therefore, the Contoso forest will act as the central forest for the purposes of this walkthrough. If you have elected to use your own forest design instead of the example provided in this walkthrough (Contoso and Fabrikam), you need to choose the forest that will act as your central forest and install the server running Live Communications Server 2005 with SP1 in that forest before you continue. For information about installing and configuring Live Communication Server, see the Live Communications Server 2005 Deployment Resources Web site.

Extend Metaverse Schema

Live Communications Server 2005 with SP1 uses the same contact information stored in the global address list that is used by Exchange and its clients. In addition to this information, Live Communications Server 2005 with SP1 requires the data stored in five additional attributes:

OtherMobile
OtherPager
IpPhone
msRTCSIP-OriginatorSid
msRTCSIP-PrimaryUserAddress

The MIIS 2003 metaverse schema must be extended to add support for these attributes.

To extend the metaverse schema

Click Metaverse Designer.
Click person in the Object types pane.
Click Add Attribute in the Actions pane.
Click New Attribute button.
Enter msRTCSIP-OriginatorSid in the Attribute name: field.
Select Binary (indexable) in the Attribute type: drop-down field.
Verify the Multi-valued and Indexed check boxes are not selected.
Click OK.
Click Add Attribute.
Click the New Attribute button.
Enter msRTCSIP-PrimaryUserAddress in the Attribute name: field.
Select String (indexable) in the Attribute type: drop-down field.
Verify the Multi-valued and Indexed check boxes are not selected.
Click OK.
Click Add Attribute.
Click the New Attribute button.
Enter ipPhone in the Attribute name: field.
Select String (indexable) in the Attribute type: drop-down field.
Verify the Multi-valued and Indexed check boxes are not selected.
Click New Attribute.
Click the New Attribute button.
Enter otherMobile in the Attribute name: field.
Select String (indexable) in the Attribute type: drop-down field.
Verify the Multi-valued and Indexed check boxes are not selected.
Click New Attribute.
Click the New Attribute button.
Enter otherPager in the Attribute name: field.
Select String (indexable) in the Attribute type: drop-down field.
Verify the Multi-valued and Indexed check boxes are not selected.
Click OK.
Click OK.

After extending the metaverse schema, you must refresh the central forest’s metaverse schema:

To refresh the metaverse schema of the central forest

Right-click the central forest management agent (Contoso).
Click Refresh Schema…
Click OK.
Enter Enterprise Admin credentials for the central forest.
Click OK.
Click Close once the schema has refreshed.

Configure a One-way trust from the Central Forest

Live Communications Server 2005 with SP1 requires a one-way, incoming trust between the central forest and any other forest whose users will be connecting to the server running Live Communications Server 2005 with SP1. This is necessary so the server running Live Communications Server 2005 with SP1 can validate user credentials when the user attempts to connect to the server regardless of which forest the user is connecting from. The trust needs to be one-way from the central forest to the other forest.

Note

MIIS does not require any trusts to synchronize information across different forests. This trust is only required if Live Communications Server 2005 with SP1 is being deployed for users across multiple forests.

To establish a one-way trust from the central forest

Logon to CONNOA-DC-01 as a member of the Enterprise Admins group in the Contoso forest.
Open Active Directory Domains and Trusts.
Right-click connoa.concorp.contoso.com and choose Properties.
Click the Trusts tab and click New Trust….
The New Trust wizard opens. Click Next.
Enter fabnoa.fabcorp.fabrikam.com as the Trust Name. Click Next.
Select One-way outgoing as the Direction of Trust. Click Next.
On the Sides of Trust page, select This domain only. Click Next.
On the Outgoing Trust Authentication Level page, select Domain-wide authentication. Click Next.
Enter a strong password for the Trust Password. Confirm the password by entering it a second time. Click Next.
Review the summary information to make sure the options are correct and click Next.
Click Next to create the trust.
When asked to confirm the outgoing trust select No, do not confirm the outgoing trust. Click Next.
Click Finish. Click OK to close the SID Filtering dialog box if it appears.
Click OK to close the Properties dialog.
Logon to FABNOA-DC-01 as a member of the Enterprise Admins group in the Fabrikam forest.
Open Active Directory Domains and Trusts.
Right-click fabnoa.fabcorp.fabrikam.com and choose Properties.
Click the Trusts tab and click New Trust….
The New Trust wizard opens. Click Next.
Enter connoa.concorp.contoso.com as the Trust Name. Click Next.
Select One-way incoming as the Direction of Trust. Click Next.
On the Sides of Trust page, select This domain only. Click Next.
On the Outgoing Trust Authentication Level page, select Domain-wide authentication. Click Next.
Enter a strong password for the Trust Password. Use the same password that you entered in step 10 above. Confirm the password by entering it a second time. Click Next.
Click Next to create the trust.
When asked to confirm the incoming trust, select Yes, confirm the incoming trust. Enter the user name and password of the administrator account from the Contoso forest that was used for steps 1-15. Click Next.
Click Finish.
Click OK to close the Properties dialog.

Configure the Management Agent for the Central Forest

Some changes need to be made to the configuration of the central forest's management agent so it can use the two new attributes you added to the schema.

To configure the management agent for the central forest

Click Management Agents.
Select the management agent for the central forest (Contoso).
Select Properties in the Actions pane.
Click Select Attributes in the Management Agent Designer list.
Click Show All.
Find and select msRTCSIP-OriginatorSid.
Find and select msRTCSIP-PrimaryUserAddress.
Find and select ipPhone.
Find and select otherMobile.
Find and select otherPager.
Click Configure Attribute Flow in the Management Agent Designer list.
Expand the node that has Object Type: contact in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Under Build Attribute Flow, select msRTCSIP-OriginatorSid in the Data sourceattribute.
Select the Export option button in the Flow Direction section.
Select the option to Allow Nulls.
Select the Direct option button in the Mapping Type section.
Select msRTCSIP-OriginatorSid in the Metaverse attribute: list.
Click New.
Select msRTCSIP-PrimaryUserAddress in the Data source attribute: list of the Build Attribute Flow section.
Select the Import option button in the Flow Direction section.
Select the Direct option button in the Mapping Type section.
Select msRTCSIP-PrimaryUserAddress in the Metaverse attribute: list.
Click New.
Expand the node that has Object Type: contact in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Under Build Attribute Flow, select ipPhone in the Data sourceattribute.
Select the Export option button in the Flow Direction section.
Select the option to Allow Nulls.
Select the Direct option button in the Mapping Type section.
Select ipPhone in the Metaverse attribute: list.
Click New.
Expand the node that has Object Type: contact in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Under Build Attribute Flow, select otherMobile in the Data sourceattribute.
Select the Export option button in the Flow Direction section.
Select the option to Allow Nulls.
Select the Direct option button in the Mapping Type section.
Select otherMobile in the Metaverse attribute: list.
Click New.
Expand the node that has Object Type: contact in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Under Build Attribute Flow, select otherPager in the Data sourceattribute.
Select the Export option button in the Flow Direction section.
Select the option to Allow Nulls.
Select the Direct option button in the Mapping Type section.
Select otherPager in the Metaverse attribute: list.
Click New.
Click OK.

Configure Management Agent for the Non-Central Forests

The management agents for any other forests that are included in the Live Communications Server 2005 with SP1 deployment need to be updated also. Perform the following steps for the other forest management agents:

To configure the management agents for the non-central forests

Click Management Agents.
Select the management agent for a non-central forest.
Select Properties in the Actions pane.
Click Select Attributes in the Management Agent Designer list.
Click Show All.
Find and select objectSid.
Find and select ipPhone.
Find and select otherMobile.
Find and select otherPager.
Click Configure Attribute Flow in the Management Agent Designer list.
Expand the node that has Object Type: user in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Under Build Attribute Flow, select objectSid in the Data source attribute: list.
Select the Import option button in the Flow Direction section.
Select Direct in the Mapping Type section.
Select msRTCSIP-OriginatorSid in the Metaverse attribute list.
Click New.
In the Configure Attribute Flow table, make sure the node that has Object Type: user in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column is selected.
Click the row that shows proxyAddresses selected in the Data source attribute: column and legacyExchangeDN selected in the Metaverse attribute: column.
Verify Flow Direction is set to Export.
Under Build Attribute Flow, while holding the CTRL key, click msRTCSIP-PrimaryUserAddress attribute in the Metaverse attribute list in order to multiselect.
Click Edit.
Replace the string ProxyAddressesMappingBackwards with LcsProxyAddressesMappingBackwards in the Flow rule name: field.
Click OK.
In the Configure Attribute Flow table, expand the node that has Object Type: contact in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Click the row that shows proxyAddresses selected in the Data Source Attribute column, legacyExchangeDN and proxyAddresses selected in the Metaverse attribute: column
Under Build Attribute Flow, while holding the CTRL key, click msRTCSIP-PrimaryUserAddress attribute in the Metaverse attribute list in order to multiselect.
Click Edit
Replace the string ProxyAddressesMappingForwards with LcsProxyAddressesMappingForwards in the Flow rule name: field.
Click OK.
Expand the node that has Object Type: user in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Under Build Attribute Flow, select ipPhone in the Data source attribute: list.
Select the Import option button in the Flow Direction section.
Select Direct in the Mapping Type section.
Select ipPhone in the Metaverse attribute list.
Click New.
Expand the node that has Object Type: user in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Under Build Attribute Flow, select otherMobile in the Data source attribute: list.
Select the Import option button in the Flow Direction section.
Select Direct in the Mapping Type section.
Select otherMobile in the Metaverse attribute list.
Click New.
Expand the node that has Object Type: user in the Data Source Attribute column and Object Type: person in the Metaverse Attribute column of the Configure Attribute Flow table.
Under Build Attribute Flow, select otherPager in the Data source attribute: list.
Select the Import option button in the Flow Direction section.
Select Direct in the Mapping Type section.
Select otherPager in the Metaverse attribute list.
Click New.
Click OK.
Repeat all steps for each non-central forest management agent.

Synchronize the Live Communications Attributes

Once the above management agent configurations are completed, import run profiles must be run on all management agents to import the Active Directory data of all forests into their respective connector space. Synchronization then imports the new information into the metaverse and provisions the updates to the connector space so the new data can be exported to the central forest. Finally, the export run profile is run to export the provisioned contact objects representing users from the different non-central forests to the central forest.

To import and synchronize the new contact data

For each forest that is part of the Live Communications Server 2005 with SP1 deployment:
1. Select the forest management agent under Management Agents.
2. Right-click the management agent and select Run…
3. Select Full Import (Stage Only).
4. Click OK.
5. After you have performed the import on each forest, the next step is synchronization. Once again, these steps need to be performed on each forest.
6. Select the forest management agent under Management Agents.
7. Right-click the management agent.
8. Select Run…
9. Select Full Synchronization.
10. Click OK.

To export the contact information to the central forest

Select the central forest management agent under Management Agents
Right-click the management agent
Select Run…
Select Export
Click OK

Verifying Successful Synchronization

To test whether or not the necessary contact information was successfully synchronized between the two forests, sign on to a Windows Messenger 5.1 client in the Contoso forest on CONNOA-DC-01 by using a user account from the Contoso forest. Then, sign on to a Windows Messenger 5.1 client on FABNOA-DC-01 by using a user account from the Fabrikam forest.

If the contact information was successfully synchronized across the forests, each user should be able to add the other user's contact information to their contact list in Windows Messenger. By clicking on the contact's name, they can establish a messaging sessions and should be able to chat back and forth.

All the information you need to set up a server running Live Communications Server 2005 with SP1 and the Windows Messaging clients for this test can be found in the Live Communications Server 2005 Standard Edition Lab Quick Start (or the Live Communications Server 2005 Enterprise Edition Lab Quick Start if you only have access to the Enterprise Edition) located at the Live Communications Server 2005 Deployment Resources Web site.

To test that synchronization has worked correctly without configuring Live Communications Server 2005 with SP1 and using Windows Messenger, a tool such as ADSIEDIT or LDP can also be used to lookup and confirm the extra attributes have been added to the contact objects in the central forest.

Summary

You have just completed a rudimentary implementation of GAL synchronization by using MIIS 2003. You started with two forests each hosting their own Exchange GAL and you used the management agent for Active Directory global address list (GAL) to synchronize the global address lists between the two forests. After the initial synchronization, you performed some rudimentary administrative tasks and then observed how MIIS 2003 synchronized the changes you made. You hid a mailbox on one forest and then observed how the contact information for that mailbox was removed from the GAL in the other forest. You deleted a user in one forest and saw the contact object for that user removed from the contact list in the other forest. You also attempted to remove a contact from the remote forest’s contact list and observed how synchronization caused the contact to be replaced.

You also had the option of configuring five additional attributes needed for use by LCS 2005 SP1. These attributes make it possible for users in one forest to see the contact information for users in another forest. This exercise demonstrated how to use the GALSync management agent to synchronize this contact information for use by LCS 2005 SP1.