Running protectvob on identities-preserving replicas

1. Stop synchronization among identities-preserving replicas in the family. Make sure that all update packets have been imported.
2. Run the protectvob command on all identities-preserving VOB replicas in the family. You must use the same options and arguments in each command.
3. Restart synchronization.

If you do not change the owner or group at all identities-preserving VOB replicas at the same time, metadata divergence can occur for the owner or group of new elements created at nonpreserving replicas. When the oplog entry for the new element is imported at an identities-preserving replica, the element’s owner or group is the owner or group of the VOB at the time the entry is imported. If a change to the VOB owner or group has been made at other identities-preserving replicas, the element’s owner or group will be different at the different replicas.

If you do not add a group to all identities-preserving VOB replicas at the same time, synchronization failures can occur for elements with the new group. The failures occur during import at the replicas where the group was not added.

When you remove a group from the group list of a VOB replica, the group cannot be used for new elements created in the VOB, but existing elements with that group are not changed. (To find these elements, use the find command with the –group option.) If you do not remove the group from all identities-preserving replicas at the same time, synchronization import failures can occur for new elements created with the deleted group. (You can fix the synchronization failure by running protectvob –add_group on the importing VOB replica.) An alternative to using protectvob –delete_group is to leave the group in the VOB’s group list and create a trigger that checks the primary group of the user and prevents creation of the element if the user’s primary group is one of the obsolete groups.