Exportar (0) Imprimir
Expandir todo
Expandir Minimizar
Personas que lo han encontrado útil: 1 de 1 - Valorar este tema

Los tres problemas principales de configuración del módulo de administración de Exchange

 

Última modificación del tema: 2005-08-19

Use el módulo de administración de Exchange 2003 para supervisar el rendimiento, la disponibilidad y la seguridad de Microsoft® Exchange Server 2003; el módulo le alerta de los eventos que afectan directamente a la disponibilidad del servidor y filtra los que no precisan ninguna acción. Cuando se importa, el módulo de administración de Exchange comienza a supervisar los servidores del entorno que ejecutan Exchange. No obstante, algunos scripts requieren configuración. Es posible que algunas veces, durante la configuración, reciba errores que no sepa cómo solucionar. En este artículo se analizan tres de los problemas de configuración más comunes por los que los clientes de Microsoft nos llaman para obtener ayuda. Antes de tratar estos problemas, revisemos cómo se prepara para supervisión un servidor que ejecuta Exchange.

Cuando se implementa el módulo de administración de Exchange, Microsoft Operations Manager (MOM) se encarga de la mayor parte de la configuración, trabajando en segundo plano para identificar los servidores del entorno que ejecutan Exchange y utilizar en dichos servidores las reglas incluidas en el módulo de administración. Algunas de estas reglas comprueban la configuración del servidor para determinados atributos y pueden llamar a otras reglas que efectúen los cambios necesarios para preparar el servidor para supervisión. Cuando estas reglas comienzan a activarse, verá que los eventos surgen en la Consola de administrador de MOM, lo cual indica que este proceso se está realizando. Finalmente, debería ver otros eventos que le lleven a dar los pasos necesarios para finalizar el trabajo de configuración iniciado por MOM.

En este punto, ejecutaría el asistente de configuración del módulo de administración de Exchange para llevar a cabo los cambios de configuración finales que requiere MOM para una supervisión completa de las funcionalidades de Exchange, como la disponibilidad de los buzones de correo, el flujo de correo o los servicios. Lamentablemente, también es posible que descubra que no se puede ejecutar el asistente debido a un error en la preparación preliminar que MOM ha estado realizando.

Un problema que encontramos de vez en cuando en el soporte técnico del módulo de administración de Exchange es la incapacidad de finalizar la configuración para supervisar un servidor que ejecuta Exchange. Esta situación puede deberse a que faltan datos publicados en segundo plano cuando se implementa el módulo de administración. Intentaremos explicar por qué puede ocurrir esto y qué hacer si ocurre.

En el asistente de configuración, puede ver el error siguiente:

Error: No se puede configurar la cuenta de acceso de buzón en el equipo <nombreservidor>. Esta configuración sólo se puede realizar después de que MOM registre el evento 9986 de Exchange MOM.

Explicaremos el evento 9986 y cuándo se debe esperar que se produzca, además de algunos motivos por los que no tal vez no lo vea. Una de las primeras reglas que se activa en un servidor back-end de Exchange es la prueba de disponibilidad de buzón. El script asociado a esta regla comprueba los datos del Registro que hacen posible la prueba. La clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExMPLS se utiliza para almacenar las credenciales cifradas de la cuenta de dominio que se usa para el acceso a la supervisión de buzones en cada servidor que ejecuta Exchange. Esta cuenta de acceso de buzones (MAA) debe disponer de permisos para iniciar sesión en los buzones de prueba, ya que MOM utiliza estas credenciales para representar a la cuenta durante el inicio de sesión. Si faltan los datos del registro, esta regla genera un evento que desencadena otra regla que, a su vez, inicia la publicación de la regla que falta y que se usa para almacenar las credenciales.

Para publicar la clave, los servidores de Exchange necesitan tener instalados objetos COM distribuido (DCOM) "de ayudante" para trabajar junto con las reglas de publicación. El objeto DCOM responsable de la publicación de la clave de Registro que almacena las credenciales de MAA se instala con la configuración de Exchange Server 2003. Sin embargo, en versiones anteriores de Exchange, MOM instala los objetos de ayudante según sea necesario, o se pueden instalar manualmente. La regla de publicación llama al objeto DCOM para publicar los datos requeridos en el servidor.

Si DCOM y la función del objeto de ayudante funcionan como es de esperar, se crea la clave de Registro ExMPLS. Cuando se publican los datos, se produce el evento 9986 y podrá ejecutar el asistente de configuración frente a dicho servidor. El asistente escribe a continuación las credenciales de MAA en forma cifrada en la clave. Y no se preocupe si teme que falte el evento, hay una regla que se ejecuta diariamente y que comprueba y genera el evento 9986 incluso aunque los datos se hayan publicado correctamente con anterioridad.

Si la publicación da error, la regla genera eventos que aparecen en la Consola de administrador de MOM para avisar del error al administrador. Los errores pueden deberse a que falta un objeto DCOM o funciona incorrectamente o bien a que los permisos de DCOM están configurados de forma incorrecta. Los objetos DCOM que faltan o funcionan incorrectamente y que se instalan con el módulo de administración de Exchange pueden ser difíciles de solucionar. Póngase en contacto con el soporte técnico de Microsoft si se produce un error al generar el evento 9986. Para obtener más información sobre cómo investigar y resolver problemas con la configuración de permisos DCOM, consulte en Microsoft Knowledge Base el artículo 274696, Acciones como buscar y arrastrar y colocar no funcionan porque los permisos de acceso predeterminado han cambiado en la herramienta Dcomcnfg.exe.

Después de haber generado el evento 9986, puede ejecutar el asistente de configuración para configurar el entorno para la supervisión de Exchange. El asistente de configuración crea la cuenta de acceso de buzón (MAA) y las cuentas (agente) de prueba y buzones. Estas cuentas se usan para que el script de inicio de sesión de MAPI y el de OWA supervisen los servidores de Exchange.

Para comprobar que el almacén de buzones está montado y que los usuarios de Microsoft Office Outlook® pueden iniciar sesión correctamente, el módulo de administración de Exchange ejecuta el script de comprobación de inicio de sesión de MAPI. En este script, se utilizan las credenciales de MAA para iniciar sesión realmente y abrir el buzón del buzón de prueba (nombreservidorMOM). Los scripts de comprobación de flujo de correo también utilizan el inicio de sesión MAPI para enviar y recibir mensajes. Puede ver el inicio de sesión en el servidor que ejecuta Exchange mirando en el administrador del sistema de Exchange en la sección Inicios de sesión debajo de la carpeta Almacén de buzones. Debe ver el buzón Prueba; observe que MAA era la cuenta de Microsoft Windows® utilizada para iniciar sesión.

Uno de los problemas más frecuentes con los que nos encontramos son los errores de script de inicio de sesión de MAPI. Es posible que encuentre diferentes mensajes de error, incluidos MAPI_E_NOT_FOUND, MAPI_E_LOGON_FAILED y MAPI_E_NOT_INITIALIZED. Para obtener más información sobre algunas de las causas comunes de estos mensajes de error, consulte el tema "Permissions and Directory Access Errors" en Exchange Server Management Pack Guide for MOM 2005 (página en inglés).

Si obtiene errores de inicio de sesión de MPI, siga todos los pasos de solución de problemas de esta sección, ya que puede haber diversas causas para estos problemas y la resolución de una de ellas puede desenmascarar el problema subyacente. Para obtener más información acerca de los errores de MAPI, consulte en Knowledge Base el artículo 238119, INFO: Lista de códigos de resultado numérico MAPI extendido.

Además, debe comprobar que MAA dispone de derechos completos en el buzón utilizado para la prueba de inicio de sesión de MAPI. Puede comprobar si MAA tiene permisos abriendo Outlook como cuenta de acceso a buzones. A continuación, abra el buzón de prueba yendo a Archivo, Abrir, Carpeta de otro usuario y seleccione el buzón de prueba. Debe poder ver la Bandeja de entrada de la cuenta de prueba. Si no puede abrir el buzón, abra Usuarios y equipos de Active Directory y mire las propiedades del buzón de prueba. Haga clic en Opciones avanzadas de Exchange y, a continuación, en Derechos del buzón. El MAA debe aparecer aquí y debe disponer de permisos acceso completo a buzón, eliminar almacén de buzones y lectura.

Si sigue teniendo problemas para abrir el buzón de prueba, asegúrese de que ninguno de los buzones que utiliza MOM (buzones de prueba y MAA) esté oculto. Si las cuentas están ocultas en la lista global de direcciones (GAL), no se podrá usar el script de inicio de sesión de MAPI ni el script de comprobación de flujo de correo. Si las cuentas no están ocultas pero sigue sin poder iniciar sesión en Outlook, a veces es útil determinar cómo se crearon. La forma en que se crearon la cuentas, por ejemplo, con el asistente de configuración, manualmente o con un producto de distribución de terceros puede dar pistas sobre por qué no puede iniciar sesión en Outlook.

Otra prueba consiste en iniciar sesión en Windows en el servidor que ejecuta Exchange mediante las credenciales de inicio de sesión de la cuenta de acceso a buzones. Abra el Administrador del sistema de Exchange y expanda Grupos administrativos, expanda Servidores, y siga expandiendo hasta que pueda seleccionar Buzones en el lado izquierdo. ¿Puede ver la lista de buzones en el lado derecho? Si no, puede que se haya denegado Ver el estado del almacén de información a la cuenta de acceso a buzones. Puede seguir el procedimiento de edición de ADSI indicado a continuación y profundizar en las propiedades del servidor. Haga clic en la ficha Seguridad (consulte el paso 10 más abajo). Seleccione la cuenta de acceso a buzones y desplácese hacia abajo en la lista de permisos. Asegúrese de que Ver estado del almacén de información ha heredado Permitir. Si tiene heredado Denegar, compruebe las propiedades de CN=Servidores, CN=suGrupoAdministrativo y CN=Grupos administrativos para localizar la denegación.

Éstos son los pasos en Edición de ADSI para la denegación explícita:

  1. Abra Edición de ADSI.
  2. En el panel izquierdo, en Raíz de consola, haga clic con el botón secundario en Edición de ADSI.
  3. Seleccione Conectar con.
  4. En la ventana Configuración de conexión, busque en la sección Punto de conexión y elija Seleccionar un contexto de nomenclatura conocido y, a continuación, en el menú desplegable, seleccione Configuración. Haga clic en Aceptar.
  5. En la ventana Raíz de consola, expanda el signo más junto a Configuración.
  6. Expanda el signo más junto a CN=Configuración, DC=.
  7. Expanda CN=Services.
  8. Expanda CN=Microsoft Exchange.
  9. Resalte CN=<suNombreOrg> y, a continuación, haga clic en Propiedades.
  10. Haga clic en la ficha Seguridad.
  11. Localice la cuenta de Acceso a buzones y compruebe que Enviar como o Recibir como no tiene definido el permiso en Denegar.

En la Edición de ADSI, compruebe que Enviar como y Recibir como no se han denegado en el nivel de grupo administrativo o en el servidor de Exchange.

Los problemas de servicio de directorio de Active Directory® también pueden producir errores intermitentes en el script de comprobación de inicio de sesión de MAPI. Se produce un error en el inicio de sesión de MAPI si no tiene acceso a un controlador de dominio o si el controlador de dominio no responde a tiempo. Inicie el servicio Operador de sistema de Exchange si no se ha iniciado. Compruebe la configuración de los buzones de agente y corrija los errores que haya en la configuración. Compruebe que se tiene acceso a los controladores de dominio del dominio y que los usuarios pueden iniciar sesión con Outlook.

También puede habilitar el registro en el servidor que ejecuta Exchange para ayudar a solucionar el problema. En el servidor que ejecuta Exchange, agregue la siguiente clave de registro (tipo DWORD) y defina el valor en 1:

\\HKLM\Software\Microsoft\Exchange MOM\DebugLS

noteNOTA:
Recuerde definir el valor en 0 cuando desee desactivar el registro.

Detenga y reinicie el servicio MOM en el servidor que está ejecutando Exchange. Asegúrese de conceder derechos completos de cuenta de acceso a buzones a %systemdrive%; en caso contrario no se realizará un registro útil en ExMPLS_LOG.txt. Asegúrese de eliminar el derecho posteriormente.

Espere hasta que se ejecute el script de comprobación de inicio de sesión de MAPI (espere por la noche) y busque un archivo denominado ExMPLS_LOG.txt que se encuentra en %systemdrive%. Este archivo de registro suele resultar útil para solucionar problemas de inicio de sesión de MAPI.

Si sigue teniendo problemas con el inicio de sesión de MAPI después de realizar estos pasos, llame al soporte técnico a usuarios de Microsoft (CSS) para solución de problemas adicional.

Los problemas con los scripts de comprobación de inicio de sesión de Microsoft® Office Outlook® Web Access 2003 y Microsoft Outlook® Mobile Access son otros de los problemas con los que a veces se encuentran nuestros clientes. El módulo de administración de Exchange proporciona diversos grupos de reglas en el grupo de reglas de supervisión de disponibilidad y estado que engloban la prueba de inicio de sesión sintética. Estos grupos de reglas simulan un inicio de sesión de buzón mediante una de nuestras tecnologías de movilidad como, por ejemplo, Outlook Web Access, Outlook Mobile Access o Exchange ActiveSync. Debido a la complejidad del proceso de inicio de sesión sintético, a veces vemos errores señalados en MOM que indican un error en el inicio de sesión incluso aunque realmente fuera posible iniciar sesión en Outlook Web Access mediante Internet Explorer. Un error de este tipo que encontramos con frecuencia dentro de esta categoría es el siguiente:

Descripción:

Error de inicio de sesión de OWA.

Dirección URL: no definida

No se puede medir la disponibilidad de OWA. Error inesperado.

No se puede encontrar ningún servidor virtual ni directorio virtual (SSL habilitado) en este servidor para formar una dirección URL válida. Intente proporcional la dirección URL en la clave de registro de direcciones URL personalizadas (consulte la guía de configuración para conocer los detalles).

A primera vista, parece que el inicio de sesión no fue capaz de encontrar el servidor virtual de Exchange. Por tanto, el inicio de sesión dio error. Sin embargo, sabe que tiene un servidor virtual de Exchange. Y utiliza Outlook Web Access cada día para comprobar el correo cuando está fuera de la oficina. Así que, ¿qué nos está diciendo este error realmente? La pista sutil del error anterior es la dirección URL devuelta, No definida. Para comprender mejor qué es lo que ocurre, dediquemos unos minutos a explicar cómo funciona el proceso de inicio de sesión sintético de Outlook Web Access.

El script de comprobación de inicio de sesión de Outlook Web Access inicia el proceso. Aunque el script tiene muchas tareas, las funciones principales son las siguientes:

  • Habilita una referencia al objeto de automatización OWAAvailability que se devuelve a objOwa.
  • Lee la siguiente clave de Registro y recupera los valores de las cadenas CustomURL y BEAccount: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange MOM\FEMonitoring\<FEServerName>
  • Transfiere el nombre de buzón y cualquier valor de customURL encontrado a objOwa.OWALogon.
  • Registra los resultados (éxito o error) en la consola del operador de MOM

La función del script OWALogon toma tres parámetros: el BEMailbox en que deseamos iniciar sesión, un valor de tiempo de espera y la dirección URL. Esta función se puede llamar varias veces, dependiendo de cuántas direcciones customURL se encuentren en el registro. La primera llamada siempre se realiza con un valor de URL NULO que finalmente prueba https://localhost y seguidamente se realizan llamadas en un bucle probando las direcciones customURL. Nos interesa la primera llamada con la dirección URL NULA.

La función de script OWALogon es responsable de transferir los argumentos recibidos al objeto de automatización objOwa.OWALogon, que hará el trabajo duro por nosotros. Dado que no transferimos los tres argumentos (dejando la dirección URL NULA), lo primero que objOwa.OWALogon debe hacer es llamar a un método que construirá una dirección URL para probar. Este método, GetExchangeURL, devolverá la dirección URL del buzón especificado. No obstante, cuando GetExchangeURL no es capaz de determinar la dirección URL del buzón transferido, devuelve NULL, registrando nuestro error no esperado.

Ahora que conocemos por qué se registra el error, puede ver por qué sugerimos que URL:línea no definida era una pista sutil. Como indicaba el error, no éramos capaces de determinar cuál era la dirección URL, por tanto se producía un error. Ahora aclararemos GetExchangeURL.

La primera vez que revisamos este código nos sorprendió la cantidad de trabajo que los desarrolladores habían dedicado a este método. Realmente, todo lo que tenemos que hacer es devolver https://localhost. ¿no es cierto? Depende. ¿Qué ocurre si tenemos diversos directorios virtuales o servidores de Exchange, cada uno publicado con su propia dirección URL (digamos de alojamiento)? Necesitamos conocer a qué servidor virtual pertenece el buzón para poder saber que estamos probando la dirección URL correcta. De acuerdo, así que no podemos hacer ninguna suposición y tenemos que poder crear la dirección URL correcta para el buzón de prueba. Aquí no disponemos de espacio para describir con detalle todo el proceso GetExchangeURL; no obstante, mencionaremos brevemente los pasos principales.

  • Obtener la dirección SMTP primaria de los buzones de prueba   Es una búsqueda simple de Protocolo compacto de acceso a directorios (LDAP) del buzón de prueba mediante samAccountName. El atributo proxyaddress se lee y se analiza en busca de la dirección que empieza por SMTP: (tenga en cuenta las mayúsculas, las direcciones no primarias estarán en minúsculas). Este valor se analiza a continuación para extraer el nombre de dominio. Para probar este paso, realice la siguiente búsqueda de LDAP y compruebe que se devuelve el buzón de prueba:
    (&(objectClass=user)(objectCategory=person)(samAccountName=testmailbox))
  • Buscar el directorio virtual   Más búsquedas de LDAP. Aquí no entraremos en mucho detalle ya que es muy genérico y poco interesante. El resultado final es una consulta para todos los servidores virtuales HTTP del servidor de aplicaciones de usuario.
    (&(objectCategory=msExchProtocolCfgHTTPVirtualDirectory)(folderPathname=MBX))
  • Comprobar el dominio SMTP del directorio virtual   Compruebe en el servidor virtual la presencia del atributo msExchDefaultDomain y compruebe si está configurado (de forma predeterminada no lo está). En caso afirmativo, compruebe si coincide con los dominios SMTP primarios o no primarios del buzón. Si msExchDefaultDomain no está definido, compruebe si la dirección SMTP primaria del buzón coincide con el dominio SMTP primario de la directiva de destinatario predeterminada. Por ejemplo, si en el buzón de prueba se marca mediante una directiva personalizada que utiliza @it.contoso.com, pero la directiva de destinatario predeterminada está configurada para marcar @contoso.com, se producirá un error.
    importantImportante:
    Esta situación es la causa más común de que GetExchangeURL devuelva NULL en los casos que nos encontramos en el soporte técnico a usuarios de Microsoft (CSS).
  • Comprobar que SSL está habilitado en el directorio virtual   Compruebe la presencia de la propiedad de metabase IIS://localhost/W3SVC/1/root/Exchange/AccessSSLFlags. Puede comprobar este valor mediante una herramienta del kit de recursos de Servicios de Internet Information Server (IIS) denominada Metabase Explorer. Para obtener más información sobre esta herramienta y otras en el kit de recursos de IIS, consulte en Knowledge Base el artículo 840671, The IIS 6.0 Resource Kit Tools (página en inglés). Para obtener más información sobre la propiedad AccessSSLFlags, consulte AccessSSLFlags Metabase Property (IIS 6.0) (página en inglés) en la sección IIS 6.0 Reference de IIS 6.0 Operations Guide.
  • Comprobar el valor de secureBindings   Obtenga la propiedad de metabase IIS://localhost/W3SVC/1/secureBindings y analícela. Si la propiedad secureBindings comienza con :<portNumber> (:443), el servidor virtual se define en “Todos sin asignar”, de modo que la dirección URL se define en https://localhost. Si la propiedad no empieza por un “:”, analice la dirección IP que se ha asignado a este puerto. Esta dirección IP se comprueba a continuación mediante una llamada de WMI a Win32_NetworkAdapterConfiguration y la propiedad IPAddress devuelta se compara con la dirección IP encontrada en la propiedad secureBindings. Si se encuentra una coincidencia, defina la dirección URL en https://direcciónip. Si no se encuentra ninguna coincidencia, se devuelve NULO. Nuevamente, puede utilizar Metabase Explorer para ver cómo está definida la propiedad. Si empieza por una dirección IP, puede utilizar WBEMTest para consultar la clase Win32_NetworkAdapterConfiguration y comprobar la propiedad IPAddress. Para obtener más información sobre la propiedad secureBindings, consulte SecureBindings Metabase Property (IIS 6.0) (página en inglés) en la sección IIS 6.0 Reference de la IIS 6.0 Operations Guide. Para obtener información sobre cómo usar WBEMTest, consulte Scripting Eye for the GUI Guy (página en inglés).

Si tras comprobar los pasos anteriores, sigue sin poder determinar por qué GetExchangeURL ha devuelto NULO, el servicio de soporte técnico a usuarios de Microsoft (CSS) dispone de una herramienta denominada OWACheck que puede resultar muy útil para solucionar este problema. Póngase en contacto con el servicio de soporte técnico a usuarios de Microsoft (CSS) para obtener esta herramienta y para ayuda adicional de solución de problemas.

Para obtener más información al respecto, consulte los recursos siguientes:

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