Outlook 2016 implémentation de la découverte automatique

Résumé

La découverte automatique est la fonctionnalité que Outlook utilise pour obtenir des informations de configuration pour les serveurs avec lesquels il se connecte. Dans Outlook 2016 avec des serveurs Exchange, la découverte automatique est considérée comme le point unique de vérité pour les informations de configuration et doit être configuré et fonctionner correctement pour que Outlook soit pleinement fonctionnel. Cet article décrit l’implémentation de la découverte automatique dans la version « Click-to-Run » du canal actuel Outlook 2016. Pour plus d’informations sur les Office 365 des canaux clients, voir les sites web Microsoft suivants :

Numéros de version et de build des canaux de mise à jour pour Office 365 clients

Office 365 des canaux de mise à jour du client

Informations supplémentaires

Minutage de la découverte automatique

La découverte automatique s’exécute aux moments suivants :

Pendant la création du compte.
À des intervalles définis pour collecter les modifications apportées aux URL qui fournissent Exchange fonctionnalités de service web (OOF, Service de disponibilité, et ainsi de suite). Si ce processus réussit, un autre essai est effectué une heure plus tard. Si la tentative réussit, l’essai suivant est effectué 5 minutes plus tard. Chaque tentative peut éventuellement être décalée de 25 % en raison de l’infrastructure de tâches en arrière-plan utilisée par toutes Microsoft Office applications.
En réponse à certaines défaillances de connectivité. Dans différents scénarios, lorsqu’une tentative de connexion échoue, Outlook une tâche de découverte automatique pour récupérer les nouveaux paramètres dans le cadre de 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, voir l’article MSDN suivant : Outlook référence MAPI.

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 au domaine, Outlook nom d’utilisateur utilisateur doit connaître le nom d’utilisateur utilisateur pour initier le processus de découverte automatique. Il est possible que le nom d’Windows un nom d’Outlook ait directement accès à celui-ci à partir des informations d’identification d’identification. Toutefois, si un utilisateur utilise domaine \nom d’utilisateur pour se connecter Windows, Outlook possède uniquement les mêmes informations d’identification pour l’utilisateur. Pour obtenir le nom d’utilisateur Outlook, vous devez d’abord rechercher l’utilisateur dans l’annuaire. Outlook vous demanderez que cette recherche pourchait des références. Dans les environnements complexes, un grand nombre de PC peuvent être contactés avant qu’un résultat ne soit trouvé. Une fois Outlook l’utilisateur a été découvert, la valeur est mise en cache dans le profil et la recherche ne doit pas se reproduire pour cet utilisateur.

Pour éviter ce scénario, l’utilisateur peut se connecter à l’aide d’un nom d’utilisateur utilisateur au lieu d’un nom d’utilisateur utilisateur (domaine et nom d’utilisateur).

Considérations de la politique itar

Microsoft Office 365 fournit des fonctionnalités qui peuvent prendre en charge les clients ayant des obligations ITAR. Dans le contexte de la fonctionnalité de découverte automatique dans Outlook, cet ensemble de fonctionnalités inclut des paramètres de stratégie et un comportement qui garantit que les points de terminaison du service utilisés pour la découverte automatique respectent les exigences du cloud souverain. Plus précisément, dans les Office 365 étapes spécifiques répertoriées dans le processus de découverte automatique (étape 4 et étape 11), un contrôle de stratégie est disponible pour garantir que les points de terminaison de service appropriés soient utilisés pendant le processus de découverte automatique.

Processus de découverte automatique Chaque fois que Outlook besoin d’informations de découverte automatique, il utilise un ensemble d’étapes ordonné pour essayer 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 et la valeur d’objet de stratégie de groupe est incluse dans la description de l’étape.

Étape 1 : vérifier 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 du redémarrage du client Outlook. La première étape de découverte automatique consiste à vérifier dans le Registre des informations de « démarrage » spécifiques qui indiquent à Outlook que vous êtes au beau milieu de l’un de ces scénarios de redémarrage et de lire la charge utile de découverte automatique à partir du fichier local spécial. Il s’agit d’un cas rare qui n’est généralement pas à l’origine de problèmes de découverte automatique générique. Pour cette étape, si Outlook décide 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, toute la tentative de découverte automatique é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 les préférences de données locales

Outlook fournit un GPO qui permet 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 a déployé un fichier autodiscover.xml, Outlook lire la charge utile de découverte automatique à partir de ce fichier. Là encore, il s’agit d’un cas rare, qui n’est généralement pas la cause de problèmes de découverte automatique générique. 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, voir l’article TechNet suivant : Planifier la configuration automatique de comptes d’utilisateurs dans Outlook 2010Remarque Cet article a été créé pour

Outlook 2010. Toutefois, il est toujours pertinent pour les versions ultérieures de Outlook.

La valeur du contrôle de stratégie pour cette étape est la suivante : PreferLocalXML.

Étape 3 : recherchez les données de lKG (Last Known Good)

Lorsque le découverte automatique récupère une charge utile XML correctement à travers n’importe quelle étape, il se peut que la charge utile soit mise en cache localement en tant que configuration de « dernière bonne connue ». La première méthode courante pour obtenir une charge utile de découverte automatique est à partir de ce dernier fichier bon connu. Le chemin d’accès au dernier fichier XML bon connu provient du Outlook de données. L’étape LKG est utilisée uniquement pour découvrir la configuration de boîte aux lettres principale. Si la recherche de découverte automatique est une boîte aux lettres non principale (alternative, délégué, dossier public, boîte aux lettres de groupe, etc.), l’étape LKG est ignorée automatiquement. 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 : ExcludeLastKnownKnowURL.

Étape 4 : vérifier la priorité d’O365

Outlook un ensemble d’heuristiques pour déterminer si le compte d’utilisateur fourni provient d Office 365. Si Outlook détermine en toute confiance que vous êtes un utilisateur d’O365, une tentative est faite pour récupérer la charge utile de découverte automatique à partir des points de terminaison O365 connus (généralement en 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.

ItAR consideration

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 permet à Outlook d’interroger un service central de Office 365 de sécurité afin d’extraire les URL appropriées à partir des lesquelles récupérer la charge utile de découverte automatique. Conceptuellement, le processus fonctionne comme suit :

Vous définissez la nouvelle stratégie.
À l’étape 4 du processus de découverte automatique, Outlook interroge le service Office 365 de sécurité.
Le service détermine les besoins spécifiques en matière d’ITAR (le cas échéant) pour l’utilisateur spécifié, et renvoie les URL appropriées pour cet utilisateur à l’aide des informations de domaine du nom d’utilisateur supérieur.
Outlook tente de récupérer la charge utile de découverte automatique à partir des URL fournies par le service.

Valeur de contrôle de stratégie pour la nouvelle fonctionnalité permettant d’utiliser le service de Office 365 est EnableOffice365ConfigService.

Remarque : À partir 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 au domaine, Outlook exécute une requête LDAP pour récupérer les données du point de connexion de service qui renvoie un chemin d’accès au XML de découverte automatique. Une tentative est ensuite faite sur chaque URL renvoyée par la recherche SCP pour essayer d’extraire 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, voir 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 crée une URL à partir du nom de domaine de l’adresse initiale au format https://<domain>/autodiscover/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 de façon volontaire toutes les erreurs de certificat qui se produisent pendant 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 https://autodiscover.<domain>/autodiscover/autodiscover.xml et tente de récupérer la charge utile à partir de l’URL résultante. Étant donné qu’il s’agit généralement de l’URL principale des données de découverte automatique, Outlook 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 : recherchez les données locales

À l’étape 2, Outlook vérifié si l’administrateur avait déployé une stratégie pour vérifier spécifiquement 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 récupéré de charge utile, Outlook tente à présent de récupérer une charge utile à partir du fichier local, même si le paramètre PreferLocalXML n’est pas 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 les redirections HTTP

Pour cette étape, Outlook envoie une demande à l’URL du domaine de découverte automatique (http://autodiscover.<domain>/autodiscover/autodiscover.xml) et teste 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 XML de charge utile à partir de la nouvelle URL. Outlook également effectuer des vérifications de certificat pour empêcher la redirection vers des URL potentiellement nuisibles au cours de 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.<domain name> » et recherche le premier enregistrement utilisant 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 une charge utile, Outlook passe à l’étape 11.
La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeSrvRecord.

Étape 11 : vérifier qu’O365 est défactuant

Si toutes les étapes précédentes n’ont pas permis de renvoyer de charge utile, Outlook utilise un jeu moins restrictif de point de terminaison O365 pour déterminer si une dernière tentative vers les points de terminaison O365 est potentiellement utile. Si Outlook décide qu’une tentative est utile, elle tente les points de terminaison de découverte automatique O365 connus au cas où le compte serait un compte O365. Cette tentative utilise les mêmes URL cibles que l’étape 4 et ne diffère que du fait qu’elle a été essayée en dernier recours et non antérieurement dans le processus de découverte automatique.

La valeur du contrôle de stratégie pour cette étape est la suivante : ExcludeExplicitO365Endpoint.

Considérations de la politique itar

Si Outlook arrive à cette étape et n’a pas récupéré avec succès une charge utile de découverte automatique, deux tests sont effectués pour déterminer si les points de terminaison Office 365 connus doivent être tentés. Tout d’abord, si la boîte aux lettres est un compte grand public (outlook.com exemple), le point de terminaison connu est tenté. Deuxièmement, si la boîte aux lettres est déterminée à appartenir à un domaine qui ne est pas requis par la fonction ITAR, le point de terminaison connu est tenté. Si la boîte aux lettres est déterminée comme commerciale et appartient à un domaine qui possède des exigences ITAR, aucune tentative n’est entreprise vers les points de terminaison Office 365 connus. Dans les prochaines publication, l’étape 11 pourra passer à la même logique que l’étape 4 et appeler le Office 365 de groupe. Lorsque cette modification est faite, cet article est mis à jour pour refléter la nouvelle étape du processus.

Redirect handling Step 9 in the Autodiscover Process section is an explicit step to handle nonsecure redirect data. Dans les autres étapes de sécurité, 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 rediriger vers une nouvelle URL différente pour essayer de récupérer la charge utile. En outre, 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 une « redirection des réponses » :

Code d’état HTTP (301, 302) avec une nouvelle URL
Code d’état HTTP de 200 mais avec un code XML de charge utile Outlook à rediriger vers une autre URL
Code d’état HTTP de 200 mais avec un code XML de charge utile Outlook à utiliser une autre adresse smtp comme adresse cible.

Dans les cas 1 et 2, un Outlook tente de récupérer le XML de découverte automatique à partir de la nouvelle URL, à condition que le protocole soit https. Les URL nonecure (http) ne sont pas tentées. De plus, même si le protocole de la nouvelle URL est https, Outlook vérifiera les informations sur le certificat afin de fournir une mesure supplémentaire de sécurité.

Dans le cas 3, Outlook tout le processus de découverte automatique à partir du début. Si toutes les étapes (1-11) sont essayées sans succès à l’aide de la nouvelle adresse de courrier, Outlook retourne à l’adresse de courrier 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 relatives à la manière Outlook de tenter d’obtenir la charge utile de découverte automatique. Plusieurs optimisations et tentatives exceptionnelles peuvent légèrement modifier le processus. Par exemple, lors de la création d’un compte, Outlook ignore en interne l’étape 3 (recherche des données de lKG), car il ne peut pas encore avoir de dernière entrée connue bonne. De même, si une tentative a été déclenchée en raison d’une erreur lors de l’utilisation des informations de configuration actuelles, Outlook souhaite à nouveau la découverte automatique et ne pas utiliser les informations LKG, car les dernières informations pertinentes connues ont provoqué un échec.

Contrôle de stratégie Les valeurs de stratégie définies dans la section Processus de découverte automatique peuvent être soit des valeurs de Registre basées sur une stratégie, soit des valeurs non basées sur des stratégies. Lorsqu’elles sont déployées via un groupe de stratégies de groupe ou une configuration manuelle de la clé de stratégie, les paramètres sont prioritaire sur la clé non-stratégie.

Clé non-stratégie : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

Clé de 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 par un paramètre de 1 Outlook activer cette étape du processus. Pour les valeurs restantes, un paramètre de 1 indique à Outlook de désactiver ou d’ignorer l’étape associée. Par exemple, la définition de la valeur ExcludeHttpsRootDomain sur 1 définit Outlook ne pas effectuer l’étape 6 du 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 Office 365 de groupe

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 les utilisateurs à appeler Outlook service de Office 365 de sécurité pour récupérer les URL de découverte automatique appropriées.

Paramètres d’heure d’heure d’été HTTP

Clé : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Valeur : Délai d’terme
Par défaut : 25 secondes
Minimum : 10 secondes
Maximum : 120 secondes

Informations : les date d’arrêt spécifiées sont utilisées en tant que paramètres WinHttpSetTimeouts. Les données spécifiées sont transmises aux quatre paramètres de l’API WinHttpSetTimeouts. Cela peut permettre d’obtenir une demande HTTP qui ne peut pas être atteinte plus rapidement, ce qui améliore les performances globales. Les paramètres peuvent également permettre au succès d’une demande HTTP qui prend plus de temps que la valeur par défaut de 25 secondes d’augmenter le paramètre de délai d’terme à une valeur supérieure à 25 secondes.
Mapi/Http Protocol Control

Clé : HKEY_CURRENT_USER\Software\Microsoft\Exchange
Valeur : MapiHttpDisabled
Par défaut : 0
Données : 1 = Protocole désactivé ; 0 = Protocole activé

Informations : Cette valeur n’est pas située sous la clé de découverte automatique. Il s’agit d’un paramètre général qui contrôle si les Outlook peuvent essayer de se connecter à Exchange à l’aide de la pile du protocole Mapi/Http. La valeur par défaut Outlook 2016 ne doit 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 de sorte que les paramètres du protocole Mapi/Http soient évalués et traitées.
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 = En-têtes sont ajoutés ; 0 = Les en-têtes ne sont pas ajoutés

Informations : Notez que cette valeur n’est pas sous la clé de découverte automatique. Ce paramètre contrôle si un en-tête de négociation d’authentification est ajouté aux demandes http. Le contenu de l’en-tête dépend des capacités d’authentification de l’ordinateur client. Par exemple, l’en-tête peut être : « Capacité X-Nego : Négociation, pku2u, Kerberos, NTLM, MSOIDSSP ». Cette valeur de Registre et l’en-tête qu’elle ajoute sont rarement utilisés dans une pile d’authentifications modernes et très peu probables d’affecter le processus de découverte 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 des avertissements/erreurs de certificat ; 0 = Ne pas afficher d’avertissements de certificat

Informations : cette valeur contrôle la façon dont Outlook gère les erreurs et avertissements reçus lors de l’enregistrement de tâches http. Outlook peut remplacer ce paramètre dans certains cas (étape 6 de la section Processus de découverte automatique), mais dans le cas général, si ce paramètre est activé, Outlook affiche une boîte de dialogue de sécurité qui affiche l’erreur ou l’avertissement du certificat et autorise l’utilisateur à OK ou annuler la demande Http. L’utilisateur peut décider d’ignorer trois erreurs de certificat spécifiques et de Outlook réessayer de la demande http :

WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID : problème avec la date dans les propriétés du certificat
WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID : un problème se pose avec le nom commun dans les propriétés du certificat
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA : problèmes avec l’autorité de certification dans les propriétés du certificat

Pour plus d’informations sur ces trois états d’erreur de certificat, voir WINHTTP_STATUS_CALLBACK fonction de rappel

Gestion de l’authentification du proxy

Clé : HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
Valeur : AllowOutlookHttpProxyAuthentication
Par défaut : 0
Données : 1 = Autoriser les Outlook à gérer les défis d’authentification des serveurs proxy ; 0 = échec silencieux des défis d’authentification à partir de serveurs proxy

Informations : cette valeur de Registre permet la configuration d’une sécurité et est couverte 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 : 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 Exchange ActiveSync comptes EAS. Le processus de découverte automatique et la prise de décisions d’EAS sont distincts des étapes décrites dans cet article. Par exemple, l’implémentation EAS n’implémente pas la logique du point de terminaison O365 et n’a pas d’étape qui vérifie les emplacements SCP. Cet article décrit les étapes détaillées que Outlook utilise pour les tentatives de découverte automatique afin d’obtenir les protocoles MAPI de Exchange.

Références

Vous pouvez trouver des informations héritées sur la découverte automatique dans l’article suivant de la Base de connaissances Microsoft :

2212902 Comportement inattendu de la découverte automatique lorsque vous avez des paramètres de Registre sous la clé \Autodiscover

Pour plus d’informations sur la découverte automatique, consultez les articles Microsoft suivants :

Découverte automatique pour Exchange

Service de découverte automatique