Ce navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Cet article explique comment mettre à niveau les contrôleurs de domaine Microsoft Windows 2000 vers Windows Server 2003 et comment ajouter de nouveaux contrôleurs de domaine Windows Server 2003 aux domaines Windows 2000.
Numéro de base de connaissances d’origine : 325379
Cet article explique comment mettre à niveau les contrôleurs de domaine Microsoft Windows 2000 vers Windows Server 2003 et comment ajouter de nouveaux contrôleurs de domaine Windows Server 2003 aux 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 :
Avant de mettre à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003 ou avant d’ajouter de nouveaux contrôleurs de domaine Windows Server 2003 à un domaine Windows 2000, procédez comme suit :
Stockez les clients qui accèdent aux ressources dans le domaine qui hébergent les contrôleurs de domaine Windows Server 2003 pour la 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 et imprimantes partagés 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 Install 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 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.
Microsoft Windows 95
Installez le client de 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.
Client réseau Microsoft 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 un disque de floppy de démarrage pour copier des fichiers du 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 reçoivent le message d’erreur suivant lorsqu’ils essaient de se connecter à une ressource réseau :
- Erreur -36 E/S
Installez les logiciels 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 si une version mise à jour existe. 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 exécutant 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 connexion du service SMB dans la 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é organisationnelle 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 :
Signer numériquement les communications (toujours)
Si les contrôleurs de domaine ne se trouvent pas dans l’unité organisationnelle du contrôleur de domaine, vous devez lier l’objet de stratégie de groupe du contrôleur de domaine par défaut à toutes les unités organisationnelles qui hébergent les contrôleurs de domaine Windows 2000 ou Windows Server 2003. Vous pouvez également configurer la connexion de service SMB à un objet de stratégie de groupe lié à ces unités organisationnelles.
Stockez les contrôleurs de domaine qui se trouvent dans le domaine et dans la forêt :
Assurez-vous 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érieur. 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 disposer d’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 Windows 2000 SP4, Windows XP et les ordinateurs clients 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 fonctionnera pas. Pour résoudre ce comportement, les contrôleurs de domaine administrés à distance doivent avoir un minimum de Windows 2000 SP3 installé. 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 :
dsa.msc /server=ipaddressPour 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 de 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
Notes
Les attributs du contrôleur de domaine ne suivent pas l’installation des correctifs logiciels individuels.
Vérifiez la réplication Active Directory de bout en bout dans toute la forêt.
Vérifiez que chaque contrôleur de domaine dans la forêt mise à niveau réplique tous ses contextes de nommage dé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 de 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 « Plus delta » de la sortie repadmin ne doivent pas être significativement supérieures à la fréquence de réplication sur les liens de site ou les 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 être répliqués entrants en moins de la durée de vie de Tombstone (TSL) nombre de jours (par défaut, 60 jours). Si la réplication ne peut pas être effectuée en fonction, 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 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 des 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 un échec de dégradation de contrôleur de domaine
Effectuez cette action uniquement en dernier recours pour récupérer l’installation du système d’exploitation et les programmes installés. Vous perdrez des objets et des 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, leurs groupes et les 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 pour un nombre supérieur à tombstonelifetime nombre de jours. Dans ce cas, vous pouvez réanier les 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 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 avec force les contrôleurs de domaine qui n’ont effectué aucune réplication entrante sur une partition donnée dans le nombre de jours de vie tombstone et supprimer leurs métadonnées restantes de la forêt Active Directory à l’aide de Ntdsutil et d’autres utilitaires. Contactez votre fournisseur de support ou Microsoft PSS pour obtenir de l’aide supplémentaire.
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 à partir du Kit de ressources pour déterminer s’il existe des incohérences dans les stratégies dans un domaine. Utilisez Healthcheck à partir des outils de prise en charge de Windows Server 2003 pour déterminer si la fonction des jeux de réplicas de partage Sysvol fonctionne correctement dans chaque domaine.
Si le contenu du partage Sysvol est incohérent, résolvez toutes les incohérences.
Utilisez Dcdiag.exe à partir 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
Stockez les rôles d’opérations.
Les maîtres d’opérations de schéma et d’infrastructure sont utilisés pour introduire des modifications de schéma à l’échelle du domaine et des forêts apporté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ésident sur les contrôleurs de domaine en direct et que chaque propriétaire de rôle a effectué la 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 à l’échelle du domaine. Les rôles de maître des opérations 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 les contrôleurs de domaine supprimés.
Vérifiez que la réplication entrante d’Active Directory a été effectuée 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 placement, cliquez sur les numéros d’article suivants pour afficher les articles de la Base de connaissances Microsoft :
197132 rôles Windows 2000 Active Directory FSMO
223346 placement et optimisation FSMO sur les contrôleurs de domaine Active Directory
Révision EventLog
Examinez les journaux des événements sur tous les contrôleurs de domaine pour les événements problématiques. Les journaux d’événements ne doivent pas contenir de messages d’événements sérieux qui indiquent un problème avec l’un des processus et composants suivants :
connectivité physique
connectivité réseau
inscription de noms
résolution de noms
authentication
Stratégie de groupe
stratégie de sécurité
sous-système de disque
schéma
Topologie
moteur de réplication
Inventaire de l’espace disque
Le volume qui héberge le fichier de base de données Active Directory, Ntds.dit, doit avoir un espace libre égal à au moins 15 à 20 % de la taille de fichier Ntds.dit. Le volume qui héberge le fichier journal Active Directory doit également avoir un espace libre égal à au moins 15 à 20 % de la taille de fichier Ntds.dit. Pour plus d’informations sur la libération d’espace disque supplémentaire, consultez la section « Contrôleurs de domaine sans espace disque suffisant » de cet article.
Scavenging DNS (facultatif)
Activez la détection DNS à intervalles de 7 jours pour tous les serveurs DNS de la forêt. Pour obtenir de meilleurs résultats, effectuez cette opération 61 jours ou plus avant de mettre à niveau le système d’exploitation. Cela fournit le démon de nettoyage DNS suffisant pour collecter les anciens objets DNS lorsqu’une défragmentation hors connexion est effectuée sur le fichier Ntds.dit.
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 des 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
Sauvegarde de l’état du système
Effectuez une sauvegarde de l’état du 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.
Notes
adprep /forestprep .adprep .Le schéma Exchange 2000 définit trois attributs inetOrgPerson avec des attributs LDAPDisplayNames non conformes à request for Comment (RFC) : houseIdentifier, secrétaire et labeledURI.
La commande Windows 2000 inetOrgPerson Kit et Windows Server 2003 adprep définissent les versions de plainte RFC des trois mêmes attributs avec ldapDisplayNames identiques que les versions non conformes À RFC.
Lorsque la commande Windows Server 2003 adprep /forestprep est exécutée sans scripts correctives dans une forêt qui contient des modifications de schéma Windows 2000 et Exchange 2000, ldapDisplayNames pour les attributs houseIdentifier, labeledURI et secrétaire deviennent mangled. Un attribut devient « mangled » si « Dup » ou d’autres caractères uniques sont ajoutés au début du nom d’attribut conflictuel 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 noms LDAPDisplayNames mangled pour ces attributs dans les cas suivants :
adprep /forestprep dans une forêt qui contient le schéma Windows 2000 avant d’ajouter le schéma Exchange 2000.adprep /forestprep .adprep /forestprep .Les attributs mangled se produisent dans Windows 2000 dans les cas suivants :
adprep /forestprep sans exécuter d’abord les scripts de nettoyage. Les plans d’action pour chaque scénario suivent :Si les modifications de schéma Exchange 2000 sont introduites dans votre forêt Windows 2000 une fois la commande Windows Server 2003 adprep /forestprep exécutée, 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 ».
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 , tenez compte du plan d’action suivant :
Connectez-vous à la console du maître des opérations de schéma à l’aide d’un compte membre du groupe de sécurité Admins du schéma.
Cliquez sur Démarrer, cliquez sur Exécuter, tapez notepad.exe dans la zone Ouvrir, puis cliquez sur OK.
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
-
Vérifiez qu’il n’y a pas d’espace à la fin de chaque ligne.
Dans le menu Fichier , cliquez sur Enregistrer. Dans la boîte de dialogue Enregistrer sous, procédez comme suit :
Exécutez le script InetOrgPersonPrevent.ldf.
Cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd dans la zone Ouvrir , puis cliquez sur OK.
À l’invite de commandes, tapez ce qui suit, puis appuyez sur Entrée : cd %userprofile%
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 :
Par exemple, la syntaxe de commande d’une forêt Active Directory dont le domaine racine de forêt est TAILSPINTOYS.COM :
c :\documents et paramètres\administrator>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X « dc=tailspintoys,dc=com »
Notes
Vous devrez peut-être modifier la sous-clé de Registre autorisée de la mise à jour du schéma 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.
Vérifiez que les attributs LDAPDisplayNames pour 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 en tant que msExchAssistantName, msExchLabeledURI et msExchHouseIdentifier avant d’exécuter les commandes Windows Server 2003 adprep /forestprep .
Accédez à la section « Vue d’ensemble : Mise à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003 » pour exécuter les commandes et /domainprep les adprep /forestprep commandes.
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, secrétaire et labeledURI deviendront mangled. Pour identifier les noms bascules, utilisez Ldp.exe pour localiser les attributs affectés :
Installez Ldp.exe à partir du dossier Support\Tools du média Microsoft Windows 2000 ou Windows Server 2003.
Démarrez Ldp.exe à partir d’un contrôleur de domaine ou d’un ordinateur membre dans la forêt.
Enregistrez le chemin d’accès de nom unique pour l’attribut SchemaNamingContext. Par exemple, pour un contrôleur de domaine dans la forêt CORP.ADATUM.COM, le chemin d’accès de nom unique peut être CN=Schema,CN=Configuration,DC=corp,DC=company,DC=com.
Dans le menu Parcourir , cliquez sur Rechercher.
Utilisez les paramètres suivants pour configurer la boîte de dialogue Rechercher :
Les attributs Mangled houseIdentifier, secrétaire 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
Si les LDAPDisplayNames pour labeledURI, secretary et houseIdentifier ont été mangledées à l’étape 6, exécutez le script InetOrgPersonFix.ldf Windows Server 2003 pour récupérer, puis accédez à la section « Mise à niveau des contrôleurs de domaine Windows 2000 avec Winnt32.exe ».
Créez un dossier nommé %Systemdrive%\IOP, puis extrayez le fichier InetOrgPersonFix.ldf dans ce dossier.
À l’invite de commandes, tapez cd %systemdrive%\iop.
Extrayez le fichier InetOrgPersonFix.ldf à partir du fichier Support.cab qui se trouve dans le dossier Support\Tools du support d’installation de Windows Server 2003.
À partir de la console du maître des opérations de schéma, chargez le fichier InetOrgPersonFix.ldf à l’aide de Ldifde.exe pour corriger l’attribut LdapDisplayName des attributs houseIdentifier, secrétaire et labeledURI. Pour ce faire, tapez la commande suivante, où <X> est une constante sensible à la casse et <un chemin d’accès 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 :
Vérifiez que les attributs houseIdentifier, secrétaire et labeledURI dans le contexte d’affectation de noms de schéma ne sont pas « mangled » avant d’installer Exchange 2000.
La commande Windows Server 2003 adprep que vous exécutez à partir du dossier \I386 du média 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 :
Descripteurs de sécurité par défaut améliorés pour les classes d’objets
Nouveaux attributs d’utilisateur et de groupe
Les nouveaux objets de schéma et attributs tels que l’utilitaire inetOrgPersonThe adprep prennent en charge deux arguments de ligne de commande :
adprep /forestprep: exécute les 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 unique effectuée sur le modèle FSMO (Schema Operation Master) de la forêt. L’opération de préparation de forêt doit effectuer et répliquer vers le maître d’infrastructure de chaque domaine avant de pouvoir s’exécuter adprep /domainprep dans ce domaine.
La adprep /domainprep commande est une opération unique que vous exécutez sur le contrôleur de domaine maître des opérations d’infrastructure 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 de 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 effectuer aucune des actions suivantes, sauf si les opérations /forestprep et /domainprep se sont terminées et répliquées sur tous les contrôleurs de domaine de ce domaine :
Notes
Vous pouvez mettre à niveau les serveurs et ordinateurs membres Windows 2000 vers des ordinateurs membres Windows Server 2003 chaque fois que vous le souhaitez.
Promouvoir de nouveaux contrôleurs de domaine Windows Server 2003 dans le domaine à l’aide de Dcpromo.exe.Le domaine qui héberge le maître des opérations de schéma est le seul domaine où vous devez exécuter les deux adprep /forestprep et adprep /domainprep. Dans tous les autres domaines, vous devez uniquement exécuter adprep /domainprep.
Les adprep /forestprep commandes et adprep /domainprep les commandes n’ajoutent pas d’attributs au jeu d’attributs partiels du catalogue global ou provoquent une synchronisation complète du catalogue global. La version RTM de adprep /domainprep cette opération 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.
Une fois les modifications apportées adprep /forestprep et adprep /domainprep entièrement répliquées, 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.
Pour préparer une forêt et des domaines Windows 2000 à accepter les contrôleurs de domaine Windows Server 2003, suivez d’abord ces étapes dans un environnement lab, puis dans un environnement de production :
Assurez-vous que vous avez terminé toutes les opérations de la phase « Inventaire des forêts » avec une attention particulière aux éléments suivants :
Connectez-vous à la console du maître des opérations de schéma avec un compte membre du groupe de sécurité Admins du schéma.
Vérifiez que le FSMO de schéma 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.)
La documentation Microsoft anticipée vous recommande d’isoler le maître des opérations de schéma 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 peut entraîner le rejet des modifications de schéma lorsqu’elle est redémarrée sur un réseau privé.
Exécutez adprep sur le maître des opérations de schéma. Pour ce faire, cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK. Dans le maître des opérations de schéma, tapez la commande suivante :
X:\I386\adprep /forestprep
où X :\I386\ est le chemin d’accès du support d’installation de Windows Server 2003. Cette commande exécute la mise à niveau du schéma à l’échelle de la forêt.
Notes
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 suivant, peuvent être ignorés :
Vérifiez que la adprep /forestprep commande s’est correctement exécutée sur le maître des opérations de schéma. Pour ce faire, à partir de la console du maître des opérations de schéma, 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) La 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 ce n’est pas le cas, vérifiez les éléments suivants :
Le chemin complet de Adprep.exe situé dans le dossier \I386 du support d’installation a été spécifié lors adprep de l’exécution. Pour cela, 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 .
Si vous avez désactivé la réplication sortante sur le maître des opérations de schéma à l’étape 4, activez la réplication afin que les modifications apportées au adprep /forestprep schéma puissent se propager. Pour ce faire, procédez comme suit :
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 :
adprep /forestprep s’ajoutent, telles que 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 quels objets et attributs il doit y avoir. Par exemple, inetOrgPerson est défini dans Sch18.ldf.Recherchez mangled LDAPDisplayNames. Si vous trouvez des noms bascules, accédez au scénario 3 du même article.
Connectez-vous à la console du maître des opérations de schéma avec un compte membre du groupe Administrateurs de schémas de la forêt qui héberge le maître des opérations de schéma.
Exécutez adprep /domainprep une fois que les modifications /forestprep sont entièrement répliquées sur le contrôleur de domaine maître d’infrastructure dans chaque domaine qui hébergera les contrôleurs de domaine Windows Server 2003. Pour ce faire, procédez comme suit :
Identifiez le contrôleur de domaine maître d’infrastructure 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.
Notes
L’administrateur d’entreprise peut ne pas être membre du groupe de sécurité Administrateurs de domaine dans les domaines enfants de la forêt.
Exécutez adprep /domainprep sur le maître d’infrastructure. Pour ce faire, cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd, puis, dans le masque de l’infrastructure, tapez la commande suivante : X:\I386\adprep /domainprep où X :\I386\ est le chemin d’accès du support d’installation de Windows Server 2003. Cette commande exécute des modifications à l’échelle du domaine dans le domaine cible.
Notes
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.
Vérifiez que domainprep s’est terminé correctement. Pour ce faire, vérifiez les éléments suivants :
adprep /domainprep terminée sans erreur.adprep /domainprep ne s’exécute pas, vérifiez les éléments suivants :adprep est membre du groupe de sécurité Administrateurs du domaine dans le domaine que vous mettez à niveau. Pour cela, utilisez la commande whoami /all.adprep. Pour ce faire, à une invite de commandes, tapez la commande suivante : x :\i386\adprep /forestprep où x est le lecteur qui héberge le support d’installation.adprep cela ne fonctionne toujours pas, affichez le fichier Adprep.log dans le dossier %systemroot%\System32\Debug\Adprep\Logs\ Latest_log .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 path of domain que vous mettez à niveau existe et la valeur de l’attribut Revision correspond à la valeur du même attribut sur le maître d’infrastructure du domaine.
- (Facultatif) Rechercher des objets, des attributs ou des modifications de liste de contrôle d’accès (ACL) ajoutées adprep /domainprep . Répétez les étapes 1 à 4 sur le maître d’infrastructure 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 maintenant 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.
Une fois les modifications apportées à /forestprep et /domainprep entièrement répliquées et que vous avez pris une décision sur l’interopérabilité de 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 être parmi les premiers contrôleurs de domaine qui exécutent Windows Server 2003 dans la forêt dans chaque domaine :
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 Ajouter/supprimer des programmes dans Panneau de configuration. (Mises à niveau de Windows 2000 uniquement.)
Installez tous les fichiers de correctif logiciel ou d’autres correctifs que Microsoft ou l’administrateur détermine est important.
Vérifiez chaque contrôleur de domaine pour connaître les éventuels problèmes de mise à niveau. Pour ce faire, exécutez la commande suivante à partir du dossier \I386 du support d’installation : winnt32.exe /checkupgradeonly résolvez les problèmes identifiés par la vérification de compatibilité.
Exécutez WINNT32.EXE à partir du dossier \I386 du support d’installation, puis redémarrez le contrôleur de domaine 2003 mis à niveau.
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 de clients NT NT 4.0 SP6 ou 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é organisationnelle Contrôleurs de domaine, puis liez cette stratégie à toutes les unités organisationnelles qui hébergent les 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 : signer numériquement les communications (toujours)
Vérifiez l’intégrité de la mise à niveau à l’aide des points de données suivants :
Notes
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é.
Installez les outils d’administration Windows Server 2003 (mises à niveau de Windows 2000 et contrôleurs non de domaine Windows Server 2003 uniquement). Adminpak.msi se trouve dans le dossier \I386 du CD-ROM Windows Server 2003. Le support Windows Server 2003 contient des outils de support mis à jour dans le fichier Support\Tools\Suptools.msi. Veillez à réinstaller ce fichier.
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 le stockage verrouillé afin de ne pas les utiliser accidentellement pour restaurer un contrôleur de domaine qui exécute désormais Windows Server 2003.
(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 une fois le magasin d’instances unique (SIS) terminé (mises à niveau de Windows 2000 uniquement).
Le SIS examine les autorisations existantes sur les objets stockés dans Active Directory, puis applique un descripteur de sécurité plus efficace sur 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 d’abord le système d’exploitation Windows Server 2003. Vous bénéficiez du magasin de descripteur de sécurité amélioré 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 d’instances unique est terminée et sert de file d’attente que l’administrateur effectue une 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 d’un maximum de 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 d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :
232122 Effectuer une défragmentation hors connexion de la base de données Active Directory
Examinez le service serveur DLT. Les contrôleurs de domaine Windows Server 2003 désactivent le service DLT Server lors des installations nouvelles et mises à niveau. Si les clients Windows 2000 ou Windows XP de votre organisation utilisent le service DLT Server, utilisez la 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 manière incrémentielle les objets de suivi de liens distribués d’Active Directory. Pour plus d’informations à ce sujet, cliquez sur le numéro de l’article suivant pour l’afficher 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. Attendez le nombre de jours tombstonelifetime (par défaut, 60 jours) après la suppression du dernier objet DLT et pour que le garbage collection se termine, puis utilisez NTDSUTIL.EXE pour effectuer une défragmentation hors connexion du fichier Ntds.dit.
Configurez la structure d’unité d’organisation recommandée. Microsoft recommande aux administrateurs de déployer activement la structure d’unité d’organisation 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, redirigez 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 organisationnelles spécifié par l’administrateur.
Pour plus d’informations sur la structure d’unité organisationnelle de bonne pratique, consultez la section « Création d’une conception d’unité organisationnelle » du livre blanc « Best Practice Active Directory Design for Managing Windows Networks ». Pour afficher le livre blanc, consultez le site Web Microsoft suivant : https://technet.microsoft.com/library/bb727085.aspx Pour plus d’informations sur la modification du conteneur par défaut où se trouvent les utilisateurs, les ordinateurs et les 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 rediriger les utilisateurs et les conteneurs d’ordinateurs dans les domaines Windows Server 2003
Répétez les étapes 1 à 10 requises pour chaque contrôleur de domaine Windows Server 2003 nouveau ou mis à niveau dans la forêt et l’étape 11 (structure d’unité d’organisation Best Practice) pour chaque domaine Active Directory.
Dans Récapitulatif :
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 s’effectue en douceur, vous pouvez vous attendre à des résultats similaires dans les environnements de production. Pour les environnements complexes, l’environnement lab doit mettre en miroir l’environnement de production dans les domaines suivants :
adprep /forestprepadprep /domainprepUne compréhension du processus de mise à niveau et de la complexité de l’environnement combiné à 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 liens de réseau étendu à haute disponibilité (WAN) peuvent être mis à niveau en quelques heures seulement. Vous devrez peut-être prendre plus de soin avec les 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 au cours de plusieurs semaines ou mois.
Utilisez les mises à niveau « Exécution sèche » dans le labo pour effectuer les tâches suivantes :
Sur les contrôleurs de domaine avec un espace disque insuffisant, procédez comme suit pour libérer de l’espace disque supplémentaire sur le volume qui héberge les fichiers Ntds.dit et Log :
Supprimez les fichiers inutilisés, y compris *.tmp fichiers ou 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
Supprimez tous les fichiers de vidage de mémoire ou d’utilisateur. Pour ce faire, tapez les commandes suivantes (appuyez sur Entrée après chaque commande) :
cd /d drive\
del *.dmp /s
Supprimez ou déplacez temporairement des fichiers auxquels vous pouvez accéder à partir d’autres serveurs ou réinstaller 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.
Supprimez les anciens profils utilisateur ou inutilisés. Pour ce faire, cliquez sur Démarrer, cliquez avec le bouton droit sur Mon ordinateur, cliquez sur Propriétés, sur l’onglet Profils utilisateur, puis supprimez tous les profils pour les comptes anciens et inutilisés. Ne supprimez aucun profil pouvant être destiné aux comptes de service.
Supprimez les symboles à l’emplacement %systemroot%\Symbols. Pour ce faire, tapez la commande suivante : rd /s %systemroot%\symbols selon que les serveurs ont un jeu de symboles complet ou petit, cela peut atteindre environ 70 Mo à 600 Mo.
Effectuez une défragmentation hors connexion. Une défragmentation hors connexion du fichier Ntds.dit peut libérer de l’espace, mais nécessite temporairement un double espace du fichier DIT actuel. Effectuez la défragmentation hors connexion à l’aide d’autres volumes locaux si l’un d’eux est disponible. Vous pouvez également utiliser de l’espace sur un serveur réseau connecté le mieux adapté 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’utilisateurs inutiles, les comptes d’ordinateur, les enregistrements DNS et les objets DLT d’Active Directory.
Notes
Active Directory ne supprime pas les objets de la base de données tant que le nombre tombstonelifetime de jours (par défaut, 60 jours) est passé et que le garbage collection se termine. Si vous réduisez tombstonelifetime à une valeur inférieure à la réplication de bout en bout dans la forêt, vous pouvez entraîner des incohérences dans Active Directory.
Entrainement
Module
Migration d’Active Directory Domain Services - Training
Déterminez la meilleure approche pour déplacer des contrôleurs de domaine vers Windows Server 2025. Découvrez comment l’outil de migration Active Directory peut regrouper des domaines dans une forêt ou migrer des domaines vers une nouvelle forêt AD DS.