サポートと今すぐチャット
サポートとのチャット

Collaboration Services 3.10.1 - Deployment Guide

About this document About Collaboration Services Architecture and functionality Before you begin Platform considerations Pre-installation planning Prepare for use Collaboration Services upgrade Installation checklists Re-installing Collaboration Services Troubleshooting

Conflicting email addresses

When Collaboration Services creates a stub object, it verifies that no other object with the same address exists in the forest by querying the nearest Global Catalog. If the object already exists, Collaboration Services can take any of the following actions:

•
Delete the conflicting object and create a stub object.
This method works for forests that have contact objects corresponding to another forest’s users or distribution groups. Deletion is the most straight-forward and recommended method to resolve conflicts, since it is the only option that can resolve conflicts between objects of different classes (for example, user and contact).
* 
NOTE: This method will be applied only to objects located in the organizational units (OUs) you specify.
•
Match the new object into the existing one.
This method works only if both the stub object being created and the conflicting object are of the same class (for example, both are users).
In this method, the existing object is used as a stub for the duration of synchronization. The difference between this type of stub object and a regular stub object is that the object keeps its account state unchanged; for example, if the account was enabled, it remains enabled after Collaboration Services makes a stub of it.
* 
NOTE: This method will be applied only to objects located in the OUs you specify, and to objects for which pre-matching rules were created.
•
If Collaboration Services cannot resolve the conflict for a particular object automatically using the current settings, then the object is placed in the Non-Applied Objects queue, from which you can resolve the conflict by either approving the suggested action or configuring another action manually.
For example, a user can have active user accounts with the same email address in two or more forests. This probably means that user needs to access resources in both forests. If so, it is recommended not to delete the conflicting objects but to use matching. In this case, active accounts can be used as stubs, so the users will still be able to log on in multiple forests with Collaboration Services deployed.

When configuring the matching, you can choose the attribute synchronization direction on a per-attribute basis, so some or all attributes are synchronized from the published object to the object you are matching into. Attribute synchronization is useful if the user account is updated by the provisioning system in one of the forests and these changes need to be propagated to the same user’s accounts in other forests.

Figure 6. Attribute synchronization

If you have active user accounts of the same user in multiple forests but do not want to use matching for some reason, you can do one of the following:

•
Exclude these accounts from Collaboration Services synchronization; since the user is represented in both Exchange organizations’ global address lists (GALs).
•
Delete the Exchange mailbox for all but one of the accounts. These accounts will still be enabled and used to access resources. Collaboration Services will create disabled stub user accounts for Exchange collaboration.

Other conflicts

There can be other conflicts that are not detected and resolved by Collaboration Services automatically because the conflicting objects do not cause technical issues, but can confuse the end users. Examples include:

•
Accounts that have different email addresses but correspond to the same user. If these accounts are synchronized, the GAL will have two entries for the same user.
•
Namesakes in different forests. If user accounts with the same name are synchronized, two different users will appear in the GAL with the same name. You can use a Collaboration Services suffix mapper to add text descriptions to the stub objects’ display names to help avoid confusion.

Step 3: Plan Collaboration Services configuration

Choose the HQ forest

After you decide how conflicts will be resolved in each forest, you can plan the Collaboration Services configuration. The main decision will be which forest should serve as the headquarters (HQ) for Collaboration Services synchronization. Only one HQ forest can be set up in a Collaboration Services environment.

* 
NOTE: The HQ forest role cannot be granted to any other forest after Collaboration Services has been deployed. To change the HQ forest, you will need to go through the deployment process again.

Consider the following criteria when selecting the HQ forest:

Synchronization performance considerations

To increase synchronization performance and reduce network traffic and HQ server load, choose the forest containing the most data to be synchronized.

Hardware considerations

The HQ forest processes all synchronized data from all synchronization partners. Therefore, there is a higher data processing load on the HQ Collaboration Services server, which means higher hardware requirements.

Support considerations

The HQ forest administrator will be a key person to help other partners in tuning performance and troubleshooting problems for the whole Collaboration Services structure.

Object selection

You must also consider how you will form object collections. This decision may require additional environment preparation. Collaboration Services allows both explicit and dynamic object selection.

Dynamic object selection may be based on the following:

•
Active Directory OU structure
If all the objects to be synchronized from a forest reside within the same OU or a few OUs, you can specify which types of objects should be synchronized from these OUs. This is the recommended method of object selection.
•
LDAP filters
Use filters to narrow the scope of objects that belong to a collection. This option is available only if you organize your collection on a per-container basis. If you plan to use LDAP filters for object selection, create and test the filters in advance. You can use any utility that can perform LDAP searches to test a filter, such as Ldp.exe or Csvde.exe.
•
Groups
User accounts and contacts that are members of a group can be published along with the group.
* 
NOTE: The nested groups and their members will not be published.
Mappers

Decide if you need mappers to customize Collaboration Services synchronization. For example, consider using mappers if:

•
Different forests use different naming standards. A mapper can be used to create stub objects according to a forest’s naming standards.
•
You would like to add a description to the stub objects’ display names.
* 
NOTE: Most mappers can be used by both the administrator who publishes collection and the administrator who subscribes to it.

Choose the HQ forest

Step 3: Plan Collaboration Services configuration

After you decide how conflicts will be resolved in each forest, you can plan the Collaboration Services configuration. The main decision will be which forest should serve as the headquarters (HQ) for Collaboration Services synchronization. Only one HQ forest can be set up in a Collaboration Services environment.

* 
NOTE: The HQ forest role cannot be granted to any other forest after Collaboration Services has been deployed. To change the HQ forest, you will need to go through the deployment process again.

Consider the following criteria when selecting the HQ forest:

Synchronization performance considerations

To increase synchronization performance and reduce network traffic and HQ server load, choose the forest containing the most data to be synchronized.

Hardware considerations

The HQ forest processes all synchronized data from all synchronization partners. Therefore, there is a higher data processing load on the HQ Collaboration Services server, which means higher hardware requirements.

Support considerations

The HQ forest administrator will be a key person to help other partners in tuning performance and troubleshooting problems for the whole Collaboration Services structure.

Object selection

You must also consider how you will form object collections. This decision may require additional environment preparation. Collaboration Services allows both explicit and dynamic object selection.

Dynamic object selection may be based on the following:

•
Active Directory OU structure
If all the objects to be synchronized from a forest reside within the same OU or a few OUs, you can specify which types of objects should be synchronized from these OUs. This is the recommended method of object selection.
•
LDAP filters
Use filters to narrow the scope of objects that belong to a collection. This option is available only if you organize your collection on a per-container basis. If you plan to use LDAP filters for object selection, create and test the filters in advance. You can use any utility that can perform LDAP searches to test a filter, such as Ldp.exe or Csvde.exe.
•
Groups
User accounts and contacts that are members of a group can be published along with the group.
* 
NOTE: The nested groups and their members will not be published.
Mappers

Decide if you need mappers to customize Collaboration Services synchronization. For example, consider using mappers if:

•
Different forests use different naming standards. A mapper can be used to create stub objects according to a forest’s naming standards.
•
You would like to add a description to the stub objects’ display names.
* 
NOTE: Most mappers can be used by both the administrator who publishes collection and the administrator who subscribes to it.
関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択