Cet article explique comment mettre à niveau des contrôleurs de domaine Microsoft Windows 2000 vers Microsoft Windows Server 2003 et comment ajouter de nouveaux contrôleurs de domaine Windows Server 2003 à des domaines Windows 2000.
Avant de mettre à niveau des 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 :
Inventoriez les clients qui accèdent aux ressources du domaine qui héberge les contrôleurs de domaine Windows Server 2003 pour assurer la compatibilité avec la signature SMB :
Chaque contrôleur de domaine Windows Server 2003 autorise la signature SMB dans sa stratégie de sécurité locale. Assurez-vous que tous les clients du réseau qui utilisent le protocole SMB/CIFS pour accéder aux fichiers et aux imprimantes partagés dans les domaines hébergeant les contrôleurs de domaine Windows Server 2003 peuvent être configurés ou être 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 récents prenant en charge la signature SMB. Pour plus d'informations sur la façon de désactiver la signature SMB, reportez-vous à la section « Pour désactiver la signature SMB » à la fin de cette étape.
Plans d'action
La liste suivante présente des plans d'action pour les clients SMB les plus courants :
Microsoft Windows Server 2003, Microsoft Windows XP Professionnel, Microsoft Windows 2000 Server, Microsoft Windows Professionnel et Microsoft Windows 98
Aucune action n'est nécessaire.
Microsoft Windows NT 4.0
Installez le Service Pack 3 ou version ultérieure (le Service Pack 6A est recommandé) sur tous les ordinateurs Windows NT 4.0 qui accèdent aux domaines contenant des ordinateurs Windows Server 2003. Ou bien, désactivez temporairement la signature SMB sur les contrôleurs de domaine Windows Server 2003. Pour plus d'informations sur la façon de désactiver la signature SMB, reportez-vous à la section « Pour désactiver la signature SMB » à la fin de cette étape.
Microsoft Windows 95
Installez le client de service d'annuaire Windows 9x 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 Windows 9x original est disponible sur le CD-ROM Windows 2000 Server. Toutefois, ce module complémentaire a été remplacé par un client de service d'annuaire Windows 9x amélioré. Pour des informations sur la procédure à suivre pour désactiver la signature SMB, reportez-vous à la section "Pour désactiver la signature SMB" à la fin de cette étape.
Client réseau Microsoft pour MS-DOS et clients Microsoft LAN Manager
Vous pouvez utiliser le Client réseau Microsoft pour MS-DOS et le client réseau Microsoft LAN Manager 2.x pour fournir l'accès aux ressources du réseau. Vous pouvez également les associer à une disquette de démarrage pour copier les fichiers du système d'exploitation et d'autres fichiers d'un annuaire partagé sur un serveur de fichiers pour composer une routine d'installation des logiciels. Ces clients ne prennent pas en charge la signature SMB. Utilisez une autre méthode d'installation ou désactivez la signature SMB. Pour des informations sur la procédure à suivre pour désactiver la signature SMB, reportez-vous à 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 afficheront le message d'erreur suivant lors des tentatives de connexion à 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 des informations sur la procédure à suivre pour désactiver la signature SMB, reportez-vous à 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 vérifier 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 vous ne pouvez pas installer les mises à jour logicielles sur les contrôleurs de domaine concernés exécutant Windows 95, Windows NT 4.0 ou d'autres clients installés avant la parution de Windows Server 2003, désactivez temporairement les exigences de signature du service SMB dans Stratégie de groupe afin de pouvoir déployer la mise à jour du logiciel client.
Vous pouvez désactiver la signature du service SMB dans le noeud 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 signées numériquement (toujours)
Si des contrôleurs de domaine se trouvent en dehors de l'unité d'organisation du contrôleur de domaine, vous devez lier l'objet de stratégie de groupe du contrôleur de domaine par défaut (Objet de stratégie de groupe) à 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 signature du service SMB dans un Objet de stratégie de groupe qui est lié à ces unités d'organisation.
Inventoriez les contrôleurs de domaine se trouvant dans le domaine et la forêt :
Assurez-vous que tous les contrôleurs de domaine Windows 2000 de la forêt possèdent tous les correctifs logiciels et les Service Packs appropriés.
Microsoft recommande que tous les contrôleurs de domaine Windows 2000 exécutent le Service Pack 4 (SP4) de Windows 2000 ou des systèmes d'exploitation plus récents. Si vous ne pouvez pas déployer complètement Windows 2000 SP4 ou version ultérieure, tous les contrôleurs de domaine Windows 2000 doivent comporter un fichier Ntdsa.dll dont l'horodatage est postérieure au 4 juin 2001 et la version supérieure à 5.0.2195.3673.
Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
331161
(http://support.microsoft.com/kb/331161/
)
Correctifs à installer sur les contrôleurs de domaine Windows 2000 avant d'exécuter Adprep /Forestprep pour préparer la forêt et les domaines en vue de l'ajout de contrôleurs de domaine Windows Server 2003
Par défaut, les outils d'administration Active Directory des ordinateurs clients Windows 2000 SP4, Windows XP et Windows Server 2003 utilisent la signature LADP (Lightweight Directory Access Protocol). Si de tels ordinateurs utilisent (ou se replient vers) 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, les contrôleurs de domaine administrés à distance doivent disposer d'au moins Windows 2000 SP3. Sinon, vous devez désactiver la signature LDAP sur les clients qui exécutent les outils d'administration.
Pour plus d'informations sur LDAP, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft.
325465
(http://support.microsoft.com/kb/325465/
)
Les contrôleurs de domaine Windows 2000 nécessitent SP3 ou version ultérieure lors de l'utilisation des outils d'administration Windows Server 2003
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 des composants logiciels enfichables Microsoft Management Console (MMC) sur un contrôleur de domaine spécifique désigné par son adresse IP. Par exemple, vous cliquez sur Démarrer, sur Exécuter, puis vous tapez la commande suivante :
dsa.msc /server=ipaddress
Pour déterminer le système d'exploitation et le niveau de version de 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 de la forêt, puis exécutez la commande repadmin suivante sur un contrôleur de domaine dans chaque domaine dans la forêt :
>repadmin /showattr nom du contrôleur de domaine dans le domaine cible 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 n'effectuent pas le suivi de l'installation des correctifs individuels.
Vérifiez la réplication Active Directory de bout en bout à travers la forêt.
Vérifiez que chaque contrôleur de domaine de la forêt mise à niveau réplique tous ses contextes de nommage locaux avec ses partenaires conformément au calendrier défini par les liens de site ou les objets connexion. Utilisez la version Windows Server 2003 de Repadmin.exe sur un ordinateur membre Windows XP ou Windows Server 2003 de la forêt avec les arguments suivants :
REPADMIN /REPLSUM /BYSRC /BYDEST /SORT:DELTA <-output formatted to fit on page
DestDC largest delta fails/total %% error
NA-DC-01 13d.21h:10m:10s 97 / 143 67 (8240) There is no such object...
NA-DC-02 13d.04h:11m:07s 180 / 763 23 (8524) The DSA operation...
NA-DC-03 12d.03h:54m:41s 5 / 5 100 (8524) The DSA operation...
Tous les contrôleurs de domaine de la forêt doivent répliquer Active Directory sans erreur et les valeurs dans la colonne « Largest Delta » de la sortie de repadmin ne doivent pas être beaucoup plus importantes que la fréquence de réplication sur les liens de site ou objets connexion correspondants, utilisés par un contrôleur de domaine de destination donné.
Résolvez toutes les erreurs de réplication entre les contrôleurs de domaine qui n'ont pas pu effectuer de réplication entrante dans le nombre de jours de la durée de vie de désactivation (par défaut, 60 jours). Si la réplication ne peut pas fonctionner, vous pouvez devoir rétrograder de force les contrôleurs de domaine et les supprimer de la forêt en utilisant la commande metadata cleanup de Ntdsutil, puis les promouvoir de 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 façon de supprimer des contrôleurs de domaine Windows 2000 orphelins de leur domaine, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
216498
(http://support.microsoft.com/kb/216498/
)
Comment faire pour supprimer des données dans Active Directory après l'échec d'une rétrogradation de contrôleur de domaine.
Prenez cette mesure uniquement en dernier recours pour récupérer l'installation du système d'exploitation et les programmes installés. Vous perdrez les objets et les attributs non répliqués sur les contrôleurs de domaine orphelins, notamment les utilisateurs, les ordinateurs, les relations d'approbation, les mots de passe, les groupes et les appartenances aux groupes.
Soyez prudent lorsque vous essayez de résoudre des erreurs de la réplication sur des contrôleurs de domaine qui n'ont pas répliqué de modifications entrantes pour une partition Active Directory particulière pendant une période excédant le nombre de jours de la durée de vie de désactivation. Dans cette situation, 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 transitifs ou directs n'ont jamais reçu la suppression dans les 60 jours précédents.
Pensez à supprimer tous les objets en attente qui résident sur les contrôleurs de domaine qui n'ont pas exécuté de réplication entrante dans les 60 derniers jours. Vous pouvez rétrograder de force les contrôleurs de domaine qui n'ont pas exécuté de réplication entrante sur une partition donnée dans le nombre de jours de la durée de vie de désactivation et supprimer leurs métadonnées restantes de la forêt Active Directory en utilisant Ntdsutil et d'autres utilitaires. Contactez votre fournisseur de support technique ou les services de Support technique Microsoft pour obtenir une aide supplémentaire.
Vérifiez la cohérence du contenu du partage Sysvol.
Vérifiez que la partie système de fichiers de la stratégie de groupe est cohérente. Vous pouvez utiliser l'utilitaire Gpotool.exe du Kit de ressources pour déterminer s'il y a des incohérences entre des stratégies dans un domaine. Utilisez les outils de support Windows Server 2003 Healthcheck pour déterminer si les jeux de réplicas du partage SYSVOL fonctionnent correctement dans chaque domaine.
Si le contenu du partage Sysvol est incohérent, résolvez toutes les incohérences.
Utilisez les outils de support Dcdiag.exe pour vérifier que tous les contrôleurs de domaine possèdent des partages Netlogon et Sysvol. Pour cela, tapez la commande suivante à l'invite :
DCDIAG.EXE /e /test:frssysvol
Inventoriez les rôles des opérations.
Les maîtres d'opérations de schéma et d'infrastructure introduisent les modifications de schéma opérées par l'utilitaire adprep de Windows Server 2003 à l'échelle de la forêt et des domaines. Vérifiez que le contrôleur de domaine qui tient le rôle de schéma et le rôle d'infrastructure pour chaque domaine dans la forêt réside sur des contrôleurs de domaine en ligne et que chaque propriétaire d'un rôle a exécuté la réplication entrante sur toutes ses partitions depuis son dernier redémarrage.
La commande DCDIAG /test:FSMOCHECK permet d'afficher les rôles opérationnels à l'échelle de la forêt et du domaine. Les rôles de maître d'opérations qui résident sur des contrôleurs de domaine inexistants doivent être remis à un contrôleur de domaine sain en utilisant NTDSUTIL. Les rôles qui résident sur des contrôleurs de domaine défectueux doivent être transférés, dans la mesure du possible. Sinon, ils doivent être saisis. La commande NETDOM QUERY FSMO n'identifie pas les rôles FSMO qui résident sur les contrôleurs de domaine qui ont été supprimés.
Vérifiez que le contrôleur de schéma et chaque maître d'infrastructure ont exécuté une réplication entrante d'Active Directory depuis leur dernier démarrage. Vous pouvez le vérifier grâce à la commande REPADMIN /SHOWREPS NOMCD, où NOMCD est le nom de l'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 ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft.
197132
(http://support.microsoft.com/kb/197132/
)
Rôles FSMO de Windows 2000 Active Directory
223346
(http://support.microsoft.com/kb/223346/
)
Placement et optimisation des rôles FSMO sur les contrôleurs de domaine Active Directory
Examen des journaux d'événements
Examinez les journaux d'événements sur tous les contrôleurs de domaine pour vérifier la présence d'événements problématiques. Les journaux d'événements ne doivent pas contenir de messages d'événements graves concernant les processus et composants suivants :
connectivité physique connectivité réseau enregistrement de nom résolution de nom authentification Stratégie de groupe stratégie de sécurité sous-système 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 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 l'espace disque supplémentaire, reportez-vous à la section « Contrôleurs de domaine ne disposant pas d'un espace disque suffisant » du présent article.
Nettoyage des DNS (facultatif)
Activez le nettoyage des DNS à 7 jours d'intervalle pour tous les serveurs DNS de la forêt. Pour obtenir les meilleurs résultats, effectuez cette opération 61 jours au moins avant de mettre à niveau le système d'exploitation. Cela donne au service de nettoyage DNS le temps nécessaire pour récupérer les anciens objets DNS lorsqu'une défragmentation hors connexion est effectuée sur le fichier Ntds.dit.
Désactivation du service Serveur DLT (facultatif)
Le service Serveur DLT est désactivé sur les installations nouvelles et mises à niveau des contrôleurs de domaine Windows Server 2003. Si vous n'utilisez pas le suivi de lien, vous pouvez désactiver le service Serveur DLT sur vos contrôleurs de domaine Windows 2000 et commencer la suppression des objets DLT de chaque domaine de la forêt. Pour plus d'informations, reportez-vous à la section « Recommandations de Microsoft relatives au service Serveur de suivi de lien distribué » de l'article suivant dans la base de connaissance Microsoft :
312403
(http://support.microsoft.com/kb/312403/
)
Suivi de liaisons distribuées sur les contrôleurs de domaine Windows
Sauvegarde de l'état du système
Effectuez une sauvegarde de l'état système d'au moins deux contrôleurs de domaine de 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
Remarques
Si Exchange 2000 Server est ou doit être installé dans une forêt Windows 2000, lisez cette section avant d'exécuter la commande adprep /forestprep de Windows Server 2003.
Le schéma Exchange 2000 définit trois attributs inetOrgPerson non conformes aux spécifications RFC (Request for Comment) LDAPDisplayNames : houseIdentifier, secretary et labeledURI.
Le Kit inetOrgPerson de Windows 2000 et la commande adprep de Windows Server 2003 définissent des versions, conformes aux RFC, de ces trois attributs avec des noms complets LDAP (LDAPDisplayNames) identiques aux versions conformes aux RFC.
Lorsque la commande adprep /forestprep de Windows Server 2003 est exécutée sans scripts correctifs dans une forêt contenant des modifications de schéma Windows 2000 et Exchange 2000, les noms complets LADP des attributs houseIdentifier, labeledURI et secretary sont décomposés. Un attribut est « décomposé » si « Dup » ou d'autres caractères uniques sont ajoutés au début du nom de l'attribut conflictuel pour que les objets et les attributs de l'annuaire aient des noms uniques.
Les forêts Active Directory ne sont pas vulnérables à la décomposition des noms complets LDAP pour ces attributs dans les cas suivants :
Si vous exécutez la commande adprep /forestprep de Windows Server 2003 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 une forêt où un contrôleur de domaine Windows Server 2003 était le premier contrôleur de domaine lors de la création de la forêt.
Si vous ajoutez le Kit inetOrgPerson de Windows 2000 à une forêt contenant le schéma Windows 2000, que vous installez des modifications de schéma Exchange 2000, puis que vous exécutez la commande adprep /forestprep de Windows Server 2003.
Si vous ajoutez un schéma Exchange 2000 à une forêt Windows 2000 existante, puis que vous exécutez la commande /forestprep d'Exchange 2003 avant d'exécuter la commande adprep /forestprep de Windows Server 2003.
Les attributs seront décomposés dans Windows 2000 dans les cas suivants :
Si vous ajoutez les versions Exchange 2000 des attributs labeledURI, houseIdentifier et secretary à une forêt Windows 2000 avant d'installer le Kit inetOrgPerson de Windows 2000.
Si vous ajoutez les versions Exchange 2000 des attributs labeledURI, houseIdentifier et secretary à une forêt Windows 2000 avant d'exécuter la commande adprep /forestprep de Windows Server 2003 et sans d'abord exécuter les scripts de nettoyage.
Plans d'action pour chaque scénario :
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
Scénario 2 : Les modifications de schéma Exchange 2000 sont installées avant que vous n'exécutiez la commande adprep /forestprep de Windows Server 2003
Si les modifications du schéma Exchange 2000 ont déjà été installées, mais que vous n'avez PAS exécuté la commande adprep /forestprep de Windows Server 2003, considérez le plan d'action suivant :
Ouvrez une session sur la console du maître d'opérations de schéma à l'aide d'un compte qui est membre du groupe de sécurité Administrateurs de schéma.
Cliquez sur Démarrer, sur Exécuter, puis tapez notepad.exe dans la zone Ouvrir et cliquez sur OK.
Copiez le texte suivant, y compris le trait d'union après « schemaUpdateNow: 1 » dans le Bloc-notes.
Vérifiez qu'aucun espace n'est inséré à la fin de chaque ligne.
Dans le menu Fichier, cliquez sur Enregistrer. Dans la boîte de dialogue Enregistrer sous, procédez comme suit :
Dans la zone Nom de fichier, tapez la ligne suivante :
\%userprofile%\InetOrgPersonPrevent.ldf
Dans la zone Type, cliquez sur Tous les fichiers.
Dans la zone Codage, cliquez sur Unicode.
Cliquez sur Enregistrer.
Quittez le Bloc-notes.
Exécutez le script InetOrgPersonPrevent.ldf.
Cliquez sur Démarrer, 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 "chemin d'accès du nom de domaine pour le domaine racine de la forêt"
Remarques relatives à la syntaxe :
DC=X est une constante sensible à la casse.
Le chemin d'accès du nom de domaine pour le domaine racine doit être entre guillemets.
Par exemple, la syntaxe de commande pour une forêt Active Directory dont le domaine racine est TAILSPINTOYS.COM est :
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 Schema Update Allowed si le message d'erreur suivant s'affiche :
La mise à jour du schéma n'est pas autorisée sur ce contrôleur de domaine. Soit 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.
Pour plus d'informations sur la façon de modifier cette sous-clé de Registre, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
285172
(http://support.microsoft.com/kb/285172/
)
La mise à jour de schéma exige l'accès en écriture au schéma dans Active Directory
Vérifiez que les noms complets LDAP des attributs CN=ms-Exch-Assistant-Name, CN=ms-Exch-LabeledURI et CN=ms-Exch-House-Identifier dans le contexte de nommage du schéma apparaissent maintenant respectivement sous la forme msExchAssistantName, msExchLabeledURI et msExchHouseIdentifier avant d'exécuter les commandes adprep /forestprep de Windows Server 2003.
Scénario 3 : La commande forestprep de Windows Server 2003 a été exécutée avant d'exécuter inetOrgPersonFix
Si vous exécutez la commande adprep /forestprep de Windows Server 2003 dans une forêt Windows 2000 qui contient les modifications de schéma Exchange 2000, les attributs LDAPDisplayName de houseIdentifier, secretaryet labeledURI seront décomposés. Pour identifier des noms décomposés, utilisez Ldp.exe afin de localiser les attributs affectés :
Installez Ldp.exe à partir du dossier Support\Tools du support de Microsoft Windows 2000 ou de Windows Server 2003.
Démarrez Ldp.exe à partir d'un contrôleur de domaine ou d'un ordinateur membre de la forêt.
Dans le menu Connexion, cliquez sur Connecter, laissez la zone Serveur vide, tapez 389 dans la zone Port, puis cliquez sur OK.
Dans le menu Connexion, cliquez sur Lier, laissez toutes les zones vides, puis cliquez sur OK.
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.
Dans le menu Parcourir, cliquez sur Rechercher.
Utilisez les paramètres suivants pour configurer la boîte de dialogue Rechercher :
Nom unique de base : le chemin de nom unique pour le contexte de nommage de schéma identifié à l'étape 3.
Filtre : (ldapdisplayname=dup*)
Étendue : sous-arbre
Les attributs houseIdentifier, secretary et labeledURI décomposés ont des attributs LDAPDisplayName d'un format semblable au suivant :
Si les noms complets LDAP pour labeledURI, secretary et houseIdentifier ont été décomposés à l'étape 6, exécutez le script InetOrgPersonFix.ldf de Windows Server 2003 pour les récupérer, puis passez à 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 vers ce dossier.
À une invite de commandes, tapez cd %systemdrive%\iop.
Extrayez le fichier InetOrgPersonFix.ldf du fichier Support.cab situé dans le dossier Support\Tools du support d'installation de Windows Server 2003.
À partir de la console du maître d'opérations du schéma, 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 <chemin d'accès du nom de domaine pour le domaine racine de la forêt> est le chemin d'accès du nom de domaine pour le domaine racine de la forêt :
Le chemin d'accès du nom de domaine pour le domaine racine de la forêt doit être entre guillemets.
Vérifiez que les attributs houseIdentifier,secretary et labeledURI dans le contexte de nommage du schéma ne sont pas décomposés avant d'installer Exchange 2000.
Pour plus d'informations sur un conflit relatif au schéma avec les Services pour UNIX version 2.0, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
293783
(http://support.microsoft.com/kb/293783/
)
Impossible d'effectuer une mise à niveau d'un serveur Windows 2000 vers Windows Server 2003 si les Services Windows pour UNIX 2.0 sont installés
Vue d'ensemble : Mise à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003
La commande adprep de Windows Server 2003 que vous exécutez à partir du dossier \I386 du support Windows Server 2003 prépare une forêt Windows 2000 et ses domaines à l'ajout de contrôleurs de domaine Windows Server 2003. La commande adprep /forestprep de Windows Server 2003 ajoute les fonctionnalités suivantes :
Descripteurs de sécurité par défaut améliorés pour les classes d'objet
Nouveaux attributs d'utilisateur et de groupe
Nouveaux objets et attributs de schéma tels que inetOrgPerson
L'utilitaire adprep prend en charge deux arguments de ligne de commande :
adprep /forestprep : exécute les opérations de mise à niveau de la forêt. adprep /domainprep : exécute les opérations de mise à niveau du domaine.
La commande adprep /forestprep est une opération unique effectuée sur le maître de l'opération du schéma (FSMO) de la forêt. L'opération forestprep doit s'achever et se répliquer vers le maître d'infrastructure de chaque domaine pour que vous puissiez exécuter adprep /domainprep dans ce domaine.
La commande adprep /domainprep est une opération unique que vous exécutez sur le contrôleur de domaine du maître des opérations d'infrastructure de chaque domaine dans la forêt qui hébergera des contrôleurs de domaine Windows Server 2003 nouveaux ou mis à niveau. La commande d'adprep /domainprep vérifie que les modifications de forestprep ont été répliquées dans la partition du domaine, puis opère ses propres modifications dans la partition du domaine et les stratégies de groupe dans le partage Sysvol.
Vous ne pouvez pas exécuter l'une ou l'autre des actions suivantes si les opérations /forestprep et /domainprep ne se sont pas terminées et répliquées sur tous les contrôleurs de domaine dans ce domaine :
Mettre à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003 en utilisant Winnt32.exe.
Remarque : Vous pouvez à tout moment mettre à niveau les serveurs et les ordinateurs membres Windows 2000 vers Windows Server 2003.
Promouvoir de nouveaux contrôleurs de domaine Windows Server 2003 dans le domaine en utilisant Dcpromo.exe.
Le domaine qui héberge le maître d'opérations du schéma est le seul domaine où vous devez exécuter adprep /forestprep et adprep /domainprep. Dans tous les autres domaines, il vous suffit d'exécuter adprep /domainprep.
Les commandes adprep /forestprep et adprep /domainprep n'ajoutent pas d'attributs à l'ensemble partiel d'attributs du catalogue global et n'entraînent pas de synchronisation complète du catalogue global. La version RTM de adprep /domainprep provoque 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 effectuées ne sont exécutées qu'une seule fois.
Une fois les modifications de adprep /forestprep et de adprep /domainprep 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 support de Windows Server 2003. Vous pouvez également ajouter de nouveaux contrôleurs de domaine Windows Server 2003 au domaine à l'aide de Dcpromo.exe.
Mise à niveau de la forêt à l'aide de la commande adprep /forestprep
Pour préparer une forêt et des domaines Windows 2000 de manière à accepter des contrôleurs de domaine Windows Server 2003, effectuez ces étapes dans un premier temps dans un environnement de laboratoire, puis dans un environnement de production :
Assurez-vous que vous avez effectué toutes les opérations de la phase « Inventaire des forêts » en faisant particulièrement attention aux éléments suivants :
Vous avez créé des sauvegardes de l'état du système.
Tous les contrôleurs de domaine Windows 2000 de la forêt disposent de tous les correctifs logiciels et Service Packs appropriés.
La réplication de bout en bout d'Active Directory s'exécute partout dans la forêt
FRS réplique correctement la stratégie du système de fichiers dans chaque domaine.
Ouvrez une session sur la console du maître d'opérations de schéma à l'aide d'un compte qui est membre du groupe de sécurité Administrateurs de schéma.
Vérifiez que le schéma FSMO a exécuté la réplication entrante de la partition du schéma en tapant le code suivant à une invite de commandes Windows NT :
repadmin /showreps
(repadmin est installé à partir du dossier Support\Tools d'Active Directory.)
La documentation précédente de Microsoft vous recommande d'isoler le maître d'opérations du schéma sur un réseau privé avant d'exécuter adprep /forestprep. Néanmoins, la pratique indique que cette étape n'est pas nécessaire et peut provoquer le rejet des modifications du schéma par un maître d'opérations du schéma lorsqu'il est redémarré sur un réseau privé. Si vous souhaitez isoler les ajouts du schéma opérés par adprep, Microsoft vous recommande de désactiver temporairement la réplication sortante d'Active Directory avec l'utilitaire de ligne de commande repadmin. Pour cela, procédez comme suit :
Cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK.
Tapez la commande suivante et appuyez sur ENTRÉE :
repadmin /options +DISABLE_OUTBOUND_REPL
Exécutez adprep sur le maître d'opérations du schéma. Pour ce faire, cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK. Sur le maître d'opérations du 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.
Remarque Vous pouvez ignorer les événements portant l'ID 1153 enregistrés dans le journal des événements Service d'annuaire, tel que l'exemple qui suit :
Type d'événement : Erreur Source de l'événement : NTDS Général Catégorie de l'événement : Traitement interne ID de l'événement : 1153 Date : JJ/MM/AAAA Heure : HH:MM:SS Utilisateur : Ordinateur Tout le monde : <des contrôleurs de domaine> Description : L'identificateur de classe 655562 (nom de classe msWMI-MergeablePolicyTemplate) a une superclasse 655560 non valide. Héritage ignoré.
Vérifiez que la commande adprep /forestprep s'est exécutée avec succès sur le maître d'opérations du schéma. Pour ce faire, vérifiez les éléments suivants à partir de la console du maître d'opérations du schéma :
La commande adprep /forestprep s'est terminée sans erreur.
L'objet CN=Windows2003Update est écrit sous CN=ForestUpdates, CN=Configuration, DC = domaine_racine_forêt. Enregistrez la valeur de l'attribut Revision.
(Facultatif) La version du schéma a été incrémentée à la version 30. Pour cela, observez l'attribut ObjectVersion sous CN=Schema, CN=Configuration, DC = domaine_racine_forêt.
Si adprep /forestprep ne s'exécute pas, vérifiez les éléments suivants :
Le chemin complet pour le fichier Adprep.exe situé dans le dossier \I386 du support d'installation a été spécifié lors de l'exécution de adprep. Pour cela, tapez la commande suivante :
x:\i386\adprep /forestprep
où x représente le lecteur contenant le support d'installation.
L'utilisateur connecté qui exécute adprep appartient au groupe de sécurité Administrateurs de schéma. Pour le vérifier, utilisez la commande whoami /all.
Si adprep ne fonctionne toujours pas, affichez le fichier Adprep.log dans le dossier %systemroot%\System32\Debug\Adprep\Logs\Dernier_journal.
Si vous avez désactivé la réplication sortante sur le maître d'opérations du schéma à l'étape 4, activez la réplication afin que les modifications du schéma effectuées par adprep /forestprep puissent être propagées. Pour cela, procédez comme suit :
Cliquez sur Démarrer, sur Exécuter, tapez cmd, puis cliquez sur OK.
Tapez la commande suivante et appuyez sur ENTRÉE :
repadmin /options -DISABLE_OUTBOUND_REPL
Vérifiez que les modifications de adprep /forestprep se sont répliquées sur tous les contrôleurs de domaine de la forêt. Ceci est utile pour surveiller les attributs suivants :
Incrémentation de la version du schéma
CN=Windows2003Update, CN=ForestUpdates, CN=Configuration, DC = domaine_racine_forêt ou CN=Operations, CN=DomainUpdates, CN=System, DC = domaine_racine_forêt et les GUID d'opérations au-dessous se sont répliqués.
Recherchez les nouvelles classes, objets, attributs ou autres modifications de schéma ajoutés par adprep /forestprep, par exemple inetOrgPerson. Affichez les fichiers SchXX.ldf (où XX est un nombre entre 14 et 30) dans le dossier %systemroot%\System32 pour déterminer quels objets et attributs devraient s'y trouver. Par exemple, inetOrgPerson est défini dans Sch18.ldf.
Recherchez les noms complets LDAP décomposés.
Si Exchange 2000 a été installé avant que vous ayez exécuté la commande adprep /forestprep de Windows Server 2003, consultez la section « Identification des attributs de nom décomposés » de l'article suivant de la Base de connaissances Microsoft.
314649
(http://support.microsoft.com/kb/314649/
)
La commande adprep /forestprep de Windows Server 2003 provoque une déformation d'attributs dans les forêts Windows 2000 qui contiennent des serveurs Exchange 2000
Si vous trouvez des noms décomposés, passez au Scénario 3 de la section « Exchange 2000 dans les forêts Windows 2000 » de cet article.
Connectez-vous à la console du maître d'opérations du schéma avec un compte appartenant au groupe de sécurité de Administrateurs du schéma de la forêt qui héberge le maître d'opérations du schéma.
Mise à niveau du domaine à l'aide de la commande adprep /domainprep
Exécutez adprep /domainprep après la réplication complète des modifications de /forestprep sur le contrôleur de domaine du maître des opérations d'infrastructure dans chaque domaine qui hébergera des contrôleurs de domaine Windows Server 2003. Pour cela, procédez comme suit :
Identifiez le contrôleur de domaine du maître d'infrastructure dans le domaine que vous mettez à niveau, puis connectez-vous avec un compte qui est membre du groupe de sécurité Administrateurs de domaine dans le domaine que vous mettez à niveau.
Remarque : L'administrateur de l'entreprise peut ne pas être un membre du groupe de sécurité Administrateurs du domaine dans les domaines enfants de la forêt.
Exécutez adprep /domainprep sur le maître d'infrastructure. Pour cela, cliquez sur Démarrer, sur Exécuter, tapez cmd, puis sur le maître d'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.
Remarque : la commande adprep /domainprep modifie les autorisations de fichiers dans le partage Sysvol. Ces modifications provoquent une synchronisation complète des fichiers dans cette arborescence.
Vérifiez que la commande domainprep s'est exécutée avec succès. Pour cela, vérifiez les éléments suivants :
La commande adprep /domainprep s'est exécutée sans erreur.
Le CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=chemin d'accès du nom du domaine à mettre à niveau existe
Si adprep /domainprep ne s'exécute pas, vérifiez les éléments suivants :
L'utilisateur connecté qui exécute adprep appartient au groupe de sécurité Administrateurs du domaine dans le domaine que vous mettez à niveau. Pour cela, utilisez la commande whoami /all.
Le chemin complet pour le fichier Adprep.exe situé dans le répertoire \I386 du support d'installation a été spécifié lors de l'exécution de adprep. Pour cela, tapez la commande suivante à l'invite de commandes :
x:\i386\adprep /forestprep
où x représente le lecteur contenant le support d'installation.
Si adprep ne fonctionne toujours pas, affichez le fichier Adprep.log dans le dossier %systemroot%\System32\Debug\Adprep\Logs\Dernier_journal.
Vérifiez que les modifications de adprep /domainprep se sont répliquées. Pour ce faire, vérifiez les éléments suivants pour les autres contrôleurs de domaine :
L'objet CN=Windows2003Update, CN=DomainUpdates, CN=System, DC = chemin d'accès du nom du domaine à mettre à niveau existe et la valeur de l'attribut Révision correspond à la valeur du même attribut sur le maître d'infrastructure du domaine.
(Facultatif) Recherchez les modifications d'objets, d'attributs ou de liste de contrôle d'accès (ACL) qu'a ajoutées adprep /domainprep.
Répétez les étapes 1-4 sur le maître d'infrastructure des domaines restants en masse ou lorsque vous ajoutez ou mettez à niveau les contrôleurs de domaine de ces domaines vers Windows Server 2003. Vous pouvez maintenant encourager de nouveaux ordinateurs Windows Server 2003 dans la forêt en utilisant DCPROMO. Vous pouvez également mettre à niveau les contrôleurs de domaine Windows 2000 existants vers Windows Server 2003 en utilisant Winnt32.exe.
Mise à niveau de contrôleurs de domaine Windows 2000 à l'aide de Winnnt32.exe
Après la réplication complète des modifications de /forestprep et /domainprep et après avoir pris une décision à propos de l'interopérabilité de la sécurité avec les clients d'une 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 compter parmi les premiers contrôleurs de domaine Windows Server 2003 dans la forêt dans chaque domaine :
Le maître d'attribution de noms de domaine dans la forêt afin que vous puissiez créer des partitions de programme DNS par défaut.
Le contrôleur de domaine principal du domaine racine de la forêt afin que les entités de sécurité à l'échelle de l'entreprise que forestprep de Windows Server 2003 ajoute deviennent visibles dans l'éditeur de l'ACL.
Le contrôleur de domaine principal dans chaque domaine autre que le domaine racine afin que vous puissiez créer de nouvelles entités de sécurité Windows 2003 spécifiques à la sécurité.
Pour cela, utilisez WINNT32 pour mettre à niveau les contrôleurs de domaine existants qui hébergent le rôle opérationnel souhaité. Ou bien, transférez ce rôle à un contrôleur de domaine Windows Server 2003 promu récemment. Exécutez 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 ou ordinateur membre Windows Server 2003 que vous promouvez :
Avant d'utiliser WINNT32 pour mettre à niveau des ordinateurs membres et des contrôleurs de domaine Windows 2000, supprimez les Outils d'administration Windows 2000. Pour cela, utilisez l'outil Ajout/Suppression de programmes du Panneau de configuration. (mises à niveau de Windows 2000 uniquement.)
Installez les fichiers du correctif logiciel ou d'autres correctifs considérés importants par Microsoft ou par votre administrateur.
Vérifiez sur chaque contrôleur de domaine la présence possible de problèmes de mise à niveau. Pour cela, exécutez la commande suivante à partir du dossier \I386 du support d'installation :
winnt32.exe /checkupgradeonly
Résolvez le cas échéant les problèmes identifiés par le contrôle de compatibilité.
Exécutez WINNT32.EXE à partir du dossier \I386 du support d'installation et redémarrez le contrôleur de domaine mis à niveau vers Windows Server 2003.
Réduisez les paramètres de sécurité pour les clients de version antérieure selon vos besoins.
Si des clients Windows NT 4.0 n'ont pas NT 4.0 SP6 ou si des clients Windows 95 ne possèdent pas le client de service d'annuaire, désactivez la signature de Service SMB dans 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 d'organisation 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 signées numériquement (toujours)
Vérifiez l'état de la mise à niveau à l'aide des points de données suivants :
La mise à niveau a réussi.
Les correctifs logiciels que vous avez ajoutés à l'installation ont correctement remplacé les binaires originaux.
La réplication entrante et sortante d'Active Directory se produit pour tous les contextes de nommage maintenus 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 : le message d'événement suivant peut s'afficher après la mise à niveau :
Type d'événement : Erreur Source de l'événement : Sauvegarde NTDS Catégorie de l'événement : Sauvegarde ID de l'événement : 1913 Date : Date Heure : HH:MM:SS Utilisateur : N/A Ordinateur : nom_ordinateur Description : Erreur interne : L'opération de sauvegarde et de restauration d'Active Directory a rencontré une erreur inattendue. La sauvegarde ou la restauration échouera tant que ce problème n'est pas corrigé.
Vous pouvez ignorer ce message en toute sécurité.
Installez les Outils d'administration Windows Server 2003 (mises à niveau de Windows 2000 et contrôleurs Windows Server 2003 autres que les contrôleurs de domaine uniquement). Adminpak.msi se trouve dans le dossier \I386 du CD-ROM Windows Server 2003. Le support de Windows Server 2003 contient des outils d'assistance mis à jour dans le fichier Support\Tools\Suptools.msi. Assurez-vous de bien réinstaller ce fichier.
Sauvegardez de nouveau 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. Placez ces sauvegardes des ordinateurs Windows 2000 mis à niveau vers Windows Server 2003 dans un dispositif de stockage verrouillé afin de ne pas les utiliser par erreur pour restaurer un contrôleur de domaine qui exécute maintenant Windows Server 2003.
(Facultatif) Exécutez 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 l'exécution de la banque d'instance seule (SIS) (mises à niveau de Windows 2000 uniquement).
SIS examine les autorisations existantes sur les objets stockés dans Active Directory, puis il applique un descripteur de sécurité plus efficace sur ces objets. SIS démarre automatiquement (ce qu'indique l'événement 1953 dans le journal des événements du service d'annuaire) quand des 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 la banque de descripteurs de sécurité améliorés uniquement lorsque vous entrez un ID de message d'événement 1966 dans le journal des événements du service d'annuaire :
Type d'événement : Informations Source de l'événement : NTDS SDPROP Catégorie de l'événement : Traitement interne ID de l'événement : 1966 Date : JJ/MM/AAAA Heure : HH:MM:SS Utilisateur : NT AUTHORITY\OUVERTURE DE SESSION ANONYME Ordinateur : <nom_ordinateur> Description : Le propagateur de descripteurs de sécurité a terminé la passe de propagation complète. Espace alloué (Mo) : XX Espace libre (Mo) : XX
Cette opération a pu augmenter l'espace libre dans la base de données Active Directory. Action utilisateur : Envisagez de défragmenter la base de données hors connexion pour exploiter l'espace libre éventuellement disponible dans la base de données Active Directory. Pour plus d'informations, consultez le centre Aide et support à l'adresse http://support.microsoft.com.
Ce message d'événement indique que l'opération de stockage à instance unique est terminée et suggère à l'administrateur d'effectuer une défragmentation hors connexion de Ntds.dit à l'aide de NTDSUTIL.EXE.
La défragmentation hors connexion peut réduire de jusqu'à 40 % la taille d'un fichier Windows 2000 Ntds.dit, elle améliore les performances d'Active Directory et met à jour les pages de la base de données pour améliorer l'efficacité du stockage des attributs Link Valued.
Pour plus d'informations sur la façon de défragmenter la base de données Active Directory, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
232122
(http://support.microsoft.com/kb/232122/
)
Exécution d'une défragmentation hors connexion de la base de données Active Directory
Enquêtez sur le Service Serveur DLT. Les contrôleurs de domaine Windows Server 2003 désactivent le service Serveur DLT sur les installations nouvelles et sur les mises à niveau. Si les clients Windows 2000 ou Windows XP de votre organisation utilisent le service Serveur DLT, utilisez Stratégie de groupe pour activer le service Serveur DLT sur les contrôleurs de domaine Windows Server 2003 nouveaux ou mis à niveau. Sinon, supprimez successivement les objets de suivi de liaisons distribués d'Active Directory.
Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft.
312403
(http://support.microsoft.com/kb/312403/
)
Suivi de lien distribué sur les contrôleurs de domaine Windows
315229
(http://support.microsoft.com/kb/315229/
)
Version textuelle de Dltpurge.vbs pour l'article Q312403 de la Base de connaissances Microsoft
Si vous supprimez en masse des milliers d'objets DLT ou d'autres objets, vous pouvez bloquer la réplication en raison d'un manque de banques de versions. Respectez le nombre de jours de durée de vie de désactivation (par défaut, 60 jours) après la suppression du dernier objet DLT et pour que le nettoyage de la mémoire s'achève, puis utilisez NTDSUTIL.EXE pour effectuer une défragmentation connexion ligne du fichier Ntds.dit.
Configurez la structure d'unité d'organisation recommandée. Microsoft recommande que les administrateurs déploient activement la structure d'unité d'organisation recommandée dans tous les domaines Active Directory et, après avoir mis à niveau ou déployé les contrôleurs de domaine Windows Server 2003 en mode Domaine Windows, redirigent les conteneurs par défaut que les API de version antérieure utilisent pour créer des utilisateurs, des ordinateurs et des groupes sur un conteneur d'unité d'organisation spécifié par l'administrateur.
Pour plus d'informations sur la structure de l'unité d'organisation recommandée, affichez la section « Creating an Organizational Unit Design » (Création d'une conception d'unité d'organisation) du livre blanc intitulé « Best Practice Active Directory Design for Managing Windows Networks ». Pour afficher ce livre blanc, reportez-vous au site Web de Microsoft à l'adresse suivante (en anglais) :
Pour plus d'informations sur la modification du conteneur par défaut où se trouvent les utilisateurs, ordinateurs et groupes créés par les API de version antérieure, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
324949
(http://support.microsoft.com/kb/324949/
)
Redirection des conteneurs Utilisateurs et Ordinateurs dans les domaines Windows Server 2003
Répétez les étapes 1 à 10 selon les besoins 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 recommandée) pour chaque domaine Active Directory.
En résumé :
Mettez à niveau les contrôleurs de domaine Windows 2000 avec WINNT32 (à partir du support d'installation intégrant un service pack le cas échéant)
Vérifiez les fichiers correctifs qui ont été installés sur les ordinateurs mis à niveau
Installez tout correctif requis non fourni sur le support d'installation
Vérifiez l'état de fonctionnement des serveurs nouveaux ou mis à niveau (AD, FRS, Stratégie etc.)
Attendez 24 heures après la mise à niveau du système d'exploitation, puis effectuez une défragmentation hors connexion (facultatif)
Démarrez le Service DLT si nécessaire, sinon supprimez les objets DLT au niveau de la forêt à l'aide des domainpreps q312403 / q315229
Effectuez une défragmentation hors connexion 60 + jours (nombre de jours de la durée de vie de désactivation et du nettoyage de la mémoire) après la suppression des objets DLT
Exécution à vide des mises à niveau dans un environnement de laboratoire
Avant de mettre à niveau les contrôleurs de domaine Windows vers un domaine de production Windows 2000, validez et mettez au point votre processus de mise à niveau en laboratoire. Si la mise à niveau d'un environnement de laboratoire qui simule avec précision la forêt de production s'effectue sans encombre, vous pouvez escompter des résultats similaires dans les environnements de production. Pour les environnements complexes, l'environnement de laboratoire doit reproduire l'environnement de production dans les domaines suivants :
Matériel : type d'ordinateur, taille mémoire, positionnement du fichier d'échange, taille du disque, performance et configuration RAID, niveaux de révision du BIOS et du microprogramme
Logiciels : versions du système d'exploitation client et serveur, applications clientes et serveur, versions de Service Pack, correctifs logiciels, modifications de schéma, groupes de sécurité, appartenances de groupe, autorisations, paramètres de stratégie, type de recensement et emplacement d'objet, interopérabilité des versions
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 de connexion et d'autres événements. Le but n'est pas de reproduire l'étendue de l'environnement de production, mais plutôt de déterminer le coût et la fréquence des opérations communes et d'interpoler leurs effets (requêtes de noms, trafic de réplication, bande passante réseau et utilisation processeur) sur l'environnement de production en fonction de vos besoins actuels et futurs.
Espace disque : Notez les tailles de début, maximum et finale des fichiers journaux du système d'exploitation, de NTDS.DIT et Active Directory sur les contrôleurs de domaine de catalogue global et non global dans chaque domaine après chacune des opérations suivantes :
adprep /forestprep
adprep /domainprep
Mise à niveau des contrôleurs de domaine Windows 2000 vers Windows Server 2003
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 combinée à une observation détaillée vous aidera à déterminer la méthode que vous appliquez à la mise à niveau des environnements de production. Les environnements comportant 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. Il vous faudra consacrer davantage d'attention lors des déploiements d'entreprise qui comportent des centaines de contrôleurs de domaine ou des centaines de milliers d'objets Active Directory. Dans de tels cas, il vous faudra planifier la mise à niveau dans l'espace de plusieurs semaines ou de plusieurs mois.
Utilisez des mises à niveau à vide dans le laboratoire pour effectuer les tâches suivantes :
Comprendre les rouages internes du processus de mise à niveau et des risques associés.
Exposer les domaines de problèmes potentiels pour le processus de déploiement dans votre environnement.
Tester et développer des plans de secours en cas d'échec de la mise à niveau.
Définir le niveau approprié de détail à appliquer au processus de mise à niveau pour le domaine de production.
Contrôleurs de domaine ne disposant pas d'un 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 sur le volume qui héberge le fichier NTDS.DIT et les fichiers journaux :
Supprimez les fichiers inutilisés, notamment les fichiers *.tmp ou les fichiers en cache qu'utilisent les navigateurs Internet. Pour cela, tapez les commandes suivantes en appuyant sur ENTRÉE après chaque commande :
cd /d lecteur\ del *.tmp /s
Supprimez tout fichier utilisateur ou de vidage mémoire. Pour cela, tapez les commandes suivantes en appuyant sur ENTRÉE après chaque commande :
cd /d lecteur\ del *.dmp /s
Supprimez ou déplacez temporairement les fichiers auxquels vous pouvez accéder à partir d'autres serveurs ou que vous pouvez facilement réinstaller. Les fichiers que vous pouvez supprimer et facilement remplacer sont notamment ADMINPAK, Support Tools, ainsi que tous les fichiers du dossier %systemroot%\System32\Dllcache.
Supprimez les profils utilisateurs 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 destinés aux comptes anciens ou inutilisés. Ne supprimez aucun profil qui peut être lié à des comptes de service.
Supprimez les symboles dans %systemroot%\Symbols. Pour cela, tapez la commande suivante :
rd /s %systemroot%\symbols
Selon que le serveur possède un jeu de symboles complet ou restreint, cela peut vous faire gagner de 70 à 600 Mo.
Effectuez une défragmentation hors connexion. Une défragmentation hors connexion du fichier NTDS.DIT peut libérer de l'espace mais requiert temporairement le double de celui occupé par le fichier DIT actuel. Effectuez la défragmentation hors connexion en utilisant d'autres volumes locaux si l'un d'eux est disponible. Ou utilisez l'espace d'un serveur de réseau mieux connecté pour effectuer la défragmentation hors connexion. Si l'espace disque n'est toujours pas suffisant, supprimez progressivement d'Active Directory des comptes utilisateur, comptes d'ordinateurs, enregistrements DNS et objets DLT inutiles.
Remarque : Active Directory ne supprime pas les objets de la base de données tant que le nombre de jours de la durée de vie de désactivation (par défaut, 60 jours) ne s'est pas écoulé et que le nettoyage de la mémoire n'est pas terminé. Si vous réduisez la durée de vie de désactivation à une valeur inférieure à la réplication de bout en bout dans la forêt, vous pouvez provoquer des incohérences dans Active Directory.
Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
821076
(http://support.microsoft.com/kb/821076/
)
Les fichiers d'aide de Windows Server 2003 contiennent des informations incorrectes sur la façon de mettre à jour un domaine Windows 2000
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Help and Support
Retour au début
