Présentation des architectures et scénarios de tests Projet 2005 Présentation des architectures et scénarios de tests Migration d’un domaine NT4 vers un Active Directory (2000 ou 2003) Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les architectures de tests Projet 2005 Projet 2005 Les architectures de tests Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les architectures de tests Projet 2005 Projet 2005 Les architectures de tests Évaluation de l’existant en terme matériel : Si le contrôleur de domaine principal de l’entreprise est capable de supporter les charges imposées par Windows 2003 la migration pourra s’effectuer sans changements de matériels. En revanche, si le contrôleur de domaine principal n’est pas en mesure de faire fonctionner Windows 2003, il faudra promouvoir un contrôleur de domaine capable de supporter ce système d’exploitation, puis de le hisser au rang de contrôleur principal de domaine pour poursuivre la migration. Nous pouvons également envisager un cas de figure où aucun des contrôleurs de domaines n’est capable de supporter Windows 2003, il faudra alors installer un contrôleur de domaine de secours sur un serveur capable de le supporter, puis d’affecter à ce dernier les droits de contrôleur de domaine principal. Afin de ne pas perdre le matériel utilisé il pourrait être intéressant de mettre en place des serveurs dits de Roll Back, qui permettront à tout moment un retour en arrière si la migration venait à dysfonctionner. Pour finir, il faudra vérifier si le contrôleur principal de domaine fait fonctionner d’autres services auquel cas une mise à jour ou une migration de ces derniers sur d’autres serveurs s’imposera avant le passage du contrôleur principal de domaine vers Windows 2003. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les architectures de tests Projet 2005 Projet 2005 Les architectures de tests Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les architectures de tests Projet 2005 Projet 2005 Les architectures de tests Evaluation de l’existant en terme logiciel Seules les versions Windows NT 4.0 serveur édition standard et Terminal serveur peuvent être migrées directement vers Windows 2003 serveur, cependant il est nécessaire que ces dernières soient dotées du service Pack 5. Il est important de notifier que la réinstallation d’applications fonctionnant sur ces plateformes n’est pas nécessaire à la seule condition que ces dernières soient compatibles Windows 2003 serveur. Si le parc informatique de l’entreprise comporte des serveurs dotés de systèmes d’exploitation tels que Windows NT 3.51 ne pouvant pas être migrés vers Windows 2003 serveur, il est indispensable de réaliser une des deux actions suivantes : Si l’entreprise a l’obligation de conserver les applications fonctionnant sur ces serveurs, elle doit alors impérativement vérifier leur compatibilité sous Windows 2003 serveur. Si ces dernières le sont, il faut alors migrer le système d’exploitation vers un système d’exploitation pouvant être directement mis à jour pour Windows 2003 serveur. Si l’entreprise peut se passer des applications situées sur ces ordinateurs, il est conseillé d’effectuer une installation propre de Windows 2003 serveur sur ces derniers. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les architectures de tests Projet 2005 Les architectures de tests Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les scénarios de tests Vue d’ensemble Projet 2005 Les scénarios de tests Vue d’ensemble Le scénario de migration d’Active Directory suppose que vous avez seulement besoin de migrer les comptes utilisateurs vers un autre domaine dans la même ou dans une forêt différente d’Active Directory. Le scénario de migration d’Active Directory est schématisé dans la figure suivante: Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les scénarios de tests Projet 2005 Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les scénarios de tests Pre-migration Activities Projet 2005 Les scénarios de tests Pre-migration Activities Préparer l’environnement source et cible pour la migration. Etablir les règles entre chaque domaine source et cible. Vous pouvez tirer bénéfice en utilisant les possibilités de Trust Migration dans le Gestionnaire de Migration, qui vous permettra de copier les règles que le domaine source a avec d’autres domaines vers le domaine cible. Pour plus de détails sur les règles de migration, référez vous à la section Pre-migration Activities > Trust Migration de ce document. Migrer les objets du site pour maintenir la même configuration de site pour l’environnement cible. Utilisez les possibilités de Site Migration dans le Gestionnaire de Migration de sites. Pour plus de détails sur la migration de site, referez vous à la section Pre-migration Activities > Site Migration de ce document. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les scénarios de tests Migration Projet 2005 Les scénarios de tests Migration Établissez la synchronisation d'annuaire entre la source et les domaines cibles pour vous assurer que les propriétés des comptes, y compris les mots de passe et les membres des groupes, et que tous les comptes migrés sont maintenus en synchro pendant la période de coexistence. Si cette dernière est courte, vous pouvez passer cette étape. Notez que la synchronisation n’est pas disponible pour les migrations intra-forest d’Active Directory. Référez vous à la section Active Directory Migration > Directory Synchronization de ce document. Migrer des comptes de domaines sources vers des domaines cibles. Référez vous à la section Active Directory Migration > Accounts Migration de ce document. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les scénarios de tests Mise à jour de ressources Projet 2005 Les scénarios de tests Mise à jour de ressources Traitez les ressources distribuées, telles que les postes de travail d'utilisateur, les serveurs de fichiers et d'impression, et les serveurs d'application, en utilisant la ressource mettant à jour l’annuaire. Referez vous à la section Resource Update de ce document. Quand les postes des utilisateurs sont mis à jour, les profils utilisateurs devront aussi être mis à jour, ainsi les utilisateurs migrés auront les même profils que les utilisateurs source correspondant quand ils se logueront sur le domaine cible pour la première fois. Referez vous à la section Resource Update > User Profiles Update de ce document pour plus de details. Traitez les serveurs BackOffice, tels qu’Exchange, SQL, et les serveurs SMS, en utilisant l’assistant. Referez vous à la section Resource Update de ce document. Déplacer le serveur vers le domaine cible. Referez vous à la section Resource Update > Moving Computers to a Target Domain de ce document. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les scénarios de tests Projet 2005 Post-migration Activities Arrêtez et désinstallez les agents de synchro d’annuaire. Referez vous à la section Active Directory Migration > Directory Synchronization de ce document. Désactivez les comptes source. Nous vous recommandons d’attendre quelque temps après la désactivation des comptes avant de passer à l’étape suivante pour être sûr que tous les utilisateurs utilisent le compte cible. Referez vous à la section Post-migration Activities > Disable Source Accounts de ce document. Nettoyez l’historique des attributs SID des comptes cible. Après cette étape, attendez quelque temps pour être sûr que tous les utilisateurs cible peuvent acceder aux ressources qu’ils utilisaient avant la migration. Referez vous à la section Post-migration Activities > Cleanup SIDHistoryAttributes de ce document. Nettoyez l’heritage des permisions aux ressources. Notez qu’après le nettoyage il est difficile de revenir en arrière. Il est recommandé que vous nettoyez les permissions seulement si vous êtes sûr que tous les utilisateurs Utilisent leur compte cible pour les applications et n’ont pas de problemes d’acces aux ressources. Referez vous à la section Post-migration Activities > Cleanup Legacy Accounts Permissions de ce document. Désarmés les environnements migrés. Referez vous à la section Post-migration Activities > Decommission Migrated Environments de ce document. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les scénarios de tests Choix de tester les trois points suivants: Projet 2005 Les scénarios de tests Choix de tester les trois points suivants: Accès à tout moment, aux ressources utilisateurs et applications. Restructuration des groupes (utilisateur ou service). Possibilité de retour en arrière. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN

Les scénarios de tests Les trois configurations suivantes : Projet 2005 Les scénarios de tests Les trois configurations suivantes : Conditions idéales : peu de services activés, peu de comptes utilisateurs, et l’environnement est à jour. Conditions réelles : l’environnement NT 4 n’est pas mit à jour, quelques services sont activés (spool, web, etc.), nombreux comptes utilisateurs, et plusieurs serveurs. Conditions difficiles : l’environnement NT est antérieur à la version 4, un très grand nombre de services actifs, de comptes utilisateurs et de serveurs (voir plusieurs contrôleurs de domaines). Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VANDERSARREN