Autodiscover con Exchange Híbrido

Uno de los aspectos claves dentro del proceso de planificación de Exchange, es la configuración del servicio de Autodiscover. Muchos de los problemas a nivel de acceso de clientes está relacionado con este tema.

Esto incluye configuración de perfiles, fuera de oficina, descarga de libreta de direcciones (OAB) entre otros, todos dependen de que el servicio de Autodiscover funcione correctamente.


Para qué usar Autodiscover?

El servicio de Autodiscover proporciona información que clientes como Outlook o Activesync utilizan para configurar el perfil y acceder a varios servicios o recursos como por ejemplo buzones compartidos, delegados, buzones de archivo y carpetas públicas.

Este proceso permite que los clientes puedan conectarse al correo prácticamente de forma automática ya que lo único que deben conocer son datos de dirección de correo, usuario y contraseña. Adicionalmente, mediante la configuración de sufijos UPN alternativos podemos hacer coincidir la dirección de correo con la cuenta del usuario lo que podría evitar confusión y minimizar las llamadas de soporte por este tema.

La realidad es que hoy por hoy si usar autodiscover o no ya no es una opción, para que los clientes no tengan problemas con los distintos tipos de acceso al correo (más allá de enviar y recibir mail) es necesario configurar autodiscover. Casos puntuales como configuración de dispositivos móviles aun funcionaría bien con la configuración manual, pero ya no sería así en el caso del cliente Outlook.

La configuración asociada a este servicio abarca múltiples componentes y dependiendo de si el usuario accede desde un equipo interno o externo cómo funciona el acceso.

Esta configuración la detallo en los cursos exclusivos del sitio, en este artículo vemos puntualmente cómo se debe configurar el punto de acceso al servicio de autodiscover partiendo de la base que a nivel On Premises este se encuentra bien configurado.


Qué pasa cuando una organización tiene buzones On Premises y en Exchange Online? A dónde se debe apuntar el registro DNS de Autodiscover?

Si pensamos el caso de una implementación híbrida de Exchange, donde tenemos usuarios de correo por ejemplo @empresa.com On Premises y usuarios @empresa.com en Exchange Online es necesario contar con un punto de acceso centralizado donde se identifique si es un usuario On Premises o si se encuentra en la nube y en base a este resultado qué camino tomar.

La respuesta corta es la siguiente: El registro DNS de autodiscover debe apuntar a la organización On Premises.

De este modo cuando clientes alojados en la nube intenten conectarse con su buzón en Office 365 primero se conectarían a un Exchange On premises para luego ser redireccionados al autodiscover en Office 365. Esto se resuelve en base a un atributo del usuario en Active Directory: “TargetAddress”. Este atributo es estampado como parte del proceso de configuración de un buzón en Exchange Online (ya sea un buzón de 0 o un buzón migrado a la nube).

El atributo TargetAddress esta compuesto por el nombre del Tenant seguido por mail.onmicrosoft.com. Si el tenant de la empresa es “empresa”, este atributo sería “usuario@empresa.mail.onmicrosoft.com”.

Una vez que el cliente recibe la información proporcionada por el servidor on premises comienza nuevamente el proceso de autodiscover pero esta vez en base al atributo TargetAddress para luego conectarse a “autodiscover.nombredetenant.mail.onmicrosoft.com” que sería un alias a “autodiscover.outlook.com” (el proceso completo es más extenso y se encuentra documentado en el blog del equipo de producto de Exchange).


Qué pasa en el caso de que se migren todos los buzones a la nube? Se debe modificar el registro DNS de Autodiscover?

Usualmente con fines administrativos se recomienda mantener al menos un servidor con Exchange On Premises, en este caso ya no tendría buzones pero opcionalmente podría ofrecer servicios como por ejemplo el caso de autodiscover. Si bien esta podría ser una opción, la realidad es que ya no tendría mucho sentido y agrega un posible punto de falla.

En definitiva, una vez migrado todos los buzones a la nube lo ideal sería apuntar el registro de Autodiscover a Office 365. Para lograr esto se configura un registro DNS de tipo alias “autodiscover.empresa.com” que apunte a “autodiscover.outlook.com”.


Una vez configurado el servicio de autodiscover, la recomendación es validar el funcionamiento usando la siguiente herramienta de Microsoft:


 

Acerca de Daniel Núñez Banega

Consultor IT especializado en Microsoft Exchange y Active Directory.
Principales Certificaciones: Microsoft Certified Trainer | Microsoft Certified Solutions Expert | Microsoft Certified Systems Engineer | Microsoft Certified Systems Administrator | Microsoft Certified IT Professional | Microsoft Certified Technology Specialist

Interacciones del lector

Comentarios

  1. Miguel Sanchez dice

    Actualmente tenemos un ambiente híbrido. Hace poco actualizamos el certificado ssl de exchange on premise, pero desde esa configuración no funciona la conexion exchange para clientes outlook,esto ocurre solamente con usuarios locales.
    Valide el autodiscover en testconnectivity.microsoft.com y arroja lo siguiente:

    Certificate trust is being validated.
    The certificate is trusted and all certificates are present in the chain.

    Test Steps

    The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=outlook.novasoft.com.co, OU=Domain Control Validated.
    One or more certificate chains were constructed successfully.

    Additional Details

    A total of 2 chains were built. The highest quality chain ends in root certificate OU=Go Daddy Class 2 Certification Authority, O=”The Go Daddy Group, Inc.”, C=US.
    Elapsed Time: 12 ms.
    Analyzing the certificate chains for compatibility problems with versions of Windows.
    Potential compatibility problems were identified with some versions of Windows.

    Additional Details

    The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the “Update Root Certificates” feature isn’t enabled.
    Elapsed Time: 3 ms.

    No se cual es el inconveniente para que los clientes outlook con usuarios locales no funcione.

    • Daniel Núñez Banega dice

      Hola Miguel, que error exacto reciben los usuarios?
      Desde los clientes problemáticos revisaste la información que obtienen de Autodiscover?

  2. Miguel Sanchez dice

    Después de que configuro el cliente outlook, me pide reiniciarlo, entonces lo reinicio y cuando vuelvo ha abrir outlook me arroja un mensaje “La conexión a Microsoft Exchange no se encuentra disponible. Outlook tiene que estar en linea o conectado para realizar esta acción”.

    Después me arroja una ventana donde ;

    Servidor microsoft exchange:
    outlook.nova.com.co

    buzon:prueba@nova.com.co

    y selecciono comprobar nombre.
    me arroja que no se pude comprobar nombre.

    Esto ocurre solamente con los buzones onpremise.

    • Daniel Núñez Banega dice

      Hola Miguel, se me ocurre que algo a nivel de autodiscover o sus dependencias no esté funcionando correctamente. Esto debería estar configurado apuntando a la organización on premises.
      Te recomiendo revisar el asistente de implementación híbrida de Microsoft y en base a esto verificar si alguno de los puntos no fue tenido en cuenta en su momento:
      https://technet.microsoft.com/es-es/office/dn756393.aspx

  3. Manuel Montilla dice

    tengo problemas para mis clientes en moviles no me permite la configuracion, tengo una plataforma exchange 2013 y tambien sucede lo del servico autodiscover no me funciona no se en que me podrias ayudar

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *