La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Présentation des architectures et scénarios de tests

Présentations similaires


Présentation au sujet: "Présentation des architectures et scénarios de tests"— Transcription de la présentation:

1 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 VENDERSAREN

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

3 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 VENDERSAREN

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

5 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 VENDERSAREN

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

7 Les scénarios de tests Overview
Projet 2005 Les scénarios de tests Overview The Active Directory migration scenario assumes you only need to migrate user accounts to another domain in the same or a different Active Directory forest. Exchange Server is either not installed in the source forest, or for some reason you do not want to migrate Exchange data to the target. Active Directory Migration scenario is schematically shown in the figure below: Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VENDERSAREN

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

9 Pre-migration Activities
Projet 2005 Les scénarios de tests Pre-migration Activities 1) Prepare the source and target environments for migration. Refer to the Quest Migration Manager Quick Start Guide. 2) Establish trusts between each source or target domain you want to migrate. You can benefit from using the Trust Migration capability in Migration Manager, which allows you to copy the trusts that the source domain has with other domains to the target domain. For more details on trust migration, refer to the Pre-migration Activities > Trust Migration section of this document. 3) Migrate site objects to maintain the same site configuration for the target environment. Us thee Site Migration capability in Migration Manager to migrate sites. For more details on site migration refer to the Pre-migration Activities > Site Migration section of this document. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VENDERSAREN

10 Les scénarios de tests Projet 2005 Migration
4) Establish directory synchronization between the source and target domains to ensure that account properties, including passwords and group membership, for all migrated accounts are kept in sync during the co-existence period. If the coexistence period is short, you may skip this step. Note that synchronization is not available for intra-forest Active Directory migrations. Refer to the Active Directory Migration > Directory Synchronization section of this document. 5) Migrate accounts from the source to the target domains. Refer to the Active Directory Migration > Accounts Migration section of this document. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VENDERSAREN

11 to a Target Domain section of this document.
Projet 2005 Les scénarios de tests Resource Update 6) Process distributed resources, such as end-user workstations, file and print servers, and application servers, using Resource Updating Manager. Refer to the Resource Update section of this document. When user workstations are updated, user profiles should also be updated, so the migrated users will get the same profile as the corresponding source users when they log on to the target domain for the first time. Refer to the Resource Update > User Profiles Update section of this document for more details. 7) Process BackOffice servers, such as Exchange, SQL, and SMS Server, using the corresponding processing wizards. Refer to the Resource Update section of this document. 8) Move servers to the target domain. Refer to the Resource Update > Moving Computers to a Target Domain section of this document. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VENDERSAREN

12 Post-migration Activities
Projet 2005 Les scénarios de tests Post-migration Activities 10) Stop and uninstall the Directory Synchronization Agents. Refer to the Active Directory Migration > Directory Synchronization section of this document. 11) Disable the source accounts. We recommend that you wait some time after disabling the source accounts before proceeding with the next step to make sure that all users are using their target accounts. Refer to the Post-migration Activities > Disable Source Accounts section of this document. 12) Clean up SIDHistory attributes from the target accounts. After SIDHistory is cleaned up, wait some time to ensure that all target users can access the resources they used before the migration. Refer to the Post-migration Activities > Cleanup SIDHistory Attributes section of this document. 13) Clean up legacy accounts permissions from resources. Note that cleanup is hard to undo. It is recommended that you clean up permissions only when you are sure that all users are using their target accounts for all applications and have no problems accessing resources. Refer to the Post-migration Activities > Cleanup Legacy Accounts Permissions section of this document. 14) Decommission migrated environments. Refer to the Post-migration Activities > Decommission Migrated Environments section of this document. Franck CAVROIS, Jean-Claude KUTZ, Julien LUSSAC, Benjamin TOLMAN et David VENDERSAREN

13 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 VENDERSAREN

14 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 VENDERSAREN


Télécharger ppt "Présentation des architectures et scénarios de tests"

Présentations similaires


Annonces Google