Preguntas y respuestas acerca de Exchange

  • Artículo

Transiciones y migraciones

Henrik Walther

T ransitions y migraciones parecen en un gran número de las mentes de gente. En esta instalación, responden a preguntas acerca del traslado desde Exchange 2003 a Exchange 2007, así como desde cualquiera de ellas para Exchange 2010.

I Nuestra empresa utiliza Lotus Domino para mensajería. Sin embargo, tenemos previsto mover a Exchange.Because Exchange 2010 es simplemente alrededor de la esquina, nos estamos pensando omitiendo Exchange 2007 y en su lugar la migración directamente a Exchange 2010. Con esto está presente, tenemos una pregunta para usted: ¿Microsoft actualizará Microsoft Transporter Suite para compatibilidad con Exchange 2010 o proporcionará otra herramienta de migración y coexistencia?
G  

El equipo de Exchange no agregará compatibilidad para Exchange 2010 en el Microsoft Transporter Suite. En su lugar, utilizará herramientas socio para entregar la característica establecer necesaria para una migración Domino-to-Exchange. Por ejemplo, es ayudar a socios con actualizaciones así su coexistencia de Domino a Exchange / herramientas de migración funcionan correctamente con Exchange 2010. Además, el equipo de Exchange se asegurará de que funcionalidad espacios de direcciones de los asociados.

Sin embargo, tenga en cuenta que puede migrar sin utilizar herramientas de socio que admiten Exchange 2010. Para ello, se podría implementar un servidor de Exchange 2007 para utilizar como un salto de migración. Es decir, agregar un servidor de Exchange 2007 a la infraestructura y, a continuación, configurar el Transporter Suite en él. Migrar primero los datos de Domino a ese servidor y, a continuación, desde allí a servidores de Exchange 2010.

Por último, tenga en cuenta que Microsoft admitirá Transporter Suite durante la vida de Exchange 2007, extendido de soporte técnico de que termina en 2017. Así, todavía tiene unos pocos años para realizar la migración con el Transporter Suite.

 
I Sé que Exchange 2007 lanzamiento a fabricación (RTM) y SP1 no admiten la versión 2 de Windows PowerShell, pero le Exchange 2007 SP2? estoy solicitando porque planeamos administrar Exchange 2007 y los servidores de 2010 con las herramientas de administración de Exchange equivalentes desde el mismo servidor.
G

Sí, Exchange 2007 SP2 será compatible con Windows PowerShell v2 para ese propósito exacto. Dado que Microsoft admite la instalación de Exchange 2007 y herramientas de administración de 2010 en el mismo servidor (consulte de figura 1), y lo que facilita la administración de Exchange 2007 y 2010 desde la misma posible de servidor, compatibilidad con Windows PowerShell v2 en Exchange 2007 SP2 tenía sentido.

Pero tenga en cuenta que Exchange 2007 SP2 no podrá aprovechar nuevas características, como PowerShell remoto, en Windows PowerShell v2. Simplemente significa que puede instalar Windows PowerShell v2 en lugar de Windows PowerShell v1. El conjunto de características de Windows PowerShell de Exchange 2007 seguirá siendo la misma.

Figura 1: Un único servidor puede admitir herramientas de administración de Exchange 2007 SP2 y Exchange 2010.

I

Tenemos previsto para la transición de Exchange 2003 a Exchange 2007. Antes de que hacemos, deseamos actualizar nuestros controladores de dominio a Windows Server 2008 comobueno como cambiar los dominios y bosques niveles funcionales de Windows 2003 al modo nativo deWindows 2008.En nuestra investigación, encontramos documentación)TechNet.Microsoft.com/library/bb232170.aspx) que nos indica que el servidor de Exchange 2003 ya no funcionará como se esperaba si cambiamos el entorno de Active Directory al dominio de modo nativo de Windows Server 2008.

¿Haría arrojar alguna luz sobre por qué Microsoft no admite el cambio del entorno Active Directory al modo nativo de Windows Server 2008?
G  

El artículo es correcto, y aquí es por qué. En primer lugar, Microsoft ha creado Exchange 2003 (así como sus service packs) long antes de que se desarrollaron los entornos de Active Directory basado en Windows 2008 y Windows Server 2008. Por supuesto, esto, significa que el grupo de productos de Exchange no tenía ninguna posibilidad de codificación o pruebas contra un entorno de Active Directory basado en Windows Server 2008 mientras desarrollan Exchange 2003.

Dado que ha finalizado el soporte técnico de Exchange 2003 (aunque soporte técnico extendido se ejecuta a través de mediados 2014), dedicar recursos de pruebas para este escenario no tiene sentido.

La conclusión es que el equipo de Exchange no sabe si se interrumpirá ninguna funcionalidad de Exchange 2003 en un entorno de Active Directory basado en Windows Server 2008. Pero esto es cierto: Se debe algo interrumpir, las posibilidades de cambiar el código de Exchange 2003 de Microsoft que lo corrija son finos en ninguno.

 
I  

¿Nos hemos sido informados que varios cambios de esquema de Exchange 2007 SP2 habilitar coexistencia con Exchange 2010.Will que necesitamos para ejecutar Setup.com /PrepareSchema al actualizar a Exchange 2007 SP2 así como cuando nos estamos Preparando el entorno de Active Directory para Exchange 2010?

Además, tenemos la misma pregunta para Setup.com /PrepareAD y /PrepareDomain.
G  

Exchange 2007 SP2 contienen realmente los cambios de esquema. De hecho, este service pack incluye todos los cambios de esquema requeridos por Exchange 2010. Sí, se lea correctamente. Si ha actualizado Exchange 2007 SP2, no es necesario ejecutar Setup.com /PrepareSchema cuando esté listo para preparar el entorno de Active Directory para Exchange 2010. El grupo de producto decidió incluir el esquema de Exchange 2010 de Exchange cambia en Exchange 2007 SP2 principalmente para que los clientes sólo tenían que ejecute una vez Setup.com /PrepareSchema.

Pero incluso si ha actualizado a Exchange 2007 SP2 y, por lo que realizan los cambios de esquema necesarios para Exchange 2010, todavía debe ejecutar Setup.com /PrepareAD y /PrepareDomain mediante los bits de Exchange 2010. Esto es debido a los nuevos grupos de seguridad universal, el modelo de permiso de control de acceso basada en funciones, cmdlets y qué-not que estará disponible con Exchange 2010.

 
I
Esperar después de instalar los objetos de esquema incluidos con Exchange 2010 un qué tipo de crecimiento de la base de datos (NTDS.dit) de Active Directory
G  

Como regla general, planee 2 KB de crecimiento del árbol de información de directorio (DIT) por cada nueva clase o atributo en el esquema de Active Directory. Debido a que Exchange 2010 instala aproximadamente 3.000 objetos en el esquema, debe esperar el tamaño total del archivo NTDS.dit aumentar aproximadamente 6 MB.

Como se mencionó en mi respuesta a la pregunta anterior, los mismos cambios de esquema se incluyen con Exchange 2007 SP2 y Exchange 2010. Por lo que verá el crecimiento mismo independientemente de si ejecuta Setup.com /PrepareSchema mediante bits de Exchange 2007 SP2 o Exchange 2010.

Figura 2: el archivo NTDS.dit puede ser considerable.

I  

Debido a que tenemos una gran cantidad de usuarios de Mac, tenemos una gran cantidad de clientes de Entourage 2008 (y anteriores) en nuestro environment.Most de mensajería basado en Exchange 2007 de los clientes de Entourage conectar utilizando Web-Based distribuido Authoring and Versioning (WebDAV), pero algunas conectan a través de protocolo de oficina de correos (POP), así como acceso de mensajes de Internet (IMAP).

¿Hemos oído que Microsoft va a interrumpir WebDAV como de Exchange 2010 y preguntarse si saldrá clientes Entourage obligados a conectarse a Exchange 2010 mediante protocolos heredados como POP o IMAP?
G  

Sí, tiene razón, con Exchange 2010 Microsoft interrumpe WebDAV. Y Sí, esto significa que los usuarios de Entourage 2008 y versiones anteriores sólo podrán conectarse a Exchange 2010 a través de POP o IMAP.

Pero el equipo de Exchange sólo no puede omitir este protocolo de cliente de correo porque lo utiliza otro grupo de producto de Microsoft. Por tanto, Microsoft está teniendo cuidado de este problema con el nuevo cliente de Entourage (que, de escribir este documento es en la versión beta).

Próximas Entourage utilizará el cliente Exchange Web Services (EWS) para conectarse a Exchange. Como resultado, esta versión también será compatible con muchas más características de las versiones anteriores, basadas en WebDAV.

Ahora las tareas, notas y categorías pueden sincronizar withExchange y la nueva versión de Entourage tendrá compatibilidad completa para la detección automática (Entourage 2008 SP1 tenía sólo compatibilidad limitada para detección automática).

Puede leer más acerca de la próxima versión de Entourage aquí: officeformac.com/blog/Entourage-for-Exchange-Web-Services-Beta-is-Live.

 
I  

Estamos una pequeña empresa que desea utilizar la nueva funcionalidad de grupo (DAG) de disponibilidad de la base de datos una vez actualizar de Exchange 2003 a Exchange 2010.We nos ha leído todas las secciones relacionadas con DAG en la documentación de Exchange 2010 TechNet, pero parece no puede encontrar información en miembro de NIC DAG cuántos servidores necesitan.

Las máquinas que planeamos dedicar como servidores miembro de DAG actualmente sólo tienen una NIC. ¿Es este suficiente?
G  

Aunque DAGs funcionará sin problemas con sólo una interfaz de red, realmente debería tener al menos dos NIC conectadas para separar las subredes en cada servidor miembro de DAG. De hecho, Microsoft no admite DAGs con sólo una interfaz de red.

Puede que se pregunte por qué esto es un escenario de trabajo si Microsoft no lo admite.

Figura 3: Un servidor de miembro del grupo de disponibilidad de base de datos debe tener al menos dos interfaces de red, como se muestra aquí

Bien, imagine lo siguiente: Tiene un DAG con dos servidores miembro cada configurado con dos NIC--una red pública para las conexiones de la interfaz de programación de aplicaciones de mensajería (MAPI) y una red privada de latido y replicación.

Ahora, perderá la red privada, que sirve también de la red de replicación. En esta situación, la replicación continuará a través de la red pública (incluso si no ha habilitado la replicación para esta red).

Si sólo hubiera una sola NIC en cada servidor miembro de DAG, debería detener la replicación. Dependiendo de la duración del tiempo de inactividad, podrían dar como resultado de las colas de enorme copia y podría perder datos si la copia de la base de datos activa está dañada y se requería una conmutación por error a una copia de la base de datos en otro servidor de miembro DAG.

 

Henrik Walther , un Microsoft Certified Master: Exchange 2007 y MVP de Exchange con más de 15 años de experiencia en el negocio de TI. Trabaja como arquitecto de tecnología para Timengo (un Microsoft Gold Certified Partner en Dinamarca) y como escritor técnico para Biblioso Corp. (una compañía en EE.UU. especializada en administrado documentación y localización de servicios).