Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Without Identity, there is no migration project

Posted by Teruin laurent sur décembre 10, 2018

When merging or acquiring companies, the question of information systems integration arises. In most cases, several scenarios are possible. The most logical but sometimes the most complicated is the merger, the second, generally faster integration, consists in interconnecting this information system via mutual approvals between the different environments. In both cases, it will be necessary, at some point, to establish a cohabitation, a coexistence of systems that will quickly allow users of acquired subsidiaries to access the group’s business applications.

Generally, this coexistence is not an objective in itself, but rather a transitional step that allows sales forces and business managers to integrate the group’s applications directly. This coexistence will then have to give way to a real merger, which may eventually include the removal of the new subsidiary’s information system. The objective in this case is to obtain, through a single directory, homogeneous services for the group (messaging, intranet, collaborative portals, telephony, etc.). In addition to Data Migration, the question of identities will then arise. Without Identity, there is no migration project.

In the Microsoft environment, the company’s technical directory is represented by the Active Directory. When acquiring new companies, the question arises of integrating all its users, their workstations, their servers but sometimes their Office 365 environment into the group’s infrastructures. The first project to be addressed is undoubtedly identity. How many user accounts are to be taken over? How are subcontractor accounts managed, what is the identity management policy in the new subsidiary?

Without the definition of the merger or identity integration project, other services will not be able to migrate. This is the first project that will have to be addressed. This is precisely what we propose you to study

Possible scenarios

There are actually 2 main scenarios that can be considered when a company acquisition occurs.

Integration: The first scenario, known as integration, assumes that the environment of this new society will continue. In this case, the directory identities will have to be kept and synchronized to Azure AD if the group has an Office 365 environment. The establishment of approval relationships between its two environments will make it possible to easily share resources, via mono or bidirectional authentication processes. This scenario can of course be repeated, allowing new acquisitions to quickly integrate the group’s resources. This is sometimes the case when the acquired company retains its own identity or brands. In this case, integration is simple, users keep their own identity, their email address, their instant messaging ID etc… etc… etc…

From an architectural point of view, the two forests coexist on both sides with domain controller servers deployed in each respective agency. It should be noted in passing that this mode of operation may, however, raise some mobility concerns when a group user tries to connect from a subsidiary’s network.

In our case, directory synchronization processes such as Azure Ad Connect to Office 365 support these scenarios, and are perfectly adapted to these situations.

Despite this, and despite this relative simplicity, adaptations are often desirable and undertaken, such as the homogenization of email addresses, the standardization of resource naming as meeting rooms, distribution lists, security groups can be. The objective is then to offer users a single and homogeneous directory in which they can find their way and address resources between the various entities.

This integration can also be improved if both companies have messaging systems based on the same technologies such as Microsoft Exchange. In this case, so-called « rich » interactions are possible, such as being able to search the busy free slots of employees located in another subsidiary. More simply, if the group has chosen Microsoft Exchange Online messaging, with the subsidiary’s identities synchronized, it will then be quite simple to migrate the subsidiary’s messaging data to this new environment.

In this scenario, the group’s Identity and Access Management (IAM) processes will also be updated. They will have to take this new environment into account a posteriori, and be able to address it when new identities have to be created or deleted. This generally involves bringing this new directory up to group standards, by « populating » in particular unique identifiers (Personnel numbers, Identifier) on objects such as user accounts, subcontractor accounts, etc… Here again, the objective is not to eliminate the subsidiary’s directory but to integrate it into the group’s identity management processes.

Merger: The second scenario, which we will call a merger, consists in considering that the directory of the acquired subsidiary has the objective of disappearing. Only user data will be included, and the identities specific to the subsidiary environment will therefore have to be ignored in the synchronization processes. In most cases, all users as well as their workstations and server resources (to name a few) will have to migrate to the group’s Active Directory environment.

This scenario is obviously more complex and longer, but the integration in the long term will be more successful. Everyone will be integrated into the Group’s one and only Active Directory forest.In this case, the question is how to achieve this identity fusion, while integrating the migration of the related data. Again, without an identity, there is no migration project. How can you integrate the data of a new company into the Office 365 & Active Directory environment of a group, without synchronizing your directory data, knowing that data and access are closely linked?

The first thing to do is to create these same identities in the destination environment (Group environment) and synchronize them if necessary, in the Office 365 environment. A common key will have to be established between the two directory environments to ensure that a one-to-one relationship for user accounts in particular can be established. Users will have two accounts, one in their original forest, one in the group’s forest.

In most cases, the creation of these new identities is based on the group’s current standards, so it is not uncommon for the login names to be different for the subsidiary. If the group uses Office 365, the user’s login name (UPN) will generally be identical to their main email address ( for example), which will force the subsidiary in the event of two-way approval relationships to no longer use it for the benefit of the group directory. (Deletion of the UPN in the source forest in case of a bidirectional approval relationship).

For reasons of access to the agencies’ resources, the creation of these user accounts will also have to take into account their old identity and more particularly what is known as the Sid History. This Sid History will allow users who need to use their identity within the group to continue to have access to their old resources such as file services.

As the agency directory must disappear, and therefore must not be synchronized around 0365, it will also be necessary to recreate all the inherited security and distribution groups to the group directory, taking care here too to keep their Sid History (Security Group only). Most companies often use this opportunity to rename them so that they follow the current nomenclature (this is called directory data transposition rather than duplication). As the fusion scenario is a process that will last, until all workstations integrate the new forest, this transposition will have to be maintained to allow resources to move to these new identities.

Once this transposition is implemented and maintained, the displacement of resources can take place. The latter will have to rely on and take into account this identity transposition to modify the inherited authorizations and replace them with the group’s identities. This is what migration tools generally do by integrating as Sharegate an identity mapping table as part of the migration of Sharepoint resources whether they are hosted on site or on 0365. (Migration Tenant à Tenant)

Once migrated, users connected with their accounts in the group’s forest will find their accesses on their Sharepoint sites.

For mailbox & public folder migration, if the subsidiary uses the Exchange environment, the migration is more complex and would deserve a thorough publication. However, by duplicating the email attributes of users in the Source environment to the destination forest, you should be aware that it is possible to move mailboxes from the subsidiary to the group environment by attaching these mailboxes to group identities. This mailbox movement having as a particularity the preservation of the Mailbox Guid attribute, it will allow the automatic update of your users’ Outlook profile, avoiding you an intervention on each workstation.

Identity, as we have tried to demonstrate to you, often underestimated, therefore plays a decisive role in integration projects and, depending on the level of complexity, can call into question your migration strategy. Analyzing how these mergers, adaptations and the consequences of their modifications on the application environment will be carried out is essential to build a realistic project plan. This should be one of the first steps to be taken into account. Without an identity, there is no migration.


Laurent TERUIN


Posted in Non classé | Leave a Comment »

IGNITE 2018 : Contenu des principales sessions

Posted by Teruin laurent sur octobre 26, 2018


Vous trouverez ci joint le contenu des principales sessions classé par theme. Il y a « un peu » de lecture pour vos longues soirées d’automne!AlKfEdbwpIS_heIEZiJydl2j0LZ6GA


PS : Si vous voulez récupérer l’intégralité de toutes les sessions je vous conseille d’utiliser ce script



Posted in Non classé | Leave a Comment »

Microsoft Exchange : Controller l’accès aux dossiers publics

Posted by Teruin laurent sur octobre 22, 2018

Jusqu’à présent, les administrateurs n’avaient aucun contrôle sur les utilisateurs qui pouvaient parcourir les dossiers publics depuis leurs clients Outlook. Si des dossiers publics ont été créés au sein de l’organisation ou si une organisation Exchange Online est configurée pour accéder à des dossiers publics sur site, tous les clients se connecte et afficher l’objet « Dossiers publics » dans Outlook. De là, les administrateurs pouvaient contrôler l’accès aux dossiers publics individuels (contrôlé par les permissions des dossiers). Cependant, il était très difficile de restreindre l’accès aux dossiers publics.

Microsoft introduit désormais la possibilité de contrôler l’affichage l’objet du dossier public dans Outlook à un seul ensemble d’utilisateurs qui pourraient en avoir besoin.

Pour ce faire, les administrateurs peuvent utiliser deux paramètres :

  • PublicFolderClientAccess est un paramètre facultatif sur l’objet utilisateur. Par défaut, sa valeur est fixée à ‘false’. Si vous définissez ce paramètre sur  » true  » pour un utilisateur spécifique, cet utilisateur sera désigné comme l’un des utilisateurs qui verront les dossiers publics dans Outlook.
  • PublicFolderShowClientControl dans la configuration de l’organisation. Par défaut, la valeur de ce paramètre est également ‘false’ et une fois qu’il est réglé sur’true’, l’accès contrôlé des dossiers publics est activé.

Voici un exemple d’utilisation de ces paramètres ; pour n’autoriser l’accès qu’à l’utilisateur « Administrateur » et activer la fonction pour l’organisation :

set-CASMailbox « Administrator » -PublicFolderClientAccess $true
Set-OrganizationConfig -PublicFolderShowClientControl $true

Remarque importante : régler le paramètre d’organisation sur true sans régler les attributs utilisateur sur true en premier fera en sorte qu’aucun utilisateur ne verra l’objet du dossier public dans Outlook pour Windows. En d’autres termes, si vous voulez implémenter ceci, nous vous suggérons de planifier à l’avance et de remplir d’abord les attributs utilisateur (PublicFolderClientAccess sur les utilisateurs qui ont besoin d’accès défini sur true) puis de définir le paramètre du niveau organisation (PublicFolderShowClientControl défini sur true). De cette façon, les utilisateurs qui ont besoin d’avoir accès ne perdront pas l’accès de façon inattendue.

Les administrateurs du Tenant disposeront désormais d’une plus grande flexibilité quant aux utilisateurs qui se connectent aux dossiers publics dans Outlook. Cela profitera aux très grandes organisations qui pourraient avoir des problèmes avec les limites de connexion aux dossiers publics et réduira la charge de cette infrastructure.



Posted in Non classé | Leave a Comment »

Exchange Online : Empêcher l’authentification Basique

Posted by Teruin laurent sur octobre 15, 2018

Les équipes de Microsoft vont introduire sur Exchange Online une nouvelle fonctionnalité qui sera le fait de pouvoir disposer d’une Politique d’authentification. Les stratégies d’authentification fourniront à l’administrateur la capacité de définir des protocoles qui devraient permettre, ou pas, l’authentification de base. Les politiques pourront être créées et définies par défaut pour le Tenant, ou définies par utilisateur, Les paramètres par utilisateur remplaçant les paramètres par défaut du Tenant. Lorsqu’une connexion à Exchange Online via l’authentification de base est établie, les conditions de la police sont vérifiées et appliquées. Si la tentative de connexion a utilisé l’authentification de base et que la stratégie est configurée pour empêcher la connexion de base, la connexion sera bloquée à ce point.

Pour rappel l’authentification basiques est utilisée par tout les clients non microsoft comme les clients de messagerie présent par defaut dans les clients Android. Cette Authentication de base transmet le mot de passe en clair dans un Tunnel crypté HTTPS.

Laurent TERUIN



Posted in Non classé | Leave a Comment »

0365: When one feature chases another / Team Guest Access VS MailUser

Posted by Teruin laurent sur octobre 11, 2018


Some time ago we had identified that if people (Mail user) or user account with the email address entered in the email field of your Active Directory were present in your tenant’s Azure Active Directory environment, then these people could not be invited as guests in Teams. A priori I would say that this is confirmed. The MAIL user functionality in Office 365 can no longer be used if you want these people to have the opportunity to be invited into team. Because if the user can be resolved then the user will be considered as internal. If you are in hybrid mode here is the action plan I propose

The situation

  • All User accounts with mail extension (Mail User) are synchronized as such in 0365
    • This synchronization makes them appear in the address book of Exchange Online and Exchange On Prem. Teams cannot see them as an external person because they are considered internal.
  • All user accounts with the email address (in the email field) entered are synchronized as such in 0365
    • This synchronization does not show them in Exchange Online or Exchange on Premise. Teams cannot see them as an external person because they are considered internal.

Recommended solution for users with Mail User Extension

– Inventories of their membership in Exchange distribution lists

– Convert all users with Mail Extension as a Single Active Directory user

– Creation of an email contact with their email address in the 0365 or Onprem environment with synchronization to Azure AD

– Repositioning in distribution lists

Recommended solution for users whose email address is entered in the Active Directory email field

– Stop the synchronization of this type of accounts in the 0365 environments


Posted in Non classé | Leave a Comment »

0365 : Quand une fonctionnalité en chasse une autre / Team Accès invité VS MailUser

Posted by Teruin laurent sur octobre 11, 2018

English version here


Il y a quelque temps nous avions identifié que si des personnes (Mail user) ou compte utilisateur avec l’adresse email renseignée dans le champs mail de votre Active Directory étaient présent dans l’environnement Azure Active Directory de votre tenant, alors ces personnes ne pouvaient être invité en tant qu’invité dans Teams. A priori je dirais que cela est confirmé. La fonctionnalité MAIL user dans Office 365 ne peut plus être utilisée si vous désirez que ces personnes aient la possibilité d’être invité dans team. Car si l’utilisateur peut etre résolu alors ce dernier sera considéré comme interne. Si vous êtes en mode hybride voici le plan d’action que je propose

La situation

  • Tous les comptes Utilisateurs avec extension de messagerie (Mail User) sont synchronisés en tant que tel dans 0365
    • Cette synchronisation les fait apparaitre dans le carnet d’adresse de Exchange Online et Exchange On Prem. Teams ne peut pas les voir en tant que personne externe car considéré comme Internes
  • Tous les comptes utilisateurs avec l’adresse de messagerie (dans le champ mail) renseignée sont synchronisés en tant que tel dans 0365
    • Cette synchronisation ne les fait apparaitre ni dans Exchange Online ni dans Exchange on Premise. Teams ne peut pas les voir en tant que personne externe, car considéré comme Internes


Solution recommandée pour les utilisateurs avec Extension de messagerie (Mail User)

  • Inventaires de leurs appartenances aux listes de distribution Exchange
  • Conversion de tous les utilisateurs avec Extension de messagerie en tant que Simple utilisateur Active Directory
  • Création d’un contact de messagerie avec leur adresse email dans l’environnement 0365 ou Onprem avec synchronisation vers Azure AD
  • Repositionnement dans les listes de distribution

Solution recommandée pour les utilisateurs dont l’adresse de messagerie est renseignée dans le champs mail Active Directory

  • Arrêt de la synchronisation de ses comptes dans l’environnement 0365



Posted in Non classé | Leave a Comment »

Activation de l’accès invité Team / changement

Posted by Teruin laurent sur octobre 11, 2018


Pour information les procédures d’activation de l’accès invités dans team tel que documenté par Microsoft ici

ne sont plus valable.

L’activation se fait directement dans l’espace dédié à Team et à Skype :

Après avoir activé cette fonctionnalité nous avons remarqué qu’il n’était pas possible d’inviter quelqu’un car team ne reconnaissais pas cette personne comme externe, alors que celle-ci possédait bien un compte sur un autre Tenant 0365

Nous avons ouvert un incident. Le support Microsoft nous a fait exécuter le script suivant.

Install-Module AzureADPreview -Verbose -AllowClobber -Scope CurrentUser
$template = Get-AzureADDirectorySettingTemplate | ? {$_.displayname -eq « group.unified »}
$settingsCopy = $template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $settingsCopy
$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value « Group.Unified » -EQ).id
$settingsCopy = Get-AzureADDirectorySetting –Id $settingsObjectID
$settingsCopy[« AllowGuestsToAccessGroups »] = « true »
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy
(Get-AzureADDirectorySetting –Id $settingsObjectID).Values
$template = Get-AzureADDirectorySettingTemplate | ? {$_.displayname -eq « group.unified »}
$settingsCopy = $template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $settingsCopy
$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value « Group.Unified » -EQ).id
$settingsCopy = Get-AzureADDirectorySetting –Id $settingsObjectID
$settingsCopy[« AllowToAddGuests »] = « true »
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy
(Get-AzureADDirectorySetting –Id $settingsObjectID).Values
Read-Host -Prompt « Press Enter to Quit »

Mais cela n’a pas suffi à résoudre le problème immédiatement. Le processus d’activation des accès invités peut prendre un peu de temps selon le support. Donc soyons patient : 11 Octobre 2018 11 :15 Après 12 heures nous refaisons le test et la …. Magie


Posted in Non classé | Leave a Comment »

Autodiscover Outlook 0365 / Partie 1

Posted by Teruin laurent sur octobre 6, 2018

Dans l’environnement Office 365, les problèmes de connexion voire d’authentification peuvent être nombreux et peuvent être issu de différentes causes. Dans cet article nous allons expliquer comment procéder pour déterminer la causalité de ces problèmes de connexion.

Nous attacherons spécifiquement au client Outlook 2016 dans un environnement Windows 7 ou Windows 10. L’objectif de ce document est donc de vous proposer une méthodologie d’investigation qui devrait vous permettre de comprendre et de résoudre ses problèmes récurrents.

Les problèmes d’authentification de connexion dans un environnement Office 365 peuvent avoir effectivement plusieurs causes. Ces causes sont souvent directement liées à l’environnement de production mais également à l’environnement de connexion.

En effet le client Outlook réagit, s’adapte en fonction de l’environnement qu’il soit uniquement basé sur Office 365, ou basé sur un environnement hybride, comportant des serveurs Microsoft Exchange sur site, et une partie des boîtes aux lettres sur Exchange Online.

Selon votre environnement, et selon l’emplacement des ressources auxquelles Outlook va tenter d’accéder le diagnostic sera plus complexe à établir. En effet dans les environnements hybrides il n’est pas rare de constater qu’une partie des ressources de type boîte aux lettres soit répartie entre les deux environnements Exchange Online et Exchange sur site. Dans ce cas, le client Outlook devra vraisemblablement se connecter sur ses deux environnements et il est possible que vous constatiez des fenêtres d’authentification liée spécifiquement à un environnement bien déterminé. L’objectif de ce document est donc de vous familiariser avec ces processus de connexion pour vous puissiez déterminer quelle en est la cause.

Cas 1 : toutes les ressources de messagerie sont hébergées sur Exchange Online

Pour commencer nous allons partir d’un cas très simple qui consiste à considérer que toutes les boîtes aux lettres ainsi que toutes les autres sources de messagerie, sont hébergées dans l’environnement Exchange Online.

Dans ce cas précis environnement hybride n’existe pas. Si vous rencontrez des problèmes de connexion à ce stade, la première chose à faire, et de vérifier via un client Web si vous pouvez avoir accès à la boîte aux lettres. Cette première étape qui permettra de savoir si la boîte aux lettres est correctement paramétrée et si celle-ci est fonctionnelle. Dans la plupart des cas la connexion va s’effectuer via une interface Web et une authentification dite moderne. C’est authentification va générer un jeton d’accès qui sera réutilisé si celui-ci n’est pas effacé, lors des connexions suivantes, évitant à l’utilisateur de ressaisir ces informations connexion.

Si vous avez pu avoir accès à la boîte aux lettres de l’utilisateur c’est que celle-ci fonctionne correctement. Reste alors à savoir pourquoi le client Outlook ne se connecte pas.

La plupart du temps, les problèmes de connexion d’un client Outlook vers Exchange Online, proviennent de deux facteurs que sont la résolution DNS et les services de proxy. Ainsi la première chose à faire, et de vérifier depuis le poste de travail en question si la résolution DNS vers les services Office 365 est correcte et si les services proxy ne vous empêchent pas de vous connecter à l’environnement Exchange Online.

Pour ce qui est du DNS voici quelques vérifications que vous devez effectuer. En utilisant une fenêtre de commande depuis la station de travail, effectuez les commandes suivantes et vérifier que la résolution DNS fonctionne en plus du Ping.

Si la résolution de ces deux noms ne fonctionne pas alors il s’agit d’un problème DNS. Si cette résolution fonctionne, nous allons vérifier que la connexion via le protocole https peut s’effectuer. Pour cela nous allons utiliser le programme client Telnet qu’il vous faudra peut-être installer sur la machine Windows. En utilisant les deux commandes suivantes, vous allez tenter depuis le poste en question une connexion sur le port 443 utilisée par le protocole https vers les points de connexion Exchange Online.

Si la connexion s’établit l’écran sur sa fiche avec un curseur qui clignote.

Dans le cas contraire l’interface de commande vous renvoi un message d’erreur.

Si vous ne parvenez pas à établir ses connexions cela signifie que le port 443 n’est pas ouvert vers l’environnement Office 365 ou que votre serveur proxy vous empêche d’établir ces connexions. Pour vérifier la connexion via votre serveur proxy si votre station de travail en utilise un, utilisez cette technique.

Depuis votre explorateur essayer de joindre cette URL

Vous devriez être inviter à entrer vos informations de connexion.

Dans le cas contraire soit le port 443 est fermé soit votre serveur proxy ne vous autorise pas accéder à cette ressource. En entrant vos informations de connexion vous devriez obtenir le résultat suivant


Cela peut provenir soit de votre système de protection installée sur votre poste de travail, soit de votre pare-feu qui protège votre réseau local d’Internet.

Dans ce cas il faudra prendre contact avec les services de votre entreprise pour vérifier faire ouvrir ses ports de connexion à destination des services Exchange Online.

Pour comprendre comment s’établi la découverte automatique d’un client Outlook vous devez assimiler les différentes étapes que ce dernier parcours dans sa quête de boite aux lettres. Elles sont au nombre de 11 et sont détaillées ci-dessous :

Etape d’autodécouverte suivie par le client Outlook 2016

Étape 1 : Vérification des scénarios de redémarrage

Dans certains cas, par exemple lorsque vous ajoutez un deuxième compte pendant l’exécution d’Outlook, l’information Autodiscover est mise en cache dans un fichier local pour être utilisée lors du redémarrage du client Outlook. La toute première étape d’Autodiscover est de vérifier dans le registre les informations spéciales de « boot » qui indiquent à Outlook que vous êtes au milieu d’un de ces scénarios de redémarrage et de lire l’information d’Autodiscover dans le fichier local spécial.

Étape 2 : Vérification de la préférence pour les données locales

Outlook fournit une GPO permettant aux administrateurs de déployer un fichier XML Autodiscover spécifique à utiliser pour la configuration. Si l’administrateur a déployé cette clef de registre et créé un fichier autodiscover.xml, Outlook lit l’information Autodiscover de ce fichier. Encore une fois, il s’agit d’un cas rare qui n’est généralement pas la cause des problèmes génériques d’Autodiscover.

Étape 3 : Vérification des données du dernier bien connu (LKG)

Lorsque l’autodiscover récupère avec succès une information XML à n’importe quelle étape, l’information peut être mise en cache localement en tant que configuration « last known good ». Le chemin du dernier bon fichier XML connu provient du profil Outlook.
L’étape LKG sert uniquement à découvrir la configuration de la boîte aux lettres principale. Si la recherche d’Autodiscover concerne une boîte aux lettres non primaire (boîte aux lettres alternative, déléguée, dossier public, boîte aux lettres de groupe, et ainsi de suite), l’étape LKG est alors automatiquement ignorée.

Étape 4 : Vérifier si O365 est prioritaire

Outlook utilise une méthode heuristique pour déterminer si le compte utilisateur fourni provient d’Office 365. Si Outlook détermine que vous êtes un utilisateur O365, il essaie de récupérer l’information Autodiscover à partir des points de connexion O365 connus (généralement ou La clef de registre servant à contrôler ce comportement est : ExclureExplicitO365Endpoint.

Étape 5 : Vérification des données SCP

Si l’ordinateur est relié à un 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 du fichier XML Autodiscover. Chaque URL renvoyée par la recherche SCP est ensuite essayée pour tenter de récupérer l’information Autodiscover. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 6.

Etape 6 : Vérifier le domaine racine

Pour cette étape, Outlook construit une URL à partir du nom de domaine de l’adresse initiale dans le format https://<domain>/autodiscover/autodiscover.xml et essaie de récupérer l’information de l’URL résultante. Comme de nombreux domaines racine ne sont pas configurés pour Autodiscover, Outlook réduit volontairement au silence les erreurs de certificat qui se produisent pendant la tentative de récupération. Si cette étape ne permet pas de récupérer une information Auodiscover, Outlook passe à l’étape 7.

Etape 7 : Vérifier le domaine Autodiscover

Pour cette étape, Outlook construit une URL à partir du nom de domaine de l’adresse initiale dans le format https://autodiscover.<domain>/autodiscover/autodiscover.xml et essaie de récupérer l’information de l’URL résultante. Comme il s’agit de l’URL principale généralement utilisée pour les données Autodiscover, 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, dont la valeur de contrôle est la suivante : ExclureHttpsAutoDiscoverDomain.

Étape 8 : Vérification des données locales

Dans l’étape 2, Outlook a vérifié si l’administrateur avait déployé une stratégie pour vérifier spécifiquement l’information Autodiscover en tant que préférence. S’il n’y a pas de politique en place, mais que les étapes précédentes n’ont pas permis de récupérer une information, Outlook tente de récupérer une information à partir du fichier local, même sans le paramètre PreferLocalXML en place. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 9.

Etape 9 : Vérifier les redirections Http

Pour cette étape, Outlook envoie une requête à l’URL du domaine Autodiscover (http://autodiscover.<domain>/autodiscover/autodiscover.xml) et teste les réponses de redirection. Si une information XML Autodiscover réelle est retournée et non une redirection, Outlook ignore la réponse XML Autodiscover 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 une information XML depuis la nouvelle URL. Outlook effectuera également des vérifications de certificats pour empêcher la redirection vers des URL potentiellement nuisibles lors de cette étape. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 10. Vous pouvez contrôler ce comportement via la clef de registre : ExclureHttpRedirect.

Étape 10 : Vérifier les données sur les SRV

Pour cette étape, Outlook fait une requête DNS en « _autodiscover._tcp.<domain name> » et parcourt les résultats à la recherche du premier enregistrement qui utilise https comme protocole. Outlook essaie alors de récupérer l’information à partir de cette URL. Si cette étape ne permet pas de récupérer une information, Outlook passe à l’étape 11. Vous pouvez contrôler ce comportement via la clef de registre : ExclureSrvRecord

Étape 11 : Vérification de l’O365 en tant que Sécurité-Défaut

Si toutes les étapes précédentes n’ont pas retourné une information d’autodécouverte, Outlook utilise une méthode heuristique moins restrictive pour décider si une dernière tentative aux points de connexion O365 est potentiellement utile. Si Outlook décide qu’une tentative en vaut la peine, il essaie les points de connexion Autodiscover connus au cas où 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 utilisée en dernier recours et non plus tôt dans le processus Autodiscover. Vous pouvez contrôler ce comportement via la clef de registre : ExclureExplicitO365Endpoint.

L’emplacement des clef de registre peuvent étre trouvée ici HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover et pour rappel sont les suivante

  • PreferLocalXML
  • ExclureHttpRedirect
  • ExclureHttpsAutoDiscoverDomain (DécouverteDomaine)
  • ExclureHttpsRootDomain
  • ExclureScpLookup
  • ExclureSrvRecord
  • ExclureLastKnownGoodURL (s’applique uniquement à Outlook 2010 version 14.0.7140.5001 et versions ultérieures)
  • ExclureExplicitO365Endpoint (s’applique uniquement à Outlook 2016 version 16.0.6741.2017 et versions ultérieures)

Comment connaitre la méthode que votre Outlook Utilise pour retrouver l’information Autodiscover ?

Vous pouvez utiliser les étapes suivantes dans Outlook pour déterminer la méthode par laquelle Outlook essaie de récupérer les informations d’Autodiscover dans Exchange :

Lancez Outlook.

  • Appuyez sur la touche CTRL, cliquez avec le bouton droit de la souris sur l’icône Outlook dans la zone de notification, puis cliquez sur Test E-mail AutoConfiguration.
  • Vérifiez que l’adresse e-mail est correctement saisie dans la zone Adresse e-mail.
  • Entrez votre mot de passe si vous n’êtes pas connecté à un domaine ou si vous accédez à une boîte aux lettres différente de la vôtre.
  • Cliquez sur pour décocher les cases Utiliser Guessmart et Authentification Guessmart sécurisée.
  • Cliquez sur Tester.
  • Passez en revue les détails dans l’onglet Journal.

Dans la seconde partie nous étudierons le comportement d’autodécouverte en environnement Hybride

Laurent TERUIN








Posted in Non classé | Leave a Comment »

BitTitan: Failed to validate endpoint Autodiscover (403 Forbiden)

Posted by Teruin laurent sur septembre 20, 2018

When creating a connection point through the Bititan interface you may have noticed that communication between BT services and your Exchange 2010 could not be established.

The error message is as follows:

Failed to validate endpoint Autodiscover cloudMenow of type ExchangeServer.
Exchange Error: (403) Forbidden{« $type »: »System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.String, mscorlib]], mscorlib », »errorCode »: »EndpointValidationFailure », »Message »: »Failed to validate endpoint Autodiscover cloudMenow of type ExchangeServer.\nExchange Error: (403) Forbidden »}

IF you test from the Microsoft remote connectivity you can observe this

Exception details:
Message: The request failed. The remote server returned an error: (403) Forbidden.
Type: Microsoft.Exchange.WebServices.Data.ServiceRequestException
Stack trace:
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)
at Microsoft.Exchange.WebServices.Data.ExchangeService.InternalBindToFolders(IEnumerable`1 folderIds, PropertySet propertySet, ServiceErrorHandling errorHandling)
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.Tools.ExRca.Tests.GetOrCreateSyncFolderTest.PerformTestReally()
Exception details:
Message: The remote server returned an error: (403) Forbidden.
Type: System.Net.WebException
Stack trace:
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)

Elapsed Time: 437 ms.


To fix that I try to configure EWS with these options

Set-OrganizationConfig -EwsApplicationAccessPolicy:$null (Not Sufficient)
set-casmailbox -Identity bittitan -EwsEnabled:$true (Not Sufficient)
get-casmailbox -Identity bittitan | set-casmailbox -EwsApplicationAccessPolicy:$null (Not Sufficient)
get-casmailbox -Identity bittitan | set-casmailbox -EwsBlockList:$none (Not Sufficient)
get-casmailbox -Identity bittitan | Set-CASMailbox -EwsAllowEntourage:$true (Not Sufficient)
get-casmailbox -Identity bittitan | Set-CASMailbox -EwsAllowMacOutlook:$true(Not Sufficient)

Set-OrganizationConfig -EwsEnabled:$true (Not Sufficient)
Set-OrganizationConfig -EwsBlockList:$none


Trying to open directly the URL from an Internal Machine.

And…. It is working internaly !

So let see what’s going on on my old TMG2010.

And surprise on the listener that use the publication rules (Sounds Not Good right? )

Let change that with

and the result is (With Remote Connectivity)

So now lets try to check with bittitan .








Posted in Non classé | Leave a Comment »

Impossible d’inviter une personne invitée dans l’environnement Team

Posted by Teruin laurent sur septembre 13, 2018

Si dans votre tenant vous avez ouvert l’environnement Team pour les accès invités, il est possible que celui-ci ne fonctionne pas dans le cas suivant : partage un Teams pour inviter qui se trouve être un compte 0365 sur un autre tenant. Ce dernier possédant une licence E1 ou E3 sur le tenant 0365 hébergeant

Lors du partage l’application team résout ce nom car john.adams possède un simple compte Active Directory avec dans le champ mail son adresse de messagerie externe. De plus ce compte est synchronisé depuis votre active directory vers 0365.

La solution pour résoudre ce problème passe par

  • Soit la non synchronisation de ce compte dans Office 365
  • La suppression de son adresse Email dans son compte Active Directory


Posted in Non classé | Leave a Comment »