1.7.2 Master/Slave LDAP Configuration for Calendar Server Version 6.3

A master/slave LDAP configuration includes a master (root) directory server and one or more slave (consumer or replica) directory servers. Calendar Server can access the master LDAP directory server either directly or through a slave directory server:

• If Calendar Server accesses the master LDAP directory server directly, the LDAP should be accurate, and you don't need to configure the LDAP data cache.

• If Calendar Server accesses the master LDAP directory server through a slave directory server, LDAP data changes are usually written transparently using an LDAP referral to the master directory server. The LDAP referral then replicates the data back to each slave directory server.

  In this second type of configuration, problems with inaccurate LDAP data can occur because of the delay in the availability of committed LDAP data to the slave directory servers.

  For example, Calendar Server commits an LDAP data change, but the new data is not available for a specific amount of time because of the delay in the master directory server updating each slave directory server. A subsequent Calendar Server client operation uses the old LDAP data and presents an out-of-date view.

  If the delay in updating the slave directory servers is short (only a few seconds), clients might not experience a problem. However, if the delay is longer (minutes or hours), clients will display inaccurate LDAP data for the length of the delay.

  The following table lists operations and the LDAP attributes affected by such a delay:

  Operation	LDAP Attributes
  Autoprovisioning of calendars	icsCalendar, icsSubscribed, icsCalendarOwned, icsDWPHost
  Calendar groups	icsStatus, icsCalendar
  Calendar creation	icsCalendarOwned, icsSubscribed
  Calendar subscription	icsSubscribed
  User options	icsExtendedUserPrefs, icsFirstDay, icsTimeZone, icsFreeBusy
  Calendar searches	icsCalendarOwned