Post mortemMigration à partir d'Exchange 5.5

Whitney Roberts

LE PROJET

Le département de l'éducation du Kentucky avait besoin de migrer de son implémentation existante Microsoft® Exchange Server 5.5 vers Exchange Server 2003. Le système prend en charge environ 600 000 professeurs, étudiants et autre personnel au cours d'une année scolaire.

LES INTERVENANTS

Le projet a été géré par l'OET (Office of Education Technology) du ministère de l'éducation du Kentucky assisté des consultants de KiZAN Technologies. Le personnel de l'OET a fourni une vue d'ensemble de l'implémentation Exchange 5.5. L'exécution au jour le jour des serveurs Exchange était de la responsabilité du personnel local des circonscriptions scolaires.

LES DÉFIS

Le ministère de l'éducation assure la direction technique des 178 circonscriptions scolaires de l'État du Kentucky (Commonwealth of Kentucky). Ces circonscriptions scolaires sont reliées les unes aux autres via un WAN mais chacune héberge son propre serveur Exchange 5.5 géré en local, qui nécessitait d'être mis à niveau de façon individuelle. Cette mise à niveau devait permettre une prise en charge pour les clients en mode mis en cache Outlook® 2003, une pratique d'Outlook Web Access (OWA) améliorée, un schéma d'adressage électronique standardisé et bien d'autres choses.

Outre la mise en œuvre d'une nouvelle infrastructure cliente et de serveur de messagerie, plusieurs des circonscriptions scolaires ajoutaient la prise en charge du courrier électronique pour les étudiants. La police fédérale et gouvernementale ont toutes deux exigé que les informations des étudiants soient protégées et ne soient pas visibles hors de leur circonscription respective.

LE PROGRAMME

Étant donné qu'un ADC (connecteur Active Directory®) ne pouvait pas être utilisé, nous avons créé une nouvelle organisation Exchange et avons migré vers elle. Utiliser des adresses électroniques standardisées signifiait créer de nouveaux sous-domaines d'identification pour chaque circonscription scolaire et près de 400 nouvelles stratégies de destinataire. La protection des adresses des étudiants a nécessité la construction d'un système de listes d'adresses globales (LAG) et de listes d'adresses personnalisées pour chaque circonscription scolaire.

La migration effective impliquait d'activer du nouveau matériel, de créer et de configurer des boîtes aux lettres basées sur l'appartenance à la circonscription et le type d'utilisateur et de configurer des attributs d'extension basés sur l'appartenance à la circonscription et le type d'utilisateur de façon à ce que l'utilisateur s'affiche dans les listes d'adresses appropriées.

Nous avons créé une application basée sur Visual Basic® pour détecter et corriger les attributs de comptes ou les appartenances aux groupes mal configurés et pour attribuer correctement de nouvelles boîtes aux lettres et garantir que les exigences en matière de visibilité étaient conservées. L'application a été déployée dans les 178 circonscriptions et fonctionne de façon temporisée à partir des serveurs des circonscriptions scolaires.

Contexte

À première vue, ce travail peut ne pas sembler une tâche délicate ou techniquement difficile. Pourtant, comme on me l'a fait remarquer, les exigences de fonctionnement sont prioritaires et les exigences de fonctionnement de ce projet nous ont ouvert les yeux.

Au fil des années, la décentralisation de la gestion et un méli-mélo au niveau des normes ont créé de nombreux « silos » de prise en charge qui la plupart du temps devaient être gérés par l'OET. En outre, l'OET devait également s'assurer que l'implémentation Exchange 5.5 était conforme aux exigences des circonscriptions scolaires et à celles du ministère de l'éducation. Ceci signifiait que pour les circonscriptions qui utilisaient le courrier électronique des étudiants, les informations de ces derniers devaient être protégées et ne pas être visibles hors de la circonscription concernée, comme défini par les normes fédérales et gouvernementales (voir la page ed.gov/policy/gen/guid/fpco/ferpa/index.html, en anglais).

Dans Exchange 5.5, ces normes signifiaient que les données des étudiants au sein de la circonscription ne pouvaient pas être répliquées vers les autres circonscriptions scolaires ou les autres agences gouvernementales qui partageaient les données LAG. Cela nécessitait en particulier de passer par un processus d'exportation/importation manuel pour chacun des 178 sites Exchange 5.5 : masquer les étudiants, répliquer la liste, ne plus masquer les étudiants et enfin réimporter la liste d'adresses. De cette façon, les autres circonscriptions ne pouvaient visualiser que les données du personnel et la circonscription scolaire propriétaire des informations pouvait visualiser toutes les données la concernant mais seulement les données du personnel des autres circonscriptions scolaires.

Compte tenu des forces et des faiblesses du système existant, la mise à niveau de l'infrastructure de messagerie devait remplir certains critères spécifiques. Tout d'abord, le département de l'éducation du Kentucky souhaitait utiliser un schéma d'affectation de nom SMTP lisible commun qui soit généralisé à toute l'organisation. Le schéma devait fournir des espaces d'adressage SMTP différents pour les professeurs et les étudiants.

Le nouveau système devait également fournir un service géré de manière centralisée qui enlèverait à la circonscription la gestion et la responsabilité de la mise à disposition de la messagerie. Ceci comprenait la centralisation de la gestion de la récupération des données après sinistre, du flux de messages et de la résolution des appels au support technique. Par conséquent, le nouveau système devait fournir une méthode centralisée pour généraliser la configuration utilisateur dans toutes les circonscriptions, quelle que soit la situation géographique ou l'affiliation à une circonscription d'un utilisateur donné.

Le nouveau système devait ensuite fournir un accès Web et via des appareils mobiles sécurisé au courrier électronique en passant par un espace de noms unifié commun à toutes les circonscriptions.

Compte tenu de ces exigences (dont beaucoup n'étaient pas encore implémentées dans le système Exchange 5.5 existant) la mise à niveau vers Exchange 2003 semblait assez impressionnante.

Blocs de génération de la solution

Pour satisfaire aux exigences de fonctionnement, plusieurs options propres à Exchange ont été choisies pour le déploiement.

Étant donné le manque de standardisation et l'importance particulière de l'environnement Exchange 5.5, un ADC ne pouvait pas être utilisé. Au lieu de cela, nous avons créé une nouvelle organisation Exchange et avons migré dans celle-ci.

Le nettoyage et la standardisation des adresses électroniques pour le personnel et les étudiants de chaque circonscription ont engendré la création de plus de 400 nouvelles stratégies de destinataire. Les exigences imposaient qu'il y ait un sous-domaine d'identification unique pour chaque circonscription, comprenant une désignation d'identification de la circonscription pour les étudiants. Par exemple, dans le cas du comté de Shelby, le sous-domaine primaire devait être shelby.kyschools.us. Les étudiants de chaque circonscription ont reçu une désignation de sous-domaine stu., afin que les étudiants du comté de Shelby aient des adresses stu.shelby.kyschools.us.

Une autre contrainte était que les adresses des étudiants ne devaient être visibles que dans la circonscription de ces étudiants, alors que les adresses du personnel devaient être visibles dans toutes les circonscriptions. Cela supposait la construction d'un système élaboré de LAG et de listes d'adresses personnalisées, comme présenté dans la figure 1 et la figure 2. L'un des avantages de passer à Exchange 2003 était que les listes d'adresses pouvaient être sécurisées par des autorisations et que l'accès à chaque liste d'adresses individuelle pouvait être contrôlé en fonction de l'appartenance à un groupe. Nous avons fait bon usage de cette fonctionnalité et avons créé deux groupes de sécurité au niveau de la circonscription (l'un pour le personnel et l'autre pour les étudiants), puis nous avons sécurisé les LAG et les listes d'adresses des étudiants et du personnel correspondantes de sorte que seul les comptes utilisateur d'une circonscription spécifique aient accès à certaines listes d'adresses. En supprimant la LAG et les listes d'adresses par défaut puis en s'assurant que les groupes Tous les utilisateurs et Utilisateurs authentifiés n'étaient pas répertoriés sur la liste de contrôle d'accès (ACL) pour chaque liste d'adresses, nous pouvions présélectionner la liste d'adresses qu'un type d'utilisateurs spécifique d'une circonscription spécifique pourrait voir.

Figure 1** Listes d'adresses personnalisées basées sur les rôles **(Cliquer sur l'image pour l'agrandir)

Cependant, les autorisations ne résolvaient qu'une partie du problème de la visibilité. Il nous fallait trouver un moyen de contrôler ce qui était visible et dans quelle liste d'adresses. Une requête LDAP (Lightweight Direct Access Protocol) de base a été créée pour nous permettre d'effectuer la demande de la visibilité des étudiants et du personnel ; la requête a alors été légèrement adaptée à chaque liste d'adresses et LAG. Par exemple, la requête LDAP pour la LAG du personnel de Shelby ne devait montrer que les étudiants et le personnel concernés de Shelby et tout le personnel (mais pas les étudiants) de toutes les autres circonscriptions de l'état. La LAG des étudiants de Shelby ne devait montrer que le personnel et les étudiants de Shelby et pas le personnel ou les étudiants des autres circonscriptions dans l'état. Nous avons répété cette requête pour toutes les autres circonscriptions de l'organisation. La figure 3 présente les exemples de quelques requêtes LDAP utilisées dans cette migration complexe.

Figure 3 Requête LDAP de liste d'adresses

Requête LDAP de LAG du personnel

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14))))) 

Requête LDAP de liste d'adresses de la circonscription

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))

Requête LDAP de liste d'adresses des étudiants de la circonscription

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))

Requête LDAP de liste d'adresses hors connexion de la circonscription

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))

Figure 2** Listes d'adresses globales différenciant le personnel des étudiants **(Cliquer sur l'image pour l'agrandir)

Les valeurs personnalisées pour les propriétés de l'utilisateur Exchange extensionAttribute14 (attribut personnalisé 14) et extensionAttribute15 (attribut personnalisé 15) constituaient le mécanisme de différenciation sous-jacent aux requêtes LDAP. Tout le personnel et les étudiants d'un bout à l'autre de l'État utilisaient une valeur spécifique pour extensionAttribute14 pour désigner le type d'utilisateur et une valeur unique dans extensionAttribute15 pour afficher l'appartenance à la circonscription. En utilisant des valeurs uniques pour chaque circonscription et les mêmes valeurs pour chaque type d'utilisateur, les listes d'adresses pouvaient afficher avec exactitude les informations requises pour chaque type d'utilisateur dans chaque circonscription.

Ces listes d'adresses fonctionnaient plutôt bien en ce qui concerne l'accès des utilisateurs au courrier électronique via Outlook en mode hors cache ou via OWA. (Nous dirigions chaque utilisateur vers la liste d'adresses correcte dans OWA à l'aide de l'attribut msExchQueryBaseDN.) Mais pour les utilisateurs exécutant Outlook en mode mis en cache, cela présentait un autre problème. Outlook ne considèrera pas une LAG personnalisée comme étant le carnet d'adresses en mode hors connexion désigné ; aussi avons-nous donc dû créer des listes d'adresses supplémentaires qui étaient des copies des LAG. Chaque banque de boîtes aux lettres de la circonscription a alors été configurée avec la liste d'adresses du carnet d'adresses en mode hors connexion appropriée pour ses utilisateurs en mode mis en cache. En tout, cette solution plafonnait à plus de 1 500 listes d'adresses pour offrir des fonctions complètes aux différents types d'utilisateurs dans les 178 circonscriptions.

Garantie de la conformité

Pour s'assurer que la structure qui était mise en place fonctionnerait correctement, l'adhésion aux normes nouvellement établies était d'une importance capitale. Plusieurs tâches de haut niveau devaient se produire pour chaque utilisateur autorisé Exchange dans l'organisation. Cela s'explique par le fait que chaque utilisateur doit être correctement localisé sur tous les serveurs Exchange de la circonscription et doit également être visible sur les bonnes listes d'adresses.

L'utilisateur devait être membre du groupe de sécurité approprié au sein du domaine de la circonscription car le groupe de sécurité fournit les autorisations pour ouvrir la liste d'adresses appropriée. L'utilisateur avait également besoin que l'attribut msExchQuerybaseDN soit correctement défini en fonction de l'appartenance à la circonscription et à l'unité d'organisation. L'unité d'organisation de l'utilisateur déterminait le type d'utilisateur.

L'étape suivante consistait à créer la boîte aux lettres de l'utilisateur sur la bonne banque et sur le serveur approprié en fonction de l'appartenance à la circonscription et du type d'utilisateur. Ceci avait un impact sur les niveaux de service, les limites de taille de boîtes aux lettres et les listes d'adresses des carnets d'adresses en mode hors connexion de telle manière que le mode mis en cache d'Outlook puisse fonctionner correctement. Les attributs d'extension étaient définis en fonction de l'appartenance à la circonscription et du type d'utilisateur de sorte que l'utilisateur puisse apparaître dans les listes d'adresses appropriées et ne soit pas visible dans les autres.

Enfin, nous devions fournir un moyen de corriger automatiquement tout attribut de compte ou toute appartenance aux groupes dans le cas où ces éléments auraient été mal définis par erreur sur des valeurs inappropriées ou modifiés. Si un utilisateur passe d'une unité d'organisation à une autre au sein du domaine de la circonscription, cela signifie que la classification d'un utilisateur est modifiée et que l'emplacement de la boîte aux lettres, le choix de la LAG et la visibilité de la liste d'adresses doivent être mis à jour.

Nous avions besoin d'un système d'attribution de privilèges qui accomplirait ces tâches et assurerait la cohérence du système et l'exactitude des données d'Active Directory. Nous avons créé une application Visual Basic basée sur une console qui s'exécute de façon temporisée à partir des serveurs Exchange 2003 des circonscriptions scolaires. L'application, qui certifie le respect des normes et de la stratégie et gère également la création de nouveaux objets et l'attribution de privilèges d'accès, a été déployée sur les 178 circonscriptions.

Nous avons pensé que les tâches en cours étaient trop complexes pour qu'une série de scripts puisse fonctionner rapidement et de façon fiable. Par conséquent, l'application Visual Basic a été considérée comme la solution appropriée parce qu'elle était efficace, prenait en charge la gestion des exceptions et des erreurs de façon structurée et que son code interne pourrait être facilement adapté au code d'extension Microsoft Identity Integration Server (MIIS) à l'avenir avec une réécriture minimale.

Puisque nous devions migrer vers une nouvelle organisation, il nous fallait créer une méthode de cohabitation. Il y avait plus de 178 domaines SMTP hérités à prendre en charge dans le nouvel environnement — certaines circonscriptions avaient des domaines de courrier électronique préexistants pour les étudiants et d'autres non — mais nous avions la chance de pouvoir faire migrer les circonscriptions une par une et d'amener les messages et les adresses hérités sur le nouveau système sans que cela n'affecte les autres circonscriptions. Il nous fallait cependant éviter d'interrompre le flux de messages lors de la migration d'une circonscription d'Exchange 5.5 à Exchange 2003. Cela supposait d'implémenter un certain type de synchronisation des répertoires entre Active Directory d'Exchange 2003 et le répertoire Exchange 5.5 hérité. Microsoft accordait aux services de l'éducation du Kentucky une utilisation limitée de MIIS pour le temps de la migration uniquement et du code d'extension personnalisé a donc été développé et utilisé pour synchroniser les deux organisations Exchange via MIIS avant, pendant et après la migration.

Le transfert vers une nouvelle organisation Exchange affecte naturellement la configuration du client MAPI. Les services de l'éducation ont été confrontés au fait qu'il y avait littéralement des dizaines de milliers de profils MAPI au niveau de la circonscription qui devaient être reconfigurés pendant la migration. Heureusement, Microsoft a sorti Exchange Profile Tool (l'outil de profil Exchange, ExProfRe.exe), qui a été utilisé pour la migration de profil dans les circonscriptions. Nous avons créé un installateur empaqueté qui exécutait ExProfRe.exe avec des valeurs préchargées de sorte que les migrations de profil au niveau de la circonscription puissent être effectuées de façon automatique. Le programme était appelé via la stratégie de groupe. Nous avons obtenu un taux de réussite de près de 100 pour cent sur les migrations de profil automatisées entre organisations.

Mises à niveau matérielles

Les nouveaux serveurs Exchange 2003 allaient remplacer les serveurs Exchange 5.5 qui étaient dispersés géographiquement ; du point de vue matériel, cette solution devait donc prendre en charge le même nombre d'utilisateurs que le déploiement Exchange 5.5, plus le chargement des comptes étudiants supplémentaires. Les serveurs devaient être hébergés en local au sein des circonscriptions car la topologie WAN était conçue de telle façon que la totalité du trafic inter-circonscription (Internet et interne) puisse circuler sur une ligne T1 privée (Pour certaines circonscriptions, sur plusieurs lignes T1).

En raison de contraintes budgétaires, de gestion et d'hébergement de l'équipement, les serveurs Exchange ne disposeraient pas du stockage connecté au réseau SAN (storage area network), tout stockage devait donc être interne ou à connexion directe. La plupart des circonscriptions ne disposant pas de centres de données avec stockage en rack et refroidissement centralisé, les serveurs devaient être aussi autonomes que possible. Par chance, la plupart des circonscriptions comptaient moins de 5 000 utilisateurs ; des déploiements sur un seul serveur étaient donc possibles. Pour les circonscriptions comptant davantage d'utilisateurs, des serveurs plus puissants (voire plusieurs serveurs) et des espaces de stockage supplémentaires ont été utilisés, parfois avec des serveurs frontaux séparés pour pouvoir trier ultérieurement le trafic étudiant du trafic personnel.

Dans la plupart des circonscriptions, nous avons pu déployer des serveurs à deux processeurs bien équipés dont la configuration comprenait le nombre maximal de 15 000 disques RPM Ultra320 SCSI, plusieurs contrôleurs RAID et 4 Go de RAM. Les circonscriptions plus importantes se sont vu dotées d'un serveur à quatre processeurs ou plus, utilisant des serveurs frontaux plus petits si nécessaire. Les tests d'évaluation et de performances avant déploiement n'ont indiqué aucun problème d'utilisation ou de chargement. Cependant, à des degrés divers, les modèles d'utilisation locale constitueraient le véritable facteur déterminant la performance globale du serveur.

Test de validation technique

Même si l'environnement de production contient une forêt Active Directory de 178 domaines, le laboratoire de validation technique (VT) a été réduit à 13 domaines de circonscription et à un domaine racine vide. Tous les domaines de test ont été renseignés avec des exportations provenant des domaines de production. Des serveurs Exchange 5.5 virtuels ont été générés et configurés avec des copies des bases de données de la circonscription sélectionnée afin que nous puissions tester le processus et la création de la migration de l'environnement programmé. Le laboratoire de test de validation technique entier a été construit avec des ordinateurs virtuels de sorte que l'environnement puisse être référencé, figé et redéployé par la suite lorsque nécessaire.

De multiples scripts (à l'aide de VBScript), de packages d'installation Systems Management Server (SMS) et d'applications de console ont été créés, codés, testés et finalisés. Au final, nous avions des scripts qui effectuaient l'installation et la configuration initiales d'Exchange 2003, y compris les stratégies de destinataire, les LAG et les listes d'adresses personnalisées et les autorisations. Les scripts géraient également la configuration du groupe administratif, la configuration du domaine de circonscription (création du groupe de sécurité et délégation des autorisations) et la configuration après déploiement pour la migration.

L'activation des serveurs Exchange 2003 représentait quelques défis importants. Il nous fallait installer correctement tous les serveurs Exchange sur les 178 domaines et le faire de manière à ne pas compromettre le reste de la migration. Exchange 2003 diffère d'Exchange 2000 du fait que le groupe Serveurs de domaine Exchange spécifique aux domaines n'est pas ajouté à l'ACL de l'organisation avant que le premier serveur Exchange 2003 du domaine ne soit installé. (Dans Exchange 2000, le groupe est ajouté lors de l'exécution du processus DomainPrep.) Afin de nous assurer que nous disposions de tous les groupes de sécurité nécessaires répertoriés sur l'objet d'organisation dans Active Directory, il nous fallait effectuer l'installation, dans un domaine donné, copier manuellement Active Directory à partir du domaine vers le site hub de réplication Active Directory, puis tirer cette réplication vers la prochaine circonscription devant être installée. L'installation de la circonscription suivante ne pouvait commencer en toute sécurité qu'une fois que l'on avait confirmé que l'ACL sur l'objet d'organisation avait le groupe Serveurs de domaine Exchange de la circonscription précédente. Si ce processus avait été effectué dans le mauvais ordre ne serait-ce que pour un domaine, cette circonscription aurait dû au minimum être réinstallée ou bien la communication entre d'autres circonscriptions n'aurait pas été possible à cause d'un objet d'organisation ACL ne répertoriant pas toutes les autres circonscriptions correctement.

Nous avons testé la totalité du déploiement, la configuration, l'activation des serveurs et la migration plusieurs fois jusqu'à ce que nous soyons sûrs du bon fonctionnement du processus au sein de l'environnement de VT.

Migration et difficultés grandissantes

Une fois les procédures de VT et les résultats approuvés par l'équipe du projet, la migration pouvait commencer. Les OET avaient choisi d'effectuer leurs propres migrations dans un premier temps afin qu'ils puissent personnellement expérimenter le processus et ses répercussions. Au moment de la migration, tous les serveurs avaient déjà été activés et l'environnement initial avait été vérifié. Tous les serveurs de protocole frontaux étaient en place et prêts à être utilisés.

L'exécution du plan de migration s'est bien passé et, après 21 heures de transfert du contenu d'un serveur à un autre, l'OET était fin prêt et opérationnel sur Exchange 2003. Heureusement, il n'y avait eu aucun problème majeur concernant le passage des profils Outlook d'Exchange 5.5 à Exchange 2003. Nous avons empaqueté un fichier de commande appelant ExProfRe.exe dans différentes configurations sur la base d'une logique simple. Nous avons alors distribué le fichier de commande et ExProfRe.exe au partage Accès réseau d'un contrôleur de domaine dans chaque circonscription et utilisé la stratégie de groupe pour exécuter la commande pour tous les clients à la fin de la migration. Ceci à bien fonctionné pour l'OET et nous étions confiants pour la suite du processus.

À ce niveau, le plan de migration a été revu et réapprouvé en fonction de notre expérience de déploiement avec l'OET. Pour la suite de la migration, nous avons choisi six circonscriptions comme premiers sites de production. Avant la migration de chaque circonscription, le MIIS devait lire les dernières informations concernant les boîtes aux lettres de la circonscription d'Exchange 5.5 et mettre à jour les utilisateurs correspondants dans le domaine de la circonscription. Nous avons utilisé l'Assistant Migration Microsoft Exchange (Mailmig.exe) afin de procéder au déplacement effectif des données de boîte aux lettres entre organisations. Lorsque l'assistant a déplacé les données de boîte aux lettres, toutes les adresses proxy ont été amenées et mises à jour à partir de ce que MIIS avait à l'origine exporté sur Active Directory. Au cours de la migration, la messagerie serait mise en file d'attente dans les serveurs SMTP frontaux, puis distribuée à la circonscription une fois la migration, la configuration des serveurs après migration et les tests utilisateur effectués ; la circonscription était prête à effectuer la migration client à grande échelle avec ExProfRe.exe.

Batailler avec le RUS

Pour que les clients Outlook fonctionnent correctement, nous avions besoin de nous assurer que la solution d'attribution de privilèges constituait l'autorité ultime au niveau de la définition des valeurs d'attributs. Nous avions également besoin que le service de mise à jour des destinataires (RUS) ait fait, pour ainsi dire, son travail d'installation des comptes, mais le RUS ne devait se lancer qu'une fois l'attribution de privilèges d'accès effectuée. Pour ce faire, les instances du RUS pour les 178 circonscriptions étaient définies sur Never (Jamais) et la solution d'attribution de privilèges d'accès utilisait du code qui déclenchait le lancement du RUS une fois l'attribution de privilèges effectuée.

La plupart des circonscriptions comptaient quotidiennement moins de 5 000 utilisateurs et encore moins de mises à jour  ; le RUS s'exécutait donc rapidement puisque le système d'attribution de privilèges lançait une mise à jour au lieu d'une reconstruction à la fin de son exécution quotidienne. Cependant, il y avait plusieurs circonscriptions qui comptaient plus de 10 000 utilisateurs. Les mises à jour dans ces environnements prenaient beaucoup plus de temps et lorsqu'une reconstruction complète d'un RUS était nécessaire pour les grands domaines, le service pouvait s'exécuter pendant une semaine ou plus. Le RUS évaluant tous les types d'objet lorsqu'il s'exécute, le fait d'effectuer une reconstruction dans un domaine aussi grand était affaiblissant.

Bien que nous n'ayons pas pu arriver à une stratégie d'atténuation (et que nous ayons travaillé avec des membres du groupe produit Exchange pour tenter de trouver une solution), nous avons amélioré le code d'attribution de privilèges pour gérer une grande partie des éléments que gère normalement le RUS. Les attributs proxyAddresses et showInAddressBook ont été renseignés pour les utilisateurs après l'attribution de privilèges initiale de sorte qu'ils puissent se connecter immédiatement plutôt que de devoir attendre que le RUS ait achevé sa tâche. Nous avons également créé une tâche manuelle qui s'exécute sur l'un des serveurs de protocole frontaux Exchange 2003. Elle effectue une importation LDIFDE temporisée et efface l'adresse gatewayProxy du RUS de sorte que si une stratégie de destinataire est appliquée par accident dans l'environnement, elle n'est pas placée sur la liste des tâches à effectuer de chaque RUS dans l'organisation.

Problèmes de catégoriseur

L'un des aspects intéressants dans le fait d'empêcher les données des étudiants de sortir de la circonscription scolaire était l'implémentation de contrôles qui empêche les étudiants d'envoyer des messages à des utilisateurs situés en dehors de leur propre circonscription ou vers des adresses Internet situées hors du système. Plutôt que de travailler via un système sophistiqué de connecteurs et d'éléments annexes, nous avons décidé d'implémenter une fonctionnalité moins connue d'Exchange 2003 et d'utiliser des restrictions de connecteur sur le connecteur de groupe de routage existant entre la circonscription et le concentrateur central où se trouvent les serveurs de protocole frontaux. Deux groupes de sécurité ont été créés dans chaque domaine - l'un pour le personnel et l'autre pour les étudiants - et ces groupes ont été ajoutés aux restrictions du connecteur.

Une fois la vérification des restrictions de connecteur activées dans le Registre, nous avons commencé à remarquer quelques problèmes d'affaiblissement des performances. Des messages allaient être bloqués dans le catégoriseur et dans les files d'attentes de distribution locales pendant des heures — y compris les messages destinés à des destinataires sur le même serveur. Ces problèmes ont empiré au fur et à mesure de la migration de circonscriptions supplémentaires. Nous avons établi une solution à court terme en désactivant la vérification des restrictions de connecteur, avec pour résultat l'amélioration des performances de distribution du courrier. Un contrôle plus approfondi révéla que le catégoriseur vérifiait non seulement les appartenances aux groupes des deux groupes de son propre domaine lorsque les messages étaient soumis, mais également les appartenances aux groupes des deux mêmes groupes dans les 177 autres domaines. Cette opération était effectuée pour chaque message entrant ou sortant du serveur.

Suite à cela, nous avons contacté Microsoft pour une prise en charge du problème. Après évaluation, Microsoft est actuellement en train de générer un correctif pour atténuer ce problème en permettant au catégoriseur de travailler selon un mode de complexité de topologie réduit. À la date de publication, nous n'avons pas plus d'informations concernant le correctif, mais l'objectif est de fournir un paramètre qui permette au catégoriseur de formuler certaines hypothèses sur la topologie de routage et de ne pas vérifier l'appartenance aux groupes sur tous les connecteurs.

Retour d'expérience

S'il y a bien une chose que j'ai apprise tout au long de ce projet, c'est que les exigences de fonctionnement régissent tout ce que nous faisons en tant que consultants. À plusieurs reprises, la faisabilité de l'exigence de fonctionnement a dû être mise en balance avec la complexité de la solution. Les décisions et les options que j'ai décrites dans cette rubrique sont celles que nous avons estimé être les plus appropriées compte tenu de notre environnement (qui comprend des éléments dont je n'ai pas eu le temps de parler ici), de nos ressources et de nos exigences de fonctionnement. Vos décisions peuvent s'avérer différentes mais espérons que cette rubrique vous aura apporté quelques éléments de réflexion. Heureusement pour nous, Exchange 2003 et Active Directory nous ont apporté une grande souplesse pour répondre à toutes les exigences de cette migration complexe. Une fois passé le choc du gigantisme du déploiement des services de l'éducation du Kentucky, la solution elle-même est assez simple et est générée à partir des fonctionnalités Active Directory et Exchange 2003 qui pour moi sont sous-exploitées.

La seconde leçon importante à retenir, c'est qu'il faut mettre en pratique une approche équilibrée en ce qui concerne la gestion des pannes et des problèmes ou des risques. Il est parfois approprié de résoudre les pannes en local et parfois nécessaire de faire appel aux ressources avancées des services de support technique de Microsoft.

Perspectives

L'environnement du ministère de l'éducation du Kentucky est certainement unique. Au cours de ce déploiement, presque toutes les fonctionnalités d'Exchange ont été utilisées ou personnalisées pour satisfaire aux exigences des services. Maintenant que l'environnement dans son intégralité a été déployé et a migré correctement, le temps d'implémenter des fonctionnalités supplémentaires est venu. Le ministère de l'éducation a déjà vu l'intérêt des circonscriptions scolaires pour la plate-forme Windows Mobile® et espère que cette tendance pour les outils mobiles va continuer.

La consolidation des serveurs permet une amélioration considérable. Le ministère de l'éducation du Kentucky cherche actuellement à virtualiser certains aspects de l'environnement Active Directory. Et avec la perspective d'Exchange 2007, le ministère a commencé à s'intéresser aux exigences pour la mise à niveau de ses systèmes de messagerie.

Les services de l'éducation du Kentucky étudient également d'autres propositions supplémentaires de collaborations dans Live Communication Server, Live Meeting Server, etc. De plus, Microsoft Operations Manager 2005 est actuellement en cours de déploiement pour la gestion et le contrôle des serveurs Exchange et Active Directory.

Résultats

Chaque enfant scolarisé dans le système scolaire public du Kentucky va pouvoir profiter de la qualité et de la généralisation de cette implémentation — y compris mes propres enfants et les enfants des gens avec lesquels j'ai travaillé sur ce projet. Cette implémentation a plus que jamais positionné les services de l'éducation du Kentucky pour aller plus loin et plus vite en matière de technologie, d'une manière plus sécurisée et standardisée que jamais. Je suis fier d'avoir participé à une telle entreprise.

Whitney Robertsest consultant principal de KiZAN Technologies (www.kizan.com) et travaille avec Exchange depuis la sortie d'Exchange 4.0.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.