[TUTORIEL]: Partage entre Organisations Exchange (partie 1: les Free/Busy)

Et bien! Cela faisait presque 1 an et demi sans billet ! Manque d'inspiration? Peut-être, mais surtout énormément de temps consacré au travail et à ma petite fille qui, au moment de l'écriture de ce billet, a presque 1 an :)
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".

Note: Le SP3 d'Exchange 2007 est important ici puisqu'il va nous permettre d'utiliser un mode de coexistence sympathique... :)
(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

puis, depuis un Exchange Management Shell côté Org A:

• Get-ClientAccessServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-Exch-EPI-Token-Serialization" -User "FORETB\Exchange Servers"

Depuis Exchange 2007, je vais utiliser une subtilité, à savoir déclarer mon Organisation Exchange 2010 comme un "proxy" de Free/Busy, ce qui permettra de ne pas utiliser l'Autodiscover. Outre un temps de réponse plus rapide (pas de recherche de SCP) cela permet de cibler une URL à proximité (par exemple: cibler "us.uc-lab.com" sur une ferme aux Etats-Unis). Le reste est identique.

• 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:

1. 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...
2. 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 officielle:

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.

Une fois tous ces points validés, une réplication AD en bonne et due forme, il est nécessaire de redémarrer les Web Services des deux côtés. Deux techniques, redémarrer IIS (iisreset nomduserveur) sur chaque CAS, mais cela coupe les autres services HTTP... donc pas terrible... soit effectuer un recyclage de l'Application Pool MSExchangeServicesAppPool (ma méthode préférée, surtout que c'est déjà tout scripté :)).

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:

1. L'Availability Web Service détermine que l'utilisateur n'est pas une BàL dans l'Organisation
2. Que c'est un contact avec une adresse externe (important, surtout dans le cas d'Exchange 2007)
3. Qu'un Availability Address Space existe pour le domaine de messagerie de l'adresse externe
4. 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")
5. Que l'URL d'Audiscover est https://qqchose.domain.ext/Autodiscover/Autodiscover.xml
6. 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
7. La requête à l'Availability Web Service distant est envoyée puis consommée et l'information retournée au client...

Sachez aussi qu'Exchange 2007 SP3 Rollup 6 et que Exchange 2010 SP2 Rollup 1 permettent désormais d'utiliser les URL Externes lors de la recherche de SCP. Ainsi, le comportement sera différent en fonction de la version que vous souhaiterez utiliser. Si vous utiliser des versions antérieures, Exchange 2007 et Exchange 2010 auront la furieuse tendance à retourner l'URL Interne définie sur le Web Service virtual directory. Si vous utilisez les dernières mises à jour, l'URL externe sera retournée, et dès lors devra pouvoir être résolue en interne.

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) !!!