Cola de Exchange & R: las migraciones y actualizaciones
Al migrar de un grupo a otro, las actualizaciones no siempre son automáticas, ni deseadas.
Henrik Walther
Exchange 2010 y Hyper-V
**Q.**Estamos planeando implementar Exchange Server 2010. Política de empresa establece que todos los nuevos servidores deben ser máquinas virtuales (VMs) que se ejecuta con Hyper-V. A fin de aumentar la disponibilidad de servicios y las aplicaciones, los servidores raíz de Hyper-V participan en clústeres de conmutación por error de Hyper-V.
Recientemente hemos visto este blog publicar en el blog del equipo de Exchange de Microsoft anuncio de soporte de virtualización de hardware mejorado para Exchange 2010. Especialmente encontramos la siguiente declaración interesante:
"La combinación de soluciones de alta disponibilidad de Exchange 2010 (grupos de disponibilidad de base de datos [además]) con clustering basado en hipervisor, alta disponibilidad, o soluciones de migración que se moverán o automáticamente servidores de buzones de conmutación por error que son miembros de un DAG entre servidores en clúster raíz, ahora soporta."
Es una buena noticia para nosotros, ya que significa que ahora podemos implementar servidores de buzón de Exchange 2010 participando en un DAG como máquinas virtuales en un clúster de conmutación por error de Hyper-V. ¿Hay alguna otra cosa que deberíamos ser conscientes de ello?
**A.**Bien, sin duda, había programado la implementación de Exchange 2010. Está absolutamente correcto que ahora soporta Microsoft combina además con tecnología de clustering y migración de failover basado en host. Esto se aplica no sólo a Hyper-V, pero cualquier proveedor de virtualización de hardware que participan en el Programa de validación de virtualización de Windows Server (SVVP).
Sin embargo, hay un par de puntos importantes a tener en cuenta si planea miembros DAG migración en vivo. Necesita Exchange 2010 SP1 o posterior para este soporte. Ha también recomienda utilizar discos no paso y volúmenes de clúster compartido. Cuando el equipo de Hyper-V y el grupo de producto de Exchange probaron cada método, observaron el tiempo sin conexión asociado al mover los recursos de almacenamiento de información fue reducir a la mitad por el uso de volúmenes de clúster compartido.
Si el tiempo offline servidor excede cinco segundos, el nodo de DAG será desalojado del clúster. Por lo que es importante asegurarse de que el clúster de conmutación por error de Hyper-V puede migrar recursos en menos de cinco segundos. Si no puede, ajustar el tiempo de espera de latido de clúster a un valor más alto. Usted no debe establecer superior a 10 segundos, aunque.
También debe asegurarse de que ha aplicado las revisiones más recientes relacionados con Hyper-V a los servidores Hyper-V. En cuanto a la migración en vivo de red, asegúrese de tramas jumbo están habilitados y los conmutadores que admiten tramas jumbo. También se recomienda que cambie el búfer de recepción en cada host de Hyper-V en 8192. Además, debe implementar tanto ancho de banda posible para la red de migración en vivo (5 GB o mayor es preferible).
Es importante configurar cada VM guardar y restaurar el estado del disco cuando se mudó o fuera de línea. Cualquier failover debe hacer un arranque en frío cuando el nodo de destino se ejecuta en una máquina virtual. Un proceso de migración planificada también debe incluir un inicio apagado y frío. La acción sin conexión controlada de clúster se establece en "Guardar estado" por defecto. En su lugar, debe establecerse en "Cerrar" (véase figura 1) para que el servidor frío inicia cuando live-migrar de un nodo de Hyper-V a otro.
.jpg)
Figura 1 acción sin conexión controlada por Cluster consiste en "Shut down.”
El recientemente publicado "Las mejores prácticas para virtualizar Exchange Server 2010 con Windows Server 2008 R2 Hyper-V" libro blanco incluye un montón de buena información acerca de la virtualización de Exchange 2010 usando Hyper-V. Y, por último pero no menos importante, el la documentación de Exchange 2010 en TechNet se ha actualizado para reflejar esta nueva postura de apoyo.
Registrar FQDN
**Q.**Ha implementado Exchange 2010 y tiene un total de 12 funciones de servidor de acceso de cliente (CAS). Utilizamos un modelo de centro de datos de distribución de usuario activo/pasivo. Esto significa que tenemos un centro de datos principal y un centro de datos de conmutación por error. Hay seis funciones de CAS en cada centro de datos. Utilizamos una solución del equilibrador de carga basado en hardware para cargar el tráfico de acceso de cliente de equilibrio en cada centro de datos. Tenemos aproximadamente 50.000 usuarios, con la mayoría que se conectan a su buzón con clientes de Outlook 2007/2010 internos.
Recientemente vimos este blog post en el Blog del equipo de Exchange, que recomienda a todos los clientes de habilitar la autenticación Kerberos para clientes internos de Outlook y explica por qué. Debido a esta recomendación, estamos planeando habilitar la autenticación Kerberos para los clientes de Outlook internas en nuestra organización.
Aunque hemos leer la entrada de blog en detalle y retirado la documentación pertinente de Exchange 2010 en TechNet, seguimos siendo un poco las dudas en la hora a la que plenamente calificado los nombres de dominio (FQDN) es necesario registrarse como nombres de principales de servicio (SPN). ¿Qué pasa con el FQDN de descubrir automáticamente? ¿Necesitamos registrar este FQDN así?
**A.**Puedo entender por qué está un poco confundido sobre el FQDN de descubrir automáticamente. Mayoría de los clientes tiene un FQDN, usualmente llamado detección automática de detección automática..com (companyname). Este FQDN es para clientes externos (principalmente dispositivos de Outlook en cualquier lugar y Exchange ActiveSync) para la creación automática de perfiles.
Varias características de Outlook 2007/2010 se basan en el servicio de detección automática (Asistente para fuera de oficina [OOF], libreta de direcciones sin conexión [OAB] y [UM] de mensajería unificada). Los clientes de Outlook 2007/2010 internos no usan este FQDN de detección automática, aunque. Buscar el punto de conexión de servicio de Active Directory utilizando el servicio Detección automática Uniform Resource Identifier (URI), que, por defecto, señala el FQDN de CAS (véase figura 2).
Cuando se utiliza una solución de equilibrador de carga para distribuir el tráfico de clientes entre CASs en una matriz de CAS, se suele definir el servicio Detección automática URI a la dirección IP virtual (VIP) asociados con el servicio virtual respectivo en el equilibrador de carga. Algunos clientes utilizan un nombre de dominio completo dedicado. Otros sólo utilizan el mismo FQDN para Outlook Web App (OWA), Panel de Control de cambio (ECP), OAB y servicios Web de Exchange (EWS).
.jpg)
Figura 2: FQDN para el servicio interno de detección automática de URI.
Actualizaciones de extremo
**Q.**Tenemos una solución Exchange 2010 sitio resistente con datacenter una primaria y conmutación por error. Recientemente hicimos un cambio de datacenter prevista para comprobar los pasos en nuestro plan de recuperación ante desastres de centro de datos. Durante la transición, notó algo. Aunque los clientes Outlook internos pueden conectar bien después de haber cambiado el registro DNS para la matriz de CAS en el centro de datos principal, por lo que se señala en la matriz de CAS en el centro de datos de conmutación por error, el extremo de conexión nunca fue actualizado en los clientes.
¿Cuando la matriz de CAS no está disponible en el centro de datos principal, y se actualiza el registro DNS para esta matriz CAS que apunte a la matriz de CAS en el centro de datos de conmutación por error, no espera que el comportamiento que se actualiza el extremo de la conexión en el cliente de Outlook, así?
**A.**Lo que se ve es realmente el comportamiento esperado. El extremo de conexión no / no se actualiza cuando cambia el registro DNS para la matriz de CAS en el centro de datos principal a la dirección IP asociada con la matriz de CAS en el centro de datos de conmutación por error. Como se ha visto usted mismo, los clientes de Outlook se conectarán bien mientras resuelve el nombre de matriz de CAS a dirección IP accesible.
Este comportamiento hace que las cosas menos doloroso cuando se hace el cambio de centro de datos. Sólo tiene que cuidar de la replicación de DNS: no hay que preocuparse si un cliente de Outlook tiene su perfil actualizado.
Actualizaciones de perfil
**Q.**Tenemos varios sitios de Active Directory, todas con servidores Exchange 2010 SP1. Cada sitio tiene tres funciones de CAS. Para distribuir el tráfico de clientes entre las tres funciones de CAS en cada sitio, creamos CAS matrices y además proporcionar resiliencia de buzón.
A veces, un usuario permanentemente se mueve de un sitio físico a otro. En este evento, nos movemos el buzón del usuario a una base de datos de buzones de correo en el sitio nuevo. Porque pasamos el buzón del usuario de una base de datos de buzones de correo con un valor de servidor de acceso de cliente de RPC diferente del valor de la base de datos de destino, esperamos que perfil de Outlook del usuario se actualizará para reflejar el valor RPC CAS de la base de datos del buzón de destino (véase figura 3).
.jpg)
Figura 3: valor de servidor de acceso de cliente de RPC para una base de datos de buzones de correo.
No tenemos ningún cliente de Outlook 2003, único 2007 y 2010. Hasta ahora, sólo hemos podido tener el perfil de Outlook actualizado mediante la ejecución de una reparación de perfil.
**A.**Entiendo cómo era de esperar el perfil de Outlook para actualizar automáticamente durante un movimiento de buzones entre sitios de una base de datos de buzones de correo con un valor de CAS de RPC a una base de datos del buzón de destino con otro valor de CAS de RPC. En realidad, sin embargo, lo que tiene es el comportamiento esperado.
La razón de este comportamiento tiene que ver con el hecho de que el origen de CAS (matriz) determina qué buzón debe obtener acceso basado en las propiedades de Active Directory. Si Active Directory está actualizado, nunca habla con la base de datos del buzón mal y nunca recibir la respuesta de anecWrongServer, que es necesario para activar una actualización de perfil de Outlook. El grupo de producto de Exchange es plenamente consciente de este comportamiento lejos del ideal. No existe palabra aún respecto a cuándo, o incluso si — se arreglará.
Confíe pero verifique
**Q.**Estamos tratando de establecer una Federación entre nuestro grupo de Exchange 2010 y otro. Me parece recordar que necesita utilizar un certificado de una autoridad de certificación de terceros (CA) de confianza para establecer confianzas de Federación entre organizaciones de Exchange 2010. Quería comprobar si esto es cierto.
**A.**Probablemente leas esto antes de Exchange 2010 SP1 fue puesto en libertad. Con Exchange 2010 RTM, era necesario un certificado de confianza de una CA de terceros para obtener una confianza de Federación trabajando entre dos organizaciones de Exchange 2010.
Sin embargo, esto cambió con el lanzamiento de Exchange 2010 SP1. Con Exchange 2010 SP1, puede utilizar un certificado autofirmado o un certificado emitido desde una PKI interna. En realidad, el Asistente de "Nueva Federación confianza" automáticamente crea e instala un certificado autofirmado específicamente para fines de confianza de Federación (véase figura 4).
.jpg)
Figura 4 el nuevo certificado autofirmado creado por el asistente "nueva Federación confiar".
.jpg)
Henrik Waltheres un Microsoft Certified Master: Exchange 2007 y Exchange MVP con más de 15 años de experiencia en el negocio de TI. Trabaja como arquitecto de tecnología de Timengo Consulting (Microsoft Gold Certified Partner en Dinamarca) y como escritor técnico para Biblioso Corp. (una compañía norteamericana especializada en administrar servicios de documentación y localización).