Exchange Queue & A Recuperar un servidor de buzones en clústeres, problemas de libreta de direcciones sin conexión y mucho más
Henrik Walther
QNuestra infraestructura de mensajería se basa en Exchange 2007 SP1. Todos los servidores de Exchange 2007 Service Pack 1 se han instalado en Windows Server 2008. Contamos con dos centros de datos, los centros de datos principal y una copia de seguridad que podemos conmutación por error un desastre debe alcanzar el principal. En nuestro centro de datos principal, todos los servidores de buzón se basan en replicación continua de clúster (CCR) para ofrecer una solución de alta disponibilidad local. Para conmutaciones por buzón servidor error de los centros de datos principal a los centros de datos copia de seguridad, utilizamos la replicación continua suspensión (SCR). Esto significa que todo los en función de la CCR agrupados servidores de buzones (CMSs) en los centros de datos principal también actúan como orígenes de SCR. Cada origen de SCR tiene destinos SCR correspondientes en el centro de datos copia de seguridad en forma de los clústeres de reserva en el que sólo la pasiva buzón función de servidor ha sido instalada
Recientemente hicimos una prueba de conmutación por error de sitio entre los dos centros de datos y, por desgracia, ejecutamos en un problema al intentar recuperar las CMSs a los clústeres de reserva. Cuando se ejecuta Setup.com / con el /RecoverCMS conmutador, se obtuvo el mensaje de error que se muestra en Figure 1 .
Figura 1 configuración de un error al recuperar CMS a un clúster de reserva
Se pregunte si se ha visto este error al recuperar un CMS para un clúster de reserva y, lo que es más importante, si tiene una solución para él.
ASí, tuve la misfortune de encontrarse con este problema al intentar recuperar un CMS a un clúster de reserva. Afortunadamente, esto fue también durante una prueba de conmutación por error nivel de sitio. (¿Es necesario explicar por qué es importante probar sus soluciones de conmutación por error?)
Una cosa que obtuvo me pensar en era que había probado la misma configuración muchas veces antes sin problemas. Sin embargo, todas las pruebas de recuperación anteriores eran con Exchange 2007 SP1 instalado en Windows Server 2003 y no Windows Server 2008, tal como era el caso cuando presione este problema.
Me a descubrir cómo trabajo comparado con clústeres de Windows Server 2003, en función de clústeres de conmutación por error de Windows Server 2008 llevó. En Windows Server 2003, ha creado y había dedicado una cuenta de servicio de Cluster Server al clúster. En Windows Server 2008, ya no hacerlo; en su lugar, se ejecuta el clúster de conmutación por error en el "sistema local". Cuando examinar la aplicación y el sistema inicia una sesión en el clúster de reserva en el que al intentar recuperar el CMS, encontró el error que se muestra en la figura 2 .
La Figura 2 error de recuperación due to permisos inadecuados
Este error de identificador de evento explica que el clúster de conmutación por error de Windows no tiene los permisos necesarios actualizar la cuenta de equipo CMS en Active Directory. También muestra tres posibles razones. Puesto que se está recuperar un CMS existente en un clúster en espera, se puede omitir la primera uno. Puesto que hemos no ha llegado las cuotas para el número de objetos de equipo, se puede omitir así número dos. El último elemento, sin embargo, es muy interesante. Indica a nosotros para comprobar que el clúster de conmutación por error de Windows en el que se recuperar el CMS tiene permisos de "Full Control" al objeto de cuenta de equipo CMS.
Un aspecto en la ficha Seguridad en la página de propiedades del objeto de equipo CMS en los usuarios de Active Directory y equipos revela que el clúster de espera no tiene permisos de "Full Control" (Figure 3).
La figura 3 el clúster de espera no tiene permisos de “ Full Control ”
Agregar el clúster de reserva con permisos de "Full Control" al objeto de equipo CMS resolver el problema para mí y debe hacer lo mismo en su entorno.
En el momento de redactar este documento (el final de febrero), no hay ninguna información sobre este problema en lugares públicos como TechNet o en los artículos de Knowledge Base. Sin embargo, mi buen amigo Tim McMichael servicios de soporte al cliente de Microsoft de escribe una entrada de blog en este tema que se incluye en mucho más detalles que puedo hacer aquí. Por lo que se vuelva ir visite del Tim blog para obtener más información " Permisos recomendados para el CNO (objeto de nombre de clúster) en Windows 2008 para operaciones de instalación de Exchange 2007 SP1.").
QEstamos actualmente en el proceso de elaborar una solución de conmutación por error de nivel de sitio. Para nuestra infraestructura de mensajería de Exchange 2007 SP1, en función, vamos a utilizar la replicación continua de reserva (SCR) como la solución de recuperación ante desastres entre nuestro centro de datos principal y de reserva. Puesto que sólo algunos de nuestros usuarios finales se han actualizado a Office Outlook 2007 con el resto todavía en Outlook 2003, tenemos una pregunta. ¿Cuando se produce una conmutación por error de los servidores de Exchange 2007 Service Pack 1 de los centros de datos principal en los centros de datos copia de seguridad, se ambas versiones de Outlook recogidas simplemente los cambios después de realizar los pasos de conmutación por error de sitio SCR necesarios?
AMuy buena pregunta y, en realidad, la respuesta depende si estás utilizando portabilidad RecoverCMS o base de datos para la conmutación por error los servidores de buzones para los centros de datos copia de seguridad. Si se tiene servidores de buzones independientes en los centros de datos principal y replican a servidores de buzones independientes en el centro de datos copia de seguridad mediante SCR, a continuación, utilizaría la portabilidad de base de datos para la conmutación por error el Mailbo x bases de datos. Si tiene clústeres de copia única (SCC) o servidores de buzones de CCR en los centros de datos copia de seguridad principal y espera clústeres en los centros de datos copia de seguridad, podría utilizar el modificador RecoverCMS para recuperar el CMS completo a los centros de datos copia de seguridad. Cuando se utiliza RecoverCMS como mecanismo de conmutación por error, normalmente no es necesario que preocuparse de conectividad de clientes de Outlook después de la conmutación por error. Tenga en cuenta que cambie la dirección IP del CMS. Pero si ha configurado el período de DNS valor Live (TTL) a cinco minutos según a recomendaciones de prácticas recomendadas, tenga en cuenta que habrá un retraso ligero antes de que los clientes de Outlook podrá volver a conectar con el CMS.
Si estás utilizando portabilidad de la base de datos como el mecanismo de recuperación, la situación es un poco diferente, dependiendo de la versión de cliente de Outlook. Los clientes de Outlook 2007 reflejará los cambios automáticamente mediante el servicio de detección automática que se ejecuta en los servidores de acceso de cliente. Esto significa que no debe hacer los cambios manuales para esta versión de Outlook. Sin embargo, no es necesariamente el caso con los clientes de Outlook 2003. Cuando se ha recuperado un buzón de otro servidor, el nombre del servidor almacena las bases de datos buzón Obviamente será diferente.
¿Es posible que pregunte, esta cuestión cuando se usa el cmdlet Move-Mailbox con el –ConfigurationOnly cambiar después de la conmutación por error? Sí, sigue importa debido a que Outlook 2003 no admite el servicio de detección automática. Esto significa que el servidor original en los buzones se almacenaron antes de que la conmutación por error debe ser en línea para que se puede actualizar el nombre del servidor en el perfil de MAPI de Outlook. Si el servidor original está sin conexión, el nombre del servidor no se actualizarán automáticamente.
Por lo tanto, si se está enfrentan un desastre donde se sin conexión todos los servidores en los centros de datos principal, deberá volver a configurar los perfiles de MAPI de Outlook 2003 con una herramienta como el redirector de perfil (ExProfre) de Microsoft Exchange Server en combinación con un script de inicio de sesión para reflejar los cambios. Merece la pena tener en cuenta que si todos los clientes se encuentran en los centros de datos principal, deberá reconstruirlos de todos modos.
QEn nuestra infraestructura de mensajería de Exchange 2007 SP1, en función, todos nuestros servidores de buzones son la replicación continua de clúster (CCR) - habilitado. Hemos instalado cuatro tarjetas de interfaz de red (NIC) en cada nodo del clúster. Dos NIC han se ha asociado y están conectadas a la red pública, que acepta las solicitudes de cliente de Outlook y así sucesivamente. La tercera tarjeta de interfaz de red se utiliza para la red de latido entre los nodos de clúster de dos de la CCR. La cuarta tarjeta NIC es hay específicamente para propósitos de trasvase de registros. Mediante el cmdlet Enable-ContinuousReplicationHostName que se introdujo en Exchange 2007 SP1, nos tener (para lograr la redundancia de envío de registro) especifica que se pueden utilizar tanto el latido y la red de envío de registro dedicado para enviar los archivos de registro de activo en el nodo pasivo. Este funciona realmente y gran reduce el tráfico en la red pública, especialmente en situaciones donde una reinicialización de uno o más buzones bases de datos son necesarios (aunque debería ser muy raro).
También tenemos SCR habilitada entre estos servidores de buzones en función de la CCR y varios destinos SCR en nuestro centro de datos copia de seguridad. Esto conduce a nuestro pregunta. ¿Es posible usar el cmdlet Enable-ContinuousReplicationHostName con SCR?
AEstoy congratula que ha sido útil para el cmdlet EnableContinuousReplicationName. Sin embargo, desde este cmdlet se creó específicamente para las soluciones CCR, la respuesta a su pregunta es, desafortunadamente, no, actualmente que esto no se admite en una solución SCR.
QSólo se dispone de transición de Exchange 2003 a Exchange 2007 SP1. Funciones de servidor Exchange 2007 SP1 todas se ejecutan en Windows Server 2008 y nuestros servidores de buzones de Exchange 2007 se basan en CCR.
Las cosas funcionan muy bien hasta ahora pero se ha observado un problema con el sin conexión direcciones Libreta (OAB). Cuando se se actualiza con nuevos objetos de correo, las actualizaciones no se reflejan en Outlook 2007 a los usuarios finales. Se ha se solucionar el problema y ha encuentra 1021 de ID. de evento en el registro de aplicación en los servidores de acceso de cliente con la siguiente descripción:
Process MSExchangeFDS.exe (PID=xxxx). Could not find directory <OAB share location>
This is normal if the directory has never been generated. Otherwise, make sure this directory
and share has read permission for the "Exchange Servers" group.
Hemos tratado de copiar la libreta de direcciones sin conexión manualmente desde el servidor en función de la CCR buzón donde está hospedado en el servidor de acceso de cliente. Esto da como resultado las actualizaciones en Outlook, pero nos gustaría obtener el problema fijo de forma permanente. ¿Tiene la receta?
AHe hacia abajo que carretera, demasiado. El motivo de este problema es debido el comportamiento de los clústeres de conmutación por error de Windows 2008. Clústeres de conmutación por error de Windows 2008 presenta un nuevo concepto denominado ámbito compartido. Básicamente, significa ámbito compartido que un recurso compartido de archivos es específico a ser el nombre de un nodo o a una del clúster de nombre objetos que de los hosts de recurso compartido. Cuando un recurso compartido se comparte con el nombre de nodo, no se puede tener acceso al nombre de servidor de buzones de clústeres (CMS). Para obtener información más geeky detallada sobre el ámbito de recurso compartido de archivo, vea esta entrada en la consultar el blog del equipo principal " Archivo de recurso compartido 'Ámbito' en clústeres de Windows Server 2008 la conmutación por error").
Para resolver el problema, deberá instalar Exchange 2007 Service Pack 1 informe de actualización de 5 o posterior, que incluye la corrección de errores necesaria. Vea también el artículo" CAS de Exchange 2007 no puede copiar la libreta de direcciones sin conexión desde el recurso compartido Libreta de direcciones sin conexión en clústeres de Windows Server 2008-basado Exchange 2007 CCR." Dado que esta actualización informe aporta algunas regresiones con ella, es importante que lea el artículo informe de actualización de 5 KB estrechamente antes de utilizar esta solución.
Henrik Walther es un principal de certificado de Microsoft: Exchange 2007 y MVP de Exchange con más de 15 años de experiencia en el negocio de TI. Trabaja como un arquitecto de tecnología de Trifork infraestructura Consulting (un socio de oro de Microsoft en Dinamarca) y como un escritor técnico para Biblioso Corporation (una compañía de estados UNIDOS en función que está especializada en servicios de documentación y localización administrados).