Cisco Cisco Unified MeetingPlace Directory Services
Release Note, MeetingPlace Directory Services Release
4.2.7.22
Page 3 of 10
0050-0048-01, Rev. A0
Revision Date: 04/25/2002
Example of suspense file error
The following error will appear if there are duplicate entries in the database. A duplicate entry error will
look something like this:
look something like this:
/*****************************************************************************/
/* Error LDAP0037: MetaLink has determined that entry */
/* CN=alexandra.c.smith,OU=People,DC=ds,DC=dev,DC=latitude,DC=com in */
/* system LDAP correlates with entry /o=latitude.com/ou=people/nm=1239876 */
/* 8 in system DCD. However, the second entry is already linked to */
/* entry CN=alex.smith,OU=People,DC=ds,DC=dev,DC=latitude,DC=com in the */
/* first system. This is an error, and the link needs to be removed */
/* before this change can by synchronized. */
/*****************************************************************************/
Modify [0][24]3+1AwnkTYkGY85dvEvNMoA==
(2 attempts)
/* Error LDAP0037: MetaLink has determined that entry */
/* CN=alexandra.c.smith,OU=People,DC=ds,DC=dev,DC=latitude,DC=com in */
/* system LDAP correlates with entry /o=latitude.com/ou=people/nm=1239876 */
/* 8 in system DCD. However, the second entry is already linked to */
/* entry CN=alex.smith,OU=People,DC=ds,DC=dev,DC=latitude,DC=com in the */
/* first system. This is an error, and the link needs to be removed */
/* before this change can by synchronized. */
/*****************************************************************************/
Modify [0][24]3+1AwnkTYkGY85dvEvNMoA==
(2 attempts)
Problems like duplicate entries can be associated with invalid data in the corporate directory. These
problems must be fixed in the corporate directory to get resolved. Fixing problems in the corporate
directory will generate an update and the entry will get synchronized. The suspense file still needs to be
replayed in order to resolve the errors that are already fixed. A new suspense file will be generated with
errors that still exist.
Built-in profiles
The MeetingPlace Server contains four profiles native to its database, such as “guest” and “technician”.
These are called “built-in” profiles. These four default profiles are filtered from MeetingPlace into
MeetingPlace Directory Services when the MetaLink agreement between MeetingPlace and MeetingPlace
Directory Services is run. Please note that if there are entries from LDAP or Active Directory using these
names, those entries will not be imported into MeetingPlace.
The deployment specialist who installs MeetingPlace Directory Services should check the contents of the
customer directory and consult the customer directory administrators to see if there is a possibility that the
built-in profiles (guest, email, technician, sales engineer) may be overwritten. By default, case filters are
used to block the import of those profiles so that those particular usernames will not be replicated. The
exact application of those filters depends of business rules, but the basic principle is to make sure that no
profile in the customer directory will correlate with the built-in profiles (be sure to consider the profile
numbers for these accounts also). The downside of using filters is the performance impact, since every
entry in the customer directory has to be tested by the filter against the built-in profiles.
For example, if the correlation is based on the MPName=PersonnelID, the following filter could be
applied:
These are called “built-in” profiles. These four default profiles are filtered from MeetingPlace into
MeetingPlace Directory Services when the MetaLink agreement between MeetingPlace and MeetingPlace
Directory Services is run. Please note that if there are entries from LDAP or Active Directory using these
names, those entries will not be imported into MeetingPlace.
The deployment specialist who installs MeetingPlace Directory Services should check the contents of the
customer directory and consult the customer directory administrators to see if there is a possibility that the
built-in profiles (guest, email, technician, sales engineer) may be overwritten. By default, case filters are
used to block the import of those profiles so that those particular usernames will not be replicated. The
exact application of those filters depends of business rules, but the basic principle is to make sure that no
profile in the customer directory will correlate with the built-in profiles (be sure to consider the profile
numbers for these accounts also). The downside of using filters is the performance impact, since every
entry in the customer directory has to be tested by the filter against the built-in profiles.
For example, if the correlation is based on the MPName=PersonnelID, the following filter could be
applied:
Abs_Person = &filterAnd("5", &attrHasValue(*objectClass, "person"),
&filterNot(&attrHasValue(*PersonnelID, "email"),
&filterNot(&attrHasValue(*PersonnelID, "technician"),
&filterNot(&attrHasValue(*PersonnelID, "guest"),
&filterNot(&attrHasValue(*PersonnelID, "sales engineer") )
&filterNot(&attrHasValue(*PersonnelID, "technician"),
&filterNot(&attrHasValue(*PersonnelID, "guest"),
&filterNot(&attrHasValue(*PersonnelID, "sales engineer") )
Note: The following are default profile numbers for the built-in profiles
userid=guest, profile# =0000 - constant