Cola de Exchange & R: Exchange siempre está cambiando
Si está cambiando de días de calendario predeterminado, los extremos de datacenter o redireccionamiento de los servidores, siempre tiene que estar preparado para realizar cambios en Exchange.
Henrik Walther
La noche del lunes
P. Estamos una gran organización Europea y sólo se han migrado desde IBM Lotus Domino a Microsoft Exchange 2010. La mayoría de nuestros usuarios utiliza Outlook Web App 2010 como su cliente de correo predeterminado. Varios usuarios han observado que "Domingo" es el valor predeterminado de primer día de la semana en configuración | Calendario en el Panel de Control de Exchange (consulte figura 1).
.jpg)
Figura 1 el valor predeterminado de primer día de la semana para un buzón de Exchange 2010.
Como el lunes se consideran el primer día de la semana laboral en nuestra región, queremos cambiar esta configuración para todos los usuarios de Exchange 2010 en la organización. ¿Podemos utilizar el Consola de administración de Exchange (EMC) o el Shell de administración de Exchange (EMS) para hacerlo de forma centralizada para todos nuestros usuarios? Hemos visto en la página de propiedades para los buzones en el EMC y incluso a través de EMS mediante el cmdlet Get-Mailbox, pero no podemos ver todos los atributos que se relacionan con el primer día laborable de la semana. ¿Podrían ayudarme?
**R.**El lunes es el primer día de la semana laboral en la mayoría de los países europeos, por lo que entiendo la frustración. Afortunadamente, es relativamente fácil cambiar esta configuración para todos los usuarios. No puede hacerlo mediante la EMC, pero sin duda se puede hacer con el Shell de administración de Exchange (EMS). La mayoría pensaría que deba utilizar el cmdlet Set-Mailbox para cambiar la configuración. En realidad, deberá usar el cmdlet Set-MailboxCalendarConfiguration.
Ejecute el siguiente comando y verá todas las opciones de calendario específico se puede manipular para un buzón (consulte figura 2):
Get-MailboxCalendarConfiguration –Identity <user> | fl
.jpg)
Figura 2 cambiar el valor predeterminado de primer día de la semana a través de la Shell de administración de Exchange.
Si desea cambiar el "WeekStartDay" para el lunes para todos los usuarios de la organización de Exchange 2010 tenía "Contoso" en el atributo de compañía (por ejemplo), utilice el siguiente comando:
Get-User –Filter "Company –eq 'Contoso'" | Set-MaiboxCalendarConfiguration –WeekStartDay “Monday”
Volver al centro
P. Nos hemos sido ejecutando Exchange 2010 hace aproximadamente un año. Somos una gran organización, y hasta ahora hemos tenido un único centro de datos que aloja nuestra solución de mensajería de Exchange 2010. Hemos introducido un centro de datos extra por lo que podemos lograr resistencia de buzón en el nivel de sitio. Habrá conectar ambos centros de datos, por lo que hemos creado una matriz de servidor de acceso de cliente (CAS matriz) en el centro de datos de usuarios activos.
Ya pasamos los primeros 100 usuarios al nuevo centro de datos para comprobar las cosas funcionarán como se espera. No estamos bastante allí. Vemos problemas con el extremo de cliente de Outlook (MAPI) cambiado de "outlook-1.contoso.com" (CAS objeto array FQDN en el primer centro de datos) a "outlook-2.contoso.com" (nuevo CAS objeto array FQDN en el nuevo centro de datos).
Los clientes de Outlook (MAPI) seguir utilizando el extremo antiguo, que significa que los clientes de Outlook creación sesiones RPC en la matriz de CAS en el primer centro de datos y la matriz de entidades emisoras de certificados, a continuación, habla RPC con los servidores de buzones en el nuevo centro de datos. ¿Cualquier idea si esto es intencionado? Si no es así, ¿tiene alguna idea de cómo se puede arreglar?
**R.**Algunas colas de Exchange & Un lectores recordará he tocado este tema antes. Al mover buzones de un centro de datos con una matriz de entidades emisoras de certificados a otro centro de datos con otra matriz de entidades emisoras de certificados, que se desea hacer el antiguo extremo no puede resolverse o no está disponible. Esto afectará a todos los usuarios que están activos en el primer centro de datos.
La solución aquí, aunque no suena bien, es actualizar el perfil de Outlook (MAPI) para los usuarios que tenían su buzón movido al nuevo centro de datos (usando la opción "Reparar perfil" dentro de Outlook. Por ejemplo).
Algunos de ustedes pueden preguntarse por qué Exchange 2010 se comporta de esta manera. Funcionaba bien con las versiones anteriores de Exchange. Los clientes MAPI de Outlook ahora conectan con el servicio de acceso de cliente de RPC (servicio de entidad emisora de certificados de RPC) en función de servidor de acceso de cliente, no directamente en el almacén en la función de servidor de buzón.
En Exchange 2007 y versiones anteriores, cuando mueve un buzón de base de datos de un buzón a otro, se realizarían en la base de datos de buzón de origen envía un "ecWrongserver" al cliente de Outlook. Que obligado a localizar el buzón en la base de datos en la que el buzón ahora.
El servicio de entidad emisora de certificados de RPC no puede responder con un "ecWrongServer" cuando un * a través de (base de datos o conmutación por error), se produce entre dos centros de datos (y el servicio de entidad emisora de certificados de RPC está disponible). De forma similar, no puede responder si mover un buzón de una base de datos de buzones en un centro de datos a una base de datos de buzones en otro, donde el atributo RpcClientAccessServer de la base de datos de destino contiene otro completo nombre de dominio completamente (FQDN).
Durante el desarrollo de Exchange 2010 SP1, hay planes para introducir una opción "Permitir cruzar sitio RPC Client Access" llamada que configuraría para un grupo de base de datos de disponibilidad (DAG). Esta opción se consideró excesivamente compleja, por lo que resultó adecuado antes de distribuir Exchange 2010 SP1.
¿Podemos nos coexistir?
P. Hemos implementado Exchange 2010 en nuestra organización de Exchange 2003. Actualmente estamos planeando señalar el espacio de nombres que se utiliza para tener acceso a un buzón de Exchange 2003 en la matriz de entidades emisoras de certificados de Exchange 2010. Ya hemos agregado un FQDN heredado (legacy.contoso.com) para el certificado de SAN/UC y hemos configurado la dirección URL heredada en el directorio virtual de OWA 2010.
Hemos Habilitar descarga de SSL en la solución de equilibrador de carga que distribuye el tráfico de cliente entre las entidades Emisoras. También nos hemos seguido los pasos de este artículo de TechNet Wiki para configurar la descarga de SSL en los servidores de Exchange 2010 CA. Descarga de SSL no está habilitada en los servidores de Exchange 2003 front-end (FE).
Estamos muy seguros de si descarga de SSL funcionará en un escenario de coexistencia, donde los clientes se conectan a los servidores de Exchange 2010 CA y redireccionan a los servidores de Exchange 2003 FE. ¿Sabe si funcionará este escenario?
**R.**Sí, los usuarios de OWA 2003 tener acceso a sus buzones mediante la autenticación de servidores de Exchange 2010 CA que redirigir la sesión a los servidores de Exchange 2003 FE. Esto funciona incluso con SSL habilitado en la solución de equilibrador de carga y los servidores de Exchange 2010 CA.
Algunos de ustedes podrían esperar otra respuesta. Exchange 2003 URL configurado en el directorio virtual de OWA (2010) debe ser en forma de "https://legacy.contoso.com/exchange" y no "http://legacy.contoso.com/exchange". De lo contrario, obtendrá un 91 de ID de evento en el registro de aplicación (consulte figura 3).
.jpg)
Figura 3 Error en el registro de aplicación cuando se configura URL heredado con HTTP, en lugar de HTTPS.
El legado URL debe comenzar con HTTPS y no HTTP. Porque los servidores de Exchange 2010 CA simplemente redirigen la sesión del cliente a un servidor de Exchange 2003 FE, funcionará correctamente cuando se utiliza HTTPS para la dirección URL heredada de OWA.
Cola de copia
P. Cuando se trabaja con varios escenarios de Exchange 2010 DAG (normalmente en entornos de laboratorio), algunas veces veo una longitud de cola de copia extremadamente alta (consulte figura 4).
.jpg)
Figura 4 una cola de copia extremadamente alta es siempre una posibilidad.
La primera vez que me he dado cuenta, pensé, "lo que el?" Tras estudiar el caso, puedo ver que es el mismo número exacto de cada vez que suceda. ¿Sabe si se trata de un error o algo?
**R.**El número que está viendo es el valor más alto que se puede establecer para la longitud de la cola de copia. Copia de registro no está sucediendo y las actualizaciones de la base de datos de clúster no están ocurriendo. Una pérdida de conectividad de red entre los nodos de DAG normalmente hace algo como esto.
En un entorno de laboratorio lenta, esto puede ocurrir en alguna ocasión. Aunque usted no debería ver en un entorno de producción. Si lo hace, se recomienda intentar encontrar la causa raíz para perder la conectividad de red entre los nodos de DAG...
.jpg)
**Henrik Walther**es un Microsoft Certified Master: Exchange 2007 y MVP de Exchange con más de 16 años de experiencia en el negocio de TI. Trabaja como arquitecto de tecnología para un Microsoft Gold Certified Partner en Dinamarca y como escritor técnico para Biblioso Corp. (una empresa en Estados Unidos que se especializa en servicios de documentación y localización administrados). También es un proveedor contratado por trabajar en varios equipos de producto (incluyendo los equipos de Exchange y Lync) en Microsoft.