Compartir a través de


Intercambio de cola & A: Traslado a la nube

Usted tendrá algunas decisiones que al mover el correo electrónico de local a un entorno basado en la nube como Exchange Online.

Henrik Walther

A través del bosque

P. Nos estamos quedando Exchange 2010 dentro de una organización de grandes empresas. Tenemos un negocio socio ejecutando Exchange 2007. Tenemos que ser capaces de compartir calendarios y la información de disponibilidad con este socio. Debido a esto, hemos configurado entre bosques disponibilidad por las instrucciones para Exchange 2010 en la biblioteca de TechNet.

Sin embargo, incluso después de haber verificado que podemos resolver y realizar peticiones de detección automática entre bosques, nosotros todavía no podemos recuperar información de disponibilidad. ¿Tienes alguna idea qué es prevenir esto?

R. Desde Exchange 2007 lanzado para fabricación (RTM), ha habido algo de un error que los resultados en detección automática utilizando la dirección URL interna del directorio virtual de servicios Web de Exchange (EWS) cuando buscando información de disponibilidad para los usuarios entre bosques (véase figura 1). De forma predeterminada, la dirección URL interna del directorio virtual EWS puntos a CAS_server.fqdn.com. Por lo tanto, debe poder resolverse. Esto también significa que el nombre de dominio completo (FQDN) deben ser resueltas.

Autodiscover will use the Exchange Web Services virtual directory internal URL by default.

Figura 1 detección automática usará la URL interna del directorio virtual de servicios Web de Exchange por defecto.

Aunque esto está lejos de ser ideal, hay correcciones que cambian este comportamiento para Exchange 2007 y Exchange 2010. Cuando se trata de Exchange 2007, aplicar el Update Rollup 6 para el SP3 de Exchange Server 2007. Para Exchange 2010, aplicar el Update Rollup 1 para Exchange 2010 Service Pack 2. Con la solución aplicada, usted podrá enviar solicitudes de disponibilidad por Internet. Funcionará bien en Exchange topologías de sitio proxy así. Con la solución aplicada, la fuente de servidor de acceso de cliente (CAS) honrará la URL externa para el directorio virtual de EWS y no de forma predeterminada mediante la dirección URL interna de EWS.

Tenga en cuenta que después de aplicar esta revisión, la URL externa para EWS debe poder resolverse entre los bosques de Exchange compartir información de disponibilidad. No puede configurar el servicio de disponibilidad para utilizar la dirección URL interna de EWS para búsquedas de disponibilidad entre bosques.

Autenticación en línea

P. Estamos actualmente en las fases de la planificación de nuestro Exchange 2007 local infraestructura de mensajería para el componente de Exchange Online de Office 365 en movimiento. Nuestro plan es configurar una implementación de Exchange híbrido y Federación de identidades.

Una cosa que estamos un poco seguros es soporte para autenticación con varios sufijos de nombre principal (UPN) de usuario. Hemos oído para algunos usuarios autenticar contra Active Directory Federation Services (ADFS) con alias@domain1.com y otros usuarios que se autentican con alias@domain2.com, tenemos una granja de Federación de ADFS por UPN que queremos utilizar para fines de autenticación. ¿Puede usted arrojar algo de luz sobre esto?

**R.**Esta es la situación. Antes Update Rollup 1 (Nota Update Rollup 2 está disponible y debe utilizar) para la versión 2.0 de ADFS para Web (RTW), las empresas que implementan la Federación de identidades basada en ADFS con Office 365 debían implementar una granja de Federación de ADFS por UPN que necesita autenticarse contra un servicio de Office 365. Esto significó que la empresa tuvo que desplegar dos servidores proxy ADFS y dos servidores ADFS por UPN compatible. Así que esto requeriría ocho servidores soportar dos UPN. Usted podría ir con un servidor proxy ADFS y un servidor ADFS por UPN, pero realmente no desea introducir un punto único de falla.

Ahora Update Rollup 1 o posterior para RTW de ADFS 2.0 soporta múltiples UPN por explotación de Federación de ADFS. Uno de mis recientemente publicado publicaciones en blogs, "Office 365 – ADFS & Soporte para múltiples de UPN," le guiará en cómo introducir el soporte para un UPN adicional en la implementación de ADFS existente (ver figura 2).

You’ll have to ensure you have the proper infrastructure to support ADFS authentication.

Figura 2 usted tendrá que asegurarse de que tiene la infraestructura adecuada para soporte de autenticación de ADFS.

Ahorro de servidores

P. Nos estamos moviendo de nuestra infraestructura de mensajería basado en Exchange 2003 de local a la parte de intercambio en línea de Office 365. Estamos estableciendo una configuración híbrida para lograr la convivencia Rico. También queremos establecer la Federación de identidades, pero no tenemos el presupuesto para cuatro servidores adicionales en nuestro entorno local.

Actualmente contamos con cuatro servidores de Exchange 2003. La implementación de Exchange híbrido, ya nos estamos implementando dos servidores de Exchange 2010. También estamos implementando un servidor para la sincronización de directorios. ¿Sabes cómo podemos mantener el número de servidores necesarios al mínimo y también lograr alta disponibilidad?

**R.**Hay dos opciones para la configuración de Federación de identidades. Como ya sabéis, necesitará dos servidores ADFS en la red interna y dos servidores proxy ADFS en la red perimetral. Si tiene menos de 1.000 usuarios, instalar el componente ADFS en dos controladores de dominio existentes en el entorno local es realmente una solución viable (ver figura 3). Cuando se trata de servidores proxy ADFS, puede utilizar dos servidores Web o servidores proxy en la red perimetral. Para obtener más información, consulte la "tabla de estimación: Determinar el número de servidores de ADFS 2.0 para implementar en su organización"en el"planificar e implementar ADFS 2.0 para su uso con single sign-on"artículo en el sitio de la comunidad de Microsoft Office 365.

There are specific guidelines to support your Office 365 deployment.

Figura 3 hay directrices específicas para apoyar la implementación de Office 365.

Si tiene más de 1.000 usuarios, debe utilizar servidores dedicados para los servidores internos de ADFS y servidores proxy ADFS. Estos pueden ser servidores virtuales. Si usted tiene más de 1.000 usuarios y no desea implementar servidores dedicados de ADFS en su entorno local, hay otra opción. Puede crear servidores virtuales de ADFS en Windows Azure y establecer una red privada Virtual (VPN) para su entorno local. Esto ayuda a reducir el número de servidores sin sacrificar la alta disponibilidad (HA), que es un no-go de ADFS. Tener resultados ADFS en usuarios no poder de acceso Office 365.

También puede usar Windows Azure como un sitio de recuperación ante fallos de ADFS. Implementar un servidor ADFS y un servidor de proxy ADFS en su entorno local y el resto en Windows Azure. Esta última requerirá un DC en Windows Azure así. Así que tienes un par de opciones para resolver su bloqueador de implementación actual.

Problemas de la vista previa

P. Hemos creado un nuevo inquilino en Office 365 vista previa (onda 15). Hemos podido sincronizar los objetos de usuario al inquilino con la herramienta de sincronización de directorios. Sin embargo, cuando intentamos añadir al inquilino con "Agregar bosque de Exchange" en la consola de administración de Exchange 2010 Service Pack 2, obtenemos el siguiente error: "Error al obtener información de asignación de funciones de gestión para 'server.pord.outlook.com/Microsoft Exchange Hosted Organizations/tenant_name.onmicrosoft.com/globaladmin':
Microsoft.Exchange.Data.Directory.Management.ExchangeroleAssignmentPresentation no es compatible con MockEngine!"

¿Alguna idea?

R. Deberás aplicar Exchange 2010 SP3 para poder agregar un inquilino de Office 365 vista previa (onda 15) a la consola de administración de Exchange 2010. Porque este service pack no liberarse antes de la primera mitad del año 2013, lo que usted está tratando de hacer no es compatible actualmente a menos que usted está participando en la vista previa de Office 365 o programa de intercambio de adopción de tecnología.

Romi Mahajan

Henrik Waltheres un Microsoft Certified Master: Exchange 2007 y Exchange MVP 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 un escritor técnico de Biblioso Corp. (una empresa norteamericana que se especializa en administrados de 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.

Contenido relacionado