Mapping unresolved users

To use a custom security configuration in a Data Archive collective, you must configure the Data Archive server to accept unresolvable security mappings during replication. The Data Archive server includes a lookup-failure tuning parameter that tells it to ignore unresolvable mappings during replication. (Collectives do not replicate tuning parameters.) With this tuning parameter enabled, you can create mappings on one collective member that other collective members cannot resolve, but replication between collective members will succeed.

For example, suppose the primary server is in the domain where you want to create mappings and you have a secondary server that is not part of that domain. If you create mappings on the primary server with domain accounts, the replication of these mappings will fail on the secondary server (because that domain does not exist for the secondary server). Replication will stop and the secondary server will fall out of synchronization. If you enable the tuning parameter on the secondary server, the server will accept the mappings and replication will succeed.

Similarly, suppose the primary server defines a mapping against a local Windows group. Because secondary servers do not know about that local group, the mappings will cause replication to fail. If you enable the tuning parameter on the secondary servers, they will accept the mappings and replication will succeed. In this case, you might also need to define mappings against local Windows groups on the secondary servers. Therefore, you must also enable the tuning parameter on the primary server.

Note: After you enable the lookup-failure tuning parameter, you must use the Windows Security ID (SID) of a group instead of the group name when you configure a mapping for a local Windows group, and because you cannot use PI SMT to create mappings based on SIDs, you must use piconfig.