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 y el caso particular de entornos híbridos dentro de lo que sería el Taller Intensivo de Migración Híbrida a Office 365.
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:
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.
Hola Miguel, que error exacto reciben los usuarios?
Desde los clientes problemáticos revisaste la información que obtienen de Autodiscover?
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.
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
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
Hola Manuel, te dejo link a un artículo de Microsoft donde se detalla el funcionamiento de autodiscover:
https://technet.microsoft.com/es-es/library/bb124251(v=exchg.150).aspx
Buen día, Daniel te cuento que tengo un ambiente híbrido, pero cuando me generaron un nuevo certificado, ya no me reconoce uno de los dominios, por esta razón todos los buzones que están en On premise no envían ni reciben de cuentas que no sean locales, los buzones que tenemos en 365 no le pueden enviar a esas cuentas.
Hola Wilmar, es muy amplio lo que comentas, sería necesario conocer el escenario específico y detalle del problema.
Entonces, ¿qué pasa con el escenario en el que algunos buzones de correo se dejan en las instalaciones? Tengo todos mis usuarios reales en O365, pero tenemos algunos servicios y buzones de correo compartidos en las instalaciones. Mi idea era cambiar los registros públicos a O365 (principalmente para dejar de publicar esa IP) y dejar los registros de detección automática internos apuntando al servidor local.
Hola Roser, si los buzones que mantenes On Premises no son utilizados mediante ningún servicio que requiera autodiscover podría ser posible hacer el cambio.
Buenas tardes, tenemos un evento extraño con falla de conexion en el outlook. En la consola de administracion del exchange 2016, en mail flow, receive connectors, se desactivo client frontend, y algunos outlook presentaron falla de error a abrirlos, y cuando vi, se habia cambiado el archivo .xml de conexion, en la carpeta outlook. lo borramos y vuelve a crearse y funciona, pero porque pasa esto, parece que detecta otra red y cambia el archivo por una conexion tipo imap, y falla. como corrijo eso.?
Buenas Lisandro, el problema de Outlook no debería tener relación con lo que comentas sobre los conectores, más bien apuntaría a un problema de autodiscover.
Tengo un detalle, en mis versiones de Outlook 2013 al configurar la cuenta me manda la pantalla de autenticación basica y en Outlook 2016 se ve que va a mostrar una pantalla pero desaparece y al final en las dos versiones me manda error de comunicación