[INFO]: Exchange 2013 Preview / Erreurs Securité (ID 4625 / Unknown logon name or password)

Au lendemain de l'installation de mon serveur Exchange 2013 Preview, j'ai remarqué que mes journaux d'évenements de sécurité se remplissaient d'échecs de type "Audit failure" / "An account failed to log on"... (EventID 4625).

Quid? Je vois que le compte qui bombarde mon serveur de demandes d'authentification (et échoue donc), est HealthMailbox4139e7ab8f1048e5a8bc51cca4ec531f@uc-previewlab.com. Le nom du compte ressemble à une adresse E-mail, certes, mais est en fait un UPN (User Principal Name). Une recherche rapide dans mon AD, et je vois que l'utilisateur existe bien. Cependant, l'UPN défini est HealthMailbox4139e7ab8f1048e5a8bc51cca4ec531f@uc-previewlab.org et non ".com".

Hier, j'ai reconfiguré le domaine SMTP par défaut à "uc-previewlab.com" ce qui a eu pour effet de changer toutes les adresses E-mail à cette extension. Il semblerait donc que l'adresse E-mail soit utilisée afin d'authentifier l'utilisateur "HealthMailbox" sans se préoccuper de savoir si elle est bien différente de l'UPN (elle l'est, la plupart du temps :)).

Bref, un coup de "domain.msc", et j'ajoute à ma forêt le suffixe UPN "@uc-previewlab.com". Je change l'UPN de la BàL HealthMailbox et quelques secondes après, les erreurs ont disparu!

Moralité: il s'agit à mon humble avis d'un bug qui j'espère sera corrigé à la sortie du produit.

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          7/22/2012 6:34:00 PM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      sv-e15pr-1.uc-previewlab.org
Description:
An account failed to log on.
Subject:
 Security ID:  SYSTEM
 Account Name:  SV-E15PR-1$
 Account Domain:  PREVIEW
 Logon ID:  0x3E7
Logon Type:   8
Account For Which Logon Failed:
 Security ID:  NULL SID
 Account Name:  HealthMailbox4139e7ab8f1048e5a8bc51cca4ec531f@uc-previewlab.com
 Account Domain:  
Failure Information:
 Failure Reason:  Unknown user name or bad password.
 Status:   0xC000006D
 Sub Status:  0xC0000064
Process Information:
 Caller Process ID: 0xe68
 Caller Process Name: C:\Exchange\Bin\MSExchangeHMWorker.exe
Network Information:
 Workstation Name: SV-E15PR-1
 Source Network Address: -
 Source Port:  -
Detailed Authentication Information:
 Logon Process:  Advapi 
 Authentication Package: Negotiate
 Transited Services: -
 Package Name (NTLM only): -
 Key Length:  0

[INFO]: Quelques hotfixes recommandés sur vos serveurs s'exécutant sur Windows Server 2008 R2 (SP1)

... en attendant le Service Pack 2 de Windows Server 2008 R2, je vous conseille d'évaluer lap possibilité d'installer ces hotfixes sur vos serveurs (en particulier Exchange et Lync):

• http://support.microsoft.com/kb/2401588/en-us (mise à jour du Rpc Windows / problème de crashs sporadiques du service)
• http://support.microsoft.com/kb/2619234/en-us (mise à jour importante vis-à-vis du Rpc/Http, il s'agit d'ailleurs d'un pré-requis à Exchange 2013)
• http://support.microsoft.com/kb/2675785/en-us (correction d'un problème d'ajustement automatique de la taille des fenêtres TCP/IP)
• http://support.microsoft.com/kb/2699780/en-us (correction d'une fuite mémoire dans le service Remote Registry)

[INFO]: Installation d'Exchange 2013 (Preview) et un avant goût d'Outlook Web App 2013 !

Après le "Quoi de neuf dans Exchange 2013" et une balade au parc avec ma femme et ma fille, il est temps de s'attarder sur l'installation d'Exchange 2013 (Preview) et avant de regarder ce qu'il a dans le ventre sur les aspects techniques, vous donner un avant goût d'Outlook Web App 2013.

Installation d'Exchange 2013

Rassurez vous, rien de révolutionnaire ici. Tout d'abord, j'ai choisi la solution de facilité, à savoir installer Exchange 2013 Preview sur Windows Server 2012 RC. De facilité car les dépendances systèmes et fonctionnalités Windows sont déjà présentes... gain de temps. De plus il faut avouer que Windows Server 2012 RC est particulièrement stable pour une RC et surtout très rapide!

1) Préparation de l'AD

Bref, on commence par une préparation de l'AD. Les principes sont strictement identiques à la version précédente. On peut préparer le Schema, tous les domaines, ou chacun indépendement, etc... Dans mon petit lab de preview j'ai choisi de faire l'intégrale, préparation AD et création de l'organisation en une seule étape:

Fait rigolo, notez le switch "/IAcceptExchangeServerLicenseTerm" qui m'a fait sourire. Outre les aspects licence, il évite le temps de réflexion pénible introduit dans le setup d'Exchange 2010.

Notez aussi qu'il n'y a plus un "setup.exe" et un "setup.com", juste un "setup.exe" qui peut être utilisé en ligne de commande ou en graphique.

Voilà, c'était pour la partie Active Directory, exécutée sur mon contrôleur de domaine Windows Server 2012 RC... Passons maintenant au serveur membre Exchange!

2) Installation des pré-requis

J'ai pour habitude d'installer les pré-requis Windows à la main. L'équipe Exchange a conservé le switch /InstallWindowsComponents, mais ils n'installent évidemment pas les "autres" pré-requis, à savoir:

• L'Office FilterPack 2010 + son SP1
• UCMA 4.0 (toujours en Beta/Preview)

Personnellement, j'installe aussi le iFilter Adobe v9.0 x64 afin d'indexer les documents PDF.

Du coup, j'ai adapté mon petit script d'installation des composants Windows, dont voici un exemple d'usage (ici rôles CAS et MBX) - il faut redémarrer avant de continuer le reste de l'installation des pré-requis et d'Exchange 2013:

Puis j'ai ensuite installé l'UCMA 4.0 (rappel: Unified Communcations Managed API 4.0 est à la base un composant Communications Server / Lync) et les iFilters Office (+SP1) et Adobe. Il est important de désinstaller les composants Visual C++ 11 Beta qui sont installés en même temps que les composants UCMA 4.0:

Une fois tout ce petit monde sur mon serveur, un petit coup de Windows Update a fini d'installer les derniers correctifs disponibles. Dès lors, le serveur était désormais prêt pour accueillir Exchange 2013.

3) Installation d'Exchange

A des fins de tests, j'ai pris l'option d'installer les rôles Client Access et Mailbox Server conjointements sur le serveur. Dans le contexte cela n'a aucune importance et viendra le lab complexe lorsque l'on souhaitera explorer l'intégralité de la technique...

Aide du "Setup" - On voit ici très bien qu'il n'existe que deux rôles principaux...

Un petit coup de setup en ligne de commande:

.\Setup.exe /mode:Install /role:CA,MB /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents /TargetDir:C:\Exchange

Une quinzaine de minutes après, nous y voilà, Exchange 2013 est installé! Un redémarrage étant requis, je m'exécute et après quelques sueurs froides (premier redémarrage assez long), le serveur est tout fraîchement installé.

Une ouverture de l'eventlog confirme que tout un tas de composants "MS Exchange quelque chose" ont démarré :) - de même un coup d'oeil à la console des Services confirme que tout a démarré!

Il suffit ensuite de regarder la console IIS, et là de constater que l'on a deux sites IIS. Un sur Default web Site, l'autre additionel, nommé "Exchange Back End".

Aller, sur ces observations, tentons de nous connecter à Outlook Web App... La page de connection est épurée, style Métro / Windows 8 / Office 2013... Notez le logo "Office" en bas à droite!

Le premier bon point est la rapidité de chargement de la Web App, là où Exchange 2010 peinait un peu parfois, le code se charge ici super vite! Nous voici donc connecté à notre boîte aux lettres en quelques secondes...

Encore une fois, style épuré non sans rappeler Office/Outlook 2013. On retourve le bandeau et un menu bandeau minimaliste. On remarque aussi qu'Outlook Web App remplace le concept de "Contacts" par le concept de "People". L'idée est de fournir ici une liste de contacts E-mail/Instant Messaging/Social Connector intégrée, tout comme le propose déjà Outlook 2013.

On voit aussi que le menu "..." permet d'accéder à des actions supplémentaires, comme entre autres l'affichage dans une nouvelle fenêtre, ou même l'affichage des propriétés détaillés d'un message (pratique pour le troubleshooting...)

Allons voir maintenant ce qui nous est proposé dans les vraies nouveautés...

Mode Offline

Outlook Web App 2013 est désormais accessible en mode déconnecté dès lors que l'on utilise Internet Explorer 10, Chrome 17 (et +) ou Safari 5 (et +). Il n'est évidemment pas recommandé d'utiliser ce mode si l'on est pas sur un poste habituel / maîtrisé / "corp" et il sera intéressant de regarder s'il est possible de bloquer ce mode lors d'une connection au travers d'un poste considéré non securisé...

Web Apps Extensibility

Ensuite, regardons la ligne d'en dessous... "Manage apps..". Késako? C'est pour moi une innovation majeure d'Outlook Web App 2013, à savoir la possibilité d'intégrer d'autres Web Apps dans Owa, qu'elles soient "corporate" ou simplement grand public. Ici j'ai par exemple ajouté l'application Hertz, sachant que Microsoft fournit de base trois applications: Bing Maps et deux autres applications de productivité intégrées au calendrier.

Exchange Administration Center

Après l'Exchange Control Panel, voici l'Exchange Administration Center ou "EAC". Il s'agit tout simplement d'une console Web (dans la lignée de l'ECP donc) mais qui a vocation à remplacer la MMC Exchange Management Console. Belle ambition! Il s'agissait d'un voeu pieu car on sentait clairement l'orientation prise par Microsoft déjà avec Exchange 2010 et poussée encore plus loin ici.

On se connecte d'ailleurs sur l'Url "/ecp". Ce qui est intéressant ici c'est que lorsque l'on accède à ses options on utilise la même Web App, mais que dans un nouveau contexte, on se voit proposer de se connecter à l'EAC. De la même manière que la connexion à Owa, on a un formulaire de connexion épuré et stylisé Windows 8 / Office 2013...

On retrouve alors la plupart des prinpaux élements de configuration, quelques nouveautés à explorer (il y en aura surtout énormément dans les Cmdlets :)).

En voici quelques exemples:

Gestion des déstinataires (BàL, Grouptes, BàL de Ressources, Contacts, BàL Partagées et migration (Move Requests))



Gestion des "migrations" - il s'agit d'une console centralisant les Move Requests et permettant de gérer des comptes admin afin d'effectuer des migrations "inter-Org" et/ou entre Exchange et Office 365/Exchange Online.



On retrouve l'éditeur RBAC et des nouveaux Rôles, en particulier sur le DLP (Data Loss Prevention) sur lequel nous reviendons plus tard...

 Voici donc un premier toucher à Exchange 2013, et surtout à Outlook Web App. Il convient de dire que la simplification des rôles va faciliter le déploiement, mais surtout... comme System Center, Windows Server, Office, etc etc le Cloud est omniprésent. On aime ou pas, en tout cas il est impossible d'y être indifférent!

A bientôt, et bonnes vacances à tous!

[INFO]: Quoi de neuf dans Exchange 2013?

La version Preview d'Exchange 2013 est disponible depuis plus de trois jours (tout comme Office et  SharePoint). Microsoft a donc tenu sa promesse de fournir la "Wave 15", que l'on conviendra d'appeler désormais la suite 2013 (voire même suite "Office 2013"), cet été. Pile-poile pendant les vacances, cela ne nous laisse que peu de temps pour blogger en masse (damned!).

Le site Technet commence donc juste à être peuplé de nouvelles pages autour du produit Exchange 2013. Ce qui ressort de la documentation est un ensemble de changements radicaux dans l'architecture des rôles du produit. A chacun donc d'apprécier chaque changement à sa juste (ou injuste) valeur. Il y aura des joies et de peines, des cris (de joie) et des larmes (de joie aussi ?)... 
Au menu donc:

• Disparition des rôles Hub Transport Server et Edge Transport Server qui se retrouvent sur les rôles Client Access Server et Mailbox Server
• Front-End Transport Service (sur les CAS, effectue l'hygiène/anti-malware): remplace le Edge Transport
• Hub Transport Service (anciennement sur les Hub et Edge): revient sur les serveurs à rôle Mailbox et fonctionne dans le même état d'esprit que les Hub Transport Server
• Mailbox Transport Service: qui effectue le lien entre le Hub Transport Service et les Mailbox Databases (semblable au service de soumission d'Exchange 2007 et 2010
• Disparition du rôle Unified Messaging: Le rôle Client Access Server fera désormais office de point d'entrée SIP (rappel: Session Intiation Protocol) et le chemin média s'établira avec le rôle Mailbox Server. Le CAS sera donc le routeur SIP et le MBX le "endpoint". La seule exception sera lors d'une intégration avec Lync où ce dernier sera capable d'utiliser le Mailbox Server directement comme point de stockage des messages vocaux. Nota bene: La partie Unified Messaging ne sera pas activée par défaut.
• Le changement est somme toute radical et il faudra y regarder de plus près avant de se faire une idée précise :)
• Disparition de l'Exchange Management Console, au bénéfice d'une console 100% Web, portée par l'Exchange Control Panel et que l'on nommera alors l'Exchange Administration Center (EAC). Il subsistera quelques éléments dans une MMC nommés "Exchange Toolbox". L'idée ici est de favoriser l'accès distant et l'utilisation d'une console dynamique et sans pré-requis forts sur le poste de l'administrateur. Toute ressemblance avec Office 365 ne serait que ... voulue.

Dans la continuité de la version précédente (et surtout de son SP2), Exchange s'intégrera toujous plus fort avec le Cloud. Dans l'air du temps me direz vous (ndlr: du temps qui passe, pas qu'il fait... quoique avec les nuages cela porte à confusion ;)). Il sera possible d'intégrer Tenant et OnPremise au moment de l'installation même d'Exchange. Plus facile, on ne peut pas... :)

Dans les nouveautés fonctionnelles:

• Outlook Web App et Control Panel sont donc toujours là mais bénféficient d'un relookage intégral en Metro-Style... Owa devient un vrai frontal applicatif et pourra être étendu avec de nouvelles Web Apps (ça sens l'intégration avec d'autres produits ;)) et surtout sera disponible en mode "hors connexion" !!!! (nécessite tout de même Internet Explorer 10)
• Meilleure intégration fonctionnelle entre Exchange/Outlook, Lync et SharePoint. Apparition des "Site Mailboxes" qui permettent une intégration forte entre Exchange et SharePoint, et la possibilité d'utiliser tout ce petit monde pour un partage complet E-mail/Documents/Contacts. Pratique en cas d'équipe projet travaillant sur des mêmes sujets...
• Conservation des Dossiers Publics mais disparition des Public Folder Databases (ça peut faire sourire :)). Quid? Les Dossiers Publics deviennent stockés dans une Mailbox de type "PublicFolder". Technet référence déjà une procédure pour migrer depuis Exchange Server 2010 SP3 (sachant que le SP3 n'existe pas encore!) et cela promet d'être fun... (ou pas)
• Côté haute disponibilité, on retrouve les Database Availability Groups et essentiellement la même philosophie de réplication/disponibilité. La fonctionnalité est grandement améliorée grâce à tout un tas d'aides à la gestion via des scripts type "One Copy Trigger" qui permet de déclecher des actions lorsque la haute disponibilité ou l'intégrité des donnés sont en danger.

Le tout est saupoudré d'énormément de fonctionnalités déjà existantes mais grandement améliorées grâce aux demandes des clients, mais aussi et surtout aux apports du Cloud dans les nouvelles façons de gérer ses infrastructures...

Que se passe-t-il techniquement parlant ?

• Il n'est plus requis d'avoir un serveur à rôle Client Access (et anciennement Hub Transport) par site Active Directory. Il devient donc possible de faire des sites "purs back-end" n'hébergeant que les boîtes aux lettres et du transport, et donc à contrario de disposer de sites "purs front-end" n'hébergeant que des frontaux de présentation et de transport "externe". Ce n'est pas une obligation cependant et l'on pourra rester dans un mode plus classique. C'est un concept qui peut paraître difficile à appréhender mais qui va permettre de grandement solidifier les services sans pour autant se prendre la tête (complexité) ou mettre la main au portefeuille (nombre de serveurs) :)
• N'oubliez donc pas qu'il faudra conserver l'idée des sites "Internet-faced" et des sites "Back-end"
• Indifférence de session: Exchange 2010 a introduit un usage massif des load-balancers et une dépendance très forte... Personnellement j'adore les load-balancers, mais il faut admettre que cela a rajouté une complexité opérationnelle à laquelle les exploitants (surtout ceux venus d'Exchange 2003) n'étaient pas habitués... Avec Exchange 2013 les load-balancers resteront une nécessités, mais avec une complexité réduite:
• L'affinité de session ne sera plus requise depuis un client/une IP source: cela causait pas mal de soucis en particulier avec des serveurs Blackberry et Good Mobile et consorts...
• Optimisation de l'authentification: le client authentifié est persisté via le Client Access Server qui l'impersonnifie pour accéder au reste des accès. Cela réduit considérablement les requêtes d'authentification et négociations diverses de sécurité et accroît de manière drastique la capacité d'accueil et les performances. J'aime aussi à penser que cela réduira l'effet "popups" (ceux ayant déjà déployé Exchange 2010 dans des grosses configs avec des réseaux bancals me comprendront) :)
• Le Store se transforme: Le Service Information Store devient le "Managed Store" et intègre un moteur de recherche FAST, issu du monde SharePoint. Il s'optimise aussi de manière à encore réduire les besoins d'IOPS, non pas pour aller sur des clefs USB ou du 5,400 tours/minute, mais afin de permettre de supporter plusieurs copies sur un seul et même disque... Et oui, avec des disques de 3TB et 4TB qui vont devenir standards en 2013/2014, cela commençait à devenir nécessaire (j'aime bien faire de grosses BàL mais bon, les clients Outlook ne suivent plus au bout d'un moment :P).
• Modifications dans le Throttling Framework: Exchange 2010 a introduit le Throttling Framwork dans le but d'éviter qu'une suconsommation des resources pénalise l'intégralité du service. Exchange 2013 va encore plus loin en améliorant les possibilités et en créant des politiques de gestion de la charge de travail permettant d'assurer des qualités de service minimum. Il s'agira essentiellement de surveiller les seuils de performance des composants de la chaîne (les "Ressources") et de définir des typologies de classes de services (les "Workloads"). Typiquement, si l'on défini une catégorie d'utilisateurs type "Web Access Users", on sera à même de leur garantir un meilleur accès aux ressources Owa que les autres (qui se connecteront via des moyens plus classiques).

Dans la version Preview d'Exchange 2013, il n'est pas supporté de coexister des versions précédentes. Cela inclut Exchange 2010, 2007 et bien sûr Exchange 2003. Il est prévu cependant de supporter une coexistence, à minima avec Exchange 2010 et 2007 mais la coexistence avec Exchange 2003 n'est pour l'instant pas prévue.

Côté client, Outlook 2007 SP2 + mise à jour de Juilet 2011 sera la version minimale. Cette fameuse mise à jour contient les correctifs nécessaires à une intégration correcte avec Office 365. C'est aussi une des raisons pour lesquelles Outlook 2003 ne sera plus supporté (outre son obscolescence).

Voilà il ne s'agit que d'une introduction, mais la fumée sort déjà par les oreilles... ;)

Prochain billet: installation!

[TUTORIEL]: Partage entre Organisations Exchange (partie 2: coexistence "riche")

Rappel de la première partie.

Nous avons vu comment:

1. Créer des Availability Address Spaces
2. "Une méthode" pour interconnecter deux organisations Exchange (une 2010 SP2 et une 2007 SP3)
3. Observé que l'affichage des informations de disponibilité était fonctionnelle

Maintenant, nous allons aller un peu plus loin et explorer le partage du *contenu* des boîtes aux lettres au travers des habituelles permissions Mapi/Cdo d'Outlook.

Partie 2: Mise en oeuvre d'une coexistence riche au travers de délégations inter-organisationnelles. 

2.1) Quel est le problème, au fond ?

C'est très simple... Lorsque nous donnons des permissions sur un dossier (type "Boite de réception" ou "Calendrier"), Outlook utilise la référence de sécurité de l'objet de notre délégué, à savoir son "SID" (Security IDentifier).

Or, le SID est typiquement mis sur un objet de securité, type un objet 'user' ou 'inetOrgPerson' ou bien sûr un groupe, lorsqu'il s'agit d'un groupe de sécurité.

Dans l'état actuel des choses, mon délégué (John Doe) est actuellement hébergé chez PARTNER Inc. (représentant un département historique du Groupe et qui doit "converger" dans le Système d'Information Corp). Bref, c'est actuellement un ... contact. Et donc, il n'est pas un objet de sécurité.

Si l'on essaye d'assigner des droits à un contact depuis Outlook, ce dernier nous dira de manière très sympathique

Alors gambergeons un peu. Cela nous rappelle un scénario OCS/Lync que l'on appelle "Central Forest". C'est une variante du "Resource Forest" où les objets représentant les comptes OCS/Lync sont des contacts. Ces contact ont vocation à représenter les objets dans l'annuaire Active Directory et répliqués dans la base OCS/Lync. En ce qui concerne la securité et l'authentification ils sont cependant reliés à un compte utilisateur d'une forêt que l'on identifie comme "Forêt utilisateur". La relation est faite avec l'attribut 'msRTCSIP-OriginatorSid' dans lequel on copie le SID de l'utilisateur.

Et si Exchange pouvait faire pareil? On connait bien le 'msExchMasterAccountSid' qui est utilisé dans un cas de forêt de ressources où typiquement il existe un compte utilisateur désactivé portant les attributs Exchange représentant la configuration de la boite aux lettres (server, base de donnée, alias, etc...).

2.2) OK, et...?

Sur cette base, on sait qu'il existe un moyen d'associer une boîte aux lettres d'une forêt 'R' (comme Ressource :)) à une compte d'une forêt 'U' (comme Utilisateur). Mais dans le cas d'une coexistence entre organisations, cela ne suffit pas... et encore moins sur des objets de type 'Contact'.

Lorsque l'on regarde les types d'objets connus dans Exchange 2007 et Exchange 2010, on voit qu'il existe un type nommé "Across-Forest Contact". Késako? Simplement un type spécialisé de contacts AD/Exchange autorisant l'utilisation de certains attributs, ceci à des fins de partage inter-Organisations:

• targetAddress: son utilité ne change pas, et permet toujours la localisation des Web Services pour utilisation des Free/Busy
• mAPIRecipient: permet à Exchange/Outlook de voir le contact comme un objet sur lequel on a la capacité d'accéder en tant que délégué (utilisé quand un quelqu'un de l'Org A veut se connecter à la boîte aux lettres de quelqu'un de l'Org B)
• msExchMasterAccountSid: référence le SID d'un utilisateur de l'organisation voisine (utilisé quand un quelqu'un de l'Org A veut donner des permissions à quelqu'un de l'Org B)
• msExchOriginatingForest: référence la Forêt AD d'origine, et permet donc au referral de notre Organisation d'aller chercher un Referral dans l'autre Forêt/Organisation et donc de se connecter en MAPI !!! Ta-da!

Voici donc les quatre attributs critiques. Il en reste deux, qui permettent à Exchange de détecter que notre contact est un "Cross-Forest Contact" et de réagir en conséquence:

• msExchRecipientDisplayType: type de l'objet
• msExchRecipientTypeDetails: type détaillé

2.3) Création d'un Cross-Forest MailContact

Dans un scénario réel, il serait de la résponsabilité d'ILM 2007 SP1 ou de FIM 2010 / FIM 2012 R2 d'effectuer cette besogne. Il suffit pour cela de cocher la case idoine dans la partie synchron inter-forêt (Enable cross-forest delegation for Exchange Server 2007/Exchange Server 2010).

Ici, nous allons le faire à la main, pour cela un petit script suffit. Il a pour doux nom de 'Enable-CrossForestMailContact.ps'. Il s'agit d'un script qui va ajouter les attributs nécessaires sur un objet 'MailContact' déjà existant. Voici l'usage:

On spécifie ici l'identité du contact, l'utilisateur lié, un contrôleur de domaine d'origine et la forêt d'origine. Le script sera en charge d'aller chercher le reste. Une fois terminé, l'objet MailContact modifié et apparaît en lecture seule. Normal? Il semblerait que oui puisque ce type d'objet n'est censé être touché/modifié que dans un contexte de synchronisation d'annuaires, et donc via des interfact LDAP/ADSI et non via Exchange...

Il sera nécessaire de faire les modifications dans les deux sens afin de 1) pouvoir donner les délégations et 2) de voir le contact de l'autre côté comme un contact fédéré.

2.4) Résultats

N'oubliez pas mettre à jour votre (ou vos) OABs.

• Get-OfflineAddressBook | Update-OfflineAddressBook
• puis un fois la génération terminée: Get-ClientAccessServer | Update-FileDistributionService -Type OAB

Il ne reste plus qu'à démarrer vos clients Outlook, puis de récupérer l'OAB à jour.

Côté "John Doe" (Org B), je peux désormais donner l'accès à mon Calendrier à "Benoit Boudeville" en mode Editeur... Je peux même passer par l'assistant de délégation classique.

Une fois ces actions effectuées, mon client côté Exchange 2010 (Benoit Boudeville) doit aussi mettre à jour son OAB, s'il existait un accès à un Calendrier partagé (anciennement en Free/Busy seuls donc), il change automatiquement en accès complet, comme si "John Doe" avait magiquement été migré sur Exchange 2010 !!!

Et l'on voit bien que l'accès se fait directement en MAPI (ici vers le serveur Exchange 2007):

Il va sans dire que cela fonctionne pour tous les dossiers que l'on peut déléguer via Outlook, cela devrait aussi fonctionner pour des accès de type "Full Mailbox Access".

A vour de jouer !!! :)

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