Académie Microsoft Exchange Server 2010

 

MODULE 5: Suppression des serveurs Exchange 2003 Article de Damien Caro, Architecte Infrastructure sur les solutions de Communications Unifiées, Microsoft France Son blog : https://blogs.technet.com/dcaro/

Sommaire de l'article

Déplacement des dossiers publics Changement du serveur de génération du carnet d'adresse en mode autonome 57 Modification des connecteurs SMTP Suppression des bases de données privées et publiques Suppression des connecteurs de groupe de routage et du RUS Désinstallation des serveurs Exchange 2003 Conclusion

Téléchargez le module au format Word   Inscrivez vous au Live Meeting du 29 avril pour une bonne suppression des serveurs Exchange 2003

Dans le module 2, nous avons déplacé les boites aux lettres d'un serveur Exchange 2003 vers Exchange 2010 en s'assurant que les clients pouvaient toujours accéder à leurs données.

Avant d'arrêter les serveurs Exchange 2003 nous avons encore quelques opérations à effectuer pour réaliser complètement la migration :

·         Déplacement des dossiers publics vers les serveurs Exchange 2010

·         Changement du serveur de génération du carnet d'adresse en mode autonome pour un serveur Exchange 2010

·         Déplacement des connecteurs SMTP en sortie pour utiliser Exchange 2010

·         Suppression des bases de données privées et publiques sur les serveurs Exchange 2003

·         Suppression du connecteur de groupe de routage et du RUS (Service de mise à jour des destinataires).

Une fois que ces étapes ont été réalisées nous pourrons procéder à la suppression des serveurs Exchange 2003 de l'organisation.

Déplacement des dossiers publics

Le mode de fonctionnement des dossiers publics est celui d'une base de données répartie sur plusieurs serveurs. Nous allons mettre à profit cette particularité des dossiers publics pour la migration vers Exchange 2010.

La migration vers Exchange 2010 peut être l'occasion pour identifier les dossiers publics des utilisateurs candidats à l'archivage.

Lancez la console d'administration des dossiers publics puis pour chaque dossier public ou chaque dossier public parent il faut ajouter un réplica vers le serveur de dossier public en Exchange 2010. Dans notre lab, nous utiliserons le serveur AC-EXCH-1.

Il est alors possible de forcer des horaires de réplication personnalisés ou de conserver les horaires de réplication de la base de données. De même il est possible d'en profiter pour indiquer une limite d'âge des données dans ces dossiers publics. Une modification à ce niveau doit être faite en accord avec la politique de l'entreprise sur la conservation des données dans les dossiers publics.

 

Ces étapes doivent être répétées pour tous les dossiers que vous souhaitez migrer vers Exchange 2010 et pour les dossiers système (dans l'arborescence System Public Folders) :

·         OFFLINE ADDRESS BOOK  (et les sous dossiers)

·         SCHEDULE+ FREE BUSY (et les sous-dossiers)

Ces dossiers sont nécessaires au bon fonctionnement des clients Outlook 2003 ou antérieurs.

Après avoir effectué ces modifications, il faut attendre que les réplications se fassent. Pour vérifier si une réplication a eu lieu vous pouvez utiliser les cmdlets suivants :

Dossiers utilisateurs : Get-PublicFolder –Recurse | Format-List Name,Replicas

Dossiers systèmes : Get-PublicFolder \NON_IPM_SUBTREE –Recurse |Format-List Name,Replicas

Sur la ligne "Replicas" vous devriez voir le serveur Exchange 2010 qui a été configuré à l'étape ci-dessus :

Après avoir effectué cette étape, il faut laisser le temps à tous les dossiers publics de se répliquer correctement d'un environnement à l'autre.

Haut de page

 

Changement du serveur de génération du carnet d'adresse en mode autonome

Le carnet d'adresse en mode autonome est téléchargé par les clients Outlook, il est ensuite utilisé quand le client est déconnecté du serveur pour permettre à l'utilisateur d'avoir un accès restreint à l'annuaire.

L'OAB (Carnet d'Adresse en mode Autonome) est généré par défaut une fois par jour. Il compile l'annuaire global dans un format compressé et le met à disponibilité des clients Outlook. Jusqu'à Exchange 2003, le fichier ainsi généré était copié dans le dossier public système "OFFLINE ADDRESS BOOK" que nous venons de répliquer vers le serveur AC-EXCH-1. A charge des clients de se connecter sur le serveur et de télécharger les mises à jour.

Le processus n'a pas changé avec Exchange 2010, c'est le mode de diffusion qui a évolué. Il est par contre possible diffuser ce fichier via les web-services, permettant ainsi de réduire l'adhésion du système de messagerie aux dossiers publics.

L'opération s'effectue depuis la console d'administration d'Exchange 2010. Clic droit sur l'objet "Offline Address Book" puis move. Il suffit alors de sélectionner le serveur de destination de son choix.

Après avoir effectué le déplacement, il faut activer le mode de distribution par Web-Services :

Après avoir effectué l'opération, pour éviter d'avoir à attendre une journée la génération du carnet d'adresse en mode autonome sur le nouveau serveur, demandez une génération du carnet d'adresse en mode autonome manuellement.

Note : Ne décochez pas l'option "Enable Public Folder distribution" avant que la génération sur AC-EXCH-1 soit terminée. Cela forcerait les clients à télécharger à nouveau la totalité du carnet d'adresse en mode autonome.

Haut de page

Modification des connecteurs SMTP

Dans notre infrastructure de lab, comme dans la plupart des environnements, nous avons un connecteur SMTP servant à la remise des messages vers l'extérieur (ou simplement à simuler cette remise).

Il n'est pas possible de modifier un connecteur SMTP créé avec Exchange 2003. En effet, le connecteur est associé à un groupe de routage et comme nous l'avons vu dans le premier module, les serveurs Exchange 2010 sont dans un groupe de routage spécifique.

La procédure à suivre consiste donc à suivre les étapes suivantes :

·         Créer un nouveau connecteur SMTP pour ne pas perturber le fonctionnement de la messagerie

·         Suppression du connecteur existant sur Exchange 2003

Création d'un nouveau connecteur SMTP

La création du connecteur doit se faire depuis Exchange 2010, soit AC-EXCH-1 dans notre cas. En reprenant la logique de la console d'administration de Exchange 2010, le connecteur est créé au niveau de l'organisation / Hub Transport – puis dans l'onglet Send Connector.

Donnez un nom au connecteur permettant de l'identifier facilement. Dans notre lab, je l'appelle Connecteur Internet et choisissez le type d'usage qui est prévu pour ce connecteur, dans notre cas, c'est le type Internet.

Il faut ensuite définir le serveur qui sert de relais vers l'extérieur si celui existe (si vous utiliser une remise via DNS, il suffit de choisir la première case) :

Et pour terminer, choisir le serveur de transport qui servira de moteur de routage pour ce connecteur. S'il n'y a qu'un seul serveur de transport de disponible (ou joignable au moment de la création du connecteur) dans l'organisation, il sera proposé de façon automatique.

 

Il reste à valider la création du connecteur sur le groupe de routage Exchange 2010.

Dans un environnement de production, il faudra recommencer l'opération pour tous les connecteurs qui existent sous Exchange 2003 (ou en profiter pour consolider les connecteurs).

Dans notre lab, nous nous limitons à un seul connecteur.

Suppression du connecteur SMTP sur Exchange 2003

Avant de procéder aux étapes suivantes, vérifiez que le connecteur sur Exchange 2010 route correctement les messages.

Une fois cette vérification effectuée, vous pouvez lancer le System Manager de Exchange 2003 et supprimer le connecteur.

Haut de page

 

Suppression des bases de données privées et publiques

Avant de désinstaller un serveur Exchange, d'une manière générale, il faut s'assurer que ce dernier ne contient plus de données non accessibles par ailleurs. Cela se traduit techniquement par :

·         Aucunes boites aux lettres sur le serveur

·         Aucun dossier public non répliqué sur un autre serveur

Pour s'assurer que l'on respecte les deux points ci-dessus, nous allons supprimer les bases de données privées et publiques. Depuis Exchange 2003 SP2 (version minimale pour la cohabitation avec Exchange 2010), le gestionnaire système vérifie pour nous ces deux points lors de la suppression d'une base de données.

Suppression des bases de données privées sur AC-EXCH03 et AC-EXCH03-FE

Pour vérifier que cette base de données ne comporte aucune boite aux lettres, nous pouvons regarder les instances dans la base de données depuis le gestionnaire système d'Exchange 2003 ou exécuter le cmdlet powershell suivant :

Get-Mailbox | Where{$_.Database –like "AC-EXCH03\*"} | format-table Name,Alias,ServerName,Database

Le résultat du cmdlet donnera la liste des boites aux lettres encore hébergées sur le serveur Exchange 2003 de note lab.

Dans le cas ci-dessus, il reste la boite aux lettres de l'administrateur sur Exchange 2003.

Après avoir déplacé la boite aux lettres en question, nous pouvons supprimer la base de données des boites aux lettres :

Si vous le souhaitez, vous pouvez supprimer le fichier associé à la base de données sur le serveur.

Suppression des bases de données publiques sur AC-EXCH03 et AC-EXCH03-FE

Dans la première étape de ce module nous avons mis en place un réplica des données depuis AC-EXCH03 vers AC-EXCH-1 (Exchange 2010).

Il est nécessaire que les deux répliques de dossiers publiques soient synchronisées avant de commencer cette étape sous peine de perdre des données.

Suppression des répliques sur Exchange 2003

Pour commencer, pour chacun des dossiers publics, il faut supprimer la réplique qui existe sur Exchange 2003 en ne laissant dans la liste des réplicas que la réplique sur Exchange 2010 :

Cette opération est à faire encore une fois sur tous les dossiers publics de l'organisation (utilisateurs et systèmes). Encore une fois, il faudra être patient pour que la modification soit répliquée sur l'ensemble des serveurs de dossiers public de l'organisation.

Astuce : Le redémarrage du service "Microsoft Exchange Information Store" déclenche une demande de mise à jour des informations des dossiers publics. C'est un moyen en environnement de test de réduire le temps de ces opérations associées aux dossiers publics.

Suppression des bases de données de dossiers publics

Lorsque les répliques ont été mise à jour, le conteneur "Public Folders Instances" dans le gestionnaire système d'Exchange 2003 doit être vide comme ceci :

Avec Exchange 2003 SP2, c'est la seule situation à partir de laquelle le gestionnaire système vous laissera supprimer une base de données de dossiers publics.

La procédure à suivre est alors presque la même que pour la banque d'information privée avec le changement suivant. Si la banque de dossier publique est encode identifie comme utilisée pour l'un de ces rôles :

·         Base par défaut d'une base de données privée

·         Utilisée pour les dossiers systèmes d'un groupe administratif

·         Pour le carnet d'adresse en mode autonome

Alors vous aurez ce message vous invitant à choisir une autre base de dossiers publics :

Dans notre cas, si les étapes précédentes se sont bien passées, nous pouvons ignorer ce message mais toutefois sélectionner une base de dossiers publics de remplacement pour terminer l'assistant.

Il faut répéter cette opération sur l'ensemble des bases de données de dossiers publics de l'organisation.

Note : Il y a d'autres éléments à prendre en considération dans un environnement de production comme par exemple procéder à un nettoyage des recipient policies.  Tous ces éléments sont adressés dans la procédure disponible à cette adresse : https://technet.microsoft.com/en-us/library/bb288905.aspx

 

Haut de page

Suppression des connecteurs de groupe de routage et du RUS

Dans le cas de notre académie, nous allons supprimer les derniers serveurs Exchange 2003 de l'organisation, ce point, que vous rencontrez à un moment ou un autre dans vos environnements de production, nous amène à procéder aux étapes suivantes :

·         Suppression des connecteurs de groupe de routage

·         Suppression du RUS – Recipient Update Service

Suppression du connecteur de groupe de routage

Lors de l'installation du premier serveur Exchange 2010 de l'organisation, le système a créé un groupe de routage spécifique pour mettre tous les serveyrs Exchange 2010 de l'organisation. Ce groupe de routage est connecté avec le groupe de routage de son choit lors de l'installation. Avant de pouvoir désinstaller le dernier Exchange 2003 de l'organisation, il faut supprimer ce connecteur de groupe de routage.

Il suffit de supprimer l'objet dans chacun des groupes de routage présents :

Une fois le connecteur supprimé des deux coté, il reste à supprimer le RUS de l'organisation.

Suppression du RUS

Le RUS – Recipient Update Service – est utilisé par Exchange 2003 pour l'application des politiques de d'adresses de messagerie sur les utilisateurs. C'est le délai d'exécution de ce dernier qui est en cause dans le cas d'une lenteur avant de pouvoir se connecter à sa boite aux lettres pour la première fois.

Il existe au moins deux instances du RUS dans une organisation Exchange 2003 : le RUS du domaine pour appliquer une politique d'adresses de messagerie et le RUS de l'entreprise pour appliquer les politiques d'entreprise.

Avant de désinstaller le dernier serveur Exchange 2003 de l'organisation, il faut avoir supprimé ces deux instances. L'instance associée à l'organisation Exchange est facile à supprimer, il suffit de faire un clic droit sur l'objet en question comme ceci :

Par contre, pour la suppression de l'instance associée à l'entreprise, il est nécessaire de lancer Adsiedit. Adsiedit est installé en installant les outils de support disponibles sur le CD de Windows 2003 dans le répertoire support.

La suppression se fait en ouvrant le conteneur suivant :
"CN=Address Lists Container,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ucdemo,DC=fr"

Ensuite sélectionnez le conteneur "CN=Recipient Update Services".

Supprimer l'objet qui se trouve dans la fenêtre de droit qui s'appelle "CN=Recipient Update Service (Entreprise Confguration)".

Une fois ces deux instances de RUS supprimées de l'environnement, le dernier serveur Exchange 2003 de l'organisation n'est plus lié à aucun élément présent dans Active Directory, il est possible de le désinstaller.

Désinstallation des serveurs Exchange 2003

C'est la dernière étape !

Nous allons procéder dans l'ordre suivant :

1.       Désinstallation des serveurs Frontaux

2.       Désinstallation des serveurs Dorsaux

La procédure de désinstallation se lance depuis le panneau de configuration du serveur dans les options "Add/Remove Programs" et en choisissant "Exchange Server" :

Le processus va prendre quelques minutes pendant lesquelles les services de Windows modifiés lors de l'installation par Exchange 2003 (SMTP, IIS …) seront arrêtés.

Note : A la fin de la procédure, il faut redémarrer le serveur.

Dans le cas d'un serveur en exploitation, il est recommandé de réinstaller un nouveau système d'exploitation avant d'installer une nouvelle application serveur.

Au redémarrage, l'organisation ne contient plus aucun serveur Exchange 2003 !

Conclusion

Ce dernier module nous a permis de finaliser notre procédure de migration de Exchange 2003 à Exchange 2010.

Nous avons réalisé les étapes suivantes :

·         Déplacement des dossiers publics en utilisant leur mécanisme de réplication

·         Déplacement du serveur de génération du carnet d'adresse en mode autonome et mise à jour du mode de distribution

·         Déplacement des connecteurs de routage des mails vers l'extérieur de l'organisation

·         Suppression des bases de données privée et publiques

Les étapes de migration qui ont été suivies ici avaient pour but de vous aider à appréhender la migration vers Exchange 2010 depuis Exchange 2003 dans son ensemble. Ce document n'a pas vocation à remplacer la documentation officielle du produit sur Technet mais bien à vous donner les premiers éléments pour savoir la lire. Nous

Ces étapes de finalisation sont importantes et doivent être vues comme une succession de "mini-projets". C'est souvent dans ces étapes que l'on peut perdre le plus de temps et où une erreur peut avoir l'impact le plus important. Il est crucial de bien préparer ces dernières étapes accompagnant la migration.

 

Haut de page