8. Astuces concernant les Service Packs Exchange

de la base de données Exchange avant et après l’installation des Service Packs, en vérifiant les autorisations et en testant les mises à jour dans un environnement de test en cluster avant de les déployer en production.

Application du dernier Service Pack.

Comme je l’indique dans cet article, il n’existe encore aucun Service Pack pour Exchange 2003. Concernant les clusters exécutant Exchange 2000, le Service Pack 3 (SP3), téléchargeable à l’adresse http://www.microsoft.com/exchange/downloads/ 2000/sp3/default.asp, intègre plus de 400 corrections d’erreurs. La fragmentation de la mémoire virtuelle constitue un problème majeur pour les organisations Exchange de grande taille, en particulier si elles comportent un grand nombre de clients MAPI. Le SP3 inclut une version actualisée de la Banque d’informations (store.exe) afin d’aider à résoudre ce problème. Ce Service Pack comporte également plusieurs corrections spécifiques aux clusters, comme les articles Microsoft suivants l’expliquent : « XCON: Cluster Failover Process Is Delayed Because of Message Transfer Agent Remote Procedure Call Timeouts » (http://support.microsoft. com/? kbid=316354 ), « XCON: Messages Back Up in Queue When the Virtual Server Is Set to Forward All Messages with Unresolved Recipients » (http://support.microsoft.com/?k bid=316204 ), « XADM: Custer Service Terminate Function Does Not Kill the Information Store Unless It Times Out » (http://support.microsoft.com/?kbid =322126 ) et « XADM: The Information Store Stops on a Cluster Because of the IsAlive Check » (http://support.microsoft. com/?kbid=315 771 ).

Exécution de sauvegardes complètes.

Effectuez des sauvegardes complètes de votre serveur Exchange avant et immédiatement après l’installation d’un Service Pack Exchange. Mettez de côté les bandes ne faisant pas partie du cycle de sauvegarde normal. Les Service Packs Exchange comportent fréquemment une version actualisée de store.exe. Lorsque vous remontez les bases de données Exchange après l’application d’un Service Pack, ce dernier met à jour les bases de données afin qu’elles fonctionnent avec le nouveau code binaire du service Store. Les différences de versions de ce service signifient qu’il est impossible de revenir à une sauvegarde réalisée sur un Service Pack antérieur. Par exemple, vous ne pouvez pas restaurer sur un serveur avec SP3 une sauvegarde effectuée alors que le serveur utilisait le SP2. (L’article Microsoft « XADM: Exchange 2000 SP2 Does Not Allow You to Restore Exchange 2000 or Exchange 2000 SP1 », à l’adresse http://support.microsoft. com/?kbid=316794 , contient certaines informations générales sur les scénarios de conflits de versions de la Banque d’informations.) Veillez à mettre à jour vos serveurs de récupération après sinistre et les procédures afin de prendre en compte les modifications apportées par les Service Packs Exchange.

Vérification des autorisations.

Comme je l’ai expliqué dans la 1ère partie, vous devez avoir les autorisations d’administrateur intégral Exchange (Full Administrator) pour mettre à jour un cluster Exchange 2000. L’application des Service Packs peut toutefois entraîner la réinitialisation des autorisations à leur valeur par défaut. Avant et après l’application d’un Service Pack, vérifiez les autorisations au niveau du groupe d’administration dans lequel votre EVS réside. (Par défaut, Exchange System Manager [ESM] n’affiche pas les paramètres de sécurité. Pour activer l’onglet Security, ajoutez l’entrée REG_DWORD ShowSecurityPage à la sousclé de registre HKEY_CURRENT_USER\Software\Microsoft\ Exchange\ExAdmin et définissez la valeur 1 pour l’entrée.) Test des mises à jour. Mettez en place un environnement de test parallèle afin de pouvoir tester les Service Packs, correctifs à chaud et tous les produits tierce partie avant de les déployer en production. (De nombreux produits de tiers ne sont pas pris en charge sur les clusters et ils requièrent certaines personnalisations afin de fonctionner correctement.) La reproduction exacte de votre configuration de production peut ne pas être très économique, mais vous pouvez envisager un cluster de test qui fait appel à une technologie de serveur virtuel, telle que VMware pour les tests des produits tierce partie. Les applications tierce partie compatibles avec les clusters créent des ressources de cluster au niveau de la console Cluster Administrator. Il est possible de les déplacer d’un noeud à l’autre lors des opérations de basculement. Toutefois, pour les produits tierce partie qui ne créent pas de ressources de cluster, assurez-vous que vous pouvez les arrêter et les démarrer automatiquement sur les noeuds du cluster lors des opérations de basculement et de restauration. L’un des avantages de l’utilisation des clusters avec Exchange est la possibilité des mises à jour tournantes afin de réduire les temps d’arrêt pour les utilisateurs finaux. Une mise jour tournante implique de déplacer l’EVS vers un noeud et d’effectuer l’installation sur le noeud passif, puis de restaurer le cluster et de mettre à jour l’autre noeud. Supposons, par exemple, que vous ayez un cluster à deux noeuds, le noeud 1 étant le noeud actif avec un EVS (EVS1) et le noeud 2 jouant le rôle du noeud passif, sans ressource de cluster active. Commencez par sauvegarder le noeud 2. Appliquez ensuite le Service Pack et déplacez EVS1 sur celuici. Vérifiez la présence d’erreurs au niveau du journal Application et vérifiez qu’Exchange démarre correctement sur le noeud 2. En supposant que tout se déroule normalement, sauvegardez le noeud 1 et appliquez le Service Pack sur celui-ci. Redéplacez EVS1 vers le noeud 1, vérifiez la présence d’erreurs au niveau du journal Application, puis vérifiez qu’Exchange démarre correctement sur ce noeud. Effectuez une sauvegarde complète du cluster, y compris l’état du système sur chaque noeud et les bases de données Exchange.