Bonnes et mauvaises surprises

est due au fait que le serveur de messagerie apparaît sous le nom du cluster dans l’organisation Exchange.

En revanche, ce sont les noeuds membres du cluster qui apparaissent dans AD. La solution a donc été de créer une entrée de type ordinateur correspondant nom du cluster Exchange 2000 dans AD avant d’installer le 1er Serveur Exchange 2007. Ce nom a ensuite été supprimé après installation des différents serveurs Exchange 2007. En effet, le cluster Exchange 2000 ne peut redémarrer tant qu’un nom identique existe dans l’annuaire. Le problème serait identique avec un cluster Exchange 2003.

Dès l’installation des serveurs d’accès « CAS » en 2007 et avant même la migration des boîtes du cluster Exchange 2000 vers 2007, les utilisateurs ont pu accéder à leurs boîtes par OWA, mais avec l’ancienne interface. Ceci était déjà un progrès. Le déplacement des boîtes entre les serveurs Exchange n’a posé aucun problème. Outlook 2003 s’est globalement très bien débrouillé pour reconfigurer son accès. En revanche, l’accès par OWA 2007 est beaucoup plus exigent. Plusieurs types de messages sont apparus. A ce niveau, dès qu’un domaine possédait des comptes qui avaient des boîtes migrées sur Exchange 2007, la mise à jour d’au moins un contrôleur de ce domaine en Windows 2003 SP1 était indispensable.

La préparation du domaine par le setup de Exchange 2007 permet alors de créer les groupes de sécurité indispensables. Néanmoins, des erreurs de droits persistaient sur l’accès OWA. En effet, certains comptes n’héritaient plus correctement des droits, ce qui empêchait aux serveurs Exchange l’accès aux informations sur les boîtes et donc aux utilisateurs d’utiliser OWA. La réplication, puis le transfert définitif des dossiers publics vers Exchange 2007 n’a posé aucun problème. D’ailleurs, on parle souvent de se préparer à la suppression des dossiers publics au moment de la migration Exchange 2007. Cela est bien, mais pas du tout obligatoire !

D’ailleurs, le Service Pack 1 de Exchange 2007 remet une nouvelle interface graphique d’administration de ces dossiers publics. Malheureusement pour le client et pour de nombreux administrateurs Exchange, l’apprentissage des commandes PowerShell est nécessaire pour la mise en place de fonctionnalités très classiques. Par exemple, la création d’un connecteur de réception autorisant le dépôt de message depuis un serveur SAP oblige le passage par la ligne de commande pour donner les autorisations adéquates. De même, les autorisations et la configuration sur les ressources partagées imposent l’utilisation de commandes Powershell, par exemple pour l’utilisation d’une solution de type BlackBerry.