Esta sección describe los problemas de compatibilidad que existen en Connector para Microsoft Outlook.
Esta sección describe las consideraciones de Sun Java System Calendar Server para Connector para Microsoft Outlook.
La última versión de Calendar Server está disponible en el sitio de descarga de colaboración y comunicación.
Se recomienda que los usuarios también instalen el último conjunto de revisiones que están disponibles en SunSolve.
Para obtener instrucciones de instalación detalladas, consulte laSun Java Enterprise System 2005Q4 Installation Guide for UNIX. Para obtener instrucciones de configuración, consulte la Sun Java System Calendar Server 6 2005Q4 Administration Guide.
Si está migrando de Calendar Server 5.x a la última versión de Calendar Server, debe ejecutar la utilidad cs5migrate_recurring para convertir la base de datos para que sea compatible con el modelo de datos de Connector para Microsoft Outlook. Póngase en contacto con el servicio de asistencia técnica para obtener información acerca de la utilidad cs5migrate_recurring.
Calendar Server 6 2004Q2 (y posterior) requiere que los usuarios tengan el atributo LDAP mail para los calendarios de usuarios y de recursos.
Para los clientes que vayan a utilizar Microsoft Outlook para programar calendarios de recursos (por ejemplo, para salas de reuniones o equipos como un equipo portátil o proyector), cada recurso debe tener una dirección de correo electrónico, incluso aunque no se necesite el correo electrónico. El atributo LDAP mail especifica esta dirección de correo electrónico.
Deberá agregar el atributo LDAP mail de la siguiente manera:
Instalación de 5.x. Antes de ejecutar la cs5migrate_recurring utilidad de migración, agregue el atributo mail a los usuarios para los calendarios de usuarios y de recursos. Para agregar el atributo mail, use la utilidad csattribute de Calendar Server o una utilidad como ldapmodify de Directory Server.
Nueva instalación (6 2004Q2 o superior). Añada el atributo LDAP mail para los usuarios existentes para los calendarios de recursos y usuarios utilizando la utilidad csattribute de Calendar Server o una utilidad como ldapmodify de Directory Server.
Si crea calendarios o usuarios nuevos tras la instalación, use la opción -m email obligatoria para especificar una dirección de correo electrónico cuando ejecute estas utilidades de Calendar Server:
Utilidad csresource para calendarios de recursos nuevos
Utilidad csuser para los usuarios nuevos
Para obtener información relacionada acerca de csattribute, csresource y csuser, consulte la Sun Java System Calendar Server 6 2005Q4 Administration Guide. Para obtener información relacionada acerca de la utilidad ldapmodify, consulte la Sun Java System Directory Server Resource Kit Tools Reference.
El siguiente ejemplo agrega el atributo LDAP mail a una sala de conferencias denominada “Room100” en el servidor sesta.com. Este ejemplo configura Messaging Server. Si está utilizando otro servidor de correo electrónico, consulte la documentación del producto para el proceso equivalente.
Agregue el atributo mail al servidor LDAP utilizando la utilidad csattribute :
# ./csattribute -a mail=Room100@sesta.com add Room100
Para comprobar que el atributo se ha definido, use el comando csattribute list con la opción -v (detallada):
# ./csattribute -v list Room100 ... cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com has mail: Room100@sesta.com |
Los siguientes ejemplos establecen el canal bitbucket de Messaging Server para el correo electrónico generado para los calendarios de recursos. Este ejemplo utiliza un recurso que se llama “Room100” en el servidor sesta.com. Si no establece el canal bitbucket (o equivalente), deberá eliminar periódicamente los mensajes de correo electrónico enviados al calendario de recursos.
Asegúrese de que el canal bitbucket se haya definido en el archivo imta.cnf.
Para dirigir los mensajes al canal bitbucket, cree la dirección de correo electrónico del recurso mediante la utilidad csresource:
# ./csattribute -a mail=Room100@bitbucket.sesta.com add Room100
Para habilitar estos cambios, también podría tener que generar tablas o configuraciones de alias. Consulte la documentación de Messaging Server (o su producto de correo electrónico) así como los procedimientos y documentación de su sitio relativos a los cambios en los servicios de correo.
Los siguientes ejemplos establecen el canal bitbucket de Sendmail para el correo electrónico generado para los calendarios de recursos. Este ejemplo utiliza un recurso que se llama “Room100” en el servidor sesta.com. Si no establece el canal bitbucket (o equivalente), deberá eliminar periódicamente los mensajes de correo electrónico enviados al calendario de recursos.
En el archivo /etc/aliases del host adecuado, agregue una entrada como, por ejemplo:
# Resource/Conference room aliases Room100: /dev/null |
Añada las direcciones de correo electrónico del recurso al directorio LDAP utilizando la utilidad csresource:
# ./csattribute -a mail=Room100@sesta.com add Room100
Si necesita configurar alias de correo electrónico para un usuario de calendario, use el atributo LDAP mailalternateaddress. El atributo LDAP mail proporciona la dirección de correo principal y el atributo LDAP mailalternateaddress se utiliza para los alias de correo electrónico. Ambos atributos asignan las direcciones de correo al ID de calendario del usuario (calid).
Por ejemplo, suponga que desea agregar el atributo mailalternateaddress para un usuario que se llame John Smith con estos valores:
ID de usuario (uid) y calid: johnsmith
Dirección de correo electrónico: john.smith@sesta.com
Alias de correo electrónico: johns@sesta.com y jsmith@sesta.com
Use estos comandos de utilidad de Calendar Server:
# ./csuser -g John -s Smith -y password -l en -m john.smith@sesta.com \ -c johnsmith create johnsmith # ./csattribute -a mailalternateaddress=johns@sesta.com add johnsmith # ./csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith |
Si Directory Server requiere autenticación para la búsqueda LDAP de calendario compartido, el parámetro service.wcap.userprefs.ldapproxyauth debe definirse en el archivo ics.conf de la siguiente manera:
Conexión anónima: service.wcap.userprefs.ldapproxyauth = "no"
Conexión mediante proxy autenticada: service.wcap.userprefs.ldapproxyauth = "yes"
Si el valor de service.wcap.userprefs.ldapproxyauth es afirmativo, debe definir el ACI LDAP adecuado para la entrada calmaster. Por ejemplo, para definir el ACI calmaster para la autenticación mediante proxy del dominio sesta.com, use la herramienta ldapmodify de la siguiente manera:
dn: o=usergroup changetype: modify add: aci aci: (targetattr="icscalendar || cn || givenName || sn || uid || mail")(targetfilter=(objectClass=icscalendaruser))(version 3.0; acl "Allow calendar administrators to proxy - product=ics,class=admin,num=2,version=1"; allow (proxy) groupdn = "ldap:///cn=Calendar Administrators,ou=Groups,o=usergroup";)
Para el nodo basedn del dominio, el siguiente ejemplo muestra la ACI correcta:
dn: o=sesta.com,o=usergroup changetype: modify add: aci aci:(targetattr="icscalendar || cn || givenName || sn || uid || mail") (targetfilter=(objectClass=icscalendaruser))(version 3.0; acl "Allow calendar users to read and search other users - product=ics,class=admin,num=3,version=1"; allow (search,read) userdn = "ldap:///uid=*, ou=People, o=sesta.com, o=usergroup";)
Si no hay ningún dominio, agregue esta ACI al sufijo root eliminando la parte o=sesta.com de la línea dn:.
El programa de configuración de Calendar Server, csconfigurator.sh, agrega estas ACI. Si está actualizando desde Java Enterprise System Release 1, debe ejecutar nuevamente el programa de configuración para obtener las ACI actualizadas.
La opción de búsqueda de disponibilidad de Microsoft Outlook no está disponible para los usuarios que acceden a Calendar Server en el modo SSL. Para utilizar el modo SSL y no SSL para la misma instancia de Calendar Server, los usuarios deben especificar distintos números de puertos de la siguiente manera:
Modo SSL: para acceder a Calendar Server mediante SSL, use el puerto SSL. El número de puerto predeterminado es “443” y se configura en el archivo ics.conf mediante este parámetro:
service.http.ssl.port = "443"
Modo no SSL: para utilizar la opción Libre/Ocupado de Outlook, acceda a Calendar Server utilizando el puerto HTTP habitual. El número de puerto predeterminado es “80” y se configura en el archivo ics.conf mediante este parámetro:
service.http.port = "80"
Para obtener más información acerca de SSL, consulte el Capítulo 8, Configuring SSL de Sun Java System Calendar Server 6 2005Q4 Administration Guide.
Calendar Server 6 2004Q2 o posterior incluye la base de datos de registros de eliminación ( ics50deletelog.db) para guardar los eventos y las tareas eliminadas. Para obtener más información, consulte el Capítulo 18, Administering the Delete Log Database de Sun Java System Calendar Server 6 2005Q4 Administration Guide.
Mientras el protocolo IMAP define sólo una carpeta de sistema para el correo entrante (INBOX), los clientes de correo como Outlook y Sun Java System Communications Express definen sus propias carpetas de sistema para los borradores, el correo enviado y el correo eliminado. Los clientes de correo no pueden distinguir de ningún modo esas carpetas. Estas carpetas de sistema se crean a partir de varios nombres preferidos y traducidos según la configuración regional y el software del cliente. Esto genera varias carpetas IMAP físicas que se crean para una carpeta del sistema si más de un cliente de correo electrónico accede a una sola cuenta de correo electrónico (o es el mismo cliente de correo electrónico, pero con un equipo con una configuración regional diferente).
En Outlook la denominación de carpetas es la siguiente:
Elementos eliminados=Deleted Items
Borradores=Drafts
Elementos enviados=Sent Items
En Communications Express la denominación de carpetas es la siguiente:
Elementos eliminados=Trash
Borradores=Drafts
Elementos enviados=Sent
Hay disponible un nuevo archivo de asignación de sistema de correo de Sun Java System Connector para Microsoft Outlook para ofrecer una mayor interacción entre Outlook y Communications Express. Esta solución permite al administrador configurar la asignación de las carpetas del sistema. El archivo uwc_folders.map contiene las definiciones de asignación de carpetas de sistema para Communications Express. El archivo outlook_folders.map contiene las definiciones de asignación de carpetas de sistema para Connector para Microsoft Outlook.
Puede elegir el archivo de las carpetas de asignación que desee utilizar como archivo de definición de asignación de carpetas del sistema predeterminado en el programa de configuración de implementación (en la ficha “Correo”). Elija entre el estilo de Outlook o el estilo de Communications Express para incluir cuáles de estos estándares debe utilizar el programa de usuario para nombrar las carpetas IMAP de los usuarios. Lo que seleccione aquí determinará cuál de los dos archivos de asignación, outlook_folders.map o uwc_folders.map, se utilizará para asignar los nombres de carpetas IMAP de los usuarios. Un administrador puede, antes de ejecutar este programa, editar estos archivos para que cumplan los requisitos locales, siempre que los nombres de archivo originales se mantengan igual.
A continuación, se deben definir las carpetas de sistema para Communications Express. El archivo i18n.js define los nombres de carpetas de sistema para Communications Express. Este archivo se encuentra en el directorio /var/opt/SUNWmsgsr/config/html/ lang, donde lang es el idioma específico localizado (por ejemplo fr para francés). Este archivo debe modificarse de forma que las entradas de asignación sean similares a las entradas del archivo sjoc_folders.map.
Por ejemplo, de forma predeterminada las asignaciones de carpetas en el archivo i18n.js en francés son las siguientes:
i18n[’INBOX’] = ’Inbox’ i18n[’trash folder’] = ’trash’ i18n[’draft folder’] = ’draft’ i18n[’sent folder’] = ’sent’ ... fldr[’INBOX’] = ’French Inbox’ fldr[’trash’] = ’French Trash’ fldr[’draft folder’] = ’French Draft Folder’ fldr[’sent folder’] = ’French Sent Folder’
Los valores de i18n[x ] se utilizan para crear las carpetas de sistema en el almacén IMAP. Por ejemplo, si i18n[’trash folder’]= ’trash’, se creará una carpeta con el nombre trash en el almacén IMAP. Los valores de fldr[y] ] se usan para mostrar los nombres de carpetas del sistema en la interfaz del cliente.
En el archivo sjoc_folders.map, las asignaciones de carpetas similares son las siguientes:
[fr] INBOX=’Boîte de réception’ Deleted Items=’Éléments supprimés’ Drafts=’Brouillons’ Sent Items =’Éléments envoyés’
Por consiguiente, las asignaciones de carpetas i18n.js en francés se deben modificar para que coincidan con el archivo sjoc_folders.map:
i18n[’INBOX’] = ’Boîte de réception’ i18n[’trash folder’] = ’Éléments supprimés’i18n[’draft folder’] = ’Brouillons’ i18n[’sent folder’] = ’Éléments envoyés’ ... fldr[’INBOX’] = ’Boîte de réception’ fldr[’trash’] = ’Éléments supprimés’ fldr[’Drafts’] = ’Brouillons’ fldr[’Sent’] = ’Éléments envoyés’
Deberá modificar cada idioma representado por un archivo i18n.js.
Los archivos i18n.js incluyen código UTF8, por lo que deberá utilizar un editor que conserve este código.
Esta nueva definición de asignación de carpetas sólo es efectiva para usuarios nuevos.
Antes de que los usuarios inicien sesión en Communications Express, se debe establecer el idioma preferido de los usuarios. Para ello, defina el atributo preferredLanguage o preferredLocale utilizando el comando ldapmodify.
Los usuarios nuevos deberían ver únicamente un conjunto de carpetas de sistema, excepto en el caso siguiente:
Un usuario inicia la sesión en Outlook con la configuración regional definida en francés. Posteriormente, el mismo usuario inicia la sesión en Communications Express usando como idioma preferido el inglés. Este usuario verá las carpetas de sistema de papelera, de borrador y de elementos enviados (Éléments supprimés, Brouillons y Éléments envoyés) en Outlook así como en Communications Express.
Todos los productos de cliente que se suministran con Sun Java System Communications Services permiten que los usuarios busquen el directorio corporativo y sus propias libretas de direcciones. Si bien esto funciona, se puede mejorar la experiencia del usuario con algunos ajustes LDAP.
Esta sección plantea:
Si está utilizando Communications Express o Connector para Microsoft Outlook, la realización de una búsqueda en los contactos personales o la libreta de direcciones pública de una cadena concreta es una operación específica de la configuración regional. Por ejemplo, un usuario francés que busque “Gaelle” espera obtener entradas que contengan la cadena “Gaelle” pero también todas las entradas que contengan la cadena “Gaëlle.”
Las distintas normas que indican la forma en que se presentan las entradas a un usuario basándose en la configuración regional se llaman "normas de intercalado" u "orden de intercalado". El orden de intercalado proporciona información específica del idioma y la cultura sobre cómo se deben ordenar los caracteres de un idioma concreto. Identifica elementos como la secuencia de las letras en el alfabeto, cómo comparar las letras con acentos con letras sin ellos y si hay caracteres que se pueden ignorar al comparar cadenas. El orden de intercalado también tiene en cuenta la información específica de la cultura de un idioma, como la dirección en la que se lee un idioma (de izquierda a derecha, derecha a izquierda o de arriba a abajo).
Sun Java System Directory Server admite una amplia variedad de configuraciones regionales y normas de intercalado (consulte “Identifying Supported Locales” en la Sun Java System Directory Server 5 2005Q1 Administration Reference). En función de la base de usuarios, deberá seleccionar la configuración regional más adecuada para su entorno. En los siguientes ejemplos se utilizará la configuración regional English (US) (OID = 1.3.6.1.4.1.42.2.27.9.4.34.1).
Para especificar la configuración regional que se debe utilizar al realizar una búsqueda, use la sintaxis de filtro de regla coincidente descrita en “Searching an Internationalized Directory” en la Sun Java System Directory Server 5 2005Q1 Administration Reference. Esta sintaxis permite especificar la configuración regional así como el tipo de búsqueda (igualdad, subcadena, etc.).
Por ejemplo, el siguiente filtro realizará una comparación de subcadenas (.6) en el atributo CN, utilizando las normas de intercalado de inglés (US) (1.3.6.1.4.1.42.2.27.9.4.34.1). El filtro buscará el CN para cadenas que empiecen con “Gae”.
cn:1.3.6.1.4.1.42.2.27.9.4.34.1.6:=Gae*
Al realizar una búsqueda LDAP, la mayoría de los problemas de rendimiento se deben al hecho de que los índices no están presentes o no se han configurado adecuadamente. De forma predeterminada, Directory Server se ha configurado de forma que las búsquedas emitidas por Communications Express o por Connector para Microsoft Outlook se indexen y muestren un resultado en un intervalo de tiempo razonable. Sin embargo, Directory Server no se ha configurado para búsquedas internacionales. Por lo tanto, hay que alterar los índices existentes de forma que tengan en cuenta las normas de intercalado que se han seleccionado. Esto se describe en la sección “Managing Indexes” de la Sun Java System Directory Server 5 2005Q1 Administration Guide.
Por ejemplo, el atributo CN se indexa de forma predeterminada en el sufijo userRoot:
# ldapsearch -D "cn=Directory manager" -b "cn=cn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" "objectclass=*" cn=cn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass=top objectClass=nsIndex cn=cn nsSystemIndex=false nsIndexType=pres nsIndexType=eq nsIndexType=sub
Para habilitar las búsquedas internacionales utilizando las normas de intercalado de inglés (US), agregue un atributo nsMatchingRule con el ODI English (US). Los clientes realizan búsquedas de subcadenas, por lo que es necesario agregar el sufijo de subcadena (“.6”) al OID :
#ldapmodify -D "cn=Directory manager" dn: cn=cn,cn=index,cn=userRoot,cn=ldbm database, cn=plugins,cn=config changetype: modify add: nsMatchingRule nsMatchingRule: 1.3.6.1.4.1.42.2.27.9.4.34.1.6
No agregue ningún espacio, tabulación ni caracteres no visibles al comienzo o al final del valor.
nsMatchingRule es un atributo con varios valores. Se pueden agregar distintos tipos de búsquedas para el mismo OID o distintos OID.
A continuación, se debe ejecutar la secuencia de comandos db2index.pl que se encuentra en serverroot/slapd-instance:
# perl db2index.pl -D "cn=Directory Manager" -w \ secret -n userRoot -t cn
Esta operación se ejecuta en línea y puede tardar cierto tiempo en realizarse. Como alternativa, se puede reiniciar el sufijo. Consulte “Reinitializing a Suffix” en la Sun Java System Directory Server 5 2005Q1 Administration Guide.
La consola también se puede utilizar para agregar el atributo nsMatchingRule (consulte la sección “Managing Indexes” en la Sun Java System Directory Server 5 2005Q1 Administration Guide).
En las siguientes secciones se muestra la lista de índices que se deben modificar. Asegúrese de que no se realice ninguna búsqueda no indexada. Esto se puede hacer mirando el archivo de registro de acceso de Directory Server (y buscando notes=U en las entradas de resultados de las búsquedas).
El filtro de búsqueda utilizado por Communications Express debe cambiarse para ajustarse a la sintaxis de la norma de coincidencia. Esto se obtiene habilitando los parámetros de norma de intercalado que se especifican en el archivo db_config.properties (que se encuentra en deployed-path/WEB-INF/ldappstore (para almacén personal) y deployed-path/WEB-INF/corp-dir (para el directorio corporativo).
Los parámetros son:
# Collation Rule # Uncomment below to apply collation rule # collation_rule=en-US # Search Fields for which collation rule should be applied. # The fields provided here should be disambiguator formatted fields # e.g. entry/displayname, person/givenname etc. # Uncomment below to supply the comma-separated fields # search_fields=entry/displayname
Elimine el comentario de los parámetros collation_rule y search_fields para habilitar la norma de intercalado. Para especificar un conjunto de campos en la búsqueda, cambie el valor de search_fields a los valores deseados. collation_rule puede contener la etiqueta de idioma o el OID correspondiente al idioma (en el ejemplo 1.3.6.1.4.1.42.2.27.9.4.34.1) sin el sufijo que especifica el tipo de búsqueda. La instancia de contenedor web debe iniciarse tras realizar el cambio.
Los siguientes atributos deben indexarse en el servidor LDAP para la búsqueda internacional con respecto a Communications Express:
cn (en el sufijo ou=people/ou=groups)
displayname (en el sufijo o=piServerDb)
Connector para Microsoft Outlook puede configurarse para la utilización de un DN y una contraseña o para vincular como anónimo. Para habilitar el acceso anónimo al directorio corporativo, agregue un ACL en el nivel Root de los subárboles ou=people/ou=group.
Por ejemplo, si el nivel root es dc=red,dc=sesta,dc=com, realice las siguientes acciones:
#ldapmodify -D "cn=Directory manager" dn: dc=red,dc=sesta,dc=com changetype: modify add: aci aci: (targetattr != "userPassword") (version 3.0;acl "Anonymous access"; allow (read,compare,search) (userdn = "ldap:///anyone");)
Nuevo en esta versión 7 2005Q4, Connector para Microsoft Outlook permite que el usuario final navegue por los directorios. Al acceder a la página de la libreta de direcciones, se muestran las primeras 10 entradas del directorio. El usuario puede desplazarse hacia arriba y abajo o escribir unos pocos caracteres y ver los resultados automáticamente actualizados. Éste es un cambio con respecto a las versiones anteriores de Connector para Microsoft Outlook, donde el usuario sólo podía buscar un usuario concreto.
Para habilitar esta función mientras se mantiene un buen rendimiento, connector se basa en dos extensiones de control LDAP que se llaman Virtual List View (VLVl, vista de lista virtual) y clasificación de resultados de búsqueda del servidor (RFC 2891). El siguiente ejemplo de ldapsearch muestra la lista de los controles admitidos:
# ldapsearch -s base "objectclass=*" supportedControl supportedControl=2.16.840.1.113730.3.4.2 supportedControl=2.16.840.1.113730.3.4.3 supportedControl=2.16.840.1.113730.3.4.4 supportedControl=2.16.840.1.113730.3.4.5 supportedControl=1.2.840.113556.1.4.473 ------> Server Side Sort Control supportedControl=2.16.840.1.113730.3.4.9 ------> VLV Control supportedControl=2.16.840.1.113730.3.4.16 supportedControl=2.16.840.1.113730.3.4.15 supportedControl=2.16.840.1.113730.3.4.17 supportedControl=2.16.840.1.113730.3.4.19 supportedControl=1.3.6.1.4.1.42.2.27.9.5.2 supportedControl=1.3.6.1.4.1.42.2.27.9.5.6 supportedControl=2.16.840.1.113730.3.4.14 supportedControl=1.3.6.1.4.1.1466.29539.12 supportedControl=2.16.840.1.113730.3.4.12 supportedControl=2.16.840.1.113730.3.4.18 supportedControl=2.16.840.1.113730.3.4.13
Sun Java System Directory Server admite los dos controles. Sin embargo, el control VLV es, de forma predeterminada, el único disponible para los usuarios autenticados:
ldapsearch -D "cn=Directory Manager" -b \ "oid=2.16.840.1.113730.3.4.9,cn=features,cn=config" \ "objectclass=*" aci oid=2.16.840.1.113730.3.4.9,cn=features,cn=config \ aci=(targetattr != "aci")(version 3.0; acl "VLV Request Control"; \ allow( read, search, compare, proxy ) userdn = "ldap:///all";)
Para permitir el acceso anónimo al control VLV, agregue la ACI correspondiente:
#ldapmodify -D "cn=Directory Manager" \ dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config \ changetype: modify add: aci aci: (targetattr !="aci")\ (version 3.0; acl "VLV Request Control"; allow (compare,read,search) \ userdn = "ldap:///anyone"; )
Para mejorar el rendimiento de las búsquedas que requieren VLV además de clasificación, cree un índice de exploración en Directory Server (como se describe en “Managing Browsing Indexing” en la Sun Java System Directory Server 5 2005Q1 Administration Guide). Cada índice de exploración es específico para un DN de base, filtro de búsqueda, ámbito y atributo de clasificación. La configuración de VLV se puede ajustar en el cliente utilizando la herramienta de configuración de implementación.
En dicho caso concreto, se debe crear un índice de exploración para un dn de base igual a dc=red,dc=iplanet,dc=com, un filtro igual a (&(mail=*)(cn=*)), utilizando una clasificación en el atributo cn. La información del índice de exploración se agrega a la configuración que contiene el dn de base (en este caso userRoot):
#ldapmodify -D "cn=Directory Manager" dn: cn=Browsing red.sesta.com,cn=userRoot, cn=ldbm database,cn=plugins,cn=config changetype: add objectClass: top objectClass: vlvSearch cn: Browsing red.sesta.com vlvbase: dc=red,dc=sesta,dc=com vlvscope: 2 vlvfilter: (&(mail=*)(cn=*)) aci: (targetattr="*") (version 3.0; acl "VLV for Anonymous"; allow (read,search,compare) userdn="ldap:///anyone";) dn: cn=Sort by cn, cn=Browsing red.sesta.com,cn=userRoot, cn=ldbm database,cn=plugins,cn=config changetype: add objectClass: top objectClass: vlvIndex cn: Sort by cn vlvSort: cn
A continuación, ejecute el comando vlvindex, que se encuentra en serverroot/slapd-instance:
# ./vlvindex -n userRoot -T "Sort by cn"