Exchange Queue & A: Conéctate y vencerás
Los lectores de este mes tienen dudas acerca de las conexiones, cómo administrar una flota de dispositivos móviles, los límites en las listas de la SAN y la agrupación en Exchange.
Henrik Walther
Conexiones correctas
P. Nuestra empresa ha pasado a una infraestructura sólida para el sitio de Exchange 2010 que consta de dos servidores de Exchange 2010 polivalentes: uno en el centro de datos principal (sitio de Active Directory 1) y uno en el centro de datos de conmutación por error (sitio de Active Directory 2). El grupo de TI ha instalado las herramientas de administración de Exchange 2010 en sus estaciones de trabajo, que se encuentran físicamente en un tercer sitio de Active Directory (sitio de Active Directory 3).
Hemos observado que cuando se inicia el Shell de administración de Exchange (EMS), las estaciones de trabajo respectivos conectan aleatoriamente a los servidores de Exchange 2010 en el sitio de Active Directory 1 y 2 del sitio de Active Directory. Nos gustaría estas estaciones de trabajo siempre establecer una conexión con el directorio virtual de Windows PowerShell remoto en el servidor de Exchange 2010 ubicado en el sitio de Active Directory 1. ¿Sabe si podemos hacer esto?
**R.**Hay una razón válida para la lógica integrada que está viendo. Está diseñado para lograr la redundancia de administración de Exchange y distribuir las sesiones de administración entre varios servidores de Exchange 2010 para que un único servidor no tiene toda la carga.
Para responder a tu pregunta, aunque: Sí, hay una forma de codificar el 2010 específicos de Exchange server al que se deben conectar las estaciones de trabajo. Inicie sesión en la estación de trabajo y cambiar el atajo de EMS. Para ello, abra Propiedades del acceso directo de EMS (consulte figura 1).
.jpg)
Figura 1 Abrir la página de propiedades para el acceso directo de Shell de administración de Exchange.
Cambiar el destino de este:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe - noexit-command ". ' C:\Archivos programa\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer-auto "
A:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe - noexit-command ". ' C:\Archivos programa\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; ExchangeServerEX01 conectar "
El servidor al que desea que los ordenadores de sobremesa para conectarse se denomina EX01 en este ejemplo. Haga clic en aplicar, a continuación, Aceptar y lanzar el EMS. La sesión ahora establecerá una conexión en EX01 (consulte figura 2).
.jpg)
Figura 2 el Shell de administración de Exchange se conecta a la Exchange Server especificada en el acceso directo.
Un mundo, DAG
P. Nos quedamos Exchange 2010 a lo largo de nuestra organización. Contamos con un centro de datos en Europa y uno de los Estados Unidos. Contamos con un único grupo de disponibilidad de base de datos (DAG) extiende en los dos centros de datos. Hay cuatro miembros DAG en Europa y cuatro miembros DAG en los Estados Unidos.
Cada centro de datos tiene un sitio dedicado de Active Directory, por lo que los miembros de DAG en Europa y Estados Unidos. los centros de datos están en subredes distintas. Cada miembro de DAG tiene dos tarjetas de red: una MAPI y una red de replicación. Hemos creado rutas estáticas y contrae las redes de DAG según las instrucciones en cola anterior de Exchange & Columnas.
Todo funciona como se esperaba, con una excepción importante. Cuando cambiamos de domicilio el grupo de clúster principal del propietario del Gestor de activo principal actual a otro miembro de DAG, el grupo se mueve correctamente. Sin embargo, el miembro de DAG desde el que se mueve el PAM pierde la configuración de puerta de enlace predeterminada en la NIC de MAPI. Esto significa que cuando termine, no puede comunicarse con cualquiera de los servidores del centro de datos. ¿Has oído hablar de este problema y tienen una solución o una revisión?
**R.**Sí, me he visto este problema. Y aunque este problema es cluster/DAG relacionado, la corrección es sorprendentemente sencilla. Tiene que aplicar la revisión descrita en este artículo de Microsoft Knowledge Base.
Administrar el tumulto móvil
P. Mi cliente sólo ha pasado de Exchange 2003 a Exchange 2010. La mayoría de sus usuarios dependen en gran medida de sus teléfonos inteligentes, que sincronizan con Exchange a través de Exchange ActiveSync (EAS). Cuando estaban en Exchange 2003, utiliza "Microsoft Exchange Server ActiveSync Web Administration Tool" para el barrido remoto pérdida o robo de dispositivos móviles. Saben que pueden iniciar barridos remotos y más usando la Consola de administración de Exchange o el Shell, pero prefiere utilizar una herramienta basada en Web como herramienta de administración de Web de ActiveSync de Microsoft Exchange Server. ¿Sabe si existe una herramienta similar para Exchange 2010?
R: una de las introducciones realmente agradables con Exchange 2010 fue el Panel de Control de Exchange (ECP). Se trata de un módulo de Web que sustituye la antigua página de opciones de Outlook Web Access (OWA) (consulte figura 3). Puede administrar todo tipo de configuración relacionada con el buzón de inicio de sesión en OWA, seleccionar "Opciones" y, a continuación, "ver todas las opciones".
.jpg)
Figura 3 acceso A Panel de Control de Exchange a través de Outlook Web App.
Una de las nuevas opciones en el ECP está bajo "Teléfono", a continuación, "Administrar teléfonos". Aquí verá una lista de todos los perfiles de dispositivo (todos los dispositivos sincronizados con sus respectivos buzones). También puede eliminar las asociaciones de dispositivo e iniciar un barrido remoto contra un teléfono móvil (consulte figura 4). ¿Bastante increíble, correcto?
.jpg)
Figura 4 Administrar dispositivos móviles mediante el Panel de Control de Exchange.
Obtiene una mejor. El ECP se desarrolló no sólo pensando en los usuarios, los administradores de Exchange también pueden utilizarlo para configurar varios configuración de la organización de Exchange y para administrar los buzones de usuario. Una de las opciones como administrador es eliminar las asociaciones de dispositivo o iniciar barridos remotos contra un teléfono móvil en nombre del usuario (consulte figura 5).
.jpg)
Figura 5 Administrar móviles de los usuarios de negocios.
Tan el ECP le ofrece gran variedad de opciones en cuanto a administración de teléfonos móviles a través de un módulo basada en Web.
Límites exteriores
P. Tenemos un cliente que planea tener más de 60 totalmente cualificado nombres de dominio (FQDN) en la lista de SAN de un certificado de SAN. ¿Sabe si es compatible incluso? Utilizan Exchange 2010 y Forefront Threat Management Gateway (TMG) 2010. Necesitan que muchos FQDN debido a están configurando enriquecido coexistencia entre su solución en instalaciones de Exchange 2010 y Office 365.
**R.**Exchange 2010 ni TMG 2010 establece los límites de disco duros. El límite se establece por la autoridad que expide el certificado de SAN y por supuesto la limitación de tamaño del propio certificado. Aunque no es un límite físico, la mayoría de las autoridades de certificado recomiendan a SAN menos de 40 entradas de la lista. Mantener la lista de SAN en menos de 40 entradas es una buena idea, porque la lista hace que el tamaño del certificado sea mayor para cada nombre de agregado. En la práctica, por lo tanto, es mejor mantener a 40 como máximo.
Algunos dispositivos proxy sólo admiten los 10 primeros SANs en un certificado. Para la mayoría, la principal preocupación es mantener la ventana inicial de saturación demasiado grande. El SSL handshake "servidor" mensaje de saludo es lo primero que el socket SSL se envía al cliente. Si es demasiado grande, la ventana inicial de saturación (cosas TCP) es alta para la conexión de socket y hará que la E/S de zócalo inferior al óptimo.
Intente mantener el número de entradas en menos de 40. Listas grandes pueden conducir a un rendimiento deficiente. Un certificado con 40 entradas de la lista de SAN también sería bastante costoso y una pesadilla administrativa.
Auténticamente Virtual
P. Nos quedamos Exchange 2010. Publicamos OWA, EAS y Outlook Anywhere (OA) a Internet con Forefront TMG 2010, que también pre-authenticates los clientes de Exchange que se conectan desde Internet. Queremos proporcionar autenticación basada en formularios a los usuarios OWA/ECP internos y externos, por lo que hemos creado un sitio Web adicional en IIS. Creamos un nuevo /OWA y el directorio virtual de /ECP por debajo de este sitio. Configuramos esto según las recomendaciones de esta entrada de blog en el equipo de Exchange de Microsoft blog y funciona perfectamente.
Nos gustaría agregar un directorio virtual de RPC (OA) para el segundo sitio Web, pero que realmente no hemos sido capaces de encontrar cualquier documentación acerca de cómo hacerlo. ¿Puede iluminar nosotros?
**R.**Soporte técnico de Windows Server 2008 especifica los sitios Web diferentes para el componente Proxy de RPC, pero sólo se ejecuta en un único sitio, no de varios sitios Web. Exchange 2010 no admite OA en sitios Web no sea el sitio Web predeterminado en un servidor de acceso de cliente. Además, Windows y Exchange Server no admiten Proxy de RPC o OA que se ejecuta en varios sitios Web en el mismo servidor. Esto ha sido así desde Windows Server 2003 y Exchange 2003, donde se introdujo RPC sobre HTTP.
.jpg)
Henrik Waltheres 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 Consulting (un Microsoft Gold Certified Partner en Dinamarca) y como escritor técnico para Biblioso Corp. (una empresa en Estados Unidos especializada en servicios de documentación y localización administrados).