Salut à tous
Je travaille actuellement sur une migration AD 2003 / Exchange 2003 vers AD 2008 / Exchange 2007. Ce type de projet étant très complexe, je commence toujours par une maquette complète de la migration la plus fidèle possible de l’environnement de production.
Cet article a pour but d’expliquer comment réaliser une maquette très proche de l’environnement de production sans (trop) perturber la production.
QUELQUES ELEMENTS THEORIQUES :
1. Toute la configuration d’Exchange 2000 / 2003 / 2007 (sauf pour le rôle Transport Edge d’Exchange 2007) se trouve dans la partition de configuration d’Active Directory.
* Chemin LDAP configuration Exchange avec une forêt MSREPORT.FREE.FR : CN=Microsoft Exchange, CN=Services, CN=Configuration,DC=MSREPORT,DC=FREE,DC=FR
Si l’on dispose d’un contrôleur de domaine, on peut donc restaurer la configuration d’Exchange.
2. Une machine virtuelle, du point de vue de ma machine physique (serveur de virtualisation), c’est des fichiers. On peut donc faire un clone de cette machine par un simple copier / coller (enfin il y a quelques règles à respecter).
PRE-REQUIS DE LA MAQUETTE :
1. Un serveur avec 8 Go de mémoire et environ 200 Go d’espace disque supportant un des outils de virtualisation suivant :
* Vmware Server : ce produit est gratuit mais peut être installé sur tout type de matériel. A utiliser si le serveur de maquette n’est pas compatible XenServer / Hyper-V / Vmware car Windows 2008 n’est pas supporté sur ce type d’environnement de virtualisation.
* XenServer 5.X : ce produit est gratuit et mais n’est supporté que sur certains serveurs.
Pour plus d’informations, voir http://hcl.xensource.com.
* Vmware ESX 3.5i / 4i. ce produit est gratuit mais n’est supporté que sur certains serveurs. Pour plus d’informations, voir :
http://www.vmware.com/resources/compatibility/pdf/ vi_systems_guide.pdf
* Hyper-V : nécessite une licence Windows 2008 / une machine supportant IntelVT / AMD-V. Pour rappel, Windows 2008 Server est supporté sur Hyper-V, XenServer 5.X et Vmware 3.5 U2 à travers le SVVP :
http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpsupport.htm
2. Une sauvegarde de l’Etat du système de tous vos contrôleurs de domaine avec NTBACKUP ou un outils de sauvegarde supportant la sauvegarde de l’Etat du Système.
3. Un certain niveau de compétence. Il s’agit d’une procédure complexe qui peut générer de gros problèmes de production si elle est mal exécutée. Ces informations vous sont donnés sans aucune garantie.
PRESENTATION DE L’ENVIRONNEMENT DE PRODUCTION :
* Je pars du principe que vous disposer d’une forêt avec 2 domaines et un serveur Exchange 2003 Server SP2 installé dans le domaine racine.
* Chaque domaine est géré par deux contrôleurs de domaine Windows 2003 Server X32 SP2.
PROCEDURE CREATION D’UNE MAQUETTE :
ETAPE 1 : VIRTUALISATION DES CONTRÔLEURS DE DOMAINE :
Je vous arrête tout de suite. PAS DE P2V DE CONTRÔLEUR DE DOMAINE !
Cela ne marche pas bien surtout quand on veut récupérer plusieurs contrôleurs de domaine qui doivent pouvoir répliquer par la suite. Pour plus d’informations, voir :
http://support.microsoft.com/kb/875495/en-us
http://www.vmware.com/files/pdf/Virtualizing_Windows _Active_Directory.pdf
Si vous disposer de contrôleur de domaine sous forme de machines virtuelles :
* FAIRE UNE SAUVEGARDE DE L’ETAT DU SYSTEME (AVEC NTBACKUP ou votre outils de diagnostics) DE TOUS VOS CONTRÖLEURS DE DOMAINE.
* Définir ces deux serveurs comme serveurs DNS et serveurs de Catalogue. Un contrôleur de domaine peut être Mâitre d’Infrastructure et serveur de Catalogue Global si tous les DC sont serveurs de Catalogue global.
http://support.microsoft.com/kb/324801/en-us
http://support.microsoft.com/kb/223346/en-us
* Arrêter un des contrôleurs de domaine dans chaque domaine et copier ces deux contrôleurs de domaine en copiant les fichiers de la machine virtuelle (VM) correspondante sur le serveur de tests. Il faut arrêter les deux contrôleurs de domaine en même temps ! A faire si vous disposez de plusieurs contrôleurs de domaine pour chaque domaine. Attention, cela peut avoir de l’impact sur Exchange, car ce dernier s’appuie sur certains contrôleurs de domaine (DS Access). Cela est encore plus problématique si les DS ACCESS ont été forcés. Pour plus d’informations, voir :
http://searchexchange.techtarget.com/news/article/ 0,289142,sid43_gci1119795,00.html
http://support.microsoft.com/kb/910999
* Dès que la copie des deux contrôleurs de domaine (un pour le domaine racine et un pour le domaine enfant) est terminée, redémarrer les contrôleurs de domaine de production (la version originale). Ne redémarrer surtout pas la copie des 2 deux contrôleurs de domaine (VMs) à ce moment.
* Configurer les machines virtuelles dupliquées pour démarrer DANS UN ENVIRONNEMENT RESEAU ISOLE. Si vous ne savez pas faire cela, vous arrêter tout de suite !
* Pour les amateurs de Vmware, créer un nouveau vSwitch et lui affecter aucune carte réseau physique. Mapper la carte réseau des deux machines virtuelles dans ce vSwitch.
Avec Hyper-V / XenServer, créer un réseau interne et configurer la carte réseau des deux machines virtelles dans ce réseau Interne.
Avec Vmware Server, mapper les deux machines sur le VMNET 2. Par défaut ce VMNET n’est pas connecté à une carte physique.
Pour les autres (ceux qui disposent que de contrôleurs de domaine sous forme de VM dans leur environnement de production) :
* Installer la solution de virtualisation sur votre serveur de tests.
* FAIRE UNE SAUVEGARDE DE L’ETAT DU SYSTEME (AVEC NTBACKUP ou votre outils de diagnostics) DE TOUS VOS CONTRÖLEURS DE DOMAINE.
* Créer deux nouvelles machines virtuelles sous Windows 2000 / 2003 / 2008 (selon la version de votre annuaire).
* Appeler ces machines DCROOTTEMP et DCCHILDTEMP.
* Faire un DCPROMO sur DCROOTTEMP et ajouter cette machine en tant que contrôleur de domaine supplémentaire dans le domaine MSREPORT.FREE.FR. Valider que la réplication est fonctionelle et que NTFRS a répliqué (attendre au minimum 30 minutes). Utiliser l’outil DCDIAG et valider dans les observateurs d’événements que vous ne rencontrez pas d’erreurs.
* Faire un DCPROMO sur DCCHILDTEMP et ajouter cette machine en tant que contrôleur de domaine supplémentaire dans le domaine CHILD.MSREPORT.FREE.FR. Valider que la réplication est fonctionelle et que NTFRS a répliqué (attendre au minimum 30 minutes). Utiliser l’outil DCDIAG et valider dans les observateurs d’événements que vous ne rencontrez pas d’erreurs.
* Définir ces deux serveurs comme serveurs DNS et sevreurs de Catalogue.
* Ne transférer pas les rôles FSMO sur les serveurs de la maquette. On forcera leur transfert sur la maquette avec NTSUTIL.
* Arrêter DCROOTTEMP et DCCHILDTEMP et copier ces deux contrôleurs de domaine en copiant les fichiers de la machine virtuelle (VM) correspondante sur le serveur de tests. Il faut arrêter les deux contrôleurs de domaine en même temps ! Normalement vous disposez de plusieurs contrôleurs de domaine dans chaque domaine. Attention, cela peut avoir de l’impact sur Exchange, car ce dernier s’appuie sur certains contrôleurs de domaine (DS Access). Cela est encore plus problématique si les DS ACCESS ont été forcés. Pour plus d’informations, voir :
http://searchexchange.techtarget.com/news/article/ 0,289142,sid43_gci1119795,00.html
http://support.microsoft.com/kb/910999
* Redémarrer les version originale de DCROOTTEMP et DCCHILDTEMP qui sont des serveurs de production et faire un DCPROMO inverse sur ces deux contrôleurs de domaine (attendre environ 30 minutes voir plus entre chaque DCPROMO inverse pour que les objets connexions se regénèrent correctement).
* Configurer les machines virtuelles dupliquées pour démarrer DANS UN ENVIRONNEMENT RESEAU ISOLE. Si vous ne savez pas faire cela, vous arrêter tout de suite !
* Pour les amateurs de Vmware, créer un nouveau vSwitch et lui affecter aucune carte réseau physique. Mapper la carte réseau des deux machines virtuelles dans ce vSwitch.
Avec Hyper-V / XenServer, créer un réseau interne et configurer la carte réseau des deux machines virtelles dans ce réseau Interne.
Avec Vmware Server, mapper les deux machines sur le VMNET 2. Par défaut ce VMNET n’est pas connectée à une carte physique.
Faire ensuite un DCPROMO inverse
Remarque :
* IL NE FAUT SURTOUT PAS QUE LES VM DE L’ENVIRONNEMENT DE TESTS PUISSENT COMMUNIQUER AVEC L’ENVIRONNEMENT DE PRODUCTION. Si cela arrive, vous allez générer un désynchronisation des USN et à terme aucune des deux copies du contrôleurs de domaine en cause ne pourra plus communiquer avec les autres :
http://support.microsoft.com/kb/875495/en-us
* Le contrôleur de domaine dupliqué doit être de préférence un serveur DNS si vous voulez récupérer les zones DNS. Pou rappel les zones DNS de la ForestDnsZones / DomainDnsZones ne sont répliquées que sur les contrôleurs de domaine qui sont serveurs DNS.
ETAPE 2 : NETTOYAGE DE L’ANNUAIRE :
Il faut en effet supprimer les contrôleurs de domaine qui n’ont pas été supprimés et transférer (mode forcé) si nécessaire les rôles FSMO.
En effet c’est comme si on avait fait un DCPROMO / FORCEREMOVAL des contrôleurs de domaine qui n’ont pas été copiés.
Pour cela, on va utiliser NTDSUTIL et appliquer les procédure ci dessous :
http://support.microsoft.com/kb/255504/en-us
http://support.microsoft.com/kb/216498/en-us
http://support.microsoft.com/kb/230306
http://support.microsoft.com/kb/887424/fr
J’ai rencontré quelques erreurs assez sympatiques en faisant l’adprep /rodcprep car je n’avais pas reconfiguré les partitions DomainDnsZones qui utilisaient encore l’ancien Maître d’Infrastructure (un ancien contrôleur de domaine de l’environnment de production que je n’ai pas copié au niveau de la maquette). Voir article :
http://support.microsoft.com/kb/949257/en-us
ETAPE 3 : RESTAURATION DU SERVEUR EXCHANGE :
* On va maintenant restaurer notre serveur Exchange 2003 en utilisant la commande setup.exe /Disasterrecovery.
* Il ne faudra pas oublier d’installer tous les correctifs / service packs Exchange installés sur le serveur Exchange en mode DisasterRecovery.
* Utiliser l’Exchange Best Practice Analyser pour valider le bon fonctionnement de votre serveur Exchange. Cet outil va par exemple vous remonter si vous avez une version des binaires plus ancienne que la version d’Exchange 2003 (celle inscrite dans la partition de configuration). Cela peut arrivé si votre serveur de production est en SP2 et que vous n’avez utilisé un CD d’installation SP0 ou SP1 pour faire la restauration d’Exchange 2003 en mode Diaster Recovery. Il faut alors installer le SP2 d’Exchange en mode Disaster Recovery : http://www.microsoft.com/downloads/details.aspx?displaylang=fr& FamilyID=dbab201f-4bee-4943-ac22-e2ddbd258df3
* Une fois cela effectué, il faut reconfigurer les DSACCESS et le serveur RUS pour utiliser des contrôleurs de domaine qui existe encore dans l’environnement de tests.
http://searchexchange.techtarget.com/news/article/ 0,289142,sid43_gci1119795,00.html
http://support.microsoft.com/kb/910999
* Si vous n’avez pas restaurer toutes les bases de données, vous ne voyez plus les boîtes aux lettres de ces bases. Dans ce cas, monter les bases de données. Cela va générer une base vierge. Envoyer un mail à tous les utilisateurs de cette base. Cela va regénérer toutes les boîtes aux lettres. En effet, une boîte aux lettres n’est générée sur le serveur Exchange que quand un utilisateur se connecte à la boîte aux lettres ou quand elle reçoit un mail.
* Je vous conseille de restaurer la banque de dossier publics car les dossiers publics sont assez complexes à migrer.
* Restaurer aussi les bases de données dans la mesure du possible pour valider qu’il n’y a pas de problème de boîtes aux lettres corrompus.
Pour plus d’informations :
http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=a58f49c5-1190-4fbf-aede-007a8f366b0e
http://www.msexchange.org/tutorials/Recovering-Failed-Exchange-2003-Member-Server-Using-Disaster-Recovery-Switch.html
Vous disposez maintenant d’un environnement de tests pour valider votre migration.
Penser à le sauvegarder car c’est long à créer. Ajouter aussi quelques stations de travail Windows XP 2000 / XP / Linux avec votre client mail d’entreprise pour tester.
a+
