Exchange Queue & A Outlook Anywhere y IPv6, el Analizador de conectividad remota y más
Henrik Walther
P que sólo haya terminado la implementación de Exchange 2007 en servidores de Windows Server 2008, basado en nuestra organización y cosas está trabajando muy bien, con una excepción. Incluso si se ha configurado Outlook en cualquier lugar (conocido como RPC sobre HTTP) siguiendo las instrucciones de la documentación de Exchange 2007 en Microsoft TechNet, no se puede conectar a los servidores acceso de cliente de Exchange 2007 desde un cliente de Outlook 2007 en Internet, independientemente de lo que intentamos. Se realizaron que el certificado de la red SAN es de confianza por el cliente y que el puerto TCP 443 está abierto en el servidor de seguridad conectado a los servidores de acceso de cliente. ¿Ha visto alguna vez este tipo de problema?
una de hecho, tengo. Mencione que Exchange 2007 se ha instalado en servidores de Windows Server 2008-basado. Cuando un servidor de acceso de cliente se ha instalado en un servidor de Windows Server 2008, es importante tener en cuenta que Outlook Anywhere no funcionará correctamente si IPv6 está habilitado en el servidor. Puesto que IPv6 está habilitada de forma predeterminada cuando Exchange 2007 SP1 está instalado en Windows Server 2008, debe asegurarse deshabilitarlo. He visto varios casos donde esto resuelve el problema.
Para obtener más información acerca de por qué Outlook en cualquier lugar y IPv6 en Windows Server 2008 forman una cocktail incorrecto y cómo deshabilitar IPv6 correctamente en servidores de Windows 2008 sin excederse en Exchange 2007, es recomendable que consulte la entrada de blog del equipo de Exchange de Microsoft en msexchangeteam.com/archive/2008/06/20/449053.aspx. Este problema debe ser fijos con Exchange 2007 Service Pack 1 resumen 4.
P actualmente estoy implementar Outlook en cualquier lugar y Exchange ActiveSync en nuestro entorno de mensajería en función de Exchange 2007, y se pregunte si algún modo es posible probar si Outlook en cualquier lugar funcionará como se esperaba en el otro lado de nuestra red de perímetro. Además, desea asegurar que el servicio de detección automática ha configurado correctamente en nuestro entorno. ¿Puede dar me los punteros?
A Sí, es posible comprobar si Outlook Anywhere está funcionando correctamente. Los empleados de Microsoft dos (Shawn McGrath del grupo de productos Exchange y Portillo Brad servicios de soporte técnico de) han creado una herramienta de basada en Web denominada Server remoto conexión Analyzer de Exchange (ExRCA). La herramienta (en la figura 1 ) debe aún se consideran un prototipo, pero no han experimentado cualquier errores o el comportamiento extraño absoluto. Puede realizar la herramienta de detección automática de Outlook 2007 y pruebas de conectividad RPC/HTTP; también puede probar si ActiveSync de Exchange y SMTP entrante correo flujo funciona como se esperaba. Aunque ExRCA actualmente no se admiten por Microsoft, recomienda para las pruebas de conectividad remota con Exchange 2007.
La figura 1 página de inicio de analizador de conectividad remota de Exchange Server (haga clic en la imagen de una vista más grande)
P nuestra organización, que utiliza Exchange Server 2007, está en las fases de planeamiento de implementación de replicación continua de reserva (SCR). Desee tener un segundo conjunto de datos para cada una de las bases de datos buzones creados en nuestros servidores de buzón de Exchange 2007 Service Pack 1 no agrupados en otro sitio. ¿Se han sido leer mucho sobre SCR en la documentación de Exchange 2007 en Microsoft TechNet pero aún tiene alguna pregunta nos no administrado para obtener respuestas a hay: si se activa un objetivo SCR, se esto tiene el mismo efecto que un Move-Mailbox con el parámetro –ConfigurationOnly especificado para todos los buzones de usuario en una base de datos de buzones determinado? En otras palabras, sólo cambiar la ubicación de servidor de Exchange en Active Directory.
un puesto que está utilizando los servidores de buzón no agrupados (en caso contrario, conocido como un servidor de buzones independientes) como los servidores de SCR de origen, la descripción es correcta. Dado que se se active la copia SCR en un servidor diferente, se utilizará la portabilidad de la base de datos. Esto significa que se cambiará la ubicación del servidor Exchange en Active Directory para los buzones de usuario en la base de datos correspondiente buzón.
Si fueron de servidores SCR de origen en el entorno de Exchange 2007 bien replicación continua agrupada (CCR), o clústeres de copia única (SCC) - basado y ha utilizado un nodo pasivo en un clúster de conmutación por error como el objetivo SCR, debe activar el objetivo SCR con el mismo nombre y la ubicación de servidor de Exchange en Active Directory no cambiaría.
P Nos sólo ha finalizado la implementación de Exchange Server 2007 en nuestro entorno empresarial y se pregunte si es compatible para mover los grupos de seguridad de Exchange 2007 seis, que se crearon mediante instalación de Exchange 2007 cuando se preparan para la instalación de Exchange 2007, a otra unidad organizativa en lugar de la Microsoft Exchange seguridad de grupos de UNIDAD, que se crea en el dominio raíz del bosque y dominios.
una a diferencia de Exchange 2000 o 2003, que no permiten mueva los grupos de Exchange a otra unidad ORGANIZATIVA en el bosque, Exchange 2007 realmente permite esto. Puede ver que los seis Exchange 2007 grupos de seguridad (consulte la figura 2 ) creado cuando el bosque está preparado para Exchange 2007 se marca con dos propiedades únicas; el primero es un GUID conocido y el segundo es un nombre distintivo que puede cambiar.
La figura 2, grupos de seguridad de Exchange Server 2007 (haga clic en la imagen de una vista más grande)
Estas dos propiedades y el hecho de que se agregan a OtherWellKnownObjects atributo del bosque respectivos cuando se ejecuta el programa de instalación, asegúrese de que Exchange se pueden buscar los grupos de seguridad en cualquier lugar en el bosque. Para que pueda continuar y mueva los grupos en cualquier lugar lo desea, incluso en otro dominio del bosque. Puede encontrar detalles adicionales en Ross Smith excelente p+f acerca de los permisos de Exchange 2007 ( technet.microsoft.com/bb310792) incluido en la documentación de Exchange 2007 en Microsoft TechNet.
P por de algunos reestructuración en nuestro entorno de mensajería en función de Exchange 2007, desee mover el testigo de recurso compartido de archivo para cada uno de nuestros servidores de buzones de Exchange 2007 CCR a otro servidor de transporte del concentrador. ¿Puede incluyen algunas instrucciones sobre cómo esto se consigue de forma compatible?
A mover que el testigo de recurso compartido de archivo de un servidor concentrador de transporte de Exchange 2007 a otro es muy sencillo. Simplemente siga los pasos que activará cuando configura inicialmente el testigo de recurso compartido de archivo para los servidores de buzón agrupados. La única diferencia es la ruta que especifique en el servidor. Los pasos adecuados pueden encontrarse en cómo configurar la sección de testigo de recurso compartido de archivos de la documentación de Exchange 2007 en Microsoft TechNet (consulte la technet.microsoft.com/bb124922).
Por cierto, debe saber que si ha realizado uso de un CNAME registro para apunte a su servidor concentrador de transporte al configurar el testigo de recurso compartido de archivo, la tarea podría, a continuación, simplemente ser cuestión de que cambiar el nombre de dominio completo (FQDN) de los host de destino para que el alias en los respectivo CNAME registro puntos (consulte la La figura 3 ).
La figura 3 registro CNAME hacia un host de destino de un testigo de recurso compartido de archivo (haga clic en la imagen de una vista más grande)
Tenga en cuenta, sin embargo, que si tiene nodos de clústeres ubicados en diferentes sitios, instrucciones de resistencia de sitio del grupo de productos de Exchange ha cambiado (consulte la msexchangeteam.com/archive/2008/04/03/448615.aspx). Básicamente, el grupo de productos de Exchange no recomienda utilizar registros CNAME en entornos de Exchange 2007 geográfica de Cluster Server.
P está pensando en mejorar la configuración de seguridad de los servidores de mensajería de Exchange 2007 en nuestra organización. Parte de nuestro plan de optimización de seguridad es cifrar los volúmenes en el que se encuentran las bases de datos de Exchange. Nos preguntado si se recomienda o aún se admiten para almacenar archivos de base de datos de Exchange en un volumen que ha sido cifrado con cifrado de sistema de cifrado de archivos (EFS).
la respuesta es un no cifrado . Colocación de Exchange 2007 bases de datos en un volumen cifrado de EFS basado no es compatible con Microsoft. De hecho, es no compatible para .EDB, Log, .stm (Exchange 2000 o 2003), .dat, .eml y .chk archivos. La razón principal es que este tipo de cifrado que se da una sobrecarga adicional, lo que afecta significativamente al rendimiento.
Para ayudar a proteger los datos de Exchange 2007 más archivos, se debe impedir el acceso no autorizado en el equipo de Exchange y utilizar el formato del mensaje S/MIME para cifrar los datos del mensaje. También, si instala Exchange 2007 en Windows Server 2008, considere el uso de BitLocker para proteger los volúmenes.
P he instalado sólo Exchange 2007 Service Pack 1 en un servidor de Windows Server 2008 que es también un controlador de dominio. Dado que no usa IPv6 en este entorno, deshabilitan se en conexiones de red tenía se ha instalado Service Pack 1 de Exchange 2007, y, a continuación, reinicia el servidor. Cuando llegó vuelve a estar conectado, ya no inician los servicios de Exchange 2007. Error 214, en el registro de aplicación contiene la siguiente información:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).
A varios informes que he visto en este comportamiento. Aunque no es conveniente instalar cualquiera de las funciones del servidor Exchange 2007 en un servidor de Windows Server 2008 que también actúa como un controlador de dominio, tener una o más funciones de servidor de Exchange 2007 que se ejecuta con IPv6 deshabilitado en un controlador de dominio deberían funcionar, especialmente ya que éste es un escenario común en los laboratorios de pruebas y en otros lugares. La solución como de ahora es rehabilitar IPv6 en el servidor. Rumor tiene que Exchange 2007 Service Pack 1 resumen 4 solucionará este problema.
Henrik Walther es un principal de certificado de Microsoft: Exchange 2007 y MVP de Exchange con más de 14 años de experiencia en el negocio de TI. Trabaja como un arquitecto de tecnología de Interprise Consulting (una Microsoft infraestructura socio de oro en Dinamarca) y como un escritor técnico para Biblioso Corporation (una compañía de US-en función que está especializada en servicios de documentación y localización administrados).