Previous Topic: Post-Upgrade Cleanup Operations

Next Topic: Database Changes Are Replicated to Child Machines

Group History Cleanup Operations

Important! Because of the sequential way in which this cleanup operation is rolled out across your machine hierarchy, it is essential that you upgrade your CMS before you upgrade your gateways.

A CA DLP user can only belong to one user group at a time. But rare instances have been identified where a user simultaneously belonged to multiple groups. This problem is fixed in the current CA DLP release.

Previously, the constraint on group membership was enforced (imperfectly) by the CA DLP infrastructure; in the current version, it is enforced in the CMS database. Consequently, when you upgrade your CMS, a database cleanup operation eliminates any schema violations.

Such violations are rare and the cleanup operation will not normally need to take any action. But if it does detect user accounts with a corrupt group history, it takes the following steps:

Type 1 Cleanup

Where possible, the cleanup operation simply retains the user’s newest group membership (the group they joined most recently), and deletes any other current group memberships. The user’s remaining group history (the groups they belonged to previously) is retained if its integrity is otherwise intact; if the remaining group history is also corrupt, a type 2 cleanup is needed (see below). These changes replicated to any child servers.

Before the cleanup operation deletes any invalid current groups from the user account record, it saves these details to the WGNDUPUG1 database table. After any CMS upgrade, you need to check for entries in this table.

Note: This ‘simple’ group history corruption is the only type that we have observed in the field.

Type 2 Cleanup

If the group history contains too many errors and the database violations prove intractable, the cleanup operation deletes the entire group history except for the user’s newest group membership. These changes replicated to any child servers.

Before the cleanup operation deletes any invalid groups from the user account, it saves details of these in the WGNDUPUG2 database table. After any CMS upgrade, you must check for entries in this table.

Note: Such complex examples of group history corruption have never been observed in the field.

More information:

Database Changes Are Replicated to Child Machines