QCS (Quest Collaboration Services) Namespaces logic

The documented QCS logic of how it picks redirection address on the stub objects may use some additional clarification so I am going to share it here per my QCS 3.7 – based LAB testing.

To choose the redirection address (targetAddress) on stub object, Collaboration Services does the following:

 ·        If the published object’s targetAddress attribute is populated, then it will be used. This logical step can be omitted / skipped with the latest hotfix 3.7.0.074 and registry setting “DontCopyTargetAddress“, see additional hotfix documentation. For QCS 3.8 it’s already integrated and no hotfix is needed.

 ·        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.

 NOTE:

This default logic does not apply to the “User-to-Contact” mapper set on the publication’s or subscription’s side in which case Primary SMTP Address will be always used as the redirection address on the stub Contact with the exception that still no stub object will be created if none of the proxyAddresses match the Namespaces list (in this case no object will be sent by the publisher). To change QCS mapper’s logic so that it obeys the Namespaces list, there is a custom DLL ACSStdMappers.dll which may be requested from the Quest product team. Please note however that such “out of the box” product behavior modifications are considered as custom dev solutions which involve additional costs.