The Content Server fetches users and groups from a UserProvider only on demand, for example when a user logs in, or the members of a group are requested. Once fetched, users and groups are cached time-based in the Content Server. When a user or group is accessed again after expiration, the Content Server updates it against the UserProvider. Initially, after a restart of the Content Server, all users and groups are considered expired.

When the Content Server updates a user against the UserProvider, it may turn out that the user is no longer present in the UserProvider. In this case the Content Server marks the user as inactive. That means that the user can no longer log in. All the user's assets, like content (even checked-out content), workflows, and his home directory are preserved, though, and can be finalized by other - typically administrative - users with according permissions.

When a user finally vanishes from the UserProvider, because it has been deleted on purpose, it is up to an administrative user to clean up the Content Server, which includes deleting the user's home directory, checking in its checked-out contents, so that other users can take over, and aborting the user's workflows.

Sometimes users vanish accidentally from the UserProvider, mainly by erroneous configuration changes. When the configuration is fixed, the user is available again. In this case, the Content Server can recognize the user and reactivate it. The user gets its old home directory with all existing content, esp. the studio preferences. If a user from the UserProvider is not recognized as an already known active or inactive user, it is treated as a new user and gets a new empty home directory.

For backward compatibility reasons, the reactivation of users is disabled by default. It can be enabled by setting the configuration property cap.server.restore-inactive-users to true. The property is global and applies to users of all UserProviders of the Content Server. It is not possible to control the reactivation of users for a specific UserProvider.

For historical reasons, external users have two IDs in the Content Server: a UUID and a jndiId. For details see LdapObject. Recognition of inactive users works only if a UserProvider supports UUIDs, and if both, the UUID and the jndiId, of the inactive user account on the Content Server and the external user match.