Résumé
La découverte automatique est la fonctionnalité utilisée par Outlook pour obtenir des informations de configuration pour les serveurs auxquels il se connecte. Dans Outlook 2016 avec les serveurs Exchange, la découverte automatique est considérée comme le point de vérité unique pour les informations de configuration et doit être configurée et fonctionner correctement pour qu’Outlook soit pleinement fonctionnel. Cet article décrit l’implémentation de la découverte automatique dans la version « Démarrer en un clic » actuelle d’Outlook 2016. Pour plus d’informations sur les versions du canal client Office 365, consultez les sites web Microsoft suivants :
Numéros de version et de build des versions de canal de mise à jour pour les clients Office 365
Versions du canal de mise à jour du client Office 365
Informations complémentaires
Calendrier de découverte automatique
La découverte automatique s’exécute aux moments suivants :
- Lors de la création du compte.
- À des intervalles définis pour collecter les modifications apportées aux URL qui fournissent des fonctionnalités de service Web Exchange (OOF, service de disponibilité, etc.). Si ce processus réussit, une autre tentative est effectuée une heure plus tard. Si la tentative échoue, la prochaine tentative est effectuée 5 minutes plus tard. Chaque tentative peut potentiellement être échelonnée de 25 % en raison de l’infrastructure de tâches en arrière-plan utilisée par toutes les applications Microsoft Office.
- En réponse à certains échecs de connectivité. Dans divers scénarios, lorsqu’une tentative de connexion échoue, Outlook démarre une tâche de découverte automatique pour récupérer les nouveaux paramètres dans toute tentative de correction du problème de connexion.
- Lorsqu’une autre application l’appelle à l’aide de MAPI. Pour plus d’informations sur MAPI, consultez l’article MSDN suivant : Référence MAPI Outlook.
Efficacité de la découverte automatique
Utilisez le nom d’utilisateur principal (UPN) pour accélérer le processus de découverte automatique.
Sur un ordinateur joint à un domaine, Outlook doit connaître l’UPN d’un utilisateur afin de lancer le processus de découverte automatique. L’UPN peut avoir été utilisé pour se connecter à Windows, auquel cas Outlook a un accès direct au UPN à partir des informations d’identification de connexion. Toutefois, si un utilisateur utilise domaine\nom d’utilisateur pour se connecter à Windows, Outlook n’a que les mêmes informations d’identification pour l’utilisateur. Pour obtenir l’UPN, Outlook doit d’abord rechercher l’utilisateur dans l’annuaire. Outlook demandera que cette recherche recherche des références. Dans des environnements complexes, un grand nombre de contrôleurs de domaine peuvent être contactés avant qu’un résultat ne soit trouvé. Une fois qu’Outlook découvre l’UPN pour l’utilisateur, la valeur est mise en cache dans le profil et la recherche ne doit plus se reproduire pour cet utilisateur.
Pour éviter ce scénario, l’utilisateur peut ouvrir une session à l’aide d’un nom d’utilisateur principal au lieu de nom d’utilisateur/domaine.
Considérations ITAR
Microsoft Office 365 offre des fonctionnalités qui peuvent aider les clients à respecter leurs obligations ITAR. Dans le contexte de la fonctionnalité de découverte automatique d’Outlook, cet ensemble de fonctionnalités inclut des paramètres de stratégie et un comportement qui garantissent que les points de terminaison de service utilisés pour la découverte automatique respectent les exigences du cloud souverain. Plus précisément, dans les étapes spécifiques à Office 365 répertoriées dans le processus de découverte automatique (étapes 4 et 11), un contrôle de stratégie est disponible pour garantir que les points de terminaison de service appropriés sont utilisés pendant le processus de découverte automatique.
Processus de découverte automatique Chaque fois qu’Outlook a besoin d’informations de découverte automatique, il utilise un ensemble d’étapes ordonnées pour tenter de récupérer une charge utile XML contenant des paramètres de configuration. Bon nombre de ces étapes peuvent être contrôlées à l’aide d’objets de stratégie de groupe (GPO), et la valeur GPO est incluse dans la description de l’étape.
Étape 1 : Rechercher les scénarios de redémarrage
Dans certains cas, par exemple lorsque vous ajoutez un deuxième compte pendant l’exécution d’Outlook, la charge utile de découverte automatique est mise en cache dans un fichier local à utiliser lors d’un redémarrage du client Outlook. La toute première étape de la découverte automatique consiste à case activée dans le Registre des informations de « démarrage » spéciales qui indiquent à Outlook que vous êtes au milieu de l’un de ces scénarios de redémarrage et à lire la charge utile de découverte automatique à partir du fichier local spécial. Il s’agit d’un cas rare et généralement pas la cause de problèmes génériques de découverte automatique. Pour cette étape, si Outlook détermine que vous êtes dans ce scénario de démarrage spécial et que la tentative de récupération des données XML de découverte automatique échoue, c’est toute la tentative de découverte automatique qui échoue. Aucune étape supplémentaire n’est tentée.
Il n’existe aucun contrôle de stratégie spécifique pour cette étape.
Étape 2 : Vérifier la préférence de Données locales
Outlook fournit un objet de stratégie de groupe permettant aux administrateurs de déployer un fichier XML de découverte automatique spécifique à utiliser pour la configuration. Si l’administrateur a déployé cette valeur de Registre et amorcé un fichier autodiscover.xml, Outlook lit la charge utile de découverte automatique à partir de ce fichier. Il s’agit là encore d’un cas rare et généralement pas la cause de problèmes génériques de découverte automatique. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 3.
Pour plus d’informations sur le XML de découverte automatique, consultez l’article TechNet suivant : Planifier la configuration automatique des comptes d’utilisateurs dans Outlook 2010
Remarque Cet article a été créé pour Outlook 2010. Toutefois, elle reste pertinente pour les versions ultérieures d’Outlook.
La valeur du contrôle de stratégie pour cette étape est la suivante : PreferLocalXML.
Étape 3 : Vérifier les données du dernier bien connu (LKG)
Lorsque la découverte automatique récupère une charge utile XML à n’importe quelle étape, la charge utile peut être mise en cache localement en tant que « dernière configuration valide connue ». La première méthode généralement réussie pour obtenir une charge utile de découverte automatique est à partir de ce dernier fichier valide connu. Le chemin du dernier fichier XML valide connu provient du profil Outlook. L’étape LKG est utilisée uniquement pour découvrir la configuration de la boîte aux lettres principale. Si la recherche de découverte automatique concerne une boîte aux lettres non principale (secondaire, délégué, dossier public, boîte aux lettres de groupe, etc.), l’étape LKG est automatiquement ignorée. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 4.
La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeLastKnownGoodURL.
Étape 4 : Vérifier la priorité d’O365
Outlook utilise un ensemble d’heuristiques pour déterminer si le compte d’utilisateur fourni provient d’Office 365. Si Outlook détermine avec certitude que vous êtes un utilisateur O365, une tentative est effectuée pour récupérer la charge utile de découverte automatique à partir des points de terminaison O365 connus (généralement https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml ou https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 5.
La valeur du contrôle de stratégie pour cette étape est la suivante :
ExcludeExplicitO365Endpoint.
Considérations ITAR
Par défaut, Outlook interroge le point de terminaison connu pour récupérer la charge utile de découverte automatique. La stratégie existante pour contourner cette étape est toujours valide et peut être utilisée pour passer à l’étape 5 sans essayer le point de terminaison. Par ailleurs, il existe une nouvelle stratégie qui demande à Outlook d’interroger un service de configuration central d’Office 365 afin de récupérer les URL appropriées à partir desquelles récupérer la charge utile de découverte automatique. Conceptuellement, le processus fonctionne comme suit :
- Vous avez défini la nouvelle stratégie.
- Au cours de l’étape 4 du processus de découverte automatique, Outlook interroge le service de configuration d’Office 365.
- Le service détermine quels besoins ITAR spéciaux (le cas échéant) sont en cours pour l’utilisateur spécifié et renvoie les URL appropriées pour cet utilisateur à l’aide des informations de domaine de l’UPN.
- Outlook tente de récupérer la charge utile de découverte automatique à partir des URL fournies par le service.
La valeur de contrôle de stratégie pour la nouvelle fonctionnalité utilisant le service de configuration d’Office 365 est EnableOffice365ConfigService.
Remarque
À compter de la build 16.0.9327.1000, la stratégie EnableOffice365ConfigService n’est plus utilisée.
Étape 5 : Vérifier les données SCP
Si l’ordinateur est joint à un domaine, Outlook exécute une requête LDAP pour récupérer les données du point de connexion de service qui renvoient un chemin du XML de découverte automatique. Une tentative est ensuite effectuée sur chaque URL renvoyée par la recherche SCP pour tenter de récupérer la charge utile de découverte automatique. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 6.
Pour plus d’informations sur SCP, consultez l’article MSDN suivant : Publication avec des points de connexion de service.
La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeScpLookup.
Étape 6 : vérifier le domaine racine
Pour cette étape, Outlook génère une URL à partir du nom de domaine de l’adresse initiale au format https://< domaine>/découverte automatique/autodiscover.xml et tente de récupérer la charge utile à partir de l’URL résultante. Étant donné que de nombreux domaines racines ne sont pas configurés pour la découverte automatique, Outlook supprime délibérément toutes les erreurs de certificat qui se produisent lors de la tentative de récupération. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 7.
La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeHttpsRootDomain.
Étape 7 : Vérifier le domaine de découverte automatique
Pour cette étape, Outlook crée une URL à partir du nom de domaine de l’adresse initiale au format de https://autodiscover.<domaine>/autodiscover/autodiscover.xml et tente de récupérer la charge utile à partir de l’URL résultante. Comme il s’agit de l’URL principale généralement dédiée aux données de découverte automatique, Outlook ne supprime pas les erreurs de certificat qui se produisent lors de la tentative de récupération. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 8.
La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeHttpsAutoDiscoverDomain.
Étape 8 : Vérifier la présence de données locales
À l’étape 2, Outlook a vérifié si l’administrateur avait déployé une stratégie pour vérifier spécifiquement la case activée pour la charge utile de découverte automatique comme préférence. Si aucune stratégie n’est en place, mais que les étapes précédentes n’ont pas permis de récupérer une charge utile, Outlook tente maintenant de récupérer une charge utile à partir du fichier local, même sans le paramètre PreferLocalXML en place. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 9.
Il n’existe aucun contrôle de stratégie pour cette étape.
Étape 9 : vérifier la présence de redirections HTTP
Pour cette étape, Outlook envoie une demande à l’URL du domaine de découverte automatique (http://autodiscover.<domaine>/autodiscover/autodiscover.xml) et testez les réponses de redirection. Si une charge utile XML de découverte automatique réelle est renvoyée et non une redirection, Outlook ignore la réponse XML de découverte automatique réelle, car elle a été récupérée sans sécurité (http). Si la réponse est une URL de redirection valide, Outlook suit la redirection et tente de récupérer un fichier XML de charge utile à partir de la nouvelle URL. Outlook effectuera également des vérifications de certificat pour empêcher la redirection vers des URL potentiellement dangereuses à cette étape. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 10.
La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeHttpRedirect.
Étape 10 : Vérifier les données SRV
Pour cette étape, Outlook effectue une requête DNS pour « _autodiscover._tcp.<nom de> domaine » et parcourt les résultats à la recherche du premier enregistrement qui utilise HTTPS comme protocole. Outlook tente ensuite de récupérer la charge utile à partir de cette URL. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 11.
La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeSrvRecord.
Étape 11 : Rechercher O365 comme sécurité intégrée
Si toutes les étapes précédentes n’ont pas renvoyé de charge utile, Outlook utilise un ensemble d’heuristiques moins restrictif pour déterminer si une dernière tentative sur les points de terminaison O365 est potentiellement utile. Si Outlook estime qu’une tentative vaut la peine, il essaie d’utiliser les points de terminaison connus de découverte automatique O365 si le compte est un compte O365. Cette tentative utilise les mêmes URL cibles que l’étape 4 et ne diffère que par le fait qu’elle est tentée en dernier recours et non plus tôt dans le processus de découverte automatique.
La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeExplicitO365Endpoint.
Considérations ITAR
Si Outlook arrive à cette étape et n’a pas récupéré une charge utile de découverte automatique, deux tests sont effectués pour voir si les points de terminaison d’Office 365 bien connus doivent être essayés. Tout d’abord, si la boîte aux lettres est un compte consommateur (par exemple, outlook.com), le point de terminaison connu est tenté. Deuxièmement, si la boîte aux lettres appartient à un domaine qui n’a pas de exigences ITAR, le point de terminaison bien connu est tenté. S’il s’agit d’une boîte aux lettres commerciale appartenant à un domaine qui a des exigences ITAR, aucune tentative n’est effectuée sur les points de terminaison Office 365 bien connus. Dans les versions ultérieures, l’étape 11 peut passer à la même logique que l’étape 4 et appeler le service de configuration d’Office 365. Lorsque cette modification sera apportée, cet article sera mis à jour pour refléter la nouvelle étape du processus.
L’étape 9 de la section Processus de découverte automatique est une étape explicite pour gérer les données de redirection non sécurisées. Dans les autres étapes sécurisées, pour toute tentative de récupération de la charge utile XML de découverte automatique, une réponse possible du point de terminaison est une réponse de redirection. Cette réponse indique à Outlook de rediriger vers une nouvelle URL différente pour tenter de récupérer la charge utile. De plus, les données de redirection peuvent contenir une nouvelle adresse e-mail différente à utiliser comme adresse cible pour la tentative de découverte automatique. Outlook considère trois réponses distinctes comme des « réponses de redirection » :
- Un code de status HTTP (301, 302) avec une nouvelle URL
- Un code de status HTTP de 200, mais avec un code XML de charge utile qui indique à Outlook de rediriger vers une autre URL
- Un code de status HTTP de 200, mais avec un code XML de charge utile qui indique à Outlook d’utiliser une autre adresse SMTP comme adresse cible.
Dans les cas 1 et 2, Outlook tente de récupérer le XML de découverte automatique à partir de la nouvelle URL, à condition que le protocole soit https. Les tentatives d’URL non sécurisées (http) ne sont pas effectuées. En outre, même si le protocole de la nouvelle URL est https, Outlook vérifiera les informations de case activée pour fournir une mesure de sécurité supplémentaire.
Pour le cas 3, Outlook démarre l’ensemble du processus de découverte automatique depuis le début. Si toutes les étapes (1-11) sont tentées sans succès à l’aide de la nouvelle adresse e-mail, Outlook revient à l’adresse e-mail d’origine, passe à l’étape 5 et continue la tentative de récupération d’une charge utile XML avec l’adresse d’origine.
Exceptions : Les étapes de la section Processus de découverte automatique sont les règles générales permettant d’obtenir la charge utile de découverte automatique par Outlook. Il existe diverses optimisations et tentatives exceptionnelles qui peuvent modifier légèrement le processus. Par exemple, lors de la création d’un compte, Outlook ignore en interne l’étape 3 (case activée pour les données LKG), car il ne peut pas encore avoir de dernière entrée valide connue. De même, si une tentative a été déclenchée en raison d’une erreur en utilisant les informations de configuration actuelles, Outlook souhaite volontairement effectuer une nouvelle découverte automatique et ne pas utiliser les informations LKG, car les dernières informations correctes connues ont probablement entraîné un échec.
Contrôle de stratégie Les valeurs de stratégie définies dans la section Processus de découverte automatique peuvent être des valeurs de Registre basées sur des stratégies ou des valeurs non basées sur des stratégies. Lorsqu’ils sont déployés par le biais d’un GPO ou d’une configuration manuelle de la clé de stratégie, les paramètres sont prioritaires sur la clé non-stratégie.
Clé sans stratégie : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Clé de la stratégie : HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover
Chaque valeur est de type DWORD.
PreferLocalXML diffère des autres valeurs de contrôle, car le paramètre 1 définit Outlook pour activer cette étape dans le processus. Pour les valeurs restantes, le paramètre 1 indique à Outlook de désactiver ou d’ignorer l’étape associée. Par exemple, définir la valeur ExcludeHttpsRootDomain sur 1 définit Outlook pour ne pas effectuer l’étape 6 dans le processus.
Contrôles de registre supplémentaires
Outlook fournit plusieurs options de configuration supplémentaires basées sur le registre qui peuvent affecter le processus de découverte automatique :
Utiliser le service de configuration d’Office 365
Clé : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Valeur : EnableOffice365ConfigService
Par défaut : 0
Données : définissez ces données DWORD sur 1 pour forcer Outlook à appeler le service de configuration d’Office 365 pour récupérer les URL de découverte automatique appropriées.
Paramètres de délai d’attente HTTP
Clé : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Valeur : délai d’expiration
Valeur par défaut : 25 secondes
Minimum : 10 secondes
Maximum : 120 secondes
Information : les délais spécifiés sont utilisés comme paramètres WinHttpSetTimeouts . Les données spécifiées sont transmises aux quatre paramètres de l’API WinHttpSetTimeouts. Une requête HTTP qui ne peut pas être atteinte peut ainsi expirer plus rapidement, ce qui améliore les performances globales. Ces paramètres peuvent également permettre à une requête HTTP plus longue que la valeur par défaut de 25 secondes de réussir en augmentant le paramètre de délai d’attente à une valeur supérieure à 25 secondes.
Contrôle du protocole Mapi/HTTP
Clé : HKEY_CURRENT_USER\Software\Microsoft\Exchange
Valeur : MapiHttpDisabled
Par défaut : 0
Données : 1 = le protocole est désactivé ; 0 = le protocole est activé
Information : cette valeur ne se trouve pas sous la clé de découverte automatique. Il s’agit d’un paramètre général qui détermine si Outlook peut tenter de se connecter à Exchange à l’aide de la pile de protocoles Mapi/Http. La valeur par défaut dans Outlook 2016 est de ne pas désactiver ce protocole. Cela permet au processus de découverte automatique d’ajouter un en-tête spécial (X-MapiHttpCapability :1) au processus de découverte afin que les paramètres du protocole Mapi/HTTP puissent être évalués et traités.
Contrôle de négociation de l’authentification héritée
Clé : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
Valeur : AllowNegoCapabilityHeader
Par défaut : 0
Données : 1 = les en-têtes sont ajoutés ; 0 = les en-têtes ne sont pas ajoutés
Information : Notez que cette valeur n’est pas sous la clé de découverte automatique. Ce paramètre détermine si un en-tête de négociation d’authentification est ajouté aux requêtes http. Le contenu de l’en-tête dépend des capacités d’authentification de l’ordinateur client. Voici un exemple d’en-tête : « X-Nego-Capability : Negotiate, pku2u, Kerberos, NTLM, MSOIDSSP ». Cette valeur de Registre et l’en-tête qu’elle ajoute sont rarement utilisés dans les piles d’authentification modernes et très peu susceptibles d’affecter le processus tAodiscover de manière négative ou positive.
Gestion des erreurs de certificat
Clé : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Valeur : ShowCertErrors
Par défaut : 0
Données : 1 = Afficher les avertissements/erreurs de certificat ; 0 = ne pas afficher les avertissements de certificat
Information : cette valeur contrôle la façon dont Outlook traite les erreurs de certificat et les avertissements reçus lors de l’exécution de tâches http. Outlook peut remplacer ce paramètre dans certains cas (étape 6 de la section Processus de découverte automatique), mais pour le cas général, si ce paramètre est activé, Outlook invite une boîte de dialogue de sécurité qui affiche l’erreur ou l’avertissement de certificat et permet à l’utilisateur d’OK ou d’annuler la demande Http. Il existe trois erreurs de certificat spécifiques que l’utilisateur peut décider d’ignorer et de demander à Outlook de réessayer la requête http :
WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID : un problème existe avec la date dans les propriétés du certificat.
WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID : le nom commun dans les propriétés du certificat présente un problème.
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – Il y a un problème avec l’autorité de certification dans les propriétés du certificat
Pour plus d’informations sur ces trois états d’erreur de certificat, consultez WINHTTP_STATUS_CALLBACK fonction de rappel
Gestion de l’authentification proxy
Clé : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
Valeur : AllowOutlookHttpProxyAuthentication
Par défaut : 0
Données : 1 = autoriser Outlook à gérer les défis d’authentification à partir de serveurs proxy ; 0 = échec silencieux des problèmes d’authentification de serveurs proxy
Information : Cette valeur de registre permet d’assouplir une configuration de sécurité et est traitée en détail dans l’article suivant de la Base de connaissances Microsoft :
3115474 MS16-099 : Description de la mise à jour de sécurité pour Outlook 2010 datée du 9 août 2016
Découverte automatique pour d’autres protocoles
La découverte automatique en tant que fonctionnalité est également utilisée par Outlook pour découvrir et configurer les comptes Exchange ActiveSync (EAS). Le processus de découverte automatique et la prise de décision EAS sont distincts des étapes décrites dans cet article. Par exemple, l’implémentation EAS n’implémente pas la logique de point de terminaison O365 et n’a pas d’étape qui vérifie les emplacements SCP. Cet article décrit en détail les étapes détaillées utilisées par Outlook pour les tentatives de découverte automatique visant à obtenir les protocoles MAPI à partir d’Exchange.
Références
Vous trouverez des informations héritées sur la découverte automatique dans l’article suivant de la Base de connaissances Microsoft :
2212902 Comportement inattendu de découverte automatique lorsque vous avez les paramètres de registre sous la clé \Autodiscover
Pour plus d’informations sur la découverte automatique, consultez les articles Microsoft suivants :