Mise à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003

Cet article explique comment mettre à niveau des contrôleurs de domaine Microsoft Windows 2000 vers Windows Server 2003 et comment ajouter de nouveaux contrôleurs de domaine Windows Server 2003 à des domaines Windows 2000.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 325379

Résumé

Cet article explique comment mettre à niveau des contrôleurs de domaine Microsoft Windows 2000 vers Windows Server 2003 et comment ajouter de nouveaux contrôleurs de domaine Windows Server 2003 à des domaines Windows 2000. Pour plus d’informations sur la mise à niveau des contrôleurs de domaine vers Windows Server 2008 ou Windows Server 2008 R2, visitez le site web Microsoft suivant :

Mettre à niveau des contrôleurs de domaine : Support Microsoft Démarrage rapide pour l’ajout de contrôleurs de domaine Windows Server 2008 ou Windows Server 2008 R2 à des domaines existants

Inventaire des domaines et des forêts

Avant de mettre à niveau les contrôleurs de domaine Windows 2000 vers Windows Server 2003 ou d’ajouter de nouveaux contrôleurs de domaine Windows Server 2003 à un domaine Windows 2000, procédez comme suit :

1. Inventoriez les clients qui accèdent aux ressources dans le domaine qui hébergent les contrôleurs de domaine Windows Server 2003 à des fins de compatibilité avec la signature SMB :

   Chaque contrôleur de domaine Windows Server 2003 active la connexion SMB dans sa stratégie de sécurité locale. Assurez-vous que tous les clients réseau qui utilisent le protocole SMB/CIFS pour accéder aux fichiers partagés et aux imprimantes dans les domaines qui hébergent des contrôleurs de domaine Windows Server 2003 peuvent être configurés ou mis à niveau pour prendre en charge la signature SMB. Si ce n’est pas le cas, désactivez temporairement la signature SMB jusqu’à ce que les mises à jour puissent être installées ou jusqu’à ce que les clients puissent être mis à niveau vers des systèmes d’exploitation plus récents qui prennent en charge la signature SMB. Pour plus d’informations sur la désactivation de la signature SMB, consultez la section Pour désactiver la signature SMB à la fin de cette étape.

   Plans d’action

   La liste suivante présente les plans d’action pour les clients SMB populaires :

   • Microsoft Windows Server 2003, Microsoft Windows XP Professionnel, Microsoft Windows 2000 Server, Microsoft Windows 2000 Professionnel et Microsoft Windows 98

     Aucune action n’est requise.

   • Microsoft Windows NT 4.0 Installez Service Pack 3 ou version ultérieure (Service Pack 6A est recommandé) sur tous les ordinateurs Windows NT 4.0 qui accèdent aux domaines qui contiennent des ordinateurs Windows Server 2003. Au lieu de cela, désactivez temporairement la connexion SMB sur les contrôleurs de domaine Windows Server 2003. Pour plus d’informations sur la désactivation de la signature SMB, consultez la section Pour désactiver la signature SMB à la fin de cette étape.

   • Microsoft Windows 95

     Installez le client du service d’annuaire Windows 9 x sur les ordinateurs Windows 95 ou désactivez temporairement la signature SMB sur les contrôleurs de domaine Windows Server 2003. Le client de service d’annuaire Win9 x d’origine est disponible sur le CD-ROM Windows 2000 Server. Toutefois, ce module complémentaire client a été remplacé par un client de service d’annuaire Win9 x amélioré. Pour plus d’informations sur la désactivation de la signature SMB, consultez la section Pour désactiver la signature SMB à la fin de cette étape.

   • Microsoft Network Client pour les clients MS-DOS et Microsoft LAN Manager

     Le client réseau Microsoft pour MS-DOS et le client réseau Microsoft LAN Manager 2.x peuvent être utilisés pour fournir l’accès aux ressources réseau, ou ils peuvent être combinés avec une disquette de démarrage pour copier des fichiers de système d’exploitation et d’autres fichiers à partir d’un répertoire partagé sur un serveur de fichiers dans le cadre d’une routine d’installation logicielle. Ces clients ne prennent pas en charge la signature SMB. Utilisez une autre méthode d’installation ou désactivez la signature SMB. Pour plus d’informations sur la désactivation de la signature SMB, consultez la section Pour désactiver la signature SMB à la fin de cette étape.

   • Clients Macintosh

     Certains clients Macintosh ne sont pas compatibles avec la signature SMB et recevront le message d’erreur suivant lorsqu’ils tentent de se connecter à une ressource réseau :

     - Erreur -36 E/S

     Installez le logiciel mis à jour s’il est disponible. Sinon, désactivez la signature SMB sur les contrôleurs de domaine Windows Server 2003. Pour plus d’informations sur la désactivation de la signature SMB, consultez la section Pour désactiver la signature SMB à la fin de cette étape.

   • Autres clients SMB tiers

     Certains clients SMB tiers ne prennent pas en charge la signature SMB. Consultez votre fournisseur SMB pour voir s’il existe une version mise à jour. Sinon, désactivez la signature SMB sur les contrôleurs de domaine Windows Server 2003.

   Pour désactiver la signature SMB

   Si les mises à jour logicielles ne peuvent pas être installées sur les contrôleurs de domaine affectés qui exécutent Windows 95, Windows NT 4.0 ou d’autres clients installés avant l’introduction de Windows Server 2003, désactivez temporairement les exigences de signature du service SMB dans stratégie de groupe jusqu’à ce que vous puissiez déployer le logiciel client mis à jour.

   Vous pouvez désactiver la connexion du service SMB dans le nœud suivant de la stratégie Contrôleurs de domaine par défaut sur l’unité d’organisation des contrôleurs de domaine : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité\Serveur réseau Microsoft :

   Communications de signature numérique (toujours)

   Si les contrôleurs de domaine ne se trouvent pas dans l’unité d’organisation du contrôleur de domaine, vous devez lier l’objet stratégie de groupe (GPO) du contrôleur de domaine par défaut à toutes les unités d’organisation qui hébergent les contrôleurs de domaine Windows 2000 ou Windows Server 2003. Vous pouvez également configurer la connexion du service SMB dans un objet de stratégie de groupe lié à ces unités organisationnelles.

2. Inventaire des contrôleurs de domaine qui se trouvent dans le domaine et dans la forêt :

   1. Vérifiez que tous les contrôleurs de domaine Windows 2000 de la forêt ont installé tous les correctifs logiciels et Service Packs appropriés.

      Microsoft recommande que tous les contrôleurs de domaine Windows 2000 exécutent les systèmes d’exploitation Windows 2000 Service Pack 4 (SP4) ou ultérieurs. Si vous ne pouvez pas déployer entièrement Windows 2000 SP4 ou version ultérieure, tous les contrôleurs de domaine Windows 2000 doivent avoir un fichier Ntdsa.dll dont la date et la version sont postérieures au 4 juin 2001 et 5.0.2195.3673.

      Par défaut, les outils d’administration Active Directory sur les ordinateurs clients Windows 2000 SP4, Windows XP et Windows Server 2003 utilisent la signature LDAP (Lightweight Directory Access Protocol). Si ces ordinateurs utilisent (ou revient à) l’authentification NTLM lorsqu’ils administrent à distance des contrôleurs de domaine Windows 2000, la connexion ne fonctionne pas. Pour résoudre ce problème, un minimum de Windows 2000 SP3 doit être installé sur les contrôleurs de domaine administrés à distance. Sinon, vous devez désactiver la signature LDAP sur les clients qui exécutent les outils d’administration.

      Les scénarios suivants utilisent l’authentification NTLM :

      • Vous administrez des contrôleurs de domaine Windows 2000 situés dans une forêt externe connectée par une approbation NTLM (non Kerberos).
      • Vous concentrez les composants logiciels enfichables MMC (Microsoft Management Console) sur un contrôleur de domaine spécifique référencé par son adresse IP. Par exemple, vous cliquez sur Démarrer, sur Exécuter, puis tapez la commande suivante : dsa.msc /server=ipaddress

      Pour déterminer le système d’exploitation et le niveau de révision du Service Pack des contrôleurs de domaine Active Directory dans un domaine Active Directory, installez la version Windows Server 2003 de Repadmin.exe sur un ordinateur membre Windows XP Professionnel ou Windows Server 2003 dans la forêt, puis exécutez la commande suivante repadmin sur un contrôleur de domaine dans chaque domaine de la forêt :

      >repadmin /showattr <name of the domain controller that is in the target domain> ncobj:domain: /filter:"(&(objectCategory=computer)(primaryGroupID=516))" /subtree /atts:operatingSystem,operatingSystemVersion,operatingSystemServicePack
      
      DN: CN=NA-DC-01,organizational unit=Domain Controllers,DC=company,DC=com
       1> operatingSystem: Windows Server 2003
       1> operatingSystemVersion: 5.2 (3718)
      DN: CN=NA-DC-02,organizational unit=Domain Controllers,DC=company,DC=com
       1> operatingSystem: Windows 2000 Server
       1> operatingSystemVersion: 5.0 (2195)
       1> operatingSystemServicePack: Service Pack 1
      

      Remarque

      Les attributs du contrôleur de domaine ne suivent pas l’installation des correctifs logiciels individuels.

   2. Vérifiez la réplication Active Directory de bout en bout dans la forêt.

      Vérifiez que chaque contrôleur de domaine dans la forêt mise à niveau réplique tous ses contextes de nommage tenus localement avec ses partenaires de manière cohérente avec la planification définie par les liens de site ou les objets de connexion. Utilisez la version Windows Server 2003 de Repadmin.exe sur un ordinateur membre Windows XP ou Windows Server 2003 dans la forêt avec les arguments suivants : Tous les contrôleurs de domaine de la forêt doivent répliquer Active Directory sans erreur, et les valeurs de la colonne « Delta le plus grand » de la sortie repadmin ne doivent pas être significativement supérieures à la fréquence de réplication sur les liens de site ou objets de connexion correspondants utilisés par un domaine de destination donné Contrôleur.

      Résolvez toutes les erreurs de réplication entre les contrôleurs de domaine qui n’ont pas pu effectuer la réplication entrante en moins de nombre de jours de durée de vie de Tombstone (TSL) (par défaut, 60 jours). Si la réplication ne peut pas fonctionner, vous devrez peut-être rétrograder de force les contrôleurs de domaine et les supprimer de la forêt à l’aide de la commande de nettoyage des métadonnées Ntdsutil, puis les promouvoir à nouveau dans la forêt. Vous pouvez utiliser une rétrogradation forcée pour enregistrer à la fois l’installation du système d’exploitation et les programmes qui se trouvent sur un contrôleur de domaine orphelin. Pour plus d’informations sur la suppression de contrôleurs de domaine Windows 2000 orphelins de leur domaine, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

      216498 Comment supprimer des données dans Active Directory après une rétrogradation de contrôleur de domaine infructueuse

      Effectuez cette action uniquement en dernier recours pour récupérer l’installation du système d’exploitation et des programmes installés. Vous perdrez des objets et attributs non répliqués sur les contrôleurs de domaine orphelins, notamment les utilisateurs, les ordinateurs, les relations d’approbation, leurs mots de passe, groupes et appartenances aux groupes.

      Soyez prudent lorsque vous essayez de résoudre les erreurs de réplication sur les contrôleurs de domaine qui n’ont pas répliqué les modifications entrantes pour une partition Active Directory particulière pendant un nombre de jours supérieur à tombstonelifetime . Dans ce cas, vous pouvez réanimer des objets qui ont été supprimés sur un contrôleur de domaine, mais pour lesquels les partenaires de réplication directe ou transitive n’ont jamais reçu la suppression au cours des 60 derniers jours.

      Envisagez de supprimer tous les objets persistants qui résident sur des contrôleurs de domaine qui n’ont pas effectué de réplication entrante au cours des 60 derniers jours. Vous pouvez également rétrograder de force les contrôleurs de domaine qui n’ont pas effectué de réplication entrante sur une partition donnée en nombre de jours de durée de vie tombstone et supprimer leurs métadonnées restantes de la forêt Active Directory à l’aide de Ntdsutil et d’autres utilitaires. Pour obtenir de l’aide supplémentaire, contactez votre fournisseur de support ou Microsoft PSS.

   3. Vérifiez que le contenu du partage Sysvol est cohérent.

      Vérifiez que la partie système de fichiers de la stratégie de groupe est cohérente. Vous pouvez utiliser Gpotool.exe du Kit de ressources pour déterminer s’il existe des incohérences dans les stratégies dans un domaine. Utilisez la vérification d’intégrité des outils de prise en charge de Windows Server 2003 pour déterminer si le partage Sysvol réplica jeux fonctionne correctement dans chaque domaine.

      Si le contenu du partage Sysvol est incohérent, résolvez toutes les incohérences.

   4. Utilisez Dcdiag.exe des outils de support pour vérifier que tous les contrôleurs de domaine ont des partages Netlogon et Sysvol partagés. Pour ce faire, tapez la commande suivante à l’invite de commandes :

      DCDIAG.EXE /e /test:frssysvol
      

   5. Inventoriez les rôles d’opérations.

      Les maîtres des opérations de schéma et d’infrastructure sont utilisés pour introduire des modifications de schéma à l’échelle de la forêt et du domaine dans la forêt et ses domaines qui sont effectuées par l’utilitaire adprep Windows Server 2003. Vérifiez que le contrôleur de domaine qui héberge le rôle de schéma et le rôle d’infrastructure pour chaque domaine de la forêt réside sur des contrôleurs de domaine en direct et que chaque propriétaire de rôle a effectué une réplication entrante sur toutes les partitions depuis leur dernier redémarrage.

      La DCDIAG /test:FSMOCHECK commande peut être utilisée pour afficher les rôles opérationnels à l’échelle de la forêt et du domaine. Les opérations master rôles qui résident sur des contrôleurs de domaine inexistants doivent être saisis dans un contrôleur de domaine sain à l’aide de NTDSUTIL. Les rôles qui résident sur des contrôleurs de domaine non sains doivent être transférés si possible. Sinon, ils devraient être saisis. La NETDOM QUERY FSMO commande n’identifie pas les rôles FSMO qui résident sur des contrôleurs de domaine supprimés.

      Vérifiez que les ont effectué la réplication entrante d’Active Directory depuis le dernier démarrage. La réplication entrante peut être vérifiée à l’aide de la REPADMIN /SHOWREPS DCNAME commande , où DCNAME est le nom d’ordinateur NetBIOS ou le nom d’ordinateur complet d’un contrôleur de domaine. Pour plus d’informations sur les maîtres d’opérations et leur positionnement, cliquez sur les numéros d’article suivants pour afficher les articles dans la Base de connaissances Microsoft :

      197132 rôles FSMO Windows 2000 Active Directory

      223346 placement et optimisation FSMO sur les contrôleurs de domaine Active Directory

   6. Révision EventLog

      Examinez les journaux des événements sur tous les contrôleurs de domaine à la recherche d’événements problématiques. Les journaux des événements ne doivent pas contenir de messages d’événements graves qui indiquent un problème avec l’un des processus et composants suivants :

      connectivité physique
      connectivité réseau
      inscription de nom
      résolution de noms
      authentification
      Stratégie de groupe
      stratégie de sécurité
      sous-système de disque
      Schéma
      Topologie
      moteur de réplication

   7. Inventaire de l’espace disque

      Le volume qui héberge le fichier de base de données Active Directory, Ntds.dit, doit disposer d’un espace libre égal à au moins 15 à 20 % de la taille du fichier Ntds.dit. Le volume qui héberge le fichier journal Active Directory doit également disposer d’un espace libre égal à au moins 15 à 20 % de la taille du fichier Ntds.dit. Pour plus d’informations sur la façon de libérer de l’espace disque supplémentaire, consultez la section « Contrôleurs de domaine sans espace disque suffisant » de cet article.

   8. Nettoyage DNS (facultatif)

      Activez le nettoyage DNS à intervalles de 7 jours pour tous les serveurs DNS de la forêt. Pour de meilleurs résultats, effectuez cette opération 61 jours ou plus avant de mettre à niveau le système d’exploitation. Cela fournit au démon de récupération DNS suffisamment de temps pour collecter la mémoire des anciens objets DNS lorsqu’une défragmentation hors connexion est effectuée sur le fichier Ntds.dit.

   9. Désactiver le service serveur DLT (facultatif)

      Le service DLT Server est désactivé sur les installations nouvelles et mises à niveau des contrôleurs de domaine Windows Server 2003. Si le suivi de liens distribués n’est pas utilisé, vous pouvez désactiver le service DLT Server sur vos contrôleurs de domaine Windows 2000 et commencer à supprimer des objets DLT de chaque domaine de la forêt. Pour plus d’informations, consultez la section « Recommandations Microsoft pour le suivi des liens distribués » de l’article suivant dans la Base de connaissances Microsoft : 312403 Distributed Link Tracking sur les contrôleurs de domaine Windows

   10. Sauvegarde de l’état du système

       Effectuez une sauvegarde de l’état système d’au moins deux contrôleurs de domaine dans chaque domaine de la forêt. Vous pouvez utiliser la sauvegarde pour récupérer tous les domaines de la forêt si la mise à niveau ne fonctionne pas.

Microsoft Exchange 2000 dans les forêts Windows 2000

Le schéma Exchange 2000 définit trois attributs inetOrgPerson avec des LDAPDisplayNames non conformes À la demande de commentaire (RFC) : houseIdentifier, secretary et labeledURI.

Le Kit inetOrgPerson De Windows 2000 et la commande Windows Server 2003 adprep définissent les versions RFC-complaint des trois mêmes attributs avec ldapDisplayName identiques que les versions non conformes À RFC.

Lorsque la commande Windows Server 2003 adprep /forestprep est exécutée sans scripts correctifs dans une forêt qui contient des modifications de schéma Windows 2000 et Exchange 2000, les ldapDisplayNames des attributs houseIdentifier, labeledURI et secretary sont modifiés. Un attribut devient « désactivé » si « Dup » ou d’autres caractères uniques sont ajoutés au début du nom d’attribut en conflit afin que les objets et les attributs du répertoire aient des noms uniques.

Les forêts Active Directory ne sont pas vulnérables aux LDAPDisplayNames mal gérés pour ces attributs dans les cas suivants :

• Si vous exécutez la commande Windows Server 2003 adprep /forestprep dans une forêt qui contient le schéma Windows 2000 avant d’ajouter le schéma Exchange 2000.
• Si vous installez le schéma Exchange 2000 dans la forêt qui a été créée où un contrôleur de domaine Windows Server 2003 était le premier contrôleur de domaine dans la forêt.
• Si vous ajoutez windows 2000 inetOrgPerson Kit à une forêt qui contient le schéma Windows 2000, que vous installez les modifications de schéma Exchange 2000, puis que vous exécutez la commande Windows Server 2003 adprep /forestprep .
• Si vous ajoutez un schéma Exchange 2000 à une forêt Windows 2000 existante, exécutez Exchange 2003 /forestprep avant d’exécuter la commande Windows Server 2003 adprep /forestprep .

Les attributs désactivés se produisent dans Windows 2000 dans les cas suivants :

• Si vous ajoutez les versions Exchange 2000 de labeledURI, houseIdentifier et les attributs secretary à une forêt Windows 2000 avant d’installer le kit inetOrgPerson De Windows 2000.
• Vous ajoutez les versions Exchange 2000 des attributs labeledURI, houseIdentifier et secretary à une forêt Windows 2000 avant d’exécuter la commande Windows Server 2003 adprep /forestprep sans exécuter au préalable les scripts de nettoyage. Les plans d’action pour chaque scénario sont les suivants :

Scénario 1 : Les modifications de schéma Exchange 2000 sont ajoutées après l’exécution de la commande adprep /forestprep de Windows Server 2003

Si des modifications de schéma Exchange 2000 sont introduites dans votre forêt Windows 2000 après l’exécution de la commande Windows Server 2003 adprep /forestprep , aucun nettoyage n’est nécessaire. Accédez à la section « Vue d’ensemble : Mise à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003 ».

Scénario 2 : Les modifications de schéma Exchange 2000 seront installées avant la commande adprep /forestprep de Windows Server 2003

Si des modifications de schéma Exchange 2000 ont déjà été installées, mais que vous n’avez PAS exécuté la commande Windows Server 2003 adprep /forestprep , envisagez le plan d’action suivant :

1. Connectez-vous à la console des opérations de schéma master à l’aide d’un compte membre du groupe de sécurité Administrateurs de schéma.

2. Cliquez sur Démarrer, sur Exécuter, tapez notepad.exe dans la zone Ouvrir , puis cliquez sur OK.

3. Copiez le texte suivant, y compris le trait d’union de fin après « schemaUpdateNow : 1 » dans le Bloc-notes.

   dn : CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
   changetype : Modifier
   replace :LDAPDisplayName
   LDAPDisplayName : msExchAssistantName
   -

   dn : CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
   changetype : Modifier
   replace : LDAPDisplayName
   LDAPDisplayName : msExchLabeledURI
   -

   dn : CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
   changetype : Modifier
   replace : LDAPDisplayName
   LDAPDisplayName : msExchHouseIdentifier
   -

   Dn:
   changetype : Modifier
   add : schemaUpdateNow
   schemaUpdateNow : 1
   -

4. Vérifiez qu’il n’y a pas d’espace à la fin de chaque ligne.

5. Dans le menu Fichier, cliquez sur Enregistrer. Dans la boîte de dialogue Enregistrer sous, procédez comme suit :

   1. Dans la zone Nom de fichier, tapez ce qui suit : \%userprofile%\InetOrgPersonPrevent.ldf
   2. Dans la zone Type de fichier , cliquez sur Tous les fichiers.
   3. Dans la zone Encodage , cliquez sur Unicode.
   4. Cliquez sur Save (Enregistrer).
   5. Quittez le Bloc-notes.

6. Exécutez le script InetOrgPersonPrevent.ldf.

   1. Cliquez sur Démarrer, sur Exécuter, tapez cmd dans la zone Ouvrir , puis cliquez sur OK.

   2. À l’invite de commandes, tapez ce qui suit, puis appuyez sur Entrée : cd %userprofile%

   3. Tapez la commande suivante

   c:\documents and settings\%username%>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X "domain name path for forest root domain"
   

   Notes de syntaxe :

   • DC=X est une constante sensible à la casse.
   • Le chemin d’accès du nom de domaine pour le domaine racine doit être placé entre guillemets.

   Par exemple, la syntaxe de commande pour une forêt Active Directory dont le domaine racine de forêt est TAILSPINTOYS.COM :

   c :\documents and settings\administrator>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X « dc=tailspintoys,dc=com »

   Remarque

   Vous devrez peut-être modifier la sous-clé de Registre Mise à jour du schéma Autorisée si vous recevez le message d’erreur suivant : La mise à jour du schéma n’est pas autorisée sur ce contrôleur de domaine, car la clé de Registre n’est pas définie ou le contrôleur de domaine n’est pas le propriétaire du rôle FSMO du schéma.

7. Vérifiez que les attributs LDAPDisplayNames pour les attributs CN=ms-Exch-Assistant-Name, CN=ms-Exch-LabeledURI et CN=ms-Exch-House-Identifier dans le contexte d’affectation de noms de schéma apparaissent désormais sous la forme msExchAssistantName, msExchLabeledURI et msExchHouseIdentifier avant d’exécuter les commandes Windows Server 2003 adprep /forestprep .

8. Accédez à la section « Vue d’ensemble : Mise à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003 » pour exécuter les adprep /forestprep commandes et /domainprep .

Scénario 3 : La commande forestprep de Windows Server 2003 a été exécutée sans exécuter au préalable inetOrgPersonFix

Si vous exécutez la commande Windows Server 2003 adprep /forestprep dans une forêt Windows 2000 qui contient les modifications de schéma Exchange 2000, les attributs LDAPDisplayName pour houseIdentifier, secretary et labeledURI sont modifiés. Pour identifier les noms désactivés, utilisez Ldp.exe pour localiser les attributs affectés :

1. Installez Ldp.exe à partir du dossier Support\Tools du média Microsoft Windows 2000 ou Windows Server 2003.

2. Démarrez Ldp.exe à partir d’un contrôleur de domaine ou d’un ordinateur membre dans la forêt.

   1. Dans le menu Connexion , cliquez sur Se connecter, laissez la zone Serveur vide, tapez 389 dans la zone Port , puis cliquez sur OK.
   2. Dans le menu Connexion , cliquez sur Lier, laissez toutes les zones vides, puis cliquez sur OK.

3. Enregistrez le chemin du nom unique pour l’attribut SchemaNamingContext. Par exemple, pour un contrôleur de domaine dans la forêt CORP.ADATUM.COM, le chemin du nom unique peut être CN=Schema,CN=Configuration,DC=corp,DC=company,DC=com.

4. Dans le menu Parcourir , cliquez sur Rechercher.

5. Utilisez les paramètres suivants pour configurer la boîte de dialogue Rechercher :

   • Nom de base : chemin d’accès du nom unique pour le contexte d’affectation de noms de schéma identifié à l’étape 3.
   • Filtre : (ldapdisplayname=dup*)
   • Étendue : Sous-arborescence

6. Les attributs HouseIdentifier, secretary et labeledURI ont des attributs LDAPDisplayName similaires au format suivant :

   LDAPDisplayName : DUP-labeledURI-9591bbd3-d2a6-4669-afda-48af7c35507d ;
   LDAPDisplayName : DUP-secretary-c5a1240d-70c0-455c-9906-a4070602f85f
   LDAPDisplayName : DUP-houseIdentifier-354b0ca8-9b6c-4722-aae7-e66906cc9eef

7. Si les LDAPDisplayNames pour labeledURI, secretary et houseIdentifier ont été désactivés à l’étape 6, exécutez le script Windows Server 2003 InetOrgPersonFix.ldf pour récupérer, puis accédez à la section « Mise à niveau des contrôleurs de domaine Windows 2000 avec Winnt32.exe ».

   1. Créez un dossier nommé %Systemdrive%\IOP, puis extrayez le fichier InetOrgPersonFix.ldf dans ce dossier.

   2. À l’invite de commandes, tapez cd %systemdrive%\iop.

   3. Extrayez le fichier InetOrgPersonFix.ldf du fichier Support.cab qui se trouve dans le dossier Support\Tools du support d’installation de Windows Server 2003.

   4. À partir de la console des opérations de schéma master, chargez le fichier InetOrgPersonFix.ldf à l’aide de Ldifde.exe pour corriger l’attribut LdapDisplayName des attributs houseIdentifier, secretary et labeledURI. Pour ce faire, tapez la commande suivante, où <X> est une constante sensible à la casse et <le chemin dn pour le domaine> racine de forêt est le chemin d’accès du nom de domaine pour le domaine racine de la forêt :

      C:\IOP>ldifde -i -f inetorgpersonfix.ldf -v -c DC=X "domain name path for forest root domain"
      

      Notes de syntaxe :

      • DC=X est une constante sensible à la casse.
      • Le chemin d’accès du nom de domaine pour le domaine racine de forêt doit être placé entre guillemets.

8. Vérifiez que les attributs houseIdentifier, secretary et labeledURI dans le contexte d’affectation de noms de schéma ne sont pas « mangled » avant d’installer Exchange 2000.

Vue d’ensemble : Mise à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003

La commande Windows Server 2003 adprep que vous exécutez à partir du dossier \I386 du support Windows Server 2003 prépare une forêt Windows 2000 et ses domaines pour l’ajout de contrôleurs de domaine Windows Server 2003. La commande Windows Server 2003 adprep /forestprep ajoute les fonctionnalités suivantes :

• Amélioration des descripteurs de sécurité par défaut pour les classes d’objets

• Nouveaux attributs d’utilisateur et de groupe

• Nouveaux objets et attributs de schéma comme inetOrgPersonL’utilitaire adprep prend en charge deux arguments de ligne de commande :

  • adprep /forestprep: exécute des opérations de mise à niveau de forêt.
  • dprep /domainprep: exécute des opérations de mise à niveau de domaine.

La adprep /forestprep commande est une opération ponctuelle effectuée sur le master d’opération de schéma (FSMO) de la forêt. L’opération forestprep doit se terminer et répliquer sur l’infrastructure master de chaque domaine avant de pouvoir exécuter adprep /domainprep dans ce domaine.

La adprep /domainprep commande est une opération unique que vous exécutez sur les opérations d’infrastructure master contrôleur de domaine de chaque domaine de la forêt qui hébergera des contrôleurs de domaine Windows Server 2003 nouveaux ou mis à niveau. La adprep /domainprep commande vérifie que les modifications apportées à forestprep ont été répliquées dans la partition de domaine, puis apporte ses propres modifications à la partition de domaine et aux stratégies de groupe dans le partage Sysvol.

Vous ne pouvez pas effectuer l’une des actions suivantes, sauf si les opérations /forestprep et /domainprep sont terminées et répliquées sur tous les contrôleurs de domaine de ce domaine :

• Mettez à niveau les contrôleurs de domaine Windows 2000 vers des contrôleurs de domaine Windows Server 2003 à l’aide de Winnt32.exe.

Les adprep /forestprep commandes et adprep /domainprep n’ajoutent pas d’attributs au jeu d’attributs partiels du catalogue global ou n’entraînent pas une synchronisation complète du catalogue global. La version RTM de adprep /domainprep entraîne une synchronisation complète du dossier \Policies dans l’arborescence Sysvol. Même si vous exécutez forestprep et domainprep plusieurs fois, les opérations terminées ne sont effectuées qu’une seule fois.

Après les modifications apportées adprep /forestprep à et adprep /domainprep la réplication complète, vous pouvez mettre à niveau les contrôleurs de domaine Windows 2000 vers Windows Server 2003 en exécutant Winnt32.exe à partir du dossier \I386 du média Windows Server 2003. En outre, vous pouvez ajouter de nouveaux contrôleurs de domaine Windows Server 2003 au domaine à l’aide de Dcpromo.exe.

Mise à niveau de la forêt avec la commande adprep /forestprep

Pour préparer une forêt et des domaines Windows 2000 à accepter les contrôleurs de domaine Windows Server 2003, procédez d’abord comme suit dans un environnement lab, puis dans un environnement de production :

1. Vérifiez que vous avez effectué toutes les opérations de la phase « Inventaire de forêt » avec une attention particulière aux éléments suivants :

   1. Vous avez créé des sauvegardes d’état système.
   2. Tous les contrôleurs de domaine Windows 2000 de la forêt ont installé tous les correctifs logiciels et Service Packs appropriés.
   3. La réplication de bout en bout d’Active Directory se produit dans toute la forêt
   4. FRS réplique correctement la stratégie de système de fichiers dans chaque domaine.

2. Connectez-vous à la console des opérations de schéma master avec un compte membre du groupe de sécurité Administrateurs de schéma.

3. Vérifiez que le schéma FSMO a effectué la réplication entrante de la partition de schéma en tapant ce qui suit à l’invite de commandes Windows NT : repadmin /showreps

   ( repadmin est installé par le dossier Support\Tools d’Active Directory.)

4. La documentation microsoft vous recommande d’isoler les opérations de schéma master sur un réseau privé avant d’exécuter adprep /forestprep. L’expérience réelle suggère que cette étape n’est pas nécessaire et qu’une master d’opérations de schéma peut rejeter les modifications de schéma lorsqu’elle est redémarrée sur un réseau privé.

5. Exécutez adprep sur le master des opérations de schéma. Pour ce faire, cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK. Dans le master des opérations de schéma, tapez la commande suivante :

    X:\I386\adprep /forestprep
   

   où X :\I386\ est le chemin du support d’installation de Windows Server 2003. Cette commande exécute la mise à niveau du schéma à l’échelle de la forêt.

   Remarque

   Les événements avec l’ID d’événement 1153 qui sont enregistrés dans le journal des événements du service d’annuaire, tels que l’exemple qui suit, peuvent être ignorés :

6. Vérifiez que la commande s’est adprep /forestprep correctement exécutée sur les opérations de schéma master. Pour ce faire, à partir de la console des opérations de schéma master, vérifiez les éléments suivants : - La adprep /forestprep commande s’est terminée sans erreur. - L’objet CN=Windows2003Update est écrit sous CN=ForestUpdates,CN=Configuration,DC= forest_root_domain. Enregistrez la valeur de l’attribut Revision. - (Facultatif) Version du schéma incrémentée à la version 30. Pour ce faire, consultez l’attribut ObjectVersion sous CN=Schema,CN=Configuration,DC= forest_root_domain. Si adprep /forestprep ne s’exécute pas, vérifiez les éléments suivants :

   • Le chemin complet pour Adprep.exe situé dans le dossier \I386 du support d’installation a été spécifié lors de l’exécution adprep . Pour ce faire, tapez la commande suivante :

     x:\i386\adprep /forestprep
     

     où x est le lecteur qui héberge le support d’installation.

   • L’utilisateur connecté qui exécute adprep est membre du groupe de sécurité Administrateurs du schéma. Pour vérifier cela, utilisez la whoami /all commande .

   • Si adprep cela ne fonctionne toujours pas, affichez le fichier Adprep.log dans le dossier %systemroot%\System32\Debug\Adprep\Logs\Latest_log .

7. Si vous avez désactivé la réplication sortante sur les opérations de schéma master à l’étape 4, activez la réplication afin que les modifications de schéma effectuées par adprep /forestprep puissent se propager. Pour ce faire, procédez comme suit :

   1. Cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK.
   2. Tapez ce qui suit, puis appuyez sur Entrée : repadmin /options -DISABLE_OUTBOUND_REPL

8. Vérifiez que les adprep /forestprep modifications ont été répliquées sur tous les contrôleurs de domaine de la forêt. Il est utile de surveiller les attributs suivants :

   1. Incrémentation de la version du schéma
   2. CN=Windows2003Update, CN=ForestUpdates,CN=Configuration,DC= forest_root_domain ou CN=Operations,CN=DomainUpdates,CN=System,DC= forest_root_domain et les GUID d’opérations qu’il contient sont répliqués dans.
   3. Recherchez les nouvelles classes de schéma, objets, attributs ou autres modifications ajoutées, telles que adprep /forestprep inetOrgPerson. Affichez les fichiers Sch XX.ldf (où XX est un nombre compris entre 14 et 30) dans le dossier %systemroot%\System32 pour déterminer les objets et attributs qu’il doit y avoir. Par exemple, inetOrgPerson est défini dans Sch18.ldf.

9. Recherchez LDAPDisplayNames mangled. Si vous trouvez des noms mutilés, accédez au Scénario 3 du même article.

10. Connectez-vous à la console des opérations de schéma master avec un compte membre du groupe Administrateurs de schéma de la forêt qui héberge les opérations de schéma master.

Mise à niveau du domaine avec la commande adprep /domainprep

Exécutez adprep /domainprep une fois que les modifications /forestprep sont entièrement répliquées sur l’infrastructure master contrôleur de domaine dans chaque domaine qui hébergera les contrôleurs de domaine Windows Server 2003. Pour ce faire, procédez comme suit :

1. Identifiez l’infrastructure master contrôleur de domaine dans le domaine que vous mettez à niveau, puis connectez-vous avec un compte membre du groupe de sécurité Administrateurs du domaine dans le domaine que vous mettez à niveau.

   Remarque

   L’administrateur d’entreprise ne peut pas être membre du groupe de sécurité Administrateurs du domaine dans les domaines enfants de la forêt.

2. Exécutez adprep /domainprep sur le master d’infrastructure. Pour ce faire, cliquez sur Démarrer, sur Exécuter, tapez cmd, puis dans infrastructure master tapez la commande suivante : X:\I386\adprep /domainprep où X :\I386\ est le chemin du support d’installation de Windows Server 2003. Cette commande exécute les modifications à l’échelle du domaine dans le domaine cible.

   Remarque

   La adprep /domainprep commande modifie les autorisations de fichiers dans le partage Sysvol. Ces modifications entraînent une synchronisation complète des fichiers dans cette arborescence de répertoires.

3. Vérifiez que domainprep s’est terminé avec succès. Pour ce faire, vérifiez les éléments suivants :

   • La adprep /domainprep commande s’est terminée sans erreur.
   • Le chemin CN=Windows2003Update,CN=DomainUpdates,CN=System,DC= dn du domaine que vous mettez à niveau existeSi adprep /domainprep ne s’exécute pas, vérifiez les éléments suivants :
   • L’utilisateur connecté qui exécute adprep a l’appartenance au groupe de sécurité Administrateurs du domaine dans le domaine en cours de mise à niveau. Pour ce faire, utilisez la whoami /all commande .
   • Le chemin d’accès complet pour Adprep.exe situé dans le répertoire \I386 du support d’installation a été spécifié lors de l’exécution adprepde . Pour ce faire, à l’invite de commandes, tapez la commande suivante : x :\i386\adprep /forestprep où x est le lecteur qui héberge le support d’installation.
   • Si adprep cela ne fonctionne toujours pas, affichez le fichier Adprep.log dans le dossier %systemroot%\System32\Debug\Adprep\Logs\ Latest_log .

4. Vérifiez que les adprep /domainprep modifications ont été répliquées. Pour ce faire, pour les contrôleurs de domaine restants dans le domaine, vérifiez les éléments suivants : - Le CN=Windows2003Update,CN=DomainUpdates,CN=System,DC= dn chemin du domaine que vous mettez à niveau l’objet existe et la valeur de l’attribut Revision correspond à la valeur du même attribut sur l’infrastructure master du domaine. - (Facultatif) Recherchez les modifications apportées aux objets, aux attributs ou à la liste de contrôle d’accès (ACL) qui ont adprep /domainprep été ajoutées. Répétez les étapes 1 à 4 sur l’infrastructure master des domaines restants en bloc ou lorsque vous ajoutez ou mettez à niveau des contrôleurs de domaine dans ces domaines vers Windows Server 2003. Vous pouvez désormais promouvoir de nouveaux ordinateurs Windows Server 2003 dans la forêt à l’aide de DCPROMO. Vous pouvez également mettre à niveau des contrôleurs de domaine Windows 2000 existants vers Windows Server 2003 à l’aide de WINNT32.EXE.

Mise à niveau des contrôleurs de domaine Windows 2000 à l’aide de Winnt32.exe

Une fois que les modifications apportées à /forestprep et /domainprep sont complètement répliquées et que vous avez pris une décision concernant l’interopérabilité de la sécurité avec les clients de version antérieure, vous pouvez mettre à niveau les contrôleurs de domaine Windows 2000 vers Windows Server 2003 et ajouter de nouveaux contrôleurs de domaine Windows Server 2003 au domaine.

Les ordinateurs suivants doivent figurer parmi les premiers contrôleurs de domaine qui exécutent Windows Server 2003 dans la forêt de chaque domaine :

• Le nommage de domaine master dans la forêt afin que vous puissiez créer des partitions de programme DNS par défaut.
• Contrôleur de domaine principal du domaine racine de la forêt afin que les principaux de sécurité à l’échelle de l’entreprise ajoutés par le forestprep de Windows Server 2003 deviennent visibles dans l’éditeur de liste de contrôle d’accès.
• Contrôleur de domaine principal dans chaque domaine non racine afin que vous puissiez créer de nouveaux principaux de sécurité Windows 2003 spécifiques au domaine. Pour ce faire, utilisez WINNT32 pour mettre à niveau les contrôleurs de domaine existants qui hébergent le rôle opérationnel souhaité. Vous pouvez également transférer le rôle vers un contrôleur de domaine Windows Server 2003 nouvellement promu. Effectuez les étapes suivantes pour chaque contrôleur de domaine Windows 2000 que vous mettez à niveau vers Windows Server 2003 avec WINNT32 et pour chaque groupe de travail Windows Server 2003 ou ordinateur membre que vous promouvez :

1. Avant d’utiliser WINNT32 pour mettre à niveau les ordinateurs membres windows 2000 et les contrôleurs de domaine, supprimez les outils d’administration Windows 2000. Pour ce faire, utilisez l’outil Ajout/Suppression de programmes dans Panneau de configuration. (Mises à niveau de Windows 2000 uniquement.)

2. Installez les fichiers de correctif logiciel ou d’autres correctifs que Microsoft ou l’administrateur déterminent comme importants.

3. Recherchez les éventuels problèmes de mise à niveau dans chaque contrôleur de domaine. Pour ce faire, exécutez la commande suivante à partir du dossier \I386 du support d’installation : winnt32.exe /checkupgradeonly Résolvez les problèmes que le case activée de compatibilité identifie.

4. Exécutez WINNT32.EXE à partir du dossier \I386 du support d’installation, puis redémarrez le contrôleur de domaine 2003 mis à niveau.

5. Réduisez les paramètres de sécurité pour les clients de version antérieure en fonction des besoins.

   Si les clients Windows NT 4.0 n’ont pas NT 4.0 SP6 ou Les clients Windows 95 n’ont pas installé le client de service d’annuaire, désactivez la signature du service SMB sur la stratégie Contrôleurs de domaine par défaut sur l’unité d’organisation Contrôleurs de domaine, puis liez cette stratégie à toutes les unités organisationnelles qui hébergent des contrôleurs de domaine. Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité\Serveur réseau Microsoft : communications de signature numérique (toujours)

6. Vérifiez l’intégrité de la mise à niveau à l’aide des points de données suivants :

   • La mise à niveau s’est terminée avec succès.
   • Les correctifs logiciels que vous avez ajoutés à l’installation ont correctement remplacé les fichiers binaires d’origine.
   • La réplication entrante et sortante d’Active Directory se produit pour tous les contextes d’affectation de noms détenus par le contrôleur de domaine.
   • Les partages Netlogon et Sysvol existent.
   • Le journal des événements indique que le contrôleur de domaine et ses services sont sains.

   Remarque

   Vous pouvez recevoir le message d’événement suivant après la mise à niveau : Vous pouvez ignorer ce message d’événement en toute sécurité.

7. Installez les outils d’administration Windows Server 2003 (mises à niveau de Windows 2000 et contrôleurs windows Server 2003 non de domaine uniquement). Adminpak.msi se trouve dans le dossier \I386 du CD-ROM Windows Server 2003. Le média Windows Server 2003 contient des outils de support mis à jour dans le fichier Support\Tools\Suptools.msi. Veillez à réinstaller ce fichier.

8. Effectuez de nouvelles sauvegardes d’au moins les deux premiers contrôleurs de domaine Windows 2000 que vous avez mis à niveau vers Windows Server 2003 dans chaque domaine de la forêt. Recherchez les sauvegardes des ordinateurs Windows 2000 que vous avez mis à niveau vers Windows Server 2003 dans un stockage verrouillé afin de ne pas les utiliser accidentellement pour restaurer un contrôleur de domaine qui exécute désormais Windows Server 2003.

9. (Facultatif) Effectuez une défragmentation hors connexion de la base de données Active Directory sur les contrôleurs de domaine que vous avez mis à niveau vers Windows Server 2003 après la fin du magasin de instance unique (mises à niveau de Windows 2000 uniquement).

   Le SIS passe en revue les autorisations existantes sur les objets stockés dans Active Directory, puis applique un descripteur de sécurité plus efficace à ces objets. Le SIS démarre automatiquement (identifié par l’événement 1953 dans le journal des événements du service d’annuaire) lorsque les contrôleurs de domaine mis à niveau démarrent pour la première fois le système d’exploitation Windows Server 2003. Vous bénéficiez de l’amélioration du magasin de descripteurs de sécurité uniquement lorsque vous consignez un message d’événement ID d’événement 1966 dans le journal des événements du service d’annuaire : ce message d’événement indique que l’opération de magasin de instance unique est terminée et sert de file d’attente à l’administrateur pour effectuer la défragmentation hors connexion de Ntds.dit à l’aide de NTDSUTIL.EXE.

   La défragmentation hors connexion peut réduire la taille d’un fichier Windows 2000 Ntds.dit jusqu’à 40 %, améliorer les performances d’Active Directory et mettre à jour les pages de la base de données pour un stockage plus efficace des attributs Link Valued. Pour plus d’informations sur la défragmentation de la base de données Active Directory, cliquez sur le numéro ci-dessous pour afficher l’article dans la Base de connaissances Microsoft :

   232122 La défragmentation hors connexion de la base de données Active Directory

10. Examinez le service serveur DLT. Les contrôleurs de domaine Windows Server 2003 désactivent le service DLT Server lors des nouvelles installations et mises à niveau. Si les clients Windows 2000 ou Windows XP de votre organization utilisent le service DLT Server, utilisez stratégie de groupe pour activer le service DLT Server sur les contrôleurs de domaine Windows Server 2003 nouveaux ou mis à niveau. Sinon, supprimez de façon incrémentielle les objets de suivi de liens distribués d’Active Directory. Pour plus d’informations, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

    312403 Distributed Link Tracking sur les contrôleurs de domaine Windows

    Si vous supprimez en bloc des milliers d’objets DLT ou d’autres objets, vous pouvez bloquer la réplication en raison d’un manque de magasin de versions. Wait tombstonelifetime nombre de jours (par défaut, 60 jours) après la suppression du dernier objet DLT et la fin du garbage collection, puis utilisez NTDSUTIL.EXE pour effectuer une défragmentation hors connexion du fichier Ntds.dit.

11. Configurez la structure d’unité organisationnelle de la meilleure pratique. Microsoft recommande aux administrateurs de déployer activement la structure d’unités organisationnelles recommandées dans tous les domaines Active Directory et, après avoir mis à niveau ou déployé des contrôleurs de domaine Windows Server 2003 en mode domaine Windows, rediriger les conteneurs par défaut utilisés par les API de version antérieure pour créer des utilisateurs, des ordinateurs et des groupes vers un conteneur d’unités d’organisation spécifié par l’administrateur.

    Pour plus d’informations sur la structure des unités organisationnelles des meilleures pratiques, consultez la section « Création d’une conception d’unité d’organisation » du livre blanc « Best Practice Active Directory Design for Managing Windows Networks ». Pour afficher le livre blanc, visitez le site web Microsoft suivant : https://technet.microsoft.com/library/bb727085.aspx Pour plus d’informations sur la modification du conteneur par défaut dans lequel se trouvent les utilisateurs, ordinateurs et groupes créés par les API de version antérieure, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

    324949 Redirection des conteneurs d’utilisateurs et d’ordinateurs dans les domaines Windows Server 2003

12. Répétez les étapes 1 à 10 si nécessaire pour chaque contrôleur de domaine Windows Server 2003 nouveau ou mis à niveau dans la forêt et l’étape 11 (structure d’unité organisationnelle des meilleures pratiques) pour chaque domaine Active Directory.

    En résumé :

    • Mettre à niveau les contrôleurs de domaine Windows 2000 avec WINNT32 (à partir du support d’installation glissé, le cas échéant)
    • Vérifiez que les fichiers de correctifs logiciels ont été installés sur les ordinateurs mis à niveau
    • Installer les correctifs logiciels requis non contenus sur le support d’installation
    • Vérifier l’intégrité sur les serveurs nouveaux ou mis à niveau (AD, FRS, Stratégie, et ainsi de suite)
    • Patientez 24 heures après la mise à niveau du système d’exploitation, puis la défragmentation hors connexion (facultatif)
    • Démarrez le service DLT si vous le devez, sinon supprimez les objets DLT à l’aide de q312403/q315229 post-forest-wide domainpreps
    • Effectuer une défragmentation hors connexion de plus de 60 jours (durée de vie et nombre de jours de garbage collection) après la suppression d’objets DLT

Mises à niveau à exécution sèche dans un environnement lab

Avant de mettre à niveau les contrôleurs de domaine Windows vers un domaine Windows 2000 de production, validez et affinez votre processus de mise à niveau dans le labo. Si la mise à niveau d’un environnement lab qui reflète avec précision la forêt de production fonctionne correctement, vous pouvez vous attendre à des résultats similaires dans les environnements de production. Pour les environnements complexes, l’environnement lab doit miroir l’environnement de production dans les domaines suivants :

• Matériel : type d’ordinateur, taille de la mémoire, emplacement des fichiers de page, taille du disque, performances et configuration raid, niveaux de révision du BIOS et du microprogramme
• Logiciels : versions du système d’exploitation client et serveur, applications client et serveur, versions du Service Pack, correctifs logiciels, modifications de schéma, groupes de sécurité, appartenances aux groupes, autorisations, paramètres de stratégie, type et emplacement du nombre d’objets, interopérabilité des versions
• Infrastructure réseau : WINS, DHCP, vitesses de liaison, bande passante disponible
• Chargement : les simulateurs de charge peuvent simuler des modifications de mot de passe, la création d’objets, la réplication Active Directory, l’authentification d’ouverture de session et d’autres événements. L’objectif n’est pas de reproduire l’échelle de l’environnement de production. Au lieu de cela, les objectifs sont de découvrir les coûts et la fréquence des opérations courantes et d’interpoler leurs effets (requêtes de nom, trafic de réplication, bande passante réseau et consommation du processeur) sur l’environnement de production en fonction de vos besoins actuels et futurs.
• Administration : tâches effectuées, outils utilisés, systèmes d’exploitation utilisés
• Opération : capacité, interopérabilité
• Espace disque : notez la taille de début, de pointe et de fin du système d’exploitation, des fichiers journaux Ntds.dit et Active Directory sur les contrôleurs de domaine catalogue global et non globaux dans chaque domaine après chacune des opérations suivantes :
  1. adprep /forestprep
  2. adprep /domainprep
  3. Mise à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003
  4. Exécution de la défragmentation hors connexion après les mises à niveau de version

Une compréhension du processus de mise à niveau et de la complexité de l’environnement, associée à une observation détaillée, détermine le rythme et le degré de soin que vous appliquez à la mise à niveau des environnements de production. Les environnements avec un petit nombre de contrôleurs de domaine et d’objets Active Directory connectés via des liaisons de réseau étendu (WAN) à haute disponibilité peuvent être mis à niveau en quelques heures seulement. Vous devrez peut-être faire plus attention aux déploiements d’entreprise qui ont des centaines de contrôleurs de domaine ou des centaines de milliers d’objets Active Directory. Dans ce cas, vous pouvez effectuer la mise à niveau sur plusieurs semaines ou mois.

Utilisez les mises à niveau « Dry-run » dans le labo pour effectuer les tâches suivantes :

• Comprendre le fonctionnement interne du processus de mise à niveau et les risques associés.
• Exposez les zones de problème potentielles pour le processus de déploiement dans votre environnement.
• Testez et développez des plans de secours en cas d’échec de la mise à niveau.
• Définissez le niveau de détail approprié à appliquer au processus de mise à niveau pour le domaine de production.

Contrôleurs de domaine sans espace disque suffisant

Sur les contrôleurs de domaine dont l’espace disque est insuffisant, procédez comme suit pour libérer de l’espace disque supplémentaire sur le volume qui héberge les fichiers journaux et Ntds.dit :

1. Supprimez les fichiers inutilisés, y compris les fichiers *.tmp ou les fichiers mis en cache utilisés par les navigateurs Internet. Pour ce faire, tapez les commandes suivantes (appuyez sur Entrée après chaque commande) :

   cd /d drive\  
   del *.tmp /s  
   

2. Supprimez tous les fichiers de vidage utilisateur ou mémoire. Pour ce faire, tapez les commandes suivantes (appuyez sur Entrée après chaque commande) :

   cd /d drive\  
   del *.dmp /s  
   

3. Supprimez ou déplacez temporairement les fichiers auxquels vous pouvez accéder à partir d’autres serveurs ou réinstallez facilement. Les fichiers que vous pouvez supprimer et remplacer facilement incluent ADMINPAK, les outils de support et tous les fichiers du dossier %systemroot%\System32\Dllcache.

4. Supprimez les profils utilisateur anciens ou inutilisés. Pour ce faire, cliquez sur Démarrer, cliquez avec le bouton droit sur Poste de travail, cliquez sur Propriétés, cliquez sur l’onglet Profils utilisateur , puis supprimez tous les profils correspondant aux comptes anciens et inutilisés. Ne supprimez pas les profils qui peuvent être pour les comptes de service.

5. Supprimez les symboles dans %systemroot%\Symbols. Pour ce faire, tapez la commande suivante : rd /s %systemroot%\symbols Selon que les serveurs ont un ensemble de symboles complet ou petit, cela peut gagner environ 70 Mo à 600 Mo.

6. Effectuer une défragmentation hors connexion. Une défragmentation hors connexion du fichier Ntds.dit peut libérer de l’espace, mais nécessite temporairement le double de l’espace du fichier DIT actuel. Effectuez la défragmentation hors connexion à l’aide d’autres volumes locaux, le cas échéant. Vous pouvez également utiliser l’espace sur un serveur réseau mieux connecté pour effectuer la défragmentation hors connexion. Si l’espace disque n’est toujours pas suffisant, supprimez de manière incrémentielle les comptes d’utilisateur, les comptes d’ordinateur, les enregistrements DNS et les objets DLT inutiles d’Active Directory.