Bref... ne nous égarons pas!!! Ce soir, nous allons expliquer un concept simple: le partage des informations de disponibilité, à savoir les fameuses "Free/Busy Information" entre deux organisations Exchange 2007/2010. Mais ce n'est pas la finalité, juste un moyen d'aller plus loin et de proposer mieux au travers d'une fonctionnalité "top secrète" et très peu documentée chez Microsoft... :) - cela fera l'objet de la seconde partie.
L'important étant de comprendre (et de ne pas rater) cette première partie :)
Partie 1: Le partage des informations de disponibilités
Chez Avanade, nos clients sont très majoritairement des "gros", voire des "très gros", voire des "très très gros". Il est courant chez nos clients de rencontrer des systèmes d'information multiples, gérés par des DSI différentes, une gouvernance historiquement séparée et qui fini par converger... ou pas! Dès lors se pose la question d'une coexistence plus ou moins riche et plus ou moins facile, ou d'une migration. Il est fréquent que pour des raisons de temps/priorités ou tout simplement pour des questions budgétaires ces questions traînent en longueur et ne passent généralement pas par la case "mise à niveau" (typiquement, faire une fédération entre Organisations Exchange 2010 est devenu "facile" mais quid d'une Org 2010 et une Org 2007, voire même de deux Orgs 2007).
Lorsque deux Organisations commencent à coexister, chacune synchronise les boîtes aux lettres de l'une en tant que contacts dans leur Active Directory. Plus précisément des "Mail-Enabled Contacts". Un classique.
Mais cela n'aide pas cette problématique:
A savoir que l'utilisateur de l'organisation A ne voit pas les disponibilités de son collègue de l'organisation B... En effet, "John Doe" (désolé pour le manque d'imagination :)) est un contact, comme l'image ci-dessous le montre:
Pour remédier à ce désagrément, nous avons besoin d'un environnement de ce type:- Deux forêts Active Directory et deux organisation Exchange 2007 SP1 ou ultérieure, ou Exchange 2010 SP1 ou ultérieure
- Des relations d'approbation, dans notre cas bidirectionnelles - ce n'est pas un pré-requis mais facilité la vie et dans le cas du partage des Free/Busy il sera possible d'utiliser un compte de service cependant risque de nous causer soucis lors de la 2nde partie (...)
- Les droits nécessaires: Enterprise Admin et Org Admin
Il est critique que les deux organisations soient configurées parfaitement, en particulier sur les points suivants:
- La configuration des Web Services eux-mêmes (authentification en particulier pour l'Autodiscover et les Exchange Web Services), IIS en général sur les CAS et bien sûr le Load-Balancer s'il y en a un dans la chaîne...
- La relation de confiance entre les deux environnements (typiquement, au delà de la relation d'approbation c'est faire confiance aux autorités de certification ayant émis les certificats)
1.1) L'environnement utilisé
Dans le cas du Lab utilisé ici, nous avons:
- Une organisation Exchange 2010 SP2, donc "moderne"; elle simule un environnement d'une DSI Groupe d'un de mes clients favoris et a donc vocation à être "la cible" - la forêt est "corp.uc-lab.org";
- Une organisation Exchange 2007 SP3, donc "récente"; elle simule une entité spécifique du Groupe en question - la forêt est "partner.local".
(Update: lire le commentaire plus loin sur l'apport du Rollup 6 à Exchange 2007 SP3)
1.2) Availability Address Space
La coexistence des Free/Busy a été introduite dans Exchange 2007 au travers d'une fonction spécifique de l'Availability Service (membre des Exchange Web Services) appellée "Availability Address Space".
Pour faire court, l'idée est de permettre à un serveur CAS d'une Organisation de savoir interroger les Free/Busy d'une autre organisation. Il est même possible de le faire avec une organisation Exchange 2003 au travers des Dossiers Publics. Nous allons nous intéresser à la version "100% Web Services".
1.2.1) Principe de base
Le principe de base est déclaratif: chaque Organisation va définir un ensemble de domaines SMTP pour lesquels l'Availability Web Service va pouvoir interroger les Web Services d'une autre Organisation. L'autre Organisation sera trouvée via l'adresse cible du contact (autrement dit, la "targetAddress").
- UserA est dans l'Organisation A
- UserB est dans l'Organisation B
- UserB est synchronisé en tant que contact dans l'AD/Organisation A et UserA dans AD/Org B
- UserA fait une demande de réunion à UserB
- Le CAS de l'Org A regarde s'il existe un Availability Address Space pour le domaine SMTP de UserB
- Si non, la reqûete échoue
- Si oui, le CAS de l'Org A effectue une requête d'Autodiscover afin de localiser un Service Connection Point dans l'Org B (attention: il va utiliser une External URL)
- Une fois le SCP trouvé il effectue une requête de disponibilité et elle aboutit ou échoue...
1.2.2) La configuration
Tout d'abord, nous allons configurer Exchange 2007 afin de répondre correctement à un serveur Exchange 2010, à savoir sur une durée de requête Free/Busy supérieure à la durée autorisée par défaut (42 jours). La valeur recommandée est de 62 jours (identique à E2010) et est positionnée par la variable maximumQueryIntervalDays du Web.config des EWS Exchange 2007 (dans $exinstall\ClientAccess\exchweb\ews) .
Une fois cette petite étape terminée, il est nécessaire d'effectuer un recyclage de l'Application Pool ou de faire un IISReset. Attendons, puisque de toute façon, nous en ferons un plus tard...
Il faut maintenant créer les Availability Address Spaces, c'est très simple.
Depuis Exchange 2010, en ajoutant deux domaines SMTP de l'Org B et en autorisant les serveurs Exchange 2007 de l'Org B à utiliser les Web Services de l'Org A:
- Add-AvailabilityAddressSpace -ForestName partner.com -AccessMethod PerUserFB -UseServiceAccount $true
- Add-AvailabilityAddressSpace -ForestName us.partner.com -AccessMethod PerUserFB -UseServiceAccount $true
- Get-ClientAccessServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-Exch-EPI-Token-Serialization" -User "FORETB\Exchange Servers"
- Add-AvailabilityAddressSpace -ForestName uc-lab.com -AccessMethod InternalProxy -ProxyUrl https://fermedecasdansOrgA.ext/EWS/Exchange.asmx -UseServiceAccount $true
- Get-ClientAccessServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-Exch-EPI-Token-Serialization" -User "FORETA\Exchange Servers"
Maintenant, il ne reste plus qu'à permettre à l'Organisation A de rechercher efficacement les domaines SMTP de l'Organisation B dans un contexte d'Autodiscover. Cela peut être fait simplement en publiant un Service Connection Point global dans la partition de Configuration de la Foret A.
Cela se fait de deux manières:
Méthode officieuse:
Rappel:
Et bonheur, lorsqu'une requête est effectuée au travers de l'Availabilty Web Service, le mécanisme suivant s’exécute:
Fin de la première partie.
La seconde partie va vous faire dresser les cheveux sur la tête puisque nous allons pousser le vice encore plus loin en permettant à deux utilisateurs de deux Forêts/Organisation différentes de faire du Cross-Forest Delegation. Oui, j'entends par là partager des boîtes aux lettres via permissions Mapi/Cdo/Outlook (donc granulaires) !!!
- La méthode officielle: utiliser la Cmdlet Export-AutoDiscoverConfig depuis l'Org B mais cela requiert d'être exécuté depuis l'Org B en spécifiant un compte Enterprise Admin de la Forêt A...
- La méthode officieuse: utiliser un script permettant de faire la même chose sans accès à l'Org B et en contrôlant ce que l'on veut supporter comme domaines SMTP en Autodiscover :)
Méthode officieuse:
Rappel:
- Nous avons crée les Availability Address Spaces de deux côtés
- Côté Org A (Exchange 2010 dans notre cas), nous avons crée un SCP de type LDAP permettant d'aller rechercher les informations d'Autodiscover dans la Forêt B (recherche d'un objet de type serviceConnectionPoint)
- De chaque côté, nous avons configuré l'accès aux Web Services afin d'autoriser les comptes machines des serveurs Exchange de chaque Organisation de pouvoir sérialiser des requêtes d'utilisateurs à destination des serveurs de l'autre Organisation.
1.3) Le résultat
Dès lors que vous avez un client Outlook 2007 (SP2 recommandé sur Outlook 2007 et SP1 recommandé sur Outlook 2010), vous avez donc la possibilité d'utiliser les Web Services.Et bonheur, lorsqu'une requête est effectuée au travers de l'Availabilty Web Service, le mécanisme suivant s’exécute:
- L'Availability Web Service détermine que l'utilisateur n'est pas une BàL dans l'Organisation
- Que c'est un contact avec une adresse externe (important, surtout dans le cas d'Exchange 2007)
- Qu'un Availability Address Space existe pour le domaine de messagerie de l'adresse externe
- Qu'un SCP global existe pour l'Autodiscover, et que pour le domaine de messagerie en question, c'est telle ou telle forêt qui doit répondre (exemple: pour "partner.com" dans mon lab, le point de service est en "LDAP://partner.local")
- Que l'URL d'Audiscover est https://qqchose.domain.ext/Autodiscover/Autodiscover.xml
- La requête à l'Autodiscover est envoyée puis consommée (doit se passer en moins de 10 secondes, sinon échec!), l'URL des EWS est déterminée
- La requête à l'Availability Web Service distant est envoyée puis consommée et l'information retournée au client...
Fin de la première partie.
La seconde partie va vous faire dresser les cheveux sur la tête puisque nous allons pousser le vice encore plus loin en permettant à deux utilisateurs de deux Forêts/Organisation différentes de faire du Cross-Forest Delegation. Oui, j'entends par là partager des boîtes aux lettres via permissions Mapi/Cdo/Outlook (donc granulaires) !!!
Bonjour,
RépondreSupprimers'il s'agit d'un exchange 2007 sp1 et d'un exchange 2010.
est ce que le tuto reste sensiblement le même ou ca change du tout au tout ?
Bien Cordialement
Maxime JOUAN
blog.virtuoze.fr
typiquement, la valeur maximumQueryIntervalDays n'existe pas sur mon transport HUB exchange 2007 sp1 :(
RépondreSupprimerBonjour Maxime,
RépondreSupprimerSur Exchange 2007, la valeur maximumQueryIntervalDays n'existe pas dans le Web.config (sur le rôle CAS, je précise, pas HTS :)). Lorsque cette valeur n'est pas présente, elle est à 42 jours par défaut, ce qui est en deçà du nombre de jours demandé par Ex2010 d'un seul tenant de Free/Busy. Il suffit d'ajouter la configuration à l'endroit approprié dans le Web.config.
Cela fonctionnera de ce point de vue mais il faut savoir qu'Exchange 2007 SP1 (outre le fait qu'il ne soit plus supporté :)) n'est pas capable d'utiliser la mathode InternalProxy pour l'Availability Address Space. Par conséquent la seule option qui reste est d'utiliser l'ancienne méthode de l'Autodiscover, qui n'est pas une synécure car il va s'entêter à utiliser l'External Url définie sur les Web Services Ex2010. Cela peut être particulièrement embêtant si la résolution de nom ne le permet pas, ou si en forçant par un fichier Hosts ou un DNS interne l'utilisation d'une IP dans le réseau et que le certificat présent sur Ex2010 ou le load-balancer ne contient pas ce le Fqdn lié à l'External Url.
Je vous recommande vivement de mettre à jour à minima les CAS Ex2007 en SP3 + dernier Rollup afin de prévenir tout problème!
Sinon sur le reste, le tuto devrait rester très similaire.
Cdt,
Benoit.
Salut Benoit,
RépondreSupprimerje te remercie beaucoup d'avoir pris le temps de me répondre.
je suis impressionné dans le mauvais sens du terme de voir la façon donc microsoft à penser aux possibles coexistence entre deux exchange.
Autant l'approbation de domaine ca va pas chercher bien loin, mais pour exchange on a l'impression que ca n'a pas été pensé pour!
a+
max
Bonjour Max,
RépondreSupprimerEn effet, Exchange n'est pensé que pour une seule base d'annuaire. Il existe un mode appelé Forêt de Resources, qui n'est autre qu'une implémentation d'Exchange dans une tièrce forêt. Elle a vocation à répondre à pas mal de chose vis à vis d'une décorrelation entre AD d'authentication. Cependant, elle ne répond pas au besoin de coexistence entre deux forêts existantes où la seule réponse viable sur le long terme est la migration inter-forêt.
Cela dit le mode de coexistence inter-Org n'est quasiement pas documenté, et donc méconnu. A mon sens il n'a vocatioin à exister que dans le scénario où aucun rapprochement (migration*, restructuration) n'est possible, que ce soit techniquement, politiquement ou financièrement. En soi, ce mode de coexistence n'est pas le plus simple à maintenir si l'on dépasse juste l'aspect Free/Busy.
Bonne journée!
Benoit.
bonjour
RépondreSupprimeret faire cette manipulation avec des exchanges 2013 ? ca tourne ?
Bonjour "Anonyme" :)
RépondreSupprimerExcellente question. Je n'ai pas eu l'opportunité de tester cependant je pense que - si cela peut fonctionner - cela sera certainement compliqué pour deux raisons: 1) le referral serveur a changé dans Ex2013 et 2) Ex2013 ne fait que du Rpc/Http en sécurité "Anonyme" en ce qui concerne la connexion Mapi. Dès lors un utilisateur Ex2013 aura probablement du mal à se connecter à un Ex2010 ou Ex2007 [...]. C'est à tester je dirai, tout en essayant plusieurs configuration de sécurité sur le profil Outlook / compte Exchange.
bonjour,
RépondreSupprimermoi j'ai 3 domaines, 3 ex13 et j'aimerai que tout le monde puissent se voir (surtout les calendriers! )
Bonjour Damien,
RépondreSupprimerAvez-vous pensé à l'utilisation des passerelles de Federation Microsoft pour cela ? Il suffit de publiquer quelques Web Services et configurer les politiques de partage.
Super Tuto!
RépondreSupprimerEst ce que le script new-autodiscoverconfig est trouvable quelque part?
Merci.
Bonjour Anonyme :)
RépondreSupprimerJe ne l'avais pas mis sur mon OneDrive, mais c'est maintenant chose faite: http://1drv.ms/1kkGw1A
Il faudra récupérer le script d'include mod-Utils.ps1
Bonjour,
RépondreSupprimercette methode fonctionne t elle entre exchange 2007 et 2013 sur deux site distant ?
Si oui, quelle est la methode la plus simple pour que les faire communiquer entre eux ?
VPN ?
Merci d'avance.
Cdt
Bonjour,
Supprimerquand vous dites "deux sites distants" voulez vous dire deux serveurs dans la même organisation mais distants géographiquement ou deux organisations isolées et devant se parler / partager des choses?
Il s'agit de deux organisations isolées et devant partager leurs agenda.
RépondreSupprimerMerci
Le partage de Free/Busy fonctionnera cependant le partage complet (2nde partie) ne fonctionnera pas (trop de différence entre les protocoles d'accès et méthodes d'authentification). Pourrait fonctionner si les clients Outlook auto configurés par Ex2013 sont réactivés pour Nego ou Kerberos ou Ntlm au lieu de Anonyme (onglet sécurité dans les propriétés du compte). Pas simple, a cause des nombreux changements dans Ex2013 pour remplacer le Mapi/Rpc et le Rpc/Http (maintenant l'âge du nouveau protocole Mapi/Http débute!)
RépondreSupprimerBonjour,
SupprimerJe souhaites mette en oeuvre votre technique afin que mes utilisateurs Excahnge puisse partager leurs calendrier.
J'ai un serveur Exhcange en 2013 SP1 et un autre sur un site distant d'une autre orgnisation en exchange 2010 SP3.
J'ai vu que je pouvait egalement faire du partage de federation....Microsoft Federation Gateway...
Qu' elle solution est la plus simple à mettre en oeuvre ?
Merci d'avance.
Bonjour Marty: Avec deux organisations Exchange 2010 et plus c'est assez simple en effet. Il suffit de déclarer de chaque coté un Trust avec la passerelle de fédération Microsoft.
SupprimerSur Exchange 2010 cela se fait via la création d'un Federation Trust. Vous pouvez le faire via la console Exchange 2010. Il faudra faire en sorte que les serveurs CAS aient un accès à Internet, soit directement, soit via un proxy (utiliser Set-ExchangeServer pour le positionner, attention au format c'est http://1.2.3.4:1234).
Sur Ex2013 c'est la même chose mais via l'Exchange Admin Center..
Ensuite il faudra configurer des deux côtés:
1. sharing policies
2. Organization Relationship
Je rappelle que dans les deux cas il faut que l'autodiscover soit bien publié ainsi que les Web Services (/Ews/*) et avec un certificat émis par une autorité de certification publique.
Bonjour Benoit,
SupprimerMerci pour votre réponse mais en suivant la procédure sur le site de Microsoft suivant c'est un peu fouillis je ne m'en sort pas...
http://technet.microsoft.com/fr-fr/library/ff601760
Je suis bloquer à l'etape 2 et trois lorsuqe que j'execute les commandes suivantes Add-FederatedDomain -DomainName test.com et Get-FederationInformation -DomainName j'ai le message :
Les informations sur la federation envoyees par l'organisation externe n'ont pas pu etre recues.
+Categoryinfo : Notspecified
Merci d'avance.
Bonjour Benoit,
SupprimerMerci pour votre réponse. En revanche je galere un peu en passant par la procedure suivante : http://technet.microsoft.com/fr-fr/library/ff601760. C'est un peu fouillis j'ai l'impression de tourner en rond...
Je bloque à l'etape 2 et 3 en tapant les commandes :
Get-FederationInformation -DomainName et Add-FederatedDomain -DomainName test.com
[PS] C:\Windows\system32>Get-FederationInformation -DomainName serveur.carnuta.com
Les informations sur la fédération envoyées par l'organisation externe n'ont pas pu être reçues.
+ CategoryInfo : NotSpecified: (:) [Get-FederationInformation], GetFederationInformationFailedException
+ FullyQualifiedErrorId : AAFC53A5,Microsoft.Exchange.Management.SystemConfigurationTasks.GetFederationInformation
[PS] C:\Windows\system32>Add-FederatedDomain -DomainName carnuta.com
Aucune approbation de fédération n'est configurée pour cette organisation ou aucun domaine n'est fédéré en tant qu'espa
ce de noms de compte.
+ CategoryInfo : InvalidOperation: (Federation:ADObjectId) [Add-FederatedDomain], NoTrustConfiguredExcept
ion
+ FullyQualifiedErrorId : 9D18936,Microsoft.Exchange.Management.SystemConfigurationTasks.AddFederatedDomain
Merci d'acance.
Merci pour ce tuto, dans notre cas les utilisateurs exchange 2007 reçoivent bien les free/busy des utilisateurs du exchange 2010 mais pas l'inverse ?
RépondreSupprimerComment pourrais-je debugger cela ?
Bonjour Benoit,
RépondreSupprimerCela fonctionne-t-il pour deux serveurs Exchange 2007?
Merci par avance.
Julien
Bonsoir Julien,
RépondreSupprimerOui il est possible de fédérer les Free/Busy entre deux organisations Exchange. L'implémentation est similaire, il peut être nécessaire de créer l'AvailabilityAddressSpace en mode "classique" (ex: PerUserFB) plutôt qu'en InternalProxy et ensuite la configuration risque de varier en fonction du niveau de "proximité" entre les organisations (relations d'approbation entre les forêts? résolution de nom? ou par Internet en passant par de la publication de l'AutoDiscover et des Web Services, etc...).
Donc possible oui... :)
Bonjour Benoit,
SupprimerCela fonctionne bien et effectivement il faut créer l'AvailabilityAddressSpace en mode "PerUserFB"
Merci.
Julien
Bonjour,
RépondreSupprimerSuper tuto.
merci de l'avoir mis en place.
mais j'ai une question s'il s'agit de deux serveurs Echanges 2010, on l'applique comment?
Bonjour Dieuner,
SupprimerDeux options: si les deux organisation Exchange 2010 ont un accès Internet et peuvent être publiées sur Internet + bénéficier de certificats publics, possible de passer par la passerelle de Fédération MS. L'avantage est que cela permet de les fédérer aussi par la suite avec d'autres organisations.
Si cela n'est pas faisable, il faut utiliser les Availability Address Spaces des deux côtés, et que l'organisation A puisse utiliser l'Autodiscover de l'organisation B (pour chaque domaine) et vice-versa. Là où cela peut devenir compliqué est sur le principe de résolution de nom, l'accès aux Web Services et les accès réseau en général.
Il faut ensuite savoir quel est le niveau de confiance entre les deux organisations / forêts AD. Si il y a une relation d'approbation bidirectionnelle forêt, cela peut être assez simple en définitive:
- Le droit PerUserFB fonctionnera nativement,
- Il est possible de créer des Service Connection Points dans chaque AD pour aider à trouver les informations d'accès des Web Services sans recourir à l'Autodiscover par DNS.
Pour utiliser le PerUserFB, il est possible d'utiliser le compte des serveurs Exchange entre les forêts (cela demande un peu de configuration mais c'est bien expliqué sur le Technet ici: https://technet.microsoft.com/en-us/library/bb125182(v=exchg.141).aspx (suivre la procédure: Use the Shell to configure per-user free/busy information in a trusted cross-forest topology)).
Dernier point: assurez vous que les utilisateurs de l'organisation A sont bien présents dans l'organisation B en tant que MailContact (recommandé) ou MailUser. C'est important car Exchange va se baser sur l'ExternalEmailAddress (attribut 'targetAddress' dans l'AD) afin de localiser les Web Services de l'autre organisation.
S'il n'y a pas de relation d'approbation entre les forêts c'est un peu plus compliqué et il faudra utiliser des comptes AD dans chaque forêt, ces comptes servant aux serveurs Exchange de l'autre forêt à se connecter au Web Services. Dans ce contexte, il faut faire du OrgWideFB, comme décrit dans la procédure "Use the Shell to configure organization-wide free/busy information in an untrusted cross-forest topology".