Calendar Server requires a unique identifier in the form of an LDAP attribute whose value is used to map each calendar entry (in the LDAP Directory Server) to a unique account in the calendar database (the MySQL Server or Oracle Database that stores Calendar Server data). The unique identifier links various entries from different database tables for a user, group, and resource. You must use a unique identifier, and one that does not change, for user, group, and resource entries stored in LDAP.
When planning to deploy Calendar Server, and before installing and configuring Calendar Server, decide on the LDAP attribute to be used as the unique identifier. This is a critical decision. Realistically, you cannot change the attribute you use as the unique identifier once you deploy Calendar Server and start using it. Starting with version 7 Update 3, Calendar Server provides the davUniqueId attribute, which is the recommended attribute to use.
For more information, see davUniqueId in the Communications Suite Schema Reference.
You set the attribute to be used as the unique identifier during the Calendar Server initial configuration phase. (When installing a Communications Suite component such as Calendar Server, you first install the software and then configure it. These are two separate steps.) The Calendar Server configurator program, init-config, prompts you to enter the attribute you have chosen as your unique identifier. The configurator then stores the value to the davcore.uriinfo.permanentuniqueid Calendar Server configuration parameter.
Ever since the release of Calendar Server 7, the LDAP operational attribute nsUniqueId has been chosen as the default value used for the unique identifier. However, it was discovered that this choice has a potential serious downside. The problem with using nsUniqueId is that if the LDAP entry for a user, group, or resource is deleted and recreated in LDAP, the new entry would receive a different nsUniqueId value from the Directory Server, causing a disconnect from the existing account in the calendar database. As a result, recreated users cannot access their existing calendars.
The Calendar Server 184.108.40.206.0 documentation explains this situation in more detail. See Changing User uuid.
To prevent this potentially serious issue, Calendar Server 7 Update 3 introduced a new attribute, davUniqueId, in the davEntity objectclass, to use as the unique identifier. You should provision this attribute for your users, groups, and resources LDAP entries with globally unique IDs. To use Delegated Administrator as your provisioning tool, make sure that you are running at least Delegated Administrator 7 Patch 6, which supports provisioning the davUniqueId attribute.
In the Calendar Server data base, the unique identifier value is case sensitive. If you need to move or recreate the corresponding LDAP entry, make sure to retain the case of the value as is. However, because the value is considered as case insensitive for LDAP comparisons, do not create a unique identifier value for another user or resource entry by just changing the case of the value.
For a fresh installation:
- During initial configuration, when prompted by the Calendar Server init-config configurator, choose the default value, davUniqueId.
This is stored to the davcore.uriinfo.permanentuniqueid configuration parameter. For more information, see davUniqueId in the Communications Suite Schema Reference.
- In LDAP, populate calendar users, groups, and resources with the davUniqueId attribute.
- Use the populate-davuniqueid tool (introduced in Calendar Server 7 Update 3).
- Use your own LDAP tools.
If you initially deployed Calendar Server 7 Update 2 to use the nsUniqueId attribute as your unique identifier, you should switch to using the davUniqueId attribute, new in Calendar Server 7 Update 3. For more information on the problems with using nsUniqueId, see Changing User uuid.
To upgrade to Calendar Server 220.127.116.11.0, see Calendar Server 18.104.22.168.0 Upgrade.