Exportar (0) Imprimir
Expandir todo
Expandir Minimizar

Descripción de las carpetas predeterminadas de EXOLEDB

 

Última modificación del tema: 2006-01-11

Jason Nelson

En este artículo se describen las distintas carpetas de EXOLEDB del servidor de Microsoft® Exchange y se explica su finalidad.

EXOLEDB crea varias carpetas del sistema bajo NON_IPM_SUBTREE durante la fase de aceptación de clientes de la inicialización de la base de datos de mensajes (MDB). Algunas de las carpetas se conservan por motivos de continuidad, pero la mayoría de ellas tiene una finalidad práctica. Si se eliminan las carpetas, el servidor puede verse afectado. No se debe replicar ninguna de las carpetas. Las carpetas que se crean son las siguientes:

  • \NON_IPM_SUBTREE\schema-root\
  • \NON_IPM_SUBTREE\schema-root\Default
  • \NON_IPM_SUBTREE\schema-root\Microsoft\
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views
  • \NON_IPM_SUBTREE\StoreEvents\
  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents
  • \NON_IPM_SUBTREE\StoreEvents\Internal
  • \NON_IPM_SUBTREE\OWAScratchPad

En todos los casos, las subcarpetas que tienen el GUID en el nombre corresponden al objeto de la MDB que tiene el mismo GUID.

Las carpetas de esquema son las primeras que se crean.

En la lista siguiente se explica la carpeta schema-root:

  • \NON_IPM_SUBTREE\schema-root\
    Se introdujo en Exchange 2000 Server.
  • \NON_IPM_SUBTREE\schema-root\Default
    Se introdujo en Exchange 2000 Server Service Pack 1 (SP1).
  • \NON_IPM_SUBTREE\schema-root\Microsoft\
    Se introdujo en Exchange 2000 Server Server SP1.
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1
    Se introdujo en Exchange 2000 Server Server SP1.

A continuación se muestra una ruta de esquema típica de una MDB pública:

  • File://.BackOfficeStorage/<dominio>/<NombreTLH>/NON_IPM_SUBTREE/schema-root/microsoft/exchangeV1

La ruta de esquema de la MDB privada está en el buzón del operador del sistema.

EXOLEDB admite varios esquemas, o definiciones de tipo de propiedad. Estas carpetas son compatibles con la plataforma de desarrollo del almacén Web de Exchange. El objetivo era que los elementos de las carpetas pudieran coexistir y hacer referencia a varias versiones del esquema. En un momento dado, en Exchange 2000 Server, los archivos de esquema estaban en la carpeta raíz del esquema y los cambios realizados en el esquema se propagaban a todos los elementos. Esta situación ocasionaba problemas en el espacio de trabajo de desarrollo de aplicaciones, donde había que trabajar con cada elemento para quitar o agregar propiedades, por lo que Microsoft adoptó un método de versiones. Bajo la carpeta raíz de esquema, Microsoft crea subcarpetas con elementos de aplicación y versión para que se puedan realizar actualizaciones sin problemas. EXOLEDB busca cambios en las carpetas de esquema para poder propagar las entradas, realizar el volcado de la caché de esquema y volverla a llenar mientras tiene lugar el procesamiento. La carpeta \schemaroot\default es el lugar en que los elementos normales de las carpetas obtienen el esquema. La carpeta raíz de esquema se marca de forma que señala a la carpeta de ExchangeV1. EXOLEDB llena las entradas de esquema desde los archivos .xml, que se procesan mediante un receptor de sucesos, EXSCHEMA.EXE. El enlace con el receptor de sucesos no se puede eliminar ni quitar, porque no tiene una entrada en la carpeta EventBindings, como la mayoría de los sucesos.

En la siguiente lista se describen las carpetas EXCHWEB, views, IMG y controls:

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views

Estos elementos se introdujeron en Exchange 2000 Server SP1; no se rellenaban en Exchange 2000 Server Service Pack 3 (SP3) y tampoco se rellenan en Exchange Server 2003.

Para que el almacén local abra elementos que hacen referencia a la funcionalidad de control de Microsoft Outlook® Web Access, los archivos tienen que estar en una carpeta que se pueda sincronizar. En un momento dado, en estas carpetas había copias de los datos Web de Outlook Web Access para que se pudieran abrir los elementos del almacén de información local (LIS), pero no se han usado nunca fuera del LIS.

A continuación, EXOLEDB inicia el sistema de enlace con sucesos, que crea StoreEvents.

Todas las carpetas de sucesos de almacén de la siguiente lista existían ya en Exchange 2000 Server:

  • \NON_IPM_SUBTREE\StoreEvents\
  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents
  • \NON_IPM_SUBTREE\StoreEvents\Internal

Ésta es la carpeta de enlaces de sucesos, en la que EXOLEDB almacena la información sobre los sucesos creados en una MDB específica. Durante el inicio, EXOLEDB debe enumerar los sucesos aquí, lo que puede dar lugar a tiempos de inicio de almacén largos si hay un gran número de receptores de sucesos. En Exchange Server 2003 el rendimiento es mucho mejor en este aspecto, pero el tiempo necesario para montar un MDB sigue viéndose afectado por el número de filas. Se valida la clase de cada enlace con un método de suceso válido, como onsave u ontimer, un clsid válido y parámetros de receptor. Los sucesos que tienen la clase ANY sólo se pueden registrar en la subcarpeta GlobalEvents.

Después de crear las carpetas de esquema y de iniciar el sistema de enlaces de sucesos, EXOLEDB crea OWAScratchPad.

OWAScratchPad se introdujo en Exchange 2000 Server SP1. Se muestra de la siguiente manera:

  • \NON_IPM_SUBTREE\OWAScratchPad

Las exposiciones tienen que empezar en algún lugar para tener datos adjuntos, y para los inicios de sesión en el almacén público, ese lugar es OWAScratchPad. Puesto que el Sistema distribuido de creación y control de versiones (DAV) no traspasa las operaciones de MDB, se necesita un punto en todos los buzones en el que siempre se puedan escribir exposiciones, para que se pueda admitir la inclusión de datos adjuntos. Las exposiciones se escalonan en OWAScratchPad hasta que se han agregado todos los datos adjunto, o se almacenan. El límite del tamaño en OWAScratchPad controla el tamaño de los datos adjuntos que se pueden agregar mediante Outlook Web Access. Si se trata de exponer mensajes más grandes se producirá un error parecido al siguiente:

  • Este elemento es más grande que el tamaño máximo definido para esta carpeta y no se puede guardar. Póngase en contacto con el administrador para que aumente los límites de las carpetas.

El tamaño de OWAScratchPad se restablece siempre a 1 megabyte (MB) cuando se inicializa EXOLEDB si no se define el valor "Message Size Limit" REG_DWORD de la clave del Registro HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA. Este es un requisito de Microsoft SharePoint® Portal Server, porque EXOLEDB no tiene forma de saber que se está ejecutando el modo magma.

Las exposiciones de OWAScratchPad se hacen con el formato URL normal, es decir, hacen referencia a la carpeta y el mensaje directamente. Se hace así para poder admitir raíces con muchos niveles, en las que una dirección URL descriptiva podría ser demasiado larga.

Lea atentamente las siguientes preguntas más frecuentes (P+F).

Esta pregunta tiene dos respuestas:

  • Objetos de Active Directory    Cuando se elimina un almacén, no hay forma de indicarle a Active Directory que los objetos de las carpetas públicas han desaparecido. Posteriormente, cuando se vuelven a crear carpetas, no se adjuntan a los objetos correspondientes del servicio de directorio. Se crean nuevos objetos del servicio de directorio.
  • Carpetas en sí mismas   Si las carpetas se han configurado para su replicación y se elimina el almacén correspondiente, EXOLEDB volverá a crear las carpetas al iniciarse, y la replicación puede crear un duplicado de las carpetas así configuradas. Esto causa problemas con los enlaces de sucesos. La eliminación de las carpetas duplicadas mediante direcciones URL descriptivas no es aconsejable, porque es probable que las dos carpetas tengan la misma dirección URL descriptiva.

Cuando aumenta el número de carpetas que tienen el mismo número, se agrega un número aleatorio al proxy del servicio de directorio para que sea exclusivo, lo que da lugar a nombres como controls12345678.

Si eliminara las carpetas, EXOLEDB las volvería a crear. Además, la mayoría de estas carpetas tienen usos que hacen que su ausencia afecte negativamente al funcionamiento del servidor.

Si faltan carpetas del esquema, es decir, no están en el subárbol ipm, se puede establecer la siguiente clave del registro en un valor REG_DWORD de 0 para que se vuelva a llenar el esquema:

HKLM\System\CurrentControlSet\MSExchangeIS\Parameters\Schema\<MDBGUID>

EXOLEDB concede automáticamente a todos los usuarios permiso de lectura para las carpetas de esquema. Esta lista de control de acceso (ACL) se puede modificar, pero se eliminaría si se volviera a producir la propagación del esquema.

No es necesario replicar el contenido de las carpetas como parte de los procedimientos de replicación de carpetas del sistema.

Para obtener más información, consulte la siguiente entrada del blog de Exchange:

 
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft