Exchange Queue & A: Migración de buzones
Mover y proteger los buzones de Exchange pueden ser difícil de negocio, especialmente entre bosques o de servidor de un dominio a otro.
Henrik Walther
Exchange virtualizado
P: Va a implementar la solución de mensajería de Exchange 2010 en servidores agrupados de Hyper-V y planeaba proteger las bases de datos de buzones con la base de datos de disponibilidad de grupos (DAGs). Hemos notado la siguiente instrucción en sección de Requisitos de Exchange 2010 en la documentación de TechNet, por lo que queremos oír los tienen sobre este:
“ Microsoft no es compatible con las soluciones de alta disponibilidad de Exchange de la combinación (base de datos de disponibilidad de grupos [DAGs] con basada en hipervisor de organización por clústeres, alta disponibilidad) o las soluciones de migración. DAGs son compatibles en entornos de virtualización de hardware siempre que el entorno de virtualización no utilizar a servidores agrupados de la raíz. ”
R: Tal como se indica en el paso anterior, no se admite la combinación de Exchange 2010 DAGs con virtualización de alta disponibilidad (HA). Debe utilizar la alta disponibilidad o la virtualización de alta disponibilidad de nivel de aplicación. En cuanto a Exchange 2010, se recomienda el nivel de aplicación de alta disponibilidad.
Si sólo dispone de servidores raíz de clúster y requieren el uso de d AG, a continuación, puede hacer que los miembros de d AG almacenados en un servidor agrupado de raíz de Hyper-V, siempre que se ha deshabilitado todas la virtualización de alta disponibilidad para los servidores virtuales de miembro d AG respectivos. Cuando que lea esto, la documentación de TechNet debe se actualizaron para reflejar esta nueva postura de soporte técnico.
Exchange de equilibrio de carga
P: Se va a diseñar la nueva infraestructura de Exchange 2010 y ha decidido utilizar un equilibrador de carga de hardware para ofrecer una alta disponibilidad y la distribución de la carga entre los servidores de acceso de cliente de la matriz de CAS. Para reducir la carga de trabajo SSL en nuestros servidores CAS y aprovechar las ventajas de los métodos de la afinidad al igual que la cookie y el ID de SSL, deseamos la descarga de SSL para el equilibrador de carga de hardware.
Sabemos que la descarga de SSL para Outlook Web Access (OWA), Outlook Anywhere (OA) y Exchange Web Services (EWS) es compatible, pero ¿qué acerca de Exchange ActiveSync (EAS)? Solicito que yo sé que esto no se admite en Exchange 2007 por (cómo configurar descarga de SSL para Outlook Web Access en Exchange Server 2007 de ).
R: En realidad, se admite la descarga de SSL para EAS tanto para Exchange 2007 y Exchange 2010. Nunca se actualizó la documentación de Exchange 2007 para reflejar esta declaración de soporte técnico.
Es importante tener en cuenta que sólo se admite en el punto de entrada (para servidores CAS en el sitio de Internet enfrentado) no está en un escenario de proxy CAS a CAS.
Migración entre bosques
P: Nos estamos está preparando realizar una migración entre bosques de Exchange 2003 a Exchange 2010. Hemos desarrollado un entorno de laboratorio que simule el entorno de producción para asegurarse de que las cosas funcionan según lo previsto.
En primer lugar, se prepara el bosque de destino con objetos válido de Active Directory mediante las instrucciones que aparecen en la documentación de Exchange 2010 TechNet ( de Preparación de buzones entre bosques se mueve con el MoveRequest.ps1-preparación de la secuencia de comandos en el shell). La secuencia de comandos se ejecuta correctamente y se puede ver en Active Directory los objetos se crean en el bosque de destino, pero se recibe el error se muestra en del 1 de la figura cuando se intenta mover un buzón heredado utilizando la opción mediante el comando siguiente:
New-MoveRequest -Identity 'cotestuser1@contoso.com -RemoteLegacy -TargetDatabaseMDB01 -RemoteGlobalCatalog 'DC1.contoso.com' -RemoteCredential $Cred -TargetDeliveryDomain 'fabrikam.com'
.jpg)
Figura 1 del Error de mover buzones entre bosques
¿Tiene alguna idea lo que no puede producir este error?
R: Excelente de control de tiempo, tenido este hace unos meses yo mismo durante una migración entre bosques de Exchange 2003 a Exchange 2010. Con la Ayuda de Dmitri Gavrilov (que un principal de desarrollo lead en el equipo de buzón de Exchange en el grupo de producto de Exchange), me di cuenta era porque no hay ninguna resolución de NetBIOS entre los dos bosques de Active Directory.
Al llevar a cabo un buzón entre bosques, se mueve con el nuevo-MoveRequestcmdlet, el servidor de Exchange 2010 en el bosque de destino desde el que se ejecuta el comando debe ser capaz de alcanzar el servidor de buzón de origen de la organización de Exchange 2003 utilizando su nombre NetBIOS. Esto es debido a que el nuevo-MoveRequestcmdlet intentará conectarse al servidor de origen utilizando el LegacyDN, que normalmente contiene sólo el nombre NetBIOS del servidor. Por lo tanto, debe en WINS en el programa de instalación o utilizar archivos de host a fin de evitar este mensaje de error.
Cualquier puerto de una tormenta
P: He leído en varios orígenes que cuando se utiliza un equilibrador de carga de hardware para proporcionar alta disponibilidad y en Outlook el cliente de distribución de carga en todos los servidores de acceso de cliente de la red interna, se debe abrir los puertos siguientes para la conectividad de Outlook para que funcione correctamente: El asignador de extremos de TCP (TCP: 143) y el rango RPC dinámico-1024 de TCP/UDP - 65535. ¿Es correcto? Pensé que Exchange 2010 no admite el protocolo de datagramas de usuario (UDP).
R: Más adecuada. Con Exchange 2010, ya no admite UDP. Se Don necesita abrir UDP: sólo TCP. Esto también es true para que Outlook 2003, incluso cuando Outlook intenta utilizar las notificaciones de UDP inicialmente. Si ve que Exchange Server no responde a UDP, vuelve a sondear Exchange Server utilizando TCP. El problema es que los clientes de Outlook 2003 en el modo en línea sólo sondean cada 60 segundos, lo que produce los síntomas siguientes:
- Los mensajes salientes de correo electrónico permanecen en la Bandeja de salida de un minuto.
- Mensajes de correo electrónico no llegan en la Bandeja de entrada de un minuto.
- No desaparecen de la carpeta Elementos eliminados de las carpetas de un minuto.
- Los elementos que se han movido de una carpeta a otra carpeta tardar un minuto para que desaparezca de la carpeta original.
Si tiene clientes de Outlook 2003 en modo con conexión, tendrá que corregir este problema siguiendo los pasos descritos en el siguiente artículo de Knowledge Base: En Outlook 2003, los mensajes de correo electrónico tardan mucho tiempo para enviar y recibir cuando utiliza un buzón de Exchange 2010.
Protección de buzón
P: Está diseñando actualmente nuestra infraestructura Exchange 2010. Uno de los requisitos es tener alta disponibilidad en todos los niveles, por lo que se va a proteger las bases de datos de buzones mediante DAGs y equilibrador de carga de los servidores de acceso de cliente utilizando una matriz de acceso de cliente y un hardware redundante.
También planeamos publicar el servidor de acceso de cliente a Internet a través de una matriz de Forefront Threat Management Gateway (TMG). Estoy algo no está seguro acerca de cómo publicar los servidores CAS a Internet en la forma correcta. ¿Deberíamos sólo tiene que señalar las reglas de publicación de Web de ISA en el equilibrador de carga de hardware de la red interna y deje que el equilibrador de carga de hardware de distribuir el tráfico de cliente a través de los servidores CAS?
R: Se trata de una buena pregunta. Déjeme explicarlo. Al utilizar TMG (o UAG en este caso) para publicar los servidores de Exchange 2010 CAS, usar de funciones de equilibrio de carga de batería de servidores de servidor Web incluidos con TMG. Simplemente no seleccione las reglas de publicación de Web en el equilibrador de carga de hardware de la red interna.
En un escenario típico, cuando TMG recibe una solicitud de cliente, TMG cambiará el campo de dirección IP de origen en el encabezado IP a la dirección IP configurada en su interfaz interna. Esto significa que todas las solicitudes de cliente procesadas como proxy de TMG al equilibrador de carga de hardware se parecen proceder de la misma IP de cliente. Esto hace que la HLB enviar todas las solicitudes de cliente para el mismo servidor CAS en lugar de distribuirlos entre los servidores CAS en la matriz de CAS de Exchange 2010.
Algunos podrían decir sólo se puede cambiar el comportamiento de solicitud de proxy de “ las peticiones parecen provenir del equipo servidor ISA ” a “ las peticiones parecen provenir del cliente original ” como se muestra en de figura 2, pero no que es sencillo. Si lo hace, deberá establecer la TMG como puerta de enlace predeterminada (o utilizar rutas estáticas, consulte de figura 2) en cada servidor CAS, que puede ofrecer a otras tareas. La mayoría de las empresas también utilizan NAT de todas formas, lo que significa que el origen de que IP se parece provenir del mismo cliente (dirección IP del dispositivo NAT), incluso si se establece la TMG como puerta de enlace predeterminada en los servidores CAS.
.jpg)
La figura 2 de comportamiento de solicitud de proxy TMG
Aunque TMG proporciona una capa adicional de seguridad y le permite realizar una autenticación previa de los clientes antes de que sean procesadas como proxy para los servidores CAS, es importante tener en cuenta que la funcionalidad de equilibrio de carga de batería de servidores del servidor de TMG Web tiene las mismas limitaciones que Equilibrio de carga de red Windows cuando se trata de afinidad. Utiliza el componente de NLB de Windows, lo que significa que está limitado a afinidad basada en IP de origen y no puede aprovechar los métodos de afinidad como cookies o SSL-Id.
Buzones en movimiento
P: Nos hemos implementado Exchange 2010 en un bosque de Active Directory que se compone de un dominio raíz y varios dominios secundarios. Hay servidores de Exchange 2010 en cada dominio secundario y, a veces es necesario mover buzones entre servidores de buzones en dominios diferentes. Se utilizan tanto como sea posibles de comandos de shell de administración de Exchange.
También queremos usar el cmdlet New-MoveRequest para mover buzones entre los dominios secundarios, pero al hacerlo, no podemos observamos los buzones de uno de los otros dominios. El comando finaliza, pero no muestre los buzones. Además, se obtiene un error al intentar mover los buzones, ya que no se puede ver desde el shell de administración de Exchange. ¿Tiene alguna idea lo que está ocurriendo?
R: Cuando se utiliza el comando de shell de administración de Exchange 2010, el ámbito de destinatario predeterminada se establece en el nivel de dominio. Esto significa que se mostrarán sólo los buzones locales cuando se ejecuta algo parecido al cmdlet Get-Mailbox. Para cambiar el ámbito de destinatario para todo el bosque, debe ejecutar el comando siguiente (consulte de figura 3): Conjunto-ADServerSettings - ViewEntireForest: $ true
.jpg)
La figura 3 de cambiar el ámbito de destinatario predeterminada
_***Henrik Walther****es un principal de Microsoft Certified: Exchange 2007 y MVP de Exchange con más de 15 años de experiencia en el sector de TI. Trabaja como un arquitecto de tecnología forTimengoConsulting (un Microsoft Gold Certified Partner en Dinamarca) y como escritor técnico para Biblioso Corp. (una empresa estadounidense especializada en servicios de documentación y localización administrados). Para enviar por correo electrónico Walther en v-henwal@microsoft.com de . * _