Notas de la versión de Sun Java System Communications Services 2005Q4

Problemas de compatibilidad

Esta sección describe los problemas de compatibilidad que existen en Connector para Microsoft Outlook.

Consideraciones sobre Sun Java System Calendar Server

Esta sección describe las consideraciones de Sun Java System Calendar Server para Connector para Microsoft Outlook.

Instalación de Calendar Server

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.


Nota –

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.


Atributo LDAP mail obligatorio

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:

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.

Procedureadición del atributo LDAP email a un calendario de recursos

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.

Pasos
  1. Agregue el atributo mail al servidor LDAP utilizando la utilidad csattribute :

    # ./csattribute -a mail=Room100@sesta.com add Room100

  2. 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
    
                         

ProcedureConfiguración del canal bitbucket para el correo electrónico de recursos (Messaging Server)

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.

Pasos
  1. Asegúrese de que el canal bitbucket se haya definido en el archivo imta.cnf.

  2. 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


    Nota –

    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.


ProcedureConfiguración del canal bitbucket para el correo electrónico de recursos (Sendmail)

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.

Pasos
  1. En el archivo /etc/aliases del host adecuado, agregue una entrada como, por ejemplo:


    # Resource/Conference room aliases
    Room100: /dev/null
  2. 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

Alias del correo electrónico (atributo mailalternateaddress)

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:

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

Configuración de búsqueda LDAP de calendario compartido

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:

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.

Búsqueda de disponibilidad en Outlook y SSL

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:

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.

Base de datos de registro de eliminaciones de Calendar Server

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.

Interoperabilidad en la asignación de carpetas del sistema con Communications Express

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:

En Communications Express la denominación de carpetas es la siguiente:

Definición de las carpetas de sistema para Outlook

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.

Definición de las carpetas de sistema para Communications Express

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.


Nota –

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.

Configuración LDAP en clientes

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:

Configuración de búsquedas internacionales

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*

Actualización de los índices

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 

Nota –

No agregue ningún espacio, tabulación ni caracteres no visibles al comienzo o al final del valor.



Nota –

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).

Configuración de un filtro de búsqueda en Communications Express

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:

Permitir el acceso anónimo al directorio corporativo

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");)

Permitir la navegación por directorios

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"