Cola de Exchange & R: Automatizar y consolidar
Existen varias formas de arreglárselas con la automatización, uso compartido del buzón y problemas de consolidación en Exchange.
Henrik Walther
Con colaborador invitado Georg Hinterhofer
Resiliencia de sitio en los conectores de envío
P. Estamos en el proceso de implementación de Exchange 2010 en múltiples sitios y configuración para redundancia. Al planear para la entrega de correo saliente a través de hosts inteligentes, queremos lograr redundancia automática en caso de que falle el sitio primario. Nos gustaría mantener el tráfico en el sitio primario cuando todo está bien. ¿Cómo podemos lograr esto?
**R.**Puede añadir fácilmente que múltiples hosts inteligentes en un conector de envío e intercambio serán sólo por turnos a través de ellos. Sin embargo, esto sólo resuelve uno de los requisitos: redundancia en todos los sitios. Tráfico todavía se distribuirá uniformemente incluso cuando están todos los sitios, lo que quema el ancho de banda innecesario entre sitios.
En este caso, el conector de envío está configurado con dos gateways de correo primaria y secundaria aparece como hosts inteligentes. Exchange en un orden alternante usará para entregar el correo saliente.
Para resolver esto, deberás aplicar un truco nifty enseñó en formación Microsoft Certified Master. Se basa en el hecho poco conocido que el cuadro host inteligente en Exchange (versiones 2003, 2007 y 2010) no pueden tomar sólo los registros o IP resuelve direcciones, pero también debe tener registros de intercambiador de correo (MX). Sin embargo, puede asignar prioridad a los registros MX.
En primer lugar, asegurarse de que tiene registros DNS A para sus puertas de enlace de correo en el lugar. A continuación, vienen con un nombre aleatorio para el registro MX de ser creado en pronto en DNS. En este ejemplo, he decidido allsmarthosts.forest1.local. Crear los necesarios registros MX en DNS.
Con llanura MX enrutamiento basado, Exchange usará el registro MX con la mayor prioridad, como está disponible. Ahora, la única cosa que queda hacer es volver a configurar el conector de Exchange enviar a leer allsmarthosts.forest1.local como host inteligente sólo.
Al hacerlo, Exchange usará primary.forest1.local para el correo saliente, como está disponible. Una vez que se cae o se vuelve inaccesible, Exchange comenzará utilizando secondary.forest1.local como host inteligente. Eso es lo que pueden hacer un poco artimañas DNS para usted.
Intercambio entre organizaciones
P. Recientemente adquirimos una empresa que también está ejecutando Exchange 2010. Mientras que el plan es consolidar entornos, necesitamos inmediatamente establecer calendario (no sólo disponibilidad) compartir entre ambas organizaciones. Parece que hay poca información por ahí. ¿Puede compartir algún detalle sobre calendario de cómo 1:1 intercambio de obras y lo que necesitamos para configurar esto?
**R.**Esta característica fue desarrollada para que Office 365 facilitar la coexistencia de locales. Se puede utilizar para este escenario, así. Tanto las organizaciones deben estar ejecutando Exchange 2010. Los clientes pueden ser 2010 de Outlook Web Access (OWA) o Outlook 2010.
En este caso, el cliente de compartir el calendario puede especificar la cantidad de información (sólo disponibilidad, disponibilidad más ubicación, disponibilidad con detalle completo) para compartir. ¿Cómo funciona? Técnicamente, su propio servidor de buzón creará una copia o caché del calendario compartido y mostrarla en Outlook o OWA. Este es uno de los principales escollos. Los servidores de buzones de correo deben ser capaces de conectarse a Internet, como son las consultas de los elementos de calendario compartido.
Cuando usted mira el calendario compartido en MFCMAPI, parece muy parecido a uno propio. La excepción es que está marcado como de sólo lectura. Puede ver todos los elementos de calendario compartido, como realmente están almacenadas en su propio buzón.
Para configurar esto, necesitará configurar ambas organizaciones para federarse con la puerta de enlace de Federación de Microsoft (MFG). También tendrá que garantizar que si una organización aún se está ejecutando la versión RTM de Exchange, deberás actualizar a por lo menos el primer service pack, por lo que te consigues la misma instancia de la Mfg. En ese caso, no necesita relaciones organizativas. (Necesitaría aquellos para compartir la disponibilidad, pero desea obtener compartir el calendario en este caso).
Para federar su organización con la MFG, simplemente siga los pasos descritos aquí. Deberás publicar registros TXT adicionales en DNS para demostrar la titularidad del dominio. Hacer esto para ambos sitios que desea relacionar y agregar los dominios adecuados. Además, necesitará definir las directivas de uso compartidas de ambos lados para permitir compartir con detalles el calendario.
Notificación de la Directiva predeterminada ya permite a los usuarios compartan calendario de disponibilidad de la información con el mundo entero (indicado por el * dominio). Desea tener calendario completo compartir con tu pareja, por lo que necesita para configurar correctamente el dial de compartir y agregar los dominios de la organización que desea poder compartir con. Una vez más, es necesario hacerlo en ambos sitios.
Compartir eficazmente las políticas permite controlar qué usuarios pueden compartir sus calendarios y con quién. Este intercambio no se limita a los elementos del calendario. Puedes compartir tus contactos así.
En primer lugar compartir el calendario. El destinatario, a continuación, puede optar por agregar el calendario compartido. El calendario aparecerá pronto con los elementos compartidos.
Si necesita solucionar esto, es un buen lugar para empezar a mirar la URL real. Esto se almacena en el buzón del destinatario. Usted puede recuperar con MFCMAPI. Asegúrese de que la URL es accesible desde los servidores de buzones de correo locales.
Agentes de extensión cmdlet
P. Para cada nuevo buzón que creamos, queremos deshabilitar ActiveSync por defecto. Acceso sólo debe estar disponible a petición. Sin embargo, al crear un nuevo buzón con el cmdlet New-Mailbox, no tenemos la opción de deshabilitar ActiveSync en el momento de la creación. Tenemos que ejecutar un conjunto de CASMailbox –ActiveSyncEnabled:$ false manualmente después de la creación. Las personas a veces se olvida este paso y por lo tanto dejar acceso de ActiveSync habilitado para personas que no deberían tener acceso. ¿Sabes de alguna forma de cambiar estos valores predeterminados a nivel mundial, o existe alguna otra manera fácil alrededor?
**R.**Esta pregunta surge con bastante frecuencia. Lamentablemente, la respuesta corta es no. No hay forma para cambiar estos valores predeterminados (como acceso Web habilitado de forma predeterminada, ActiveSync habilitada de forma predeterminada, litigios, discapacitados, etc.). Exchange configurará siempre a sus gustos codificados.
Afortunadamente, hay una manera de evitar esta limitación, con agentes de extensión de cmdlet. Lo que hace un agente de extensión del cmdlet (también conocido como agente de secuencias de comandos) es escuchar cualquier comando de Exchange se dispararon. Si programado para hacerlo, será ejecutar cualquier comando dado después o cambiar los datos en el cmdlet real ser despedido.
Aquí hay un ejemplo que se adapte a su pregunta:
New-Mailbox -Name "Georg Hinterhofer" -Database DB1 -UserPrincipalName hiho22@hihosoft.local –Password $p.password
Esto crea un usuario con todos los valores predeterminados en el lugar. El agente de extensión del cmdlet detecta que ha ejecutado el cmdlet New-Mailbox y gira automáticamente un cmdlet segundo (uno que no es visible para usted). Se ejecuta Set-CASMailbox –identity hiho22 –ActiveSyncEnabled:$ false, configuración de todas sus necesidades.
Entonces, ¿cómo conseguimos el agente ya está en marcha? En primer lugar, determinar la acción que desea establecer como el gatillo y qué acción desea ejecutar cuando se activa el desencadenador. En este caso, es fácil. Cada vez que alguien ejecuta el cmdlet New-Mailbox, desea disparar hasta el cmdlet Set-CASMailbox para deshabilitar ActiveSync.
Ahora puedes ir y hacer la codificación real. Buscar un archivo llamado scriptingagentconfig.xml.sample en %ExchangeInstallPath%\bin\CmdletExtensionAgents y copiarlo. Cambiar el nombre de la copia para leer sólo scriptingagentconfig.xml y abren con su editor favorito. En este ejemplo, modificar el contenido del archivo a este aspecto:
<?xml version="1.0" encoding="utf-8" ?> <Configuration version="1.0"> <Feature Name="DisableEASonNewlyCreatedMailboxes" Cmdlets="new-mailbox"> <ApiCall Name="OnComplete"> if ($succeeded) { $dc = (Get-ADServerSettings).DefaultPreferredDomaincontrollers $user = $provisioninghandler.UserSpecifiedParameters["UserPrincipalName"] set-casmailbox $user -ActiveSyncEnabled:$false -DomainController $dc.item(0) } </ApiCall> </Feature> </Configuration>
Guarde el archivo modificado. Si tienes más de un servidor de Exchange, debe copiar la copia modificada del archivo para cada uno de esos servidores. Tenga en cuenta también cómo Get-ADServerSettings determina el controlador de dominio preferido para evitar los errores relacionados con la latencia de replicación de Active Directory. Puede quitar esta opción si sólo tiene un DC en su entorno.
Por último, necesitará activar al agente de secuencias de comandos. Esta es una configuración de toda la organización, por lo que sólo necesita ejecutar esta vez, no una vez para cada servidor:
Enable-CmdletExtensionAgent "Scripting Agent"
Verificar el resultado y ya está. Ahora, ejecutar todos cmdlet New-Mailbox favorito y ver como ActiveSync se desactiva automáticamente.
.jpg)
.jpg)
Henrik Walther es un Microsoft Certified Master: Exchange 2007 y Exchange con más de 16 años de experiencia en el campo de TI. Trabaja como un arquitecto de tecnología para Microsoft gold partner en Dinamarca y como un escritor técnico de Biblioso Corp. (una empresa norteamericana que se especializa en administrar servicios de documentación y localización). También es un proveedor contratado trabajando en diversos equipos de producto (incluyendo los equipos Exchange y Lync) de Microsoft.
Georg Hinterhofer es un Microsoft Certified Master: Exchange 2010. Trabaja como ingeniero senior campo premier, centrando únicamente en Microsoft Exchange. Está basado en Austria, cerca de Viena.