-
标题
How does Quest Collaboration Services select the Target Address Attribute for Stub Objects. -
说明
This article describes how Quest Collaboration Services (QCS) selects the target address attribute for stub objects.
-
解决办法
For each original object, Collaboration Services creates a stub object in the forests that subscribe to the collection. To choose the redirection address, Collaboration Services retrieves the particular object's primary or secondary SMTP addresses while publishing an object and checks which of the specified Namespaces (starting from topmost Namespaces in the list) matches the retrieved objects SMTP addresses. The first matching proxy address will be selected as the redirection address for the current object. If none of the retrieved addresses is encountered in the specified Namespaces, a stub object will not be created. The Namespaces page of the Collaboration Services Properties dialog box allows you to add new Namespaces or edit existing Namespaces if your policy has changed since Collaboration Services setup.
The above Logic is further explained here:· If the published object’s targetAddress attribute is populated, then it will be used. This logical step can be omitted / skipped with the Registry on the QCS machine, creating a DWORD called "DontCopyTargetAddress" Value of 1, in HKLM\Software\wow6432node\Aelita\AelitaCollaborationServices
· If the targetAddress attribute is not available, then the primary SMTP address is used as long as it’s present anywhere on the Namespaces regardless of the order.
· If redirection address is not yet identified by this point, then it will be set to the secondary proxy address matching to the topmost address on the Namespaces page of the publisher’s side. The namespaces listed there are in priority order.
· If none of the secondary proxy addresses were encountered in the specified Namespace list, no stub object will be created.
Important: Please note that this default behavior does not apply if you use mappers. For example when using User to Contact or Group to Contact Mapper it just copies almost all attributes of inbound synchronizing object. As a result, it always puts primary SMTP address of the original user into contacts "TargetAddress" attribute ignoring options provided under Namespaces. This logic is by design and can not be changed.
-
缺陷ID
TF00164740 -
其他信息
A good way to test if you do not want to add a TargetAddress to the Source and want to keep the Primary SMTP Address just as it is yet set the TargetAddress on the Stub:Lets say you have two namespaces:
- company.com
- yourwanted.namespace.comYourwanted.namespace is the one you wish to have as the targetaddress on the Stub.
1. You need to remove the Primary SMTP Addresses namespace from the Active Directory Namespaces list in QCS (Active Directory | Namespaces) on the Publisher side where the Source Object is.
2. Add the yourwanted.namespace.com SMTP namespace to the namespaces list in QCS (Active Directory | Namespaces)
3. Set yourwanted.namespace.com Email address as the Secondary SMTP address on the Source Object (keeping company.com as the Primary SMTP Address).
4. Then publish the source object in a Publication, (Optional to use a User to Contact Mapper) QCS will first look and see if the Primary SMTP namespace on the object is in the QCS Namespaces list.
5. If the Primary SMTP namespace exists, QCS will automatically use the Primary SMTP namespace since it found a match in the namespace list, regardless of the order.
6. If the primary SMTP Namespace (company.com) is removed, QCS will look at what the Secondary SMTP address Namespace is on the Source Object, then look at the QCS Namespace list in QCS, and use the Secondary SMTP addresses namespace as the TargetAddress on the Stub AD Contact Object created on the Subscriber side.