Windows Server 2003

Contents
Windows Server
Active Directory
Active Directory
Sauvegarde, restauration ou récupération d’urgence Active Directory
L’erreur c00002e2 ou « Choisir une option » s’affiche
Événement Services d’annuaire 2095 lors de la restauration USN
Événement 2089 si vous ne sauvegardez pas un contrôleur de domaine
ID d’événement 1587 après la restauration du contrôleur de domaine
Comment supprimer des domaines orphelins
Comment restaurer des comptes d’utilisateurs supprimés et leurs groupes
Aucun serveur d’ouverture de session n’est disponible
Défragmentation hors connexion de la base de données Active Directory
Déplacer une arborescence SYSVOL
RODC réplique les mots de passe
Syskey.exe'utilitaire n’est plus pris en charge
Le dossier SYSVOL n’est pas répliqué entre les contrôleurs de domaine
Services de certificat Active Directory
Une autorité de certification ne peut pas utiliser de modèle de certificat
Sauvegarder la clé privée EFS de l’agent de récupération
Impossible de sélectionner des modèles de certificat compatibles avec l’autorité de
certification
Impossible de partager des fichiers avec plusieurs certificats EFS
Les services de certificats ne démarrent pas
Les services de certificats peuvent ne pas démarrer sur un ordinateur
Modifier la date d’expiration des certificats émis par l’autorité de certification
Échecs de sauvegarde MasterKey DPAPI
Exporter le certificat d’autorité de certification racine
Rechercher le nom du serveur d’autorité de certification racine d’entreprise
Comment réinstaller le rôle d’autorité de certification
Comment supprimer manuellement l’autorité de certification Windows d’entreprise
Déplacer une autorité de certification vers un autre serveur
Déplacer la base de données et les fichiers journaux du serveur de certificats
Certificats racines approuvés requis
Définir une période de validité différente pour l’autorité de certification
subordonnée
Configurer l’authentification basée sur un certificat dans des forêts sans approbation
pour un serveur web
Les certificats d’autorité de certification racine valides ne sont pas approuvés
Les modèles de version 3 n’apparaissent pas dans l’inscription web de certificat
Problèmes de base de données Active Directory et échecs de démarrage du
contrôleur de domaine
Erreur « Accès refusé » lors de la réplication du service d’annuaire AD
Erreur « Les services d’annuaire ne peuvent pas démarrer » lors du démarrage d’un
Échec de la communication AD sur les contrôleurs de domaine multirésidents
Le service ADWS se bloque après la mise à niveau
Processus de garbage collection de bases de données
Erreur lors de la configuration d’un serveur avec 伺服器管理員
ID d’événement ESENT 1000, 1202, 412 et 454
Les ID d’événement 5788 et 5789 se produisent
Comment exécuter le vérificateur sémantique sur la base de données AD
Comment utiliser Ntdsutil pour gérer des fichiers Active Directory
ISMServ.exe ne démarre pas au démarrage du contrôleur de domaine
Mises à jour de niveau fonctionnel de domaine ou de forêt Active Directory
Erreur « Adprep n’a pas pu contacter un réplica » lors de l’exécution de la
commande « Adprep /rodcprep »
Configurer la délégation Kerberos contrainte
Le processus de promotion du contrôleur de domaine affiche « Windows Server
Technical Preview »
Guide pratique pour configurer le pare-feu pour les domaines et les approbations
Élever les niveaux fonctionnels de domaine et de forêt Active Directory
Services AD FS (Active Directory Federation Services)
Résoudre les problèmes d’authentification unique ADFS
Erreur ADFS 180 et points de terminaison manquants
Erreur de certificat ADFS 2.0
Erreur ADFS 2.0 401
Erreur ADFS 2.0 : impossible d’afficher cette page
Échec du démarrage du service ADFS 2.0
Disponibilité et description de Active Directory 联合身份验证服务 2.0
Modifier le certificat de communication de service AD FS 2.0
Description de la fonctionnalité De verrouillage intelligent Extranet
Désactiver et remplacer TLS 1.0 dans ADFS
Erreur 0x80072EE7 lorsque vous effectuez une jointure d’espace de travail
Échec de la connexion du service ADFS
Échec de la conversion du domaine en standard
Restaurer IIS et nettoyer Active Directory
Résoudre l’erreur AD FS 2.0
Résoudre les problèmes AD FS dans Azure Active Directory
Active Directory FSMO
Impossible de se connecter au domaine
Échec de la saisie du rôle maître RID avec Ntdsutil
Rechercher les serveurs qui détiennent des rôles FSMO
Rôles FSMO
Comment transférer ou saisir des rôles FSMO
Comment afficher et transférer des rôles FSMO
Fonction de modification du mot de passe et de résolution des conflits
Processus de transfert et de saisie des rôles FSMO
Active Directory Lightweight Directory Services (AD LDS) et adam (Active Directory
Application Mode)
L’ID d’événement général ADAM 1161 est journalisé sur un serveur AD LDS
Modifier le mot de passe de l’utilisateur Windows Active Directory via LDAP
Masquer ou afficher la classe d’objets InetOrgPerson
Comment configurer la journalisation des événements de diagnostic AD et LDS
Les opérations LDAP vers Active Directory sont désactivées
Échec du démarrage du service LDS avec l’ID d’événement 1168
Nombreux événements « ID d’événement 1216 »
Des problèmes se produisent avec les contrôleurs de domaine dans les zones DNS
intégrées à Active Directory
Résoudre OBJ_CLASS_VIOLATION erreur dans Adamsync
Outil de migration Active Directory (ADMT)
L’instance AD LDS journalise l’ID d’événement 2092
Échec de l’installation d’ADMT 3.1 PES avec une erreur
Échec de l’exécution de la console ADMT après l’installation
Problèmes lors de la migration vers un domaine avec ADMT 3.1
Informations de support pour ADMT et PES
Résoudre les problèmes de migration de mot de passe intra-forêt
Résoudre les problèmes de migration sIDHistory avec ADMTv2
L’application Windows ne peut pas démarrer
Réplication Active Directory
Conseils de dépannage : réplication Active Directory
Les modifications Active Directory ne sont pas répliquées
Erreur de réplication Active Directory 1256
ID d’événement de réplication Active Directory 1388 ou 1988
ID d’événement de réplication Active Directory 1925
ID d’événement de réplication Active Directory 2108 et 1084
Échec des opérations AD avec l’erreur Win32 1127
Échec des opérations AD avec l’erreur Win32 8240
Échec de la réplication AD avec l’erreur 8409
La réplication AD ne fonctionne pas et l’événement 1865
Échec des réplications AD avec l’erreur 1818
Impossible de modifier l’étendue de réplication d’une zone intégrée à AD
Impossible de supprimer des objets AD avec de nombreux liens
Les modifications ne sont pas répliquées sur les contrôleurs de domaine de
destination
Échec du test DCDiag VerifyReferences
Diagnostiquer les échecs de réplication
Désactiver la création automatique de la topologie de réplication par KCC
Des connexions de réplication AD en double sont créées
Obtenir et utiliser l’outil d’état de réplication AD
Correctifs logiciels pour les technologies DFS
Comment limiter le trafic RPC à un port spécifique
Objets persistants dans une forêt Windows Server Active Directory
Les objets persistants restent
Échec de la réplication manuelle des données entre les contrôleurs de domaine
Modifier l’intervalle de réplication dc intrasite par défaut
ID d’événement d’avertissement de réplication NTDS 1093
ID d’avertissement de réplication NTDS 1083 et 1061
La dépréciation NTFRS bloque l’installation des contrôleurs de domaine de
réplication
Échec des opérations avec l’erreur Win32 1753
Échec des opérations avec l’erreur Win32 8524
Le contrôleur de domaine enfant orphelin n’est pas répliqué
Erreur de réplication 1722
Erreur de réplication 5 - Accès refusé
Résoudre l’erreur de réplication Active Directory 1396
Résoudre l’erreur de réplication AD 8446
Résoudre les erreurs courantes de réplication Active Directory
Résoudre l’erreur de réplication du contrôleur de domaine 1727
Résoudre les problèmes liés à l’ID d’événement 1311
Résoudre les erreurs de base de données Jet et les étapes de récupération
Résoudre l’erreur de réplication 8418
Résoudre l’erreur de réplication 8456 ou 8457
Utiliser Ntdsutil pour rechercher et nettoyer les identificateurs de sécurité en double
Services AD RMS (Active Directory Rights Management Services)
L’ID d’événement 84 se produit dans AD RMS dans Windows Server
Topologie Active Directory (sites, sous-réseaux et objets de connexion)
Impossible de promouvoir un contrôleur de domaine auprès d’un serveur de
catalogue global
Impossible de créer un espace de noms DFS
Problèmes lors du changement de nom des sites dans la forêt AD
KFSO ne fonctionne pas dans l’approbation externe
Optimiser l’emplacement du contrôleur de domaine
Problèmes liés à la promotion du contrôleur de domaine au serveur de catalogue
global
DCPromo et l’installation de contrôleurs de domaine
Erreur « Incompatibilité de schéma » lors de la tentative d’exécution de l’Assistant
Installation d’Active Directory
Une erreur d’accès est refusée se produit avec DCPROMO
L’accès est refusé lorsque vous promouvez le contrôleur de domaine
Échec des opérations de configuration AD DS
Impossible d’ajouter un contrôleur de domaine en tant que nœud
Impossible de sélectionner le rôle serveur DNS lors de l’ajout d’un contrôleur de
domaine dans un domaine AD existant
Créer un serveur Active Directory
La promotion dc cesse de répondre
Échec de la rétrogradation DCPROMO
Déploiement et fonctionnement de domaines Active Directory
Le changement de nom du contrôleur de domaine ne renomme pas tous les objets
AD DFSR SYSVOL
Les contrôleurs de domaine ne rétrogradent pas
Erreurs lors de l’exécution de commandes DCDIAG
Échec de rétrograder le contrôleur de domaine avec Dcpromo.exe
Placement et optimisation FSMO
Règles d’application de stratégie de groupe pour les contrôleurs de domaine
‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬préparation n’est pas effectuée
Comment mettre à niveau des contrôleurs de domaine
Comment utiliser le mode sans assistance pour installer et supprimer AD DS
Échec de l’installation d’AD DS
Erreur interne pendant la phase de réplication de dcpromo
Échec du déplacement de Windows Server vers un domaine
Le partage NETLOGON n’est pas présent après l’installation d’AD DS sur un
nouveau contrôleur de domaine complet ou en lecture seule
Le contrôleur de domaine nouvellement promu ne parvient pas à publier après
DCpromo
Scalabilité ou performances du contrôleur de domaine (y compris LDAP)
DC retourne uniquement 5 000 valeurs dans la réponse LDAP
Le contrôleur de domaine ne fonctionne pas correctement
ID d’événement 1644 lors de l’exécution de requêtes LDAP
Comment résoudre les problèmes d’utilisation élevée de l’UC Lsass.exe
Problèmes liés au dépassement des valeurs de backlog des demandes de réplication
AD et des rpc Netlogon
Les serveurs LDAP et Kerberos réinitialisent les sessions TCP
Problèmes de performances après la mise à niveau des contrôleurs de domaine
Utiliser Event1644Reader.ps1 pour analyser les performances des requêtes LDAP
Problèmes de jonction de domaine
Erreur « Le compte n’est pas autorisé à se connecter à partir de cette station »
Échec de l’installation d’Active Directory
Impossible d’accéder à Internet ou au domaine
Limite par défaut aux numéros de station de travail
Mécanisme permettant de localiser un contrôleur de domaine
Le service Netlogon ne conserve pas les paramètres après la mise à niveau sur place
Limites de prise en charge d’Active Directory sur NAT
Le Centre de synchronisation synchronise les fichiers hors connexion très lentement
Résolution des problèmes d’erreur de réplication AD 1908
Résoudre les erreurs lors de la jonction d’ordinateurs à un domaine
Impossible de joindre des ordinateurs à un domaine
Échec de l’utilisation de l’interface utilisateur de jonction de domaine pour joindre un
ordinateur à un domaine AD
Configuration et interopérabilité LDAP
Les contrôleurs de domaine ne peuvent pas être localisés et les sessions sortantes à
taux élevé
Activer LDAP sur SSL
Comment désactiver TLS 1.3 pour AD et LDAP
Comment activer la signature LDAP dans Windows Server
Comment activer la journalisation de débogage du client LDAP
Les requêtes pagagées LDAP avec références subordonnées ne sont pas suivies
correctement
Les requêtes LDAP retournent une liste d’attributs partielle
Les requêtes LDAP ciblant les noms d’hôtes prennent plus de temps
Paramètres et exigences de sécurité de session LDAP après ADV190023
Problèmes de connexion LDAPS
Faire en sorte que les contrôleurs de domaine répondent à LDAP Ping sur le port
UDP 138
Utiliser la fonctionnalité Dbdump en ligne dans Ldp.exe
Afficher et définir une stratégie LDAP à l’aide de Ntdsutil
Mise à jour du schéma : problèmes connus, meilleures pratiques, révision de flux de
travail
Comment trouver la version actuelle du schéma
Échec ou conflit de mise à jour du schéma
Retards lors de la communication des membres de domaine aux contrôleurs de
domaine
Erreur lors de l’exécution de l’Assistant Installation d’AD
Protocole TLS (Transport Layer Security)
Désactiver TLS 1.0 et 1.1 et forcer l’utilisation de TLS 1.2
Erreurs lorsque les applications tentent de se connecter à SQL Server
Gestion des utilisateurs, ordinateurs, groupes et objets
Erreur « Cette propriété est limitée à 64 valeurs »
Accès refusé après connexion à un compte d’administrateur local
ACCÈS REFUSÉ avec les API NetUser et NetGroup
L’accès est refusé lorsque des utilisateurs non administrateurs rejoignent des
ordinateurs
L’allocateur d’identificateur de compte ne parvient pas à s’initialiser
Ajouter des groupes spéciaux à des groupes intégrés
Tous les membres d’un groupe ne peuvent pas être retournés
Les résultats auditPol et stratégie de sécurité locale sont différents
Impossible d’accéder aux données AD à partir de l’Explorateur de contrôles de code
source
Impossible d’ajouter un utilisateur ou un objet au service d’annuaire
Impossible de démarrer Active Directory-brukere og -datamaskiner Tool
Compatibilité avec les comptes d’utilisateur se terminant par le signe dollar
Définir des modèles de sécurité par modèle de sécurité Snap-In
Erreur « Le type de données de répertoire ne peut pas être converti vers/ à partir
d’un type de données DS natif »
L’ID d’événement 5722 est journalisé sur le contrôleur de domaine
Échec de la suppression des paramètres NTDS orphelins
Échec de l’exécution de Get-ADGroupMember pour le groupe local de domaine
Le mode de planification RSoP n’est pas pris en charge dans un scénario inter-forêts
Comment modifier les noms d’affichage des utilisateurs Active Directory
Comment activer la journalisation des événements Kerberos
Comment réinitialiser le mot de passe de l’administrateur DSRM
Comment utiliser des fantômes
Informations sur les appareils configurés en tant que CONTRÔLEURS DE DOMAINE
Permettre aux non-administrateurs d’afficher le conteneur d’objets supprimés
Les comptes Linux ne peuvent pas obtenir de cycles chiffrés AES dans AD DS
Modifier les propriétés filtrées d’un objet
Plusieurs onglets de propriétés utilisateur sont manquants
Nommer des ordinateurs, des domaines, des sites et des unités d’organisation
NET.EXE commande /ADD ne prend pas en charge les noms de plus de 20
caractères
Le service Netlogon ne démarre pas
Échec de la modification du mot de passe pour le mot de passe expiré
Échec de la réinitialisation du mot de passe avec erreur
Protocoles de modification de mot de passe dans Windows
Performances médiocres lors de l’appel de fonctions de recherche
Rediriger les utilisateurs et les conteneurs d’ordinateurs
Renommer un élément après une collision de réplication
Restreindre l’utilisation d’un ordinateur à un seul utilisateur de domaine
Définir le mot de passe d’un utilisateur avec Ldifde
Certaines applications et API nécessitent l’accès aux informations d’autorisation
L’outil Lingering Object Liquidator (LoL)
Utiliser Adminpak pour administrer à distance des ordinateurs
Utiliser le service d’annuaire pour gérer les objets AD
Indicateurs de propriété UserAccountControl
Contrôleur de domaine virtualisé (erreurs et questions)
Héberger des contrôleurs de domaine AD dans des environnements d’hébergement
virtuel
ID d’événements du service de temps Windows 24, 29 et 38
Service de temps Windows
Configurer W32Time sur un décalage de temps important
Convertir des attributs de date/heure au format d’heure standard
Message d’erreur lorsque vous exécutez la commande « w32tm /resync »
Événement 142 : Le service de temps a arrêté la publicité
Comment configurer un serveur de temps faisant autorité
Comment le service de temps Windows traite-t-il une seconde bissextile
Prise en charge de la seconde bissextile
Le service de temps ne corrige pas l’heure
La synchronisation de l’heure peut échouer
Activer la journalisation de débogage dans le service de temps Windows
Les paramètres W32time échouent lors du démarrage du service de temps
Windows dans un groupe de travail
Les paramètres du service de temps Windows ne sont pas conservés dans une mise
à niveau
développement Administration
développement Administration
Interface des services Active Directory (ADSI)
Convertir le GUID mis en forme de chaîne en forme de chaîne hexadécimale
WMI (Windows Management Instrumentation)
Bonne pratique pour configurer les performances de transfert EventLog
Correctifs logiciels suggérés pour les problèmes WMI
Windows Installer a reconfiguré toutes les applications
Administration à distance de Windows (WinRM)
Le collecteur d’événements ne transfère pas d’événements
Gestion des applications
Gestion des applications
Installation de .NET Framework
Les services en fonction de ASP.NET service d’état ne démarrent pas
Applications tierces
La connexion n’est pas disponible dans le composant logiciel enfichable MMC
Application Compatibility Toolkit (ACT)
DXDIAG signale une faible mémoire des adaptateurs d’affichage
Erreur « L’analyse de Best Practices Analyzer a échoué »
Performances et stabilité COM et COM+
L’application COM+ cesse de fonctionner lorsque les utilisateurs se déconnectent
Programmation COM et DCOM
Les performances se dégradent lors de l’accès à des fichiers volumineux
Administration, configuration et sécurité COM+
0x80004027 erreur lorsque vous accédez à distance à l’objet COM+
Code d’erreur 80080005 lors du démarrage de nombreuses applications COM+
Démarrage, configuration, connectivité et cluster DTC
Comment configurer DTC pour qu’il fonctionne via des pare-feu
Comment activer l’accès DTC réseau
Régénérer ou déplacer l’installation MSDTC à utiliser avec le cluster de basculement
SQL
Résoudre les problèmes de connectivité dans MS DTC avec l’outil DTCPing
Système d’événements
Description du suivi des événements d’arrêt
Comment supprimer des fichiers journaux ‫ ﻋﺎرض ا ﺣﺪاث‬endommagés
Déplacer ‫ ﻋﺎرض ا ﺣﺪاث‬fichiers journaux vers un autre emplacement
MSI
Résoudre les problèmes d’altération de l’inscription des mises à jour logicielles MSI
Échec de l’installation de MSI avec l’erreur 1603
Interface utilisateur multilingue (MUI) et Éditeur de méthode d’entrée (IME)
Application des paramètres « Options régionales et linguistiques »
Échec de l’initialisation de l’écouteur HTTP en l’absence de SeChangeNotifyPrivilege
Hôte de script Windows (CScript ou WScript)
Exécuter un script d’ouverture de session une fois lorsqu’un nouvel utilisateur se
connecte
Sauvegarde et stockage
Sauvegarde et stockage
Sauvegarde et restauration Active Directory, ou récupération d’urgence
Durée de conservation d’une sauvegarde d’état système d’AD
Configuration et utilisation du logiciel de sauvegarde
0x80042306 erreur lors de la configuration des versions précédentes pour un point
de montage
Accès refusé lors de l’exécution d’un travail par lots
Échec du programme de sauvegarde pour un volume système volumineux
Impossible d’ajouter un disque supplémentaire à une sauvegarde planifiée
Erreur de connexion des clients DirectAccess 0x274d
Erreur Diskshadow lorsque vous essayez de créer un instantané VSS
Activer les fonctionnalités de suivi de débogage de VSS
Erreur 3266/3013 lorsque vous effectuez une sauvegarde/restauration de base de
données
Message d’erreur lorsque vous effectuez une sauvegarde de l’état du système
ID d’événement 8193 lorsque vous effectuez une sauvegarde
Comment utiliser la fonctionnalité de sauvegarde pour sauvegarder et restaurer des
données
Aucun enregistreur VSS lors de l’exécution de la commande « enregistreurs de liste
vssadmin »
Codes de retour utilisés par l’utilitaire Robocopy
Échec du processus de sauvegarde du serveur et erreur 0x80070005
ID d’événement srv du journal des événements système 2012
Échec de la sauvegarde de l’état du système
Échec de l’ouverture de la console MMC de sauvegarde Windows Server
Altération des données et erreurs de disque
Conseils de dépannage : Altération des données et erreurs de disque
La sauvegarde ne démarre pas après avoir effectué une récupération complète
Impossible de supprimer des fichiers sur le système de fichiers NTFS
Modifier le comportement de la commande de format
Corriger les problèmes d’espace disque sur les volumes NTFS
ID d’événement de disque 154
Des erreurs se produisent lorsque vous apportez une ressource de disque physique
L’extension d’un CSV n’est pas bloquée
Définir le registre d’attributs Partmgr avec PowerShell
Le système journalise plusieurs événements qui spécifient l’ID d’événement 640
Déduplication
Cloner ou dupliquer une installation Windows
Erreurs pour les requêtes Andx de lecture SMB pour les fichiers gérés par la
déduplication des données
Les fichiers sont endommagés sur un volume dédupliqué
Le garbage collection complet entraîne des problèmes de performances
Problèmes connus après l’activation de la déduplication des données sur CSV
Resource Manager du serveur de fichiers (FSRM)
Erreur 10013 lors de la liaison à nouveau du port exclu
Le serveur de fichiers Resource Manager n’a pas pu charger les objets WMI
L’utilisation du quota FSRM est incorrecte
Correctifs logiciels pour les services de fichiers dans Windows Server 2008
Stockage insuffisant pour traiter cette commande
Iscsi
Les partages de fichiers sur les appareils iSCSI ne sont pas recréé
Les limites de taille de disque virtuel iSCSI sont incorrectes
Limites de Microsoft iSCSI Software Target 3.3
Les sous-réseaux redondants sont créés de manière incorrecte
L’initiateur iSCSI ne peut pas se connecter à la cible favorite
E/S multipathes (MPIO) et Storport
Impossible d’installer Windows dans le numéro d’unité logique de démarrage avec
plusieurs chemins d’accès
L’activation de MPIO avec des disques SAS réduit les performances
Option MPIO non disponible dans Gestion des disques
Gestion des partitions et des volumes
Erreur « Vous n’avez pas d’autorisation »
Un volume apparaît comme brut dans la gestion des disques
Meilleures pratiques pour l’utilisation de disques dynamiques
Impossible d’accéder à un volume CSV à partir d’un nœud passif
Impossible de sélectionner ou de mettre en forme une partition de disque dur
Impossible de démarrer un ordinateur à partir d’un lecteur flash USB du système de
fichiers FAT32
Impossible d’utiliser la commande d’arrêt DiskPart pour interrompre un jeu mis en
miroir
Configurer une alerte d’espace disque faible
Limitations du défragmenteur de disque
Suivi des liens distribués sur les contrôleurs de domaine
Établir et démarrer des miroirs GPT dans Windows 64 bits
Étendre un volume de données
Questions fréquentes (FAQ) sur l’architecture du disque de table de partitionnement
GUID
Correction de l’utilisation intensive de la mémoire dans ReFS
Les disques d’échange à chaud ne sont pas reconnus
Comment NTFS réserve de l’espace pour MFT
Comment établir un volume entrelacé
Mise en miroir de la partition système et de démarrage (RAID1)
Comment exécuter l’outil Nettoyage de disque (Cleanmgr.exe)
Comment configurer la mise en miroir dynamique des partitions de démarrage sur
les disques GPT
Intel SSD D3-S4510 et Intel SSD D3-S4610 série 1,92 To et 3,84 To lecteurs ne
répond pas
Nouveau mécanisme de journalisation pour les disques durs virtuels
Le volume ReFS à l’aide de DPM ne répond plus
Lettre de restauration du lecteur système/de démarrage
Les volumes simples peuvent devenir inaccessibles
Limite d’utilisation pour le service VSS (Volume Shadow Copy Service)
Utiliser le composant logiciel enfichable Gestion des disques
Prise en charge des disques durs de plus de 2 To dans Windows
Matériel de stockage
Comment activer ou désactiver la mise en cache d’écriture sur le disque
Informations sur l’ID d’événement 51
Le disque de transmission dans une machine virtuelle hautement disponible est en
lecture seule
Les volumes partagés de cluster répliqués sont hors connexion
Stratégie de support pour les disques durs du secteur 4K
Erreur d’appareil USB non reconnue
Espaces de stockage
Étendre des espaces de stockage hiérarchisé autonomes
Restauration du système ou réinitialisation de votre ordinateur
Comment restaurer une installation de Windows 7
Service VSS
Échec de la sauvegarde en raison de l’enregistreur VSS
Échec de la sauvegarde avec les événements VSS 12292 et 11
Erreur 0x8000FFFF lors de l’exécution de la commande « vssadmin list writers »
Erreur 0x80042409 lors d’une restauration VSS
ID d’événement 513 lors de l’exécution de VSS dans Windows Server
Aucun enregistreur VSS n’est répertorié lors de l’exécution d’enregistreurs de liste
vssadmin
Les clichés instantanés sont supprimés lors de l’exécution d’un travail de classification
FCI
Échec de la sauvegarde de l’état du système à l’aide de la sauvegarde Windows
Server
Avertissements de sauvegarde tiers après l’installation d’une mise à jour de
maintenance
La mise en ligne du service De cliché instantané de volume prend plus de temps
Événement VSS 8193 lors du redémarrage du service Services de chiffrement
ID d’événement VSS 8019, 20, 8193 ou 12302
Avertissements VSS dans le journal des événements d’application
Échec du rapport des enregistreurs VSS sur une machine virtuelle
Containers
Gestion des conteneurs
Stratégie de support pour les conteneurs Windows et Docker dans les scénarios
locaux
Déploiement
Déploiement
Activation
Erreur « Windows n’est pas authentique »
0xc004f063 lors de l’activation d’une version OEM
ID d’avertissement du journal des événements de l’application 1058
Erreur 0x8007000D lorsque vous activez une machine
Erreur 0xC004E002 pendant l’activation
Erreur 0xC004F015 lorsque vous activez Windows 10
Erreur 0xC004F074 lors de l’activation de Windows
Erreur lors de la validation d’une copie de Windows
Événement 12293 lors de l’inscription d’un enregistrement d’hôte KMS
Échec de l’activation basée sur un jeton d’avertissement de l’ID d’événement 12321
L’ID d’événement 8208, 8200 ou 900 est journalisé
Échec de l’activation de Windows Server sur Internet
Comment modifier la clé de produit licence en volume
Comment reconstruire le fichier Tokens.dat
La base de données spécifiée n’est pas une erreur de base de données VAMT valide
Échec de l’activation de Windows avec erreur 0x8007267C
Échec de l’installation de Windows avec erreur
Appareils et pilotes
Erreur « Arrêter 0x0000007B »
Erreur « Cet appareil ne peut pas démarrer » lors du déploiement d’un disque SSD
NVMe à chaud
Impossible de trouver l’adaptateur de bouclage Microsoft
Impossible d’installer un pilote VMWare sur Windows Server 2008 R2
Modifications du comportement par défaut pour le stationnement principal
Activer technologie Plug and Play fonctionnalité pour les appareils de port parallèles
ID d’événement 37 après avoir modifié la stratégie d’alimentation
L’ID d’événement 56 est journalisé
Échec de l’insertion d’une carte à puce dans un lecteur
Comment déterminer le type de processeur
Comment remplacer un pilote à l’aide de la console de récupération
Comment utiliser Enhedshåndtering pour configurer des appareils
Stratégie de prise en charge des logiciels tiers au niveau du noyau
Échec de l’installation du pilote VMware dans Windows Server 2008 R2 SP1
Prise en charge des services de déploiement Windows (WDS) pour UEFI
GPM
Échec du déploiement de multidiffusion à partir de WDS
Maintenance
Conseils de dépannage : Installation de fonctionnalités ou de rôles Windows
Conseils de résolution des problèmes : Mise à jour de Windows Server
Impossible de se connecter au site web d’administration WSUS
Impossible d’installer .NET Framework 3.5 sur l’installation OEM de Windows
Impossible d’installer des mises à jour ou des programmes
Le fichier CBS.log contient des entrées que certains fichiers ne sont pas réparés
Description du vérificateur de fichiers système (Sfc.exe)
Description de Windows Server Update Services 3.0
Erreur 0x800f0906 lorsque vous convertissez Server Core en interface graphique
utilisateur
Erreur 0x800f0922 en cas d’échec de l’installation de la fonctionnalité MPIO
Erreur 0x800f0922 lorsque vous désinstallez des rôles/fonctionnalités
Erreur C0190003 après l’installation des mises à jour
Échec de l’installation du rôle Serveur de stratégies réseau
Échec de la planification du redémarrage du service Software Protection
Corriger les erreurs de Windows Update
Comment bloquer l’accès utilisateur à Windows Update
Utilisation de la console de récupération
Installer l’outil de création de rapports du support technique Microsoft
Liste des mises à jour
Réinscrire le client/serveur Windows dans WSUS
La partition système est mise hors connexion après l’installation d’un disque tiers
SystemInfo.exe n’affiche pas toutes les mises à jour installées
Désactiver temporairement le pilote de filtre en mode noyau
Pourquoi vous pouvez être invité à redémarrer votre ordinateur
Windows Server 2008 Service Pack 2
Le package d’installation WSUS 3.0 est disponible
Installation dynamique WSUS 3.0 SP2 pour 伺服器管理員
WSUS SelfUpdate n’envoie pas de mises à jour automatiques
WUSA retourne 0x5 ERROR_ACCESS_DENIED
Vous ne pouvez pas installer de fonctionnalités dans Windows Server 2012 R2
Configuration
Ajouter des pilotes PNP OEM aux installations Windows
Éviter les GUID en double lorsque vous imagez des clients SMS
Impossible d’ouvrir des fichiers EXE
Les dictionnaires IME chinois ne sont pas encore prêts
La méthode d’entrée chinoise (simplifiée) ne fonctionne pas
Créer une image ISO pour les plateformes UEFI
Activer la journalisation et le suivi pour les composants WDS
ID d’événement 307 et 304 enregistrés pour le déploiement de Windows
Échec de l’exécution d’applications sur Windows Server Core
Comment effectuer une mise à niveau sur place/réparation
La mise à niveau sur place se bloque à l’écran noir
Intégrer Windows Server Update Services (WSUS) 3.0 dans 伺服器管理員
Problèmes connus qui affectent la tâche de maintenance du nettoyage AppX
Les longs chemins d’accès comportant des espaces nécessitent des guillemets.
Modifier manuellement Boot.ini fichier
MDT Media Deployment USB n’est pas démarrable
Microsoft Deployment Toolkit prend en charge le cycle de vie
Échec de la tâche de configuration post-déploiement
Échec du programme d’installation sur une machine virtuelle avec erreur
0xE0000100
Échec de la séquence de tâches SYSPREP et CAPTURE
Le serveur WDS peut ne pas démarrer
Le programme d’installation sans assistance n’utilise pas le nom d’ordinateur spécifié
par l’utilisateur pendant OOBE
La mise à niveau échoue avec l’erreur 0x000000C4
Utilisation d’ID de langue pour identifier les modules linguistiques
Échec du démarrage du service de déploiement Windows
Échec de l’installation de Base de données interne Windows (WID)
Erreur de configuration PCR7 « Liaison impossible »
Instructions de support et d’installation de Windows Server pour la famille de
processeurs AMD Rome
Les clients WSUS ne peuvent pas installer les mises à jour
Stratégie de groupe
AppLocker ou stratégies de restriction logicielle
Appliquer des objets ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬aux serveurs Terminal Services
Déploiement de logiciels via ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Modifier un emplacement ou définir plusieurs chemins UNC pour le package MSI
Résoudre les problèmes d’installation de logiciels par journalisation de débogage
Utiliser ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬pour configurer l’ouverture de session automatique dans
Terminal Services
Utiliser ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬pour déployer une restauration de problème connu
Utiliser ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬pour installer à distance des logiciels
gestion ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬- GPMC ou AGPM
Erreur 0x8007000D lors de l’exécution de l’objet de stratégie de groupe Backup-
GPO dans Server Core
AGPM et GPRESULT ne fonctionnent pas
Les modifications apportées aux autorisations d’objet de stratégie de groupe ne sont
pas enregistrées
Créer un magasin central sur un contrôleur de domaine
L’outil Dcgpofix ne restaure pas les paramètres de sécurité à l’état d’origine
Description des groupes restreints de stratégie de groupe
Comment activer la fonctionnalité de bouclage ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Comment définir la sécurité du journal des événements localement ou via ‫ﻧﻬﺞ‬
‫اﻟﻤﺠﻤﻮﻋﺔ‬
Comment donner aux utilisateurs l’accès aux objets ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Gérer ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬fichiers de modèle d’administration
Les autorisations pour cet objet de stratégie de groupe sont incohérentes
Supprimer cet élément s’il n’est plus appliqué
Réinitialiser les droits d’utilisateur dans l’objet de stratégie de groupe de domaine
par défaut
Le répertoire n’est pas vide
Le système ne trouve pas le fichier spécifié
Résoudre les problèmes liés aux événements SCECLI 1202
Utiliser des objets de stratégie de groupe pour modifier le nom de domaine
d’ouverture de session par défaut
Utiliser Rsop.msc pour collecter la stratégie d’ordinateur
Conflit WinStoreUI.admx avec Windows 10 fichier ADMX
Message d’erreur incorrect pour les fichiers .adml manquants
Gestion des mappages de lecteurs via ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬Préférences supprime les mappages de lecteurs manuels
Gestion des paramètres d’Internet Explorer via ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
« Autoriser le contenu actif à exécuter des fichiers sur mon ordinateur » ne
fonctionne pas
Utiliser ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬pour contrôler l’accès aux sites web
Gestion des imprimantes via ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Les préférences d’imprimante ne peuvent pas définir l’imprimante par défaut
Gestion des appareils amovibles via ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Comment utiliser ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬pour désactiver les pilotes
Problèmes lors de l’application d’objets ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬à des utilisateurs ou à des
ordinateurs
Conseils de dépannage : Application de ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Erreur « L’espace de noms est déjà défini » lors de la modification d’une stratégie
Le paramètre « Définir le chemin du profil itinérant pour tous les utilisateurs qui se
connectent à cet ordinateur » s’applique aux comptes locaux
Un paramètre ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬n’est pas disponible dans la liste des paramètres de
stratégie de sécurité
Échec de l’authentification avec une erreur Accès refusé
Erreur 0x80004005 lorsque vous créez un DSN avec GPP
Événement 1202 avec état 0x534 journalisé
ID d’événement 1053 à l’aide de la commande « Gpupdate /force »
Les événements 1101 et 1030 sont consignés dans le journal des applications
Échec de l’exécution de l’Assistant Modélisation ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
La stratégie de groupe de redirection de dossiers n’est pas appliquée
‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬des erreurs lorsque la variable d’environnement inconnue est utilisée
La stratégie de groupe avec des filtres WMI peut être refusée ou entraîner une
ouverture de session/démarrage lente
ID d’événement Netlogon 5719 ou événement 1129 ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Les modifications de stratégie de mot de passe ne sont pas appliquées
Les paramètres sont appliqués à partir de ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Certaines zones ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬sont manquantes
Utiliser ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬pour ajouter l’entrée de Registre MaxTokenSize
Échec de l’application de l’élément de tâche planifiée GPP utilisateur
Des erreurs Userenv se produisent et les événements sont enregistrés
Les filtres ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬WMI ne fonctionnent pas
Filtrage de sécurité et ciblage au niveau de l’élément
Configurer des stratégies de groupe pour définir la sécurité
événements de préférences ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Problèmes d’accès ou de réplication Sysvol
Modifier les autorisations par défaut sur les objets de stratégie de groupe
Échec de la migration ou de la réplication de DFSR SYSVOL
Erreurs lors de l’exécution de GPMC
Comment forcer la synchronisation pour la réplication sysvol répliquée DFSR
Réduire la taille de SYSVOL en supprimant les modèles d’administration
Régénérer l’arborescence SYSVOL et son contenu dans un domaine
Les contrôleurs de domaine ne répliquent pas le répertoire partagé SYSVOL
Résoudre les problèmes liés aux partages SYSVOL et NETLOGON manquants
Disponibilité élevée
Disponibilité élevée
Impossible de mettre une ressource en ligne
Conseils de dépannage : Impossible de mettre une ressource en ligne
Impossible d’ajouter un nom de réseau en ligne
Impossible d’apporter un disque physique en ligne
Impossible d’apporter une adresse IP en ligne
Erreur « Le paramètre est incorrect »
Itinéraire actif supprimé
La ressource de disque de cluster ne peut pas être mise en ligne
Échec de la ressource de partage de fichiers de cluster
Informations de clustering sur le basculement d’adresse IP
Le compte de validation de cluster provoque des événements ou des messages
Erreur 0x8000ffff lorsque vous modifiez les paramètres de cliché instantané
Des messages d’erreur se produisent lors de la mise en ligne d’un groupe de clusters
Échec du partage de dossiers dans un cluster de basculement
Ajout de disques SAS locaux dans le cluster de basculement Windows Server
La ressource Nom réseau ne peut pas être mise en ligne
La ressource de disque physique ne se met pas en ligne
Récupérer un objet ordinateur qui prend en charge la ressource Network Name
Impossible de basculer un groupe
Fonctionnalités SMB 3.0 dans Windows Server 2012 serveur de fichiers
Le nœud de cluster est suspendu
Le fichier de vidage mémoire est endommagé
Échec du démarrage du service de cluster
Conseils de dépannage : Échec du démarrage du service de cluster
Options de démarrage du service de cluster
Le service de cluster cesse de répondre sur un nœud de cluster
Comment résoudre les problèmes liés au compte de service de cluster
Résoudre les problèmes de démarrage du service de cluster
Volume partagé de cluster (CSV)
Conseils de dépannage : ID d’événement 5120 Cluster Shared Volume
mise à jour Cluster-Aware (CAU)
Mises à jour recommandées pour les clusters de basculement basés sur Windows
Server 2012
Erreurs lors de l’exécution de l’Assistant Validation
La pac dans le cluster de basculement n’est pas mise en ligne
Échec du test de validation de cluster sur la configuration Active Directory
Erreur « Un élément avec la même clé a déjà été ajouté »
Échec de la validation du cluster de basculement
Échec du test de réservation persistante SCSI-3
Échec du test de validation du basculement de disque
Vous ne voyez pas le disque de cluster dans l’Explorateur ou diskmgmt lors du
basculement
Création initiale d’un cluster ou ajout d’un nœud
L’erreur « Le nœud de cluster existe déjà » peut apparaître lors de l’installation du
cluster
Échec de la validation du cluster avec l’erreur 80070005
La création d’un cluster de basculement échoue avec l’erreur 0xc000005e
L’ID d’événement du message d’erreur 1289 est journalisé lorsque vous essayez de
créer un cluster
Implications de l’utilisation du commutateur /forcequorum
Déplacer un cluster Windows Server vers un autre domaine
Échec de chargement du fournisseur
Résolution des problèmes liés aux nœuds de cluster invité dans Hyper-V qui ne sont
pas créés ou joints
Impossible de joindre un nœud à un cluster
Nœud supprimé du cluster
Les ressources d’adresse IP du cluster échouent sur les deux nœuds lorsqu’un nœud
se déconnecte
Imprimer des clusters et l’impression à haute disponibilité
Comment configurer un serveur d’impression en cluster
Remplacement du matériel et mise à jour du système d’exploitation
Impossible de mettre à niveau le système d’exploitation du serveur cluster
Comment mettre à jour des clusters de basculement
Mises à jour recommandées pour les clusters de serveurs Windows Server 2008 R2
Cause racine d’un basculement inattendu
Conseils de résolution des problèmes : Basculement inattendu du cluster
Comportement de basculement sur des clusters de trois nœuds ou plus
Exécuter la commande chkdsk /f sur un disque de cluster partagé
Mises à jour pour Windows Server 2012 clusters de basculement R2
Configuration et configuration de services et d’applications en cluster
Ajouter la prise en charge de plus de huit numéros logiques
Les logiciels antivirus causent des problèmes avec Cluster Services
Modifier l’adresse IP des cartes réseau dans un cluster
Configurer les clichés instantanés de la fonctionnalité Dossiers partagés
Configurer des points de montage de volume sur un cluster de serveurs
Créer des partages de fichiers sur un cluster
Activer la prise en charge à l’aide de contrôleurs RAID cluster
ID d’événement 1222 lorsque vous créez un cluster de basculement
Étendre la partition d’un disque partagé de cluster
Échec de la gestion du cluster avec le gestionnaire de cluster de basculement
Comment le service de cluster réserve et apporte des disques en ligne
Comment configurer FTP pour IIS dans un cluster de basculement
Stratégie de support Microsoft pour le cluster de basculement Windows Server
NetBIOS et WINS ne sont pas lier aux ressources d’adresse IP du cluster
Configuration « Heartbeat » privée recommandée sur un serveur de cluster
Mises à jour recommandées pour les clusters de basculement Windows Server 2008
R2 SP1
Les fonctionnalités SMB ne fonctionnent pas avec la configuration de nom réseau de
cluster non par défaut
Stratégie de prise en charge des solutions logicielles de stockage tierces
Messages d’avertissement inattendus dans un cluster de basculement virtualisé
Utiliser des nœuds de cluster Windows Server comme contrôleurs de domaine
Réseau
Réseau
Accès aux partages de fichiers distants (espace de noms SMB ou DFS)
Conseils de dépannage : SMB
Conseils de résolution des problèmes : Espace de noms DFS
Erreur « Échec de l’écriture différée »
%HOMEPATH%, %HOMESHARE%, et %HOMEDRIVE% variables sont résolus
incorrectement
Impossible d’utiliser des informations d’identification différentes pour un partage
réseau
Gestion de l’ordinateur montre que les sessions des clients sont lentes
Configurer DFS pour utiliser des noms de domaine complets
Service DFS Namespaces et ses données de configuration
Les utilisateurs du domaine ne parviennent pas à accéder à un partage sur un
serveur de fichiers
L’alias CNAME DNS ne parvient pas à connecter un partage de serveur de fichiers
SMB
Messages d’erreur sur les connexions SMB
Événement 1 sur l’initialisation du client témoin SMB
Événement 30818 lorsque les connexions RDMA basculent vers TCP
Échec de l’ouverture des partages de fichiers ou des composants logiciels
enfichables ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
L’accès invité dans SMB2 est désactivé par défaut
Correctifs logiciels pour les technologies de services de fichiers
Comment autoriser les utilisateurs distants à accéder à votre réseau
Comment créer un répertoire virtuel sur un site web existant
Comment désactiver manuellement un serveur racine
Comment supprimer des partages d’administration
Comportement de session IPC$ et de partage Null
Le lecteur réseau mappé est déconnecté
Le nom du dossier redirigé n’est pas un nom d’utilisateur
Les performances réseau de SMB Direct sont réduites
Autorisations de serveur et de fichier NFS
Des problèmes se produisent lorsque des partages administratifs sont manquants
Processus de récupération d’un espace de noms DFS
Robocopy peut signaler l’erreur 1338 ou 87
Vue d’ensemble de la signature du bloc de message serveur
Définition des options de serveur WINS principal et secondaire
Erreur système 1331 lorsque vous vous connectez à un partage
L’erreur système 67 s’est produite. Le nom du réseau est introuvable
Résoudre les échecs d’accès DFSN
Résoudre les problèmes d’ID d’événement 1020 sur un serveur de fichiers
Service de transfert intelligent en arrière-plan (BITS)
Erreur « Échec du téléchargement du fichier de contenu » lors du téléchargement
d’un fichier par BITS
DFSR
Le backlog est signalé pour le membre Read-Only DFSR
La taille du dossier ConflictAndDeleted dépasse la limite
Délégation de la réplication DFS
DFSR ne peut pas répliquer des fichiers après la restauration d’un serveur virtualisé
Blocage des bases de données DFSR sur le membre principal
Événement DFSR 2212 après le redémarrage du service DFSR
ID d’événement DFSR 2213
Le rapport d’intégrité DFSR affiche l’ID d’événement 4302
Erreur lors de la modification du groupe de réplication DFS ou de l’espace de noms
Comment configurer la journalisation DFSR
Le paramètre de sécurité modifie les retards sur les partenaires de réplication DFSR
La migration DFSR SYSVOL échoue après la mise à niveau sur place
Résoudre les erreurs journal_wrap sur les jeux de réplicas Sysvol et DFS
Résoudre les problèmes liés aux partages SYSVOL et Netlogon manquants
Scénario de déploiement DFS-R et DFS-N non pris en charge
DNS
Conseils de dépannage : DNS
Échec de l’accès à un serveur localement à l’aide de son nom de domaine complet
ou de son alias CNAME
Comportement du numéro de série de zone DNS intégré à Active Directory
Éviter d’inscrire une carte réseau indésirable dans DNS
Meilleures pratiques pour les paramètres du client DNS
Impossible de supprimer un enregistrement d’une zone DNS
Impossible de modifier le fichier Hosts ou Lmhosts
Compatibilité d’Exchange avec les domaines à étiquette unique, les espaces de
noms disjoints et discontiguous
Configurer un serveur de noms secondaire
Délais d’expiration de la résolution du client DNS
Planification de l’espace de noms DNS
Échec des requêtes DNS sur certains domaines
Les enregistrements DNS ne s’affichent pas dans les zones DNS
DNS enregistre les enregistrements SRV en double pour un contrôleur de domaine
Les serveurs DNS ne résolvent pas les requêtes pour les domaines de niveau
supérieur
Événement journaux du serveur DNS 7062
Vulnérabilité du serveur DNS aux attaques par espionnage de cache
Les options de transfert de zone DNS sont réinitialisées de manière inattendue
Le serveur DNS devient une île
Événement 4015 lors de l’exécution de DNS sur RODC
Événements 407 et 408 lors de l’interrogation du serveur DNS
ID d’événement 4000 et 4007 quand les zones DNS ne sont pas chargées
Délais de résolution des redirecteurs et des redirecteurs conditionnels
GetAddrInfo échoue avec l’erreur 11001
Comment configurer des mises à jour dynamiques DNS
Comment créer une partition d’annuaire d’applications personnalisée
Comment activer ou désactiver les mises à jour DNS
Comment déplacer des zones DNS vers un autre serveur
Intégrer Windows DNS dans un espace de noms DNS existant
Problèmes de résolution de noms et de connectivité
NBTSTAT -A ne résout pas le nom de l’ordinateur avec DNS
Aucune mise à jour dynamique sur la zone de recherche inversée sans classe
Empêcher les contrôleurs de domaine de noms DNS
Les enregistrements ne sont pas supprimés en cas de nettoyage manuel
Les indicateurs racines réapparaissent après avoir été supprimés
Stratégie de prise en charge des domaines à étiquette unique
L’enregistrement A de l’hôte est inscrit dans DNS
Fonctionnalité de commande netmask et de tourniquet (round robin)
Résoudre les problèmes liés à l’ID d’événement DNS 4013
Résoudre les problèmes de résolution de noms DNS sur Internet
Vérifier que les enregistrements DNS SRV ont été créés
Échec de l’inscription WINS si un serveur pointe vers lui-même pour la résolution de
noms WINS
Protocole DHCP (Dynamic Host Configuration Protocol)
Conseils de dépannage : DHCP
Impossible d’ajouter une réservation DHCP
Le client DHCP ne peut pas obtenir d’adresse IP affectée par DHCP
Le serveur DHCP envoie un DHCPNAK aux clients
Les mises à jour dynamiques des inscriptions DNS sont retardées
ID d’événement 1056 après l’installation de DHCP
Impossible de modifier l’étendue DHCP existante
Augmenter le nombre d’adresses IP sur un sous-réseau
Installer et configurer un serveur DHCP dans un groupe de travail
Problèmes connus avec le basculement DHCP
Les clients PXE ne démarrent pas
Utiliser l’utilitaire Netsh pour exporter et importer des étendues DHCP
Frs
Codes d’erreur du journal des événements FRS
Comment réinitialiser le dossier de préproduction FRS
NTFRS_xxxxxxxx est ajouté à un nom de dossier
Événement d’erreur NTFRS 13559 et arrêt de la réplication
Récupération d’objets et d’attributs FRS manquants dans AD
Résoudre les problèmes liés au service de réplication de fichiers
Utiliser BurFlags pour réinitialiser FRS
Windows Server version 1709 ne prend plus en charge FRS
Gestion des adresses IP (IPAM)
Une adresse IP incorrecte est retournée
Installer et configurer IP version 6
Équilibrage de charge réseau (NLB)
Concept et notes d’équilibrage de charge réseau
Configurer l’infrastructure réseau pour prendre en charge le mode d’opération NLB
RADIUS - Serveur de stratégie réseau (NPS) ou IAS (Internet Authentication Service)
Conseils de dépannage : Serveur de stratégies réseau
Exigences relatives aux certificats lorsque vous utilisez EAP-TLS
Accès à distance
Conseils de dépannage : Accès à distance (VPN et AOVPN)
Conseils de dépannage : DirectAccess
Impossible de se connecter à Internet sur un serveur VPN
Configurer le verrouillage du compte client d’accès à distance
Les clients DirectAccess ne peuvent pas se connecter au serveur
Performances réseau de DirectAccess dans Windows
Erreur 51 ou 53 lorsque vous accédez à des ressources partagées
Erreur 633 : le modem est déjà utilisé
Installation et configuration d’un serveur VPN
Échec du VPN L2TP avec l’erreur 787
Échec des connexions VPN LT2P/IPsec RAS
Configurer le routage et l’accès à distance pour un intranet
Le service de routage et d’accès à distance ne démarre pas
Résoudre l’erreur 720 lors de l’établissement d’une connexion VPN
Mises à jour pour Windows Server 2012 et DirectAccess R2 2012
Résoudre les problèmes de la console serveur DirectAccess : 6to4
Résoudre les problèmes liés à la console serveur DirectAccess : DNS
Résoudre les problèmes de la console serveur DirectAccess : contrôleur de domaine
et Kerberos
Résoudre les problèmes liés à la console serveur DirectAccess : IP-Https et IPSec
Résoudre les problèmes liés à la console serveur DirectAccess : réseau et haute
disponibilité
Communications TCP/IP
Conseils de dépannage : communication TCP/IP
Conseils de dépannage : Performances TCP/IP
Un serveur SMB ne répond pas
Échec de l’accès aux sites web hébergés sur akamai CDN
Comportement de mise en cache du protocole ARP (Address Resolution Protocol)
Passerelle par défaut vide après la configuration de l’adresse IP statique
Configurer l’ordinateur ISA Server pour les demandes d’authentification
Configurer les paramètres du serveur proxy
Configurer le service SNMP
Supprimer toutes les connexions actives de l’ordinateur local
SMB de l’hôte direct sur TCP/IP
Les clients DirectAccess ne peuvent pas se connecter lorsqu’un proxy statique est
configuré
Désactiver les fonctionnalités de proxy HTTP
Désactiver la fonctionnalité de détection de média pour TCP/IP
Désactiver NetBIOS sur TCP/IP à l’aide d’options de serveur DHCP
DNS fonctionne à la fois sur TCP et UDP
Erreur 0x2AFC ou 0x274D lorsque les clients DirectAccess tentent de se connecter
via IP-HTTPS
Message d’erreur lorsque vous définissez une adresse IP
Événement 1500 lorsque SNMP est activé
L’ID d’événement 7023 est journalisé
Échec de l’ouverture des propriétés TCP/IP de la carte réseau
Modifier l’adresse IP d’une carte réseau
Comment configurer une zone de recherche inversée subnetted
Comment configurer IPv6 pour les utilisateurs avancés
Comment configurer l’allocation de ports dynamiques RPC pour qu’elle fonctionne
avec des pare-feu
Comment configurer la mise en réseau TCP/IP si NetBIOS est désactivé
Comment installer l’adaptateur de bouclage Microsoft
Comment résoudre les problèmes liés aux fonctionnalités avancées de
performances réseau
Guide pratique pour résoudre les problèmes liés à la jointure du lieu de travail
Comment utiliser PortQry pour résoudre les problèmes de connectivité AD
Comment configurer le filtrage TCP/IP
Informations sur Network Monitor 3
Les paramètres ip et de passerelle par défaut sont attribués de manière incorrecte
Plusieurs passerelles par défaut provoquent des problèmes de connectivité
Systèmes d’exploitation commandes Net
Compatibilité du système d’exploitation avec les serveurs racines DNSSEC activés
Partie 1 : Vue d’ensemble des performances TCP/IP
Partie 2 : Problèmes réseau sous-jacents de performances TCP/IP
Partie 3 : Problèmes connus liés aux performances TCP/IP
Utilisation de l’outil en ligne de commande PortQry
Processus de l’établissement d’une liaison TCP triple
Fonctionnalité de paramétrage automatique de la fenêtre de réception pour le trafic
HTTP
Réserver une plage de ports éphémères
Vue d’ensemble des services et exigences relatives aux ports réseau
Des performances lentes se produisent lorsque vous copiez des données sur un
serveur TCP
Partage SMB inaccessible lorsque le port TCP 445 est à l’écoute
Fonctionnalités de déchargement TCP Chimney, de mise à l’échelle côté réception
et d’accès direct à la mémoire réseau
Fonctionnalités TCP dans Windows
Arrêts du trafic TCP
Les propriétés TCP/IP revient aux paramètres par défaut
TcpAckFrequency pour contrôler le comportement TCP ACK
Fonctionnalité de métrique automatique pour les itinéraires IPv4
La plage de ports dynamiques par défaut pour TCP/IP a changé
Utiliser WHOIS pour rechercher des domaines Internet
Les machines virtuelles perdent la connectivité réseau
WSAEMSGSIZE - Erreur 10040 dans Winsock 2.0
Webwindows-client et WebDAV
L’accès aux sites FQDN nécessite des informations d’identification
Pare-feu Windows avec sécurité avancée (WFAS)
Conseils de résolution des problèmes : Pare-feu Windows avec sécurité avancée
Erreur 0x000006D9 lorsque vous partagez une imprimante
Comment désactiver le mode furtif
La communication UDP est bloquée
Utiliser le contexte de pare-feu netsh advfirewall
Association de cartes réseau Windows (basculement d’équilibrage de charge)
État « Échec introuvable » pour l’équipe de carte réseau
ID d’événement 236 avec SR-IOV activé
ID d’événement du noyau 2 quand MSFT_NetLbfoTeamNic est appelé
Minuteur LACP configuré de manière incorrecte lors de la création d’une équipe de
carte réseau pour LBFO
Performances réseau médiocres sur les machines virtuelles quand VMQ est activé
Les services ne redémarrent pas automatiquement avec l’association de cartes
réseau
GAGNE
Résoudre les problèmes liés aux événements WINS 4102, 4243, 4242 et 4286
Mise en réseau sans fil et authentification 802.1X
Conseils de dépannage : technologie sans fil
Configurer le serveur L2TP/IPsec derrière l’appareil NAT-T
Configurer le partage de connexion Internet
Performances
Performances
Applications
Impossible de définir des fichiers de page sur une partition supérieure à 2 téraoctets
Compatibilité des programmes 32 bits sur les versions 64 bits de Windows
La copie de fichiers .EXE peut entraîner une erreur de violation de partage - Dossier
utilisé
ID d’événement ESENT 327 et 326
Modifications apportées au Registre dans les versions x64 de Windows
Valeurs de Registre pour les paramètres de contrôle de processus
Écran bleu/Vérification des bogues
Conseils de résolution des problèmes : arrêter les erreurs et redémarrer de façon
inattendue
Erreur « Arrêter 0x0000000A » pour les cv du processeur à partir de l’état
d’inactivité C1
Désactiver ou activer le programme Dr Watson
Erreur 0x00000007B après la reconfiguration des périphériques matériels
Erreur 0x00000019 lorsque NTFS crée un nom au format 8.3
Erreur 0x000000D1 lorsque vous avez activé le contrôleur de stockage
Impossible d’accéder au dossier partagé à partir d’applications
Comment utiliser le vérificateur de pilote pour identifier les problèmes
Options du fichier de vidage mémoire
Arrêter 7F, erreur de 0x00000008 (double-erreur)
Arrêter le code DRIVER_VERIFIER_DMA_VIOLATION
Arrêter l’erreur « DRIVER_IRQL_NOT_LESS_OR_EQUAL »
Arrêter l’erreur 0x109 sur une machine virtuelle VMWare
Arrêter l’erreur 7E sur un serveur exécutant NFS
Arrêter le code d’erreur 0x0000007F
Basculer Terminal Services vers le mode Serveur d’applications
Résoudre l’erreur « STOP 0xC000021A »
Utiliser Dumpchk.exe pour vérifier un fichier de vidage de mémoire
Le démarrage est lent
L’ordinateur se fige lorsqu’il est connecté à l’aide de RDP
Un dépôt WMI volumineux provoque une ouverture de session lente
Le service utilisant un compte gMSA ne démarre pas
Démarrage lent et échec de démarrage des services
Résoudre les problèmes de démarrage
No Boot (not BugChecks)
Écran noir au démarrage
Impossible de démarrer à partir du deuxième média de démarrage sur les
ordinateurs UEFI
Impossible de mettre en forme ou d’utiliser correctement une partition de disque
L’ordinateur ne démarre pas après que vous avez marqué la partition principale
comme étant active
L’ordinateur continue de démarrer en mode sans échec
ID d’événement 46 lorsque vous démarrez un ordinateur
Échec du redémarrage de Windows après la récupération complète du système
d’exploitation
Échec du démarrage en mode normal - Problème de pilote
Résolution des problèmes liés au Registre pour les utilisateurs avancés
Échec du démarrage lorsque la protection du microprogramme est activée
ARRÊTER 0X0000007B erreur lors du démarrage à partir d’une autre carte iSCSI
Prise en charge du démarrage à partir de SAN
Options de commutateur pour les fichiers Boot.ini
Résoudre l’erreur « NTLDR is Missing »
Utiliser WinRE pour résoudre les problèmes de démarrage
Outils d’analyse des performances
Les fréquences d’UC affichées dans la page de propriétés système ne
correspondent pas
Créer une alerte de compteur de performances
Performances de disque plus lentes avec plusieurs disques
Comment déterminer quel programme utilise ou bloque des ports TCP spécifiques
Comment activer des messages d’état détaillés
Comment obtenir un handle de fenêtre de console
Limitation connue de l’interface utilisateur des informations d’UC dans Windows
Server 2016
Les fichiers journaux sont supprimés lorsque vous utilisez Monitor de Desempenho
Régénérer manuellement les compteurs de performances
Surveiller les performances des ordinateurs distants
La fonction QueryPerformanceCounter fonctionne mal dans certains programmes
Reconstruire les valeurs de la bibliothèque de compteurs de performances
Moniteur de fiabilité n’affiche aucune information
Le processus de génération de rapports cesse de répondre
Configuration et réglage du service serveur
Le Gestionnaire des tâches affiche des informations de mémoire incorrectes
Impossible d’allouer de la mémoire à partir du pool pagagé système
Le jeu de collecteurs de données défini par l’utilisateur ne s’exécute pas comme
prévu
Mémoire virtuelle dans la version 32 bits de Windows
L’arrêt est lent ou se bloque
code de raison d’arrêt incorrect écrit dans SEL
Utiliser Userdump.exe pour créer un fichier de vidage
Performances lentes
Conseils de résolution des problèmes : Utilisation élevée du processeur
Ajouter des processeurs à un ordinateur
Une erreur se produit lors de la suppression des clés de Registre
Utilisation élevée du processeur lors de la recherche dans l’application Paramètres
Les fichiers de vidage de mémoire du noyau sont générés
Prise en charge de la mémoire volumineuse dans Windows Server 2003
Problèmes de performances avec le profil utilisateur par défaut personnalisé
Performances lentes lors de l’utilisation du plan d’alimentation
Performances lentes avec des fichiers sur le réseau
Blocage du système
Impossible de redémarrer un ordinateur Windows Server qui utilise Credential
Guard et Hyper-V
Compresser les ruches de registre volumineuses
Description du Registre Windows
La limitation du tas de bureau provoque une erreur de mémoire insuffisante
L’activation du mode débogage entraîne le blocage de Windows
L’ordinateur cesse de répondre
Impression
Impression
Conseils de dépannage : Impression
Résoudre les problèmes d’impression
Résoudre les problèmes d’impression et les meilleures pratiques
Résoudre les problèmes d’impression
Résoudre les problèmes connus d’impression
Gestion et configuration de l’installation des pilotes d’impression
Imprimer les erreurs du spouleur
Erreurs et résolution des problèmes : Problèmes généraux
Impossible d’imprimer après l’installation d’un service pack ou d’un correctif
d’imprimante
Erreur lors de l’installation d’une imprimante réseau partagée
ID d’événement associé aux restrictions de point et d’impression
La redirection d’imprimante et de lecteur ne fonctionne pas dans une session
Terminal Server
Performances lentes avec les pilotes d’imprimante HP
Spooler.xml croissance des fichiers et un processeur élevé dans spoolsv.exe
processus
Le nouvel état de l’imprimante est hors connexion
Impossible d’imprimer avec les pilotes d’imprimante de type 4 ou 3
Windows n’a pas pu se connecter à l’imprimante
Erreurs et résolution des problèmes : sortie d’impression ou échecs d’impression
L’impression s’interrompt après chaque 11 travaux d’impression
Erreurs et résolution des problèmes : Spouleur d’impression
La taille du fichier spool EMF augmente en taille lors de l’impression d’un document
avec un grand nombre de données raster
Liste des imprimantes vide dans la console de gestion des impressions
Le spouleur d’imprimante se bloque de manière aléatoire
Gestion et configuration : Problèmes généraux
Ajouter la fonctionnalité Répertoire d’impression pour les dossiers
Comment imprimer dans un fichier sans intervention de l’utilisateur
Les serveurs ne peuvent pas être utilisés comme serveurs d’impression
Moniteur de port standard pour TCP/IP
Utiliser des enregistrements CNAME pour consolider les serveurs d’impression
Gestion et configuration : installation de pilotes d’impression
Un pilote d’imprimante ne peut pas être installé via Windows Update
Comment configurer l’impression Sur Internet
Comment trouver un pilote d’imprimante compatible
Installation et configuration d’un serveur de fichiers et d’impression
Les imprimantes sont regroupées en une seule avec des appareils et des
imprimantes
Gestion et configuration : sauvegarde et migration de file d’attente d’impression
Sauvegarder et restaurer des imprimantes lors de la mise à niveau
Gestion et configuration : imprimantes via ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Utiliser ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬pour contrôler les imprimantes
Services Bureau à distance
Services Bureau à distance
Administration
Un écran noir peut apparaître lors de la connexion
Échec de l’ajout du rôle Services Bureau à distance
Mises à jour disponibles pour les services Bureau à distance dans Windows Server
2012 R2
Impossible de créer une collection de sessions
Configuration de la connexion dans Terminal Server
Refuser aux utilisateurs les autorisations de se connecter au serveur hôte de session
Bureau à distance
Erreur 2147944102 lorsque vous démarrez le service BITS
Fair Share est activé par défaut dans les services Bureau à distance
Comment ajouter un utilisateur aux autorisations RDP de Terminal Services
Comment activer Windows Remote Shell
Comment ombrager une session Terminal Server
Comment désactiver temporairement les journaux du client Terminal Server
TLS incorrect s’affiche
Installer le service de rôle RDS sans Service Broker de connexion
Limiter les connexions sur un serveur terminal
Fichiers journaux pour la résolution des problèmes liés aux services Bureau à
distance
RdS ne parvient pas à s’installer avec l’erreur 0x800706D9
Mises à jour recommandées pour rds dans Windows Server 2012 R2
Présentation du protocole Bureau à distance
Le service Bureau à distance ne peut pas redémarrer si Keep-Alive est activé
Les outils des services Bureau à distance ne sont pas fonctionnels
Mises à jour des services Bureau à distance dans Windows Server 2012
Mises à jour des services Bureau à distance dans Windows Server 2016
Configurer le script d’ouverture de session uniquement pour les utilisateurs de
Terminal Server
Commandes du serveur terminal : CHANGE
Erreurs Terminal Server 2200 à 2299
Démarrage, connexion et application de Terminal Server
Paramètres de connexion stockés dans le fichier Default.rdp
Mises à jour pour les services Bureau à distance
Compatibilité des applications
Configuration requise du client RDC pour TS Web Access
Paramètres de Registre Terminal Server pour les applications
Authentification
0xC000035B lorsque vous utilisez LmCompatibility
Les clients ne peuvent pas se connecter à Terminal Server
Impossible de contacter l’autorité de sécurité locale
Gestion des certificats
Messages d’erreur lors de la connexion à un serveur terminal
Échec du répartiteur de connexions RDS ou RDMS
Utiliser un certificat d’authentification serveur personnalisé pour TLS sur RDS
Connexion à une session ou un bureau
Se connecter à une session de console fantôme avec Terminal Services
Erreur 0xc0000005 lorsque vous vous connectez au client Terminal Server
ID d’événement 10000 lorsque Terminal Server est activé
Impossible de se connecter à un serveur terminal
Comment connecter des clients à Terminal Services
Comment supprimer des entrées de la zone Ordinateur de connexion Bureau à
distance
La stratégie locale n’autorise pas l’ouverture de session de manière interactive
Le nouvel utilisateur ne parvient pas à se connecter via RDP
La fonctionnalité RSL (Registry Size Limit) est toujours respectée
Le contrôle à distance demande l’autorisation de l’utilisateur
Mise à jour du client Connexion Bureau à distance 6.1
La connexion bureau à distance est bloquée
La session connexion Bureau à distance est prise en charge avec le protocole Bureau
à distance
Résoudre les problèmes d’établissement d’une session Terminal Services
Résoudre les erreurs de Bureau à distance déconnecté
Équilibreur de charge et répartiteur de connexions
Problèmes de communication
Le rôle RDS ne peut pas coexister avec le rôle AD DS
La batterie de serveurs Bureau à distance n’est pas disponible sur DirectAccess
Performances (audio et vidéo) et RemoteFX
Le taux d’images est limité à 30 FPS dans les sessions distantes
Les machines virtuelles remoteFX nouvelles et existantes ne démarrent pas
Les paramètres GPU physiques ne sont pas disponibles après la jonction de domaine
Le Bureau à distance ne peut pas se connecter à un poste de travail virtuel
Impression (y compris la redirection)
La redirection de l’imprimante ne fonctionne pas
RDWeb
Impossible d’afficher les programmes « RemoteApp »
Impossible de se connecter à un ordinateur distant
Aucune icône Connectée dans la zone de notification
L’onglet Bureau à distance dans RDWEB est manquant dans Edge
Redirection (et non imprimante)
Le changement d’état de verrouillage des majuscules n’est pas synchronisé avec
l’ordinateur client
Échec de la copie de fichiers de plus de 2 Go
Le scanneur redirigé USB RemoteFX ne démarre pas
Licence des services Bureau à distance (Terminal Services)
Conseils de dépannage : Gestion des licences rds
Impossible de se connecter aux services Bureau à distance, car aucun serveur de
licences des services Bureau à distance n’est disponible
Erreur « Les licences ne sont pas disponibles pour ce Bureau à distance » dans Le
diagnostic des licences
Configurer les certificats d’écouteur RDP
Désactiver ou réactiver un serveur de licences
Erreur après la configuration des serveurs broker de connexion Bureau à distance
pour la haute disponibilité
ID d’événement 4105 lors de l’exécution des licences bureau à distance
ID d’événement 44 sur un serveur de licences RDS
Guide pratique pour intaller et configurer le connecteur externe
Guide pratique pour déplacer des listes de certification Terminal Services
Les attributs de licence ne sont pas mis à jour
Le service de gestion des licences bureau à distance ne démarre pas
Supprimer des licences Terminal Server du client RDP
Configurer les licences bureau à distance entre les forêts de domaines ou les
groupes de travail
Licence Terminal Server pour le déploiement
Licences Terminal Server
Sessions bureau à distance
Conseils de dépannage : connectivité de session RDS
« Erreur système 67 » lors de l’utilisation du nom de domaine complet pour
connecter un ordinateur distant
Blocage des applications si un autre utilisateur se déconnecte
Mises à jour disponibles pour Terminal Services (Services Bureau à distance)
Impossible de supprimer un hôte bureau à distance d’un déploiement RDS
Impossible d’établir une session Bureau à distance
Impossible d’agrandir la fenêtre de session RDC en plein écran
Modifications apportées aux 連線管理員 distantes
Les clients sont déconnectés pendant ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬mise à jour
Le répartiteur de connexions ne peut pas être mixte
Comment désactiver le message d’avertissement pour les sessions bureau à distance
inactives
La redirection de lecteur local ne fonctionne pas dans la session RDP
Déconnecter tous les utilisateurs de session Terminal Server
La commande QUERY USER ne peut pas interroger à partir d’un serveur distant
Le client RDS ne peut pas se connecter au serveur hôte de session Bureau à distance
Connexion Bureau à distance 6.0 invite à entrer des informations d’identification
La virtualisation IP bureau à distance ne fonctionne pas
La session Bureau à distance ou RemoteApp ne se termine pas
Partage d’applications uniques avec Terminal Server
MSG de commandes Terminal Server
Le répertoire d’accueil de l’utilisateur terminal Server n’est pas défini correctement
Applications RemoteApp
L’application ne démarre pas dans la session TS RemoteApp
Afficher les problèmes lors du déploiement d’applications via le mode Hi-Def
RemoteApp
Les sessions RemoteApp sont déconnectées
Infrastructure VDI (Virtual Desktop Infrastructure)
Erreur « Ce nom d’ordinateur n’est pas valide » lors de l’ombrage d’une session
distante
La collection VDI nécessite une approbation bidirectionnelle
Ressources
Agent virtuel
Présentation de l’agent de support virtuel pour Windows Commercial
Sécurité et programmes malveillants
Sécurité et programmes malveillants
Suspicion qu’un processus ou un service inconnu est malveillant
Alerte de virus sur le ver Blaster et ses variantes
Expérience shell
Expérience shell
Applications tierces
Impossible de créer une règle de hachage AppLocker pour un fichier
Cortana et la recherche
La recherche Windows est désactivée par défaut
Desktop Shell
Impossible de configurer un module linguistique
Impossible d’utiliser la commande « runas »
Activer et utiliser la fonctionnalité d’identification
Erreur multipoint Manager au démarrage
Le Gestionnaire de tâches affiche une valeur incorrecte pour le cache L2/L3
Utiliser l’exécution pour démarrer une application en tant qu’administrateur
Problèmes d’ppp et d’affichage
L’ajustement ppp n’est pas disponible dans la session à distance
DST et fuseaux horaires
Heure incorrecte sur les versions 64 bits de Windows
Le format de date par défaut est modifié
проводник/l’Explorateur Windows
Utilisation accrue du processeur lors de l’accès à un partage FileTable
Le dossier TEMP avec l’ID de session d’ouverture de session est supprimé
Écran de verrouillage ou économiseur d’écran
Impossible d’afficher le nom du dernier utilisateur connecté
Assistance à distance
La connexion d’assistance à distance ne fonctionne pas avec le chiffrement FIPS
Menu Démarrer
Les raccourcis du menu Démarrer ne sont pas immédiatement accessibles
Lecteur Windows Media
Comment activer les fonctionnalités d’expérience utilisateur
Mise en réseau définie par logiciel
Mise en réseau définie par logiciel
Conseils de dépannage : SDN
Serveur DNS interne pour SDN
Centre de données défini par logiciel et mise en réseau à définition logicielle
Composants de gestion système
Composants de gestion système
Observateur d'événements
Échec du transfert du journal des événements de sécurité avec erreur 0x138C et
5004
Aide et support
Le suivi d’événements pour Windows est simplifié
Outils de support Windows Server 2003 Service Pack 1
Microsoft Management Console (MMC)
Un service lent ne démarre pas en raison d’une erreur de délai d’attente
Impossible de se connecter à Enhedshåndtering à distance
Erreur 1783 lorsque vous ouvrez Services.msc
Échec de l’activation du journal des événements d’analyse ou de débogage
Modifier à distance le registre d’un ordinateur client
Résoudre les problèmes liés aux autorisations de démarrage du service
Résoudre les problèmes de connectivité de la console Administrateur SMS
Présentation de MMC
PowerShell
Enter-PSSession cmdlet échoue
Les caractères CJC sont tronqués dans PowerShell
Gestionnaire de serveur
code d’erreur 0x800706BE
Erreur lorsque vous sélectionnez Rôles dans 伺服器管理員
Outils d'administration de serveur distant
Gestionnaire des tâches
Échec de l’ouverture du Gestionnaire des tâches
Planificateur de tâches
Erreur 0x8007000d lorsque vous exécutez une ancienne tâche planifiée
Guide pratique pour planifier un processus serveur
La tâche planifiée peut ne pas s’exécuter au redémarrage
Les tâches planifiées référencent des chemins d’accès de profil utilisateur incorrects
Winrm
Le service WinRM ne démarre pas
WMI
Utilisation élevée du processeur par processus WmiPrvSE.exe
Erreur 0x8004106C pendant l’exécution de requêtes WMI
Événement 5605 lors de l’interrogation de l’espace de noms MSCluster par WMI
Événement Microsoft-Windows-RPC-Events 11 après le redémarrage
Nouveau comportement de l’arbitre WMI
UserProfiles et ouverture de session
UserProfiles et ouverture de session
Redirection de dossiers
Échec de la configuration de la redirection de dossiers avec ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
La redirection de dossier échoue avec ERROR_SEM_TIMEOUT
Les paramètres de redirection de dossier ne sont pas appliqués
Échec de l’ouverture de session de l’utilisateur
Informations d’ouverture de session de domaine mises en cache
Impossible de se déconnecter à partir d’un ordinateur
Erreur 1384 lorsque vous vous connectez à un domaine
Erreur : le serveur RPC n’est pas disponible
L’ouverture de session interactive n’est pas autorisée
Activer l’ouverture de session automatique
Le chargement des profils utilisateur peut échouer
Windows se connecte et se déconnecte immédiatement
Profils utilisateur
Erreur « Le nom de fichier ou l’extension est trop long »
Affecter un script d’ouverture de session à un profil pour un utilisateur local
Guide pratique pour créer des dossiers redirigés ou des dossiers d’accueil optimisés
pour la sécurité
Comment supprimer un profil utilisateur
Gestion de la détection de liaison lente du service profil utilisateur
Problèmes d’ouverture de session lorsque vous activez « Exécuter des scripts
d’ouverture de session de façon synchrone »
Échec du chargement du profil
Réadressation des répertoires Utilisateurs et ProgramData
Gestion de versions des profils utilisateur itinérants
L’utilisateur peut ne pas être en mesure de modifier son mot de passe
Virtualisation
Virtualisation
Sauvegarde et restauration de machines virtuelles
Sauvegarder et restaurer une machine virtuelle Hyper-V
Sauvegarder des machines virtuelles à partir d’une partition parente
Sauvegarde de machines virtuelles appartenant à un cluster invité
Impossible d’exporter une machine virtuelle
Erreur 0x80070005 lors de l’exportation de machines virtuelles vers un partage
réseau
Conteneur
L’appel d’API des compteurs de performances est retardé
Configuration des paramètres de machine virtuelle
Mise en cache dans la pile de stockage virtuel
Le copier-coller ne fonctionne pas lorsque vous vous connectez à une machine
virtuelle Hyper-V
L’allocation de mémoire dynamique dans une machine virtuelle ne change pas
Carte réseau fantôme générée à partir de modèles VMware
Hyper-V limite le nombre maximal de processeurs
La machine virtuelle Hyper-V ne démarre pas et déclenche 0x80070057 erreur
Emplacements de fichiers pris en charge par la machine virtuelle Hyper-V
Importation d’une machine virtuelle
Problèmes de résolution de la souris et de l’écran
Démarrage et arrêt lents sur les machines virtuelles
La structure d’ID de sécurité n’est pas valide (0x80070539)
Utilisation d’Hyper-V avec des lecteurs grand secteur
Échec de l’utilisation de Vmconnect.exe pour se connecter à une machine virtuelle
ID d’événement fournisseur de base VDS 1
La machine virtuelle ne peut pas atteindre le réseau lorsque le balisage vLan est
activé
Machines virtuelles à haute disponibilité
Impossible de modifier la valeur ConfigStoreRootPath d’un cluster Hyper-V
Les utilisateurs ne peuvent pas se connecter au serveur virtuel après le basculement
Virtualisation de réseau Hyper-V (HNV)
ID d’événement 106
Réplica Hyper-V
Événements 18210 et 3041 lorsque le réplica Hyper-V est configuré
Événements lors de la sauvegarde d’un disque sur la machine réplica
Optimisation des fonctionnalités et des performances de HVR
La réplication Hyper-V est suspendue à l’arrêt du système
Installation et configuration d’Hyper-V
Exclusions antivirus pour les hôtes Hyper-V
Impossible d’importer une machine virtuelle
Événement 7000 après l’installation du rôle Hyper-V
Échec du service VMM Hyper-V avec l’ID d’événement 14050
Les erreurs de version incompatibles sont consignées
Problèmes lors du démarrage de la machine virtuelle ou de l’installation d’Hyper-V
Mises à jour recommandées pour Windows Server 2012 environnements Hyper-V
R2
Correctifs logiciels, mises à jour et solutions connues recommandés
Exécuter des programmes sur des logiciels de virtualisation matérielle non Microsoft
Échec de SCVMM P2V avec erreur 0x80070005
Spécifications pour le matériel émulé et synthétique pris en charge
Stratégie de support pour l’association de cartes réseau avec Hyper-V
Mettre à niveau des ordinateurs avec le rôle Hyper-V installé
Composants d’intégration
Message des services d’intégration détériorés pour les invités non Windows
L’ID d’événement 4096 est enregistré dans l’hôte Hyper-V
La synchronisation de l’heure Hyper-V n’ajuste pas l’horloge du système de machine
virtuelle
La valeur de temps d’activité de la console de gestion Hyper-V passe à l’heure de
reprise
L’appareil VMBus ne se charge pas
L’état de VM Integration Services signale une incompatibilité de version de
protocole
Appareils inconnus dans Device Manager
Migration dynamique
Conseils de dépannage : Migration dynamique
Impossible de migrer une machine virtuelle d’un hôte vers un autre
Échec du démarrage ou de la migration dynamique des machines virtuelles Hyper-V
Résoudre les problèmes de migration dynamique
Captures instantanées, points de contrôle et disques de différenciation
Impossible de supprimer un point de contrôle de récupération pour une machine
virtuelle dans DPM
Fusion des points de contrôle qui ont plusieurs disques de différenciation
Configuration du stockage
Impossible d’ajouter un deuxième adaptateur Fibre Channel
Message d’erreur après avoir placé le fichier de page sur un autre lecteur que le
lecteur C
Échecs d’E/S FCoE sur les invités Hyper-V
Les numéros d’unités logiques de machine virtuelle disparaissent une fois que vous
les avez configurés en tant qu’appareils MPIO
Création d’une machine virtuelle
Erreur lors de la gestion d’un fichier VHD
Logiciels serveur Microsoft et environnements de virtualisation pris en charge
Partenaires de support pour les logiciels de virtualisation matérielle autres que
Microsoft
Machines virtuelles manquantes
État de la machine virtuelle
Get-VMNetworkAdapter commande ne signale pas d’adresses IP
Les actions d’arrêt de machine virtuelle ne s’exécutent pas
虛擬機器 entrer l’état suspendu
La machine virtuelle ne démarre pas
Erreur « Impossible de démarrer la machine virtuelle »
0x8000FFFF erreur lorsque vous démarrez une machine virtuelle
Échec du démarrage de la machine virtuelle sélectionnée
La machine virtuelle Hyper-V ne peut pas démarrer lorsque le lancement sécurisé
de System Guard est activé
Échec du démarrage de la machine virtuelle Hyper-V
Les machines virtuelles Hyper-V restaurées peuvent ne pas démarrer
La machine virtuelle ne démarre pas
Virtual Switch Manager (vmswitch)
Impossible de créer un commutateur virtuel dans Hyper-V
Échec de la création de commutateurs V dans l’environnement Hyper-V
Limite par défaut de 256 adresses MAC dynamiques
La connectivité réseau est perdue si VMQ est activé
Événement VmSwitch Error 113
Sécurité Windows
Sécurité Windows
Verrouillages de compte
Outils de verrouillage et de gestion de compte
Comportement d’expiration du mot de passe du compte administrateur
Énumérer les comptes d’utilisateur verrouillés à l’aide de requêtes enregistrées
Renommer les comptes d’administrateur et d’invité
Utiliser l’utilitaire EventCombMT pour rechercher des verrouillages de compte dans
les journaux des événements
Bitlocker
Conseils de dépannage : MBAM
Comment configurer MBAM avec une communication réseau sécurisée
Utilisation de la visionneuse de mot de passe de récupération BitLocker
L’enregistrement d’ordinateur est rejeté dans MBAM
Erreur lors de l’ouverture de rapports dans MBAM
Erreur lors de l’affichage des rapports dans MBAM
Les rapports d’entreprise MBAM ne sont pas mis à jour
MBAM ne parvient pas à s’approprier le TPM
Échec de l’installation de MBAM si SSRS n’est pas configuré correctement
Certificats et infrastructure à clé publique (PKI)
« Erreur Http 500.0 » lors de l’obtention du mot de passe de défi d’inscription NDES
Ajouter SAN au certificat LDAP sécurisé
Approbation requise pour les renouvellements de certificats
L’autorité de certification ne publie pas de certificats dans un domaine approuvé
Impossible de demander un certificat à partir de pages d’inscription web
Impossible de demander un certificat à l’aide de l’inscription web
La commande Certutil -view ne retourne pas de certificats émis
Les ordinateurs clients ne peuvent pas chiffrer un fichier dans un domaine
Les clients ne peuvent pas s’authentifier auprès d’un serveur
Chiffrement 32 8 événements signalés en continu
L’ID d’événement 4107 ou l’ID d’événement 11 est journalisé
Comment désactiver l’autorité de certification d’entreprise Windows et supprimer les
objets associés
Comment développer la limite maximale de taille d’extension à AD CS
Comment importer des autorités de certification tierces dans le magasin Enterprise
NTAuth
Comment installer des certificats importés sur un serveur web
KDC_ERR_C_PRINCIPAL_UNKNOWN dans la requête S4U2Self
Suppression de la stratégie commune fédérale des États-Unis du magasin racine
approuvé Microsoft
Les certificats de serveur Bureau à distance sont renouvelés deux fois par jour
Échec du renouvellement du certificat de l’Agent d’inscription
Configuration requise pour les certificats de contrôleur de domaine provenant d’une
autorité de certification tierce
Limiter les algorithmes et protocoles de chiffrement
Le certificat d’autorité de certification racine n’apparaît pas
Échec de la validation du certificat de sécurité
Modèles de certificats remplacés et impact sur le magasin AD de l’utilisateur
Prise en charge des algorithmes de chiffrement Suite B
Utiliser et résoudre les problèmes liés à la fonction CryptAcquireContext
Utiliser Cipher.exe pour remplacer les données supprimées
Approbations de domaine et de forêt
Erreur « Le serveur n’est pas opérationnel » lors de l’ajout d’un utilisateur de
domaine approuvé
Impossible de configurer une approbation entre un domaine Windows et un
domaine basé sur AD
Les noms de forêts qui se chevauchent provoquent des problèmes
Impossible de résoudre l’identificateur de sécurité
Les domaines approuvés n’apparaissent pas
Les utilisateurs et les groupes ne peuvent pas être ajoutés à la forêt approuvée
Authentification Kerberos
Échec de l’authentification sur les serveurs NTLM et Kerberos
La délégation contrainte pour CIFS échoue avec ACCESS_DENIED
Erreur KDC de l’ID d’événement 27 sur les contrôleurs de domaine
Comment désactiver l’autre nom de l’objet pour le mappage UPN
Comment forcer Kerberos à utiliser TCP au lieu d’UDP
Événement KDC 16 ou 27 si DES pour Kerberos est désactivé
Le service KDC sur un rodc ne peut pas démarrer et génère l’erreur 1450
L’authentification Kerberos échoue lorsqu’un utilisateur appartient à de nombreux
groupes
Le SPN Kerberos est sur un compte incorrect
Erreur etype Kerberos non prise en charge
KRB_AP_ERR_MODIFIED erreur sur le client Kerberos
Échec de la journalisation sur un compte d’utilisateur
Clés de Registre sur le protocole Kerberos et le KDC
La compression SID de ressource provoque des problèmes d’autorisation
Échec de l’authentification unique avec pré-ouverture de session lors de l’ouverture
de session de l’utilisateur
Échec des demandes TGS pour le compte krbtgt
L’Assistant Inscription d’empreintes digitales ne s’exécute pas
Impossible de se connecter à un domaine
Authentification héritée (NTLM)
L’événement d’audit affiche le package d’authentification en tant que NTLMv1
Auditer l’utilisation de NTLMv1 sur un contrôleur de domaine
Échec de l’authentification des membres de domaine
Erreur lors de la connexion à un site Web
Comment désactiver les modifications automatiques du mot de passe du compte de
machine
Comment empêcher Windows de stocker un hachage LM du mot de passe
Exemples et algorithmes de validation d’accès réseau
Un nouveau paramètre modifie l’authentification réseau NTLM
Authentification utilisateur NTLM
Réglage des performances pour l’authentification NTLM
Les mises à jour Windows ajoutent de nouvelles protections d’authentification
directe NTLM pour CVE-2022-21857
Autorisations, contrôle d’accès et audit
Les fichiers journaux .bak sont supprimés et perdus
Impossible de copier des fichiers du lecteur mappé vers le répertoire local
Autorisations par défaut pour les dossiers MachineKeys
N’avez pas l’autorisation d’accéder au dossier
Erreur 1079 lorsque les services ne démarrent pas
Évaluer les autorisations effectives pour les ressources distantes
Accorder l’autorisation « Réplication des modifications d’annuaire »
Accorder aux utilisateurs les droits de gestion des services
Comment désactiver le contrôle de compte d’utilisateur
Comment activer l’audit des objets AD
Les autorisations héritées ne sont pas automatiquement mises à jour
Marquer un attribut comme confidentiel
Nombre maximal d’entrées de contrôle d’accès
SeImpersonatePrivilege et SeCreateGlobalPrivilege
Les paramètres d’audit de sécurité ne sont pas appliqués lorsque vous déployez une
stratégie basée sur un domaine
Les SID ne sont pas résolus en noms conviviaux
Contrôle de compte d’utilisateur et restrictions à distance
nous ne pouvons pas accéder au journal de sécurité
Problèmes de canal sécurisé
Un ordinateur ne peut pas identifier le réseau
Configurer la clé prépartagée pour utiliser L2TP
Déployer un ordre de suite de chiffrement personnalisé
Réinitialiser le mot de passe du contrôleur de domaine avec Netdom.exe
Problèmes de canal sécurisé détectés
Problèmes de communication SSL/TLS après l’installation d’une mise à jour
Modèles de sécurité
Appliquer des modèles de sécurité prédéfinis
Ouverture de session par carte à puce
Activation de l’ouverture de session de carte à puce
Faq sur la fin du support Windows Server (EoS)
Fin de la prise en charge de Windows Server 2008 et Windows Server 2008 R2
Utilitaires de résolution des problèmes Windows
Présentation de l’ensemble d’outils TroubleShootingScript (TSSv2)
Documentation Active Directory
22/09/2022 • 2 minutes to read
Les rubriques de cette section fournissent des solutions et des guides de scénario pour vous aider à résoudre les
problèmes liés à Active Directory et à résoudre eux-mêmes ces problèmes. Les rubriques sont divisées en sous-
catégories. Parcourez le contenu ou utilisez la fonctionnalité de recherche pour rechercher du contenu pertinent.
Sous-catégories Active Directory

Sauvegarde, restauration ou récupération d’urgence Active Directory
Services de certificat Active Directory
Problèmes de base de données Active Directory et échecs de démarrage du contrôleur de domaine
Mises à jour au niveau fonctionnel du domaine ou de la forêt Active Directory
Services AD FS (Active Directory Federation Services)
Active Directory FSMO
Active Directory Lightweight Directory Services (AD LDS) et ADAM (Active Directory Application Mode)
Active Directory Migration Tool (ADMT)
Réplication Active Directory
Topologie Active Directory (sites, sous-réseaux et objets de connexion)
DCPromo et l’installation des contrôleurs de domaine
Évolutivité ou performances du contrôleur de domaine (y compris LDAP)
Problèmes de jointeurs de domaine
Configuration et interopérabilité LDAP
Mise à jour du schéma : problèmes connus, meilleures pratiques, révision de flux de travail
Échec ou conflit de mise à jour du schéma
Protocole TLS (Transport Layer Security)
Gestion des utilisateurs, des ordinateurs, des groupes et des objets
Contrôleur de domaine virtualisé (erreurs et questions)
Windows Service de temps
Le contrôleur de domaine ne démarre pas, une
erreur c00002e2 se produit ou l’option « Choisir une
option » s’affiche.
Cet article permet de corriger l’erreur c00002e2 ou « Choisir une option » lorsque le contrôleur de domaine ne
démarre pas.
S’applique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro de la ko d’origine : 2737463
Symptômes
Un contrôleur de domaine ne démarre pas ou n’affiche pas l’écran d’accueil. Après avoir redémarré le contrôleur
de domaine et suivi le processus de démarrage, vous remarquez les symptômes suivants, en fonction de votre
système d’exploitation.
Windows Server 2008 R2 ou Windows Server 2008
1. Au démarrage, le serveur subit une erreur d’arrêt et affiche brièvement le message d’erreur suivant :
STOP : les services d’annuaire c00002e2 n’ont pas pu démarrer en raison de l’erreur suivante :
La procédure spécifiée est in trouver
État de l’erreur : 0xc000007a.
2. Le serveur bascule ensuite vers le menu de démarrage pour la récupération ou pour un démarrage
normal.
Windows Server 2012 versions ultérieures
Au démarrage, le serveur bascule vers le menu Choisir une option qui permet de continuer ou de résoudre les
problèmes.
Cause
Ce problème se produit car le rôle Services de domaine Active Directory a été supprimé d’un contrôleur de
domaine sans le rétrograder au premier abord. L’utilisation Dism.exe, Pkgmgr.exe ou Ocsetup.exe pour
supprimer le rôle DirectoryServices-DomainController réussit, mais ces outils de maintenance ne valident pas si
l’ordinateur est un contrôleur de domaine.
Résolution
NOTE
Ces étapes supposent que vous avez d’autres contrôleurs de domaine actifs et que vous souhaitez uniquement supprimer
les services de domaine Active Directory de ce serveur. Si vous n’avez pas d’autres contrôleurs de domaine qui
fonctionnent et qu’il s’agit du seul contrôleur de domaine dans le domaine, vous devez restaurer une sauvegarde d’état
système antérieure.
Windows Server 2008 R2 ou Windows Server 2008
1. Redémarrez le serveur pendant que vous maintenez shift+F8.
2. Sélectionnez le mode de réparation des services d’annuaire (DSRM), puis connectez-vous à l’aide du
compte DSRM.
3. Vérifier que le rôle a été supprimé. Par exemple, pour le faire sur Windows Server 2008 R2, utilisez la
commande suivante :
dism.exe /online /get-features
4. Ajoutez DirectoryServices-DomainController rôle de serveur au serveur. Par exemple, pour le faire sur
Windows Server 2008 R2, utilisez la commande suivante :
dism.exe /online /enable-feature /featurename:DirectoryServices-DomainController
5. Redémarrez et sélectionnez de nouveau le mode de restauration des services d’annuaire.

6. Appliquez un paramètre /forceremoval pour supprimer les services de domaine Active Directory du
contrôleur de domaine. Pour ce faire, exécutez la commande suivante :
dcpromo.exe /forceremoval
7. Pour supprimer les métadonnées du contrôleur de domaine, utilisez ntdsutil.exe ou l’outil dsa.msc.
Windows Server 2012 versions ultérieures
1. Dans le menu Choisir une option, sélectionnez Résoudre les problèmes, cliquez sur Démarrer
Paramètres, puis cliquez sur Redémarrer.
2. Sélectionnez le mode de réparation des services d’annuaire (DSRM), puis connectez-vous à l’aide du
mot de passe DSRM.
3. Vérifier que le rôle a été supprimé. Pour ce faire, utilisez la commande suivante :
dism.exe /online /get-features
4. Ajoutez DirectoryServices-DomainController rôle de serveur au serveur. Pour ce faire, utilisez la

commande suivante :
dism.exe /online /enable-feature /featurename:DirectoryServices-DomainController
5. Redémarrez, sélectionnez de nouveau le mode de restauration des services d’annuaire et connectez-

vous à l’aide du compte DSRM.
6. Utilisez le Gestionnaire de serveur ou Windows PowerShell et appliquez un paramètre -ForceRemoval
pour supprimer les services de domaine Active Directory du contrôleur de domaine. Pour ce faire,
exécutez la commande suivante :
Uninstall-AddsDomaincontroller -ForceRemoval
7. Pour supprimer les métadonnées du contrôleur de domaine, utilisez ntdsutil.exe ou l’outil dsa.msc.
Informations supplémentaires
Utilisez toujours le Gestionnaire de serveur ou le module Windows PowerShell ServerManager pour supprimer
les binaires du rôle Services de domaine Active Directory. Ces outils valident si un serveur est un contrôleur de
domaine actif et ne vous permet pas de supprimer les fichiers critiques.
Pour plus d’informations sur la suppression des métadonnées du contrôleur de domaine, voir le site web
Microsoft TechNet suivant :
Nettoyer les métadonnées du serveur
S’il s’agit du seul domaine serveur dans le domaine, ne supprimez pas les services de domaine Active Directory
du serveur. Restituer à la place son état système à partir de la sauvegarde la plus récente.
Un contrôleur Windows server enregistre
l’événement Directory Services 2095 lorsqu’il
rencontre une rollback USN
Cet article explique comment détecter et récupérer si un contrôleur de domaine Windows Server est
incorrectement rétabli à l’aide d’une installation basée sur une image du système d’exploitation.
NOTE
Cet article est destiné uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous
recherchez de l’aide sur un problème, demandez à l’Community Microsoft.
Résumé
Cet article décrit un échec de réplication Active Directory silencieux provoqué par une mise à jour de numéro de
séquence (USN). Une restauration USN se produit lorsqu’une ancienne version d’une base de données Active
Directory est restaurée ou passée de manière incorrecte sur place.
Lorsqu’une récupération usn se produit, les modifications apportées aux objets et aux attributs qui se
produisent sur un contrôleur de domaine ne sont pas répliquées sur d’autres contrôleurs de domaine dans la
forêt. Étant donné que les partenaires de réplication pensent avoir une copie à jour de la base de données Active
Directory, les outils de surveillance et de dépannage tels que Repadmin.exe ne signalent aucune erreur de
réplication.
Les contrôleurs de domaine enregistrent l’événement Directory Services 2095 dans le journal des événements
des services d’annuaire lorsqu’ils détectent une rollback USN. Le texte du message d’événement dirige les
administrateurs vers cet article pour en savoir plus sur les options de récupération.
Exemple d’entrée de journal de l’événement 2095
Log Name: <Service name> Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: <DateTime>
Event ID: 2095
Task Category: Replication
Level: Error
Keywords: Classic
User: <USER NAME>
Computer: SERVER.contoso.com
Description:
During an Active Directory Domain Services replication request, the local domain controller (DC) identified
a remote DC which has received replication data from the local DC using already-acknowledged USN tracking
numbers.
Because the remote DC believes it is has a more up-to-date Active Directory Domain Services database than
the local DC, the remote DC will not apply future changes to its copy of the Active Directory Domain
Services database or replicate them to its direct and transitive replication partners that originate from
this local DC.
If not resolved immediately, this scenario will result in inconsistencies in the Active Directory Domain
Services databases of this source DC and one or more direct and transitive replication partners.
Specifically the consistency of users, computers and trust relationships, their passwords, security groups,
security group memberships and other Active Directory Domain Services configuration data may vary, affecting
the ability to log on, find objects of interest and perform other critical operations.
To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or

contact your Microsoft product support.
The most probable cause of this situation is the improper restore of Active Directory Domain Services on the
local domain controller.
User Actions:
If this situation occurred because of an improper or unintended restore, forcibly demote the DC.
Les rubriques suivantes abordent la façon de détecter et de récupérer à partir d’une rollback USN dans un
contrôleur de domaine Windows server.
Méthodes prise en charge pour la back up Active Directory sur les

contrôleurs de domaine qui exécutent Windows Server 2012 versions
ultérieures
Windows Server 2012 prise en charge de Hyper-Visor ID de génération (GenID). Cela permet à l’invité virtuel de
détecter les volumes de disque qui ont un nouvel ID et de répondre au nouveau GenID. Dans Active Directory,
les services d’annuaire réagissent comme si le contrôleur de domaine avait été restauré à partir d’une
sauvegarde. Il génère ensuite un nouvel ID d’appel. En utilisant le nouvel ID d’appel, l’instance de base de
données peut entrer de nouveau en toute sécurité la réplication dans la forêt.
Il s’agit de l’un des scénarios abordés dans le déploiement et la configuration du contrôleur de domaine
virtualisé.
Méthodes prise en charge pour la back up Active Directory sur les

contrôleurs de domaine qui exécutent Windows Server 2003 ou
versions ultérieures de Windows Server
Au cours du cycle de vie d’un contrôleur de domaine, vous de devez restaurer ou « restaurer » le contenu de la
base de données Active Directory à un point connu dans le temps. Vous pouvez également être appelé à
retourner les éléments du système d’exploitation hôte d’un contrôleur de domaine, y compris Active Directory, à
un point connu.
Vous pouvez utiliser les méthodes suivantes pour récupérer le contenu d’Active Directory :
Utilisez un utilitaire de sauvegarde et de restauration pris en charge par Active Directory qui utilise les
API fournies par Microsoft et testées par Microsoft. Ces API restaurent une sauvegarde de l’état du
système sans faire autorité ou faisant autorité. La sauvegarde qui est restaurée doit provenir de la même
installation de système d’exploitation et du même ordinateur physique ou virtuel en cours de
restauration.
Utilisez un utilitaire de sauvegarde et de restauration pris en charge par Active Directory qui utilise les
API du service Microsoft Volume Shadow Copy. Ces API remontent et restaurent l’état du système du
contrôleur de domaine. Le service Volume Shadow Copy prend en charge la création de copies de
l’ombre à un point dans le temps d’un ou de plusieurs volumes sur des ordinateurs exécutant Windows
Server 2003, Windows Server 2008 ou Windows Server 2008 R2. Les clichés instantanés à un point dans
le temps sont également appelés captures instantanées. Pour plus d’informations, recherchez « Volume
Shadow Copy Service » dans le Support Microsoft.
Restituer l’état du système. Évaluez si des sauvegardes d’état système valides existent pour ce contrôleur
de domaine. Si une sauvegarde d’état système valide a été réalisée avant la restauration incorrecte du
contrôleur de domaine restauré et si la sauvegarde contient des modifications récentes qui ont été
apportées au contrôleur de domaine, restituer l’état du système à partir de la sauvegarde la plus récente.
Comportement classique qui se produit lors de la restauration d’une

sauvegarde de l’état du système active Directory
Windows Les contrôleurs de domaine serveur utilisent des noms principaux de service avec les ID d’appel pour
suivre les mises à jour qui doivent être répliquées entre les partenaires de réplication dans une forêt Active
Directory.
Les contrôleurs de domaine source utilisent des usns pour déterminer les modifications qui ont déjà été reçues
par le contrôleur de domaine de destination qui demande des modifications. Les contrôleurs de domaine de
destination utilisent des noms de domaine unis pour déterminer les modifications qui doivent être demandées
aux contrôleurs de domaine source.
L’ID d’appel identifie la version ou l’insération de la base de données Active Directory qui s’exécute sur un
contrôleur de domaine donné.
Lorsque Active Directory est restauré sur un contrôleur de domaine à l’aide des API et des méthodes que
Microsoft a conçues et testées, l’ID d’appel est correctement réinitialisé sur le contrôleur de domaine restauré.
les contrôleurs de domaine de la forêt reçoivent une notification de réinitialisation de l’appel. Par conséquent, ils
ajustent leurs valeurs de filigrane élevées en conséquence.
Logiciels et méthodologies qui entraînent des mises à jour usn

Lorsque les environnements, programmes ou sous-systèmes suivants sont utilisés, les administrateurs peuvent
contourner les vérifications et validations que Microsoft a conçues pour se produire lors de la restauration de
l’état du système du contrôleur de domaine :
Démarrage d’un contrôleur de domaine Active Directory dont le fichier de base de données Active
Directory a été restauré (copié) en place à l’aide d’un programme d’imagerie tel que Celui-ci.
Démarrage d’une image de disque dur virtuel précédemment enregistrée d’un contrôleur de domaine. Le
scénario suivant peut provoquer une récupération usn :
1. Promouvoir un contrôleur de domaine dans un environnement d’hébergement virtuel.
2. Créez une capture instantanée ou une autre version de l’environnement d’hébergement virtuel.
3. Laissez le contrôleur de domaine poursuivre la réplication entrante et la réplication sortante.
4. Démarrez le fichier image du contrôleur de domaine que vous avez créé à l’étape 2.
Microsoft Virtual PC 2004, Microsoft Virtual Server 2005 et EMC VMWARE sont des exemples
d’environnements d’hébergement virtualisés à l’origine de ce scénario. D’autres environnements
d’hébergement virtualisés peuvent également provoquer ce scénario.
Pour plus d’informations sur les conditions de prise en charge des contrôleurs de domaine dans les
environnements d’hébergement virtuel, voir Éléments à prendre en compte lorsque vous hébergez des
contrôleurs de domaine Active Directory dans des environnements d’hébergement virtuels.
Démarrage d’un contrôleur de domaine Active Directory situé sur un volume sur lequel le sous-système
de disque se charge à l’aide d’images enregistrées précédemment du système d’exploitation sans
nécessiter une restauration de l’état du système d’Active Directory.
Scénario A : démarrage de plusieurs copies d’Active Directory situées sur un sous-système de
disque qui stocke plusieurs versions d’un volume
1. Promouvoir un contrôleur de domaine. Recherchez le fichier Ntds.dit sur un sous-système de
disque qui peut stocker plusieurs versions du volume qui héberge le fichier Ntds.dit.
2. Utilisez le sous-système de disque pour créer un instantané du volume qui héberge le fichier
Ntds.dit pour le contrôleur de domaine.
3. Continuez à laisser le contrôleur de domaine charger Active Directory à partir du volume que
vous avez créé à l’étape 1.
4. Démarrez le contrôleur de domaine enregistré par la base de données Active Directory à
l’étape 2.
Scénario B : démarrage d’Active Directory à partir d’autres lecteurs dans un miroir rompu
1. Promouvoir un contrôleur de domaine. Recherchez le fichier Ntds.dit sur un lecteur en miroir.
2. Cassez le miroir.
3. Continuez la réplication entrante et la réplication sortante à l’aide du fichier Ntds.dit sur le
premier lecteur du miroir.
4. Démarrez le contrôleur de domaine à l’aide du fichier Ntds.dit sur le deuxième lecteur dans le
miroir.
Même si ce n’est pas prévu, chacun de ces scénarios peut entraîner le retour des contrôleurs de domaine à une
version antérieure de la base de données Active Directory par des méthodes non pris en service. La seule façon
prise en charge de restaurer le contenu d’Active Directory ou l’état local d’un contrôleur de domaine Active
Directory consiste à utiliser un utilitaire de sauvegarde et de restauration pris en charge par Active Directory
pour restaurer une sauvegarde d’état système provenant de la même installation du système d’exploitation et
du même ordinateur physique ou virtuel en cours de restauration.
Microsoft ne prend en charge aucun autre processus qui prend en charge une capture instantanée des éléments
de l’état du système d’un contrôleur de domaine Active Directory et copie les éléments de cet état dans une
image de système d’exploitation. À moins qu’un administrateur n’intervienne, ces processus entraînent une
récupération usn. Cette restauration usn entraîne l’incohérente des objets incohérents dans leurs bases de
données Active Directory pour les partenaires de réplication directe et transitive d’un contrôleur de domaine
mal restauré.
Les effets d’une rollback USN

Lorsque des modifications usn sont effectuées, les modifications apportées aux objets et aux attributs ne sont
pas répliquées par les contrôleurs de domaine de destination qui ont déjà vu le nom d’usn.
Étant donné que ces contrôleurs de domaine de destination pensent être à jour, aucune erreur de réplication
n’est signalée dans les journaux des événements du service d’annuaire ou par les outils de surveillance et de
diagnostic.
La rollback USN peut affecter la réplication d’un objet ou d’un attribut dans n’importe quelle partition. L’effet
secondaire le plus fréquemment observé est que les comptes d’utilisateur et les comptes d’ordinateur créés sur
le contrôleur de domaine de récupération n’existent pas sur un ou plusieurs partenaires de réplication. Ou bien,
les mises à jour de mot de passe provenant du contrôleur de domaine de récupération n’existent pas sur les
partenaires de réplication.
Les étapes suivantes montrent la séquence d’événements qui peuvent provoquer une récupération usn. Une
restauration USN se produit lorsque l’état du système du contrôleur de domaine est restauré dans le temps à
l’aide d’une restauration d’état système non pris en service.
1. Un administrateur promeut trois contrôleurs de domaine dans un domaine. (Dans cet exemple, les
contrôleurs de domaine sont DC1, DC2 et DC2, et le domaine est Contoso.com.) DC1 et DC2 sont des
partenaires de réplication directe. DC2 et DC3 sont également des partenaires de réplication directe. DC1
et DC3 ne sont pas des partenaires de réplication directs, mais reçoivent les mises à jour provenant de
manière transitive via DC2.
2. Un administrateur crée 10 comptes d’utilisateur qui correspondent aux usns 1 à 10 sur DC1. Tous ces
comptes sont répliqués vers DC2 et DC3.
3. Une image de disque d’un système d’exploitation est capturée sur DC1. Cette image a un enregistrement
des objets qui correspondent aux usns locaux 1 à 10 sur DC1.
4. Les modifications suivantes sont apportées dans Active Directory :
Les mots de passe des 10 comptes d’utilisateur créés à l’étape 2 sont réinitialisés sur DC1. Ces mots
de passe correspondent aux usns 11 à 20. Les 10 mots de passe mis à jour sont répliqués vers DC2 et
DC3.
10 nouveaux comptes d’utilisateur correspondant aux usns 21 à 30 sont créés sur DC1. Ces 10
comptes d’utilisateurs sont répliqués sur DC2 et DC3.
10 nouveaux comptes d’ordinateur correspondant aux usns 31 à 40 sont créés sur DC1. Ces 10
comptes d’ordinateurs sont répliqués vers DC2 et DC3.
10 nouveaux groupes de sécurité qui correspondent aux usns 41 à 50 sont créés sur DC1. Ces 10
groupes de sécurité se répliquent sur DC2 et DC3.
5. DC1 subit une défaillance matérielle ou logicielle. L’administrateur utilise un utilitaire d’imagerie sur
disque pour copier l’image du système d’exploitation créée à l’étape 3. DC1 commence maintenant par
une base de données Active Directory qui a connaissance des usns 1 à 10.
Étant donné que l’image du système d’exploitation a été copiée sur place et qu’une méthode prise en
charge de restauration de l’état du système n’a pas été utilisée, DC1 continue d’utiliser le même ID
d’appel que celui qui a créé la copie initiale de la base de données et toutes les modifications jusqu’à USN
50. DC2 et DC3 conservent également le même ID d’appel pour DC1, ainsi qu’un vecteur à jour de USN
50 pour DC1. (Un vecteur à jour est l’état actuel des dernières mises à jour d’origine qui se produisent sur
tous les contrôleurs de domaine pour une partition d’annuaire donnée.)
À moins qu’un administrateur n’intervienne, DC2 et DC3 ne répliquent pas les modifications entrantes
correspondant au usn usn local 11 à 50 qui proviennent de DC1. En outre, en fonction de l’ID d’appel
utilisé par DC2, DC1 a déjà connaissance des modifications qui correspondent à USN 11 à 50. Par
conséquent, DC2 n’envoie pas ces modifications. Étant donné que les modifications apportées à l’étape 4
n’existent pas sur DC1, les demandes d’accès échouent avec une erreur « Accès refusé ». Cette erreur se
produit soit parce que les mots de passe ne correspondent pas, soit parce que le compte n’existe pas
lorsque les comptes les plus nouveaux s’authentifier de manière aléatoire avec DC1.
6. Les administrateurs qui surveillent l’état de réplication dans la forêt notent les situations suivantes :
L’outil en ligne de commande signale que la réplication Active Directory double entre DC1 et DC2
et entre DC2 et DC3 se produit sans Repadmin /showreps erreur. Cette situation rend toute
incohérence de réplication difficile à détecter.
Les événements de réplication dans les journaux des événements du service d’annuaire des
contrôleurs de domaine qui exécutent Windows Server n’indiquent aucun échec de réplication
dans les journaux des événements du service d’annuaire. Cette situation rend toute incohérence de
réplication difficile à détecter.
Les utilisateurs et ordinateurs Active Directory ou l’outil d’administration Active Directory (Ldp.exe)
indiquent un nombre différent d’objets et de métadonnées d’objet lorsque les partitions d’annuaire
de domaine sur DC2 et DC3 sont comparées à la partition sur DC1. La différence est l’ensemble
des modifications qui m’indiquent les modifications usn 11 à 50 à l’étape 4.
NOTE
Dans cet exemple, le nombre d’objets différent s’applique aux comptes d’utilisateurs, aux comptes
d’ordinateur et aux groupes de sécurité. Les différentes métadonnées d’objet représentent les différents
mots de passe de compte d’utilisateur.
Les demandes d’authentification des 10 comptes d’utilisateurs créés à l’étape 2 génèrent parfois
une erreur « Accès refusé » ou « Mot de passe incorrect ». Cette erreur peut se produire parce qu’il
existe une insérialisation de mot de passe entre ces comptes d’utilisateur sur DC1 et les comptes
sur DC2 et DC3. Les comptes d’utilisateurs qui sont face à ce problème correspondent aux
comptes d’utilisateur qui ont été créés à l’étape 4. Les comptes d’utilisateur et les réinitialisations
de mot de passe à l’étape 4 n’ont pas été répliqués sur d’autres contrôleurs de domaine du
domaine.
7. DC2 et DC3 commencent à répliquer les mises à jour d’origine entrantes qui correspondent aux numéros
USN supérieurs à 50 à partir de DC1. Cette réplication se déroule normalement sans intervention
administrative, car le seuil de vecteur de date à jour précédemment enregistré( USN 50) a été dépassé.
(USN 50 était le réseau usn vectoriel à jour enregistré pour DC1 sur DC2 et DC3 avant la mise hors
connexion et la restauration de DC1.) Toutefois, les nouvelles modifications qui correspondent aux usns
11 à 50 sur dc1 d’origine après la restauration non pris en service ne seront jamais répliquées vers DC2,
DC3 ou leurs partenaires de réplication transitifs.
Bien que les symptômes mentionnés à l’étape 6 représentent une partie de l’effet qu’une rollback USN peut
avoir sur les comptes d’utilisateur et d’ordinateur, une rollback USN peut empêcher tout type d’objet dans
n’importe quelle partition Active Directory de se répliquer. Ces types d’objets sont les suivants :
Topologie et planification de réplication Active Directory
L’existence de contrôleurs de domaine dans la forêt et les rôles que ces contrôleurs de domaine
détiennent
NOTE
Ces rôles incluent le catalogue global, les allocations d’identificateur relatif (RID) et les rôles principaux des
opérations. (Les rôles maîtres d’opérations sont également appelés opérations maîtres unique flexibles ou FSMO.)
L’existence de partitions de domaine et d’application dans la forêt

L’existence de groupes de sécurité et leur appartenance actuelle au groupe
Enregistrement DNS dans les zones DNS intégrées à Active Directory
La taille du trous USN peut représenter des centaines, des milliers, voire des dizaines de milliers de
modifications apportées aux utilisateurs, ordinateurs, trusts, mots de passe et groupes de sécurité. (Le trous
USN est défini par la différence entre le numéro USN le plus élevé qui existait lors de la sauvegarde de l’état
système restauré et le nombre de modifications d’origine qui ont été créées sur le contrôleur de domaine
restauré avant qu’elle ne soit mise hors connexion.)
Détecter une rollback USN sur un contrôleur de domaine Windows

Server
Étant donné qu’une annulation usn est difficile à détecter, un contrôleur de domaine Windows Server 2003 SP1
ou version ultérieure enregistre l’événement 2095 lorsqu’un contrôleur de domaine source envoie un numéro
usn précédemment reconnu à un contrôleur de domaine de destination sans modification correspondante de
l’ID d’appel.
Pour empêcher la création de mises à jour uniques d’origine d’Active Directory sur le contrôleur de domaine
restauré de manière incorrecte, le service Net Logon est suspendu. Lorsque le service Net Logon est suspendu,
les comptes d’utilisateur et d’ordinateur ne peuvent pas modifier le mot de passe sur un contrôleur de domaine
qui ne répliquera pas ces modifications sortantes. De même, les outils d’administration Active Directory
privilégient un contrôleur de domaine sain lorsqu’ils met à jour des objets dans Active Directory.
Sur un contrôleur de domaine, les messages d’événement qui ressemblent à ce qui suit sont enregistrés si les
conditions suivantes sont vraies :
Un contrôleur de domaine source envoie un numéro usn reconnu précédemment à un contrôleur de
domaine de destination.
Il n’existe aucune modification correspondante dans l’ID d’appel.
Ces événements peuvent être capturés dans le journal des événements du service d’annuaire. Toutefois, ils
peuvent être remplacés avant d’être observés par un administrateur.
Vous pouvez suspecter qu’une récupération usn s’est produite. Toutefois, vous ne voyez pas les événements de
mise en corrélation dans le journal des événements du service d’annuaire. Dans ce scénario, recherchez l’entrée
de Registre Dsa Not Writable. Cette entrée fournit des preuves légales qu’une rollback USN a eu lieu.
Sous-clé du Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Entrée de Registre : Dsa not Writable
Valeur : 0x4
La suppression ou la modification manuelle de la valeur d’entrée de Registre Dsa Not Writable place le
contrôleur de domaine de récupération dans un état définitivement non pris en main. Par conséquent, ces
modifications ne sont pas pris en charge. Plus précisément, la modification de la valeur supprime le
comportement de mise en quarantaine ajouté par le code de détection de la suppression usn. Les partitions
Active Directory sur le contrôleur de domaine de récupération seront définitivement incohérentes avec les
partenaires de réplication directe et transitive dans la même forêt Active Directory.
Récupérer à partir d’une rollback USN

Il existe trois approches de récupération à partir d’une récupération USN.
Supprimez le contrôleur de domaine du domaine. Pour cela, procédez comme suit :
1. Supprimez Active Directory du contrôleur de domaine pour le forcer à être un serveur autonome.
Pour plus d’informations, voir Les contrôleurs de domaine ne rétrogradent pas normalement
lorsque vous utilisez l’Assistant Installation d’Active Directory pour forcer la rétrogradation.
2. Fermez le serveur rétrogradé.
3. Sur un contrôleur de domaine sain, nettoyez les métadonnées du contrôleur de domaine
rétrogradé. Pour plus d’informations, voir Nettoyer les métadonnéesdu serveur du contrôleur de
domaine Active Directory.
4. Si le contrôleur de domaine incorrectement restauré héberge des rôles maîtres d’opérations,
transférez ces rôles à un contrôleur de domaine sain. Pour plus d’informations, voir Transférer ou
saisir des rôles FSMO dans les services de domaine Active Directory.
5. Redémarrez le serveur rétrogradé.
6. Si nécessaire, installez à nouveau Active Directory sur le serveur autonome.
7. Si le contrôleur de domaine était auparavant un catalogue global, configurez le contrôleur de
domaine en tant que catalogue global. Pour plus d’informations, voir Comment créer ou déplacer
un catalogue global.
8. Si le contrôleur de domaine hébergeait précédemment des rôles maîtres d’opérations, transférez
les rôles maîtres d’opérations au contrôleur de domaine. Pour plus d’informations, voir Transférer
ou saisir des rôles FSMO dans les services de domaine Active Directory.
Restituer l’état système d’une bonne sauvegarde.
Évaluez si des sauvegardes d’état système valides existent pour ce contrôleur de domaine. Si une
sauvegarde d’état système valide a été réalisée avant la restauration incorrecte du contrôleur de domaine
restauré et que la sauvegarde contient des modifications récentes qui ont été apportées au contrôleur de
domaine, restituer l’état du système à partir de la sauvegarde la plus récente.
Restituer l’état du système sans sauvegarde de l’état du système.
Vous pouvez utiliser la capture instantanée comme source d’une sauvegarde. Vous pouvez également
définir la base de données pour qu’elle se donne un nouvel ID d’appel à l’aide de la procédure de la
section Pour restaurer une version précédente d’un disque dur virtuel de contrôleur de domaine virtuel
sans sauvegarde des données d’état système de l’exécution des contrôleurs de domaine dans Hyper-V.
Références
Éléments à prendre en compte lorsque vous hébergez des contrôleurs de domaine Active Directory dans
des environnements d’hébergement virtuels
Architecture du contrôleur de domaine virtualisé
L’événement de réplication NTDS 2089 est
journalisé si Windows Server 2003 SP1 et les
contrôleurs de domaine ultérieurs ne sont pas
enregistrés dans une période donnée
Cet article décrit le problème dans lequel un nouveau message d’erreur d’événement est consigné si vous ne
sauvegardez pas un contrôleur de domaine basé sur Windows Server 2003 Service Pack 1 (SP1) dans une
période donnée appelée intervalle de latence de sauvegarde.
S’applique à : Window Server 2003
Introduction
Lorsque vous back up a domain controller that is running Microsoft Windows Server 2003 Service Pack 1 (SP1),
a new event error message is logged for each writable domain or application partition that the domain
controller hosts. Cela est vrai si la partition n’est pas backed dans une période donnée. La période est appelée
intervalle de latence de sauvegarde. Vous pouvez définir une valeur de Registre pour spécifier cet intervalle en
jours.
Nouveau comportement dans Windows Server 2003 SP1
L’attribut signature DSA est modifié chaque fois qu’une sauvegarde de l’état du système est réalisée. Le système
d’exploitation surveille cet attribut. Un message d’erreur d’événement est consigné lorsque les critères
d’intervalle de latence de sauvegarde sont satisfaits. Tout Windows contrôleur de domaine basé sur Server 2003
SP1 peut enregistrer l’événement car l’attribut signature DSA est un attribut répliqué.
NOTE
Le nouveau message d’erreur d’événement n’est pas enregistré tant qu’une sauvegarde n’a pas été réalisée sur un
contrôleur de domaine basé sur Windows Server 2003 qui exécute Windows Server 2003 SP1. Seuls Windows contrôleurs
de domaine basés sur Server 2003 SP1 enregistrent ce message d’erreur d’événement.
La période par défaut de l’intervalle de latence de sauvegarde est la moitié de la durée de vie de Tombstone
(TSL) pour la journalisation du message d’erreur d’événement sur le contrôleur de domaine. La liste suivante
montre la différence entre les valeurs TSL par défaut d’une forêt créée sur Windows Server 2003 et d’une forêt
créée sur Windows Server 2003 SP1 :
Windows Server 2003
Par défaut, la valeur TSL dans Windows Server 2003 est de 60 jours. Par conséquent, le message d’erreur
d’événement n’est enregistré que 30 jours après la dernière sauvegarde.
Windows Server 2003 SP1
Par défaut, la valeur TSL dans la nouvelle forêt créée par Windows Server 2003 SP1 est de 180 jours. La valeur
TSL est de 60 jours dans tous les autres cas. Le message d’erreur d’événement dans une forêt avec un TSL de
180 jours n’est enregistré que 90 jours après la dernière sauvegarde.
NOTE
Si vous installez simplement Windows Server 2003 SP1 sur des ordinateurs basés sur Windows Server 2003, cela
n’augmente pas le TSL à 180 jours. La forêt doit être créée sur un serveur sur Windows Server 2003 SP1 est installé au
moment où vous la créez. Pour plus d’informations, cliquez sur le numéro d’article suivant pour afficher l’article dans la
Base de connaissances Microsoft :
216993 durée de vie utile d’une sauvegarde de l’état système d’Active Directory
Stratégie de déploiement
La valeur par défaut de l’intervalle de latence de sauvegarde dans une forêt qui utilise le TSL par défaut est
insuffisante pour avertir correctement les administrateurs que les partitions ne sont pas sauvegardes avec une
fréquence suffisante.
Dans le Registre, les administrateurs peuvent spécifier une valeur pour l’entrée du seuil de latence de
sauvegarde ( jours). Cela fournit une méthode simple pour ajuster le moment où l’ID d’événement 2089 est
enregistré si une sauvegarde n’est pas réalisée pendant une certaine période. Par conséquent, la période reflète
les stratégies de sauvegarde des administrateurs. Ce message d’erreur d’événement sert d’avertissement aux
administrateurs pour leur dire que les contrôleurs de domaine ne sont pas en cours de back up avant
l’expiration du TSL. Ce message d’erreur d’événement est également un événement de suivi utile pour surveiller
des applications telles que Microsoft Operations Manager (MOM).
Nous vous recommandons d’appliquer des sauvegardes d’état système qui incluent chaque partition de forêt,
de domaine et d’application sur au moins deux ordinateurs par jour. Nous vous recommandons également de
configurer cet événement pour qu’il se produise tous les deux jours si aucune sauvegarde n’est réalisée. Les
programmes de sauvegarde tiers peuvent utiliser une méthode qui appelle l’API de sauvegarde qui met à jour
l’attribut. Lorsque ces programmes utilisent cette méthode, l’attribut signature DSA est mis à jour.
Un message d’erreur de l’ID d’événement 2089 est consigné dans le journal des événements du service
d’annuaire lorsqu’une partition n’est pas enregistrée pendant l’intervalle de latence de sauvegarde. Un seul
message d’erreur d’événement est consigné chaque jour pour chaque partition qu’un contrôleur de domaine
héberge. Le message d’erreur d’événement est similaire à ce qui suit :
Type d'événement : Avertissement

Source de l’événement : réplication NTDS
Catégorie d’événement : ID d’événement de sauvegarde : 2089
Description : cette partition d’annuaire n’a pas été backed depuis au moins le nombre de jours suivants.
Partition d’annuaire :
DC=domainDC=com
« Intervalle de latence de sauvegarde » ( jours) :
30
Il est recommandé de prendre une sauvegarde aussi souvent que possible pour récupérer suite à une perte
accidentelle de données. Toutefois, si vous n’avez pas pris de sauvegarde depuis au moins le nombre de jours «
intervalle de latence de sauvegarde », ce message est consigné tous les jours jusqu’à ce qu’une sauvegarde soit
prise. Vous pouvez sauvegarder n’importe quel réplica qui contient cette partition.
Par défaut, l'« intervalle de latence de sauvegarde » est fixé à la moitié de l’intervalle de durée de vie de
Tombstone. Si vous souhaitez modifier l'« intervalle de latence de sauvegarde » par défaut, vous pouvez le faire
en ajoutant la clé de Registre suivante.
Clé de Registre « Intervalle de latence de sauvegarde » ( jours) :
System\CurrentControlSet\Services\NTDS\Parameters\Backup Latency Threshold (days) .
NOTE
La valeur du seuil de latence de sauvegarde (jours) est une entrée de Registre, mais pas une clé, comme indiqué dans le
message d’erreur d’événement. L’intervalle de latence de sauvegarde est la moitié de la valeur du TSL de la forêt. Lorsque
cette valeur est atteinte, le système d’exploitation enregistre l’ID d’événement 2089 dans le journal des événements du
service d’annuaire. Cet ID d’événement avertit les administrateurs de surveiller les applications et de s’assurer que les
contrôleurs de domaine sont pris en compte avant l’expiration du TSL. Pour définir l’intervalle d’attente du système
d’exploitation avant qu’un ID d’événement 2089 ne soit journalisé, utilisez l’Éditeur du Registre pour définir la valeur de
l’entrée du seuil de latence de sauvegarde (jours). Pour cela, procédez comme suit :
1. Démarrez l’Éditeur du Registre.
2. Recherchez, puis cliquez sur la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
3. Cliquez avec le bouton droit sur Paramètres, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
4. Tapez seuil de latence de sauvegarde (jours), puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur Seuil de latence de sauvegarde ( jours), puis cliquez sur Modifier.
6. Dans la zone de données Valeur, tapez le nombre de jours à utiliser comme seuil, puis cliquez sur OK .
Références
https://blogs.msdn.com/brettsh/archive/2006/02/09/528708.aspx
La restauration d’un contrôleur de domaine peut
provoquer des incohérences entre les contrôleurs de
domaine
Cet article fournit de l’aide pour résoudre un problème dans lequel la restauration d’un contrôleur de domaine
provoque des incohérences entre les contrôleurs de domaine.
S’applique à : Windows Server 2012 R2
Symptômes
La restauration d’un contrôleur de domaine peut provoquer un ID d’événement : 1587, indiquant des
incohérences entre les contrôleurs de domaine. Si cela se produit, certains objets en attente peuvent être
présents sur le contrôleur de domaine restauré. En outre, les nouveaux objets sur le contrôleur de domaine
restauré ne sont pas répliqués.
Cause
Ce problème se produit parce que le contrôleur de domaine affecte un nouvel ID d’appel, mais utilise la marque
high premier plan d’origine.
Solution de contournement
Pour contourner ce problème, rétrograder, puis promouvoir le contrôleur de domaine restauré. Avant de
rétrograder le serveur concerné, forcez une réplication complète du serveur concerné vers un autre contrôleur
de domaine. (La synchronisation complète peut être intensive en ressources pour les domaines plus
importants.) Effectuez la synchronisation complète sur la partition de domaine et sur la partition de
configuration. La ligne suivante illustre la syntaxe de la commande Repadmin que vous utilisez pour effectuer la
synchronisation :
repadmin /sync <Naming Context> <Dest DC> <Source DC GUID> [/force] [/full]
La ligne suivante est un exemple d’utilisation de cette commande :
repadmin /sync DC=domain,DC=root good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force /full
Dans l’exemple de commande :

« DC=domain,DC=root » est le contexte d’attribution de noms de domaine.
« good_DC » est le DC de destination. Il s’agit du bon partenaire qui recevra les mises à jour.
Le GUID DSA est le GUID de réplication du DC restauré. Pour ce faire, Repadmin /showreps exécutez-le sur le
serveur restauré. Le GUID est répertorié en haut sous « GUID d’objet DC ».
Si la synchronisation réussit, vous recevez le message suivant : Synchronisez de 122a5239-36b3-488a-b24c-
971ed0ca8a46 à Good_DC terminé.
Répétez le processus pour le contexte d’attribution de noms de configuration à l’aide d’une commande
semblable à la suivante :
repadmin /sync cn=configuration,DC=domain,DC=root good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force

/full
Le problème n’est pas susceptible d’être résolu une fois que vous avez fait cela. Après cela, installez le correctif
logiciel ou rétrogradez, puis faites la promotion du contrôleur de domaine pour résoudre le problème.
Statut
Microsoft a confirmé qu’il s’agit d’un problème dans les produits Microsoft répertoriés au début de cet article.
Ce problème a été corrigé pour la première fois dans Windows 2000 Service Pack 3.
Lorsque vous restituer un contrôleur de domaine, le nom d’usn le plus élevé est restauré au moment de la
création de la sauvegarde. L’ID d’appel du contrôleur de domaine est retiré et un nouvel ID est attribué.
Lorsqu’un partenaire tente de répliquer la première fois après la restauration, le message suivant est enregistré :
Type d'événement : Informations

Catégorie d’événement : (5)
ID d’événement : 1587
Date : <DateTime>
Heure : <DateTime>
Utilisateur : CONTOSO \ CO-NA-DC-01$
Ordinateur : CO-DC-02
Description :
L’agent de service d’annuaire (DSA) correspondant à objectGuid d0a6a575-9702-4f4e-bf68-bb2a9f875188
a demandé des modifications en commençant par un signet précédant la restauration la plus récente de la
DSA locale à partir d’une sauvegarde sur usn 94727614. Le signet est ajusté comme suit : ID d’appel
précédent : bc546028-fae7-4978-abe0-d294694da32b
Previous Object Update USN: 95853579
Previous Property Update USN: 95853579
Nouvel ID d’appel : ae6286cb-740b-4bb3-ace7-9577efa9dc9f
Nouveau usn de mise à jour d’objet : 94727614
Nouveau usn de mise à jour de propriété : 94727614
Cet événement est typique pour un contrôleur de domaine restauré. En soi, cela n’indique pas un problème. Il
s’agit d’un problème si les objets créés sur le contrôleur de domaine restauré ne sont pas répliqués en mode
silencieux.
Dans le scénario de problème, le usn le plus élevé est revenir en arrière. Toutefois, pendant le signet (ou
réinitialisation du vecteur « à jour », le contrôleur de domaine source fournit la valeur USN la plus élevée qui
était présente avant la restauration. Les objets qui ont des valeurs USNchanged entre la valeur
d’attributCommittedUSN supérieure et inférieure sont jamais pris en compte pour la réplication.
Par exemple : supposons que le contrôleur de domaine 1 possède un usn le plus élevé de 100. Son partenaire de
réplication, contrôleur de domaine 2, a un vecteur « à jour » de 100 pour le contrôleur de domaine 1.
Vous restituer le contrôleur de domaine 1 à partir d’une sauvegarde sur laquelle la valeur usn la plus élevée est
50. Après la réplication suivante avec le contrôleur de domaine 2, le contrôleur de domaine 1 réinitialise le
signet sur 100 (il doit être égal à 50). le contrôleur de domaine 1 provient des modifications 51, 52 et 53.
Lorsque le contrôleur de domaine 2 négocie la réplication, il ne considère jamais les modifications, car il pense
que les modifications ont été apportées jusqu’à 100. le contrôleur de domaine 1 continue d’apporter des
modifications et finit par atteindre 101. La modification 101 est répliquée, mais les modifications 51 à 100 ne le
sont pas.
Dans certains cas, vous pouvez détecter cet état. Utilisez Ldp ou ADSI Edit pour lire l’attributcommittedUSN le
plus élevé actuel sur l’objet rootDSE sur le contrôleur de domaine restauré. Ensuite, comparez-le à la sortie de la
repadmin /showreps /verbose commande sur l’un de ses partenaires. Dans la sortie Repadmin, recherchez la
valeur « USN ###/OU » pour le contrôleur de domaine restauré pour chaque contexte d’appellation. Si la valeur
dans Repadmin est supérieure à l’attributCommittedUSN le plus élevé, le contrôleur de domaine restauré
rencontre le problème.
Si le contrôleur de domaine restauré a fourni suffisamment de mises à jour que son attribut
highestCommittedUSN a atteint ou a dépassé le vecteur « à jour » enregistré sur les autres contrôleurs de
domaine (comme dans l’exemple de cet article), certaines modifications ne seront jamais envisagées pour la
réplication. Toutefois, les nouvelles modifications sont répliquées. Les modifications non répliquées sont
appelées « objets en attente ».
Comment supprimer des domaines orphelins
d’Active Directory
S’applique à : Windows 10, Windows Server 2012 R2

Résumé
En règle générale, lorsque le dernier contrôleur de domaine d’un domaine est rétrogradé, l’administrateur
sélectionne Ce serveur est le dernier contrôleur de domaine dans l’option de domaine dans l’outil DCPromo.
Cette procédure supprime les métadonnées de domaine d’Active Directory. Cet article explique comment
supprimer des métadonnées de domaine d’Active Directory si cette procédure n’est pas utilisée ou si tous les
contrôleurs de domaine sont mis hors connexion mais pas rétrogradés en premier.
Cau t i on
L’administrateur doit vérifier que la réplication s’est produite depuis la rétrogradation du dernier contrôleur de
domaine avant de supprimer manuellement les métadon données de domaine. L’utilisation incorrecte de l’outil
NTDSUTIL peut entraîner une perte partielle ou complète des fonctionnalités Active Directory.
Suppression de domaines orphelins d’Active Directory

1. Déterminez le contrôleur de domaine qui détient le rôle FSMO (Domain Naming Master Flexible Single
Master Operations). Pour identifier le serveur qui détient ce rôle :
a. Démarrez le logiciel en snap-in MMC (Active Directory Domains and Trusts) à partir du menu Outils
d’administration.
b. Cliquez avec le bouton droit sur le nœud racine dans le volet gauche intitulé Domaines et trusts
Active Director y, puis sélectionnez Operations Master .
c. Le contrôleur de domaine qui détient actuellement ce rôle est identifié dans le cadre Maître des
opérations en cours.
NOTE
Si elle a été modifiée récemment, il se peut que tous les ordinateurs n’ont pas encore reçu cette
modification en raison de la réplication.
Pour plus d’informations sur les rôles FSMO, voir rôles FSMO Active Directory dans Windows.
2. Vérifiez que tous les serveurs du domaine ont été rétrogradés.
3. Ouvrez une fenêtre d'invite de commandes.
4. À l’invite de commandes, ntdsutil tapez, puis appuyez sur Entrée.
5. metadata cleanup Tapez, puis appuyez sur Entrée.
6. connections Tapez, puis appuyez sur Entrée. Ce menu permet de se connecter au serveur spécifique sur
lequel les modifications auront lieu. Si l’utilisateur actuellement connecté n’est pas membre du groupe
Administrateurs Enterprise, d’autres informations d’identification peuvent être fournies en spécifiant les
informations d’identification à utiliser avant d’établir la connexion. Pour ce faire, tapez :
set creds <domainname> <username> <password> , puis appuyez sur Entrée. Pour un mot de passe null, tapez
null pour le paramètre de mot de passe.
7. Type , où est le nom du contrôleur de domaine qui contient le rôle connect to server <servername>
<servername> FSMO principal d’appellation de domaine. Appuyez ensuite sur Entrée. Vous devez
recevoir la confirmation que la connexion est établie. Si une erreur se produit, vérifiez que le contrôleur
de domaine utilisé dans la connexion est disponible. Vérifiez également que les informations
d’identification que vous avez fournies ont des autorisations administratives sur le serveur.
8. quit Tapez, puis appuyez sur Entrée. Le menu Nettoyage des métadonnées s’affiche.
9. select operation target Tapez, puis appuyez sur Entrée.
10. list domainsTapez, puis appuyez sur Entrée. Une liste de domaines dans la forêt s’affiche, chacun avec
un numéro associé.
11. select domain <number> Tapez, puis appuyez sur Entrée, où nombre est le numéro associé au domaine à
supprimer.
12. quit Tapez, puis appuyez sur Entrée. Le menu Nettoyage des métadonnées s’affiche.
13. remove selected domain Tapez, puis appuyez sur Entrée. Vous devez recevoir la confirmation que la
suppression a réussi. Si une erreur se produit, consultez la Base de connaissances Microsoft pour obtenir
des articles sur des messages d’erreur spécifiques.
14. Tapez quit dans chaque menu pour quitter l’outil NTDSUTIL. Vous devez recevoir la confirmation que la
connexion s’est déconnectée correctement.
Références
Pour plus d’informations sur l’outil NTDSUTIL, voir la documentation des outils de support située dans le dossier
Support\Reskit du CD-ROM Windows 2000. Les fichiers d’aide inclus dans le Kit de ressources Microsoft
Windows 2000 contiennent un lien Books Online. Vous pouvez cliquer sur le lien pour obtenir plus
d’informations sur l’outil NTDSUTIL.
Pour plus d’informations sur la suppression de contrôleurs de domaine du domaine que vous tentez de
supprimer, consultez l’article suivant :
216498 supprimer des données dans Active Directory après une rétrogradation de contrôleur de domaine
infructueuse
Comment restaurer les comptes d’utilisateurs
supprimés et leurs appartenances aux groupes dans
Active Directory
Cet article fournit des informations sur la restauration des comptes d’utilisateurs supprimés et des
appartenances aux groupes dans Active Directory.
Produits concernés : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Introduction
Vous pouvez utiliser plusieurs méthodes pour restaurer des comptes d’utilisateurs, des comptes d’ordinateur et
des groupes de sécurité supprimés. Ces objets sont appelés collectivement principaux de sécurité.
La méthode la plus courante consiste à activer la fonctionnalité Corbeille AD prise en charge sur les contrôleurs
de domaine basés sur Windows Server 2008 R2 et ultérieur. Pour plus d’informations sur cette fonctionnalité,
notamment sur la façon de l’activer et de restaurer des objets, voir le Guide pas à pas de la Corbeille Active
Directory.
Si cette méthode n’est pas disponible, les trois méthodes suivantes peuvent être utilisées. Dans les trois
méthodes, vous restituerez les objets supprimés de manière faisant autorité, puis vous restituerez les
informations d’appartenance aux groupes pour les principaux de sécurité supprimés. Lorsque vous restituer un
objet supprimé, vous devez restaurer member memberOf les anciennes valeurs des attributs et des valeurs dans
le principal de sécurité affecté.
NOTE
La récupération des objets supprimés dans Active Directory peut être simplifiée en activant la fonctionnalité Corbeille AD
prise en charge sur les contrôleurs de domaine basés sur Windows Server 2008 R2 et version ultérieure. Pour plus
d’informations sur cette fonctionnalité, notamment sur la façon de l’activer et de restaurer des objets, voir le Guide pas à
pas de la Corbeille Active Directory.
Plus d’informations
Les méthodes 1 et 2 offrent une meilleure expérience aux utilisateurs et aux administrateurs de domaine. Ces
méthodes conservent les ajouts aux groupes de sécurité effectués entre la dernière sauvegarde de l’état du
système et l’heure de la suppression. Dans la méthode 3, vous n’ajustez pas individuellement les principaux de
sécurité. Au lieu de cela, vous revenir aux appartenances aux groupes de sécurité à leur état au moment de la
dernière sauvegarde.
La plupart des suppressions à grande échelle sont accidentelles. Microsoft recommande de prendre plusieurs
mesures pour empêcher d’autres personnes de supprimer des objets en bloc.
NOTE
Pour empêcher la suppression ou le déplacement accidentel d’objets (en particulier les unités d’organisation), deux entrées
de contrôle d’accès refuser peuvent être ajoutées au descripteur de sécurité de chaque objet (DENY DELETEDELETE &
TREE) et une entrée de contrôle d’accès refuser peut être ajoutée au descripteur de sécurité du parent de chaque objet
(DENY DELETE CHILD ). Pour ce faire, utilisez Utilisateurs et ordinateurs Active Directory, ADSIEdit, LDP ou l’outil en ligne
de commande DSACLS. Vous pouvez également modifier les autorisations par défaut dans le schéma AD pour les unités
d’organisation afin que ces ace soient incluses par défaut.
Par exemple, pour protéger l’unité d’organisation appelée. Les utilisateurs du domaine AD CONTOSO.COM qui sont
appelés après avoir été accidentellement déplacés ou supprimés de l’unité d’organisation parente appelée
MyCompany, ont la configuration suivante :
Pour l’unité d’organisation MyCompany , ajoutez DENY ACE pour Tout le monde pour SUPPRIMER l’enfant
avec cette étendue d’objet uniquement :
DSACLS "OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:DC"/
Pour l’unité d’organisation Utilisateurs, ajoutez DENY ACE pour Tout le monde à DELETE et DELETE TREE avec
cette étendue d’objet uniquement :
DSACLS "OU=Users,OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:SDDT"
Le logiciel en ligne Utilisateurs et ordinateurs Active Directory dans Windows Server 2008 inclut une case à
cocher Protéger l’objet contre la suppression accidentelle sous l’onglet Objet.
NOTE
La case à cocher Fonctionnalités avancées doit être activée pour afficher cet onglet.
Lorsque vous créez une unité d’organisation à l’aide des utilisateurs et ordinateurs Active Directory dans
Windows Server 2008, la case à cocher Protéger le conteneur contre la suppression accidentelle s’affiche. Par
défaut, la case à cocher est sélectionnée et peut être désélectionée.
Bien que vous pouvez configurer chaque objet dans Active Directory à l’aide de ces ace, il convient mieux aux
unités d’organisation. La suppression ou les mouvements de tous les objets feuille peuvent avoir un effet majeur.
Cette configuration empêche les suppressions ou les mouvements de ce type. Pour vraiment supprimer ou
déplacer un objet à l’aide d’une telle configuration, les aces de refus doivent d’abord être supprimées.
Cet article explique comment restaurer des comptes d’utilisateurs, des comptes d’ordinateur et leurs
appartenances à des groupes après leur suppression d’Active Directory. Dans les variantes de ce scénario, les
comptes d’utilisateur, les comptes d’ordinateur ou les groupes de sécurité peuvent avoir été supprimés
individuellement ou dans une combinaison. Dans tous ces cas, les mêmes étapes initiales s’appliquent. Vous
restituer ou restaurer authent les objets qui ont été supprimés par inadvertance. Certains objets supprimés
nécessitent davantage de travail pour être restaurés. Ces objets incluent des objets tels que des comptes
d’utilisateurs qui contiennent des attributs qui sont des liens arrière des attributs d’autres objets. Deux de ces
attributs sont managedBy et memberOf .
Lorsque vous ajoutez des principaux de sécurité, tels qu’un compte d’utilisateur, un groupe de sécurité ou un
compte d’ordinateur à un groupe de sécurité, vous a apporté les modifications suivantes dans Active Directory :
1. Le nom du principal de sécurité est ajouté à l’attribut membre de chaque groupe de sécurité.
2. Pour chaque groupe de sécurité dont l’utilisateur, l’ordinateur ou le groupe de sécurité est membre, un lien
arrière est ajouté à l’attribut du principal de memberOf sécurité.
De même, lorsqu’un utilisateur, un ordinateur ou un groupe est supprimé d’Active Directory, les actions
suivantes se produisent :
1. Le principal de sécurité supprimé est déplacé dans le conteneur d’objets supprimés.
2. Quelques valeurs d’attribut, y compris l’attribut memberOf , sont supprimées du principal de sécurité
supprimé.
3. Les principaux de sécurité supprimés sont supprimés des groupes de sécurité dont ils étaient membres. En
d’autres termes, les principaux de sécurité supprimés sont supprimés de l’attribut membre de chaque groupe
de sécurité.
Lorsque vous récupérez des principaux de sécurité supprimés et restituer leurs appartenances aux groupes,
chaque principal de sécurité doit exister dans Active Directory avant de restaurer son appartenance au groupe.
Le membre peut être un utilisateur, un ordinateur ou un autre groupe de sécurité. Pour rétablir cette règle plus
largement, un objet qui contient des attributs dont les valeurs sont des liens arrière doit exister dans Active
Directory pour que l’objet qui contient ce lien avant puisse être restauré ou modifié.
Cet article se concentre sur la récupération des comptes d’utilisateurs supprimés et de leur appartenance à des
groupes de sécurité. Ses concepts s’appliquent également aux autres suppressions d’objets. Les concepts de cet
article s’appliquent également aux objets supprimés dont les valeurs d’attribut utilisent des liens avant et des
liens arrière vers d’autres objets dans Active Directory.
Vous pouvez utiliser l’une des trois méthodes pour récupérer les principaux de sécurité. Lorsque vous utilisez la
méthode 1, vous laissez en place tous les principaux de sécurité qui ont été ajoutés à n’importe quel groupe de
sécurité dans la forêt. Et vous ajoutez uniquement les principaux de sécurité qui ont été supprimés de leurs
domaines respectifs à leurs groupes de sécurité. Par exemple, vous devez effectuer une sauvegarde de l’état du
système, ajouter un utilisateur à un groupe de sécurité, puis restaurer la sauvegarde de l’état système. Lorsque
vous utilisez les méthodes 1 ou 2, vous conservez tous les utilisateurs qui ont été ajoutés aux groupes de
sécurité qui contiennent des utilisateurs supprimés entre les dates de création de la sauvegarde de l’état
système et la date de restauration de la sauvegarde. Lorsque vous utilisez la méthode 3, vous revenir aux
appartenances aux groupes de sécurité de tous les groupes de sécurité qui contiennent des utilisateurs
supprimés à leur état au moment de la sauvegarde de l’état du système.
Méthode 1 : restaurer les comptes d’utilisateur supprimés, puis

rajouter les utilisateurs restaurés à leurs groupes à l’aide de
lNtdsutil.exe de ligne de commande
LNtdsutil.exe de ligne de commande vous permet de restaurer les liens arrière des objets supprimés. Deux
fichiers sont générés pour chaque opération de restauration faisant autorité. Un fichier contient une liste d’objets
restaurés faisant autorité. L’autre fichier est un fichier .ldf qui est utilisé avec l’utilitaire Ldifde.exe. Ce fichier est
utilisé pour restaurer les liens arrière pour les objets qui font autorité restaurés. Une restauration faisant autorité
d’un objet utilisateur génère également des fichiers LDIF (Data Interchange Format) LDAP avec l’appartenance
au groupe. Cette méthode évite une restauration double.
Lorsque vous utilisez cette méthode, vous effectuez les étapes de haut niveau suivantes :
1. Vérifiez si un catalogue global dans le domaine de l’utilisateur n’a pas été répliqué dans la suppression.
Empêchez ensuite la réplication de ce catalogue global. S’il n’existe pas de catalogue global latent, recherchez
la sauvegarde d’état système la plus actuelle d’un contrôleur de domaine de catalogue global dans le
domaine d’accueil de l’utilisateur supprimé.
2. Auth restore all the deleted user accounts, and then allow end-to-end replication of those user accounts.
3. Ajoutez tous les utilisateurs restaurés à tous les groupes dans tous les domaines dont les comptes
d’utilisateurs étaient membres avant leur suppression.
Pour utiliser la méthode 1, suivez la procédure ci-après :
1. Vérifiez s’il existe un contrôleur de domaine de catalogue global dans le domaine d’accueil de l’utilisateur
supprimé qui n’a répliqué aucune partie de la suppression.
NOTE
Concentrez-vous sur les catalogues globaux qui ont les planifications de réplication les moins fréquentes.
S’il existe un ou plusieurs de ces catalogues globaux, utilisez l’outil en ligne de commande Repadmin.exe
pour désactiver immédiatement la réplication entrante en suivant les étapes suivantes :
a. Sélectionnez Démarrer , puis Exécuter .
b. Tapez cmd dans la zone Ouvrir , puis sélectionnez OK .
c. Tapez la commande suivante à l’invite de commandes, puis appuyez sur Entrée :
repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL
NOTE
Repadmin Si vous ne pouvez pas émettre la commande immédiatement, supprimez toute la connectivité
réseau du catalogue global Repadmin latent tant que vous ne pouvez pas désactiver la réplication
entrante, puis renvoyez immédiatement la connectivité réseau.
Ce contrôleur de domaine est appelé contrôleur de domaine de récupération. S’il n’existe aucun catalogue
global de ce type, allez à l’étape 2.
2. Il est préférable d’arrêter d’apporter des modifications aux groupes de sécurité dans la forêt si toutes les
affirmations suivantes sont vraies :
Vous utilisez la méthode 1 pour restaurer de manière faisant autorité des utilisateurs ou des comptes
d’ordinateurs supprimés à l’aide de leur chemin d’accès dn (nom dn).
La suppression a été répliquée sur tous les contrôleurs de domaine de la forêt à l’exception du
contrôleur de domaine de récupération latent.
Vous n’êtes pas en train de restaurer les groupes de sécurité ou leurs conteneurs parents.
Si vous restitiez des groupes de sécurité ou des conteneurs d’unité d’organisation qui hébergent des
groupes de sécurité ou des comptes d’utilisateur, arrêtez temporairement toutes ces modifications.
Avertir les administrateurs et les administrateurs du service d’aide dans les domaines appropriés en plus
des utilisateurs du domaine dans lequel la suppression s’est produite lors de l’arrêt de ces modifications.
3. Créez une sauvegarde de l’état du système dans le domaine dans lequel la suppression s’est produite.
Vous pouvez utiliser cette sauvegarde si vous devez revenir en arrière de vos modifications.
NOTE
Si les sauvegardes d’état système sont à jour jusqu’au point de suppression, ignorez cette étape et passez à l’étape
4.
Si vous avez identifié un contrôleur de domaine de récupération à l’étape 1, back up its system state now.
Si tous les catalogues globaux situés dans le domaine où la suppression s’est produite ont été répliqués
lors de la suppression, back up the system state of a global catalog in the domain where the deletion
occurred.
Lorsque vous créez une sauvegarde, vous pouvez rétablir l’état actuel du contrôleur de domaine de
récupération. Effectuez de nouveau votre plan de récupération si votre première essai n’a pas abouti.
4. Si vous ne trouvez pas de contrôleur de domaine de catalogue global latent dans le domaine où
l’utilisateur a été supprimé, recherchez la sauvegarde d’état système la plus récente d’un contrôleur de
domaine de catalogue global dans ce domaine. Cette sauvegarde d’état système doit contenir les objets
supprimés. Utilisez ce contrôleur de domaine comme contrôleur de domaine de récupération.
Seules les restaurations des contrôleurs de domaine de catalogue global dans le domaine de l’utilisateur
contiennent des informations d’appartenance aux groupes universels et globaux pour les groupes de
sécurité qui résident dans des domaines externes. S’il n’existe aucune sauvegarde de l’état système d’un
contrôleur de domaine de catalogue global dans le domaine où les utilisateurs ont été supprimés, vous
ne pouvez pas utiliser l’attribut sur les comptes d’utilisateur restaurés pour déterminer l’appartenance à
un groupe global ou universel ou pour récupérer l’appartenance memberOf à des domaines externes. En
outre, il est bon de trouver la sauvegarde d’état système la plus récente d’un contrôleur de domaine de
catalogue non global.
5. Si vous connaissez le mot de passe du compte d’administrateur hors connexion, démarrez le contrôleur
de domaine de récupération en mode Derepair. Si vous ne connaissez pas le mot de passe du compte
d’administrateur hors connexion, réinitialisez le mot de passe à l’aide de ntdsutil.exe alors que le
contrôleur de domaine de récupération est toujours en mode Active Directory normal.
Vous pouvez utiliser l’outil en ligne de commande setpwd pour réinitialiser le mot de passe sur les
contrôleurs de domaine lorsqu’ils sont en mode Active Directory en ligne.
NOTE
Microsoft ne prend plus en charge Windows 2000.
Les administrateurs de Windows Server 2003 et des contrôleurs de domaine ultérieurs

set dsrm password peuvent utiliser la commande de l’outil en ligne de commande Ntdsutil pour
réinitialiser le mot de passe du compte d’administrateur hors connexion.
Pour plus d’informations sur la réinitialisation du compte d’administrateur du mode restauration des
services d’annuaire, voir Comment réinitialiser le mot de passe du compte d’administrateur en mode
restauration des services d’annuaire dans Windows Server.
6. Appuyez sur F8 pendant le processus de démarrage pour démarrer le contrôleur de domaine de
récupération en mode Disrepair. Connectez-vous à la console du contrôleur de domaine de récupération
avec le compte d’administrateur hors connexion. Si vous réinitialisez le mot de passe à l’étape 5, utilisez le
nouveau mot de passe.
Si le contrôleur de domaine de récupération est un contrôleur de domaine de catalogue global latent, ne
restituer l’état du système. Allez à l’étape 7.
Si vous créez le contrôleur de domaine de récupération à l’aide d’une sauvegarde de l’état du système,
restituer la sauvegarde d’état système la plus actuelle qui a été réalisée sur le contrôleur de domaine de
récupération maintenant.
7. Auth restore the deleted user accounts, the deleted computer accounts, or the deleted security groups.
NOTE
Les termes restauration d’th et restauration faisant autorité font référence au processus d’utilisation de la
commande de restauration faisant autorité dans l’outil en ligne de commande Ntdsutil pour incrémenter les
numéros de version d’objets spécifiques ou de conteneurs spécifiques et de tous leurs objets subordonnés. Dès
que la réplication de bout en bout se produit, les objets ciblés dans la copie locale du contrôleur de domaine de
récupération d’Active Directory font autorité sur tous les contrôleurs de domaine qui partagent cette partition.
Une restauration faisant autorité est différente d’une restauration d’état système. Une restauration de l’état
système remplit la copie locale d’Active Directory du contrôleur de domaine restauré avec les versions des objets
au moment où la sauvegarde de l’état système a été réalisée.
Les restaurations faisant autorité sont effectuées avec l’outil en ligne de commande Ntdsutil et font
référence au chemin d’accès au nom de domaine (dn) des utilisateurs supprimés ou des conteneurs qui
hébergent les utilisateurs supprimés.
Lorsque vous restituerez l’th, utilisez des chemins d’accès de nom de domaine (dn) qui sont aussi bas
dans l’arborescence de domaine que ce qu’ils doivent être. L’objectif est d’éviter de reconvenir aux objets
qui ne sont pas liés à la suppression. Ces objets peuvent inclure des objets qui ont été modifiés après la
sauvegarde de l’état du système.
Restituer auth les utilisateurs supprimés dans l’ordre suivant :
a. Auth restore the domain name (dn) path for each deleted user account, computer account, or
security group.
Les restaurations faisant autorité d’objets spécifiques prennent plus de temps, mais sont moins
destructrices que les restaurations faisant autorité d’une sous-arbre entière. Auth restore the
lowest common parent container that holds the deleted objects.
Ntdsutil utilise la syntaxe suivante :
ntdsutil "authoritative restore" "restore object <object DN path>" q q
Par exemple, pour restaurer de manière faisant autorité l’utilisateur supprimé John Doe dans l’ou
Contoso.com Mayberr y du domaine, utilisez la commande suivante :
ntdsutil "authoritative restore" "restore object cn=JohnDoe,ou=Mayberry,dc=contoso,dc=com" q q
Pour restaurer le groupe de sécurité supprimé ContosoPrintAccess dans l’ou Contoso.com

Mayberr y du domaine, utilisez la commande suivante :
ntdsutil "authoritative restore" "restore object

cn=ContosoPrintAccess,ou=Mayberry,dc=contoso,dc=com" q q
IMPORTANT
L’utilisation de guillemets est requise.
Pour chaque utilisateur que vous restituer, au moins deux fichiers sont générés. Ces fichiers ont le
format suivant :
ar_ YYYMMDD-HHMMSS _objects.txt
Ce fichier contient une liste des objets restaurés faisant autorité. Utilisez ce fichier avec la
commande de restauration faisant autorité de ntdsutil create ldif file from dans tout autre
domaine de la forêt où l’utilisateur était membre des groupes Domain Local.
ar_ YYYMMDD-HHMMSS _links_usn.loc.ldf
Si vous effectuez la restauration d’th sur un catalogue global, l’un de ces fichiers est généré pour
chaque domaine de la forêt. Ce fichier contient un script que vous pouvez utiliser avec l’utilitaire
Ldifde.exe de données. Le script restaure les liens arrière pour les objets restaurés. Dans le
domaine d’accueil de l’utilisateur, le script restaure toutes les appartenances de groupe pour les
utilisateurs restaurés. Dans tous les autres domaines de la forêt où l’utilisateur est membre d’un
groupe, le script restaure uniquement les appartenances aux groupes universels et globaux. Le
script ne restaure aucune appartenance au groupe Domain Local. Ces appartenances ne sont pas
suivis par un catalogue global.
b. Auth restore only the OU or Common-Name (CN) containers that host the deleted user accounts
or groups.
Les restaurations faisant autorité d’une sous-arbre entière sont valides lorsque l’ou ciblée par la
commande de restauration faisant autorité ntdsutil contient la plupart des objets que vous essayez
de restaurer de manière faisant autorité. Dans l’idéal, l’ouo ciblé contient tous les objets que vous
essayez de restaurer de manière fiable.
Une restauration faisant autorité sur une sous-arbre d’ou restaure tous les attributs et objets qui
résident dans le conteneur. Toutes les modifications qui ont été apportées jusqu’à la restauration
d’une sauvegarde de l’état du système sont restaurées à leurs valeurs au moment de la
sauvegarde. Avec les comptes d’utilisateur, les comptes d’ordinateur et les groupes de sécurité,
cette récupération peut signifier la perte des modifications les plus récentes apportées à :
mots de passe
répertoire d’accueil
chemin d’accès du profil
location
coordonnées
appartenance à un groupe
tous les descripteurs de sécurité définis sur ces objets et attributs.
ntdsutil "authoritative restore" "restore subtree <container DN path>" q q
Par exemple, pour restaurer avec autorité l’ouo Contoso.com Mayberr y du domaine, utilisez la
commande suivante :
ntdsutil "authoritative restore" "restore subtree ou=Mayberry, dc=contoso,dc=com" q q
NOTE
Répétez cette étape pour chaque ou plusieurs ou plusieurs groupes d’homologues qui hébergent des
utilisateurs ou des groupes supprimés.
IMPORTANT
Lorsque vous restituer un objet subordonné d’une ou plusieurs de ses boîtes de données, tous les
conteneurs parents supprimés des objets subordonnés supprimés doivent être explicitement restaurés.
Pour chaque unité d’organisation que vous restituerez, au moins deux fichiers sont générés. Ces
fichiers ont le format suivant :
ar_ YYYMMDD-HHMMSS _objects.txt
Ce fichier contient une liste des objets restaurés faisant autorité. Utilisez ce fichier avec la
commande de restauration faisant autorité de ntdsutil create ldif file from dans tout autre
domaine de la forêt où les utilisateurs restaurés étaient membres de groupes Domain Local.
ar_ YYYMMDD-HHMMSS _links_usn.loc.ldf
Ce fichier contient un script que vous pouvez utiliser avec l’utilitaire Ldifde.exe de données. Le
script restaure les liens arrière pour les objets restaurés. Dans le domaine d’accueil de l’utilisateur,
le script restaure toutes les appartenances de groupe pour les utilisateurs restaurés.
8. Si des objets supprimés ont été récupérés sur le contrôleur de domaine de récupération en raison d’une
restauration de l’état du système, supprimez tous les câbles réseau qui assurent la connectivité réseau à
tous les autres contrôleurs de domaine dans la forêt.
9. Redémarrez le contrôleur de domaine de récupération en mode Active Directory normal.
10. Tapez la commande suivante pour désactiver la réplication entrante vers le contrôleur de domaine de
récupération :
Activez de nouveau la connectivité réseau au contrôleur de domaine de récupération dont l’état système
a été restauré.
11. Répliquer les objets restaurés auth à partir du contrôleur de domaine de récupération vers les
contrôleurs de domaine dans le domaine et dans la forêt.
Bien que la réplication entrante vers le contrôleur de domaine de récupération reste désactivée, tapez la
commande suivante pour pousser les objets restaurés auth vers tous les contrôleurs de domaine réplicas
entre sites dans le domaine et dans tous les catalogues globaux de la forêt :
repadmin /syncall /d /e /P <recovery dc> <Naming Context>
Si toutes les affirmations suivantes sont vraies, les liens d’appartenance aux groupes sont reconstruits
avec la restauration et la réplication des comptes d’utilisateur supprimés. Allez à l’étape 14.
NOTE
Si une ou plusieurs des instructions suivantes ne sont pas vraies, allez à l’étape 12.
Votre forêt est en cours d’exécution au niveau fonctionnel de forêt Windows Server 2003 et ultérieur
ou ultérieur, ou au niveau fonctionnel de forêt intermédiaire Windows Server 2003 et ultérieur ou
ultérieur.
Seuls les comptes d’utilisateur ou les comptes d’ordinateur ont été supprimés, et non les groupes de
sécurité.
Les utilisateurs supprimés ont été ajoutés aux groupes de sécurité dans tous les domaines de la forêt
après la transition de la forêt vers Windows Server 2003 et ultérieur, ou le niveau fonctionnel de la
forêt ultérieure.
12. Sur la console du contrôleur de domaine de récupération, utilisez l’utilitaire Ldifde.exe et le fichier ar_
YYYMMDD-HHMMSS _links_usn.loc.ldf pour restaurer les appartenances aux groupes de l’utilisateur.
Pour ce faire, procédez comme suit :
Sélectionnez Démarrer , Exécuter , tapez cmd dans la zone Ouvrir , puis sélectionnez OK .
À l'invite de commandes, tapez la commande suivante, puis appuyez sur Entrée :
ldifde -i -f ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf
13. Activez la réplication entrante sur le contrôleur de domaine de récupération à l’aide de la commande
suivante :
repadmin /options <recovery dc name> -DISABLE_INBOUND_REPL
14. Si des utilisateurs supprimés ont été ajoutés à des groupes locaux dans des domaines externes, prenez
l’une des mesures suivantes :
Ajoutez manuellement les utilisateurs supprimés à ces groupes.
Restituer l’état du système et l’th restaurer chacun des groupes de sécurité locaux qui contient les
utilisateurs supprimés.
15. Vérifiez l’appartenance au groupe dans le domaine du contrôleur de domaine de récupération et dans les
catalogues globaux dans d’autres domaines.
16. Effectuer une nouvelle sauvegarde de l’état système des contrôleurs de domaine dans le domaine du
contrôleur de domaine de récupération.
17. Informez tous les administrateurs de forêt, les administrateurs délégués, les administrateurs du service
d’aide de la forêt et les utilisateurs du domaine que la restauration de l’utilisateur est terminée.
Les administrateurs du service d’aide peuvent être tenus de réinitialiser les mots de passe des comptes
d’utilisateurs restaurés et des comptes d’ordinateur dont le mot de passe de domaine a été modifié après
la restauration du système.
Les utilisateurs qui ont modifié leur mot de passe après la sauvegarde de l’état du système trouveront
que leur mot de passe le plus récent ne fonctionne plus. Si ces utilisateurs le connaissent, essayez de se
connecter à l’aide de leurs mots de passe précédents. Dans le cas contraire, les administrateurs du service
d’aide doivent réinitialiser le mot de passe et sélectionner l’utilisateur doit modifier le mot de passe lors
de la prochaine case à cocher d’accès. Faites-le de préférence sur un contrôleur de domaine dans le
même site Active Directory que celui où se trouve l’utilisateur.
Méthode 2 : restaurer les comptes d’utilisateur supprimés, puis

rajouter les utilisateurs restaurés à leurs groupes
Empêchez ensuite la réplication de ce catalogue global. S’il n’existe pas de catalogue global latent, recherchez
la sauvegarde d’état système la plus actuelle d’un contrôleur de domaine de catalogue global dans le
domaine d’accueil de l’utilisateur supprimé.
2. Auth restore all the deleted user accounts, and then allow end-to-end replication of those user accounts.
3. Ajoutez tous les utilisateurs restaurés à tous les groupes dans tous les domaines dont les comptes
d’utilisateurs étaient membres avant leur suppression.
1. Vérifiez s’il existe un contrôleur de domaine de catalogue global dans le domaine d’accueil de l’utilisateur
supprimé qui n’a répliqué aucune partie de la suppression.
NOTE
Concentrez-vous sur les catalogues globaux qui ont les planifications de réplication les moins fréquentes.
S’il existe un ou plusieurs de ces catalogues globaux, utilisez l’outil Repadmin.exe ligne de commande
pour désactiver immédiatement la réplication entrante. Pour ce faire, procédez comme suit :
c. Tapez la commande suivante à l’invite de commandes, puis appuyez sur Entrée :
NOTE
Si vous ne pouvez pas émettre la commande Repadmin immédiatement, supprimez toute la connectivité réseau
du catalogue global latent tant que vous ne pouvez pas utiliser Repadmin pour désactiver la réplication entrante,
puis renvoyez immédiatement la connectivité réseau.
Ce contrôleur de domaine est appelé contrôleur de domaine de récupération. S’il n’existe aucun catalogue
global de ce type, allez à l’étape 2.
2. Déterminez si les ajouts, suppressions et modifications apportés aux comptes d’utilisateur, aux comptes
d’ordinateur et aux groupes de sécurité doivent être temporairement arrêtés jusqu’à ce que toutes les
étapes de récupération soient terminées.
Pour conserver le chemin de récupération le plus flexible, arrêtez temporairement d’apporter des
modifications aux éléments suivants. Les modifications incluent les réinitialisations de mot de passe par
les utilisateurs du domaine, les administrateurs du service d’aide et les administrateurs du domaine dans
lequel la suppression s’est produite, en plus des modifications d’appartenance aux groupes d’utilisateurs
supprimés. Envisagez d’interrompre les ajouts, suppressions et modifications apportés aux éléments
suivants :
a. Comptes d’utilisateur et attributs sur les comptes d’utilisateurs
b. Comptes et attributs d’ordinateur sur les comptes d’ordinateur
c. Comptes de service
d. Groupes de sécurité
Il est préférable d’arrêter d’apporter des modifications aux groupes de sécurité dans la forêt si toutes les
affirmations suivantes sont vraies :
Vous utilisez la méthode 2 pour restaurer de manière faisant autorité des utilisateurs ou des comptes
d’ordinateur supprimés par leur chemin d’accès de nom de domaine (dn).
La suppression a été répliquée sur tous les contrôleurs de domaine de la forêt à l’exception du
contrôleur de domaine de récupération latent.
Vous n’êtes pas en train de restaurer les groupes de sécurité ou leurs conteneurs parents.
Si vous restitiez des groupes de sécurité ou des conteneurs d’unité d’organisation qui hébergent des
groupes de sécurité ou des comptes d’utilisateur, arrêtez temporairement toutes ces modifications.
Avertir les administrateurs et les administrateurs du service d’aide dans les domaines appropriés en plus
des utilisateurs du domaine dans lequel la suppression s’est produite lors de l’arrêt de ces modifications.
NOTE
Si les sauvegardes d’état système sont à jour jusqu’au point de suppression, ignorez cette étape et passez à l’étape
4.
Si tous les catalogues globaux situés dans le domaine où la suppression s’est produite ont été répliqués
lors de la suppression, back up the system state of a global catalog in the domain where the deletion
occurred.
Seules les restaurations des contrôleurs de domaine de catalogue global dans le domaine de l’utilisateur
contiennent des informations d’appartenance aux groupes universels et globaux pour les groupes de
sécurité qui résident dans des domaines externes. S’il n’existe aucune sauvegarde de l’état système d’un
contrôleur de domaine de catalogue global dans le domaine où les utilisateurs ont été supprimés, vous
ne pouvez pas utiliser l’attribut sur les comptes d’utilisateur restaurés pour déterminer l’appartenance à
un groupe global ou universel ou pour récupérer l’appartenance memberOf à des domaines externes. En
outre, il est bon de trouver la sauvegarde d’état système la plus récente d’un contrôleur de domaine de
catalogue non global.
d’administrateur hors connexion, réinitialisez-le alors que le contrôleur de domaine de récupération est
toujours en mode Active Directory normal.
contrôleurs de domaine qui exécutent Windows 2000 Service Pack 2 (SP2) et version ultérieure lorsqu’ils
sont en mode Active Directory en ligne.
NOTE

restituer l’état du système. Allez à l’étape 7.
récupération maintenant.
NOTE
Les restaurations faisant autorité sont effectuées avec l’outil en ligne de commande Ntdsutil et font
référence au chemin d’accès au nom de domaine (dn) des utilisateurs supprimés ou des conteneurs qui
hébergent les utilisateurs supprimés.
Lorsque vous restituerez l’th, utilisez des chemins d’accès de nom de domaine (dn) qui sont aussi bas
dans l’arborescence de domaine que ce qu’ils doivent être. L’objectif est d’éviter de reconvenir aux objets
qui ne sont pas liés à la suppression. Ces objets peuvent inclure des objets qui ont été modifiés après la
security group.


IMPORTANT
NOTE
Cette syntaxe est disponible uniquement dans Windows Server 2003 et ultérieur. La seule syntaxe
Windows 2000 consiste à utiliser les syntaxes suivantes :
ntdsutil "authoritative restore" "restore subtree object DN path"
NOTE
L’opération de restauration faisant autorité de Ntdsutil n’est pas réussie si le chemin d’accès au nom (DN)
contient des espaces ou des caractères étendus. Pour que la restauration par script réussisse,
restore object <DN path> la commande doit être passée en tant que chaîne complète.
Pour contourner ce problème, encapsulez le DN qui contient des espaces et des caractères étendus
avec des séquences d’échappatoires de guillemets doubles. Voici un exemple :
ntdsutil "authoritative restore" "restore object \"CN=John Doe,OU=Mayberry

NC,DC=contoso,DC=com\"" q q
NOTE
La commande doit être modifiée si le DN des objets en cours de restauration contient des virgules.
Prenons l’exemple suivant :
ntdsutil "authoritative restore" "restore object \"CN=Doe\, John,OU=Mayberry

NC,DC=contoso,DC=com\"" q q
NOTE
Si les objets ont été restaurés à partir d’une bande, marqués faisant autorité et que la restauration n’a pas
fonctionné comme prévu, puis que la même bande est utilisée pour restaurer de nouveau la base de
données NTDS, la version USN des objets à restaurer faisant autorité doit être supérieure à la valeur par
défaut de 100 000, sinon les objets ne seront pas répliqués après la deuxième restauration. La syntaxe ci-
dessous est nécessaire pour écrire un numéro de version supérieur à 100 000 (par défaut) :
ntdsutil "authoritative restore" "restore object \"CN=Doe\, John,OU=Mayberry

NC,DC=contoso,DC=com\" verinc 150000\"" q q
NOTE
Si le script demande confirmation sur chaque objet en cours de restauration, vous pouvez désactiver les
invites. La syntaxe pour désactiver l’invite est la suivante :
ntdsutil "popups off" "authoritative restore" "restore object \"CN=John Doe,OU=Mayberry

NC,DC=contoso,DC=com\" verinc 150000\"" q q
or groups.
commande de restauration faisant autorité ntdsutil contient la plupart des objets que vous essayez
de restaurer de manière faisant autorité. Dans l’idéal, l’ouo ciblé contient tous les objets que vous
essayez de restaurer de manière fiable.
cette récupération peut signifier la perte des dernières modifications apportées aux mots de passe,
au répertoire d’accueil, au chemin d’accès au profil, à l’emplacement et aux informations de
contact, à l’appartenance au groupe et à tous les descripteurs de sécurité définis sur ces objets et
attributs.
commande suivante :
ntdsutil "authoritative restore" "restore subtree ou=Mayberry, dc=contoso,dc=com" q q
NOTE
IMPORTANT
conteneurs parents supprimés des objets subordonnés supprimés doivent être explicitement restaurés.
8. Si des objets supprimés ont été récupérés sur le contrôleur de domaine de récupération en raison d’une
restauration de l’état du système, supprimez tous les câbles réseau qui assurent la connectivité réseau à
tous les autres contrôleurs de domaine dans la forêt.
10. Tapez la commande suivante pour désactiver la réplication entrante vers le contrôleur de domaine de
récupération :
Activez de nouveau la connectivité réseau au contrôleur de domaine de récupération dont l’état système
a été restauré.
11. Répliquer les objets restaurés auth à partir du contrôleur de domaine de récupération vers les
commande suivante pour pousser les objets restaurés auth vers tous les contrôleurs de domaine réplicas
entre sites dans le domaine et dans tous les catalogues globaux de la forêt :
avec la restauration et la réplication des comptes d’utilisateur supprimés. Allez à l’étape 14.
NOTE
Si une ou plusieurs des instructions suivantes ne sont pas vraies, allez à l’étape 12.
Votre forêt est en cours d’exécution au niveau fonctionnel de forêt Windows Server 2003 et ultérieur,
ou au niveau fonctionnel de forêt intermédiaire Windows Server 2003 et ultérieur.
Seuls les comptes d’utilisateur ou les comptes d’ordinateur ont été supprimés, et non les groupes de
sécurité.
Les utilisateurs supprimés ont été ajoutés aux groupes de sécurité dans tous les domaines de la forêt
après la transition de la forêt vers Windows Server 2003 et le niveau fonctionnel de la forêt ultérieure.
12. Déterminez les groupes de sécurité dont les utilisateurs supprimés étaient membres, puis ajoutez-les à
ces groupes.
NOTE
Avant de pouvoir ajouter des utilisateurs à des groupes, les utilisateurs que vous avez restaurés à l’étape 7 et ceux
que vous avez répliqués à l’étape 11 doivent avoir été répliqués sur les contrôleurs de domaine dans le domaine
du contrôleur de domaine référencé et sur tous les contrôleurs de domaine de catalogue global dans la forêt.
Si vous avez déployé un utilitaire de mise en service de groupe pour re-repaser l’appartenance aux
groupes de sécurité, utilisez cet utilitaire pour restaurer les utilisateurs supprimés dans les groupes de
sécurité dont ils étaient membres avant leur suppression. Faites-le une fois que tous les contrôleurs de
domaine directs et transitifs dans le domaine de la forêt et les serveurs de catalogue global ont répliqué
les utilisateurs auth restaurés et tous les conteneurs restaurés.
Si vous n’avez pas l’utilitaire, Ldifde.exe Groupadd.exe les outils en ligne de commande peuvent
automatiser cette tâche pour vous lorsqu’ils sont exécutés sur le contrôleur de domaine de récupération.
Ces outils sont disponibles à partir des services de support technique Microsoft. Dans ce scénario,
Ldifde.exe crée un fichier d’informations LDIF (Data Interchange Format) LDAP qui contient les noms des
comptes d’utilisateurs et de leurs groupes de sécurité. Elle démarre dans un conteneur d’ou que
l’administrateur spécifie. Groupadd.exe lit ensuite l’attribut memberOf de chaque compte d’utilisateur
répertorié dans le fichier .ldf. Il génère ensuite des informations LDIF distinctes et uniques pour chaque
domaine de la forêt. Ces informations LDIF contiennent les noms des groupes de sécurité associés aux
utilisateurs supprimés. Utilisez les informations LDIF pour rajouter les informations aux utilisateurs afin
que leurs appartenances aux groupes soient restaurées. Suivez les étapes suivantes pour cette phase de
la récupération :
a. Connectez-vous à la console du contrôleur de domaine de récupération à l’aide d’un compte
d’utilisateur membre du groupe de sécurité de l’administrateur de domaine.
b. Utilisez la commande Ldifde pour vider les noms des comptes d’utilisateurs supprimés et leurs
attributs memberOf , en commençant par le conteneur d’ou le plus haut où la suppression s’est
produite. La commande Ldifde utilise la syntaxe suivante :
ldifde -d <dn path of container that hosts deleted users> -r "(objectClass=user)" -l memberof
-p subtree -f user_membership_after_restore.ldf
Utilisez la syntaxe suivante si des comptes d’ordinateur supprimés ont été ajoutés à des groupes
de sécurité :
ldifde -d <dn path of container that hosts deleted users> -r "(objectClass=computer)" -l

memberof -p subtree -f computer_membership_after_restore.ldf
c. Exécutez la Groupadd commande pour créer d’autres fichiers .ldf qui contiennent les noms de
domaines et les noms des groupes de sécurité globaux et universels dont les utilisateurs
supprimés étaient membres. La Groupadd commande utilise la syntaxe suivante :
Groupadd / after_restore users_membership_after_restore.ldf
Répétez cette commande si des comptes d’ordinateur supprimés ont été ajoutés aux groupes de
sécurité.
d. Importez Groupadd chaque fichier _fully.qualified.domain.name.ldf que vous avez créé à l’étape
12c dans un contrôleur de domaine de catalogue global qui correspond au fichier .ldf de chaque
domaine. Utilisez la syntaxe Ldifde suivante :
Ldifde -i -k -f Groupadd_<fully.qualified.domain.name>.ldf
Exécutez le fichier .ldf pour le domaine dont les utilisateurs ont été supprimés sur n’importe quel
contrôleur de domaine à l’exception du contrôleur de domaine de récupération.
e. Sur la console de chaque contrôleur de domaine utilisé pour importer le fichier
Groupadd_<fully.qualified.domain.name>.ldf pour un domaine particulier, répliquez les
ajouts d’appartenance au groupe vers les autres contrôleurs de domaine dans le domaine et dans
les contrôleurs de domaine du catalogue global dans la forêt. Pour ce faire, utilisez la commande
suivante :
13. Pour désactiver la réplication sortante, tapez le texte suivant, puis appuyez sur Entrée :
repadmin /options +DISABLE_OUTBOUND_REPL

NOTE
Pour activer à nouveau la réplication sortante, tapez le texte suivant, puis appuyez sur Entrée :
repadmin /options -DISABLE_OUTBOUND_REPL
contrôleur de domaine de récupération.
d’utilisateurs restaurés et des comptes d’ordinateur dont le mot de passe de domaine a été modifié après
d’aide doivent réinitialiser le mot de passe et sélectionner l’utilisateur doit modifier le mot de passe lors
de la prochaine case à cocher d’accès. Faites-le de préférence sur un contrôleur de domaine dans le
même site Active Directory que celui où se trouve l’utilisateur.
Méthode 3 : restaurer les utilisateurs supprimés et les groupes de

sécurité des utilisateurs supprimés à deux reprises
Empêchez ensuite ce contrôleur de domaine de répliquer la suppression. S’il n’existe pas de catalogue global
latent, recherchez la sauvegarde d’état système la plus actuelle d’un contrôleur de domaine de catalogue
global dans le domaine d’accueil de l’utilisateur supprimé.
2. Restituer avec autorité tous les comptes d’utilisateurs supprimés et tous les groupes de sécurité dans le
domaine de l’utilisateur supprimé.
3. Attendez la réplication de bout en bout des utilisateurs restaurés et des groupes de sécurité sur tous les
contrôleurs de domaine dans le domaine de l’utilisateur supprimé et sur les contrôleurs de domaine de
catalogue global de la forêt.
4. Répétez les étapes 2 et 3 pour restaurer de manière fiable les utilisateurs et les groupes de sécurité
supprimés. (Vous restituer l’état du système une seule fois.)
5. Si les utilisateurs supprimés étaient membres de groupes de sécurité dans d’autres domaines, restituer avec
autorité tous les groupes de sécurité dont les utilisateurs supprimés étaient membres dans ces domaines.
Ou, si les sauvegardes d’état système sont en cours, restituer de manière faisant autorité tous les groupes de
sécurité dans ces domaines. Pour satisfaire l’exigence selon qui les membres du groupe supprimés doivent
être restaurés avant les groupes de sécurité pour corriger les liens d’appartenance au groupe, vous restituer
deux fois les deux types d’objets dans cette méthode. La première restauration met en place tous les comptes
d’utilisateur et de groupe. La deuxième restauration restaure les groupes supprimés et répare les
informations d’appartenance aux groupes, y compris les informations d’appartenance pour les groupes
imbrmbrés.
1. Vérifiez si un contrôleur de domaine de catalogue global existe dans le domaine d’accueil des utilisateurs
supprimés et n’a pas été répliqué dans une partie de la suppression.
NOTE
Concentrez-vous sur les catalogues globaux dans le domaine qui ont les planifications de réplication les moins
fréquentes. Si ces contrôleurs de domaine existent, utilisez lRepadmin.exe de ligne de commande pour désactiver
immédiatement la réplication entrante. Pour ce faire, procédez comme suit :

c. Tapez repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL à l’invite de commandes, puis
appuyez sur Entrée.
NOTE
Si vous ne pouvez pas émettre la commande Repadmin immédiatement, supprimez toute la connectivité réseau
du contrôleur de domaine tant que vous ne pouvez pas utiliser Repadmin pour désactiver la réplication entrante,
puis renvoyez immédiatement la connectivité réseau.
Ce contrôleur de domaine est appelé contrôleur de domaine de récupération.

2. Évitez d’apporter des ajouts, suppressions et modifications aux éléments suivants jusqu’à ce que toutes
les étapes de récupération soient terminées. Les modifications incluent les réinitialisations de mot de
passe par les utilisateurs du domaine, les administrateurs du service d’aide et les administrateurs du
domaine dans lequel la suppression s’est produite, en plus des modifications d’appartenance aux groupes
d’utilisateurs supprimés.
a. Comptes d’utilisateur et attributs sur les comptes d’utilisateurs
b. Comptes et attributs d’ordinateur sur les comptes d’ordinateur
c. Comptes de service
d. Groupes de sécurité
NOTE
Évitez en particulier les modifications apportées à l’appartenance aux groupes pour les utilisateurs, les
ordinateurs, les groupes et les comptes de service dans la forêt où la suppression s’est produite.
e. Informez tous les administrateurs de forêt, les administrateurs délégués et les administrateurs du
support de support dans la forêt de la solution de secours temporaire. Cette mise en stand-down
est requise dans la méthode 2, car vous restitiez de manière faisant autorité tous les groupes de
sécurité des utilisateurs supprimés. Par conséquent, toutes les modifications apportées aux
groupes après la date de sauvegarde de l’état système sont perdues.
NOTE
Si vos sauvegardes d’état système sont à jour jusqu’au moment où la suppression s’est produite, ignorez cette
étape et passez à l’étape 4.
Si tous les catalogues globaux situés dans le domaine dans lequel la suppression s’est produite ont
répliqué la suppression, back up the system state of a global catalog in the domain where the deletion
occurred.
Seules les bases de données des contrôleurs de domaine de catalogue global dans le domaine de
l’utilisateur contiennent des informations d’appartenance aux groupes pour les domaines externes de la
forêt. S’il n’existe aucune sauvegarde de l’état système d’un contrôleur de domaine de catalogue global
dans le domaine où les utilisateurs ont été supprimés, vous ne pouvez pas utiliser l’attribut sur les
comptes d’utilisateur restaurés pour déterminer l’appartenance à un groupe global ou universel ou pour
récupérer l’appartenance memberOf à des domaines externes. Passer à l’étape suivante. S’il existe un
enregistrement externe de l’appartenance à un groupe dans des domaines externes, ajoutez les
utilisateurs restaurés aux groupes de sécurité dans ces domaines une fois que les comptes d’utilisateur
ont été restaurés.
d’administrateur hors connexion, réinitialisez-le alors que le contrôleur de domaine de récupération est
toujours en mode Active Directory normal.
contrôleurs de domaine qui exécutent Windows 2000 SP2 et version ultérieure lorsqu’ils sont en mode
Active Directory en ligne.
NOTE

restituer l’état du système. Allez directement à l’étape 7.
récupération qui contient les objets supprimés maintenant.
NOTE
Les restaurations faisant autorité sont effectuées avec l’outil en ligne de commande Ntdsutil en
référençant le chemin dn (domain name) des utilisateurs supprimés ou des conteneurs qui hébergent les
Lorsque vous restituerez l’th, utilisez des chemins d’accès de nom de domaine qui sont aussi bas dans
l’arborescence de domaine que ce qu’ils doivent être. L’objectif est d’éviter de reconvenir aux objets qui
ne sont pas liés à la suppression. Ces objets peuvent inclure des objets qui ont été modifiés après la
deleted security group.

IMPORTANT
En utilisant ce format Ntdsutil, vous pouvez également automatiser la restauration faisant autorité
de nombreux objets dans un fichier de lots ou un script.
NOTE
Cette syntaxe est disponible uniquement dans Windows Server 2003 et ultérieur. La seule syntaxe
Windows 2000 est d’utiliser : ntdsutil "authoritative restore" "restore subtree object DN path" .
or groups.
commande de restauration faisant autorité Ntdsutil contient la plupart des objets que vous
essayez de restaurer de manière faisant autorité. Dans l’idéal, l’ouo ciblé contient tous les objets
que vous essayez de restaurer de manière fiable.
cette récupération peut signifier la perte des dernières modifications apportées aux mots de passe,
au répertoire d’accueil, au chemin d’accès au profil, à l’emplacement et aux informations de
contact, à l’appartenance au groupe et à tous les descripteurs de sécurité définis sur ces objets et
attributs.
commande suivante :
ntdsutil "authoritative restore" "restore subtree ou=Mayberry,dc=contoso,dc=com" q q
NOTE
IMPORTANT
conteneurs parents des objets subordonnés supprimés doivent être explicitement restaurés.
9. Répliquer les objets restaurés faisant autorité à partir du contrôleur de domaine de récupération vers les
commande suivante pour pousser les objets restaurés faisant autorité vers tous les contrôleurs de
domaine réplicas entre sites dans le domaine et vers les catalogues globaux de la forêt :
Une fois que tous les contrôleurs de domaine directs et transitifs des serveurs de domaine et de
catalogue global de la forêt ont été répliqués dans les utilisateurs restaurés faisant autorité et tous les
conteneurs restaurés, allez à l’étape 11.
avec la restauration des comptes d’utilisateur supprimés. Allez à l’étape 13.
Votre forêt est en cours d’exécution au niveau fonctionnel de forêt Windows Server 2003 et ultérieur,
ou au niveau fonctionnel de forêt intermédiaire Windows Server 2003 et ultérieur.
Seuls les groupes de sécurité n’ont pas été supprimés.
Tous les utilisateurs supprimés ont été ajoutés à tous les groupes de sécurité dans tous les domaines
de la forêt.
Envisagez d’utiliser Repadmin la commande pour accélérer la réplication sortante des utilisateurs à partir
du contrôleur de domaine restauré.
Si des groupes ont également été supprimés ou si vous ne pouvez pas garantir que tous les utilisateurs
supprimés ont été ajoutés à tous les groupes de sécurité après la transition vers le niveau fonctionnel
intermédiaire ou de forêt Windows Server 2003 et ultérieur, allez à l’étape 12.
10. Répétez les étapes 7, 8 et 9 sans restaurer l’état du système, puis allez à l’étape 11.
13. Utilisez la commande suivante pour activer la réplication entrante sur le contrôleur de domaine de
récupération :
repadmin /options recovery dc name -DISABLE_INBOUND_REPL
contrôleur de domaine de récupération et les catalogues globaux dans d’autres domaines de la forêt.
d’utilisateur restaurés et des comptes d’ordinateur dont le mot de passe de domaine a été modifié après
d’aide doivent réinitialiser le mot de passe avec l’utilisateur doit modifier le mot de passe lors de la
prochaine case à cocher d’accès. Faites-le de préférence sur un contrôleur de domaine dans le même site
Active Directory que celui où se trouve l’utilisateur.
Comment récupérer des utilisateurs supprimés sur un contrôleur de

domaine lorsque vous n’avez pas de sauvegarde d’état système valide
Si vous n’avez pas de sauvegardes d’état système actuelles dans un domaine où des comptes d’utilisateurs ou
des groupes de sécurité ont été supprimés et que la suppression s’est produite dans les domaines qui
contiennent Windows Server 2003 et les contrôleurs de domaine ultérieurs, suivez ces étapes pour réanimer
manuellement les objets supprimés du conteneur d’objets supprimés :
1. Suivez les étapes de la section suivante pour animer les utilisateurs, les ordinateurs, les groupes ou tous les
utilisateurs supprimés :
Comment supprimer manuellement des objets dans un conteneur d’objets supprimés
2. Utilisez utilisateurs et ordinateurs Active Directory pour modifier le compte de désactivé à activé. (Le compte
apparaît dans l’ou d’origine.)
3. Utilisez les fonctionnalités de réinitialisation en bloc dans Windows Server 2003 et les versions ultérieures
d’Utilisateurs et ordinateurs Active Directory pour effectuer des réinitialisations en bloc sur le mot de passe
doivent être modifiées au prochain paramètre de stratégie d’inscription, dans l’annuaire d’accueil, sur le
chemin d’accès du profil et sur l’appartenance au groupe pour le compte supprimé, le cas échéant. Vous
pouvez également utiliser un équivalent par programme de ces fonctionnalités.
4. Si Microsoft Exchange 2000 ou une ultérieure a été utilisé, réparez la boîte aux lettres Exchange’utilisateur
supprimé.
5. Si Exchange 2000 ou ultérieure a été utilisé, réassociez l’utilisateur supprimé à la boîte aux lettres
Exchange’utilisateur.
6. Vérifiez que l’utilisateur récupéré peut se connecter et accéder aux répertoires locaux, aux répertoires
partagés et aux fichiers.
Vous pouvez automatiser une partie ou l’ensemble de ces étapes de récupération à l’aide des méthodes
suivantes :
Écrivez un script qui automatise les étapes de récupération manuelle répertoriées à l’étape 1. Lorsque vous
écrivez un tel script, envisagez d’étudier la portée de l’objet supprimé par date, heure et dernier conteneur
parent connu, puis automatisez la réanimation de l’objet supprimé. Pour automatiser la réanimation,
isDeleted modifiez l’attribut de TRUE à FALSE et modifiez le nom commun relatif lastKnownParent à la
valeur définie dans l’attribut ou dans un nouveau conteneur d’ou de nom commun (CN) spécifié par
l’administrateur. (Le nom de distinction relatif est également appelé RDN.)
Obtenez un programme non Microsoft qui prend en charge la réanimation d’objets supprimés sur Windows
Server 2003 et les contrôleurs de domaine ultérieurs. L’un de ces utilitaires est AdRestore. AdRestore utilise
la Windows Server 2003 et les primitives ultérieures pour ne plusdelete les objets individuellement. Aelita
Software Corporation et Commvault Systems proposent également des produits qui offrent des
fonctionnalités de non-delete sur Windows Server 2003 et les contrôleurs de domaine ultérieurs.
Pour obtenir AdRestore, voir AdRestore v1.1.
Microsoft fournit des informations de contact de sociétés tierces afin de vous aider à obtenir un support
technique. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas la
précision de ces informations de contact tierces.
Comment supprimer manuellement des objets dans le conteneur
d’un objet supprimé
Pour supprimer manuellement les objets du conteneur d’un objet supprimé, suivez les étapes suivantes :
1. Sélectionnez Démarrer , Exécuter , puis tapez ldp.exe.
ldp.exe est disponible :
Sur les ordinateurs sur lequel le rôle contrôleur de domaine a été installé.
Sur les ordinateurs où les outils d’administration de serveur distant (RSAT) ont été installés.
2. Utilisez le menu Connexion dans Ldp pour effectuer les opérations de connexion et les opérations de
liaison à un contrôleur de domaine Windows Server 2003 et ultérieur.
Spécifiez les informations d’identification de l’administrateur de domaine pendant l’opération de liaison.
3. Dans le menu Options , sélectionnez Contrôles .
4. Dans la liste Load Predefined , sélectionnez Renvoyer les objets supprimés .
NOTE
Le contrôle 1.2.840.113556.1.4.417 se déplace vers la fenêtre Contrôles actifs.
5. Sous Type de contrôle , sélectionnez Ser veur et OK .

6. Dans le menu Affichage, sélectionnez Arborescence , tapez le chemin d’accès au nom du conteneur
d’objets supprimés dans le domaine où la suppression s’est produite, puis sélectionnez OK .
NOTE
Le chemin d’accès au nom est également appelé chemin d’accès DN. Par exemple, si la suppression s’est produite
dans le contoso.com domaine, le chemin d’accès DN est le chemin d’accès suivant :
cn=deleted Objects,dc=contoso,dc=com
7. Dans le volet gauche de la fenêtre, double-cliquez sur le conteneur d’objets supprimés .
NOTE
À la suite d’une requête Idap, seuls 1 000 objets sont renvoyés par défaut. Par exemple, s’il existe plus de 1 000
objets dans le conteneur Objets supprimés, tous les objets n’apparaissent pas dans ce conteneur. Si votre objet
cible n’apparaît pas, utilisez ntdsutil, puis définissez le nombre maximal à l’aide de maxpagesize pour obtenir les
résultats de la recherche.
8. Double-cliquez sur l’objet que vous souhaitez déséliser ou animer.

9. Cliquez avec le bouton droit sur l’objet que vous souhaitez animer, puis sélectionnez Modifier .
Modifiez la valeur de l’attribut isDeleted et du chemin d’accès DN dans une seule opération de
modification LDAP (Lightweight Directory Access Protocol). Pour configurer la boîte de dialogue Modifier,
suivez les étapes suivantes :
a. Dans la zone Modifier l’attribut d’entrée , tapez isDeleted. Laissez la zone Valeur vide.
b. Sélectionnez la bouton d’option Supprimer, puis sélectionnez Entrée pour effectuer la première
des deux entrées de la boîte de dialogue Liste d’entrées .
IMPORTANT
Ne sélectionnez pas Exécuter .
c. Dans la zone Attribut, tapez distinguishedName.

d. Dans la zone Valeurs , tapez le nouveau chemin d’accès DN de l’objet réanimé.
Par exemple, pour animer le compte d’utilisateur JohnDoe dans l’UO Mayberry, utilisez le chemin
DN suivant : cn= JohnDoe,ou = Mayberr y,dc = contoso,dc = com
NOTE
Si vous souhaitez réanimer un objet supprimé dans son conteneur d’origine, vous devez lui attribuer la
valeur du dernier attributKnownParent de l’objet supprimé, puis coller le chemin d’accès DN complet dans
la zone Valeurs.
e. Dans la zone Opération , sélectionnez REMPL ACER .

f. Sélectionnez Entrée .
g. Cochez la case Synchrone.
h. Cochez la case Étendue.
i. Sélectionnez EXÉCUTER .
10. Après avoir réanimé les objets, sélectionnez Contrôles dans le menu Options , sélectionnez le bouton
d’achat à supprimer (1.2.840.113556.1.4.417) de la liste des contrôles actifs .
11. Réinitialisez les mots de passe, les profils, les répertoires d’accueil et les appartenances aux groupes des
Lorsque l’objet a été supprimé, toutes les valeurs d’attribut à l’exception SID de , ObjectGUID et
LastKnownParent``SAMAccountName ont été supprimées.
12. Activez le compte réanimé dans Utilisateurs et ordinateurs Active Directory.
NOTE
L’objet réanimé possède le même SID principal qu’avant la suppression, mais l’objet doit être ajouté à nouveau aux
mêmes groupes de sécurité pour avoir le même niveau d’accès aux ressources. La première version de Windows
Server 2003 et version ultérieure ne conserve pas l’attribut sur les comptes d’utilisateur, les comptes d’ordinateur
sIDHistory et les groupes de sécurité réanimés. Windows Server 2003 et les ultérieures avec Service Pack 1
sIDHistory conservent l’attribut sur les objets supprimés.
13. Supprimez les attributs Exchange Microsoft et reconnectez l’utilisateur à la boîte aux lettres
Exchange’utilisateur.
NOTE
La réanimation des objets supprimés est prise en charge lorsque la suppression se produit sur un contrôleur de
domaine Windows Server 2003 et ultérieur. La réanimation des objets supprimés n’est pas prise en charge lorsque
la suppression se produit sur un contrôleur de domaine Windows 2000 qui est ensuite mis à niveau vers Windows
Server 2003 et ultérieur.
NOTE
Si la suppression se produit sur un contrôleur de domaine Windows 2000 dans le domaine, lastParentOf
l’attribut n’est pas rempli sur Windows Server 2003 et les contrôleurs de domaine ultérieurs.
Comment déterminer quand et où une suppression s’est produite

Lorsque des utilisateurs sont supprimés en raison d’une suppression en bloc, vous pouvez découvrir l’origine de
la suppression. Pour ce faire, procédez comme suit :
1. Pour localiser les principaux de sécurité supprimés, suivez les étapes 1 à 7 de la section Comment
supprimer manuellement les objets de la section conteneur d’un objet supprimé. Si une arborescence a
été supprimée, suivez ces étapes pour localiser un conteneur parent de l’objet supprimé.
2. Copiez la valeur de l’attribut objectGUID dans Windows presse-papiers. Vous pouvez coller cette valeur
lorsque vous entrez la commande Repadmin à l’étape 4.
3. Sur la ligne de commande, exécutez la commande suivante :
repadmin /showmeta GUID=<objectGUID> <FQDN>
Par exemple, objectGUID si le conteneur ou l’objet supprimé est 791273b2-eba7-4285-a117-

aa804ea76e95 et que le nom de domaine complet (FQDN) dc.contoso.com est , exécutez la commande
suivante :
repadmin /showmeta GUID=791273b2-eba7-4285-a117-aa804ea76e95 dc.contoso.com
La syntaxe de cette commande doit inclure le GUID de l’objet ou conteneur supprimé et le nom de sujet
du serveur à partir de qui vous souhaitez vous sourcer.
4. Dans la sortie Repadmin de la commande, recherchez la date, l’heure et le contrôleur de domaine
d’origine pour l’attribut isDeleted . Par exemple, les informations de l’attribut isDeleted apparaissent
dans la cinquième ligne de l’exemple de sortie suivant :
O RG. T IM E/ DAT
LO C . USN DC D’O RIGIN E O RG. USN E VER AT T RIB UT
134759 Default-First- 134759 Date/heure 1 objectClass

Site-Name\NA-
DC1
134760 Default-First- 134760 Date/heure 2 ou

Site-Name\NA-
DC1
134759 Default-First- 134759 Date/heure 1 instanceType

Site-Name\NA-
DC1
134759 Default-First- 134759 Date/heure 1 whenCreated

Site-Name\NA-
DC1
O RG. T IM E/ DAT
LO C . USN DC D’O RIGIN E O RG. USN E VER AT T RIB UT
134760 Default-First- 134760 Date/heure 1 isDeleted

Site-Name\NA-
DC1
134759 Default-First- 134759 Date/heure 1 nTSecurityDescr

Site-Name\NA- iptor
DC1
134760 Default-First- 134760 Date/heure 2 nom

Site-Name\NA-
DC1
134760 Default-First- 134760 Date/heure 1 lastKnownParen

Site-Name\NA- t
DC1
134760 Default-First- 134760 Date/heure 2 objectCategory

Site-Name\NA-
DC1
5. Si le nom du contrôleur de domaine d’origine apparaît en tant que GUID alpha-numérique à 32

caractères, utilisez la commande Ping pour résoudre le GUID en adresse IP et le nom du contrôleur de
domaine à l’origine de la suppression. La commande Ping utilise la syntaxe suivante :
ping -a <originating DC GUID>._msdomain controllers.<fully qualified path for forest root domain>
NOTE
L’option -a est sensible à la cas. Utilisez le nom de domaine complet du domaine racine de la forêt, quel que soit
le domaine où réside le contrôleur de domaine d’origine.
Par exemple, Contoso.com si le contrôleur de domaine d’origine réside dans un domaine de la forêt et
qu’il a un GUID 644eb7e7-1566-4f29-a778-4b487637564b, exécutez la commande suivante :
ping -a 644eb7e7-1566-4f29-a778-4b487637564b._msdomain controllers.contoso.com
La sortie renvoyée par cette commande est similaire à la suivante :
Pinging na-dc1.contoso.com [65.53.65.101] with 32 bytes of data:
Reply from 65.53.65.101: bytes=32 time<1ms TTL=128

Comment réduire l’impact des suppressions en bloc à l’avenir

Les clés pour minimiser l’impact de la suppression en bloc d’utilisateurs, d’ordinateurs et de groupes de sécurité
sont :
Assurez-vous que vous avez des sauvegardes d’état système à jour.
Contrôlez étroitement l’accès aux comptes d’utilisateur privilégiés.
Contrôlez étroitement ce que ces comptes peuvent faire.
Pratique de récupération à partir de suppressions en bloc.
Les changements d’état système se produisent tous les jours. Ces modifications peuvent inclure les éléments
suivants :
Réinitialisations de mot de passe sur les comptes d’utilisateur et les comptes d’ordinateur
Modifications apportées à l’appartenance aux groupes
Autres modifications d’attribut sur les comptes d’utilisateur, les comptes d’ordinateur et les groupes de
sécurité.
Si votre matériel ou logiciel tombe en panne, ou si votre site rencontre un autre sinistre, vous pouvez restaurer
les sauvegardes qui ont été apportées après chaque ensemble important de modifications dans chaque
domaine et site Active Directory dans la forêt. Si vous ne conservez pas les sauvegardes actuelles, vous risquez
de perdre des données ou de devoir restaurer des objets restaurés.
Microsoft recommande de prendre les mesures suivantes pour empêcher les suppressions en bloc :
1. Ne partagez pas le mot de passe des comptes d’administrateur intégrés ou autorisez le partage des
comptes d’utilisateurs d’administration courants. Si le mot de passe du compte d’administrateur intégré
est connu, modifiez-le et définissez un processus interne qui déconseille son utilisation. Les événements
d’audit pour les comptes d’utilisateurs partagés empêchent de déterminer l’identité de l’utilisateur qui
modifie Active Directory. Par conséquent, l’utilisation de comptes d’utilisateurs partagés doit être
déconseillée.
2. Il est rare que les comptes d’utilisateur, les comptes d’ordinateur et les groupes de sécurité soient
supprimés intentionnellement. C’est particulièrement vrai pour les suppressions d’arborescence.
Dissociez la possibilité pour les administrateurs de service et délégués de supprimer ces objets de la
possibilité de créer et de gérer des comptes d’utilisateurs, des comptes d’ordinateur, des groupes de
sécurité, des conteneurs d’ou et leurs attributs. Accordez uniquement aux comptes d’utilisateurs ou
groupes de sécurité les plus privilégiés le droit d’effectuer des suppressions d’arborescence. Ces comptes
d’utilisateur privilégiés peuvent inclure des administrateurs d’entreprise.
3. Accordez aux administrateurs délégués un accès uniquement à la classe d’objet que ces administrateurs
sont autorisés à gérer. Par exemple, la tâche principale d’un administrateur du service d’aide consiste à
modifier les propriétés des comptes d’utilisateurs. Il n’est pas autorisé à créer et supprimer des comptes
d’ordinateur, des groupes de sécurité ou des conteneurs d’ou. Cette restriction s’applique également pour
supprimer des autorisations pour les administrateurs d’autres classes d’objets spécifiques.
4. Testez les paramètres d’audit pour suivre les opérations de suppression dans un domaine d’atelier. Une
fois que vous êtes à l’aise avec les résultats, appliquez votre meilleure solution au domaine de production.
5. Les modifications apportées au contrôle d’accès et à l’audit sur les conteneurs qui hébergent des dizaines
de milliers d’objets peuvent faire croître considérablement la base de données Active Directory, en
particulier dans Windows 2000 domaines. Utilisez un domaine de test qui reflète le domaine de
production pour évaluer les modifications potentielles apportées à l’espace disque disponible. Vérifiez les
volumes de disque dur qui hébergent les fichiers Ntds.dit et les fichiers journaux des contrôleurs de
domaine dans le domaine de production pour obtenir de l’espace disque disponible. Évitez de définir des
modifications de contrôle d’accès et d’audit sur l’en-tête du contrôleur de réseau de domaine. Ces
modifications s’appliquent inutilement à tous les objets de toutes les classes dans tous les conteneurs de
la partition. Par exemple, évitez d’apporter des modifications à l’inscription des enregistrements DNS
(Domain Name System) et DLT (Distributed Link Tracking) dans le dossier CN=SYSTEM de la partition de
domaine.
6. Utilisez la structure d’unité d’organisation des meilleures pratiques pour séparer les comptes d’utilisateur,
les comptes d’ordinateur, les groupes de sécurité et les comptes de service, dans leur propre unité
d’organisation. Lorsque vous utilisez cette structure, vous pouvez appliquer des listes de contrôle d’accès
discrétionnaire (DACL) aux objets d’une classe unique pour l’administration déléguée. Vous pouvez
également restaurer des objets en fonction de la classe d’objet s’ils doivent être restaurés. La structure
d’unité d’organisation des meilleures pratiques est abordée dans la section Création d’une conception
d’unité d’organisation de l’article suivant :
Best Practice Active Directory Design for Managing Windows Networks
7. Testez les suppressions en bloc dans un environnement de laboratoire qui reflète votre domaine de
production. Choisissez la méthode de récupération qui vous semble logique, puis personnalisez-la pour
votre organisation. Vous pouvez identifier :
Les noms des contrôleurs de domaine dans chaque domaine qui est régulièrement backed up
L’endroit où les images de sauvegarde sont stockées
Dans l’idéal, ces images sont stockées sur un disque dur supplémentaire local à un catalogue global
dans chaque domaine de la forêt.
Les membres de l’organisation du service d’aide à contacter
La meilleure façon d’effectuer ce contact
8. La plupart des suppressions en bloc de comptes d’utilisateurs, de comptes d’ordinateurs et de groupes de
sécurité que Microsoft voit sont accidentelles. Discutez de ce scénario avec votre équipe technique et
développez un plan d’action interne. Concentrez-vous sur la détection précoce. Et renvoyez les
fonctionnalités à vos utilisateurs de domaine et à votre entreprise aussi rapidement que possible. Vous
pouvez également prendre des mesures pour empêcher les suppressions accidentelles en bloc en éditant
les listes de contrôle d’accès des unités d’organisation.
Pour plus d’informations sur l’utilisation des outils d’interface Windows pour empêcher les suppressions
accidentelles en bloc, voir Protection contre les suppressions accidentelles en bloc dans Active Directory.
Pour plus d’informations sur la prévention des suppressions accidentelles en bloc à l’aide Dsacls.exe ou
d’un script, consultez l’article suivant :
Script pour protéger les unités d’organisation contre la suppression accidentelle.
Outils et scripts qui peuvent vous aider à récupérer des suppressions

en bloc
L’utilitaire de ligne de commande Groupadd.exe lit l’attribut sur une collection d’utilisateurs memberOf dans une
ou plusieurs personnes et crée un fichier .ldf qui ajoute chaque compte d’utilisateur restauré aux groupes de
sécurité dans chaque domaine de la forêt.
Groupadd.exe détecte automatiquement les domaines et les groupes de sécurité dont les utilisateurs supprimés
étaient membres et les ajoute à ces groupes. Ce processus est expliqué plus en détail à l’étape 11 de la méthode
1.
Groupadd.exe s’exécute sur Windows Server 2003 et les contrôleurs de domaine ultérieurs.
Groupadd.exe utilise la syntaxe suivante :
groupadd / after_restore ldf_file [/ before_restore ldf_file ]
Ici, ldf_file représente le nom du fichier .ldf à utiliser avec l’argument précédent, after_restore représente la
source de données du fichier utilisateur et before_restore représente les données utilisateur de
l’environnement de production. (La source de données du fichier utilisateur est la bonne source de données
utilisateur.)
Pour obtenir Groupadd.exe, contactez les services de support technique Microsoft.
Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de
Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces
produits.
References
Pour plus d’informations sur l’utilisation de la fonctionnalité Corbeille AD incluse dans Windows Server 2008
R2, voir le Guide pas à pas de la Corbeille Active Directory.
Aucune erreur n’est disponible pour les serveurs
d’enregistrement après le clonage du contrôleur de
domaine
Cet article fournit une solution à une erreur qui se produit après le clone d’un nouveau VDC et tente de se
connecter de manière interactive.
S’applique à : Windows Server 2016, Windows Server 2019
Symptômes
Vous utilisez la fonctionnalité de clonage VDC (Virtualized Domain Controller) introduite dans Windows Server
2012. Une fois que vous clonez un nouveau VDC, vous essayez de vous connectez de manière interactive.
Toutefois, vous recevez l’erreur suivante :
Il n’existe actuellement aucun serveur d’accès disponible pour le service de demande d’accès.
Cause
Le processus de clonage a échoué et le serveur a démarré en mode de réparation des services d’annuaire
(DSRM). Il n’y a aucune indication visuelle que le contrôleur de domaine a démarré dans la gestion des données
de gestion des données dans la page de signature Ctrl+Alt+Supprim de Windows Server.
Résolution
1. Sélectionnez la flèche gauche ou appuyez sur la touche Échap.
2. Sélectionnez Autre utilisateur .
3. Tapez le nom d’utilisateur comme suit : .\administrator
4. Fournissez le mot de passe utilisateur DSRM qui est actuellement définie sur le contrôleur de domaine
source et qui a été utilisé pour cloner cet ordinateur. Ce mot de passe a été spécifié lors de la promotion
d’origine. Notez que ce mot de passe a peut-être été modifié ultérieurement à l’aide NTDSUTIL.EXE.
5. Lorsque vous vous connectez, le serveur affiche le MODE SANS ÉCHEC dans les quatre coins de l’écran.
Résoudre les problèmes qui empêchaient le clonage, supprimer l’indicateur de démarrage DSRM, puis
essayer de cloner à nouveau le contrôleur de domaine
Ce comportement visuel et l’erreur ne sont pas spécifiques au clonage. Ce comportement et cette erreur sont
spécifiques uniquement à la gestion des problèmes de gestion des problèmes de gestion des accès aux détails
des problèmes. La gestion des droits numériques en cas de DSRM est intentionnellement invoquée dans le
cadre du processus de clonage pour protéger le réseau et le domaine contre les contrôleurs de domaine
dupliqués.
Le mode de réparation des services d’annuaire était appelé mode de restauration des services d’annuaire
Windows systèmes d’exploitation.
Pour plus d’informations sur la configuration et la résolution des problèmes de VDC avec des détails et des
instructions détaillées, voir Virtualized Domain Controller Technical Reference (Level 300).
Effectuer la défragmentation hors connexion de la
base de données Active Directory
Cet article explique comment effectuer la défragmentation hors connexion de la base de données Active
Directory.
Résumé
Active Directory effectue automatiquement la défragmentation en ligne de la base de données à certains
intervalles dans le cadre du processus de garbage collection. (Par défaut, cela se produit toutes les 12 heures.) La
défragmentation en ligne ne réduit pas la taille du fichier de base de données (Ntds.dit), mais optimise le
stockage des données dans la base de données et récupère de l’espace dans le répertoire pour les nouveaux
objets.
L’utilisation d’une défragmentation hors connexion crée une nouvelle version du fichier de base de données
sans fragmentation interne. Il crée également tous les index. Selon la fragmentation du fichier de base de
données d’origine, le nouveau fichier peut être beaucoup plus petit.
Effectuer la défragmentation hors connexion de la base de données

Active Directory
Pour effectuer la défragmentation hors connexion de la base de données Active Directory, suivez les étapes
suivantes :
1. Back up Active Directory. Windows La sauvegarde du serveur prend en charge la sauvegarde d’Active
Directory en ligne. Cela se produit automatiquement lorsque vous sélectionnez l’option de sauvegarde de
tout l’ordinateur dans l’Assistant Sauvegarde, ou de manière indépendante en sélectionnant de
sauvegarder l’état du système dans l’Assistant.
2. Prenez l’une des actions suivantes :
Arrêtez les ser vices de domaine Active Director y ou l’instance LDS.
Démarrez msconfig et allez dans le volet de démarrage. Sélectionnez l’installation du système
d’exploitation que vous souhaitez configurer. Sélectionnez Coffre démarrer dans la section Options
de démarrage, puis sélectionnez l’élément de réparation Active Director y. Une fois que vous avez
cliqué sur OK, l’outil vous demande de redémarrer. Redémarrez l'ordinateur.
3. Connectez-vous au compte d’administrateur à l’aide du mot de passe défini pour le compte
d’administrateur local dans le mode sam de restauration du service d’annuaire.
4. Ouvrez une fenêtre d’invite de commandes.
5. NTDSUTIL utilise les variables d’environnement TEMP et TMP pour créer une base de données temporaire
pendant la défragmentation. Si l’espace libre de votre volume standard utilisé est inférieur à la taille de la
base de données compactée, vous recevez l’erreur suivante :
maintenance de fichiers : compacter en d:\compactDB

Lancer le mode DÉFRAGMENTATION...
Base de données source : D:\windows\NTDS\ntds.dit
Base de données cible : d:\compactDB\ntds.dit
État de la défragmentation (% achevé)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
.......................... L’opération s’est terminée avec l’erreur -1808( JET_errDiskFull, aucun espace laissé sur le
disque).
Dans ce cas, définissez les variables d’environnement TMP et TEMP sur un volume qui dispose de
suffisamment d’espace libre pour la tâche. Par exemple, utilisez les paramètres suivants :
Md d:\temp
Set tmp=d:\temp
Set temp=d:\temp
NOTE
Ce problème peut également se produire lors d’une vérification de l’intégrité de la base de données.
6. Exécutez NTDSUTIL.
7. Tapez activer les instances ntd pour sélectionner l’instance de base de données Active Directory. Utilisez le
nom de l’instance LDS si vous souhaitez compacter une base de données LDS.
8. Tapez des fichiers, puis appuyez sur Entrée.
9. Tapez des informations, puis appuyez sur Entrée. Cela affiche les informations actuelles sur le chemin
d’accès et la taille de la base de données Active Directory et de ses fichiers journaux. Notez le chemin
d’accès.
10. Établir un emplacement qui dispose d’un espace disque suffisant pour stocker la base de données
compactée.
11. compact to <drive>:\<directory> Tapez, puis appuyez sur Entrée. Dans cette commande, les espaces
réservé et représentent le chemin d’accès de l’emplacement que vous avez établi <drive> <directory> à
l’étape précédente.
NOTE
Vous devez spécifier un chemin d’accès au répertoire. Si le chemin contient des espaces, le chemin entier doit être
entre guillemets. Par exemple, tapez compact en « c:\ndossier ew».
12. Une nouvelle base de données nommée Ntds.dit ou AdamNtds.dit est créée dans le chemin d’accès que
vous avez spécifié.
13. Tapez quit, puis appuyez sur Entrée. Tapez à nouveau quitter pour revenir à l’invite de commandes.
14. Si la défragmentation réussit sans erreur, suivez Ntdsutil.exe instructions à l’écran. Supprimez tous les
fichiers journaux dans le répertoire des journaux en tapant la commande
del drive :\ pathToLogFiles \*.log suivante.
Copiez le nouveau fichier Ntds.dit ou AdamNtds.dit sur l’ancien fichier de base de données dans le
chemin d’accès actuel à la base de données que vous avez noté à l’étape 5.
NOTE
Vous n’avez pas supprimé le fichier Edb.chk.
15. Si vous avez arrêté les services de domaine Active Directory ou l’instance LDS, vous pouvez le
redémarrer maintenant.
16. Si vous travaillez en mode restauration Active Directory, démarrez msconfig et allez dans le volet de
démarrage. Sélectionnez l’installation du système d’exploitation que vous souhaitez configurer. Cliquez
pour effacer Coffre démarrage dans la section Options de démarrage. Lorsque vous cliquez sur OK,
l’outil vous demande de redémarrer. Redémarrez l'ordinateur.
Comment déplacer une arborescence SYSVOL qui
utilise FRS pour la réplication
Cet article décrit deux options pour déplacer l’arborescence du volume système (SYSVOL) sur votre contrôleur
de domaine.
Résumé
SYSVOL est un ensemble de dossiers, de points d’parse du système de fichiers et de paramètres de stratégie de
groupe répliqués par le service de réplication de fichiers (FRS). La réplication distribue une copie cohérente des
paramètres et des scripts de stratégie de groupe entre les contrôleurs de domaine dans un domaine. Les
ordinateurs membres et les contrôleurs de domaine accèdent au contenu de l’arborescence SYSVOL via deux
dossiers partagés, Sysvol et Netlogon.
Cet article explique comment déplacer l’arborescence SYSVOL et ses partages vers une lettre de lecteur logique
ou physique différente.
Cette section explique comment déplacer l’arborescence SYSVOL du dossier C:\Winnt\Sysvol vers le dossier
X:\Winnt\Sysvol. Dans cet exemple, le contrôleur de domaine est nommé DC1 et le nom de domaine est
CONTOSO.COM .
Utiliser l’Assistant Installation d’Active Directory pour rétrograder et

réentribuer le contrôleur de domaine
1. Confirmez que la réplication entrante et sortante se produit pour le service d’annuaire Active Directory et
pour l’arborescence SYSVOL.
2. Utilisez l’Assistant Installation d’Active Directory pour rétrograder le contrôleur de domaine DC1 sur le
réseau. Redémarrez DC1 immédiatement après la rétrogradation.
3. Avant de reprogrammer DC1, attendez que les événements suivants se produisent :
Tous les contrôleurs de domaine de la forêt doivent répliquer la suppression de l’objet de
paramètres du système de fichiers NTDS du contrôleur de domaine rétrogradé. Cet objet se trouve
dans la partition de configuration. L’objet paramètres NTDS est le parent des objets de connexion
Active Directory visibles dans le logiciel en ligne Sites et services Active Directory.
Tous les contrôleurs de domaine de catalogue global dans la forêt doivent répliquer la copie en
lecture seule de la partition de domaine de DC1.
4. Utilisez l’Assistant Installation d’Active Directory pour spécifier un nouveau lecteur et un nouveau chemin
d’accès sur une partition au format NTFS. La rétrogradation et la rétrogradation d’un contrôleur de
domaine est une option simple et prise en charge pour déplacer l’arborescence SYSVOL et ses partages si
les conditions suivantes sont vraies :
Un petit à moyen nombre d’objets existent dans Active Directory.
La connectivité à la vitesse du réseau local (LAN) est disponible.
Des contrôleurs de domaine supplémentaires sont disponibles dans le domaine Active Directory
concerné et le site Active Directory.
Toutefois, les promotions de l’Assistant Installation Active Directory basées sur le réseau dans les domaines avec
des bases de données Active Directory à plusieurs gigaoctets peuvent prendre entre 2 et 7 jours si la
connectivité réseau est lente.
Pour éviter les retards lors de la promotion de contrôleurs de domaine réplica qui exécutent Windows Server
2003 ou une ultérieure, vous pouvez faire des installations à partir de promotions basées sur des supports, où
l’essentiel d’Active Directory est issu d’une sauvegarde de l’état du système restaurée localement.
Pour estimer le temps nécessaire pour une promotion basée sur le réseau, comparez les heures de début et de
fin d’une promotion précédente comparable au niveau de l’étendue. Ces heures sont disponibles dans le fichier
%Systemroot%\Debug\Dcpromo.log.
Déplacer manuellement une arborescence SYSVOL existante vers un

nouvel emplacement
Dans le cycle de vie d’un contrôleur de domaine qui utilise le service de réplication de fichiers (FRS), vous de
devez peut-être déplacer l’arborescence SYSVOL vers un autre lecteur logique ou physique. Vous pouvez
déplacer l’arborescence SYSVOL pour améliorer les performances du système ou pour obtenir plus d’espace
disque disponible pour l’arborescence SYSVOL ou pour le dossier intermédiaire FRS.
Pour plus d’informations sur la modification du dossier de transit FRS à un emplacement indépendant de
l’arborescence SYSVOL, voir Comment réinitialiser le dossier de transit du service de réplication de fichiers sur
un autre lecteur logique.
Pour déplacer une arborescence SYSVOL vers un nouveau lecteur, utilisez l’une des options suivantes :
Faire une rétrogradation de l’Assistant Installation Active Directory (Dcpromo.exe) en réseau. Spécifiez un
nouveau lecteur et un nouveau chemin d’accès pour l’arborescence SYSVOL lors de la promotion.
Modifiez le Registre et déplacez manuellement l’arborescence SYSVOL vers un nouveau lecteur.
IMPORTANT
Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des
problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, veillez à suivre ces
étapes scrupuleusement. Pour une meilleure protection, sauvegardez le registre avant de le modifier. Vous pouvez alors le
restaurer en cas de problème. Pour plus d’informations sur la façon de back up et restore the registry, voir How to back
up and restore the registry in Windows.
Pour déplacer manuellement l’arborescence SYSVOL, déplacez l’arborescence SYSVOL de son lecteur et de son
chemin vers un nouveau lecteur et chemin de destination en modifiant plusieurs clés de Registre et en
réinitialisation des points d’parparage dans le système de fichiers. Pour ce faire, suivez les étapes suivantes :
1. Préparez votre contrôleur de domaine. Pour ce faire, suivez les étapes suivantes :
a. Confirmez que la réplication Active Directory entrante et sortante se produit sur le contrôleur de
domaine.
b. Confirmez que la réplication FRS entrante et sortante du jeu de réplicas SYSVOL se produit sur le
contrôleur de domaine.
c. Désactiver les programmes antivirus ou d’autres services qui créent des verrous sur des fichiers
ou des dossiers qui résident dans l’arborescence SYSVOL.
d. Back up the system state of the domain controller. Back up the file system part of the SYSVOL tree
on the domain controller so that you can return the computer to its current configuration if you
experience problems with the relocalisation process.
e. Arrêtez le frs.
2. Utilisez Windows Explorer ou un programme équivalent pour copier l’arborescence de domaine SYSVOL
d’origine dans le Presse-papiers.
Par exemple, si l’arborescence de domaine SYSVOL se trouve dans le dossier C:\Winnt\Sysvol, cliquez
pour sélectionner ce dossier, cliquez sur Modifier dans la barre de menus, puis cliquez sur Copier .
3. Utilisez Windows Explorer ou un programme équivalent pour coller le contenu du Presse-papiers dans le
nouveau chemin d’accès.
Par exemple, pour déplacer l’arborescence SYSVOL vers le dossier, cliquez pour sélectionner ce dossier,
cliquez sur Modifier, puis X:\Winnt\Sysvol cliquez sur Coller .
Le dossier parent de l’arborescence SYSVOL déplacée peut être modifié. Toutefois, nous vous
recommandons de conserver le même chemin d’accès relatif pour l’arborescence SYSVOL déplacée. Par
exemple, si l’arborescence SYSVOL se trouvait à l’origine dans le dossier et que vous souhaitez déplacer
l’arborescence SYSVOL sur le lecteur logique X, créez un dossier t, puis collez l’arborescence
C:\Winnt\Sysvol SYSVOL dans ce X:\Winn dossier.
4. Utilisez les Ldp.exe ou ADSIedit.msc pour modifier la valeur de l’attribut FRSRootPath dans Active
Directory. L’attribut FRSRootPath doit refléter le nouveau lecteur racine du jeu de réplicas et le dossier
que vous avez spécifié à l’étape 3. Dans cet exemple, vous devez modifier l’attribut FRSRootPath comme
suit :
Chemin d’accès DN :
cn=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=DC1,OU=Domain
Controller,DC=CONTOSO.COM
Valeur FRSRootPath : X:\Winnt\Sysvol\Domain
5. Utilisez les Ldp.exe ou ADSIedit.msc pour modifier la valeur de l’attribut FRSStagingPath. Cet attribut doit
refléter le nouveau chemin d’accès intermédiaire, y compris le nouveau lecteur et le nouveau dossier que
vous avez sélectionnés à l’étape 3.
Chemin d’accès DN :
cn=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=DC1,OU=Domain
Controller,DC=CONTOSO.COM
Valeur FRSStagingPath : X:\Winnt\Sysvol\Staging\Domain
6. Modifiez le Registre pour qu’il reflète le nouveau dossier et lecteur de transit. Pour ce faire, suivez ces
étapes.
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez regedt32, puis cliquez sur OK.
b. Recherchez, puis cliquez avec le bouton droit sur la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
c. Cliquez avec le bouton droit sur la valeur SYSVOL, puis cliquez sur Modifier. Tapez un nouveau chemin
d’accès pour la racine du jeu de réplicas SYSVOL. Par exemple, tapez X:\Winnt\sysvol\sysvol .
7. Configurez FRS pour une restauration non faisant autorité du jeu de réplicas SYSVOL. Pour ce faire,
a. Recherchez et sélectionnez la sous-clé de Registre suivante :
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
at Startup
b. Cliquez avec le bouton droit sur la valeur BurFlags, puis sélectionnez Modifier . Définissez la
valeur sur D2 hexadécimal s’il existe d’autres contrôleurs de domaine dans le même domaine.
Définissez la valeur BurFlags sur D4 hexadécimal si un seul contrôleur de domaine existe dans
le domaine.
IMPORTANT
Ne redémarrez pas FRS maintenant.
NOTE
Si le contrôleur de domaine héberge des racines ou des liens DFS répliqués par FRS, vous pouvez définir la clé de
Registre BurFlags spécifique au jeu de réplicas pour éviter une panne temporaire du service et une réplication de
données dans des racines ou des liaisons DFS répliquées par FRS.
Pour plus d’informations, voir Utiliser la clé de Registre BurFlags pour réinitialiserle service de réplication
de fichiers.
8. Appliquez les autorisations par défaut au nouveau chemin d’accès de l’arborescence SYSVOL. Pour ce
faire, copiez le texte suivant, puis collez-le dans Bloc-notes fichier :
[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$ »
Revision=1
[Description du profil]
Description=perms par défaut pour sysvol
[Sécurité des fichiers]
;" %SystemRoot%\SYSVOL »,0,"D:AR(A;OICI;FA;; ; BA) »
; ---------------------------------------------------------------------------------------------
; Sysvol. CETTE VARIABLE D’ENVIRONNEMENT DOIT ÊTRE DÉFINIE!!!!!!!!!!!!!!!!!!!!!!!!!
; ---------------------------------------------------------------------------------------------
« %Sysvol% »,2,"D:P(A; CIOI; GRGX;;; AU)(A; CIOI; GRGX;; ; SO)(A; CIOI; GA;;; BA)(A; CIOI; GA;;; SY)(A;
CIOI; GA;;; CO) »
« %Sysvol%\domain\policies »,2,"D:P(A; CIOI; GRGX;; ; AU)(A; CIOI; GRGX;; ; SO)(A; CIOI; GA;;; BA)(A;
CIOI; GA;;; SY)(A; CIOI; GA;;; CO)(A; CIOI; GRGWGXSD;;; PA) »
9. Utilisez les paramètres suivants pour enregistrer le contenu du fichier Bloc-notes que vous avez créé à
l’étape 8 :
Nom de fichier : %systemroot%\security\templates\sysvol.inf
Type d’enregistrer : Tous les fichiers
Codage : Unicode
NOTE
La variable d’environnement SYSVOL doit être définie pour pointer vers le nouvel emplacement. Sinon, la
commande Secedit ne s’exécute pas correctement.
10. Importez le modèle de sécurité SYSVOL. Pour ce faire, sélectionnez Démarrer, Exécuter, tapez cmd, puis
sélectionnez OK. Tapez ce qui suit, puis appuyez sur Entrée :
secedit /configure /cfg %systemroot%\security\templates\sysvol.inf /db
%systemroot%\security\templates\sysvol.db /overwrite
11. Utilisez la commande pour mettre à jour les points d’parse dans le système de fichiers afin de refléter le
nouveau chemin d’accès de Linkd l’arborescence SYSVOL. Par exemple, si votre contrôleur de domaine
se trouve dans le domaine et que l’arborescence SYSVOL se trouve dans le dossier, tapez les commandes
suivantes à l’invite de commandes sur votre contrôleur de CONTOSO.COM X:\Windows\Sysvol domaine.
Appuyez sur Entrée après chaque commande.
linkd X:\Winnt\Sysvol\Sysvol\CONTOSO.COM X:\Winnt\Sysvol\Domain

linkd X:\Winnt\Sysvol\Staging areas\CONTOSO.COM X:\Winnt\Sysvol\Staging\Domain
NOTE
Assurez-vous que l’arborescence du répertoire SYSVOL est créée avant d’exécuter la commande Linkd. La
commande échoue s’il existe des données dans CONTOSO.COM répertoire ou sous-répertoires.
12. Redémarrez FRS.

13. Recherchez dans le journal des événements FRS des événements qui indiquent que le jeu de réplicas est
joint et que le dossier SYSVOL a été modifié.
14. Sur le contrôleur de domaine, utilisez la commande ou la commande d’affichage net pour vérifier que le
contrôleur de domaine a partagé les net logon dossiers Netlogon et Sysvol. Si les dossiers partagés
n’existent pas, suivez les étapes suivantes :
a. Si la valeur de la
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\Sysvolready sous-clé
de Registre est 1, redémarrez le service Netlogon. Si cette valeur de sous-clé est 0, allez à l’étape c.
b. Recherchez de nouveau les dossiers partagés. Si les dossiers ne sont toujours pas disponibles,
tapez la commande à l’invite de commandes, puis nltest /dbflag:2080FFFF appuyez sur Entrée :
Recherchez les erreurs dans le %Systemroot%\Debug\Netlogon.log fichier.
c. Si la valeur de la sous-clé de Registre est 0, ne définissez pas la valeur de
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\Sysvolready Registre
sur 1. Examinez les journaux de débogage FRS dans le dossier pour vérifier que la réplication FRS
entrante et sortante %Systemroot%\Debug se produit.
15. Redémarrez les services que vous avez arrêtés à l’étape 1c.
RodC réplique les mots de passe lorsqu’il a reçu des
autorisations incorrectes dans Windows Server
Cet article traite d’un problème dans lequel RODC réplique les mots de passe lorsqu’il se fait accorder des
autorisations incorrectes dans Windows Server.
S’applique à : Windows Server 2016, Windows Server 2012 R2
Symptôme
Normalement, les contrôleurs de domaine en lecture seule répliquent uniquement les mots de passe utilisateur
pour les comptes d’utilisateur qui sont membres du groupe de réplication de mot de passe RODC autorisé ou
qui sont répertoriés dans l’attribut msDS-RevealOnDemandGroup du compte RODC.
Toutefois, pour certains comptes d’utilisateur qui ne sont pas membres du groupe de réplication de mot de
passe RODC autorisé ou qui ne sont pas répertoriés dans l’attribut msDS-RevealOnDemandGroup du compte
RODC, vous pouvez trouver que les mots de passe des comptes authentifiés par le rodc peuvent être mis en
cache par le RODC.
Par exemple, lorsque vous comparez la sortie de la propriété Stratégie de réplication de mot de passe avancée à
l’aide des utilisateurs et ordinateurs Active Directory et de la sortie de , les entrées répertoriées diffèrent entre
les repadmin /prp view RODC_name reveal deux.
Cause
Ce problème est dû à une configuration d’autorisation incorrecte.
Par défaut, le Enterprise contrôleurs de domaine qui contient uniquement des DCS accessibles en écriture
dispose de l’autorisation Réplication des changements de répertoire sur la partition de domaine. Par exemple,
sur « DC=contoso,DC=com » dans Active Directory.
Toutefois, lorsque le problème se produit, le problème RODC dispose également de l’autorisation Réplication du
répertoire Change Tout sur le domaine, car elle a été accordée par un administrateur soit au groupe
contrôleurs de domaine Enterprise en lecture seule, soit à l’objet RODC directement ou indirectement via une
autre appartenance au groupe.
Normalement, les rodcs répliquent uniquement les mots de passe utilisateur si les comptes d’utilisateur sont
membres du groupe de réplication de mot de passe RODC autorisé ou sont répertoriés dans l’attribut msDS-
RevealOnDemandGroup du compte RODC.
Avec l’autorisation Réplication des changements de répertoire, tous les attributs utilisateur, y compris les mots
de passe, sont répliqués du dc source vers le RODC comme s’il s’agit d’un code RWDC (Read Write DC) normal.
Résolution
Pour résoudre ce problème, modifiez l’autorisation Réplication du répertoire change toutes les autorisations
accordées à l’objet Enterprise Contrôleurs de domaine en lecture seule en réplication des changements de
répertoire.
Suivez ces étapes pour valider les autorisations et déterminer d’où viennent les mauvaises autorisations.
Étape 1
Utilisez LDP pour afficher les autorisations « contrôler l’accès » sur le domaine. Pour ce faire, vous pouvez suivre
les étapes suivantes :
1. Exécutez la LDP.exe sur un contrôleur de domaine.
2. Connecter l’arborescence (par exemple, DC=contoso,DC=com).
3. Cliquez avec le bouton droit sur le nœud DC=contoso,DC=com, sélectionnez Avancé, puis sélectionnez
Descripteur de sécurité.
4. Choisissez l’option Vidage de texte pour un affichage texte des autorisations ou laissez-la désactivée pour
obtenir un éditeur de sécurité GUI.
5. Vérifiez les autorisations pour vous assurer que le groupe Enterprise contrôleurs de domaine en lecture
seule dispose uniquement de l’autorisation Réplication des modifications de réper toire.
Étape 2
Vérifiez les appartenances aux groupes du rodc pour déterminer si la réplication des changements de
répertoire tout est accordée par le biais d’un autre groupe.
Pour obtenir la véritable appartenance au RODC, vous pouvez utiliser une requête pour l’attribut TokenGroups
afin de récupérer la liste de groupes effective de l’utilisateur à l’aide de l’outil LDP.
Veillez à sélectionner l’étendue de base et à ajouter l’attribut requis. Lorsque vous copiez la recherche sur un
utilisateur individuel, vous obtenez la liste de cet utilisateur. Si l’utilisateur fait partie de nombreux groupes, vous
devez étendre la quantité de données imprimées par LDP dans la fenêtre de droite, sélectionner
Options\Général dans le menu et ajuster les chars par champ à une valeur supérieure :
Étape 3
Sur Windows Server 2008 R2, Windows 7, Windows Server 2008 ou Windows Vista, vérifiez si vous rencontrez
le problème décrit dans l’article suivant :
Le logiciel en cache MMC « Utilisateurs et ordinateurs Active Directory » n’indique pas tous les comptes dont les
mots de passe sont mis en cache sur le RODC dans Windows
Étape 4
Confirmez la cohérence des propriétés du compte d’ordinateur du RODC sur tous les contrôleurs de domaine du
domaine.
L’une des méthodes consiste à exporter les métadonnées de réplication du compte d’ordinateur du RODC à
partir de repadmin tous les contrôleurs de domaine. Pour ce faire, exécutez la commande suivante :
repadmin /showobjmeta *<dn of RODC account>' > rodc_meta.txt
Étape 5
Comme à l’étape 4, confirmez la cohérence du groupe de réplication de mot de passe RODC autorisé et de tout
autre groupe configuré sur l’attribut msDS-RevealOnDemandGroup pour voir si les mots de passe
d’utilisateur mis en cache incorrectement peuvent être expliqués par l’appartenance incohérente au groupe sur
différents DCS qui peuvent être causées par un problème de réplication.
Étape 6
Vérifiez que les utilisateurs dont les mots de passe sont mis en cache par le RODC ne sont pas accidentellement
membres d’un groupe configuré pour mettre en cache leurs mots de passe.
NOTE
La MMC collecte les informations de stratégie de réplication de mot de passe à partir de n’importe quel contrôleur de
domaine (même le contrôleur de domaine en cours), tandis que la commande interroge toujours un contrôleur de
domaine en repadmin /prp lecture-écriture.
S’il existe des incohérences de réplication entre le RODC et un dc RW, cela peut expliquer la différence de sortie
de ces deux utilitaires/méthodes.
Syskey.exe'utilitaire n’est plus pris en charge dans
Windows 10, Windows Server 2016 et versions
ultérieures
Windows 10, version 1709, Windows Server, version 2004 et versions ultérieures de Windows ne peuvent plus
syskey.exe utilitaire.
S’applique à : Windows 10 - toutes les éditions, Windows Server 2019, Windows Server 2016
Détail des modifications

Les modifications suivantes sont apportées :
L’utilitaire syskey.exe n’est plus inclus dans Windows.
Windows ne demande jamais de mot de passe syskey au démarrage.
Windows ne prendra plus en charge l’installation d’un contrôleur de domaine Active Directory à l’aide
d’Install-From-Media (IFM) qui a été chiffré en externe par l’utilitaire syskey.exe.
Si un système d’exploitation a été chiffré en externe par l’utilitaire syskey.exe, vous ne pouvez pas le mettre à
niveau vers Windows 10 version 1709, Windows Server version 2004 ou une version ultérieure de Windows.
Si vous souhaitez utiliser la sécurité du système d’exploitation au démarrage, nous vous recommandons
d’utiliser BitLocker ou des technologies similaires au lieu de l’utilitaire syskey.exe de démarrage.
Si vous utilisez un support IFM Active Directory pour installer des contrôleurs de domaine Active Directory
réplicas, nous vous recommandons d’utiliser BitLocker ou d’autres utilitaires de chiffrement de fichiers pour
protéger tous les supports IFM.
Pour mettre à niveau un système d’exploitation chiffré en externe par l’utilitaire syskey.exe vers Windows 10 RS3
ou Windows Server 2016 RS3, le système d’exploitation doit être configuré pour ne pas utiliser de mot de passe
de clé syskey externe. Pour plus d’informations, voir l’étape 5 de l’utilisation de l’utilitaire SysKeypour sécuriser
la base de données Sécurité Windows Accounts Manager.
Syskey est une clé de chiffrement racine interne Windows qui est utilisée pour chiffrer d’autres données
sensibles sur l’état du système d’exploitation, telles que les hages de mot de passe de compte d’utilisateur.
L’utilitaire SysKey peut être utilisé pour ajouter une couche supplémentaire de protection, en chiffrant la clé
syskey pour utiliser un mot de passe externe. Dans cet état, le système d’exploitation bloque le processus de
démarrage et invite les utilisateurs à obtenir le mot de passe (de manière interactive ou en lisant à partir d’une
disquette).
Malheureusement, la clé de chiffrement syskey et l’utilisation de syskey.exe ne sont plus considérés comme
sécurisés. La clé Syskey est basée sur un chiffrement faible qui peut facilement être rompu dans les temps
modernes. Les données protégées par la clé syskey sont limitées et ne couvrent pas tous les fichiers ou données
sur le volume du système d’exploitation. Lsyskey.exe'utilitaire a également été connu pour être utilisé par les
pirates informatiques dans le cadre des attaques de ransomware.
Active Directory a précédemment pris en charge l’utilisation d’une clé syskey chiffrée en externe pour les
médias IFM. Lorsqu’un contrôleur de domaine est installé à l’aide d’un support IFM, le mot de passe de clé
syskey externe doit également être fourni. Malheureusement, cette protection subit les mêmes failles de
sécurité.
Référence
L’utilitaire syskey.exe et sa prise en charge sous-jacente dans le système d’exploitation Windows a été introduit
pour la première fois dans Windows 2000 et est backporté vers Windows NT 4.0. Pour plus d’informations, voir
Comment utiliser l’utilitaire SysKeypour sécuriser la base de données Sécurité Windows Accounts Manager .
Les ID d’événement 13552 et 13555 sont enregistrés
dans le journal du service de réplication de fichiers
sur Windows de domaine basé sur Windows de
domaine
Cet article permet de résoudre un problème dans lequel le dossier SYSVOL n’est pas répliqué entre les
contrôleurs de domaine qui exécutent Windows Server 2012 R2, Windows Server 2012, Windows Server 2008
R2, Windows Server 2008 ou Windows Server 2003.
Symptômes
Ce problème peut se produire dans l’une des conditions suivantes sur un contrôleur de domaine qui exécute
Windows Server :
Vous modifiez la configuration des périphériques système ou la configuration des périphériques système
échoue.
Une altération se produit dans la base de données du service de réplication de fichiers (FRS).
Informations sur l’événement
Les deux événements ressemblent à ce qui suit :
Événement 13555 :
Le service de réplication de fichiers est dans un état d’erreur
Événement 13552 :
Le service de réplication de fichiers ne peut pas ajouter cet ordinateur au jeu de réplicas suivant : « VOLUME
DU SYSTÈME DE DOMAINE (SYSVOL SHARE) »
Ces journaux des événements indiquent que le dossier SYSVOL n’est pas répliqué entre les contrôleurs de
domaine. Par conséquent, ce problème entraîne des paramètres de stratégie de groupe incohérents et le résultat
incorrect de la stratégie est définie sur chaque ordinateur client.
Cause
Ce problème se produit car NTFS détecte une mise à jour du microprogramme en tant que modification de
configuration sur les disques, puis modifie l’ID du journal. Par conséquent, un ID de fichier pour les données
dans la base de données FRS ne correspond pas à l’ID de fichier pour les données dans la base de données de
journal du numéro de séquence de mise à jour (USN).
IMPORTANT
Suivez attentivement les étapes de cette section. Des problèmes graves peuvent se produire si vous modifiez le Registre
de façon incorrecte. Avant de modifier le Registre, sauvegardez-le pour restauration en cas de problèmes.
Pour contourner ce problème, sur les contrôleurs de domaine enregistrés, suivez les étapes suivantes :
1. Prenez une sauvegarde complète ou de l’état du système pour chaque contrôleur de domaine.
2. Arrêtez le frs. Pour ce faire, à l’invite de commandes sur chaque contrôleur de domaine, tapez la
commande suivante, puis appuyez sur Entrée : net stop ntfrs
NOTE
À ce stade, sélectionnez un contrôleur de domaine de référence qui peut être basé sur la connectivité et les
ressources serveur physiques. Ce contrôleur de domaine sera le « contrôleur de domaine de référence » dans
toutes les étapes suivantes.
3. Supprimez les fichiers des trois dossiers suivants pour initialiser le frs sur le contrôleur de domaine de
référence.
Ne supprimez pas les trois dossiers. Supprimez les sous-dossiers et les fichiers dans ces trois dossiers :
%systemroot%\ntfrs\jet
%systemroot%\sysvol\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
%systemroot%\sysvol\staging\domainIf these folders and files aren’t shown, perform the additional
steps to show the hidden files or folders.
4. Forcer la synchronisation de FRS sur le contrôleur de domaine de référence. Pour cela, procédez comme
suit :
a. Ouvrez l’Éditeur du Registre et recherchez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\NTFRS\Parameters\Backup/Restore\Process at
Startup
b. Cliquez avec le bouton droit sur l’entrée BurFlags, puis cliquez sur Modifier.
c. Dans la zone Données de la valeur, tapez D4, puis cliquez sur OK.
d. Fermez l’Éditeur du Registre.
5. À l’invite de commandes sur le contrôleur de domaine de référence, exécutez la commande suivante pour
redémarrer le service FRS : net start ntfrs
NOTE
Les étapes 6 à 10 doivent être réalisées uniquement sur d’autres contrôleurs de domaine.
6. Téléchargez et installez l’outil PsTools sur d’autres contrôleurs de domaine. Cet outil contient les outils en
ligne de commande PsExec qui peuvent être utilisés pour supprimer des dossiers sous le dossier SYSVOL.
7. Supprimez des fichiers dans les trois dossiers ci-dessous pour initialiser le frs sur d’autres contrôleurs de
domaine.
Ne supprimez pas les trois dossiers. Supprimez les sous-dossiers et les fichiers dans les trois dossiers
suivants :
%systemroot%\ntfrs\jet
%systemroot%\sysvol\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
%systemroot%\sysvol\staging\domainIf these folders and files aren’t shown, perform the additional
steps to show the hidden files or folders.
8. Supprimez les dossiers suivants sous le chemin d’accès « %systemroot%\sysvol\domain » :
%systemroot%\sysvol\domain\policies
%systemroot%\sysvol\domain\scripts
%systemroot%\sysvol\domain\policies_NTFRS_ xxxxxxx
%systemroot%\sysvol\domain\scripts_NTFRS_ xxxxxxx
%systemroot%\sysvol\domain\NtFrs_PreExisting__See_Evntlog
NOTE
« xxxxxxx » est un espace réservé qui représente des caractères alphanumériques. Ignorez cette étape s’il n’existe
pas de tels dossiers et fichiers.
En outre, si les dossiers et les fichiers ne peuvent pas être supprimés, suivez ces étapes pour les
supprimer à l’aide de l’outil PsExec.
Étapes pour supprimer des dossiers et des fichiers à l’aide de l’outil PsExec :
a. Exécutez l’invite de commandes avec des droits d’administration.
b. Changez le répertoire actuel en lecteur où se trouve les fichiers d’installation de l’outil PsTools (par
exemple, exécutez cd c:\PsTools).
c. Exécutez la commande suivante : Psexec.exe -i -s cmd .
d. À l’invite de commandes, tapez rd /s pour supprimer les fichiers et dossiers suivants sous le dossier
SYSVOL (par exemple, exécutez rd %systemroot%\sysvol\domain\policies /s) :
%systemroot%\sysvol\domain\policies
%systemroot%\sysvol\domain\scripts
%systemroot%\sysvol\domain\policies_NTFRS_ xxxxxxx
%systemroot%\sysvol\domain\scripts_NTFRS_ xxxxxxx
%systemroot%\sysvol\domain\NtFrs_PreExisting__See_Evntlog
NOTE
« xxxxxxx » est un espace réservé qui représente des caractères alphanumériques. Ignorez cette étape s’il n’existe
pas de tels dossiers et fichiers.
9. Forcer la synchronisation de FRS sur d’autres contrôleurs de domaine. Pour cela, procédez comme suit :
a. Ouvrez l’Éditeur du Registre et recherchez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\NTFRS\Parameters\Backup/Restore\Process at
Startup
b. Cliquez avec le bouton droit sur l’entrée BurFlags, puis cliquez sur Modifier.
c. Dans la zone Données de la valeur, tapez D2, puis cliquez sur OK.
10. À l’invite de commandes, exécutez la commande suivante pour redémarrer FRS sur d’autres contrôleurs
de domaine : net start ntfrs
11. Confirmez la réplication.
Les entrées de journal « Erreur » ou « Avertissement » ne seront plus enregistrées dans le journal des
événements. Si la réplication a réussi, l’ID d’événement 13516 est enregistré.
Vérifiez la cohérence en comparant les fichiers et dossiers des dossiers SYSVOL entre tous les
contrôleurs de domaine.
12. Redémarrez le service FRS sur le contrôleur de domaine de référence en exécutant la commande suivante
: net stop ntfrs && net start ntfrs
NOTE
Le contrôleur de domaine avec « BurFlags = D4 » fonctionne comme contrôleur de domaine de référence jusqu’à ce
que le service soit redémarré. La valeur de l’entrée BurFlags est réinitialisée en redémarrage de FRS.
Pour les contrôleurs de domaine qui ont « BurFlags = D2 », la valeur de l’entrée BurFlags est également réinitialisée
automatiquement en redémarrage de FRS.
Après avoir terminé toutes les étapes, consultez le journal des événements FRS. Les ID d’événement 13553,
13554 et 13516 sont enregistrés en quelques minutes. Ces journaux indiquent que la réplication SYSVOL se
termine correctement.
Statut
Microsoft a confirmé qu’il s’agit d’un problème dans les produits Microsoft répertoriés dans la section «
S’applique à ».
Affichez les fichiers et dossiers masqués dans Windows Explorer :
1. Dans Windows’explorateur, dans le menu Outils, cliquez sur Options de dossier.
2. Sous l’onglet Affichage, activez l’option Afficher les fichiers et dossiers masqués.
NOTE
Dans Windows Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2, activez l’option Afficher les
fichiers, dossiers et lecteurs masqués dans l’onglet Affichage.
Une autorité de certification ne peut pas utiliser un
modèle de certificat
Cet article fournit une solution à un problème dans lequel un modèle de certificat ne peut pas charger et les
demandes de certificat échouent à l’aide du même modèle.
Résumé
Lorsque les services de certificat démarrent sur une autorité de certification, un modèle de certificat ne peut pas
charger et les demandes de certificat échouent à l’aide du même modèle.
Le comportement se produit car le groupe Utilisateurs authentifiés est supprimé de la liste de contrôle d’accès
(ACL) du modèle. Le groupe Utilisateurs authentifiés se trouve sur une ACL de modèle, par défaut. (L’ac elle-
même est incluse dans ce groupe.) Si le groupe Utilisateurs authentifiés est supprimé, l’autorité de certification
(entreprise) elle-même ne peut plus lire le modèle dans Active Directory, et c’est pourquoi les demandes de
certificats peuvent échouent.
Si un administrateur souhaite supprimer le groupe Utilisateurs authentifiés, chaque compte d’ordinateur de
l’ac.ca doit être ajouté aux ACA de modèle et avoir la valeur Lecture.
Si des utilisateurs authentifiés ont été supprimés des listes de sécurité d’un modèle, les erreurs suivantes
peuvent être observées au démarrage de l’ac et lorsqu’un certificat est demandé par rapport au modèle.
Erreurs observées en cas d’échec de l’inscription

Pour le client :
Inscription au moyen d’une page Web :
Demande de certificat refusée

Votre demande de certificat a été refusée.
Pour plus d’informations, contactez votre administrateur. Inscription à l’aide de la console MMC
(Microsoft Management Console) : Assistant Demande de certificat : l’autorité de certification a rejeté
la demande. Erreur non spécifiée.
Pour l’ac :
Type d’événement : Avertissement

Event Source:CertSvc
Catégorie d’événement :Aucun
Date : <DateTime>
Heure : <DateTime>
Utilisateur : N/A
Ordinateur : MUSCIEN
Description :
Les services de certificat ont rejeté la demande 9, car le modèle de certificat demandé n’est pas pris
en charge par cette ac. 0x80094800 (-2146875392). La demande était pour TED\administrator.
Informations supplémentaires : Refusé par le module de stratégie. La demande était pour le modèle
de certificat ( <template name> ) qui n’est pas pris en charge par la stratégie des services de
certificats.
Erreur sur l’ac au démarrage des services de certificats

Type d’événement : Erreur
Event Source:CertSvc
Catégorie d’événement :Aucun
Date : <DateTime>
Heure : <DateTime>
Utilisateur : N/A
Ordinateur : MUSCIEN
Description :
Le module de stratégie « Enterprise module de stratégie autonome » a consigné l’erreur suivante : Le
modèle de certificat <template name> n’a pas pu être chargé. Élément in trouvé. 0x80070490 (WIN32 :
1168).
Back up the recovery agent Encrypting File System
(EFS) private key in Windows
Cet article explique comment back up the recovery agent Encrypting File System (EFS) private key on a
computer.
S’applique à : Windows 7 Service Pack 1, Windows Server 2012 R2
Résumé
Utilisez la clé privée de l’agent de récupération pour récupérer des données dans les situations où la copie de la
clé privée EFS située sur l’ordinateur local est perdue. Cet article contient des informations sur l’utilisation de
l’Assistant Exportation de certificat pour exporter la clé privée de l’agent de récupération à partir d’un ordinateur
membre d’un groupe de travail et d’un contrôleur de domaine Windows Server 2003 basé sur Windows 2000,
basé sur Windows Server 2008 ou Windows Server 2008 R2.
Introduction
Cet article explique comment back up the recovery agent Encrypting File System (EFS) private key in Windows
Server 2003, in Windows 2000, in Windows XP, in Windows Vista, in Windows 7, in Windows Server 2008, and
in Windows Server 2008 R2. Vous pouvez utiliser la clé privée de l’agent de récupération pour récupérer des
données dans les situations où la copie de la clé privée EFS située sur l’ordinateur local est perdue.
Vous pouvez utiliser EFS pour chiffrer des fichiers de données afin d’empêcher tout accès non autorisé. EFS
utilise une clé de chiffrement qui est générée dynamiquement pour chiffrer le fichier. La clé de chiffrement de
fichier (FEK) est chiffrée avec la clé publique EFS et est ajoutée au fichier en tant qu’attribut EFS nommé Data
Decryption Field (DDF). Pour déchiffrer le FEK, vous devez avoir la clé privée EFS correspondante de la paire de
clés publique/privée. Après avoir déchiffré le FEK, vous pouvez utiliser le FEK pour déchiffrer le fichier.
Si votre clé privée EFS est perdue, vous pouvez utiliser un agent de récupération pour récupérer des fichiers
chiffrés. Chaque fois qu’un fichier est chiffré, le FEK est également chiffré avec la clé publique de l’agent de
récupération. Le FEK chiffré est joint au fichier avec la copie chiffrée avec votre clé publique EFS dans le champ
de récupération de données (DRF). Si vous utilisez la clé privée de l’agent de récupération, vous pouvez
déchiffrer le FEK, puis déchiffrer le fichier.
Par défaut, si un ordinateur exécutant Microsoft Windows 2000 Professional est membre d’un groupe de travail
ou d’un domaine Microsoft Windows NT 4.0, l’administrateur local qui se connecte d’abord à l’ordinateur est
désigné comme agent de récupération par défaut. Par défaut, si un ordinateur exécutant Windows XP ou
Windows 2000 est membre d’un domaine Windows Server 2003 ou d’un domaine Windows 2000, le compte
Administrateur intégré sur le premier contrôleur de domaine du domaine est désigné comme agent de
récupération par défaut.
Un ordinateur qui exécute Windows XP et qui est membre d’un groupe de travail n’a pas d’agent de
récupération par défaut. Vous devez créer manuellement un agent de récupération local.
IMPORTANT
Après avoir exporté la clé privée vers une disquette ou un autre support amovible, stockez la disquette ou le support
dans un emplacement sécurisé. Si quelqu’un accède à votre clé privée EFS, cette personne peut accéder à vos données
chiffrées.
Exporter la clé privée de l’agent de récupération à partir d’un ordinateur membre d’un groupe de travail
Pour exporter la clé privée de l’agent de récupération à partir d’un ordinateur membre d’un groupe de travail,
1. Connectez-vous à l’ordinateur à l’aide du compte d’utilisateur local de l’agent de récupération.
2. Cliquez sur Démarrer, puis sur Exécuter, tapez mmc, puis cliquez sur OK.
3. Dans le menu Fichier , cliquez sur Ajouter/Supprimer un composant logiciel enfichable . Cliquez
ensuite sur Ajouter Windows Server 2003, dans Windows XP ou Windows 2000. Vous pouvez également
cliquer sur OK dans Windows Vista, Windows 7, Windows Server 2008 ou Windows Server 2008 R2.
4. Sous Les logiciels en snap-in autonomes disponibles, cliquez sur Cer tificats, puis cliquez sur
Ajouter.
5. Cliquez sur Mon compte d’utilisateur, puis sur Terminer.
6. Cliquez sur Fermer, puis sur OK dans Windows Server 2003, Windows XP ou Windows 2000. Vous
pouvez également cliquer sur OK dans Windows Vista, Windows 7, Windows Server 2008 ou Windows
Server 2008 R2.
7. Double-cliquez sur Cer tificats - Utilisateur actuel, double-cliquez sur Personnel, puis double-
cliquez sur Cer tificats.
8. Recherchez le certificat qui affiche les mots « File Recovery » (sans les guillemets) dans la colonne
Intended Purposes.
9. Cliquez avec le bouton droit sur le certificat que vous avez localisé à l’étape 8, pointez sur Toutes les
tâches, puis cliquez sur Expor ter . L’Assistant Exportation de certificat démarre.
10. Cliquez sur Suivant .
11. Cliquez sur Oui, expor tez la clé privée, puis cliquez sur Suivant.
12. Cliquez sur Informations personnelles Exchange - PKCS #12 (. PFX).
NOTE
Nous vous recommandons vivement de cliquer également pour activer une protection forte (nécessite la case à
cocher IE 5.0, NT 4.0 SP4 ou supérieure pour protéger votre clé privée contre tout accès non autorisé).
Si vous cliquez pour sélectionner la case à cocher Supprimer la clé privée si l’exportation réussit, la clé
privée est supprimée de l’ordinateur et vous ne pourrez pas déchiffrer les fichiers chiffrés.
14. Spécifiez un mot de passe, puis cliquez sur Suivant .
15. Spécifiez un nom de fichier et un emplacement où vous souhaitez exporter le certificat et la clé privée,
puis cliquez sur Suivant .
NOTE
Nous vous recommandons de sauvegarder le fichier sur un disque ou sur un périphérique multimédia amovible,
puis de stocker la sauvegarde à un emplacement où vous pouvez confirmer la sécurité physique de la sauvegarde.
16. Vérifiez les paramètres affichés dans la page Fin de l’Assistant Exportation de certificat, puis cliquez sur
Terminer.
Exporter la clé privée de l’agent de récupération de domaine
Le premier contrôleur de domaine d’un domaine contient le profil d’administrateur intégré qui contient le
certificat public et la clé privée de l’agent de récupération par défaut du domaine. Le certificat public est importé
dans la stratégie de domaine par défaut et est appliqué aux clients de domaine à l’aide de la stratégie de groupe.
Si le profil Administrateur ou si le premier contrôleur de domaine n’est plus disponible, la clé privée utilisée pour
déchiffrer les fichiers chiffrés est perdue et les fichiers ne peuvent pas être récupérés via cet agent de
récupération.
Pour localiser la stratégie de récupération de données chiffrées, ouvrez la stratégie de domaine par défaut dans
le logiciel en snap-in Éditeur d’objets de stratégie de groupe, développez Configuration ordinateur,
développez Windows Paramètres, développez Sécurité Paramètres, puis développez Stratégies de clé
publique.
Pour exporter la clé privée de l’agent de récupération de domaine, suivez les étapes suivantes :
1. Recherchez le premier contrôleur de domaine promu dans le domaine.
2. Connectez-vous au contrôleur de domaine à l’aide du compte Administrateur intégré.
3. Cliquez sur Démarrer, puis sur Exécuter, tapez mmc, puis cliquez sur OK.
4. Dans le menu Fichier , cliquez sur Ajouter/Supprimer un composant logiciel enfichable . Cliquez
ensuite sur Ajouter Windows Server 2003 ou dans Windows 2000. Vous pouvez également cliquer sur
OK Windows Server 2008 ou dans Windows Server 2008 R2.
5. Sous Les logiciels en snap-in autonomes disponibles, cliquez sur Cer tificats, puis cliquez sur
Ajouter.
6. Cliquez sur Mon compte d’utilisateur, puis sur Terminer.
7. Cliquez sur Fermer, puis sur OK dans Windows Server 2003 ou Windows 2000. Vous pouvez
également cliquer sur OK Windows Server 2008 ou dans Windows Server 2008 R2.
8. Double-cliquez sur Cer tificats - Utilisateur actuel, double-cliquez sur Personnel, puis double-
cliquez sur Cer tificats.
9. Recherchez le certificat qui affiche les mots « File Recovery » (sans les guillemets) dans la colonne
Intended Purposes.
10. Cliquez avec le bouton droit sur le certificat que vous avez localisé à l’étape 9, pointez sur Toutes les
tâches, puis cliquez sur Expor ter . L’Assistant Exportation de certificat démarre.
12. Cliquez sur Oui, expor tez la clé privée, puis cliquez sur Suivant.
13. Cliquez sur Informations personnelles Exchange - PKCS #12 (. PFX).
NOTE
Nous vous recommandons vivement de cliquer pour activer une protection forte (nécessite la case à cocher IE
5.0, NT 4.0 SP4 ou supérieure pour protéger votre clé privée contre tout accès non autorisé).
Si vous cliquez pour sélectionner la case à cocher Supprimer la clé privée si l’exportation réussit, la clé
privée est supprimée du contrôleur de domaine. En tant que meilleure pratique, nous vous
recommandons d’utiliser cette option. Installez la clé privée de l’agent de récupération uniquement
lorsque vous en avez besoin pour récupérer des fichiers. À tout autre moment, exportez, puis stockez la
clé privée de l’agent de récupération hors connexion pour maintenir sa sécurité.
15. Spécifiez un mot de passe, puis cliquez sur Suivant .
16. Spécifiez un nom de fichier et un emplacement où vous souhaitez exporter le certificat et la clé privée,
NOTE
Nous vous recommandons de sauvegarder le fichier sur un disque ou sur un périphérique multimédia amovible,
puis de stocker la sauvegarde à un emplacement où vous pouvez confirmer la sécurité physique de la sauvegarde.
17. Vérifiez les paramètres affichés dans la page Fin de l’Assistant Exportation de certificat, puis cliquez sur
Terminer.
Impossible de sélectionner Windows Server 2016
modèles de certificat compatibles avec l’Windows
Server 2016 des cae ou des serveurs CEP basés sur
une base ultérieure
Cet article fournit une solution de contournement pour le problème Windows Server 2016 les modèles de
certificat compatibles avec l’AC ne peuvent pas être sélectionnés à partir de Windows Server 2016 ou de
serveurs CA ou CEP basés sur une base ultérieure.
Symptômes
Envisagez l’un des scénarios suivants :
Vous configurez un serveur Windows Server 2016 d’inscription de certificats (CEP) ou un serveur
d’inscription de certificats (CES).
Vous installez une nouvelle autorité de Windows Server 2016 certification.
Vous configurez les paramètres de compatibilité d’un modèle de certificat en configurant l’autorité de
cer tification sur Windows Ser ver 2016 et le destinataire du certificat sur Windows 10 /Windows
Ser ver 2016 .
Lorsque Windows 10 utilisateurs tentent de demander des certificats à l’aide de la page d’inscription Web de
l’AC (URL CEP), le modèle de certificat que vous avez configuré comme décrit ici n’est pas répertorié comme
modèle disponible.
Cause
Il s’agit d’un problème connu dans Windows Server 2016 versions ultérieures. Le serveur CEP ou CES fournit
des modèles de certificats uniquement aux clients qui ont les paramètres de compatibilité suivants :
Autorité de cer tification : Windows Server 2012 R2 ou une version antérieure
Destinataire du certificat : Windows 8.1 (ou une version antérieure) et Windows Server 2012 R2 (ou une
version antérieure)
Pour contourner ce problème, suivez les étapes suivantes :
1. Configurez les paramètres de compatibilité du modèle de certificat comme suit :
Autorité de cer tification : Windows Ser ver 2012 R2
Destinataire du certificat : Windows 8.1 /Windows Ser ver 2012 R2
2. Attendez 30 minutes que le serveur CEP reçoie les informations du modèle mis à jour (ou utilisez l’outil
IISReset pour redémarrer le serveur).
3. Sur l’ordinateur client, effacer le cache de stratégie d’inscription côté client à l’aide de la commande
suivante dans une fenêtre d’invite de commandes :
certutil -f -policyserver * -policycache delete
4. Sur l’ordinateur client, essayez à nouveau d’inscrire le certificat. Le modèle doit maintenant être
disponible.
Vous ne pouvez pas partager des fichiers qui ont
plusieurs certificats EFS
Cet article décrit un problème dans lequel vous ne pouvez pas partager des fichiers chiffrés à l’aide de plusieurs
certificats EFS.
S’applique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 - toutes
les éditions
Symptômes
Prenons l’exemple du scénario suivant :
Vous souhaitez que les utilisateurs partagent des fichiers chiffrés à l’aide de plusieurs certificats de
système de fichiers EFS( Encrypting File System).
Les utilisateurs U1 et U2 ont des certificats EFS valides.
Le fichier F1 existe sur un ordinateur sur lequel le système EFS est activé, et les utilisateurs U1 et U2 ont
des autorisations de lecture et d’écriture sur le fichier.
L’utilisateur U1 suit les étapes suivantes pour chiffrer le fichier F1 :
1. Recherchez le fichier F1 sur le disque.
2. Cliquez avec le bouton droit sur le fichier F1.
3. Cliquez sur Propriétés .
4. Cliquez sur Avancé .
5. Sélectionnez Chiffrer le contenu pour sécuriser les données.
6. Cliquez sur OK .
7. Cliquez sur Appliquer .
L’utilisateur U1 crée le partage de fichiers pour le fichier F1 en ajoutant le certificat EFS approprié pour
l’utilisateur U2 au fichier F1.
Les utilisateurs U1 et U2 suivent les étapes suivantes pour accéder au fichier F1 :
1. Recherchez le fichier F1 sur le disque.
2. Cliquez avec le bouton droit sur le fichier F1.
5. Cliquez sur Détails .
6. Cliquez sur Ajouter .
7. Sélectionnez l’utilisateur que vous souhaitez ajouter.
8. Cliquez sur OK .
L’utilisateur U1 ou l’utilisateur U2 modifie le fichier F1.
Dans ce scénario, les métadonnées EFS ne sont pas conservées et seul l’utilisateur actuel peut déchiffrer le
fichier. Toutefois, vous vous attendez à ce que les métadonnées EFS soient conservées et que l’utilisateur que
vous avez ajouté à l’étape 7 soit toujours là.
Cause
Si une application ouvre et enregistre un fichier à l’aide de l’API, et si ce fichier a été chiffré à l’aide du système
EFS alors que plusieurs certificats étaient présents, le fichier résultant contient uniquement le certificat de
l’utilisateur qui a enregistré le replacefile() fichier. Ce comportement est inhérent au produit.
Statut
Cette méthode de partage de fichiers chiffrés n’est pas pris en cas d’utilisation pour le moment.
Les services de certificats (certsvc) ne démarrent pas
après la mise à niveau vers Windows Server 2016
Cet article fournit une solution à un problème dans lequel les services de certificats (certsvc) ne démarrent pas
après la mise à niveau vers Microsoft Windows Server 2016.
S’applique à : Windows Server 2016
Symptômes
Après avoir effectué une mise à niveau sur place de Windows Server 2012 ou Windows Server 2012 R2 vers
Windows Server 2016, il se peut que les services de certificats Active Directory (certsvc) ne démarrent pas. Si
vous essayez de démarrer manuellement le service à partir de services Management Console (services.msc), la
tentative peut échouer avec le message d’erreur suivant :
Windows n’a pas pu démarrer le service Services de certificats Active Directory sur l’ordinateur local. Erreur
1058 : le service ne peut pas être démarré, soit parce qu’il est désactivé, soit parce qu’il n’a pas activé les
appareils qui lui sont associés.
En outre, lorsque vous essayez de démarrer les services de certificats Active Directory à partir du logiciel en
ligne des services de certificats, celui-ci peut échouer, puis vous recevez le message d’erreur suivant :
Titre : Services de certificats Microsoft Active Directory

Le service ne peut pas être démarré, soit parce qu’il est désactivé, soit parce qu’il n’a pas activé les appareils
qui lui sont associés.
0x422 (WIN32 : 1058 ERROR_SERVICE_DISABLED)
NOTE
Aucun événement n’est enregistré dans les journaux système ou d’application lorsque le service ne parvient pas à
démarrer.
Ce problème peut se produire sur différentes configurations. Par exemple : joint à un domaine, non joint à un domaine,
Enterprise autorité de certification et autorité de certification autonome
Pour récupérer à partir de ce problème, redémarrez l’ordinateur. Les services de certificats Active Directory sont
automatiquement démarrés après le redémarrage de l’ordinateur.
Statut
S’applique à ».
Les services de certificats peuvent ne pas démarrer
sur un ordinateur exécutant Windows Server 2003
ou Windows 2000
Cet article fournit une solution à un problème dans lequel les services de certificats (CS) peuvent ne pas
démarrer sur un ordinateur exécutant Windows Server 2003 ou Windows 2000.
S’applique à : Windows 10 - toutes les éditions, Windows Server 2012 R2
Symptômes
Sur un ordinateur exécutant Microsoft Windows Server 2003 ou Microsoft Windows Server 2000, il se peut que
les services de certificats ne démarrent pas.
En outre, le message d’erreur suivant peut être enregistré dans le journal des applications dans l’Observateur
d’événements.
Cause
Avant de commencer, les services de certificats édent toutes les clés et les certificats qui ont été délivrés à
l’autorité de certification, même si les clés et les certificats ont expiré. Les services de certificats ne démarrent
pas si l’un de ces certificats a été supprimé du magasin de certificats personnels de l’ordinateur local.
Résolution
Pour résoudre ce problème, vérifiez que le nombre d’empreintes numériques de certificat dans le Registre est
égal au nombre de certificats délivrés à l’autorité de certification. Si des certificats sont manquants, importez les
certificats manquants dans le magasin de certificats personnels de l’ordinateur local. Après avoir importé les
certificats manquants, utilisez la commande pour réparer la liaison entre les certificats importés et le magasin
de clés certutil -repairstore privé associé.
Pour ce faire, utilisez l’une des méthodes suivantes, selon la version du système d’exploitation que votre
ordinateur exécute.
Méthode 1 : Windows Server 2003

Pour résoudre ce problème sur un ordinateur Windows Server 2003, suivez ces étapes.
Étape 1 : Rechercher les certificats manquants
IMPORTANT
restaurer en cas de problème. Pour plus d’informations, voir Comment faire pour la back up et restaurer leRegistre dans
Windows .
Les empreintes numériques de certificat indiquent tous les certificats qui ont été délivrés à cette ca. Chaque fois
qu’un certificat est renouvelé, une nouvelle empreinte de certificat est ajoutée à la liste CaCertHash dans le
Registre. Le nombre d’entrées de cette liste doit être égal au nombre de certificats délivrés à l’ac et répertoriés
dans le magasin de certificats personnels de l’ordinateur local.
Pour rechercher les certificats manquants, suivez les étapes suivantes :
1. Sélectionnez Démarrer, sélectionnez Exécuter, tapez regedit, puis sélectionnez OK.
2. Recherchez, puis sélectionnez la sous-clé suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\**Your_Certificate_Authority_Name
*
3. Dans le volet droit, double-cliquez sur CaCer tHash .
4. Notez le nombre d’empreintes numériques de certificat que contient la liste de données Valeur.
5. Démarrez l’invite de commandes.
6. Tapez la commande suivante, puis appuyez sur Entrée : certutil -store
Comparez le nombre de certificats répertoriés dans le magasin de certificats personnels de l’ordinateur

local au nombre d’empreintes numériques de certificat répertoriées dans l’entrée de Registre CaCertHash.
Si les numéros sont différents, allez à l’étape 2 : Importer les certificats manquants. Si les chiffres sont
identiques, allez à l’étape 3 : Installer Windows Pack d’outils d’administration server 2003.
Étape 2 : Importer les certificats manquants
1. Sélectionnez Démarrer, pointez sur Tous les programmes, pointez sur Outils d’administration, puis
sélectionnez Cer tificats.
Si les cer tificats n’apparaissent pas dans la liste, suivez les étapes suivantes :
a. Sélectionnez Démarrer, sélectionnez Exécuter, tapez mmc, puis sélectionnez OK.
b. Dans le menu Fichier , sélectionnez Ajouter/Supprimer un composant logiciel enfichable .
c. Sélectionnez Ajouter .
d. Dans la liste des logiciels en snap-in, sélectionnez Cer tificats, puis ajoutez .
Si la boîte de dialogue Cer tificats s’affiche, sélectionnez Mon compte d’utilisateur, puis
terminez.
e. Sélectionnez Fermer puis OK .
Le répertoire Certificats est maintenant ajouté à la Console de gestion Microsoft (MMC).
f. Dans le menu Fichier, sélectionnez Enregistrer sous , tapez Certificats dans la zone Nom de
fichier, puis sélectionnez Enregistrer .
Pour ouvrir les certificats à l’avenir, sélectionnez Démarrer, pointez sur Tous les programmes,
pointez sur Outils d’administration, puis sélectionnez Cer tificats.
2. Développez Cer tificats, développez Personnel, cliquez avec le bouton droit sur Cer tificats, pointez
sur Toutes les tâches, puis sélectionnez Impor ter .
3. Dans la page d’accueil, sélectionnez Suivant.
4. Dans la page Fichier à importer, tapez le chemin d’accès complet du fichier de certificat à importer dans
la zone Nom de fichier, puis sélectionnez Suivant . Au lieu de cela, sélectionnez Parcourir, recherchez le
fichier, puis sélectionnez Suivant .
5. Si le fichier que vous souhaitez importer est un fichier d’informations Exchange - PKCS #12 (*. PFX), vous
serez invité à nous demander le mot de passe. Tapez le mot de passe, puis sélectionnez Suivant.
6. Dans la page Magasin de cer tificats, sélectionnez Suivant.
7. Dans la page Fin de l’Assistant Impor tation de certificat, sélectionnez Terminer.
NOTE
L’ac publie toujours ses certificats d’ac dans le %systemroot%\System32\CertSvc\CertEnroll dossier. Il se peut que vous
trouviez les certificats manquants dans ce dossier.
Étape 3 : Installer le pack d’outils Windows Administration Server 2003

Après avoir importé les certificats, vous devez utiliser l’outil Certutil pour réparer la liaison entre les certificats
importés et le magasin de clés privées associé. L’outil Certutil est inclus dans les outils de certificat de l’ac. Les
outils Windows certificat d’ac server 2003 se trouvent dans le pack d’outils d’administration Windows Server
2003. Si les outils de certificat d’ac ne sont pas installés sur votre ordinateur, installez-les maintenant.
Étape 4 : Réparer les liens
Après avoir installé Windows Pack d’outils d’administration Server 2003, suivez les étapes suivantes :
2. Tapez ce qui suit, puis appuyez sur Entrée :
cd %systemroot%\system32\certsrv\certenroll
3. Notez le certificat dans le dossier Certenroll qui ressemble à ce qui suit : Your_Ser ver .
Your_Domain .com_rootca.crt
4. Tapez les commandes suivantes, puis appuyez sur Entrée après chaque commande :
%systemroot%\system32\certutil -addstore my
%systemroot%\system32\certsrv\certenroll\Your_Server.Your_Domain.com_rootca.crt
%systemroot%\System32\certutil -dump
%systemroot%\system32\certsrv\certenroll\Your_Server.Your_Domain.com_rootca.crt
Your_Ser ver.Your_Domain .com_rootca.crt est le nom du certificat dans le dossier Certenroll que vous
avez noté à l’étape 3.
5. Dans la sortie de la dernière commande, vers la fin, vous verrez une ligne semblable à la suivante :
Key Id Hash(sha1) : ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5 09 d9 b6 32 1b
Les données de hachage d’ID de clé sont spécifiques à votre ordinateur. Notez cette ligne.
6. Tapez la commande suivante, y compris les guillemets, puis appuyez sur Entrée :
%systemroot%\system32\certutil -repairstore my "Key_Id_Hash_Data »
Dans cette commande, Key_Id_Hash_Data est la ligne que vous avez noté à l’étape 4. Par exemple, tapez
ce qui suit :
%systemroot%\system32\certutil -repairstore my "ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5
09 d9 b6 32 1b »
Vous recevrez ensuite la sortie suivante :
CertUtil: -repairstore command completed successfully.
7. Pour vérifier les certificats, tapez ce qui suit, puis appuyez sur Entrée :
%systemroot%\system32\certutil -verifykeys Une fois cette commande s’exécute, vous recevrez la sortie
suivante :
CertUtil: -verifykeys command completed successfully.
Étape 5 : Démarrer le service services de certificats

1. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez Ser vices.
2. Cliquez avec le bouton droit sur Ser vices de certificats, puis sélectionnez Démarrer.
Méthode 2 : Windows 2000

Pour résoudre ce problème sur un ordinateur Windows 2000, suivez ces étapes.
Étape 1 : Recherche des certificats manquants
IMPORTANT
Windows .
Les empreintes numériques de certificat indiquent tous les certificats qui ont été délivrés à cette ca. Chaque fois
qu’un certificat est renouvelé, une nouvelle empreinte de certificat est ajoutée à la liste CaCertHash dans le
Registre. Le nombre d’entrées de cette liste doit être égal au nombre de certificats délivrés à l’ac et répertoriés
dans le magasin de certificats personnels de l’ordinateur local.
Pour rechercher les certificats manquants, suivez les étapes suivantes :
1. Sélectionnez Démarrer, sélectionnez Exécuter, tapez regedit, puis sélectionnez OK.
2. Recherchez et sélectionnez la sous-clé suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\**Your_Certificate_Authority_Name
*
3. Dans le volet droit, double-cliquez sur CaCer tHash .
4. Notez le nombre d’empreintes numériques de certificat que contient la liste de données Valeur.
6. Tapez ce qui suit, puis appuyez sur Entrée : certutil -store
Comparez le nombre de certificats répertoriés dans le magasin de certificats personnels de l’ordinateur local au
nombre d’empreintes numériques de certificat répertoriées dans l’entrée de Registre CaCertHash. Si les
numéros sont différents, allez à l’étape 2 : Importer les certificats manquants. Si les chiffres sont identiques, allez
à l’étape 3 : Installer Windows Pack d’outils d’administration server 2003.
Étape 2 : Importation des certificats manquants
1. Sélectionnez Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis
sélectionnez Cer tificats.
Si les certificats n’apparaissent pas dans la liste, suivez les étapes suivantes :
a. Sélectionnez Démarrer, sélectionnez Exécuter, tapez mmc, puis sélectionnez OK.
b. Dans le menu Console, sélectionnez Ajouter/Supprimer un logiciel en un clin d’œil.
c. Sélectionner Ajouter
d. Dans la liste des logiciels en snap-in, sélectionnez Cer tificats, puis ajoutez .
Si la boîte de dialogue Cer tificats s’affiche, sélectionnez Mon compte d’utilisateur, puis terminez. 5.
Sélectionnez Fermer . 6. Sélectionnez OK . 7. Le répertoire Certificats est maintenant ajouté à la Console
de gestion Microsoft (MMC). 8. Dans le menu Console, sélectionnez Enregistrer sous , tapez
Certificats comme nom de fichier, puis sélectionnez Enregistrer .
Pour ouvrir les certificats à l’avenir, sélectionnez Démarrer, pointez sur Programmes, pointez sur Outils
d’administration, puis sélectionnez Cer tificats.
2. Développez Cer tificats, développez Personnel, cliquez avec le bouton droit sur Cer tificats, pointez
sur Toutes les tâches, puis sélectionnez Impor ter .
3. Dans la page d’accueil, sélectionnez Suivant.
4. Dans la page Fichier à importer, tapez le chemin d’accès complet du fichier de certificat à importer dans
la zone Nom de fichier, puis sélectionnez Suivant . Au lieu de cela, sélectionnez Parcourir, recherchez le
fichier, puis sélectionnez Suivant .
5. Si le fichier que vous souhaitez importer est un fichier d’informations Exchange - PKCS #12 (*. PFX), le
mot de passe vous est invité. Tapez le mot de passe, puis sélectionnez Suivant.
6. Dans la page Magasin de cer tificats, sélectionnez Suivant.
7. Dans la page Fin de l’Assistant Impor tation de certificat, sélectionnez Terminer.
NOTE
L’ac publie toujours ses certificats d’ac dans le %systemroot%\System32\CertSvc\CertEnroll dossier. Il se peut que vous
trouviez les certificats manquants dans ce dossier.
Étape 3 : Installer les outils Windows Server 2003 Certutil

Après avoir importé les certificats, vous devez utiliser les outils de certificat de l’ac Windows Server 2003 pour
réparer la liaison entre les certificats importés et le magasin de clés privées associé.
Les versions Windows Server 2003 de Certutil.exe et Certreq.exe sont incluses dans le pack d’outils
d’administration Windows Server 2003. Pour installer les outils sur un ordinateur Windows 2000, vous devez
d’abord installer le pack d’outils d’administration Windows Server 2003 sur un ordinateur exécutant Windows
Server 2003 ou Microsoft Windows XP avec Service Pack 1 (SP1) ou un Service Pack ultérieur. Le pack Windows
Outils d’administration Server 2003 ne peut pas être installé directement sur un ordinateur Windows 2000.
IMPORTANT
Après avoir copié les outils de certificat d’ac Windows Server 2003 sur l’ordinateur Windows 2000, deux versions de l’outil
Certutil résident sur l’ordinateur Windows 2000. Ne supprimez pas l Windows 2000 Certutil. D’autres programmes
dépendent de la Windows 2000 de cet outil. Par exemple, le logiciel en ligne MMC Certificats nécessite Windows’outil
Certutil 2000. En outre, n’inscrivez pas les fichiers Windows Server 2003 Certcli.dll et Certadm.dll sur l’ordinateur
Windows 2000.
Pour utiliser les outils Windows certificat de l’ac server 2003 sur un ordinateur Windows 2000, suivez les étapes
suivantes :
1. Télécharger le pack Windows Outils d’administration Server 2003
2. Connectez-vous à un ordinateur exécutant Windows Server 2003 ou Windows XP avec SP1 ou avec un
Service Pack ultérieur.
3. Installez le Windows Pack d’outils d’administration Server 2003.
4. Dans le pack d’outils d’administration Windows Server 2003, recherchez les fichiers suivants, puis copiez-
les dans un support de stockage amovible, tel qu’un disque de 3,5 pouces :
Certreq.exe
Certutil.exe
Certcli.dll
Certadm.dll
5. Connectez-vous à l Windows 2000 en tant qu’administrateur.
6. Insérez le support de stockage amovible que vous avez utilisé à l’étape 4 dans le lecteur approprié de
l’ordinateur Windows 2000.
8. Make a new folder, and then copy the files on the removable storage medium to the new folder. Pour ce
faire, tapez les commandes suivantes, puis appuyez sur Entrée après chaque commande :
cd\
md W2k3tool
cd w2k3tool
copier Removable_Media_Drive_Letter :\cert*
NOTE
Pour éviter les conflits avec les versions Windows 2000 de l’outil Certutil qui se trouve déjà sur l’ordinateur,
n’incluez pas le dossier W2k3tool dans le chemin de recherche de votre système.
Étape 4 : Réparation des liens

Une fois que vous avez copié les fichiers Windows Server 2003 CA Certificate Tools sur l’ordinateur Windows
2000, suivez les étapes suivantes :
2. Tapez ce qui suit, puis appuyez sur Entrée :
cd %systemroot\system32\certsrv\certenroll
3. Notez le certificat dans le dossier Certenroll qui ressemble à ce qui suit :

Your_Ser ver.Your_Domain.com_rootca.cr t
Root_Drive_Letter : \ w2k3tool \certutil -addstore my %systemroot%\system32\certsrv\certenroll\
Your_Ser ver.Your_Domain .com_rootca.crt
Root_Drive_Letter : \ w2k3tool \certutil -dump %systemroot%\system32\certsrv\certenroll\
Your_Ser ver.Your_Domain .com_rootca.crt
Root_Drive_Letter est la lettre du répertoire racine.
Your_Ser ver.Your_Domain .com_rootca.crt est le nom du certificat dans le dossier Certenroll que vous
avez noté à l’étape 3.
5. Dans la sortie de la dernière commande, vers la fin, vous verrez une ligne semblable à la suivante : Key Id
Hash(sha1) : ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5 09 d9 b6 32 1b
Les données de hachage d’ID de clé sont spécifiques à votre ordinateur. Notez cette ligne.
6. Tapez la commande suivante, y compris les guillemets, puis appuyez sur Entrée :
Root_Drive_Letter : \ w2k3tool \certutil -repairstore my "Key_Id_Hash_Data »
Dans cette commande, Key_Id_Hash_Data est la ligne que vous avez notée à l’étape 5. Par exemple, tapez
ce qui suit :
c:\w2k3tool\certutil -repairstore my "ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5 09 d9 b6 32
1b »
Une fois cette commande terminée, vous recevrez le résultat suivant :
CertUtil: -repairstore command completed successfully.
7. Pour vérifier les certificats, tapez la commande suivante, puis appuyez sur Entrée :
Root_Drive_Letter : \ w2k3tool \certutil -verifykeys
Une fois cette commande s’exécute, vous recevrez la sortie suivante :
CertUtil: -verifykeys command completed successfully.
Étape 5 : Démarrage du service services de certificats

2. Cliquez avec le bouton droit sur Ser vices de certificats, puis sélectionnez Démarrer.
Vous devez désaffecter et remplacer l’ac si l’une des conditions suivantes est vraie :
Vous ne pouvez pas localiser les certificats manquants.
Les certificats ne peuvent pas être réinstallés.
La certutil -repairstore commande ne peut pas être terminée car les clés privées ont été supprimées.
Pour désaffecter et remplacer l’ac, suivez les étapes suivantes :
1. Révoquer les certificats pour l’ac qui a cessé de fonctionner correctement. Pour ce faire, suivez les
étapes suivantes :
a. Connectez-vous en tant qu’administrateur à l’ordinateur qui a émis les certificats que vous
souhaitez révoquer.
b. Sélectionnez Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis
sélectionnez Autorité de cer tification.
c. Développez CA_Name, puis sélectionnez Cer tificats émis.
d. Dans le volet droit, sélectionnez le certificat à révoquer.
e. Dans le menu Action, pointer sur Toutes les tâches, puis sélectionnez Révoquer le
cer tificat.
f. Dans la liste de code Raison, sélectionnez la raison de la révocation du certificat, puis
sélectionnez Oui .
Cela révoque tous les certificats émis par l’ac qui ont cessé de fonctionner correctement.
2. Publiez la liste de révocation de certificats (CRL) sur l’ac la plus élevée suivante. Pour ce faire,
a. Connectez-vous en tant qu’administrateur à l’ordinateur qui exécute l’ac la plus élevée suivante.
b. Sélectionnez Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis
sélectionnez Autorité de cer tification.
c. Développez CA_Name, puis sélectionnez Cer tificats révoqués.
d. Dans le menu Action, pointez sur Toutes les tâches, puis sélectionnez Publier.
e. Sélectionnez Oui pour réécrire la CRL publiée précédemment.
3. Si l’autorité de sécurité qui a cessé de fonctionner correctement a été publiée dans les services
d’annuaire Active Directory, supprimez-la. Pour supprimer l’autorité de contrôle d’accès d’Active
Directory, suivez les étapes suivantes :
a. Démarrez l’invite de commandes.
b. Tapez ce qui suit, puis appuyez sur Entrée :
certutil -dsdel CA_Name
4. Supprimez les services de certificats du serveur où l’ac a cessé de fonctionner correctement. Pour
ce faire, suivez les étapes suivantes :
a. Sélectionnez Démarrer, pointez sur Paramètres, puis sélectionnez Panneau de contrôle.
b. Double-cliquez sur Ajouter/Supprimer des programmes, puis sélectionnez
Ajouter/Supprimer Windows composants.
c. Dans la liste Composants, cliquez pour effacer la case Ser vices de certificats, sélectionnez
Suivant, puis Terminer.
5. Installez les services de certificats. Pour ce faire, suivez les étapes suivantes :
a. Sélectionnez Ajouter/Supprimer Windows composants.
b. Dans la liste Composants, sélectionnez la case à cocher Ser vices de certificats, sélectionnez
Suivant, puis Terminer.
6. Tous les utilisateurs, les ordinateurs ou les services avec des certificats émis par l’ac qui ont cessé
de fonctionner correctement doivent s’inscrire pour les certificats de la nouvelle CA.
NOTE
Si ce problème se produit sur l’autorité de sécurité racine de la hiérarchie de l’infrastructure à clé publique (PKI) et si le
problème ne peut pas être réparé, vous devez remplacer toute la hiérarchie pKI. Pour plus d’informations sur la
suppression de la hiérarchie PKI, voir Comment désaffecter une autorité de certification Windows entreprise et supprimer
tous les objets associés.
Modifier la date d’expiration des certificats émis par
l’autorité de certification
Cet article explique comment modifier la période de validité d’un certificat émis par l’autorité de certification .
Résumé
Par défaut, la durée de vie d’un certificat émis par une autorité de certification autonome est d’un an. Au bout
d’un an, le certificat expire et n’est pas approuvé pour une utilisation. Il peut se passer de la date d’expiration par
défaut pour les certificats émis par une cae intermédiaire ou émettrice.
La période de validité définie dans le Registre affecte tous les certificats émis par des autorité de certification
autonomes Enterprise de certification. Pour les Enterprise, le paramètre de Registre par défaut est de deux ans.
Pour les autorité de configuration autonomes, le paramètre de Registre par défaut est un an. Pour les certificats
émis par des autorité de certification autonomes, la période de validité est déterminée par l’entrée de Registre
décrite plus loin dans cet article. Cette valeur s’applique à tous les certificats émis par l’ac.
Pour les certificats émis par les Enterprise de certification, la période de validité est définie dans le modèle utilisé
pour créer le certificat. Windows 2000 et Windows Server 2003 ne Édition Standard pas la modification de ces
modèles. Windows Server 2003 Êdition Entreprise prend en charge les modèles de certificat de version 2 qui
peuvent être modifiés. La période de validité définie dans le modèle s’applique à tous les certificats émis par une
autorité de certification Enterprise dans la forêt Active Directory. Un certificat émis par une cae est valide pour
les périodes suivantes :
La période de validité du Registre qui est notée plus tôt dans cet article.
Cela s’applique à l’ac autonome et aux certificats d’ac subordonnés émis par l’Enterprise ac.
Période de validité du modèle.
Cela s’applique à l’Enterprise ac. Les modèles pris en charge Windows 2000 et Windows Server 2003 Édition
Standard ne peuvent pas être modifiés. Les modèles pris en charge par Windows Server Êdition Entreprise
(modèles de version 2) ne peuvent pas être modifiés.
Pour une Enterprise de certification, la période de validité d’un certificat émis est définie sur la valeur minimale
de toutes les valeurs suivantes :
La période de validité du Registre de l’autorité de contrôle d’autorité de données (par exemple :
ValidityPeriod == Years, ValidityPeriodUnits == 1)
Période de validité du modèle
Période de validité restante du certificat de signature de l’autorité de certification
Si le bit EDITF_ATTRIBUTEENDDATE est activé dans la valeur de Registre EditFlags du module de stratégie, la
période de validité spécifiée via les attributs de la demande (ExpirationDate:Date ou
ValidityPeriod:Years\nValidityPeriodUnits:1)
NOTE
La syntaxe ExpirationDate:Date n’a pas été prise en charge Windows Server 2008.
Pour une ca autonome, aucun modèle n’est traitée. Par conséquent, la période de validité du modèle ne s’applique pas.
Date d’expiration du certificat de l’ac

Une autorité de certification ne peut pas émettre un certificat dont la validité est plus longue que celle de son
propre certificat d’autorité de certification.
NOTE
Le nom de l’attribut de demande est composé de paires de chaînes de valeurs qui accompagnent la demande et qui
spécifient la période de validité. Par défaut, ce paramètre est activé par un paramètre de Registre sur une autorité de
configuration autonome uniquement.
Modifier la date d’expiration des certificats émis par l’ac

Pour modifier les paramètres de période de validité d’une autorité de configuration, suivez ces étapes.
IMPORTANT
1. Cliquez sur Démarrer , puis sur Exécuter .

2. Dans la zone Ouvrir, tapez regedit, puis cliquez sur OK.
3. Recherchez, puis cliquez sur la clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>
4. Dans le volet droit, double-cliquez sur ValidityPeriod .

5. Dans la zone de données Valeur, tapez l’une des valeurs suivantes, puis cliquez sur OK :
Jours
Semaines
Mois
Années
6. Dans le volet droit, double-cliquez sur ValidityPeriodUnits .
7. Dans la zone Données de la valeur, tapez la valeur numérique que vous souhaitez, puis cliquez sur OK .
Par exemple, tapez 2.
8. Arrêtez, puis redémarrez le service des services de certificats. Pour ce faire, procédez comme suit :
a. Cliquez sur Démarrer , puis sur Exécuter .
b. Dans la zone Ouvrir , tapez cmd, puis cliquez sur OK .
c. À l’invite de commandes, tapez les lignes suivantes. Appuyez sur Entrée après chaque ligne.
net stop certsvc

net start certsvc
d. Tapez exit pour quitter l’invite de commandes.

Échecs de sauvegarde DPAPI MasterKey lorsque
RWDC n’est pas disponible
Cet article fournit une solution pour résoudre les échecs de sauvegarde MasterKey DPAPI qui se produisent
lorsque RWDC n’est pas disponible.
S’applique à : Windows 10, version 1809, Windows Server 2012 R2, Windows Server 2016, Windows Server
2019
Symptômes
Le comportement suivant se produit dans Windows 8.1 et Windows Server 2012 R2 après l’installation de
MS14-066, KB2992611, KB3000850 ou des mises à jour plus nouvelles qui incluent ces correctifs.
Le même comportement se produit également dans toutes les versions de Windows 10 et les versions
ultérieures de Windows. Les utilisateurs de domaine qui se connectent pour la première fois à un nouvel
ordinateur dans un site qui est fourni par un contrôleur de domaine en lecture seule (RODC) rencontrent les
erreurs et problèmes suivants.
Problèmes génériques
1. L’ouverture du Gestionnaire d’informations d’identification échoue avec 0x80090345 erreur de
connexion, qui est m’adonne à ce qui suit :
H EX DÉC IM A L SY M B O L IQ UE C O N VIVIA L
0x80090345 -2146892987 SEC_E_DELEGATION_REQ L’opération demandée ne

UIRED peut pas être terminée.
L’ordinateur doit être
approuvé pour la
délégation et le compte
d’utilisateur actuel doit
être configuré pour
autoriser la délégation.
2. L’enregistrement d’un mot de passe RDP échoue sans erreur apparente.

3. La modification des mots de passe prend plus de temps que prévu.
4. L’Explorateur se bloque lorsque vous chiffrez un fichier.
5. Dans Office et Office 365, l’ajout d’un nouveau compte dans Windows Live Mail 2012 échoue avec une
erreur 0x80090345.
6. Outlook création de profil échoue avec l’erreur suivante :
Une connexion chiffrée à votre serveur de messagerie n’est pas disponible.
7. La signature de Lync et Skype se bloque ou subit un long retard pendant l’étape « Contacting server and
signing in ».
8. SQL service ne parvient pas à démarrer sous un compte de domaine et déclenche l’erreur suivante :
Impossible d’initialiser le chiffrement SSL car un certificat valide est in trouvé et il n’est pas possible
de créer un certificat auto-signé.
9. SQL Server’installation échoue avec l’erreur suivante :
Erreur : SQL configuration du serveur a rencontré l’erreur suivante : « génération du code d’erreur du
document XML 0x8410001.
10. Les utilisateurs de domaine ne peuvent pas gérer SQL de données à partir de SMSS. (SQL Server
Management Studio). This issue occurs when the database is navigated from via SSMS
DataBasesCustomerDatabaseTablesTable -> -> -> name .
Si vous cliquez avec le bouton droit sur le tableau, puis sélectionnez Conception , l’erreur suivante se
produit :
L’opération demandée ne peut pas être terminée. L’ordinateur doit être approuvé pour la délégation
et le compte d’utilisateur actuel doit être configuré pour autoriser la délégation. Cette exception
provient de System_Security_ni ! System.Security.Cryptography.ProtectedData.Protect(Byte[], Byte[],
System.Security.Cryptography.DataProtectionScope). »
11. L’installation ADFS WAP ne parvient pas à créer un certificat auto-signé et déclenche l’erreur suivante :
Exception : une erreur s’est produite lors de la tentative de création du certificat d’autorisation de
proxy.
12. L’installation ADLDS dans un site couvert par rodc uniquement échoue avec l’erreur suivante :
Taper un utilisateur et un mot de passe valides pour un compte de service sélectionné
a. Dans ce cas, le fichier AdamInstall.log affiche les données suivantes :
adamsetup D20.10F8 0255 15:30:22.002 Enter GetServiceAccountError

adamsetup D20.10F8 0256 15:30:22.002 Tapez un nom d’utilisateur et un mot de passe
valides pour le compte de service sélectionné.
adamsetup D20.10F8 0257 15:30:22.002 ADAMERR_SERVICE_INVALID_CREDS
b. Un exemple de suivi réseau pris au cours de l’échec montre que les ADLDS envoient un mot de
passe incorrect et que la demande TGT Kerberos échoue avec KDC_ERR_PREAUTH_FAILED :
SO URC E DEST IN AT IO N P ROTO C O L E DESC RIP T IO N
ADLDS RODC KerberosV5 AS Request Cname:

ADLDSSvc Realm:
CONTOSO Sname:
krbtgt/contoso
{TCP:375, IPv4:7}
RODC ADLDS KerberosV5 KerberosV5:KRB_ERROR

-
KDC_ERR_PREAUTH_FAI
LED (24) {TCP:376,
IPv4:7}
c. L’ID d’événement 4625 est consigné dans le journal de sécurité du serveur ADLDS, comme suit :
Mots clés : échec d’audit
Description : un compte n’a pas réussi à se connecter.
..
Informations sur l’échec :
Raison de l’échec : nom d’utilisateur inconnu ou mot de passe incorrect.
Status: 0xC000006D
Sub Status: 0xC000006A
..
Informations sur le processus :
Nom du processus de l’appelant : C:\Windows\ADAM\adaminstall.exe
Où l’état état et sub se traduit par :
0xc000006a -1073741718 STATUS_WRONG_PASS Lorsque vous essayez

WORD de mettre à jour un mot
de passe, ce statut de
retour indique que la
valeur fournie en tant
que mot de passe actuel
n’est pas correcte.
0xc000006d -1073741715 STATUS_LOGON_FAILUR La tentative d’logo n’est

E pas valide. Cela est dû à
un nom d’utilisateur ou
à des informations
d’authentification
mauvaises.
Dans tous les cas, NETLOGON. LOG affiche les demandes DsGetDcName qui appellent des
contrôleurs de domaine accessibles en writable :
[MISC] [3736] Fonction DsGetDcName appelée : client PID=568, Dom:VS Acct:(null) Indicateurs
: DS WRITABLE NETBIOS RET_DNS
[CRITIQUE] [3736] NetpDcMatchResponse: CON-DC4: CONTOSO.COM .: Le répondeur n’est pas un
serveur accessible en writable.
[MISC] [2600] La fonction DsGetDcName renvoie 1355 (piD client=564) : Indicateurs Dom:VS
Acct:(null) : FORCE DS WRITABLE NETBIOS RET_DNS
Où :
0x54b 1355 ERROR_NO_SUCH_DO Le domaine spécifié

MAIN n’existe pas ou n’a pas
pu être contacté.
Cause
Lorsqu’un utilisateur se connecte à un ordinateur pour la première fois et tente de chiffrer des données pour la
première fois, le système d’exploitation doit créer une clé MasterKey DPAPI préférée, qui est basée sur le mot de
passe actuel de l’utilisateur. Lors de la création de la DPAPI MasterKey, une tentative de back up de cette clé
principale est réalisée en contactant un RWDC. Si la sauvegarde échoue, la clé MasterKey ne peut pas être créée
et une erreur 0x80090345 est renvoyée.
Cet échec est un nouveau comportement, introduit par la KB2992611. Dans les systèmes d’exploitation plus
anciens et sur les systèmes où la KB2992611 n’est pas installée, si le client ne parvient pas à contacter un RWDC
lors de la sauvegarde de masterKey, la création de la clé principale est toujours autorisée et une sauvegarde
locale est créée.
Autrement dit, le comportement hérité effectue une sauvegarde locale de la clé principale si aucun RWDC n’est
disponible.
Conformément au bref de conception que les GUID ne stockent pas de clés secrètes, ces derniers ne stockent
pas ou ne gèrent pas la sauvegarde de la clé MasterKey. Par conséquent, dans les sites où aucun RWDC n’est
disponible, les problèmes décrits dans la section « Symptômes » peuvent se produire.
NOTE
Lorsqu’une clé principale préférée existe mais qu’elle a expiré (cas de mot de passe expiré), une tentative de génération
d’une nouvelle clé principale est réalisée. S’il n’est pas possible de créer une sauvegarde de domaine de la nouvelle clé
principale, le client revient à l’ancienne et le comportement décrit dans la section « Symptômes » ne se produit pas.
Le problème se produit uniquement en l’absence de MasterKey et lorsque l’utilisateur n’a jamais ouvert de
session sur l’ordinateur.
Résolution
1. Vérifiez que les stations de travail et les serveurs joints au domaine où le problème se produit ont accès
aux RWDCs.
Exécutez la ligne de commande suivante pour vérifier qu’un RWDC existe et qu’il est dans un état sain :
nltest /dsgetdc:<domain> /writable [/force]
Utilisez NETLOGON. Log et un suivi réseau avec les exemples de journaux fournis dans cet article pour
vérifier la résolution des noms et la connectivité à un RWDC.
Pour déterminer si vous rencontrez ce problème, essayez d’ouvrir CREDMAN dans le Panneau de
contrôle. Si la tentative échoue avec une erreur 0x80090345, vous l’avez vérifié.
2. Si possible, rendez l’ordinateur sur un site où un RWDC existe, puis connectez-vous pour la première fois.
Après cela, la clé MasterKey DPAPI est créée et le problème est résolu.
3. Si vous n’avez pas accès à un RWDC et si l’utilisateur n’est pas en itinérance entre les ordinateurs, l’entrée
de Registre suivante peut être utilisée pour résoudre le problème.
La définition de cette valeur sur 1 entraîne la sauvegarde locale des clés maîtres DPAPI au lieu d’utiliser
une sauvegarde de domaine. En outre, les clés créées précédemment ne déclenchent pas d’appels pour
un contrôleur de domaine accessible en création, sauf dans des cas limités, comme expliqué ci-dessous.
Ce paramètre de Registre s’applique uniquement aux comptes de domaine. Les comptes locaux utilisent
toujours des sauvegardes locales.
H K EY _LO C A L _M A C H IN E\ SO F T WA RE\ M IC RO SO F T \ C RY P T
O GRA P H Y \ P ROT EC T \ P RO VIDERS\ DF 9D8C D0- 1501- 11D1-
PAT H 8C 7A - 00C 04F C 297EB
Paramètre ProtectionPolicy
H K EY _LO C A L _M A C H IN E\ SO F T WA RE\ M IC RO SO F T \ C RY P T
O GRA P H Y \ P ROT EC T \ P RO VIDERS\ DF 9D8C D0- 1501- 11D1-
PAT H 8C 7A - 00C 04F C 297EB
Type de données DWORD
Valeur 1
Redémarrage du système d’exploitation demandé Oui
Notes Système d’exploitation
WARNING
N’utilisez pas cette clé de Registre si les utilisateurs du domaine se connectent à plusieurs ordinateurs ! Étant donné que
les clés sont backed localement, toute modification de mot de passe non locale peut déclencher une situation dans
laquelle toutes les clés maîtres DPAPI sont enveloppées à l’aide de l’ancien mot de passe, puis la récupération de domaine
n’est pas possible. Cette clé de Registre doit être définie uniquement dans un environnement où la perte de données est
acceptable.
RUB RIQ UE DÉTA IL S
Windows protection des données Windows protection des données
Sauvegarde et restauration clés dans DPAPI

Lorsqu’un ordinateur est membre d’un domaine, la DPAPI
dispose d’un mécanisme de sauvegarde pour autoriser la
non-protection des données. Lorsqu’une clé MasterKey est
générée, la DPAPI parle à un contrôleur de domaine. Les
contrôleurs de domaine ont une paire de clés
publique/privée à l’échelle du domaine, associée uniquement
à la DPAPI. Le client DPAPI local obtient la clé publique du
contrôleur de domaine auprès d’un contrôleur de domaine à
l’aide d’un appel RPC mutuellement authentifié et protégé
par la confidentialité. Le client chiffre la clé MasterKey avec la
clé publique du contrôleur de domaine. Il stocke ensuite
cette sauvegarde MasterKey avec la clé MasterKey protégée
par le mot de passe de l’utilisateur. Lors de la non-protection
des données, si la DPAPI ne peut pas utiliser la clé MasterKey
protégée par le mot de passe de l’utilisateur, elle envoie la clé
MasterKey de sauvegarde à un contrôleur de domaine à
l’aide d’un appel RPC mutuellement authentifié et protégé
par la confidentialité. Le contrôleur de domaine déchiffre
ensuite la clé MasterKey avec sa clé privée et la renvoie au
client à l’aide du même appel RPC protégé. Cet appel RPC
protégé permet de s’assurer que personne à l’écoute sur le
réseau ne peut obtenir la clé MasterKey.
Considérations sur le placement rodc Considérations sur le placement rodc
La ko liée qui modifie le comportement/démarre ce Mise à jour de novembre 2014 pour Windows RT 8.1,
problème. Windows 8.1 et Windows Server 2012 R2 (KB3000850)
RUB RIQ UE DÉTA IL S
Document de protocole distant de clé de sauvegarde Annexe B : Comportement du produit

Utilisation du Client-Side de secrets
Un serveur BackupKey Remote Protocol n’effectue pas

réellement de sauvegarde à distance des secrets. Au lieu de
cela, le serveur encapsule chaque secret et le renvoie au
client. Le client est responsable du stockage de la question
secrète jusqu’à ce qu’elle soit de nouveau nécessaire, auquel
moment le client peut demander au serveur de déballer la
question secrète.
Voir 3.1.4.1.3 BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID

Comment exporter un certificat d’autorité de
certification racine
Cet article explique comment exporter le certificat d’autorité de certification racine.

Numéro de base de connaissances d’origine : 555252
Conseils
1. Demande du certificat d’autorité de certification racine à l’aide de la ligne de commande :
a. Connectez-vous au serveur d’autorité de certification racine avec un compte administrateur.
b. Accédez à Star tRun > . Entrez la cmd de texte, puis sélectionnez Entrée .
c. Pour exporter le serveur d’autorité de certification racine vers un nouveau nom de fichier
ca_name.cer, tapez :
certutil -ca.cert ca_name.cer
2. Demande du certificat d’autorité de certification racine à partir du site d’inscription web :

a. Connectez-vous au site d’inscription web de l’autorité de certification racine.
En règle générale, le site d’inscription web se trouve dans les liens suivants :
<ip_address>http:///certsrv
ou
<fqdn>http:///certsrv
ip_address = Adresse IP du serveur d’autorité de certification racine.
fqdn = Nom de domaine complet du serveur d’autorité de certification racine.
b. Sélectionnez Télécharger un cer tificat d’autorité de cer tification, une chaîne de
cer tificats ou une liste de révocation de cer tificats .
c. Sélectionnez Télécharger le cer tificat d’autorité de cer tification .
d. Enregistrez le fichier « cer tnew.cer » dans le magasin de disques local.
Exclusion de contenu communautaire Solutions
MICROSOFT CORPORATION ET/OU SES FOURNISSEURS RESPECTIFS NE FONT AUCUNE DÉCLARATION SUR
LA PERTINENCE, DE FIABILITÉ OU L’EXACTITUDE DES INFORMATIONS ET DES ÉLÉMENTS GRAPHIQUES
ASSOCIÉS CONTENUS DANS LE PRÉSENT DOCUMENT. TOUTES CES INFORMATIONS ET ÉLÉMENTS
GRAPHIQUES ASSOCIÉS SONT FOURNIS « EN L’ÉTAT » SANS GARANTIE D’AUCUNE SORTE. MICROSOFT ET/OU
SES FOURNISSEURS RESPECTIFS EXCLUENT TOUTES LES GARANTIES ET CONDITIONS RELATIVES À CES
INFORMATIONS ET LES GRAPHIQUES ASSOCIÉS, NOTAMMENT TOUTE GARANTIE IMPLICITE DE QUALITÉ
MARCHANDE, D’ADÉQUATION À UN USAGE PARTICULIER, LOIS ET D’ABSENCE DE CONTREFAÇON. VOUS
RECONNAISSEZ SPÉCIFIQUEMENT QU’EN AUCUN CAS MICROSOFT ET/OU SES FOURNISSEURS EST
RESPONSABLES POUR DES DOMMAGES DIRECTS, INDIRECTS, PUNITIFS, OU ACCESSOIRES, SPÉCIALES, NI LES
DOMMAGES QUELCONQUES Y COMPRIS, SANS LIMITATION, LES DOMMAGES POUR PERTE D’UTILISATION, DE
DONNÉES OU DE BÉNÉFICES, DÉCOULANT D’OU DANS N’IMPORTE QUEL LIÉS À L’UTILISATION D’OU DE
L’INCAPACITÉ À UTILISER LES INFORMATIONS ET LES ÉLÉMENTS GRAPHIQUES ASSOCIÉS CONTENUS DANS LE
PRÉSENT DOCUMENT , BASÉ SUR LE CONTRAT, RESPONSABILITÉ DÉLICTUELLE, NÉGLIGENCE,
RESPONSABILITÉ STRICTE OU AUTREMENT, MÊME SI MICROSOFT OU L’UN DE SES FOURNISSEURS A ÉTÉ
AVERTI DE L’ÉVENTUALITÉ DE DOMMAGES.
Comment trouver le nom du serveur Enterprise
autorité de certification racine
Cet article vous aide à trouver le nom du Enterprise de l’autorité de certification racine.
Résumé
Le contenu suivant décrit deux options pour trouver le nom du Enterprise autorité de certification racine.
Option 1
1. Connectez-vous à l’aide de l’administrateur de domaine à l’ordinateur qui se connecte au domaine.
2. Go to Star t -> Run -> Write cmd and press on Enter button.
3. Écrivez «cer tutil.exe » et appuyez sur le bouton Entrée.
Option 2
1. Connectez-vous à l’aide de l’administrateur de domaine à l’ordinateur qui se connecte au domaine.
2. Installez les Windows de support technique.
3. Go to Star t -> Run -> Write adsiedit.msc and press on Enter button.
4. Accédez à :
CN=Autorités de certification,CN=Clé publique
Services,CN=Services,CN=Configuration,DC=ntdomain,DC=com
Sous Autorités de certification, vous trouverez votre Enterprise d’autorité de certification racine.
Réinstaller le rôle d’ac dans Windows Server 2012
Essentials
Cet article explique comment désinstaller puis réinstaller le rôle d’autorité de certification dans Windows Server
2012 Essentials.
Désinstaller le rôle serveur d’accès au contrôle d’accès

1. Dans le Gestionnaire de serveur, cliquez sur Gérer, puis sur Supprimer les rôles et les
fonctionnalités.
2. Sur la page Avant de commencer , cliquez sur Suivant .
3. Dans la page Sélectionner un ser veur de destination, sélectionnez le serveur dans le pool de
serveurs, puis cliquez sur Suivant.
4. Dans la page Supprimer les rôles serveur, développez Services de cer tificats Active Director y,
activez la case à cocher Inscription web de l’autorité de cer tification, puis cliquez sur Suivant .
5. Sur la page Supprimer des fonctionnalités , cliquez sur Suivant .
6. Dans la page Confirmer les sélections de suppression, vérifiez les informations, puis cliquez sur
Supprimer.
7. Cliquez sur Fermer une fois la suppression terminée.
8. Répétez les étapes 1 à 3.
9. Dans la page Supprimer les rôles ser veur, activez la case à cocher Services de cer tificats Active
Director y.
NOTE
Lorsque vous êtes invité à supprimer les outils d’administration de serveur distant, cliquez sur Supprimer des
fonctionnalités, puis cliquez sur Suivant .
10. Sur la page Supprimer des fonctionnalités , cliquez sur Suivant .

11. Dans la page Confirmer les sélections de suppression, vérifiez les informations, puis cliquez sur
Supprimer.
12. Une fois la suppression terminée, cliquez sur Fermer, puis redémarrez le serveur.
Réinstaller le rôle serveur d’accès au ca

1. Dans le Gestionnaire de serveur, cliquez sur Gérer, puis sur Ajouter des rôles et des
fonctionnalités.
2. Dans la page Avant de commencer, cliquez sur Suivant.
3. Dans la page Sélectionner un type d’installation, cliquez sur Installation basée sur un rôle ou sur une
fonctionnalité, puis cliquez sur Suivant .
4. Dans la page Sélectionner un ser veur de destination, sélectionnez le serveur dans le pool de
serveurs, puis cliquez sur Suivant.
5. Dans la page Sélectionner des rôles ser veur, cliquez sur le rôle Ser vices de cer tificats Active
Director y.
6. Lorsque vous êtes invité à installer les outils d’administration de serveur distant, cliquez sur Ajouter
des fonctionnalités, puis sur Suivant .
7. Dans la page Sélectionner des fonctionnalités, cliquez sur Suivant.
8. Dans la page Ser vices de cer tificats Active Director y, cliquez sur Suivant.
9. Dans la page Sélectionner des ser vices de rôle, sélectionnez Autorité de cer tification et Inscription
web de l’autorité de cer tification, puis cliquez sur Suivant .
10. Dans la page Confirmer les sélections d’installation, vérifiez les informations, puis cliquez sur
Installer.
11. Attendez la fin de l’installation. Une fois l’installation terminée, cliquez sur Configurer les services de
cer tificats Active Director y sur le lien du serveur de destination.
12. Dans la page Informations d’identification, cliquez sur Suivant .
NOTE
Vous pouvez modifier les informations d’identification si nécessaire.
13. Dans la page Ser vices de rôle, sélectionnez Autorité de cer tification et Inscription web de l’autorité de
cer tification, puis cliquez sur Suivant .
14. Dans la page Type d’installation, cliquez Enterprise CA, puis cliquez sur Suivant .
15. Dans la page Type d’ac, cliquez sur Ca racine, puis sur Suivant .
16. Dans la page Clé privée, cliquez sur Utiliser une clé privée existante, cliquez sur Sélectionner un
certificat et utiliser sa clé privée associée, puis cliquez sur Suivant .
17. Dans la page Cer tificat existant, sélectionnez <Ser ver_Name> le cer tificat -CA, puis cliquez sur
Suivant .
NOTE
<Ser ver_Name> est le nom du serveur de destination.
18. Dans la page Base de données de l’ac, acceptez les emplacements par défaut, puis cliquez sur Suivant .
19. Dans la page Confirmation, confirmez vos sélections, puis cliquez sur Configurer .
20. Lorsque la configuration est terminée, cliquez sur Fermer.
Vérifier l'installation
1. Dans le Gestionnaire de serveur, cliquez sur Outils, puis sur Autorité de cer tification.
2. Cliquez avec le bouton droit sur le nom de l’ac, puis cliquez sur Propriétés.
3. Dans la boîte de dialogue Propriétés, cliquez sur l’onglet Extensions.
4. Dans la liste qui s’affiche, cliquez
http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl sur .
5. Assurez-vous que les options suivantes sont sélectionnées :
Inclure dans les CRL. Les clients l’utilisent pour rechercher des emplacements de la CRL
delta.
Inclure dans l’extension CDP des cer tificats émis.
6. Cliquez sur OK pour enregistrer vos modifications.
7. Lorsque vous êtes invité à redémarrer les services de certificats Active Directory, cliquez sur Oui.
8. Fermez la console de l’autorité de certification.
Ajouter un modèle de certificat à l’ac

1. Dans le Gestionnaire de serveur, cliquez sur Outils, puis sur Autorité de cer tification.
2. Double-cliquez sur le nom de l’ac pour développer l’élément.
3. Right-Click modèles de cer tificat, cliquez sur Nouveau, puis sur Modèle de certificat à émettre.
4. Dans la liste, cliquez sur Windows modèle de certificat d’ordinateur solutions serveur, puis cliquez sur OK .
5. Fermez la console de l’autorité de certification.
Ajouter le serveur et les clients au tableau de bord

1. Ouvrez une fenêtre d’invite de commandes en tant qu’administrateur.
2. Tapez cd « \Program Files\Windows Server\Bin », puis appuyez sur entrée.
3. Tapez WssPowerShell.exe, puis appuyez sur la touche Entrée.
4. Tapez Add-WssLocalMachineCert, puis appuyez sur entrée.
5. Redémarrez le serveur.
6. Ré-exécutez l’installation du connecteur sur tous les ordinateurs clients.
Lier le certificat aux sites web Internet Information Services (IIS )
1. Ouvrez le Gestionnaire de services Internet.
2. Choisissez tous les sites web qui utilisent les anciens certificats d’ordinateur, puis remplacez-les par les
nouveaux certificats.
Comment supprimer manuellement Enterprise
Windows certificat d’un domaine Windows
2000/2003
Cet article a été rédigé par Yuval Sinay, MVP Microsoft.

Symptômes
Dans certaines organisations, il existe des procédures de sauvegarde régulières pour Enterprise Windows
autorité de certification. En cas de problème de serveur (logiciel/matériel), vous devrez peut-être réinstaller
l’Enterprise Windows de certification. Avant de pouvoir réinstaller l’autorité de certification Enterprise Windows,
vous devrez peut-être supprimer manuellement les objets et les données qui appartiennent à l’Enterprise
Windows d’origine et qui résident dans le Windows Active Directory.
Cause
Enterprise Windows’autorité de certification enregistre les paramètres de configuration et les données dans
Windows Active Directory.
Résolution
R. Sauvegarde :
Il est recommandé de back up all the nodes that contain Active Directory-related data before and after you
follow this procedure, including:
Windows Contrôleurs de domaine
Serveurs Exchange
Connecteur Active Directory
Windows Serveur avec services pour Unix
IsA Server Enterprise
Enterprise Windows certificate authority
Utilisez la procédure suivante en dernier recours. Cela peut affecter votre environnement de production et
nécessiter le redémarrage de certains nodes/services.
B. Active Director y Clean :
NOTE
Connectez-vous au système avec un compte qui dispose des autorisations :
1. Administrateur d’entreprise
2. Administrateur de domaine
3. Administrateur d’autorité de certification
4. Administrateur de schéma (le serveur qui fonctionne en tant que gestionnaire de schéma FSMO doit être en ligne
pendant le processus).
Pour supprimer tous les objets des services de certification d’Active Directory :
1. Démarrez « Sites et ser vices Active Director y ».
2. Sélectionnez l’option de menu « Affichage », puis le nœud «Afficher les ser vices ».
3. Développez «Ser vices », puis «Ser vices à clé publique ».
4. Sélectionnez le nœud « AIA ».
5. Dans le volet droit, recherchez l’objet « cer tificateAuthority » pour votre autorité de certification.
Supprimez l’objet.
6. Sélectionnez le nœud « CDP ».
7. Dans le volet droit, recherchez l’objet Container du serveur sur lequel les services de certification sont
installés. Supprimez le conteneur et les objets qu’il contient.
8. Sélectionnez le nœud «Autorités de certification ».
9. Dans le volet droit, recherchez l’objet « cer tificateAuthority » pour votre autorité de certification.
Supprimez l’objet.
10. Sélectionnez le nœud « Enrollment Ser vices ».
11. Dans le volet droit, vérifiez que l’objet « pKIEnrollmentSer vice » pour votre autorité de certification,
supprimez-le.
12. Sélectionnez le nœud « Modèles de certificats ».
13. Dans le volet droit, supprimez tous les modèles de certificat.
NOTE
Supprimez tous les modèles de certificats uniquement si aucune autre Enterprise de certification n’est installée
dans la forêt. Si les modèles sont supprimés par inadvertance, restituer les modèles à partir de la sauvegarde.
14. Sélectionnez le nœud «Ser vices à clé publique » et recherchez l’objet « NTAuthCer tificates ».
15. S’il n’existe aucune autre Enterprise ou des ca autonomes installés dans la forêt, supprimez l’objet, sinon
laissez-le seul.
16. Utilisez la commande « Sites et ser vices Active Director y » ou « du kit de ressources Windows pour
forcer la réplication vers les autres contrôleurs de domaine dans le Repadmin domaine/la forêt.
Nettoyage du contrôleur de domaine
Une fois l’ac supprimée, les certificats qui ont été délivrés à tous les contrôleurs de domaine doivent être
supprimés. Vous pouvez le faire facilement à l’aide DSSTORE.EXE du Kit de ressources :
Vous pouvez également supprimer les anciens certificats de contrôleur de domaine à l’aide de la certutil
commande :
1. À l’invite de commandes sur un contrôleur de domaine, tapez : certutil -dcinfo deleteBad .
2. Certutil.exe tentera de valider tous les certificats dc délivrés aux contrôleurs de domaine. Les certificats
qui échouent à la validation seront supprimés. À ce stade, vous pouvez réinstaller les services de
certificats. Une fois l’installation terminée, le nouveau certificat racine est publié dans Active Directory.
Lorsque le domaine
les clients actualisent leur stratégie de sécurité, ils téléchargent automatiquement le nouveau certificat
racine dans leurs magasins racines de confiance. o forcer l’application de la stratégie de sécurité.
3. À l’invite de commandes, tapez gpupdate /target: computer .
NOTE
Si l’autorité de certification Enterprise Windows a publié un certificat ordinateur/utilisateur ou d’autres types de
certificats (certificat de serveur web, etc.), il est recommandé de supprimer les anciens certificats avant de
réinstaller le certificat Enterprise Windows.
Comment déplacer une autorité de certification vers
un autre serveur
Cet article explique comment déplacer une autorité de certification vers un autre serveur.
S’applique à : Windows Server 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2,
Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows
Server 2022
NOTE
Cet article s’applique à Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows
Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022. Le support
pour Windows 2000 a pris fin le 13 juillet 2010. Le centre de solutions de fin de support Windows 2000 est un point de
départ pour la planification de votre stratégie de migration à partir de Windows 2000. La prise en charge de Windows
2008 et 2008 R2 a pris fin le 14 janvier 2020. Pour plus d’informations, consultez la politique de cycle de vie Support
Microsoft.
Résumé
Les autorités de certification sont la composante centrale de l’infrastructure à clé publique (PKI) d’une
organisation. Les autorités de certification sont configurées pour exister pendant de nombreuses années ou
décennies, pendant lesquelles le matériel qui héberge l’autorité de certification est probablement mis à niveau.
NOTE
Pour déplacer une autorité de certification d’un serveur qui exécute Windows serveur 2000 vers un serveur qui exécute
Windows Server 2003, vous devez d’abord mettre à niveau le serveur d’autorité de certification qui exécute Windows
serveur 2000 vers Windows Server 2003. Vous pouvez ensuite suivre les étapes décrites dans cet article.
Assurez-vous que %Systemroot% du serveur cible correspond au %Systemroot% du serveur à partir duquel la
sauvegarde de l’état du système est effectuée.
Vous devez modifier le chemin des fichiers d’autorité de certification lorsque vous installez les composants du
serveur d’autorité de certification afin qu’ils correspondent à l’emplacement de la sauvegarde. Par exemple, si
vous sauvegardez à partir du dossier Certlog D:\Winnt\System32\, vous devez restaurer la sauvegarde dans le
dossier Certlog D:\Winnt\System32\. Vous ne pouvez pas restaurer la sauvegarde dans le dossier Certlog
C:\Winnt\System32\. Après avoir restauré la sauvegarde, vous pouvez déplacer les fichiers de base de données
d’autorité de certification vers l’emplacement par défaut.
Si vous essayez de restaurer la sauvegarde et que % Systemroot% de la sauvegarde et le serveur cible ne
correspondent pas, vous pouvez recevoir le message d’erreur suivant :
La restauration d’une image incrémentielle ne peut pas être effectuée avant d’effectuer une restauration à
partir d’une image complète. Le nom du répertoire est non valide. 0x8007010b (WIN32/HTTP:267)
Le déplacement des services de certificats d’un système d’exploitation 32 bits vers un système d’exploitation 64
bits ou inversement peut échouer avec l’un des messages d’erreur suivants :
Les données attendues n’existent pas dans ce répertoire.
Impossible d’effectuer la restauration d’une image incrémentielle avant d’effectuer une restauration à partir
d’une image complète 0x8007010b (WIN32/HTTP:267)
Le format de la base de données passe de la version 32 bits à la version 64 bits provoque des incompatibilités et
la restauration est bloquée. Cela ressemble au passage de Windows 2000 à Windows Server 2003 CA. Toutefois,
il n’existe aucun chemin de mise à niveau entre une version 32 bits de Windows Server 2003 et une version 64
bits. Par conséquent, vous ne pouvez pas déplacer une base de données 32 bits existante vers une base de
données 64 bits sur un ordinateur Windows Server 2003. Toutefois, vous pouvez effectuer une mise à niveau de
l’autorité de certification Windows Server 2003 (exécutée sur Windows Server 2003 x86) vers Windows autorité
de certification Server 2008 R2 (en cours d’exécution sur Windows Server 2008 R2 x64). Cette mise à niveau est
prise en charge.
Une version x64 de Windows Server 2003 R2 CD2 met uniquement à jour les versions 64 bits de Windows
Server 2003 basées sur l’architecture EM64T ou sur l’architecture AMD64.
Sauvegarder et restaurer les clés et la base de données de l’autorité

de certification
IMPORTANT
restaurer en cas de problème. Pour plus d’informations sur la procédure de sauvegarde et de restauration du Registre,
consultez l’article Comment sauvegarder et restaurer le Registre dans Windows.
1. Notez les modèles de certificat qui sont configurés dans le dossier Modèles de certificat dans le
composant logiciel enfichable Autorité de certification. Les paramètres des modèles de certificat sont
stockés dans Active Directory. Ils ne sont pas automatiquement sauvegardés. Vous devez configurer
manuellement les paramètres des modèles de certificat sur la nouvelle autorité de certification pour
conserver le même ensemble de modèles.
NOTE
Le dossier Modèles de certificats existe uniquement sur une autorité de certification d’entreprise. Les autorités de
certification autonomes n’utilisent pas de modèles de certificat. Par conséquent, cette étape ne s’applique pas à
une autorité de certification autonome.
2. Utilisez le composant logiciel enfichable Autorité de certification pour sauvegarder la base de données
d’autorité de certification et la clé privée. Pour cela, procédez comme suit :
a. Dans le composant logiciel enfichable Autorité de certification, cliquez avec le bouton droit sur le nom
de l’autorité de certification, cliquez sur Toutes les tâches , puis sur Sauvegarder l’autorité de
cer tification pour démarrer l’Assistant Sauvegarde de l’autorité de certification.
b. Cliquez sur Suivant , puis sur Clé privée et cer tificat d’autorité de cer tification .
c. Cliquez sur La base de données de cer tificat et le journal de la base de données de
cer tificats .
d. Utilisez un dossier vide comme emplacement de sauvegarde. Assurez-vous que le nouveau serveur
peut accéder au dossier de sauvegarde.
e. Cliquez sur Suivant . Si le dossier de sauvegarde spécifié n’existe pas, l’Assistant Sauvegarde de
l’autorité de certification le crée.
f. Tapez, puis confirmez un mot de passe pour le fichier de sauvegarde de clé privée d’autorité de
certification.
g. Cliquez sur Suivant , puis vérifiez les paramètres de sauvegarde. Les paramètres suivants doivent être
affichés :
Clé privée et cer tificat d’autorité de cer tification
Journal émis et demandes en attente
h. Cliquez sur Terminer .
3. Enregistrez les paramètres du Registre pour cette autorité de certification. Pour cela, procédez comme
suit :
a. Cliquez sur Démarrer , puis Exécuter , entrez regedit dans la zone Ouvrir et cliquez sur OK .
b. Recherchez la sous-clé de Registre suivante et cliquez dessus avec le bouton droit :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
c. Cliquez sur Expor ter .
d. Enregistrez le fichier de Registre dans le dossier de sauvegarde de l’autorité de certification que vous
avez défini à l’étape 2d.
4. Supprimez Certificate Services de l’ancien serveur.
NOTE
Cette étape supprime des objets d’Active Directory. N’effectuez pas cette étape dans l’ordre. Si la suppression de
l’autorité de certification source est effectuée après l’installation de l’autorité de certification cible (étape 6 dans
cette section), l’autorité de certification cible devient inutilisable.
5. Renommez l’ancien serveur ou déconnectez-le définitivement du réseau.

6. Installez Certificate Services sur le nouveau serveur. Pour cela, procédez comme suit.
NOTE
Le nouveau serveur doit avoir le même nom d’ordinateur que l’ancien serveur.
a. Dans le Panneau de configuration, double-cliquez sur Ajout/Suppression de programmes .

b. Cliquez sur Ajouter/Supprimer Windows Composants , cliquez sur Ser vices de cer tificats dans
l’Assistant Composants Windows, puis sur Suivant .
c. Dans la boîte de dialogue Type d’autorité de certification, cliquez sur le type d’autorité de
certification approprié.
d. Cliquez sur Utiliser les paramètres personnalisés pour générer la paire de clés et le
cer tificat d’autorité de certification, puis cliquez sur Suivant .
e. Cliquez sur Impor ter , tapez le chemin d’accès du . Fichier P12 dans le dossier de sauvegarde, tapez le
mot de passe que vous avez choisi à l’étape 2f, puis cliquez sur OK .
f. Dans la boîte de dialogue Paire de clés publique et privée , vérifiez que l’option Utiliser des
clés existantes est cochée.
g. Cliquez deux fois sur Suivant .
h. Acceptez les paramètres par défaut de la base de données de certificats Paramètres, cliquez sur
Suivant , puis cliquez sur Terminer pour terminer l’installation des services de certificats.
IMPORTANT
Si le nouveau serveur a un nom d’ordinateur différent , procédez comme suit :
a. Dans le Panneau de configuration, double-cliquez sur Ajout/Suppression de programmes .

c. Dans la boîte de dialogue Type d’autorité de certification, cliquez sur le type d’autorité de
d. Cliquez sur Utiliser les paramètres personnalisés pour générer la paire de clés et le
cer tificat d’autorité de certification, puis cliquez sur Suivant .
e. Cliquez sur Impor ter , tapez le chemin d’accès du . Fichier P12 dans le dossier de sauvegarde, tapez le
mot de passe que vous avez choisi à l’étape 2f, puis cliquez sur OK .
f. Dans la boîte de dialogue Paire de clés publique et privée , vérifiez que l’option Utiliser des
clés existantes est cochée.
g. Cliquez deux fois sur Suivant .
h. Acceptez les paramètres par défaut de la base de données de certificats Paramètres, cliquez sur
Suivant , puis cliquez sur Terminer pour terminer l’installation des services de certificats.
i. Modifiez la clé de Registre précédemment exportée à l’étape 3 comme suit :
a. Cliquez avec le bouton droit sur la clé exportée.
b. Modifier.
c. Remplacez la valeur CASer verName par le nouveau nom du serveur.
d. Enregistrer et fermer.
7. Arrêtez le service Certificate Services.
8. Recherchez le fichier de Registre que vous avez enregistré à l’étape 3, puis double-cliquez dessus pour
importer les paramètres du Registre. Si le chemin d’accès affiché dans l’exportation du Registre à partir
de l’ancienne autorité de certification diffère du nouveau chemin d’accès, vous devez ajuster votre
exportation de Registre en conséquence. Par défaut, le nouveau chemin d’accès est C:\Windows dans
Windows Server 2003.
9. Utilisez le composant logiciel enfichable Autorité de certification pour restaurer la base de données de
l’autorité de certification. Pour cela, procédez comme suit :
a. Dans le composant logiciel enfichable Autorité de certification, cliquez avec le bouton droit sur le
nom de l’autorité de certification, cliquez sur Toutes les tâches , puis sur Restaurer l’autorité
de cer tification .
L’Assistant Restauration de l’autorité de certification démarre.
c. Cliquez sur La base de données de cer tificat et le journal de la base de données de
cer tificats .
d. Tapez l’emplacement du dossier de sauvegarde, puis cliquez sur Suivant .
e. Vérifiez les paramètres de sauvegarde. Les paramètres Journal émis et Demandes en attente
doivent être affichés.
f. Cliquez sur Terminer , puis sur Oui pour redémarrer Les services de certificats lorsque la base de
données de l’autorité de certification est restaurée.
Vous pouvez recevoir l’erreur suivante pendant le processus d’autorité de certification de restauration si
le dossier de sauvegarde de l’autorité de certification n’est pas au format de structure de dossiers correct :
---------------------------
Services de certificats Microsoft
---------------------------
Les données attendues n’existent pas dans ce répertoire.
Choisissez un autre répertoire. Le nom du répertoire est non valide. 0x8007010b (WIN32/HTTP : 267)
La structure de dossiers correcte est la suivante :

C:\Ca_Backup\CA_NAME.p12
C:\Ca_Backup\Database\certbkxp.dat
C:\Ca_Backup\Database\edb#####.log
C:\Ca_Backup\Database\CA_NAME.edb
Où C:\Ca_Backup est le dossier que vous avez choisi lors de la phase d’autorité de certification de
sauvegarde à l’étape 2.
10. Dans le composant logiciel enfichable Autorité de certification, ajoutez ou supprimez manuellement des
modèles de certificat pour dupliquer les paramètres de modèles de certificat que vous avez notés à
l’étape 1.
NOTE
Si vous rencontrez des problèmes lors de la publication de nouveaux modèles ou de vos modèles personnalisés, suivez les
étapes ci-dessous.
1. À partir d’un contrôleur de domaine dans la forêt où vous avez migré le rôle d’autorité de certification,
démarrez ADSI Edit.
2. Cliquez avec le bouton droit sur ADSI Edit -> Connecter to -> In Select a well known Naming Context
choose Configuration -> OK.
3. Accédez à CN=Configuration | CN=Services | CN=| des services à clé publique CN=Services d’inscription.
4. Cliquez avec le bouton droit sur l’autorité de certification dans le volet droit à partir duquel vous souhaitez
vous inscrire, puis cliquez sur Propriétés . Recherchez l’attribut indicateurs ; et vérifiez qu’il est défini sur 10.
5. Si ce n’est pas le cas, définissez-le sur 10 et attendez ou forcez manuellement la réplication Active Directory.
6. Fermez ADSI Edit et, à partir de votre serveur d’autorité de certification, assurez-vous que vous pouvez
désormais publier vos nouveaux modèles.
Sauvegarder et restaurer les clés d’autorité de certification et la base

de données dans Windows serveur 2000
IMPORTANT
1. Notez les modèles de certificat qui sont configurés dans le dossier Modèles de certificat dans le
composant logiciel enfichable Autorité de certification. Les paramètres des modèles de certificat sont
stockés dans Active Directory. Ils ne sont pas automatiquement sauvegardés. Vous devez configurer
manuellement les paramètres des modèles de certificat sur la nouvelle autorité de certification pour
conserver le même ensemble de modèles.
NOTE
Le dossier Modèles de certificats existe uniquement sur une autorité de certification d’entreprise. Les autorités de
certification autonomes n’utilisent pas de modèles de certificat. Par conséquent, cette étape ne s’applique pas à
une autorité de certification autonome.
2. Utilisez le composant logiciel enfichable Autorité de certification pour sauvegarder la base de données
d’autorité de certification et la clé privée. Pour cela, procédez comme suit :
a. Dans le composant logiciel enfichable Autorité de certification, cliquez avec le bouton droit sur le nom
de l’autorité de certification, cliquez sur Toutes les tâches , puis sur Sauvegarder l’autorité de
cer tification pour démarrer l’Assistant Sauvegarde de l’autorité de certification.
c. Cliquez sur Journal des cer tificats émis et file d’attente de demandes de cer tificat en
attente.
d. Utilisez un dossier vide comme emplacement de sauvegarde. Assurez-vous que le nouveau serveur
peut accéder au dossier de sauvegarde.
e. Cliquez sur Suivant . Si le dossier de sauvegarde spécifié n’existe pas, l’Assistant Sauvegarde de
l’autorité de certification le crée.
f. Tapez, puis confirmez un mot de passe pour le fichier de sauvegarde de clé privée d’autorité de
certification.
g. Cliquez deux fois sur Suivant , puis vérifiez les paramètres de sauvegarde. Les paramètres suivants
doivent être affichés :
Clé privée et cer tificat d’autorité de cer tification
Journal émis et demandes en attente
h. Cliquez sur Terminer .
3. Enregistrez les paramètres du Registre pour cette autorité de certification. Pour cela, procédez comme
suit :
b. Recherchez, puis cliquez avec le bouton droit sur la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
c. Cliquez sur Configuration , puis sur Expor ter le fichier de Registre dans le menu Registre .
d. Enregistrez le fichier de Registre dans le dossier de sauvegarde de l’autorité de certification que vous
avez défini à l’étape 2d.
4. Supprimez Certificate Services de l’ancien serveur.
NOTE
Cette étape supprime des objets d’Active Directory. N’effectuez pas cette étape dans l’ordre. Si la suppression de
l’autorité de certification source est effectuée après l’installation de l’autorité de certification cible (étape 6 dans
cette section), l’autorité de certification cible devient inutilisable.
5. Renommez l’ancien serveur ou déconnectez-le définitivement du réseau.

6. Installez Certificate Services sur le nouveau serveur. Pour cela, procédez comme suit.
NOTE
Le nouveau serveur doit avoir le même nom d’ordinateur que l’ancien serveur.
a. Dans le Panneau de configuration, double-cliquez sur Ajout/Suppression de programmes.

c. Dans la boîte de dialogue Type d’autorité de cer tification , cliquez sur le type d’autorité de
d. Cliquez sur Options avancées , puis sur Suivant .
e. Dans la boîte de dialogue Paire de clés publique et privée , cliquez sur Utiliser les clés
existantes , puis sur Impor ter .
f. Tapez le chemin d’accès du . Fichier P12 dans le dossier de sauvegarde, tapez le mot de passe que
vous avez choisi à l’étape 2f, puis cliquez sur OK .
g. Cliquez sur Suivant , tapez une description d’autorité de certification le cas échéant, puis cliquez sur
Suivant.
h. Acceptez les paramètres par défaut de l’emplacement Stockage données, cliquez sur Suivant , puis
cliquez sur Terminer pour terminer l’installation des services de certificats.
7. Arrêtez le service Certificate Services.
8. Recherchez le fichier de Registre que vous avez enregistré à l’étape 3, puis double-cliquez dessus pour
importer les paramètres du Registre.
9. Utilisez le composant logiciel enfichable Autorité de certification pour restaurer la base de données de
l’autorité de certification. Pour cela, procédez comme suit :
a. Dans le composant logiciel enfichable Autorité de certification, cliquez avec le bouton droit sur le
nom de l’autorité de certification, cliquez sur Toutes les tâches , puis sur Restaurer l’autorité
de cer tification .
L’Assistant Restauration de l’autorité de certification démarre.
b. Cliquez sur Suivant , puis sur Journal des cer tificats émis et file d’attente de demandes de
cer tificat en attente .
c. Tapez l’emplacement du dossier de sauvegarde, puis cliquez sur Suivant .
d. Vérifiez les paramètres de sauvegarde. Les paramètres suivants doivent être affichés :
Journal émis
Demandes en attente
e. Cliquez sur Terminer , puis sur Oui pour redémarrer Les services de certificats lorsque la base de
données de l’autorité de certification est restaurée.
10. Dans le composant logiciel enfichable Autorité de certification, ajoutez ou supprimez manuellement des
modèles de certificat pour dupliquer les paramètres de modèles de certificat que vous avez notés à
l’étape 1.
Pour plus d’informations sur les scénarios de mise à niveau et de migration pour Windows Server 2003 et
Windows Server 2008, consultez le livre blanc « Guide de mise à niveau et de migration des services de
certificats Active Directory ». Pour consulter le livre blanc, consultez le Guide de mise à niveau et de migration
des services de certificats Active Directory.
Déplacer la base de données du serveur de
certificats et les fichiers journaux
Cet article explique comment déplacer la base de données et les fichiers journaux d’un serveur de certificats.
IMPORTANT
Cet article contient des informations sur la modification du Registre. Avant de modifier le Registre, veillez à le back up et
assurez-vous que vous comprenez comment restaurer le Registre en cas de problème. Pour plus d’informations sur la
façon de restaurer, de restaurer et de modifier le Registre, cliquez sur le numéro d’article suivant pour afficher l’article dans
la Base de connaissances Microsoft :
256986 description du Registre microsoft Windows
Déplacer la base de données du serveur de certificats et les fichiers

journaux
WARNING
Si vous utilisez l’Éditeur du Registre de manière incorrecte, vous risquez de graves problèmes qui peuvent nécessiter la
réinstallation de votre système d’exploitation. Microsoft ne peut pas garantir que vous pouvez résoudre les problèmes
résultant de l’utilisation incorrecte de l’Éditeur du Registre. Utilisez l’Éditeur du Registre à vos risques et périls.
Pour modifier l’emplacement de la base de données du serveur de certificats et des fichiers journaux, utilisez les
étapes suivantes :
1. Arrêtez le service des services de certificats.
2. Copiez les fichiers de base de données et les fichiers journaux vers un nouvel emplacement. Le chemin
d’accès à la base de données par défaut est : %SystemRoot%\System32\CertLog
3. Modifiez les chemins d’accès aux bases de données dans les entrées de Registre suivantes pour refléter le
nouveau chemin d’accès :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBDirectory
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBLogDirectory
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBSystemDirectory
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBTempDirectory
4. Démarrez le service des services de certificats.

5. Consultez le journal des événements d’application pour l’événement CertSvc 26 pour vérifier que le
service des services de certificats a démarré correctement. Un message d’avertissement s’affiche si le
service ne démarre pas correctement. Si cela se produit, vérifiez la syntaxe des chemins d’accès dans le
Registre.
Vous devrez peut-être modifier les autorisations NTFS pour accorder des autorisations contrôle total au compte
système. Par défaut, le compte système et les groupes Administrateurs et administrateurs Enterprise
administrateurs ont un accès contrôle total pour le dossier CertLog.
Certificats racines de confiance requis
Cet article répertorie les certificats racines de confiance requis par Windows d’exploitation. Ces certificats
racines de confiance sont requis pour que le système d’exploitation s’exécute correctement.
Résumé
Dans le cadre d’une procédure de gestion de la confiance de l’infrastructure à clé publique (PKI), certains
administrateurs peuvent décider de supprimer des certificats racines de confiance d’un domaine, d’un serveur
ou d’un client Windows. Toutefois, les certificats racine répertoriés dans la section Certificats racine nécessaires
et de confiance dans cet article sont requis pour que le système d’exploitation fonctionne correctement. La
suppression des certificats suivants peut limiter les fonctionnalités du système d’exploitation ou entraîner
l’échec de l’ordinateur. Ne les supprimez pas.
Certificats racines nécessaires et fiables

Les certificats suivants sont nécessaires et fiables dans :
Windows 7
Windows Vista
Windows Server 2008 R2
Windows Server 2008
DAT E
N UM ÉRO DE D’EXP IRAT IO RÔ L ES N O M FA C IL E
ÉM IS P O UR ÉM IS PA R SÉRIE N P RÉVUS À RET EN IR ÉTAT
Autorité Autorité 00c1008b3c3 12/31/2020 Tous Autorité R

racine racine c8811d13ef6 racine
Microsoft Microsoft 63ecdf40 Microsoft
Ca du temps Ca du temps 00 12/31/2020 Horodatage Ca du temps R

de de de
décongélation décongélation décongélation
Autorité de Autorité de 79ad16a14aa 5/9/2021 Tous Autorité de R

certification certification 0a5ad4c7358 certification
racine racine f407132e65 racine
Microsoft Microsoft Microsoft
Les certificats ci-après sont nécessaires et fiables dans Windows XP et Windows Server 2003 :
DAT E
N UM ÉRO DE D’EXP IRAT IO RÔ L ES N O M FA C IL E
ÉM IS P O UR ÉM IS PA R SÉRIE N P RÉVUS À RET EN IR ÉTAT
Copyright (c) Copyright (c) 01 12/30/1999 Horodatage Microsoft R

1997 1997 Timestamp
Microsoft Microsoft Root
Corp. Corp.
Autorité Autorité 01 12/31/1999 Messagerie Microsoft R

racine racine sécurisée, Authenticode(
Microsoft Microsoft signature de tm) Root
Authenticode( Authenticode( code
tm) tm)

AUCUNE AUCUNE 4a19d2388c8 1/7/2004 Horodatage VeriSign Time R

RESPONSABIL RESPONSABIL 2591ca55d73 Stamping CA
ITÉ ITÉ 5f155ddca3
ACCEPTÉE, ACCEPTÉE,
(c)97 VeriSign, (c)97 VeriSign,
Inc. Inc.
VeriSign VeriSign 03c78f37db9 1/7/2004 Messagerie VeriSign R

Commercial Commercial 228df3cbb1a sécurisée, Commercial
Software Software ad82fa6710 signature de Software
Publishers CA Publishers CA code Publishers CA

de de de
Autorité de Autorité de 79ad16a14aa 5/9/2021 Tous Autorité de R

certification certification 0a5ad4c7358 certification
racine racine f407132e65 racine
Microsoft Microsoft Microsoft
Les certificats ci-après sont nécessaires et fiables dans Microsoft Windows 2000 :
DAT E
N UM ÉRO DE D’EXP IRAT IO RÔ L ES NOM
ÉM IS P O UR ÉM IS PA R SÉRIE N P RÉVUS C O N VIVIA L ÉTAT
Copyright (c) Copyright (c) 01 12/30/1999 Horodatage Microsoft R

1997 1997 Timestamp
Microsoft Microsoft Root
Corp. Corp.
Autorité Autorité 01 12/31/1999 Messagerie Microsoft R

racine racine sécurisée, Authenticode(
Microsoft Microsoft signature de tm) Root
Authenticode( Authenticode( code
tm) tm)
DAT E
N UM ÉRO DE D’EXP IRAT IO RÔ L ES NOM
ÉM IS P O UR ÉM IS PA R SÉRIE N P RÉVUS C O N VIVIA L ÉTAT

AUCUNE AUCUNE 4a19d2388c8 1/7/2004 Horodatage VeriSign Time R

RESPONSABIL RESPONSABIL 2591ca55d73 Stamping CA
ITÉ ITÉ 5f155ddca3
ACCEPTÉE, ACCEPTÉE,
(c)97 VeriSign, (c)97 VeriSign,
Inc. Inc.
VeriSign VeriSign 03c78f37db9 1/7/2004 Messagerie VeriSign R

Commercial Commercial 228df3cbb1a sécurisée, Commercial
Software Software ad82fa6710 signature de Software
Publishers CA Publishers CA code Publishers CA

de de de
Certains certificats répertoriés dans les tableaux précédents ont expiré. Toutefois, ces certificats sont nécessaires
pour la compatibilité ascendante. Même s’il existe un certificat racine approuvé expiré, tout ce qui a été signé à
l’aide de ce certificat avant la date d’expiration nécessite la validation du certificat racine approuvé. Tant que les
certificats expirés ne sont pas révoqués, ils peuvent être utilisés pour valider tout ce qui a été signé avant leur
expiration.
Comment définir une autorité de certification
Enterprise subordonnée de manière à avoir une
période de validité de certificat différente de celle
de l’autorité de certification parente
Cet article explique comment définir une autorité de certification subordonnée d’entreprise pour qu’elle
présente une période de validité de certificat différente de celle de l’autorité de certification parente.
Résumé
Vous pouvez utiliser les étapes suivantes pour accorder à une ca subordonnée une période de validation de
certificat différente de celle de l’ac parent. Ce processus est divisé en trois étapes :
Étape 1 : Définir la période de validation sur l’ac parent. Étape 2 : Installer l’ac subordonnée. Étape 3 : Revenir à
l’heure de validation sur l’ac parent.
1. Définissez la période de validation sur l’ac parent. Pour ce faire, utilisez les commandes suivantes pour
définir la période de validation souhaitée sur l’ac parent qui émettra le certificat de l’ac subordonnée :
certutil -setreg ca\ValidityPeriod "Weeks"

certutil -setreg ca\ValidityPeriodUnits "3"
2. Installez l’ac subordonnée. Veillez à utiliser l’ac parent que vous avez utilisée à l’étape 1.
3. Réinitialisez la période de validation sur l’ac parent qui a émis le certificat de l’ac subordonnée (par
exemple, « 2 ans », qui est la valeur par défaut). Pour ce faire, utilisez les commandes suivantes :
certutil -setreg ca\ValidityPeriod "Years"

certutil -setreg ca\ValidityPeriodUnits "2"
NOTE
Si vous exécutez sur l’autorité de certification subordonnée, la propriété ValidityPeriod et la propriété
ValidityPeriodUnits sont toujours synchronisées avec l’autorité de certification parente, même si le certificat de
l’autorité de certification subordonnée n’est valide que pendant trois certutil -getreg ca\val* semaines.
Comment configurer l’authentification basée sur les
certificats dans les forêts sans confiance pour un
serveur web
Cet article explique comment configurer un serveur web pour utiliser des cartes à puce pour l’authentification
basée sur des certificats entre forêts lorsque les forêts d’utilisateurs et la forêt de ressources ne s’trustent pas
mutuellement.
Configuration de l’environnement
Envisagez un environnement qui utilise la configuration suivante :
Forêt d’utilisateurs nommée Contoso.com .
Forêt de ressources nommée Fabrikam.com . La forêt a Tailspintoys.com été ajoutée en tant que nom
d’utilisateur principal (UPN) de remplacement.
Il n’existe aucune relation d’confiance entre les deux forêts.
Les cartes à puce utilisateur utilisent des certificats qui ont des entrées SAN (Autre nom de l’objet) au format
user@tailspintoys.com .
Un serveur web IIS configuré pour l’authentification basée sur les certificats Active Directory.
Configurez Active Directory et le serveur web comme décrit dans les procédures suivantes.
Configurer Active Directory

Pour configurer la forêt de ressources pour authentifier les cartes à puce, suivez les étapes suivantes :
1. Assurez-vous qu’un certificat d’authentification Kerberos authentification authentification KDC (EKU) a été
émis aux contrôleurs de domaine.
2. Assurez-vous que le certificat de l’ac émettrice du certificat de l’utilisateur est installé dans Enterprise
magasin NTAUTH.
Pour publier le certificat de l’ac émettrice dans le domaine, exécutez la commande suivante à une invite
de commandes :
certutil -dspublish -f <filename> NTAUTHCA
Dans cette commande, représente le nom du fichier de certificat de l’ac, <filename> qui a une extension
.cer.
3. Les utilisateurs doivent avoir des comptes qui utilisent l’UPN de remplacement de la forêt de ressources.
Pour configurer la forêt d’utilisateurs, suivez les étapes suivantes :
1. Assurez-vous que l’authentification par carte à puce et l’authentification du client sont définies dans le
certificat.
2. Assurez-vous que le SAN du certificat utilise l’UPN de l’utilisateur.
3. Assurez-vous d’installer le certificat d’ac émettrice du certificat utilisateur dans Enterprise magasin
NTAUTH.
NOTE
Si vous souhaitez configurer la délégation sur le serveur frontal ou ignorer l’utilisation de l’UPN dans l’attribut SAN
du certificat (itinéraire AltSecID), consultez la section Plus d’informations.
Configurer le serveur web

Pour configurer le serveur Web IIS dans la forêt de ressources, suivez les étapes suivantes :
1. Installez le rôle serveur Web IIS, puis sélectionnez la fonctionnalité Sécurité de l’authentification par
mappage de certificat client.
2. Sur le serveur Web IIS, activez l’authentification par cer tificat client Active Director y.
3. Sur votre site web, configurez SSL Paramètres demander SSL, puis sous Cer tificats clients,
sélectionnez Exiger .
Assurez-vous qu’aucun autre type d’authentification n’est activé sur le site web. Nous vous déconseillons
d’activer l’authentification basée sur les certificats avec tout autre type d’authentification, car le service de
mappage du certificat présenté par l’utilisateur au compte d’utilisateur dans Active Directory est conçu
pour fonctionner uniquement avec le type d’authentification de certificat client Active Director y. Si vous
activez l’authentification anonyme, vous risquez de connaître des résultats inattendus.
Si vous souhaitez configurer la délégation sur ce serveur web de ressources pour interroger un serveur
principal, tel qu’un serveur de base de données ou une ca, vous pouvez également configurer la délégation
contrainte à l’aide d’un compte de service personnalisé. En outre, vous devez configurer le serveur web pour la
délégation contrainte (S4U2Self) ou la transition de protocole. Pour plus d’informations, voir Comment
configurer la délégation Kerberos contrainte pour les pages proxy d’inscription web.
Si vous souhaitez ignorer l’UPN dans l’attribut SAN du certificat de carte à puce de l’utilisateur, vous devez
macaler explicitement à l’aide des attributs AltSecIDou utiliser des conseils de nom.
NOTE
Nous ne recommandons pas cette approche de configuration des certificats de carte à puce.
Si vous publiez l’attribut SAN en tant qu’UPN prévu dans le certificat de l’utilisateur, vous ne devez pas activer
AltSecID.
Pour vérifier le magasin NTAuth sur le serveur web, ouvrez une fenêtre d’invite de commandes et exécutez la
commande suivante :
Certutil -viewstore -enterprise NTAUTH
Références
Préparation d’un domaine non routable pour la synchronisation d’annuaires
Comment importer des certificats d’ac tiers
Liste complète des modifications à apporter pour activer le mappage de certificat client sur IIS à l’aide
Fonctionnement de la carte à puce dans Windows
Attributs de sécurité utilisateur
HowTo: Map a user to a certificate via all the methods available in the altSecurityIdentities attribute
Les certificats d’ac racine valides distribués à l’aide
d’un GPO peuvent apparaître par intermittence
comme non confiance
Cet article fournit une solution de contournement pour un problème dans lequel les certificats d’ac racine
valides distribués à l’aide d’un objet de groupe apparaissent comme non confiance.
Symptômes
IMPORTANT
Les problèmes de certificat de l’autorité de certification racine non confiance peuvent être causés par de nombreux
problèmes de configuration pKI. Cet article n’illustre qu’une des causes possibles du certificat d’ac racine non confiance.
Diverses applications qui utilisent des certificats et l’infrastructure à clé publique (PKI) peuvent faire l’expérience
de problèmes intermittents, tels que des erreurs de connectivité, une ou deux fois par jour/semaine. Ces
problèmes se produisent en raison de l’échec de la vérification du certificat d’entité final. Les applications
affectées peuvent renvoyer différentes erreurs de connectivité, mais elles auront toutes des erreurs de certificat
racine non confiance en commun. Voici un exemple d’erreur :
H EX DÉC IM A L SY M B O L IQ UE VERSIO N T EXT E
0x800b0109 -2146762487 (CERT_E_UNTRUSTEDROOT) Chaîne de certificats traitée,

mais terminée dans un
certificat racine
Toute application pKI qui utilise l’architecture système CryptoAPI peut être affectée par une perte intermittente
de connectivité ou une défaillance de la fonctionnalité PKI/Certificate dependent. À compter d’avril 2020, la liste
des applications connues pour être affectées par ce problème inclut, mais ne sont probablement pas limitées à :
Citrix
RdS (Remote Desktop Service)
Skype
Navigateurs Web
Les administrateurs peuvent identifier et résoudre les problèmes de certificat d’ac racine non confiance en
inspectant le journal CAPI2.
Concentrez vos efforts de dépannage sur les erreurs de chaîne de construction/vérifier la stratégie de chaîne
dans le journal CAPI2 contenant les signatures suivantes. Par exemple :
Erreur <DateTime> CAPI2 11 Build Chain

Erreur <DateTime> CAPI2 30 Vérifier la stratégie de chaîne
Résultat Une chaîne de certificats traitée, mais terminée dans un certificat racine qui n’est pas approuvé par
le fournisseur de confiance.
[valeur] 800b0109
Cause
Des problèmes de certificat d’ac racine non confiance peuvent se produire si le certificat d’ac racine est distribué
à l’aide de la stratégie de groupe suivante :
Configuration de l’ordinateur > Windows Paramètres > sécurité Paramètres stratégies de clé publique
Autorités de > > cer tification racines de confiance
Détails de la cause racine
Lors de la distribution du certificat d’ac racine à l’aide d’un GPO, le contenu du certificat
HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates sera supprimé et écrit à nouveau. Cette
suppression est du point de vue de la conception, car la stratégie de groupe applique les modifications du
Registre.
Les modifications apportées à la zone du Registre Windows qui est réservé aux certificats d’autorité de
certification racine avertiront le composant API de chiffrement de l’application cliente. Et l’application commence
la synchronisation avec les modifications du Registre. La synchronisation est la façon dont les applications sont
tenues à jour et prises en compte de la liste la plus à jour des certificats d’ac racines valides.
Dans certains scénarios, le traitement de la stratégie de groupe prend plus de temps. Par exemple, de nombreux
certificats d’ac racine sont distribués via un GPO (semblable à de nombreuses stratégies ou pare-feu).
Applocker Dans ces scénarios, l’application peut ne pas recevoir la liste complète des certificats d’ac racines de
confiance.
Pour cette raison, les certificats d’entité de fin qui se chaînent à ces certificats d’ac racines manquants seront
rendus comme non confiance. Et divers problèmes liés aux certificats commenceront à se produire. Ce problème
est intermittent et peut être temporairement résolu en réen appliquant à la fois le traitement ou le redémarrage
des GPO.
Si le certificat d’ac racine est publié à l’aide d’autres méthodes, les problèmes peuvent ne pas se produire en
raison de la situation mentionnée plus haut.
Microsoft est conscient de ce problème et travaille à améliorer l’expérience de certificat et d’API de chiffrement
dans une prochaine version de Windows.
Pour résoudre ce problème, évitez de distribuer le certificat d’ac racine à l’aide d’un GPO. Il peut inclure le
ciblage de l’emplacement du Registre (par exemple) pour remettre le certificat d’autorité de certification racine
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates au client.
Lorsque vous stockez le certificat d’ac racine dans un autre magasin de certificats d’ac racine physique, le
problème doit être résolu.
Exemples d’autres méthodes de publication de certificats d’ac racine
Méthode 1 : Utilisez l’outil en ligne de commande et la racine du certificat d’ac stocké dans certutil le fichier
rootca.cer:
certutil -addstore root c:\tmp\rootca.cer

NOTE
Cette commande ne peut être exécutée que par les administrateurs locaux et n’affectera qu’un seul ordinateur.
Méthode 2 : Démarrez certlm.msc (console de gestion des certificats pour l’ordinateur local) et importez le
certificat d’autorité de certification racine dans le magasin physique du Registre.
NOTE
La console certlm.msc ne peut être démarrée que par les administrateurs locaux. En outre, l’importation n’affectera qu’un
seul ordinateur.
Méthode 3 : Utiliser les préférences DPO pour publier le certificat d’ac racine, comme décrit dans les
préférences de stratégie de groupe
Pour publier le certificat d’ac racine, suivez les étapes suivantes :
1. Importez manuellement le certificat racine sur un ordinateur à l’aide de
certutil -addstore root c:\tmp\rootca.cer la commande (voir la méthode 1).
2. Ouvrez GPMC.msc sur l’ordinateur sur qui vous avez importé le certificat racine.
3. Modifiez l’GPO que vous souhaitez utiliser pour déployer les paramètres de Registre de la manière
suivante :
a. Modifiez la configuration ordinateur > stratégie de groupe préférences > Windows Paramètres
> registre >chemin d’accès au certificat racine.
b. Ajoutez le certificat racine à l’GPO comme présenté dans la capture d’écran suivante.
4. Déployez le nouvel GPO sur les ordinateurs sur lequel le certificat racine doit être publié.
Toute autre méthode, outil ou solution de gestion des clients qui distribue les certificats d’ac racine en les
écrivant dans l’emplacement HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates
fonctionne.
Références
Outil Certutil
Magasins de certificats
Emplacements du magasin système
Préférences de stratégie de groupe
API de chiffrement CertControlStore
Les modèles de version 3 (CNG) n’apparaîtront pas
dans l’inscription web de certificat Windows Server
2008 ou Windows Server 2008 R2
Cet article permet de résoudre un problème dans lequel les modèles CNG ou 2008 n’apparaissent pas dans le
menu déroulant modèle demande de certificat avancé.
Symptômes
Lorsque vous utilisez la page d’inscription web de certificat sur un serveur Windows Server 2008 ou Windows
Server 2008 R2, la nouvelle version 3, également appelée modèles CNG ou 2008, n’apparaît pas dans le menu
déroulant modèle demande de certificat avancé. Par conséquent, l’inscription web à l’aide d’un modèle CNG ne
peut pas avoir lieu via la méthode d’inscription web.
Lorsque cela se produit, les certificats peuvent être demandés et inscrits correctement à l’aide des mêmes
modèles que d’autres méthodes d’inscription. En d’autres termes, vous pouvez demander un certificat à partir
de ce modèle à l’aide du logiciel en snap-in MMC de certificats, d’un script, d’une inscription automatique ou
d’une demande exportée. Le problème se produit uniquement lorsque l’inscription web n’autorise pas la
sélection du modèle Version 3.
D’autres causes fréquentes de ne pas pouvoir autoriser la demande d’un certificat peuvent être que le serveur
n’est pas un serveur Enterprise ou que le demandeur n’a pas d’autorisations d’autorisation d’autorisation de
lecture et d’autorisation de demande sur le modèle dans Active Directory.
Cause
Ce comportement est inhérent au produit. Les modèles de version 3 peuvent avoir des exigences de demande
supplémentaires que la méthode d’inscription web peut ne pas remplir.
Résolution
Utilisez une méthode de demande différente pour ces certificats. Outre l’inscription web, toutes les autres
méthodes de requête fonctionnent dans ce scénario.
Une alternative, qui ne doit pas être tentée en production pour les clients sans test approfondi dans un
environnement de test, est disponible pour permettre aux modèles de version 3 d’apparaître dans les pages par
défaut d’inscription web. La raison pour laquelle il n’est pas recommandé est que les pages d’inscription web, là
encore, peuvent ne pas contenir le code nécessaire au certificat pour remplir toutes les données nécessaires, ce
qui peut entraîner un certificat problématique. Gardez cela à l’esprit lorsque vous envisagez d’effectuer les
étapes ci-dessous. Cette option consiste à modifier la version msPKI-Template-Schema-Version de 3 à 2.
En outre, la modification de l’attribut msPKI-Template-Schema-Version entraîne le rechargement du cache de
modèles et du cache CSP disponible.
1. Sur votre contrôleur de domaine, allez à Démarrer, Exécutez, tapez AdsiEdit.msc et appuyez sur
Entrée .
2. Dans AdsiEdit.msc, cliquez avec le bouton droit sur le nœud ADSIEDIT dans le volet gauche et
sélectionnez Connecter À dans le menu qui s’affiche.
3. Dans la boîte de dialogue Paramètres connexion, sélectionnez Configuration dans la section Point
de connexion, puis cliquez sur OK.
4. Développez les nodes dans le volet gauche jusqu’à ce que vous avez atteint votre magasin de modèles
(CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=).
5. Double-cliquez sur le modèle version 3 que vous souhaitez voir apparaître dans la page d’inscription
web.
6. Faites défiler vers le bas et sélectionnez l’attribut msPKI-Template-Schema-Version.
7. Double-cliquez sur l’attribut msPKI-Template-Schema-Version et modifiez la valeur de 3 à 2, puis
cliquez sur OK .
8. Cliquez sur Appliquer . Cela met à jour le modèle et la liste des CSP. Gardez cela à l’esprit si vous utilisez
des CSP tiers dans votre environnement.
9. Go to your web enrollment page (if ran from your CA server) and attempt to enroll the certificate using
an advanced request.
Vous recevez un message d’erreur « Accès refusé »
sur un contrôleur de domaine lorsque vous essayez
de répliquer le service d’annuaire Active Directory
Cet article permet de corriger l’erreur « l’accès est refusé » sur un contrôleur de domaine lorsque vous essayez
de répliquer le service d’annuaire Active Directory.
S’applique à : Windows Server 2012 R2, Windows 10 - toutes les éditions
IMPORTANT
la Base de connaissances Microsoft : 256986 Description du Registre Microsoft Windows
Symptômes
Lorsque vous essayez de répliquer le service d’annuaire Active Directory sur un contrôleur de domaine
exécutant Microsoft Windows Server 2003 avec Service Pack 1 (SP1) ou une version x64 de Microsoft Windows
Server 2003, vous recevez le message d’erreur suivant sur le contrôleur de domaine de destination :
accès refusé
Cause
Ce problème se produit lorsque la valeur de l’entrée de Registre RestrictRemoteClients est 2.
Windows Server 2003 SP1 et les versions x64 de Windows Server 2003 lisent les paramètres d’appel de
procédure distante (RPC) à partir de cette entrée. Si la valeur de l’entrée est 2, le trafic RPC doit être authentifié.
Par conséquent, la réplication Active Directory ne réussit pas. D’autres services RPC sur le contrôleur de
domaine peuvent également être affectés.
Résolution
WARNING
Pour résoudre ce problème, activez le port 135 sur Windows pare-feu, puis utilisez l’une des méthodes
suivantes :
Définissez la valeur de l’entrée de Registre RestrictRemoteClients sur 0 ou 1.
Désactivez les restrictions pour l’objet de stratégie de groupe Clients RPC non authentifiés.
Pour cela, procédez comme suit.
NOTE
Par défaut, le port 135 est bloqué dans Windows Server 2003 SP1 et dans les versions x64 de Windows Server 2003.
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapezfirewall.cpl, puis cliquez sur OK.
2. Cliquez sur l’onglet Exceptions, puis sur Ajouter un por t.
3. Dans la zone Nom, tapez un nom pour le port.
Par exemple, tapez TCP 135.
4. Dans la zone Numéro de por t, tapez 135.
5. Cliquez sur TCP, puis sur OK.
Le nouveau port apparaît sous l’onglet Exceptions.
6. Cliquez pour cocher la case en regard du nouveau port, puis cliquez sur OK.
7. Cliquez sur Démarrer et sur Exécuter , tapez regedit, puis cliquez sur OK .
8. Utilisez l’une des méthodes suivantes :
Définissez la valeur de l’entrée de Registre RestrictRemoteClients sur 0 ou 1. Pour cela, procédez comme
suit :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc
2. Dans le volet droit, cliquez sur l’entrée RestrictRemoteClients.
NOTE
Si cette entrée n’existe pas, suivez les étapes suivantes :
1. Dans le menu Edition , pointez sur Nouveau , puis cliquez sur Valeur DWORD .
2. Tapez RestrictRemoteClients, puis appuyez sur Entrée.
3. Dans le menu Edition , cliquez sur Modifier .

4. Dans la zone de données Valeur, tapez 0 ou 1, puis cliquez sur OK.
5. Quittez l’Éditeur du Registre.
Utilisez l’Éditeur d’objets de stratégie de groupe pour désactiver les restrictions pour l’objet de stratégie
de groupe Clients RPC non authentifiés. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer , sur Exécuter , tapez gpedit.msc , puis cliquez sur OK .
2. Dans l’arborescence de la console, double-cliquez sur Configuration ordinateur, double-cliquez sur
Modèles d’administration, double-cliquez sur Système, puis sur Appel de procédure distante.
3. Double-cliquez sur Restrictions pour les clients RPC non authentifiés, cliquez sur Désactiver, puis
sur OK .
4. Quittez l’Éditeur d’objets de stratégie de groupe.
Statut
S’applique à ».
Pour plus d’informations sur l’entrée de Registre RestrictRemoteClients, visitez le site Web Microsoft suivant : la
clé de Registre RestrictRemoteClients est activée.
Support technique pour Windows éditions x64

Votre fabricant de matériel fournit un support technique et une assistance pour les Windows éditions x64 de
Microsoft. Votre fabricant de matériel assure la prise en charge car Windows édition x64 a été incluse dans votre
matériel. Votre fabricant de matériel a peut-être personnalisé l’installation Windows édition x64 avec des
composants uniques. Les composants uniques peuvent inclure des pilotes de périphérique spécifiques ou
inclure des paramètres facultatifs pour optimiser les performances du matériel. Microsoft vous fournira une
assistance raisonnable si vous avez besoin d’aide technique Windows édition x64. Toutefois, il se peut que vous
deiez contacter directement votre fabricant. Votre fabricant est le mieux qualifié pour prendre en charge les
logiciels que votre fabricant a installés sur le matériel.
Erreur lorsque vous démarrez votre contrôleur de
domaine Windows : les services d’annuaire ne
peuvent pas démarrer
Cet article explique comment récupérer à partir d’une base de données Active Directory endommagée ou d’un
problème similaire qui empêche votre ordinateur de démarrer en mode normal.
Résumé
Cet article vous guide tout au long d’une série d’étapes qui peuvent vous aider à diagnostiquer la cause de
l’erreur du système de démarrage des ser vices d’annuaire. Ces étapes peuvent inclure les éléments suivants :
Vérification de l’existence des fichiers du service d’annuaire Active Directory.
Vérifier que les autorisations du système de fichiers sont correctes.
Vérification de l’intégrité de la base de données Active Directory.
Effectuer une analyse de base de données sémantique.
Réparation de la base de données Active Directory.
Suppression et recréation de la base de données Active Directory.
Cet article vous explique également comment utiliser Ntdsutil ou Esentutl pour effectuer une réparation de
perte de la base de données Active Directory. Étant donné qu’une réparation avec perte supprime des données
et peut introduire de nouveaux problèmes, n’effectuez une réparation avec perte que s’il s’agit de la seule option
disponible.
Symptômes
Lorsque vous démarrez votre contrôleur de domaine, l’écran peut être vide et vous pouvez recevoir le message
d’erreur suivant :
LSASS.EXE - Erreur système, l’initialisation du gestionnaire de comptes de sécurité a échoué en raison de

l’erreur suivante : Les services d’annuaire ne peuvent pas démarrer. État d'0xc00002e1.
Veuillez cliquer sur OK pour arrêter ce système et redémarrer en mode de restauration des services
d’annuaire, consultez le journal des événements pour obtenir des informations plus détaillées.
En outre, les messages d’ID d’événement suivants peuvent apparaître dans le journal des événements :
Description : « La défragmentation NTDS (260) Online commence une passe sur la base de données NTDS.
DIT. »
Description : « La défragmentation NTDS (268) Online a terminé une passe complète sur la base de données
'C:\WINNT\NTDS\ntds.dit'. »
Description : « NTDS (260) le moteur de base de données s’est arrêté. »
Description : « Le répertoire a été fermé avec succès. »
Description: « Erreur : 1032 (fffffbf8) s’est produit. (ID interne 4042b). Veuillez contacter les services de
support technique Microsoft pour obtenir de l’aide. »
Description : « La base de données des services d’annuaire Windows n’a pas pu être initialisée et a renvoyé
l’erreur 1032. Erreur irrécible, le répertoire ne peut pas continuer. »
Cause
Ce problème se produit car une ou plusieurs des conditions suivantes sont vraies :
Les autorisations du système de fichiers NTFS sur la racine du lecteur sont trop restrictives.
Les autorisations du système de fichiers NTFS sur le dossier NTDS sont trop restrictives.
La lettre de lecteur du volume qui contient la base de données Active Directory a changé.
La base de données Active Directory (Ntds.dit) est endommagée.
Le dossier NTDS est compressé.
Résolution
Pour résoudre ce problème, suivez les étapes suivantes :
1. Redémarrez le contrôleur de domaine.
2. Lorsque les informations du BIOS apparaissent, appuyez sur F8.
3. Sélectionnez le mode restauration des ser vices d’annuaire , puis appuyez sur Entrée.
4. Connectez-vous à l’aide du mot de passe du mode restauration des services d’annuaire.
5. Cliquez sur Démarrer, sélectionnez Exécuter , tapez cmd dans la zone Ouvrir, puis cliquez sur OK .
6. À l’invite de commandes, tapez les informations des fichiers ntdsutil.
La sortie semblable à la sortie suivante s’affiche :
Informations sur le lecteur :

C:\ NTFS (Fixed Drive ) free(533.3 Mb) total(4.1 Gb)
Informations sur le chemin d’accès DS :
Base de données : C:\WINDOWS\NTDS\ntds.dit - 10,1 Mo Backup dir :
C:\WINDOWS\NTDS\dsadata.bak Working dir: C:\WINDOWS\NTDS Log dir : C:\WINDOWS\NTDS - 4
2,1 Mo total temp.edb - 2,1 Mo res2.log - 10,0 Mo res1.log - 10,0 Mo edb00001.log - 10,0 Mo edb.log
- 10,0 Mo
NOTE
Les emplacements de fichiers inclus dans cette sortie se trouvent également dans la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Les entrées suivantes de cette clé contiennent les emplacements de fichiers :

Chemin de sauvegarde de base de données
Chemin d’accès aux fichiers journaux de base de données
Annuaire de travail DSA
7. Vérifiez que les fichiers répertoriés dans la sortie à l’étape 6 existent.
8. Vérifiez que les dossiers de la sortie Ntdsutil ont les autorisations correctes. Les autorisations correctes
sont spécifiées dans les tableaux suivants.
Windows Ser ver 2003
C OMPT E A UTO RISAT IO N S H ÉRITA GE
Système Contrôle total Ce dossier, sous-dossiers et fichiers
Administrateurs Contrôle total Ce dossier, sous-dossiers et fichiers
Creator, propriétaire Contrôle total Sous-dossiers et fichiers

uniquement
Local Service Créer des dossiers/ Append Data Ce dossier et ses sous-dossiers
Windows 2000
NOTE
En outre, le compte système requiert des autorisations contrôle total sur les dossiers suivants :
Racine du lecteur qui contient le dossier Ntds
Dossier %WINDIR%
Dans Windows Server 2003, l’emplacement par défaut du dossier %WINDIR% est C:\WINDOWS. Dans Windows
2000, l’emplacement par défaut du dossier %WINDIR% est C:\WINNT.
9. Vérifiez l’intégrité de la base de données Active Directory. Pour ce faire, tapez intégrité des fichiers
ntdsutil à l’invite de commandes.
Si la vérification de l’intégrité ne signale aucune erreur, redémarrez le contrôleur de domaine en mode
normal. Si la vérification de l’intégrité ne se termine pas sans erreurs, continuez comme suit.
10. Effectuer une analyse sémantique de base de données. Pour ce faire, tapez la commande suivante à
l’invite de commandes, y compris les guillemets :
ntdsutil "sem d a" go
11. Si l’analyse sémantique de la base de données n’indique aucune erreur, continuez comme suit. Si l’analyse
signale des erreurs, tapez la commande suivante à l’invite de commandes, y compris les guillemets :
ntdsutil "sem d a" "go f"
12. Suivez les étapes de l’article suivant de la Base de connaissances Microsoft pour effectuer une
défragmentation hors connexion de la base de données Active Directory :
232122 défragmentation hors connexion de la base de données Active Directory
13. Si le problème existe toujours après la défragmentation hors connexion et qu’il existe d’autres
contrôleurs de domaine fonctionnels dans le même domaine, supprimez Active Directory du serveur, puis
réinstallez Active Directory. Pour ce faire, suivez les étapes de la section « Solution de contournement » de
l’article suivant de la Base de connaissances Microsoft :
332199 contrôleurs de domaine ne rétrogradent pas normalement lorsque vous utilisez l’Assistant
Installation d’Active Directory pour forcer la rétrogradation dans Windows Server 2003 et Windows 2000
Server
NOTE
Si votre contrôleur de domaine exécute Microsoft Small Business Server, vous ne pouvez pas effectuer cette étape,
car Small Business Server ne peut pas être ajouté à un domaine existant en tant que contrôleur de domaine
supplémentaire (réplica). Si vous avez une sauvegarde d’état système plus nouvelle que la durée de vie de
tombstone, restituer cette sauvegarde d’état système au lieu de supprimer Active Directory du serveur. Par défaut,
la durée de vie de tombstone est de 60 jours.
14. Si aucune sauvegarde de l’état du système n’est disponible et qu’il n’existe aucun autre contrôleur de
domaine sain dans le domaine, nous vous recommandons de reconstruire le domaine en supprimant
Active Directory, puis en réinstallant Active Directory sur le serveur, en créant un domaine. Vous pouvez
utiliser à nouveau l’ancien nom de domaine ou un nouveau nom de domaine. Vous pouvez également
reconstruire le domaine en reformatant et en réinstallant Windows sur le serveur. Toutefois, la
suppression d’Active Directory est plus rapide et supprime efficacement la base de données Active
Directory endommagée.
Si aucune sauvegarde de l’état du système n’est disponible, il n’y a aucun autre contrôleur de domaine
sain dans le domaine, et vous devez que le contrôleur de domaine fonctionne immédiatement, effectuer
une réparation avec perte à l’aide de Ntdsutil ou Esentutl.
NOTE
Microsoft ne prend pas en charge les contrôleurs de domaine après l’utilisation de Ntdsutil ou Esentutl pour
récupérer suite à une altération de la base de données Active Directory. Si vous effectuez ce type de réparation,
vous devez reconstruire le contrôleur de domaine pour qu’Active Directory soit dans une configuration prise en
charge. La commande de réparation dans Ntdsutil utilise l’utilitaire Esentutl pour effectuer une réparation de perte
de la base de données. Ce type de réparation corrige l’altération en supprimant des données de la base de
données. Utilisez uniquement ce type de réparation en dernier recours.
Bien que le contrôleur de domaine puisse démarrer et semble fonctionner correctement après la
réparation, son état n’est pas pris en compte, car les données supprimées de la base de données peuvent
provoquer un nombre quelconque de problèmes qui peuvent ne pas apparaître avant plus tard. Il n’existe
aucun moyen de déterminer quelles données ont été supprimées lors de la réparation de la base de
données. Dès que possible après la réparation, vous devez reconstruire le domaine pour rétablir une
configuration prise en charge par Active Directory. Si vous utilisez uniquement les méthodes d’analyse de
base de données sémantique ou de défragmentation hors connexion référencés dans cet article, vous
n’avez pas besoin de reconstruire le contrôleur de domaine par la suite.
15. Avant d’effectuer une réparation avec perte, contactez les services de support technique Microsoft pour
confirmer que vous avez examiné toutes les options de récupération possibles et pour vérifier que la base
de données est réellement dans un état irréparable. Pour obtenir la liste complète des numéros de
téléphone des services de support technique Microsoft et des informations sur les coûts de support,
visitez le site Web Microsoft suivant :
Contacter le support Microsoft
Sur un Windows de domaine server 2000, utilisez Ntdsutil pour récupérer la base de données Active
Directory. Pour ce faire, tapez la réparation des fichiers ntdsutil à l’invite de commandes en mode
restauration du service d’annuaire.
Pour effectuer une réparation à perte d’un contrôleur de domaine Windows Server 2003, utilisez l’outil
Esentutl.exe pour récupérer la base de données Active Directory. Pour ce faire, tapez esentutl /p à une
invite de commandes sur le contrôleur de domaine Windows Server 2003.
16. Une fois l’opération de réparation terminée, renommez les fichiers .log dans le dossier NTDS à l’aide
d’une autre extension telle que .bak et essayez de démarrer le contrôleur de domaine en mode normal.
17. Si vous pouvez démarrer le contrôleur de domaine en mode normal après la réparation, migrez les objets
Active Directory pertinents vers une nouvelle forêt dès que possible. Étant donné que cette méthode de
réparation avec perte corrige l’altération en supprimant des données, elle peut entraîner des problèmes
ultérieurs extrêmement difficiles à résoudre. À la première opportunité après la réparation, vous devez
reconstruire le domaine pour remettre Active Directory dans une configuration prise en charge.
Vous pouvez migrer des utilisateurs, des ordinateurs et des groupes à l’aide de l’outil de migration Active
Directory (ADMT), de Ldifde ou d’un outil de migration non Microsoft. ADMT peut migrer des comptes
d’utilisateurs, des comptes d’ordinateur et des groupes de sécurité avec ou sans l’historique
d’identificateur de sécurité (SID). ADMT migre également les profils utilisateur. Pour utiliser ADMT dans
un environnement Small Business Server, examinez le livre blanc « Migrating from Small Business Server
2000 or Windows 2000 Server ». Pour obtenir ce livre blanc, visitez le site Web Microsoft suivant :
Migration de Small Business Server 2000 ou Windows 2000 Server vers Windows Small Business Server
2003
Vous pouvez utiliser Ldifde pour exporter et importer de nombreux types d’objets du domaine
endommagé vers le nouveau domaine. Ces objets incluent les comptes d’utilisateur, les comptes
d’ordinateur, les groupes de sécurité, les unités d’organisation, les sites Active Directory, les sous-réseaux
et les liens de sites. Ldifde ne peut pas migrer l’historique SID. Ldifde fait partie de Windows 2000 Server
et Windows Server 2003.
Pour plus d’informations sur l’utilisation de Ldifde, cliquez sur le numéro d’article suivant pour afficher
l’article dans la Base de connaissances Microsoft :
237677 Ldifde pour importer et exporter des objets d’annuaire dans Active Directory
Vous pouvez utiliser la Console de gestion des stratégies de groupe (GPMC) pour exporter le système de
fichiers et la partie Active Directory de l’objet de stratégie de groupe du domaine endommagé vers le
nouveau domaine.
Pour obtenir la GPMC, visitez le site Web Microsoft suivant :
Cloud Computing Services
Pour plus d’informations sur la migration des objets de stratégie de groupe à l’aide de la GpMC, voir le
livre blanc « Migrer des objets de stratégie de groupe entre domaines avec gpmc ». Pour obtenir ce livre
blanc, visitez le site Web Microsoft suivant :
Migration des G GPOs sur plusieurs domaines
18. Après la récupération, évaluez votre plan de sauvegarde actuel pour vous assurer que vous avez
programmé des sauvegardes d’état système suffisamment fréquemment. Planifier des sauvegardes de
l’état du système au moins tous les jours ou après chaque modification importante. Les sauvegardes
d’état système doivent contenir le niveau requis de tolérance de panne. Par exemple, ne stockez pas les
sauvegardes sur le même lecteur que l’ordinateur que vous sauvegardez. Dans la mesure du possible,
utilisez plusieurs contrôleurs de domaine pour éviter un point de défaillance unique. Stockez les
sauvegardes dans un emplacement hors site afin que la récupération d’urgence du site (incendie, vol,
débordement, vol d’ordinateur) n’affecte pas votre capacité de récupération. Les sites Web Microsoft
suivants peuvent vous aider à développer un plan de sauvegarde.
Windows Server 2003 : Création d’un plan de sauvegarde et de récupération
Windows 2000 : Chapitre 14 - Sauvegarde et récupération des données
Windows Small Business Server : Windows Server Essentials (Small Business Server)
Échec de la communication Active Directory sur les
contrôleurs de domaine multi-accueil
Cet article décrit un problème dans lequel la communication Active Directory, y compris la réplication échoue
par intermittence.
S’applique à : Windows 2000
Symptômes
Dans un domaine Windows 2000 qui possède des contrôleurs de domaine multi-accueil, la communication
Active Directory, y compris la réplication, peut échouer par intermittence.
Cause
Ce problème peut se produire si l’une des cartes réseau est attachée à un réseau externe (par exemple, Internet)
sur le contrôleur de domaine multi-accueil, et si le trafic LDAP (Lightweight Directory Access Protocol) et
Kerberos entre les réseaux internes et externes est partiellement ou complètement restreint en raison d’un
proxy, d’ISA Server, de NAT Server ou d’un autre périphérique de pare-feu.
Dans ce scénario, les cartes réseau sur les contrôleurs de domaine multi-accueil enregistrent à la fois les
adresses IP (Internet Protocol) intérieures et externes avec le serveur DNS. Les demandes de recherche de
résolution de noms DNS retournent les enregistrements de manière « tour à tour », en alternant les adresses IP
internes et externes. Les opérations de réplication nécessitent plusieurs demandes de recherche
d’enregistrements SRV. Dans ce cas, la moitié des demandes de recherche DNS retournent une adresse IP qui ne
peut pas être contactée et l’opération de réplication échoue.
Résolution
Pour résoudre ce problème :
1. Désactivez l’inscription sur la carte réseau externe sur le contrôleur de domaine multi-accueil. Pour ce
faire, procédez comme suit :
a. Cliquez sur Démarrer, Paramètres, puis sur Connexions réseau et d’appels d’accès.
b. Cliquez avec le bouton droit sur la connexion de réseau local externe, puis cliquez sur Propriétés.
c. Cliquez sur TCP/IP, puis sur Propriétés.
d. Cliquez sur Avancé, puis sur Pour effacer la case à cocher Inscrire le DNS pour cette connexion.
2. Désactivez la fonctionnalité de tourn robin sur le serveur DNS. Pour ce faire, procédez comme suit :
a. Cliquez sur Démarrer, Paramètres, sur Outils d’administration, puis sur DNS.
b. Ouvrez les propriétés du nom du serveur DNS.
c. Cliquez sur l’onglet Avancé, puis sur pour activer la case à cocher Activer le tour robin.
3. Supprimez les entrées existantes dans DNS. Pour ce faire, procédez comme suit :
a. Accédez à l’emplacement suivant : Sous \ DNS DNS Ser vername \Forward Lookup Zones \ Domain
Name
b. Supprimer les entrées d’enregistrement d’hôte (A) qui font référence au nom d’ordinateur du
contrôleur de domaine pour les adresses IP de carte réseau extérieures.
c. Supprimer des entrées d’enregistrement d’hôte (A) pour le même nom que le dossier parent pour les
adresses IP de carte réseau.
4. Démarrez la console de gestion DNS, cliquez avec le bouton droit sur le nom du serveur, puis cliquez sur
Propriétés.
5. Cliquez sur l’onglet Interfaces, puis supprimez l’adresse IP externe afin que DNS ne l’écoute pas.
6. Ouvrez une invite de commandes, tapez ipconfig /flushdns, appuyez sur Entrée, tapez ipconfig
/registerdns, puis appuyez sur Entrée.
7. Modifiez l’ordre de liaison de vos cartes réseau afin que la carte interne soit la première carte liée. Pour
cela, procédez comme suit :
a. Cliquez sur Démarrer, Paramètres, puis sur Connexions réseau et d’accès à l’accès.
b. Dans le menu Avancé, cliquez sur Avancé.
c. Vérifiez que la carte réseau interne est répertoriée en premier dans la zone Connexions.
Statut
Ce comportement est inhérent au produit.
Pour plus d’informations, cliquez sur les numéros d’article suivants pour afficher les articles de la Base de
connaissances Microsoft :
246804 comment activer ou désactiver les mises à jour DNS dans Windows 2000 et Windows Server 2003
Le service ADWS se crashe après la mise à niveau
Cet article fournit une solution à un problème dans lequel le service ADWS (Active Directory Web Services) se
crashe après la mise à niveau.
Symptômes
Après avoir effectué une mise à niveau sur place d’un contrôleur de domaine Microsoft Windows Server 2008
R2 vers Windows Server 2012 R2, le service ADWS (Active Directory Web Services) se crashe au démarrage.
Cause
Il s’agit d’un problème connu concernant le produit.
Résolution
Pour résoudre ce problème, réinstallez le package Microsoft .NET Framework 4.5.2.
Processus de collecte de la garbage de base de
données Active Directory et calcul des intervalles
autorisés
Cet article décrit le processus de collecte de la garbage collection de la base de données Active Directory et le
calcul des intervalles autorisés.
S’applique à : Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Résumé
La base de données Active Directory intègre un processus de collecte de la garbage collection qui s’exécute
indépendamment sur chaque contrôleur de domaine de l’entreprise.
Le garbage collection est un processus de mise en service conçu pour libérer de l’espace dans la base de
données Active Directory. Ce processus s’exécute sur chaque contrôleur de domaine de l’entreprise avec un
intervalle de vie par défaut de 12 heures. Vous pouvez modifier cet intervalle en modifiant l’attribut
garbageCollPeriod dans l’objet de configuration DS à l’échelle de l’entreprise (NTDS).
Le chemin d’accès de l’objet dans Contoso.com le domaine ressemble à ce qui suit :
CN=Service d’annuaire,CN=Windows NT,CN=Services,CN=Configuration,DC=CONTOSO,DC=COM
Utilisez un outil d’édition Active Directory pour définir l’attribut garbageCollPeriod. Les outils pris en charge
incluent adsiedit.msc, Ldp.exe et les scripts ADSI (Active Directory Service Interfaces).
Lorsqu’un objet est supprimé, il n’est pas supprimé de la base de données Active Directory. Au lieu de cela,
l’objet est marqué pour suppression ultérieurement. Cette marque est ensuite répliquée sur d’autres contrôleurs
de domaine. Par conséquent, le processus de collecte de la garbage commence par supprimer les restes des
objets précédemment supprimés de la base de données. Ces objets sont appelés tombstones. Ensuite, le
processus de collecte de la garbage collection supprime les fichiers journaux inutiles. Enfin, le processus
démarre un thread de défragmentation pour demander davantage d’espace libre.
En outre, il existe deux méthodes pour défragmenter la base de données Active Directory. Une méthode est une
opération de défragmentation en ligne qui s’exécute dans le cadre du processus de nettoyage de la garbage.
L’avantage de cette méthode est que le serveur n’a pas besoin d’être mis hors connexion pour que l’opération
s’exécute. Toutefois, cette méthode ne réduit pas la taille du fichier de base de données Active Directory
(Ntds.dit). L’autre méthode met le serveur hors connexion et défragmente la base de données à l’aide de
lNtdsutil.exe de base de données. Cette approche nécessite que la base de données démarre en mode
réparation. L’avantage de cette méthode est que la base de données est re resous et que l’espace inutilisé est
supprimé. Par conséquent, et la taille du fichier Ntds.dit est réduite. Pour utiliser cette méthode, le contrôleur de
domaine doit être mis hors connexion.
Limites pour garbageCollPeriod :
La valeur minimale est 1 et la valeur maximale est 168 pour une semaine. La valeur par défaut est 12 heures.
Minimum pour la durée de vie de Tombstone :
La durée de vie minimale de Tombstone est de 2 jours pour les besoins du calcul de la suspension de l’exécution
du KCC.
La couche de base de données AD applique une mesure supplémentaire. Les jours TSL ne doivent pas être
inférieurs à trois fois l’intervalle du garbage collector. Sur la base de la valeur par défaut de 12 heures, TSL est
un minimum de 2 jours. Si l’intervalle gc est de 20 heures, le TSL minimum est de 3 jours (doit être supérieur à
60 heures). Si l’intervalle gc est de 25 heures, vous obtenez plus de trois jours (avec 75 heures) et le TSL
minimum est de 4 jours.
Le hic avec les vérifications effectuées par la couche DB et le KCC est que si TSL est inférieur au minimum
autorisé, il ne revient pas à la valeur minimale de 2 jours ou plus, mais à la valeur par défaut de 60 ou 180 jours.
IMPORTANT
Si le TSL est corrigé par défaut en raison d’une insaltérance, la valeur de l’intervalle de collecte de la garbage collection est
également définie sur la valeur par défaut de 12 heures.
Valeurs par défaut de la durée de vie de Tombstone

Historique
La durée de vie par défaut de tombstone (TSL) dans Windows Server 2003 était de 60 jours et s’est montrée
trop courte. Par exemple, un contrôleur de domaine prétenté peut être en transit pendant plus de 60 jours. Un
administrateur ne peut pas résoudre un échec de réplication ou mettre en fonctionnement un contrôleur de
domaine hors connexion tant que le TSL n’est pas dépassé. Windows Server 2003 Service Pack 1 (SP1) a
augmenté le TSL de 60 à 180 jours dans les scénarios suivants :
Un Windows de domaine NT 4.0 est mis à niveau vers Windows Server 2003 à l’aide du support
d’installation Windows Server 2003 SP1 pour créer une forêt.
Un Windows Server 2003 SP1 crée une forêt.
Windows Server 2003 SP1 ne modifie pas la valeur de TSL lorsque l’une des conditions suivantes est vraie :
Un domaine Windows 2000 est mis à niveau vers Windows Server 2003 à l’aide du support d’installation
pour Windows Server 2003 avec SP1.
Windows Server 2003 SP1 est installé sur un contrôleur de domaine qui exécute la version d’origine de
L’augmentation du TSL d’un domaine à 180 jours présente les avantages suivants :
Les sauvegardes utilisées dans les scénarios de récupération de données ont une durée de vie plus utile.
Les sauvegardes d’état système utilisées pour l’installation à partir de promotions multimédias ont une
durée de vie plus utile.
Les contrôleurs de domaine peuvent être hors connexion plus longtemps. Les ordinateurs prétentés
approchent moins fréquemment l’expiration du TSL.
Un contrôleur de domaine peut revenir au domaine après une période plus longue hors connexion.
La connaissance des objets supprimés est conservée plus longtemps sur le contrôleur de domaine d’origine.
Le paramètre par défaut dans votre forêt dépend du système d’exploitation à la « naissance » de la forêt et des
méthodes de mise à niveau à partir de là, comme ci-dessus.
Si vous n’êtes pas sûr de la valeur de TSL utilisée dans votre forêt, nous vous recommandons de la définir
explicitement, ainsi que msDS-deletedObjectLifetime si nécessaire.
Référence : La Corbeille AD : compréhension, mise en œuvre, meilleures pratiques et dépannage
Erreur de configuration du contrôleur de domaine
(le serveur n’est pas opérationnel) lorsque vous
configurez un serveur à l’aide du Gestionnaire de
serveur
Cet article permet de résoudre une erreur (le serveur n’est pas opérationnel) qui se produit lorsque vous
configurez un serveur à partir d’un groupe de travail en tant que contrôleur de domaine à l’aide du Gestionnaire
de serveur.
Symptômes
Prenons le cas de figure suivant. Vous configurez un serveur qui s’exécute Windows Server 2012 partir d’un
groupe de travail en tant que contrôleur de domaine à l’aide du Gestionnaire de serveur. Ensuite, cliquez sur le
bouton Sélectionner dans la page Configuration du déploiement. Dans ce scénario, vous recevez le
message d’erreur suivant :
Une erreur s’est produite lors du contact du domaine contoso.

Le serveur n’est pas opérationnel.
NOTE
Vous avez une connectivité LDAP, RPC et DNS et pouvez contacter tous les contrôleurs de domaine existants sans
problème pour d’autres opérations.
Cause
Ce problème se produit car l’authentification NTLM est désactivée dans le domaine ou sur les contrôleurs de
domaine.
Résolution
Pour résoudre ce problème, associez le serveur au domaine, puis configurez le serveur comme contrôleur de
domaine. Une fois que vous avez joint le serveur au domaine, l’Assistant Services de domaine Active Directory
(AD DS) dans le Gestionnaire de serveur utilise l’authentification Kerberos au lieu de l’authentification NTLM
pour parcourir la forêt AD DS.
Pour plus d’informations sur la désactivation de l’authentification NTLM dans les domaines Windows Server
2008 R2 et versions ultérieures, voir les sites web suivants :
Présentation de la restriction de l’authentification NTLM
Blocage NTLM et vous : méthodologies d’analyse et d’audit des applications Windows 7
Les ID d’événement ESENT 1000, 1202, 412 et 454
sont consignés à plusieurs reprises dans le journal
des applications
Cet article fournit une solution à un problème dans lequel les ID d’événement ESENT 1000, 1202, 412 et 454
sont enregistrés à plusieurs reprises dans le journal des applications.
Symptômes
Les ID d’événement suivants sont enregistrés toutes les cinq minutes dans le journal des applications :
1000
1202
412
454
Cause
Ce problème se produit si le fichier de base de données de stratégie de groupe local est endommagé.
Résolution
Pour résoudre ce problème, utilisez la procédure décrite dans cette section pour re-créer le fichier de stratégie
de groupe local.
IMPORTANT
L’implémentation d’un modèle de sécurité sur un contrôleur de domaine peut modifier les paramètres de la stratégie de
contrôleur de domaine par défaut ou de la stratégie de domaine par défaut. Le modèle appliqué peut réécrire les
autorisations sur les nouveaux fichiers, clés de Registre et services système créés par d’autres programmes. La restauration
de ces stratégies peut être nécessaire après l’application d’un modèle de sécurité. Avant d’effectuer ces étapes sur un
contrôleur de domaine, créez une sauvegarde du partage SYSVOL.
NOTE
Lorsque vous utilisez la procédure suivante, votre ordinateur revient à l’état d’installation d’origine où la stratégie de
sécurité locale n’est pas définie. Vous de devez peut-être démarrer votre ordinateur en mode Coffre pour renommer ou
déplacer des fichiers. Pour plus d’informations sur la façon de faire, voir Windows 2000 Help.
1. Ouvrez le dossier %SystemRoot%\Security, créez un dossier, puis nommez-le « OldSecurity ».

2. Déplacez tous les fichiers se terminant par .log du dossier %SystemRoot%\Security vers le dossier
OldSecurity.
3. Recherchez le fichier Secedit.sdb dans le dossier %SystemRoot%\Security\Database, puis renommez ce
fichier en « Secedit.old ».
4. Cliquez successivement sur Démarrer et Exécuter, tapez mmc, puis cliquez sur OK.
5. Cliquez sur Console, sur Ajouter/Supprimer un logiciel en snap-in, puis ajoutez le logiciel en snap-in
Sécurité et configuration.
6. Cliquez avec le bouton droit sur Sécurité et configuration et analyse, puis cliquez sur Ouvrir la base de
données.
7. Accédez au dossier %TEMP%, tapez Secedit.sdb dans la zone Nom de fichier, puis cliquez sur Ouvrir .
8. Lorsque vous êtes invité à importer un modèle, cliquez sur Setup Security.inf, puis cliquez sur Ouvrir.
9. Copiez %TEMP%\Secedit.sdb %SystemRoot%\Security\Database.
Les ID d’événement 5788 et 5789 se produisent sur
un ordinateur Windows base de données
Cet article fournit des solutions à un problème où l’ID d’événement 5788 et l’ID d’événement 5789 sont
enregistrés lorsque le nom de domaine DNS et le nom de domaine Active Directory diffèrent sur un ordinateur
Windows.
Symptômes
Vous pouvez être à l’un des problèmes suivants :
Sur Windows Vista et les versions ultérieures, vous recevez le message d’erreur suivant lors de l’logo
interactif :
La base de données de sécurité sur le serveur ne contient pas de compte d’ordinateur pour cette
relation d’confiance de station de travail.
Les connexions interactives avec des comptes basés sur un domaine ne fonctionnent pas. Seules les
connexions avec des comptes locaux fonctionnent.
Les messages d’événement suivants sont consignés dans le journal système :
Type d'événement : Erreur

Source de l’événement : NETLOGON
Catégorie d’événement : Aucun
Ordinateur : ComputerName
Description :
Échec de la tentative de mise à jour du nom principal de service (SPN) de l’objet ordinateur dans
Active Directory. L’erreur suivante s’est produite : <Detailed error message that varies,
depending on the cause.>

Ordinateur : Ordinateur
Description :
Échec de la tentative de mise à jour du nom d’hôte DNS de l’objet ordinateur dans Active Directory.
L’erreur suivante s’est produite : <Detailed error message that varies, depending on the
cause.>
NOTE
Les messages d’erreur détaillés pour ces événements sont répertoriés dans la section « Cause ».
Cause
Ce comportement se produit lorsqu’un ordinateur tente mais n’écrit pas dans les attributs dNSHostName et
servicePrincipalName pour son compte d’ordinateur dans un domaine AD DS (Active Directory Domain
Services).
Un ordinateur tente de mettre à jour ces attributs si les conditions suivantes sont vraies :
Immédiatement après qu’un ordinateur basé sur Windows rejoint un domaine, l’ordinateur tente de définir
les attributs dNSHostName et servicePrincipalName pour son compte d’ordinateur dans le nouveau
domaine.
Lorsque le canal de sécurité est établi sur un ordinateur Windows qui est déjà membre d’un domaine AD DS,
l’ordinateur tente de mettre à jour les attributs dNSHostName et servicePrincipalName pour son compte
d’ordinateur dans le domaine.
Sur un Windows de domaine basé sur le client, le service Netlogon tente de mettre à jour l’attribut
servicePrincipalName toutes les 22 minutes.
Il existe deux causes possibles des échecs de mise à jour :
L’ordinateur ne peut pas effectuer une demande de modification LDAP des attributs dNSHostName ou
servicePrincipalName pour son compte d’ordinateur.
Dans ce cas, les messages d’erreur qui correspondent aux événements décrits dans la section «
Symptômes » sont les suivants :
Événement 5788
L’accès est refusé.
Événement 5789
Le fichier spécifié est introuvable.
Le suffixe DNS principal de l’ordinateur ne correspond pas au nom DNS du domaine AD DS dont
l’ordinateur est membre. Cette configuration est appelée « espace de noms disjoint ».
Par exemple, l’ordinateur est membre du domaine Active contoso.com Directory. Toutefois, son nom de
domaine complet DNS est member1.nyc.contoso.com . Par conséquent, le suffixe DNS principal ne
correspond pas au nom de domaine Active Directory.
La mise à jour est bloquée dans cette configuration car la validation d’écriture prérequise des valeurs
d’attribut échoue. La validation d’écriture échoue car, par défaut, le Gestionnaire de comptes de sécurité
(SAM) exige que le suffixe DNS principal d’un ordinateur corresponde au nom DNS du domaine AD DS
dont l’ordinateur est membre.
Dans ce cas, les messages d’erreur qui correspondent aux événements décrits dans la section «
Symptômes » sont les suivants :
Événement 5788
La syntaxe d’attribut spécifiée pour le service d’annuaire n’est pas valide.

Événement 5789
Le paramètre est incorrect.
Résolution
Pour résoudre ce problème, recherchez la cause la plus probable, comme décrit dans la section « Cause ».
Ensuite, utilisez la résolution appropriée pour la cause.
Résolution de la cause 1
Pour résoudre ce problème, vous devez vous assurer que le compte d’ordinateur dispose des autorisations
suffisantes pour mettre à jour son propre objet ordinateur.
Dans l’Éditeur de liste de contrôle d’accès, assurez-vous qu’il existe une entrée de contrôle d’accès (ACE) pour le
compte de confiance « SELF » et qu’il dispose de l’accès « Autoriser » pour les droits étendus suivants :
Écriture validée dans le nom d’hôte DNS
Écriture validée dans le nom principal de service
Ensuite, vérifiez les autorisations de refus qui peuvent s’appliquer. À l’exclusion des appartenances de groupe de
l’ordinateur, les administrateurs de sécurité suivants s’appliquent également à l’ordinateur :
Tout le monde
Utilisateurs authentifiés
SELF
Les ace qui s’appliquent à ces trustees peuvent également refuser l’accès à l’écriture aux attributs, ou refuser les
droits étendus « Écriture validée dans le nom d’hôte DNS » ou « Écriture validée dans le nom principal du
service ».
Résolution de la cause 2
Pour résoudre ce problème, utilisez l’une des méthodes suivantes, selon le cas :
Méthode 1 : Corriger un espace de noms disjoint involontaire
Si la configuration disjointe est involontaire et si vous souhaitez revenir à un espace de noms contigu, utilisez
cette méthode.
Pour plus d’informations sur la façon de revenir à un espace de noms contigu sur Windows Server 2003,
consultez l’article Microsoft TechNet suivant :
Transition d’un espace de noms disjoint vers un espace de noms contigu
Pour Windows Server 2008 et Windows Vista et versions ultérieures, consultez l’article Microsoft TechNet
suivant :
Inverser un espace de noms disjoint créé accidentellement
Méthode 2 : Vérifier que la configuration de l’espace de noms disjoint fonctionne correctement
Utilisez cette méthode si vous souhaitez conserver l’espace de noms disjoint. Pour ce faire, suivez ces étapes
pour apporter des modifications de configuration afin de résoudre les erreurs.
Pour plus d’informations sur la façon de vérifier que l’espace de noms disjoint fonctionne correctement sur
Windows Server 2003 R2, Windows Server 2003, Windows Server 2003 avec Service Pack 1 (SP1) et Windows
Server 2003 avec Service Pack 2 (SP2), voir l’article Microsoft TechNet suivant : Créer un espace de noms
disjoint
Pour plus d’informations sur la façon de vérifier que l’espace de noms disjoint fonctionne correctement sur
Windows Server 2008 R2 et Windows Server 2008, voir l’article Microsoft TechNet suivant : Créer un espace de
noms disjoint
En étendant l’exemple mentionné dans la dernière puce principale de la section « Cause », vous ajoutez comme
suffixe autorisé nyc.contoso.com à l’attribut.
Les versions antérieures de cet article ont mentionné la modification des autorisations sur les objets ordinateur
pour permettre l’accès en écriture général pour résoudre ce problème. Il s’agissait de la seule approche qui
existait Windows 2000. Toutefois, il est moins sécurisé que d’utiliser msDS-AllowedDNSSuffixes.
msDS-AllowedDNSSuffixes empêche le client d’écrire des SNS arbitraires dans Active Directory. La « Windows
2000 » permet au client d’écrire des noms de service qui bloquent l’emploi de Kerberos sur d’autres serveurs
importants (création de doublons). Lorsque vous utilisez msDS-AllowedDNSSuffixes, des collisions SPN telles
que celles-ci peuvent se produire uniquement lorsque l’autre serveur a le même nom d’hôte que l’ordinateur
local.
Un suivi réseau de la réponse à la demande de modification LDAP affiche les informations suivantes :
win: 17368, src: 389 dst: 1044
LDAP : ProtocolOp : ModifyResponse (7)
LDAP : MessageID
LDAP : ProtocolOp = ModifyResponse
LDAP : Code de résultat = Violation de contrainte
LDAP : Message d’erreur = 0000200B : AtrErr : DSID-03151E6D Dans ce suivi réseau, 200B hexadécimal est égal
à 8203 décimal.
La commande net helpmsg 8203 renvoie les informations suivantes : La syntaxe d’attribut spécifiée pour le
service d’annuaire n’est pas valide. » Le moniteur réseau 5.00.943 affiche le code de résultat suivant : « Violation
de contrainte ». Winldap.h maps error 13 to « LDAP_CONSTRAINT_VIOLATION.
Le nom de domaine DNS et le nom de domaine Active Directory peuvent différer si une ou plusieurs des
La configuration DNS TCP/IP contient un domaine DNS différent du domaine Active Directory dont
l’ordinateur est membre, et le suffixe DNS principal Change lorsque l’option d’appartenance au domaine
est désactivée. Pour afficher cette option, cliquez avec le bouton droit sur Mon ordinateur, cliquez sur
Propriétés, puis cliquez sur l’onglet Identification réseau.
Windows Les ordinateurs basés sur server 2003 ou Windows XP Professional peuvent appliquer un
paramètre de stratégie de groupe qui définit le suffixe principal sur une valeur qui diffère du domaine
Active Directory. Le paramètre de stratégie de groupe est le suivant : Configuration ordinateur\Modèles
d’administration\Réseau\Client DNS : Suffixe DNS principal
Le contrôleur de domaine se trouve dans un domaine renommé par l’utilitaire Rendom.exe domaine.
Toutefois, l’administrateur a encore changé le suffixe DNS par rapport au nom de domaine DNS
précédent. Le processus de changement de nom de domaine ne met pas à jour le suffixe DNS principal
pour qu’il corresponde au nom de domaine DNS actuel après les noms de domaine DNS. Les domaines
d’une forêt Active Directory qui n’ont pas le même nom de domaine hiérarchique sont dans une
arborescence de domaine différente. Lorsque différentes forêts de domaines sont dans une forêt, les
domaines racines ne sont pas contigus. Toutefois, cette configuration ne crée pas d’espace de noms DNS
disjoint. Vous avez plusieurs domaines racineS DNS ou même Active Directory DNS. Un espace de noms
disjoint se caractérise par une différence entre le suffixe DNS principal et le nom de domaine Active
Directory dont l’ordinateur est membre.
L’espace de noms disjoint peut être utilisé avec précaution dans certains scénarios. Toutefois, il n’est pas pris en
charge dans tous les scénarios.
Comment effectuer une analyse sémantique de
base de données pour la base de données Active
Directory à l’aide de Ntdsutil.exe
Cet article décrit les étapes à suivre pour effectuer une analyse de base de données sémantique pour la base de
données Active Directory à l’aide de Ntdsutil.exe
Résumé
Cet article pas à pas décrit comment exécuter le contrôle sémantique sur la base de données Active Directory.
Contrairement aux commandes de gestion de fichiers, qui testent l’intégrité de la base de données par rapport à
la sémantique de la base de données ESENT, l’analyse sémantique analyse les données par rapport à la
sémantique Active Directory. Vous pouvez utiliser ce processus pour générer des rapports sur le nombre
d’enregistrements présents, y compris les enregistrements supprimés et fantômes.
Le service Windows Directory 2000 ouvre ses fichiers en mode Exclusif. Cela signifie que les fichiers ne peuvent
pas être gérés pendant que l’ordinateur fonctionne en tant que contrôleur de domaine. La première procédure
consiste à démarrer votre serveur en mode restauration des services d’annuaire.
Démarrage en mode restauration des services d’annuaire

2. Une fois que les informations du BIOS apparaissent, appuyez sur F8.
3. Sélectionnez le mode de restauration des ser vices d’annuaire (Windows 2000 contrôleurs de domaine
uniquement), puis appuyez sur Entrée.
4. Sélectionnez votre serveur, puis appuyez sur Entrée.
5. Connectez-vous à l’aide de votre compte d’administration de restauration qui a été effectué lors de la
promotion de ce contrôleur de domaine.
Démarrage Ntdsutil.exe
1. Cliquez sur Démarrer, puis sur Exécuter.
2. Dans la zone Ouvrir, tapez ntdsutil, puis appuyez sur Entrée. Notez que vous pouvez afficher Ntdsutil.exe'aide
en tapant ? à l’invite de commandes, puis en appuyant sur Entrée.
Effectuer une analyse de base de données

Cette procédure démarre l’analyse sémantique du fichier Ntds.dit. Un rapport est généré et écrit dans un fichier
nommé Dsdit.dmp. n, dans le dossier actuel, où n est un incrémenté qui est incrémenté chaque fois que vous
exécutez la commande.
1. À l’invite Ntdsutil.exe commande, tapez Analyse sémantique de la base de données, puis appuyez sur Entrée.
2. À l’invite de commandes du contrôle sémantique, tapez Go, puis appuyez sur Entrée.
3. La vérification s’affiche. Pour quitter, tapez q, appuyez sur Entrée, tapez q, puis appuyez sur Entrée.
Récupérer un enregistrement spécifique
Cette procédure récupère un numéro d’enregistrement spécifique à partir du fichier Ntds.dit à l’aide de la
variable de numéro d’enregistrement DNT. L’une des fonctions de la couche base de données consiste à traduire
chaque nom unique en une structure entière appelée balise de nom unique, utilisée pour tous les accès internes.
La couche de base de données garantit l’unicité de la balise de nom unique pour chaque enregistrement de base
de données. Pour afficher les index et leur DNT associé, utilisez la commande d’intégrité dans le menu Fichiers
de Ntdsutil.exe.
1. À l’invite Ntdsutil.exe commande, tapez Analyse sémantique de la base de données, puis appuyez sur Entrée.
2. À l’invite de commandes du contrôle sémantique, tapez Go, puis appuyez sur Entrée.
3. À l’invite de commandes de vérification sémantique, tapez Obtenir le numéro d’enregistrement DNT, puis
4. La vérification s’affiche. Pour quitter, tapez q, appuyez sur Entrée, tapez q, puis appuyez sur Entrée.
Utilisation de Ntdsutil pour gérer des fichiers Active
Directory à partir de la ligne de commande
Windows Server 2003
Cet article explique comment gérer le fichier de base de données Active Directory (AD), Ntds.dit, à partir de la
ligne de commande.
Comment démarrer votre ordinateur en mode restauration des

services d’annuaire
Windows Le service d’annuaire Server 2003 ouvre ses fichiers en mode exclusif, ce qui signifie que les fichiers
ne peuvent pas être gérés pendant que le serveur fonctionne en tant que contrôleur de domaine.
Pour démarrer le serveur en mode restauration des services d’annuaire, suivez les étapes suivantes :
1. Redémarrez l'ordinateur.
2. Une fois que les informations du BIOS (Basic Input/Output System) sont affichées, appuyez sur F8.
3. Utilisez la flèche vers le bas pour sélectionner le mode de restauration des services d’annuaire (Windows
Contrôleurs de domaine Ser ver 2003 uniquement), puis appuyez sur Entrée .
4. Utilisez les flèches Haut et Bas pour sélectionner le Windows d’exploitation Server 2003, puis appuyez sur
Entrée .
5. Connectez-vous avec votre compte d’administration et votre mot de passe.
Comment installer les outils de support et démarrer Ntdsutil

Pour installer Windows outils de support technique, suivez les étapes suivantes :
1. Insérez le CD-ROM d’installation Windows Server 2003 dans le lecteur de CD-ROM ou de DVD-ROM.
2. Sélectionnez Démarrer, sélectionnez Exécuter, drive_letter :\Support\Tools\suptools.msi tapez, puis
Pour démarrer Ntdsutil, sélectionnez Démarrer, sélectionnez Exécuter, tapez ntdsutil dans la zone Ouvrir, puis
appuyez sur Entrée .
NOTE
Pour accéder à la liste des commandes disponibles, tapez ?, puis appuyez sur Entrée .
Comment déplacer la base de données

Vous pouvez déplacer le fichier de données Ntds.dit vers un nouveau dossier. Si vous le faites, le Registre est mis
à jour afin que le service d’annuaire utilise le nouvel emplacement lorsque vous redémarrez le serveur.
Pour déplacer le fichier de données vers un autre dossier, suivez les étapes suivantes :
1. Sélectionnez Démarrer, sélectionnez Exécuter, tapez ntdsutil dans la zone Ouvrir, puis appuyez sur
Entrée.
2. À l’invite de commandes Ntdsutil, tapez des fichiers, puis appuyez sur Entrée .
3. À l’invite de commandes de maintenance de fichier, tapez Déplacer la DB vers un nouvel emplacement (où le
nouvel emplacement est un dossier existant que vous avez créé à cet effet), puis appuyez sur Entrée .
4. Pour quitter Ntdsutil, tapez quit, puis appuyez sur Entrée .
Comment déplacer des fichiers journaux

Utilisez les journaux de déplacement pour commander le déplacement des fichiers journaux du service
d’annuaire vers un autre dossier. Pour que les nouveaux paramètres prennent effet, redémarrez l’ordinateur
après avoir déplacez les fichiers journaux.
Pour déplacer les fichiers journaux, suivez les étapes suivantes :
Entrée.
3. À l’invite de commandes de maintenance de fichier, tapez déplacer les journaux vers un nouvel emplacement
(où le nouvel emplacement est un dossier existant que vous avez créé à cet effet), puis appuyez sur Entrée .
4. Tapez quit, puis appuyez sur Entrée .
Comment récupérer la base de données

Pour récupérer la base de données, suivez les étapes suivantes :
Entrée.
3. À l’invite de commandes de maintenance de fichier, tapez récupérer, puis appuyez sur Entrée.
NOTE
Vous pouvez également utiliser Esentutl.exe pour effectuer la récupération de base de données lorsque la procédure
décrite précédemment dans cet article échoue (par exemple, la procédure peut échouer lorsque la base de données est
incohérente). Pour utiliser Esentutl.exe de récupération de base de données, suivez les étapes suivantes :
1. Sélectionnez Démarrer, Sélectionnez Exécuter, tapez cmd dans la zone Ouvrir, puis appuyez sur Entrée.
2. Tapez esentutl /r path \ntds.dit, puis appuyez sur Entrée . fait référence à l’emplacement actuel du fichier
Ntds.dit.
3. Supprimez les fichiers journaux de base de données (.log) du dossier WINDOWS\Ntds.
Pour plus d’informations sur l’utilitaire esentutl.exe, à l’invite de commandes, tapez esentutl /? , puis appuyez
sur Entrée .
NOTE
Cette procédure implique des journaux de transactions pour récupérer des données. Les journaux de transactions sont
utilisés pour s’assurer que les transactions engagés ne sont pas perdues en cas de panne de votre ordinateur ou en cas de
perte de courant inattendue. Les données de transaction sont écrites d’abord dans un fichier journal, puis dans le fichier
de données. Après avoir redémarré l’ordinateur après un échec, vous pouvez réexécuter le journal pour reproduire les
transactions qui ont été enregistrées dans le fichier de données, mais qui n’ont pas été enregistrées.
Comment définir des chemins d’accès

Vous pouvez utiliser la commande définir le chemin d’accès pour les éléments suivants :
Sauvegarde : utilisez ce paramètre avec la commande définir le chemin d’accès pour définir la cible de
sauvegarde disque à disque sur le dossier spécifié par la variable d’emplacement. Vous pouvez configurer le
service d’annuaire pour qu’il sauvegarde disque à disque en ligne à intervalles réguliers.
Base de données : utilisez ce paramètre avec la commande définir le chemin d’accès pour mettre à jour la
partie du Registre qui identifie l’emplacement et le nom de fichier du fichier de données. Utilisez cette
commande uniquement pour reconstruire un contrôleur de domaine qui a perdu son fichier de données et
qui n’est pas restauré au moyen de procédures de restauration classiques.
Journaux : utilisez ce paramètre avec la commande définir le chemin d’accès pour mettre à jour la partie du
Registre qui identifie l’emplacement des fichiers journaux. Utilisez cette commande uniquement si vous
resserez un contrôleur de domaine qui a perdu ses fichiers journaux et n’est pas restauré au moyen de
procédures de restauration classiques.
Répertoire de travail : utilisez ce paramètre avec la commande définir le chemin d’accès pour définir la partie
du Registre qui identifie le dossier de travail du service d’annuaire sur le dossier spécifié par la variable
d’emplacement. Pour exécuter la commande définir le chemin d’accès, suivez les étapes suivantes :
Entrée.
3. À l’invite de commandes de maintenance de fichier, tapez l’emplacement de l’objet chemin d’accès, puis
appuyez sur Entrée . fait référence à l’un des éléments suivants :
Sauvegarde
Database
Journaux d’activité
Répertoire de travail
fait référence à l’emplacement (dossier) auquel vous souhaitez définir l’objet identifié dans la commande.
ISMServ.exe ne démarre pas lorsqu’un contrôleur
de domaine démarre
Cet article fournit une solution de contournement pour un problème dans lequel le service IsmServ ne démarre
pas correctement au démarrage d’un contrôleur de domaine.
Symptômes
Lorsque vous démarrez un contrôleur de domaine Windows Server, il ne démarre pas correctement. Lorsque
vous vérifiez le journal système dans l’Observateur d’événements, vous trouvez l’entrée suivante pour l’ID
d’événement 7023 :
Nom du journal : System

Source : Gestionnaire de contrôle de service
Niveau : Erreur
Description :
Le service IsmServ s’est terminé par l’erreur suivante :
Le serveur spécifié ne peut pas effectuer l’opération demandée.
Xml d’événement :
<Event xmlns=" http://schemas.microsoft.com/win/2004/08/events/event ">
...
<EventData>
<Data Name="param1">IsmServ</Data>
<Data Name="param2">%%58</Data>
</EventData>
</Event>
Cet événement inclut les paramètres de données suivants :

Valeur du paramètre param1, IsmSer v : Cela représente le service de messagerie intersite (ISMserv.exe).
Valeur du paramètre param2, 58 : cette valeur est m ERROR_BAD_NET_RESP message « Le serveur
spécifié ne peut pas effectuer l’opération demandée »).
Pour collecter plus d’informations sur ce problème, vous pouvez configurer le suivi des événements LDAP pour
que Windows (ETW) s’exécute au démarrage du système. (Pour plus d’informations sur la façon de le faire, voir
plus d’informations.) Après avoir redémarré le dc, vous devez voir les lignes suivantes dans le journal :
[Microsoft-Windows-LDAP-Client/Debug] La connexion Message=LDAP 0xec4b08a8 'localhost' à l’aide de

GetHostByName.
...
[Microsoft-Windows-LDAP-Client/Debug] Message=gethostbyname collected 2 records for
dc1.contoso.com ' '[Microsoft-Windows-LDAP-Client/Debug] Message=LdapParallelConnect
called for connection 0xec4b08a8 with timeout 45 sec 0 usec. Le nombre total est de 2.
[Microsoft-Windows-LDAP-Client/Debug] Message=Aucune réponse pour le moment...
[Microsoft-Windows-LDAP-Client/Debug] Message=LdapParallelConnect terminé pour la connexion
0xec4b08a8. La durée prise était de 1 sec. Le délai d’origine spécifié était de 45 sec 0 usec.
...
[Microsoft-Windows-LDAP-Client/Debug] Message=LdapConnect failed to open connection 0xec4b08a8,
error = 0x5b.
[Microsoft-Windows-LDAP-Client/Debug] Message=LdapConnect thread 0xce0 a une connexion
0xec4b08a8 vers le bas.
Dans ce cas, la valeur du paramètre d’erreur (0x5b ou 91 ) est m LDAP_CONNECT_ERROR message.
Cause
ISMServ dépend des services de domaine Active Directory (AD DS). Toutefois, au démarrage du système,
ISMServ peut essayer de créer une connexion LDAP à AD DS avant la fin de la mise en ligne d’AD DS. Lorsque
cela se produit, le port LDAP (port TCP 389) n’est pas disponible lorsque ISMServ tente de se connecter. Étant
donné que le port n’est pas à l’écoute, ISMServ détermine que la connexion a échoué sans attendre le délai
d’attente de connexion (45 secondes). Par conséquent, ISMServ ne démarre pas.
Pour contourner immédiatement ce problème, redémarrez manuellement ISMServ.
Pour éviter ce problème à l’avenir, utilisez le logiciel en snap-in MMC Services et applications pour changer le
type de démarrage d’ISMServ de Automatique à Automatique (Démarrage différé).
Pour configurer LDAP ETW, suivez les étapes suivantes :
1. Utilisez l’Éditeur du Registre pour créer la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ldap\Tracing\ISMSERV.EXE
2. Ouvrez une fenêtre d’invite de commandes avec élévation de niveaux et exécutez les commandes
suivantes :
logman create trace "autosession\g_os" -ow -o c:\boot-ldap.etl -p "Microsoft-Windows-LDAP-Client"

0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode Circular -f bincirc -max 4096 -ets reg add
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\g_os /v FileMax /t REG_DWORD /d 2
/F
4. Après le démarrage de l’ordinateur, exécutez la commande suivante à une invite de commandes avec
élévation de élévation de niveaux :
logman stop "g_os" -ets
5. Lorsque vous avez terminé la collecte des données, exécutez la commande suivante à une invite de
commandes avec élévation de élévation de niveaux pour arrêter le suivi :
logman delete "autosession\g_os" -et

Statut
Références
Comment activer la journalisation du débogage du client LDAP (Wldap32.dll)
Erreur lorsque vous exécutez la commande dans
Windows Server 2008 : Adprep n’a pas pu contacter
un réplica pour Adprep /rodcprep partition
DC=DomainDnsZones,DC=Contoso,DC=com
Cet article résout un problème : la commande n’est pas terminée correctement, car le maître d’infrastructure
pour un ou plusieurs Adprep /rodcprep NCS Active Directory n’est pas accessible.
Symptômes
Lorsque vous exécutez Adprep /rodcprep la commande sur Windows Server 2008, vous recevez le message
Adprep n’a pas pu contacter un réplica pour partition DC=DomainDnsZones,DC=Contoso,DC=com

Adprep a échoué à l’opération sur la partition DC=DomainDnsZones,DC=Contoso,DC=com Skipping to next
partition.
Adprep n’a pas pu contacter un réplica pour partition DC=ForestDnsZones,DC=Contoso,DC=com
Adprep a rencontré une erreur LDAP. Code d’erreur : 0x0. Code d’erreur étendu du serveur : 0x0, message
d’erreur serveur : (null).
Adprep a échoué à l’opération sur la partition DC=ForestDnsZones,DC=Contoso,DC=com Skipping to next
partition.
Adprep est terminé avec des erreurs. Toutes les partitions ne sont pas mises à jour.
Cause
Ce problème se produit lorsque la commande tente de contacter le maître Adprep /rodcprep d’infrastructure
pour chaque partition d’application dans la forêt. La commande permet de définir les autorisations requises
pour la réplication Read-Only contrôleur de domaine (RODC). La Adprep /rodcprep commande échoue si l’une
des conditions suivantes est vraie :
La partition ou les partitions référencés dans le message d’erreur n’existent plus.
Le maître d’infrastructure pour la ou les partitions référencé(s) a été rétrogradé de force ou est hors
connexion.
Résolution
Pour résoudre ce problème si la partition n’existe plus, faites un nettoyage des métadonnées pour la partition
orpheline à l’aide du paramètre « remove nc » de l’outil Dsmgmt. Pour plus d’informations, visitez le site Web
Microsoft suivant :
gestion des partitions
Si la partition spécifiée existe, spécifiez un propriétaire de rôle d’infrastructure en ligne pour la partition. Vous
pouvez le faire en modifiant manuellement l’attribut fSMORoleOwner sur l’objet, comme décrit dans la section
« Plus d’informations ».
L’exemple de script suivant modifie l’attribut fSMORoleOwner sur l’objet infrastructure du NDNC (Non-
Domain Naming Context) spécifié en un serveur actif ou contactable. Le NDNC de cet exemple est le contexte
d’appellation NDNC DomainDnsZones,DC=contoso,DC=com. Le script utilise la commande suivante :
cscript fixfsmo.vbs DC=DomainDnsZones,DC=contoso,DC=com

'-------fixfsmo.vbs------------------
const ADS_NAME_INITTYPE_GC = 3
const ADS_NAME_TYPE_1779 = 1
const ADS_NAME_TYPE_CANONICAL = 2
set inArgs = WScript.Arguments
if (inArgs.Count = 1) then
' Assume the command line argument is the NDNC (in DN form) to use.
NdncDN = inArgs(0)
Else
Wscript.StdOut.Write "usage: cscript fixfsmo.vbs NdncDN"
End if
if (NdncDN <> "") then
' Convert the DN form of the NDNC into DNS dotted form.
Set objTranslator = CreateObject("NameTranslate")
objTranslator.Init ADS_NAME_INITTYPE_GC, ""
objTranslator.Set ADS_NAME_TYPE_1779, NdncDN
strDomainDNS = objTranslator.Get(ADS_NAME_TYPE_CANONICAL)
strDomainDNS = Left(strDomainDNS, len(strDomainDNS)-1)
Wscript.Echo "DNS name: " & strDomainDNS
' Find a domain controller that hosts this NDNC and that is online.
set objRootDSE = GetObject("LDAP://" & strDomainDNS & "/RootDSE")
strDnsHostName = objRootDSE.Get("dnsHostName")
strDsServiceName = objRootDSE.Get("dsServiceName")
Wscript.Echo "Using DC " & strDnsHostName
' Get the current infrastructure fsmo.

strInfraDN = "CN=Infrastructure," & NdncDN
set objInfra = GetObject("LDAP://" & strInfraDN)
Wscript.Echo "infra fsmo is " & objInfra.fsmoroleowner
' If the current fsmo holder is deleted, set the fsmo holder to this domain controller.
if (InStr(objInfra.fsmoroleowner, "\0ADEL:") > 0) then
' Set the fsmo holder to this domain controller.

objInfra.Put "fSMORoleOwner", strDsServiceName
objInfra.SetInfo
' Read the fsmo holder back.

set objInfra = GetObject("LDAP://" & strInfraDN)
Wscript.Echo "infra fsmo changed to:" & objInfra.fsmoroleowner
End if
End if
Pour déterminer le maître d’infrastructure d’une partition, interrogez l’attribut fSMORoleOwner sur l’objet
d’infrastructure sous la racine du contexte d’appellation en question. Par exemple, interrogez l’attribut
fSMORoleOwner sur le CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=com naming
context root to determine the infrastructure master for the DC=DomainDnsZones,DC=contoso,DC=com
partition. De même, interrogez l’attribut fSMORoleOwner sur l’attribut
CN=Infrastructure,DC=ForestDnsZones,DC=contoso,DC=com naming context root to determine the
infrastructure master for the D C=ForestDnsZones,DC=contoso,DC=com partition.
Vous pouvez utiliser des outils tels que l’outil LDP, l’outil ADSI (Active Directory Service Interfaces) Edit et l’outil
ldifde pour ces requêtes. Par exemple, la requête suivante utilise l’outil Idifde :
ldifde -f Infra_DomainDNSZones.ldf -d « CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=com » -l
fSMORoleOwner
Cette requête renvoie le propriétaire du rôle principal d’infrastructure pour la partition
DC=DomainDnsZones,DC=contoso,DC=com au fichier Infra_DomainDNSZones.ldf.
NOTE
Vous pouvez exécuter la Adprep /rodcprep commande plusieurs fois sans endommager la forêt. Les opérations
effectuées lors des exécutions antérieures de la commande rodcprep ne sont pas répétées.
Si vous essayez d’exécuter la commande dans un environnement isolé, le maître d’infrastructure pour chaque
domaine et pour chaque partition d’annuaire d’applications doit être disponible dans l’environnement pour que
l’opération rodcprep réussisse.
Comment configurer la délégation Kerberos
contrainte pour les pages proxy d’inscription web
L’article fournit des instructions pas à pas pour implémenter le service pour l’utilisateur au proxy (S4U2Proxy)
ou la délégation Kerberos contrainte uniquement sur un compte de service personnalisé pour les pages proxy
d’inscription Web.
S’applique à : Window Server 2016, Window Server 2019, Windows Server 2012 R2
Résumé
Cet article fournit des instructions pas à pas pour implémenter le service pour l’utilisateur au proxy (S4U2Proxy)
ou la délégation Kerberos contrainte uniquement pour les pages proxy d’inscription Web. Cet article décrit les
scénarios de configuration suivants :
Configuration de la délégation pour un compte de service personnalisé
Configuration de la délégation au compte NetworkService
NOTE
Les flux de travail décrits dans cet article sont spécifiques à un environnement particulier. Les mêmes flux de travail
peuvent ne pas fonctionner pour une situation différente. Toutefois, les principes restent les mêmes. La figure suivante
résume cet environnement.
Scénario 1 : configurer la délégation contrainte pour un compte de

service personnalisé
Cette section décrit comment implémenter le service pour la délégation contrainte d’utilisateur à proxy
(S4U2Proxy) ou Kerberos uniquement lorsque vous utilisez un compte de service personnalisé pour les pages
proxy d’inscription Web.
1. Ajouter un SPN au compte de service
Associez le compte de service à un nom principal de service (SPN). Pour cela, procédez comme suit :
1. Dans Utilisateurs et ordinateurs Active Director y, connectez-vous au domaine, puis sélectionnez
Utilisateurs > PKI .
2. Cliquez avec le bouton droit sur le compte de service (par exemple, web_svc), puis sélectionnez
Propriétés.
3. Select Attribute Editor > ser vicePrincipalName .
4. Tapez la nouvelle chaîne SPN, sélectionnez Ajouter (comme illustré dans la figure suivante), puis
sélectionnez OK .
Vous pouvez également utiliser Windows PowerShell pour configurer le SPN. Pour ce faire, ouvrez une
fenêtre PowerShell avec élévation de niveaux, puis exécutez setspn -s SPN Accountname . Par exemple,
exécutez la commande suivante :
setspn -s HTTP/webenroll2016.contoso.com web_svc
2. Configurer la délégation
1. Configurez la délégation contrainte S4U2proxy (Kerberos uniquement) sur le compte de service. Pour ce
faire, dans la boîte de dialogue Propriétés du compte de service (comme décrit dans la procédure
précédente), sélectionnez Délégation Faites confiance à cet utilisateur pour la délégation aux services
spécifiés > uniquement. Assurez-vous que l’utilisation de Kerberos uniquement est sélectionnée.
2. Fermez la boîte de dialogue.
3. Dans l’arborescence de la console, sélectionnez Ordinateurs, puis le compte d’ordinateur du serveur
frontal d’inscription Web.
NOTE
Ce compte est également appelé « compte d’ordinateur ».
4. Configurez la délégation contrainte S4U2self (transition de protocole) sur le compte d’ordinateur. Pour ce
faire, cliquez avec le bouton droit sur le compte d’ordinateur, puis sélectionnez Délégation de propriétés
Faire confiance à cet ordinateur pour la délégation aux > > ser vices spécifiés uniquement.
Sélectionnez Utiliser tout protocole d’authentification .
3. Créer et lier le certificat SSL pour l’inscription web
Pour activer les pages d’inscription web, créez un certificat de domaine pour le site web, puis l’lier au site Web
par défaut. Pour cela, procédez comme suit :
1. Ouvrez Internet Information Services (IIS).
2. Dans l’arborescence de la console, <HostName _> sélectionnez _Certificats de serveur.
NOTE
<HostName> est le nom du serveur web frontal.
3. Dans le menu Actions, sélectionnez Créer un cer tificat de domaine.

4. Une fois le certificat créé, sélectionnez Site Web par défaut dans l’arborescence de la console, puis
sélectionnez Liaisons.
5. Assurez-vous que por t est définie sur 443 . Ensuite, sous cer tificat SSL, sélectionnez le certificat que
vous avez créé à l’étape 3.
6. Sélectionnez OK pour lier le certificat au port 443.
4. Configurer le serveur frontal d’inscription Web pour utiliser le compte de service
IMPORTANT
Assurez-vous que le compte de service fait partie des administrateurs locaux ou du groupe IIS_Users sur le serveur
web.
1. Cliquez avec le bouton droit sur DefaultAppPool, puis sélectionnez Advanced Paramètres .
2. Sélectionnez Identité du modèle > de processus, sélectionnez Compte personnalisé, puis

sélectionnez Définir. Spécifiez le nom et le mot de passe du compte de service.
3. Sélectionnez OK dans les boîtes de dialogue Définir les informations d’identification et l’identité du
pool d’applications.
4. Dans Advanced Paramètres , recherchez Charger le profil utilisateur et assurez-vous qu’il a la valeur
True .
Scénario 2 : configurer la délégation contrainte sur le compte

NetworkService
Cette section décrit comment implémenter la délégation contrainte S4U2Proxy ou Kerberos uniquement lorsque
vous utilisez le compte NetworkService pour les pages proxy d’inscription Web.
Étape facultative : configurer un nom à utiliser pour les connexions
Vous pouvez attribuer un nom au rôle d’inscription Web que les clients peuvent utiliser pour se connecter. Cette
configuration signifie que les demandes entrantes n’ont pas besoin de connaître le nom d’ordinateur du serveur
frontal d’inscription Web, ni d’autres informations de routage telles que le nom canonique DNS (CNAME).
Par exemple, supposons que le nom d’ordinateur de votre serveur d’inscription web soit WEBENROLLMAC
(dans le domaine Contoso). Vous souhaitez que les connexions entrantes utilisent plutôt le nom
ContosoWebEnroll. Dans ce cas, l’URL de connexion est la suivante :
https://contosowebenroll.contoso.com/certsrv
Il ne serait pas le suivant :

https://WEBENROLLMAC.contoso.com/certsrv
Pour utiliser une telle configuration, suivez les étapes suivantes :

1. Dans le fichier de zone DNS pour le domaine, créez un enregistrement d’alias ou un enregistrement de
nom d’hôte qui m’indique le nouveau nom de connexion à l’adresse IP du rôle d’inscription Web. Utilisez
l’outil Ping pour tester la configuration du routage.
Dans l’exemple mentionné précédemment, le fichier de zone possède un enregistrement d’alias qui maie
ContosoWebEnroll à l’adresse IP du rôle Contoso.com d’inscription Web.
2. Configurez le nouveau nom en tant que SPN pour le serveur frontal d’inscription web. Pour cela,
procédez comme suit :
a. Dans Utilisateurs et ordinateurs Active Directory, connectez-vous au domaine, puis sélectionnez
Ordinateurs.
b. Cliquez avec le bouton droit sur le compte d’ordinateur du serveur frontal d’inscription Web, puis
sélectionnez Propriétés.
NOTE
c. Select Attribute Editor > ser vicePrincipalName .

d. Tapez HTTP/ < ConnectionName > . < DomainName .com > , sélectionnez Ajouter, puis
sélectionnez OK .
NOTE
Dans cette chaîne, est le nouveau nom que vous <ConnectionName> avez défini et est le nom du
<DomainName> domaine. Dans l’exemple, la chaîne est HTTP/ContosoWebEnroll.contoso.com .
1. Configurer la délégation
1. Si vous ne vous êtes pas encore connecté au domaine, faites-le maintenant dans Utilisateurs et
ordinateurs Active Director y, puis sélectionnez Ordinateurs .
2. Cliquez avec le bouton droit sur le compte d’ordinateur du serveur frontal d’inscription Web, puis
NOTE
3. Sélectionnez Délégation, puis sélectionnez Faire confiance à cet ordinateur pour la délégation
aux ser vices spécifiés uniquement.
NOTE
Si vous pouvez garantir que les clients utiliseront toujours l’authentification Kerberos lorsqu’ils se connectent à ce
serveur, sélectionnez Utiliser Kerberos uniquement. Si certains clients utilisent d’autres méthodes
d’authentification, telles que l’authentification NTLM ou basée sur les formulaires, sélectionnez Utiliser n’impor te
quel protocole d’authentification.
2. Créer et lier le certificat SSL pour l’inscription web

Pour activer les pages d’inscription web, créez un certificat de domaine pour le site web, puis l’attachez au
premier site par défaut. Pour cela, procédez comme suit :
1. Ouvrez le Gestionnaire de services Internet.
2. Dans l’arborescence de la console, <HostName _> sélectionnez _ Certificats de serveur dans le volet
Actions.
NOTE
<HostName> est le nom du serveur web frontal.
3. Dans le menu Actions, sélectionnez Créer un cer tificat de domaine.

4. Une fois le certificat créé, sélectionnez Site Web par défaut, puis sélectionnez Liaisons.
5. Assurez-vous que por t est définie sur 443 . Ensuite, sous cer tificat SSL, sélectionnez le certificat que
vous avez créé à l’étape 3. Sélectionnez OK pour lier le certificat au port 443.
3. Configurer le serveur frontal d’inscription Web pour utiliser le compte NetworkService

1. Cliquez avec le bouton droit sur DefaultAppPool, puis sélectionnez Advanced Paramètres .
2. Sélectionnez l’identité du modèle > de processus. Assurez-vous que le compte intégré est
sélectionné, puis sélectionnez NetworkSer vice. Ensuite, sélectionnez OK.
3. Dans les propriétés avancées, recherchez Charger le profil utilisateur, puis assurez-vous qu’il a la
valeur True .
4. Redémarrez le service IIS.
Voir aussi
Pour plus d’informations sur ces processus, voir Authenticating Web Application Users.
Pour plus d’informations sur les extensions de protocole S4U2self et S4U2proxy, consultez les articles suivants :
[MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol
4.1 Exemple de domaine unique S4U2self
4.3 Exemple S4U2proxy
Le processus de promotion du contrôleur de
domaine affiche l’option Windows Server Technical
Preview dans la liste des niveaux fonctionnels
domaine et forêt
Cet article fournit une solution à un problème dans lequel le processus de promotion du contrôleur de domaine
affiche « Windows Server Technical Preview » dans la liste des niveaux fonctionnels domaine et forêt.
Symptômes
Vous avez un ordinateur en cours d’exécution Windows Server 2016.
Vous installez le rôle AD DS (Active Directory Domain Service).
Une fois le rôle installé, vous exécutez le processus de promotion du contrôleur de domaine (DC) sur le
serveur.
Toutefois, sur la deuxième page de l’Assistant Promotion dc, vous remarquez que les niveaux fonctionnels Forêt
et Domaine indiquent une version incorrecte de Windows, comme dans la capture d’écran suivante :
Vous vous attendez à ce que l’Assistant Promotion DC affiche Windows Ser ver 2016 au lieu de Windows
Ser ver Technical Preview .
NOTE
Les niveaux fonctionnels Windows Server 2016 domaine et forêt ne sont pas affectés sur le plan fonctionnel.
Cause
Ce problème se produit car la chaîne d’affichage n’a pas été mise à jour dans les niveaux fonctionnels forêt et
domaine avant la publication de Windows Server 2016.
Résolution
Pour résoudre ce problème, appliquez la dernière mise à jour cumulative Windows Server 2016 de Windows
Update avant de promouvoir un ordinateur en contrôleur de domaine.
Comment configurer un pare-feu pour les domaines
et approbations Active Directory
Cet article explique comment configurer un pare-feu pour les domaines et approbations Active Directory.
S ʼapplique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 Standard, Windows
Server 2012 Standard
Numéro de l’article d’origine dans la base de connaissances : 179442
NOTE
Tous les ports répertoriés dans les tableaux suivants ne sont pas requis dans tous les scénarios. Par exemple, si le pare-feu
sépare les membres et les contrôleurs de domaine, vous n’avez pas à ouvrir les ports FRS ou DFSR. En outre, si vous savez
qu’aucun client n’utilise LDAP avec SSL/TLS, vous n’avez pas à ouvrir les ports 636 et 3269.
NOTE
Les deux contrôleurs de domaine se trouvent tous les deux dans la même forêt, ou les deux contrôleurs de domaine se
trouvent chacun dans une forêt distincte. En outre, les approbations dans la forêt sont des approbations Windows Server
2003 ou des approbations d'une version ultérieure.
P O RT ( S) C L IEN T ( S) P O RT SERVEUR SERVIC E
1024-65535/TCP 135/TCP Mappeur de point de terminaison RPC
1024-65535/TCP 1024-65535/TCP RPC pour LSA, SAM, NetLogon (*)
1024-65535/TCP/UDP 389/TCP/UDP LDAP
1024-65535/TCP 636/TCP LDAP SSL
1024-65535/TCP 3268/TCP LDAP GC
1024-65535/TCP 3269/TCP LDAP GC SSL
53,1024-65535/TCP/UDP 53/TCP/UDP DNS
1024-65535/TCP/UDP 88/TCP/UDP Kerberos
1024-65535/TCP 445/TCP SMB
1024-65535/TCP 1024-65535/TCP FRS RPC (*)
Les ports NetBIOS répertoriés pour Windows NT sont également requis pour Windows 2000 et Windows
Server 2003 lorsque des approbations à des domaines sont configurées pour prendre en charge uniquement
les communications basées sur NetBIOS. Par exemple, systèmes d’exploitation Windows NT ou contrôleurs de
domaine tiers basés sur Samba.
Pour plus d’informations sur la définition des ports de serveur RPC utilisés par les services RPC LSA, consultez
les ressources suivantes :
Limitation du trafic RPC Active Directory à un port spécifique.
Section Contrôleurs de domaine et Active Directory dans l’article Vue d’ensemble des services et exigences
de ports réseau pour Windows.
Windows Server 2008 et versions ultérieures
Windows Server 2008 et les versions ultérieures de Windows Server ont augmenté la plage de ports clients
dynamiques pour les connexions sortantes. Le nouveau port de début par défaut est 49152 et le nouveau port
de fin par défaut est 65535. Par conséquent, vous devez augmenter la plage de ports RPC dans vos pare-feu.
Cette modification a été apportée pour respecter les recommandations de l’IANA (Internet Assigned Numbers
Authority). Cette situation diffère d’un domaine en mode mixte qui se compose de contrôleurs de domaine
Windows Server 2003, de contrôleurs de domaine serveur Windows 2000 ou de clients hérités, où la plage de
ports dynamiques par défaut est comprise entre 1025 et 5000.
Pour plus d’informations sur la modification de la plage de ports dynamiques dans Windows Server 2012 et
dans Windows Server 2012 R2, consultez les ressources suivantes :
La plage de ports dynamiques par défaut pour TCP/IP a changé.
Ports dynamiques dans Windows Server.
P O RT ( S) C L IEN T ( S) P O RT SERVEUR SERVIC E
49152-65535/UDP 123/UDP W32Time
49152-65535/TCP 135/TCP Mappeur de point de terminaison RPC
49152-65535/TCP 464/TCP/UDP Modification de mot de passe Kerberos
49152-65535/TCP 49152-65535/TCP RPC pour LSA, SAM, NetLogon (*)
49152-65535/TCP/UDP 389/TCP/UDP LDAP
49152-65535/TCP 636/TCP LDAP SSL
49152-65535/TCP 3268/TCP LDAP GC
49152-65535/TCP 3269/TCP LDAP GC SSL
53, 49152-65535/TCP/UDP 53/TCP/UDP DNS
49152-65535/TCP 49152-65535/TCP FRS RPC (*)
49152-65535/TCP/UDP 88/TCP/UDP Kerberos
49152-65535/TCP/UDP 445/TCP SMB (**)
49152-65535/TCP 49152-65535/TCP DFSR RPC (*)
Les ports NetBIOS répertoriés pour Windows NT sont également requis pour Windows 2000 et Server 2003
quand des approbations à des domaines sont configurées pour ne prendre en charge que les communications
NetBIOS. Par exemple, systèmes d’exploitation Windows NT ou contrôleurs de domaine tiers basés sur Samba.
(*) Pour plus d’informations sur la définition des ports serveurs RPC utilisés par les services LSA RPC, consultez
les ressources suivantes :
Limitation du trafic RPC Active Directory à un port spécifique.
Section Contrôleurs de domaine et Active Directory dans l’article Vue d’ensemble des services et exigences
de ports réseau pour Windows.
(**) Ce port n’est pas nécessaire pour le fonctionnement de l’approbation. Il n’est utilisé que pour la création
d’approbation.
NOTE
L’approbation externe 123/UDP n’est nécessaire que si vous avez configuré manuellement le service de temps Windows
pour qu’il se synchronise avec un serveur sur l’approbation externe.
Active Directory
Le client Microsoft LDAP utilise le test Ping ICMP quand une requête LDAP est en attente pendant une période
prolongée et qu’il attend une réponse. Il envoie des demandes ping pour vérifier que le serveur est toujours
présent sur le réseau. S’il ne reçoit pas de réponses ping, la demande LDAP échoue avec LDAP_TIMEOUT.
Le redirecteur Windows utilise également des messages Ping ICMP pour vérifier qu’une adresse IP de serveur
est résolue par le service DNS avant l’établissement d’une connexion, ainsi que quand un serveur est localisé à
l’aide du service DFS. Si vous souhaitez réduire le trafic ICMP, vous pouvez utiliser l’exemple de règle de pare-feu
suivant :
<any> ICMP -> DC IP addr = allow
Contrairement aux couches de protocole TCP et UDP, ICMP n’a pas de numéro de port, car il est hébergé
directement par la couche IP.
Par défaut, les serveurs DNS Windows Server 2003 et Windows 2000 Server utilisent des ports côté client
éphémères quand ils interrogent d’autres serveurs DNS. Toutefois, ce comportement peut être modifié par un
paramètre de Registre spécifique. Vous pouvez également établir une approbation via le tunnel obligatoire PPTP
(Point-to-Point Tunneling Protocol) pour limiter le nombre de ports que le pare-feu doit ouvrir. Pour PPTP, les
ports ci-dessous doivent être activés.
P O RT S C L IEN T S P O RT SERVEUR P ROTO C O L E
1024-65535/TCP 1723/TCP PPTP
En outre, vous devez activer IP PROTOCOL 47 (GRE).

NOTE
Quand vous ajoutez des autorisations à une ressource sur un domaine d’approbation pour les utilisateurs d’un domaine
approuvé, il existe des différences entre le comportement dans Windows 2000 et celui dans Windows NT 4.0. Si
l’ordinateur ne peut pas afficher la liste des utilisateurs du domaine distant, tenez compte du comportement suivant :
Windows NT 4.0 tente de résoudre les noms entrés manuellement en contactant le contrôleur de domaine principal
(CDP) pour le domaine de l’utilisateur distant (UDP 138). Si cette communication échoue, un ordinateur
Windows NT 4.0 contacte son propre CDP, puis demande la résolution du nom.
Windows 2000 et Windows Server 2003 tentent également de contacter le CDP de l’utilisateur distant pour une
résolution sur le port UDP 138. Toutefois, ils n’utilisent pas leur propre CDP. Veillez à ce que tous les serveurs membres
Windows 2000 et Windows Server 2003 qui accorderont l’accès aux ressources disposent d’une connectivité UDP 138
au CDP distant.
Référence
L’article Vue d’ensemble des services et exigences de ports réseau pour Windows décrit les ports, protocoles et
services réseau obligatoires utilisés par les systèmes d’exploitation client et serveur Microsoft, les programmes
serveurs et leurs sous-composants dans le système Microsoft Windows Server. Les administrateurs et les
professionnels de support peuvent utiliser cet article comme feuille de route pour déterminer quels ports et
protocoles sont nécessaires aux systèmes d’exploitation Microsoft et aux programmes pour la connectivité
réseau dans un réseau segmenté.
N’utilisez pas les informations sur les ports fournies dans l’article Vue d’ensemble des services et exigences de
ports réseau pour Windows pour configurer le Pare-feu Windows. Pour plus d’informations sur la configuration
du Pare-feu Windows, consultez l’article Windows Firewall with Advanced Security (en anglais uniquement).
Comment élever les niveaux fonctionnels de
domaine et de forêt Active Directory
Cet article explique comment élever les niveaux fonctionnels de domaine et de forêt Active Directory.
Résumé
Pour plus d’informationssur Windows Server 2016 et les nouvelles fonctionnalités des services de domaine
Active Directory (AD DS), voir Nouveautés des services de domaine Active Directory pour Windows Server
2016 .
Cet article traite de l’augmentation des niveaux fonctionnels de domaine et de forêt pris en charge par les
contrôleurs de domaine basés sur Microsoft Windows Server 2003 ou plus récents. Il existe quatre version
d’Active Directory et seuls les niveaux qui ont changé depuis Windows NT Server 4.0 nécessitent une attention
particulière. Par conséquent, les autres modifications de niveau sont mentionnées à l’aide des versions plus
récentes, actuelles ou antérieures du système d’exploitation du contrôleur de domaine, du domaine ou du
niveau fonctionnel de la forêt.
Les niveaux fonctionnels sont une extension du mode mixte et des concepts de mode natif introduits dans
Microsoft Windows 2000 Server pour activer de nouvelles fonctionnalités Active Directory. Certaines
fonctionnalités Active Directory supplémentaires sont disponibles lorsque tous les contrôleurs de domaine
exécutent la dernière version de Windows Server dans un domaine ou dans une forêt, et lorsque
l’administrateur active le niveau fonctionnel correspondant dans le domaine ou dans la forêt.
Pour activer les fonctionnalités de domaine les plus récentes, tous les contrôleurs de domaine doivent exécutent
la dernière version du système d’exploitation Windows Server dans le domaine. Si cette exigence est remplie,
l’administrateur peut augmenter le niveau fonctionnel du domaine.
Pour activer les fonctionnalités les plus récentes à l’échelle de la forêt, tous les contrôleurs de domaine de la
forêt doivent exécutent la version du système d’exploitation Windows Server qui correspond au niveau
fonctionnel de forêt souhaité. En outre, le niveau fonctionnel de domaine actuel doit déjà être au niveau le plus
récent. Si ces conditions sont remplies, l’administrateur peut augmenter le niveau fonctionnel de la forêt.
En règle générale, les modifications apportées aux niveaux fonctionnels du domaine et de la forêt sont
irréversibles. Si la modification peut être annulée, une récupération de forêt doit être utilisée. Avec le Windows
d’exploitation Server 2008 R2, les modifications apportées aux niveaux fonctionnels de domaine et aux niveaux
fonctionnels de forêt peuvent être revenir en arrière. Toutefois, la mise à jour peut être effectuée uniquement
dans les scénarios spécifiques décrits dans l’article Technet sur les niveaux fonctionnels d’Active Directory.
NOTE
Les niveaux fonctionnels de domaine les plus récents et les niveaux fonctionnels de forêt les plus récents affectent
uniquement la façon dont les contrôleurs de domaine fonctionnent ensemble en tant que groupe. Les clients qui
interagissent avec le domaine ou la forêt ne sont pas affectés. En outre, les applications ne sont pas affectées par les
modifications apportées aux niveaux fonctionnels du domaine ou aux niveaux fonctionnels de la forêt. Toutefois, les
applications peuvent tirer parti des fonctionnalités de domaine les plus nouvelles et des fonctionnalités de forêt les plus
nouvelles.
Pour plus d’informations, consultez l’article TechNet sur les fonctionnalités associées aux différents niveaux fonctionnels.
Augmentation du niveau fonctionnel

Cau t i on
N’augmentez pas le niveau fonctionnel si le domaine possède ou aura un contrôleur de domaine d’une version
antérieure à la version mentionnée pour ce niveau. Par exemple, un niveau fonctionnel Windows Server 2008
nécessite que tous les contrôleurs de domaine Windows Server 2008 ou un système d’exploitation ultérieur soit
installé dans le domaine ou dans la forêt. Une fois que le niveau fonctionnel du domaine est élevé, il ne peut être
modifié qu’à un niveau plus ancien à l’aide d’une récupération de forêt. Cette restriction existe parce que les
fonctionnalités modifient souvent la communication entre les contrôleurs de domaine ou parce que les
fonctionnalités modifient le stockage des données Active Directory dans la base de données.
La méthode la plus courante pour activer les niveaux fonctionnels de domaine et de forêt consiste à utiliser les
outils d’administration de l’interface utilisateur graphique (GUI) documentés dans l’article TechNet sur les
niveaux fonctionnels d’Active Directory Windows Server 2003. Cet article décrit Windows Server 2003.
Toutefois, les étapes sont les mêmes dans les versions plus récentes du système d’exploitation. En outre, le
niveau fonctionnel peut être configuré manuellement ou à l’aide de Windows PowerShell scripts. Pour plus
d’informations sur la configuration manuelle du niveau fonctionnel, voir la section « Afficher et définir le niveau
fonctionnel ».
Pour plus d’informations sur l’utilisation Windows PowerShell script pour configurer le niveau fonctionnel, voir
Élever le niveau fonctionnel de la forêt.
Afficher et définir manuellement le niveau fonctionnel
Les outils LDAP (Lightweight Directory Access Protocol), tels que Ldp.exe et Adsiedit.msc, peuvent être utilisés
pour afficher et modifier les paramètres fonctionnels actuels du domaine et de la forêt. Lorsque vous modifiez
manuellement les attributs de niveau fonctionnel, la meilleure pratique consiste à apporter des modifications
d’attribut au contrôleur de domaine FSMO (Flexible Single Master Operations) qui est normalement ciblé par les
outils d’administration Microsoft.
Paramètres de niveau fonctionnel du domaine
L’attribut msDS-Behavior-Version se trouve sur l’en-tête NC (naming context) du domaine, c’est-à-dire DC=corp,
DC=contoso, DC=com.
Vous pouvez définir les valeurs suivantes pour cet attribut :
Valeur 0 ou non set=domaine de niveau mixte
Valeur de 1 =Windows niveau de domaine Server 2003
Valeur de 4=Windows niveau de domaine Server 2008 R2
Paramètres du mode mixte et du mode natif
L’attribut ntMixedDomain se trouve sur l’en-tête nc (naming context) du domaine, c’est-à-dire DC=corp,
DC=contoso, DC=com.
Valeur 0=Domaine de niveau natif
Valeur 1=Domaine de niveau mixte
Paramètre au niveau de la forêt
L’attribut msDS-Behavior-Version se trouve sur l’objet CN=Partitions dans le contexte d’appellation de
configuration (NC), c’est-à-dire CN=Partitions, CN=Configuration, DC= ForestRootDomain.
Valeur 0 ou non définie =forêt de niveau mixte
Valeur de 1 =Windows niveau de forêt intermédiaire server 2003
Valeur de 2 =Windows forêt Server 2003
NOTE
Lorsque vous augmentez l’attribut msDS-Behavior-Version de la valeur 0 à la valeur 1 à l’aide deAdsiedit.msc, vous
recevez le message d’erreur suivant :
Opération de modification illégale. Certains aspects de la modification ne sont pas autorisés.

Valeur de 4=Windows niveau de domaine Server 2008 R2
Après avoir utilisé les outils LDAP (Lightweight Directory Access Protocol) pour modifier le niveau fonctionnel,
cliquez sur OK pour continuer. Les attributs sur le conteneur de partitions et sur l’en-tête de domaine sont
correctement augmentés. Si un message d’erreur est envoyé par le Ldp.exe, vous pouvez ignorer le message
d’erreur en toute sécurité. Pour vérifier que l’augmentation du niveau a réussi, actualisez la liste des attributs,
puis vérifiez le paramètre actuel. Ce message d’erreur peut également se produire une fois que vous avez
effectué l’augmentation du niveau sur le FSMO faisant autorité si la modification n’a pas encore été répliquée
sur le contrôleur de domaine local.
Afficher rapidement les paramètres actuels à l’aide Ldp.exe fichier
1. Démarrez le Ldp.exe fichier.
2. Dans le menu Connexion, cliquez sur Connecter .
3. Spécifiez le contrôleur de domaine que vous souhaitez interroger, ou laissez l’espace vide pour vous
connecter à n’importe quel contrôleur de domaine.
Une fois que vous vous êtes connecté à un contrôleur de domaine, les informations RootDSE du contrôleur de
domaine s’affiche. Ces informations incluent des informations sur la forêt, le domaine et les contrôleurs de
domaine. Voici un exemple de contrôleur de domaine Windows Server 2003. Dans l’exemple suivant, supposons
que le mode de domaine est Windows Server 2003 et que le mode forêt est Windows 2000 Server.
NOTE
La fonctionnalité du contrôleur de domaine représente le niveau fonctionnel le plus élevé possible pour ce contrôleur de
domaine.
1> domainFunctionality : 2=(DS_BEHAVIOR_WIN2003)
1> forestFunctionality : 0=(DS_BEHAVIOR_WIN2000)
1> domainControllerFunctionality : 2=(DS_BEHAVIOR_WIN2003)
Conditions requises lorsque vous modifiez manuellement le niveau fonctionnel

Vous devez modifier le mode domaine en mode natif avant d’augmenter le niveau de domaine si l’une
Le niveau fonctionnel du domaine est élevé par programme au deuxième niveau fonctionnel en
modifiant directement la valeur de l’attribut msdsBehaviorVersion sur l’objet domainDNS.
Le niveau fonctionnel du domaine est élevé au deuxième niveau fonctionnel à l’aide de l’utilitaire
Ldp.exe ou de l’utilitaire Adsiedit.msc.
Si vous ne modifiez pas le mode domaine en mode natif avant d’augmenter le niveau de domaine,
l’opération ne se termine pas correctement et vous recevez les messages d’erreur suivants :
SV_PROBLEM_WILL_NOT_PERFORM
ERROR_DS_ILLEGAL_MOD_OPERATION
En outre, le message suivant est consigné dans le journal des services d’annuaire :
Active Directory could not update the functional level of the following domain because the domain is
in mixed mode.
Dans ce scénario, vous pouvez modifier le mode domaine en mode natif à l’aide du logiciel en ligne
Utilisateurs & Ordinateurs Active Directory, à l’aide du logiciel en ligne MMC de l’interface utilisateur
d’active directory & Trusts ou en modifiant par programme la valeur de l’attribut ntMixedDomain sur 0
sur l’objet domainDNS. Lorsque ce processus est utilisé pour élever le niveau fonctionnel du domaine à 2
(Windows Server 2003), le mode domaine est automatiquement modifié en mode natif.
La transition du mode mixte au mode natif modifie l’étendue du groupe de sécurité Administrateurs du
schéma et du groupe de sécurité Administrateurs Enterprise en groupes universels. Lorsque ces groupes
ont été modifiés en groupes universels, le message suivant est consigné dans le journal système :
Event Type: Information

Event Source: SAM
Event ID: 16408
Computer:Server Name
Description: "Domain operation mode has been changed to Native Mode. The change cannot be reversed."
Lorsque les outils d’administration Windows Server 2003 sont utilisés pour appeler le niveau fonctionnel
du domaine, l’attribut ntmixedmode et l’attribut msdsBehaviorVersion sont modifiés dans l’ordre correct.
Toutefois, cela ne se produit pas toujours. Dans le scénario suivant, le mode natif est implicitement définie
sur la valeur 0 sans modifier l’étendue du groupe de sécurité Administrateurs du schéma et du groupe de
sécurité administrateurs de Enterprise sur universel :
L’attribut msdsBehaviorVersion qui contrôle le mode fonctionnel du domaine est manuellement ou
par programme la valeur 2.
Le niveau fonctionnel de la forêt est fixé à 2 à l’aide de n’importe quelle méthode. Dans ce scénario, les
contrôleurs de domaine bloquent la transition vers le niveau fonctionnel de la forêt jusqu’à ce que
tous les domaines qui se trouve dans le réseau local soient configurés en mode natif et que la
modification d’attribut requise soit réalisée dans les étendues du groupe de sécurité.
Niveaux fonctionnels pertinents pour Windows Server 2000
Windows Server 2000 prend en charge uniquement le mode mixte et le mode natif. En outre, il applique
uniquement ces modes à la fonctionnalité de domaine. Les sections suivantes listent les modes de domaine
Windows Server 2003, car ces modes affectent la mise à niveau des domaines Windows NT 4.0 et Windows
Server 2000.
Il existe de nombreuses considérations lors de l’augmentation du niveau de système d’exploitation du contrôleur
de domaine. Ces considérations sont dues aux limitations de stockage et de réplication des attributs liés dans
Windows 2000 Server.
Windows server 2000 mixte (par défaut)
Contrôleurs de domaine pris en charge : Microsoft Windows NT 4.0, Windows Server 2000, Windows Server
2003
Fonctionnalités activées : groupes locaux et globaux, prise en charge du catalogue global
Windows 2000 Server natif
Contrôleurs de domaine pris en charge : Windows Server 2000, Windows Server 2003, Windows Server
2008, Windows Server 2008 R2
Fonctionnalités activées : imbrmbrage de groupes, groupes universels, historique des sids, conversion de
groupes entre groupes de sécurité et groupes de distribution, vous pouvez augmenter les niveaux de
domaine en augmentant les paramètres au niveau de la forêt
Windows Serveur intermédiaire 2003
Contrôleurs de domaine pris en charge : Windows NT 4.0, Windows Server 2003
Fonctionnalités prise en charge : aucune fonctionnalité à l’échelle du domaine n’est activée à ce niveau. Tous
les domaines d’une forêt sont automatiquement élevés à ce niveau lorsque le niveau de la forêt passe à
intermédiaire. Ce mode est utilisé uniquement lorsque vous Windows des domaines NT 4.0 vers Windows
Server 2003.
Windows Server 2003
Contrôleurs de domaine pris en charge : Windows Server 2003, Windows Server 2008, Windows Server
2008 R2
Fonctionnalités prise en charge : changement de nom du contrôleur de domaine, attribut d’timestamp de
l’enregistrement mis à jour et répliqué. Prise en charge du mot de passe utilisateur sur la classe d’objet
InetOrgPerson. La délégation contrainte vous permet de rediriger les conteneurs Utilisateurs et ordinateurs.
Les domaines mis à niveau à partir de Windows NT 4.0 ou créés par la promotion d’un ordinateur basé sur
Windows Server 2003 fonctionnent au niveau fonctionnel mixte Windows 2000. Windows 2000 Server
conservent leur niveau fonctionnel actuel lorsque les contrôleurs de domaine Windows Server 2000 sont mis à
niveau vers le système d’exploitation Windows Server 2003. Vous pouvez élever le niveau fonctionnel du
domaine à Windows 2000 Server natif ou Windows Server 2003.
Niveau intermédiaire : mise à niveau à partir Windows domaine NT 4.0
Windows Server 2003 Active Directory autorise un niveau fonctionnel spécial de forêt et de domaine nommé
Windows Server 2003 intermédiaire. Ce niveau fonctionnel est fourni pour les mises à niveau des domaines NT
4.0 Windows existants dans lequel un ou plusieurs contrôleurs de domaine de sauvegarde Windows NT 4.0 (NT
4.0) doivent fonctionner après la mise à niveau. Windows de domaine Server 2000 ne sont pas pris en charge
dans ce mode. Windows L’intervalle de serveur 2003 s’applique aux scénarios suivants :
Mises à niveau de domaine Windows NT 4.0 vers Windows Server 2003.
Windows Les bdcs NT 4.0 ne sont pas mis à niveau immédiatement.
Windows Domaines NT 4.0 qui contiennent des groupes de plus de 5 000 membres (à l’exception du groupe
d’utilisateurs de domaine).
Il n’est pas prévu d’implémenter Windows contrôleurs de domaine Server2000 dans la forêt à tout moment.
Windows Server 2003 interim provides two important improvements while still permitting replication to
Windows NT 4.0 BDCs:
1. Réplication efficace des groupes de sécurité et prise en charge de plus de 5 000 membres par groupe.
2. Amélioration des algorithmes de générateur de topologie intersessants KCC.
En raison de l’efficacité de la réplication de groupe activée au niveau intermédiaire, le niveau intermédiaire est le
niveau recommandé pour toutes les mises à niveau Windows NT 4.0. Pour plus d’informations, voir la section «
Meilleures pratiques » de cet article.
Définition Windows niveau fonctionnel de forêt intermédiaire server 2003
Windows Server 2003 interim peut être activé de trois manières différentes. Les deux premières méthodes sont
fortement recommandées. Cela est dû au fait que les groupes de sécurité utilisent la réplication des valeurs liées
(LVR) après la mise à niveau du contrôleur de domaine principal (PDC) du domaine Windows NT 4.0 vers un
contrôleur de domaine Windows Server 2003. La troisième option est moins recommandée, car l’appartenance
à des groupes de sécurité utilise un attribut à valeurs multiples unique, ce qui peut entraîner des problèmes de
réplication. Les méthodes d’activation Windows Server 2003 intermédiaire sont les autres :
1. Pendant la mise à niveau.
L’option est présentée dans l’Assistant Installation dcpromo lorsque vous mettre à niveau le PDC d’un
domaine NT 4.0 Windows qui sert de premier contrôleur de domaine dans le domaine racine d’une
nouvelle forêt.
2. Avant de mettre à niveau le PDC Windows NT 4.0 d’un NT 4.0 Windows en tant que premier contrôleur
de domaine d’un nouveau domaine dans une forêt existante en configurant manuellement le niveau
fonctionnel de la forêt à l’aide des outils LDAP (Lightweight Directory Access Protocol).
Les domaines enfants héritent des paramètres de fonctionnalités à l’échelle de la forêt dans qui ils sont
promus. La mise à niveau du PDC d’un domaine NT 4.0 Windows en tant que domaine enfant dans une
forêt Windows Server 2003 existante où des niveaux fonctionnels de forêt intermédiaire ont été
configurés à l’aide du fichier Ldp.exe ou du fichier Adsiedit.msc permet aux groupes de sécurité d’utiliser
la réplication des valeurs liées après la mise à niveau de la version du système d’exploitation.
3. Après la mise à niveau à l’aide des outils LDAP.
Utilisez les deux dernières options lorsque vous rejoignez une forêt Windows Server 2003 existante lors
d’une mise à niveau. Il s’agit d’un scénario courant lorsqu’un domaine « racine vide » est en position. Le
domaine mis à niveau est joint en tant qu’enfant de la racine vide et hérite du paramètre de domaine de
la forêt.
Meilleures pratiques
La section suivante présente les meilleures pratiques en matière d’augmentation des niveaux fonctionnels. La
section est décomposée en deux parties. « Tâches de préparation » décrit le travail à effectuer avant
l’augmentation et « Augmentation optimale des chemins d’accès » décrit les motivations et les méthodes pour
différents scénarios d’augmentation de niveau.
Pour découvrir Windows contrôleurs de domaine NT 4.0, suivez les étapes suivantes :
1. À partir de Windows de domaine basé sur Server 2003, ouvrez Utilisateurs et ordinateurs Active
Director y.
2. Si le contrôleur de domaine n’est pas déjà connecté au domaine approprié, suivez les étapes suivantes
pour vous connecter au domaine approprié :
a. Cliquez avec le bouton droit sur l’objet domaine actuel, puis cliquez sur Connecter domaine.
b. Dans la boîte de dialogue Domaine, tapez le nom DNS du domaine à connecter, puis cliquez sur OK.
Vous pouvez également cliquer sur Parcourir pour sélectionner le domaine dans l’arborescence de
domaines, puis cliquez sur OK.
3. Cliquez avec le bouton droit sur l’objet domaine, puis cliquez sur Rechercher.
4. Dans la boîte de dialogue Rechercher, cliquez sur Recherche personnalisée.
5. Cliquez sur le domaine pour lequel vous souhaitez modifier le niveau fonctionnel.
6. Cliquez sur l’onglet Avancé .
7. Dans la zone de requête Entrer LDAP, tapez ce qui suit et ne laissez aucun espace entre les caractères :
(&(objectCategory=computer)(operatingSystem Version=4 * )
(userAccountControl:1.2.840.113556.1.4.803:=8192))
NOTE
Cette requête n’est pas sensible à la cas.
8. Cliquez sur Rechercher maintenant .

Une liste des ordinateurs du domaine qui exécutent Windows NT 4.0 et fonctionnent en tant que
contrôleurs de domaine apparaît.
Un contrôleur de domaine peut apparaître dans la liste pour l’une des raisons suivantes :
Le contrôleur de domaine exécute Windows NT 4.0 et doit être mis à niveau.
Le contrôleur de domaine est mis à niveau vers Windows Server 2003, mais la modification n’est pas
répliquée sur le contrôleur de domaine cible.
Le contrôleur de domaine n’est plus en service, mais l’objet ordinateur du contrôleur de domaine n’est pas
supprimé du domaine.
Avant de pouvoir modifier le niveau fonctionnel du domaine en Windows Server 2003, vous devez localiser
physiquement n’importe quel contrôleur de domaine dans la liste, déterminer l’état actuel du contrôleur de
domaine, puis mettre à niveau ou supprimer le contrôleur de domaine selon le cas.
NOTE
Contrairement aux contrôleurs de domaine Windows Server 2000, les contrôleurs de domaine Windows NT 4.0 ne
bloquent pas une augmentation de niveau. Lorsque vous modifiez le niveau fonctionnel du domaine, la réplication vers
Windows contrôleurs de domaine NT 4.0 s’arrête. Toutefois, lorsque vous essayez d’Windows niveau de la forêt Server
2003 avec des domaines dans Windows Server 2000, le niveau mixte est bloqué. L’absence de Windows DDC NT 4.0 est
implicite en raison de la nécessité au niveau de la forêt de tous les domaines au niveau natif ou ultérieur de Windows
Server 2000.
Exemple : Tâches de préparation avant l’augmentation du niveau

Dans cet exemple, l’environnement est élevé du mode mixte Windows Server 2000 au mode Windows server
2003.
Inventoriez la forêt pour les versions antérieures des contrôleurs de domaine.
Si une liste de serveurs précise n’est pas disponible, suivez les étapes suivantes :
1. Pour découvrir des domaines de niveau mixte, des contrôleurs de domaine Windows Server 2000 ou des
contrôleurs de domaine avec des objets endommagés ou manquants, utilisez les domaines Active Directory
et le logiciel en snap-in MMC Trusts.
2. Dans le logiciel en snap-in, cliquez sur Raise Forest Functionality, puis cliquez sur Enregistrer sous pour
générer un rapport détaillé.
3. Si aucun problème n’a été trouvé, l’option d’augmentation jusqu’au niveau de la forêt Windows Server 2003
est disponible dans la liste « Niveaux fonctionnels de forêt disponibles ». Lorsque vous essayez d’augmenter
le niveau de forêt, les objets contrôleur de domaine dans les conteneurs de configuration sont recherchés
pour les contrôleurs de domaine dont msds-behavior-version n’est pas définie sur le niveau cible
souhaité. Ils sont supposés être des Windows de domaine Server 2000 ou des objets contrôleurs de domaine
server Windows plus nouveaux endommagés.
4. Si des contrôleurs de domaine ou des contrôleurs de domaine de version antérieure qui ont des objets
ordinateur endommagés ou manquants ont été trouvés, ils sont inclus dans le rapport. L’état de ces
contrôleurs de domaine doit être examiné et la représentation du contrôleur de domaine dans Active
Directory doit être réparée ou supprimée à l’aide du fichier Ntdsutil.
Pour plus d’informations, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de
216498 supprimer des données dans Active Directory après une rétrogradation de contrôleur de domaine
infructueuse
Vé r i fi e r q u e l a r é p l i c a t i o n d e b o u t e n b o u t fo n c t i o n n e d a n s l a fo r ê t
Pour vérifier que la réplication de bout en bout fonctionne dans la forêt, utilisez la version Windows Server 2003
ou une version plus récente de Repadmin par rapport aux contrôleurs de domaine Windows Server 2000 ou
Windows Server 2003 :
Repadmin/Replsum * /Sort:Delta[/Errorsonly] pour l’inventaire initial.
Repadmin/Showrepl * /CSV>showrepl.csv. Importez dans Excel, puis utilisez le filtre automatique de
>données pour identifier les fonctionnalités de réplication.
Utilisez des outils de réplication tels que Repadmin pour vérifier que la réplication à l’échelle de la forêt
fonctionne correctement.
Vérifiez la compatibilité de tous les programmes ou services avec les contrôleurs de domaine Windows Server
les plus nouveaux et avec le mode Windows server et de forêt plus élevé. Utilisez un environnement de
laboratoire pour tester minutieusement les programmes et services de production pour les problèmes de
compatibilité. Contactez les fournisseurs pour confirmer la fonctionnalité.
Préparez un plan de sortie qui inclut l’une des actions suivantes :
Déconnectez au moins deux contrôleurs de domaine de chaque domaine de la forêt.
Créez une sauvegarde d’état système d’au moins deux contrôleurs de domaine à partir de chaque domaine
de la forêt.
Avant de pouvoir utiliser le plan de récupération, tous les contrôleurs de domaine de la forêt doivent être
désaffectés avant le processus de récupération.
NOTE
Les augmentations de niveau ne peuvent pas faire autorité. Cela signifie que tous les contrôleurs de domaine qui ont
répliqué l’augmentation du niveau doivent être désaffectés.
Une fois tous les contrôleurs de domaine précédents désaffectés, faites monter les contrôleurs de domaine
déconnectés ou restituer les contrôleurs de domaine à partir de la sauvegarde. Supprimez les métadonnées de
tous les autres contrôleurs de domaine, puis reomotez-les. Il s’agit d’un processus difficile à éviter.
Exemple : Comment passer du niveau mixte Windows Server 2000 au niveau de la forêt Windows Server 2003
Augmentez tous les domaines Windows niveau natif server 2000. Une fois cette approche terminée, augmentez
le niveau fonctionnel du domaine racine de la forêt Windows niveau de la forêt Server 2003. Lorsque le niveau
de la forêt est répliqué sur les PC de chaque domaine de la forêt, le niveau de domaine passe automatiquement
au niveau du domaine Windows Server 2003. Cette méthode présente les avantages suivants :
L’augmentation du niveau à l’échelle de la forêt n’est effectuée qu’une seule fois. Vous n’avez pas besoin
d’augmenter manuellement chaque domaine de la forêt jusqu’au niveau fonctionnel de Windows Server
2003.
Une vérification des Windows de domaine Server 2000 est effectuée avant l’augmentation du niveau (voir
les étapes de préparation). L’augmentation est bloquée jusqu’à ce que les contrôleurs de domaine
problématiques soient supprimés ou mis à niveau. Un rapport détaillé peut être généré en répertoriant les
contrôleurs de domaine bloquants et en fournissant des données actionnables.
Une vérification des domaines au niveau intermédiaire Windows Server 2000 mixte ou Windows Server
2003 est effectuée. L’augmentation est bloquée jusqu’à ce que les niveaux de domaine soient augmentés
jusqu’Windows server 2000 natif. Les domaines de niveau intermédiaire doivent être augmentés Windows
niveau de domaine Server 2003. Un rapport détaillé peut être généré en répertoriant les domaines
bloquants.
Windows Mises à niveau NT 4.0
Windows Les mises à niveau NT 4.0 utilisent toujours le niveau intermédiaire pendant la mise à niveau du PDC,
sauf si des contrôleurs de domaine Windows Server 2000 ont été introduits dans la forêt dans le PDC. Lorsque
le mode intermédiaire est utilisé pendant la mise à niveau du PDC, les grands groupes existants utilisent
immédiatement la réplication LVR, évitant ainsi les problèmes de réplication potentiels décrits plus tôt dans cet
article. Utilisez l’une des méthodes suivantes pour passer au niveau intermédiaire pendant la mise à niveau :
Sélectionnez le niveau intermédiaire pendant Dcpromo. Cette option est présentée uniquement lorsque le
PDC est mis à niveau vers une nouvelle forêt.
Définissez le niveau de forêt d’une forêt existante sur intermédiaire, puis rejoignez la forêt pendant la mise à
niveau du PDC. Le domaine mis à niveau hérite du paramètre de forêt.
Une fois tous les CCI NT 4.0 Windows mis à niveau ou supprimés, chaque domaine doit être transitioné au
niveau de la forêt et peut être passé en mode forêt Windows Server 2003.
Une raison d’éviter d’utiliser le mode intermédiaire est si vous envisagez d’implémenter des contrôleurs de
domaine Windows Server 2000 après la mise à niveau, ou à tout moment à l’avenir.
Considération spéciale pour les grands groupes dans Windows NT 4.0
Dans les domaines Windows NT 4.0, des groupes de sécurité contenant bien plus de 5 000 membres peuvent
exister. Dans Windows NT 4.0, lorsqu’un membre d’un groupe de sécurité change, seule la modification unique
d’appartenance est répliquée sur les contrôleurs de domaine de sauvegarde. Dans Windows Server 2000, les
appartenances aux groupes sont des attributs liés stockés dans un attribut à valeurs multiples unique de l’objet
groupe. Lorsqu’une seule modification est apporté à l’appartenance d’un groupe, le groupe entier est répliqué
en tant qu’unité unique. Étant donné que l’appartenance au groupe est répliquée en tant qu’unité unique, il est
possible que les mises à jour de l’appartenance au groupe soient « perdues » lorsque différents membres sont
ajoutés ou supprimés en même temps sur différents contrôleurs de domaine. En outre, la taille de cet objet
unique peut être plus importante que la mémoire tampon utilisée pour valider une entrée dans la base de
données. Pour plus d’informations, voir la section « Problèmes du magasin de versions avec les grands groupes
» de cet article. Pour ces raisons, la limite recommandée pour les membres du groupe est de 5 000.
L’exception à la règle de membre 5000 est le groupe principal (par défaut, il s’agit du groupe « Utilisateurs du
domaine »). Le groupe principal utilise un mécanisme « calculé » basé sur le « primarygroupID » de l’utilisateur
pour déterminer l’appartenance. Le groupe principal ne stocke pas les membres en tant qu’attributs liés à
valeurs multiples. Si le groupe principal de l’utilisateur est modifié en groupe personnalisé, son appartenance au
groupe Utilisateurs du domaine est écrite dans l’attribut lié pour le groupe et n’est plus calculée. Le nouveau
groupe principal Rid est écrit sur « primarygroupID » et l’utilisateur est supprimé de l’attribut membre du
groupe.
Si l’administrateur ne sélectionne pas le niveau intermédiaire pour le domaine de mise à niveau, vous devez
suivre les étapes suivantes avant la mise à niveau :
1. Inventoriez tous les grands groupes et identifiez les groupes de plus de 5 000, à l’exception du groupe
d’utilisateurs de domaine.
2. Tous les groupes qui ont plus de 5 000 membres doivent être divisés en groupes de moins de 5 000
membres.
3. Recherchez toutes les listes de contrôle d’accès dans laquelle les grands groupes ont été entrés et ajoutez les
petits groupes que vous avez créés à l’étape 2. Windows Le niveau de forêt intermédiaire de Server 2003
permet aux administrateurs de ne pas avoir à découvrir et réaffecter des groupes de sécurité globaux de plus
de 5 000 membres.
Problèmes du magasin de versions avec des groupes importants
Pendant les opérations de longue durée, telles que les recherches approfondies ou les validations sur un attribut
unique et de grande taille, Active Directory doit s’assurer que l’état de la base de données est statique jusqu’à ce
que l’opération soit terminée. Un exemple de recherches approfondies ou de validations sur des attributs de
grande taille est un grand groupe qui utilise le stockage hérité.
À mesure que les mises à jour de la base de données se produisent en permanence localement et à partir de
partenaires de réplication, Active Directory fournit un état statique en interrogeant toutes les modifications
entrantes jusqu’à ce que l’opération de longue durée soit terminée. Une fois l’opération terminée, les
modifications en file d’attente sont appliquées à la base de données.
L’emplacement de stockage de ces modifications en file d’attente est appelé « magasin de versions » et est
d’environ 100 mégaoctets. La taille du magasin de versions varie et dépend de la mémoire physique. Si une
opération de longue durée ne se termine pas avant l’épuisement du magasin de versions, le contrôleur de
domaine cesse d’accepter les mises à jour tant que l’opération de longue durée et les modifications en file
d’attente ne sont pas enregistrées. Les groupes qui atteignent un grand nombre (plus de 5 000 membres)
risquent d’épuiser le magasin de versions tant que le groupe important est engagé.
Windows Server 2003 introduit un nouveau mécanisme de réplication pour les attributs liés à valeurs multiples
appelé réplication de valeurs de lien (LVR). Au lieu de répliquer l’ensemble du groupe en une seule opération de
réplication, le système de réponse vocale lv permet de répondre à ce problème en réplication de chaque
membre du groupe en tant qu’opération de réplication distincte. Le LVR devient disponible lorsque le niveau
fonctionnel de la forêt est élevé au niveau de la forêt intermédiaire Windows Server 2003 ou au niveau de la
forêt Windows Server 2003. Dans ce niveau fonctionnel, la fonction LVR permet de répliquer des groupes entre
Windows de domaine Server 2003.
Résoudre les problèmes d’authentification unique
avec Services ADFS (AD FS)
Cet article vous aide à résoudre les problèmes d’authentification unique avec Services ADFS (AD FS).
Sélectionnez l’une des sections suivantes en fonction du type de problème que vous rencontrez.
S’applique à : Services ADFS numéro de base de connaissances d’origine : 4034932
Invite d’authentification NTLM ou basée sur les formulaires

Lors de la résolution des problèmes d’authentification unique avec Services ADFS (AD FS), si les utilisateurs ont
reçu une invite d’authentification NTLM ou basée sur des formulaires inattendue, suivez les étapes décrites dans
cet article pour résoudre ce problème.
Vérifier les paramètres d’authentification intégrée Windows
Pour résoudre ce problème, vérifiez les paramètres d’authentification intégrée de Windows dans le navigateur
client, les paramètres AD FS et les paramètres de demande d’authentification.
Vérifier le navigateur client de l’utilisateur
Vérifiez les paramètres suivants dans Les options Internet :
Sous l’onglet Avancé , vérifiez que le paramètre Activer l’authentification Windows intégrée est activé.
Après Les sites > intranet > locaux de sécurité > avancés , vérifiez que l’URL AD FS figure dans la liste des
sites web.
Après sécurité > intranet local > niveau personnalisé , assurez-vous que l’ouver ture de session
automatique uniquement dans le paramètre Zone Intranet est sélectionnée.
Si vous utilisez Firefox, Chrome ou Safari, vérifiez que les paramètres équivalents dans ces navigateurs sont
activés.
Vérifier les paramètres AD FS
Vé r i fi e r l e p a r a m è t r e W i n d o w s I n t e g r a t e d F a l l b a c k
1. Ouvrez Windows PowerShell avec l’option Exécuter en tant qu’administrateur.

2. Obtenez la stratégie d’authentification globale en exécutant la commande suivante :
Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
3. Examinez la valeur de l’attribut WindowsIntegratedFallbackEnabled .

Si la valeur est True , l’authentification basée sur les formulaires est attendue. Cela signifie que la demande
d’authentification provient d’un navigateur qui ne prend pas en charge l’authentification intégrée Windows.
Consultez la section suivante sur la prise en charge de votre navigateur.
Si la valeur est False , l’authentification intégrée Windows doit être attendue.
Vé r i fi e r l e p a r a m è t r e W I A Su p p o r t e d U se r s A g e n t s
1. Obtenez la liste des agents utilisateur pris en charge en exécutant la commande suivante :
Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

2. Examinez la liste des chaînes de l’agent utilisateur retournées par la commande.
Vérifiez si la chaîne de l’agent utilisateur de votre navigateur figure dans la liste. Si ce n’est pas le cas, ajoutez la
chaîne de l’agent utilisateur en suivant les étapes ci-dessous :
1. Accédez à http://useragentstring.com/ cette option pour détecter et afficher la chaîne de l’agent utilisateur
de votre navigateur.
2. Obtenez la liste des agents utilisateur pris en charge en exécutant la commande suivante :
$wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
3. Ajoutez la chaîne d’agent utilisateur de votre navigateur en exécutant la commande suivante :
$wiaStrings = $wiaStrings+"NewUAString"
Exemple :
$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
4. Mettez à jour le paramètre WIASupportedUserAgents en exécutant la commande suivante :
Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
Vérifier les paramètres de la demande d’authentification

Vé r i fi e r si l a d e m a n d e d ’ a u t h e n t i fi c a t i o n sp é c i fi e l ’ a u t h e n t i fi c a t i o n b a sé e su r l e s fo r m u l a i r e s c o m m e m é t h o d e d ’ a u t h e n t i fi c a t i o n
1. Si la demande d’authentification est une demande WS-Federation, vérifiez si la demande inclut wauth=
urn:oasis:names:tc:SAML:1.0:am:password .
2. Si la demande d’authentification est une demande SAML, vérifiez si la demande inclut un élément
samlp:AuthnContextClassRef avec la valeur urn:oasis:names:tc:SAML:2.0:ac:classes:Password .
Pour plus d’informations, consultez Vue d’ensemble des gestionnaires d’authentification des pages de connexion
AD FS.
Vé r i fi e z si l ’ a p p l i c a t i o n e st M i c r o so ft O n l i n e Se r v i c e s p o u r O ffi c e 3 6 5
Si l’application à laquelle vous souhaitez accéder n’est pas Microsoft Online Services, ce que vous rencontrez est
attendu et contrôlé par la demande d’authentification entrante. Collaborez avec le propriétaire de l’application
pour modifier le comportement.
Si l’application est Microsoft Online Services, ce que vous rencontrez peut être contrôlé par le paramètre
PromptLoginBehavior de l’objet de domaine approuvé. Ce paramètre contrôle si les locataires Azure AD
envoient prompt=login à AD FS. Pour définir le paramètre PromptLoginBehavior , procédez comme suit :
1. Ouvrez Windows PowerShell avec l’option « Exécuter en tant qu’administrateur ».
2. Obtenez le paramètre de fédération de domaine existant en exécutant la commande suivante :
Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
3. Définissez le paramètre PromptLoginBehavior en exécutant la commande suivante :

Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior
<TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -
PreferredAuthenticationProtocol <WsFed|SAMLP>
Les valeurs du paramètre PromptLoginBehavior sont les suivantes :

a. TranslateToFreshPasswordAuth : Azure AD envoie wauth et wfresh à AD FS au lieu
d’prompt=login. Cela aboutit à une demande d’authentification pour utiliser l’authentification basée
sur les formulaires.
b. NativeSuppor t : le paramètre prompt=login est envoyé tel qu’il est à AD FS.
c. Désactivé : rien n’est envoyé à AD FS.
Pour en savoir plus sur la commande Set-MSOLDomainFederationSettings, consultez Services ADFS prise en
charge des paramètres prompt=login.
Scénario Azure Active Directory (Azure AD)
Si la demande d’authentification envoyée à Azure AD inclut le paramètre prompt=login, désactivez la
fonctionnalité prompt=login en exécutant la commande suivante :
Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled
Après avoir exécuté cette commande, Office 365 applications n’incluent pas le paramètre prompt=login dans
chaque demande d’authentification.
Scénario non Azure AD
Les méthodes d’authentification peuvent être spécifiées pour les paramètres de requête tels que WAUTH et
RequestedAuthNContext dans les demandes d’authentification. Vérifiez si d’autres paramètres de requête
appliquent l’invite d’authentification inattendue. Si c’est le cas, modifiez le paramètre de requête pour utiliser la
méthode d’authentification attendue.
Vérifier si l’authentification unique est désactivée
Si l’authentification unique est désactivée, activez-la et testez si le problème est résolu.
Invite d’authentification multifacteur

Pour résoudre ce problème, vérifiez si les règles de revendication dans la partie de confiance sont correctement
définies pour l’authentification multifacteur.
L’authentification multifacteur peut être activée sur un serveur AD FS, à une partie de confiance ou spécifiée
dans un paramètre de demande d’authentification. Vérifiez les configurations pour voir si elles sont
correctement définies. Si l’authentification multifacteur est attendue mais que vous y êtes invité à plusieurs
reprises, vérifiez les règles d’émission de partie de confiance pour voir si les revendications d’authentification
multifacteur sont transmises à l’application.
Pour plus d’informations sur l’authentification multifacteur dans AD FS, consultez les articles suivants :
Visite guidée de Multi-Factor Authentication dans ADFS – Partie 1 : Stratégie
Visite guidée sous le capot sur l’authentification multifacteur dans ADFS – Partie 2 : Parties de confiance
tenant compte de l’authentification multifacteur
Vérifier la configuration sur le serveur AD FS et la partie de confiance
Pour vérifier la configuration sur le serveur AD FS, validez les règles d’authentification supplémentaires globales.
Pour vérifier la configuration sur la partie de confiance, validez les règles d’authentification supplémentaires
pour l’approbation de partie de confiance.
1. Pour vérifier la configuration sur le serveur AD FS, exécutez la commande suivante dans une fenêtre
Windows PowerShell.
Get-ADFSAdditionalAuthenticationRule
Pour vérifier la configuration sur la partie de confiance, exécutez la commande suivante :
Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty

AdditionalAuthenticationRules
NOTE
Si les commandes ne retournent rien, les règles d’authentification supplémentaires ne sont pas configurées.
Ignorez cette section.
2. Observez l’ensemble de règles de revendication configuré.

Vérifier si l’authentification multifacteur est activée dans l’ensemble de règles de revendication
Un ensemble de règles de revendication est composé des sections suivantes :
Instruction de condition : C:[Type=``…,Value=…]
L’instruction issue : => issue (Type=``…,Value=…)
Si l’instruction issue contient la revendication suivante, l’authentification multifacteur est spécifiée.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value =
"http://schemas.microsoft.com/claims/multipleauthn"
Voici des exemples qui nécessitent l’utilisation de l’authentification multifacteur pour les appareils non joints au
lieu de travail et pour l’accès extranet, respectivement :
c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value ==
"false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
Value = "http://schemas.microsoft.com/claims/multipleauthn")
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] =>
issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value =
"http://schemas.microsoft.com/claims/multipleauthn")
Vérifier les règles d’émission de partie de confiance

Si l’utilisateur reçoit à plusieurs reprises des invites d’authentification multifacteur après avoir effectué la
première authentification, il est possible que la partie de réponse ne passe pas les revendications
d’authentification multifacteur à l’application. Pour vérifier si les revendications d’authentification sont
transmises, procédez comme suit :
1. Exécutez la commande suivante dans Windows PowerShell:
Get-ADFSRelyingPartyTrust -TargetName ClaimApp
2. Observez l’ensemble de règles défini dans les attributs IssuanceAuthorizationRules ou

IssuanceAuthorizationRulesFile.
L’ensemble de règles doit inclure la règle d’émission suivante pour passer par les revendications
d’authentification multifacteur :
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==”
http://schemas.microsoft.com/claims/multipleauthn”]=>issue(claim = c)
Vérifier le paramètre de demande d’authentification

Vérifier si la demande d’authentification spécifie l’authentification multifacteur comme méthode d’authentification
Si la demande d’authentification est une demande WS-Federation, vérifiez si la demande inclut
wauth= http://schemas.microsoft.com/claims/multipleauthn .
Si la demande d’authentification est une demande SAML, vérifiez si la demande inclut un élément
samlp:AuthnContextClassRef avec une valeur http://schemas.microsoft.com/claims/multipleauthn .
Pour plus d’informations, consultez Vue d’ensemble des gestionnaires d’authentification des pages de connexion
AD FS.
Vérifiez si l’application est Microsoft Online Services pour Office 365
Si l’application à laquelle vous souhaitez accéder est Microsoft Online Services pour Office 365, vérifiez le
paramètre de fédération de domaine SupportsMFA.
1. Obtenez le paramètre actuel de fédération de domaine SupportsMFA en exécutant la commande suivante
:
Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
2. Si le paramètre SupportsMFA est FALSE, définissez-le sur TRUE en exécutant la commande suivante :
Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
Vérifier si l’authentification unique est désactivée

Si l’authentification unique est désactivée, activez-la et testez si le problème est résolu.
Les utilisateurs ne peuvent pas se connecter au site ou au service

cible
Ce problème peut se produire sur la page de connexion AD FS ou côté application.
Si le problème se produit sur la page de connexion AD FS, vous recevez un message d’erreur « Une erreur s’est
produite », « Le service HTTP 503 n’est pas disponible » ou un autre message d’erreur. L’URL de la page d’erreur
affiche le nom du service AD FS, par exemple fs.contoso.com .
Si le problème se produit côté application, l’URL de la page d’erreur affiche l’adresse IP ou le nom du site du
service cible.
Suivez les étapes décrites dans la section suivante en fonction de l’endroit où vous rencontrez ce problème.
Ce problème se produit sur la page de connexion AD FS
Pour résoudre ce problème, vérifiez si tous les utilisateurs sont concernés par le problème et si les utilisateurs
peuvent accéder à toutes les parties de confiance.
Tous les utilisateurs sont affectés par le problème, et l’utilisateur ne peut accéder à aucune des parties de confiance
Vérifions la fonctionnalité de connexion interne à l’aide d’IdpInitiatedSignOn. Pour ce faire, utilisez la page
IdpInititatedSignOn pour vérifier si le service AD FS est opérationnel et si la fonctionnalité d’authentification
fonctionne correctement. Pour ouvrir la page IdpInitiatedSignOn, procédez comme suit :
1. Activez la page IdpInitiatedSignOn en exécutant la commande suivante sur le serveur AD FS :
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
2. À partir d’un ordinateur qui se trouve à l’intérieur de votre réseau, visitez la page suivante :
https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx
3. Entrez les informations d’identification correctes d’un utilisateur valide dans la page de connexion.
L a c o n n e x i o n a r é u ssi
Si la connexion réussit, vérifiez si l’état du service AD FS est en cours d’exécution.

1. Sur le serveur AD FS, ouvrez Gestionnaire de serveur.
2. Dans le Gestionnaire de serveur, cliquez sur Outils > Ser vices .
3. Vérifiez si l’état de Ser vices ADFS est en cours d’exécution .
Ensuite, vérifiez la fonctionnalité de connexion externe à l’aide d’IdpInitiatedSignOn. Utilisez la page
IdpInititatedSignOn pour vérifier rapidement si le service AD FS est opérationnel et si la fonctionnalité
d’authentification fonctionne correctement. Pour ouvrir la page IdpInitiatedSignOn, procédez comme suit :
1. Activez la page IdpInitiatedSignOn en exécutant la commande suivante sur le serveur AD FS :
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
2. À partir d’un ordinateur situé en dehors de votre réseau, visitez la page suivante :
https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx
3. Entrez les informations d’identification correctes d’un utilisateur valide dans la page de connexion.
Si la connexion échoue, consultez Vérifier les composants et services associés à AD FS et vérifier la relation
d’approbation du proxy.
Si la connexion réussit, poursuivez la résolution des problèmes en suivant les étapes décrites dans Tous les
utilisateurs concernés par le problème, et l’utilisateur peut accéder à certaines des parties de confiance.
La c o n n exi o n éc h o u e
Si la connexion échoue, vérifiez les composants et services associés à AD FS.

Vérifiez si l’état du service AD FS est en cours d’exécution.
1. Sur le serveur AD FS, ouvrez Gestionnaire de serveur.
2. Dans le Gestionnaire de serveur, cliquez sur Outils > Ser vices .
3. Vérifiez si l’état de Ser vices ADFS est en cours d’exécution .
Vérifiez si les points de terminaison sont activés. AD FS fournit différents points de terminaison pour différents
scénarios et fonctionnalités. Tous les points de terminaison ne sont pas activés par défaut. Pour vérifier l’état des
points de terminaison, procédez comme suit :
1. Sur le serveur AD FS, ouvrez la console de gestion AD FS.
2. Développez les points de terminaison de ser vice > .
3. Recherchez les points de terminaison et vérifiez si les états sont activés sur la colonne Activé .
Ensuite, vérifiez si Azure AD Connect est installé. Nous vous recommandons d’utiliser Azure AD Connect pour
faciliter la gestion des certificats SSL.
Si Azure AD Connect est installé, veillez à l’utiliser pour gérer et mettre à jour les certificats SSL.
Si Azure AD Connect n’est pas installé, vérifiez si le certificat SSL répond aux exigences AD FS suivantes :
Le certificat est issu d’une autorité de certification racine approuvée.
AD FS requiert que les certificats SSL proviennent d’une autorité de certification racine approuvée. Si AD
FS est accessible à partir d’ordinateurs non joints à un domaine, nous vous recommandons d’utiliser un
certificat SSL à partir d’une autorité de certification racine tierce approuvée comme DigiCert, VeriSign,
etc. Si le certificat SSL ne vient pas d’une autorité de certification racine approuvée, la communication
SSL peut s’interrompre.
Le nom d’objet du certificat est valide.
Le nom de l’objet doit correspondre au nom du service de fédération, et non au nom du serveur AD FS
ou à un autre nom. Pour obtenir le nom du service de fédération, exécutez la commande suivante sur le
serveur AD FS principal :
Get-AdfsProperties | select hostname
Le certificat n’est pas révoqué.

Recherchez la révocation de certificat. Si le certificat est révoqué, la connexion SSL ne peut pas être
approuvée et sera bloquée par les clients.
Si le certificat SSL ne répond pas à ces exigences, essayez d’obtenir un certificat qualifié pour la communication
SSL. Nous vous recommandons d’utiliser Azure AD Connect pour faciliter la gestion des certificats SSL.
Consultez Mettre à jour le certificat TLS/SSL pour une batterie de serveurs Services ADFS (AD FS).
Si le certificat SSL répond à ces exigences, vérifiez les configurations suivantes du certificat SSL.
V é ri f i e r s i l e c e rt i f i c a t SSL e s t c o rre c t e me n t i n s t a l l é
Le certificat SSL doit être installé dans le magasin personnel de l’ordinateur local sur chaque serveur de
fédération de votre batterie de serveurs. Pour installer le certificat, double-cliquez sur . Fichier PFX du certificat
et suivez l’Assistant.
Pour vérifier si le certificat est installé à l’emplacement approprié, procédez comme suit :
1. Répertoriez les certificats qui se trouvent dans le magasin personnel de l’ordinateur local en exécutant la
commande suivante :
dir Cert:\LocalMachine\My
2. Vérifiez si le certificat figure dans la liste.
V é ri f i e r s i l e c e rt i f i c a t SSL c o rre c t e s t u t i l i s é
Obtenez l’empreinte numérique du certificat utilisé pour la communication SSL et vérifiez si l’empreinte
numérique correspond à l’empreinte du certificat attendue.
Pour obtenir l’empreinte numérique du certificat en cours d’utilisation, exécutez la commande suivante dans
Windows PowerShell :
Get-AdfsSslCertificate
Si le certificat incorrect est utilisé, définissez le certificat approprié en exécutant la commande suivante :
Set-AdfsSslCertificate –Thumbprint CorrectThumprint
V é ri f i e r s i l e c e rt i f i c a t SSL e s t d é f i n i c o mme c e rt i f i c a t d e c o mmu n i c a t i o n d e s e rv i c e

Le certificat SSL doit être défini comme certificat de communication de service dans votre batterie de serveurs
AD FS. Cela ne se produit pas automatiquement. Pour vérifier si le certificat correct est défini, procédez comme
suit :
1. Dans la console de gestion AD FS, développez Cer tificats de ser vice > .
2. Vérifiez si le certificat répertorié sous Communications de ser vice est le certificat attendu.
Si le certificat incorrect est répertorié, définissez le certificat approprié, puis accordez au service AD FS
l’autorisation de lecture sur le certificat. Pour cela, procédez comme suit :
1. Définissez le certificat correct :
a. Cliquez avec le bouton droit sur Cer tificats , puis cliquez sur Définir le cer tificat de
communication de ser vice .
b. Sélectionnez le certificat approprié.
2. Vérifiez si le service AD FS dispose de l’autorisation de lecture sur le certificat :
a. Ajoutez le composant logiciel enfichable Cer tificats pour le compte d’ordinateur local à la console de
gestion Microsoft (MMC).
b. Développez Cer tificats (Ordinateur local) > Personnel > Cer tificats .
c. Cliquez avec le bouton droit sur le certificat SSL, puis cliquez sur Toutes les tâches > gérer les clés
privées .
d. Vérifiez si adfssr v est répertorié sous Les noms de groupes et d’utilisateurs avec l’autorisation
Lecture .
3. Si adfssrv n’est pas répertorié, accordez au service AD FS l’autorisation de lecture sur le certificat :
a. Cliquez sur Ajouter , cliquez sur Emplacements , sur le serveur, puis sur OK .
b. Sous Entrez les noms d’objets à sélectionner , entrez nt ser vice\adfssr v , cliquez sur Vérifier
les noms , puis cliquez sur OK .
Si vous utilisez AD FS avec le service d’inscription d’appareil (DRS), entrez nt ser vice\drs à la place.
c. Accordez l’autorisation lecture , puis cliquez sur OK .
V é ri f i e r s i l e s e rv i c e d ’ i n s c ri p t i o n d ’ a p p a re i l ( DR S) e s t c o n f i g u ré d a n s A D F S
Si vous avez configuré AD FS avec DRS, assurez-vous que le certificat SSL est également correctement configuré
pour RDS. Par exemple, s’il existe deux suffixes contoso.com UPN et fabrikam.com , le certificat doit avoir
enterpriseregistration.contoso.com et enterpriseregistration.fabrikma.com en tant que nom d’alternative de
sujet (SAN).
Pour vérifier si le certificat SSL a les noms d’accès partagés appropriés, procédez comme suit :
1. Répertoriez tous les suffixes UPN utilisés dans l’organisation en exécutant la commande suivante :
Get-AdfsDeviceRegistratrionUpnSuffix
2. Vérifiez si les noms d’accès partagés requis sont configurés pour le certificat SSL.
3. Si le certificat SSL n’a pas les noms DRS corrects en tant que noms SAN, obtenez un nouveau certificat
SSL qui contient les noms d’accès partagés appropriés pour DRS, puis utilisez-le comme certificat SSL
pour AD FS.
Ensuite, vérifiez la configuration du certificat sur les serveurs WAP et les liaisons de secours :
Vérifiez si le certificat SSL correct est défini sur tous les serveurs WAP.
1. Assurez-vous que le certificat SSL est installé dans le magasin Personnel de l’ordinateur local sur
chaque serveur WAP.
2. Obtenez le certificat SSL utilisé par WAP en exécutant la commande suivante :
Get-WebApplicationProxySslCertificate
3. Si le certificat SSL est incorrect, définissez le certificat SSL correct en exécutant la commande
suivante :
Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
Vérifiez les liaisons de certificat et mettez-les à jour si nécessaire.

Pour prendre en charge les cas autres que SNI, les administrateurs peuvent spécifier des liaisons de
secours. Outre la liaison federationservicename:443 standard, recherchez les liaisons de secours sous les
ID d’application suivants :
{5d89a20c-beab-4389-9447-324788eb944a} : ID d’application pour AD FS.
{f955c070-e044-456c-ac00-e9e4275b3f04} : il s’agit de l’ID d’application pour le Proxy d'application
web.
Par exemple, si le certificat SSL est spécifié pour une liaison de secours comme 0.0.0.0:443, assurez-vous
que la liaison est mise à jour en conséquence lorsque le certificat SSL est mis à jour.
Tous les utilisateurs sont affectés par le problème, et l’utilisateur peut accéder à certaines des parties de confiance
Tout d’abord, obtenons les informations de la partie de confiance et du client OAuth. Si vous utilisez une partie
de confiance conventionnelle, procédez comme suit :
1. Sur le serveur AD FS principal, ouvrez Windows PowerShell avec l’option Exécuter en tant
qu’administrateur .
2. Ajoutez le composant AD FS 2.0 à Windows PowerShell en exécutant la commande suivante :
Add-PSSnapin Microsoft.Adfs.PowerShell
3. Obtenez les informations de la partie de confiance en exécutant la commande suivante :
$rp = Get-AdfsRelyingPartyTrust RPName
4. Obtenez les informations du client OAuth en exécutant la commande suivante :
$client = Get-AdfsClient ClientName
Si vous utilisez la fonctionnalité Groupe d’applications dans Windows Server 2016, suivez les étapes ci-dessous :
1. Sur le serveur AD FS principal, ouvrez Windows PowerShell avec l’option Exécuter en tant
qu’administrateur .
$rp = Get-AdfsWebApiApplication ResourceID
3. Si le client OAuth est public, obtenez les informations du client en exécutant la commande suivante :
$client = Get-AdfsNativeClientApplication ClientName
Si le client est confidentiel, obtenez les informations du client en exécutant la commande suivante :
$client = Get-AdfsServerApplication ClientName
Continuez maintenant avec les méthodes de dépannage suivantes.

Vé r i fi e r l e s p a r a m è t r e s d e l a p a r t i e d e c o n fi a n c e e t d u c l i e n t
L’identificateur de partie de confiance, l’ID client et l’URI de redirection doivent être fournis par le propriétaire de
l’application et le client. Toutefois, il peut toujours y avoir une incompatibilité entre ce que le propriétaire fournit
et ce qui est configuré dans AD FS. Par exemple, une incompatibilité peut être due à une faute de frappe. Vérifiez
si les paramètres fournis par le propriétaire correspondent à ceux configurés dans AD FS. Les étapes de la page
précédente vous permettent d’obtenir les paramètres configurés dans AD FS via PowerShell.
PA RA M ÈT RES F O URN IS PA R L E P RO P RIÉTA IRE PA RA M ÈT RES C O N F IGURÉS DA N S A D F S
ID de partie de confiance $rp. Identificateur
URI de redirection de partie de confiance Correspondance de préfixe ou de caractère générique de

$rp. WSFedEndpoint pour une partie de confiance
WS-Fed
$rp. SamlEndpoints pour une partie de confiance
SAML
ID du client $client. Clientid
URI de redirection du client Correspondance de préfixe de $client. RedirectUri
Si les éléments du tableau correspondent, vérifiez également si ces paramètres correspondent entre ce qu’ils
apparaissent dans la demande d’authentification envoyée à AD FS et ce qui est configuré dans AD FS. Essayez de
reproduire le problème pendant lequel vous capturez une trace Fiddler sur la demande d’authentification
envoyée par l’application à AD FS. Examinez les paramètres de requête pour effectuer les vérifications suivantes
en fonction du type de requête.
De ma n d e s O A u t h
Une requête OAuth se présente comme suit :

https://sts.contoso.com/adfs/oauth2/authorize?
response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com
Vérifiez si les paramètres de requête correspondent aux paramètres configurés dans AD FS.
PA RA M ÈT RES DE L A REQ UÊT E PA RA M ÈT RES C O N F IGURÉS DA N S A D F S
client_id $client. Clientid
redirect_uri Correspondance de préfixe de @client_RedirectUri
Le paramètre « resource » doit représenter une partie de confiance valide dans AD FS. Obtenez les informations
de partie de confiance en exécutant l’une des commandes suivantes.
Si vous utilisez une partie de confiance conventionnelle, exécutez la commande suivante :
Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
Si vous utilisez la fonctionnalité Groupe d’applications dans Windows Server 2016, exécutez la commande
suivante :
Get-AdfsWebApiApplication "ValueOfTheResourceParameter"
d e ma n d e s W S-F e d
Une demande WS-Fed ressemble à ce qui suit :

https://fs.contoso.com/adfs/ls/?
wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z
Vérifiez si les paramètres de requête correspondent aux paramètres configurés dans AD FS :
PA RA M ÈT RES DE L A REQ UÊT E PA RA M ÈT RES C O N F IGURÉS DA N S A D F S
wtrealm $rp. Identificateur
wreply Correspondance de préfixe ou de caractère générique de

$rp. WSFedEndpoint
De ma n d e s SA M L
Une requête SAML se présente comme suit :

https://sts.contoso.com/adfs/ls/?
SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-
sha1&Signature=Signature
Décodez la valeur du paramètre SAMLRequest à l’aide de l’option « From DeflatedSAML » dans l’Assistant Texte
Fiddler. La valeur décodée ressemble à ce qui suit :
<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z"

Destination="https://TestClaimProvider-Samlp-Only/adfs/ls"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" />
</samlp:AuthnRequest>
Effectuez les vérifications suivantes dans la valeur décodée :

Vérifiez si le nom d’hôte dans la valeur destination correspond au nom d’hôte AD FS.
Vérifiez si la valeur de l’émetteur correspond $rp.Identifier .
Remarques supplémentaires pour SAML :
$rp. SamlEndpoints : affiche tous les types de points de terminaison SAML. La réponse d’AD FS est envoyée
aux URL correspondantes configurées dans les points de terminaison. Un point de terminaison SAML peut
utiliser des liaisons de redirection, de publication ou d’artefact pour la transmission de messages. Toutes ces
URL peuvent être configurées dans AD FS.
$rp. SignedSamlRequestsRequired : si la valeur est définie, la requête SAML envoyée par la partie de
confiance doit être signée. Les paramètres « SigAlg » et « Signature » doivent être présents dans la requête.
$rp. RequestSigningCertificate : il s’agit du certificat de signature utilisé pour générer la signature sur la
requête SAML. Assurez-vous que le certificat est valide et demandez au propriétaire de l’application de faire
correspondre le certificat.
Vé r i fi e r l e c e r t i fi c a t d e c h i ffr e m e n t
Si $rp.EncryptClaims les retours sont activés , le chiffrement de partie de confiance est activé. AD FS utilise le
certificat de chiffrement pour chiffrer les revendications. Effectuez les vérifications suivantes :
$rp. EncryptionCertificate : utilisez cette commande pour obtenir le certificat et vérifier s’il est valide.
$rp. EncryptionCertificateRevocationCheck : utilisez cette commande pour vérifier si le certificat répond aux
exigences de vérification de révocation.
L e s d e u x m é t h o d e s p r é c é d e n t e s n e fo n c t i o n n e n t p a s
Pour poursuivre la résolution des problèmes, consultez Utiliser l’application De jeton de vidage.
Tous les utilisateurs ne sont pas affectés par le problème et l’utilisateur ne peut accéder à aucune des parties de confiance
Dans ce scénario, effectuez les vérifications suivantes.
Vé r i fi e r si l ’ u t i l i sa t e u r e st d é sa c t i v é
Vérifiez l’état de l’utilisateur dans Windows PowerShell ou l’interface utilisateur. Si l’utilisateur est désactivé,
activez-le.
V é ri f i e r l ’ é t a t d e l ’ u t i l i s a t e u r a v e c W i n d o w s P o w e r Sh e l l
1. Connectez-vous à l’un des contrôleurs de domaine.

2. Ouvrez Windows PowerShell.
3. Vérifiez l’état de l’utilisateur en exécutant la commande suivante :
Get-ADUser -Identity <samaccountname of the user> | Select Enabled
V é ri f i e r l ’ é t a t d e l ’ u t i l i s a t e u r d a n s l ’ i n t e rf a c e u t i l i s a t e u r
1. Connectez-vous à l’un des contrôleurs de domaine.

2. Ouvrez la console de gestion Utilisateurs et ordinateurs Active Director y .
3. Cliquez sur le nœud Utilisateurs , cliquez avec le bouton droit sur l’utilisateur dans le volet droit, puis
cliquez sur Propriétés .
4. Cliquez sur l’onglet Compte .
5. Sous Options de compte , vérifiez si le compte est désactivé .
6. Si l’option est cochée, décochez-la.

Vé r i fi e r si l e s p r o p r i é t é s d e l ’ u t i l i sa t e u r o n t é t é m i se s à j o u r r é c e m m e n t
Si une propriété de l’utilisateur est mise à jour dans Active Directory, cela entraîne une modification des
métadonnées de l’objet utilisateur. Vérifiez l’objet de métadonnées utilisateur pour voir quelles propriétés ont été
mises à jour récemment. Si des modifications sont trouvées, assurez-vous qu’elles sont récupérées par les
services associés. Pour vérifier si des modifications de propriété ont été apportées à un utilisateur, procédez
comme suit :
1. Connectez-vous à un contrôleur de domaine.
2. Ouvrez Windows PowerShell.
3. Obtenez les métadonnées de l’objet utilisateur en exécutant la commande suivante :
repadmin /showobjmeta <destination DC> "user DN"
Voici un exemple de la commande :

repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"
4. Dans les métadonnées, examinez la colonne Heure/Date de chaque attribut pour trouver un indice de
modification. Dans l’exemple suivant, l’attribut userPrincipleName prend une date plus récente que les
autres attributs, ce qui représente une modification des métadonnées de l’objet utilisateur.
Vé r i fi e r l ’ a p p r o b a t i o n d e fo r ê t si l ’ u t i l i sa t e u r a p p a r t i e n t à u n e a u t r e fo r ê t
Dans un environnement AD FS à forêts multiples, une approbation de forêt bidirectionnelle est requise entre la
forêt où AD FS est déployé et les autres forêts qui utilisent le déploiement AD FS pour l’authentification. Pour
vérifier si l’approbation entre les forêts fonctionne comme prévu, procédez comme suit :
1. Connectez-vous à un contrôleur de domaine dans la forêt où AD FS est déployé.
2. Ouvrez la console de gestion des domaines et approbations Active Director y .
3. Dans la console de gestion, cliquez avec le bouton droit sur le domaine qui contient l’approbation que
vous souhaitez vérifier, puis cliquez sur Propriétés .
4. Cliquez sur l’onglet Approbations .
5. Sous Domaines approuvés par ce domaine (approbations sor tantes) ou Domaines qui
approuvent ce domaine (approbations entrantes), cliquez sur l’approbation à vérifier, puis cliquez
sur Propriétés .
6. Cliquez sur Valider .
Dans la boîte de dialogue ser vices de domaine Active Director y , sélectionnez l’une des options.
Si vous sélectionnez Non , nous vous recommandons de répéter la même procédure pour le
domaine réciproque.
Si vous sélectionnez Oui , fournissez des informations d’identification d’utilisateur administratif
pour le domaine réciproque. Il n’est pas nécessaire d’effectuer la même procédure pour le domaine
réciproque.
Si ces étapes ne vous ont pas aidé à résoudre le problème, poursuivez la résolution des problèmes avec les
étapes de la section Non tous les utilisateurs ne sont pas affectés par le problème, et l’utilisateur peut accéder à
certaines parties de confiance .
Tous les utilisateurs ne sont pas affectés par le problème, et l’utilisateur peut accéder à certaines des parties de confiance
Dans ce scénario, vérifiez si ce problème se produit dans un scénario Azure AD. Si c’est le cas, effectuez ces
vérifications pour résoudre ce problème. Si ce n’est pas le cas, consultez Utiliser l’application De jeton de vidage
pour résoudre ce problème.
Vé r i fi e r si l ’ u t i l i sa t e u r e st sy n c h r o n i sé a v e c A z u r e A D
Si un utilisateur tente de se connecter à Azure AD, il est redirigé vers AD FS pour l’authentification d’un domaine
fédéré. L’une des raisons possibles d’un échec de connexion est que l’utilisateur n’est pas encore synchronisé
avec Azure AD. Vous pouvez voir une boucle d’Azure AD vers AD FS après la première tentative
d’authentification sur AD FS. Pour déterminer si l’utilisateur est synchronisé avec Azure AD, procédez comme
suit :
1. Téléchargez et installez le module Azure AD PowerShell pour Windows PowerShell.
2. Ouvrez Windows PowerShell avec l’option « Exécuter en tant qu’administrateur ».
3. Lancez une connexion à Azure AD en exécutant la commande suivante :
Connect-MsolService
4. Fournissez les informations d’identification de l’administrateur général pour la connexion.
5. Obtenez la liste des utilisateurs dans Azure AD en exécutant la commande suivante :
Get-MsolUser
6. Vérifiez si l’utilisateur figure dans la liste.
Si l’utilisateur ne figure pas dans la liste, synchronisez-le avec Azure AD.
Vé r i fi e r i m m u t a b l e I D e t U P N d a n s l a r è g l e d e r e v e n d i c a t i o n d ’ é m i ssi o n
Azure AD nécessite immutableID et l’UPN de l’utilisateur pour authentifier l’utilisateur.
NOTE
immutableID est également appelé sourceAnchor dans les outils suivants :
Azure AD Sync
Azure Active Directory Sync (DirSync)
Les administrateurs peuvent utiliser Azure AD Connect pour la gestion automatique de l’approbation AD FS avec
Azure AD. Si vous ne gérez pas l’approbation via Azure AD Connect, nous vous recommandons de le faire en
téléchargeant Azure AD Connect Azure AD Connect pour activer la gestion automatique des règles de
revendication en fonction des paramètres de synchronisation.
Pour vérifier si les règles de revendication pour immutableID et UPN dans AD FS correspondent à ce qu’Azure
AD utilise, procédez comme suit :
1. Obtenez sourceAnchor et UPN dans Azure AD Connect.
a. Ouvrez Azure AD Connect.
b. Cliquez sur Afficher la configuration actuelle .
c. Dans la page Vérifier votre solution , notez les valeurs source ANCHOR et USER PRINCIPAL
NAME .
2. Vérifiez les valeurs d’immutableID (sourceAnchor) et d’UPN dans la règle de revendication

correspondante configurée sur le serveur AD FS.
a. Sur le serveur AD FS, ouvrez la console de gestion AD FS.
b. Cliquez sur Approbations de par tie de confiance .
c. Cliquez avec le bouton droit sur l’approbation de partie de confiance avec Azure AD, puis cliquez
sur Modifier la stratégie d’émission de revendications .
d. Ouvrez la règle de revendication pour l’ID immuable et l’UPN.
e. Vérifiez si les variables interrogées pour les valeurs immutableID et UPN sont identiques à celles
qui apparaissent dans Azure AD Connect.
3. S’il existe une différence, utilisez l’une des méthodes ci-dessous :
Si AD FS est géré par Azure AD Connect, réinitialisez l’approbation de partie de confiance à l’aide
d’Azure AD Connect.
Si AD FS n’est pas géré par Azure AD Connect, corrigez les revendications avec les attributs
appropriés.
Si ces vérifications ne vous ont pas aidé à résoudre le problème, consultez Utiliser l’application De jeton de
vidage pour résoudre ce problème.
Ce problème se produit côté application
Si le certificat de signature de jeton a été renouvelé récemment par AD FS, vérifiez si le nouveau certificat est
récupéré par le partenaire de fédération. Si AD FS utilise un certificat de déchiffrement de jeton qui a également
été renouvelé récemment, effectuez également la même vérification. Pour vérifier si le certificat de signature de
jeton AD FS actuel sur AD FS correspond à celui du partenaire de fédération, procédez comme suit :
1. Obtenez le certificat de signature de jeton actuel sur AD FS en exécutant la commande suivante :
Get-ADFSCertificate -CertificateType token-signing
2. Dans la liste des certificats retournés, recherchez celui avec IsPrimar y = TRUE et notez l’empreinte
numérique.
3. Obtenez l’empreinte numérique du certificat de signature de jeton actuel sur le partenaire de fédération.
Le propriétaire de l’application doit vous le fournir.
4. Comparez les empreintes numériques des deux certificats.
Vérifiez également si AD FS utilise un certificat de déchiffrement de jeton renouvelé, sauf que la commande
permettant d’obtenir le certificat de déchiffrement de jeton sur AD FS est la suivante :
Get-ADFSCertificate -CertificateType token-decrypting

Les empreintes numériques des deux certificats correspondent
Si les empreintes correspondent, vérifiez que les partenaires utilisent les nouveaux certificats AD FS.
En cas d’incompatibilité de certificat, assurez-vous que les partenaires utilisent les nouveaux certificats. Les
certificats sont inclus dans les métadonnées de fédération publiées par le serveur AD FS.
NOTE
Les partenaires font référence à tous vos partenaires d’organisation de ressources ou d’organisation de comptes,
représentés dans votre AD FS par des approbations de partie de confiance et des approbations de fournisseur de
revendications.
Les partenaires peuvent accéder aux métadonnées de fédération

Si les partenaires peuvent accéder aux métadonnées de fédération, demandez aux partenaires d’utiliser
les nouveaux certificats.
Les partenaires ne peuvent pas accéder aux métadonnées de fédération
Dans ce cas, vous devez envoyer manuellement aux partenaires les clés publiques des nouveaux
certificats. Pour cela, procédez comme suit :
1. Exportez les clés publiques en tant que fichiers .cert ou en tant que fichiers .p7b pour inclure
l’ensemble des chaînes de certificats.
2. Envoyez les clés publiques aux partenaires.
3. Demandez aux partenaires d’utiliser les nouveaux certificats.
Les empreintes numériques des deux certificats ne correspondent pas
Ensuite, vérifiez s’il existe une incompatibilité d’algorithme de signature de jetons. Pour cela, procédez comme
suit :
1. Déterminez l’algorithme utilisé par la partie de confiance en exécutant la commande suivante :
Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
Les valeurs possibles sont SHA1 ou SHA256.

2. Vérifiez auprès du propriétaire de l’application l’algorithme utilisé côté application.
3. Vérifiez si les deux algorithmes correspondent.
Si les deux algorithmes correspondent, vérifiez si le format d’ID de nom correspond à ce dont l’application a
besoin.
1. Sur le serveur AD FS, videz les règles de transformation d’émission en exécutant la commande suivante :
(Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
2. Recherchez la règle qui émet la revendication NameIdentifier. Si une telle règle n’existe pas, ignorez cette
étape.
Voici un exemple de règle :
c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type =
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =
"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");
Notez le format NameIdentifier dans la syntaxe suivante :
Properties["Property-type-URI"] = "ValueURI"
Les formats possibles sont répertoriés ci-dessous. Le premier format est la valeur par défaut.
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
3. Demandez au propriétaire de l’application le format NameIdentifier requis par l’application.
4. Vérifiez si les deux formats NameIdentifier correspondent.
5. Si les formats ne correspondent pas, configurez la revendication NameIdentifier pour utiliser le format
requis par l’application. Pour cela, procédez comme suit :
a. Ouvrez la console de gestion AD FS.
b. Cliquez sur Approbations de par tie de confiance , sélectionnez le partenaire de fédération
approprié, puis cliquez sur Modifier la stratégie d’émission des revendications dans le volet
Actions .
c. Ajoutez une nouvelle règle s’il n’existe aucune règle pour émettre la revendication NameIdentifier ou
mettre à jour une règle existante. Sélectionnez l’ID de nom pour le type de revendication
entrante , puis spécifiez le format requis par l’application.
Si les deux algorithmes ne correspondent pas, mettez à jour l’algorithme de signature utilisé par l’approbation
de partie de confiance.
1. Ouvrez la console de gestion AD FS.
2. Cliquez avec le bouton droit sur l’approbation de partie de confiance, puis cliquez sur Propriétés .
3. Sous l’onglet Avancé , sélectionnez l’algorithme pour qu’il corresponde à ce dont l’application a besoin.
À propos du renouvellement automatique de certificat
Si le certificat de signature de jeton ou le certificat de déchiffrement de jeton sont auto-signés,
AutoCertificateRollover est activé par défaut sur ces certificats et AD FS gère le renouvellement automatique des
certificats lorsqu’ils sont proches de l’expiration.
Pour déterminer si vous utilisez des certificats auto-signés, procédez comme suit :
1. Exécutez la commande suivante :
Get-ADFSCerticate -CertificateType "token-signing"
2. Examinez les attributs de certificat.

Si les attributs Objet et Émetteur commencent tous les deux par « Signature CN=ADFS... », le certificat est
auto-signé et géré par AutoCertRollover.
Pour confirmer si les certificats sont renouvelés automatiquement, procédez comme suit :
Get-ADFSProperties | FL AutoCertificateRollover
2. Examinez l’attribut AutoCertificateRollover.

Si AutoCer tificateRollover = TRUE , AD FS génère automatiquement de nouveaux certificats (30
jours avant l’expiration par défaut) et les définit comme certificats principaux (25 jours avant
l’expiration).
Si AutoCer tificateRollover = FALSE , vous devez remplacer manuellement les certificats.
Vérifier les services et composants liés à ADFS

Cet article explique comment vérifier les services et composants liés à ADFS. Ces étapes peuvent vous aider à
résoudre les problèmes d’authentification unique (SSO) liés à Services ADFS (ADFS).
Vérifier DNS
L’accès à ADFS doit pointer directement vers l’un des serveurs WAP (Web Proxy d'application) ou l’équilibreur
de charge devant les serveurs WAP. Effectuez les vérifications suivantes :
Effectuez un test ping sur le nom du service de fédération (par exemple). fs.contoso.com Vérifiez si l’adresse
IP à laquelle ping se résout est de l’un des serveurs WAP ou de l’équilibreur de charge des serveurs WAP.
Vérifiez s’il existe un enregistrement A pour le service de fédération dans le serveur DNS. L’enregistrement A
doit pointer vers l’un des serveurs WAP ou vers l’équilibreur de charge des serveurs WAP.
Si WAP n’est pas implémenté dans votre scénario pour l’accès externe, vérifiez si l’accès à ADFS pointe
directement vers l’un des serveurs ADFS ou l’équilibreur de charge devant les serveurs ADFS :
Effectuez un test ping sur le nom du service de fédération (par exemple). fs.contoso.com Vérifiez si l’adresse
IP que vous obtenez est résolue vers l’un des serveurs ADFS ou l’équilibreur de charge des serveurs ADFS.
Vérifiez s’il existe un enregistrement A pour le service de fédération dans le serveur DNS. L’enregistrement A
doit pointer vers l’un des serveurs ADFS ou vers l’équilibreur de charge des serveurs ADFS.
Vérifier l’équilibreur de charge s’il est utilisé
Vérifiez si le pare-feu bloque le trafic entre :
Serveur ADFS et équilibreur de charge.
Serveur WAP (Web Proxy d'application) et équilibreur de charge si WAP est utilisé.
Si la sonde est activée sur l’équilibreur de charge, vérifiez ce qui suit :
Si vous exécutez Windows Server 2012 R2, vérifiez que le correctif cumulatif d’août 2014 est installé.
Vérifiez si le port 80 est activé dans le pare-feu sur les serveurs WAP et les serveurs ADFS.
Vérifiez que la sonde est définie pour le port 80 et pour le point de terminaison /adfs/probe.
Vérifier les paramètres du pare -feu
Vérifiez si le trafic entrant via le port TCP 443 est activé sur :
le pare-feu entre le serveur web Proxy d'application et la batterie de serveurs de fédération.
le pare-feu entre les clients et le serveur web Proxy d'application.
Vérifiez si le trafic entrant via le port TCP 49443 est activé sur le pare-feu entre les clients et le serveur web
Proxy d'application lorsque les conditions suivantes sont remplies :
L’authentification du client TLS à l’aide du certificat X.509 est activée.
Vous utilisez ADFS sur Windows Server 2012 R2.
NOTE
La configuration n’est pas requise sur le pare-feu entre le serveur web Proxy d'application et les serveurs de fédération.
Vérifier si le point de terminaison est activé sur le proxy

ADFS fournit différents points de terminaison pour différents scénarios et fonctionnalités. Tous les points de
terminaison ne sont pas activés par défaut. Pour vérifier si le point de terminaison est activé sur le proxy,
1. Sur le serveur ADFS, ouvrez la console de gestion ADFS.
2. Développez les points de terminaison de ser vice > .
3. Recherchez le point de terminaison et vérifiez si l’état est activé sur la colonne Proxy activé .
Vérifier la relation d’approbation de proxy
Si web Proxy d'application (WAP) est déployé, la relation d’approbation de proxy doit être établie entre le
serveur WAP et le serveur AD FS. Vérifiez si la relation d’approbation de proxy est établie ou commence à
échouer à un moment donné.
NOTE
Les informations de cette page s’appliquent à AD FS 2012 R2 et versions ultérieures.
Informations contextuelles
La relation d’approbation de proxy est basée sur un certificat client. Lorsque vous exécutez l’Assistant Web Proxy
d'application post-installation, l’Assistant génère un certificat client auto-signé à l’aide des informations
d’identification que vous avez spécifiées dans l’Assistant. Ensuite, l’Assistant insère le certificat dans la base de
données de configuration AD FS et l’ajoute au magasin de certificats AdfsTrustedDevices sur le serveur AD FS.
Pour toute communication SSL, http.sys utilise l’ordre de priorité suivant pour que les liaisons de certificat SSL
correspondent à un certificat :
P RIO RIT É NOM PA RA M ÈT RES DESC RIP T IO N
1 IP IP:port Correspondance exacte

entre l’adresse IP et le port
2 SNI Hostname:port Correspondance exacte du

nom d’hôte (la connexion
doit spécifier SNI)
3 CCS Port Appeler le magasin central

de certificats
4 Caractère générique IPv6 Port Correspondance avec

caractère générique IPv6 (la
connexion doit être IPv6)
5 Caractère générique IP Port Correspondance avec

caractère générique IP (la
connexion peut être IPv4
ou IPv6)
AD FS 2012 R2 et versions ultérieures sont indépendants d’Internet Information Services (IIS) et s’exécutent en
tant que service en plus de http.sys. les liaisons de certificat SSL hostname:port sont utilisées par AD FS. Lors de
l’authentification par certificat client, AD FS envoie une liste d’approbation de certificat (CTL) basée sur les
certificats dans le magasin AdfsTrustedDevices. Si une liaison de certificat SSL pour votre serveur AD FS utilise
IP:port ou si le magasin CTL n’est pas AdfsTrustedDevices, la relation d’approbation de proxy peut ne pas être
établie.
Obtenir les liaisons de certificat SSL pour AD FS
Sur le serveur AD FS, exécutez la commande suivante dans Windows PowerShell :
netsh http show sslcert
Dans la liste des liaisons retournées, recherchez celles avec l’ID d’application 5d89a20c-beab-4389-9447-
324788eb944a. Voici un exemple de liaison saine. Notez la ligne « Nom du magasin Ctl ».
Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Exécuter un script pour détecter automatiquement les problèmes

Pour détecter automatiquement les problèmes liés à la relation d’approbation de proxy, exécutez le script
suivant. En fonction du problème détecté, effectuez l’action en conséquence.
param
(
[switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
$ipport = $false
$hostnameport = $false
if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
## Check for IP specific certificate bindings
if ( ( $ipport -eq $true ) )
{
$httpsslcertoutput[$i]
$ipbindingparsed = $httpsslcertoutput[$i].split(":")
if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
{
$warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which
may conflict with the AD FS port 443 cert binding." | Write-Warning
$certbindingissuedetected = $true
}
$i = $i + 14
continue
}
## check that CTL Store is set for ADFS service binding
elseif ( $hostnameport -eq $true )
{
{
$httpsslcertoutput[$i]
$ipbindingparsed = $httpsslcertoutput[$i].split(":")
If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq
"443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
{
Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
$certbindingissuedetected = $true
}
$i = $i + 14
continue
}
$i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues
detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne
$_.Subject}
If ( $certlist.count -gt 0 )
{
Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store
and should be removed"
$certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
Param ([bool]$repair=$false)
Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust
config")
$doc = new-object Xml
$doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
$connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
$command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
$cli = new-object System.Data.SqlClient.SqlConnection
$cli.ConnectionString = $connString
$cmd = new-object System.Data.SqlClient.SqlCommand
$cmd.CommandText = $command
$cmd.Connection = $cli
$cli.Open()
$configString = $cmd.ExecuteScalar()
$configXml = new-object XML
$configXml.LoadXml($configString)
$rawCerts =
$configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstri
ngArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
#$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
$store = new-object
System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
$store.open("MaxAllowed")
$atLeastOneMismatch = $false
$badCerts = @()
foreach($rawCert in $rawCerts)
{
$rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
$now = Get-Date
if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
{
$certThumbprint = $cert.Thumbprint
$certSubject = $cert.Subject
$ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
if ($ctlMatch -eq $null)
{
{
$atLeastOneMismatch = $true
Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
if ($repair -eq $true)
{
write-Warning "Attempting to repair"
$store.Add($cert)
Write-Warning "Repair successful"
}
else
{
Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts
switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
}
}
}
}
$store.Close()
if ($atLeastOneMismatch -eq $false)
{
Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
}
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")
Problème 1 : Il existe une liaison spécifique à l’adresse IP

La liaison peut entrer en conflit avec la liaison de certificat AD FS sur le port 443.
La liaison IP:port a la priorité la plus élevée. Si une liaison IP:port se trouve dans les liaisons de certificat SSL AD
FS, http.sys utilise toujours le certificat pour la liaison pour la communication SSL. Pour résoudre ce problème,
utilisez les méthodes suivantes.
1. Supprimer la liaison IP:port
N’oubliez pas que la liaison IP:port peut revenir après l’avoir supprimée. Par exemple, une application
configurée avec cette liaison IP:port peut la recréer automatiquement lors du prochain démarrage du
service.
2. Utiliser une autre adresse IP pour la communication SSL AD FS
Si la liaison IP:port est requise, résolvez le nom de domaine complet du service ADFS en une autre
adresse IP qui n’est utilisée dans aucune liaison. De cette façon, http.sys utilisera la liaison Hostname:port
pour la communication SSL.
3. Définir AdfsTrustedDevices comme magasin CTL pour la liaison IP:port
Il s’agit du dernier recours si vous ne pouvez pas utiliser les méthodes ci-dessus. Toutefois, il est
préférable de comprendre les conditions suivantes avant de remplacer le magasin CTL par défaut par
AdfsTrustedDevices :
Pourquoi la liaison IP:port est-elle là?
Si la liaison s’appuie sur le magasin CTL par défaut pour l’authentification par certificat client.
Problème 2 : La liaison de certificat AD FS n’a pas le nom du magasin CTL défini sur AdfsTrustedDevices
Si Azure AD Connect est installé, utilisez AAD Connect pour définir le nom du magasin CTL sur
AdfsTrustedDevices pour les liaisons de certificat SSL sur tous les serveurs AD FS. Si Azure AD Connect n’est pas
installé, régénérez les liaisons de certificat AD FS en exécutant la commande suivante sur tous les serveurs AD
FS.
Set-AdfsSslCertificate -Thumbprint Thumbprint
Problème 3 : Un certificat qui n’est pas auto -signé existe dans le magasin de certificats AdfsTrustedDevices
Si un certificat émis par une autorité de certification se trouve dans un magasin de certificats où seuls les
certificats auto-signés existent normalement, la durée de vie générée à partir du magasin contiendra
uniquement le certificat émis par l’autorité de certification. Le magasin de certificats AdfsTrustedDevices est un
magasin qui est censé avoir uniquement des certificats auto-signés. Ces certificats sont les suivants :
MS-Organization-Access : certificat auto-signé utilisé pour émettre des certificats de jointure d’espace de
travail.
Approbation de proxy ADFS : certificats pour chaque serveur web Proxy d'application.
Par conséquent, supprimez tout certificat émis par l’autorité de certification du magasin de certificats
AdfsTrustedDevices.
Problème 4 : Installer KB2964735 ou réexécuter le script avec -syncproxytrustcerts
Lorsqu’une relation d’approbation de proxy est établie avec un serveur AD FS, le certificat client est écrit dans la
base de données de configuration AD FS et ajouté au magasin de certificats AdfsTrustedDevices sur le serveur
AD FS. Pour un déploiement de batterie de serveurs AD FS, le certificat client doit être synchronisé avec les
autres serveurs AD FS. Si la synchronisation ne se produit pas pour une raison quelconque, une relation
d’approbation de proxy fonctionne uniquement sur le serveur AD FS avec lequel l’approbation a été établie,
mais pas avec les autres serveurs AD FS.
Pour résoudre ce problème, utilisez l’une des méthodes suivantes.
Méthode 1
Installez la mise à jour documentée dans KB 2964735 sur tous les serveurs AD FS. Une fois la mise à jour
installée, une synchronisation du certificat client est supposée se produire automatiquement.
Méthode 2
Exécutez le script avec le commutateur – syncproxytrustcerts pour synchroniser manuellement les certificats
clients de la base de données de configuration AD FS vers le magasin de certificats AdfsTrustedDevices. Le script
doit être exécuté sur tous les serveurs AD FS de la batterie de serveurs.
NOTE
Il ne s’agit pas d’une solution permanente, car les certificats clients seront renouvelés régulièrement.
Problème 5 : Toutes les vérifications sont passées. Mais le problème persiste

Vérifiez s’il existe une incompatibilité d’heure ou de fuseau horaire. Si l’heure correspond mais que le fuseau
horaire ne le fait pas, la relation d’approbation de proxy ne sera pas établie.
Vérifier s’il existe un arrêt SSL entre le serveur AD FS et le serveur WAP
Si l’arrêt SSL se produit sur un appareil réseau entre les serveurs AD FS et le serveur WAP, la communication
entre AD FS et WAP s’arrête, car la communication est basée sur le certificat client.
Désactivez l’arrêt SSL sur l’appareil réseau entre les serveurs AD FS et WAP.
Utiliser l’application Dump Token

L’application Dump Token est utile lors du débogage des problèmes avec votre service de fédération et de la
validation des règles de revendication personnalisées. Il ne s’agit pas d’une solution officielle, mais d’une bonne
solution de débogage indépendante qui est recommandée à des fins de résolution des problèmes.
Avant d’utiliser l’application Dump Token
Avant d’utiliser l’application Dump Token, vous devez :
1. Obtenez les informations de la partie de confiance pour l’application à laquelle vous souhaitez accéder. Si
l’authentification OAuth est implémentée, obtenez également les informations du client OAuth.
2. Configurez l’application de jeton de vidage.
Obtenir les informations de la partie de confiance et du client OAuth
Si vous utilisez une partie de confiance conventionnelle, procédez comme suit :
1. Sur le serveur AD FS, ouvrez Windows PowerShell avec l’option Exécuter en tant qu’administrateur .
2. Ajoutez le composant AD FS 2.0 à Windows PowerShell en exécutant la commande suivante :
Add-PSSnapin Microsoft.Adfs.PowerShell
4. Obtenez les informations du client OAuth en exécutant la commande suivante :
$client = Get-AdfsClient ClientName
Si vous utilisez la fonctionnalité Groupe d’applications dans Windows Server 2016, suivez les étapes ci-dessous :
1. Sur le serveur AD FS, ouvrez Windows PowerShell avec l’option Exécuter en tant qu’administrateur .
$rp = Get-AdfsWebApiApplication ResourceID
3. Si le client OAuth est public, obtenez les informations du client en exécutant la commande suivante :
$client = Get-AdfsNativeClientApplication ClientName
Si le client OAuth est confidentiel, obtenez les informations du client en exécutant la commande suivante :
$client = Get-AdfsServerApplication ClientName
Configurer l’application De jeton de vidage

Pour configurer l’application Dump Token, exécutez les commandes suivantes dans la fenêtre Windows
PowerShell :
$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value =

`"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules
$authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint
Continuez maintenant avec les méthodes de dépannage suivantes. À la fin de chaque méthode, vérifiez si le
problème est résolu. Si ce n’est pas le cas, utilisez une autre méthode.
Méthodes de dépannage
Vérifier la stratégie d’autorisation pour voir si l’utilisateur est impacté
Dans cette méthode, vous commencez par obtenir les détails de la stratégie, puis utilisez l’application Dump
Token pour diagnostiquer la stratégie afin de voir si l’utilisateur est impacté.
O b t e n i r l e s d é t a i l s d e l a st r a t é g i e
$rp. IssuanceAuthorizationRules affiche les règles d’autorisation de la partie de confiance.

Dans Windows Server 2016 et versions ultérieures, vous pouvez utiliser $rp. AccessControlPolicyName pour
configurer la stratégie d’authentification et d’autorisation. Si $rp. AccessControlPolicyName a une valeur, une
stratégie de contrôle d’accès est en place qui régit la stratégie d’autorisation. Dans ce cas, $rp.
IssuanceAuthorizationRules est vide. Utilisez $rp. ResultantPolicy pour en savoir plus sur la stratégie de contrôle
d’accès.
Si $rp. ResultantPolicy n’a pas les détails sur la stratégie. Examinez les règles de revendication réelles. Pour
obtenir les règles de revendication, procédez comme suit :
1. Définissez la stratégie de contrôle d’accès sur $null en exécutant la commande suivante :
Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
3. Vérifier $rp.IssuanceAuthorizationRules et $rp. AdditionalAuthenticationRules .
U t i l i se r l ’ a p p l i c a t i o n D u m p To k e n p o u r d i a g n o st i q u e r l a st r a t é g i e d ’ a u t o r i sa t i o n
1. Définissez la stratégie d’authentification du jeton de vidage sur la même valeur que la partie de confiance
défaillante.
2. Faites ouvrir à l’utilisateur l’un des liens suivants en fonction de la stratégie d’authentification que vous
avez définie.
WS-Fed : https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
SAML-P : https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
Forcer l’authentification multifacteur :
https://FerderationInstance/adfs/ls?
wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
3. Connectez-vous à la page Sign-In.
Ce que vous obtenez est l’ensemble des revendications de l’utilisateur. Vérifiez si la stratégie d’autorisation
refuse ou autorise explicitement l’utilisateur en fonction de ces revendications.
Vérifier si une revendication manquante ou inattendue provoque un refus d’accès à la ressource
1. Configurez les règles de revendication dans l’application Dump Token pour qu’elles soient identiques aux
règles de revendication de la partie de confiance défaillante.
2. Configurez la stratégie d’authentification du jeton de vidage pour qu’elle soit identique à la partie de
confiance défaillante.
3. Faites ouvrir à l’utilisateur l’un des liens suivants en fonction de la stratégie d’authentification que vous
avez définie.
WS-Fed : https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
SAML-P : https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
Forcer l’authentification multifacteur :
https://FerderationInstance/adfs/ls?
wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
4. Connectez-vous à la page Sign-In.
Il s’agit de l’ensemble des revendications que la partie de confiance va obtenir pour l’utilisateur. Si des
revendications sont manquantes ou inattendues, examinez la stratégie d’émission pour en déterminer la raison.
Si toutes les revendications sont présentes, contactez le propriétaire de l’application pour voir quelle
revendication est manquante ou inattendue.
Vérifier si un état d’appareil est requis
Si les règles d’autorisation vérifient les revendications d’appareil, vérifiez si l’une de ces revendications
d’appareil est manquante dans la liste des revendications que vous obtenez de l’application Dump Token. Les
revendications manquantes peuvent bloquer l’authentification des appareils. Pour obtenir les revendications de
l’application De jeton de vidage, suivez les étapes de l’application Utiliser le jeton de vidage pour
diagnostiquer la section stratégie d’autorisation dans la stratégie d’autorisation Vérifier si la
méthode d’autorisation de l’utilisateur a été affectée .
Voici les revendications d’appareil. Les règles d’autorisation peuvent utiliser certaines d’entre elles.
http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
http://schemas.microsoft.com/2014/02/deviceusagetime
http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype
En cas de revendication manquante, suivez les étapes de configuration de l’accès conditionnel local à l’aide
d’appareils inscrits pour vous assurer que l’environnement est configuré pour l’authentification des appareils.
Si toutes les revendications sont présentes, vérifiez si les valeurs des revendications de l’application de jeton de
vidage correspondent aux valeurs requises dans la stratégie d’autorisation.
L’ID d’événement 180 est enregistré et les points de
terminaison AD FS sont manquants dans Windows
Server 2016
Cet article décrit un problème dans lequel les fonctionnalités des services AD FS (Active Directory Federation
Services) telles que l’authentification d’appareil et la découverte OAuth ne fonctionnent pas.
S’applique à : Windows Server 2012 R2, Windows Server 2016
Symptômes
Vous pouvez être l’un des symptômes suivants :
Les points de terminaison enregistrés par AD FS sont perdus par intermittence.
L’ID d’événement 180 est enregistré toutes les cinq minutes dans le journal des événements AD
FS/Admin, comme suit :
Log Name: AD FS/Admin

Source: AD FS
Event ID: 180
Task Category: None
Level: Error
Keywords: AD FS
Description: An error occurred while upgrading FarmBehaviorLevel 'Max' from Minor Version '0' to
Minor Version '3'.
Exception details: Object reference not set to an instance of an object.
L’exécution de l’cmdlet PowerShell révèle qu’aucune méthode d’authentification client n’est définie,
comme illustré sur la ligne inférieure de Get-AdfsGlobalAuthenticationPolicy la sortie suivante :
Get-AdfsGlobalAuthenticationPolicy
AdditionalAuthenticationProvider : {AzureMfaAuthentication}
DeviceAuthenticationEnabled : True
DeviceAuthenticationMethod : All
TreatDomainJoinedDevicesAsCompliant : False
PrimaryIntranetAuthenticationProvider : {FormsAuthentication, WindowsAuthentication,
AzurePrimaryAuthentication, MicrosoftPassportAuthentication}
PrimaryExtranetAuthenticationProvider : {FormsAuthentication, AzurePrimaryAuthentication,
MicrosoftPassportAuthentication}
WindowsIntegratedFallbackEnabled : True
ClientAuthenticationMethods : None
Ce problème se produit dans une batterie de serveurs AD FS à qui les conditions suivantes s’appliquent :
Un ou plusieurs serveurs AD FS (WS2016) Windows Server 2016 (WS2016) ont été ajoutés à une batterie de
serveurs AD FS Windows Server 2012 R2 (WS2012R2) sur une batterie de serveurs 4041685 de la base de
données (ou des version mensuelles ou d’aperçu ultérieures) installées.
La batterie de serveurs a été mise à niveau vers le niveau de comportement de la batterie WS2016.
La mise à jour de la 4088787 a été installée sur la batterie de serveurs AD FS WS2016.
Cause
L’installation de la mise à jour de la base de données 4088787 du 13 mars 2018 sur un nœud principal dans
une batterie de serveurs AD FS dont le FBL a été élevé de 1 (WS2012R2) à 3 (WS2016) peut provoquer une
régression AD FS et un réordification des lignes dans la base de données AD FS. Ce problème laisse la base de
données dans un état dans lequel certains éléments de données ont des occurrences en double. Cet état
provoque des échecs de démarrage du serveur AD FS et d’autres erreurs.
Résolution
Pour résoudre ce problème, suivez ces étapes.
Étape 1 : Vérifier le problème
Déterminez si le point de terminaison openid-configuration peut être atteint en exécutant la commande suivante
à l’invite de commandes PowerShell :
Get-AdfsEndpoint -AddressPath "/adfs/.well-known/openid-configuration"
Si le point de terminaison est in trouvé, le résultat suivant indique que le problème existe probablement :
Get-AdfsEndpoint : PS0137: No Endpoint found with Address '/adfs/.well-known/openid-configuration'.

At line:1 char:1
+ Get-AdfsEndpoint -AddressPath "/adfs/.well-known/openid-configuration ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Get-AdfsEndpoint], ArgumentException
+ FullyQualifiedErrorId : PS0137,Microsoft.IdentityServer.Management.Commands.GetEndpointCommand
Étape 2 : Enregistrez le script trouvé à la fin de cet article sous le nom « KB4088787_Fix.ps1 »
L’équipe AD FS a développé un script PowerShell que vous pouvez exécuter sur un serveur AD FS pour corriger
les paramètres de configuration AD FS dans la base de données associée à la base de données 4088787.
Ce script se trouve à la fin de cet article. Enregistrez le script sous le nom « KB4088787_Fix.ps1 » et copiez-le sur
le nœud principal de votre batterie AD FS.
Étape 3 : Back up AD FS configuration databas
Avant d’exécuter le script KB4088787_Fix.ps1, il est important que vous back up your AD FS configuration. Cette
configuration AD FS est stockée dans le Base de données interne Windows (WID) ou dans une base Microsoft
SQL Server données.
Si vous utilisez WID pour stocker la configuration AD FS, vous pouvez utiliser l’outil de restauration rapide ADFS
(disponible à partir du Centre de téléchargement Microsoft)pour stocker les données de configuration. Si vous
utilisez SQL Server pour stocker la base de données de configuration AD FS, vous devez créer une sauvegarde
SQL Server supplémentaire avant d’exécuter le script. L’état de la base de données peut être restauré à partir de
l’une de ces sauvegardes, si nécessaire.
Étape 4 : Exécuter le script KB4088787_Fix.ps1
Dans l’Explorateur de fichiers, cliquez avec le bouton droit sur le fichier KB4088787_Fix.ps1 que vous avez
enregistré dans le nœud principal de votre batterie AD FS, puis sélectionnez Exécuter avec PowerShell.
Le script vérifie d’abord que la base de données de serveur AD FS actuelle a été endommagée par le problème
de mise à niveau décrit. Si c’est le cas, le script localise les propriétés rompues et les corrige. Le script
KB4088787_Fix.ps1 vous demande de confirmer les modifications apportées à la base de données, puis
redémarre AD FS si nécessaire.
NOTE
Chaque fois que le script est exécuté, une copie du XML des paramètres de service est enregistrée. Les données sont
enregistrées dans le répertoire de travail au format de nom suivant :
serviceSettingsXml_<yyyy>-<MM>-<dd>-<hh>-<mm>-<ss>.xml
Par exemple, si le script est exécuté le 14 avril 2021 à 10:14:53, il est enregistré comme suit :
serviceSettingsXml_2021-04-14-10-14-53.xml
Une fois le script terminé et un redémarrage des AD FS, toutes les défaillances d’authentification et de point de
terminaison de l’appareil doivent être corrigées.
Si l’application du correctif de script et le redémarrage du système ne corrigent pas le problème, allez sur le site
web du support Microsoft.
Script PowerShell : KB4088787_Fix.ps1

#
# Version 2.0.0
#
# Helper function - serializes any DataContract object to an XML string

function Get-DataContractSerializedString()
{
[CmdletBinding()]
Param
(
[Parameter(Mandatory = $true, HelpMessage="Any object serializable with the DataContractSerializer")]
[ValidateNotNull()]
$object
)
$serializer = New-Object System.Runtime.Serialization.DataContractSerializer($object.GetType())

$serializedData = $null
try
{
# No simple write to string option, so we have to write to a memory stream
# then read back the bytes...
$stream = New-Object System.IO.MemoryStream
$writer = New-Object System.Xml.XmlTextWriter($stream,[System.Text.Encoding]::UTF8)
$null = $serializer.WriteObject($writer, $object);

$null = $writer.Flush();
# Read back the text we wrote to the memory stream

$reader = New-Object System.IO.StreamReader($stream,[System.Text.Encoding]::UTF8)
$null = $stream.Seek(0, [System.IO.SeekOrigin]::Begin)
$serializedData = $reader.ReadToEnd()
}
finally
{
if ($reader -ne $null)
{
try
{
$reader.Dispose()
}
catch [System.ObjectDisposedException] { }
}
}
if ($writer -ne $null)

{
try
{
$writer.Dispose()
}
}
if ($stream -ne $null)

{
try
{
$stream.Dispose()
}
}
}
return $serializedData
}
function Write-XmlIndent
{
param
(
$xmlData
)
$strWriter = New-Object System.IO.StringWriter

$xmlWriter = New-Object System.XMl.XmlTextWriter $strWriter
# Default = None, change Formatting to Indented

$xmlWriter.Formatting = "indented"
# Gets or sets how many IndentChars to write for each level in

# the hierarchy when Formatting is set to Formatting.Indented
$xmlWriter.Indentation = 1
$xmlData.WriteContentTo($xmlWriter)
$xmlWriter.Flush()
$strWriter.Flush()
$strWriter.ToString()
}
function Get-ADFSXMLServiceSettings
{
param
(
$saveData
)

$cli.Open()
try
{
$cmd.CommandText = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
$configString = $cmd.ExecuteScalar()
$configXml = new-object XML
$configXml.LoadXml($configString)
if($saveData)
{
$script:originalPath = "original_serviceSettingsXml_$(get-date -f yyyy-MM-dd-hh-mm-ss).xml"
Write-XmlIndent($configXml) | Out-File $script:originalPath
Write-Host "Original XML saved to: $script:originalPath"
}
write-output $configXml
}
finally
{
$cli.CLose()
}
}
# Gets internal ADFS settings by extracting them Get-AdfsProperties

function Get-AdfsInternalSettings()
{
$settings = Get-AdfsProperties
$settingsType = $settings.GetType()
$propInfo = $settingsType.GetProperty("ServiceSettingsData", [System.Reflection.BindingFlags]::Instance -
bor [System.Reflection.BindingFlags]::NonPublic)
$internalSettings = $propInfo.GetValue($settings, $null)
return $internalSettings
}
function Set-AdfsInternalSettings()
{
[CmdletBinding()]
Param
(
[Parameter(Mandatory = $true, HelpMessage="Settings object fetched from Get-AdfsInternalSettings")]
[ValidateNotNull()]
$InternalSettings
)
$settingsData = Get-DataContractSerializedString -object $InternalSettings

$cli.Open()
try
{
$cmd.CommandText = "update [IdentityServerPolicy].[ServiceSettings] SET ServiceSettingsData=@content,
[ServiceSettingsVersion] = [ServiceSettingsVersion] + 1,[LastUpdateTime] = GETDATE()"
$cmd.Parameters.AddWithValue("@content", $settingsData) | out-null
$rowsAffected = $cmd.ExecuteNonQuery()
# Update service state table for WID sync if required

if ($connString -match "##wid")
{
$cmd.CommandText = "UPDATE [IdentityServerPolicy].[ServiceStateSummary] SET [SerialNumber] = [SerialNumber]
+ 1,[LastUpdateTime] = GETDATE() WHERE ServiceObjectType='ServiceSettings'"
$widRowsAffected = $cmd.ExecuteNonQuery()
}
}
finally
{
$cli.CLose()
}
}
function Create-EndpointConfiguration()
{
Param
(
[ValidateNotNull()]
$xmlData
)
# EndpointConfiguration
$enabled = Create-BoolFromString($xmlData.Enabled)
$proxy = Create-BoolFromString($xmlData.Proxy)
$canProxy = Create-BoolFromString($xmlData.CanProxy)
$endpointConfig = New-Object -TypeName

Microsoft.IdentityServer.PolicyModel.Configuration.EndpointConfiguration -ArgumentList $xmlData.Address,
$enabled , ([Microsoft.IdentityServer.PolicyModel.Configuration.EndpointMode] $xmlData.ModeValue), $proxy,
$xmlData.Version, $canProxy
return $endpointConfig
}
function Create-ClientSecretSettings()
{
Param
(
[ValidateNotNull()]
$xmlData
)
# ClientSecretSettings
$clientSecretSettings = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Client.ClientSecretSettings
$clientSecretSettings.ClientSecretRolloverTimeMinutes = $xmlData.ClientSecretRolloverTimeMinutes
$clientSecretSettings.ClientSecretLockoutThreshold = $xmlData.ClientSecretLockoutThreshold;
$clientSecretSettings.SaltedHashAlgorithm = $xmlData.SaltedHashAlgorithm
$clientSecretSettings.SaltSize = $xmlData.SaltSize
$clientSecretSettings.SecretSize = $xmlData.SecretSize
return $clientSecretSettings
}
function Create-IdTokenIssuer()
{
Param
(
[ValidateNotNull()]
$xmlData
)
#IdTokenIssuer
$idTokenIssuerConfig = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Configuration.IdTokenIssuerConfiguration
$idTokenIssuerConfig.Address = $xmlData.Address
return $idTokenIssuerConfig
}
function Create-CertificateAuthorityConfiguration()
{
Param
(
[ValidateNotNull()]
$xmlData
)
# CertificateAuthorityConfiguration
$certAuthorityConfig = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Configuration.CertificateAuthorityConfiguration
$certAuthorityConfig.Mode.Value =
[Microsoft.IdentityServer.PolicyModel.Configuration.CertificateAuthorityMode] $xmlData.ModeValue
$certAuthorityConfig.GenerationThresholdInMinutes = $xmlData.GenerationThresholdInMinutes
$certAuthorityConfig.PromotionThresholdInMinutes = $xmlData.PromotionThresholdInMinutes
$certAuthorityConfig.CertificateLifetimeInMinutes = $xmlData.CertificateLifetimeInMinutes
$certAuthorityConfig.RolloverIntervalInMinutes = $xmlData.RolloverIntervalInMinutes
$certAuthorityConfig.CriticalThresholdInMinutes = $xmlData.CriticalThresholdInMinutes
# Create Cert reference

if ($xmlData.PrimaryIssuerCertificate.IsEmpty -ne $true)
{
$certReference = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Configuration.CertificateReference
$certReference.IsChainIncluded = Create-BoolFromString($xmlData.PrimaryIssuerCertificate.IsChainIncluded)
$certReference.IsChainIncludedSpecified = Create-
BoolFromString($xmlData.PrimaryIssuerCertificate.IsChainIncludedSpecified)
$certReference.FindValue = $xmlData.PrimaryIssuerCertificate.FindValue
$certReference.RawCertificate = $xmlData.PrimaryIssuerCertificate.RawCertificate
$certReference.EncryptedPfx = $xmlData.PrimaryIssuerCertificate.EncryptedPfx
$certReference.StoreName.Value = [System.Security.Cryptography.X509Certificates.StoreName]
$xmlData.PrimaryIssuerCertificate.StoreNameValue
$certReference.StoreLocation.Value = [System.Security.Cryptography.X509Certificates.StoreLocation]
$xmlData.PrimaryIssuerCertificate.StoreLocationValue
$certReference.X509FindType.Value = [System.Security.Cryptography.X509Certificates.X509FindType]
$xmlData.PrimaryIssuerCertificate.X509FindTypeValue
$certAuthorityConfig.PrimaryIssuerCertificate = $certReference
}
if ($xmlData.QueuedIssuerCertificate.IsEmpty -ne $true){

# Create PromotionCert
$promotionCert = New-Object -TypeName
Microsoft.IdentityServer.PolicyModel.Configuration.PromotionCertificate
$promotionCert.ObjectId = $xmlData.QueuedIssuerCertificate.ObjectId
$certAuthorityConfig.QueuedIssuerCertificate = $promotionCert
}
$certAuthorityConfig.CriticalThresholdInMinutes = $xmlData.CriticalThresholdInMinutes
if ($xmlData.CertificateAuthority.IsEmpty -ne $true){

$certAuthorityConfig.CertificateAuthority = $xmlData.CertificateAuthority
}
if ($xmlData.EnrollmentAgentCertificateTemplateName.IsEmpty -ne $true)

{
$certAuthorityConfig.EnrollmentAgentCertificateTemplateName =
$xmlData.EnrollmentAgentCertificateTemplateName
}
if ($xmlData.LogonCertificateTemplateName.IsEmpty -ne $true)

{
$certAuthorityConfig.LogonCertificateTemplateName = $xmlData.LogonCertificateTemplateName
}
if ($xmlData.VPNCertificateTemplateName.IsEmpty -ne $true)

{
$certAuthorityConfig.VPNCertificateTemplateName = $xmlData.VPNCertificateTemplateName
}
if ($xmlData.WindowsHelloCertificateTemplateName.IsEmpty -ne $true)

{
$certAuthorityConfig.WindowsHelloCertificateTemplateName = $xmlData.WindowsHelloCertificateTemplateName
}
$certAuthorityConfig.AutoEnrollEnabled = Create-BoolFromString($xmlData.AutoEnrollEnabled)
$certAuthorityConfig.WindowsHelloCertificateProxyEnabled = Create-
BoolFromString($xmlData.WindowsHelloCertificateProxyEnabled)
return $certAuthorityConfig
}
}
function Create-OAuthClientAuthenticationMethods()
{
Param
(
[ValidateNotNull()]
$xmlData
)
# OAuthClientAuthenticationMethods
return 15
}
function Create-BoolFromString()
{
Param
(
[ValidateNotNull()]
$xmlData
)
if ($xmlData -eq $null -or $xmlData.ToLower() -eq "false")

{
return 0
}else{
return 1
}
}
function Get-ObjectFromElement()
{
Param
(
[ValidateNotNull()]
$xmlData,
[ValidateNotNull()]
$elementName
)
$endpointConfigs = "DeviceRegistrationEndpoint", "OAuthJwksEndpoint", "OAuthDiscoveryEndpoint",

"WebFingerEndpoint", "CertificateAuthorityCrlEndpoint", "UserInfoEndpoint"
# Microsoft.IdentityServer.PolicyModel.Configuration.EndpointConfiguration
$clientSecretSettings = "ClientSecretSettings"
# Microsoft.IdentityServer.PolicyModel.Client.ClientSecretSettings
$oauthClientAuthMethod = "OAuthClientAuthenticationMethods"
# Microsoft.IdentityServer.PolicyModel.Configuration.ClientAuthenticationMethod
$certAuthorityConfig = "CertificateAuthorityConfiguration"
# Microsoft.IdentityServer.PolicyModel.Configuration.CertificateAuthorityConfiguration
$idTokenIssuer = "IdTokenIssuer"
# Microsoft.IdentityServer.PolicyModel.Configuration.IdTokenIssuerConfiguration
$boolObjs = "EnableIdPInitiatedSignonPage", "IgnoreTokenBinding", "EnableOauthLogout"
$basicObjs = "DeviceUsageWindowInSeconds", "MaxLdapUserNameLength", "FarmBehaviorMinorVersion",

"PromptLoginFederation", "PromptLoginFallbackAuthenticationType"
if ($endpointConfigs.Contains($elementName))
{
return Create-EndpointConfiguration($xmlData)
}elseif ($clientSecretSettings.Contains($elementName))
{
return Create-ClientSecretSettings($xmlData)
return Create-ClientSecretSettings($xmlData)
}elseif ($oauthClientAuthMethod.Contains($elementName))
{
return Create-OAuthClientAuthenticationMethods($xmlData)
}elseif ($certAuthorityConfig.Contains($elementName))
{
return Create-CertificateAuthorityConfiguration($xmlData)
}elseif ($idTokenIssuer.Contains($elementName))
{
return Create-IdTokenIssuer($xmlData)
}elseif ($boolObjs.Contains($elementName))
{
return Create-BoolFromString($xmlData)
}else{
return $xmlData
}
}
$role = (Get-AdfsSyncProperties).Role
if($role -ne "PrimaryComputer")
{
Write-Host "This script must execute on the primary node in the AD FS farm. Cannot continue."
exit
}
Add-Type -Path ('C:\\Windows\\ADFS\\Microsoft.IdentityServer.dll')

$script:originalPath = $null
# Get the XML of the Service Settings blob, and look for duplicate elements
$xmlData = Get-ADFSXMLServiceSettings($true)
$dataObj = Get-AdfsInternalSettings
if($dataObj.SecurityTokenService.DeviceRegistrationEndpoint.Length -ne 1)
{
if(($xmlData.ServiceSettingsData.SecurityTokenService | Select-Object
"DeviceRegistrationEndpoint").DeviceRegistrationEndpoint.IsEmpty[0] -ne $True)
{
# In this case, the service settings object is showing an issue, but the XML data is not.
# This is possible in the case that the sequence of KB applications has occurred, but no Service Settings
write oparation
# has occured.
# To handle this, we will prompt the user to allow us to throttle a Service Setting to force a write
operation
# Do a no-op service settings action so that the duplicates are populated in the database (if issue exists)
$message = "Confirmation required"
$question = "To ensure data detection is possible, we need to perform an AD FS Properties operation. `nIf
you continue, this script will add 1 minute to the value of 'ProxyTrustTokenLifetime', and then the value of
'ProxyTrustTokenLifetime' will be returned to its original setting. `nIf you wish to make a Set-
AdfsProperties operation yourself, answer 'No', and perform the operation yourself. `n`nAre you sure you
want to proceed?"
$choices = New-Object Collections.ObjectModel.Collection[Management.Automation.Host.ChoiceDescription]

$choices.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&Yes'))
$choices.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&No'))
$decision = $Host.UI.PromptForChoice($message, $question, $choices, 1)
if ($decision -eq 0) {
$prop = Get-AdfsProperties
$original = $prop.ProxyTrustTokenLifetime
Set-AdfsProperties -ProxyTrustTokenLifetime ($original + 1)
Set-AdfsProperties -ProxyTrustTokenLifetime $original
# Refresh the XML and data obj

$xmlData = Get-ADFSXMLServiceSettings($false)
$dataObj = Get-AdfsInternalSettings
}else{
Write-Host "We did not perform a service settings operation. Please make some service settings change by
performing a Set-AdfsProperties command, and try the script again."
performing a Set-AdfsProperties command, and try the script again."
}
}
}
if(($xmlData.ServiceSettingsData.SecurityTokenService | Select-Object
"DeviceRegistrationEndpoint").DeviceRegistrationEndpoint.IsEmpty[0] -eq $True)
{
$possibleDuplicateElements = "DeviceRegistrationEndpoint", "DeviceUsageWindowInSeconds",
"OAuthClientAuthenticationMethods", "MaxLdapUserNameLength", "EnableIdPInitiatedSignonPage",
"ClientSecretSettings", "OAuthDiscoveryEndpoint", "OAuthJwksEndpoint", "IdTokenIssuer",
"CertificateAuthorityConfiguration", "WebFingerEndpoint", "CertificateAuthorityCrlEndpoint",
"UserInfoEndpoint", "IgnoreTokenBinding", "FarmBehaviorMinorVersion", "EnableOauthLogout",
"PromptLoginFederation", "PromptLoginFallbackAuthenticationType"
$existingDups = @()
foreach( $dup in $possibleDuplicateElements )
{
$object = $xmlData.ServiceSettingsData.SecurityTokenService | Select-Object $dup
if( $object.$dup.Count -gt 1 )

{
# We have an element with duplicate values
# Take the last one in the list
$newObj = $object.$dup[$object.$dup.Count - 1]
$savableObj = Get-ObjectFromElement -xmlData $newObj -elementName $dup
$existingDups += $dup
$dataObj.SecurityTokenService.$dup = $savableObj
}
}
# Write the modified Service Settings data object back to the database
if($existingDups.Count -gt 0)
{
$filename = "modified_serviceSettingsXml_$(get-date -f yyyy-MM-dd-hh-mm-ss).xml"
$modifiedData = Get-DataContractSerializedString -object $dataObj
Write-XmlIndent([xml]$modifiedData) | Out-File $filename
Write-Host "Modifed XML saved to: $filename"

$question = "We have located duplicate data in Service Settings, and need to make a modification to the
configuration database. `nIf you continue, the values of some elements will be updated in your database.
`nIf you wish to see the difference, you can compare the following two files from the working directory:
`n`n$script:originalPath `n$filename `n`nAre you sure you want to proceed?"

$decision = $Host.UI.PromptForChoice($message, $question, $choices, 1)

if ($decision -eq 0) {
Write-Host "Performing update to Service Settings"
Set-AdfsInternalSettings -InternalSettings $dataObj
Write-Host "Updated Service Settings`n`n"
Write-Host "The following elements in the service settings data were modified:`n"
foreach($d in $existingDups)
{
Write-Host $d
}
Write-Host "`nAll nodes in this farm should be restarted. This script will attempt to restart the current
node, but no other nodes."
Write-Host "Please manually restart all nodes in your AD FS farm.`n`n"

$question = "An AD FS Service restart is required. Proceed with restart?"
$question = "An AD FS Service restart is required. Proceed with restart?"

$decision2 = $Host.UI.PromptForChoice($message, $question, $choices, 1)
if($decision2 -eq 0){

Write-Host "Stopping AD FS"
net stop adfssrv
Write-Host "Starting AD FS"

net start adfssrv
}else{
Write-Host "You chose not to restart AD FS. Please manually restart AD FS to allow the changes to take
effect."
}
} else {
Write-Host "Cancelling"
}
}else{
Write-Host "No Operations Needed"
}
}else
{
Write-Host "No issues detected. Terminating script."
}
Erreur de certificat ADFS 2.0 : une erreur s’est
produite lors d’une tentative de construction de la
chaîne de certificats
Cet article permet de corriger l’erreur de certificat ADFS 2.0 lors d’une tentative de construction de la chaîne de
certificats.
Résumé
La plupart des problèmes liés aux services fédérés Active Directory (AD FS) 2.0 appartiennent à l’une des
principales catégories suivantes. Cet article contient des instructions pas à pas pour résoudre les problèmes de
certificat.
Problèmes de connectivité (KB 3044971)
Problèmes de service ADFS (KB 3044973)
Problèmes de certificat (KB 3044974)
Problèmes d’authentification (KB 3044976)
Problèmes liés aux règles de revendication (KB 3044977)
Symptômes
Ce problème démarre après la changement ou le remplacement d’un certificat AD FS.
Le programme cesse d’accepter le jeton émis par AD FS.
AD FS renvoie l’une des erreurs suivantes lorsqu’il reçoit une demande ou une réponse signée, ou s’il
tente de chiffrer un jeton à émettre à une application de partie de confiance :
Une erreur s’est produite lors d’une tentative de construction de la chaîne de certificats pour le
certificat de signature d’autorisation de partie de confiance.
certificat de signature de confiance du fournisseur de revendications.
certificat de chiffrement d’une confiance de partie de confiance.
Les ID d’événement liés aux certificats suivants sont consignés dans le journal des événements AD FS :
Description : lors du traitement de la configuration du service de fédération, l’élément «
serviceIdentityToken » a été trouvé pour avoir des données non valides. Impossible d’accéder à la clé
privée du certificat configuré. Les valeurs de certificate:Element: serviceIdentityToken sont les
suivantes :
AD FS 2.0 a détecté qu’un ou plusieurs certificats de la base de données de configuration AD FS 2.0
ont besoin d’être mis à jour manuellement.
certificat de configuration.
Une erreur s’est produite lors de l’activation des points de terminaison du service de fédération.
Données supplémentaires
Détails de l’exception :
System.ArgumentNullException : la valeur ne peut pas être null.
Nom du paramètre : certificat
AD FS 2.0 a détecté qu’un ou plusieurs des certificats spécifiés dans le service de fédération n’étaient
pas accessibles au compte de service utilisé par le service Windows AD FS 2.0.
Action de l’utilisateur : assurez-vous que le compte de service AD FS dispose des autorisations de
lecture sur les clés privées du certificat.
Détails supplémentaires :
Certificat de signature de jetons avec empreinte numérique « xxxxxxxx »
Résolution
Pour résoudre ce problème, suivez ces étapes dans l’ordre donné. Ces étapes vous aideront à déterminer la
cause du problème. Veillez à vérifier si le problème est résolu après chaque étape.
Étape 1 : Vérifier les clés privées
Vérifiez si tous les certificats AD FS (communications de service, déchiffrement du jeton et signature de jetons)
sont valides et qu’une clé privée leur est associée. Assurez-vous également que le certificat est dans sa période
de validité.
Où trouver les certificats

Pour les certificats de communications de service :
1. Sur le serveur AD FS, cliquez sur Démarrer, cliquez sur Exécuter, tapez MMC.exe, puis appuyez sur
Entrée.
2. Dans la boîte de dialogue Ajouter/Supprimer un logiciel en snap-in, cliquez sur OK.
3. Dans l’écran du logiciel en ligne Certificats, cliquez sur le magasin de certificats du compte
d’ordinateur.
4. Pour afficher les propriétés du certificat de communications de service, développez Cer tificat
(ordinateur local), développez Personnel, puis cliquez sur Cer tificats .
Pour les certificats de signature et de déchiffrement de jetons :
Si les certificats sont des certificats auto-signés ajoutés par défaut par le serveur ADFS, logonez-vous
de manière interactive sur le serveur ADFS à l’aide du compte de service ADFS et vérifiez le magasin
de certificats de l’utilisateur (certmgr.msc).
Si le certificat est issu d’une autorité de certification (CA), configurée par les administrateurs ADFS
après la désactivation de l’autoCertificateRollover, vous devriez être en mesure de le trouver sous le
magasin de certificats du serveur ADFS.
Étape 2 : Assurez-vous que les certificats n’utilisent pas de clé privée Cryptographic Next Generation (CNG )
Les certificats qui utilisent la clé privée CNG ne sont pas pris en charge pour la signature de jetons et le
déchiffrement du jeton. Si AD FS a généré le certificat auto-signé, ce certificat n’utilise pas CNG. Pour un
certificat émis par une ca, assurez-vous que le certificat n’est pas basé sur CNG. Pour ce faire, suivez les étapes
suivantes : si le modèle d’ac utilise l’un des fournisseurs de services de chiffrement répertoriés, le certificat émis
par cette cae n’est pas pris en charge par le serveur AD FS.
Pour plus d’informations, voir Comment déterminer si un certificat utilise une clé CAPI1 ou CNG.
Étape 3 : Vérifier si la liaison SSL des certificats de communication de service dans IIS est liée au port 443
Comment vérifier et corriger
1. Démarrez le Gestionnaire des iis. Pour ce faire, cliquez sur Démarrer, sur Outils d’administration, puis
sur Internet Information Services (IIS).
2. Cliquez sur le nom du serveur, puis développez le dossier Sites.
3. Recherchez votre site web (généralement, il est appelé « Site Web par défaut ») et sélectionnez-le.
4. Dans le menu Actions sur le côté droit, cliquez sur Liaisons. Assurez-vous que le type d’appel d’offres
https est lié au port 443. Dans le cas contraire, cliquez sur Modifier pour modifier le port.
Étape 4 : vérifiez que le certificat de communication de service est valide, approuvé et qu’il passe un contrôle
de révocation
Voici comment vérifier
1. Ouvrez AD FS 2.0 Management.
2. Développez le ser vice, cliquez sur Cer tificat, cliquez avec le bouton droit sur le certificat de
communications de service, puis cliquez sur Afficher le cer tificat.
3. Dans le volet d’informations, cliquez sur Copier dans le fichier et enregistrez le fichier sous le nom
filename.cer.
4. À l’invite de commandes, exécutez la commande suivante pour déterminer si le certificat de
communication de service est valide :
Run 'Certutil -verify -urlfetch certificate.CER > cert_cerification.txt'
5. Ouvrez le fichier de sortie créé au-dessus de « cert_verification.txt ».

6. Go to the end of the file, and check whether it includes the following for a successful revocation test:
Vérification de révocation de certificat feuilles

CertUtil: -verify command completed successfully.
7. Si le fichier indique que les vérifications de révocation ont échoué ou que le serveur de révocation était
hors connexion, vérifiez le journal pour déterminer quel certificat de la chaîne de certificats n’a pas pu
être vérifié.
Vérifiez si un chemin AIA ou CDP a échoué. Dans un scénario dans lequel plusieurs chemins d’accès sont
spécifiés sous un seul type de fichier, les deux chemins doivent être marqués comme vérifiés.
---------------- certificat AIA ----------------

Durée vérifiée « Certificat (0) » : 0
[0.0] http://www.contoso.com/pki/mswww(6).crt
Failed « AIA » Time: 0
Erreur lors de la récupération de l’URL : le nom ou l’adresse du serveur n’a pas pu être résolu
0x80072ee7 (WIN32 : 12007)
http://corppki/aia/mswww(6).crt
---------------- certificat CDP ----------------

Durée vérifiée « CRL de base (5a) » : 0
[0.0] http://mscrl.contoso.com/pki/crl/mswww(6).crl
Durée vérifiée « CRL de base (5a) » : 0
[1.0] http://crl.contoso.com/pki/crl/mswww(6).crl
Failed « CDP » Time: 0
Erreur lors de la récupération de l’URL : le nom ou l’adresse du serveur n’a pas pu être résolu
0x80072ee7 (WIN32 : 12007)
http://corppki/crl/mswww(6).crl
La collecte d’un suivi réseau peut être utile si l’un des chemins d’accès AIA, CDP ou OCSP n’est pas
disponible.
8. Si l’entrée du journal indique que le certificat est révoqué, vous devez demander un autre certificat valide
et non révoqué.
Étape 5 : Assurez-vous que les comptes de service ADFS disposent de l’autorisation lecture pour la clé privée
des certificats ADFS
Vérifier l’autorisation de lecture
1. Sur le serveur AD FS, cliquez sur Démarrer, cliquez sur Exécuter, entrez MMC.exe, puis appuyez sur
Entrée.
2. Dans la boîte de dialogue Ajouter/Supprimer un logiciel en snap-in, cliquez sur OK.
3. Dans la fenêtre Racine de la console, cliquez sur Cer tificats (ordinateur local) pour afficher les
magasins de certificats de l’ordinateur.
4. Cliquez avec le bouton droit sur le service AD FS, pointez sur Toutes les tâches, puis cliquez sur Gérer
les clés privées.
5. Vérifiez si le compte AD FS dispose de l’autorisation Lecture.
Étape 6 : Vérifier si la fonctionnalité AutoCertificateRollover ADFS est activée pour les certificats de signature
et de déchiffrement de jetons
Comment vérifier la fonctionnalité AutoCertificateRollover ADFS
Si AutoCertificateRollover est désactivé, les certificats de signature et de déchiffrement de jeton ne seront pas
renouvelés automatiquement. Avant l’expiration de ces certificats, assurez-vous qu’un nouveau certificat est
ajouté à la configuration AD FS. Dans le cas contraire, la partie de confiance n’aura pas confiance dans le
jeton émis par le serveur AD FS.
Si AutoCertificateRollover est activé, les nouveaux certificats de signature et de déchiffrement de jetons sont
générés 20 jours avant l’expiration des anciens certificats. Les nouveaux certificats obtiennent l’état Principal
cinq jours après leur génération. Une fois le nouvel ensemble de certificats généré, assurez-vous que les
mêmes informations sont mises à jour sur les confiances de la partie de confiance et du fournisseur de
revendications.
Pour plus d’informations sur la fonctionnalité AutoCertificateRollover AD FS, consultez les rubriques TechNet
suivantes :
AD FS 2.0 : Understanding AutoCertificateRollover Threshold Properties
AD FS 2.0 : Comment activer et utiliser immédiatement AutoCertificateRollover
AD FS 2.0 : Comment remplacer le SSL, les communications de service, la signature de jetons et Token-
Decrypting certificats
Étape 7 : Ajouter le nom du service de fédération dans le SAN du certificat
Si l’attribut SAN (Subject Alternative Name) est activé pour le certificat, le nom du service de fédération doit
également être ajouté dans le SAN du certificat, ainsi que d’autres noms. Pour plus d’informations, voir SSL
Certificate Requirements.
Étape 8 : Vérifier les autorisations du compte de service pour le conteneur de partage de certificat (CN=
<GUID> ,CN=ADFS,CN=Microsoft,CN=Program Data,DC= <Domain> ,DC= <COM> )
Comment vérifier et corriger l’autorisation du compte de service
1. Sur un contrôleur de domaine ( DC), ouvrez Adsiedit.msc.
2. Connecter au contexte d’attribution de noms par défaut.
3. Locate CN= <GUID> ,CN=ADFS,CN=Microsoft,CN=Program Data,DC= <Domain> ,DC=
<COM> .
NOTE
Dans ce nom de conteneur, les paramètres entre crochets représentent les valeurs réelles. Un exemple de GUID
est « 62b8a5cb-5d16-4b13-b616-06caea706ada ».
4. Cliquez avec le bouton droit sur le GUID, puis cliquez sur Propriétés. S’il existe plusieurs GUID, suivez les
étapes suivantes :
a. Démarrez Windows PowerShell sur le serveur qui exécute le service AD FS.
b. Exécutez la commande suivante :
Add-PSSnapin microsoft.adfs.powershellGet-ADFSProperties
c. Recherchez le GUID du service AD FS en cours d’exécution sous Cer tificateShareingContainer .

5. Assurez-vous que le compte de service ADFS dispose des autorisations Lecture, Écriture et « Créer tous
les objets enfants » accordées à cet objet et à tous les descendants.
Étape 9 : Vérifier les fournisseurs de revendications et les parties de confiance pour les mises à jour de
certificats
Si les certificats de signature et de déchiffrement de jetons ont changé, assurez-vous que les fournisseurs de
revendications et les parties de confiance sont mis à jour pour avoir les nouveaux certificats. Si les fournisseurs
de revendications et les parties de confiance ne sont pas mis à jour, ils ne peuvent pas faire confiance au service
AD FS.
Une fois la modification réalisée, partagez le Federationmetadata.xml avec le fournisseur de revendications et
la partie de confiance.
Le fournisseur de revendications et la partie de confiance peuvent exiger uniquement que les nouveaux
certificats de signature de jetons et de déchiffrement de jetons (sans clé privée) soient mis à jour dans
l’autorisation de fédération à leur fin.
Étape 10 : Recherchez une demande signée et une réponse du fournisseur de revendications ou de la partie
de confiance
La demande et la réponse signées peuvent être reçues par le serveur AD FS du fournisseur de revendications ou
de la partie de confiance. Dans ce scénario, le serveur AD FS peut vérifier la validité du certificat utilisé pour la
signature et échouer. AD FS vérifie également la validité du certificat lié à la partie de confiance utilisée pour
envoyer un jeton chiffré au serveur AD FS.
Scénarios
AD FS 2.0 reçoit une demande SAML-P signée envoyée par une partie de confiance.
NOTE
L’utilisation de la signature des demandes de signature est une option configurable. Pour définir cette exigence
pour une confiance de partie de confiance, utilisez le paramètre RequireSignedSamlRequests avec la cmdlet
Set-ADFSRelyingPartyTrust de confiance.
AD FS 2.0 reçoit une demande de signature SAML signée de la partie de confiance. Dans ce scénario, la
demande de signature doit être signée.
AD FS 2.0 reçoit une demande de connexion d’un fournisseur de revendications et chiffre une demande
de connexion pour la partie de confiance. Dans ce scénario, le fournisseur de revendications initie la
signature.
AD FS 2.0 émettra un jeton chiffré pour une partie de confiance.
AD FS 2.0 reçoit un jeton émis par un fournisseur de revendications.
AD FS 2.0 reçoit une demande de signature SAML signée d’un fournisseur de revendications. Dans ce
scénario, la demande de signature doit être signée.
Ce qu’il faut vérifier pour résoudre le problème
Assurez-vous que le certificat de signature de l’trust du fournisseur de revendications est valide et qu’il
n’a pas été révoqué.
Assurez-vous qu’AD FS 2.0 peut accéder à la liste de révocation de certificats si le paramètre de
révocation ne spécifie pas de paramètre « aucun » ou « cache uniquement ».
NOTE
Vous pouvez utiliser Windows PowerShell cmdlets pour AD FS 2.0 pour configurer les paramètres de révocation
suivants :
Paramètre SigningCer tificateRevocationCheck de la cmdlet Set-ADFSClaimsProviderTrust ou Set-
ADFSRelyingPartyTrust
Paramètre Encr yptionCer tificateRevocationCheck de la cmdlet Set-ADFSRelyingPartyTrust ou Set-
ADFSClaimsProviderTrust
Pour plus d’informations, voir Troubleshooting certificate problems with AD FS 2.0.

Erreur ADFS 2.0 : 401 La ressource demandée
requiert l’authentification de l’utilisateur
Cet article traite d’un problème dans lequel vous êtes invité à obtenir des informations d’identification et où
l’événement 111 est enregistré lorsque vous authentifier un compte dans Active Directory Federation Services
(AD FS) 2.0.
Résumé
principales catégories suivantes. Cet article contient des instructions pas à pas pour résoudre les problèmes
d’authentification.
Symptômes
Lorsque vous essayez d’authentifier un compte dans Active Directory Federation Services (AD FS) 2.0, les
erreurs suivantes se produisent :
Le serveur AD FS renvoie le message d’erreur suivant :
Erreur 401 non autorisée-HTTP. La ressource demandée nécessite l’authentification de l’utilisateur.
Sur un écran de connexion basé sur un formulaire, le serveur renvoie le message d’erreur suivant :
Le nom d’utilisateur ou le mot de passe est incorrect.
Vous êtes continuellement invité à obtenir des informations d’identification.

L’événement 111 est consigné dans le journal d’administration AD FS, comme suit :
Nom du journal : AD FS 2.0/Admin

Niveau : Error
Mots clés : AD FS
Description :
Le service de fédération a rencontré une erreur lors du traitement de WS-Trust demande.
Type de requête : http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
Détails de l’exception :
Microsoft.IdentityModel.SecurityTokenService.FailedAuthenticationException: MSIS3019 : Échec de
l’authentification. ---> System.IdentityModel.Tokens.SecurityTokenValidationException : ID4063 : Échec
d’logonUser pour l’utilisateur « user1 ». Assurez-vous que l’utilisateur dispose d’un Windows valide. -
--> System.ComponentModel.Win32Exception : échec d’accès : nom d’utilisateur inconnu ou mot de
passe incorrect
Résolution
Pour résoudre ce problème, suivez ces étapes, dans l’ordre donné. Ces étapes vous aideront à déterminer la
cause du problème.
Étape 1 : Attribuer l’enregistrement de nom de service de fédération AD FS correct
Assurez-vous que le DNS possède un enregistrement HOST (A) pour le nom du service de fédération AD FS et
évitez d’utiliser un enregistrement CNAME. Pour plus d’informations, voir comportements d’Internet Explorer
avec l’authentification Kerberos.
Étape 2 : Vérifier l’inscription du nom du service de fédération
Recherchez le nom du service de fédération et vérifiez si le nom est enregistré sous le compte de service AD FS.
Pour cela, procédez comme suit :
1. Recherchez l’HÔTE/nom <Federation Ser vice Name> :
a. Ouvrez le Gestionnaire AD FS 2.0.
b. Cliquez avec le bouton droit sur ADFS 2.0, puis sélectionnez Modifier les propriétés du ser vice
de fédération.
c. Sous l’onglet Général, recherchez le champ Nom du service de fédération pour voir le nom.
2. Vérifiez si host/name est inscrit sous le compte de <Federation Ser vice Name> service AD FS :
a. Ouvrez le logiciel en snap-in Gestion. Pour ce faire, cliquez sur Démarrer, sur Tous les
programmes, sur Outils d’administration, puis sur Ser vices.
b. Double-cliquez sur AD FS (2.0) Windows Ser vice.
c. Sous l’onglet Connexion, notez le compte de service qui s’affiche dans le champ Ce compte.
d. Cliquez sur Démarrer , sur Tous les programmes , puis sur Accessoires , cliquez avec le bouton
droit sur Invite de commandes , puis cliquez sur Exécuter en tant qu’administrateur .
e. Exécutez la commande suivante :
SETSPN -L domain\<ADFS Service Account>
Si le nom du service de fédération n’existe pas encore, exécutez la commande suivante pour ajouter le nom
principal de service (SPN) au compte AD FS :
SetSPN -a host/<Federation service name> <username of service account>
Étape 3 : Recherchez les SNS en double

Vérifiez qu’il n’existe aucun nom de domaine complet en double pour le nom du compte AD FS. Pour cela,
1. Cliquez sur Démarrer , sur Tous les programmes , puis sur Accessoires , cliquez avec le bouton droit
sur Invite de commandes , puis cliquez sur Exécuter en tant qu’administrateur .
2. Exécutez la commande suivante pour vous assurer qu’il n’existe aucun nom de domaine complet en
double pour le nom du compte AD FS :
SETSPN -X -F
Étape 4 : Vérifier si le navigateur utilise l’authentification Windows intégrée

Assurez-vous que le navigateur Internet Explorer que vous utilisez est configuré pour utiliser
Windows’authentification intégrée. Pour ce faire, démarrez Internet Explorer, cliquez sur Paramètres, sur
Options Internet, sur Avancé, puis sur Activer l’authentification IntegratedWindows .
Étape 5 : Vérifier le type d’authentification
Assurez-vous que le type d’authentification par défaut sur le serveur AD FS est configuré correctement. Pour
1. Dans Windows’explorateur, accédez à C:\inetpub\adfs\ls (cela suppose qu’inetpub se trouve sur le lecteur C).
2. Recherchez Web.config, puis ouvrez le fichier dans Bloc-notes.
3. Dans le fichier, recherchez (Ctrl+F). <localAuthenticationTypes>
4. Sous <localAuthenticationTypes> , recherchez les quatre lignes qui représentent les types
d’authentification locaux.
5. Sélectionnez et supprimez votre type d’authentification local préféré (ligne entière). Ensuite, collez la ligne en
haut de la liste (sous <localAuthenticationTypes> ).
6. Enregistrez et fermez le fichier web.config.
Pour plus d’informations sur le type d’authentification local, consultez la rubrique TechNet suivante :
AD FS 2.0 : Procédure de modification du type d’authentification local
Étape 6 : Vérifier les paramètres d’authentification
Assurez-vous que les répertoires virtuels AD FS sont configurés correctement pour l’authentification dans
Internet Information Services (IIS).
Dans le nœud Site Web par défaut/adfs, ouvrez le paramètre d’authentification, puis assurez-vous que
l’authentification anonyme est activée.
Dans le nœud Site Web par défaut/adfs/ls, ouvrez le paramètre d’authentification, puis assurez-vous que
l’authentification anonyme et l’authentification Windows sont activées.
Étape 7 : Vérifier les paramètres d’confiance du proxy
Si vous avez configuré un serveur proxy AD FS, vérifiez si l’confiance du proxy est renouvelée pendant les
intervalles de connexion entre les serveurs proxy AD FS et AD FS.
Le serveur proxy renouvelle automatiquement l’confiance avec le service de fédération AD FS. Si ce processus
échoue, l’événement 394 est enregistré dans l’Observateur d’événements et vous recevez le message d’erreur
suivant :
Le serveur proxy de fédération n’a pas pu renouveler son accord avec le service de fédération.
Pour résoudre ce problème, réessayez d’exécuter l’Assistant Configuration du proxy AD FS. Lorsque l’Assistant
s’exécute, assurez-vous que les mots de passe et le nom d’utilisateur de domaine valides sont utilisés. Ces
informations d’identification ne sont pas stockées sur le serveur proxy AD FS. Lorsque vous entrez des
informations d’identification pour l’Assistant Configuration de l’trust de proxy, vous avez deux possibilités.
Utilisez les informations d’identification de domaine qui ont des droits d’administration local sur les serveurs
AD FS.
Utiliser les informations d’identification du compte de service AD FS
Étape 8 : Vérifier les paramètres de protection étendue IIS
Certains navigateurs ne peuvent pas s’authentifier si la protection étendue (autrement dit, l’authentification
Windows) est activée dans IIS, comme indiqué à l’étape 5. Essayez de désactiver l’authentification Windows pour
déterminer si cela résout le problème.
Vous pouvez également voir que la protection étendue n’autorise pas l’authentification Windows lorsque le
proxy SSL est effectué par des outils tels que Fiddler ou certains équilibreurs de charge intelligents.
Par exemple : vous pouvez voir des invites d’authentification répétées si fiddler Web Debugger est en cours
d’exécution sur le client.
Pour désactiver la protection étendue de l’authentification, suivez la méthode appropriée, en fonction du type de
client.
Pour les clients passifs
Utilisez cette méthode pour les applications virtuelles « Default Web Site/adfs/ls » sur tous les serveurs de la
batterie de serveurs de fédération AD FS. Pour cela, procédez comme suit :
1. Ouvrez le Gestionnaire des iis, puis recherchez le niveau à gérer.
Pour plus d’informations sur l’ouverture du Gestionnaire des iis, voir Open IIS Manager (IIS 7).
2. Dans l’affichage des fonctionnalités, double-cliquez sur Authentification.
3. Dans la page Authentification, sélectionnez Windows’authentification.
4. Dans le volet Actions, cliquez sur Paramètres .
5. Lorsque la boîte de dialogue Paramètres avancé s’affiche, cliquez sur Off dans le menu Protection
étendue.
Pour les clients actifs
Utilisez cette méthode pour le serveur AD FS principal :
1. Démarrez Windows PowerShell.
2. Pour charger le Windows PowerShell logiciel en snap-in AD FS, exécutez la commande suivante :
Add-PsSnapIn Microsoft.Adfs.Powershell
3. Pour désactiver la protection étendue de l’authentification, exécutez la commande suivante :
Set-ADFSProperties -ExtendedProtectionTokenCheck "None"
Étape 9 : Vérifier l’état du canal sécurisé entre le serveur ADFS et les DCS
Assurez-vous que le canal sécurisé entre AD FS et les DCS est bon. Pour ce faire, exécutez la commande
suivante :
Nltest /dsgetdc:domainname
Si la réponse est autre que « réussite », vous devez résoudre les problèmes du canal sécurisé netlogon. Pour ce
faire, assurez-vous que les conditions suivantes sont vraies :
Le contrôleur de domaine (DC) est accessible
Les noms de dc peuvent être résolus
Les mots de passe sur l’ordinateur et son compte sur le site Active Directory sont synchronisés.
Étape 10 : Vérifier les goulots d’étranglement
Vérifiez si vous rencontrez des goulots d’étranglement liés à l’authentification selon le paramètre
MaxconcurrentAPI sur le serveur AD FS ou sur les DCS. Pour plus d’informations sur la vérification de ce
paramètre, consultez l’article suivant de la Base de connaissances :
Comment régler les performances pour l’authentification NTLM à l’aide du paramètre MaxConcurrentApi
Étape 11 : Vérifier si le serveur proxy ADFS rencontre une congestion
Vérifiez si le serveur proxy ADFS est en cours de limitation des connexions, car il a reçu de nombreuses
demandes ou une réponse différée du serveur AD FS. Pour plus d’informations, consultez la rubrique TechNet
suivante :
AD FS 2.x : Dépannage de l’ID d’événement du serveur proxy 230 (algorithme d’algorithme d’congestion)
Dans ce scénario, vous pouvez remarquer des échecs de connexion intermittents sur ADFS.
Étape 12 : Vérifier les paramètres d’confiance du proxy
Si vous avez configuré un serveur proxy ADFS, vérifiez si l’confiance du proxy est renouvelée pendant les
intervalles de connexion entre les serveurs proxy AD FS et AD FS.
Le serveur proxy renouvelle automatiquement l’confiance avec le service de fédération AD FS. Si ce processus
échoue, l’événement 394 est enregistré dans l’Observateur d’événements et vous recevez le message d’erreur
suivant :
Le serveur proxy de fédération n’a pas pu renouveler son accord avec le service de fédération.
Pour résoudre ce problème, réessayez d’exécuter l’Assistant Configuration du proxy AD FS. Lorsque l’Assistant
s’exécute, assurez-vous que les mots de passe et le nom d’utilisateur de domaine valides sont utilisés. Ces
informations d’identification ne sont pas stockées sur le serveur proxy AD FS.
Étape 13 : Activer l’audit ADFS avec les événements d’audit d’logo : réussite et échec
Pour plus d’informations, voir Configuring ADFS Servers for Troubleshooting.
Erreur ADFS 2.0 : Cette page ne peut pas être
affichée
Cet article fournit une solution à une erreur lorsque vous essayez d’accéder à une application sur un site web
qui utilise AD FS 2.0.
Résumé
principales catégories suivantes. Cet article contient des instructions pas à pas pour résoudre les problèmes de
connectivité.
Échec du démarrage du service ADFS 2.0 (KB 3044971)
Symptômes
Symptôme 1
Lorsque vous essayez d’accéder à une application web sur un site web qui utilise les services AD FS
(Active Directory Federation Services) 2.0, vous recevez le message d’erreur suivant :
Cette page ne peut pas être affichée.
Symptôme 2
Vous ne pouvez pas accéder à la page d' sign-on initiée par IDP et aux métadonnées AD FS suivantes :
https://ADFSServiceName/federationmetadata/2007-06/federationmetadata.xml
https://ADFSServiceName/adfs/ls/idpinitiatedsignon.aspx
Résolution
Pour résoudre ce problème, suivez ces étapes dans l’ordre. Ces étapes vous aideront à déterminer la cause du
problème. Veillez à vérifier si le problème est résolu après chaque étape.
Étape 1 : Vérifier si le client est redirigé vers l’URL AD FS correcte
1. Démarrez Internet Explorer.
2. Appuyez sur F12 pour ouvrir la fenêtre des outils de développement.
3. Sous l’onglet Réseau, sélectionnez le bouton Démarrer ou appuyez sur Démarrer la capture pour
activer la capture du trafic réseau.
4. Accédez à l’URL de l’application web.
5. Examinez les traces réseau pour voir que le client est redirigé vers l’URL du service AD FS pour
l’authentification. Assurez-vous que l’URL du service AD FS est correcte.
Dans la capture d’écran suivante, la première URL est pour l’application web et la deuxième pour le
service AD FS.
Comment corriger
Si vous êtes redirigé vers une adresse incorrecte, vous avez probablement des paramètres de fédération
AD FS incorrects dans votre application web. Vérifiez ces paramètres pour vous assurer que l’URL du
service de fédération AD FS (fournisseur de services SAML) est correcte.
Étape 2 : Vérifier si le nom du service AD FS peut être résolu en adresse IP correcte
Sur un ordinateur client et un serveur proxy AD FS (le cas présent), utilisez une commande ping ou
nslookup pour déterminer si le nom du service AD FS est résolu en adresse IP correcte. Utilisez les
instructions suivantes :
Intranet : le nom doit être résolu en ADRESSE IP du serveur AD FS interne ou adresse IP à charge
équilibrée du serveur AD FS (Interne).
Externe : le nom doit être résolu en adresse IP externe/publique du service AD FS. Dans ce cas, le
DNS public est utilisé pour résoudre le nom. Si vous remarquez que différentes IPS publiques sont
renvoyées à partir de différents ordinateurs pour le même nom de service AD FS, la modification
récente du DNS public n’est peut-être pas encore propagée sur tous les serveurs DNS publics dans
le monde entier. Une telle modification peut nécessiter jusqu’à 24 heures pour être répliquée.
IMPORTANT
Sur tous les serveurs AD FS, assurez-vous que les serveurs proxy AD FS peuvent résoudre le nom du
service AD FS sur l’adresse IP interne du serveur AD FS ou sur l’adresse IP à charge équilibrée du serveur
AD FS interne. La meilleure façon de le faire consiste à ajouter une entrée dans le fichier HOST sur le
serveur proxy AD FS ou à utiliser une configuration DNS fractionné dans un réseau de périmètre
(également appelé « DMZ », « zone démilitarisée » et « sous-réseau filtré »).
Exemple de commande nslookup :
Nslookup sts.contoso.com
Comment corriger
Vérifiez l’enregistrement du nom du service AD FS via le serveur DNS ou le fournisseur de services
Internet (ISP). Assurez-vous que l’adresse IP est correcte.
Étape 3 : Vérifier si le port TCP 443 sur le serveur AD FS est accessible
Utilisez Telnet ou PortQryUI - Interface utilisateur pour l’analyseur de port de ligne de commande
PortQry pour interroger la connectivité du port 443 sur le serveur AD FS. Assurez-vous que le port 443
est à l’écoute.
Comment corriger
Si le serveur AD FS n’est pas à l’écoute sur le port 443, suivez les étapes suivantes :
1. Assurez-vous que le service Windows AD FS 2.0 est démarré.
2. Vérifiez le Windows de pare-feu sur le serveur AD FS pour vous assurer que le port TCP 433 est
autorisé à établir des connexions.
3. Si un équilibreur de charge est utilisé avant les services AD FS, essayez de contourner le processus
d’équilibrage de charge pour vérifier qu’il ne s’agit pas de la cause du problème. (L’équilibrage de
charge est une cause courante.)
Étape 4 : Vérifiez si vous pouvez utiliser une page d’authentification initiée par IdP pour vous authentifier
auprès d’ADFS
Démarrez Internet Explorer, puis accédez à l’adresse web suivante. Si vous recevez un avertissement de
certificat lorsque vous essayez d’ouvrir cette page, sélectionnez Continuer.
http:// <YourADFSServiceName> /adfs/ls/idpinitiatedsignon.aspx
NOTE
Dans cette URL, représente le nom réel du <YourADFSServiceName> service AD FS.
En règle générale, vous accédez à un écran de connexion, puis vous pouvez vous connectez à l’aide de vos
informations d’identification.
Comment corriger
Si vous pouvez réussir les étapes 1 à 3, mais que vous ne pouvez toujours pas accéder à l’application
web, suivez les étapes suivantes :
1. Utilisez un autre ordinateur client et un autre navigateur pour les tests. Il peut y avoir un problème qui
affecte le client.
2. Pour résoudre les problèmes avancés suivants, vous pouvez :
3. Collectez les informations de suivi et de capture réseau du débogger Web Fiddler pendant que vous
accédez à la IDPInitiatedsignon page. Pour plus d’informations, voir AD FS 2.0: How to Use Fiddler
Web Debugger to Analyze a WS-Federation Passive Sign-In.
4. Collectez les suivis réseau à partir de l’ordinateur client pour vérifier si l’accord SSL s’est correctement
terminé, s’il existe un message chiffré, si vous accédez à l’adresse IP correcte, etc. Pour plus
d’informations, voir Comment activer la journalisation des événements Schannel dans Windows et
Windows Server.
Exclusion de responsabilité de tiers
produits.
Le démarrage du service AD FS 2.0 échoue
Cet article fournit les étapes de résolution des problèmes de configuration et de démarrage du service ADFS.
Résumé
La plupart des problèmes ADFS 2.0 appartiennent à l’une des principales catégories suivantes. Cet article
contient les instructions pas à pas pour résoudre les problèmes de service ADFS.
Problèmes de connectivité
Problèmes liés aux certificats
Problèmes d’authentification
Problèmes liés aux règles de revendication
Symptômes
Le service AD FS ne démarre pas.
Le service AD FS démarre, mais les erreurs suivantes sont consignées dans le journal d’administration AD
FS après un redémarrage :
La configuration du service FS n’a pas pu être chargée correctement à partir de la base de données de
configuration AD FS.
Une SQL Server de configuration AD FS avec la chaîne de connexion %1 a échoué.
Une erreur s’est produite lors de l’activation des points de terminaison du service de fédération.
Résolution
Pour résoudre ce problème, suivez ces étapes, dans l’ordre donné. Ces étapes vous aideront à déterminer la
Étape 1 : Vérifier si le service AD FS a un temps d’attente au démarrage
Si le service AD FS n’est plus à l’issue de sa tentative de démarrage, vous recevez le message d’erreur suivant :
Le service n’a pas répondu à la demande de démarrage ou de contrôle en temps voulu.
Corriger les temps de service AD FS

Modifiez les données de valeur pour la valeur DWORD Ser vicesPipeTimeout sur 60000 dans la clé de
contrôle. Pour cela, procédez comme suit :
1. Sur le serveur AD FS, ouvrez l’Éditeur du Registre.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
3. Cliquez sur la sous-clé Contrôle.

4. Cliquez avec le bouton droit sur la valeur DWORD Ser vicesPipeTimeout, puis cliquez sur Modifier. S’il
n’existe aucune valeur Ser vicesPipeTimeout, créez-la.
5. Cliquez sur Décimal .
6. Tapez 60000, puis cliquez sur OK. Pour plus d’informations sur cette erreur de délai d’erreur, voir AD FS
2.0 :Le service ne parvient pas à démarrer : « Le service n’a pas répondu à la demande de démarrage ou
de contrôle en temps voulu ».
Étape 2 : Vérifier si la base de données de configuration AD FS est en cours d’exécution
Si vous utilisez Base de données interne Windows (WID) comme base de données de configuration AD
FS, ouvrez services.msc et vérifiez si le service Base de données interne Windows est en cours
d’exécution.
Si vous utilisez le service SQL Server comme base de données de configuration AD FS, ouvrez
services.msc. Vérifiez si le service SQL Server est en cours d’exécution. Vous pouvez également créer un
fichier Test.udl et remplir la chaîne de connexion pour tester la connectivité Microsoft SQL Server.
Comment corriger
Ouvrez Services.msc, puis démarrez le service Base de données interne Windows service ou SQL Server service.
Pour un serveur AD FS qui utilise SQL Server comme base de données de configuration, vous devez également
vérifier deux paramètres de sécurité, comme suit :
1. Connecter le serveur qui s’exécute SQL Server à l’aide de SQL Management Studio.
2. Vérifiez si l’identité du service Windows AD FS 2.0 existe sur la console SQL Server sur le nœud >
Connexions de sécurité. Si ce n’est pas le cas, ajoutez-le.
3. Vérifiez si l’identité du service Windows AD FS 2.0 existe sous > Databases AdfsConfiguration
Security Users et qu’il possède le schéma > > IdentitySer verPolicy. Si ce n’est pas le cas, ajoutez-le.
Étape 3 : Vérifier le compte de service AD FS
1. Vérifiez si le service AD FS et le service AppPool IIS sont en cours d’exécution sous un compte de service
valide. Si vous avez modifié le mot de passe du compte de service, assurez-vous que le nouveau mot de
passe est mis à jour dans le service AD FS et dans iiS AppPool.
a. Ouvrez Services.msc, cliquez avec le bouton droit sur AD FS 2.0 Ser vice, puis cliquez sur
Propriétés. Sous l’onglet Connexion, assurez-vous que le nouveau compte de service AD FS
est répertorié dans la zone Ce compte.
b. Ouvrez le Gestionnaire des iis, accédez aux pools d’applications, cliquez avec le bouton droit sur
ADFSAppPool, puis cliquez sur Advanced Paramètres . Dans la section Modèle de processus,
assurez-vous que le nouveau compte de service AD FS est répertorié en tant qu’identité.
2. Vérifiez si le compte de service dispose d’autorisations suffisantes dans la base de données AD FS. Vous
devez être préoccupé par l’autorisation si vous avez modifié le compte de service sous le service ADFS en
cours d’exécution.
Si vous utilisez SQL Server serveur de configuration, suivez les étapes suivantes pour réinitialiser
l’autorisation pour le compte de service :
a. À l’invite de commandes, exécutez la commande suivante :
fsconfig.exe /CreateSQLScripts /ServiceAccount <ADFS service account> /ScriptDestinationFolder
<path to create scripts>
b. Copiez le script que vous avez créé sur le serveur qui exécute SQL Server.
c. Exécutez le script sur le serveur.
3. Vérifiez si le compte de service dispose d’autorisations de lecture et de modification sur le conteneur de
partage de certificats (CN= <GUID> ,CN=ADFS,CN=Microsoft,CN=Program Data,DC=
<Domain> ,DC= <COM> ).
a. Sur un contrôleur de domaine, ouvrez ADSIEDIT.msc.
b. Connecter au contexte d’attribution de noms par défaut.
c. Accédez à CN= <GUID> ,CN=ADFS,CN=Microsoft,CN=Program Data,DC= <Domain>
,DC= <COM> . Un exemple de GUID est 62b8a5cb-5d16-4b13-b616-06caea706ada.
d. Cliquez avec le bouton droit sur le GUID, puis cliquez sur Propriétés. S’il existe plusieurs GUID,
suivez ces étapes pour trouver le GUID du serveur qui exécute le service AD FS.
a. Sur le serveur qui exécute le service AD FS, démarrez Windows PowerShell.
b. Exécutez les commandes suivantes :
Add-PSSnapin microsoft.adfs.powershell
Get-ADFSProperties
c. Le GUID est répertorié sous Cer tificateShareingContainer .

4. Vérifiez si le nouveau compte de service dispose de l’autorisation Lecture sur la clé privée du certificat de
communication du service AD FS.
a. Créez une console MMC (Microsoft Management Console) à l’aide du logiciel en ligne Certificats qui
cible le magasin de certificats de l’ordinateur local.
b. Développez la MMC, puis sélectionnez Gérer les clés privées.
c. Sous l’onglet Sécurité, ajoutez le compte de service AD FS et accordez l’autorisation lecture à ce
compte.
5. Vérifiez si l’hôte AD FS Service Principal (SPN) HOST/ADFSServiceName a été ajouté sous le compte de
service et a été supprimé du compte précédent (au cas où le compte de service changerait).
a. Cliquez avec le bouton droit sur Invite de commandes, puis cliquez sur Exécuter en tant
qu’administrateur.
b. SetSPN -f -q host/ <Federation service name> Tapez, puis appuyez sur Entrée.
Dans cette commande, représente le nom de service de nom de domaine complet (FQDN) du point de
terminaison du <Federation service name> service AD FS. Vous trouverez le nom du service dans la
boîte de dialogue Propriétés du service de fédération :
Pour ajouter ou supprimer le SPN du compte, suivez les étapes suivantes :
a. Sur un contrôleur de domaine, ouvrez ADSIEDIT.msc.
b. Connecter au contexte d’attribution de noms par défaut.
c. Développez vers CN=Utilisateurs,CN=Microsoft,CN=Données de programme,DC=
<Domain> ,DC= <COM> .
d. Recherchez le compte de service. Cliquez avec le bouton droit sur le compte de service, puis
cliquez sur Propriétés.
e. Recherchez l’attribut ser vicePrincipalName, puis cliquez sur Modifier .
f. Ajoutez ou supprimez le SPN du service AD FS. Voici un exemple de SPN de service AD FS :
HOST/newadfs.contoso.com
6. Si vous modifiez le mot de passe du compte de service, assurez-vous que le nouveau mot de passe est
mis à jour dans le service AD FS et dans Lepool d’application IIS AD FS.
7. Vérifiez si le compte de service AD FS se trouve dans le groupe d’administration local. Pour éviter tout
problème potentiel, accordez au compte de service AD FS des droits d’administrateur local.
Étape 4 : Mettre à jour le service AD FS vers la dernière version
Vérifiez si les mises à jour suivantes sont installées. Si ce n’est pas le cas, installez-les.
Rollup Update 2 for ADFS 2.0
Mise à jour de déploiement 3 pour ADFS 2.0
La mise à jour est disponible pour résoudre plusieurs problèmes après l’installation de la mise à jour de
sécurité 2843638 sur un serveur AD FS
Étape 5 : Corriger une défaillance intermittente du service AD FS
Si vous rencontrez une défaillance intermittente du service AD FS, vérifiez si le problème a commencé après
l’application de la mise 2894844 sécurité. Dans ce cas, AD FS échoue et génère un numéro de référence lorsqu’il
est accessible à partir d’un réseau externe ou via une communication basée sur un formulaire.
Si le problème a commencé après l’application de la 2894844 de mise à jour de sécurité, vous rencontrez peut-
être le problème décrit dans la cause 1 : l’application web est en cours d’exécution dans une section de batterie
(environnement multi-ser veur) dans Résolution des erreurs de code d’authentification de message d’état
d’affichage (MAC).
Pour résoudre ce problème, définissez la même clé d’ordinateur statique sur tous les serveurs AD FS et le proxy
AD FS :
1. Dans le Gestionnaire des iis, recherchez et ouvrez le dossier adfs/ls.
2. Dans la section ASP.NET, cliquez sur Touche ordinateur.
3. Désinsécher la générer automatiquement lors de l’utilisation et générer une clé unique pour chaque
application à cocher pour la clé de validation et la clé de déchiffrement.
4. Cliquez sur Générer les clés.
5. Cliquez sur Appliquer .
6. Copiez les clés de validation et de déchiffrement du premier serveur AD FS, puis collez-les sur tous les autres
serveurs.
Étape 6 : assurez-vous que les certificats de communication, de signature de jetons et de déchiffrement de
jeton du service ADFS sont configurés correctement
Pour plus d’informations, voir erreur de certificat ADFS 2.0: une erreur s’est produite lors d’une tentative de
construction de la chaîne de certificats.
Disponibilité et description des services AD FS
(Active Directory Federation Services) 2.0
Cet article fournit la disponibilité et la description d’Active Directory Federation Services 2.0.
Introduction
Active Directory Federation Services (AD FS) 2.0 permet aux utilisateurs de collaborer au-delà des limites de
l’organisation et d’accéder facilement aux applications en local et dans le cloud. De plus, AD FS permet de
maintenir la sécurité des applications. Grâce à une infrastructure basée sur les revendications, le système
informatique peut activer une expérience d’sign-on unique pour les utilisateurs finaux des applications. Une telle
infrastructure basée sur les revendications ne nécessite pas de compte ou mot de passe distinct, que les
applications soient situées dans des organisations partenaires ou hébergées dans le cloud.
Configuration requise
Pour implémenter AD FS 2.0, l’ordinateur doit exécuter l’un des systèmes d’Windows suivants :
Windows Server 2008 R2 (64 bits) :
Datacenter Edition
Enterprise Edition
Standard Edition
Embedded Solution Edition
Small Business Solutions Edition
Small Business Solutions EM Edition
Serveur petite Édition Standard
Small Businesses Server Premium Edition
Solutions Premium Edition
Solutions Edition
Solutions EM Edition
Foundation Server Edition
Small Businesses Edition
Essential Additional Edition
Essential Additional Svc Edition
Essential Management Edition
Essential Management Svc Edition
Windows Server 2008 avec Service Pack 2 (32 bits ou 64 bits) :
Datacenter Edition
Datacenter sans Hyper-V Edition
Enterprise Edition
Enterprise sans Hyper-V Edition
Standard Edition
Édition Moyenne Gestion des entreprises
Medium Business Messaging Edition
Édition Business Security de taille moyenne
Small Business Server Premium Edition
Serveur Petite Entreprise Édition Standard
Small Business Server Prime Edition
Small Businesses Edition
Édition Petites Entreprises sans Hyper-V
Pour installer AD FS 2.0, les logiciels et correctifs suivants doivent être installés. S’ils ne sont pas installés lors de
l’installation d’AD FS 2.0, le programme d’installation d’AD FS 2.0 les installe automatiquement.
Microsoft .NET Framework 3.5 avec Service Pack 1
NOTE
Ce logiciel est installé automatiquement uniquement lorsque l’ordinateur exécute Windows Server 2008 R2.
Windows PowerShell
Internet Information Services (IIS) 7
Windows Identity Foundation (WIF)
Mises à jour logicielles et correctifs logiciels
Le correctif logiciel suivant doit être installé sur les ordinateurs qui exécutent Windows Server
2008 R2 :
981002 un correctif est disponible pour Windows Communication Foundation dans .NET
Framework 3.5 Service Pack 1 pour Windows 7 et Windows Server 2008 R2
Windows Server 2008
Les mises à jour logicielles et les correctifs logiciels suivants doivent être installés sur les
ordinateurs exécutant Windows Server 2008 SP2 :
973917 description de la mise à jour qui implémente la protection étendue de l’authentification
dans Internet Information Services (IIS)
Langues prises en charge

AD FS 2.0 est pris en charge dans les langues suivantes :
Chinois (simplifié)
Chinois (traditionnel)
Tchèque
Néerlandais
Anglais
Français
Allemand
Hongrois
Italien
Japonais
Coréen
Polonais
Portugais (Brésil)
Portugais (Espagnol)
Russe
Espagnol
Suédois
Turc
Télécharger des informations

Les fichiers suivants peuvent être téléchargés à partir du Centre de téléchargement Microsoft :
SY ST ÈM E D W IN DO W S
D’EXP LO ITAT IO N P RIS EN TA IL L E DU F IC H IER DE
N O M DU PA C K A GE C H A RGE P L AT EF O RM E T ÉL ÉC H A RGEM EN T
AdfsSetup.exe Windows Server 2008 R2 x64 24,04 Mo
AdfsSetup.exe Windows Server 2008 SP2 x64 42,64 Mo
AdfsSetup.exe Windows Server 2008 SP2 x86 38,66 Mo
Pour plus d’informations sur le téléchargement des fichiers de support Microsoft, voir Comment obtenir des
fichiers de support Microsoft à partir de services en ligne.
Microsoft a analysé ce fichier à la recherche de virus. Microsoft a utilisé le logiciel de détection de virus le plus
actuel disponible à la date de la date de la mise en ligne du fichier. Le fichier est stocké sur des serveurs à
sécurité améliorée qui permettent d’empêcher toute modification non autorisée du fichier.
Plus d’informations sur Active Directory Federation Services 2.0

Pour plus d’informations sur les détails techniques et les livres blancs, voir Active Directory Federation Services
2.0 Overview.
Informations de mise à niveau pour Windows d’exploitation

Si AD FS 2.0 est déployé sur un ordinateur exécutant Windows Server 2008, AD FS 2.0 est automatiquement
désinstallé lorsque vous effectuez une mise à niveau de votre système d’exploitation Windows vers Windows
Server 2008 R2. Vous devez installer le package d’installation AD FS 2.0 pour Windows Server 2008 R2 après
avoir mis à niveau le Windows d’exploitation.
Si vous souhaitez conserver les données de configuration précédentes sur le serveur de fédération et restaurer
les données après avoir réinstallé AD FS 2.0, suivez les étapes des sections Avant de mettre à niveau les
Windows et Après la mise à niveau Windows.
Avant de mettre à niveau Windows
Copiez le fichier de configuration du service AD FS sur un serveur de fichiers sur le réseau avant de mettre à
niveau le système d’exploitation. Notez également le compte de service utilisé par le service Windows AD FS 2.0.
1. Recherchez le dossier d’installation AD FS 2.0 suivant :
%system drive%\Program FilesActive\ Directory Federation Service 2.0
2. Copiez le fichier de configuration suivant dans un emplacement de sauvegarde sécurisé :
Microsoft.IdentityServer.Servicehost.exe.config
3. Cliquez sur Démarrer , sur Exécuter , entrez services.msc, puis cliquez sur OK .
4. Cliquez avec le bouton droit sur AD FS 2.0 Windows Ser vice , puis cliquez sur Propriétés .
5. Sous l’onglet Connexion , notez le compte de service utilisé pour le service Windows AD FS 2.0.
Après la mise à niveau Windows
Réinstallez AD FS 2.0, définissez un paramètre de Registre pour restaurer la configuration précédente, restaurer
le compte de service et démarrer les services appropriés. Pour cela, procédez comme suit.
NOTE
Une fois ces étapes terminés, l’installation précédente d’AD FS 2.0 qui était présente sur ce serveur de fédération avant la
mise à niveau est restaurée.
1. Réinstallez AD FS 2.0.
2. Copiez le fichier de configuration suivant que vous avez enregistré à l’étape 2 de la section Avant
Windows mise à niveau :
Microsoft.IdentityServer.Servicehost.exe.config
3. Recherchez le dossier d’installation AD FS 2.0 suivant, puis copiez le fichier mentionné à l’étape 2 à cet
emplacement :
%system drive%\Program FilesActive\ Directory Federation Service 2.0
5. Recherchez la sous-clé de Registre suivante, puis cliquez dessus :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\adfssrv
6. Dans le menu Édition , pointez sur Nouveau , puis cliquez sur Valeur de chaîne .
7. Tapez InitialConfigurationCompleted, puis appuyez sur Entrée.
8. Cliquez avec le bouton droit sur InitialConfigurationCompleted , puis cliquez sur Modifier .
9. Dans la zone Données de la valeur, tapez TRUE, puis cliquez sur OK .
10. Dans le menu Fichier , cliquez sur Quitter pour quitter l’Éditeur du Registre.
12. Si vous utilisez Base de données interne Windows comme base de données de configuration AD FS 2.0,
suivez ces étapes. Dans le cas contraire, ignorez l’étape 12 et allez à l’étape 13.
a. Cliquez avec le bouton droit Base de données interne Windows (MICROSOFT##SSEE), puis
b. Sous l’onglet Général , si le champ État du ser vice n’affiche pas Démarré, cliquez sur Démarrer
pour démarrer Base de données interne Windows service.
c. Cliquez sur OK .
13. Cliquez avec le bouton droit sur AD FS 2.0 Windows Ser vice , puis cliquez sur Propriétés .
14. Sous l’onglet Connexion , fournissez le nom du compte de service d’origine et le mot de passe utilisé
pour le service Windows AD FS 2.0.
15. Sous l’onglet Général , sélectionnez Automatique dans la zone De démarrage .
16. Si le champ État du ser vice n’affiche pas Démarré, cliquez sur Démarrer pour démarrer le service
Windows AD FS 2.0.
17. Cliquez sur OK .
Informations sur la déclaration de confidentialité

AD FS 2.0 est couvert par la déclaration de confidentialité Windows server suivante :
Windows 7 déclaration de confidentialité
Révisions techniques
Le tableau suivant répertorie les révisions techniques importantes apportées à cet article. Le numéro de révision
et la date de la dernière révision de cet article peuvent indiquer des révisions éditoriales mineures ou
structurelles de cet article qui ne sont pas incluses dans le tableau.
DAT E REVISIO N
5 mai 2010 Date de publication d’origine

Comment modifier le certificat de communications
de service AD FS 2.0 après son expiration
Cet article décrit les étapes à suivre pour modifier le certificat de communications de service Active Directory
Federation Services 2.0.
S’applique à : Windows Server 2008 R2 Service Pack 1
Symptômes
Un utilisateur souhaite savoir comment modifier le certificat de communication du service AD FS (Active
Directory Federation Services) 2.0 après son expiration ou pour d’autres raisons.
Résolution
Le remplacement d’un certificat de service serveur AD FS 2.0 existant est un processus à plusieurs étapes.
Étape 1
Installez le nouveau certificat dans le magasin de certificats de l’ordinateur local. Pour ce faire, suivez les étapes
suivantes :
1. Sélectionnez Démarrer , puis Exécuter .
2. Tapez MMC .
3. Dans le menu Fichier , sélectionnez Ajouter/Supprimer un composant logiciel enfichable .
4. Dans la liste Des logiciels en snap-in disponibles, sélectionnez Cer tificats, puis ajoutez . L’Assistant
Logiciel en un clin d’œil des certificats démarre.
5. Sélectionnez Compte d’ordinateur , puis sélectionnez Suivant .
6. Sélectionnez Ordinateur local : (l’ordinateur sur qui cette console est en cours d’exécution), puis
sélectionnez Terminer .
7. Sélectionnez OK .
8. Expand Console Root\Cer tificates (Local Computer)\Personal\Cer tificates .
9. Cliquez avec le bouton droit sur Cer tificats, sélectionnez Toutes les tâches, puis sélectionnez
Impor ter.
Étape 2
Ajoutez au compte de service AD FS les autorisations d’accès à la clé privée du nouveau certificat. Pour ce faire,
1. Une fois que le magasin de certificats de l’ordinateur local est toujours ouvert, sélectionnez le certificat
qui a été importé.
2. Cliquez avec le bouton droit sur le certificat, sélectionnez Toutes les tâches, puis sélectionnez Gérer
les clés privées.
3. Ajoutez le compte qui exécute le ser vice ADFS, puis accordez au moins au compte des autorisations de
lecture.
NOTE
Si vous n’avez pas la possibilité de gérer les clés privées, vous de devez peut-être exécuter la commande suivante :
certutil -repairstore my *
Étape 3
Lier le nouveau certificat au site web AD FS à l’aide du Gestionnaire des iis. Pour ce faire, suivez les étapes
suivantes :
1. Ouvrez le Internet Information Services (IIS) Manager.
2. Accédez au site Web par défaut.
3. Cliquez avec le bouton droit sur Site Web par défaut, puis sélectionnez Modifier les liaisons.
4. Sélectionnez HTTPS, puis modifiez.
5. Sélectionnez le certificat correct sous l’en-tête du certificat SSL.
6. Sélectionnez OK, puis fermez.
Étape 4
Configurez le service AD FS Server pour utiliser le nouveau certificat. Pour ce faire, suivez les étapes suivantes :
1. Ouvrez AD FS 2.0 Management.
2. Accédez à AD FS 2.0\Ser vice\Cer tificates .
3. Cliquez avec le bouton droit sur Cer tificats, puis sélectionnez Définir le cer tificat de
communications de ser vice.
4. Sélectionnez le nouveau certificat dans l’interface utilisateur de sélection de certificat.
NOTE
Vous pouvez voir une boîte de dialogue contenant le message suivant :
La longueur de la clé de certificat est inférieure à 2 048 bits. Les certificats dont la taille de clé est inférieure à 2
048 bits peuvent présenter un risque de sécurité et ne sont pas recommandés. Voulez-vous continuer ?
Après avoir lu le message, sélectionnez Oui . Une autre boîte de dialogue apparaît. Il contient le message
suivant :
Assurez-vous que la clé privée du certificat choisi est accessible au compte de service pour ce service
de fédération sur chaque serveur de la batterie de serveurs.
Cette étape a déjà été effectuée à l’étape 2. Sélectionnez OK .

Encore besoin d’aide ? Go to Office 365 Community.
Description de la fonctionnalité verrouillage
intelligent extranet dans Windows Server 2016
Cet article décrit la fonctionnalité de verrouillage intelligent extranet dans Windows Server 2016.
Présentation
À partir de la mise à jour de mars 2018 pour Windows Server 2016, les services AD FS (Active Directory
Federation Services) disposent d’une nouvelle fonctionnalité nommée ESL (Smart Lockout). Dans une ère
d’attaques accrues sur les services d’authentification, ESL permet aux services AD FS de ne pas différencier les
tentatives de connecteur d’un utilisateur valide et les tentatives de se connectant de ce qui peut être une
personne malveillante. Par conséquent, AD FS peut verrouiller les attaquants tout en permettant aux utilisateurs
valides de continuer à utiliser leur compte. Cela empêche le déni de service pour les utilisateurs et protège
contre les attaques ciblées contre les comptes d’utilisateur connus.
La fonctionnalité ESL est disponible pour AD FS dans Windows Server 2016.
Comment installer et configurer ESL

Installer les mises à jour sur tous les serveurs
Tout d’abord, assurez-vous que tous Windows Server 2016 serveurs AD FS sont à jour depuis les mises à jour
Windows mars 2018.
Mettre à jour les autorisations de base de données d’artefacts
Le verrouillage intelligent extranet nécessite que le compte de service AD FS soit autorisé à créer une table dans
la base de données d’artefacts AD FS. Connectez-vous à n’importe quel serveur AD FS en tant qu’administrateur
AD FS, puis accordez cette autorisation en exécutant les commandes suivantes dans une fenêtre d’invite de
commandes PowerShell :
$cred= Get-Credential
Update-AdfsArtifactDatabasePermission -Credential$cred
NOTE
L$cred un espace réservé est un compte qui dispose des autorisations d’administrateur AD FS. Cela doit fournir les
autorisations d’écriture pour créer le tableau.
Les commandes ci-dessus peuvent échouer en raison d’un manque d’autorisations suffisantes, car votre batterie
de serveurs AD FS utilise SQL Server et les informations d’identification fournies ci-dessus ne disposent pas
d’autorisations d’administrateur sur votre serveur SQL. Dans ce cas, vous pouvez configurer manuellement les
autorisations de base de données dans SQL Server Database en exécutant la commande suivante lorsque vous
êtes connecté à la base de données AdfsArtifactStore.
ALTER AUTHORIZATION ON SCHEMA::[ArtifactStore] TO [db_genevaservice]
Configurer ESL
Un nouveau paramètre nommé ExtranetLockoutMode est ajouté pour prendre en charge ESL. Il contient les
valeurs suivantes :
ADPasswordCounter : il s’agit du mode de « verrouillage souple extranet » AD FS hérité, qui ne se différencie
pas en fonction de l’emplacement. Ceci est la valeur par défaut.
ADFSSmartLockoutLogOnly : il s’agit du verrouillage intelligent extranet. Au lieu de rejeter les demandes
d’authentification, AD FS écrit des événements d’administration et d’audit.
ADFSSmartLockoutEnforce : il s’agit du verrouillage intelligent extranet avec prise en charge complète du
blocage des demandes inconnues lorsque les seuils sont atteints.
Nous vous recommandons de configurer d’abord le fournisseur de verrouillage pour qu’il se connecte
uniquement pendant une courte période (1 à 3 jours) en exécutant l’cmdlet suivante. Examinez les audits (voir
ci-dessous pour plus d’informations) au cours de cette période pour déterminer le nombre de comptes
susceptibles d’être touchés ainsi que la fréquence de ces événements. Après avoir réussi l’évaluation des audits,
définissez le paramètre sur le mode « ADFSSmartLockoutEnforce » :
Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly
Dans ce mode, AD FS effectue l’analyse, mais ne bloque aucune demande en raison des compteurs de
verrouillage. Ce mode permet de vérifier que le verrouillage intelligent s’exécute correctement avant d’activer le
mode « appliquer ».
Pour que le nouveau mode prenne effet, redémarrez le service AD FS sur tous les serveurs en exécutant la
commande suivante :
Restart-service adfssrv
Définir le seuil de verrouillage et la fenêtre d’observation

Il existe deux paramètres clés pour ESL : le seuil de verrouillage et la fenêtre d’observation.
Paramètre du seuil de verrouillage
Chaque fois qu’une authentification basée sur un mot de passe réussit, AD FS stocke les adresses IP clientes en
tant qu’emplacements familiers dans la table d’activité du compte.
Si l’authentification basée sur un mot de passe échoue et que les informations d’identification ne proviennent
pas d’un emplacement familier, le nombre d’authentifications qui ont échoué est incrémenté.
Une fois que le nombre d’échec des tentatives de mot de passe à partir d’emplacements inconnus a atteint le
seuil de verrouillage, si l’authentification basée sur un mot de passe à partir d’un emplacement inconnu échoue,
le compte est verrouillé.
NOTE
Le verrouillage continue de s’appliquer aux emplacements familiers séparément de ce nouveau compteur de verrouillage
inconnu.
Le seuil est fixé à l’aide Set-AdfsProperties de .

Exemple :
Set-AdfsProperties -ExtranetLockoutThreshold 10
Paramètre de la fenêtre Observation

Le paramètre de la fenêtre d’observation permet à un compte de se déverrouiller automatiquement après un
certain temps. Une fois le compte déverrouillé, une tentative d’authentification est autorisée. Si l’authentification
réussit, le nombre d’authentifications en échec est réinitialisé à 0. En cas d’échec, le système attend une autre
fenêtre d’observation avant que l’utilisateur puisse essayer à nouveau.
La fenêtre d’observation est définie à l’aide Set-AdfsProperties de l’exemple de commande suivant :
Set-AdfsProperties -ExtranetObservationWindow ( new-timespan -minutes 5 )
Activer le verrouillage
Le verrouillage extranet peut être activé ou désactivé à l’aide du paramètre EnableExtranetLockout, comme dans
les exemples suivants.
Pour activer le verrouillage, exécutez la commande suivante :
Set-AdfsProperties -EnableExtranetLockout $true
Pour désactiver le verrouillage, exécutez la commande suivante :
Set-AdfsProperties -EnableExtranetLockout $false
Activer le mode d’application

Une fois que vous êtes à l’aise avec le seuil de verrouillage et la fenêtre d’observation, ESL peut être déplacé en
mode « appliquer » à l’aide de l';;
Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce
Pour que le nouveau mode prenne effet, redémarrez le service AD FS sur tous les serveurs à l’aide de la
commande suivante :
Restart-service adfssrv
Gestion d’ESL
Gérer l’activité du compte d’utilisateur
AD FS fournit trois cmdlets pour gérer les données d’activité des comptes d’utilisateurs. Ces cmdlets se
connectent automatiquement au nœud de la batterie de serveurs qui détient le rôle principal.
NOTE
Ce comportement peut être overridden en passant le paramètre -Server.
Get-ADFSAccountActivity
Lire l’activité de compte actuelle pour un compte d’utilisateur. L’cmdlet se connecte toujours
automatiquement au maître de la batterie de serveurs à l’aide du point de terminaison REST activité de
compte. Par conséquent, toutes les données doivent toujours être cohérentes.
Get-ADFSAccountActivity user@contoso.com
Set-ADFSAccountActivity
Mettez à jour l’activité de compte pour un compte d’utilisateur. Cela permet d’ajouter de nouveaux
emplacements familiers ou d’effacer l’état pour n’importe quel compte.
Set-ADFSAccountActivityuser@contoso.com -FamiliarLocation "1.2.3.4"
Reset-ADFSAccountLockout
Réinitialise le compteur de verrouillage d’un compte d’utilisateur.
Reset-ADFSAccountLockoutuser@contoso.com -Familiar
Résolution des problèmes

Mise à jour des autorisations de base de données
Si des erreurs sont renvoyées à partir de la Update-AdfsArtifactDatabasePermission cmdlet, vérifiez les
informations suivantes :
La vérification échoue si les nodes sont sur la liste de la batterie de serveurs mais ne sont plus membres de
la batterie de serveurs. Cette situation peut être corrigée en cours remove-adfsnode <node name> d’exécution.
Vérifiez que la mise à jour est déployée sur tous les serveurs.
Vérifiez que les informations d’identification transmises à la cmdlet sont autorisées à modifier le propriétaire
du schéma de base de données d’artefacts AD FS.
Journalisation/audit
Lorsqu’une demande d’authentification est rejetée parce que le compte dépasse le seuil de verrouillage, AD FS
écrit un extranetLockoutEvent dans le flux d’audit de sécurité.
Exemple d’événement journalisé
Un événement de verrouillage extranet s’est produit. Pour plus d’informations sur l’échec, voir XML.
ID d’activité : 172332e1-1301-4e56-0e00-0080000000db
XML : <?xml version="1.0" encoding="utf-16"?> <AuditBase xmlns:xsd=" http://www.w3.org/2001/XMLSchema
" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " xsi:type="ExtranetLockoutAudit"> <AuditType>
ExtranetLockout</AuditType>
<AuditResult>Échec</AuditResult>
<FailureType>ExtranetLockoutError</FailureType>
<ErrorCode>AccountRestrictedAudit</ErrorCode>
<ContextComponents>
<Component xsi:type="ResourceAuditComponent">
<RelyingParty> http://contoso.com /adfs/services/trust</RelyingParty>
<ClaimsProvider>N/A</ClaimsProvider>
<UserId>TQDFTD\Administrator</UserId>
</Component>
<Component xsi:type="RequestAuditComponent">
<Server>N/A</Server>
<AuthProtocol>WSFederation</AuthProtocol>
<NetworkLocation>Intranet</NetworkLocation>
<IpAddress>4.4.4.4</IpAddress>
<ForwardedIpAddress />
<ProxyIpAddress>1.2.3.4</ProxyIpAddress>
<NetworkIpAddress>1.2.3.4</NetworkIpAddress>
<ProxyServer>N/A</ProxyServer>
<UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, comme
Gecko) Chrome/63.0.3239.132 Safari/537.36</UserAgentString>
<Endpoint>/adfs/ls</Endpoint>
</Component>
<Component xsi:type="LockoutConfigAuditComponent">
<CurrentBadPasswordCount>5</CurrentBadPasswordCount>
<ConfigBadPasswordCount>5</ConfigBadPasswordCount>
<LastBadAttempt>02/07/2018 21:47:44</LastBadAttempt>
<LockoutWindowConfig>00:30:00</LockoutWindowConfig>
</Component>
</ContextComponents>
</AuditBase>
Désinstaller
SQL Server batteries de serveurs de base de données peuvent désinstaller la mise à jour à l’aide
Paramètres’application sans problème.
Les batteries de serveurs de base de données WID doivent suivre ces étapes en raison du binaire de vérification
de base de données WID mis à jour :
1. Exécutez le script psh Deinstall qui arrête le service et abandonne la table d’activité du compte.
Stop-Service adfssrv -ErrorAction Stop

if ( -not $connString -like "*##wid*" )

{
Write-Error "SQL installs don't require DB updates, skipping DB table drop"
}
else
{
$connString = "Data Source=np:\\.\pipe\microsoft##wid\tsql\query;Initial
Catalog=AdfsArtifactStore;Integrated Security=True"
stop-service adfssrv
$cli.Open()
try
{
$cmd.CommandText = "IF EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[ArtifactStore].[AccountActivity]') AND type in (N'U')) DROP TABLE [ArtifactStore].
[AccountActivity]"
$cmd.ExecuteNonQuery()
}
finally
{
$cli.CLose()
} write-warning "Finish removing the patch using the Settings app and then restart the complete
to complete the uninstall"
}
2. Désinstallez la mise à jour à l’aide de l’application paramètres.

Considérations pour la désactivation et le
remplacement de TLS 1.0 dans AD FS
Cet article fournit des conseils et des considérations pour la désactivation et le remplacement de TLS 1.0 dans
les services AD FS (Active Directory Federation Services).
Résumé
De nombreux clients envisagent de désactiver les protocoles TLS 1.0 et RC4 dans AD FS et de le remplacer par
TLS 1.1 ou une version ultérieure. Cet article traite des problèmes qui peuvent se produire si vous désactivez
TLS 1.0 et fournit des conseils pour vous aider à terminer le processus.
Après avoir désactivé TLS 1.0 sur les serveurs proxy AD FS ou AD FS, ces serveurs peuvent être en mesure de
faire face à certains des symptômes suivants :
La connectivité entre un proxy AD FS et un serveur AD FS échoue. Cela peut entraîner l’une des
conditions suivantes :
La configuration du proxy échoue dans l’Assistant ou à l’aide Windows PowerShell.
L’ID d’événement 422 est enregistré sur les proxies AD FS :
Impossible de récupérer la configuration du proxy à partir du service de fédération.
Les proxys ne peuvent pas transmettre le trafic aux serveurs AD FS et le message d’erreur suivant
est généré :
Erreur HTTP 503 - Le service n’est pas disponible.
Les services AD FS ne peuvent pas mettre à jour les métadonnées de fédération des trusts de partie de
confiance ou des trusts de fournisseur de revendications configurées.
Vous recevez un message d’erreur HTTP 503 :
Le service n’est pas disponible. Accès HTTP 503 aux services Office 365 pour les domaines fédérés.
Vous recevez un message d’erreur RDP :
Connectivité RDP perdue pour les serveurs.
Cause
Ce problème se produit si les clients désactivent les anciens protocoles à l’aide des clés de Registre SChannel.
Pour obtenir un exemple de cette pratique, consultez la section Désactiver les anciens protocoles dans la section
registre.
Résolution
IMPORTANT
ADFS est développé à l’aide de Microsoft .NET Framework. Pour que les applications .NET soient en charge de la
cryptographie forte (c’est-à-dire, TLS 1.1 et version supérieure), vous devez d’abord installer les mises à jour
décrites dans l’avis de sécurité suivant : Conseil de sécurité Microsoft 2960358.
IMPORTANT
Les clients qui exécutent des applications .NET Framework 3.5 sur des applications Windows 10 ou .NET Framework
4.5/4.5.1/4.5.2 sur des systèmes sur qui .NET Framework 4.6 est installé doivent suivre les étapes fournies dans cet avis
pour désactiver manuellement RC4 dans TLS. Pour plus d’informations, voir la section Actions suggérées de l’avis.
NOTE
Les systèmes qui exécutent le .NET Framework 4.6 uniquement sont protégés par défaut et n’ont pas besoin d’être
mis à jour.
Les étapes supplémentaires de l’avis de sécurité nécessitent que vous créez la clé de Registre
SchUseStrongCr ypto, comme décrit dans l’article de conseil.
Exemples de sous-clés pour cette nouvelle clé de Registre :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. NETFramework\v2.0.50727]
SchUseStrongCrypto=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. NETFramework\v4.0.30319]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft. NETFramework\v4.0.30319]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft. NETFramework\v2.0.50727]
Pour appliquer la modification, vous devez redémarrer les applications et services suivants :
Service ADFS (adfssrv)
Device Registration Service (drs)
Toute autre application .NET qui peut être en cours d’exécution sur le serveur
Le pool Internet Information Services d’applications (IIS) pour ADFS (s’applique uniquement aux ADFS 2.0 et
ADFS 2.1)
IMPORTANT
Désactiver les anciens protocoles dans le Registre

Un exemple de désactivation d’anciens protocoles à l’aide de clés de Registre SChannel serait de configurer les
valeurs des sous-clés de Registre de la liste suivante. Ceux-ci désactivent les protocoles SSL 3.0, TLS 1.0 et RC4.
Étant donné que cette situation s’applique à SChannel, elle affecte toutes les connexions SSL/TLS vers et depuis
le serveur.
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0 » /f

reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL
3.0\Client » /f
3.0\Server » /f
3.0\Client » /v Enabled /t REG_DWORD /d 000000000
3.0\Server » /v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0 » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Client » /f
1.0\Server » /f
1.0\Client » /v Enabled /t REG_DWORD /d 000000000
1.0\Server » /v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128 »
/f
/v Enabled /t REG_DWORD /d 000000000
/f
/v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4
128/128 » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4
128/128 » /v Enabled /t REG_DWORD /d 000000000
NOTE
Vous devez redémarrer l’ordinateur après avoir changé ces valeurs.
Pour vérifier qu’un serveur connecté à Internet a correctement désactivé les anciens protocoles, vous pouvez
utiliser n’importe quel outil de vérification de test SSL en ligne, tel que Qualys SSL Labs. Pour plus
d’informations, voir SSL Server Test.
Solution alternative
Comme alternative à l’utilisation de la clé de Registre SchUseStrongCr ypto, vous pouvez utiliser la clé de
Registre SystemDefaultTlsVersions lorsque vous utilisez la .NET Framework 3.5.1.
SystemDefaultTlsVersions est disponible après l’installation de la mise à jour 3154518.
Une fois les clés de Registre définies, le service ADFS honore les valeurs par défaut de SChannel et fonctionne.
Effets secondaires connus

Voici quelques effets secondaires.
Les applications clientes ne peuvent pas se connecter au serveur ADFS ou au proxy ADFS pour
l’authentification
Lorsque vous désactivez TLS 1.0 et les versions antérieures sur les serveurs ADFS et les proxys, les applications
clientes qui tentent de s’y connecter doivent prendre en charge TLS 1.1 ou les versions ultérieures.
Cela est vrai, par exemple, pour Android Mobile 4.1.1 lorsque vous utilisez l’application Portail d'entreprise
Intune pour inscrire cet appareil. L’application Intune ne peut pas afficher la page de signature ADFS.
Ceci est attendu dans cette version Android, car TLS 1.1 est désactivé par défaut.
Vous pouvez obtenir plus de détails sur ces problèmes potentiels en collectant des suivis réseau sur le serveur
ou les proxys ADFS pendant que vous reproduisez l’échec de connexion. Dans ce scénario, vous pouvez
travailler avec le fournisseur de système d’exploitation client ou le fournisseur d’applications pour vérifier que
les versions TLS plus récentes sont pris en charge. Les ADFS ne peuvent pas mettre à jour les métadonnées de
fédération.
Scénario 1
Les services ADFS ne peuvent pas récupérer automatiquement le Federationmetadata.xml des trusts de
partie de confiance ou des trusts de fournisseur de revendications.
Lorsque vous essayez de mettre à jour le fichier XML manuellement, vous recevez le message d’erreur
suivant :
Une erreur s’est produite lors d’une tentative de lecture des métadonnées de fédération.
Sinon, vous recevez le message d’erreur suivant lorsque vous utilisez Windows PowerShell :
La connexion sous-jacente a été fermée. Une erreur inattendue s’est produite lors d’une réception.
En analysant plus attentivement l’exception sous-jacente, nous pouvons voir les informations suivantes :
PS C: > Update-AdfsRelyingPartyTrust -TargetName « Microsoft Office 365 Identity Platform »

Update-AdfsRelyingPartyTrust : la connexion sous-jacente a été fermée : une erreur inattendue s’est produite
lors d’une réception.
À line:1 char:1
+Update-AdfsRelyingPartyTrust -TargetName « Microsoft Office 365 identity platform ...+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Microsoft.Ident... relyingPartyTrust:RelyingPartyTrust) [Update-AdfsRelyingP
artyTrust], WebException
+ FullyQualifiedErrorId : La connexion sous-jacente a été fermée : une erreur inattendue s’est produite sur un
receive.,Microso ft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand
PS C: > $error[0] | fl * -f
writeErrorStream : True
PSMessageDetails :
Exception : System.Net.WebException : la connexion sous-jacente a été fermée : une erreur inattendue s’est
produite lors d’une réception. ---> System.ComponentModel.Win32Exception : le client et le serveur ne
peuvent pas communiquer, car ils ne possèdent pas d’algorithme commun
at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package,
CredentialUse intent, SecureCredential scc)
at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage,
SecureCredential& secureCredential)
at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint)
at System.Net.Security.SecureChannel.GenerateToken(Byte[] input, Int32 offset, Int32 count, Byte[]& output)
at System.Net.Security.SecureChannel.NextMessage(Byte[] incoming, Int32 offset, Int32 count)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest
asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer,
AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback
callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback,
Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback,
Object state)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.WriteHeaders(Boolean async)
--- fin de la trace de pile des exceptions internes ---
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.IdentityServer.Management.Resources.Managers.RelyingPartyTrustManager.ApplyMeta
dataFromUrl(RelyingPartyTrust party, Uri metadataUrl, String& warnings)
at Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand.OperateOnRely
ingPartyTrust(RelyingPartyTrust party)
at Microsoft.IdentityServer.Management.Commands.RemoveRelyingPartyTrustCommand.ProcessRecord()
TargetObject : Microsoft.IdentityServer.Management.Resources.RelyingPartyTrust
CategoryInfo : NotSpecified: (Microsoft.Ident... relyingPartyTrust:RelyingPartyTrust)
[Update-AdfsRelyingPartyTrust], WebException
FullyQualifiedErrorId : La connexion sous-jacente a été fermée : une erreur inattendue s’est produite sur un
receive.,Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand
ErrorDetails : la connexion sous-jacente a été fermée : une erreur inattendue s’est produite lors d’une
réception. InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock> , <No file> : line 1
PipelineIterationInfo : {0, 1}
Lorsque nous analysons les traces réseau, nous ne voyons aucun ClientHello. En outre, le client lui-même (ADFS)
ferme la connexion (TCP FIN) lorsque nous nous attendions à ce qu’il envoie le ClientHello :
3794 <DateTime> 4.0967400 (4588) adfs1 nexus.microsoftonline-p.com.nsatc.net TCP 8192 TCP: [Bad
CheckSum]Flags=CE.... S., SrcPort=56156, DstPort=HTTPS(443)
4013 <DateTime> 4.1983176 (0) nexus.microsoftonline-p.com.nsatc.net Adfs1 TCP 2097152 TCP:Flags=... A..
S., SrcPort=HTTPS(443), DstPort=56156
CheckSum]Flags=... A...., SrcPort=56156, DstPort=HTTPS(443)
CheckSum]Flags=... A... F, SrcPort=56156, DstPort=HTTPS(443)
4057 <DateTime> 4.2999711 (0) nexus.microsoftonline-p.com.nsatc.net adfs1 TCP 0 TCP:Flags=...
A.R.,SrcPort=HTTPS(443), DstPort=56156
En effet, les clés de Registre SChannel ont été créées. Celles-ci suppriment la prise en charge de SSL 3.0 ou TLS
1.0 en tant que client.
Toutefois, la clé SchUseStrongCr ypto n’a pas été créée. Ainsi, après avoir établi la session TCP/IP, le
ClientHello doit être envoyé en ayant les conditions suivantes :
.NET à l’aide d’un chiffrement faible (uniquement TLS 1.0 et versions antérieures)
SChannel configuré pour utiliser uniquement TLS 1.1 ou versions ultérieures
Résolution : appliquez SchUseStrongCrypto et redémarrez.
HTTP 503 dans l’accès Office 365 services
Scénario 2
Seuls TLS 1.1 et versions ultérieures sont pris en charge dans le service ADFSOffice.
Vous avez un domaine fédéré O365.
Le client accède à un service O365 qui utilise la proxiedauthentication : l’application cliente a envoyé les
informations d’identification à l’aide de HTTP Basic, et le service O365 utilise ces informations d’identification
dans une nouvelle connexion à ADFS pour authentifier l’utilisateur.
Le service cloud envoie un TLS 1.0 à ADFS et ADFS ferme la connexion.
Le client reçoit une réponse HTTP 503.
Par exemple, cela est vrai lorsque vous accédez à la découverte automatique. Dans ce scénario, Outlook clients
sont affectés. Cela peut être facilement reproduit en ouvrant un navigateur web et en allant à
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover .
xmlRequest envoyé :
GET https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml HTTP/1.1

Hôte : autodiscover-s.outlook.com
Agent utilisateur : Mozilla/5.0 (Windows NT 10.0 ; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept : text/html,application/xhtml+xml,application/xml;q=0.9, / ;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connexion : maintenir la vie
Autorisation : de base (SUPPRIMÉE POUR CONFIDENTIALITÉ)
Réponse reçue de Exchange Online service :
HTTP/1.1 Service 503 indisponible

Cache-Control: private
Retry-After: 30
Serveur : Microsoft-IIS/8.0
request-id: 33c23dc6-2359-44a5-a819-03f3f8e85aae
X-CalculatedBETarget: db4pr04mb394.eurprd04.prod.outlook.com
X-AutoDiscovery-Error: LiveIdBasicAuth:FederatedStsUnreachable: <X-forwarded-for:*<IP Address> >
<FederatedSTSFailure> System.Net.WebException: The underlying connection was closed: An unexpected
error occurred on a send.; X-DiagInfo : DB4PR04MB394 X-BEServer : DB4PR04MB394 X-AspNet-Version :
4.0.30319 Set-Cookie: X-BackEndCookie2=; expires= <DateTime> ; path=/Autodiscover; secure; HttpOnly
Set-Cookie: X-BackEndCookie=; expires= <DateTime> *; path=/Autodiscover; secure; HttpOnly
X-Powered-By: ASP.NET
X-FEServer : AM3PR05CA0056
Date : <DateTime>
Content-Length: 0
En analysant les traces réseau dans le serveur WAP, nous pouvons voir plusieurs connexions provenant de notre
cloud, comme suit. WaP met fin à ces connexions (TCP RST) peu de temps après la réception du Client Hello.
3282 <DateTime> 10.8024332 (0) 132.245.225.68 62047 (0xF25F) 10.10.1.5 443 (0x1BB) TCP 52 (0x34) 32
8192 TCP:Flags=CE.... S., SrcPort=62047, DstPort=HTTPS(443), PayloadLen=0, Seq=1681718623, Ack=0,
Win=8192 ( Facteur d’échelle de négociation 0x8 ) = 8192
3285 <DateTime> 10.8025263 (0) 10.10.1.5 443 (0x1BB) 132.245.225.68 62047 (0xF25F) TCP 52 (0x34) 32
8192 TCP: [Bad CheckSum]Flags=. E.A.. S., SrcPort=HTTPS(443), DstPort=62047, PayloadLen=0,
Seq=3949992650, Ack=1681718624, Win=8192 ( Facteur d’échelle négocié 0x8 ) = 8192
3286 <DateTime> 10.8239153 (0) 132.245.225.68 62047 (0xF25F) 10.10.1.5 443 (0x1BB) TCP 40 (0x28) 20
517 TCP:Flags=... A...., SrcPort=62047, DstPort=HTTPS(443), PayloadLen=0, Seq=1681718624,
Ack=3949992651, Win=517
3293 <DateTime> 10.8244384 (0) 132.245.225.68 62047 (0xF25F) 10.10.1.5 443 (0x1BB) TLS 156 (0x9C)
136 517 TLS:TLS Rec Layer-1 HandShake: Client Hello.
3300 <DateTime> 10.8246757 (4) 10.10.1.5 443 (0x1BB) 132.245.225.68 62047 (0xF25F) TCP 40 (0x28) 20
0 TCP: [Bad CheckSum]Flags=... A.R.,SrcPort=HTTPS(443), DstPort=62047, PayloadLen=0,
Seq=3949992651, Ack=1681718740, Win=0 (facteur d’échelle 0x0) = 0
Nous voyons également que Client Hello utilise TLS 1.0 :
Frame: Number = 3293, Captured Frame Length = 271, MediaType = NetEvent

+ NetEvent :
+ MicrosoftWindowsNDISPacketCapture : Fragment de paquet (170 (0xAA) octets)
+ Ethernet : Etype = Internet IP (IPv4),DestinationAddress:[00-0D-3A-24-43-98],SourceAddress:[12-34-56-
78-9A-BC]
+ Ipv4 : Src = <IP Address> , Dest = <IP Address> , Next Protocol = TCP, Packet ID = 31775, Longueur IP
totale = 156
+ Tcp: Flags=... AP..., SrcPort=62047, DstPort=HTTPS(443), PayloadLen=116, Seq=1681718624 -
1681718740, Ack=3949992651, Win=517
TLSSSLData : Données de charge utile TLS (Transport Layer Security)
- TLS : TLS Rec Layer-1 HandShake : Client Hello.
- TlsRecordLayer : TLS Rec Layer-1 HandShake :
ContentType: HandShake:
- Version : TLS 1.0
Major : 3 (0x3)
Mineure : 1 (0x1)
Longueur : 111 (0x6F)
- SSLHandshake : SSL HandShake ClientHello(0x01)
HandShakeType : ClientHello(0x01)
Longueur : 107 (0x6B)
- ClientHello : TLS 1.0
+ Version : TLS 1.0
+ RandomBytes :
SessionIDLength : 0 (0x0)
CipherSuitesLength : 14
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
+ TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
+ TLSCipherSuites : TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
+ TLSCipherSuites : TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
+ TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
+ TLSCipherSuites: TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }
+ TLSCipherSuites: TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }
CompressionMethodsLength : 1 (0x1)
CompressionMethods : 0 (0x0)
ExtensionsLength : 52 (0x34)
- ClientHelloExtension: Server Name(0x0000)
ExtensionType: Server Name(0x0000)
ExtensionLength : 19 (0x13)
NameListLength : 17 (0x11)
NameType : nom d’hôte (0)
NameLength : 14 (0xE)
ServerName : sts.contoso.net
+ ClientHelloExtension : Elliptic Curves(0x000A)
+ ClientHelloExtension : EC Point Formats(0x000B)
+ ClientHelloExtension : SessionTicket TLS(0x0023)
+ ClientHelloExtension : type d’extension inconnu
+ ClientHelloExtension: Renegotiation Info(0xFF01)
Dans ce scénario, il est prévu que le proxy ADFS rejette la connexion. This problem has been reported to
Exchange Online team and is under investigation.
Solutions de contournement :
Utiliser l’authentification moderne.
NOTE
Cela n’a pas été testé. Toutefois, d’un point de vue conceptuel, la connexion à ADFS est directement à partir de
l’application cliente. Par conséquent, elle doit fonctionner si elle prend en charge TLS 1.1.
Ré-activez le serveur TLS 1.0 dans le proxy WAP/ADFS.
Références
Norme de sécurité des données (DSS) d’industrie de carte de paiement (PCI)
Erreur lors de la configuration de WAP – « La connexion sous-jacente a été fermée » –Partie 2
produits.
Erreur « Échec de découverte de l’espace de travail
» avec le code de sortie 0x80072EE7
Cet article fournit une solution à une erreur 0x80072EE7 qui se produit lorsque les utilisateurs effectuent une
joint de l’espace de travail.
NOTE
Famille d’utilisateurs : cet article est destiné aux agents de support et aux professionnels de l’informatique, et non aux
utilisateurs à domicile. Pour obtenir de meilleurs résultats de recherche, modifiez vos mots clés de recherche pour inclure
le produit qui déclenche l’erreur et le code d’erreur.
Symptômes
Lorsque les utilisateurs tentent d’effectuer une joint de l’espace de travail, ils reçoivent le message d’erreur
suivant :
Confirmez que vous utilisez les informations de connectez-vous actuelles et que votre lieu de travail utilise
cette fonctionnalité. En outre, la connexion à votre espace de travail peut ne pas fonctionner pour le
moment. Patientez et recommencez.
En outre, un administrateur peut voir les détails de l’événement suivants dans l’Observateur d’événements :
Nom du journal : Microsoft-Windows-Workplace Join/Admin
Source : Microsoft-Windows-Workplace Join
Niveau : Error
Description :
Échec de la découverte de l’espace de travail.
Code de sortie : 0x80072EE7.
Le nom ou l’adresse du serveur n’a pas pu être résolu. Impossible de se connecter à
https://EnterpriseRegistration.domainTEST.com:443/EnrollmentServer/contract?api-version=1.0 .
Cause
Ce problème se produit si l’une des conditions suivantes est vraie :
L’utilisateur actuellement signé est issu d’un domaine qui ne contient pas d’enregistrement DNS pour le
service DRS.
Un utilisateur qui possède un suffixe de nom d’utilisateur principal (UPN) qui utilise le domaine initial (par
exemple) et qui n’est pas encore activé en tant qu’autorité de gestion des appareils mobiles via Microsoft
Intune pour la gestion des appareils mobiles dans Office 365 tente d’effectuer une jointur de l’espace de
joe@contoso.onmicrosoft.com travail.
Résolution
Vérifier le DNS
1. Vérifiez l’enregistrement CNAME EnterpriseRegistration pour le suffixe UPN du compte d’utilisateur. Il
s’agit de la partie après le caractère « @ », comme dans john@contoso.com .
2. Ouvrez une fenêtre d’invite de commandes, puis exécutez la commande suivante :
Nslookup enterpriseregistration.domain.com
Si vous utilisez Azure Active Directory Join

Les résultats doivent renvoyer le résultat CNAME de EnterpriseRegistration.windows.net.
Si vous utilisez Windows Server Workplace Join
L’hôte interne doit retourner le nœud ADFS interne.
L’hôte externe doit retourner le proxy ADFS externe (le cas présent).
Références
Pour plus d’informations sur la résolution des problèmes, voir l’article suivant dans la Base de connaissances
Microsoft :
3045377 journalisation des diagnostics pour la résolution des problèmes de jointage de l’espace de travail
Erreur lorsque vous utilisez la commande Set-
MsolADFSContext : Échec de la connexion au
serveur <ServerName> Active Directory Federation
Services 2.0
S’applique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Symptômes
Lorsque vous exécutez la commande dans le module Microsoft Azure Active Directory pour Windows
PowerShell, vous recevez Set-MsolADFSContext -Computer l’erreur suivante :
Set-MsolADFSContext : la connexion au serveur Active Directory Federation Services 2.0 a échoué en raison
<ServerName> d’informations d’identification non valides.
Cause
Cette erreur se produit si Remote PowerShell n’est pas activé sur le serveur de fédération AD FS (Active
Directory Federation Services) référencé par -computer le paramètre.
Lorsqu’un domaine est correctement ajouté et vérifié dans le portail, vous pouvez utiliser le module Azure
Active Directory pour Windows PowerShell pour configurer l' sign-on unique (SSO) à partir d’une station de
travail de gestion à l’aide de Remote PowerShell.
Toutefois, le module Azure Active Directory pour Windows PowerShell ne peut être installé que sur Windows 7
et Windows Server 2008 SR2. Le module Azure Active Directory pour Windows PowerShell ne peut pas être
installé sur Windows Server 2008 Service Pack 2 (SP2). Par conséquent, ce problème est particulièrement
pertinent lorsque les AD FS sont installés sur une plateforme Windows Server 2008 SP2. Dans ce cas, la
commande Azure Active Directory Module Windows PowerShell associée à AD FS doit être émise à partir d’un
ordinateur distant.
Résolution
Pour activer Remote PowerShell sur le serveur de fédération AD FS, suivez les étapes suivantes :
1. Commencez Windows PowerShell en tant qu’administrateur. Pour ce faire, cliquez avec le bouton droit
sur Windows PowerShell raccourci, puis sélectionnez Exécuter en tant qu’administrateur.
2. Pour configurer la Windows PowerShell pour la mise à la remoting, tapez la commande suivante, puis
appuyez sur Entrée :
Enable-PSRemoting -force
Pour plus d’informations sur les conditions requises pour Remote PowerShell, voir
About_Remote_Requirements.
Pour plus d’informations sur la fonctionnalité Remote PowerShell, voir Windows PowerShell: Dive Deep into
Remoting.
Encore besoin d’aide ? Accédez à la Communauté Microsoft ou au site Web Forums Azure Active Directory.
Erreur lors de l'Convert-MsolDomainToStandard
cmdlet : Échec de la connexion à Active Directory
Federation Services 2.0 sur l’ordinateur local
Cet article fournit une solution pour résoudre un problème dans lequel vous recevez l’erreur « Échec de la
connexion à Active Directory Federation Services 2.0 sur l’ordinateur local » lors de la conversion d’un domaine
fédéré en domaine géré à l’aide de la Convert-MsolDomainToStandard cmdlet.
Symptômes
Lorsque vous exécutez l’cmdlet pour convertir un domaine fédéré en domaine géré, vous recevez
Convert-MsolDomainToStandard le message d’erreur suivant :
Échec de la connexion à Active Directory Federation Services 2.0 sur l’ordinateur local.
Essayez d'Set-MsolADFSContect avant d’exécutez à nouveau cette commande.
Cause
Ce problème se produit si le serveur sur lequel vous exécutez la cmdlet n’exécute pas les
Convert-MsolDomainToStandard services AD FS (Active Directory Federation Services).
Résolution
Faites l’une des choses suivantes, selon votre situation :
Si AD FS est toujours en cours d’exécution, utilisez la cmdlet pour spécifier le serveur sur lequel
Set-MsolADFSContext AD FS est en cours d’exécution.
Par exemple :
Set-MsolADFSContext -Computer <ServerName>
Pour plus d’informations sur Set-MsolADFSContext cmdlet, voir Set-MsolADFSContext.

Si AD FS n’est pas en cours d’exécution, utilisez la cmdlet pour changer le domaine
Set-MsolDomainAuthentication en domaine géré.
Par exemple :
Set-MsolDomainAuthentication -DomainName <DomainName> -Authentication Managed
Pour plus d’informations sur Set-MsolDomainAuthentication cmdlet, voir Set-MsolDomainAuthentication.
Encore besoin d’aide ? Go to Microsoft Community or Azure Active Directory Forums website.
Comment restaurer IIS et nettoyer Active Directory
lorsque vous désinstallez Active Directory
Federation Services 2.0
Cet article explique comment restaurer Internet Information Services (IIS) et nettoyer Active Directory lorsque
vous désinstallez Active Directory Federation Services 2.0.
Introduction
L’Assistant Désinstallation des services AD FS 2.0 (AD FS 2.0) désinstalle AD FS 2.0 de votre ordinateur. Toutefois,
vous de devez toujours restaurer ou nettoyer manuellement les paramètres dans l’une des situations suivantes :
Lorsque vous désinstallez AD FS 2.0 d’un serveur de fédération ou d’un ordinateur proxy de serveur de
fédération, l’Assistant Désinstallation ne restaure pas IIS à son état d’origine.
Lorsque vous désinstallez AD FS 2.0 du dernier serveur de fédération ajouté dans une batterie de serveurs
de fédération, le processus de désinstallation ne supprime pas le conteneur de partage de certificats créé
dans Active Directory.
Si vous exécutez l’Assistant Configuration du serveur de fédération AD FS 2.0 après avoir réinstallé AD FS 2.0,
mais que vous n’avez pas nettoyé la configuration AD FS 2.0 précédente à partir d’IIS, vous pouvez voir l’un des
symptômes suivants :
La page Résultats de la configuration peut afficher le composant Déployer le site Web de configuration
du navigateur répertorié avec l’état Configuration terminée par des avertissements. Lorsque vous cliquez
sur l’état, vous pouvez voir l’avertissement suivant :
Site Web existant détecté. Par conséquent, le site Web n’a pas été réinstallé. Si vous essayez de
redéployer les sites Web AD FS 2.0 par défaut, voir pour
http://go.microsoft.com/fwlink/?LinkId=181110 plus d’informations.
La page Résultats de la configuration peut afficher le site Web de configuration de déploiement de

composant de navigateur répertorié avec l’état Configuration des composants... lorsque le message
d’erreur suivant s’affiche :
Impossible de copier les fichiers de site Web dans C: \ inetpub \ \ adfs ls, car le répertoire existe déjà.
Supprimez le répertoire et réexécutez l’Assistant Configuration ou mettez à jour le site Web existant
manuellement.
Vous pouvez utiliser les méthodes suivantes pour nettoyer ou restaurer la configuration d’origine :
Restaurer IIS sur un serveur de fédération ou un serveur proxy de

fédération
Lorsqu’AD FS 2.0 est installé sur un ordinateur configuré pour le serveur de fédération ou le rôle proxy de
serveur de fédération, il crée les répertoires virtuels /adfs et /adfs/ls dans IIS. AD FS 2.0 crée également un pool
d’applications nommé ADFSAppPool. Lorsque vous désinstallez AD FS 2.0 d’un serveur de fédération ou d’un
ordinateur proxy de serveur de fédération, ces répertoires virtuels ne sont pas supprimés. En outre, le pool
d’applications n’est pas supprimé. Cela peut créer des problèmes si AD FS 2.0 est installé à nouveau sur le même
ordinateur.
Pour supprimer manuellement ces répertoires du serveur de fédération désaffecté ou de l’ordinateur proxy du
serveur de fédération, suivez les étapes suivantes :
1. Cliquez sur Démarrer, sélectionnez Outils d’administration, puis sélectionnez Gestionnaire des
ser vices IiS.
2. Développez le nœud nom du serveur, développez Sites, puis sélectionnez Site Web par défaut.
3. Dans le volet Actions, sélectionnez Afficher les applications.
NOTE
Vous devriez voir les deux répertoires virtuels suivants associés à AD FS 2.0 :
/adfs
/adfs/ls
4. Cliquez avec le bouton droit sur l’application AD FS 2.0 qui se trouve dans chaque répertoire virtuel, puis
cliquez sur Supprimer.
5. Dans le volet Actions, sélectionnez Pools d’applications.
NOTE
Vous devriez voir un pool d’applications nommé ADFSAppPool.
6. Cliquez avec le bouton droit sur ADFSAppPool, puis sélectionnez Supprimer.
NOTE
Les deux étapes suivantes montrent comment supprimer le répertoire adfs du répertoire \ « inetpub ». Si vous
avez apporté des modifications personnalisées au contenu de ce répertoire, nous vous recommandons de le faire
à un autre emplacement avant de supprimer le répertoire.
7. Dans Windows’explorateur, accédez au répertoire « inetpub ». Ce répertoire se trouve dans le chemin

d’accès suivant :
%systemdrive% \ inetpub
8. Cliquez avec le bouton droit sur le répertoire Adfs, puis cliquez sur Supprimer.
Supprimer le conteneur de partage de certificats dans Active

Directory
Lorsque vous installez AD FS 2.0 et utilisez l’Assistant Configuration du serveur de fédération pour créer un
serveur de fédération dans une nouvelle batterie de serveurs de fédération, l’Assistant crée un conteneur de
partage de certificats dans Active Directory. Ce conteneur est utilisé par tous les serveurs de fédération de la
batterie de serveurs. Lorsque vous désinstallez AD FS 2.0 du dernier serveur de fédération ajouté dans une
batterie de serveurs, ce conteneur n’est pas supprimé d’Active Directory.
Pour supprimer manuellement ce conteneur dans Active Directory, suivez les étapes suivantes :
1. Avant de supprimer AD FS 2.0 du dernier serveur de fédération de la batterie de serveurs, exécutez les
commandes PowerShell suivantes sur le sts AD FS 2.0 pour déterminer l’emplacement du conteneur de
partage de certificats dans Active Directory :
Add-PsSnapin Microsoft.Adfs.Powershell
Get-AdfsProperties
2. Notez la propriété Cer tificateSharingContainer dans la sortie de l’étape précédente.

3. Connectez-vous à un serveur sur lequel l’outil ADSIEdit (ADSIEdit.msc) est installé.
4. Cliquez sur Démarrer, sur Exécuter, tapez ADSIEdit.msc, puis appuyez sur Entrée.
5. Dans l’outil ADSIEdit, connectez-vous au contexte d’attribution de noms par défaut en suivant les étapes
suivantes :
a. Cliquez avec le bouton droit sur ADSI Edit, puis cliquez sur Connecter à .
b. Sous Point de connexion, cliquez sur Sélectionner un contexte d’attribution de noms connu, puis
sélectionnez Contexte d’attribution de noms par défaut.
c. Cliquez sur OK .
6. Développez le nœud suivant :
Contexte d’attribution de noms par défaut, {votre par tition de domaine}, CN=Données de
programme, CN=Microsoft, CN=ADFS
NOTE
Sous CN=ADFS, vous voyez un conteneur nommé CN={GUID} pour chaque batterie de serveurs AD FS 2.0 que
vous avez déployée, où {GUID} correspond à la propriété Cer tificateSharingContainer que vous avez
capturée à l’aide de la commande PowerShell à l’étape Get-AdfsProperties 1.
7. Cliquez avec le bouton droit sur le conteneur {GUID} approprié, puis sélectionnez Supprimer.
Erreur ADFS 2.0 : l’accès est refusé
Cet article fournit une solution pour corriger l’erreur AD FS (Active Directory Federated Services) 2.0.
Résumé
La plupart des problèmes liés aux AD FS 2.0 appartiennent à l’une des principales catégories suivantes. Cet
article contient des instructions pas à pas pour résoudre les problèmes liés aux règles de revendications.
Symptômes
Le jeton émis par le service AD FS ne comprend pas les revendications appropriées pour autoriser l’accès
utilisateur à l’application.
Le serveur AD FS renvoie le message d’erreur suivant :
Accès refusé
Si vous activez l’audit AD FS à l’aide de la rubrique Configuration des serveurs ADFS pour la résolution
des problèmes, l’erreur suivante est consignée dans le journal des événements :
Le service de fédération n’a pas pu autoriser l’émission de jeton pour l’appelant.
Résolution
Pour résoudre ce problème, suivez ces étapes dans l’ordre donné. Ces étapes vous aideront à déterminer la
Étape 1 : Obtenir des détails sur les revendications requises
Déterminez les types de revendications requis dans le jeton SAML du propriétaire de la partie de confiance.
Déterminez le fournisseur de revendications utilisé pour authentifier l’utilisateur.
Par exemple :
Un fournisseur de partie de confiance peut indiquer qu’il souhaite que les valeurs de messagerie, de
nom et de rôle de l’utilisateur soient fournies.
Si le fournisseur de revendications dans cette situation est « Active Directory », vous devez configurer
une règle de revendication d’acceptation au niveau « Active Directory ».
NOTE
Si le fournisseur de revendications est un autre service d’jetons de sécurité (STS), nous devons créer une règle de
revendication pass Through ou Transform pour accepter les valeurs de revendication stockées dans les types de
revendications définis localement qui doivent être transmis à la partie de confiance.
Créez une revendication pass Through pour ces revendications au niveau de la partie de confiance.
Étape 2 : Vérifier si AD FS refuse le jeton en fonction des règles d’autorisation
Pour ce faire, cliquez avec le bouton droit sur la partie de confiance, cliquez sur Modifier les règles de
revendication, puis cliquez sur l’onglet Règles d’autorisation d’émission. Lorsque vous examinez les
informations des règles, prenons en compte les recommandations suivantes :
Toutes les règles de revendications d’autorisation sont traitées.
Si aucune règle n’est définie, le serveur AD FS refuse tous les utilisateurs.
L’approche allowlist peut également être utilisée au lieu d’utiliser une règle Autoriser tout. Dans ce cas, vous
définissez un ensemble de règles qui spécifient les conditions dans lesquelles l’utilisateur doit être émis un
jeton.
Dans l’approche de la liste de blocage, vous aurez besoin d’une règle Autoriser tout, ainsi que d’une ou de
plusieurs règles de refus basées sur une condition.
Une règle de refus remplace toujours une règle d’autoriser. Cela signifie que si les conditions de
revendication Autoriser et Refuser sont vraies pour l’utilisateur, la règle de refus sera suivie.
Pour que les règles d’autorisation basées sur d’autres valeurs de revendication autorisent ou refusent un
jeton, ces revendications doivent déjà être poussées dans le pipeline de revendications à partir du niveau de
confiance du fournisseur de revendications.
Étape 3 : Capturer un suivi Fiddler
Capturez un suivi du débogger Web Fiddler pour capturer la communication vers le service AD FS et déterminer
si un jeton SAML a été émis. Si un jeton SAML a été émis, décodez-le pour déterminer si l’ensemble correct de
revendications est émis.
Pour plus d’informations sur ce processus, voir AD FS 2.0: How to Use Fiddler Web Debugger to Analyze a WS-
Federation Passive Sign-In.
Pour rechercher le jeton SAML émis par le service AD FS :
Dans un suivi de fiddler, examinez la réponse d’AD FS pour déterminer où le service AD FS est en train de
définir les cookies MSISAuth et MSISAuthenticated. Vous pouvez également examiner la demande une fois
qu’AD FS a définit les cookies MSISAuth et MSISAuthenticated.
Sélectionnez le jeton, puis démarrez TextWizard dans Fiddler. Utilisez URLDecode pour un RSTR (WS-Fed) ou
FromDeflatedSAML pour une réponse de protocole SAML 2.0.
Étape 4 : Activer l’audit ADFS et vérifier si le jeton a été émis ou refusé, ainsi que la liste des revendications en
cours de traitement
Configurez les serveurs AD FS pour enregistrer l’audit des événements AD FS dans le journal de sécurité. Pour
configurer le journal Sécurité Windows pour prendre en charge l’audit des événements AD FS, suivez les étapes
suivantes :
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Stratégie de sécurité locale.
2. Double-cliquez sur Stratégies locales, puis cliquez sur Stratégie d’audit.
3. Dans le volet d’informations, double-cliquez sur Auditer l’accès aux objets.
4. Dans la page Propriétés d’accès à l’objet Audit, sélectionnez Réussite ou Échec ou les deux, puis cliquez
sur OK.
5. Fermez le logiciel en Paramètres sécurité locale.
6. À l’invite de commandes, tapez gpupdate /force, puis appuyez sur Entrée pour actualiser immédiatement la
stratégie locale.
Vous pouvez également utiliser l’GPO suivant pour configurer le Sécurité Windows journal :
Configuration ordinateur\Stratégies\Windows Paramètres\Sécurité Paramètres\Configuration avancée de la
stratégie d’audit\Stratégies d’audit\Accès aux objets\Application d’audit générée - Réussite et échec Configurer
ADFS
Cela est utile dans un scénario dans lequel AD FS a refusé un jeton à l’utilisateur. Le processus d’audit AD FS
signale l’événement et les revendications qui ont été générées avant le refus du jeton. Cela vous permet de
déterminer la revendication à l’origine de l’application de la règle de refus. Examinez en particulier le journal des
événements de sécurité pour les ID d’événement 299, 500, 501 et 325.
Étape 5 : Déterminer si vous avez besoin d’une revendication personnalisée
Si les exigences d’émission de revendications ne peuvent pas être remplies par les modèles de règle de
revendication par défaut, vous devrez peut-être écrire une revendication personnalisée. Pour plus
d’informations, voir Understanding Claim Rule Language in AD FS 2.0 & Higher.
produits.
Résoudre les problèmes AD FS dans Azure Active
Directory et Office 365
Cet article traite du dépannage des flux de travail pour les problèmes d’authentification pour les utilisateurs
fédérés dans Azure Active Directory ou Office 365.
Symptômes
Les utilisateurs fédérés ne peuvent pas se Office 365 ou Microsoft Azure même si les utilisateurs gérés dans
le cloud uniquement qui ont un suffixe UPN domainxx.onmicrosoft.com peuvent se connecter sans problème.
La redirection vers les services AD FS (Active Directory Federation Services) ou STS ne se produit pas pour
un utilisateur fédéré. Sinon, une erreur « La page ne peut pas être affichée » est déclenchée.
Vous recevez un avertissement lié au certificat sur un navigateur lorsque vous essayez de vous authentifier
auprès d’AD FS. Indique que la validation du certificat échoue ou que le certificat n’est pas approuvé.
Erreur ou erreur « Méthode d’th inconnue » indiquant qu’elle n’est AuthnContext pas prise en charge. En
outre, les erreurs au niveau AD FS ou STS lorsque vous êtes redirigé à partir de Office 365.
AD FS envoie une erreur « Accès refusé ».
AD FS envoie une erreur indiquant qu’il y a un problème d’accès au site . qui inclut un numéro d’ID de
référence.
L’utilisateur est invité à plusieurs reprises à obtenir des informations d’identification au niveau AD FS.
Les utilisateurs fédérés ne peuvent pas s’authentifier à partir d’un réseau externe ou lorsqu’ils utilisent une
application qui utilise l’itinéraire réseau externe (Outlook, par exemple).
Les utilisateurs fédérés ne peuvent pas se connecter après la changement d’un certificat de signature de
jetons sur AD FS.
Une erreur « Désolé, mais nous avons des difficultés pour vous mettre en communication » est déclenchée
lorsqu’un utilisateur fédéré se Office 365 dans Microsoft Azure. Cette erreur inclut des codes d’erreur tels que
8004786C, 80041034, 80041317, 80043431, 80048163, 80045C06, 8004789A ou une demande BAD.
Résolution des problèmes de flux de travail

1. Accédez Microsoft Office Home, puis entrez le nom de la signature de l’utilisateur fédéré
(someoneexample @.com ). Après avoir appuyez sur l’onglet pour supprimer le focus de la zone de
connexion, vérifiez si l’état de la page passe à Redirection , puis vous êtes redirigé vers votre service AD
FS (Active Directory Federation Service) pour vous connecter.
Lorsque la redirection se produit, vous voyez la page suivante :
a. Si aucune redirection ne se produit et que vous êtes invité à entrer un mot de passe sur la même
page, ce qui signifie que Azure Active Directory (AD) ou Office 365 ne reconnaît pas l’utilisateur ou
le domaine de l’utilisateur à fédéré. Pour vérifier s’il existe une confiance de fédération entre Azure
AD ou Office 365 et votre serveur AD FS, Get-msoldomain exécutez l’cmdlet à partir de Azure AD
PowerShell. Si un domaine est fédéré, sa propriété d’authentification s’affiche sous la forme
Fédéré , comme dans la capture d’écran suivante :
b. Si la redirection se produit, mais que vous n’êtes pas redirigé vers votre serveur AD FS pour la
connexion, vérifiez si le nom du service AD FS est résolu sur l’adresse IP correcte et s’il peut se
connecter à cette adresse IP sur le port TCP 443.
Si le domaine est affiché comme fédéré , obtenez des informations sur l’autorisation de fédération
en exécutant les commandes suivantes :
Get-MsolFederationProperty -DomainName <domain>

Get-MsolDomainFederationSettings -DomainName <domain>
Vérifiez l’URI, l’URL et le certificat du partenaire de fédération configuré par Office 365 ou Azure
AD.
2. Une fois redirigé vers AD FS, le navigateur peut créer une erreur liée à l’autorisation de certificat et, pour
certains clients et appareils, il peut ne pas vous laisser établir une session SSL (Secure Sockets Layer)
avec AD FS. Pour résoudre ce problème, suivez les étapes suivantes :
a. Assurez-vous que le certificat de communication du service AD FS présenté au client est le même
que celui configuré sur AD FS.
Dans l’idéal, le certificat de communication du service AD FS doit être identique au certificat SSL
présenté au client lorsqu’il tente d’établir un tunnel SSL avec le service AD FS.
Dans AD FS 2.0 :
Lier le certificat à IIS->premier site par défaut.
Utilisez le logiciel en snap-in AD FS pour ajouter le même certificat que le certificat de
communication de service.
Dans AD FS 2012 R2 :
Utilisez le logiciel en snap-in AD FS ou la commande Add-adfscertificate pour ajouter un
certificat de communication de service.
Utilisez la Set-adfssslcertificate commande pour définir le même certificat pour la liaison
SSL.
b. Assurez-vous que le certificat de communication du service AD FS est approuvé par le client.
c. Si des clients non SNI tentent d’établir une session SSL avec AD FS ou WAP 2-12 R2, la tentative
peut échouer. Dans ce cas, envisagez d’ajouter une entrée de retour sur les serveurs AD FS ou WAP
pour prendre en charge les clients non-SNI. Pour plus d’informations, voir Comment prendre en
charge les clients non SNI avec le proxy d’application web et AD FS 2012 R2.
3. AuthnContext Vous pouvez rencontrer une erreur « Méthode d’th inconnue » ou des erreurs indiquant
qu’elle n’est pas prise en charge au niveau AD FS ou STS lorsque vous êtes redirigé à partir de Office 365.
Il est plus courant lorsque vous redirigez vers AD FS ou STS à l’aide d’un paramètre qui applique une
méthode d’authentification. Pour appliquer une méthode d’authentification, utilisez l’une des méthodes
suivantes :
Pour WS-Federation, utilisez une chaîne de requête WAUTH pour forcer une méthode
d’authentification préférée.
Pour SAML2.0, utilisez ce qui suit :
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
Lorsque la méthode d’authentification appliquée est envoyée avec une valeur incorrecte ou si cette
méthode d’authentification n’est pas prise en charge sur AD FS ou STS, vous recevez un message d’erreur
avant d’être authentifié.
Le tableau suivant présente les AUTHENTIFICATIONs de type d’authentification reconnues par AD FS pour
lWS-Federation passive.
M ÉT H O DE D’A UT H EN T IF IC AT IO N REC H ERC H ÉE URI WA UT H
Authentification par nom d’utilisateur et mot de passe urn:oasis:names:tc:SAML:1.0:am:password
Authentification du client SSL urn:ietf:rfc:2246
Windows’authentification intégrée urn:federation:authentication:windows
Classes de contexte d’authentification SAML prise en charge

M ÉT H O DES D'A UT H EN T IF IC AT IO N URI DE C L A SSE DE C O N T EXT E D’A UT H EN T IF IC AT IO N
Nom d'utilisateur et mot de passe urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Transport protégé par mot de passe urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtecte

dTransport
Client TLS (Transport Layer Security) urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
Certificat X.509 urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Authentification Windows intégrée urn:federation:authentication:windows
Kerberos urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
Pour vous assurer que la méthode d’authentification est prise en charge au niveau AD FS, vérifiez ce qui
suit.
AD FS 2.0
Sous /adfs/ls/web.config, assurez-vous que l’entrée du type d’authentification est présente.
<microsoft.identityServer.web>
<localAuthenticationTypes>
< add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>
AD FS 2.0 : Comment modifier le type d’authentification local

AD FS 2012 R2
a. Sous Gestion AD FS, sélectionnez Stratégies d’authentification dans le logiciel en ligne AD FS.
b. Dans la section Authentification principale, sélectionnez Modifier en Paramètres . Vous pouvez
également cliquer avec le bouton droit sur Stratégies d’authentification , puis sélectionner
Modifier l’authentification principale globale . Ou, dans le volet Actions , sélectionnez
Modifier l’authentification principale globale .
c. Dans la fenêtre Modifier la stratégie d’authentification globale, sous l’onglet Principal, vous
pouvez configurer les paramètres dans le cadre de la stratégie d’authentification globale. Par
exemple, pour l’authentification principale, vous pouvez sélectionner les méthodes
d’authentification disponibles sous Extranet et Intranet .
Assurez-vous que la case à cocher de la méthode d’authentification requise est sélectionnée.
4. Si vous arrivez à vos AD FS et entrez vos informations d’identification, mais que vous ne pouvez pas être
authentifié, recherchez les problèmes suivants.
a. Problème de réplication Active Directory
Si la réplication AD est rompue, les modifications apportées à l’utilisateur ou au groupe peuvent
ne pas être synchronisées entre les contrôleurs de domaine. Entre les contrôleurs de domaine, il
peut y avoir une insériorité de mot de passe, UPN, GroupMembership ou Proxyaddress qui affecte
la réponse AD FS (authentification et revendications). Vous devez commencer à regarder les
contrôleurs de domaine sur le même site qu’AD FS. L’exécution repadmin /showreps d’une
DCdiag /v ou d’une commande doit révéler s’il existe un problème sur les contrôleurs de
domaine que les AD FS sont les plus susceptibles de contacter.
Vous pouvez également collecter un résumé de réplication AD pour vous assurer que les
modifications AD sont répliquées correctement sur tous les contrôleurs de domaine. La sortie
repadmin /showrepl * /csv > showrepl.csv est utile pour vérifier l’état de la réplication. Pour plus
d’informations, voir Résolution des problèmes de réplication Active Directory.
b. Compte verrouillé ou désactivé dans Active Directory
Lorsqu’un utilisateur final est authentifié via AD FS, il ne reçoit pas de message d’erreur indiquant
que le compte est verrouillé ou désactivé. À partir d’AD FS et de l’audit d’authentification, vous
devez être en mesure de déterminer si l’authentification a échoué en raison d’un mot de passe
incorrect, si le compte est désactivé ou verrouillé, etc.
Pour activer AD FS et l’audit d’accès sur les serveurs AD FS, suivez les étapes suivantes :
a. Utilisez une stratégie locale ou de domaine pour activer la réussite et l’échec pour les
stratégies suivantes :
Événement d’audit d’une logon, situé dans
Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
Auditer l’accès aux objets, situé dans

Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
b. Désactivez la stratégie suivante :

Audit : forcer les paramètres de sous-catégorie de stratégie d’audit (Windows Vista ou
ultérieur) à remplacer les paramètres de catégorie de stratégie d’audit
Cette stratégie se trouve dans
Computer configuration\Windows Settings\Security setting\Local Policy\Security Option .
Si vous souhaitez la configurer à l’aide d’un audit avancé, voir Configuring Computers for
Troubleshooting AD FS 2.0.
c. Configurez AD FS pour l’audit :
a. Ouvrez le logiciel en snap-in AD FS 2.0 Management.
b. Dans le volet Actions , sélectionnez Modifier les propriétés du ser vice de
fédération .
c. Dans la boîte de dialogue Propriétés du ser vice de fédération, sélectionnez
l’onglet Événements .
d. Cochez les cases Audits de réussite et Échecs .
e. S’exécute GPupdate /force sur le serveur.

c. Le nom principal de service (SPN) est enregistré de manière incorrecte
Il peut y avoir des SPN en double ou un SPN enregistré sous un compte autre que le compte de
service AD FS. Pour une configuration de batterie de serveurs AD FS, assurez-vous que SPN
HOST/AD FSservicename est ajouté sous le compte de service qui exécute le service AD FS. Pour
une configuration AD FS autonome, où le service est en cours d’exécution sous Service réseau, le
nom principal de service doit se trouver sous le compte d’ordinateur serveur qui héberge AD FS.
Assurez-vous qu’il n’existe pas de SDN en double pour le service AD FS, car cela peut entraîner des
échecs d’authentification intermittents avec AD FS. Pour lister les SNS, exécutez
SETSPN -L <ServiceAccount> .
Exécutez SETSPN -A HOST/AD FSservicename ServiceAccount pour ajouter le SPN.

Exécutez SETSPN -X -F cette recherche pour vérifier les SNS dupliqués.
d. UpNs dupliqués dans Active Directory
Un utilisateur peut être en mesure de s’authentifier via AD FS lorsqu’il utilise SAMAccountName,
mais ne peut pas s’authentifier lors de l’utilisation d’UPN. Dans ce scénario, Active Directory peut
contenir deux utilisateurs qui ont le même UPN. Il est possible de finir avec deux utilisateurs qui
ont le même UPN lorsque les utilisateurs sont ajoutés et modifiés par le biais de scripts (ADSIedit,
par exemple).
Lorsque l’UPN est utilisé pour l’authentification dans ce scénario, l’utilisateur est authentifié par
rapport à l’utilisateur en double. Les informations d’identification fournies ne sont donc pas
validées.
Vous pouvez utiliser des requêtes telles que les suivantes pour vérifier si plusieurs objets dans AD
ont les mêmes valeurs pour un attribut :
Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN
Assurez-vous que l’UPN de l’utilisateur en double est renommé, afin que la demande
d’authentification auprès de l’UPN soit validée par rapport aux objets corrects.
e. Dans un scénario où vous utilisez votre adresse de messagerie comme ID de connexion dans
Office 365 et que vous entrez la même adresse de messagerie lorsque vous êtes redirigé vers AD
FS pour l’authentification, l’authentification peut échouer avec une erreur « NO_SUCH_USER »
dans les journaux d’audit. Pour permettre aux AD FS de rechercher un utilisateur pour
l’authentification à l’aide d’un attribut autre que UPN ou SAMaccountname, vous devez configurer
AD FS pour prendre en charge un autre ID de connexion. Pour plus d’informations, voir
Configuring Alternate Login ID.
Sur AD FS 2012 R2
a. Installez update 2919355.
b. Mettez à jour la configuration AD FS en exécutant l’applet de commande PowerShell
suivante sur l’un des serveurs de fédération de votre batterie de serveurs (si vous avez une
batterie WID, vous devez exécuter cette commande sur le serveur AD FS principal de votre
batterie de serveurs) :
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID

<attribute> -LookupForests <forest domain>
NOTE
AlternateLoginID est le nom LDAP de l’attribut que vous souhaitez utiliser pour la connexion. Et
LookupForests est la liste des entrées DNS de forêts à qui appartiennent vos utilisateurs.
Pour activer la fonctionnalité d’ID de connexion de remplacement, vous devez configurer les
paramètres AlternateLoginID et LookupForests avec une valeur valide non null.
f. Le compte de service AD FS n’a pas accès en lecture au jeton AD FS qui signe la clé privée du
certificat. Pour ajouter cette autorisation, suivez les étapes suivantes :
a. Lorsque vous ajoutez un nouveau certificat Token-Signing, vous recevez l’avertissement
suivant :
Assurez-vous que la clé privée du certificat choisi est accessible au compte de service
pour ce service de fédération sur chaque serveur de la batterie de serveurs.
b. Sélectionnez Démarrer , Exécuter , tapez mmc.exe, puis appuyez sur Entrée.

c. Sélectionnez Fichier , puis ajouter /supprimer un logiciel en snap-in .
d. Double-cliquez sur Cer tificats .
e. Sélectionnez le compte d’ordinateur en question, puis sélectionnez Suivant .
f. Sélectionnez Ordinateur local , puis Terminer .
g. Développez Cer tificats (ordinateur local), développez Persona l, puis sélectionnez
Cer tificats .
h. Cliquez avec le bouton droit sur votre nouveau certificat de signature de jetons,
sélectionnez Toutes les tâches, puis sélectionnez Gérer les clés privées .
i. Ajoutez un accès en lecture pour votre compte de service AD FS 2.0, puis sélectionnez OK .
j. Fermez la MMC Certificats.
g. L’option Protection étendue pour Windows’authentification est activée pour le répertoire
virtuel AD FS ou LS. Cela peut entraîner des problèmes avec des navigateurs spécifiques. Parfois,
les services AD FS vous invitent à plusieurs reprises à obtenir des informations d’identification, et
cela peut être lié au paramètre protection étendue activé pour l’authentification Windows pour les
services AD FS ou l’application LS dans IIS.
Lorsque la protection étendue de l’authentification est activée, les demandes d’authentification

sont liées à la fois aux noms principaux de service (SNS) du serveur auquel le client tente de se
connecter et au canal TLS (Transport Layer Security) externe sur lequel l’authentification Windows
intégrée se produit. La protection étendue améliore la fonctionnalité d’authentification Windows
existante pour atténuer les relais d’authentification ou les attaques « de l’intermédiaire ». Toutefois,
certains navigateurs ne fonctionnent pas avec le paramètre protection étendue ; au lieu de cela, ils
invitent à plusieurs reprises à obtenir des informations d’identification, puis refusent l’accès. La
désactivation de la protection étendue est utile dans ce scénario.
Pour plus d’informations, voir AD FS 2.0: Continuously Prompted for Credentials While Using
Fiddler Web Debugger.
Pour AD FS 2012 R2
Exécutez l’cmdlet suivante pour désactiver la protection étendue :
Set-ADFSProperties -ExtendedProtectionTokenCheck None
h. Les règles d’autorisation d’émission dans l’approbation de partie de confiance (RP) peuvent
refuser l’accès aux utilisateurs. Dans l’approbation de partie de confiance AD FS, vous pouvez
configurer les règles d’autorisation d’émission qui contrôlent si un utilisateur authentifié doit être
émis un jeton pour une partie de confiance. Les administrateurs peuvent utiliser les revendications
émises pour décider s’il faut refuser l’accès à un utilisateur membre d’un groupe qui est tiré en
tant que revendication.
Si certains utilisateurs fédérés ne peuvent pas s’authentifier via AD FS, vous voudrez peut-être
vérifier les règles d’autorisation d’émission pour le rp Office 365 et voir si la règle Autoriser l’accès
à tous les utilisateurs est configurée.
Si cette règle n’est pas configurée, consultez les règles d’autorisation personnalisées pour vérifier
si la condition de cette règle est « true » pour l’utilisateur concerné. Pour plus d’informations,
reportez-vous aux ressources suivantes :
Understanding Claim Rule Language in AD FS 2.0 & Higher
Configuration des stratégies d’accès client
Limitation de l’accès Office 365 Services en fonction de l’emplacement du client
Si vous pouvez vous authentifier à partir d’un intranet lorsque vous accédez directement au
serveur AD FS, mais que vous ne pouvez pas vous authentifier lorsque vous accédez à AD FS via
un proxy AD FS, recherchez les problèmes suivants :
Problème de synchronisation de l’heure sur le serveur AD FS et le proxy AD FS
Assurez-vous que l’heure sur le serveur AD FS et l’heure sur le proxy sont synchronisées.
Lorsque le temps sur le serveur AD FS est éteint de plus de cinq minutes à partir du temps
sur les contrôleurs de domaine, des échecs d’authentification se produisent. Lorsque l’heure
sur le proxy AD FS n’est pas synchronisée avec AD FS, l’confiance du proxy est affectée et
rompue. Ainsi, une demande qui passe par le proxy AD FS échoue.
Vérifiez si l’confiance de proxy AD FS avec le service AD FS fonctionne correctement.
Réexécutez la configuration du proxy si vous pensez que l’confiance du proxy est rompue.
5. Une fois que votre AD FS a émis un jeton, Azure AD ou Office 365 une erreur. Dans ce cas, recherchez les
problèmes suivants :
Les revendications émises par AD FS dans le jeton doivent correspondre aux attributs respectifs de
l’utilisateur dans Azure AD. Dans le jeton Azure AD ou Office 365, les revendications suivantes sont
requises.
WSFED :
UPN : la valeur de cette revendication doit correspondre à l’UPN des utilisateurs dans Azure AD.
ImmutableID : la valeur de cette revendication doit correspondre à la sourceAnchor ou
ImmutableID de l’utilisateur dans Azure AD.
Pour obtenir la valeur d’attribut User Azure AD, exécutez la ligne de commande suivante :
Get-MsolUser -UserPrincipalName <UPN>
SAML 2.0 :
IDPEmail : la valeur de cette revendication doit correspondre au nom d’utilisateur principal des
utilisateurs dans Azure AD.
NAMEID : la valeur de cette revendication doit correspondre à la sourceAnchor ou ImmutableID de
l’utilisateur dans Azure AD.
Pour plus d’informations, voir Utiliser un fournisseur d’identité SAML 2.0 pour implémenter l’sign-
on unique.
Exemples :
Ce problème peut se produire lorsque l’UPN d’un utilisateur synchronisé est modifié dans AD,
mais sans mettre à jour l’annuaire en ligne. Dans ce scénario, vous pouvez corriger l’UPN de
l’utilisateur dans AD (pour correspondre au nom de l’utilisateur associé) ou exécuter l’cmdlet
suivante pour modifier le nom de l’utilisateur associé dans l’annuaire en ligne :
Set-MsolUserPrincipalName -UserPrincipalName [ExistingUPN] -NewUserPrincipalName [DomainUPN-

AD]
Il se peut également que vous utilisiez AADsync pour synchroniser MAIL en tant qu’UPN et EMPID
en tant que SourceAnchor, mais les règles de revendication de partie de confiance au niveau AD FS
n’ont pas été mises à jour pour envoyer LE COURRIER en tant qu’UPN et EMPID en tant
qu’ImmutableID.
Il existe une non-distinction entre les certificats de signature de jetons entre AD FS et Office 365.
Il s’agit de l’un des problèmes les plus courants. AD FS utilise le certificat de signature de jetons
pour signer le jeton envoyé à l’utilisateur ou à l’application. L’autorisation entre les services AD FS
et Office 365 est une confiance fédérée basée sur ce certificat de signature de jetons (par exemple,
Office 365 vérifie que le jeton reçu est signé à l’aide d’un certificat de signature de jetons du
fournisseur de revendications [le service AD FS] qu’il a confiance).
Toutefois, si le certificat de signature de jetons sur les AD FS est modifié en raison du rollover
automatique des certificats ou de l’intervention d’un administrateur (après ou avant l’expiration du
certificat), les détails du nouveau certificat doivent être mis à jour sur le client Office 365 pour le
domaine fédéré. Il se peut que cela ne se produise pas automatiquement . cela peut nécessiter
l’intervention d’un administrateur. Lorsque le certificat de signature de jetons principal sur AD FS
est différent de ce que Office 365 connaît, le jeton émis par AD FS n’est pas approuvé par Office
365. L’utilisateur fédéré n’est donc pas autorisé à se connecter.
Office 365 ou Azure AD tenteront d’accéder au service AD FS, en supposant que le service est
accessible sur le réseau public. Nous essayons d’sonder les métadonnées de fédération AD FS à
intervalles réguliers pour obtenir les modifications de configuration sur AD FS, principalement les
informations de certificat de signature de jetons. Si ce processus ne fonctionne pas,
l’administrateur général doit recevoir un avertissement sur le portail Office 365 concernant
l’expiration du certificat de signature de jetons et les actions nécessaires pour le mettre à jour.
Vous pouvez utiliser cette fonction Get-MsolFederationProperty -DomainName <domain> pour vider la
propriété de fédération sur AD FS et Office 365. Vous pouvez comparer l’empreinte numérique
TokenSigningCertificate pour vérifier si la configuration du client Office 365 pour votre domaine
fédéré est synchronisée avec AD FS. Si vous trouvez une non-mise à jour dans la configuration du
certificat de signature de jetons, exécutez la commande suivante pour la mettre à jour :
Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
Vous pouvez également exécuter l’outil suivant pour planifier une tâche sur le serveur AD FS qui
surveille le passage de certificat automatique du certificat de signature de jetons et met à jour le
client Office 365 automatiquement.
Microsoft Office 365'installation d’Automation de mise à jour des métadonnées de
fédération
Vérifier et gérer l’sign-on unique avec AD FS
Les règles de revendication de transformation d’émission Office 365 rp ne sont pas configurées
correctement.
Dans un scénario où vous avez plusieurs domaines TLD (domaines de niveau supérieur), vous
pouvez avoir des problèmes de logo si le commutateur Supportmultipledomain n’a pas été utilisé
lors de la création et de la mise à jour de l’confiance RP. Pour plus d’informations, voir
Commutateur SupportMultipleDomain, lors de la gestion de l’ingso Office 365.
Assurez-vous que le chiffrement de jeton n’est pas utilisé par AD FS ou STS lorsqu’un jeton est
émis à Azure AD ou à Office 365.
6. Il existe des informations d’identification mises en cache obsolètes dans Windows d’informations
d’identification.
Parfois, lors de la connexion à partir d’une station de travail vers le portail (ou lors de l’utilisation de
Outlook), lorsque l’utilisateur est invité à obtenir des informations d’identification, les informations
d’identification peuvent être enregistrées pour la cible (service Office 365 ou AD FS) dans le Gestionnaire
d’informations d’identification Windows ( Control Panel\User Accounts\Credential Manager ). Cela permet
d’éviter une invite d’informations d’identification pendant un certain temps, mais elle peut provoquer un
problème une fois que le mot de passe de l’utilisateur a changé et que le gestionnaire d’informations
d’identification n’est pas mis à jour. Dans ce scénario, les informations d’identification obsolètes sont
envoyées au service AD FS et c’est pourquoi l’authentification échoue. La suppression ou la mise à jour
des informations d’identification mises en cache dans Windows d’informations d’identification peuvent
vous aider.
7. Assurez-vous que l’algorithme de hachage sécurisé configuré sur l’Office 365 partie de confiance est
configuré sur SHA1.
Lorsque l’relation d’confiance entre sts/AD FS et Azure AD/Office 365 utilise le protocole SAML 2.0,
l’algorithme de hachage sécurisé configuré pour la signature numérique doit être SHA1.
8. Si aucune des causes précédentes ne s’applique à votre situation, créez un dossier de support auprès de
Microsoft et demandez-lui de vérifier si le compte d’utilisateur apparaît de manière cohérente sous le
client Office 365 client. Pour plus d’informations, voir Un utilisateur fédéré est invité à plusieurs reprises à
fournir des informations d’identification lors de la connexion à Office 365, Azure ou Intune.
9. Selon le service cloud (intégré à Azure AD) auquel vous accédez, la demande d’authentification envoyée
aux services AD FS peut varier. Par exemple : certaines requêtes peuvent inclure des paramètres
supplémentaires tels que Wauth ou Wfresh, et ces paramètres peuvent entraîner un comportement
différent au niveau AD FS.
Nous recommandons que les binaires AD FS soient toujours mis à jour pour inclure les correctifs pour les
problèmes connus. Pour plus d’informations sur les dernières mises à jour, consultez le tableau suivant.
A D F S 2. 0 A D F S 2012 R2
Description du rollup de mise à jour 3 pour les Rollup de mise à jour de décembre 2014 pour Windows
services AD FS (Active Directory Federation RT 8.1, Windows 8.1 et Windows Server 2012 R2
Services) 2.0
La mise à jour est disponible pour résoudre
plusieurs problèmes après l’installation de la mise
à jour de sécurité 2843638 sur un serveur AD FS
Les utilisateurs ne peuvent pas se connecter au
domaine après la modification du mot de passe sur
un contrôleur de domaine distant
Cet article fournit une solution à un problème dans lequel les utilisateurs ne peuvent pas se connecter au
domaine après la modification du mot de passe sur un contrôleur de domaine distant.
Symptômes
Après avoir changé le mot de passe d’un compte d’utilisateur sur un contrôleur de domaine distant qui détient
le rôle FSMO (Flexible Single Master Operation) du contrôleur de domaine principal, il se peut que l’utilisateur
ne puisse pas se connecte à un contrôleur de domaine local en entrant le nouveau mot de passe. Toutefois, il se
peut que l’utilisateur puisse toujours se connecter au domaine à l’aide de son mot de passe précédent.
Cause
Ce comportement peut se produire lorsque les conditions suivantes sont vraies :
Le contrôleur de domaine distant n’a pas encore été répliqué avec le contrôleur de domaine local.
Kerberos est configuré pour utiliser le protocole UDP (User Datagram Protocol) (configuration par
défaut).
Le jeton de sécurité de l’utilisateur est trop grand pour tenir dans un message UDP Kerberos.
NOTE
Le jeton de sécurité de l’utilisateur peut être important si cet utilisateur est membre de nombreux groupes.
Ce problème est dû à la fonctionnalité anti-relecture de l’authentification Kerberos sur le contrôleur de domaine

local. Les étapes suivantes illustrent ce comportement :
1. Le mot de passe du compte d’utilisateur est modifié sur le contrôleur de domaine distant, mais cette
modification n’a pas encore été répliquée sur le contrôleur de domaine local.
2. L’utilisateur tente de se connecter au domaine à l’aide du nouveau mot de passe. Le message Exchange
service d’authentification Kerberos (KRB_AS_REQ) est envoyé au contrôleur de domaine local à l’aide d’UDP.
3. Le contrôleur de domaine local échoue à l’authentification car il ne comprend pas encore les nouvelles
informations de mot de passe.
4. Le contrôleur de domaine local fait suivre la demande au PDC distant ( KDCSVC!FailedLogon ).
5. Dans la fonction, une entrée pour la demande est entrée dans la table de détection de relecture et le message
KRB_AS_REQ est envoyé au FailedLogon PDC distant.
6. Le PDC distant authentifiera la demande, puis renvoie une réponse positive au contrôleur de domaine local.
7. Le contrôleur de domaine local détecte que la réponse est trop grande pour un paquet UDP et c’est pourquoi
il envoie une demande à l’ordinateur client pour renvoyer la demande à l’aide du protocole TCP
(Transmission Control Protocol).
8. L’ordinateur client retransmet la demande d’authentification à l’aide de TCP.
9. Le contrôleur de domaine local échoue à l’authentification car il ne comprend pas encore les nouvelles
informations de mot de passe (comme à l’étape 3).
10. Le contrôleur de domaine local forwarde la demande au contrôleur de domaine PDC distant
KDCSVC!FailedLogon () (comme à l’étape 4).
11. La vérification de détection de relecture dans la fonction renvoie un message KRB_AP_ERR_REPEAT car une
entrée pour cette demande est déjà présente dans la table de détection FailedLogon de relecture. Il s’agit de
l’entrée créée à l’étape 5.
La tentative d’authentification échoue.
Résolution
Pour résoudre ce problème, obtenez le dernier Service Pack pour Windows 2000.
La version anglaise de ce correctif possède les attributs de fichier (ou version ultérieure) répertoriés dans le
tableau suivant. Les dates et heures de ces fichiers sont répertoriées en temps universel coordonné (UTC).
Lorsque vous affichez les informations de fichier, elles sont converties en heure locale. Pour trouver la différence
entre l’heure UTC et l’heure locale, utilisez l’onglet Fuseau horaire dans l’outil Date et heure du Panneau de
contrôle.
Date Time Version Size File name

-----------------------------------------------------------
22-Mar-2002 23:55 5.0.2195.4959 123,664 Adsldp.dll
30-Jan-2002 00:52 5.0.2195.4851 130,832 Adsldpc.dll
30-Jan-2002 00:52 5.0.2195.4016 62,736 Adsmsext.dll
22-Mar-2002 23:55 5.0.2195.5201 356,624 Advapi32.dll
22-Mar-2002 23:55 5.0.2195.4985 135,952 Dnsapi.dll
22-Mar-2002 23:55 5.0.2195.4985 95,504 Dnsrslvr.dll
22-Mar-2002 23:56 5.0.2195.5013 521,488 Instlsa5.dll
22-Mar-2002 23:55 5.0.2195.5246 145,680 Kdcsvc.dll
22-Mar-2002 23:50 5.0.2195.5246 199,952 Kerberos.dll
07-Feb-2002 19:35 5.0.2195.4914 71,024 Ksecdd.sys
02-Mar-2002 21:32 5.0.2195.5013 503,568 Lsasrv.dll
02-Mar-2002 21:32 5.0.2195.5013 33,552 Lsass.exe
08-Dec-2001 00:05 5.0.2195.4745 107,280 Msv1_0.dll
22-Mar-2002 23:55 5.0.2195.4917 306,960 Netapi32.dll
22-Mar-2002 23:55 5.0.2195.4979 360,208 Netlogon.dll
22-Mar-2002 23:55 5.0.2195.5221 917,264 Ntdsa.dll
22-Mar-2002 23:55 5.0.2195.5201 386,832 Samsrv.dll
30-Jan-2002 00:52 5.0.2195.4874 128,784 Scecli.dll
22-Mar-2002 23:55 5.0.2195.4968 299,792 Scesrv.dll
30-Jan-2002 00:52 5.0.2195.4600 48,400 W32time.dll
06-Nov-2001 19:43 5.0.2195.4600 56,592 W32tm.exe
22-Mar-2002 23:55 5.0.2195.5011 125,712 Wldap32.dll
Pour contourner ce problème, modifiez le mot de passe du compte d’utilisateur sur le contrôleur de domaine
local ou forcez Kerberos à utiliser le protocole TCP (Transmission Control Protocol) au lieu de LDP (User
Datagram Protocol).
Pour plus d’informations, voir Comment forcer Kerberos àutiliser TCP au lieu d’UDP dans Windows .
Statut
Ce problème a été corrigé pour la première fois dans Windows 2000 Service Pack 3.
La fonctionnalité anti-relecture Kerberos empêche le même paquet d’être reçu deux fois par le serveur
d’authentification. Une attaque par relecture est une attaque dans laquelle une transmission de données valide
est répétée de manière malveillante ou frauduleuse, soit par l’auteur de l’attaque, soit par un adversaire qui
intercepte les données et les retransmet. Une personne malveillante peut tenter de « relire » le nom d’utilisateur
et le mot de passe d’un utilisateur valide pour tenter de s’authentifier à l’aide des informations d’identification
de cet utilisateur.
Erreur lors de la tentative de saisie du rôle maître
RID avec Ntdsutil
Cet article fournit de l’aide pour corriger une erreur qui se produit lorsque vous saisissez le rôle maître d’ID
relatif (RID) avec l’outil Ntdsutil vers un autre contrôleur de domaine.
Symptômes
Supposez le scénario suivant. Le serveur qui détient le rôle maître des opérations RID n’est plus accessible et
doit être reconstruit. Vous tentez de saisir le rôle de maître RID avec l’outil Ntdsutil sur un autre contrôleur de
domaine, mais vous recevez l’erreur suivante :
Tentative de transfert sécurisé du FSMO RID avant la crise.

ldap_modify_sW’erreur 0x34(52 (Non disponible).
Le message d’erreur étendu Ldap est 000020AF : SvcErr : DSID-0321093D, problème 5002 (NON
DISPONIBLE), données 8
L’erreur Win32 renvoyée 0x20af (l’opération FSMO demandée a échoué. Le titulaire actuel du FSMO n’a pas
pu être contacté.)
Selon le code d’erreur, cela peut indiquer une erreur de connexion, ldap ou de transfert de rôle.
Échec du transfert du FSMO RID, suite à une crise...
La recherche n’a pas trouvé de contrôleurs de domaine
Cause
L’attribut fSMORoleOwner de l’objet RID Manager$ dans Active Directory n’est pas valide. Par exemple, la
valeur suivante entraînerait cette erreur :
CN=NTDS Paramètres DEL:a586a105-5a9c-4b2f-8289-bc5b43841ac8,CN=DC01,CN=Servers,CN=Default-

First-Site-Name,CN=Sites,CN=Configuration,DC=contoso,DC=com
Résolution
Pour résoudre ce problème, utilisez l’outil AdsiEdit pour mettre à jour l’attribut fSMORoleOwner de l’objet Rid
Manager$ dans Active Directory.
1. Ouvrez AdsiEdit (AdsiEdit.msc).
2. Développez Domaine, puis sélectionnez CN=Système.
3. Avec CN=Système sélectionné dans le volet gauche, cliquez avec le bouton droit sur CN=RID
Manager$ et sélectionnez Propriétés.
4. L’attribut fSMORoleOwner doit correspondre à l’ancien master RID. Par exemple, si DC01 était l’ancien
master RID (le serveur qui n’est plus disponible), l’attribut fSMORoleOwner serait :
CN=NTDS Paramètres,CN=DC01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com
Un exemple de valeur non valide pour l’attribut fSMORoleOwner qui peut entraîner une erreur lors de
la tentative de saisie du rôle serait :
CN=NTDS Paramètres DEL:a586a105-5a9c-4b2f-8289-

bc5b43841ac8,CN=DC01,CN=Servers,CN=Default-First-Site-
5. Modifiez la valeur d’attribut fSMORoleOwner pour refléter le contrôleur de domaine que vous
souhaitez attribuer au contrôleur RID. Par exemple, si DC01 est le contrôleur de domaine en échec et
DC02 est le contrôleur de domaine pour lequel vous souhaitez saisir le rôle de maître RID, vous devez
modifier l’attribut pour refléter le fait que DC02 sera le nouveau master RID.
CN=NTDS Paramètres,CN=DC02,CN=Servers,CN=Default-First-Site-
6. La modification de l’attribut fSMORoleOwner permet de réaliser la même chose que de saisir le rôle
avec Ntdsutil. Par conséquent, après avoir changé l’attribut manuellement, vous n’avez pas besoin
d’utiliser Ntdsutil pour saisir le rôle.
Comment trouver des serveurs qui tiennent des
rôles d’opérations maîtres unique flexibles
Cet article explique comment rechercher les serveurs qui détiennent les rôles FSMO (Flexible Single Master
Operation) dans une forêt.
Résumé
Active Directory définit cinq rôles FSMO :
Contrôleur de schéma
Maître d’attribution de noms de domaine
Master RID
Master PDC
Infrastructure master
Le maître de schéma et le maître d’appellation de domaine sont des rôles par forêt. Par conséquent, il n’existe
qu’un seul maître de schéma et un maître d’attribution de noms de domaine par forêt.
Le maître RID, le maître PDC et le maître d’infrastructure sont des rôles par domaine. Chaque domaine possède
son propre maître RID, maître PDC et maître d’infrastructure. Par conséquent, si une forêt possède trois
domaines, il existe trois maîtres RID, trois maîtres PDC et trois maîtres d’infrastructure.
Déterminer les titulaires FSMO RID, PDC et Infrastructure d’un

domaine sélectionné
1. Cliquez sur Démarrer, sur Exécuter, tapez dsa.msc, puis cliquez sur OK.
2. Cliquez avec le bouton droit sur l’objet Domain sélectionné dans le volet supérieur gauche, puis cliquez sur
Operations Masters.
3. Cliquez sur l’onglet PDC pour afficher le serveur qui détient le rôle principal PDC.
4. Cliquez sur l’onglet Infrastructure pour afficher le serveur qui détient le rôle principal Infrastructure.
5. Cliquez sur l’onglet Pool RID pour afficher le serveur qui détient le rôle principal RID.
Déterminer le titulaire du FSMO du schéma dans une forêt

2. Dans le menu Console, cliquez sur Ajouter/Supprimer un logiciel en un clin d’œil, cliquez sur Ajouter,
double-cliquez sur Schéma Active Directory, cliquez sur Fermer, puis sur OK.
3. Cliquez avec le bouton droit sur Schéma Active Directory dans le volet supérieur gauche, puis cliquez sur
Operations Masters pour afficher le serveur qui détient le rôle de maître de schéma.
NOTE
Pour que le logiciel en un clin d’œil du schéma Active Directory soit disponible, vous de Schmmgmt.dll fichier. Pour ce faire,
cliquez sur Démarrer, sur Exécuter, tapez regsvr32 schmmgmt.dll dans la zone Ouvrir, puis cliquez sur OK. Un message
s’affiche et indique que l’inscription a réussi.
Déterminer le titulaire FSMO d’attribution de noms de domaine dans

une forêt
2. Dans le menu Console, cliquez sur Ajouter/Supprimer un logiciel en un clin d’œil, cliquez sur Ajouter,
double-cliquez sur Domaines et trusts Active Director y, cliquez sur Fermer, puis cliquez sur OK.
3. Dans le volet gauche, cliquez sur Domaines et trusts Active Director y.
4. Cliquez avec le bouton droit sur Domaines Active Director y et Confiance, puis cliquez sur Operations
Master pour afficher le serveur qui détient le rôle maître d’attribution de noms de domaine dans la forêt.
Utiliser le Kit de Windows Server 2000

Le kit de ressources Windows 2000 contient un fichier .cmd appelé Dumpfsmos.cmd que vous pouvez utiliser
pour rapidement lister les propriétaires de rôles FSMO pour votre domaine et votre forêt actuels. Le fichier .cmd
utilise Ntdsutil.exe pour éumer les propriétaires de rôles. Le fichier Dumpfsmos.cmd contient :
@echo off
REM
REM Script to dump FSMO role owners on the server designated by %1
REM
if ""=="%1" goto usage
Ntdsutil roles Connections "Connect to server %1" Quit "select Operation Target" "List roles for connected
server" Quit Quit Quit
goto done
:usage
@echo Please provide the name of a domain controller (i.e. dumpfsmos MYDC)
@echo.
:done
Utiliser l’outil NTDSUTIL

NTDSUTIL est un outil fourni avec Windows 2000 Server, Windows 2000 Advanced Server et Windows 2000
Datacenter Server. Cet outil permet de vérifier la modification de certains aspects d’Active Directory. Voici les
étapes nécessaires pour afficher les rôles FSMO (Flexible Single Master Operation) sur un contrôleur de
domaine donné.
Ntdsutil.exe est le seul outil qui vous montre tous les propriétaires de rôles FSMO. Vous pouvez afficher
l’émulateur PDC, le master RID et les propriétaires de rôles maîtres d’infrastructure dans Utilisateurs et
ordinateurs Active Directory. Vous pouvez afficher le propriétaire du rôle de maître de schéma dans le logiciel en
snap-in du schéma Active Directory. Vous pouvez afficher le propriétaire du rôle principal d’attribution de noms
de domaine dans Les domaines et les trusts Active Directory.
1. Cliquez sur Démarrer, sur Exécuter, tapez cmd dans la zone Ouvrir, puis appuyez sur Entrée.
2. Tapez ntdsutil, puis appuyez sur Entrée.
3. Tapez gestion de domaine, puis appuyez sur Entrée.
4. Tapez connexions, puis appuyez sur Entrée.
5. Tapez connectez-vous à ser verName , où Ser verName est le nom du contrôleur de domaine que vous
souhaitez afficher, puis appuyez sur Entrée.
6. Tapez quit, puis appuyez sur Entrée.
7. Tapez la cible de l’opération select, puis appuyez sur Entrée.
8. Tapez les rôles de liste pour le serveur connecté, puis appuyez sur Entrée. Une liste est affichée de la
même façon que celle répertoriée ci-dessous. Les résultats peuvent très dépendre des rôles que peut
contenir le contrôleur de domaine particulier. Si vous recevez un message d’erreur, vérifiez l’orthographe
des commandes car la syntaxe des commandes doit être exacte. Si vous avez besoin de la syntaxe d’une
commande, tapez ? à chaque invite :
Server "dc1" knows about 5 roles

Schema - CN=NTDS
Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=com
Domain - CN=NTDS
PDC - CN=NTDS
RID - CN=NTDS
Infrastructure - CN=NTDS
Utiliser DCDIAG
Sur un Windows de domaine 2000, exécutez la commande suivante :
DCdiag /test:Knowsofroleholders /v
Vous devez utiliser le commutateur /v. Cette liste répertorie les propriétaires de tous les rôles FSMO dans
l’entreprise.
References
Pour plus d’informations, cliquez sur les numéros d’article ci-dessous pour afficher les articles :
197132 Windows FSMO Active Directory 2000
223346 optimisation et placement FSMO sur Windows 2000 Domains
Rôles FSMO Active Directory dans Windows
Cet article vous permet principalement de découvrir les rôles d’opérations à maître unique flottant (FSMO,
Flexible Single Master Operation) dans Active Directory.
Produits concernés : Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 et Windows
Server 2022
Résumé
Active Directory est le référentiel central qui stocke tous les objets d’une entreprise et leurs attributs respectifs. Il
s’agit d’une base de données hiérarchique multimaître qui peut stocker des millions d’objets. Les modifications
apportées à la base de données peuvent être traitées sur n’importe quel contrôleur de domaine (DC) de
l’entreprise, qu’il soit connecté ou déconnecté du réseau.
Modèle multimaître
Une base de données multimaître, telle qu’Active Directory, offre la possibilité d’autoriser les modifications sur
n’importe quel contrôleur de domaine de l’entreprise. Elle introduit toutefois aussi la possibilité de conflits qui
peuvent potentiellement entraîner des problèmes une fois que les données sont répliquées dans le reste de
l’entreprise. Pour gérer les mises à jour conflictuelles, Windows dispose notamment d’un algorithme de
résolution des conflits qui gère les écarts dans les valeurs. Pour ce faire, il effectue une résolution sur le
contrôleur de domaine dans lequel les modifications ont été écrites en dernier. Il s’agit du principe « last writer
wins » (dernière version valide). Les modifications apportées à tous les autres contrôleurs de domaine sont
ignorées. Bien que cette méthode soit acceptable dans certains cas, il peut arriver que la résolution des conflits
soit trop difficile à l’aide de l’approche « last writer wins ». Dans ce cas, il est préférable d’empêcher le conflit
de se produire plutôt que d’essayer de le résoudre après sa survenance.
Pour certains types de modifications, Windows intègre des méthodes pour éviter que des mises à jour Active
Directory conflictuelles ne se produisent.
Modèle à maître unique

Pour empêcher les mises à jour conflictuelles dans Windows, Active Directory effectue des mises à jour de
certains objets selon le modèle à maître unique. Dans ce modèle, un seul contrôleur de domaine de l’annuaire
est autorisé à traiter les mises à jour. Il est similaire au rôle attribué à un contrôleur de domaine principal (PDC)
dans les versions antérieures de Windows, comme Microsoft Windows NT 3.51 et 4.0. Dans les versions
antérieures de Windows, le contrôleur de domaine principal est chargé de traiter toutes les mises à jour dans un
domaine donné.
Active Directory étend le modèle à maître unique qui figure dans les versions antérieures de Windows pour
inclure plusieurs rôles et la possibilité de transférer des rôles vers n’importe quel contrôleur de domaine de
l’entreprise. Étant donné qu’un rôle Active Directory n’est pas lié à un seul contrôleur de domaine, il est appelé
« rôle FSMO ». Actuellement, il existe cinq rôles FSMO dans Windows :
Contrôleur de schéma
Maître d’opérations des noms de domaine
Maître RID
Émulateur PDC
Maître d’infrastructure
En règle générale, une appartenance de rôle FSMO est exécutée uniquement quand le contrôleur de domaine a
répliqué le contexte d’appellation (NC) où l’appartenance est stockée depuis le démarrage du service d’annuaire.
Assurez-vous qu’une prise de rôle FSMO atteint le détenteur précédent avant l’utilisation du rôle.
Rôle FSMO Contrôleur de schéma
Le détenteur du rôle FSMO Contrôleur de schéma est le contrôleur de domaine chargé d’exécuter les mises à
jour du schéma d’annuaire, c’est-à-dire le contexte d’appellation du schéma ou
LDAP://cn=schema,cn=configuration,dc=<domain>. Ce contrôleur de domaine est le seul qui peut traiter les
mises à jour du schéma d’annuaire. Une fois la mise à jour du schéma terminée, il est répliqué du contrôleur de
schéma vers tous les autres contrôleurs de domaine de l’annuaire. Il n’existe qu’un seul contrôleur de schéma
par forêt.
Exigences de réplication initiale et de connectivité
Le détenteur de ce rôle FSMO n’est actif que quand le détenteur du rôle a effectué une réplication entrante
correcte du contexte d’appellation du schéma depuis le démarrage du service d’annuaire.
Les contrôleurs de domaine et les membres de la forêt contactent uniquement le rôle FSMO quand ils
mettent à jour le schéma.
Rôle FSMO Maître d’opérations des noms de domaine
Le détenteur du rôle FSMO Maître d’opérations des noms de domaine est le contrôleur de domaine chargé
d’apporter les modifications à l’espace de noms de domaine à l’échelle de la forêt de l’annuaire, c’est-à-dire le
contexte d’appellation des partitions\configuration ou LDAP://CN=Partitions, CN=Configuration, DC=
<domain>. Ce contrôleur de domaine est le seul qui peut ajouter ou supprimer un domaine de l’annuaire. Il
peut également ajouter ou supprimer des références croisées à des domaines dans des annuaires externes.
Le détenteur de ce rôle FSMO n’est actif que quand le détenteur du rôle a effectué une réplication
entrante correcte du contexte d’appellation de la configuration depuis le démarrage du service
d’annuaire.
Les membres de domaine de la forêt contactent uniquement le détenteur du rôle FSMO quand ils
mettent à jour les références croisées. Les contrôleurs de domaine contactent le détenteur du rôle FSMO
dans les cas suivants :
Des domaines sont ajoutés ou supprimés dans la forêt.
De nouvelles instances de partitions d’annuaire d’application sur des contrôleurs de domaine sont
ajoutées. Par exemple, un serveur DNS a été inscrit pour les partitions d’annuaire d’application DNS
par défaut.
Rôle FSMO Maître RID
Le détenteur du rôle FSMO Maître RID est le contrôleur de domaine unique chargé de traiter les demandes du
pool RID provenant de tous les contrôleurs de domaine d’un domaine donné. Il est également chargé de
supprimer un objet de son domaine et de le placer dans un autre domaine lors d’un déplacement d’objet.
Quand un contrôleur de domaine crée un objet principal de sécurité, tel qu’un utilisateur ou un groupe, il
attache un ID de sécurité (SID) unique à l’objet. Ce SID se compose des éléments suivants :
Un SID de domaine identique pour tous les SID créés dans un domaine.
Un ID relatif (RID) unique pour chaque SID de principal de sécurité créé dans un domaine.
Chaque contrôleur de domaine Windows d’un domaine est alloué à un pool de RID qu’il est autorisé à affecter
aux principaux de sécurité qu’il crée. Quand le pool RID alloué d’un contrôleur de domaine passe sous un seuil
donné, il émet une demande de RID supplémentaires au maître RID du domaine. Le maître RID du domaine
répond à la demande en récupérant les RID du pool RID non alloué du domaine et les affecte au pool du
contrôleur de domaine demandeur. Il existe un maître RID par domaine dans un annuaire.
correcte du contexte d’appellation du domaine depuis le démarrage du service d’annuaire.
Les contrôleurs de domaine contactent le détenteur du rôle FSMO quand ils récupèrent un nouveau pool RID.
Le nouveau pool RID est remis aux contrôleurs de domaine via la réplication AD.
Rôle FSMO Émulateur PDC
L’émulateur PDC est nécessaire pour synchroniser l’heure dans une entreprise. Windows inclut le service de
temps W32Time (Temps Windows) requis par le protocole d’authentification Kerberos. Tous les ordinateurs
Windows d’une entreprise utilisent une heure commune. Le service de temps vise à garantir que le service
Temps Windows utilise une relation hiérarchique qui contrôle l’autorité. Il n’autorise pas les boucles pour
garantir une utilisation appropriée d’une heure commune.
L’émulateur PDC d’un domaine fait autorité pour le domaine. L’émulateur PDC à la racine de la forêt fait autorité
pour l’entreprise et doit être configuré pour collecter l’heure à partir d’une source externe. Tous les détenteurs
du rôle FSMO PDC respectent la hiérarchie des domaines pour la sélection de leur partenaire de temps entrant.
Dans un domaine Windows, le détenteur du rôle Émulateur PDC conserve les fonctions suivantes :
Les changements de mot de passe effectués par d’autres contrôleurs de domaine dans le domaine sont
répliqués de manière préférentielle vers l’émulateur PDC.
Quand un échec d’authentification se produit sur un contrôleur de domaine donné en raison d’un mot de
passe incorrect, cet échec est transféré à l’émulateur PDC avant qu’un message d’échec de mot de passe
incorrect soit signalé à l’utilisateur.
Le verrouillage de compte est traité sur l’émulateur PDC.
L’émulateur PDC exécute toutes les fonctionnalités qu’un contrôleur de domaine principal Windows NT 4.0
Server ou version antérieure effectue pour les clients Windows NT 4.0 ou version antérieure.
Cette partie du rôle Émulateur PDC est inutile dans la situation suivante :
Toutes les stations de travail, tous les serveurs membres et tous les contrôleurs de domaine qui exécutent
Windows NT 4.0 ou version antérieure sont mis à niveau vers Windows 2000.
L’émulateur PDC effectue toujours les autres fonctions décrites dans un environnement Windows 2000.
Les informations ci-dessous décrivent les modifications qui se produisent pendant le processus de mise à
niveau :
Les clients Windows (stations de travail et serveurs membres) et les clients de bas niveau qui ont installé le
package client des services distribués n’effectuent pas d’écritures d’annuaire (telles que les changements de
mot de passe) préférentiellement sur le contrôleur de domaine qui s’est annoncé comme PDC. Ils utilisent
n’importe quel contrôleur de domaine pour le domaine.
Une fois que les contrôleurs de domaine secondaires (BDC) dans les domaines de bas niveau sont mis à
niveau vers Windows 2000, l’émulateur PDC ne reçoit aucune demande de réplica de bas niveau.
Les clients Windows (stations de travail et serveurs membres) et les clients de bas niveau qui ont installé le
package client des services distribués utilisent Active Directory pour localiser les ressources réseau. Ils ne
nécessitent pas le service Explorateur Windows NT.
Le détenteur de ce rôle FSMO est toujours actif quand l’émulateur PDC constate que l’attribut
fSMORoleOwner de l’en-tête du contexte d’appellation du domaine pointe vers lui-même. Il n’existe
aucune exigence de réplication entrante.
Les contrôleurs de domaine contactent le détenteur du rôle FSMO quand ils ont un nouveau mot de
passe ou que la vérification du mot de passe local échoue. Aucune erreur ne se produit quand
l’émulateur PDC n’est pas accessible ou que la valeur du Registre AvoidPdcOnWan est définie sur 1 .
Vous pouvez utiliser l’applet de commande suivante pour exécuter les conditions préalables à la
rétrogradation d’un contrôleur de domaine.
PS C:\Users\Capecodadmin> Test-ADDSDomainControllerUninstallation -DemoteOperationMasterRole |fl
Voici un exemple de sortie quand l’émulateur PDC n’est pas accessible.
Message : Échec de la vérification des conditions préalables pour la promotion du contrôleur de

domaine. Vous avez indiqué que ce contrôleur de domaine Active Directory n’est pas le dernier du
domaine « contoso.com ». Toutefois, aucun autre contrôleur de domaine de ce domaine ne peut être
contacté. Si vous continuez, toutes les modifications apportées à ce contrôleur de domaine par les
services de domaine Active Directory seront perdues. Pour poursuivre néanmoins, indiquez l’option
« IgnoreLastDCInDomainMismatch ».
Contexte : Test.VerifyDcPromoCore.DCPromo.General.50
RebootRequired : False
État : Erreur
Rôle FSMO Maître d’infrastructure

Quand un objet d’un domaine est référencé par un autre objet d’un autre domaine, il représente la référence par
les éléments suivants :
le GUID ;
le SID (pour les références aux principaux de sécurité) ;
le DN de l’objet référencé.
Le détenteur du rôle FSMO Maître d’infrastructure est le contrôleur de domaine chargé de mettre à jour le SID
et le nom unique d’un objet dans une référence d’objet inter-domaines.
NOTE
Le rôle Maître d’infrastructure (IM) doit être détenu par un contrôleur de domaine qui n’est pas un serveur de catalogue
global (GC). Si le maître d’infrastructure est exécuté sur un serveur de catalogue global, il arrête la mise à jour des
informations sur les objets, car il ne dispose pas de références aux objets qu’il ne contient pas. Cela s’explique par le fait
qu’un serveur de catalogue global comprend un réplica partiel de chaque objet de la forêt. Par conséquent, les références
d’objets inter-domaines dans ce domaine ne sont pas mises à jour et un avertissement correspondant est consigné dans
le journal des événements de ce contrôleur de domaine.
Si tous les contrôleurs de domaine d’un domaine hébergent également le catalogue global, ils disposent tous
des données actuelles, peu importe le contrôleur de domaine qui détient le rôle Maître d’infrastructure.
Quand la fonctionnalité facultative Corbeille est activée, chaque contrôleur de domaine est chargé de mettre à
jour ses références d’objets inter-domaines quand l’objet référencé est déplacé, renommé ou supprimé. Dans ce
cas, aucune tâche n’est associée au rôle FSMO Maître d’infrastructure, peu importe le contrôleur de domaine qui
détient le rôle Maître d’infrastructure. Pour plus d’informations, consultez l’article 6.1.5.5 Infrastructure FSMO
Role (en anglais uniquement).
correcte du contexte d’appellation du domaine depuis le démarrage du service d’annuaire.
Il n’existe aucune exigence de connectivité pour le détenteur de ce rôle FSMO. Il s’agit d’une fonctionnalité de
nettoyage interne de la forêt.
Transférer ou prendre des rôles FSMO dans Active
Directory Domain Services
Cet article explique quand et comment procéder au transfert ou à la saisie des rôles d’opérations à maître
unique flottant (FSMO).
Produits concernés : Windows Server 2019, Windows Server Standard 2016, Windows Server Essentials 2016,
Windows Server Datacenter 2016
Dans une forêt Active Directory Domain Services (AD DS), il existe des tâches spécifiques qui doivent être
effectuées par un seul contrôleur de domaine (DC). Les contrôleurs de domaine affectés à l’exécution de ces
opérations uniques portent le nom de « détenteurs de rôles FSMO ». Le tableau ci-dessous répertorie les rôles
FSMO et leur positionnement dans Active Directory.
C O N T EXT E D’A P P EL L AT IO N
RO L E P O RT ÉE ( PA RT IT IO N A C T IVE DIREC TO RY )
Contrôleur de schéma Forêt CN=Schema,CN=configuration,DC=

<forest root domain>
Maître d’opérations des noms de Forêt CN=configuration,DC=<forest root

domaine domain>
Émulateur PDC Domaine DC=<domain>
Maître RID Domaine DC=<domain>
Maître d’infrastructure Domaine DC=<domain>
Pour plus d’informations sur les détenteurs de rôles FSMO et les recommandations relatives au positionnement
des rôles, consultez l’article Placement et optimisation FSMO sur les contrôleurs de domaine Active Directory.
NOTE
Les partitions d’application Active Directory qui incluent des partitions d’application DNS comportent des liens de rôle
FSMO. Si une partition d’application DNS définit un détenteur pour le rôle Maître d’infrastructure, vous ne pouvez pas
utiliser Ntdsutil, DCPromo ou d’autres outils pour supprimer cette partition d’application. Pour plus d’informations,
consultez l’article La rétrogradation DCPROMO échoue si elle ne parvient pas à contacter le maître d’infrastructure DNS.
Quand un contrôleur de domaine faisant office de détenteur de rôle commence à s’exécuter (par exemple, après
une défaillance ou un arrêt), il ne se comporte pas immédiatement comme détenteur de rôle. Le contrôleur de
domaine attend de recevoir la réplication entrante pour son contexte d’appellation (par exemple, le détenteur du
rôle Contrôleur de schéma attend de recevoir la réplication entrante de la partition de schéma).
Les informations que les contrôleurs de domaine transmettent dans le cadre de la réplication Active Directory
incluent les identités des détenteurs de rôle FSMO actuels. Quand le contrôleur de domaine qui vient de
démarrer reçoit les informations de réplication entrante, il vérifie s’il est toujours le détenteur du rôle. Si c’est le
cas, il reprend les opérations habituelles. Si les informations répliquées indiquent qu’un autre contrôleur de
domaine fait office de détenteur de rôle, le nouveau contrôleur de domaine démarré abandonne l’appartenance
du rôle. Ce comportement réduit le risque de détenteurs de rôle FSMO en double dans le domaine ou la forêt.
IMPORTANT
Les opérations AD FS échouent si elles nécessitent un détenteur de rôle et si le nouveau détenteur de rôle démarré est en
réalité le détenteur de rôle mais qu’il ne reçoit pas de réplication entrante.
Tout se passe alors comme si le détenteur de rôle était hors connexion.
Déterminer quand transférer ou prendre des rôles

Dans des conditions normales, les cinq rôles doivent tous être attribués à des contrôleurs de domaine « actifs »
dans la forêt. Quand vous créez une forêt Active Directory, l’Assistant Installation d’Active Directory
(Dcpromo.exe) attribue les cinq rôles FSMO au premier contrôleur de domaine qu’il crée dans le domaine racine
de la forêt. Quand vous créez un domaine enfant ou de l’arborescence, Dcpromo.exe attribue les trois rôles de
domaine au premier contrôleur du domaine.
Les contrôleurs de domaine continuent à détenir les rôles FSMO jusqu’à ce qu’ils soient réassignés par le biais
d’une des méthodes suivantes :
Un administrateur réassigne le rôle à l’aide d’un outil d’administration à interface graphique.
Un administrateur réassigne le rôle à l’aide de la commande ntdsutil /roles .
Un administrateur rétrograde normalement un contrôleur de domaine détenteur de rôle par le biais de
l’Assistant Installation d’Active Directory. Cet Assistant réassigne tout rôle détenu localement à un contrôleur
de domaine existant dans la forêt.
Un administrateur peut rétrograder un contrôleur de domaine détenteur de rôle à l’aide de la commande
dcpromo /forceremoval .
Le contrôleur de domaine s’arrête et redémarre. Lorsque le contrôleur de domaine redémarre, il reçoit des
informations de réplication entrante lui indiquant qu’un autre contrôleur de domaine est détenteur du rôle.
Dans ce cas, le contrôleur de domaine nouvellement lancé renonce au rôle (tel que décrit précédemment).
Si un détenteur de rôle FSMO rencontre un dysfonctionnement ou est mis hors service avant le transfert de ses
rôles, il convient de saisir et de transférer les rôles sur un contrôleur de domaine adapté et sain.
Nous recommandons de transférer des rôles FSMO dans les scénarios suivants :
Le détenteur de rôle actuel est opérationnel et accessible sur le réseau par le nouveau propriétaire FSMO.
Vous pouvez facilement rétrograder un contrôleur de domaine qui détient actuellement les rôles FSMO que
vous souhaitez assigner à un contrôleur de domaine spécifique dans votre forêt Active Directory.
Le contrôleur de domaine qui détient actuellement des rôles FSMO est placé hors connexion pour des
opérations de maintenance planifiées et certains rôles FSMO spécifiques doivent être assignés à des
contrôleurs de domaine actifs. Vous devrez peut-être transférer des rôles pour effectuer des opérations qui
concernent le détenteur de rôle FSMO. Cela est particulièrement vrai pour le rôle d’émulateur du contrôleur
de domaine principal (PDC). Il s’agit d’un problème moins important pour le rôle maître RID, le rôle de maître
d’attribution de noms de domaine et les rôles de contrôleur de schéma.
Nous recommandons de prendre des rôles FSMO dans les scénarios suivants :
Le détenteur de rôle actuel rencontre une erreur opérationnelle qui empêche le bon déroulement d’une
opération FSMO et ce rôle ne peut pas être transféré.
Vous utilisez la commande dcpromo /forceremoval pour rétrograder de force un contrôleur de domaine
qui possède un rôle FSMO.
IMPORTANT
La commande dcpromo /forceremoval laisse les rôles FSMO dans un état non valide jusqu’à ce qu’ils soient
réassignés par un administrateur.
Le système d’exploitation de l’ordinateur qui détenait à l’origine un rôle spécifique n’existe plus ou a été
réinstallé.
NOTE
Nous vous recommandons de saisir tous les rôles uniquement lorsque l’autre contrôleur de domaine ne retourne pas
au domaine.
Lorsque les rôles FSMO doivent être saisis dans les scénarios de récupération de forêt, suivez l’étape 5 de l’article
Exécuter la récupération initiale, dans la section Restaurer le premier contrôleur de domaine inscriptible dans chaque
domaine.
Après un transfert ou une saisie de rôle, le nouveau détenteur du rôle n’est pas opérationnel immédiatement. Au lieu
de cela, le nouveau détenteur du rôle se comporte comme un détenteur de rôle redémarré et attend sa copie du
contexte d'appellation pour le rôle (comme la partition de domaine) pour lancer efficacement un cycle de réplication
entrante. Cette exigence de réplication permet de s’assurer que le nouveau détenteur de rôle est aussi à jour que
possible avant d’entrer en action. Elle limite également le nombre d’erreurs potentielles. Cette fenêtre comprend
uniquement les changements que le détenteur de rôle précédent n’a pas fini de reproduire sur les autres contrôleurs
de domaine avant qu’il ne soit hors ligne. Pour une liste du contexte d’appellation de chaque rôle FSMO, consultez le
tableau présenté dans la section Plus d’informations.
Identifier un nouveau titulaire de rôle

Le meilleur candidat pour le nouveau détenteur de rôle est un contrôleur de domaine répondant aux critères
suivants :
Il réside dans le même domaine que le détenteur de rôle précédent.
Il dispose de la copie répliquée et non protégée la plus récente de la partition de rôle.
Supposons, par exemple, que vous deviez transférer le rôle de contrôleur de schéma. Le rôle de contrôleur de
schéma fait partie de la partition de schéma de la forêt (cn=Schema,cn=Configuration,dc=<forest root
domain>). Le meilleur candidat pour un nouveau détenteur de rôle est un contrôleur de domaine qui réside
également dans le domaine racine de la forêt et dans le même site Active Directory que le détenteur actuel du
rôle.
Cau t i on
Ne placez pas le rôle de maître d’infrastructure sur le même contrôleur de domaine que le serveur de catalogue
global. Si le rôle de maître d’infrastructure est exécuté sur un serveur de catalogue global, il arrête la mise à jour
des informations sur les objets, car il ne dispose pas de références aux objets qu’il ne contient pas. Cela
s’explique par le fait qu’un serveur de catalogue global comprend un réplica partiel de chaque objet de la forêt.
Pour vérifier si un contrôleur de domaine est également un serveur de catalogue global, procédez comme suit :
1. Sélectionnez Démarrer > Programmes > Outils d’administration > Sites et ser vices
Active Director y .
2. Dans le volet de navigation, double-cliquez sur Sites , puis recherchez le site approprié ou sélectionnez
Default-first-site-name si aucun autre site n’est disponible.
3. Ouvrez le dossier Serveurs, puis sélectionnez le contrôleur de domaine.
4. Dans le dossier du contrôleur de domaine, double-cliquez sur Paramètres NTDS .
5. Dans le menu Action , cliquez sur Propriétés .
6. Sous l’onglet Général , vérifiez si la case à cocher Catalogue global est activée.
Pour plus d’informations, reportez-vous aux rubriques suivantes :
Récupération de la forêt Active Directory : prise d’un rôle de maître d’opérations
Planification de l’emplacement des rôles de maître d’opérations
Définir ou transférer des rôles FSMO

Vous pouvez utiliser Windows PowerShell ou Ntdsutil pour saisir ou transférer des rôles. Pour obtenir plus
d’informations et consulter des exemples liés à l’utilisation de PowerShell pour ces tâches, consultez l’article
Move-ADDirectoryServerOperationMasterRole.
IMPORTANT
Si vous devez saisir le rôle de maître RID, envisagez d’utiliser l’applet de commande Move-
ADDirectoryServerOperationMasterRole au lieu de l’utilitaire Ntdsutil.exe.
Pour éviter le risque de SID dupliqués dans le domaine, Ntdsutil incrémente de 10 000 le prochain RID disponible dans le
pool lorsque vous saisissez le rôle de maître RID. Ce comportement peut amener votre forêt à consommer complètement
ses plages disponibles de valeurs RID. En revanche, si vous utilisez l’applet de commande PowerShell pour prendre le rôle
Maître RID, le RID suivant disponible n’est pas affecté.
Pour prendre ou transférer les rôles FSMO à l’aide de l’utilitaire Ntdsutil, procédez comme suit :
1. Connectez-vous à un ordinateur membre sur lequel les outils AD RSAT sont installés ou à un contrôleur
de domaine situé dans la forêt où les rôles FSMO sont transférés.
NOTE
Il est recommandé de vous connecter au contrôleur de domaine auquel vous attribuez des rôles FSMO.
L’utilisateur connecté doit être membre du groupe Administrateurs d’entreprise pour pouvoir transférer les
rôles Contrôleur de schéma ou Maître d’opérations des noms de domaine, ou membre du groupe
Administrateurs de domaine du domaine où les rôles Émulateur PDC, Maître RID et Maître d’infrastructure
sont transférés.
2. Sélectionnez Démarrer > Exécuter , tapez ntdsutil dans la zone Ouvrir , puis sélectionnez OK .
3. Tapez roles, puis appuyez sur Entrée.
NOTE
Pour afficher la liste des commandes disponibles dans une invite de l’utilitaire Ntdsutil, tapez ?, puis appuyez sur
Entrée.
4. Tapez connections, puis appuyez sur Entrée.

5. Tapez connect to server <servername>, puis appuyez sur Entrée.
NOTE
Dans cette commande, <servername> correspond au nom du contrôleur de domaine auquel vous souhaitez
assigner le rôle FSMO.
6. À l’invite ser ver connections , tapez q, puis appuyez sur Entrée.
7. Effectuez l'une des opérations suivantes :
Pour transférer le rôle : tapez transfer <role>, puis appuyez sur Entrée.
NOTE
Dans cette commande, <role> correspond au rôle à transférer.
Pour prendre le rôle : tapez seize <role>, puis appuyez sur Entrée.
NOTE
Dans cette commande, <role> correspond au rôle à prendre.
Par exemple, pour définir le rôle de maître RID, tapez seize rid master. Des exceptions concernent le rôle
Émulateur PDC, dont la syntaxe est seize pdc , et le rôle Maître d’opérations des noms de domaine, dont
la syntaxe est seize naming master .
Pour afficher la liste des rôles que vous pouvez transférer ou prendre, tapez ? à l’invite fsmo
maintenance , puis appuyez sur Entrée, ou consultez la liste des rôles fournie au début de cet article.
8. À l’invite fsmo maintenance , tapez q, puis appuyez sur Entrée pour accéder à l’invite ntdsutil . Tapez q,
puis appuyez sur Entrée pour quitter l’utilitaire Ntdsutil.
Considérations relatives à la réparation ou à la suppression des

détenteurs de rôle précédents
Si c’est possible et si vous êtes en mesure de transférer les rôles au lieu de les prendre, corrigez le détenteur de
rôle précédent. Si vous ne pouvez pas corriger le détenteur de rôle précédent ou si vous avez pris les rôles,
supprimez le détenteur de rôle précédent du domaine.
IMPORTANT
Si vous envisagez d’utiliser l’ordinateur réparé en tant que contrôleur de domaine, il est recommandé de reconfigurer
l’ordinateur en contrôleur de domaine à partir de zéro au lieu de restaurer le contrôleur de domaine à partir d’une
sauvegarde. Le processus de restauration régénère le contrôleur de domaine en tant que détenteur de rôle.
Pour remettre l’ordinateur réparé dans la forêt en tant que contrôleur de domaine
Formatez le disque dur de l’ancien détenteur de rôle, puis réinstallez Windows sur l’ordinateur.
Rétrogradez de force l’ancien détenteur de rôle en serveur membre.
2. Sur un autre contrôleur de domaine de la forêt, utilisez Ntdsutil pour supprimer les métadonnées
de l’ancien détenteur de rôle. Pour plus d’informations, consultez la section Nettoyer les
métadonnées du serveur à l’aide de Ntdsutil.
3. Après avoir nettoyé les métadonnées, vous pouvez à nouveau promouvoir l’ordinateur en
contrôleur de domaine et lui retransférer un rôle.
Pour supprimer l’ordinateur de la forêt après avoir pris ses rôles
1. Supprimez l’ordinateur du domaine.
2. Sur un autre contrôleur de domaine de la forêt, utilisez Ntdsutil pour supprimer les métadonnées de
l’ancien détenteur de rôle. Pour plus d’informations, consultez la section Nettoyer les métadonnées du
serveur à l’aide de Ntdsutil.
Considérations relatives à la réintégration des îles de réplication

Quand une partie d’un domaine ou d’une forêt ne peut pas communiquer avec le reste du domaine ou de la
forêt pendant une période prolongée, les sections isolées du domaine ou de la forêt sont appelées « îles de
réplication ». Les contrôleurs de domaine d’une île ne peuvent pas se répliquer avec les contrôleurs de domaine
d’autres îles. Après plusieurs cycles de réplication, les îles de réplication ne sont plus synchronisées. Si chaque île
possède ses propres détenteurs de rôle FSMO, des problèmes peuvent se produire lors de la restauration de la
communication entre les îles.
IMPORTANT
Dans la plupart des cas, vous pouvez tirer parti de l’exigence de réplication initiale (comme décrit dans cet article) pour
éliminer les détenteurs de rôle en double. Un détenteur de rôle redémarré doit abandonner le rôle s’il détecte un
détenteur de rôle en double.
Dans certains cas, il est impossible de résoudre ce comportement. Les informations contenues dans cette section peuvent
alors être utiles.
Le tableau ci-dessous identifie les rôles FMSO qui peuvent poser des problèmes si une forêt ou un domaine
comporte plusieurs détenteurs pour ce rôle :
C O N F L IT S P OT EN T IEL S EN T RE P L USIEURS DÉT EN T EURS DE

RO L E RÔ L E ?
Contrôleur de schéma Oui
Maître d’opérations des noms de domaine Oui
Maître RID Oui
Émulateur PDC Non
Maître d’infrastructure Non
Ce problème ne concerne pas l’émulateur PDC et le maître d’infrastructure. Ces détenteurs de rôle ne
conservent pas les données opérationnelles. En outre, le maître d’infrastructure n’apporte pas souvent de
modifications. Par conséquent, si plusieurs îles comportent ces détenteurs de rôles, vous pouvez les réintégrer
sans provoquer de problèmes à long terme.
Le contrôleur de schéma, le maître d’opérations des noms de domaine et le maître RID peuvent créer des objets
et conserver les modifications dans Active Directory. Chaque île qui possède l’un de ces détenteurs de rôle peut
avoir des objets Schéma, des domaines ou des pools RID en double et en conflit au moment de la restauration
de la réplication. Avant de réintégrer des îles, déterminez les détenteurs de rôle à conserver. Supprimez les
contrôleurs de schéma, les maîtres d’opérations des noms de domaine et les maîtres RID en double éventuels en
suivant les procédures de réparation, de suppression et de nettoyage mentionnées dans cet article.
References
Pour plus d’informations, reportez-vous aux rubriques suivantes :
Rôles FSMO Active Directory dans Windows
Placement et optimisation FSMO sur les contrôleurs de domaine Active Directory
Procédure de transfert et de prise des opérations à maître unique flottant
PROCÉDURE : Utiliser Ntdsutil pour rechercher et nettoyer les identificateurs de sécurité en double dans
Windows Server
Résoudre les problèmes d’ID d’événement DNS 4013 : Le serveur DNS n’a pas pu charger les zones DNS
intégrées à AD
La rétrogradation DCPROMO échoue si elle ne parvient pas à contacter le maître d’infrastructure DNS
Rôles FSMO
Effectuer une récupération initiale
Récupération de la forêt Active Directory : prise d’un rôle de maître d’opérations
Nettoyer les métadonnées du serveur à l’aide de Ntdsutil
Planification de l’emplacement des rôles de maître d’opérations
Move-ADDirectoryServerOperationMasterRole
Comment afficher et transférer des rôles FSMO
Cet article décrit comment afficher et transférer des rôles FSMO.

Résumé
Cet article décrit comment transférer des rôles FSMO (opérations à maître unique flottant), également appelés
rôles de maître d’opérations, à l’aide des outils de composant logiciel enfichable Active Directory dans MMC
(Microsoft Management Console) dans Windows Server 2003.
Rôles FSMO
Dans une forêt, au moins cinq rôles FSMO sont attribués à un ou plusieurs contrôleurs de domaine. Les cinq
rôles FSMO sont les suivants :
Contrôleur de schéma : le contrôleur de schéma du domaine contrôle toutes les mises à jour et les
modifications apportées au schéma. Pour mettre à jour le schéma d’une forêt, vous devez avoir accès au
contrôleur de schéma. Il ne peut y avoir qu’un seul contrôleur de schéma dans toute la forêt.
Maître d’opérations des noms de domaine : le maître d’opérations des noms de domaine contrôle l’ajout ou
la suppression de domaines dans la forêt. Il ne peut y avoir qu’un seul maître d’opérations des noms de
domaine dans toute la forêt.
Maître d’infrastructure : l’infrastructure est responsable de la mise à jour des références des objets de son
domaine vers des objets d’autres domaines. À tout moment, il ne peut y avoir qu’un seul contrôleur de
domaine agissant en tant que maître d’infrastructure dans chaque domaine.
Maître des ID relatifs (RID) : le maître RID est responsable du traitement des demandes de pool RID
provenant de tous les contrôleurs de domaine d’un domaine particulier. À tout moment, il ne peut y avoir
qu’un seul contrôleur de domaine agissant en tant que maître RID dans le domaine.
Émulateur PDC : l’émulateur PDC est un contrôleur de domaine qui se présente comme le contrôleur de
domaine principal (PDC) pour les stations de travail, les serveurs membres et les contrôleurs de domaine qui
exécutent des versions antérieures de Windows. Par exemple, si le domaine contient des ordinateurs qui
n’exécutent pas le logiciel client Microsoft Windows XP Professionnel ou Microsoft Windows 2000, ou s’il
contient des contrôleurs de domaine secondaires Microsoft Windows NT, l’émulateur PDC agit comme un
PDC Windows NT. Il s’agit également de l’explorateur principal de domaine, qui gère les incohérences de mot
de passe. À tout moment, il ne peut y avoir qu’un seul contrôleur de domaine agissant comme émulateur
PDC dans chaque domaine de la forêt.
Vous pouvez transférer des rôles FSMO à l’aide de l’utilitaire de ligne de commande Ntdsutil.exe ou à l’aide d’un
outil enfichable MMC. Selon le rôle FSMO que vous souhaitez transférer, vous pouvez utiliser l’un des trois outils
enfichables MMC suivants :
Composant logiciel enfichable Schéma Active Directory
Composant logiciel enfichable Domaines et approbations Active Directory
Utilisateurs et ordinateurs Active Directory
Si un ordinateur n’existe plus, le rôle doit être saisi. Pour saisir un rôle, employez l’utilitaire Ntdsutil.exe.
Pour savoir comment employer l’utilitaire Ntdsutil.exe pour saisir des rôles FSMO, cliquez sur le numéro ci-
dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
255504 Utiliser Ntdsutil.exe pour saisir ou transférer les rôles FSMO vers un domaine
Utiliser le composant logiciel enfichable Contrôleur de schéma Active Directory pour transférer le rôle de
contrôleur de schéma. Avant de pouvoir utiliser ce composant logiciel enfichable, vous devez inscrire le fichier
Schmmgmt.dll.
Inscrire Schmmgmt.dll
2. Tapez regsvr32 schmmgmt.dll dans la zone Ouvrir, puis cliquez sur OK.
3. Cliquez sur OK lorsque vous recevez le message indiquant que l’opération a réussi.
Transférer le rôle de contrôleur de schéma
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez mmc dans la zone de texte Ouvrir, puis cliquez sur OK.
2. Dans le menu Fichier, cliquez sur Ajouter/Supprimer un composant logiciel enfichable .
3. Cliquez sur Ajouter.
4. Cliquez sur Schéma Active Directory, puis sur Ajouter, puis Fermer, puis OK.
5. Dans l’arborescence de la console, cliquez avec le bouton droit sur Schéma Active Directory, puis cliquez sur
Modifier le contrôleur de domaine.
6. Cliquez sur Spécifier le nom, tapez le nom du contrôleur de domaine qui sera le nouveau titulaire du rôle,
puis cliquez sur OK.
7. Dans l’arborescence de la console, cliquez avec le bouton droit sur Schéma Active Directory, puis cliquez sur
Maître d’opérations.
8. Cliquez sur Modifier.
9. Cliquez sur OK pour confirmer que vous souhaitez transférer le rôle, puis cliquez sur Fermer.
Transférer le rôle de Maître d’opérations des noms de domaine
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Domaines et approbations
Active Director y .
2. Cliquez avec le bouton droit sur Domaines et approbations Active Director y , puis cliquez sur Se
connecter au contrôleur de domaine .
NOTE
Vous devez effectuer cette étape si vous n’êtes pas sur le contrôleur de domaine auquel vous souhaitez transférer
le rôle. Vous ne devez toutefois pas l’effectuer si vous êtes déjà connecté au contrôleur de domaine dont vous
souhaitez transférer le rôle.
3. Effectuez l’une des opérations suivantes :

Dans la zone Entrez le nom d’un autre contrôleur de domaine , tapez le nom du contrôleur de
domaine qui sera le nouveau détenteur du rôle, puis cliquez sur OK.
ou -
Dans la liste Ou sélectionner un contrôleur de domaine disponible , cliquez sur le contrôleur de
4. Dans l’arborescence de la console, cliquez avec le bouton droit sur Domaines et approbations Active
Director y , puis cliquez sur Maître d’opérations.
5. Cliquez sur Modifier.
Transférer les rôles Maître RID, Émulateur PDC et Maître d’infrastructure
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Utilisateurs et ordinateurs
Active Director y .
2. Cliquez avec le bouton droit sur Utilisateurs et ordinateurs Active Director y , puis cliquez sur Se
connecter au contrôleur de domaine .
NOTE
Vous devez effectuer cette étape si vous n’êtes pas sur le contrôleur de domaine auquel vous souhaitez transférer
le rôle. Vous ne devez toutefois pas l’effectuer si vous êtes déjà connecté au contrôleur de domaine dont vous
souhaitez transférer le rôle.
3. Effectuez l’une des opérations suivantes :

Dans la zone Entrez le nom d’un autre contrôleur de domaine , tapez le nom du contrôleur de
ou -
Dans la liste Ou sélectionner un contrôleur de domaine disponible , cliquez sur le contrôleur de
4. Dans l’arborescence de la console, cliquez avec le bouton droit sur Utilisateurs et ordinateurs Active
Director y , pointez sur Toutes les tâches, puis cliquez sur Maître d’opérations.
5. Cliquez sur l’onglet correspondant au rôle à transférer (RID, PDC ou Infrastructure), puis cliquez sur
Modifier.
Fonctionnalités de modification de mot de passe et
de résolution des conflits Windows
Cet article décrit une nouvelle valeur de Registre qui peut être utilisée par l’administrateur pour contrôler le
moment où le PDC est contacté, ce qui permet de réduire les coûts de communication entre les sites.
IMPORTANT
façon de restaurer, de restaurer et de modifier le Registre, voir Windows registre pour les utilisateurs avancés.

Résumé
Par défaut, lorsqu’un mot de passe de compte d’ordinateur ou de mot de passe d’utilisateur est modifié, ou
qu’un contrôleur de domaine reçoit une demande d’authentification client à l’aide d’un mot de passe incorrect,
le contrôleur de domaine Windows agissant en tant que propriétaire du rôle FSMO (Flexible Single Master
Operation) du contrôleur de domaine principal pour le domaine Windows est contacté. Cet article décrit une
nouvelle valeur de Registre qui peut être utilisée par l’administrateur pour contrôler le moment où le PDC est
contacté, ce qui permet de réduire les coûts de communication entre les sites.
WARNING
La valeur de Registre suivante peut être modifiée pour contrôler la notification de mot de passe et la résolution
des conflits de mots de passe, comme décrit ci-dessous :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
Valeur de Registre : AvoidPdcOnWan

Type de Registre : REG_DWORD
Données de la valeur de Registre : 0 (ou valeur non présente) ou 1
0 ou valeur non présente = FALSE (pour désactiver)
1 = TRUE (pour activer)
Valeur par défaut : (la valeur n’est pas présente)
Plateforme : uniquement Windows 2 000 contrôleurs de domaine
Notification de modification de mot de passe
Par défaut, les modifications de mot de passe de compte d’ordinateur et de mot de passe utilisateur sont
envoyées immédiatement au FSMO PDC. Dans un domaine en mode mixte, si un contrôleur de domaine
Windows NT 4.0 reçoit la demande, le client est envoyé au propriétaire du rôle FSMO PDC (qui doit être un
ordinateur Windows 2000) pour effectuer la modification du mot de passe. Cette modification est ensuite
répliquée sur d’autres contrôleurs de domaine Windows 2000 à l’aide de la réplication Active Directory, et sur
les contrôleurs de domaine de bas niveau via le processus de réplication de bas niveau. Si un contrôleur de
domaine Windows 2000 reçoit la demande (en mode mixte ou natif), la modification du mot de passe est
effectuée localement, envoyée immédiatement au propriétaire du rôle FSMO PDC à l’aide du service Netlogon
sous la forme d’un appel de procédure distante (RPC), puis la modification de mot de passe est répliquée à ses
partenaires à l’aide du processus de réplication Active Directory. Les contrôleurs de domaine de bas niveau
répliquent la modification directement à partir du propriétaire du rôle FSMO PDC.
Si la valeur AvoidPdcOnWan est définie sur TRUE et que le FSMO PDC se trouve sur un autre site, la
modification du mot de passe n’est pas immédiatement envoyée au PDC. Toutefois, elle est avertie de la
modification par le biais de la réplication Active Directory normale, qui la réplique à son tour sur les contrôleurs
de domaine de bas niveau (si le domaine est en mode mixte). Si le FSMO PDC se trouve sur le même site, la
valeur AvoidPdcOnWan est ignorée et la modification du mot de passe est immédiatement communiquée au
PDC.
Il se peut qu’un mot de passe mis à jour ne soit pas envoyé à l’émulateur PDC même si AvoidPdcOnWan a la
police FALSE ou n’est pas définie, s’il existe des problèmes lors de l’envoi de la demande au PDC, par exemple
une panne réseau. Aucune erreur n’est consignée dans ce cas. La mise à jour est ensuite distribuée à l’aide de la
réplication AD normale.
Résolution de conflit de mot de passe
Par défaut, Windows de domaine interrogent le propriétaire du rôle FSMO PDC si un client tente de
s’authentifier à l’aide d’un mot de passe incorrect en fonction de sa base de données locale. Si le mot de passe
envoyé par le client est correct sur le PDC, le client est autorisé à accéder et le contrôleur de domaine réplique la
modification du mot de passe.
La valeur AvoidPdcOnWan peut être utilisée par les administrateurs pour contrôler quand les contrôleurs de
domaine Active Directory tentent d’utiliser le propriétaire du rôle FSMO PDC pour résoudre les conflits de mots
de passe.
Si la valeur AvoidPdcOnWan est définie sur TRUE et que le propriétaire du rôle FSMO PDC se trouve sur un
autre site, le contrôleur de domaine n’essaie pas d’authentifier un client par rapport aux informations de mot de
passe stockées sur le FSMO PDC. Notez toutefois que cela entraîne le refus de l’accès au client.
Un mot de passe incorrect peut ne pas être essayé sur l’émulateur PDC même si AvoidPdcOnWan a la false ou
n’est pas définie, s’il existe des problèmes lors de l’envoi de la demande au PDC, par exemple une panne réseau.
Aucune erreur n’est consignée dans ce cas. La tentative d’accès est refusée dans ce cas.
Processus flexible de transfert et de crise de
l’opération mono-maître
Cet article explique comment les rôles FSMO (Flexible Single Master Operations) sont transférés d’un contrôleur
de domaine à un autre et comment ce rôle peut être nommé de force dans le cas où le contrôleur de domaine
qui détenait précédemment le rôle n’est plus disponible.
Transfert du rôle d’opération maître unique flexible

Le transfert d’un rôle FSMO est la forme suggérée de déplacement d’un rôle FSMO entre les contrôleurs de
domaine et peut être initié par l’administrateur ou par rétrogradation d’un contrôleur de domaine, mais n’est
pas initié automatiquement par le système d’exploitation. Cela inclut un serveur en état d’arrêt. Les rôles FSMO
ne sont pas automatiquement déplacés pendant le processus d’arrêt ; vous devez prendre cela en compte lors
de l’arrêt d’un contrôleur de domaine qui a un rôle FSMO pour la maintenance, par exemple.
Dans le cas d’un transfert d’un rôle FSMO entre deux contrôleurs de domaine, une synchronisation des données
conservées par le propriétaire du rôle FSMO vers le serveur qui reçoit le rôle FSMO est effectuée avant le
transfert du rôle afin de s’assurer que toutes les modifications ont été enregistrées avant le changement de rôle.
Les attributs opérationnels sont des attributs qui se traduisent en une action sur le serveur. Ce type d’attribut
n’est pas défini dans le schéma, mais est conservé par le serveur et intercepté lorsqu’un client tente de lire ou
d’écrire dans celui-ci. Lorsque l’attribut est lu, le résultat est généralement un résultat calculé du serveur.
Lorsque l’attribut est écrit, une action prédéfinë se produit sur le contrôleur de domaine.
Les attributs opérationnels suivants sont utilisés pour transférer des rôles FSMO et se trouvent dans l’entrée
RootDSE (ou entrée spécifique d’une DSA racine), à la racine de l’arborescence Active Directory d’un contrôleur
de domaine donné où des informations spécifiques sur le contrôleur de domaine sont conservées. Lors de
l’écriture dans l’attribut opérationnel approprié sur le contrôleur de domaine pour recevoir le rôle FSMO,
l’ancien contrôleur de domaine est rétrogradé et le nouveau contrôleur de domaine est promu
automatiquement. Aucune intervention manuelle n’est requise. Les attributs opérationnels qui représentent les
rôles FSMO sont :
becomeRidMaster
becomeSchemaMaster
becomeDomainMaster
becomePDC
becomeInfrastructureMaster
Si l’administrateur spécifie le serveur devant recevoir le rôle FSMO à l’aide d’un outil tel que Ntdsutil, l’échange
du rôle FSMO est défini entre le propriétaire actuel et le contrôleur de domaine spécifié par l’administrateur.
Lorsqu’un contrôleur de domaine est rétrogradé, l’attribut opérationnel « GiveAwayAllFsmoRoles » est écrit, ce
qui déclenche le contrôleur de domaine à localiser d’autres contrôleurs de domaine pour décharger les rôles
qu’il possède actuellement. Windows 2000 détermine les rôles dont le contrôleur de domaine rétrogradé est
actuellement propriétaire et recherche un contrôleur de domaine approprié en suivant les règles suivantes :
1. Recherchez un serveur dans le même site.
2. Recherchez un serveur sur lequel il existe une connectivité RPC.
3. Utilisez un serveur sur un transport asynchrone (tel que SMTP).
Dans tous les transferts, si le rôle est un rôle spécifique au domaine, le rôle peut être déplacé uniquement vers
un autre contrôleur de domaine dans le même domaine. Dans le cas contraire, tout contrôleur de domaine dans
l’entreprise est candidat.
Saisir le rôle d’opération maître unique flexible

Les administrateurs doivent faire preuve d’une prudence extrême lors de la saisie des rôles FSMO. Cette
opération, dans la plupart des cas, doit être effectuée uniquement si le propriétaire du rôle FSMO d’origine ne
sera pas de nouveau dans l’environnement.
Lorsque l’administrateur saisit un rôle FSMO sur un ordinateur existant, l’attribut « fsmoRoleOwner » est
modifié sur l’objet qui représente la racine des données en contournant directement la synchronisation des
données et le transfert du rôle. L’attribut « fsmoRoleOwner » de chacun des objets suivants est écrit avec le nom
principal (DN) de l’objet Paramètres NTDS (données dans Active Directory qui définit un ordinateur en tant que
contrôleur de domaine) du contrôleur de domaine qui prend possession de ce rôle. À mesure que la réplication
de cette modification commence à se propager, les autres contrôleurs de domaine apprennent le changement de
rôle FSMO.
Contrôleur de domaine principal (PDC) FSMO : LDAP://DC=MICROSOFT,DC=COM RID Master FSMO :
LDAP://CN=Rid Manager$,CN=System,DC=MICROSOFT,DC=COM Schema Master FSMO:
LDAP://CN=Schema,CN=Configuration,DC=Microsoft,DC=Com Infrastructure Master FSMO:
LDAP://CN=Infrastructure,DC=Microsoft,DC=Com Domain Naming Master FSMO:
LDAP://CN=Partitions,CN=Configuration,DC=Microsoft, DC=Com Par exemple, si Server1 est le PDC dans le
domaine Microsoft.com et est retiré et que l’administrateur ne peut pas rétrograder l’ordinateur correctement,
server2 doit se voir attribuer le rôle FSMO du PDC. Après la crise du rôle, la valeur CN=NTDS
Paramètres,CN=SERVER2,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=Microsoft,DC=Com est présente sur l’objet suivant :
LDAP://DC=MICROSOFT,DC=COM
Références
Pour plus d’informations sur les rôles FSMO en général, voir l’article suivant dans la Base de connaissances
Microsoft :
Pour plus d’informations sur le placement correct des rôles FSMO, voir l’article suivant dans la Base de
223346 optimisation et placement FSMO sur Windows 2000 Domains
L’ID d’événement général ADAM 1161 est enregistré
sur un serveur AD LDS
Cet article décrit un problème dans lequel l’ID d’événement général ADAM 1161 est enregistré sur un serveur
AD LDS.
Symptômes
L’événement suivant est consigné dans le journal ADAM chaque fois qu’une instance est redémarré sur un
serveur AD LDS qui exécute Windows Server 2012 R2.
Cause
La table de hiérarchie du carnet d’adresses n’existe pas dans la base de données AD LDS (Active Directory
Lightweight Directory Services). Par conséquent, l’événement est déclenché au démarrage du service.
Cet événement peut être ignoré en toute sécurité sur une instance AD LDS.
Modifier un mot de passe d’utilisateur Windows
Active Directory et LDS via LDAP
Cet article explique comment modifier un mot de passe utilisateur Windows Active Directory et LDS via LDAP.
S’applique à : Windows Active Directory
Résumé
En fonction de certaines restrictions, vous pouvez définir un mot de passe Windows Active Directory and
Lightweight Directory Services (LDS) via le protocole LDAP (Lightweight Directory Access Protocol). Cet article
explique comment définir ou modifier l’attribut de mot de passe.
Ces étapes s’appliquent également aux utilisateurs ADAM (Active Directory Application Mode) et LDS et aux
objets userProxy de la même façon que pour les utilisateurs AD. Pour plus d’informations, consultez des
indications supplémentaires à la fin de l’article.
Le mot de passe est stocké dans la base de données AD et LDS sur un objet utilisateur dans l’attribut
unicodePwd . Cet attribut peut être écrit dans des conditions restreintes, mais ne peut pas être lu. L’attribut ne
peut être modifié que ; il ne peut pas être ajouté lors de la création d’un objet ou interrogé par une recherche.
Pour modifier cet attribut, le client doit disposer d’une connexion TLS (Transport Layer Security) /SSL (Secure
Socket Layer) 128 bits au serveur. Une session chiffrée utilisant des clés de session créées par SSP à l’aide de
Windows New Technology LAN Manager (NTLM) ou Kerberos est également acceptable tant que la longueur de
clé minimale est remplie.
Pour que cette connexion soit possible à l’aide de TLS/SSL :
Le serveur doit posséder un certificat de serveur pour une connexion RSA 128 bits.
Le client doit approuver l’autorité de certification qui a généré le certificat de serveur.
Le client et le serveur doivent être capables d’effectuer un chiffrement 128 bits.
La syntaxe de l’attribut unicodePwd est octet-string ; toutefois, le service d’annuaire s’attend à ce que la chaîne
d’octet contienne une chaîne UNICODE (comme le nom de l’attribut l’indique). Cela signifie que toutes les
valeurs de cet attribut passées dans LDAP doivent être des chaînes UNICODE encodées en BER (Règles
d’encodage de base) sous la forme d’une chaîne d’octet. En outre, la chaîne UNICODE doit commencer et se
terminer par des guillemets qui ne font pas partie du mot de passe souhaité.
Il existe deux façons possibles de modifier l’attribut unicodePwd . La première est similaire à une opération de
changement de mot de passe standard de l’utilisateur. Dans ce cas, la demande de modification doit contenir à la
fois une opération de suppression et une opération d’ajout. L’opération de suppression doit contenir le mot de
passe actuel avec des guillemets autour de celui-ci. L’opération d’ajout doit contenir le nouveau mot de passe
souhaité avec des guillemets autour.
La deuxième façon de modifier cet attribut est analogue à la réinitialisation par un administrateur d’un mot de
passe pour un utilisateur. Pour ce faire, le client doit lier en tant qu’utilisateur disposant des autorisations
suffisantes pour modifier le mot de passe d’un autre utilisateur. Cette demande de modification doit contenir
une opération de remplacement unique avec le nouveau mot de passe souhaité entouré de guillemets. Si le
client dispose d’autorisations suffisantes, ce mot de passe devient le nouveau mot de passe, quel que soit
l’ancien mot de passe.
Les deux fonctions suivantes fournissent des exemples de ces opérations :
ULONG ChangeUserPassword(WCHAR* pszUserDN, WCHAR* pszOldPassword,WCHAR* pszNewPassword)

{
ULONG err = 1;
LDAPMod modNewPassword;
LDAPMod modOldPassword;
LDAPMod *modEntry[3];
BERVAL newPwdBerVal;
BERVAL oldPwdBerVal;
BERVAL *newPwd_attr[2];
BERVAL *oldPwd_attr[2];
WCHAR pszNewPasswordWithQuotes[1024];
WCHAR pszOldPasswordWithQuotes[1024];
// Build an array of LDAPMod.
// For setting unicodePwd, this MUST be a double op.

modEntry[0] = &modOldPassword;
modEntry[1] = &modNewPassword;
modEntry[2] = NULL;
// Build mod struct for unicodePwd Add.

modNewPassword.mod_op = LDAP_MOD_ADD | LDAP_MOD_BVALUES;
modNewPassword.mod_type =L"unicodePwd";
modNewPassword.mod_vals.modv_bvals = newPwd_attr;
// Build mod struct for unicodePwd Delete.

modOldPassword.mod_op = LDAP_MOD_DELETE | LDAP_MOD_BVALUES;
modOldPassword.mod_type =L"unicodePwd";
modOldPassword.mod_vals.modv_bvals = oldPwd_attr;
// Password will be single valued, so we only have one element.

newPwd_attr[0] = &newPwdBerVal;
newPwd_attr[1]= NULL;
oldPwd_attr[0] = &oldPwdBerVal;
oldPwd_attr[1]= NULL;
// Surround the passwords in quotes.

wsprintf(pszNewPasswordWithQuotes,L"\"%s\"",pszNewPassword);
wsprintf(pszOldPasswordWithQuotes,L"\"%s\"",pszOldPassword);
// Build the BER structures with the UNICODE passwords w/quotes.

newPwdBerVal.bv_len = wcslen(pszNewPasswordWithQuotes) * sizeof(WCHAR);
newPwdBerVal.bv_val = (char*)pszNewPasswordWithQuotes;
oldPwdBerVal.bv_len = wcslen(pszOldPasswordWithQuotes) * sizeof(WCHAR);
oldPwdBerVal.bv_val = (char*)pszOldPasswordWithQuotes;
// Perform single modify.

err = ldap_modify_s(ldapConnection,
pszUserDN,
modEntry
);
if (err == LDAP_SUCCESS )
wprintf(L"\nPassword successfully changed!\n");
else
wprintf(L"\nPassword change failed!\n");
return err;
}
ULONG SetUserPassword(WCHAR* pszUserDN, WCHAR* pszPassword)

{
{
ULONG err = 1;
LDAPMod modPassword;
LDAPMod *modEntry[2];
BERVAL pwdBerVal;
BERVAL *pwd_attr[2];
WCHAR pszPasswordWithQuotes[1024];
// Build an array of LDAPMod.

// For setting unicodePwd, this MUST be a single op.
modEntry[0] = &modPassword;
modEntry[1] = NULL;
// Build mod struct for unicodePwd.

modPassword.mod_op = LDAP_MOD_REPLACE | LDAP_MOD_BVALUES;
modPassword.mod_type =L"unicodePwd";
modPassword.mod_vals.modv_bvals = pwd_attr;
// Password will be single valued, so we only have one element.

pwd_attr[0] = &pwdBerVal;
pwd_attr[1]= NULL;
// Surround the password in quotes.

wsprintf(pszPasswordWithQuotes,L"\"%s\"",pszPassword);
// Build the BER structure with the UNICODE password.

pwdBerVal.bv_len = wcslen(pszPasswordWithQuotes) * sizeof(WCHAR);
pwdBerVal.bv_val = (char*)pszPasswordWithQuotes;
// Perform single modify.

err = ldap_modify_s(ldapConnection,
pszUserDN,
modEntry
);
if (err == LDAP_SUCCESS )
wprintf(L"\nPassword succesfully set!\n");
else
wprintf(L"\nPassword set failed!\n");
return err;
}
TIP
Pour configurer des instances LDS à l’aide d’objets UserProxy pour les réinitialisations de mot de passe, vous devez
autoriser la délégation contrainte du compte de service LDS (par défaut : compte d’ordinateur LDS) aux contrôleurs de
domaine au cas où l’ouverture de session utilisateur utiliserait Kerberos.
Si vous utilisez une liaison simple LDAP, vous devez utiliser Windows Server 2022 ou une version plus récente et définir
une entrée de Registre pour transférer les informations d’identification de session LDAP administrateur au contrôleur
domaine Active Directory :
Clé de Registre : HKLM\system\currentcontrolset\services<LDS Instance>\Parameters
Entrée du Registre : Autoriser le type d’ouverture de session ClearText
Type : REG_DWORD
Données : 0 : ne pas autoriser le transfert des informations d’identification (par défaut)
1 : Autoriser le transfert des informations d’identification pour la réinitialisation du mot de passe
Notez que la modification dans les deux cas signifie que le serveur LDS doit être considéré comme un appareil de
niveau 0, car il peut démarrer des tâches sensibles à la sécurité sur le contrôleur de domaine.
S’applique à
Windows Server 2012 Datacenter
Windows Server 2012 Standard
Windows Server 2012 R2Centre de données
Windows Server 2012 R2 Standard
Windows Server 2016
Windows Server 2019
Windows Server 2022
Windows 8.1 Entreprise
Windows 8.1 Professionnel
Windows 10
Windows 11
Masquer ou afficher la classe d’objet InetOrgPerson
dans utilisateurs et ordinateurs Active Directory
Cet article explique comment masquer ou afficher la classe d’objet InetOrgPerson dans Utilisateurs et
ordinateurs Active Directory.
Résumé
Dans Windows Server 2003 et versions ultérieures d’Active Directory, une classe d’objet supplémentaire est
introduite. Classe d’objet InetOrgPerson. InetOrgPerson est défini dans la norme RFC 2798 et a été accepté
comme norme de d’autres implémentations d’annuaire LDAP (Lightweight Directory Access Protocol).
Active Directory a été modifié pour prendre en charge la classe InetOrgPerson et, avec l’ajout de la définition de
classe User, vous pouvez désormais créer InetOrgPerson en tant que principaux de sécurité dans Active
Directory. Cela améliore grandement les capacités d’un administrateur pour migrer des comptes d’utilisateurs
d’annuaires tiers vers Active Directory.
Toutefois, cette modification peut introduire des problèmes avec des programmes tiers (les programmes tiers
sont définis comme des programmes qui utilisent Active Directory comme méthode d’authentification).
Microsoft recommande d’effectuer des tests complets de compatibilité des programmes avant d’utiliser la classe
InetOrgPerson.
Pour cette raison et pour éviter toute confusion, vous pouvez désactiver les références visibles au type d’objet
InetOrgPerson dans Utilisateurs et ordinateurs Active Directory. Cela empêche les administrateurs de créer par
erreur des utilisateurs InetOrgPerson au lieu du type d’utilisateur le plus accepté.
Pour activer ou désactiver le type d’utilisateur InetOrgPerson dans Utilisateurs et ordinateurs Active Directory,
1. Connectez-vous au contrôleur de domaine Windows Server 2003 qui détient le rôle FSMO contrôleur de
schéma en tant que compte avec des autorisations d’administrateur de schéma.
2. Ouvrez le logiciel en snap-in Adsiedit Microsoft Management Console (MMC).
3. Dans le dossier Schéma, recherchez l’objet CN=InetOrgPersonClass. Cliquez avec le bouton droit sur cet
objet, puis cliquez sur Propriétés.
4. Recherchez l’attribut defaultHidingValue, puis modifiez sa valeur en fonction de votre résultat attendu. Si
vous définissez cette valeur sur True, cela masque le type d’objet InetOrgPerson dans Utilisateurs et
ordinateurs Active Directory. Si vous définissez cette valeur sur False, le type d’objet s’affiche.
5. Une fois la valeur définie, cliquez sur Appliquer, puis sur OK. Autorisez la latence de réplication standard,
puis redémarrez toutes les instances des utilisateurs et ordinateurs Active Directory.Si vous définissez
l’attribut defaultHidingValue sur False, vous pouvez créer de nouveaux utilisateurs du type InetOrgPerson.
Avec DefaultHidingValue définie sur True, cette fonctionnalité est supprimée.
NOTE
Cela est vrai uniquement pour les utilisateurs et ordinateurs Active Directory. Vous pouvez toujours créer les types
d’utilisateurs InetOrgPerson par d’autres moyens, quel que soit ce paramètre.
Comment configurer la journalisation des
événements de diagnostic Active Directory et LDS
Cet article pas à pas décrit comment configurer la journalisation des événements de diagnostic Active Directory
dans les systèmes d’exploitation Microsoft Windows Server.
S’applique à : Windows Server 2019, , Windows Server 2016, Windows Server 2012 R2, Windows 7 Service
Pack 1
Résumé
Active Directory enregistre les événements dans le journal des services d’annuaire ou de l’instance LDS dans
l’Observateur d’événements. Vous pouvez utiliser les informations collectées dans le journal pour diagnostiquer
et résoudre les problèmes éventuels ou surveiller l’activité des événements liés à Active Directory sur votre
serveur.
Par défaut, Active Directory enregistre uniquement les événements critiques et les événements d’erreur dans le
journal du service d’annuaire. Pour configurer Active Directory afin d’enregistrer d’autres événements, vous
devez augmenter le niveau de journalisation en éditant le Registre.
Journalisation des événements de diagnostic Active Directory

Les entrées de Registre qui gèrent la journalisation des diagnostics pour Active Directory sont stockées dans les
sous-clés de Registre suivantes.
Contrôleur de domaine : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
LDS : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS instance name>\Diagnostics
Chacune des valeurs REG_DWORD suivantes sous la sous-clé représente un type d’événement qui peut être
Diagnostics écrit dans le journal des événements :
1. Vérification de la cohérence des connaissances (KCC)

2. Événements de sécurité
3. Événements d’interface ExDS
4. Événements d’interface MAPI
5. Événements de réplication
6. Garbage Collection
7. Configuration interne
8. Accès à l’annuaire
9. Traitement interne
10. Compteurs de performance
11. Initialisation/résiliation
12. Contrôle de service
13. Résolution de noms
14. Sauvegarde
15. Ingénierie de champ
16. Événements d’interface LDAP
17. Configuration
18. Catalogue global
19. Messagerie inters site
20. Mise en cache de groupe
21. Linked-Value réplication des Linked-Value
22. DS RPC Client
23. Serveur RPC DS
24. Schéma DS
25. Moteur de transformation
26. Contrôle d’accès basé sur les revendications
Niveaux de journalisation
Chaque entrée peut être affectée d’une valeur de 0 à 5, et cette valeur détermine le niveau de détail des
événements qui sont enregistrés. Les niveaux de journalisation sont décrits comme :
0 (aucun) : seuls les événements critiques et les événements d’erreur sont enregistrés à ce niveau. Il s’agit du
paramètre par défaut pour toutes les entrées et il ne doit être modifié que si un problème se produit et que
vous souhaitez examiner.
1 (minimal) : les événements de haut niveau sont enregistrés dans le journal des événements à ce niveau. Les
événements peuvent inclure un message pour chaque tâche principale effectuée par le service. Utilisez ce
paramètre pour lancer une enquête lorsque vous ne connaissez pas l’emplacement du problème.
2 (de base)
3 (étendue) : ce niveau enregistre des informations plus détaillées que les niveaux inférieurs, telles que les
étapes effectuées pour effectuer une tâche. Utilisez ce paramètre lorsque vous avez réduit le problème à un
service ou à un groupe de catégories.
4 (verbose)
5 (interne) : ce niveau enregistre tous les événements, y compris les chaînes de débogage et les modifications
de configuration. Un journal complet du service est enregistré. Utilisez ce paramètre lorsque vous avez suivi
le problème vers une catégorie particulière d’un petit ensemble de catégories.
Comment configurer la journalisation des événements de diagnostic

Active Directory
Pour configurer la journalisation des événements de diagnostic Active Directory, suivez ces étapes.
IMPORTANT
Windows .

2. Dans la zone Ouvrir, tapez regedit puis cliquez sur OK .
3. Recherchez et sélectionnez les clés de Registre suivantes.
Contrôleur de domaine : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
LDS : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS instance name>\Diagnostics
Chaque entrée affichée dans le volet droit de la fenêtre De l’Éditeur du Registre représente un type
d’événement qu’Active Directory peut journaliser. Toutes les entrées sont définies sur la valeur par défaut
0 (Aucune).
4. Configurez la journalisation des événements pour le composant approprié :
a. Dans le volet droit de l’Éditeur du Registre, double-cliquez sur l’entrée qui représente le type
d’événement pour lequel vous souhaitez journaliser. Par exemple, événements de sécurité.
b. Tapez le niveau de journalisation que vous souhaitez (par exemple, 2) dans la zone de données Valeur,
puis sélectionnez OK .
5. Répétez l’étape 4 pour chaque composant que vous souhaitez enregistrer.
6. Dans le menu Registre, sélectionnez Quitter pour quitter l’Éditeur du Registre.
NOTE
Les niveaux de journalisation doivent être fixés à la valeur par défaut 0 (Aucun), sauf si vous examinez un
problème.
Lorsque vous augmentez le niveau de journalisation, les détails de chaque message et le nombre de messages
écrits dans le journal des événements augmentent également. Un niveau de diagnostic supérieur ou supérieur
à 3 n’est pas recommandé, car la journalisation à ces niveaux nécessite plus de ressources système et peut
dégrader les performances de votre serveur. Veillez à réinitialiser les entrées sur 0 une fois que vous avez
terminé d’examiner le problème.
Les opérations LDAP anonymes vers Active
Directory sont désactivées sur les contrôleurs de
domaine
Cet article fournit des informations sur le problème de désactivation des opérations LDAP anonymes dans
Active Directory sur les contrôleurs de domaine.
Résumé
Par défaut, les opérations LDAP (Lightweight Directory Access Protocol) anonymes sur Active Directory, autres
que les recherches et les liaisons rootDSE, ne sont pas autorisées dans Microsoft Windows Server 2003.
Active Directory dans les versions antérieures de Microsoft Windows domaines basés sur un rôle accepte les
demandes anonymes. Dans ces versions, un résultat positif dépend du fait que les autorisations utilisateur sont
correctes dans Active Directory.
Avec Windows Server 2003, seuls les utilisateurs authentifiés peuvent lancer une demande LDAP auprès des
contrôleurs de domaine basés sur Windows Server 2003. Vous pouvez remplacer ce nouveau comportement
par défaut en modifiant le septième caractère de l’attribut dsHeuristics sur le chemin DN comme suit :
CN=Service d’annuaire,CN=Windows NT,CN=Services,CN=Configuration, Domaine racine dans la forêt
Le paramètre DsHeuristics s’applique à tous Windows de domaine basés sur Server 2003 dans la même forêt.
La valeur est réalisée par les contrôleurs de domaine lors de la réplication Active Directory sans redémarrer
Windows. Les contrôleurs de domaine Microsoft Windows 2000 ne sont pas en charge et ne limitent pas les
opérations anonymes si elles sont présentes dans une forêt Windows Server 2003.
Les valeurs valides pour l’attribut dsHeuristic sont 0 et 0000002. Par défaut, l’attribut DsHeuristics n’existe pas,
mais sa valeur interne par défaut est 0. Si vous définissez le septième caractère sur 2 (0000002), les clients
anonymes peuvent effectuer n’importe quelle opération autorisée par la liste de contrôle d’accès (ACL), tout
comme les contrôleurs de domaine basés sur Windows 2000.
NOTE
Si l’attribut est déjà définie, ne modifiez pas les caractères de la chaîne DsHeuristics autres que le septième caractère. Si la
valeur n’est pas définie, veillez à fournir les zéros non avant jusqu’au septième caractère. En outre, vous pouvez utiliser
Adsiedit.msc pour apporter la modification à l’attribut.
La chaîne dsHeuristics sur un contrôleur de domaine dans la forêt .com Forest_Name apparaît comme suit
lorsque vous l’affichez à l’aide de Ldp.exe. Seuls les attributs sélectionnés sont affichés.
>> Dn : CN=Service d’annuaire,CN=Windows NT,CN=Services,CN=Configuration,DC=

<forest_name>,DC=com
2> objectClass: top; nTDSService;
1> cn : service d’annuaire ;
1> dSHeuristics : 0000002; <-2 dans le septième caractère = anonyme
accès autorisé. Notez les zéros non avant.
1 nom> : Service d’annuaire ;
Échec du démarrage du service LDS après la
modification manuelle de msDS-Behavior-Version
dans Windows Server 2019 et 2016
Cet article fournit une solution à une erreur lors de l’échec du démarrage du service LDS après la modification
manuelle de msDS-Behavior-Version.
Symptôme
Dans ADSI Edit, vous modifiez l’attribut msDS-Behavior-Version du conteneur partitions sur 7 afin
d’augmenter le niveau fonctionnel de l’instance LDS (Active Directory) Lightweight Directory Services (ADS) à
WIN2016.
Après avoir redémarré le serveur ou arrêté le service LDS, le service LDS ne peut pas être démarré. Lorsque
vous essayez de démarrer manuellement le service, les erreurs d’événement suivantes sont consignées :
Nom du journal : ADAM (LDS)

Source : ADAM [LDS] Général
Catégorie de tâche : traitement interne
Niveau : Error
Mots clés : Classique
Utilisateur : LOGO ANONYME
Ordinateur : LDS.CONTOSO.COM
Description :
Erreur interne : une erreur des services AD DS (Active Directory Lightweight Directory Services) s’est
produite.
Valeur d’erreur (décimal) :
-1601
Valeur d’erreur (hex) :
fffff9bf
ID interne :
20801a4
En outre, le message d’erreur suivant s’affiche :
Windows n’a pas pu démarrer le <ServiceName> Service LDS sur l’ordinateur local.
Erreur 0xc0000025 : 0xc0000025
Cause
La définition manuelle de la valeur de l’attribut msDS-Behavior-Version sur 7 sur les instances LDS n’est pas
prise en charge.
Résolution
Si l’instance LDS ne contient qu’un seul serveur, vous devez restaurer le serveur à partir d’une sauvegarde pour
résoudre le problème.
S’il existe plusieurs serveurs réplicas dans cette instance (par exemple, LDSServer1 et LDSServer2) et si un
serveur n’a pas encore été redémarré, suivez les étapes suivantes :
1. Si le serveur LDS sur lequel le service qui ne démarre pas (par exemple, LDSServer1) détient les rôles
LDS (par exemple, Schema et Domain Naming FSMO), saisissez les rôles en exécutant ntdsutil :
C:\Windows\system32> ntdsutil
ntdsutil: roles
maintenance fsmo : connexions
connexions de serveur : se connecter au serveur LDSSer ver2:50000( 50000 est le numéro de
port dans cet exemple)
Liaison à LDSServer2:50000...
Connecté à LDSServer2:50000 à l’aide des informations d’identification de l’utilisateur connecté
localement.
connexions de serveur : q
Maintenance fsmo : maître de schéma seize
2. Connecter à la partition de configuration du serveur qui exécute toujours l’instance LDS (par exemple,
LDSServer2), puis retourne la version du niveau de fonctionnalité en reconstant la valeur de l’attribut
msDS-Behavior-Version.
3. Exécutez un nettoyage des métadonnées du serveur LDS (LDSServer1) à l’aide de dsmgmt :
C:\Windows\system32> dsmgmt
dsmgmt : nettoyage des métadonnées
nettoyage des métadonnées : connexions
connexions de serveur : connexion au serveur LDSSer ver2:50000 ( 50000 est le numéro de port
dans cet exemple)
Liaison à LDSServer2:50000... Connecté à LDSServer2:50000 à l’aide des informations d’identification
de l’utilisateur connecté localement. connexions de serveur : q
nettoyage des métadonnées : sélectionner la cible de l’opération
select operation target: list naming contexts
Found 3 Naming Context(s) 0 - CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-
3E5467888DEF} 1 - CN=Schema,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-
3E5467888DEF} 2 - DC=LDS,DC=COM select operation target: select naming context2 ( 2
signifie contexte d’appellation de domaine )
Aucun site actuel Aucun domaine actuel Aucun contexte d’attribution de noms de serveur actuel -
DC=LDS,DC=COM - Cible d’opération de sélection : liste des sites
Found 4 site(s) 0 - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-
4366-A8B8-3E5467888DEF} 1 - CN=Site1,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-
A8B8-3E5467888DEF} 2 - CN=Site2,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-
3E5467888DEF} 3 - CN=Site3,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-
3E5467888DEF} : sélectionnez site3 (où 3 est le numéro du site dans lequel se trouve le ser veur,
résultat correspondant à l’étape précédente)
Site - CN=Site3,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-3E5467888DEF}
Aucun domaine actuel Aucun contexte d’attribution de noms de serveur actuel - DC=LDS,DC=COM
select operation target: list ser vers in Site
Trouvé 1 serveur(s) 0 - CN=LDSServer1,CN=Servers,CN=Site3,CN=Sites,CN=Configuration,CN=
{6B7FEBF4-017B-4366-A8B8-3E5467888DEF} : sélectionnez Ser ver0 (où 0 est le numéro du
serveur que vous souhaitez supprimer, correspondant à la sortie de l’étape précédente)
Site - CN=Site3,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-A8B8-3E5467888DEF}
Aucun serveur de domaine actuel -
CN=LDSServer1,CN=Servers,CN=Site3,CN=Sites,CN=Configuration,CN={6B7FEBF4-017B-4366-
A8B8-3E5 Objet DSA } 467888DEF - CN=NTDS
Paramètres,CN=LDSServer1,CN=Servers,CN=Site3,CN=Sites,CN=Configuration,CN={6B7FEBF4-
017B-4366-A8B8-3E5467888DEF} Nom d’hôte DNS - contexte d’appellation
LDSServer1.CONTOSO.COM - DC=LDS,DC=COM select operation target : q
nettoyage des métadonnées : supprimer le ser veur sélectionné
4. Connectez-vous à LDSServer1 et désinstallez l’instance :
5. Exécutez le programme d’installation des services ADS (Active Directory Lightweight Directory Services)
(C:\Windows\ADAM\adaminstall.exe) sur LDSServer1 pour installer un réplica de l’instance existante à
partir de LDSServer2.
Nombreux événements « ID d’événement 1216 »
dans le journal des événements des services
d’annuaire
Cet article fournit une solution au problème où de nombreux événements « Event ID 1216 » se produisent dans
le journal des événements des services d’annuaire.
NOTE
la Base de connaissances Microsoft :
256986 description du Registre microsoft Windows
Symptômes
Vous pouvez trouver plusieurs instances de l’entrée suivante dans le journal des événements des services
d’annuaire :
Type d’événement : Avertissement

Source de l’événement : LDAP NTDS
Event Category:LDAP Interface
ID d’événement :1216
Date :<DateTime>
Heure :<DateTime>
Utilisateur : N/A
Computer:Computer
Description :
Le serveur LDAP a fermé un socket à un client en raison d’une condition d’erreur, 1234. (ID interne
c01028c::4294967295).
NOTE
La valeur de l’ID interne varie selon chaque instance.
Cause
Ce message du journal des événements se produit lorsqu’un client LDAP (Lightweight Directory Access
Protocol) envoie une demande à l’ordinateur à l’aide du protocole UDP (User Datagram Protocol), mais ne
conserve pas son socket ouvert pour écouter la réponse du serveur. Lorsque le serveur tente de renvoyer la
réponse, le message d’erreur est consigné dans le journal des événements. Il s’agit d’une erreur sans danger qui
peut se produire fréquemment dans des conditions de fonctionnement normales. Elle se produit uniquement si
le niveau de journalisation des diagnostics est augmenté en modifiant le niveau de journalisation LDAP sur 2 ou
plus dans le Registre.
Résolution
WARNING

1. Lancez un Éditeur du Registre (Regedt32.exe).
2. Recherchez la valeur des événements d’interface LDAP dans la clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
3. Définissez la valeur de données des événements d’interface LDAP sur un paramètre inférieur, puis cliquez sur
OK.
La valeur par défaut de cette valeur de Registre est 0.
Problèmes qui peuvent se produire avec de
nombreux contrôleurs de domaine dans les zones
DNS intégrées Active Directory

S’applique à : Versions de Windows Server Windows pris en charge
Symptômes
Les inscriptions DNS (Domain Name System) des enregistrements A (enregistrés par Netlogon) et des
enregistrements NS (ajoutés par les serveurs DNS faisant autorité) dans une zone DNS intégrée à Active
Directory pour certains DCS peuvent ne pas fonctionner dans un domaine qui contient un grand nombre de
DCS (généralement plus de 1 200). Si la zone DNS intégrée à Active Directory porte le même nom que le nom
de domaine Active Directory, les problèmes liés à l’inscription des enregistrements A et des enregistrements NS
à la racine de la zone semblent se produire dans un domaine avec plus de 400 DCs. En outre, un ou plusieurs
des messages d’erreur suivants peuvent être enregistrés dans le journal des événements :
Event Type: Error

Event Source: DNS
Event Category: None
Event ID: 4011
Description: The DNS server was unable to add or write an update of domain name xyz in zone xyz.example.com
to the Active Directory. Check that the Active Directory is functioning properly and add or update this
domain name using the DNS console. The event data contains the error.
Data: 0000: 2a 23 00 00 *#..
Event Type: Error

Event Source: DNS
Event ID: 4015
Description: The DNS server has encountered a critical error from the Active Directory. Check that the
Active Directory is functioning properly. The event data contains the error.
Data: 0000: 0b 00 00 00 ....
The final status code from event 4015, 0x00000b, maps to error "LDAP_ADMIN_LIMIT_EXCEEDED Administration
limit on the server has exceeded."
Event Type: Warning

Event Source: NTDS Replication
Event Category: Replication
Event ID: 1093
Description: The directory replication agent (DRA) could not apply changes to object
DC=@,DC=xyz.example.com,CN=MicrosoftDNS,CN=System,DC=xyz,DC=example, DC=com (GUID <GUID>) because the
incoming changes cause the object to exceed the database's record size limit. The incoming change to
attribute 9017e (dnsRecord) will be backed out in an attempt to make the update fit. In addition to the
change to the attribute not being applied locally, the current value of the attribute on this system will be
sent out to all other systems to make that the definitive version. This has the effect of nullifying the
change to the rest of the enterprise.
The reversal may be recognized as follows: version 5474, time of change 2000-06-28 19:33.24 and USN of
2873104.
Event Type: Information
Event ID: 1101
Description: The directory replication agent (DRA) was able to successfully apply the changes to object
DC=@,DC=xyz.example.com,CN=MicrosoftDNS,CN=System, DC=xyz,DC=example,DC=com (GUID <GUID>) after backing out
one or more of the attribute changes. Preceding messages will indicate which attributes were reversed.
Please note that this will have the effect of nullifying the change where it was made, causing the original
update not to take effect. The originator should be notified that their change was not accepted by the
system.
Cause
Ce problème se produit car Active Directory est limité à environ 1 200 valeurs qui peuvent être associées à un
seul objet. Dans une zone DNS intégrée à Active Directory, les noms DNS sont représentés par des objets
dnsNode, et les enregistrements DNS sont stockés en tant que valeurs dans l’attribut dnsRecord à valeurs
multiples sur les objets dnsNode, ce qui provoque les messages d’erreur répertoriés plus tôt dans cet article.
Résolution
Vous pouvez utiliser l’une des méthodes suivantes pour résoudre ce problème.
Méthode 1
Si vous souhaitez spécifier une liste de serveurs DNS qui peuvent ajouter des enregistrements NS
correspondant à eux-mêmes à une zone spécifiée, choisissez un serveur DNS, puis exécutez Dnscmd.exe avec le
commutateur /AllowNSRecordsAutoCreation :
Pour définir une liste d’adresses TCP/IP de serveurs DNS autorisés à créer automatiquement des
enregistrements NS pour une zone, utilisez la
dnscmd servername /config zonename /AllowNSRecordsAutoCreation IPList commande. Par exemple :
Dnscmd NS1 /config zonename.com /AllowNSRecordsAutoCreation 10.1.1.1 10.5.4.2
Pour effacer la liste des adresses TCP/IP des serveurs DNS autorisés à créer automatiquement des
enregistrements NS pour une zone et à revenir à l’état par défaut lorsque chaque serveur DNS principal
ajoute automatiquement à une zone un enregistrement NS correspondant à celle-ci, utilisez la
dnscmd servername /config zonename /AllowNSRecordsAutoCreation commande. Par exemple :
Dnscmd NS1 /config zonename.com /AllowNSRecordsAutoCreation
Pour interroger la liste des adresses TCP/IP des serveurs DNS autorisés à créer automatiquement des
enregistrements NS pour une zone, utilisez la
dnscmd servername /zoneinfo zonename /AllowNSRecordsAutoCreation commande. Par exemple :
Dnscmd NS1 /zoneinfo zonename.com /AllowNSRecordsAutoCreation
NOTE
Exécutez cette commande sur un seul serveur DNS. La réplication Active Directory propage les modifications à tous les
serveurs DNS qui s’exécutent sur des DCS dans le même domaine.
Dans un environnement dans lequel la majorité des DCS DNS d’un domaine sont situés dans des succursales et
quelques-uns se trouvent dans un emplacement central, vous pouvez utiliser la commande décrite plus tôt dans
cet article pour définir IPList de manière à inclure uniquement les Dnscmd DCS DNS centralisés. Ainsi, seuls les
DCS DNS centralisés ajoutent leurs enregistrements NS respectifs à la zone de domaine Active Directory.
Méthode 2
IMPORTANT
Windows .
Si vous souhaitez choisir le serveur DNS qui n’ajoute pas d’enregistrements NS correspondant à eux-mêmes à
une zone DNS intégrée à Active Directory, utilisez l’Éditeur du Registre (Regedt32.exe) pour configurer la valeur
de Registre suivante sur chaque serveur DNS concerné :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
Valeur de Registre : DisableNSRecordsAutoCreation

Type de données : REG_DWORD
Plage de données : 0x0 | 0x1
Valeur par défaut : 0x0
Cette valeur affecte toutes les zones DNS intégrées à Active Directory. Les valeurs ont les significations suivantes
:
VA L EUR SIGN IF IC AT IO N
0 Le serveur DNS crée automatiquement des enregistrements

NS pour toutes les zones DNS intégrées à Active Directory,
sauf si une zone, hébergée par le serveur, contient l’attribut
AllowNSRecordsAutoCreation (décrit plus tôt dans cet article)
qui n’inclut pas le serveur. Dans ce cas, le serveur utilise la
configuration AllowNSRecordsAutoCreation.
1 Le serveur DNS ne crée pas automatiquement

d’enregistrements NS pour toutes les zones DNS intégrées à
Active Directory, quelle que soit la configuration
AllowNSRecordsAutoCreation dans les zones DNS intégrées
à Active Directory.
NOTE
Pour appliquer les modifications à cette valeur, vous devez redémarrer le service DNS Server.
Si vous souhaitez empêcher certains serveurs DNS d’ajouter leurs enregistrements NS correspondants aux
zones DNS intégrées à Active Directory qu’ils hébergent, vous pouvez utiliser la valeur de Registre
DisableNSRecordsAutoCreation décrite plus tôt dans cet article.
NOTE
Si la valeur de Registre DisableNSRecordsAutoCreation est définie sur 0x1, aucune des zones DNS intégrées à Active
Directory hébergées par ce serveur DNS ne contiendra ses enregistrements NS. Par conséquent, si ce serveur doit ajouter
son propre enregistrement NS à au moins une zone DNS intégrée à Active Directory qu’il héberge, ne définissez pas la
valeur de Registre sur 0x1.
Netlogon Fix
IMPORTANT
Windows .
La partie Netlogon de ce correctif donne aux administrateurs un meilleur contrôle, comme décrit plus tôt dans
cet article. Vous devez appliquer le correctif à chaque dc. En outre, pour empêcher un dc de tenter des mises à
jour dynamiques de certains enregistrements DNS qui, par défaut, sont mis à jour dynamiquement par
Netlogon, utilisez Regedt32.exe pour configurer la valeur de Registre suivante :
Valeur de Registre : DnsAvoidRegisterRecords

Type de données : REG_MULTI_SZ
Dans cette valeur, spécifiez la liste des mnémoniques correspondant aux enregistrements DNS qui ne doivent
pas être enregistrés par ce dc.
NOTE
Définissez la valeur sur la liste des mnémoniques délimitées par des entrées spécifiées dans le tableau suivant.
La liste de mnémoniques inclut :
M N ÉM O N IQ UE TYPE EN REGIST REM EN T DN S
LdapIpAddress A <DnsDomainName>
Ldap SRV _ldap._tcp.<DnsDomainName>
LdapAtSite SRV _ldap._tcp. <SiteName> _sites.

<DnsDomainName>
Pdc SRV _ldap._tcp.pdc._msdcs.

<DnsDomainName>
Gc SRV _ldap._tcp.gc._msdcs.
<DnsForestName>
GcAtSite SRV _ldap._tcp. <SiteName>

_sites.gc._msdcs.<DnsForestName>
DcByGuid SRV _ldap._tcp. <DomainGuid>

domains._msdcs.<DnsForestName>
GcIpAddress A gc._msdcs.<DnsForestName>
DsaCname CNAME <DsaGuid>._msdcs.

<DnsForestName>
Kdc SRV _kerberos._tcp.dc._msdcs.

<DnsDomainName>
KdcAtSite SRV _kerberos._tcp. <SiteName>

_sites.dc._msdcs.<DnsDomainName>
Dc SRV _ldap._tcp.dc._msdcs.
<DnsDomainName>
DcAtSite SRV _ldap._tcp. <SiteName>

_sites.dc._msdcs.<DnsDomainName>
Rfc1510Kdc SRV _kerberos._tcp.<DnsDomainName>
Rfc1510KdcAtSite SRV _kerberos._tcp. <SiteName> _sites.

<DnsDomainName>
GenericGc SRV _gc._tcp.<DnsForestName>
GenericGcAtSite SRV _gc._tcp. <SiteName> _sites.

<DnsForestName>
Rfc1510UdpKdc SRV _kerberos._udp.<DnsDomainName>
Rfc1510Kpwd SRV _kpasswd._tcp.<DnsDomainName>
Rfc1510UdpKpwd SRV _kpasswd._udp.<DnsDomainName>
NOTE
Il n’est pas nécessaire de redémarrer le service Netlogon. Si la valeur de Registre DnsAvoidRegisterRecords est créée ou
modifiée pendant que le service Netlogon est arrêté ou dans les 15 premières minutes après le démarrage de Netlogon,
les mises à jour DNS appropriées ont lieu avec un court délai (toutefois, le délai est au plus tard 15 minutes après le
démarrage de Netlogon).
Les enregistrements DNS des enregistrements A effectués par Netlogon peuvent également être modifiés à
l’aide de la valeur de Registre RegisterDnsARecords. Pour plus d’informations, voir Comment activer ou
désactiver les mises à jour DNS dans Windows.
N’ignorez pas que les valeurs de Registre DnsAvoidRegisterRecords et RegisterDnsARecords doivent autoriser
l’inscription de l’enregistrement hôte (A) :
RegisterDnsARecords = 0x1
Si vous listez LdapIpAddress et GcIpAddress dans les paramètres de valeur de Registre
DnsAvoidRegisterRecords, les enregistrements A ne sont pas enregistrés.
RegisterDnsARecords = 0x0
Que vous listiez LdapIpAddress et GcIpAddress dans les paramètres de valeur de Registre
DnsAvoidRegisterRecords, les enregistrements A ne sont pas enregistrés.
Pour éviter que le problème décrit précédemment dans cet article ne se produise dans un environnement dans
lequel un ensemble de DCs et/ou de serveurs de catalogue global (GC) se trouve dans un emplacement central
et qu’un grand nombre de DCs et/ou de serveurs GC se trouvent dans des succursales, l’administrateur peut
désactiver l’inscription de certains enregistrements DNS par Netlogon sur les DCS/GCs des succursales. Dans ce
cas, la liste des mnémoniques qui ne doivent pas être enregistrés inclut :
Enregistrements spécifiques à dc :
DcByGuid SRV _ldap._tcp. <DomainGuid>


<DnsDomainName>
<DnsDomainName>
Enregistrements propres à gc :
<DnsForestName>
NOTE
Ces listes n’incluent pas les enregistrements spécifiques au site. Par conséquent, les DCS et les serveurs GC des
succursales sont situés par des enregistrements spécifiques au site qui sont généralement utilisés par un localisateur de
dc. Si un programme recherche un DC/GC à l’aide d’enregistrements génériques (non spécifiques au site), tels que les
enregistrements des listes répertoriées plus tôt dans cet article, il trouve un DC/GC dans l’emplacement central.
Un administrateur peut également choisir de limiter le nombre d’enregistrements de localisation de dc tels que
les enregistrements SRV et A enregistrés par Netlogon pour le même nom DNS générique
(_ldap._tcp.dc._msdcs. ), même dans un scénario avec moins de 1 200 DCs dans le même domaine, afin de
réduire la taille des réponses DNS aux requêtes pour ces <DomainName> enregistrements.
Statut
S’applique à ».
Chaque serveur DNS faisant autorité pour une zone DNS intégrée à Active Directory ajoute un enregistrement
NS. Par défaut, chaque dc d’un domaine inscrit un enregistrement SRV pour un ensemble de noms non
spécifiques au site tels que « _ldap._tcp <domain_name> ». et un(s) enregistrement(s) map(s) active(s) le nom
de domaine DNS Active Directory sur le ou les adresses IP/TCP du dc. Lorsqu’un serveur DNS tente d’écrire un
enregistrement après environ 1 200 enregistrements avec le même nom partagé, l’autorité de sécurité locale
(LSA) s’exécute à 100 % d’utilisation du processeur pendant environ 10 secondes et l’inscription ne réussit pas.
Netlogon retente cette inscription toutes les heures ; Le pic d’utilisation du processeur à 100 % réapparaît au
moins une fois par heure et les tentatives d’inscription n’aboutissent pas.
Résoudre une erreur
OBJ_CLASS_VIOLATION’erreur dans Adamsync
Cet article explique comment résoudre une erreur OBJ_CLASS_VIOLATION qui se produit lorsque vous utilisez
l’outil Adamsync dans Windows Server.
Résumé
Cette erreur se produit en raison des différences de définition de classe entre le service d’annuaire Active
Directory et l’instance ADAM. Pour résoudre ce problème, suivez les étapes décrites dans les sections suivantes :
Déterminer l’attribut et la classe de l’objet
Étapes pour résoudre le problème lorsque les attributs appartiennent à la classe TOP
Étapes pour résoudre le problème lorsque les attributs n’appartiennent pas à la classe TOP
Symptômes
Vous essayez d’utiliser l’outil de synchronisation ADAM (Active Directory Application Moder) (Adamsync.exe)
pour synchroniser les objets Active Directory avec une instance ADAM sur un serveur Windows. Toutefois, un
message d’erreur semblable à ce qui suit est consigné dans le fichier journal Adamsync :
Entrée de traitement : Page X, Cadre X, Entrée X, Nombre X, Entrée source de traitement USN X
<guid=f9023a23e3a06d408f07a0d51c301f38> entrée de traitement dans l’étendue
f9023a23e3a06d408f07a0d51c301f38. Ajout d’un objet cible
CN= TestGroup ,OU= Accounts ,dc= domain , dc= com . Ajout d’attributs : sourceobjectguid, objectClass,
instanceType, displayName, info, adminDescription, displayNamePrintable, userAccountControl, codePage,
countryCode, logonHours, primaryGroupID, comment, accountExpires, sAMAccountName, desktopProfile,
legacyExchangeDN, userPrincipalName
Une erreur Ldap s’est produite. ldap_add_sW : Violation de classe d’objet. Informations étendues : 0000207D
: UpdErr : DSID-0315119D, problème 6002 (OBJ_CLASS_VIOLATION), données -2054643804
Cause
Ce problème se produit en raison des différences de définition de classe entre Active Directory et ADAM. Cette
différence apparaît lorsque vous essayez de modifier un objet pour inclure un attribut non valide pour sa classe.
Par exemple, l’attribut n’est pas défini du tout dans le schéma ADAM ou l’attribut est défini, mais l’attribut n’est
pas présent dans la liste des attributs obligatoires ou facultatifs pour la classe spécifique. En règle générale, la
deuxième situation est la cause la plus fréquente de ce problème.
La définition de classe de l’objet à synchroniser contient un ou plusieurs attributs dans Active Directory qui ne
sont pas disponibles dans ADAM. La section « Ajout d’attributs » du message d’erreur mentionné dans la section
« Symptômes » affiche les attributs que vous essayez d’ajouter. Ces attributs sont définis dans la liste des
attributs facultatifs ou obligatoires de la classe de l’objet en cours de synchronisation.
Par exemple, dans le message d’erreur mentionné dans la section « Symptômes », l’objet de référence est
CN=TestGroup. Lorsque vous affichez l’objet CN=TestGroup dans Active Directory et que vous vérifiez la liste
des attributs de cette classe et de toutes les classes parentes, vous voyez qu’un ou plusieurs attributs de cette
liste ne sont pas dans la liste des attributs obligatoires ou facultatifs qui sont activés pour cette classe dans
ADAM.
NOTE
Cela inclut les listes d’attributs de toutes les classes parentes.
Résolution
Déterminer les attributs et la classe de l’objet
1. Vérifiez la liste des attributs ajoutés à l’objet qui a échoué. Vous pouvez déterminer l’objet qui a échoué en
visualisé le message d’erreur dans le journal de synchronisation. L’objet en échec est toujours le dernier objet
indiqué à la fin du journal de synchronisation juste avant le message d’erreur. Par exemple, l’objet
CN=TestGroup a échoué dans le message d’erreur mentionné dans la section « Symptômes ».
2. Déterminez si les attributs DisplayNamePrintable, Flags ou ExtensionName sont inclus dans le message
d’erreur. Si l’un de ces attributs est inclus dans le message d’erreur, consultez la section « Étapes pour
résoudre le problème lorsque les attributs appartiennent à la classe TOP ». Si aucun attribut n’est inclus dans
le message d’erreur, consultez la section « Étapes de résolution du problème lorsque les attributs
n’appartiennent pas à la classe TOP ».
Étapes pour résoudre le problème lorsque les attributs appartiennent à la classe TOP
Vous découvrirez que la classe TOP dans le schéma Active Directory contient l’attribut DisplayNamePrintable,
Flags ou ExtensionName. Toutefois, ces attributs ne sont pas contenus dans la classe TOP dans ADAM. Toutefois,
vous ne pouvez pas modifier la classe TOP dans ADAM. Par conséquent, utilisez l’une des méthodes suivantes
pour résoudre le problème :
Excluez ces attributs à <exclude> l’aide de la section du fichier de configuration XML.
À l’aide du schéma MMC, ajoutez manuellement ces attributs à la liste des attributs facultatifs pour la classe
pertinente dans le schéma ADAM. Par exemple, dans le message d’erreur mentionné dans la section «
Symptômes », l’objet défaillant est de la classe Group. Par conséquent, vous devez ajouter ces attributs à la
liste des attributs facultatifs pour la classe Group dans ADAM.
Étapes pour résoudre le problème lorsque les attributs n’appartiennent pas à la classe TOP
1. Dans ADSchemaAnalyzer, sous le menu Options des outils, cliquez sur Mettre à jour avec des références à
des éléments nouveaux et présents sous l’onglet de \ génération LDIF.
2. Utilisez le menu Fichier pour charger Active Directory comme schéma cible et ADAM comme schéma de
base. Attendez que l’outil termine de comparer les schémas.
3. Dans le menu Schéma, cliquez sur Marquer tous les éléments comme inclus.
4. Dans le menu Fichier, cliquez sur Créer un fichier LDIF pour créer un fichier LDF qui contient les
modifications.
NOTE
Si vous importez ce fichier LDF directement dans ADAM, les attributs nécessaires ne seront probablement pas
ajoutés ou modifiés correctement.
5. Aucun message d’erreur n’est affiché. Consultez la section « Pourquoi vous ne pouvez pas importer le
fichier LDF directement dans ADAM » pour savoir pourquoi cela se produit. Dans ce cas, allez à l’étape 5
sans importer le fichier LDF.
6. Examinez le fichier LDF que vous avez créé à l’étape 4. Plus précisément, affichez la classe à l’origine du
problème. Par exemple, affichez la classe Group. La section de cette classe contient la liste des attributs
présents dans la liste des attributs obligatoires ou facultatifs pour cette classe dans Active Directory, mais
qui sont manquants dans ADAM.
7. Recherchez l’attribut problème dans le fichier LDF. Pour ce faire, examinez la section « #attributes » dans
le fichier LDF. Les attributs qui ne sont pas importés restent dans cette section. En règle générale, l’attribut
problème est le seul attribut que vous trouvez dans la section « #attributes ». Si vous trouvez l’attribut
problème, allez à l’étape 8. Si vous ne trouvez pas l’attribut problème, allez à l’étape 7.
8. Si l’attribut problème n’est pas évident à partir de la section « #attributes » dans le fichier LDF, suivez les
étapes suivantes pour rechercher l’attribut problème :
a. Actuellement, toutes les modifications apportées à une classe se trouve sous une section dans le
fichier LDF. Il s’agit de la section #Updating éléments présents. Sous cette section, recherchez la
section qui met à jour la classe qui présente le problème. Par exemple, si la classe Group est le
problème, vous trouverez une section qui ressemble à ce qui suit :
# Élément Update : group

dn: cn=Group,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: mayContain
# mayContain: adminCount
mayContain: 1.2.840.113556.1.4.150
# mayContain: controlAccessRights
mayContain: 1.2.840.113556.1.4.200
# mayContain: groupAttributes
mayContain: 1.2.840.113556.1.4.152
# mayContain: groupMembershipSAM
mayContain: 1.2.840.113556.1.4.166
-
Notez que d’autres entrées qui peuvent se trouver ici ont été exclues de cet exemple.
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
b. Modifiez les entrées que vous avez localisées à l’étape 4a en fractionnant les entrées en un seul
attribut par opération. Par exemple, modifiez les entrées de l’exemple à l’étape 7a à l’aide d’entrées
qui ressemblent à ce qui suit :

changetype: modify
add: mayContain
# mayContain: adminCount
mayContain: 1.2.840.113556.1.4.150
-
changetype: modify
add: mayContain
# mayContain: controlAccessRights
mayContain: 1.2.840.113556.1.4.200
-
changetype: modify
add: mayContain
# mayContain: groupAttributes
mayContain: 1.2.840.113556.1.4.152
-
changetype: modify
add: mayContain
# mayContain: groupMembershipSAM
mayContain: 1.2.840.113556.1.4.166
-
Notez que d’autres entrées qui peuvent se trouver ici ont été exclues de cet exemple.
dn:
changetype: modify
schemaUpdateNow: 1
9. Enregistrez le fichier LDF.

10. Importez le fichier LDF dans le schéma ADAM à l’aide de la commande fournie au début du fichier LDF.
11. Affichez le rapport affiché par l’utilitaire Ldifde. Ldifde signale maintenant les erreurs qui se produisent
avec les attributs qui n’ont pas été importés. Les informations d’erreur ressembleront aux exemples
d’informations suivants :
ldifde -i -u -f c:\data\problem\KBtest_modified.ldf -s localhost:50010 -j .-c "cn=Configuration,dc=X"

#configurationNamingContext
Connecting to "localhost:50010"
Connexion en tant qu’utilisateur actuel à l’aide du SSPI

Importation du répertoire à partir du fichier « c:\data\problem\KBtest_modified.ldf »
Chargement des entrées.
Ajouter une erreur sur la ligne 15 : Existe déjà
L’erreur côté serveur est la 0x2071 une tentative d’ajout d’un objet à l’objet
ectory avec un nom déjà utilisé.
L’erreur du serveur étendu est la :
00002071 : UpdErr : DSID-0305030D, problème 6005 (ENTRY_EXISTS), données 0
NOTE
Recherchez l’attribut problème dans le fichier LDF en visualisant le numéro de ligne indiqué dans le rapport
d’erreurs.
12. Utilisez ces informations d’erreur pour rechercher l’attribut problème et résoudre le problème. Pour
résoudre le problème, suivez les étapes suivantes :
a. Recherchez l’attribut problème dans le fichier LDF en visualisant le numéro de ligne indiqué dans le
rapport d’erreurs. L’attribut en échec peut avoir un préfixe « DUP- » dans displayName.
b. Notez l’identificateur d’objet (OID) de l’attribut et recherchez cet identificateur d’objet dans ADAM.
c. Recherchez dans ADAM l’attribut qui a le même identificateur d’objet.
d. Comparez l’attribut dans ADAM et dans le fichier LDF pour rechercher les différences. Par exemple, les
attributs peuvent avoir un nom d’affichage différent mais le même identificateur d’objet.
e. Déterminez l’attribut à conserver, puis corrigez l’autre attribut. Par exemple, vous pouvez supprimer
l’entrée du fichier LDF ou corriger l’entrée d’attribut ADAM. Vous pouvez également exclure l’attribut
problème de la synchronisation à l’aide de la <exclude> section du fichier de configuration XML.
13. Une fois que l’attribut problème a été corrigé dans Active Directory ou dans le schéma ADAM ou après
que l’attribut a été supprimé du fichier LDF, importez de nouveau le fichier LDF modifié. L’opération
d’importation doit maintenant réussir. Si le problème n’est pas résolu, il se peut qu’un autre attribut soit à
l’origine du problème. Répétez les étapes 10 à 12 jusqu’à ce que tous les attributs soient importés.
Journalisation des diagnostics
Lorsque vous trouvez l’attribut problème, il n’est peut-être pas évident de savoir ce qui ne va pas avec. Par
exemple, il se peut que vous ne trouviez pas d’identificateur d’objet en double ou un
entrée DisplayName différente. Lorsqu’un attribut problème n’est pas importé, vous pouvez obtenir plus
d’informations sur l’échec en retournant la journalisation du débogage pour l’interface LDAP. Pour cela,
1. Pour obtenir plus d’informations sur l’échec de ldifde, activer la journalisation LDAP dans ADAM. Pour ce
faire, modifiez la valeur de l’entrée de Registre des événements de l’interface LDAP catégorie 16 sur
5. Cette entrée de Registre se trouve sous la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ADAM_instanceName\Diagnostics
2. Importez à nouveau le fichier LDF.

3. Recherchez des erreurs dans le journal des événements.
4. Une fois le dépannage terminé, redéfinissez la valeur de l’entrée de Registre des événements de
l’interface LDAP catégorie 16 sur 0. Dans le cas contraire, le journal des événements sera inondable.
Contacter le support Microsoft
Si le problème n’est pas résolu une fois que vous avez terminé les étapes de cet article, contactez le Support
Microsoft.
Statut
Pour synchroniser les données d’Active Directory avec ADAM à l’aide de l’outil Adamsync, suivez les étapes
suivantes :
1. Cliquez sur Démarrer, pointez sur Tous les programmes, pointez sur ADAM, puis cliquez sur Invite de
commandes des outils ADAM.
2. À l’invite de commandes, tapez la commande suivante, puis appuyez sur Entrée : adamsync /fs
Ser ver_Name : por t_number configurationName /log log_file_name .log
Pourquoi vous ne pouvez pas importer le fichier LDF directement dans ADAM
Si vous importez le fichier LDF que vous avez créé à l’étape 1 sous la section « Étapes de résolution du problème
lorsque les attributs n’appartiennent pas à la classe TOP » dans ADAM, ces attributs ne sont toujours pas ajoutés
à la liste des attributs dans ADAM. Vous pouvez vérifier ce comportement à l’aide du schéma ADAM MMC ou
ADSIEDIT pour examiner le schéma. Ce comportement se produit car l’opération d’importation Ldifde échoue en
mode silencieux. Actuellement, Ldifde ne signale pas d’erreurs. Il échoue en mode silencieux en raison de la
façon dont ADSchemaAnalyzer construit le fichier LDF. ADSchemaAnalyzer utilise les commandes
ntdsschemaadd et ntdsSchemamodify. Ces commandes activer le contrôle LDAP permissif. Cela signifie que
tout échec est silencieux.
En outre, pour chaque classe, tous les attributs à ajouter à la liste des attributs facultatifs sont ajoutés dans une
opération d’ajout/modification. Par conséquent, en cas de problème d’ajout d’un des attributs, toute l’opération
échoue et aucun attribut de la liste n’est ajouté. Par conséquent, des étapes supplémentaires doivent être prises
pour rechercher l’attribut problème.
En règle générale, la raison probable de l’échec est un identificateur d’objet en double d’un attribut ou une autre
différence dans les définitions d’attribut dans Active Directory et ADAM. Cela signifie que les OID en double
peuvent être manqués et qu’un attribut peut être considéré comme un nouvel attribut si LDapDisplayName
n’existe pas dans ADAM.
L’instance AD LDS enregistre l’ID d’événement 2092
dans Windows Server
Cet article fournit une solution à un problème qui se produit lorsque vous redémarrez un serveur AD LDS qui
contient des rôles FSMO ou redémarrez une instance AD LDS sur ce serveur.
Symptômes
Lorsque vous redémarrez un serveur AD LDS (Active Directory Light-weight Domain Services) qui contient des
rôles FSMO (Flexible Single Master Operations) ou redémarrez une instance AD LDS sur ce serveur, vous
obtenez un message d’avertissement (ID d’événement 2092) dans l’Observateur d’événements ADAM pour
cette instance particulière. L’ID d’événement 2092 affiche :
Nom du journal : ADAM (InstanceName)

Source : Réplication ADAM [InstanceName]
Date :
Catégorie de tâche : réplication
Niveau : Avertissement
Ordinateur : ADAMComputerName
Description :
Ce serveur est le propriétaire du rôle FSMO suivant, mais ne le considère pas comme valide. Pour la
partition qui contient le FSMO, ce serveur n’a été répliqué avec aucun de ses partenaires depuis le
redémarrage de ce serveur. Les erreurs de réplication empêchent la validation de ce rôle.
Les opérations qui nécessitent de contacter un maître d’opération FSMO échouent jusqu’à ce que cette
condition soit corrigée.
Rôle FSMO : CN=Schema,CN=Configuration,CN={95B93FA0-93B9-4E54-A654-0D55F5CF9E4B}
Action de l’utilisateur :
1. La synchronisation initiale est la première réplication précoce effectuée par un système au démarrage.
Un échec de la synchronisation initiale peut expliquer pourquoi un rôle FSMO ne peut pas être validé. Ce
processus est expliqué dans l’article de la 305476.
2. Ce serveur dispose d’un ou de plusieurs partenaires de réplication et la réplication échoue pour tous ces
partenaires. Utilisez la commande repadmin /showrepl pour afficher les erreurs de réplication. Corrigez
l’erreur en question. Par exemple, il peut y avoir des problèmes de connectivité IP, de résolution de noms
DNS ou d’authentification de sécurité qui empêchent la réplication réussie.
3. Dans le cas rare où tous les partenaires de réplication sont en panne est une occurrence attendue, peut-
être en raison de la maintenance ou d’une récupération d’urgence, vous pouvez forcer la validation du
rôle. Pour ce faire, vous pouvez utiliser NTDSUTIL.EXE pour saisir le rôle sur le même serveur. Cette étape
peut être effectuée à l’aide des étapes fournies dans les articles de la Base de 255504 et 324801 sur
https://support.microsoft.com .
Les opérations suivantes peuvent être impactées :
Schéma : vous ne pourrez plus modifier le schéma de cette forêt.
Noms de domaine : vous ne pourrez plus ajouter ou supprimer des domaines de cette forêt.
PDC : vous ne pourrez plus effectuer d’opérations de contrôleur de domaine principales, telles que des mises
à jour de stratégie de groupe et des réinitialisations de mot de passe pour les comptes des services
Lightweight Directory non Active Directory.
RID : vous ne serez pas en mesure d’allocation de nouveaux identificateurs de sécurité pour les nouveaux
comptes d’utilisateur, comptes d’ordinateur ou groupes de sécurité.
Infrastructure : les références de noms entre domaines, telles que les appartenances à des groupes
universels, ne seront pas mises à jour correctement si leur objet cible est déplacé ou renommé.
Nom du journal : ADAM (InstanceName)

Source : Réplication ADAM [InstanceName]
Date :
Ordinateur : ADAMComputerName
Description :
Ce serveur est le propriétaire du rôle FSMO suivant, mais ne le considère pas comme valide. Pour la
partition qui contient le FSMO, ce serveur n’a été répliqué avec aucun de ses partenaires depuis le
redémarrage de ce serveur. Les erreurs de réplication empêchent la validation de ce rôle.
Les opérations qui nécessitent de contacter un maître d’opération FSMO échouent jusqu’à ce que cette
condition soit corrigée.
Rôle FSMO : CN=Partitions,CN=Configuration,CN={95B93FA0-93B9-4E54-A654-0D55F5CF9E4B}
1. La synchronisation initiale est la première réplication précoce effectuée par un système au démarrage.
Un échec de la synchronisation initiale peut expliquer pourquoi un rôle FSMO ne peut pas être validé. Ce
processus est expliqué dans l’article de la 305476.
2. Ce serveur dispose d’un ou de plusieurs partenaires de réplication et la réplication échoue pour tous ces
partenaires. Utilisez la commande repadmin /showrepl pour afficher les erreurs de réplication. Corrigez
l’erreur en question. Par exemple, il peut y avoir des problèmes de connectivité IP, de résolution de noms
DNS ou d’authentification de sécurité qui empêchent la réplication réussie.
3. Dans le cas rare où tous les partenaires de réplication sont en panne est une occurrence attendue, peut-
être en raison de la maintenance ou d’une récupération d’urgence, vous pouvez forcer la validation du
rôle. Pour ce faire, vous pouvez utiliser NTDSUTIL.EXE pour saisir le rôle sur le même serveur. Cette étape
peut être effectuée à l’aide des étapes fournies dans les articles de la Base de 255504 et 324801 sur
https://support.microsoft.com .
Les opérations suivantes peuvent être impactées :

Schéma : vous ne pourrez plus modifier le schéma de cette forêt.
Noms de domaine : vous ne pourrez plus ajouter ou supprimer des domaines de cette forêt.
PDC : vous ne pourrez plus effectuer d’opérations de contrôleur de domaine principales, telles que des mises
à jour de stratégie de groupe et des réinitialisations de mot de passe pour les comptes des services
Lightweight Directory non Active Directory.
RID : vous ne serez pas en mesure d’allocation de nouveaux identificateurs de sécurité pour les nouveaux
comptes d’utilisateur, comptes d’ordinateur ou groupes de sécurité.
Infrastructure : les références de noms entre domaines, telles que les appartenances à des groupes
universels, ne seront pas mises à jour correctement si leur objet cible est déplacé ou renommé.
Cause
Lorsqu’il y a au moins deux instances AD LDS dans un jeu de réplicas, les instances AD LDS propriétaire de
FSMO sont requises pour répliquer une partition particulière sur le démarrage du service afin de répondre aux
exigences de synchronisation initiale. L’événement 2092 est consigné peu de temps après le démarrage du
service pour indiquer cette condition. Le nom de domaine FSMO est requis pour répliquer la partition
configuration et le FSMO de schéma est requis pour répliquer la partition de schéma. Une fois que la partition
respective a été répliquée avec succès, les mises à jour sont de nouveau autorisées. Aucun événement n’est
consigné pour indiquer que la synchronisation initiale s’est correctement terminée.
Résolution
Si la réplication AD LDS fonctionne entre les instances, vous pouvez ignorer cet événement. Il s’agit d’un
comportement de conception que l’instance du titulaire du rôle FSMO recherche un partenaire réplica pour
mettre à jour les informations, lors du redémarrage du service/serveur AD LDS.
Pour vérifier la réplication entre les instances AD LDS, vous pouvez utiliser dcdiag.exe ou repadmin.exe. Pour
plus d’informations, consultez les articles suivants :
Repadmin
Dcdiag
L’installation d’ADMT 3.1 PES échoue avec une
erreur : le mot de passe fourni ne correspond pas
au mot de passe de cette clé de chiffrement
Cet article permet de résoudre un problème dans lequel une erreur « Le mot de passe fourni ne correspond pas
au mot de passe de cette clé de chiffrement » se produit lorsque vous configurez le service PES (Password
Export Server) sur l’Outil de migration Active Directory version 3.1.
Symptômes
La configuration du service d’exportation de mot de passe (PES) sur l’Outil de migration Active Directory version
3.1 sur le titulaire du rôle PDC Emulator ADMT KEY du domaine source à l’aide de la commande ci-dessous
échoue avec l’erreur à l’écran suivante :
Syntaxe de ligne de commande :
CLÉ ADMT /OPTION:CREATE /SOURCEDOMAIN:<ADMT source domain> /KEYFILE:x:\<path>\<filename>.pes
/PWD:*
Erreur à l’écran :
Texte du titre de la boîte de dialogue : Mot de passe non valide !

Texte du message de boîte de dialogue :
Le mot de passe fourni ne correspond pas au mot de passe de cette clé de chiffrement. La DLL de filtre de
migration de mot de passe de l’outil ADMT ne s’installe pas sans clé de chiffrement valide.
Cause
Le mot de passe fourni était correct, mais Windows Installer (msiexec.exe) n’a pas réussi à ouvrir un handle vers
l’objet de stratégie sur le contrôleur de domaine pour enregistrer le mot de passe qui sera utilisé par le service
PES. L’échec indique que le compte d’utilisateur ne avait pas l’autorisation requise.
L’utilisateur qui installe le service PES doit être membre du groupe Administrateurs intégré du domaine.
En outre, si le compte d’utilisateur n’est pas membre du compte Administrateurs intégré et que le contrôle de
compte d’utilisateur (UAC) est activé sur le contrôleur de domaine, l’utilisateur s’exécute avec le moins de
privilèges d’utilisateur après l’enregistrement. Pour accéder à l’objet de stratégie sur le contrôleur de domaine
pour l’installation du service PES, l’utilisateur doit lancer le fichier d’installation Pwdmig.msi avec des privilèges
complets.
Résolution
Assurez-vous que le compte d’utilisateur qui installe le service PES est membre du groupe Administrateurs
intégré du domaine en exécutant la commande whoami /groups , puis exécutez le fichier d’installation
Pwdmig.msi dans une fenêtre d’invite de commandes avec élévation de niveau élevé, lancée avec l’option
Exécuter en tant qu’administrateur.
Si vous voyez que la sortie de la commande whoami /groups ressemble à ce qui suit, cela signifie que
l’utilisateur s’est connecté avec le moins de privilèges d’utilisateur. Bien qu’ils sont membres du groupe
Administrateurs intégré, ils n’ont pas l’autorisation d’effectuer des tâches administratives avec ce jeton.
Whoami /groups output:
N O M DU GRO UP E TYPE SID AT T RIB UT S
========== ========== ========== ==========
Tout le monde Groupe connu S-1-1-0 Groupe obligatoire, Activé

par défaut, Groupe activé
BUILTIN\Administrators Alias S-1-5-32-544 Groupe utilisé pour refuser

uniquement
BUILTIN\Users Alias S-1-5-32-545 Groupe obligatoire, Activé

par défaut, Groupe activé
....
Installation d’ADMT 3.2 incomplète, erreur de la
console MMC « impossible d’ouvrir la base de
données « ADMT » demandée par la connexion »
Cet article fournit de l’aide sur une erreur (Impossible d’ouvrir la base de données « ADMT » demandée par la
connexion. L’échec de l’logo) se produit lorsque vous exécutez la console de l’outil de migration Active Directory
(ADMT).
Symptômes
Lorsque vous installez ADMT 3.2 sur un contrôleur de domaine Windows Server 2008 R2 et que vous utilisez
SQL Express 2008 avec SP1 et la mise à jour cumulative 4 de SQL 2008, l’installation se termine sans erreurs.
Toutefois, la boîte de dialogue « Assistant Installation de l’outil de migration Active Directory » est vide lorsque
l’installation est terminée.
Lorsque vous tentez ensuite d’exécuter la console ADMT, vous recevez une erreur :
Outil de migration Active Directory

Impossible de vérifier les actions qui ont échoué.:D BManager.IManageDB.1 : Impossible d’ouvrir la base de
données « ADMT » demandée par la connexion. Échec de la logon.
La console MMC affiche ensuite :
MMC n’a pas pu créer le logiciel en snap-in.

MMC n’a pas pu créer le logiciel en snap-in. Le logiciel en snap-in n’a peut-être pas été installé correctement.
Nom : Outil de migration Active Directory
CLSID : {E1975D70-3F8E-11D3-99EE-00C04F39BD92}
Cause
Il existe un défaut de code dans la façon dont ADMT interopérer avec SQL Express 2008 SP1 sur les contrôleurs
de domaine, ce qui entraîne la création du groupe « SQLServerMSSQLUser$ComputerName$InstanceName ».
Ce groupe est requis par ADMT pour configurer des autorisations spécifiques pendant l’installation de l’ADMT et
permet de créer la base de données ADMT dans l’instance SQL instance. ADMT s’attend à ce que le groupe soit
présent, ce qui conduit à la boîte de dialogue vide et à une installation incomplète.
Solution de contournement 1
La pratique standard consiste à installer ADMT sur un ordinateur membre dans le domaine cible. Installez SQL
Express 2008 SP1 sur un serveur membre Windows 2008 R2 dans le domaine cible, puis installez ADMT 3.2 sur
ce même serveur membre.
Si vous devez installer ADMT 3.2 sur un contrôleur de domaine afin d’utiliser des migrations d’utilisateurs par
script ou en ligne de commande avec l’historique SID, installez SQL 2008 SP1 (édition non Express) sur un
serveur membre Windows Server 2008 R2 dans le domaine cible et sélectionnez cette instance distante lors de
l’installation d’ADMT 3.2 sur le contrôleur de domaine. Vous pouvez également installer SQL Express 2005 SP3
sur le contrôleur de domaine.
Si vous devez installer ADMT 3.2 et SQL Express 2008 SP1 sur le même contrôleur de domaine, utilisez les
étapes suivantes sur le contrôleur de domaine cible :
1. Installez le package de mise à jour cumulative 4 pour SQL Server 2008 sur le contrôleur de domaine.
2. Installez SQL Express 2008 SP1 sur le contrôleur de domaine. Notez le SQL’instance créée pendant
l’installation (SQLEXPRESS est la valeur par défaut).
3. Créez un groupe local de domaine au format « SQLServerMSSQLUser$ <DCComputerName> $
<InstanceName> ». Par exemple, si le contrôleur de domaine est nommé « DC1 » et que l’instance SQL
était « SQLEXPRESS », vous devez exécuter la commande suivante dans une invite de commandes avec
élévation de élévation de niveau :
NET LOCALGROUP SQLServerMSSQLUser$DC1$SQLEXPRESS /ADD
4. Récupérez le SID SQL service à l’aide SC.EXE commande avec le nom de l’instance SQL service. Par
exemple, si l’instance SQL est « SQLEXPRESS », exécutez la commande suivante dans une invite de
commandes avec élévation de élévation de valeurs et notez la valeur SID de SERVICE renvoyée :
SC SHOWSID MSSQL$SQLEXPRESS
5. Dans le Windows, créez le sous-répertoire « ADMT » et un sous-sous-répertoire sous ce nom nommé «

Data ». Par exemple, vous devez exécuter la commande suivante dans une invite de commandes avec
élévation de élévation de niveau :
MD %SystemRoot%\ADMT\Data
6. À l’aide du SID récupéré à l’étape 4, définissez les autorisations CONTRÔLE TOTAL sur le dossier
%SystemRoot%\ADMT\Data. Par exemple, si le SID renvoyé à l’étape 4 était « S-1-5-80-3880006512-
4290199581-3569869737-363123133 », vous devez exécuter la commande suivante dans une invite de
commandes avec élévation de niveaux :
ICACLS %systemroot%\ADMT\Data /grant *S-1-5-80-3880006512-4290199581-3569869737-363123133:F
7. Installez ADMT 3.2 sur le contrôleur de domaine tout en sélectionnant l’instance SQL Express 2008 locale.
Problèmes connus qui peuvent se produire lorsque
vous utilisez ADMT 3.1 pour migrer vers un
domaine qui contient des contrôleurs de domaine
Cet article décrit les problèmes connus que vous pouvez connaître lorsque vous utilisez l’outil de migration
Active Directory 3.1 pour migrer des données Active Directory vers un domaine et fournit de l’aide pour
résoudre ces problèmes.
Résumé
Bien que l’outil de migration Active Directory (ADMT) 3.1 ne soit pas destiné à cibler Windows Server 2008 R2,
Microsoft a vérifié que cet outil peut être utilisé pour migrer les données Active Directory vers un domaine
hébergé par un ou plusieurs contrôleurs de domaine Windows Server 2008 R2. Toutefois, il existe des
problèmes connus avec cette approche. Cet article décrit ces problèmes et fournit des solutions de
contournement.
La liste suivante décrit les scénarios pris en charge mis à jour pour l’utilisation d’ADMT 3.1 :
ADMT 3.1 doit être exécuté à partir d’un ordinateur Windows Server 2008. L’ordinateur doit être un serveur
membre ou un contrôleur de domaine.
L’outil ADMT peut être installé sur n’importe quel ordinateur exécutant Windows Server 2008, sauf si les
ordinateurs sont Read-Only contrôleurs de domaine ou dans une configuration Server Core.
Le domaine cible doit être basé sur Windows 2000 Server, Windows Server 2003, Windows Server 2008 ou
Windows Server 2008 R2.
Le domaine source doit être basé sur Windows 2000 Server, Windows Server 2003 ou Windows Server
2008.
L’agent ADMT, qui est installé par ADMT sur les ordinateurs des domaines sources, peut fonctionner sur des
ordinateurs exécutant Windows 2000 Professional, Windows 2000 Server, Windows XP, Windows Server
2003, Windows Vista, Windows Server 2008, Windows 7 ou Windows Server 2008 R2.
NOTE
Si vous n’avez pas Windows Server 2008 car vous avez mis à niveau Windows 2000 ou Windows Server 2003 vers
Windows Server 2008 R2, vous avez des droits de rétrogradation. Pour obtenir des clés de produit et des supports pour
Windows Server 2008 R2, visitez ce site.
Problèmes détectés
Les problèmes connus suivants peuvent se produire lorsque vous utilisez ADMT 3.1 pour migrer des données
vers un environnement Active Directory Windows Server 2008 R2 :
L’Assistant Migration d’ordinateur répertorie les comptes de service gérés en tant qu’objets
sélectionnables. Ces objets ne peuvent pas être migrés à l’aide d’ADMT 3.1. Bien que ces objets soient
sélectionnables, l’Assistant échouera (sans bloquer) les migrations de ces objets et se quittera avec une
erreur.
Le compte de service géré est une nouvelle Windows Server 2008 R2. Pour plus d’informations,
consultez la page Web Microsoft suivante :
Nouveautés des comptes de service
La traduction de sécurité sur les clés de Registre peut échouer (blocage). Lorsque le problème se produit,
l’administrateur peut recevoir un message d’erreur semblable à l’un des suivants :
ERR3:7330 Failed to open registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\009, rc=714 The specified registry key is referenced by a predefined handle.
ERR3:7330 Failed to open registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows
NT\CurrentVersion\Perflib\009, rc=714 The specified registry key is referenced by a predefined handle.
ERR3:7331 Échec de l’HKEY_DYN_DATA de clé de Registre, rc=120 Cette fonction n’est pas prise en charge
sur ce système.
La migration de plusieurs mots de passe utilisateur dans un lot peut échouer pour le premier mot de
passe utilisateur. Lorsque ce problème se produit, l’administrateur peut recevoir un message d’erreur
semblable à ce qui suit :
Impossible d’établir une session avec le serveur expert de mot de passe : le serveur RPC n’est pas
disponible
Pour résoudre ce problème, effectuez à nouveau la migration de mot de passe.
La migration par script des utilisateurs pour remplir l’historique SID échoue lorsqu’elle est effectuée
sur un serveur membre dans le domaine cible. Lorsque vous utilisez l’outil ou le script en ligne de
commande ADMT.EXE pour migrer l’historique des SID, vous devez effectuer la migration sur un
contrôleur de domaine Windows Server 2008 dans le domaine cible.
LAdmtdb.exe ne valide pas la version d’une instance de base de données distante. L’administrateur
doit s’assurer que le serveur de base de données distant exécute Microsoft SQL Server 2000 avec
Service Pack 4, SQL Server 2005 ou une version ultérieure. Pour plus d’informations sur la migration
des comptes d’utilisateurs, consultez la page Web Microsoft suivante : Migration de tous les comptes
d’utilisateurs
Informations de support pour ADMT et PES
Cet article décrit les informations relatives à l’outil de migration Active Directory version 3.2 (ADMT v3.2) et au
serveur d’exportation de mot de passe version 3.1 (PES v3.1).
Résumé
Cet article fournit la documentation et les outils de migration Active Directory gratuits. Les outils sont ADMT
v3.2 et PES v3.1. Cet article décrit également les problèmes connus et les limitations de l’ensemble d’outils.
ADMT Guide
Le guide suivant fournit des conseils pour la migration de domaines à l’aide de l’outil de migration Active
Directory :
Guide de l’outil de migration Active Directory (ADMT) : Migration et restructuration de domaines Active
Directory
NOTE
ADMT n’a pas été mis à jour pour la migration Windows 8.1 et 10 stations de travail.
Windows Server 2012, Windows Server 2012 R2 et versions ultérieures de Windows Server n’ont pas été testées pour
les applications modernes et les migrations de profil. Votre expérience peut varier, en fonction de nombreux facteurs,
notamment la version Windows que vous migrez. Utilisez la suite d’outils à vos propres risques.
Une alternative à la suite d’outils ADMT est également disponible à partir de Microsoft Services:Active Directory
Migration Services (ADMS). Cet outil s’exécute dans le cloud Azure. Pour obtenir des informations d’entrée de gamme,
consultez Taste of Premier: Directory Consolidation with Windows Azure Active Directory Migration Services.
Problèmes connus et conseils

Installation de PES sur Windows Server 2012 et versions ultérieures
Les anciens guides ADMT ne mentionnent pas la nécessité d’exécuter le fichier pedmig.msi à une invite de
commandes avec élévation de privilèges. Le dernier guide ADMT mentionne cette exigence. Le dernier
guide date du 26 février 2018 et est disponible dans le Centre de téléchargement Microsoft.
L’ordinateur exécutant ADMT ne doit pas utiliser Credential Guard
La station de travail qui pilote la migration n’effectue pas la migration seule. Le mouvement de l’objet est
exécuté sur le contrôleur de domaine cible (DC). Il délégue l’utilisateur exécutant la tâche de migration
lors de la migration d’un utilisateur à partir du domaine source.
Par défaut, les contrôleurs de domaine sont configurés pour une délégation non contrainte qui n’est plus
autorisée par Credential Guard.
Si ADMT est installé sur un serveur membre basé sur Windows Server 2016 ou une version ultérieure
Windows serveur membre basé sur le serveur, vous devez désactiver Credential Guard pour exécuter des
migrations. Vous pouvez également déplacer l’installation ADMT vers le contrôleur de domaine cible, où
vous n’avez pas à déléguer. En outre, Credential Guard n’est pas pris en charge sur les contrôleurs de
domaine cibles.
Le contrôleur de domaine ne peut pas utiliser de délégation non contrainte
En raison des vecteurs d’attaque existants, Microsoft restreint et bloque l’utilisation de la délégation non
contrainte. Cela affecte également les contrôleurs de domaine. ADMT enregistre l’erreur suivante :
Erreur du journal ADMT : Impossible de déplacer l’objet source. Vérifiez que le compte de l’appelant
n’est pas marqué comme sensible et ne peut donc pas être délégué. hr=0x8009030e Aucune
information d’identification n’est disponible dans le package de sécurité
Le changement de comportement pour Windows Server 2008 R2 est contenu dans le 12 mars 2019-
KB4489885 (mise à jour de sécurité uniquement).
Microsoft PFE a abordé ce problème dans Get rid of accounts that use Kerberos Unconstrained
Delegation. Un autre blog décrit le plan de publication.
Vous pouvez configurer les contrôleurs de domaine cibles pour la délégation contrainte et autoriser les
contrôleurs de domaine cibles à déléguer aux contrôleurs de domaine sources (délégation contrainte
basée sur les ressources). Cela n’est possible que lorsque vos contrôleurs de domaine sont Windows
Server 2012 ou version ultérieure de Windows Server.
Dans Windows Server 2008 R2 ou version antérieure de Windows Server, vous pouvez uniquement
déplacer l’installation ADMT vers un contrôleur de domaine cible. Vous n’avez alors pas besoin de
déléguer.
TLS 1.0 doit être activé sur l’ordinateur ADMT pour se connecter à SQL Server
Si TLS 1.0 est désactivé, vous recevez un message semblable à ce qui suit sur l’ordinateur ADMT :
Impossible de rechercher les actions ayant échoué. : DBManager.ImanaDB.1 : [DBNETLIB]

[ConnectionOpen (SECCreateCredentials()).] Erreur de sécurité SSL.
En outre, si TLS 1.0 est désactivé, l’outil Administrateur ne charge pas le composant logiciel enfichable
lorsqu’il s’ouvre. Vous recevez un message qui ressemble à ce qui suit :
MMC n’a pas pu créer le composant logiciel enfichable.

MMC n’a pas pu créer le composant logiciel enfichable. Le composant logiciel enfichable n’a peut-être
pas été installé correctement.
Nom : Outil de migration Active Directory
CLSID : {E1975D70-3F8E-11D3-99EE-00C04F39BD92}
Les utilisateurs exécutant ADMT ne doivent pas être membres d’un silo d’authentification
Le compte d’utilisateur utilisé pour piloter la migration de SidHistory ne doit pas se trouver dans un silo
d’authentification. Lors de la migration de SidHistory dans la forêt, le contrôleur de domaine cible crée
une session réseau vers le contrôleur de domaine source et s’authentifie à l’aide de NTLM. Pour les
comptes d’utilisateur administrateur qui se trouvent dans un silo d’authentification, dans certains
systèmes d’exploitation, NTLM n’est pas autorisé pour ces comptes d’utilisateur par défaut ou est
désactivé par les utilisateurs.
Les domaines dans le flux d’authentification des tâches ADMT ne doivent pas restreindre NTLM
Pour la même raison que pour éviter les silos d’authentification, les domaines utilisés pour les migrations
ADMT SidHistory ne doivent pas restreindre l’utilisation de NTLM par l’une des stratégies.
versions SQL Server
Il n’existe aucune vérification de version pour les versions SQL Server qui ont ADMT. Les derniers tests
ont été exécutés en 2013. Par conséquent, les ordinateurs qui s’exécutent SQL Server 2014 et versions
ultérieures n’ont pas été testés. Effectuez vos propres tests d’ADMT dans un environnement de test avant
d’utiliser l’outil pour la migration de production.
Comptes de service administré de groupe
À compter du 27 février 2018, le Guide ADMT décrit comment gérer les comptes de service managés
comme implémentés dans Windows Server 2008 R2. Aucun test n’a été effectué pour les comptes de
service administrés de groupe (GMSA). Étant donné la gestion spéciale de ces comptes à plusieurs
endroits, vous devez suivre les instructions suivantes :
N’essayez pas de migrer GMSA au-delà des limites des forêts.
Soyez prudent lorsque vous essayez de déplacer GMSA dans une forêt.
Systèmes d’exploitation client
Bien que l’ensemble d’outils le plus récent ait été publié après Windows 8.0 sur le marché, il n’y a eu
aucun test pour la migration de compte d’ordinateur Windows 8.xand 10.x et, en particulier, aucun test de
migration complète des profils utilisateur.
Nous avons détecté plusieurs problèmes de migration liés à la transition correcte des profils utilisateur.
Cela est particulièrement vrai pour les inscriptions d’applications modernes et les autorisations de profil.
Répétez les migrations pour les mises à jour de mot de passe
Certains clients exécutent des migrations répétées de comptes pour transférer un nouveau mot de passe
d’un compte source vers un nouveau compte dans une autre forêt. ADMT n’est pas conçu pour cette
approche. Il effectue le suivi de chaque tâche de migration dans sa base de données. Au fil du temps, la
taille de la base de données ADMT augmente. Finalement, il peut rencontrer les éléments suivants :
La base de données dépasse la taille sous licence de la base de données (pour SQL déploiements
express).
La base de données dépasse l’espace disque disponible sur les ordinateurs qui exécutent SQL
Server.
Les tâches de migration ralentissent. Cela est dû au fait que l’outil analyse l’historique de migration
lorsque vous exécutez un nouveau travail.
NOTE
Si vous envisagez d’utiliser ADMT de cette façon pendant plusieurs semaines ou mois et que vous avez
une planification de synchronisation fréquente, nous vous recommandons d’utiliser une solution basée sur
une solution de synchronisation, telle que Microsoft Identity Manager.
References
Détails sur les silos d’authentification
Détails sur les stratégies de restriction NTLM
Comment résoudre les problèmes Inter-Forest
migration de mot de passe avec ADMTv2
Cet article décrit les dépendances et les étapes de résolution des problèmes courants associés à l’opération de
migration de mot de passe inter-forêts.
Résumé
Si vous effectuez des migrations intra-forêts à l’aide de l’outil de migration Active Directory (ADMT) v2, aucune
configuration spéciale n’est nécessaire pour gérer les mots de passe des utilisateurs, sIDHistory et les IDENTIFIC
(Globally Unique Identifiers) des objets pendant l’opération de déplacement.
Toutefois, si vous utilisez ADMTv2 pour effectuer une migration de mot de passe inter-forêts lorsque vous clonez
des comptes d’utilisateurs, cette opération repose sur des dépendances que l’administrateur doit configurer. Cet
article décrit les dépendances et les étapes de résolution des problèmes courants associés à cette opération.
Configuration
Au-delà de la configuration de base, ADMTv2 nécessite les dépendances suivantes lorsqu’il est utilisé pour
effectuer la migration de mot de passe inter-forêts :
Le Service Pack 6a (SP6a) ou une ultérieure doit être installé sur les contrôleurs de domaine Microsoft
Windows NT 4.0.
Tous les contrôleurs de domaine doivent utiliser le chiffrement 128 bits.
La valeur RestrictAnonymous sur le contrôleur de domaine cible doit être définie sur 0 pendant la
migration.
Les autorisations de lecture sur le groupe Accès compatible pré-Windows 2000 doivent être définies sur
CN=Ser ver,CN=System,DC={targetdom},DC={tld} .
La clé de Registre suivante doit être configurée sur le serveur d’exportation de mot de passe :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\AllowPasswordExport = 1
Le serveur d’exportation de mot de passe doit être redémarré après la modification du Registre.
Le groupe Tout le monde doit être membre du groupe Accès compatible pré-Windows 2000 dans le
domaine cible pendant la migration. Cette action est bloquée par utilisateurs et ordinateurs Active
Directory. Pour ajouter le groupe Tout le monde, exécutez la commande suivante : NET LOCALGROUP
« PRE-WINDOWS 2000 COMPATIBLE ACCESS » EVERYONE /ADD
Si le domaine cible est basé sur Windows Server 2003, exécutez cette commande pour faire du groupe
suivant un membre du groupe Accès compatible pré-Windows 2000 : NET LOCALGROUP « ACCÈS
COMPATIBLE PRÉ-WINDOWS 2000 » « LOGON ANONYME » /ADD
Voici quelques-uns des messages d’erreur les plus courants et leurs résolutions :
Impossible d’établir une session avec le serveur d’exportation de mot de passe. Le serveur cible n’a pas
de clé de chiffrement pour le domaine \ source {SRCDOM}. Cette erreur peut être causée par l’un des
problèmes de configuration suivants :
Le serveur d’exportation de mot de passe n’a pas été configuré avec la DLL de migration de mot de passe
et une clé de chiffrement pour le serveur cible.
ou -
La clé de chiffrement a été créée et installée, mais ADMT s’exécute sur un autre ordinateur que
l’ordinateur qui a créé la clé de chiffrement. Les clés de chiffrement de migration de mot de passe sont
valides par ordinateur et non par domaine.
WRN1:7557 Échec de la copie du mot de passe pour {user}. Un mot de passe fort a été généré à la place.
Impossible de copier le mot de passe. L’accès est refusé. Si ce message d’erreur apparaît dans le fichier
Migration.log, vérifiez les informations suivantes :
La valeur de clé de Registre suivante est définie sur les contrôleurs de domaine cibles :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\RestrictAnonymous = 0
Avant Windows 2000, l’accès compatible dispose d’autorisations de lecture et d’éumérer des
autorisations de domaine SAM complètes sur l’objet, comme suit : CN=Server,CN=System,DC=
{TargetDomain},DC={tld}
W1:7557 N’a pas réussi à copier le mot de passe pour {User}. Un mot de passe fort a été généré à la
place. Impossible de copier le mot de passe. Le serveur RPC n’est pas disponible. Ce message d’erreur
indique généralement l’échec de la résolution des noms. Vérifiez que la résolution des noms DNS
(Domain Name System) et NetBIOS (WINS) fonctionne correctement pour les deux domaines.
Comment résoudre les problèmes de migration
sIDHistory inter-forêts avec ADMTv2
Cet article explique comment résoudre les problèmes de migration sIDHistory inter-forêts avec l’outil de
migration Active Directory version 2 (ADMTv2).
Lorsque vous utilisez ADMTv2 pour migrer sIDHistory dans le cadre d’une migration d’utilisateur ou de groupe
inter-forêts, la configuration est requise avec les exigences de migration de base.
Par défaut, sIDHistory, mot de passe et objectGUID sont tous conservés pendant les migrations intra-forêts, mais
ce n’est pas le cas pour le clonage inter-forêts.
Étant donné qu’il n’existe aucun contexte de sécurité intégré pour les opérations inter-forêts, vous devez prendre
des mesures pour protéger la sécurité des opérations au-delà des limites de la forêt.
Configuration
Les conditions de base requises pour les opérations de migration inter-forêts sont :
Migration de base des comptes d’utilisateur et de groupe basée sur l’Assistant sans sIDHistory
Le domaine source doit faire confiance au domaine cible.
Le compte d’utilisateur qui exécute ADMTv2 doit avoir des droits d’administrateur dans le domaine source.
Le compte d’utilisateur ADMT doit avoir des autorisations déléguées pour créer des objets d’utilisateur ou de
groupe dans le conteneur cible.
La résolution de noms DNS (nom d’hôte) et NetBIOS entre les domaines doit exister.
La migration sIDHistory nécessite les dépendances supplémentaires suivantes
Audit de réussite et d’échec de la gestion des comptes pour les domaines source et cible.
Les domaines sources appellent l’audit de gestion des utilisateurs et des groupes.
Groupe local vide dans le domaine source nommé {SourceNetBIOSDom}$$$.
La HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport clé de Registre doit être
définie sur 1 sur le contrôleur de domaine principal du domaine source.
Vous devez redémarrer le contrôleur de domaine principal du domaine source après la configuration du
Registre.
Windows sécurité nécessite des informations d’identification utilisateur avec les droits d’administrateur ou
droits étendus MigratesIDHistory délégués dans le domaine cible. Vous ajoutez ces informations
d’identification dans l’Assistant lorsque la migration sIDHistory est allumée.
Pour déléguer l’étendue MigrateSidHistory directement sur un contrôleur de domaine ou sur un ordinateur sur
qui le pack d’outils d’administration Windows Server est installé, suivez les étapes suivantes :
1. Cliquez sur Démarrer , sur Outils d'administration , puis sur Utilisateurs et ordinateurs Active
Director y .
2. Cliquez avec le bouton droit sur le nom du domaine à partir de qui vous souhaitez déléguer l’étendue
MigrateSidHistory, puis cliquez sur Délégation de contrôle pour ouvrir la fenêtre De l’Assistant Délégation de
contrôle.
3. Cliquez sur Suivant, cliquez sur Ajouter, entrez le nom de l’utilisateur ou du groupe que vous souhaitez
ajouter dans la boîte de dialogue Sélectionner des utilisateurs, des ordinateurs ou des groupes, cliquez sur
OK, puis cliquez sur Suivant.
4. Cliquez pour sélectionner l’option Créer une tâche personnalisée à déléguer, puis cliquez sur Suivant.
5. Assurez-vous que ce dossier, les objets existants dans ce dossier et la création de nouveaux objets dans cette
option de dossier sont sélectionnés, puis cliquez sur Suivant .
6. Assurez-vous que l’option Général est sélectionnée, cliquez sur Migrer l’historique SID dans la liste
Autorisations, puis cliquez sur Suivant .
7. Vérifiez que les informations sont correctes, puis cliquez sur Terminer.
Aucun sID à migrer ne peut exister dans la forêt cible, soit en tant que sID principal, soit en tant
qu’attribut sIDHistory d’un autre objet.
Exigences supplémentaires pour la migration de sIDHistory avec la ligne de commande ou les interfaces de script
Lorsque vous démarrez une migration d’utilisateur ou de groupe avec la migration sIDHistory à partir de la
ligne de commande ou d’un script, la commande ou le script doit être exécuté sur le contrôleur de domaine
dans le domaine cible.
Le compte d’utilisateur qui exécute la migration doit avoir des droits d’administrateur dans les domaines
source et cible.
Conditions spéciales requises pour l’Assistant Fusion et mappage de groupes
Si sIDHistory doit être migré pendant le mappage et la fusion de groupes, l’étendue des groupes sources doit
correspondre à l’étendue du groupe cible.

L’étape la plus simple que vous pouvez utiliser pour résoudre les problèmes de migration sIDHistory inter-forêts
consiste à utiliser l’Assistant Migration de compte d’utilisateur ou l’Assistant Migration de compte de groupe
pour exécuter une migration en mode test.
Pendant la migration en mode test, ADMTv2 valide les dépendances suivantes :
Le groupe local {SourceNetBIOSDom}$$$ est créé.
TcpipClientSupport sur le contrôleur de domaine principal source ou l’émulateur de contrôleur de domaine
principal est allumé.
L’audit dans les deux domaines est désactivé.
Éventuellement, ADMT peut réparer toutes ces dépendances qui ne sont pas définies. Pour réparer ou configurer
ces paramètres, le compte utilisé pour exécuter ADMT doit avoir suffisamment d’autorisations dans chaque
domaine respectif pour effectuer les tâches.
Seul l’Assistant effectue ces vérifications et corrections. La ligne de commande et les interfaces de script
n’effectuent pas ces vérifications et ne fonctionnent pas sans une configuration correcte.
Messages d’erreur courants avec la migration sIDHistory inter-forêts
« Le handle n’est pas valide (code d’erreur = 6). »
Cette erreur indique un problème RPC dans lequel l’outil de migration ne peut pas se lier à un point de
terminaison RPC sur le contrôleur de domaine principal source. Les causes possibles sont les suivantes :
TcpipClientSupport sur le contrôleur de domaine principal source ou l’émulateur de contrôleur de domaine
principal n’a pas été allumé.
Le contrôleur de domaine principal ou l’émulateur du contrôleur de domaine principal n’a pas été redémarré
après la configuration de TcpipClientSupport.
La résolution de noms DNS ou NetBIOS ne fonctionne pas.
N’a pas pu vérifier l’audit et TcpipClientSupport sur les domaines. Ne sera pas en mesure de migrer sid’s. Le
groupe local spécifié n’existe pas.
Cette erreur indique généralement qu’un utilisateur ou un groupe global ou universel avec le nom
{SourceNetBIOSDom}$$$ existe déjà. ADMT crée généralement le groupe local de ce nom, mais il ne peut pas le
faire si un principal de sécurité existe déjà avec le nom.
N’a pas pu vérifier l’audit et TcpipClientSupport sur les domaines. Ne sera pas en mesure de migrer sid’s.
Cette erreur indique généralement que le compte d’utilisateur utilisé pour exécuter ADMT n’a pas les
autorisations suffisantes pour effectuer la migration dans l’un des domaines ou les deux. Échec de la recherche
de nom de domaine, rc=1332. Aucun mappage entre les noms de compte et les ID de sécurité n’a été effectué.
Cette erreur dans le fichier Migration.log après une migration avec sIDHistory indique généralement que le
domaine source a configuré des trusts qui n’existent pas sur le domaine cible. Pour résoudre ce problème,
exécutez l’Assistant Migration de l’trust pour maquer les trusts dans le domaine source, puis répliquez les
relations dans le domaine cible.
Informations supplémentaires sur sIDHistory

SIDHistory est un attribut à valeurs multiples de principaux de sécurité dans Active Directory qui peut contenir
jusqu’à 850 valeurs. Pour assurer la compatibilité ascendante avec les contrôleurs de domaine qui exécutent des
versions antérieures de Windows, l’attribut sIDHistory n’est disponible que dans les domaines qui fonctionnent
au niveau fonctionnel de Windows.
Certains produits de fournisseurs tiers vous offrent la possibilité d’activer sIDHistory dans les domaines en
mode mixte. Ces revendications ne représentent pas l’utilisation légitime des API publiques. Les administrateurs
de domaine qui utilisent ces outils risquent de placer leur déploiement Active Directory dans un état non pris en
compte.
Pendant les migrations intra-forêts, LDAP_Rename est responsable du déplacement des objets. Pour cette raison,
les objets migrés conservent des données d’identification importantes, notamment l’objectGUID et le mot de
passe. Ce n’est pas le cas pour les migrations inter-forêts, qui appellent DSAddSidHistory pour remplir l’attribut
dans le domaine cible. La migration de mot de passe peut être désactivée pour le clonage inter-forêts, mais
l’objectGUID est toujours perdu pendant ce type de migration.
Dans les deux cas, un nouveau sID est attribué aux objets migrés par le domaine cible. Le sID d’origine est ajouté
à l’attribut sIDHistory de l’objet migré dans le nouveau domaine. Après cela, l’attribut sIDHistory peut ne pas être
modifié ou supprimé à l’aide des outils d’administration Active Directory standard. Cette propriété n’est pas
autorisée, car l’attribut sIDHistory appartient au sam. Il est possible d’effacer sIDHistory à l’aide d’un script ou
d’un outil interne Microsoft non public.
Notez que sIDHistory est un outil de transition et n’est pas destiné à exister indéfiniment attaché aux principaux
de sécurité. Bien que la migration de sIDHistory puisse considérablement faciliter et simplifier le processus de
migration de domaine, il existe des implications importantes en matière de sécurité qui doivent être envisagées
avant d’implémenter sIDHistory dans une entreprise de production.
Un jeton Windows de sécurité peut contenir un maximum de 1 023 SIDD, y compris sIDHistory et les SIDD de
groupe. Kerberos est également limité car Windows Kerberos possède une mémoire tampon 73 sID. Cette taille
peut être multipliée par un changement de Registre à l’échelle de l’entreprise. Le dépassement de ces limites ne
respecte pas la restriction MaxTokenSize et peut entraîner des résultats imprévisibles, notamment l’échec de
l’authentification Kerberos et l’application de stratégies de manière imprévisible ou inexistante. Pour éviter ces
problèmes, utilisez la traduction de sécurité au lieu de sIDHistory comme solution à long terme pour maintenir
l’accès aux ressources après une migration de domaine.
Windows’application ne peut pas démarrer après
l’application de traduction de sécurité ADMT 3.2 en
Windows 8, Windows 8.1 et Windows 10
Cet article fournit une solution à une erreur qui se produit lorsque Windows App ne peut pas démarrer après
l’application de traduction de sécurité ADMT 3.2.
Applicabilité : Windows 10 - Toutes les éditions
Symptômes
Vous créez un compte d’utilisateur dans le domaine A.
Vous liez un compte Microsoft (MSA) au compte d’utilisateur.
Vous vous connectez à un ordinateur Windows 8, Windows 8.1 ou Windows 10 à l’aide du compte
d’utilisateur, puis vous installez une application Windows client.
Vous utilisez l’Outil de migration Active Directory (ADMT) 3.2 pour migrer le compte d’utilisateur du
domaine A vers le domaine B.
Vous exécutez une traduction de sécurité pour mettre à jour les paramètres d’autorisations sur l’ordinateur
client à l’aide du nouveau SID de domaine des utilisateurs.
Vous vous déconnectez, puis vous vous connectez à l’aide du compte d’utilisateur migré.
Dans ce scénario, les problèmes suivants se produisent :
La traduction de sécurité échoue et génère l’erreur 1314 dans le journal ADMT sur le client sur lequel
l’agent de traduction de sécurité a été dirigé. L’entrée du journal ressemble à ce qui suit.
DÉC IM A L H EX SY M B O L IQ UE C O N VIVIA L
1314 0x522 ERROR_PRIVELEGE_NOT_ Un privilège requis n’est

HELD pas détenu par le client.
Les applications intégrées et stockées ne peuvent pas démarrer sur des ordinateurs Windows 8, basés sur
Windows 8.1 ou Windows 10 de données.
Le fait de cliquer sur le bouton Démarrer n’ouvre pas le menu Démarrer sur Windows 10 ordinateurs
basés sur un ordinateur.
Si vous basculez en mode tablette, puis revenir au mode précédent dans Windows 10, le menu
Démarrer continue de fonctionner, mais les autres applications intégrées et stockées ne démarrent pas.
La recherche ne répond pas.

L’application Paramètres ne démarre pas sur les ordinateurs basés sur Windows 10 lorsque vous cliquez
directement sur l’icône Paramètres ou que vous utilisez le raccourci clavier Windows+I. Cette
application fonctionne la première fois qu’elle est démarrée et elle fonctionne également lorsque vous
utilisez le menu raccourci Paramètres d’affichage sur le Bureau.
Vous ne pouvez pas afficher .jpg fichiers, car l’application moderne affectée dans l’outil d’associations de
fichiers ne démarre pas. Lorsque cela se produit, vous recevez le message d’erreur suivant :
Valeur non valide pour le Registre
Lorsque vous cliquez sur l’application Store dans la barre des Windows d’un ordinateur Windows 10, la
commande échoue et vous recevez le message d’erreur suivant :
Cette application ne peut pas être installée.
Pour contourner ce problème, procédez comme suit :
1. Migrez les comptes d’utilisateur sur un Windows 8 d’exploitation pré-Windows 8 vers le domaine de
destination avant de mettre à niveau les comptes vers Windows 10.
2. Pour Windows applications installées à partir du Microsoft Store, désinstallez puis réinstallez l’application.
3. Protéger les données d’application : protégez et restituer les données selon les besoins afin d’éviter la perte
de données. Les données peuvent être copiées ou restaurées dans un compte d’utilisateur nouveau ou
différent qui n’est pas encore soumis à la traduction de sécurité.
References
Guide de l’outil de migration Active Directory (ADMT) : migration et réorganisation des domaines Active
Directory
Guide de résolution des problèmes de réplication
Active Directory
E S S AY E Z N O T R E - virtuel Il peut vous aider à identifier et à résoudre rapidement les problèmes courants de
AGENT
réplication Active Directory
Cet article est conçu pour vous aider à résoudre les problèmes de réplication Active Directory.
Liste de contrôle de dépannage

Utilisez la liste de vérification suivante pour résoudre les problèmes de réplication suivants :
Les événements d’erreur et d’avertissement dans le journal des événements du service d’annuaire
indiquent la contrainte spécifique qui provoque un échec de réplication sur le contrôleur de domaine
source ou de destination. Si le message d’événement suggère des étapes pour une solution, essayez les
étapes décrites dans l’événement.
Les outils de diagnostic tels que Repadmin fournissent également des informations qui peuvent vous
aider à résoudre les échecs de réplication. Pour surveiller la réplication et diagnostiquer les erreurs,
utilisez l’une des méthodes suivantes :
Téléchargez et exécutez l’outil Support Microsoft et l’Assistant Récupération.
Utilisez l’outil État de réplication Active Directory si vous souhaitez uniquement analyser l’état de la
réplication.
Excluez les interruptions intentionnelles ou les défaillances matérielles.
Dans un scénario : un contrôleur de domaine est généré dans un site intermédiaire. Le contrôleur de
domaine est actuellement hors connexion et attend son déploiement sur le site de production final, un
site distant tel qu’une filiale.
Lorsqu’un autre contrôleur de domaine tente de répliquer avec le contrôleur de domaine, il signale des
erreurs de réplication. Vous pouvez tenir compte de ces erreurs de réplication.
Les problèmes de réplication peuvent être causés par une défaillance matérielle.
Les appels de procédure distante de réplication Active Directory se produisent dynamiquement sur un
port disponible via le MAPP RPC (Rpc Endpoint Mapper) sur le port 135. Assurez-vous que Windows
Defender Pare-feu avec Advanced Security et d’autres pare-feu sont correctement configurés pour activer
la réplication.
Une fois que vous avez exclu les déconnexions intentionnelles et les défaillances matérielles, les problèmes de
réplication peuvent avoir l’une des causes suivantes :
Connectivité réseau : la connexion réseau peut ne pas être disponible ou les paramètres réseau peuvent ne
pas être configurés correctement.
Résolution de noms : les erreurs de configuration DNS sont une cause courante d’échecs de réplication.
Moteur de réplication : si les planifications de réplication intersite sont trop courtes, les files d’attente de
réplication peuvent être trop volumineuses pour être traitées dans le temps requis par la planification de
réplication sortante. Dans ce cas, la réplication de certaines modifications peut être bloquée indéfiniment, ou
suffisamment longue pour dépasser la durée de vie de la pierre tombale.
Topologie de réplication : les contrôleurs de domaine doivent avoir des liens intersite dans services de
domaine Active Directory (AD DS) qui correspondent à des connexions réseau étendu réel (WAN) ou à
réseau privé virtuel (VPN). Si vous créez des objets dans AD DS pour la topologie de réplication qui ne sont
pas pris en charge par la topologie de site réelle de votre réseau, la réplication qui nécessite la topologie mal
configurée échoue.
Authentification et autorisation : les problèmes d’authentification et d’autorisation provoquent des erreurs «
accès refusé » lorsqu’un contrôleur de domaine tente de se connecter à son partenaire de réplication.
Magasin de bases de données d’annuaires : la base de données d’annuaire peut ne pas être en mesure de
traiter les transactions suffisamment rapidement pour suivre les délais d’expiration de la réplication.
Solutions courantes pour les problèmes de réplication Active

Directory
Surveillez l’intégrité de la réplication quotidiennement ou utilisez-la Repadmin pour récupérer l’état de la
réplication quotidiennement.
Essayez de résoudre les échecs signalés en temps voulu à l’aide des méthodes décrites dans les messages
d’événement et ce guide. Si le logiciel est à l’origine du problème, désinstallez-le avant de continuer à essayer
d’autres solutions.
Si le problème qui provoque l’échec de la réplication ne peut pas être résolu par des méthodes connues,
supprimez AD DS du serveur, puis réinstallez-le. Pour plus d’informations sur la réinstallation d’AD DS,
consultez Désaffectation d’un contrôleur de domaine.
Si AD DS ne peut pas être supprimé de manière classique lorsque le serveur est connecté au réseau, utilisez
l’une des méthodes suivantes pour résoudre le problème :
Forcez la suppression d’AD DS en mode de restauration des services d’annuaire (DSRM), nettoyez les
métadonnées du serveur, puis réinstallez AD DS.
Réinstallez le système d’exploitation et régénérez le contrôleur de domaine.
Problèmes et solutions courants

La plupart des problèmes de réplication sont identifiés dans les messages d’événement qui sont enregistrés
dans le journal des événements du service d’annuaire. Les problèmes de réplication peuvent également être
identifiés sous la forme de messages d’erreur dans la sortie de la repadmin /showrepl commande.
Message repadmin :
La durée de vie de la dernière réplication avec ce serveur a dépassé la durée de vie de la pierre tombale.
Une réplication entrante d’un contrôleur de domaine a échoué avec le contrôleur de domaine source nommé
suffisamment longtemps pour qu’une suppression ait été supprimée, répliquée et récupérée à partir d’AD DS.
Consultez l’ID d’événement de réplication Active Directory 2042.
Message repadmin :
Aucun voisin entrant
Si aucun élément n’apparaît dans la section « Voisins entrants » de la sortie générée par repadmin /showrepl , le
contrôleur de domaine n’a pas pu établir de liens de réplication avec un autre contrôleur de domaine. Consultez
l’ID d’événement de réplication Active Directory 1925.
Code d’erreur 5
Message repadmin :
Il existe un lien de réplication entre deux contrôleurs de domaine, mais la réplication ne peut pas être effectuée
correctement en raison d’un échec d’authentification. Voir l’échec de la réplication Active Directory avec l’erreur
5 : l’accès est refusé.
Code d’erreur 49
Message repadmin :
Erreur LDAP 49.
Le compte d’ordinateur du contrôleur de domaine peut ne pas être synchronisé avec le centre de distribution de
clés (KDC). Corrigez les problèmes de sécurité de réplication.
ID d’événement 1925 et ID d’événement 2087
Message repadmin :
Impossible d’ouvrir la connexion LDAP à l’hôte local.
L’outil d’administration n’a pas pu contacter AD DS. Consultez les articles suivants :
ID d’événement 1925, ID d’événement 2087 et ID d’événement 2088
Message repadmin :
Échec de la <date - time> dernière tentative avec le « Nom du compte cible incorrect ».
Ce problème peut être lié à des problèmes de connectivité, DNS ou d’authentification. Si cette erreur est une
erreur DNS, le contrôleur de domaine local n’a pas pu résoudre le nom DNS basé sur l’identificateur global
unique (GUID) de son partenaire de réplication. Consultez les articles suivants :
Collecte de données
Avant de contacter le support Microsoft, vous pouvez collecter des informations sur votre problème.
Conditions préalables
1. TSSv2 doit être exécuté par des comptes disposant de privilèges d’administrateur sur le système local, et le
CLUF doit être accepté (une fois le CLUF accepté, TSSv2 n’est plus invité).
2. Nous vous recommandons la stratégie d’exécution PowerShell de l’ordinateur RemoteSigned local.
NOTE
Si la stratégie d’exécution PowerShell actuelle n’autorise pas l’exécution de TSSv2, effectuez les actions suivantes :
Définissez la RemoteSigned stratégie d’exécution pour le niveau de processus en exécutant l’applet de commande
PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned .
Pour vérifier si la modification prend effet, exécutez l’applet de commande PS C:\> Get-ExecutionPolicy -List .
Étant donné que les autorisations au niveau du processus s’appliquent uniquement à la session PowerShell actuelle,
une fois la fenêtre PowerShell donnée dans laquelle TSSv2 s’exécute est fermée, l’autorisation affectée pour le niveau de
processus revient également à l’état précédemment configuré.
Collecter les informations clés avant de contacter le support Microsoft

1. Téléchargez TSSv2 sur tous les nœuds et décompressez-le dans le dossier C:\tss_tool .
2. Ouvrez le dossier C:\tss_tool à partir d’une invite de commandes PowerShell avec élévation de privilèges.
3. Exécutez l’outil SDP pour collecter les journaux à partir des nœuds source et de destination.
4. Décompressez le fichier et exécutez l’applet de commande suivante sur les deux nœuds :
TSSv2.ps1 -SDP HyperV -SkipSDPList skipBPA,skipTS
Collectez tous les journaux d’activité. Compressez et chargez la collection sur l’espace de travail.
Référence
Résoudre les erreurs courantes de réplication Active Directory
Surveillance et dépannage d'Active Directory réplication à l'aide de Repadmin
Les modifications Active Directory ne sont pas
répliquées
Cet article fournit une solution à un problème dans lequel la réplication n’est pas terminée lorsque vous
répliquez les modifications apportées au service d’annuaire Active Directory sur un contrôleur de domaine.
Symptômes
Lorsque vous essayez de répliquer les modifications apportées au service d’annuaire Active Directory vers un
contrôleur de domaine Microsoft Windows Server 2003, la réplication n’est pas terminée.
Dans le journal des événements, vous pouvez voir des événements semblables à ce qui suit : Dans ce cas,
l’erreur 1818 s’affiche également dans la sortie de la commande repadmin /showrepl et dans la sortie de la
commande repadmin /showreps.
Cause
Ce problème peut se produire lorsque les contrôleurs de domaine de destination qui effectuent une réplication
RPC (Remote Procedure Call) ne reçoivent pas de modifications de réplication d’un contrôleur de domaine
source dans le délai spécifié par le paramètre de Registre rpc Replication Timeout (mins). Vous pouvez être le
plus souvent face à ce problème dans l’une des situations suivantes :
Vous faites la promotion d’un nouveau contrôleur de domaine dans la forêt à l’aide de l’Assistant Installation
d’Active Directory (Dcpromo.exe).
Les contrôleurs de domaine existants répliquent à partir des contrôleurs de domaine source connectés sur
des liaisons réseau lentes.
La valeur par défaut du paramètre de Registre Délai d’accès au registre de réplication RPC (mins) sur Windows
ordinateurs basés sur 2000 est de 45 minutes. La valeur par défaut du paramètre de Registre Délai d’accès au
registre de réplication RPC (mins) sur les ordinateurs basés sur Windows Server 2003 est de 5 minutes. Lorsque
vous avez mis à niveau le système d’exploitation de Windows 2000 vers Windows Server 2003, la valeur du
paramètre de Registre Délai d’accès au délai d’accès à la réplication RPC (mins) est modifiée de 45 minutes à 5
minutes. Si un contrôleur de domaine de destination qui effectue une réplication RPC ne reçoit pas le package
de réplication demandé dans le délai spécifié par le paramètre de Registre Délai d’heure de réplication RPC
(mins), le contrôleur de domaine de destination met fin à la connexion RPC avec le contrôleur de domaine
source non réactif et enregistre un événement d’avertissement.
Résolution
IMPORTANT
restaurer en cas de problème. Pour plus d’informations sur la façon de la back up et de la restauration du Registre, cliquez
sur le numéro d’article suivant pour afficher l’article de la Base de connaissances Microsoft : 322756 How to back up and
restore the Registry in Windows
Pour résoudre ce problème, augmentez la bande passante de votre connexion réseau afin que les modifications
Active Directory se répliquent au cours du délai d’attente de cinq minutes. Si vous ne pouvez pas augmenter la
bande passante de votre connexion réseau, modifiez le Registre sur votre ordinateur Windows Server 2003
pour augmenter la valeur du délai d’accès RPC pour la réplication Active Directory. Pour augmenter la valeur du
délai d’accès RPC, suivez les étapes suivantes :
2. Recherchez la sous-clé de Registre suivante :
3. Cliquez avec le bouton droit sur Paramètres, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
4. Tapez rpc Replication Timeout (mins), puis appuyez sur Entrée pour nommer la nouvelle valeur.
5. Cliquez avec le bouton droit sur Délai d’application de la réplication RPC (min), puis cliquez sur
Modifier.
6. Dans la zone de données Valeur, tapez le nombre de minutes que vous souhaitez utiliser pour le délai d’accès
RPC pour la réplication Active Directory, puis cliquez sur OK . Sur un ordinateur Windows Server 2003 qui
fait partie d’un environnement Windows 2000 ou qui a été mis à niveau à partir de Windows 2000 Server,
vous pouvez définir cette valeur sur 45 minutes.
NOTE
Vous devez redémarrer l’ordinateur pour activer les modifications apportées au délai d’erreur de réplication RPC
(mins).
Erreur de réplication Active Directory 1256 : le
système distant n’est pas disponible
Cet article décrit les symptômes, la cause et les étapes de résolution pour les cas où la réplication Active
Directory échoue avec l’erreur 1256 : Le système distant n’est pas disponible.
Symptômes
1. DcDIAG signale que le test réplications Active Directory a échoué avec l’erreur 1256 : Le système distant
n’est pas disponible.
Test de démarrage : réplications

[Vérification des réplications, <Destination DC>] Une tentative de réplication récente a échoué :
De <source DC> à <destination DC>
Contexte d’attribution de noms : <directory partition DN path>
La réplication a généré une erreur (1256) :
Le système distant n’est pas disponible. Pour plus d’informations sur la résolution des
problèmes réseau, voir Windows’aide.
L’échec s’est produit à <date> <time>
Le dernier succès s’est produit à l' <date> <time>
2. REPADMIN.EXE signale qu’une tentative de réplication a échoué avec l’état 1256. Les commandes
REPADMIN qui mentionnent généralement l’état 1256 sont les suivantes :
REPADMIN /REPLSUM
REPADMIN /SHOWREPS
REPADMIN /SHOWREPL
REPADMIN /FAILCACHE
Un exemple de sortie REPADMIN /SHOWREPS de la représentation de la réplication entrante de LonEMEADC

vers LonContosoDC ayant échoué avec le système distant n’est pas disponible est illustré ci-dessous :
Repadmin : exécution de la commande /showrepl par rapport à l’host local DC complet

Londres\LONCONTOSODC
Options DSA : IS_GC
Options de site : (aucune)
GUID d’objet DSA : a29bbfda-8425-4cb9-9c66-8e07d505a5c6
DSA invocationID: d58a6322-6a28-4708-82d3-53b7dcc13c1a
==== INBOUNDBOUNDONS =======================================
<snip>
DC=ForestDnsZones,DC=Contoso,DC=com
Londres\CASMEADC via RPC
GUID d’objet DSA : cd691606-63d1-4cc8-b77a-055674ba569d
Last attempt @ 2010-06-10 17:35:46 failed, result 1256 (0x4e8) :
Le système distant n’est pas disponible. Pour plus d’informations sur la résolution des problèmes
réseau, voir Windows’aide.
<#> échecs consécutifs.
Dernière réussite @ <date> <time>.
3. Les événements NTDS KCC, réplication NTDS ou ActiveDirectory_DomainService avec l’état 1256 sont
enregistrés dans le journal des événements du service d’annuaire.
SO URC E DE L 'ÉVÉN EM EN T ID D’ÉVÉN EM EN T C H A ÎN E D’ÉVÉN EM EN T
Réplication NTDS 1085 * Événement interne : Les services de

ActiveDirectory_DomainService domaine Active Directory n’ont pas
pu synchroniser la partition
d’annuaire suivante avec le service
d’annuaire à l’adresse réseau
suivante.
NTDS KCC 1308 Le contrôleur de cohérence des

ActiveDirectory_DomainService connaissances (KCC) a détecté que
les tentatives successives de
réplication avec le contrôleur de
domaine suivant ont constamment
échoué. Le contrôle de cohérence
des connaissances (KCC) a détecté
que les tentatives successives de
réplication avec le service d’annuaire
suivant ont constamment échoué.
NOTE
L’événement 1085 est journalisé uniquement si la valeur 5 des diagnostics NTDS événements de réplication a été
définie sur une valeur de 1 ou supérieure.
Cause
L’état de réplication 1256 est enregistré pour la raison suivante :
Lorsque le dc de destination ne parvient pas à se lier à la source DC à l’aide de RPC, un code d’erreur win32 dans
l’état Repsfrom pour cette partition - généralement schéma ou configuration, car ces partitions sont répliquées
avec une priorité supérieure. Une fois qu’une erreur de liaison RPC s’est produite, une routine de nettoyage
s’exécute pour effacer la file d’attente des DCS de destination de cette même source DC. Cela permet d’éviter
toute tentative de réplication avec un dc à qui il ne peut pas se connecter. Étant donné qu’il n’a pas tenté de
synchroniser les partitions qui ont été effacées de la file d’attente, l’état 1256 est enregistré. Dans un scénario où
dc de destination réplique le schéma, la configuration et plusieurs partitions GC non accessibles en writable à
partir de la source DC, l’état d’erreur win32 pour les partitions de schéma et de configuration qui ont provoqué
l’échec de la liaison RPC est journalisé. Le dc de destination annule ensuite les tâches de réplication en attente
pour les partitions restantes et enregistre l’erreur win32 1256 pour l’état.
Résumé : 1256 est consigné en tant qu’état de réplication par partition suite à l’annulation de la demande de
synchronisation par le dc source par le dc de destination en raison d’une défaillance de connectivité
précédemment rencontrée.
Résolution
L’erreur win32 1256 ne doit pas être au centre des efforts de dépannage. Recherchez plutôt l’état de réplication
qui a conduit à l’échec de liaison RPC, puis suivez l’article correspondant dépannage des opérations Active
Directory qui échouent avec erreur...
Diagnostiquer les échecs de réplication Active Directory.
Pour déterminer l’erreur win32 à résoudre, utilisez l’une des méthodes suivantes :
1. Affichage repadmin /showreps ou sortie /showrepl sur le dc de destination
a. Identifier le dc source dans la sortie et lister tous les messages d’état win32 par partition
b. L’état win32 répertorié qui n’est pas un 1256 doit être au centre des efforts de dépannage
2. Utilisez la repadmin /showrepl * /csv sortie :
a. Colonne de filtre K, État de la dernière défaillance : Désélection 0 et (vides)
b. Colonne de filtre C, Destination DSA : Désélectionner ( Sélectionner tout) et sélectionner
uniquement le dc où l’état 1256 est enregistré.
c. Si 1256 est connecté à plusieurs dc source, colonne de filtre F, DSA source : Désélectionner (
sélectionner tout) et sélectionner un seul DC pour affiner le focus.
d. Colonne K, État de la dernière défaillance rép. rép. 1256, ainsi que l’erreur win32 réelle qui a conduit à
l’échec de liaison RPC.
Dans l’exemple suivant, l’erreur win32 1722 est enregistrée pour les partitions de configuration et de
schéma et doit être au centre du dépannage.
B C D E F H I J K
Site Destina Context Source Source Nombre Heure Heure État de

DSA de tion e DSA DSA d’échec de la de la la
destina DSA d’attrib Site s dernièr dernièr dernièr
tion ution e e e
de défailla réussite défailla
noms nce nce
Londres LONCO CN=Con Londres ERMEAD 11 6/10/20 6/10/20 1722

NTOSOD figuratio C 10 17:35 10 14:50
C n,DC=C
ontoso,
DC=com
Londres LONCO CN=Sch Londres ERMEAD 11 6/10/20 6/10/20 1722

NTOSOD ema,CN C 10 17:36 10 14:50
C =Config
uration,
DC=Con
toso,DC
=com
Londres LONCO DC=For Londres ERMEAD 11 6/10/20 6/10/20 1256

NTOSOD estDnsZ C 10 17:35 10 14:50
C ones,DC
=Contos
o,DC=co
m
Londres LONCO DC=cor Londres ERMEAD 11 6/10/20 6/10/20 1256

NTOSOD p,DC=C C 10 17:35 10 14:50
C ontoso,
DC=com
B C D E F H I J K
Londres LONCO DC=EM Londres ERMEAD 11 6/10/20 6/10/20 1256

NTOSOD EA,DC= C 10 17:35 10 14:54
C Contoso,
DC=com
Londres LONCO DC=apa Londres ERMEAD 11 6/10/20 6/10/20 1256

NTOSOD c,DC=Co C 10 17:35 10 14:50
C ntoso,D
C=com
3. Lancez une synchronisation de réplication manuelle entre les DCS source et de destination à l’aide du
repadmin.
(Cela nécessite un
Repadmin /replicate DestinationDC SourceDC <DN of partition reporting status 1256>
commutateur /readonly pour la partition GC ou le commutateur /selsecrets si la destination est un
RODC)
repadmin /replicate loncontosodc lonemeadc.emea.contoso.com dc=forestdnszones,dc=contoso,dc=com
Échec de DsReplicaSync() avec l’état 1722 (0x6ba) :
Le serveur RPC n’est pas disponible.
Notez qu’après avoir lancé manuellement la réplication pour la partition, l’état est passé de 1256 à 1722 :
B C D E F H I J K
Destina Destina Context Source Source Nombre Heure Heure État de

tion tion e DSA DSA d’échec de la de la la
DSA DSA d’attrib Site s dernièr dernièr dernièr
Site ution e e e
de défailla réussite défailla
noms nce nce
Londres LONCO CN=Con Londres ERMEAD 11 6/10/20 6/10/20 1722

NTOSOD figuratio C 10 17:35 10 14:50
C n,DC=C
ontoso,
DC=com
Londres LONCO CN=Sch Londres ERMEAD 11 6/10/20 6/10/20 1722

NTOSOD ema,CN C 10 17:36 10 14:50
C =Config
uration,
DC=Con
toso,DC
=com
Londres LONCO DC=For Londres ERMEAD 12 6/10/20 6/10/20 1722

NTOSOD estDnsZ C 10 17:46 10 14:50
C ones,
DC=Con
toso,DC
=com
B C D E F H I J K
Londres LONCO DC=cor Londres ERMEAD 11 6/10/20 6/10/20 1256

NTOSOD p,DC=C C 10 17:35 10 14:50
C ontoso,
DC=com
Londres LONCO DC=EM Londres ERMEAD 11 6/10/20 6/10/20 1256

NTOSOD EA,DC= C 10 17:35 10 14:54
C Contoso,
DC=com
Londres LONCO DC=apa Londres ERMEAD 11 6/10/20 6/10/20 1256

NTOSOD c,DC=Co C 10 17:35 10 14:50
C ntoso,D
C=com
Les articles suivants contiennent les procédures de dépannage pour les erreurs généralement consignées avec
l’erreur win32 1256 :
ERREUR W IN 32 A RT IC L E
-2146893022 Erreur de réplication Active Directory - 2146893022 : le nom

de principal cible est incorrect
5 Erreur de réplication Active Directory 5 - Accès refusé
1722 Erreur de réplication Active Directory 1722 : le serveur RPC

n’est pas disponible
1727 Résoudre l’erreur de réplication du contrôleur de domaine

1727 - L’appel de procédure distante a échoué et ne s’est
pas exécuté
1753 Erreur de réplication Active Directory 1753 : aucun point de

terminaison n’est disponible à partir du mappeur de point de
terminaison
1908 Résolution des problèmes d’opérations Active Directory

ayant échoué avec l’erreur 1908 : Le contrôleur de domaine
pour ce domaine n’a pas pu être trouvé
8524 Erreur de réplication Active Directory 8524 : l’opération DSA

ne peut pas se poursuivre en raison d’un échec de recherche
DNS
8453 Erreur de réplication Active Directory 8453 : l’accès à la

réplication a été refusé
Erreur de réplication Active Directory 8304 : « La
taille maximale d’un objet a été dépassée »

S’applique à : Versions de Windows Server Windows pris en charge
Résumé
Cet article décrit les causes et les solutions de l’erreur de réplication Active Directory 8304 (0x2070) : « La taille
maximale d’un objet a été dépassée ».
NOTE
Vous pouvez obtenir le texte convivial du code d’erreur en exécutant la net helpmsg 8304 commande.
Symptômes
Vous pouvez être l’un des symptômes suivants.
Symptôme 1
La commande signale que le test de réplication Active Directory a échoué et a généré l’erreur 8304 : « La taille
maximale d’un objet dcdiag a été dépassée ».
Starting test: Replications

[Replications Check, <DESTINATION DC>] A recent replication attempt failed:
From <SOURCE DC>to <DESTINATION DC>
Naming Context: <directory partition DN path>
The replication generated an error (8304):
The maximum size of an object has been exceeded.
The failure occurred at <date><time>.
The last success occurred at <date><time>.
......................... <DESTINATION DC> failed test Replications
Symptôme 2
Lorsque vous cliquez avec le bouton droit sur un objet de connexion à partir d’un contrôleur de domaine source,
puis que vous sélectionnez Répliquer maintenant, la réplication échoue et génère le message d’erreur suivant :
Répliquer maintenant
L’erreur suivante s’est produite lors de la tentative de synchronisation du contexte d’attribution de noms du
contrôleur de domaine <active directory partition name> au contrôleur de domaine <source DC>
<destination DC> :
La taille maximale d’un objet a été dépassée
L’opération ne se poursuit pas
Symptôme 3
Diverses repadmin.exe de commande échouent et génèrent l’erreur 8304. Ces commandes incluent, sans s’y
limiter, les éléments suivants :
repadmin /add
repadmin /replsum
repadmin /showrepl
repadmin /showrepl
repadmin /syncall
Symptôme 4
L’ID d’événement 1084 est consigné dans le journal des événements du service d’annuaire des DCS qui tentent
de répliquer des objets Active Directory entrants.
Log Name: Directory Service

Event ID: 1084
Level: Error
User: ANONYMOUS LOGON
Computer: <Destination DC>
Description:
Internal event: Active Directory Domain Services could not update the following object with changes received
from the following source directory service. This is because an error occurred during the application of the
changes to Active Directory Domain Services on the directory service.
Object:
CN=john\0ADEL:<GUID>,CN=Deleted Objects,<directory partition DN path>
Object GUID:
<GUID>
Source directory service:
<GUID>._msdcs.contoso.com
Synchronization of the directory service with the source directory service is blocked until this update
problem is corrected.
This operation will be tried again at the next scheduled replication.
User Action
Restart the local computer if this condition appears to be related to low system resources (for example, low
physical or virtual memory).
Additional Data
Error value:
8304 The maximum size of an object has been exceeded.
Vous pouvez également voir un événement 1093 :

Log Name: Directory Service
Event ID: 1093
Level: Warning
Computer: <Destination DC>
Description:
Active Directory Domain Services could not update the following object with attribute changes because the
incoming change caused the object to exceed the maximum object record size. The incoming change to the
following attribute will be reversed in an attempt to complete the update.
Object:
CN=<MachineName>\0ADEL:<GUID>,CN=Deleted
Objects,DC=xxxx,DC=domainname,DC=com
Object GUID:
<GUID>
Attribute:
9030d (lastKnownParent)
The current value (without changes) of the attribute on the local directory partition will replicate to all
other directory services. This will counteract the change to the rest of the directory services. The
reversal values may be recognized as follows:
Version:
2
Time of change:
<DateTime>
Update sequence number:

65064475
Note this event may not quote the attribute that has the most data or values. It quotes the update for the
attribute that made the object size overflow.
Cause
L’erreur 8304 est consignée lorsque le contrôleur de domaine tente de répliquer un objet qui dépasse la taille
maximale.
La cause la plus courante est d’avoir un attribut non lié avec un grand nombre de valeurs. En raison de la
structure interne de la base de données Active Directory et de la taille d’enregistrement de base de données
Active Directory de 8 Ko, cette limite de valeurs est d’environ 1 200 à 1 300 valeurs, en fonction de la population
d’autres attributs non liés.
Sur le serveur source, lorsque vous utilisez un outil comme LDP ou exécutez la commande sur l’objet, la sortie
ressemble à repadmin /showattr /allvalues /extended ce qui suit :
1> distinguishedName:<GUID=<GUID>>;CN=Allowedclients\0ADEL:<GUID>,CN=Deleted
Objects,CN=Configuration,DC=contoso,DC=com
1> instanceType: 0x4 = ( WRITE )
1> whenCreated: 25.4.2018. 13:48:07Central European Daylight Time
1> msDS-LastKnownRDN: Allowed clients
1>msExchSmtpReceiveMaxRecipientsPerMessage: 200
1243> msExchSmtpReceiveRemoteIPRanges:10.142.241.142;…
Voici les attributs que vous pouvez rencontrer :
proxyAddresses
servicePrincipalName
userCertificate
msExchSmtpReceiveRemoteIPRanges
dnsRecord
msiFileList
msTSProperty01, msTSProperty02, ...
registeredAddress
NOTE
Ce problème peut se produire pour tout attribut non lié à valeurs multiples. L’attribut avec une syntaxe liée ou liée à des
données n’est pas affecté par ce problème.
Selon les ressources disponibles et la population réelle des pages de base de données locales, la limite peut être
atteint à un nombre de valeurs différent. C’est pourquoi une modification peut être prise par certaines instances
de contrôleur de domaine ou LDS, mais pas par d’autres.
Ce problème peut également se produire lorsqu’une valeur d’attribut unique dépasse environ 5 Mo. La
transaction de base de données AD doit contenir la valeur précédente et la nouvelle valeur lorsque la valeur
d’attribut est mise à jour.
Résolution
Cette limite est indépendante de la version du système d’exploitation microsoft LDAP Server. Il n’existe aucune
solution de contournement à cette limitation. Vous devez éventuellement réviser votre application et la façon
dont elle utilise cet attribut.
L’événement 1084 listera l’objet qui a dépassé la taille maximale. Si l’objet est un objet en cours, identifiez
l’attribut qui a trop de valeurs et supprimez certaines des valeurs sur le contrôleur de domaine source.
Si l’objet est un objet supprimé et que la Corbeille Active Directory est activée, la meilleure méthode pour
corriger le problème consiste à forcer l’objet à devenir un objet recyclé. Lorsque l’objet est recyclé, Active
Directory supprime la plupart des attributs. En règle générale, cela réduit suffisamment la taille de l’objet pour
qu’il puisse être répliqué correctement. Ce processus supprime véritablement l’objet et le rend irrécable de la
Corbeille. Si l’objet est un principal de sécurité tel qu’un compte d’utilisateur, nous vous recommandons de ne
pas le déléviser. Si un objet suffisamment grand n’est pas supprimé, certains attributs risquent d’être
correctement définies. Cela peut endommager l’objet et l’empêcher d’être utilisé ou même supprimé.
La commande PowerShell suivante peut être utilisée pour forcer l’objet à l’état recyclé.
NOTE
La commande suivante doit être exécuté sur le contrôleur de domaine répertorié dans l’événement 1084 en tant que
contrôleur de domaine source. L’événement liste également le nom unique de l’objet.
Get-ADObject <dn of object> -IncludeDeletedObjects | Remove-ADObject
Par exemple :
Get-ADObject "CN=john\0ADEL:<GUID>,CN=Deleted Objects,dc=contoso,dc=com" | Remove-ADObject
Une fois l’objet recyclé, utilisez sites et services Active Directory pour essayer de forcer la réplication.
Voici quelques suggestions pour éviter la limite des problèmes passés de Microsoft.
Utilisation de l’attribut dnsRecord par Microsoft DNS Server
Chaque adresse IP ou cible de nom SRV est une valeur supplémentaire de l’attribut dnsRecord. Par défaut,
chaque contrôleur de domaine dans Active Directory inscrit une série de noms auprès du DNS, certains sont
basés sur les sites couverts par le contrôleur de domaine, d’autres sont sans site. La limite est généralement
atteinte pour les noms sans site.
Lorsque vous approchez un grand nombre de contrôleurs de domaine dans un domaine, comme 1 200
contrôleurs de domaine, il peut y avoir des problèmes de mise à jour des objets DNS pour les noms avec les
valeurs supplémentaires. Dans un tel domaine, il n’est souvent pas souhaité d’avoir autant d’entrées pour les
noms sans site. Pour éviter cette limite, vous pouvez créer une valeur de Registre « DnsAvoidRegisterRecords »
sur les contrôleurs de domaine qui ne doivent pas être présents dans les noms sans site.
DFS Volume management in version 1 namespaces attribute PKT
Les espaces de noms DFS version 1 utilisent un seul objet AD par espace de noms, et toutes les informations de
lien DFS sont conservées dans un attribut unique « PKT ». Il existe des problèmes de gestion de l’espace de noms
lorsque cet objet blob dépasse 5 Mo (environ 5 000 liens).
Pour plus d’informations, voir Fonctionnement de DFS.
Dans Windows Server 2008, DFS introduit des espaces de noms de version 2 où chaque lien DFS est un objet
AD distinct.
Erreur de réplication Active Directory 8451 : «
L’opération de réplication a rencontré une erreur de
base de données »
Cet article fournit une résolution de l’erreur de réplication Active Directory 8451 : « L’opération de réplication a
rencontré une erreur de base de données ».
NOTE
Famille d’utilisateurs : cet article est destiné uniquement aux agents de support technique et aux professionnels de
l’informatique. Si vous recherchez de l’aide pour résoudre un problème, demandez au Community Microsoft.
Symptômes
Cet article décrit les symptômes et les causes des situations dans lesquelles les opérations des services de
domaine Active Directory (AD DS) échouent et génèrent l’erreur 8451 : « L’opération de réplication a rencontré
une erreur de base de données ». Cet article fournit également une solution à ce problème.
Vous pouvez être l’un des symptômes suivants :
Un ou plusieurs messages d’erreur à l’écran, événements journalisé ou sortie de diagnostic identifient
une erreur de base de données. Les formats possibles pour cette erreur sont les suivants.
C O DE DÉC IM A L C O DE H EXA DÉC IM A L C O DE T EXT E M ESSA GE D’ERREUR
8451 0x2103 ERROR_DS_DRA_DB_ERR L’opération de réplication

OR a rencontré une erreur de
base de données.
-1018 0xfffffc06 JET_errReadVerifyFailure Erreur checksum sur une

page de base de données.
-1047 0xfffffbe9 JET_errInvalidBufferSize La mémoire tampon de

données ne correspond
pas à la taille des
colonnes.
-1075 0xfffffbc JET_errOutOfLongValueID Le compteur d’ID à valeur

longue a atteint la valeur
maximale (faire une
défragmentation hors
connexion pour récupérer
les données LongValueID
gratuites et inutilisées).
C O DE DÉC IM A L C O DE H EXA DÉC IM A L C O DE T EXT E M ESSA GE D’ERREUR
-1206 0xfffffb4a JET_errDatabaseCorrupte Fichier non base de

d données ou base de
données endommagée.
-1414 0xfffffa7a JET_errSecondaryIndexCor L’index secondaire est

rupted endommagé. La base de
données doit être
défragmentée.
-1526 0xfffffa0a JET_errLVCorrupted Corruption rencontrée

dans l’arborescence à
valeurs longues.
-1601 0xfffff9bf JET_errRecordNotFound La clé est in trouvée.
-1603 0xfffff9b JET_errNoCurrentRecord Devise non sur un

enregistrement.
Dcpromo.exe échoue et génère l’erreur 8451.

L’interface utilisateur affiche le message suivant :
L’opération a échoué car :

Les services de domaine Active Directory n’ont pas pu répliquer la partition <DN path of failing
partition> d’annuaire à partir du contrôleur de domaine Active Directory <helper DC>distant.<dns
domain name><top level domain>
L’opération de réplication a rencontré une erreur de base de données.
Le fichier Dcpromo.log contient les informations suivantes :
<date><time> [INFO] NstdInstall pour contoso.com renvoyé 8451

<date><time> [INFO] DsRolepInstallDs renvoyé 8451
<date><time> [ERREUR] Échec de l’installation dans le service d’annuaire (8451)
<date><time> [INFO] Démarrage du service NETLOGON
Repadmin.exe signale que la tentative de réplication a échoué avec l’état 8451. Repadmin.exe commandes
qui mentionnent généralement l’état 8451 incluent, sans s’y limiter, les suivantes :
Repadmin /kcc
Repadmin /rehost
Repadmin /replicate
Repadmin /replsum
Repadmin /showrepl
Repadmin /showreps
Repadmin /showutdvec
Repadmin /syncall
Pour plus d’informations sur l’utilisation de Repadmin pour résoudre les problèmes de réplication,
voir Monitoring and Troubleshooting Active Directory Replication Using Repadmin.
repadmin /showreps L’exemple suivant montre la sortie de la commande qui indique que la
réplication entrante de CONTOSO-DC2 vers CONTOSO-DC1 a échoué et généré le message «
L’accès à la réplication a été refusé ».
Default-First-Site-Name\CONTOSO-DC1
Options DSA : IS_GC
GUID d’objet DSA : b6dc8589-7e00-4a5d-b688-045aef63ec01
DSA invocationID: b6dc8589-7e00-4a5d-b688-045aef63ec01
DC=contoso,DC=com
Default-First-Site-Name\CONTOSO-DC2 via RPC
GUID d’objet DSA : 74fbe06c-932c-46b5-831b-af9e31f496b2
Last attempt @ <date> <time> failed, result 8451 (0x2103) :
échecs consécutifs.
L’Observateur d’événements répertorie un ou plusieurs événements qui mentionnent l’erreur 8451. Le

tableau suivant répertorie les sources d’événements et les ID d’événements courants qui mentionnent
l’erreur 8451 (dans l’ordre source de l’événement + ID d’événement).
SO URC E DE L’ÉVÉN EM EN T ID D’ÉVÉN EM EN T M ESSA GE D’ÉVÉN EM EN T
Microsoft-Windows- 1039 avec erreur étendue 8451 Événement interne : les services de
ActiveDirectory_DomainService domaine Active Directory n’ont pas
pu traiter l’objet suivant.
Microsoft-Windows- 1084 avec erreur étendue 8451 Événement interne : Active

ActiveDirectory_DomainService Directory n’a pas pu mettre à jour
l’objet suivant avec les modifications
reçues du contrôleur de domaine
source suivant. Cela est dû au fait
qu’une erreur s’est produite lors de
l’application des modifications
apportées à Active Directory sur le
Microsoft-Windows- 1308 avec erreur étendue 8451 Le contrôle de cohérence des

ActiveDirectory_DomainService connaissances (KCC) a détecté
l’échec d’une tentative successive de
suivant.
Microsoft-Windows- 1699 avec erreur étendue 8451 Le contrôleur de domaine local n’a
ActiveDirectory_DomainService pas pu récupérer les modifications
demandées pour la partition
d’annuaire suivante. Par conséquent,
il n’a pas pu envoyer les demandes
de modification au contrôleur de
domaine à l’adresse réseau suivante.
Réplication NTDS 2108 avec erreur étendue 8451 Cet événement contient DES
avec une valeur d’erreur secondaire PROCÉDURES DE RÉPARATION pour
-1075 l’événement 1084 précédemment
enregistré. Ce message indique un
problème spécifique avec la
cohérence de la base de données
Active Directory sur cette
destination de réplication. Une
erreur de base de données s’est
produite lors de l’application de
modifications répliquées à l’objet
suivant. La base de données avait
un contenu inattendu, ce qui
empêchait la modification d’être
réalisée. Objet : CN=
justintu@contoso.com
,OU=marketing,OU=5thWard,OU=
Général,DC=Contoso,DC=com
Object GUID: 2843919c-345c-4f57-
bc1a-4ed5acbcf9e2 Source domain
controller: 173ee10f-4c28-4acd-
a2d7-61af8d4d3010._msdcs.
Contoso.com action de l’utilisateur
Si aucune de ces actions ne réussit
et que l’erreur de réplication se
poursuit, vous devez rétrograder ce
contrôleur de domaine et le
promouvoir à nouveau. Valeur
d’erreur principale de données
supplémentaire : 8451 L’opération
de réplication a rencontré une
erreur de base de données. Valeur
d’erreur secondaire : -1075
NTDS General 1039 avec erreur étendue 8451. Événement interne : Active
Directory n’a pas pu traiter l’objet
suivant.
NTDS KCC 1925 avec erreur étendue 8451 La tentative d’établissement d’un
lien de réplication pour la partition
de répertoire accessible en texte
suivante a échoué.
Réplication NTDS 1084 avec erreur étendue 8451 Événement interne : Active
Directory n’a pas pu mettre à jour
Réplication NTDS 1699 avec erreur étendue 8451 Le contrôleur de domaine local n’a
pas pu récupérer les modifications
Lorsque vous augmentez le niveau de journalisation de diagnostic NTDS sur le contrôleur de domaine,
l’Observateur d’événements répertorie les événements supplémentaires liés à l’erreur 8451. Le tableau
suivant répertorie les sources d’événements et les ID d’événements qui accompagnent fréquemment
d’autres événements contenant l’erreur 8451.
Traitement interne 1481 avec erreur-1601 Erreur interne : l’opération sur l’objet
a échoué. Données supplémentaires
: Valeur d’erreur : 2 000020EF :
NameErr : DSID-032500E8,
problème 2001 (NO_OBJECT),
données -1601, meilleure
correspondance de :
Traitement interne 1173 avec erreur-1075 Événement interne : Active

Directory a rencontré l’exception
suivante et les paramètres associés.
Exception : paramètre e0010004 : 0
valeur d’erreur de données
supplémentaire : -1075 ID interne :
205086d

205036b

2050344
NTDS ISAM 474 avec erreur-1018 La page de base de données lue à

partir du fichier «
E:\NTDS\Data\ntds.dit » au décalage
3846455296
(0x00000000e5444000) pour 8 192
octets (0x00002000) n’a pas été
vérifiée en raison d’une
insérialisation de la sommes de
contrôle de page. La valeur de la
323677604 (0x134aeda4) et la
valeur réelle de la 2081515684
(0x7c1168a4). L’opération de lecture
échoue avec l’erreur -1018
(0xfffffc06). Si cette condition
persiste, restituer la base de
données à partir d’une sauvegarde
précédente. Ce problème est
probablement dû à un matériel
défectueux. Contactez votre
fournisseur de matériel pour obtenir
de l’aide supplémentaire pour
diagnostiquer le problème.
NTDS ISAM 488 NTDS (396) NTDSA : incohérence de

données détectée dans la table de
données de la base de données
C:\WINDOWS\NTDS\ntds.dit (4621
7905).
Lorsque vous exécutez l’utilitaire Dcdiag.exe, il produit une sortie qui ressemble à :

* Vérification des réplications
[Vérification des réplications,<DC Name>] Une tentative de réplication récente a échoué :
Contexte d’attribution de noms : <DN path of failing naming context>
L’opération de réplication a rencontré une erreur de base de données
Dans sites et services Active Directory, lorsque vous cliquez avec le bouton droit sur l’objet de connexion
d’un dc source et sélectionnez Répliquer maintenant, la commande échoue et génère un message
ressemblant à :
L’erreur suivante s’est produite lors de la tentative de synchronisation du contexte d’attribution de

noms <%nom de partition d’annuaire%> <Source DC> du contrôleur de domaine au contrôleur de
domaine <Destination DC>:
« L’opération de réplication a rencontré une erreur de base de données. »
L’opération ne se poursuit pas.
Décoder les codes d’erreur

Vous pouvez utiliser Microsoft Exchange Server recherche de code d’erreur pour décoder les codes d’erreur
décrits dans cet article. Le décodage des codes d’erreur liés à l’erreur 8451 et les erreurs qui l’accompagnent
produit les informations suivantes :
C:>err 8451
pour les décimales 8451 /hexadécimales 0x2103 :
ERROR_DS_DRA_DB_ERROR winerror.h
2 correspondances trouvées pour « 8451 »
C:>err -1414
pour décimal -1414 / hexadécimal 0xfffffa7a :
JET_errSecondaryIndexCorrupted esent98.h
/L’index secondaire est endommagé. La base de données doit être défragmentée/
1 correspondances trouvées pour « -1414 »
C:>err -1526
pour les décimales -1526 /hexadécimales 0xfffffa0a :
JET_errLVCorrupted esent98.h
/Corruption rencontrée dans l’arborescence à valeurs longues/
C:>err -1603
pour décimal -1603 / hexadécimal 0xfffff9bd :
JET_errNoCurrentRecord esent98.h
/Devise non sur un enregistrement/
C:>err -1075
pour décimal -1075 /hexadécimal 0xfffffbcd :
JET_errOutOfLongValueIDs esent98.h
/Le compteur d’ID à valeur longue a atteint la valeur maximale. (effectuer une défragmentation hors
connexion pour récupérer les données LongValueID gratuites/inutilisées)/
C:>err -1601
pour décimal -1601 /hexadécimal 0xfffff9bf :
JET_errRecordNotFound esent98.h
/La clé est in trouvée/
C:>err -1047
pour les décimales -1047 /hexadécimales 0xfffffbe9 :
JET_errInvalidBufferSize esent98.h
/La mémoire tampon de données ne correspond pas à la taille de colonne/
C:>err -1018
pour les décimales -1018 /hexadécimales 0xfffffc06 :
JET_errReadVerifyFailure ese.h
/Erreur checksum sur une page de base de données/
JET_errReadVerifyFailure esent98.h
/* Erreur checksum sur une page de base de données */
C:>err -1206
pour décimal -1206 /hexadécimal 0xfffffb4a :
JET_errDatabaseCorrupted esent98.h
/Fichier non base de données ou base de données endommagée/
Cause
L’état 8451 : « L’opération de réplication a rencontré une erreur de base de données » a plusieurs causes
premières, notamment les suivantes :
La base de données Active Directory ou l’index de base de données Active Directory peut être endommagé.
Elle peut être causée par les raisons suivantes :
Matériel défaillant :
Disque
Contrôleur
Cache du contrôleur
Pilotes obsolètes :
Contrôleur
Microprogramme obsolète :
BIOS ordinateur
Contrôleur
Disque
Perte d’alimentation soudaine.
Objets en attente.
Le compteur d’ID à valeur longue a atteint sa valeur maximale :
Les types de colonne ESE et JET_coltypLongText sont JET_coltypLongBinary appelés types de
colonne de valeur longue. Ces colonnes sont des chaînes de grande taille et des objets binaires
de grande taille qui peuvent être stockés dans des arbre B+ distincts de l’index principal.
Lorsque les valeurs longues sont stockées séparément de l’enregistrement principal, elles sont
à clé interne sur un ID de valeur longue (LID).
Descripteur de sécurité non valide dans l’attribut msExchSecurityDescriptor .
Résolution
IMPORTANT
Comment résoudre une occurrence unique du problème

Si l’erreur se produit sur un seul contrôleur de domaine et semble être un problème isolé, la meilleure et la
résolution la plus rapide consiste à défragmenter la base de données sur le serveur concerné. Pour plus
d’informations sur la façon de le faire, voir Comment effectuer la défragmentation hors connexion de la base de
données Active Directory.
Si la défragmentation hors connexion ne corrige pas le problème, rétrograder, puis réentribuer le contrôleur de
domaine affecté. Pour plus d’informations sur la façon de le faire, voir Rétrogradation des contrôleurs de
domaine et des domaines.
Comment résoudre un problème récurrent
Si le problème se reproduit, collectez des données de diagnostic.
1. Activez la journalisation des diagnostics NTDS pour les événements de réplication et le traitement interne
à un niveau de 5.
Pour augmenter la journalisation des diagnostics NTDS, modifiez les valeurs REG_DWORD suivantes
dans le Registre du contrôleur de domaine de destination sous la sous-clé de Registre suivante :
Définissez la valeur des entrées suivantes sur 5 :

Événements de réplication
Traitement interne
NOTE
La journalisation de niveau 5 est extrêmement détaillée. Les valeurs des deux clés doivent être restaurées à la
valeur par défaut de 0 une fois le problème résolu. Le filtrage du journal des événements des services d’annuaire
doit être effectué pour isoler et identifier ces événements.
Pour plus d’informations sur la terminologie standard utilisée pour décrire les mises à jour logicielles
Microsoft, consultez l’article suivant de la Base de connaissances :
2. Examinez les journaux des événements pour les nouveaux événements qui ont été générés à partir de la
journalisation accrue pour les valeurs d’erreur qui donnent une vue définitive de l’erreur 8451 d’origine.
Par exemple, un ID d’événement de traitement interne 1173 dont la valeur d’erreur est -1526 indiquerait
que l’arborescence à valeurs longues est corrompue.
3. En fonction des informations supplémentaires de l’augmentation de la journalisation, reportez-vous au
tableau suivant pour obtenir une résolution potentielle.
RÉSO L UT IO N S
C O DE DÉC IM A L C O DE H EX C O DE T EXT E M ESSA GE D’ERREUR P OT EN T IEL L ES
-1018 0xfffffc06 JET_errReadVerifyFai Erreur checksum Vérifiez le matériel,

lure sur une page de les
base de données microprogrammes
et les pilotes.
Restauration à
partir d’une
sauvegarde.
Rétrograder/promo
uvoir.
-1047 0xfffffbe9 JET_errInvalidBuffer La mémoire 832851 réplication

Size tampon de données entrante échoue sur
ne correspond pas les contrôleurs de
à la taille de domaine avec l’ID
colonne d’événement :
1699, erreur 8451
ou erreur de jet -
1601 Remarque :
ce correctif n’est
plus disponible.
RÉSO L UT IO N S
-1075 0xfffffbcd JET_errOutOfLongV Le compteur d’ID à Défragmentation

alueIDs valeur longue a hors connexion.
atteint la valeur
maximale.
(défragmentation
hors connexion
pour récupérer les
données gratuites
ou inutilisées
LongValueIDs )
-1206 0xfffffb4a JET_errDatabaseCor Fichier non-base de Vérifiez le matériel,

rupted données ou base de les
données microprogrammes
endommagée et les pilotes.
Exécutez la
commande
Esentutl/k .
Exécutez les
commandes
d’analyse de base
de données
sémantique et
d’intégrité des
fichiers Ntdsutil ,
puis
défragmentation
hors connexion.
Sinon, restituer à
partir d’une
sauvegarde ou
rétrograder/promo
uvoir.
-1414 0xfffffa7a JET_errSecondaryIn L’index secondaire Défragmentation

dexCorrupted est endommagé. La hors connexion.
base de données
doit être
défragmentée.
-1526 0xfffffa0a JET_errLVCorrupted Corruption Vérifiez le matériel,

rencontrée dans les
l’arborescence à microprogrammes
valeurs longues et les pilotes.
Exécutez la
Esentutl /k
commande.
Exécutez les
commandes
Ntdsutil** file
integrity et SDA,
puis la
défragmentation
hors connexion.
Sinon, restituer à
partir d’une
sauvegarde ou
rétrograder et
promouvoir.
RÉSO L UT IO N S
-1601 0xfffff9bf JET_errRecordNotFo La clé est in trouvée Vérifiez le matériel,

und les
microprogrammes
et les pilotes.
Exécutez la
Esentutl /k
commande.
Exécutez les
commandes
Ntdsutil File
Integrity et SDA,
puis la
défragmentation
hors connexion.
Sinon, restituer à
partir d’une
sauvegarde ou
rétrograder et
promouvoir.
-1603 0xfffff9bd JET_errNoCurrentRe Devise non sur un Vérifiez le matériel,

cord enregistrement les
microprogrammes
et les pilotes.
Exécutez la
Esentutl /
commande k.
Exécutez les
commandes
Ntdsutil File
Integrity et SDA,
puis la
défragmentation
hors connexion.
Sinon, restituer à
partir d’une
sauvegarde ou
rétrograder et
promouvoir.
8451 0x2103 ERROR_DS_DRA_DB L’opération de Vérifiez le matériel,

_ERROR réplication a les
rencontré une microprogrammes
erreur de base de et les pilotes.
données Exécutez la
Esentutl /k
commande.
Exécutez les
commandes
Ntdsutil File
Integrity et SDA,
puis la
défragmentation
hors connexion.
Sinon, restituer à
partir d’une
sauvegarde ou
rétrograder/promo
uvoir.
4. Si toutes ces méthodes échouent, restituons le contrôleur de domaine à partir d’une sauvegarde, ou
rétrograder, puis reomote.
Vérifiez la pile de base de données à jet verticale à partir du bas vers le haut (en haut jusqu’à la couche suivante
uniquement une fois que la couche sous-jacente a été noté comme étant « bonne ») comme vous le faites pour
TCP.
C O UC H E C O M M A N DE N T DSUT IL C O M M A N DE ESEN T UT L
(1) Cohérence physique pas d’équivalent Esentutl /k
(2) Cohérence logique extensible Ntdsutil, fichiers , intégrité Esentutl /g

Stockage Engine (ESE)
(3) Cohérence logique de l’application Ntdsutil, sémantique database aucun équivalent pour SDA +
analysisNtdsutil + , compact Esentutl /d
ou 1988 : un objet en attente est détecté
Cet article vous aide à résoudre les problèmes d’ID d’événement de réplication Active Directory 1388 et 1988.
Résumé
Si un contrôleur de domaine de destination enregistre l’ID d’événement 1388 ou l’ID d’événement 1988, un
objet en attente a été détecté et l’une des deux conditions existe sur le contrôleur de domaine de destination :
ID d’événement 1388 : la réplication entrante de l’objet en attente s’est produite sur le contrôleur de domaine
de destination.
ID d’événement 1988 : la réplication entrante de la partition d’annuaire de l’objet en attente a été bloquée sur
le contrôleur de domaine de destination.
Cet événement indique qu’un contrôleur de domaine de destination dont la cohérence de réplication n’est pas
strictement activée a reçu une demande de mise à jour d’un objet qui ne réside pas dans la copie locale de la
base de données Active Directory. En réponse, le contrôleur de domaine de destination a demandé l’objet
complet au partenaire de réplication source. De cette façon, un objet en attente a été répliqué sur le contrôleur
de domaine de destination. Par conséquent, l’objet en attente a été réintroduit dans le répertoire.
IMPORTANT
Lorsque l’ID d’événement 1388 se produit, si le contrôleur de domaine source (le partenaire de réplication sortant
réplication de l’objet en attente) ou le contrôleur de domaine de destination (le partenaire de réplication entrant qui
signale l’ID d’événement 1388) exécute Windows 2000 Server, vous ne pouvez pas utiliser l’outil Repadmin pour
supprimer les objets en attente. Pour plus d’informations sur la suppression d’objets en attente dans ce cas, consultez
l’exemple d’objets en attente qui peuvent rester après la mise en ligne d’un serveur de catalogue global hors date. Les
procédures et les informations de cet article s’appliquent à la suppression des objets en attente des serveurs de catalogue
global ainsi que des contrôleurs de domaine qui ne sont pas des serveurs de catalogue global.
Le texte de l’événement identifie le contrôleur de domaine source et l’objet obsolète (en attente). Voici un
exemple du texte de l’événement :
Nom du journal : service d’annuaire

Source : Microsoft-Windows-ActiveDirectory_DomainService
Date : 03/05/2008 15:34:01
Niveau : Error
Ordinateur : DC3.contoso.com Description : un autre contrôleur de domaine (DC) a tenté de répliquer dans ce
dc un objet qui n’est pas présent dans la base de données locale des services de domaine Active Directory.
L’objet a peut-être été supprimé et déjà la garbage collected (une durée de vie de tombstone ou plus a été
passée depuis la suppression de l’objet) sur ce DC. Le jeu d’attributs inclus dans la demande de mise à jour
n’est pas suffisant pour créer l’objet. L’objet est re-demandé avec un jeu d’attributs complet et re-créé sur ce
dc.
Source DC (adresse réseau spécifique au transport) :
4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com
Objet :
CN=InternalApps,CN=Users,DC=contoso,DC=com
GUID d’objet : a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a
DC=contoso,DC=com
Destination highest property USN: 20510
Vérifiez le souhait continu d’existence de cet objet. Pour arrêter la re-création d’objets similaires futurs, la clé
de Registre suivante doit être créée.
Clé de Registre :
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency
Cet événement indique qu’un contrôleur de domaine de destination dont la cohérence de réplication est
strictement activée a reçu une demande de mise à jour d’un objet qui n’existe pas dans sa copie locale de la base
de données Active Directory. En réponse, le contrôleur de domaine de destination a bloqué la réplication de la
partition d’annuaire contenant cet objet à partir de ce contrôleur de domaine source. Le texte de l’événement
identifie le contrôleur de domaine source et l’objet obsolète (en attente). Voici un exemple du texte de
l’événement :

Date : 07/02/2008 8:20:11 ID d’événement : 1988
Niveau : Error
Ordinateur : DC5.contoso.com
Description :
La réplication des services de domaine Active Directory a rencontré l’existence d’objets dans la partition
suivante qui ont été supprimés de la base de données des services de domaine Active Directory des
contrôleurs de domaine locaux. Tous les partenaires de réplication directe ou transitive n’ont pas été
répliqués dans la suppression avant le nombre de jours écoulés sur la durée de vie de tombstone. Les objets
qui ont été supprimés et la garbage collected from an Active Directory Domain Services partition but still
exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog
servers in other domains in the forest are known as « leted objects ».
Cet événement est journalisé car la source DC contient un objet en attente qui n’existe pas dans la base de
données des services de domaine Active Directory des DCS locaux. Cette tentative de réplication a été
bloquée.
La meilleure solution à ce problème consiste à identifier et supprimer tous les objets en attente dans la forêt.
Source DC (adresse réseau spécifique au transport) :
4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com
Objet : CN=InternalApps,CN=Users,DC=contoso,DC=com
GUID d’objet :
a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a
Diagnostic
Un objet qui a été définitivement supprimé des AD DS (autrement dit, sa valeur tombstone a été récupérée sur
tous les contrôleurs de domaine connectés) reste sur un contrôleur de domaine déconnecté. Le contrôleur de
domaine n’a pas réussi à recevoir la réplication directe ou transitive de la suppression d’objet car il a été
déconnecté (hors connexion ou en cas d’échec de réplication entrante) de la topologie de réplication pour une
période qui a dépassé une durée de vie de tombstone. Le contrôleur de domaine est maintenant reconnecté à la
topologie et cet objet a été mis à jour sur le contrôleur de domaine, ce qui entraîne une notification de
réplication au partenaire de réplication qu’une mise à jour est prête pour la réplication. Le partenaire de
réplication a répondu en fonction de son paramètre de cohérence de réplication. Cette notification s’applique
aux tentatives de réplication d’un objet accessible en writable. Une copie de l’objet en attente accessible en ligne
peut également exister sur un serveur de catalogue global.
Résolution
Si la réplication d’un objet en attente est détectée, vous pouvez supprimer l’objet d’AD DS, ainsi que les réplicas
en lecture seule de l’objet, en identifiant les contrôleurs de domaine qui peuvent stocker cet objet (y compris les
serveurs de catalogue global) et en exécutant une commande de repadmin pour supprimer les objets en attente
sur ces serveurs ( repadmin /removelingeringobjects ). Cette commande est disponible sur les contrôleurs de
domaine qui exécutent Windows Server 2008. Il est également disponible sur les contrôleurs de domaine qui
n’exécutent pas Windows Server 2008, mais qui exécutent la version de Repadmin.exe incluse avec les outils de
support Windows dans Windows Server 2003.
Pour supprimer les objets en attente, faites les choses suivantes :
1. Utilisez le texte de l’événement pour identifier les événements suivants :
a. Partition d’annuaire de l’objet
b. Contrôleur de domaine source qui a tenté la réplication de l’objet en attente
2. Utilisez Repadmin pour identifier le GUID d’un contrôleur de domaine faisant autorité.
3. Utilisez repadmin pour supprimer les objets en attente.
4. Activez une cohérence de réplication stricte, si nécessaire.
5. Assurez-vous que la cohérence de réplication stricte est activée pour les contrôleurs de domaine
nouvellement promus, si nécessaire.
Utiliser Repadmin pour identifier le GUID d’un contrôleur de domaine faisant autorité
Pour effectuer la procédure qui supprime les objets en attente, vous devez identifier l’identificateur global
unique (GUID) d’un contrôleur de domaine à jour qui possède un réplica accessible en ligne de la partition
d’annuaire qui contient l’objet en attente qui a été signalé. La partition d’annuaire est identifiée dans le message
d’événement. Le GUID d’objet d’un contrôleur de domaine est stocké dans l’attribut objectGUID de l’objet
Paramètres NTDS.
Conditions préalables :
Pour effectuer cette procédure, vous devez au minimum être membre des administrateurs de domaine
dans le domaine du contrôleur de domaine dont vous souhaitez identifier le GUID. Examinez les détails sur
l’utilisation des comptes appropriés et des appartenances aux groupes aux groupes locaux et par défaut de
domaine.
Outil : Repadmin.exe
Étapes pour identifier le GUID d’un contrôleur de domaine
1. À l’invite de commandes, tapez la commande suivante et appuyez sur Entrée :
repadmin /showrepl <ServerName>
PA RA M ÈT RE DESC RIP T IO N
/showrepl Affiche l’état de réplication, <ServerName> y compris le

moment où le contrôleur de domaine spécifié par la
dernière tentative de réplication entrante des partitions
Active Directory. Affiche également le GUID du
contrôleur de domaine spécifié.
<ServerName> Nom du contrôleur de domaine dont vous souhaitez

afficher le GUID.
2. Dans la première section de la sortie, recherchez l’entrée objectGuid . Sélectionnez et copiez la valeur
GUID dans un fichier texte afin de pouvoir l’utiliser ailleurs.
Utiliser repadmin pour supprimer les objets en attente
Si le contrôleur de domaine de destination et le contrôleur de domaine source exécutent Windows Server 2003
ou Windows Server 2008, vous pouvez utiliser cette procédure pour supprimer les objets en attente avec
Repadmin. Si l’un des contrôleurs de domaine exécute Windows Server 2000, suivez les instructions de
l’exemple Objets en attente après la mise en ligne d’un serveur de catalogue global non à jour.
L’appartenance aux administrateurs de domaine dans le domaine du contrôleur de domaine qui possède
des objets en attente, ou administrateurs Enterprise si la partition d’annuaire qui possède des objets en
attente est la partition de répertoire de configuration ou de schéma, est la configuration ou la partition de
répertoire de schéma requise pour effectuer cette procédure. Examinez les détails sur l’utilisation des
comptes appropriés et des appartenances aux groupes aux groupes locaux et par défaut de domaine.
Système d’exploitation : Windows Server 2003 ou Windows Server 2008 pour <ServerName>
et<ServerGUID>
Outil : Repadmin.exe
Étapes d’utilisation du repadmin pour supprimer les objets en attente
1. Ouvrez une invite de commandes en tant qu’administrateur : dans le menu Démarrer , cliquez avec le
bouton droit sur Invite de commandes, puis cliquez sur Exécuter en tant qu’administrateur . Si la
boîte de dialogue Contrôle de compte d’utilisateur s’affiche, fournissez les informations
d’identification Administrateurs Enterprise domaine, si nécessaire, puis cliquez sur Continuer .
2. À l'invite de commandes, tapez la commande suivante, puis appuyez sur Entrée :
repadmin /removelingeringobjects <ServerName> <ServerGUID> <DirectoryPartition> /advisory_mode
/removelingeringobjects Supprime les objets en attente <ServerName> du

contrôleur de domaine spécifié par pour la partition
d’annuaire spécifiée par <DirectoryPartition>.
<ServerName> Nom du contrôleur de domaine qui possède des objets

en attente, comme identifié dans le message
d’événement (ID d’événement 1388 ou ID d’événement
1988). Vous pouvez utiliser le nom DNS (Domain Name
System) ou le nom distinguished, par exemple, le nom
distinguished CN=DC5,OU=Domain
Controllers,DC=contoso,DC=com ou le nom DNS
DC5.contoso.com .
<ServerGUID> GUID d’un contrôleur de domaine qui possède un réplica

à jour accessible en ligne de la partition d’annuaire qui
contient l’objet en attente.
<DirectoryPartition> Nom unique de la partition d’annuaire identifiée dans le

message d’événement, par exemple :
Pour la partition d’annuaire de domaine Sales
dans la contoso.com forêt :
DC=sales,DC=contoso,DC=com
Pour la partition du répertoire de configuration
dans la contoso.com forêt :
CN=configuration,DC=contoso,DC=com
Pour la partition contoso.com de répertoire de
schéma dans la forêt :
CN=schema,CN=configuration,DC=contoso,DC=
com
/advisory_mode Enregistre les objets en attente qui seront supprimés afin

que vous pouvez les examiner, mais pas les supprimer.
3. Répétez l’étape 2 sans /advisory_mode supprimer les objets en attente identifiés de la partition
d’annuaire.
4. Répétez les étapes 2 et 3 pour chaque contrôleur de domaine qui peut avoir des objets en attente.
NOTE
Le <ServerName> paramètre utilise la syntaxe DC_LIST pour le repadmin, qui permet l’utilisation de * pour tous les
contrôleurs de domaine dans la forêt et gc: pour tous les serveurs de catalogue global dans la forêt. Pour voir la syntaxe
DC_LIST, tapez repadmin /listhelp . Pour plus d’informations sur la syntaxe des paramètres /regkey
/removelingeringobjects et des paramètres, tapez repadmin /experthelp .
Activer une cohérence de réplication stricte

Pour vous assurer que les objets en attente ne peuvent pas être répliqués s’ils se produisent, activez une
cohérence de réplication stricte sur tous les contrôleurs de domaine. Le paramètre de cohérence de réplication
est stocké dans le Registre sur chaque contrôleur de domaine. Toutefois, sur les contrôleurs de domaine
exécutant Windows Server 2003 avec Service Pack 1 (SP1), Windows Server 2003 avec Service Pack 2 (SP2),
Windows Server 2003 R2 ou Windows Server 2008, vous pouvez utiliser Repadmin pour assurer une cohérence
de réplication stricte sur un ou tous les contrôleurs de domaine.
Sur les contrôleurs de domaine exécutant Windows Server 2003 sans SP1 ou exécutant une version de
Windows 2000 Server, vous devez modifier le Registre pour activer le paramètre.
Utiliser repadmin pour assurer une cohérence de réplication stricte
Utilisez cette procédure pour supprimer les objets en attente sur un contrôleur de domaine qui exécute
Windows Server 2003 avec SP1, Windows Server 2003 avec SP2, Windows Server 2003 R2 ou Windows Server
2008.
Pour effectuer cette procédure sur un seul contrôleur de domaine, il faut au minimum être membre
d’administrateurs de domaine ou d’administrateurs de domaine équivalent. Pour effectuer cette procédure
sur tous les contrôleurs de domaine de la forêt, il faut au minimum être membre Enterprise administrateurs
de domaine, ou un administrateur équivalent. Examinez les détails sur l’utilisation des comptes appropriés et
des appartenances aux groupes aux groupes locaux et par défaut de domaine.
Ét a p e s d ’ u t i l i sa t i o n d u r e p a d m i n p o u r a ssu r e r u n e c o h é r e n c e d e r é p l i c a t i o n st r i c t e
boîte de dialogue Contrôle de compte d’utilisateur s’affiche, fournissez les informations
d’identification Administrateurs Enterprise domaine, si nécessaire, puis cliquez sur Continuer .
repadmin /regkey <DC_LIST> +strict
/regkey Active (+) et désactive (-) la valeur de l’entrée de Registre

Cohérence de la réplication stricte dans .
<DC_LIST> Nom d’un contrôleur de domaine unique, ou * pour

appliquer la modification à tous les contrôleurs de
domaine dans la forêt. Pour le nom du contrôleur de
domaine, vous pouvez utiliser le nom DNS, le nom de
l’objet ordinateur du contrôleur de domaine ou le nom
de l’objet serveur du contrôleur de domaine, par
exemple, le nom distinguished name
CN=DC5,OU=Domain Controllers,DC=contoso,DC=com
ou le nom DNS DC5.contoso.com .
+strict Active l’entrée de Registre Cohérence de réplication

stricte.
3. Si vous n’utilisez pas * pour appliquer la modification à tous les contrôleurs de domaine, répétez l’étape 2
pour chaque contrôleur de domaine sur lequel vous souhaitez activer une cohérence de réplication
stricte.
NOTE
Pour plus d’options d’attribution de noms et d’informations sur la syntaxe du paramètre <DC_LIST>, à l’invite de
commandes. repadmin /listhelp Pour plus d’informations sur la syntaxe des paramètres /regkey
/removelingeringobjects et des paramètres, tapez repadmin /experthelp .
Utiliser Regedit pour assurer une cohérence de réplication stricte

Comme alternative à l’utilisation de Repadmin, vous pouvez activer une cohérence de réplication stricte en
éditant directement le Registre. La méthode de Registre est requise pour un contrôleur de domaine qui exécute
une version de Windows Server antérieure à Windows Server 2003 avec SP1. Le paramètre de cohérence de
réplication est stocké dans l’entrée Cohérence de réplication stricte dans
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters .
Les valeurs de l’entrée de Registre Strict Replication Consistency sont les suivantes :
Valeur : 1 (0 pour désactiver)
Valeur par défaut : 1 (activé) dans une nouvelle forêt Windows Server 2003 ou Windows Server 2008 ; sinon
0.
Vous devez au moins être membre du groupe Admins du domaine (ou un groupe équivalent) pour
effectuer cette procédure. Examinez les détails sur l’utilisation des comptes appropriés et des appartenances
aux groupes aux groupes locaux et par défaut de domaine).
Outil : Regedit.exe
NOTE
Il est recommandé de ne pas modifier directement le Registre, sauf s’il n’existe aucune autre alternative. Les modifications
apportées au Registre ne sont pas validées par l’éditeur du Registre ou par Windows avant leur application et, par
conséquent, des valeurs incorrectes peuvent être stockées. Cela peut entraîner des erreurs irrécables dans le système.
Dans la mesure du possible, utilisez la stratégie de groupe ou d’autres outils Windows, tels que microsoft Management
Console (MMC), pour accomplir des tâches plutôt que de modifier directement le Registre. Si vous devez modifier le
Registre, faites preuve d’une prudence extrême.
Ét a p e s d ’ u t i l i sa t i o n d e R e g e d i t p o u r a ssu r e r u n e c o h é r e n c e d e r é p l i c a t i o n st r i c t e
1. Ouvrez Regedit en tant qu’administrateur : cliquez sur Démarrer , puis, dans Démarrer la recherche,
tapez regedit. En haut du menu Démarrer , cliquez avec le bouton regedit.exe , puis cliquez sur
Exécuter en tant qu’administrateur . Dans la boîte de dialogue Contrôle de compte
d’utilisateur , fournissez les informations d’identification Administrateurs du domaine, puis cliquez sur
OK .
2. Accédez à l’entrée Cohérence de réplication stricte dans
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters .
3. Définissez la valeur de l’entrée Cohérence de réplication stricte sur 1.
S’assurer que la cohérence de réplication stricte est activée pour les contrôleurs de domaine nouvellement
promus
Si vous mettre à niveau une forêt créée à l’origine à l’aide d’un ordinateur exécutant Windows Server 2000, vous
devez vous assurer que la forêt est configurée pour permettre une cohérence de réplication stricte sur les
contrôleurs de domaine nouvellement promus afin d’éviter les objets en attente. Après avoir mis à jour la forêt
comme décrit dans (Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008
R2 AD DS Domains), tous les nouveaux contrôleurs de domaine que vous ajoutez ultérieurement à la forêt sont
créés avec une cohérence de réplication stricte désactivée. Toutefois, vous pouvez implémenter une modification
de configuration de forêt qui entraîne l’application d’une cohérence de réplication stricte aux nouveaux
contrôleurs de domaine. Pour vous assurer que la cohérence de réplication est strictement activée pour les
nouveaux contrôleurs de domaine que vous ajoutez à la forêt, vous pouvez utiliser l’outil Ldifde.exe pour créer
un objet dans la partition du répertoire de configuration de la forêt. Cet objet est responsable de l’activation
d’une cohérence de réplication stricte sur tout contrôleur de domaine Windows Server 2003 ou Windows
Server 2008 promu dans la forêt.
L’objet que vous créez est un GUID opérationnel du nom suivant :
CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=
<ForestRootDomain>
Vous pouvez utiliser la procédure suivante sur n’importe quel contrôleur de domaine de la forêt pour ajouter cet
objet à la partition du répertoire de configuration.
Pour effectuer cette procédure, il faut au minimum Enterprise administrateurs administrateurs , ou un
compte équivalent. Examinez les détails sur l’utilisation des comptes appropriés et des appartenances aux
groupes aux groupes locaux et par défaut de domaine.
Étapes de création de l’objet qui garantit une cohérence de réplication stricte sur les nouveaux contrôleurs de domaine
1. Dans un éditeur de texte, tel que Bloc-notes, créez le fichier texte suivant :
dn:
CN=94fdebc6-8eeb-4640-80de-
ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<ForestRootDomain>
changetype: add
objectClass: container
showInAdvancedViewOnly : TRUE
name: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=<ForestRootDomain>
2. Où <ForestRootDomain> contient tous les composants de domaine (DC=) du domaine racine de la forêt,
par exemple, contoso.com pour la forêt, DC=contoso,DC=com ; fineartschool.net pour la forêt,
DC=fineartschool,DC=net.
boîte de dialogue Contrôle de compte d’utilisateur s’affiche, Enterprise informations d’identification
administrateurs, si nécessaire, puis cliquez sur Continuer .
ldifde -i -f <Path>\<FileName>
-i Spécifie le mode d’importation. Si le mode d’importation

n’est pas spécifié, le mode par défaut est l’exportation.
-f Identifie le nom du fichier d’importation ou

d’exportation.
<Path>\<FileName> Chemin d’accès et nom du fichier d’importation que vous

avez créé à l’étape 1, par exemple, C:\ldifde.txt.
Pour plus d’informations sur l’utilisation de Ldifde, voir LDIFDE.

: échec de la tentative d’établissement d’un lien de
réplication en raison d’un problème de recherche
DNS
Cet article permet de résoudre le problème où vous obtenez l’ID d’événement 1925 avec le message d’erreur
que la recherche DNS a échoué, la réplication entrante d’une partition d’annuaire a échoué sur le contrôleur de
Ce problème se produit généralement lorsqu’une tentative d’établissement d’un lien de réplication échoue suite
à un problème de recherche DNS (Domain Name System). Si vous recevez l’ID d’événement 1925 avec le
message d’erreur d’échec de la recherche DNS, la réplication entrante d’une partition d’annuaire a échoué sur le
contrôleur de domaine de destination et vous devez résoudre le problème DNS.
Voici un exemple du texte de l’événement :

Date : 12/03/2008 8:14:13
Catégorie de tâche : Vérification de la cohérence des connaissances
Description :
La tentative d’établissement d’un lien de réplication pour la partition d’annuaire accessible en texte suivante
a échoué.
CN=Configuration,DC=contoso,DC=com
Service d’annuaire source : CN=NTDS Paramètres,CN=DC1,CN=Servers,CN=Default-First-Site-Name,
CN=Sites,CN=Configuration,DC=contoso,DC=com
Adresse du contrôleur de domaine source :
f8786828-ecf5-4b7d-ad12-8ab60178f7cd._msdcs.contoso.com
Transport intersite (le cas contraire) : CN=IP,CN=Transports intersites,
CN=Sites,CN=Configuration,DC=constoso,DC=com
Ce contrôleur de domaine ne pourra pas répliquer avec le contrôleur de domaine source tant que ce
problème n’aura pas été résolu.
Action de l'utilisateur
Vérifiez si le contrôleur de domaine source est accessible ou si la connectivité réseau est disponible.
Valeur d’erreur :
8524 L’opération de la DSA ne peut pas continuer en raison d’un échec de recherche DNS.
Résolution
Procédez au test DNS comme décrit dans « ID d’événement de réplicationActive Directory 2087: l’échec de la
recherche DNS a provoqué l’échec de la réplication ».
ID d’événement de réplication Active Directory
2042 : cela fait trop de temps que cet ordinateur a
été répliqué
Cet article vous aide à résoudre les problèmes d’ID d’événement de réplication Active Directory 2042.
Symptômes
Si un contrôleur de domaine n’a pas été répliqué avec son partenaire pendant une durée de vie plus longue
qu’une durée de vie de tombstone, il est possible qu’il existe un problème d’objet en attente sur l’un des
contrôleurs de domaine ou les deux. La durée de vie de tombstone dans une forêt Active Directory détermine la
durée de rétention d’un objet supprimé (appelé « tombstone ») dans les services de domaine Active Directory
(AD DS). La durée de vie de tombstone est déterminée par la valeur de l’attribut tombstoneLifetime sur l’objet
Service d’annuaire dans la partition du répertoire de configuration.
Lorsque la condition qui entraîne le journal de l’ID d’événement 2042 se produit, la réplication entrante avec le
partenaire source est arrêtée sur le contrôleur de domaine de destination et l’ID d’événement 2042 est consigné
dans le journal des événements du service d’annuaire. L’événement identifie le contrôleur de domaine source et
les mesures appropriées à suivre pour supprimer le contrôleur de domaine obsolète ou supprimer les objets en
attente et restaurer la réplication du contrôleur de domaine source.

Date : <Time>
Niveau : Error
Ordinateur : <domain controller hostname>
Description :
Cela fait trop longtemps que cet ordinateur n’a pas été répliqué avec l’ordinateur source nommé. Le temps
entre les réplications avec cette source a dépassé la durée de vie de tombstone. La réplication a été arrêtée
avec cette source.
La raison pour laquelle la réplication n’est pas autorisée à se poursuivre est que les affichages des objets
supprimés par les deux ordinateurs peuvent maintenant être différents. L’ordinateur source peut encore
avoir des copies d’objets qui ont été supprimés (et la garbage collected) sur cet ordinateur. S’ils ont été
autorisés à répliquer, l’ordinateur source peut renvoyer des objets qui ont déjà été supprimés.
Heure de la dernière réplication réussie :
<date> <time>
ID d’appel de la source :
<Invocation ID>
Nom de la source :
<GUID>._msdcs.<domain>
Durée de vie de Tombstone ( jours) : <TSL number in days>
L’opération de réplication a échoué.
Déterminez lequel des deux ordinateurs a été déconnecté de la forêt et qui est maintenant hors de la date.
Vous avez trois options :
1. Rétrograder ou réinstaller les ordinateurs qui ont été déconnectés.
2. Utilisez l’outil « repadmin /removeletedobjects » pour supprimer les objets supprimés incohérents, puis
reprendre la réplication.
3. Reprendre la réplication. Des objets supprimés incohérents peuvent être introduits.
Vous pouvez continuer la réplication à l’aide de la clé de Registre suivante.
Une fois que les systèmes ont été répliqués une seule fois, il est recommandé de supprimer la clé pour
rétablir la protection.
Clé de Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and
Corrupt Partner
La repadmin /showrepl commande signale également l’erreur 8416, comme illustré dans l’exemple suivant :
Source : Default-First-Site-Name\DC1
******* <number> ÉCHECS CONSÉCUTIFS DEPUIS <date> <time>
Dernière erreur : 8614 (0x21a6) :
Les services de domaine Active Directory ne peuvent pas répliquer avec ce serveur, car le temps depuis la
dernière réplication avec ce serveur a dépassé la durée de vie de tombstone.
Cause
Il existe quelques causes potentielles pour la journalisation de l’ID d’événement 2042, notamment :
Windows server 2003 pre-Service Pack 1 (SP1) domain controllers having a software issue that causes
replication failures.
Échecs de réplication qui existaient plus longtemps que la valeur de durée de vie de tombstone configurée.
Avance ou mise à jour du temps système qui entraîne la suppression d’objets sur certains contrôleurs de
domaine, mais pas sur tous les domaines.
Résolution
La résolution de ce problème dépend de la ou des causes réelles du problème. Pour résoudre ce problème,
vérifiez chacune des conditions suivantes :
1. Déterminez s’il existe des Windows de domaine Server 2003 qui n’ont pas au moins SP1 appliqué. Si
vous trouvez des contrôleurs de domaine de ce type, veillez à les mettre à jour vers au moins SP1 pour
résoudre ce problème.
2. Déterminez si des échecs de réplication ont été autorisés à dépasser la durée de vie de la forêt. En règle
générale, la durée de vie de tombstone de la forêt est de 60 à 180 jours par défaut. Le message
d’événement indique la durée de vie de tombstone de la forêt telle qu’elle est actuellement configurée.
Exécutez la commande repadmin /showrepl pour déterminer s’il existe un problème de réplication. Si
vous pensez qu’il existe un problème de réplication, voir Surveillance et dépannage de la réplication
Active Directory à l’aide du repadmin pour plus d’informations sur la résolution du problème.
3. Déterminez s’il existe des objets en attente. Pour ce faire, exécutez la commande
repadmin /removelingeringobjects en mode avis, comme décrit dans la procédure suivante.
Vous devez d’abord identifier un contrôleur de domaine faisant autorité. Si vous savez qu’un contrôleur de
domaine spécifique a les dernières modifications, vous pouvez l’utiliser comme contrôleur de domaine faisant
autorité. Dans le cas contraire, vous de devez effectuer la procédure suivante sur plusieurs contrôleurs de
domaine jusqu’à ce que vous identifiiez un contrôleur de domaine qui, selon vous, a les dernières modifications.
Ensuite, vous pouvez utiliser ce contrôleur de domaine comme contrôleur de domaine faisant autorité.
Vous devez au moins être membre du groupe Admins du domaine (ou un groupe équivalent) pour effectuer
cette procédure. Examinez les détails sur les appartenances aux groupes par défaut dans Active Directory Local
et Domain Default Groups.
Identifier les objets en attente

1. Sur un contrôleur de domaine dont vous prévoyez d’avoir les dernières modifications, ouvrez une fenêtre
d’invite de commandes avec élévation de élévation de niveaux. Pour ouvrir une fenêtre d'invite de
commandes, cliquez sur Démarrer , pointez sur Tous les programmes , cliquez sur Accessoires ,
cliquez avec le bouton droit sur Invite de commandes , puis cliquez sur Exécuter en tant
qu'administrateur .
2. Exécutez la commande de repadmin suivante en mode avis. Cela vous permet d’évaluer les objets en
attente sans supprimer quoi que ce soit.
repadmin /removelingeringobjects <DestDCName> <SourceDCGUID> <LDAPPartition> /advisory_mode
Remplacez les éléments suivants par les espaces réservé dans la syntaxe de commande :
DestDCName : nom d’hôte du contrôleur de domaine que vous ciblez pour le nettoyage d’objet en
attente. Par exemple, si vous souhaitez supprimer les objets en attente de DC1 dans le domaine
contoso.com, dc1.contoso.com remplacez <DestDCName>.
SourceDCGUID : Exécutez la commande suivante :
repadmin /showrepl AuthDCname |more
où AuthDCname est le nom d’hôte du contrôleur de domaine que vous avez sélectionné comme
faisant autorité. Remplacez le premier GUID d’objet DSA qui s’affiche pour <SourceDCGUID>.
LDAPPartition : nom LDAP (Lightweight Directory Access Partition) de la partition que vous ciblez.
Par exemple, si les objets en attente se sont dans la partition contoso.com de domaine du
domaine, remplacez dc=contoso,dc=com par <LDAPPartition>.
Voici un exemple de commande permettant d’identifier les objets en attente :
repadmin /removelingeringobjects dc1.contoso.com 4a8717eb-8e58-456c-995a-c92e4add7e8e dc=contoso,dc=com

/advisory_mode
Si nécessaire, répétez les étapes précédentes sur des contrôleurs de domaine supplémentaires jusqu’à ce que
vous déterminiez le contrôleur de domaine qui, selon vous, a les dernières modifications. Utilisez ce contrôleur
de domaine comme contrôleur de domaine faisant autorité. Exécutez la repadmin /removelingeringobjects
commande sans le /advisory_mode commutateur pour supprimer réellement les objets en attente. Répétez la
commande si nécessaire pour supprimer les objets en attente de chaque contrôleur de domaine qui les possède.
Redémarrer la réplication après l’ID d’événement 2042

L’état normal de la réplication est celui dans lequel les modifications apportées aux objets et à leurs attributs
convergent de manière à ce que les contrôleurs de domaine reçoivent les dernières informations. Lorsqu’un
contrôleur de domaine partenaire est détecté comme passant des modifications plus anciennes, les
modifications apportées par le partenaire sont considérées comme « d’une part, d’autre part. » Le partenaire est
dit impliqué dans une « réplication d’une grande réplication ». Les contrôleurs de domaine arrêtent
normalement la réplication avec n’importe quel partenaire considéré comme impliqué dans une réplication
d’une grande réplication.
Après avoir supprimé tous les objets en attente, vous pouvez redémarrer la réplication sur le contrôleur de
domaine qui a enregistré l’événement en éditant le Registre.
NOTE
Redémarrez la réplication uniquement après avoir supprimé tous les objets en attente. Une modification incorrecte du
Registre peut endommager gravement votre système. Avant d’apporter des modifications au Registre, il est conseillé de
sauvegarder les données de valeur stockées dans l’ordinateur.
Vous devez au moins être membre du groupe Admins du domaine (ou un groupe équivalent) pour effectuer
cette procédure. Examinez les détails sur les appartenances aux groupes par défaut dans Active Directory Local
et Domain Default Groups.
Utiliser Repadmin pour redémarrer la réplication après l’ID

d’événement 2042
1. Ouvrez une invite de commandes avec élévation de élévation de niveau. Pour ouvrir une fenêtre d'invite
de commandes, cliquez sur Démarrer , pointez sur Tous les programmes , cliquez sur Accessoires ,
cliquez avec le bouton droit sur Invite de commandes , puis cliquez sur Exécuter en tant
qu'administrateur .
repadmin /regkey <hostname> +allowDivergent
/regkey Active (+) et désactive (-) la valeur de l’entrée de Registre

Cohérence de la réplication stricte dans .
<hostname> Remplacez le nom d’un contrôleur de domaine unique ou

utilisez un astérisque (*) pour appliquer la modification à
tous les contrôleurs de domaine dans la forêt. Pour le
nom du contrôleur de domaine, vous pouvez utiliser le
nom DNS (Domain Name System), le nom de l’objet
ordinateur du contrôleur de domaine ou le nom de
l’objet serveur du contrôleur de domaine.
+allowDivergent Permet à la réplication de recommencer avec le

partenaire de réplication qui avait des objets en attente.
Vous ne devez exécuter cette commande qu’une fois
tous les objets en attente supprimés. Une fois que la
réplication s’exécute à nouveau correctement, utilisez le
-allowDivergent commutateur pour éviter que la
réplication ne se produise.
NOTE
Si vous n’avez pas utilisé d’astérisque (*) pour appliquer la modification à tous les contrôleurs de domaine, répétez l’étape
2 pour chaque contrôleur de domaine sur lequel vous souhaitez autoriser la réplication d’une autre façon.
Réinitialiser le Registre pour se protéger contre la réplication obsolète

Lorsque vous êtes satisfait que des objets en attente ont été supprimés et que la réplication s’est correctement
produite à partir du contrôleur de domaine source, utilisez Repadmin pour empêcher la réplication d’origine.
Pour éviter toute réplication d’ordre général, exécutez la commande suivante :
repadmin /regkey <hostname> -allowDivergent
Par exemple, pour restreindre la réplication d’un contrôleur de domaine nommé DC1 dans contoso.com
domaine, exécutez la commande suivante :
repadmin /regkey dc1.contoso.com -allowDivergent
NOTE
Si vous n’avez pas supprimé tous les objets en attente, une tentative de réplication peut entraîner la réplication d’un objet
en attente. Si la cohérence de réplication stricte est activée sur le contrôleur de domaine de destination, la réplication avec
le contrôleur de domaine source est de nouveau bloquée.
ID d’événement de réplication Active Directory
2087 : échec de recherche DNS à l’origine de l’échec
de la réplication
Cet article fournit une solution à l’ID d’événement de réplication Active Directory 2087 qui se produit lorsqu’un
échec de recherche DNS provoque l’échec de la réplication.
Symptômes
Ce problème se produit généralement lorsqu’un échec de recherche DNS entraîne l’échec de la réplication.
Lorsqu’un contrôleur de domaine de destination reçoit l’ID d’événement 2087 dans le journal des événements
du service d’annuaire, tente de résoudre l’identificateur global unique (GUID) dans l’enregistrement de ressource
d’alias (CNAME), le nom de domaine complet (FQDN) et le nom NetBIOS en adresse IP du contrôleur de
domaine source ont tous échoué. Si vous ne parviennent pas à localiser le partenaire de réplication source, la
réplication avec cette source est empêchée tant que le problème n’est pas résolu.
Nom du journal : répertoire

Source de service : Microsoft-Windows-ActiveDirectory_DomainService
Date : 09/03/2008 11:00:21
Catégorie de tâche : client RPC DS
Niveau : Error
Description : Active Directory n’a pas pu résoudre le nom d’hôte DNS suivant du contrôleur de domaine
source en adresse IP. Cette erreur empêche les ajouts, suppressions et modifications dans les services de
domaine Active Directory de se répliquer entre un ou plusieurs contrôleurs de domaine dans la forêt. Les
groupes de sécurité, la stratégie de groupe, les utilisateurs et les ordinateurs et leurs mots de passe seront
incohérents entre les contrôleurs de domaine jusqu’à ce que cette erreur soit résolue, ce qui peut affecter
l’authentification d’authentification et l’accès aux ressources réseau.
Contrôleur de domaine source : DC2
Nom d’hôte DNS défaillant :
b0069e56-b19c-438a-8a1f-64866374dd6e._msdcs.contoso.com
REMARQUE : par défaut, seuls 10 échecs DNS sont affichés pour une période donnée de 12 heures, même si
plus de 10 échecs se produisent. Pour enregistrer tous les événements d’échec individuels, définissez la
valeur de Registre de diagnostics suivante sur 1 :
Chemin d’accès du Registre : HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client
1. Si le contrôleur de domaine source ne fonctionne plus ou si son système d’exploitation a été réinstallé
avec un nom d’ordinateur différent ou un GUID d’objet NTDSDSA, supprimez les métadonnées du
contrôleur de domaine source avec ntdsutil.exe, en suivant les étapes décrites dans l’article MSKB
216498.
2. Confirmez que le contrôleur de domaine source exécute les services de domaine Active Directory et
qu’il est accessible sur le réseau en tapant « net view » ou \ \ <source DC name> « ping <source DC
name> ».
3. Vérifiez que le contrôleur de domaine source utilise un serveur DNS valide pour les services DNS et
que l’enregistrement d’hôte et l’enregistrement CNAME du contrôleur de domaine source sont
correctement enregistrés, à l’aide de la version DNS enhanced de DCDIAG.EXE disponible sur
http://www.microsoft.com/dns
dcdiag /test:dns
4. Vérifiez que ce contrôleur de domaine de destination utilise un serveur DNS valide pour les services
DNS, en exécutant la commande DNS Enhanced de DCDIAG.EXE sur la console du contrôleur de
domaine de destination, comme suit :
dcdiag /test:dns
5. Pour une analyse plus approfondie des erreurs DNS, voir la 824449 :
http://support.microsoft.com/?kbid=824449
Valeur d’erreur : 11004
Le nom demandé est valide, mais aucune donnée du type demandé n’a été trouvée.
Diagnostic
L’échec de la résolution de l’enregistrement de ressource CNAME (Current Alias) du contrôleur de domaine
source en adresse IP peut avoir les causes suivantes :
Le contrôleur de domaine source est éteint, hors connexion ou réside sur un réseau isolé, et les données
Active Directory et DNS du contrôleur de domaine hors connexion n’ont pas été supprimées pour
indiquer que le contrôleur de domaine est inaccessible.
L’une des conditions suivantes existe :
Le contrôleur de domaine source n’a pas enregistré ses enregistrements de ressources dans le DNS.
Le contrôleur de domaine de destination est configuré pour utiliser un serveur DNS non valide.
Le contrôleur de domaine source est configuré pour utiliser un serveur DNS non valide.
Le serveur DNS utilisé par le contrôleur de domaine source n’héberge pas les zones correctes ou les
zones ne sont pas configurées pour accepter les mises à jour dynamiques.
Les serveurs DNS directs que le contrôleur de domaine de destination interroge ne peuvent pas
résoudre l’adresse IP du contrôleur de domaine source suite à des délégations ou des forwardeurs
inexistants ou non valides.
Les services de domaine Active Directory (AD DS) ont été supprimés sur le contrôleur de domaine
source, puis réinstallés avec la même adresse IP, mais la connaissance du nouveau GUID NTDS
Paramètres n’a pas atteint le contrôleur de domaine de destination.
AD DS a été supprimé sur le contrôleur de domaine source, puis réinstallé avec une adresse IP différente,
mais l’enregistrement de ressource de l’adresse hôte actuelle (A) pour l’adresse IP du contrôleur de
domaine source n’est pas enregistré ou n’existe pas sur les serveurs DNS que le contrôleur de domaine
de destination interroge en raison de la latence de réplication ou d’une erreur de réplication.
Le système d’exploitation du contrôleur de domaine source a été réinstallé avec un nom d’ordinateur
différent, mais ses métadonnées n’ont pas été supprimées ou ont été supprimées et n’ont pas encore été
répliquées par le contrôleur de domaine de destination.
Résolution
Tout d’abord, déterminez si un contrôleur de domaine fonctionne. Si le contrôleur de domaine source ne
fonctionne pas, supprimez ses métadonnées restantes d’AD DS.
Si le contrôleur de domaine source fonctionne, poursuivez les procédures pour diagnostiquer et résoudre le
problème DNS, si nécessaire :
Utilisez Dcdiag pour diagnostiquer les problèmes DNS.
Enregistrez les enregistrements de ressource du service DNS (SRV), ainsi que les enregistrements d’hôte.
Synchronisez la réplication entre les contrôleurs de domaine source et de destination.
Vérifiez la cohérence de l’Paramètres GUID NTDS.
Déterminer si un contrôleur de domaine fonctionne
Pour déterminer si le contrôleur de domaine source fonctionne, utilisez le test suivant.
Pour effectuer cette procédure, il faut au minimum être membre du groupe Utilisateurs du domaine
dans le domaine du contrôleur de domaine ou d’un groupe équivalent. Examinez les détails sur
l’utilisation des comptes et appartenances aux groupes appropriés aux groupes locaux et par défaut de
domaine.
Outil : affichage net
Pour vérifier que le contrôleur de domaine exécute AD DS et qu’il est accessible sur le réseau, à l’invite de
commandes, tapez la commande suivante, puis appuyez sur Entrée :
net view \\<SourceDomainControllerName>
Où <SourceDomainControllerName> se trouve le nom NetBIOS du contrôleur de domaine.

Cette commande affiche les partages Netlogon et SYSVOL, indiquant que le serveur fonctionne comme un
contrôleur de domaine. Si ce test montre que le contrôleur de domaine ne fonctionne pas sur le réseau,
déterminez la nature de la déconnexion et si le contrôleur de domaine peut être récupéré ou si ses métadonnées
doivent être supprimées manuellement d’AD DS. Si le contrôleur de domaine ne fonctionne pas et ne peut pas
être restauré, utilisez la procédure de la section suivante,Nettoyer les métadonnées du contrôleur de domaine,
pour supprimer les données associées à ce serveur d’AD DS.
Nettoyer les métadonnées du contrôleur de domaine
Si les tests montrent que le contrôleur de domaine ne fonctionne plus, mais que vous voyez toujours des objets
représentant le contrôleur de domaine dans le logiciel en ligne Sites et services Active Directory, la réplication
continue d’être tentée et vous devez supprimer ces objets des services AD DS manuellement. Vous devez utiliser
l’outil Ntdsutil pour nettoyer (supprimer) les métadonnées du contrôleur de domaine qui a été supprimé.
Si le contrôleur de domaine supprimé est le dernier contrôleur de domaine dans le domaine, vous devez
également supprimer les métadonnées du domaine. Laissez suffisamment de temps à tous les serveurs de
catalogue global de la forêt pour répliquer la suppression de domaine entrante avant de promouvoir un
nouveau domaine avec le même nom.
Le processus de nettoyage des métadonnées est amélioré dans la version de Ntdsutil incluse dans Windows
Server 2003 Service Pack 1 (SP1). Les instructions de nettoyage des métadonnées avec la version Windows
Server 2003 de Ntdsutil et la version Windows Server 2003 SP1 de Ntdsutil sont fournies dans la procédure
suivante.
L’appartenance Enterprise administrateurs, ou un équivalent, est la valeur minimale requise pour effectuer
cette procédure. Examinez les détails sur l’utilisation des comptes et appartenances aux groupes appropriés
aux groupes locaux et par défaut de domaine.
Outil : Ntdsutil (outil en ligne de commande System32)
Étapes de nettoyage des métadonnées du serveur
1. Ouvrez une invite de commandes.
2. À l’invite de commandes, tapez ntdsutil la commande, puis appuyez sur Entrée.
3. À l’invite de commandes ntdsutil, tapez la commande, puis metadata cleanup appuyez sur Entrée.
4. Effectuez le nettoyage des métadonnées comme suit :
NOTE
Si vous supprimez des métadonnées de domaine ainsi que des métadonnées de serveur, ignorez la procédure
suivante et utilisez la procédure qui commence à l’étape 1.
Si vous effectuez uniquement le nettoyage des métadonnées du serveur et que vous utilisez la
version de Ntdsutil.exe incluse avec Windows Server 2003 SP1, à l’invite de commandes, tapez la
commande suivante, puis appuyez sur metadata cleanup: Entrée :
remove selected server <ServerName>
Ou
remove selected server <ServerName1> on <ServerName2>
<ServerName>, <ServerName1> Nom du contrôleur de domaine dont vous souhaitez

supprimer les métadonnées, sous la forme cn=
<ServerName> ,cn=Servers,cn= <SiteName> ,
cn=Sites,cn=Configuration,dc=<ForestRootDomain>
<ServerName2> Nom DNS du contrôleur de domaine auquel vous

souhaitez vous connecter et à partir duquel vous
souhaitez supprimer les métadonnées du serveur.
Si vous effectuez un nettoyage des métadonnées à l’aide de la version de Ntdsutil.exe incluse dans
Windows Server 2003 sans Service Pack, ou si vous effectuez à la fois le nettoyage des
métadonnées de domaine et le nettoyage des métadonnées du serveur, effectuez le nettoyage des
métadonnées comme suit :
a. À metadata cleanup: l’invite, tapez connection la commande, puis appuyez sur Entrée.
b. À server connections: l’invite, tapez connect to server <Server> la commande, puis appuyez
sur Entrée.
c. À connection: l’invite, tapez quit la commande, puis appuyez sur Entrée.
d. À metadata cleanup: l’invite, tapez select operation target la commande, puis appuyez sur
Entrée.
e. À select operation target: l’invite, tapez list sites la commande, puis appuyez sur Entrée.
f. Une liste numéroée de sites s’affiche. Tapez select site <SiteNumber> la commande, puis
g. À select operation target: l’invite, tapez list domains in site la commande, puis appuyez
sur Entrée.
h. Une liste numéroée de domaines dans le site sélectionné s’affiche. Tapez
select domain <DomainNumber> la commande, puis appuyez sur Entrée.
i. À select operation target: l’invite, tapez list servers in site la commande, puis appuyez
sur Entrée.
j. Une liste numéroée de serveurs dans un domaine et un site s’affiche. Tapez
select server <ServerNumber> la commande, puis appuyez sur Entrée.
k. À select operation target: l’invite, tapez quit la commande, puis appuyez sur Entrée.
l. À metadata cleanup: l’invite, tapez remove selected server la commande, puis appuyez sur
Entrée.
m. Si le serveur dont vous avez supprimé les métadonnées est le dernier contrôleur de domaine
dans le domaine et que vous souhaitez supprimer les métadonnées de domaine, à l’invite,
tapez la commande, puis appuyez sur metadata cleanup: remove selected domain Entrée. Les
métadonnées du domaine que vous avez sélectionné à l’étape h sont supprimées.
n. À metadata cleanup: ntdsutil: l’invite, quit tapez, puis appuyez sur Entrée.
<Server> Nom DNS d’un contrôleur de domaine à connecter.
<SiteNumber> Nombre associé au site du serveur que vous

souhaitez nettoyer, qui apparaît dans la liste.
<DomainNumber> Nombre associé au domaine du serveur que vous

souhaitez nettoyer, qui apparaît dans la liste.
<ServerNumber> Nombre associé au serveur que vous souhaitez

nettoyer, qui apparaît dans la liste.
Utiliser Dcdiag pour diagnostiquer les problèmes DNS

Si le contrôleur de domaine fonctionne en ligne, continuez à utiliser l’outil Dcdiag pour diagnostiquer et
résoudre les problèmes DNS qui pourraient interférer avec la réplication Active Directory.
Utilisez les procédures suivantes pour effectuer ce processus :
Vérifiez la connectivité et la fonctionnalité DNS de base.
Vérifiez l’inscription de l’enregistrement de ressource d’alias (CNAME) dans DNS.
Vérifiez les mises à jour dynamiques et activez les mises à jour dynamiques sécurisées.
Avant de commencer ces procédures, collectez les informations suivantes, contenues dans le texte du message
ID d’événement 2087 :
FQDN du contrôleur de domaine source et du contrôleur de domaine de destination
Adresse IP du contrôleur de domaine source
La version mise à jour de Dcdiag incluse dans les outils de support Windows dans Windows Server 2003 SP1
contient des tests qui fournissent des tests consolidés et améliorés des fonctionnalités DNS de base et avancées.
Vous pouvez utiliser cet outil pour diagnostiquer les fonctionnalités DNS de base et les mises à jour
dynamiques.
Lorsque vous utilisez la version SP1 améliorée de Dcdiag pour les tests DNS, il existe des exigences spécifiques
qui ne s’appliquent pas à tous les tests Dcdiag.
Pour effectuer les nouveaux tests DNS disponibles dans la version SP1 de Dcdiag, il faut au minimum être
membre d’Enterprise administrateurs ou d’un équivalent. Examinez les détails sur l’utilisation des comptes
et appartenances aux groupes appropriés aux groupes locaux et par défaut de domaine.
Outil : Dcdiag.exe
Système d'exploitation:
Vous pouvez exécuter la version améliorée de Dcdiag sur les ordinateurs exécutant les systèmes
d’exploitation suivants :
Windows XP Professionnel
Windows Server 2003
Windows Server 2003 avec SP1
Vous pouvez exécuter les nouveaux tests DNS Dcdiag sur des serveurs DNS Microsoft installés sur
des contrôleurs de domaine exécutant les systèmes d’exploitation suivants :
Windows 2000 Server avec Service Pack 3 (SP3)
Windows 2000 Server avec Service Pack 4 (SP4)
Windows Server 2003
Windows Server 2003 avec SP1
NOTE
Vous pouvez utiliser le commutateur dans les commandes Dcdiag pour enregistrer /f: la sortie dans un fichier texte. À
utiliser pour générer le fichier à l’emplacement indiqué /f: FileName dans FileName, par exemple,
/f:c:\Test\DnsTest.txt .
Vérifier la fonctionnalité DNS de base

Pour vérifier les paramètres qui peuvent interférer avec la réplication Active Directory, vous pouvez commencer
par l’exécution du test DNS de base qui garantit que le DNS fonctionne correctement sur le contrôleur de
domaine.
Le test DNS de base vérifie les éléments suivants :
Connectivité : le test détermine si les contrôleurs de domaine sont inscrits dans DNS, peuvent être
contactés par PING et ont une connectivité LDAP/RPC (Lightweight Directory Access Protocol/remote
procedure call). Si le test de connectivité échoue sur un contrôleur de domaine, aucun autre test n’est
exécuté sur ce contrôleur de domaine. Le test de connectivité est effectué automatiquement avant
l’application d’un autre test DNS.
Services essentiels : le test confirme que les services suivants sont en cours d’exécution et disponibles sur
le contrôleur de domaine testé :
Service client DNS
Service Net Logon
Service centre de distribution de clés (KDC)
Service DNS Server (si DNS est installé sur le contrôleur de domaine)
Configuration du client DNS : le test confirme que les serveurs DNS sur toutes les cartes sont accessibles.
Inscriptions des enregistrements de ressources : le test confirme que l’enregistrement de ressource hôte
(A) de chaque contrôleur de domaine est inscrit sur au moins l’un des serveurs DNS configurés sur le
client.
Zone et début de l’autorité ( SOA) : si le contrôleur de domaine exécute le service serveur DNS, le test
confirme que la zone de domaine Active Directory et l’enregistrement de ressource de début de l’autorité
(SOA) pour la zone de domaine Active Directory sont présents.
Zone racine : vérifie si la zone racine (.) est présente.
Ét a p e s d e v é r i fi c a t i o n d e s fo n c t i o n n a l i t é s D N S d e b a se
1. À l’invite de commandes, tapez la commande suivante et appuyez sur Entrée :
dcdiag /test:dns /s:<SourceDomainControllerName> /DnsBasic
Où se trouve le nom, le nom NetBIOS ou le nom DNS du contrôleur <SourceDomainControllerName>

de domaine.
En alternative, vous pouvez tester tous les contrôleurs de domaine dans la forêt en tapant /e: au lieu de
/s: .
2. Copiez le rapport dans Bloc-notes un éditeur de texte équivalent.

3. Faites défiler le tableau récapitulatif vers le bas du fichier journal Dcdiag.
4. Notez les noms de tous les contrôleurs de domaine qui signalent l’état « Avertir » ou « Échec » dans le
tableau récapitulatif.
5. Recherchez la section détaillée de l’analyse du contrôleur de domaine à problème en recherchant la
chaîne « DC: <DomainControllerName> ».
6. A apporté les modifications de configuration requises sur les clients DNS et les serveurs DNS.
7. Pour valider les modifications de configuration, Dcdiag /test:DNS réexécutez-la avec le commutateur ou
le /e: /s: commutateur.
Si le test DNS de base n’affiche aucune erreur, continuez en vérifiant que les enregistrements de ressources
utilisés pour localiser les contrôleurs de domaine sont enregistrés dans le DNS.
Vérifier l’enregistrement des ressources
Le contrôleur de domaine de destination utilise l’enregistrement de ressource d’alias DNS (CNAME) pour
localiser son partenaire de réplication de contrôleur de domaine source. Bien que les contrôleurs de domaine
exécutant Windows Server 2003 avec SP1 peuvent localiser des partenaires de réplication source à l’aide de
noms de domaine pleinement connus ou, en cas d’échec, les noms NetBIOS, la présence de l’enregistrement de
ressource d’alias (CNAME) est attendue et doit être vérifiée pour que le DNS fonctionne correctement.
Vous pouvez utiliser Dcdiag pour vérifier l’inscription de tous les enregistrements de ressources qui sont
essentiels pour l’emplacement du contrôleur de domaine à l’aide du dcdiag /test:dns /DnsRecordRegistration
test. Ce test vérifie l’inscription des enregistrements de ressources suivants dans DNS :
L’alias (CNAME) (enregistrement de ressource basé sur le GUID qui localise un partenaire de réplication)
L’hôte (A) (l’enregistrement de ressource hôte qui contient l’adresse IP du contrôleur de domaine)
LDAP SRV (les enregistrements de ressource de service (SRV) qui localisent les serveurs LDAP)
Gc SRV (les enregistrements de ressource de service (SRV) qui localisent les serveurs de catalogue global)
Enregistrements de ressource PDC SRV (le service (SRV) qui localise les opérations d’émulateur de
contrôleur de domaine principal (PDC)
Vous pouvez également utiliser la procédure suivante pour vérifier uniquement l’enregistrement de ressource
d’alias (CNAME).
Ét a p e s d e v é r i fi c a t i o n d e l ’e n r e g i st r e m e n t d e r e sso u r c e d ’ a l i a s (C N A M E)
1. Dans le logiciel en ligne DNS, recherchez n’importe quel contrôleur de domaine qui exécute le service
DNS Server, où le serveur héberge la zone DNS avec le même nom que le domaine Active Directory du
2. Dans l’arborescence de la console, cliquez sur la zone nommée _msdcs. Dns_Domain_Name.
NOTE
Dans Windows 2000 Server DNS, _msdcs. Dns_Domain_Name est un sous-domaine de la zone DNS pour le nom
de domaine Active Directory. Dans Windows DNS Server 2003, _msdcs. Dns_Domain_Name est une zone
distincte.
3. Dans le volet d’informations, vérifiez que les enregistrements de ressources suivants sont présents :
Un enregistrement de ressource d’alias (CNAME) nommé Dsa_Guid._msdcs. Dns_Domain_Name
Un enregistrement de ressource hôte (A) correspondant pour le nom du serveur DNS
Si l’enregistrement de ressource d’alias (CNAME) n’est pas enregistré, vérifiez que les mises à jour dynamiques
fonctionnent correctement. Utilisez le test de la section suivante.
Vérifier les mises à jour dynamiques
Si le test DNS de base indique que les enregistrements de ressource n’existent pas dans DNS, utilisez le test de
mise à jour dynamique pour diagnostiquer pourquoi le service Net Logon n’a pas inscrit automatiquement les
enregistrements de ressource. Pour vérifier que la zone de domaine Active Directory est configurée pour
accepter les mises à jour dynamiques sécurisées et pour enregistrer un enregistrement de test
(_dcdiag_test_record), utilisez la procédure suivante. L’enregistrement de test est supprimé automatiquement
après le test.
Pour vérifier les mises à jour dynamiques, à l’invite de commandes, tapez la commande suivante, puis appuyez
sur Entrée :
dcdiag /test:dns /s:<SourceDomainControllerName> /DnsDynamicUpdate
Où se trouve le nom, le nom NetBIOS ou le nom DNS du contrôleur <SourceDomainControllerName> de

domaine.
Vous pouvez également tester tous les contrôleurs de domaine à l’aide du /e: commutateur au lieu du /s:
commutateur.
Si la mise à jour dynamique sécurisée n’est pas configurée, utilisez la procédure suivante pour la configurer.
Activer les mises à jour dynamiques sécurisées
1. Ouvrez le logiciel en snap-in DNS.
2. Dans l’arborescence de la console, cliquez avec le bouton droit sur la zone applicable, puis cliquez sur
Propriétés.
3. Sous l’onglet Général, vérifiez que le type de zone est intégré à Active Directory.
4. Dans les mises à jour dynamiques, cliquez sur Sécurisé uniquement.
Enregistrer les enregistrements de ressource DNS
Si les enregistrements de ressource DNS n’apparaissent pas dans le DNS pour le contrôleur de domaine source,
que vous avez vérifié les mises à jour dynamiques et que vous souhaitez enregistrer les enregistrements de
ressource DNS immédiatement, vous pouvez forcer l’inscription manuellement en suivant la procédure
suivante. Le service Net Logon sur un contrôleur de domaine enregistre les enregistrements de ressource DNS
requis pour que le contrôleur de domaine se trouve sur le réseau. Le service client DNS enregistre
l’enregistrement de ressource hôte (A) vers qui pointe l’enregistrement d’alias (CNAME).
Pour effectuer cette procédure, il faut au minimum être membre du groupe Administrateurs du domaine
dans le domaine racine de la forêt ou du groupe administrateurs Enterprise, ou un groupe équivalent.
Outils net stop / net start : , ipconfig
Enregistrer manuellement les enregistrements de ressource DNS
Pour lancer l’inscription des enregistrements de ressource Locator du contrôleur de domaine manuellement sur
le contrôleur de domaine source, à l’invite de commandes, tapez les commandes suivantes, puis appuyez sur
Entrée après chaque commande :
net stop net logon

net start net logon
Pour lancer manuellement l’inscription de l’enregistrement de ressource A de l’hôte, à l’invite de commandes,

tapez la commande suivante, puis appuyez sur Entrée :
ipconfig /flushdns
ipconfig /registerdns
Patientez 15 minutes, puis examinez les événements dans l’Observateur d’événements pour garantir
l’inscription correcte des enregistrements de ressource.
Répétez la procédure de la section Vérifier l’enregistrement de ressource précédemment dans cette section pour
vérifier que les enregistrements de ressource apparaissent dans DNS.
Synchroniser la réplication entre les contrôleurs de domaine source et de destination
Une fois le test DNS terminé, utilisez la procédure suivante pour synchroniser la réplication sur la connexion
entrante entre le contrôleur de domaine source et le contrôleur de domaine de destination.
dans le domaine du contrôleur de domaine de destination, ou un groupe équivalent. Examinez les détails sur
l’utilisation des comptes et appartenances aux groupes appropriés aux groupes locaux et par défaut de
domaine.
Outil : Sites et services Active Directory
Étapes de synchronisation de la réplication à partir d’un contrôleur de domaine source
1. Ouvrez Sites et services Active Directory.
2. Dans l’arborescence de la console, double-cliquez sur le conteneur Sites, double-cliquez sur le site du
contrôleur de domaine auquel vous souhaitez synchroniser la réplication, double-cliquez sur le conteneur
Serveurs, double-cliquez sur l’objet serveur du contrôleur de domaine, puis cliquez sur NTDS Paramètres .
3. Dans le volet d’informations, dans la colonne De ser veur, recherchez l’objet de connexion qui affiche le nom
du contrôleur de domaine source.
4. Cliquez avec le bouton droit sur l’objet de connexion approprié, puis cliquez sur Répliquer maintenant.
5. Cliquez sur OK .
Si la réplication ne réussit pas, utilisez la procédure de la section suivante pour vérifier la cohérence du GUID
Paramètres NTDS.
Vérifier la cohérence du GUID Paramètres NTDS
Si vous avez effectué tous les tests DNS et que d’autres tests et réplication n’aboutit pas, utilisez la procédure
suivante pour vérifier que le GUID de l’objet Paramètres NTDS utilisé par le contrôleur de domaine de
destination pour localiser son partenaire de réplication correspond au GUID actuellement en vigueur sur le
contrôleur de domaine source lui-même. Pour effectuer ce test, vous affichez le GUID de l’objet tel qu’il apparaît
dans les répertoires locaux de chaque contrôleur de domaine.
dans le domaine du contrôleur de domaine de destination, ou un groupe équivalent.
Outil : Ldp.exe (Windows support technique)
Étapes de vérification de la cohérence du GUID Paramètres NTDS
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez Ldp, puis cliquez sur OK.
2. Dans le menu Connexion, cliquez sur Connecter .
3. Dans la Connecter dialogue, laissez la zone Ser veur vide.
4. Dans Por t, tapez 389, puis cliquez sur OK.
5. Dans le menu Connexion, cliquez sur Lier.
6. Dans la boîte de dialogue Liaison, fournissez les informations Enterprise administrateurs. S’il n’est pas déjà
sélectionné, cliquez sur Domaine.
7. Dans Domaine, tapez le nom du domaine racine de la forêt, puis cliquez sur OK.
8. Dans le menu Affichage, cliquez sur Arborescence.
9. Dans la boîte de dialogue Arborescence, tapez CN=Configuration,DC=Forest_Root_Domain puis cliquez
sur OK .
10. Accédez à l’objet CN=NTDS Paramètres,CN=SourceServerName,CN=Servers,CN=SiteName,
CN=Sites,CN=configuration,DC=ForestRootDomain.
11. Double-cliquez sur l’objet Paramètres NTDS. Dans le volet d’informations, affichez la valeur de l’attribut
objectGUID . Cliquez avec le bouton droit sur cette valeur, puis copiez-la dans Bloc-notes.
12. Dans le menu Connexion, cliquez sur Déconnecter.
13. Répétez les étapes 2 à 11, mais à l’étape 3, tapez le nom du contrôleur de domaine source, par exemple
DC03.
14. Dans Bloc-notes, comparez les valeurs des deux GUID.
15. Si les valeurs ne correspondent pas, le contrôleur de domaine de destination doit recevoir la réplication du
GUID valide. Vérifiez la valeur GUID sur d’autres contrôleurs de domaine et essayez la réplication sur le
contrôleur de domaine de destination avec un autre contrôleur de domaine qui possède le GUID correct.
16. Si les valeurs correspondent, vérifiez que le GUID correspond au GUID dans Dsa_Guid._msdcs.
Dns_Domain_Nameresource pour le contrôleur de domaine source, comme suit :
a. Notez les serveurs DNS principaux que chaque contrôleur de domaine identifie dans les propriétés
TCP/IP dans leur réseau Paramètres. Tous les serveurs DNS répertoriés dans les propriétés TCP/IP
respectives doivent pouvoir résoudre indirectement ou directement cet enregistrement de ressource
d’alias (CNAME).
b. Sur les serveurs répertoriés, identifiez le ou les serveurs de noms faisant autorité pour cette zone de
domaine en regardant les noms de serveur répertoriés pour les enregistrements de ressource de
serveur de noms (NS) à la racine de la zone. (Dans le logiciel en snap-in DNS, sélectionnez la zone de
recherche avant pour le domaine racine, puis affichez les enregistrements de serveur de noms (NS)
dans le volet d’informations.)
c. Sur le ou les serveurs de noms obtenus à l’étape b, ouvrez le logiciel en snap-in DNS et double-
cliquez sur la zone de recherche avant pour le nom de domaine racine de la forêt. Double-cliquez sur
_msdcs dossier de gestion et notez les enregistrements de ressource d’alias (CNAME) qui existent
pour le nom de votre serveur.
Les ID d’événement de réplication Active Directory
2108 et 1084 se produisent pendant la réplication
entrante des services de domaine Active Directory
Cet article fournit une solution à un problème dans lequel vous obtenez les ID d’événement 2108 et 1084
lorsque la réplication entrante des services de domaine Active Directory (AD DS) se produit.
Symptômes
Lorsque la réplication entrante des services de domaine Active Directory (AD DS) se produit, un contrôleur de
domaine de destination qui exécute Microsoft Windows Server 2003 Service Pack 1 (SP1) via Windows Server
2016 enregistre l’événement suivant dans le journal du service d’annuaire :
ID d’événement 1084 : Événement interne : Les services de domaine Active Directory n’ont pas pu mettre à
jour l’objet suivant avec les modifications reçues du service d’annuaire source suivant. Cela est dû au fait
qu’une erreur s’est produite lors de l’application des modifications apportées aux services de domaine
Active Directory sur le service d’annuaire.
Objet : CN=<cn path>
GUID d’objet : <objectguid>
Service d’annuaire source : NTDSA._msdcs.<forst root DNS domain name>
La synchronisation du service d’annuaire avec le service d’annuaire source est bloquée jusqu’à ce que ce
problème de mise à jour soit résolu.
Cette opération est tentée à nouveau lors de la prochaine réplication programmée.
Redémarrez l’ordinateur local si cette condition semble être liée à de faibles ressources système (par
exemple, une mémoire physique ou virtuelle faible).
Données supplémentaires :
Valeur d’erreur : <error code> <error string>
NOTE
Dans le texte de la valeur Error, et représentent les valeurs réelles <error code> <error string> affichées dans l’entrée
du journal.
L’événement 1804 est journalisé Windows server 2000.
Les contrôleurs de domaine de destination qui exécutent Windows Server 2003 SP1 enregistrent également
l’événement suivant dans le journal du service d’annuaire :
ID d’événement 2108 : cet événement contient DES PROCÉDURES DE RÉPARATION pour l’événement 1084
qui a été précédemment journalisé. Ce message indique un problème spécifique avec la cohérence de la
base de données des services de domaine Active Directory sur cette destination de réplication. Une erreur
de base de données s’est produite lors de l’application de modifications répliquées à l’objet suivant. La base
de données avait un contenu inattendu, ce qui empêchait la modification d’être réalisée.
NOTE
L’événement 2108 est connecté Windows Server 2003 après l’installation de SP1.
Il s’agit d’un événement partenaire de l’événement 1084.
Cause
Ces événements se produisent lorsque le contrôleur de domaine ne peut pas écrire une modification
transactionnelle dans la copie locale de la base de données Active Directory.
Résolution
Pour résoudre ce problème, suivez ces étapes. Réessayez l’opération de réplication après chaque étape qui
effectue une modification.
1. Assurez-vous que l’espace disque disponible est suffisant sur les volumes qui hébergent la base de
données Active Directory, puis réessayez l’opération. Pour libérer de l’espace disque supplémentaire,
a. Déplacez les fichiers non liés vers un autre volume.
b. Effectuez une sauvegarde de l’état du système. Ce processus réduit la taille des fichiers journaux
de transactions. Pour plus d’informations, voir Comment utiliser la fonctionnalité de sauvegarde
pour sauvegarder et restaurer des données dans Windows Server 2003.
c. Effectuer une défragmentation hors connexion d’Active Directory. Pour plus d’informations, voir
Comment effectuer la défragmentation horsconnexion de la base de données Active Directory .
2. Assurez-vous que la compression du système de fichiers NTFS n’est pas allumée sur les lecteurs
physiques qui hébergent le fichier Ntds.dit et les fichiers journaux des transactions. Pour le confirmer,
cliquez avec le bouton droit sur la lettre du lecteur dans l’ordinateur Mon ordinateur, puis assurez-vous
que la case à cocher Compresser pour économiser de l’espace disque n’est pas sélectionnée.
3. Assurez-vous que les lecteurs physiques qui hébergent le fichier Ntds.dit et les fichiers journaux des
transactions sont spécifiquement exclus des programmes antivirus distants et locaux. Pour plus
d’informations, consultez la documentation de votre logiciel antivirus.
4. Si le contrôleur de domaine de destination contient le catalogue global et que l’erreur se produit dans
l’une des partitions en lecture seule, utilisez l’une des méthodes suivantes pour résoudre le problème :
Méthode 1 : utilisez l’option de réhost de l’outil Repadmin.exe pour réhost la partition affectée.
LRepadmin.exe est installé sur les ordinateurs qui ont le rôle de contrôleur de domaine et est
installé avec l’outil RSAT sur les stations de travail et serveurs membres. Pour ce faire, tapez ce qui
suit à l’invite de commandes, où domain_controller est le nom du contrôleur de domaine de
destination et good_source_domain_controller_name est le nom d’un autre contrôleur de
domaine :
repadmin /rehost domain_controller naming_context good_source_domain_controller_name
Méthode 2 : configurez le contrôleur de domaine afin qu’il ne soit plus un serveur de catalogue
global. Procédez comme suit :
a. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Sites et
ser vices Active Director y.
b. Localisez les serveurs de premier site par défaut domain_controller_name sous-Paramètres \
\ \ NTDS.
c. Cliquez avec le bouton droit sur NTDS Paramètres, puis cliquez sur Propriétés.
d. Cliquez pour effacer la case à cocher Catalogue global, puis cliquez sur OK.
Méthode 3
Si l’erreur se produit dans une partition de programme, utilisez l’outil Ntdsutil.exe pour modifier le
réplica qui héberge la partition du programme.
5. Utilisez un utilitaire tiers, tel que l’utilitaire FileMon, pour déterminer si un programme ou un utilisateur
accède à la base de données Active Directory, aux fichiers journaux des transactions ou au fichier
Edp.tmp. S’il existe une activité d’accès aux fichiers, arrêtez les services responsables de l’activité. Pour
plus d’informations sur l’utilitaire FileMon, voir FileMon Windows v7.04.
6. Déterminez si le problème est lié au parent de l’objet Active Directory sur le contrôleur de domaine de
destination. Pour cela, procédez comme suit :
a. Sur le contrôleur de domaine source, déplacez temporairement l’objet référencé dans l’événement
1084 vers un conteneur d’unité d’organisation. L’ou ne doit pas être liée au conteneur actuel. Par
exemple, déplacez l’objet vers un nouveau conteneur de la racine du domaine.
b. Si la réplication est terminée après le déplacement de l’objet, déplacez-le vers son conteneur
d’origine.
c. Forcez le propagator de descripteur de sécurité à reconstruire le conteneur d’objets dans la base
de données qui existe sur les contrôleurs de domaine source et de destination. Pour cela, procédez
comme suit :
a. Assurez-vous que les outils de Windows Server 2003 sont installés. Les outils de support
sont disponibles sur le CD-ROM Windows Server 2003 dans le dossier Support\Tools.
Double-cliquez sur le Suptools.msi pour installer les outils.
b. Cliquez sur Démarrer, cliquez sur Exécuter, tapez ldp, puis cliquez sur OK.
c. Cliquez sur Connexion, Connecter, puis tapez le nom du serveur à connecter.
NOTE
Vous vous connecterez sur le port 389 pour Active Directory.
d. Cliquez sur Connexion, cliquez sur Liaison, puis tapez votre nom d’utilisateur
d’administration, votre mot de passe et votre domaine. (Vous devez utiliser les informations
d’identification d’administrateur de domaine ou d’administrateur d’entreprise.) Cliquez sur
OK .
e. Dans le menu Parcourir, cliquez sur Modifier. Laissez la zone de texte DN vide. Dans la
zone de texte Attribut, tapez FixUpInheritance . Cliquez sur Oui dans la zone de texte
Valeur.
f. Dans la zone Opération, cliquez sur Ajouter.
g. Cliquez sur Entrée pour remplir la zone Liste d’entrées.
NOTE
Dans la zone Liste d’entrées, [Add]fixupinheritance:yes apparaît.
h. Cliquez sur Exécuter .
NOTE
Le volet droit affiche désormais l’état Modifié et le propagator du descripteur de sécurité démarre.
Le runtime du propagator de descripteur de sécurité dépend de la taille de la base de données
Active Directory. Le processus est terminé lorsque le compteur DS Security Propagation
Events de l’objet NTDS Performance revient à zéro.
i. Cliquez sur Fermer, sur Connexion, puis sur Quitter.

7. Sur le contrôleur de domaine source, tapez à l’invite de commandes, puis affichez les métadonnées de
l’objet pour le chemin d’accès au nom unique référencé dans l’événement
repadmin /showmeta distinguished_name_path 1084. Répétez cette étape sur le contrôleur de domaine de
destination. Recherchez les valeurs incohérentes qui incluent, sans s’y limiter, les valeurs suivantes :
Noms et nombres d’attributs incorrects qui apparaissent sur l’objet
Horodaages d’origine ou de date incorrects
Numéros de séquence de mise à jour locale incorrects (USN)
Des valeurs incorrectes peuvent indiquer un problème avec la page de base de données qui héberge
l’objet.
Pour utiliser l'Repadmin.exe lorsque le chemin d’accès au nom principal fait référence à un objet en direct,
tapez ce qui suit à l’invite de commandes :
repadmin /showmeta remote_domain_controller_name distinguished_name_path_of_reference _object
Si l’objet se trouve dans un conteneur d’objets supprimés ou si vous ne pouvez pas utiliser l’outil
Repadmin.exe pour trouver l’objet, utilisez la référence GUID de l’objet pour trouver l’objet. Ce GUID est
référencé dans l’événement 1084. Pour ce faire, tapez ce qui suit à l’invite de commandes :
repadmin /showmeta remote_domain_controller_name "GUID_for_the_object

that_is_referenced_in_Event_ID_1084"
Par exemple, si les événements 1084 et 2108 font référence à un objet dont le GUID est b49cd496-98a2-
4500-bb08-58550c2f79ac, tapez repadmin /showmeta "<GUID=b49cd496-98a2-4500-bb08-58550c2f79ac>" .
NOTE
Les guillemets et crochets sont obligatoires.
8. Obtenez l’outil de Ntdsutil.exe le plus récent en installant le service pack le plus récent pour votre système
d’exploitation. Utilisez l'Ntdsutil.exe pour effectuer une vérification de l’intégrité de la base de données
Active Directory sur le contrôleur de domaine source.
Avant de démarrer l’ordinateur en mode restauration des services d’annuaire, obtenez le mot de passe du
compte d’administrateur hors connexion. Si vous ne connaissez pas le mot de passe du compte
d’administrateur, réinitialisez le mot de passe du mode restauration des services d’annuaire avant de
démarrer dans ce mode. Sur les contrôleurs de domaine qui exécutent Windows 2000 Service Pack 2
(SP2) et ultérieurs, utilisez la Setpwd.exe suivante. La Setpwd.exe est située dans le dossier
%Systemroot%\System32. Sur Windows de domaine basé sur Server 2003, utilisez la commande Mot de
passe du mode restauration des services d’annuaire Ntdsutil Set.
Pour plus d’informations sur le mode de restauration des services d’annuaire, consultez le message
d’erreur « Les services d’annuaire ne peuvent pas démarrer » lorsque vous démarrez votre contrôleur de
domaine Windows ou SBS.
Pour plus d’informations sur la modification du mot de passe dans Windows Server 2003, consultez le
message d’erreur « Les services d’annuaire ne peuvent pas démarrer » lorsque vous démarrez votre
contrôleur de domaine Windows ou SBS.
9. Redémarrez le contrôleur de domaine source, puis appuyez sur F8 pour démarrer le mode de
restauration des services d’annuaire. À l’invite de commandes, ntdsutil files integrity tapez, puis
NOTE
Cette commande confirme l’intégrité de la base de données.
Si l’outil Ntdsutil signale que la base de données est endommagée et que vous avez des réplicas
des contextes d’attribution de noms sur le contrôleur de domaine source, forcez la rétrogradation
du contrôleur de domaine source, puis faites-le à nouveau après avoir vérifié l’intégrité des pilotes,
du microprogramme et des lecteurs physiques qui hébergent la base de données Active Directory
et les fichiers journaux des transactions.
Si la base de données est endommagée et qu’il n’existe aucun réplica du contexte d’attribution de
noms sur le contrôleur de domaine source, restituer l’état système le plus récent. Utilisez
l'NTDSutil.exe pour confirmer à nouveau l’intégrité de la base de données. Si vous recevez
toujours un message d’altération, restituer les sauvegardes plus anciennes jusqu’à ce que vous
confirmiez l’intégrité du contrôleur de domaine.
Si la base de données est toujours endommagée, restituer la sauvegarde de l’état du système la
plus récente, puis, à l’invite de commandes, tapez :
ntdsutil files recover
Utilisez l’outil NTDSutil.exe vérifier à nouveau l’intégrité de la base de données. Si la base de

données réussit la vérification de l’intégrité, effectuez une défragmentation hors connexion de la
partition de disque. Pour plus d’informations, voir Comment effectuer la défragmentation
horsconnexion de la base de données Active Directory .
Pour effectuer une vérification de l’intégrité de la base de données, tapez ce qui suit à l’invite de
commandes, puis appuyez sur Entrée, où database_name est le nom de la base de données
Active Directory :
esentutl.exe /g database_name
Enfin, utilisez l’option Démarrer Windows normalement pour redémarrer l’ordinateur, puis
réessayez la réplication du contrôleur de domaine source vers le contrôleur de domaine de
destination affecté. Si la base de données échoue à la vérification de l’intégrité, le contrôleur de
domaine doit être interrompu. Vous utilisez l’outil de migration Active Directory (ADMT) pour
migrer des objets. Vous pouvez également utiliser les outils Ldifde.exe et Csvde.exe pour exporter
des objets que vous importerez dans un nouveau contrôleur de domaine de destination.
Pour plus d’informations sur l’utilisation des outils Ldifde.exe et Csvde.exe, voir le Guide pas à pas
de l’importation et de l’exportation en bloc vers Active Directory.
10. Si ces étapes ne réussissent pas et que l’erreur de réplication se poursuit, rétrogradez le contrôleur de
domaine, confirmez l’intégrité des lecteurs physiques et des volumes qui hébergent le fichier Ntds.dit et
le sous-système de disque, puis faites de nouveau la promotion du contrôleur de domaine. Utilisez le
même nom d’ordinateur.
11. Utilisez la commande compacte des fichiers ntdsutil pour effectuer une défragmentation hors connexion
de la base de données Active Directory. Pour plus d’informations, voir Performing offline
defragmentation of the Active Directory Database .
12. À l’invite de commandes, tapez la commande suivante, puis appuyez sur Entrée :
ntdsutil "semantic database analysis" "go"
NOTE
Les guillemets de cet exemple sont requis pour exécuter la commande d’analyse de base de données sémantique à
l’aide d’un argument de ligne de commande unique.
Si des erreurs sont signalées, type ntdsutil go fixup puis appuyez sur Entrée.
NOTE
Les commandes de base de données sémantique n’effectuent pas de réparations de perte sur les bases de
données Active Directory, telles que les commandes ou la réparation de fichiers Ntdsutil Ntdsutil server 2003
Service Pack 1 pré-Windows Server 2003. Esentutl /p

Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité
de ces produits.
Erreur de réplication Active Directory 1127 : lors de
l’accès au disque dur, une opération de disque a
échoué même après des tentatives
Cet article décrit un problème dans lequel les réplications Active Directory échouent avec l’erreur Win32 1127 :
« Lors de l’accès au disque dur, une opération de disque a échoué même après des tentatives. »
Symptômes
Cet article décrit les symptômes, les causes et les étapes de résolution pour les cas où les opérations AD
échouent avec l’erreur Win32 1127 : « Lors de l’accès au disque dur, une opération de disque a échoué même
après des tentatives. »
1. La promotion DCPROMO d’un nouveau contrôleur de domaine échoue avec l’erreur 1127 : lors de l’accès
au disque dur, une opération de disque a échoué même après de nouvelles tentatives
L’erreur à l’écran affichée dans DCPROMO est la :
Texte du titre de la boîte de dialogue : Assistant Installation d’Active Directory

Texte du message :
Active Directory n’a pas pu répliquer la partition d’annuaire <DN path of failing partition> à partir du
contrôleur de domaine <fully qualified computer name of helper DC> distant.
« Lors de l’accès au disque dur, une opération de disque a échoué même après des tentatives. »
DCPROMO. LOG contient le texte suivant :
[INFO] Réplication de <partition name> la partition d’annuaire
[INFO] Erreur : Active Directory n’a pas pu répliquer la partition d’annuaire <partition DN> à partir
du contrôleur de domaine <helper DC> distant. (1127)
[INFO] NtdsInstall pour <DNS domain> la 1127 renvoyée
[INFO] DsRolepInstallDs a renvoyé 1127 [ERREUR] Échec d’installation dans le service d’annuaire
(1127)
2. DCDIAG signale que le test réplications Active Directory a échoué avec l’état d’erreur (1127) : lors de
l’accès au disque dur, une opération de disque a échoué même après des tentatives
Un exemple de texte d’erreur issu de DCDIAG est illustré ci-dessous :
Serveur de test : <site><DC name>

[Vérification des réplications, <DC name> ] Une tentative de réplication récente a échoué :
Contexte d’attribution de noms : DC=<DN path>
Lors de l’accès au disque dur, une opération de disque a échoué même après des tentatives.
L’échec s’est produit à <date> <time> .
Le dernier succès s’est produit à ( jamais)| <date>.
3. REPADMIN.EXE signale que la dernière tentative de réplication a échoué avec l’état 1127
Les commandes REPADMIN qui mentionnent généralement l’état 1127 sont les suivantes :
REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL
4. Commande « répliquer maintenant » dans les sites et services Active Directory (DSSITE). MSC) échoue
avec l’erreur à l’écran « Lors de l’accès au disque dur, une opération de disque a échoué même après des
tentatives »
Titre de la boîte de dialogue : répliquer maintenant

Texte du message : l’erreur suivante s’est produite lors de la tentative de synchronisation du contexte
d’attribution de noms à <DNS name of directory partition> partir du contrôleur de domaine <source
DC>
vers le contrôleur de domaine <destination DC> :
Lors de l’accès au disque dur, une opération de disque a échoué même après des tentatives.
Cette opération ne se poursuit pas.
5. Les événements dans le journal des événements des services d’annuaire mentionnent l’état d’erreur 1127
Les événements qui mentionnent généralement l’état 1127 sont les suivants :
SO URC E ET ID D’ÉVÉN EM EN T C H A ÎN E DE M ESSA GE
KCC 1926 NTDS Échec de la tentative d’établissement d’un lien de

réplication vers une partition de répertoire en lecture
seule avec les paramètres suivants
Réplication NTDS 1084 Événement interne : Active Directory n’a pas pu mettre à
jour l’objet suivant avec les modifications reçues du
contrôleur de domaine source suivant. Cela est dû au fait
qu’une erreur s’est produite lors de l’application des
modifications apportées à Active Directory sur le
Réplication NTDS 1699 Le contrôleur de domaine local n’a pas pu récupérer les
modifications demandées pour la partition d’annuaire
suivante. Par conséquent, il n’a pas pu envoyer les
demandes de modification au contrôleur de domaine à
l’adresse réseau suivante.
Réplication NTDS 2108 Cet événement contient DES PROCÉDURES DE

RÉPARATION pour l’événement 1084 précédemment
enregistré. Ce message indique un problème spécifique
avec la cohérence de la base de données Active Directory
sur cette destination de réplication. Une erreur de base
de données s’est produite lors de l’application de
modifications répliquées à l’objet suivant. La base de
données avait un contenu inattendu, ce qui empêchait la
modification d’être réalisée.
6. L’événement de réplication NTDS 2108 peut être consigné dans le journal des événements des services
d’annuaire en fonction de l’erreur d’objet, de dc source et de jet qui déclenche la journalisation de l’état
1127 dans les erreurs à l’écran, les événements consignés et la sortie de l’outil de diagnostic.
Les erreurs Jet connues pour apparaître dans l’événement de réplication NTDS 2108 avec l’état 1127
incluent, mais ne sont pas limitées à :
JET ERRO R ( DÉC IM A L ) ERREUR SY M B O L IQ UE C H A ÎN E D’ERREUR
-510 JET_errLogWriteFail Échec de l’écriture dans le fichier

journal
-1018 JET_errReadVerifyFailure Erreur checksum sur une page de

base de données
-1019 JET_errPageNotInitialized Page de base de données vide
-1021 JET_errDiskReadVerificationFailure Le système d’exploitation

ERROR_CRC à partir des IO de
fichier
-1022 JET_errDiskIO Erreur d’IO de disque
-1605 JET_errKeyDuplicate Clé en double non illégale
7. Les événements ISAM NTDS peuvent être enregistrés dans le journal des événements des services
d’annuaire indiquant l’existence d’erreurs de jet liées à l’état 1127 apparaissant dans d’autres erreurs à
l’écran, événements journalisé et sortie de l’outil de diagnostic
SO URC E DE L’ÉVÉN EM EN T + ID D’ÉVÉN EM EN T T EXT E DE L’ÉVÉN EM EN T
ISAM NTDS 474 Page de base de données lue à partir du fichier au

décalage ( ) pour ( ) échec de vérification de la vérification
d’une insalurance de la base de contrôle de
<drive:\path\ntds.dit> <decimal offset> <hex offset>
<decimal page size> <hex page size> page.... L’opération
de lecture échouera avec une <decimal jet error> erreur
( <hex jet error> ). ). Si cette condition persiste, restituer
la base de données à partir d’une sauvegarde
précédente. Ce problème est probablement dû à un
matériel défectueux. Contactez votre fournisseur de
matériel pour obtenir de l’aide supplémentaire pour
NTDS ISAM 475 Page de base de données lue à partir du fichier au

décalage ( ) pour ( ) échec de vérification d’un numéro
<drive:\path\ntds.dit> <decimal offset> de <hex offset>
<decimal page size> <hex page size> page. ...
L’opération de lecture échouera avec une <decimal jet
error> erreur ( <hex jet error> ). ). Si cette condition
persiste, restituer la base de données à partir d’une
sauvegarde précédente. Ce problème est probablement
dû à un matériel défectueux. Contactez votre fournisseur
de matériel pour obtenir de l’aide supplémentaire pour
Cause
Active Directory ne peut pas écrire dans la base de données ou les fichiers journaux Active Directory. Les causes
premières sont les suivantes :
1. Le logiciel sur l’ordinateur local interfère avec la capacité d’Active Directory à écrire des modifications dans la
base de données Active Directory et/ou les fichiers journaux
2. Il existe un défaut dans le sous-système de disque, y compris le contrôleur de carte mère/pilote, le
microprogramme, le pilote, les lecteurs physiques.
Résolution
1. Rechercher les événements de réplication NTDS 1084 dans le journal des événements des
ser vices d’annuaire
Pour les DCS qui enregistrent l’état 1127, ouvrez le journal des événements du service d’annuaire et
concentrez-vous sur l’événement de réplication NTDS 1084.
L’événement de réplication NTDS 1084 indique qu’Active Directory n’a pas pu écrire de mises à jour dans
un objet dans sa copie locale d’Active Directory.
Les métadonnées de l’événement 1084 identifient (1.) le chemin d’accès DN (et donc la partition hôte des
objets) qui n’a pas pu être mis à jour, (2.) l’objectGUID pour l’objet en question et (3.) l’enregistrement
CNAME complet du DC source qui envoie la mise à jour
2. Recherchez l’événement de réplication NTDS 2108 journalisé immédiatement après chaque
événement NTDS Replication 1084 et identifiez l’erreur de jet consignée dans l’événement
2108.
L’événement de réplication NTDS 2108 est l'« action de l’utilisateur » pour l’événement NTDS Replication
1084.
Pour chaque événement de réplication NTDS 1084 enregistré, il doit y avoir un événement de réplication
NTDS 2108 correspondant consigné dans le journal des événements des services d’annuaire qui
mentionne (1.) le même chemin d’accès DN d’objet et (2.) objectguid et (3.) source DC enregistrés dans
l’événement NTDS Replication 1084 précédent et une erreur de jet qui définit /définit la cause et votre
plan de récupération pour résoudre la condition d’erreur.
3. Exécutez le plan d’action pour l’erreur Jet consignée dans votre événement de réplication
NTDS 2108 :
Si l’erreur Jet consignée dans vos événements de réplication NTDS est répertoriée dans le tableau ci-
dessous, exécutez l’action de l’utilisateur, sinon, passez à l’étape #4 :
ERREUR SY M B O L IQ UE + C H A ÎN E
JET ERRO R ( DÉC IM A L ) D’ERREUR A C T IO N DE L’UT IL ISAT EUR
-510 JET_errLogWriteFail / Un échec d’écriture du journal s’est

Échec de l’écriture dans le fichier produit sur le dc de destination.
journal
Vérifiez l’état du disque, de la
partition et du système de fichiers
sur le dc de destination.
Recherchez les logiciels qui peuvent

créer des verrous sur les fichiers
journaux Active Directory tels que
les logiciels antivirus sur le dc de
destination.
Voir si le problème persiste après le

redémarrage ou essayer le
démarrage
Méthode 1 : arrêter les services qui

créent des verrous sur les fichiers
dans le système de fichiers et se
concentrent spécifiquement sur les
logiciels antivirus.
Méthode 2 : appuyez sur F8

pendant le démarrage du système
d’exploitation et choisissez « Coffre
mode avec mise en réseau ».
Méthode 3 : désactiver les services

tiers non liés au démarrage.
Redémarrez.
Windows touche + R -> MSCONFIG

-> Services - > masquer tout
Microsoft
Services : > désactiver la case à
cocher pour les services tiers
Windows + R -> MSCONFIG ->

Onglet Démarrage - masquer >
Microsoft
Services - > cliquez sur « Désactiver
tout »
-1018 JET_errReadVerifyFailure / La DB est endommagée

Erreur checksum sur une page de
base de données Erreur due à une défaillance
matérielle.
Évaluez la pile de disques, y compris

la carte mère/contrôleur, le
microprogramme, les câbles de
connexion et les lecteurs physiques
et contactez les fournisseurs
concernés pour connaître les
problèmes connus. Comparez la
configuration actuelle à la
configuration de référence des
fournisseurs.
Évaluez si le problème peut être

résolu par les dernières mises à jour
JET ERRO R ( DÉC IM A L ) D’ERREUR du
A C Tmicroprogramme
IO N DE L’UT IL ISATouEUR
s’il a été
déclenché par la mise à jour récente
du microprogramme.
Si certains DCS journalisation -

1018s alors que d’autres DCS dans
le même environnement ne le sont
pas, recherchez les différences dans
la configuration matérielle.
Les bases de données consignant

cette erreur ne peuvent pas être
récupérées ou réparées par des
vérifications d’intégrité ou une
analyse sémantique de base de
données dans NTDSUTIL ou
ESENTUTL.
La défragmentation hors connexion

risque de résoudre le problème dans
le cas peu probable où ce problème
est dû à un problème de cohérence
d’index.
Essayez une défragmentation hors

connexion, sinon, restituer une
sauvegarde de l’état système qui
pré-date l’altération, OU forcer
l’rétrogradation, effectuer un
nettoyage complet des
métadonnées et promouvoir à
nouveau. Si l’erreur -1018 s’affiche,
répétez l’erreur jusqu’à ce que la
cause première matérielle soit
résolue.
Un client a signalé une erreur de jet

-1018s sur des DCS virtualisés
s’exécutant sur le même hôte virtuel
uniquement sur des ordinateurs
utilisant un contrôleur raid à bord. À
l’heure actuelle, l’UPS ne dispose pas
d’une puissance suffisante pour les
contrôleurs raid à bord pour valider
les modifications apportées au
disque suite à une perte
d’alimentation électrique. La solution
de contournement était de
configurer le logiciel UPS pour
arrêter les invités virtualisés en cas
de perte d’alimentation électrique.
Les serveurs avec des contrôleurs
raid dédiés (pas à bord) avec leurs
propres sauvegardes de batterie
n’ont pas connu l’erreur de jet -
1018.
-1019 JET_errPageNotInitialized / Semblable à l’erreur -1018, mais

Page de base de données vide causée par un purge de page perdu.
Une perte de purge peut

représenter une modification
critique du nom de l’usn. L’échec
d’une application identique à la dc
locale ou aux partenaires de
réplication transitive peut être
dangereux lorsqu’il existe un seul
chemin de réplication.
Déployer le système d’exploitation

sur le matériel de classe serveur et
les composants du sous-système de
disque
Installez UPS sur l’ordinateur hôte.
Installez le contrôleur de disque

avec la sauvegarde de la batterie de
l’appareil.
Désactivez le cache
d’écriture/écriture sur le contrôleur
de lecteur.
Évitez de placer NTDS. Fichiers DIT

et LOG sur les lecteurs IDE
Les bases de données consignant

cette erreur ne peuvent pas être
récupérées ou réparées par des
vérifications d’intégrité ou une
analyse sémantique de base de
données dans NTDSUTIL ou
ESENTUTL.
Les défragmentations hors

connexion peuvent résoudre le
problème dans le cas peu probable
où ce problème est dû à un
problème de cohérence d’index.
Essayez une défragmentation hors

connexion, sinon, restituer une
sauvegarde de l’état système qui
pré-date l’altération, OU forcer
l’rétrogradation, effectuer un
nettoyage complet des
métadonnées et promouvoir à
nouveau. Répétez jusqu’à ce que la
cause première matérielle soit
résolue.
-1021 JET_errDiskReadVerificationFailure Jet error -1021 is new to Windows

/Le système d’exploitation renvoyé Server 2008 R2.
ERROR_CRC à partir d’une IO de
fichier Les systèmes d Windows server
2008 R2 pré-opérationnels
retournent -1022 dans ce cas.
-1021 identifie qu’une erreur -1018

s’est produite au niveau du disque.
Restated, -1021 indique qu’un
lecteur de disque a renvoyé une
erreur de somme de vérification
erronée et qu’il s’agit de la source
spécifique du problème dans la pile
de disques.
Le problème peut être dû à des

blocs de disque dur dont le disque
dur peut assurer le suivi.
La rétrogradation et la promotion
du contrôleur de domaine peuvent
déclencher le stockage des données
sur des blocs sains.
-1022 JET_errDiskIO/Erreur d’O disque Erreur de disque générique
Les erreurs d’IO de disque signifient

que le système d’exploitation a
rencontré une erreur non spécifique
d’accès au disque. Cette erreur peut
être consignée lorsque les
contrôleurs retournent des erreurs
génériques telles que « l’appareil ne
fonctionne pas ». Certains disques
et versions de jet retournent cette
erreur pour les problèmes CRC.
Vérifiez la pile de pilotes entière.
-1605 JET_errKeyDuplicate / Clé en double Erreur ponctuelle.

non illégale Rétrograder et reomote.
Peut être causée par une altération
de l’index.
Exécutez l’analyse sémantique de
base de données NTDUSITL. S’il
n’est toujours pas résolu, effectuez
une défragmentation hors
connexion.
4. Si l’erreur Jet dans l’événement de réplication NTDS ne se trouve PAS dans le tableau ci-
dessus, validez la pile de base de données Jet ver ticale
Si l’événement 2108 enregistre une erreur de jet non mentionnée dans le tableau, utilisez l’utilitaire de
recherche de code d’erreur Microsoft Exchange Server pour résoudre l’erreur de jet sur sa chaîne d’erreur
symbolique et conviviale à l’aide de la syntaxe « err <jet error> ». Il est essentiel d’ajouter le caractère de
préfixe « - » principal lors de la résolution des erreurs de jet à l’aide ERR.EXE. (par exemple, « c: \>err -
1018 »).
Le texte du message d’événement dans l’événement de réplication NTDS 2108 contient une action
utilisateur partielle pour l’événement NTDS Replication 1084.
L’action utilisateur de réplication NTDS 2108 est documentée dans l’article de la base de données MSKB
lié 837932. Si l’action de l’utilisateur pour votre événement n’est pas mentionnée dans le tableau ci-
dessus, exécutez une version modifiée du plan d’action dans MSKB 837932 en validant la pile de base de
données à jet verticale à partir du bas vers le haut ( jusqu’à la couche suivante uniquement lorsque la
couche sous-jacente est « bonne ») comme vous le faites avec TCP.
L AY ER C O M M A N DE N T DSUT IL C O M M A N DE ESEN T T UL
(1.) Cohérence physique pas d’équivalent ESENTUTL /K
(2.) Cohérence logique ESE INTÉGRITÉ DES FICHIERS NTDSUTIL ESENTUTL /G
(3.) Cohérence logique de NTDSUTIL - Analyse >base de aucun équivalent pour SDA
l’application données sémantique
+ +
NTDSUTIL -> défragmentation hors ESENTUTL /D

connexion
Résolution de l’erreur de réplication AD 8240 : il
n’existe aucun objet de ce type sur le serveur
Cet article décrit les symptômes, la cause et la résolution des opérations AD qui échouent avec l’erreur Win32
8240 : « Il n’existe aucun objet de ce type sur le serveur. »
NOTE
Accueil des utilisateurs : Cet article est destiné uniquement aux agents de support technique et aux professionnels de
l’informatique. Si vous recherchez de l’aide sur un problème, demandez à l’CommunityMicrosoft.
Symptômes
Symptôme 1
Sortie de la Repadmin /ShowReps commande :
SiteName \ DCName via RPC

objectGuid: <GUID>
Last attempt @ <Time> failed, result 8240:
Il n’existe aucun objet de ce type sur le serveur.
Dernière réussite @ ( jamais).
Symptôme 2
Lorsque vous essayez de forcer la réplication dans la console sites et services Active Directory (dssite.msc) à
l’aide de l’option Répliquer maintenant, vous recevez le message d’erreur suivant :
L’erreur suivante s’est produite lors de la tentative de synchronisation du contexte d’attribution de noms du
contrôleur de <Naming Context> domaine au contrôleur de domaine <Source-DC-Name> <Destination-
DC-Name> :
Il n’existe aucun objet de ce type sur le serveur. Cette opération ne se poursuit pas.
Symptôme 3
Lorsque vous essayez de supprimer Active Directory d’un contrôleur de domaine, vous recevez le message
d’erreur suivant dans l’Assistant Installation d’Active Directory :
Active Directory n’a pas pu transférer les données restantes dans la partition d’annuaire <Naming-
Contentxt> vers le contrôleur de domaine . <Domain-Controller> » Il n’existe aucun objet de ce type sur le
serveur. »
Symptôme 4
Vous recevez l’événement général NTDS 1126 dans le service d’annuaire sur le contrôleur de domaine avec
l’erreur 8240 :
Source de l’événement : NTDS General
Catégorie d’événement : catalogue global
Date : <DateTime>
Heure : <DateTime>
Utilisateur : NT AUTHORITY \ ANONYMOUS LOGON
Description :
Active Directory n’a pas pu établir de connexion avec le catalogue global.
Valeur d’erreur :
8240 Il n’existe aucun objet de ce type sur le serveur.
ID interne :
3200ba0
Cause
L’erreur 8240 (0x2030) signifie ERROR_DS_NO_SUCH_OBJECT. Cela indique que l’objet spécifique n’a pas pu
être trouvé dans le répertoire. Cette erreur peut se rencontrer dans les deux situations suivantes.
Situation 1 : pendant la réplication AD
Lorsqu’une modification se produit sur un objet dans Active Directory sur le contrôleur de domaine source, le
contrôleur de domaine source propage cette modification à d’autres contrôleurs de domaine en notifiant ses
partenaires de réplication pour récupérer cette modification. Les contrôleurs de domaine de destination tirent la
modification du contrôleur de domaine source lorsqu’ils reçoivent la notification de modification. Une fois la
modification récupérée, les contrôleurs de domaine de destination tentent de les transposer dans la base de
données locale.
Le contrôleur de domaine de destination doit rechercher l’objet modifié dans la base de données locale afin que
la modification puisse être appliquée à cet objet. Si l’objet cible ne peut pas être localisé pour une raison
quelconque, Active Directory signale l’erreur 8240.
Cette erreur peut être observée dans les situations suivantes :
Lorsqu’une modification s’est produite sur un objet sur le contrôleur de domaine source, mais que cet objet a
été nettoyé par le processus de nettoyage de la garbage-collection
Lorsque la réplication AD récupère après un échec pendant une durée supérieure à la durée de vie de
tombstone (TSL), il se peut que la suppression ne soit pas propagée avant que la tombestone ne soit
nettoyée
Lorsque Le contrôleur de domaine d’origine des changements a supprimé Active Directory avant que le
contrôleur de domaine ait la possibilité de propager la suppression à d’autres contrôleurs de domaine qui
hébergent une partition accessible en ligne pour ce domaine et que la modification est répliquée dans le
catalogue global
Situation 2 : 8240 signalés dans l’événement 1126 (NTDS )
Le contrôleur de domaine tente de localiser les catalogues globaux pour ses fonctionnalités, telles que la
recherche d’appartenance à un groupe universel. Si le système ne peut pas localiser un contrôleur de domaine
disponible, l’événement 1126 est signalé avec l’erreur 8240 dans le journal des événements NTDS.
Résolution
Situation 1 : pendant la réplication AD
Pour résoudre ce problème, procédez comme suit :
1. Déterminez le contrôleur de domaine problématique qui possède l’objet incohérent. Cette erreur signifie
que le contrôleur de domaine local trouve qu’un objet incohérent existe dans son partenaire entrant
(pour la connexion de réplication spécifique), mais pas dans la base de données AD locale.
2. Déterminez si vous souhaitez supprimer les objets ou laisser ces objets tels qu’ils sont, comme suit :
Si vous souhaitez supprimer les objets, vous pouvez utiliser la commande Repadmin.exe avec le
commutateur Remove DomainObjects pour supprimer ces objets incohérents du contrôleur de
domaine source. Pour plus d’informations, voir le site web Microsoft TechNet suivant :
Utiliser repadmin pour supprimer les objets en attente
NOTE
Pour une partition en lecture seule, vous devez utiliser la Repadmin /Rehost commande.
Si vous souhaitez conserver ces objets, vous pouvez créer les objets suivants sur le contrôleur de
domaine de destination :
Sous-clé : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Nom de la valeur : cohérence de réplication stricte
Type de valeur : REG_DWORD
Données de valeur : 0
Nom de la valeur : autoriser la réplication avec des partenaires non fiables et endommagés
Nom de la valeur : corriger l’objet manquant
NOTE
Vous devez être prudent dans un environnement de grande taille qui contient de nombreux contrôleurs
de domaine, car la propagation de ces objets incohérents peut entraîner le signalement de 8 240 erreurs
par de plus en plus de contrôleurs de domaine jusqu’à ce que la propagation soit terminée.
Une autre option consiste à supprimer de force Active Directory du contrôleur de domaine qui
contient les objets incohérents. Pour cela, procédez comme suit :
a. Suppression forcée d’Active Directory : Assistant Installation d’Active Directory (Dcpromo.exe)
/forceremoval.
b. Nettoyez les métadonnées pour le contrôleur de domaine en suivant les étapes de l’article
suivant de la Base de connaissances Microsoft : 216498 Comment supprimer des données dans
Active Directory après une rétrogradation de contrôleur de domaine infructueuse
c. Reomote le contrôleur de domaine à l’aide Dcpromo.exe.
Situation 2 : 8240 signalés dans l’événement 1126 (NTDS )
Pour l’erreur qui indique que gc n’est pas disponible, nous pouvons généralement suivre le processus
d’emplacement GC à vérifier. Pour cela, procédez comme suit :
1. Vérifiez s’il existe un catalogue global spécifié dans la forêt. Si ce n’est pas le cas, configurez un gc.
NOTE
Une fois que vous avez marqué un contrôleur de domaine comme GC, le KCC peut prendre du temps pour
calculer une nouvelle topologie de réplication, créer le catalogue global et l’annonce de gc prêt. La durée dépend
de la planification de la réplication, du temps utilisé pour répliquer les NCS en lecture seule requises et de
l’intervalle d’actvitie du KCC.
2. Vérifiez si vous pouvez obtenir un contrôleur de domaine à partir du DNS via la commande lTest.exe
/DnsGetDC: <DomainName> /GC /Force. Si vous ne pouvez pas enregistrer gc dans DNS, prenez les
deux mesures suivantes :
Annonce gc sur les GCs existants : utilisez ldp.exe se connecter à GC pour vérifier si la valeur de
isGlobalCatalogReady est définie sur true .
Vérifiez l’inscription DNS : netdiag /fix.
3. Vérifiez si vous pouvez vous connecter au GC via TCP 3268 via ldp.exe.
910204 résolution des problèmes liés à la promotion d’un contrôleur de domaine vers un serveur de catalogue
global
Erreur 8409 et échec de la réplication AD après la
restauration ou la désinsplication des objets AD
dans Windows Server 2016
Cet article fournit une solution à une erreur 8409 après la restauration ou la désdelete d’objets AD.
Symptômes
Supposons que vous disposez d’une forêt Active Directory Windows des contrôleurs de domaine dans Windows
Server 2016, et que la fonctionnalité facultative de la Corbeille n’est pas activée. Supposons également que vous
restituer un objet supprimé via une opération de restauration faisant autorité NTDSUTIL, ou que vous l’avez
annulé par le biais d’une commande LDAP ou d’un outil de récupération commerciale.
Une fois la mise à jour répliquée, la réplication Active Directory échoue et renvoie l’erreur 8409.
NOTE
L’échec se produit à chaque tentative de réplication pour le contexte d’attribution de noms affecté pour tous les
partenaires entrants. Toutefois, l’échec cesse de se produire après plusieurs heures.
En outre, les événements suivants sont consignés dans le journal des événements Windows NT Directory
Services (NTDS) sur le contrôleur de domaine dans Windows Server 2016 :

Description :
Erreur interne : l’opération sur l’objet a échoué.
Valeur d’erreur :
5 000020D9 : SvcErr : DSID-030F2534, problème 5001 (OCCUPÉ), données 0
Description :
Événement interne : Les services de domaine Active Directory n’ont pas pu mettre à jour l’objet suivant avec
les modifications reçues du service d’annuaire source suivant. Cela est dû au fait qu’une erreur s’est produite
lors de l’application des modifications apportées aux services de domaine Active Directory sur le service
d’annuaire.
Objet :
CN=user,OU=users,DC=contoso,DC=com
GUID d’objet : GUID
Service d’annuaire source :
GUID._msdcs.contoso.com
Redémarrez l’ordinateur local si cette condition semble être liée à de faibles ressources système (par
Valeur d’erreur :
8409 Une erreur de base de données s’est produite.
Description :
Cet événement contient DES PROCÉDURES DE RÉPARATION pour l’événement 1084 qui a été
précédemment enregistré. Ce message indique un problème spécifique avec la cohérence de la base de
données des services de domaine Active Directory sur cette destination de réplication. Une erreur de base
de données s’est produite lors de l’application de modifications répliquées à l’objet suivant. La base de
données avait un contenu inattendu, ce qui empêchait la modification d’être réalisée.
Objet :
CN=user,OU=users,DC=contoso,DC=com
GUID d’objet : GUID
GUID._msdcs.contoso.com
...
Valeur d’erreur principale :
8409 Une erreur de base de données s’est produite.
Valeur d’erreur secondaire :
0 L’opération s’est terminée correctement.
Cause
Lorsque NTDS est démarré dans Windows Server 2008 R2 ou une version ultérieure, DS démarre une tâche
interne pour vérifier tous les NCs accessibles en ligne pour savoir s’il est nécessaire d’affecter une valeur true à
l’attribut IsRecycled des objets supprimés.
Tant que cette tâche n’est pas terminée, l’état de la fonctionnalité facultative corbeille est désactivé. Dans cet état,
le moteur de réplication n’autorise pas la suppression ou la restauration d’objets Active Directory. Par
conséquent, cela n’interagit pas avec l’ajout de l’attribut isRecycled.
Cette tâche est terminée en quelques secondes si les objets ont déjà la valeur d’attribut TRUE . Dans Windows
Server 2016, la tâche est différée pendant un démarrage afin d’améliorer le temps de démarrage de DS, et elle
est reprogrammée pour commencer six heures plus tard. Par conséquent, vous ne pouvez répliquer aucun
processus de restauration d’objet AD pendant les six premières heures de temps d’arrêt des DS.
La journalisation des diagnostics NTDS pour six garbage collection au niveau 2 vous permettrait de voir
l’événement « 2406 » qui indique le début de la tâche et l’événement « 2405 » qui indique la fin de la tâche.
Si la réplication AD a la priorité la plus élevée, vous pouvez supprimer à nouveau les objets, puis les restaurer
ultérieurement. Sinon, vous pouvez attendre six heures jusqu’à ce que la tâche soit terminée. Si vous redémarrez
le contrôleur de domaine, vous démarrez un autre intervalle de six heures avec ce problème.
Résolution
Pour résoudre ce problème, activez la fonctionnalité facultative Corbeille pour permettre la fin des opérations de
restauration ou de restauration. Après cela, aucune tâche démarrée ne désactive la fonctionnalité facultative.
Lorsque le service d’annuaire démarre, il suit la progression de la tâche par le biais d’événements enregistrés
dans le journal des événements NTDS. Les événements de gestion de la désactivation de la fonctionnalité
facultative de la Corbeille sont les suivants :
Désactivation de l’état :
Catégorie de tâche : configuration interne
Niveau : Informations
Description :
Ce serveur des services de domaine Active Directory désactive la prise en charge de la fonctionnalité
facultative « Fonctionnalité de corbeille ».
Description :
Ce serveur des services de domaine Active Directory désactive la Corbeille. Les objets supprimés ne peuvent
pas être supprimés pour le moment.
État désactivé :
Description :
Ce serveur des services de domaine Active Directory ne prend pas en charge la fonctionnalité facultative «
Corbeille ».
Description :
Ce serveur des services de domaine Active Directory ne prend pas en charge la Corbeille. Toutefois,
lorsqu’un objet n’est pas supprimé, certains attributs de cet objet peuvent être perdus. En outre, les attributs
d’autres objets qui font référence à l’objet non supprimé peuvent également être perdus.
La réplication AD ne fonctionne pas avec
l’événement 1865 enregistré
Cet article permet de résoudre un problème dans lequel la réplication Active Directory ne fonctionne pas et les
ID d’événement 1865 et 1311 sont enregistrés.
Symptômes
Vous avez plusieurs sites dans la forêt. Sur certains sites, vous constatez que la réplication AD ne fonctionne pas.
Sur les Inter-Site de domaine ISTG (Topology Generator), les événements suivants sont enregistrés toutes les 15
minutes.

Source de l’événement : KCC NTDS
Catégorie d’événement : Vérification de la cohérence des connaissances
Date : <date>
Heure : <time>
Utilisateur : NT AUTHORITY\ANONYMOUS LOGON
Ordinateur : <computername>
Description :
Le contrôle de cohérence des connaissances (KCC) n’a pas pu former une topologie de réseau
d’arborescence complète. Par conséquent, la liste de sites suivante n’est pas accessible à partir du site local.
Sites : CN= <sitename> ,CN=Sites,CN=Configuration,DC= <domain> ,DC=com
Date : <date>
Heure : <time>
Description :
Le contrôle de cohérence des connaissances (KCC) a détecté des problèmes avec la partition d’annuaire
suivante.
CN=Configuration,DC= <domain> ,DC=com
Cause
Cela peut se produire en cas de problèmes de connectivité entre les serveurs ISTG. Par exemple, si un pare-feu a
bloqué les ports, le problème se produit.
Résolution
Utilisez l’outil de portqry pour résoudre les problèmes de connectivité aux serveurs Bridgehead des sites
répertoriés dans l’événement 1865. Si les ports sont bloqués par le pare-feu, configurez le pare-feu pour ouvrir
les ports.
Community exclusion de responsabilité de contenu des solutions de contenu
Microsoft Corporation et/ou ses fournisseurs respectifs ne font aucune représentation de l’exactitude, de la
fiabilité ou de l’exactitude des informations et des graphiques associés contenus ici. Toutes ces informations et
graphiques associés sont fournis « en l’temps » sans garantie de quelque sorte que ce soit. Microsoft et/ou ses
fournisseurs respectifs délament toutes les garanties et conditions relatives à ces informations et graphiques
connexes, y compris toutes les garanties implicites et conditions de qualité, l’aptitude à un usage particulier,
l’effort de travail, le titre et la non-contrefaçon. Vous acceptez spécifiquement qu’en aucun cas Microsoft et/ou
ses fournisseurs ne soient responsables de tout dommage direct, indirect, indirect, accidentel, spécial,
conséquencenel, ou de tout dommage quelconque, y compris, sans limitation, de dommages en cas de perte
d’utilisation, de données ou de bénéfices, résultant ou de quelque manière que ce soit lié à l’utilisation ou à
l’impossibilité d’utiliser les informations et les graphiques associés contenus dans le présent présent, sur la base
d’un contrat, d’un délit, d’une négligence, d’une responsabilité stricte ou autrement, même si Microsoft ou l’un
de ses fournisseurs a été informé de la possibilité de dommages.
Résolution de l’erreur de réplication AD 1818 : l’appel
de procédure distante a été annulé
Cet article décrit un problème dans lequel les réplications Active Directory échouent avec l’erreur 1818 : l’appel
de procédure distante a été annulé (RPC_S_CALL_CANCELLED).
NOTE
l’informatique. Si vous recherchez de l’aide sur un problème, demandez à l’Community Microsoft.
Symptômes
Cet article décrit les symptômes, la cause et les étapes de résolution en cas d’échec de la réplication Active
Directory avec l’erreur 1818 : L’appel de procédure distante a été annulé (RPC_S_CALL_CANCELLED).
1. Les formats possibles pour l’erreur sont les suivants :
DÉC IM A L H EX SY M B O L IQ UE C H A ÎN E D’ERREUR
1818 0x71a RPC_S_CALL_CANCELLED L’appel de procédure

distante a été annulé.
2. Les événements suivants sont enregistrés
Réplication NTDS 1232 Active Directory a tenté d’effectuer

un appel de procédure distante
(RPC) vers le serveur suivant. L’appel
a été annulé et a été annulé.
Réplication NTDS 1188 Un thread dans Active Directory

attend la fin d’un RPC effectué sur le
contrôleur de domaine suivant.
Contrôleur de domaine :
b8b5a0e4-92d5-4a88-a601-
61971d7033af._msdcs.
Contoso.com
Opération :
obtenir des modifications
ID de thread :
448
Délai d’attente (minutes) :
5
Active Directory a tenté d’annuler
l’appel et de récupérer ce thread.
Si cette condition persiste,
redémarrez le contrôleur de
domaine.
1173 avec l’état d’erreur 1818 Événement interne : Active

Réplication NTDS Directory a rencontré l’exception
supplémentaire : 1818 ID interne :
5000ede
Réplication NTDS 1085 avec l’état d’erreur 1818 Événement interne : Active
Directory n’a pas pu synchroniser la
partition d’annuaire suivante avec le
contrôleur de domaine à l’adresse
réseau suivante.
Partition d’annuaire : <NC>
Adresse réseau : <GUID-based DC
name>
Si cette erreur persiste, le contrôleur
de cohérence des connaissances
reconfigure les liaisons de réplication
et contourne le contrôleur de
domaine.
Vérifiez que l’adresse réseau peut
être résolue avec une requête DNS.
Valeur d’erreur de données
supplémentaire : 1818 L’appel de
procédure distante a été annulé.
. Repadmin /showreps affiche le message d’erreur suivant
DC=Contoso,DC=com
<Sitename>\<DCname> via RPC DC
GUID <GUID> de l’objet DC : Dernière tentative @ 2009-11-25 10:56:55 a échoué, résultat 1818
(0x71a) : can’t retrieve message string 1818
(0x71a), erreur 1815. 823 échecs consécutifs. Dernière réussite @ ( jamais).
3. Repadmin /showrepsà partir du nom du contrôleur de domaine indique qu’il ne parvient pas à tirer le
<SiteName> nc du domaine, mais qu’il peut tirer tous les autres NCs
===================
<Sitename>\<DC name>
Options DC : IS_GC
Options du site : IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED
GUID d’objet DC : <GUID>
DC invocationID : <InvocationID>
==== INBOUNDBOUNDONS =====================================
DC=Contoso,DC=com
<Sitename>\<DCname> via RPC DC
GUID d’objet DC : <GUID>
Last attempt @ <DateTime> failed, result 1818 (0x71a) :
Can’t retrieve message string 1818 (0x71a), error 1815. 123 consécutifs
failure(s). Dernière réussite @ ( jamais).
4. DCPromo peut échouer lors de la promotion d’un nouveau contrôleur de domaine et l’erreur suivante
s’est produite sur l’interface graphique graphique DCPROMO.
Assistant Installation d’Active Directory.

L’opération a échoué car : Active Directory n’a pas pu répliquer la partition d’annuaire
CN=Configuration.... à partir du contrôleur de domaine distant « nom du serveur »
« L’appel de procédure distante a été annulé »
Les entrées suivantes seront enregistrées dans les journaux DCPROMO.
<DateTime> [INFO] EVENTLOG (informations) : NTDS General /Service Control : 1004

Les services de domaine Active Directory ont été arrêtés avec succès.
<DateTime> [INFO] NtdsInstall pour la <FQDN fo the domain> 1818 renvoyée
<DateTime> [INFO] DsRolepInstallDs renvoyé 1818
<DateTime> [ERROR] Échec de l’installation dans le service d’annuaire (1818)
<DateTime> [ERROR] Échec de DsRolepFinishSysVolPropagation (Abandon de la promotion) avec
8001
<DateTime> [INFO] Démarrage du service NETLOGON
<DateTime> [INFO] Configuration du service NETLOGON sur 2 renvoyé 0
<DateTime> [INFO] L’opération de contrôleur de domaine tentée est terminée
<DateTime> [INFO] DsRolepSetOperationDone renvoyé 0
5. Lors de la tentative de réhostance d’une partition sur le catalogue global
Échec de repadmin /rehost avec échec de DsReplicaAdd avec l’état

1818 (0x71a)>
DsReplicaAdd échoue avec l’état 1818 (0x71a)
Cause
Le problème se produit lorsque le dc de destination qui effectue la réplication entrante ne reçoit pas de
modifications de réplication dans le délai de secondes spécifié dans la clé de Registre « Délai d’avance de
réplication RPC ». Vous pouvez être le plus souvent face à ce problème dans l’une des situations suivantes :
Vous faites la promotion d’un nouveau contrôleur de domaine dans la forêt à l’aide de l’Assistant Installation
d’Active Directory (Dcpromo.exe).
Les contrôleurs de domaine existants répliquent à partir des contrôleurs de domaine source connectés sur
des liaisons réseau lentes.
La valeur par défaut pour le paramètre de Registre Délai d’accès minimum de réplication RPC sur Windows
2000 ordinateurs basés sur 2000 est de 45 minutes. La valeur par défaut pour le paramètre de Registre Délai
d’accès minimum de réplication RPC sur les ordinateurs basés sur Windows Server 2003 est de 5 minutes.
Lorsque vous avez mis à niveau le système d’exploitation de Windows 2000 vers Windows Server 2003, la
valeur du paramètre de Registre Délai d’accès au délai d’accès à la réplication RPC (mins) est modifiée de 45
minutes à 5 minutes. Si un contrôleur de domaine de destination qui effectue une réplication RPC ne reçoit pas
le package de réplication demandé dans le délai spécifié par le paramètre de Registre Délai d’heure de
réplication RPC (mins), le contrôleur de domaine de destination met fin à la connexion RPC avec le contrôleur de
domaine source non réactif et enregistre un événement d’avertissement.
Voici quelques causes racines spécifiques de la journalisation Active Directory
1818 \ 0x71a \ RPC_S_CALL_CANCELLED :
1. Un ancien pilote de carte d’interface réseau installé sur les contrôleurs de domaine peut entraîner l’échec de
certaines fonctionnalités réseau telles que SNP (Scalable Networking Pack)
2. La bande passante faible ou les paquets réseau diminuent entre les contrôleurs de domaine source et de
destination.
3. Périphérique réseau entre l’appareil source et le périphérique de destination qui dépose des paquets.
NOTE
Une insalubrement de vitesse et de duplex entre la NIC et le commutateur sur un contrôleur de domaine peut entraîner
l’abandon des images, des réinitialisations, des accusé de réception en double et des images retransmises.
Résolution
1. Augmenter le délai d’délai de réplication en ajoutant la touche RPC Replication Timeout (mins)
Démarrez l’Éditeur du Registre.

Recherchez la sous-clé de Registre suivante :
Cliquez avec le bouton droit sur Paramètres, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
Tapez rpc replication timeout (mins), puis appuyez sur Entrée pour nommer la nouvelle valeur.
Cliquez avec le bouton droit sur Délai d’application de la réplication RPC (min), puis cliquez sur
Modifier.
Dans la zone de données Valeur, tapez le nombre de minutes que vous souhaitez utiliser pour le
délai d’accès RPC pour la réplication Active Directory, puis cliquez sur OK.
Sur un ordinateur Windows Server 2003 qui fait partie d’un environnement Windows 2000 ou qui a été
mis à niveau à partir de Windows 2000 Server, vous pouvez définir cette valeur sur 45 minutes. Cette
valeur peut dépendre de votre configuration réseau et doit être ajustée en conséquence.
NOTE
Vous devez redémarrer l’ordinateur pour activer les modifications apportées au délai d’accès à la réplication RPC
(mins)
2. Mettre à jour les pilotes de carte réseau

Pour déterminer si un pilote de carte réseau mis à jour est disponible, contactez le fabricant de la carte
réseau ou le gestionnaire d’équipement d’origine (OEM) de l’ordinateur. Le pilote doit respecter la
spécification NDIS (Network Driver Interface Specification) 5.2 ou une version ultérieure de cette
spécification.
Pour désactiver manuellement le déchargement RSS et TCP, suivez les étapes suivantes :
Cliquez sur Démarrer, puis sur Exécuter, tapez regedit, puis cliquez sur OK.
Trouvez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Cliquez avec le bouton droit sur EnableTCPChimney, puis cliquez sur Modifier.
Dans la zone Données de la valeur, tapez 0, puis cliquez sur OK.
Cliquez avec le bouton droit sur EnableRSS, puis cliquez sur Modifier.
Cliquez avec le bouton droit sur EnableTCPA, puis cliquez sur Modifier.
Quittez l’Éditeur du Registre,
NOTE
Vous devez redémarrer l’ordinateur pour activer les modifications apportées à EnableTCPChimney.
3. Activez la détection pmTU Black Hole sur les hôtes basés Windows qui communiqueront sur une
connexion WAN. Procédez comme suit :
Démarrez l’Éditeur du Registre ( Regedit.exe ).
Localisez la clé suivante dans le Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters
Dans le menu Modifier, cliquez sur Ajouter une valeur, puis ajoutez la valeur de Registre suivante :
Nom de la valeur : EnablePMTUBHDetect

Valeur : 1
Redémarrer l’ordinateur
4. Vérifiez l’ordre de liaison réseau :

Pour configurer l’ordre de liaison réseau :
a. Fermez les programmes qui sont en cours d’exécution.
b. Cliquez avec le bouton droit sur Voisinage réseau, puis cliquez sur Propriétés.
c. Cliquez sur l’onglet Liaisons. Dans la zone Afficher les liaisons pour, cliquez sur Tous les services.
d. Double-cliquez sur chaque service répertorié pour le développer.
e. Sous chaque service, double-cliquez sur chaque protocole pour le développer.
f. Sous chaque protocole, il existe un certain nombre d’icônes de carte réseau. Cliquez sur l’icône de
votre carte réseau, puis cliquez sur Monter jusqu’à ce que la carte réseau se trouve en haut de la
liste. Laissez les entrées « Wrapper wan d’accès à distance » dans n’importe quel ordre sous la ou
les cartes réseau.
NOTE
Si vous avez plusieurs cartes réseau, placez la carte interne (avec l’adresse IP de protocole Internet 10.0.0.2
par défaut sur un réseau Small Business Server) en haut de l’ordre de liaison, avec la ou les cartes externes
directement sous la carte interne.
L’ordre final doit être similaire à :

[1] Carte réseau 1
[2] Carte réseau 2 (le cas présent)
[3] Wrapper wan d’accès à distance
.
.
.
[n] Wrapper wan d’accès à distance
g. Répétez l’étape 6 pour chaque service dans la boîte de dialogue.
h. Une fois que vous avez vérifié les paramètres de chaque service, cliquez sur Tous les protocoles
dans la zone Afficher les liaisons pour. L’entrée « Wrapper wan d’accès à distance » n’a pas de carte
réseau répertoriée. Ignorez cet élément. Répétez les étapes 4 à 6 pour chaque protocole restant.
i. Une fois que vous avez vérifié que les liaisons sont correctement définies pour tous les services et
protocoles, cliquez sur OK. Cela initialise la réabinage des services. Lorsque cela est terminé, vous
êtes invité à redémarrer l’ordinateur. Cliquez sur Oui.
Les modifications Active Directory ne sont pas répliquées
Comment résoudre l’erreur de réplication Active
Directory 5 dans Windows Server : l’accès est refusé
Cet article décrit les symptômes, la cause et la résolution des situations dans lesquelles la réplication Active
Directory échoue avec l’erreur 5 : l’accès est refusé.
Symptômes
Vous pouvez rencontrer un ou plusieurs des symptômes suivants lorsque les réplications Active Directory
échouent avec l’erreur 5.
Symptôme 1
LDcdiag.exe de ligne de commande indique que le test de réplication Active Directory échoue avec le code d’état
d’erreur (5). Le rapport ressemble à ce qui suit :
Serveur de test : Site_Name \ Destination_DC_Name

*Replications Check
[Vérification des réplications,Destination_DC_Name] Une tentative de réplication récente a échoué :
De Source_DC à Destination_DC
Contexte d’attribution de noms : Director y_Par tition_DN_Path
L’échec s’est produit à l’heure de la date .
Le dernier succès s’est produit à l’heure de la date .
Des échecs de nombre se sont produits depuis le dernier succès.
Symptôme 2
LDcdiag.exe de ligne de commande indique que la fonction DsBindWithSpnEx échoue avec l’erreur 5 en
exécutant la DCDIAG /test:CHECKSECURITYERROR commande.
Symptôme 3
LREPADMIN.exe de ligne de commande indique que la dernière tentative de réplication a échoué avec l’état 5.
Les commandes REPADMIN qui mentionnent fréquemment les cinq états sont les suivantes :
REPADMIN /KCC
REPADMIN /REPLICATE
REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL
Exemple de sortie de la REPADMIN /SHOWREPL commande suivante. Cette sortie montre la réplication entrante de
DC_2_Name à DC_1_Name avec l’erreur « Accès refusé ».
\ Site_Name DC_1_Name
Options DSA : IS_GC
GUID d’objet DSA : GUID
DSA invocationID: invocationID
==== INBOUNDONS========================================
DC= DomainName,DC =com
\ Site_Name DC_2_Name via RPC
GUID d’objet DSA : GUID
Last attempt @ Date Time failed, result 5(0x5) :
Last success @ Date Time .
Symptôme 4
Les événements NTDS KCC, NTDS General ou Microsoft-Windows-ActiveDirectory_DomainService ayant le
statut cinq sont enregistrés dans le journal des services d’annuaire dans l’Observateur d’événements.
Le tableau suivant récapitule les événements Active Directory qui mentionnent fréquemment l’état 8524.
RÉF ÉVÉN EM EN T SO URC E C H A ÎN E D’ÉVÉN EM EN T
1655 NTDS General Active Directory a tenté de

communiquer avec le catalogue global
suivant et les tentatives ont échoué.
1925 NTDS KCC La tentative d’établissement d’un lien

de réplication pour la partition de
répertoire accessible en texte suivante
a échoué.
1926 NTDS KCC La tentative d’établissement d’un lien

de réplication vers une partition de
répertoire en lecture seule avec les
paramètres suivants a échoué.
Symptôme 5
Lorsque vous cliquez avec le bouton droit sur l’objet de connexion à partir d’un contrôleur de domaine source
dans sites et services Active Directory, puis sélectionnez Répliquer maintenant, le processus échoue et vous
recevez l’erreur suivante :
Répliquer maintenant
L’erreur suivante s’est produite lors de la tentative de synchronisation du contexte d’attribution de noms
%director y par tition name % de Domain Controller Source DC vers domain controller destination DC :
l’accès est refusé.
L’opération ne se poursuit pas.
La capture d’écran suivante représente un exemple de l’erreur :

Utilisez l’outil de ligne de commande DCDIAG générique pour exécuter plusieurs tests. Utilisez l’outil en ligne de
commande DCDIAG /TEST:CheckSecurityErrors pour effectuer des tests spécifiques. (Ces tests incluent une
vérification d’inscription SPN.) Exécutez les tests pour résoudre les problèmes de réplication des opérations
Active Directory avec l’erreur 5 et l’erreur 8453. Toutefois, sachez que cet outil ne s’exécute pas dans le cadre de
l’exécution par défaut de DCDIAG.
Pour contourner ce problème, procédez comme suit :
1. À l’invite de commandes, exécutez DCDIAG sur le contrôleur de domaine de destination.
2. Exécutez DCDIAG /TEST:CheckSecurityError .
3. Exécutez NETDIAG.
4. Résolvez les erreurs identifiées par DCDIAG et NETDIAG.
5. Réessayez l’opération de réplication qui a échoué précédemment. Si les réplications continuent d’échouer,
consultez la section « Causes et solutions ».
Causes et solutions
Les causes suivantes peuvent entraîner l’erreur 5. Certaines d’entre elles ont des solutions.
Cause 1 : le paramètre RestrictRemoteClients dans le Registre a la valeur 2
Si les restrictions pour le paramètre de stratégie des clients RPC non authentifiés sont activées et sont définies
sur Authentifié sans exceptions, la valeur de Registre RestrictRemoteClients est définie sur la valeur 0x2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC dans la sous-clé de Registre.
Ce paramètre de stratégie permet uniquement aux clients d’appel de procédure distante (RPC) authentifiés de se
connecter aux serveurs RPC en cours d’exécution sur l’ordinateur sur lequel le paramètre de stratégie est
appliqué. Il n’autorise pas les exceptions. Si vous sélectionnez cette option, un système ne peut pas recevoir
d’appels anonymes distants à l’aide de RPC. Ce paramètre ne doit jamais être appliqué à un contrôleur de
domaine.
Solution
1. Désactivez les restrictions pour le paramètre de stratégie des clients RPC non authentifiés qui limite la
valeur de Registre RestrictRemoteClients à 2.
NOTE
Le paramètre de stratégie se trouve dans le chemin d’accès suivant : Configuration ordinateur\Modèles
d’administration\Système\Appel de procédure distante\Restrictions pour les clients RPC non authentifiés
2. Supprimez le paramètre de Registre RestrictRemoteClients, puis redémarrez.

Voir Restrictions pour les clients RPC non authentifiés : la stratégie de groupe qui place votre domaine en face.
Cause 2 : le paramètre CrashOnAuditFail dans le Registre du contrôleur de domaine de destination a la valeur
2
Une valeur CrashOnAduitFail de 2 est déclenchée si l’audit : arrêter immédiatement le système si le paramètre
de stratégie d’audit de sécurité dans la stratégie de groupe est activé et que le journal des événements de
sécurité local devient plein.
Les contrôleurs de domaine Active Directory sont particulièrement sujets aux journaux de sécurité à capacité
maximale lorsque l’audit est activé et que la taille du journal des événements de sécurité est limitée par les
événements Ne pas effacer les événements (effacer manuellement le journal) et Les effacer selon les options
requises dans l’Observateur d’événements ou leurs équivalents de stratégie de groupe.
Solution
IMPORTANT
1. Effacer le journal des événements de sécurité et l’enregistrer à un autre emplacement si nécessaire.
2. Réévaluez les contraintes de taille dans le journal des événements de sécurité. Cela inclut les paramètres basés sur une
stratégie.
3. Supprimez puis re-créez une entrée de Registre CrashOnAuditFail comme suit : sous-clé de Registre :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
Nom de la valeur : CrashOnAuditFail
4. Redémarrez le contrôleur de domaine de destination.
Cause 3 : Confiance non valide

Si la réplication Active Directory échoue entre les contrôleurs de domaine dans différents domaines, vous devez
vérifier l’état des relations d’confiance le long du chemin d’accès d’confiance.
Vous pouvez essayer le test De relation d’confiance NetDiag pour vérifier les trusts rompues.
LNetdiag.exe'utilitaire identifie les confiances rompues en affichant le texte suivant :
Test de relation d’confiance. . . . . . : Échec

Testez pour vous assurer que DomainSid du domaine « domainname » est correct.
[FATAL] Le canal sécurisé vers le domaine « domainname » est rompu.
[% code d’état variable %]
Par exemple, si vous avez une forêt multi-domaines qui contient un domaine racine ( Contoso.COM ), un domaine
enfant ( B.Contoso.COM ), un domaine petit-enfant ( C.B.Contoso.COM ) et un domaine d’arborescence dans la
même forêt ( Fabrikam.COM ) et si la réplication échoue entre les contrôleurs de domaine dans le domaine petit-
enfant ( C.B.Contoso.COM ) et le domaine d’arborescence ( Fabrikam.COM) , B.Contoso.COM``C.B.Contoso.COM vous
devez vérifier l’état d’confiance entre et, B.Contoso.COM Contoso.COM entre et, Contoso.COM Fabrikam.COM enfin,
entre et .
S’il existe une relation de raccourci entre les domaines de destination, vous n’avez pas besoin de valider la
chaîne de chemin d’accès d’confiance. Au lieu de cela, vous devez valider l’confiance de raccourci entre le
domaine de destination et le domaine source.
Recherchez les modifications récentes apportées au mot de passe de l’trust en exécutant la commande suivante :
Repadmin /showobjmeta * <DN path for TDO in question>

Vérifiez que le contrôleur de domaine de destination est transitifment entrant réplication de la partition de
répertoire de domaine accessible en writable où les modifications de mot de passe d’confiance peuvent prendre
effet.
Les commandes de réinitialisation des confiances à partir du domaine racine PDC sont les suivantes :
netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT /PasswordO:* /Reset
/TwoWay
Les commandes de réinitialisation des confiances à partir du domaine enfant PDC sont les suivantes :
netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root /PasswordD:* /UserO:Child /PasswordO:* /Reset
/TwoWay
Cause 4 : décalage de temps excessif

Les paramètres de stratégie Kerberos dans la stratégie de domaine par défaut permettent une différence de cinq
minutes dans le temps système (il s’agit de la valeur par défaut) entre les contrôleurs de domaine KDC et les
serveurs cibles Kerberos pour empêcher les attaques par relecture. Certaines documentations indiquent que
l’heure système du client et celle de la cible Kerberos doivent être dans les cinq minutes l’un de l’autre. D’autres
documents indiquent que, dans le contexte de l’authentification Kerberos, le temps qui est important est le delta
entre le KDC utilisé par l’appelant et l’heure sur la cible Kerberos. En outre, Kerberos ne se soucie pas si l’heure
système sur les contrôleurs de domaine appropriés correspond à l’heure actuelle. Il se soucie uniquement du
fait que la différence de temps relative entre le KDC et le contrôleur de domaine cible se trouve dans la durée
maximale que la stratégie Kerberos autorise. (La durée par défaut est de cinq minutes ou moins.)
Dans le cadre des opérations Active Directory, le serveur cible est le contrôleur de domaine source contacté par
le contrôleur de domaine de destination. Chaque contrôleur de domaine dans une forêt Active Directory qui
exécute actuellement le service KDC est un KDC potentiel. Par conséquent, vous devez prendre en compte la
précision du temps sur tous les autres contrôleurs de domaine par rapport au contrôleur de domaine source.
Cela inclut le temps sur le contrôleur de domaine de destination lui-même.
Vous pouvez utiliser les deux commandes suivantes pour vérifier la précision de l’heure :
DCDIAG /TEST:CheckSecurityError
W32TM /MONITOR
Vous trouverez un exemple de sortie de DCDIAG /TEST:CheckSecurityError dans la section « Plus d’informations
». Cet exemple montre une inclinaison excessive du temps sur les contrôleurs de domaine basés sur Windows
Server 2003 et Windows Server 2008 R2.
Recherchez les événements LSASRV 40960 sur le contrôleur de domaine de destination au moment de l’échec
de la demande de réplication. Recherchez les événements qui mentionnent un GUID dans l’enregistrement
CNAME du contrôleur de domaine source avec erreur étendue 0xc000133. Recherchez les événements qui
ressemblent à ce qui suit :
L’heure au niveau du contrôleur de domaine principal est différente de celle du contrôleur de domaine de
sauvegarde ou du serveur membre par trop grande quantité
Les suivis réseau qui capturent l’ordinateur de destination qui se connecte à un dossier partagé sur le contrôleur
de domaine source (ainsi que d’autres opérations) peuvent afficher l’erreur « Une erreur étendue s’est produite »
à l’écran, mais un suivi réseau affiche les éléments suivants :
-> KerberosV5 KerberosV5:TGS Request Realm: <- TGS request from source DC
<- Kerberosvs Kerberosvs:KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) <- Réponse TGS où «
KRB_AP_ERR_TKE_NYV
< - cartes sur « Ticket pas encore valide » < - map pas sur « Ticket pas encore valide »
La TKE_NYV indique que la plage de dates sur le ticket TGS est plus nouvelle que l’heure sur la cible. Cela
indique une inclinaison excessive du temps.
NOTE
W32TM /MONITOR vérifie le temps uniquement sur les contrôleurs de domaine dans le domaine des ordinateurs de
test. Vous devez donc l’exécuter dans chaque domaine et comparer le temps entre les domaines.
Lorsque la différence de temps est trop importante sur les contrôleurs de domaine de destination basés sur Windows
Server 2008 R2, la commande Répliquer maintenant dans DSSITE. Le MSC échoue avec l’erreur « Il existe une
différence d’heure et/ou de date entre le client et le serveur » à l’écran. Cette chaîne d’erreur est mie à l’erreur 1398
décimale ou 0x576 hexadécimale avec le nom ERROR_TIME_SKEW’erreur symbolique.
Pour plus d’informations, voir Setting Clock Synchronization Tolerance to Prevent Replay Attacks.
Cause 5 : le canal de sécurité ou le mot de passe ne sont pas valides sur le contrôleur de domaine source ou
de destination
Validez le canal de sécurité en exécutant l’une des commandes suivantes :
nltest /sc:query
netdom verify
Sous condition, réinitialisez le mot de passe du contrôleur de domaine de destination à l’aide de NETDOM
/RESETPWD.
Solution
1. Désactivez le service Centre de distribution de clés Kerberos (KDC) sur le contrôleur de domaine qui est
redémarré.
2. À partir de la console du contrôleur de domaine de destination, NETDOM RESETPWD exécutez cette
commande pour réinitialiser le mot de passe du contrôleur de domaine de destination comme suit :
c:\>netdom resetpwd /server: server_name /userd: domain_name\administrator /passwordd:

administrator_password
3. Assurez-vous que les KDCs probables et le contrôleur de domaine source (s’ils sont dans le même
domaine) répliquent les connaissances entrantes du nouveau mot de passe du contrôleur de domaine de
destination.
4. Redémarrez le contrôleur de domaine de destination pour mettre à jour les tickets Kerberos et réessayez
l’opération de réplication.
Découvrez comment utiliser Netdom.exe pour réinitialiser les mots de passe de compte d’ordinateur d’un
Cause 6 : le droit d’utilisateur « Accéder à cet ordinateur à partir du réseau » n’est pas accordé à un utilisateur
qui déclenche la réplication
Dans une installation par défaut de Windows, la stratégie de contrôleur de domaine par défaut est liée à l’unité
d’organisation (OU) du contrôleur de domaine. L’ou accorde l’accès à cet ordinateur à partir du droit utilisateur
réseau aux groupes de sécurité suivants :
ST RAT ÉGIE LO C A L E ST RAT ÉGIE DE C O N T RÔ L EUR DE DO M A IN E PA R DÉFA UT
Administrateurs Administrateurs
Utilisateurs authentifiés Utilisateurs authentifiés
Tout le monde Tout le monde
Enterprise de domaine Enterprise de domaine
[Accès pré-Windows 2000] Accès pré-Windows 2000 compatible
Si les opérations Active Directory échouent avec l’erreur 5, vous devez vérifier les points suivants :
Les groupes de sécurité du tableau se sont vus accorder l’accès à cet ordinateur à partir du droit utilisateur
réseau dans la stratégie du contrôleur de domaine par défaut.
Les comptes d’ordinateur du contrôleur de domaine se trouvent dans l’ou du contrôleur de domaine.
La stratégie du contrôleur de domaine par défaut est liée à l’organisation du contrôleur de domaine ou à
d’autres OUS qui hébergent des comptes d’ordinateur.
La stratégie de groupe est appliquée au contrôleur de domaine de destination qui enregistre actuellement
l’erreur 5.
Le refus d’accès à cet ordinateur à partir du droit d’utilisateur réseau est activé ou ne fait pas référence à des
groupes directs ou transitifs que le contexte de sécurité utilisé par le contrôleur de domaine ou le compte
d’utilisateur qui déclenche la réplication.
La priorité de la stratégie, l’héritage bloqué, le filtrage WMI (Microsoft Windows Management
Instrumentation), ou autres, n’empêchent pas le paramètre de stratégie de s’appliquer aux ordinateurs de rôle
de contrôleur de domaine.
NOTE
Les paramètres de stratégie peuvent être validés avec RSOP. Outil MSC. Toutefois, GPRESULT /Z est l’outil préféré, car il
est plus précis.
La stratégie locale est prioritaire sur la stratégie définie dans les sites, les domaines et l’ou.
À un moment, il était courant pour les administrateurs de supprimer les groupes « contrôleurs de domaine Enterprise
» et « Tout le monde » du paramètre de stratégie « Accéder à cet ordinateur à partir du réseau » dans la stratégie du
contrôleur de domaine par défaut. Toutefois, la suppression des deux groupes est fatale. Il n’y a aucune raison de
supprimer « contrôleurs de domaine Enterprise » de ce paramètre de stratégie, car seuls les contrôleurs de domaine
sont membres de ce groupe.
Cause 7 : Il existe une insématisation de signature SMB entre les contrôleurs de domaine source et de
destination
PA RA M ÈT RE DE ST RAT ÉGIE C H EM IN D’A C C ÈS DU REGIST RE
Client réseau Microsoft : communications avec signature HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanwork

numérique (si le serveur l’accepte) station\Parameters\Enablesecuritysignature
Client réseau Microsoft : communications avec signature HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanwork

numérique (toujours) station\Parameters\Requiresecuritysignature
Serveur réseau Microsoft : communications avec signature HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserv

numérique (si le serveur l’accepte) er\Parameters\Enablesecuritysignature
Serveur réseau Microsoft : communications avec signature HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserv

numérique (toujours) er\Parameters\Requiresecuritysignature
Vous devez vous concentrer sur les différences de signature SMB entre les contrôleurs de domaine source et de
destination. Les cas classiques impliquent un paramètre activé ou requis d’un côté, mais désactivé de l’autre.
Cause 8 : fragmentation de paquets Kerberos au format UDP
Les routeurs et commutateurs réseau peuvent fragmenter ou abandonner complètement des paquets réseau au
format UDP (User Datagram Protocol) de grande taille utilisés par Kerberos et les mécanismes d’extension pour
DNS (EDNS0). Les ordinateurs qui exécutent des familles de systèmes d’exploitation Windows 2000 Server ou
Windows Server 2003 sont particulièrement vulnérables à la fragmentation UDP sur les ordinateurs exécutant
Windows Server 2008 ou Windows Server 2008 R2.
Solution
1. À partir de la console du contrôleur de domaine de destination, ping le contrôleur de domaine source par
son nom d’ordinateur complet pour identifier le plus grand paquet pris en charge par l’itinéraire réseau.
Pour ce faire, exécutez la commande suivante :
c:\>Ping <Source_DC_hostname>.<Fully_Qualified_Computer_Name> -f -l 1472
2. Si le plus grand paquet non fragmenté est inférieur à 1 472 octets, essayez l’une des méthodes suivantes
(par ordre de préférence) :
Modifiez l’infrastructure réseau pour prendre correctement en charge les images UDP de grande taille.
Cela peut nécessiter une mise à niveau du microprogramme ou un changement de configuration sur
les routeurs, commutateurs ou pare-feu.
Définissez maxpacketsize (sur le contrôleur de domaine de destination) sur le plus grand paquet
identifié par la commande PING -f -l moins 8 octets pour prendre en compte l’en-tête TCP, puis
redémarrez le contrôleur de domaine modifié.
Définissez maxpacketsize (sur le contrôleur de domaine de destination) sur la valeur 1. Cela déclenche
l’authentification Kerberos pour utiliser un protocole TCP. Redémarrez le contrôleur de domaine
modifié pour que la modification prenne effet.
3. Réessayez l’opération Active Directory ayant échoué.
Cause 9 : la fonctionnalité Décharger l’envoi important est activée sur les cartes réseau
Solution
1. Sur le contrôleur de domaine de destination, ouvrez les propriétés de la carte réseau.
2. Cliquez sur le bouton Configurer.
3. Sélectionnez l’onglet Avancé .
4. Désactivez la propriété IPv4 Large Send Offload .
Cause 10 : domaine Kerberos non valide
Le domaine Kerberos n’est pas valide si une ou plusieurs des conditions suivantes sont vraies :
L’entrée de Registre KDCNames contient de manière incorrecte le nom de domaine Active Directory local.
La clé de Registre PolAcDmN et la clé de Registre PolPrDmN ne correspondent pas.
Solutions
IMPORTANT
Solution pour l’entrée de Registre KDCNames incorrecte

1. Sur le contrôleur de domaine de destination, exécutez REGEDIT.
2. Recherchez la sous-clé suivante dans le Registre :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Domains
3. Pour chaque > <Fully_Qualified_Domain sous la sous-clé, vérifiez que la valeur de l’entrée de Registre
KdcNames fait référence à un domaine Kerberos externe valide et non au domaine local ou à un autre
domaine dans la même forêt Active Directory.
Solution pour l’insaltération des clés de Registre PolAcDmN et PolPrDmN
NOTE
Cette méthode est valide uniquement pour les contrôleurs de domaine qui exécutent Windows Server 2000.

2. Dans le volet de navigation, développez Sécurité .
3. Dans le menu Sécurité , cliquez sur Autorisations pour accorder au groupe local Administrateurs le
contrôle total de la ruche SECURITY et de ses conteneurs et objets enfants.
HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN
5. Dans le volet droit de l’Éditeur du Registre, cliquez sur ****Aucun nom : REG_NONE entrée de Registre
une seule fois.
6. Dans le menu Affichage , cliquez sur Afficher les données binaires .
7. Dans la section Format de la boîte de dialogue, cliquez sur Sur deux sur deux.
Le nom de domaine s’affiche sous la forme d’une chaîne à droite de la boîte de dialogue Données
binaires. Le nom de domaine est identique au domaine Kerberos.
HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN
9. Dans le volet droit de l’Éditeur du Registre, double-cliquez sur l’entrée ****No Name : REG_NONE .
10. Dans la boîte de dialogue Éditeur binaire, collez la valeur de la sous-clé de Registre PolPrDmN. (La
valeur de la sous-clé de Registre PolPrDmN est le nom de domaine NetBIOS).
11. Redémarrez le contrôleur de domaine. Si le contrôleur de domaine ne fonctionne pas correctement,
consultez d’autres méthodes.
Cause 11 : il existe une incompatibilité de compatibilité du gestionnaire laN (LM Compatibility) entre les
contrôleurs de domaine source et de destination
Cause 12 : les noms principaux de service ne sont pas enregistrés ou ne sont pas présents en raison d’une
latence de réplication simple ou d’un échec de réplication
Cause 13 : un logiciel antivirus utilise un pilote de filtre de carte réseau de mini-pare -feu sur le contrôleur de
domaine source ou de destination
État
S’applique à ».
Les erreurs et événements Active Directory tels que ceux décrits dans la section « Symptômes » peuvent
également échouer avec l’erreur 8453 et la chaîne d’erreur similaire suivante :
L’accès à la réplication a été refusé.
Les situations suivantes peuvent entraîner l’échec des opérations Active Directory avec l’erreur 8453. Toutefois,
ces situations ne provoquent pas d’échecs avec l’erreur 5.
L’en-tête NC (Naming Context) n’est pas autorisé avec l’autorisation Réplication des changements de
répertoire.
Le principal de sécurité qui démarre la réplication n’est pas membre d’un groupe qui a reçu l’autorisation
Réplication des changements de répertoire.
Les indicateurs sont manquants dans l’attribut UserAccountControl. Il s’agit notamment de
l’SERVER_TRUST_ACCOUNT et de l’TRUSTED_FOR_DELEGATION’indicateur.
Le contrôleur de domaine en lecture seule (RODC) est joint au domaine sans que la ADPREP /RODCPREP
commande s’exécute en premier.
Exemple de sortie de DCDIAG /TEST:CheckSecurityError
Exemple de sortie DCDIAG /test:CHECKSECURITYERROR à partir Windows contrôleur de domaine Server 2008
R2 suivant. Cette sortie est due à une inclinaison excessive du temps.
Test principal du serveur : <Site_Name>\<Destination_DC_Name> test de démarrage : CheckSecurityError

Source DC <Source DC> présente une erreur de sécurité possible (1398).
Diagnostic...
Erreur de décalage de temps entre le client et 1 DCS ! ERROR_ACCESS_DENIED
ou un ordinateur en panne reçu par :
<Source DC> [<Source DC>] Échec de DsBindWithSpnEx() avec l’erreur 1398,
Il existe une différence d’heure et/ou de date entre le client et le serveur.
Ignorer dc dans <Source DC> le test de convergence de l’objet
CN=<Destination_DC>,OU=Contrôleurs de domaine,DC=<DomainName>,DC=com, car nous
impossible de se connecter !
......................... <Destination_DC> échec du test CheckSecurityError
Exemple de sortie DCDIAG /CHECKSECURITYERROR à partir d’Windows contrôleur de domaine basé sur Server
2003. Cela est dû à une inclinaison excessive du temps.
Faire des tests principaux

Serveur de test : <Site_Name>\<Destination_DC_Name>
Test de démarrage : CheckSecurityError
Source DC <Source DC>présente une erreur de sécurité possible (5). Diagnostic...
Erreur de décalage de temps entre le client et 1 DCS ! ERROR_ACCESS_DENIED ou vers le bas reçues par :
<Source DC>
Source DC <Source DC>_has d’erreur de sécurité possible (5). Diagnostic...
Erreur de décalage de temps : 7 205 secondes différentes entre :.
<Source DC>
<Destination_DC>
[<Source DC>] Échec de DsBindWithSpnEx() avec l’erreur 5,
Ignorer DC <Source DC>dans le test de convergence de l’objet CN=<Destination_DC>,OU=Contrôleurs de
domaine,DC=<DomainName>,DC=com, car nous ne pouvons pas nous connecter !
......................... <Destination_DC> échec du test CheckSecurityError
Exemple de sortie DCDIAG /CHECKSECURITYERROR ci-dessous. Il affiche les noms de SPN manquants. (Le
résultat peut varier d’un environnement à l’autre.)
Faire des tests principaux

Serveur de test : <site name>\<dc name>
Test omis par la demande de l’utilisateur : Publicité
Test de démarrage : CheckSecurityError
* Dr Auth : vérification des erreurs de sécurité de début
KDC trouvé <KDC DC> pour le domaine <DNS Name of AD domain> dans le site <site name>
Vérification du compte d’ordinateur pour DC <DC name> sur DC <DC Name>
* SPN :LDAP/<hostname>.<DNS domain name>/<DNS domain name>
* SPN :LDAP/<hostname>.<DNS domain name>
* SPN :LDAP/ manquant<hostname>
* SPN :LDAP/<hostname>.<DNS domain name>/<NetBIOS domain name>
* SPN manquant :LDAP/bba727ef-be4e-477d-9796-63b6cee3bSf.<forest root domain DN>
* SPN trouvé :E3514235-4B06-I1D1-ABØ4-00c04fc2dcd2/<NTDS Settings object GUID>/<forest root
domain DNS name>
* SPN :HOST/<hostname>manquant.<DNS domain name>/<DNS domain name>
* SPN trouvé :HOST/<hostname>.<DNS domain name>
* SPN trouvé :HOST/<hostname>
* SPN :HOST/<hostname>manquant.<DNS domain name>/<NetBIOS domain name>
* SPN :GC/<hostname>manquant.<DNS domain name>/<DNS domain name> Impossible de vérifier le
compte d’ordinateur (<DN path for Dc machine account>) sur <DC Name> <DC name>.
Résolution de l’erreur de réplication AD 8333 : Objet
Directory in trouvé
Cet article décrit un problème dans lequel les réplications Active Directory échouent avec l’erreur 8333 : objet
Directory in trouvé (ERROR_DS_OBJ_NOT_FOUND).
NOTE
Accueil des utilisateurs : Cet article est destiné uniquement aux agents de support technique et aux
professionnels de l’informatique. Si vous recherchez de l’aide sur un problème, demandez à
l’CommunityMicrosoft.
Symptômes
Cet article décrit les symptômes, la cause et les étapes de résolution en cas d’échec de la réplication Active
Directory avec l’erreur 8333 : Objet Directory in trouvé (ERROR_DS_OBJ_NOT_FOUND).
1. Les formats possibles pour l’erreur sont les suivants :
8333 0x208d ERROR_DS_OBJ_NOT_FO Objet Directory in trouvé.

UND
2. Les événements suivants peuvent être enregistrés

Réplication NTDS 2108 Cet événement contient DES

PROCÉDURES DE RÉPARATION pour
l’événement 1084 précédemment
réalisée. Objet :
OU=TestOU,DC=contoso,DC=com
Object GUID: <GUID> Source
domain controller: A52b57e3-
92b9-4264-822b-
72963eaf1030._msdcs.contoso.com
Additional Data Primary Error value:
8333 Directory object not found.
Valeur d’erreur secondaire : -1601
JET_errRecordNotFound, la clé est in
trouvée
2031 L’objet configuration du service DS

NTDS General est in trouvé. Il a peut-être été
supprimé accidentellement. Active
Directory pourra fonctionner
normalement, mais vous ne pourrez
pas définir certains paramètres de
service, tels que les limites LDAP, les
stratégies de requête par défaut et
les mappages SPN. Objet
configuration du service DS :
CN=Service
d’annuaire,CN=Windows
NT,CN=Services,CN=Configuration,
DC=contoso,DC=com Error: 8333
(objet directory in found.) Action de
l’utilisateur : essayez de restaurer
l’objet configuration du service DS.
3. Il peut y avoir une sortie à partir de repadmin /replsum
Dc-1-03 03h:14m:11s 1 / 52 1 (8333) Objet Directory in trouvé.

4. DCPromo peut échouer lors de la promotion d’un nouveau contrôleur de domaine et vous verrez les
erreurs suivantes dans le journal DCPROMO.
<DateTime> [INFO] Création d’utilisateurs de domaine, de groupes et d’objets ordinateur

<DateTime> [INFO] Erreur : Active Directory ne comprend pas d’informations critiques après
l’installation et ne peut pas continuer. S’il s’agit d’un contrôleur de domaine réplica, rejoignez ce
serveur dans le domaine. (8333)
<DateTime> [INFO] NtdsInstall pour contoso.com la 8333 renvoyée
<DateTime> [INFO] DsRolepInstallDs a renvoyé 8333
<DateTime> [ERROR] Échec de l’installation dans le service d’annuaire (8333)
NOTE
L’erreur 8333 se traduit par ERROR_DS_OBJ_NOT_FOUND ou « Objet Directory in trouvé ».
5. Lors de la tentative de réhostance d’une partition sur le catalogue global

repadmin /rehost \<dc-name>\<partition to rehost>\<good source>
repadmin /rehost failed with DsReplicaAdd failed with status 8333 (0x208d)
Cause
L’état d’erreur 8333 « Directory Object Not Found » a plusieurs causes racines, notamment :
1. Altération de la base de données avec des erreurs associées supplémentaires consignées dans le journal
des événements du contrôleur de domaine source :
SO URC E ID D’ÉVÈN EM EN T DESC RIP T IO N

PROCÉDURES DE RÉPARATION pour
l’événement 1084 précédemment
des services de domaine Active
Directory sur cette destination de
réplication. Une erreur de base de
données s’est produite lors de
l’application de modifications
répliquées à l’objet suivant. La base
de données avait un contenu
inattendu, ce qui empêchait la
modification d’être réalisée. Objet :
CN=chduffey,OU=IT,OU=Corp,DC=
contoso,DC=com
GUID d’objet : <GUID>
Contrôleur de domaine source :
c4efaf4e-d652-4630-8623-
afec5ebc8532._msdcs.contso.comAd
ditional Data
Valeur d’erreur principale : 8333
Objet Directory in trouvé.
NTDS General 1168 Error -1073741790(c0000022) has

occurred (Internal ID 3000b3a).
Contactez les services de support
technique Microsoft pour obtenir de
l’aide.
Microsoft-Windows- 1084 Événement interne : Active

Réplication NTDS 1699 Le contrôleur de domaine local n’a

8446 L’opération de réplication n’a
pas réussi à allouer de la mémoire
En outre, vous pouvez voir le code d’état de la réplication :
C O DE SO URC ES IN F O RM AT IO N S SUP P L ÉM EN TA IRES
8451 Repadmin, DcPromo, en tant que Reportez-vous au guide de

sous-code dans les événements de résolution des problèmes pour le
corruption de base de données 8451 dans la première instance si
cette erreur est identifiée.
2645996
2. Objets en attente avec les erreurs associées consignées :
SO URC E ID D’ÉVÉN EM EN T DESC RIP T IO N
Réplication NTDS 1988 La réplication Active Directory a

rencontré l’existence d’objets dans la
partition suivante qui ont été
supprimés de la base de données
Active Directory des contrôleurs de
domaine locaux. Tous les partenaires
de réplication directe ou transitive
n’ont pas été répliqués dans la
suppression avant le nombre de
jours écoulés au cours de la durée
de vie de tombstone. Les objets qui
ont été supprimés et la garbage
collecté à partir d’une partition
Active Directory, mais qui existent
toujours dans les partitions
accessibles en lecture d’autres DCS
dans le même domaine, ou les
partitions en lecture seule des
serveurs de catalogue global dans
d’autres domaines de la forêt sont
appelés « objets en attente ».
Réplication NTDS 1388 Un autre contrôleur de domaine a

tenté de répliquer dans ce dc un
objet qui n’est pas présent dans la
locale. L’objet a peut-être été
supprimé et déjà la garbage
collected (une durée de vie de
tombstone ou plus a été passée
depuis la suppression de l’objet) sur
ce DC. Le jeu d’attributs inclus dans
la demande de mise à jour n’est pas
suffisant pour créer l’objet. L’objet
est re-demandé avec un jeu
d’attributs complet et re-créé sur ce
dc.
En outre, vous pouvez voir les codes d’état de réplication suivants :
SO URC E SO URC ES DESC RIP T IO N
8606 Repadmin, DCPromo, sous-code Reportez-vous au guide de

dans les événements de réplication résolution des problèmes pour le
NTDS 8606 dans la première instance si
cette erreur est identifiée. 2028495
1722 Repadmin, DCPromo, sous-code Reportez-vous au guide de

dans les événements de réplication résolution des problèmes pour 1722
NTDS dans la première instance si cette
erreur est identifiée. 2102154
3. Objets conflictuelles
4. Processus tiers
a. Antivirus
b. Logiciel de synchronisation d’annuaires
Résolution
L’examen du message d’erreur 8333 « Objet d’annuaire in trouvé » doit commencer sur le contrôleur de
domaine source dans le partenariat de réplication. Faisant référence à chacune des causes possibles du
problème dans la section « Cause » de ce document, un professionnel du support technique doit commencer
son examen sur la source du partenariat de réplication source/destination.
1. Vérifiez les indications d’altération de la base de données Active Director y (JET) :
a. Examinez le journal des événements des services d’annuaire sur les partenaires de réplication
source et de destination pour les événements d’altération de base de données JET. Les événements
possibles sont les suivants :


PROCÉDURES DE RÉPARATION
pour l’événement 1084
précédemment enregistré. Ce
message indique un problème
spécifique avec la cohérence de la
base de données des services de
domaine Active Directory sur
cette destination de réplication.
Une erreur de base de données
s’est produite lors de l’application
de modifications répliquées à
l’objet suivant. La base de
données avait un contenu
inattendu, ce qui empêchait la
modification d’être réalisée. Objet
:
CN=chduffey,OU=IT,OU=Corp,D
C=contoso,DC=com
c4efaf4e-d652-4630-8623-
afec5ebc8532._msdcs.contso.com
Additional Data
Valeur d’erreur principale : 8333
Objet Directory in trouvé.
NTDS General 1168 Error -1073741790(c0000022)

has occurred (Internal ID
3000b3a). Contactez les services
de support technique Microsoft
pour obtenir de l’aide.
Microsoft-Windows- 1084 Événement interne : Active

l’objet suivant avec les
modifications reçues du
contrôleur de domaine source
suivant. Cela est dû au fait qu’une
erreur s’est produite lors de
apportées à Active Directory sur
le contrôleur de domaine.
Réplication NTDS 1699 Le contrôleur de domaine local

n’a pas pu récupérer les
modifications demandées pour la
partition d’annuaire suivante. Par
conséquent, il n’a pas pu envoyer
les demandes de modification au
contrôleur de domaine à l’adresse
réseau suivante. 8446 L’opération
de réplication n’a pas réussi à
allouer de la mémoire
En outre, vous pouvez voir le code d’état de la réplication :

IN F O RM AT IO N S
C O DE SO URC ES SUP P L ÉM EN TA IRES

sous-code dans les événements résolution des problèmes pour le
de corruption de base de 8451 dans la première instance si
données cette erreur est identifiée.
2645996
b. Activez la journalisation de réplication des services d’annuaire avancés :
IMPORTANT
Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre.
Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par
conséquent, veillez à suivre ces étapes scrupuleusement. Pour une meilleure protection, sauvegardez le
registre avant de le modifier. Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations
sur la façon de la back up et de la restauration du Registre, cliquez sur le numéro d’article suivant pour
afficher l’article dans la Base de connaissances Microsoft :
322756 Comment sauvegarder et restaurer le Registre dans Windows
Pour augmenter la journalisation des diagnostics NTDS, modifiez les valeurs REG_DWORD
suivantes dans le Registre du contrôleur de domaine de destination sous la clé de Registre
suivante :
Définissez la valeur des sous-clés suivantes sur 5 :
5 Événements de réplication
9 Traitement interne
Remarque : la journalisation de niveau 5 est extrêmement détaillée et les valeurs des deux sous-
clés doivent être définies sur la valeur par défaut 0 une fois le problème résolu. Le filtrage du
journal des événements des services d’annuaire doit être effectué pour isoler et identifier ces
événements.
c. Examinez les journaux des événements pour les nouveaux événements qui ont été générés à partir
de la journalisation accrue pour les valeurs d’erreur qui donnent une vue définitive de l’altération
de la base de données.
d. Si une altération de la base de données a été détectée, assurez-vous que les sauvegardes récentes
existent pour chaque domaine de la forêt.
e. Redémarrez le contrôleur de domaine signalant que la base de données est corrompue en mode
de restauration des services d’annuaire. (Appuyez sur F8 pendant le redémarrage du serveur ou si
cela n’est pas possible, ouvrez msconfig.exe et choisissez « Réparation Active Directory » dans les
options de démarrage.)
f. Pour effectuer une inspection de la base de données en mode de restauration des services
d’annuaire :
a. Ouvrir une invite de commandes
b. Tapez « ntdsutil »
c. Tapez « activer les instances ntds »
d. Type « Analyse de base de données sémantique »
e. Tapez « go »
Si des erreurs sont détectées, elles sont affichées dans la console et écrites dans un fichier journal
dans le répertoire de travail actuel.
g. Si des erreurs de corruption de base de données sont détectées, il est conseillé de contacter les
services de support Microsoft.
h. En tant que dernière option. Vous pouvez rétrograder le contrôleur de domaine et le promouvoir à
nouveau pour remplacer la base de données et répliquer le contenu à partir d’un autre serveur du
domaine.
NOTE
Si une base de données Active Directory a été endommagée dans votre environnement, il est important
de prendre en compte la source de l’altération pour éviter les problèmes à l’avenir. Voici quelques-unes des
causes connues d’une telle corruption :
1. Matériel défectueux : disque dur ou contrôleur
2. Mise en cache : contrôleur de disque dur
3. Pilotes obsolètes : contrôleur de disque dur
4. Microprogramme obsolète : BIOS, contrôleur de disque dur, disque dur
5. Perte d’alimentation soudaine
2. Vérifiez l’existence et supprimez des objets en attente sur tous les contrôleurs de domaine dans la forêt.
Il existe plusieurs approches pour vérifier les objets en attente, notamment :
a. Vérifiez l’existence des événements des services d’annuaire suivants sur les contrôleurs de
domaine dans la forêt :
Réplication NTDS 1988 La réplication Active Directory a

rencontré l’existence d’objets dans
la partition suivante qui ont été
supprimés de la base de données
Active Directory des contrôleurs
de domaine locaux. Tous les
partenaires de réplication directe
ou transitive n’ont pas été
répliqués dans la suppression
avant le nombre de jours écoulés
au cours de la durée de vie de
tombstone. Les objets qui ont été
supprimés et la garbage collected
from an Active Directory partition
but still exist in the writable
partitions of other DCs in the
same domain, or read-only
partitions of global catalog
servers in other domains in the
forest are known as « leted
objects ».
Réplication NTDS 1388 Un autre contrôleur de domaine a

tenté de répliquer dans ce dc un
objet qui n’est pas présent dans la
locale. L’objet a peut-être été
supprimé et déjà la garbage
collected (une durée de vie de
tombstone ou plus a été passée
depuis la suppression de l’objet)
sur ce DC. Le jeu d’attributs inclus
dans la demande de mise à jour
n’est pas suffisant pour créer
l’objet. L’objet est re-demandé
avec un jeu d’attributs complet et
re-créé sur ce dc.
En outre, vous pouvez voir les codes d’état de réplication suivants :
IN F O RM AT IO N S
C O DE SO URC ES SUP P L ÉM EN TA IRES

sous-code dans les événements résolution des problèmes pour le
de corruption de base de 8451 dans la première instance si
données cette erreur est identifiée.
2645996
b. Utilisez repldiag.exe pour examiner la forêt pour les objets en attente.

Repldiag peut être téléchargé à partir de codeplex.com. Pour effectuer le mode d’avis
d’enregistrement d’objet en attente, utilisez la syntaxe suivante :
repldiag /RemoveLingeringObjects/AdvisoryMode
L’événement du service d’annuaire 1942 sera enregistré sur chaque contrôleur de domaine et
indiquera le nombre d’objets en attente détectés dans chaque partition d’annuaire.
Le travail effectué par repldiag peut également être effectué avec l’outil de réplication des services
d’annuaire intégré : Repadmin.exe.
Pour les professionnels du support qui préfèrent utiliser repadmin.exe, la commande partielle sera
Repadmin /removelingeringobjects . Repldiag.exe offre un avantage par rapport aux Repadmin.exe,
car il peut être utilisé pour effectuer des recherches dans toutes les partitions d’annuaire, sur tous
les serveurs de la forêt avec une seule commande.
Si des objets En attente sont détectés :
a. Effectuez une sauvegarde de l’état système de deux contrôleurs de domaine dans chaque
domaine de la forêt.
b. Utilisez repldiag.exe pour effectuer un nettoyage des objets en attente :
repldiag /Remove QuingObjects
c. Chaque contrôleur de domaine enregistre un événement de services d’annuaire 1942 pour
chaque partition de services d’annuaire afin d’indiquer si des objets en attente ont été
supprimés.
Pour une autre approche de la suppression des objets en attente, vous pouvez utiliser l’outil intégré
Repadmin.exe avec le /removelingeringobjects commutateur. Cette approche nécessite plusieurs
commandes, repldiag fournit un agrégat des commandes que Repadmin.exe utiliseriez.
3. Vérifiez l’existence d’objets en conflit et supprimez-les :
a. Recherchez les partitions d’annuaire pertinentes pour les objets gérés par le CNF et l’objet en conflit qui
est en conflit avec la syntaxe suivante :
repadmin /showattr localhost "dc=parent,dc=com" /subtree /filter:"((&(objectClass=*)(cn=*\0acnf:*)))"
/atts:objectclass,whencreated,whenchanged
Dans cet exemple, « dc=parent,dc=com » est le nom du parent.com domaine.

Dans la plupart des cas, l’erreur 8333 indique la ou les partitions d’annuaire à évaluer pour les objets en
conflit. Il est recommandé de vérifier la partition de configuration dans toutes les instances :
repadmin /showattr localhost "cn=configuration,dc=parent,dc=com" /subtree /filter:"((&(objectClass=*)
(cn=*\0acnf:*)))" /atts:objectclass,whencreated,whenchanged
b. Passer en revue les attributs, les valeurs d’attribut et, si elles sont présentes, les objets subordonnés
pour déterminer quel objet doit rester et lequel doit être supprimé
c. Assurez-vous que vous avez une sauvegarde à jour de l’annuaire
d. Supprimez l’objet/conteneur en conflit ou l’objet avec LDP.EXE, ADSIEDIT ou l’un des outils de gestion
Active Directory.
4. Effectuer des tests des partenaires de réplication avec des composants tiers supprimés.
Plusieurs produits tiers sont à l’origine de ce problème, notamment :
a. Logiciel antivirus
b. Directory Synchronization
Objets en attente :
Nettoyer la forêt Active Directory d’objets en attente
Corruption de base de données :
ID d’événement 1539 — Intégrité de la base de données
Résolution de l’erreur de réplication AD 8477 : la
demande de réplication a été publiée . en attente
de réponse
Cet article décrit un problème dans lequel les réplications Active Directory échouent avec l’erreur 8477 : « La
demande de réplication a été publiée ; en attente de réponse ».
NOTE
Symptômes
Cet article décrit les symptômes, la cause et les étapes de résolution impliqués dans la résolution de l’erreur de
réplication Active Directory 8477 : « La demande de réplication a été publiée ; en attente de réponse ».
Les symptômes décrits dans cet article sont généralement liés à l’occurrence de l’événement 8477, mais peuvent
également être observés avec d’autres événements liés à une réplication lente ou différée. Lors de la résolution
de ces problèmes, il convient de prendre en compte tous les facteurs qui peuvent entraîner des retards de
réplication et d’être corrigés en conséquence.
La sortie de repadmin.exe /showreps /verbose peut signaler que la tentative de réplication a échoué avec
l’erreur 8477 - « La demande de réplication a été publiée ; en attente de réponse »
DC=Contoso,DC=com
Default-First-Site-Name\DomainController via RPC
GUID d’objet DSA : <source DCs ntds settings object object guid>
Adresse : <source DCs ntds settings object object guid>._msdcs.Contoso.Com
DSA invocationID : <source DCs NTDS DB invocation id>
DO_SCHEDULED_SYNCS PRÉEMPTIBLE COMPRESS_CHANGES NO_CHANGE_NOTIFICATIONS ÉCRITURE
USNs : 1158544/OU, 111052/PU
La dernière tentative @ <Date Time> a été retardée pour une raison normale, résultat 8477 (0x211d) :
La demande de réplication a été publiée . en attente de réponse.
Dernière réussite @ <Date Time>
La sortie de repadmin.exe/file d’attente peut signaler un grand nombre de demandes de réplication entrante
en file d’attente et une durée d’exécution sans précédent
Repadmin /queue
commande/file d’attente en cours d’exécution du repadmin sur le serveur localhost
La file d’attente contient 26 éléments.
La tâche en cours a commencé à s’exécuter à .<Date Time>
La tâche s’exécute depuis 86 minutes, 12 secondes.
[6485] Enqueued <Date Time> à la priorité 590
SYNCHRONISER À PARTIR DE LA SOURCE
NC DC=Contoso,DC=com
DC Default-First-Site-Name\DomainController
GUID d’objet DC <source DCs ntds settings object object guid>
Addr <source DCs ntds settings object object guid>de transport DC ._msdcs.Contoso.com
ASYNCHRONOUS_OPERATION’ÉCRITURE PÉRIODIQUE NEVER_NOTIFY PRÉEMPTÉ
NOTE
L’occurrence de l’événement 8477 lorsque des demandes de réplication entrantes sont en file d’interrogation est
généralement observée à la suite d’une tâche de réplication préemptée. Cet événement est indiqué par l’événement 8461
- L’opération de réplication a été préalablementemptée.
Lorsque vous utilisez dcdiag.exe, l’initialisation d’un contrôleur de domaine récemment promu peut être
retardée, en attendant la fin d’une synchronisation initiale.
Diagnostic du serveur d’annuaire
Effectuer la configuration initiale :
Tentative de recherche du serveur d’accueil...
Home Server = DomainController
L’initialisation du service d’annuaire sur DomainController n’est pas terminée.
Pour que le service d’annuaire se considère comme synchronisé, il doit
essayer une synchronisation initiale avec au moins un réplica de ce
domaine accessible en écriture du serveur. Il doit également obtenir des informations Rid à partir du
Titulaire FSMO.
Le service d’annuaire n’a pas signalé l’événement qui permet à d’autres services
sachez qu’il est prêt à accepter les demandes. Services tels que la clé
Le centre de distribution, le service de messagerie intersite et NetLogon ne seront pas
considérez ce système comme un contrôleur de domaine éligible.
* Forêt AD identifiée.
Terminé la collecte des informations initiales.
L’initialisation du service d’annuaire sur LADC01 n’est pas terminée.
Pour que le service d’annuaire se considère comme synchronisé, il doit
essayer une synchronisation initiale avec au moins un réplica de ce
domaine accessible en écriture du serveur. Il doit également obtenir des informations Rid à partir du
Titulaire FSMO.
Le service d’annuaire n’a pas signalé l’événement qui permet à d’autres services
sachez qu’il est prêt à accepter les demandes. Services tels que la clé
Le centre de distribution, le service de messagerie intersite et NetLogon ne seront pas
considérez ce système comme un contrôleur de domaine éligible.
Terminé la collecte des informations initiales.
NOTE
Le résultat des dcdiag.exe décrits ci-dessus est un comportement normal lors de la promotion d’un nouveau contrôleur
de domaine réplica dans un environnement. L’occurrence de 8477 dans ce cas doit avoir le temps d’effacer les cycles de
réplication normaux avant que des activités correctives soient envisagées ou effectuées.
Lorsque vous utilisez dcdiag.exe, le cas de test « Réplications » peut émettre un « AVERTISSEMENT DE
LATENCE DE RÉPLICATION »
AVERTISSEMENT DE LATENCE DE RÉPLICATION
DomainController : une opération de réplication de longue durée est en cours
Le travail s’exécute depuis 84 minutes et 22 secondes.
La réplication des nouvelles modifications le long de ce chemin d’accès sera retardée.
C’est normal pour une nouvelle connexion ou pour un système qui a été mis en panne depuis longtemps.
Enqueued <Date Time> at priority 90
Op : SYNCHRONISER À PARTIR DE LA SOURCE
NC DC=Contoso,DC=com
DSADN <source DCs ntds settings object object guid>
Addr <source DCs ntds settings object object guid>de transport DSA ._msdcs.Contoso.com
......................... DomainController a réussi les réplications de test
L’événement de réplication NTDS 1580 peut être enregistré dans le journal des événements du service
d’annuaire
SO URC E DE L 'ÉVÉN EM EN T ID D’ÉVÈN EM EN T C H A ÎN E D’ÉVÉN EM EN T
Réplication NTDS 1580 Une tâche de réplication entrante des

services de domaine Active Directory
de longue durée s’est terminée avec les
paramètres suivants.
Durée écoulée (minutes) :
84
Opération :
Synchroniser le réplica
Options :
0x21000051
Paramètre 1 :
DC=Contoso,DC=com
Paramètre 2 :
<source DCs ntds settings object
object guid>
Paramètre 3 :
Paramètre 4 :
Une tâche de réplication de longue

durée peut également se produire
lorsqu’un système est indisponible ou
qu’une partition d’annuaire est
indisponible pendant une période
prolongée. Une tâche de réplication de
longue durée peut indiquer un grand
nombre de mises à jour ou un certain
nombre de mises à jour complexes qui
se produisent au niveau du service
d’annuaire source. L’application de ces
mises à jour pendant les périodes non
critiques peut empêcher les retards de
réplication.
Une tâche de réplication de longue

durée est normale dans le cas de
l’ajout d’une nouvelle partition
d’annuaire aux services de domaine
Active Directory. Cela peut se produire
en raison d’une nouvelle installation,
d’une promotion de catalogue global
ou d’une connexion générée par le
Contrôle de cohérence des
connaissances (KCC).
Valeur d’erreur :
L’opération s’est terminée
correctement.
Cause
L’état 8477 (La demande de réplication a été publiée ; en attente de réponse) est informationnel et représente
une opération de réplication Active Directory normale, indiquant que la réplication est en cours à partir de la
source et qu’elle n’a pas encore été appliquée au réplica de base de données contrôleurs de domaine de
destination.
La présence de cet événement pendant une période prolongée peut, toutefois, être indicatif de problèmes avec
la réplication Active Directory sur le contrôleur de domaine de destination. Les causes possibles sont les
suivantes :
1. Mémoire physique disponible faible, liaisons réseau à latence élevée ou Low-Bandwidth, utilisation
processeur excessive ou I/S disque pour la quantité de données réplication par le contrôleur de domaine
2. Taux élevé de modification des objets dans les services de domaine Active Directory (AD DS)
3. Utilitaires tiers qui peuvent entraver ou retarder la fonction de réplication normale
4. Grands groupes (plus de 5 000 membres) pour lequel la réplication à valeur liée n’est pas activée
5. Modification récente du schéma Active Directory dans laquelle un nombre important d’attributs de schéma a
été modifié ou indexé
Résolution
L’examen de l’erreur de réplication 8477 doit être effectué, au moins initialement, sur le contrôleur de domaine
de destination dans le cadre du partenariat de réplication. La section de résolution de cet article traite des
techniques qu’un administrateur Active Directory doit utiliser pour résoudre les causes possibles de l’erreur
8477, selon la section « Cause ».
Mémoire physique disponible faible, liaisons réseau à latence élevée ou Low-Bandwidth, utilisation
processeur excessive ou I/S disque pour la quantité de données réplication par le contrôleur de domaine
Les contrôleurs de domaine Active Directory doivent être configurés avec le moins de rôles et d’applications
supplémentaires possible. Dans l’idéal, un contrôleur de domaine doit être un serveur à usage unique utilisé
uniquement pour le service des requêtes et des demandes d’authentification. Lors de la résolution des
problèmes de performances d’Active Directory, il est souvent préférable d’analyser d’abord le système pour les
applications, services ou tâches supplémentaires inutiles ou redondantes.
Dans un premier temps, une Professional doit vérifier le Gestionnaire des tâches (et le moniteur de ressources,
le cas échéant) pour déterminer si l’utilisation globale du processeur et de la mémoire est trop élevée ou s’il
s’écarte d’une ligne de base prédéfinie. Si aucune ligne de base n’existe, les meilleures pratiques de Microsoft
suggèrent que l’utilisation répétée et soutenue de l’UC supérieure à 80 % serait considérée comme élevée et
devrait faire l’objet d’une étude plus en détail.
Résolution des problèmes d’utilisation élevée du processeur sur un contrôleur de domaine - Résolution des
problèmes d’utilisation élevée du processeur sur un contrôleur de domaine
En ce qui concerne l’utilisation du disque, sur les contrôleurs de domaine Active Directory, les fichiers Ntds.dit et
edb.log doivent être les fichiers les plus actifs sur le système. Pour déterminer si c’est le cas, la journalisation et
l’analyse des performances (comme ci-dessous) doivent être effectuées.
Une bande passante faible, une latence élevée ou une connectivité réseau occupée peuvent également
provoquer l’erreur 8477 sur les contrôleurs de domaine Active Directory. Les mesures des données de
performances réseau doivent être collectées à partir d’un contrôleur de domaine à l’aide de l’analyseurs de
performances, du moniteur réseau ou d’autres outils de ce type. Les instructions sur la surveillance et la mesure
du trafic de réplication sont détaillées dans le trafic de réplication Active Directory.
Pour Windows de domaine basés sur Ser ver 2003 :
Une Professional informatique peut choisir d’utiliser l’Moniteur de performances avec des compteurs
processeur, disque physique, interface réseau et services d’annuaire ajoutés pour déterminer et examiner les
problèmes de performances sur le système. Au lieu de cela, Server Performance Advisor peut réduire la
complexité de l’analyse des mesures de performances obtenues à partir de l’Analyseurs de performances. Il
s’agit d’un téléchargement gratuit qui permet d’examiner l’UC, le réseau, la mémoire et les entrées/s disque, en
donnant des détails sur l’utilisation globale et en précisant si les données de performances sont considérées
comme inactives, normales ou potentiellement problématiques.
Pour Windows Ser ver 2008 et les contrôleurs de domaine basés sur les supérieurs :
L’Windows performance dans Windows Server 2008 et les ultérieures inclut les fonctionnalités clés de Server
Performance Advisor directement. Dans les ensembles de collecteurs de données système, l’ensemble de
diagnostics Active Directory, de la même manière que Le Conseiller en performances du serveur, produit un
rapport avec des mesures clés pour l’examen des performances d’Active Directory et fournit des avertissements
pour un comportement non caractéristique sur les contrôleurs de domaine Active Directory. Les avertissements
sont inclus en haut du rapport. Voici un exemple :
AVERT ISSEM EN T
Symptôme : Le système rencontre une pagination excessive
Cause : La mémoire disponible sur le système est faible.
Détails : La mémoire physique totale sur le système n’est pas capable

de gérer la charge.
Résolution : Mettre à niveau la mémoire physique ou réduire la charge

système
Connexes : Diagnostic de la mémoire
Symptôme : Sur les serveurs d’annuaire, Ntds.dit et Edb.log doivent être

les fichiers les plus actifs. Dans ce cas,
C:\Windows\NTDS\ntds.dit présente le taux d’E/S le plus
élevé (84,622 opérations/s).
Taux élevé de modification des objets dans les services de domaine Active Directory (AD DS )
Dans un environnement Active Directory occupé, un grand nombre de modifications peuvent se produire sur les
objets entre chaque réplication programmée. Si cela est attendu dans l’environnement, tous les aspects de
l’infrastructure des organisations doivent être re tailler correctement pour faciliter la réplication efficace.
Dans le cas où un administrateur informatique ignore ou n’attend pas un grand nombre de modifications et
reçoit l’erreur 8477, une enquête doit être menée pour déterminer les modifications qui se produisent dans
l’environnement et déterminer si celles-ci sont attendues ou le résultat d’un problème avec une application ou
un service. Un moyen efficace pour effectuer cette tâche consiste à déterminer les objets qui changent via
l’utilisation de l’attribut uSNChanged, la valeur uSNChanged la plus élevée sur un contrôleur de domaine
spécifique représente le High-Watermark usn.
L’exécution de repadmin /showreps /verbose sur un contrôleur de domaine avec l’événement 8477 affiché
affiche la High-Watermark actuelle et est suivie de /OU :
DC=Contoso,DC=com
Default-First-Site-Name\DomainController via RPC
GUID d’objet DSA : <source DCs ntds settings object object guid>
Adresse : <source DCs ntds settings object object guid>._msdcs.Contoso.Com
DSA invocationID : <source DCs NTDS DB invocation id>
DO_SCHEDULED_SYNCS PRÉEMPTIBLE COMPRESS_CHANGES NO_CHANGE_NOTIFICATIONS ÉCRITURE
USNs : 1158544/OU, 111052/PU
La dernière tentative @ <Date Time> a été retardée pour une raison normale, résultat 8477 (0x211d) :
La demande de réplication a été publiée . en attente de réponse.
Dernière réussite @ <Date Time>
Selon le nombre de modifications qui se produisent, le usn le plus élevé présent sur un contrôleur de domaine
peut incrémenter rapidement. Pour déterminer les objets en cours de mise à jour, il est suggéré que, sur le
partenaire de réplication source, la commande ci-dessous soit exécuté pour le contexte d’attribution de noms
approprié :
Repadmin /showattrDomainControllerNameDC=Contoso,DC=com /subtree /filter:"(uSNChanged>=highestcommitedusn)"
/atts:objectclass
Des applications ou des services spécifiques, tels que le Exchange service de mise à jour de destinataire, peuvent
apporter des modifications régulières aux attributs Active Directory et peuvent avoir besoin d’être réglés si le
trafic de réplication résultant est ingérable.
Utilitaires tiers qui peuvent entraver ou retarder la fonction de réplication normale
Les applications tierces doivent être configurées et configurées autour des meilleures pratiques en matière de
performances et de prise en charge. Certaines applications, si elles ne sont pas configurées autour des
meilleures pratiques en matière de performances Active Directory, peuvent avoir un impact sur la fonction
normale du contrôleur de domaine Active Directory.
Les applications de remarque incluent (mais ne sont pas limitées à) :
a. Logiciel d’analyse antivirus
b. Agents de surveillance
c. Applications de gestion et de synchronisation d’identités
d. Logiciels et agents de sauvegarde
Recommandations en matière d’analyse antivirus Enterprise ordinateurs exécutant actuellement des versions de
Windows
Grands groupes (plus de 5 000 membres) pour lequel la réplication à valeur liée n’est pas activée
La réplication à valeur liée n’est pas disponible dans Windows 2000 Server. Étant donné qu’une mise à jour
d’origine doit être écrite dans une seule transaction de base de données et que la limite pratique pour une
transaction unique est de 5 000 valeurs, l’appartenance à plus de 5 000 valeurs n’est pas prise en charge dans
Windows 2000 Server Active Directory. Un groupe de cette taille représente une limitation à la fois pour
l’opération d’écriture de base de données requise pour enregistrer une modification d’un attribut de cette taille
et le transfert de cette quantité de données sur le réseau. Ceci est différent dans les forêts Windows 2003 ou un
niveau fonctionnel supérieur où la réplication à valeur liée (LVR) pour les appartenances à des groupes est
activée.
Lorsqu’un domaine est mis à niveau à partir d’un niveau fonctionnel 2000, les appartenances de tous les
groupes effectués sont considérées comme héritées et peuvent toujours provoquer des problèmes de
réplication :
1. Les forêts avant le niveau fonctionnel 2003 doivent diviser les groupes en groupes plus petits qui ne
dépassent pas 5 000 membres. L’imbrmbrage de groupes peut également être utilisé, en fournissant les
applications et les services qui utilisent les groupes pour la prendre en charge.
2. Les forêts au niveau fonctionnel 2003 peuvent supprimer et rétablir les membres du groupe pour les
rendre activés pour le LVR. Au fil du temps, à mesure que les principaux de sécurité sont ajoutés et
supprimés des groupes, les membres sont lentement activés pour le LVR Remarque : les événements
1479 et 1519 sont également généralement enregistrés dans le journal des événements du service
d’annuaire lorsque de grands groupes provoquent des problèmes et des retards de réplication.
L’utilisation des membres hérités repadmin /showobjmeta dans un groupe peut être déterminée et convertie en
membres activés pour LVR si nécessaire pour résoudre le problème, ces utilisateurs sont indiqués avec « Type »
de valeur LEGACY :
repadmin /showobjmeta DomainControllerName « CN=Administrators,CN=Builtin,DC=Contoso,DC=Com »

3 entrées.
Type Attribute Last Mod Time Originating DSA Loc.USN Org.USN Ver
======= ============ ============= ================= ======= =======
===
Nom distinguished
=============================
PRESENT member <Date Time> Default-First-Site-Name\DomainController 8203 8203 1
CN=Administrateur,CN=Utilisateurs,DC=Contoso,DC=Com
CN=Enterprise admins,CN=Users,DC=Contoso,DC=Com
CN=Administrateurs de domaine,CN=Utilisateurs,DC=Contoso,DC=Com
LEGACY member <Date Time> Default-First-Site-Name\DomainController 198458 198458 1
CN=mjordan,CN=Users,DC=Contoso,DC=Com
Modification récente du schéma Active Directory dans laquelle un nombre important d’attributs de schéma a
été modifié ou indexé
Les définitions d’attribut sont stockées dans des objets attributeSchema dans la partition du répertoire de
schéma. Les modifications apportées aux objets attributeSchema bloquent toute autre réplication jusqu’à ce que
les modifications de schéma soient apportées. Lors de la réplication d’une partition d’annuaire autre que la
partition de répertoire de schéma, le système de réplication vérifie d’abord si les versions de schéma de la
source et les contrôleurs de domaine de destination sont en accord. Si les versions ne sont pas identiques, la
réplication de l’autre partition d’annuaire est reprogrammée jusqu’à ce que la partition du répertoire de schéma
soit synchronisée.
La modification du schéma par le biais de l’utilisation de LDIFDE ou de binaires personnalisés inclus dans les
applications (c’est-à-dire, Microsoft Exchange, Operations Manager, etc.) peut ajouter des attributs indexés à la
partition du répertoire de schéma. Selon la taille de la mise à jour, des retards de réplication peuvent être
provoqués dans des bases de données de grande taille.
Dans ces cas-là, l’état 8477 peut apparaître comme un problème temporaire et doit être censé s’auto-résoudre
une fois que les mises à jour de schéma de priorité supérieure sont répliquées avec succès et que toutes les
autres réplications rattrapent les modifications du carnet d’attente au sein de l’annuaire.
Fonctionnement du modèle de réplication Active Directory
Vous ne pouvez pas modifier l’étendue de
réplication d’une zone DNS intégrée Active
Directory dans Windows Server 2003
Cet article fournit une solution à une erreur qui se produit lorsque vous modifiez l’étendue de réplication d’une
zone DNS (Integrated Domain Name System) Active Directory.
Symptômes
Lorsque vous essayez de modifier l’étendue de réplication d’une zone DNS intégrée Active Directory, vous
pouvez recevoir une erreur semblable au message d’erreur suivant :
L’étendue de réplication n’a pas pu être définie.

Un serveur a été en panne.
Cause
Ce problème peut se produire si le compte système ne présente pas l’autorisation SeSecurityPrivelige fournie
par le compte d’administrateur intégré.
Résolution
Pour résoudre ce problème, vous devez ajouter le compte de groupe Administrateurs intégré à l’autorisation
utilisateur gérer l’audit et le journal de sécurité. L’autorisation utilisateur gérer l’audit et le journal de sécurité se
trouve dans la stratégie de contrôleur de domaine par défaut. Après avoir ajouté le compte de groupe
Administrateurs intégré, modifiez l’étendue de réplication de la zone DNS requise.
Pour ajouter le compte de groupe Administrateurs intégré à l’autorisation utilisateur gérer les journaux d’audit
et de sécurité, suivez les étapes suivantes :
1. Démarrez le logiciel en ligne Utilisateurs et ordinateurs Active Directory.
2. Cliquez avec le bouton droit sur le conteneur Contrôleurs de domaine, puis cliquez sur Propriétés.
3. Cliquez sur l’onglet Stratégie de groupe, puis cliquez sur Modifier.
4. Dans le volet gauche, développez Windows Paramètres, puis développez Sécurité Paramètres .
5. Développez les stratégies locales, puis cliquez sur Attribution des droits d’utilisateur.
6. Dans le volet droit, double-cliquez sur Gérer l’audit et le journal de sécurité, puis cliquez sur Ajouter un
utilisateur ou un groupe.
7. Cliquez sur Parcourir, puis sur Avancé.
8. Cliquez sur Rechercher maintenant, puis sur Administrateurs dans la zone Résultats de la recherche.
9. Cliquez sur OK, sur OK, sur OK, puis sur OK pour quitter l’Éditeur d’objets de stratégie de groupe.
10. Dans le menu Fichier, cliquez sur Quitter.
11. Cliquez sur OK .
12. Quittez le logiciel en ligne Utilisateurs et ordinateurs Active Directory.
13. Modifier l’étendue de réplication de la zone DNS intégrée Active Directory.
La suppression d’objets Active Directory qui ont de
nombreux liens provoque des échecs de réplication
Cet article fournit une solution de contournement pour un problème qui se produit lorsque vous supprimez des
objets Active Directory qui contiennent de nombreux liens avant.
Résumé
Cet article traite d’un problème qui se produit lorsque vous supprimez des objets Active Directory qui
contiennent de nombreux liens avant. Voici quelques exemples courants :
Appartenances aux groupes (attribut de membre)
Informations d’identification utilisateur itinérantes (attribut ms-PKI-AccountCredentials)
Les liens d’utilisateurs exposés par le contrôleur de domaine en lecture seule (RODC) (l’attribut mds-
revealedusers)
Le nombre de liens où vous commencez à voir des problèmes peut être aussi faible que 50 000. Sur un seul
objet, il peut y avoir plusieurs millions de liens.
La clé de Registre abordée dans cet article doit être appliquée uniquement aux contrôleurs de domaine et aux
serveurs LDS (Lightweight Directory Services) qui rencontrent le problème décrit dans la section « Symptômes
». This issue is likely to occur on Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016
DCS. En suivant les recommandations données ici, vous pouvez réduire les performances de réplication Active
Directory, mais augmenter la fiabilité du traitement correct de la suppression d’objets de ce type.
Symptômes
Lorsque vous supprimez des objets Active Directory qui contiennent de nombreux liens avant, vous pouvez
rencontrer un échec de réplication. Par exemple, vous supprimez des groupes avec de grands groupes
d’appartenances, ou vous rétrogradez, puis supprimez les comptes d’ordinateur RODC qui ont de nombreux
liens vers des comptes d’utilisateurs dont le mot de passe est exposé sur le RODC.
Les conditions suivantes sont les indicateurs clés que cette solution applique au problème :
Le niveau fonctionnel de la forêt Windows Server 2003 ou une version ultérieure de Windows Server, de
sorte que la réplication de valeur de lien est utilisée.
L’événement 2094 (délai de réplication) se produit plusieurs fois, référent le même objet supprimé.
Les événements 1083 et 1955 (conflit d’écriture) sont enregistrés à proximité de la journalisation de
l’événement 2094 référent au même objet supprimé.
Le contrôleur de domaine concerné peut également signaler que le magasin de versions est épuisé (ID
d’événement 623). L’épuisement du magasin de versions ne se produit pas toujours dans ce scénario. Les
autres facteurs qui augmentent la probabilité d’épuisement du magasin de versions incluent un taux
élevé de modifications apportées aux objets Active Directory, à la fois locales et répliquées, ainsi que
d’autres opérations de longue durée, telles que des requêtes approfondies.
La réplication Active Directory échoue avec l’erreur 8409, l’erreur « Une erreur de base de données s’est
produite » ou d’autres événements mentionnent les codes d’état associés mentionnés dans le tableau
suivant :
000020D9 8409 ERROR_DS_DATABASE_ER Une erreur de base de

ROR données s’est produite
Si la Corbeille Active Directory est activée, les erreurs de réplication peuvent ne pas se produire pendant
60 à 180 jours (durée de vie de l’objet supprimé) après la suppression de l’objet. Les problèmes se
produisent lorsque l’objet passe de l’état supprimé à l’état recyclé.
Entrées du journal des événements
Lorsque le problème se produit, les événements suivants sont enregistrés :

Description : Avertissement de performances : la réplication a été retardée lors de l’application des
modifications à l’objet suivant. Si ce message se produit fréquemment, il indique que la réplication se
produit lentement et que le serveur peut avoir des difficultés à suivre les modifications.
DN d’objet : <object name>
GUID d’objet : <object GUID>
DN de partition : DC=contoso,DC=com
Serveur : xxxx-xxxx-xxxx-xxxx-xxxxxxx._msdcs.contoso.com
Temps écoulé (secs) : 11
Une raison courante de voir ce délai est que cet objet est particulièrement grand, soit dans la taille de ses
valeurs, soit dans le nombre de valeurs. Vous devez d’abord déterminer si l’application peut être modifiée
pour réduire la quantité de données stockées sur l’objet ou le nombre de valeurs. S’il s’agit d’un groupe
important ou d’une liste de distribution, vous pouvez envisager d’augmenter le niveau fonctionnel de la
forêt à Windows Server 2003 ou une autre, car cela permettra à la réplication de fonctionner plus
efficacement. Vous devez évaluer si la plateforme serveur offre des performances suffisantes en termes de
mémoire et de puissance de traitement. Enfin, vous pouvez envisager de régler la base de données des
services de domaine Active Directory en déplaçant la base de données et les journaux vers des partitions de
disque distinctes.
Si vous souhaitez modifier la limite d’avertissement, la clé de Registre est incluse ci-dessous. La valeur zéro
désactive la vérification.
Limite d’avertissement (secs) : 10
Clé de Registre limite : SystemCurrentControlSetServicesNTDSParametersReplicator\\\\\ délai d’attente
maximal pour l’objet de mise à jour (secs)
Description :
Les services de domaine Active Directory n’ont pas pu mettre à jour l’objet suivant avec les modifications
reçues du service d’annuaire à l’adresse réseau suivante, car les services de domaine Active Directory étaient
occupés à traiter les informations.
Objet : <object name>
Adresse réseau : xxxxx-xxxx-xxxx-xxxx-xxxxxxx._msdcs.contoso.com
Cette opération sera tentée à nouveau ultérieurement.
Description : les services de domaine Active Directory ont rencontré un conflit d’écriture lors de l’application
de modifications répliquées à l’objet suivant.
Objet : <object name>
Durée en secondes : 48
Les entrées du journal des événements précédant cette entrée indiquent si la mise à jour a été acceptée ou
non.
Un conflit d’écriture peut être dû à des modifications simultanées apportées au même objet ou à des
modifications simultanées d’autres objets dont les attributs font référence à cet objet. Cela se produit
généralement lorsque l’objet représente un grand groupe avec de nombreux membres et que le niveau
fonctionnel de la forêt est Windows 2000. Ce conflit a déclenché des tentatives supplémentaires de mise à
jour. Si le système semble lent, cela peut être dû à la réplication de ces modifications.
Utilisez des groupes plus petits pour cette opération ou augmentez le niveau fonctionnel de la forêt
Par défaut, lorsque vous supprimez un objet Active Directory qui possède un nombre exceptionnellement élevé
de liens avant et arrière, 10 000 liens sont supprimés à la fois. Pendant ce temps, si d’autres threads met à jour
les objets cibles de ces liens, la transaction de suppression de liens est suspendue jusqu’à ce que les objets
soient à nouveau disponibles. Cette suspension peut entraîner la fin de l’intégralité de la transaction de
suppression. Pendant ce temps, d’autres tâches de réplication sont maintenues par cette tâche de longue durée.
Par exemple, vous remarquerez peut-être que les mots de passe et les mises à jour d’appartenance aux groupes
ne progressent pas dans toute la forêt.
Pendant que cette mise à jour est en attente, les administrateurs peuvent voir des conflits d’écriture et des
événements d’échec de transaction. En outre, à mesure que des objets supplémentaires sont traitées par
réplication, de plus en plus de magasins de versions sont alloués, car la transaction importante en attente ne
libère pas le magasin de versions allouées tant que la transaction de suppression n’est pas terminée. Cela peut
entraîner des erreurs de magasin de versions et des avertissements de réplication.
NOTE
Le garbage collection n’est pas lié au traitement des suppressions de liens d’appartenance à un groupe.
La réduction du TSL n’est pas une méthode valide d’accélération des suppressions de liens.
La valeur héritée pour la taille de lot du processus Liens est de 1 000 dans les versions antérieures Windows Server
2008 R2. Dans les versions ultérieures, la taille du lot est augmentée à 10 000 pour améliorer les performances de la
suppression dans les forêts où la Corbeille est activée.
Vérifiez les valeurs du paramètre de taille de lot du processus Links. S’il n’est pas par défaut, définissez la valeur à
sa valeur par défaut ou une valeur encore plus petite telle que 1 000, 100 ou même 10.
Des valeurs plus petites diminuent l’utilisation du magasin de versions en supprimant un plus petit nombre d’objets par
suppression, réduisant ainsi le temps total d’effectuer une seule transaction de suppression. Cela a pour effet positif de
réduire le magasin de versions et la fenêtre de temps pour les conflits d’écriture, tandis que vous augmentez le temps
nécessaire pour refléter précisément l’appartenance au groupe dans l’annuaire.
Les services Active Directory vérifient la clé de Registre suivante.

Pour AD DS :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Links process batch size
Pour AD LDS :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<adam instance>\Parameters\Links process batch size
Type : DWORD
Valeur min : 1000
Valeur maximale : 10 000
Cette valeur remplace la valeur par défaut de 10 000 comme nombre de liaisons atomiques à traiter en même
temps. Vous n’avez pas besoin de redémarrer le service d’instance NTDS ou LDS, ni de redémarrer l’ordinateur
pour rendre le paramètre efficace.
Après chaque opération atomique, le magasin de versions correspondant est publié. Le magasin de versions
n’est réacquis que lors de la prochaine opération atomique qui continue à traiter le même objet. Vous avez peut-
être des idées sur la façon de faire en grande partie la baisse de la taille du lot de liens. Vous pouvez la combiner
avec une augmentation du magasin de versions ESE. Si, pour une raison quelconque, vous avez augmenté le
magasin de versions, vous pouvez décider d’augmenter un peu plus ou non la valeur de taille de lot du
processus Liens .
Si vous souhaitez en savoir plus, consultez les articles suivants :
Magasin de versions appelé et ils sont tous en dehors des compartiments
Le contrôleur de domaine s’exécute plus lentement ou cesse de répondre lorsque le processus de collecte de
la garbage collection s’exécute.
Pour contourner ce problème, définissez la valeur de la taille de lot du processus Liens inférieure à 10 000. Cela
réduit le risque de collision d’accès aux objets. Ce faisant, vous rendez le processus de réplication de suppression
d’objets de grande taille plus fiable. En outre, l’intégralité de la transaction prend désormais plus de temps. Cela
vous permet également d’éviter les problèmes de magasin de versions.
References
Présentation de l’itinérance des informations d’identification
Présentation des Read-Only DCS
Les modifications apportées aux groupes de
sécurité ou aux groupes de distribution ne sont pas
répliquées sur les contrôleurs de domaine de
destination lorsque vous utilisez la réplication des
valeurs de lien dans un environnement Windows
Server 2003
Cet article fournit une solution à un problème dans lequel les modifications apportées aux groupes de sécurité
ou aux groupes de distribution ne sont pas répliquées sur les contrôleurs de domaine de destination lorsque
vous utilisez la réplication de valeur de lien.
Symptômes
Prenons le cas de figure suivant. Dans un environnement Windows Server 2003, vous définissez le niveau
fonctionnel de la forêt sur Windows Server 2003 ou sur une version ultérieure de Windows. Vous le faites pour
appliquer des modifications de réplication de valeur de lien (LVR) à l’appartenance au groupe sur les attributs
LVR. Dans ce scénario, vous pouvez être face aux symptômes suivants :
Les modifications apportées au groupe de sécurité ou au groupe de distribution existant sur le contrôleur
de domaine source ne sont pas répliquées sur les contrôleurs de domaine de destination. Ce symptôme
se présente lorsque le changement d’appartenance au groupe est initié par un administrateur ou par un
programme.
Lorsque vous exécutez la commande, vous recevez un message qui indique qu’un contrôleur de domaine
de destination basé sur repadmin /showreps Windows Server 2008 ou Windows Server 2003 ne peut pas
répliquer les modifications entrantes apportées à une partition d’annuaire à partir d’un ou plusieurs
contrôleurs de domaine source. Dans ce cas, vous recevez également une erreur Win32 8451.
NOTE
L’erreur Win32 8451 correspond à l’erreur ERROR_DS_DRA_DB_ERROR et à la description suivante :
Le contrôleur de domaine de destination Windows Server 2008 ou Windows Server 2003 affecté peut ne
pas répliquer les modifications entrantes apportées aux partitions en lecture seule à partir de catalogues
globaux ou de contrôleurs de domaine qui hébergent des partitions d’annuaire accessibles en lecture
seule.
Windows Les contrôleurs de domaine de destination server 2008 et Windows Server 2003 journal des
événements dans le journal du service d’annuaire.
NOTE
L’événement général NTDS 1173 indique un échec de réplication générique.
La valeur d’erreur de données supplémentaire -1603 est m moire à une devise qui n’est pas sur une erreur de
jet d’enregistrement et au nom symbolique errNoCurrentRecord. La faute d’orthographe du texte d’erreur
actuellement dans la devise ne se trouve pas sur un texte d’erreur d’enregistrement.
L’exception e0010004 correspond à une erreur DSA_DB_EXCEPTION.
L’ID 2050344 correspond à une fonction dans le code de couche base de données de NTDS. Ce nombre
dépend du système d’exploitation, du Service Pack et des révisions de correction.
Windows Les contrôleurs de domaine de destination server 2008 et Windows Server 2003 enregistrent
l’événement de service d’annuaire 1692.
NOTE
Cet événement est consigné lorsque vous activez la journalisation des diagnostics et que vous définissez la valeur
de l’entrée de Registre 5 Replication Events sur 1 ou plus.
Pour plus d’informations sur la journalisation des diagnostics NTDS, voir Comment configurer la
journalisation des événements de diagnostic Active Directory et LDS.
Ces symptômes peuvent se produire lorsque des modifications sont apportées à une classe d’objet répliquée
par LVR avec des liaisons avant. (Ces modifications apportées à la classe d’objet répliquée par LVR sont
également apportées aux groupes de sécurité et de distribution.)
Cause
Ce problème se produit si les contrôleurs de domaine de destination basés sur Windows Server 2008 ou
Windows Server 2003 arrêtent la réplication entrante lorsqu’ils reçoivent des mises à jour LVR d’objets qui
n’existent pas dans leurs copies locales d’Active Directory.
Plus précisément, ce problème peut se produire si les conditions suivantes sont vraies :
Les modifications d’appartenance apportées aux groupes de sécurité ou de distribution sur les
contrôleurs de domaine source sont répliquées à l’aide de la réplication de valeur de lien (LVR) vers les
contrôleurs de domaine de destination qui n’ont pas d’instance du groupe en cours de modification. Par
exemple, ce problème peut se produire lorsqu’un objet est supprimé et que la durée de vie des objets
tombstone a expiré à partir de la copie locale d’Active Directory.
Le niveau fonctionnel de la forêt est Windows le mode intermédiaire de Server 2003 ou une version
ultérieure.
Les groupes de sécurité ou de distribution en attente résident sur des partitions en lecture seule ou
accessibles en lecture seule des contrôleurs de domaine source basés sur Windows Server 2003 ou
Windows Server 2008, et la réplication s’arrête entre les contrôleurs de domaine source et de destination.
Résolution
IMPORTANT
sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

1. Exécutez la commande de repadmin suivante sur le contrôleur de domaine principal (PDC) pour créer un
fichier .csv qui contient la liste des contrôleurs de domaine de destination :
repadmin /showrepl * /csv >showrepl.csv
2. Ouvrez le fichier .csv dans Excel, puis identifiez les échecs de réplication sur les contrôleurs de domaine
de destination qui ont échoué au processus de réplication entrante et qui affichent l’erreur Win32 8451.
3. Sur les contrôleurs de domaine qui enregistrent le message d’erreur « Erreur Win32 8451 », assurez-vous
que la journalisation des diagnostics pour l’entrée de Registre 5 Événements de réplication est définie
sur la valeur 1 . Pour cela, procédez comme suit :
a. Cliquez sur Démarrer , puis sur Exécuter .
b. Dans la zone Ouvrir, tapez regedit, puis cliquez sur OK.
c. Recherchez, puis cliquez sur la clé de Registre suivante :
d. Dans le volet d’informations, double-cliquez sur 5 Événements de réplication, tapez 1 dans la

zone de données Valeur, puis cliquez sur OK .
e. Fermez l'Éditeur du registre.
4. Sur les contrôleurs de domaine de destination, vérifiez que l’événement du service d’annuaire 1692 est
enregistré dans le journal du service d’annuaire. L’événement affiche les modifications apportées à
l’attribut membre du groupe de sécurité ou à d’autres attributs répliqués par LVR et aux GUID d’objet en
attente.
5. Supprimez les objets en attente des contrôleurs de domaine de destination Windows Server 2008 ou
Windows Server 2003 à l’aide de la repadmin /removelingeringobjects commande.
IMPORTANT
La désactivation de la fonctionnalité de cohérence de réplication stricte dans le Registre des contrôleurs de domaine de
destination basés sur Windows Server 2008 ou Windows Server 2003 ne reprend pas la réplication. Vous ne devez pas
définir la valeur de l’entrée de Registre Cohérence de réplication stricte sur 0 pour débloquer la réplication des partitions
d’annuaire.
Ne forcez pas la réplication des partitions d’annuaire sur les contrôleurs de domaine source à l’aide de la commande
repadmin /sync ou d’une commande équivalente avec le commutateur /force.
Échec du test VERIFYReferences de DCDiag lorsque
vous utilisez DFSR pour répliquer SYSVOL
Cet article fournit une solution à une erreur qui se produit lorsque vous utilisez le service de réplication du
système de fichiers distribués (DFSR) pour répliquer le dossier sysvol.
Symptômes
Vous utilisez le service de réplication du système de fichiers distribués (DFSR) pour répliquer le dossier
sysvol.
Tous les contrôleurs de domaine exécutent Windows Server 2008 R2 ou une version ultérieure.
Vous exécutez l’outil de diagnostics du contrôleur de domaine (DCDiag) pour générer un rapport sur la
réplication.
Dans ce scénario, DCDiag renvoie le message d’erreur suivant :
échec du test VerifyReferences
Le rapport DCDiag contient l’entrée suivante :
Problem: Missing Expected Value

Base Object: CN=<DCNAME>,OU=Domain Controllers,DC=<DOMAIN>,DC=<COM>
Base Object Description: "DC Account Object"
Value Object Attribute Name: frsComputerReferenceBL
Value Object Description: "SYSVOL FRS Member Object"
Recommended Action: See Knowledge Base Article: Q312862
Lorsque ce problème se produit, DCDiag valide l’objet de référence pour DFSR. En outre, le service de réplication
de fichiers NT (NTFRS) s’arrête.
Cause
Ce problème se produit car il n’existe aucune référence du service de réplication de fichiers (FRS) dans la base
de données Active Directory sous l’objet contrôleur de domaine lorsque DFSR est utilisé pour la réplication
sysvole. Au lieu de cela, il n’existe qu’un objet pour la DFSR.
Cette logique n’est pas incluse dans les versions antérieures de DCDiag, comme DCDiag pour Windows Server
2008 ou DCDiag installé avec les outils de support Windows Server 2003. Par exemple, ces versions recherchent
la référence de membre FRS et génèrent une erreur false dans DCDiag.
Résolution
Pour résoudre ce problème, exécutez Dcdiag.exe à partir de %windir%\System32 . Ce dossier contient la dernière
version de DCDiag Windows 2008 et Windows 2008 R2. En exécutant la dernière version de DCDiag, la
réplication sysvol réussira le test VerifyReferences.
À la place, si la suite Windows Support Tools est installée sur Windows Server 2008 R2, désinstallez-la. Ce qui
résout le problème et vous permet d’exécuter Dcdiag.exe partir de n’importe quel emplacement.
Même si vous utilisez les dernières version de DCDiag, l’erreur mentionnée dans la section Symptômes peut
toujours se produire si l’attribut msDFSR-Flags dans la ligne CN= <DCNAME> ,OU=Contrôleurs de
domaine,DC= <DOMAIN> ,DC= dans l’entrée DCDiag est manquant ou ne correspond pas à l’un des indicateurs
<COM> suivants :
Phase redirigée : msDFSR-Flags on CN=dfsr-LocalSettings 0x20 (32 dez)
Phase supprimée : msDFSR-Flags on CN=dfsr-LocalSettings 0x30 (48 dez)
Dans ce cas, DCDiag suppose à tort que le service de réplication de fichiers (FRS) est toujours configuré pour
SYSVOL et tente de vérifier les objets et attributs FRS dans une base de données Active Directory qui n’existe
pas. Vous pouvez donc vous attendre à ce que la vérification échoue.
Diagnostiquer les échecs de réplication Active
Directory
Cet article explique comment diagnostiquer les échecs de réplication Active Directory.
Symptômes
Vous remarquerez peut-être qu’Active Directory ne parvient pas à répliquer dans les conditions suivantes :
Les outils de surveillance, y compris l’Outil d’état de réplication Active Directory (ADREPLSTATUS) et
REPADMIN, exposent les échecs de réplication.
Les administrateurs, les utilisateurs ou les applications détectent que les objets créés et modifiés dans Active
Directory n’existent pas sur tous les contrôleurs de domaine (DCS) dans une étendue de réplication
commune.
Cause
La réplication des services de domaine Active Directory (AD DS) présente les dépendances suivantes :
Connectivité réseau sur les ports et protocoles utilisés par le service ADDS
Résolution de noms DNS pour résoudre le nom d’un partenaire de réplication en adresse IP
Authentification et autorisation
Précision dans les 5 minutes pour prendre en charge l’authentification Kerberos
Base de données d’annuaire
Topologie de réplication Active Directory pour créer des objets de connexion entre les partenaires de
réplication
Moteur de réplication ADDS
Résolution
Utilisez l’une des méthodes suivantes pour afficher les erreurs de réplication :
Téléchargez et exécutez l’outil Microsoft Assistant Support et récupération ou exécutez l’outil de
réplication d’état AD sur les DCS.
Lire l’état de réplication dans la repadmin /showrepl sortie.
Repadmin fait partie des outils d’administration de serveur distant (RSAT). Si vous utilisez
Windows 10 version 1803 ou une version antérieure de Windows, téléchargez les outils
d’administration de serveur distant (RSAT).
Dans Windows 10, version 1809 et les versions ultérieures de Windows 10, vous pouvez installer
la fonctionnalité RSAT via Paramètres > gérer les fonctionnalités facultatives.
À repadmin utiliser pour identifier les erreurs de réplication Active Directory à l’échelle de la forêt
Vous pouvez créer une feuille de calcul Microsoft Excel pour les contrôleurs de domaine à l’aide de la
repadmin/showrepl commande pour afficher les erreurs de réplication. Pour ce faire, suivez les étapes suivantes :
1. Ouvrez une invite de commandes en tant qu’administrateur :
Dans le menu Démarrer, cliquez avec le bouton droit sur Invite de commandes, puis cliquez sur
Exécuter en tant qu’administrateur. Si la boîte de dialogue Contrôle de compte d’utilisateur
s’affiche, Enterprise informations d’identification administrateurs, puis cliquez sur Continuer .
repadmin /showrepl * /csv >showrepl.csv
3. Dans Excel, ouvrez showrepl.csv.

4. Formater la feuille de calcul comme suit :
a. Masquer ou supprimer les colonnes A et G.
b. Sélectionnez la ligne 1 sous la ligne d’en-tête de colonne. Sous l’onglet Affichage, cliquez sur Figer
les volets, puis cliquez sur Figer la ligne supérieure.
c. Sélectionnez la feuille de calcul entière. Sous l’onglet Données, cliquez sur Filtre.
d. Dans la colonne Heure de la dernière réussite, cliquez sur la flèche vers le bas, pointez sur Filtres de
texte, puis cliquez sur Filtre personnalisé.
e. Trier le tableau du plus ancien au plus récent.
f. Dans la colonne Source DC ou Source DSA, cliquez sur la flèche du filtre vers le bas, pointez sur
Filtres de texte, puis cliquez sur Filtre personnalisé.
g. Dans la boîte de dialogue Filtre automatique personnalisé, sous Afficher les lignes où , cliquez
sur ne contient pas . Dans la zone de texte adjacente, tapez del pour éliminer les contrôleurs de
domaine supprimés de l’affichage.
h. Répétez l’étape 6 pour la colonne Heure de la dernière défaillance, mais utilisez la valeur qui n’est pas
égale, puis tapez la valeur 0 .
5. Pour corriger les échecs de réplication qui apparaissent sous État de la dernière défaillance, voir
comment résoudre les erreurs de réplication Active Directory courantes.
Comment désactiver le contrôle de cohérence des
connaissances de la création automatique de la
topologie de réplication
Cet article explique comment désactiver le contrôle de cohérence des connaissances de la création automatique
de la topologie de réplication.
Résumé
Le contrôle de cohérence des connaissances (KCC) est un composant Microsoft Windows 2000 et Microsoft
Windows Server 2003 qui génère et maintient automatiquement la topologie de réplication intras site et inters
site. Vous pouvez désactiver la génération automatique du KCC de la gestion de la topologie intras site ou inters
site, ou les deux.
Dans certains cas, vous pouvez créer manuellement des connexions de réplication pour adapter la topologie de
réplication, mais cela augmente la charge de travail de surveillance des modifications de la topologie réseau
décrites dans Active Directory ou des échecs de réplication qui se produisent sur les contrôleurs de domaine.
Le KCC s’exécute à intervalles réguliers pour ajuster la topologie de réplication pour les modifications qui se
produisent dans Active Directory, telles que l’ajout de nouveaux contrôleurs de domaine et de nouveaux sites
créés. En même temps, le KCC examine l’état de réplication des connexions existantes pour déterminer si les
connexions ne fonctionnent pas. Si une connexion ne fonctionne pas, une fois qu’un seuil est atteint, le KCC crée
automatiquement des connexions temporaires à d’autres partenaires de réplication (le cas contraire) pour
s’assurer que la réplication n’est pas bloquée.
NOTE
Lorsque la gestion de la topologie de réplication automatique est désactivée, la détection de failover mentionnée ci-
dessus est également désactivée.
Vous pouvez utiliser l’outil Ldp.exe inclus dans le Kit de ressources Windows 2000 ou Windows Server 2003
pour effectuer des recherches LDAP (Lightweight Directory Access Protocol) dans Active Directory pour obtenir
des informations spécifiques selon les critères de recherche. Cela vous permet également d’interroger des
données qui ne sont pas visibles à l’aide des outils d’administration inclus Windows 2000. Toutefois, toutes les
informations renvoyées dans les requêtes LDP sont soumises aux autorisations de sécurité.
Comment modifier Active Directory pour désactiver le KCC pour un site
1. Exécutez Setup.exe (s’il n’est pas déjà installé) à partir du dossier Outils de support du \ CD-ROM
Windows 2000 ou Windows Server 2003. Cette installation installe le Kit d’outils de support technique.
2. Exécuter Ldp.exe
3. Dans le menu Connexion, cliquez sur Connecter.
4. Tapez le nom de serveur d’un contrôleur de domaine dans l’entreprise, vérifiez que le paramètre de port
est 389, cliquez pour effacer la case à cocher sans connexion, puis cliquez sur OK. Une fois la connexion
terminée, les données spécifiques au serveur s’affichent dans le volet droit.
5. Dans le menu Connexion, cliquez sur Lier. Tapez le nom d’utilisateur, le mot de passe et le nom de
domaine (au format DNS) dans les zones appropriées (vous devrez peut-être cliquer pour sélectionner la
case à cocher Domaine), puis cliquez sur OK. Si la liaison réussit, vous devez recevoir un message dans le
volet droit semblable à l’exemple suivant :
Authentifié en tant que dn : YourUserID
6. Dans le menu Affichage, cliquez sur Arborescence.
7. Dans la zone BaseDN, tapez le nom de l’objet de site dans le conteneur de configuration de la forêt. Par
exemple, pour le site Default-First-Site-Name dans la forêt, le nom de domaine ressemble à Mydomain.com
l’exemple suivant :
CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM
Si cet objet se trouve, LDP doit afficher l’objet dans le volet gauche.
8. Développez l’affichage. L’un des objets enfants doit commencer par CN=NTDS Site Paramètres. Double-
cliquez sur cet objet. Dans le volet droit, LDP doit obtenir les paramètres actuels pour les attributs de cet
objet. Chaque attribut est précédé d’un nombre, puis d’un crochet (>). Le nombre représente le nombre
de valeurs que contient l’attribut.
9. Recherchez l’attribut « options ». S’il n’est pas présent, cela est normal et facilite la modification de la
valeur.
NOTE
Si l’attribut « options » est présent et que la valeur n’est pas 0, vous devez déterminer les indicateurs actuels qui
sont définies et utiliser les valeurs ci-dessous pour construire la nouvelle valeur avant de continuer à l’étape
suivante.
10. Dans le volet droit, recherchez le début de la sortie de l’objet site Paramètres NTDS. Il ressemble à
l’exemple suivant :
Développement de la base 'CN=NTDS Site Paramètres,CN=Default-First-Site-

Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM'...
Résultat <0> : (null)
DNs de correspondance :
Obtention d’une entrée :
>> Dn : CN=NTDS Site Paramètres,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM
11. Copiez la chaîne de données de la partie « >> Dn » de la sortie LDP.

12. Dans le menu Parcourir, cliquez sur Modifier. Dans la zone Dn, collez la chaîne que vous avez copiée à
l’étape précédente.
13. Dans la zone Attribut, tapez options.
14. Dans la zone Valeurs, tapez la valeur appropriée :
Pour désactiver la génération automatique de topologie intras site, utilisez la valeur 1 (décimal).
Pour désactiver la génération automatique de topologies intersesses, utilisez la valeur 16 (décimal).
Pour désactiver la génération de topologies intras site et inters site, utilisez la valeur 17 (décimal).
15. Dans la zone Opération, cliquez sur Remplacer, sur Entrée, puis sur Exécuter.
16. Dans le volet droit, la sortie doit ressembler à l’exemple suivant si l’opération réussit :
Call Modify... ldap_modify_s(ld,'CN=NTDS Site Paramètres,CN=Default-First-Site-

Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM',[1] attrs);
Modification de « CN=NTDS Site Paramètres,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=MYDOMAIN,DC=COM ».
NOTE
Pour ré-activer la génération du KCC, supprimez la valeur que vous avez entrée à l’étape 14 de cette section.
Pour déterminer si ces valeurs sont définies correctement, vous pouvez utiliser le Moniteur de réplication Active
Directory (également inclus dans l’installation des outils de support technique) pour générer un rapport sur la
configuration du site. La sortie incluse dans ces informations est similaire à l’exemple suivant :
Nom du site : Default-First-Site-Name

---------------------------------------
Options du site : NTDSSETTINGS_OPT_IS_AUTO_TOPOLOGY_DISABLED
NTDSSETTINGS_OPT_IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED
Générateur de topologie de site : CN=NTDS Paramètres,CN=ESTAD-PROXY,CN=Servers,CN=Default-First-
Site-Name,CN=Sites,CN=Configuration,DC=ifr,DC=com
Renouvellement de la topologie de site :
Failover de topologie de site :
NOTE
NTDSSETTINGS_OPT_IS_AUTO_TOPOLOGY_DISABLED signifie que la gestion de la topologie intras site est désactivée et
NTDSSETTINGS_OPT_IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED que la gestion de la topologie inters site est désactivée.
Des connexions de réplication Active Directory en
double sont créées
Cet article fournit une solution à un problème dans lequel des connexions de réplication Active Directory en
double sont créées pour un ou plusieurs contrôleurs de domaine sur un ou plusieurs sites.
Symptômes
Dans les sites et services Active Directory, des connexions de réplication Active Directory en double sont créées
pour un ou plusieurs contrôleurs de domaine sur un ou plusieurs sites.
Cause
Ce problème est dû à un manque de connectivité réseau ou à un autre problème qui interrompt la réplication
sur le générateur de topologie intersite (ISTG) du site. Si l’ISTG ne peut pas atteindre d’autres contrôleurs de
domaine, il tente de créer de nouvelles connexions de réplication Active Directory (en double) pour les
contrôleurs de domaine dans le même site.
NOTE
S’il s’agit d’une condition temporaire, rien ne nettoie les objets de connexion en double. Si le problème de connectivité et
de réplication ne se produit plus sur l’ISTG, vous devez supprimer manuellement les objets de connexion en double, puis
réexécuter l’ISTG pour vous assurer que les doublons ne sont pas repadmin /kcc re-créés.
Pour collecter les données pertinentes pour ce problème, suivez ces étapes.
NOTE
Repadmin /kcc <DCNAME> est la commande qui force l’exécuter. Toutefois, elle ne crée pas de connexion si l’autre
connexion est toujours en place.
Replace <DCNAME> avec le nom du contrôleur de domaine qui sert d’ISTG pour le site.
1. Exécutez repadmin /showconn <DCNAME> >showconn.txt .

2. Exécutez repadmin /failcache <DCNAME> >failcache.txt .
3. Exécutez PortQRYUI sur et ciblez un contrôleur de domaine distant avec qui vous avez des connexions en
<DCNAME> double, comme suit :
« Test des domaines et des trusts » Fichier /Résultat de l’enregistrement
4. On <DCNAME> , run repadmin /bind RemoteDC (from step 3). Par exemple : repadmin /bind RemoteDC1
5. Si vous ne parvient pas à vous connecter, tracez le réseau à l’aide de netsh sur les deux contrôleurs de
repadmin /bind domaine, comme suit :
a. Exécutez netsh trace start capture=yes tracefile=c:\%computername%.etl .
b. Exécutez repadmin /bind <DCNAME> .
c. Connecter à l’aide du nom de domaine complet au lieu du nom d’hôte, si possible.
d. Exécutez netsh trace stop .
6. Exécutez repadmin /showrepl * /csv >showrepl.csv .
7. Exécutez repadmin /viewlist * >DCs.txt .
8. Exécutez repadmin /istg >istg.txt .
Résolution
Pour résoudre ce problème, ouvrez les ports dans le site pour permettre à l’ISTG de se connecter aux contrôleurs
de domaine. Une fois le problème de connectivité résolu, supprimez les objets de connexion en double, puis
réexécutez le KCC sur le groupe istg.
Pour plus d’informations sur ce problème, voir fonctionnement de la topologie de réplication Active Directory.
Concentrez-vous particulièrement sur la section de génération de KCC et de topologie et sur le sous-site «
Serveurs de non-réponse exclus ».
Comment obtenir et utiliser l’outil d’état de
réplication Active Directory
Cet article présente l’outil d’état de réplication Active Directory (ADREPLSTATUS). Cet outil permet aux
administrateurs d’identifier, de hiérarchiser et de corriger les erreurs de réplication Active Directory sur un
contrôleur de domaine unique (DC) ou sur tous les DCS se trouver dans un domaine ou une forêt Active
Directory.
Vous trouverez ADREPLSTATUS dans le Centre de téléchargement Microsoft. Vous pouvez également le trouver
dans Microsoft Operations Management Suite (OMS), la solution de gestion informatique cloud tout-en-un de
Microsoft.
Si vous exécutez l’outil, puis recevez un message vous messageant que la licence a expiré, téléchargez et installez
à nouveau l’outil. ADREPLSTATUS a été récemment mis à jour dans le Centre de téléchargement Microsoft.
Fonctionnalités
Découverte automatique des DCS et des domaines dans la forêt Active Directory à laquelle l’ordinateur
exécutant ADREPLSTATUS est joint.
Le mode « Erreurs uniquement » permet aux administrateurs de se concentrer uniquement sur les DCS
signalant des échecs de réplication. Pour en savoir plus, voir ci-dessous.
Lorsque ADREPLSTATUS détecte des erreurs de réplication, l’outil s’appuie sur son intégration au contenu de
résolution sur Microsoft TechNet pour afficher les étapes de résolution des principales erreurs de réplication
AD. Pour en savoir plus, voir ci-dessous.
Tri et regroupement enrichis des résultats en cliquant sur un seul en-tête de colonne (tri) ou en faisant glisser
un ou plusieurs en-têtes de colonne vers la barre de filtre. Utilisez une ou les deux options pour organiser la
sortie par dernière erreur de réplication, date de réussite de la dernière réplication, contexte d’attribution de
noms dc source, date de réussite de la réplication, etc.
Exportez les données d’état de réplication afin qu’elles soient importées et consultables par les
administrateurs de domaine source, les administrateurs de domaine de destination ou les professionnels du
support technique dans Microsoft Excel ou ADREPLSTATUS.
Choisissez les colonnes à afficher et leur ordre d’affichage. Ces paramètres sont enregistrés en tant que
préférence sur l’ordinateur ADREPLSTATUS.
NOTE
ADREPLSTATUS est un outil en lecture seule qui ne modifie pas la configuration ou les objets d’une forêt Active Directory.
L’interface utilisateur ADREPLSTATUS se compose d’une barre d’outils Microsoft Office ruban de style utilisateur
pour exposer différentes fonctionnalités. L’onglet Visionneuse d’état de réplication affiche l’état de
réplication pour tous les DCS de la forêt. La capture d’écran suivante montre ADREPLSTATUS mettant en
surbrillance un dc qui n’a pas été répliqué dans la durée de vie de Tombstone en nombre de jours (identifié ici
par le codage de couleurs noir).
Erreur uniquement
En utilisant le bouton Erreurs uniquement (en haut à droite de l’image ci-dessous), vous pouvez filtrer les DCS
sains pour vous concentrer sur les DCS de destination signalant des erreurs de réplication :
Analyse des erreurs de réplication

Le Guide des erreurs de réplication possède un affichage Résumé des erreurs détectées qui enregistre chaque
erreur de réplication unique qui se produit sur l’ensemble de PC ciblés par l’administrateur.
La sélection de l’un des codes d’erreur de réplication charge le contenu de dépannage recommandé pour cette
erreur. Par exemple, voici une capture d’écran de l’affichage de l’article TechNet sur l’erreur de réplication Active
Directory 1256 :
Les objectifs de cet outil sont d’aider les administrateurs à identifier et corriger les erreurs de réplication Active
Directory avant qu’elles ne provoquent des pannes ou des pannes d’applications et d’utilisateurs, ou que des
objets en attente provoquent des échecs de réplication à court ou à long terme, et qu’ils donnent aux
administrateurs plus d’informations sur le fonctionnement de la réplication Active Directory dans leurs
environnements.
La version actuelle d’ADREPLSTATUS à partir de cette publication est 2.2.20717.1 (comme indiqué sur l’écran de
démarrage ADREPLSTATUS).
ADREPLSTATUS ne fonctionne pas lorsque le paramètre de sécurité suivant est activé dans Windows -
Chiffrement système : utiliser des algorithmes de chiffrement conformes à la norme FIPS 140, y compris les
algorithmes de chiffrement, de hachage et de signature.
Une coche supplémentaire s’affiche en bas du s’il s’agit d’une colonne lorsque vous cliquez avec le bouton
droit sur un en-tête de colonne.
NOTE
L’outil ADRPLSTATUS est pris en charge par l’équipe Microsoft ADREPLSTATUS. Les administrateurs et les professionnels
du support technique qui font l’expérience d’erreurs lors de l’installation ou de l’exécution d’ADREPLSTATUS peuvent
envoyer un rapport de problème.
Pour les problèmes connus, l’équipe ADREPLSTATUS signale l’état sur la même page. Si votre problème nécessite une
investigation supplémentaire, l’équipe ADREPLSTATUS vous contactera à l’adresse de messagerie que vous avez fournie
dans votre rapport de problèmes.
Le temps nécessaire pour fournir une solution dépend de la charge de travail de l’équipe, ainsi que de la complexité et de
la cause du problème. Les défauts de code dans l’outil ADREPLSTATUS peuvent généralement être résolus relativement
rapidement. Les défaillances d’outils en raison de causes externes peuvent prendre plus de temps, sauf si une solution de
contournement est trouvée.
L’équipe ADREPLSTATUS ne peut pas corriger les erreurs de réplication Active Directory identifiées par l’outil
ADREPLSTATUS. Contactez votre fournisseur de support pour résoudre le problème. Vous pouvez également soumettre
des erreurs de réplication et les recherches sur ce forum TechNet Windows Server.
Liste des correctifs actuellement disponibles pour les
technologies de système de fichiers distribués (DFS)
dans Windows Server 2012 et Windows Server 2012
R2
Cet article répertorie les correctifs logiciels actuellement disponibles pour les utilisateurs qui ont installé des
technologies de système de fichiers distribués (DFS) sur un ordinateur Windows Server 2012 ou un ordinateur
Résumé
Les articles de la Base de connaissances Microsoft répertoriés dans cet article décrivent les correctifs
disponibles. Si vous avez installé des technologies DFS sur un ordinateur Windows Server 2012 ou un
ordinateur Windows Server 2012 R2, nous vous recommandons d’examiner et d’installer les correctifs logiciels
décrits dans plus d’informations.
Remarque. Les deux technologies dans DFS sont les espaces de noms DFS (DFS-N) et la réplication DFS (DFS-R).
Une approche de maintenance consistant à installer les déploiements mensuels offre aux clients un modèle
cohérent pour rester à jour et sécurisé. Vous pouvez remplacer un reup mensuel plus récent par un ancien
rapport mensuel. Le reste des mises à jour de cette liste est toujours requis, car certains composants de ces
mises à jour ont été publiés avant octobre 2016 et ne sont pas inclus dans un dernier déploiement mensuel.
Pour plus d’informations sur cette approche de maintenance, voir Simplified servicing for Windows 7 and
Windows 8.1: the latest improvements.

Vous pouvez obtenir les derniers correctifs pour ces composants DFS en installant les mises à jour suivantes :
KB 4056895 : 8 janvier 2018-KB4056895 (déploiement mensuel) ou ultérieur
KB 2996883 : DFSR arrête la réplication après un arrêt inattendu dans un environnement Windows 8.1 ou
Mise à jour 3000850 de la 3000850 : mise à jour de novembre 2014 pour Windows RT 8.1, Windows 8.1 et
KB 3046481 : le déploiement d’espaces de noms DFS entraîne un délai d’accès ou de délai d’accès lent
lorsque vous accédez au partage DFS dans Windows Server 2012 R2
Windows Server 2012

Vous pouvez obtenir les derniers correctifs pour ces composants DFS en installant les mises à jour suivantes :
KB 4025331 : 11 juillet 2017-KB4025331 (déploiement mensuel) ou ultérieur
Base de 2884176 : travaux en souffrance importants sur Windows serveurs DFSR basés sur la base de la
base de données
KB 2962407 : Windows RT, Windows 8 et Windows Server 2012 de mise à jour : juin 2014
NOTE
Certains des tableaux suivants contiennent des cellules vides pour s’adapter aux informations qui seront fournies
ultérieurement.
Espaces de noms DFS

P O URQ UO I N O US T Y P E ET
A RT IC L E DE L A B A SE REC O M M A N DO N S DISP O N IB IL IT É DES
DAT E D’A JO UT DE C O N N A ISSA N C ES T IT L E C E C O RREC T IF C O RREC T IF S
15 avril 2020 4056895 8 janvier 2018- Ce rapport mensuel Inclus dans le 3

KB4056895 contient la version janvier 2018-
(déploiement 6.3.9600.18895 de KB4056898 (mise à
mensuel) Dfsc.sys. (côté client). jour de sécurité
uniquement).. Inclus
dans les rapports
mensuels du 8
janvier 2018-
KB4056895 et les
autres.
06 mars 2015 3046481 Le déploiement des Ce correctif contient Pour installer cette
espaces de noms DFS la version la plus mise à jour, vous
entraîne un délai récente de Dfssvc.exe devez avoir installé
d’accès ou de délai pour Windows Server Windows Server
d’accès lent lorsque 2012 R2. 2012 R2.
vous accédez au
partage DFS dans
Windows Server
2012 R2.
Windows Server 2012
15 avril 2020 3192406 Aperçu d’octobre Ce déploiement Inclus dans la

2016 du rapport de mensuel contient la prévisualisation
qualité mensuel pour version d’octobre 2016 du
Windows Server 6.2.9200.21968 de rapport de qualité
2012 Dfssvc.exe et la mensuel pour les
version Windows Server
6.2.9200.21976 de 2012 et les autres.
Dfsc.sys pour
Windows Server
2012.
Réplication DFS
15 avril 2020 4038774 19 septembre 2017- Ce rapport mensuel Inclus dans le 19

KB4038774 (aperçu contient la version septembre 2017-
du rapport mensuel) 6.3.9600.18776 de KB4038774
Dfsrs.exe pour (prévisualisation des
Windows Server rapports mensuels)
2012 R2. et les déploiements
mensuels ultérieurs.
Non applicable Ce correctif contient Pour installer ce

la version la plus correctif, vous devez
récente de Dfsrro.sys avoir installé
pour Windows Server Windows Server
2012 R2. 2012 R2.
Non applicable Ce correctif contient

la version la plus
récente de
Dfsrclus.dll pour
Windows Server
2012 R2.
31 août 2014 2996883 DFSR interrompt la Ce correctif logiciel Pour appliquer ce

réplication après un contient les versions correctif logiciel, vous
arrêt inattendu dans les plus récentes devez Windows
un environnement Dfsrdiag.exe et Server 2012 R2 et
Windows 8.1 ou Dfsrmig.exe pour mise à jour d’avril
Windows Server Windows Server 2014 2919355.
2012 R2 2012 R2.
Windows Server 2012
14 février 2015 2884176 Retards importants Ce correctif contient Pour installer ce

sur Windows la version la plus correctif logiciel, vous
serveurs DFSR basés récente des Dfsrs.exe devez Windows
sur un serveur et Dfsrress.dll pour Server 2012 installé.
Windows Server Ce correctif logiciel
2012. est disponible pour
téléchargement
individuel.
Jan-10 2016 3121255 0x00000024'erreur Ce correctif logiciel Pour installer ce

d’arrêt dans contient une mise à correctif logiciel, vous
FsRtlNotifyFilterRepor jour Ntfs.sys pour devez Windows
tChange et la Windows Server Server 2012 installé.
sauvegarde VSS du 2012. Ce correctif logiciel
serveur de données est disponible pour
personnelles échoue téléchargement
dans Windows individuel. Ce
correctif est
également inclus
dans les correctifs
mensuels du 11
juillet 2017-
KB4025331 (
correctifs mensuels)
et les correctifs
mensuels ultérieurs.
Réplication DFS : migration Sysvol
Non applicable Ce correctif logiciel Pour installer ce

contient les versions correctif logiciel, vous
les plus récentes devez Windows
Dfsrdiag.exe et Server 2012 installé.
Dfsrmig.exe pour
Windows Server
2012.
Robocopy
18-Nov-2014 3000850 Rollup de mise à jour Ce correctif contient Pour installer ce

de novembre 2014 la version la plus déploiement de mise
pour Windows RT récente de à jour, vous devez
8.1, Windows 8.1 et Robocopy.exe. avoir installé
Windows Server Windows Server
2012 R2 Robocopy peut être 2012 R2 et la mise à
utilisé pour pré- jour d’avril 2014
amorcer des données 2919355.
pour de nouveaux
dossiers répliqués et
est également utilisé
pendant la migration
de Sysvol de FRS vers
DFSR.
Windows Server 2012
16 mai 2014 2962407 Windows RT, Ce correctif contient Pour installer ce

Windows 8 et la version la plus correctif logiciel, vous
Windows Server récente de devez Windows 8 ou
2012 de mise à jour : Robocopy.exe. Windows Server
juin 2014 2012 installé.
Robocopy peut être
utilisé pour pré-
amorcer des données
pour de nouveaux
dossiers répliqués et
est également utilisé
pendant la migration
de Sysvol de FRS vers
DFSR.
Sous-clés de Registre liées à DFS qui ont été introduites dans les correctifs logiciels ou les mises à jour de sécurité
A RT IC L E DE L A B A SE DE
DAT E C O N N A ISSA N C ES SO US- C L É DE REGIST RE
21 janvier 2012 KB 2663685 HKLM\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRe
18 novembre. 2009 KB 967326 HKLM\System\CurrentControlSet\Services\DFSR\Parameters\Settings\RpcContextHand
References
KB 968429 : liste des correctifs logiciels actuellement disponibles pour les technologies de système de
fichiers distribués (DFS) dans Windows Server 2008 et Windows Server 2008 R2
KB 2473205 : liste des correctifs logiciels actuellement disponibles pour les technologies des services de
fichiers dans Windows Server 2008 et Windows Server 2008 R2
KB 2899011 : liste des correctifs actuellement disponibles pour les technologies des services de fichiers dans
Windows Server 2012 et Windows Server 2012 R2
Comment limiter le trafic RPC Active Directory à un
port spécifique
Cet article explique comment restreindre le trafic RPC (Appel de procédure distante) de réplication Active
Directory (AD) à un port spécifique dans Windows Server.
S’applique à : toutes les versions de Windows Server
Résumé
Par défaut, les appels de procédure distante de réplication Active Directory (RPC) se produisent dynamiquement
sur un port disponible via le rpc endpoint Mapper (RPCSS) à l’aide du port 135. Un administrateur peut
remplacer cette fonctionnalité et spécifier le port transitant par tout le trafic RPC Active Directory. Cette
procédure verrouille le port.
Lorsque vous spécifiez les ports à utiliser à l’aide des entrées de Registre dans Plus d’informations, le trafic de
réplication côté serveur Active Directory et le trafic RPC client sont envoyés à ces ports par le mapper de point
de terminaison. Cette configuration est possible car toutes les interfaces RPC pris en charge par Active Directory
s’exécutent sur tous les ports sur lesquels elle est à l’écoute.
NOTE
Cet article ne décrit pas comment configurer la réplication AD pour un pare-feu. Des ports supplémentaires doivent être
ouverts pour que la réplication fonctionne via un pare-feu. Par exemple, les ports doivent être ouverts pour le protocole
Kerberos. Pour obtenir la liste complète des ports requis pour les services à travers un pare-feu, voir Vue d’ensemble du
service et exigences relatives aux ports réseau pour Windows.
IMPORTANT
Lorsque vous vous connectez à un point de terminaison RPC, le runtime RPC sur le client contacte le RPCSS sur
le serveur sur un port connu (135). Il obtient également le port à connecter pour le service qui assure la prise en
charge de l’interface RPC souhaitée. Il part du principe que le client ne connaît pas la liaison complète. Il s’agit de
la situation de tous les services RPC AD.
Le service enregistre un ou plusieurs points de terminaison au démarrage et a le choix entre un port affecté
dynamiquement ou un port spécifique.
Si vous configurez Active Directory et Netlogon pour qu’ils s’exécutent au por t x comme dans l’entrée suivante,
ils deviennent les ports inscrits auprès du mappeur de point de terminaison en plus du port dynamique
standard.
Utilisez l’Éditeur du Registre pour modifier les valeurs suivantes sur chaque contrôleur de domaine où les ports
restreints doivent être utilisés. Les serveurs membres ne sont pas considérés comme des serveurs d’accès.
L’affectation de port statique pour NTDS n’a donc aucun effet sur les serveurs membres.
Les serveurs membres ont l’interface RPC Netlogon, mais elle est rarement utilisée. Voici quelques exemples de
récupération de configuration à distance, par exemple nltest /server:member.contoso.com /sc_query:contoso.com
.
Clé de Registre 1
Valeur de Registre : port TCP/IP
Données de valeur : (port disponible)
Redémarrez l’ordinateur pour que le nouveau paramètre devienne effectif.

Clé de Registre 2
Valeur de Registre : DCTcpipPort
Redémarrez le service Netlogon pour que le nouveau paramètre devienne effectif.
NOTE
Lorsque vous utilisez l’entrée de Registre et que vous la définissez sur le même port que l’entrée de Registre, vous recevez
l’événement d’erreur DCTcpipPort TCP/IP Port Netlogon 5809 sous NTDS\Parameters . Cela indique que le port
configuré est en cours d’utilisation et que vous devez choisir un autre port.
Vous recevrez le même événement lorsque vous avez un port unique et que vous redémarrez le service
Netlogon sur le contrôleur de domaine. Ce comportement est inhérent au produit. Elle se produit en raison de la
façon dont le runtime RPC gère ses ports de serveur. Le port sera utilisé après le redémarrage et l’événement
peut être ignoré.
Les administrateurs doivent vérifier que la communication sur le port spécifié est activée si des périphériques
ou logiciels réseau intermédiaires sont utilisés pour filtrer les paquets entre les contrôleurs de domaine.
Souvent, vous devez également définir manuellement le port RPC du service de réplication de fichiers (FRS), car
la réplication AD et FRS est répliquée avec les mêmes contrôleurs de domaine. Le port RPC FRS doit utiliser un
autre port.
Ne supposez pas que les clients utilisent uniquement les services RPC Netlogon et que seul le paramètre
DCTcpipPort est donc requis. Les clients utilisent également d’autres services RPC tels que SamRPC, LSARPC et
l’interface des services de réplication d’annuaire (DRS). Vous devez toujours configurer les paramètres du
Registre et ouvrir les deux ports sur le pare-feu.
Après avoir spécifié les ports, vous pouvez rencontrer les problèmes suivants :
Longue durée d’accès après avoir définie un port statique spécifique pour NTDS et Netlogon dans un
environnement de domaine Windows Server 2008 R2
Échec de la réplication AD avec un problème RPC après avoir fixé un port statique pour NTDS dans un
Windows de domaine basé sur Windows de domaine
L’échec de l’Windows après la limitation du trafic RPC client à DC dans Windows Server 2012 R2 ou
Pour résoudre les problèmes, installez les mises à jour mentionnées dans les articles.
Informations sur les objets en attente dans une forêt
Windows Server Active Directory de données
Cet article fournit des informations sur les objets en attente dans Windows Server Active Directory forêt.
Résumé
Cet article contient des informations sur les objets en attente dans une forêt Active Directory. Plus précisément,
l’article décrit les événements qui indiquent la présence d’objets en attente, les causes des objets en attente et les
méthodes que vous pouvez utiliser pour supprimer les objets en attente.
INTRODUCTION
Des objets en attente peuvent se produire si un contrôleur de domaine ne se réplique pas pendant un intervalle
de temps supérieur à la durée de vie de tombstone (TSL). Le contrôleur de domaine se reconnecte ensuite à la
topologie de réplication. Les objets qui sont supprimés du service d’annuaire Active Directory lorsque le
contrôleur de domaine est hors connexion peuvent rester sur le contrôleur de domaine en tant qu’objets en
attente. Cet article contient des informations détaillées sur les événements qui indiquent la présence d’objets en
attente, les causes des objets en attente et les méthodes que vous pouvez utiliser pour supprimer les objets en
attente.
Durée de vie de Tombstone et réplication des suppressions
Lorsqu’un objet est supprimé, Active Directory réplique la suppression en tant qu’objet tombstone. Un objet
tombstone se compose d’un petit sous-ensemble des attributs de l’objet supprimé. En réplication entrante de cet
objet, les autres contrôleurs de domaine dans le domaine et dans la forêt reçoivent des informations sur la
suppression. Le tombstone est conservé dans Active Directory pendant une période spécifiée. Cette période
spécifiée est appelée TSL. À la fin du TSL, l’objet tombstone est définitivement supprimé.
La valeur par défaut du TSL dépend de la version du système d’exploitation qui s’exécute sur le premier
contrôleur de domaine installé dans une forêt. Le tableau suivant indique les valeurs TSL par défaut pour
différents Windows d’exploitation.
P REM IER C O N T RÔ L EUR DE DO M A IN E DA N S L A RA C IN E DE

L A F O RÊT DURÉE DE VIE DE TO M B STO N E PA R DÉFA UT
Windows 2000 60 jours
Windows Server 2003 60 jours
Windows Server 2003 avec Service Pack 1 180 jours

NOTE
La valeur TSL existante ne change pas lorsqu’un contrôleur de domaine est mis à niveau vers Windows Server 2003 avec
Service Pack 1 (SP1). La valeur TSL existante est conservée jusqu’à ce que vous la modifiez manuellement.
Une fois que le tombstone est supprimé définitivement, la suppression d’objet ne peut plus être répliquée. Le
TSL définit la durée pendant combien de temps les contrôleurs de domaine de la forêt conservent les
informations sur un objet supprimé. Le TSL définit également la durée pendant laquelle tous les partenaires de
réplication directe et transitive du contrôleur de domaine d’origine doivent recevoir une suppression unique.
Comment se produisent les objets en attente
Lorsqu’un contrôleur de domaine est déconnecté pendant une période plus longue que le TSL, un ou plusieurs
objets supprimés d’Active Directory sur tous les autres contrôleurs de domaine peuvent rester sur le contrôleur
de domaine déconnecté. Ces objets sont appelés objets en attente. Étant donné que le contrôleur de domaine est
hors connexion pendant la période où la tombestone est active, le contrôleur de domaine ne reçoit jamais la
réplication de la tombestone.
Lorsque ce contrôleur de domaine est reconnecté à la topologie de réplication, il agit comme un partenaire de
réplication source qui possède un objet que son partenaire de destination ne possède pas.
Des problèmes de réplication se produisent lorsque l’objet sur le contrôleur de domaine source est mis à jour.
Dans ce cas, lorsque le partenaire de destination tente de répliquer la mise à jour entrante, le contrôleur de
domaine de destination répond de deux manières :
Si la cohérence de réplication stricte est activée pour le contrôleur de domaine de destination, il reconnaît
qu’il ne peut pas mettre à jour l’objet. Le contrôleur arrête localement la réplication entrante de la
partition d’annuaire à partir du contrôleur de domaine source.
Si la cohérence de réplication stricte est désactivée pour le contrôleur de domaine de destination, le
contrôleur demande le réplica complet de l’objet mis à jour. Dans ce cas, l’objet est réintroduit dans le
répertoire.
Causes des déconnexions longues
Les conditions suivantes peuvent entraîner de longues déconnexions :
Un contrôleur de domaine est déconnecté du réseau et est placé dans le stockage.
L’expédition d’un contrôleur de domaine pré-mis en place vers son emplacement distant prend plus de
temps qu’un TSL.
Les connexions de réseau large (WAN) ne sont pas disponibles pendant de longues périodes. Par
exemple, un contrôleur de domaine à bord d’un ship de ship peut ne pas être en mesure de répliquer, car
le bâtiment est en mer pendant une durée plus longue que le TSL.
L’événement signalé est un faux positif, car un administrateur a raccourci le TSL pour forcer le collecte de
la garbage collection d’objets supprimés.
L’événement signalé est un faux positif, car l’horloge système sur la source ou sur le contrôleur de
domaine de destination est incorrectement avancée ou revenir en arrière. Les inclinaisons d’horloge sont
les plus courantes suite à un redémarrage du système. Une inclinaison de l’horloge peut se produire pour
les raisons suivantes :
Un problème est à l’état de la batterie de l’horloge système ou de la carte mère.
La source d’heure d’un ordinateur est configurée de manière incorrecte. Il inclut un serveur source
de temps configuré à l’aide du service Windows Time (W32Time), à l’aide d’un serveur de temps
tiers ou à l’aide de routeurs réseau.
Un administrateur avance ou remonte l’horloge système pour prolonger la durée de vie utile
d’une sauvegarde de l’état du système ou accélérer le collecte de la garbage collection d’objets
supprimés. Assurez-vous que l’horloge système reflète l’heure réelle. Assurez-vous également que
les journaux des événements ne contiennent pas d’événements non valides du futur ou du passé.
Indications qu’un contrôleur de domaine possède des objets en attente
Un contrôleur de domaine obsolète peut stocker des objets en attente sans effet perceptible lorsque les
Un administrateur, une application ou un service ne met pas à jour l’objet en attente.
Un administrateur, une application ou un service n’essaie pas de créer un objet qui a le même nom dans le
domaine.
Un administrateur, une application ou un service n’essaie pas de créer un objet en utilisant le même nom
d’utilisateur principal (UPN) dans la forêt.
Même en l’absence d’effet perceptible, la présence d’objets en attente peut entraîner des problèmes. Ces
problèmes sont plus susceptibles de se produire si un objet en attente est un principal de sécurité.
Événements qui indiquent que des objets en attente peuvent être présents dans la forêt
ID D’ÉVÉN EM EN T DESC RIP T IO N GÉN ÉRA L E
1862 Le contrôleur de domaine local n’a pas reçu récemment

d’informations de réplication de plusieurs contrôleurs de
domaine (intersite).

domaine (intersite).

domaine (résumé).
1311 Le contrôle de cohérence des connaissances (KCC) n’a pas pu

créer une topologie d’arborescence couvrante.
2042 Cela fait trop longtemps que ce serveur a été répliqué pour
la dernière fois avec le serveur source nommé.
Événements qui indiquent que des objets en attente sont présents dans la forêt
1388 Ce système de destination a reçu une mise à jour pour un

objet qui aurait dû être présent localement, mais non.
1311 Un autre contrôleur de domaine a répliqué un objet qui n’est

pas présent sur ce contrôleur de domaine.
NOTE
Les objets en attente ne sont pas présents sur les contrôleurs de domaine qui enregistrent l’ID d’événement 1988. Le
contrôleur de domaine source contient l’objet en attente.
Erreurs de repadminage qui indiquent que des objets en attente sont présents dans la forêt
8606 Des attributs insuffisants ont été attribués pour créer un

objet.
Autres indications de présence d’objets en attente dans la forêt

Un compte d’utilisateur ou de groupe qui a été supprimé reste dans la liste d’adresses globale (LA GAL)
sur les serveurs qui exécutent Microsoft Exchange Server. Par conséquent, bien que le nom du compte
apparaisse dans la liste d’adresses réseau, des erreurs se produisent lorsque les utilisateurs tentent
d’envoyer des messages électroniques.
Plusieurs copies d’un objet apparaissent dans le s picker d’objet ou dans la LA GAL d’un objet qui doit
être unique dans la forêt. Vous voyez parfois des objets en double qui ont changé de nom. Ces objets en
double provoquent une confusion dans les recherches dans l’annuaire. Par exemple, si le nom seul relatif
de deux objets ne peut pas être résolu, la résolution de conflit a pour effet d’y apposer le nom
CNF:GUID . Dans cet exemple, représente * un caractère réservé, CNF est une constante qui indique
une résolution de conflit et le GUID représente la valeur de l’attribut objectGUID.
Les messages électroniques ne sont pas remis à un utilisateur dont le compte Active Directory semble
actif. Une fois qu’un contrôleur de domaine obsolète ou un serveur de catalogue global est reconnecté,
les deux instances de l’objet utilisateur apparaissent dans le catalogue global. Étant donné que les deux
objets ont la même adresse de messagerie, les messages électroniques ne peuvent pas être remis.
Un groupe universel qui n’existe plus continue d’apparaître dans le jeton d’accès d’un utilisateur. Bien que
le groupe n’existe plus, si un compte d’utilisateur a toujours le groupe dans son jeton de sécurité, il se
peut que l’utilisateur ait accès à une ressource que vous souhaitez rendre indisponible pour cet utilisateur.
Il n’est pas possible Exchange créer un nouvel objet ou une nouvelle boîte aux lettres. Mais vous ne voyez
pas l’objet dans Active Directory. Un message d’erreur signale que l’objet existe déjà.
Les recherches qui utilisent les attributs d’un objet existant peuvent trouver à tort plusieurs copies d’un
objet du même nom. Un objet a été supprimé du domaine. Toutefois, cet objet reste dans un serveur de
catalogue global isolé.
Si vous tentez de mettre à jour un objet en attente qui réside dans une partition d’annuaire accessible en
création, les événements sont enregistrés sur le contrôleur de domaine de destination. Toutefois, si la seule
version d’un objet en attente se trouve dans une partition d’annuaire en lecture seule sur un serveur de
catalogue global, l’objet ne peut pas être mis à jour. Par conséquent, ce type d’événement n’est pas déclenché.
Suppression d’objets en attente de la forêt
Windows forêts basées sur 2000
Pour plus d’informations sur la suppression d’objets en attente dans un domaine Windows 2000, cliquez sur le
numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :
314282 objets en attente peuvent rester après la mise en ligne d’un serveur de catalogue global non à jour
Windows forêts basées sur Server 2003
892777 Windows De support Server 2003 Service Pack 1
Empêcher les objets en attente
Voici des méthodes que vous pouvez utiliser pour empêcher les objets en attente.
Méthode 1 : activer l’entrée de Registre Cohérence de réplication stricte
Vous pouvez activer l’entrée de Registre Cohérence de réplication stricte afin que les objets suspects soient mis
en quarantaine. Ensuite, les administrations peuvent supprimer ces objets avant qu’ils ne se propagent dans
toute la forêt.
Si un objet en attente accessible en création se trouve dans votre environnement et qu’une tentative de mise à
jour de l’objet est réalisée, la valeur de l’entrée de Registre Cohérence de réplication stricte détermine si la
réplication se poursuit ou est arrêtée. L’entrée de Registre Cohérence de réplication stricte se trouve dans la
sous-clé de Registre suivante : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Le type de données pour cette entrée est REG_DWORD. Si vous définissez la valeur sur 1, l’entrée est activée. La
réplication entrante de la partition d’annuaire spécifiée à partir de la source est arrêtée sur la destination. Si
vous définissez la valeur sur 0, l’entrée est désactivée. La destination demande l’objet complet au contrôleur de
domaine source. L’objet en attente est redessyé dans le répertoire en tant que nouvel objet.
La valeur par défaut de l’entrée de Registre Cohérence de réplication stricte est déterminée par les conditions
dans lesquelles le contrôleur de domaine a été installé dans la forêt.
NOTE
L’augmentation du niveau fonctionnel du domaine ou de la forêt ne modifie pas le paramètre de cohérence de réplication
sur un contrôleur de domaine.
Par défaut, la valeur de l’entrée de Registre Cohérence de réplication stricte sur les contrôleurs de domaine
installés dans une forêt est 1 (activée) si les conditions suivantes sont vraies :
La version Windows Server 2003 de Winnt32.exe est utilisée pour mettre à niveau un contrôleur de domaine
principal Windows NT 4.0 vers Windows Server 2003. Cet ordinateur crée le domaine racine de la forêt
d’une nouvelle forêt.
Active Directory est installé sur un serveur qui exécute Windows Server 2003. Cet ordinateur crée le
domaine racine de la forêt d’une nouvelle forêt.
Par défaut, la valeur de l’entrée de Registre Cohérence de réplication stricte sur les contrôleurs de domaine est 0
(désactivée) si les conditions suivantes sont vraies :
Un Windows de domaine basé sur 2000 est mis à niveau vers Windows Server 2003.
Active Directory est installé sur un serveur membre Windows Server 2003 dans une forêt Windows 2000.
Si vous avez un contrôleur de domaine qui exécute Windows Server 2003 avec SP1, vous n’avez pas besoin de
modifier le Registre pour définir la valeur de l’entrée de Registre Cohérence de réplication stricte. À la place, vous
pouvez utiliser l’outil Repadmin.exe pour définir cette valeur pour un contrôleur de domaine dans la forêt ou
pour tous les contrôleurs de domaine de la forêt.
Pour plus d’informations sur l’utilisation Repadmin.exe pour définir une cohérence de réplication stricte, visitez
le site Web Microsoft suivant :
https://technet.microsoft.com/library/cc780362(WS.10).aspx
Méthode 2 : surveiller la réplication à l’aide d’une commande de ligne de commande
Pour surveiller la réplication à l’aide de repadmin /showrepl la commande, suivez les étapes suivantes :
1. Cliquez sur Démarrer , puis sur Exécuter , tapez cmd, puis cliquez sur OK .
2. Tapez repadmin /showrepl * /csv >showrepl.csv , puis appuyez sur Entrée.
3. Dans Microsoft Excel, ouvrez Showrepl.csv fichier.
4. Sélectionnez la colonne A + RPC et la colonne SMTP .
5. Dans le menu Edition , cliquez sur Supprimer .
6. Sélectionnez la ligne qui se trouve immédiatement sous les en-têtes de colonne.
7. Dans le menu Windows , cliquez sur Figer le volet .
8. Sélectionnez la feuille de calcul complète.
9. Dans le menu Données , pointez sur Filtrer , puis cliquez sur Filtre automatique .
10. Dans l’en-tête de la colonne Dernière réussite, cliquez sur la flèche vers le bas, puis cliquez sur Trier
croissant .
11. Dans l’en-tête de la colonne src DC , cliquez sur la flèche vers le bas, puis cliquez sur Personnalisé .
12. Dans la boîte de dialogue Filtre automatique personnalisé, le clic ne contient pas .
13. Dans la zone à droite de ne contient pas , tapez del.
NOTE
Cette étape empêche les contrôleurs de domaine supprimés d’apparaître dans les résultats.
14. Dans l’en-tête de la colonne Dernier échec, cliquez sur la flèche vers le bas, puis cliquez sur
Personnalisé .
15. Dans la boîte de dialogue Filtre automatique personnalisé, cliquez sur n’est pas égal à.
16. Dans la zone à droite de n’est pas égale , tapez 0.
17. Résolvez les échecs de réplication qui s’affichent.
Méthode 3 : Supprimer des contrôleurs de domaine
Vous pouvez supprimer les contrôleurs de domaine défaillants de la forêt avant l’expiration du TSL.
Méthode 4 : augmenter le TSL
Windows 2000 Server
Augmentez le TSL à 180 jours à l’aide de l’outil Adsiedit. Pour ce faire, procédez comme suit :
1. Dans l’outil Adsiedit, développez Configuration DomainControllerName , développez
CN=Configuration , DC=ForestRootDomain , développez CN=Ser vices , développez CN=Windows
NT , cliquez avec le bouton droit sur CN=Ser vice d’annuaire, puis cliquez sur Propriétés .
2. Cliquez sur l’onglet Attribut.
3. Dans la liste Sélectionner les propriétés à afficher , cliquez sur Facultatif .
4. Dans la liste Sélectionner une propriété à afficher , cliquez sur TombstoneLifetime .
5. Dans la zone Modifier l’attribut , tapez 180, cliquez sur Définir , puis sur OK . Windows Server 2003
Augmentez le TSL à 180 jours à l’aide de l’outil Adsiedit. Pour ce faire, procédez comme suit :
1. Dans l’outil Adsiedit, développez Configuration DomainControllerName , développez
CN=Configuration , DC=ForestRootDomain , développez CN=Ser vices , développez CN=Windows
NT , cliquez avec le bouton droit sur CN=Ser vice d’annuaire, puis cliquez sur Propriétés .
2. Cliquez sur l’onglet Éditeur d’attributs .
3. Dans la liste d’attributs , cliquez sur TombstoneLifetime , puis sur Modifier .
4. Dans la zone Valeur, tapez 180, puis cliquez sur OK .
Les objets en attente peuvent rester après la mise
en ligne d’un serveur de catalogue global hors date
Cet article décrit les procédures de nettoyage des objets réintroduits dans AD après la mise en ligne d’un dc
hors connexion.
Symptômes
Vous devez mettre un contrôleur de domaine (DC) ou un serveur de catalogue global en ligne après qu’il a été
hors connexion pendant un certain temps. Une fois qu’il est en ligne, vous observez un ou plusieurs des
Les messages électroniques ne sont pas remis à un utilisateur dont l’objet utilisateur a été déplacé entre les
domaines. Une fois le serveur de catalogue global ou dc obsolète de nouveau en ligne, les deux instances de
l’objet utilisateur apparaissent dans le catalogue global. Les deux objets ont la même adresse de messagerie,
de sorte que les messages électroniques ne peuvent pas être remis.
Un compte d’utilisateur qui n’existe plus apparaît toujours dans la liste d’adresses globale.
Un groupe universel qui n’existe plus apparaît toujours dans le jeton d’accès d’un utilisateur.
D’autres DCS ou serveurs de catalogue global journalisation des événements tels que EventID 1084, Il
n’existe aucun objet de ce type sur le ser veur . La réplication supplémentaire est bloquée sur les DCS ou les
serveurs de catalogue global concernés.
Cause
Ces problèmes peuvent se produire si le serveur de catalogue global ou dc est hors connexion depuis plus
longtemps que la valeur de l’attribut Tombstone-Lifetime des objets utilisateur.
Pour plus d’informations sur l’attribut Tombstone-Lifetime, voir l’attribut Tombstone-Lifetime.
L’attribut Tombstone-Lifetime définit le nombre de jours avant la suppression d’un objet supprimé des
services d’annuaire. Cela permet de supprimer des objets de serveurs répliqués et d’empêcher les restaurations
de réintroduire un objet supprimé. La valeur par défaut est 180 jours. Après cela, Active Directory n’a plus
besoin de mémoriser la modification.
Si un dc ou un serveur de catalogue global est hors connexion pendant une durée de vie plus longue que la
valeur de l’attribut Tombstone-Lifetime, sa copie d’Active Directory (ou du catalogue global) peut contenir des
objets qui ont été supprimés sur les autres DCS. Toutefois, les autres DCS ne se souvenent plus que les objets
ont été supprimés. Lorsque vous activez le dc hors connexion, il synchronise sa copie d’Active Directory avec le
reste du domaine. Étant donné que les informations sur les suppressions ont été ignorées, le dc réplique les
objets affectés (appelés objets en attente) dans le reste du domaine.
En règle générale, AD DS utilise un modèle de réplication à cohérence souple, dans lequel certains contextes
d’attribution de noms (également appelés partitions d’annuaire) sont en lecture/écritureet d’autres en lecture
seule. Lorsqu’un dc qui reçoit un objet répliqué qui appartient à un contexte d’attribution de noms en
lecture/écriture et que cet objet n’existe pas déjà dans la copie locale de l’arborescence d’informations
d’annuaire (DIT), le dc crée l’objet. Au cours du processus de réplication, l’objet réapparaît sur tous les DCS du
domaine.
Les DCS et les serveurs de catalogue global peuvent également utiliser un modèle de cohérence de réplication
strict. Dans ce modèle, lorsque le dc reçoit un objet répliqué qui n’existe pas déjà dans la dit locale, il cesse de
recevoir ou d’envoyer des données répliquées et enregistre des événements tels que l’ID d’événement 1084, « Il
n’existe aucun objet de ce type sur le serveur ». Pour plus d’informations sur la cohérence de réplication stricte,
notamment sur les circonstances dans lesquelles les DCS peuvent utiliser ce modèle par défaut, voir la 910205
de la base de données, Informations sur les objets en attente dans une forêt Windows Server Active Directory.
Pour plus d’informations sur les problèmes de tombstone, voir KB216993Durée de vie utile d’une sauvegarde
d’état système d’Active Directory.
Résolution 1 : déterminer si Active Directory a des objets en attente

et éviter les objets en attente futurs
KB 910205, explique plusieurs façons de déterminer si votre système Active Directory a cumulé des objets en
attente. La 910205 de la KB décrit également les étapes que vous pouvez prendre pour empêcher les objets en
attente d’être insérez.
Résolution 2 : supprimer les objets en attente

Si l’objet ne doit pas exister du tout dans Active Directory (par exemple, si l’objet a été réintroduit par un
contrôleur de domaine obsolète), vous pouvez supprimer les objets à l’aide des outils standard (tels que
ADSIEdit ou le logiciel en ligne Utilisateurs et ordinateurs Active Directory).
Il est facile de supprimer les objets en attente pour les contextes d’attribution de noms en lecture/écriture. Dans
Windows Server 2003 et versions ultérieures, vous pouvez supprimer les objets en attente à l’aide de la
repadmin /removelingeringobjects commande. Pour plus d’informations sur l’utilisation de RepAdmin, voir L’ID
d’événement de réplication Active Directory 1388 ou 1988: un objet en attente est détecté.
Cet article explique comment supprimer les objets en attente qui ont déjà été présentés dans des contextes
d’attribution de noms en lecture seule, tels que des partitions d’annuaire sur des serveurs de catalogue global
ou des contrôleurs de domaine Read-Only. La fonctionnalité abordée dans la section Plus d’informations existe
toujours dans les systèmes d’exploitation plus nouveaux et peut toujours être utile pour résoudre les problèmes
de comportement inattendu de RepAdmin.
Cette procédure requiert l’objectGUID d’un dc qui dispose d’une copie en lecture/écriture de l’objet et
l’objetGUID de l’objet lui-même. Si vous devez supprimer plusieurs objets, déterminez si l’un des objets est dans
une relation parent/enfant (vous pouvez le déterminer à partir des noms unique des objets). Si tel est le cas,
commandez les suppressions afin que tous les objets enfants soient supprimés avant leurs objets parents.
Cette procédure est en trois étapes principales, que vous devez effectuer sur un ordinateur qui a accès à la forêt
(et vous devez utiliser un compte d’utilisateur qui dispose d’autorisations administratives sur la forêt) :
1. Obtenez le nom et l’objet OBJECTGUID de l’objet en attente.
2. Identifiez un dc dans le domaine d’objet.
3. Supprimez les objets en attente. Sélectionnez l’une des méthodes suivantes :
Supprimez quelques objets en attente.
Supprimez un grand nombre d’objets en attente.
IMPORTANT
Chaque serveur de catalogue global sur lequel vous avez l’intention d’exécuter les opérations de suppression (étape 3)
doit avoir une connectivité réseau au contrôleur de domaine que vous avez identifié (étape 2).
Pour plus d’informations sur la résolution des problèmes, consultez les sections suivantes :
Message d’erreur lors de l’exécution de Walkservers.cmd pour modifier de nombreux objets en attente dans
l’environnement.
Message d’erreur 87 lors de la suppression d’objets en attente dans l’environnement.
Obtenir le nom et l’objet OBJECTGUID de l’objet en attente
La meilleure façon d’identifier le domaine dans lequel se trouve un objet (et de déterminer le nom d’un dc qui
dispose d’une copie en lecture/écriture de l’objet) consiste à récupérer le nom de l’objet. Vous pouvez rechercher
le nom (ou des parties du nom) de l’objet à l’aide de lLdp.exe de recherche. Pour cela, procédez comme suit :
1. Démarrez Ldp.exe.
Dans la plupart des versions Windows, sélectionnez Démarrer > l'ldp.exe ****. Dans les versions
antérieures Windows (par exemple, Windows Server 2003 SP1), cet outil est disponible en tant qu’un des
outils de support.
2. Sélectionnez Connexion > Connecter . Dans la zone Ser veur, tapez le nom d’un serveur de catalogue
global. Dans la zone Por t, tapez 3268, puis sélectionnez OK.
3. Select Connection > Bind . Tapez des informations d’identification valides si vos informations
d’identification actuelles ne sont pas suffisantes pour interroger tout le contenu du catalogue global.
Sélectionnez OK .
4. Sélectionnez > Arborescence d’affichage . Entrez le nom de la racine de la forêt, puis sélectionnez OK.
5. Dans la liste des arborescences, cliquez avec le bouton droit sur la racine de la forêt, puis sélectionnez
Rechercher.
6. Dans la zone Filtre, tapez un filtre qui utilise le <attribute> = <value> format.
Dans le texte du filtre, représente l’attribut objet à rechercher et représente les critères pour <attribute>
<value> lesquels vous recherchez. Vous pouvez utiliser ***** comme caractère générique dans la valeur
et vous pouvez utiliser une expression.
Pour plus d’informations sur la syntaxe du filtre LDAP (Lightweight Directory Access Protocol), consultez
la syntaxe du filtre de recherche.
Par exemple, pour rechercher des objets pour lesquels l’attribut sAMAccountName a la valeur testuser ,
tapez (sAMAccountName = testuser) dans la zone Filtre. Pour rechercher un objet utilisateur, les attributs
suivants sont particulièrement utiles :
cn
userPrincipalName
sAMAccountName
name
messagerie
sn
Pour rechercher un objet de groupe, les attributs suivants sont particulièrement utiles :
cn
sAMAccountName
name
7. Sous Étendue, sélectionnez Sous-arbre .
8. Sélectionnez la zone Attributs, puis sélectionnez la fin de la chaîne d’attribut. Tapez ;objectGUID à la fin
de la chaîne.
Dans certaines versions de Ldp, vous devez sélectionner Options pour voir la zone Attributs.
9. Pour exécuter la requête, sélectionnez Exécuter.
Les résultats apparaissent dans la fenêtre Ldp principale.
10. Déterminez, s’il y en a, quels objets répertoriés dans les résultats doivent être supprimés du catalogue
global. Une indication que vous avez trouvé un objet non conforme est que l’objet n’existe pas dans une
copie en lecture/écriture du contexte d’attribution de noms.
11. Si les objets que vous recherchez ne sont pas inclus dans les résultats de la requête, reformulez le filtre et
ré-exécutez la recherche.
12. Si vous avez identifié un objet en attente, notez les valeurs de ses attributs DN et objectGUID. Vous
aurez besoin de ces valeurs ultérieurement.
Identifier un dc dans le domaine d’objet
La valeur de l’attribut DN de l’objet inclut le domaine de l’objet. Lorsque vous connaissez le domaine, vous
pouvez identifier un serveur de catalogue global ou un serveur de catalogue global dans le domaine. Pour cela,
procédez comme suit.
1. Vérifiez les par ties dc= de la valeur DN. Combinez les par ties dc= pour obtenir le nom de domaine.
Par exemple, si un objet a la valeur DN cn=FirstName
LastName,cn=Users,dc=name1,dc=name2,dc=com , l’objet se trouve dans le name1.name2.com
domaine.
2. Pour localiser un contrôleur de domaine (ou un serveur de catalogue global) dans ce domaine, ouvrez
Utilisateurs et ordinateurs Active Directory, ouvrez le conteneur de domaine, puis ouvrez le conteneur
Contrôleurs de domaine.
3. Ouvrez une fenêtre d’invite de commandes avec élévation de élévation de niveaux et entrez
repadmin /showreps dc-name .
NOTE
Dans cette commande, dc-name représente le nom d’ordinateur du dc que vous avez identifié à l’étape 2.
Dans les versions antérieures de Windows (par exemple, Windows Server 2003 SP1), RepAdmin est disponible en
tant qu’un des outils de support.
Le repadmin produit des résultats semblables à ce qui suit :
Default-First-Site-Name\WS2016-DC-01 DSA Options: IS_GC Site Options: (none) DSA object GUID:
<GUID> DSA invocationID: <invocationID>
4. Notez la valeur du GUID de l’objet DSA. Il s’agit de la valeur objectGUID de la dc.

Supprimer des objets en attente
Utilisez les méthodes suivantes pour supprimer les objets en attente.
Supprimer quelques objets en attente de quelques serveurs de catalogue global
Si vous n’avez que quelques objets et catalogues globaux, suivez ces étapes pour supprimer les objets à l’aide
Ldp.exe :
1. Utilisez Enterprise’informations d’identification administrateur pour vous connectez à chaque serveur de
catalogue global qui contient une copie de l’objet en attente.
2. Démarrez Ldp.exe et connectez-vous au port 389 sur le contrôleur de domaine local (laissez la zone
Ser veur vide).
3. Select Connection > Bind . Laissez toutes les cases vides (vous êtes déjà Enterprise administrateur).
4. Sélectionnez Parcourir > modifier.
5. Configurez les entrées suivantes dans la boîte de dialogue Modifier :
a. Laissez la zone Dn vide.
b. Dans la zone Attribut, tapez Remove Qu’est-ce que c’est ?
c. Dans la zone Valeurs, tapez une valeur qui utilise le format suivant :
<GUID=dcGUID>: <GUID=objectGUID>
Dans cette valeur, dcGUID représente le GUID du dc que vous avez identifié à l’étape 2 de cette
section, et objectGUID représente le GUID de l’objet en attente que vous avez identifié à l’étape 1
de cette section.
La valeur doit ressembler à ce qui suit :
<GUID=<GUID>> : <GUID=<GUID>>
IMPORTANT
Dans la valeur, n’omettez pas les espaces avant et après le deux-points.
d. Sélectionnez > Opération remplacer, puis sélectionnez Entrée .

La zone Liste des entrées affiche la commande complète.
e. Sélectionnez Exécuter .
Les résultats apparaissent dans la fenêtre Ldp principale et doivent ressembler à ce qui suit.
Call Modify... ldap_modify_s(ld, '(null)',[1] attrs); Modifié « ».
Supprimer un grand nombre d’objets en attente de plusieurs serveurs de catalogue global

Si vous devez supprimer un grand nombre d’objets en attente, vous pouvez supprimer plus efficacement à l’aide
de scripts qu’en les supprimant manuellement. Pour créer de tels scripts, utilisez les étapes suivantes :
1. Créez un dossier et, dans ce dossier, créez des fichiers qui ont les noms suivants :
Walkservers.cmd
Walkobjects.cmd
Modifyrootdse.vbs
Server-list.txt
Object-list.txt fichier
2. Collez le texte suivant dans Walkservers.cmd :
for /f %%j in (server-list.txt) do walkobjects %%j
3. Collez le texte suivant dans Walkobjects.cmd :
for /f "delims=@" %%i in (object-list.txt) do cscript //NoLogo MODIFYROOTDSE.VBS %1 "%%i" >>update-

%1.log
4. Collez le texte suivant dans Modifyrootdse.vbs :

'********************************************************************
'*
'* File: MODIFYROOTDSE.VBS
'* Created: January 2002
'* Version: 1.0
'*
'* Main Function: Writes Active Directory information to clean up
'* objects as per: Q314282.
'* Usage: Modifyrootdse.vbs <TargetServer> <GUID PAIR>
'* Parameter are fed into the script using a pair of batch files.
'*
'* Copyright (C) 2002 Microsoft Corporation '*
'********************************************************************
OPTION EXPLICIT
ON ERROR RESUME NEXT
Dim objDomain
Dim ObjValue, strServerName, adsLdapPath
Dim i
'Get the command-line arguments
if Wscript.arguments.count <> 2 Then

Print "Invalid Number of Parameters. Use with WalkServers.CMD and WalkObjects.CMD"
WScript.quit
End If
strServerName = Wscript.arguments.item(0)
ObjValue = Wscript.arguments.item(1)
adsLdapPath = "LDAP://" & strServerName & "/RootDSE"
Set objDomain = GetObject(adsLdapPath)

If Err.Number <> 0 Then
WScript.Echo "Error opening ROOTDSE. Error number is: " & Err.Number & ". Error description is: "
& Err.Description & "."
Set objDomain = Nothing
WScript.quit
End If
objDomain.Put "RemoveLingeringObject", ObjValue

objDomain.Setinfo
If Err.Number = 0 Then
WScript.Echo "Object " & ObjValue & " was removed."
Else
WScript.Echo "Object " & ObjValue & " could not be removed. Error number is: " & Err.Number & ".
Error description is: " & Err.Description & "."
End If
WScript.Quit
NOTE
Si vous démarrez Modifyrootdse.vbs manuellement, veillez à mettre entre guillemets tous les paramètres qui
contiennent des espaces.
5. Créez une liste de tous les noms de domaine complets des serveurs de catalogue global et des DCS qui
contiennent les objets en attente, puis collez la liste dans Server-list.txt. Utilisez les noms de domaine
complets pour éviter les recherches de suffixe DNS.
6. Pour chaque objet en attente, identifiez un dc dans le domaine d’objet qui ne comprend pas de copie de
l’objet en attente. Il s’agit généralement d’un dc qui a un contexte d’attribution de noms en
lecture/écriture dans lequel vous avez supprimé manuellement l’objet en attente. Comme décrit ailleurs
dans cet article, utilisez RepAdmin pour obtenir la valeur objectGUID de chaque DC.
7. Dans Object-list.txt, créez une liste de paires GUID en utilisant le format suivant :
<GUID=dcGUID> : <GUID=objectGUID>
NOTE
Dans cette valeur, dcGUID représente le GUID de la dc qui ne comprend pas de copie de l’objet en attente, et
objectGUID représente le GUID de l’objet en attente.
Chaque paire doit ressembler à ce qui suit :

<GUID= <GUID> > : <GUID= <GUID> >
IMPORTANT
Dans la valeur, n’omettez pas les espaces avant et après le deux-points.
8. Exécutez le fichier Walk-servers.cmd.

Pour chaque serveur de catalogue global ou dc répertorié dans Server-list.txt, les scripts génèrent un fichier
journal nommé Update-server-name.log. Chaque fichier journal contient une ligne pour chaque objet à
supprimer.
Étant donné que les objets en attente peuvent ne pas exister sur chaque serveur répertorié, les erreurs dans les
fichiers journaux n’indiquent pas nécessairement un problème. Toutefois, les messages d’erreur de l’opération de
formulaire refusé ou l’erreur d’opération indiquent qu’il existe un problème avec les GUID ou avec la syntaxe de
la valeur. Si ces erreurs se produisent, vérifiez les éléments suivants :
Assurez-vous que les GUID DC sont les GUID corrects pour les contrôleurs de domaine qui contiennent
un contexte d’attribution de noms en lecture/écriture du domaine qui contient l’objet.
Assurez-vous que les GUID d’objet identifient les objets en attente dans des contextes d’attribution de
noms en lecture seule (serveurs de catalogue global ou rodcs).
Erreur lors de l’exécution de Walkservers.cmd pour modifier de nombreux objets en attente dans l’environnement
Objet <GUID=<GUID> > : <GUID=<GUID>> n’a pas pu être supprimé. Le numéro d’erreur est : -
2147016672. La description de l’erreur est la suivante : .
C a u se d e c e t t e e r r e u r
Cette erreur se produit lorsque le script s’exécute sur le GUID d’un dc qui ne contient pas de contexte
d’attribution de noms en lecture/écriture qui correspond au contexte d’attribution de noms qui contient l’objet
en attente. Vérifiez l’emplacement de l’objet en attente par Ldp.exe'outil.
Ex e m p l e
Dans l’exemple suivant, l’objet en attente à supprimer se trouve dans le domaine corp.company.local. Toutefois,
l<GUID=> entrée dans le fichier Objects-list.txt est associé à un dc qui réside dans le domaine <GUID>
company.local. Ce dc ne comprend pas de contexte d’attribution de noms en lecture/écriture pour le domaine
corp.company.local.
La recherche suivante produit plusieurs objets qui représentent le même utilisateur (Joe) et répertorie leurs
valeurs objectGUID.
ldap_search_s(ld, « DC=company,DC=local », 2, « (cn=User*) », attrList, 0, &msg) Result <0>: (null)

DNs de correspondance :
Obtention de 4 entrées :
>> Dn : CN=User , Joe,OU=Exec,OU=Corporate Users,DC=corp,DC=company,DC=local
1> canonicalName : corp.company.local/Corporate Users/Exec/User, Joe;
1> cn : User, Joe; 1 description> : PDG ;
1> displayName : User, Joe; 1> distinguishedName : CN=User , Joe,OU=Exec,OU=Corporate
Users,DC=corp,DC=company,DC=local; 4> objectClass: top; personne ; organizationalPerson; utilisateur ;
1> objectGUID : <GUID> ; 1 nom> : User, Joe ;
>> Dn : CN=User , Joe,OU=Migration,DC=corp,DC=company,DC=local 1> canonicalName:
corp.company.local/Migration/User, Joe;
1> cn : User, Joe;
1> description : Compte désactivé ; 1> displayName : User, Joe; 1> name : CN=User ,
Joe,OU=Migration,DC=corp,DC=company,DC=local;
4> objectClass: top; personne ; organizationalPerson; utilisateur ;
1> objectGUID : <GUID> ;
1> : Utilisateur, Joe ;
Dans cet exemple, supposons qu’il existe un dc dans le domaine corp.company.local nommé CORP-DC-01.
L’exécution de repadmin /showreps CORP-DC-01 la commande produit la valeur objectGUID <GUID> . Ce GUID
remplace le GUID précédent dans Objects-list.txt fichier. L’entrée de cet objet en attente apparaît maintenant
comme suit :
<GUID=<GUID>> : <GUID=<GUID>>
Le premier GUID est le GUID du contrôleur de domaine dans le domaine corp.company.local. Le deuxième GUID
est le GUID de l’objet en attente. Après cette modification, le script Walk-servers.cmd s’exécute correctement.
Message d’erreur 87 lors de la suppression d’objets en attente dans l’environnement
Cette erreur peut se produire lorsque vous trouvez que des objets n’apparaissent pas sur tous les DCS qui
hébergent le contexte d’attribution de noms, mais ne les repadmin /removelingeringobjects supprime pas. Cela
peut se faire lorsqu’un dc hub réplique de nouveaux objets qu’il a créés avec des serveurs de catalogue global,
mais pas avec des DCS de réplica en lecture/écriture dans son propre domaine.
Cette erreur est renvoyée uniquement dans deux cas :
L’objet existe sur la référence DC.
L’objet est trop petit (par rapport à la valeur TSL actuelle) pour être en attente.
Pour obtenir un exemple du deuxième cas, considérez un serveur de catalogue global qui contient les
métadonnées suivantes :
Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute

======= =============== ========= ============= === =========
143543261 d20f71f3-6147-4f80-a0c2-470541ef09e6 104742409 <DateTime> objectClass
Vecteur de date à jour d’un réplica RW : d20f71f3-6147-4f80-a0c2-470541ef09e6 @ USN 104583382 @
Time <DateTime>
Vecteur de date à jour d’un GC : d20f71f3-6147-4f80-a0c2-470541ef09e6 @ USN 104762881 @ Time
<DateTime>
Dans ce cas, le dc a créé l’objet après que la réplication avec les DCS dans son propre domaine a commencé à
échouer, mais il a quand même été répliqué avec les serveurs de catalogue global dans d’autres domaines.
Pour résoudre ce problème, laissez ces objets devenir de réels objets en attente (au-delà de TSL), puis
supprimez-les à l’aide du script de cet article. Pour vous assurer que les données continuent de se répliquer,
définissez Autoriser la réplication avec des par tenaires non fiables et endommagés sur tous les DCS de la
forêt.
Si vous ne pouvez pas résoudre les erreurs dans les fichiers journaux à l’aide de ces méthodes, vous rencontrez
peut-être un autre problème. Contactez les services de support technique Microsoft pour obtenir une assistance
supplémentaire.
Erreur (le nom principal cible est incorrect) lors de la
réplication manuelle des données entre les
contrôleurs de domaine
Cet article fournit une solution à une erreur qui se produit lorsque vous répliquez manuellement des données
entre des contrôleurs de domaine.
NOTE
Cet article s’applique Windows 2000. Le support Windows 2000 se termine le 13 juillet 2010. Le Windows solutions de fin
de support 2000 est un point de départ pour la planification de votre stratégie de migration à partir de Windows 2000.
Pour plus d’informations, voir la politique de cycle de vie du support Microsoft.
Symptômes
Lorsque vous utilisez le logiciel en ligne Sites et services Active Directory pour répliquer manuellement des
données entre des contrôleurs de domaine Windows 2000, vous pouvez recevoir l’un des messages d’erreur
suivants :
Le nom principal cible est incorrect
Ou
Accès refusé
En outre, les messages d’ID d’événement suivants peuvent être enregistrés dans le journal système :
Event Source: Netlogon

Event ID: 3210
User: N/A
Event Description:
Failed to authenticate with \\DOMAINDC, a Windows NT domain controller for domain DOMAIN.

Event ID: 5722
User: N/A
Event Description:
The session setup from the computer 1 failed to authenticate. The name of the account referenced in the
security database is 2. The following error occurred: n3
Résolution
Pour résoudre ce problème, déterminez d’abord quel contrôleur de domaine est le contrôleur de domaine
principal (PDC) actuel Emulator rôle principal des opérations. Pour ce faire, utilisez l’une des méthodes suivantes
:
Installez l’utilitaire Netdom.exe à partir Windows 2000 Support Tools, puis exécutez la commande
suivante :
netdom query fsmo
Démarrez le logiciel en ligne Utilisateurs et ordinateurs Active Directory, cliquez avec le bouton droit sur
le domaine, puis cliquez sur Operations Masters . Cliquez sur l’onglet PDC ; le titulaire du rôle actuel
est affiché dans la fenêtre Operations Master. Sous cet onglet, vous pouvez modifier le rôle de maître
des opérations sur l’ordinateur actuel dans la deuxième fenêtre (si cet ordinateur n’est pas le titulaire
actuel).
Utilisez lNtdsutil.exe utilitaire (inclus dans Windows 2000) et l’utilitaire de ligne de commande du Kit de
ressources. Toutefois, ces interfaces sont recommandées pour les utilisateurs plus avancés. Pour plus
d’informations, voir Comment trouver des serveurs qui ont des rôles d’opérations maîtres simples
flexibles.
Sur les contrôleurs de domaine qui rencontrent ce problème, désactivez le service Centre de distribution de clés
Kerberos (KDC) :
1. Cliquez sur Démarrer, pointez sur Programmes, cliquez sur Outils d’administration, puis sur Ser vices.
2. Double-cliquez sur KDC, définissez le type de démarrage sur Désactivé, puis redémarrez l’ordinateur.
Après le redémarrage de l’ordinateur, utilisez l’utilitaire Netdom pour réinitialiser les canaux sécurisés entre ces
contrôleurs de domaine et le titulaire du rôle maître des opérations Emulator PDC. Pour ce faire, exécutez la
commande suivante à partir des contrôleurs de domaine autres que le Emulator de rôle principal des opérations
PDC :
netdom resetpwd /server: server_name /userd: domain_name \administrator /passwordd: administrator_password
Où ser ver_name est le nom du serveur qui est le Emulator de rôle principal des opérations PDC.
Après avoir réinitialisé le canal sécurisé, redémarrez les contrôleurs de domaine. Même si vous tentez de
réinitialiser le canal sécurisé à l’aide de l’utilitaire Netdom et que la commande ne se termine pas correctement,
continuez le processus de redémarrage.
Si seul le titulaire du rôle maître des opérations PDC Emulator est en cours d’exécution, le KDC force les autres
contrôleurs de domaine à resynchroniser avec cet ordinateur, au lieu de s’émettre eux-mêmes un nouveau ticket
Kerberos.
Une fois que les ordinateurs ont terminé le redémarrage, démarrez le programme Services, redémarrez le
service KDC, puis tentez à nouveau la réplication.
S’il existe plusieurs contrôleurs de domaine dans le domaine, le message d’erreur que vous recevez lorsque ce
problème se produit varie selon la façon dont la réplication est tentée et si l’un des contrôleurs de domaine
impliqués est également le titulaire du rôle maître des opérations PDC Emulator.
Dans certains cas, lorsque vous tentez de vous connecter au contrôleur de domaine qui possède le rôle maître
des opérations PDC Emulator d’un autre contrôleur de domaine, vous pouvez recevoir un message d’erreur «
Accès refusé net view \\computername ». Toutefois, si vous utilisez l’adresse IP (Internet Protocol), la commande
peut réussir.
Lorsque ce problème se produit, de nombreuses erreurs peuvent être signalées dans les journaux des
événements. Ces erreurs varient en fonction de l’une des conditions suivantes :
Le contrôleur de domaine n’était pas entièrement fonctionnel avant que le problème ne se soit produit.
Le contrôleur de domaine n’a pas réussi à terminer le processus de l’Assistant Installation d’Active
Directory.
Le dossier Sysvol sur le contrôleur de domaine n’a pas été partagé.
Le contrôleur de domaine n’avait pas la structure de fichiers complète sous le dossier Domain_name et
le dossier Stratégies situé dans %SystemRoot% \ \ Sysvol Sysvol \ Domain_name \ Policies.
L’événement suivant est un exemple d’événement qui peut être signalé :
Event ID: 3034

Type: Warning
Source: MRxSmb
Description: The redirector was unable to initialize security context or query context attributes.
Comment modifier l’intervalle de réplication Intra-
Site de contrôleur de domaine par défaut
Cet article explique comment modifier l’intervalle de réplication du contrôleur de domaine intras site par défaut.
Lorsqu’un contrôleur de domaine écrit une modification dans sa copie locale d’Active Directory, un horloge est
démarré qui détermine quand les partenaires de réplication du contrôleur de domaine doivent être avertis de la
modification. Par défaut, cet intervalle est de 15 secondes dans Windows Server 2003 et versions ultérieures.
Lorsque cet intervalle s’est écoulé, le contrôleur de domaine initie une notification à chaque partenaire de
réplication intras site qu’il a des modifications qui doivent être propagées. Un autre paramètre configurable
détermine le nombre de secondes à suspendre entre les notifications. Ce paramètre empêche les réponses
simultanées des partenaires de réplication. Par défaut, cet intervalle est de 3 secondes dans Windows Server
2003 et les versions ultérieures, lorsque le niveau fonctionnel de la forêt est Windows Server 2003 ou un niveau
fonctionnel supérieur. Ces deux intervalles peuvent être modifiés en éditant le Registre.
WARNING
Cet article contient des informations sur la modification du Registre. Avant de modifier le Registre, pensez à le sauvegarder
et assurez-vous que vous savez le restaurer en cas de problème. Pour plus d’informations sur la façon de back up, restore
et modify the registry, voir Windows registry information for advanced users.
Pour modifier le délai entre la modification d’Active Directory et la première notification du partenaire de
réplication, utilisez l’Éditeur du Registre pour modifier les données de valeur de la valeur DWORD « Interruption
de notification du réplicateur après modification (secs) » dans la clé de Registre suivante :
Chemin d’accès : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Clé : interruption de notification du réplicateur après modification (secs)
Valeur : REG_DWORD
Pour modifier le délai de notification entre les contrôleurs de domaine, utilisez l’Éditeur du Registre pour
modifier les données de valeur de la valeur DWORD « Interruption de notification du réplicateur entre les DSAs
(secs) » dans la clé de Registre suivante :
Clé : interruption de notification du réplicateur entre les DSAs (secs)
Valeur : REG_DWORD
NOTE
Un paramètre s’applique également au mode d’application Active Directory (ADAM) et aux services AD LDS (Active
Directory Lightweight Directory Services). Pour ADAM et AD LDS, la clé de Registre se trouve dans la clé de Registre «
Parameters » de l’instance ADAM.
Avertissement de réplication NTDS avec l’ID
Cet article fournit une solution à un ID d’événement d’avertissement NTDS 1093.

Symptômes
Lors de la résolution d’un autre problème, nous avons trouvé l’ID d’événement d’avertissement NTDS 1093.

Catégorie d’événement : réplication
Date : MM/JD/AAA
Heure : hh:mm:ss
Ordinateur : DC02
Description :
Active Directory n’a pas pu mettre à jour l’objet suivant avec des modifications d’attribut, car la modification
entrante a provoqué le dépassement de la taille maximale de l’enregistrement de l’objet. La modification
entrante de l’attribut suivant est annulée lors d’une tentative de fin de la mise à jour.
Objet :
CN=user01,OU=OU1,OU=OU2,OU=Users,DC=contoso,DC=com
GUID d’objet :
<GUID>
Attribut :
24 (userCertificate)
La valeur actuelle (sans modification) de l’attribut sur ce contrôleur de domaine est répliquée sur tous les
autres contrôleurs de domaine. Cela permettra d’atténuer la modification dans le reste de la forêt répliquée.
Les valeurs d’inversion peuvent être reconnues comme suit :
Version:
10277
Heure du changement :
<DateTime>
Numéro de séquence de mise à jour :
614514713
Pour plus d’informations, consultez le Centre d’aide et de support à
https://go.microsoft.com/fwlink/events.asp l’aide.
Cet ID d’événement d’avertissement 1093 indique que la modification entrante ne sera pas répliquée sur le
contrôleur de domaine actuel et qu’elle sera annulée. Autrement dit, les mises à jour entrantes sur l’objet associé
seront abandonnées pour terminer la réplication AD. Cet avertissement n’influence pas la réplication AD.
Cause
L’attribut userCertificate de l’utilisateur identifié (user01) contient un grand nombre de certificats, ce qui
dépasse la taille maximale d’enregistrement d’objet.
Résolution
Pour résoudre le problème, les certificats indésirables doivent être supprimés de l’attribut userCertificate de
l’objet utilisateur dans Active Directory.
Pour identifier les certificats indésirables, vous pouvez vous référer à la méthode dans la section suivante.
Vous pouvez utiliser cette méthode pour exporter les données utilisateur de l’objet utilisateur qui atteignent la
taille maximale de l’objet. Identifiez ensuite les certificats associés par les scripts et déterminez les certificats
indésirables qui peuvent être supprimés de cet objet utilisateur.
1. Exportez les données utilisateur en exécutant la commande sur l’un des contrôleurs de domaine : (sortie
user_data.txt)
ldifde -f user_data.txt -d "distinguishedname of the problem user account" -p base
2. Préparez le script LDF2Certs.vbs contenu suivant :

Option explicit
Const strVBSfile = "LDF2Certs.vbs"
Const ForReading = 1
Const StatusLookingForStart = 0
Const StatusLookingForEnd = 1
Dim strLDFFile
Call CommandParser()
WScript.Echo "!Open the input LDF file " & strLDFFile
Dim oFS
Set oFS = CreateObject("Scripting.FileSystemObject")
Dim objLDFFile
Set objLDFFile = oFS.OpenTextFile(strLDFFile, ForReading, False)
Dim strReadLine, lngStatus, objCertFile, lngCertNumber, strCertFile
lngStatus = StatusLookingForStart
lngCertNumber = 0
Do While objLDFFile.AtEndOfStream <> True
strReadLine = objLDFFile.ReadLine
If lngStatus = StatusLookingForEnd Then
If Not IsNull(strReadLine) Then
If InStr(strReadLine,":") > 0 Then
objCertFile.Close
Set objCertFile = Nothing
lngCertNumber = lngCertNumber + 1
lngStatus = StatusLookingForStart
Else
objCertFile.Write strReadLine
End If
End If
End If
If lngStatus = StatusLookingForStart Then
If Not IsNull(strReadLine) Then
If InStr(strReadLine,"userCertificate::") > 0 Then
WScript.Echo "!Found " & (lngCertNumber + 1) & " certificate"
strCertFile = "Cert" & Right("0000" & CStr(lngCertNumber), 4) & ".cer"
Set objCertFile = oFS.CreateTextFile(strCertFile, True, False)
lngStatus = StatusLookingForEnd
End If
End If
End If
Loop
objLDFFile.Close
Set objLDFFile = Nothing
Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")
Sub CommandParser()'Glable variables: strLDFFile
If WScript.Arguments.Named.Exists("LDFFile") = True Then
strLDFFile = WScript.Arguments.Named.Item("LDFFile")
WScript.Echo "CommandParser: the LDF file name: " & strLDFFile
Else
Call ShowUsage()
End If
End Sub
Sub ShowUsage()
WScript.Echo " "
WScript.Echo "Usage: CScript " & strVBSfile & " /LDFFile:<Input LDF file name, such as input.txt>"
WScript.Quit
End Sub
3. Préparez l'doit.bat script avec les commandes suivantes :
cscript LDF2Certs.vbs /LDFFile:user_data.txt

dir /B Cert*.* > listofcerts.txt
FOR /F %%i IN (listofcerts.txt) DO echo %%i >> allcerts.txt && certutil -dump %%i >> allcerts.txt
4. Placez deux scripts (LDF2Certs.vbs et doit.bat) et les données utilisateur (user_data.txt) dans le même
dossier et exécutez le script doit.bat. Après l’exécution du script, allcerts.txt fichier texte est généré, qui
contient tous les certificats dans les données utilisateur avec des informations détaillées. Pendant ce
temps, tous les certificats seront également vidés sous la mesure de fichiers .cer dans le même dossier.
NOTE
Le vidage d’un grand nombre de certificats peut prendre un certain temps.
5. Vous pouvez identifier les certificats avec leur format de texte ou d’interface utilisateur et décider qu’ils
peuvent être supprimés de cet objet utilisateur.
Description des ID d’avertissement de réplication
NTDS 1083 et 1061 et ID d’erreur SAM 12294 en
raison d’une collision Active Directory
Cet article fournit de l’aide pour résoudre un problème qui se produit si une modification qui est réalisée sur le
contrôleur de domaine local est également réalisée sur le contrôleur de domaine qui détient le rôle maître des
opérations PDC.
Résumé
Les modifications simultanées par rapport aux attributs d’objet Active Directory sur différents contrôleurs de
domaine peuvent provoquer une collision Active Directory pour la mise à jour. Dans ce cas, les avertissements
de réplication NTDS 1083 ou 1061 ou l’ID d’erreur SAM 12294 peuvent être enregistrés.
Les événements suivants peuvent être consignés si la réplication immédiate est déclenchée (par exemple, par
une réplication urgente pour une condition de verrouillage utilisateur) et entre en conflit avec la mise à jour
Active Directory locale :

Description :
Avertissement de réplication : le répertoire est occupé. Il n’a pas pu mettre à jour l’objet CN=... avec les
modifications apportées par GUID._msdcs.domain. Essaiera à nouveau plus tard.
Cela indique que la tentative infructueuse de la mise à jour déclenchée à distance qui sera retentée
ultérieurement :

Description :
Erreur interne : l’appel de l’agent de réplication d’annuaire (DRA) a renvoyé l’erreur 8438.
(décimal 8438 /hex 0x20f6 : ERROR_DS_DRA_BUSY, winerror.h)
Si la journalisation NTDS avancée est activée, l’ID d’erreur suivant peut également être enregistré :

Catégorie d’événement : traitement interne
Description :
Événement interne : l’exception e0010004 s’est produite avec les paramètres -1102 et 0 (ID interne
2030537).
(JetDataBase ID -1102 : JET_errWriteConflict -1102, échec du verrouillage d’écriture en raison d’un
verrouillage d’écriture en suspens)
Si la journalisation NTDS est définie sur 4 (détaillée) ou supérieure dans l’entrée Événements de réplication de la
sous-clé, l’ID d’erreur suivant peut également être
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics\ journalisé :

Source de l’événement : événement de réplication NTDS
Catégorie : Réplication
Description :
Les modifications d’objet suivantes n’ont pas été appliquées à la base de données Active Directory locale, car
les métadonnées locales de l’objet indiquent que la modification est redondante.
Si la mise à jour déclenchée à distance l’emporte sur la mise à jour locale, l’événement système suivant peut être
enregistré pour un verrouillage de compte d’utilisateur :

Source de l’événement : SAM
Utilisateur : user-SID
Description :
La base de données SAM n’a pas pu verrouiller le compte de l’utilisateur en raison d’une erreur de
ressource, telle qu’un échec d’écriture du disque dur (le code d’erreur spécifique se trouve dans les données
d’erreur). Les comptes sont verrouillés après qu’un certain nombre de mots de passe incorrects ont été
fournis. Pensez donc à réinitialiser le mot de passe du compte mentionné ci-dessus.
Données : 0000: c00002a5
Vous devez analyser les données d’erreur pour recevoir la condition d’erreur correcte. DWord data hexadecimal
0xc00002a5 = decimal -1073741147: STATUS_DS_BUSY, ntstatus.h).
Après les avertissements, un événement d’informations NTDS est journalisé et signale que la mise à jour en file
d’attente a déjà été réalisée (avec le même ID de version) et qu’elle est ignorée comme redondante :

Description :
Propriété 90296 (lockoutTime) de l’objet CN=username,OU=... n’est pas appliquée à la base de données
locale, car ses métadonnées locales impliquent que la modification est redondante. La version locale est
(version-ID).
Lorsque cette condition existe, aucune erreur de réplication ne s’est produite. Active Directory est cohérent et
vous pouvez ignorer en toute sécurité les journaux d’événements résultants.
Sur un ordinateur qui exécute Microsoft Windows Server, vous pouvez également déterminer si une erreur de
réplication s’est produite en exportant les métadon données de réplication de l’objet. Pour ce faire, exécutez la
commande suivante à une invite de commandes :
repadmin /showobjmeta <domainController> <objectDN>
NOTE
Dans cette commande, remplacez les espaces réservé suivants :
Remplacez l’espace réser vé domainController par le nom d’hôte d’un contrôleur de domaine.
Remplacez l’espace réser vé objectDN par le nom de l’objet affecté.
Dans la sortie générée par cette commande, mettez en correspondance les heures de dernière mise à jour de
l’attribut et les heures pendantes où les événements ont été enregistrés. À partir de ces informations, vous
pouvez déterminer l’attribut à l’origine de l’erreur de réplication.
En règle générale, vous faites face à ce problème avec l’attribut lockoutTime ou avec l’un des attributs de mot de
passe. Dans ce cas, vous pouvez ignorer les événements en toute sécurité. Les événements se produisent car la
modification qui se produit sur le contrôleur de domaine principal (PDC) est également écrite sur le contrôleur
de domaine local. En même temps, la modification est répliquée parmi les contrôleurs de domaine. Pour
lockoutTime, la modification est répliquée de manière urgente sur le site du PDC.
En raison des intervalles courts de notification de réplication que vous pouvez avoir dans Microsoft Windows
Server, vous pouvez être en collision de réplication sur le même site du PDC. Les modifications de mot de passe
sont un exemple de scénario dans lequel vous pouvez faire face à une collision de réplication. Ce comportement
est dû au fait qu’un contrôleur de domaine a transmis de nouveaux mots de passe au PDC. Le PDC et le
contrôleur de domaine local répliquent ensuite les informations de mot de passe modifiées. Par conséquent, une
collision de réplication peut se produire sur un autre contrôleur de domaine dans le même site. Pour plus
d’informations sur la notification de réplication, cliquez sur le numéro d’article suivant pour afficher l’article
dans la Base de connaissances Microsoft :
214678 modifier l’intervalle de réplication du contrôleur de domaine intras site par défaut
Pour réduire la génération des événements de collision de réplication, configurez le PDC dans un site qui n’a pas
d’autres contrôleurs de domaine ou ordinateurs clients. Dans ce scénario, le PDC ne réplique pas de manière
urgente les mises à jour qu’il reçoit. Par conséquent, vous pouvez réduire le risque de collisions de réplication.
Dans un domaine de grande taille, vous pouvez utiliser cette méthode pour réduire la charge sur le PDC.
L’annulation de NTFRS bloque intentionnellement
l’installation Windows server version 1709 des DCS
réplicas

Symptôme
Lorsque vous utilisez la cmdlet Install-ADDSDomainController pour installer un contrôleur de réplica-domaine
exécutant Windows Server version 1709 sur un domaine activé pour NTFRS, l’installation échoue et vous
Le domaine spécifié %1 utilise toujours le service de réplication de fichiers (FRS), qui est désapprouvé. Ce
serveur ne prend pas en charge FRS et ne peut pas être promu en tant que réplica dans le domaine spécifié.
Vous devez migrer le domaine spécifié pour utiliser la réplication DFS à l’aide de la commande DFSNBG
avant de continuer.
Pour plus d'informations, reportez-vous à l'article https://go.microsoft.com/fwlink/?linkid=849270.
Si la version Windows Server est antérieure à Windows Server version 1709, vous recevez le message suivant :
Le service de réplication de fichiers (FRS) est désapprouvé. Pour continuer à répliquer le dossier SYSVOL,
vous devez migrer vers la réplication DFS à l’aide de la commande DFSNBG. Si vous continuez à utiliser FRS
pour la réplication SYSVOL dans ce domaine, il se peut que vous ne soyez pas en mesure d’ajouter des
contrôleurs de domaine exécutant une prochaine version de Windows Server.
Les serveurs qui exécutent indirectement Install-ADDSDomainController cmdlet dans le Gestionnaire de serveur
sont également affectés.
Cause
Ce comportement est prévu et par conception et cohérent avec les annonces précédentes concernant
l’annulation de NTFRS dans les futures versions de Windows. Windows Server 2016 est la version initiale qui
met fin à la prise en charge de NTFRS.
Résolution
Utilisez les étapes de l’article suivant pour migrer la réplication sysvole de FRS vers DFSR :
Guide de migration de la réplication Sysvol : réplication FRS vers DFS
Erreur de réplication Active Directory 1753 : aucun
point de terminaison n’est disponible à partir du
mappeur de point de terminaison
Cet article décrit un problème dans lequel les réplications Active Directory échouent avec l’erreur Win32 1753 :
« Il n’existe aucun point de terminaison disponible à partir du mappeur de point de terminaison. »
professionnels de l’informatique. Si vous recherchez de l’aide sur un problème, demandez à l’Community
Microsoft.
Symptômes
Cet article décrit les symptômes, la cause et les étapes de résolution pour les opérations AD qui échouent avec
l’erreur Win32 1753 : « Il n’existe aucun point de terminaison disponible à partir du mappeur de point de
terminaison. »
1. DCDIAG signale que le test de connectivité, le test de réplications Active Directory ou le test
KnowsOfRoleHolders ont échoué avec l’erreur 1753 : « Il n’y a plus de points de terminaison disponibles à
partir du mappeur de point de terminaison. »
Serveur de test : <site><DC Name>

Test de début : connectivité
*Vérification des services LDAP Active Directory * Vérification des services RPC Active Directory
[<DC Name>] Échec de DsBindWithSpnEx() avec l’erreur 1753,
Il n’y a plus aucun point de terminaison disponible à partir du mappeur de point de terminaison.
Impression des informations d’erreur étendue RPC :
Enregistrement d’erreur 1, ProcessID est <process ID> (DcDiag)
L’heure système est la : <date> <time>
Le composant de génération est 2 (rpc runtime) L’état est 1753 : aucun point de terminaison n’est
disponible à partir du mappeur de point de terminaison. L’emplacement de détection est 500
NumberOfParameters est 4
Chaîne Unicode : ncacn_ip_tcp
Chaîne Unicode : <source DC object GUID>._msdcs.contoso.com
Val long : -481213899
Val long : 65537
Error Record 2, ProcessID is 700 (DcDiag)
L’heure système est la : <date> <time>
Le composant de génération est 2 (runtime RPC)
L’état est 1753 : il n’y a plus de points de terminaison disponibles à partir du mappeur de point de
terminaison.
NumberOfParameters est 1
Chaîne Unicode : 1025
Contexte d’attribution de noms : <DN path of directory partition>
Aucun point de terminaison n’est disponible à partir du mappeur de point de terminaison.
L’échec s’est produit à <date> <time>.
Le dernier succès s’est produit à <date> <time>.
3 échecs se sont produits depuis le dernier succès.
Le répertoire est <DC name> en cours.
de démarrage ou d’arrêt, et n’est pas disponible.
Vérifiez que l’ordinateur n’est pas suspendu pendant le démarrage.
2. REPADMIN.EXE signale que la tentative de réplication a échoué avec l’état 1753.

REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL
L’exemple REPADMIN /SHOWREPS de sortie suivant montre que la réplication entrante de CONTOSO-DC2
vers CONTOSO-DC1 échoue avec l’erreur « L’accès à la réplication a été refusé » :
Options DSA : IS_GC
GUID d’objet DSA :
DSA invocationID :
DC=contoso,DC=com
Last attempt @ <date> <time> failed, result 1753 (0x6d9) :
Aucun point de terminaison n’est disponible à partir du mappeur de point de terminaison.
3. La commande « Vérifier la topologie de réplication » dans sites et services Active Directory renvoie « Il
n’y a plus aucun point de terminaison disponible à partir du mappeur de point de terminaison ».
Le fait de cliquer avec le bouton droit sur l’objet de connexion à partir d’un dc source et de sélectionner «
Vérifier la topologie de réplication » échoue avec « Il n’y a plus de points de terminaison disponibles à
partir du mappeur de point de terminaison. Le message d’erreur à l’écran s’affiche ci-dessous :
Texte du titre de la boîte de dialogue : vérifier la topologie de réplication

L’erreur suivante s’est produite lors de la tentative de contact du contrôleur de domaine : aucun point
de terminaison n’est disponible à partir du mappeur de point de terminaison.
OK
4. La commande « répliquer maintenant » dans sites et services Active Directory renvoie « Il n’y a plus
aucun point de terminaison disponible à partir du mappeur de point de terminaison ».
Le fait de cliquer avec le bouton droit sur l’objet de connexion à partir d’un dc source et de choisir «
répliquer maintenant » échoue avec « Il n’y a plus de points de terminaison disponibles à partir du
mappeur de point de terminaison. Le message d’erreur à l’écran s’affiche ci-dessous :
Texte du titre de la boîte de dialogue : répliquer maintenant

Texte du message de <directory partition name> <Source DC> <Destination DC>boîte de dialogue :
l’erreur suivante s’est produite lors de la tentative de synchronisation du contexte d’attribution de
noms du contrôleur de domaine au contrôleur de domaine : il n’existe aucun point de terminaison
disponible à partir du mappeur de point de terminaison.
Boutons dans la boîte de dialogue : OK
5. Les événements NTDS Knowledge Consistency Checker (KCC), NTDS General ou Microsoft-Windows-
ActiveDirectory_DomainService avec l’état 1753 sont enregistrés dans le journal des événements du
service d’annuaire.
Les événements Active Directory qui mentionnent généralement l’état 1753 sont les suivants :
NTDS General 1655 Active Directory a tenté de

communiquer avec le catalogue
global suivant et les tentatives ont
échoué.
NTDS KCC 1925 La tentative d’établissement d’un

NTDS KCC 1265 Une tentative du Contrôleur de

cohérence des connaissances (KCC)
pour ajouter un contrat de
réplication pour la partition
d’annuaire et le contrôleur de
domaine source suivants a échoué.
Cause
Le diagramme ci-dessous illustre le flux de travail Appel de procédure distante (RPC). Le flux de travail
commence par l’inscription de l’application serveur avec le Mappeur de point de terminaison RPC (EPM) à
l’étape 1. Elle se termine par le passage des données du client RPC à l’application cliente à l’étape 7.
Les étapes 1 à 7 muivent les opérations suivantes :
1. L’application serveur inscrit ses points de terminaison auprès du mappeur de point de terminaison RPC
(EPM).
2. Le client effectue un appel RPC pour le compte d’un utilisateur, d’un système d’exploitation ou d’une
opération initiée par l’application.
3. Le RPC côté client contacte le programme EPM des ordinateurs cibles et demande au point de terminaison
de terminer l’appel client.
4. Le système EPM de l’ordinateur serveur répond par un point de terminaison.
5. Le RPC côté client contacte l’application serveur.
6. L’application serveur exécute l’appel, renvoie le résultat au RPC client.
7. Rpc côté client transmet le résultat à l’application cliente.
L’échec 1753 est généré par un échec entre les étapes 3 et 4. Plus précisément, l’erreur 1753 signifie que le client
RPC (DC de destination) peut contacter le serveur RPC (DC source) sur le port 135, mais que le serveur EPM sur
le serveur RPC (DC source) n’a pas pu localiser l’application RPC d’intérêt et a renvoyé l’erreur côté serveur
1753. L’erreur indique que le client RPC (DC de destination) a reçu la réponse d’erreur côté serveur du serveur
RPC (dc source de réplication AD) sur le réseau.
Les causes racines spécifiques de l’erreur 1753 sont les suivantes :
1. L’application serveur n’a jamais démarré. Autrement dit, l’étape 1 du diagramme « Plus d’informations » n’a
jamais été tentée.
2. L’application serveur a démarré, mais un échec s’est créé lors de l’initialisation. L’échec l’a empêché de
s’inscrire auprès du mapper du point de terminaison RPC. Autrement dit, l’étape 1 du diagramme « Plus
d’informations » a été tentée mais a échoué.
3. L’application serveur a démarré, mais plus tard. Autrement dit, l’étape 1 du diagramme « Plus d’informations
» a été effectuée avec succès. Elle a été annulée plus tard, car le serveur a été annulé.
4. L’application serveur a désinsgré manuellement ses points de terminaison (similaires à 3, mais intentionnels).
Peu probable, mais inclus pour l’intégralité.)
5. Le client RPC (DC de destination) a contacté un serveur RPC différent de celui prévu. Cela est dû à une erreur
de mappage de nom à IP dans le fichier DNS, WINS ou hôte/lmhosts.
L’erreur 1753 n’est PAS causée par :
un manque de connectivité réseau entre le client RPC (DC de destination) et le serveur RPC (DC source) sur
le port 135.
un manque de connectivité réseau entre le serveur RPC (DC source) utilisant le port 135 et le client RPC (DC
de destination) sur le port éphémère.
non-connexion du mot de passe ou incapacité de la source DC à déchiffrer un paquet chiffré Kerberos.
Résolution
Vérifier que le service enregistrant son service auprès du mappeur de point de terminaison a démarré
Pour Windows DCS 2000 et Windows Server 2003 : assurez-vous que le dc source est démarré en mode
normal.
Pour Windows Server 2008 ou Windows Server 2008 R2 : à partir de la console de la source DC, démarrez le
Gestionnaire de services (services.msc). Vérifiez que le service Active Directory est en cours d’exécution.
Active Directory apparaît sous le nom « Services de domaine Active Directory »
Vérifiez que le client RPC (DC de destination) s’est connecté au serveur RPC prévu (DC source )
Tous les DCS d’une forêt Active Directory commune enregistrent un enregistrement CNAME DC guided dans le
_msdcs.<forest root domain> Zone DNS, quel que soit le domaine dans quoi ils résident dans la forêt.
L’enregistrement CNAME DC guidé est dérivé de l’objectGUID de chaque objet DCs NTDS Paramètres objet.
Lors d’opérations basées sur la réplication, un dc de destination interroge DNS pour l’enregistrement CNAME
GUIDED DCS source. L’enregistrement CNAME contient le nom complet de l’ordinateur DC source. Ce nom est
utilisé pour dériver l’adresse IP DCS source via :
Recherche dans le cache client DNS
Recherche de fichier Hôte/LMHost
enregistrement A/AAAA de l’hôte dans DNS ou WINS
Les objets NTDS obsolètes Paramètres et un nom erroné pour les mappages IP dans les fichiers DNS, WINS,
Host et LMHOST peuvent entraîner la connexion du client RPC (DC de destination) au mauvais serveur RPC
(SOURCE DC). En outre, le nom d’un mappage IP non sécurisé peut entraîner la connexion du client RPC (DC de
destination) à un ordinateur qui n’a même pas l’application serveur RPC d’intérêt (le rôle Active Directory dans
ce cas) installé. Par exemple, un enregistrement d’hôte obsolète pour DC2 contient l’adresse IP de DC3 ou d’un
ordinateur membre.
Vérifiez que les GUID suivants correspondent :
GUID d’objet pour le DC source qui existe dans la copie DCS de destination d’Active Directory
GUID de l’objet DC source stocké dans la copie DCS source d’Active Directory.
En cas de différence, repadmin /showobjmeta utilisez l’objet paramètres NTDS pour voir lequel correspond à la
dernière promotion de la source DC. Comparez les cachets de date suivants :
Date de création Paramètres’objet NTDS à partir de /showobjmeta .
Dernière date de promotion dans le fichier DCs dcpromo.log source.
Vous de devez peut-être utiliser la dernière date de modification/création du DCPROMO. Fichier JOURNAL lui-
même. Si les GUID de l’objet ne sont pas identiques, le DC de destination peut avoir un objet Paramètres NTDS
obsolète pour le DC source dont l’enregistrement CNAME fait référence à un enregistrement hôte avec un nom
de mappage IP non fiable.
Sur le dc de destination, exécutez IPCONFIG /ALL pour déterminer les serveurs DNS que le dc de destination
utilise pour la résolution de noms :
c:\>ipconfig /all
Sur la dc de destination, exécutez l’enregistrement NSLOOKUP DC CNAME complet des DCS sources :
c:\>nslookup -type=cname \<fully qualified cname of source DC> <destination DCs primary DNS Server IP >
c:\>nslookup -type=cname \<fully qualified cname of source DC> <destination DCs secondary DNS Server IP>
Vérifiez que l’adresse IP renvoyée par NSLOOKUP « possède » le nom d’hôte /l’identité de sécurité de la source
DC.
a) C:\\>NBTSTAT -A \\<IP address _returned_ by NSLOOKUP in the step above>
OR
b) Connectez-vous à la console de la source DC, IPCONFIG exécutez l’invite CMD et vérifiez que le DC source
possède l’adresse IP renvoyée par la commande NSLOOKUP ci-dessus.
Recherchez des hôtes obsolètes/dupliqués aux mappages IP dans le DNS.
NSLOOKUP -type=hostname \<single label hostname of source DC> \<primary DNS Server IP on destination DC>
NSLOOKUP -type=hostname \<single label hostname of source DC> \<secondary DNS Server IP on destination DC>
NSLOOKUP -type=hostname \<fully qualified computer name of source DC> \<primary DNS Server IP on destination
DC>
NSLOOKUP -type=hostname \<fully qualified computer name of source DC> \<secondary DNS Server IP on dest. DC>
Si des adresses IP non valides existent dans les enregistrements hôtes, recherchez si le nettoyage DNS est activé
et correctement configuré.
Si les tests ci-dessus ou une trace réseau n’indiquent pas une requête de nom renvoyant une adresse IP non
valide, envisagez des entrées obsolètes dans les fichiers HOST, les fichiers LMHOSTS et les serveurs WINS. Les
serveurs DNS peuvent également être configurés pour effectuer une résolution de nom de retour WINS.
Vérifiez que l’application serveur (Active Directory, et ainsi de suite ) s’est inscrite auprès du mappeur de point
de terminaison sur le serveur RPC (source DC )
Active Directory utilise un mélange de ports enregistrés dynamiquement et connus. Les ports et protocoles
connus utilisés par les contrôleurs de domaine Active Directory sont les suivants :
A P P L IC AT IO N
SERVEUR RP C P O RT TC P UDP C O M M EN TA IRES
Serveur DNS 53 Ã Ã
Kerberos 88 Ã Ã
Serveur LDAP 389 Ã Ã
Microsoft-DS 445 Ã Ã
LDAP SSL 636 Ã Ã
Serveur de catalogue 3268 Ã

global
A P P L IC AT IO N
SERVEUR RP C P O RT TC P UDP C O M M EN TA IRES
Serveur de catalogue 3269 Ã

global
Les ports connus ne sont PAS enregistrés auprès du mappeur de point de terminaison.
Active Directory et d’autres applications enregistrent également les services qui reçoivent des ports affectés
dynamiquement dans la plage de ports éphémère RPC. Ces applications serveur RPC sont affectées
dynamiquement aux ports TCP entre 1024 et 5 000 sur les ordinateurs Windows 2000 et Windows Server 2003.
Ils sont attribués dynamiquement aux ports TCP entre 49152 et 65535 sur les ordinateurs Windows Server
2008 et Windows Server 2008 R2. Le port RPC utilisé par la réplication peut être codé en dur dans le Registre à
l’aide des étapes documentées dans MSKB 224196. Active Directory continue de s’inscrire auprès de l’EPM
lorsqu’il est configuré pour utiliser un port codé en dur.
Vérifiez que l’application de serveur RPC d’intérêt s’est inscrite auprès du mappeur de point de terminaison RPC
sur le serveur RPC (dc source dans le cas de la réplication AD).
Il existe plusieurs façons d’accomplir cette tâche. L’une consiste à installer et exécuter PORTQRY à partir d’une
invite de commandes privilégiée par l’administrateur sur la console du DC source :
c:\>portquery -n \<source DC> -e 135 >file.txt
portqry Dans la sortie, notez les numéros de port enregistrés dynamiquement par « MS NT Directory DRS
Interface » (UUID = 351...) pour le protocole ncacn_ip_tcp . L’extrait de code ci-dessous présente un exemple de
sortie d’un dc Windows Server 2008 R2 et de la paire UUID/protocole utilisée par Active Directory en gras :
UUID : e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface ncacn_np:CONTOSO-

DC01[\pipelsass\]
UUID : e3514235-4b06-11d1-ab04-00c04fc2dcd2 Interface DRS du répertoire MS NT
ncacn_np:CONTOSO-DC01[\PIPE\ protected_storage]
ncacn_ip_tcp:CONTOSO-DC01[49156]
ncacn_http:CONTOSO-DC01[49157]
ncacn_http:CONTOSO-DC01[6004]
Autres causes
1. Vérifiez que le dc source est démarré en mode normal. Vérifiez également que le rôle de système
d’exploitation et de dc sur le dc source a démarré entièrement.
2. Vérifiez que le service de domaine Active Directory est en cours d’exécution. Si le service est actuellement
arrêté ou n’a pas été configuré avec les valeurs de démarrage par défaut, réinitialisez les valeurs de
démarrage par défaut. Redémarrez le dc modifié, puis réessayez l’opération.
3. Vérifiez que la valeur de démarrage et l’état du service pour le service RPC et RPC Locator sont corrects
pour la version du système d’exploitation du client RPC (DC de destination) et du serveur RPC (DC
source). Si le service est actuellement arrêté ou n’a pas été configuré avec les valeurs de démarrage par
défaut, réinitialisez les valeurs de démarrage par défaut. Redémarrez le dc modifié, puis réessayez
l’opération.
Assurez-vous également que le contexte de service correspond aux paramètres par défaut.
W IN DO W S 2000 VA L EUR DE DÉM A RRA GE ÉTAT DU SERVIC E
Appel de procédure distante (RPC) Automatique Démarré
Localisateur d’appel de procédure Automatique Démarré

distante (RPC)
Windows Ser ver 2003, Ser ver Valeur de démarrage État du ser vice
2008, Ser ver 2008 R2
Appel de procédure distante (RPC) Automatique Démarré
Localisateur d’appel de procédure Manual Null ou Stopped

distante (RPC)
4. Vérifiez que la taille de la plage de ports dynamiques n’a pas été limitée. La syntaxe WINDOWS Server
2008 et Windows Server 2008 R2 NETSH pour l’éumérer de la plage de ports RPC est indiquée ci-
dessous :
>netsh int ipv4 show dynamicport tcp

>netsh int ipv4 show dynamicport udp
>netsh int ipv6 show dynamicport tcp
>netsh int ipv6 show dynamicport udp
5. Examinez les 224196 de la 224196. Assurez-vous que le port codé en dur se trouve dans la plage de
ports éphémère de la version du système d’exploitation de dc source.
6. Vérifiez que la clé ClientProtocols existe HKLM\Software\Microsoft\Rpc sous et contient les cinq valeurs par
défaut suivantes :
ncacn_http REG_SZ rpcrt4.dll

ncacn_ip_tcp REG_SZ rpcrt4.dll
ncacn_nb_tcp REG_SZ rpcrt4.dll
ncacn_np REG_SZ rpcrt4.dll
ncacn_ip_udp REG_SZ rpcrt4.dll
Exemple de nom incorrect au mappage IP à l’origine de l’erreur RPC 1753 et -2146893022 : le nom de
principal cible est incorrect
Le contoso.com domaine se compose de \\DC1 \et \DC2 avec les adresses IP x.x.1.1 et x.x.1.2. Les
enregistrements « A » / « AAAA \» de l’hôte pour \DC2 sont correctement enregistrés sur tous les serveurs DNS
\configurés pour \DC1. En outre, le fichier HOSTS \sur \DC1 contient un mappage d’entrée du nom d’hôte
complet DC2 à l’adresse IP x.x.1.2. Plus tard, l’adresse IP de DC2 change de X.X.1.2 à X.X.1.3 et un nouvel
ordinateur membre est joint au domaine avec l’adresse IP x.x.1.2. Les tentatives de réplication AD déclenchées
par la commande « répliquer maintenant » dans le logiciel en ligne Sites et services Active Directory échouent
avec l’erreur 1753. Le suivi est illustré ci-dessous :
F#'opération DEST SRC

1 X.x.1.1 x.x.1.2 ARP:Request, x.x.1.1 demande x.x.1.2
2 X.x.1.2 x.x.1.1 ARP:Response, x.x.1.2 au 00-13-72-28-C8-5E
3 x.x.1.1 x.x.1.2 TCP:Flags=: S., SrcPort=50206, résolution de point de terminaison DstPort=DCE(135)
4 x.x.1.2 x.x.1.1 ARP:Request, x.x.1.2 demande x.x.1.1
5 x.x.1.1 x.x.1.2 ARP:Response, x.x.1.1 au 00-15-5D-42-2E-00
6 x.x.1.2 x.x.1.1 TCP:Flags=... A.. Résolution de point de terminaison S., SrcPort=DCE(135)
7 x.x.1.1 x.x.1.2 TCP:Flags=... A...., SrcPort=50206, DstPort=DCE endpoint resolution(135)
8 x.x.1.1 x.x.1.2 MSRPC:c/o Bind : UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
9 x.x.1.2 x.x.1.1 MSRPC:c/o Bind Ack: Call=0x2 Assoc Grp=0x5E68 Xmit=0x16D0 Recv=0x16D0
10 x.x.1.1 x.x.1.2 EPM:Request : ept_map : NDR, DRSR(DRSR) {E3514235-4B06-11D1-AB04-00C04FC2DCD2}
[Résolution de point de terminaison DCE(135)]
11 x.x.1.2 x.x.1.1 EPM:Response : ept_map : 0x16C9A0D6 - EP_S_NOT_REGISTERED
À l’image 10 , le dc de destination interroge le mapper de point de fin des DCs source sur le port 135 pour la
classe de service de réplication Active Directory UUID {E351...}
Dans l’image 11 , la source DC, dans ce cas un ordinateur membre, n’héberge pas encore le rôle DC. Il n’a donc
pas inscrit {E351...} UUID pour le service de réplication avec son EPM local. Le dc source répond par une erreur
symbolique EP_S_NOT_REGISTERED. Cette erreur est mappée à l’erreur décimale 1753, à la 0x6d9 d’erreur
hexadécimale et à l’erreur conviviale « Il n’y a plus aucun point de terminaison disponible à partir du mappeur
de point de terminaison ».
Plus tard, l’ordinateur membre avec l’adresse IP x.x.1.2 est promu en tant que réplica « MayberryDC » dans le
contoso.com domaine. Là encore, la commande « répliquer maintenant » est utilisée pour déclencher la
réplication, mais cette fois-ci échoue avec l’erreur à l’écran « le nom principal cible est incorrect ». L’ordinateur
dont la NIC possède l’adresse IP x.x.1.2 est un contrôleur de domaine. Il est actuellement démarré en mode
normal et a inscrit le {E351...} UUID du service de réplication avec son EPM local. Mais il ne possède pas le
nom/l’identité de sécurité de DC2 et ne peut pas déchiffrer la demande Kerberos de DC1. Ainsi, la demande
échoue avec l’erreur « Le nom principal cible est incorrect ». Cette erreur est mimique à l’erreur décimale -
2146893022, erreur hexadécimale 0x80090322.
Ces mappages hôte à IP non valides peuvent être causés par des entrées obsolètes dans des fichiers
hôte/lmhost, des inscriptions a/AAAA d’hôte dans DNS ou WINS.
Résumé :
L’exemple 1 a échoué en raison d’un hôte au mappage IP non valide (dans le fichier HOST dans ce cas). Cela a
provoqué la résolution du dc de destination en un dc « source » qui n’avait pas le service AD en cours
d’exécution (ou même installé pour cette raison). Le SPN de réplication n’était donc pas encore enregistré et
le dc source a renvoyé l’erreur 1753.
Dans le deuxième cas, un hôte au mappage IP non valide (là encore dans le fichier HOST) a entraîné la
connexion du dc de destination à un dc qui avait inscrit le {E351...} SPN de réplication. Mais cette source avait
un nom d’hôte et une identité de sécurité différents de la source prévue DC, donc les tentatives ont échoué
avec l’erreur -2146893022 : le nom de principal cible est incorrect .
Contenu connexe
Vue d’ensemble du service et exigences relatives aux ports réseau pour Windows Server
Restriction du trafic de réplication Active Directory et du trafic RPC client vers un port spécifique
Comment configurer l’allocation de ports dynamiques RPC pour qu’elle fonctionne avec le pare-feu
Fonctionnement du RPC
Comment le serveur se prépare à une connexion
Comment le client établit une connexion
Inscription de l’interface
Rendre le serveur disponible sur le réseau
Inscription des points de terminaison
Écoute des appels clients
Comment le client établit une connexion
224196 restriction du trafic de réplication Active Directory et du trafic RPC client vers un port spécifique
SPN pour un dc cible dans AD DS
Erreur de réplication Active Directory 8524 :
l’opération DSA ne peut pas se poursuivre en raison
d’un échec de recherche DNS
Cet article décrit les symptômes, la cause et les étapes de résolution des opérations AD qui échouent avec
l’erreur Win32 8524 :
L’opération DSA ne peut pas se poursuivre en raison d’un échec de recherche DNS.

Microsoft.
Symptômes
1. DCDIAG signale que le test réplications Active Directory a échoué avec l’état 8524 :
Serveur de test : <sitename><destination DC>

[Vérification des réplications,<destination DC>] Une tentative de réplication récente a échoué : De
<source DC> à <destination DC>
Contexte d’attribution de noms :
CN=<DN path for failing directory partition>,DC=Contoso,DC=Com
2. REPADMIN signale qu’une tentative de réplication a échoué avec l’état 8524.

REPADMIN /REPLSUM
REPADMIN /SHOWREPS
REPADMIN /SHOWREPL
Un exemple de 8 524 échecs de REPADMIN /SHOWREPL est illustré ci-dessous :
Options DSA : IS_GC
GUID d’objet DSA : DSA invocationID :
DC=contoso,DC=com
Last attempt @ YYYY-MM-DD HH:MM:SS failed, result 8524 (0x214c) :
1(s) défaillance(s) consécutive(s).
Dernière réussite @ YYYY-MM-DD HH:MM:SS.
Reste de la sortie /showrepl tronquée

3. L’un des événements suivants avec l’état 8524 est consigné dans le journal des événements du service
d’annuaire :
NTDS Knowledge Consistency Checker (KCC)
NTDS General
Microsoft-Windows-ActiveDirectory_DomainService
ÉVÉN EM EN T SO URC E C H A ÎN E D’ÉVÉN EM EN T
Microsoft-Windows- 2023 Ce serveur d’annuaire n’a pas pu

ActiveDirectory_DomainService répliquer les modifications
apportées au serveur d’annuaire
distant suivant pour la partition
d’annuaire suivante.

échoué.
NTDS KCC 1308 Le KCC a détecté que les tentatives

successives de réplication avec le
service d’annuaire suivant ont
constamment échoué.
NTDS KCC 1865 Le KCC n’a pas pu former une

topologie de réseau d’arborescence
complète. Par conséquent, la liste de
sites suivante n’est pas accessible à
partir du site local

NTDS KCC 1926 Échec de la tentative

d’établissement d’un lien de
réplication vers une partition de
paramètres suivants
4. Les contrôleurs de domaine enregistrent les événements de réplication NTDS 2087 et NTDS Replication
2088 dans le journal des événements du service d’annuaire :

Date : <date> <time>
Niveau : Error
Ordinateur : <dc name>.<domain name>
Description :
Les services de domaine Active Directory n’ont pas pu résoudre le nom d’hôte DNS suivant du
contrôleur de domaine source en adresse IP. Cette erreur empêche les ajouts, suppressions et
modifications dans les services de domaine Active Directory de se répliquer entre un ou plusieurs
contrôleurs de domaine dans la forêt. Les groupes de sécurité, la stratégie de groupe, les utilisateurs
et les ordinateurs, ainsi que leurs mots de passe seront incohérents entre les contrôleurs de domaine
jusqu’à ce que cette erreur soit résolue. Cela affecte potentiellement l’authentification par logo et
l’accès aux ressources réseau.

Ordinateur : <dc name>.<domain name>
Description :
Les services de domaine Active Directory n’ont pas pu utiliser DNS pour résoudre l’adresse IP du
contrôleur de domaine source répertorié ci-dessous. Pour maintenir la cohérence des groupes de
sécurité, de la stratégie de groupe, des utilisateurs et des ordinateurs et de leurs mots de passe, les
services de domaine Active Directory ont été répliqués avec succès à l’aide de NetBIOS ou du nom
d’ordinateur complet du contrôleur de domaine source.
Une configuration DNS non valide peut affecter d’autres opérations essentielles sur les ordinateurs
membres, les contrôleurs de domaine ou les serveurs d’applications dans cette forêt des services de
domaine Active Directory, y compris l’authentification d’authentification ou l’accès aux ressources
réseau.
Vous devez immédiatement résoudre cette erreur de configuration DNS afin que ce contrôleur de
domaine puisse résoudre l’adresse IP du contrôleur de domaine source à l’aide du DNS.
Cause
L’état d’erreur 8524 est map pour la chaîne d’erreur suivante :
Il s’agit d’une erreur « catch-all » pour toutes les défaillances DNS possibles affectant Active Directory sur les
contrôleurs de domaine post-Windows Server 2003 SP1.
Microsoft-Windows-ActiveDirectory_DomainService l’événement 2087 est un événement partenaire d’autres
événements Active Directory qui mentionnent l’état 8524 si un contrôleur de domaine Active Directory ne
parvient pas à résoudre un dc distant par son enregistrement CNAME complet (<object guid for source DCs
NTDS Settings object>._msdcs.<forest root domain>) à l’aide du DNS.
Microsoft-Windows-ActiveDirectory_DomainService l’événement 2088 est journalisé lorsqu’un contrôleur de
domaine source est résolu avec succès par son nom NetBIOS, mais que ce type de solution de résolution de
nom se produit uniquement en cas d’échec de la résolution des noms DNS.
La présence de l’état 8524 et des événements Microsoft-Windows-ActiveDirectory_DomainService 2088 ou
2087 indiquent tous que la résolution de noms DNS échoue dans Active Directory.
En résumé, l’état de réplication 8524 est consigné lorsqu’un dc de destination ne peut pas résoudre le DC source
par ses enregistrements CNAME et Hôte « A » ou Hôte « AAAA » à l’aide du DNS. Les causes racines spécifiques
sont les suivantes :
1. Le DC source est hors connexion ou n’existe plus, mais son objet Paramètres NTDS existe toujours dans la
copie DCS de destination d’Active Directory.
2. Le dc source n’a pas réussi à enregistrer le CNAME ou les enregistrements d’hôte sur un ou plusieurs
serveurs DNS pour les raisons suivantes :
Les tentatives d’inscription ont échoué.
Les paramètres du client DNS sur la source ne pointent pas vers des serveurs DNS qui hébergent, ont
été transmis ou déléguer _msdcs.<forest root domain zone and (or) primary DNS suffix domain
zones>
3. Les paramètres du client DNS sur le dc de destination ne pointent pas vers les serveurs DNS qui
hébergent, avancent ou déléguent les zones DNS contenant le CNAME ou les enregistrements d’hôte
pour le DC source
4. Les enregistrements CNAME et hôte enregistrés par le dc source n’existent pas sur les serveurs DNS
interrogés par le dc de destination pour les raisons suivantes :
Latence de réplication simple
Un échec de réplication
Un échec de transfert de zone
5. Des délégations ou des forwardeurs non valides. Ils empêchent le dc de destination de résoudre les
enregistrements CNAME ou Host pour les DCS dans d’autres domaines de la forêt.
6. Les serveurs DNS utilisés par les serveurs DNS de destination, dc source ou intermédiaires ne
fonctionnent pas correctement.
Résolution
Vérifier si le 8524 est dû à un dc hors connexion ou à des métadonnées DC obsolètes
Si l’erreur/événement 8524 fait référence à un dc actuellement hors connexion mais toujours valide dans la
forêt, rendez-le opérationnel.
Si l’erreur/événement 8524 fait référence à un dc inactif, supprimez les métadonnées obsolètes de ce dc de la
copie DCS de destination d’Active Directory. Un dc inactif est une installation dc qui n’existe plus sur le réseau,
mais son objet Paramètres NTDS existe toujours dans la copie DCS de destination d’Active Directory .
Le support Microsoft recherche régulièrement des métadonnées obsolètes pour des DCS inexistants ou des
métadonnées obsolètes des promotions précédentes d’un dc avec le même nom d’ordinateur qui n’a pas été
supprimé d’Active Directory.
Supprimer les métadonnées dc obsolètes si elles sont présentes
Nettoyage des métadonnées d’interface utilisateur graphique à l’aide des sites et services Active Directory (DSSITE). MSC)
1. Démarrez Windows Server 2008 ou Windows Server 2008 R2 Active Directory Sites and Services
(DSSITE). MSC).
Pour ce faire, vous pouvez également démarrer les services et sites Active Directory sur un ordinateur
Windows Vista ou Windows 7 qui a été installé dans le cadre du package Outils d’administration de
serveur distant (RSAT).
2. Concentrez le DSSITE. Le logiciel en snap-in MSC sur la copie DCS de destination d’Active Directory.
Après le démarrage de DSSITE. MSC, cliquez avec le bouton droit sur « Sites et services Active Directory
[<DC Name>]
Sélectionnez le contrôleur de domaine de destination qui journalisation l’erreur/l’événement 8524 dans
la liste des PC visibles dans le « Modifier contrôleur de domaine... » list
3. Supprimez l’objet DCs NTDS source Paramètres dans les erreurs et événements 8524. Utilisateurs et
ordinateurs Active Directory (DSA). MSC) s’enclenche et supprime l’objet DCs NTDS source
Paramètres’objet.
Un objet DCs NTDS Paramètres s’affiche
Sous le conteneur Sites, Nom du site, Serveurs et %server name%
Au-dessus de l’objet de connexion entrante affiché dans le volet droit des sites et services Active
Directory.
La mise en surbrillante rouge dans la capture d’écran ci-dessous montre l’objet Paramètres NTDS pour
CONTOSO-DC2 situé sous le site Default-First-Site-Name.
Cliquez avec le bouton droit sur l’objet Paramètres NTDS obsolète que vous souhaitez supprimer, puis
sélectionnez « Supprimer ».
Le nettoyage des métadonnées peut également être effectué à partir du logiciel en ligne Utilisateurs et
ordinateurs Active Directory W2K8 /W2K8 R2, comme documenté dans TECHNET.
Nettoyage des métadonnées de ligne de commande à l’aide de NTDSUTIL
La méthode héritée ou de ligne de commande de suppression d’objets NTDS Paramètres obsolètes à l’aide de la
commande de nettoyage des métadonnées NTDSUTIL est documentée dans MSKB 216498.
Exécuter DCDIAG /TEST:DNS sur le DC source + dc de destination
DCDIAG /TEST:DNS fait sept tests différents pour rapidement savoir si l’état DNS d’un contrôleur de domaine est
en cours. Ce test n’est pas exécuté dans le cadre de l’exécution par défaut de DCDIAG.
1. Connectez-vous Enterprise informations d’identification d’administrateur à la console des contrôleurs de
domaine de destination qui enregistrent les événements 8524.
2. Ouvrez une invite DE CMD privilégiée d’administration, DCDIAG /TEST:DNS /F puis exécutez la
journalisation de l’état 8424 et du DC source à partir de la copie dc de destination.
Pour exécuter DCDIAG sur tous les DCS d’une forêt, tapez DCDIAG /TEST:DNS /V /E /F:<File name.txt> .
Pour exécuter DCDIAG TEST:DNS sur un DC spécifique, tapez
DCDIAG /TEST:DNS /V /S:<DC NAME> /F:<File name.txt> .
3. Recherchez le tableau récapitulatif à la fin de la DCDIAG /TEST:DNS sortie. Identifier et rapprocher les
conditions d’avertissement ou d’échec sur les DCS pertinents du rapport.
4. Si DCDIAG n’identifie pas la cause première, faites le « long chemin » en suivant les étapes ci-dessous.
Vérifier la résolution de noms Active Directory à l’aide de la commande PING
Les DCS de destination résolvent les DCS sources dans DNS par leurs enregistrements CNAME complets qui
sont dérivés du GUID d’objet de l’objet NTDS Paramètres distant (l’objet parent vers les objets de connexion
visibles dans le logiciel en ligne Sites et services Active Directory). Vous pouvez tester la capacité d’un DCs
donné à résoudre un enregistrement CNAME complet DC source à l’aide de la commande PING.
1. Recherchez l’objetGUID de l’objet DCs NTDS source Paramètres dans la copie DCS source d’Active
Directory.
À partir de la console de la source DC journalisation de l’erreur/événement 8524, tapez :
repadmin /showrepl <fully qualified hostname of source DC cited in the 8524 error (event)>
Par exemple, si le dc référencé dans l’événement/erreur 8524 est contoso-DC2 contoso.com dans le
domaine, tapez :
repadmin /showrepl contoso-dc2.contoso.com
Le champ « GUID repadmin /SHOWREPl d’objet DSA » dans l’en-tête de la commande contient l’objet
OBJECTGUID de l’objet de paramètres NTDS actuel des DCS sources. Utilisez la vue des DCS sources de
son objet Paramètres NTDS au cas où la réplication serait lente ou défaillante. L’en-tête de la repadmin
sortie ressemblera à :
Options DSA : IS_GC
GUID d’objet DSA : 8a7baee5-cd81-4c8c-9c0f-b10030574016 <- cliquez avec le bouton droit +
copiez cette chaîne dans la Windows
< presse-papiers & coller dans celui-ci la commande PING dans
<- étape 4
2. Recherchez l’ObjectGUID de la source DC dans la copie DCS de destination d’Active Directory.

À partir de la console de destination DC journalisation de l’erreur/événement 8524, tapez :
repadmin /showrepl <fully qualified hostname of destination DC>
Par exemple, si l’erreur/événement de journalisation dc 8524 est contoso-DC1 contoso.com dans le

domaine, tapez :
repadmin /showrepl contoso-dc1.contoso.com
REPADMIN /SHOWREPLla sortie est indiquée ci-dessous. Le champ « GUID d’objet DSA » est répertorié pour
chaque DC source à partir de la réplication entrante DC de destination.
c:\>repadmin /showreps `contoso-dc1.contoso.com`
DSA Options: IS_GC
Site Options: (none)
DSA object GUID:
DSA invocationID:
DC=contoso,DC=com
DSA object GUID: 8a7baee5-cd81-4c8c-9c0f-b10030574016 <- Object GUID for source DC
derived from
Last attempt @ 2010-03-24 15:45:15 failed, result 8524 (0x214c): \ destination DCs
copy of Active Directory
The DSA operation is unable to proceed because of a DNS lookup failure.
23 consecutive failure(s).
Last success @ YYYY-MM-DD HH:MM:SS.
3. Comparez le GUID de l’objet des valeurs 2 et 3.

Si les GUID de l’objet sont les mêmes, les DC source et de destination connaissent la même ins
instantiation (la même promotion) de la source DC. S’ils sont différents, figurez celui qui a été créé
ultérieurement. L’objet de paramètre NTDS avec la date de création antérieure est probablement obsolète
et doit être supprimé.
4. Ping sur la source DC par son CNAME complet.
À partir de la console du dc de destination, testez la résolution de nom d’Active Directory avec un ping de
l’enregistrement CNAME complet des DCS sources :
c:\>ping <ObjectGUID> from source DCs NTDS Settings object._msdcs.<DNS name for Active Directory
forest root domain>
À l’aide de notre exemple de l’objetGUID 8a7baee5... à partir de la sortie ci-dessus à partir du dc

contoso.com contoso-dc1 dans le domaine, la syntaxe PING serait la suivante : repadmin /showreps
c:\>ping 8a7baee5-cd81-4c8c-9c0f-b10030574016. _msdcs.contoso.com
Si ping fonctionne, réessayez l’opération ayant échoué dans Active Directory. En cas d’échec de la
commande PING, procédez à l’opération « Résoudre l’échec de recherche DNS 8524 », mais réessayez le
test PING après chaque étape jusqu’à ce qu’il soit résolu.
Résoudre l’échec de recherche DNS 8524 : le long chemin
Si les erreurs/événements 8524 ne sont pas causés par des métadonnées DC obsolètes et que le test PING
CNAME échoue, testez l’état DNS de :
The source DC
Dc de destination
Serveurs DNS utilisés par les DCS source et de destination
En résumé, vérifiez que :
Le dc source a inscrit le CNAME et les enregistrements d’hôte avec un DNS valide.
Le dc de destination pointe vers des serveurs DNS valides.
Les enregistrements d’intérêt enregistrés par les DCS source peuvent être résolus par les DCS de destination.
Le texte du message d’erreur dans l’événement client RPC DS 2087 documente une action de l’utilisateur pour
résoudre l’erreur 8524. Voici un plan d’action plus détaillé :
1. Vérifier que le dc source pointe vers des ser veurs DNS valides
Sur la source DC, vérifiez que les paramètres du client DNS pointent exclusivement vers des serveur DNS
opérationnels qui hébergent, the_msdcs.<forest root domain> (autrement dit, tous les DCS de la forêt
contoso.com enregistrer des enregistrements CNAME dans the_msdcs.contoso.com)
AND
Zone DNS pour le domaine Active Directory (autrement dit, un ordinateur du domaine contoso.com
enregistre les enregistrements d’hôte dans contoso.com zone).
AND
Le domaine de suffixe DNS principal des ordinateurs est différent du nom de domaine Active Directory
(voir l’article Technet Disjoint Namespace).
Les options pour valider qu’un serveur DNS héberge, les avants ou les délégués (autrement dit, « peut
résoudre ») de telles zones incluent.
Démarrez l’outil de gestion DNS pour votre DNS et vérifiez les serveurs DNS vers lesquels le dc
source pointe pour héberger les zones en question pour la résolution de noms.
Utilisez NSLOOKUP pour vérifier que tous les serveurs DNS pointant vers le dc source peuvent
résoudre les requêtes pour les zones DNS en question.
Exécuter IPCONFIG /ALL sur la console du DC source
c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 10.45.42.99 <- Primary DNS Server IP>
10.45.42.101<- Secondary DNS Server IP>
Exécutez les requêtes NSLOOKUP suivantes :
c:\>nslookup -type=soa <Source DC DNS domain name> <source DCs primary DNS Server IP >
c:\>nslookup -type=soa < Source DC DNS domain name > <source DCs secondary DNS Server IP >
c:\>nslookup -type=soa <_msdcs.<forest root DNS domain> <source DCs primary DNS Server IP >
c:\>nslookup -type=soa <_msdcs.<forest root DNS domain> <source DCs secondary DNS Server IP >
Par exemple, CHILD.CONTOSO.COM contoso.com si un dc dans le domaine de la forêt est configuré

avec les IPS du serveur DNS principal et secondaire « 10.45.42.99 » et « 10.45.42.101 », la syntaxe
NSLOOKUP serait la suivante :
c:\>nslookup -type=soa child.contoso.com 10.45.42.99

c:\>nslookup -type=soa _msdcs.contoso.com 10.45.42.99
Remarques :
La requête SOA pour la zone _mscs.contoso.com est résolue correctement si le DNS ciblé dispose d’un
bon forwardeur ou délégation ou pour the_msdcs.<forest root zone> Elle ne sera pas résolue
correctement si l'_msdcs.<forest root zone> sur le serveur DNS interrogé est un sous-domaine
<forest root zone> non délégué de la relation de zone créée par Windows 2000 domaines.
Les enregistrements CNAME sont toujours enregistrés dans le _msdcs.<forest root zone>, même pour
DC dans les domaines non racine.
La configuration du client DNS d’un ordinateur dc ou membre pour qu’il pointe vers un serveur DNS
ISP pour la résolution de noms n’est pas valide. La seule exception est que le FS A été contracté (c’est-
à-dire, payé) et héberge actuellement, a transmis ou déléguer des requêtes DNS pour votre forêt
Active Directory.
En règle générale, les serveurs DNS isP n’acceptent pas les mises à jour DNS dynamiques, de sorte
que les enregistrements CNAME, Host et SRV doivent être enregistrés manuellement.
2. Vérifier que la source DC a inscrit son enregistrement CNAME
Utilisez l’étape 1 de « Vérifier la résolution de noms Active Directory à l’aide de ping » pour localiser
l’enregistrement CNAME actuel de la source DC.
Exécutez ipconfig /all cette commande sur la console de la source DC pour déterminer les serveurs
DNS vers lesquels le dc source pointe pour la résolution de noms.
c:\>ipconfig /all
…
DNS Servers . . . . . . . . . . . : 10.45.42.99 <primary DNS Server IP
10.45.41.101 <secondary DNS Server IP
Utilisez NSLOOKUP pour interroger les serveurs DNS actuels pour l’enregistrement CNAME des DCS
sources (trouvé via la procédure de la procédure « Vérifier la résolution de noms Active Directory à l’aide
de ping »).
c:\>nslookup -type=cname <fully qualified cname of source DC> <source DCs primary DNS Server IP >
c:\>nslookup -type=cname <fully qualified cname of source DC> <source DCs secondary DNS Server IP>
Dans l’exemple, NTDS Paramètres objectGUID pour contoso-dc2 dans le domaine contoso.com est
8a7baee5-cd81-4c8c-9c0f-b10030574016. Il pointe vers « 10.45.42.99 » comme principal pour la
résolution de nom DNS. La syntaxe NSLOOKUP serait la suivante :
c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 10.45.42.99

Si la source DC n’a pas inscrit son enregistrement CNAME sur les serveurs DNS vers qui il pointe pour la
résolution de noms, exécutez la commande suivante à partir de la source DC. Ensuite, revérifiez
l’inscription de l’enregistrement CNAME :
c:\>net stop netlogon & net start netlogon
Remarques :
Les enregistrements CNAME sont enregistrés par le service NETLOGON au démarrage du système
d’exploitation, au démarrage du service NETLOGON et par intervalles périodiques ultérieurement.
Chaque promotion d’un dc du même nom peut créer un nouvel objet Paramètres NTDS avec un
objectGUID différent qui inscrit donc un enregistrement CNAME différent. Vérifiez l’inscription de
l’enregistrement CNAME en fonction de la dernière promotion de la source DC par rapport à
l’objectGUID pour l’objet Paramètres NTDS sur le dc de destination si la source a été promue plus de
1x.
Les problèmes de minutage au démarrage du système d’exploitation peuvent retarder l’inscription
DNS dynamique réussie.
Si l’enregistrement CNAME d’un dc a été enregistré avec succès, mais qu’il disparaît ultérieurement,
vérifiez la KB953317. Zones DNS dupliquées dans différentes étendues de réplication ou nettoyage
DNS trop agressif par le serveur DNS.
Si l’enregistrement CNAME échoue sur les serveurs DNS vers lesquels le dc source pointe pour la
résolution de noms, examinez les événements NETLOGN dans le journal des événements SYSTÈME
pour les échecs d’inscription DNS.
3. Vérifier que le dc source a inscrit ses enregistrements d’hôte
À partir de la console de la source DC, ipconfig /all exécutez l’applet de commande pour déterminer
les serveurs DNS vers lesquels le dc source pointe pour la résolution de noms.
c:\>ipconfig /all
…
Utilisez NSLOOKUP pour interroger les serveurs DNS actuels pour l’enregistrement d’hôte.
c:\>nslookup -type=A+AAAA <fully qualified hostname of source DC> <source DCs primary DNS Server IP
>
c:\>nslookup -type=A+AAAA <fully qualified hostname of source DC> <source DCs secondary DNS Server
IP>
Pour poursuivre l’exemple de nom d’hôte pour contoso-dc2 dans le domaine contoso.com est 8a7baee5-
cd81-4c8c-9c0f-b10030574016 et pointe vers self (127.0.0.1) comme principal pour la résolution de
noms DNS, la syntaxe NSLOOKUP serait la suivante :
c:\>nslookup -type=A+AAAA contoso-dc1.contoso.com 10.45.42.99

Répétez la commande NSLOOKUP par rapport à l’adresse IP du serveur DNS secondaire DNS source.
Pour inscrire dynamiquement les enregistrements « A » de l’hôte, tapez la commande suivante à partir de
la console de l’ordinateur :
c:\>ipconfig /registerdns
Remarques :
Windows ordinateurs 2000 à Windows Server 2008 R2 enregistrent tous des enregistrements « A »
d’hôte IPv4.
Windows server 2008 et Windows Server 2008 R2 enregistrent tous les enregistrements AAAA de
l’hôte IPv6.
Les enregistrements « A » et « AAAA » de l’hôte sont enregistrés dans la zone de suffixe DNS
principale des ordinateurs.
Désactivez les CCI qui ne sont pas attachées à des câbles réseau.
Désactivez l’inscription des enregistrements d’hôte sur les CCI qui ne sont pas accessibles aux PC et
aux ordinateurs membres sur le réseau.
Il n’est pas pris en charge de désactiver le protocole IPv6 en désactivant la case à cocher IPv6 dans les
propriétés de la carte réseau.
4. Vérifier que le dc de destination pointe vers des ser veurs DNS valides
Sur la dc de destination, vérifiez que les paramètres du client DNS pointent exclusivement vers les
serveur DNS actuellement en ligne qui hébergent, avancent et déléguent les _msdcs.<forest root
domain> (autrement dit, tous les DCS de la forêt contoso.com enregistrer des enregistrements CNAME
dans the_msdcs.contoso.com).
AND
Zone DNS pour le domaine Active Directory (autrement dit, un ordinateur du domaine contoso.com
enregistre les enregistrements d’hôte dans contoso.com zone).
AND
Le domaine de suffixe DNS principal des ordinateurs est différent du nom de domaine Active Directory
(voir l’article Technet Disjoint Namespace).
Les options pour valider qu’un serveur DNS héberge, les avants ou les délégués (autrement dit, « peut
résoudre ») ces zones sont les suivantes :
Démarrez l’outil de gestion DNS pour votre DNS et vérifiez les serveurs DNS vers lesquels le dc
source pointe pour héberger les zones en question pour la résolution de noms.
OR
Utilisez NSLOOKUP pour vérifier que tous les serveurs DNS pointant vers le dc source peuvent
résoudre les requêtes pour les zones DNS en question.
Exécutez IPCONFIG /ALL sur la console de destination DC :
c:\>ipconfig /all
…
Exécutez les requêtes NSLOOKUP suivantes à partir de la console de destination DC :
c:\>nslookup -type=soa <Source DC DNS domain name> <destinatin DCs primary DNS Server IP >
c:\>nslookup -type=soa < Source DC DNS domain name > <destination DCs secondary DNS Server IP
>
c:\>nslookup -type=soa _msdcs.<forest root DNS domain> <destination DCs primary DNS Server IP
>
c:\>nslookup -type=soa _msdcs.<forest root DNS name> <destination DCs secondary DNS Server
IP>
Par exemple, si un dc dans le domaine CHILD.CONTOSO.COM de la forêt contoso.com est configuré avec
les IPS du serveur DNS principal et secondaire « 10.45.42.102 » et « 10.45.42.103 », la syntaxe
NSLOOKUP serait

Remarques :
La requête SOA pour la zone _mscs.contoso.com est résolue correctement si le DNS ciblé dispose d’un
bon forwardeur ou délégation ou pour the_msdcs.<forest root zone> Elle ne sera pas résolue
correctement si the_msdcs.<forest root zone> sur le serveur DNS interrogé est un sous-domaine
<forest root zone> non délégué de la relation de zone créée par Windows 2000 domaines.
La configuration du client DNS d’un ordinateur dc ou membre pour qu’il pointe vers un serveur DNS
ISP pour la résolution de noms n’est pas valide. La seule exception est que le FS A été contracté (c’est-
à-dire, payé) et héberge actuellement, a transmis ou déléguer des requêtes DNS pour votre forêt
Active Directory.
En règle générale, les serveurs DNS isP n’acceptent pas les mises à jour DNS dynamiques, de sorte
que les enregistrements CNAME, Host et SRV doivent être enregistrés manuellement.
Le résolveur DNS sur les ordinateurs Windows est « résinant » par conception. Il utilise des serveurs
DNS qui répondent aux requêtes, que ces serveurs DNS hébergent, avancent ou déléguent les zones
requises. Restated, the DNS resolver won’t fail over and query another DNS server as long as the
active DNS is responsive, even if the response from the DNS Server is « I either don’t host the record
you’re looking for or even host a copy of the zone for that record ».
5. Vérifiez que le ser veur DNS utilisé par le dc de destination peut résoudre les
enregistrements DCs CNAME et HOST sources
À partir de la console de destination DC, ipconfig /all exécutez la commande pour déterminer les
serveurs DNS vers lesquels dc de destination pointe pour la résolution de noms :
DNS Servers that destination DC points to for name resolution:
c:\>ipconfig /all
…
À partir de la console de destination DC, NSLOOKUP utilisez pour interroger les serveurs DNS configurés
sur le dc de destination pour les enregistrements CNAME et d’hôte DCs sources :
c:\>nslookup -type=cname <fully qualified CNAME of source DC> <destination DCs primary DNS Server IP
>
c:\>nslookup -type=cname <fully qualified CNAME of source DC> <destination DCs secondary DNS Server
IP>
c:\>nslookup -type=host <fully qualified hostname of source DC> <destination DCs primary DNS Server
IP >
c:\>nslookup -type=host <fully qualified hostname of source DC> <destination DCs secondary DNS Server
IP>
Dans l’exemple, contoso-dc2 dans le domaine contoso.com avec guid 8a7baee5-cd81-4c8c-9c0f-

b10030574016 Contoso.com dans le domaine racine de la forêt pointe vers les serveurs DNS «
10.45.42.102 » et « 10.45.42.103 ». La syntaxe NSLOOKUP serait la suivante :

6. Examiner la relation entre les ser veurs DNS utilisés par les DCS source et de destination
Si les serveurs DNS utilisés par les copies des serveurs AD d’hôte source et de destination du _msdcs.
<forest root> et <primary DNS suffix> zones, recherchez :
Latence de réplication entre le DNS où l’enregistrement a été enregistré et le DNS dans lequel
l’enregistrement est interrogé.
Échec de réplication entre le DNS dans lequel l’enregistrement est enregistré et le DNS en cours
d’interrogation.
La zone DNS hébergeant l’enregistrement d’intérêt reste dans différentes étendues de réplication et
par conséquent dans un contenu différent, ou est en conflit/CNF sur un ou plusieurs DCS.
Si les zones DNS utilisées par le dc source et le dc de destination sont stockées dans des copies
principales et secondaires des zones DNS, recherchez :
La case à cocher « Autoriser les transferts de zone » n’est pas activée sur le DNS qui héberge la copie
principale de la zone.
La case à cocher « Seuls les serveurs suivants » est activée, mais l’adresse IP du DNS secondaire n’a
pas été ajoutée à la liste d’adresses ip sur le DNS principal.
La zone DNS sur le DNS Windows Server 2008 hébergeant la copie secondaire de la zone est vide en
raison de la KB953317.
Si les serveurs DNS utilisés par le dc source et le dc de destination ont des relations parent/enfant,
recherchez :
Délégations non valides sur le DNS qui possède la zone parente qui déléguer à la zone subordonnée.
Adresses IP de forwardeur non valides sur le serveur DNS qui tentent de résoudre la zone DNS
supérieure (exemple : un dc dans child.contoso.com essayant de résoudre les enregistrements d’hôte
dans la zone conto.com en restant sur les serveurs DNS dans le domaine racine).
Les informations du contrôleur de domaine enfant
orphelin ne sont pas répliquées sur d’autres
Cet article fournit une solution à un problème dans lequel un contrôleur de domaine enfant orphelin ne peut
pas être répliqué sur d’autres contrôleurs de domaine.
Symptômes
Un domaine enfant Microsoft Windows Server est orphelin du reste de la forêt. Ce domaine enfant peut recevoir
des modifications qui sont répliquées par des contrôleurs de domaine dans le domaine parent (racine), mais
aucun contrôleur de domaine dans le domaine racine ou tout autre domaine enfant n’a connaissance des
contrôleurs de domaine dans le domaine enfant concerné.
Lorsqu’un administrateur tente d’afficher les contrôleurs de domaine dans le domaine enfant orphelin à partir
d’un autre domaine, aucun contrôleur de domaine n’est affiché. Par exemple, aucun contrôleur de domaine n’est
affiché dans le contexte d’attribution de noms de configuration suivant :
CN=Servers,CN= Site_Name ,CN=Sites,CN=Configuration,DC= Domain_Name ,DC=com
Dans ce cas, Site_Name et Domain_Name sont des attributs du domaine orphelin.
Cause
Ce problème peut se produire si le domaine enfant est orphelin du domaine parent.
Résolution
IMPORTANT
Pour résoudre ce problème, vous devez créer un lien de réplication, puis activer l’authentification à sens seul au
lieu de l’authentification double. Pour cela, procédez comme suit :
1. Sur un contrôleur de domaine dans le domaine racine, ajoutez la valeur de Registre de réplicateur
autoriser le réplicateur à répliquer. Pour ce faire, suivez ces étapes sur le contrôleur de domaine.
a. Sélectionnez > Démarrer l’exécuter, puis entrez regedt32 .
b. Sélectionnez la sous-clé de Registre suivante :
c. Sélectionnez > Modifier la nouvelle valeur > DWORD.
d. Entrez Le réplicateur autorise le réplicateur de récupération SPN.
e. Dans le volet droit, double-cliquez sur Replicator Allow SPN Fallback , tapez 1 dans la zone de
données Valeur, puis sélectionnez OK .
f. Redémarrez le contrôleur de domaine.
2. Ouvrez une fenêtre d’invite de commandes et exécutez les commandes suivantes :
repadmin /options fully_qualified_domain_name_(FQDN)_of_the_root_domain_controller

+DISABLE_NTDSCONN_XLATE
repadmin /add CN=Configuration,DC=Domain_Name,DC=Domain_Name FQDN_of_the_root_domain_controller
FQDN_of_the_child_domain_controller
repadmin /showreps
Une connexion entrante réussie doit être affichée pour le contexte d’attribution de noms de configuration
à partir du contrôleur de domaine enfant.
NOTE
Pour plus d’informations sur lRepadmin.exe, voir Monitoring and Troubleshooting Active Directory Replication
Using Repadmin.
3. À l’invite de commandes, exécutez la commande :

repadmin /options FQDN_of_the_root_domain_controller -DISABLE_NTDSCONN_XLATE .
4. Supprimez l’entrée de Registre de réplicateur autoriser le SPN de base. Pour cela, procédez comme suit :
a. Démarrez l’Éditeur du Registre, puis sélectionnez la sous-clé de Registre suivante :
b. Cliquez avec le bouton droit sur Réplicateur autoriser le repli SPN, sélectionnez
Supprimer, puis sélectionnez OK.
5. Forcer la réplication entre tous les contrôleurs de domaine dans le domaine racine. Pour cela, procédez
comme suit :
a. Sur un contrôleur de domaine dans le domaine racine, sélectionnez Démarrer les programmes >
> d’administration Outils > d’administration Sites et ser vices Active Director y.
b. Développez > Sites Ser vers, développez Ser ver_Name dossier, puis sélectionnez NTDS
Paramètres .
c. S’il existe d’autres contrôleurs de domaine dans votre environnement à répliquer, ils sont
répertoriés dans le volet droit. Cliquez avec le bouton droit sur le premier contrôleur de domaine
dans la liste, sélectionnez Toutes les tâches, puis sélectionnez Vérifier la topologie de réplication
pour démarrer le contrôle de cohérence des connaissances (KCC).
Un objet de connexion entrant provenant d’un ou plusieurs des contrôleurs de domaine enfants
s’affiche. Vous de devez peut-être mettre à jour l’affichage en appuyant sur F5.
d. Répétez l’étape 3 pour chaque contrôleur de domaine dans le domaine racine.
6. Autoriser la réplication à se produire dans toute la forêt. Ensuite, exécutez la commande sur le contrôleur
de repadmin /showreps domaine racine et sur les contrôleurs de domaine enfants. Cette étape permet de
s’assurer que la réplication du service d’annuaire Active Directory (AD DS) réussit.
L’entrée de Registre de réplication autoriser le SPN de base permet au contrôleur de domaine d’utiliser
l’authentification à sens seul si l’authentification double ne peut pas être effectuée en raison d’un échec de la
résolution d’un nom principal de service (SPN) en compte d’ordinateur.
Erreur de réplication Active Directory 1722 : le
serveur RPC n’est pas disponible
Cet article permet de corriger l’erreur 1722 de la réplication Active Directory.

Symptômes
Cet article décrit les symptômes, la cause et la résolution de l’échec de la réplication Active Directory avec
l’erreur Win32 1722 : le serveur RPC n’est pas disponible.
1. DcPROMO Promotion of a replica DC fails to create an NTDS Paramètres object on the helper DC with
error 1722
Texte du titre de la boîte de dialogue : Assistant Installation des services de domaine Active Directory
The operation failed because: Active Directory Domain Services could not create the NTDS Settings
object for this Active Directory Domain Controller CN=NTDS Settings,CN=<Name of DC being
promoted),CN=Servers,CN=<site name>,CN=Sites,CN=Configuration,DC=<forest root domain> on the remote
AD DC <helper DC>.<domain name>.<top level domain>. Ensure the provided network credentials have
sufficient permissions. "The RPC server is unavailable."
2. DCDIAG signale que le test réplications Active Directory a échoué avec l’erreur 1722 : le serveur RPC n’est
pas disponible.
[Replications Check,<DC Name>] A recent replication attempt failed:

From <source DC> to <destination DC>
Naming Context: <DN path of directory partition>
The RPC server is unavailable.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
<X> failures have occurred since the last success.
[<dc name>] DsBindWithSpnEx() failed with error 1722,
The RPC server is unavailable..
Printing RPC Extended Error Info:
<snip>
3. REPADMIN.EXE signale que la tentative de réplication a échoué avec l’état 1722 (0x6ba).
Les commandes REPADMIN qui mentionnent généralement l’état -1722 (0x6ba) incluent, sans s’y limiter,
les suivantes :
REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL
Un exemple de sortie REPADMIN /SHOWREPS à partir REPADMIN /SYNCALL du ser veur RPC indisponible et
de la représentation de celui-ci est illustré ci-dessous :
c:\> repadmin /showreps

<site name><destination DC>
DC Options: <list of flags>
DC object GUID: <NTDS settings object object GUID>
DC invocationID: <invocation ID string>
==== INBOUND NEIGHBORS ======================================
DC=<DN path for directory partition>
<site name><source DC via RPC
DC object GUID: <source DCs ntds settings object object guid>
Last attempt @ <date> <time> failed, result **1722 (0x6ba):
<X #> consecutive failure(s).
Last success @ <date> <time>
Un exemple de sortie illustrant REPADMIN /SYNCALL l’erreur d’indisponibilité du serveur RPC est illustré
ci-dessous :
C:\>repadmin /syncall
CALLBACK MESSAGE: Error contacting server \<object guid of NTDS Settings object>._msdcs.\<forest
root domain>.\<top level domain> (network error): 1722 (0x6ba):
4. La commande Répliquer maintenant dans sites et services Active Directory renvoie le ser veur RPC
indisponible .
Le fait de cliquer avec le bouton droit sur l’objet de connexion à partir d’un dc source et de choisir la
réplication échoue maintenant avec le serveur RPC indisponible . Le message d’erreur à l’écran s’affiche
ci-dessous :
L’erreur suivante s’est produite lors de la tentative <DNS name of directory partition> <source Dc
host name> <destination DC hostname>de synchronisation du contexte d’attribution de noms du
contrôleur de domaine au contrôleur de domaine : le serveur RPC n’est pas disponible. Cette
opération ne se poursuit pas. Cette condition peut être causée par un problème de recherche DNS.
Pour plus d’informations sur la résolution des problèmes de recherche DNS courants, voir le site Web
Microsoft suivant : Problème de recherche DNS
5. Les événements NTDS Knowledge Consistency Checker (KCC), NTDS General ou Microsoft-Windows-
ActiveDirectory_DomainService avec l’état 1722 sont enregistrés dans le journal des événements du
Microsoft-Windows- 1125 L’Assistant Installation des services

ActiveDirectory_DomainService de domaine Active Directory
(Dcpromo) n’a pas pu établir de
connexion avec le contrôleur de
domaine suivant.
NTDS KCC 1311 Le contrôle de cohérence des

connaissances (KCC) a détecté des
problèmes avec la partition
d’annuaire suivante.
NTDS KCC 1865 Le contrôle de cohérence des

connaissances (KCC) n’a pas pu
former une topologie de réseau
d’arborescence complète. Par
conséquent, la liste de sites suivante
n’est pas accessible à partir du site
local.

Réplication NTDS 1960 Événement interne : le contrôleur de

domaine suivant a reçu une
exception d’une connexion d’appel
de procédure distante (RPC).
L’opération a peut-être échoué.
Cause
RPC est une couche intermédiaire entre le transport réseau et le protocole d’application. RPC lui-même n’a pas
d’informations particulières sur les défaillances, mais tente de masquer les échecs de protocole de couche
inférieure dans une erreur au niveau de la couche RPC.
L’erreur RPC 1722 / 0x6ba /RPC_S_SERVER_UNAVAILABLE est enregistrée lorsqu’un protocole de couche
inférieure signale une défaillance de connectivité. Le cas courant est que l’opération abstraite TCP CONNECT a
échoué. Dans le contexte de la réplication AD, le client RPC sur le dc de destination n’a pas pu se connecter
correctement au serveur RPC sur la dc source. Causes courantes :
1. Liaison d’une défaillance locale
2. Échec DHCP
3. Échec DNS
4. Échec WINS
5. Échec du routage (y compris les ports bloqués sur les pare-feu)
6. Échecs d’authentification IPSec/Réseau
7. Limitations de ressources
8. Protocole de couche supérieure non en cours d’exécution
9. Le protocole de couche supérieure retourne cette erreur
Résolution
Étapes de dépannage de base pour identifier le problème.
Vérifier que la valeur de démarrage et l’état du service sont corrects pour RPC, RPC Locator et le Centre de
distribution de clés Kerberos
Vérifiez que la valeur de démarrage et l’état du service sont corrects pour l’appel de procédure distante (RPC), le
localisateur d’appel de procédure distante (RPC) et le centre de distribution de clés Kerberos.
La version du système d’exploitation détermine les valeurs correctes pour le système source et de destination
qui journalisation l’erreur de réplication. Utilisez le tableau suivant pour valider les paramètres.
N O M DU SERVIC E W IN DO W S 2000 W IN DO W S 2003 / R2 W IN DO W S 2008 W IN DO W S 2008 R2
Appel de procédure Démarré/Automatiqu Démarré/Automatiqu Démarré/Automatiqu Démarré/Automatiqu

distante (RPC) e e e e
Localisateur d’appel Démarré/ Non démarré/ Non démarré/ Non démarré/

de procédure Automatique Manuel Manuel Manuel
distante (RPC) (contrôleurs de
domaine)
Non démarré/
Manuel(Serveurs
membres)
Centre de Démarré/ Démarré/ Démarré/ Démarré/

distribution de clés Automatique Automatique Automatique Automatique
Kerberos (KDC) (contrôleurs de (contrôleurs de (contrôleurs de (contrôleurs de
domaine) domaine) domaine) domaine)
Non Non Non Non

démarré/désactivé(se démarré/désactivé(se démarré/désactivé(se démarré/désactivé(se
rveurs membres) rveurs membres) rveurs membres) rveurs membres)
Si vous a apporté des modifications pour correspondre aux paramètres ci-dessus, redémarrez l’ordinateur.
Vérifiez que la valeur de démarrage et l’état du service correspondent aux valeurs documentées dans le tableau
ci-dessus.
Vérifiez que la clé ClientProtocols existe sous HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc, et qu’elle
contient les protocoles par défaut corrects
N O M DU P ROTO C O L E TYPE VA L EUR DE DO N N ÉES
ncacn_http REG_SZ rpcrt4.dll
Si la clé ClientProtocols ou l’une des quatre valeurs par défaut est manquante, importez la clé à partir d’un
serveur connu.
Vérifier que le DNS fonctionne
Les échecs de recherche DNS sont la cause d’un grand nombre d’erreurs RPC 1722 en matière de réplication.
Il existe quelques outils à utiliser pour vous aider à identifier les erreurs DNS :
DCDIAG /TEST:DNS /V /E /F:<filename.log>
DCDIAG /TEST:DNS La commande peut valider l’état DNS des contrôleurs de domaine Windows 2000
Server (SP3 ou ultérieur), Windows Server 2003 et Windows Server 2008. Ce test a été introduit pour la
première fois avec Windows Server 2003 Service Pack 1.
Il existe sept groupes de test pour cette commande.
Authentification (authentification)
De base ( Basc )
Enregistrement des enregistrements (RReg)
Mise à jour dynamique ( Dyn )
Delegations (Del)
Forwarders/Root hints (Forw)
Exemple de sortie :
TEST: Authentication (Auth)

Authentication test: Successfully completed
TEST: Basic (Basc)

Microsoft(R) Windows(R) Server 2003, Enterprise Edition (Service Pack level: 2.0) is supported
NETLOGON service is running
kdc service is running
DNSCACHE service is running
DNS service is running
DC is a DNS server
Network adapters information:
Adapter [00000009] Microsoft Virtual Machine Bus Network Adapter:
MAC address is 00:15:5D:40:CF:92
IP address is static
IP address: <IP Address>
DNS servers:
<DNS IP Address> (DC.domain.com.) [Valid]
The A record for this DC was found
The SOA record for the Active Directory zone was found
The Active Directory zone on this DC/DNS server was found (primary)
Root zone on this DC/DNS server was not found
<omitted other tests for readability>
Résumé des résultats des tests DNS :
Auth Basc Forw Del Dyn RReg Ext
Domain: fragale.contoso.com
DC1 PASS PASS FAIL PASS PASS PASS n/a
Domain: child.fragale.contoso.com
DC2 PASS PASS n/a n/a n/a PASS n/a
Enterprise DNS infrastructure test results:

For parent domain domain.com and subordinate domain child:
Forwarders or root hints are not misconfigured from parent domain to subordinate domain
Error: Forwarders are configured from subordinate to parent domain but some of them failed DNS
server tests
(See DNS servers section for error details)

Delegation is configured properly from parent to subordinate domain
......................... domain.com failed test DNS
Le résumé fournit des étapes de correction pour les échecs les plus courants de ce test.
Vous pouvez trouver des explications et des options supplémentaires pour ce test à l’outil de
diagnostic du contrôleur de domaine (dcdiag.exe).
NLTEST /DSGETDC:<netbios or DNS domain name>
Nltest /dsgetdc est utilisé pour exercer le processus de localisation de dc. Tente /dsgetdc:<domain name>
donc de trouver le contrôleur de domaine pour le domaine. L’utilisation de l’indicateur de force force
l’emplacement du contrôleur de domaine au lieu d’utiliser le cache. Vous pouvez également spécifier des
options telles que /gc ou /pdc pour localiser un catalogue global ou un émulateur de contrôleur de
domaine principal. Pour trouver le catalogue global, vous devez spécifier un nom d’arborescence , qui est
le nom de domaine DNS du domaine racine.
Exemple de sortie :
DC: [\DC.fabrikam.com]
Address: \\<IP Address>
Dom Guid: 5499c0e6-2d33-429d-aab3-f45f6a06922b
Dom Name: fabrikam.com
Forest Name: fabrikam.com
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE
The command completed successfully
Netdiag -v
Peut être utilisé avec Windows 2003 et les versions antérieures pour collecter des informations
spécifiques pour la configuration et l’erreur réseau. L’exécution de cet outil prend un certain temps lors de
l’exécution du -v commutateur.
Exemple de sortie pour le test DNS :
DNS test . . . . . . . . . . . . . : Passed

Interface {34FDC272-55DC-4103-B4B7-89234BC30C4A}
DNS Domain:
DNS Servers: <DNS Server Ip address>
IP Address: Expected registration with PDN (primary DNS domain name):
Hostname: DC.fabrikam.com.
Authoritative zone: fabrikam.com.
Primary DNS server: DC.fabrikam.com <Ip Address>
Authoritative NS:<Ip Address>
Check the DNS registration for DCs entries on DNS server <DNS Server Ip address>
The Record is correct on DNS server '<DNS Server Ip address>'.
(You will see this line repeated several times for every entry for this DC. Including srv records.)
The Record is correct on DNS server '<DNS Server Ip address>'.
PASS - All the DNS entries for DC are registered on DNS server '<DNS Server Ip address>'.
ping -a <IP_of_problem_server>
Il s’agit d’un simple test rapide pour valider que l’enregistrement hôte d’un contrôleur de domaine est
résolu sur l’ordinateur correct.
dnslint /s IP /ad IP
DNSLint est un utilitaire Windows qui vous aide à diagnostiquer les problèmes courants de résolution
des noms DNS. La sortie est un fichier htm avec beaucoup d’informations, notamment :
Ser veur DNS : localhost
IP Address: 127.0.0.1
UDP port 53 responding to queries: YES
TCP port 53 responding to queries: Not tested
Answering authoritatively for domain: NO
SoA enregistre les données du ser veur :
Authoritative name server: DC.domain.com

Hostmaster: hostmaster
Zone serial number: 14
Zone expires in: 1.00 day(s)
Refresh period: 900 seconds
Retry delay: 600 seconds
Default (minimum) TTL: 3600 seconds
Enregistrements de référence (NS) supplémentaires à partir du serveur : DC2.fabrikam.com <IP Address>
Enregistrements d’alias (CNAME) et de collage (A) pour les GUID de forêt à par tir du ser veur
:
CNAME : 98d4aa0c-d8e2-499a-8f90-9730b0440d9b._msdcs.fabrikam.com
Alias : DC.fabrikam.com
Collage : <IP Adress>
CNAME : a2c5007f-7082-4adb-ba7d-a9c47db1efc3._msdcs.fabrikam.com
Alias : dc2.child.fabrikam.com
Collage : <IP Address>
Pour plus d’informations, voir Description de l’utilitaire DNSLint.
Vérifier que les ports réseau ne sont pas bloqués par un pare -feu ou une application tierce à l’écoute sur les
ports requis
Le mappeur de point de terminaison (à l’écoute sur le port 135) indique au client sur quel port affecté de
manière aléatoire un service (FRS, réplication AD, MAPI, etc.) est à l’écoute.
P ROTO C O L E D’A P P L IC AT IO N P ROTO C O L E P O RT S
Serveur de catalogue global TCP 3269
Serveur de catalogue global TCP 3268
Serveur LDAP TCP 389
Serveur LDAP UDP 389
LDAP SSL TCP 636
LDAP SSL UDP 636
IPsec ISAKMP UDP 500
NAT-T UDP 4500
RPC TCP 135
PORTS TCP élevés alloués de manière TCP 1024 - 5000

aléatoire RPC¹ 49152 - 65535*
* Il s’agit de la plage Windows Server 2008, Windows Vista, Windows 7 et Windows 2008 R2.
Portqry peut être utilisé pour identifier si un port est bloqué à partir d’un dc lors du ciblage d’un autre DC. Il
peut être téléchargé à l’analyseur de port de ligne de commande PortQry version 2.0.
Exemple de syntaxe :
portqry -n <problem_server> -e 135
portqry -n <problem_server> -r 1024-5000
Une version graphique de portqry, appelée Portqryui, se trouve dans PortQryUI - Interface utilisateur de
l’analyseur de port de ligne de commande PortQry.
Si les ports de la plage de ports dynamiques sont bloqués, utilisez les liens ci-dessous pour configurer une
plage de ports gérable pour le client.
Liens importants supplémentaires pour la configuration et l’travail avec les pare-feu et les contrôleurs de
domaine :
HOWTO : Configurer l’allocation de port dynamique RPC pour qu’elle fonctionne avec le pare-feu
Restriction du trafic de réplication Active Directory à un port spécifique
Comment configurer un pare-feu pour les domaines et les trusts
Liste des ports par défaut du contrôleur Windows server
Ports requis pour le système Microsoft Windows Server
Pilotes de la NIC non bon
Consultez les fournisseurs de cartes réseau ou les fabricants OEM pour les pilotes les plus récents.
La fragmentation UDP peut provoquer des erreurs de réplication qui semblent avoir une source de serveur
RPC indisponible
Les erreurs d’ID d’événement 40960 & 40961 avec une source de LSASRV sont courantes pour cette cause
particulière.
Pour plus d’informations, voir Comment forcer Kerberos à utiliser TCP au lieu d’UDP dans Windows.
Différences de signature SMB entre les DCS
L’utilisation de la stratégie des contrôleurs de domaine par défaut pour configurer des paramètres cohérents
pour la signature SMB dans la section suivante permet de résoudre cette cause :
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Client réseau Microsoft : communications avec signature numérique (toujours) désactivées.

Client réseau Microsoft : communications avec signature numérique (si le serveur l’accepte) Activées.
Serveur réseau Microsoft : communications avec signature numérique (toujours) désactivées.
Serveur réseau Microsoft : communications avec signature numérique (si le client l’accepte) Activées.
Les paramètres se trouvent sous les clés de Registre suivantes :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters et
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters
RequireSecuritySignature = toujours (0,disable, 1 enable).

EnableSecuritySignature = est que le serveur accepte (0,disable, 1 enable).
Résolution des problèmes supplémentaires :
Si les informations ci-dessus ne fournissent pas de solution pour la 1722, utilisez la journalisation des
diagnostics suivante pour recueillir plus d’informations :
Windows Server 2003 SP2 computers logs extended RPC Server info in NTDS Replication events 1960, 1961, 1962
and 1963.
Crank up NTDS Diagnostic logging
1 = basic, 2 and 3 add continually verbose info and 5 logs extended info.
References
Valeurs de retour RPC
Understanding Extended Error Information
Emplacements de détection des informations d’erreur étendues
Activation des informations sur l’erreur étendue
Connectivité réseau
Erreur de réplication Active Directory - 2146893022 :
le nom de principal cible est incorrect
Cet article explique comment résoudre un problème dans lequel la réplication Active Directory échoue et génère
une erreur (-2146893022 : le nom principal cible est incorrect).
NOTE
Résumé
Cette erreur se produit lorsque le contrôleur de domaine source ne déchiffre pas le ticket de service fourni par le
contrôleur de domaine de destination (cible).
Cause principale
Le contrôleur de domaine de destination reçoit un ticket de service à partir d’un centre de distribution de clés
Kerberos (KDC). Et le KDC dispose d’une ancienne version du mot de passe pour le contrôleur de domaine
source.
Résolution supérieure
1. Arrêtez le service KDC sur le contrôleur de domaine de destination. Pour ce faire, exécutez la commande
suivante à une invite de commandes :
net stop KDC
2. Démarrez la réplication sur le contrôleur de domaine de destination à partir du contrôleur de domaine

source. Utiliser les sites et services AD ou Repadmin .
Utilisation de repadmin :
Repadmin /replicate destinationDC sourceDC DN_of_Domain_NC
Par exemple, si la réplication échoue ContosoDC2.contoso.com , exécutez la commande suivante sur

ContosoDC1.contoso.com :
Repadmin /replicate ContosoDC2.contoso.com ContosoDC1.contoso.com "DC=contoso,DC=com"
3. Démarrez le service KDC Kerberos sur le contrôleur de domaine de destination en exécutant la

commande suivante :
net start KDC
Si le problème n’est pas résolu, consultez la section Résolution pour obtenir une solution netdom resetpwd
alternative dans laquelle vous utilisez la commande pour réinitialiser le mot de passe du compte d’ordinateur du
contrôleur de domaine source. Si ces étapes ne résolvent pas le problème, examinez le reste de cet article.
Symptômes
Lorsque ce problème se produit, vous présentez un ou plusieurs des symptômes suivants :
DCDIAG signale que le test de réplications Active Directory a échoué et a renvoyé l’erreur -2146893022 :
le nom de principal cible est incorrect.

Contexte d’attribution de noms : <DN path of directory partition>
La réplication a généré une erreur (-2146893022) :
Le nom de principal cible est incorrect.
<X> des échecs se sont produits depuis le dernier succès.
Repadmin.exe signale qu’une tentative de réplication a échoué et signale l’état -2146893022

(0x80090322).
Repadmin les commandes qui indiquent généralement l’état -2146893022 (0x80090322) incluent,
sans s’y limiter, les suivantes :
DMIN /REPLSUMREPA
REPADMIN /SHOWREPL
REPADMIN /SHOWREPL
REPADMIN /SYNCALL
Voici un exemple de REPADMIN /SHOWREPS sortie à partir REPADMIN /SYNCALL de l’erreur qui indique
que le nom de principal cible est incorrect :
c:\> repadmin /showreps
<site name>\<destination DC>
DC Options: IS_GC
DC object GUID: <NTDS settings object object GUID>
DChttp://bemis/13/Pages/2090913_en-US.aspx invocationID: <invocation ID string>
DC=<DN path for directory partition>

<site name>\<source DC via RPC
DC object GUID: <source DCs ntds settings object object guid>
Last attempt @ <date> <time> failed, result -2146893022 (0x80090322):
The target principal name is incorrect.
<X #> consecutive failure(s).
Last success @ <date> <time>.
c:\> repadmin /syncall /Ade

Syncing all NC's held on localhost.
Syncing partition: DC=<Directory DN path>
CALLBACK MESSAGE: Error contacting server CN=NTDS Settings,CN=<server name>,CN=Servers,CN=
<site name>,CN=Sites,CN=Configuration,DC=<forest root domain> (network error): -2146893022
(0x80090322):
La commande Répliquer maintenant dans sites et services Active Directory renvoie le message
Le nom de principal cible est incorrect
Le fait de cliquer avec le bouton droit sur l’objet de connexion à partir d’un dc source, puis de sélectionner
répliquer, échoue maintenant. Le message d’erreur à l’écran est le suivant :

Texte du message de la boîte de dialogue : l’erreur suivante s’est produite lors de la tentative de
contact du contrôleur de domaine <source DC name>:
Le nom de principal cible est incorrect
Les événements NTDS Knowledge Consistency Checker (KCC), NTDS General ou Microsoft-Windows-
ActiveDirector y_DomainSer vice qui ont l’état -2146893022 sont consignés dans le journal des
événements du service d’annuaire.
Les événements Active Directory qui mentionnent généralement l’état -2146893022 incluent, sans s’y
limiter, les événements suivants :

Réplication NTDS 1586 La Windows point de contrôle de

réplication NT 4.0 ou antérieure
avec le maître de l’émulateur PDC a
échoué.
Une synchronisation complète de la

base de données du Gestionnaire de
comptes de sécurité (SAM) avec les
contrôleurs de domaine exécutant
Windows NT 4.0 et les version
antérieures peut avoir lieu si le rôle
maître de l’émulateur PDC est
transféré au contrôleur de domaine
local avant le prochain point de
contrôle réussi.


connaissances (KCC) a détecté que
échoué.
Microsoft-Windows- 1926 Échec de la tentative

ActiveDirectory_DomainService d’établissement d’un lien de
Messagerie inters site NTDS 1373 Le service de messagerie intersite

n’a pas pu recevoir de messages
pour le service suivant via le
transport suivant. Échec de la
requête pour les messages.
Cause
Le code d'2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL-ce n’est pas une erreur Active
Directory. Il peut être renvoyé par les composants de couche inférieure suivants pour différentes causes racines :
RPC
Kerberos
SSL
LSA
NTLM
Les erreurs Kerberos qui sont mappées par Windows code à -2146893022 \ 0x80090322 \
SEC_E_WRONG_PRINCIPAL sont les suivantes :
KRB_AP_ERR_MODIFIED (0x29 / 41 décimal / KRB_APP_ERR_MODIFIED )
KRB_AP_ERR_BADMATCH (0x24h36 / décimal / « Ticket et authentifié ne correspondent pas » )
KRB_AP_ERR_NOT_US (décimale / 0x23h35 / « Le ticket n’est pas pour nous » )
Voici quelques causes racines spécifiques de -2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL :
Un mappage nom-IP non bon dans un fichier DNS, WINS, HOST ou LMHOST. Cela a provoqué la
connexion du contrôleur de domaine de destination au contrôleur de domaine source erroné dans un
autre domaine Kerberos.
Le KDC et le contrôleur de domaine source ont différentes versions du mot de passe du compte
d’ordinateur du contrôleur de domaine source. L’ordinateur cible Kerberos (contrôleur de domaine
source) n’a donc pas pu déchiffrer les données d’authentification Kerberos envoyées par le client
Kerberos (contrôleur de domaine de destination).
Le KDC n’a pas pu trouver de domaine pour rechercher le nom principal de domaine du contrôleur de
domaine source.
Les données d’authentification dans les cadres chiffrés Kerberos ont été modifiées par le matériel (y
compris les périphériques réseau), les logiciels ou un attaquant.
Résolution
Exécuter dcdiag /test:checksecurityerror sur le dc source
Les SNS peuvent être manquants, non valides ou dupliqués en raison d’une latence de réplication simple,
en particulier suite à des échecs de promotion ou de réplication.
Les noms de service dupliqués peuvent entraîner un nom de service de mappage des noms de noms non
bon.
DCDIAG /TEST:CheckSecurityError peut vérifier les SNS manquants ou dupliqués et d’autres erreurs.
Exécutez cette commande sur la console de tous les contrôleurs de domaine source qui échouent à la
réplication sortante avec SEC_E_WRONG_PRINCIPAL erreur.
Vous pouvez vérifier l’inscription du SPN par rapport à un emplacement spécifique à l’aide de la syntaxe
suivante :
dcdiag /test:checksecurityerror replsource:<remote dc>
Vérifier que le trafic réseau chiffré Kerberos a atteint la cible Kerberos prévue (mappage de nom à IP)
Les contrôleurs de domaine de destination De réplication Active Directory entrants recherchent
dans leur copie locale du répertoire l’objectGUID des contrôleurs de domaine source NTDS
Paramètres objets.
Les contrôleurs de domaine interrogent le serveur DNS actif pour obtenir un enregistrement
CNAME DC GUIDED correspondant. Ensuite, il est mappé à un enregistrement A/AAAA hôte qui
contient l’adresse IP du contrôleur de domaine source.
Dans ce scénario, Active Directory exécute un service de récupération de résolution de noms. Il
inclut des requêtes pour des noms d’ordinateurs complets dans DNS ou des noms d’hôtes à
étiquette unique dans WINS.
NOTE
Les serveurs DNS peuvent également effectuer des recherche WINS dans des scénarios de récupération.
Les situations suivantes peuvent toutes provoquer l’soumission par un contrôleur de domaine de destination du
trafic chiffré Kerberos à la cible Kerberos erronée :
Objets de Paramètres NTDS obsolètes
Mappages nom-IP non bon dans les enregistrements d’hôte DNS et WINS
Entrées obsolètes dans les fichiers HOST
Pour vérifier cette condition, vous pouvez soit suivre le réseau, soit vérifier manuellement que les requêtes de
nom DNS/NetBIOS sont résolues sur l’ordinateur cible prévu.
Méthode 1 : méthode de suivi réseau (telle qu’elle est expliquée par le moniteur réseau 3.3.1641 en 2013, avec
l’option d’utilisateurs complets activés par défaut)
Le tableau suivant présente un résumé du trafic réseau qui se produit lorsque la destination DC1 entrante
réplique l’annuaire Active Directory à partir de la source DC2.
F# SRC DEST P ROTO C O L E C A DRE C O M M EN TA IRE
1 DC1 DC2 MSRPC MSRPC:c/o Appel RPC Dest

Request: DC vers EPM sur
unknown dc source sur
Call=0x5 135
Opnum=0x3
Context=0x1
Hint=0x90
2 DC2 DC1 MSRPC Réponse Réponse EPM à

MSRPC:c/o : l’appelant RPC
Appel=0x5
Context=0x1
Hint=0xF4
Cancels=0x0
3 DC1 DC2 MSRPC MSRPC:c/o Bind: Demande de

UUID{E3514235 liaison RPC à
-4B06-11D1- E351... service
AB04- UUID
00C04FC2DCD2}
DRSR(DRSR)
Call=0x2 Assoc
Grp=0x0
Xmit=0x16D0
Recv=0x16D0
4 DC2 DC1 MSRPC MSRPC:c/o Bind Réponse de

Ack: Call=0x2 liaison RPC
Assoc
Grp=0x9E62
Xmit=0x16D0
Recv=0x16D0
F# SRC DEST P ROTO C O L E C A DRE C O M M EN TA IRE
5 DC1 KDC KerberosV5 Domaine de Demande TGS

demande pour le SPN de
KerberosV5:TGS réplication de dc
CONTOSO.COM source. Cette
Sname : opération
E3514235- n’apparaît pas
4B06-11D1- sur le réseau de
AB04- destination DC
00C04FC2DCD2 utilise lui-même
/6f3f96d3-dfbf- comme KDC.
4daf-9236-
4d6da6909dd2/c
ontoso.com
6 KDC DC1 KerberosV5 KerberosV5:TGS Réponse TGS à

Response destination DC
Cname: contoso-dc1.
CONTOSO-DC1$ Cette opération
n’apparaît pas
sur le réseau de
destination DC
utilise lui-même
comme KDC.
7 DC1 DC2 MSRPC MSRPC:c/o Demande AP

Alter Cont:
UUID{E3514235-
4B06-11D1-
AB04-
00C04FC2DCD2}
DRSR(DRSR)
Call=0x2
8 DC2 DC1 MSRPC MSRPC:c/o Réponse AP.

Alter Cont
Resp:
Call=0x2
Assoc
Grp=0x9E62
Xmit=0x16D0
Recv=0x16D0
DRIL L DO W N SUR F RA M E 7 DRIL L DO W N SUR F RA M E 8 C O M M EN TA IRES
MSRPC MSRPC:c/o Alter Cont: MSRPC:c/o Alter Cont Resp: DC1 se connecte au service de
UUID{E3514235-4B06-11D1-AB04- Call=0x2 Assoc Grp=0xC3EA43 réplication AD sur DC2 sur le port
00C04FC2DCD2} DRSR(DRSR) Xmit=0x16D0 Recv=0x16D0
Call=0x2 renvoyé par le EPM sur DC2.
Ipv4 : Src = x.x.x.245, Dest = x.x.x.35, Ipv4 : Src = x.x.x.35, Dest = x.x.x.245, Vérifiez que la source de réplication AD
Next Protocol = TCP, Packet ID =, Total Next Protocol = TCP, Packet ID = DC ( Dest appelée ordinateur dans la
IP Length = 0 31546, Longueur IP totale = 278 première colonne et l’ordinateur Src
dans la colonne 2 possède l’adresse
IP mentionnée dans le suivi). C’est
dans x.x.x.35 cet exemple.
DRIL L DO W N SUR F RA M E 7 DRIL L DO W N SUR F RA M E 8 C O M M EN TA IRES
Ticket : Realm: CONTOSO.COM , : ErrorCode: KRB_AP_ERR_MODIFIED Dans la colonne 1, notez le domaine

Sname E3514235-4B06-11D1-AB04- (41) du domaine Kerberos contoso.com
00C04FC2DCD2/6f3f96d3-dfbf-4daf- cible suivi du SPN de réplication des
9236-4d6da6909dd2/contoso.com Domaine : <verify that realm returned contrôleurs de domaine source (
by the source DC matches the Sname ) qui se compose du service de
Kerberos realm intended by the réplication Active Directory UUID
destination DC>. (E351...) concaté avec le GUID d’objet
de l’objet NTDS Paramètres des
Sname : <verify that the sName in contrôleurs de domaine source.
the AP response matches contains the
hostname of the intended source DC Valeur GUIDED 6f3f96d3-dfbf-4daf-
and NOT another DC that the 9236-4d6da6909dd2 à droite de
destination incorrectly resolved to due l’E351... L’UUID du service de
to a bad name-to-ip mapping réplication est le GUID d’objet pour
problem>. l’objet de paramètres NTDS des
contrôleurs de domaine source. Il est
actuellement défini dans la copie des
contrôleurs de domaine de destination
d’Active Directory. Vérifiez que ce GUID
d’objet correspond à la valeur du
champ GUID repadmin /showreps
d’objet DSA lorsqu’il est exécuté à
partir de la console de la source DC.
Un ping ou des nslookup

contrôleurs de domaine source
with_msdcs.<forest root DNS name> à
partir de la console de destination DC
doit renvoyer l’adresse IP actuelle des
contrôleurs de domaine source :
ping 6f3f96d3-dfbf-4daf-9236-
4d6da6909dd2._msdcs.contoso.com
nslookup -type=cname 6f3f96d3-

dfbf-4daf-9236-
4d6da6909dd2._msdcs.<forest root
domain> <DNS Server IP>
Dans la réponse indiquée dans la

colonne 2, concentrez-vous Sname
sur le champ et vérifiez qu’il contient le
nom d’hôte de la source de réplication
AD DC.
Des mappages nom-IP non valides

peuvent entraîner la connexion de la
dc de destination à un dc dans un
domaine cible non valide, ce qui peut
entraîner la non-invalidation de la
valeur Realm, comme illustré dans le
cas présent. Les mappages hôte-IP
non bon peuvent entraîner la
connexion de DC1 à DC3 dans le
même domaine. Il générerait toujours
KRB_AP_ERR_MODIFIED , mais le
nom de domaine dans le cadre 8
correspondrait au domaine dans le
cadre 7.
Méthode 2 : vérification du mappage nom-ADRESSE IP (sans utilisation d’un suivi réseau)

À partir de la console du contrôleur de domaine source :
C O M M A N DE C O M M EN TA IRE
IPCONFIG /ALL |MORE Remarque sur l’adresse IP de la NIC utilisée par les
contrôleurs de domaine de destination
REPADMIN /SHOWREPS |MORE Valeur de note du GUID de l’objet DSA. Il indique le GUID
d’objet pour les contrôleurs de domaine source NTDS
Paramètres Object dans la copie des contrôleurs de domaine
source d’Active Directory.
À partir de la console de destination DC :
C O M M A N DE C O M M EN TA IRE
IPCONFIG /ALL |MORE Notez les serveurs DNS principal, secondaire et troisième
configurés pour que le dc de destination puisse interroger
pendant les recherche DNS.
REPADMIN /SHOWREPS |MORE Dans la section repadmin Trafic entrant de la sortie,

recherchez l’état de réplication où le DC de destination
réplique une partition commune à partir de la source DC en
question.
Le GUID de l’objet DSA répertorié pour le DC source dans la

section état de réplication du rapport doit correspondre au
GUID /showreps d’objet répertorié dans l’en-tête lorsqu’il
est exécuté sur la console du DC source.
IPCONFIG /FLUSHDNS Effacer le cache client DNS
Démarrer > Exécuter > Bloc-notes Recherchez des mappages d’hôte à IP référençant l’étiquette
%systemroot%\system32\drivers\etc\hosts unique ou le nom DNS complet des contrôleurs de domaine
source. Supprimer s’il est présent. Enregistrez les
modifications dans le fichier HOST.
Exécutez Nbtstat -R (cas supérieur R) pour actualiser le

cache de noms NetBIOS.
NSLOOKUP -type=CNAME <object guid of source DCs Vérifiez que l’adresse IP renvoyée correspond à l’adresse IP
NTDS Settings object>._msdcs.<forest root DNS name> de dc cible répertoriée ci-dessus enregistrée à partir de la
<primary DNS Server IP>
console de la source DC.
Répétez l’étape pour chaque adresse IP de serveur DNS Répétez cette répétition pour tous les IPS de serveurs DNS
supplémentaire configurée sur le dc de destination. configurés sur dc de destination.
Exemple :
c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-
b10030574016._msdcs.contoso.com 152.45.42.103
nslookup -type=A+AAAA <FQDN of source DC> <DNS Recherchez des enregistrements A d’hôte en double sur
Server IP> toutes les IPS de serveur DNS configurées sur le dc de
destination.
nbtstat -A <IP address of DNS Server IP returned by Doit renvoyer le nom de la source DC.
nslookup>
NOTE
Une demande de réplication qui est redirigé vers un contrôleur autre que le contrôleur de domaine (en raison d’un
mappage nom-ADRESSE IP non bon) ou un contrôleur de domaine qui ne dispose pas actuellement de l’E351... service
UUID inscrit auprès du mappeur de point de terminaison renvoie l’erreur 1753 : aucun point de terminaison n’est
disponible avec le mappeur de point de terminaison.
La cible Kerberos ne peut pas déchiffrer les données authentifiées Kerberos en raison d’une inaltérité de mot de
passe.
Ce problème peut se produire si le mot de passe du contrôleur de domaine source diffère entre le KDC et la
copie du contrôleur de domaine source de l’annuaire Active Directory. La copie du mot de passe du compte
d’ordinateur du contrôleur de domaine source du contrôleur de domaine de destination peut être obsolète s’il
ne s’utilise pas lui-même comme KDC.
Les échecs de réplication peuvent empêcher les contrôleurs de domaine d’avoir une valeur de mot de passe
actuelle pour les contrôleurs de domaine dans un domaine donné.
Chaque contrôleur de domaine exécute le service KDC pour son domaine. Pour les mêmes transactions de
domaine, un contrôleur de domaine de destination préfère obtenir des tickets Kerberos à partir de lui-même.
Toutefois, il peut obtenir un ticket auprès d’un contrôleur de domaine distant. Les références sont utilisées pour
obtenir des tickets Kerberos à partir d’autres domaines.
La NLTEST /DSGETDC:<DNS domain of target domain> /kdc commande qui s’exécute à une invite de commandes
avec élévation de niveau élevé à proximité d’une erreur SEC_E_WRONG_PRINCIPAL peut être utilisée pour
identifier rapidement le KDC qu’un client Kerberos cible.
La façon définitive de déterminer le contrôleur de domaine auprès duquel un client Kerberos a reçu un ticket
consiste à suivre le réseau. L’absence de trafic Kerberos dans un suivi réseau peut indiquer :
Le client Kerberos a déjà acquis des tickets.
Il s’agit d’obtenir des tickets hors ligne de lui-même.
Votre application de suivi réseau n’est pas correctement en cours d’utilisation du trafic Kerberos.
Les tickets Kerberos pour le compte d’utilisateur connecté peuvent être purgés à une invite de commandes avec
élévation de niveaux à l’aide de la KLIST purge commande.
Les tickets Kerberos pour le compte système qui sont utilisés par la réplication Active Directory peuvent être
purgés sans redémarrage à l’aide KLIST -li 0x3e7 purge de .
Les contrôleurs de domaine peuvent être utilisés pour utiliser d’autres contrôleurs de domaine en arrêtant le
service KDC sur un contrôleur de domaine local ou distant.
REPADMIN /SHOWOBJMETA Permet de vérifier les différences évidentes de numéro de version dans les attributs liés
au mot de passe (dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet, lmPwdHistory) pour le contrôleur de
domaine source dans la copie du contrôleur de domaine source et du contrôleur de domaine de destination de
l’annuaire Active Directory.
C:\>repadmin /showobjmeta <source DC> <DN path of source DC computer account>
C:\>repadmin /showobjmeta <KDC selected by destination DC> <DN path of source DC computer account>
La commande netdom
resetpwd /server:<DC to direct password change to> /userd:<user name> /passwordd:<password> qui est exécuté à
une invite de commandes avec élévation de niveaux sur la console du contrôleur de domaine nécessitant une
réinitialisation de mot de passe peut être utilisée pour réinitialiser les mots de passe du compte d’ordinateur du
Résoudre les problèmes de scénarios spécifiques

Repro des étapes pour un mappage hôte-IP erroné qui entraîne l’pull du contrôleur de domaine de
destination à partir d’une source erronée.
1. Promouvoir \\dc1 + \\DC2 + \\DC3 dans le contoso.com domaine. La réplication de bout en
bout se produit sans erreurs.
2. Arrêtez le KDC sur \\DC1 \\et DC2 pour forcer le trafic Kerberos hors zone qui peut être observé
dans un suivi réseau. La réplication de bout en bout se produit sans erreurs.
3. Créez une entrée de fichier hôte \\pour DC2 qui pointe vers l’adresse IP d’un dc dans une forêt
distante. Il s’agit de simuler un mappage hôte-IP non conforme dans un enregistrement A/AAAA
hôte, ou peut-être un objet NTDS Paramètres obsolète dans la copie du contrôleur de domaine de
destination de l’annuaire Active Directory.
4. Démarrez sites et services Active Directory sur la console de \\DC1. Cliquez avec le bouton \\droit
sur l’objet \\de connexion entrant de DC1 à partir de DC2 et notez que le nom du compte cible
est une erreur de réplication incorrecte.
Repro steps for a source domain controller password mismatch between KDC and the source domain
controller.
1. Promouvoir \\dc1 + \\DC2 + \\DC3 dans le contoso.com domaine. La réplication de bout en
bout se produit sans erreur.
2. Arrêtez le KDC sur \\DC1 \\et DC2 pour forcer le trafic Kerberos hors zone qui peut être observé
dans le suivi réseau. La réplication de bout en bout se produit sans erreur.
3. Désactivation de la réplication entrante sur KDC \\DC3 pour simuler un échec de réplication sur le
KDC.
4. Réinitialisez le mot de passe \\du compte d’ordinateur sur DC2 \\trois fois ou plus afin que DC1
\\et DC2 ont tous deux le mot de passe actuel pour \\DC2.
5. Démarrez sites et services Active Directory sur la console de \\DC1. Cliquez avec le bouton \\droit
sur l’objet \\de connexion entrant de DC1 à partir de DC2 et notez que le nom du compte cible est
une erreur de réplication incorrecte.
Journalisation du client RPC DS
Définir NTDS\Diagnostics Loggings\DS RPC Client = 3 . Déclencher la réplication. Recherchez
l’événement de catégorie de tâche 1962 + 1963. Notez la liste complète cname qui est répertoriée dans
le champ du ser vice d’annuaire . Le contrôleur de domaine de destination doit être en mesure
d’envoyer un ping à cet enregistrement et d’avoir l’adresse renvoyée sur l’adresse IP actuelle de la source
DC.
Flux de travail Kerberos
Le flux de travail Kerberos comprend les actions suivantes :
L’ordinateur client appelle la fonction IntializeSecurityContext et spécifie le fournisseur de support
de sécurité Negotiate (SSP).
Le client contacte le KDC avec son TGT et demande un ticket TGS pour le contrôleur de domaine
cible.
Le KDC recherche dans le catalogue global une source (e351 ou nom d’hôte) dans le domaine du
contrôleur de domaine de destination.
Si le contrôleur de domaine cible se trouve dans le domaine du contrôleur de domaine de
destination, le KDC fournit au client un ticket de service.
Si le contrôleur de domaine cible se trouve dans un autre domaine, le KDC fournit au client un
ticket de référence.
Le client contacte un KDC dans le domaine du contrôleur de domaine cible et demande un ticket
de service.
Si le nom de domaine unique du contrôleur de domaine source n’existe pas dans le domaine, vous
recevez KDC_ERR_S_PRINCIPAL_UNKNOWN erreur.
Le contrôleur de domaine de destination contacte la cible et présente son ticket.
Si le contrôleur de domaine cible possède le nom dans le ticket et peut le déchiffrer,
l’authentification fonctionne.
Si le contrôleur de domaine cible héberge l’UUID du service de serveur RPC, l’erreur kerberos
KRB_AP_ERR_NOT_US ou KRB_AP_ERR_MODIFIED sur le réseau est réapplique à l’erreur
suivante :
-2146893022 décimal / 0x80090322 / SEC_E_WRONG_PRINCIPAL / « Le nom principal cible

est incorrect »
Erreur de réplication Active Directory 5 - Accès
refusé
Cet article décrit les étapes de symptômes, de cause et de résolution pour les situations dans lesquelles les
opérations AD échouent avec l’erreur 5 : l’accès est refusé.
Symptômes
1. DCDIAG signale que le test réplications Active Directory a échoué avec le code d’état d’erreur (5) : l’accès
est refusé .
Testing server: <site name><destination dc name>

Replications Check
[Replications Check,<destination DC name] A recent replication attempt failed:
Access is denied.
3 failures have occurred since the last success.
2. DCDIAG signale que DsBindWithSpnEx() a échoué avec l’erreur 5.

3. REPADMIN.EXE signale que la dernière tentative de réplication a échoué avec l’état 5.
REPADMIN les commandes qui mentionnent généralement l’état 5 incluent, mais ne sont pas limitées à :
REPADMIN /KCC
REPADMIN /REPLICATE
REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL
Un exemple de sortie REPADMIN /SHOWREPS de l’affichage de la réplication entrante de CONTOSO-DC2 vers
CONTOSO-DC1 ayant échoué avec l’accès à la réplication a été refusé est illustré ci-dessous :
DSA Options: IS_GC
DSA object GUID: b6dc8589-7e00-4a5d-b688-045aef63ec01
DC=contoso, DC=com
DSA object GUID: 74fbe06c-932c-46b5-831b-af9e31f496b2
Last attempt @ <date> <time> failed, result 5 (0x5):
Access is denied.
<#> consecutive failure(s).
4. Les événements NTDS KCC, NTDS General ou Microsoft-Windows-ActiveDirectory_DomainService avec

l’état 5 sont enregistrés dans le journal des événements du service d’annuaire.

échoué.


lien de réplication vers une partition
de répertoire en lecture seule avec
les paramètres suivants a échoué.
5. La commande Répliquer maintenant dans Sites et services Active Directory renvoie le refus
d’Access .
Le fait de cliquer avec le bouton droit sur l’objet de connexion à partir d’un dc source et de choisir la
réplication échoue maintenant avec Access est refusé . Le texte et la capture d’écran du message
d’erreur à l’écran sont présentés ci-dessous :
6. Texte du titre de la boîte de dialogue : répliquer maintenant

noms <%nom de la partition d’annuaire%> <Source DC> <Destination DC>du contrôleur de
domaine au contrôleur de domaine : l’accès est refusé.

Cause
Causes racines valides de l’erreur 5 : l’accès est refusé :
1. Le paramètre RestrictRemoteClients dans le Registre a la valeur 2 .
2. L’accès à cet ordinateur à partir du droit d’utilisateur réseau n’est pas accordé au groupe contrôleurs
de Enterprise ou à l’administrateur déclenchant une réplication immédiate.
3. Le paramètre CrashOnAuditFail dans le Registre du DC de destination a la valeur 2 .
4. Il existe une différence de temps entre le centre de distribution de clés (KDC) utilisé par le dc de destination et
le dc source. La différence de temps dépasse la inclinaison de temps maximale autorisée par Kerberos définie
dans la stratégie de domaine par défaut.
5. Il existe une non-matisation de signature SMB entre les DCS source et de destination.
6. Il existe une incompatibilité LMCompatiblity entre les DCS source et de destination.
7. Les noms principaux de service ne sont pas enregistrés ou ne sont pas présents en raison d’une latence de
réplication simple ou d’un échec de réplication.
8. Les paquets Kerberos au format UDP sont fragmentés par les périphériques d’infrastructure réseau tels que
les routeurs et les commutateurs.
9. Le canal sécurisé sur la source ou la destination DC n’est pas valide.
10. Les relations d’confiance dans la chaîne d’confiance sont rompues ou non valides.
11. Le paramètre KDCNames dans la HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains section du
Registre contient de manière incorrecte le nom de domaine Active Directory local.
12. Certaines cartes réseau disposent d’une fonctionnalité de déchargement d’envoi important.
13. Logiciel antivirus qui utilise un pilote de filtre de carte réseau de mini-pare-feu sur le dc source ou de
destination.
Les erreurs et événements Active Directory comme ceux mentionnés dans la section symptômes de cette ko
peuvent également échouer avec l’erreur 8453 avec une chaîne d’erreur similaire Accès à la réplication a été
refusé . Les raisons principales suivantes peuvent provoquer l’échec des opérations AD avec le 8453 : l’accès à la
réplication a été refusé, mais ne provoque pas d’échecs avec l’erreur 5 : la réplication est refusée :
1. La tête NC n’est pas autorisée avec l’autorisation de modification du réper toire de réplication.
2. Le principal de sécurité qui démarre la réplication n’est pas membre d’un groupe qui a reçu des
modifications de réper toire de réplication .
3. Indicateurs manquants dans l’attribut UserAccountControl , y compris SERVER_TRUST_ACCOUNT et
TRUSTED_FOR_DELEGATION .
4. RODC promu dans le domaine sans avoir été exécuté pour la première fois ADPREP /RODCPREP .
Résolution
L’échec de la réplication AD avec l’erreur 5 a plusieurs causes premières. Résoudre le problème initialement à
l’aide d’outils tels que :
DCDIAG
DCDIAG /TEST : CheckSecurityError
NETDIAG qui expose des problèmes courants
S’il n’est toujours pas résolu, vous passerez la liste des causes connues dans l’ordre le plus courant, le moins
complexe, le moins perturbant vers l’ordre le plus courant, le plus complexe et le plus perturbant.
Exécuter DCDIAG, DCDIAG /TEST:CheckSecurityError et NETDIAG
DcDIAG générique exécute plusieurs tests.
DCDIAG /TEST:CheckSecurityErrors a été écrit pour faire des tests spécifiques (y compris une vérification
d’inscription SPN) afin de résoudre les problèmes de réplication des opérations Active Directory ayant échoué
avec :
erreur 5 : accès refusé
erreur 8453 : accès à la réplication refusé
DCDIAG /TEST:CheckSecurityErrors n’est pas exécuté dans le cadre de l’exécution par défaut de DCDIAG.
1. Exécuter DCDIAG sur le dc de destination
2. Exécuter DCDIAG /TEST:CheckSecurityError
3. Exécuter NETDIAG
4. Résolvez les erreurs identifiées par DCDIAG et NETDIAG. Réessayez l’opération de réplication qui a échoué
précédemment. En cas d’échec, poursuivez jusqu’à la fin .
Long terme
1. RestrictRemoteClients est définie sur 2
Cette valeur de Registre est définie sur une valeur de 0x2 dans
RestrictRemoteClients
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC .

a. Désactivez la stratégie qui applique ce paramètre.
b. Supprimez le RestrictRemoteClients paramètre de Registre et redémarrez.
Pour plus d’informations sur ce paramètre, voir La clé de Registre RestrictRemoteClients est
activée.
La RestrictRemoteClients valeur de Registre est définie par le paramètre de stratégie de groupe
suivant :
Configuration de l’ordinateur > Modèles d’administration > Système > Appel de
procédure distante - Restrictions pour les clients RPC non authentifiés
Une valeur de Registre de 0x2 est appliquée si le paramètre de stratégie est activé et s’il est
authentifié sans exceptions .
Cette option permet uniquement aux clients RPC authentifiés de se connecter aux serveurs RPC en
cours d’exécution sur l’ordinateur sur lequel le paramètre de stratégie est appliqué. Il n’autorise pas
les exceptions. Si vous sélectionnez cette option, un système ne peut pas recevoir d’appels
anonymes distants à l’aide de RPC. Ce paramètre ne doit jamais être appliqué à un contrôleur de
domaine.
2. Vérifiez l’accès à cet ordinateur à par tir des droits réseau.
Dans une installation par défaut de Windows, la stratégie de contrôleurs de domaine par défaut est liée
au conteneur d’ou des contrôleurs de domaine. Il accorde l’accès à cet ordinateur à par tir du droit
d’utilisateur réseau aux groupes de sécurité suivants :
ST RAT ÉGIE LO C A L E ST RAT ÉGIE DE C O N T RÔ L EURS DE DO M A IN E PA R DÉFA UT
Administrateurs Administrateurs
Utilisateurs authentifiés Utilisateurs authentifiés
Tout le monde Tout le monde
Enterprise de domaine Enterprise de domaine
[Accès pré-Windows 2000] [Accès pré-Windows 2000]
Si les opérations Active Directory échouent avec l’erreur 5 : l’accès est refusé, vérifiez que :
Les groupes de sécurité de la liste ci-dessus se sont vus accorder l’accès à cet ordinateur à partir du
réseau directement dans la stratégie par défaut des contrôleurs de domaine.
Les comptes d’ordinateur du contrôleur de domaine se trouvent dans l’ou des contrôleurs de domaine.
La stratégie de contrôleurs de domaine par défaut est liée à l’ou des contrôleurs de domaine ou à
d’autres comptes d’ordinateur d’hébergement.
La stratégie de groupe s’applique au contrôleur de domaine de destination qui journalisation
actuellement l’erreur 5.
Refuser l’accès à cet ordinateur à partir d’un droit d’utilisateur réseau n’a pas été activé ou ne fait
pas référence à des groupes directs ou imbrmbrés défaillants.
La priorité de la stratégie, l’héritage bloqué, le filtrage WMI, etc., n’empêche pas le paramètre de
stratégie de s’appliquer aux ordinateurs de rôle DC.
Les paramètres de stratégie peuvent être validés avec RSOP. MSC, mais GPRESULT /Z il s’agit de l’outil
préféré, car il est plus précis.
NOTE
La stratégie locale est prioritaire sur la stratégie définie dans Sites, Domaines et ou.
NOTE
À un moment, il était courant pour les administrateurs de supprimer les contrôleurs de domaine d’entreprise et
tous les groupes de l’accès à cet ordinateur du réseau directement dans la stratégie de contrôleurs de domaine
par défaut. La suppression des deux est fatale. Il n’y a aucune raison de supprimer des contrôleurs de domaine
d’entreprise de ce droit, car seuls les DCS sont membres de ce groupe.
3. CrashOnAuditFail =2
Échec de la réplication HKLM\System\CurrentControlSet\Control\LSA\CrashOnAuditFail AD lorsque = a la
valeur 2 ,
CrashOnAduitFail La valeur 2 est déclenchée lorsque l’audit : arrêter immédiatement le système si le
paramètre d’audit de sécurité dans la stratégie de groupe est activé et que le journal des événements de
sécurité local devient plein.
Les contrôleurs de domaine Active Directory sont particulièrement sujets aux journaux de sécurité de
capacité maximale lorsque l’audit a été activé, et la taille du journal des événements de sécurité a été
limitée par les événements Ne pas over write (effacer manuellement le journal) ou Over write selon les
options requises dans l’Observateur d’événements ou les équivalents de stratégie de groupe.
Si HKLM\System\CCS\Control\LSA\CrashOnAuditFail =2:
Effacer le journal des événements de sécurité (enregistrer à un autre emplacement si nécessaire)
Ré-évitez les contraintes de taille dans le journal des événements de sécurité, y compris les
paramètres basés sur la stratégie.
Recréer CrashOnAuditFail (REG_DWORD) = 1
Redémarrage
Si la valeur 0 ou 1 est vue, certains ingénieurs CSS ont résolu des erreurs d’accès en effantant à nouveau
le journal des événements de sécurité, the CrashOnAuditFail en supprimant la valeur de Registre et en
redémarrage de la base de données de destination. CrashOnAuditFail
Contenu connexe : gérer le journal d’audit et de sécurité.
4. Décalage de temps excessif
Les paramètres de stratégie Kerberos dans la stratégie de domaine par défaut permettent une différence
de 5 minutes (valeur par défaut) dans le temps système entre les contrôleurs de domaine KDC et un
serveur cible Kerberos pour empêcher les attaques par relecture. Certaines documentations indiquent
que le temps entre le client et la cible Kerberos doit être de cinq minutes l’un après l’autre. D’autres font
état du fait que dans le contexte de l’authentification Kerberos, le temps qui importe est le delta entre le
KDC utilisé par l’appelant et l’heure sur la cible Kerberos. En outre, Kerberos ne se soucie pas que l’heure
système sur les DCS pertinents corresponde à l’heure actuelle. Il se soucie uniquement du fait que la
différence de temps relative entre le KDC et le dc cible se trouve à l’intérieur de la inclinaison de temps
maximale (cinq minutes par défaut ou moins) autorisée par la stratégie Kerberos.
Dans le contexte des opérations Active Directory, le serveur cible est le DC source contacté par le dc de
destination. Chaque contrôleur de domaine dans une forêt Active Directory (exécutant actuellement le
service KDC) est un KDC potentiel. Vous devez donc prendre en compte la précision du temps sur tous les
autres DCS par rapport à la source DC, y compris l’heure sur le DC de destination lui-même.
Deux méthodes de vérification de la précision du temps sont les suivantes :
C:\> DCDIAG /TEST: CheckSecurityError
AND
C:\> W32TM /MONITOR
Recherchez les événements LSASRV 40960 sur le dc de destination au moment de l’échec de la demande
de réplication qui mentionne un enregistrement CNAME GUIDed de la source DC avec une erreur
étendue :
0xc000133 : l’heure au niveau du contrôleur de domaine principal est trop importante que celle du
contrôleur de domaine de sauvegarde ou du serveur membre.
Les suivis réseau qui capturent l’ordinateur de destination qui se connecte à un dossier partagé sur le dc
source (et d’autres opérations) peuvent afficher l’erreur à l’écran qu’une erreur étendue s’est produite .
Toutefois, une trace réseau indique :
KerberosV5:TGS Request Realm > TGS request from source DC

KerberosV5:KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) > réponse TGS où KRB_AP_ERR_TKE_NYV >
mapp à Ticket non encore valide
La TKE_NYV indique que la plage de dates sur le ticket TGS est plus nouvelle que l’heure sur la cible, ce
qui indique une inclinaison excessive du temps.
NOTE
W32TM /MONITOR vérifie uniquement le temps sur les DCS dans le domaine des ordinateurs de test afin que vous
devrez l’exécuter dans chaque domaine et comparer le temps entre les domaines.
NOTE
Si le temps système s’est révélé inexact, veillez à déterminer pourquoi et ce qui peut être fait pour éviter les temps
imprécis à l’avenir. Le PDC racine de la forêt a-t-il été configuré avec une source de temps externe ? Les sources de
temps de référence sont-elles en ligne et disponibles sur le réseau ? Le service de temps était-il en cours
d’exécution ? Les ordinateurs de rôle DC sont-ils configurés pour utiliser la hiérarchie NT5DS pour l’heure source ?
NOTE
Lorsque la différence de temps est trop importante sur Windows DCS de destination Server 2008 R2, la
commande répliquer maintenant dans DSSITE. Le MSC échoue avec l’erreur à l’écran Il existe une différence
d’heure et/ou de date entre le client et le ser veur . Cette chaîne d’erreur est mie à l’erreur 1398
décimale/0x576 hexadécimal avec le nom d’erreur symbolique ERROR_TIME_SKEW .
Contenu connexe : définition de la tolérance de synchronisation des horloges pour empêcher les attaques
par relecture.
5. Non-matisation de la signature SMB
La meilleure matrice de compatibilité pour la signature SMB est définie par quatre paramètres de
stratégie et leurs équivalents basés sur le Registre :
Client réseau Microsoft : communications avec signature HKLM\SYSTEM\CCS\Services\Lanmanworkstation\Param

numérique (si le serveur l’accepte) eters\Enablesecuritysignature
Client réseau Microsoft : communications avec signature HKLM\SYSTEM\CCS\Services\Lanmanworkstation\Param

numérique (toujours) eters\Requiresecuritysignature
Serveur réseau Microsoft : communications avec HKLM\SYSTEM\CCS\Services\Lanmanserver\Parameters\

signature numérique (si le serveur l’accepte) Enablesecuritysignature
Serveur réseau Microsoft : communications avec HKLM\SYSTEM\CCS\Services\Lanmanserver\Parameters\

signature numérique (toujours) Requiresecuritysignature
Concentrez-vous sur les différences de signature SMB entre les contrôleurs de domaine source et de
destination, les cas classiques étant activés ou obligatoires d’un côté, mais désactivés de l’autre.
NOTE
Des tests internes ont montré des indisponibilités de signature SMB entraînant l’échec de la réplication avec
l’erreur 1722 : le serveur RPC n’est pas disponible .
6. Fragmentation de paquets Kerberos au format UDP

Les routeurs et commutateurs réseau peuvent fragmenter ou abandonner complètement de grands
paquets réseau au format UDP utilisés par Kerberos et EDNS0 (DNS). Les ordinateurs exécutant Windows
2000 et Windows 2003 sont vulnérables à la fragmentation UDP par rapport aux ordinateurs exécutant
Windows Server 2008 et 2008 R2.
À partir de la console du dc de destination, ping sur la source DC par son nom d’ordinateur
complet pour identifier le plus grand paquet pris en charge par l’itinéraire réseau.
c:\> Ping <source DC hostname.>. <fully qualified computer name> -f -l 1472
Si le plus grand paquet non fragmenté est inférieur à 1 472 octets, soit (par ordre de préférence)
Modifiez votre infrastructure réseau pour prendre correctement en charge les images UDP
de grande taille. Elle peut nécessiter une mise à niveau du microprogramme ou une
modification de la config sur les routeurs, commutateurs ou pare-feu.
OR
Définissez maxpacketsize (sur la base de données de destination) sur le plus grand paquet
identifié par la commande PING -f -l moins 8 octets pour prendre en compte l’en-tête TCP et
redémarrer le dc modifié.
OR
Définissez maxpacketsize (sur la dc de destination) sur la valeur « 1 », ce qui déclenche
l’utilisation d’un protocole TCP par Kerberos. Redémarrez le dc modifié pour que la
modification prenne effet.
Réessayer l’opération Active Directory ayant échoué
1. Canal sécurisé non valide / Insécurisation du mot de passe
Valider le canal sécurisé avec ou nltest /sc: query netdom verify .
Pour plus d’informations sur la réinitialisation du mot de passe de dc de destination avec, voir Comment
utiliser Netdom.exe pour réinitialiser les mots de passe de compte d’ordinateur d’un NETDOM / RESETPWD
contrôleur de domaine Windows Server.
Désactivez le service KDC sur le dc en cours de redémarrage.
À partir de la console de destination DC, exécutez NETDOM RESETPWD pour réinitialiser le mot de
passe du dc de destination :
c:\>netdom resetpwd /server: server_name /userd: domain_name \administrator /passwordd:

administrator_password
Assurez-vous que les KDCs probables et la source DC (si dans le même domaine) répliquent les
connaissances entrantes du nouveau mot de passe des DCS de destination.
Redémarrez le dc de destination pour vider les tickets Kerberos et réessayez l’opération de
réplication.
2. Confiance non valide
Si la réplication AD échoue entre les DCS dans différents domaines, vérifiez l’état des relations
d’confiance le long du chemin d’accès d’confiance
Lorsque vous en avez la possibilité, utilisez le test de relation d’confiance NETDIAG pour vérifier la
rupture des relations d’confiance. NETDIAG identifie les confiances rompues avec le texte suivant :
Test de relation d’confiance. . . . . . : Échec du test pour s’assurer que DomainSid du domaine
<domainname> est correct. [FATAL] Le canal sécurisé vers le domaine <domainname> est rompu.
[<%code d’état variable%>]
Par exemple, vous avez une forêt multi-domaines contenant :

domaine racine Contoso.COM
domaine enfant B.Contoso.COM
domaine petit-enfant C.B.Contoso.COM
domaine d’arborescence dans la même forêt Fabrikam.COM
Si la réplication échoue entre les DCS dans le domaine petit-enfant C.B.Contoso.COM Fabrikam.COM et le
domaine d’arborescence, vérifiez l’état d’confiance dans l’ordre suivant :
entre et C.B.Contoso.COM``B.Contoso.COM
entre et B.Contoso.COM``Contoso.COM
entre et Contoso.COM``Fabrikam.COM
S’il existe une confiance raccourcie entre les domaines de destination, la chaîne de chemin d’accès d’trust
n’a pas besoin d’être validée. Au lieu de cela, validez l’accord de raccourci entre le domaine de destination
et le domaine source.
Repadmin /showobjmeta * \<DN path for TDO in question> Vérifiez que les modifications récentes
apportées au mot de passe de l’relation d’confiance avec l’objet de domaine approuvé (TDO) vérifient que
le dc de destination est transitivement entrant réplication de la partition d’annuaire de domaine
accessible en writable où les modifications de mot de passe d’confiance peuvent avoir lieu.
Commandes pour réinitialiser les confiances :
À partir du domaine racine PDC :
netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT

/PasswordO:* /Reset /TwoWay
À partir du domaine enfant PDC :
netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root/PasswordD:*/UserO:Child

/PasswordO:* /Reset /TwoWay
3. Domaine Kerberos non valide - PolAcDmN / PolPrDmN (pas de repro lors de la réécrite de l’article)
La copie à partir du contrôleur de domaine ne fonctionne pas correctement.
a. Démarrez l’Éditeur du Registre.
b. Dans le volet gauche, développez Sécurité .
c. Dans le menu Sécurité , sélectionnez Autorisations pour accorder au groupe local Administrateurs
le contrôle total de la ruche SECURITY et de ses conteneurs et objets enfants.
d. Recherchez la HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN clé.
e. Dans le volet droit de l’Éditeur du Registre, <No Name>sélectionnez l’entrée : REG_NONE entrée
une fois.
f. Dans le menu Affichage , sélectionnez Afficher les données binaires . Dans la section Format de
la boîte de dialogue, sélectionnez Byte .
g. Le nom de domaine apparaît sous la forme d’une chaîne dans le côté droit de la boîte de dialogue
Données binaires. Le nom de domaine est identique au domaine Kerberos.
h. Recherchez la HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN clé de Registre.
i. Dans le volet droit de l’Éditeur du Registre, double-cliquez <No Name>sur l’entrée REG_NONE :
j. Dans la boîte de dialogue Éditeur binaire, collez la valeur de PolPrDmN . (La valeur de PolPrDmN
sera le nom de domaine NetBIOS).
k. Redémarrez le contrôleur de domaine.
4. Domaine Kerberos non valide - KdcNames
Sur la console de destination DC, exécutez REGEDIT.
Recherchez le chemin d’accès suivant dans le Registre : HKLM\system\ccs\control\lsa\kerberos\domains .
Pour chaque <fully qualified domain> sous HKLM\system\ccs\control\lsa\kerberos\domains , KdcNames
vérifiez que la valeur pour fait référence à un domaine Kerberos externe valide et NON au domaine
local ou à un autre domaine dans la même forêt Active Directory.
5. Cartes réseau avec déchargement d’envoi important IPv4 activé :
Ouvrez les propriétés de la car te carte réseau.
Sélectionnez Le bouton Configurer.
Sélectionnez Onglet Avancé.
Désactivez le déchargement d’envoi impor tant IPv4 .
Redémarrez.
Le contexte d’attribution de noms est en cours de
suppression ou n’est pas répliqué à partir du serveur
spécifié
Cet article fournit une résolution pour résoudre l’erreur de réplication Active Directory (8452). Cet article est
destiné uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous êtes un
utilisateur à domicile et que vous recherchez de l’aide sur un problème, demandez à l’Community Microsoft.
Symptômes
1. DCDIAG signale que le test réplications Active Directory a échoué avec le code d’état d’erreur (8452) : le
contexte d’attribution de noms est en cours de suppression ou n’est pas répliqué à partir du serveur
spécifié.
Serveur de test : <site name><destination dc name>

Vérification des réplications
[Vérification des réplications,<destination DC name>] Une tentative de réplication récente a échoué :
Le contexte d’attribution de noms est en cours de suppression ou n’est pas répliqué à partir du
serveur spécifié.
2. REPADMIN.EXE signale que la dernière tentative de réplication a échoué avec l’état 8452.
REPADMIN les commandes qui mentionnent généralement les cinq états incluent, sans s’y limiter , les
suivantes :
REPADMIN /SHOWREPS
REPADMIN /REPLSUM
REPADMIN /SYNCALL
Un exemple de sortie REPADMIN /SHOWREPS de la représentation de la réplication entrante de CONTOSO-
DC2 vers CONTOSO-DC1 ayant échoué avec l’accès à la réplication a été refusé est illustré ci-dessous :
DSA Options: IS_GC
DSA object GUID: b6dc8589-7e00-4a5d-b688-045aef63ec01
DC=contoso,DC=com
The naming context is in the process of being removed or is not replicated from the specified
server.
3. La commande Répliquer maintenant dans sites et services Active Directory renvoie l’erreur suivante :
Le contexte d’attribution de noms est en cours de suppression ou n’est pas répliqué à partir du
serveur spécifié.
Le fait de cliquer avec le bouton droit sur l’objet de connexion à partir d’un dc source et de choisir
répliquer échoue maintenant avec l’erreur ci-dessus. Le texte du message d’erreur à l’écran s’affiche ci-
dessous :
Texte du titre de la boîte de dialogue : texte du message Répliquer maintenant boîte de dialogue :
l’erreur suivante s’est produite lors de la tentative de synchronisation du contexte d’attribution de
noms <%nom de la partition d’annuaire%> <Source DC> <Destination DC>du contrôleur de
domaine au contrôleur de domaine : le contexte d’attribution de noms est en cours de suppression ou
n’est pas répliqué à partir du serveur spécifié.

les cinq états sont enregistrés dans le journal des événements du service d’annuaire.
NTDS General 1586 Le point de contrôle avec le PDC a

échoué. Le processus de point de
contrôle sera de nouveau retenté
dans quatre heures. Une
synchronisation complète de la base
de données de sécurité avec les
contrôleurs de domaine de niveau
bas peut avoir lieu si cet ordinateur
est promu comme PDC avant le
prochain point de contrôle réussi.
L’erreur renvoyée était : le contexte
d’attribution de noms est en cours
de suppression ou n’est pas répliqué
à partir du serveur spécifié.
Cause
Cette erreur se produit le plus souvent lorsque les topologies de réplication suivantes sont différentes :
Topologie de réplication dans un dc qui démarre la réplication.
Topologie de réplication définie dans la copie dc de destination d’Active Directory.
L’erreur se produit naturellement lorsque la topologie de réplication dans une forêt Active Directory est modifiée
par :
Nouvelles partitions ajoutées ou supprimées de la forêt. Par exemple, la promotion ou la rétrogradation
du premier/dernier dc dans un domaine. Ou l’ajout/suppression d’une partition d’application, y compris
les partitions d’application DNS par défaut.
L’ajout ou la suppression de partitions d’annuaire sur des DCS existants (c’est-à-dire, la
promotion/rétrogradation du catalogue global ou l’ajout/suppression d’une partition d’application).
Modifications apportées à la topologie ou aux paramètres de réplication :
Promotion de nouveaux DCS
Rétrogradation des DCS existants
Modifications apportées aux têtes de pont préférées/nommées
La création de chemins de réplication alternatifs en réponse à des échecs de réplication ou à des DCS
hors connexion
Modifications des liens de site et de site.
L’erreur peut être passagère dans une forêt qui subit les modifications ci-dessus. Elle reste temporaire jusqu’à ce
que l’ensemble des DCS et partitions sources à partir duquel chaque dc de destination réplique soit répliqué en
déclenchant des opérations de réplication.
L’erreur peut être persistante lorsque des échecs de réplication empêchent la réplication de bout en bout des
modifications de topologie dans la forêt.
L’erreur est le plus souvent vue dans les scénarios de réplication déclenchés par REPADMIN.EXE à distance (en
/SYNCALL particulier ) ou la commande répliquer maintenant dans DSSITE. MSC où la copie d’Active Directory
sur la réplication déclenchant la réplication dc présente une liste de DCS source différente qu’un DC de
destination réplique à partir de partitions par rapport à ce que le dc de destination a défini dans sa copie
d’Active Directory.
Windows 2000 contrôleurs de domaine sont particulièrement sujets à cette erreur lors de la rétrogradation gc,
car ils sont lents à supprimer des objets des partitions en lecture seule. La suppression d’objets lors de la
rétrogradation gc s’est considérablement améliorée sur Windows Server 2003 et versions ultérieures du
L’événement de réplication NTDS 1586 se produit dans la situation suivante :
Le rôle FSMO (Flexible Single Master Operation) du contrôleur de domaine principal pour le domaine a été
saisi ou transféré vers un contrôleur de domaine qui n’était pas un partenaire de réplication direct du détenteur
de rôle précédent.
Dans de rares conditions, l’erreur peut être causée par une altération des attributs tels que hasMasterNCs ou
msds-hasMasterNCs .
La section Plus d’informations de cet article contient des explications sur la raison pour laquelle les outils de
diagnostic et d’administration répertoriés dans la section Symptômes de cet article génèrent l’erreur 8452.
En résumé, l’erreur 8452 se produit si l’une des conditions suivantes est vraie :
1. Lorsque DC1 <- DC2 est démarré pour un contexte d’attribution de noms (NC), sur DC1, il n’existe aucun lien
de réplica pour le NC à partir de DC2.
2. Lorsque DC1 <- DC2 en cours de réplication pour une NC, le NC est en cours de suppression sur DC2.
3. Dans un environnement de domaine mixte, le rôle FSMO PDC est transféré de DC2 à DC1, mais sur DC1, il
n’existe aucun lien de réplica à partir de DC2.
Résolution
1. Patientez. Comme mentionné plus haut, cette condition est temporaire et ne justifie normalement pas le
dépannage.
Supposons que les modifications de topologie de réplication du type répertorié dans la section Cause ont
lieu dans votre forêt Active Directory. Dans ce cas, attendez que la condition d’erreur se corrige avec le
temps.
2. repadmin /syncall Évitez d’utiliser la commande et les équivalents tant que les contrôleurs de domaine
ne démarrent pas la réplication et que les DCS de destination sont répliqués pour accepter les DCS
sources et les partitions d’annuaire en cours de réplication.
3. A apporté des modifications d’origine aux bons endroits.
4. Push et Pull modifient l’objet de connexion et la partition selon les besoins.
5. Aller directement.
Si la commande répliquer maintenant de \DC3 à \DC2 lorsque le DSSITE. Le logiciel en snap-in MSC
est exécuté à partir de la console \de DC1 \, mais se concentre sur DC4, et coupe les intermédiaires.
Si l’erreur est due à la cause première non. 3, une fois que l’utilisateur a donné l’entrée correcte, l’erreur
ne se produit pas. Par exemple, au cas où non. 1 du scénario non. 3, si l’utilisateur <src DC> <the NC>
<dest DC> <src DC> entre une commande correcte de telle façon que sur un lien de réplica à partir de ,
repadmin /replicate la commande est exécutée avec succès.
6. Résoudre les échecs de réplication bloquant la réplication de bout en bout.

7. REPADMIN /REPLICATE.
8. Événement de réplication NTDS 1586.
Pour l’événement de réplication NTDS 1586, transférez le rôle DPC à un contrôleur de domaine Active
Directory qui est actuellement un partenaire de réplication direct du PDC de domaine précédent.
repadmin /syncall
L’opération repadmin /syncall entraîne le démarrage de la réplication à partir de tous ses partenaires de
réplication source par un dc et la réplication des partenaires de réplication source à partir de tous leurs
partenaires de réplication source, etc.
Par exemple, supposons que nous avons une topologie de réplication DC1 <- DC2 <- DC3. repadmin /syncall
sur DC1 démarre la réplication suivante : DC2 <- DC3 et DC1 <- DC2.
Il existe deux cas où l’erreur 8452 peut être observée dans ce scénario :
Cas 1 : modifier la topologie de réplication pour que DC2 soit répliqué entrant à partir de DC4 afin que la
topologie actuelle devienne DC1 <- DC2 <- DC4.
repadmin /syncall Si nous appelons DC1 avant de connaître les réplications entrantes de la topologie DC2 <-
DC4 vers DC1, syncall l’opération démarre les réplications DC2 <- DC3, car DC1 conserve l’ancienne topologie
de réplication stockée localement. Sur DC2 pour le moment, le KCC a créé un lien de réplica à partir de DC4 et a
supprimé le lien de réplica de DC3. La réplication de DC2 <- DC3 ne peut donc pas être exécutée et l’opération
enregistre l’erreur 8452.
Cas 2 : supposons qu’une NC sur DC3 est en cours de suppression pendant que nous appelons
repadmin /syncall <the NC> DC1. Dc2 <- La réplication DC3 sera démarrée comme auparavant. Étant donné
que le NC sur DC3 est en cours de suppression, il ne s’agit pas d’une source de réplication valide, l’erreur 8452
est observée.
Sites et services Active Directory (DSSITE. MSC ) -> répliquer maintenant
Le logiciel en ligne Sites et services Active Directory, DSSITE. MSC utilise les informations de topologie stockées
dans sa copie locale d’AD.
Étant donné la topologie de réplication DC1 <- DC2 <- DC3, un objet de connexion existe sous l’objet
Paramètres NTDS de DC2. Cet objet de connexion représente l’itinéraire vers DC2 pour répliquer un NC (ou
plusieurs NCs) entrants à partir de DC3. Si nous cliquons avec le bouton droit sur cet objet de connexion et que
nous sélectionnons répliquer maintenant, nous allons démarrer une réplication DC2 <- DC3 sur DC2.
Comme dans l’exemple REPAMIN /SYNCALL , il existe également deux cas où nous pouvons observer l’erreur
8452.
Cas 1 : supposons que nous changeons la topologie de réplication sur DC2 pour la rendre réplication entrante à
partir de DC4. La nouvelle topologie de réplication est DC1 <- DC2 <- DC4. Tant que cette topologie n’a pas
changé de réplication sortante vers DC1, la topologie sur DC1 est toujours l’ancienne topologie de DC1 <- DC2
<- DC3.
Le démarrage de l’interface utilisateur Des sites et services Active Directory axé sur la copie DC1s d’Active
Directory indique toujours que DC2 dispose d’un objet de connexion entrant à partir de la source DC3. Le fait de
cliquer avec le bouton droit sur l’objet de connexion entrante DCS à partir de DC2 et de choisir la réplication
maintenant démarre une réplication DC2 <- DC3 sur DC2. Toutefois, le KCC sur DC2 a déjà supprimé le lien de
réplica entrant vers DC2 de DC3 et créé un lien de réplica vers DC2. Étant donné que la tentative de réplication
DC2 <-> DC2 ne peut pas être exécutée, la demande échoue à l’erreur 8452.
Cas 2 : supposons que nous supprimant un NC sur DC3 lorsque nous cliquons avec le bouton droit sur l’objet de
connexion, puis que nous sélectionnons répliquer maintenant sur DC1 pour démarrer la réplication DC2 <- DC3
pour cette NC. Étant donné que le NC sur DC3 est en cours de suppression, DC3 n’est pas une source de
réplication valide. Nous allons donc voir l’erreur 8452.
repadmin /replicate ou repadmin /sync
La replicate commande (ou sync ) de repadmin déclencheur la réplication immédiate d’un contexte
d’attribution de noms (partition d’annuaire) vers un dc de destination à partir d’un dc source. Sa syntaxe
(simplifiée) est la suivante : repadmin /replicate <dest DC> <src DC> <replicated NC> .
Dans deux cas, nous déclencherons l’erreur 8452 repadmin /replicate lorsque la commande (ou sync ) est
utilisée pour démarrer une réplication :
Cas 1 : le paramètre <src DC> n’est pas un partenaire de réplication pour <dest DC> <replicated NC>. Par
exemple, nous devons réplication de la topologie DC1 <- DC2 <- DC3 dans laquelle DC2 synchronise une NC à
partir de DC3. Si nous appelons repadmin /replicate DC2 DC1 nc, une réplication DC2 <- DC1 sera démarrée.
Étant donné que sur DC2, nous n’avons pas de lien de réplica à partir de DC1 pour le NC, cette réplication ne
peut pas être exécutée et nous allons obtenir l’erreur 8452.
Cas 2 : le NC est supprimé sur src DC repadmin /replicate <dest DC> <src DC> <the NC> lorsque nous appelons ,
<src DC> il ne s’agit donc pas d’une source de réplication valide. Nous allons donc voir l’erreur 8452.
DCDIAG
La showrepl commande (ou showreps ) signale l’état repadmin de réplication de chaque dc source à partir
duquel le dc de destination possède un objet de connexion entrante. Le test de réplications de dcdiag vérifie la
réplication à temps entre les DCS. Si l’erreur 8452 repadmin /showrepl dcdiag /test:replications se trouve
dans ou signale, la raison est que le NC répliqué est supprimé sur le DC source lors de la dernière réplication.
Événement de réplication NTDS 1586
L’événement de réplication NTDS 1586 est généré dans un environnement de domaine mixte qui contient des
Windows NT 4.0 et des DCS Active Directory. Dans cet environnement de domaine mixte, les contrôleurs de
domaine Active Directory se répliquent entre eux à l’aide du protocole de réplication DS, tandis que le PDC
Active Directory réplique sur les bdCs netlogon NT4 à l’aide du protocole de réplication hérité. Dans ce cas, le
titulaire du rôle FSMO PDC Active Directory est le point unique pour la réplication vers les BDC NT4 dans un
domaine commun. Le PDC tient à jour un point de contrôle pour chaque BDC représentant la modification
répliquée la plus récente. Si le rôle FSMO PDC est transféré vers un autre dc Active Directory dans le domaine,
les informations sur chaque point de contrôle BDC individuel doivent être répliquées vers le nouveau rôle FSMO
PDC. Ainsi, le nouveau titulaire du rôle FSMO PDC doit avoir une relation de réplication directe avec l’ancien
titulaire du rôle FSMO PDC. Si le nouveau PDC ne se réplique pas directement avec l’ancien PDC (autrement dit,
sur le nouveau PDC, il n’y a pas de lien de réplica à partir de l’ancien PDC), nous allons voir l’erreur 8452 dans
l’événement 1586.
Rétrogradation
Il existe un autre scénario dans DRAERR_NoReplica erreur sera renvoyée. Lorsque nous rétrogradons un dc,
il utilise le localisateur de dc pour trouver un dc dans le cas où répliquer les modifications locales. Si le dc trouvé
ne se réplique pas directement avec le dc supprimé, DRAERR_NoReplica est renvoyé et le localisateur de DC
est appelé pour trouver un DC de destination. Dans ce scénario, l’erreur n’est pas enregistrée et n’est donc pas
observée.
Liens connexes
Fonctionnement du modèle de réplication Active Directory
RepsFrom
Erreur de réplication Active Directory 8453 : l’accès
à la réplication a été refusé
Cet article explique comment résoudre un problème d’échec de la réplication Active Directory et génère l’erreur
8453 : l’accès à la réplication a été refusé.
NOTE
Résumé
Les causes principales de cette erreur 8453 sont les suivantes :
Le contrôleur de domaine de destination n’a pas les autorisations requises pour répliquer le
contexte/partition d’attribution de noms.
L’administrateur qui a démarré manuellement la réplication n’est pas autorisé à le faire.
NOTE
Cette condition n’affecte pas la réplication périodique ou programmée.
Cause principale
Pour une période ou une réplication programmée, si le contrôleur de domaine de destination est un contrôleur
de domaine en lecture seule ( RODC) :
Le groupe de sécurité contrôleurs de domaine Enterprise Read-Only n’a pas d’autorisations réplication des
changements de répertoire à la racine du contexte d’appellation (NC) pour la partition qui ne se réplique pas et
renvoie l’erreur 8453.
Solution supérieure
Sur chaque NC que les CONTRÔLEURs de contrôle d’accès ne répliquent pas et qui renvoie l’erreur 8453,
accordez des autorisations réplication des changements de répertoire au groupe de sécurité Contrôleurs de
domaine en lecture seule du domaine racine de la forêt Enterprise.
Exemple :
Un rodc ne childdc2.child.contoso.com réplique pas la contoso.com partition et renvoie l’erreur 8453. Pour
résoudre ce problème, suivez les étapes suivantes :
1. Ouvrez ADSIEDIT.msc sur un contrôleur contoso.com de domaine.
2. Ouvrez une connexion au domaine contoso.com NC (contexte d’attribution de noms par défaut).
3. Ouvrez les propriétés de dc=contoso,dc=com NC , puis sélectionnez l’onglet Sécurité.
4. Sélectionnez Ajouter , puis entrez l’entrée suivante dans la zone de texte :
Contoso\Enterprise Read-Only domain controllers
NOTE
Ce groupe existe uniquement dans le domaine racine de la forêt.
5. Sélectionnez Vérifier les noms , puis OK .

6. Dans la boîte de dialogue Autorisations Enterprise Read-Only contrôleurs de domaine, cochez
les cases Autoriser automatiquement :
Lecture
Lire les stratégies de verrouillage & mot de passe de domaine
Lire les autres paramètres de domaine
7. Sélectionnez la zone Autoriser en de côté réplication des modifications de réper toire , puis
sélectionnez OK .
Si ces étapes ne résolvent pas le problème, consultez le reste de cet article.
Symptômes
Lorsque ce problème se produit, vous présentez un ou plusieurs des symptômes suivants :
Le test de réplication DCDIAG ( DCDIAG /TEST:NCSecDesc ) signale que le contrôleur de domaine testé a
échoué aux réplications de test et qu’il présente l’état 8453 : L’accès à la réplication a été refusé :

[Replications Check,<destination domain controller] A recent replication attempt failed:
From <source DC> to <Destination DC
Naming Context: <DN path of failing directory partition>
Replication access was denied.
%#% failures have occurred since the last success.
The machine account for the destination <destination DC>.
is not configured properly.
Check the userAccountControl field.
Kerberos Error.
The machine account is not present, or does not match on the.
destination, source or KDC servers.
Verify domain partition of KDC is in sync with rest of enterprise.
The tool repadmin/syncall can be used for this purpose.
......................... <DC tested by DCDIAG> failed test Replications
Le test DCDIAG NCSecDesc ( DCDIAG /TEST:NCSecDes ) signale que le contrôleur de domaine qui a été testé
par DCDIAG a échoué au test NCSecDec et qu’une ou plusieurs autorisations sont manquantes sur la
tête NC d’une ou plusieurs partitions d’annuaire sur le contrôleur de domaine testé qui a été testé par
DCDIAG :
Starting test: NCSecDesc
Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have
Replicating Directory Changes <- List of missing access
Replication Synchronization <- rights required for each Manage
Replication Topology <- security group could vary
Replicating Directory Changes In Filtered Set <- depending in missing
access rights for the naming context: <- right in your environment
DC=contoso,DC=com
Error CONTOSO\Domain Controllers doesn't have
Replicating Directory Changes All
access rights for the naming context:
DC=contoso,DC=com
Error CONTOSO\Enterprise Read-Only Domain Controllers doesn't have
Replicating Directory Changes
access rights for the naming context:
DC=contoso,DC=com
......................... CONTOSO-DC2 failed test NCSecDesc
Le test DCDIAG MachineAccount ( DCDIAG /TEST:MachineAccount ) signale que le contrôleur de domaine qui
a été testé par DCDIAG a échoué au test MachineAccount , car les indicateurs
SERVER_TRUST_ACCOUNT ou TRUSTED_FOR_DELEGATION sont manquants dans l’attribut
UserAccountControl sur le compte d’ordinateur des contrôleurs de domaine :
Starting test: MachineAccount

The account CONTOSO-DC2 is not trusted for delegation . It cannot
replicate.
The account CONTOSO-DC2 is not a DC account. It cannot replicate.
Warning: Attribute userAccountControl of CONTOSO-DC2 is:
0x288 = ( HOMEDIR_REQUIRED | ENCRYPTED_TEXT_PASSWORD_ALLOWED | NORMAL_ACCOUNT )
Typical setting for a DC is
0x82000 = ( SERVER_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION )
This may be affecting replication?
......................... CONTOSO-DC2 failed test MachineAccount
Le test du journal des événements du KCC DCDIAG indique l’équivalent hexadécimal de l’événement
Microsoft-Windows-ActiveDirectory_DomainService 2896 :
B50 hex = 2 896 décimal. Cette erreur peut être consignée toutes les 60 secondes sur le contrôleur de
domaine maître de l’infrastructure.
Starting test: KccEvent

The KCC Event log test
An error event occurred. EventID: 0xC0000B50
Time Generated: 06/25/2010 07:45:07
Event String:
A client made a DirSync LDAP request for a directory partition. Access was denied due to the
following error.
Directory partition:
<DN path of directory partition>
Error value:
8453 Replication access was denied.
User Action
The client may not have access for this request. If the client requires it, they should be assigned
the control access right "Replicating Directory Changes" on the directory partition in question.
REPADMIN.EXE signale qu’une tentative de réplication a échoué et a renvoyé un état 8453.

Les commandes REPADMIN qui indiquent généralement l’état 8453 incluent, mais ne sont pas limitées
aux éléments suivants.
REPADMIN /KCC
REPADMIN /REHOST
REPADMIN /REPLICATE
REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SHOWUTDVEC
REPADMIN /SYNCALL
Voici un exemple de sortie de l’affichage de la réplication entrante de

REPADMIN /SHOWREPS
CONTOSO-DC2 vers CONTOSO-DC1 qui a échoué et qui a refusé l’accès à la réplication :
DSA Options: IS_GC
DSA object GUID:
DSA invocationID:
DC=contoso,DC=com
Replication access was denied.
La commande répliquer maintenant dans les sites et services Active Directory (DSSITE). MSC) renvoie
une erreur d’accès à la réplication refusée.
Si vous cliquez avec le bouton droit sur l’objet de connexion à partir d’un contrôleur de domaine source,
la sélection de la réplication échoue maintenant. Une erreur d’accès à la réplication a été refusée .
Le message d’erreur suivant s’affiche :
Dialog title text: Replicate Now

Dialog message text: The following error occurred during the attempt to synchronize naming context
<%directory partition name%> from Domain Controller <Source DC> to Domain Controller <Destination
DC>:
Replication access was denied
The operation will not continue

Buttons in Dialog: OK
Les événements NTDS KCC, NTDS General ou Microsoft-Windows-ActiveDirectory_DomainService dont
l’état est 8453 sont enregistrés dans le journal des événements AD DS (Active Directory Directive
Services).
Les événements Active Directory qui indiquent généralement l’état 8453 incluent, sans s’y limiter, les
événements suivants :
Microsoft-Windows- 1699 Ce service d’annuaire n’a pas pu

ActiveDirectory_DomainService récupérer les modifications demandées
pour la partition d’annuaire suivante.
Par conséquent, il n’a pas pu envoyer
de demandes de modification au
service d’annuaire à l’adresse réseau
suivante.
Microsoft-Windows- 2896 Un client a effectué une demande

ActiveDirectory_DomainService LDAP DirSync pour une partition
d’annuaire. L’accès a été refusé en
raison de l’erreur suivante.

communiquer avec le catalogue global
suivant et les tentatives ont échoué.
NTDS KCC 1265 Tentative d’établissement d’un lien de

réplication avec des paramètres
Partition : <partition DN path>
DN DSA source : <DN of source DC
NTDS Settings object>
Adresse DSA source : <source DCs
fully qualified CNAME>
Transport inters site (le caser) : <dn
path>
a échoué avec l’état suivant :
NTDS KCC 1925 La tentative d’établissement d’un lien

de réplication pour la partition de
répertoire accessible en texte suivante
a échoué.
Cause
L’erreur 8453 (accès à la réplication a été refusé) a plusieurs causes premières, notamment :
L’attribut UserAccountControl sur le compte d’ordinateur du contrôleur de domaine de destination
est absent de l’un des indicateurs suivants :
SERVER_TRUST_ACCOUNT ou TRUSTED_FOR_DELEGATION
Les autorisations par défaut n’existent pas sur une ou plusieurs partitions d’annuaire pour permettre la
réplication programmée dans le contexte de sécurité du système d’exploitation.
Les autorisations par défaut ou personnalisées n’existent pas sur une ou plusieurs partitions d’annuaire
pour permettre aux utilisateurs de déclencher une réplication ad hoc ou immédiate à l’aide de DSSITE.
MSC réplique maintenant , repadmin /replicate ou repadmin /syncall des commandes similaires.
Les autorisations requises pour déclencher la réplication ad hoc sont correctement définies sur les
partitions d’annuaire pertinentes. Toutefois, l’utilisateur n’est membre d’aucun groupe de sécurité qui a
reçu l’autorisation de modification du répertoire de réplication.
L’utilisateur qui déclenche la réplication ad hoc est membre des groupes de sécurité requis, et ces
groupes de sécurité ont reçu l’autorisation Répliquer les changements de réper toire . Toutefois,
l’appartenance au groupe qui accorde l’autorisation réplication des changements d’annuaire est
supprimée du jeton de sécurité de l’utilisateur par la fonctionnalité de jeton d’accès utilisateur partagé
Contrôle de compte d’utilisateur. Cette fonctionnalité a été introduite dans Windows Vista et Windows
Server 2008.
NOTE
Ne confondez pas la fonctionnalité de sécurité du jeton fractioné Contrôle de compte d’utilisateur introduite dans
Vista et Windows Server 2008 avec l’attribut UserAccountControl défini sur les comptes d’ordinateur de rôle de
contrôleur de domaine stockés par le service Active Directory.
Si le contrôleur de domaine de destination est un contrôleur de domaine de domaine de destination,

RODCPREP n’a pas été exécuté dans les domaines qui hébergent actuellement des contrôleurs de
domaine en lecture seule, ou le groupe contrôleurs de domaine Enterprise Read-Only ne dispose pas des
autorisations Répliquer les changements de répertoire pour la partition qui n’est pas répliquée.
Les DCS qui exécutent de nouvelles versions de système d’exploitation ont été ajoutés à une forêt
existante où Office Communication Server a été installé.
Vous avez des instances LDS (Lightweight Directory Services). Et l’objet Paramètres NTDS pour les
instances affectées est manquant dans le conteneur de configuration LDS. Par exemple, vous voyez
l’entrée suivante :
CN=NtDs Paramètres,CN=Server1$ADAMINST1,CN=Server,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,CN={A560B9B8-6B05-4000-9A1F-9A853DB6615A}
Les erreurs et événements Active Directory, tels que ceux mentionnés dans la section Symptômes , peuvent
également se produire et générer un message d’erreur 5 (Accès refusé).
Les étapes de l’erreur 5 ou de l’erreur 8453 mentionnées dans la section Résolution ne résoudra pas les échecs
de réplication sur les ordinateurs qui échouent actuellement à la réplication et génèrent l’autre message d’erreur.
Les causes principales courantes de l’échec des opérations Active Directory qui génèrent l’erreur 5 messages
Décalage de temps excessif
Fragmentation des paquets Kerberos au format UDP par des appareils intermédiaires sur le réseau
Accès manquant à cet ordinateur à par tir des droits réseau .
Canaux sécurisés ou trusts intra-domaine rompus
CrashOnAuditFail = 2 entrées dans le Registre
Résolution
Pour résoudre ce problème, utilisez les méthodes suivantes.
Exécutez une vérification de l’état à l’aide de DCDIAG + DCDIAG /test:CheckSecurityError
1. Exécutez DCDIAG sur le dc de destination signalant l’erreur ou l’événement 8453.
2. Exécutez DCDIAG sur le contrôleur de domaine source sur lequel le contrôleur de domaine de destination
rapporte l’erreur ou l’événement 8453.
3. Exécuter sur DCDIAG /test:CheckSecurityError le contrôleur de domaine de destination.
4. S’exécute DCDIAG /test:CheckSecurityError sur le dc source.
Corriger un UserAccountControl non valide
L’attribut UserAccountControl inclut un masque de bits qui définit les fonctionnalités et l’état d’un compte
d’utilisateur ou d’ordinateur. Pour plus d’informations sur les indicateurs UserAccountControl , consultez
l’attribut User-Account-Control.
La valeur d’attribut UserAccountControl type pour un compte d’ordinateur DC accessible en écriture
(complet_) est_ 532 480 décimales ou 82 000 hexadécimals. Les valeurs UserAccountControl pour un
compte d’ordinateur dc peuvent varier, mais doivent contenir les indicateurs SERVER_TRUST_ACCOUNT et
TRUSTED_FOR_DELEGATION , comme indiqué dans le tableau suivant.
IN DIC AT EUR DE P RO P RIÉT É VA L EUR H EX VA L EUR DÉC IM A L E
SERVER_TRUST_ACCOUNT 0x2000 8192
TRUSTED_FOR_DELEGATION 0x80000 524288
Valeur UserAccountControl 0x82000 532480
La valeur d’attribut UserAccountControl type pour un compte d’ordinateur contrôleur de domaine en lecture
seule est 83890176 décimale ou 5001000 hexadécimal.
IN DIC AT EUR DE P RO P RIÉT É VA L EUR H EX VA L EUR DÉC IM A L E
WORKSTATION_TRUST_ACCOUNT 0x1000 4096
TRUSTED_TO_AUTHENTICATE_FO 0x1000000 16777216

R_DELEGATION
PARTIAL_SECRETS_ACCOUNT 0X4000000 67108864
Valeur UserAccountControl type 0x5001000 83890176

pour RODC
L’attribut UserAccountControl sur le contrôleur de domaine de destination n’a pas

SERVER_TRUST_ACCOUNT’indicateur
Si le test DCDIAG MachineAccount échoue et renvoie un message d’erreur MachineAcccount qui a
échoué et que l’attribut UserAccountControl sur le contrôleur de domaine testé ne porte pas
l’indicateur SERVER_TRUST_ACCOUNT , ajoutez l’indicateur manquant dans la copie Active Directory
du contrôleur de domaine testé.
1. Démarrez ADSIEDIT. MSC sur la console du contrôleur de domaine qui manque
l’SERVER_TRUST_ACCOUNT comme indiqué par DCDIAG.
2. Cliquez avec le bouton droit sur ADSIEDIT dans le volet supérieur gauche d’ADSIEDIT. MSC, puis
sélectionnez Se connecter .
3. Dans la boîte de dialogue Paramètres connexion, cliquez sur Sélectionner un contexte d’attribution
de noms connu, puis sélectionnez Contexte d’attribution de noms par défaut (par tition de
domaine du compte d’ordinateur).
4. Cliquez sur Sélectionner ou tapez un domaine ou un ser veur . Et sélectionnez le nom du
contrôleur de domaine défaillant dans DCDIAG.
6. Dans le contexte d’attribution de noms de domaine, recherchez et cliquez avec le bouton droit sur le
compte d’ordinateur du contrôleur de domaine, puis sélectionnez Propriétés .
7. Double-cliquez sur l’attribut UserAccountControl , puis enregistrez sa valeur décimale.
8. Démarrez Windows calculatrice en mode programmeur (Windows Server 2008 et versions
ultérieures).
9. Entrez la valeur décimale de UserAccountControl . Convertissez la valeur décimale en son équivalent
hexadécimal, ajoutez 0x80000 à la valeur existante, puis appuyez sur le signe égal (=).
10. Convertissez la valeur UserAccountContorl nouvellement calculée en son équivalent décimal.
11. Entrez la nouvelle valeur décimale de la calculatrice Windows à l’attribut UserAccountControl dans
ADSIEDIT. MSC.
12. Sélectionnez OK deux fois pour enregistrer.
L’attribut UserAccountControl sur le contrôleur de domaine de destination ne por te pas
l’ TRUSTED_FOR_DELEGATION de domaine
Si le test DCDIAG MachineAccount renvoie un message d’erreur MachineAcccount qui a échoué et que
l’attribut UserAccountControl sur le contrôleur de domaine testé ne porte pas l’indicateur TRUSTED
_FOR_DELEGATION , ajoutez l’indicateur manquant dans la copie Active Directory du contrôleur de
domaine testé.
1. Démarrez La DSA (Active Directory Users and Computers). MSC) sur la console du contrôleur de
domaine qui a été testé par DCDIAG.
2. Cliquez avec le bouton droit sur le compte d’ordinateur du contrôleur de domaine.
3. Sélectionnez l’onglet Délégation.
4. Sur le compte de l’ordinateur du contrôleur de domaine, sélectionnez l’option De confiance de cet
ordinateur pour la délégation à n’importe quel ser vice (Kerberos uniquement).
Corriger les descripteurs de sécurité par défaut non valides

Les opérations Active Directory ont lieu dans le contexte de sécurité du compte qui a démarré l’opération. Les
autorisations par défaut sur les partitions Active Directory autorisent les opérations suivantes :
Les membres du groupe Administrateurs Enterprise peuvent démarrer une réplication ad hoc entre
n’importe quel contrôleur de domaine dans n’importe quel domaine de la même forêt.
Les membres du groupe Administrateurs intégrés peuvent démarrer une réplication ad hoc entre les
contrôleurs de domaine dans le même domaine.
Les contrôleurs de domaine dans la même forêt peuvent démarrer la réplication à l’aide de la notification de
modification ou de la planification de la réplication.
Les autorisations par défaut sur les partitions Active Directory n’autorisent pas les opérations suivantes par
défaut :
Les membres du groupe Administrateurs intégrés dans un domaine ne peuvent pas démarrer la réplication
ad hoc vers les contrôleurs de domaine de ce domaine à partir de contrôleurs de domaine dans différents
domaines.
Les utilisateurs qui ne sont pas membres du groupe Administrateurs intégrés ne peuvent pas démarrer la
réplication ad hoc à partir d’un autre contrôleur de domaine dans le même domaine ou forêt.
Par conception, ces opérations échouent tant que les autorisations par défaut ou les appartenances aux groupes
ne sont pas modifiées.
Les autorisations sont définies en haut de chaque partition de répertoire (en-tête NC) et sont héritées dans
l’arborescence de partition. Vérifiez que les groupes explicites (groupes dont l’utilisateur est directement
membre) et les groupes implicites (groupes dont les groupes explicites sont imbrmbrés) ont les autorisations
requises. Vérifiez également que les autorisations de refus attribuées à des groupes implicites ou explicites ne
prévalent pas sur les autorisations requises. Pour plus d’informations sur les partitions d’annuaire par défaut,
voir Sécurité par défaut de la partition du répertoire de configuration.
Vérifier que les autorisations par défaut existent en haut de chaque par tition d’annuaire qui
échoue et que l’accès à la réplication a été refusé
Si la réplication ad hoc échoue entre les contrôleurs de domaine dans différents domaines ou entre les
contrôleurs de domaine dans le même domaine pour les administrateurs non-domaines, consultez la
section Accorder des autorisations d’administrateurs autres que des domaines.
Si la réplication ad hoc échoue pour les membres du groupe Administrateurs Enterprise, concentrez-vous
sur les autorisations d’en-tête NC accordées au groupe Administrateurs Enterprise.
Si la réplication ad hoc échoue pour les membres d’un groupe Administrateurs de domaine, concentrez-
vous sur les autorisations accordées au groupe de sécurité Administrateurs intégré.
Si une réplication programmée démarrée par des contrôleurs de domaine dans une forêt échoue et
retourne l’erreur 8453, concentrez-vous sur les autorisations pour les groupes de sécurité suivants :
Enterprise de domaine
Enterprise Read-Only de domaine
Si une réplication programmée est démarrée par des contrôleurs de domaine sur un contrôleur de
domaine en lecture seule et retourne l’erreur 8453, vérifiez que le groupe de sécurité contrôleurs
de domaine Enterprise Read-Only se voit accorder l’accès requis sur le responsable NC de chaque
partition d’annuaire.
Le tableau suivant indique l’autorisation par défaut définie sur le schéma, la configuration, le
domaine et les applications DNS par différentes versions Windows suivantes.
DA C L REQ UIS SUR C H A Q UE PA RT IT IO N D’A N N UA IRE W IN DO W S SERVER 2008 ET ULT ÉRIEUR
Gérer la topologie de réplication X
Réplication des modifications de répertoire X
Synchronisation de la réplication X
Réplication de tous les changements de répertoire X
Réplication des modifications dans l’ensemble de X

filtres
NOTE
Le test NCSecDesc DCDIAG peut signaler des erreurs fausses positives lorsqu’il est exécuté dans des
environnements avec des versions système mixtes.
La commande DSACLS peut être utilisée pour vider les autorisations sur une partition d’annuaire
donnée à l’aide de la syntaxe suivante :
DSACLS <DN path of directory partition>
Par exemple, utilisez la commande suivante :
C:\>dsacls dc=contoso,dc=com
La commande peut être ciblée sur un contrôleur de domaine distant à l’aide de la syntaxe :
c:\>dsacls \\contoso-dc2\dc=contoso,dc=com
Soyez certains que les autorisations DENY sur les têtes NC suppriment les autorisations pour les
groupes dont l’utilisateur défaillant est un membre direct ou imbrmbré.
Ajouter les autorisations requises manquantes
Utilisez l’éditeur ACL Active Directory dans ADSIEDIT. MSC pour ajouter le DACLS manquant.
Accorder des autorisations d’administrateurs autres que des domaines
Accordez aux administrateurs non-domaines les autorisations suivantes :
Pour répliquer entre les contrôleurs de domaine dans le même domaine pour les administrateurs non-
entreprise
Pour répliquer entre les contrôleurs de domaine dans différents domaines
Les autorisations par défaut sur les partitions Active Directory n’autorisent pas les opérations suivantes :
Les membres du groupe Administrateurs intégrés dans un domaine ne peuvent pas initier de réplication ad
hoc à partir de contrôleurs de domaine dans différents domaines.
Utilisateurs qui ne sont pas membres du groupe d’administrateurs de domaine intégré pour lancer une
réplication ad hoc entre contrôleurs de domaine dans le même domaine ou un domaine différent.
Ces opérations échouent tant que les autorisations sur les partitions d’annuaire ne sont pas modifiées.
Pour résoudre ce problème, utilisez l’une des méthodes suivantes :
Ajoutez des utilisateurs à des groupes existants qui ont déjà reçu les autorisations requises pour répliquer
les partitions d’annuaire. (Ajoutez les administrateurs de domaine pour la réplication dans le même
domaine ou le groupe Administrateurs Enterprise pour déclencher une réplication ad hoc entre différents
domaines.)
Créez votre propre groupe, accordez-lui les autorisations requises sur les partitions d’annuaire dans toute
la forêt, puis ajoutez des utilisateurs à ces groupes.
Pour plus d’informations, voir KB303972. Accordez au groupe de sécurité en question les mêmes autorisations
répertoriées dans le tableau de la section Corriger les descripteurs de sécurité par défaut non valides .
Vérifier l’appartenance à un groupe dans les groupes de sécurité requis
Une fois que les groupes de sécurité corrects ont reçu les autorisations requises sur les partitions d’annuaire,
vérifiez que les utilisateurs qui démarrent la réplication sont membres de groupes de sécurité directs ou
imbrités qui se sont vus accorder des autorisations de réplication. Pour ce faire, procédez comme suit :
1. Connectez-vous à l’aide du compte d’utilisateur dans lequel la réplication ad hoc échoue et l’accès à la
réplication a été refusé .
2. À l’invite de commandes, exécutez la commande suivante :
WHOAMI /ALL
3. Vérifiez l’appartenance aux groupes de sécurité qui ont reçu les autorisations de modification de
répertoire de réplication sur les partitions d’annuaire pertinentes.
Si l’utilisateur a été ajouté au groupe autorisé qui a été modifié après la dernière connexion utilisateur,
connectez-vous une deuxième fois, puis exécutez à nouveau la WHOAMI /ALL commande.
Si cette commande n’affiche toujours pas l’appartenance aux groupes de sécurité attendus, ouvrez une
fenêtre d’invite de commandes avec élévation de niveaux sur l’ordinateur local et WHOAMI /ALL exécutez-
la à l’invite de commandes.
WHOAMI /ALL Si l’appartenance au groupe diffère entre la sortie générée par des invites de commandes
avec élévation de niveau élevé et non élevée, voir Lorsque vous exécutez une requête LDAP sur un
contrôleur de domaine Windows Server 2008, vous obtenez une liste d’attributs partielle.
4. Vérifiez que les appartenances de groupe imbrmbrées attendues existent.
Si un utilisateur dispose des autorisations pour exécuter la réplication ad hoc en tant que membre du
groupe imbrmbré, qui est membre du groupe auquel des autorisations de réplication ont été accordées
directement, vérifiez la chaîne d’appartenance au groupe imbrmbrée. Nous avons constaté des échecs de
réplication Active Directory ad hoc, car les groupes Administrateurs de domaine et Administrateurs de
Enterprise ont été supprimés des groupes Administrateurs intégrés.
Réplication RODC
Si la réplication initiée par l’ordinateur échoue sur les CONTRÔLEURS de domaine, ADPREP /RODCPREP vérifiez
que vous avez exécuté et que le groupe contrôleur de domaine Enterprise Read-Only se voir accorder le droit
Répliquer les changements de répertoire sur chaque en-tête NC.
Objet de Paramètres NTDS manquant pour le serveur LDS
Dans les services LDS (Active Directory Lightweight Directory Services), il est possible de supprimer l’objet sans
nettoyage des métadonnées dans DBDSUTIL. Cela peut provoquer ce problème. Pour restaurer l’instance dans le
jeu de configuration, vous devez désinstaller l’instance LDS sur les serveurs affectés, puis exécuter l’Assistant
Configuration d’ADAM.
NOTE
Si vous avez ajouté la prise en charge LDAPS pour l’instance, vous devez configurer à nouveau le certificat dans le
magasin de services, car la désinstallation de l’instance supprime également l’instance de service.
Résoudre l’erreur de réplication Active Directory
8614
Cet article décrit les étapes à suivre pour résoudre l’erreur de réplication Active Directory 8614.
NOTE
Symptômes
1. DCDIAG signale que le test réplications Active Directory a échoué avec le code d’état d’erreur 8614 :
Active Directory ne peut pas répliquer avec ce serveur car le temps depuis la dernière réplication avec ce
serveur a dépassé la durée de vie de tombstone.
Testing server: <site name><destination dc name>

* Replications Check
[Replications Check,<destination DC name] A recent replication attempt failed:
Active Directory cannot replicate with this server because the time since the last replication with
this server has exceeded the tombstone lifetime.
3 failures have occurred since the last success.
2. REPADMIN.EXE signale que la dernière tentative de réplication a échoué avec l’état 8614. Les commandes
REPADMIN qui mentionnent généralement l’état 8614 sont les suivantes :
REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL
Un exemple de sortie REPADMIN /SHOWREPS de la représentation de la réplication entrante de CONTOSO-
DC2 vers CONTOSO-DC1 ayant échoué avec l’accès à la réplication a été refusé est illustré ci-dessous :
efault-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC
DSA object GUID:
DSA invocationID:
DC=contoso,DC=com
DSA object GUID:
Last attempt @ <date> <time> failed, result 8614(0x21a6):
The Active Directory cannot replicate with this server because the time since the last replication
with this server has exceeded the tombstone lifetime.

les cinq états sont enregistrés dans le journal des événements du service d’annuaire.
SO URC E DE L’ÉVÉN EM EN T ID C H A ÎN E D’ÉVÉN EM EN T

4. L’événement de réplication NTDS 2042 peut être enregistré dans le journal des événements du service
d’annuaire :
Event Type: Error
Event ID: 2042
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: <name of DC that logged event>
Description:
It has been too long since this machine last replicated with the named source
machine. The time between replications with this source has exceeded the tombstone
lifetime. Replication has been stopped with this source.
The reason that replication is not allowed to continue is that the two machine's views of deleted
objects may now be different. The source machine may still have copies of objects that have been
deleted (and garbage collected) on this machine. If they were allowed to replicate, the source
machine might return objects which have already been deleted.
Time of last successful replication: YYYY-MM-DD HH:MM:SS

Invocation ID of source: <32 character GUID for source DC>
Name of source: <fully qualified cname record of source DC>
Tombstone lifetime (days): <current TSL value. Default = 60 or 180 days>
The replication operation has failed.
User Action:
Determine which of the two machines was disconnected from the forest and is now out of date. You have
three options:
1. Demote or reinstall the machine(s) that were disconnected.

2. Use the repadmin /removelingeringobjects tool to remove inconsistent deleted objects and then
resume replication.
3. Resume replication. Inconsistent deleted objects may be introduced. You can continue replication
by using the following registry key. Once the systems replicate once, it's recommended that you
remove the key to reinstate the protection.
5. La commande Répliquer maintenant dans sites et services Active Directory renvoie le message
suivant :
Active Directory ne peut pas répliquer avec ce serveur, car le temps depuis la dernière réplication
avec ce serveur a dépassé la durée de vie de tombstone.
Cliquez avec le bouton droit sur l’objet de connexion à partir d’un dc source et choisissez répliquer
maintenant dans Active Directory Sites and Services (DSSITE). MSC) échoue. Vous recevez le message
suivant :
Le texte du message d’erreur à l’écran est le suivant :

Texte du message de boîte de dialogue : l’erreur suivante s’est produite lors de la tentative de
synchronisation du contexte d’attribution de noms <%nom de partition d’annuaire%> <Source DC> du
contrôleur de domaine au contrôleur de domaine <Destination DC>:
Cause
Les contrôleurs de domaine Active Directory peuvent être réplication multi-maîtres. Tout contrôleur de domaine
qui contient une partition accessible en création peut provenir d’une création, d’une modification ou d’une
suppression d’un objet ou d’un attribut (valeur). La connaissance de la suppression d’objet/d’attribut persiste
pendant le nombre de jours de la durée de vie de tombstone. (Voir les informations sur les objets en attente
dans Windows Server Active Directory forêt.
Active Directory nécessite une réplication de bout en bout de tous les titulaires de partition pour répliquer de
manière transitive toutes les suppressions d’origine des partitions d’annuaire sur tous les titulaires de partition.
L’échec de la réplication entrante d’une partition d’annuaire en un nombre de jours TSL de déploiement entraîne
l’attente d’objets. Un objet en attente est un objet qui a été intentionnellement supprimé par au moins un dc,
mais qui existe de manière incorrecte sur les DCS de destination qui n’a pas pu répliquer les connaissances
temporaires de toutes les suppressions uniques.
L’erreur 8614 est un exemple de logique ajoutée dans les contrôleurs de domaine qui exécutent Windows
Server 2003 ou une version ultérieure. Il met en quarantaine la répartition des objets en attente et identifie les
échecs de réplication à long terme qui provoquent des partitions d’annuaire incohérentes.
Les causes premières de l’erreur 8614 et de l’événement de réplication NTDS 2042 sont les suivantes :
1. Le dc de destination qui enregistre l’erreur 8614 n’a pas réussi à répliquer une partition d’annuaire
entrante à partir d’un ou plusieurs DCS sources pour le nombre de jours de durée de vie de tombstone.
2. L’heure système sur le dc de destination a déplacé ou a fait un saut dans la durée de vie de tombstone un
ou plusieurs nombres de jours à l’avenir depuis la dernière réplication réussie. Il donne l’apparence au
moteur de réplication que le dc de destination n’a pas réussi à répliquer une partition d’annuaire entrante
pour la durée de vie de tombstone écoulée en nombre de jours.
Des sauts de temps peuvent se produire lorsque les conditions suivantes sont vraies :
Un dc de destination réplique correctement les trafics entrants, adopte un TSL d’heure système
mauvais ou plus de jours à l’avenir.
Le dc de destination tente ensuite de répliquer entrant à partir d’une source qui a été répliquée pour la
dernière fois à partir de TSL ou plus de jours dans le passé.
Ou
Le temps passe de l’heure actuelle à une durée de vie de date/heure tombstone ou plus de jours dans le
passé, réplications entrantes réussies. Il tente ensuite de répliquer le trafic entrant après avoir adopté le
TSL de temps ou plus de jours à l’avenir.
Fondamentalement, la cause et la résolution de l’erreur de réplication 8614 s’appliquent de la même manière à
la cause et à la résolution de l’événement de réplication NTDS 2042.
Résolution
NOTE
Il existe deux plans d’action pour récupérer les contrôleurs de domaine Active Directory qui enregistrent l’état d’erreur
8614 ou l’événement de réplication NTDS 2042. Vous pouvez soit forcer le rétrogradation du contrôleur de domaine, soit
utiliser le plan d’action ci-dessous qui indique : Rechercher les correctifs requis, rechercher des sauts de temps, rechercher
des objets en attente et les supprimer s’ils sont présents, supprimer les mises en quarantaine de réplication, résoudre les
échecs de réplication, puis remettre le contrôleur de domaine en service. La rétrogradation de force de ces DCS peut être
plus facile et plus rapide, mais peut entraîner la perte de mises à jour d’origine (c’est-à-dire, la perte de données) sur le
contrôleur de domaine rétrogradé de force. Active Directory récupère correctement à partir de cette condition en suivant
les étapes ci-dessous. Sélectionnez la meilleure solution pour votre scénario. Ne supposez pas qu’une rétrogradation de
force est la seule solution utilisable, en particulier lorsque l’échec de la réplication est facile à résoudre ou qu’il est externe
à Active Directory.
1. Recherchez les valeurs non par valeur par valeur de durée de vie de tombstone.
Par défaut, la durée de vie de tombstone est de 60 ou 180 jours, selon la version de Windows déployée
dans votre forêt. Le support Microsoft voit régulièrement les DCS qui ont échoué à la réplication entrante
pendant ces périodes. Il est également possible que la durée de vie de tombstone ait été configurée sur
une courte période, par exemple deux jours. Si c’est le cas, les DCS qui n’ont pas été répliquées entrantes
pendant, par exemple, cinq jours échouent au test suivant :
Tous les DCS doivent être répliqués avec un nombre de jours TSL de déploiement
À repadmin /showattr utiliser pour voir si une valeur non parefault pour l’attribut TombstoneLifetime a
été configurée.
repadmin /showattr "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<forest root

domain>,DC=<top level domain>"
Si l’attribut n’est pas présent dans la showattr sortie, une valeur interne par défaut est utilisée.
2. Recherchez les DCS dont la réplication entrante a échoué pour le nombre de jours TSL.
Exécutez repadmin /showrepl * /csv l’opération en utilisant Excel comme indiqué dans la section Vérifier
la réplication réussie vers un contrôleur de domaine. Tez la sortie de replsum dans Excel sur la dernière
colonne de réussite de réplication dans l’ordre du moins actuel à la date et à l’heure les plus actuelles.
3. Recherchez Windows contrôleurs de domaine RTM Server 2003.
Si l’erreur 8614 s’est produite sur un contrôleur de domaine Windows Server 2003 RTM, installez le
dernier service pack Windows Server 2003.
4. Vérifiez les sauts de temps.
Pour déterminer si un saut de temps s’est produit, vérifiez les journaux d’événements et de diagnostics (
repadmin /showreps journaux dcdiag) sur les DCS de destination qui enregistrent les erreurs 8614 pour
les timestamps suivants :
Horodatés qui ont précédé la publication d’un système d’exploitation. Par exemple, les cachets de date
Windows Server 2003 pour un système d’exploitation publié dans Windows Server 2008.
Horodatés qui datent avant l’installation du système d’exploitation dans votre forêt.
Horodatés à l’avenir.
Aucun événement consigné dans une plage de dates donnée.
Les équipes de support Microsoft ont vu le temps système sur les contrôleurs de domaine de production
sauter de manière incorrecte les heures, les jours, les semaines, les années et même les dizaines d’années
passées et futures.
Si l’heure système s’est trouvée incorrecte, corrigez-la. Ensuite, essayez de déterminer pourquoi le temps
a été trop long et ce qu’il est possible de faire pour éviter les temps imprécis et simplement corriger le
temps incorrect. Les domaines possibles à examiner sont les suivants :
Le PDC racine de la forêt a-t-il été configuré à l’aide d’une source de temps externe ?
Les sources de temps de référence sont-elles en ligne, disponibles sur le réseau et résolvables dans
DNS ?
Le service de temps microsoft ou tiers était-il en cours d’exécution et dans un état sans erreur ?
Les ordinateurs à rôle DC sont-ils configurés pour utiliser la hiérarchie NT5DS pour l’heure source ?
La protection de la mise à l’heure a-t-elle été décrite dans La configuration du service Windows Time
par rapport à un décalage de temps important ?
Les horloges système ont-elles de bonnes batteries et une heure précise dans le BIOS ?
Les ordinateurs hôtes et invités virtuels sont-ils configurés pour l’heure source conformément aux
recommandations des fabricants d’hébergement ?
Cet article explique comment configurer le service de temps Windows par rapport à des étapes de
documents de décalage de temps importants pour protéger les contrôleurs de domaine contre l’écoute
d’échantillons de temps non valides. Pour plus d’informations sur MaxPosPhaseCorrection et
MaxNegPhaseCorrection , Windows Time Service.
5. Recherchez et supprimez les objets en attente s’ils sont présents.
Le point de la mise en quarantaine de la réplication d’erreur 8614 consiste à vérifier la présence d’objets
en attente et à les supprimer, s’ils sont présents, dans chaque partition locale avant de définir Autoriser la
réplication avec un partenaire non fiable et endommagé sur 1 dans le Registre de la base de données de
destination, même si vous pensez que tous les DCS de destination de la forêt s’exécutent en cohérence de
réplication stricte.
La suppression d’objets en attente n’entre pas dans le cadre de cet article. Si vous souhaitez en savoir
plus, consultez les articles suivants :
Informations sur les objets en attente dans Windows Server Active Directory forêt.
ID d’événement 1388 ou 1988 : un objet en attente est détecté
Repadmin la syntaxe est présentée ici :
A IDE EN L IGN E ( W IN DO W S SERVER 2008 ET VERSIO N

SY N TA XE ULT ÉRIEURE)
c:\>repadmin /removelingeringobjects c:\>repadmin /help:removelingeringobject

<Dest_DSA_LIST> <Source DSA GUID> <NC>
[/advisory_mode]
6. Évaluer la définition d’une réplication stricte sur les DCS de destination.

La réplication en mode strict empêche la réanimatement des objets en attente sur les DCS de destination
qui ont utilisé le garbage collection pour créer, supprimer et récupérer des objets supprimés
intentionnellement.
Clé de Registre pour une réplication stricte :
Chemin d’accès : HKEY_LOCAL_MACHINE\system\ccs\services\ntds\parameters
Paramètre : cohérence de réplication stricte <- not case sensitive>
Type : reg_dword
Valeur : 0 | 1
Repadmin pour activer et désactiver la réplication stricte sur un ou plusieurs DCS, voici ce qui suit :
A IDE EN L IGN E
( W IN DO W S SERVER A C T IVER SUR TO US A C T IVER SUR TO US
2008 ET VERSIO N A C T IVER SUR UN L ES DC S DE L A L ES GC S DE L A
SY N TA XE ULT ÉRIEURE) SEUL DC F O RÊT F O RÊT
repadmin Repadmin repadmin repadmin repadmin

/regkey /help:regkey /regkey <fully /regkey * /regkey gc:
<DSA_LIST> qualified +strict +strict
<{+|-}key> computer name>
[value +strict
[/reg_sz]
]
7. Définissez autoriser la réplication avec un par tenaire non fiable et endommagé sur 1 sur le dc
8614.
Une fois les objets en attente supprimés, désactivez la mise en quarantaine de la réplication basée sur le
temps :
Méthode de Registre :
Chemin d’accès au Registre : HKEY_LOCAL_MACHINE\system\ccs\services\ntds\parameters
Paramètre du Registre : autoriser la réplication avec des partenaires <- Ne pas sensible à la cas
Valeur du Registre : 0 = ne pas autoriser, 1 = autoriser
Repadmin méthode :
A IDE EN L IGN E
( W IN DO W S SERVER A C T IVER SUR TO US A C T IVER SUR TO US
2008 ET VERSIO N A C T IVER SUR UN L ES DC S DE L A L ES GC S DE L A
SY N TA XE ULT ÉRIEURE) SEUL DC F O RÊT F O RÊT
repadmin Repadmin repadmin /regkey repadmin repadmin

/regkey /help:regkey dc01.contoso.com /regkey * /regkey GC:
<DSA_LIST> +allowDivergent +allowDivergent +allowDivergent
<{+|-}key>
[value
[/reg_sz]
]
8. Résoudre les échecs de réplication AD s’ils sont présents.

Lorsque l’état d’erreur 8614 est enregistré sur un dc de destination, les erreurs de réplication précédentes
qui ont été enregistrées dans le nombre de jours TSL précédent sont masquées.
Le fait que l’erreur 8614 a été signalée par le dc de destination ne signifie pas que la panne de réplication
réside sur la dc de destination. Au lieu de cela, la source de l’échec de réplication peut être le réseau ou la
résolution de nom DNS. Ou bien, il peut y avoir un problème avec l’un des éléments suivants :
authentification
base de données jet
topologie
moteur de réplication sur le DC source ou le DC de destination ;
Passer en revue les événements du service d’annuaire et la sortie de diagnostic (dcdiag, repadmin
journaux) générés par la dc source, par la dc de destination et par d’autres partenaires de réplication dans
le passé pour identifier l’étendue et l’état d’échec qui empêchent la réplication entre le DC de destination
et le DC source.
9. Supprimez autoriser la réplication avec un par tenaire non fiable et endommagé ou définissez
autoriser la réplication avec un par tenaire non fiable et endommagé sur 0 dans le Registre.
10. Surveillez quotidiennement la réplication Active Directory.
Surveillez quotidiennement la réplication de bout en bout dans votre forêt Active Directory à l’aide d’une
application de surveillance Active Directory. Une option peu coûteuse mais efficace consiste à exécuter
repadmin /showrepl * /csv , puis à l’Excel. Pour plus d’informations, voir Méthode 2 : surveiller la
réplication à l’aide d’une ligne de commande.
Identifiez les DCS qui approchent des échecs de réplication pour 50 % et 90 % de la durée de vie de
tombstone. Placez-les sur une liste de surveillance. À 50 % de TSL, faites une forte pression pour
résoudre les erreurs de réplication. À 90 %, envisagez de rétrograder les DCS qui provoquent des erreurs
de réplication de force si nécessaire. Pour ce faire, utilisez la dcpromo /forceremoval commande.
Là encore, les erreurs de réplication qui sont enregistrées sur un dc de destination peuvent être causées
par un problème sur :
The source DC
Dc de destination
Réseau sous-jacent
Par conséquent, essayez d’en déterminer la cause et l’endroit où se trouve la panne avant de prendre des
mesures préventives.
References
Résolution des problèmes liés aux objets répliqués (ID d’événement 1388, 1988, 2042)
Erreur de réplication Active Directory 1396 : Échec
de l’logo : le nom du compte cible est incorrect
l’erreur Win32 1396.
Symptômes
l’erreur Win32 1396 :
Échec de l’logo : le nom du compte cible est incorrect.
1. DCDIAG signale que les réplications Active Directory ont échoué avec l’erreur 1396 :
Serveur de test : <Site name><DC Name>

Contexte d’attribution de noms : CN=<DN path of naming context>
Des échecs XX se sont produits depuis le dernier succès
2. REPADMIN.EXE signale que la tentative de réplication a échoué avec l’état 1396.

REPADMIN /ADD
REPADMIN /REPLSUM*
REPADMIN /REHOST
REPADMIN /SHOWVECTOR /LATENCY
REPADMIN /SHOWREPS
REPADMIN /SHOWREPL
REPADMIN /SYNCALL
Exemple de REPADMIN /SHOWREPS sortie de la représentation de la réplication entrante de CONTOSO-DC2
vers CONTOSO-DC1 ayant échoué avec l’échec de l’accès : le nom du compte cible est une erreur
incorrecte est illustré ci-dessous :
Options DSA : IS_GC
GUID d’objet DSA : <GUID>
DSA invocationID : <invocationID>
DC=contoso,DC=com
3. La commande Répliquer maintenant dans Sites et services Active Directory renvoie l’échec de l’accès
: le nom du compte cible est incorrect .
Le fait de cliquer avec le bouton droit sur l’objet de connexion à partir d’un dc source et de choisir
répliquer échoue maintenant avec échec de connexion : le nom du compte cible est incorrect . Le
message d’erreur à l’écran s’affiche ci-dessous :
Texte du message de boîte de dialogue : L’erreur suivante s’est produite <partition DNS path> <source
DC> lors de la tentative de synchronisation du contexte d’attribution de noms du contrôleur de domaine
au contrôleur de domaine <destination DC>:
Cette opération ne se poursuit pas.
l’état 1396 sont enregistrés dans le journal des événements du service d’annuaire.
Microsoft-Windows- 1125 L’Assistant Installation des services

ActiveDirectory_DomainService de domaine Active Directory
(Dcpromo) n’a pas pu établir de
connexion avec le contrôleur de
domaine suivant.
Réplication NTDS (cet événement 1645 Active Directory n’a pas effectué
répertorie le SPN à 3 partie) d’appel de procédure distante
authentifiée (RPC) vers un autre
contrôleur de domaine, car le nom
principal de service (SPN) souhaité
pour le contrôleur de domaine de
destination n’est pas inscrit sur le
contrôleur de domaine du centre de
distribution de clés (KDC) qui résout
le SPN.
Microsoft-Windows- 1655 Les services de domaine Active

ActiveDirectory_DomainService Directory ont tenté de
échoué.
Microsoft-Windows- 2847 Le contrôle de cohérence des

ActiveDirectory_DomainService connaissances a localisé une
connexion de réplication pour le
service d’annuaire local en lecture
seule et a tenté de la mettre à jour à
distance sur l’instance de service
d’annuaire suivante. L’opération a
échoué. Elle sera retentée.


lien de réplication vers une partition
de répertoire en lecture seule avec
les paramètres suivants a échoué.
NETLOGON 5781 Le serveur ne peut pas enregistrer

son nom dans le DNS
5. Dcpromo échoue avec une erreur à l’écran :
Échec de l’installation d’Active Directory

Le service d’annuaire n’a pas réussi à créer l’objet serveur pour CN=NTDS
Paramètres,CN=ServerBeingPromoted,CN=Servers,CN=Site,CN=Sites,CN=Configuration,DC=contos
o,DC=com sur le serveur ReplicationSourceDC.contoso.com. Assurez-vous que les informations
d’identification réseau fournies ont un accès suffisant pour ajouter un réplica.
« Échec de la logon : le nom du compte cible est incorrect. »
OK
Dans ce cas, les ID d’événement 1645, 1168 et 1125 sont connectés au serveur promu.
6. Ma cartographier un lecteur à l’aide net use
C:\>net use z: \\<server_name>\c$
L’erreur système 1396 s’est produite.

Dans ce cas, le serveur consignait également l’ID d’événement 333 dans le journal des événements
système et l’utilisation de SQL Server utilisait une quantité élevée de mémoire virtuelle.
7. L’heure de dc est incorrecte.
8. Le KDC ne démarre pas sur un rodc après une restauration du compte krbtgt pour le RODC, qui a été
supprimé. Après la restauration à l’aide d’outils de restauration tiers, l’erreur 1396 s’affiche.
L’ID d’événement 1645 est enregistré sur le RODC.

Dcdiag signale également une erreur qui indique qu’il ne peut pas mettre à jour le compte RODC
krbtgt.
Cause
Plusieurs causes racines existent. Les causes racines connues sont les suivantes :
1. Le nom principal de service n’existe pas dans le catalogue global recherché par le KDC pour le compte du
client qui tente de s’authentifier à l’aide de Kerberos.
Dans le contexte de la réplication Active Directory, le client Kerberos est le dc de destination, le KDC qui
effectue la recherche SPN est probablement le DC de destination lui-même, mais il peut s’agit d’un DC
distant.
2. Le compte d’utilisateur ou de service qui doit contenir le nom principal du service recherché n’existe pas
dans le catalogue global recherché par le KDC pour le compte du dc de destination qui tente de répliquer.
Dans le contexte de la réplication Active Directory, le compte d’ordinateur DC source n’existe pas dans le
catalogue global recherché par le dc pour le compte du dc de destination qui effectue la réplication
entrante.
3. Le dc de destination n’a pas de secret LSA pour le domaine DCS source.
4. Le SPN à chercher existe sur un compte d’ordinateur différent de celui de la source DC.
5. Pour les problèmes où la réplication échoue à un rodc, le compte KRBTGT spécifique à RODC a peut-être
été supprimé.
Résolution
1. Vérifiez le journal des événements du service d’annuaire sur le dc de destination pour l’événement de
réplication NTDS 1645 et notez les remarques suivantes :
Nom du dc de destination
Le SPN à l’étude (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<object guid for source DCs NTDS
Settings object>/<target domain>..<tld>@<target domain><tld>
Le KDC utilisé par le dc de destination
2. À partir de la console du KDC identifié à l’étape 1, tapez

nltest /dsgetdc:<forest root DNS domain name > /gc .
Exécutez le test de localisation NLTEST immédiatement après une tentative de réplication qui échoue avec
l’erreur 1396 sur le dc de destination.
Cela doit identifier le GC sur quoi le KDC effectue des recherche SPN.
Le GC recherché par le KDC peut également être captué dans l’événement Microsoft-Windows-
ActiveDirectory_DomainService 1655.
3. Recherchez le SPN détecté à l’étape 1 sur le catalogue global découvert à l’étape 2.
C:\>repadmin /showattrServer_NameDC=corp,DC=contoso,dc=com <GC used by KDC> <DN path of forest root

domain> /filter:"(serviceprincipalname=<SPN cited in the NTDS Replication event 1645>)" /gc /subtree
/atts:cn,serviceprincipalname
Ou
C:\>dsquery * forestroot -scope subtree -filter "(serviceprincipalname=E3514235-4B06-11D1-AB04-

00C04FC2DCD2/65cead9f-4949-46a3-a49a-f1fbfe13d2b3*)" -attr * -sServer_Name.europe.corp.microsoft.com
Vérifiez que l’objet hôte du SPN existe.

Vérifiez le chemin d’accès DN de l’objet hôte, notamment si l’objet est CNF/conflict mangled ou s’il réside
dans le conteneur perdu et trouvé.
Vérifiez que le SPN de réplication DCS AD source est enregistré uniquement sur le compte d’ordinateur
DCS source.
Si le SPN de réplication est manquant, déterminez si le dc source a inscrit son SPN avec lui-même et si le
SPN est manquant sur le GC utilisé par le KDC en raison d’une latence de réplication simple ou d’un
échec de réplication
4. Vérifiez l’état du canal sécurisé et l’état d’confiance du canal sécurisé.
Ce tableau répertorie les autres symptômes, causes et résolutions :
SY M P TÔ M E C A USE RÉSO L UT IO N
Le contrôleur de domaine ne Ces problèmes se produisent car le Dans ce cas, vous devrez peut-être
fonctionne pas et enregistre les ID numéro de version du compte KRBTGT appliquer le correctif dans KB939820.
d’événement 1925 et 1411 sur les augmente lorsque vous effectuez une
contrôleurs de domaine Windows restauration faisant autorité. Le
Server 2008 et les contrôleurs de compte KRBTGT est un compte de
domaine Windows Server 2003 dans service utilisé par le service KDC
le même domaine que celui qui a été (Kerberos Key Distribution Center).
restauré de manière faisant autorité.
SY M P TÔ M E C A USE RÉSO L UT IO N
Ma cartographier un lecteur à l’aide Si l’erreur s’affiche lors du mappage Pour empêcher le système de
d’une utilisation nette d’un lecteur à l’aide d’une utilisation consigner l’événement 333 de façon
C:\Documents and nette, la cause peut être que la continue à l’avenir, appliquez le
Paramètres\wschong>net use z: \ mémoire non pagyée ou la mémoire 970054 de correctif sur le serveur et
<server_name>\c$ System error 1396 du pool pagayé est temporairement définissez la valeur de Registre suivante
has occurred. insuffisante. Le système continue sur 1 :
Échec de l’logo : le nom du compte d’enregistrer ces événements jusqu’à Emplacement :
cible est incorrect. ce que l’ordinateur soit redémarré ou HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Sessio
Dans ce cas, le serveur consignait l’ID que la ruche associée soit déchargée, Manager
d’événement 333 et utilisait une même si l’insuffisance de mémoire Nom :
mémoire élevée, SQL Server temporaire s’arrête. Pour plus RegistryFlushErrorSubside
l’utilisation la plus élevée. d’informations SQL Server problèmes Type : REG_DWORD
de performances, voir Troubleshooting Valeur : 1 ou 2
Performance Problems in SQL Server
2005.
L’heure de dc est incorrecte. Le dc est une machine virtuelle qui a a désactivé l’option de synchronisation
été définie pour synchroniser le temps de l’heure de dc virtuelle à partir de
avec l’hôte VMware, a provoqué les l’hôte VMWare, afin qu’elle puisse
événements 1925, 1645. synchroniser le temps avec le PDC.
Dcpromo échoue avec une erreur à Pendant dcpromo, le SPN sur le DC Pour une erreur dcpromo dans laquelle
l’écran : Échec de l’installation d’Active d’aide (dc source de réplication) n’est le nom principal de service DC n’est
Directory. L’opération a échoué car : pas valide. pas valide, utilisez SetSPN pour créer
Le service d’annuaire n’a pas réussi à un SPN sur dc d’aide, au format
créer l’objet serveur pour CN=NTDS GC/serverName.contoso.com
Paramètres,CN=ServerBeingPromoted,
CN=Servers,CN=Site,
CN=Sites,CN=Configuration,DC=cont
oso, DC=com sur le serveur
ReplicationSourceDC.contoso.com.
Assurez-vous que les informations
d’identification réseau fournies ont un
accès suffisant pour ajouter un réplica.
Échec de l’logo : le nom du compte
cible est incorrect.
Dans ce cas, les ID d’événement 1645,

1168 et 1125 sont connectés au
serveur promu.
Les autres causes sont les suivantes :
1. L’ID d’événement 1925 peut se produire sur les contrôleurs de domaine Windows Server 2008 et les
contrôleurs de domaine Windows Server 2003 dans le même domaine que celui qui a été restauré de
manière faisant autorité. Dans ce cas, vous devrez peut-être appliquer le correctif 939820.
2. Pendant dcpromo, le SPN sur le DC d’aide (dc source de réplication) n’est pas valide.
3. Si l’erreur s’affiche lors du mappage d’un lecteur à l’aide d’une utilisation nette, la cause peut être que la
mémoire non pagyée ou la mémoire du pool pagayé est temporairement insuffisante. Le système
continue d’enregistrer ces événements jusqu’à ce que l’ordinateur soit redémarré ou que la ruche
associée soit déchargée, même si l’insuffisance de mémoire temporaire s’arrête. Pour plus d’informations
SQL Server problèmes de performances, voir Troubleshooting Performance Problems in SQL Server
2005.
4. Le dc est une machine virtuelle qui a été définie pour synchroniser le temps avec l’hôte VMware, a
provoqué les événements 1925, 1645.
5. Pour le scénario spécifique RODC dans lequel le compte KRBTGT est supprimé : restituer de manière
faisant autorité le compte KRBTGT_##### à l’aide de NTDSUTIL, puis importer le fichier LDIFDE pour
corriger les liens arrière. Au minimum, l’attribut msDS-KrbTgtLink sur l’objet ordinateur du RODC doit
être mis à jour pour pointer vers le DN du compte restauré.
Résolution de l’erreur de réplication AD 8446 :
l’opération de réplication n’a pas réussi à allouer de
la mémoire
Cet article décrit les symptômes, la cause et les étapes de résolution des problèmes en cas d’échec de la
réplication Active Directory avec l’erreur 8446.
NOTE

Symptômes
Cet article décrit les symptômes, la cause et les étapes de résolution des problèmes en cas d’échec de la
réplication Active Directory avec l’erreur 8446 : « L’opération de réplication n’a pas réussi à allouer de la
mémoire ».
1. REPADMIN.exe signale que la tentative de réplication a échoué avec l’erreur « 8446 » : l’opération de
réplication n’a pas réussi à allouer de la mémoire
DC=Contoso,DC=com
Default-First-Site-NameDomainController\ via RPC
GUID d’objet DC : <source DCs ntds settings object object guid>
Last attempt @ <Date Time> failed, result 8446 (0x20fe) :
L’opération de réplication n’a pas réussi à allouer de la mémoire.
1 359 échecs consécutifs.
Dernière réussite @ <Date & Time>.
CN=Configuration,DC=Contoso,DC=com
Default-First-Site-NameDomainController\ via RPC
GUID d’objet DC : <source DCs ntds settings object object guid>
Last attempt @ <Date Time> failed, result 8446 (0x20fe) :
Source : Default-First-Site-NameDomainController\
1359 ÉCHECS CONSÉCUTIFS depuis <Date Time>
Dernière erreur : 8446 (0x20fe) :
2. DCPROMO échoue avec l’erreur 1130

06/05 09:55:33 [INFO] Error - Active Directory could not replicate the directory partition
CN=Configuration,DC=contoso,DC=com from the remote domain controller
5thWardDC1.contoso.com. (1130)
06/05 09:55:33 [INFO] NtdsInstall pour domain.net renvoyé 1130
06/05 09:55:33 [INFO] DsRolepInstallDs renvoyé 1130
06/05 09:55:33 [ERREUR] Échec d’installation dans le service d’annuaire (1130)
Réplication non critique renvoyée 1130
err.exe 1130
ERROR_NOT_ENOUGH_SERVER_MEMORY/Le stockage du serveur est insuffisant pour traiter cette
commande.
3. La réplication NTDS, les événements généraux NTDS avec l’état 8466 sont consignés dans le journal des

8446 L’opération de réplication n’a
pas réussi à allouer de la mémoire
NTDS General 1079 Active Directory n’a pas pu allouer

suffisamment de mémoire pour
traiter les tâches de réplication. La
réplication peut être affectée jusqu’à
ce que davantage de mémoire soit
disponible Augmenter la quantité de
mémoire physique ou virtuelle et
redémarrer ce contrôleur de
domaine
4. Lorsque vous essayez de lancer manuellement la réplication à l’aide de Repadmin ou de sites et services
Active Directory, vous obtenez le message d’erreur suivant :

noms Contoso.com du contrôleur <Source DC > de domaine au contrôleur de domaine <Destination
DC>:
L’opération de réplication n’a pas réussi à allouer de la mémoire. Cette opération ne se poursuit pas.
5. Il se peut que le contrôleur de domaine ne réponde plus et qu’un redémarrage offre une solution de
contournement temporaire.
Cause
La 8446 (opération n’a pas réussi à allouer de la mémoire. Cette opération ne se poursuit pas) l’état peut se
produire lorsque le moteur de réplication Active Directory ne peut pas allouer de mémoire pour effectuer la
réplication Active Directory.
Ces événements peuvent se produire en raison des conditions suivantes :
Mémoire physique disponible faible
Taille de fichier d’pagination faible disponible par rapport à la mémoire physique (configuration de fichier de
pagination erronée) : le fichier d’pagination doit être 1,5 fois la taille de la mémoire physique
Épuisement des pool paginés ou non paginés dans le noyau
Mémoire virtuelle LSASS sur les contrôleurs de domaine 32 bits. C’est là que la mémoire virtuelle de LSASS
atteint la limite de 2 Go de mémoire virtuelle disponible pour un processus en cours d’exécution en mode
utilisateur.
La mémoire virtuelle pourrait être une fuite dans le processus du mode utilisateur LSASS, ou le cache de
base de données (cache ESE) peut consommer toute la mémoire disponible.
Les informations suivantes sont importantes à comprendre
Lsass.exe'utilisation de la mémoire sur les contrôleurs de domaine a deux composants principaux : un fixe et une
variable.
Le composant fixe est composé du code, des piles, des tas et de différentes structures de données de taille fixe
(par exemple, le cache de schéma). La quantité de mémoire que LSASS utilise peut varier en fonction de la
charge sur l’ordinateur. À mesure que le nombre de threads en cours d’exécution augmente, le nombre de piles
de mémoire augmente également. Lsass.exe utilise généralement 100 Mo à 300 Mo de mémoire. Lsass.exe
utilise la même quantité de mémoire, quelle que soit la quantité de RAM installée sur l’ordinateur.
Le composant variable est le cache de mémoire tampon de base de données. La taille du cache peut aller de
moins de 1 Mo à la taille de la base de données entière. Étant donné qu’un cache plus volumineux améliore les
performances, le moteur de base de données pour AD (ESENT) tente de le conserver aussi volumineux que
possible. Bien que la taille du cache varie en fonction de la pression de la mémoire sur l’ordinateur, la taille
maximale du cache est limitée à la fois par la quantité de RAM physique installée sur l’ordinateur et par la
quantité d’espace d’adressace virtuel (VA) disponible. AD utilise uniquement une partie de l’espace va total pour
le cache.
Résolution
Déterminez s’il existe des ressources suivantes et corrigez la cause sous-jacente :
RAM physique
Fichier d’échange
Pool pagaré ou pool non pagaré
Fragmentation de la mémoire virtuelle LSASS
Si la cause première n’est pas la mémoire, le problème peut être dû à un manque d’espace d’adressame continu
disponible pour l’allocation de mémoire. En raison de la fragmentation de la mémoire, les segments d’adresse
disponibles sont trop petits pour satisfaire la demande.
Le problème de fragmentation n’est pas visible sur les systèmes 64 bits, car il dispose d’un espace d’adressame
virtuel beaucoup plus important de 16 To. Par conséquent, une solution remplace les contrôleurs de domaine 32
bits par le matériel 64 bits de DC et une version 64 bits du système d’exploitation.
Évolutivité du contrôleur de domaine
S’il n’y a aucune fuite de mémoire apparente ou une perte de ressources :
Vérifiez la taille du NTDS. Fichier DIT sur le contrôleur de domaine ; Si la taille est au-delà de 2 Go sur un
contrôleur de domaine 32 bits, une solution probable consiste à passer à un système d’exploitation et à un
matériel 64 bits.
Dans de nombreux cas, les administrateurs sont passés au matériel x64 Bits et n’ont pas rencontré de répétition
de l’erreur 8446 (la réplication n’a pas pu allouer de mémoire).
Pour les systèmes d’exploitation 32 bits, en fonction de la taille du NTDS. DIT, le commutateur /USERVA boot.ini
qui augmente l’espace d’adressare en mode virtuel sur les contrôleurs de domaine peut fournir une assistance,
mais cela peut provoquer une dégradation du mode noyau, car cela réduit la taille de l’espace d’adressare en
mode noyau. Avant d’implémenter le commutateur /UserVA, il est préférable de consulter un expert en
optimisation des performances de mémoire Windows pour une analyse de l’utilisation de la mémoire en mode
noyau et en mode utilisateur. Le cache de base de données consomme toute la mémoire virtuelle disponible
pour le processus LSASS.
Exécutez l’Analysez les performances avec des compteurs de base de données, examinez les compteurs suivants
:
LSASS - Ensemble de travail
LSASS - Octets virtuels
Base de données - « Taille du cache de base de données »
NOTE
Par défaut, vous ne serez pas en mesure d’afficher les compteurs de base de données sur un contrôleur de Windows
2003. Utilisez les étapes suivantes pour ajouter les compteurs de base de données Windows Server 2003.
Ces étapes ne sont pas nécessaires pour Window Server 2008 et les ultérieures.
1. Importez les paramètres de Registre suivants : (copiez le texte suivant dans le bloc-notes et enregistrez-le
en tant que fichier .reg, puis importez les paramètres sur le dc)
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\Performance]
« Open"="OpenPerformanceData »
« Collect"="CollectPerformanceData »
« Close"="ClosePerformanceData »
« Library"="C:\\Windows\\ System32\\esentprf.dll »
« Show Advanced Counters"=dword:00000001
2. Exécutez la commande suivante à partir d’une invite de commandes pour back up vos compteurs de
performance existants : Lodctr /s: backup.ini
3. Exécutez la commande suivante à partir d’une invite de commandes pour inscrire les compteurs de base
de données : Lodctr c:\windows\system32\esentprf.ini
Ouvrez Perfmon ou redémarrez l’écran de performances s’il est déjà ouvert.
Vous devriez maintenant être en mesure d’afficher un nouvel objet de performances dans Perfmon
appelé Base de données.
Ajoutez le compteur « Taille du cache de base de données ». Dans l’exemple suivant, la taille du cache de
base de données augmente avec une tendance croissante d’octets virtuels et d’ensembles de travail du
processus LSASS qui consomment finalement les 2 Go de mémoire virtuelle disponibles allouées au
processus LSASS. Vous rencontrerez l’échec de la réplication 8446 une fois cet espace d’adressare virtuel
consommé. Reportez-vous à la section « Le cache de base de données ESE LSASS n’est pas limité par
défaut » de l’article pour obtenir des instructions détaillées sur la façon d’éviter cette condition.
Le cache de base de données ESE LSASS n’est pas limité par défaut
Si vous déterminez qu’il s’agit du cache de base de données qui consomme de la mémoire à l’aide de l’écran de
performance, vous pouvez ajouter la valeur de Registre suivante pour limiter le cache de base de données.
Vous pouvez utiliser la valeur de Registre « Mémoires tampons maximales EDB » pour limiter l’allocation du
cache ESE (le nombre de pages est de 8 912 octets) pour éviter les conditions.
Nom de la valeur : Mémoires tampons maximales EDB
Type : reg_dword
Paramètre : <refer to the values below>
Clé de Registre : HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Cau t i on
Assurez-vous que vous définissez une valeur optimale sur la valeur de Registre (mémoires tampons maximales
EDB), si la limite de cache est trop faible, cela peut entraîner une dégradation des performances. Vous pouvez
appliquer les valeurs suivantes comme début pour une optimisation, selon que le commutateur de boot.ini /3
Go est utilisé ou non :
Sans commutateur /3 Go : « Mémoires tampons maximales EDB », Reg_DWord : 157286 (1,2 Go) ;
consommation LSASS attendue ~1,5 Go avec commutateur /3 Go : « Mémoires tampons maximales EDB »,
Reg_DWord : 235929 (1,8 Go) ; consommation LSASS attendue ~2,1 Go
Erreur de réplication Active Directory 8464 : échec
de la tentative de synchronisation
Cet article vous aide à résoudre l’erreur de réplication Active Directory 8464.
NOTE
Symptômes
Cet article décrit les symptômes, la cause et la résolution des problèmes dans lesquels la réplication Active
Directory échoue et renvoie l’erreur 8464 :
Code d’erreur Hex : 0x00002110

Code d’erreur de décembre : 8464
Nom symbolique : ERROR_DS_DRA_INCOMPATIBLE_PARTIAL_SET
Description de l’erreur : échec de la tentative de synchronisation car le dc de destination attend actuellement
de synchroniser de nouveaux attributs partiels à partir de la source. Cette condition est normale si un
changement de schéma récent a modifié le jeu d’attributs partiel. Le jeu d’attributs partiels de destination
n’est pas un sous-ensemble de l’ensemble d’attributs partiels source.
En-tête : winerror.h
En outre, une entrée ActiveDirectory_DomainService événement de réplication NTDS ou NTDS 1704 qui
ressemble à ce qui suit est consignée :

Source de l’événement : ActiveDirectory_DomainService/réplication NTDS
Catégorie de tâche : catalogue global
Texte de l’événement : le catalogue global a initié la réplication d’un membre du jeu d’attributs partiels pour
la partition d’annuaire suivante à partir du contrôleur de domaine suivant.
DC=<name>,DC=<domain>,DC=com
<fqdn>
Il s’agit d’un cycle de réplication spécial en raison de l’ajout d’un ou de plusieurs attributs au jeu d’attributs
partiel.
NOTE
Il est courant de voir l’état de réplication Active Directory 8464 après avoir étendu le schéma ou après avoir ajouté de
nouveaux attributs au jeu d’attributs partiels (PAS). Ce message indique que la réplication est retardée temporairement.
L’état de réplication Active Directory 8464 disparaît une fois le processus de mise à jour terminé.
Cause
Ce problème se produit car la synchronisation PAS est déclenchée lorsqu’un attribut est ajouté à la passe.
Pour plus d’informations, voir la section Plus d’informations.
Résolution
Étant donné qu’il s’agit d’une partie standard de la synchronisation PAS, les étapes de résolution ne sont pas
nécessaires. Consultez la section Plus d’informations pour les étapes de résolution des problèmes si cet état de
réplication persiste dans l’environnement pendant plus d’une semaine.
Détails de la cause de l’état 8464
La définition de schéma d’un attribut est stockée dans la partition de schéma en tant qu’objet attributeSchema.
La vérification de la case à cocher Répliquer cet attribut dans le catalogue global définit l’attribut
isMemberOfPartialAttributeSet sur TRUE sur l’objet attributeSchema. Tout objet attributeSchema dont cet
attribut a la valeur TRUE entraîne l’inclure dans le jeu d’attributs partiel.
Lorsque la synchronisation PAS se produit (qui résulte de l’extension PAS), il existe une tâche spécialisée dans la
file d’attente des tâches de réplication. L DRS_SYNC_PAS identifie cette tâche spécialisée.
Une topologie Active Directory non optimale ou des échecs de réplication Active Directory peuvent entraîner un
retard important dans le processus de mise à jour PAS. Il est courant de voir l’état de réplication Active Directory
8464 pendant le processus de mise à jour PAS.
Vérifier l’état de réplication Active Directory 8464
Les Repadmin commandes et autres outils qui fournissent un rapport d’état de réplication Active Directory
indiquent qu’une tentative de réplication est retardée avec l’état 8464.
Voici les commandes et autres Repadmin outils qui mentionnent généralement l’état 8464, y compris, mais sans
s’y limiter :
REPADMIN /SHOWREPL
REPADMIN /REPLSUM
REPADMIN /REPLICATE
Outil d’état de réplication Active Directory
Voici un exemple de sortie Repadmin /showrepl qui montre que la réplication entrante de DC2 à DC1 est
retardée :
Options DSA DomainDC2\ : IS_GC options de site : (aucun) GUID <GUID> d’objet DSA : DSA invocationID :
<ID>
DC=child,DC=root,DC=contoso,DC=com
DomainDC1\ via RPC DSA object GUID: <GUID> Last attempt @ 2014-08-28 04:50:44 was delayed for a
normal reason, result 8464 (0x2110)
Voici la sortie détaillée de la Repadmin /showrepl commande :
DomainTRDC1\ via RPC

GUID <GUID> d’objet DSA : Adresse : xxxxxxxxxx._msdcs.root.contoso.com DSA invocationID: <ID>
SYNC_ON_STARTUP DO_SCHEDULED_SYNCS PARTIAL_ATTRIBUTE_SET USNs: 0/OU, 234943/PU
La dernière tentative @ <Date & Time> a été retardée pour une raison normale, résultat 8464 (0x2110) :
La tentative de synchronisation a échoué car le dc de destination attend actuellement de synchroniser de
nouveaux attributs partiels à partir de la source. Cette condition est normale si un changement de schéma
récent a modifié le jeu d’attributs partiel.
Le jeu d’attributs partiels de destination n’est pas un sous-ensemble de l’ensemble d’attributs partiels source.
Comment déterminer le contrôleur de domaine de destination
NOTE
Ces étapes nécessitent une connaissance de la topologie de réplication Active Directory de l’environnement, de la
corrélation des données d’état de la réplication et de la modification temporaire de l’intervalle ou des connexions de
réplication Active Directory.
1. Identifiez un contrôleur de domaine de destination pour l’état de réplication Active Directory journalisé
d’une partition 8464. Utilisez ce contrôleur de domaine et cette partition pour ces étapes (ne vous écartez
pas entre les partitions et les contrôleurs de domaine).
NOTE
Cette étape vous permet de vous concentrer d’abord sur la mise à jour des serveurs têtes de pont et du
contrôleur de domaine de site hub.
2. Collectez les données suivantes. Vérifiez les résultats de l’état de réplication pour le contrôleur de
domaine de destination et le contrôleur de domaine source. Exécutez les commandes suivantes pour
exporter les résultats :
a. Comparez l’état actuel de synchronisation PAS entre tous les serveurs de catalogue global.
Exécutez la commande suivante pour exporter le résultat vers un pas_domain.txt de données :
repadmin /showattr gc: <Partition_DN> /gc /atts:partialattributeset >pas_domain.txt
b. Vérifiez les résultats de l’état de réplication pour les contrôleurs de domaine source et de
destination. Exécutez les commandes suivantes pour exporter les résultats :
Repadmin /showrepl <DestinationDC> /verbose >repl_destDC.txt

Repadmin /showrepl <SourceDC> /verbose >repl_sourceDC.txt
Repadmin /showrepl * /csv >showrepl.csv
c. Liste de tous les attributs dans le PAS. Cela est utile pour déterminer le nombre actuel. Exécutez la
commande suivante pour exporter le résultat vers un pas.txt de données :
repadmin /showattr fsmo_schema: ncobj:schema: /filter:"(ismemberofpartialattributeset=TRUE)"

/subtree /atts:dn >pas.txt
d. Vérifiez les ID d’événement 1704 et 1702, car ils indiquent que la synchronisation PAS est terminée
dans le journal des événements du service d’annuaire. Voici un exemple d’ID d’événement 1702 :

Source de l’événement : ActiveDirectory_DomainService/réplication NTDS
Catégorie de tâche : catalogue global
Texte de l’événement : le catalogue global a terminé la synchronisation du jeu d’attributs
partiels pour la partition d’annuaire suivante à partir du contrôleur de domaine suivant.
DC=<name>,DC=<domain>,DC=com
<fqdn>
Il s’agit d’un cycle de réplication spécial en raison de l’ajout d’un ou de plusieurs attributs au
jeu d’attributs partiel.
3. Analysez les données en fonction du contrôleur de domaine de destination avec un contrôleur de

domaine pas ou source obsolète avec pas obsolète.
Si le contrôleur de domaine de destination ne comprend pas la passe mise à jour, faites les choses
suivantes :
a. Déterminez si les partenaires sources ont la valeur mise à jour.
b. Mettez à jour la destination et tous les contrôleurs de domaine source qui ne sont pas à jour
pour effacer l’état 8464.
c. Démarrez manuellement la réplication avec des contrôleurs de domaine source à jour. Vous
pouvez également créer et répliquer des contrôleurs de domaine source si des connexions
n’existent pas.
d. Lorsque le contrôleur de domaine de destination est mis à jour, l’état 8464 est enregistré pour
les contrôleurs de domaine source qui ne sont pas mis à jour.
Si le contrôleur de domaine de destination dispose de la passe mise à jour, mais pas du contrôleur de
domaine source, l’état 8464 ne sera pas effacer tant que la source n’aura pas été mise à jour. Vous
pouvez également mettre à jour le contrôleur de domaine source en délant manuellement la
réplication avec un contrôleur de domaine à jour.
Pas_domain.txt instructions
La valeur d’intérêt pour la sortie est répertoriée après la v1.cAttrs = texte. Cette valeur numérique affiche le
nombre d’attributs inclus dans le pas. Comparez ces valeurs entre chaque catalogue global (GC) pour chaque
partition. Si tous les GCs affichent la même valeur, tous les GCs sont synchronisés (ils ont tous le PAS mis à jour
ou ils ne le sont pas tous). Si toutes les valeurs sont identiques, comparez-les avec les valeurs de sortie dans
d’autres partitions ou le schéma de vidage, puis comptez la liste des attributs dans le PAS.
Voici un exemple de journal, où DC1 n’a pas mis à jour le jeu d’attributs partiels pour la partition CHILD. DC2 a
également terminé le processus de mise à jour PAS. Aucune donnée n’est enregistrée pour ChildDC1, car
l’attribut partialattributeset n’a pas de données en raison de ChildDC1 contenant une copie complète de la
partition de domaine enfant.
Repadmin : exécution de la commande /showattr sur un contrôle DC DC1.root.contoso.com

DN : DC=child,DC=root,DC=contoso,DC=com
1> partialAttributeSet : { dwVersion = 1 ; dwFlag = 0 ; V1.cAttrs = 196, V1.rgPartialAttr = 0, 3, 4, 6, 7, 8, 9
Repadmin : exécution de la commande /showattr sur un contrôle DC ChildDC1.child.root.contoso.com
Repadmin : exécution de la commande /showattr sur un contrôle DC DC2.root.contoso.com
1> partialAttributeSet : { dwVersion = 1 ; dwFlag = 0 ; V1.cAttrs = 203, V1.rgPartialAttr = 0, 3, 4, 6, 7, 8, 9
Pas.txt instructions
Identifier la liste des attributs dans le pas
Pour voir la liste des attributs dans le pas, utilisez repadmin ou un autre outil pour interroger la partition de
schéma pour tous les attributs pour lequel la valeur ismemberofpartialattributeset est définie sur TRUE :
repadmin /showattr fsmo_schema: ncobj:schema: /filter:"(ismemberofpartialattributeset=TRUE)" /subtree

/atts:dn >pas.txt
Assurez-vous que le mot TRUE est en texte en minuscules.

Vous pouvez également utiliser LDIFDE pour obtenir ces données avec le nombre :
Ldifde -f pas.txt -d "cn=schema,cn=configuration,dc=forestRootDN" -r "(ismemberofpartialattributeset=TRUE)"

196 entries exported
Identifier le nombre d’attributs dans le pas

Pour obtenir le nombre d’attributs de la sortie du repadmin, suivez les étapes suivantes :
1. Ouvrez le fichier texte dans Bloc-notes .
2. Supprimez les lignes vides au début et à la fin du fichier.
3. Supprimez la ligne en haut du fichier qui commence par « Repadmin : exécution de la commande /showatt ».
4. Placez votre pointeur sur la dernière ligne de texte du fichier, puis appuyez sur le raccourci clavier Ctrl + G
pour ouvrir la boîte de dialogue Aller à la ligne. Le numéro de ligne dans cette fenêtre représente le nombre
d’attributs dans le jeu d’attributs partiel.
Journal des événements du service d’annuaire
Activez la journalisation des diagnostics pour les événements de catalogue global afin d’afficher des détails
supplémentaires sur le cycle de mise à jour du jeu d’attributs partiel. Après avoir activer le verbosité des
événements de réplication, affichez le journal des événements des services d’annuaire.
Pour activer la journalisation des diagnostics pour les événements de catalogue global, suivez les étapes
suivantes :
1. Ouvrez Regedit.
3. Configurer la journalisation des événements pour le catalogue global :
a. Sur le côté droit de l’Éditeur du Registre, double-cliquez sur l’entrée 18 Catalogue global.
b. Tapez 3 dans la zone Données de la valeur, puis cliquez sur OK .
4. Fermez Regedit.
Cycle d’état de réplication lors de la synchronisation d’attributs partielle
Le message d’état de réplication Active Directory 8464 est enregistré lorsque le contrôleur de domaine de
destination attend de synchroniser la passe mise à jour à partir du contrôleur de domaine source.
NOTE
Le contrôleur de domaine sélectionné pour la tâche PAS_Sync peut passer à un autre contrôleur de domaine source lors
de l’intervalle de réplication suivant (à partir de l’ensemble existant de partenaires réplicas).
Les nouvelles tentatives de synchronisation du pas sont basées sur la planification de la réplication. Lorsqu’une
autre source est sélectionnée pour la tâche PAS_Sync, la réplication se poursuit généralement avec le contrôleur
de domaine source précédent. Une fois la pas correctement mise à jour, la réplication de la même partition vers
le contrôleur de domaine mis à jour échouera à partir des contrôleurs de domaine sans le pas mis à jour. Le
même état de réplication est enregistré pour ce scénario.
Lorsque le contrôleur de domaine de destination n’a pas mis à jour le pas, l’un des processus suivants se produit
:
Sélectionne une source de réplica pour mettre à jour pas. Ensuite, l’événement 1704 est enregistré au début
de la synchronisation.
Si la source ne présente pas le PAS mis à jour, l’état de réplication Active Directory 8464 est journalisé et l’ID
d’événement 1705 est consigné si la journalisation des diagnostics est activée.
Si la tâche de mise à jour PAS a échoué, puis qu’une nouvelle source est sélectionnée, l’ID d’événement 1706
est enregistré si la journalisation des diagnostics est activée.
La réplication à partir d’autres contrôleurs de domaine pour la même partition se déroule comme d’habitude
(l’état 0 est consigné en l’absence d’échec).
Exemple de cycle de synchronisation PAS
Cette section est un exemple du cycle de synchronisation PAS. Le tableau suivant est les contrôleurs de domaine
dans la forêt :
C O N T RÔ L EURS DE DO M A IN E DO M A IN
DC1 Root.contoso.com
DC2 Root.contoso.com
ChildDC1 Child.root.contoso.com
ChildDC2 Child.root.contoso.com
TRDC1 Treeroot.fabrikam.com
Voici la structure de la forêt :

7 nouveaux attributs sont ajoutés à la passe à l’aide de l’extension de schéma. Par conséquent, le nombre
d’attributs dans la passe passe de 196 à 203.
Cela démarre la synchronisation PAS. Tous les GCs doivent maintenant sourcer les données pour ces sept
attributs dans chaque partition GC.
Ce diagramme illustre la mise à jour d’une seule partition.
L’intervalle de réplication dans cet environnement est de 15 minutes.
Il existe une condition pré-existante qui bloque la réplication à partir d’un dc hébergeant une copie accessible
en texte de la partition.
Dans ce scénario, les processus suivants se produisent :
1. Lorsque le contrôleur de domaine de destination n’a pas mis à jour le pas :
a. DC1 sélectionne DC2 pour PAS_SYNC. Étant donné que DC2 possède également l’ancien pas, l’état
de réplication Active Directory 8464 est enregistré.
b. TRDC1 n’a pas été sélectionné pour PAS_SYNC et il a également l’ancien statut de réplication PAS,
Active Directory 0 (réussite) est enregistré.
c. ChildDC1 contient une copie accessible en writable de la partition CHILD afin qu’elle ait tous les
attributs pour cette partition. Toutefois, il existe un problème pré-existant qui entraîne l’échec de la
réplication Active Directory avec l’erreur 8606.
2. Le contrôleur de domaine de destination sélectionne une nouvelle source (TRDC1) pour la PAS_SYNC
tâche.
a. TRDC1 dispose également de l’ancienne passe afin que la réplication soit retardée et que l’état
8464 soit journalisé.
b. DC2 possède également l’ancienne passe. Toutefois, il n’est pas sélectionné pour PAS_Sync cet
intervalle et la réplication est correctement effectuée. Par conséquent, l’état 0 est enregistré.
c. La réplication Active Directory échoue toujours avec ChildDC1 en raison d’un problème d’objets en
attente non lié existe (objets abandonnés).
3. PAS_SYNC bascule vers l’autre réplica obsolète (DC2).

a. Pendant ce temps, nous corrigeons le problème de réplication sur ChildDC1.
b. La réplication est retardée à partir de DC2 et l’état 8464 est enregistré.
c. La réplication se déroule correctement à partir de TRDC1.
d. La réplication se déroule correctement à partir de ChildDC1 (mais elle n’est pas sélectionnée pour
PAS_Sync sur ce cycle).
4. Un contrôleur de domaine approprié est enfin sélectionné pour PAS_SYNC (ChildDC1).
a. La réplication se déroule comme d’habitude à partir de DC2 et TRDC1 (ces tentatives sont
effectuées avant PAS_Sync).
b. La réplication se déroule comme d’habitude à partir de ChildDC1 et PAS_SYNC est terminée.
5. Le contrôleur de domaine de destination dispose enfin de la passe mise à jour (à partir du dernier
intervalle).
a. La réplication à partir de DC2 et TRDC1 est désormais retardée car les contrôleurs de domaine
source sont obsolètes. Le même état de réplication Active Directory est enregistré pour ce
problème.
b. La réplication s’est terminée correctement à partir de ChildDC1.
6. Entre l’intervalle de réplication précédent et le suivant, la copie DC2 de l’ensemble d’attributs partiels
pour le domaine CHILD est également mise à jour (mais pas dans l’image).
a. Étant donné que le contrôleur de domaine de destination (DC1) et les contrôleurs de domaine
source (DC2 et ChildDC1*) ont tous deux la passe mise à jour, la réplication est terminée
correctement.
*ChildDC1 possède un ensemble complet d’attributs pour la partition (et pas seulement).
b. La réplication est retardée à partir de TRDC1, car elle possède toujours l’ancien PAS.
7. Entre l’intervalle de réplication précédent et le suivant, la copie TRDC1 de l’ensemble d’attributs partiels
pour le domaine CHILD est également mise à jour (mais pas dans l’image).
a. La réplication est effectuée correctement à partir de tous les partenaires, car le contrôleur de
domaine de destination et les sources ont tous les mêmes attributs pour le pas.
Erreur de réplication Active Directory 8545 : « La
mise à jour de réplication n’a pas pu être appliquée
»
Cet article fournit une solution à un problème dans lequel la réplication Active Directory échoue pour une ou
plusieurs partitions avec l’erreur 8545.
NOTE
Symptômes
Dans Windows Server 2012 et Windows Server 2008, la réplication Active Directory échoue pour une ou
plusieurs partitions et renvoie l’erreur 8545 : « La mise à jour de réplication n’a pas pu être appliquée, car la
source ou la destination n’a pas encore reçu d’informations concernant une opération de déplacement récente
entre domaines. »
En outre, l’erreur suivante est consignée dans le journal du service d’annuaire sur le contrôleur de domaine de
destination :
Événement Microsoft-Windows-ActiveDirectory_DomainService Event ID 1084Internal : Les services de

domaine Active Directory n’ont pas pu mettre à jour l’objet suivant avec les modifications reçues du service
d’annuaire source suivant. Cela est dû au fait qu’une erreur s’est produite lors de l’application des
modifications apportées aux services de domaine Active Directory sur le service d’annuaire.
Objet :
CN=<User>,OU=Users,OU=Magasins,DC=na,DC=contoso,DC=com
GUID d’objet :
33555323-8e42-42dd-ab95-51693b54281f
1126750c-e8ac-4355-8412-ccb287e48c23._msdcs.contoso.com
Redémarrez l’ordinateur local si cette condition semble être liée à des ressources système faibles (par
Valeur d’erreur :
8545 La mise à jour de réplication n’a pas pu être appliquée, car la source ou la destination n’a pas encore
reçu d’informations concernant une opération de déplacement récente entre domaines.
NOTE
Pour plus d’informations sur l’application des valeurs référencés dans l’ID d’événement 1084, voir les tableaux dans la
section « Plus d’informations ».
Cause
Ce problème se produit si l’objet répertorié dans l’événement 1084 a été migré d’un domaine vers un autre
domaine dans la même forêt. Le contrôleur de domaine de destination n’apprend pas le nouvel emplacement de
l’objet (sa partition). Par conséquent, l’objet est toujours présent dans l’ancienne partition sur le contrôleur de
Le contrôleur de domaine source connaît la migration de l’objet et le localise dans le nouvel emplacement de
l’objet.
L’erreur de réplication Active Directory 8545 est enregistrée lorsque le contrôleur de domaine source tente
d’envoyer des modifications pour cet objet récemment migré lorsque le contrôleur de domaine de destination
trouve l’objet présent dans une partition différente.
Résolution
À titre de prévention, envisagez d’installer l’article 2682997 de la Base de connaissances Microsoft sur tous les
contrôleurs de domaine qui exécutent toujours Windows Server 2008 ou Windows Server 2008 R2. Pour ce
faire, procédez comme suit :
1. Déterminez le nom (DN) du contexte d’appellation (NC) /partition à partir de laquelle l’objet a été migré.
Pour plus d’informations à ce sujet, consultez la section « Plus d’informations ».
2. Sur le contrôleur de domaine de destination, suivez les étapes suivantes pour déshost cette partition :
a. Exécutez la ligne de commande suivante : Repadmin /unhost DestinationDC
<DNofObject'sOldLocation>
Par exemple, si le contrôleur de domaine de destination est DC1 et que le DN de la partition à
partir de laquelle l’objet a été migré est dc=corp,dc=contoso,dc=com, la commande sera
Repadmin /unhost DC1 dc=corp,dc=contoso,dc=com.
NOTE
Surveillez le journal du service d’annuaire sur le contrôleur de domaine pour l’ID d’événement 1660.
Examinez le texte de l’événement pour vous assurer que le contrôleur de domaine n’héberge plus le NC
CORP.
b. L’ID d’événement 1659 indique l’état de l’opération d’unhost. Ne liez pas la partition tant que vous
n’avez pas correctement synchronisé l’autre partition.
3. Sur le contrôleur de domaine de destination, déclenchez la réplication avec le contrôleur de domaine
source (celui qui a échoué).
4. Réhostez la partition à partir d’un contrôleur de domaine qui dispose d’une copie en lecture/écriture
valide de la partition. Pour ce faire, exécutez la ligne de commande suivante :
Repadmin /add DNobObject’sOldLocation DestinationDC GoodSourceDC /readonly
Par exemple, supposons que le contrôleur de domaine de destination est DC1, que la partition que vous
n’avez pas haitée est dc=corp,dc=contoso,dc=com et qu’un contrôleur de domaine qui dispose d’une
copie en lecture/écriture de la partition CorpDC1.corp.contoso.com Corp est . Dans ce cas, la commande
sera . Repadmin /add dc=corp,dc=contoso,dc=com dc1 CorpDC1.corp.contoso.com /readonly Pour plus
d’informations sur ce scénario spécifique, consultez la section « Plus d’informations ».
Le scénario décrit dans les sections précédentes peut prêter à confusion. Utilisez le style de tableau suivant pour
documenter tous les points de données dont vous avez besoin pour résoudre ce problème.
Tout d’abord, déterminez s’il s’agit du contrôleur de domaine source ou de destination qui dispose d’une copie
de l’objet à l’ancien emplacement (emplacement à partir de lequel l’objet a été migré).
NOM DÉTA IL S
DN d’objet CN=MAGASINSTU,OU=Users,OU=CAS,DC=na,DC=contoso
,DC=com
ObjectGUID 33555323-8e42-42dd-ab95-51693b54281f
Parent Object DN OU=Users,OU=CAS,DC=na,DC=contoso,DC=com
Ancien domaine source (DN) Dans quel domaine se trouvait l’objet ?
Dc=corp,dc=contoso,dc=com
Domaine cible (DN) Vers quel domaine l’objet a-t-il été migré ?
Dc=na,dc=contoso,dc=com
Identifier tous les DCS avec des objets (métadonnées de Repadmin /showobjmeta *"<GUID=33555323-8e42-42dd-
réplication) ab95-51693b54281f> » >JUSTINTUObjmeta.txt
Important :
Pour les DCS dont vous ne parviennent pas à obtenir des

données à partir des :
1. Connecter à chaque dc à partir de qui vous n’avez pas
obtenu de données.
2. Réexécutez la commande et remplacez l’astérisque par le
nom dc.
Exemple : repadmin /showobjmeta DC004

« <GUID=33555323-8e42-42dd-ab95-51693b54281f> »
>LCTXDC004_JUSTINTUObjmeta.txt
NOM DÉTA IL S
Identifier tous les DCS avec des objets (valeurs d’attribut) Repadmin /showattr *"<GUID=33555323-8e42-42dd-
ab95-51693b54281f> » /gc >JUSTINTUattr.txt
Important :
Pour les DCS dont vous ne parviennent pas à obtenir des

données à partir des :
1. Connecter à chaque dc en question.
2. Réexécutez la commande et remplacez l’astérisque par le
nom dc.
Exemple : repadmin /showobjattr LCTXDC004

« <GUID=33555323-8e42-42dd-ab95-51693b54281f> »
/gc >LCTXDC004_JUSTINTUAttr.txt
Identifier tous les DCS de la forêt Repadmin /viewlist * >allDCs.txt
Identifier les DSA_GUID pour tous les DCS Repadmin /showattr DCNAME NCONNER: Config: /filter:"
(Objectclass=NTDSDSA) » /atts:objectGUID /subtree
>ntdsa.txt
Les deux commandes précédentes.
DC dans le domaine source sans objet dans le nom de

partition NA
DC dans le domaine source sans objet dans la partition NA

DSA_GUID
État de la réplication pour la forêt Repadmin /showrepl * /csv >showrepl.csv
Pour identifier l’emplacement actuel de l’objet dans la base de données :

1. Vidage de la base de données de l’un des DCS de destination.
2. Ouvrez le fichier de vidage de base de données, puis recherchez l’objetGUID signalé dans l’événement 1084.
3. Prenez les valeurs DNT et PDNT et créez la hiérarchie d’objets en copiant les valeurs pertinentes dans un
tableau, comme suit :
DN T P DN T RDN O B JEC TGUID
61001 45020 Tsétu 33555323-8e42-42dd-

ab95-51693b54281f
45020 20005 LostAndFound
6931 1752 Corp
1751 20003 Contoso
1750 2 com
À l’aide du fichier de vidage de base de données, vous pouvez voir l’emplacement actuel de cet objet dans la
base de données sur ce contrôleur de domaine :
CN=LostAndFound,DC=Corp,DC=Contoso,DC=com
Vous pouvez voir que l’objet était présent dans le conteneur LostAndFound sur le corp.contoso.com NC.
Toutefois, la réplication est bloquée sur cet objet à l’exception du NA.contoso.com NC. Étant donné que cet objet
est déjà présent dans la base de données (mais dans l’ancien NC incorrect), vous devez supprimer cette partition
de ce contrôleur de domaine afin de supprimer l’ancien objet.
Exemple de plan d’action de scénario
L’objet Configuration a été migré de la partition Corp vers la partition NA. Toutefois, la partition NA ne parvient
pas à répliquer NADC1.na.contoso.com à partir de DC1.la.contoso.com , et la tentative renvoie l’erreur 8545.
Destination DC : DC1.la.contoso.com
Source DC : NADC1.na.contoso.com
1. À titre de prévention, envisagez d’installer l’article de la 2682997 de la Ko sur tous les contrôleurs de
domaine qui exécutent toujours Windows Server 2008 ou Windows Server 2008 R2. Pour ce faire, vous
devez déshost la partition Corp sur le contrôleur de domaine, répliquer la partition NA, puis lire la partition
CORP à partir d’une source fiable connue. Pour ce faire, procédez comme suit :
a. Déshost la partition du GC en exécutant les commandes suivantes :
Repadmin /options du dc +disable_ntdsconn_xlate
Repadmin /unhost the DC dc=corp,dc=contoso,dc=com
b. Surveillez le journal du service d’annuaire sur le contrôleur de domaine pour l’ID d’événement
1660. Examinez le texte de l’événement pour vérifier que le contrôleur de domaine n’héberge plus
le NC CORP.
2. L’ID d’événement 1659 indique l’état de l’opération d’unhost. Ne liez pas la partition tant que vous n’avez pas
synchronisé la partition NA, comme suit :
a. Répliquez la partition NA. Une fois la partition correctement supprimée de la base de données :
lancez la réplication CORPDC.na.contoso.com en exécutant la commande suivante :
Repadmin /replicate the DC1.la.contoso.com NADC1.na.contoso.com DC=na,DC=bayer,DC=cnb
b. Lecture du NC CORP sur ce contrôleur de domaine en exécutant les commandes repadmin /add
suivantes :
Repadmin /add dc=corp,dc=contoso,dc=com DC1.la.contoso.com CorpDC1.corp.contoso.com /readonly
Repadmin /options the DC -disable_ntdsconn_xlate

Résoudre les erreurs courantes de réplication Active
Directory
Cet article contient des informations et des liens pour vous aider à résoudre les erreurs de réplication Active
Directory. Il est destiné à fournir aux administrateurs Active Directory une méthode pour diagnostiquer les
échecs de réplication et déterminer où ces échecs se produisent.
NOTE
Codes d’erreur
Pour résoudre des erreurs spécifiques, reportez-vous au tableau suivant.
C O DE D’ERREUR DE RÉP L IC AT IO N C A USE C O N N A ISSA N C ES A SSO C IÉE
8464 Ce problème se produit car la Erreur de réplication Active Directory

synchronisation partielle des 8464 : échec de la tentative de
ensembles d’attributs (PAS) est synchronisation
déclenchée lorsqu’un attribut est
ajouté à la passe.
8477 Ce code est informationnel et Résolution de l’erreur de réplication AD

représente une opération de 8477 : la demande de réplication a été
réplication Active Directory normale. Il publiée . en attente de réponse
indique que la réplication est en cours
à partir de la source et qu’elle n’a pas
encore été appliquée au réplica de
base de données du contrôleur de
8418 Les tentatives de réplication d’Active Dépannage de l’erreur de réplication

Directory lorsque les informations de AD 8418 : échec de l’opération de
schéma ne sont pas cohérentes entre réplication en raison d’une
les partenaires contrôleurs de domaine inmatmatation de schéma entre les
impliqués entraînent un état d’erreur serveurs impliqués
de non-concordance de schéma. Ce
symptôme se manifeste lui-même de
plusieurs manières. La cause sous-
jacente de l’erreur peut varier.
1908 Cette erreur a deux causes principales : Résolution de l’erreur de réplication AD

Le contrôleur de domaine de 1908 : le contrôleur de domaine pour
destination ne peut pas ce domaine n’a pas pu être trouvé
contacter un centre de
distribution de clés (KDC).
L’ordinateur rencontre des
erreurs liées à Kerberos.
8333 Cette erreur a plusieurs causes. Les Résolution de l’erreur de réplication AD

choix sont les suivants : 8333 : Objet Directory in trouvé
Altération de la base de
données, avec des erreurs
associées supplémentaires
consignées dans le journal des
événements du contrôleur de
domaine source
Objets en attente dont les
erreurs associées sont
consignées
Objets conflictuelles
Processus tiers
8589 Cette erreur se produit le plus souvent Résolution de l’erreur de réplication AD

sur un contrôleur de domaine après la 8589 : le service DS ne peut pas
suppression forcée d’Active Directory dériver un nom principal de service
par un partenaire de réplication, puis (SPN)
une nouvelle promotion avant la fin de
la réplication de bout en bout. Cette
erreur peut également se produire
lorsque vous renommez un contrôleur
de domaine et que l’attribut
serverReference n’est pas mis à jour.
1818 Le problème se produit lorsque le Résolution de l’erreur de réplication AD

contrôleur de domaine de destination 1818 : l’appel de procédure distante a
qui effectue la réplication entrante ne été annulé
reçoit pas de modifications de
réplication dans le délai de secondes
spécifié dans la clé de Registre Délai
d’arrivée à la réplication RPC.
8446 Cette erreur peut se produire lorsque Résolution de l’erreur de réplication AD

le moteur de réplication Active 8446 : l’opération de réplication n’a pas
Directory ne peut pas allouer de réussi à allouer de la mémoire
mémoire pour exécuter la réplication
Active Directory.
8240 Cette erreur indique que l’objet Résolution de l’erreur de réplication AD

spécifique est in trouver dans le 8240 : il n’existe aucun objet de ce
répertoire. Cette erreur peut se type sur le serveur
rencontrer dans les situations
suivantes :
Pendant la réplication AD
8240 signalés dans
l’événement 1126 (NTDS)
8451 État 8451 : l’opération de Erreur de réplication Active Directory

réplication a rencontré une erreur 8451 : l’opération de réplication a
de base de données à plusieurs rencontré une erreur de base de
causes. Reportez-vous à l’article données
connexe de la Base de connaissances
dans la troisième colonne.
1256 Cette erreur est consignée en raison Erreur de réplication Active Directory
d’une défaillance de la connectivité. 1256 : le système distant n’est pas
disponible.
1396 Les causes connues de cette erreur Erreur de réplication Active Directory
sont les suivantes : 1396 : Échec de l’logo : le nom du
Le nom principal de service compte cible est incorrect.
(SPN) n’existe pas dans le
catalogue global recherché par
le Centre de distribution de clés
Kerberos (KDC) pour le compte
du client qui tente de
s’authentifier à l’aide du
protocole Kerberos.
Le compte d’utilisateur ou de
service qui doit contenir le nom
principal de service recherché
n’existe pas dans le catalogue
global recherché par le KDC
pour le compte du contrôleur
de domaine de destination qui
tente de répliquer.
Le contrôleur de domaine de
destination n’a pas de secret de
l’autorité de sécurité locale
(LSA) pour le domaine du
contrôleur de domaine source.
Le SPN en cours de recherche
existe sur le compte d’un autre
ordinateur que le contrôleur de
domaine source.
1722 L’appel de procédure distante (RPC) est Erreur de réplication Active Directory
une couche intermédiaire entre le 1722 : le serveur RPC n’est pas
transport réseau et le protocole disponible
d’application. RPC lui-même n’a pas
d’informations particulières sur les
échecs. Toutefois, il tente de masquer
les échecs de protocole de couche
inférieure dans une erreur au niveau
de la couche RPC.
-2146893022 Ce code d’erreur n’est pas renvoyé par Erreur de réplication Active Directory -
Active Directory. Toutefois, il peut être 2146893022 : le nom de principal cible
renvoyé par des composants de est incorrect
couche inférieure. Il s’agit notamment
du protocole RPC, Kerberos, SSL
(Secure Sockets Layer), LSA et NT LAN
Manager (NTLM). Le code est renvoyé
pour diverses raisons.
1753 Les causes spécifiques de cette erreur Erreur de réplication Active Directory
sont les suivantes : 1753 : aucun point de terminaison
L’application serveur n’a jamais n’est disponible à partir du mappeur
démarré. de point de terminaison
L’application serveur a démarré.
Toutefois, un échec lors de
l’initialisation a empêché
l’application serveur de
s’inscrire auprès du mappeur
de point de terminaison RPC.
L’application serveur a démarré,
mais plus tard.
L’application serveur a
manuellement désinsgré ses
points de terminaison. (Cela
ressemble à la cause
précédente, mais son
occurrence était intentionnelle.
Il est peu probable que vous
receviez cette erreur pour cette
raison. Toutefois, nous
l’incluons à des fins.)
Le client RPC (c’est-à-dire, le
contrôleur de domaine de
destination) a contacté un
serveur RPC différent de celui
prévu en raison d’une erreur de
mappage nom à IP dans DNS,
WINS ou le fichier
hôte/lmhosts.
8606 L’erreur 8606 est consignée lorsque les Erreur de réplication Active Directory
conditions suivantes sont vraies : 8606 : des attributs insuffisants ont
Un contrôleur de domaine été attribués pour créer un objet
source envoie une mise à jour à
un objet (au lieu d’envoyer une
demande de création d’objet
d’origine) qui a déjà été créé,
supprimé, puis récupéré par le
garbage collection à partir de la
copie Active Directory d’un
destination.
destination a été configuré
pour s’exécuter dans une
cohérence de réplication stricte.
1127 L’erreur 8606 est consignée lorsque les Erreur de réplication Active Directory
conditions suivantes sont vraies : 1127 : lors de l’accès au disque dur,
Un contrôleur de domaine une opération de disque a échoué
source envoie une mise à jour à même après des tentatives
un objet (au lieu d’envoyer une
demande de création d’objet
d’origine) qui a déjà été créé,
supprimé, puis récupéré par le
garbage collection à partir de la
copie Active Directory d’un
destination.
destination a été configuré
pour s’exécuter dans une
cohérence de réplication stricte.
duplication de ci-dessus ?
8452 Cette erreur se produit le plus souvent Le contexte d’attribution de noms est
lorsque la topologie de réplication en cours de suppression ou n’est pas
dans un contrôleur de domaine qui répliqué à partir du serveur spécifié
démarre la réplication diffère de la
topologie de réplication définie dans la
copie Active Directory du contrôleur
de domaine de destination.
8456 ou 8457 La réplication entrante ou sortante a 2023007

été automatiquement désactivée par le
système d’exploitation en raison de
plusieurs causes racines.
8453 Cette erreur d’accès à la Erreur de réplication Active Directory

réplication a été refusée et a 8453 : l’accès à la réplication a été
plusieurs causes. refusé
8524 Il s’agit d’une erreur « catch-all » pour Erreur de réplication Active Directory
toutes les défaillances DNS possibles 8524 : l’opération DSA ne peut pas se
qui affectent Active Directory sur les poursuivre en raison d’un échec de
contrôleurs de domaine basés sur recherche DNS
Windows Server 2003 SP1.
8614 Les causes de cette erreur (et pour Résoudre l’erreur de réplication Active
l’événement de réplication NTDS 2042) Directory 8614
destination qui journalisation
l’erreur 8614 n’a pas répliqué
une partition d’annuaire
entrante à partir d’un ou
plusieurs contrôleurs de
domaine source pour le
nombre de jours de durée de
vie de Tombstone.
L’heure système sur le
destination a été déplacée ou a
fait un saut dans la durée de
vie de Tombstone un ou
plusieurs jours à l’avenir après
la dernière réplication réussie.
8545 Cette erreur de réplication Active Erreur de réplication Active Directory

Directory est consignée lorsque le 8545 : La mise à jour de réplication n’a
contrôleur de domaine source tente pas pu être appliquée
d’envoyer des modifications pour un
objet récemment migré lorsque l’objet
du contrôleur de domaine de
destination est présent dans une
partition différente.
5 Cette erreur de réplication Active Erreur de réplication Active Directory 5

Directory a plusieurs causes. - Accès refusé
ID d’événement
Pour résoudre les problèmes d’ID d’événement spécifiques, reportez-vous au tableau suivant :
ID D’ÉVÉN EM EN T C A USE A RT IC L E C O N N EXE
ID d’événement 1311 Résolution des problèmes de topologie Comment résoudre les problèmes des
de réplication messages d’ID d’événement 1311 sur
Windows domaine
ID d’événement 1388 ou 1988 Un objet en attente est détecté 4469619
ID d’événement 2042 Cela fait trop longtemps que cet 4469622

ordinateur n’a pas été répliqué
ID d’événement 1925 Échec de la tentative d’établissement 4469659

d’un lien de réplication en raison d’un
problème de recherche DNS
ID d’événement 2087 Échec de la recherche DNS à l’origine 4469661

de l’échec de la réplication
ID D’ÉVÉN EM EN T C A USE A RT IC L E C O N N EXE
ID d’événement 2088 Échec de la recherche DNS avec succès ID d’événement 2088 : échec de
de la réplication recherche DNS avec succès de la
réplication
References
Dépannage des problèmes de réplication d'Active Directory
Dépannage des problèmes de réplication d'Active Directory
Diagnostiquer les échecs de réplication Active Directory
Résoudre l’erreur de réplication du contrôleur de
domaine 1727 - L’appel de procédure distante a
échoué et ne s’est pas exécuté
Cet article résout le message d’erreur « L’appel de procédure distante a échoué et n’a pas été exécuté ». Cette
erreur se produit lors de la réplication du contrôleur de domaine (DC) sur Windows Server.
S’applique à : Windows 10, version 2004, Windows 10, version 1909, Windows Server 2019, Windows Server
2012 R2, Windows Server 2016
Symptômes
Cette erreur de réplication Active Directory (AD) apparaît dans une ou plusieurs des formes suivantes :
Décimal : 1727
Hex : 0x6bf
Symbolique : RPC_S_CALL_FAILED_DNE
Message d’erreur : l’appel de procédure distante a échoué et ne s’est pas exécuté.
Cause
Ce problème se produit pour l’une des raisons suivantes :
Problème de connectivité réseau entre les deux contrôleurs de domaine. Pour plus d’informations, voir les
sections suivantes.
Un problème de performances induit par la charge sur le partenaire de réplication. Ce problème est moins
courant et est souvent temporaire. Pour plus d’informations, voir les sections suivantes.
À propos du problème de connectivité réseau
Ce problème se produit lorsque le partenaire de réplication de dc ne peut pas terminer la connexion RPC au
service RPC de réplication AD (DRSR UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2). Plus précisément, le
partenaire de réplication peut se lier au mappeur de point de terminaison RPC, mais ne peut pas terminer la
liaison RPC DRSR.
Les causes racines possibles sont les suivantes :
pare-feu
routeurs
Optimiseurs de wan
autres périphériques réseau intermédiaires
pilotes de filtre réseau
À propos du problème de performances
Ce problème se produit lorsque l’une des conditions suivantes est vraie :
Le serveur est en souffrance et ne répond pas au message TCP ACK ou au message de réponse. Ainsi,
l’expéditeur abandonne la session TCP.
Le réseau est trop lent ou peu fiable. Il ne peut pas remettre le TCP ACK ou le message de réponse.
Résolution
Pour résoudre ce problème, déterminez les modifications récentes qui auraient une incidence sur le réseau entre
les deux DCS et annuler ces modifications si possible. S’il n’y a pas de modifications récentes, vous devez
examiner complètement la connectivité réseau RPC entre les deux DCS. Pour ce faire, suivez les étapes de
résolution des problèmes de haut niveau ou les étapes de dépannage détaillées.
Étapes de résolution des problèmes de haut niveau

1. Prenez une capture réseau double côté pendant que vous reproduisez le problème. Pour ce faire,
a. Démarrez une capture réseau sur les deux DCS.
b. Démarrez manuellement la réplication entre les deux DCS.
c. Arrêtez les deux côtés de la trace lorsque vous recevez l’erreur.
2. Examinez la conversation RPC entre les deux DCS. Déterminez s’il existe un cas dans lequel le message
envoyé à partir du dc du demandeur n’incurie pas de réponse du partenaire de réplication.
NOTE
Parfois, il existe une réponse partielle qui inclut l’ACK TCP de retour pour le message de demande. Toutefois, le trafic a été
modifié ou la réponse n’arrive pas au dc du demandeur. Par conséquent, la pile TCP ne reçoit pas de ACK.
Étapes de dépannage détaillées

Démarrez une capture réseau sur les deux DCS avant de suivre les étapes suivantes pour tester la connectivité
DC.
Tester la connectivité DC source à partir du dc de destination
Suivez les étapes suivantes sur le dc de destination :
1. Vérifiez si le dc source est à l’écoute sur le port TCP 135. Pour ce faire, exécutez la PortQry.exe -n -e 135
commande.
Si l’état du port est FILTERED, l’échec de la réplication AD est susceptible d’échouer et de renvoyer l’erreur
1722 à la place. Essayez de résoudre l’erreur 1722, puis vérifiez si la réplication AD réussit. Si le problème
persiste, redémarrez les étapes de dépannage détaillées.
Si l’état n’est pas FILtré, les commandes retournent la base de données de mapper du point de
terminaison RPC. Recherchez l’interface DRS d’annuaire MS NT pour trouver le port de plage supérieure
dans la base de données de point de terminaison mappée que le dc source écoute pour la réplication AD.
Vous pouvez obtenir une ou plusieurs entrées. Notez les ports pour les ncacn_ip_tcp.
Par exemple, vous obtenez quelque chose qui ressemble à l’exemple suivant, qui présente deux ports de
plage supérieure 49159 et 49160 :
UUID : e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS Interface
ncacn_ip_tcp:2012dc[49159] UUID : e3514235-4b06-11d1-ab04-00c04fc2dcd2 MS NT Directory DRS
Interface ncacn_ip_tcp:2012dc[49160]
NOTE
Les ports de plage supérieure sont spécifiques à DC et sont affectés dynamiquement. Toutefois, un administrateur
peut coder en dur le port utilisé pour la réplication AD à l’aide de la valeur de Registre suivante.
Valeur de Registre : port TCP/IP
2. Testez la connectivité des ports TCP aux ports de plage supérieure que vous notez. Pour ce faire, exécutez
la commande suivante :
PortQry.exe -n <SourceDC> -e <Upper_Range_Port_Number>
Par exemple, vous exécutez les commandes suivantes :
PortQry.exe -n 2012dc -e 49159

PortQry.exe -n 2012dc -e 49160
Si l’état du port est FILtré, examinez le suivi réseau que vous avez capturé pour déterminer où le paquet
est bloqué.
3. Testez le DNS. Vérifiez que le DC de destination peut résoudre les enregistrements CNAME et HOST de la
source DC. Vérifiez également que l’adresse IP résolue est l’adresse IP réelle de la source DC. Si DNS
pointe vers une ancienne adresse IP ou une adresse IP non valide, une tentative de connexion RPC est
effectuée vers un DC source incorrect.
Tester la connectivité DC de destination à partir de la source DC
Répétez les étapes 1 à 3 sur le DC source.
Comment résoudre les problèmes de messages d’ID
d’événement 1311 sur Windows domaine
Cet article explique comment résoudre les problèmes de messages de l’ID d’événement 1311 dans le journal
des événements du service d’annuaire sur Windows domaine.
Symptômes
Le contrôle de cohérence des connaissances (KCC) construit et maintient la topologie de réplication pour Active
Directory. Pour ce faire, le KCC examine la somme de tous les contextes d’attribution de noms qui résident dans
la forêt et toutes les contraintes définies par l’administrateur pour le site, le lien de site et le coût de lien.
Si un domaine Active Directory, un schéma, une configuration, une partition d’application ou les contextes
d’attribution de noms de catalogue global ne peuvent pas être répliqués entre des contrôleurs de domaine ou
des sites, un message d’ID d’événement 1311 semblable au suivant est consigné dans le journal des
événements du service d’annuaire :

Date : MM/JD/AAA
Heure : HH:MM:SS AM| PM
Utilisateur : N/A
Ordinateur : <domain_controller_name>
Description :
L’analyseur de cohérence du service d’annuaire a déterminé qu’il n’existe pas suffisamment de connectivité
physique publiée via le Gestionnaire des sites et des services Active Directory pour créer une arborescence
couvrante connectant tous les sites contenant la partition CN= <partition name> ,DC= ,DC=com, ou (b) la
réplication ne peut pas être effectuée avec un ou plusieurs serveurs critiques afin que les modifications se
propagent sur tous les sites (le plus souvent en raison de l’injoignable des <root domain of forest>
serveurs).
Cause
Ce comportement se produit si une ou plusieurs des conditions suivantes sont vraies :
Le pontage de liaison de site est activé sur un réseau qui ne prend pas en charge la connectivité réseau
physique entre deux contrôleurs de domaine dans différents sites connectés par un lien KCC.
Un ou plusieurs sites ne sont pas contenus dans des liens de site.
Les liens de site contiennent tous les sites, mais ceux-ci ne sont pas interconnectés. Cette condition est
appelée liens de site disjoints.
Un ou plusieurs contrôleurs de domaine sont hors connexion.
Les contrôleurs de domaine Bridgehead sont en ligne, mais des erreurs se produisent lorsqu’ils essaient
de répliquer un contexte d’attribution de noms requis entre les sites Active Directory.
Les têtes de pont préférées définies par l’administrateur sont en ligne, mais elles n’hébergent pas les
contextes d’attribution de noms requis.
Les têtes de pont préférées sont définies correctement par l’administrateur, mais elles sont actuellement
hors connexion.
Le serveur tête de pont est surchargé soit parce qu’il est sous-resserrisé, trop de sites de succursale
tentent de répliquer les modifications à partir du même contrôleur de domaine hub, soit les planifications
des liaisons de sites sont trop fréquentes.
Le KCC a créé un chemin d’accès différent autour d’une défaillance de connexion de site à site, mais il
retente la connexion défaillante toutes les 15 minutes, car elle est en mode de conservation des
connexions.
Les causes courantes des messages de l’ID d’événement 1311 sont en deux catégories : configuration logique
incorrecte et défaillance de l’infrastructure. Les messages de l’ID d’événement 1311 sont enregistrés lorsqu’une
configuration logique incorrecte ou une erreur de réplication se produit.
Configuration logique incorrecte
Une configuration logique est incorrectement configurée lorsque les informations dans le contexte
d’appellation de configuration (NC) (visibles dans le logiciel enfichable Sites et services) ne
correspondent pas à la topologie physique du réseau qui héberge la forêt Active Directory. Par exemple,
un site peut ne pas être correctement défini, les sites manquants dans les liens de site peuvent être inclus,
les liens de site peuvent ne pas être interconnectés ou des têtes de pont incorrectes peuvent être
sélectionnées par l’administrateur.
Échec de l’infrastructure
Une défaillance d’infrastructure se produit en raison de l’un des événements suivants :
Une liaison de réseau large (WAN) échoue.
Un contrôleur de domaine qui héberge un contexte d’attribution de noms nécessaire est hors
connexion.
Un échec de réplication se produit pour un ou plusieurs contextes d’attribution de noms.
Le partenaire entrant pour la réplication a désactivé la réplication sortante.
Résolution
Pour résoudre les problèmes des messages de l’ID d’événement 1311, utilisez les méthodes suivantes.
Déterminez si les messages de l’ID d’événement 1311 sont spécifiques au site ou à l’échelle de la forêt.
Déterminez si le pontage de liaison de site est allumé et si le réseau est entièrement acheminé.
Vérifiez que tous les sites sont définis dans les liens de sites.
Détectez et supprimez les têtes de pont préférées.
Résoudre les échecs de réplication Active Directory dans la forêt.
Déterminez si les serveurs sources sont surchargés.
Déterminez si les liens de site sont disjoints.
Supprimez les connexions si le KCC est en mode « Connection Keeping ».
Déterminer si les messages de l’ID d’événement 1311 sont spécifiques au site ou à l’échelle de la forêt
Déterminez si les messages de l’ID d’événement 1311 sont enregistrés sur tous les contrôleurs de domaine ISTG
(Générateur de topologies intersesses) dans la forêt ou uniquement sur les contrôleurs de domaine ISTG
spécifiques au site. Pour localiser les contrôleurs de domaine ISTG, utilisez lLdp.exe pour rechercher les attributs
suivants :
DN de base : CN=Sites,CN=Configuration,DC=RootDomainName,DC=Com
Filter: (cn=NTDS Site Paramètres)
Étendue : Sous-arbre
Attributs : interSiteTopologyGenerator
Pour déterminer l’étendue de l’événement, utilisez l’une des méthodes suivantes :
Examinez les journaux des événements du service d’annuaire d’un nombre approprié de contrôleurs de
domaine ISTG dans la forêt.
Utilisez l’outil Eventcombmt.exe (disponible auprès des services de support technique Microsoft) pour
rechercher des messages d’ID d’événement 1311 sur un nombre approprié de contrôleurs de domaine
ISTG dans la forêt.
Déterminer si le pontage de liaison de site est allumé et si le réseau est entièrement acheminé
Lorsque vous activez le pontage de liaison de site dans le logiciel en ligne Sites et services Active Directory, vous
devez vous assurer que tout site défini dans Active Directory dispose d’une connexion réseau entièrement
acheminée vers tout autre site défini par l’administrateur. Si le KCC crée un lien de connexion entre deux sites
non connectés dans lesquels le pontage de lien de site est activé, les messages de l’ID d’événement 1311
peuvent être enregistrés.
Le pontage de lien de site est activé dans Active Directory si les conditions suivantes sont vraies :
La case à cocher Ponter tous les liens de site est sélectionnée pour le protocole IP et le protocole SMTP
dans le logiciel en ligne Sites et services Active Directory.
L’attribut Options pour le protocole IP et le protocole SMTP est NULL ou est définie sur 0 (zéro) pour les
chemins d’accès DN (Domain Name) suivants :
CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC= root domain of forest
CN=SMTP,CN=Transports inters site,CN=Sites,CN=Configuration,DC= domaine racine de la forêt
Pour déterminer s’il existe une connexion réseau entièrement acheminée entre deux sites, contactez votre
administrateur nos, votre administrateur réseau ou votre architecte Active Directory.
Si le pontage de liaison de site est activé dans un environnement non acheminé, rendez le réseau entièrement
acheminé ou désactivez le pontage de liaison de site, puis créez les liens de sites et les ponts de liens de sites
que vous devez utiliser. Attendez deux fois l’intervalle de réplication le plus long dans la forêt. Si les messages de
l’ID d’événement 1311 continuent d’être enregistrés ou si le pontage de liaison de site est activé dans un réseau
entièrement acheminé, continuez jusqu’à la méthode « Vérifier que tous les sites sont définis dans les liens de
sites ».
Par défaut, le pontage de lien de site est allumé. En outre, les recommandations recommandées vous
recommandent de maintenir le pontage de lien de site sous l’effet d’un pontage.
Le diagramme suivant utilise des signes plus (+) et moins (-) pour illustrer les connexions réseau physiques
entre les sites Active Directory. Site AZ is listed in site link WEST and site GA is listed in site link EAST, but sites
AZ and GA don’t have fully routed network connections to sites WA and NY in an Active Directory configuration
where site link bridging is enabled.
WA <-- Site Link WANY --> NY
+- +-
+ - + -
+ - + -
+ - + -
CA + + + AZ IL + + + GA
Site Link WEST Site Link EAST
Vérifier que tous les sites sont définis dans les liens de sites
Chaque site défini dans Active Directory doit être hébergé ou résider dans un lien de site. Par exemple, si des
sites WA, CA, AZ, NY, IL et GA sont définis et que des liaisons de site WEST, EAST et WANY sont définies, les
messages d’ID d’événement 1311 sont enregistrés si un site (par exemple, AZ ou GA) n’est pas répertorié dans
un lien de site où les sites sont connectés physiquement. Les sites sont orphelins lorsque les sites d’un lien de
sites supprimé ne sont pas ajoutés à un lien de site existant approprié.
WA -- Site Link WANY -- NY

/ /
/ /
/ /
CA (AZ) IL (GA)
Site Link WEST Site Link EAST
Étant donné que les sites AZ et GA ne sont répertoriés dans aucun lien de site, ils sont orphelins et le KCC ne les
prend pas en compte lorsqu’il construit la topologie de réplication pour Active Directory.
La repadmin /showism commande est utile pour localiser des sites mal configurés. La sortie de
repadmin /showism la commande ressemble à l’exemple suivant à partir d’une forêt nommée corp:
==== TRANSPORT CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=corp,DC=com

CONNECTIVITY INFORMATION FOR 3 SITES: ====
0, 1, 2
( 0) CN=US-NC,CN=Sites,CN=Configuration,DC=corp,DC=com 0:0:0, 100:15:0, 200:15:0
( 1) CN=US-TX,CN=Sites,CN=Configuration,DC=corp,DC=com 100:15:0, 0:0:0, 100:15:0
( 2) CN=US-WA,CN=Sites,CN=Configuration,DC=corp,DC=com 200:15:0, 100:15:0, 0:0:0
NOTE
Contrairement aux autres arguments de la commande repadmin, vous ne pouvez pas exécuter repadmin /showism la
commande à partir d’un ordinateur distant. Vous devez exécuter la commande à partir de la console du contrôleur de
domaine que vous souhaitez examiner (dans la plupart des cas, il s’agit du contrôleur de repadmin /showism domaine
ISTG).
Pour chaque site configuré pour la réplication IP ou la réplication SMTP (non affichée), la commande renvoie
une matrice de site qui représente les connexions à tous les sites de la repadmin /showism forêt. Chaque entrée
de la matrice de site contient trois nombres délimités par des deux-points (:) qui représentent le coût, l’intervalle
de réplication et les options de chaque lien de réplication vers un autre site dans la forêt Active Directory. Les
nombres d’une entrée apparaissent dans l’ordre suivant :
Coût : Inter valle de réplication : Options
La valeur Coût indique la préférence pour un lien réseau pour la réplication des informations d’annuaire
entre les sites. L’administrateur utilise le logiciel en ligne Sites et services Active Directory pour définir la
valeur coût de chaque lien de site.
La valeur de l’inter valle de réplication indique la fréquence de réplication du lien en minutes.
La valeur Options indique les options pour le lien de site, y compris la notification de lien de site.
NOTE
Lorsque vous dépanner les messages de l’ID d’événement 1311, vous pouvez ignorer la valeur Options.
Dans l’exemple de la forêt, le pontage de liaison de site est activé et la forêt contient corp.com trois sites Active
Directory :
Site 0 : US-NC, site non découvert qui utilise la liaison TX<->NC pour se connecter au site 1 (US-TX).
Site 1 : US-TX, qui héberge deux contrôleurs de domaine.
Site 2 : US-WA, site couvert qui utilise le lien TX<->WA pour se connecter au site 1 (US-TX).
Chaque matrice de site contient une entrée 0:0:0 qui fait référence à elle-même. Une entrée qui contient des
nombres positifs pour la valeur de coût et la valeur de l’intervalle de réplication (par exemple, 200:15:0 ou
100:15:0) indique que la connexion au site est bonne. Une entrée -1:0:0 indique que la connexion au site ne
fonctionne pas. Ce qui se produit si une ou plusieurs des conditions suivantes sont vraies :
Le protocole de réplication n’est pas utilisé. Par exemple, si la réplication SMTP n’est pas configurée, les
entrées de la partie SMTP de la matrice s’affichent toutes sous la même taille que /SHOWISM -1:0:0.
Le site n’héberge aucun contrôleur de domaine (il s’agit d’un site découvert).
Le site n’est pas inclus dans un lien de site.
Si le pontage de liaison de site est activé et que la commande repadmin /showism renvoie -1:0:0 entrées pour
un ou plusieurs sites Active Directory couverts, assurez-vous que les sites affectés sont répertoriés dans un lien
de site.
Un site avec un complément complet d’entrées -1:0:0 et une entrée 0:0:0 est orphelin, sauf si le site est
découvert (aucun contrôleur de domaine ne réside dans ce site). Lorsque vous dépanner les messages de l’ID
d’événement 1311, enregistrez les noms de tous les sites orphelins, mais n’enregistrez pas les noms des sites
non découverts.
Si le pontage de liaison de site est désactivé, les entrées -1:0:0 sont moins significatives. Si c’est le cas, vous
devez déterminer manuellement si chaque site est inclus dans un lien de site. Pour ce faire, notez la liste des
sites et des liens de sites, puis mapz manuellement chaque site sur un lien de site.
NOTE
La repadmin /showism commande renvoie toujours les entrées -1:0:0 pour un site non découvert.
Dans l’exemple suivant, le pontage de lien de site est activé dans la forêt et le lien de repadmin /showism
corp.com site TX<->wa a été supprimé. Le site 2 (US-WA) est orphelin de tous les autres sites de la forêt et doit
être ajouté à un lien de site approprié.

CONNECTIVITY INFORMATION FOR 3 SITES: ====
0, 1, 2 ( 0) CN=US-NC,CN=Sites,CN=Configuration,DC=corp,DC=com 0:0:0, 100:15:0, -1:0:0
( 1) CN=US-TX,CN=Sites,CN=Configuration,DC=corp,DC=com 100:15:0, 0:0:0, -1:0:0
( 2) CN=US-WA,CN=Sites,CN=Configuration,DC=corp,DC=com -1:0:0, -1:0:0, 0:0:0
Détecter et supprimer les têtes de pont préférées

Étant donné que la sélection correcte de la tête de pont est difficile dans les forêts à domaines multiples et que
Windows 2000 dispose d’une bonne logique de point d’accès en cas de mise hors connexion d’une tête de pont
sélectionnée par le KCC, Microsoft recommande vivement de ne pas définir les serveurs têtes de pont préférés.
Pour rechercher des serveurs têtes de pont préférés :
1. Utilisez lLdp.exe de ligne de commande pour effectuer une recherche LDAP pour les critères suivants :
Chemin d’accès DN : cn=sites,cn=configuration,dc=<root domain of forest>
ObjectClass: server
Attributs : bridgeheadTransportList
2. Utilisez la commande FINDSTR par rapport à un fichier d’exportation LDIFDE à partir du conteneur
CN=Sites,CN=Configuration :
LDIFDE CN=SITES,CN=CONFIGURATION,DC= <Root domain in forest> SITEDUMP. LDF
FINDSTR /i « bridgeheadTransportList » SITEDUMP. LDF
Si la recherche renvoie des résultats, notez le nom du serveur dans le chemin d’accès du nom de
domaine dans lequel l’attribut bridgeheadTransportList est rempli.
Si vous trouvez des serveurs têtes de pont préférés, utilisez le logiciel en snap-in Site et Services pour les
supprimer, puis patientez deux fois l’intervalle de réplication maximal dans la forêt. Si les messages de
l’ID d’événement 1311 continuent d’être enregistrés, continuez à la méthode suivante.
Résoudre les échecs de réplication Active Directory dans la forêt
La réplication Active Directory nécessite la réplication transitive de tous les contextes d’attribution de noms dans
la forêt à tous les contrôleurs de domaine qui répliquent une partition commune.
Résolvez les échecs de réplication pour les contrôleurs de domaine en ligne aussi rapidement que possible, en
particulier ceux qui hébergent des contextes d’attribution de noms spécifiques dans une forêt (par exemple, le
seul contrôleur de domaine pour un domaine particulier dans la forêt). En dernier recours, si vous ne pouvez
pas faire répliquer un contrôleur de domaine, supprimez-le de la forêt.
Si un contrôleur de domaine est hors connexion pendant moins de jours que le numéro de durée de vie de
tombstone (par défaut, 60), mettre le contrôleur de domaine en ligne et le forcer à répliquer, ou en dernier
recours, le supprimer de la forêt.
Si un contrôleur de domaine est hors connexion ou ne réplique pas les modifications entrantes pendant plus de
jours que le numéro de durée de vie de tombstone, ne le modifiez pas. Supprimez-le immédiatement de la forêt.
Pour plus d’informations sur la valeur TombstoneLifetime, cliquez sur les numéros d’article suivants pour
afficher les articles de la Base de connaissances Microsoft :
216993 durée de vie utile d’une sauvegarde de l’état système d’Active Directory
314282 objets en attente peuvent rester après la mise en ligne d’un serveur de catalogue global hors date
Lorsque vous souhaitez découvrir et résoudre les problèmes de réplication, les outils suivants peuvent être
utiles :
repadmin /failcache : exécutez cette commande à partir de la console de chaque contrôleur de domaine
ISTG dans la forêt pour découvrir les échecs de réplication des têtes de pont dans le site pour ce groupe
ISTG.
NOTE
Vous pouvez également exécuter cette commande à distance sur d’autres contrôleurs de domaine ISTG dans la
forêt.
repadmin /showreps : Exécutez cette commande à partir de la console de chaque contrôleur de domaine
ISTG dans la forêt pour analyser la réplication de contrôleurs de domaine spécifiques exposés par la
repadmin /failcache commande.
dcdiag /test:intersite /e /q : cette commande teste la connectivité inters site pour les contrôleurs de
domaine tête de pont dans la forêt. Le jeu de résultats est limité aux contrôleurs de domaine qui sont en
cas d’erreurs avec le /q commutateur.
dcdiag /test:connectivity /e /q : cette commande teste la résolution de noms et la connectivité ldap/rpc
à tous les contrôleurs de domaine dans la forêt. Le jeu de résultats est limité aux contrôleurs de domaine
qui sont en cas d’erreurs avec le /q commutateur.
Examinez le journal des événements du service d’annuaire sur les contrôleurs de domaine ISTG et les
serveurs Bridgehead, en utilisant les paramètres suivants pour les niveaux de diagnostic NTDS :
Un contrôle de cohérence des connaissances : 3
Cinq événements de réplication : 3
Traitement interne : 1
La repadmin /failcache commande répertorie les échecs de réplication que le KCC connaît. La sortie de la
repadmin /failcache commande est divisée en deux sections :
Le cache KCC Link Failures répertorie les erreurs pour les liens de connexion existants. Le contrôleur de domaine
ISTG importe les données showreps (repsfroms) pour chaque serveur tête de pont de son site. Toutefois, le
contrôleur de domaine ISTG ne liste pas les erreurs. Le cache d’échec de liaison est vidé au début de chaque run
KCC et rechargé au cours de l’utilisation en cours.
Le cache des échecs de connexion KCC répertorie les tentatives infructueuses de construction d’objets de
connexion entre les contrôleurs de domaine (reps de ou reps vers). Lorsque vous exécutez la commande à partir
du contrôleur de domaine ISTG, elle répertorie les entrées importées à partir des têtes de pont
repadmin /failcache dans le site. Au début de chaque utilisation du KCC, le KCC examine chaque entrée dans le
cache d’échec de connexion et tente d’établir une connexion DsBind vers le serveur défaillant. Si la liaison
réussit, l’entrée est supprimée.
La repadmin /failcache commande diffère de la commande de deux repadmin /showreps manières :
La repadmin /showrepscommande affiche le contexte d’attribution de noms défaillant. La
repadmin /failcache commande ne l’est pas.
Les données de repadmin /failcache la commande ne sont pas répliquées entre les contrôleurs de domaine.
L’exemple suivant montre un exemple de sortie de la repadmin /failcache commande.
Z : > repadmin /failcache ==== KCC CONNECTION FAILURES >

==============================
(aucun)
==== KCC LINK FAILURES > ====================================
USA-WA-24\C-24-DC03 DC OBJECT GUID: 134244cd-26be-4944-82a7-ac3eb74fc02f Aucun échec. USA-
WA-24\B-24-DC02 DC object GUID: 21b050d6-33b5-424d-aa9b-060fe209233d No Failures. USA-WA-
24\Z-24-DC-05 DC OBJECT GUID: bfb3b008-3849-4e5d-81d8-53dbb76d587a Aucun échec.
Déterminer si les serveurs sources sont surchargés

Un contrôleur de domaine surchargé avec un grand nombre de partenaires de réplication directe ou une
planification de réplication trop agressive peut créer un journal des travaux en souffrance dans lequel certains
partenaires ne reçoivent jamais de modifications d’un contrôleur de domaine hub. Dans la sortie de la
commande, les contrôleurs de domaine partenaires des contrôleurs de domaine source surchargés apparaissent
avec l’état repadmin /showreps Jamais.
Pour résoudre ce problème, reizez le matériel, reconfigurez les liens de site et reconfigurez les liaisons de site ou
les planifications de connexion si nécessaire pour réduire la charge sur les contrôleurs de domaine surchargés.
Déterminer si les liens de site sont disjoints
Les liens de site disjoints sont une configuration Active Directory dans laquelle la topologie est décomposée en
deux parties ou dans laquelle certains sites ne sont pas répliqués car les définitions de site et les définitions de
liens de site sont incorrectes. Par exemple, le diagramme suivant illustre une configuration dans laquelle
Sitelink_ABC contient les sites A, B et C et les Sitelink_DEF contient les sites D, E et F, mais aucun lien de site ne
connecte les sites de Sitelink_ABC à l’un des sites de Sitelink_DEF. Pour résoudre la condition de liens de site
disjoints, un nouveau lien de site doit connecter au moins un site dans Sitelink_ABC avec au moins un site dans
Sitelink_DEF (par exemple, un nouveau lien de site entre le site A et le site D).
A D
/ \ / \
/ \ / \
/ \ / \
B C E F
Sitelink_ABC Sitelink_DEF
Le diagramme suivant illustre une autre configuration possible de liens de sites disjoints. Dans ce cas, un
nouveau lien de site doit joindre n’importe quel site dans Sitelink_ABDC avec au moins un site dans Sitelink_FG
(par exemple, un nouveau lien de site entre le site A et le site F) pour résoudre la condition de liens de sites
disjoints.
A F
/ \ \
/ \ \
/ \ \
B C \
\ / \
\ / \
\ / \
D G
Sitelink_ABDC Sitelink_FG
Les liens de site disjoints sont la configuration incorrecte la plus difficile à résoudre. Recherchez les liens de site
disjoints uniquement après avoir exclu toutes les autres causes connues. Utilisez un crayon et du papier pour
représenter un graphique de la topologie de site et localiser les sites orphelins.
Supprimer des connexions si le KCC est en mode Conserver la connexion
Si le KCC crée un chemin d’accès différent autour d’une défaillance de connexion de site à site, mais qu’il retentre
la connexion défaillante toutes les 15 minutes car il est en mode de conservation des connexions, supprimez
toutes les connexions rompues et laissez le KCC les reconstruire. Attendez deux fois la planification de réplication
la plus longue dans la forêt.
Terminologie et concepts
Serveur Tête de pont : n’importe quel contrôleur de domaine dans un site Active Directory qui réplique
une partition Active Directory (par exemple, schéma, configuration, domaine, partition d’application ou
catalogue global) sur un contrôleur de domaine dans un autre site Active Directory.
Une tête de pont est sélectionnée pour chaque partition d’annuaire, domaine ou partition d’application
unique dans un site Active Directory, de sorte qu’un site qui héberge trois domaines différents possède
trois serveurs têtes de pont dans le site.
Les contrôleurs de domaine répliquent tous les contextes d’attribution de noms en commun avec leurs
partenaires de réplication directe, de sorte qu’un contrôleur de domaine dans le domaine « corp.com »
réplique CN=SCHEMA et CN=CONFIGURATION en plus du contexte d’appellation de domaine «
corp.com » avec son partenaire tête de pont intersessage.
Générateur de topologie inters site (ISTG) : pour chaque site Active Directory, un seul serveur, appelé ISTG,
est désigné pour créer la topologie de réplication intersessage.
Site non découvert : site Active Directory défini dans le logiciel en ligne Sites et services qui ne contient
actuellement aucun contrôleur de domaine Windows 2000. Un site non découvert peut attendre que son
contrôleur de domaine arrive à partir d’un site intermédiaire. En outre, un site peut être défini comme
non découvert pour fournir la préférence de site pour les opérations clientes.
Sortie tronquée de la commande REPADMIN /SHOWISM

Dans certains environnements, la commande de la build 2195 de Windows se quitte prématurément pendant
l’exécution et sa sortie est tronquée en raison d’une erreur repadmin /showism interne. Par exemple, la partie
supérieure de cette sortie réussie d’un contrôleur de domaine dans le domaine indique que 128 sites sont
définis /SHOWISM corp.com (0-127).

INFORMATIONS DE CONNECTIVITÉ POUR 128 SITES : ====
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,
29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43,
44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58,
59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103,
104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118,
119, 120, 121, 122, 123, 124, 125, 126, 127
Dans l’exemple suivant, la sortie s’arrête au milieu de la ligne repadmin /showism pour le site 115,
CN=HeadQuarters.
Tous les DCS dans le site CN=Headquarters,CN=Sites,CN=Configuration,DC=corp,DC=com (avec trans

hosting NC) sont candidats tête & de pont. (115)
CN=headquarters,CN=Sites,CN=Configuration,DC=corp,DC=com -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -
1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0,
-1:0:0, -1:0:0, -1:0:0, -1:0:0, -1:0:0, 100:0:0, 150:0:0, 150:0:0, 100:0:0,
Pour résoudre ce problème de troncation, obtenez une version mise à jour du fichier Repadmin.exe auprès des
services de support technique Microsoft (PSS).
Résoudre les erreurs de la base de données Jet et
les étapes de récupération
Cet article présente les messages d’erreur de base de données Jet et les étapes de résolution des problèmes.
Résumé
Lors du démarrage du système d’exploitation, de l’installation/désinstallation du contrôleur de domaine ou de la
réplication Active Directory, vous pouvez rencontrer des messages d’erreur Jet. Cet article présente les messages
d’erreur Jet et leurs solutions.
Messages d’erreur
-501 JET_errLogFileCorrupt
Cause
Le matériel a endommagé les E/S lors de l’écriture ou le matériel a perdu son purge , ce qui a provoqué
l’inutilisable du journal. En règle générale, la base de données (DB) est endommagée.
Résolution
Restituer la base de données à partir d’une sauvegarde correcte connue ou réinstaller le contrôleur de domaine
( DC).
-510 JET_errLogWriteFail / Échec d’écriture dans le fichier journal
Cause
Un échec d’écriture du journal s’est produit. Ce problème peut être dû à l’une des raisons suivantes :
Un contrôleur, un disque dur ou tout autre matériel ne répond plus aux commandes de disque.
Les logiciels, tels que les logiciels antivirus, ont créé des verrous sur les fichiers journaux Active Directory.
Résolution
1. Un redémarrage du serveur restaure l’accès s’il s’agit d’un problème matériel. Si le problème se produit
fréquemment, vous pouvez mettre à niveau le microprogramme, remplacer le contrôleur ou remplacer le
disque dans cet ordre.
2. Pour un problème qui est dû à un logiciel, arrêtez les services qui créent des verrous sur les fichiers dans
le système de fichiers. Par exemple, déterminez si un logiciel antivirus entraîne des verrous sur les fichiers
journaux Active Directory. Assurez-vous que les fichiers appropriés ont été ajoutés à la liste d’exclusion
antivirus. Windows Server 2016 exclure automatiquement certains fichiers et dossiers de l’analyse
antivirus, voir Liste des exclusions automatiques. Pour Windows Server 2012 R2, voir :
Recommandations en matière d’analyse antivirus Enterprise ordinateurs exécutant actuellement des
versions de Windows
L’ID d’événement 2108 et l’ID d’événement 1084 se produisent pendant la réplication entrante
d’Active Directory dans Windows 2000 Server et Windows Server 2003
Exclusions de fichiers et de dossiers recommandées pour Microsoft Forefront Client Security,
Forefront Endpoint Protection 2010 et Microsoft System Center 2012 Endpoint Protection
Si les étapes 1 et 2 ne corrigent pas le problème, déterminez si une application ou un service non-Microsoft est
à l’origine du problème en les désactivant. Pour ce faire, procédez comme suit :
1. Appuyez Windows + R. Entrez MSCONFIG , puis cliquez sur OK . Sous l’onglet Ser vices , sélectionnez
Masquer tous les ser vices Microsoft . Cochez la case pour les services tiers.
2. Désactivez tous les éléments de démarrage activés.
-528 JET_errMissingLogFile
Cause
Cela peut être dû à un arrêt inattendu provoqué par une coupure de courant ou un autre arrêt inattendu. Les
autres causes incluent les modifications apportées par l’administrateur aux fichiers journaux (par exemple, la
copie d’une ancienne copie) ou les logiciels de sauvegarde/restauration endommagés (si immédiatement après
une restauration).
Résolution
Restituer la base de données à partir d’une sauvegarde connue ou réinstaller le dc.
-543 JET_errRequiredLogFilesMissing
Voir -528 /JET_errMissingLogFile (ci-dessus).
Cause
L’administrateur a modifié les journaux ou perdu le purgement d’I/S à l’arrêt.
-550 JET_errDatabaseDirtyShutdown
Cause
-551 JET_errConsistentTimeMismatch
Cause
-567 JET_errDbTimeTooNew
Cause
Le sous-système de disque a perdu une ou plusieurs données, probablement lors d’un blocage ou d’un arrêt
non planifié.
Résolution
Vérifiez la sauvegarde de la batterie pour le cache disque.
Erreur -1018 JET_errReadVerifyFailure/Checksum sur une page de base de données
Cause
La DB est endommagée en raison d’une défaillance matérielle.
Résolution
Évaluez la pile de disques, y compris la carte mère/contrôleur, le microprogramme, les câbles de connexion et
les lecteurs physiques, et contactez les fournisseurs concernés pour connaître les problèmes connus.
Comparez votre configuration actuelle aux configurations de référence des fournisseurs.
Évaluez si le problème peut être résolu par les dernières mises à jour du microprogramme ou s’il a été
déclenché par une mise à jour récente du microprogramme.
Si certains DCS journalisation -1018s alors que d’autres DCS dans le même environnement ne le sont pas,
recherchez les différences dans les configurations matérielles.
Les bases de données qui enregistrent cette erreur ne peuvent pas être récupérées ou réparées par des
vérifications d’intégrité ou une analyse sémantique de base de données dans NTDSUTIL ou ESENTUTL.
Les défragmentations hors connexion peuvent résoudre le problème dans le cas peu probable où le
problème est dû à un problème de cohérence d’index.
Essayez une défragmentation hors connexion. Sinon, restituer une sauvegarde de l’état système qui prédate
l’altération. Ou rétrograder en force, effectuer un nettoyage complet des métadonnées et reomote. Si l’erreur
-1018 s’affiche, répétez l’erreur jusqu’à ce que la cause racine matérielle soit résolue.
Lorsque l’erreur Jet -1018s se produit sur des DCS virtualisés qui sont en cours d’exécution sur le même hôte
virtuel uniquement sur des ordinateurs qui utilisent un contrôleur raid à bord, l’erreur peut se produire car
l’alimentation non coupure (UPS) n’était pas suffisante pour les contrôleurs raid à bord pour valider les
modifications apportées au disque suite à une perte de puissance électrique. La solution de contournement
consiste à configurer le logiciel UPS pour arrêter les invités virtualisés en cas de perte d’alimentation électrique.
Les serveurs qui ont des contrôleurs raid dédiés (pas à bord) avec leurs propres sauvegardes de batterie ne font
pas face à l’erreur -1018 JET.
-1019 JET_errPageNotInitialized page de base de données vide
Cause
Cela ressemble à l’erreur -1018, mais est due à une perte de purge de page.
Une perte de purge peut représenter une modification critique du nom de l’usn. L’échec de l’application de la
même modification aux DCS locaux ou aux partenaires de réplication transitive peut être dangereux lorsqu’il
existe un seul chemin de réplication.
Résolution
Déployez le système d’exploitation sur des composants matériels et de sous-système de disque de classe
serveur.
Installez UPS sur l’ordinateur hôte.
Installez un contrôleur de disque avec la sauvegarde de la batterie de l’appareil.
Désactivez le cache d’écriture/écriture sur le contrôleur de lecteur.
Évitez de placer NTDS. Fichiers DIT et LOG sur les lecteurs IDE.
Les bases de données qui enregistrent cette erreur ne peuvent pas être récupérées ou réparées par des
vérifications d’intégrité ou une analyse sémantique de base de données dans NTDSUTIL ou ESENTUTL.
Les défragmentations hors connexion peuvent résoudre le problème dans le cas peu probable où le problème
est dû à un problème de cohérence d’index.
Essayez une défragmentation hors connexion. Sinon, restituer une sauvegarde de l’état système qui prédate
l’altération. Vous aussi, forcez le rétrogradation, effectuez un nettoyage complet des métadonnées, puis
reomotez. Répétez cette répétition jusqu’à ce que la cause première matérielle soit résolue.
-1021 JET_errDiskReadVerificationFailure / Le système d’exploitation ERROR_CRC à partir d’un IO de fichier
Jet error -1021 was new as of Windows Server 2008 R2. Windows versions antérieures à Windows Server 2008
R2 retournent -1022 à la place.
-1021 identifie une erreur -1018 qui s’est produite au niveau du disque. En d’autres termes, -1021 indique qu’un
lecteur de disque a renvoyé une erreur de somme de vérification erronée et qu’il s’agit de la source spécifique
du problème dans la pile de disques.
Cause
Le problème peut être dû à des blocs défectueux sur le disque dur dont le disque dur peut assurer le suivi.
Résolution
La suppression et la réinstallation d’Active Directory sur le contrôleur de domaine peuvent déclencher le
stockage des données sur des blocs sains.
-1022 JET_errDiskIO/erreur d’O disque
Cause
Erreur de disque générique. Les erreurs d’IO de disque signifient que le système d’exploitation a rencontré une
erreur non spécifique lors de l’accès au disque. Cette erreur peut être consignée lorsque les contrôleurs
retournent des erreurs génériques telles que « l’appareil ne fonctionne pas ». Certains disques et versions de Jet
retournent cette erreur pour les problèmes CRC.
Résolution
Vérifiez l’ensemble de la pile de pilotes.
-1206 JET_errDatabaseCorrupted
Cause
Cette erreur est identique à celle du fichier journal manquant/endommagé. Cette erreur indique qu’un flush
perdu s’est produit.
-1216 JET_errAttachedDatabaseMismatch
Cause
-1605 JET_errKeyDuplicate / Clé en double non illégale
Cause
Erreur ponctuelle. Cette erreur peut être due à une altération de l’index.
Résolution
Supprimez et réinstallez Active Directory sur le dc. Exécutez l’analyse de base de données sémantique
NTDUSITL. Si le problème persiste, effectuez une défragmentation hors connexion.
-1811
Cause
Résoudre des problèmes

Vous pouvez utiliser ces méthodes pour résoudre les erreurs de base de données Jet :
1. Vérifiez que toutes les bases de données Active Directory et les fichiers journaux sont déployés sur un
matériel approprié.
De nombreux lecteurs SATA et IDE ne sont pas pris en charge par la commande de purge d’écriture. Les
lecteurs SAS le supportent.
Les bases de données Active Directory et les fichiers journaux doivent utiliser des lecteurs SAS sur des
contrôleurs SAS qui ont une sauvegarde de batterie sur n’importe quel élément de mise en cache
d’écriture.
2. Si 0xc00002e1 (c00002e1) et 0xc00002e2 (c00002e2) sont des contrôleurs de domaine invité virtuels
qui s’exécutent sur des hôtes Hyper-V Windows Server 2012, installez les correctifs correctives dus à la
perte de cohérence avec les disques durs virtuels connectés à l’IDE lorsqu’un serveur hôte Hyper-V subit
un redémarrage non planifié sur des hôtes et des DCS invités, selon les besoins.
3. Vérifiez si l’événement qui a précédé les erreurs de démarrage LSASS 0xc00002e1 (c00002e1) et
0xc00002e2 (c00002e2) indique l’un des problèmes suivants :
Panne d’alimentation non reprogrammée.
Le système se bloque.
Installation de Windows mises à jour ou d’installations de Service Pack.
Ajout ou suppression de disques, de volumes ou de partitions dans le système local.
Défaillance du disque dur.
NTDS. Dit ou un ou plusieurs fichiers journaux ont été copiés à partir d’un autre ordinateur ou même
à partir d’un point précédent dans cette vie DCS.
Inconnu
4. Démarrez l’ordinateur en mode restauration des services d’annuaire.
5. Meilleure pratique : effectuer une sauvegarde de l’état système afin de pouvoir rétablir les modifications
apportées au cours de votre session de récupération.
6. Meilleure pratique : demandez à l’administrateur à l’avance de localiser la sauvegarde d’état système la
plus récente afin que vous pouvez prendre en compte l’existence ou la nonexistence de sauvegardes
d’état système dans vos plans de récupération. Si possible, demande à l’administrateur de déléguer
l’emplacement des sauvegardes.
7. Exécutez NTDSUTIL -> -> Info.
NOTE
chemin d’accès au NTDS. FICHIERS DIT et journaux.
8. Vérifiez que le lecteur qui héberge le NTDS. Les fichiers DIT ou journaux sont disponibles au démarrage
du système d’exploitation.
9. Ouvrez Windows Explorer et vérifiez que le NTDS. Les fichiers DIT et journaux sont présents dans le
chemin d’accès du fichier journal signalé à l’étape 7.
Si les fichiers sont présents, passer à l’étape 10.
Si les fichiers ne sont pas présents, recherchez le fichier NTDS sur tous les lecteurs et volumes
disponibles. FICHIERS DIT et journaux qui appartiennent à cette instance d’Active Directory.
WARNING
Il peut y avoir plusieurs NTDS. FICHIERS DIT et journaux présents sur les lecteurs locaux. Utilisez les horodatés
pour rechercher l’instance correcte.
Corrigez les chemins d’accès pour les chemins d’accès de la base de données et des fichiers journaux
selon les besoins.
10. Vérifiez les autorisations de fichier pour la version du système d’exploitation en question.
NOTE
Le système d’exploitation a besoin d’autorisations Windows Server 2003.
Creator, propriétaire Contrôle total Sous-dossiers et fichiers

uniquement
Local Service Créer des dossiers/ Append Data Ce dossier et ses sous-dossiers
Racine du volume qui héberge le NTDS. Fichiers journaux DIT et NTDS (le système nécessite un
contrôle total)
Dossier %windir% (c:\windows ou c:\winnnt) (le système nécessite un contrôle total)
Dossier qui héberge le fichier NTDS. Fichiers journaux DIT et NTDS (voir le tableau des autorisations
ci-dessous)
Fichiers journaux NTDS eux-mêmes (voir le tableau de bord ci-dessous)
11. Vérifiez que les fichiers journaux corrects résident dans le répertoire des fichiers journaux :
NTDSUTIL /FILES identifie le répertoire de base de données et le répertoire de fichiers journaux si
différent. NTDSUTIL /MH identifie les fichiers journaux requis dans le répertoire des fichiers journaux.
En aucun cas, la base de données ou les fichiers journaux d’un dc ne doivent être copiés vers un autre dc
pour rendre le second DC fonctionnel.
12. Confirmez que la compression de disque ou de fichier n’est activée sur aucun volume qui héberge NTDS.
Volume de fichier DIT ou journal.
13. Validez l’état de la base de données dans NTDS. DIT du bas vers le haut.
Validez l’état de la base de données Jet de bas en haut. Continuez jusqu’à la couche suivante uniquement
lorsque la couche sous-jacente se termine sans erreur.
La résolution d’une erreur signalée par la cohérence logique ese logique ou logique d’application lorsque
la cohérence physique échoue encore vous conduit à un chemin de dépannage inapproprié.
Les commandes NTDSUTIL et ESENTUTL équivalentes pour chacune des commandes ultérieures sont
indiquées ci-dessous :
C O M M A N DE ESEN T UT L
C O UC H E C O M M A N DE N T DSUT IL ÉQ UIVA L EN T E
1. Cohérence physique pas d’équivalent ESENTUTL /K
2. Cohérence logique ESE INTÉGRITÉ DES FICHIERS NTDSUTIL ESENTUTL /G
3. Cohérence logique de l’application NTDSUTIL - Analyse >base de Aucun équivalent. Exécuter

données sémantique NTDSUTIL -> SDA
+ +
NTDSUTIL -> défragmentation hors ESENTUTL / D

connexion
14. Recherchez l’action de l’utilisateur pour la première erreur Jet défaillante rencontrée à l’étape 13.
Effectuez des corrections si possible.
15. Réparez la base de données Jet :
Certaines erreurs de base de données Jet peuvent être réparées à l’aide de NTDSUTIL et ESENTUTL.
Certaines erreurs de base de données Jet ne peuvent pas être réparées et toute tentative de réparation
échoue. Dans ce cas, votre seule possibilité peut être de restaurer une sauvegarde de l’état système
qui a précédé l’altération ou de créer un nouveau serveur. Si les DCS de réplica sont à jour, encouragez
la promotion de réplicas supplémentaires dans le domaine après avoir tenté d’atténuer la cause
première des erreurs matérielles ou logicielles.
NOTE
L’erreur Jet renvoyée dans l’événement NTDS General 1168 est une erreur de couche d’application. N’agissez pas
sur cette erreur Jet à moins que les vérifications de cohérence physique et logique de l’application (testées dans
cet ordre) ne passent sans erreur.
Pour plus d’informations, consultez l’article Microsoft suivant :
Le contrôleur de domaine ne démarre pas, une erreur c00002e2 se produit ou l’option « Choisir une option »
s’affiche
Qu’est-ce qu’une perte d’IO/Flush perdu
Lorsqu’une application écrit des données sur un disque, le disque indique la réussite de l’opération écrite.
Toutefois, lorsque l’application tente de lire les données qu’elle vient d’écrire, les données n’existent pas. This
issue is called as lost I/O, or lost flush.
Dépannage de l’erreur de réplication AD 8418 :
échec de l’opération de réplication en raison d’une
inmatmatation de schéma entre les serveurs
impliqués
l’erreur Win32 8418.
NOTE
Symptômes
l’erreur Win32 8418 : l’opération de réplication a échoué en raison d’une inaltérabilité de schéma entre les
serveurs impliqués.
Cet article fait partie d’une série sur la résolution des erreurs et des événements de réplication AD documentés
sur Technet. Pour rechercher cet article et les articles associés, utilisez votre moteur de recherche Internet favori
pour effectuer une requête sur : Résolution des erreurs de réplication <error number>AD : <error string>
site:support.microsoft.com
Par exemple : Résolution de l’erreur de réplication AD 5 : l’accès est refusé site:support.microsoft.com
La réplication de toutes les données Active Directory entre des contrôleurs de domaine dans une forêt repose
sur l’affichage cohérent de toutes les définitions d’objets et d’attributs. Ces définitions sont stockées dans la
partition de schéma de la base de données Active Directory. Le moteur de réplication d’annuaire hiérarchise la
réplication des données de cette partition au-dessus de toutes les autres. Lorsqu’une modification d’une
définition de schéma est détectée entre les partenaires, elle doit être répliquée pour que les données des autres
partitions soient synchronisées.
1. Une ou plusieurs erreurs à l’écran, événements journalisé ou sortie de diagnostic identifient l’existence
d’une insaltérité de schéma.
Les formats possibles pour cette erreur sont les suivants :
8418 0x20e2 ERROR_DS_DRA_SCHEMA L’opération de réplication

_MISMATCH a échoué en raison d’une
insématisation de schéma
entre les serveurs
impliqués.
2. DCPromo Promotion
Erreur à l’écran
---------------------------
Assistant Installation des services de domaine Active Directory
---------------------------
L’opération a échoué car : Les services de domaine Active Directory n’ont pas pu répliquer la partition
<DN path of partition> d’annuaire à partir du contrôleur de domaine Active Directory distant
<helper DC FQDN>.
« L’opération de réplication a échoué en raison d’une inmatmatisation de schéma entre les serveurs
impliqués. »
---------------------------
OK
---------------------------
DCPROMO. LOG où une erreur est rencontrée avant la phase de réplication non critique :
MM/DD/YYYY HH:MM:SS [INFO] NtdsInstall pour <nom de domaine hostname.dns.<top level

domain> renvoyé 8418
MM/DD/YYYY HH:MM:SS [INFO] DsRolepInstallDs renvoyé 8418
MM/JD/AAA HH:MM:SS [ERREUR] Échec d’installation dans le service d’annuaire (8418)
MM/JD/AAA HH:MM:SS [INFO] Démarrage du service NETLOGON
Si l’erreur est rencontrée pendant la phase de réplication non critique de DCPROMO, le réplica DC
redémarre et enregistre les éléments suivants dans dcPROMO. Fichier JOURNAL.
MM/JD HH:MM:SS [AVERTISSEMENT] La réplication non critique a renvoyé 8418 MM/JD HH:MM:SS
[INFO] Nettoyage des anciennes informations Netlogon MM/JD HH:MM:SS [INFO] Arrêt de DS
MM/JD HH:MM:SS [INFO] L’opération de contrôleur de domaine tentée est terminée.
3. Les événements suivants peuvent être enregistrés dans le journal des événements du service d’annuaire
Microsoft-Windows- 1203 Le service d’annuaire n’a pas pu

ActiveDirectory_DomainService répliquer l’objet suivant à partir du
service d’annuaire source à l’adresse
réseau suivante en raison d’une
non-mise en réseau des services de
Microsoft-Windows- 1309 avec l’état d’erreur 8418 Le contrôle de cohérence des

ActiveDirectory_DomainService connaissances (KCC) a détecté que
suivant ont constamment échoué.
Microsoft-Windows- 1791 avec l’état d’erreur 8418 La réplication de la partition

ActiveDirectory_DomainService d’annuaire d’applications <DN
path> à partir de la source <NTDS
Settings object GUID> DC (<source
DC FQDN>) a été abandonnée. La
réplication nécessite un schéma
cohérent, mais la dernière tentative
de synchronisation du schéma a
échoué. Il est essentiel que la
réplication de schéma fonctionne
correctement. Consultez les erreurs
précédentes pour plus de
diagnostics. Si ce problème persiste,
contactez les services de support
l’aide. Erreur 8418 : l’opération de
réplication a échoué en raison d’une
insalérable insalion de schéma entre
les serveurs impliqués.
NTDS KCC 1925 avec l’état d’erreur 8418 La tentative d’établissement d’un

pas pu répliquer l’objet suivant à
partir du contrôleur de domaine
source à l’adresse réseau suivante
en raison d’une inaltérable
inaltérable dans le schéma Active
Directory.
Réplication NTDS 1791 avec l’état d’erreur 8418 La réplication du contexte

d’attribution de <DN path> noms à
partir de la source <NTDS Settings
object guid> a été abandonnée. La
réplication nécessite un schéma
cohérent, mais la dernière tentative
de synchronisation du schéma a
échoué. Il est essentiel que la
réplication de schéma fonctionne
correctement. Consultez les erreurs
précédentes pour plus de
diagnostics. Si ce problème persiste,
contactez les services de support
l’aide. Erreur 8418 : l’opération de
réplication a échoué en raison d’une
insalérable insalion de schéma entre
les serveurs impliqués.
4. Les sites et services Active Directory échouent avec l’erreur suivante :
--------------------------- Répliquer maintenant --------------------------- <Naming context> <source

DC> <destination DC>L’erreur suivante s’est produite lors de la tentative de synchronisation du
contexte d’attribution de noms entre le contrôleur de domaine et le contrôleur de domaine :
l’opération de réplication a échoué en raison d’une inmatmatisation de schéma entre les serveurs
impliqués. Cette opération ne se poursuit pas. --------------------------- OK ---------------------------
5. REPADMIN.EXE affiche les erreurs suivantes :
REPADMIN /SHOWREPS
Last attempt @ YYYY-MM-DD HH:MM:SS failed, result 8418 (0x20e2) : the replication operation failed
because of a schema mismatch between the servers involved.
REPADMIN /SYNCALL
repadmin /syncall /AePdq Syncing all NC’s held on <DC Name>. Partition de synchronisation :
DC=contoso,DC=com SyncAll a signalé les erreurs suivantes : Erreur lors de l’émission de la
réplication : 8418 (0x20e2) : l’opération de réplication a échoué en raison d’une non-compatibilité de
schéma entre les serveurs impliqués.
REPADMIN /REPLSUM
Repadmin /replsummary Replication Summary Start time: YYYY-MM-DD HH:MM:SS Beginning data
collection for replication summary, this may take a while: ..... Le plus grand delta de la DSA source
échoue/total %% erreur <Source DC> xxh:yym:zzs 4 / 5 80 (8418) Échec de l’opération de réplication
en raison d’une insalponsabilité de schéma entre les serveurs impliqués. Destination DSA largest
delta fails/total %% error <dest DC> 04h:02m:16s 4 / 5 80 (8418) The replication operation failed
because of a schema mismatch between the servers involved.
Cause
Les tentatives de réplication d’AD lorsque les informations de schéma ne sont pas cohérentes entre les
partenaires de dc impliqués entraînent un état d’erreur « Non-concordance de schéma ». Ce symptôme peut
être exprimé de différentes manières, comme indiqué ci-dessus. Toutefois, la cause sous-jacente de l’erreur qui
se produit peut varier.
Il existe également des scénarios dans lequel cette erreur est produite, mais il n’y a pas d’insématisation dans les
informations de schéma au sens le plus strict. Dans ce cas, il se peut que les données Active Directory répliquées
ne soient pas conformes à la définition de schéma actuelle de l’objet ou de l’attribut pertinent dont la valeur est
synchronisée et appliquée au niveau de la base de données de destination.
La durée des erreurs de non-matisation de schéma est généralement l’une des deux catégories suivantes :
temporaire ou persistante. Dans la catégorie persistante, certaines défaillances peuvent être examinées ET
résolues en toute sécurité.
Pour les problèmes d’échec de la réplication de schéma en raison de définitions de schéma d’attribut incorrectes,
veuillez faire appel au support technique et au service clientèle Microsoft pour qu’ils s’en chargent.
Remarque : il est essentiel de tester en laboratoire la modification du schéma avant d’implémenter un plan
d’action proposé dans votre schéma de production.
Mise à jour du schéma : après une mise à jour de schéma d’administration, il est probable qu’une insématisation
de schéma se produise sur différents dcs dans la forêt. Cela se produit généralement dans un modèle qui
correspond à la topologie et à la planification de réplication AD. Ce comportement est normal tant que l’état
d’erreur est temporaire*. Cette classe d’échec est la plus susceptible d’être
signalés par le logiciel de surveillance et ne nécessitent aucune intervention administrative.
La durée pendant laquelle l’inaltérabilité du schéma peut être consignée par un dc de destination donné ne doit
pas durer plus d’un cycle de réplication pour un partenaire donné. Les dcs avec un seul partenaire ne doivent
voir l’erreur qu’une seule fois, tandis que les dcs d’en-tête de pont peuvent voir l’erreur plusieurs fois, une pour
chaque partenaire.
Une estimation raisonnable de l’échec passager de la limite de temps acceptable est la période de convergence
de la forêt* x 1,5.
*Durée la plus longue pour qu’une mise à jour d’objet soit répliquée d’un dc vers tous les autres DCS de la forêt.
Déclencheurs de symptôme transitoire
Mise à jour du schéma : après une mise à jour de schéma d’administration, il est probable qu’une insématisation
de schéma se produise sur différents dcs dans la forêt. Cela se produit généralement dans un modèle qui
correspond à la topologie et à la planification de réplication AD. Ce comportement est normal tant que l’état
d’erreur est temporaire*. Cette classe de défaillance est le plus susceptible d’être signalée par le logiciel de
surveillance et ne nécessite aucune intervention administrative.
La durée pendant laquelle l’inaltérabilité du schéma peut être consignée par un dc de destination donné ne doit
pas durer plus d’un cycle de réplication pour un partenaire donné. Les dcs avec un seul partenaire ne doivent
voir l’erreur qu’une seule fois, tandis que les dcs d’en-tête de pont peuvent voir l’erreur plusieurs fois, une pour
chaque partenaire.
*Une estimation raisonnable de la durée acceptable d’un échec passager est deux fois plus longue qu’il faut
pour qu’une mise à jour d’objet soit répliquée d’un dc vers tous les autres DCS de la forêt.
Déclencheurs de symptôme persistants
Dans certains scénarios, l’erreur de non-mise en cause du schéma persiste indéfiniment et une intervention est
nécessaire pour examiner, identifier le déclencheur sous-jacent et résoudre. Certains scénarios présents sous le
nom de problèmes connus, tandis que dans d’autres, la non-matisation du schéma est purement un effet
secondaire d’autres problèmes bloquants qui l’empêchent de se résoudre de manière autonome par le biais
d’une réplication normale.
Problèmes connus
A RT IC L E DE L A K B N . T IT L E DO N N ÉES C L ÉS
982438 Vous ne pouvez pas installer AD DS ID d’événement 1791

dans Windows Server 2008 dans un
domaine Windows Server 2003 si
MSCS est installé sur un autre
ordinateur du même domaine
947020 Les ID d’événement 1481, 1173 et ID d’événement 1481 Erreur 2083 ;

1203 sont enregistrés dans le journal DSID 31510B7
des services d’annuaire sur un
contrôleur de domaine Windows ID d’événement 1173 Param 2083
Server 2003 DSID 31010B7
ID d’événement 1203 « Non-

matisation du schéma »
824873 L’événement 1791 est journalisé ID d’événement 1791 Erreur 8418

lorsque les informations sont
répliquées de Windows 2000 vers ID d’événement 1481 DSID 3151030
Windows Server 2003
2001769 Erreur lors de la propagation des ID d’événement 1450 DSID 3150dbe

autorisations : « Impossible
d’enregistrer les autorisations...
Autres problèmes de blocage

RUB RIQ UE KB DO N N ÉES C L ÉS
Mise en quarantaine de la réplication 2020053 ID d’événement 2042
État d’erreur 8614
Échec de la réplication provoqué par 2028495 ID d’événement 1988 avec l’état 8606
des objets de niveau d’attente lorsque
la cohérence de réplication stricte est
activée
Topologie de réplication
Réplication désactivée 2028495 État 8457
DNS (résolution de noms) 2021446 ID d’événement 2023 avec code d’état

8524
RPC 1722: Code d’état 1722
2102154 Code d’état 1753
1753:
2089874
Résolution
Pour résoudre un problème de non-mise en cause du schéma, il est essentiel de comprendre le scénario dans
lequel l’erreur est émise, car elle peut influencer les données collectées. Les scénarios courants sont les suivants :
Mise à jour récente du schéma
DC Promotion
Réplication normale
Comme indiqué précédemment, dans le cas d’une mise à jour récente du schéma, il est courant pour certains dc
de signaler l’insématisation du schéma dans le cadre normal du traitement de la mise à jour. Cet état ne doit être
examiné que s’il persiste pendant une période prolongée La non-matisation du schéma pendant la promotion
d’un dc est presque toujours un problème persistant qui ne peut pas être corrigé sans examen et mesures
correctives.
Collecte de données initiale
Le but de la collecte de données initiale est d’essayer de capturer des informations suffisantes pour identifier si
un problème connu est en cours d’expérience ou si d’autres problèmes contribuent à l’échec.
La collecte de données de réplication pour tous les dc de la forêt est conseillée, en particulier dans le cas où une
insaluration de schéma a été notée après une mise à jour récente du schéma ou lors de la surveillance de la
réplication normale. La collecte de ces données permet d’identifier les poches d’échec de réplication sur
lesquelles se concentrer.
Repadmin showrepl * /csv > allrepl.csv
Une fois que toutes les défaillances de réplication du dc, de n’importe quel formulaire, repadmin /showrepl ont
été identifiées à partir de la caméra de focus de données vers des DC spécifiques.
Dans le cas où DCpromo échoue avec une insaltérence de schéma, les données suivantes doivent être collectées
:
Journaux DCpromo et DCpromoUI
Journalisation des événements de diagnostic NTDS sur le dc source et de destination, comme décrit ci-
dessous dans « Data Collection Phase 2 »
Ldifde Export of the Schema partition as described below in the « Schema Review »
Vérifier les versions de schéma
La version actuelle du schéma peut être lue à partir de deux endroits sur un dc donné : le Registre et dans Active
Directory lui-même. En fonctionnement normal, les deux valeurs doivent être synchronisées et refléter
correctement la version de schéma de la forêt telle que définie par le schéma FSMO.
Remarque : seules les mises à jour du schéma Active Directory fournies par Microsoft permettent de mettre à
jour le numéro SchemaVersion.
Valeurs de version du schéma de référence
SY ST ÈM E D’EXP LO ITAT IO N VERSIO N DE SC H ÉM A
Windows 2000 13
Windows Server 2003 30
Windows Server 2003 R2 31
Windows Server 2008R2 47
Windows Server 2012R2 69
Dans le Registre :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\SystemSchemaVersion
Dans Active Directory :
Objet : Cn=Schema,cn=configuration,dc=contoso,dc=com
Attribut : ObjectVersion
La version de schéma dans AD peut être exportée à l’aide de l’une des commandes suivantes
Ldifde -f schemaver.ldf -d Cn=Schema,cn=configuration,dc=contoso,dc=com -l ObjectVersion dsquery *
cn=schema,cn=configuration,dc=contoso,dc=com -scope base -attr objectVersion
Résolution possible 1
Dans le scénario où les conditions suivantes s’appliquent :
Le schéma AD a été récemment mis à jour
Un ou plusieurs partenaires d’un dc signalent une insématisation de schéma pendant une période prolongée
Les versions du registre et du schéma AD sur le dc source sont synchronisées et correspondent à la version
attendue à l’échelle de la forêt.
Il est possible qu’un redémarrage de la source DC résolve les échecs de réplication. La cause sous-jacente est
l’échec du rechargement correct de la version en mémoire du schéma après réception de la mise à jour du
schéma.
Phase 2 de collecte de données
Si la résolution ci-dessus n’est pas applicable ou si elle échoue, augmentez la journalisation des événements «
Diagnostic NTDS » sur les DCS source et de destination sous la clé de Registre suivante.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics
NOM TYPE VA L EUR
5 Réplication DWORD 5
9 Traitement interne DWORD 5
24 Schéma DWORD 5
7 Configuration interne DWORD 5
Cela permet d’enregistrer des informations supplémentaires dans le journal des événements des services
d’annuaire qui vous aideront à diagnostiquer le problème.
Déclenchez le scénario qui déclenche une erreur de non-connexion de schéma et examinez les données du
journal des événements collectées pour essayer d’identifier :
Objet sur lequel la réplication échoue par son nom d’objet ou objectGUID
Attribut appliqué par son nom ldapdisplayname ou son ID interne
Toute donnée d’erreur interne ou étendue.
Les ID d’événements qui vous intéressent dans le journal des événements du service d’annuaire sont les
suivants :
Événement de réplication 1173
Replication, événement 1791
Replication, événement 1203
Les événements d’exemple suivants montrent à la fois un ID interne et des données d’erreur étendues

Date : <DateTime>
Ordinateur : Dc12.Contoso.com
Description :
Événement interne : les services de domaine Active Directory ont rencontré l’exception suivante et les
paramètres associés.
Exception :
e0010004
Paramètre : 0
Valeur d’erreur :
8364
ID interne :
2050078
L’exemple d’événement suivant identifie un objet spécifique sur lequel la réplication a été bloquée.

Date : <DateTime>
Ordinateur : GB-JDT-DMV-N55.contoso.com
Description :
Le service d’annuaire n’a pas pu répliquer l’objet suivant à partir du service d’annuaire source à l’adresse
réseau suivante en raison d’une non-mise en réseau des services de domaine Active Directory.
Objet : CN=Machine,CN={54EFB8A2-33F1-4E04-B4AD-
229ABA513555},CN=Policies,CN=System,DC=contoso,DC=com
Adresse réseau : <GUID>._msdcs.contoso.com
Les services de domaine Active Directory tenteront de synchroniser le schéma avant d’essayer de
synchroniser la partition d’annuaire suivante. Partition d’annuaire :
DC=contoso,DC=comiption:
Le service d’annuaire n’a pas pu répliquer l’objet suivant à partir du service d’annuaire source à l’adresse
réseau suivante en raison d’une non-mise en réseau des services de domaine Active Directory. Objet :
CN=Machine,CN={54EFB8A2-33F1-4E04-B4AD-
229ABA513555},CN=Policies,CN=System,DC=contoso,DC=com Network address:
<GUID>._msdcs.contoso.com
Les services de domaine Active Directory tenteront de synchroniser le schéma avant d’essayer de
synchroniser la partition d’annuaire suivante. Partition d’annuaire : DC=contoso,DC=com
Passer en revue les données collectées

Recherchez les événements de corrélation, y compris ceux mentionnés ci-dessus, qui pointent vers des scénarios
de déclencheur connus.
Recherchez les événements qui peuvent indiquer d’autres problèmes sous-jacents sur la source ou la destination
qui pourraient bloquer la réplication et qui peuvent donc provoquer la persistance d’un échec passager
d’insématisation.
Voici quelques exemples d’autres causes :
Contraintes de corruption de base de données La réplication met en quarantaine la cohérence de réplication
stricte Objets de réplication désactivés avec des descripteurs de sécurité dépassant 64 Ko DNS (résolution de
nom), etc. Échecs de communication RPC Pare-feu local
Consultez la section Causes pour plus d’informations sur les événements et les codes d’état associés pour
certains de ces problèmes.
Actions supplémentaires
Si l’échec du déclenchement de l’objet peut être identifié, repadmin /showobjmeta utilisez-le d’abord pour vider
les métadonnées de réplication d’objet et à la fois sur la source et la destination DC. Cette méthode peut être
utilisée pour identifier les attributs « candidate » qui peuvent être la cause de l’échec
Repadmin /showobjmeta Target_DC "DN_of Trigger_Object"
Si seul le GUID de l’objet est connu, utilisez la syntaxe :

Repadmin /showobjmeta Target_DC "\<GUID=ObjectGuid_of Trigger_Object>"
Examinez les métadonnées de réplication afin de vous assurer que tous les attributs répliqués affichent un nom
d’attribut correctement formé
Exemple
Les deux entrées réplication de métadonnées de réplication d’un objet problème tel qu’affiché par Repadmin.exe
n’affiche aucun ldapdisplayname :
USN DSA Org USN Org. Attribut de version heure/date

24260 f4617e99-9688-42a6-8562-43fdd2d5cda4 18085395 <DateTime> 2
24260 f4617e99-9688-42a6-8562-43fdd2d5cda4 18086114 <DateTime> 3
Si l’un des champs de métadonnées n’a pas de nom associé, essayez d'ldp.exe pour exposer l’attribut interne
Les métadonnées du même objet ci-dessus que celles affichées dans LDP.exe l’AttributID associé aux données
AttID Ver Loc.USN Originating DSA Org.USN Org.Time/Date

250000 2 24260 f4617e99-9688-42a6-8562-43fdd2d5cda4 18085395 <DateTime>
250004 3 24260 f4617e99-9688-42a6-8562-43fdd2d5cda4 18086114 <DateTime>
L’ID d’attribut peut être utilisé pour vous aider à identifier l’attribut problème, mais nécessite l’engagement du
Support Microsoft.
Comparaison de version : les attributs à répliquer auront des numéros de version plus élevés sur la source.
NOTE
Dans le scénario DCpromo, l’objet de destination n’existe probablement pas encore.
Si seul l’objet peut être identifié à partir des données d’événement, videz les valeurs d’attribut de l’objet
déclencheur.
Ldifde -f results.txt> -d "DN_of Trigger_Object" -s Target_DC Ldifde -f \<results.txt> -d "

<GUID=ObjectGuid_of Trigger_Object>" -s Target_DC Repadmin /showattr Target_DC "DN_of Trigger_Object"
Repadmin /showattr Target_DC "DN_of Trigger_Object"
Si les événements de réplication 8418 ont produit des erreurs étendues ou internes, utilisez ces valeurs pour
essayer de faire correspondre les problèmes connus.
Si l’attribut déclenchant l’échec ne peut pas être identifié par les données du journal des événements ou les
métadonnées de réplication, il sera nécessaire de faire appel au Support technique Microsoft pour faciliter
l’examen.
Révision du schéma
Une fois qu’un attribut déclencheur potentiel a été identifié et que d’autres causes connues ont été supprimées,
l’action suivante consiste à examiner la définition de schéma de l’attribut. Cette analyse est plus performant avec
l’assistance du Support technique Microsoft.
Exportation de la partition de schéma entière à partir des contrôleurs de domaine source et de destination :
Ldifde -f schema _TargetDC.ldf -d cn=schema,cn=configuration,dc=contoso,dc=com -s Target_DC
Données à fournir au support Microsoft

Être prêt à fournir les informations suivantes au personnel du support Microsoft pour vous aider à
diagnostiquer les causes de l’insérialisation du schéma
Exportation de la partition de schéma à partir du contrôleur de domaine source
Journaux DCpromo à partir de destination DC (le cas échéant pour le scénario)
Repadmin /showrepl sortie du contrôleur de domaine source et de destination
Journaux des événements des services d’annuaire avec la journalisation étendue à partir du contrôleur de
domaine source et de destination
Métadonnées de réplication de tout objet problème identifié à partir des journaux des événements
Exportation LDIFDE de tout objet problème identifié à partir des journaux des événements
Les problèmes de définition de schéma possibles qui peuvent déclencher une insérialisation sont les suivants :
Valeurs de syntaxe om non valides OID Invalid MayContain values Objects with attributes that contain data but
the schema definition for the attribute type(s) has been marked as defunct
Erreur de réplication Active Directory 8456 ou 8457
: la source | le serveur de destination rejette
actuellement les demandes de réplication
Cet article décrit les étapes de symptômes, de cause et de résolution pour les situations dans lesquelles les
opérations Active Directory échouent avec l’erreur 8456 ou 8457.
NOTE
Symptômes
Échec des opérations Active Directory avec l’erreur 8456 ou 8457 : la source | le serveur de destination rejette
actuellement les demandes de réplication.
1. La promotion DCPROMO d’un nouveau contrôleur de domaine dans une forêt existante échoue avec
l’erreur : le serveur source rejette actuellement les demandes de réplication.
Texte du titre de la boîte de dialogue : Texte du message de l’Assistant Installation d’Active Directory :
L’opération a échoué car Active Directory n’a pas pu transférer les données restantes dans la partition
<directory partition DN path> d’annuaire vers le contrôleur de domaine <destination DC>. « Le
serveur source rejette actuellement les demandes de réplication. »
2. DCDIAG signale l’erreur : le serveur source rejette actuellement les demandes de réplication ou le
serveur de destination rejette actuellement les demandes de réplication .
Serveur de test : Default-First-Site-Name<DC NAME>

[Vérification des réplications,<DC NAME>] Une tentative de réplication récente a échoué :
De IADOMINO à <DC NAME>
Contexte d’attribution de noms : DC=<DN path of partition>
Le serveur source rejette actuellement les demandes de réplication.
L’échec s’est produit à <Date> <Time>.
Le dernier succès s’est produit à <Date> <time>.
La réplication a été explicitement désactivée via les options du serveur
Serveur de test : Default-First-Site-Name<DC NAME>
[Vérification des réplications,<DC NAME>] Une tentative de réplication récente a échoué :
De IADOMINO à <DC NAME>
Contexte d’attribution de noms : DC=<DN path of partition>
Le serveur de destination rejette actuellement les demandes de réplication.
L’échec s’est produit à <Date> <Time>.
Le dernier succès s’est produit à <Date> <time>.
La réplication a été explicitement désactivée via les options du serveur
3. REPADMIN indique que la réplication Active Directory entrante et sortante peut échouer avec l’erreur : La
source | le serveur de destination rejette actuellement la réplication.
DC=Contoso,DC=COM
<site name><dc name> via RPC
GUID d’objet DC : <objectguid of source DCs NTDS settings object>
Le serveur de destination rejette actuellement les demandes de réplication.
DC=Contoso,DC=COM
<site name><dc name> via RPC
GUID d’objet DC : <objectguid of source DCs NTDS settings object>
Le serveur source rejette actuellement les demandes de réplication.
NOTE
Les commandes REPADMIN peuvent afficher les valeurs hexadécimale et décimale équivalentes pour l’erreur de
réplication en cours de rejet.
4. Les sources d’événements et les ID d’événement qui indiquent qu’une rollback USN s’est produite
incluent, sans s’y limiter, les éléments suivants.
SO URC E DE L’ÉVÉN EM EN T ID D’ÉVÉN EM EN T C H A ÎN E D’ÉVÉN EM EN T

connaissances (KCC) a détecté que
échoué.

NTDS KCC 1926 Échec de la tentative

d’établissement d’un lien de
SO URC E DE L’ÉVÉN EM EN T ID D’ÉVÉN EM EN T C H A ÎN E D’ÉVÉN EM EN T
Réplication NTDS 1586 La Windows point de contrôle de

réplication NT 4.0 ou antérieure
avec le maître de l’émulateur PDC a
échoué. Une synchronisation
complète de la base de données du
Gestionnaire de comptes de sécurité
(SAM) avec les contrôleurs de
domaine exécutant Windows NT 4.0
et les version antérieures peut se
produire si le rôle maître de
l’émulateur PDC est transféré au
contrôleur de domaine local avant le
prochain point de contrôle réussi. Le
processus de point de contrôle sera
testé à nouveau dans quatre heures.

pas pu répliquer les modifications
apportées au contrôleur de
domaine distant suivant pour la
partition d’annuaire suivante.
Microsoft-Windows- 2095 Lors d’une demande de réplication

ActiveDirectory_DomainService des services de domaine Active
Directory, le contrôleur de domaine
local a identifié un contrôleur de
domaine distant qui a reçu des
données de réplication de la dc
locale à l’aide de numéros de suivi
USN déjà reconnus.
Microsoft-Windows- 2103 La base de données des services de

ActiveDirectory_DomainService domaine Active Directory a été
restaurée à l’aide d’une procédure
de restauration non pris en service.
Les services de domaine Active
Directory ne pourront pas se
connecter aux utilisateurs tant que
cette condition persiste. Par
conséquent, le service Net Logon a
été suspendu.
Où les codes d’état incorporés 8456 et 8457 se muivent.
ERREUR DÉC IM A L E ERREUR H EXA DÉC IM A L E C H A ÎN E D’ERREUR
8456 2108 Le serveur source rejette

actuellement la réplication
8457 2109 Le serveur de destination rejette

actuellement la réplication
5. L’événement général NTDS 2013 peut être enregistré dans le journal des événements des services
d’annuaire. Cela indique qu’une restauration usn s’est produite en raison d’une restauration ou
restauration non pris en compte de la base de données Active Directory.

Catégorie d’événement : contrôle de service
Date : <date>
Heure : <time>
Utilisateur : <user name>
Ordinateur : <computer name>
Description : la base de données Active Directory a été restaurée à l’aide d’une procédure de
restauration non pris en compte. Active Directory ne peut pas se connecter aux utilisateurs tant que
cette condition persiste. Par conséquent, le service Net Logon a été suspendu. Action de l’utilisateur
Consultez les journaux d’événements précédents pour plus d’informations. Pour plus d’informations,
consultez le Centre d’aide et de support à l’aide. https://support.microsoft.com
6. L’événement général NTDS 1393 peut être enregistré dans le journal des événements des services
d’annuaire. Cela indique que le lecteur physique ou virtuel qui héberge la base de données ou les fichiers
journaux Active Directory manque d’espace disque libre :

Catégorie d’événement : contrôle de service
Date : <date>
Heure : <time>
Utilisateur : <user name>
Ordinateur : <computer name> Description :
Les tentatives de mise à jour de la base de données du service d’annuaire échouent avec l’erreur 112.
Étant donné Windows ne parvenez pas à se connecter aux utilisateurs tant que cette condition
persiste, le service NetLogon est suspendu. M ake sure that sufficient free disk space is available on
the drives where the directory database and log files reside.
Cause
La réplication entrante ou sortante a été automatiquement désactivée par le système d’exploitation en raison de
plusieurs causes racines.
Trois événements qui désactivent la réplication entrante ou sortante sont les suivants :
Une rollback USN s’est produite (événement général NTDS 2103).
Le disque dur est plein (événement général NTDS 1393).
Un vecteur UTD endommagé est présent (événement 2881).
Le système d’exploitation effectue automatiquement quatre modifications de configuration lorsque l’une des
trois conditions se produit. Les quatre modifications de configuration sont les suivantes :
1. La réplication Active Directory entrante est désactivée.
2. La réplication Active Directory sortante est désactivée.
3. DSA not writable is set to a nonzero value in the registry.
4. L’état du service NETLOGON est modifié de l’exécution à l’état suspendu .
La cause principale dominante de cette condition d’erreur est une rollback USN abordée dans le contrôleur de
domaine A Windows Server enregistre l’événement Directory Services 2095 lorsqu’il rencontre une rollback
USN.
Ne supposez pas qu’aucune valeur autre que zéro n’est accessible en ligne pour la DSA ou qu’un serveur
source ou de destination rejette actuellement les demandes de réplication au cours de la réplication
DCPROMO/AD signifie de manière définitive qu’une rétrogradation USN s’est produite et que ces contrôleurs de
domaine doivent implicitement être rétrogradés en force ou répliqués par force. Démotionmaybe l’option
correcte. Toutefois, elle peut être excessive lorsque l’erreur est due à un espace disque insuffisant.
Résolution
1. Vérifiez la valeur de la DSA non accessible en création .
Pour chaque contrôleur de domaine qui journalisation l’erreur 8456 ou 8457, déterminez si l’un des trois
événements déclencheurs a automatiquement désactivé la réplication Active Directory entrante ou
sortante en lisant la valeur « DSA not writable » dans le Registre local.
Lorsque la réplication est automatiquement désactivée, le système d’exploitation écrit l’une des quatre
valeurs possibles dans la DSA non accessible en écriture :
Paramètre : DSA non accessible en création
Type : Reg_dword
Valeurs :
#
définir DSA_WRITABLE_GEN 1
#
définir DSA_WRITABLE_NO_SPACE 2
#
définir DSA_WRITABLE_USNROLLBCK 4
#
définir DSA_WRITABLE_CORRUPT_UTDV 8
La valeur 1 peut être écrite uniquement lorsque la version de la forêt est incompatible avec le système
d’exploitation (par exemple, le dc W2K est promu dans une forêt de niveau fonctionnel Windows Server
2003 ou autre).
La valeur 2 signifie que le lecteur physique ou virtuel qui héberge la base de données ou les fichiers
journaux Active Directory manque d’espace disque libre.
La valeur 4 signifie qu’une récupération usn s’est produite, car la base de données Active Directory a été
incorrectement revenir dans le temps. Les opérations connues pour provoquer une rollback USN sont les
suivantes :
Démarrage à partir de captures instantanées de machine virtuelle enregistrées précédemment sur des
ordinateurs de rôle de contrôleur de domaine sur des hôtes Hyper-V ou VMWARE.
Conversions physiques-virtuelles (P2V) incorrectes dans les forêts qui contiennent plusieurs
Restauration d’ordinateurs de rôle DC à l’aide de produits d’imagerie tels que Ghost.
Faire revenir le contenu d’une partition qui héberge la base de données Active Directory dans le
temps à l’aide d’un sous-système de disque avancé.
La valeur 8 indique que le vecteur de date à jour est endommagé sur le dc local.
Techniquement, la DSA ne peut pas être accessible en writable peut se composer de plusieurs
valeurs. Par exemple, une valeur de Registre de 10 indiquerait un espace disque insuffisant et un UTD
endommagé. En règle générale, une seule valeur est écrite dans la DSA et n’est pas accessible en
écriture .
NOTE
Il est courant pour les professionnels du support technique et les administrateurs de désactiver partiellement la
mise en quarantaine de la réplication en activant la réplication sortante, en activant la réplication entrante, en
modifiant la valeur de démarrage du service NETLOGON de désactivée à automatique, et en démarrant le service
NETLOGON. Par conséquent, il se peut que la configuration de mise en quarantaine complète ne soit pas en place
lorsqu’elle est examinée.
2. Recherchez les événements de mise en quarantaine dans le journal des événements du service
d’annuaire.
En supposant que le journal des événements du service d’annuaire ne s’est pas veloppé, vous pouvez
trouver un ou plusieurs événements connexes consignés dans le journal des événements du service
d’annuaire d’un contrôleur de domaine qui enregistre l’erreur 8456 ou 8457.
ÉVÉN EM EN T DÉTA IL S
NTDS General 2103 La base de données Active Directory a été restaurée à

l’aide d’une procédure de restauration non prévue. Active
Directory ne peut pas se connecter aux utilisateurs tant
que cette condition persiste. Par conséquent, le service
Net Logon a été suspendu. Action de l’utilisateur
Consultez les journaux d’événements précédents pour
plus d’informations.
Événement général NTDS 1393 L’espace disque est insuffisant.
Événement 2881 Non applicable
3. Effectuez la récupération en fonction de la valeur de DSA non accessible en création ou sur les
événements qui sont enregistrés sur le système :
Si la DSA ne peut pas être accessible en lecture est égale à 4 ou si l’événement NTDS General
2103 est journalisé, effectuez les étapes de récupération pour une restauration USN. Pour plus
d’informations, voir A Windows Server domain controller logs Directory Services event 2095
when it encounters a USN rollback.
Si la DSA ne peut pas être accessible en ligne est égale à 2 ou si l’événement NTDS General 1393
est journalisé, recherchez suffisamment d’espace disque libre sur les partitions physiques et
virtuelles qui hébergent la base de données Active Directory et les fichiers journaux. Libérez de
l’espace selon les besoins.
Si la DSA ne peut pas être accessible en ligne est égale à 8, rétrogradez, puis réproduisez le
contrôleur de domaine avant de pouvoir répliquer sa valeur mauvaise sur d’autres contrôleurs de
domaine dans la forêt.
Résolution de l’erreur de réplication AD 8461
Cet article décrit les symptômes, les causes et les étapes de résolution pour les cas dans lesquels la réplication
AD est retardée et génère l’erreur Win32 8461 :
L’opération de réplication a été préemptée.

Symptômes
Les symptômes spécifiques sont les suivants :
Symptôme 1 :
DCDIAG signale que le test réplications Active Directory a échoué avec l’état d’erreur (8461) : l’opération
de réplication a été préemptée.
L’exemple de texte d’erreur issu de DCDIAG ressemble à ce qui suit :

AVERTISSEMENT DE LATENCE DE RÉPLICATION
[Vérification des réplications,<DC name>] Ce chemin de réplication a été précédé d’un travail de
priorité plus élevée.
La réplication des nouvelles modifications le long de ce chemin d’accès sera retardée.
La progression se produit normalement sur ce chemin d’accès.
Symptôme 2 :
REPADMIN.EXE signale que la dernière tentative de réplication a été retardée pour une raison normale,
résultat 8461 (0x210d).
REPADMIN Les commandes qui mentionnent généralement l’état 8461 sont les suivantes :
REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL
Symptôme 3 :
Repadmin /rehost échoue et génère le code d’état 8461.
Symptôme 4 :
Repadmin /queue révèle une ou plusieurs tâches dont l’état est « PREEMPTED ».
[12142] Enqueued 2011-11-26 06:05:55 à la priorité 40

SYNCHRONISER À PARTIR DE LA SOURCE
NC dc=west,dc=contoso,dc=com
DSA Domaine\Guid d’objet DSA DC DSA <GUID>
Addr <GUID> de transport DSA ._msdcs.contoso.com
ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY PRÉEMPTÉ
Symptôme 5 :
Commande « répliquer maintenant » dans les sites et services Active Directory (DSSITE). MSC) échoue et
génère le message d’erreur suivant :
Titre de la boîte de dialogue : répliquer maintenant

Texte du message : l’erreur suivante s’est produite lors de la tentative de synchronisation du contexte
d’attribution de noms à <DNS name of directory partition> partir du contrôleur de domaine <source
DC>
vers le contrôleur de domaine <destination DC>:
Symptôme 6 :
Les événements dans le journal des événements des services d’annuaire mentionnent l’état d’erreur
8461.
SO URC E ET ID D’ÉVÉN EM EN T M ESSA GE
Réplication NTDS 1839 Le nombre d’opérations suivant est en attente dans la

file d’attente de réplication. L’opération la plus ancienne
est en attente depuis l’heure suivante. Durée : nombre
<date> <time> d’opérations <value> en attente : cette
condition peut se produire si la charge de travail de
réplication globale sur ce contrôleur de domaine est trop
importante ou si l’intervalle de réplication est trop petit.
Réplication NTDS 2094 Avertissement de performances : la réplication a été

retardée lors de l’application des modifications à l’objet
suivant. Si ce message se produit fréquemment, il
indique que la réplication se produit lentement et que le
serveur peut avoir des difficultés à suivre les
modifications.
Source : réplication NTDS

Type : Avertissement
Description :
Le nombre d’opérations suivant est en attente
dans la file d’attente de réplication. L’opération la plus ancienne a
attendait depuis la fois suivante.
Heure :
Nombre d’opérations en attente :
Cette condition peut se produire si la valeur globale
la charge de travail de réplication sur ce contrôleur de domaine est
trop grand ou l’intervalle de réplication est trop petit.
NOTE
L’événement 1580 est également consigné lorsque des tâches de réplication de longue durée se terminent si la
journalisation détaillée des diagnostics de réplication a été définie sur une valeur supérieure ou 0x1 supérieure.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Diagnostics] « 5 Replication
Events"=dword:00000001
SO URC E ET ID D’ÉVÉN EM EN T C H A ÎN E D’ÉVÉN EM EN T
Réplication NTDS 1580 Une tâche de réplication entrante des services de

domaine Active Directory de longue durée s’est terminée
avec les paramètres suivants.
Durée écoulée (minutes) :

84
Opération :
Synchroniser le réplica
Options :
0x21000051
Paramètre 1 :
DC=Contoso,DC=com
Paramètre 2 :
<source DCs ntds settings object object guid>
Paramètre 3 :
Paramètre 4 :
Une tâche de réplication de longue durée peut

également se produire lorsqu’un système est
indisponible ou qu’une partition d’annuaire est
indisponible pendant une période prolongée. Une tâche
de réplication de longue durée peut indiquer un grand
nombre de mises à jour ou un certain nombre de mises
à jour complexes qui se produisent au niveau du service
d’annuaire source. L’application de ces mises à jour
pendant les périodes non critiques peut empêcher les
retards de réplication.
Une tâche de réplication de longue durée est normale

dans le cas de l’ajout d’une nouvelle partition d’annuaire
aux services de domaine Active Directory. Cela peut se
produire en raison d’une nouvelle installation, d’une
promotion de catalogue global ou d’une connexion
générée par le Contrôle de cohérence des connaissances
(KCC).
Valeur d’erreur :
L’opération s’est terminée correctement.

Cause
Cet état de réplication est renvoyé lorsqu’il existe des tâches de réplication prioritaires dans la file d’attente
entrante des DCS de destination. Il n’indique pas une condition d’échec ; La tâche de réplication n’est pas
annulée, mais elle est mise dans un modèle de mise en place jusqu’à ce que le travail de priorité supérieure soit
terminé. Il est normal de voir ce message renvoyé régulièrement dans des environnements plus importants et il
est important de noter que la condition est temporaire.
Bien que ce problème soit courant et temporaire, d’autres problèmes de réplication AD peuvent provoquer un
journal des travaux en souffrance dans la file d’attente. Si cela se produit, vous pouvez commencer à voir les
tâches de réplication fréquemment préemptées. La journalisation fréquente de l’événement 2094 «
Avertissement de performances » (exemple d’événement illustré dans les sections « Symptômes » et «
Résolution » ) est une autre indication que la résolution des problèmes peut être nécessaire.
Examiner ces problèmes
Explication de la priorité repadmin /queue de réplication
Analyser la sor tie de file d’attente au fil du temps pour déterminer si les tâches sont en cours de
traitement
Explication de repadmin /showrepl /verbose
L A P RO GRESSIO N DE L A RÉP L IC AT IO N
EN T RA N T E A ÉT É IN T ERRO M P UE PA R
UN E DEM A N DE DE RÉP L IC AT IO N DE AT T EN DEZ L A F IN DE L A
P RIO RIT É P L US ÉL EVÉE, T EL L E Q U’UN E RÉP L IC AT IO N . C E M ESSA GE
L A RÉP L IC AT IO N A C T IVE DIREC TO RY DEM A N DE GÉN ÉRÉE M A N UEL L EM EN T D’IN F O RM AT IO N IN DIQ UE UN
A ÉT É P RÉEM P T ÉE. AVEC L A REPADMIN /SYNC C O M M A N DE. F O N C T IO N N EM EN T N O RM A L .
Charge de réplication
Trop de partenaires
Trop fréquent des mises à jour d’objet et d’attribut
Mises à jour fréquentes combinées avec une notification de modification inters site qui entraîne un taux élevé
de notifications de modification redondantes
Fenêtre de planification de réplication de petite taille
Problème basé sur les performances
Performances du disque et de la mémoire
Performances du réseau
Résolution
Cet état n’indique pas une condition d’échec. Il s’agit d’un problème temporaire dans de nombreux cas et
aucune étape de résolution n’est requise.
Si l’état 8461 ne s’effacera jamais, il y a beaucoup de travail à faire pour déterminer le chemin d’accès correct à
prendre. Ce problème nécessite une connaissance avancée de plusieurs outils de dépannage. Il peut être
nécessaire de demander l’aide du Support Microsoft pour vous aider dans le processus d’analyse des données.
Vous devez déterminer la cause avant d’implémenter des étapes pour résoudre un problème sous-jacent. La
cause de l’état de réplication 8461 peut se produire dans l’un des scénarios suivants :
Condition temporaire
Charge cohérente
Chargement temporaire
Problème de performances
Performances du système d’exploitation
Performances du disque
Performances du réseau
Déterminez s’il s’agit uniquement d’une condition temporaire. Documentez l’heure à l’origine de la réplication
manuelle et recherchez les tâches correspondantes dans la repadmin /queue sortie. Plus tard, exécutez
repadmin /queue et déterminez si les tâches initiées manuellement sont toujours présentes.
Si les tâches de réplication sont en file d’attente. Examinez la tâche en cours d’exécution et examinez-la.
Utilisez les données du journal des événements, la sortie du repadmin et l’analyseur de performances pour
isoler la cause du problème. Déterminez la rapidité de traitement des mises à jour et le taux de modification.
Cohérence
Le contrôleur de domaine a trop de partenaires de réplication ou une charge de réplication trop importante. Les
symptômes d’un dc surchargé seraient les suivants :
File d’attente de réplication qui ne s’effacera jamais même si les tâches de réplication sont traitées en
temps voulu
NOTE
Vous pouvez utiliser au repadmin /queue fil du temps et corréler cela avec les données de performances pour
identifier ce scénario.
Occurrence fréquente de l’état de réplication 8461

Solution : réduisez les connexions entrantes (équilibrez les connexions entre les DCS de site hub
(ADLB.exe est utile ici), ajoutez de nouveaux DCS et rééquilibrez les connexions, déployez RODC dans les
sites spoke et réduisez la réplication excessive des modifications.
Réplication excessive
Attributs fréquemment mis à jour. Identifiez les mises à jour d’attributs à l’aide d’événements détaillés du journal
des événements de réplication ( repadmin /showchanges ou à l’aide de ) repadmin /showobjmeta et mettez en
corrélation avec plusieurs objets sur la base de données de destination. Consultez l’attribut identifié dans
l’événement et recherchez un numéro de version élevé, ou obtenez plusieurs journaux pour le même objet tout
au long de la journée et voir si le numéro de version augmente fréquemment.
Temporaire
Modifications en bloc rarement
Après avoir héberger une partition pour la première fois ou pendant un hôte
Problème basé sur les performances
Les symptômes courants de la mise en file d’attente induite par les performances sont les suivants :

Description :
Avertissement de performances : la réplication a été retardée
lors de l’application des modifications à l’objet suivant. Si c’est le cas
se produit fréquemment, il indique que le message
se produit lentement et que le serveur peut
ont des difficultés à suivre les modifications.
DN objet : CN=TU,OU=Workstations,DC=contoso,DC=com
DN de partition : DC=contoso,DC=com
Serveur : <GUID>._msdcs.contoso.com
Temps écoulé (secs) : 13
Une raison courante de voir ce délai est que cet objet est particulièrement grand, soit dans la taille de ses
valeurs, soit dans le nombre de valeurs. Vous devez d’abord déterminer si l’application peut être modifiée
pour réduire la quantité de données stockées sur l’objet ou le nombre de valeurs. S’il s’agit d’un groupe
important ou d’une liste de distribution, vous pouvez envisager d’augmenter la version de la forêt vers
Windows Server 2003, car cela permettra à la réplication de fonctionner plus efficacement. Vous devez
évaluer si la plateforme serveur offre des performances suffisantes en termes de mémoire et de puissance
de traitement. Enfin, vous pouvez envisager de régler la base de données Active Directory en déplaçant la
base de données et les journaux vers des partitions de disque distinctes.
Si vous souhaitez modifier la limite d’avertissement, la clé de Registre est incluse ci-dessous. La valeur zéro
désactive la vérification.
Limite supplémentaire d’avertissement de données (secs) : 10 clés de Registre limites :
System\CurrentControlSet\Services\NTDS\Parameters\Replicator maximum wait for update object (secs)
Déterminez si les modifications appliquées à la base de données se produisent lentement à l’aide de l’analyse
des performances et de la repadmin /queue sortie. Corréler les compteurs de réplication AD avec les compteurs
de performance du système d’exploitation de base (disque, mémoire, réseau et processeur).
DC
Disque
Réseau
La file d’attente contient 55 éléments.

La tâche en cours a commencé à s’exécuter à .<DateTime>
La tâche s’exécute depuis 508 minutes, 53 secondes.
[6485] Enqueued 2011-11-26 01:55:33 à la priorité 590
SYNC FROM SOURCE NC DC=corp,DC=contoso,DC=com
DCDp\5thWardDC
GUID d’objet DC <GUID>
Addr <GUID> de transport DC ._msdcs.contoso.com
FORCE
[12142] Enqueued <DateTime> à la priorité 40
SYNC FROM SOURCE NC dc=west,dc=contoso,dc=com
DC Centre d’états(s) de Washington\Centre d’étude des états
GUID d’objet DC <GUID>
Addr <GUID> de transport DC ._msdcs.contoso.com
ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY PRÉEMPTÉ
Résolution des problèmes de réplication AD lente
Ce problème nécessite une connaissance avancée de plusieurs outils de dépannage. Il peut être nécessaire de
demander l’aide du Support Microsoft pour vous aider dans le processus d’analyse des données.
Terminologie : lent et latent
Dans une réplication AD lente, les modifications sont apportées à la base de données Active Directory lentement
ou les tâches de réplication prennent beaucoup de temps à traiter.
Les causes courantes sont les suivantes :
Problèmes de performances des systèmes d’exploitation/dc
Ressource d’exploitation
Goulot d’étranglement du disque
Problèmes liés aux bases de données AD
Corruption logique ou physique
Problèmes d’objet ou d’attribut
Problèmes de chargement dc
Gestion d’un trop grand nombre de clients
Tempête de réplication
Taux élevé de modification des objets et des attributs
Synchronisations de partition complètes
Dans la réplication AD latente, le dc n’est pas informé des modifications pendant un certain temps :
Les causes courantes sont les suivantes :
Configuration de la topologie AD (planification, liens de site, planification de réplication, topologie
déconnectée)
Cette stratégie de collecte de données et de documents est destinée à être utilisée pour résoudre les problèmes
de réplication AD lente.
Symptômes d’une réplication AD lente
Repadmin Data
À utiliser Repadmin /queue pour documenter les tâches de réplication en file d’attente. Surveillez la file d’attente
pour voir s’il existe un retard dans le traitement des tâches de réplication. Enregistrez toutes repadmin /queue
les sorties dans le même fichier texte pour avoir de bonnes données historiques.
Repadmin /queue DCName >DCNameReplQueue.txt

Choice /d y /t 300
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 300
Choice /d y /t 900
Choice /d y /t 900
Choice /d y /t 1800
Examinez la sortie pour voir si les tâches de réplication sont traitées en temps voulu. La partie supérieure du
fichier contient la tâche en cours d’exécution et la durée de son exécution. Si la même tâche est toujours en haut
de la sortie, vous pouvez utiliser la sortie détaillée repadmin /showrepl pour surveiller la progression.
Modifications de repadmin
Repadmin /showrepl
Utilisez Repadmin /showrepl et l’option /verbose pour surveiller l’état de la dernière réplication et le nombre de
modifications qui restent à répliquer.
Repadmin /showrepl /verbose DCNameDomainDN
Repadmin /showrepl /verbose 5thwardCorpDC dc=corp,dc=contoso,dc=com
Pour limiter la sortie afin que seul le dc source souhaité s’affiche, utilisez ce qui suit :
Repadmin /showrepl /verbose DCNameDomainDN SourceDcDSAObjectGUID
Repadmin /showrepl /verbose 5thwardCorpDC <GUID> dc=corp,dc=contoso,dc=com
Repadmin /showutdvec
À utiliser Repadmin /showutdvec sur le dc source et de destination pour déterminer le delta de réplication.
repadmin /showutdvec DCName DomainDN
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com
Obtenir Repadmin /showutdvec /latency à partir de la source et de la destination DC pour la partition en

question.
Dans la sortie, documente les documents suivants :
1. From source DCs showutdvec: USN # next to Source DCName
2. À partir des DCs de destination showutdvec USN# à côté de SOURCE DCNanme
Source DC
Dallas\2008DC1 @ USN 451265 @ Time <DateTime>

Dallas\SourceDC @ USN 1126541 @ Time <DateTime>
Domaine\2012DC3 @ USN 469842 @ Time <DateTime>
66a1b264-80b8-44f8-8356-9ebcd7a34f15 @ USN 32811 @ Time <DateTime>
Dallas\DestinationDC @ USN 1353465 @ Time <DateTime>
Destination DC

Dallas\SourceDC @ USN 801224 @ Time <DateTime>
Domaine\2012DC3 @ USN 469842 @ Time <DateTime>
66a1b264-80b8-44f8-8356-9ebcd7a34f15 @ USN 32811 @ Time <DateTime>
Dallas\DestinationDC @ USN 1359087 @ Time <DateTime>
Source DC
SourceDC @ USN 1126541
Destination DC
SourceDC @ USN 801224
1126541-801224 = 325317
Le dc de destination est 325 317 usns en retard.
NOTE
Vous pouvez également obtenir les DCS source highestcommitedUSN à partir du dc source à l’aide de cette commande
:
repadmin /showattr SourceDC . /atts:highestcommittedusn DN: 1> highestCommittedUSN: 1126541
Données de performance
Créez un ensemble de collecteurs de données définis par l’utilisateur dans l’Analyseur de performances qui
utilise le modèle Diagnostics AD.
Les étapes qui s’y rapportent détaillent la configuration d’un bon ensemble de compteurs de performances dc
de référence. Vous devrez modifier certains paramètres, tels que la durée et l’intervalle d’échantillonnage pour
adapter votre scénario spécifique.
Comment créer un ensemble de collecte de données définies par l’utilisateur
1. Ouvrez le Gestionnaire de serveur sur une version complète Windows Server 2008 ou une version
ultérieure.
2. Développez diagnostics et > performances > des ensembles de collecteurs de données.
3. Cliquez avec le bouton droit sur User Defined et sélectionnez New > Data Collector Set.
4. Tapez un nom tel que Diagnostics AD DS et laissez la sélection par défaut créer à partir d’un modèle
(recommandé) sélectionnée. Ensuite, sélectionnez Suivant.
5. Sélectionnez Diagnostics Active Directory dans la liste des modèles, puis sélectionnez Suivant et suivez les
invites de l’Assistant (a apporter les modifications que vous pensez nécessaires).
6. Cliquez avec le bouton droit sur le nouvel ensemble de collecteurs de données défini par l’utilisateur et
affichez les propriétés.
7. Pour modifier l’heure d’application, modifiez les paramètres Durée globale dans l’onglet Arrêter la condition,
puis cliquez sur OK pour appliquer les modifications.
Options à prendre en compte :
Durée globale : vous pouvez faire arrêter le collecteur de données après la collecte pour une durée définie
Limites : vous pouvez faire arrêter la collecte des données après qu’un seuil de taille ou de temps est
atteint (avec la possibilité de le faire redémarrer automatiquement)
La définition de limites est avantageuse lorsque vous souhaitez limiter la taille du journal.
Redémarrer le jeu de collecteurs de données aux limites
Durée
Taille maximale
Afficher les propriétés du compteur de performance pour l’ensemble de collecteurs de données définis par
l’utilisateur
1. Sélectionnez votre nouvel ensemble de collecteurs de données définis par l’utilisateur.
2. Cliquez avec le bouton droit sur Compteur de performances, puis sélectionnez Propriétés.
Vous avez ici la possibilité de modifier l’intervalle de l’exemple et d’ajouter ou de supprimer des compteurs
supplémentaires.
Pour ce scénario, l’intervalle d’échantillonnage par défaut de 3 secondes doit être suffisant. Toutefois, pour des
périodes d’échantillonnage beaucoup plus longues, un intervalle de 3 secondes est trop fréquent.
Tous les compteurs recommandés sont inclus dans l’ensemble de collecteurs AD Diagnostic par défaut, à trois
exceptions près :
Database ==>Instances(lsass/NTDSA)\ *
LogicalDisk(*)\*
Pour LogicalDisk : toutes les instances ne sont pas requises : le lecteur système et les lecteurs où les bases
de données et les journaux sont stockés doivent être inclus au niveau minimum de la sécurité System-
Wide statistiques\*
Statistiques de System-Wide sécurité\*
Pour ajouter les compteurs de base de données AD DS au jeu de collecte de données défini par l’utilisateur
1. Dans Propriétés du compteur de performance, sélectionnez Ajouter.
2. Expand Database ==>Instances (tous les compteurs doivent être mis en surbrillant).
3. Sous Instances de l’objet sélectionné, sélectionnez lsass/NTDSA
4. Sélectionnez Ajouter, puis cliquez sur OK.
5. Ajoutez également les objets LogicalDisk et Security System-Wide Statistics.
Une fois les paramètres configurés à votre convenance, vous pouvez exécuter le nouveau jeu de collecteurs de
données directement à partir du Gestionnaire de serveur ou l’exporter et le déployer sur des serveurs
spécifiques.
Lorsque vous êtes prêt à commencer à collecter des données de performances, démarrez votre ensemble de
collections nouvellement défini :
Pour démarrer votre jeu de collecte de données nouvellement défini à partir de la MMC :
1. Dans le mmc Analyseur de performances, accédez à Performances/ Ensembles de collecteurs de données/
Défini par l’utilisateur
2. Cliquez avec le bouton droit sur le nouvel ensemble de collections AD DS Diagnostics et sélectionnez
Démarrer.
3. Vous pouvez vérifier qu’il a démarré en sélectionnant l’état Exécution des diagnostics AD DS définis par
l’utilisateur
Une fois le test terminé, arrêtez l’ensemble de collections de diagnostics AD DS :
1. Dans le mmc Analyseur de performances, accédez à Performance / Jeux de collecteurs de données/Défini par
l’utilisateur.
2. Cliquez avec le bouton droit sur la nouvelle collection de diagnostics AD DS , puis sélectionnez Arrêter. Vous
pouvez vérifier qu’il s’est arrêté en sélectionnant Défini par l’utilisateur.
Les diagnostics AD DS doivent passer de l’état Exécution à Compilation et enfin Arrêté. Veuillez noter que le
MMC n’est pas parfait pour l’actualisation de son affichage. Ainsi, s’il semble bloqué en cours d’exécution ou de
compilation après avoir cliqué sur L’écran, essayez d’actualisation de l’écran.
Le rapport compilé est consultable sous Performances/ Rapports/ Défini par l’utilisateur / Diagnostics AD DS
Le chemin d’accès par Windows Explorer se trouve ici : %systemdrive%\PerfLogs\Admin\AD DS Diagnostics
Instructions de ligne de commande : collecter les diagnostics AD à partir de la ligne de commande :
Pour DÉMARRER une collection de données à partir de la ligne de commande, lancez cette commande à partir
d’une invite de commandes avec élévation de élévation de niveau :
logman start "user defined\AD DS Diagnostics" -ets
Pour ARRÊTER la collecte de données avant la valeur par défaut de 5 minutes, émettre la commande suivante :
(obtenez au moins un exemple complet de cinq minutes pour ce problème)
logman stop "user defined\AD DS Diagnostics" -ets
Les données de diagnostic sont enregistrées ici : C:\PerfLogs\Admin\AD DS DiagnosticsDateStamp\

Exemple de script de collecte de données
logman start "system\Active Directory Diagnostics" -ets time /t >slow.txt

repadmin /showrepl /verbose LiverpoolDC1 dc=north,dc=fabrikam,dc=com >slowrepl.txt
repadmin /queue LiverpoolDC1 >>slow.txt
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slow.txt
:start
ping 127.0.0.1 -n 60 >NUL
time /t >>slow.txt time /t >>slowrepl.txt
repadmin /showrepl /verbose LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slowrepl.txt
repadmin /queue LiverpoolDC1 >>slow.txt
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slow.txt
goto start
Données du journal des événements

La journalisation par défaut activée dans le journal des événements des services d’annuaire est utile pour
surveiller les événements qui indiquent une application lente des modifications. (ÉVÉNEMENT X) La
journalisation détaillée des diagnostics peut être activée pour voir les modifications en cours d’application.
L’activation de la journalisation des diagnostics au niveau mentionné dans cet article entraîne le remplissage du
journal assez rapidement. Activez-le donc uniquement lors de la résolution active de cette condition. Pour vous
donner une idée du taux d’événements consignés avec ce niveau de verbosité :
Journal des événements des services d’annuaire configuré sur 100 Mo wrapped en moins de deux minutes (1
minute 27 secondes). Le journal contenait 195 728 événements. De tous les événements, 189 340 étaient des ID
d’événement 1412 (ajout d’attribut).
Augmenter la taille du journal des événements des services d’annuaire
Dimensionner le journal des événements afin que la journalisation améliorée ne provoque pas
l’encapsulage du journal trop court d’un point
Activez la journalisation des diagnostics de réplication AD 0x5 :
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics 5 Replication Events = 5
Exportez le journal des événements des services d’annuaire peu de temps après avoir reçu l’état 8461 et
réduisez la journalisation des diagnostics à un niveau approprié.
Examinez le journal des événements pour obtenir les données suivantes :
À quelle vitesse les valeurs d’attribut sont-elles écrites dans la base de données ? ->'ID d’événement du journal
des événements des services d’annuaire 1412 ou encore meilleur, utilisez le compteur de performances :
DirectoryServices /DRA Inbound Properties Applied/s
Au niveau de diagnostic 5 pour les événements de réplication, pour la création d’objets utilisateur, environ 25
événements 1412 (selon ce qui a été écrit au moment de la création de l’utilisateur) sont écrits (un par valeur
d’attribut). Lorsque tous les attributs ont été ajoutés, l’événement de création d’objet est journalisé (ID
d’événement 1365).
La section description de l’événement contient les données suivantes :
Événement interne :
Les modifications d’objet suivantes ont été appliquées à la base de données des services de domaine Active
Directory locale.
Propriété : 900dd (sAMAccountName)
Objet : CN=xtestingusers14167,CN=Users,DC=north,DC=fabrikam,DC=com, objet
GUID : <GUID>
Version distante : 1
Timestamp distant : <DateTime>
UsN d’origine distante : 540828
La section Property contient les attributID et lDAPDisplayName de l’attribut.

Un événement est écrit par valeur à ce niveau de journal de débogage. Filtrez les événements et déterminez le
nombre d’entrées qui se produisent sur une période donnée. Examinez les détails de l’événement afin de
déterminer si nous écrivons des valeurs pour plusieurs attributs afin d’inssérer un objet ou si nous écrivons
dans le même attribut sur plusieurs objets. Bien que ce niveau d’analyse puisse sembler fastidieux, il peut être
utile pour déterminer la cause première. Par exemple, si vous voyez que nous écrivons seulement quelques
événements par seconde, cela peut indiquer que les transactions sont écrites lentement dans la base de données
ou que nous avons peut-être trop de partenaires qui envoient des modifications redondantes (ID d’événement
1239).
Notez qu’il est parfaitement normal de voir l’ID d’événement 1239 lorsque les diagnostics de réplication sont
0x5. Si vous filtrez l’événement 1239 et que vous ne voyez rien d’autre et que vous avez un historique
relativement long du journal des événements, cela peut indiquer un problème. Ce problème a été observé par
un client avec un environnement Active Directory de grande taille pour qui la notification de modification inters
site était activée. Si vous déterminez qu’il y a un grand nombre d’événements par seconde, la réplication n’est
probablement pas affectée par un problème de performances.
Métadonnées d’objet
Si un événement journalisé indique qu’une modification prend beaucoup de temps pour traiter l’ID
d’événement, enregistrez l’objetGUID, puis obtenez la sortie suivante :
Métadonnées de réplication :
Repadmin /showobjmeta "<GUID=ObjectGUID>" >objectmeta.txt
Examinez la sortie pour les attributs récemment modifiés. Accordez une attention particulière aux attributs dont
les numéros de version sont fréquemment modifiés. Un attribut dont le nombre de versions est élevé peut
indiquer que des modifications fréquentes sont apportées à l’attribut. Si vous suspectez cela, vous pouvez
afficher la valeur d’attribut pour obtenir un contexte sur la raison de la changement de l’attribut, ou vous pouvez
laisser passer un certain temps, repadmin /showobjmeta puis obtenir une sortie supplémentaire afin de vérifier si
la version du même attribut sur le même objet a augmenté davantage.
Données d’objet et d’attribut :
Utilisez un utilitaire pour la sortie des valeurs d’objet et d’attribut. Ensuite, examinez les données d’attribut pour
les attributs qui ont récemment modifié des données. Les exemples suivants présentent deux méthodes pour ce
faire.
Valeurs d’attribut d’objet du repadmin :
Repadmin /showattr DCName "<GUID=ObjectGUID>" /allvalues /long >objectByGuid.txt
Valeurs d’attribut d’objet de LDP

Connecter et lier au serveur dans LDP et copier toutes les sorties de l’objet dans un fichier texte
ldpoutput.txt
Données liées au réseau
Tasklist /svc >nets.txt Netstat -anob >>nets.txt
Compteurs de performances spécifiques à la réplication AnalysisKey AD

DRA Inbound Full Sync Objects Remaining
Objets entrants DRA appliqués/s
Objets entrants DRA / seconde (réplication entrante)
Objets entrants d’ra filtrés/s (suggère tous les nouveaux attributs)
Nombre total d’octets sortants de l’ra depuis la file d’attente de réplication de démarrage :
IN DIQ UE L E N O M B RE DE
SY N C H RO N ISAT IO N S D’A N N UA IRES
EN F IL E D’AT T EN T E P O UR C E SERVEUR. C E C O M P T EUR DO IT ÊT RE A USSI B A S
C E C O M P T EUR P ERM ET D’IDEN T IF IER Q UE P O SSIB L E. SI C E N ’EST PA S L E
L ES B A C K LO GS DE RÉP L IC AT IO N : C A S, L E M AT ÉRIEL DU SERVEUR
DIREC TO RY SERVIC ES\ DRA P EN DIN G P L US L E N O M B RE EST ÉL EVÉ, P L US L E RA L EN T IT P RO B A B L EM EN T L A
REP L IC AT IO N SY N C H RO N IZ AT IO N S B A C K LO G EST VO L UM IN EUX. RÉP L IC AT IO N .
Utilisez ce compteur pour déterminer la file d’attente de réplication. Repadmin /queue DCName signale
également ces informations.
Mesurer les performances actuelles :
IN DIQ UE L E N O M B RE D’O B JET S REÇ US PA R DES VO ISIN S VIA
O B JET S EN T RA N T S DRA A P P L IQ UÉS/ S L A RÉP L IC AT IO N EN T RA N T E ET A P P L IQ UÉS.
Propriétés entrantes DRA appliquées/s Indique le nombre total de propriétés d’objet (attributs)
appliquées à partir de partenaires de réplication entrante.
Vous pouvez utiliser les deux compteurs pour surveiller la rapidité d’application des modifications à la base de
données.
Base de données :
Performances du serveur :
C E C O M P T EUR IN DIQ UE Q UE L E
SERVEUR SURVEIL L É REÇ O IT DES
M O DIF IC AT IO N S, M A IS Q UE L EUR
A P P L IC AT IO N À L A B A SE DE DO N N ÉES
IN DIQ UE L E N O M B RE DE M ISES À P REN D B EA UC O UP DE T EM P S. C E
JO UR D’O B JET S REÇ UES DA N S L E C O M P T EUR DO IT ÊT RE A USSI B A S Q UE
PA Q UET DE M ISE À JO UR DE P O SSIB L E. SI C E N ’EST PA S L E C A S,
DIREC TO RY SERVIC ES\ DRA IN B O UN D RÉP L IC AT IO N D’A N N UA IRE L E P L US C EL A IN DIQ UE GÉN ÉRA L EM EN T Q UE
O B JEC T UP DAT ES REM A IN IN G IN RÉC EN T Q UI N ’O N T PA S EN C O RE ÉT É L E M AT ÉRIEL SERVEUR RA L EN T IT L A
PA C K ET A P P L IQ UÉES A U SERVEUR LO C A L . RÉP L IC AT IO N .
Réseau :
O B JEC T \ C O UN T ER DESC RIP T IO N C O N SEIL S
DirectoryServices\DRA Inbound Bytes Indique le nombre total d’octets reçus

Total/s par seconde via la réplication entrante.
Ce nombre est la somme des octets de
données non compressées et non
compressées reçues pendant le trafic
entrant
Tests
Scénario Deux DCS ont été isolés (aucune activité de client ou autre serveur) 15 000 utilisateurs ont été créés à
partir d’un script avec les attributs minimaux remplis sur un dc Activé la connexion entre les deux DCS.
Pour vous donner une idée du taux d’événements consignés avec ce niveau de verbosité :
Un journal des événements des services d’annuaire configuré à 100 Mo dans une taille wrapped en moins de
deux minutes (1 minute 27 secondes). Le journal contenait 195 728 événements. De tous les événements, 189
340 étaient des ID d’événement 1412 (ajout d’attribut). Le nombre d’événements 1412 par seconde :
01: 2400
02: 3570
03: 3540
04: 2160
05: 1170
06: 1890
07: 2225
08: 1435
09: 4233
10: 2817
L’ID d’événement 1365 (création d’objet) a été enregistré 6 312 fois en 1 minute 27 secondes. En une minute, 4
630 objets utilisateur ont été créés, composés de 138 900 attributs), soit environ 77 objets par seconde.
Une compréhension des compteurs de performance NTDS est nécessaire pour résoudre efficacement ce
problème.
Les créations d’objets par seconde sont obtenues via les compteurs de performance suivants :
Objets entrants NTDS/DRA appliqués/s
La base de données ajoute/s
Valeurs entrantes NTDS/DRA (DNs uniquement)/s Ce nombre inclut des objets qui font référence à
d’autres objets. Les valeurs pour les noms différents, telles que les appartenances à des groupes ou des
listes de distribution, sont plus coûteuses à appliquer que d’autres types de valeurs, car un objet de liste
de distribution ou de groupe peut inclure des centaines ou des milliers de membres. En revanche, un
objet simple ne peut avoir qu’un ou deux attributs. Un nombre élevé de ce compteur peut expliquer
pourquoi les modifications entrantes sont lentes à être appliquées à la base de données. Créations
d’attributs par seconde :
Propriétés entrantes NTDS/DRA appliquées/s
Condition spéciale fréquemment rencontrée
Repadmin /rehost entraîne l’état 8461 :
Ce problème se produit lorsque le gc en cours d’hosted est occupé à accepter les mises à jour pour d’autres
partitions. La recherche de partitions de domaine accessibles en lecture, y compris le schéma, la configuration et
la partition de domaine, est par nature des éléments de travail plus prioritaires que la réhosting d’une partition
de domaine en lecture seule.
La sortie du repadmin/file d’attente doit montrer que la demande d’ajout de la partition a été mis en file
d’attente et qu’elle sera finalement traitée. Toutefois, il est parfois nécessaire d’utiliser une autre méthode d’host
de partition :
1. Repadmin /unhost
2. Attendre l’ID d’événement 1660
3. Désactiver la traduction de connexion KCC
4. Repadmin /addIf le processus est préempté avant la fin de /add, repadmin /replicate /readonly /force
vous pouvez désactiver la réplication et l’utilisation entrantes, ainsi que les options et les options permettant
de ré-héberger la partition avant de réactiver la réplication entrante.
Erreur de réplication Active Directory 8606 : des
attributs insuffisants ont été attribués pour créer un
objet
Cet article fournit de l’aide pour résoudre l’erreur de réplication Active Directory 8606 : des attributs insuffisants
ont été attribués pour créer un objet.
NOTE
Résumé
Cet article décrit les symptômes et les causes d’un problème dans lequel la réplication Active Directory échoue
et génère l’erreur 8606 : « Des attributs insuffisants ont été attribués pour créer un objet. Cet objet n’existe peut-
être pas car il a peut-être été supprimé. » Cet article décrit également une résolution de ce problème.
Symptômes
Symptôme 1
DcDIAG signale que le test réplications Active Directory a échoué avec l’erreur 8606 : « Des attributs insuffisants
ont été attribués pour créer un objet ».

[Vérification des réplications, <Destination DC> ] Une tentative de réplication récente a échoué :
Des attributs insuffisants ont été attribués pour créer un objet. Cet objet n’existe peut-être pas, car il a peut-
être été supprimé et déjà collecté la garbage
L’échec s’est produit à <date> <time>
Le dernier succès s’est produit à l' <date> <time>
Symptôme 2
Réplication entrante déclenchée par la commande Répliquer maintenant dans le logiciel en ligne DSSITE (Sites et
services Active Directory). Le MSC échoue et génère l’erreur « Des attributs insuffisants ont été attribués pour
créer un objet ». Lorsque vous cliquez avec le bouton droit sur un objet de connexion à partir d’un dc source,
puis sélectionnez Répliquer maintenant, la réplication échoue et génère l’erreur suivante : « L’accès est refusé ».
En outre, le message d’erreur suivant s’affiche :

Texte du message de boîte de dialogue : l’erreur suivante s’est produite lors de la tentative de
synchronisation du contexte d’attribution de noms <%nom de partition Active Directory%> du contrôleur
de domaine au contrôleur de <source DC> domaine <destination DC> :
Des attributs insuffisants ont été attribués pour créer un objet. Cet objet n’existe peut-être pas, car il a peut-
être été supprimé et déjà collecté la garbage.
Symptôme 3
Diverses REPADMIN.EXE de commande échouent avec l’erreur 8606. Ces commandes incluent, sans s’y limiter,
les éléments suivants :
repadmin /add repadmin /replsum
repadmin /showrepl repadmin /showrepl
repadmin /syncall
Symptôme 4
L’événement 1988 est consigné peu de temps après l’un des événements suivants :
Le premier contrôleur de domaine de la forêt est déployé.
Toute mise à jour du jeu d’attributs partiel est réalisée.
Symptôme 5
L’événement de réplication NTDS 1988 peut être enregistré dans le journal des événements du service
d’annuaire des contrôleurs de domaine qui tentent de répliquer active Directory entrante.
Tapez : Erreur
Source : réplication NTDS
Catégorie : Réplication
Ordinateur : <hostname of DC that logged event, aka the "destination" DC in the replication attempt>
Description : le contrôleur de domaine local a tenté de répliquer l’objet suivant à partir du contrôleur de
domaine source suivant. Cet objet n’est pas présent sur le contrôleur de domaine local, car il a peut-être été
supprimé et déjà collecté la garbage.
<fully qualified GUIDED CNAME of source DC>
Objet :
<DN path of live object on source DC>
GUID d’objet :
<object GUID of object on source DCs copy of Active Directory>
Cause
L’erreur 8606 est consignée lorsque les conditions suivantes sont vraies :
Un contrôleur de domaine source envoie une mise à jour à un objet (au lieu d’une création d’objet d’origine)
qui a déjà été créé, supprimé, puis récupéré par le garbage collection à partir de la copie Active Directory
d’un contrôleur de domaine de destination.
Le contrôleur de domaine de destination a été configuré pour s’exécuter dans une cohérence de réplication
stricte.
Si le contrôleur de domaine de destination a été configuré pour utiliser la cohérence de réplication souple, l’objet
aurait été « réanimé » sur la copie du répertoire du contrôleur de domaine de destination. Les variantes
spécifiques qui peuvent provoquer une erreur sont 8606 documentées dans la section « Plus d’informations ».
Toutefois, l’erreur est due à l’une des raisons suivantes :
Objet définitivement en attente dont la suppression nécessite l’intervention de l’administrateur
Objet temporaire temporaire qui se corrige lui-même lorsque le contrôleur de domaine source effectue son
prochain nettoyage de nettoyage de la garbage-collection. L’introduction du premier contrôleur de domaine
dans une forêt existante et les mises à jour du jeu d’attributs partiel sont des causes connues de cette
condition.
Objet qui n’a pas été supprimé ou restauré au moment de l’expiration de la durée de vie de tombstone
Lorsque vous dépanner les erreurs 8606, réfléchissez aux points suivants :
Bien que l’erreur 8606 soit consignée sur le contrôleur de domaine de destination, l’objet problème qui
bloque la réplication réside sur le contrôleur de domaine source. En outre, le contrôleur de domaine
source ou un partenaire de réplication transitif du contrôleur de domaine source n’a potentiellement pas
pu répliquer entrante connaissance d’un nombre de jours de durée de vie de tombstone supprimé dans
le passé.
Les objets en attente peuvent exister dans les circonstances suivantes :
En tant qu’objets « live », en tant qu’objets CNF ou en conflit mangled « live » ou en tant qu’objets CNF
ou en conflit mangled dans le conteneur d’objets supprimés du contrôleur de domaine source
Dans n’importe quelle partition d’annuaire à l’exception de la partition de schéma. Les objets en
attente sont le plus souvent trouvés dans les partitions de domaine en lecture seule sur les GCs. Les
objets en attente peuvent également exister dans les partitions de domaine accessibles en writables
ainsi que dans la partition de configuration. La partition de schéma ne prend pas en charge les
suppressions.
Dans n’importe quelle classe d’objet (les utilisateurs, les ordinateurs, les groupes et les
enregistrements DNS sont les plus courants).
N’oubliez pas de rechercher des objets potentiellement en attente par GUID d’objet ou chemin d’accès DN
afin que les objets soient trouvés indépendamment de leur partition hôte et conteneur parent. La
recherche par objectguid permet également de localiser les objets qui se trouve dans le conteneur
d’objets supprimés sans utiliser le contrôle LDAP des objets supprimés.
L’événement NTDS Replication 1988 identifie uniquement l’objet actuel sur le contrôleur de domaine
source qui bloque la réplication entrante par un contrôleur de domaine de destination en mode strict. Il
existe probablement d’autres objets « derrière » l’objet référencé dans l’événement 1988 qui est
également en attente.
La présence d’objets en attente sur un contrôleur de domaine source empêche ou bloque les contrôleurs
de domaine de destination en mode strict de répliquer les « bonnes » modifications entrantes qui se
cachent derrière l’objet en attente dans la file d’attente de réplication.
En raison de la façon dont les contrôleurs de domaine suppriment individuellement des objets de leurs
conteneurs d’objets supprimés (le daemon de nettoyage de la garbage-collection s’exécute toutes les 12
heures à partir de la dernière exécution de chaque contrôleur de domaine), les objets qui provoquent
8606 erreurs sur les contrôleurs de domaine de destination peuvent être supprimés lors de la prochaine
exécution de nettoyage du nettoyage de la garbage-collection. Les objets en attente dans cette classe sont
temporaires et doivent se supprimer eux-mêmes dans un peu plus de 12 heures après le début du
problème.
L’objet en question en question est probablement un objet qui a été intentionnellement supprimé par un
administrateur ou une application. Factorez-le dans votre plan de résolution et prenez garde à la
réanimation des objets, en particulier les principaux de sécurité qui ont été supprimés intentionnellement.
Résolution
Résolution
1. Identifiez la valeur actuelle pour le paramètre TombStoneLifeTime à l’échelle de la forêt.
c:\>repadmin /showattr. "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest

root domain,DC=TLD> /atts:tombstonelifetime
Consultez la section « Durée de vie et réplication de suppressions de Tombstone » dans l’article suivant
de la Base de connaissances Microsoft :
910205 informations sur les objets en attente dans Windows Server Active Directory forêt.
2. Pour chaque contrôleur de domaine de destination qui enregistre l’erreur 8606, filtrez le journal des
événements du service d’annuaire sur l’événement de réplication NTDS 1988.
3. Collecter des métadonnées pour chaque objet unique mentionné dans l’événement de réplication NTDS
1988. À partir de chaque événement 1988 enregistré sur le contrôleur de domaine de destination qui
mentionne un nouvel objet, remplir le tableau suivant :
C H EM IN EN DIREC T
D’A C C ÈS DN GUID PA RT IT IO N OU L A ST K N O W VA L EUR
DE L’O B JET D’O B JET SO URC E DC H ÔT E SUP P RIM É ? N PA REN T ISDEL ET ED
Les colonnes 1 à 5 de ce tableau peuvent être remplies en lisant les valeurs directement à partir des
champs des événements NTDS Replication 1988 enregistrés dans les journaux des événements du
service d’annuaire des contrôleurs de domaine de destination qui enregistrent l’événement 1988 ou l’état
de réplication 8606.
Les cachets de date pour les colonnes LastKnownParent et IsDeleted peuvent être déterminés en
exécutant et en référençant l’objet qui est mentionné dans l’événement 1988 de réplication
repadmin /showobjmeta NTDS. Pour ce faire, utilisez la syntaxe suivante :
c:\>repadmin /showobjmeta <fqdn of source DC from 1988 event> "<GUID=GUID of object cited in the 1988
event>"
Le cachet de date de LastKnownParent identifie la date à laquelle l’objet a été supprimé. Le cachet de date
pour IsDeleted vous indique à quel moment l’objet a été supprimé ou réanimé pour la dernière fois. Le
numéro de version vous indique si la dernière modification a supprimé ou réanimé l’objet. Une valeur
IsDeleteted de 1 représente une suppression initiale. Les valeurs impaires supérieure à 1 indiquent une
réanimation après au moins une suppression. Par exemple, une valeur isDeleted de 2 représente un
objet qui a été supprimé (version 1), puis qui est ensuite supprimé ou réanimé (version 2). Les valeurs de
type even-numbered ultérieures pour IsDeleted représentent des animations ou des suppressions
ultérieures de l’objet.
4. Sélectionnez l’action appropriée en fonction des métadonnées d’objet mentionnées dans l’événement
1988.
L’erreur 8606 / événement de réplication NTDS 1988 est le plus souvent dû à des échecs de réplication à
long terme qui empêchent les contrôleurs de domaine de réplication entrante de toutes les suppressions
d’origine dans la forêt. Cela entraîne des objets en attente sur un ou plusieurs contrôleurs de domaine
source.
Examinez les métadonnées de l’objet répertorié dans le tableau créé à l’étape 4 de la section « Résolution
».
Si l’objet de l’événement 1988 est soit ((live sur le contrôleur de domaine source), mais (supprimé sur le
contrôleur de domaine de destination pour une durée de vie plus longue que l’expiration de la durée de
vie de tombstone), voir « Suppression des objets en attente » et « ». Les objets dans cette condition
doivent être supprimés manuellement par un administrateur.
Les objets supprimés ont peut-être été supprimés prématurément du conteneur d’objets supprimés si le
temps système a avancé dans le temps sur le contrôleur de domaine de destination. Consultez la section
« Vérifier les sauts de temps ».
Si l’objet mentionné dans l’événement 1988 existe dans le conteneur d’objets supprimés du contrôleur de
domaine source et que sa date de suppression se trouve juste au moment de l’expiration de la durée de
vie de tombstone de telle sorte que l’objet a été récupéré par le garbage collection par un ou plusieurs
contrôleurs de domaine de destination et qu’il sera récupéré par le garbage collection lors de l’intervalle
suivant du garbage-collection sur les contrôleurs de domaine source (c’est-à-dire, les objets en attente
sont temporaires), vous avez le choix. Attendez la prochaine exécution du garbage collection pour
supprimer l’objet ou déclenchez manuellement le garbage collection sur le contrôleur de domaine source.
Voir « Démarrage manuel du collecte de la garbage ». L’introduction du premier contrôleur de domaine
ou toute modification du jeu d’attributs partiels peut provoquer cette condition.
Si la sortie de l’objet mentionné dans l’événement 1988 a une valeur LastKnownParent de 1, cela indique
que l’objet a été supprimé et qu’une valeur IsDeleted est de 2 ou une autre valeur numérotée, et que le
cachet de date pour IsDeleted est au niveau de la cusp du nombre de jours de durée de vie de tombstone
différent du cachet de date pour repadmin /showobjmeta LastKnownParent, l’objet a ensuite été supprimé,
puis supprimé /auth-restored alors qu’il était toujours en cours sur le contrôleur de domaine source,
mais déjà récupéré par le garbage collection par les contrôleurs de domaine de destination, erreur de
journalisation 8606 / Événement 1988. Voir Reanimations à la fin de l’expiration de TSL
Comment supprimer des objets en attente
Bien qu’il existe de nombreuses méthodes pour supprimer les objets en attente, il existe trois outils principaux
couramment utilisés : repadmin.exe, Outils d’objets en attente (LoL) et repldiag.
Entâmateur d’objets en attente (LoL)
La méthode la plus simple pour nettoyer les objets en attente consiste à utiliser le lol. L’outil LoL a été développé
pour vous aider à automatiser le processus de nettoyage par rapport à une forêt Active Directory. L’outil est basé
sur l’interface utilisateur graphique et peut analyser la forêt Active Directory actuelle et détecter et nettoyer les
objets en attente. L’outil est disponible dans le Centre de téléchargement Microsoft.
Repadmin
Les deux commandes suivantes peuvent REPADMIN.EXE objets en attente des partitions d’annuaire :
REPADMIN /REMOVELINGERINGOBJECTS
REPADMIN /REHOST
REPADMIN /REMOVELINGERINGOBJCTS permet de supprimer les objets en attente des partitions d’annuaire
accessibles en lecture seule et accessibles en lecture seule sur les contrôleurs de domaine source. La syntaxe est
la suivante :
c:\>repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> [/ADVISORY_MODE]
Où :
<Dest_DSA_LIST> est le nom d’un contrôleur de domaine qui contient des objets en attente (comme le
contrôleur de domaine source mentionné dans l’événement NTDS Replication 1988).
<Source DSA GUID> est le nom d’un contrôleur de domaine qui héberge une copie accessible en texte de la
partition d’annuaire qui contient les objets en attente pour lesquels le contrôleur de domaine dans
<Dest_DSA_LIST> dispose d’une connectivité réseau. Le dc à nettoyer (premier DC spécifié dans la commande)
doit être en mesure de se connecter directement au port 389 sur le dc qui héberge une copie accessible en ligne
de la partition d’annuaire (spécifiée en deuxième position dans la commande).
<NC> est le chemin d’accès DN de la partition d’annuaire qui est suspecté de contenir des objets en attente, tels
que la partition spécifiée dans un événement 1988.
REPADMIN /REHOST permet de supprimer des contrôleurs de domaine d’objets en attente qui hébergent une copie
en lecture seule d’une partition d’annuaire de domaines des contrôleurs de domaine. La syntaxe est la suivante :
c:\>repadmin /rehost DSA <Naming Context> <Good Source DSA Address>
Où :
DSA est le nom d’un contrôleur de domaine qui héberge une partition de répertoire de domaine en lecture
seule pour un domaine nonlocal. Par exemple, un gc dans root.contoso.com peut réhost sa copie en lecture seule
de child.contoso.com mais ne peut pas root.contoso.com.
<Naming Context> est le chemin d’accès DN d’une partition d’annuaire de domaine en lecture seule qui réside
dans un catalogue global.
<Good Source DSA Address> est le nom d’un contrôleur de domaine qui héberge une copie accessible en texte
de <Naming Context> . Le contrôleur de domaine doit être disponible sur le réseau pour l’ordinateur de la DSA.
Si l’objet en attente signalé dans l’événement 1988 n’est pas supprimé par le repadmin, évaluez si l’objet sur le
contrôleur de domaine source a été créé dans l’intervalle USN ou si les objets d’origine du contrôleur de
domaine n’existent pas dans le vecteur de date à jour du contrôleur de domaine source.
Repldiag
NOTE
Les objets en attente peuvent également être supprimés à l’aide repldiag.exe. Cet outil automatise le
repadmin /removelingeringobjects processus. La suppression d’objets en attente d’une forêt avec repldiag est aussi
simple que repldiag /removelingeringobjects l’exécution. Toutefois, il est généralement préférable d’exercer un
contrôle sur le processus dans des environnements plus grands. L’option /OverRideReferenceDC vous permet de
sélectionner le dc utilisé pour le nettoyage. L’option vous permet de voir à quoi ressemble un nettoyage à l’échelle de la
forêt /outputrepadmincommandlinesyntax à l’aide du repadmin.
Lancez le laboratoire TechNet à la demande suivant pour une pratique de dépannage guidée de cette erreur et
d’autres erreurs de réplication AD :
Dans l’atelier, vous utilisez à la fois le repadmin et lerepldiag.exe pour supprimer les objets en attente
Résolution des erreurs de réplication Active Directory
Dans ce laboratoire, vous allez parcourir les phases de dépannage, d’analyse et d’implémentation des erreurs de
réplication Active Directory couramment rencontrées. Vous utiliserez une combinaison d’outils ADREPLSTATUS,
repadmin.exe et d’autres outils pour résoudre les problèmes d’un environnement de cinq dc à trois domaines.
Les erreurs de réplication AD rencontrées dans l’atelier sont les suivantes : -2146893022, 1256, 1908, 8453 et
8606. »
Surveillance quotidienne de l’état de réplication Active Directory
Si l’erreur 8606 /Event 1988 a été causée par l’échec de la réplication des modifications Active Directory dans le
dernier nombre de jours de la durée de vie de tombstone, assurez-vous que l’état de réplication Active Directory
est surveillé quotidiennement. L’état de la réplication peut être surveillé à l’aide d’une application de
surveillance dédiée ou en visualxant la sortie de l’option peu coûteuse mais efficace pour exécuter la commande
dans une application de feuille de calcul telle que repadmin /showrepl * /csv Microsoft Excel. (Voir « Méthode 2 :
surveiller la réplication à l’aide d’une ligne de commande » dans l’article de la Base de connaissances Microsoft
910205).
Les contrôleurs de domaine qui n’ont pas été répliqués entrants dans 50 % du nombre de jours de la durée de
vie de tombstone doivent être placés dans une liste de surveillance qui reçoit l’attention de l’administrateur
prioritaire pour rendre la réplication opérationnelle. Les contrôleurs de domaine qui ne peuvent pas être
répliqués doivent être rétrogradés de force s’ils n’ont pas été répliqués dans un délai de 90 % du chiffrement
TSL.
Les échecs de réplication qui apparaissent sur un contrôleur de domaine de destination peuvent être causés par
le contrôleur de domaine de destination, par le contrôleur de domaine source ou par le réseau sous-jacent et
l’infrastructure DNS.
Vérifier les sauts de temps
Pour déterminer si un saut d’heure s’est produit, vérifiez les horodaters dans les journaux d’événements et de
diagnostics (observateur d’événements, journaux netlogon, rapports dcdiag) sur les contrôleurs de domaine de
destination qui enregistrent les repadmin /showreps événements d’erreur 8606 /NTDS Replication 1988 pour les
événements suivants :
Cachets de date qui datent avant la publication d’un système d’exploitation (par exemple, les cachets de date
de CY 2003 pour un système d’exploitation publié dans CY 2008)
Horodats qui prédent l’installation du système d’exploitation dans votre forêt
Horodaodatés à l’avenir
Aucun événement consigné dans une plage de dates donnée
Les équipes de support Microsoft ont vu le temps système sur les contrôleurs de domaine de production sauter
de manière incorrecte les heures, les jours, les semaines, les années et même les dizaines d’années passées et
futures. Si le temps système a été jugé inexact, vous devez le corriger, puis essayer de déterminer pourquoi le
temps a été trop long et ce qu’il est possible de faire pour éviter les temps imprécis et simplement corriger le
temps incorrect. Les questions possibles sont les suivantes :
Le PDC racine de la forêt a-t-il été configuré à l’aide d’une source de temps externe ?
Les sources de temps en ligne de référence sont-elles disponibles sur le réseau et peuvent-elles être résolus
dans DNS ?
Le service de temps microsoft ou tiers était-il en cours d’exécution et dans un état sans erreur ?
Les ordinateurs de rôle de contrôleur de domaine sont-ils configurés pour utiliser la hiérarchie NT5DS pour
l’heure source ?
La protection de la récupération de temps décrite dans l’article de la Base de connaissances Microsoft
884776 mise en place ?
Les horloges système ont-elles de bonnes batteries et une heure précise dans le BIOS sur les contrôleurs de
domaine sur les ordinateurs hôtes virtuels ?
Les ordinateurs hôtes et invités virtuels sont-ils configurés pour l’heure source conformément aux
recommandations du fabricant de l’hébergement ?
L’article de la Base de connaissances Microsoft 884776 des étapes pour protéger les contrôleurs de domaine
de l'« écoute » aux exemples de temps non valides. Plus d’informations sur MaxPosPhaseCorrection et
MaxNegPhaseCorrection sont disponibles dans le billet de blog W32Time Windows Time Service.
Recherchez les objets en attente à repadmin /removelingeringobjects /advisorymode l’aide, puis supprimez-les
selon les besoins.
Relâchez l’utilisateur « Autoriser la réplication avec le partenaire d’autant plus qu’il est endommagé » selon les
besoins.
Comment démarrer manuellement le collecte de la garbage
Plusieurs options s’offrent à vous pour déclencher manuellement le garbage collection sur un contrôleur de
domaine spécifique :
Exécutez « repadmin /setattr " " " doGarbageCollection add 1 »
Exécutez LDIFDE /s <server> /i /f dogarbage.ldif où dobarbage.ldif contient le texte :
dn:
changetype: modify
replace: DoGarbageCollection
dogarbagecollection: 1
-
NOTE
Le caractère « - » final est un élément obligatoire du fichier .ldif.
Animations à la fin de l’expiration de TSL

Pour que cette condition existe, doit signaler que l’objet est « in trouvé » sur le contrôleur de domaine de
destination, mais qu’il est en direct sur le contrôleur de domaine source et qu’il s’agit d’un objet supprimé ou
repadmin /showobject "<GUID=object guid for object in 1988 event>" non supprimé.
Un examen des champs clés à partir du contrôleur de domaine source doit signaler que les valeurs suivantes
sont vraies : LastKnownParent a une valeur de 1 et son cachet de date est au niveau du nombre de jours TSL
dans le repadmin /showobjmeta passé. Son cachet de date indique la date de suppression de l’objet.
IsDeleted a le numéro de version 2 (ou une autre valeur numérotation) où la version 1 a défini la suppression
d’origine et la version 2 est la restauration/réanimation. Le cachet de date pour « isDeleted=2 » doit être ~ TSL
nombre de jours après la dernière date de modification pour LastKnownParent.
Évaluez si l’objet en question doit rester un objet en direct ou un objet supprimé. Si LastKnownParent a la valeur
1, un objet ou une personne a supprimé l’objet. S’il ne s’agit pas d’une suppression accidentelle, il est fortuit que
l’objet soit supprimé des contrôleurs de domaine source qui ont une copie en direct de l’objet.
Si l’objet doit exister sur tous les réplicas, les options sont les suivantes :
Activez la réplication souple sur les contrôleurs de domaine de destination en mode strict qui n’ont pas
l’objet.
Rétrogradez de force les contrôleurs de domaine qui ont déjà collecté la garbage de l’objet.
Supprimez l’objet, puis re-créez-le.
Plus d'informations
Lancez le laboratoire TechNet à la demande suivant pour une pratique de dépannage guidée de cette erreur et
d’autres erreurs de réplication AD :
Résolution des erreurs de réplication Active Directory

Dans ce laboratoire, vous allez parcourir les phases de dépannage, d’analyse et d’implémentation des
erreurs de réplication Active Directory couramment rencontrées. Vous utiliserez une combinaison d’outils
ADREPLSTATUS, repadmin.exe et d’autres outils pour résoudre les problèmes d’un environnement de cinq
dc à trois domaines. Les erreurs de réplication AD rencontrées dans l’atelier sont les suivantes : -
2146893022, 1256, 1908, 8453 et 8606. »
Causes des objets en attente
Cause 1 : le contrôleur de domaine source envoie des mises à jour aux objets qui ont déjà été récupérés par le garbage collection
sur le contrôleur de domaine de destination, car le contrôleur de domaine source était hors connexion ou a échoué à la réplication
pour le nombre de jours écouléS TSL
Le CONTOSO.COM domaine contient deux contrôleurs de domaine dans le même domaine. Durée de vie de
Tombstone = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC2 subit une
défaillance de la carte mère. En attendant, DC1 effectue quotidiennement des suppressions d’origine pour les
groupes de sécurité obsolètes au cours des 90 prochains jours. Une fois hors connexion pendant 90 jours, DC2
reçoit une carte mère de remplacement, s’alimente, puis reçoit une modification DACL ou SACL sur tous les
comptes d’utilisateur avant qu’il réplique les connaissances de suppressions d’origine de DC1. DC1 enregistre
les erreurs 8606 pour les groupes de sécurité de mises à jour qui sont purgés sur DC1 pendant les 30 premiers
jours où DC2 était hors connexion.
Cause 2 : le dc source envoie des mises à jour aux objets à la fin de l’expiration du protocole TSL qui ont déjà été récupérés par le
garbage collection par un DC de destination en mode strict
Tombstone = 60 jours. La réplication stricte est activée sur les deux contrôleurs de domaine. DC1 et DC2
répliquent toutes les 24 heures. DC1 part-supprime tous les jours. DC1 est mis à niveau sur place. Cela marque
le nouvel attribut sur tous les objets dans la configuration et les partitions de domaine accessibles en writable.
Cela inclut les objets qui se trouve actuellement dans le conteneur d’objets supprimés. Certains d’entre eux ont
été supprimés il y a 60 jours et sont maintenant à la fin de l’expiration de tombstone. DC2 récupère certains
objets par le garbage collection qui ont été supprimés TSL il y a quelques jours avant l’ouverture de la
planification de réplication avec DC2. L’erreur 8606 est consignée jusqu’à ce que DC1 récupère les objets
bloquants par le garbage collection.
Toute mise à jour de l’ensemble d’attributs partiels peut provoquer des objets temporairement en attente qui
s’effacent eux-mêmes après que les contrôleurs de domaine source collectent la garbage-collect des objets
supprimés à la mise à jour de TSL (par exemple, l’ajout du premier contrôleur de domaine W2K8 R2 à une forêt
existante).
Cause 3 : un saut de temps sur un contrôleur de domaine de destination accélère prématurément le tri des objets supprimés sur
un contrôleur de domaine de destination
répliquent toutes les 24 heures. DC1 part des suppressions quotidiennes. La source de temps de référence
utilisée par DC1 (mais pas DC2) est mise à jour jusqu’à l’année civile 2039. Ainsi, DC2 utilise également une
heure système dans CY2039. Dc1 supprime ainsi prématurément les objets qui sont supprimés aujourd’hui de
son conteneur d’objets supprimés. En attendant, DC2 a apporté des modifications aux attributs des utilisateurs,
des ordinateurs et des groupes qui sont actifs sur DC2, mais supprimés et maintenant prématurément la
garbage collecté sur DC1. DC1 enregistre l’erreur 8606 lors de la prochaine réplication entrante des
modifications pour les objets supprimés prématurés.
Cause 4 : un objet est réanimé à la fin de l’expiration de TSL
répliquent toutes les 24 heures. DC1 part des suppressions quotidiennes. Une ou plusieurs utilisateurs,
ordinateurs et groupes sont supprimés accidentellement. Une sauvegarde de l’état du système qui a été réalisée
à la cusp de TSL dans le passé est restaurée sur DC2. La sauvegarde contient des objets qui sont en direct sur
DC2, mais qui sont déjà supprimés et récupérés par le garbage collection sur DC1.
Cause 5 : une bulle USN déclenche la journalisation du 8606
Dites que vous créez un objet dans une bulle USN de telle sorte qu’il ne soit pas répliqué sortant, car le
contrôleur de domaine de destination « pense » qu’il possède l’objet en raison de la bulle. À présent, une fois
que la bulle se ferme et que les modifications recommencent à se répliquer, une modification est créée pour cet
objet sur le contrôleur de domaine source et s’affiche comme un objet en attente pour le contrôleur de domaine
de destination. Le contrôleur de destination enregistre l’événement 8606.
Conditions requises pour la connaissance de réplication de bout en bout des suppressions d’origine
Les contrôleurs de domaine Active Directory prennent en charge la réplication multi-maîtres où n’importe quel
contrôleur de domaine (qui contient une partition accessible en création) peut provenir d’une création, d’une
modification ou d’une suppression d’un objet ou d’un attribut (valeur). La connaissance des suppressions
d’objet/d’attribut est persistante par le contrôleur de domaine d’origine et tout contrôleur de domaine qui a une
connaissance répliquée entrante d’une suppression d’origine pendant un nombre de jours TSL. (Consultez les
articles de la Base de connaissances Microsoft 216996 et 910205)
Active Directory nécessite une réplication de bout en bout de tous les titulaires de partition pour répliquer de
manière transitive toutes les suppressions d’origine pour toutes les partitions d’annuaire sur tous les titulaires
de partition. L’échec de la réplication entrante d’une partition d’annuaire en un nombre de jours TSL de
déploiement entraîne l’attente d’objets. Un objet en attente est un objet qui a été intentionnellement supprimé
par au moins un contrôleur de domaine, mais qui existe de manière incorrecte sur les contrôleurs de domaine
de destination qui n’ont pas répliqué la connaissance passagère de toutes les suppressions uniques.
Utiliser Ntdsutil pour rechercher et nettoyer les
identificateurs de sécurité en double
Cet article explique comment utiliser Ntdsutil pour rechercher et nettoyer les identificateurs de sécurité en
double.
Résumé
Cet article explique comment vérifier et nettoyer ou supprimer des identificateurs de sécurité en double (SID)
dans la base de données SAM. Chaque compte de sécurité, tel qu’un utilisateur, un groupe ou un ordinateur,
possède un SID unique. Les autorisations d’accès sont accordées ou refusées aux SID pour des ressources, telles
que des fichiers, des dossiers, des imprimantes, des boîtes aux lettres Microsoft Exchange, des bases de données
Microsoft SQL Server, des objets stockés dans Active Directory et toutes les données protégées par le modèle de
sécurité Windows Server.
Un SID contient des informations d’en-tête et un ensemble d’identificateurs relatifs qui identifient le domaine et
le compte de sécurité. Dans un domaine, chaque contrôleur de domaine peut créer des comptes et émettre un
SID unique pour chaque compte. Chaque contrôleur de domaine conserve un pool d’ID relatifs qui est utilisé
pour créer des SID. Une fois que 80 % du pool d’ID relatif est consommé, le contrôleur de domaine demande un
nouveau pool d’identificateurs relatifs au contrôleur d’opérations d’ID relatif. Assurez-vous que le même pool
d’ID relatifs n’est jamais alloué à différents contrôleurs de domaine et empêche l’allocation de SID en double.
Toutefois, comme il est possible (mais rare) d’allouer un pool d’ID relatif en double, vous devez identifier les
comptes qui ont reçu des SID en double pour empêcher l’application d’une sécurité incorrecte.
Des pools d’ID relatifs en double peuvent se produire si l’administrateur saisit le rôle principal d’ID relatif (RID
master), alors que le master RID d’origine est opérationnel mais temporairement déconnecté du réseau. En
pratique, le rôle principal RID est supposé par un seul contrôleur de domaine après un cycle de réplication.
Toutefois, avant la résolution de la propriété du rôle, deux contrôleurs de domaine différents peuvent chacun
demander un nouveau pool d’ID relatif et se faire attribuer le même pool d’ID relatif.
Démarrer Ntdsutil
Pour démarrer Ntdsutil, suivez les étapes suivantes :
1. Sélectionnez Démarrer > Exécuter .
2. Dans la zone Ouvrir, tapez ntdsutil, puis appuyez sur Entrée. Pour accéder à l’aide à tout moment, tapez ?
à l’invite de commandes, puis appuyez sur Entrée.
Rechercher un SID en double
Pour rechercher un SID en double, suivez les étapes suivantes :
1. À l’invite de commandes Ntdsutil, tapez gestion des comptes de sécurité, puis appuyez sur Entrée.
2. Pour vous connecter au serveur qui stocke votre base de données SAM (Security Account Maintenance),
tapez à l’invite de commandes SAM, puis connect to serverDNSNameOfServer appuyez sur Entrée.
3. À l’invite de commandes SAM, tapez vérifier le sid dupliqué, puis appuyez sur Entrée.
NOTE
Un affichage des doublons s’affiche.
Nettoyer un SID en double

1. À l’invite de commandes Ntdsutil, tapez gestion des comptes de sécurité, puis appuyez sur Entrée.
2. Connecter sur le serveur qui stocke votre base de données SAM (Security Account Maintenance). À
l’invite de commandes SAM, tapez « connect to serverDNSNameOfServer » et appuyez sur Entrée.
3. À l’invite de commandes SAM, tapez double sid de nettoyage, puis appuyez sur Entrée.
NOTE
Ntdsutil confirme la suppression du doublon.
4. À l’invite de commandes SAM, tapez q, puis appuyez sur Entrée.

5. Une fois que vous avez terminé d’utiliser Ntdsutil, tapez q, puis appuyez sur Entrée.
L’ID d’événement 84 se produit dans services AD
RMS (Active Directory Rights Management
Services) (AD RMS) dans Windows Server
Cet article fournit de l’aide pour résoudre un problème dans lequel l’ID d’événement 84 est connecté à services
AD RMS (Active Directory Rights Management Services) (AD RMS) dans Windows Server.
Symptômes
Sur un Windows serveur sur services AD RMS (Active Directory Rights Management Services) (AD RMS), vous
recevez l’événement suivant :
Nom du journal : Application

Source : services AD RMS (Active Directory Rights Management Services)
Date : Date/Heure
Catégorie de tâche : certification
Niveau : Erreur
Utilisateur : N/A
Ordinateur : ipc01.treyresearch.net
Description :
Ce services AD RMS (Active Directory Rights Management Services) cluster (AD RMS) ne peut pas effectuer
d’opération sur l’une des bases de données AD RMS. Assurez-vous que toutes les bases de données AD RMS
fonctionnent correctement sur le réseau et que le compte de service AD RMS dispose des autorisations de
lecture et d’écriture sur les bases de données.
Référence des paramètres
Contexte : Pipeline[ComponentBase.LogResults]
RequestId:RequestID
HelpLink.ProdName : Microsoft SQL Server
HelpLink.ProdVer : 10.50.4000
HelpLink.EvtSrc : MSSQLServer
HelpLink.EvtID: 8115
HelpLink.BaseHelpUrl : https://go.microsoft.com/fwlink
HelpLink.LinkId: 20476
SqlError-1.Class : 0
SqlError-0.State: 1
SqlError-1.Server : sql01.treyresearch.net ,1441
SqlError-0.Message : erreur de dépassement arithmétique conver tissant IDENTITY en type de
données smallint.
SqlError-1.Number: 3606
SqlError-1.Message : dépassement arithmétique.
SqlError-1.State: 0
Microsoft.RightsManagementServices.LowSeveritySqlException
Message : l’Moteur de base de données a lancé cette exception en réponse à une erreur qui peut être
corrigée par l’utilisateur, telle qu’une entité ou un objet de base de données manquant, une incohérence
possible des données, un blocage de transaction, des problèmes de paramètres de sécurité ou une erreur de
syntaxe de commande SQL. Pour plus d’informations, consultez les détails de SqlError.
HelpLink.ProdName : Microsoft SQL Server
HelpLink.ProdVer : 10.50.4000
HelpLink.EvtSrc : MSSQLServer
HelpLink.EvtID: 8115
HelpLink.BaseHelpUrl : https://go.microsoft.com/fwlink
HelpLink.LinkId: 20476
Contexte : ComponentBase.LogResults
SqlError-0.State: 1
SqlError-0.Message : erreur de dépassement arithmétique convertissant IDENTITY en type de données
smallint.
SqlError-1.Message : dépassement arithmétique.
SqlError-1.State: 0
+ System.Data.SqlClient.SqlException
+ Message : erreur de dépassement arithmétique convertissant l’identité en type de données smallint.
Dépassement arithmétique.
+HelpLink.ProdName : Microsoft SQL Server
+ HelpLink.ProdVer : 10.50.4000
+ HelpLink.EvtSrc : MSSQLServer
+ HelpLink.EvtID: 8115
+ HelpLink.BaseHelpUrl : https://go.microsoft.com/fwlink
+ HelpLink.LinkId: 20476
+ Contexte : ComponentBase.LogResults
Cause
Ce problème se produit car le processus de journalisation AD RMS ne journalisation pas un événement dans la
base de données de journalisation.
Il existe deux tables dans la base de données de journalisation qui font référence à une valeur UserAgentId. Les
deux dbo. UserAgent et le dbo. Les tables ServiceRequest ont une colonne UserAgentId. Ces colonnes sont
toutes deux de type de données smallint. Dès que la valeur UserAgentId dépasse la valeur maximale (~32 767),
la base de données de journalisation ne peut pas être mise à jour. Lorsqu’une transaction ne se connecte pas,
RMS retourne la demande et envoie une erreur.
Lorsque vous demandez une licence à AD RMS, les clients passent des chaînes d’agent avec les informations de
base sur l’application à l’aide de la demande. Le dbo. La table UserAgent stocke uniquement les chaînes d’agent
uniques.
À l’origine, les clients MSIPC viennent de passer des versions du système d’exploitation, de l’application, du
MSIPC et de l’architecture. La table dans laquelle les chaînes sont stockées conserve uniquement les entrées
uniques. Il ne doit pas y avoir beaucoup de chaînes uniques dans la base d’utilisateurs.
MSIPC;version=1.0.2191.0;AppName=EXCEL.EXE;AppVersion=16.0.7369.2127;AppArch=x86;OSName=Windows;OSVersion=10
.0.10586;OSArch=amd64
À un moment donné, le client MSIPC a commencé à inclure l’ID de processus (PID) à cette chaîne d’agent
utilisateur. Cela rend chaque chaîne unique.
MSIPC;version=1.0.2456.0;AppName=EXCEL.EXE;AppVersion=15.0.4919.1000;AppArch=x86;PID=13660;OSName=Windows;OS
Version=6.1.7601;OSA
Par conséquent, le tableau qui ne doit pas avoir beaucoup de chaînes uniques à stocker a maintenant plusieurs
milliers.
Pour contourner ce problème, désactivez la journalisation sur le cluster AD RMS :
Résolution
Pour résoudre ce problème, modifiez le type de données des colonnes de smallint à int (integer). Pour cela,
NOTE
La modification d’une base de données de journalisation de grande taille peut prendre beaucoup de temps et entraîner
des SQL performances. Par conséquent, nous vous recommandons de SQL la DB de production à partir de l’instance SQL
production et de la restaurer sur un emplacement de production SQL production. Après cela, vous pouvez effectuer
l’altération de la base de données sur l’emplacement SQL production, puis remplacer la base de données de production.
1. Back up the AD RMS logging database.

2. Collectez les SQL données.
Nom de la base de données de journalisation AD RMS
Nom de la clé Dbo.UserAgent
3. Générez le script (voir l’exemple suivant).

Exemple de script
NOTE
Modifiez le nom de la base de données et la valeur de clé de table UserAgent pour refléter l’environnement cible.
/*******************************************************************************
THIS TOOL AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
*******************************************************************************/
use [DRMS_Logging_ipc_treyresearch_net_443]
go
ALTER TABLE [dbo].[ServiceRequest] drop CONSTRAINT [FK_CLIENTINFOID_ServiceRequest_UserAgent]

GO
Alter table [dbo].[ServiceRequest] alter COLUMN [UserAgentId] int

GO
ALTER TABLE [dbo].[UserAgent] DROP CONSTRAINT [PK__UserAgen__UserAgentId]

GO
Alter table [dbo].[UserAgent] alter COLUMN [UserAgentId] int

GO
Alter table [dbo].[UserAgent] ADD PRIMARY KEY (UserAgentId)

GO
ALTER TABLE [dbo].[ServiceRequest] WITH CHECK ADD CONSTRAINT [FK_CLIENTINFOID_ServiceRequest_UserAgent]

FOREIGN KEY([UserAgentId]) REFERENCES [dbo].[UserAgent] ([UserAgentId])
GO
ALTER TABLE [dbo].[ServiceRequest] CHECK CONSTRAINT [FK_CLIENTINFOID_ServiceRequest_UserAgent]

GO
Vous ne pouvez pas promouvoir un contrôleur de
domaine Windows Server comme serveur de
catalogue global
Cet article fournit des solutions à un problème dans lequel vous ne pouvez pas promouvoir un contrôleur de
domaine Windows Server comme serveur de catalogue global.
Symptômes
Vous ne pouvez pas promouvoir un contrôleur de domaine Microsoft Windows Server comme serveur de
catalogue global. Après avoir essayé d’attribuer le rôle de serveur de catalogue global au contrôleur de domaine
Windows Server en cliquant sur la case à cocher Catalogue global, le contrôleur de domaine n’est pas promu
comme serveur de catalogue global. Les événements d’informations semblables aux suivants peuvent être
consignés à plusieurs reprises dans le journal des services d’annuaire.
Événement 1559
Événement 1578
Événement 1801
Si vous activez la journalisation des diagnostics pour le Contrôle de cohérence des connaissances (KCC) au
niveau 1, l’événement suivant est journalisé.
Symptômes supplémentaires
Lorsque vous tapez sur la ligne de commande du contrôleur de domaine Windows Server, il se peut qu’un ou
plusieurs domaines repadmin /showrepl n’apparaissent pas.
Lorsque vous essayez d’ajouter une connexion à l’aide du contexte d’attribution de noms du domaine manquant,
vous pouvez recevoir le message d’erreur suivant :
Numéro d’erreur : 8440.

Le contexte d’attribution de noms spécifié pour cette opération de réplication n’est pas valide.
Cause
Ce problème se produit lorsque la mise à jour d’attribution de noms de domaine pour le domaine n’a pas atteint
le contrôleur de domaine qui rencontre le problème. Ou bien, la mise à jour d’attribution de noms de domaine
pour un domaine qui vient d’être promu n’a peut-être atteint aucun contrôleur de domaine en dehors de ce
domaine.
Vous pouvez vérifier si la mise à jour d’attribution de noms de domaine a atteint tous les contrôleurs de
domaine en modifiant l’attribut dumpDatabase sur le contrôleur de domaine qui rencontre le problème. Pour
plus d’informations, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances
Microsoft :
315098 comment utiliser la fonctionnalité de dbdump en ligne dans Ldp.exe
Dans le fichier de vidage que vous créez, recherchez l’enregistrement de référence croisée pour le domaine. Cet
enregistrement de référence croisée possède une classe d’objet 196619. Recherchez l’enregistrement vers
196619 la classe d’objet. Ensuite, assurez-vous que la classe d’objet contenue dans l’enregistrement dispose d’un
GUID affecté.
Dans l’exemple suivant, l’objet 5070 fait référence à l’objet 5072. Toutefois, aucun GUID n’est affecté à l’objet
5072 :
5070 4111 1 1459 true 3 DOMAIN DOMAIN 5072 196619 - 6f73dba6-33e1-41e5-9330-c09a60a37942 4

objectclass: 196619, 65536
5071 2 2 - false <DateTime> - 1376281 com com - - - - -
5072 5071 5 - false <DateTime> - 1376281 domaine
Résolution
Méthode 1
Si un ou deux contrôleurs de domaine rencontrent le problème et que d’autres contrôleurs de domaine dans le
même domaine ne rencontrent pas le problème, vous devez rétrograder, puis promouvoir les contrôleurs de
domaine qui rencontrent le problème. Pour cela, procédez comme suit :
1. Connectez-vous au contrôleur de domaine Windows Server à l’aide d’un compte qui dispose des
autorisations d’administrateur de domaine.
2. Cliquez sur Démarrer , sur Exécuter , tapez dcpromo, puis cliquez sur OK .
3. Suivez les instructions de l’Assistant pour rétrograder le contrôleur de domaine.
4. Après avoir rétrogradé le contrôleur de domaine, redémarrez l’ordinateur Windows Server.
5. Cliquez sur Démarrer , sur Exécuter , tapez dcpromo, puis cliquez sur OK .
6. Suivez les instructions de l’Assistant pour promouvoir le contrôleur de Windows server.
Méthode 2
Vous devez reconstruire le domaine mentionné dans les descriptions d’événement si l’une des conditions
suivantes est vraie :
Aucun contrôleur de domaine dans le domaine n’a reçu la mise à jour.
Les contrôleurs de domaine qui résident en dehors du domaine signalé dans les messages d’événement
n’ont pas reçu la mise à jour.
L’événement 1119 peut être enregistré dans le journal des services d’annuaire sur le contrôleur de domaine. Cet
événement peut être enregistré après avoir attribué le rôle de serveur de catalogue global au contrôleur de
domaine, et après la réplication du compte et des informations de schéma sur le nouveau serveur de catalogue
global.
La description de l’événement indique que l’ordinateur est identifié comme serveur de catalogue global. Pour
vérifier que le maître d’attribution de noms de domaine est un serveur de catalogue global, suivez les étapes
suivantes :
2. Tapez nltest /dsgetdc : domain_name /server: ser ver_name, puis appuyez sur Entrée .
3. Vérifiez que l’indicateur GC est présent sur le serveur.
Par exemple, lorsque vous tapez la commande, vous recevez un message semblable à ce qui suit si l’indicateur
GC est présent :
DC : \ \ Server_Name
Adresse : \ \ Adresse IP
Guid dom : <GUID>
Nom du dom : Domain_name
Nom de la forêt : Domain_name.com
Nom de notre site : Default-First-Site-Name
Indicateurs : PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST CLOSE_SITE
La commande a été exécutée comme il se doit
Erreur lors de la tentative de création d’un espace
de noms DFS : l’espace de noms ne peut pas être
interrogé. Le serveur RPC n’est pas disponible
Cet article fournit une solution à une erreur qui se produit lorsque vous créez un espace de noms DFS.
Symptômes
Vous pouvez recevoir l’erreur suivante lors de la tentative de création d’un espace de noms DFS sur un
ordinateur Windows Server 2008 :
L’espace de noms ne peut pas être interrogé. Le serveur RPC n’est pas disponible.
Ce problème est généralement observé dans un environnement utilisant un serveur DNS tiers.
Cause
Cette erreur peut se produire lorsqu’aucun enregistrement DomainDNSName n’est enregistré pour le domaine.
Ces enregistrements sont mis à jour par le service Netlogon sur les contrôleurs de domaine. Ces
enregistrements sont les mêmes que les enregistrements A parents dans la zone de recherche avant du
domaine.
La documentation suivante indique que ces enregistrements ne sont pas obligatoires et sont utilisés
uniquement pour les clients DNS qui ne comprennent pas les enregistrements SRV :
Fonctionnement de la prise en charge DNS pour Active Directory.
DnsDomainName :
Permet à un client non SRV de localiser un contrôleur de domaine dans le domaine en cherchant un
enregistrement A. Un nom dans ce formulaire est renvoyé au client LDAP par le biais d’une référence LDAP. Un
client non SRV recherche le nom ; Un client SRV recherche l’enregistrement de ressource SRV approprié.
Dans un suivi réseau, vous verrez une recherche DNS pour l’enregistrement DomainDNSname A et le serveur
DNS répondra avec l’enregistrement SOA si ces enregistrements A n’existent pas.
Requête de recherche DNS :
Dns : QueryId = 0x887C, QUERY (requête Standard), Requête pour adatum.com type d’hôte Addr sur
Internet de classe
QRecord : adatum.com de type Host Addr sur Internet de classe
Réponse avec l’enregistrement SOA :
Dns : QueryId = 0x887C, QUERY (requête standard), Réponse - Réussite

QRecord : adatum.com de type Host Addr sur Internet de classe
AuthorityRecord : adatum.com type SOA sur la classe Internet : PrimaryNameServer : adadc1.adatum.com,
AuthoritativeMailbox : hostmaster.adatum.com
Résolution
Mettez à jour les enregistrements A sur le serveur DNS ou créez un fichier HOSTS sur l’ordinateur Windows
Server 2008 qui inclut le nom complet et les adresses IP du contrôleur de domaine.
Exemple de fichier HOSTS :
adatum.com 192.168.2.10
adatum.com 192.168.3.10
adatum.com 192.168.4.10
Vous pouvez être face à des problèmes lorsque
vous renommez des sites dans la forêt Active
Directory
Cet article décrit les problèmes que vous pouvez rencontres lorsque vous renommez des sites dans la forêt
Active Directory.
Lorsque vous renommez un site dans la forêt Active Directory, les événements suivants se produisent en
arrière-plan :
1. La modification du nom du site est répliquée dans le contexte d’attribution de noms de configuration (NC)
dans toute la forêt.
2. Lorsque le changement de nom de site est répliqué sur un contrôleur de domaine local, le service Net Logon
recherche sa table de mappage de sous-réseau à site. Par la suite, le service Net Logon informe les
ordinateurs clients du nouveau nom de site.
3. Le service Net Logon sur le contrôleur de domaine enregistre ensuite ses nouveaux enregistrements SRV
(Domain Name System) spécifiques au site auprès de son serveur DNS (Domain Name System) faisant
autorité.
4. Le serveur DNS écrit les nouveaux enregistrements de contrôleur de domaine dans la zone. Ces nouvelles
informations sont ensuite répliquées sur d’autres serveurs DNS en fonction de la planification de réplication
DNS ou Active Directory.
5. Les ordinateurs clients reçoivent le nouveau nom de site du contrôleur de domaine. Les ordinateurs clients
utilisent ensuite ce nouveau nom de site dans les requêtes DNS pour rechercher des contrôleurs de domaine.
6. Le service serveur de système de fichiers distribués (DFS) conserve les caches des mappages de client à site
et de serveur à site. Ces caches sont nommés « cache de site client » et « cache de site cible ». Ces caches
sont actualisé toutes les 12 heures, mais ils ne sont présents de manière fiable qu’après 24 heures.
En raison des différents intervalles de temps utilisés pour mettre à jour les informations relatives au site, vous
pouvez être aux premières difficultés suivantes :
Lorsque les ordinateurs clients sont informés du nouveau nom de site à l’étape 2, leur serveur DNS peut
ne pas encore avoir les nouvelles inscriptions d’enregistrement et retournera donc une erreur. Les
ordinateurs clients interrogent ensuite les enregistrements qui ne sont pas spécifiques au site. Les
contrôleurs de domaine renvoyés par cette requête peuvent uniquement avoir un lien réseau faible vers
l’ordinateur client. Par conséquent, l’ordinateur client subit des performances médiocres. L’effet de ce
problème dépend des suivants :
Retard de réplication des informations de site dans le nc de configuration
Délai d’obtention des nouveaux enregistrements DNS propagés à tous les serveurs DNS
Pour forcer le service Net Logon à inscrire immédiatement ses enregistrements DNS, vous pouvez
exécuter la commande à l’invite nltest /dsregdns de commandes.
NOTE
L’outil Nltest peut être obtenu à partir des outils de support de Microsoft Windows Server 2003.
Pour accélérer l’adoption de nouveaux sites en particulier pour l’accès au volume système
(SYSVOL), vous pouvez utiliser le serveur d’accès en tant que serveur DFS préféré.
Lorsque les ordinateurs clients recherchent des volumes DFS basés sur le domaine, les serveurs
d’espaces de noms DFS ou les contrôleurs de domaine examinent l’adresse IP des ordinateurs clients et
leurs informations de site local. Lorsque les serveurs d’espaces de noms DFS ou les contrôleurs de
domaine examinent l’adresse IP, ils peuvent déterminer le site où se trouver les ordinateurs clients. Vous
pouvez également effectuer ce mappage à partir du cache de site client. DFS peut exécuter une requête
pour le meilleur autre site à l’aide du mode de sélection de site Windows Server 2003 le plus proche. Le
serveur DFS examine ensuite le cache du site cible pour trouver les serveurs du site où se trouve
l’ordinateur client et les meilleurs sites suivants. En raison du délai de mise à jour des caches, le serveur
DFS risque de ne pas trouver les nouveaux noms de site dans le cache de sites cible. Le serveur DFS
renvoie ensuite une liste de serveurs mal classés à l’ordinateur client. Par conséquent, l’ordinateur client
peut contacter des serveurs lents pour les fichiers. Cela entraîne des performances médiocres.
Si les informations de site sont entièrement répliquées dans Active Directory et DNS, vous pouvez
redémarrer tous les serveurs d’espaces de noms DFS ou contrôleurs de domaine afin qu’ils obtiennent le
dernier mappage de serveur à site.
Pour plus d’informations sur DFS, visitez le site Web Microsoft suivant :
Système de fichiers distribués
L’ordre de recherche de la forêt Kerberos peut ne
pas fonctionner dans une confiance externe et l’ID
d’événement 17 est renvoyé
Cet article décrit une situation dans laquelle l’ordre de recherche de forêt Kerberos (KFSO) ne fonctionne pas
dans une confiance externe.
S’applique à : Windows Server 2008 R2 Service Pack 1, Windows 7 Service Pack 1
Symptômes
Dans Windows Server 2008 R2 et les versions ultérieures de Windows Server, les paramètres de stratégie de
groupe suivants peuvent être utilisés pour configurer l’oE KFSO :
Configuration de l’ordinateur \ Modèles d’administration \ Système \ Kerberos \ Utiliser l’ordre de
recherche de forêt
Configuration de l’ordinateur \ Modèles d’administration \ Système \ KDC \ Utiliser l’ordre de
recherche de forêt
Une fois ces paramètres configurés, l’authentification Kerberos peut fonctionner dans des confiances externes
dans un environnement de forêt à domaine unique. Toutefois, il peut échouer lorsque la forêt spécifiée contient
plusieurs domaines.
Dans ce cas, InitializeSecurityContext peut renvoyer « SEC_E_TARGET_UNKNOWN ». En outre, l’événement
suivant peut être journalisé.
Cause
La fonctionnalité d’authentification KFSO permet d’autoriser la résolution de nom principal de service (SPN) de
nom d’hôte court dans un environnement d’authentification de forêt au lieu d’offrir la prise en charge de
l’authentification Kerberos sur les trusts externes.
Si l’authentification Kerberos est requise, une confiance de forêt est nécessaire. Dans le cas d’une confiance
externe, vous devez modifier l’application pour utiliser les noms de serveur FQDN et les noms de service à trois
partie. Pour plus d’informations, voir Technologies for Federating Multiple Forests.
Lorsque des noms de domaine noms de domaine (FQDN) sont utilisés, l’objet d’trust de forêt peut proposer un
routage SPN en fonction du suffixe UPN/SPN fourni dans la demande afin que le Centre de distribution de clés
(KDC) connaisse le saut suivant dans la procédure de référence Kerberos.
Dans un environnement de confiance externe où l’oE KFS est configurée, le KDC ou le client Kerberos tente
d’ajouter le suffixe spécifié pour effectuer une recherche, puis il émettra une demande DsCrackNames sur la
forêt cible afin de résoudre le nom principal de service demandé. Toutefois, la demande DsCrackNames peut
essayer de se connecter à n’importe quel catalogue global dans la forêt cible. Si la demande contacte le
contrôleur de domaine dans le domaine approuvé directement, l’authentification Kerberos peut réussir. Si la
demande contacte un contrôleur de domaine dans un autre domaine, il se peut que l’authentification Kerberos
échoue.
Ce comportement est attendu, car l’authentification KFSO n’est pas conçue pour offrir la prise en charge de
l’authentification Kerberos sur des confiances externes. Pour utiliser une relation d’confiance Kerberos entre les
forêts, créez plutôt une relation d’confiance de forêt.
Comment optimiser l’emplacement d’un contrôleur
de domaine ou d’un catalogue global qui réside en
dehors du site d’un client
Cet article décrit les étapes à suivre pour optimiser l’emplacement d’un contrôleur de domaine ou d’un
catalogue global qui réside en dehors du site d’un client.
Résumé
Le mécanisme de localisation du contrôleur de domaine dans Windows 2000 préfère toujours un contrôleur de
domaine qui réside dans le site du client qui recherche un contrôleur de domaine. Cela est obtenu par un
contrôleur de domaine qui enregistre les enregistrements de ressource DNS SRV du localisateur de contrôleur
de domaine propre au site pour le site dans lequel réside le contrôleur de domaine.
En outre, un contrôleur de domaine peut enregistrer des enregistrements de ressource DNS SRV propres au site
pour tous les autres sites qui ne contiennent pas de contrôleur de domaine dans le même rôle que le site du
contrôleur de domaine le plus proche. Ces rôles incluent un rôle qui héberge le même domaine, ou qui est un
catalogue global). Ce mécanisme garantit que les clients localiseront le contrôleur de domaine le plus proche
dans les cas où aucun contrôleur de domaine ne se trouve sur le site du client.
Pour plus d’informations sur ce mécanisme, consultez le kit de ressources du serveur Windows 2000, «
Distributed Systems Guide », chapitre 3 : « Résolution de noms dans Active Directory ».
Dans le cas où tous les contrôleurs de domaine du même rôle (c’est-à-dire, qui hébergent le même domaine ou
qui sont des catalogues globaux) d’un site particulier deviennent indisponibles, les clients qui se trouvent dans
le même site sont mis à la disposition d’un autre contrôleur de domaine dans n’importe quel autre site sans
optimisation.
Les informations suivantes décrivent la configuration recommandée que vous devez utiliser pour optimiser
l’emplacement des contrôleurs de domaine ou des catalogues globaux lorsque tous les contrôleurs de
domaine/catalogues globaux qui servent un site particulier deviennent indisponibles. « Section I » décrit la
configuration des topologies de hub-and-spoke. « Section II » décrit la configuration d’autres topologies.
IMPORTANT
restaurer en cas de problème. Pour plus d'informations sur la procédure de sauvegarde et de restauration du Registre,
cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
Section I : Topologie « Hub-and-spoke »

Les recommandations de cette section sont basées sur l’hypothèse suivante dans la topologie « hub-and-spoke
»:
Il est préférable que si tous les contrôleurs de domaine et les catalogues globaux d’un site satellite deviennent
indisponibles, un client qui recherche un contrôleur de domaine ou un catalogue global dans ce site échoue vers
un contrôleur de domaine ou un catalogue global qui se trouve dans un concentrateur central et non dans un
autre site satellite. Cette solution convient aux topologies qui ont un site hub unique ou plusieurs concentrateurs
centraux pour s’adapter aux cas où il n’est pas pertinent de savoir quel site central un client satellite fait échouer.
Pour ce faire, les contrôleurs de domaine et les catalogues globaux des succursales ne doivent pas enregistrer
d’enregistrements DNS de localisation de contrôleurs de domaine génériques (non spécifiques au site). Ces
enregistrements sont enregistrés uniquement par les contrôleurs de domaine et les catalogues globaux dans le
hub central. Lorsque les clients ne peuvent pas localiser les contrôleurs de domaine et les catalogues globaux
qui servent leur site, ils tentent de localiser des contrôleurs de domaine ou des catalogues globaux à l’aide de
ces enregistrements DNS génériques (non spécifiques au site).
Les enregistrements suivants ne doivent pas être enregistrés par les contrôleurs de domaine ou les catalogues
globaux dans les sites satellites :
Windows de domaine basés sur Windows Server 2003
Windows contrôleurs de domaine basés sur 2000 avec service Pack 2 (SP2) ou ultérieur installé, ou avec le
correctif logiciel spécifié dans l’article de la Base de connaissances 267855
Pour configurer des contrôleurs de domaine ou des catalogues globaux pour ne pas enregistrer
d’enregistrements génériques
Windows 2000
3. Dans le menu Modifier , cliquez sur Ajouter une valeur, puis ajoutez la valeur de Registre suivante :
Nom de la valeur : DnsAvoidRegisterRecords
Définissez la valeur sur la liste des mnémoniques délimitées par des entrées spécifiées dans la section «
Tables de référence ».
4. Fermez l’Éditeur du Registre.
Windows Server 2003
Pour configurer les contrôleurs de domaine basés sur Windows Server 2003, utilisez la stratégie de groupe de
groupe « DNS de localisation DC non enregistrés par les DCs ». Pour ce faire, spécifiez la liste des mnémoniques
délimités par des espaces spécifiés dans la section « Tables de référence ».
Tableaux de référence
Les tableaux suivants contiennent des mnémoniques, des types et des noms de propriétaire des
enregistrements DNS du localisateur de contrôleur de domaine qui ne doivent pas être enregistrés par les
contrôleurs de domaine satellites et les catalogues globaux pour optimiser l’emplacement du contrôleur de
domaine.
Enregistrements spécifiques au contrôleur de domaine
DcByGuid SRV _ldap._tcp.<DomainGuid>.


<DnsDomainName>
<DnsDomainName>
Enregistrements spécifiques au catalogue global
<DnsForestName>
Pour obtenir la liste complète des enregistrements DNS du localisateur de contrôleur de domaine, consultez le
kit de ressources du serveur Windows 2000, « Guide des systèmes distribués », chapitre 3 : « Résolution de
noms dans Active Directory ». Pour obtenir la liste complète des enregistrements DNS du localisateur de
contrôleur de domaine, reportez-vous à l’article de la KB Q267855 référencé dans cet article.
Section II : Autres topologies
Si le passage aux concentrateurs centraux lorsque les contrôleurs de domaine locaux et les catalogues globaux
deviennent indisponibles ne répond pas à vos besoins, vous pouvez utiliser la configuration suivante.
Si les clients (tels que les serveurs qui exécutent les serveurs Microsoft Exchange) dans le site A échouent vers
les contrôleurs de domaine et les catalogues globaux du site B, un administrateur peut configurer tout ou partie
des contrôleurs de domaine et des catalogues globaux dans le site B pour enregistrer les enregistrements
spécifiques au site A lorsque les contrôleurs de domaine et les catalogues globaux du site A deviennent
indisponibles. Pour vous assurer que les contrôleurs de domaine et les catalogues globaux du site B sont choisis
par les clients du site A uniquement si les contrôleurs de domaine et les catalogues globaux du site A ne sont
pas disponibles, les contrôleurs de domaine et les catalogues globaux du site B qui couvrent le site A doivent
inscrire les enregistrements SRV qui contiennent une priorité SRV inférieure (valeur absolue supérieure).
NOTE
Le paramètre de priorité est appliqué à tous les enregistrements SRV enregistrés par un contrôleur de domaine. Par
conséquent, l’administrateur doit être prudent lors de la définition d’une priorité inférieure à utiliser par un contrôleur de
domaine, car le contrôleur de domaine enregistre une priorité inférieure pour les enregistrements spécifiques au site, y
compris pour son propre site.
Pour configurer un contrôleur de domaine afin d’inscrire des enregistrements spécifiques à un site pour un
autre site
Windows 2000
Nom de la valeur : SiteCoverage
Définissez la valeur sur la liste des noms de sites délimités par des espaces pour lesquels le contrôleur de
domaine doit s’inscrire.
Windows Server 2003
Pour configurer les contrôleurs de domaine basés sur Windows Server 2003, utilisez la stratégie de groupe «
Sites couverts par le localisateur de contrôleur de domaine DNS SRV Records ». Pour ce faire, spécifiez la liste
des noms de sites délimités par des espaces pour lesquels le contrôleur de domaine doit s’inscrire.
Pour configurer un catalogue global afin d’inscrire des enregistrements spécifiques à un site pour un autre
site
Windows 2000
Nom de la valeur : GcSiteCoverage
Définissez la valeur sur la liste des noms de sites délimités par des espaces pour lesquels le catalogue
global doit s’inscrire.
Windows Server 2003
Utilisez la stratégie de groupe « Sites couverts par le localisateur de catalogue global DNS SRV Records » Net
Logon service en spécifiant la liste des noms de sites délimités par un retour chariot pour lesquels le catalogue
global doit s’inscrire.
Pour configurer un contrôleur de domaine afin d’inscrire des enregistrements SRV avec une priorité
particulière
Windows 2000
Nom de la valeur : LdapSrvPriority
Définissez la valeur sur la valeur souhaitée de la priorité. Quitter
Windows Server 2003
Pour configurer les contrôleurs de domaine basés sur Windows Server 2003, utilisez la stratégie de groupe «
Priority Set in the domain controller locator DNS SRV Records » (Enregistrement SRV DNS).
Résoudre les problèmes liés à la promotion d’un
contrôleur de domaine vers un serveur de
catalogue global
Cet article traite d’un problème de promotion d’un contrôleur de domaine vers un serveur de catalogue global.
Résumé
Cet article traite des sujets suivants :
Messages d’événement enregistrés dans le journal des services d’annuaire pour Windows Server
Causes possibles de l’échec de la promotion de catalogue global
Méthodes pour déterminer la cause de l’échec de la promotion de catalogue global
Méthodes de résolution de l’échec de la promotion de catalogue global
Symptômes
Lorsque vous essayez de promouvoir un contrôleur de domaine en serveur de catalogue global, il se peut que le
contrôleur de domaine ne s’annonce pas en tant que catalogue global. Cela est vrai si vous faites la promotion
du contrôleur de domaine par programme ou en cliquant pour sélectionner l’option Catalogue global. Lorsque
ce problème se produit, les messages d’événement sont enregistrés dans le journal des services d’annuaire.
En outre, la sortie peut montrer que le contrôleur de domaine n’a pas réussi le test de publicité et qu’il ne fait
pas de publicité pour le catalogue global. Cette sortie se produit lorsqu’un contrôleur de domaine enregistre l’ID
d’événement 1578 et lorsque vous exécutez une vérification de diagnostic du contrôleur de domaine
(Dcdiag.exe) sur ce contrôleur de domaine.
NOTE
Pour exécuter une vérification de diagnostic de contrôleur de domaine, exécutez les procédures suivantes :
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd, puis cliquez sur OK.
2. À l’invite de commandes, dcdiag /v /f: logfile.txt tapez, puis appuyez sur Entrée.
Les messages d’événement suivants sont consignés dans le journal des services d’annuaire lorsque ce problème
se produit.
Si vous activez la journalisation des diagnostics pour le Contrôle de cohérence des connaissances (KCC)
au niveau 1, l’événement suivant est journalisé.
Cause
Un catalogue global doit répliquer les copies entrantes de tous les objets de toutes les partitions de domaine de
la forêt pour que le catalogue global puisse annoncer le rôle de catalogue global.
Lorsqu’un contrôleur de domaine est sélectionné pour héberger le catalogue global, le KCC sur le contrôleur de
domaine promu utilise sa discrétion pour créer des objets de connexion à partir des contrôleurs de domaine
source qui hébergent les partitions requises. Ces contrôleurs de domaine source peuvent être constitués de
catalogues globaux existants dans la forêt ou de contrôleurs de domaine qui hébergent des copies accessibles
en ligne de chaque partition de domaine qui réside dans sa forêt. Le contenu de chaque partition de domaine
est ensuite répliqué à partir des contrôleurs de domaine source désignés par le KCC. Le contenu est répliqué
dans le catalogue global nouvellement promu sur les liens de connexion existants ou nouvellement créés.
La promotion de catalogue global peut échouer si l’une des conditions suivantes est vraie :
1. La partition de configuration sur un ou plusieurs contrôleurs de domaine contient un objet de référence
croisée à un domaine obsolète ou orphelin, mais aucun contrôleur de domaine pour ce domaine ne se
trouve dans la forêt.
2. Les métadonnées d’un contrôleur de domaine source désigné par le KCC se trouvent dans la partition de
configuration d’un ou plusieurs contrôleurs de domaine, mais ne représentent pas un contrôleur de
domaine actuellement présent dans la forêt.
3. Le contrôleur de domaine source sélectionné par le KCC sur le catalogue global promu est hors
connexion.
4. Le contrôleur de domaine source sélectionné par le KCC sur le catalogue global promu est inaccessible
sur le réseau. Ce contrôleur de domaine est inaccessible car il n’y a pas de connectivité réseau ou de
connectivité réseau partielle. Voici quelques exemples de problèmes de connectivité réseau :
Ports bloqués
Adresses IP filtrées
Réseaux qui ne sont pas entièrement acheminés, mais qui ont l’option de liens de site à tous les ponts
activée
5. Les catalogues globaux de domaine source sont contraints d’agir en tant que têtes de pont, car les
contrôleurs de domaine non globaux ont été sélectionnés à tort comme têtes de pont préférées par les
administrateurs.
6. Le catalogue global promu ne peut pas créer de lien de connexion à partir du contrôleur de domaine
source sélectionné en raison de l’état d’erreur consigné dans l’un des événements répertoriés dans la
section Résumé.
Un domaine orphelin empêche le contrôleur de domaine de terminer la réplication. Le contrôleur de domaine
ne peut pas s’annoncer en tant que serveur de catalogue global tant que la réplication n’est pas terminée.
Plusieurs problèmes peuvent conduire à un domaine orphelin :
1. Active Directory a été supprimé de tous les contrôleurs de domaine d’un domaine, mais l’objet de
référence croisée de partition de domaine reste.
2. Active Directory a été supprimé d’un contrôleur de domaine et la partition d’annuaire du contrôleur de
domaine a été supprimée. Le contrôleur de domaine a ensuite été re-créé avant la fin de la réplication.
Ces événements provoquaient des fantômes insérants référencés de manière incorrecte par un objet de
référence croisée.
3. La mise à jour d’attribution de noms de domaine pour le domaine n’a pas atteint le contrôleur de
domaine qui rencontre le problème. Ou bien, la mise à jour d’attribution de noms de domaine pour un
domaine qui vient d’être promu n’a peut-être atteint aucun contrôleur de domaine en dehors de ce
domaine. Ce problème serait temporaire.
Résolution
WARNING
Vous ne devez pas activer un niveau d’occupation réduit pour accélérer artificiellement la promotion de catalogue global.
Nous vous recommandons vivement de résoudre d’abord le problème de réplication du service d’annuaire afin que le
catalogue global soit publié automatiquement.
Pour résoudre ce problème, identifiez d’abord la cause première du problème de réplication, puis résolvez ce
problème. Déterminez si le problème de réplication est dû à l’une des conditions suivantes :
Un délai de réplication
Un domaine orphelin situé dans l’environnement de forêt
Incapacité à créer le lien de connexion
Incapacité à répliquer sur le contrat de connexion
Si un ID d’événement KCC NTD 1265 est enregistré dans le journal du service d’annuaire, utilisez cet événement
pour déterminer la cause de l’échec de réplication pour la même partition de domaine. Assurez-vous que la
connectivité réseau est bonne et qu’aucun port réseau requis n’est bloqué. Les ports réseau requis sont, par
exemple, TCP 135 et les ports éphémères utilisés par RPC. Affichez les enregistrements DNS pour vous assurer
que les enregistrements Hôte et SRV enregistrés sont tous correctement enregistrés. S’il existe des
enregistrements incorrects, vous devez les effacer et les enregistrer.
Supprimez toutes les métadonnées obsolètes pour les contrôleurs de domaine et les domaines de la forêt
répertoriés dans les ID d’événement appropriés. Vous devez le faire pour vous assurer que la réplication ne
échoue pas en raison d’un contrôleur de domaine ou d’un domaine inexistant. Pour plus d’informations sur la
suppression des métadonnées Active Directory, consultez l’article suivant :
Nettoyer les métadonnées du serveur du contrôleur de domaine Active Directory
Après avoir vérifié que la réplication entre les contrôleurs de domaine fonctionne correctement, déterminez s’il
existe un objet de domaine orphelin. Vous pouvez utiliser l’utilitaire Ntdsutil.exe pour effacer l’objet domaine
orphelin. S’il existe un objet contrôleur de domaine orphelin pour ce domaine, vous devez également supprimer
l’objet contrôleur de domaine. Pour plus d’informations sur la suppression d’un domaine orphelin, consultez
l’article suivant :
Comment supprimer des domaines orphelins d’Active Directory
Pour plus d’informations sur la suppression d’objets contrôleur de domaine orphelins, consultez l’article suivant
:
Nettoyer les métadonnées du serveur du contrôleur de domaine Active Directory
Une fois que vous avez promu le contrôleur de domaine en serveur de catalogue global, les partitions de
domaine dans la forêt sont répliquées sur le nouveau serveur de catalogue global. Lorsque toutes les partitions
ont été répliquées sur le nouveau serveur de catalogue global, l’ID d’événement 1119 est enregistré dans le
journal des services d’annuaire sur le contrôleur de domaine. La description de l’événement indique que
l’ordinateur se fait désormais une publicité en tant que serveur de catalogue global.
Pour vérifier que le contrôleur de domaine est un serveur de catalogue global, suivez les étapes suivantes :
2. nltest /dsgetdc: Domain_name /server: Server_Name Tapez, puis appuyez sur Entrée.
3. Vérifiez que le serveur affiche l’indicateur « GC » (catalogue global). Par exemple, lorsque vous tapez la
commande à l’étape 2, vous recevez un message semblable à ce qui suit si l’indicateur GC est présent :
DC : \\<ServerName>
Adresse : \\<IPAddress>
Guid dom : <GUID>
Nom du dom : <DomainName>
Nom de la forêt : <DomainName> .com
Nom de notre site : Default-First-Site-Name
Indicateurs : PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST CLOSE_SITE la commande
s’est correctement terminée
NOTE
Nltest est un outil en ligne de commande intégré à Windows Server. Pour plus d’informations, voir Nltest.
Pour plus d’informations, consultez les articles suivants :

Vous ne pouvez pas promouvoir un contrôleur de domaine Windows Server comme serveur de
catalogue global
Comment supprimer des domaines orphelins d’Active Directory
Le message d’erreur « Non-mise en schéma » se
produit lorsque vous essayez d’exécuter l’Assistant
Installation d’Active Directory (Dcpromo.exe)
Cet article fournit la résolution de l’erreur « insaltérable schéma » lorsque vous essayez d’exécuter l’Assistant
Installation d’Active Directory (Dcpromo.exe).
S’applique à : Windows Serveurs 2012 R2
Symptômes
Lorsque vous exécutez l’Assistant Installation d’Active Directory (Dcpromo.exe) sur un ordinateur qui exécute
l’une des éditions de Microsoft Windows répertoriées dans la section « S’applique à », vous pouvez recevoir un
message d’erreur « Non-mise en réseau du schéma ».
Si vous exécutez Microsoft Windows Server 2003, vous pouvez recevoir le message d’erreur suivant :
Active Directory n’a pas pu répliquer le chemin d’accès DN de la partition d’annuaire pour la partition à
partir du nom d’ordinateur complet du contrôleur de domaine distant du contrôleur de domaine source.
L’opération de réplication a échoué en raison d’une inmatmatisation de schéma entre les serveurs impliqués.
Si vous exécutez Microsoft Windows 2000, vous pouvez recevoir le message d’erreur suivant :
Le service d’annuaire n’a pas réussi à répliquer le nom de la par tition à partir du nom du serveur distant.
L’opération de réplication a échoué en raison d’une inmatmatisation de schéma entre les serveurs impliqués.
Cause
Ce problème peut se produire si l’une des conditions suivantes est vraie :
Condition 1 : la copie du contrôleur de domaine source du service d’annuaire Active Directory contient des
attributs à valeurs multiples en double.
Condition 2 : un ou plusieurs attributs ou pages de la base de données du contrôleur de domaine source sont
endommagés.
Condition 3 : le contrôleur de domaine source possède dans sa base de données des attributs qui ne sont pas
couverts par le schéma actuel en raison de la suppression du schéma.
Résolution
Pour résoudre ce problème, utilisez l’une des deux méthodes suivantes. La méthode 1 traite les conditions 1 et 2.
La méthode 2 résout la condition 3.
Méthode 1 : Résolution des conditions 1 et 2
Le message d’erreur « Insématisation du schéma » est intéréssant. La cause première de l’erreur peut ne rien
avoir à voir avec la partition de schéma (CN) ou avec des objets qui y sont. Le problème réel peut être une
violation de contrainte de base de données, telle qu’un attribut à valeurs multiples avec des valeurs en double.
Pour résoudre ce problème et résoudre ce problème, suivez les étapes de cette procédure en six étapes.
Partie 1 : activer la journalisation des diagnostics
Activer la journalisation des diagnostics sur le contrôleur de domaine source. Pour cela, procédez comme suit.
IMPORTANT
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics
3. Dans la colonne Nom du volet droit, cliquez avec le bouton droit sur l’entrée de Registre 5 Événements
de réplication, puis cliquez sur Modifier.
4. Tapez 5, puis cliquez sur OK.
5. Répétez les étapes 3 et 4 pour les entrées de Registre suivantes :
7 Configuration interne
8 Accès à l’annuaire
24 Schéma DS
6. Dans le volet gauche, cliquez à nouveau sur la sous-clé de Registre suivante :
7. Dans le menu Fichier, cliquez sur Expor ter.

8. Dans la zone Enregistrer dans, ouvrez le dossier Bureau de l’administrateur sur l’ordinateur sur lequel
vous recevez le message d’erreur « Non-application du schéma ». Dans la zone Nom de fichier, tapez
Ntds_logging, puis cliquez sur OK .
NOTE
En règle générale, le dossier Bureau de l’administrateur est C : \ Documents et Paramètres Bureau de \ \
l’administrateur. Toutefois, la lettre du lecteur système peut varier. Pour trouver le lecteur système utilisé par votre
ordinateur, suivez les étapes suivantes :
a. Connectez-vous à l’ordinateur sur lequel vous recevez le message d’erreur « Insatiste de schéma ».
b. Cliquez sur Démarrer, cliquez sur Exécuter, tapez la commande, puis cliquez sur OK.
c. Tapez ensemble, puis appuyez sur Entrée.
La ligne de sortie qui commence par « SystemDrive= » vous montre la lettre de lecteur que votre
système utilise.
d. Tapez exit et appuyez sur Entrée.
Partie 2 : Forcer la réplication entrante d’Active Directory
Forcer l’ordinateur de destination à effectuer la réplication entrante d’Active Directory à partir d’un contrôleur de
domaine où la journalisation des diagnostics NTDS a été activée. S’il existe plusieurs contrôleurs de domaine
source, assurez-vous que la réplication se produit à partir d’un contrôleur de domaine source où la
journalisation des diagnostics a été activée. Pour ce faire, utilisez l’une des méthodes suivantes :
Augmentez la journalisation sur tous les contrôleurs de domaine source possibles en suivant les étapes 1
à 5 de la section « Partie 1 : activer la journalisation
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics des diagnostics ».
Arrêtez le service Net Logon sur tous les contrôleurs de domaine source possibles à l’exception du
contrôleur de domaine source qui est référencé dans l’erreur « insématisation du schéma » où la
journalisation a été augmentée. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis cliquez
sur Ser vices.
2. Cliquez avec le bouton droit sur Net Logon, puis cliquez sur Arrêter .
3. Créez un fichier de réponses de l’Assistant Installation d’Active Director y sans surveillance.
Exécutez l’Assistant Installation d’Active Director y sur l’ordinateur de destination signalant l’erreur «
insatiste de schéma » avec la journalisation des diagnostics NTDS activée. La durée exacte de la
journalisation des diagnostics NTDS varie selon que l’ordinateur promu exécute Windows 2000 ou
L’Assistant Installation d’Active Directory affecte les clés de Windows suivantes :
Les contrôleurs de domaine d’aide qui exécutent Windows 2000 ou Windows Server 2003 conservent
les paramètres de journal dans la sous-clé de Registre jusqu’à ce que l’Assistant Installation d’Active
Directory rétrograde ces contrôleurs de
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics domaine.
Windows ordinateurs basés sur 2 000 qui sont promus ont la sous-clé de Registre au début de chaque
tentative HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics de promotion.
Double-cliquez sur Ntds_logging.reg dès que la réplication entrante de la partition de schéma à
partir du contrôleur de domaine d’aide a commencé à pré-remplir la sous-clé de Registre pour chaque
tentative de promotion du contrôleur de domaine
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics Windows 2000.
Windows Les ordinateurs basés sur Server 2003 ne écrivent pas les valeurs pré-existantes dans la
sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics de Registre.
Toutefois, les paramètres existants sont supprimés après chaque tentative de promotion qui a échoué.
Partie 3 : pré-remplir le Registre sur les contrôleurs de domaine de destination
Pré-remplir la sous-clé sur les contrôleurs de domaine de destination qui exécutent
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics Windows 2000 ou Windows Server
2003. Pour cela, procédez comme suit :
1. Sur le contrôleur de domaine source, suivez les étapes 1 à 5 de la section « Partie 1 : Activer la
journalisation des diagnostics ».
2. Cliquez avec le bouton droit sur la sous-clé de Registre suivante, puis cliquez sur Expor ter :
3. Dans la zone Enregistrer dans, ouvrez le dossier Bureau de l’administrateur sur l’ordinateur promu.
Dans la zone Nom de fichier, tapez Ntds_logging, puis cliquez sur OK .
NOTE
Pour localiser le dossier Bureau, consultez la remarque de la partie 1, étape 8.
4. Sur le contrôleur de domaine de destination, double-cliquez sur le fichier Ntds_logging.reg que vous
avez enregistré dans le dossier Bureau de l’administrateur au moment approprié, selon que l’ordinateur
promu exécute Windows Server 2003 ou Windows 2000.
Partie 4 : Recherche des attributs à valeurs multiples en double
1. Examinez les journaux des événements du service d’annuaire sur le contrôleur de domaine source et le
contrôleur de domaine de destination pour trouver l’objet problème.
2. Sur le contrôleur de domaine source, examinez le journal des événements du service d’annuaire et notez
le dernier objet et attribut qui ont été répliqués vers le contrôleur de domaine promu. L’objet problème
est soit le dernier objet ou attribut référencé dans le journal des événements du service d’annuaire, soit
l’objet dans la même partition avec le numéro usn de séquence de mise à jour le plus élevé suivant.
Enregistrez le chemin d’accès du nom de domaine de l’objet référencé et le dernier attribut répliqué. Sur
le contrôleur de domaine source, recherchez le dernier événement 1240. Sur le contrôleur de domaine de
destination, recherchez l’événement 1203.
3. Utilisez la ldifde commande pour exporter l’objet référencé. Pour cela :
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez la commande, puis cliquez sur OK.
b. Tapez ce qui suit, puis appuyez sur Entrée :
LDIFDE -f MISMATCH -d <domain name path of object referenced in event log of the source domain
controller>
4. Examinez la sortie ldifde dans Bloc-notes ou un autre éditeur de texte. Prêtez une attention particulière
aux attributs qui ont des valeurs en double. Par exemple, l’exemple tronqué suivant contient des attributs
avec des valeurs en double :
msExchMonitoringResponses:: <Start of Duplicate #1>

W19fQ0xBU1M6c3RyKDE3KV1TTVRQRXZlbnRDb25zdW1lcltOb3RpZnlPbkVycm9yOnN0cigyKV0tM
V
tSZXNwb25kVG9XaGljaE9iamVjdHM6c3RyKDEpXTBbT2JqZWN0c1RvUmVzcG9uZFRvOnN0cigwKV1
b U01UUFNlcnZlcjpzdHIoNCldQUxFWFtUb0xpbmU6c3RyKDI1KV1yamtlbnZpbkBtZXRib2UuazEyLm
5qLnVzW01lc3NhZ2U6c3RyKDMxNyldJVRhcmdldEluc3RhbmNlLk5hbWUlIGhhcyByZXBvcnRlZCBh
ICVUYXJnZXRJbnN0YW5jZS5TZXJ2ZXJTdGF0ZVN0cmluZyUuICBSZXBvcnRlZCBzdGF0dXMgaXM6DQ
pRdWV1ZXMgLSAlVGFy
Z2V0SW5zdGFuy2UuUXVldWVzU3RhdGVTdHJpbmclDQpEcml2ZXMglSAlVGFy
Z2V0SW5zdGFuy2UuRGlza3NTdGF0ZVN0cmluZyUNClNlcnZpY2VzIC0gJVRhcmdldEluc3RhbmNlLl
NlcnZpY2VzU3RhdGVTdHJpbmclDQpNZW1vcnkgLSAlVGFyZ2V0SW5zdGFuy2UuTWVtb3J5U3RhdG
VT
dHJpbmclDQpDUFUgLSAlVGFyZ2V0SW5zdGFuY2UuQ1BVU3RhdGVTdHJpbmclDQpbU3ViamVjdDp
zdH
IoNTkpXSVUYXJnZXRJbnN0YW5jZS5TZXJ2ZXJTdGF0ZVN0cmluZyUgb24gJVRhcmdldEluc3RhbmNl
Lk5hbWUl msExchMonitoringResponses:: <Start of Duplicate#2>
W19fQ0xBU1M6c3RyKDE3KV1TTVRQRXZlbnRDb25zdW1lcltOb3RpZnlPbkVycm9yOnN0cigyKV0tM
V
tSZXNwb25kVG9XaGljaE9iamVjdHM6c3RyKDEpXTBbT2JqZWN0c1RvUmVzcG9uZFRvOnN0cigwKV1
b U01UUFNlcnZlcjpzdHIoNCldQUxFWFtUb0xpbmU6c3RyKDI1KV1yamtlbnZpbkBtZXRib2UuazEyLm
5qLnVzW01lc3NhZ2U6c3RyKDMxNyldJVRhcmdldEluc3RhbmNlLk5hbWUlIGhhcyByZXBvcnRlZCBh
ICVUYXJnZXRJbnN0YW5jZS5TZXJ2ZXJTdGF0ZVN0cmluZyUuICBSZXBvcnRlZCBzdGF0dXMgaXM6DQ
pRdWV1ZXMgLSAlVGFy
Z2V0SW5zdGFuY2UuUXVldWVzU3RhdGVTdHJpbmclDQpEcml2ZXMgLSAlVGFy
Z2V0SW5zdGFuY2UuRGlza3NTdGF0ZVN0cmluZyUNClNlcnZpY2VzIC0gJVRhcmdldEluc3RhbmNlLl
NlcnZpY2VzU3RhdGVTdHJpbmclDQpNZW1vcnkgLSAlVGFyZ2V0SW5zdGFuY2UuTWVtb3J5U3RhdG
VT
dHJpbmclDQpDUFUgLSAlVGFyZ2V0SW5zdGFuY2UuQ1BVU3RhdGVTdHJpbmclDQpbU3ViamVjdDp
zdH
IoNTkpXSVUYXJnZXRJbnN0YW5jZS5TZXJ2ZXJTdGF0ZVN0cmluZyUgb24gJVRhcmdldEluc3RhbmNl
Lk5hbWUl
5. Si des valeurs en double s’affichent, Adsiedit.msc utilisez ldifde ou supprimez l’un des doublons. Une
fois que vous avez supprimé les doublons, réessayez la promotion en exécutant à nouveau l’Assistant
Installation d’Active Director y.
Partie 5 : Rechercher l’altération de la base de données
La cause première peut être l’altération de la base de données sur le contrôleur de domaine source. Pour
localiser l’altération de la base de données et la réparer, suivez les étapes suivantes :
1. Examinez le journal des événements des services d’annuaire du contrôleur de domaine source pour le
dernier événement 1240 enregistré. Cet événement peut être enregistré juste avant l’événement de
traitement interne 1173. Notez le chemin d’accès DN de l’objet référencé dans le dernier événement
1240, puis exécutez l’outil Repadmin.exe sur la console du contrôleur de domaine source. Pour cela,
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez la commande, puis cliquez sur OK.
b. Tapez la commande suivante, puis appuyez sur Entrée :
REPADMIN /SHOWMETA CN=Secret,CN=Schema,CN=Configuration,DC=CORP,DC=COM
2. Afficher les métadonnées du dernier objet répliqué sortant qui a été répliqué à partir du contrôleur de
domaine source. Si aucune valeur en double n’est trouvée, examinez le journal des événements des
services d’annuaire du contrôleur de domaine source pour le dernier événement 1240 enregistré avant
un événement 1173. Voici un exemple d’événement 1240.
3. Exécutez la commande sur le chemin d’accès du nom de domaine de l’objet référencé dans le dernier
événement 1240 qui a été enregistré sur le contrôleur repadmin /showmeta de domaine source. Par
exemple, à l’aide de l’exemple d’événement à l’étape 2 pour un contrôleur de domaine dans CORP.COM
domaine, la syntaxe serait la suivante :
REPADMIN /SHOWMETA CN=Secret,CN=Schema,CN=Configuration,DC=CORP,DC=COM
Recherchez des valeurs incohérentes ou suspectes dans la sortie, en particulier dans les colonnes Heure
d’origine et USN local. Par exemple, dans l’exemple de sortie tronquée suivant, deux attributs,
defaultObjectCategory et ObjectClass, ont ce qui semble être des numéros USN et 0 horodatés non
valides.
Sortie tronquée de la repadmin /showmeta commande :
CN=Secret,=Schema,CN=Configuration,DC=CORP,DC=COM object Loc. USNOriginating Time:

Attribute 21962002-01-29 05:52.47 instanceType 18295873486194836 4446-09-07 21:07
51.13defaultObjectCategory 182958734861948362002-01-29 05:52.47 objectClass
4. Si l’objet problème référencé dans la sortie n’est pas un objet critique, faites une sauvegarde ldifde de
l’objet, puis supprimez l’objet. Ne supprimez pas les objets problème qui résident dans la partition de
schéma d’Active Directory.
5. Exécutez une vérification de l’intégrité des fichiers NTDSUTIL par rapport à la base de données Active
Directory. Pour cela :
a. Windows 2000 utilise setpwd pour modifier les mots de passe DSRM. Windows Server 2003
utilise ntdsutil pour modifier les mots de passe DSRM.
L’option suivante fonctionne dans Windows Server 2003 :
322672 réinitialiser le mot de passe du compte d’administrateur du mode restauration des
services d’annuaire dans Windows Server
b. Démarrez le contrôleur de domaine source en mode DSREPAIR.
NOTE
Les clients qui tentent d’accéder aux informations de la racine DFS ou du lien DFS peuvent recevoir un
message d’erreur « Accès refusé » lors d’une tentative de connexion pendant que le contrôleur de domaine
est en mode DSREPAIR. Ce comportement est inhérent au produit.
c. Exécutez la vérification de l’intégrité des fichiers NTDSUTIL à partir Windows’invite de

commandes.
d. Recherchez les erreurs dans la sortie NTDSUTIL.
6. Si la vérification de l’intégrité NTDSUTIL a enregistré l’erreur de jet -1206, examinez les options suivantes.
Ne réparez en aucun cas les bases de données Active Directory endommagées à l’aide de NTDSUTIL ou
d’équivalents ESENTUTL.
a. Si d’autres contrôleurs de domaine candidats existent pour la source du nouveau contrôleur de
domaine dans la forêt, exécutez l’Assistant Installation d’Active Directory avec le contrôleur de
domaine source du problème hors connexion.
b. S’il existe d’autres contrôleurs de domaine dans le domaine et s’il n’existe aucun état système
significatif propre au contrôleur de domaine d’aide, essayez de rétrograder le contrôleur de
domaine source d’origine. Sinon, forcez-le à rétrograder, puis supprimez ses métadonnées de la
forêt. Exécutez l’Assistant Installation d’Active Directory pour rajouter le contrôleur de domaine
d’origine à la forêt après la réplication de bout en bout de la suppression sur tous les contrôleurs
de domaine de la forêt.
c. Restituer l’état du système pour ce contrôleur de domaine si toutes les conditions suivantes sont
vraies :
Le contrôleur de domaine source d’origine est le seul contrôleur de domaine dans son
domaine.
Il contient l’état système critique (autrement dit, il contient le domaine racine de la forêt, ou il y
a un investissement significatif dans les objets dans sa copie d’Active Directory).
Il existe une sauvegarde d’état système valide (autrement dit, la sauvegarde a moins de jours
tombstonelifetime et ne contient aucun objet endommagé).
NOTE
Une restauration d’état système d’une partition qui contient un seul réplica est en fait une restauration
faisant autorité de cette partition.
d. Si le contrôleur de domaine source d’origine est le seul contrôleur de domaine dans son domaine
et s’il contient l’état du système critique mais qu’il n’existe aucune sauvegarde d’état système
valide, envisagez de suivre les étapes suivantes :
Ajoutez un contrôleur Windows de domaine de sauvegarde Microsoft NT 4.0 au domaine. Cette
option suppose un mode mixte ou un commutateur qui permet à la bdc Windows NT 4.0 de se
répliquer avec des contrôleurs de domaine basés sur Windows 2000 dans les domaines en mode
natif.
Placez le Windows BDC basé sur NT 4.0 sur un réseau privé.
Promouvoir le Windows BDC basé sur NT 4.0 vers un contrôleur de domaine principal (PDC).
Mettre à niveau Windows PDC NT 4.0 vers Windows 2000 ou vers Windows Server 2003.
Ajoutez des contrôleurs de domaine réplica pour la tolérance de panne et l’équilibrage de charge.
Ajoutez les modifications de schéma requises pour les programmes Active Directory.
Partie 6 : désactiver la journalisation des diagnostics
Une fois le dépannage et la résolution du problème terminés, éteinez la journalisation des diagnostics. Pour ce
faire, allez à la « Partie 1 : activer la journalisation des diagnostics » et suivez les étapes 1 à 5. Définissez les
entrées de Registre suivantes sur 0 (zéro).
5 Événements de réplication
7 Configuration interne
8 Accès à l’annuaire
24 Schéma DS
Méthode 2 : Résolution de la condition 3
La troisième cause de l’erreur de « non-mise en commun du schéma » se produit lorsque le contrôleur de
domaine d’aide possède dans sa base de données des attributs qui ne sont pas couverts par le schéma actuel.
Ce problème peut se produire si un objet de schéma a été supprimé sur un contrôleur de domaine Windows
2000 avant l’installation du Service Pack 3 (SP3) pour Windows 2000.
1. Identifiez l’objet qui possède les attributs qui ne sont pas dans le schéma. Pour ce faire, prenons les
considérations suivantes :
Si vous exécutez Windows 2000, l’événement 1039 est enregistré sur le contrôleur de domaine source
avec le nom unique de l’objet concerné.
Si vous exécutez un autre système d’exploitation, activez les événements de réplication au niveau 5 (5)
sur la source. Pendant la réplication sortante, l’objet et l’attribut en cours d’expédition sont enregistrés.
Lorsque l’erreur se produit, recherchez l’objet suivant qui serait envoyé à l’ordinateur de destination.
2. Après avoir identifié l’objet qui possède les attributs supplémentaires, faites l’une ou plusieurs des choses
suivantes :
Supprimez l’objet. Les attributs incriminés seront retirés et la tombestone sera livrée pour réplication.
Modifiez l’objet pour supprimer les attributs en question.
Ajoutez à nouveau les entrées de schéma qui ont été supprimées.
DCPROMO échoue avec l’erreur « L’accès est refusé
» si l’utilisateur qui fait la promotion n’a pas le droit
d’utilisateur « Approuvé pour la délégation »
Cet article fournit une solution à une erreur Access refusée qui se produit avec DCPROMO (Contrôleur de
contrôleur de domaine).
Symptômes
La promotion DCPROMO d’un ordinateur membre Windows Server 2008 ou version ultérieure vers un
contrôleur de domaine réplica échoue avec l’erreur suivante :
Titre : Sécurité Windows

Texte du message : informations d’identification réseau
L’opération a échoué car l’Assistant Installation <hostname>des services de domaine Active Directory n’a
pas pu convertir le compte d’ordinateur $ en compte de contrôleur de domaine Active Directory. « L’accès
est refusé »
La rétrogradation DCPROMO peut échouer avec la même erreur :

L’opération a échoué car : Les services <hostname>de domaine Active Directory n’ont pas pu configurer le
compte d’ordinateur $ sur le compte de contrôleur de domaine Active Directory distant <fully qualified
name of helper DC>. « L’accès est refusé »
Cause
Le compte d’utilisateur utilisé pour exécuter DCPROMO ne s’est pas vu accorder le droit d’utilisateur « Activer
les comptes d’utilisateur et d’ordinateur pour qu’ils soient fiables pour la délégation ».
Résolution
1. Vérifiez que la stratégie de contrôleurs de domaine par défaut existe dans Active Directory.
Si la stratégie de contrôleur de domaine n’existe pas, évaluez si cette condition est dû à une latence de
réplication simple, à un échec de réplication Active Directory ou si la stratégie a été supprimée d’Active
Directory. Si la stratégie a été supprimée, contactez le Support Microsoft pour recréer la stratégie
manquante avec le GUID de stratégie par défaut (identificateur global unique). Ne recréez pas
manuellement la stratégie avec le même nom et les mêmes paramètres que la valeur par défaut.
Si la stratégie par défaut des contrôleurs de domaine existe dans Active Directory sur certains contrôleurs
de domaine, mais pas sur d’autres, évaluez si cette incohérence est due à une latence de réplication
simple ou à un échec de réplication. Résolvez selon les besoins.
2. Vérifiez que le compte de serveur n’est pas protégé contre la suppression accidentelle.
Pour ce faire, allez dans le Centre d’administration Active Director y , recherchez votre serveur sous la
liste Ordinateurs dans votre domaine, ouvrez les propriétés. Dans la première section, sous les
informations du système d’exploitation, assurez-vous que la case à cocher Protéger contre la suppression
accidentelle est désactivée.
Dans le processus d’élévation au contrôleur de domaine, le compte d’ordinateur du serveur est supprimé
et ajouté à nouveau en tant que contrôleur de domaine. Si vous cliquez sur cette case à cocher, cela ne
peut pas se produire.
3. Vérifiez que l’opération DCPROMO a été accordée au compte d’utilisateur « Activer les comptes
d’utilisateurs et d’ordinateurs pour qu’ils soient fiables pour la délégation » dans la stratégie de
contrôleurs de domaine par défaut.
Exécutez whoami /all cette vérification pour vérifier que le droit d’utilisateur « Activer la délégation des
comptes d’utilisateur et des ordinateurs » existe dans le jeton de sécurité des utilisateurs.
NOTE
Par défaut, ce droit est accordé aux membres du groupe de sécurité Administrateurs dans le domaine cible. Le
compte Administrateur intégré est membre de ce groupe de sécurité, mais il a peut-être été supprimé.
Si un utilisateur autre que le groupe d’administrateurs intégré fait des promotions DCPROMO, ajoutez
ce compte d’utilisateur au groupe de sécurité Administrateurs ou ajoutez au compte d’utilisateur
l’utilisateur « Activer la délégation des comptes d’ordinateur et d’utilisateur » directement dans la
stratégie de contrôleurs de domaine par défaut.
« Activer les comptes d’utilisateur et d’ordinateur pour qu’ils soient fiables pour la délégation » a été
récemment modifié ou la stratégie accordant le compte d’utilisateur DCPROMO existe sur certains
contrôleurs de domaine dans le domaine, mais pas sur d’autres, recherchez une latence de réplication
simple ou un échec de réplication dans Active Directory et la réplication du système de fichiers (FSR)
/DFSR(Distributed File System Replication).
Si la stratégie a été récemment modifiée, connectez-vous au compte d’utilisateur DCPROMO.
4. Vérifiez que la stratégie par défaut des contrôleurs de domaine est liée à l’UO des contrôleurs de
domaine et que tous les comptes d’ordinateur DC restent dans cette UO.
Si les comptes d’ordinateur DC restent dans un autre conteneur d’UO, déplacez tous les comptes
d’ordinateur DC vers l’UO des contrôleurs de domaine ou lier la stratégie de contrôleurs de domaine par
défaut à l’autre conteneur d’UO.
5. Vérifiez que la partie système de fichiers de la stratégie des contrôleurs de domaine par défaut existe
dans le partage SYSVOL du dc utilisé pour appliquer la stratégie sur l’ordinateur promu ou rétrogradé.
S’il n’est pas présent, cela peut être dû à une ou plusieurs des raisons suivantes :
Latence de réplication dans FRS/DFSR
Échec de réplication dans FRS/DFSR
La stratégie a été supprimée du SYSVOL. Si la stratégie a été supprimée, contactez le Support
Microsoft pour recréer la stratégie manquante avec le GUID de stratégie par défaut. Ne recréez pas
manuellement la stratégie avec le même nom et les mêmes paramètres que la valeur par défaut.
6. La stratégie de domaine par défaut en général ne s’applique pas à l’utilisateur connecté.
Pour vérifier l’héritage des stratégies, le filtrage WMI (Windows Management Instrumentation) ou le
problème de descripteur de sécurité qui empêche peut-être l’application de la stratégie, exécutez la
commande suivante :
gpresult /h result.html
Tableau 1. Journaux de promotion (exemple)
DC P RO M O. LO G DC P RO M O UI. LO G
[INFO] Création de l’objet Paramètres NTDS pour ce Appel de DsRoleGetDcOperationResults

contrôleur de domaine Active Directory sur le Erreur 0x0 (!0 => erreur)
.contoso.com AD DC <helperDC>distant... Résultats de l’opération :
[INFO] Réplication de la partition du répertoire de OperationStatus : 0x5 !0 => erreur
schéma DisplayString : l’Assistant Installation <DC being
... promoted>des services de domaine Active Directory n’a
[INFO] a répliqué le conteneur de schéma. pas pu convertir le compte d’ordinateur $ en compte de
[Info] Active Directory Domain Services a mis à jour le contrôleur de domaine Active Directory.
cache de schéma. ServerInstalledSite : (null)
[INFO] Réplication de la partition du répertoire de OperationResultsFlags : 0x0
configuration Entrez ProgressDialog::UpdateText L’Assistant Installation
... <dc being promoted>des services de domaine Active
[INFO] a répliqué le conteneur de configuration. Directory n’a pas pu convertir le compte d’ordinateur $
[Info] Error - The Active Directory Domain Services en compte de contrôleur de domaine Active Directory.
Installation Wizard was unable to convert the computer Enter State::SetOperationResultsMessage The Active
account <DC being promoted>$ to an Active Directory Directory Domain Services Installation Wizard was
Domain Controller account. (5) unable to convert the computer account <dc being
[INFO] EVENTLOG (erreur) : NTDS Général /Traitement promoted>$ to an Active Directory Domain Controller
interne : 1168 account.
Erreur interne : une erreur des services de domaine Entrez State::SetOperationResultsFlags 0x0
Active Directory s’est produite. Exception capturée
catch completed
Données supplémentaires gestion des exceptions
Enter State::ClearHiddenWhileUnattended
Valeur d’erreur (décimal) : Entrer EnableConsoleLocking
-1073741823 Enter RegistryKey::Create SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon
Valeur d’erreur (hex) : Enter RegistryKey::SetValue-DWORD
c0000001 DisableLockWorkstation
Enter State::SetOperationResults result FAILURE
ID interne : Entrez ProgressDialog::UpdateText
300162a Enter State::IsOperationRetryAllowed
true
[INFO] EVENTLOG (Informations) : NTDS General/Service les informations d’identification n’étaient pas valides,
Control: 1004 hr=0x80070005
Les services de domaine Active Directory ont été arrêtés Entrez getErrorMessage 80070005
avec succès. Enter State::GetOperationResultsMessage The Active
Directory Domain Services Installation Wizard was
[INFO] NtdsInstall pour a.com renvoyé 5 unable to convert the computer account <dc being
[INFO] DsRolepInstallDs renvoyé 5 promoted>$ to an Active Directory Domain Controller
[ERREUR] Échec de l’installation dans le service account.
d’annuaire (5) Enter State::GetOperation REPLICA
[INFO] Starting service NETLOGON Enter State::GetReplicaDomainDNSName <target dns
[INFO] Configuration du service NETLOGON sur 2 domain name>
renvoyé 0
[INFO] L’opération de contrôleur de domaine tentée est
terminée
[INFO] DsRolepSetOperationDone renvoyé 0
Tableau 2. Journaux de rétrogradation (exemple)

DC P RO M O. LO G DC P RO M O UI. LO G
[INFO] Désinstallation du service d’annuaire ....

[INFO] Invoking NtdsDemote OperationStatus : 0x5 !0 => erreur
... DisplayString : Les services de domaine Active Directory
[INFO] Suppression d’objets services de domaine Active n’ont pas pu configurer le compte d’ordinateur <dc
Directory qui font référence au contrôleur de domaine name>$ sur le contrôleur de domaine Active Directory
Active Directory local à partir du contrôleur de domaine distant<helper DC>.<dns domain>
Active Directory distant...<DNS domain> ServerInstalledSite : (null)
[Info] Error - Active Directory Domain Services couldn’t OperationResultsFlags : 0x0
configure the computer account <dc being demoted>$ Enter ProgressDialog::UpdateText Active Directory
on the remote Active Directory Domain Controller Domain Services couldn’t configure the computer
<helper DC>.<DNS domain>. (5) account <dc name>$ on the remote Active Directory
[INFO] NtdsDemote renvoyé 5 Domain Controller VM1-W7.a.com.
[INFO] DsRolepDemoteDs renvoyé 5 Enter State::SetOperationResultsMessage Active
[ERREUR] Échec de rétrogradation du service d’annuaire Directory Domain Services couldn’t configure the
(5) computer account <dc name>$ on the remote Active
.... Directory Domain Controller <helper DC>.<DNS
domain>.
Entrez State::SetOperationResultsFlags 0x0
...
les informations d’identification n’étaient pas valides,
hr=0x80070005
Entrez getErrorMessage 80070005
Enter State::GetOperationResultsMessage Active
Directory Domain Services couldn’t configure the
computer account <dc name>$ on the remote Active
Directory Domain Controller <helper DC>.<DNS
domain>.
Enter State::GetOperation DEMOTE
Enter State::GetParentDomainDnsName
Erreur « Accès refusé » lorsque vous essayez de
créer un objet Paramètres NTDS
Cet article fournit une solution pour corriger une erreur (Accès refusé) qui se produit lorsque vous faites la
promotion de nouveaux contrôleurs de domaine Windows Server 2012 R2 dans un domaine existant.
Symptômes
Lorsque vous essayez de promouvoir de nouveaux contrôleurs Windows Server 2012 R2 dans un domaine
existant, l’opération échoue avec une erreur « Accès refusé ». Ce problème se produit même lorsque l’utilisateur
est membre du groupe Administrateurs du domaine Enterprise Administrateurs.
Dans ce cas, l’administrateur voit le message d’erreur suivant :
L’opération a échoué car : Les services de domaine Active Directory n’ont pas pu configurer le compte
d’ordinateur $ sur le compte de contrôleur de domaine <hostname> Active Directory <fully qualified name
of helper DC> distant. « L’accès est refusé »
L’échec se produit lors de l’ajout de l’objet Paramètres NTDS pour le nouveau contrôleur de domaine, renvoyant
le message d’erreur suivant :
Active Directory Domain Services could not create the NTDS Paramètres object for this Active Directory Domain
Controller CN=NTDS Paramètres,CN=TEST-
DC,CN=Servers,CN=mysite,CN=Sites,CN=Configuration,DC=domain,DC=com on the remote AD DC
DCName.ChildDomain.domain.com . Assurez-vous que les informations d’identification réseau fournies ont
des autorisations suffisantes.
« L’accès est refusé. »
En outre, le fichier DCPromo.log affiche les erreurs suivantes :

2705DateTime[INFO]
Erreur - Les services de domaine Active Directory n’ont pas pu créer l’objet Paramètres NTDS pour ce
contrôleur de domaine Active Directory CN=NTDS Paramètres,CN=TEST-
DC,CN=Servers,CN=mysite,CN=Sites,CN=Configuration,DC=domain,DC=com sur le
DCName.ChildDomain.domain.com distant AD DC. Assurez-vous que les informations d’identification
réseau fournies ont des autorisations suffisantes. (5)
DateTime[INFO] EVENTLOG (erreur) : NTDS General/Internal Processing: 1168 Internal error: An Active
Directory Domain Services error has occurred.
Valeur d’erreur (décimal) :
-1073741823
Valeur d’erreur (hex) :
c0000001
ID interne : 30017c6
...
DateTime[INFO] NtdsInstall pour ChildDomain.domain.com le retour 5
DateTime [INFO] DsRolepInstallDs renvoyé 5
DateTime [ERROR] Échec de l’installation dans le service d’annuaire (5)
DateTime[ERROR] Échec de DsRolepFinishSysVolPropagation (Abandon de la promotion) avec 8001
DateTime[AVERTISSEMENT] Échec de l’abandon de l’installation en volume du système (8001)
DateTime[INFO] Démarrage du service NETLOGON
DateTime[INFO] Configuration du service NETLOGON sur 2 renvoyé 0
DateTime[INFO] L’opération de contrôleur de domaine tentée est terminée
Où les erreurs se muivent :
Cause
Ce problème se produit car l’autorisation Ajouter/Supprimer un réplica dans le domaine est manquante pour les
groupes Administrateurs du domaine et Administrateurs Enterprise sur la partition de domaine du domaine.
Résolution
1. Vérifiez que toutes les étapes et conditions de la section « Résolution » de l’article de la Base de 2002413
sont vraies pour votre environnement.
2. Si la promotion du contrôleur de domaine échoue toujours même après avoir vérifié que l’utilisateur
dispose également de l’autorisation SeEnableDelegationPrivilege, vérifiez ADSIEdit.msc pour vérifier les
autorisations effectives de l’utilisateur pour la partition de domaine :
a. Cliquez sur Démarrer, sur Exécuter, puis tapez adsiedit.msc.
b. Développez le contexte d’attribution de noms par défaut, cliquez avec le bouton droit sur
DC=domaine,DC=com, puis cliquez sur Propriétés .
c. Sous l’onglet Sécurité, cliquez sur le bouton Avancé.
d. Sous l’onglet Accès effectif, entrez le nom d’utilisateur ou de groupe de l’utilisateur qui effectue
l’opération qui échoue dans DCPromo.
e. Confirmez si l’autorisation d’accès au réplica d’ajout/suppression dans le contrôle de domaine a
été accordée.
3. Si l’autorisation Ajouter/Supprimer un réplica dans le domaine est manquante pour l’utilisateur ou le
groupe, ajoutez-le à l’aide d’ADSIEdit.msc :
a. Cliquez sur Démarrer, sur Exécuter, puis tapez adsiedit.msc.
b. Développez le contexte d’attribution de noms par défaut, cliquez avec le bouton droit sur
DC=domaine,DC=com, puis cliquez sur Propriétés .
c. Sous l’onglet Sécurité, cliquez sur le bouton Avancé.
d. Sous l’onglet Autorisations, ajoutez le réplica Ajouter/supprimer dans l’autorisation d’accès au
contrôle de domaine pour l’utilisateur ou le groupe souhaité comme suit :
Type : Autoriser
S’applique à : Cet objet uniquement
NOTE
il peut y avoir d’autres raisons pour lesquelles la promotion ou la rétrogradation d’un contrôleur de domaine échoue avec
une erreur « Accès refusé ». Pour plus d’informations, voir la 2002413.
Erreur « Impossible de démarrer le service » lors de
la configuration des services AD DS
Cet article fournit de l’aide sur une erreur (le service ne peut pas être démarré) qui se produit en cas d’échec de
la configuration des services de domaine Active Directory (AD DS).
Symptômes
Dans Windows Server 2012, l’une des opérations de configuration AD DS suivantes échoue :
Configuration d’un nouveau contrôleur de domaine à l’aide du Gestionnaire de serveur ou du module
AddsDeployment Windows PowerShell module
Suppression d’AD DS d’un contrôleur de domaine existant à l’aide du Gestionnaire de serveur ou du module
AddsDeployment Windows PowerShell
Clonage d’un contrôleur de domaine virtualisé à l’aide dccloneconfig.xml
En cas d’échec de la configuration, vous recevez le message d’erreur suivant :
Le service ne peut pas être démarré, soit parce qu’il est désactivé, soit parce qu’aucun périphérique n’est
associé.
En outre, vous voyez que le fichier Dcpromoui.log contient la ligne de texte suivante :
Entrez getErrorMessage 80070422
Cause
Ce problème se produit car un administrateur a configuré le « type de démarrage » pour le service DS Role
Server (DsRoleSvc) sur désactivé. Vous pouvez le confirmer à l’aide du logiciel en snap-in Services.msc pour
examiner la liste des types de démarrage sous l’onglet Général.
Par défaut, le service serveur de rôles DS est installé pendant l’installation du rôle AD DS et est définie sur le
type de démarrage manuel.
Résolution
Pour résoudre ce problème, assurez-vous que le service serveur de rôles DS n’est pas désactivé. Pour ce faire,
utilisez Services.msc ou Sc.exe pour définir le type de démarrage sur Manuel et pour laisser les opérations du
serveur de rôles DS démarrer et arrêter le service à la demande. Par exemple, exécutez la commande suivante à
partir d’une invite de commandes avec élévation de niveaux Administrateur :
sc.exe config dsrolesvc start= demand

NOTE
L’espace après l’argument « start= » est intentionnel.
Le service serveur de rôles DS est une nouveauté Windows Server 2012 et est utilisé pour installer ou
supprimer Active Directory ou pour cloner des contrôleurs de domaine.
Vous ne pouvez pas ajouter un contrôleur de
domaine en tant que nœud dans un environnement
de cluster de failover
Cet article fournit des informations sur l’ajout d’un contrôleur de domaine en tant que nœud dans un
environnement de cluster de failover.
Symptômes
Lorsque vous créez un environnement de cluster de Windows Server 2012 de Windows Server 2012, vous ne
pouvez pas ajouter un serveur dont le rôle services de domaine Active Directory (AD DS) est un nœud.
Cause
Nous ne combinant pas le rôle AD DS et la fonctionnalité de cluster de Windows Server 2012.
Statut
Bien que cela ne soit pas recommandé, vous pouvez activer les contrôleurs de domaine en tant que nœud de
cluster dans les versions Windows Server antérieures à Windows Server 2012. Toutefois, à partir Windows
Server 2012, cette configuration n’est plus prise en charge.
Pour plus d’informations sur l’utilisation des contrôleurs de domaine en tant que nodes dans les clusters de
failover, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :
281662 comment utiliser des Windows cluster serveur en tant que contrôleurs de domaine
Pour plus d’informations sur la stratégie de support Microsoft pour les clusters de Windows Server 2012,
cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :
2775067 stratégie de support Microsoft pour les clusters Windows Server 2012 de changement de compte
Impossible de sélectionner le rôle serveur DNS lors
de l’ajout d’un contrôleur de domaine à un domaine
Active Directory existant
Cet article permet de résoudre un problème où l’option d’installation automatique du rôle serveur DNS est
désactivée ou grisée dans l’Assistant Installation d’Active Directory (DCPROMO) lors de la promotion d’un
contrôleur de domaine réplica Windows Server 2008 ou Windows Server 2008 R2.
Symptômes
Lors de la promotion d’un contrôleur de domaine réplica Windows Server 2008 ou Windows Server 2008 R2,
l’option d’installation automatique du rôle serveur DNS est désactivée ou grisée dans l’Assistant Installation
d’Active Directory (DCPROMO).
Texte dans les états du champ Informations supplémentaires :
Le DNS ne peut pas être installé sur ce contrôleur de domaine, car ce domaine n’héberge pas le DNS.
Une capture d’écran de cette condition est affichée ci-dessous :
Le fichier %windir%\debug\dcpromoui.log sur le contrôleur de domaine réplica promu affiche les données
suivantes :
Enter DoesDomainHostDns SLD

dcpromoui A74. A78 046C <DateTime> Dns_DoesDomainHostDns le nom de domaine SLD
dcpromoui A74. Une requête SOA A78 046D a renvoyé 9003 afin que le <DateTime> domaine n’héberge
pas le DNS
dcpromoui A74. A78 046E <DateTime> Dns_DoesDomainHostDns renvoyer false
dcpromoui A74. A78 046F <DateTime> HRESULT = 0x00000000
dcpromoui A74. A78 0470 <DateTime> Le domaine n’héberge pas le DNS.
Cause
1. Un défaut de code empêche la case à cocher du serveur DNS d’être activée lors de la promotion des
contrôleurs de domaine réplica dans des domaines existants avec des noms DNS en une seule partie
comme « contoso » au lieu d’un nom DNS complet des meilleures pratiques comme « » ou contoso.com
« corp.contoso.com ». Cette condition existe même lorsque Microsoft DNS est installé sur un contrôleur
de domaine et héberge des zones de recherche avant intégrées à Active Directory pour le domaine cible.
Pour plus d’informations sur les domaines en une seule page, visitez le site web Microsoft suivant :
Centre de solutions de planification des espaces de noms DNS Microsoft
OR
2. DCPromo vérifie si la zone DNS de la forêt Active Directory cible est hébergée dans Active Directory. Si la
zone DNS du domaine cible n’est pas hébergée sur un contrôleur de domaine existant dans la forêt cible,
DCPROMO ne permet pas à l’utilisateur d’installer DNS pendant la promotion du réplica.
L’objectif de ce comportement est d’empêcher les administrateurs de créer des copies en double de zones
DNS avec différentes étendues de réplication (c’est-à-dire, des zones basées sur des fichiers sur des
serveurs DNS Microsoft ou tiers et des zones DNS intégrées Active Directory sur des contrôleurs de
domaine sur le contrôleur de domaine nouvellement promu).
Résolution
Pour la première cause première, poursuivez la promotion et installez le rôle serveur DNS après sa promotion.
Pour la deuxième cause première, la configuration du client et du serveur DNS sur le contrôleur de domaine
réplica promu était suffisante pour découvrir un contrôleur de domaine d’aide dans le domaine cible, mais
DCPROMO a déterminé que la zone DNS du domaine n’était pas intégrée à Active Directory.
Déterminez les serveurs DNS qui vont héberger la zone pour votre domaine Active Directory et les étendues de
réplication que ces zones utiliseront (Microsoft DNS par rapport à un DNS tiers, une partition d’application à
l’échelle de la forêt, une partition d’application à l’échelle du domaine, une base de données principale, etc.)
Ne laissez pas l’impossibilité d’installer automatiquement le rôle serveur DNS pendant DCPROMO pour bloquer
la promotion des contrôleurs de domaine réplica Windows Server 2008 dans le domaine. Le Gestionnaire de
serveur peut être utilisé pour installer le rôle Serveur DNS Microsoft sur les contrôleurs de domaine existants,
ainsi que sur les ordinateurs fonctionnant en tant qu’ordinateurs membres ou de groupe de travail. Les zones
DNS et leurs enregistrements peuvent être répliqués ou copiés entre des serveurs DNS.
Les solutions de contournement spécifiques sont les suivantes :
1. Si les zones DNS existent sur des serveurs DNS en dehors du domaine, envisagez de déplacer les zones
vers un contrôleur de domaine existant dans le domaine qui héberge le rôle serveur DNS.
2. Si les données de zone doivent être déplacées, configurez le serveur DNS Microsoft pour héberger une
copie secondaire de la zone, convertissez cette zone en une zone principale basée sur les fichiers, puis
convertissez la zone pour qu’elle soit intégrée à Active Directory selon les besoins. Vous pouvez ignorer
cette étape si vous n’avez aucun intérêt à enregistrer les données de zone DNS.
3. Configurez le nouveau contrôleur de domaine réplica promu pour qu’il pointe exclusivement vers les
serveurs DNS hébergeant des copies intégrées Active Directory de la zone.
4. Utilisez la commande suivante pour forcer les ordinateurs Windows 2000, Windows XP, Windows Server
2003, Windows Vista et Windows Server 2008 à inscrire dynamiquement les enregistrements A ou AAAA
de l’hôte :
ipconfig /registerdns
5. Utilisez la commande suivante pour forcer Windows contrôleurs de domaine Windows 2000, Windows
Server 2003 et Windows Server 2008 à enregistrer dynamiquement des enregistrements SRV
net stop netlogon & net start netlogon
6. Redémarrez DCPROMO sur le contrôleur de domaine réplica.

Comment créer un serveur Active Directory dans
Windows Server 2003
Cet article explique comment installer et configurer une nouvelle installation Active Directory dans un
environnement de laboratoire qui inclut Windows Server 2003 et Active Directory.
NOTE
Vous aurez besoin de deux serveurs réseau qui exécutent Windows Server 2003 à cet effet dans un environnement de
laboratoire.
Créer Active Directory

Après avoir installé Windows Server 2003 sur un serveur autonome, exécutez l’Assistant Active Directory pour
créer la forêt ou le domaine Active Directory, puis convertissez l’ordinateur Windows Server 2003 en premier
contrôleur de domaine de la forêt. Pour convertir un ordinateur Windows Server 2003 en premier contrôleur de
domaine dans la forêt, suivez les étapes suivantes :
1. Insérez le CD-ROM Windows Server 2003 dans le cd-ROM ou le lecteur de DVD de votre ordinateur.
2. Cliquez sur Démarrer, cliquez sur Exécuter, puis tapez dcpromo.
3. Cliquez sur OK pour démarrer l’Assistant Installation d’Active Director y, puis cliquez sur Suivant .
4. Cliquez sur Contrôleur de domaine pour un nouveau domaine, puis sur Suivant .
5. Cliquez sur Domaine dans une nouvelle forêt, puis sur Suivant .
6. Spécifiez le nom DNS complet du nouveau domaine. Notez que, étant donné que cette procédure est
pour un environnement de laboratoire et que vous n’intégrez pas cet environnement à votre
infrastructure DNS existante, vous pouvez utiliser quelque chose de générique, tel que mycompany.local,
pour ce paramètre. Cliquez sur Suivant .
7. Acceptez le nom netBIOS du domaine par défaut (il s’agit de « mycompany » si vous avez utilisé la
suggestion à l’étape 6). Cliquez sur Suivant .
8. Définissez l’emplacement de la base de données et du fichier journal sur le paramètre par défaut du
dossier c: \ winnt \ ntds, puis cliquez sur Suivant .
9. Définissez l’emplacement du dossier Sysvol sur le paramètre par défaut du dossier sysvol c: winnt, puis
cliquez \ \ sur Suivant .
10. Cliquez sur Installer et configurer le ser veur DNS sur cet ordinateur, puis cliquez sur Suivant .
11. Cliquez sur Autorisations compatibles uniquement avec Windows 2000 ou Windows Ser ver
2003 ou les systèmes d’exploitation, puis cliquez sur Suivant .
12. Comme il s’agit d’un environnement de laboratoire, laissez le mot de passe de l’administrateur du mode
restauration des services d’annuaire vide. Notez que dans un environnement de production complet, ce
mot de passe est définie à l’aide d’un format de mot de passe sécurisé. Cliquez sur Suivant .
13. Examinez et confirmez les options que vous avez sélectionnées, puis cliquez sur Suivant .
14. L’installation d’Active Directory se poursuit. Notez que cette opération peut prendre plusieurs minutes.
15. Lorsque vous y êtes invité, redémarrez l’ordinateur. Après le redémarrage de l’ordinateur, confirmez que
les enregistrements d’emplacement du service DNS (Domain Name System) pour le nouveau contrôleur
de domaine ont été créés. Pour vérifier que les enregistrements d’emplacement du service DNS ont été
créés, suivez les étapes suivantes :
a. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur DNS pour démarrer la
console d’administrateur DNS.
b. Développez le nom du serveur, développez zones de recherche avant, puis développez le
domaine.
c. Vérifiez que les dossiers _msdcs, _sites, _tcp et _udp sont présents. Ces dossiers et les enregistrements
d’emplacement de service qu’ils contiennent sont essentiels aux opérations Active Directory et
Ajouter des utilisateurs et des ordinateurs au domaine Active

Directory
Une fois le nouveau domaine Active Directory établi, créez un compte d’utilisateur dans ce domaine à utiliser
comme compte d’administration. Lorsque cet utilisateur est ajouté aux groupes de sécurité appropriés, utilisez
ce compte pour ajouter des ordinateurs au domaine.
1. Pour créer un utilisateur, suivez les étapes suivantes :
a. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Utilisateurs et
ordinateurs Active Director y pour démarrer la console Utilisateurs et ordinateurs Active
Directory.
b. Cliquez sur le nom de domaine que vous avez créé, puis développez le contenu.
c. Cliquez avec le bouton droit sur Utilisateurs, pointez sur Nouveau, puis cliquez sur Utilisateur.
d. Tapez le prénom, le nom et le nom d’utilisateur du nouvel utilisateur, puis cliquez sur Suivant .
e. Tapez un nouveau mot de passe, confirmez-le, puis cliquez pour sélectionner l’une des cases à
cocher suivantes :
Les utilisateurs doivent modifier le mot de passe à la prochaine fois (recommandé pour la
plupart des utilisateurs)
L’utilisateur ne peut pas modifier le mot de passe
Le mot de passe n’expire jamais
Le compte est désactivé
Cliquez sur Suivant .
f. Examinez les informations que vous avez fournies et, si tout est correct, cliquez sur Terminer.
2. Après avoir créé le nouvel utilisateur, donnez à ce compte d’utilisateur l’appartenance à un groupe qui lui
permet d’effectuer des tâches administratives. Comme il s’agit d’un environnement de laboratoire dont
vous contrôlez le contrôle, vous pouvez accorder à ce compte d’utilisateur un accès administratif complet
en le faisant membre des groupes Administrateurs de schéma, de Enterprise et de domaine. Pour ajouter
le compte aux groupes d’administrateurs de schéma, de Enterprise et de domaine, suivez les étapes
suivantes :
a. Dans la console Utilisateurs et ordinateurs Active Directory, cliquez avec le bouton droit sur le
nouveau compte que vous avez créé, puis cliquez sur Propriétés.
b. Cliquez sur l'onglet Membre de , puis sur Ajouter .
c. Dans la boîte de dialogue Sélectionner des groupes, spécifiez un groupe, puis cliquez sur OK pour
ajouter les groupes que vous souhaitez à la liste.
d. Répétez le processus de sélection pour chaque groupe dans lequel l’utilisateur doit être membre du
compte.
e. Cliquez sur OK pour terminer.
3. La dernière étape de ce processus consiste à ajouter un serveur membre au domaine. Ce processus
s’applique également aux stations de travail. Pour ajouter un ordinateur au domaine, suivez les étapes
suivantes :
a. Connectez-vous à l’ordinateur que vous souhaitez ajouter au domaine.
b. Cliquez avec le bouton droit sur Mon ordinateur, puis cliquez sur Propriétés.
c. Cliquez sur l’onglet Nom de l’ordinateur, puis sur Modifier.
d. Dans la boîte de dialogue Changements de nom d’ordinateur, cliquez sur Domaine sous
Membre de, puis tapez le nom de domaine. Cliquez sur OK .
e. Lorsque vous y êtes invité, tapez le nom d’utilisateur et le mot de passe du compte que vous avez
créé précédemment, puis cliquez sur OK .
Un message qui vous souhaite bienvenue dans le domaine est généré.
f. Cliquez sur OK pour revenir à l’onglet Nom de l’ordinateur, puis cliquez sur OK pour terminer.
g. Redémarrez l’ordinateur si vous êtes invité à le faire.
Résolution des problèmes : vous ne pouvez pas ouvrir les logiciels en

snap-in Active Directory
Une fois l’installation d’Active Directory terminée, il se peut que vous ne soyez pas en mesure de démarrer le
logiciel en ligne Utilisateurs et ordinateurs Active Directory et que vous receviez un message d’erreur qui
indique qu’aucune autorité ne peut être contactée pour l’authentification. Cela peut se produire si le DNS n’est
pas correctement configuré. Pour résoudre ce problème, vérifiez que les zones de votre serveur DNS sont
configurées correctement et que votre serveur DNS dispose de l’autorité pour la zone qui contient le nom de
domaine Active Directory. Si les zones semblent correctes et que le serveur dispose de l’autorité pour le
domaine, essayez de démarrer à nouveau le logiciel en ligne Utilisateurs et ordinateurs Active Directory. Si vous
recevez le même message d’erreur, utilisez l’utilitaire DCPROMO pour supprimer Active Directory, redémarrer
l’ordinateur, puis réinstaller Active Directory.
Pour plus d’informations sur la configuration du DNS sur Windows Server 2003, voir Comment configurer DNS
pour l’accès à Internet dans Windows Server 2003.
La promotion du contrôleur de domaine cesse de
répondre lorsque NetBIOS sur TCPIP est désactivé
dans Windows Server 2012 R2
Cet article fournit une solution à un problème dans lequel la promotion du contrôleur de domaine cesse de
répondre lorsque des informations d’identification courtes sont utilisées dans un environnement dans lequel
NetBIOS sur TCPIP est désactivé.
Symptômes
Lorsque vous utilisez l’Assistant Configuration des services de domaine Active Directory pour promouvoir un
ordinateur en contrôleur de domaine dans Windows Server 2012 R2, l’Assistant cesse de répondre. Lorsque le
problème se produit, l’Assistant Configuration des services de domaine Active Directory indique que la
promotion est en cours et affiche le texte suivant :
Windows Server 2012 Les contrôleurs de domaine R2 ont une valeur par défaut pour le paramètre de
sécurité nommé « Autoriser les algorithmes de chiffrement compatibles avec Windows NT 4.0 » qui
empêche les algorithmes de chiffrement plus faibles lors de l’établissement de sessions de canal de sécurité.
Lorsque le problème se produit, le fichier Dcpromo.log indique correctement que l’opération de promotion s’est
arrêtée :
[INFO] DnsDomainName erd contoso.local

[INFO] Enfant FlatDomainName
[INFO] SiteName Default-First-Site-Name
[INFO] SystemVolumeRootPath C:\Windows\SYSVOL
INFO] DsDatabasePath C:\Windows\NTDS, DsLogPath C:\Windows\NTDS
[INFO] ParentDnsDomainName contoso.local
[INFO] ParentServer <helper DC> .contoso.local
[INFO] Compte contoso\administrateur
[INFO] Options 5243072
[INFO] Valider les chemins d’accès fournis
....
[INFO] EVENTLOG (erreur) : Réplication NTDS / Client RPC DS : 1963
Événement interne : le service d’annuaire local suivant a reçu une exception d’une connexion d’appel de
procédure distante (RPC). Des informations RPC complètes ont été demandées. Il s’agit d’informations
intermédiaires qui peuvent ne pas contenir de cause possible
[INFO] EVENTLOG (erreur) : Réplication NTDS /Client RPC DS : 1962
Événement interne : le service d’annuaire local a reçu une exception d’une connexion d’appel de procédure
distante (RPC). Les informations sur les erreurs étendues ne sont pas disponibles.
.... Valeur d’erreur :
Une erreur spécifique au package de sécurité s’est produite. Service 1825directory :
<hostname> Données supplémentaires
Valeur d’erreur :
Le contrôleur de domaine de ce domaine n’a pas pu être trouvé. (1908)
[INFO] EVENTLOG (erreur) : réplication NTDS / installation : 1125
L’Assistant Installation des services de domaine Active Directory (Dcpromo) n’a pas pu établir de connexion
avec le contrôleur de domaine suivant.
Contrôleur de domaine <DC name> : <DNS domain name> .<top level domain name>
Valeur d’erreur :
1908 Le contrôleur de domaine de ce domaine n’a pas pu être trouvé.
Ce problème se produit lorsque les conditions suivantes sont vraies :

NetBIOS sur TCP/IP est désactivé. Cela se produit dans les situations suivantes :
L’option Désactiver NetBIOS sur TCP/IP n’est pas sélectionnée dans le panneau Réseaux, l’onglet
WINS dans la Paramètres TCP/IP avancée des propriétés IPv4.
NetBIOS sur TCP/IP est désactivé sur le serveur DHCP.
Les ordinateurs utilisent uniquement la configuration IPv6.
Les noms d’informations d’identification « courts » sont utilisés dans l’interface utilisateur des
informations d’identification ou dans le fichier de réponse de promotion du contrôleur de domaine.
La section précédente indique qu’une erreur ERROR_DOMAIN_CONTROLLER_NOT_FOUND est renvoyée
par l’appel de liaison DRS lorsque le processus de promotion est en cours de configuration pour
répliquer le premier contexte Dcpromo.log d’attribution de noms.
Dans ce cas, Kerberos ne peut pas localiser un contrôleur de domaine avec qui s’authentifier à l’aide des
informations d’identification spécifiées. Par exemple, les informations d’identification spécifiées sont «
wolf\administrator » au lieu d’informations d’identification DNS « longues » comme
wolf.com\administrator. Dans les informations d’identification, « wolf » est le nom NetBIOS du domaine
hébergeant le compte d’administrateur.
NOTE
Si le problème se produit lorsque vous faites la promotion d’un nouveau contrôleur de domaine dans un nouveau
domaine enfant. Les problèmes suivants se produisent également :
L’ordinateur considère qu’il est joint au domaine.
Vous aurez la possibilité de vous connecter au domaine enfant, mais la connexion échouera.
Si vous vous connectez localement à l’ordinateur, les services ADDS et AWDS sont désactivés. Le Netlogon.exe n’est
pas démarré et la valeur de démarrage est définie sur identique manuellement, par exemple le paramètre par défaut
pour une station de travail membre.
Cause
Lorsque vous exécutez l’Assistant Configuration des services de domaine Active Directory dans un
environnement NetBIOS-less\WINS-less, il introduit certaines limitations de localisation de DC pour connaître
les noms de domaine courts. Cela est particulièrement vrai sur un ordinateur non joint à un domaine. Le
localisateur de dc tente de masquer les noms de domaine courts sur des noms de domaine complets (FQDN) à
l’aide de la liste des domaines de confiance, qui implique que le DNS soit utilisé la plupart du temps. Si le DNS
ne peut pas être utilisé, le localisateur doit utiliser WINS\NetBIOS. Toutefois, WINS\NetBIOS n’est pas disponible
lorsque NetBIOS sur TCP/IP est désactivé. Ce problème peut être en partie contourner par la fonctionnalité de
suffixe DNS ajoutée au localisateur de dc dans Windows Server 2012 R2 et Windows 8.1 mais qui n’est pas
toujours une solution fiable à 100 %.
Résolution
Pour résoudre le problème, suivez les étapes suivantes :
1. Terminez le processus gestionnaire de serveur dans le Gestionnaire des tâches.
NOTE
Cette étape ferme l’Assistant Configuration des services de domaine Active Directory. Lorsque le problème se
produit, le bouton Annuler dans l’interface utilisateur ne fonctionne pas. En outre, la fin de l’Assistant
Configuration des services de domaine Active Directory dans le Gestionnaire des tâches ne fonctionne pas non
plus.
2. Lorsque vous faites à nouveau la promotion de l’ordinateur en tant que contrôleur de domaine, utilisez
l’une des solutions de contournement suivantes :
Informations d’identification « longues » spécifiques, par exemple, \administrateur, dans l’Assistant
Promotion ou dans les fichiers de <domain> réponses de promotion.
Sur les ordinateurs Windows 8.1 et Windows Server 2012 R2, configurez les suffixes de recherche
DNS, de sorte que lorsque les suffixes de recherche DNS sont concénés avec le nom de domaine
NetBIOS fourni, ils peuvent être résolus en nom DNS complet du domaine Active Directory qui
héberge le compte d’utilisateur utilisé pour effectuer l’opération authentifiée.
NOTE
Cela suppose que le nom NetBIOS spécifié dans les informations d’identification « UI » correspond à la
partie la plus à gauche du nom de domaine DNS des comptes cibles.
Rejoignez l’ordinateur invité en tant qu’ordinateur membre dans le domaine cible, puis réessayez la
promotion.
Activez temporairement NetBIOS sur TCP/IP pour terminer la promotion.
La rétrogradation DCPROMO échoue si elle ne
parvient pas à contacter le maître d’infrastructure
DNS
Cet article résout un problème dans lequel la rétrogradation d’un ordinateur Windows Server qui héberge les
services de domaine Active Directory (AD DS) ou le rôle serveur de contrôleur de domaine échoue.
Symptômes
La rétrogradation d’un ordinateur Windows server hébergeant le rôle serveur de contrôleur de domaine ou AD
DS échoue. L’erreur à l’écran suivante s’affiche :
Texte de la barre de titre : Assistant Installation des services de domaine Active Directory
Texte du message :
Les services de domaine Active Directory n’ont pas pu transférer les données restantes dans la partition
d’annuaire
DC=DomainDNSZones,DC= <DNS domjain name> to Active Directory Domain Controller
\\<DNS name of helper DC used to service demotion>
« Le service d’annuaire ne manque pas d’informations de configuration obligatoires et ne parvient pas à
déterminer la propriété des rôles d’opération à maître unique flottants. »
Partie pertinente de DCPROMO. Le fichier JOURNAL contient le texte suivant :
<date> <time> [INFO] Transferring operations master roles owned by this Active Directory Domain Controller
in directory partition
DC=DomainDnsZones,DC=contoso,DC=com to Active Directory Domain Controller \\<DNS name of helper DC...
<date> <time> [INFO] EVENTLOG (Warning): NTDS Replication / Replication : 2091
Un examen de l’objet d’infrastructure et des attributs de la partition d’application DNS référencé dans l’erreur
DCPROMO à l’écran et DCPROMO. LOG :
Expanding base 'CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=com'...
Getting 1 entries:
Dn: CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=com
cn: Infrastructure;
distinguishedName: CN=Infrastructure,DC=DomainDnsZones,DC=contoso,DC=corp,DC=microsoft,DC=com;
dSCorePropagationData: 0x0 = ( );
fSMORoleOwner: CN=NTDS Settings\0ADEL:<NTDS Settings objet GUID>,CN=\<hostname of last DC to host the
partition infrastructure role>,CN=Servers,CN=<active directory site
name>,CN=Sites,CN=Configuration,DC=contoso,DC=com;
instanceType: 0x4 = ( WRITE );
isCriticalSystemObject: TRUE;
name: Infrastructure;
objectCategory: CN=Infrastructure-Update,CN=Schema,CN=Configuration,DC=contoso,DC=com;
objectClass (2): top; infrastructureUpdate;
objectGUID: <object guid>;
showInAdvancedViewOnly: TRUE;
systemFlags: 0x8C000000 = ( DISALLOW_DELETE | DOMAIN_DISALLOW_RENAME | DOMAIN_DISALLOW_MOVE );
uSNChanged: <some USN #>;
uSNCreated: <some USN #>;
whenChanged: <date> <time>;
whenCreated: <date> <time>;
Où les éléments de distinction dans la sortie LDAP provenant de l’exemple de CONTOSO.COM domaine sont les
suivants :
1. fSMORoleOwner L’attribut contient la chaîne 0ADEL indiquant que le rôle propriétaire de l’objet Paramètres
DC a été supprimé.
2. L’attribut contient un GUID alpha-numérique de 32 caractères de l’objet fSMORoleOwner DCs NTDS
Paramètres propriétaire au format xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
3. Nom de la partition d’application DNS par défaut pour laquelle l’attribut est affecté à un dc avec un objet
fSMORoleOwner Paramètres NTDS supprimé. Dans ce cas, l’erreur fait référence à DomainDNSZones. Cette
même erreur peut également se produire pour la partition d’application ForestDNSZones.
Cause
L’erreur se produit lorsque le contrôleur de domaine rétrogradé ne peut pas répliquer les modifications
sortantes vers le dc qui possède le FSMO d’infrastructure ou le rôle opérationnel pour la partition référencé
dans l’erreur DCPROMO [ journal].
Plus précisément, la tentative de rétrogradation est abandonnée pour se protéger contre la perte de données.
Dans le cas des partitions d’application DNS, la rétrogradation est bloquée pour garantir que les données
suivantes sont répliquées :
enregistrements DNS en direct et supprimés
ACLS des enregistrements DNS
métadonnées, telles que les dates d’inscription et de suppression
Les chemins d’accès DN pour les partitions où l’erreur dans la section Symptômes peut se produire sont les
suivants :
CN=Infrastructures,DC=DomainDNSZones....
CN=Infrastructures,DC=ForestDNSZones....
Résolution
NOTE
Lorsque le maître d’infrastructure est affecté à un NTDSA supprimé sur une partition d’application DNS, comme
DomainDNSZones, il peut également être manquant pour la partition ForestDNSZones ou vice versa. Nous vous
recommandons de vérifier que les partitions DomainDNSZones et ForestDNSZones affectées aux contrôleurs de domaine
Windows Server 2003 ou ultérieurs en direct hébergeant le rôle et la partition DNS Server en question.
Pour résoudre ce problème, appliquez l’une des méthodes suivantes :

1. Permet d’affecter le chemin d’accès DN de l’attribut à un dc actif qui était un partenaire de réplication
direct du propriétaire du ADSIEDIT.MSC fsMORoleOwner rôle FSMO d’origine. Attendez ensuite que cette
modification soit répliquée de façon entrante vers le dc rétrogradé.
2. Exécutez le script dans la section Résolution de la KB949257 pour la partition en question.
3. Si le contrôleur de domaine en cours de rétrogradation ne peut pas répliquer les modifications entrantes
pour la partition d’annuaire en question, exécutez la commande pour rétrograder de force le contrôleur
de DCPROMO /FORCEREMOVAL domaine.
DCPromo tente de répliquer les modifications sortantes sur chaque NC détenu localement afin que les
modifications uniques ne sont pas perdues. Si les données sont stockées dans des zones DNS, DCPROMO tente
de répliquer le contenu des zones DNS vers le maître d’infrastructure pour la partition DNS en question.
Problème connexe :
KB949257 décrit un problème dans lequel la commande échoue lorsque le maître d’infrastructure pour une ou
plusieurs partitions d’application DNS est affecté à un ADPREP /RODCPREP NTDSA supprimé.
Déploiement et fonctionnement de domaines Active
Directory configurés à l’aide de noms DNS en une
seule partie
Cet article contient des informations sur le déploiement et le fonctionnement des domaines Active Directory
(AD) configurés à l’aide de noms DNS en une seule partie.
S’applique à : Windows Server 2008 R2 Service Pack 1, Windows Server 2012 R2, Windows Server 2016,
Windows Server 2019, Windows 10, version 1809
Résumé
Le fait de vouloir supprimer la configuration de domaine en une seule partie est une raison fréquente de
renommer un domaine. Les informations de compatibilité des applications de cet article s’appliquent à tous les
scénarios dans lesquels vous pouvez envisager de renommer un domaine.
Pour les raisons suivantes, la meilleure pratique consiste à créer des domaines Active Directory qui ont des
noms DNS complets :
Les noms DNS à une seule étiquette ne peuvent pas être enregistrés à l’aide d’un bureau
d’enregistrement Internet.
Les ordinateurs clients et les contrôleurs de domaine associés à des domaines en une seule partie
nécessitent une configuration supplémentaire pour enregistrer dynamiquement des enregistrements
DNS dans des zones DNS à étiquette unique.
Les ordinateurs clients et les contrôleurs de domaine peuvent nécessiter une configuration
supplémentaire pour résoudre les requêtes DNS dans les zones DNS à étiquette unique.
Certaines applications basées sur un serveur sont incompatibles avec les noms de domaine en une seule
partie. Il se peut que la prise en charge des applications n’existe pas dans la version initiale d’une
application ou qu’elle soit abandonnée dans une prochaine version.
La transition d’un nom de domaine DNS à une seule étiquette vers un nom DNS complet n’est pas triviale
et se compose de deux options. Migrez les utilisateurs, ordinateurs, groupes et autres états vers une
nouvelle forêt. Sinon, renommez le domaine existant. Certaines applications basées sur un serveur sont
incompatibles avec la fonctionnalité de changement de nom de domaine prise en charge dans Windows
Server 2003 et les contrôleurs de domaine plus nouveaux. Ces incompatibilités bloquent la fonctionnalité
de changement de nom de domaine ou rendent l’utilisation de la fonctionnalité de changement de nom
de domaine plus difficile lorsque vous essayez de renommer un nom DNS à une seule étiquette en nom
de domaine complet.
L’Assistant Installation d’Active Directory (Dcpromo.exe) dans Windows Server 2008 vous avertit contre la
création de domaines qui ont des noms DNS en une seule fois. Étant donné qu’il n’existe aucune raison
professionnelle ou technique de créer de nouveaux domaines qui ont des noms DNS en une seule partie,
l’Assistant Installation d’Active Directory dans Windows Server 2008 R2 bloque explicitement la création
de ces domaines.
Les produits suivants sont des exemples d’applications incompatibles avec le changement de nom de domaine :
Microsoft Exchange Server 2000
Microsoft Internet Security and Acceleration (ISA) Server 2004
Microsoft Live Communications Server 2005
Microsoft Operations Manager 2005
Microsoft SharePoint Portal Server 2003
Microsoft Systems Management Server (SMS) 2003
Microsoft Office Communications Server 2007
Microsoft Office Communications Server 2007 R2
Microsoft System Center Operations Manager 2007 SP1
Microsoft System Center Operations Manager 2007 R2
Microsoft Lync Server 2010
Microsoft Lync Server 2013
Les noms de domaine Active Directory les plus pratiques sont constitués d’un ou de plusieurs sous-domaines
associés à un domaine de niveau supérieur séparé par un point ( « . »). Voici quelques exemples :
contoso.com
corp.contoso.com
Les noms d’étiquette unique sont constitués d’un seul mot comme « contoso ».
Le domaine de niveau supérieur occupe l’étiquette la plus à droite dans un nom de domaine. Les domaines de
niveau supérieur courants sont les suivants :
.com
.net
.org
Domaines de niveau supérieur (ccTLD) de code pays à deux lettres tels que .nz
Les noms de domaine Active Directory doivent se composer d’au moins deux étiquettes pour le système
d’exploitation actuel et futur, ainsi que pour l’expérience et la fiabilité des applications.
Les requêtes de domaine de niveau supérieur non valides signalées par le comité de conseil sur la sécurité et la
stabilité de l’ICANN se trouvent dans les requêtes de domaine de niveau supérieur non valides au niveau racine
du système de noms de domaine.
Inscription des noms DNS auprès d’un bureau d’enregistrement

Internet
Nous vous recommandons d’inscrire des noms DNS pour les principaux espaces de noms DNS internes et
externes auprès d’un bureau d’enregistrement Internet. Ce qui inclut le domaine racine de la forêt d’une forêt
Active Directory, sauf si ces noms sont des sous-domaines de noms DNS enregistrés par le nom de votre
organisation (par exemple, le domaine racine de la forêt « corp.example.com » est un sous-domaine d’un «
example.com » interne. espace de noms.) Lorsque vous inscrivez vos noms DNS auprès d’un bureau
d’enregistrement Internet, cela permet aux serveurs DNS Internet de résoudre votre domaine maintenant ou à
un moment donné au cours de la durée de vie de votre forêt Active Directory. De plus, cette inscription permet
d’éviter les collisions de noms possibles entre d’autres organisations.
Symptômes possibles lorsque les clients ne peuvent pas enregistrer
dynamiquement des enregistrements DNS dans une zone de
recherche avant en une seule étiquette
Si vous utilisez un nom DNS en une seule étiquette dans votre environnement, les clients risquent de ne pas
pouvoir enregistrer dynamiquement les enregistrements DNS dans une zone de recherche avant en une seule
étiquette. Les symptômes spécifiques varient en fonction de la version de Microsoft Windows installée.
La liste suivante décrit les symptômes qui peuvent se produire :
Après avoir configuré Microsoft Windows pour un nom de domaine en une seule étiquette, tous les
serveurs qui ont le rôle de contrôleur de domaine risquent de ne pas pouvoir enregistrer les
enregistrements DNS. Le journal système du contrôleur de domaine peut régulièrement enregistrer des
avertissements NETLOGON 5781 semblables à l’exemple suivant :
NOTE
Le code d’état 0000232a est map pour le code d’erreur suivant :
DNS_ERROR_RCODE_SERVER_FAILURE
Les codes d’état et codes d’erreur supplémentaires suivants peuvent apparaître dans les fichiers journaux
tels que Netdiag.log :
Code d’erreur DNS : 0x0000251D = DNS_INFO_NO_RECORDS

DNS_ERROR_RCODE_ERROR
RCODE_SERVER_FAILURE
Windows ordinateurs configurés pour les mises à jour dynamiques DNS ne s’inscrivent pas dans un
domaine en une seule étiquette. Les événements d’avertissement qui ressemblent aux exemples suivants
sont enregistrés dans le journal système de l’ordinateur :
Comment permettre aux clients Windows de faire des requêtes et des

mises à jour dynamiques avec des zones DNS en une seule fois
Par défaut, Windows n’envoie pas de mises à jour aux domaines de niveau supérieur. Toutefois, vous pouvez
modifier ce comportement à l’aide de l’une des méthodes décrites dans cette section. Utilisez l’une des
méthodes suivantes pour permettre aux clients basés Windows de mettre à jour dynamiquement les zones DNS
en une seule partie.
En outre, sans modification, un membre de domaine Active Directory dans une forêt qui ne contient aucun
domaine avec des noms DNS en une seule partie n’utilise pas le service DNS Server pour localiser les
contrôleurs de domaine dans les domaines qui ont des noms DNS en une seule partie qui se trouve dans
d’autres forêts. L’accès client aux domaines qui ont des noms DNS en une seule partie échoue si la résolution de
noms NetBIOS n’est pas configurée correctement.
Méthode 1 : utiliser l’Éditeur du Registre
Configuration du localisateur de contrôleur de domaine pour Windows XP Professional et les versions
ultérieures de Windows
IMPORTANT
problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, veillez à
suivre ces étapes scrupuleusement. Pour une meilleure protection, sauvegardez le registre avant de le modifier.
Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations, voir Comment faire pour la back up
et restaurer le Registre dans Windows.
Sur un ordinateur Windows, un membre de domaine Active Directory nécessite une configuration
supplémentaire pour prendre en charge les noms DNS en une seule partie pour les domaines. Plus
précisément, le localisateur de contrôleur de domaine sur le membre de domaine Active Directory
n’utilise pas le service serveur DNS pour localiser les contrôleurs de domaine dans un domaine qui a un
nom DNS en une seule partie, sauf si ce membre de domaine Active Directory est joint à une forêt qui
contient au moins un domaine et que ce domaine possède un nom DNS en une seule partie.
Pour permettre à un membre de domaine Active Directory d’utiliser DNS pour localiser des contrôleurs
de domaine dans des domaines dont les noms DNS en une seule partie se trouve dans d’autres forêts,
1. Sélectionnez Démarrer , Exécuter , tapez regedit, puis sélectionnez OK .
3. Dans le volet d’informations, recherchez l’entrée AllowSingleLabelDnsDomain . Si l’entrée

AllowSingleLabelDnsDomain n’existe pas, suivez les étapes suivantes :
a. Dans le menu Édition , pointez sur Nouveau , puis sélectionnez Valeur DWORD .
b. Tapez AllowSingleLabelDnsDomain comme nom d’entrée, puis appuyez sur Entrée .
4. Double-cliquez sur l’entrée AllowSingleLabelDnsDomain .
5. Dans la zone Données de la valeur, tapez 1, puis sélectionnez OK .
Configuration du client DNS
IMPORTANT
Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations, voir Comment faire pour la back up
et restaurer le Registre dans Windows.
Les membres de domaine Active Directory et les contrôleurs de domaine qui se trouveraient dans un
domaine qui possède un nom DNS en une seule partie doivent généralement enregistrer
dynamiquement les enregistrements DNS dans une zone DNS à étiquette unique qui correspond au nom
DNS de ce domaine. Si un domaine racine de forêt Active Directory possède un nom DNS en une seule
partie, tous les contrôleurs de domaine de cette forêt doivent généralement enregistrer dynamiquement
les enregistrements DNS dans une zone DNS à étiquette unique qui correspond au nom DNS de la racine
de la forêt.
Par défaut, les ordinateurs clients DNS basés sur Windows ne tentent pas de mettre à jour
dynamiquement la zone racine « . » ou des zones DNS à étiquette unique. Pour permettre Windows
ordinateurs clients DNS basés sur un seul ordinateur d’essayer les mises à jour dynamiques d’une zone
DNS en une seule partie, suivez les étapes suivantes :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DnsCache\Parameters
3. Dans le volet d’informations, recherchez l’entrée UpdateTopLevelDomainZones . Si l’entrée

UpdateTopLevelDomainZones n’existe pas, suivez les étapes suivantes :
a. Dans le menu Édition , pointez sur Nouveau , puis sélectionnez Valeur DWORD .
b. Tapez UpdateTopLevelDomainZones comme nom d’entrée, puis appuyez sur Entrée .
4. Double-cliquez sur l’entrée UpdateTopLevelDomainZones .
5. Dans la zone Données de la valeur, tapez 1, puis sélectionnez OK .
Ces modifications de configuration doivent être appliquées à tous les contrôleurs de domaine et
membres d’un domaine qui ont des noms DNS en une seule partie. Si un domaine dont le nom de
domaine est en une seule partie est une racine de forêt, ces modifications de configuration doivent être
appliquées à tous les contrôleurs de domaine dans la forêt, sauf si les zones distinctes _msdcs.
ForestName, _sites. ForestName, _tcp. ForestName, and_udp. ForestName est délégué à partir de la zone
ForestName .
Pour que les modifications prennent effet, redémarrez les ordinateurs sur lequel vous avez modifié les
entrées de Registre.
NOTE
Pour Windows Server 2003 et les versions ultérieures, l’entrée UpdateTopLevelDomainZones a été déplacée
vers la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
Sur un contrôleur de domaine Microsoft Windows 2000 SP4, l’ordinateur signale l’erreur d’inscription de nom
suivante dans le journal des événements système si le paramètre UpdateTopLevelDomainZones n’est pas activé
:
Sur un contrôleur Windows 2000 SP4, vous devez redémarrer votre ordinateur après avoir ajouté le paramètre
UpdateTopLevelDomainZones.
Méthode 2 : utiliser une stratégie de groupe

Utilisez la stratégie de groupe pour activer la stratégie Mettre à jour les zones de domaine de niveau supérieur
et l’emplacement des DCS hébergeant un domaine avec une stratégie de nom DNS en une seule partie, comme
indiqué dans le tableau suivant sous l’emplacement du dossier sur le conteneur de domaine racine dans
Utilisateurs et ordinateurs, ou sur toutes les unités d’organisation qui hébergent des comptes d’ordinateur pour
les ordinateurs membres, et pour les contrôleurs de domaine dans le domaine.
ST RAT ÉGIE EM P L A C EM EN T DU DO SSIER
Mettre à jour les zones de domaine de niveau supérieur Configuration ordinateur\Modèles

d’administration\Réseau\Client DNS
Emplacement des DCS hébergeant un domaine avec un nom Configuration ordinateur\Modèles

DNS en une seule partie d’administration\Système\Net Logon\Dc Locator DNS
Records
NOTE
Ces stratégies sont uniquement Windows ordinateurs basés sur Server 2003 et sur Windows ordinateurs XP.
Pour activer ces stratégies, suivez les étapes suivantes sur le conteneur de domaine racine :
1. Sélectionnez Démarrer , Exécuter , tapez gpedit.msc, puis sélectionnez OK .
2. Sous Stratégie de l’ordinateur local , développez Configuration de l’ordinateur .
3. Développez les modèles d’administration .
4. Activez la stratégie Mettre à jour les zones de domaine de niveau supérieur. Pour ce faire, procédez comme
suit :
a. Développez le réseau .
b. Sélectionnez Client DNS .
c. Dans le volet d’informations, double-cliquez sur Mettre à jour les zones de domaine de niveau
supérieur .
d. Sélectionnez Activé .
e. Sélectionnez Apply (Appliquer), puis OK .
5. Activez l’emplacement des DCS hébergeant un domaine avec une stratégie de nom DNS en une seule partie.
a. Développez Système .
b. Développez Net Logon .
c. Sélectionnez Enregistrements DNS DC Locator .
d. Dans le volet d’informations, double-cliquez sur Emplacement des DCS hébergeant un domaine avec
un nom DNS en une seule par tie .
e. Sélectionnez Activé .
f. Sélectionnez Apply (Appliquer), puis OK .
6. Quittez la stratégie de groupe.
Sur Windows serveurs DNS basés sur Server 2003 et versions ultérieures, assurez-vous que les serveurs
racines ne sont pas créés involontairement.
Sur Windows serveurs DNS basés sur 2 000, vous de devez peut-être supprimer la zone racine « . » pour que les
enregistrements DNS sont correctement déclarés. La zone racine est automatiquement créée lorsque le service
serveur DNS est installé, car le service serveur DNS ne peut pas atteindre les indications racine. Ce problème a
été corrigé dans les versions ultérieures de Windows.
Les serveurs racine peuvent être créés par l’Assistant DCpromo. Si la zone « . » existe, un serveur racine a été
créé. Pour que la résolution de noms fonctionne correctement, vous de devez peut-être supprimer cette zone.
Paramètres de stratégie DNS nouveaux et modifiés pour Windows

Server 2003 et versions ultérieures
La stratégie Mettre à jour les zones de domaine de niveau supérieur
Si cette stratégie est spécifiée, elle crée une REG_DWORD UpdateTopLevelDomainZones entrée sous la sous-clé
de Registre suivante : HKLM\Software\Policies\Microsoft\Windows NT\DNSClient
Les valeurs d’entrée suivantes sont les suivantes UpdateTopLevelDomainZones : - Activé (0x1). Un 0x1
signifie que les ordinateurs peuvent essayer de mettre à jour les zones TopLevelDomain. Autrement dit,
UpdateTopLevelDomainZones si le paramètre est activé, les ordinateurs sur lesquels cette stratégie est
appliquée envoient des mises à jour dynamiques à toute zone faisant autorité pour les enregistrements
de ressources que l’ordinateur doit mettre à jour, à l’exception de la zone racine. - Désactivé (0x0). Un 0x0
signifie que les ordinateurs ne sont pas autorisés à essayer de mettre à jour les zones TopLevelDomain.
Autrement dit, si ce paramètre est désactivé, les ordinateurs sur lesquels cette stratégie est appliquée
n’envoient pas de mises à jour dynamiques à la zone racine ou aux zones de domaine de niveau
supérieur faisant autorité pour les enregistrements de ressources que l’ordinateur doit mettre à jour. Si ce
paramètre n’est pas configuré, la stratégie n’est appliquée à aucun ordinateur et les ordinateurs utilisent
leur configuration locale.
Stratégie Enregistrer les enregistrements PTR
Une nouvelle valeur possible, 0x2, REG_DWORD RegisterReverseLookup de l’entrée a été ajoutée sous la sous-
clé de Registre suivante :
HKLM\Software\Policies\Microsoft\Windows NT\DNSClient
Les valeurs d’entrée suivantes sont les suivantes RegisterReverseLookup : - 0x2. Inscrivez-vous
uniquement si l’enregistrement « A » réussit. Les ordinateurs tentent d’implémenter l’inscription des
enregistrements de ressource PTR uniquement s’ils ont réussi à inscrire les enregistrements de ressource
« A » correspondants. - 0x1. Inscrivez-vous. Les ordinateurs tentent d’implémenter l’inscription des
enregistrements de ressource PTR quelle que soit la réussite de l’inscription des enregistrements « A ». -
0x0. Ne pas s’inscrire. Les ordinateurs n’essaient jamais d’implémenter l’inscription des enregistrements
de ressource PTR.
References
Planification d’espaces de noms DNS
Impossible de sélectionner le rôle serveur DNS lors de l’ajout d’un contrôleur de domaine à un domaine
Active Directory existant
Guide ADMT : Migration et réorganisation des domaines Active Directory
Guide de l’outil de migration Active Directory (ADMT) : migration et réorganisation des domaines Active
Directory
Le changement de nom du contrôleur de domaine
ne renomme pas tous les objets SYSVOL AD DFSR
Cet article fournit des résolutions pour résoudre le problème où le changement de nom du contrôleur de
domaine ne renomme pas tous les objets AD DFSR. SYSVOL
Symptômes
Le conteneur MsDFSR-Member SYSVOL utilisé par la réplication DFS (DFSR) n’est pas mis à jour lorsqu’un
contrôleur de domaine est renommé. Par exemple, lorsque vous renommez un dc nommé « OldName » en un
dc nommé « NewName », l’objet suivant n’est pas renommé :
CN=OLDNAME,CN=Topology,CN=Domain System Volume,CN=DFSR-
Globalsettings,CN=System,DC=contoso,DC=com
La réplication de fichiers continuera de fonctionner correctement et normalement, et le dossier sysvol ne sera
pas affecté pour le traitement ou les scripts de stratégie de groupe.
Toutefois, le CN ne sera pas mis à jour ou supprimé lors des rétrogradations ultérieures ou via le nettoyage des
métadonnées. Cela laisse indéfiniment les objets de topologie DFSR orphelins dans le domaine Active Directory.
En outre, si un nouveau contrôleur de domaine, avec l’ancien nom du contrôleur de domaine précédemment
renommé, doit être promu dans le domaine, il prend le contrôle de l’ancien objet et arrête temporairement la
réplication sur le contrôleur de domaine renommé jusqu’à ce qu’un administrateur recrée manuellement un
nouvel objet pour le contrôleur de domaine renommé à l’aide d’ADSIEDIT. MSC.
Cause
Un défaut de code dans le processus de changement de nom du contrôleur de domaine.
Résolution
Solution de contournement 1 :
Avant d'DCPROMO.EXE, renommez les ordinateurs au nom prévu final à l’aide de l’applet ou de la NETDOM.EXE
du panneau de NETDOM.EXE.
Lorsque vous renommez un dc existant, rétrogradez-le d’abord de manière DCPROMO.EXE, renommez-le, puis
faites-le revenir en dc.
Utilisez ADSIEDIT. MSC pour corriger les objets AD manuellement, en suivant les étapes suivantes :
1. Connectez-vous en tant qu’administrateur de domaine sur un dc dans le domaine concerné.
2. Démarrez ADSIEDIT. MSC.
3. Connecter au contexte d’attribution de noms par défaut.
4. Accédez au conteneur de topologie DFSR. Par exemple, dans un domaine contoso.com appelé, il s’agit des
suivants :
CN=Topology,CN=Domain System Volume,CN=DFSR-Globalsettings,CN=System,DC=contoso,DC=com
5. Renommez l’objet CN membre msDFSR qui a l’ancien nom d’ordinateur et donnez-lui le nouveau nom
d’ordinateur.
Was: CN=OLDNAME,CN=Topology,CN=Domain System Volume,CN=DFSR-
Modification vers : CN=NEWNAME,CN=Topology,CN=Domain System Volume,CN=DFSR-
S’applique à ».
Les contrôleurs de domaine ne rétrogradent pas
normalement lorsque vous utilisez l’Assistant
Installation d’Active Directory pour forcer la
rétrogradation
Cet article fournit une solution de contournement pour un problème dans lequel les contrôleurs de domaine ne
sont pas rétrogradés lorsque vous utilisez l’Assistant Installation d’Active Directory (Dcpromo.exe) pour forcer la
rétrogradation.
Symptômes
Les contrôleurs de domaine Microsoft Windows 2000 ou Microsoft Windows Server 2003 peuvent ne pas
rétrograder normalement à l’aide de l’Assistant Installation d’Active Directory (Dcpromo.exe).
Cause
Ce comportement peut se produire en cas d’échec d’une dépendance ou d’une opération requise. Il s’agit
notamment de la connectivité réseau, de la résolution de noms, de l’authentification, de la réplication du service
d’annuaire Active Directory ou de l’emplacement d’un objet critique dans Active Directory.
Résolution
Pour résoudre ce problème, déterminez ce qui empêche la rétrogradation normale du contrôleur de domaine
Windows 2000 ou Windows Server 2003, puis essayez de rétrograder le contrôleur de domaine à l’aide de
l’Assistant Installation d’Active Directory à nouveau.
NOTE
Pour Windows Server 2008, le mode de restauration des services d’annuaire (DSRM) reste inchangé par rapport à
Windows Server 2003, à une exception près. Dans Windows Server 2008, vous pouvez exécuter la commande pour forcer
la suppression d’AD DS d’un contrôleur de domaine démarré dans la gestion des données de gestion des données, tout
comme dans l’état arrêté dcpromo/forceremoval AD DS. Un contrôleur de domaine doit toujours être démarré dans
DSRM pour restaurer les données d’état système à partir d’une sauvegarde. Pour plus d’informations sur la façon de faire,
voir le Guide pas à pas de Restartable AD DS.
Si vous ne pouvez pas résoudre le comportement, vous pouvez utiliser les solutions de contournement
suivantes pour effectuer une rétrogradation forcée du contrôleur de domaine afin de conserver l’installation du
système d’exploitation et des applications qui y sont présentes.
WARNING
Avant d’utiliser l’une des solutions de contournement suivantes, assurez-vous que vous pouvez démarrer correctement
en mode restauration des services d’annuaire. Sinon, vous ne pourrez pas vous connecter après avoir rétrogradé de force
l’ordinateur. Si vous ne vous souvenez pas du mot de passe du mode restauration des services d’annuaire, vous pouvez
réinitialiser le mot de passe à l’aide de l’utilitaire Setpwd.exe situé dans le Winnt\System32 dossier. Dans Windows Server
2003, la fonctionnalité de l’utilitaire Setpwd.exe a été intégrée à la commande Définir le mot de passe DSRM de l’outil
NTDSUTIL.
Windows 2000 contrôleurs de domaine

1. Installez le correctif logiciel Q332199 sur un contrôleur de domaine Windows 2000 qui exécute le Service
Pack 2 (SP2) ou une version ultérieure, ou installez Windows 2000 Service Pack 4 (SP4). SP2 et versions
ultérieures prendre en charge la rétrogradation forcée. Ensuite, redémarrez votre ordinateur.
2. Cliquez sur Démarrer, cliquez sur Exécuter, puis tapez la commande : dcpromo /forceremoval .
3. Cliquez sur OK .
4. Dans la page Bienvenue dans l’Assistant Installation d’Active Director y, cliquez sur Suivant.
5. Si l’ordinateur que vous supprimez est un serveur de catalogue global, cliquez sur OK dans la fenêtre de
message.
NOTE
Promouvoir des catalogues globaux supplémentaires dans la forêt ou dans le site si le contrôleur de domaine que
vous rétrogradez est un serveur de catalogue global, si nécessaire.
6. Dans la page Supprimer Active Director y, assurez-vous que ce serveur est le dernier contrôleur de
domaine dans la case à cocher du domaine, puis cliquez sur Suivant .
7. Dans la page Informations d’identification réseau, tapez le nom, le mot de passe et le nom de
domaine d’un compte d’utilisateur avec des informations d’identification d’administrateur d’entreprise
dans la forêt, puis cliquez sur Suivant .
8. Dans Mot de passe de l’administrateur, tapez le mot de passe et le mot de passe confirmé que vous
souhaitez affecter au compte Administrateur de la base de données SAM locale, puis cliquez sur Suivant .
9. Dans la page Résumé, cliquez sur Suivant.
10. Effectuer un nettoyage des métadonnées pour le contrôleur de domaine rétrogradé sur un contrôleur de
domaine survivant dans la forêt.
Si vous avez supprimé un domaine de la forêt à l’aide de la commande de domaine sélectionnée dans Ntdsutil,
vérifiez que tous les contrôleurs de domaine et les serveurs de catalogue global de la forêt ont supprimé tous
les objets et les références au domaine que vous avez supprimés avant de promouvoir un nouveau domaine
dans la même forêt avec le même nom de domaine. Des outils tels que Replmon.exe ou Repadmin.exe de
Windows 2000 Support Tools peuvent vous aider à déterminer si une réplication de bout en bout s’est produite.
Windows 2000 SP3 et les serveurs de catalogue global précédents sont sensiblement plus lents à supprimer des
objets et des contextes d’attribution de noms qu’Windows Server 2003.
Windows Contrôleurs de domaine Server 2003
1. Par défaut, Windows de domaine Server 2003 prendre en charge la rétrogradation forcée. Cliquez sur
Démarrer, cliquez sur Exécuter, puis tapez la commande : dcpromo /forceremoval .
2. Cliquez sur OK .
3. Dans la page Bienvenue dans l’Assistant Installation d’Active Director y, cliquez sur Suivant.
4. Dans la page Forcer la suppression d’Active Director y, cliquez sur Suivant .
5. Dans Mot de passe de l’administrateur, tapez le mot de passe et le mot de passe confirmé que vous
souhaitez affecter au compte Administrateur de la base de données SAM locale, puis cliquez sur Suivant .
6. En résumé, cliquez sur Suivant .
7. Effectuer un nettoyage des métadonnées pour le contrôleur de domaine rétrogradé sur un contrôleur de
domaine survivant dans la forêt.
Si vous avez supprimé un domaine de la forêt à l’aide de la commande de domaine sélectionnée dans Ntdsutil,
vérifiez que tous les contrôleurs de domaine et les serveurs de catalogue global de la forêt ont supprimé tous
les objets et les références au domaine que vous avez supprimés avant de promouvoir un nouveau domaine
dans la même forêt avec le même nom de domaine. Windows 2000 Service Pack 3 (SP3) et les serveurs de
catalogue global précédents sont sensiblement plus lents à supprimer des objets et des contextes d’attribution
de noms qu’Windows Server 2003.
Si les entrées de contrôle d’accès aux ressources sur l’ordinateur dont vous avez supprimé Active Directory
étaient basées sur des groupes locaux de domaine, ces autorisations devront peut-être être reconfigurées, car
ces groupes ne seront pas disponibles pour les serveurs membres ou autonomes. Si vous envisagez d’installer
Active Directory sur l’ordinateur pour en faire un contrôleur de domaine dans le domaine d’origine, vous n’avez
plus besoin de configurer de listes de contrôle d’accès. Si vous préférez laisser l’ordinateur en tant que membre
ou serveur autonome, toutes les autorisations basées sur des groupes locaux de domaine doivent être traduites
ou remplacées.
Windows Améliorations de Server 2003 Service Pack 1
Windows Server 2003 SP1 améliore le dcpromo /forceremoval processus. Lorsqu’il est exécuté, une vérification
est réalisée pour déterminer si le contrôleur de domaine héberge un rôle maître d’opérations, s’il s’agit d’un
serveur DNS (Domain Name System) ou d’un serveur de catalogue dcpromo /forceremoval global. Pour chacun
de ces rôles, l’administrateur reçoit un avertissement indépendant qui l’avertit de prendre les mesures
appropriées.
Si le contrôleur de domaine ne peut pas démarrer en mode normal
IMPORTANT
IMPORTANT
Suivez ces étapes uniquement en dernier recours si le contrôleur de domaine ne peut pas démarrer en mode normal.
Pour supprimer Active Directory d’un contrôleur de domaine, suivez les étapes suivantes :
1. Redémarrez l’ordinateur, puis appuyez sur F8 pour afficher Windows menu Options avancées 2000.
2. Choisissez le mode restauration des ser vices d’annuaire, appuyez sur Entrée, puis appuyez à
nouveau sur Entrée pour continuer le redémarrage.
3. Modifiez l’entrée ProductType dans le Registre. Pour cela, procédez comme suit :
a. Cliquez sur Démarrer et sur Exécuter , tapez regedit, puis cliquez sur OK .
b. Recherchez la sous-clé de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions
Registre.
c. Dans le volet droit, double-cliquez sur ProductType .
d. Tapez ServerNT dans la zone Données de la valeur, puis cliquez sur OK.
NOTE
Si cette valeur n’est pas définie correctement ou est mal orthographié, vous pouvez recevoir le message
d’erreur suivant : Processus système - Violation de licence : le système a détecté une falsification avec votre
type de produit enregistré. Il s’agit d’une violation de votre licence logicielle. La falsification du type de
produit n’est pas autorisée.
e. Quittez l’Éditeur du Registre.

5. Connectez-vous avec le compte d’administrateur et le mot de passe utilisés pour le mode réparation du
L’ordinateur se comporte comme un serveur membre. Toutefois, il reste des fichiers et des entrées de
Registre restants sur l’ordinateur qui sont associés au contrôleur de domaine.
6. Démarrez l’Éditeur du Registre et recherchez l’entrée de
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters Registre.
S’il existe une entrée pour Src Root Domain Sr v, cliquez avec le bouton droit sur la valeur, puis cliquez
sur Supprimer . Cette valeur doit être supprimée afin que le contrôleur de domaine se voit comme le
seul contrôleur de domaine dans le domaine après la promotion.
IMPORTANT
L’étape ci-dessus est critique. Sans cela, la re-promotion dans la forêt AD temporaire ne se terminera pas et vous
ne pourrez pas vous connecter au contrôleur de domaine.
7. Supprimez les fichiers restants et les entrées de Registre. Pour cela, procédez comme suit :
a. Démarrez l’Assistant Installation d’Active Directory.
b. Installez Active Directory pour faire de l’ordinateur un contrôleur de domaine pour un nouveau
domaine temporaire, tel que psstemp.deleteme.
NOTE
Veillez à faire de l’ordinateur un contrôleur de domaine dans une autre forêt.
c. Après avoir installé Active Directory, démarrez à nouveau l’Assistant Installation d’Active Directory,
puis supprimez Active Directory du contrôleur de domaine.
8. Après avoir supprimé Active Directory d’un contrôleur de domaine, supprimez les métadonnées qui
restent dans le domaine. Pour plus d’informations sur la suppression de ces métadonnées, voir Comment
supprimer des données dans Active Directory après une rétrogradation de contrôleur de domaine
infructueuse.
État
Microsoft a testé et prend en charge la rétrogradation forcée des contrôleurs de domaine qui exécutent
Windows 2000 ou Windows Server 2003.
L’Assistant Installation d’Active Directory crée des contrôleurs de domaine Active Directory sur Windows 2000 et
Windows Server 2003. Les opérations effectuées par l’Assistant Installation d’Active Directory incluent
l’installation de nouveaux services, les modifications apportées aux valeurs de démarrage des services existants
et la transition vers Active Directory en tant que domaine de sécurité et d’authentification.
Avec la rétrogradation forcée, un administrateur de domaine peut forcer la suppression d’Active Directory et la
suppression des modifications système localement détenues sans avoir à contacter ou répliquer les
modifications localement apportées à un autre contrôleur de domaine dans la forêt.
Étant donné que la rétrogradation forcée entraîne la perte de toutes les modifications localement détenues,
utilisez-la uniquement en dernier recours dans les domaines de production ou de test. Vous pouvez rétrograder
les contrôleurs de domaine de force lorsque la connectivité, la résolution de noms, l’authentification ou les
dépendances du moteur de réplication ne peuvent pas être résolues afin que la rétrogradation normale puisse
être effectuée. Les scénarios valides pour les rétrogradations forcées sont les suivants :
Aucun contrôleur de domaine n’est actuellement disponible dans le domaine parent lorsque vous essayez
de rétrograder le dernier contrôleur de domaine dans un domaine enfant immédiat.
L’Assistant Installation d’Active Directory ne peut pas se terminer car il existe une dépendance de nom,
d’authentification, de moteur de réplication ou d’objet Active Directory que vous ne pouvez pas résoudre
après avoir effectué un dépannage détaillé.
Un contrôleur de domaine n’a pas répliqué les modifications Active Directory entrantes dans la durée de
vie de Tombstone (la durée de vie de Tombstone par défaut est de 60 jours) en jours pour un ou plusieurs
contextes d’attribution de noms.
IMPORTANT
Ne récupérez pas ces contrôleurs de domaine, sauf s’ils sont la seule chance de récupération pour un domaine
particulier.
Le temps ne permet pas de dépanner plus en détail, car vous devez immédiatement mettre en service le
contrôleur de domaine. Les rétrogradations forcées peuvent être utiles dans les environnements de
laboratoire et de salle de classe où vous pouvez supprimer des contrôleurs de domaine des domaines
existants, mais vous n’avez pas besoin de rétrograder chaque contrôleur de domaine en série.
Si vous forcez la rétrogradation d’un contrôleur de domaine, vous perdrez toutes les modifications uniques qui
résident dans Active Directory du contrôleur de domaine que vous rétrogradez de force. Cela inclut l’ajout, la
suppression ou la modification d’utilisateurs, d’ordinateurs, de groupes, de relations d’confiance et de stratégie
de groupe ou de configuration Active Directory qui n’ont pas été répliqués avant l’utilisation de la
dcpromo /forceremoval commande. En outre, vous perdrez les modifications apportées à l’un des attributs de
ces objets, tels que les mots de passe pour les utilisateurs, les ordinateurs et les relations d’confiance et
l’appartenance à un groupe.
Toutefois, si vous forcez la rétrogradation d’un contrôleur de domaine, vous renvoyez le système d’exploitation à
un état identique à celui de la rétrogradation réussie du dernier contrôleur de domaine dans un domaine
(valeurs de début de service, services installés, utilisation d’un sam basé sur le Registre pour la base de données
de comptes, l’ordinateur est membre d’un groupe de travail). Les programmes installés sur le contrôleur de
domaine rétrogradé restent installés.
Le journal des événements système identifie les contrôleurs de domaine rétrogradés Windows 2000 et les
instances de l’opération par L’ID d’événement dcpromo /forceremoval 29234. Par exemple : le journal des
événements système identifie les contrôleurs de domaine Windows Server 2003 rétrogradés de force par l’ID
d’événement 29239. Par exemple : après avoir utilisé la commande, les métadonnées de l’ordinateur rétrogradé
ne sont pas supprimées sur les dcpromo /forceremoval contrôleurs de domaine existants. Pour plus
d’informations, voir Nettoyer les métadonnéesdu serveur du contrôleur de domaine Active Directory.
Voici les éléments que vous devez traiter, le cas échéant, après avoir rétrogradé de force un contrôleur de
domaine :
1. Supprimez le compte d’ordinateur du domaine.
2. Vérifiez que les enregistrements DNS, tels que les enregistrements A, CNAME et SRV, sont supprimés et
supprimez-les s’ils sont présents.
3. Vérifiez que les objets membres FRS (FRS et DFS) sont supprimés et supprimez-les s’ils sont présents.
4. Si l’ordinateur rétrogradé est membre d’un groupe de sécurité, supprimez-le de ces groupes.
5. Supprimez toutes les références DFS au serveur rétrogradé, telles que les liens ou les réplicas racines.
6. Un contrôleur de domaine survivant doit saisir tous les rôles maîtres d’opérations, également appelés
opérations maîtres unique flexibles ou FSMO, qui étaient précédemment détenus par le contrôleur de
domaine rétrogradé de force. Pour plus d’informations, voir Transférer ou saisir des rôles FSMO dans les
services de domaine Active Directory.
7. Si le contrôleur de domaine que vous rétrogradez est un serveur DNS ou un serveur de catalogue global,
vous devez créer un serveur GC ou DNS pour satisfaire l’équilibrage de charge, la tolérance de pannes et les
paramètres de configuration dans la forêt.
8. Lorsque vous utilisez la commande de serveur sélectionnée supprimer dans NTDSUTIL, l’objet NTDSDSA,
l’objet parent des connexions entrantes au contrôleur de domaine que vous avez rétrogradé de force, est
supprimé. La commande ne supprime pas les objets serveur parent qui apparaissent dans le logiciel en ligne
Sites et services. Utilisez le logiciel en ligne MMC Sites et services Active Directory pour supprimer l’objet
serveur si le contrôleur de domaine n’est pas promu dans la forêt avec le même nom d’ordinateur.
DCDIAG.EXE erreurs attendues /E ou /A ou /C
Cet article vous aide à corriger les erreurs qui se produisent lorsque vous exécutez DCDIAG.EXE /E /A ou des
/C commandes.

Symptômes
Vous administrez un environnement AD. Il peut y avoir une combinaison de DCS Windows Server 2003,
Windows Server 2003 R2, Windows Server 2008 et Windows Server 2008 R2.
Lorsque vous exécutez (ou ) sur DCDIAG.EXE /E /A Windows Server 2008 ou Windows Server 2008 R2 (inclus
avec les systèmes d’exploitation), les erreurs suivantes s’Windows sur tous les /C DCS Windows Server 2003 :
Test de démarrage : Services

Type de service non valide : RpcSs sur DCDIAG-2003, valeur actuelle
WIN32_OWN_PROCESS valeur attendue WIN32_SHARE_PROCESS
......................... Échec des services de test de DCDIAG-2003
Lors de l’exécution (ou ) sur DCDIAG.EXE /E /A Windows Server 2008 ou Windows Server 2008 R2 (inclus avec
les systèmes d’exploitation), vous voyez les erreurs suivantes sur tous les PC /C Win2008 et Win2008 R2 :
Test de début : FrsEvent

Service de réplication de fichiers du journal des événements sur le serveur
dcdiag-2008.margiestravel.com n’a pas pu être interrogé, erreur 0x6ba
« Le serveur RPC n’est pas disponible. »
......................... échec du test FrsEvent de dcdiag-2008
Test de début : DFSREvent

Réplication DFS du journal des événements sur le serveur
dcdiag-2008r2.margiestravel.com n’a pas pu être interrogé, erreur 0x6ba
......................... Échec du test DFSREvent de dcdiag-2008r2
Test de début : KccEvent

Service d’annuaire des journaux d’événements sur le serveur
......................... Échec du test KccEvent de dcdiag-2008
Test de début : SystemLog

Système du journal des événements sur le serveur
......................... Échec du test systemLog de dcdiag-2008
Lors de DCDIAG.EXE /E l’exécution (ou /A ou /C) sur Windows Server 2003 (inclus dans l’installation hors bande
des outils de support) :
Aucune erreur n’est consignée pour les DCS, quel que soit le système d’exploitation.
Lors de l’exécution (qui inclut) sur DCDIAG.EXE /C /test:verifyenterprisereferences Windows Server 2008 ou
Windows Server 2008 R2, et que le mode fonctionnel du domaine est Windows Server 2008 ou supérieur, et
que FRS est toujours utilisé pour répliquer SYSVOL, vous voyez les erreurs suivantes :
Test de début : VerifyEnterpriseReferences

Les problèmes suivants ont été trouvés lors de la vérification de diverses références DN importantes. Notez
que ces problèmes
peut être signalé en raison de la latence dans la réplication. Suivez donc pour résoudre les problèmes
suivants, uniquement si
le même problème est signalé sur tous les DCS pour un domaine donné ou si le problème persiste après la
réplication
temps raisonnable pour répliquer les modifications.
[1] Problème : valeur attendue manquante
Objet de base : CN=SRV-01,OU=Domain Controllers,DC=margiestravel,DC=com
Description de l’objet de base : « Objet compte DC »
Nom d’attribut de l’objet value : msDFSR-ComputerReferenceBL
Description de l’objet Value : « Objet membre SYSVOL FRS »
Action recommandée : voir l’article de la Base de connaissances : Q312862
[2] Problème : valeur attendue manquante
Objet de base : CN=SRV-02,OU=Domain Controllers,DC=margiestravel,DC=com
Description de l’objet de base : « Objet compte DC »
Nom d’attribut de l’objet value : msDFSR-ComputerReferenceBL
Description de l’objet Value : « Objet membre SYSVOL FRS »
Action recommandée : voir l’article de la Base de connaissances : Q312862
Erreur LDAP 0x20 (32) - Aucun objet de ce type.
......................... Échec du test SRV-01 VerifyEnterpriseReferences
Lors de l’exécution (qui inclut) et que vous spécifiez sur DCDIAG.EXE /C /test:outboundsecurechannels Windows
Server /testdomain:<your trusted domain> 2008 ou sur Windows Server 2008 R2, vous voyez les erreurs
suivantes :
Serveur de test : Default-First-Site-Name\SRV-01

Test de début : OutboundSecureChannels
[SRV-01] N’a pas d’objet de confiance de niveau bas pour [contoso.com]
[SRV-01] N’a pas d’objet d’confiance de niveau contoso.com]
[SRV-02] N’a pas d’objet de confiance de niveau bas pour [contoso.com]
[SRV-02] N’a pas d’objet d’confiance de niveau contoso.com]
......................... Échec du test outboundSecureChannels de SRV-01
Cause
Tous ces comportements sont attendus.
Les versions Windows Server 2008/200R2 de DCDIAG sont conçues pour tester RPCSS pour le
paramètre de processus partagé Windows Server 2008 , et non le paramètre de processus isolé
précédent utilisé dans Windows Server 2003 et les systèmes d’exploitation plus anciens. L’outil ne fait pas
la distinction entre les services OS pour ce service.
Les versions Windows Server 2008/200R2 de DCDIAG supposent qu’un niveau fonctionnel de domaine
Windows Server 2008 signifie que les DCS répliquent SYSVOL avec DFSR.
Les versions Windows Server 2008/200R2 de DCDIAG ne testent pas correctement l’état d’confiance
Windows Server 2008/2008 R2 n’autorise pas la connectivité à distance au journal des événements en
fonction des règles de pare-feu par défaut.
La version Windows Server 2003 de DCDIAG ne signale pas d’erreur si elle ne peut pas se connecter au
journal des événements . Il signale uniquement s’il se connecte et trouve des erreurs.
La Windows Server 2003 de DCDIAG ne teste pas la configuration du service RPCSS.
Résolution
Il existe plusieurs solutions de contournement à ces problèmes :
Ignorez toutes ces erreurs lors de l’exécution de DCDIAG.
Pour arrêter les erreurs liées au journal des événements, activez les règles de pare-feu entrant intégrées
sur les DCS afin que les journaux des événements soient accessibles à distance :
Gestion des journaux des événements distants (NP-In) Gestion des journaux
d’événements distants (RPC) Gestion des journaux d’événements distants (RPC-EPMAP)
Pour ce faire, vous pouvez utiliser le logiciel enfichable « pare-feu Windows avec fonctions avancées
de sécurité »**(WF.MSC),** à l’aide de la stratégie de groupe de pare-feu (Configuration
ordinateur\ Stratégies\ Windows Paramètres\ Sécurité Paramètres\ Windows Pare-feu
avec fonctions avancées de sécurité ) ou à l’aide de NETSH.EXE ADVFIREWALL .
Pour arrêter l’erreur de service RPCSS, vous pouvez refuser le test avec /SKIP:SERVICES . Il existe des
réserves à ce sujet, voir Plus d’informations. Il est préférable d’ignorer complètement cette erreur
spécifique lorsqu’elle est renvoyée par des DCS Win2003.
Il est normal et normal que le type de comportement de ce service soit 0x10 (isolé) sur Windows Server
2003 et 0x20 (partagé) sur Windows Server 2008 et les ultérieures. Ne la modifiez pas en fonction de ce
que dit DCDIAG, sauf si vous exécutez la version de DCDIAG qui est avec ce système d’exploitation. Entre
Windows Server 2003 et Windows Server 2008, le comportement a changé pour le service RPC, mais il
n’y avait pas encore de partage dans ce processus svchost.exe. Dans Windows Server 2008 R2, le
nouveau service RPCEptMapper a été ajouté à ce processus svchost partagé. Vous pouvez voir qui
lancerait dans ce même processus en cherchant cette valeur dans les clés de Registre de service :
%systemroot%\system32\svchost.exe -k RPCSS.
Ne modifiez pas le type de service sur Windows Server 2003 pour arrêter l’erreur. Il peut y avoir des
problèmes inattendus à long terme, car il ne s’agit pas d’une configuration testée. Ces problèmes seraient
difficiles à identifier ou à suivre jusqu’à cette cause première. Solution à long terme au problème de
service RPCSS : remplacez les serveurs Windows Server 2003 restants par un système d’exploitation
ultérieur.
Pour arrêter les erreurs OutboundSecureChannels, utilisez /skip:outboundsecurechannels . Les tests ne
sont pas valides et peuvent être testés avec NETDOM.EXE et NLTEST.EXE .
Pour arrêter les erreurs VerifyEnterpriseReferences, migrez votre SYSVOL de FRS vers DFSR. Étant donné
que vous utilisez un domaine Windows Server 2008 natif ou ultérieur, FRS n’est plus recommandé pour
la réplication SYSVOL et rien ne vous empêche de remplacer le système FRS déconseillé. Voir
https://technet.microsoft.com/library/dd640019.aspx (en anglais).
Le test Windows Server 2008/2008 R2 DCDIAG Ser vices vérifie que les services suivants sont en cours
d’exécution, configurés avec les options de démarrage par défaut et configurés avec les types de processus par
défaut :
NOTE
Voici les vrais noms de service dans le Registre sous HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
RPCSS - Démarrer automatiquement - Processus partagé

EVENTSYSTEM - Démarrer automatiquement - Processus partagé
DBNACHE - Démarrer automatiquement - Processus partagé
NTFRS - Démarrer automatiquement - Propre processus
ISMSERV - Démarrer automatiquement - Processus partagé
KDC - Démarrer automatiquement - Processus partagé
SAMSS - Démarrer automatiquement - Processus partagé
SERVER - Démarrer automatiquement - Processus partagé
WORKSTATION - Démarrer automatiquement - Processus partagé
W32TIME - Démarrer manuellement ou automatiquement - Processus partagé
NETLOGON - Démarrer automatiquement - Processus partagé
(Si le niveau fonctionnel du domaine Windows Server 2008 ou une ultérieure)
DFSR - Démarrer automatiquement - Propre processus
(Si la cible est Windows Server 2008 ou une ultérieure)
NTDS - Démarrer automatiquement - Processus partagé
(Si vous utilisez la réplication AD basée sur SMTP)
IISADMIN - Démarrer automatiquement - Processus partagé
SMTPSVC - Démarrer automatiquement - Processus partagé
Un message d’erreur se produit lorsque vous
rétrogradez un contrôleur de domaine
Cet article fournit une solution à un problème dans lequel la rétrogradation d’un contrôleur de domaine à l’aide
de l’Assistant Installation d’Active Directory (Dcpromo.exe) échoue.
Symptômes
Lorsque vous rétrogradez un Windows de domaine à l’aide du Dcpromo.exe, vous pouvez recevoir le message
Ce contrôleur de domaine contient le dernier réplica des partitions d’annuaire d’applications suivantes :
DC=MSTAPI,DC= votre domaine ,DC=com
Cause
Ce comportement peut se produire si vous avez installé le contrôleur de domaine à l’aide de l’Assistant
Configurer votre ser veur. Lorsque vous utilisez cet Assistant, il crée automatiquement une partition de
programme ou un contexte d’attribution de noms non-domaine appelé DC=MSTAPI,DC= votre
domaine ,DC=com.
Résolution
Si vous avez créé la partition à l’aide de l’Assistant Configurer votre serveur et que vous avez utilisé le nom par
défaut de Mstapi, si ce nom n’est pas utilisé, utilisez l’outil Tapicfg.exe pour supprimer ce nom. Pour ce faire,
exécutez la commande suivante, où <your_domain.com> votre nom DNS de domaine :
tapicfg remove /directory:mstapi. <your_domain.com>
Si la partition a été créée manuellement ou à l’aide d’un autre programme, vous pouvez la supprimer à l’aide de
l’utilitaire Ntdsutil :
1. Ouvrez une invite de commandes, puis tapez ntdsutil.
2. À partir de l’invite Ntdsutil, tapez domain management .
3. Dans la fenêtre Gestion du domaine, tapez connections .
4. Tapez connect to server <yourservername> .
Une fois que le message de liaison s’affiche, vous aurez une connexion réussie à votre serveur.
5. Dans la fenêtre Connexions au serveur, tapez quit .
6. Dans la fenêtre Gestion du domaine, tapez list . Une liste des contextes d’attribution de noms sur ce
serveur s’affiche.
7. Pour supprimer le réplica de partition d’annuaire d’applications, tapez
remove nc replica <ApplicationDirectoryPartition> <DomainController> .
8. À l’invite Ntdsutil, tapez, puis appuyez sur Entrée jusqu’à ce que vous revenons à l’invite Q de
commandes CMD. Vous pouvez maintenant rétrograder ce contrôleur de domaine. Vous de devez peut-
être redémarrer ce contrôleur de domaine avant de redémarrer l’Assistant Installation d’Active Directory.
Windows prend en charge les contextes d’attribution de noms de programmes, également appelés contextes
d’attribution de noms autres que des domaines. Cette fonctionnalité permet au service d’annuaire Microsoft
Active Directory d’héberger des données dynamiques sans impact sur les performances du réseau en vous
permettant de contrôler l’étendue de la réplication et du placement des réplicas. Avec les services Active
Directory, vous pouvez créer un type de contexte ou de partition d’attribution de noms, appelé partition
d’application. Ce contexte d’attribution de noms peut contenir une hiérarchie de n’importe quel type d’objet à
l’exception des principaux de sécurité (utilisateurs, groupes et ordinateurs) et peut être configuré pour être
répliqué sur n’importe quel ensemble de contrôleurs de domaine dans la forêt qui ne sont pas nécessairement
tous dans le même domaine.
Placement et optimisation FSMO sur les contrôleurs
de domaine Active Directory
Certaines opérations sont préférables sur un seul contrôleur de domaine. Cet article décrit l’emplacement des
rôles Active Directory Flexible Single-Master Operation (FSMO) dans le domaine et la forêt pour ces opérations.
Certaines opérations de domaine et à l’échelle de l’entreprise ne sont pas adaptées aux mises à jour multi-
maîtres. Dans ce cas, les opérations doivent être réalisées sur un seul contrôleur de domaine dans le domaine
ou dans la forêt. Le fait d’avoir un propriétaire à maître unique définit une cible connue pour les opérations
critiques et empêche les conflits ou latences possibles créés par les mises à jour multi-maîtres. Cela signifie que
le propriétaire du rôle FSMO approprié doit être en ligne, découvrable et disponible sur le réseau par les
ordinateurs qui doivent effectuer des opérations dépendantes du FSMO.
Lorsque l’Assistant Installation d’Active Directory (Dcpromo.exe) crée le premier domaine dans une nouvelle
forêt, l’Assistant ajoute cinq rôles FSMO. Une forêt avec un domaine a cinq rôles. L’Assistant Installation d’Active
Directory ajoute trois rôles à l’échelle du domaine sur le premier contrôleur de domaine dans chaque domaine
supplémentaire de la forêt. En outre, des rôles principaux d’infrastructure existent pour chaque partition
d’application. Il inclut le domaine par défaut et les partitions d’application DNS à l’échelle de la forêt qui sont
créées sur Windows Server 2003 et les contrôleurs de domaine ultérieurs. Les maîtres des opérations et leur
étendue sont indiqués dans le tableau suivant.
B ESO IN S EN F O N C T IO N ET EN
RÔ L E F SM O P O RT ÉE DISP O N IB IL IT É
Schema Master Entreprise - Utilisé pour introduire des mises à

jour de schéma manuelles et par
programmation. Il inclut les mises à
jour qui sont ajoutées par Windows
ADPREP /FORESTPREP , par Microsoft
Exchange et par d’autres applications
qui utilisent les services de domaine
Active Directory (AD DS).
- Doit être en ligne lorsque des mises à
jour de schéma sont effectuées.
Domain Naming Master Entreprise - Permet d’ajouter et de supprimer des

domaines et des partitions
d’application vers et depuis la forêt.
- Doit être en ligne lorsque des
domaines et des partitions
d’application dans une forêt sont
ajoutés ou supprimés.
Contrôleur de domaine principal Domain - Reçoit les mises à jour de mot de

passe lorsque les mots de passe sont
modifiés pour l’ordinateur et pour les
comptes d’utilisateurs qui sont sur des
contrôleurs de domaine réplicas.
- Consulté par les contrôleurs de
domaine réplica qui ont des demandes
d’authentification de service dont les
mots de passe ne sont pas égaux.
- Contrôleur de domaine cible par
défaut pour les mises à jour de
stratégie de groupe.
- Ciblez le contrôleur de domaine pour
les applications héritées qui effectuent
des opérations accessibles en ligne et
pour certains outils d’administration.
- Doit être en ligne et accessible 24
heures sur 24, 7 jours sur 7.
RID Domain - Alloue des pools RID actifs et de

veille aux contrôleurs de domaine
réplicas dans le même domaine.
- Doit être en ligne dans les situations
suivantes :
lorsque les contrôleurs de
domaine nouvellement promus
doivent obtenir un pool RID
local requis pour la publicité
lorsque les contrôleurs de
domaine existants doivent
mettre à jour l’allocation
actuelle ou de veille du pool
RID.
Infrastructure Master Domain - Met à jour les références et les

fantômes entre domaines à partir du
Partition d’application catalogue global. Pour plus
d’informations, voir Phantoms,
tombstones et le maître
d’infrastructure
- Un maître d’infrastructure distinct est
créé pour chaque partition
d’application, y compris les partitions
d’application à l’échelle de la forêt et à
l’échelle du domaine par défaut créées
par Windows Server 2003 et les
contrôleurs de domaine ultérieurs.
La Windows Server 2008 R2

ADPREP /RODCPREP cible le rôle de
maître d’infrastructure pour
l’application DNS par défaut dans le
domaine racine de la forêt. Le chemin
d’accès DN pour ce titulaire de rôle est
:
CN=Infrastructure,DC=Domain
DnsZones,DC=<forest root
domain>,DC=<top level
domain>
CN=Infrastructure,DC=ForestD
nsZones,DC=<forest root
domain>,DC=<top level
domain>
Disponibilité et placement FSMO

L’Assistant Installation d’Active Directory fait le placement initial des rôles sur les contrôleurs de domaine. Ce
placement est souvent correct pour les répertoires qui n’ont que quelques contrôleurs de domaine. Dans un
répertoire qui dispose de nombreux contrôleurs de domaine, le placement par défaut peut ne pas être la
meilleure correspondance pour votre réseau.
Prenons en compte les facteurs suivants dans vos critères de sélection :
Il est plus facile de suivre les rôles FSMO si vous les hébergez sur moins d’ordinateurs.
Placez les rôles sur les contrôleurs de domaine accessibles par les ordinateurs, qui ont besoin d’accéder à
un rôle donné, en particulier sur les réseaux qui ne sont pas entièrement acheminés. Par exemple, pour
obtenir un pool RID actuel ou de veille, ou effectuer une authentification directe, tous les DCS ont besoin
d’un accès réseau aux titulaires de rôles RID et PDC dans leurs domaines respectifs.
Vous devez transférer (et non saisir) le rôle au nouveau contrôleur de domaine dans les conditions
suivantes :
un rôle doit être déplacé vers un autre contrôleur de domaine
le titulaire du rôle actuel est en ligne et disponible
Les rôles FSMO ne doivent être saisis que si le détenteur de rôle actuel n’est pas disponible. Pour plus
d’informations, voir Managing Operations Master Roles.
Les rôles FSMO attribués à des contrôleurs de domaine hors connexion ou dans un état d’erreur doivent
uniquement être transférés ou saisis si des opérations dépendantes des rôles sont en cours. Si le titulaire
du rôle peut être rendu opérationnel avant que le rôle soit nécessaire, vous pouvez retarder la saisie du
rôle. Si la disponibilité des rôles est essentielle, transférez ou saisissez le rôle selon les besoins. Le rôle
PDC dans chaque domaine doit toujours être en ligne.
Sélectionnez un partenaire de réplication intrasite direct pour que les titulaires de rôles existants agissent
en tant que titulaires de rôles de veille. Si le propriétaire principal passe hors connexion ou échoue,
transférez ou saisissez le rôle au contrôleur de domaine FSMO de veille désigné selon les besoins.
Recommandations générales pour le placement FSMO

Placez le maître de schéma sur le PDC du domaine racine de la forêt.
Placez le maître d’attribution de noms de domaine sur le PDC racine de la forêt.
L’ajout ou la suppression de domaines doit être une opération étroitement contrôlée. Placez ce rôle sur le
PDC racine de la forêt. Certaines opérations qui utilisent le maître d’appellation de domaine échouent si
le maître d’attribution de noms de domaine n’est pas disponible. Ces opérations incluent la création ou la
suppression de domaines et de partitions d’applications. Sur un contrôleur de domaine qui exécute
Microsoft Windows 2000, le maître d’appellation de domaine doit également être hébergé sur un serveur
de catalogue global. Sur les contrôleurs de domaine qui exécutent Windows Server 2003 ou versions
ultérieures, le maître d’appellation de domaine n’a pas besoin d’être un serveur de catalogue global.
Placez le PDC sur votre meilleur matériel dans un site hub fiable qui contient des contrôleurs de domaine
réplica dans le même site et domaine Active Directory.
Dans les environnements de grande taille ou occupés, le PDC a souvent l’utilisation du processeur la plus
élevée, car il gère l’authentification directe et les mises à jour de mot de passe. Si une utilisation élevée du
processeur devient un problème, identifiez la source. La source inclut les applications ou les ordinateurs
qui peuvent effectuer trop d’opérations (transitivement) ciblant le PDC. Les techniques de réduction du
processeur sont les suivantes :
Ajout de processeurs plus ou plus rapides
Ajout de réplicas
Ajout de mémoire pour mettre en cache des objets Active Directory
Suppression du catalogue global pour éviter les recherche de catalogue global
Réduction du nombre de partenaires de réplication entrants et sortants
Augmentation de la planification de réplication
Réduction de la visibilité de l’authentification à l’aide de LDAPSRVWEIGHT et LDAPPRIORITY, et à l’aide
de la fonctionnalité Randomize1CList.
Tous les contrôleurs de domaine d’un domaine particulier et les ordinateurs qui exécutent des
applications et des outils d’administration qui ciblent le PDC doivent avoir une connectivité réseau au
domaine PDC.
Placez le master RID sur le domaine PDC dans le même domaine.
La surcharge principale RID est légère, en particulier dans les domaines matures qui ont déjà créé la
plupart de leurs utilisateurs, ordinateurs et groupes. Le domaine PDC reçoit généralement le plus
d’attention de la part des administrateurs. La colocation de ce rôle sur le PDC permet d’assurer une
disponibilité fiable. Assurez-vous que les contrôleurs de domaine existants et les contrôleurs de domaine
nouvellement promus ont une connectivité réseau pour obtenir des pools RID actifs et de veille auprès du
contrôleur RID, en particulier les contrôleurs de domaine promus dans les sites distants ou de transit.
Les conseils hérités suggèrent de placer le maître d’infrastructure sur un serveur de catalogue non global.
Deux règles sont à prendre en compte :
Forêt à domaine unique :
Dans une forêt qui contient un seul domaine Active Directory, il n’y a pas de fantômes. Ainsi, le
maître d’infrastructure n’a aucun travail à faire. Le contrôleur d’infrastructure peut être placé sur
n’importe quel contrôleur de domaine dans le domaine, que ce contrôleur de domaine héberge ou
non le catalogue global.
Forêt multidomaine :
Si chaque contrôleur de domaine d’un domaine qui fait partie d’une forêt à plusieurs domaines
héberge également le catalogue global, il n’y a aucun fantôme ou aucun travail à faire pour le
contrôleur d’infrastructure. Le contrôleur d’infrastructure peut être placé sur n’importe quel
contrôleur de domaine de ce domaine. Pratiquement, la plupart des administrateurs hébergent le
catalogue global sur chaque contrôleur de domaine de la forêt.
Si chaque contrôleur de domaine d’un domaine donné situé dans une forêt multi-domaines
n’héberge pas le catalogue global, le contrôleur d’infrastructure doit être placé sur un contrôleur
de domaine qui n’héberge pas le catalogue global.
References
Pour plus d’informations, voir Comment utiliser les Windows cluster serveur en tant que contrôleurs de
domaine.
Articles sur les rôles Operations Master :
Fantômes, tombstones et le maître d’infrastructure
Erreur lors de l’exécuter Adprep /rodcprep dans Windows Server 2008
L’événement de réplication NTDS 1586 se produit dans l’une des situations suivantes :
Le rôle FSMO PDC pour un domaine particulier a été saisi.
Le rôle FSMO PDC pour un domaine particulier a été transféré vers un nouveau contrôleur de domaine qui
n’était pas un partenaire de réplication directe du détenteur de rôle précédent.
Règles d’application de stratégie de groupe pour les
Cet article décrit les règles d’application de stratégie de groupe pour les contrôleurs de domaine.
Résumé
Les contrôleurs de domaine tirent certains paramètres de sécurité uniquement des objets de stratégie de
groupe liés à la racine du domaine. Étant donné que les contrôleurs de domaine partagent la même base de
données de compte pour le domaine, certains paramètres de sécurité doivent être uniformément définies sur
tous les contrôleurs de domaine. Cela garantit que les membres du domaine ont une expérience cohérente, quel
que soit le contrôleur de domaine qu’ils utilisent pour se connecter. Windows 2000 permet d’appliquer
uniquement certains paramètres de la stratégie de groupe aux contrôleurs de domaine au niveau du domaine.
Ce comportement de stratégie de groupe est différent pour le serveur membre et les stations de travail.
Les paramètres suivants sont appliqués aux contrôleurs de domaine dans Windows 2000 uniquement lorsque la
stratégie de groupe est liée au conteneur de domaine :
Tous les paramètres dans Configuration ordinateur/Windows Paramètres/Sécurité
Paramètres/Stratégies de compte (cela inclut toutes les stratégies De verrouillage de compte, mot de
passe et Kerberos.)
Les trois paramètres suivants dans Configuration ordinateur/Windows Paramètres/Sécurité
Paramètres/Stratégies locales/Options de sécurité :
Déconnecter automatiquement les utilisateurs à l’expiration de l’heure de connexion
Renommer le compte d’administrateur
Renommer le compte invité
Les paramètres suivants sont appliqués aux contrôleurs de domaine basés sur Windows Server 2003
uniquement lorsque la stratégie de groupe est liée au conteneur de domaine. (Les paramètres se trouvent dans
Configuration ordinateur/Windows Paramètres/Sécurité Paramètres/Stratégies locales/Options de
sécurité.)
Comptes : état du compte Administrateur
Comptes : état du compte invité
Comptes : renommer le compte d’administrateur
Comptes : renommer le compte invité
Sécurité réseau : forcer la ouverture de logo à l’expiration des heures d’ouverture de contrat
Ces paramètres des objets de stratégie de groupe ne sont pas appliqués à l’unité d’organisation Contrôleurs de
domaine, car un contrôleur de domaine peut être déplacé hors de l’unité d’organisation Contrôleurs de domaine
et dans une autre unité d’organisation. L’utilisation du conteneur de domaine permet d’appliquer ces paramètres
indépendamment de l’unité d’organisation dans laquelle réside le conteneur de domaine.
Le processus d’application de ces paramètres sur un contrôleur de domaine inclut les éléments suivants :
Le contrôleur de domaine collecte la liste des objets de stratégie de groupe en recherchant les conteneurs
parents de l’objet Ordinateur du contrôleur de domaine.
Le contrôleur de domaine applique les paramètres répertoriés précédemment uniquement si l’objet de
stratégie de groupe est lié au conteneur de domaine.
S’il existe plusieurs objets de stratégie de groupe liés au conteneur Domaine, l’application des objets de
stratégie de groupe commence par l’objet de stratégie de groupe en bas de la liste et se termine par l’objet de
stratégie de groupe en haut. Ainsi, l’objet de stratégie de groupe en haut est prioritaire sur les autres.
La préparation de la stratégie de groupe n’est pas
effectuée lorsque vous préparez automatiquement
un domaine existant pour Windows Server 2012 R2
Cet article décrit un problème : la préparation de la stratégie de groupe n’est pas effectuée lorsque vous
préparez automatiquement un domaine existant.
Symptômes
Lorsque vous préparez automatiquement un domaine existant pour Windows Server 2012 R2 à l’aide du
Gestionnaire de serveur ou de la cmdlet Windows PowerShell, la préparation de la stratégie de groupe
Install-AddsDomainController n’est pas effectuée. En outre, la sortie suivante s’affiche brièvement lorsque vous
utilisez Install-AddsDomainController :
Adprep a mis à jour les informations à l’échelle de la forêt.

Adprep a mis à jour les informations à l’échelle du domaine.
La nouvelle fonctionnalité de planification entre domaines pour la stratégie de groupe, le mode de planification
RSOP, nécessite la mise à jour des autorisations du système de fichiers et des services de domaine Active
Directory pour les objets de stratégie de groupe existants.
NOTE
Cette sortie n’est pas visible lorsque vous installez les services de domaine Active Directory (AD DS) à l’aide du
Gestionnaire de serveur et que la sortie n’est pas enregistrée.
Cause
Ce comportement est inhérent au produit. Les fonctionnalités automatisées de préparation de domaine distant
ajoutées dans Windows Server 2012 ne modifient pas le comportement de préparation de la stratégie de
groupe (Gpprep) qui s’est produit dans les systèmes d’exploitation précédents.
Gpprep ajoute des fonctionnalités de planification entre domaines pour la stratégie de groupe et le mode de
planification de l’ensemble de stratégies résultante (RSoP). Cela nécessite la mise à jour du système de fichiers
dans les autorisations SYSVOL et Active Directory pour les stratégies de groupe existantes. Si l’environnement
contient déjà des autorisations personnalisées ou déléguées qui ont été mises en place manuellement par les
administrateurs, Gpprep déclenche la réplication de tous les fichiers de stratégie de groupe dans SYSVOL et
peut refuser la fonctionnalité RSOP aux utilisateurs délégués jusqu’à ce que leurs autorisations soient re-créées
par les administrateurs.
Résolution
Les administrateurs de domaine doivent s’exécuter manuellement, comme ils deviez le faire dans
adprep.exe /domainprep /gpprep Windows Server 2003, Windows Server 2008 et Windows Server 2008 R2.
Les administrateurs ne doivent exécuter Gpprep qu’une seule fois dans l’historique d’un domaine. Ils ne doivent
pas exécuter Gpprep chaque fois qu’une mise à niveau se produit. Gpprep a été introduit dans Windows Server
2003.
LAdprep.exe est inclus sur le support Windows Server 2012 \support\adprep. Cette version de Adprep.exe
prend en charge la préparation à distance et n’a pas besoin de s’exécuter sur le rôle maître d’opérations maître
d’infrastructure (également appelé FSMO ou opérations mono master flexibles), comme dans les systèmes
d’exploitation serveur précédents.
Pour plus d’informations sur les commandes Adprep.exe héritées, voir Préparer votre infrastructure pour la mise
à niveau.
Mise à niveau Windows contrôleurs de domaine
2000 vers Windows Server 2003
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 à des
domaines Windows 2000.
Résumé
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 à des
domaines Windows 2000. Pour plus d’informations sur la mise à niveau des contrôleurs de domaine vers
Windows Server 2008 ou Windows Server 2008 R2, visitez le site Web Microsoft suivant :
Mise à niveau des contrôleurs de domaine : démarrage rapide du support Microsoft pour l’ajout de contrôleurs
de domaine Windows Server 2008 ou Windows Server 2008 R2 à des domaines existants
Inventaire de domaine et de forêt

Avant de mettre à niveau Windows 2000 contrôleurs de domaine vers Windows Server 2003 ou avant d’ajouter
de nouveaux contrôleurs de domaine Windows Server 2003 à un domaine Windows 2000, suivez les étapes
suivantes :
1. Inventoriez les clients qui accèdent aux ressources dans le domaine qui hébergent Windows contrôleurs
de domaine Server 2003 pour la compatibilité avec la signature SMB :
Chaque Windows de domaine Server 2003 permet la signature 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 les 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 soient installées ou
jusqu’à ce que les clients soient mis à niveau vers des systèmes d’exploitation plus nouveaux qui la prise
en charge. 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 les plus populaires :
Microsoft Windows Server 2003, Microsoft Windows XP Professional, Microsoft Windows 2000
Server, Microsoft Windows 2000 Professional et Microsoft Windows 98
Aucune action n’est requise.
Microsoft Windows NT 4.0 installe le Service Pack 3 ou une ultérieure (Service Pack 6A est
recommandé) sur tous les ordinateurs NT 4.0 de Windows qui accèdent aux domaines qui
contiennent des ordinateurs Windows Server 2003. À la place, désactivez temporairement la
signature SMB Windows contrôleurs de domaine 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 Server 2000.
Toutefois, ce module 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 à une
disquette amorçable pour copier les 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 sont pas en charge de la signature SMB. Utilisez une autre méthode
d’installation ou désactivez la signature SMB. Pour plus d’informations sur la désactivation de la
signature SMB, consultez la section Pour désactiver la signature SMB à la fin de cette étape.
Clients Macintosh
Certains clients Macintosh ne sont pas compatibles avec la signature SMB et recevront le message
d’erreur suivant lorsqu’ils essaieront de se connecter à une ressource réseau :
- Erreur -36 I/S
Installez les logiciels mis à jour s’ils sont disponibles. Dans le cas contraire, désactivez la signature
SMB Windows contrôleurs de domaine 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 la prise en charge de la signature SMB. Consultez votre fournisseur
SMB pour voir s’il existe une version mise à jour. Dans le cas contraire, désactivez la signature SMB
Windows contrôleurs de domaine 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 concernés qui
exécutent Windows 95, Windows NT 4.0 ou d’autres clients qui ont été installés avant l’introduction de
Windows Server 2003, désactivez temporairement les exigences de signature de service SMB dans la
stratégie de groupe jusqu’à ce que vous déployiez des logiciels clients mis à jour.
Vous pouvez désactiver la signature du service SMB dans le nœud suivant de la stratégie contrôleurs de
domaine par défaut sur l’unité d’organisation des contrôleurs de domaine : Configuration ordinateur
Windows Paramètres Sécurité Paramètres Options de sécurité des stratégies locales \ \ Microsoft
Network Server \ \ \ :
Communications signe numériquement (toujours)
Si les contrôleurs de domaine ne sont pas situés dans l’unité d’organisation du contrôleur de domaine,
vous devez lier l’objet de stratégie de groupe (GPO) du contrôleur de domaine par défaut à toutes les
unités d’organisation qui hébergent les contrôleurs de domaine Windows 2000 ou Windows Server
2003. Vous pouvez également configurer la signature du service SMB dans un GPO lié à ces unités
d’organisation.
2. Inventoriez les contrôleurs de domaine qui se sont dans le domaine et dans la forêt :
a. Assurez-vous que tous Windows 2 000 contrôleurs de domaine dans 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 avoir un fichier Ntdsa.dll dont la date et la version sont antérieures au 4
juin 2001 et au 5.0.2195.3673.
Par défaut, les outils d’administration Active Directory sur les ordinateurs clients Windows 2000
SP4, Windows XP et Windows Server 2003 utilisent la signature LDAP (Lightweight Directory
Access Protocol). Si ces ordinateurs utilisent (ou reviennent à) l’authentification NTLM lorsqu’ils
administrent à distance Windows 2000 contrôleurs de domaine, la connexion ne fonctionne pas.
Pour résoudre ce problème, un minimum de Windows 2000 SP3 doit être installé pour les
contrôleurs de domaine administrés à distance. Sinon, vous devez désactiver la signature LDAP sur
les clients qui exécutent les outils d’administration.
Les scénarios suivants utilisent l’authentification NTLM :
Vous administrez Windows 2 000 contrôleurs de domaine situés dans une forêt externe
connectée par une confiance NTLM (non Kerberos).
Vous concentrez les logiciels en snap-in de microsoft Management Console (MMC) sur un
contrôleur de domaine spécifique référencé par son adresse IP. Par exemple, vous cliquez sur
Démarrer, sur Exécuter, puis tapez la commande suivante : dsa.msc /server=ipaddress
Pour déterminer le système d’exploitation et le niveau de révision du Service Pack des contrôleurs
de domaine Active Directory dans un domaine Active Directory, installez la version Windows
Server 2003 de Repadmin.exe sur un ordinateur membre Windows XP Professional ou Windows
Server 2003 dans la forêt, puis exécutez la commande suivante sur un contrôleur de domaine
dans chaque domaine des repadmin fores 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
NOTE
Les attributs du contrôleur de domaine ne font pas le suivi de l’installation de correctifs logiciels
individuels.
b. 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
d’attribution de noms locaux avec ses partenaires de manière cohérente avec la planification
définie par les liens de site ou les objets de connexion. Utilisez la version Windows Server 2003 de
Repadmin.exe sur un ordinateur membre basé sur Windows XP ou Windows Server 2003 dans la
forêt avec les arguments suivants : tous les contrôleurs de domaine de la forêt doivent répliquer
Active Directory sans erreur, et les valeurs de la colonne « Delta le plus grand » du résultat du
repadmin ne doivent pas être beaucoup plus élevées que la fréquence de réplication sur les liens
de site ou c correspondants. objets onnection 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 dont la réplication
entrante n’a pas pu être répliquée en moins de 60 jours (par défaut, 60 jours). Si la réplication ne
peut pas fonctionner, vous pouvez être contraint de rétrograder les contrôleurs de domaine et de
les supprimer de la forêt à l’aide de la commande de nettoyage des métadonnées Ntdsutil, puis de
les promouvoir à nouveau dans la forêt. Vous pouvez utiliser une rétrogradation forcé pour
enregistrer à la fois l’installation du système d’exploitation et les programmes sur un contrôleur de
domaine orphelin. Pour plus d’informations sur la suppression de contrôleurs de domaine
Windows 2000 orphelins de leur domaine, cliquez sur le numéro d’article suivant pour afficher
216498 supprimer des données dans Active Directory après une rétrogradation de contrôleur de
domaine infructueuse
Ne faites cette action qu’en dernier recours pour récupérer l’installation du système d’exploitation
et des programmes installés. Vous perdrez les objets et attributs non répliqués sur les contrôleurs
de domaine orphelins, y compris les utilisateurs, les ordinateurs, les relations d’confiance, leurs
mots de passe, les 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 d’une partition Active Directory
particulière pendant un nombre de jours supérieur à tombstonelifetime. Lorsque vous le faites,
vous pouvez réanimer des objets qui ont été supprimés sur un contrôleur de domaine, mais pour
lesquels les partenaires de réplication directe ou transitive n’ont jamais reçu la suppression au
cours des 60 derniers jours.
Envisagez de supprimer tous les objets en attente qui résident sur des contrôleurs de domaine qui
n’ont pas effectué de réplication entrante au cours des 60 derniers jours. Vous pouvez également
rétrograder de force les contrôleurs de domaine qui n’ont effectué aucune réplication entrante sur
une partition donnée en nombre de jours 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.
c. 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 les Gpotool.exe du Kit de ressources pour déterminer s’il existe des incohérences dans les
stratégies au sein d’un domaine. Utilisez Healthcheck des outils de support Windows Server 2003
pour déterminer si les jeux de réplicas de partage Sysvol fonctionnent correctement dans chaque
domaine.
Si le contenu du partage Sysvol est incohérent, résolvez toutes les incohérences.
d. Utilisez Dcdiag.exe des outils de support pour vérifier que tous les contrôleurs de domaine ont des
partages Netlogon et Sysvol partagés. Pour ce faire, tapez la commande suivante à l’invite de
commandes :
DCDIAG.EXE /e /test:frssysvol
e. Inventorier les rôles d’opération.

Les maîtres des opérations de schéma et d’infrastructure sont utilisés pour introduire des
modifications de schéma à l’échelle de la forêt et du domaine dans la forêt et ses domaines
effectués par l’utilitaire de présentation Windows Server 2003. Vérifiez que le contrôleur de
domaine qui héberge le rôle de schéma et le rôle d’infrastructure pour chaque domaine de la forêt
réside sur des contrôleurs de domaine en direct et que chaque propriétaire de rôle a effectué une
réplication entrante sur toutes les partitions depuis leur dernier redémarrage.
La commande peut être utilisée pour afficher les rôles opérationnels à l’échelle de la
DCDIAG /test:FSMOCHECK forêt et du domaine. Les rôles maîtres d’opérations qui résident sur des
contrôleurs de domaine inexistants doivent être saisis sur un contrôleur de domaine sain à l’aide
de NTDSUTIL. Les rôles qui résident sur des contrôleurs de domaine défectueux doivent être
transférés si possible. Dans le cas contraire, ils doivent être saisis. La NETDOM QUERY FSMO
commande n’identifie pas les rôles FSMO qui résident sur des contrôleurs de domaine supprimés.
Vérifiez que 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 commande, où DCNAME est le nom de
l’ordinateur NetBIOS ou le nom d’ordinateur complet d’un REPADMIN /SHOWREPS DCNAME contrôleur
de domaine. Pour plus d’informations sur les maîtres des opérations et leur placement, cliquez sur
les numéros d’article suivants pour consulter les articles de la Base de connaissances Microsoft :
223346 optimisation et placement FSMO sur les contrôleurs de domaine Active Directory
f. EventLog Review
Examinez les journaux des événements sur tous les contrôleurs de domaine pour les événements
problématiques. Les journaux des événements ne doivent pas contenir de messages d’événement
sérieux qui indiquent un problème avec l’un des processus et composants suivants :
connectivité physique
connectivité réseau
inscription de nom
résolution de nom
authentification
stratégie de sécurité
sous-système de disque
schéma
topologie
moteur de réplication
g. 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 du 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 du fichier Ntds.dit. Pour plus d’informations sur la façon de libérer de l’espace disque
supplémentaire, voir la section « Contrôleurs de domaine sans espace disque suffisant » de cet
article.
h. Nettoyage DNS (facultatif)
Activez le nettoyage 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 donne au daemon de nettoyage DNS suffisamment de temps pour
collecter la garbage-collecting des objets DNS en âge lorsqu’une défragmentation hors connexion
est effectuée sur le fichier Ntds.dit.
i. Désactiver le service serveur DLT (facultatif)
Le service DLT Server est désactivé sur les installations nouvelles et mises à niveau de Windows de
domaine Server 2003. Si le suivi des liens distribués n’est pas utilisé, vous pouvez désactiver le
service serveur DLT 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, voir la section « Microsoft
Recommandations for distributed link tracking » de l’article suivant de la Base de connaissances
Microsoft : 312403 Distributed Link Tracking sur les contrôleurs de domaine Windows
j. Sauvegarde de l’état du système
Effectuer une sauvegarde de l’état système d’au moins deux contrôleurs de domaine dans chaque
domaine de la forêt. Vous pouvez utiliser la sauvegarde pour récupérer tous les domaines de la
forêt si la mise à niveau ne fonctionne pas.
Microsoft Exchange 2000 dans Windows 2000

NOTE
Si Exchange Server 2000 est installé ou le sera, dans une forêt Windows 2000, lisez cette section avant d’exécuter la
commande Windows Server 2003. adprep /forestprep
Si Microsoft Exchange Server schéma 2003 est installé, allez à la section « Vue d’ensemble : Mise à niveau des
contrôleurs de domaineWindows 2000 vers Windows Server 2003» avant d’exécuter les commandes Windows Server
2003. adprep
Le schéma Exchange 2000 définit trois attributs inetOrgPerson avec LDAPDisplayNames non conforme à la
demande de commentaire (RFC) : houseIdentifier, premier et labeledURI.
Le kit inetOrgPerson Windows 2000 et la commande Windows Server 2003 définissent les versions RFC-
complaint des trois mêmes attributs avec adprep des noms LDAPDisplayNames identiques en tant que versions
non conformes RFC.
Lorsque la commande Windows Server 2003 est exécuté sans scripts correctifs dans une forêt qui contient des
modifications de schéma adprep /forestprep Windows 2000 et Exchange 2000, les noms LDAPDisplayNames
pour les attributs houseIdentifier, labeledURI et attributes d’attributs d’attributs sont mangled. Un attribut
devient « mangled » si « Dup » ou d’autres caractères uniques sont ajoutés au début du nom d’attribut en conflit
afin que les objets et les attributs dans le répertoire ont des noms uniques.
Les forêts Active Directory ne sont pas vulnérables aux LDAPDisplayNames mangled pour ces attributs dans les
cas suivants :
Si vous exécutez la commande Windows Server 2003 dans une forêt qui contient le schéma Windows 2000
avant d’ajouter le schéma adprep /forestprep Exchange 2000.
Si vous installez le schéma Exchange 2000 dans la forêt créée alors qu’un contrôleur de domaine Windows
Server 2003 était le premier contrôleur de domaine dans la forêt.
Si vous ajoutez Windows 2000 inetOrgPerson Kit à une forêt qui contient le schéma Windows 2000, puis que
vous installez Exchange 2000, puis que vous exécutez la commande Windows Server 2003.
adprep /forestprep
Si vous ajoutez un schéma Exchange 2000 à une forêt Windows 2000 existante, exécutez Exchange 2003
/forestprep avant d’exécuter la commande Windows Server 2003. adprep /forestprep
Les attributs mangled se produisent Windows 2000 dans les cas suivants :
Si vous ajoutez les versions Exchange 2000 de l’URI d’étiquette, du houseIdentifier et des attributs d’attributs
d’attribut à une forêt Windows 2000 avant d’installer le kit inetOrgPerson Windows 2000.
Vous ajoutez les versions Exchange 2000 de l’URI d’étiquette, du houseIdentifier et des attributs d’attribut à
une forêt Windows 2000 avant d’exécuter la commande Windows Server 2003 sans exécuter au départ les
scripts de adprep /forestprep nettoyage. Les plans d’action pour chaque scénario sont les suivants :
Scénario 1 : Exchange modifications de schéma 2000 sont ajoutées après l’Windows commande
adprep/forestprep de Windows Server 2003
Si Exchange 2000 modifications de schéma sont introduites dans votre forêt Windows 20 Windows 00 après
l’exécuter, aucun nettoyage n’est adprep /forestprep nécessaire. Go to the "Overview: Upgrading Windows 2000
domain controllers to Windows Server 2003" section.
Scénario 2 : Exchange modifications de schéma 2000 seront installées avant la commande Windows Server
2003 adprep /forestprep
Si Exchange 2000 modifications de schéma ont déjà été installées, mais que vous n’avez PAS exécuté la
commande Windows Server 2003, envisagez le adprep /forestprep plan d’action suivant :
1. Connectez-vous à la console du maître des opérations de schéma à l’aide d’un compte membre du
groupe de sécurité Administrateurs du schéma.
2. Cliquez sur Démarrer, cliquez sur Exécuter, tapeznotepad.exe dans la zone Ouvrir, puis cliquez sur OK.
3. Copiez le texte suivant, y compris le tiret de fin après « schemaUpdateNow: 1 » pour Bloc-notes.
dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace:LDAPDisplayName
LDAPDisplayName : msExchAssistantName
-
dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchLabeledURI
-
dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName : msExchHouseIdentifier
-
dn:
changetype: Modify
schemaUpdateNow: 1
-
4. Confirmez qu’il n’y a pas d’espace à la fin de chaque ligne.

5. Dans le menu Fichier , cliquez sur Enregistrer . Dans la boîte de dialogue Enregistrer sous , procédez
comme suit :
a. Dans la zone Nom de fichier, tapez ce qui suit : \ %userprofile% \ InetOrgPersonPrevent.ldf
b. Dans la zone Enregistrer en tant que type, cliquez sur Tous les fichiers.
c. Dans la zone Decodage, cliquez sur Unicode .
d. Cliquez sur Enregistrer .
e. Quittez Bloc-notes.
6. Exécutez le script InetOrgPersonPrevent.ldf.
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd dans la zone Ouvrir, puis cliquez sur
OK.
b. À l’invite de commandes, tapez ce qui suit, puis appuyez sur Entrée : cd %userprofile%
c. 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"
Remarques de syntaxe :
DC=X est une constante sensible à la cas.
Le chemin d’accès au nom de domaine du domaine racine doit être entre guillemets.
Par exemple, la syntaxe de commande pour une forêt Active Directory dont le domaine racine de forêt est
TAILSPINTOYS.COM :
c: \ documents and settings administrator>\ ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X

« dc=tailspintoys,dc=com »
NOTE
Vous devrez peut-être modifier la sous-clé de Registre Schema Update Allowed si vous recevez le message
d’erreur suivant : La mise à jour du schéma n’est pas autorisée sur ce dc, car la clé de Registre n’est pas définie ou
le dc n’est pas le propriétaire du rôle FSMO de schéma.
7. Vérifiez que les attributs LDAPDisplayNames pour les attributs CN=ms-Exch-Assistant-Name, CN=ms-
Exch-LabeledURI et CN=ms-Exch-House-Identifier dans le contexte d’appellation de schéma apparaissent
désormais sous les noms msExchAssistantName, msExchLabeledURI et msExchHouseIdentifier avant
d’exécuter les commandes Windows Server 2003. adprep /forestprep
8. Go to the "Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003" section to
run the adprep /forestprep and /domainprep commands.
Scénario 3 : la commande Windows Server 2003 forestprep a été exécuté sans exécuter au premier abord
inetOrgPersonFix
Si vous exécutez la commande Windows Server 2003 dans une forêt Windows 2000 qui contient les
modifications apportées au schéma adprep /forestprep Exchange 2000, les attributs LDAPDisplayName pour
houseIdentifier, l’uri d’accès et l’urié étiqueté deviennent mangled. Pour identifier les noms mangled, utilisez
Ldp.exe pour localiser les attributs affectés :
1. Installez Ldp.exe à partir du dossier Outils de support du média \ Microsoft Windows 2000 ou Windows
Server 2003.
2. Démarrez Ldp.exe à partir d’un contrôleur de domaine ou d’un ordinateur membre dans la forêt.
a. Dans le menu Connexion, cliquez sur Connecter , laissez la zone Serveur vide, tapez 389 dans la zone
Por t, puis cliquez sur OK .
b. Dans le menu Connexion, cliquez sur Lier, laissez toutes les zones vides, puis cliquez sur OK.
3. Enregistrez le chemin d’accès au nom de l’attribut SchemaNamingContext. Par exemple, pour un
contrôleur de domaine dans corp. ADATUM.COM forêt, le chemin d’accès au nom distingue peut être
CN=Schema,CN=Configuration,DC=corp,DC=company,DC=com.
4. Dans le menu Parcourir, cliquez sur Rechercher.
5. Utilisez les paramètres suivants pour configurer la boîte de dialogue Rechercher :
DN de base : chemin d’accès au nom pour le contexte d’appellation de schéma identifié à l’étape 3.
Filter : (ldapdisplayname=dup*)
Scope : Subtree
6. Les attributs mangled houseIdentifier, de musique et labeledURI ont des attributs LDAPDisplayName
similaires au format suivant :
LDAPDisplayName : DUP-labeledURI-9591bbd3-d2a6-4669-afda-48af7c35507d;
LDAPDisplayName : DUP-cas-c5a1240d-70c0-455c-9906-a4070602f85f
LDAPDisplayName : DUP-houseIdentifier-354b0ca8-9b6c-4722-aae7-e66906cc9eef
7. Si les noms LDAPDisplayNames pour labeledURI, l’enregistrement et le houseIdentifier ont été mangled à
l’étape 6, exécutez le script Windows Server 2003 InetOrgPersonFix.ldf pour récupérer, puis allez à la
section « Mise à niveau des contrôleurs de domaine Windows 2000 avec Winnt32.exe ».
a. Créez un dossier nommé %Systemdrive% IOP, puis extrayez le fichier \ InetOrgPersonFix.ldf dans
ce dossier.
b. À l’invite de commandes, tapez cd %systemdrive%\iop .
c. Extrayez le fichier InetOrgPersonFix.ldf du fichier Support.cab situé dans le dossier Outils de
support du support \ d’installation Windows Server 2003.
d. À 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,
sherifier et labeledURI. Pour ce faire, tapez la commande suivante, qui est une constante sensible à
la cas et qui est le chemin d’accès du nom de domaine pour le domaine <X> racine de la forêt <dn
path for forest root domain> :
C:\IOP>ldifde -i -f inetorgpersonfix.ldf -v -c DC=X "domain name path for forest root domain"
Remarques de syntaxe :
DC=X est une constante sensible à la cas.
Le chemin d’accès au nom de domaine du domaine racine de la forêt doit être entre guillemets.
8. Vérifiez que les attributs houseIdentifier, sheatérificateur et labeledURI dans le contexte d’appellation de
schéma ne sont pas « mangled » avant d’installer Exchange 2000.
Vue d’ensemble : mise Windows 2000 contrôleurs de domaine vers

Windows Server 2003
La commande Windows Server 2003 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 adprep \
Windows Server 2003. La Windows Server 2003 ajoute adprep /forestprep les fonctionnalités suivantes :
Descripteurs de sécurité par défaut améliorés pour les classes d’objets
Nouveaux attributs utilisateur et groupe
Nouveaux objets et attributs de schéma comme inetOrgPersonThe adprep utility prend en charge deux
arguments de ligne de commande :
adprep /forestprep : exécute des opérations de mise à niveau de forêt.
dprep /domainprep : exécute des opérations de mise à niveau de domaine.
La commande est une opération en une seule fois effectuée sur le maître d’opérations de schéma
adprep /forestprep (FSMO) de la forêt. L’opération forestprep doit être terminée et répliquée sur le maître
d’infrastructure de chaque domaine avant de pouvoir adprep /domainprep s’exécuter dans ce domaine.
La commande est une opération à une seule opération 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 à adprep /domainprep niveau. La commande vérifie que les
modifications de forestprep ont été répliquées dans la partition de domaine, puis effectue ses propres
modifications dans la partition de domaine et les stratégies de groupe dans le partage adprep /domainprep
Sysvol.
Vous ne pouvez effectuer aucune des actions suivantes, sauf si les opérations /forestprep et /domainprep sont
terminées et répliquées sur tous les contrôleurs de domaine de ce domaine :
Mettre à niveau Windows contrôleurs de domaine 2000 vers Windows de domaine Server 2003 à l’aide
Winnt32.exe.
NOTE
Vous pouvez mettre à niveau Windows 2 000 serveurs et ordinateurs membres vers des ordinateurs Windows Server
2003 lorsque vous le souhaitez. Promouvoir de Windows contrôleurs de domaine 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 dans lequel vous devez
exécuter à la fois adprep /forestprep et adprep /domainprep . Dans tous les autres domaines, vous devez
uniquement exécuter adprep /domainprep .
Les commandes et les commandes n’ajoutent pas d’attributs au jeu adprep /forestprep d’attributs partiels du
catalogue global ou entraînent une synchronisation adprep /domainprep complète du catalogue global. La
version RTM entraîne une synchronisation complète du dossier Stratégies dans adprep /domainprep
l’arborescence \ Sysvol. Même si vous exécutez forestprep et domainprep plusieurs fois, les opérations
terminées ne sont effectuées qu’une seule fois.
Après les modifications et leur réplication complète, vous pouvez mettre à niveau les contrôleurs de domaine
Windows 2000 vers Windows Server 2003 en exécutant Winnt32.exe à partir du dossier adprep /forestprep
adprep /domainprep \I386 du média Windows Server 2003. En outre, vous pouvez ajouter de nouveaux
contrôleurs Windows Server 2003 au domaine à l’aide de Dcpromo.exe.
Mise à niveau de la forêt avec la commande adprep/forestprep
Pour préparer une forêt et des domaines Windows 2000 à accepter les contrôleurs de domaine Windows Server
2003, suivez d’abord ces étapes dans un environnement de laboratoire, puis dans un environnement de
production :
1. Assurez-vous d’avoir effectué toutes les opérations de la phase « Inventaire de forêt » en accordant une
attention particulière aux éléments suivants :
a. Vous avez créé des sauvegardes d’état système.
b. Tous les Windows 2 000 contrôleurs de domaine dans la forêt ont installé tous les correctifs logiciels
et service packs appropriés.
c. La réplication de bout en bout d’Active Directory se produit dans toute la forêt
d. FRS réplique la stratégie de système de fichiers correctement dans chaque domaine.
2. Connectez-vous à la console du maître des opérations de schéma avec un compte membre du groupe de
sécurité Administrateurs du schéma.
3. 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 à une invite de commandes NT Windows suivante : repadmin /showreps
( le repadmin est installé par le support technique \ Dossier Outils d’Active Directory.)
4. La documentation microsoft anticipée 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 par un maître des opérations de schéma
lorsqu’il est redémarré sur un réseau privé.
5. Exécuter adprep sur le maître des opérations de schéma. Pour ce faire, cliquez sur Démarrer, cliquez
sur Exécuter, tapez cmd, puis cliquez sur OK. Sur 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 Windows d’installation server 2003. Cette commande exécute la
mise à niveau du schéma à l’échelle de la forêt.
NOTE
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 :
6. Vérifiez que la adprep /forestprep commande s’est correctement réussie 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) 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 d’accès complet Adprep.exe situé dans le dossier I386 du support d’installation a été
spécifié lors de \ adprep l’utilisation. Pour ce faire, tapez la commande suivante :
x:\i386\adprep /forestprep
où x est le lecteur qui héberge le support d’installation.

L’utilisateur connecté qui exécute adprep est membre du groupe de sécurité Administrateurs du
schéma. Pour vérifier cela, utilisez la whoami /all commande.
Si cela ne fonctionne toujours pas, affichez le fichier Adprep.log dans le dossier adprep
%systemroot% \ System32 \ Debug \ Adprep \ Logs \ Latest_log dossier.
7. 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 schéma par peuvent adprep /forestprep se propager.
Pour ce faire, vous pouvez suivre les étapes suivantes :
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd, puis cliquez sur OK.
b. Tapez ce qui suit, puis appuyez sur Entrée : repadmin /options -DISABLE_OUTBOUND_REPL
8. Vérifiez que les adprep /forestprep modifications ont été répliquées sur tous les contrôleurs de domaine
de la forêt. Il est utile de surveiller les attributs suivants :
a. Incrémentation de la version du schéma
b. Le CN=Windows2003Update, CN=ForestUpdates,CN=Configuration,DC= forest_root_domain ou
CN=Operations,CN=DomainUpdates,CN=System,DC= forest_root_domain et les GUID
d’opérations sous celui-ci ont été répliqués.
c. Recherchez de nouvelles classes de schéma, des objets, des attributs ou d’autres modifications qui
s’ajoutent, telles adprep /forestprep qu’inetOrgPerson. Affichez les fichiers .ldf Sch XX (où XX est un
nombre entre 14 et 30) dans le dossier %systemroot%\System32 pour déterminer les objets et
attributs qu’il doit y avoir. Par exemple, inetOrgPerson est défini dans Sch18.ldf.
9. Recherchez LDAPDisplayNames mangled. Si vous trouvez des noms mangled, allez au scénario 3 du
même article.
10. Log on to the console of the schema operations master with an account that is a member of the Schema
Admins group security group of the forest that hosts the schema operations master.
Mise à niveau du domaine avec la commande adprep/domainprep
S’exécute après la réplication complète des modifications /forestprep sur le contrôleur de domaine maître
d’infrastructure dans chaque domaine qui hébergera Windows contrôleurs de domaine adprep /domainprep
Server 2003. Pour ce faire, procédez comme suit :
1. Identifiez le contrôleur de domaine maître d’infrastructure dans le domaine que vous êtes en train de
mettre à niveau, puis connectez-vous avec un compte membre du groupe de sécurité Administrateurs du
domaine dans le domaine que vous êtes en train de mettre à niveau.
NOTE
L’administrateur d’entreprise peut ne pas être membre du groupe de sécurité Administrateurs du domaine dans
les domaines enfants de la forêt.
2. adprep /domainprep Exécutez-le sur le maître d’infrastructure. Pour ce faire, cliquez sur Démarrer, cliquez
sur Exécuter, tapez cmd, puis, dans le master d’infrastructure, tapez la commande suivante : où X : I386 est
le chemin d’accès du support X:\I386\adprep /domainprep d’installation Windows Server \ \ 2003. Cette
commande exécute les modifications à l’échelle du domaine dans le domaine cible.
NOTE
La commande modifie les autorisations des fichiers dans le partage adprep /domainprep Sysvol. Ces
modifications entraînent une synchronisation complète des fichiers dans cette arborescence de répertoires.
3. Vérifiez que domainprep s’est correctement terminé. Pour ce faire, vérifiez les éléments suivants :
La adprep /domainprep commande s’est terminée sans erreur.
Le cn=Windows2003Update,CN=DomainUpdates,CN=System,DC= dn path of domain you are
upgrading existsIf adprep /domainprep doesn’t run, verify the following items:
L’utilisateur connecté qui s’exécute est membre du groupe de sécurité Administrateurs du domaine
dans le domaine en adprep cours de mise à niveau. Pour ce faire, utilisez la whoami /all commande.
Le chemin d’accès complet Adprep.exe situé dans le répertoire I386 du support d’installation a été
spécifié \ lors de l’utilisation. adprep Pour ce faire, à l’invite de commandes, tapez la commande
suivante : où x est le lecteur x :\i386\adprep /forestprep qui héberge le support d’installation.
Si cela ne fonctionne toujours pas, affichez le fichier Adprep.log dans le dossier adprep
%systemroot% \ System32 \ Debug \ Adprep \ Logs \ Latest_log dossier.
4. Vérifiez que les adprep /domainprep modifications ont été répliquées. Pour ce faire, pour les contrôleurs
de domaine restants dans le domaine, vérifiez les éléments suivants : - Le
CN=Windows2003Update,CN=DomainUpdates,CN=System,DC= chemin dn du domaine que vous êtes
en cours de mise à 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) Recherchez les objets, attributs ou
modifications de liste de contrôle d’accès (ACL) adprep /domainprep qui ont été ajoutés. Répétez les
étapes 1 à 4 sur le maître d’infrastructure des domaines restants en bloc ou lorsque vous ajoutez ou
mettre à niveau des DCS dans ces domaines vers Windows Server 2003. Vous pouvez désormais
promouvoir de nouveaux ordinateurs Windows Server 2003 dans la forêt à l’aide de DCPROMO. Vous
pouvez également mettre à niveau Windows 2 000 contrôleurs de domaine existants vers Windows
Server 2003 à l’aide WINNT32.EXE.
Mise à niveau Windows 2000 contrôleurs de domaine à l’aide de

Winnt32.exe
Une fois que les modifications de /forestprep et /domainprep ont été 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 Windows 2000 contrôleurs de domaine 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 :
Le maître d’attribution de noms de domaine dans la forêt afin que vous pouvez créer des partitions de
programme DNS par défaut.
Contrôleur de domaine principal du domaine racine de la forêt afin que les principaux de sécurité à l’échelle
de l’entreprise ajoutés par Windows Server 2003 deviennent visibles dans l’éditeur de la zone de contrôle
d’accès.
Contrôleur de domaine principal dans chaque domaine non racine afin que vous pouvez créer des principaux
de sécurité spécifiques Windows 2003. Pour ce faire, utilisez WINNT32 pour mettre à niveau les contrôleurs
de domaine existants qui hébergent le rôle opérationnel que vous souhaitez. Vous de même transférer le rôle
vers un contrôleur de domaine Windows Server 2003 nouvellement promu. Effectuez les étapes suivantes
pour chaque contrôleur de domaine Windows 2000 que vous effectuez une mise à niveau vers Windows
Server 2003 avec WINNT32 et pour chaque ordinateur membre ou groupe de travail Windows Server 2003
que vous faites la promotion :
1. Avant d’utiliser WINNT32 pour mettre à niveau Windows 2 000 ordinateurs membres et contrôleurs de
domaine, supprimez Windows outils d’administration 2000. Pour ce faire, utilisez l’outil
Ajout/Suppression de programmes dans le Panneau de contrôle. (Windows mises à niveau 2000
uniquement.)
2. Installez tous les fichiers de correctifs ou autres correctifs que Microsoft ou l’administrateur détermine
comme importants.
3. Recherchez les problèmes de mise à niveau possibles sur chaque contrôleur de domaine. Pour ce faire,
exécutez la commande suivante à partir du dossier I386 du support d’installation : Résolvez les
problèmes identifiés par la vérification de \ winnt32.exe /checkupgradeonly compatibilité.
4. Exécutez WINNT32.EXE à partir du dossier I386 du support d’installation et redémarrez le contrôleur de
domaine \ 2003 mis à niveau.
5. Réduire les paramètres de sécurité pour les clients de version antérieure selon les besoins.
Si Windows clients NT 4.0 n’ont pas NT 4.0 SP6 ou Windows 95 n’ont pas le client de service d’annuaire
installé, désactivez la signature du service SMB sur la stratégie contrôleurs de domaine par défaut sur
l’unité d’organisation Contrôleurs de domaine, puis lier cette stratégie à toutes les unités d’organisation
qui hébergent les contrôleurs de domaine. Configuration ordinateur Windows Paramètres sécurité
Paramètres stratégies locales Options de sécurité Microsoft Network Server : communications avec
signature \ \ numérique \ \ \ (toujours)
6. Vérifiez l’état de la mise à niveau à l’aide des points de données suivants :
La mise à niveau s’est terminée correctement.
Les correctifs que vous avez ajoutés à l’installation remplacent correctement les binaires d’origine.
La réplication entrante et sortante d’Active Directory a lieu pour tous les contextes d’attribution de
noms détenus par le contrôleur de domaine.
Les partages Netlogon et Sysvol existent.
Le journal des événements indique que le contrôleur de domaine et ses services sont sains.
NOTE
Vous pouvez recevoir le message d’événement suivant après la mise à niveau : Vous pouvez ignorer ce message
d’événement en toute sécurité.
7. Installez Windows Server 2003 Administration Tools (Windows 2000 upgrades and Windows Server
2003 non-domain controllers only). Adminpak.msi se trouve dans le dossier \ I386 du CD-ROM Windows
Server 2003. Windows Le média Server 2003 contient des outils de support mis à jour dans le fichier
dSuptools.msi \ \ de support. Veillez à réinstaller ce fichier.
8. Effectuer de nouvelles sauvegardes d’au moins les deux premiers contrôleurs de domaine Windows 2000
que vous avez mis à niveau vers Windows Server 2003 dans chaque domaine de la forêt. Recherchez les
sauvegardes des ordinateurs Windows 2000 que vous avez mis à niveau vers Windows Server 2003
dans un stockage verrouillé afin de ne pas les utiliser accidentellement pour restaurer un contrôleur de
domaine qui exécute Windows Server 2003.
9. (Facultatif) Effectuez une défragmentation hors connexion de la base de données Active Directory sur les
contrôleurs de domaine que vous avez mis à niveau vers Windows Server 2003 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 à 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 de l’amélioration du magasin de descripteurs de sécurité uniquement lorsque vous enregistrez
un message d’événement ID 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
à l’administrateur pour effectuer la défragmentation hors connexion de Ntds.dit à l’aide de NTDSUTIL.EXE.
La défragmentation hors connexion peut réduire la taille d’un fichier Ntds.dit Windows 2000 jusqu’à 40
%, améliorer les performances d’Active Directory et mettre à jour les pages de la base de données pour
un stockage plus efficace des attributs Link Valued. Pour plus d’informations sur la défragmentation de la
base de données Active Directory, cliquez sur le numéro d’article suivant pour afficher l’article dans la
232122 défragmentation hors connexion de la base de données Active Directory
10. Examinez le service serveur DLT. Windows Les contrôleurs de domaine Server 2003 désactivent le service
DLT Server sur les installations nouvelles et de mise à niveau. Si Windows 2000 ou Windows XP dans
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. Dans le cas
contraire, supprimez incrémentiellement les objets de suivi des liens distribués d’Active Directory. Pour
plus d’informations, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de
312403 de liens distribués sur Windows de domaine basés sur des contrôleurs de domaine
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 avoir supprimé le dernier objet DLT et pour terminer le collecte de la garbage, puis
utilisez NTDSUTIL.EXE pour effectuer une défragmentation hors connexion du fichier Ntds.dit.
11. Configurez la structure de l’unité d’organisation des meilleures pratiques. Microsoft recommande aux
administrateurs de déployer 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, redirigez les conteneurs par défaut que les API de version
antérieure utilisent pour créer des utilisateurs, des ordinateurs et des groupes vers un conteneur d’unité
d’organisation spécifié par l’administrateur.
Pour plus d’informations sur la structure d’unité d’organisation des meilleures pratiques, consultez la
section « Création d’une conception d’unité d’organisation » du livre blanc « Best Practice Active Directory
Design for Managing Windows Networks ». Pour afficher le livre blanc, visitez le site Web Microsoft
suivant : 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
https://technet.microsoft.com/library/bb727085.aspx Microsoft :
324949 redirection des conteneurs d’utilisateurs et d’ordinateurs Windows domaines Server 2003
12. 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 Best Practice) pour
chaque domaine Active Directory.
En résumé :
Mettre à niveau Windows contrôleurs de domaine 2000 avec WINNT32 (à partir du support
d’installation en aval si utilisé)
Vérifier que les fichiers de correctifs ont été installés sur les ordinateurs mis à niveau
Installer les correctifs logiciels requis qui ne sont pas contenus sur le support d’installation
Vérifier l’état des serveurs nouveaux ou mis à niveau (AD, FRS, Stratégie, et ainsi de suite)
Attendre 24 heures après la mise à niveau du système d’exploitation, puis défragmentation hors
connexion (facultatif)
Démarrez le service DLT si vous devez supprimer des objets DLT à l’aide de q312403 /q315229 après
domainpreps à l’échelle de la forêt
Effectuer une défragmentation hors connexion de plus de 60 jours (durée de vie de tombstone et
collecte de la garbage collection # de jours) après la suppression d’objets DLT
Mises à niveau à chaud dans un environnement de laboratoire

Avant de mettre à niveau Windows contrôleurs de domaine vers un domaine de production Windows 2000,
validez et affinez votre processus de mise à niveau dans l’atelier. Si la mise à niveau d’un environnement de
laboratoire qui reflète avec précision la forêt de production fonctionne sans problème, vous pouvez vous
attendre à des résultats similaires dans les environnements de production. Pour les environnements complexes,
l’environnement de laboratoire doit mettre en miroir l’environnement de production dans les domaines suivants
:
Matériel : type d’ordinateur, taille de la mémoire, emplacement des fichiers de page, taille du disque,
performances et configuration raid, niveaux de révision du BIOS et du microprogramme
Logiciels : versions du système d’exploitation client et serveur, applications client et serveur, versions du
Service Pack, correctifs logiciels, modifications de schéma, groupes de sécurité, appartenances aux groupes,
autorisations, paramètres de stratégie, type de compte d’objet et emplacement, interopérabilité des versions
Infrastructure réseau : WINS, DHCP, vitesses de liaison, bande passante disponible
Load : les simulateurs de charge peuvent simuler des modifications de mot de passe, la création d’objets, la
réplication Active Directory, l’authentification par logo et d’autres événements. L’objectif n’est pas de
reproduire l’échelle de l’environnement de production. Au lieu de cela, les objectifs sont de découvrir les
coûts et la fréquence des opérations courantes et d’interpoler leurs effets (requêtes de noms, trafic de
réplication, bande passante réseau et consommation de processeur) sur l’environnement de production en
fonction de vos besoins actuels et futurs.
Administration : tâches effectuées, outils utilisés, systèmes d’exploitation utilisés
Opération : capacité, interopérabilité
Espace disque : notez la taille de début, de pointe et de fin du système d’exploitation, Ntds.dit et les fichiers
journaux Active Directory sur les contrôleurs de domaine de catalogue global et non globaux dans chaque
domaine après chacune des opérations suivantes :
1. adprep /forestprep
2. adprep /domainprep
3. Mise à niveau Windows contrôleurs de domaine 2000 vers Windows Server 2003
4. Réalisation 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é à 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 sur des liaisons de réseau large (WAN) haute disponibilité peuvent être mis à
niveau en quelques heures seulement. Vous de devez peut-être faire plus attention aux déploiements
d’entreprise qui ont des centaines de contrôleurs de domaine ou des centaines de milliers d’objets Active
Directory. Dans ce cas, vous pouvez effectuer la mise à niveau sur plusieurs semaines ou mois.
Utilisez des mises à niveau « à chaud » dans l’atelier pour effectuer les tâches suivantes :
Comprendre le fonctionnement interne du processus de mise à niveau et les risques associés.
Exposer les problèmes potentiels pour le processus de déploiement dans votre environnement.
Testez et développez des plans de repli au cas où la mise à niveau ne réussirait pas.
Définissez le niveau de détail approprié à appliquer au processus de mise à niveau pour le domaine de
production.
Contrôleurs de domaine sans espace disque suffisant

Sur les contrôleurs de domaine dont l’espace disque est insuffisant, utilisez les étapes suivantes pour libérer de
l’espace disque supplémentaire sur le volume qui héberge les fichiers Ntds.dit et Log :
1. Supprimez les fichiers inutilisés, y compris les fichiers *.tmp ou les fichiers mis en cache utilisés par les
navigateurs Internet. Pour ce faire, tapez les commandes suivantes (appuyez sur Entrée après chaque
commande) :
cd /d drive\
del *.tmp /s
2. Supprimez 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
3. Supprimez ou relocaliser temporairement les fichiers accessibles à partir d’autres serveurs ou réinstallez-
les facilement. Les fichiers que vous pouvez supprimer et remplacer facilement incluent ADMINPAK, les
outils de support technique et tous les fichiers du dossier %systemroot% \ System32 \ Dllcache.
4. Supprimez les profils utilisateur anciens ou inutilisés. Pour ce faire, cliquez sur Démarrer, cliquez avec le
bouton droit sur Mon ordinateur, cliquez sur Propriétés, cliquez sur l’onglet Profils utilisateur, puis
supprimez tous les profils qui sont pour les comptes anciens et inutilisés. Ne supprimez pas les profils qui
peuvent être pour les comptes de service.
5. Supprimez les symboles dans %systemroot% \ Symbols. Pour ce faire, tapez la commande suivante :
Selon que les serveurs ont un jeu de symboles complet ou petit, cela peut prendre environ 70 Mo à
rd /s %systemroot%\symbols 600 Mo.
6. Effectuer une défragmentation hors connexion. Une défragmentation hors connexion du fichier Ntds.dit
peut libérer de l’espace, mais nécessite temporairement le double de l’espace du fichier DIT actuel.
Effectuez la défragmentation hors connexion à l’aide d’autres volumes locaux s’il en existe un. Vous
pouvez également utiliser de l’espace sur un meilleur serveur réseau connecté pour effectuer la
défragmentation hors connexion. Si l’espace disque n’est toujours pas suffisant, supprimez de manière
incrémentielle les comptes d’utilisateurs, les comptes d’ordinateur, les enregistrements DNS et les objets
DLT inutiles d’Active Directory.
NOTE
Active Directory ne supprime pas les objets de la base de données tant que le nombre de jours (par défaut, 60 jours) n’a
pas été écoulé et que le collecte de la garbage est terminé. Si vous réduisez tombstonelifetime à une valeur inférieure à
la réplication de bout en bout dans la forêt, vous risquez de provoquer des incohérences dans Active Directory.
Syntaxe du fichier de réponse DCPROMO pour la
promotion et la rétrogradation sans surveillance des
Cet article décrit les paramètres et options utilisés dans le fichier de réponses DCPROMO pour installer et
supprimer les services de domaine Active Directory (AD DS) sur les contrôleurs de domaine.
Résumé
Cet article décrit la syntaxe que vous utilisez pour créer des fichiers de réponses afin d’effectuer des installations
sans surveillance d’AD DS sur des contrôleurs de domaine. Vous pouvez également utiliser les fichiers de
réponses pour supprimer AD DS en mode sans surveillance.
Introduction
Le programme Dcpromo.exe (DCPROMO) a été introduit dans Microsoft Windows 2000 Server pour fournir
une méthode d’interface utilisateur graphique (GUI) de promotion et de rétrogradation des contrôleurs de
domaine Active Directory. Les administrateurs peuvent utiliser des fichiers de réponses DCPROMO pour
effectuer les tâches sans surveillance suivantes :
Promouvoir des serveurs de groupe de travail et des serveurs membres aux contrôleurs de domaine Active
Directory.
Mettre à niveau microsoft Windows contrôleurs de domaine NT 4.0 vers les contrôleurs de domaine Active
Directory.
Rétrograder les contrôleurs de domaine.
Windows Server 2003 a mis à jour la syntaxe des fichiers de réponses DCPROMO.
Windows Server 2012 DCPROMO remplacé par les cmdlets PowerShell. Toutefois, la version Windows Server
2003 de la syntaxe du fichier de réponses DCPROMO reste entièrement prise en charge sur les versions
Windows suivantes :
Windows Server 2019
Windows Server 2016
Windows Server 2012
Windows Server 2008
Le fichier de réponses DCPROMO est un fichier texte ASCII qui fournit une entrée utilisateur automatisée pour
chaque page de l’Assistant DCPROMO.
Il existe de subtiles différences entre la syntaxe du fichier de réponses DCPROMO dans Windows 2000 Server et
Windows Server 2003. Malgré ces différences, Windows Server 2003 peut lire la syntaxe du fichier de réponse
Windows Server 2000 et interpréter les paramètres équivalents. Toutefois, la syntaxe Windows Server 2003
peut ne pas fonctionner correctement sur un contrôleur de domaine Windows Server 2000. Par exemple,
Windows 2000 Server ne peut pas utiliser les RemoveApplicationPartitions options et les ConfirmGc options.
Si vous devez utiliser les mêmes fichiers de réponses sur les contrôleurs de domaine Windows 2000 Server et
Windows Server 2003, utilisez la syntaxe du fichier de réponses décrite dans cet article.
Pour démarrer DCPROMO en mode sans surveillance, ouvrez une fenêtre d’invite de commandes
d’administration et exécutez la commande suivante :
dcpromo /answer:<answer.txt>
NOTE
Dans cette commande, est le chemin d’accès et le nom du fichier de réponses qui sera utilisé pour <answer.txt> la
rétrogradation ou la promotion. Vous pouvez utiliser cette commande, que vous utilisez la commande Démarrer l’exécuter
ou un fichier > d’installation sans surveillance.
Chaque opération DCPROMO nécessite des réponses à des champs spécifiques dans la section [DCInstall] du
fichier de réponses. La liste suivante fournit les champs requis pour chaque opération. Les valeurs par défaut
sont utilisées si l’option n’est pas spécifiée. Les valeurs par défaut de ces champs sont décrites dans Définitions
de champs.
Pour les nouvelles installations de forêt, les options suivantes s’appliquent :
[DCINSTALL]
InstallDNS=yes
NewDomain=forest
NewDomainDNSName=<The fully qualified Domain Name System (DNS) name>
DomainNetBiosName=<By default, the first label of the fully qualified DNS name>
SiteName=<Default-First-Site-Name>
ReplicaOrNewDomain=domain
ForestLevel=<The forest functional level number>
DomainLevel=<The domain functional level number>
DatabasePath= » <The path of a folder on a local volume> »
LogPath= » <The path of a folder on a local volume> »
RebootOnCompletion=yes
SYSVOLPath= » <The path of a folder on a local volume> »
SafeModeAdminPassword=<The password for an offline administrator account>
Pour les installations de domaine enfant, les options suivantes s’appliquent :
[DCINSTALL]
ParentDomainDNSName=<Fully qualified DNS name of parent domain>
UserName=<The administrative account in the parent domain>
UserDomain=<The name of the domain of the user account>
Password= <The password for the user account> Specify * to prompt the user for credentials during the
installation.
NewDomain=child
ChildName=<The single-label DNS name of the new domain>
SiteName= Ce site doit être créé à l’avance dans le logiciel en <The name of the AD DS site in which this
domain controller will reside> snap-in Dssites.msc.
DomainNetBiosName=<The first label of the fully qualified DNS name>
DomainLevel= Cette valeur ne peut pas être inférieure à la valeur actuelle du niveau fonctionnel <The
domain functional level number> de la forêt.
InstallDNS=yes
CreateDNSDelegation=yes
DNSDelegationUserName = Le compte utilisé pour installer AD DS peut différer du compte du domaine
parent qui dispose des autorisations requises pour créer une délégation <The account that has
permissions to create a DNS delegation> DNS. Dans ce cas, spécifiez le compte qui peut créer la
délégation DNS pour ce paramètre. Spécifiez * d’indiquer à l’utilisateur les informations d’identification
pendant l’installation.
DNSDelegationPassword= Spécifiez * pour indiquer à l’utilisateur un mot de passe <The password for
the account that is specified for DNSDelegationUserName> pendant l’installation.
Pour une nouvelle arborescence dans les installations de forêt existantes, les options suivantes
s’appliquent :
[DCINSTALL]
UserName=<An administrative account in the parent domain>
Password= <The password for the adminstrative account> Spécifiez * d’indiquer à l’utilisateur les
informations d’identification pendant l’installation.
NewDomain=tree
NewDomainDNSName=<The fully qualified DNS name of the new domain>
DomainNetBiosName=<The first label of the fully qualified DNS name>
DomainLevel=<The domain functional level number>
InstallDNS=yes
CreateDNSDelegation=yes
DNSDelegationUserName = Le compte utilisé pour installer AD DS peut différer du compte du domaine
parent qui dispose des autorisations requises pour créer une délégation <The account that has
permissions to create a DNS delegation> DNS. Dans ce cas, spécifiez le compte qui peut créer la
délégation DNS pour ce paramètre. Spécifiez * d’indiquer à l’utilisateur les informations d’identification
DNSDelegationPassword= Spécifiez * pour indiquer à l’utilisateur un mot de passe <The password for
the account that is specified for DNSDelegationUserName> pendant l’installation.
Pour les installations de contrôleur de domaine supplémentaires, les options suivantes s’appliquent :
[DCINSTALL]
UserName=<The administrative account in the domain of the new domain controller>
UserDomain=<The name of the domain of the new domain controller>
Password=<The password for the UserName account>
ReplicaOrNewDomain=replica
ReplicaDomainDNSName=<The fully qualified domain name (FQDN) of the domain in which you want
to add an additional domain controller>
InstallDNS=yes
ConfirmGC=yes
Pour les installations de contrôleur de domaine supplémentaires qui utilisent la méthode Install From
Media (IFM), les options suivantes s’appliquent :
[DCINSTALL]
UserDomain=<The name of the domain of the UserName account>
SafeModeAdminPassword=<The password of an offline administrator account>
CriticalReplicationOnly=no
SiteName=<The name of the AD DS site in which this domain controller will reside>
Ce site doit être créé à l’avance dans le logiciel en snap-in Dssites.msc.
ReplicaOrNewDomain=replica
ReplicaDomainDNSName=<The fully qualified domain name (FQDN) of the domain in which you want
to add an additional domain controller>
ReplicationSourceDC=<An existing domain controller in the domain>
ReplicationSourcePath=<The local drive and the path of the backup>
Pour les installations de contrôleur de domaine en lecture seule, les options suivantes s’appliquent :
[DCINSTALL]
PasswordReplicationDenied=<The names of the user, group, and computer accounts whose passwords
are not to be replicated to this RODC>
PasswordReplicationAllowed =<The names of the user, group, and computer accounts whose passwords
can be replicated to this RODC>
DelegatedAdmin=<The user or group account name that will install and administer the RODC>
SiteName=Default-First-Site-Name
CreateDNSDelegation=no
CriticalReplicationOnly=yes
ReplicaOrNewDomain=ReadOnlyReplica
ReplicaDomainDNSName=<The FQDN of the domain in which you want to add an additional domain
controller>
DatabasePath= " <The path of a folder on a local volume> »
InstallDNS=yes
ConfirmGC=yes
Pour la suppression des AD DS, les options suivantes s’appliquent :
[DCINSTALL]
UserName=<An administrative account in the domain>
UserDomain=<The domain name of the administrative account>
AdministratorPassword=<The local administrator password for the server>
RemoveApplicationPartitions=yes
RemoveDNSDelegation=yes
DNSDelegationUserName=<The DNS server administrative account for the DNS zone that contains the
DNS delegation>
DNSDelegationPassword=<The password for the DNSDelegationUserName account>
Pour supprimer AD DS du dernier contrôleur de domaine d’un domaine, les options suivantes
s’appliquent :
[DCINSTALL]
UserDomain=<The domain name of the UserName account>
Password= <The password for the UserName account> Specify * to prompt the user for credentials
during the installation.
IsLastDCInDomain=yes
RemoveApplicationPartitions=If you want to remove the partitions, specify « yes » (no quotation marks)
for this entry. Si vous souhaitez conserver les partitions, cette entrée est facultative.
DNS delegation>
DNSDelegationPassword=<The password for the DNS server administrative account>
Pour la suppression du dernier contrôleur de domaine dans une forêt, les options suivantes s’appliquent :
[DCINSTALL]
UserDomain=<The domain name of the UserName account>
Password= <The password for the UserName account> Specify * to prompt the user for credentials
during the installation.
IsLastDCInDomain=yes
RemoveApplicationPartitions=If you want to remove the partitions, specify « yes » (no quotation marks)
for this entry. Si vous souhaitez conserver les partitions, cette entrée est facultative.
DNS delegation>
DNSDelegationPassword=<The password for the DNS server administrative account>
Définitions de champ
Cette section décrit les champs et les entrées que vous pouvez utiliser dans le fichier de réponses. La valeur par
défaut de chaque entrée apparaît en gras.
Paramètres d’opération d’installation
A l l o w D o m a i n R e i n st a l l
Oui, | Non
Cette entrée indique si un domaine existant est re-créé.
A l l o w D o m a i n C o n t r o l l e r R e i n st a l l
Oui, | Non
Cette entrée indique s’il faut continuer à installer ce contrôleur de domaine même si un compte de
contrôleur de domaine actif qui utilise le même nom est détecté. Spécifiez « Oui » (pas de guillemets)
uniquement si vous êtes sûr que le compte n’est plus utilisé.
A p p l i c a t i o n P a r t i t i o n s To R e p l i c a t e
Aucune valeur par défaut

Cette entrée spécifie les partitions d’application qui doivent être répliquées au format « partition1 » «
partition2 ». Si * est spécifié, toutes les partitions d’application sont répliquées. Utilisez des noms séparés par
des espaces ou séparés par des virgules et des espaces. Insérablez la chaîne entière entre guillemets.
Ch i l d N am e

Il s’agit du nom du domaine subordonné qui est appendé à l’entrée ParentDomainDNSName. Si le domaine
parent est « A.COM » et que le domaine subordonné est « B », entrez « B.A.COM et B » (sans guillemets) pour
ChildName.
C o n fi r m G c
Oui, | Non
Cette entrée indique si le réplica est également un catalogue global. « Oui » fait du réplica un catalogue
global si la sauvegarde était un catalogue global. « Non » ne fait pas du réplica un catalogue global. (Ces
entrées ne nécessitent pas de guillemets.)
C r e a t e D N SD e l e g a t i o n
Oui, | Non
Cette entrée indique s’il faut créer une délégation DNS qui fait référence à ce nouveau serveur DNS. Cette
entrée est valide pour le DNS intégré à AD DS uniquement.
Cr i t i c al Repl i c at i o n O n l y
Oui, | Non
Cette entrée indique si l’opération d’installation effectue uniquement une réplication importante avant un
redémarrage, puis ignore la partie non critique et potentiellement longue de la réplication. La réplication non
critique se produit une fois l’installation du rôle terminée et l’ordinateur redémarre.
D a t a b a se P a t h
%systemroot% \ NTDS
Cette entrée est le chemin d’accès du répertoire UNC (Universal Naming Convention) complet sur un disque
dur de l’ordinateur local. Ce répertoire hébergera la base de données AD DS (NTDS). DIT). Si le répertoire
existe, il doit être vide. S’il n’existe pas, il sera créé. L’espace disque disponible sur le lecteur logique
sélectionné doit être de 200 mégaoctets (Mo). Pour prendre en charge les erreurs d’arrondi ou tous les objets
du domaine, l’espace disque disponible peut avoir besoin d’être plus grand. Pour de meilleures
performances, recherchez le répertoire sur un disque dur dédié.
Del egat ed A dm i n

Cette entrée spécifie le nom de l’utilisateur ou du groupe qui installera et administrera le rodc. Si aucune
valeur n’est spécifiée, seuls les membres du groupe Administrateurs du domaine ou du groupe
Administrateurs Enterprise peuvent installer et administrer le rodc.
D N SD e l e g a t i o n P a ssw o r d
<Password> | *
Cette entrée spécifie le mot de passe du compte d’utilisateur utilisé pour créer ou supprimer la délégation
DNS. Spécifiez * pour invite l’utilisateur à entrer des informations d’identification.
D N SD e l e g a t i o n U se r N a m e

Cette entrée spécifie le nom d’utilisateur à utiliser lors de la création ou de la suppression de la délégation
DNS. Si vous ne spécifiez aucune valeur, les informations d’identification de compte que vous spécifiez pour
l’installation ou la suppression d’AD DS sont utilisées pour la délégation DNS.
D N SO n N e t w o r k
Oui, | Non
Cette entrée indique si le service DNS est disponible sur le réseau. Cette entrée est utilisée uniquement
lorsque la carte réseau de cet ordinateur n’est pas configurée pour utiliser le nom d’un serveur DNS pour la
résolution de noms. Spécifiez « Non » (sans guillemets) pour indiquer que DNS sera installé sur cet
ordinateur pour la résolution de noms. Sinon, la carte réseau doit d’abord être configurée pour utiliser un
nom de serveur DNS.
Do m ai n Level
0|2|3
Cette entrée spécifie le niveau fonctionnel du domaine. Cette entrée est basée sur les niveaux qui existent
dans la forêt lorsqu’un nouveau domaine est créé dans une forêt existante. Les descriptions des valeurs sont
les suivantes :
0 = Windows mode natif du serveur 2000
2 = Windows Server 2003
Do m ai n N et bi o sN am e

Cette entrée est le nom NetBIOS utilisé par les clients pré-AD DS pour accéder au domaine.
DomainNetbiosName doit être unique sur le réseau.
F o r e st L e v e l
0|2|3
Cette entrée spécifie le niveau fonctionnel de la forêt lorsqu’un nouveau domaine est créé dans une
nouvelle forêt comme suit :
0 = Windows 2000 Server
3 = Windows Server 2008 Vous ne devez pas utiliser cette entrée lorsque vous installez un nouveau
contrôleur de domaine dans une forêt existante. L’entrée ForestLevel remplace l’entrée
SetForestVersion disponible dans Windows Server 2003.
I n st a l l D N S
Oui, | Non
La valeur par défaut change en fonction de l’opération. Pour une nouvelle forêt, le rôle serveur DNS est
installé par défaut. Pour une nouvelle arborescence, un nouveau domaine enfant ou un réplica, un serveur
DNS est installé par défaut si une infrastructure DNS existante est détectée par l’Assistant Installation des
services de domaine Active Directory. Si aucune infrastructure DNS existante n’est détectée par l’Assistant,
aucun serveur DNS n’est installé par défaut.
Cette entrée indique si DNS est configuré pour un nouveau domaine si l’Assistant Installation des services de
domaine Active Directory détecte que le protocole de mise à jour dynamique DNS n’est pas disponible. Cette
entrée s’applique également si l’Assistant détecte un nombre insuffisant de serveurs DNS pour un domaine
existant.
Log Pat h
%systemroot% \ NTDS
Il s’agit du chemin d’accès du répertoire complet non-UNC sur un disque dur sur l’ordinateur local qui
hébergera les fichiers journaux AD DS. Si le répertoire existe, il doit être vide. S’il n’existe pas, il sera créé.
N ew Do m ai n
Arborescence | Enfant | Forêt

« Arborescence » signifie que le nouveau domaine est la racine d’une nouvelle arborescence dans une forêt
existante. « Enfant » signifie que le nouveau domaine est un enfant d’un domaine existant. « Forêt » signifie
que le nouveau domaine est le premier domaine dans une nouvelle forêt d’arbre de domaine.
N e w D o m a i n D N SN a m e

Cette entrée est utilisée dans les installations « nouvelle arborescence dans la forêt existante » ou « nouvelle
forêt ». La valeur est un nom de domaine DNS qui n’est actuellement pas utilisé.
P a r e n t D o m a i n D N SN a m e

Cette entrée spécifie le nom d’un domaine DNS parent existant pour une installation de domaine enfant.
P a ssw o r d
<Password> | *
Cette entrée spécifie le mot de passe qui correspond au compte d’utilisateur utilisé pour configurer le
contrôleur de domaine. Spécifiez * pour invite l’utilisateur à entrer des informations d’identification. Pour la
protection, les mots de passe sont supprimés du fichier de réponses après une installation. Les mots de passe
doivent être redéfinis chaque fois qu’un fichier de réponses est utilisé.
P a ssw o r d R e p l i c a t i o n A l l o w e d
<Security_Principal> | AUCUN
Cette entrée spécifie les noms des comptes d’ordinateur et des comptes d’utilisateurs dont les mots de
passe peuvent être répliqués dans ce RODC. Spécifiez « NONE » (sans guillemets) si vous souhaitez
conserver la valeur vide. Par défaut, aucune identification utilisateur n’est mise en cache sur ce rodc. Pour
spécifier plusieurs principaux de sécurité, ajoutez l’entrée plusieurs fois.
P a ssw o r d R e p l i c a t i o n D e n i e d
<Security_Principal> | AUCUN
Cette entrée spécifie les noms des comptes d’utilisateur, de groupe et d’ordinateur dont les mots de passe
ne doivent pas être répliqués dans le RODC. Spécifiez « NONE » (sans guillemets) si vous ne souhaitez
pas refuser la réplication des informations d’identification pour des utilisateurs ou des ordinateurs. Pour
spécifier plusieurs principaux de sécurité, ajoutez l’entrée plusieurs fois.
Rebo o t O n Co m pl et i o n
Oui, | Non
Cette entrée indique si l’ordinateur doit être redémarré après l’installation ou la suppression d’AD DS, que
l’opération soit réussie ou non.
R e b o o t O n Su c c e ss
Oui, | Aucun | NoAndNoPromptEither

Cette entrée indique si l’ordinateur doit être redémarré après l’installation ou la suppression d’AD DS. Un
redémarrage est toujours nécessaire pour effectuer une modification dans un rôle AD DS.
R e p l i c a D o m a i n D N SN a m e

Cette entrée spécifie le nom de domaine (FQDN) du domaine dans lequel vous souhaitez configurer un
contrôleur de domaine supplémentaire.
Repl i c aO r N ew Do m ai n
Réplica | ReadOnlyReplica, | Domaine

Cette entrée est utilisée uniquement pour les nouvelles installations. « Domaine » (sans guillemets)
convertit le serveur en premier contrôleur de domaine d’un nouveau domaine. « ReadOnlyReplica » (sans
guillemets) convertit le serveur en rodc. « Replica » (sans guillemets) convertit le serveur en contrôleur
de domaine supplémentaire.
R e p l i c a t i o n So u r c e D C

Cette entrée spécifie le nom de domaine (FQDN) du contrôleur de domaine partenaire à partir duquel les
données AD DS sont répliquées pour créer le contrôleur de domaine.
R e p l i c a t i o n So u r c e P a t h

Cette entrée spécifie l’emplacement des fichiers d’installation utilisés pour créer un contrôleur de domaine.
Sa fe M o d e A d m i n P a ssw o r d
<Password> | AUCUN
Cette entrée est utilisée pour fournir le mot de passe du compte d’administrateur hors connexion utilisé en
mode de restauration du service d’annuaire. Vous ne pouvez pas spécifier de mot de passe vide.
Si t e N a m e
Default-First-Site-Name
Cette entrée spécifie le nom du site lorsque vous installez une nouvelle forêt. Pour une nouvelle forêt, la
valeur par défaut est Default-First-Site-Name. Pour tous les autres scénarios, un site est sélectionné à l’aide
du site actuel et de la configuration de sous-réseau de la forêt.
Sk i p A u t o C o n fi g D N S

Cette entrée est pour les utilisateurs experts qui souhaitent ignorer la configuration automatique des
paramètres client, des forwardeurs et des conseils racine. L’entrée n’est en vigueur que si le service DNS
Server est déjà installé sur le serveur. Dans ce cas, vous recevrez un message d’information qui confirme que
la configuration automatique du DNS a été ignorée. Sinon, cette entrée est ignorée. Si vous spécifiez ce
commutateur, assurez-vous que les zones sont créées et configurées correctement avant d’installer AD DS,
sinon le contrôleur de domaine ne fonctionnera pas correctement. Cette entrée n’ignore pas la création
automatique de la délégation DNS dans la zone DNS parente. Pour contrôler la création de délégation DNS,
utilisez l’entrée DNSDelegation.
Sy sk e y
<system_key> | AUCUN
Cette entrée spécifie la clé système pour le média à partir duquel vous répliquez les données.
SY SV O L P a t h
%systemroot% \ SYSVOL
Cette entrée spécifie un répertoire complet non UNC sur le disque dur de l’ordinateur local. Ce répertoire
hébergera les fichiers journaux AD DS. Si le répertoire existe déjà, il doit être vide. S’il n’existe pas, il sera créé.
Le répertoire doit se trouver sur une partition mise en forme à l’aide du système de fichiers NTFS 5.0.
Recherchez le répertoire sur un disque dur physique différent du système d’exploitation pour obtenir de
meilleures performances.
T r a n sfe r I M R o l e I fN e e d e d
Oui, | Non
Cette entrée indique s’il faut transférer le rôle principal d’infrastructure à ce contrôleur de domaine. Cette
entrée est utile si le contrôleur de domaine est actuellement hébergé sur un serveur de catalogue global et
que vous ne prévoyez pas de faire du contrôleur de domaine un serveur de catalogue global. Spécifiez « Oui
» (sans guillemets) pour transférer le rôle principal d’infrastructure à ce contrôleur de domaine. Si vous
spécifiez « Oui », veillez à spécifier l’entrée ConfirmGC=No.
U se r D o m a i n

Cette entrée spécifie le nom de domaine du compte d’utilisateur utilisé pour installer AD DS sur un serveur.
U se r N a m e

Cette entrée spécifie le nom du compte d’utilisateur utilisé pour l’installation d’AD DS sur un serveur. Nous
vous recommandons de spécifier les informations d’identification du compte <domain> \ au
format<user_name> format.
Paramètres d’opération de suppression
A d m i n i st r a t o r P a ssw o r d

Cette entrée permet de spécifier le mot de passe de l’administrateur local lorsque vous supprimez AD DS
d’un contrôleur de domaine.
D e m o t e F SM O
Oui, | Non
Cette entrée indique si une suppression forcée se produit même si un rôle maître des opérations est détenu
par le contrôleur de domaine.
D N SD e l e g a t i o n P a ssw o r d
<Password> | *
Cette entrée spécifie le mot de passe du compte d’utilisateur utilisé pour créer ou supprimer la délégation
DNS. Spécifiez * pour invite l’utilisateur à entrer des informations d’identification.
D N SD e l e g a t i o n U se r N a m e

Cette entrée spécifie le nom d’utilisateur à utiliser lors de la création ou de la suppression de la délégation
DNS. Si vous ne spécifiez pas de valeur, les informations d’identification de compte que vous spécifiez pour
l’installation AD DS ou pour la suppression AD DS sont utilisées pour la délégation DNS.
I g n o r e I s L a st D c I n D o m a i n M i sm a t c h
Oui, | Non
Cette entrée indique s’il faut poursuivre la suppression des services AD DS du contrôleur de domaine
lorsque l’entrée IsLastDCInDomain=Yes est spécifiée ou que l’Assistant Installation des services de domaine
Active Directory détecte qu’il existe en fait un autre contrôleur de domaine actif dans le domaine. Cette
entrée s’applique également à un scénario dans lequel l’entrée IsLastDCInDomain=No est spécifiée, et
l’Assistant ne peut pas contacter un autre contrôleur de domaine dans le domaine.
I g n o r e I s L a st D N SSe r v e r F o r Z o n e
Oui, | Non
Cette entrée indique s’il faut continuer à supprimer AD DS même si le contrôleur de domaine est le dernier
serveur DNS pour une ou plusieurs zones DNS intégrées à AD DS que le contrôleur de domaine héberge.
I s L a st D C I n D o m a i n
Oui, | Non
Cette entrée indique si le contrôleur de domaine duquel vous supprimez AD DS est le dernier contrôleur de
domaine dans le domaine.
P a ssw o r d
<Password> | *
Cette entrée spécifie le mot de passe qui correspond au compte d’utilisateur utilisé pour configurer le
contrôleur de domaine. Spécifiez * pour invite l’utilisateur à entrer des informations d’identification. Pour la
protection, les mots de passe sont supprimés du fichier de réponses après l’installation d’AD DS. Les mots de
passe doivent être redéfinis chaque fois qu’un fichier de réponses est utilisé.
Rebo o t O n Co m pl et i o n
Oui, | Non
Cette entrée indique si l’ordinateur doit être redémarré après l’installation ou la suppression d’AD DS, que
l’opération soit réussie ou non.
R e b o o t O n Su c c e ss
Oui, | Aucun | NoAndNoPromptEither

Détermine si l’ordinateur doit être redémarré après l’installation ou la suppression d’AD DS. Un
redémarrage est toujours nécessaire pour effectuer une modification dans un rôle AD DS.
Rem o veA ppl i c at i o n Par t i t i o n s
Oui, | Non
Cette entrée indique s’il faut supprimer des partitions d’application lorsque vous supprimez AD DS d’un
contrôleur de domaine. « Oui » (sans guillemets) supprime les partitions d’application sur le contrôleur de
domaine. « Non » (sans guillemets) ne supprime pas les partitions d’application sur le contrôleur de
domaine. Si le contrôleur de domaine héberge le dernier réplica d’une partition d’annuaire d’applications,
vous devez vérifier manuellement que vous devez supprimer ces partitions.
R e m o v e D N SD e l e g a t i o n
Oui, | Non
Cette entrée indique s’il faut supprimer les délégations DNS pointant vers ce serveur DNS de la zone
DNS parente.
Ret ai n DCMet adat a
Oui, | Non
Cette entrée indique si les métadonnées du contrôleur de domaine sont conservées dans le domaine après la
suppression des services de domaine AD DS afin qu’un administrateur délégué puisse supprimer les services
AD DS d’un contrôleur de domaine de domaine en cours.
U se r D o m a i n

Cette entrée spécifie le nom de domaine du compte d’utilisateur utilisé pour installer AD DS.
U se r N a m e

Cette entrée spécifie le nom du compte d’utilisateur utilisé pour installer AD DS sur un serveur. Nous vous
recommandons de spécifier les informations d’identification du compte <domain> \ au format<user_name>
format.
Codes de retour d’installation sans surveillance
L’Assistant Installation des services de domaine Active Directory renvoie un code de réussite ou un code d’échec
après avoir terminé l’installation sans surveillance d’un contrôleur de domaine Windows Server 2008. Pour plus
d’informations sur les codes de retour d’installation sans surveillance, visitez le site Web Microsoft suivant :
Codes de retour d’installation sans surveillance
L’installation des services de domaine Active
Directory échoue avec l’erreur « L’utilisateur spécifié
existe déjà ».
Cet article fournit une solution à un problème dans lequel l’installation des services de domaine Active
Directory échoue avec l’erreur : L’utilisateur spécifié existe déjà.
Symptômes
Lorsque vous tentez d’installer les services de domaine Active Directory sur un ordinateur Windows Server,
vous pouvez recevoir l’erreur suivante :
Erreur lors de la jointation d’un domaine

L’opération a échoué car : la tentative de joindre cet ordinateur à <target DNS domain> l’ordinateur a
échoué. L’utilisateur spécifié existe déjà.
Débogage %systemroot% \ \ DCPROMOUI. LOG contient le texte suivant :
dcpromoui Enter ComposeFailureMessage

dcpromoui Enter GetErrorMessage 80070524
dcpromoui Enter State::GetOperationResultsMessage La tentative de joindre cet ordinateur au <target DNS
domain> domaine a échoué.
dcpromoui Enter State::GetOperationResultsFlags 0x0
dcpromoui Enter State::SetFailureMessage L’opération a échoué car :
La tentative de joindre cet ordinateur au <target DNS domain> domaine a échoué.
« L’utilisateur spécifié existe déjà. »
Cause
Il existe un compte d’ordinateur du même nom que l’ordinateur sur lequel vous tentez d’installer les services de
Résolution
1. Si vous installez les services de domaine Active Directory sur un ordinateur du même nom qu’un
contrôleur de domaine qui existait précédemment dans le domaine, il est possible que les métadonnées
restent.
Vous pouvez utiliser l’une des méthodes suivantes pour supprimer les métadonnées :
Nettoyer les métadonnées du serveur
216498 supprimer des données dans Active Directory après une rétrogradation de contrôleur de
domaine infructueuse
Pour obtenir de meilleurs résultats, supprimez les métadonnées du contrôleur de domaine obsolète sur
un contrôleur de domaine dans le même domaine et site que le nouveau contrôleur de domaine joint, ou
le contrôleur de domaine d’aide spécifié dans l’Assistant Installation d’Active Directory ou le fichier de
réponses.
2. Si l’Assistant Installation d’Active Directory continue d’échouer avec l’erreur « L’utilisateur spécifié existe
déjà », examinez le débogage %systemroot% \ \ DCPROMOUI. Log pour identifier le nom du contrôleur
de domaine d’aide que le nouveau contrôleur de domaine tente d’utiliser.
Exemple de sortie de DCPROMOUI. LOG :
dcpromoui Enter DS::JoinDomain ← search for this section of the %systemroot% \ debug \
dcpromoui.log
dcpromoui Enter (Entrer l’administrateur DeMeuveurName)
administrateur d’contoso.com \ dcpromoui
dcpromoui Enter MyNetJoinDomain contoso.com .contoso.com ← nom du contrôleur de domaine
<helper DCs hostname> d’aide
dcpromoui Calling NetJoinDomain
dcpromoui lpServer : (null)
dcpromoui lpDomain : contoso.com <helper DCs hostname> .contoso.com
dcpromoui lpAccountOU : (null)
dcpromoui lpAccount : contoso.com \ administrateur
dcpromoui fJoinOptions : 0x27
dcpromoui HRESULT = 0x80070524Error ← 0x80070524 = 0x524 hex / 1316 décimal avec une
erreur symbolique ERROR_USER_EXISTS
dcpromoui HRESULT = 0x80070524
3. Vérifiez que le contrôleur de domaine d’aide identifié à l’étape 2 a répliqué la suppression du compte
d’ordinateur du contrôleur de domaine en conflit et des objets NTDS Paramètres (nettoyage des
métadonnées) effectués à l’étape 1. Si le compte de l’ordinateur du contrôleur de domaine existe toujours,
évaluez les raisons possibles :
Latence de réplication telle qu’un contrôleur de domaine étant à plusieurs sauts du contrôleur de
domaine à l’origine du nettoyage des métadonnées.
Échec de la réplication entrante sur le contrôleur de domaine d’aide.
Le contrôleur de domaine d’aide réside dans un site en retard qui a été intentionnellement configuré
pour répliquer les modifications entrantes de manière différée.
4. Pour plus d’informations sur les autres causes premières de cette erreur, cliquez sur le numéro d’article
suivant pour afficher les articles de la Base de connaissances Microsoft :
938447 Vous ne pouvez pas ajouter un nom d’utilisateur ou un nom d’objet qui diffère uniquement d’un
caractère avec une marque diacritique
Résoudre un message d’erreur interne pendant la
phase de réplication de dcpromo
Cet article explique comment résoudre une erreur interne que vous recevez pendant la phase de réplication de
l’Assistant Installation d’Active Directory (Dcpromo).
NOTE
Résumé
Pendant la promotion, les objets du service d’annuaire sont répliqués dans l’ordre du numéro de séquence de
mise à jour (USN) (faible à élevé) pour le schéma, la configuration et le domaine. Des erreurs internes peuvent
se produire lorsqu’un conteneur parent pour les objets enfants répliqués n’existe pas dans le service d’annuaire
local.
Ce problème peut se produire dans l’un des scénarios suivants :
Il existe un objet en direct dont le parent a été supprimé dans le passé, et le parent a expiré et a été
converti en fantôme. Par conséquent, l’objet enfant ne peut plus être répliqué. L’appel à FillGuidAndSid
pour l’objet parent dans ReplPrepareDataToShip ne réussit pas et une erreur est signalée (8352 =
ERROR_DS_NOT_AN_OBJECT). Cette erreur entraîne la fin de la réplication sortante de l’objet enfant et
vous recevez un message d’erreur interne de réplication.
S’il existe un objet actif (ou supprimé) qui a un parent fantôme, Active Directory accepte temporairement
l’objet actif en raison des exigences de réplication hors commande. Les procédures de nettoyage de
disque, telles que le nettoyage de la garbage, ne doivent pas être en mesure de convertir un objet
supprimé en fantôme si le parent a des objets enfants. Le Ntdsa.dll depuis Windows 2000 Service Pack 2
(SP2) empêche cette situation dans le service d’annuaire. Toutefois, ce fichier ne corrige pas le problème
une fois qu’il s’est déjà produit.
Vous utilisez la commande de restauration faisant autorité lorsque vous utilisez Windows Server 2003
ou une version ultérieure de l’outil Ntdsutil. Ntdsutil.exe augmente le nombre de conteneurs et d’objets
enfants spécifiés dans Active Directory. Les versions bêta de Ntdsutil.exe peuvent augmenter à tort le usn
pour le conteneur Perdu et trouvé. Lorsque les objets destinés au conteneur Perdu et Trouvé sont
répliqués avant que le conteneur ne soit créé dans le service d’annuaire local, l’événement suivant est
signalé :
Événement 1084 : échec de la réplication avec une erreur interne
Pour éviter ce scénario, le conteneur Perdu et trouvé est normalement l’un des premiers conteneurs
répliqués.
Des erreurs internes peuvent également se produire sur des contrôleurs de domaine Active Directory existants
pendant la réplication Active Directory normale ou initiée par l’administrateur.
Étapes de résolution de ce message d’erreur

1. Utilisez le moniteur réseau, les journaux d’événements ou Dcpromo.log pour localiser le serveur source
utilisé pendant la réplication Active Directory (lorsque vous utilisez l’Assistant Installation d’Active
Directory).
2. Si cette erreur se produit lorsque vous utilisez l’Assistant Installation d’Active Directory et qu’il existe
plusieurs partenaires de réplication potentiels, utilisez le fichier de réponse de l’Assistant Installation
d’Active Directory pour rechercher le serveur source. Les contrôleurs de domaine source possibles
incluent les contrôleurs de domaine dans le domaine parent pour les nouveaux domaines enfants, ou les
contrôleurs de domaine dans le même domaine pour les contrôleurs de domaine répliqués. Sinon, si un
serveur source spécifique est suspecté, arrêtez le service Net Logon sur l’ordinateur suspect et recherchez
à partir d’un autre contrôleur de domaine.
3. Sur le serveur source, recherchez et cliquez sur la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics
Modifiez les valeurs suivantes :

9 Traitement interne : définir le niveau de diagnostic sur 1.
7 Configuration interne : définir le niveau de diagnostic sur 3.
5 événements de réplication : définissez le niveau de diagnostic sur 3.
4. Utilisez l’Éditeur du Registre pour exporter la clé du serveur source vers l’ordinateur promu \NTDS (par
exemple, Ntds.reg). Copiez le fichier sur l’ordinateur qui rencontre l’erreur interne lors de la réplication. Si
l’erreur interne se produit lorsque l’Assistant Installation d’Active Directory est en cours d’exécution,
copiez le fichier .reg sur le bureau sur le contrôleur de domaine à problème afin que le fichier puisse être
démarré facilement.
Vous pouvez également appuyer sur Windows+R, puis faites glisser le fichier .reg à partir de la fenêtre de
l’Explorateur mis en place qui porte sur ce fichier. Sélectionnez OK pour ajouter le contenu du fichier .reg
au Registre.
5. Lorsque l’ordinateur promu commence à répliquer le contexte d’appellation de schéma, exécutez le fichier
Ntds.reg pour créer la clé de Registre et les \NTDS\Diagnostics paramètres.
WARNING
La clé de Registre n’existe pas à cette phase de promotion et doit être créée manuellement sur le contrôleur de
NTDS\Diagnostics domaine de destination. Si la clé de Registre est chargée trop tôt lorsque l’Assistant
Installation d’Active Directory est en cours d’exécution, la clé est écrasée par les valeurs par défaut et aucun
événement NTDS\Diagnostics n’est journalisé. Pour les contrôleurs de domaine existants, les paramètres de
Registre peuvent être activés à tout moment.
6. Examinez les journaux des événements du service d’annuaire sur les serveurs source et de destination.
Les événements internes sont affichés sur le serveur source en tant qu’ID d’événement 1173. Examinez
les événements de réplication NTDS qui se produisent avant l’erreur interne pour localiser l’identification
universelle globale (GUID) de l’objet en cours de réplication. (Il peut y avoir des tentatives dos à dos de
répliquer le même objet). Enregistrez le GUID de l’objet ou du conteneur problématique.
7. Démarrez Ldp.exe, lancez une connexion et lier le serveur source. Dans le menu Parcourir, sélectionnez
Supprimer. Pour le chemin d’accès au nom, tapez<GUID=GUID#>, par exemple, <GUID=b2d605a4-
b9e6-4505-ba59-895e91a9a7b5> . Définissez l’étendue de recherche sur Base, puis supprimez le GUID
spécifié.
8. À lLdp.exe, définissez la valeur de l’attribut TombstoneLifetime sur 2 (la valeur en jours avant la
suppression des objets tombstoned). TombstoneLifetime se trouve dans le chemin d’accès de nom de
marque suivant :
CN=Service d’annuaire,CN=Windows NT,CN=Services,CN=Configuration,,DC= domaine racine
,DC=COM
Vérifiez que l’attribut TombstoneLifetime est présent et que sa valeur est 2. Si la valeur est inférieure à 2,
la valeur n’est pas valide et le serveur utilise la valeur par défaut de 60 jours. (Vous pouvez également
utiliser ADSIEDIT pour modifier cet attribut.)
NOTE
Après avoir attendu deux jours que les objets tombstoned soient supprimés, vous de devez patienter 60 minutes
supplémentaires ou plus avant de redémarrer le contrôleur de domaine et de poursuivre le processus de collecte
de la garbage collection.
9. Lancez le garbage collection sur le contrôleur de domaine source. Recherchez et cliquez sur la clé de
Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics key
Modifiez les valeurs suivantes :

6 Garbage Collection : définir le niveau de diagnostic sur 3.
9 Traitement interne : définir le niveau de diagnostic sur 1.
Pour forcer un garbage collection, redémarrez le contrôleur de domaine. Le garbage collection doit
s’exécuter 15 minutes après le redémarrage du contrôleur de domaine. Les niveaux de diagnostic
enregistrent désormais les événements de collecte de la garbage collection dans le journal des
10. Pour vérifier que l’objet a été supprimé, exécutez la commande suivante :
repadmin /showmeta "<"GUID for deleted object">"
Si vous recevez un message : aucun objet de ce type, l’objet a déjà été supprimé avec succès et vous
pouvez à présent exécuter l’Assistant Installation d’Active Directory. Si l’objet n’a pas encore subi le
processus de collecte de la garbage, il doit y avoir des métadonnées pour l’attribut isDeleted. L’horodaage
associé à l’attribut isDeleted est l’heure de suppression. Vérifiez que la durée de suppression est définie
pour au moins deux jours, par exemple :
repadmin /showmeta "<GUID=b2d605a4-b9e6-4505-ba59-895e91a9a7b>"
11. Lorsque ce problème est résolu, réinitialisez les niveaux de journalisation des diagnostics sur 0 et
redéfinissez la durée de vie de tombstone sur ce qu’elle était précédemment, ou supprimez entièrement
la valeur pour inciter l’ordinateur à utiliser les valeurs par défaut. Le paramètre TombstoneLifetime est
essentiel pour définir la durée de vie utile de l’état du système et des sauvegardes Active Directory.
Lorsque TombstoneLifetime est définie sur 2, les bandes de sauvegarde qui datent de plus de deux jours
sont inutilisables. Tout contrôleur de domaine qui est en panne depuis au moins deux jours doit être
restauré à partir d’une sauvegarde ou réinstallé.
Le texte suivant est un exemple des événements signalés dans le journal des événements du service d’annuaire
sur le serveur source et de destination :
Type d’événement : Source d’événement d’information : catégorie d’événement de réplication NTDS : ID

d’événement de réplication : 1240 Date : MM/JD/heure AA : HH:MM:SS AM| Utilisateur PM : S-1-5-21-
1151542997-2719369742-1698538726-500 Computer: computer_source Description: Property 0
(objectClass) of object CN ="NTDS Paramètres DEL:51c6913c-9221-4ac4-8513-
9155dd7e15ad »,CN="ZA9902000 DEL:37eabd48-bc98-483f-b2fd-
9c8869e9c3ce »,CN=Servers,CN=Gul,CN=Sites,CN=Configuration,DC=mma,DC=fr (GUID 51c6913c-9221
-4ac4-8513-9155dd7e15ad) est envoyé à DSA 6abec3d1-3054-41c8-a362-5a0c5b7d5d71.
Type d’événement : Source de l’événement d’avertissement : Catégorie d’événement général NTDS : ID
d’événement de traitement interne : 1173 Date : MM/JD/heure AA : HH:MM:SS AM| Utilisateur PM : S-1-5-
21-1151542997-2719369742-1698538726-500 Computer: computer_source Description: Internal event:
Exception e0010002 has occurred with parameters 8442 and 20a0 (Internal ID 11003a1).
Le texte suivant est indiqué dans le journal de l’Assistant Installation d’Active Directory sur l’ordinateur promu.
Dans cet exemple de fichier Dcpromo.log, l’ordinateur promu, computer_promoted, rencontre une « erreur
interne » dans \ \ l’Assistant Installation d’Active Directory lors de la recherche à partir de \ \ computer_source.
Notez l’erreur 8442 qui se produit lors de la réplication de l’un des trois contextes d’attribution de noms ( « Le
système de réplication a rencontré une erreur interne »). Cet exemple montre que l’erreur se produit dans le
contexte d’attribution de noms de configuration :
MM/DD HH:MM:SS [INFO] Replicating CN=Configuration,DC=win2ktest,DC=A,DC=com: received 917 out

of 1783 objects.
of 1783 objects.
of 1783 objects.
of 1783 objects.
Erreur MM/JD HH:MM:SS [INFO] : le service d’annuaire n’a pas réussi à répliquer la partition
CN=Configuration,DC=test,DC=A,DC=com à partir du serveur distant computer_source.test.a.com. (8442)
MM/JD HH:MM:SS [INFO] NtdsInstall pour test.a.com la 8442 renvoyée
MM/JD HH:MM:SS [INFO] DsRolepInstallDs renvoyé 8442
MM/JD HH:MM:SS [ERREUR] Échec d’installation dans le service d’annuaire (8442)
MM/JD HH:MM:SS [INFO] Démarrage du service NETLOGON
MM/JD HH:MM:SS [INFO] Configuration du service NETLOGON sur 2 renvoyé 0
MM/JD HH:MM:SS [INFO] Recherche du compte d’ordinateur forcomputer_promotedon \
computer_source.test.a.com...
MM/JD HH:MM:SS [INFO] Configuration du compte de serveur
MM/JD HH:MM:SS [INFO] NtdsSetReplicaMachineAccount renvoyé 0
MM/DD HH:MM:SS [INFO] Tentative de déplacement accountcomputer_sourceto
CN=GAXGPTS01,CN=Computers,DC=test,DC=A,DC=com
Message d’erreur : l’Assistant ne peut pas accéder à
la liste des domaines dans la forêt
Cet article permet de résoudre l’erreur (l’Assistant ne peut pas accéder à la liste des domaines dans la forêt) qui
se produit lorsque vous utilisez Dcpromo.exe pour déplacer un serveur Windows vers un domaine existant.
Symptômes
Lorsque vous tentez d’utiliser Dcpromo.exe pour déplacer un serveur Windows 2000 ou Windows Server 2003
vers un domaine existant, le message d’erreur suivant peut s’afficher :
Assistant Installation d’Active Directory
L’Assistant ne peut pas accéder à la liste des domaines dans la forêt. L’erreur est la :
Le domaine spécifié n’existe pas ou n’a pas pu être contacté. Si vous utilisez Windows Server 2008, le message
d’erreur peut ressembler à ce qui suit : Assistant Installation d’Active Directory
Le chemin d’accès réseau est in trouvé.
Cause
Ce problème peut se produire si le serveur qui exécute le service DNS (Domain Name System) n’a pas
enregistré d’enregistrement « A » pour lui-même dans DNS.
Les enregistrements SRV des contrôleurs de domaine doivent se trouver dans la base de données DNS. Si
l’enregistrement « A » du serveur DNS est manquant, le processus ne réussit pas.
Résolution
Vous pouvez ajouter l’enregistrement « A » au DNS en émettant la commande suivante sur le serveur DNS :
ipconfig /registerdns Après avoir vérifié qu’un enregistrement « A » est présent pour le serveur DNS, vous
pouvez recevoir le message d’erreur suivant lorsque vous tentez de poursuivre le processus de Dcpromo.exe :
Assistant Installation d’Active Directory
Le serveur RPC n’est pas disponible.
Pour résoudre ce problème, tapez la commande suivante sur le serveur sur lequel vous essayez d’utiliser
Dcpromo.exe. Cette commande permet d’effacer le cache du programme de résolution DNS sur l’ordinateur qui
exécute Dcpromo.exe afin qu’il re-crée la requête une fois que l’enregistrement « A » du serveur DNS est
enregistré dans la base de données DNS.ipconfig /flushdns
Ce problème peut également se produire pendant le processus Dcpromo.exe si le partage de fichiers et
d’imprimantes n’est pas activé sur la carte réseau du contrôleur de domaine existant qui authentifiera ce
processus. Pour résoudre ce problème, activez le partage de fichiers et d’imprimantes sur le contrôleur de
domaine existant jusqu’à ce que Dcpromo.exe processus soit terminé.
Le partage NETLOGON n’est pas présent après
l’installation des services de domaine Active
Directory sur un nouveau contrôleur de domaine
complet ou en lecture seule Windows Server 2008
Cet article fournit une solution de contournement pour un problème qui se produit après l’installation des
services de domaine Active Directory sur un nouveau contrôleur de domaine Windows Server 2008 complet ou
en lecture seule.
IMPORTANT
et assurez-vous que vous savez le restaurer en cas de problème. Pour plus d’informations sur la façon de la back up,
restore et modify the registry, voir How to back up and restore the registry in Windows.

Symptômes
Après avoir installé les services de domaine Active Directory sur un nouveau contrôleur de domaine complet ou
en lecture seule Windows Server 2008 dans un domaine existant, le partage SYSVOL est présent. Toutefois, le
partage NETLOGON n’est pas présent sur le nouveau contrôleur de domaine.
NOTE
Cet article ne s’applique pas si les partages NETLOGON et SYSVOL sont manquants.
Cause
Ce problème se produit lorsque le service Netlogon lit très rapidement l’indicateur SysvolReady dans le
Registre. Ensuite, le service Netlogon tente de partager le dossier de scripts de domaine Windows SYSVOL
avant que le service de réplication de fichiers \ \ \ \ NT (NTFRS) ne crée ce dossier.
NOTE
De graves problèmes peuvent se produire si vous vous trompez en modifiant le Registre à l’aide de l’Éditeur du Registre
ou toute autre méthode. Vous risquez même de devoir réinstaller le système d’exploitation. Microsoft ne peut pas garantir
que ces problèmes puissent être résolus. Vous assumez l’ensemble des risques liés à la modification du Registre.
Pour contourner ce problème, définissez la valeur de Registre SysvolReady Flag sur 0, puis revenir à 1 dans le
Registre. Pour cela, procédez comme suit :
2. Recherchez la sous-clé suivante dans l’Éditeur du Registre :
3. Dans le volet d’informations, cliquez avec le bouton droit sur l’indicateur SysvolReady, puis cliquez sur
Modifier.
4. Dans la zone Données de la valeur, tapez 0, puis cliquez sur OK.
5. Dans le volet d’informations, cliquez avec le bouton droit sur l’indicateur SysvolReady, puis cliquez sur
Modifier.
NOTE
Netlogon partagera alors SYSVOL et le dossier scripts sera présent.
Le problème décrit dans la section Symptômes se produit dans le scénario suivant :
1. NTFRS place d’abord les modifications à l’emplacement suivant :
\\Windows Domaine SYSVOL \ \ DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Ensuite, NTFRS avertit Netlogon de partager SYSVOL en lui fixant la valeur 1 comme entrée de Registre
de l’indicateur SysvolReady.
2. NTFRS déplace et renomme ensuite les fichiers de l’emplacement mentionné à l’étape 1 vers le dossier
suivant :
\\Windows Domaine \ SYSVOL
3. Toutefois, si le service Netlogon lit très rapidement l’entrée d’indicateur SysvolReady dans le Registre, le
service Netlogon tente de partager le dossier de scripts de domaine SYSVOL Windows avant que \ \ \
NTFRS ne crée ce \ dossier. Par conséquent, le partage NETLOGON n’est pas créé.
Il se peut qu’un contrôleur de domaine
nouvellement promu ne puisse pas publier une fois
DCpromo terminé.
Cet article décrit un problème dans lequel un contrôleur de domaine nouvellement promu ne parvient pas à
publier une fois DCpromo terminé.
Symptômes
Il se peut qu’un contrôleur de domaine nouvellement promu ne parque pas à la publicité une fois DCpromo et
redémarrage terminés. Ce problème est spécifique aux contrôleurs de domaine participant à des domaines au
niveau fonctionnel où Sysvol est répliqué par la réplication du système de fichiers distribués (DFSR).
Cause
Il existe un problème de résolution de nom ou de connectivité réseau.
Résolution
Pour résoudre ce problème, choisissez l’une des options suivantes :
1. Résoudre tout problème possible de résolution de nom ou de connectivité réseau qui empêcherait la
communication avec l'« ordinateur parent » défini
2. Modifiez le Registre suivant pour pointer vers un contrôleur de domaine source disponible :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Seeding
SysVols\contoso.com
« Ordinateur parent"= » DC1.contoso.com »
DFSR est un moteur de réplication multi-maître utilisé pour répliquer des fichiers et des dossiers pour des
structures de système de fichiers distribués (DFS) et éventuellement le volume du système de domaine dans les
domaines de niveau fonctionnel. Les contrôleurs de domaine utilisant DFSR pour sysvol synchronisent
initialement leur contenu Sysvol après la synchronisation d’Active Directory par l’Assistant DCpromo et le
redémarrage de l’ordinateur.
Un contrôleur de domaine répliqué tentera de s’sourcer son contenu sysvol à partir du serveur à partir de lequel
il a utilisé le contexte d’attribution de noms de domaine pendant la promotion Active Directory en lisant la clé de
Registre « Ordinateur parent » sous :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Seeding SysVols\domain.com
NOTE
« Ordinateur parent » peut être défini automatiquement ou par un administrateur au cours de DCpromo.
Si le serveur défini par l'« ordinateur parent » devient indisponible après le redémarrage, la synchronisation
initiale du contenu sysvol est retardée jusqu’à ce que l’action de correction de la disponibilité du serveur sur le
réseau ait été restaurée.
Erreurs signalées dans le journal des événements DFSR :
Source : DFSR
Niveau : Error
Description :
Le service de réplication DFS n’a pas réussi à contacter le contrôleur de domaine pour accéder aux
informations de configuration. La réplication est arrêtée. Le service essaiera à nouveau au cours du prochain
cycle d’interrogation de configuration, qui aura lieu dans 60 minutes. Cet événement peut être dû à des
problèmes de connectivité TCP/IP, de pare-feu, de services de domaine Active Directory ou de DNS.
Source : DFSR
Niveau : Error
Description :
Le service de réplication DFS a initialisé SYSVOL au chemin local C : Windows domaine SYSVOL et attend
d’effectuer la \ \ \ réplication initiale. Le dossier répliqué reste à l’état de synchronisation initial jusqu’à ce
qu’il ait été répliqué avec son WIN-C0T0SC8MCEF.contoso.com partenaire. Si le serveur était en cours de
promotion vers un contrôleur de domaine, le contrôleur de domaine n’annonce et ne fonctionne pas en tant
que contrôleur de domaine tant que ce problème n’est pas résolu. Cela peut se produire si le partenaire
spécifié est également dans l’état de synchronisation initial, ou si des violations de partage sont rencontrées
sur ce serveur ou le partenaire de synchronisation. Si cet événement s’est produit lors de la migration de
SYSVOL du service de réplication de fichiers (FRS) vers la réplication DFS, les modifications ne seront pas
répliquées tant que ce problème n’aura pas été résolu. Cela peut entraîner la synchronisation du dossier
SYSVOL sur ce serveur avec d’autres contrôleurs de domaine.
Source : DFSR
Niveau : Error
Description :
qu’il ait été répliqué avec son partenaire DC1.contoso.com. Si le serveur était en cours de promotion vers un
contrôleur de domaine, le contrôleur de domaine n’annonce et ne fonctionne pas en tant que contrôleur de
domaine tant que ce problème n’est pas résolu. Cela peut se produire si le partenaire spécifié est également
dans l’état de synchronisation initial, ou si des violations de partage sont rencontrées sur ce serveur ou le
partenaire de synchronisation. Si cet événement s’est produit lors de la migration de SYSVOL du service de
réplication de fichiers (FRS) vers la réplication DFS, les modifications ne seront pas répliquées tant que ce
problème n’aura pas été résolu. Cela peut entraîner la synchronisation du dossier SYSVOL sur ce serveur
avec d’autres contrôleurs de domaine.
Source : DFSR
Niveau : Error
Description :
Le service de réplication DFS n’a pas réussi à communiquer avec le partenaire DC1 pour le groupe de
réplication Domain System Volume. Cette erreur peut se produire si l’hôte est inaccessible ou si le service de
réplication DFS n’est pas en cours d’exécution sur le serveur. Le service réessaye régulièrement la connexion.
Informations supplémentaires :
Erreur : 1722 (le serveur RPC n’est pas disponible.)
Source : DFSR
Description :
qu’il ait été répliqué avec son partenaire DC1.contoso.com. Si le serveur était en cours de promotion vers un
contrôleur de domaine, le contrôleur de domaine n’est pas libéré et fonctionne comme contrôleur de
domaine tant que ce problème n’est pas résolu. Cela peut se produire si le partenaire spécifié est également
dans l’état de synchronisation initial, ou si des violations de partage sont rencontrées sur ce serveur ou le
partenaire de synchronisation. Si cet événement s’est produit lors de la migration de SYSVOL du service de
réplication de fichiers (FRS) vers la réplication DFS, les modifications ne seront pas répliquées tant que ce
problème n’aura pas été résolu. Cela peut entraîner la synchronisation du dossier SYSVOL sur ce serveur
avec d’autres contrôleurs de domaine.
Nom du dossier répliqué : partage SYSVOL
Erreurs signalées dans les journaux de débogage DFSR :
ERROR: DownstreamTransport: SetupBinding Failed
Erreur : le serveur RPC n’est pas disponible.
Références :
FAQ sur la réplication du système de fichiers distribués
Informations supplémentaires sur la journalisation du débogage DFSR
DCpromo
Comment restaurer et restaurer le Registre dans Windows
Guide des opérations DNS Server
Clause d’exclusion de responsabilité
Microsoft et/ou ses fournisseurs n’offrent aucune représentation ou garantie quant à l’exactitude, la fiabilité ou
l’exactitude des informations contenues dans les documents et les graphiques associés publiés sur ce site web
(les « documents ») à quelque fin que ce soit. Les documents peuvent inclure des inexactitudes techniques ou
des erreurs typographiques et peuvent être révisés à tout moment sans préavis.
Dans la mesure maximale autorisée par la loi applicable, Microsoft et/ou ses fournisseurs délament et excluent
toutes les représentations, garanties et conditions, qu’elles soient express, implicites ou statutaires, y compris,
mais sans s’y limiter, à des représentations, des garanties ou des conditions de titre, de non-contrefaçon, de
qualité ou de condition satisfaisante, de qualité, de qualité et de qualité à un usage particulier, en ce qui concerne
le matériel.
Windows Le contrôleur de domaine Server 2008 et
les plus nouveaux retournent uniquement 5 000
valeurs dans une réponse LDAP
Cet article fournit une solution à un problème où le contrôleur de domaine Windows Server 2008 R2 ou plus
récent renvoie uniquement 5 000 valeurs pour une réponse LDAP.
Symptômes
Une application LDAP peut renvoyer moins d’informations lorsqu’une requête est envoyée à un contrôleur de
domaine Windows Server 2008 ou Windows Server 2008 R2 que lorsqu’elle est envoyée à un contrôleur de
domaine Windows Server 2003. Les résultats de la requête peuvent apparaître tronqués ou incomplets. Dans
certains cas, il se peut que vous n’obtenez aucun résultat. Par exemple, si une application LDAP interroge les
membres d’un groupe, le contrôleur de domaine Windows Server 2008 R2 ou Windows Server 2008 ne
retourne que 5 000 membres, tandis que les contrôleurs de domaine Windows Server 2003 renvoient
beaucoup plus de membres. Dans les deux cas, vous pouvez réaliser le même paramètre de stratégie LDAP
étendu dans NTDSUTIL requis pour l’application LDAP. Pour plus d’informations sur l’affichage des paramètres
de stratégie LDAP, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances
Microsoft :
315071 comment afficher et définir la stratégie LDAP dans Active Directory à l’aide de Ntdsutil.exe
Exemple de sortie :
Stratégie ldap : afficher les valeurs

Stratégie actuelle(Nouvelle)
MaxPoolThreads 4
MaxDatagramRecv 4096
MaxReceiveBuffer 10485760
InitRecvTimeout 120
MaxConnections 5000
MaxConnIdleTime 900
MaxPageSize 50000
MaxQueryDuration 120
MaxTempTableSize 10000
MaxResultSetSize, 262144
MinResultSets 0
MaxResultSetsPerConn 0
MaxNotificationPerConn 5
MaxValRange 25000
NOTE
Sur les deux contrôleurs de domaine, le paramètre MaxPageSize est fixé à 50000 (valeur par défaut 1000) et MaxValRange
à 25000 (valeur par défaut 1500).
Cause
Des limitations LDAP internes ont été introduites dans Windows Server 2008 R2 et Windows Server 2008 pour
éviter la surcharge du contrôleur de domaine. Ces limites ritent le paramètre de stratégie LDAP lorsque la valeur
de la stratégie doit être supérieure.
PA RA M ÈT RE L DA P VA L EUR M A XIM A L E ( C O DÉE EN DUR)
MaxReceiveBuffer 20971520
MaxPageSize 20000
MaxQueryDuration 1200
MaxTempTableSize 100000
MaxValRange 5000
Par conséquent, le paramètre effectif de la stratégie LDAP ci-dessus est MaxPageSize=50000 et

MaxValRange=25000 sur un contrôleur de domaine Windows Server 2003 tel que configuré dans la stratégie
LDAP, mais sur un contrôleur de domaine Windows Server 2008 R2 ou Windows Server 2008, les limites
codées en dur dictent MaxPageSize=20000 et MaxValRange=5000.
MaxValRange affecte le nombre d’attributs renvoyés pour une requête. Si vous effectuez une requête LDAP pour
l’attribut à valeurs multiples Member pour un objet groupe de plus de 5 000 membres, le contrôleur de
domaine Windows Server 2008 R2 ou Windows Server 2008 ne retournera que 5 000 d’entre eux.
Résolution
Les nouvelles limites maximales introduites avec Windows Server 2008 R2 et Windows Server 2008 tentent
d’appliquer le message que les applications doivent adopter aux stratégies que AD souhaite appliquer. Vous
devez adapter votre application LDAP en conséquence. Pour la limitation MaxValRange, vous pouvez prendre en
compte les exemples et les informations MSDN suivants pour l’utilisation de requêtes à plage : Récupération de
plage de valeurs d’attribut https://msdn.microsoft.com/library/cc223242(PROT.10).aspx
L’exemple de code suivant utilise allant jusqu’à récupérer les membres d’un groupe à l’aide de l’interface
IDirectoryObject : exemple de code pour Ranging avec IDirectoryObject
https://msdn.microsoft.com/library/aa705923(VS.85).aspx
L’exemple de code suivant utilise allant jusqu’à récupérer les membres d’un groupe à l’aide de l’interface
IDirectorySearch : exemple de code pour Ranging avec IDirectorySearch
https://msdn.microsoft.com/library/aa705924(VS.85).aspx
Pour MaxPageSize, il est recommandé d’utiliser des requêtes paginées, décrites sur MSDN comme suit :
Pagination des résultats de recherche https://msdn.microsoft.com/library/aa367011(VS.85).aspx
ldap_create_page_control, fonction https://msdn.microsoft.com/library/aa366547(VS.85).aspx
Il existe un moyen de remplacer ces limitations, mais nous vous encourageons à discuter des exigences avec le
support technique du client Microsoft pour décider si la modification des stratégies est l’approche correcte.
Pour plus d’informations sur les stratégies LDAP, consultez les stratégies LDAP
https://msdn.microsoft.com/library/cc223376(PROT.10).aspx
Le contrôleur de domaine ne fonctionne pas
correctement
Cet article fournit des solutions courantes au problème selon lequel le contrôleur de domaine ne fonctionne pas
correctement.
Symptômes
Quand vous exécutez l’outil Dcdiag sur un contrôleur de domaine Microsoft Windows 2000 Server ou Windows
Server 2003, le message d’erreur suivant peut s’afficher :
Diagnostic du contrôleur de domaine

Exécution de l’installation initiale :
[DC1] La liaison LDAP a échoué avec l’erreur 31
Quand vous utilisez l’utilitaire REPADMIN /SHOWREPS en local sur un contrôleur de domaine, l’un des messages
d’erreur ci-dessous peut s’afficher :
[D:\nt\private\ds\src\util\repadmin\repinfo.c, 389] Erreur LDAP 82 (Erreur locale).
La dernière tentative le aaaa-mm-jj hh:mm.ss a échoué, résultat 1753 : Le mappeur de point final n’a plus de
point final disponible.
La dernière tentative le aaaa-mm-jj hh:mm.ss a échoué, résultat 5 : Accès refusé.
Si vous utilisez l’utilitaire Sites et services Active Directory pour déclencher la réplication, un message indiquant
que l’accès est refusé peut s’afficher.
Quand vous essayez d’utiliser des ressources réseau à partir de la console d’un contrôleur de domaine affecté, y
compris des ressources UNC (Universal Naming Convention) ou des lecteurs réseau mappés, le message
d’erreur ci-dessous peut s’afficher :
Aucun serveur d’accès disponible (c000005e = "STATUS_NO_LOGON_SERVERS")
Si vous démarrez des outils d’administration Active Directory à partir de la console d’un contrôleur de domaine
affecté, y compris Sites et services Active Directory et Utilisateurs et ordinateurs Active Directory, l’un des
messages d’erreur ci-dessous peut s’afficher :
Les informations de nom ne peuvent pas être trouvées car : Aucune autorité n’a pu être contactée pour
l’authentification. Contactez votre administrateur système pour vérifier que le domaine est correctement
configuré et qu’il est en ligne.
Les informations de nom ne peuvent pas être trouvées car : Le nom du compte cible est incorrect. Contactez
votre administrateur système pour vérifier que le domaine est correctement configuré et qu’il est en ligne.
Les clients Microsoft Outlook connectés à des ordinateurs Microsoft Exchange Server qui utilisent des
contrôleurs de domaine affectés à des fins d’authentification peuvent être invités à entrer des informations
d’identification d’ouverture de session, même si l’authentification de connexion a réussi à partir d’autres
L’outil Netdiag peut afficher les messages d’erreur suivants :
DC list test. . . . . . . . . . . : Failed

[WARNING] Cannot call DsBind to <servername>.<fqdn> (<ip address>).
[ERROR_DOMAIN_CONTROLLER_NOT_FOUND]
Kerberos test. . . . . . . . . . . : Failed
[FATAL] Kerberos does not have a ticket for krbtgt/<fqdn>.
[FATAL] Kerberos does not have a ticket for <hostname>.
LDAP test. . . . . . . . . . . . . : Passed
[WARNING] Failed to query SPN registration on DC <hostname><fqdn>
L’événement suivant peut être consigné dans le journal des événements système du contrôleur de domaine
affecté :
Event Type: Error

Event Source: Service Control Manager
Event ID: 7023
Description: The Kerberos Key Distribution Center service terminated with the following error: The security
account manager (SAM) or local security authority (LSA) server was in the wrong state to perform the
security operation.
Résolution
Plusieurs résolutions sont possibles pour ces symptômes. Voici une liste de méthodes à essayer. Cette liste est
suivie des étapes à effectuer pour chaque méthode. Essayez chaque méthode jusqu’à ce que le problème soit
résolu. Les articles de la Base de connaissances Microsoft qui décrivent des correctifs moins courants pour ces
symptômes sont répertoriés en fin d’article.
1. Méthode 1 : Corriger les erreurs DNS (Domain Name System).
2. Méthode 2 : Synchroniser l’heure entre les ordinateurs.
3. Méthode 3 : Vérifier les droits d’utilisateur Accéder à cet ordinateur à par tir du réseau .
4. Méthode 4 : Vérifier que l’attribut userAccountControl du contrôleur de domaine est 532480.
5. Méthode 5 : Corriger le domaine Kerberos (vérifier que les clés de Registre PolAcDmN et PolPrDmN
correspondent).
6. Méthode 6 : Réinitialiser le mot de passe du compte d’ordinateur, puis obtenir un nouveau ticket Kerberos.
Méthode 1 : Corriger les erreurs DNS
1. Dans une invite de commandes, exécutez la commande netdiag -v . Cette commande crée un fichier
Netdiag.log dans le dossier où la commande a été exécutée.
2. Résolvez les erreurs DNS éventuelles dans le fichier Netdiag.log avant de continuer. L’outil Netdiag se trouve
dans les outils de support de Windows 2000 Server inclus sur le CD-ROM de Windows 2000 Server ou est
disponible au téléchargement.
3. Assurez-vous que le système DNS est configuré correctement. L’une des erreurs DNS les plus courantes
consiste à pointer le contrôleur de domaine vers un fournisseur de services Internet (ISP) pour DNS au lieu
de pointer le système DNS vers lui-même ou vers un autre serveur DNS qui prend en charge les mises à jour
dynamiques et les enregistrements SRV. Il est recommandé de pointer le contrôleur de domaine vers lui-
même ou vers un autre serveur DNS qui prend en charge les mises à jour dynamiques et les
enregistrements SRV. Il est également recommandé de configurer des redirecteurs vers le fournisseur de
services Internet pour la résolution de noms sur Internet.
Pour plus d’informations sur la configuration du système DNS pour le service d’annuaire Active Directory,
cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
254680 Planification de l’espace de noms DNS
Méthode 2 : Synchroniser l’heure entre les ordinateurs
Vérifiez que l’heure est correctement synchronisée entre les contrôleurs de domaine, ainsi qu’entre les
ordinateurs clients et les contrôleurs de domaine.
Méthode 3 : Vérifier les droits d’utilisateur « Accéder à cet ordinateur à partir du réseau »
Modifiez le fichier Gpttmpl.inf pour vérifier que les utilisateurs appropriés disposent des droits d’utilisateur
Accéder à cet ordinateur à par tir du réseau sur le contrôleur de domaine. Pour cela, procédez comme suit :
1. Modifiez le fichier Gpttmpl.inf pour la stratégie des contrôleurs de domaine par défaut. Par défaut, la
stratégie par défaut des contrôleurs de domaine est l’endroit où les droits des utilisateur sont définis pour
un contrôleur de domaine. Par défaut, le fichier Gpttmpl.inf de la stratégie par défaut des contrôleurs de
domaine se trouve dans le dossier suivant.
NOTE
Sysvol peut se trouver à un autre endroit, mais le chemin d’accès au fichier Gpttmpl.inf sera le même.
Pour les contrôleurs de domaine Windows Server 2003 :

C:\WINDOWS\Sysvol\Sysvol\<Domainname>\Policies\{6AC1786C-016F-11D2-945F-
00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf
Pour les contrôleurs de domaine Windows 2000 Server :
C:\WINNT\Sysvol\Sysvol\<Domainname>\Policies\{6AC1786C-016F-11D2-945F-
00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf
2. À droite de l’entrée SeNetworkLogonRight, ajoutez les identifiants de sécurité pour les administrateurs,
pour les utilisateurs authentifiés et pour tout le monde. Reportez-vous aux exemples suivants.
Pour les contrôleurs de domaine Windows Server 2003 :
SeNetworkLogonRight = *S-1-5-32-554,*S-1-5-9,*S-1-5-32-544,*S-1-1-0
Pour les contrôleurs de domaine Windows 2000 Server :
SeNetworkLogonRight = *S-1-5-11,*S-1-5-32-544,*S-1-1-0
NOTE
Les administrateurs (S-1-5-32-544), les utilisateurs authentifiés (S-1-5-11), tout le monde (S-1-1-0) et les
contrôleurs d’entreprise (S-1-5-9) utilisent des identifiants de sécurité bien connus qui sont les mêmes dans tous
les domaines.
3. Supprimez toutes les entrées à droite de l’entrée SeDenyNetworkLogonRight (refuser l’accès à cet
ordinateur depuis le réseau) pour qu’elles correspondent à l’exemple suivant.
SeDenyNetworkLogonRight =
NOTE
L’exemple est le même pour Windows 2000 Server et pour Windows Server 2003.
Par défaut, Windows 2000 Server n’a aucune entrée dans l’entrée SeDenyNetworkLogonRight. Par défaut,
Windows Server 2003 n’a que le compte de chaîne Support_random dans l’entrée
SeDenyNetworkLogonRight. (Le compte de chaîne Support_random est utilisé par l’assistance à distance)
Comme le compte de chaîne Support_random utilise un identificateur de sécurité (SID) différent dans
chaque domaine, on peut facilement le confondre avec un compte d’utilisateur classique si l’on se fie
simplement à l’identificateur de sécurité. Vous pouvez copier l’identificateur de sécurité dans un autre
fichier texte, puis le supprimer de l’entrée SeDenyNetworkLogonRight. Ainsi, vous pourrez le remettre en
place lorsque vous aurez fini de résoudre le problème.
SeNetworkLogonRight et SeDenyNetworkLogonRight peuvent être définis dans n’importe quelle
stratégie. Si les étapes précédentes ne permettent pas de résoudre le problème, vérifiez le fichier
Gpttmpl.inf dans d’autres stratégies de Sysvol pour confirmer que les droits de l’utilisateur n’y sont pas
également définis. Si un fichier Gpttmpl.inf ne contient aucune référence à SeNetworkLogonRight ou
SeDenyNetworkLogonRight, ces paramètres ne sont pas définis dans la stratégie et cette dernière n’est
pas à l’origine de ce problème. Si ces entrées existent, assurez-vous qu’elles correspondent aux
paramètres répertoriés précédemment pour la stratégie par défaut des contrôleurs de domaine.
Méthode 4 : vérifier que l’attribut userAccountControl du contrôleur de domaine est 532480
1. Cliquez sur Démarrer , puis sur Exécuter et saisissez adsiedit.msc.
2. Développez les objets suivants : Domain NC , puis DC=domain et enfin OU=Domain Controllers .
3. Cliquez avec le bouton droit sur le contrôleur de domaine affecté, puis sélectionnez Propriétés .
4. Sous Windows Server 2003, activez les cases Afficher les attributs obligatoires et Afficher les
attributs facultatifs sous l’onglet Éditeur d’attributs . Sous Windows 2000 Server, cliquez sur Les deux
dans la zone Sélectionner les propriétés à afficher .
5. Sous Windows Server 2003, cliquez sur userAccountControl dans la zone Attributs . Sous
Windows 2000 Server, cliquez sur userAccountControl dans la zone Sélectionner une propriété à
afficher .
6. Si la valeur n’est pas 532480, saisissez 532480 dans la zone Modifier l’attribut , puis cliquez sur Définir ,
sur Appliquer et sélectionnez OK .
7. Quittez Modification ADSI.
Méthode 5 : corriger le domaine Kerberos (vérifier que les clés de Registre PolAcDmN et PolPrDmN
correspondent)
NOTE
Cette méthode ne s’applique qu’à Windows 2000 Server.
IMPORTANT
restaurer en cas de problème. Pour plus d'informations sur la procédure de sauvegarde et de restauration du Registre,
cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
1. Démarrez l’Éditeur du Registre .

2. Dans le volet de navigation, développez Sécurité .
3. Dans le menu Sécurité , cliquez sur Autorisations pour accorder au groupe local des administrateurs
le contrôle total de la ruche SECURITY et de ses conteneurs et objets enfants.
4. Recherchez la clé nommée HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN .
5. Dans le volet droit de l’Éditeur du Registre , cliquez une fois sur l’entrée <No Name>: REG_NONE .
6. Dans le menu Affichage , cliquez sur Affichage des données binaires . Dans la section Format de la boîte
de dialogue, cliquez sur Octet .
7. Le nom de domaine apparaît sous forme de chaîne dans le côté droit de la boîte de dialogue Données
binaires . Le nom de domaine est le même que le domaine Kerberos.
8. Localisez la clé de Registre HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN .
9. Dans le volet droit de l’Éditeur du Registre , double-cliquez sur l’entrée <No Name>: REG_NONE .
10. Dans la boîte de dialogue Éditeur binaire , collez la valeur de PolPrDmN. (la valeur à partir de PolPrDmN
sera le nom de domaine NetBIOS).
Méthode 6 : réinitialiser le mot de passe du compte ordinateur, puis obtenir un nouveau ticket Kerberos
1. Arrêtez le service Centre de distribution de clés Kerberos , puis réglez la valeur de démarrage sur
Manuel .
2. Utilisez l’outil Netdom, à partir des outils de support de Windows 2000 Server ou Windows Server 2003,
pour réinitialiser le mot de passe du compte ordinateur du contrôleur de domaine :
netdom resetpwd /server: <another domain controller> /userd:domain\administrator /passwordd:

<administrator password>
Assurez-vous que la netdom commande est retournée comme effectuée avec succès. Dans le cas
contraire, la commande n’a pas fonctionné. Pour le domaine Contoso, où le contrôleur de domaine affecté
est DC1 et un contrôleur de domaine fonctionnel est DC2, vous exécutez la commande suivante netdom
depuis la console du DC1 :
netdom resetpwd /server:DC2 /userd:contoso\administrator /passwordd: <administrator password>
3. Redémarrez le contrôleur de domaine affecté.

4. Démarrez le service Centre de distribution de clés Kerberos , puis réglez le paramètre de démarrage
sur Automatique .
Pour plus d’informations sur ce problème, cliquez sur les numéros ci-dessous pour afficher les articles
correspondants dans la Base de connaissances Microsoft :
323542 Vous ne pouvez pas démarrer l’outil Utilisateurs et ordinateurs Active Directory, car le serveur n’est pas
opérationnel
Les requêtes LDAP sont exécutées plus lentement
que prévu dans le service d’annuaire AD ou
LDS/ADAM et l’ID d’événement 1644 peut être
enregistré
Cet article fournit une solution de contournement pour un problème dans lequel les requêtes LDAP
fonctionnent lentement sur un ordinateur Windows Server qui utilise un service d’annuaire AD LDS ou ADAM.
Symptômes
Sur un ordinateur Windows Server qui utilise un service d’annuaire AD LDS (Active Directory Lightweight
Directory Services) ou Active Directory Application Mode (AD/AM), certaines applications ne s’exécutent pas aux
niveaux de performances attendus.
Lorsque vous activez la journalisation d’ingénierie de champ (débogage) pour suivre une requête LDAP, le
journal des événements suivant indique que la requête LDAP est une requête inefficace.
NOTE
Les attributs utilisés dans cet événement ne sont que des exemples.
En outre, l’utilisation du processeur est élevée et le temps de réponse est lent. Si la base de données est
beaucoup plus grande que la mémoire physique disponible pour le serveur d’annuaire, vous pouvez également
voir une augmentation des IO de disque pendant le traitement d’une telle requête.
Lorsque vous examinez les attributs dans le filtre de recherche, vous constatez qu’ils ont tous des index définis.
Et si les attributs n’ont pas d’index définis et que vous ajoutez les index par le biais d’une modification de
schéma, le problème persiste ou ne s’améliore pas beaucoup.
Cause
Lorsque vous créez une trace réseau de la requête LDAP, vous remarquez qu’il s’agit d’une requête pagiée.
Le serveur LDAP ne peut utiliser qu’un seul index lors du traitement d’une requête pagiée. Cela est dû au fait
que l’implémentation LDAP pour les recherches pagiées ne crée pas de contexte coûteux pour la requête et
n’utilise donc qu’un seul index pour une requête pagiée.
Pour contourner ce problème, vous pouvez envoyer la requête sans utiliser le contrôle de requête pagiée. Cela
permet au serveur LDAP d’optimiser les filtres plus complexes.
NOTE
Par défaut, les requêtes pagyée sont activées pour certaines bibliothèques clientes LDAP. Par conséquent, vous de devez
peut-être écrire du code supplémentaire dans votre application pour activer et désactiver les requêtes pagyée selon votre
situation spécifique.
Statut
Microsoft a confirmé qu’il s’agit d’un problème.
Références
Comment configurer la journalisation des événements de diagnostic Active Directory et LDS
Comment résoudre les problèmes d’utilisation
Lsass.exe processeur élevée sur les contrôleurs de
domaine Active Directory
Cet article résout la forte utilisation Lsass.exe processeur sur les contrôleurs de domaine Active Directory.
Symptômes
Vous pouvez voir ce problème des manières suivantes :
Une alerte System Center advisor a été déclenchée. Il rappelle que le processus Lsass.exe utilise un
pourcentage constamment élevé des fonctionnalités de l’UC (compteur d’utilisation du processeur).
Un contrôleur de domaine répond lentement ou ne répond pas du tout aux demandes d’authentification ou
de recherche d’annuaire du service client.
Les clients de domaine Active Directory arrêtent régulièrement ou fréquemment de demander le service à un
contrôleur de domaine. Au lieu de cela, ils localisent un contrôleur de domaine différent à partir de qui
obtenir des services.
L’analyse des performances à l’aide de Perfmon.msc ou du Gestionnaire des tâches révèle que le processus
Lsass.exe utilise un pourcentage constamment élevé des fonctionnalités de l’UC (objet Process, compteur %
temps processeur).
Cause
Ce problème peut être dû à de nombreux problèmes simples ou combinés différents. Presque chaque cause et
résolution de ces problèmes est unique. Dans Windows Server 2008 et les ultérieures, l’outil suivant est
disponible pour vous aider à déterminer la cause du problème :
Ensemble de collecteurs de données Active Directory de l’analyseur de performances
Résolution
Pour résoudre ce problème, exécutez le jeu de collecteurs de données Active Directory de l’analyseur de
performances sur le contrôleur de domaine pendant que le problème se produit. Cet outil utilise des compteurs
de performance et le suivi pour surveiller le problème. Il compile ensuite un rapport qui affiche les détails des
problèmes potentiels. Ces problèmes doivent être examinés en tant que causes possibles.
Pour exécuter le collecteur de données Active Directory, suivez les étapes suivantes :
1. Ouvrez le Gestionnaire de serveur sur une version complète de Windows Server 2008 ou version ultérieure,
ou sélectionnez Démarrer Exécuter > > Perfmon.msc, puis appuyez sur Entrée.
2. Développez Diagnostics > Reliability and Performance Data Collector > Sets > System .
3. Cliquez avec le bouton droit sur Diagnostics Active Directory, puis sélectionnez Démarrer dans le menu qui
s’affiche.
4. Le paramètre par défaut collecte les données du rapport pendant 300 secondes (5 minutes). Ensuite, la
compilation du rapport prendra un délai supplémentaire. La durée nécessaire pour compiler le rapport est
proportionnelle à la quantité de données recueillies.
Une fois le rapport compilé, allez à Diagnostics > Reliability and Performance > Repor ts > System >
Active Director y Diagnostics . Afficher le ou les rapports qui ont été terminés.
Le rapport contient huit grandes catégories sous Résultats de diagnostic qui contiendra des informations et
des conclusions dans le rapport. Il n’indique pas toujours la cause exacte du problème. Mais vous pouvez
l’utiliser pour déterminer où rechercher la cause exacte.
En cas d’utilisation élevée du processeur par Lsass.exe, vérifiez la partie Résultats de diagnostic du rapport. Il
présente des problèmes de performances généraux. Examinez également la catégorie Active Directory. Il détaille
les actions que le contrôleur de domaine est occupé à ce moment-là. Par exemple, les requêtes LDAP qui
affectent les performances.
Les contrôleurs de domaine sont souvent les plus impactés par les requêtes à distance provenant d’ordinateurs
de l’environnement qui demandent des requêtes coûteuses. Ils sont également soumis à un volume de requêtes
plus élevé. La par tie Réseau du rapport est utile pour déterminer les clients distants qui communiquent le plus
avec le contrôleur de domaine pendant que le diagnostic collecte des données.
Le service de sous-système d’autorité de sécurité locale (Lsass.exe) est le processus sur un contrôleur de
domaine Active Directory. Il est responsable de la fourniture de recherche, d’authentification et de réplication de
base de données Active Directory.
Pour plus d’informations sur la résolution des problèmes d’utilisation élevée du processeur du processus
Lsass.exe sur un contrôleur de domaine Active Directory, voir Son of SPA: AD Data Collector Sets in Win2008
and beyond.
Problèmes liés au dépassement des valeurs de
backlog des demandes de réplication AD et des rpc
Netlogon
Cet article explique comment configurer la réplication Active Directory (AD) et les valeurs de backlog des
demandes d’appels de procédure distante (RPC) Netlogon dans Windows Server.
Vous rencontrez l’un des problèmes suivants :
Les réinitialisations TCP (Transmission Control Protocol) se produisent fréquemment, mais une analyse de
trace réseau ne fournit pas la cause racine.
Les serveurs Microsoft Exchange reçoivent des erreurs 401 par intermittence lors de l’authentification au
niveau des contrôleurs de domaine.
Les serveurs Exchange ne parviennent pas à se connecter aux contrôleurs de domaine et signalent « Le
serveur n’est pas disponible ».
Microsoft Outlook demande à plusieurs reprises les informations d’identification de l’utilisateur lors de
l’authentification au sein d’un contrôleur de domaine.
Vous recevez ce message d’erreur lorsque vous vous connectez :
« La relation d’approbation entre cette station de travail et le domaine principal a échoué. »
Vous pouvez également voir les événements suivants dans Windows Server :
Event Log: System

Event Type: Error
Event ID: 3210
Event Text:
This computer could not authenticate with [file://%3cDomain]\\<Domain Controller Name>.<Domain Name>,
a Windows domain controller for domain <Domain Name>, and therefore this computer might deny logon
requests.
This inability to authenticate might be caused by another computer on the same network using the same
name or the password for this computer account is not recognized. If this message appears again,
contact your system administrator.
Event Log: System
Event Type: Error
Event ID: 5719
Event Text:
This computer was not able to set up a secure session with a domain controller in domain <Domain
Name> due to the following:
The remote procedure call failed and did not execute.
This may lead to authentication problems. Make sure that this computer is connected to the network.
If the problem persists, please contact your domain administrator.
Event Log: System

Event Type: Error
Event Source: Microsoft-Windows-Security-Kerberos
Event ID: 7
Event Text:
The digitally signed Privilege Attribute Certificate (PAC) that contains the authorization
information for client <Hostname>$ in realm <Domain Name> could not be validated.
Événements après l’installation des mises à jour windows en

préversion juin 2022
Windows Server 2019 23 juin 2022 —KB5014669 (build du système d’exploitation 17763.3113) Mise à jour en
préversion et Windows Server 2022 23 juin 2022 — KB5014665 (build du système d’exploitation 20348.803)
Mise à jour en préversion signalent le problème et ajustent les paramètres du backlog de demande RPC. Après
avoir installé ces mises à jour, vous pouvez recevoir les événements suivants.
Le service Netlogon démarre correctement avec la taille de backlog RPC donnée.
Event Log: System

Event Type: Info
Event ID: 5836
Event Text:
The Netlogon service was able to bind to a TCP/IP port with the configured backlog size of
<Configured Backlog Size>
Échec de la taille du backlog lié au service Netlogon.
Event Log: System

Event Type: Warning
Event ID: 5837
Event Text:
The Netlogon service tried to bind to a TCP/IP port with the configured backlog size of <Configured
RPC Backlog Size> but failed.
More information can be found in the following log file '%SystemRoot%\debug\netlogon.log' and,
potentially, in the log file '%SystemRoot%\debug\netlogon.bak' created if the former log becomes
full. For steps in enabling the log, please visit https://go.microsoft.com/fwlink/?linkid=2163327.
Échec de la limite de backlog liée à la réplication Active Directory.

Event Log: Active Directory Domain Services
Event Type: Warning
Event Source: ActiveDirectory_DomainService
Event ID: 3042
Event Text:
Active Directory Domain Services could not configure the TCP port with the backlog limit as specified
in registry.
Additional Data
TCP Port:
<Configured Port>
Configured backlog limit:
<Backlog Limit Configured on Port>
Registry backlog limit:
<Backlog Limit Specified in Registry>
User Action:
Make sure the same TCP port is not being used by other services such as Netlogon and the Active
Directory Domain Controller has been rebooted after configuring the backlog limit value in registry.
La valeur limite du backlog est dépassée

Les ports TCP/IP (Transmission Control Protocol/Internet Protocol) inscrits pour la réplication AD et les rpc pour
le service Netlogon sont configurés avec une valeur limite de backlog. La valeur par défaut est 10. Cette valeur
représente le nombre maximal de requêtes pouvant être mises en file d’attente sur le port TCP/IP inscrit.
Lorsque la valeur limite du backlog est dépassée, les paquets SYN TCP sont immédiatement réinitialisés par la
couche RPC sur le serveur. Ce comportement affecte l’authentification sur les systèmes.
Augmenter la valeur limite du backlog RPC pour DRSUAPI et

Netlogon
IMPORTANT
Cette section contient des instructions pour modifier le Registre. De graves problèmes peuvent se produire si le Registre
est modifié de manière incorrecte. Par précaution, sauvegardez le registre avant de le modifier. Pour plus d’informations
sur la procédure à suivre pour sauvegarder, restaurer et modifier le Registre, consultez l’article Comment sauvegarder et
restaurer le Registre dans Windows.
Vous pouvez utiliser l’Éditeur du Registre pour augmenter les valeurs limites du backlog RPC pour DRSUAPI et
le service Netlogon comme suit :
NOTE
Nous recommandons aux administrateurs de configurer les valeurs appropriées dans les clés de Registre. De grandes
valeurs sur vos serveurs Windows peuvent entraîner de grandes quantités d’utilisation de la mémoire du pool non
pagagé. Les administrateurs doivent équilibrer l’encombrement de la mémoire et les exigences d’extensibilité.
Clé de Registre pour DRSUAPI

Clé de Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Valeur du Registre : Limite du backlog TCP/IP
Données de valeur : toute valeur comprise entre 10 et 100
Redémarrez le système pour que le paramètre prenne effet.
Clé de Registre pour Netlogon
Clé de Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Valeur du Registre : DcTcpipBacklogLimit
Données de valeur : toute valeur comprise entre 10 et 100
Redémarrez le service Netlogon pour que le paramètre prenne effet. Vous devrez peut-être également
redémarrer le contrôleur de domaine.
LDAP et Kerberos Server peuvent réinitialiser les
sessions TCP immédiatement après leur création
Cet article fournit une solution à un problème de réinitialisation des sessions TCP créées sur les ports de serveur
88, 389 et 3268. Les sessions utilisant SSL (Secure Sockets Layer) ou TLS (Transport Layer Security) sur les ports
636 et 3269 sont également affectées.
Symptômes
Vous exécutez les rôles Windows Server Active Directory Domain Services (AD DS) ou AD LDS (Active Directory
Lightweight Directory Services). De manière sporadique, vous pouvez voir que les sessions TCP créées sur les
ports de serveur 88, 389 et 3268 sont réinitialisées. Les sessions utilisant SSL (Secure Sockets Layer) ou TLS
(Transport Layer Security) sur les ports 636 et 3269 sont également affectées.
Dans le suivi du trafic réseau, vous voyez l’image avec la réinitialisation TCP (ou RST) est envoyée par le serveur
presque immédiatement après l’ouverture de la session à l’aide de l’établir avec une négociation TCP triple. Le
client peut être en mesure d’envoyer des données de demande avant l’envoi de la réinitialisation, mais cette
demande n’est pas répondue et les données ne sont pas reconnues.
Cause
Deux problèmes peuvent se produire :
1. Analyse de session inactive incorrecte :
La bibliothèque qui gère les sessions TCP pour le serveur LDAP et le centre de distribution de clés
Kerberos (KDC) utilise un thread de nettoyage pour surveiller les sessions inactives et déconnecte ces
sessions si elles sont trop longues. Le thread de nettoyage s’exécute toutes les 30 secondes pour nettoyer
ces sessions.
L’entrée de Registre KDC NewConnectionTimeout contrôle la durée d’inactivité, en utilisant une valeur par
défaut de 10 secondes. Toutefois, en fonction de l’implémentation du nettoyage, l’intervalle effectif est de
0 à 30 secondes. Par conséquent, les sessions nouvellement créées peuvent être déconnectées
immédiatement par le serveur de manière ponctuelle.
2. Protection de port client incorrecte :
Le KDC dispose également d’une protection intégrée contre les boucles de demandes et bloque les ports
clients 88 et 464. Toutefois, l’implémentation présente un bogue dans l’ordre d’byte, de sorte que les
ports 22528 et 53249 sont effectivement bloqués. En fonction de la version du système d’exploitation du
client et des ports TCP éphémères autorisés, vous pouvez ou non rencontrer ce problème.
Résolution
Pour les ports KDC, de nombreux clients, y compris le client Windows Kerberos, effectuent une nouvelle
tentative, puis obtiennent une coche de temps complète pour travailler sur la session. Les applications LDAP ont
plus de chances de considérer la réinitialisation de la connexion comme un échec fatal.
Si vous souhaitez éviter les réinitialisations sur les ports 22528 et 53249, vous devez les exclure de la plage
éphémère de ports. Pour plus d’informations, voir La plage de ports dynamiques par défaut pour TCP/IP a
changé dans Windows Vista et dans Windows Server 2008,qui s’applique également à Windows Vista et aux
versions ultérieures.
Lorsque vous définissez NewConnectionTimeout sur 40 ou plus, vous recevez une fenêtre de délai d’arrêt
de 30 à 90 secondes. Lorsque vous utilisez 70 ou plus, vous recevez de 60 à 120 secondes pour le délai
d’avance. Pour plus d’informations sur la valeur de Registre NewConnectionTimeout, voir les entrées de
Registre du protocole Kerberoset les clés de configuration KDC dans Windows .
Réponse retardée du contrôleur de domaine aux
demandes LDAP ou Kerberos
Cet article fournit de l’aide pour résoudre les problèmes de performances (tels que les retards d’Outlook et les
Outlook) qui se produisent après la mise à niveau de vos contrôleurs de domaine( DCS).
Symptômes
Après la mise à niveau de vos DCS, ce problème peut vous être affecté. Les symptômes possibles sont les
retards d’Outlook et d’autres problèmes d’application, ce qui augmente Exchange file d’attente.
Un indicateur plus évident est l’avertissement d’événement Netlogon 5807 sur le dc de réponse lente avec un
nombre élevé de clients, comme les suivants :

Utilisateur : N/A
Ordinateur : <MyW2k8R2DC1>
Description : Au cours des dernières 4,23 heures, il y a eu 123 450 connexions à ce contrôleur de domaine à
partir d’ordinateurs clients dont les adresses IP ne sont mélis es sur aucun des sites existants dans
l’entreprise. Par conséquent, ces clients ont des sites non définies et peuvent se connecter à n’importe quel
contrôleur de domaine, y compris ceux se trouver à des emplacements distants des clients. Le site d’un client
est déterminé par le mappage de son sous-réseau à l’un des sites existants. Pour déplacer les clients ci-
dessus vers l’un des sites, envisagez de créer des objets de sous-réseau couvrant les adresses IP ci-dessus
avec un mappage vers l’un des sites existants. Les noms et adresses IP des clients en question ont été
enregistrés sur cet ordinateur dans le fichier journal suivant « %SystemRoot%\debug\netlogon.log » et,
éventuellement, dans le fichier journal « %SystemRoot%\debug\netlogon.bak » créé si l’ancien journal
devient plein. Les journaux peuvent contenir d’autres informations de débogage non liées. Pour filtrer les
informations nécessaires, recherchez les lignes qui contiennent le texte NO_CLIENT_SITE:'. Le premier mot
après cette chaîne est le nom du client et le deuxième mot est l’adresse IP du client. La taille maximale des
journaux est contrôlée par la valeur DWORD du Registre suivante ; la valeur par défaut est
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize 20000000 octets.
La taille maximale actuelle est de 20 000 000 octets. Pour définir une taille maximale différente, créez la
valeur de Registre ci-dessus et définissez la taille maximale souhaitée en octets.
Cause
Pour les IP clientes non mappées sur le site, un dc effectue la résolution de noms, car depuis Vista et
l’introduction d’IPv6, un client peut avoir plusieurs IP. L’adresse IP que le client utilise pendant la commande ping
LDAP UDP Netlogon pour contacter le dc n’est peut-être pas la seule disponible. Si le dc n’a pas de sous-réseau
configuré pour cette adresse IP, il tente de trouver un autre réseau ayant un mappage et retourne le nom de site
en fonction au client.
Selon le mécanisme de résolution de noms configuré sur le dc, cette résolution de nom peut prendre quelques
secondes. Pendant ce temps, la demande LDAP Ping contient un thread ATQ provenant d’un pool ATQ limité. Un
nombre élevé de pings LDAP non mappés sur le site peut saturer ce pool. Étant donné que d’autres demandes
LDAP et Kerberos ont également besoin de ce pool, elles peuvent également être affectées.
Le programme d’installation classique lors de l’étape de ce problème est une forêt de ressources client avec une
forêt de ressources de confiance, où les segments IP du client n’ont pas de correspondance sous-réseau/site
dans la forêt de ressources. Les DCS de forêt de ressources peuvent enregistrer l’avertissement d’événement
Netlogon 5807 avec un nombre élevé de clients.
Résolution
Une mise à jour a été publiée pour permettre la mise à jour de cette recherche DNS :
2922852 update résout un problème dans lequel les réponses LDAP, Kerberos et dc locator sont lentes ou ont
un délai d’Windows
Vous pouvez appliquer la solution de contournement :
créer des sous-réseaux/sites correspondants, éviter Netlogon 5807 avec un nombre élevé de connexions
non mappées
augmentez MaxPoolThreads à 10 références (nombres par cœur). 315071 Comment afficher et définir la
stratégie LDAP dans Active Directory à l’aide de Ntdsutil.exe
optimiser la résolution de nom de dc, désactiver Netbios ou utiliser P-Node lorsque WINS est obligatoire.
Chapitre 11 - NetBIOS sur TCP/IP - Microsoft TechNet : Ressources
Analyse du compteur de performances ATQ (Active Thread Queue) : « Surveillance de votre environnement de
Office de succursale »,https://technet.microsoft.com/library/dd736504(WS.10).aspx
Utiliser Event1644Reader.ps1 pour analyser les
performances des requêtes LDAP dans Windows
Server
Cet article décrit un script qui permet d’analyser l’ID d’événement Active Directory 1644 dans Windows Server.
Examinez les étapes à suivre pour utiliser le script , puis analysez vos problèmes.
À propos du script Event1644Reader.ps1 de projet

L’ID d’événement Active Directory 1644 est consigné dans le journal des événements du service d’annuaire. Cet
événement identifie les recherches LDAP (Lightweight Directory Access Protocol) coûteuses, inefficaces ou
lentes qui sont dirigées par les contrôleurs de domaine Active Directory. NTDS General event ID 1644 can be
filtered to record LDAP searches in the Directory Services event log based on the number of objects in the
Active Directory database that were visited, the number of objects that were returned, or the LDAP search
execution time on the domain controller. Pour plus d’informations sur l’ID d’événement 1644, voir Correctif
2800945 données de performances dans le journal des événements Active Directory.
Event1644Reader.ps1 est un script Windows PowerShell qui extrait les données des événements 1644 hébergés
dans les journaux d’événements du service d’annuaire enregistrés. Ensuite, il importe ces données dans une
série de tableaux croisés dynamiques dans une feuille de calcul Microsoft Excel pour aider les administrateurs à
obtenir des informations sur les charges de travail LDAP qui sont pris en charge par les contrôleurs de domaine
et les clients qui génèrent ces requêtes.
Comment obtenir le script

Vous pouvez obtenir le script à partir du billet de blog sur l’infrastructure principale et la sécurité Sur la façon de
trouver des requêtes LDAP coûteuses, inefficaces et de longue durée dans Active Directory.
NOTE
Le script est joint au billet de blog avec le nom de Event1644Reader.zip
Clause d’exclusion de responsabilité du Centre de scripts

Les exemples de scripts ne sont pas pris en charge dans le cadre d’un programme ou d’un service de support
standard Microsoft. Les exemples de scripts sont fournis tels quels, sans garantie d’aucune sorte. Microsoft
Corporation décline aussi toute garantie implicite, y compris et sans limitation, les garanties implicites de qualité
marchande ou d’adéquation à un usage particulier. La totalité des risques découlant de l’utilisation ou de la
performance des exemples de scripts et de la documentation repose sur vous. En aucun cas Microsoft, ses
auteurs ou quiconque impliqué dans la création, la production ou la livraison des scripts ne sera responsable de
tous dommages quels qu’ils soient (y compris, sans limitation, les dommages pour perte de profits, interruption
d’activité, perte d’informations commerciales ou toute autre perte pécuniaire) découlant de l’utilisation ou de
l’impossibilité d’utiliser les exemples de scripts ou la documentation, même si Microsoft a été informé de la
possibilité de tels dommages.
Prise en charge des homologues en ligne
Pour la prise en charge des homologues en ligne, rejoignez le forum officiel des joueurs de script ! Pour fournir
des commentaires ou signaler des bogues dans des exemples de scripts, démarrez une nouvelle discussion sous
l’onglet Discussions pour ce script.
Utilisation du script
Pour mieux analyser les requêtes LDAP capturées dans l’ID d’événement 1644, suivez les étapes suivantes :
1. Assurez-vous que les contrôleurs de domaine que vous dépannagez capturent les métadonnées
d’événement ** 1644 améliorées.
NOTE
Windows Server 2012 R2 a ajouté la journalisation des événements 1644 améliorée en enregistrant la durée des
requêtes LDAP et d’autres métadonnées. La journalisation améliorée des événements 1644 a été backportée vers
Windows Server 2012, Windows Server 2008 R2 et Windows Server 2008 par des 2800945.
2. Définissez la valeur de l’entrée de Registre Field Engineering suivante sur 5 :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Field Engineering
NOTE
La définition de la verbosité du journal d’ingénierie de champ sur 5 entraîne la consigner d’autres événements
dans le journal des événements du service d’annuaire. Rétablissez la valeur par défaut de l’ingénierie de champ 0
lorsque vous ne collectez pas activement 1 644 événements. (Cette action ne nécessite pas de redémarrage.)
3. Si les entrées de Registre suivantes existent, modifiez les valeurs au seuil souhaité en millisecondes. Si
une entrée de Registre particulière n’existe pas, créez une entrée avec ce nom, puis définissez sa valeur
sur le seuil souhaité en millisecondes.
C H EM IN D’A C C ÈS DU REGIST RE T Y P E DE DO N N ÉES VA L EUR PA R DÉFA UT
HKEY_LOCAL_MACHINE\SYSTEM\C DWORD 30,000

urrentControlSet\Services\NTDS\Par
ameters\Search Time Threshold
(msecs)
HKEY_LOCAL_MACHINE\SYSTEM\C DWORD 10 000

ameters\Expensive Search Results
Threshold
HKEY_LOCAL_MACHINE\SYSTEM\C DWORD 1 000

ameters\Inefficient Search Results
Threshold
NOTE
Lorsque le niveau de journalisation Field Engineering est activé et que l’entrée de Registre du seuil de temps de
recherche (msecs) n’est pas utilisée ou est définie sur 0, la valeur par défaut du seuil de temps est 30 000
millisecondes. (Cette action ne nécessite pas de redémarrage.)
Une stratégie consisterait à définir la valeur de Registre pour les paramètres de Registre Seuil de résultats de
recherche inefficaces et Seuil de résultats de recherche coûteux, puis se concentrer sur les événements identifiés
par le délai de recherche (msecs). Commencez avec une valeur supérieure de 100 millisecondes, puis diminuez
la valeur de manière incrémentielle lorsque vous optimisez les requêtes qui se produisent dans votre
environnement.
Event1644Reader.ps1 pouvez parer des événements à partir de plusieurs contrôleurs de domaine. Configurez
les paramètres de clé de Registre d’ingénierie de champ, de temps de recherche, coûteux et inefficaces sur tous
les contrôleurs de domaine sur lesquels vous souhaitez examiner les recherches LDAP.
4. Téléchargez le fichier Event1644Reader.ps1 à partir de Vous pouvez obtenir le script à partir du billet de
blog principal sur l’infrastructure et la sécurité Comment trouver des requêtes LDAP coûteuses,
inefficaces et de longue durée dans Active Directory sur l’ordinateur qui analysera les fichiers EVTX du
service Active Directory enregistrés qui contiennent 1 644 événements.
Cet ordinateur doit avoir installé Microsoft Excel 2010 ou une version ultérieure et avoir suffisamment
d’espace disque pour héberger les journaux des événements du service d’annuaire que le script va
parseiner.
5. Copiez les journaux des événements du service d’annuaire enregistrés qui contiennent 1 644 événements
des contrôleurs de domaine où vous avez activé la journalisation des événements 1644 sur l’ordinateur
d’analyse 1644.
6. Dans Windows’Explorateur, cliquez avec le bouton droit sur Event1644Reader.ps1 fichier, puis
sélectionnez Exécuter avec PowerShell .
Voici la capture d’écran de cette étape :
7. Appuyez sur Y pour contourner la stratégie d’exécution PowerShell selon les besoins.
8. Spécifiez le chemin d’accès des fichiers EVTX à voir.
9. Lorsque vous voyez l’invite comme capture d’écran suivante, prenez les mesures suivantes :
Appuyez sur Entrée pour archiver tous les fichiers EVTX situés dans le même répertoire que le
Enent1644Reader.ps1 fichier.
Tapez drive:\path le chemin d’accès qui contient les fichiers EVTX à parer.
NOTE
Event1644Reader.ps1 1644 événements dans tous les journaux des événements du service d’annuaire de niveau
supérieur qui se trouvent dans le chemin d’accès ciblé chaque fois que le script s’exécute.
10. Ouvrez la feuille de calcul pour passer en revue les données et parcourir la série d’onglets, puis
enregistrez Excel feuille de calcul si nécessaire. Pour plus d’informations sur les onglets de la feuille de
calcul, voir la Excel feuille de calcul créée par 1644Reder.ps1section.
NOTE
*.csv fichiers créés par l’outil ne sont pas automatiquement supprimés. Envisagez de purger les fichiers *.csv une
fois votre enquête terminée.
Walkthrough of the Excel spreadsheet that is created by Event1644Reader.ps1
Event1644Reader.ps1 extrait les métadonnées de 1644 événements dans les journaux des événements du
service d’annuaire enregistrés et importe ces données dans une série de feuilles de calcul à onglets dans une
feuille de calcul Microsoft Excel feuille de calcul.
Le tableau suivant récapitule les données contenues dans chaque onglet :
TA B DESC RIP T IO N
RawData Chaque champ de données capturé par l’ID d’événement

1644 est importé dans des colonnes discrètes. Le filtrage des
données est activé automatiquement afin que vous pouvez
trier ou filtrer sur n’importe quel en-tête de colonne. Si 1644
journaux d’événements de plusieurs contrôleurs de domaine
résident dans le même répertoire que le script PowerShell ou
le répertoire spécifié par l’administrateur, utilisez des filtres
pour afficher les requêtes LDAP qui ciblent des contrôleurs
de domaine spécifiques.
Top_Star tingNode Fournit une liste triée des partitions d’annuaire ciblées par
les requêtes LDAP dans un exemple donné. Si la plupart des
requêtes se produisent dans une seule partition (schéma,
configuration ou domaine), envisagez d’ajouter cette
partition en tant que filtre dans les tableaux croisés
dynamiques restants. Les détails de l’analyse exposent les
filtres principaux (par exemple, la requête LDAP), les IPS
client qui ont émis ces requêtes, ainsi que les horodatés de
ces requêtes.
Top_Callers Répertorie les adresses IP clientes qui ont émis des requêtes
LDAP dans l’ordre décroit du nombre de recherches avec le
pourcentage du total global. Le pourcentage du total en
cours d’exécution vous permet d’identifier les principaux
appelants. (Autrement dit, les 10 ou 20 premiers appelants
peuvent générer 80 % du volume de requête, en supposant
que trop d’appels sont votre problème). Les détails de
l’analyse exposent les filtres et les étapes de date et d’heure
que chaque LDAP émis par le client interroge dans un
exemple donné.
TA B DESC RIP T IO N
Top_Filters Répertorie les requêtes LDAP les plus fréquemment émises

dans l’ordre décroit du volume. Cela inclut le temps de
recherche moyen. Les détails de l’analyse exposent l’adresse
IP du client LDAP, ainsi que la date et l’heure d’entrée de
chaque requête.
TotalSearchTime par les appelants Répertorie les adresses IP clientes dans l’ordre décroit du
temps total de recherche dans toutes les requêtes LDAP de
l’exemple. Les détails de l’analyse identifient les requêtes
LDAP et la date et l’heure d’émission de chaque requête.
TotalSearchTime par filtres Répertorie les requêtes LDAP dans l’ordre décroit du temps
total de recherche. Les détails de l’analyse exposent l’adresse
IP du client LDAP, ainsi que la date et l’heure d’entrée de
chaque requête correspondante.
Classement des temps de recherche Affiche le nombre de requêtes LDAP qui se sont produites
dans des quartiles basés sur le temps. Les requêtes plus
lentes sont mauvaises. Les requêtes plus rapides sont
bonnes si elles ne sont pas émises trop souvent. Microsoft
Exchange que les requêtes LDAP émises par les serveurs
Exchange soient résolues en 50 millisecondes ou moins.
Ainsi, le premier groupe de quartiles se concentre sur ce «
compartiment » de temps.
Tableau croisé dynamique vide Il s’agit d’un tableau croisé dynamique vide que vous pouvez
modifier selon les besoins pour afficher les données
spécifiques de votre scénario.
Analyse de scénario
Si les requêtes LDAP sont lentes ou si l’utilisation du processeur est élevée sur les contrôleurs de domaine, cela
peut être dû à des requêtes trop émises, des requêtes inefficaces, une combinaison de ces requêtes, un
épuisement du pool de files d’attente de threads asynchrone (ATQ) ou de nombreuses notifications de
modification.
Si les clients émettrent des requêtes LDAP coûteuses, inefficaces ou nombreuses, utilisez Event1644Reader.ps1
pour collecter des données sur les contrôleurs de domaine afin d’identifier les adresses IP des clients. Ensuite,
mapillez ces requêtes sur l’ID de processus, le nom du processus ou l’application d’appel sur les ordinateurs
clients.
Le tableau suivant répertorie les optimisations possibles pour ce problème.
O P T IM ISAT IO N / AT T ÉN UAT IO N RÉSUM É

O P T IM ISAT IO N / AT T ÉN UAT IO N RÉSUM É
Arrêtez la charge de travail excessive. Si de nombreuses requêtes LDAP ou beaucoup provoquent

l’arrêt du service, concentrez-vous sur les principaux clients
appelants et travaillez pour identifier et éliminer la source de
la charge de travail excessive.
Les options possibles pour identifier les applications incluent

l’utilisation de PROCMON, le suivi ETL/ETW et l’analyse de
débogage pour identifier l’application qui génère des
requêtes LDAP sur le client. Une autre stratégie consiste à
utiliser une approche de séparation par deux des services de
toprage ou de suppression des applications qui génèrent des
requêtes LDAP. Les requêtes émises peuvent insérabler
l’application ou le processus appelant.
Installez un optimiseur de requête LDAP mis à jour. Windows Server 2012 R2 contient un optimiseur de requête
LDAP mis à jour qui améliore les performances pour la
plupart des requêtes. Les sous-ensembles du Windows
Server 2012 R2 sont Windows Server 2008 R2 et Windows
Server 2012 en 2862304.
Assurez-vous que les clients envoient des requêtes aux L’envoi de requêtes LDAP sur le réseau wan introduit une
contrôleurs de domaine optimisés pour le site. latence réseau dans la remise de la requête LDAP au
contrôleur de domaine et sa réponse au client. Assurez-vous
que les sites Active Directory et les définitions de sous-
réseau existent pour les ordinateurs clients et serveurs dans
Active Directory.
Assurez-vous que les applications n’ont pas de références

codées en dur aux contrôleurs de domaine de site distant ou
aux contrôleurs de domaine accessibles en lecture seule
lorsqu’il existe des contrôleurs de domaine optimisés pour le
site.
Travaillez en équipe avec les développeurs de logiciels pour Les requêtes émises de manière efficace peuvent advenir à
réduire la fréquence à laquelle les requêtes sont émises. Cela un contrôleur de domaine de taille et de configuration
inclut l’utilisation de la mise en cache. appropriée si les requêtes sont émises trop souvent.
Les applications peuvent être amenés à limiter leur volume
de requête ou à mettre en cache les résultats de la requête
afin de réduire la charge réseau, LDAP et processeur.
Optimisez la requête LDAP pour une exécution plus rapide. La syntaxe de requête doit peut-être être restructurée pour
s’exécuter plus rapidement.
Le déplacement d’éléments de requête vers la gauche ou la
droite dans le filtre peut améliorer les performances.
L’ajout d’un double « non » peut améliorer les performances
des requêtes.
Envisagez de réduire le nombre d’objets visités en
commençant les requêtes plus bas dans l’arborescence.
Réduisez le nombre d’attributs renvoyés par les requêtes.
Ajoutez des index aux attributs Active Directory selon les L’ajout d’index peut améliorer les performances des requêtes.
besoins. Cela a pour effet secondaire d’augmenter la taille de la base
de données et peut retarder temporairement la réplication
Active Directory pendant la création de l’index.
Déterminez si un défaut de code existe dans l’optimiseur de Les défauts de l’optimiseur de requête LDAP et d’autres
requête et d’autres composants. composants peuvent réduire le débit.
Problème connu
Les valeurs de la feuille Excel ne sont pas affichées ou affichées correctement sur les ordinateurs qui utilisent des
langues autres que l’anglais.
Par exemple, cela se produit sur un ordinateur lorsque l'Get-Culture Windows PowerShell cmdlet indique le
paramètre régional comme suit :
PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-Culture
LCID Name DisplayName
---- ---- -----------
1031 de-DE German (Germany)
PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-UICulture
LCID Name DisplayName

---- ---- -----------
1033 en-US English (United States)
Dans ce cas, les nombres de la feuille de calcul Excel sont restituer comme dans la capture d’écran suivante :
Pour résoudre ce problème, modifiez le symbole décimal en point (.) dans l’élément Paramètres de région du
Panneau de configuration.
Pour plus d’informations sur les requêtes LDAP, voir le blog suivant : Comment trouver des requêtes LDAP
coûteuses, inefficaces et longues dans Active Directory
Message d’erreur : le compte n’est pas autorisé à se
connecter à partir de cette station
Cet article s’applique Windows 2000. Le support Windows 2000 se termine le 13 juillet 2010. Le Windows
solutions de fin de support 2000 est un point de départ pour la planification de votre stratégie de migration à
partir de Windows 2000. Pour plus d’informations, voir la politique de cycle de vie du support Microsoft.
Symptômes
Lorsque vous tentez de joindre un ordinateur Windows 2000 à un domaine Microsoft Windows NT 4.0, vous
pouvez recevoir le message d’erreur suivant :
L’erreur suivante s’est produite lors de la tentative de joindre le domaine « domainname » : le compte n’est
pas autorisé à se connecter à partir de cette station.
Cause
Ce comportement peut se produire car la stratégie de groupe locale, en particulier celles du dossier
Configuration ordinateur\Windows Paramètres\Sécurité Paramètres\Stratégies locales\Options de sécurité, ont
un paramètre restrictif.
Voici quelques-unes des stratégies qui peuvent provoquer ce comportement :
Communications client avec signature numérique (toujours)
Communications avec le serveur signé numériquement (toujours)
Signature numérique des communications du serveur (dans la mesure du possible)
Niveau d’authentification du Gestionnaire laN définie sur Envoyer LM et NTLM : utiliser la sécurité de session
NTLMv2 si négocié
Canal sécurisé : chiffrer numériquement ou signer des données de canal sécurisé (toujours)
Canal sécurisé : nécessite une clé de session forte (Windows 2000 ou ultérieure)
Résolution
Pour contourner ce problème, définissez à nouveau les valeurs sur ce qu’elles seraient si une nouvelle
installation s’était produite.
Examinez les stratégies précédentes et définissez-les à nouveau sur leurs paramètres par défaut.
Les paramètres par défaut de ces stratégies sont :
Communications client signe numériquement (toujours) - désactivées
Communications de serveur signé numériquement (toujours)- désactivées
Communications de serveur signé numériquement (dans la mesure du possible) - désactivées
Niveau d’authentification du Gestionnaire laN définie sur Envoyer LM et NTLM - utiliser la sécurité de session
NTLMv2 si négocié - (par défaut) envoyer des réponses NTLM & LM
Canal sécurisé : chiffrer numériquement ou signer des données de canal sécurisé (toujours) - désactivé
Canal sécurisé : nécessite une clé de session forte (Windows 2000 ou ultérieure) - désactivée
Redémarrez votre ordinateur et vous devriez être en mesure de rejoindre le domaine.
Statut
L’installation d’Active Directory se bloque à l’étape
Création de l’objet paramètres NTDS
Cet article fournit une solution à un problème dans lequel l’installation d’Active Directory échoue avec une
erreur : création de l’objet Paramètres NTDS pour ce contrôleur de domaine Active Directory sur le contrôleur de
domaine AD distant.
Symptômes
Une fois que vous avez commencé l’installation d’Active Directory dans Windows Server à l’aide du Gestionnaire
de serveur ou du module Windows PowerShell, l’installation se bloque à l’étape à laquelle vous recevez le
AddsDeployment message suivant :
Création de l’objet Paramètres NTDS pour ce contrôleur de domaine Active Directory sur le contrôleur AD
DC distant dc1-full.corp.contoso.com
Quelle que soit la durée d’attente, l’installation ne se poursuit jamais au-delà de ce point. En outre, lorsque vous
examinez les journaux des événements des services d’annuaire, vous voyez les événements répétés suivants :
Événement 1

Date : <DateTime>
Niveau : Error
Ordinateur : dc2-full
Description :
Événement interne : le service d’annuaire local suivant a reçu une exception d’une connexion d’appel
de procédure distante (RPC). Des informations RPC complètes ont été demandées. Il s’agit
d’informations intermédiaires qui peuvent ne pas contenir de cause possible.
ID de processus : 556 Informations sur les erreurs signalées :
Valeur d’erreur :
service d’annuaire :
dc1-full.corp.contoso.com
Informations sur les erreurs complètes :

Valeur d’erreur :
Une erreur spécifique au package de sécurité s’est produite. 1825
DC2-FULL
ID interne de données supplémentaire : 5000dfc
Événement 2

Date : <DateTime>
Niveau : Error
Description :
Événement interne : le service d’annuaire local a reçu une exception d’une connexion d’appel de
procédure distante (RPC). Les informations sur les erreurs étendues ne sont pas disponibles.
Valeur d’erreur :
Événement 3

Date : <DateTime>
Catégorie de tâche : installation
Niveau : Error
Description :
L’Assistant Installation des services de domaine Active Directory (Dcpromo) n’a pas pu établir de
connexion avec le contrôleur de domaine suivant.
Valeur d’erreur :
1908 Le contrôleur de domaine de ce domaine n’a pas pu être trouvé.
Cause
Ce problème se produit pour une ou plusieurs des raisons suivantes :
Le compte Administrateur intégré du serveur possède le même mot de passe que le compte d’administrateur
de domaine intégré.
Le préfixe de domaine NetBIOS ou l’UPN n’a pas été fourni comme informations d’identification pour
l’installation. Au lieu de cela, seul le nom d’utilisateur Administrateur a été fourni.
Résolution
1. Redémarrez le serveur sur lequel Active Directory n’a pas pu être installé.
2. Utilisez Dsa.msc ou Dsac.exe sur un contrôleur de domaine existant pour supprimer le compte d’ordinateur
du serveur en échec. (Le contrôleur de domaine n’est pas encore un objet contrôleur de domaine, mais
seulement un serveur membre.) Ensuite, laissez la réplication Active Directory converger.
3. Sur le serveur en panne, supprimez de force le serveur du domaine à l’aide de l’élément ou du panneau de
netdom.exe.
4. Sur le serveur en échec, supprimez le rôle Services de domaine Active Directory (AD DS) à l’aide du
Gestionnaire de serveur ou Uninstall-WindowsFeature .
5. Redémarrez le serveur défaré.
6. Installez le rôle AD DS, puis tentez à nouveau la promotion. Lorsque vous faites cela, veillez à fournir des
informations d’identification de promotion sous la forme domaine\utilisateur ou user@domain.tld .
Il s’agit d’un défaut de code Windows Server 2012 et en retard.
Si vous définissez des mots de passe différents sur les deux comptes Administrateur mais que vous ne
fournissez pas le domaine, vous recevez une erreur de mot de passe incorrect.
Nous vous déconseillons d’utiliser l’administrateur intégré pour l’administration de domaine. Au lieu de cela,
nous vous recommandons de créer un utilisateur de domaine pour chaque administrateur de l’environnement.
Ensuite, les actions des administrateurs peuvent être auditées individuellement.
Nous vous déconseillons vivement d’utiliser des mots de passe administrateur correspondants sur les serveurs
membres et le compte Administrateur de domaine. Les mots de passe locaux sont plus facilement compromis
que les comptes AD DS et la connaissance des mots de passe administrateur correspondants accorde un accès
administratif complet à l’entreprise.
Vous ne pouvez pas vous connecter à Internet et
vous ne pouvez pas vous connecter au domaine si
Windows Server 2003 SP1 est installé sur le
contrôleur de domaine d’authentification
Cet article fournit une solution à un problème dans lequel les clients ne peuvent pas se connecter au domaine
ou s’y connecter.
Symptômes
Prenons le cas de figure suivant. Un ordinateur client Microsoft Windows XP est joint à un domaine Microsoft
Windows Server 2003. En outre, Windows Server 2003 Service Pack 1 (SP1) est installé sur le contrôleur de
domaine d’authentification. Dans ce scénario, vous pouvez être face aux symptômes suivants :
Vous ne pouvez pas vous connecter à Internet.
Vous ne pouvez pas vous connecter ou vous connecter au domaine. Par conséquent, le contrôleur de
domaine est en mode bloc IPsec.
Lorsque vous démarrez le composant services IPSEC sur le contrôleur de domaine, vous pouvez recevoir un
message d’erreur semblable au suivant :
En outre, les événements suivants peuvent être enregistrés dans le journal système du serveur :

Source de l’événement : IPSEC
Date : <DateTime>
Heure : <DateTime>
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
Le pilote IPSec est entré en mode Blocage. IPSec ignorera tout le trafic réseau TCP/IP entrant et sortant qui
n’est pas autorisé par les exemptions de stratégie IPSec au démarrage.

Source de l’événement : Gestionnaire de contrôle de service
Date : <DateTime>
Heure : <DateTime>
Utilisateur : N/A
Description :
Le service services IPSEC s’est terminé par l’erreur suivante : Le système ne peut pas trouver le fichier
spécifié.
Cause
Ce problème peut se produire si la clé de Registre local de la stratégie IPSec est supprimée ou si un fichier est
endommagé dans le magasin \ \ de stratégies. Le fichier peut être endommagé si une interruption se produit
lors de l’écriture de la stratégie sur le disque.
Résolution
IMPORTANT

1. Supprimez la sous-clé de Registre de stratégie locale. Pour cela, procédez comme suit :
b. Dans l’Éditeur du Registre, recherchez et cliquez sur la sous-clé suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local
c. Dans le menu Edition , cliquez sur Supprimer .

d. Cliquez sur Oui pour confirmer la suppression de la sous-clé.
2. Reconstruire un nouveau magasin de stratégies local. Pour ce faire, cliquez sur Démarrer, sur Exécuter,
tapez regsvr32 polstore.dll dans la zone Ouvrir, puis cliquez sur OK.
3. Vérifiez que le composant services IPSEC est automatique, puis redémarrez le contrôleur de domaine.
Pour contourner temporairement ce problème, désactivez le composant SERVICES IPSEC, puis redémarrez le
Limite par défaut au nombre de stations de travail
qu’un utilisateur peut joindre au domaine
Cet article explique comment modifier l’AD pour autoriser plus ou moins de comptes d’ordinateur dans le
domaine.
Résumé
Par défaut, Windows 2000 permet aux utilisateurs authentifiés de joindre 10 comptes d’ordinateur au domaine.
Cette valeur par défaut a été implémentée pour éviter toute utilisation abusive. Toutefois, un administrateur peut
apporter une modification à un objet dans Active Directory pour le remplacer.
Les utilisateurs suivants ne sont pas limités par cette limitation :
Utilisateurs des groupes Administrateurs ou Administrateurs de domaine.
Utilisateurs qui ont des autorisations déléguées sur les conteneurs dans Active Directory pour créer et
supprimer des comptes d’ordinateur.
Pour calculer le nombre de stations de travail actuellement propriétés d’un utilisateur, vérifiez l’attribut ms-DS-
CreatorSID des comptes d’ordinateur.
Pour modifier Active Directory afin d’autoriser plus (ou moins) de comptes d’ordinateur sur le domaine, utilisez
l’outil Adsiedit.
WARNING
L’utilisation incorrecte d’Adsiedit peut entraîner de graves problèmes qui peuvent nécessiter la réinstallation de votre
système d’exploitation. Microsoft ne peut pas garantir que les problèmes résultant de l’utilisation incorrecte d’Adsiedit
peuvent être résolus. Utilisez Adsiedit à vos propres risques.
1. Installez les Windows support technique s’ils n’ont pas déjà été installés. Elle est nécessaire uniquement pour
Windows 2000 et Windows Server 2003. Pour Windows Server 2008 et Windows Server 2008 R2, Adsiedit
est installé automatiquement lorsque vous installez le rôle Services de domaine Active Directory.
2. Exécutez Adsiedit.msc en tant qu’administrateur du domaine. Développez le nœud NC de domaine. Ce
nœud contient un objet qui commence par « DC= » et reflète le nom de domaine correct. Cliquez avec le
bouton droit sur cet objet, puis sélectionnez Propriétés.
3. Dans la zone Sélectionner les propriétés à afficher, sélectionnez Les deux. Dans la zone Sélectionner
une propriété à afficher, sélectionnez ms-DS-MachineAccountQuota .
4. Dans la zone Modifier l’attribut, tapez le nombre de stations de travail que vous souhaitez que les
utilisateurs puissent gérer simultanément.
5. Sélectionnez Définir > OK.
Comment se trouvent les contrôleurs de domaine
dans Windows
Cet article décrit le mécanisme utilisé par les Windows pour localiser un contrôleur de domaine dans un
Windows basé sur un domaine.
NOTE
Résumé
Cet article décrit en détail le processus de recherche d’un domaine par son nom de style DNS et son nom
NetBIOS (flat-style). Le nom de style plat est utilisé pour la compatibilité ascendante. Dans tous les autres cas, les
noms de style DNS doivent être utilisés en tant que stratégie. Cet article traite également du dépannage du
processus d’emplacement du contrôleur de domaine.
Comment le locateur trouve un contrôleur de domaine

Cette séquence décrit comment le locateur trouve un contrôleur de domaine :
Sur le client (l’ordinateur qui localise le contrôleur de domaine), le Locator est démarré en tant qu’appel
de procédure distante (RPC) vers le service Netlogon local. L’appel d’interface de programmation
d’application (API) Locator DsGetDcName est implémenté par le service Netlogon.
Le client collecte les informations nécessaires pour sélectionner un contrôleur de domaine. Il transmet
ensuite les informations au service Netlogon à l’aide de l’appel DsGetDcName.
Le service Netlogon sur le client utilise les informations collectées pour rechercher un contrôleur de
domaine pour le domaine spécifié de deux manières :
Pour un nom DNS, Netlogon interroge DNS à l’aide du locateur compatible IP/DNS. Autrement dit,
DsGetDcName appelle l’appel DnsQuery pour lire les enregistrements de ressource de service
(SRV) et les enregistrements « A » à partir du DNS une fois qu’il ajoute le nom de domaine à la
chaîne appropriée qui spécifie les enregistrements SRV.
Une station de travail qui se connecte à un domaine basé sur Windows interroge DNS pour les
enregistrements SRV sous la forme générale :
_service._protocol.DnsDomainName
Les serveurs Active Directory offrent le service LDAP (Lightweight Directory Access Protocol) sur
le protocole TCP. Par exemple, les clients trouvent un serveur LDAP en interrogeant DNS pour
obtenir un enregistrement du formulaire :
_ldap._tcp. DnsDomainName
Pour un nom NetBIOS, Netlogon effectue la découverte de contrôleur de domaine à l’aide de Microsoft
Windows NT version 4.0-compatible Locator. Autrement dit, en utilisant le mécanisme spécifique au
transport, tel que WINS.
Dans Windows NT 4.0 et les antérieures, la « découverte » est un processus qui permet de localiser un
contrôleur de domaine pour l’authentification dans le domaine principal ou un domaine approuvé.
Le service Netlogon envoie un datagram aux ordinateurs qui ont enregistré le nom. Pour les noms de
domaine NetBIOS, le datagramme est implémenté en tant que message maillot. Pour les noms de
domaine DNS, le datagramme est implémenté en tant que recherche UDP (User Datagram Protocol)
LDAP. (UDP est le protocole de transport de datagram sans connexion qui fait partie de la suite de
protocoles TCP/IP. TCP est un protocole de transport orienté connexion.)
Chaque contrôleur de domaine disponible répond au datagramme pour indiquer qu’il est actuellement
opérationnel et renvoie les informations à DsGetDcName.
UDP permet à un programme sur un ordinateur d’envoyer un datagramme à un programme sur un autre
ordinateur. UDP inclut un numéro de port de protocole, qui permet à l’expéditeur de faire la distinction entre
plusieurs destinations (programmes) sur l’ordinateur distant.
Chaque contrôleur de domaine disponible répond au datagramme pour indiquer qu’il est actuellement
opérationnel et renvoie les informations à DsGetDcName.
Le service Netlogon met en cache les informations du contrôleur de domaine afin que les demandes
ultérieures n’ont pas besoin de répéter le processus de découverte. La mise en cache de ces informations
encourage une utilisation cohérente du même contrôleur de domaine et une vue cohérente d’Active
Directory.
Lorsqu’un client se connecte ou rejoint le réseau, il doit pouvoir localiser un contrôleur de domaine. Le client
envoie une requête de recherche DNS au DNS pour rechercher des contrôleurs de domaine, de préférence dans
le propre sous-réseau du client. Ainsi, les clients trouvent un contrôleur de domaine en interrogeant DNS pour
obtenir un enregistrement du formulaire :
_LDAP._TCP.dc._msdcs.domainname
Une fois que le client a localisé un contrôleur de domaine, il établit la communication à l’aide de LDAP pour
accéder à Active Directory. Dans le cadre de cette négociation, le contrôleur de domaine identifie le site dans
lequel se trouve le client en fonction du sous-réseau IP de ce client.
Si le client communique avec un contrôleur de domaine qui ne se trouve pas sur le site le plus proche (optimal),
le contrôleur de domaine renvoie le nom du site du client. Si le client a déjà tenté de trouver des contrôleurs de
domaine dans ce site, il utilise le contrôleur de domaine qui n’est pas optimal. Par exemple, le client envoie une
requête de recherche DNS au DNS pour rechercher des contrôleurs de domaine dans le sous-réseau du client.
Dans le cas contraire, le client recommence une recherche DNS propre au site avec le nouveau nom de site
optimal. Le contrôleur de domaine utilise certaines des informations du service d’annuaire pour identifier les
sites et les sous-réseaux.
Une fois que le client a localisé un contrôleur de domaine, l’entrée du contrôleur de domaine est mise en cache.
Si le contrôleur de domaine n’est pas dans le site optimal, le client vide le cache après 15 minutes et rejette
l’entrée de cache. Il tente ensuite de trouver un contrôleur de domaine optimal dans le même site que le client.
Une fois que le client a établi un chemin de communication vers le contrôleur de domaine, il peut établir les
informations d’identification d’authentification et d’connexion. Si nécessaire pour les ordinateurs Windows, il
peut configurer un canal sécurisé. Le client est alors prêt à exécuter des requêtes normales et à rechercher des
informations sur l’annuaire.
Le client établit une connexion LDAP à un contrôleur de domaine pour se connecter. Le processus d’logo utilise
le Gestionnaire des comptes de sécurité. Le chemin de communication utilise l’interface LDAP et le client est
authentifié par un contrôleur de domaine. Ainsi, le compte client est vérifié et transmis par le biais du
Gestionnaire de comptes de sécurité à l’agent du service d’annuaire, puis à la couche de base de données, puis à
la base de données dans le moteur ESE (Extensible Stockage engine).
Résolution des problèmes du processus de localisation de domaine

Pour résoudre les problèmes du processus de localisation de domaine :
1. Vérifiez l’Observateur d’événements sur le client et le serveur. Les journaux des événements peuvent
contenir des messages d’erreur indiquant qu’il y a un problème. Pour afficher l’Observateur
d’événements, sélectionnez Démarrer, pointez sur Outils d’administration des > programmes, puis
sélectionnez Observateur d’événements. Vérifiez le journal système sur le client et le serveur. Vérifiez
également les journaux du service d’annuaire sur le serveur et les journaux DNS sur le serveur DNS.
2. Vérifiez la configuration IP à l’aide ipconfig /all de la commande à une invite de commandes.
3. Utilisez l’utilitaire Ping pour vérifier la connectivité réseau et la résolution de noms. Ping à la fois l’adresse
IP et le nom du serveur. Vous pouvez également ping sur le nom de domaine.
4. Utilisez l’outil Netdiag pour déterminer si les composants réseau fonctionnent correctement. Pour
envoyer une sortie détaillée à un fichier texte, utilisez la commande suivante :
netdiag /v >test.txt
Examinez le fichier journal, recherchez les problèmes et examinez les composants insérants. Ce fichier
contient également d’autres détails de configuration réseau.
5. Pour résoudre les problèmes mineurs, utilisez l’outil Netdiag avec la syntaxe suivante :
netdiag /fix .
6. Utilisez la nltest /dsgetdc:domainname commande pour vérifier qu’un contrôleur de domaine peut se
trouver pour un domaine spécifique.
7. Utilisez NSLookup l’outil pour vérifier que les entrées DNS sont correctement enregistrées dans le DNS.
Vérifiez que les enregistrements SRV GUID et d’hôte du serveur peuvent être résolus.
Par exemple, pour vérifier l’inscription des enregistrements, utilisez les commandes suivantes :
nslookup servername. childofrootdomain. rootdomain.com
nslookup guid._msdcs. rootdomain.com
8. Si l’une de ces commandes ne réussit pas, utilisez l’une des méthodes suivantes pour réenregistrer des
enregistrements avec DNS :
Pour forcer l’inscription des enregistrements d’hôte, tapez ipconfig /registerdns.
Pour forcer l’inscription du service contrôleur de domaine, arrêtez et démarrez le service Netlogon.
9. Pour détecter les problèmes de contrôleur de domaine, exécutez l’utilitaire DCdiag à partir d’une invite de
commandes. L’utilitaire exécute de nombreux tests pour vérifier qu’un contrôleur de domaine s’exécute
correctement. Utilisez cette commande pour envoyer les résultats à un fichier texte :
dcdiag /v >dcdiag.txt
10. Utilisez lLdp.exe pour vous connecter au contrôleur de domaine et le lier afin de vérifier la connectivité
LDAP appropriée.
11. Si vous pensez qu’un contrôleur de domaine particulier présente des problèmes, il peut être utile
d’activer la journalisation du débogage Netlogon. Utilisez l’utilitaire NLTest en tapant cette commande :
nltest /dbflag:0x2000ffff . Les informations sont ensuite enregistrées dans le dossier Debug dans le
fichier Netlogon.log.
12. Si vous n’avez toujours pas isolé le problème, utilisez le moniteur réseau pour surveiller le trafic réseau
entre le client et le contrôleur de domaine.
Références
Pour plus d’informations, voir le kit de ressources Windows, chapitre 10, « Diagnostic, dépannage et
récupération Active Directory ».
Le service Netlogon ne conserve pas les paramètres
après une mise à niveau sur place vers Windows
Server 2016 ou Windows Server 2019
Cet article fournit une solution à un problème qui empêche le démarrage automatique du service Netlogon sur
les contrôleurs de domaine après la mise à niveau vers Windows Server 2016 ou Windows Server 2019.
Symptômes
Supposons que vous avez un ou plusieurs ordinateurs exécutant Windows Server 2012 ou Windows Server
2012 R2 et configurés en tant que contrôleurs de domaine ou serveurs membres dans un domaine Active
Directory. Vous décidez d’une mise à niveau sur place sur les contrôleurs de domaine vers Windows Server
2016 ou Windows Server 2019.
Après avoir mis à niveau les contrôleurs de domaine, vous remarquez qu’un ou plusieurs des symptômes
suivants se produisent :
Échecs d’accès de l’utilisateur
Échec de la traduction du nom siD dans les UIS du s picker d’objet
Échecs de connexion RDP
Échecs d’enregistrement d’enregistrement de ressource DNS SRV
Le profil de pare-feu sur les serveurs membres et les stations de travail ne parvient pas à sélectionner le
profil de domaine
En outre, vous pouvez recevoir l’événement suivant dans le journal système :
Nom du journal : Système

Source : Microsoft-Windows-Time-Service
Date : date/heure
Catégorie de la tâche : Aucun
Niveau : Error
Mots clés :
Utilisateur : SERVICE LOCAL
Ordinateur : nom_ordinateur
Description :
Le service de temps a rencontré une erreur et a été forcé de s’arrêter. L’erreur était : 0x80070700 : une
tentative d’accès a été réalisée, mais le service d' logons du réseau n’a pas été démarré.
Cause
Ce problème se produit car le processus de mise à niveau sur place ne définisse pas la valeur de démarrage du
type de service Netlogon sur Automatique sur le serveur mis à niveau. Lorsque le service Netlogon n’est pas en
cours d’exécution, un contrôleur de domaine ne s’annonce pas en tant que contrôleur de domaine et toutes les
autres fonctionnalités et dépendances du service Netlogon échouent. Tous les services qui dépendent de
Netlogon pour être en cours d’exécution échouent également.
Résolution
Ce problème peut être évité en laissant le processus d’installation installer les dernières mises à jour pendant la
mise à niveau sur place.
Si le problème se produit déjà, pour résoudre ce problème, modifiez le type de démarrage du service Netlogon
sur Automatique. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer, tapez services.msc dans la zone Démarrer la recherche, puis cliquez sur Application
de bureau Ser vices.
2. Recherchez et double-cliquez sur Netlogon, puis cliquez sur Automatique dans la zone De démarrage.
3. Cliquez sur OK, puis démarrez le service Netlogon.
Bien que cette action ne nécessite pas de redémarrage, nous vous recommandons de redémarrer l’ordinateur
pour vous assurer que tous les services qui dépendent de Netlogon sont démarrés et correctement enregistrés
sur le réseau.
Références
Windows Les paramètres de service de temps ne sont pas conservés pendant une mise à niveau sur place vers
Windows Server 2016 ou Windows 10 version 1607
Description des limites de prise en charge pour
Active Directory sur NAT
Cet article décrit les limites de prise en charge d’Active Directory sur NAT.
Résumé
La traduction d’adresses réseau (NAT) est une sélection de techniques réseau qui modifient les informations
d’adresse du trafic réseau en transit afin de supprimer les détails sur le réseau d’origine. Cette opération est le
plus souvent effectuée par les périphériques réseau et est destinée à faciliter l’utilisation des schémas d’adresses
de réseau privé, et parfois comme une mesure de sécurité moins idéale.
La communication entre contrôleurs de domaine (DC) et client à dc sur un nat est un scénario que les clients
rencontrent fréquemment dans des scénarios de fusion et d’acquisition. L’un des services requis lors de la
connexion des réseaux des deux sociétés est l’authentification, l’autorisation et les services d’annuaire proposés
par Active Directory.
Il n’existe aucune preuve pour indiquer qu’une configuration NAT entre forêts rompt intrinsèquement les
communications DC à DC ou les communications client à dc. Microsoft n’a pas testé ce scénario avec Active
Directory et d’autres technologies associées à Active Directory. Le protocole Kerberos ou DFS est un exemple
d’autres technologies.
Déclaration Microsoft concernant Active Directory sur NAT

Active Directory sur NAT n’a pas été testé par Microsoft.
Nous ne recommandons pas Active Directory sur NAT.
La prise en charge des problèmes liés à Active Directory sur NAT sera limitée et permettra d’atteindre
rapidement les limites des efforts commerciaux raisonnables.
Si vous avez la tâche de configurer un réseau avec NAT et que vous envisagez d’exécuter une solution Microsoft
Server (y compris Active Directory) sur nat, contactez le support technique du client Microsoft à l’aide de votre
approche préférée ou visitez le Support Microsoft. En outre, vous pouvez contacter Microsoft Consulting
Sevices.
Il n’existe aucune garantie explicite ou implicite que le suivi des instructions fournies fonctionne dans un
scénario donné, car il n’est pas testé. Les équipes de support technique travailleront sur les problèmes qui
surviennent en utilisant les instructions fournies jusqu’aux limites d’efforts commerciaux raisonnables.
La seule configuration avec NAT testée par Microsoft exécute le client sur le côté privé d’une nat et tous les
serveurs sont situés sur le côté public de la nat. La nat fonctionne également comme un serveur DNS.
Centre de synchronisation : synchronisation lente
des fichiers hors connexion sur certains serveurs de
fichiers
Cet article décrit un problème qui ralentit la progression des opérations de synchronisation des fichiers de
dossiers en mode hors connexion par le Centre de synchronisation Microsoft.
Résumé
Lorsque le Centre de synchronisation Microsoft synchronise les fichiers hors connexion, l’opération de
synchronisation peut prendre plus de temps que prévu. Ce comportement se produit lorsque le serveur de
fichiers principal é énumére le contenu du répertoire non trié (liste dans laquelle les noms de fichiers ne sont
pas triés par ordre alphabétique). Cela affecte les performances du Centre de synchronisation Microsoft lors de
la synchronisation des fichiers hors connexion avec des serveurs de fichiers autres que Microsoft.
Le Centre de synchronisation Microsoft compare la liste d’annuaires du système local à une liste de fichiers qu’il
reçoit du serveur de fichiers distant. Pour ce faire, le Centre de synchronisation appelle le répertoire des
requêtes sur le serveur de fichiers distant via le protocole CIFS (CIFS, SMB, SMB2 et SMB3). Les serveurs de
fichiers Microsoft retournent toujours les résultats du répertoire de requête par ordre alphabétique, triés par
nom de fichier. (Le système de fichiers NTFS sous-jacent conserve les listes triées.)
De nombreux systèmes de fichiers sous-jacents ne conservent pas les listes triées. Cela inclut les systèmes de
fichiers utilisés par la plupart des implémenteurs de protocole SMB tiers et les systèmes de fichiers Microsoft
tels que FAT32. Par conséquent, la plupart des serveurs de fichiers tiers présentent des retards de performances
lorsqu’ils synchronisent des fichiers hors connexion à l’aide du Centre de synchronisation.
NOTE
Le protocole SMB n’exige pas que les résultats du répertoire de requête soient triés.
L’impact significatif sur les performances dépend de plusieurs facteurs, notamment le nombre de fichiers, la
longueur des noms de fichiers (les deux propriétés affectent la taille totale des métadonnées du fichier) et la
façon dont les résultats ne sont pas triés. Lorsqu’un grand nombre de fichiers (des centaines ou des milliers)
avec des noms de fichiers de grande taille sont hors de l’ordre, un plus grand nombre de requêtes d’annuaire du
système de fichiers local et d’autres requêtes d’annuaire distante sur le serveur de fichiers distant sont
nécessaires.
Vous pouvez résoudre ce problème en utilisant des dossiers plus petits (en termes de nombre de fichiers ou de
taille de nom de fichier). Cela vous aide également si vous pouvez augmenter la mesure dans laquelle les
fichiers sont enregistrés dans l’ordre trié sur le système de fichiers sous-jacent.
Le scénario affecte uniquement les performances. Dans le cas contraire, la synchronisation des fichiers hors
connexion se produit correctement.
Résolution de l’erreur de réplication AD 1908 : le
contrôleur de domaine pour ce domaine n’a pas pu
être trouvé
Cet article fournit une résolution de l’erreur de réplication AD 1908 : Le contrôleur de domaine de ce domaine
n’a pas pu être trouvé.
NOTE
Microsoft.
Symptômes
1. REPADMIN.exe signale que la tentative de réplication a échoué avec l’état 1908.
REPADMIN /ADD
REPADMIN /REPLSUM *
REPADMIN /REHOST
REPADMIN /SHOWVECTOR /LATENCY
REPADMIN /SHOWREPS
REPADMIN /SHOWREPL
Exemple de sortie à partir de repadmin /syncall la commande :
Syncing all NC's held on CONTOSO-DC02.

Syncing partition: DC=ForestDnsZones,DC=Contoso,DC=com
CALLBACK MESSAGE: Error contacting server 1b136427-14f0-448a-965c-
9cbb61400fcd._msdcs.Contoso.com (network error): 1908 (0x774):
Could not find the domain controller for this domain.
Exemple de sortie à partir de repadmin /showreps la commande :
DC=ForestDnsZones,DC=Contoso,DC=com
HQ\Contoso-DC02 via RPC
DC object GUID:1b136427-14f0-448a-965c-9cbb61400fcd._msdcs.Contoso.com/
Last attempt @ <DATE> <TIME> failed, result 1908 (0x774):
Could not find the domain controller for this domain.
<# consecutive failure>
<Last Success>
2. Le KCC NTDS, les événements de réplication NTDS avec l’état 1908 sont enregistrés dans le journal des
SO URC E DE C AT ÉGO RIE DE TYPE C H A ÎN E

L 'ÉVÉN EM EN T L 'ÉVÉN EM EN T ID D’ÉVÈN EM EN T D'ÉVÉN EM EN T D’ÉVÉN EM EN T
NTDS KCC Vérification de la 1926 Avertissement La tentative

cohérence des d’établissement
connaissances d’un lien de
réplication vers une
partition de
répertoire en
lecture seule avec
les paramètres
suivants a échoué.
NTDS KCC Vérification de la 1925 Avertissement La tentative

cohérence des d’établissement
connaissances d’un lien de
réplication pour la
partition de
répertoire
accessible en texte
Réplication NTDS Replication 1943 Error Active Directory n’a

(Réplication) pas pu supprimer
tous les objets en
attente sur le
contrôleur de
domaine local.
Toutefois, certains
objets en attente
peuvent avoir été
supprimés sur ce
contrôleur de
domaine avant
l’arrêt de cette
opération.
L’existence de tous
les objets a été
vérifiée sur le
contrôleur de
domaine source
suivant.
Réplication NTDS Configuration 1125 Error L’Assistant

Installation des
services de
domaine Active
Directory
(Dcpromo) n’a pas
pu établir de
connexion avec le
contrôleur de
domaine suivant.
Ces événements contiennent la valeur de sous-erreur suivante :

Valeur d’erreur :
Le contrôleur de domaine de ce domaine n’a pas pu être trouvé. 1908
3. Lorsque vous essayez de forcer la réplication dans la console sites et services Active Directory
(dssite.msc) via l’option « Répliquer maintenant », il se peut que nous recevions l’erreur ci-dessous :

Texte du message de <Naming Context> <Source-DC-Name> <Destination-DC-Name>boîte de
dialogue : l’erreur suivante s’est produite lors de la tentative de synchronisation du contexte
d’attribution de noms du contrôleur de domaine au contrôleur de domaine : Le contrôleur de
domaine n’a pas pu être trouvé pour ce domaine.
Message d’échec : le contrôleur de domaine de ce domaine n’a pas pu être trouvé.
4. Promotion/rétrogradation du contrôleur de domaine

Boîte de dialogue sur Dcpromo.exe échec :
Texte du titre de la boîte de dialogue : Assistant Installation d’Active Directory
Texte du message de boîte de dialogue : Active Directory n’a pas pu créer l’objet Paramètres NTDS pour ce
contrôleur de domaine CN=NTDS Paramètres,CN=<DC_Name>,CN=Servers,CN=
<SiteName>,CN=Sites,CN=Configuration,<DomainDN> <Remote_DC_FQDN>sur le contrôleur de
domaine supprimé. Assurez-vous que les informations d’identification réseau fournies ont des
autorisations suffisantes.
Message d’échec : le contrôleur de domaine de ce domaine n’a pas pu être trouvé.
Rapports de fichier DCPromo.log(%windir%\debug\DCPromo.log) :
[INFO] Erreur - Les services de domaine Active Directory n’ont pas pu créer l’objet Paramètres NTDS pour
ce contrôleur de domaine Active Directory CN=NTDS Paramètres,CN=CONTOSO-
DC02,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Contoso,DC=com sur
le dc AD distant contoso-dc01.Contoso.com . Assurez-vous que les informations d’identification réseau
fournies ont des autorisations suffisantes. (1908)
[INFO] NtdsInstall pour la Contoso.com 1908 renvoyée
[INFO] DsRolepInstallDs renvoyé 1908
[ERROR] Échec de l’installation dans le service d’annuaire (1908)
Cause
Le code d’erreur 1908 représente l’erreur qui s’affiche comme « Le contrôleur de domaine pour ce domaine n’a
pas pu être trouvé ». Cette erreur a deux causes principales :
1. Le dc de destination ne peut pas contacter un centre de distribution de clés (KDC)
2. L’ordinateur rencontre des erreurs liées à Kerberos
Un concept important à comprendre pour ce scénario est que le KDC utilisé pour les opérations de réplication
peut être :
a. Dc de destination
b. The source DC
c. Un dc totalement différent (pas le DC source ou de destination).
Résolution
1. Vérifier que le service de distribution de clés est en cours d’exécution sur le contrôleur de domaine cible
Découvrez le centre de distribution de clés Kerberos que vous contactez. Il peut être découvert à l’aide
d’un programme de capture de paquets tel que Moniteur réseau 3.4 ( disponible ici.)
a. Utilisez le moniteur réseau pour capturer le message d’erreur reproduit. (Vous devrez peut-être
d’abord arrêter le service client DNS afin de voir le trafic de requête DNS)
b. Examinez la capture de paquets pour la requête DNS pour un KDC : exemples de requêtes
d’adresse :
_kerberos. tcp.<SiteName>. _sites.dc._msdcs.<Domain> com
_kerberos._tcp.dc._msdcs<Domain>.. com
c. Examen du trafic DCLocator :
Exemple de capture Network Monitor 3.4 du trafic DcLocator. Dans cet exemple, 10.0.1.11 est le
KDC que nous avons découvert et 10.0.1.10 est le client qui demande un ticket. Il utilise la
disposition de colonne moniteur réseau par défaut.
H EURE ET DÉC A L A GE DE A DRESSE IP A DRESSE IP DE

F RA M E # DAT E T EM P S SO URC E DEST IN AT IO N DÉTA IL S
42 3/7/2012 3.6455760 10.0.1.10 10.0.1.11 LDAPMessage

: Demande de
recherche,
MessageID :
371 *** Ce
paquet est un
appel LDAP
UDP pour DC
Locator à la
recherche de
Netlogon***
43 3/7/2012 3.6455760 10.0.1.11 10.0.1.10 NetLogon:Log

onSAMPauseR
esponseEX
(réponse SAM
lorsque
Netlogon est
suspendu) : 24
(0x18)
d. Vérifiez que le KDC Netlogon et les services de 10.10.1.11 sont en cours d’exécution. Sur le
contrôleur de domaine découvert(10.0.1.11), vérifiez le KDC Netlogon et l’état du service avec la
requête SC
Exemple : interrogez le service KDC avec : « SC Query KDC Netlogon » et le service avec : « SC
Query Netlogon » Ces commandes doivent renvoyer « State: Running »
2. Vérifier que le contrôleur de domaine de destination est Publicité en tant que centre de distribution de
clés
Utilisez DCDIAG.exe pour vérifier que le contrôleur de domaine de destination est une publicité. À partir
dCMD.exe invite de commandes, exécutez la commande suivante :
C:\DCDiag.exe /v /test:Advertising /test:SysVolCheck

Vérifiez que le contrôleur de domaine réussit les tests advertising et SYSVOLCHeck et qu’il fait de la
publicité en tant que centre de distribution SysVol de clés et qu’il est prêt. Si SysVol ce n’est pas le cas,
le serveur ne pourra pas faire de publicité en tant que contrôleur de domaine.
Serveur de test :<SiteName><DC Name>

Test de démarrage : Publicité
Le dc <DC Name> se fait publicité en tant que DC et a un DS
Le dc <DC Name> fait de la publicité en tant que serveur LDAP
Le dc <DC Name> est publicitaire comme ayant un répertoire accessible en écriture
Le dc est <DC Name> une publicité en tant que centre de distribution de clés
Le dc <DC Name> fait de la publicité en tant que serveur de temps
Les DS sont <DC Name> des publicités en tant que GC.
Test de démarrage : test prêt pour SysVolCheck * du service de réplication de fichiers SYSVOL
SYSVOL du service de réplication de fichiers est prêt
..<DC Name> test réussi SysVolCheck
3. Vérifiez que l’ordinateur source et l’ordinateur cible sont à 5 minutes l’un de l’autre.
4. Vérifier les échecs Kerberos
a. Activez la journalisation des événements Kerberos sur l’ordinateur client et les contrôleurs de domaine
dans le site.
b. KB : 262177 comment activer la journalisation des événements Kerberos
c. Dépannage de Kerberos
Cette erreur est l’un des exercices présentés dans le laboratoire pratique TechNet suivant : Laboratoire pratique
TechNet : Résolution des erreurs de réplication Active Directory
Dans ce laboratoire, vous allez parcourir les phases de dépannage, d’analyse et d’implémentation des erreurs de
réplication Active Directory couramment rencontrées. Vous utiliserez une combinaison d’outils ADREPLSTATUS,
repadmin.exe et d’autres outils pour résoudre les problèmes d’un environnement de cinq dc à trois domaines.
Les erreurs de réplication AD rencontrées dans l’atelier incluent -2146893022, 1256, 1908, 8453 et 8606.
Comment résoudre les erreurs qui se produisent
quand vous joignez des ordinateurs Windows à un
domaine
Cet article décrit plusieurs messages d’erreur courants qui peuvent s’afficher quand vous joignez des
ordinateurs clients Windows à un domaine. Cet article fournit également des suggestions de dépannage pour
ces erreurs.
Où trouver le fichier Netsetup.log

Les clients Windows consignent les détails des opérations de jonction de domaine dans le fichier
%windir%\debug\Netsetup.log.
Messages d’erreur de mise en réseau et résolutions

Erreur 1
Échec d’une tentative de résolution du nom DNS d’un contrôleur de domaine dans le domaine sur le point
d’être joint. Veuillez vérifier que ce client est configuré pour accéder à un serveur DNS pouvant résoudre des
noms DNS dans le domaine cible.
Résolution
Quand vous tapez le nom de domaine, veillez à taper le nom DNS (Domain Name System) et non le nom
NetBIOS (Network Basic Input/Output System). Par exemple, si le nom DNS du domaine cible est contoso.com ,
entrez contoso.com au lieu du nom de domaine NetBIOS « contoso ».
En outre, vérifiez que l’ordinateur peut accéder à un serveur DNS qui héberge la zone DNS du domaine cible ou
résoudre les noms DNS dans ce domaine. Assurez-vous que le serveur DNS correct est configuré sur ce client
en tant que serveur DNS préféré et que le client dispose d’une connectivité à ce serveur. Pour le vérifier, exécutez
l’une des commandes suivantes :
nltest /dsgetdc:<netbios domain name>/force
nltest /dsgetdc:<DNS domain name>/force
Erreur 2
Échec d’une tentative de résolution du nom DNS d’un contrôleur de domaine dans le domaine sur le point
d’être joint. Veuillez vérifier que ce client est configuré pour accéder à un serveur DNS pouvant résoudre des
noms DNS dans le domaine cible.
Résolution
Quand vous tapez le nom de domaine, veillez à taper le nom DNS et non le nom NetBIOS.
En outre, vérifiez que l’ordinateur peut accéder à un serveur DNS qui héberge la zone DNS du domaine cible ou
résoudre les noms DNS dans ce domaine. Assurez-vous que le serveur DNS correct est configuré sur ce client
en tant que serveur DNS préféré et que le client dispose d’une connectivité à ce serveur. Pour le vérifier, exécutez
l’une des commandes suivantes :
Erreur 3
Une opération a été tentée sur une connexion réseau qui n’existe pas.
Résolution
Quand vous tapez le nom de domaine, veillez à taper le nom DNS et non le nom NetBIOS. En outre, redémarrez
l’ordinateur avant d’essayer de joindre l’ordinateur au domaine.
Erreur 4
Plusieurs connexions à un serveur ou à une ressource partagée par le même utilisateur, en utilisant plus
d’un nom utilisateur, ne sont pas autorisées. Supprimez toutes les connexions précédentes au serveur ou à
la ressource partagée et recommencez.
Résolution
Redémarrez l’ordinateur que vous essayez de joindre au domaine pour vous assurer qu’il n’existe aucune
connexion latente à l’un des serveurs de domaine.
Erreur 5
Nom de réseau introuvable.
Résolution
Vérifiez que l’ordinateur peut accéder à un serveur DNS qui héberge la zone DNS du domaine cible ou résoudre
les noms DNS dans ce domaine. Assurez-vous que le serveur DNS correct a été configuré sur ce client en tant
que serveur DNS préféré et que le client dispose d’une connectivité à ce serveur. Pour le vérifier, exécutez l’une
des commandes suivantes :
En outre, vous pouvez mettre à jour le pilote de la carte réseau.
Erreur 6
Il n’est plus possible d’établir une connexion avec cet ordinateur distant en ce moment car il y a déjà autant
de connexions que l’ordinateur peut en accepter.
Résolution
Avant de joindre l’ordinateur au domaine, assurez-vous d’avoir effacé toutes les connexions mappées à tous les
lecteurs.
Redémarrez l’ordinateur que vous essayez de joindre au domaine pour vous assurer qu’il n’existe aucune
connexion latente à l’un des serveurs de domaine.
L’erreur peut être temporaire. Veuillez réessayer plus tard. Si le problème persiste, vérifiez l’état du contrôleur de
domaine auquel le client se connecte (connexions actives, connectivité réseau, etc.). Redémarrez le contrôleur de
domaine si le problème persiste.
Erreur 7
Le format du nom réseau spécifié n’est pas valide.
Résolution
Vérifiez que l’ordinateur peut accéder à un serveur DNS qui héberge la zone DNS du domaine cible ou résoudre
les noms DNS dans ce domaine. Assurez-vous que le serveur DNS correct a été configuré sur ce client en tant
que serveur DNS préféré et que le client dispose d’une connectivité à ce serveur. Pour le vérifier, exécutez l’une
des commandes suivantes :
Quand vous tapez le nom de domaine, veillez à taper le nom DNS et non le nom NetBIOS. Assurez-vous que les
pilotes les plus récents sont installés pour la carte réseau de l’ordinateur client. Vérifiez la connectivité entre le
client en cours de jonction et le contrôleur de domaine cible par le biais des ports et protocoles requis.
Désactivez la fonctionnalité de déchargement TCP Chimney et le déchargement IP.
Erreur 8
Le service d’annuaire a épuisé la réserve d’identificateurs relatifs.
Résolution
Assurez-vous que le contrôleur de domaine qui héberge le maître d’opérations d’ID relatifs (RID) est en ligne et
fonctionnel. Pour plus d’informations, consultez l’article ID d’événement 16650 : Échec de l’initialisation de
l’allocation d’identificateur de compte dans Windows Server.
NOTE
Vous pouvez utiliser la commande netdom query fsmo pour déterminer le contrôleur de domaine qui dispose du rôle
Maître RID.
Vérifiez qu’Active Directory est répliqué entre tous les contrôleurs de domaine. Utilisez la commande suivante
pour détecter les erreurs éventuelles :
repadmin /replsummary /bysrc /bydest /sort:delta
Erreur 9
L’appel de procédure distante a échoué et ne s’est pas exécuté.
Résolution
Assurez-vous que les pilotes les plus récents sont installés pour la carte réseau de l’ordinateur client. Vérifiez la
connectivité entre le client en cours de jonction et le contrôleur de domaine cible par le biais des ports et
protocoles requis. Désactivez la fonctionnalité de déchargement TCP Chimney et le déchargement IP.
Ce problème peut également survenir dans l’un des cas suivants :
Un périphérique réseau (routeur, pare-feu ou périphérique VPN) bloque la connectivité sur les ports et
protocoles utilisés par le protocole MSRPC.
Un périphérique réseau (routeur, pare-feu ou périphérique VPN) rejette les paquets réseau entre le client en
cours de jonction et le contrôleur de domaine.
NOTE
Les articles suivants contiennent des informations sur les exigences relatives aux ports :
832017 Vue d’ensemble du service et exigences relatives aux ports réseau pour Windows
179442 Comment configurer un pare-feu pour les domaines et les approbations
Erreur 10
Échec de la modification du nom DNS du domaine principal de cet ordinateur en « ... ». Le nom restera « ... ».
Le serveur spécifié ne peut pas effectuer l’opération.
Résolution
Cette erreur se produit quand vous utilisez l’interface utilisateur de jonction de domaine pour joindre un
ordinateur de groupe de travail Windows 7 ou Windows Server 2008 R2 à un domaine Active Directory en
spécifiant le domaine DNS cible. Pour corriger cette erreur, consultez l’article 2018583 La jonction de domaine
Windows 7 ou Windows Server 2008 R2 affiche l’erreur « Échec de la modification du nom DNS du domaine
principal de cet ordinateur en « ... » ».
Messages d’erreur d’authentification et résolutions

Erreur 1
Vous avez dépassé le nombre maximal de comptes d’ordinateur que vous êtes autorisé à créer dans ce
domaine.
Résolution
Assurez-vous que vous êtes autorisé à ajouter des ordinateurs au domaine et que vous n’avez pas dépassé le
quota défini par votre administrateur de domaine.
Pour joindre un ordinateur au domaine, le compte d’utilisateur doit disposer des autorisations de création
d’objets d’ordinateur dans Active Directory.
NOTE
Par défaut, un utilisateur non-administrateur peut joindre un maximum de 10 ordinateurs à un domaine Active Directory.
Erreur 2
Échec d’ouverture de session : le nom du compte cible est incorrect.
Résolution
Vérifiez que les contrôleurs de domaine sont inscrits à l’aide d’adresses IP correctes sur le serveur DNS et que
leur nom de principal du service (SPN) sont correctement inscrits dans le compte Active Directory
correspondant.
Erreur 3
Échec d’ouverture de session : l’utilisateur ne bénéficie pas du type d’ouverture de session demandé sur cet
ordinateur.
Résolution
Assurez-vous que vous êtes autorisé à ajouter des ordinateurs au domaine. Pour joindre un ordinateur au
domaine, le compte d’utilisateur doit disposer de l’autorisation de création d’objets d’ordinateur dans Active
Directory.
En outre, assurez-vous que le compte d’utilisateur spécifié est autorisé à ouvrir une session locale sur
l’ordinateur client. Pour ce faire, configurez le paramètre Permettre l’ouver ture d’une session locale dans la
stratégie de groupe sous Configuration ordinateur > Paramètres Windows > Paramètres de
sécurité > Stratégies locales > Attribution des droits utilisateur .
Erreur 4
Échec d’ouverture de session : nom d’utilisateur inconnu ou mot de passe incorrect.
Résolution
Veillez à utiliser la combinaison correcte de nom d’utilisateur et de mot de passe d’un compte d’utilisateur
Active Directory existant quand vous êtes invité à entrer des informations d’identification pour ajouter
l’ordinateur au domaine.
Erreur 5
Le mappage entre les noms de compte et les ID de sécurité n’a pas été effectué.
Résolution
Il s’agit probablement d’une erreur temporaire consignée quand une jonction de domaine recherche le domaine
cible pour déterminer si un compte d’ordinateur correspondant a déjà été créé ou si l’opération de jonction doit
créer dynamiquement un compte d’ordinateur sur le domaine cible.
Erreur 6
Mémoire insuffisante pour cette opération.
Résolution
Cette erreur peut se produire quand la taille du jeton Kerberos est supérieure à la taille maximale par défaut.
Dans ce cas, vous devez augmenter la taille du jeton Kerberos de l’ordinateur que vous essayez de joindre au
domaine. Pour plus d’informations, consultez les articles suivants de la Base de connaissances :
935744 Message d’erreur « Mémoire insuffisante pour cette opération » quand vous utilisez un contrôleur de
domaine pour joindre un ordinateur à un domaine
327825 Problèmes liés à l’authentification Kerberos lorsqu’un utilisateur appartient à de nombreux groupes
Erreur 7
Le compte n’est pas autorisé à se connecter depuis cette station.
Résolution
Ce problème est lié à des paramètres de signature SMB différents entre l’ordinateur client et le contrôleur de
domaine contacté pour l’opération de jonction de domaine. Consultez la documentation suivante pour connaître
les valeurs actuelles et recommandées dans votre environnement :
281648 Message d’erreur : Le compte n’est pas autorisé à se connecter depuis cette station 823659 Des
problèmes de poste client, de services ou de programmes peuvent se produire si vous modifiez les paramètres
de sécurité et les attributions des droits utilisateur
Erreur 8
Le compte spécifié pour ce service est différent du compte spécifié pour d’autres services s’exécutant dans le
même processus.
Résolution
Assurez-vous que le service de temps Windows a démarré sur le contrôleur de domaine via lequel vous essayez
de joindre le domaine.
Impossible de joindre Windows Server 2008 R2 ou
Windows 7 au domaine Active Directory
Cet article permet de résoudre un problème dans lequel les utilisateurs ne peuvent pas joindre un ordinateur à
un domaine Active Directory.
Symptômes
Vous essayez de joindre un ordinateur Windows Server 2008 R2 ou Windows 7 à un domaine Active Directory
à l’aide des modifications de nom d’ordinateur/de domaine sous Propriétés système.
Le domaine de destination Windows contrôleurs de domaine Windows 2000, Windows Server 2003 ou
Windows Server 2008 et peut avoir Windows contrôleurs de domaine NT 4.0 présents. Lorsque vous essayez de
joindre l’ordinateur Windows Server 2008 R2 au domaine en spécifiant le nom de domaine complet (FQDN)
dans l’interface utilisateur de jointeur de domaine, l’opération échoue et vous recevez l’erreur :
Impossible de contacter un contrôleur de domaine Active Directory (AD DC) pour <target DNS domain
name> le domaine
S’assurer que le nom de domaine est correctement tapé
Dans le %windir%\debug\Netsetup.log client, vous voyez la séquence suivante :
<DateTime> NetpValidateName : vérifier si « CLIENT-NAME » est valide comme nom de type 1

<DateTime> NetpCheckNetBiosNameNotInUse pour « CLIENT-NAME »[MACHINE] renvoyé 0x0
<DateTime> NetpValidateName : le nom « CLIENT-NAME » est valide pour le type 1
<DateTime>
<DateTime> NetpValidateName : vérifier si « CLIENT-NAME » est valide comme nom de type 5
<DateTime> NetpValidateName : le nom « CLIENT-NAME » est valide pour le type 5
<DateTime>
*<DateTime>*NetpValidateName : vérification domain.com pour voir si est valide en tant que nom de
type 3
*<DateTime>*NetpCheckDomainNameIsValid for domain.com returned 0x54b, last error is 0x0
*<DateTime>*NetpCheckDomainNameIsValid [ Exists domain.com ] pour les 0x54b
Lorsque vous essayez de joindre l’ordinateur Windows Server 2008 R2 au domaine en spécifiant le nom
NetBIOS dans l’interface utilisateur de jointage de domaine, vous recevez une erreur différente :
L’erreur suivante s’est produite lors de la tentative de joindre le <NetBIOS target domain name> domaine.
Le domaine spécifié n’existe pas ou n’a pas pu être contacté.
Dans le %windir%\debug\Netsetup.log client, vous voyez la séquence suivante :
<DateTime> -----------------------------------------------------------------
<DateTime> NetpDoDomainJoin
<DateTime> NetpMachineValidToJoin: 'CLIENT-NAME'
<DateTime> Version du système d’exploitation : 6.1
<DateTime> Numéro de build : 7600 (7600.win7_rtm.090713-1255)
<DateTime> Référence (SKU) : Windows Server 2008 R2 Entreprise
<DateTime> NetpDomainJoinLicensingCheck: ulLicenseValue=1, Status: 0x0
<DateTime> NetpGetLsaPrimaryDomain: status: 0x0
<DateTime> NetpMachineValidToJoin: status: 0x0
<DateTime> NetpJoinDomain
<DateTime> Ordinateur : CLIENT-NAME
<DateTime> Domaine : Domain_Name
<DateTime> MachineAccountOU: (NULL)
<DateTime> Compte : Domain_Name\admx054085
<DateTime> Options : 0x27
<DateTime> NetpLoadParameters : chargement des paramètres de Registre...
<DateTime> NetpLoadParameters : DNSNameResolutionRequired in found, defaulting to '1' 0x2
<DateTime> NetpLoadParameters : DomainCompatibilityMode in found, defaulting to '0' 0x2
<DateTime> NetpLoadParameters: status: 0x2
<DateTime> NetpValidateName : vérifier si « Domain_Name » est valide comme nom de type 3
<DateTime> NetpValidateName : « Domain_Name » n’est pas un nom de domaine Dns valide : 0x2554
<DateTime> NetpCheckDomainNameIsValid [ Exists ] for 'Domain_Name' returned 0x0
<DateTime> NetpValidateName : le nom « Domain_Name » est valide pour le type 3
<DateTime> NetpDsGetDcName : essayer de trouver DC dans le domaine « Domain_Name » , indicateurs :
0x40001010
*<DateTime>*NetpDsGetDcName : échec de recherche d’un dc dans le domaine spécifié : 0x54b, la
dernière erreur est 0x0
*<DateTime>*NetpJoinDomainOnDs : NetpDsGetDcName renvoyé : 0x54b
*<DateTime>*NetpJoinDomainOnDs : sor ties de fonction avec l’état : 0x54b
*<DateTime>*NetpDomainJoin: status: 0x54b
Les joints de domaine Windows Server 2003 au même domaine cible réussissent en spécifiant le nom de
domaine NetBIOS dans l’interface utilisateur de jointre le domaine. Les jointeurs de domaine à l’aide du nom de
domaine (FQDN) échouent également.
Vous pouvez également joindre le même ordinateur Windows Server 2008 R2 à un autre domaine Active
Directory dans la même forêt en spécifiant le nom de domaine complet.
Cause
Les erreurs se produisent si NT4Emulator est 0x1 dans la sous-clé de Registre suivante du contrôleur de
domaine d’aide utilisé pour joindre le domaine cible :
Nom de la valeur : NT4Emulator
Résolution
Pour résoudre ce problème, supprimez la valeur de Registre NT4Emulator sur les contrôleurs de domaine
Active Directory dans le domaine de destination si Windows les contrôleurs de domaine NT 4.0 ne sont plus
présents ou peuvent être retirés. Sinon, définissez la valeur de Registre suivante sur le client Windows 7 ou
Windows Server 2008 R2 avant d’essayer de joindre le domaine :
1. Démarrez l’Éditeur du Registre ( Regedit.exe ).
2. Localisez la clé suivante dans le Registre :
3. S’il n’existe pas, créez une nouvelle REG_DWORD nomméeEmulatorEmulator, et définissez la valeur
sur 0x1 .
Ce paramètre de Registre permet aux contrôleurs de domaine Active Directory avec le paramètre NT4Emulator
de répondre normalement au client demandeur (en évitant Windows mode d’émulation NT 4.0).
Dans le cas de la jointage par nom de domaine général, le client qui rejoint le domaine ne reçoit pas de réponse
adéquate aux pings LDAP qu’il envoie aux contrôleurs de domaine au début du processus de jointation de
domaine. Le contrôleur de domaine d’aide répond, mais le client joint considère que la réponse est incomplète.
Après avoir reçu les mêmes réponses de tous les contrôleurs de domaine situés à l’aide du DNS, il revient à
exécuter une requête nom NetBIOS pour le nom de domaine FQDN pour localiser un contrôleur de domaine,
mais cela n’obtient aucune réponse et l’opération de jointage échoue. Si le scénario NetBIOS le client envoie un
NetLogonSamRequest à tous les contrôleurs de domaine qu’il reçoit de la requête WINS pour le nom de
domaine. Toutefois, il ne reçoit aucune réponse adéquate et échoue avec la deuxième erreur.
Windows 7 ou Windows Server 2008 R2 affiche une
erreur (échec de la modification du nom DNS de
domaine principal de cet ordinateur sur « ». ...)
Cet article fournit une solution à une erreur qui se produit lorsque vous utilisez l’interface utilisateur de jointage
de domaine pour joindre un ordinateur de groupe de travail Windows 7 ou Windows Server 2008 R2 à un
domaine Active Directory en spécifiant le nom de domaine DNS cible.
Symptômes
L’utilisation de l’interface utilisateur de jointage de domaine pour joindre un ordinateur de groupe de travail
Windows 7 ou Windows Server 2008 R2 à un domaine Active Directory en spécifiant le nom de domaine DNS
cible échoue avec l’erreur à l’écran suivante :
La modification du nom DNS de domaine principal de cet ordinateur sur « » a échoué. Le nom restera
«<DNS domain> .<top level domain> ».
L’erreur était :
Le serveur spécifié ne peut pas effectuer l’opération requise.
The NETSETUP. LOG sur l’ordinateur joint contient le texte suivant :
<date><time> NetpSetDnsHostNameAndSpn : Échec de NetpLdapBind : 0x3a
où 0x3a cartes à :
ERREUR D’IN T ERFA C E C H A ÎN E D’ERREUR

UT IL ISAT EUR SY M B O L IQ UE H EX ERRO R # ERREUR DÉC IM A L E #
Le serveur spécifié ne peut ERROR_BAD_NET_RESP 0x3a 58

pas effectuer l’opération
Les cas où l’erreur « Modification du nom DNS du domaine principal. » s’affiche avec des erreurs étendues
autres que « le serveur spécifié ne peut pas effectuer l’opération requise », y compris celles répertoriées dans le
tableau ci-dessous, ne sont PAS liés au symptôme, à la cause ou au texte de résolution décrits dans cet article.
Erreurs étendues qui font que « Modification du nom DNS principal... » les erreurs non liées à cette ko sont les
suivantes :
ERREUR ÉT EN DUE
Une erreur spécifique au package de sécurité s’est produite
L’appel de procédure distante a échoué et ne s’est pas exécuté

Cause
Lorsqu’un ordinateur est joint au domaine, il tente d’inscrire un nom principal de service pour s’assurer que son
suffixe DNS est autorisé dans le domaine cible. Le domaine joint à l’interface utilisateur interroge les
informations de la base de données de stratégie de l’autorité de sécurité locale (LSA) pour les noms (NetBIOS)
courts et longs (DNS) du domaine cible.
L’erreur décrite dans la section Symptômes se produit parce qu’une fonction de l’interface utilisateur de jointure
de domaine effectue de manière incorrecte une liaison LDAP à un contrôleur de domaine dans le domaine cible
par son nom court, ce qui échoue dans l’une des conditions suivantes :
La case à cocher Désactiver NetBIOS sur TCP/IP a été désactivée dans les propriétés IPv4 de
l’ordinateur joint.
La connectivité sur le port UDP 137 est bloquée entre le client et le dc d’aide qui dessert l’opération de
jointage dans le domaine cible.
Le protocole TCP/IPv4 a été désactivé afin que le client joint ou le dc dans le domaine de destination ciblé par
LDAP BIND exécute uniquement TCP/IPv6.
Résolution
Malgré l’apparence de l’erreur à l’écran décrite dans la section Symptômes , l’opération de jointage de domaine
se termine comme le prouve l’état dans NETSETUP. LOG.
RÉUSSITE NetpCompleteOfflineDomainJoin : Redémarrage demandé :0x0

NetpDomainJoin: status: 0x0
Pour éliminer l’erreur, utilisez l’une des méthodes suivantes :

Vérifiez que NetBIOS sur TCP/IP est activé.
1. Cliquez sur Démarrer , Sur Exécuter, tapezncpa.cpl, puis cliquez sur OK .
2. Dans Connexions réseau , cliquez avec le bouton droit sur Connexion à la zone locale, puis cliquez
sur Propriétés .
3. Cliquez sur Protocole Internet version 4 (TCP/IPv4), puis sur Propriétés .
4. Dans la boîte de dialogue Propriétés du protocole Internet version 4 (TCP/IPv4 ), cliquez sur
Avancé .
5. Sous l’onglet WINS , vérifiez que l’activer sur TCP/IP est activé, puis cliquez trois fois sur OK .
Vérifiez la connectivité réseau de bout en bout sur le port UDP 137 sur le chemin d’accès réseau qui
connecte l’être client et le DC d’aide qui sert l’opération de jointage.
Si l’erreur s’est produite dans un environnement IPv6 uniquement ou si vous avez besoin d’un correctif
pour résoudre l’erreur, ouvrez un incident de support avec le support technique et le service clientèle
Microsoft demandant un correctif post RTM pour Windows 7/Windows Server 2008 R2.
Ajoutez le suffixe DNS de domaine dans les propriétés TCP/IP.
1. Cliquez sur Démarrer , Sur Exécuter, tapezncpa.cpl, puis cliquez sur OK .
2. Dans Connexions réseau , cliquez avec le bouton droit sur Connexion à la zone locale, puis cliquez
sur Propriétés .
3. Cliquez sur Protocole Internet version 4 (TCP/IPv4), puis sur Propriétés .
4. Dans la boîte de dialogue Propriétés du protocole Internet version 4 (TCP/IPv4 ), cliquez sur
Avancé .
5. Sous l’onglet DNS , sélectionnez ces suffixes DNS, cliquez sur Ajouter, tapez le nom de domaine du
domaine dans la boîte de dialogue Serveur DNS **, cliquez** sur Ajouter, puis sur OK trois fois.
Les contrôleurs de domaine ne peuvent pas être
localisés et les sessions sortantes à tarif élevé
Cet article explique comment résoudre le problème où un ordinateur crée des sessions sortantes à un taux
élevé.
Lorsque ce problème se produit, le service Netlogon tente de localiser les contrôleurs de domaine (DCS) pour
les utilisateurs et les ressources de domaine, et d’établir le chemin d’accès d’confiance entre les utilisateurs et les
domaines de ressources.
Dans certains scénarios, le problème peut affecter la communication entre les serveurs d’applications (par
exemple, les serveurs Exchange) ou la communication entre les serveurs d’applications et les serveurs back-end
(par exemple, les serveurs web, de base de données ou de rapports). Si le niveau d’activité des applications
dépasse un seuil, les serveurs d’applications ne pourront pas avoir de sessions entre eux ou avec des serveurs
de serveur principale.
De nombreux ports UDP sont utilisés par le processus LSASS

De nombreux ports UDP (User Datagram Protocol) sont utilisés par le processus LSASS (Local Security
Authority Subsystem Service).
[lsass.exe]
UDP 0.0.0.0:54335 *:* 908
Dans le fichier journal Netlogon (netlogon.log), de nombreuses entrées semblables aux suivantes sont
enregistrées :
[CRITICAL] NetpDcPingListIp: INTERNAL.CONTOSO.COM: Cannot LdapOpen ip address XX.YY.ZZ.26: 58

Vous trouvez également le délai d’accès aux demandes. Lorsque vous liez l’ID de thread, vous pouvez trouver le
type de demandes qui arrive à son délai d’accès. Consultez les journaux suivants pour obtenir un exemple :
[MAILSLOT] [32192] NetpDcPingListIp: INTERNAL.CONTOSO.COM: Sent UDP ping to XX.YY.ZZ.119

…
[CRITICAL] [32192] NetpDcGetPingResponse: it took 117063 msecs to poll|
Finalement, les demandes de localisation des DCS échouent et les journaux suivants sont enregistrés :
[MISC] [32192] DsGetDcName function called: client PID=180, Dom:INTERNAL.CONTOSO.COM Acct:(null) Flags: IP
KDC
…
[MISC] [32192] DsGetDcName function returns 1355 (client PID=180): Dom:INTERNAL.CONTOSO.COM Acct:(null)
Flags: IP KDC
Vous pouvez vérifier d’autres demandes pour établir des modèles afin d’identifier les domaines les plus affectés
et si toutes les demandes échouent dans le fichier netlogon.log. Pour rechercher un modèle, utilisez une
commande comme suit :
findstr DsGetDcName netlogon.log | findstr /i /c:"internal." > netlogon-internal-calls.txt
Cela permet de déterminer si un dc est fréquemment demandé, car un autre dc ne répond pas. Si vous identifiez
un dc qui fonctionne lentement ou ne répond pas, rétablissez la communication avec les DCS du domaine ou
améliorez les performances.
Dans un vidage mémoire du processus LSASS, les threads sont en attente avec la pile comme suit :
# Call Site
00 ntdll!RtlLeaveCriticalSection+0x29
01 Wldap32!ReferenceLdapRequest+0x44
02 Wldap32!LdapGetResponseFromServer+0x207
03 Wldap32!LdapWaitForResponseFromServer+0x27a
04 Wldap32!ldap_result_with_error+0x293
05 Wldap32!ldap_result+0x74
06 netlogon!NetpDcGetPingResponse+0xec
07 netlogon!NetpDcPingListIp+0x1df
08 netlogon!NetpDcGetNameSiteIp+0xa3
09 netlogon!NetpDcGetNameIp+0x188
0a netlogon!NetpDcGetName+0x11bb
0b netlogon!DsIGetDcName+0x463
0c netlogon!DsrGetDcNameEx2+0x3a0
0d kerberos!KerbGetKdcBinding+0x8e8
0e kerberos!KerbMakeSocketCall+0x165
0f kerberos!KerbGetTgsTicketEx+0x9ee
10 kerberos!KerbGetTgsTicket+0x84
11 kerberos!KerbGetServiceTicketInternal+0x739
12 kerberos!KerbGetServiceTicket+0xca
13 kerberos!KerbILogonUserEx2+0x1b2f
14 kerberos!LsaApLogonUserEx2+0xa6
15 lsasrv!NegLogonUserEx2Worker+0x7c7
16 lsasrv!NegLogonUserEx2+0x673
17 lsasrv!LsapCallAuthPackageForLogon+0xd0
18 lsasrv!LsapAuApiDispatchLogonUser+0x4ab
19 lsasrv!SspiExLogonUser+0x20e
1a sspisrv!SspirLogonUser+0x1eb
1b rpcrt4!Invoke+0x65
Épuisement des sockets UDP

Lorsqu’un port UDP est utilisé, la connexion est dans un état TIME_WAIT avant de pouvoir être réutilisée. Si les
applications sur le système utilisent différents sockets UDP à un taux élevé, ou si de nouveaux sockets sont
requis à un taux supérieur à la vitesse à laquelle les sockets inutilisés sont nettoyés, le système risque d’être à
court de sockets. Le système peut se retrouver dans un état qui ne récupère jamais, en particulier si les
applications retentent fréquemment la communication. Dans ce scénario, le service Netlogon utilise un nouveau
socket UDP pour chaque tentative de découverte dc.
NOTE
La plage de sockets par défaut est de 16 384 sockets depuis Windows Vista.
Lorsqu’un dc n’est pas réactif (par exemple, les DCS sont hors connexion ou bloqués par un pare-feu), le service
Netlogon backs up a queue of threads waiting to resolve DCs.
Autoriser davantage de sockets UDP et réutiliser d’anciens sockets
précédemment
Configurez le Registre pour autoriser l’utilisation de plus de sockets UDP pour les demandes d’application. En
outre, réduisez la durée pendant qu’une connexion reste à l’état TIME_WAIT, afin que le protocole TCP/IP
(Transmission Control Protocol/Internet Protocol) puisse réutiliser d’anciens sockets précédemment. Voici les
étapes à effectuer :
1. Ouvrez l’Éditeur du Registre.
2. Accédez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters .
3. Modifiez ou créez les entrées de Registre comme suit :
N O M DE L A VA L EUR DO N N ÉES DE L A VA L EUR
TcpTimedWaitDelay 30
MaxUserPort 65000
StrictTimeWaitSeqCheck 1
Windows Server 2019 introduit une nouvelle entrée de Registre qui permet au service Netlogon de ne pas
utiliser de nouveau socket pour chaque tentative de découverte de dc. L’entrée nommée
DCLocatorLdapConnectionCacheEnabled se trouve dans le chemin d’accès du
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Registre. Les données de valeur
peuvent être définies sur 1 pour activer cette fonctionnalité.
NOTE
Vous pouvez définir les données de valeur sur 0 pour désactiver la fonctionnalité.
Activer le protocole LDAP sur SSL avec une autorité
de certification tierce
Cet article explique comment activer le protocole LDAP (Lightweight Directory Access Protocol) sur SSL (Secure
Sockets Layer) avec une autorité de certification tierce.
Résumé
Le protocole LDAP est utilisé pour lire et écrire dans Active Directory. Par défaut, le trafic LDAP est transmis sans
sécurité. Vous pouvez rendre le trafic LDAP confidentiel et sécurisé en utilisant la technologie SSL/TLS (Transport
Layer Security). Vous pouvez activer le protocole LDAP sur SSL (LDAPS) en installant un certificat correctement
mis en forme à partir d’une autorité de certification Microsoft ou d’une autorité de certification non-Microsoft
en appliquant les procédures fournies dans cet article.
Il n’existe aucune interface utilisateur permettant de configurer le protocole LDAPS. L’installation d’un certificat
valide sur un contrôleur de domaine permet au service LDAP d’écouter et d’accepter automatiquement les
connexions SSL pour le trafic LDAP et le trafic de catalogue global.
Conditions requises pour un certificat LDAPS

Pour activer le protocole LDAPS, vous devez installer un certificat qui remplit les conditions suivantes :
Le certificat LDAPS se trouve dans le magasin de certificats personnel de l’ordinateur local (également
connu, en termes de programmation, sous le nom de magasin de certificats MY).
Une clé privée qui correspond au certificat est présente dans le magasin de l’ordinateur local et est
associée correctement au certificat. La protection renforcée de clés privées ne doit pas être activée pour la
clé privée.
L’extension Utilisation améliorée de la clé inclut l’identificateur d’objet Authentification du serveur
(1.3.6.1.5.5.7.3.1) (également appelé OID).
Le nom de domaine complet Active Directory du contrôleur de domaine (par exemple, dc01.contoso.com)
doit apparaître à l’un des emplacements suivants :
le nom commun (CN) dans le champ Subject ;
l’entrée DNS dans l’extension Autre nom de l’objet.
Le certificat a été publié par une autorité de certification approuvée par le contrôleur de domaine et les
clients LDAPS. L’approbation est établie en configurant les clients et le serveur de façon à approuver
l’autorité de certification racine à laquelle est enchaînée l’autorité de certification émettrice.
Utilisez le fournisseur de services de chiffrement (CSP) Schannel pour générer la clé.
Créer la demande de certificat

Tout utilitaire ou application qui crée une demande PKCS #10 valide peut être utilisé pour former la demande de
certificat SSL. Utilisez Certreq pour former la demande.
Certreq.exe requiert un fichier d’instructions texte afin de générer une demande de certificat X.509 appropriée
pour un contrôleur de domaine. Vous pouvez créer ce fichier à l’aide de votre éditeur de texte ASCII par défaut.
Enregistrez le fichier en tant que fichier .inf dans un dossier quelconque sur votre disque dur.
Pour demander un certificat d'authentification serveur adapté au protocole LDAPS, procédez comme suit :
1. Créez le fichier .inf. Voici un exemple de fichier .inf qui peut être utilisé pour créer la demande de
certificat.
;----------------- request.inf -----------------

[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=<DC fqdn>" ; replace with the FQDN of the DC
KeySpec = 1
KeyLength = 1024
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
;-----------------------------------------------
Coupez et collez l’exemple de fichier dans un nouveau fichier texte nommé Request.inf. Indiquez le nom
DNS complet du contrôleur de domaine dans la demande.
Certaines autorités de certification tierces peuvent nécessiter des informations supplémentaires dans le
paramètre Subject, telles qu’une adresse de courrier (E), une unité d’organisation (OU), une organisation
(O), une ville (L), un département/État ou une province (S) et un pays ou une région (C). Vous pouvez
ajouter ces informations au nom Subject (CN) dans le fichier Request.inf. Par exemple :
Subject="E=admin@contoso.com, CN=<DC fqdn>, OU=Servers, O=Contoso, L=Redmond,

S=Washington, C=US."
2. Créez le fichier de demande en exécutant la commande suivante à l’invite de commandes :
certreq -new request.inf request.req
Un fichier nommé Request.req est créé. Il s’agit du fichier de demande codé en base64.
3. Soumettez la demande à une autorité de certification. Vous pouvez soumettre la demande à une autorité
de certification Microsoft ou tierce.
4. Récupérez le certificat qui est émis, puis enregistrez-le en tant que Certnew.cer dans le même dossier que
le fichier de demande en procédant comme suit :
a. Créez un fichier nommé Certnew.cer.
b. Ouvrez le fichier dans le Bloc-notes, collez le certificat codé dans le fichier, puis enregistrez le fichier.
NOTE
Le certificat enregistré doit être codé en base64. Certaines autorités de certification tierces retournent le certificat
publié au demandeur en tant que texte codé en base64 dans un message électronique.
5. Acceptez le certificat émis en exécutant la commande suivante à l’invite de commandes :
certreq -accept certnew.cer
6. Vérifiez que le certificat est installé dans le magasin personnel de l’ordinateur en procédant comme suit :
a. Démarrez la console MMC (Microsoft Management Console).
b. Ajoutez le composant logiciel enfichable Certificats qui gère les certificats sur l’ordinateur local.
c. Développez Cer tificats (ordinateur local) , Personnel , puis Cer tificats . Il doit exister un nouveau
certificat dans le magasin personnel. Dans la boîte de dialogue Propriétés du cer tificat , le rôle
prévu affiché est Authentification ser veur . Ce certificat est publié au nom d’hôte complet de
l’ordinateur.
Pour plus d’informations sur la création de la demande de certificat, consultez le livre blanc suivant sur
l’inscription et la gestion de certificats avancées. Pour afficher ce livre blanc, consultez l’article Advanced
Certificate Enrollment and Management (en anglais uniquement).
Vérifier une connexion LDAPS

Après avoir installé un certificat, procédez comme suit pour vérifier que le protocole LDAPS est activé :
1. Démarrez l’outil d’administration Active Directory (Ldp.exe).
2. Dans le menu Connexion , cliquez sur Connecter .
3. Tapez le nom du contrôleur de domaine avec lequel établir une connexion.
4. Tapez 636 pour le numéro de port
5. Cliquez sur OK .
Les informations RootDSE doivent s’imprimer dans le volet droit, indiquant la réussite de la connexion.
Problèmes possibles
Demande étendue Start TLS
La communication LDAPS a lieu sur le port TCP 636. La communication LDAPS à un serveur de catalogue
global a lieu sur le port TCP 3269. Lors de la connexion au port 636 ou 3269, SSL/TLS est négocié avant
l’échange du trafic LDAP.
Certificats SSL multiples
Schannel, le fournisseur SSL Microsoft, sélectionne le premier certificat valide qu’il trouve dans le
magasin de l’ordinateur local. Si plusieurs certificats valides sont disponibles dans le magasin de
l’ordinateur local, Schannel peut ne pas sélectionner le certificat correct.
Problème de mise en cache de certificat SSL pré-SP3
Si un certificat LDAPS existant est remplacé par un autre certificat, par le biais d’un processus de
renouvellement ou car l’autorité de certification émettrice a changé, le serveur doit être redémarré pour
que Schannel utilise le nouveau certificat.
Améliorations
La recommandation d’origine de cet article était de placer les certificats dans le magasin personnel de
l’ordinateur local. Cette option est prise en charge, mais vous pouvez également placer les certificats dans le
magasin de certificats personnel du service NTDS sous Windows Server 2008 ainsi qu’avec les versions
ultérieures de Active Directory Domain Services (AD DS). Pour plus d’informations sur l’ajout du certificat au
magasin de certificats personnel du service NTDS, consultez l'article Event ID 1220 - LDAP over SSL.
AD DS recherche de préférence des certificats dans ce magasin plutôt que dans le magasin de l’ordinateur local.
Cela facilite la configuration d’AD DS pour utiliser le certificat approprié. Cela se produit car le magasin
personnel des ordinateurs locaux peut comprendre plusieurs certificats, ce qui peut rendre difficile la prévision
du choix.
AD DS détecte l’ajout d’un nouveau certificat dans son magasin et déclenche la mise à jour d'un certificat SSL
sans impliquer le redémarrage d’AD DS ni du contrôleur de domaine.
Une nouvelle opération rootDse nommée renewServerCertificate permet de déclencher manuellement la mise à
jour par AD DS de ses certificats SSL, sans redémarrer AD DS ni le contrôleur de domaine. Cet attribut peut être
mis à jour au moyen de adsiedit.msc ou en important la modification au format LDAP Directory Interchange
Format (LDIF) au moyen de ldifde.exe. Pour plus d’informations sur l’utilisation de LDIF pour mettre à jour cet
attribut, consultez renewServerCertificate.
Enfin, si un contrôleur de domaine Windows Server 2008 ou version ultérieure trouve plusieurs certificats dans
son magasin, il sélectionne automatiquement le certificat dont la date d’expiration est la plus éloignée dans le
futur. Si le certificat actuel approche de sa date d’expiration, vous pouvez ignorer le certificat de remplacement
dans le magasin et AD DS l’utilise automatiquement.
Ces procédures fonctionnent sous Windows Server 2008 AD DS et AD LDS 2008 (Active Directory Lightweight
Directory Services). Pour AD LDS, placez les certificats dans le magasin de certificats personnel du service qui
correspond à l’instance AD LDS et non au service NTDS.
Comment désactiver TLS 1.3 pour AD et LDAP
Les mises à jour Windows KB5014668 et KB5014665 ajoutent la prise en charge de TLS (Transport Layer
Security) 1.3 lors de l’utilisation de LDAP sur SSL ou de l’émission de la StartTLS commande. Les mises à jour
ont été publiées le 21/06/2022.
Vous devrez peut-être désactiver la prise en charge de TLS 1.3 pour des raisons de compatibilité. Cet article
explique comment désactiver ou réactiver la prise en charge de TLS 1.3.
Désactiver ou réactiver TLS 1.3

IMPORTANT
Côté serveur LDAP

Utilisez l’Éditeur du Registre pour modifier les valeurs suivantes afin de désactiver ou réactiver TLS 1.3 pour
le protocole LDAP (Lightweight Directory Access Protocol) côté serveur :
Clé de Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Valeur du Registre : LdapDisableTLS1.3
Données de valeur : 0 (activé par défaut) / 1 (désactivé)
Redémarrez le service ser vices de domaine Active Director y pour que le paramètre soit effectif.
Côté client LDAP
Utilisez l’Éditeur du Registre pour modifier les valeurs suivantes afin de désactiver ou réactiver TLS 1.3 pour
LDAP côté client :
Clé de Registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP
Valeur du Registre : DisableTLS1.3
Données de valeur : 0 (activé par défaut) / 1 (désactivé)
Le paramètre commence à prendre effet à la connexion LDAP suivante.
Comment activer la signature LDAP dans Windows
Server
Cet article décrit comment activer la signature LDAP dans Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, et Windows 10.
S ʼapplique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 (toutes les
éditions)
Résumé
La sécurité d’un serveur d’annuaire peut être considérablement améliorée en le configurant pour qu’il rejette les
liaisons LDAP SASL (Simple Authentication and Security Layer) qui ne demandent pas de signature (vérification
d’intégrité) ou pour qu’il rejette les liaisons LDAP simples effectuées sur une connexion avec texte en clair (non
chiffrée via SSL/TLS). Les liaisons SASL peuvent inclure des protocoles tels que Negotiate, Kerberos, NTLM et
Digest.
Le trafic réseau non signé est susceptible de réexécuter des attaques. Dans de tels cas, un intrus intercepte la
tentative d’authentification et l’émission d’un ticket. Le pirate peut réutiliser le ticket pour usurper l'identité de
l'utilisateur légitime. En outre, tout trafic réseau non signé est exposé à des attaques de l’intercepteur (MIM), où
le pirate intercepte des paquets entre le client et le serveur, les modifie, puis les transfère au serveur. Si ce
problème se produit sur un serveur LDAP, l'attaquant peut obliger le serveur à prendre des décisions basées sur
des requêtes contrefaites provenant du client LDAP.
Comment découvrir les clients qui n’utilisent pas l’option Exiger la

signature
Les systèmes clients basés sur des liaisons LDAP SASL (Negotiate, Kerberos, NTLM ou Digest) non signées ou
sur des liaisons LDAP simples sur une connexion non-SSL/TLS cessent de fonctionner après cette modification
de configuration. Pour vous aider à identifier ces clients, le serveur d’annuaire Active Directory Domain Services
(AD DS) ou Lightweight Directory Server (LDS) enregistre un ID d’événement récapitulatif 2887 une fois toutes
les 24 heures pour indiquer le nombre de liaisons de ce type. Nous vous recommandons de configurer les
systèmes clients afin d'éviter d'utiliser ces types de liaisons. Si aucun événement correspondant n'est observé
durant une longue période, il est recommandé de configurer le serveur de sorte qu'il rejette ces liaisons.
Si vous avez besoin de plus d'informations pour identifier ces clients, vous pouvez configurer le serveur
d'annuaire pour qu'il fournisse des journaux plus détaillés. Cette journalisation supplémentaire enregistrera un
ID d’événement 2889 lorsqu’un client essaie d’établir une liaison LDAP non signée. L’entrée du journal affiche
l’adresse IP du client et l’identité que le client a essayé d’utiliser pour l’authentification. Vous pouvez activer ces
informations supplémentaires en définissant le paramètre de diagnostic 16 événements d’interface LDAP
sur 2 (de base) . Pour plus d’informations sur la modification des paramètres de diagnostic, consultez la section
Comment configurer la journalisation des événements de diagnostic Active Directory et LDS.
Si le serveur d’annuaire est configuré pour rejeter les liaisons LDAP simples ou les liaisons LDAP SASL non
signées sur une connexion non-SSL/TLS, le serveur d’annuaire enregistre un ID d’événement récapitulatif 2888
une fois toutes les 24 heures lorsque ces tentatives de liaison se produisent.
Comment configurer l’annuaire pour exiger la signature du serveur
LDAP pour AD DS
Pour plus d’informations sur les conséquences possibles de la modification des paramètres de sécurité,
consultez la section Incompatibilités au niveau des clients, des services et des programmes pouvant survenir
lors de la modification des paramètres de sécurité et des attributions de droits d’utilisateur.
NOTE
Anomalie de journalisation de l’ID d’événement 2889
Les applications qui utilisent des clients LDAP tiers peuvent entraîner la génération d’entrées d’ID d’événement 2889
incorrectes par Windows. Cela se produit lorsque vous enregistrez des événements d’interface LDAP et si
LDAPServerIntegrity est égal à 2 . L’utilisation du chiffrement satisfait à la protection contre les attaques MIM, mais
Windows enregistre quand même l’ID d’événement 2889.
Cela se produit lorsque les clients LDAP utilisent uniquement le chiffrement avec SASL. Nous avons vu cela dans le champ
en association avec des clients LDAP tiers.
Lorsqu’une connexion ne s’appuie pas simultanément sur une signature et un verrouillage, la vérification des exigences de
sécurité de connexion utilise correctement les indicateurs et se déconnecte. La vérification génère l’erreur 8232
(ERROR_DS_STRONG_AUTH_REQUIRED).
Utilisation de la stratégie de groupe

Comment définir la condition pour la signature de serveur LDAP
1. Cliquez sur Démarrer > Exécuter , tapez mmc.exe, puis sélectionnez OK .
2. Sélectionnez Fichier > Ajouter/Supprimer un composant logiciel enfichable , sélectionnez Éditeur de
gestion des stratégies de groupe , puis cliquez sur Ajouter .
3. Sélectionnez Objet de stratégie de groupe > Rechercher .
4. Dans la boîte de dialogue Rechercher un objet de stratégie de groupe , cliquez sur Stratégie du
contrôleur de domaine par défaut sous la section Domaines, unités d’organisation et objets de
stratégie de groupe liés , puis cliquez sur OK .
5. Sélectionnez Terminer .
7. Développez Stratégie par défaut des contrôleurs de domaine > Configuration ordinateur >
Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales , puis cliquez sur
Options de sécurité .
8. Cliquez avec le bouton droit sur Contrôleur de domaine : exigences de signature du ser veur LDAP ,
puis sélectionnez Propriétés .
9. Dans la boîte de dialogue Propriétés de conditions requises pour la signature de ser veur LDAP ,
activez l’option Définir ce paramètre de stratégie , cliquez sur Exiger la signature dans la liste
déroulante Définir ce paramètre de stratégie , puis cliquez sur OK .
10. Dans la boîte de dialogue Confirmer la modification du paramètre , sélectionnez Oui .
Comment définir la condition pour la signature de client LDAP via une stratégie d’ordinateur local
1. Cliquez sur Démarrer > Exécuter , tapez mmc.exe, puis sélectionnez OK .
2. Sélectionnez Fichier > Ajouter/Supprimer un composant logiciel enfichable .
3. Dans la boîte de dialogue Ajouter ou supprimer des composants logiciels enfichables , cliquez sur
Éditeur d’objets de stratégie de groupe , puis sur Ajouter .
6. Sélectionnez Stratégie d’ordinateur local > Configuration ordinateur > Stratégies > Paramètres
Windows > Paramètres de sécurité > Stratégies locales , puis cliquez sur Options de sécurité .
7. Cliquez avec le bouton droit sur Sécurité réseau : conditions de signature du client LDAP , puis
sélectionnez Propriétés .
8. Dans la boîte de dialogue Sécurité réseau : propriétés des conditions de signature du client LDAP ,
cliquez sur Exiger la signature dans la liste, puis sélectionnez OK .
Comment définir la condition de signature du client LDAP via un objet de stratégie de groupe de domaine
1. Cliquez sur Démarrer > Exécuter , tapez mmc.exe , puis sélectionnez OK .
2. Sélectionnez Fichier > Ajouter/Supprimer un composant logiciel enfichable .
3. Dans la boîte de dialogue Ajouter ou supprimer des composants logiciels enfichables , cliquez sur
Éditeur d’objets de stratégie de groupe , puis sur Ajouter .
4. Cliquez sur Parcourir , puis sélectionnez Stratégie de domaine par défaut (ou l’objet de stratégie de
groupe pour lequel vous voulez activer la signature du client LDAP).
7. Sélectionnez Fermer .
9. Sélectionnez Stratégie de domaine par défaut > Configuration ordinateur > Paramètres Windows
> Paramètres de sécurité > Stratégies locales , puis cliquez sur Options de sécurité .
10. Dans la boîte de dialogue Sécurité réseau : propriétés des conditions de signature du client LDAP ,
cliquez sur Exiger la signature dans la liste, puis sélectionnez OK .
Comment définir la condition de signature du client LDAP avec les clés du registre
IMPORTANT
Par défaut, la clé de Registre n'est pas disponible pour les services AD LDS (Active Directory Lightweight
Directory Services). Par conséquent, vous devez créer une entrée de registre LDAPServerIntegrity de type
REG_DWORD sous la sous-clé de registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<InstanceName>\Parameters
NOTE
L’espace réservé à <InstanceName> représente le nom de l’instance AD LDS à modifier.
Comment vérifier les modifications de la configuration

1. Connectez-vous à un ordinateur sur lequel les outils d’administration AD DS sont installés.
2. Sélectionnez Démarrer > Exécuter , tapez ldp.exe, puis cliquez sur OK .
3. Sélectionnez Connexion > Connecter .
4. Dans les champs Ser veur et Por t , tapez le nom du serveur et le port non-SSL/TLS de votre serveur
d’annuaire, puis cliquez sur OK .
NOTE
Pour un contrôleur de domaine Active Directory, le port applicable est 389.
5. Une fois la connexion établie, sélectionnez Connexion > Liaison .
6. Sous Type de liaison , sélectionnez Liaison simple .
7. Tapez le nom d’utilisateur et le mot de passe, puis cliquez sur OK .
Si le message d’erreur ci-dessous s’affiche, cela signifie que vous avez correctement configuré votre
serveur d’annuaire :
Ldap_simple_bind_s() a échoué : authentification forte requise
References
ADV190023 : conseils Microsoft pour l’activation de la liaison de canal LDAP et de la signature LDAP
Conditions requises pour la liaison de canal LDAP 2020 et la signature LDAP pour Windows
Comment activer la journalisation du débogage du
client LDAP (Wldap32.dll)
Cet article explique comment activer la journalisation du débogage du client LDAP (Wldap32.dll).
S’applique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Window 10 - toutes les
éditions
Résumé
Dans Windows Vista et les versions plus récentes de Windows, vous pouvez utiliser le suivi d’événements pour
Windows (ETW) pour suivre l’activité du client LDAP, y compris l’activité chiffrée (TLS ou SASL).
Pour activer le suivi du client LDAP, suivez les étapes suivantes :
1. Créez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ldap\Tracing\<ProcessName>
NOTE
Dans cette sous-clé, est le nom complet du processus que vous souhaitez suivre, y <ProcessName> compris son
extension. Par exemple : « ldp.exe ». À l’intérieur de cette sous-clé, vous pouvez placer une entrée facultative
nommée « PID » et qui a une valeur DWORD. Si vous définissez la valeur sur un ID de processus, seule l’instance
de l’application qui possède cet ID de processus sera tracée.
IMPORTANT
Si vous n’avez pas cette sous-clé de Registre pour au moins un processus, le fichier de suivi ne contiendra pas de
données.
2. Pour démarrer une session de suivi, exécutez la commande suivante à une invite de commandes :
logman create trace "ds_ds" -ow -o c:\ds_ds.etl -p "Microsoft-Windows-LDAP-Client" 0x1a59afa3 0xff -

nb 16 16 -bs 1024 -mode Circular -f bincirc -max 4096 -ets
NOTE
Dans cette commande, « 0x1a59afa3 » est un indicateur de suivi. Ces indicateurs contrôlent les
informations enregistrées et la verbosité des données. Vous pouvez utiliser des indicateurs individuels ou
combiner des valeurs de bits pour spécifier plusieurs indicateurs simultanément. Pour les scénarios de
suivi courants, les combinaisons d’indicateurs suivantes sont utiles :
0x1A59AFA3 . Paramètres de journal qui doivent obtenir les informations dont vous avez besoin
la plupart du temps.
0x18180380 . Obtenir des informations spécifiques sur les problèmes d’établissement de
connexion.
0x1bddbf73 . Informations détaillées sur la session.
Pour plus d’informations sur les indicateurs disponibles, voir la section «Valeursdes indicateurs de
suivi » de « Utilisation d’ETW pour résoudre les problèmes deconnexions LDAP».
3. Reproduisez le comportement que vous souhaitez examiner.

4. Pour arrêter la session de suivi, exécutez la commande suivante :
logman stop "ds_ds" -ets
Pour afficher le suivi en tant que texte, utilisez l’outil pour décoder le fichier ETL sous la .txt netsh fichier, comme
suit :
netsh trace convert input=c:\ds_ds.etl output=LDAP_CLIENT-formatted.txt
Pour plus d’informations netsh trace convert sur , voir netsh trace convert l’aide. Pour ce faire, entrez à
netsh trace convert /? l’invite de commandes.
Les requêtes paginations LDAP avec références
subordonnées ne sont pas correctement dirigées
Cet article fournit certaines approches pour éviter que les requêtes paginationS LDAP avec références
subordonnées ne soient pas correctement dirigées.
Symptômes
Vous avez une application qui recherche dans Active Directory des recherches paginés à l’aide de
ldap_search_ext ou ldap_search_ext_s, et elle est définie pour poursuivre les références. Lorsqu’elle recherche
hors de la racine d’un NC de domaine, les recherches paginés se terminent prématurément après la première
page.
Dans l’application, le cookie pagayé qu’elle reçoit est vide et l’application met donc fin à la requête. Dans un suivi
réseau, vous pouvez vérifier que la requête pagiée retourne un cookie non vide avec une ou plusieurs
références. La plupart des requêtes ne voient aucun jeu de résultats lors de la référence, car souvent les objets
recherchés dans le domaine NC n’existent pas dans les NCs subordonnés, sauf s’il s’agit également de NCs de
domaine.
L’application peut également recevoir une « erreur opérationnelle » après la première page.
Un contrôleur de domaine renvoie des références subordonnées pour les contextes d’attribution de noms
suivants :
1. Lors de la recherche à la racine de la forêt : Configuration NC (suivie d’une référence pour le NC de schéma)
2. Lors de la recherche de la racine de la forêt : ForestDnsZones NC
3. DomainDnsZones NC
4. Tous les domaines enfants. Et récursivement tous les domaines petits-enfants en bas de l’arborescence de
domaine entière.
Cause
Il existe plusieurs problèmes lors de l’utilisation de références lors d’une requête pagiée :
1. Lors de l’attribution de noms aux contextes situés sur le même serveur (voir 1. et peut-être 2. et 3. ci-dessus),
l’événement se produit sur la même session LDAP, en effasant le cookie pagaué renvoyé dans la requête
principale dans le runtime LDAP client.
2. Lorsque la dernière référence pourchamp dépasse également la taille de page, le cookie de référence reçu de
la dernière NC pourchamp est utilisé pour poursuivre la recherche principale. Cela entraîne l’échec de la
recherche LDAP avec une « erreur opérationnelle », car le cookie ne correspond pas aux connaissances du
serveur sur l’index et la position d’index de la recherche.
3. Lorsque la recherche principale est effectuée à l’aide d’une liaison simple sans SSL, la tâche des références
échoue avec « erreur opérationnelle », car le client LDAP est conçu pour ne pas envoyer les informations
d’identification en texte clair lors de références de références.
Résolution
Il n’existe actuellement aucune solution au problème.
Vous pouvez utiliser les approches suivantes dans votre application pour éviter les problèmes :
1. Utilisez un DN de base qui évite que le serveur renvoie des références subordonnées, par exemple, effectuer
une recherche dans une ou sous l’objet racine du domaine.
2. Recherchez le catalogue global au lieu du domaine racine de la forêt NC. Vous devez vous assurer que tous
les attributs que vous souhaitez sont présents dans le GC et que vous souhaitez vraiment que la forêt entière
soit entière au lieu de l’arborescence de domaine que vous avez recherché précédemment.
3. Si vous ne souhaitez pas que les références soient automatiquement pourchassée : comme les références
sont pourchassés par défaut, utilisez ldap_set_option avec l’indicateur LDAP_OPT_REFERRALS pour
désactiver la référence. Vous pouvez toujours poursuivre les références manuellement après avoir terminé la
requête principale.
4. Utilisez le contrôle pour LDAP_SERVER_DOMAIN_SCOPE_OID recherche, il éteint les références de
continuation lors de la recherche de racines de domaine.
Lorsque vous exécutez une requête LDAP sur un
contrôleur de domaine, vous obtenez une liste
d’attributs partielle
Cet article fournit des solutions de contournement pour le problème lorsque vous exécutez une requête LDAP
sur un contrôleur de domaine, vous obtenez une liste d’attributs partielle.
Symptômes
Lorsque vous exécutez une demande LDAP (Lightweight Directory Access Protocol) sur un contrôleur de
domaine Windows Server 2008, vous obtenez une liste d’attributs partielle. Toutefois, si vous exécutez la même
requête LDAP sur un contrôleur de domaine Windows Server 2003, vous obtenez une liste d’attributs complète
dans la réponse.
NOTE
Vous pouvez exécuter cette requête à partir du contrôleur de domaine ou d’un ordinateur client exécutant Windows Vista
ou Windows Server 2008.
Le compte d’utilisateur que vous utilisez pour exécuter la requête LDAP possède les propriétés suivantes :
Le compte est membre du groupe Administrateurs intégré.
Le compte n’est pas le compte d’administrateur intégré.
Le compte est membre du groupe Administrateurs du domaine.
La liste de contrôle d’accès discrétionnaire (DACL) de l’objet utilisateur contient l’autorisation contrôle total
pour le groupe Administrateurs.
Les autorisations effectives de l’objet sur qui vous interrogez indiquent que l’utilisateur dispose de
l’autorisation contrôle total.
Cause
Ce problème se produit car la fonctionnalité Mode d’approbation d’administration est activée pour le compte
d’utilisateur dans Windows Vista et Windows Server 2008. Il est également appelé « contrôle de compte
d’utilisateur ». Pour l’accès aux ressources locales, le système de sécurité dispose d’un code de boucle de sorte
qu’il utilise le jeton d’accès actif de la session d’ouverture de session interactive pour la session LDAP et les
vérifications d’accès pendant le traitement des requêtes LDAP.
Pour plus d’informations sur la fonctionnalité AAM, visitez le site Web Microsoft TechNet suivant :
Pour contourner ce problème, appliquez l’une des méthodes ci-dessous.
Méthode 1
1. Utilisez l’option Exécuter en tant qu’administrateur pour ouvrir une fenêtre d’invite de commandes.
2. Exécutez la requête LDAP dans la fenêtre d’invite de commandes.
Méthode 2
Spécifiez la valeur d’invite Non pour le paramètre de sécurité suivant :
Contrôle de compte d’utilisateur : comportement de l’invite d’élévation pour les administrateurs en mode
d’approbation d’administrateur
Pour plus d’informations sur la spécification de la valeur de ce paramètre de sécurité, visitez le site Web
Microsoft TechNet suivant : https://technet.microsoft.com/library/cc772207(WS.10).aspx
Méthode 3
1. Créez un groupe dans le domaine.
2. Ajoutez le groupe Administrateurs du domaine à ce nouveau groupe.
3. Accordez l’autorisation lecture sur la partition de domaine à ce nouveau groupe. Pour cela, procédez comme
suit :
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez adsiedit.msc, puis cliquez sur OK.
b. Dans la fenêtre ADSI Edit, cliquez avec le bouton droit sur DC= <Name> ,DC=com, puis cliquez
sur Propriétés .
c. Dans la fenêtre Propriétés, cliquez sur l’onglet Sécurité.
d. Sous l’onglet Sécurité , cliquez sur Ajouter .
e. Sous Entrez les noms des objets à sélectionner, tapez le nom du nouveau groupe, puis cliquez
sur OK.
f. Assurez-vous que le groupe est sélectionné sous les noms de groupes ou d’utilisateurs, cliquez pour
sélectionner Autoriser l’autorisation lecture, puis cliquez sur OK.
g. Fermez la fenêtre ADSI Edit.
4. Exécutez à nouveau la requête LDAP.
Statut
Par défaut, la fonctionnalité AAM est désactivée pour le compte d’administrateur intégré dans Windows Vista et
Windows Server 2008. En outre, la fonctionnalité AAM est activée pour les autres comptes membres du groupe
Administrateurs intégré.
Pour vérifier cela, exécutez la commande suivante dans une fenêtre d’invite de commandes.
whoami /all
Si la fonctionnalité AAM est activée pour le compte d’utilisateur, la sortie ressemble à ce qui suit.
USER INFORMATION
----------------
User Name SID

============== ==============================================
MyDomain\MyUser S-1-5-21-2146773085-903363285-719344707-326360
GROUP INFORMATION
-----------------
Group Name Type SID Attributes

============================================= ================
=================================================
===============================================================
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Administrators Alias S-1-5-32-544 Group used for deny only
Le groupe Administrateurs intégré possède l’attribut suivant :
Group used for deny only
Le groupe « Administrateurs de domaine » est affiché comme groupe activé avec « Groupe obligatoire, Activé
par défaut, Groupe activé » dans whoami /all, mais il est vraiment désactivé pour autoriser les ace. Il s’agit d’un
problème connu dans Windows Server 2008 R2 et Windows Server 2012.
En fonction de cette sortie, la fonctionnalité AAM est activée pour le compte d’utilisateur que vous avez utilisé
pour exécuter la requête LDAP. Lorsque vous exécutez la requête LDAP, vous utilisez un jeton d’accès filtré au lieu
d’un jeton d’accès total. Même si l’autorisation contrôle total pour le groupe Administrateurs est accordée à
l’objet utilisateur, vous n’avez toujours pas l’autorisation contrôle total. Par conséquent, vous obtenez
uniquement une liste d’attributs partielle.
La configuration des nouvelles sessions pour les
services LDAP prend plus de temps que prévu si le
ciblage des noms d’hôtes
Cet article traite d’un problème dans lequel une nouvelle configuration de session pour les services LDAP prend
plus de temps que prévu s’il cible des noms d’hôtes.
S’applique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 – toutes
les éditions
Symptômes
Les requêtes LDAP (Lightweight Directory Access Protocol) qui ciblent les noms d’hôtes prennent de façon
aléatoire plus de temps que prévu pour répondre.
En outre, les événements clients DNS tels que les suivants peuvent être enregistrés dans le journal des
événements :

Source : Microsoft-Windows-DNS-Client
Utilisateur : SERVICE RÉSEAU
Description :
Résolution de noms pour le nom _ldap._tcp.<site> _sites.<name> expiré après qu’aucun des serveurs DNS
configurés n’a répondu.
NOTE
Dans cette entrée de journal, le <name> paramètre peut être l’un des éléments suivants :
Nom NETBIOS du domaine
Nom d’hôte du contrôleur de domaine
Nom d’hôte FQDN du contrôleur de domaine DNS
Ce problème provoque plusieurs problèmes qui affectent les administrateurs, les utilisateurs et les applications.
Ces problèmes incluent, mais ne sont pas limités aux éléments suivants :
Une connexion LDAP à des contrôleurs de domaine Windows Server 2008 R2 ou version ultérieure prend
environ six secondes. Les mêmes connexions aux contrôleurs de domaine Windows Server 2003 ou
Windows Server 2008 prennent généralement moins d’une seconde. Lorsque cela se produit, les opérations
LDAP suivantes, telles que les recherches de liaison et LDAP, semblent n’avoir aucun délai supplémentaire
après la connexion LDAP initiale.
La commande LDIFDE.EXE est lente, que le /Sparameter soit utilisé ou non.
Le script de contrôle d’intégrité (AD_General_Response.vbs) du pack d’administration Microsoft System
Center Active Directory (SCOM ADMP) connaît des temps d’exécution lents.
Microsoft Utilisateurs et ordinateurs Active Directory (ADUC) est lent à démarrer ou lent pour ouvrir des
conteneurs d’unité d’organisation. Extensions du composant logiciel enfichable Utilisateurs et ordinateurs
Active Directory, DSA. MSC, utilise le nom d’ordinateur FQDN dc comme nom de domaine.
Les extensions du Centre d’administration Microsoft Active Directory (ADAC) dans le Centre d’administration
Active Directory utilisent le nom d’ordinateur FQDN DC comme nom de domaine.
Microsoft stratégie de groupe Management Console (GPMC) n’utilise pas systématiquement les indicateurs
de résolution de noms.
Les scripts Visual Basic Script (VBS) qui effectuent des appels LDAP qui référencent le nom DNS complet du
contrôleur de domaine sont lents à s’exécuter.
Les applications .NET Framework qui utilisent System.Director ySer vices et
System.Director ySer vices.Protocols peuvent rencontrer des retards lors de la création de sessions
serveur.
Cause
À compter de Windows 7 et Windows Server 2008 R2, Windows a introduit une modification du comportement
de recherche de noms pour résoudre deux scénarios de problème antérieurs :
Les clients LDAP revient à NTLM chaque fois que le nom de domaine NetBIOS est fourni comme nom d’hôte
dans la connexion LDAP.
Les clients LDAP ne se connectent pas à un contrôleur de domaine dans le domaine si un client porte le
même nom que le nom de domaine NetBIOS ciblé.
Le délai se produit parce que l’une des deux conditions suivantes est vraie :
Vous rencontrez un temps d’attente long pour une réponse de diffusion. Vous ne voyez pas ce délai si
NetBIOS sur la résolution de noms TCP/IP (NetBT) via des diffusions est désactivé.
Des retards dans la résolution de noms DNS se produisent lorsque l’application interroge plusieurs noms
DNS qui n’existent pas.
Les retards peuvent être observés dans une trace réseau qui montre les clients LDAP exécutant des recherches
de noms NetBIOS pour un enregistrement « [HOSTNAME]<0x1C> » avant d’exécuter une recherche DNS pour
localiser l’ordinateur hôte de l’application (voir la figure A).
Figure A
La trace réseau d’un client Windows Server 2003 ou 2008 LDAP a montré qu’il exécutait directement la
recherche DNS pour l’ordinateur hôte sans effectuer la recherche NetBIOS pour l’enregistrement « <0x1C> ».
Figure B
Dans le cas de DNS, vous voyez des requêtes de nom pour les noms qui se terminent par un nom d’ordinateur
DC, comme suit :
_ldap._tcp. Default-First-Site-Name._sites. ADDC01.contoso.com
_ldap._tcp. ADDC01.contoso.com
_ldap._tcp. Default-First-Site-Name._sites. ADDC01
_ldap._tcp. ADDC01
Résolution
Lorsque vous ciblez un serveur LDAP par nom d’hôte au lieu d’un nom de domaine, vous devez utiliser l’option
de session LDAP_OPT_AREC_EXCLUSIVE pour indiquer que la cible est un nom d’hôte au lieu d’un nom de
domaine.
Cette option est définie différemment en fonction de l’interface de programmation utilisée. Utilisez les
informations suivantes comme référence.
Wldap32
Si un nom de serveur DNS Active Directory est passé pour theHostNameparameter, ldap_set_option devez être
appelé pour définir l’indicateur de LDAP_OPT_AREC_EXCLUSIVE avant d’appeler une fonction LDAP qui crée la
connexion réelle.
Cela force une recherche d’enregistrement A et contourne toute recherche d’enregistrement SRV lorsque
l’ordinateur résout le nom d’hôte. Dans certains scénarios, il améliore les performances du réseau. Par exemple,
dans une filiale qui utilise une connexion rendez-vous, l’utilisation de la recherche A-Record peut éviter de forcer
la numérotation à interroger un serveur DNS distant pour les enregistrements SRV lorsqu’il résout les noms.
ADSI
Si vous devez spécifier un serveur, utilisez l’indicateur ADS_SERVER_BIND pour éviter les requêtes inutiles ou
incorrectes sur le serveur DNS. Pour plus d’informations, consultez cette documentation sur ADsOpenObject() et
les fonctions associées.
System.DirectoryServices
Si votre ADsPath inclut un nom de serveur, spécifiez l’indicateur AuthenticationTypes.ServerBind lorsque vous
utilisez le fournisseur LDAP. N’utilisez pas cet indicateur pour les chemins d’accès qui incluent un nom de
domaine ou pour les chemins serverless. La spécification d’un nom de serveur sans spécifier cet indicateur
entraîne un trafic réseau inutile.
Par exemple :
DirectoryEntry ent = new DirectoryEntry(« LDAP://server01 »,null,null,AuthenticationTypes.ServerBind);
System.directoryservices.protocols
Lorsque vous préparez une nouvelle connexion LDAP, incluez un objet LdapDirectoryIdentifier construit à l’aide
d’un nom d’hôte et d’un port facultatif que vous souhaitez contacter, et qui inclut également un
<fullyQualifiedDnsHostName> paramètre défini sur True .
Le nouveau comportement par défaut dans Windows 7, Windows Server 2008 R2 et les versions ultérieures
peut être rétabli au comportement antérieur à Windows 7. Cela peut réintroduire des problèmes qui affectent
les noms NetBIOS, comme décrit dans la section « Cause ». Toutefois, il existe également des scénarios dans
lesquels le comportement pré-Windows 7 fournit de meilleurs résultats. Par conséquent, le paramètre qui
produit les meilleurs résultats dépend du scénario d’utilisation du client LDAP principal.
La solution à long terme doit toujours consister à demander à l’application d’utiliser des noms de serveur et de
domaine qui ont les indicateurs appropriés lors de l’appel aux interfaces LDAP, ADSI ou .NET. Vous devez utiliser
les indicateurs corrects pour rendre l’application indépendante des dépendances de scénario lorsque le code
client des services d’annuaire doit décider de la méthode de résolution dans des situations ambiguës.
Vous pouvez revenir au comportement antérieur à Windows 7 en définissant la valeur de Registre suivante :
Sous-clé : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP
Entrée : UseOldHostResolutionOrder
Type : REG_DWORD
En guise d’approche supplémentaire, vous pouvez désactiver la résolution de noms à l’aide de la diffusion pour
NetBt. Consultez 819108 Paramètres pour réduire le trafic WAN périodique afin de configurer NodeType en
tant que « mode p ».
Configuration des nœuds
Utiliser 0x00000008 pour le nœud hybride ou le nœud h
Utiliser 0x00000004 pour le nœud mixte ou le nœud m
Utiliser 0x00000002 pour les wins point à point ou p-node
Utiliser 0x00000001 pour le nœud de diffusion ou b-node
Types de nœuds de résolution de noms
B-Node (diffusion) : utilise des diffusions pour résoudre les noms. (Non recommandé pour les réseaux plus
volumineux.)
P-Node (pair à pair) : utilise WINS uniquement, aucune diffusion. Pas de serveur WINS, pas de résolution.
M-Node (mixte) : diffuser d’abord, puis WINS. (Non recommandé, car vous souhaitez réduire les diffusions.)
H-Node (hybride) : utilise d’abord WINS, puis diffuse. (Recommandé car il réduit le nombre de diffusions en
essayant d’abord WINS et en recourant à la diffusion uniquement en dernier recours.)
References
fonction Ldap_init
Options de session LDAP (voir LDAP_OPT_AREC_EXCLUSIVE, 0x98)
AdsopenObject, fonction ADSI
ADSI AuthenticationEnum avec la valeur ADS_SERVER_BIND
S.DS AuthenticationTypes, énumération avec la valeur ServerBind
S.DS. P Constructeur LdapDirectoryIdentifier avec l’indicateur fullyQualifiedDnsHostName
Configuration requise et paramètres de sécurité de
session LDAP après l’installation d’ADV190023
Cet article traite des paramètres et des exigences de sécurité de session LDAP après l’installation de l’avis de
sécurité ADV190023.
Résumé
Cet article présente les modifications fonctionnelles fournies par l’avis de sécurité ADV190023. En outre, cet
article décrit les paramètres de sécurité pour chaque type de session LDAP (Lightweight Directory Access
Protocol) et les informations requises pour utiliser les sessions LDAP de manière sécurisée.
ADV190023 traite des paramètres de signature de session LDAP et de vérification de contexte de sécurité client
supplémentaire ( jeton de liaison de canal, CBT). Dans l’implémentation, il existe deux éléments distincts :
LDAPSer verIntegrity et événements enregistrés sur les contrôleurs de domaine
LdapEnforceChannelBinding et événements enregistrés sur les contrôleurs de domaine.
Lorsque vous déterminez le meilleur chemin d’accès pour améliorer la sécurité conformément à ADV190023,
les propriétaires d’applications peuvent avoir besoin d’actions dans les deux domaines. Toutefois, les paramètres
et les conditions requises pour les respecter sont différents. Il est également très possible qu’une solution pour
les deux rubriques se compose d’une seule modification. Par exemple, en passant d’une liaison simple à SASL à
l’aide de Kerberos ou de TLS avec liaison simple.
La nouvelle option de jeton de liaison de canal (CBT) est l’implémentation LDAP TLS du schéma DE PROTECTION
étendue de l’authentification (TUNNEL) décrit dans la norme RFC 5056.
NOTE
Les utilisations de « PREMIER » et « CBT » peuvent être utilisées indifféremment dans ce contexte.
La méthode de traitement de la sécurité de session LDAP dépend du protocole et des options d’authentification
choisies. Il existe plusieurs options de session possibles :
Sessions sur les ports 389 ou 3268 ou sur les ports LDS personnalisés qui n’utilisent pas TLS/SSL pour une
liaison simple : il n’existe aucune sécurité pour ces sessions. Cela est dû au fait que les informations
d’identification sont transmises en texte clair. Par conséquent, il n’existe pas de matériel de clé sécurisé pour
fournir une protection. Ces sessions doivent être désactivées en activant LDAPSer verIntegrity sur
Obligatoire.
Sessions sur les ports 389 ou 3268 ou sur les ports LDS personnalisés qui n’utilisent pas TLS/SSL pour une
liaison SASL (Simple Authentication and Security Layer).
Sessions qui utilisent TLS/SSL à l’aide d’un port prédéterminé (636, 3269 ou d’un port LDS personnalisé) ou
de ports standard (389, 3268 ou un port LDS personnalisé) qui utilisent l’opération étendue STARTTLS.
Sessions LDAP n’utilisant pas TLS/SSL, liaison à l’aide de SASL
Si les sessions LDAP sont signées ou chiffrées à l’aide d’une connexion SASL, les sessions sont sécurisées contre
les attaques de l’homme au milieu (MITM). Cela est dû au fait que vous pouvez obtenir les clés de signature
uniquement si vous connaissez le mot de passe de l’utilisateur. Vous n’avez pas besoin d’informations sur la
protection étendue de l’authentification (CAS).
La méthode SASL choisie peut avoir ses propres vecteurs d’attaque, tels que NTLMv1. Mais la session LDAP elle-
même est sécurisée. Si vous utilisez le chiffrement Kerberos AES 256 bits, c’est aussi bon qu’en 2020. Les
instructions de stratégie suivantes s’appliquent :
Le paramètre LDAPSer verIntegrity=2 est important pour cette option de session, car il applique
l’utilisation de la signature par le client. Lorsque vous chiffrez les sessions, cette exigence est également
remplie.
Le paramètre LdapEnforceChannelBinding n’a aucun effet sur cette option de session.
Sessions LDAP utilisant TLS/SSL et liaison simple pour l’authentification des utilisateurs
Aucune information CBT n’est ajoutée pour ces sessions. La qualité de l’implémentation du client TLS permet de
déterminer si le client peut détecter une attaque MITM (par le biais de la vérification du nom du certificat du
serveur, de la vérification de la liste de contrôle des certificats, et ainsi de suite).
Les instructions de stratégie suivantes s’appliquent :
La condition requise pour LDAPSer verIntegrity est remplie car le canal TLS fournit la signature. Le niveau
de sécurité que le canal TLS fournit dépend de l’implémentation du client TLS.
Sessions LDAP utilisant TLS/SSL, liaison à l’aide d’un certificat pour l’authentification des utilisateurs
Actuellement, aucune information sur la BT n’est ajoutée pour ces sessions. La qualité de l’implémentation du
client TLS permet de déterminer si le client peut détecter une attaque MITM (par le biais de la vérification du
nom du certificat du serveur, de la vérification de la liste de contrôle des certificats, et ainsi de suite).
L’authentification par certificat client est suffisante pour bloquer les attaques MITM, mais elle n’empêche pas les
autres catégories d’attaques qui peuvent être atténuées uniquement par la validation côté client appropriée du
certificat TLS présenté par le serveur.
de sécurité que le canal TLS fournit dépend de l’implémentation du client TLS.
Sessions LDAP utilisant TLS/SSL, liaison avec SASL pour l’authentification des utilisateurs
Dans ce scénario, TLS fournit la sécurité de session pour le chiffrement et les clés de chiffrement sont basées sur
le certificat de serveur. Plus précisément pour l’authentification SASL qui utilise NTLM, les données
d’authentification NTLM peuvent avoir été relayées à partir de la session qui a été tenue par l’attaquant MITM.
Dans ce cas, il n’existe aucune preuve que le client dispose d’un hachage de mot de passe valide. Les
informations CBT sont protégées contre la falsification via la signature ou le chiffrement (selon le protocole
d’authentification) à l’aide d’une clé de session qui peut être obtenue uniquement en connaissant les
informations d’identification de l’utilisateur ou du serveur. L’attaquant MITM n’aurait pas ce hachage de mot de
passe s’il interceptait une authentification NTLM.
Le paramètre LdapEnforceChannelBinding est utilisé pour cette option de session. Lorsque vous
définissez cette valeur sur 2, le serveur LDAP requiert des informations sur la BT (équivalentes à LASPA) et
doit réussir la vérification.
de sécurité qu’il fournit dépend de l’implémentation du client TLS et de la nécessité ou non de CBT.
Références
Protection étendue de l’authentification
Contrôler la protection étendue de l’authentification à l’aide de la stratégie de sécurité
Résoudre les problèmes de connexion LDAP sur SSL
Cet article décrit les étapes à suivre pour résoudre les problèmes de connexion LDAP sur SSL (LDAPS).
Étape 1 : Vérifier le certificat d’authentification du serveur

Assurez-vous que le certificat d’authentification serveur que vous utilisez répond aux exigences suivantes :
Le nom de domaine complet Active Directory du contrôleur de domaine apparaît dans l’un des
emplacements suivants :
Nom commun (CN) dans le champ Objet.
Extension SAN (Subject Alternative Name) dans l’entrée DNS.
L’extension d’utilisation améliorée de la clé inclut l’identificateur d’objet Authentification serveur
(1.3.6.1.5.5.7.3.1).
La clé privée associée est disponible sur le contrôleur de domaine. Pour vérifier que la clé est disponible,
utilisez la certutil -verifykeys commande.
La chaîne de certificats est valide sur l’ordinateur client. Pour déterminer si le certificat est valide, suivez
1. Sur le contrôleur de domaine, utilisez le logiciel en ligne Certificats pour exporter le certificat SSL
vers un fichier nommé Serverssl.cer.
2. Copiez le fichier Serverssl.cer sur l’ordinateur client.
3. Sur l’ordinateur client, ouvrez une fenêtre d’invite de commandes.
4. À l’invite de commandes, tapez la commande suivante pour envoyer la sortie de la commande
vers un fichier nommé Output.txt:
certutil -v -urlfetch -verify serverssl.cer > output.txt
NOTE
Pour suivre cette étape, vous devez avoir installé l’outil en ligne de commande Certutil.
5. Ouvrez le Output.txt, puis recherchez des erreurs.
Étape 2 : Vérifier le certificat d’authentification client

Dans certains cas, LDAPS utilise un certificat d’authentification client s’il est disponible sur l’ordinateur client. Si
un tel certificat est disponible, assurez-vous que le certificat répond aux exigences suivantes :
L’extension d’utilisation améliorée de la clé inclut l’identificateur d’objet d’authentification client
(1.3.6.1.5.5.7.3.2).
La clé privée associée est disponible sur l’ordinateur client. Pour vérifier que la clé est disponible, utilisez
la certutil -verifykeys commande.
La chaîne de certificats est valide sur le contrôleur de domaine. Pour déterminer si le certificat est valide,
1. Sur l’ordinateur client, utilisez le logiciel en snap-in Certificats pour exporter le certificat SSL vers
un fichier nommé Clientssl.cer.
2. Copiez le fichier Clientssl.cer sur le serveur.
3. Sur le serveur, ouvrez une fenêtre d’invite de commandes.
4. À l’invite de commandes, tapez la commande suivante pour envoyer la sortie de la commande
vers un fichier nommé Outputclient.txt:
certutil -v -urlfetch -verify serverssl.cer > outputclient.txt
5. Ouvrez le Outputclient.txt, puis recherchez des erreurs.
Étape 3 : Recherche de plusieurs certificats SSL

Déterminez si plusieurs certificats SSL répondent aux exigences décrites à l’étape 1. Schannel (le fournisseur
Microsoft SSL) sélectionne le premier certificat valide trouvé par Schannel dans le magasin d’ordinateurs locaux.
Si plusieurs certificats valides sont disponibles dans le magasin d’ordinateurs locaux, Schannel risque de ne pas
sélectionner le certificat correct. Un conflit avec un certificat d’autorité de certification peut se produire si
l’autorité de certification est installée sur un contrôleur de domaine que vous essayez d’accéder via LDAPS.
Étape 4 : Vérifier la connexion LDAPS sur le serveur

Utilisez lLdp.exe sur le contrôleur de domaine pour essayer de vous connecter au serveur à l’aide du port 636. Si
vous ne pouvez pas vous connecter au serveur à l’aide du port 636, consultez les erreurs Ldp.exe générées.
Consultez également les journaux de l’Observateur d’événements pour rechercher des erreurs. Pour plus
d’informations sur l’utilisation de Ldp.exe pour vous connecter au port 636, voir Comment activer LDAP sur
SSLavec une autorité de certification tierce.
Étape 5 : Activer la journalisation Schannel

Activez la journalisation des événements Schannel sur le serveur et sur l’ordinateur client. Pour plus
d’informations sur la façon d’activer la journalisation des événements Schannel, voir Comment activer la
journalisation des événements Schanneldans Windows et Windows Server .
NOTE
Si vous devez effectuer le débogage SSL sur un ordinateur exécutant Microsoft Windows NT 4.0, vous devez utiliser un
fichier Schannel.dll pour le Service Pack Windows NT 4.0 installé, puis connecter un déboguer à l’ordinateur. La
journalisation Schannel envoie uniquement la sortie à un débogger dans Windows NT 4.0.
Réponse des contrôleurs de domaine au ping LDAP
sur le port UDP 138
Cet article explique comment faire en sorte que les contrôleurs de domaine répondent à LDAP Ping.
Symptômes
Le fichier LMHOSTS sur Windows server ne contient pas de nom d’hôte client.
Le serveur WINS n’est pas configuré sur Windows Server, ou le serveur WINS ne résout pas le nom d’hôte
du client.
Windows Le serveur et le client se font dans un autre segment réseau.
Dans ce scénario, Windows Server 2008 ou une ultérieure ne répond pas au ping LDAP (port UDP 138) de
l’ordinateur client.
Dans Windows Server 2003 ou une ancienne, les systèmes d’exploitation Windows Server répondent au ping
LDAP sur le port UDP 138 à partir du client, mais le comportement a changé depuis Windows Server 2008.
Pour configurer Windows Server 2008 ou une ultérieure pour répondre à LDAP Ping, configurez l’un des
paramètres suivants.
(A) Ajouter LMHOSTS
1. Déplacer vers le dossier %windir%\system32\drivers\etc.
2. Ajoutez l’adresse IP et le nom d’hôte du client au fichier LMHOSTS.
(B) Ajouter un serveur WINS
Configurez TCP/IP pour utiliser le serveur WINS qui peut résoudre le nom d’hôte client en Windows Server.
Configurer TCP/IP pour utiliser WINS
(C) Placez Windows serveurs et ordinateurs clients dans le même segment.
Windows Le serveur résout le nom d’hôte du client à l’aide de la diffusion NetBIOS si Windows serveur et les
clients sont sur le même sous-réseau.
Remarque : le DNS est la méthode principale de résolution des requêtes de noms dans Active Directory à partir
de Windows Server 2000 et incluant Windows Server 2003, Windows Server 2008, Windows Server 2012,
Windows Server 2012 R2, Windows Server 2016 et bien plus encore.
Références
Pour plus d’informations sur DCLOCATOR, voir :
Localisateur de contrôleur de domaine
Processus d’emplacement du contrôleur de domaine
Localisateur de domaine dans une confiance de forêt
Fonctionnement de la prise en charge DNS pour Active Directory
Utilisation de la fonctionnalité dbdump en ligne
Cet article explique comment utiliser la fonctionnalité de dbdump en ligne d’Active Directory.
Résumé
Vous pouvez utiliser la fonctionnalité dbdump en ligne dans Ldp.exe pour afficher les valeurs stockées dans la
base de données pendant l’exécution d’un contrôleur de domaine. Vous déclenchez la fonctionnalité dbdump en
ligne en modifiant l’attribut dumpDatabase sur le rootDSA.
Les valeurs que vous spécifiez pour cet attribut sont les attributs autres que les attributs par défaut que vous
souhaitez vidage. Les valeurs que vous spécifiez sont le nom de cet attribut. La fonctionnalité dumpDatabase
vérifie d’abord que vous disposez de droits suffisants pour la base de données. Il vide ensuite la base de
données dans le fichier Ntds.dmp. Le fichier Ntds.dmp se trouve dans le même dossier que le fichier de base de
données (.dit). Les attributs par défaut sont :
DNT
PDNT
OBJ
RDNTyp
CNT
ABCNT
DelTime
NCDNT
ABVis
Exemple d’utilisation : examiner un problème de SPN avec des

attributs CNF ou DEL supprimés en conflit
Pour créer le fichier Ntds.dmp, suivez les étapes suivantes :
1. Démarrez Ldp.exe sur le contrôleur de domaine qui journalisation de l’événement NTDS 1645.
2. Connecter localement, puis lier en tant qu’Enterprise administrateur.
3. Cliquez sur Modifier dans le menu Parcourir.
4. Modifier pour l’attribut : dumpdatabase.
5. Edit for Values : name ncname objectclass objectguid instancetype. Vous devez laisser un espace entre les
attributs.
6. Cliquez sur Entrée. La zone Liste des entrées contient l’entrée suivante :
[Add]dumpdatabase: name ncname objectclass objectguid instancetype
7. Cliquez sur les options Étendue et Exécuter.
8. Le fichier %systemroot%\NTDS\Ntds.dmp est créé ou vous recevez un message d’erreur dans Ldp.exe
que vous devez examiner.
Vous pouvez également déclencher ce déclenchement à l’aide d’un fichier d’importation LDIFDE dump-db.txt
comme :
Dn:
Changetype: modify
Ajouter : dumpdatabase
Dumpdatabase: name ncname objectclass objectguid instancetype
-
Pour importer le fichier avec LDIFDE, utilisez une ligne de commande comme
ldifde /s \<targetserver> /i /f dump-db.txt .
Utiliser la sortie
Le fichier Ntds.dmp est un fichier texte. Recherchez le GUID en conflit ou supprimé qui a été signalé dans
l’événement 1645 pour voir l’insériorisation de la référence interne.
Exemple de fichier de vidage

L’exemple suivant montre que l’objet CROSSREF pour domaine PDT pointe vers un objet erroné qui a déjà été
supprimé :
3953 2326 true 3 1 0 - 1163 - 4

3947 196619 56.6E.52.8A.2E.B4.00.43.BE.B1.B3.57.91.AD.F5.BE PDT
...
3947 1161 false 1376281 2 0 2001-08-04 11:02.47 - -
- - - 9E.4C.AB.36.81.65.2B.4F.A0.31.59.D5.C2.74.68.F2 pdt
DEL:36ab4c9e-6581-4f2b-a031-59d5c27468f2
...
3958 1161 false 1376281 3 0 2001-08-04 23:02.47 - -
- - - 85.0B.3B.A1.EC.68.37.46.9E.D0.FF.F6.66.BA.FB.84 pdt
La référence interne pointe vers 3947, bien qu’elle pointe vers le nouvel objet 3958 pour dc=pdt,dc=net.
Vous pouvez résoudre ce problème à l’aide de l’outil de vérification sémantique de la dernière version
Ntdsutil.exe'outil.
Afficher et définir la stratégie LDAP dans Active
Directory à l’aide de Ntdsutil.exe
Cet article explique comment gérer les stratégies LDAP (Lightweight Directory Access Protocol) à l’aide de
lNtdsutil.exe de gestion.
Résumé
Pour vous assurer que les contrôleurs de domaine peuvent prendre en charge les garanties au niveau du
service, vous devez spécifier des limites opérationnelles pour de nombreuses opérations LDAP. Ces limites
empêchent des opérations spécifiques d’affecter négativement les performances du serveur. Ils rendent
également le serveur plus résistant à certains types d’attaques.
Les stratégies LDAP sont implémentées à l’aide d’objets de la queryPolicy classe. Les objets de stratégie de
requête peuvent être créés dans le conteneur Stratégies de requête, qui est un enfant du conteneur du service
d’annuaire dans le contexte d’attribution de noms de configuration. Par exemple, cn=Query-
Policies,cn=Directory Service,cn=Windows NT,cn=Services configuration naming context .
Limites d’administration LDAP

Les limites d’administration LDAP sont les :
InitRecvTimeout : cette valeur définit la durée maximale en secondes pendant qu’un contrôleur de
domaine attend que le client envoie la première demande une fois que le contrôleur de domaine reçoit
une nouvelle connexion. Si le client n’envoie pas la première demande dans ce laps de temps, le serveur
déconnecte le client.
Valeur par défaut : 120 secondes
MaxActiveQueries : nombre maximal d’opérations de recherche LDAP simultanées autorisées à s’exécuter
en même temps sur un contrôleur de domaine. Lorsque cette limite est atteinte, le serveur LDAP renvoie
une erreur de occupé.
Valeur par défaut : 20
NOTE
Ce contrôle a une interaction incorrecte avec la valeur MaxPoolThreads. MaxPoolThreads est un contrôle par
processeur, tandis que MaxActiveQueries définit un nombre absolu. À partir Windows Server 2003,
MaxActiveQueries n’est plus appliqué. En outre, MaxActiveQueries n’apparaît pas dans la version Windows Server
2003 de NTDSUTIL.

MaxConnections : nombre maximal de connexions LDAP simultanées qu’un contrôleur de domaine
acceptera. Si une connexion entre lorsque le contrôleur de domaine atteint cette limite, le contrôleur de
domaine abandonne une autre connexion.
MaxConnIdleTime : durée maximale en secondes pendant qui le client peut être inactif avant que le
serveur LDAP ne ferme la connexion. Si une connexion est inactive pendant plus de ce temps, le serveur
LDAP renvoie une notification de déconnexion LDAP.
MaxDatagramRecv : taille maximale d’une demande de datagramme traitée par un contrôleur de
domaine. Les demandes dont la taille est supérieure à la valeur de MaxDatagramRecv sont ignorées.
Valeur par défaut : 4 096 octets
MaxNotificationPerConnection : nombre maximal de demandes de notification en suspens autorisées sur
une seule connexion. Lorsque cette limite est atteinte, le serveur renvoie une erreur occupé à toutes les
nouvelles recherches de notification effectuées sur cette connexion.
MaxPageSize : cette valeur contrôle le nombre maximal d’objets renvoyés dans un seul résultat de
recherche, indépendamment de la taille de chaque objet renvoyé. Pour effectuer une recherche dans
laquelle le résultat peut dépasser ce nombre d’objets, le client doit spécifier le contrôle de recherche pagé.
Il s’agit de grouper les résultats renvoyés dans des groupes qui ne sont pas supérieurs à la valeur
MaxPageSize. Pour résumer, MaxPageSize contrôle le nombre d’objets renvoyés dans un seul résultat de
recherche.
Valeur par défaut : 1 000
MaxPoolThreads : nombre maximal de threads par processeur qu’un contrôleur de domaine dédie à
l’écoute des entrées ou sorties réseau (E/S). Cette valeur détermine également le nombre maximal de
threads par processeur qui peuvent fonctionner sur des demandes LDAP en même temps.
Valeur par défaut : 4 threads par processeur
MaxResultSetSize : entre les recherches individuelles qui font une recherche de résultats pagyée, le
contrôleur de domaine peut stocker des données intermédiaires pour le client. Le contrôleur de domaine
stocke ces données pour accélérer la partie suivante de la recherche de résultats pagyée. La valeur
MaxResultSize contrôle la quantité totale de données que le contrôleur de domaine stocke pour ce type
de recherche. Lorsque cette limite est atteinte, le contrôleur de domaine rejette le plus ancien de ces
résultats intermédiaires pour faire de la place pour stocker de nouveaux résultats intermédiaires.
Valeur par défaut : 262 144 octets
MaxQueryDuration : durée maximale en secondes qu’un contrôleur de domaine consacre à une
recherche unique. Lorsque cette limite est atteinte, le contrôleur de domaine renvoie une erreur «
timeLimitExceeded ». Les recherches qui nécessitent plus de temps doivent spécifier le contrôle des
résultats pagés.
MaxTempTableSize : pendant le traitement d’une requête, la table de base de données temporaire peut
tenter de trier et de sélectionner des résultats dblayer intermédiaires. La limite MaxTempTableSize
contrôle la taille de cette table de base de données temporaire. Si la table de base de données temporaire
contient plus d’objets que la valeur de MaxTempTableSize, l’opération effectue une recherche beaucoup
moins efficace de l’intégralité de la base de données DS et de tous les objets de la base de données
dblayer DS.
Valeur par défaut : 10 000 enregistrements

MaxValRange : cette valeur contrôle le nombre de valeurs renvoyées pour un attribut d’un objet,
indépendamment du nombre d’attributs de cet objet ou du nombre d’objets qui se sont produits dans le
résultat de la recherche. Dans Windows 2000, ce contrôle est codé en dur à 1 000. Si un attribut a plus de
valeurs que le nombre spécifié par la valeur MaxValRange, vous devez utiliser des contrôles de plage de
valeurs dans LDAP pour récupérer des valeurs qui dépassent la valeur MaxValRange. MaxValueRange
contrôle le nombre de valeurs renvoyées sur un seul attribut sur un seul objet.
Valeur minimale : 30
Valeur par défaut : 1 500
Démarrer Ntdsutil.exe
Ntdsutil.exe se trouve dans le dossier Des outils de support sur le CD-ROM d Windows d’installation. Par défaut,
Ntdsutil.exe est installé dans le dossier System32.
2. Dans la zone de texte Ouvrir, tapez ntdsutil, puis appuyez sur Entrée. Pour afficher l’aide à tout moment,
tapez ? à l’invite de commandes.
Afficher les paramètres de stratégie actuels

1. À l’invite Ntdsutil.exe commande, LDAP policies tapez, puis appuyez sur Entrée.
2. À l’invite de commandes de stratégie LDAP, connections tapez, puis appuyez sur Entrée.
3. À l’invite de commandes de connexion au serveur, connect to server <DNS name of server> tapez, puis
appuyez sur Entrée. Vous souhaitez vous connecter au serveur que vous travaillez actuellement.
4. À l’invite de commandes de connexion au serveur, tapez, puis appuyez sur Entrée pour **q** revenir au
menu précédent.
5. À l’invite de commandes de stratégie LDAP, Show Values tapez, puis appuyez sur Entrée.
Un affichage des stratégies telles qu’elles existent apparaît.
Modifier les paramètres de stratégie

1. À l’invite Ntdsutil.exe commande, LDAP policies tapez, puis appuyez sur Entrée.
2. À l’invite de commandes de stratégie LDAP, Set <setting> to <variable> tapez, puis appuyez sur Entrée.
Par exemple, tapez Set MaxPoolThreads sur 8.
Ce paramètre change si vous ajoutez un autre processeur à votre serveur.
3. Vous pouvez utiliser la Show Values commande pour vérifier vos modifications.
Pour enregistrer les modifications, utilisez Valider les modifications.
4. Lorsque vous avez terminé, q tapez, puis appuyez sur Entrée.
5. Pour quitter Ntdsutil.exe, à l’invite de commandes, q tapez, puis appuyez sur Entrée.
NOTE
Cette procédure affiche uniquement les paramètres de stratégie de domaine par défaut. Si vous appliquez votre propre
paramètre de stratégie, vous ne pouvez pas le voir.
Conditions requises pour le redémarrage

Si vous modifiez les valeurs de la stratégie de requête qu’un contrôleur de domaine utilise actuellement, ces
modifications prennent effet sans redémarrage. Toutefois, si une nouvelle stratégie de requête est créée, un
redémarrage est nécessaire pour que la nouvelle stratégie de requête prenne effet.
Considérations pour la modification des valeurs de requête

Pour maintenir la résilience des serveurs de domaine, nous vous déconseillons d’augmenter la valeur du délai
d’accès de 120 secondes. Il est préférable de créer des requêtes plus efficaces. Pour plus d’informations sur la
création de requêtes efficaces, voir Création d’applications Microsoft Active Directory-Enabled plus efficaces.
Toutefois, si la modification de la requête n’est pas une option, augmentez la valeur de délai d’délai uniquement
sur un contrôleur de domaine ou sur un seul site. Pour obtenir des instructions, consultez la section suivante. Si
le paramètre est appliqué à un contrôleur de domaine, réduisez la priorité LDAP DNS sur le contrôleur de
domaine, afin que les clients utilisent moins probablement le serveur pour l’authentification. Sur le contrôleur
de domaine dont la priorité augmente, utilisez le paramètre de Registre suivant pour définir LdapSrvPriority :
Dans le menu Edition, sélectionnez Ajouter une valeur, puis ajoutez la valeur de Registre suivante :
Nom d’entrée : LdapSrvPriority
Valeur : définissez la valeur sur la valeur de la priorité que vous souhaitez.
Pour plus d’informations, voir Comment optimiser l’emplacement d’uncontrôleur de domaine ou d’un catalogue
global qui réside en dehors du site d’un client.
Instructions de configuration par contrôleur de domaine ou stratégie

de site
1. Créez une stratégie de requête sous CN=Query-Policies,CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration, forest root .
2. Définissez le contrôleur de domaine ou le site pour qu’il pointe vers la nouvelle stratégie en entrant le
nom de la nouvelle stratégie dans l’attribut Quer y-Policy-Object. L’emplacement de l’attribut est le
suivant :
L’emplacement du contrôleur de domaine est CN=NTDS Paramètres, CN=
DomainControllerName , CN=Servers,CN= site name ,CN=Sites,CN=Configuration, forest
root .
L’emplacement du site est CN=NTDS Site Paramètres,CN= nom du site
,CN=Sites,CN=Configuration, racine de la forêt .
Exemple de script
Vous pouvez utiliser le texte suivant pour créer un fichier Ldifde. Vous pouvez importer ce fichier pour créer la
stratégie avec une valeur de délai d’accès de 10 minutes. Copiez ce texte dans Ldappaboy.ldf, puis exécutez la
commande suivante, où la racine de la forêt est le nom de la racine de votre forêt. Laissez DC=X tel qu’il est. Il
s’agit d’une constante qui sera remplacée par le nom racine de la forêt lorsque le script s’exécute. La constante X
n’indique pas un nom de contrôleur de domaine.
ldifde -i -f ldappolicy.ldf -v -c DC=X DC= forest root
Démarrer le script Ldifde

dn: CN=Extended Timeout,CN=Query-Policies,CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=X
changetype: add
instanceType: 4
lDAPAdminLimits: MaxReceiveBuffer=10485760
lDAPAdminLimits: MaxDatagramRecv=1024
lDAPAdminLimits: MaxPoolThreads=4
lDAPAdminLimits: MaxResultSetSize=262144
lDAPAdminLimits: MaxTempTableSize=10000
lDAPAdminLimits: MaxQueryDuration=300
lDAPAdminLimits: MaxPageSize=1000
lDAPAdminLimits: MaxNotificationPerConn=5
lDAPAdminLimits: MaxActiveQueries=20
lDAPAdminLimits: MaxConnIdleTime=900
lDAPAdminLimits: InitRecvTimeout=120
lDAPAdminLimits: MaxConnections=5000
objectClass: queryPolicy
showInAdvancedViewOnly: TRUE
Après avoir importé le fichier, vous pouvez modifier les valeurs de requête à l’aide d’Adsiedit.msc ou Ldp.exe. Le
paramètre MaxQueryDuration dans ce script est de 5 minutes.
Pour lier la stratégie à un dc, utilisez un fichier d’importation LDIF comme ceci :
dn: CN=NTDS
Settings,CN=DC1,CN=Servers,CN=site1,CN=Sites,CN=Configuration, DC=X
changetype: modify
add: queryPolicyobject
queryPolicyobject: CN=Extended Timeout,CN=Query-Policies,CN=Directory Service,CN=Windows
Importez-le à l’aide de la commande suivante :
ldifde -i -f link-policy-dc.ldf -v -c DC=X DC= **forest root**
Pour un site, le fichier d’importation LDIF contiendrait :
dn: CN=NTDS Site Settings,CN=site1,CN=Sites,CN=Configuration, DC=X

changetype: modify
add: queryPolicyobject
queryPolicyobject: CN=Extended Timeout,CN=Query-Policies,CN=Directory Service,CN=Windows
NOTE
Ntdsutil.exe affiche uniquement la valeur dans la stratégie de requête par défaut. Si des stratégies personnalisées sont
définies, elles ne sont pas affichées par les Ntdsutil.exe.
Comment trouver la version actuelle du schéma
Cet article explique comment rechercher la version actuelle du schéma. L’auteur original de l’article était Yuval
Sinay, Microsoft MVP.
Comment trouver la version actuelle du schéma Active Directory

Pour trouver la version actuelle du schéma Active Directory, vous pouvez utiliser l’une des méthodes suivantes :
NOTE
Le domaine racine interne que nous utilisons dans cette démonstration est : contoso.local.
Méthode 1
1. Utilisez ADSIEdit.msc ou LDP.exe pour accéder à :
CN=Schema,CN=Configuration,DC=contoso,DC=local .
2. Passez en revue l’attribut objectVersion .
Méthode 2
Utilisez la ligne de DSQuery commande. Exécutez la commande suivante :
dsquery * "cn=schema,cn=configuration,dc=contoso,dc=local" -scope base -attr objectVersion
Méthode 3
Utilisez l’applet Get-ItemProperty de commande PowerShell. Exécutez la commande suivante :
Get-ItemProperty 'AD:\CN=Schema,CN=Configuration,DC=contoso,DC=local' -Name objectVersion
Attribut « objectVersion » au système d’exploitation

Les informations suivantes fournissent un mappage entre la valeur de l’attribut objectVersion et la
commutabilité du schéma Active Directory :
VERSIO N SY ST ÈM E D’EXP LO ITAT IO N
13 Windows 2000 Server
30 Windows Server 2003 RTM, Windows Service Pack 2003 1,

Windows 2003 Service Pack 2
31 Windows Server 2003 R2
44 Windows Server 2008 RTM

VERSIO N SY ST ÈM E D’EXP LO ITAT IO N
56 Windows Server 2012
Comment trouver la version actuelle du schéma Exchange

Pour trouver la version actuelle du schéma Exchange, vous pouvez utiliser l’une des méthodes suivantes :
NOTE
Le domaine racine interne que nous utilisons dans cette démonstration est : contoso.local.
Méthode 1
1. Utiliser les outils ADSIEdit.msc ou LDP.exe pour accéder à
CN=ms-Exch-Schema-Version-Pt, CN=Schema,CN=Configuration,DC=contoso,DC=local
2. Passez en revue l’attribut « rangeUpper » actuel.
Méthode 2
Ligne de commande Ues DSQuer y :
dsquery * "CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=contoso,dc=local" -scope base -attr

rangeUpper
Certains mappages d’attributs « rangeUpper »

Les informations suivantes fournissent un mappage entre la valeur de l’attribut rangeUpper et la
commutabilité du schéma Exchange :
VERSIO N D'EXC H A N GE RA N GEUP P ER
Exchange Server 2019 CU10, CU11 17003
Exchange Server 2019 CU2, CU3, CU4, CU5, CU6, CU7 17001
Exchange Server 2019 RTM, CU1 17000
Exchange Server 2019 Preview 15332
Exchange Server 2016 CU21 15334

VERSIO N D'EXC H A N GE RA N GEUP P ER
Exchange Server 2016 CU7, CU8, CU9, CU10, CU11, CU12, 15332
CU13, CU14, CU15, CU16, CU17
Exchange Server 2016 CU3, CU4, CU5 15326
Exchange Server 2016 RTM, préversion 15317
Exchange Server 2013 CU7, CU8, CU9, CU10, CU11, CU12, 15312
CU13, CU14, CU15, CU16, CU17, CU18, CU19, CU20,
CU21, CU22, CU23 with (KB5004778)
Exchange Server 2013 SP1 15292
Exchange Server 2013 RTM 15137

Retards lorsque les membres du domaine doivent
communiquer avec des DCS sur des domaines
distants
Cet article fournit de l’aide pour résoudre les retards qui se produisent lorsque les membres du domaine
doivent communiquer avec des DCS sur des domaines distants.
Symptômes
Supposons que vous disposez d’un environnement Active Directory qui possède une ou plusieurs forêts et que
chaque forêt possède un ou plusieurs arbre de domaine. Dans cet environnement, une arborescence de
domaine est une racine de nom DNS indépendante de la racine de la forêt.
Vous avez des ordinateurs membres dans tous les domaines de toutes les forêts. Vous avez également une
stratégie de sécurité réseau qui limite la communication de vos ordinateurs aux serveurs et homologues requis
pour la fonction professionnelle de vos ordinateurs, ainsi qu’aux utilisateurs qui travaillent avec cette fonction
professionnelle.
Dans ce scénario, vous remarquerez que les membres du domaine accèdent aux contrôleurs de domaine dans
des domaines autres que le domaine dont ils sont membres. Ils peuvent accéder à des serveurs qui sont
différents du serveur sur qui les utilisateurs se connectent. Cette communication peut être limitée par les règles
de pare-feu que vous avez définies.
Cette activité provoque de fréquents retards et erreurs lorsque l’ordinateur membre tente sans succès d’accéder
aux ports serveur des autres DCS de domaine.
Lorsque ce problème se produit, vous recevez un message d’erreur basé sur le protocole utilisé, comme suit :
RPC : code d’erreur 1722 (RPC_S_SERVER_UNAVAILABLE)
LDAP : code d’erreur 85 (LDAP_TIMEOUT)
WinSock : code d’erreur 10060 (WSAETIMEDOUT)
Analyse et cause
En règle générale, vous vous attendez à ce que l’ordinateur et les utilisateurs utilisent principalement des DCS du
même domaine dont ils sont membres. Ils peuvent également se connecter aux catalogues globaux pour les
recherches à l’échelle de la forêt dans leur propre forêt ou dans des forêts distantes.
Toutefois, les membres du domaine peuvent parfois atteindre en dehors de leur propre domaine. Ils peuvent le
faire en fonction de leur configuration. Ils peuvent également le faire après avoir découvert la structure globale
de la forêt, puis envoyer des demandes à tous les domaines qu’ils ont découverts.
Exemples d’exigences de communication de ce type :
La configuration peut être des paramètres de stratégie de groupe liés à l’étendue des paramètres de
stratégie pour les membres du domaine. Ou bien, il peut s’agit de paramètres de stratégie sur le site
Active Directory où se trouve l’ordinateur.
Il peut y avoir des applications qui souhaitent rechercher ou synchroniser des objets à partir de tous les
domaines qu’ils trouvent. Par exemple, la découverte SharePoint topologie.
Il existe également le groupe d’applications qui recherchent un objet racine de domaine à l’aide de recherches
LDAP et qui autorisent et reçoivent des références de continuation. Cela signifie qu’ils redirigent les références
vers tous les NCs enfants (partitions d’application et domaines enfants). Par conséquent, ils nécessitent l’accès
aux DCS de domaine enfants.
Les retards que vous pouvez connaître dépendent du nombre de domaines, des DCS référencés et du nombre
de tentatives réalisées par une application. Le délai peut prendre plusieurs minutes. Certaines applications ont
également un délai d’erreur avant que tous les DCS et domaines ne retournent des erreurs suffisamment
fréquemment. Dans votre analyse, vous pouvez voir la requête LDAP d’origine marquée comme réussie, car elle
a reçu des résultats du domaine dans lequel la requête a été démarrée. Toutefois, la requête est toujours
retardée car elle attend que les références soient terminées.
Recommandations
Microsoft ne comprend pas de documentation sur la façon de déterminer les DCS d’un domaine dans une forêt
dans l’étendue de l’entreprise qui sont utilisés en fonction d’une configuration particulière. Il n’existe pas non
plus de règles pour contrôler les PC accessibles. Cela s’applique Windows toutes les applications Microsoft.
Vous devez vous attendre à ce que n’importe quel membre de domaine atteigne tous les DCS de toutes les
forêts. Si vous souhaitez limiter les membres du domaine, vous devez utiliser une approche d’essai et d’erreur. Si
vous constatez que des retards se produisent en raison du contact de DCS supplémentaires, vous devez adopter
des règles de pare-feu qui autorisent l’accès à ces DCS.
Si vous ne savez pas quels ports sont disponibles ou bloqués par le pare-feu, utilisez l’outil PortQry pour tester
les paramètres. Pour plus d’informations, voir Nouvelles fonctionnalités dans PortQry version 2.0.
Références
Vue d’ensemble d’ADConnection
Références LDAP
Gestion et suivi des références
Vue d’ensemble du service et exigences relatives aux ports réseau pour Windows
Erreur lorsque vous exécutez l’Assistant Installation
d’Active Directory : la version du schéma Active
Directory de la forêt source n’est pas compatible
avec la version d’Active Directory sur cet ordinateur
Cet article fournit une solution à une erreur qui se produit lorsque vous essayez d’exécuter l’Assistant Installation
d’Active Directory.
S’applique à : Window Server 2003
Symptômes
Lorsque vous essayez d’exécuter l’Assistant Installation d’Active Directory sur un serveur Microsoft Windows
Server 2003 R2, l’Assistant ne se termine pas et vous pouvez recevoir le message d’erreur suivant :
L’Assistant Installation d’Active Directory ne peut pas continuer, car la forêt n’est pas prête à installer
Windows Server 2003. Utilisez l’outil en ligne de commande Adprep pour préparer la forêt et le domaine.
Pour plus d’informations sur l’utilisation d’Adprep, voir l’aide d’Active Directory.
La version du schéma Active Directory de la forêt source n’est pas compatible avec la version d’Active
Directory sur cet ordinateur.
Cause
Ce problème peut se produire lorsque Active Directory n’a pas été mis à jour avec les extensions de schéma
Résolution
Pour résoudre ce problème, exécutez la commande à partir du adprep.exe /forestprep disque d’installation
Windows Server 2003 R2 2 sur le régule de schéma. Pour ce faire, insérez le Windows d’installation server 2003
R2 2, puis tapez la commande : <Drive>:\CMPNENTS\R2\ADPREP\adprep.exe /forestprep .
La version correcte de l’outil ADPrep.exe pour Windows Server 2003 R2 est 5.2.3790.2075.
Vous pouvez vérifier le niveau de prise en charge du système d’exploitation du schéma en regardant la valeur de
la sous-clé de Registre version du schéma sur un contrôleur de domaine. Cette sous-clé se trouve à
l’emplacement suivant :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Vous pouvez également vérifier le niveau de prise en charge du système d’exploitation du schéma à l’aide de
l’utilitaire Adsiedit.exe ou de l’utilitaire Ldp.exe pour afficher l’attribut objectVersion dans les propriétés de la
partition cn=schema,cn=configuration,dc=. <domain> La valeur de la sous-clé de Registre version du schéma
et de l’attribut objectVersion est en décimal.
Valeurs Schema Version ObjectVersion et niveau de prise en charge du système d’exploitation correspondant :
13=Microsoft Windows 2000
30=Version d’origine de Microsoft Windows Server 2003 et Microsoft Windows Server 2003 Service Pack 1
(SP1)
31=Microsoft Windows Server 2003 R2
Windows Disques d’installation Server 2003 R2
Windows Server 2003 R2 est livré sur deux disques d’installation. Le disque d’installation 1 contient une version
de flux Windows Server 2003 avec Service Pack 1 (SP1). Le disque d’installation 2 contient les Windows Server
2003 R2. Si l’ordinateur Windows Server 2003 SP1 est installé, vous n’avez peut-être qu’à exécuter le disque
d’installation 2 pour mettre à niveau vers Windows Server 2003 R2.
Le disque d’installation 2 est spécifique à l’édition Windows Server 2003. Par exemple, vous devez utiliser un
disque d’installation Windows Server 2003 R2, Édition Standard pour mettre à niveau un ordinateur Windows
Server 2003 Édition Standard. Le disque d’installation 2 contient des fichiers d’installation pour la version x86 et
la version x64 de Windows Server 2003 R2.
LAdsiedit.exe et l’utilitaire Ldp.exe sont inclus dans Windows d’assistance de Server 2003 R2. Pour installer les
outils de support, Suptools.msi le dossier \Support\Tools sur le disque d’installation 1.
Étapes pour désactiver TLS 1.0 et 1.1 sur les serveurs
MBAM et forcer l’utilisation de TLS 1.2
Cet article décrit les étapes à suivre pour désactiver TLS 1.0 et 1.1 sur les serveurs MBAM (Microsoft BitLocker
Administration and Monitoring) et forcer l’utilisation de TLS 1.2.
S’applique à : Windows 10 : toutes les éditions, Windows Server 2012 R2
Symptômes
Microsoft prévoit de désactiver les anciens protocoles TLS, en vue de la désactivation de TLS 1.0 et TLS 1.1 par
défaut. Voir plan de modification : TLS 1.0 et TLS 1.1seront bientôt désactivés par défaut.
Pour les clients d’entreprise, il peut être nécessaire de désactiver TLS 1.0 et 1.1 dans leur environnement pour
l’infrastructure MBAM (Microsoft BitLocker Administration and Monitoring).
Résolution
Suivez ces étapes pour désactiver TLS 1.0 et 1.1 sur les serveurs MBAM et forcer l’utilisation de TLS 1.2.
1. Téléchargez et installez la dernière version disponible de Microsoft .NET Framework sur tous les serveurs
MBAM qui sont :
Serveurs Web exécutant des rôles IIS
SQL Serveurs exécutant le moteur SQL Server base de données et les serveurs SQL Server Reporting
Services
Reportez-vous à : Programme d’installation hors .NET Framework Microsoft 4.8 pour Windows
2. Exécutez les scripts PowerShell ci-dessous. Ils sont utilisés pour désactiver TLS 1.0 et 1.1 et forcer
l’utilisation uniquement de TLS 1.2.
3. Redémarrez les serveurs, puis testez les applications web MBAM. Confirmez que les clients MBAM
peuvent communiquer avec le serveur pour les informations de récupération.
<Tighten_DotNet.PS1>
#Tighten up the .NET Framework

$NetRegistryPath = "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319"
New-ItemProperty -Path $NetRegistryPath -Name "SchUseStrongCrypto" -Value "1" -PropertyType DWORD -Force |
Out-Null
$NetRegistryPath = "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319"
New-ItemProperty -Path $NetRegistryPath -Name "SchUseStrongCrypto" -Value "1" -PropertyType DWORD -Force |
Out-Null
<Force_TLS1.2.PS1>
$ProtocolList = @("SSL 2.0","SSL 3.0","TLS 1.0", "TLS 1.1", "TLS 1.2")
$ProtocolSubKeyList = @("Client", "Server")
$DisabledByDefault = "DisabledByDefault"
$Enabled = "Enabled"
$registryPath = "HKLM:\\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\"
foreach($Protocol in $ProtocolList)
{
Write-Host " In 1st For loop"
foreach($key in $ProtocolSubKeyList)
{
$currentRegPath = $registryPath + $Protocol + "\" + $key
Write-Host " Current Registry Path $currentRegPath"
if(!(Test-Path $currentRegPath))
{
Write-Host "creating the registry"
New-Item -Path $currentRegPath -Force | out-Null
}
if($Protocol -eq "TLS 1.2")
{
Write-Host "Working for TLS 1.2"
New-ItemProperty -Path $currentRegPath -Name $DisabledByDefault -Value "0" -PropertyType DWORD -Force | Out-
Null
New-ItemProperty -Path $currentRegPath -Name $Enabled -Value "1" -PropertyType DWORD -Force | Out-Null
}
else
{
Write-Host "Working for other protocol"
New-ItemProperty -Path $currentRegPath -Name $DisabledByDefault -Value "1" -PropertyType DWORD -Force | Out-
Null
New-ItemProperty -Path $currentRegPath -Name $Enabled -Value "0" -PropertyType DWORD -Force | Out-Null
}
}
}
Exit 0
Paramètres de Registre TLS (Transport Layer Security)
Les applications sont contraintes de fermer les
erreurs de connexion TLS lors de la connexion SQL
serveurs Windows
Cet article permet de résoudre un problème qui se produit lorsqu’une application tente d’ouvrir une connexion à
une SQL Server.
Symptômes
Lorsqu’une application tente d’ouvrir une connexion à un SQL Server, l’un des messages d’erreur suivants
s’affiche :
Une connexion a été établie avec succès avec le serveur, mais une erreur s’est produite lors du processus de
connexion. (fournisseur : fournisseur SSL, erreur : 0 - Une connexion existante a été fermée de force par
l’hôte distant.)
Une connexion a été établie avec succès avec le serveur, mais une erreur s’est produite lors de la liaison
préalable à la connexion. (fournisseur : fournisseur TCP, erreur : 0 - Une connexion existante a été fermée de
force par l’hôte distant.)
Si vous avez activé la journalisation SChannel sur le serveur, vous recevrez l’ID d’événement 36888 (une alerte
fatal a été générée) lorsque le problème se produit.
NOTE
Selon le fournisseur ou le pilote que vous utilisez, le message d’erreur peut légèrement varier.
This issue also occurs when an application running on Windows Server 2012 R2 tries to connect to SQL Server
running on Windows Server 2019.
D’autres applications client-serveur peuvent rencontrer un problème similaire.
Cause
Windows 10, version 1511 et versions ultérieures de Windows, y compris Window Server 2016 ou Windows 10,
version 1607 avec mises à jour publiées le 25 février ou les mises à jour ultérieures installées, contient une mise
à jour zéro non importante. En attendant, toutes Windows versions qui ont été publiées avant ne contiennent
pas les mises à jour zéro non importantes.
Le client et le serveur TLS doivent calculer les clés exactement de la même manière, sinon ils obtiennent des
résultats différents. Les connexions TLS échouent de manière aléatoire si les zéros non utilisés sont calculés
différemment par le client TLS et les serveurs TLS.
Lorsqu’un groupe d’échange de clés Diffie-Hellman a des zéros non calculés, les ordinateurs non correctement
calculés peuvent calculer le mac de manière incorrecte en ne comptancent pas les zéros ajoutés. This issue is
typically seen when interacting with non-Windows-based crypto implementations and can cause intermittent
negotiation failures.
Les messages d’erreur sont renvoyés lorsque l’accord TLS sécurisé est négocié entre le client et le serveur à
l’aide TLS_DHE suite de chiffrement. L’utilisation de l’une des suites de chiffrement affectées peut être identifiée
dans le paquet « Server Hello ». Pour plus d’informations, voir l’extrait de code réseau dans la section « Plus
d’informations ».
Résolution
Pour résoudre ce problème, assurez-vous que le client et le serveur impliqués dans une connexion exécutent des
Windows qui ont les correctifs zéro non majeurs pour TLS_DHE installé. Il est recommandé d’installer les mises
à jour, car elles améliorent la conformité TLS_DHE spécifications.
La liste suivante indique la version du système d’exploitation en fonction des mises à jour installées.
Windows versions qui contiennent les correctifs zéro non TLS_DHE
Windows Server 2016, version 1607
KB 4537806 : 25 février 2020-KB4537806 (os Build 14393.3542)
KB 4540670 : 10 mars 2020-KB4540670 (os Build 14393.3564)
Mises à jour qui ont la place sur KB4537806 et KB4540670 pour les versions respectives du système
d’exploitation
Windows Server 2019 RTM et versions ultérieures.
Windows 10, version 1511 et versions ultérieures de Windows 10 (voir l’historique des versions)
Windows versions qui ne contiennent pas les correctifs zéro non TLS_DHE
Windows Server 2016, version 1607 qui ne sont pas en application des correctifs de la base de 4537806 et
de la base de 4540670.
Windows 10, version 1507
Windows 8.1
Windows 7
Windows Server 2012 R2 et versions antérieures de Windows Server
Si vous ne pouvez pas mettre à jour Windows, vous pouvez désactiver le chiffrement TLS_DHE’aide de l’une des
deux méthodes.
Utilisation de la stratégie de groupe
TLS_DHE_* peut être désactivé à l’aide de la stratégie de groupe. Reportez-vous à La hiér donc pour la
configuration de la stratégie de groupe « SSL Cipher Suite Order » (Ordre des suites de chiffrement SSL).
URL de stratégie : Configuration ordinateur -> modèles d’administration -> réseau -> configuration SSL
Paramètres
Paramètre de stratégie : paramètre de commande de suite de chiffrement SSL.
Utilisation d’un script PowerShell
foreach ($CipherSuite in $(Get-TlsCipherSuite).Name)
{
if ( $CipherSuite.substring(0,7) -eq "TLS_DHE" )
{
"Disabling cipher suite: " + $CipherSuite
Disable-TlsCipherSuite -Name $CipherSuite
}
else
{
"Existing enabled cipher suite will remain enabled: " + $CipherSuite
}
}
Vous pouvez confirmer que vous rencontrez ce problème pendant l’établissement de la connexion. Lorsque le
problème se produit, vous pouvez voir la séquence suivante dans la trace réseau sur le serveur.
1103479 <DateTime> 382.4104867 <Application IP> <Server IP> TCP:Flags=CE....S., SrcPort=62702, DstPort=1433,
PayloadLen=0, Seq=829174047, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192
1103486 <DateTime> 382.4105589 <Server IP> <Application IP> TCP: [Bad CheckSum]Flags=...A..S., SrcPort=1433,
DstPort=62702, PayloadLen=0, Seq=267349053, Ack=829174048, Win=65535 ( Negotiated scale factor 0x8 ) =
16776960
1103493 <DateTime> 382.4113628 <Application IP> <Server IP> TCP:Flags=...A...., SrcPort=62702, DstPort=1433,
PayloadLen=0, Seq=829174048, Ack=267349054, Win=513 (scale factor 0x8) = 131328
1103515 <DateTime> 382.4117349 <Application IP> <Server IP> TDS:Prelogin, Version = 7.300000(No version
information available, using the default version), SPID = 0, PacketID = 1, Flags=...AP..., SrcPort=62702,
DstPort=1433, PayloadLen=88, Seq=829174048 - 829174136, Ack=267349054, Win=131328
1103525 <DateTime> 382.4118186 <Server IP> <Application IP> TDS:Response, Version = 7.300000(No version
information available, using the default version), SPID = 0, PacketID = 1, Flags=...AP..., SrcPort=1433,
DstPort=62702, PayloadLen=48, Seq=267349054 - 267349102, Ack=829174136, Win=2102272
1103547 <DateTime> 382.4128101 <Application IP> <Server IP> TLS:TLS Rec Layer-1 HandShake: Client Hello.
1103584 <DateTime> 382.4151314 <Server IP> <Application IP> TLS:TLS Rec Layer-1 HandShake: Server Hello.
Certificate. Server Key Exchange. Server Hello Done.
1103676 <DateTime> 382.4782629 <Application IP> <Server IP> TLS:TLS Rec Layer-1 HandShake: Client Key
Exchange.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message.
1103692 <DateTime> 382.4901904 <Server IP> <Application IP> TCP:[Segment Lost] [Bad CheckSum]Flags=...A...F,
SrcPort=1433, DstPort=62702, PayloadLen=0, Seq=267351024, Ack=829174648, Win=8210 (scale factor 0x8) =
2101760
1103718 <DateTime> 382.4931068 <Application IP> <Server IP> TCP:Flags=...A...F, SrcPort=62702, DstPort=1433,
1103723 <DateTime> 382.4931475 <Server IP> <Application IP> TCP: [Bad CheckSum]Flags=...A...., SrcPort=1433,
DstPort=62702, PayloadLen=0, Seq=267351025, Ack=829174649, Win=8210 (scale factor 0x8) = 2101760
Examen du paquet Server Hello pour voir la suite de chiffrement utilisée :

Frame: Number = 1103584, Captured Frame Length = 2093, MediaType = NetEvent
+NetEvent:
+MicrosoftWindowsNDISPacketCapture: Packet Fragment (1976 (0x7B8) bytes)
+Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-00-0C-9F-F4-5C],SourceAddress:[00-1D-D8-B8-3A-
7B]
+Ipv4: Src = <Server IP>, Dest = <Application IP>, Next Protocol = TCP, Packet ID = 16076, Total IP Length =
0
+Tcp: [Bad CheckSum]Flags=...AP..., SrcPort=1433, DstPort=62702, PayloadLen=1938, Seq=267349102 - 267351040,
Ack=829174322, Win=8211 (scale factor 0x8) = 2102016
+Tds: Prelogin, Version = 7.300000(No version information available, using the default version), SPID = 0,
PacketID = 0, Flags=...AP..., SrcPort=1433, DstPort=62702, PayloadLen=1938, Seq=267349102 - 267351040,
Ack=829174322, Win=2102016
TLSSSLData: Transport Layer Security (TLS) Payload Data
-TLS: TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Key Exchange. Server Hello Done.
-TlsRecordLayer: TLS Rec Layer-1 HandShake:
ContentType: HandShake:
+Version: TLS 1.2
Length: 1909 (0x775)
-SSLHandshake: SSL HandShake Server Hello Done(0x0E)
HandShakeType: ServerHello(0x02)
Length: 81 (0x51)
-ServerHello: 0x1
+Version: TLS 1.2
+RandomBytes:
SessionIDLength: 32 (0x20)
SessionID: Binary Large Object (32 Bytes)
TLSCipherSuite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 { 0x00, 0x9F }
CompressionMethods: 0 (0x0)
ExtensionsLength: 9 (0x9)
+ServerHelloExtension: Unknown Extension Type
+ServerHelloExtension: Renegotiation Info(0xFF01)
HandShakeType: Certificate(0x0B)
Length: 778 (0x30A)
+Cert: 0x1
HandShakeType: Server Key Exchange(0x0C)
Length: 1034 (0x40A)
ServerKeyExchange: Binary Large Object (1034 Bytes)
HandShakeType: Server Hello Done(0x0E)
Length: 0 (0x0)
+Tds: Prelogin, Version = 7.300000(No version information available, using the default version), Reassembled
Packet
Référence
Gérer le TLS (Transport Layer Security)
TLS
Message d’erreur lorsque vous essayez d’ajouter
plus de 64 stations de travail d’accès : « Cette
propriété est limitée à 64 valeurs »
Cet article fournit une solution à une erreur qui se produit lorsque vous essayez d’ajouter plus de 64 stations de
travail d’accès.
S’applique à : Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Symptômes
Dans Utilisateurs et ordinateurs Active Director y, vous essayez d’ajouter plus de 64 entrées de station de
travail d’inscription sous l’onglet Logon To dans la boîte de dialogue propriétés du compte d’utilisateur. Après
cela, vous pouvez recevoir le message d’erreur suivant :
Cette propriété est limitée à 64 valeurs. Vous devez supprimer certaines des valeurs existantes avant d’en
ajouter de nouvelles.
Cause
Ce problème se produit car l’attribut User-Workstations a une valeur Range-Upper 1 024 caractères. Lorsque
vous entrez les noms d’ordinateur NetBIOS à l’aide des utilisateurs et ordinateurs Active Director y, le nom
NetBIOS a une longueur maximale de 16 caractères. Par conséquent, vous ne pouvez stocker que 64 entrées de
station de travail d’ouverture de site.
Statut
NOTE
Vous pouvez modifier la valeur rangeUpper de l’attribut User-Workstations dans le schéma à une valeur jusqu’à 8192
pour autoriser davantage d’entrées dans la liste. Microsoft ne recommande pas de valeurs supérieures, car vous pouvez
atteindre les limites de taille des objets.
rangeUpper est le Ldap-Display-Name de la Range-Upper valeur. Range-Upper est la valeur maximale ou la
longueur maximale d’un attribut. LUser-Workstations est défini dans la propriété userWorkstations d’un
utilisateur. LUser-Workstations est une propriété à valeur unique qui représente une liste séparée par des
virgules de noms d’ordinateur NetBIOS.
Pour plus d’informations sur l’attribut User-Workstations, visitez le site Web Microsoft suivant : attribut User-
Workstations
Vous recevez des erreurs d’accès refusé une fois que
vous vous êtes connecté à un compte de domaine
administrateur local.
Cet article permet de résoudre les erreurs d’accès refusé qui se produisent après la connexion à un compte de
domaine administrateur local.
Symptômes
Vous créez un compte d’administrateur local sur un ordinateur qui exécute Windows server 2003 ou
ultérieur.
Vous vous connectez en utilisant le compte d’administrateur local au lieu du compte Administrateur intégré,
puis vous configurez le serveur comme premier contrôleur de domaine dans un nouveau domaine ou une
nouvelle forêt. Comme prévu, ce compte local devient un compte de domaine.
Vous utilisez ce compte de domaine pour vous connecter.
Vous essayez d’effectuer diverses opérations des services de domaine Active Directory (AD DS).
Dans ce scénario, vous recevez des erreurs d’accès refusé.
Cause
Lorsque vous configurez le premier contrôleur de domaine dans une forêt ou un nouveau domaine, le compte
local de l’utilisateur est converti en principal de sécurité de domaine et ajouté aux groupes intégrés de domaine
correspondants, tels que Utilisateurs et Administrateurs. Étant donné qu’il n’existe pas de groupes
d’administrateurs de schéma, d’administrateurs de domaine ou d’administrateurs Enterprise locaux intégrés, ces
appartenances ne sont pas mises à jour dans les groupes de domaines et vous n’êtes pas ajouté au groupe
Administrateurs du domaine.
Pour contourner ce problème, utilisez Dsa.msc, Dsac.exe ou le module Windows PowerShell Active Directory
pour ajouter l’utilisateur aux groupes Administrateurs du domaine et Administrateurs Enterprise si nécessaire.
Nous vous déconseillons d’ajouter l’utilisateur au groupe Administrateurs du schéma, sauf si vous effectuez
actuellement une mise à niveau ou une modification de schéma.
Une fois que vous vous êtes déconnecté, puis que vous vous êtes à nouveau déconnecté, les modifications
d’appartenance au groupe prennent effet.
Ce comportement est attendu et est conçu par la conception.
Bien que ce comportement ait toujours été présent dans AD DS, les procédures de sécurité améliorées dans les
réseaux d’entreprise ont exposé le comportement aux clients qui suivent les meilleures pratiques de Microsoft
pour l’utilisation du compte Administrateur intégré.
Le compte Administrateur intégré permet de s’assurer qu’au moins un utilisateur est membre d’un groupe
d’administration complet dans une nouvelle forêt.
Les applications utilisant NetUserGetInfo et des API
similaires reposent sur l’accès en lecture à certains
objets AD
Cet article traite d’un problème dans lequel les applications qui utilisent des API de bas niveau de la classe
NetUser ou NetGroup comme ou échoue avec l’erreur NetUserGetInfo NetGroupGetInfo ACCÈS REFUSÉ.
Résumé
Vous avez une application qui utilise les API de bas niveau de la classe NetUser ou NetGroup comme
NetUserGetInfo , , , , , NetUserSetInfo et NetUserEnum NetGroupGetInfo NetGroupSetInfo NetGroupEnum
NetLocalGroupGetInfo NetLocalGroupSetInfo NetLocalGroupEnum . Dans ce schéma, les API de classe NetUser
sont également utilisées pour gérer le compte d’ordinateur.
Les mêmes API sont utilisées lorsque vous voquez le fournisseur ADSI WINNT.
Ces API peuvent échouer avec ACCESS DENIED même si le compte appelant dispose d’autorisations suffisantes
sur les comptes cibles. La raison en est que l’implémentation de l’API côté client n’a pas de relation 1:1 avec les
API RPC du Gestionnaire de comptes de sécurité (SAM). Le côté client effectue des vérifications et une
préparation supplémentaires pour ces appels qui nécessitent des autorisations supplémentaires dans Active
Directory.
Une application qui utilise ces API est le service de cluster et, dans le journal du service de cluster, vous verrez :
00000a78.000021b8::2010/06/15-00:00:47.911 WARN [RES] Network <cluster-resource1> Name: Couldn’t

determine if computer account cluster-resource1 is already disabled. état 5
Un autre symptôme de cet effet peut être un nombre excessif d’enregistrements d’audit dans le journal des
événements de sécurité de vos DCS pour ces appels d’API et les objets indiqués ci-dessous, si l’audit de l’accès
réussi ou de l’échec pour le compte appelant est activé.
L’implémentation des API utilise plusieurs appels RPC dirigés vers le contrôleur de domaine pour configurer la
session et vérifier le domaine. Il accède aux objets suivants avec accès en lecture :
Objet racine du domaine : il recherche le domaine principal du contrôleur de domaine et ouvre le
domaine en lecture, ce qui ouvre l’objet AD pour le domaine, tel que DC=contoso,dc=com.
Conteneur intégré : il s’agit de l’objet racine du domaine intégré. Elle est ouverte lorsque l’appelant
souhaite vérifier son existence. L’appelant a donc besoin d’un accès en lecture au conteneur
CN=Builtin,DC=contoso,dc=com.
Objet serveur SAM : cet objet stocke les autorisations générales sur l’accès et l’éumération généraux du
compte SAM. Il sera utilisé uniquement pour certains appels. Le nom de l’objet est
cn=server,cn=system,DC=contoso,dc=com.
Dans la plupart des domaines Active Directory, les autorisations sur ces objets sont accordées en fonction de
l’appartenance à des groupes génériques tels que Utilisateurs authentifiés, Tout le monde ou le groupe d’accès
compatible pré-Windows 2000. La modification pour déclencher le problème peut avoir été que l’utilisateur a
été supprimé du dernier groupe (peut-être avec Tout le monde, et/ou les autorisations sur les objets répertoriés
ont été supprimées dans le but de renforcement des autorisations Active Directory.
Les approches pour résoudre le problème sont d’accorder les autorisations de lecture requises ou de modifier
l’application pour utiliser LDAP au lieu des API plus anciennes ou du fournisseur ADSI WINNT. LDAP ne touche
pas les objets ci-dessus et il prendra également en charge les autorisations granulaires que vous avez peut-être
définies sur l’objet cible.
Audit excessif
Lorsque l’audit est activé sur ces objets, vous verrez jusqu’à trois enregistrements d’audit pour les objets ci-
dessus pour l’ouverture et la fermeture des objets, ainsi que l’accès réel à l’objet cible. Si les événements sont
consignés de manière excessive, il est logique de supprimer les entrées dans la ACL Audit afin que ces types
d’accès génériques ne soient plus enregistrés. Le problème est que l’objet Racine du domaine et le conteneur
intégré héritent de nombreux objets subordonnés.
Pour résoudre ce problème, vous devez rompre l’héritage au niveau du conteneur intégré et redéfinir les ace qui
héritent pour s’appliquer uniquement à cet objet. Vous devez également toucher les aces sur l’objet Racine du
domaine afin que les ES de problème ne s’appliquent plus à l’objet racine de domaine. Les étapes exactes
dépendent des paramètres de la SACL en vigueur dans votre environnement.
Erreur : l’accès est refusé lorsque des utilisateurs non
administrateurs qui ont reçu un contrôle délégué
tentent de joindre des ordinateurs à un contrôleur
de domaine
Cet article fournit une solution à un message d’erreur lorsque des utilisateurs non administrateurs qui ont reçu
un contrôle délégué tentent de joindre des ordinateurs à un contrôleur de domaine.
Symptômes
Sur un contrôleur de domaine Basé sur Microsoft Windows Server 2003 ou Windows Server 2008, les
utilisateurs non administrateurs peuvent être aux premières personnes à avoir un ou plusieurs des symptômes
suivants :
Une fois qu’un utilisateur spécifique ou un groupe spécifique a reçu l’autorisation d’ajouter ou de
supprimer des objets ordinateur dans le domaine sur une unité d’organisation via l’Assistant Délégation,
les utilisateurs ne peuvent pas ajouter certains ordinateurs au domaine. Lorsque l’utilisateur tente de
joindre un ordinateur à un domaine, les utilisateurs peuvent recevoir le message d’erreur suivant :
NOTE
Les administrateurs peuvent joindre des ordinateurs au domaine sans problème.
Les utilisateurs membres du groupe Opérateurs de compte ou qui ont reçu un contrôle délégué ne
peuvent pas créer de comptes d’utilisateurs ou réinitialiser les mots de passe lorsqu’ils se connectent
localement ou lorsqu’ils se connectent via les services terminal au contrôleur de domaine.
Lorsque les utilisateurs essaient de réinitialiser un mot de passe, ils peuvent recevoir le message d’erreur
suivant :
Windows ne peut pas terminer la modification du mot de passe du nom d’utilisateur car : l’accès est
refusé.
Lorsque les utilisateurs tentent de créer un compte d’utilisateur, ils reçoivent le message d’erreur suivant :
Le mot de passe du nom d’utilisateur ne peut pas être définie en raison de privilèges insuffisants,
Windows tentera de désactiver ce compte. Si cette tentative échoue, le compte devient un risque de
sécurité. Contactez un administrateur dès que possible pour le réparer. Pour que cet utilisateur puisse
se connecter, le mot de passe doit être définie et le compte doit être activé.
Cause
Ces symptômes peuvent se produire si une ou plusieurs des conditions suivantes sont vraies :
Un utilisateur ou un groupe n’a pas reçu l’autorisation Réinitialiser les mots de passe pour les objets
ordinateur.
NOTE
Un utilisateur ou un groupe ne peut pas joindre un ordinateur à un domaine si l’utilisateur spécifié ou le groupe
spécifié n’a pas l’autorisation Réinitialiser le mot de passe définie pour les objets ordinateur. Les utilisateurs peuvent
créer des comptes d’ordinateur pour le domaine sans cette autorisation. Toutefois, si le compte d’ordinateur est
déjà présent dans Active Directory, il reçoit le message d’erreur « Accès refusé », car l’autorisation Réinitialiser le
mot de passe est requise pour réinitialiser les propriétés de l’objet ordinateur pour l’objet ordinateur existant.
Le contrôle du groupe Opérateurs de compte a été délégué aux utilisateurs ou sont membres du groupe
Opérateurs de compte. Ces utilisateurs n’ont pas reçu l’autorisation Lecture sur l’ouo intégrée dans «
Utilisateurs et ordinateurs Active Directory ».
Résolution
Pour résoudre le problème dans lequel les utilisateurs ne peuvent pas joindre un ordinateur à un domaine,
1. Sélectionnez Démarrer, Sélectionnez Exécuter, tapez dsa.msc, puis sélectionnez OK.
2. Dans le volet Des tâches, développez le nœud de domaine.
3. Recherchez et cliquez avec le bouton droit sur l’ou que vous souhaitez modifier, puis sélectionnez Contrôle
délégué.
4. Dans l’Assistant Délégation de contrôle, sélectionnez Suivant.
5. Sélectionnez Ajouter pour ajouter un utilisateur spécifique ou un groupe spécifique à la liste Des utilisateurs
et des groupes sélectionnés, puis sélectionnez Suivant .
6. Dans la page Tâches à déléguer, sélectionnez Créer une tâche personnalisée à déléguer, puis sélectionnez
Suivant .
7. Sélectionnez uniquement les objets suivants dans le dossier, puis dans la liste, cliquez pour cocher la
case Objets ordinateur. Ensuite, cochez les cases sous la liste, Créez des objets sélectionnés dans ce dossier
et supprimez les objets sélectionnés dans ce dossier.
8. Sélectionnez Suivant .
9. Dans la liste Autorisations, cliquez pour cocher les cases suivantes :
Réinitialiser le mot de passe
Lecture et écriture des restrictions de compte
Écriture validée dans le nom d’hôte DNS
Écriture validée dans le nom principal de ser vice
10. Sélectionnez Suivant, puis Terminer.
11. Fermez le logiciel en ligne de la MMC « Utilisateurs et ordinateurs Active Directory ».
Pour résoudre le problème dans lequel les utilisateurs ne peuvent pas réinitialiser les mots de passe, suivez les
étapes suivantes :
1. Sélectionnez Démarrer, Sélectionnez Exécuter, tapez dsa.msc, puis sélectionnez OK.
2. Dans le volet Des tâches, développez le nœud de domaine.
3. Recherchez et cliquez avec le bouton droit sur Builtin, puis sélectionnez Propriétés.
4. Dans la boîte de dialogue Propriétés intégrées, sélectionnez l’onglet Sécurité.
5. Dans la liste Des noms d’utilisateurs ou de groupes, sélectionnez Opérateurs de compte.
6. Sous Autorisations pour les opérateurs de compte, cliquez pour cocher la case Autoriser
l’autorisation lecture, puis sélectionnez OK.
NOTE
Si vous souhaitez utiliser un groupe ou un utilisateur autre que le groupe Opérateurs de compte, répétez les
étapes 5 et 6 pour ce groupe ou cet utilisateur.
7. Fermez le logiciel en ligne de la MMC « Utilisateurs et ordinateurs Active Directory ».

ID d’événement 16650 : échec de l’initialisation de
l’allocation d’identificateur de compte dans
Windows Server
Cet article fournit une solution pour résoudre les erreurs qui se produisent lorsque vous ajoutez des objets à
Active Directory ou restituer un contrôleur de domaine à partir d’une sauvegarde d’état système.
Symptômes
Cet article s’applique Windows 2000 et toutes les versions ultérieures. Lorsque vous essayez d’ajouter de
nouveaux utilisateurs, groupes, ordinateurs, boîtes aux lettres, contrôleurs de domaine ou autres objets à Active
Directory sur un ordinateur Microsoft Windows Server, vous pouvez recevoir le message d’erreur suivant :
Impossible de créer l’objet car le service d’annuaire n’a pas pu allouer un identificateur relatif.
Lorsque vous restituer un contrôleur de domaine à partir d’une sauvegarde d’état système, le journal système
peut contenir le message d’erreur suivant :

Source de l’événement : sam, événement
Category:None
L’allocation d’identificateur de compte n’a pas réussi à s’initialiser correctement. Les données
d’enregistrement contiennent le code d’erreur NT à l’origine de l’échec. Windows retenterez l’initialisation
jusqu’à ce qu’elle réussisse ; Jusqu’à ce moment, la création du compte sera refusée sur ce contrôleur de
domaine. Recherchez d’autres journaux d’événements SAM qui peuvent indiquer la raison exacte de l’échec.
Vous pouvez également utiliser la Dcdiag commande avec le commutateur de commentaires pour rechercher
des erreurs supplémentaires. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd dans la zone Ouvrir, puis cliquez sur OK.
2. À l’invite de commandes, DCdiag /v tapez, puis appuyez sur Entrée.
Lorsque vous Dcdiag /v tapez, vous pouvez voir des messages d’erreur semblables à ce qui suit :
Test de début : RidManager

* Le pool RID disponible pour le domaine est de 2355 1073741823
* dc01.contoso.com est le master RID
* DsBind avec rid master a réussi
* rIDAllocationPool est de 1355 à 1854
* rIDNextRID : 0 La DS a des données endommagées : valeur rIDPreviousAllocationPool non valide
* rIDPreviousAllocationPool est de 0 à 0 Aucun déboguement alloué - veuillez vérifier lelog des événements.
......................... Échec du test DC01 RidManager
Avertissement : la référence du jeu de suppression est supprimée.
ldap_search_sW of CN=RID SetDEL:cfe0828c-8842-4cb1-a642-6d9991d0516d,CN=Deleted Objects,DC=
contoso ,DC= com for rid info failed with 2: The system cannot find the file specified.
......................... Échec du test DC01 RidManager
Test de début : RidManager
* Le pool RID disponible pour le domaine est de 3104 1073741823
Avertissement : le propriétaire du rôle FSMO est supprimé.
* dc01.contoso.com est le master RID
* DsBind avec rid master a réussi
Avertissement : la référence du jeu de suppression est supprimée.
ldap_search_sW of CN=RID SetDEL:5a128cf2-f365-47bc-a883-8ff9561ff545,CN=Deleted
Objects,DC=contoso,DC=com for rid info failed with 2: The system cannot find the file specified. .........................
Échec du test DC01 RidManager
Test de début : KnowsOfRoleHolders
Role Rid Owner = CN="NTDS Paramètres DEL:fd615439-1ebb-4652-b16f-
3f8517d25593 »,CN=dc01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com Warning: CN=" » NTDS Paramètres
DEL:fd615439-1ebb-4652-b16f-3f8517d25593 »,CN=dc01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contoso,DC=com is the Rid Owner, but is deleted.
Vous pouvez également recevoir d’autres erreurs dans le journal des événements système qui peuvent vous
aider à résoudre le problème :
Source de l’événement : SAM
Description : le contrôleur de domaine démarre une demande pour un nouveau pool d’identificateurs de
compte.

Source de l’événement : SAM Event Category:None
Description : l’identificateur de compte maximal alloué à ce contrôleur de domaine a été affecté. Le
contrôleur de domaine n’a pas pu obtenir un nouveau pool d’identificateurs. Une raison possible est que le
contrôleur de domaine n’a pas pu contacter le contrôleur de domaine maître. La création de compte sur ce
contrôleur échoue tant qu’un nouveau pool n’a pas été alloué. Il peut y avoir des problèmes de réseau ou de
connectivité dans le domaine, ou le contrôleur de domaine maître peut être hors connexion ou absent du
domaine. Vérifiez que le contrôleur de domaine maître est en cours d’exécution et connecté au domaine.
Cause
Ce problème se produit dans l’un des scénarios suivants :
Lorsque l’ID relatif (RID) Master est restauré à partir de la sauvegarde, il tente de se synchroniser avec
d’autres contrôleurs de domaine pour vérifier qu’il n’existe aucun autre master RID en ligne. Toutefois, le
processus de synchronisation échoue si aucun contrôleur de domaine n’est disponible pour la
synchronisation ou si la réplication ne fonctionne pas.
NOTE
Si le domaine ne contient toujours qu’un seul contrôleur de domaine, le master RID n’essaiera pas de se
synchroniser avec d’autres contrôleurs de domaine. Le contrôleur de domaine n’a aucune connaissance des autres
Le pool RID est épuisé, ou les objets dans Active Directory liés à l’allocation RID utilisent des valeurs
incorrectes ou sont manquants.
Résolution
Supprimer les liens de réplication pour les contextes d’attribution de noms Windows
Dans Windows 2000 et versions ultérieures, vous pouvez restaurer un deuxième contrôleur de domaine pour
terminer la synchronisation initiale. Si vous ne pouvez pas restaurer un deuxième contrôleur de domaine, vous
devez effectuer un nettoyage des métadonnées sur les contrôleurs de domaine inexistants ou supprimer les
liens de réplication vers les contextes d’attribution de noms Active Directory. Si vous prévoyez de restaurer les
autres contrôleurs de domaine ultérieurement, vous devez supprimer les liens de réplication au lieu d’effectuer
un nettoyage des métadonnées.
Avant de supprimer les liens de réplication vers les contextes d’appellation Active Directory, vous devez
identifier la valeur objectGUID à l’aide de la Repadmin commande. Pour cela, procédez comme suit :
2. À l’invite de commandes, tapez repadmin /showreps . Vous verrez une sortie semblable à ce qui suit :
CN=Schema,CN=Configuration,DC=contoso,DC=comDefault-First-Site-Name\DC02 via RPC

objectGuid: <GUID> Last attempt @ was <DateTime> successful.
CN=Configuration,DC=contoso,DC=com Default-First-Site-Name\DC02 via RPC objectGuid: <GUID>
Last attempt @ was <DateTime> successful.
DC=contoso,DC=com Default-First-Site-Name\DC02 via RPC objectGuid: <GUID> Last attempt @
was <DateTime> successful.
3. Tapez repadmin /delete pour supprimer les liens de réplication. Spécifiez le contexte d’attribution de
noms et l’objetGUID comme illustré dans les exemples suivants :
repadmin /delete CN=Schema,CN=Configuration,DC=contoso,DC=com DC01 <GUID>._msdcs.contoso.com

/localonly
repadmin /delete CN=Configuration,DC=contoso,DC=com DC01 <GUID>._msdcs.contoso.com /localonly
repadmin /delete DC=contoso,DC=com DC01 <GUID>._msdcs.contoso.com /localonly
4. Redémarrez l’ordinateur maître RID. Le master RID s’initialise correctement.

Supprimer les métadonnées du contrôleur de domaine pour tous les autres contrôleurs de domaine dans le
domaine
Vous pouvez restaurer ou connecter un deuxième contrôleur de domaine pour effectuer la synchronisation
initiale. Si vous ne pouvez pas ajouter un deuxième contrôleur de domaine, vous devez effectuer un nettoyage
des métadonnées sur les contrôleurs de domaine inexistants pour les supprimer définitivement du domaine ou
supprimer définitivement les liens de réplication vers les contextes d’attribution de noms Active Directory. Pour
plus d’informations sur la suppression des métadonnées, cliquez sur le numéro d’article suivant pour afficher
l’article Nettoyer les métadonnées du serveur.
Vérifier que les objets Active Directory liés à l’allocation RID sont valides
Pour vérifier que les objets Active Directory liés à l’allocation RID sont valides, suivez les étapes suivantes :
1. Vérifiez que le groupe Tout le monde dispose de l’accès à cet ordinateur à partir du droit d’utilisateur
réseau. Le paramètre peut être configuré à l’emplacement suivant dans l’Éditeur d’objets de stratégie de
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
groupe :
2. Installez les outils Windows 2000. Ces outils sont disponibles dans le dossier de support sur les CD-ROM
Windows 2000 et Windows Server 2003. Une fois ces outils installés, ADSI Edit démarrez. Pour cela,
a. Cliquez sur Démarrer , cliquez sur Exécuter , tapez mmc dans la zone de texte Ouvrir , puis cliquez
sur OK .
b. Dans Windows 2000, cliquez sur Console, puis sur Ajouter/Supprimer un logiciel en snap-in .
Dans Windows Server 2003, cliquez sur Fichier, puis sur Ajouter/Supprimer un logiciel en snap-
in .
c. In the Add/Remove snap-in, click Add , click ADSIEdit , and then click Add .
d. Cliquez sur Fermer , puis sur OK .
3. Dans MMC, cliquez avec le bouton droit sur ADSIEdit, puis cliquez sur Connecter à .
4. Dans Connexions Paramètres , sous Point de connexion, cliquez sur Sélectionner un contexte
d’attribution de noms connu. Dans la liste drop-down, cliquez sur domaine, puis sur OK .
5. Développez le domaine, puis le nom du domaine. Par exemple, développez DC= contoso , DC=
com****.
6. Développez OU=Contrôleurs de domaine.
7. Cliquez avec le bouton droit sur le contrôleur de domaine à vérifier, puis cliquez sur Propriétés.
8. Cliquez sur sélectionner une propriété pour afficher le menu, puis cliquez sur
userAccountControl .
9. Vérifiez que la valeur de userAccountControl est 532480. Pour modifier la valeur
userAccountControl, cliquez sur Modifier dans la boîte de dialogue propriété du contrôleur de
domaine.
10. Dans l’éditeur d’attributs integer, tapez 532480 dans le champ Valeur, puis cliquez sur OK .
Vérifier que le master RID réplique avec un autre contrôleur de domaine
Si un contrôleur de domaine récemment promu génère l’événement 16650, le contrôleur de domaine peut
avoir obtenu des informations de réplication d’un autre contrôleur de domaine qui n’est pas le contrôleur RID.
Pendant la promotion, le compte d’ordinateur du nouveau contrôleur de domaine est modifié. Si ces
modifications n’ont pas été répliquées sur le contrôleur de domaine qui détient le rôle principal RID, la demande
échoue lorsque le contrôleur de domaine nouvellement promu tente d’obtenir un pool RID.
Pour vérifier que le master RID réplique avec au moins l’un de ses partenaires directs, suivez les étapes
suivantes :
1. Vérifiez que l’objet CN=RID Set existe.
L’objet CN=RID Set se trouve dans le volet droit d’ADSI Edit lorsque le contrôleur de domaine est
sélectionné sous OU=Contrôleurs de domaine dans le volet gauche.
Si aucun objet CN=RID Set n’existe, vous devez rétrograder ce contrôleur de domaine, puis le
promouvoir à nouveau pour créer l’objet.
2. Si l’objet CN=RID Set existe, assurez-vous que l’attribut rIDSetReferences sur l’objet de compte
d’ordinateur du contrôleur de domaine pointe vers le nom de l’objet RID Set, comme illustré dans
l’exemple suivant : CN=RID Set, CN=DC01,OU=Domain Controllers,CN=contoso,DC=local
Si l’attribut rIDSetReferences ne pointe pas vers le nom unique de l’objet RID Set, contactez les
services de support technique Microsoft pour plus d’informations.
Statut
Références
822053 message d’erreur : « Windows impossible de créer l’objet car le service d’annuaire n’a pas pu allouer un
identificateur relatif »
Comment ajouter des groupes spéciaux à des
groupes intégrés
Cet article explique comment ajouter des groupes spéciaux à des groupes intégrés.
Résumé
Si, en tant qu’administrateur, vous supprimez l’une des appartenances d’un groupe spécial, comme Utilisateurs
authentifiés, d’un groupe Utilisateurs locaux de domaine intégré sur un contrôleur de domaine dans Windows,
vous ne pouvez pas lire le groupe à l’aide de l’outil Utilisateurs et ordinateurs Active Directory. Pour ajouter l’un
des groupes spéciaux à un groupe local de domaine sur un contrôleur de domaine, utilisez la net localgroup
commande.
Par exemple, utilisez la commande suivante pour rajouter le groupe Utilisateurs authentifiés au groupe
Utilisateurs locaux du domaine intégré sur un contrôleur de domaine :
net localgroup users "nt authority\authenticated users" /add
Dans Windows, il existe certains groupes spéciaux créés par le système et utilisés à des fins spéciales. La liste de
ces groupes spéciaux inclut :
Logo anonyme
Batch
Creator, propriétaire
Groupe créateur
Dialup
Enterprise Contrôleurs de domaine
Tout le monde
Interactives
Réseau
Proxy
Restreint
Lui-même
Service
Système
Utilisateur Terminal Server
Étant donné que vous ne pouvez pas modifier l’appartenance à ces groupes, les groupes ne sont pas répertoriés
dans Utilisateurs et ordinateurs Active Directory ( Dsa.msc ). Toutefois, ces groupes sont utiles pour des
opérations telles que l’attribution d’autorisations à des répertoires, des fichiers, des répertoires réseau partagés
ou des imprimantes.
Les utilisateurs deviennent membres de ces groupes spéciaux en fonction de l’opération qu’ils tentent
d’effectuer. Par exemple, un utilisateur obtient l’appartenance au groupe interactif dans son jeton chaque fois
qu’il utilise un ordinateur localement. Le groupe réseau est ajouté au jeton d’un utilisateur chaque fois qu’un
utilisateur se connecte sur le réseau à un ordinateur.
Tous les membres d’un groupe peuvent ne pas être
renvoyés lorsque vous éumez les membres d’un
groupe à l’aide du fournisseur WinNT Des interfaces
de service Active Directory
Cet article fournit une solution à un problème : tous les membres d’un groupe peuvent ne pas être renvoyés
lorsque vous éumez les membres d’un groupe à l’aide du fournisseur WinNT Des interfaces de service Active
Directory.
Symptômes
Lorsque vous émanez des membres d’un groupe à l’aide du fournisseur ADSI WinNT (Active Directory Service
Interfaces) et que vous utilisez une chaîne de liaison, un problème peut se produire. Il se peut que certains
membres du groupe ne soient pas renvoyés si le groupe que vous éumez possède les membres suivants :
Groupe local qui contient des utilisateurs de domaine et des groupes de domaines en tant que membres
Un groupe local de domaine qui contient des groupes de domaines de confiance en tant que membres
Vous pouvez utiliser la méthode GetObject pour obtenir la liste des membres complète. La méthode GetObject
utilise les informations d’identification de l’utilisateur actuellement connecté. L’exemple de code suivant illustre
cela.
GetObject("WinNT://<server>/<group>,group")
Si le compte que vous souhaitez utiliser pour l’éumération du groupe n’est pas l’utilisateur actuellement
connecté, vous pouvez utiliser l’emprunt d’identité avant d’utiliser la méthode GetObject.
Statut
Étapes pour reproduire le problème

Le fournisseur WinNT Des interfaces de service Active Directory ne se connecte pas à plusieurs serveurs pour
compiler la liste des membres. Ce problème se produit si des informations d’identification explicites sont
transmises. Par conséquent, seule une liste de membres partielle est renvoyée. Par exemple, si vous exécutez le
script suivant pour lister un groupe local qui contient un groupe d’un domaine approuvé, tous les membres du
groupe sont renvoyés, à l’exception du groupe du domaine approuvé.
'Start of the script
Dim oRoot
Dim oSourceGroup
Dim oMember
Const ADS_SECURE_AUTHENTICATION=1
'Binding
Set oRoot = GetObject("WinNT:")
Set oTargetGroup = oRoot.OpenDSObject("WinNT://<server>/<group>,group", "<domain>\<user>", "
<password>",ADS_SECURE_AUTHENTICATION)'All of the following are placeholders: <server> <group> <domain>
<user> <password>
msgbox oTargetGroup.ADSPath
For Each oMember in oTargetGroup.Members

msgbox oMember.ADsPath
Next
'End of the script
IMPORTANT
Nous vous déconseillons de transmettre des informations d’identification dans les interfaces de service Active Directory à
l’aide du fournisseur WinNT Des interfaces de service Active Directory.
Pour plus d’informations, voir Problèmes d’authentification des utilisateurs avec le fournisseur WinNT Des
interfaces de service Active Directory.
Références
Interfaces du service Microsoft Active Directory
Les résultats d’AuditPol et de stratégie de sécurité
locale peuvent différer
Cet article permet de résoudre un problème dans lequel les paramètres de stratégie d’audit avec AuditPol et la
stratégie de sécurité locale (SECPOL.msc) montrent des résultats différents.
Symptômes
Lors de l’affichage des paramètres de stratégie d’audit avec AuditPol et la stratégie de sécurité locale
(SECPOL.msc), les paramètres peuvent afficher des résultats différents.
Cause
AuditPol appelle directement les API d’autorisation pour implémenter les modifications apportées à la stratégie
d’audit granulaire. Secpol.msc manipule l’objet de stratégie de groupe local, ce qui entraîne l’écriture des
modifications apportées à %SYSTEMROOT%\system32\GroupPolicy\Machine\Microsoft\Windows
NT\Audit\Audit.csv. Les paramètres enregistrés dans le fichier .csv ne sont pas appliqués directement au
système au moment de la modification, mais sont écrits dans le fichier et lus ultérieurement par l’extension côté
client (CSE). Lors du cycle d’actualisation suivant de la stratégie de groupe, le CSE applique les modifications
présentes dans le .csv de groupe.
Secpol.msc affiche ce qui est définie dans l’GPO local. Il n’existe aucun affichage « Paramètres effectifs » dans
secpol.msc qui fusionne les paramètres AuditPol granulaires et ce qui est défini localement comme vu avec
secpol.msc.
Résolution
À partir d’une invite de commandes d’administration, vous pouvez utiliser AuditPol pour afficher les paramètres
d’audit définis en exécutant :
auditpol /get /category:*
Auditpol get
« Référence d’objet non définie sur une instance
d’un objet » lors de l’accès aux informations Active
Directory à partir de l’Explorateur de contrôle de
source TFS
Cet article fournit de l’aide pour résoudre une erreur qui se produit lorsque vous accédez à des informations
Active Directory à partir Team Foundation Server’Explorateur de contrôles de source.
Publication rapide
Les articles de publication rapide fournissent des informations directement à partir de l’organisation de support
Microsoft. Les informations contenues ici sont créées en réponse à des rubriques émergentes ou uniques, ou
sont destinées à compléter d’autres informations de la base de connaissances.
Action
Créez un Windows dans Active Directory (AD), puis affectez des utilisateurs AD au groupe, puis...
1. Ouvrir Visual Studio en tant qu’administrateur TFS
2. Explorateur de contrôles Open Source
3. Cliquez avec le bouton droit sur un dossier de contrôle de version et sélectionnez Propriétés
4. Cliquez sur l’onglet Sécurité dans la boîte de dialogue Propriétés
5. Sélectionnez l Windows option Utilisateur ou Groupe, puis cliquez sur le bouton Ajouter
6. Recherchez le groupe AD ; et essayez d’ajouter le groupe
Résultat
Erreur : La référence d’objet n’est pas définie sur une instance d’un objet.
Cause
Ce problème est dû à un bogue dans la fenêtre de boîte de dialogue d’autorisation de contrôle de version Visual
Studio 2008\ Team Explorer 2008.
Résolution
Ce problème est résolu dans Visual Studio 2008 SP1. Si vous utilisez Visual Studio 2008 RTM, il existe deux
solutions de contournement :
1. Attribuer des autorisations de contrôle de version à l’aide de l’outil en ligne de commande : tf.exe
Vous pouvez entrer ou consulter la documentation MSDN relative à cette commande d’autorisation TF
pour plus d’informations sur l’attribution d’autorisations de contrôle de version à partir de la tf perm /?
ligne de commande.
2. Faites explicitement du groupe AD en question une identité TFS valide :
a. Créez un groupe d’utilisateurs sur le serveur.
b. Ajoutez le groupe AD en question à ce groupe.
c. Vous devez maintenant être en mesure d’attribuer des autorisations de contrôle de version au groupe
AD.

Dans la mesure maximale autorisée par la loi applicable, Microsoft et/ou ses fournisseurs se délamentent et
excluent toutes les représentations, garanties et conditions, qu’elles soient express, implicites ou statutaires, y
compris, mais sans s’y limiter, aux représentations, aux garanties ou aux conditions de titre, de non-violation, de
le matériel.
Vous ne pouvez pas ajouter un nom d’utilisateur ou
un nom d’objet qui diffère uniquement d’un
caractère avec une marque diacritique
Cet article fournit une solution à un problème dans lequel vous ne pouvez pas ajouter un nom d’utilisateur ou
un nom d’objet qui diffère uniquement d’un caractère avec une marque diacritique.
Symptômes
Vous essayez d’ajouter un nouvel utilisateur ou un nouvel objet au service d’annuaire Active Directory. Toutefois,
l’utilisateur ou l’objet n’est pas ajouté. En outre, vous pouvez recevoir l’un des messages d’erreur suivants :
Message d’erreur 1 :
Le nom d’utilisateur de l’objet n’a pas pu être créé.

Le problème rencontré était ;
Une tentative d’ajout d’un objet au répertoire avec un nom déjà utilisé a été tentée.
Windows ne peut pas créer le nouvel objet utilisateur, car le nom d’utilisateur est déjà en cours
d’utilisation. Sélectionnez un autre nom, puis recommencez.
Windows ne peut pas créer l’objet spécifié car : l’utilisateur spécifié existe déjà.
Le nom d’utilisateur que vous avez choisi est déjà utilisé dans cette entreprise. Choisissez un autre
nom de logo, puis essayez à nouveau.
NOTE
Dans ces messages d’erreur, le nom d’utilisateur est le nom de l’utilisateur ou de l’objet que vous avez essayé d’ajouter.
Cause
Ce problème se produit parce que le nom d’utilisateur ou le nom d’objet contient des signes diacritiques, par
exemple, des umlauts allemands. Un caractère de relance allemand contient une dieresis sur le caractère de base
lui-même, comme dans les caractères suivants :
Ää
Öö
Üü
Les caractères de relance allemands sont interprétés comme étant identiques à leurs caractères de base. Par
exemple, le caractère ü est interprété comme étant identique au caractère u. Lorsque ce problème se produit, un
utilisateur nommé ne peut pas être créé s’il existe déjà un utilisateur Muller Müller nommé. De même, un
utilisateur nommé ne peut pas être créé s’il existe déjà un utilisateur Meissner Meißner nommé.
Résolution
Pour résoudre ce problème, utilisez un nom différent pour l’utilisateur ou pour l’objet que vous souhaitez
ajouter.
Statut
Microsoft a publié des règles pour les caractères valides pour différents types d’objets, ce qui réduit davantage la
liberté de choix de nom. Pour plus d’informations, voir Conventions d’attribution de noms dans Active Directory
pour les ordinateurs, les domaines, les sites et les O.
Vous ne pouvez pas démarrer l’outil Utilisateurs et
ordinateurs Active Directory, car le serveur n’est pas
opérationnel.
Cet article fournit une solution à un problème dans lequel vous ne pouvez pas démarrer l’outil Utilisateurs et
ordinateurs Active Directory, car le serveur n’est pas opérationnel.
Symptômes
L’un des symptômes suivants peut se produire :
Lorsque vous essayez de démarrer l’outil Utilisateurs et ordinateurs Active Directory, vous recevez le
Les informations d’attribution de noms ne peuvent pas être localisées car :

Contactez votre administrateur système pour vérifier que votre domaine est correctement configuré
et qu’il est actuellement en ligne.
Lorsque vous essayez de démarrer l’outil Sites et services Active Directory, vous recevez le message
Les informations d’attribution de noms ne peuvent pas être localisées car :

Contactez votre administrateur système pour vérifier que votre domaine est correctement configuré
et qu’il est actuellement en ligne.
Lorsque vous essayez de démarrer l’outil Domaines et trusts Active Directory, vous recevez le message
Les informations de configuration décrivant cette entreprise ne sont pas disponibles.

Le traitement des logons est très lent.

Si vous avez plusieurs contrôleurs de domaine, vous pouvez vous connecter avec l’outil Utilisateurs et
ordinateurs Active Directory à un autre contrôleur de domaine dont le port 389 est ouvert sans recevoir
de message d’erreur. Mais vous ne pouvez pas accéder à un contrôleur de domaine tant que le port 389
n’est pas ouvert.
Cause
Ces problèmes peuvent se produire si le filtrage TCP/IP est configuré pour autoriser uniquement le port 80 pour
le trafic TCP/IP.
Résolution
Le port 389 est utilisé pour les connexions LDAP (Lightweight Directory Access Protocol). Ce port est bloqué si
le filtrage TCP/IP est configuré de manière incorrecte. Par défaut, le filtrage TCP/IP est configuré avec le
paramètre Autoriser tout. Pour vérifier et corriger ce paramètre :
1. Cliquez avec le bouton droit sur Mes lieux réseau sur le contrôleur de domaine sur lequel vous ne pouvez
pas démarrer Utilisateurs et ordinateurs Active Directory, puis cliquez sur Propriétés.
2. Cliquez sur Protocole Internet, puis sur Propriétés.
4. Cliquez sur Options .
5. Cliquez sur Filtrage TCP/IP, puis sur Propriétés.
6. Pour le paramètre Port TCP/IP, cliquez sur Autoriser tout.
7. Redémarrez l'ordinateur. Cela ouvre tous les ports TCP, y compris le port 389.
État
Compatibilité avec les comptes d’utilisateur se
terminant par le signe dollar ($)
Cet article décrit les problèmes de compatibilité potentiels lors de l’utilisation de comptes d’utilisateur de
domaine se terminant par le signe dollar ($) en tant que compte de service.
S’applique à : Windows Server 2012 R2, Windows 7 Service Pack 1
Résumé
À compter Windows 7/2008R2, il existe des problèmes de compatibilité potentiels avec l’utilisation de comptes
d’utilisateur de domaine se terminant par le signe dollar ($) en tant que compte de service. Les comptes de
service gérés sont identifiés en se terminant par un signe dollar ($). Le système peut évaluer le compte en tant
que compte de service géré et bloquer la modification.
Dans la console de services, si vous entrez un compte d’utilisateur dans un domaine approuvé qui se termine
par le signe dollar ($), il vous avertit que « Le nom fourni n’est pas un nom de compte correctement formé ».
Cela se produit car les comptes de service gérés ne peuvent pas être utilisés dans un domaine approuvé.
Comptes de service gérés
Définir des modèles de sécurité à l’aide des modèles
de sécurité Snap-In
Cet article fournit quelques étapes pour définir des modèles de sécurité à l’aide du logiciel en snap-in des
modèles de sécurité.
Résumé
Cet article détaillé explique comment créer et définir un nouveau modèle de sécurité à l’aide du logiciel en snap-
in Modèles de sécurité dans Microsoft Windows Server 2003.
Avec le logiciel en snap-in Modèles de sécurité, vous pouvez créer une stratégie de sécurité pour votre réseau
ou ordinateur à l’aide de modèles de sécurité. Un modèle de sécurité est un fichier texte qui représente une
configuration de sécurité. Vous pouvez appliquer un modèle de sécurité à l’ordinateur local, importer un modèle
de sécurité dans la stratégie de groupe ou utiliser un modèle de sécurité pour analyser la sécurité. Vous pouvez
utiliser un modèle de sécurité prédéféré inclus dans Windows Server 2003, modifier un modèle de sécurité
prédéféré ou créer un modèle de sécurité personnalisé qui contient les paramètres de sécurité voulus. Les
modèles de sécurité peuvent être utilisés pour définir les composants suivants :
Stratégies de compte
Stratégie de mot de passe
Stratégie de verrouillage de compte
Stratégie Kerberos
Stratégies locales
Stratégie d’audit
Attribution des droits d’utilisateur
Options de sécurité
Journal des événements : paramètres du journal des applications, du système et des événements de
sécurité
Groupes restreints : appartenance à des groupes sensibles à la sécurité
Services système : modes de démarrage et autorisations pour les services système
Registre : autorisations de clé de Registre
Système de fichiers : autorisations de fichiers et de dossiers
Ajouter les modèles de sécurité Snap-In à une console MMC (Microsoft Management Console )
Pour ajouter le logiciel en snap-in Modèles de sécurité à une console MMC, suivez les étapes suivantes :
2. Dans la zone Ouvrir, tapez mmc, puis cliquez sur OK.
3. Dans le menu Fichier , cliquez sur Ajouter/Supprimer un composant logiciel enfichable .
4. Dans la boîte de dialogue Ajouter/Supprimer un logiciel en un clin d’œil, cliquez sur l’onglet
autonome, puis cliquez sur Ajouter.
5. Dans la boîte de dialogue Ajouter un logiciel en un clin d’œil autonome, cliquez sur Modèles de
sécurité, cliquez sur Ajouter, cliquez sur Fermer, puis sur OK.
6. Dans l’arborescence de la console, développez Modèles de sécurité, puis développez
%SystemRoot%\Security\Templates .
Une liste de modèles de sécurité prédéfinie et leurs descriptions s’affiche dans le volet droit.
Créer et définir un nouveau modèle de sécurité
Pour définir un nouveau modèle de sécurité, suivez les étapes suivantes :
1. Dans l’arborescence de la console, développez Modèles de sécurité.
2. Cliquez avec le bouton droit sur %SystemRoot%\Security\Templates, puis cliquez sur Nouveau
modèle.
3. Dans la zone Nom du modèle, tapez un nom pour le nouveau modèle.
Si vous le souhaitez, vous pouvez taper une description dans la zone Description, puis cliquer sur OK.
Le nouveau modèle de sécurité apparaît dans la liste des modèles de sécurité. Notez que les paramètres
de sécurité de ce modèle ne sont pas encore définis. Lorsque vous développez le nouveau modèle de
sécurité dans l’arborescence de la console, développez chaque composant du modèle, puis double-
cliquez sur chaque paramètre de sécurité contenu dans ce composant, l’état Non défini apparaît dans la
colonne Paramètres de l’ordinateur.
4. Pour définir des stratégies de compte, des stratégies locales ou des stratégies de journal des événements,
a. Dans l’arborescence de la console, développez le composant qui contient le paramètre de sécurité que
vous souhaitez configurer.
Par exemple, pour définir une stratégie d’âge de mot de passe maximale, développez Stratégies de
compte.
b. Dans le volet droit, double-cliquez sur le paramètre de sécurité que vous souhaitez configurer. Par
exemple, pour définir la stratégie d’âge maximal du mot de passe, double-cliquez sur Stratégie de mot
de passe, puis double-cliquez sur Âge maximal du mot de passe.
c. Cliquez pour sélectionner le paramètre Définir cette stratégie dans la case à cocher du modèle,
spécifiez l’option ou le paramètre que vous souhaitez selon le paramètre de sécurité, puis cliquez sur
OK.
5. Pour définir une stratégie de groupes restreints, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur Groupes restreints, puis cliquez sur Ajouter un groupe.
b. Cliquez sur Parcourir .
c. Dans la boîte de dialogue Sélectionner des groupes, tapez le nom du groupe dont vous souhaitez
restreindre l’accès, cliquez sur OK, puis sur OK.
d. Dans la boîte de dialogue Propriétés de GroupName, sous Membres de ce groupe, cliquez sur
Ajouter des membres pour ajouter les membres que vous souhaitez au groupe.
Pour ajouter ce groupe en tant que membre d’un autre groupe, sous Ce groupe est membre de ,
cliquez sur Ajouter des groupes.
e. Cliquez sur OK .
6. Pour définir une stratégie de services système, suivez les étapes suivantes :
a. Développer les ser vices système.
b. Dans le volet droit, double-cliquez sur le service que vous souhaitez configurer.
c. Spécifiez les options de votre choix, puis cliquez sur OK.
7. Pour définir la sécurité des clés de Registre, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur Registre, puis cliquez sur Ajouter une clé.
b. Dans la boîte de dialogue Sélectionner la clé de Registre, cliquez sur la clé de Registre dont vous
souhaitez définir la sécurité, puis cliquez sur OK.
c. Dans la boîte de dialogue Sécurité de la base de données pour Registr yKey, spécifiez les
autorisations que vous souhaitez pour la clé de Registre, puis cliquez sur OK .
d. Dans la boîte de dialogue Ajouter un objet, spécifiez comment vous souhaitez que les autorisations
sur cette clé héritent, cliquez sur OK, puis cliquez sur OK .
8. Pour définir la sécurité des fichiers ou des dossiers, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur Système de fichiers, puis cliquez sur Ajouter un fichier.
b. Dans la boîte de dialogue Ajouter un fichier ou un dossier, cliquez sur un fichier ou un dossier à
ajouter à la sécurité, puis cliquez sur OK.
c. Dans la boîte de dialogue Sécurité de la base de données pour FileName ou FolderName, spécifiez
les autorisations que vous souhaitez, cliquez sur OK, puis sur OK .
Copier les Paramètres sécurité à partir d’un modèle prédéféré vers un autre modèle
Pour copier les paramètres de sécurité d’un modèle prédéféré vers votre modèle personnalisé, suivez les étapes
suivantes :
1. Dans l’arborescence de la console, développez un modèle prédéféré qui contient les paramètres que vous
souhaitez copier, cliquez avec le bouton droit sur le composant que vous souhaitez copier, puis cliquez sur
Copier .
2. Dans l’arborescence de la console, développez votre modèle personnalisé, cliquez avec le bouton droit
sur le composant approprié, puis cliquez sur Coller .
Par exemple, pour utiliser les paramètres des stratégies de compte à partir du modèle Hisecdc dans votre
modèle personnalisé, développez Hisecdc, cliquez avec le bouton droit sur Stratégies de compte, puis
cliquez sur Copier . Développez votre modèle personnalisé, cliquez avec le bouton droit sur Stratégies
de compte, puis cliquez sur Coller.
Créer un modèle de sécurité basé sur un modèle prédéféré
Pour créer un modèle de sécurité basé sur les paramètres d’un modèle prédéféré, enregistrez-le à l’aide d’un
autre nom de fichier. Pour ce faire, procédez comme suit :
1. Cliquez avec le bouton droit sur le modèle à copier, puis cliquez sur Enregistrer sous .
2. Dans la boîte de dialogue Enregistrer sous, tapez un nom pour le modèle de sécurité dans la zone
Nom de fichier, puis cliquez sur Enregistrer .
Le nouveau modèle de sécurité apparaît dans la liste des modèles de sécurité. Configurez le modèle avec
les paramètres que vous souhaitez.
Références
Pour plus d’informations sur les modèles de sécurité dans Windows Server 2003, voir la rubrique «
Gestionnaire de configuration de la sécurité » dans la section Sécurité de la documentation Windows 2003
Server.
Erreur « Impossible de convertir le type de données
d’annuaire vers ou à partir d’un type de données
DS natif »
Cet article permet de corriger l’erreur « Le type de données d’annuaire ne peut pas être converti vers ou à partir
d’un type de données DS natif ».
Symptômes
Vous exécutez ou gérez des applications qui utilisent des informations du service d’annuaire Active Directory
dans Windows. Vous pouvez recevoir des erreurs lorsque les applications utilisent des informations pour les
attributs liés. Par exemple, vous pouvez recevoir l’erreur suivante :
Le type de données d’annuaire ne peut pas être converti en / à partir d’un type de données DS natif.
Dans ce cas, lorsque vous exportez l’objet affecté à l’aide de l’utilitaire LDIFDE (Ldifde.exe), un attribut est
répertorié. Toutefois, l’attribut n’a pas de valeur.
Il peut s’agit du comportement attendu lorsque la valeur est longue. Mais la ligne suivante de la sortie possède
l’attribut suivant. Pour un groupe et son attribut managedBy, la sortie peut ressembler à ce qui suit :
...
showInAddressBook : <Address Book object DN>
managedBy :
legacyExchangeDN : <X500 name>
groupType: -2147483640
...
Dans un vidage de base de données avec le verbe de commande RootDSE dumpdatabase, les groupes affectés
s’afficheront comme suit :
38661 29827 1 1790 true - 4 3 Group-DN Group-DN - 655368 6d03f309-ded2-41d5-9794-081d40343876

4
objectclass: 655368, 65536
DNT Base BDNT DelTime DeactiveTime USNChanged NCDNT Data
38661 1 38662 - - 55247898 1790 -
38661 36 2 - - - - -
L’ID d’attribut de lien est toujours 36 et le partenaire de lien est toujours 2.

Pour plus d’informations sur le vidage de la base de données, voir Comment utiliser la fonctionnalité Dbdump
en ligne d’Active Directory.
Cause
Une application peut ajouter un lien d’objet qui fait référence à l’objet racine interne de la base de données
Active Directory. Cet objet n’a pas de nom ou d’autres propriétés utilisables pour les applications. Par
conséquent, les applications clientes affichent des messages d’erreur qui n’indiquent pas la cause d’un
problème.
Résolution
Si vous utilisez des contrôleurs de domaine qui exécutent Windows Server 2003 avec Service Pack 1, le
problème ne se produit pas. Mais l’objet avec ce lien non valide se trouve toujours dans la base de données.
Vous pouvez trouver les groupes affectés pour un contrôleur de domaine lorsque vous recherchez le NTDS.
Fichier DMP, comme suit :
findstr /i /c: » 36 2 - - " ntds.dmp

38661 36 2 - - - - -
Windows Ser ver 2003 :

Vous ne pouvez pas résoudre le problème en supprimant l’attribut. Si vous supprimez l’attribut, l’erreur suivante
est consignée dans le journal des services d’annuaire d’applications :

Description :
Active Directory n’a pas pu mettre à jour l’objet suivant avec une modification de valeur d’attribut reçue du
contrôleur de domaine source suivant. Cela est dû au fait qu’une erreur s’est produite lors de l’application
des modifications apportées à Active Directory sur le contrôleur de domaine local.
Objet :
<group DN>
GUID d’objet :
<GUID>
<GUID-based DC name>
Attribut :
managedBy :
Valeur d’attribut :
[]
GUID de valeur d’attribut :
00000000-0000-0000-0000-000000000000
Présente :
0
Cette opération est tentée à nouveau lors de la prochaine réplication programmée. La synchronisation du
contrôleur de domaine local avec le contrôleur de domaine source est bloquée jusqu’à ce que le problème
de mise à jour soit résolu.
Valeur d’erreur :
Le système de réplication a rencontré une erreur interne.
Si cette erreur est consignée, l’objet est dans un état rompu. Pour obtenir l’état d’origine ou supprimer l’objet,
vous pouvez uniquement exécuter une restauration faisant autorité sur l’objet. Pour réparer les objets qui
présentent ce comportement, nous vous recommandons de supprimer et de reconstruire l’objet à l’aide de
l’utilitaire LDIFDE.
Cau t i on
Tous les liens arrière sont supprimés lorsque vous supprimez un objet.
Si vous devez conserver certains attributs dont vous ne pouvez pas définir la valeur, tels que l’attribut objectSid
ou SidHistory, supprimez puis supprimez l’objet. (Windows Server 2003 Service Pack 1 conserve l’attribut
SidHistor y lorsque vous supprimez un objet.) Lorsque vous supprimez et supprimez un objet, vous n’avez pas
besoin d’exécuter de vérification sémantique.
Toutefois, il n’existe actuellement aucun outil permettant de récupérer les attributs et les liens arrière. Pour
restaurer les appartenances aux groupes, vous pouvez utiliser l’outil Groupadd.exe de groupe. Pour plus
d’informations, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances
Microsoft :
840001 comment restaurer les comptes d’utilisateurs supprimés et leurs appartenances aux groupes dans
Active Directory
Si vous utilisez le système d’approvisionnement Microsoft, vous pouvez utiliser le système pour récupérer les
attributs et les liens arrière.
Certaines applications de sauvegarde et de récupération peuvent offrir un moyen plus pratique de supprimer
ces attributs problématiques. L’application doit vous laisser sélectionner des attributs lors d’une opération de
restauration. Par exemple, une application doit vous laisser exclure l’attribut managedBy lorsque vous restituer
un objet supprimé.
Statut
S’applique à ». Ce problème a été d’abord résolu dans Microsoft Windows Server 2003 Service Pack 1.
L’ID d’événement 5722 est enregistré sur votre
Cet article explique comment diagnostiquer et résoudre un problème où l’événement 5722 apparaît dans le
journal système de votre contrôleur de domaine.
NOTE
Cet article s’applique Windows 2000. Le support Windows 2000 se termine le 13 juillet 2010. Pour plus
d’informations, voir la politique de cycle de vie du support Microsoft.
Résumé
Lorsque vous utilisez l’Observateur d’événements pour afficher le journal système dans un Windows de
domaine, il se peut que vous trouviez l’événement 5722 enregistré. Ce problème peut se produire dans l’un des
deux scénarios suivants :
Lorsqu’un ordinateur met à jour son mot de passe de compte d’ordinateur avec un contrôleur de domaine
Lorsqu’un ordinateur est joint à un domaine avec un nom qui existe déjà
Cet article explique comment différencier les deux scénarios et résoudre le problème.
Symptômes
Sur un contrôleur de Windows Microsoft, l’événement suivant est consigné dans le journal système :

Date : Date
Time: Time
Utilisateur : N/A
Description : La configuration de session à partir de l’ordinateur ComputerName n’a pas réussi à
s’authentifier. Le nom du compte référencé dans la base de données de sécurité est AccountName $.
L’erreur suivante s’est produite :
Cause
Dans un domaine Microsoft Windows, à partir de Windows 2000, un canal de communication discret permet de
fournir un chemin de communication plus sécurisé entre le contrôleur de domaine et les serveurs ou stations de
travail membres. Ce canal est appelé canal sécurisé. Lorsque vous joignez un ordinateur à un domaine, un
compte d’ordinateur est créé et un mot de passe est partagé entre l’ordinateur et le domaine. Par défaut, ce mot
de passe est modifié tous les 30 jours. Le mot de passe du canal sécurisé est stocké avec le compte d’ordinateur
sur le contrôleur de domaine principal (PDC). Le mot de passe est répliqué sur tous les contrôleurs de domaine
répliqués.
L’événement 5722 est journalisé dans les scénarios suivants :
Lorsqu’un ordinateur met à jour son mot de passe de compte d’ordinateur avec un contrôleur de
domaine, l’événement est consigné dans le journal système du contrôleur de domaine d’authentification.
Dans ce scénario, le canal sécurisé de l’ordinateur avec le contrôleur de domaine d’authentification est
toujours valide.
Lorsque vous associez un ordinateur à un domaine à l’aide d’un nom déjà utilisé par un autre ordinateur,
ou lorsqu’un compte d’ordinateur existant est réinitialisé. Un compte d’ordinateur existant peut être
réinitialisé à l’aide des utilisateurs et ordinateurs Active Directory ou à l’aide de Netdom.exe utilitaire.
Dans ce scénario, le mot de passe du compte de l’ordinateur ne correspond pas au mot de passe du
contrôleur de domaine et vous ne pouvez pas définir de canal sécurisé de l’ordinateur d’origine sur le
Résolution
WARNING
Si vous utilisez le logiciel en snap-in ADSI Edit, l’utilitaire LDP ou tout autre client LDAP version 3 et que vous modifiez de
manière incorrecte les attributs des objets Active Directory, vous risquez de graves problèmes. Ces problèmes peuvent
nécessiter la réinstallation de Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000
Server, Microsoft Exchange Server 2003 ou les deux Windows et Exchange. Microsoft ne peut pas garantir que les
problèmes qui se produisent si vous modifiez incorrectement les attributs de l’objet Active Directory peuvent être résolus.
La modification de ces attributs relève de votre responsabilité.
Pour résoudre ce problème, déterminez d’abord quel scénario est à l’origine du problème. Vous pouvez suivre
1. Notez la date et l’heure de journal de l’événement dans le journal système.
2. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Kit de ressources, puis cliquez sur
Console de gestion des outils.
3. Dans l’arborescence de la console, cliquez sur Outils A à Z .
4. Dans le volet d’informations, cliquez sur Éditeur ADSI.
NOTE
ADSI Edit est inclus dans les outils Windows support technique. Vous pouvez installer les outils Windows support
technique à partir du dossier Support\Tools du CD-ROM Windows Server 2000.
Pour installer ADSI Edit sur les ordinateurs exécutant Windows Server® 2003 ou Windows® XP,
installez les outils de support Windows Server 2003 à partir du CD du produit Windows Server 2003 ou
du Centre de téléchargement Microsoft. Pour plus d’informations sur l’installation des outils Windows
support technique à partir du CD-CS du produit, voir Install Windows Support Tools.
Sur les serveurs exécutant Windows Server 2008 ou Windows Server 2008 R2, ADSI Edit est installé
lorsque vous installez le rôle services de domaine Active Directory (AD DS) pour faire d’un serveur un
contrôleur de domaine. Vous pouvez également installer les Outils d'administration de serveur distant
(RSAT) Windows Server 2008 sur des serveurs membres du domaine ou sur des serveurs autonomes.
Pour obtenir des instructions spécifiques, voir Installation ou suppression du pack d’outils
d’administration de serveur distant.
Pour installer ADSI Edit sur les ordinateurs exécutant Windows Vista® avec Service Pack 1 (SP1) ou
Windows 7, vous devez installer RSAT.
5. Dans ADSI Edit, recherchez, puis cliquez avec le bouton droit sur l’ordinateur à l’origine du problème.
7. Dans Sélectionner les propriétés à afficher, cliquez sur Les deux.
8. Dans Sélectionner une propriété à afficher, cliquez sur PwdLastSet .
Si la valeur n’est pas convertie dans l’interface utilisateur en date et en timestamp lisibles, exécutez la
commande suivante ou procédez à l’étape 9 pour une ntte autre méthode :
w32tm /ntte pwdlastsetvalue
9. Copiez la valeur qui apparaît dans la ou les valeurs dans le Presse-papiers.

10. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Accessoires, puis cliquez sur
Calculatrice .
11. Dans le menu Affichage, cliquez sur Scientifique .
12. Click Dec to set the numbering system to decimal.
13. Collez la valeur du Presse-papiers dans la calculatrice.
14. Pour changer la valeur du système de numérotation décimale en nombre décimal hexadécimal, cliquez
sur Hex .
15. Dans le menu Edition , cliquez sur Copier .
16. Collez le nombre hexadécimal du Presse-papiers dans un fichier Bloc-notes.
17. Comptez huit caractères à partir du caractère le plus à droite de la chaîne hexadécimale, puis appuyez sur
SPACEBAR.
NOTE
Cette action fractionne la chaîne hexadécimale en deux chaînes hexadécimales.
18. Si la chaîne hexadécimale du côté gauche ne contient que sept caractères, ajoutez un zéro au début de la
chaîne.
19. À l’invite de commandes, tapez
Nltest /time: RightSideHexadecimalstringLeftSideHexadecimalString
Vous recevrez une sortie similaire à celle-ci :
C:\>nltest /time:a25cc370 01c294bc

a25cc370 01c294bc = 11/25/2002 13:55:41
The command completed successfully.
20. Notez la date et l’heure décodées.
21. Vérifiez si la date et l’heure que vous avez notées à l’étape 1 et la date et l’heure décodées que vous avez
notées à l’étape 20 correspondent.
22. Si la date et l’heure de journalisation de cet événement 5722 et la date et l’heure décodées
correspondent, vérifiez si un canal sécurisé est établi sur l’ordinateur à l’origine du problème avec un
contrôleur de domaine en tapant la commande suivante à l’invite de commandes :
Nltest /server: **ComputerName** /sc_query: **DomainName**
Si l’ordinateur à problème dispose d’un canal sécurisé valide établi avec un contrôleur de domaine, vous
recevez une sortie similaire à :
C:\>Nltest /server:computer1 /sc_query: DomainName Flags: 30

HAS_IP HAS_TIMESERV
Trusted DC Name \\homenode1.myhouse.com Trusted DC Connection Status Status = 0 0x0 NERR_Success The
command completed successfully.
Si l’ordinateur à problème n’a pas de canal sécurisé valide établi avec un contrôleur de domaine, vous
recevez une sortie similaire à :
C:\>nltest /server:machine1 /sc_query: DomainName Flags: 0

Trusted DC Name
Trusted DC Connection Status Status = 5 0x5 ERROR_ACCESS_DENIED The command completed successfully.
Si la date et l’heure de l’événement 5722 et la date et l’heure décodées ne correspondent pas, le mot de passe
du compte de l’ordinateur à problème peut ne pas correspondre au mot de passe qui se trouve sur le contrôleur
de domaine. Ce problème peut se produire dans l’une des circonstances suivantes :
Un administrateur réinitialise un compte d’ordinateur à l’aide des utilisateurs et ordinateurs Active Directory
ou d’un autre outil tel que Netdom.exe.
Un nouvel ordinateur est joint au domaine à l’aide d’un nom qui existe déjà dans le domaine.
NOTE
Si la journalisation du service Netlogon est désactivée pour le contrôleur de domaine, vous confirmez ce scénario en
vérifiant une entrée Netlogon.log similaire à la suivante :
05/06 13:35:25 [MISC] NlMainLoop : Notification que le compte d’confiance a ajouté (ou modifié) TRUSTING_DOMAIN$
0x#### 4
Ce message n’est pas enregistré si un ordinateur met à jour son propre mot de passe de compte d’ordinateur.
Pour résoudre les problèmes liés aux noms d’ordinateurs en double, rejoignez l’ordinateur d’origine dans le
domaine.
Vous pouvez ignorer l’événement 5722 si les deux conditions suivantes sont vraies :
Si la date et l’heure de l’événement 5722 et la date et l’heure décodées correspondent.
Un canal sécurisé valide est établi entre l’ordinateur à problème et un contrôleur de domaine.
NOTE
Lorsque ces deux conditions sont vraies, l’événement 5722 est connecté au contrôleur de domaine lorsque l’ordinateur
tente de s’authentifier auprès d’un contrôleur de domaine pendant le processus de mise à jour du compte d’ordinateur.
Les administrateurs peuvent également interroger des informations Active Directory à partir de n’importe quel
ordinateur du domaine à l’aide Ldp.exe. La version de Ldp.exe incluse dans les outils de support Windows XP
Service Pack 2 peut également être utilisée pour décoder la valeur PwdLastSet.
Références
Pour plus d’informations sur l’activation de la journalisation du débogage, cliquez sur le numéro d’article suivant
pour afficher l’article dans la Base de connaissances Microsoft :
109626 l’activation de la journalisation du débogage pour le service Net Logon
Message d’erreur : impossible de supprimer un objet
DSA
Cet article fournit une solution à un problème dans lequel vous ne parviennent pas à supprimer une Paramètres
NTDS orpheline des sites et services Active Directory.
Symptômes
Lorsque vous essayez de supprimer une Paramètres NTDS orpheline des sites et services Active Directory, vous
pouvez recevoir le message d’erreur suivant : l’objet DSA ne peut pas être supprimé.
Il n’existe généralement qu Paramètres un seul serveur NTDS dans le dossier Serveurs des sites et services
Active Directory. Si deux Paramètres NTDS sont affichés, celui qui n’est pas associé à des objets de connexion
(dans le volet droit) est probablement le Paramètres NTDS orphelin.
Cause
Le Dcpromo.exe de rétrogradation doit supprimer les Paramètres NTDS d’un serveur. Toutefois, le processus
Dcpromo.exe ne peut pas supprimer les Paramètres NTDS même si les objets de connexion sont supprimés. Si
vous avez plusieurs contrôleurs de domaine, le processus de réplication Active Directory risque de ne pas
supprimer les Paramètres NTDS de ce contrôleur de domaine.
Résolution
Pour contourner ce problème, complétez la procédure suivante sur un contrôleur de domaine qui a une
Paramètres NTDS orpheline :
1. Démarrez ADSI Edit, puis développez les branches suivantes :
Configuration NC
CN=Configuration,DC=domain, DC=com
CN=Sites
CN= nom de votre site
CN=Serveurs
2. Recherchez le serveur qui possède une Paramètres NTDS orpheline. Cliquez avec le bouton droit sur la
Paramètres NTDS orpheline, puis cliquez sur Supprimer.
3. Si vous avez plusieurs contrôleurs de domaine, assurez-vous que cette modification est répliquée sur
tous les contrôleurs de domaine.
Un objet Paramètres NTDS orphelin peut également se trouver dans le conteneur LostAndFoundConfig sous le
conteneur de configuration dans ADSI Edit. Vous pouvez utiliser la procédure analogue pour supprimer cet
objet. Pour cela :
1. Démarrez ADSI Edit, puis développez les branches suivantes :
Configuration NC
CN=Configuration,DC=domain, DC=com
CN=LostAndFoundConfig
2. Cliquez avec le bouton droit sur l’objet Paramètres NTDS orphelin, puis cliquez sur Supprimer. Assurez-
vous que l’objet serveur associé n’existe pas avant de supprimer l’objet Paramètres NTDS.
Statut
ADSIEDIT fait partie des outils de support Windows 2000.
Get-ADGroupMember renvoie une erreur pour le
groupe local de domaine aux membres des forêts
distantes
Cet article permet de résoudre une erreur qui se produit lorsque vous exécutez l’cmdlet dans un scénario où un
groupe a un membre Get-ADGroupMember d’une forêt distante.
Symptômes
Supposons que vous utilisez la cmdlet pour identifier les membres d’un groupe dans les services de domaine
Get-ADGroupMember Active Directory (AD DS). Toutefois, lorsque vous exécutez la cmdlet pour un groupe local de
domaine, l’erreur suivante est renvoyée :
Get-ADGroupMember -verbose -identity « CN=Test-Local1,OU=Test Accounts,DC=contoso,DC=com »

Get-ADGroupMember : une erreur non spécifiée s’est produite
À line:1 char:1
+ Get-ADGroupMember -verbose -identity « CN=Test-Local1,OU=Test Accounts,DC=contoso ...
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (CN=Test-Local1,... bertm-w7,DC=com:ADGroup) [Get-ADGroupMember],
ADExceptionon + FullyQualifiedErrorId :
ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADGroupMember
NOTE
Dans une relation d’confiance à sens seul, lorsque vous utilisez la cmdlet sur un groupe à partir de la forêt d’confiance,
vous recevez les erreurs suivantes si le groupe contient des membres de la forêt Get-ADGroupMember de confiance :
« Une erreur non spécifiée s’est produite »
« Le serveur n’a pas pu traiter la demande en raison d’une erreur interne »
Pour contourner ce besoin, utilisez le logiciel en ligne Utilisateurs et ordinateurs Active Directory pour afficher les
membres du groupe, ou convertissez l’confiance à sens seul en une confiance à deux sens.
Cause
Ce problème se produit si le groupe a un membre d’une autre forêt dont le compte a été supprimé de la forêt de
comptes. Le membre est représenté dans le domaine local par un principal de sécurité étranger (FSP). Dans
l’exportation LDIFDE du groupe, une appartenance s’affiche comme suit :
dn: CN=Test-Local1,OU=Test Accounts,DC=contoso,DC=com
membre :
CN=S-1-5-21-3110691720-3620623707-1182478234-
698540,CN=ForeignSecurityPrincipals,DC=contoso,DC=com
membre :
CN=S-1-5-21-3110691720-3620623707-1182478234-
695739,CN=ForeignSecurityPrincipals,DC=contoso,DC=com
Lorsque le compte source avec le SID est supprimé, le FSP n’est pas mis à jour ou supprimé pour refléter cette
suppression. Vous devez vérifier manuellement que ces références de FSP sont supprimées.
Résolution
Pour résoudre ce problème, activez la journalisation pour les demandes de résolution qui concernent ces SID et
qui sont effectuées par le service Web Active Directory. De cette façon, vous pouvez identifier les comptes dont
la résolution échoue. Pour ce faire, exécutez l’cmdlet sur le contrôleur de domaine (où l’espace réservé
représente Get-ADGroupMember contoso.com le domaine en question).
Pour activer la journalisation, exécutez les lignes de commande suivantes :
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgInfoLevel -Value 0x800 -Type

dword -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgTraceOptions -Value 0x1 -
Type dword -Force
N’oubliez pas de éteindre la journalisation lorsque vous avez le journal :
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgInfoLevel -Value 0x0 -Type

dword -Force
Vous verrez un fichier nommé c:\windows\debug\lsp.log, qui suit les tentatives SID-Name résolution. Lorsque
vous réexécutez la cmdlet sur le contrôleur de domaine où la cmdlet a été exécutée, le fichier enregistre les
échecs et ressemble à ce qui suit :
LspDsLookup - Entering function LsapLookupSidsLspDsLookup - LookupSids request for 1 SIDs with

level=1, mappedcount=0, options=0x0, clientRevision=2 is being processed. Les SID sont ; LspDsLookup -
Sids[ 0 ] = S-1-5-21-3110691720-3620623707-1182478234-698540LspDsLookup - Requestor details:
Local Machine, Process ID = 1408, Process Name =
C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe LspDsLookup - Entering function
LsapDbLookupSidsUsingIdentityCacheLspDsLookup - 1 sids remain unmappedLspDsLookup - Exiting
function LsapDbLookupSidsUsingIdentityCache with status 0x0LspDsLookup - LookupSids chain request
(using Netlogon) to \ dc3.northwindtraders.com for 1 sids will be made with level=6, mappedcount=0,
options=0x0, serverRevision=0. Les sids sont ; LspDsLookup - Sids[ 0 ] = S-1-5-21-3110691720-
3620623707-1182478234-698540 LspDsLookup - Lookup request (using Netlogon) to \
dc3.northwindtraders.com returned with 0xc0000073 and mappedcount=0, serverRevision=0LspDsLookup
- Exiting function LsapLookupSids with status 0xc0000073
Recherchez les éléments suivants pour vérifier qu’il s’agit de la section pertinente pour ce problème (dans
l’exemple de sortie précédent) :
Le processus est C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.
La demande est envoyée à un contrôleur de domaine dans une autre forêt, par exemple,
northwindtraders.com .
Le code de retour est 0xc0000073, ce qui est égal à STATUS_NONE_MAPPED.
Pour trouver l’objet FSP, exécutez la commande suivante (remplacez les noms de domaine et les SID) :
get-AdObject -Searchbase "CN=ForeignSecurityPrincipals,DC=contoso,DC=com" -ldapfilter "(cn=S-1-5-21-

3110691720-3620623707-1182478234-698540)"
L’objet d’origine de ce FSP n’existe plus, vous pouvez donc le supprimer en toute sécurité. Cela permet
également de le supprimer de tous les groupes dont il est membre :
get-AdObject -Searchbase "CN=ForeignSecurityPrincipals,DC=contoso,DC=com" -ldapfilter "(cn=S-1-5-21-

3110691720-3620623707-1182478234-698540)" | Remove-AdObject -Confirm:$false
Références
Comment les SID et les noms de compte peuvent être mappés Windows
Le mode de planification de l’ensemble de stratégies
résultant n’est pas pris en charge dans un scénario
entre forêts
Cet article décrit les limitations à l’ensemble de mode de planification de stratégie (RSoP) résultant lorsque vous
essayez de l’utiliser dans plusieurs forêts.
S’applique à : Windows 10 - toutes les éditions, Windows Server 2012 R2, Windows Server 2016, Windows
Server 2019
Symptômes
Vous ne pouvez pas utiliser le mode de planification RSoP pour planifier des scénarios qui couvrent des forêts
Windows Server 2003 et versions ultérieures. Par exemple, vous ne pouvez pas planifier un scénario dans lequel
un utilisateur se connecte à une station de travail dans la forêt 1 à partir de la forêt 2. Lorsque vous essayez
d’exécuter le mode de planification RSoP dans un environnement entre forêts, vous recevez le message d’erreur
de stratégie de groupe suivant :
Les scénarios en mode de planification entre forêts ne sont actuellement pas pris en charge.
Cause
Ce problème se produit car le mode de planification RSoP ne prend pas en charge les scénarios entre forêts.
Dans de nombreux scénarios, RSoP ne peut pas valider les informations renvoyées par un contrôleur de
domaine situé dans une autre forêt. Le groupe Utilisateurs authentifiés doit avoir des autorisations de lecture
pour les stratégies pertinentes afin de lire correctement une stratégie particulière dans un environnement entre
forêts.
Comment modifier les noms d’affichage des
utilisateurs Active Directory
Cet article explique comment modifier les noms complets des utilisateurs Active Directory (AD).
Résumé
Lorsqu’un nouvel utilisateur est créé dans Active Directory, le champ Nom complet est toujours généré au
format Prénom Nom. À son tour, ce champ définit le champ Nom complet lors de la création, de sorte que vous
vous retrouvez avec une liste d’adresses globale au format FirstName LastName.
Vous pouvez effectuer cette modification à l’aide de l’utilitaire Adsiedit. Adsiedit modifie non seulement la façon
dont le champ Nom complet est créé par défaut, mais aussi le champ Nom complet (c’est-à-dire, le champ « cn
»), c’est pourquoi les utilisateurs apparaissent dans le format choisi lorsque vous recherchez dans le logiciel en
ligne Utilisateurs et ordinateurs.
ADSIEdit Instructions
WARNING
Si vous utilisez le logiciel en snap-in ADSI (Active Directory Service Interfaces) Edit, l’utilitaire LDP ou tout autre client
LDAP (Lightweight Directory Access Protocol) version 3 et que vous modifiez incorrectement les attributs des objets
Active Directory, vous risquez de graves problèmes. Ces problèmes peuvent nécessiter la réinstallation de Microsoft
Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server
2003 ou les deux Windows et Exchange. Microsoft ne peut pas garantir que les problèmes qui se produisent si vous
modifiez incorrectement les attributs de l’objet Active Directory peuvent être résolus. La modification de ces attributs
relève de votre responsabilité.
1. Insérez Windows CD-CSV Server 2000.

2. Accédez au \support\tools répertoire.
3. Double-cliquez sur le Support.cab de données.
4. Recherchez les fichiers adsiedit.msc et adsiedit.dll. Extrayez-les %systemroot%\system32 dans votre
répertoire.
5. Exécutez regsvr32 adsiedit.dll.
6. Démarrez Microsoft Management Console (MMC), puis ajoutez le logiciel en snap-in ADSI Edit.
7. Cliquez avec le bouton droit sur le nœud supérieur, puis sélectionnez Connecter sur .
8. Modifiez le contexte d’attribution de noms en conteneur de configuration, puis sélectionnez OK pour
lier et vous authentifier.
9. Développez le nœud Conteneur de configuration, puis le nœud Configuration.
10. Développez le nœud cn=DisplaySpecifiers, puis double-cliquez sur CN=409 .
NOTE
409 est l’ID de paramètres régionaux pour l’anglais (États-Unis). Si vous êtes dans un environnement multilingue,
vous devrez peut-être apporter des modifications aux autres codes. La plupart des codes asiatiques sont déjà
définies.
L’Union internationale de télécommunications (ITU) et l’Organisation internationale de normalisation

(ISO) définissent les pages de code. Pour plus d’informations, consultez les pages Web itu
11. Dans le volet droit, ouvrez les propriétés cn=user-Display .
12. Faites défiler jusqu’à la propriété createDialog facultative.
13. Définissez l’attribut %< sur sn >.%< givenName > . Veillez à sélectionner Définir .
NOTE
Les seuls jetons qui peuvent être formatés dans la dislayName sont % <sn> , % et % <givenName> <initials> .
14. Sélectionnez OK pour fermer la boîte de dialogue.

15. Dans Utilisateurs et ordinateurs Active Directory, créez un utilisateur . Le nom complet (et donc le nom
complet) sont créés conformément à votre règle.
Ces modifications peuvent avoir des effets négatifs.
Remarques
Les instructions vous montrent comment modifier des objets utilisateur. Il existe un paramètre distinct pour
Les contacts : modifiez l’étape 11 en « contact-Display ».
Vous n’avez pas besoin de fermer le logiciel en ligne Utilisateurs et ordinateurs . les modifications sont
automatiquement reprises.
Dans les environnements de contrôleurs multi-domaines, vous devrez peut-être attendre la fin de la
réplication avant que l’interface utilisateur ne reprend les modifications.
Comment activer la journalisation des événements
Kerberos
Cet article explique comment activer la journalisation des événements Kerberos.

S’applique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10, version
1809 versions ultérieures, Windows 7 Service Pack 1
Résumé
Windows 7 Service Pack 1, Windows Server 2012 R2 et versions ultérieures offrent la possibilité de suivre des
événements Kerberos détaillés via le journal des événements. Vous pouvez utiliser ces informations lors du
dépannage de Kerberos.
IMPORTANT
La modification du niveau de journalisation entraîne la journalisation de toutes les erreurs Kerberos dans un événement.
Dans le protocole Kerberos, certaines erreurs sont attendues en fonction de la spécification du protocole. Par conséquent,
l’activation de la journalisation Kerberos peut générer des événements contenant des erreurs fausses positives attendues,
même en l’absence d’erreurs opérationnelles Kerberos.
Voici quelques exemples d’erreurs de faux positifs :

1. KDC_ERR_PREAUTH_REQUIRED est renvoyée sur la demande AS Kerberos initiale. Par défaut, le client
Windows Kerberos n’insère pas les informations de pré-authentification dans cette première demande.
La réponse contient des informations sur les types de chiffrement pris en charge sur le KDC et, dans le
cas d’AES, les sels à utiliser pour chiffrer les hésages de mot de passe.
Recommandation : ignorez toujours ce code d’erreur.
2. KDC_ERR_S_BADOPTION est utilisé par le client Kerberos pour récupérer des tickets avec des options
particulières définies, par exemple, avec certains indicateurs de délégation. Lorsque le type de délégation
demandé n’est pas possible, il s’agit de l’erreur renvoyée. Le client Kerberos essaie alors d’obtenir les
tickets demandés à l’aide d’autres indicateurs, ce qui peut réussir.
Recommandation : à moins que vous ne dépanniez un problème de délégation, ignorez cette erreur.
3. KDC_ERR_S_PRINCIPAL_UNKNOWN peuvent être enregistrées pour un large éventail de problèmes liés à
la liaison entre le client d’application et le serveur. La cause peut être :
SSN manquants ou dupliqués enregistrés dans AD.
Noms de serveur incorrects ou suffixes DNS utilisés par le client, par exemple, le client est en cours
d’enregistrement CNAME DNS et utilise l’enregistrement A résultant dans les noms de domaine
principal.
Utilisation de noms de serveurs non-FQDN qui doivent être résolus au-delà des limites de la forêt AD.
Recommandation : examinez l’utilisation des noms de serveur par les applications. Il s’agit très
probablement d’un problème de configuration du client ou du serveur.
4. KRB_AP_ERR_MODIFIED journalisé lorsqu’un SPN est définie sur un compte incorrect, ce qui ne
correspond pas au compte avec qui le serveur est en cours d’exécution. Le deuxième problème courant
est que le mot de passe entre le KDC qui émet le ticket et le serveur hébergeant le service est hors
synchronisation.
Recommandation : similaire à KDC_ERR_S_PRINCIPAL_UNKNOWN, vérifiez si le SPN est correctement
définie.
D’autres scénarios ou erreurs nécessitent l’attention des administrateurs système ou de domaine.
IMPORTANT
Windows .
Activer la journalisation des événements Kerberos sur un ordinateur

spécifique
2. Ajoutez la valeur de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Valeur de Registre : LogLevel
Données de valeur : 0x1
Si la sous-clé Parameters n’existe pas, créez-la.
NOTE
Supprimez cette valeur de Registre lorsqu’elle n’est plus nécessaire afin que les performances ne se dégradent pas
sur l’ordinateur. En outre, vous pouvez supprimer cette valeur de Registre pour désactiver la journalisation des
événements Kerberos sur un ordinateur spécifique.
3. Quittez l’Éditeur du Registre. Le paramètre entrera immédiatement en vigueur Windows Server 2012 R2,
Windows 7 et versions ultérieures.
4. Vous pouvez trouver tous les événements liés à Kerberos dans le journal système.
La journalisation des événements Kerberos est conçue uniquement à des fins de dépannage lorsque vous
attendez des informations supplémentaires pour le côté client Kerberos à une période d’action définie. Restated,
kerberos logging should be disabled when not actively troubleshooting.
D’un point de vue général, vous pouvez recevoir des erreurs supplémentaires qui sont correctement gérées par
le client de réception sans intervention de l’utilisateur ou de l’administrateur. Restated, some errors captured by
Kerberos logging don’t reflect a severe problem that must be solved or even can be solved.
Par exemple, un journal d’événements 3 sur une erreur Kerberos avec le code d’erreur 0x7
KDC_ERR_S_PRINCIPAL_UNKNOWN pour les> d’adresse IP de nom de serveur/<est consigné lorsqu’un
accès de partage est effectué par rapport à une adresse IP de serveur et aucun nom de serveur. Si cette erreur
est consignée, le client Windows tente automatiquement de revenir à l’authentification NTLM pour le compte
d’utilisateur. Si cette opération fonctionne, aucune erreur ne s’est produite.
Comment réinitialiser le mot de passe du compte
d’administrateur du mode restauration des services
d’annuaire dans Windows Server
Cet article explique comment réinitialiser le mot de passe de l’administrateur du mode de restauration des
services d’annuaire (DSRM) pour n’importe quel serveur de votre domaine sans redémarrer le serveur en mode
DSRM.
Résumé
Microsoft Windows 2000 utilise l’utilitaire Setpwd pour réinitialiser le mot de passe DSRM. Dans Microsoft
Windows Server 2003, cette fonctionnalité a été intégrée à l’outil NTDSUTIL. Notez que vous ne pouvez pas
utiliser la procédure décrite dans cet article si le serveur cible est en cours d’exécution dans DSRM. Un membre
du groupe Administrateurs de domaine définit le mot de passe de l’administrateur DSRM pendant le processus
de promotion du contrôleur de domaine. Vous pouvez utiliser Ntdsutil.exe pour réinitialiser ce mot de passe
pour le serveur sur lequel vous travaillez, ou pour un autre contrôleur de domaine dans le domaine.
Réinitialiser le mot de passe de l’administrateur DSRM

1. Cliquez sur > Démarrer, tapez ntdsutil, puis cliquez sur OK.
2. À l’invite de commandes Ntdsutil, tapez le mot de passe de la gestion des dsrm.
3. À l’invite de commandes DSRM, tapez l’une des lignes suivantes :
Pour réinitialiser le mot de passe sur le serveur sur lequel vous travaillez, tapez réinitialiser le mot
de passe sur le serveur null. La variable null suppose que le mot de passe DSRM est réinitialisé sur
l’ordinateur local. Tapez le nouveau mot de passe lorsque vous y êtes invité. Notez qu’aucun
caractère n’apparaît lorsque vous tapez le mot de passe.
ou -
Pour réinitialiser le mot de passe d’un autre serveur, tapez réinitialiser le mot de passe sur
ser vername _, où _ servername** est le nom DNS du serveur sur lequel vous réinitialisez le mot
de passe DSRM. Tapez le nouveau mot de passe lorsque vous y êtes invité. Notez qu’aucun
caractère n’apparaît lorsque vous tapez le mot de passe.
4. À l’invite de commandes DSRM, tapez q.
5. À l’invite de commandes Ntdsutil, tapez q pour quitter.
Fantômes, tombstones et le maître d’infrastructure
Cet article décrit comment les fantômes sont utilisés dans Windows Server.
Les objets fantômes sont des objets de base de données de bas niveau qu’Active Directory utilise pour les
opérations de gestion interne. Deux instances courantes d’objets fantômes sont les suivantes :
Objet qui a été supprimé.
La durée de vie de tombstone est passée, mais les références à l’objet sont toujours présentes dans la
base de données d’annuaire.
Un groupe local de domaine a un utilisateur membre d’un autre domaine dans la forêt Active Directory.
Les objets fantômes sont des types spéciaux d’objets de suivi de base de données internes et ne peuvent
pas être vus via LDAP ou ADSI (Active Directory Service Interfaces).
Suppression d’objet
Lorsqu’un objet est supprimé du répertoire actif, il suit le processus suivant.
Étape 1 : Objets normaux
L’objet existe tout d’abord en tant qu’objet Active Directory classique. Vous pouvez afficher l’objet à l’aide d’Active
Directory approprié et via l’interface LDAP.
L’objet passe à l’étape 2 lorsque l’objet est supprimé par un administrateur ou par un autre moyen.
Étape 2 : Objets supprimés avant l’expiration de la durée de vie de tombstone
L’objet existe désormais en tant qu’objet Tombstone pour la longueur de l’intervalle de durée de vie de
tombstone. Bien que l’objet conserve une partie de sa forme d’origine :
L’objet est toujours un objet classique (non fantôme).
L’attribut objectGUID n’a pas changé.
L’objet a également été considérablement modifié par rapport à sa forme d’origine :
L’objet se déplace vers le conteneur DeletedObjects (sauf si l’objet est marqué comme un objet système
spécial)
L’attribut DN de l’objet contient (esc)DEL:GUID
La plupart des autres attributs de l’objet ont été complètement supprimés.
Le schéma de l’objet détermine les attributs qui sont supprimés et les attributs conservés après la suppression.
La désignation de chaque attribut pour une classe d’objet peut être modifiée.
Les objets ne sont pas visibles à partir des outils de gestion Active Directory normaux. Vous pouvez configurer
une interface LDAP de bas niveau comme LDP pour afficher ces objets.
L’objet passe à l’un des deux états possibles (étape 3 ou 4) lorsque la durée de vie de tombstone a expiré. La
durée de vie par défaut de tombstone est de 60 jours.
Étape 3 : l’objet (Normal) est supprimé complètement de la base de données Active Directory
S’il ne reste aucune référence à cet objet dans Active Directory, la ligne de la base de données est complètement
supprimée et il n’y a aucune trace de l’objet à gauche.
Étape 4 : (Les références externes existent toujours ) objet fantôme
S’il existe des références à cet objet qui restent dans Active Directory, l’objet lui-même est supprimé et un objet
fantôme est créé à sa place jusqu’à ce que ces références soient supprimées. Cet objet fantôme est supprimé
lorsque toutes les références à l’objet sont supprimées.
Vous ne pouvez pas afficher ces objets fantômes via une interface LDAP ou ADSI.
NOTE
Lors de la suppression du catalogue global d’un contrôleur de domaine, les objets en lecture seule qui sont supprimés du
catalogue global ne sont pas supprimés du processus de suppression. Elles sont immédiatement supprimées de la base de
données et les références à ces bases de données ne sont pas affectées.
Références entre domaines et rôle principal d’infrastructure

Certains types de groupes dans un domaine Active Directory peuvent contenir des comptes de domaines
fiables. Pour vous assurer que les noms de l’appartenance au groupe sont exacts, le GUID de l’objet utilisateur
est référencé dans l’appartenance au groupe. Lorsque les outils Active Directory affichent ces groupes qui ont
des utilisateurs de domaines étrangers, ils doivent être en mesure d’afficher le nom exact et actuel de
l’utilisateur étranger sans s’appuyer sur un contact immédiat avec un contrôleur de domaine pour le domaine
étranger ou un catalogue global.
Active Directory utilise un objet fantôme pour les références de groupe à utilisateur entre domaines sur des
contrôleurs de domaine qui ne sont pas des catalogues globaux. Cet objet fantôme est un type spécial d’objet
qui ne peut pas être vu via une interface LDAP.
Les enregistrements fantômes contiennent une quantité minimale d’informations pour laisser un contrôleur de
domaine faire référence à l’emplacement dans lequel l’objet d’origine existe. L’index des objets fantômes contient
les informations suivantes sur l’objet référencé croiséement :
Nom de l’objet
GUID d’objet
SID d’objet
Lors de l’ajout d’un membre d’un autre domaine à un groupe d’utilisateurs local, le contrôleur de domaine local
qui effectue l’ajout au groupe crée l’objet fantôme pour l’utilisateur distant.
Si vous modifiez le nom de l’utilisateur étranger ou supprimez l’utilisateur étranger, les fantômes doivent être
mis à jour ou supprimés dans le domaine du groupe de chaque contrôleur de domaine dans le domaine. Le
contrôleur de domaine qui détient le rôle de maître d’infrastructure (MI) pour le domaine du groupe gère les
mises à jour des objets fantômes.
Vous ne pouvez pas afficher ces objets fantômes via une interface LDAP ou ADSI.
Processus de mise à jour et de nettoyage fantômes
Si l’objet auquel un objet fantôme fait référence a été supprimé, l’objet fantôme doit être supprimé du domaine
local (nettoyé). Un objet fantôme doit également être mis à jour si le nom de l’objet d’origine change afin que la
liste d’appartenance au groupe ait une liste précise. Le contrôleur de domaine qui détient le rôle de messagerie
instantanée dans un domaine gère les deux opérations pour son domaine.
La messagerie instantanée compare les informations sur les objets fantômes aux versions les plus récentes sur
un serveur de catalogue global et modifie les fantômes selon les besoins. L’intervalle peut être personnalisé en
ajoutant l’entrée de Registre Jours par analyse fantôme de base de données à la sous-clé de Registre suivante :
Pour effectuer cette modification, notez les remarques suivantes :

Entrée de Registre : jours par analyse du fantôme de base de données
Type : DWORD
Fonction : spécifie l’intervalle en jours entre la messagerie instantanée et les objets fantômes par rapport
aux versions les plus récentes sur un serveur de catalogue global.
NOTE
La valeur DWORD minimale est 1 jour.
Une fois que la messagerie instantanée a identifié que l’objet d’origine référent à l’objet fantôme a été modifié ou
supprimé :
La messagerie instantanée crée un objet infrastructureUpdate dans
CN=Infrastructure,DC=DomainName,DC=... et le supprime immédiatement.
Cet objet (tombstone) est répliqué par un proxy spécial vers les autres contrôleurs de domaine du
domaine qui ne sont pas des serveurs de catalogue global.
Si l’objet d’origine est renommé, la valeur dans l’attribut DNReferenceUpdate de l’infrastructureUpdate
contient le nouveau nom. Si l’objet d’origine a été supprimé, le nom DN des objets supprimés est modifié
de sorte que (esc)DEL:GUID soit appendé au nom DN d’origine.
Les contrôleurs de domaine prennent ensuite les informations dans les objets infrastructureUpdate et
appliquent les modifications aux copies locales de leurs objets fantômes en conséquence.
Si l’objet d’origine a été supprimé, les contrôleurs de domaine de réception suppriment l’objet fantôme local et
suppriment l’attribut correspondant qui le référence (par exemple, l’attribut membre d’un groupe).
NOTE
Les serveurs de catalogue global dans le domaine du groupe reçoivent la réplication de proxy spéciale pour les objets
dans CN=Infrastructure,DC=DomainName,DC=... conteneur. Toutefois, ils les ignorent car une copie en lecture seule de
l’objet lui-même est déjà ins instantiée dans la base de données locale. Il n’a donc pas besoin du fantôme pour suivre
l’appartenance au groupe et découvrira la suppression de l’objet avec la réplication AD régulière.
Conflit de rôle principal de catalogue global et d’infrastructure

Si le titulaire du rôle FSMO (Im Flexible Single Master Operation) est également un serveur de catalogue global,
les index fantômes ne sont jamais créés ou mis à jour sur ce contrôleur de domaine. (Le FSMO est également
appelé maître des opérations.) Ce comportement se produit car un serveur de catalogue global contient un
réplica partiel de chaque objet dans Active Directory. La messagerie instantanée ne stocke pas les versions
fantômes des objets étrangers, car elle possède déjà un réplica partiel de l’objet dans le catalogue global local.
Pour que ce processus fonctionne correctement dans un environnement multidomaine, le titulaire du rôle FSMO
d’infrastructure ne peut pas être un serveur de catalogue global. N’ignorez pas que le premier domaine de la
forêt contient les cinq rôles FSMO et qu’il s’agit également d’un catalogue global. Par conséquent, vous devez
transférer l’un des rôles vers un autre ordinateur dès qu’un autre contrôleur de domaine est installé dans le
domaine si vous prévoyez d’avoir plusieurs domaines.
Si le rôle FSMO d’infrastructure et le rôle catalogue global résident sur le même contrôleur de domaine, vous
recevez continuellement l’ID d’événement 1419 dans le journal des événements des services d’annuaire.
Le fait de placer le rôle Maître d’infrastructure sur un catalogue global est acceptable pour deux conditions :
1. Tous les contrôleurs de domaine dans le domaine sont des catalogues globaux. Dans ce cas, il ne peut y avoir
aucun fantôme à nettoyer.
2. Le mode forêt est « Windows Server 2008 R2 » et la fonctionnalité Corbeille est activée. Dans ce mode, les
liaisons d’objets supprimées ne sont pas fantômes, mais définies à un autre état et sont toujours présentes
dans la base de données.
Pour plus d’informations sur la Corbeille AD, voir : Scenario Overview for Restoring Deleted Active Directory
Objects
Pour plus d’informations sur l’emplacement du rôle FSMO dans le domaine et sur la façon de transférer un rôle
FSMO vers un autre contrôleur de domaine, cliquez sur les numéros d’article suivants pour consulter les articles
de la Base de connaissances Microsoft :
223346 optimisation et placement FSMO sur les contrôleurs de domaine Active Directory
223787 de transfert et de crise de l’opération maître unique flexible
Informations sur les appareils de la technologie
Riverbed configurés en tant que rodcs
Cet article décrit les informations sur les appareils de la technologie Riverbed configurés en tant que rodcs.
Résumé
Microsoft offre un support commercial raisonnable pour ses logiciels. Si nous ne pouvons pas résoudre le
problème d’un client lorsque des logiciels tiers sont impliqués, nous demanderons l’intervention du fournisseur
tiers. Selon le scénario, le support Microsoft peut demander au client de supprimer ou reconfigurer le
composant de la configuration pour voir si le problème persiste. Si le problème est confirmé comme causé ou
fortement influencé par le composant tiers, le fournisseur du composant doit être impliqué dans la résolution
du problème. Cette stratégie s’applique également aux appareils de Riverbed Technology, Inc.
Riverbed Technology, Inc. met en place des périphériques réseau intermédiaires qui visent à optimiser le réseau
de trafic réseau en compressant et en façonnant autrement le trafic qui circule sur des connexions WAN
chargées.
Les appareils peuvent intercepter les sessions SMB de l’utilisateur final et obtenir des gains de performances si
l’appareil Riverbed peut générer une base de contrôle signée valide de la charge utile dans le contexte de
sécurité du serveur. Pour ce faire, l’appareil se définit en tant qu’instance de serveur approuvé afin qu’il puisse
agir comme, et pour un serveur qui se limite au trafic réseau en cours d’optimisation.
L’approche de déploiement actuelle (septembre 2016) implique l’activation des paramètres De contrôleur de
domaine en lecture seule (RODC) UserAccountControl sur un compte d’ordinateur normal ; ou à l’aide d’un
compte de service hautement privilégié qui dispose de l’autorisation Répliquer toutes les modifications de
répertoire. Dans certaines configurations, les deux types de comptes seront utilisés. Cette approche a un certain
nombre de conséquences sur la sécurité, qui peuvent ne pas être évidentes au moment de la configuration.
Attentes
Lorsqu’un compte d’ordinateur est installé en tant que contrôleur de domaine, il reçoit certains indicateurs et
appartenances aux groupes qui lui permettent d’effectuer des procédures de sécurité et spécifiques à Active
Directory. Il s’agit notamment des éléments suivants :
Le compte peut usurper l’identité de n’importe quel utilisateur dans Active Directory, sauf ceux qui sont
marqués comme « sensibles et non autorisés pour la délégation ». En raison de la transition du protocole
Kerberos, le compte peut le faire même sans avoir le mot de passe pour les utilisateurs autorisés à usurper
l’identité.
L’autorisation « Répliquer tous les changements de répertoire » permet à l’appareil d’accéder aux hages de
mot de passe de tous les utilisateurs du domaine, y compris les comptes sensibles tels que KrbTgt, les
comptes contrôleur de domaine et les relations d’confiance.
Le compte peut être suivi en tant que contrôleur de domaine par les solutions de surveillance.
En fonction de l’existence de ces indicateurs, les « appelants » (y compris les outils d’administration)
attendent un serveur Windows et tentent d’accéder aux entités qui se représentent elles-mêmes en tant que
contrôleurs de domaine ou d’interopérer avec elles-mêmes. Cela inclut les services basés sur WMI, WinRM,
LDAP, RPC et les services Web Active Directory. De même, les applications, les ordinateurs membres et les
contrôleurs de domaine partenaires s’attendent à ce que les entités qui se représentent en tant que
contrôleurs de domaine interagissent et répondent de manière cohérente et bien définie.
Implications en matière de sécurité

Comme pour tout autre périphérique informatique dans un environnement réseau, les appareils Riverbed
peuvent faire l’objet d’attaques par des programmes malveillants. En raison de leur capacité à usurper l’identité
des utilisateurs Active Directory, les appareils Riverbed sont des cibles attrayantes pour de telles attaques.
Microsoft recommande vivement d’utiliser le même niveau de protection physique et réseau et d’audit que vous
utilisez pour vos contrôleurs de domaine Read-Write (RWDCs). L’administration de ces appareils doit suivre les
instructions actuelles concernant la sécurisation de l’accès privilégié lors de la sécurisation de l’accès privilégié.
Si vous utilisez actuellement des appareils Riverbed dans des emplacements qui ne sont pas suffisamment
sécurisés pour les RWDCs, nous vous recommandons vivement de passer en revue l’emplacement de ces
appareils.
Implications opérationnelles
Les contrôleurs de domaine ont un indicateur spécial et des objets supplémentaires associés à leurs comptes qui
fournissent une identification de rôle unique. Elle comprennent notamment :
Valeurs UserAccountControl sur le compte d’ordinateur du contrôleur de domaine
RWDC 0x82000 (Hex)
RODC 0x5011000 (Hex)
NTDS Paramètres dans le conteneur de configuration, dans le site du contrôleur de domaine
Les outils, les services et les applications peuvent interroger ces attributs pour générer une liste de contrôleurs
de domaine, puis effectuer une opération, telle que la requête, qui suppose une réponse DC normale. Les
appareils Riverbed n’implémentent pas l’ensemble complet Windows services de contrôleur de domaine et ne
répondent pas aux requêtes DC normales. Microsoft est conscient des problèmes suivants causés par cette
configuration :
Migration de la réplication sysvol du service de réplication de fichiers (FRS) vers la réplication du système
de fichiers distribués (DFSR)
Lorsqu’un domaine a été transitioné vers le mode de domaine Windows Server 2008 ou une date
ultérieure, Microsoft recommande de migrer le moteur de réplication sysvol de FRS vers DFSR.
L’outil de migration DFSR (dfsrMig.exe) crée un inventaire de tous les contrôleurs de domaine dans le
domaine au début de la migration. Cela inclut les comptes de dc utilisés par les appareils Riverbed. Les
appareils Riverbed ne répondent pas aux modifications apportées aux objets Active Directory nécessaires
à la progression de la migration. L’outil de migration DFSR ne parvient donc pas à se terminer et les
administrateurs doivent ignorer les erreurs pour passer à l’étape suivante de la migration sysvol. Ces
erreurs fausses peuvent se chevaucher avec des erreurs réelles provenant Windows ordinateurs basés
sur un serveur.
Étant donné que la migration sysvol ne peut pas être effectuée lorsqu’il existe un appareil Riverbed dans
le domaine, Microsoft recommande de supprimer les appareils Riverbed lors d’une migration.
Outils de surveillance
La plupart des outils d’analyse de serveur sur le marché utilisent des requêtes Active Directory pour
remplir un inventaire des systèmes clients et serveur. Les outils qui exploitent l’objet UserAccountControl
ou NTDS Setting pour rechercher des contrôleurs de domaine peuvent identifier de manière incorrecte
les comptes Riverbed en tant que comptes de contrôleur de domaine. Par conséquent, les appareils
Riverbed apparaissent comme des serveurs gérables dans cette liste d’inventaire.
De nombreuses solutions autorisent ensuite le déploiement à distance d’agents de surveillance ou vous
permettent d’interroger l’appareil à distance pour obtenir des informations de diagnostic. Toutefois, les
appareils Riverbed ne les prisent pas en charge, et les outils de surveillance les signalent comme
déclenchant des échecs.
Contactez Riverbed pour plus d’informations sur la surveillance des appareils Riverbed par le biais de
l’outil de surveillance de votre choix. Si aucun outil de surveillance n’est disponible, étudiez l’option
d’exclusion de l’appareil de la surveillance. Microsoft recommande vivement de surveiller l’état de
l’appareil, en fonction de la sensibilité des fonctions exécutées par ces appareils.
Outil d’administration des stratégies de groupe (GPMC)
Dans Windows Server 2012 versions ultérieures, la GPMC peut afficher l’état de réplication des
paramètres de stratégie de groupe dans le domaine ou par stratégie. Les appareils Riverbed sont inclus
dans la liste des comptes éligibles pour cette vérification d’état.
Toutefois, les informations renvoyées à gpMC par Riverbed sont incomplètes, car elles n’ont pas d’objet
Paramètres NTDS dans la partition de configuration Active Directory. Étant donné que la console GPMC
ne s’attend pas à cela, la console GPMC se crashe.
Pour éviter cet échec, déployez la mise à jour suivante sur vos ordinateurs d’administration :
La console de gestion des stratégies de groupe se crashe lorsque vous cliquez sur le domaine cible
produits.
Comment laisser les non-administrateurs afficher le
conteneur d’objets supprimés Active Directory
Cet article explique comment modifier les autorisations afin que les non-administrateurs peuvent afficher le
conteneur d’objets supprimés Active Directory.
Résumé
Lorsqu’un objet Active Directory est supprimé, une petite partie de l’objet reste dans le conteneur d’objets
supprimés pendant une durée spécifiée. Il reste là pour que les autres contrôleurs de domaine qui répliquent les
modifications soient informés de la suppression. Par défaut, seuls le compte Système et les membres du groupe
Administrateurs peuvent afficher le contenu de ce conteneur. Cet article explique comment modifier les
autorisations sur le conteneur d’objets supprimés.
Vous de devez peut-être modifier les autorisations sur le conteneur d’objets supprimés si les conditions
suivantes sont vraies :
Vous avez des applications ou des services d’entreprise qui se lient à Active Directory avec un compte non-
système ou un compte non-administrateur.
Ces applications ou services d’entreprise recherchent les modifications d’annuaire.
Pour modifier les autorisations sur le conteneur d’objets supprimés afin que les non-administrateurs peuvent
afficher ce conteneur, utilisez DSACLS.exe programme. Le DSACLS.exe est inclus dans les outils d’administration
ADAM (Active Directory Application Mode).
Pour Windows Server 2008 et les plus nouveaux, l’outil est inclus dans le système d’exploitation.
Pour Windows 2000 et Server 2003, vous pouvez le faire en obtenant et en installant les outils d’administration
ADAM, suivez les étapes suivantes :
1. Téléchargez le package de vente au détail ADAM.
Pour plus d’informations sur le téléchargement des fichiers du Support Microsoft, cliquez sur le numéro
d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :
119591 comment obtenir des fichiers de support Microsoft à partir des services en ligne Microsoft a
analysé ce fichier pour y trouver des virus. Microsoft a utilisé le logiciel de détection de virus le plus
NOTE
Cette version des outils d’administration ADAM est une mise à niveau à partir de la version des outils de support
Windows Server 2003. Cette version des outils d’administration ADAM est prise en charge par Microsoft Windows
Server 2003, Édition Standard; Microsoft Windows Server 2003, Êdition Entreprise; Microsoft Windows Server
2003, Datacenter Edition ; et Microsoft Windows XP Professional.
2. Pour extraire le contenu du fichier que vous avez téléchargé à l’étape 1, double-cliquez sur le fichier, puis
spécifiez un répertoire lorsque vous y êtes invité.
3. Dans le répertoire où vous avez extrait le fichier à l’étape 2, double-cliquez sur le programme pour
démarrer l’Assistant Installation du mode d’application Active Directory, puis cliquez sur Adamsetup.exe
Suivant.
4. Lisez et acceptez les termes de la licence, puis cliquez sur Suivant .
5. Sélectionnez uniquement les outils d’administration ADAM, puis cliquez sur Suivant.
6. Examinez vos sélections, puis cliquez sur Suivant.
7. Une fois le programme d’installation terminé, cliquez sur Terminer.
Après avoir installé les outils d’administration ADAM, vous pouvez modifier les autorisations sur le conteneur
d’objets supprimés. Pour cela, procédez comme suit :
1. Connectez-vous avec un compte d’utilisateur membre du groupe Administrateurs du domaine.
2. Cliquez sur Démarrer, pointez sur Tous les programmes, pointez sur ADAM, puis cliquez sur Invite de
commandes des outils ADAM.
3. À l’invite de commandes, tapez une commande semblable à l’exemple suivant : dsacls « CN=Objets
supprimés,DC=Contoso,DC=com » /takeownership.
Lorsque vous tapez cette commande, utilisez le nom du conteneur d’objets supprimés pour votre
domaine.
Chaque domaine de la forêt aura son propre conteneur d’objets supprimés. La sortie semblable à
l’exemple suivant doit être affichée :
Propriétaire : Contoso\Domain Admins

Groupe : AUTORITÉ NT\SYSTÈME
Liste d’accès :
{Cet objet est protégé contre l’héritage des autorisations du parent}
Autoriser BUILTIN\Administrators SPECIAL ACCESS
CONTENU DE LISTE
READ, PROPRIÉTÉ
Autoriser L’AUTORITÉ NT\ACCÈS SPÉCIAL AU SYSTÈME
DELETE
READ PERMISSONS
AUTORISATIONS D’ÉCRITURE
MODIFIER LA PROPRIÉTÉ
CRÉER UN ENFANT
SUPPRIMER UN ENFANT
CONTENU DE LISTE
ÉCRIRE AUTO
WRITE, PROPRIÉTÉ
READ, PROPRIÉTÉ
4. Pour accorder à un principal de sécurité l’autorisation d’afficher les objets dans le conteneur d’objets
supprimés, tapez une commande semblable à l’exemple suivant : dsacls « CN=Objets
supprimés,DC=Contoso,DC=com » /g CONTOSO\EricLang:LCRP
La sortie semblable à l’exemple suivant doit être affichée :
Propriétaire : CONTOSO\Domain Admins
Groupe : AUTORITÉ NT\SYSTÈME
Liste d’accès :
{Cet objet est protégé contre l’héritage des autorisations du parent}
Autoriser BUILTIN\Administrators SPECIAL ACCESS
CONTENU DE LISTE
READ, PROPRIÉTÉ
Autoriser L’AUTORITÉ NT\ACCÈS SPÉCIAL AU SYSTÈME
DELETE
READ PERMISSONS
AUTORISATIONS D’ÉCRITURE
MODIFIER LA PROPRIÉTÉ
CRÉER UN ENFANT
SUPPRIMER UN ENFANT
CONTENU DE LISTE
ÉCRIRE AUTO
WRITE, PROPRIÉTÉ
READ, PROPRIÉTÉ
Autoriser CONTOSO\EricLang SPECIAL ACCESS
CONTENU DE LISTE
READ, PROPRIÉTÉ
Dans cet exemple, l’utilisateur « CONTOSO\EricLang » a reçu les autorisations Contenu de liste et Propriété de
lecture sur le conteneur d’objets supprimés dans le domaine « CONTOSO ». Ces autorisations autorisent cet
utilisateur à afficher le contenu du conteneur d’objets supprimés, mais ne l’autorisent pas à apporter des
modifications aux objets dans le conteneur. Ces autorisations sont équivalentes aux autorisations par défaut
accordées au groupe Administrateurs. Par défaut, seul le compte système est autorisé à modifier des objets dans
le conteneur d’objets supprimés.
Les comptes Linux ne peuvent pas obtenir de tickets
chiffrés AES dans AD DS
Symptômes
Dans un environnement AD DS (Active Directory Domain Services), les comptes intégrés à Linux reçoivent des
tickets chiffrés RC4 au lieu de tickets chiffrés AES (Advanced Encryption Standard) lorsqu’ils utilisent
l’authentification Kerberos. Pour résoudre ce problème, go to the Key Distribution Center (KDC).
Dans le journal de l’ID d’événement 4769, la valeur du type de chiffrement de ticket est 0x17 pour
l’ordinateur concerné. Cela correspond à un type de chiffrement RC4.
Source: Microsoft-Windows-Security-Auditing
Event ID: 4769
Task Category: Kerberos Service Ticket Operations
Level: Information
Computer: MyDC.contoso.com
Description:
A Kerberos service ticket was requested.
…
Service Information:
Service Name: MYLINUX
Service ID: CONTOSO\MYLINUX
Network Information:
Client Address: ::ffff:10.20.30.40
Client Port: 57499
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Failure Code: 0x0
Transited Services: -
Après avoir exécuté la commande, la valeur du type de chiffrement klist KerbTicket est RSADSI RC4-
HMAC(NT) . Cela indique que le type de chiffrement est RC4.
C:\> Klist get MYLINUX@CONTOSO.COM

Current LogonId is 0:0xb532bccf
A ticket to MYLINUX@CONTOSO.COM has been retrieved successfully.
Cached Tickets: (2)
…
#1> Client: MyUser@CONTOSO.COM
Server: MYLINUX@CONTOSO.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: <DateTime> (local)
End Time: <DateTime> (local)
Renew Time: <DateTime> (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: MyDC.Contoso.com
NOTE
La définition de la valeur d’attribut msDS-Suppor tedEncr yptionTypes sur 24 (0x18) pour forcer le chiffrement AES256
ou AES128 ne résout pas le problème. De même, la désactivation du chiffrement RC4 et l’activation du chiffrement AES à
l’aide de la sécurité réseau : la configuration des types de chiffrement autorisés pour l’objet de stratégie de groupe
Kerberos ne résout pas le problème.
Cause
This issue occurs because the operatingSystemVersion attribute value of Linux is set to 3.10.0x. AD DS lit la
valeur d’attribut de gauche à droite, en s’arrêtant au premier point décimal (.) Si le premier caractère de la valeur
est un chiffre et que la valeur est inférieure à six, le KDC détermine que le système d’exploitation demandeur
risque de ne pas prise en charge des types de chiffrement plus nouveaux. Dans ce cas, la valeur est 3. Par
conséquent, le KDC ignore msDS-Suppor tedEncr yptionTypes et utilise RC4 pour chiffrer le ticket.
Ce comportement est inhérent au produit. Il s’agit des versions antérieures de Windows (notamment Windows
2000 Server, Windows Server 2003 et Windows XP) qui ne prendre en charge ni l’attribut msDS-
Suppor tedEncr yptionTypes, ni le type de chiffrement AES. Les spécifications suivantes décrivent cette
conception :
Si le serveur ou le service possède un attribut KerbSuppor tedEncr yptionTypes rempli à l’aide des
types de chiffrement pris en charge <58>, le KDC doit< 59> retourner dans la partie chiffrée
([Références-11] Annexe A) du message TGS-REP, structure PA-DATA dont le type padata est définie
sur PA-SUPPORTED-ENCTYPES [165] pour indiquer les types de chiffrement (section 2.2.7 ) sont pris
en charge par le serveur ou le service. Si ce n’est pas le cas, le KDC doit< 60> l’indicateur UseDESOnly
du serveur ou du compte de service.
<58> Section 3.3.5.7 : si le compte est pour un objet ordinateur et que la valeur de
OperatingSystemVersion (section [MS-ADA3] section 2.56) est inférieure à 6,
KerbSuppor tedEncr yptionTypes est traité comme s’il n’était pas rempli. Cette approche permet de
s’assurer que les nouveaux types de chiffrement ne sont pas tentés si l’ordinateur demandeur exécute
Windows 2000, Windows XP ou Windows Server 2003. Ces systèmes ne sont pas pris en charge par la
définition de KerbSuppor tedEncr yptionTypes .
Pour plus d’informations, voir les spécifications des Exchange TGS et de l’annexe A <58> des extensions de
protocole Kerberos.
Solution
Supprimez l’attribut operatingSystemVersion.
Définissez la valeur d’attribut de sorte que le premier caractère ne soit pas un chiffre numérique. Par
exemple, définissez la valeur sur Linux 3.10.0x au lieu de 3.10.0x.
Mettre à niveau vers une version système mise à jour conforme aux spécifications. Obtenez la mise à jour
auprès du fournisseur tiers (par exemple, Linux).
Pour plus d’informations sur la façon dont le KDC sélectionne le type de chiffrement, voir Encryption Type
Selection in Kerberos Exchanges.
Comment modifier les propriétés filtrées d’un objet
dans l’éditeur ACL pour les objets des services
d’annuaire
Cet article explique comment modifier les propriétés filtrées d’un objet dans l’éditeur ACL pour les objets des
services d’annuaire.
Résumé
L’onglet Autorisations par propriété pour un objet utilisateur que vous affichez via Utilisateurs et ordinateurs
Active Directory peut ne pas afficher toutes les propriétés de l’objet utilisateur. Cela est dû au fait que l’interface
utilisateur du contrôle d’accès filtre les types d’objets et de propriétés pour faciliter la gestion de la liste. Bien que
les propriétés d’un objet soient définies dans le schéma, la liste des propriétés filtrées affichées est stockée dans
le fichier Dssec.dat qui se trouve dans le dossier %systemroot%\System32 sur tous les contrôleurs de domaine.
Vous pouvez modifier les entrées d’un objet dans le fichier pour afficher les propriétés filtrées via l’interface
utilisateur.
Propriétés filtrées dans le fichier Dssec.dat

Une propriété filtrée ressemble à ceci dans le fichier Dssec.dat :
[Utilisateur]
propertyname=7
Pour afficher les autorisations de lecture et d’écriture pour une propriété d’un objet, vous pouvez modifier la
valeur de filtre pour afficher l’une des autorisations ou les deux. Pour afficher les autorisations de lecture et
d’écriture pour une propriété, modifiez la valeur sur zéro (0) :
[Utilisateur]
propertyname=0
Pour afficher uniquement l’autorisation d’écriture pour une propriété, modifiez la valeur sur 1 :
[Utilisateur]
propertyname=1
Pour afficher uniquement les autorisations de lecture d’une propriété, modifiez la valeur sur 2 :
[Utilisateur]
propertyname=2
NOTE
Après avoir modifié le fichier Dssec.dat, vous devez quitter et redémarrer Utilisateurs et ordinateurs Active Directory pour
voir les propriétés qui ne sont plus filtrées.
NOTE
L’éditeur ACL appelé par ADSIEdit semble ignorer le contenu de DSSEC. DAT et affiche tous les attributs par défaut.
Windows 7 RSAT : plusieurs onglets sont manquants
lors de l’affichage des propriétés utilisateur dans
Cet article fournit une solution à un problème où plusieurs onglets sont manquants lorsque vous affichez les
propriétés utilisateur dans Utilisateurs et ordinateurs Active Directory.
S’applique à : Windows 7 Service Pack 1
Symptômes
Après avoir installé les outils d’administration de serveur distant pour Windows 7 (Windows 7 RSAT) sur un
client Windows 7 joint au domaine, vous ajoutez les outils d’administration des rôles pour « AD DS Snap-ins and
Command-line Tools » :
Vous démarrez ensuite le logiciel en ligne Utilisateurs et ordinateurs Active Directory (DSA). MSC) et
examine les propriétés d’un utilisateur. Vous remarquez que tout ou partie des onglets suivants sont manquants
: Published Certificates Password Replication Object Attribute Editor Environment Sessions Remote Control
Remote Desktop Services Profile Personal Virtual Desktop UNIX Attributes Dial-in These tabs are visible when
running DSA. MSC sur la console des serveurs Windows Server 2008 R2.
Cause
Plusieurs causes racines existent. Pour plus d’informations, voir la section Résolution.
Résolution
1. Activez « Fonctionnalités avancées » via le menu Affichage. Cela affichera au moins les nouveaux onglets
suivants :
Certificats publiés
Réplication de mot de passe
Objet
Sécurité
Éditeur d’attributs
2. Si vous ne voyez toujours pas les onglets « Environnement », « Sessions », « Contrôle à distance », «
Bureau virtuel personnel » et « Profil des services Bureau à distance », ajoutez la fonctionnalité RSAT
suivante : « Outils des services Bureau à distance ». Redémarrez ensuite DSA. MSC et activez l’affichage
avancé pour faire apparaître ces onglets.
3. Si l’onglet « Attributs UNIX » n’est toujours pas présent, ajoutez la fonctionnalité RSAT suivante : « Serveur
pour les outils NIS ». Redémarrez DSA. MSC avec affichage avancé activé pour faire apparaître cet onglet.
4. L’onglet « Numérotation » est toujours manquant, car ses bibliothèques ne sont pas incluses dans les
outils d’administration de serveur distant pour Windows 7.
Conventions d'affectation de noms dans Active
Directory pour les ordinateurs, les domaines, les
sites et les unités d'organisation
Cet article décrit les conventions d’affectation de noms pour les comptes d’ordinateur dans Windows, les noms
de domaine NetBIOS, les noms de domaine DNS, les sites Active Directory et les unités d’organisation définies
dans le service d’annuaire Active Directory.
Résumé
Cet article s’articule autour des rubriques suivantes :
Caractères valides pour les noms
Longueurs de nom minimale et maximale
Noms réservés
Noms dont l’utilisation n’est pas recommandée
Recommandations générales basées sur la prise en charge d’Active Directory dans les déploiements de petite
taille, de taille moyenne et de grande taille
Tous les objets nommés dans Active Directory ou dans AD/AM et LDS font l’objet d’une correspondance de
noms basée sur l’algorithme décrit dans l’article suivant :
Impossible d’ajouter un nom d’utilisateur ou un nom d’objet qui ne diffère que d’un caractère avec un signe
diacritique.
Dans cet article, cette convention d’affectation de noms s’applique aux noms des ordinateurs, des unités
d’organisation et des sites.
Noms d'ordinateur
Noms d'ordinateur NetBIOS
Caractères autorisés
Les noms d’ordinateur NetBIOS peuvent contenir tous les caractères alphanumériques, à l’exception des
caractères étendus répertoriés dans la section Caractères non autorisés . Les noms peuvent contenir
un point, mais il ne peut pas s’agir du premier caractère.
Caractères non autorisés
Les noms d’ordinateur NetBIOS ne peuvent pas contenir les caractères suivants :
Barre oblique inverse (\)
Barre oblique (/)
Deux-points (:)
Astérisque (*)
Point d'interrogation (?)
Guillemet (")
Signe inférieur à (<)
Signe supérieur à (>)
Barre verticale (|)
Les noms peuvent contenir un point (.). Mais un nom ne peut pas commencer par un point.
L'utilisation de noms non-DNS avec des points est autorisée dans Microsoft Windows NT. Les
points ne doivent pas être utilisés dans Microsoft Windows 2000 ou dans les versions ultérieures
de Windows. Si vous effectuez une mise à niveau d’un ordinateur dont le nom NetBIOS contient
un point, modifiez le nom de l’ordinateur. Pour plus d’informations, consultez Caractères
spéciaux .
Dans Windows 2000 et les versions ultérieures de Windows, le nom d’un ordinateur qui est
membre d’un domaine Active Directory ne peut pas être constitué exclusivement de chiffres. Cette
restriction est liée aux restrictions DNS.
Pour plus d’informations sur la syntaxe des noms NetBIOS, consultez Syntaxe des noms NetBIOS.
Longueur de nom minimale : 1 caractère
Longueur de nom maximale : 15 caractères
NOTE
Le 16e caractère est réservé à l’identification de la fonctionnalité installée sur le périphérique réseau inscrit.
Noms réservés
Voir Tableau des mots réservés.
Caractères spéciaux : Point (.)
Le point divise le nom entre un identificateur d'étendue NetBIOS et le nom de l'ordinateur. L'identificateur
d'étendue NetBIOS est une chaîne facultative de caractères qui identifient les réseaux NetBIOS logiques
exécutés sur le même réseau TCP/IP physique. Pour que NetBIOS puisse fonctionner entre des
ordinateurs, ceux-ci doivent comporter le même identificateur d'étendue NetBIOS et des noms
d'ordinateur uniques.
L’utilisation d’étendues NetBIOS dans les noms correspond à une configuration héritée. Cela doit être
évité avec les forêts Active Directory. Pour plus d’informations sur les étendues NetBIOS, reportez-vous
aux sites web suivants :
rfc1001
rfc1002
Noms d'hôte DNS
Les noms DNS ne peuvent contenir que les caractères suivants : caractères alphanumériques (A-Z),
caractères numériques (0-9), signe moins (-) et point (.). Un point n'est autorisé que s'il sert à délimiter les
composants des noms de style de domaine.
Dans les systèmes de noms de domaine (DNS) Windows 2000 et Microsoft Windows Server 2003, les
caractères Unicode sont pris en charge. Les autres implémentations de DNS ne prennent pas en charge
les caractères Unicode. Évitez les caractères Unicode si les requêtes sont transmises aux serveurs qui
utilisent des implémentations non-Microsoft de DNS.
Pour plus d’informations, visitez les sites web suivants :
rfc952
rfc1123
Les noms d’hôte DNS ne peuvent pas contenir les caractères suivants :
Virgule (,)
Tilde (~)
Deux-points (:)
Point d'exclamation (!)
Arobase (@)
Signe dièse (#)
Symbole dollar ($)
Symbole pour cent (%)
Accent circonflexe (^)
Esperluette (&)
Apostrophe (')
Point (.)
Parenthèses (())
accolades ({})
trait de soulignement (_),
Espace blanc (espace)
Le trait de soulignement a un rôle spécial. Il est autorisé comme premier caractère dans les
enregistrements SRV selon la définition RFC. Toutefois, les serveurs DNS plus récents peuvent
également l’autoriser n’importe où dans un nom. Pour plus d’informations, consultez la section
Respect des restrictions de noms pour les hôtes et les domaines.
Règles supplémentaires :
Tous les caractères conservent leur casse, sauf les caractères ASCII (American Standard Code for
Information Interchange).
Le premier caractère doit être alphabétique ou numérique.
Le dernier caractère ne doit pas être un signe moins ou un point.
Les chaînes utilisateur SDDL à 2 caractères répertoriées dans la liste des SID bien connus ne
peuvent pas être utilisées. Autrement, les opérations Import, Export, et Prise de contrôle échouent.
NOTE
L’enregistrement de nom d’hôte DNS remplace les caractères non valides par un trait d’union (-).
Longueur de nom minimale : 2 caractères

La longueur maximale du nom d'hôte et du nom de domaine complet (FQDN) est de 63 octets par partie
et de 255 octets par FQDN.
NOTE
Windows n’autorise pas les noms d’ordinateur dépassant 15 caractères et vous ne pouvez pas spécifier un nom
d’hôte DNS différant du nom d’hôte NetBIOS. Vous pouvez toutefois créer des en-têtes d'hôtes pour un site web
hébergé sur un ordinateur faisant l'objet de cette recommandation.
Dans Windows 2000 et Windows Server 2003, le nom d’hôte maximum et le FQDN utilisent les limites
de longueur standard mentionnées plus haut, avec la prise en charge UTF-8 (Unicode). Étant donné que
certains caractères UTF-8 dépassent un octet de longueur, vous ne pouvez pas déterminer la taille en
comptant les caractères.
Les contrôleurs de domaine doivent avoir un FQDN de moins de 155 octets.
Noms réservés selon RFC 952
-GATEWAY
-GW
-TAC
Pour plus d’informations, consultez rfc952.
Noms réservés dans Windows
Bonnes pratiques
Lorsque vous créez des noms pour les ordinateurs DNS d'une nouvelle DNS Windows Server 2003,
appliquez les lignes directrices suivantes :
Choisissez des noms d'ordinateur que les utilisateurs peuvent facilement mémoriser.
Identifiez le propriétaire de l'ordinateur dans le nom d'ordinateur.
Choisissez un nom qui décrit l'usage prévu de l'ordinateur.
Pour les caractères ASCII, n’utilisez pas de casse pour indiquer le propriétaire ou l’usage d'un
ordinateur. Pour les caractères ASCII, DNS n’est pas sensible à la casse, notez que Windows et les
applications Windows ne conservent pas partout la casse.
Faites en sorte que le nom de domaine Active Directory corresponde au suffixe DNS principal du nom
de l'ordinateur. Pour plus d’informations, consultez la section Espaces de noms disjoints.
Utilisez un nom unique pour chaque ordinateur de votre organisation. Évitez d'utiliser un même nom
pour des ordinateurs situés dans des domaines DNS différents.
Utilisez des caractères ASCII afin de garantir l'interopérabilité avec les ordinateurs qui utilisent des
versions de Windows antérieures à Windows 2000.
Dans les noms d'ordinateur DNS, utilisez exclusivement les caractères répertoriés dans la norme
RFC 1123. Ces caractères incluent A-Z, a-z, 0-9 et le trait d’union (-). Dans Windows Server 2003, DNS
autorise la plupart des caractères UTF-8 dans les noms. Toutefois, n’utilisez des caractères ASCII ou
UTF-8 étendus que si tous les serveurs DNS de votre environnement les prennent en charge.
Noms de domaine
Voici les détails des noms de domaine NetBIOS et DNS.
Noms de domaine NetBIOS
Les noms de domaine NetBIOS peuvent contenir tous les caractères alphanumériques, à l’exception des
caractères étendus répertoriés dans la section Caractères non autorisés . Les noms peuvent contenir
un point, mais il ne peut pas s’agir du premier caractère.
Les noms d’ordinateur NetBIOS ne peuvent pas contenir les caractères suivants :
Barre oblique inverse (\)
Barre oblique (/)
Deux-points (:)
Astérisque (*)
Point d'interrogation (?)
Guillemet (")
Signe inférieur à (<)
Signe supérieur à (>)
Barre verticale (|)
Les noms peuvent contenir un point (.). Mais un nom ne peut pas commencer par un point.
L'utilisation de noms non-DNS avec des points est autorisée dans Microsoft Windows NT. Les
points ne doivent pas être utilisés dans les domaines Active Directory. Si vous effectuez une mise à
niveau d'un domaine dont le nom NetBIOS contient un point, modifiez le nom en migrant le
domaine vers une nouvelle structure de domaine. N'utilisez pas de points dans les nouveaux noms
de domaine NetBIOS.
Longueur de nom maximale : 15 caractères.
NOTE
Le 16e caractère est réservé à l’identification de la fonctionnalité installée sur le périphérique réseau inscrit.
Noms réservés dans Windows

Le nom d'un domaine mis à niveau peut inclure un mot réservé. Toutefois, dans ce cas, les relations
d’approbation avec les autres domaines échouent.
Caractères spéciaux : point (.).
Le point divise le nom entre un identificateur d'étendue NetBIOS et le nom de l'ordinateur. L'identificateur
d'étendue NetBIOS est une chaîne facultative de caractères qui identifient les réseaux NetBIOS logiques
exécutés sur le même réseau TCP/IP physique. Pour que NetBIOS puisse fonctionner entre des
ordinateurs, ceux-ci doivent comporter le même identificateur d'étendue NetBIOS et des noms
d'ordinateur uniques.
WARNING
L’utilisation d’étendues NetBIOS dans les noms correspond à une configuration héritée. Cela doit être évité avec
les forêts Active Directory. Cela ne pose aucun problème, mais certaines applications peuvent filtrer le nom et
supposer un nom DNS lorsqu'elles détectent un « point ».
Noms de domaine DNS

Pour plus d’informations, consultez les sites web suivants :
rfc952
rfc1123
Les noms de domaine DNS ne peuvent pas contenir les caractères suivants :
Virgule (,)
Tilde (~)
Deux-points (:)
Arobase (@)
Signe dièse (#)
Symbole dollar ($)
Esperluette (&)
Apostrophe (')
Point (.)
Parenthèses (())
accolades ({})
Le trait de soulignement a un rôle spécial. Il est autorisé pour le premier caractère des
enregistrements SRV par définition RFC. Toutefois, les serveurs DNS plus récents peuvent
Lors de la promotion d’un nouveau domaine, vous recevez un avertissement signalant qu’un trait
de soulignement risque de provoquer des problèmes avec certains serveurs DNS. Il vous permet
cependant de créer le domaine.
Tous les caractères conservent leur casse, sauf les caractères ASCII.
Longueur de nom minimale : 2 caractères
La longueur maximale du nom d’hôte et du nom de domaine complet (FQDN) est de 63 octets par partie
et de 255 caractères par FQDN. Ce dernier repose sur la longueur de chemin d’accès maximale possible
pour un nom de domaine Active Directory avec le chemin d’accès nécessaire dans SYSVOL , qui doit
respecter la limite MAX_PATH de 260 caractères.
Voici un exemple de chemin d’accès dans SYSVOL :
\\<FQDN domain name>\sysvol\<FQDN domain name>\policies\{<policy GUID>}\[user|machine]\<CSE-specific
path>
Le <CSE-specific path> peut contenir une entrée utilisateur telle que le nom de fichier du script
d’ouverture de session ; il peut dès lors aussi atteindre une longueur importante.
Le nom de domaine FQDN AD apparaît deux fois dans le chemin d’accès, car la longueur d’un nom de
domaine FQDN AD est limitée à 64 caractères.
Espaces de noms de domaine en une seule partie
Les noms DNS en une seule partie ne contiennent pas de suffixe tel que .com , .corp , .net , .org , ou
companyname . Par exemple, hôte est un nom DNS en une seule partie. La plupart des bureaux
d’enregistrement Internet n’autorisent pas l’enregistrement de noms DNS en une seule partie.
En général, nous vous conseillons d'enregistrer des noms DNS pour les espaces de noms internes et
externes auprès des bureaux d'enregistrement Internet. Cela inclut les noms DNS de domaines Active
Directory, à moins ces noms soient des sous-domaines de noms DNS qui sont enregistrés par votre nom
d'organisation. Par exemple, corp.example.com est un sous-domaine de example.com . L'enregistrement
de votre nom DNS auprès d'un bureau d'enregistrement Internet peut empêcher un conflit de noms, qui
peut se produire lorsque l’enregistrement d’un même domaine DNS est soumis par une autre
organisation, ou en cas de fusion de votre organisation avec une autre organisation utilisant le même
nom DNS.
Voici quelques problèmes liés aux espaces de noms en une seule partie :
Les noms DNS en une seule partie ne peuvent pas être enregistrés auprès de bureaux
d’enregistrement Internet.
Les domaines dont le nom DNS est en une seule partie nécessitent une configuration
supplémentaire.
Il est impossible d'utiliser le service Serveur DNS pour localiser des contrôleurs de domaine dans
les domaines dotés de noms DNS en une seule partie.
Par défaut, les membres de domaines Windows Server 2003, Windows XP et Windows 2000
n’effectuent pas de mise à jour dynamique vers les zones DNS dont le nom est en une seule partie.
Pour plus d’informations, consultez la section Déploiement et fonctionnement de domaines Active
Directory configurés à l’aide de noms DNS en une seule partie.
Noms réservés
N’utilisez pas de noms de domaine Internet de niveau supérieur sur l’intranet, comme .com , .net et
.org . Si vous utilisez des noms de domaine Internet de niveau supérieur sur l'intranet, les ordinateurs
sur l'intranet qui sont également connectés à Internet peuvent rencontrer des erreurs de résolution.
Espaces de noms disjoints
Un espace de noms disjoint se produit lorsque le suffixe DNS principal d’un ordinateur ne correspond pas au
domaine DNS dont il est membre. Par exemple, un espace de noms disjoint se produit lorsqu’un ordinateur
ayant le nom DNS dc1.contosocorp.com est situé dans un domaine portant le nom contoso.com .
Comment se produisent les espaces de noms disjoints
1. Un contrôleur de domaine principal Windows NT 4.0 est mis à niveau vers un contrôleur de domaine
Windows 2000 à l’aide de la version commerciale d’origine de Windows 2000. Dans l'élément Réseau du
Panneau de configuration, plusieurs suffixes DNS sont définis.
2. Le domaine est renommé lorsque la forêt est située au niveau fonctionnel de la forêt de Windows
Server 2003. Et le suffixe DNS principal n’est pas modifié en fonction du nouveau nom de domaine DNS.
Conséquences d’un espace de noms disjoint
Supposons qu’un contrôleur de domaine nommé DC1 réside dans un domaine Windows NT 4.0 dont le nom de
domaine NetBIOS est « contoso ». Ce contrôleur de domaine est mis à niveau vers Windows 2000. Lors de cette
mise à niveau, le domaine DNS est renommé contoso.com . Dans la version commerciale d'origine de
Windows 2000, la routine de mise à niveau désactive la case à cocher qui lie le suffixe DNS principal du
contrôleur de domaine à son nom de domaine DNS. Par conséquent, le suffixe DNS principal du contrôleur de
domaine est le suffixe DNS Windows NT 4.0 défini dans la liste de recherche de suffixes Windows NT 4.0. Dans
cet exemple, le nom DNS est DC1.northamerica.contoso.com .
Le contrôle de domaine enregistre de manière dynamique ses enregistrements d'emplacement de service (SRV)
dans la zone DNS qui correspond à son nom de domaine DNS. Toutefois, le contrôle de domaine enregistre ses
enregistrements d'hôte dans la zone DNS qui correspond à son suffixe DNS principal.
Pour plus d’informations sur les espaces de noms disjoints, consultez les articles suivants :
Les ID d’événements 5788 et 5789 se produisent sur un ordinateur Windows
Créer un espace de noms disjoint
Autres facteurs
Forêts connectées à Internet
Un espace de noms DNS connecté à Internet doit être un sous-domaine d'un niveau supérieur ou d'un
domaine de second niveau de l'espace de noms DNS Internet.
Nombre maximal de domaines dans une forêt
Dans Windows 2000, une forêt peut comporter au maximum 800 domaines. Dans Windows 2003, le
nombre maximal de domaines au niveau fonctionnel 2 de la forêt est de 1 200. Il s’agit d’une limite
d’attributs non liés à plusieurs valeurs dans Windows Server 2003.
Bonnes pratiques
Les noms DNS de tous les nœuds qui nécessitent une résolution de noms incluent le nom de
domaine DNS Internet pour l’organisation. Par conséquent, choisissez un nom de domaine DNS
Internet qui est court et facile à mémoriser. Étant donné le caractère hiérarchique de DNS, les
noms de domaine DNS augmentent lorsque vous ajoutez des sous-domaines à votre organisation.
Les noms de domaine courts permettent de mémoriser facilement les noms d'ordinateur.
Si l'organisation est présente sur Internet, définissez des noms par rapport au nom de domaine
DNS Internet enregistré. Par exemple, si vous avez enregistré le nom de domaine DNS
contoso.com , utilisez un nom de domaine DNS tel que corp.contoso.com pour le nom de domaine
intranet.
N’utilisez pas le nom d’une entreprise ou d’un produit existant comme nom de domaine. Vous
risqueriez de rencontrer ultérieurement un conflit de noms.
Évitez un nom générique tel que domaine.localhost. Une autre entreprise avec laquelle vous
pourriez fusionner dans le futur pourrait appliquer le même principe.
N’utilisez pas d’acronyme ou d’abréviation comme nom de domaine. Les utilisateurs pourraient
rencontrer des difficultés pour déterminer l'unité commerciale correspondant à un acronyme.
Évitez d’utiliser des traits de soulignement (_) dans les noms de domaine. Les applications peuvent
être très obéissantes aux normes RFC et rejeter le nom. Elles pourraient alors ne pas être installées
ou ne pas fonctionner avec votre domaine. Vous pouvez également rencontrer des problèmes avec
des serveurs DNS plus anciens.
N’utilisez pas le nom d’une unité/division commerciale comme nom de domaine. Les unités
commerciales et les autres divisions peuvent changer et ces noms de domaine peuvent être
trompeurs ou devenir obsolètes.
N’utilisez pas de noms géographiques qui sont difficiles à orthographier ou à mémoriser.
Évitez d'étendre la hiérarchie de noms de domaine DNS sur plus de cinq niveaux à partir du
domaine racine. Vous pouvez réduire les coûts administratifs en limitant l'étendue de la hiérarchie
de noms de domaine.
Si vous déployez DNS dans un réseau privé et que vous n’envisagez pas de créer un espace de
noms externe, enregistrez le nom de domaine DNS créé pour le domaine interne. À défaut, le nom
risque de ne pas être disponible si vous essayez de l'utiliser sur Internet ou si vous vous connectez
à un réseau connecté à Internet.
Noms de site
Nous vous recommandons d'utiliser un nom DNS valide lorsque vous créez un nom de site. À défaut, votre site
ne sera disponible que si un serveur DNS Microsoft est utilisé. Pour plus d’informations sur les noms DNS
valides, consultez la section Noms d’hôte DNS.
Pour plus d’informations, consultez les sites web suivants :
rfc952
rfc1123
Les noms DNS ne peuvent pas contenir les caractères suivants :
Virgule (,)
Tilde (~)
Deux-points (:)
Arobase (@)
Signe dièse (#)
Symbole dollar ($)
Esperluette (&)
Apostrophe (')
Point (.)
Parenthèses (())
accolades ({})
Le trait de soulignement a un rôle spécial. Il est autorisé pour le premier caractère des
enregistrements SRV par définition RFC. Toutefois, les serveurs DNS plus récents peuvent
Tous les caractères conservent leur casse, sauf les caractères ASCII.
La longueur maximale du nom DNS est de 63 octets par partie.
Noms d'unité d'organisation

Tous les caractères sont autorisés, y compris les caractères étendus. Toutefois, bien que le composant
Utilisateurs et ordinateurs Active Directory vous permette d’affecter à une unité d’organisation un nom
contenant des caractères étendus, nous vous recommandons d’utiliser un nom qui décrit l’usage de
l’unité d’organisation et qui est suffisamment court pour simplifier la gestion. Le protocole LDAP
(Lightweight Directory Access Protocol) n’impose aucune restriction, car le nom commun (CN) de l’objet
est placé entre guillemets.
Aucun caractère n'est interdit.
Problèmes particuliers
Lorsque l’unité d’organisation au niveau du domaine racine porte le même nom qu’un domaine enfant futur,
vous pouvez rencontrer des problèmes de base de données. Prenons un scénario dans lequel vous supprimez
une unité d’organisation nommée marketing pour créer un domaine enfant portant le même nom, par exemple,
marketing.contoso.com (la partie gauche du nom FQDN du domaine enfant a le même nom).
L'unité d'organisation est supprimée et, pendant la durée de vie de temporisation de l'unité d'organisation
créée, un domaine enfant du même nom est créé, supprimé puis créé à nouveau. Dans ce scénario, un nom
d'enregistrement en double dans la base de données ESE provoque un conflit de noms fantôme-fantôme lors de
la nouvelle création du domaine enfant. Ce problème empêche la réplication du conteneur de configuration.
NOTE
Un conflit de noms similaire peut également se produire avec d’autres types de noms RDN dans certaines conditions, sans
se limiter aux types de noms de contrôleur de domaine et d’unité d’organisation.
Tableau des mots réservés

M OT S RÉSERVÉS P O UR L ES W IN DO W S SERVER 2003 ET
NOMS W IN DO W S N T 4. 0 W IN DO W S 2000 VERSIO N S ULT ÉRIEURES
ANONYMOUS X X X
AUTHENTICATED USER X X
BATCH X X X
BUILTIN X X X
CREATOR GROUP X X X
CREATOR GROUP SERVER X X X
Créateur propriétaire X X X
CREATOR OWNER SERVER X X X
DIALUP X X X
DIGEST AUTH X
INTERACTIVE X X X
INTERNET X X
LOCAL X X X
LOCAL SYSTEM X
NETWORK X X X
SERVICE RÉSEAU X
NT AUTHORITY X X X
NT DOMAIN X X X
NTLM AUTH X
NULL X X X
PROXY X X
REMOTE INTERACTIVE X
RESTRICTED X X
SCHANNEL AUTH X
SELF X X
SERVER X X
SERVICE X X X
SYSTEM X X X
TERMINAL SERVER X X
THIS ORGANIZATION X
USERS X
WORLD X X X
NET.EXE /ADD ne prend pas en charge les noms de
plus de 20 caractères
Cet article fournit une solution à une erreur qui se produit lorsque vous utilisez la commande avec des noms
d’utilisateur ou de groupe de plus NET.EXE /ADD de 20 caractères.
S’applique à : Windows 10 - toutes les éditions, Windows Server 2019, Windows Server 2016, Windows Server
2012 R2
Symptômes
Lorsque vous utilisez la commande avec le commutateur et les noms d’utilisateur ou de groupe longs, cela ne
fait que NET.EXE /ADD rééditér la syntaxe NET. Vous ne recevez aucun message d’erreur.
Exemple :
C:\>NET.EXE localgroup MyRemoteUsers "REMOTE INTERACTIVE LOGON" /ADD
The syntax of this command is:
NET LOCALGROUP [groupname [/COMMENT:"text"]] [/DOMAIN]

groupname {/ADD [/COMMENT:"text"] | /DELETE} [/DOMAIN]
groupname name [...] {/ADD | /DELETE} [/DOMAIN]
La même action fonctionne avec la console MMC (Gestion de l’ordinateur graphique graphique), utilisateurs
locaux et groupes Microsoft Management Console (MMC).
Cause
La commande NET.EXE ne prend pas en charge les noms de plus de 20 caractères pour des raisons de
compatibilité ascendante avec LAN Manager 2.0.
Résolution
Si la méthode d’interface utilisateur graphique (GUI) ne peut pas être utilisée et qu’une méthode de script est
requise, utilisez l’utilitaire du Kit de ressources Windows 2000 Cusrmgr.exe. Vous pouvez également utiliser
VBScript à l’aide d’une interface de programmation d’application (API) qui prend en charge les noms de plus de
20 caractères.
État
S’applique à ».
Dans l’exemple de la section « Symptômes » de cet article, utilisez la syntaxe Cusrmgr.exe suivante :
C:\>CUSRMGR.EXE -u "REMOTE INTERACTIVE LOGON" -alg "MyRemoteUsers"
Ce problème peut également se produire avec des versions localisées dans lesquelles les groupes intégrés
dépassent la limite de 20 caractères. Par exemple, avec le nom allemand « Utilisateurs authentifiés » (19
caractères) : « Authentifizierte Benutzer » (25 caractères).
L’exemple VBScript suivant peut être adapté et utilisé comme solution de contournement supplémentaire. Il
ajoute « Utilisateurs authentifiés » à « Utilisateurs avec pouvoir » pour la version anglaise et allemande :
##### VBScript ADDGRP.VBS #####
On Error Resume Next
Dim oContainer
Dim oGroup
Dim oIADs
Dim oComputerInformation
Dim bolGroupSet
bolGroupSet = False
Set oComputerInformation = CreateObject("WScript.Network")
Set oContainer = GetObject("WinNT://" +

oComputerInformation.ComputerName)'get the IADsContainer object for the local computer
oContainer.Filter = Array("Group")'We only need to enumerate groups,

therefore the filter
For Each oIADs In oContainer 'for each IADs object we find there
If oIADs.Name = "Hauptbenutzer" Or oIADs.Name = "Power Users" Then
'check if it has the name "Power Users" or "Hauptbenutzer"
Set oGroup = oIADs 'If so put it into the IADsGroup object

oGroup.Add ("WinNT://S-1-5-11")'add the group "Authenticated Users"
oGroup.SetInfo 'and save the info
If Err <> 0 Then 'if error number is not 0 (Error occurred)

MsgBox Err.Number, vbCritical, "AddGroup" 'print out the error message
Else 'if everything seems to be ok
bolGroupSet = True 'set the boolean value to True so we know the group was added
End If
End If
Next
If bolGroupSet = True Then 'if bolGroupSet is False there was nothing done
MsgBox "Group added successfully", vbInformation, "AddGroup"
Else
MsgBox "No action has taken place!", vbExclamation, "AddGroup"
End If
##### script end #####
Pour contourner ce problème dans Windows Server 2008 et les ultérieures, utilisez la commande PowerShell
Add-ADGroupMember, comme décrit dans l’article TechNet suivant :
Add-ADGroupMember
Si vous utilisez PowerShell 5.1, utilisez la commande Add-LocalGroupMember -Group PowerShell, comme
décrit dans l’article suivant :
Add-LocalGroupMember
Le service Netlogon ne démarre pas et les ID
d’événement 2114 et 7024 sont enregistrés
Cet article fournit une solution à un problème dans lequel le service Netlogon ne démarre pas lorsque vous
démarrez un ordinateur Windows base de données.
Symptômes
Lorsque vous démarrez votre ordinateur Windows 2000, le service Netlogon ne démarre pas, même si le type
de démarrage est automatique.
L’Observateur d’événements enregistre les erreurs suivantes :
Message 1
Event Type: Error

Event Source: NETLOGON
Event ID: 2114
Description: The Server service is not started.
Message 2
Event Type: Error

Event Category:None
Event ID: 7024
Description: The Netlogon service terminated with service-specific error 2114.
Après le démarrage de votre ordinateur, vous pouvez démarrer manuellement le service Netlogon.
Cause
Ce problème peut se produire si l’une des conditions suivantes existe :
Les services dépendants du service Netlogon ont été modifiés par rapport aux valeurs par défaut et ne
sont pas correctement configurés. Il se peut que vous ne soyez pas en mesure d’accéder à certaines
ressources réseau sur l’ordinateur, car le service Netlogon n’est pas démarré.
Vous avez supprimé Client pour les réseaux Microsoft, puis l’avez réinstallé. Les dépendances ne sont pas
réinitialisées correctement si le composant Client pour Les réseaux Microsoft est supprimé, puis
réinstallé.
Résolution
IMPORTANT

2. Recherchez la clé de Registre : HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Netlogon/ .
3. Dans le volet droit, double-cliquez sur la valeur DependOnSer vice.
4. Dans la boîte de dialogue Éditeur de chaînes multiples, tapez les chaînes suivantes sur des lignes
distinctes, puis cliquez sur OK :
LanmanServer
LanmanWorkstation
5. Quittez l’Éditeur du Registre, puis redémarrez l’ordinateur.
Le service Netlogon démarre comme prévu.
Modification du mot de passe en cas d’échec du
mot de passe expiré pour un scénario de groupe de
travail
Cet article permet de résoudre une erreur qui se produit lors du traitement de la modification du mot de passe
pour un utilisateur dont le mot de passe a expiré ou qui est définie pour changer à la prochaine fois.
Symptômes
Vous avez un serveur dans une DMZ qui n’est pas membre d’un domaine. Pour l’administration, vous avez une
série d’utilisateurs locaux qui sont administrateurs.
Lorsque vous ajoutez un nouvel utilisateur sur le serveur pour l’administration, vous définissez un mot de passe
initial et vous définissez « L’utilisateur doit modifier le mot de passe lors de la prochaine logonisation ».
L’utilisateur se connecte au serveur via les services Bureau à distance. L’utilisateur est invité à modifier le mot de
passe et, après l’avoir entré, il reçoit un message d’erreur « Un espace de stockage insuffisant est disponible
pour traiter cette commande » :
Si le serveur RDS a activé le NLA, la tentative de connexion au serveur échoue avec le mot de passe expiré
indiquant l’erreur :
[Titre de la fenêtre]
Connexion Bureau à distance[Contenu]
Une erreur d’authentification s’est produite.
Impossible de contacter l’autorité de sécurité locale
Ordinateur distant : <Computer Name>
Cela peut être dû à un mot de passe expiré.
Veuillez mettre à jour votre mot de passe s’il a expiré.
Pour obtenir de l’aide, contactez votre administrateur ou votre support technique.
[OK]
La boîte de dialogue d’erreur ressemble à ceci :

Cause
Lors du traitement de la modification du mot de passe d’un utilisateur dont le mot de passe a expiré ou qui doit
être changé à la prochaine fois, Winlogon utilise un jeton anonyme pour traiter la demande de modification de
mot de passe.
La boîte de dialogue de modification du mot de passe permet également de modifier les mots de passe par
rapport aux ordinateurs distants, de sorte que les appels d’API utilisent des interfaces remotables via RPC sur
canaux nommés sur SMB. Pour cette séquence de protocole, le runtime RPC lit un paramètre de stratégie «
Server2003NegotiateDisable » à partir de la HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc clé.
Cela échoue dans le contexte du jeton anonyme, car les autorisations par défaut permettent uniquement aux
utilisateurs authentifiés, aux administrateurs et au système local de lire la clé.
Lorsque le NLA est activé, la demande de session utilisateur ne valide pas et échoue donc.
Résolution
Les approches à prendre pour éviter ce problème sont les autres :
1. Modifiez le mot de passe à distance. Notez que l’utilisateur dans le contexte où vous exécutez la modification
du mot de passe à distance doit pouvoir se connecter au serveur cible avec les informations d’identification
par défaut (ou déjà connecté au serveur à l’aide de SMB au moment de la modification du mot de passe).
2. Modifiez les autorisations de la clé pour HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Rpc
autoriser l’accès anonyme à la clé. Si la clé n’existe pas, vous pouvez la créer, puis ajouter les autorisations de
lecture pour le compte anonyme.
NOTE
Pour l’approche 2, dans une tentative de récupération à partir d’une erreur, il se peut que le service de stratégie de
groupe supprime les clés et les recrée à l’aide des autorisations par défaut. Dans ce cas, vous devez réappliquer les
autorisations.
Vous pouvez automatiser la définition des autorisations sur l’utilisation de la stratégie de sécurité du Registre
lorsque l’ordinateur est membre du domaine. Pour les ordinateurs de groupe de travail, vous pouvez importer
ce texte en tant que fichier rpc-pol.inf :
---------------------------
[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Registry Keys]
"MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\rpc",0,"D:PAR(A;CIIO;KA;;;CO)(A;CI;KA;;;SY)(A;CI;KA;;;BA)
(A;CI;KR;;;S-1-5-7)(A;CI;KR;;;BU)"
------------------------------
Vous pouvez l’appliquer à l’aide des outils ci-après :

secedit /configure /db C:\Windows\security\database\rpc-pol.sdb/cfg rpc-pol.inf /log rpc-pol.log Note the key
must exist so this is successful.
La fonctionnalité de modification des mots de passe des ordinateurs membres distants ou de groupe de travail
doit prendre en compte un certain nombre d’exigences de compatibilité. Le scénario est très important
aujourd’hui.
Pour les sessions RDS sécurisées avec NLA, il n’est pas permis de démarrer une session distante avec un mot de
passe expiré. Si vous souhaitez utiliser le NLA, vous devez modifier le mot de passe à distance à l’avance dans
une session authentifiée auprès d’un autre utilisateur.
La réinitialisation du mot de passe à l’aide des
utilisateurs Active Directory & ordinateurs échoue
avec l’erreur « Le système ne trouve pas le chemin
d’accès spécifié »
Cet article fournit une solution à une erreur qui se produit lorsque vous réinitialisez le mot de passe d’un
utilisateur.
Symptômes
Vous avez la tâche de gérer les utilisateurs dans votre domaine et vous devez réinitialiser le mot de passe d’un
utilisateur. Vous pouvez cliquer avec le bouton droit sur l’utilisateur, sélectionner Réinitialiser le mot de passe
et entrer le nouveau mot de passe. Une fois que vous avez cliqué sur OK, vous recevez le message d’erreur :
Windows ne peut pas terminer la modification du mot de <user name> passe pour les raisons :
Le système ne peut pas trouver le chemin d’accès spécifié
Le mot de passe de l’utilisateur n’est pas modifié par la suite. La même tâche peut fonctionner avec d’autres
comptes d’utilisateur d’administrateur, ainsi que pour les mêmes comptes d’administrateur sur d’autres stations
de travail. La réinitialisation du mot de passe de l’utilisateur peut également fonctionner via d’autres outils, par
exemple l’utilisation de LDIFDE, comme indiqué dans La façon de définir le mot de passe d’un utilisateur avec
Ldifde.
Cause
La fonction de gestionnaire de boîte de dialogue chiffre les nouvelles chaînes de mot de passe lorsqu’elle les tire
des contrôles d’édition. Le chiffrement échoue car il ne trouve pas les fichiers de prise en charge dans le dossier
AppData de l’utilisateur à l’emplacement suivant :
%AppData% \ Protection Microsoft \\<user sid>
Cela peut se produire si le dossier d’interface utilisateur AppData est redirigé vers un autre emplacement sans
déplacer ni copier les données d’origine. L’emplacement du dossier est spécifié dans la valeur de Registre
AppData à l’emplacement de Registre suivant :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Résolution
Pour résoudre le problème, déplacez ou copiez les données d’origine vers l’emplacement redirigé, ou
inversement la redirection du dossier AppData.
À l’aide de l’outil Moniteur de processus, vous pouvez voir que le processus d'LSASS.EXE ne pourra pas ouvrir
les fichiers dans le chemin d’accès AppData après l’accusé de réception de la nouvelle boîte de dialogue de mot
de passe. Pour plus d’informations sur l’outil Moniteur de processus, visitez le site Web Microsoft suivant :
Process Monitor v3.60
Microsoft recommande d’utiliser des stratégies de redirection de dossiers pour rediriger des parties du profil
utilisateur vers différents emplacements. Ces stratégies permettent également de déplacer automatiquement le
contenu du dossier.
Description des protocoles de modification de mot
de passe Windows
Cet article décrit les mécanismes permettant de modifier les mots de passe dans Windows.
S’applique à : Windows 10, Windows Server 2012 R2
Résumé
Windows utilise de nombreux mécanismes différents pour modifier les mots de passe. Cet article décrit ces
mécanismes.
Les protocoles de modification de mot de passe pris en charge sont :
1. Protocole NetUserChangePassword
2. Protocole NetUserSetInfo
3. Le protocole Kerberos change-password (IETF Internet Draft Draft-ietf-cat-kerb-chg-password-02.txt) [port
464]
4. Protocole Kerberos set-password (IETF Internet Draft Draft-ietf-cat-kerberos-set-passwd-00.txt) [port 464]
5. Attribut de mot de passe d’écriture LDAP (Lightweight Directory Access Protocol) (si le protocole SSL (Secure
Sockets Layer) 128 bits est utilisé)
6. XACT-SMB pour la compatibilité pré-Microsoft Windows NT (LaN Manager)
Les opérations de modification de mot de passe nécessitent que le mot de passe actuel de l’utilisateur soit
connu avant que la modification ne soit autorisée. Les opérations set-password n’ont pas cette exigence, mais
sont contrôlées par les autorisations réinitialiser le mot de passe sur le compte.
Lorsque vous utilisez LDAP (méthode 5), le contrôleur de domaine et le client doivent être en mesure d’utiliser
SSL 128 bits pour protéger la connexion. Si le contrôleur de domaine n’est pas configuré pour SSL ou si des clés
longues appropriées ne sont pas disponibles, l’écriture de modification de mot de passe est refusée.
Un contrôleur de domaine Active Directory écoute les demandes de modification de mot de passe sur tous ces
protocoles.
Comme indiqué précédemment dans cet article, différents protocoles sont utilisés dans différentes
circonstances. Par exemple :
Les clients Kerberos interopérables utilisent les protocoles Kerberos. les systèmes basés sur UNIX avec MIT
Kerberos version 5 1.1.1 peuvent modifier les mots de passe des utilisateurs dans un domaine Windows à
l’aide du protocole Kerberos change-password (méthode 3).
Lorsque les utilisateurs modifient leurs propres mots de passe en appuyant sur Ctrl+ALT+SUPPRIM, puis en
cliquant sur Modifier le mot de passe, Windows NT jusqu’à Windows 2003, le mécanisme
NetUserChangePassword (méthode 1) est utilisé si la cible est un domaine. À partir Windows Vista, le
protocole de modification de mot de passe Kerberos est utilisé pour les comptes de domaine. Si la cible est
un domaine Kerberos, le protocole Kerberos change-password (méthode 3) est utilisé.
Les demandes de modification d’un mot de passe à partir d’ordinateurs exécutant Microsoft Windows
95/Microsoft Windows 98 utilisent XACT-SMB (méthode 6).
Un programme qui utilise la méthode ChangePassword sur l’interface ADSI (Active Directory Services
Interface) IaDSUser tente d’abord de modifier le mot de passe à l’aide de LDAP (méthode 5), puis à l’aide du
protocole NetUserChangePassword (méthode 1).
Un programme qui utilise la méthode SetPassword sur l’interface ADSI IaDSUser tente d’abord de modifier le
mot de passe à l’aide de LDAP (méthode 5), puis du protocole Kerberos set-password (méthode 4), puis du
protocole NetUserSetInfo (méthode 2).
Le logiciel en ligne Utilisateurs et ordinateurs Active Directory utilise les opérations ADSI pour définir les
mots de passe des utilisateurs.
Performances médiocres lors de l’appel de fonctions
de recherche pour résoudre des noms

Lorsque vous appelez la fonction LookupAccountName ou LsaLookupNames pour résoudre des noms
isolés (comptes d’utilisateur ambigus ou non qualifiés de domaine) en identificateurs de sécurité (SID), vous
remarquerez peut-être une augmentation de l’utilisation de la mémoire et du processeur sur le contrôleur de
domaine et une diminution des performances.
Par exemple, des performances médiocres peuvent se produire lors de l’utilisation de scripts ou d’outils (tels que
Cacls.exe, Xcacls.exe, icacls.exe, Dsacls.exe et Subinacl.exe) pour appeler les fonctions afin de modifier les
paramètres de sécurité.
Le problème peut se présenter lorsque vous avez de nombreux domaines ou forêts de confiance (s’applique aux
trusts externes et de forêt), et/ou que certains de ces domaines ou forêts sont hors connexion ou lents à
répondre.
Lorsque les fonctions sont appelées pour un nom isolé (le format est AccountName par opposition à
domaine\AccountName), un appel de procédure distante (RPC) est effectué aux contrôleurs de domaine sur tous
les domaines/forêts de confiance. This issue might occur if the primary domain has many trust relationships
with other domains/forests or if it’s doing many lookups at a same time. Par exemple, un script est configuré
pour s’exécuter au démarrage de nombreux clients, ou de nombreux domaines/forêts de confiance utilisent le
même script simultanément.
Désactiver la recherche de noms isolés dans les domaines/forêts de

confiance
NOTE
Créez cette entrée de Registre uniquement sur les contrôleurs de domaine.
Voici comment créer une entrée de Registre pour désactiver la recherche de noms isolés dans les
domaines/forêts de confiance :
IMPORTANT
Cet article contient des instructions pour modifier le Registre. Des problèmes graves peuvent se produire si le Registre est
modifié de manière incorrecte. Par mesure de précaution, veillez à le faire avant de le modifier. Pour plus d’informations sur
la façon de la back up, restore et modify the registry, voir How to back up and restore the registry in Windows.

2. Accédez à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa .
3. Dans le menu Edition, sélectionnez Nouvelle > valeur DWORD.
4. Tapez LsaLookupRestrictIsolatedNameLevel et appuyez sur Entrée.
5. Cliquez avec le bouton droit sur LsaLookupRestrictIsolatedNameLevel et sélectionnez Modifier.
Tapez 1 dans la zone de données Valeur.
NOTE
Par défaut, l’entrée LsaLookupRestrictIsolatedNameLevel est définie sur 0 ou n’existe pas. Cela signifie que
la recherche de noms isolés dans les domaines/forêts de confiance est activée.
6. Sélectionnez OK et fermez l’Éditeur du Registre.
Les fonctions de recherche peuvent cibler directement un contrôleur de domaine sur un domaine approprié
pour les formats de nom suivants qui contiennent un domaine faisant autorité d’un principal de sécurité :
NetBIOSDomainName\AccountName
DnsDomainName\AccountName
AccountName@DnsDomainName
Pour plus d’informations, voir algorithmes de validation d’accèsréseau et exemples pour Windows .
Rediriger les conteneurs utilisateurs et ordinateurs
dans les domaines Active Directory
Vous pouvez utiliser redirusr et redircmp pour rediriger les comptes d’utilisateur, d’ordinateur et de groupe
créés par les API de version antérieure. Ils sont donc placés dans des conteneurs d’unité d’organisation spécifiés
par l’administrateur.
Résumé
Dans une installation par défaut d’un domaine Active Directory, les comptes d’utilisateur, d’ordinateur et de
groupe sont placés dans des conteneurs CN=objectclass au lieu d’un conteneur de classe OU plus souhaitable.
De même, les comptes créés à l’aide d’API de version antérieure sont placés dans les conteneurs CN=Utilisateurs
et CN=ordinateurs.
IMPORTANT
Certaines applications nécessitent que des principaux de sécurité spécifiques soient situés dans des conteneurs par défaut
tels que CN=Utilisateurs ou CN=Ordinateurs. Vérifiez que vos applications ont ces dépendances avant de les déplacer des
conteneurs CN=users et CN=computes.
Les utilisateurs, ordinateurs et groupes créés par des API de version antérieure placent les objets dans le chemin
d’accès DN spécifié dans l’attribut WellKnownObjects. L’attribut WellKnownObjects se trouve dans l’en-tête NC
du domaine. L’exemple de code suivant montre les chemins d’accès pertinents dans l’attribut WellKnownObjects
à partir CONTOSO.COM en-tête NC du domaine.
Dn: DC=CONTOSO,DC=COM
wellKnownObjects (11):
B:32:6227F0AF1FC2410D8E3BB10615BB5B0F:CN=NTDS Quotas,DC=CONTOSO,DC=COM;
B:32:F4BE92A4C777485E878E9421D53087DB:CN=Microsoft,CN=Program Data,DC=CONTOSO,DC=COM;
B:32:09460C08AE1E4A4EA0F64AEE7DAA1E5A:CN=Program Data,DC=CONTOSO,DC=COM;
B:32:22B70C67D56E4EFB91E9300FCA3DC1AA:CN=ForeignSecurityPrincipals,DC=CONTOSO,DC=COM;
B:32:18E2EA80684F11D2B9AA00C04F79F805:CN=Deleted Objects,DC=CONTOSO,DC=COM;
B:32:2FBAC1870ADE11D297C400C04FD8D5CD:CN=Infrastructure,DC=CONTOSO,DC=COM;
B:32:AB8153B7768811D1ADED00C04FD8D5CD:CN=LostAndFound,DC=CONTOSO,DC=COM;
B:32:AB1D30F3768811D1ADED00C04FD8D5CD:CN=System,DC=CONTOSO,DC=COM;
B:32:A361B2FFFFD211D1AA4B00C04FD7D83A:OU=Domain Controllers,DC=CONTOSO,DC=COM;
B:32:AA312825768811D1ADED00C04FD8D5CD:CN=Computers,DC=CONTOSO,DC=COM;
B:32:A9D1CA15768811D1ADED00C04FD8D5CD:CN=Users,DC=GPN,DC=COM;
Par exemple, les opérations suivantes utilisent des API de version antérieure, qui répondent aux chemins d’accès
définis dans l’attribut WellKnownObjects :
O P ÉRAT IO N VERSIO N S DU SY ST ÈM E D’EXP LO ITAT IO N
Interface utilisateur de jointrement de domaine Windows version NT 4.0
Windows 2000
Windows XP Ultimate
Windows Server 2003

Windows Vista
Windows Server 2008
Windows 7
NET COMPUTER Toutes les versions
NET GROUP Toutes les versions
NET USER Toutes les versions
NETDOM ADD, où la commande /ou n’est pas spécifiée ou Toutes les versions
prise en charge
Il est utile de faire du conteneur par défaut pour les utilisateurs, les ordinateurs et les groupes de sécurité une ou
plusieurs raisons, notamment :
Les stratégies de groupe peuvent être appliquées sur les conteneurs d’ou, mais pas sur les conteneurs de
classe CN, où les principaux de sécurité sont placés par défaut.
La meilleure pratique consiste à organiser les principaux de sécurité dans une hiérarchie d’organisation
qui reflète votre structure organisationnelle, votre disposition géographique ou votre modèle
d’administration.
Si vous redirigez les dossiers CN=Utilisateurs et CN=Ordinateurs, n’ignorez pas les problèmes suivants :
Le domaine cible doit être configuré pour s’exécuter au niveau fonctionnel Windows Server 2003 ou
supérieur. Pour le Windows domaine Server 2003, cela signifie que :
Windows Server 2003 ou ADPREP /FORESTPREP une édition plus nouvelle
Windows Server 2003 ou ADPREP /DOMAINPREP une édition plus nouvelle
Tous les contrôleurs de domaine dans le domaine cible doivent exécuter Windows Server 2003 ou une
édition plus nouvelle.
Windows niveau fonctionnel de domaine Server 2003 ou supérieur doit être activé.
Contrairement à CN=USERS et CN=COMPUTERS, les conteneurs d’UO sont soumis à des suppressions
accidentelles par des comptes d’utilisateur privilégiés, y compris des administrateurs.
Les conteneurs CN=USERS et CN=COMPUTERS sont des objets protégés par le système qui ne peuvent
pas et ne doivent pas être supprimés pour des raisons de compatibilité ascendante. Toutefois, ils peuvent
être renommés. Les unités d’organisation sont sujettes à des suppressions accidentelles d’arborescences
par les administrateurs.
Windows Server 2003 du logiciel en ligne Utilisateurs & Ordinateurs Active Directory peut suivre les
étapes de la section Protéger une unité d’organisation contre la suppression accidentelle.
Windows Server 2008 et les versions plus récentes du logiciel en ligne Utilisateurs et ordinateurs Active
Directory disposent d’une case à cocher Protéger un objet contre la suppression accidentelle que vous
pouvez sélectionner lorsque vous créez un conteneur d’ou. Vous pouvez également le sélectionner sous
l’onglet Objet de la boîte de dialogue Propriétés d’un conteneur d’ou existant.
Une option scriptée est documentée dans Script pour protéger les unités d’organisation contre la
suppression accidentelle.
Exchange Server 2000 et 2003 setup /domainprep échoue avec des erreurs.
Rediriger CN=Utilisateurs vers une UO spécifiée par l’administrateur

1. Connectez-vous avec les informations d’identification d’administrateur de domaine dans le domaine z où
le conteneur CN=Utilisateurs est redirigé.
2. Faites passer le domaine au niveau fonctionnel de domaine Windows Server 2003 ou à un niveau plus
ancien dans le logiciel en ligne Utilisateurs et ordinateurs Active Directory (Dsa.msc) ou le logiciel en
ligne Domaines et confiances (Domains.msc). Pour plus d’informations sur l’augmentation du niveau
fonctionnel du domaine, voir Comment augmenter les niveaux fonctionnels de domaine et de forêt.
3. Créez le conteneur d’ou dans lequel vous souhaitez que les utilisateurs créés avec des API de version
antérieure soient situés, si le conteneur d’ou que vous souhaitez n’existe pas.
4. Exécutez Redirusr.exe à l’invite de commandes à l’aide de la syntaxe suivante. Dans la commande,
container-dn est le nom unique de l’ou qui deviendra l’emplacement par défaut pour les objets utilisateur
nouvellement créés créés par les API de bas niveau :
c:\windows\system32\redirusr <DN path to alternate OU>
Redirusr est installé dans %SystemRoot%\System32 le dossier sur Windows ordinateurs basés sur Server
2003 ou plus nouveaux. Par exemple, pour modifier l’emplacement par défaut des utilisateurs créés avec
des API de bas niveau telles que Net User en conteneur d’UO=MYUsers dans CONTOSO.COM le domaine,
utilisez la syntaxe suivante :
c:\windows\system32>redirusr ou=myusers,DC=contoso,dc=com
Rediriger CN=Ordinateurs vers une UO spécifiée par l’administrateur

1. Connectez-vous avec les informations d’identification d’administrateur de domaine dans le domaine dans
lequel le conteneur CN=ordinateurs est redirigé.
2. Faites passer le domaine au domaine Windows Server 2003 dans le logiciel en ligne Utilisateurs et
ordinateurs Active Directory (Dsa.msc) ou dans le logiciel en ligne Domaines et confiances
(Domains.msc). Pour plus d’informations sur l’augmentation du niveau fonctionnel du domaine, voir
Comment augmenter les niveaux fonctionnels de domaine et de forêt.
3. Créez le conteneur d’ou dans lequel vous souhaitez que les ordinateurs créés avec des API de version
antérieure soient situés, si le conteneur d’ou souhaité n’existe pas.
4. Exécutez Redircmp.exe à une invite de commandes à l’aide de la syntaxe suivante. Dans la commande,
container-dn est le nom unique de l’ou qui deviendra l’emplacement par défaut pour les objets ordinateur
nouvellement créés créés par les API de bas niveau :
redircmp container-dn container-dn
Redircmp.exe est installé dans le %Systemroot%\System32 dossier dans Windows Server 2003 ou versions
ultérieures. Pour modifier l’emplacement par défaut d’un ordinateur créé avec des API de version
antérieure, telles que Net User, en conteneur OU=mycomputers dans le domaine CONTOSO.COM, utilisez
la syntaxe suivante :
C:\windows\system32>redircmp ou=mycomputers,DC=contoso,dc=com
NOTE
Lorsque Redircmp.exe est exécuté pour rediriger le conteneur CN=Ordinateurs vers une UO spécifiée par un
administrateur, le conteneur CN=Ordinateurs ne sera plus un objet protégé. Cela signifie que le conteneur
Ordinateurs peut désormais être déplacé, supprimé ou renommé. Si vous utilisez ADSIEDIT pour afficher les
attributs sur le conteneur CN=Computers, vous verrez que l’attribut systemflags a été modifié de -1946157056
à 0 . Ce comportement est voulu par la conception même du produit.
Description des messages d’erreur

Voici des messages d’erreur qui se produisent dans certains cas.
Messages d’erreur que vous recevez si le PDC est hors connexion
Redircmp et Redirusr modifient l’attribut wellKnownObjects sur le contrôleur de domaine principal (PDC). Si le
PDC du domaine modifié est hors connexion ou inaccessible, vous recevez les messages d’erreur suivants.
D:>redirusr OU=userOU,DC=udc,dc=jkcertcontoso,dc=loc com

Erreur : le contrôleur de domaine principal du domaine actuel n’a pas pu être localisé : le domaine
spécifié n’existe pas ou n’a pas pu être contacté. La redirection n’a PAS réussi.
D:>redircmp OU=computerOU,DC=contoso,dc=com DC=udc,dc=jkcert,dc=loc

Erreur : le contrôleur de domaine principal du domaine actuel n’a pas pu être localisé : le domaine
spécifié n’existe pas ou n’a pas pu être contacté. La redirection n’a PAS réussi.
Messages d’erreur que vous recevez si le niveau fonctionnel du domaine n’est Windows Server 2003
Vous essayez de rediriger les utilisateurs ou l’ou les utilisateurs de l’ordinateur dans un domaine qui n’a pas été
Windows niveau fonctionnel du domaine Windows Server 2003. Dans ce cas, vous recevez les messages
d’erreur suivants :
C:>redirusr OU=usersou,DC=contoso,dc=comDC=company,DC=com
Erreur, impossible de modifier l’attribut wellKnownObjects. Vérifiez que le niveau fonctionnel du
domaine est au moins Windows Server 2003 : La redirection n’a pas réussi.
C:>REDIRCMP ou=computersou,DC=contoso,dc=comdc=company,dc=com
domaine est au moins Windows Server 2003 : Ne pas vouloir effectuer
Messages d’erreur que vous recevez si vous vous connectez sans les autorisations requises
Si vous essayez de rediriger les utilisateurs ou l’OO de l’ordinateur à l’aide d’informations d’identification
incorrectes dans le domaine cible, vous pouvez recevoir les messages d’erreur suivants :
Message d’erreur 1
C:>REDIRCMP OU=computersou,DC=contoso,dc=comDC=company,DC=com
domaine est au moins Windows Server 2003 : La redirection des droits insuffisante n’a pas réussi.
C:>redirusr OU=usersou,DC=contoso,dc=comDC=company,DC=com
domaine est au moins Windows Server 2003 : La redirection des droits insuffisante n’a pas réussi.
Messages d’erreur que vous recevez si vous redirigez vers une ou plusieurs personnes qui n’existent pas
Vous essayez de rediriger les utilisateurs ou l’OO de l’ordinateur vers une ou plusieurs autres. Dans ce cas, vous
pouvez recevoir les messages d’erreur suivants :
C:>REDIRCMP OU=nonexistantou,DC=contoso,dc=com dc=rendom,dc=com

domaine est au moins Windows Server 2003 : aucune redirection d’objet de ce type n’a réussi.
C:>redirusr OU=nonexistantou,DC=contoso,dc=com DC=company,DC=com

domaine est au moins Windows Server 2003 : aucune redirection d’objet de ce type n’a réussi.
Messages d’erreur que vous recevez Exchange Server configuration 2000 /domainprep lorsque
CN=Utilisateurs est redirigé
Si Exchange Server 2000 et Exchange Server 2003 setup /domainprep échoue, vous recevez le message d’erreur
suivant :
Échec du programme d’installation lors de l’installation des autorisations au niveau du domaine du sous-
composant avec code d’erreur 0x80072030) (consultez les journaux d’installation pour obtenir une
description détaillée). Vous pouvez annuler l’installation ou réessayer l’étape qui a échoué.
(Réessayer/Annuler)
Les données suivantes s’Exchange Server journal d’installation 2000 qui est analyse avec l’analyseur de journal.
Exchange Server 2003 doit être similaire.
[HH:MM:SS] Completed DomainPrep of Microsoft Exchange 2000 component
[HH:MM:SS] ScGetExchangeServerGroups (K:\admin\src\libs\exsetup\dsmisc.cxx:301) Error code 0X80072030
(8240): There is no such object on the server.
[HH:MM:SS] ScCreateExchangeServerGroups (K:\admin\src\libs\exsetup\dsmisc.cxx:373) Error code 0X80072030
[HH:MM:SS] CAtomPermissions::ScAddDSObjects
(K:\admin\src\udog\exsetdata\components\domprep\a_permissions.cxx:144) Error code 0X80072030 (8240): There
is no such object on the server.
[HH:MM:SS] mode = 'DomainPrep' (61966) CBaseAtom::ScSetup
(K:\admin\src\udog\setupbase\basecomp\baseatom.cxx:775) Error code 0X80072030 (8240): There is no such
object on the server.
[HH:MM:SS] Setup encountered an error during Microsoft Exchange Domain Preparation of DomainPrep component
task. CBaseComponent::ScSetup (K:\admin\src\udog\setupbase\basecomp\basecomp.cxx:1031) Error code 0X80072030
[HH:MM:SS] CBaseComponent::ScSetup (K:\admin\src\udog\setupbase\basecomp\basecomp.cxx:1099) Error code
0X80072030 (8240): There is no such object on the server.
[HH:MM:SS] CCompDomainPrep::ScSetup (K:\admin\src\udog\exsetdata\components\domprep\compdomprep.cxx:502)
Error code 0X80072030 (8240): There is no such object on the server.
[HH:MM:SS] CComExchSetupComponent::Install (K:\admin\src\udog\BO\comboifaces.cxx:694) Error code 0X80072030
[HH:MM:SS] Setup completed
Comment renommer un objet après une collision de
réplication
Cet article explique comment renommer un objet après qu’une collision de réplication s’est produite.
Résumé
Lorsqu’une collision de réplication se produit, les objets qui ont été créés sur deux contrôleurs de domaine ou
plus différents avec le même nom de domaine rdn (nom particulier relatif) et dans le même conteneur peuvent
être renommés. Par exemple, le nom cn=APPSRV,OU=Domain Controllers,DC=domain,DC=com est changé en
ce qui suit :
CN=APPSRVCNF:b9e0025c-f9b0-48f0-ba7b-a77447716911,OU=Domain Controllers,DC=domain,DC=com
De nombreux outils et assistants, notamment l’Assistant Installation d’Active Directory, peuvent ne pas
fonctionner correctement en raison de la longueur du nouveau nom de l’objet. Par conséquent, une fois les
objets en conflit résolus manuellement, il est préférable de revenir au nom d’origine.
NOTE
Si l’objet affecté dans la collision est un ordinateur ou un contrôleur de domaine, seul le rdN utilisé pour localiser l’objet
dans Active Directory est modifié après la collision. Le nom de l’ordinateur et la façon dont l’ordinateur est identifié sur le
réseau ne sont pas modifiés.
Modifier le nom du réseau de rdn d’un objet

1. Recherchez le nouveau réseau de rdn.
Pour obtenir le rdn modifié, vous pouvez utiliser l’utilitaire LDIFDE. Cet utilitaire peut prendre en charge
les opérations par lots basées sur la norme de format de fichier LDIF (LDAP Data Interchange Format).
Vous pouvez exporter toutes les informations d’Active Directory vers un fichier à l’aide de cet utilitaire.
Par exemple, si vous souhaitez exporter les informations suivantes vers un fichier nommé Bluesky.txt,
tapez ce qui suit à une invite de commandes, puis appuyez sur Entrée :
Nom de l’ordinateur : bluesky

Emplacement dans Active Directory :
OU=Workstations,OU=DELTA,OU=OandM,DC=ad,DC=water,DC=ca,DC=gov
Contrôleur de domaine : dc1
ldifde -f c:\bluesky.txt -s dc1 -d

"OU=Workstations,OU=DELTA,OU=OandM,DC=ad,DC=water,DC=ca,DC=gov" -r
"(&(objectClass=computer)(cn=bluesky*))
L’exécution de cette commande exporte toutes les informations d’Active Directory vers le fichier spécifié
(Bluesky.txt). À partir du fichier texte spécifié, vous pouvez trouver le nouveau rdn.
Pour plus d’informations sur le programme utilitaire LDIFDE, consultez le Guide pas à pas de
l’importation et de l’exportation en bloc vers Active Directory.
2. Encodez le nouveau réseau de rdn en base 64.
Le nouveau réseau de rdn contient des caractères que vous ne pouvez pas utiliser dans une chaîne
littérale ; par conséquent, vous devez encoder le réseau de rdn à l’aide de base 64. Une fois que le réseau
de rdn suivant est codé en Base 64 :
CN=APPSRVCNF:b9e0025c-f9b0-48f0-ba7b-a77447716911,OU=Domain
Controllers,DC=domain,DC=com
Le résultat sera le suivant :
Q049QVBQU1JWQ05GOmI5ZTAwMjVjLWY5YjAtNDhmMC1iYTdiLWE3NzQ0NzcxNjkxMSxPVT1Eb21
haW4gQ29udHJvbGxlcnMsREM9ZG9tYWluLERDPW
3. Renommons le réseau de rdn modifié. Pour renommer le réseau de rdn modifié, suivez les étapes
suivantes :
a. Créez un fichier avec une extension .ldf. Lorsque vous modifiez des attributs dans Active Directory,
il est important que le format suivant soit suivi :
Exemple de fichier LDIF pour modifier rdn (changerdn.ldf)

=================
#
Modifier un rdn pour ##### APPSRV ########
dn::
Q049QVBQU1JWQ05GOmI5ZTAwMjVjLWY5YjAtDhmMC1iYTdiLWE3NzQ0NzcxNjkxMSxPVT1
Eb21haW4gQ29udHJvbGxlcnMsREM9ZG9tYWluLERDPWNvbW==
changetype:modrdn
newrdn: cn=APPSRV
deleteoldrdn: 1
dn:: représente le réseau de rdn actuel en base 64. Le (::) indique à Ldifde que la chaîne suivante est
codée en base 64.
newrdn : représente le nouveau nom de l’objet.
b. À l’invite de commandes, tapez ldifde -i -f c:\changerdn.ldf -s your server name .
L’exécution de cette commande modifie le rdn, à l’aide de l’utilitaire LDIFDE, sur le nouveau RDN
qui est spécifié par vous dans le fichier LDIF (Changerdn.ldf).
Lorsque vous exécutez cette commande, vous pouvez recevoir une sortie semblable à celle-ci :
Connexion à « appsrv.domain.com »
Connexion en tant qu’utilisateur actuel à l’aide du SSPI
Importation du répertoire à partir du fichier « changedc.ldf »
Chargement des entrées
1 : CN=APPSRVCNF:b9e0025c-f9b0-48f0-ba7b-a77447716911,OU=Domain
Controllers,DC=domain,DC=com
DN d’entrée : CN=APPSRVCNF:b9e0025c-f9b0-48f0-ba7b-a77447716911,OU=Domain
Controllers,DC=domain,DC=com change: dn
Changement de nom de cn=APPSRV avec deleteold de 1
Entrée modifiée avec succès.
1 entrée modifiée avec succès.
La commande s’est terminée correctement.
Ce processus peut revenir au nom Appsrv. Cette modification est relationnelle de sorte que toutes
les références à cet objet sont modifiées dans Active Directory.
Lorsque vous corrigez le nom sur les objets des contrôleurs de domaine, veillez à revenir à ce qu’il était à
l’origine. Cette modification ne renomme pas le contrôleur de domaine. Si vous renommez un contrôleur de
domaine, il n’est pas pris en charge Windows 2000.
Comment limiter l’utilisation d’un ordinateur à un
seul utilisateur de domaine
Cet article explique comment limiter l’utilisation d’un ordinateur à un seul utilisateur de domaine.
Symptômes
Lorsque vous créez des connexions d’confiance d’un domaine (forêt) à un autre, les utilisateurs ont la possibilité
de se connecter à des domaines/domaines différents de leur domaine d’origine (le domaine qui héberge leurs
comptes).
Cause
Les connexions/connexions d’un domaine à un autre ou/et d’une forêt à une autre permettent aux utilisateurs
de se connecter à des domaines/domaines différents de leur domaine d’origine (domaine qui héberge leurs
comptes). Le groupe « Utilisateurs authentifiés » sur chaque ordinateur permet aux utilisateurs de domaine
approuvé d’être authentifiés et de se rendre sur l’ordinateur.
Résolution
Option A : stratégie Domain-Wide de contrôle
À l’aide des fonctionnalités de stratégie de groupe dans Windows 2000/2003 Domain, vous pouvez empêcher
des utilisateurs de se connectent à des domaines/domaines différents de leur domaine d’origine.
1. Créez un GPO à l’échelle du domaine et activez le droit d’utilisateur « Refuser l’accès local » au compte
d’utilisateur de domaine source/s Dans le domaine cible.
NOTE
Certains services (tels que les services logiciels de sauvegarde) peuvent être impactés par cette stratégie et ne
fonctionnent pas. Pour éliminer les problèmes futurs, appliquez cette stratégie et utilisez le filtre de sécurité des
GPO.
Refuser l’ment local

Filtre à l’aide de groupes de sécurité
2. Exécutez-le Gpupdate /force sur le contrôleur de domaine.
Option B : supprimer les utilisations « AUTORITÉ NT\Utilisateurs authentifiés » de la liste des groupes
d’utilisateurs
Pour éliminer l’option de journalisation sur un ou plusieurs ordinateurs, suivez les instructions suivantes :
1. Cliquez avec le bouton droit sur l’icône « Mon ordinateur » sur le Bureau.
2. Choisissez «Gérer ».
3. Extraire «Utilisateurs et groupes locaux ».
4. Sélectionnez «Groupes ».
5. Sur le côté droit de l’écran, double-cliquez sur le groupe «Utilisateurs ».
6. Supprimez : « AUTORITÉ NT\Utilisateurs authentifiés » de la liste.
7. Ajoutez les utilisateurs ou groupes et groupes/s nécessitants au groupe local «Utilisateurs ».
Option C : Configurer l’utilisateur « Refuser l’accès local » sur l’ordinateur local
Pour éliminer l’option de journalisation sur un ou plusieurs ordinateurs, suivez les instructions suivantes :
1. Go to "Star t " -> "Run « .
2. Write "Gpedit.msc »
3. Activez le droit d’utilisateur « Refuser l’accès local » aux comptes d’utilisateur de domaine source.
NOTE
Certains services (tels que les services logiciels de sauvegarde) peuvent être impactés par cette stratégie et ne
fonctionnent pas.
Refuser l’ment local

4. Gpupdate /force S’exécute sur l’ordinateur local.
Option D : utiliser l’authentification sélective lors de l’utilisation de l’authentification de forêt
Création d’trusts de forêt
Comment définir le mot de passe d’un utilisateur
avec Ldifde
Cet article explique comment définir le mot de passe d’un utilisateur à l’aide de l’outil Ldifde.
L’attribut de mot de passe utilisé par Active Directory est « unicodePwd ». Cet attribut peut être écrit dans des
conditions restreintes, mais ne peut pas être lu. Cet attribut peut uniquement être modifié, et non ajouté lors de
la création d’un objet ou lu par une recherche.
Pour modifier cet attribut, le client doit avoir une connexion chiffrée SASL(Secure Sockets Layer/Transport Layer
Security(SSL/TLS) 128 bits au serveur. Le pack De chiffrement élevé doit être installé à la fois sur le client et sur
le serveur.
NOTE
Lorsque vous souhaitez utiliser le chiffrement SASL, vous pouvez utiliser l’argument « /h » de LDIFDE.
Lorsque vous utilisez un encodeur en base 64, vous devez vous assurer qu’il prend en charge Unicode, sinon vous créez
un mot de passe incorrect.
Il existe deux façons de modifier l’attribut unicodePwd. La première est analogue à une opération de
modification de mot de passe par l’utilisateur classique. Dans ce cas, la demande de modification doit contenir
une opération de suppression et une opération d’ajout. L’opération de suppression doit contenir le mot de passe
actuel entre guillemets et être codée en Base64 comme décrit dans la RFC 1521. L’opération d’ajout doit contenir
le nouveau mot de passe entre guillemets et être codée en Base64.
La deuxième façon de modifier l’attribut est analogue à la réinitialisation par un administrateur d’un mot de
passe pour un utilisateur. Pour ce faire, le client doit être lié en tant qu’administrateur à un utilisateur qui dispose
des droits suffisants pour modifier les mots de passe d’autres utilisateurs. La demande de modification doit
contenir une opération de remplacement unique avec le nouveau mot de passe entre guillemets et être codée
en Base64. Si le client dispose de droits suffisants, ce mot de passe devient le nouveau mot de passe, quel que
soit l’ancien mot de passe.
L’exemple de fichier Ldif suivant (chPwd.ldif) change un mot de passe en newPassword :
dn: CN=TestUser,DC=testdomain,DC=com
changetype: modify
replace: unicodePwd
unicodePwd::IgBu FAQAdwBQAGEAcwBzAHcAbwByAGQAIgA=
-
Pour importer le fichier chPwd.ldif, utilisez la commande suivante :

SSL/TLS :
ldifde -i -f chPwd.ldif -t 636 -s \<dcname> -b \<username> \<domain> \<password>
SASL :
ldifde -i -f chPwd.ldif -h -s \<dcname> -b \<username> \<domain> \<password>
Si le mot de passe ne répond pas aux critères des stratégies de mot de passe appliquées, une erreur se produit :
Ajout d’une erreur lors de l’entrée à partir de la ligne 1 : Ne pas vouloir effectuer l’erreur côté serveur : « Un
appareil connecté au système ne fonctionne pas
Pour plus d’informations, voir les documents suivants :

Le document « LDAP Data Interchange Format (LDIF) - Technical Specification » sur le site Web IETF suivant :
IETF 109 Online
RFC 1521 sur le site Web IETF suivant :
RFC 1521
technique. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas
l'exactitude des informations concernant les sociétés tierces.
Certaines applications et API nécessitent l’accès aux
informations d’autorisation sur les objets de compte
Cet article décrit certaines applications et interfaces de programmation d’applications (API) doivent avoir accès à
l’attribut token-groups-global-and-universal (TGGAU) sur des objets de compte d’utilisateur ou sur des objets
de compte d’ordinateur dans le service d’annuaire Active Directory.
Résumé
Certaines applications disposent de fonctionnalités qui lisent l’attribut token-groups-global-and-universal
(TGGAU) sur des objets de compte d’utilisateur ou sur des objets de compte d’ordinateur dans le service
d’annuaire Microsoft Active Directory. Certaines fonctions Win32 facilitent la lecture de l’attribut TGGAU. Les
applications qui lisent cet attribut ou qui appellent une API (appelée fonction dans le reste de cet article) qui lit
cet attribut n’aboutit pas si le contexte de sécurité appelant n’a pas accès à l’attribut.
Par défaut, l’accès à l’attribut TGGAU est déterminé par la décision de compatibilité des autorisations (prise lors
de la création du domaine au cours DCPromo.exe processus). La compatibilité des autorisations par défaut pour
les nouveaux domaines Windows Server 2003 n’accorde pas un large accès à l’attribut TGGAU. L’accès à la
lecture de l’attribut TGGAU peut être accordé selon les besoins au nouveau groupe Windows Authorization
Access (WAA) dans Windows Server 2003.
L’attribut token-groups-global-and-universal (TGGAU) est une valeur calculée dynamiquement sur les objets de
compte d’ordinateur et sur les objets de compte d’utilisateur dans Active Directory. Cet attribut émane les
appartenances aux groupes globaux et les appartenances au groupe universel pour le compte d’utilisateur ou le
compte d’ordinateur correspondant. Les applications peuvent utiliser les informations de groupe fournies par
l’attribut TGGAU pour prendre différentes décisions concernant un utilisateur spécifique lorsque l’utilisateur
n’est pas connecté.
Par exemple, une application peut utiliser ces informations pour déterminer si un utilisateur a reçu l’accès à une
ressource dont l’application contrôle l’accès. Les applications qui requièrent ces informations peuvent lire
l’attribut TGGAU directement à l’aide des interfaces Lightweight Directory Access Protocol ou Active Directory
Services Interfaces. Toutefois, Microsoft Windows Server 2003 a introduit plusieurs fonctions (notamment la
fonction AuthzInitializeContextFromSid et la fonction LsaLogonUser) qui simplifient la lecture et l’interprétation
de l’attribut TGGAU. Par conséquent, les applications qui utilisent ces fonctions peuvent lire sans le savoir
l’attribut TGGAU.
Pour que les applications puissent lire directement cet attribut ou lire indirectement cet attribut (via l’utilisation
d’une API), le contexte de sécurité dans lequel l’application s’exécute doit avoir obtenu un accès en lecture à
l’objet TGGAU sur les objets utilisateur et sur les objets ordinateur. Les applications ne supposent pas qu’elles ont
accès à TGGAU. Par conséquent, vous pouvez vous attendre à ce que les applications échouent lorsque l’accès
est refusé. Dans ce cas, vous (l’utilisateur) pouvez recevoir un message d’erreur ou une entrée de journal qui
explique que l’accès a été refusé lors de la tentative de lecture de ces informations et qui fournit des instructions
sur la façon d’obtenir l’accès (comme décrit plus loin dans cet article).
Plusieurs applications existantes dépendent des informations fournies par TGGAU, car elles sont disponibles par
défaut dans Microsoft Windows NT 4.0 et dans les systèmes d’exploitation précédents. Ainsi, sur les systèmes
d’exploitation Microsoft Windows 2000 et Windows Server 2003, l’accès en lecture à l’attribut TGGAU est
accordé au groupe Accès compatible pré-Windows 2000.
Pour les domaines qui utilisent des applications existantes, vous pouvez gérer ces applications en ajoutant les
contextes de sécurité que ces applications exécutent en tant que groupe d’accès compatible pré-Windows
2000. Au lieu de cela, vous pouvez sélectionner l’option « Autorisations compatibles avec les serveurs Windows
2000 » pendant le processus DCPromo lorsque vous créez un domaine. (Sur Windows Server 2003, cette
option est wordée comme suit : « Autorisations compatibles avec les systèmes d’exploitation de serveur
Windows 2000 » .) Cette sélection ajoute le groupe Tout le monde au groupe Accès compatible pré-Windows
2000 et accorde ainsi au groupe Tout le monde un accès en lecture à l’attribut TGGAU et à de nombreux autres
objets de domaine.
Lorsqu’un domaine Windows Server 2003 est créé, la sélection de compatibilité d’accès par défaut est
Autorisations compatibles uniquement avec les systèmes d’exploitation Windows 2000 ou Windows Ser ver
2003. Lorsque cette option est définie, le groupe Accès à la compatibilité pré-Windows 2000 inclut
uniquement l’identificateur de sécurité intégré Utilisateurs authentifiés et l’accès en lecture à l’attribut TGGAU
sur les objets est limité. Dans ce cas, l’accès aux applications qui nécessitent l’accès au groupe TGGAU est refusé,
sauf si le compte sous lequel les applications s’exécutent dispose de droits d’administrateur de domaine ou de
droits d’utilisateur similaires.
Permettre aux applications de lire l’attribut TGGAU

Pour simplifier le processus d’octroi d’un accès en lecture sur l’attribut token-groups-global-and-universal
(TGGAU) aux utilisateurs qui doivent lire l’attribut, Windows Server 2003 introduit le groupe d’accès
d’autorisation Windows (WAA).
Sur les nouvelles installations de domaines Windows Server 2003, le groupe WAA se trouve autorisé à accéder
à l’attribut TGGAU en lecture sur les objets utilisateur et les objets de groupe.
Windows 2000 Domains
Si le domaine est en mode d’accès à la compatibilité Windows 2000, le groupe Tout le monde dispose d’un accès
en lecture à l’attribut TGGAU sur les objets de compte d’utilisateur et sur les objets de compte d’ordinateur. Dans
ce mode, les applications et les fonctions ont accès à TGGAU.
Si le domaine n’est pas en mode d’accès Windows 2000, vous de devez peut-être activer certaines applications
pour lire le TGGAU. Étant donné que le groupe d’accès d’autorisation Windows n’existe pas sur Windows 2000,
il est recommandé de créer un groupe local de domaine à cet effet et d’ajouter le compte d’utilisateur ou
d’ordinateur qui nécessite l’accès à l’attribut TGGAU à ce groupe. Ce groupe doit avoir accès à l’attribut sur les
objets utilisateur, sur les objets ordinateur et tokenGroupsGlobalAndUniversal iNetOrgPerson sur les objets.
Domaines en mode mixte et domaines mis à niveau
Lorsqu’un contrôleur de domaine Windows Server 2003 est ajouté à un domaine Windows 2000, la sélection de
compatibilité d’accès précédemment sélectionnée n’est pas modifiée. Ainsi, les domaines et domaines en mode
mixte qui ont été mis à niveau vers Windows Server 2003 qui étaient en mode d’accès à la compatibilité pré-
Windows 2000 continuent à avoir le groupe Tout le monde dans le groupe Accès à la compatibilité pré-
Windows 2000. En outre, le groupe Tout le monde a toujours accès à l’attribut TGGAU. Dans ce mode, les
applications et les fonctions ont accès à TGGAU.
Si le domaine en mode mixte n’est pas en mode d’accès de compatibilité Windows 2000, vous pouvez accorder
des autorisations au moyen du groupe WAA :
Le groupe WAA est créé automatiquement lorsqu’un contrôleur de domaine Windows Server 2003 est
promu au serveur d’opérations à maître unique flottant.
Le groupe WAA n’est pas automatiquement autorisé à accéder à l’attribut TGGAU sur les domaines en mode
mixte et sur les domaines mis à niveau.
Une fois que le Windows d’accès à l’autorisation d’accès (WAA) a accès à l’attribut TGGAU, vous pouvez placer
les comptes qui nécessitent un accès dans le groupe WAA.
Nouveaux domaines Windows Server 2003
Si le domaine est en mode d’accès à la compatibilité Windows 2000, le groupe Tout le monde dispose d’un accès
en lecture à l’attribut TGGAU sur les objets de compte d’utilisateur et sur les objets de compte d’ordinateur. Dans
ce mode, les applications et les fonctions ont accès à TGGAU.
Si le domaine n’est pas en mode d’accès de compatibilité Windows 2000, ajoutez au groupe WAA les comptes
qui nécessitent l’accès à TGGAU. Dans les nouvelles installations de Windows Server 2003, le groupe WAA
dispose déjà d’un accès en lecture à TGGAU sur les objets utilisateur et sur les objets ordinateur.
Description de l’outil Outil Outil d’outils Outils
d’outils d’objets en attente
Cet article décrit l’outil LoL (Groupement d’objets en attente) pour la recherche et la suppression d’objets en
attente.
Introduction
L’Outil de traitement des objets en attente est un outil qui permet d’automatiser la découverte et la suppression
d’objets en attente. L’outil utilise la méthode DRSReplicaVerifyObjects, repadmin /removelingeringobjects qui est
utilisée par la commande et l’outil de repldiag en combinaison avec la primitive rootDSE remove TrouveObjet
utilisée par LDP.EXE.
Avantages et disponibilité
Combine la découverte et la suppression d’objets en attente dans une interface.
L’outil est disponible dans le Centre de téléchargement Microsoft.
Consultez ce billet de blog ASKDS pour obtenir des instructions détaillées sur l’utilisation des outils.
Principales fonctionnalités
Supprime tous les objets en attente sur tous les contrôleurs de domaine (DCS) sans aucune invite.
Effectue une comparaison (n * (n-1)) sur chaque dc de la forêt.
Effectue la détection de topologie, ce qui vous permet de sélectionner et de choisir des DCS à utiliser pour la
comparaison d’objets Derque (source et cible).
Exporte une liste d’objets en attente en tant que fichier CSV, afin qu’il puisse être modifié hors connexion,
puis importé dans l’outil pour supprimer les objets si nécessaire (utile pour les opérations de suppression
avancées).
Enregistre le contenu de l’objet dans un fichier journal au cas où un nouvel objet doit être libéré de l’objet en
attente.
Exigences en matière d’outils
Téléchargez et exécutez l’Outil de téléchargement d’objets en attente sur un ordinateur dc ou membre de
la forêt dont vous souhaitez supprimer les objets en attente.
Microsoft .NET Framework 4.5.2 doit être installé sur l’ordinateur qui exécute l’outil.
Autorisations : le compte d’utilisateur qui exécute l’outil doit avoir des informations d’identification
d’administrateur de domaine pour chaque domaine de la forêt où réside l’ordinateur en cours d’exécution.
Par défaut, les membres du groupe Administrateurs Enterprise ont des informations d’identification
d’administrateur de domaine dans tous les domaines d’une forêt. Les informations d’identification
d’administrateur de domaine sont suffisantes dans un domaine unique ou une forêt de domaines unique.
Vous devez activer la règle de pare-feu Gestion des journaux d’événements distants (RPC) sur n’importe
quel dc qui doit être en cours d’analyse. Dans le cas contraire, l’outil renvoie une erreur « Exception : le
serveur RPC n’est pas disponible ».
Le nombre d’objets en attente dans les environnements AD LDS /ADAM (Active Directory Lightweight
Directory Services) n’est pas pris en charge.
Procédure pas à pas
Détection d’objets en attente
Exécutez l’outil en tant qu’administrateur de domaine (ou en tant qu’administrateur Enterprise si vous souhaitez
analyser la forêt entière). Pour ce faire, suivez ces étapes.
NOTE
Vous recevrez l’erreur 8453 si l’outil n’est pas exécuté avec élévation de niveau.
1. Dans la section Détection de topologie, sélectionnez Rapide.

La détection rapide remplit les listes Contexte d’attribution de noms, Dc de référence et DC cible en
interrogeant le dc local. Une détection approfondie permet une recherche plus exhaustive de tous les DCS
et tire parti des appels DC Locator et DSBind. Sachez que la détection approfondie échouera
probablement si un ou plusieurs DCS sont inaccessibles.
2. Les champs de l’onglet Objets en attente sont les suivants :
Contexte d’attribution de noms
Dc de référence
Il s’agit de la dc que vous comparerez à la dc cible. Le dc de référence héberge une copie accessible en
écriture de la partition.
NOTE
Tous les DCS de la forêt sont affichés même s’ils ne conviennent pas en tant que DCS de référence (ChildDC2 est
un DC de référence non valide, car il n’héberge pas de copie accessible en writable d’un DC).
Dc cible
Dc cible dont les objets en attente doivent être supprimés.
3. Cliquez sur Détecter pour utiliser ces DCS pour la comparaison ou laissez tous les champs vides pour
analyser l’ensemble de l’environnement.
L’outil fait une comparaison avec tous les DCS pour toutes les partitions de manière couplée lorsque tous
les champs sont laissés vides. Dans un environnement de grande taille, cette comparaison prendra
beaucoup de temps (voire des jours) car l’opération cible (n * (n-1)) le nombre de PC dans la forêt pour
toutes les partitions localement détenues. Pour des opérations plus courtes et ciblées, sélectionnez un
contexte d’attribution de noms, un dc de référence et un dc cible. Le dc de référence doit contenir une
copie accessible en writable du contexte d’attribution de noms sélectionné. N’oubliez pas que le fait de
cliquer sur Arrêter n’arrête pas réellement l’API côté serveur, il arrête simplement le travail dans l’outil
côté client.
Pendant l’analyse, plusieurs boutons sont désactivés et le nombre actuel d’objets en attente s’affiche dans
la barre d’état en bas de l’écran, avec l’état actuel de l’outil. Au cours de cette phase d’exécution, l’outil
s’exécute en mode d’avis et lit les données du journal des événements signalées sur chaque dc cible.
Une fois l’analyse terminée, la barre d’état est mise à jour, les boutons sont ré-activés et le nombre total
d’objets en attente s’affiche. Le volet Résultats en bas de la fenêtre se met à jour avec les erreurs
rencontrées pendant l’analyse.
Si l’erreur 1396 ou l’erreur 8440 s’affiche dans le volet d’état, vous utilisez une version préliminaire de
l’outil en version bêta et vous devez la mettre à jour vers la dernière version. - L’erreur 1396 est consignée
si l’outil a utilisé de manière incorrecte un rodc comme dc de référence. - L’erreur 8440 est consignée
lorsque le dc de référence ciblée n’héberge pas de copie accessible en writable de la partition.
Remarques sur la méthode de découverte de l’Objet En attente
Utilise la méthode DRSReplicaVerifyObjects en mode avis.
S’exécute pour tous les DCS et toutes les partitions.
Collecte l’ID d’événement d’objet en attente 1946 et affiche les objets dans le volet de contenu
principal.
La liste peut être exportée vers CSV pour analyse hors connexion (ou modification pour l’importation).
Prend en charge l’importation et la suppression d’objets à partir de l’importation CSV (exploit pour les
objets non découvrables à l’aide de DRSReplicaVerifyObjects).
Prend en charge la suppression d’objets par DRSReplicaVerifyObjects et la modification LDAP rootDSE
remove Nouvelleobjets.
L’outil tire parti de la méthode Advisory Mode exposée par DRSReplicaVerifyObjects que les
repadmin /removelingeringobjects /Advisory_Mode deux et utilisent repldiag /removelingeringobjects .
Outre les événements normalement liés au mode Avis enregistrés sur chaque dc, il affiche chacun des
objets en attente dans le volet de contenu principal.
Les résultats de l’analyse sont enregistrés dans le volet Résultats. De nombreux autres détails de toutes
les opérations sont enregistrés dans le fichier log.txt<Date-TimeStamp> dans le même répertoire que le
fichier exécutable de l’outil.
Le bouton Exporter vous permet d’exporter une liste de tous les objets en attente répertoriés dans le
volet principal dans un fichier CSV. Affichez le fichier dans Excel, modifiez si nécessaire et utilisez le
bouton Importer ultérieurement pour afficher les objets sans avoir à faire une nouvelle analyse. La
fonctionnalité d’importation est également utile si vous découvrez des objets abandonnés (non
découvrables avec DRSReplicaVerifyObjects) que vous devez supprimer.
Remarque sur les objets temporaires temporaires :
Le garbage collection est un processus indépendant qui s’exécute sur chaque dc toutes les 12 heures par
défaut. L’un de ses travaux consiste à supprimer les objets qui ont été supprimés et qui ont été supprimés
en tant que tombstone pendant une durée de vie supérieure au nombre de jours de la durée de vie de
tombstone. Dans le cas d’une période de 12 heures, il existe un objet éligible pour le garbage collection
sur certains DCS, mais qui a déjà été supprimé par le processus de collecte de la garbage collection sur
d’autres DCS. Ces objets seront également signalés comme objets en attente par l’outil, mais aucune
action n’est requise, car ils seront automatiquement supprimés la prochaine fois que le processus de
garbage collector s’exécute sur le dc.
4. Pour supprimer des objets individuels, sélectionnez un seul objet ou sélectionnez plusieurs objets à l’aide
de la touche Ctrl ou Shift. Appuyez sur Ctrl pour sélectionner plusieurs objets ou sur Shift pour
sélectionner une plage d’objets, puis sélectionnez Supprimer .
La barre d’état est mise à jour avec le nouveau nombre d’objets en attente et l’état de l’opération de
suppression :
L’outil vidage une liste d’attributs pour chaque objet avant la suppression et le journal avec les résultats
de la suppression d’objets dans le fichier journal removedLingeringObjects.log.txt de données. Ce fichier
journal se trouve au même emplacement que le fichier exécutable de l’outil. C:\tools<DATE-
TIMEStamp.log.txt
Exemple de contenu du fichier journal :
le DN obj : <GUID=0bb376aa1c82a348997e5187ff012f4a>;
<SID=01050000000000515000000609701d7b0ce8f6a3e529d669f040000>; CN=
<CN_Name>,OU=<OU_Name>,DC=root,DC=contoso,DC=com
objectClass:top, person, organizationalPerson, user;
sn:Schenk;
whenCreated:20121126224220.0Z;
name:<CN_Name>;
objectSid:S-1-5-21-3607205728-1787809456-1721586238-1183;primaryGroupID:513;
sAMAccountType:805306368;
uSNChanged:32958;
objectCategory:<GUID=11ba1167b1b0af429187547c7d089c61>;
CN=Person,CN=Schema,CN=Configuration,DC=root,DC=contoso,DC=com;
whenChanged:20121126224322.0Z;
cn:<CN_Name>;
uSNCreated:32958;
l:Contrôle ;
distinguishedName:<GUID=0bb376aa1c82a348997e5187ff012f4a>;
<SID=01050000000000515000000609701d7b0ce8f6a3e529d669f040000>; CN=
<CN_Name>,OU=<OU_Name>,DC=root,DC=contoso,DC=com;
displayName:<CN_Name>;
st:Contrôle;
dSCorePropagationData:16010101000000.0Z;
userPrincipalName:<User_Name>@root.contoso.com;
givenName:<User_Name>;
instanceType:0;
sAMAccountName:<Account_Name>;
userAccountControl:650;
objectGUID:aa76b30b-821c-48a3-997e-5187ff012f4a;
value is :<GUID=70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e>:<GUID=aa76b30b-821c-48a3-997e-
5187ff012f4a> O=<CN_Name>,OU=<OU_Name>,DC=root,DC=contoso,DC=com is removed from
the directory, code de résultat de réponse mod = Réussite
---------------------------------------------
Réussite renvoyée par Remove EntingObject
Une fois tous les objets identifiés, ils peuvent être supprimés en bloc en sélectionnant tous les objets, puis
Supprimer, ou exportés dans un fichier CSV. Le fichier CSV peut être importé ultérieurement pour une
suppression en bloc. Sachez qu’il existe un bouton Supprimer repadmin /removelingeringobject tout qui
tire parti de la méthode de suppression d’objets en attente
Prise en charge : Bien que cet outil ait été minutieusement testé dans de nombreux environnements, il vous
est fourni tel quelle : aucun support Microsoft officiel n’est fourni.
Pour des questions ou des commentaires sur l’outil :
Ajoutez un commentaire à ce billet de blog, ou envoyez une idée à notre page commentaires UserVoice : veillez
à coder l’idée à l’aide de la catégorie « Outil de recherche d’objets en attente ».
Accédez à l’atelier virtuel TechNet Sur les objets en attente Active Directory de dépannage si vous souhaitez
utiliser cet outil dans un environnement de laboratoire contenant des objets en attente.
Flux de travail
F O N C T IO N N A L IT ÉS D'& ET DE
M ÉT H O DE DE SUP P RESSIO N SUP P RESSIO N D’O B JET S/ PA RT IT IO N S DÉTA IL S
F O N C T IO N N A L IT ÉS D'& ET DE
M ÉT H O DE DE SUP P RESSIO N SUP P RESSIO N D’O B JET S/ PA RT IT IO N S DÉTA IL S
État d’attente de l’objet Suppression par objet et par partition

- Basé sur l’interface graphique
Tire parti des : graphique (GUI)
- Modification de l’objet rootDSE - Affiche rapidement tous les objets en
RemoveToutingObjects LDAP attente dans la forêt à laquelle
- Méthode DRSReplicaVerifyObjects l’ordinateur en cours d’exécution est
joint
- Découverte intégrée via la méthode
DRSReplicaVerifyObjects
- Méthode automatisée pour
supprimer les objets en attente de
toutes les partitions
- Supprime les objets en attente de
tous les DCS (y compris les rodcs),
mais pas les liens en attente
- Windows DCS Server 2008 et
ultérieurs (ne fonctionne pas avec
Windows DCS Server 2003)
Repldiag /remove enobjects Suppression par partition

- Ligne de commande uniquement
Tire parti des : - Méthode automatisée pour
- Méthode DRSReplicaVerifyObjects supprimer les objets en attente de
toutes les partitions
- Découverte intégrée via
DRSReplicaVerifyObjects
- Affiche les objets découverts dans les
événements sur les DCS
- Ne supprime pas les liens en attente.
Ne supprime pas (encore) les objets en
attente des rodcs.
Primitive rootDSE LDAP Suppression par objet

RemoveToutingObjects (généralement - Nécessite une méthode de
exécutée à l’aide LDP.EXE ou d’un script découverte distincte
d’importation LDIFDE) - Supprime un objet unique par
exécution, sauf s’il est écrit par script.
Repadmin /remove enobjects Suppression par partition

- Ligne de commande uniquement
Tire parti des : - Découverte intégrée via
- Méthode DRSReplicaVerifyObjects DRSReplicaVerifyObjects
- Affiche les objets découverts dans les
événements sur les DCS
- Nécessite de nombreuses exécutions
si un nettoyage complet (n * (n-1)) est
nécessaire.
L’outil repldiag et l’outil Outil

d’agrégateur d’objets en attente
automatisent cette tâche.
Résolution de l’erreur de réplication AD 8589 : le
service DS ne peut pas dériver un nom principal de
service (SPN)
Cet article décrit les symptômes, la cause et les étapes de résolution pour les cas où les opérations AD échouent
avec l’erreur Win32 8589.
NOTE
Symptômes
Erreur 8589 : « Les services DS ne peuvent pas dériver un nom principal de service (SPN) avec lequel
s’authentifier mutuellement le serveur cible, car l’objet serveur correspondant dans la base de données DS
locale n’a pas d’attribut serverReference.
Erreur symbolique : ERROR_DS_CANT_DERIVE_SPN_WITHOUT_SERVER_REF
Vous verrez l’une des erreurs/avertissements suivants lors du dépannage de la réplication Active Directory.
1. DCDIAG signale que le test réplications Active Directory a échoué avec l’état d’erreur (8589) : le service
DS ne peut pas dériver d’ith de nom principal de service (SPN) qui authentifier mutuellement le serveur
cible, car l’objet serveur correspondant dans la base de données DS locale n’a pas d’attribut
serverReference.
Un exemple de texte d’erreur issu de DCDIAG est illustré ci-dessous :

[Vérification des réplications,<DC name>] Une tentative de réplication récente a échoué :
Le DS ne peut pas dériver un nom principal de service (SPN) avec lequel s’authentifier mutuellement
le serveur cible, car l’objet serveur correspondant dans la base de données DS locale n’a pas d’attribut
serverReference.
Le dernier succès s’est produit à ( jamais)| <date>.
2. DCDiag.exe affiche l’avertissement suivant :
Un événement d’avertissement s’est produit. EventID: 0x80000785

Heure générée : <DateTime>
Chaîne d’événement : échec de la tentative d’établissement d’un lien de réplication pour la partition
de répertoire accessible en création suivante.
DC=ForestDnsZones,DC=contoso,DC=com
CN=NTDS Paramètres,CN=DCSRV01,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=contosoDC=com
Adresse du contrôleur de domaine source :
<source DC NTDS Settings Obejct GUID>._msdcs.contoso.com
Transport intersite (le caser) :
Ce contrôleur de domaine ne pourra pas répliquer avec le contrôleur de domaine source tant que ce
problème n’aura pas été résolu.
Vérifiez si le contrôleur de domaine source est accessible ou si la connectivité réseau est disponible.
Valeur d’erreur :
8589
serverReference.
3. REPADMIN.EXE signale que la dernière tentative de réplication a échoué avec l’état 8589
REPADMIN Les commandes qui mentionnent généralement l’état 8589 incluent, sans s’y limiter, les
suivantes :
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /REPLSUM
REPADMIN /SYNCALL
Repadmin /showrepl renvoie l’erreur suivante :
Source : <Site Name>\<DC Name>

******* <n> ÉCHECS CONSÉCUTIFS DEPUIS <Date & Time>
Dernière erreur : 8589 (0x218d) :
serverReference.
4. Événements dans le journal des événements des services d’annuaire qui mentionnent l’état d’erreur 8589
Les événements, qui mentionnent généralement l’état 8589, incluent, sans s’y limiter, les suivants :
SO URC E ET ID D’ÉVÉN EM EN T C H A ÎN E DE M ESSA GE
Réplication NTDS /ActiveDirectory_DomainService 1411 Active Directory n’a pas réussi à construire un nom
principal de service d’authentification mutuelle (SPN)
pour le contrôleur de domaine suivant.
Réplication NTDS 2023 Le contrôleur de domaine local n’a pas pu répliquer les
modifications apportées au contrôleur de domaine
distant suivant pour la partition d’annuaire suivante.
KCC NTDS 1925 La tentative d’établissement d’un lien de réplication pour

la partition de répertoire accessible en texte suivante a
échoué.
Cause
L’événement le plus courant se produit sur un dc après qu’un partenaire de réplication a été rétrogradé et
répliqué de force avant d’autoriser la réplication de bout en bout. Cela peut également se produire lorsque vous
renommez un contrôleur de domaine et que l’attribut serverReference n’est pas mis à jour. Dans cette instance,
l’attribut serverReference est l’objet Server consultable dans la MMC Sites et services Active Directory
(adsiedit.msc). L’objet serveur est l’objet parent de l’objet Paramètres NTDS du contrôleur de domaine.
Résolution
Vérifiez que l’attribut serverReference n’est pas manquant ou qu’il a une valeur incorrecte et mettez-le à jour
avec la valeur correcte.
1. Recherchez le contrôleur de domaine référencé dans l’ID d’événement 1411. Il existe quelques options
que nous pouvons utiliser pour le trouver. La méthode la plus simple consiste à utiliser ping (option A). Si
ping échoue, utilisez PowerShell (option B). Si PowerShell n’est pas une option, vous pouvez utiliser
ldp.exe (option C). (Remarque : si vos DCS sont 2003 et que vous n’êtes pas en mesure d’installer
PowerShell dessus, vous pouvez utiliser PowerShell à partir d’un client joint au domaine Windows 7 ou
d’un serveur Windows 2008 ou Windows 2008 R2)
Option A
Utilisez NSLookup ou ping pour rechercher le dc répertorié dans <source DC NTDS Settings Obejct
GUID>._msdcs.contoso.com
Exemple :
Ping 3dab7f9b-92e7-4391-b8db-71df532c1493._msdcs.contoso.com
Pinging DCSRV02.contoso.com [IP] with 32 bytes of data :
Reply from [IP]: bytes=32 time<1ms TTL=128

Option B
Utilisez PowerShell pour rechercher le dc référencé. Vous pouvez utiliser deux méthodes PowerShell. Pour
ce faire, ouvrez le « Module Active Directory pour Windows PowerShell »
Méthode 1 : Exécutez les deux cmdlets PowerShell suivantes. Dans la première cmdlet, remplacez le nom
de la partition CN=Configuration,DC=contoso,DC=com par le nom complet de votre partition de
configuration. Remplacez le nom du serveur DCSRV01.contoso.com par le nom de votre contrôleur de
domaine. Dans la deuxième cmdlet, remplacez le GUID 3dab7f9b-92e7-4391-b8db-71df532c1493 par le
GUID de votre ID d’événement 1411.
$list = Get-ADObject -Filter 'ObjectClass -eq "ntdsdsa"' -SearchBase

'*CN=Configuration,DC=contoso,Dc=com*' -Server *DCSRV01.contoso.com*
-includedeletedobjects -Properties *
foreach ($dc in $list) {if ($dc.ObjectGUID -match "*3dab7f9b-92e7-4391-b8db-71df532c1493*") {Echo

$dc.DistinguishedName }}
Méthode 2 : une autre option PowerShell consiste à exécuter la méthode suivante, puis à effectuer une
recherche dans le fichier texte de sortie. Remplacez le par DCSRV01.contoso.com un dc dans votre
environnement.
Get-ADObject -Filter 'ObjectClass -eq "ntdsdsa"' -SearchBase 'CN=Configuration,DC=contoso,Dc=com' -

Server DCSRV01.contoso.com -includedeletedobjects > C:\NTDSDSA.txt
Recherchez ensuite NTDSA.txt guid référencé dans l’ID d’événement 141

Option C
Utiliser Ldp.exe
a. Cliquez sur Démarrer, puis sur Exécuter
b. Tapez LDP.exe puis appuyez sur Entrée.
c. Dans le menu Connexions, cliquez sur Lier et cliquez sur OK.
d. Dans le menu Affichage, cliquez sur Arborescence.
e. Dans BaseDN, cliquez sur la flèche de liste, cliquez sur le nom de votre partition de configuration et
cliquez sur OK.
f. Dans le menu Options, cliquez sur Contrôles.
g. Dans la boîte de dialogue Contrôles, développez le menu Charger prédéféré, cliquez sur Renvoyer les
objets supprimés et cliquez sur OK.
NOTE
Le contrôle 1.2.840.113556.1.4.417 s’affiche dans la liste Contrôles actifs.
h. Dans le menu Parcourir, cliquez sur Rechercher

i. Dans la zone DN de base, tapez : CN=Sites, CN=Configuration,DC=contoso,DC=com (Remplacez contoso et
com par le nom de domaine approprié.)
j. Dans la zone Filtre, tapez (objectClass=ntdsdsa)
k. Dans la zone Étendue, sélectionnez Sous-arbre
l. Dans la zone Attributs, un * (astérisque)
m. Cliquez sur Exécuter
n. Sur le côté droit, recherchez le GUID dans l’attribut objectGUID pour trouver le serveur référent.
Option D
a. Obtenez repadmin /showrepl une sortie à partir de la destination DC signalant l’état 8589.
b. repadmin /showrepl À l’aide de la sortie obtenue à l’étape précédente, identifiez l’état de réplication
8589 dans la sortie et documentez la date et l’horodat suivant le message de dernière tentative.
c. À l’aide de la date et de l’timestamp de l’étape précédente, recherchez l’ID d’événement correspondant
1411 dans le journal des événements des services d’annuaire sur le dc de destination. Notez que le
GUID repadmin /showrepl de l’objet DSA répertorié dans la sortie est différent de ce qui est signalé
dans l’ID d’événement 1411.( voir l’exemple de scénario ci-dessous)
d. Recherchez ensuite le contrôleur de domaine répertorié dans l’ID d’événement 1411, soit en vérifiant
l’onglet Général des propriétés NTDS Paramètres, soit en pingant le GUID dans l’ID d’événement.
e. Lier au dc source à l’aide d’ADSIEDIT ou d’Utilisateurs et ordinateurs Active Directory et ouvrir l’Éditeur
d’attributs et copier la valeur dans serverReference. Collez la valeur de cet attribut sur la copie DCS de
destination de l’objet. (Étape 2)
2. Une fois que vous avez localisé le serveur référencé à l’aide de l’une des méthodes ci-dessus, utilisez les
méthodes suivantes :
a. Cliquez sur Démarrer, puis sur Exécuter
b. Tapez ADSIEDIT.msc et appuyez sur Entrée
c. Cliquez avec le bouton droit sur « ADSI Edit » et sélectionnez « Connecter à... "
d. Dans « Point de connexion » sous « Sélectionnez un contexte d’attribution de noms connu : »
sélectionnez « Configuration », puis cliquez sur OK.
e. Dans le volet gauche, développez « Configuration »
f. Expand suivant " CN=Configuration,DC=contoso,DC=com »
g. Développez ensuite « CN=Sites »
h. Sous CN=Sites, développez le site dans lequel se trouve le serveur. Exemple : Default-First-Site-Name
i. Sous ce site, développez CN=Serveurs. Exemple : si DCSRV02 se trouve dans le site par défaut
premier site dans Contoso.com, vous devez être dans : CN=DCSRV02, CN=Servers, CN=Default-First-
Site-Name, CN=Sites, CN=Configuration, DC=contoso, DC=com
j. Cliquez avec le bouton droit sur le contrôleur de domaine (trouvé à l’aide de l’option A, B ou C) et
k. Dans l’onglet « Éditeur d’attributs », faites défiler jusqu’à l’attribut serverReference.
l. Le serverReference doit être similaire à CN=DCSRV02,OU=Domain Controllers,DC=Contoso,DC=com
S’il est manquant ou incorrect, modifiez-le à la valeur correcte.
m. Fermer ADSIEDIT.msc
Exemple de scénario
1. Obtenez une sortie repadmin /showrepl à partir de la destination DC signalant l’état 8589.
2. À l’aide de la sortie repadmin /showrepl obtenue à l’étape précédente, identifiez l’état de réplication 8589
dans la sortie et documentez la date et l’horodat suivant le message de dernière tentative.
Repadmin /showrepl sortie :
Options de Contrôle\CONTRÔLECONTOSODCDSA : IS_GC

DSA invocationID : <InvocationID>
DC=Contoso,DC=com
Pér\CONTOSOROOTDC1 via RPC
La dernière tentative @ <DateTime> a réussi.
CN=Configuration,DC=Contoso,DC=com
Domaine\5THWARDCORPDC via RPC
Last attempt @ <DateTime> failed, result 8589 (0x218d) :
serverReference.
Dernière réussite @ ( jamais).
À l’aide de la date et de l’timestamp de l’étape précédente, recherchez l’ID d’événement correspondant 1411
dans le journal des événements des services d’annuaire sur le dc de destination. Notez que le GUID de l’objet
DSA répertorié dans la sortie repadmin /showrepl est différent de ce qui est signalé dans l’ID d’événement
1411.
Journal des événements des services d’annuaire :

Date : <DateTime>
Niveau : Error
Ordinateur : LIVCONTOSODC.Contoso.com
Description :
Les services de domaine Active Directory n’ont pas réussi à construire un nom principal de service
d’authentification mutuelle (SPN) pour le service d’annuaire suivant.
Service d’annuaire : <GUID>._msdcs.Contoso.com
L’appel a été refusé. La communication avec ce service d’annuaire peut être affectée.
Valeur d’erreur :
8589 Le DS ne peut pas dériver un nom principal de service (SPN) avec lequel s’authentifier mutuellement
serverReference.
Cliquez sur Annuler, puis affichez les propriétés de l’objet serveur (5thWardCorpDC dans cet exemple)
sélectionnez l’onglet Éditeur d’attributs (Server 2008 et ultérieur) ou utilisez ADSIEDIT pour modifier l’objet sur
Server 2003
Notez que l’attribut serverReference n’est pas définie dans l’image suivante
Lier au dc source à l’aide d’ADSIEDIT ou d’Utilisateurs et ordinateurs Active Directory et ouvrir l’Éditeur
d’attributs et copier la valeur dans serverReference. Collez la valeur de cet attribut sur la copie DCS de
destination de l’objet.
Une fois que l’attribut serverReference est correctement définie pour le contrôleur de domaine, voici ce qui suit :
Utilisation du pack d’outils d’administration pour
administrer à distance les ordinateurs exécutant
Windows Server 2003, Windows XP ou Windows
2000
Cet article explique comment administrer à distance des ordinateurs à l’aide du pack d’outils d’administration.
S’applique à : Windows 10 - toutes les éditions, Windows 7 Service Pack 1, Windows Server 2012 R2
Résumé
Cet article décrit les options d’administration des ordinateurs exécutant Windows Server 2003, Windows XP ou
Microsoft Windows 2000. En outre, cet article explique comment télécharger Windows Server 2003
Administration Tools Pack (Adminpak). Cet article traite également des différents problèmes de compatibilité qui
se produisent lorsque vous administrez à distance des ordinateurs basés sur Windows 2000 à partir
d’ordinateurs Windows XP et d’ordinateurs basés sur Windows Server 2003 et inversement.
Introduction
Les rubriques suivantes sont abordées dans cet article :
Options d’administration à distance des ordinateurs exécutant Windows Server 2003, Windows XP ou
Windows 2000.
Emplacements de téléchargement des versions d’origine (RTM), Service Pack 1 et Service Pack 2 du pack
d’outils d’administration Windows Server 2003
Problèmes spécifiques à l’administration des versions 64 bits de Windows
Les problèmes de compatibilité qui se produisent lorsque Windows 2000 Professional ordinateurs sur
Windows 2000 qui ont des outils d’administration Windows 2000 sont mis à niveau vers Windows XP.
Problèmes de compatibilité qui se produisent lorsque Windows contrôleurs de domaine basés sur 2000 sont
mis à niveau vers Windows contrôleurs de domaine basés sur Server 2003.
Problèmes connus qui peuvent se produire lorsque vous utilisez les outils d’administration des versions
d’origine (RTM), Service Pack 1 et Service Pack 2 du pack d’outils d’administration Windows Server 2003
pour gérer les ordinateurs basés sur Windows 2000, Windows XP et Windows Server 2003
Options d’administration à distance
L’expérience administrative la plus transparente se produit lorsque l’ordinateur utilisé pour effectuer des tâches
administratives exécute le même système d’exploitation que l’ordinateur qui est administré à distance.
Windows Les supports d’installation de Server 2003 et Windows 2000 contiennent des outils d’administration
graphique et de ligne de commande qui peuvent être utilisés localement et dans la plupart des cas à distance
pour administrer des systèmes d’exploitation de niveau supérieur et inférieur avec un haut degré
d’interopérabilité.
Pour administrer à distance les ordinateurs exécutant Windows Server 2003 ou Windows 2000 à partir
d’ordinateurs exécutant Windows Server 2003, Windows XP ou Windows 2000, utilisez l’une des méthodes
suivantes :
Installez et utilisez des outils d’administration graphique empaquetés dans le pack d’outils
d’administration pour administrer à distance les ordinateurs exécutant Windows Server 2003, Windows
XP ou Windows 2000. Lorsque des problèmes d’interopérabilité existent entre les systèmes d’exploitation,
effectuez des tâches administratives sur la console de l’ordinateur cible ou sur un ordinateur qui exécute
le même système d’exploitation que l’ordinateur qui est administré à distance.
Utilisez les services Terminal Services pour administrer à distance les ordinateurs qui ont des outils
d’administration d’interface utilisateur graphique et de ligne de commande installés localement. Pour
éviter la limite à deux sessions, vous pouvez utiliser le mode serveur d’applications pour créer une
installation basée sur Windows Server 2003 ou Windows 2000 qui exécute terminal server ou terminal
services. Lorsque des problèmes d’interopérabilité existent entre les systèmes d’exploitation, effectuez
des tâches administratives à partir d’un serveur sur lequel Terminal Server ou les services Terminal
Server sont activés et qui exécute le même système d’exploitation que l’ordinateur distant qui est
administré.
Utilisez des outils et des scripts de ligne de commande pour administrer localement et à distance les
ordinateurs exécutant Windows Server 2003, Windows XP ou Windows 2000. Ces outils et scripts
incluent les interfaces ADSI (Active Directory Service Interfaces), les commandes Windows Net.exe et les
outils empaquetés avec Suptools.msi. Lorsque des problèmes d’interopérabilité existent entre les
systèmes d’exploitation, effectuez des tâches administratives sur la console de l’ordinateur cible ou sur un
ordinateur désigné pour les tâches administratives qui exécutent le même système d’exploitation que
l’ordinateur distant qui est administré. Par exemple, les outils de support Windows Server 2003 Service
Pack 2 (SP2) s’installeront sur un ordinateur exécutant Windows XP Professional. Toutefois, il n’est pas
garanti que les outils fonctionnent correctement dans ce scénario. Les outils connus pour être
problématiques sont les suivants :
Dfsutil.exe
Netdiag.exe
Netcap.exe
Ntfrsutil.exe
Si vous souhaitez exécuter ces outils sur un ordinateur Windows Server 2003 SP2, nous vous recommandons
de les exécuter à partir d’un ordinateur exécutant Windows Server 2003 SP2. Vous pouvez utiliser la
fonctionnalité Bureau à distance pour vous connecter à un ordinateur Windows Server 2003 SP2 qui exécute les
outils de support.
Windows Packs d’outils d’administration Windows Server 2000 server 2003 et 2000
Pour faciliter la gestion à distance de vos serveurs, Microsoft a généralement inclus des outils d’administration
graphique dans un fichier auto-extracteur nommé Adminpak.msi (Adminpak).
NOTE
Sur les versions 64 bits de Windows Server 2003, ce fichier est appelé Wadminpak.msi.
Le pack d’outils d’administration Windows 2000 se trouve dans le dossier I386 du CD de la famille de serveurs
Windows 2000 et s’installe sur les ordinateurs exécutant Windows 2000. La plupart des outils de Windows
2000 Adminpak peuvent administrer à distance Windows 2000 en plus des versions 32 bits et 64 bits de
Windows XP Professional et des versions 32 bits et 64 bits de Windows Server 2003.
Le pack d’outils d’administration Windows Server 2003 se trouve dans le dossier I386 du CD-WINDOWS Server
2003 et est disponible en téléchargement gratuit le. www.microsoft.com Le tableau suivant récapitule les
systèmes d’exploitation sur lesquels vous pouvez installer le adminpak à partir de Windows 2000, de Windows
Server 2003 original (RTM), de Windows Server 2003 Service Pack 1 (SP1) ou de Windows Server 2003 Service
Pack 2. En outre, le tableau récapitule les systèmes d’exploitation que les adminpaks de ces sources peuvent
administrer à distance.
W IN DO W S
A DM IN PA K O UT IL
W IN DO W S ( RT M ) W IN DO W S W IN DO W S D’A DM IN IST RAT I
SERVER D’O RIGIN E DE SERVER 2003 SP 1 SERVER 2003 SP 2 O N DE SERVEUR
A DM IN PA K 2000 SERVER 2003 A DM IN PA K A DM IN PA K DISTA N T ( RSAT )
Installe et
s’exécute sur
ces systèmes
d’exploitation
Windows Non Oui Oui Oui

Famille 32 bits
Ser ver 2003
Windows Non Non Oui Oui

Famille 64 bits
Ser ver 2003
Windows XP Non Oui Oui Oui

Professional
ser vice pack 2
Windows XP Non Oui Oui Oui

Professional
SP1 ou
versions
ultérieures
Windows XP Non Non Oui Oui

Professional
édition 64 bits
Windows 2000 Oui Non Non Non

Professionnel
Windows Oui Non Non Non

famille de
ser veurs 2000
Windows Vista Non Non Non Non Oui, RSAT pour

Windows Vista
Windows 7 Non Non Non Non Oui, RSAT pour

Windows 7
Windows Non Non Non Non Oui, RSAT pour

Ser ver 2008 Windows Server
2008
Windows Non Non Non Non Oui, RSAT pour

Ser ver 2008 Windows Server
R2 2008
W IN DO W S
A DM IN PA K O UT IL
W IN DO W S ( RT M ) W IN DO W S W IN DO W S D’A DM IN IST RAT I
SERVER D’O RIGIN E DE SERVER 2003 SP 1 SERVER 2003 SP 2 O N DE SERVEUR
A DM IN PA K 2000 SERVER 2003 A DM IN PA K A DM IN PA K DISTA N T ( RSAT )
Gère à
distance ces
systèmes
d’exploitation
Windows Oui Oui Oui Oui

Famille 32 bits
Ser ver 2003

Famille 64 bits
Ser ver 2003

famille de
ser veurs 2000
Windows Vue d’ensemble de l’installation et de la compatibilité du pack d’outils d’administration Server 2003
Si vous souhaitez administrer à distance des ordinateurs membres et des contrôleurs de domaine Windows
Server 2003 ou Windows 2000 à partir de clients Windows Server 2003 ou de clients basés sur Windows XP
Professional, notez les problèmes d’installation suivants :
Vous devez supprimer les versions bêta antérieures du pack d’outils d’administration Windows Server
2003 avant d’installer la version finale.
NOTE
Dans certains cas limités, les serveurs doivent être administrés à partir de clients qui exécutent le même système
d’exploitation. Par exemple, certaines opérations d’administration à distance sur Windows serveurs basés sur 2
000 ne peuvent être effectuées qu’à partir Windows clients basés sur 2 000. De même, certaines opérations sur
des ordinateurs basés sur Windows Server 2003 peuvent être effectuées uniquement à partir de clients basés sur
Windows Server 2003 ou de clients basés sur Windows XP. Cet article décrit ces limitations ou restrictions pour
chaque outil inclus dans le pack d’outils d’administration.
Si vous ne désinstallez pas les versions antérieures du pack d’outils d’administration (Adminpak.msi)
avant la mise à niveau vers Windows Server 2003 Service Pack 2, le pack d’outils d’administration ne
peut pas être désinstallé après la mise à niveau. Si vous essayez de désinstaller le pack d’outils
d’administration par le biais d’Ajout ou de Suppression de programmes ou en exécutant Adminpak.msi,
vous recevez les messages d’erreur suivants :
Windows Server 2003 Administration Tools Pack peut uniquement être installé sur Windows XP
Professional avec le correctif Q329357 appliqué, sur Windows XP Professional Service Pack 1 ou
versions ultérieures, ou sur des ordinateurs exécutant des systèmes d’exploitation Windows Server
2003.
Échec de l’installation : en raison d’une erreur, Windows l’Assistant Installation du pack d’outils
d’administration Server 2003 n’a pas pu se terminer.
Vous ne pouvez pas installer le fichier Windows 2000 Adminpak.msi sur des ordinateurs basés sur
Windows Server 2003 ou sur des clients Windows XP. Ces outils ne fonctionnent plus sur ces systèmes
d’exploitation et ne sont pas pris en charge. Utilisez la version Windows Server 2003 du pack d’outils
d’administration sur Windows ordinateurs XP.
Le Windows Pack d’outils d’administration server 2003 ne peut pas être installé ou exécuté sur Windows
ordinateurs basés sur 2000. Si vous essayez d’installer Windows Server 2003 Administration Tools Pack
sur un ordinateur Windows 2000, Vous recevez le message d’erreur suivant : le pack d’outils
d’administration Windows Server 2003 ne peut être installé que sur Windows XP Professional avec le
correctif Q329357 appliqué, sur Windows XP Professional SP1 ou ultérieur, ou sur des ordinateurs
exécutant des systèmes d’exploitation Windows Server 2003.
Insématisation au niveau du Service Pack. Obtenez le pack d’outils d’administration qui correspond au
niveau service pack de votre système d’exploitation.
De même, les utilitaires de ligne de commande du pack d’outils d’administration Windows Server 2003
s’exécutent uniquement sur les ordinateurs exécutant Windows XP ou Windows Server 2003. Les
utilitaires de ligne de commande du pack d’outils d’administration Windows Server 2003 ne s’exécutent
pas s’il existe une insérialisation de DLL ou une erreur de point d’entrée. Ce type d’insatiste ou d’erreur
peut se produire si vous copiez les utilitaires sur un ordinateur Windows 2000. Si vous essayez d’installer
le pack d’outils d’administration Windows 2000 sur un ordinateur Windows Server 2003, vous recevez le
Windows outils d’administration 2000 sont incompatibles avec Windows d’exploitation Server 2003.
Installez Windows Pack d’outils d’administration Server 2003.
Windows XP Professional n’inclut pas le fichier Adminpak.msi Windows Server 2003, car ces outils font
partie du produit Windows Server 2003 et sont livrés lorsque ce produit est publié.
Si vous utilisez Windows XP Professional service pack 2 et le pack d’outils d’administration Windows
Server 2003, vous ne pouvez pas administrer les serveurs de cluster. Toutefois, si vous utilisez Windows
XP Professional avec SP1 et le pack d’outils d’administration Windows Server 2003, vous pouvez gérer
les serveurs de cluster.
La Windows outils d’administration Server 2003 fonctionnent de la même manière que Windows 2000.
Parfois, les outils d’administration Windows Server 2003 offrent des fonctionnalités accrues par rapport à
leurs équivalents Windows 2000. Par exemple, la nouvelle fonctionnalité glisser-déposer du logiciel en
ligne utilisateurs et ordinateurs Windows Server 2003 est entièrement fonctionnelle par rapport aux
contrôleurs de domaine Windows 2000. Dans d’autres cas, l’augmentation des fonctionnalités des outils
d’administration Windows Server 2003 n’est pas allumée ou n’est pas prise en charge lorsque vous
administrez des ordinateurs basés sur Windows 2000.
Par exemple, les fonctionnalités des outils d’administration qui dépendent des fonctionnalités de Windows
Server 2003, telles que la fonctionnalité « Requête enregistrée pour la dernière fois » ne sont pas pris en charge
sur les ordinateurs basés sur un serveur Windows 2000, car les serveurs de version antérieure ne disposent pas
de la prise en charge côté serveur requise. Dans de rares cas, les outils d’administration Windows Server 2003
sont incompatibles avec les ordinateurs basés sur un serveur Windows 2000 et ne sont pas pris en charge pour
gérer ces ordinateurs. De même, dans de rares cas, Windows outils d’administration 2000 sont incompatibles
avec Windows ordinateurs basés sur Server 2003.
Mettre à niveau Windows 2000 ordinateurs vers Windows Server 2003 ou vers Windows XP
Lorsqu’un ordinateur Windows 2000 sur qui Windows 2000 Adminpak est installé est mis à niveau vers
Windows Server 2003 ou Windows XP, le rapport de compatibilité système qui s’affiche dans le processus de
mise à niveau signale que les outils d’administration Windows 2000 sont incompatibles avec Windows Server
2003 ou avec Windows XP. Si vous cliquez sur Détails, vous recevez le message d’erreur suivant : le
programme d’installation Windows outils d’administration 2000 sur votre ordinateur. Windows outils
d’administration 2000 sont incompatibles avec Windows d’exploitation Server 2003. Utilisez l’une des méthodes
suivantes :
Annulez cette mise à niveau, supprimez Windows Outils d’administration 2000, puis redémarrez la mise à
niveau.
Terminez cette mise à niveau, puis installez immédiatement Windows Pack d’outils d’administration Server
2003 en exécutant le fichier de package Adminpak.msi Windows Installer. Adminpak.msi se trouve dans le
dossier \i386 de votre CD-WINDOWS Server 2003.
NOTE
Si les outils d’administration Windows 2000 ont été mis en place lors de la mise à niveau de l’ordinateur Windows 2000
vers Windows Server 2003, n’essayez pas de supprimer l’icône Outils d’administration Windows 2000 qui apparaît dans
l’élément Ajouter ou supprimer des programmes du Panneau de commande.
Si vous essayez de supprimer les outils d’administration Windows 2000 à l’aide de l’outil Ajouter ou supprimer
des programmes, vous pouvez recevoir le message d’erreur suivant :
Boîte de dialogue apphelp annulée, empêchant ainsi le démarrage de l’application.
Ignorez ce message d’erreur. Lorsque vous installez le pack d’outils d’administration Windows Server 2003,
l’icône outils d’administration Windows 2000 est remplacée par l’icône du pack d’outils d’administration
Télécharger et installer le pack d’outils d’administration Windows Server 2003 sur Windows XP Professional
32 bits et 64 bits Windows Server 2003
Vous pouvez installer la version d’origine du pack d’outils d’administration Windows Server 2003 sur les
ordinateurs exécutant les systèmes d’exploitation suivants :
Windows XP Professional service pack 2
Windows Server 2003, versions 32 bits La version d’origine du fichier Windows Server 2003 Adminpak.msi
a été repackaged sur le site Web Microsoft en tant que Adminpak.exe après la publication de Windows
Server 2003.
Vous pouvez installer la version Service Pack 1 du pack d’outils d’administration Windows Server 2003 sur les
ordinateurs exécutant les systèmes d’exploitation suivants :
Windows XP Professional édition 64 bits
Windows Server 2003, versions 32 bits
Windows Server 2003, versions 64 bits La dernière révision du pack d’outils d’administration Windows
Server 2003 est la version Windows Server 2003 Service Pack 2. Vous pouvez installer la version Service
Pack 2 du pack d’outils d’administration Windows Server 2003 sur les ordinateurs exécutant les systèmes
Windows XP Professional édition 64
Windows Server 2003 All Editions (32 bits x86)
Windows Server 2003 Itanium-based Edition
Windows Server 2003 x64 Editions
Windows Server 2003 R2 Editions
Windows Server 2003 Stockage Server R2 Edition
Windows Server 2003 Compute Cluster Edition
Windows Server 2003 for Small Business Servers R2 Edition
NOTE
La version de Adminpak incluse dans le dossier I386 du support d’installation pour les versions 64 bits de Windows
Server 2003 est appelée Wadminpak.msi. Le fichier Wadminpak.msi est identique au fichier Adminpak.msi qui peut être
téléchargé et qui est inclus avec les www.microsoft.com versions 32 bits de Windows Server 2003 Service Pack 2. Pour
faciliter l’installation, vous pouvez installer le fichier Adminpak.msi Windows Server 2003 SP2 sur les versions 32 bits ou
64 bits de Windows XP Professional ou sur les versions 32 bits ou 64 bits de Windows Server 2003. De même, vous
pouvez installer Wadminpak.msi sur les versions 32 bits ou 64 bits de Windows XP Professional ou sur les versions 32 ou
64 bits de Windows Server 2003.
Pour installer Windows Pack d’outils d’administration Server 2003, suivez les étapes suivantes :
1. Téléchargez Windows Pack d’outils d’administration De Server 2003 Service Pack 2. Pour ce faire, visitez
le site Web Microsoft suivant : Centre de téléchargement Microsoft
Effectuez une recherche par mot clé pour « adminpak » pour le système d’exploitation « Windows XP » ou
« Windows Server ».
2. Connectez-vous à l’ordinateur local à l’aide des informations d’identification de l’administrateur.
3. Supprimez les versions antérieures du pack d’outils d’administration.
Vous devez supprimer les versions antérieures du pack d’outils d’administration avant de pouvoir
installer une version ultérieure, y compris la version finale.
Si vous ne pouvez pas utiliser Ajouter ou supprimer des programmes dans le Panneau de contrôle pour
supprimer des versions antérieures du pack d’outils d’administration, vous pouvez utiliser l’outil MSIZap
du package Support\Tools\Suptools.msi pour supprimer l’ancien package mis en cache.
Si la Windows Server 2003 Beta 3 du pack d’outils d’administration est installée, suivez les étapes
suivantes :
a. Enregistrez le texte suivant en tant que fichier nommé Rrasreg.cmd :
rem
rem RAS user snap-in extension - registry key cleanup, Beta 3 to RC1
rem upgrades only.
rem
rem use Reg.exe to delete the old key that was created by the Beta 3
rem RAS user extension snapin.
rem
reg delete HKEY_CLASSES_ROOT\RasDialin.UserAdminExt /f
reg delete HKEY_CLASSES_ROOT\RasDialin.UserAdminExt.1 /f
reg delete HKLM\SOFTWARE\Microsoft\MMC\NodeTypes\{19195a5b-6da0-11d0-afd3-
00c04fd930c9}\Extensions\NameSpace /f
b. Tapez Rrasreg.cmd à l’invite de commandes.

4. Installez le pack d’outils d’administration.
Adminpak.exe est un fichier à extraction autonome qui crée le fichier Adminpak-readme.txt et le fichier
Adminpak.msi dans un dossier que vous spécifiez lorsque vous installez le fichier. Pour installer le pack
d’outils d’administration, cliquez avec le bouton droit sur .msi fichier, puis cliquez sur Installer ou double-
cliquez sur .msi fichier. Sinon, à l’aide de la stratégie de groupe, vous pouvez utiliser Active Directory pour
installer à distance ou publier le fichier sur un ordinateur basé sur Windows XP ou sur un ordinateur
Windows Server 2003 lorsqu’un utilisateur se connecte à l’ordinateur.
Pour plus d’informations sur l’installation à distance du pack d’outils d’administration, cliquez sur les
numéros d’article suivants pour afficher les articles de la Base de connaissances Microsoft :
816102 utiliser la stratégie de groupe pour installer à distance des logiciels dans Windows Server 2003
NOTE
Lorsque vous mettre à niveau un serveur Windows 2000 vers Windows Server 2003, le contrôle de compatibilité
système dans Windows Server 2003 Winnt32.exe ou dans le processus Winnt32 /checkupgradeonly peut détecter
de manière incorrecte que le pack d’outils d’administration a été installé sur votre contrôleur de domaine Windows
2000. Ce problème se produit car l’Assistant Installation d’Active Directory (Dcpromo.exe) sur Windows 2000
utilise une fonctionnalité du fichier adminpak Windows 2000 pour créer des éléments de menu raccourci pour les
outils d’administration de domaine. Vous pouvez ignorer ce message en toute sécurité et poursuivre le processus
de mise à niveau de Windows 2000 vers Windows Server 2003.
À quoi s’attendre de la version d’origine du pack d’outils d’administration Windows Server 2003
Avant de contacter les services de support technique Microsoft( CSS), consultez les problèmes de
compatibilité connus décrits dans cet article et notez la date de publication de leur résolution.
Vous devez supprimer les versions antérieures de Adminpak.msi (Bêta 3, RC1, RC2) avant d’installer
Windows XP SP1 sur votre ordinateur Windows XP. Si vous avez installé Windows XP SP1 sur un
ordinateur basé sur Windows XP sur la version bêta 3 du pack d’outils d’administration, vous ne pouvez
pas utiliser Ajouter ou supprimer des programmes dans le Panneau de contrôle pour supprimer des
versions antérieures du pack d’outils d’administration.
Windows Les ordinateurs XP Édition Familiale ne peuvent pas joindre des domaines Microsoft Windows
NT 4.0, Windows 2000 ou Windows Server 2003. Windows XP Édition Familiale n’est pas un système
d’exploitation pris en charge pour les installations du pack d’outils d’administration.
Que faire en cas de problèmes d’administration à distance ?
1. Confirmez que vous utilisez la dernière version prise en charge des Adminpak.msi logiciels en ligne et
des fichiers DLL disponibles à partir du site Web Microsoft. Vous pouvez utiliser le script APVer.vbs inclus
dans la version d’origine du package de téléchargement Web Adminpak pour déterminer la version du
pack d’outils d’administration que vous avez installé sur votre ordinateur. Pour ce faire, modifiez le dossier
dans lequel vous avez développé Adminpak.exe, puis tapez apver /? pour voir la liste des options de ce
script de diagnostic.
2. Consultez les problèmes de compatibilité connus décrits dans cet article pour déterminer si le problème
est connu.
3. Informez le support technique microsoft ou votre fournisseur de support.
Problèmes connus pour la version Windows Server 2003 de la version d’origine de Adminpak.msi
Problèmes d’installation et de mise à niveau
Windows Server 2003 Winnt32.exe et le processus Winnt32 /checkupgradeonly sur les contrôleurs de domaine
Windows 2000 signalent que Adminpak.msi est installé lorsqu’il n’a jamais été installé ou lorsqu’il a déjà été
supprimé.
Ce problème se produit car l’Assistant Installation d’Active Directory (Dcpromo.exe) dans Windows 2000 utilise
une fonctionnalité interne de la version Windows 2000 de Adminpak.msi pour installer les raccourcis de menu
sur les contrôleurs de domaine. Vous pouvez ignorer cet avertissement en toute sécurité dans Winnt32.exe et
poursuivre la mise à niveau. Une fois la mise à niveau terminée, installez la version Windows Server 2003 de
Adminpak.msi à partir du dossier I386 du support d’installation pour vous assurer que vous avez la dernière
version des outils d’administration de domaine.
Domaines et trusts Active Directory
La version d’origine du pack d’outils d’administration Windows Server 2003 introduit la signature LDAP
(Lightweight Directory Access Protocol). Windows 2 000 contrôleurs de domaine qui sont administrés à
distance par des ordinateurs basés sur Windows 2000 qui exécutent le Service Pack 4 (SP4), par des
ordinateurs Windows XP ou par des ordinateurs basés sur Windows Server 2003 qui utilisent
l’authentification NTLM doivent avoir installé Windows 2000 Service Pack 3.
Si vous utilisez un ordinateur Windows 2000 pour administrer des domaines basés sur Windows Server 2003,
les fonctionnalités avancées d’interface utilisateur ne sont pas pris en charge par les domaines basés sur
Windows Server 2003. Par exemple, vous ne voyez pas les fonctionnalités de domaine et de forêt ou les trusts
avancées.
Schéma Active Directory
La version d’origine de Windows Server 2003 Administration Tools Pack introduit la signature LDAP.
Windows 2 000 contrôleurs de domaine qui sont administrés à distance par des ordinateurs basés sur
Windows 2000 qui exécutent le Service Pack 4 (SP4), par des ordinateurs Windows XP ou par des
ordinateurs basés sur Windows Server 2003 qui utilisent l’authentification NTLM doivent avoir installé
Windows 2000 SP3.
Le schéma peut être modifié dans cette case à cocher Contrôleur de domaine qui a été supprimée
de la boîte de dialogue Modifier le contrôleur de schéma. Par défaut, les mises à jour de schéma sont
activées Windows contrôleurs de domaine basés sur Server 2003.
Sites et services Active Directory
La version d’origine du pack Windows Server 2003 Administration Tools inclut la signature LDAP.
Windows 2000 SP3.
La modification des modèles de certificat n’est pas prise en charge.
Lorsque vous cliquez sur Afficher le nœud Services dans le menu Affichage, la commande Activée pour
le nœud Services a été supprimée sur Windows clients XP.
Lorsque la version Service Pack 1 des sites et services Active Directory est démarrée sur des systèmes 64
bits, il est possible qu’elle ne modifie pas la stratégie de groupe. En outre, le message d’erreur suivant
s’affiche :
Windows’est pas en mesure de trouver gpedit.msc. Assurez-vous que vous avez tapé le nom
correctement, puis essayez à nouveau. Pour rechercher un fichier, cliquez sur le bouton Démarrer, puis sur
Rechercher.
Modifiez la syntaxe de votre ligne de commande ou raccourci pour utiliser la syntaxe suivante :
%windir%\syswow64\mmc.exe %systemroot%\system32\dssite.msc -32
Il n’existe aucun problème connu lorsque Windows forêts basées sur 2000 sont administrées à partir de
clients Windows Server 2003 ou de clients basés sur Windows XP Professional.
La version d’origine du pack Windows Server 2003 Administration Tools inclut la signature LDAP.
Windows 2000 SP3.
L’onglet Numérotation qui configure les paramètres d’accès à distance et de routage ou d’accès VPN et de
rappel est supprimé lorsque la version d’origine du pack d’outils d’administration est installée sur les
clients basés sur Windows XP.
Les solutions ou solutions de contournement de ce problème sont les suivantes :
Installez Q837490 sur le client pré-Service Pack 2 Windows XP. Ce correctif logiciel ajoute l’onglet
d’accès à distance des clients basés sur XP Windows pré-Service Pack 2 qui exécutent la version
d’origine du composant logiciel en ligne Utilisateurs et ordinateurs Active Directory Server 2003
Windows Server 2003, Dsa.msc, qui est installé par la version d’origine du Adminpak.msi
Installez la version Windows Server 2003 Service Pack 2 d’Adminpak sur les ordinateurs basés sur
Windows XP sur Windows XP Service Pack 2 ou versions ultérieures.
Utiliser la stratégie d’accès à distance.
Démarrez Utilisateurs et ordinateurs Active Directory à partir d’un ordinateur Windows Server
2003 ou d’un ordinateur Windows 2000 accessible sur les services Terminal Server ou l’accès
bureau à distance.
Démarrez Utilisateurs et ordinateurs Active Directory à partir de la console d’un ordinateur
Windows Server 2003 ou d’un ordinateur Windows 2000.
Pour gérer les propriétés d’accès au compte d’utilisateur, utilisez le modèle d’administration de stratégie
d’accès à distance. Le modèle d’administration de stratégie d’accès à distance a été introduit dans
Windows 2000 pour répondre aux limitations du modèle d’autorisation de compte d’accès à distance
précédent. Le modèle d’administration de stratégie d’accès à distance utilise Windows pour gérer les
autorisations d’accès à distance.
Les clients qui utilisent le modèle d’administration recommandé nommé « modèle d’administration de stratégie
d’accès à distance » peuvent utiliser le package d’administration de Windows XP pour gérer les autorisations
d’accès à distance pour les utilisateurs dans Active Directory. Paramètres sous l’onglet Dial-in ne sont
généralement pas utilisés pour les déploiements VPN ou sans fil. Il existe plusieurs exceptions. Par exemple, les
administrateurs qui déploient des réseaux de numérotation peuvent utiliser le numéro de rappel. Dans ce cas,
utilisez les services Terminal Server ou bureau à distance pour accéder à un ordinateur Windows Server 2003
ou Windows 2000, ou connectez-vous à la console d’un ordinateur Windows Server 2003 ou d’un ordinateur
Windows 2000 pour gérer l’onglet Numérotation.
Le modèle d’administration des stratégies d’accès à distance présente les avantages suivants :
Administration détaillée
Les administrateurs qui gèrent l’autorisation d’accès doivent également avoir accès à l’intégralité du compte
d’utilisateur. Le compte d’utilisateur possède beaucoup plus de propriétés de sécurité. Dans le modèle
d’administration de stratégie, un groupe distinct peut être créé pour accorder des autorisations de connexion. En
outre, les autorisations de gestion de l’accès à ce groupe peuvent être accordées à un autre administrateur.
Groupes pour le contrôle d’accès
La plupart des programmes Windows Microsoft utilisent des groupes pour le contrôle d’accès. Les groupes
réduisent la tentative supplémentaire de gestion de l’accès réseau des autorisations distinctes. Vous pouvez
utiliser les mêmes groupes pour contrôler l’accès aux appels d’accès, VPN, réseau sans fil ou partages de
fichiers.
Contrôle de stratégie d’accès spécifique à la connexion
De nombreux défis sont introduits lorsque vous déployez plusieurs technologies d’accès en même temps. Les
autorisations et les paramètres des technologies de numérotation, VPN et sans fil peuvent être différents. Par
exemple, les sous-traitants peuvent être autorisés à accéder aux réseaux sans fil, mais ne peuvent pas être
autorisés à se connecter à partir de leur domicile par VPN. La technologie sans fil peut nécessiter différents
paramètres de sécurité en ce qui concerne les connexions VPN et d’accès à l’accès. Les paramètres de rappel
peuvent être utiles lorsque vous vous connectez à partir d’un code de zone locale. Toutefois, vous pouvez
désactiver le rappel lorsque l’utilisateur se connecte à partir d’un numéro de téléphone international.
Vous pouvez configurer le modèle d’administration de stratégie d’accès à distance dans le nœud Stratégies
d’accès à distance du logiciel enfichable Routage et Accès à distance lorsque le domaine est configuré en mode
natif Windows 2000 ou une version ultérieure. Pour gérer à distance l’onglet Accès à distance dans Utilisateurs
ou ordinateurs Active Directory ou dans internet Authentication Server (IAS) à partir d’un ordinateur basé sur
Windows XP, utilisez les services Terminal Server ou bureau à distance pour accéder à un ordinateur Windows
Server 2003 ou Windows 2000. Vous pouvez également vous connecter à la console d’un ordinateur Windows
Server 2003 ou d’un ordinateur Windows 2000 pour configurer ces paramètres directement.
Windows Les ordinateurs XP joints à des domaines de contrôleur de domaine basés sur Windows 2000
ne peuvent pas prendre en charge la fonctionnalité améliorée de sélection de plusieurs utilisateurs et
d’apporter des modifications en bloc pour des attributs tels que le dossier d’accueil et le chemin d’accès
au profil. La fonctionnalité de sélection multiple est prise en charge dans les forêts dont la version de
schéma est 15 ou versions ultérieures. Par exemple, l’exécution de Windows Server 2003 ADDPREP
/ForestPrep et /DomainPrep dans une forêt et un domaine basés sur Windows 2000 permettrait la prise
en charge de plusieurs sélections sur les systèmes où le logiciel en ligne Utilisateurs et ordinateurs Active
Directory Windows server 2003 est installé.
Lorsque la version Service Pack 1 des utilisateurs et ordinateurs Active Directory est démarrée sur des
systèmes 64 bits, il est possible qu’elle ne modifie pas toujours la stratégie de groupe. En outre, le
message d’erreur suivant s’affiche :
Windows’est pas en mesure de trouver gpedit.msc. Assurez-vous que vous avez tapé le nom correctement, puis
essayez à nouveau. Pour rechercher un fichier, cliquez sur le bouton Démarrer, puis sur Rechercher.
Modifiez la syntaxe de votre ligne de commande ou raccourci pour utiliser la syntaxe suivante :
%windir%\syswow64\mmc.exe %systemroot%\system32\dsa.msc -32 back
Gestionnaire d’autorisation
Il a été ajouté au pack d’outils d’administration dans Windows Server 2003 RC1 et versions ultérieures.
Autorité de certification
En raison des modifications importantes apportées au schéma, vous ne pouvez pas utiliser les clients basés sur
Windows XP Professional pour administrer des ordinateurs basés sur Windows 2000 et vous ne pouvez pas
utiliser les clients Windows 2000 pour administrer les ordinateurs basés sur Windows Server 2003. Pour
administrer des ordinateurs basés sur Windows Server 2003, effectuez une administration à distance à partir de
la console ou d’une session des services Terminal Server sur l’ordinateur de destination, ou utilisez des clients
basés sur Windows 2000 pour gérer les ordinateurs Windows 2000 Server et les clients basés sur Windows XP
et Windows Server 2003.
Administrateur de cluster
Si vous utilisez Windows XP Professional service pack 2 et le pack d’outils d’administration Windows Server
2003, vous ne pouvez pas administrer les serveurs de cluster. Toutefois, si vous utilisez Windows XP Professional
avec SP1 et le pack d’outils d’administration Windows Server 2003, vous pouvez gérer les serveurs de cluster.
Kit d’administration du Gestionnaire des connexions
Nous ne recommandons pas l’administration entre versions de Windows 2000 vers Windows Server 2003, car
cela ne produit pas de Windows profils XP.
Assistant Délégation
Aucun problème connu.
DHCP
Windows outils 2000 ne peuvent pas générer un fichier de vidage des configurations DHCP (Dynamic
Host Configuration Protocol) Windows Server 2003 en raison de modifications de code.
Il n’existe aucun nouveau problème dans Windows Server 2003 Service Pack 2.
Système de fichiers distribués (DFS)
Ajoute la prise en charge de la sonnerie, du hub et de la rayons, ainsi que la prise en charge de la
topologie personnalisée pour la réplication du service de réplication de fichiers (FRS) des racines et des
liens DFS.
Configure la priorité de connexion dans les version Q321557 et SP3 de Windows 2000 Ntfrs.exe.
Si vous utilisez un client Windows XP, vous devez utiliser la mise à jour Windows XP SP1 pour administrer
Windows Server 2003 DFS.
Adminpak inclut désormais le Windows’aide du serveur DFS Server 2003.
DNS
Lorsque vous accédez à un serveur DNS (Domain Name System) via une adresse IP, certaines informations
renvoyées, telles que les informations du forwardeur, sont incorrectes. Pour contourner ce problème, accédez au
serveur DNS via un nom d’hôte au lieu d’une adresse IP. This issue applies to the original-release version of the
Windows Server 2003 Administration Tools Pack.
Utilitaires de ligne de commande du service d’annuaire
La version d’origine du pack Windows Server 2003 Administration Tools inclut la signature LDAP. Windows 2
000 contrôleurs de domaine qui sont administrés à distance par des ordinateurs basés sur Windows 2000 qui
exécutent le Service Pack 4 (SP4), par des ordinateurs Windows XP ou par des ordinateurs basés sur Windows
Server 2003 qui utilisent l’authentification NTLM doivent avoir installé Windows 2000 SP3.
Fonctionnalité glisser-déposer des logiciels en snap-in Active Directory
La version d’origine de Windows Server 2003 Adminpak.msi ajout de fonctionnalités de glisser-déposer aux
logiciels en ligne suivants :
Sites et services Active Directory Soyez prudent lorsque vous ne déplacez pas accidentellement ou
inconsciemment des unités d’organisation sous différentes unités d’organisation parentes. Cette action peut
avoir les résultats suivants :
Les comptes d’utilisateur et d’ordinateur n’appliquent pas la stratégie de groupe comme prévu. Plus
précisément, les objets de stratégie de groupe qui sont appliqués aux comptes d’utilisateurs et d’ordinateurs
peuvent ne plus s’appliquer en raison d’une hiérarchie d’organisation différente ou parce que de nouveaux
objets de stratégie de groupe peuvent désormais s’appliquer en fonction du nouvel emplacement des objets.
L’application ou la non-application de la stratégie de groupe peut affecter le comportement du système
d’exploitation. Par exemple, l’accès aux fonctionnalités du système d’exploitation et aux ressources partagées
sur le réseau peut être affecté.
Les programmes configurés pour utiliser des chemins de noms spéciaux codés en dur peuvent ne pas
toujours localiser les objets requis.
M o d i fi c a t i o n s d u c o m p o r t e m e n t g l i sse r- d é p o se r d a n s l a v e r si o n W i n d o w s Se r v e r 2 0 0 3 SP 2 d e A d m i n p a k .m si
Dans la version Windows Server 2003 SP2 de Adminpak.msi, deux nouvelles options sont disponibles pour
contrôler le comportement de glisser-déposer dans le logiciel en ligne Utilisateurs et ordinateurs Active
Directory et dans le logiciel en ligne Sites et services Active Directory :
Par défaut, une boîte de dialogue d’avertissement est présentée lorsque vous essayez d’effectuer une
opération glisser-déposer. Vous pouvez ignorer la boîte de dialogue d’avertissement pour la session.
Toutefois, la boîte de dialogue s’affiche à nouveau au prochain démarrage du logiciel en snap-in.
Vous pouvez désactiver les fonctionnalités de glisser-déposer en attribuant la valeur 0 (zéro) à la
première partie de l’attribut DisplaySpecifiers dans le contexte d’attribution de noms de configuration
dans Active Directory. Comme il s’agit d’un paramètre à l’échelle de la forêt, les fonctionnalités de glisser-
déposer sont désactivées pour chaque domaine de la forêt. Pour désactiver la fonctionnalité glisser-
déposer, suivez les étapes suivantes :
NOTE
L’outil ADSI (Active Directory Service Interfaces) Edit doit être installé pour effectuer cette procédure. ADSI Edit est
inclus avec les outils de support Windows Server 2003 SP2. Pour plus d’informations, cliquez sur le numéro
892777 mises à jour des outils de support Windows Server 2003 sont incluses dans Windows Server 2003
Service Pack 2
1. Si vous avez le logiciel en ligne Utilisateurs et ordinateurs Active Directory ou le logiciel en ligne Sites
et services Active Directory ouvert, fermez les logiciels en snap-in.
2. Cliquez sur Démarrer, cliquez sur Exécuter, tapez adsiedit.msc dans la zone Ouvrir, puis cliquez sur
OK.
3. Développez la configuration.
4. Expand CN=Configuration,DC= ForestRootName****.
5. Cliquez avec le bouton droit sur CN=DisplaySpecifiers, puis cliquez sur Propriétés.
6. Dans la liste des attributs, double-cliquez sur les indicateurs .
7. Dans la boîte de dialogue Éditeur d’attributs de type Integer, tapez 1 dans la zone Valeur.
8. Cliquez sur OK à deux reprises.
9. Fermez ADSI Edit.
Microsoft Exchange
Les fichiers DLL Microsoft Exchange SIMPLE Mail Transfer Protocol (SMTP) et NNTP (Network News
Transfer Protocol) ont été ajoutés à Adminpak.msi. Les fichiers Staxmem.dll, Smtpapi.dll, Smtpadm.dll,
Smtpsnap.hlp et Nntpsnap.hlp supplémentaires ont été ajoutés à Adminpak.msi pour permettre aux
clients Windows XP Professional 32 bits d’administrer la version de Exchange après Microsoft Exchange
2000.
L’administration Exchange serveurs basés sur Exchange version 2000 des clients 64 bits n’est pas prise en
charge.
Aide
Le fichier d’aide Ntcmds.chm a été ajouté pour prendre en charge l’administration de ligne de commande.
Les Windows’aide Professional XP sont réinstallés lorsque le pack d’outils d’administration est supprimé.
Windows XP Professional versions des fichiers Ntart.chm et Ntcmds.chm sont restaurées pendant
l’installation du pack d’outils d’administration.
Internet Information Services de ligne de commande
Cette section s’applique aux utilitaires suivants :
IisApp.vbs
Iisback.vbs
IisCnfg.vbs
IisFtp.vbs
IisFtpdr.vbs
Iisvdir.vbs
Iisweb.vbs
Les problèmes suivants ont été signalés :
Tous les scripts sont compatibles avec Microsoft Internet Information Services (IIS) 6.0 uniquement.
IISCnfg : lorsque vous utilisez la commande, le fichier de destination (fichier que vous spécifiez après le
commutateur /f) est créé sur l’ordinateur distant (l’ordinateur iiscnfg /export Windows Server). Par
exemple, pour exporter la métabase, tapez la commande suivante :
iiscnfg /s RemoteServer /u UserName /p UserPwd /export /f d:\Config.xml /sp /LM/W3SVC/1
Lorsque vous exécutez cette commande, le D:\Config.xml est créé sur le serveur distant. Pour importer la
métabase, tapez la commande suivante :
iiscnfg /s RemoteServer /u UserName /p UserPwd /import /f d:\Config.xml /sp /LM/W3SVC/1 /dp

/LM/W3SVC/2
NOTE
Ces commandes sont d’une ligne chacune. Elles ont été wrapped pour une plus grand lisibilité.
IISCnfg vérifie que le fichier D:\Config.xml (fichier que vous spécifiez après le commutateur /f) existe à la
fois sur l’ordinateur local et sur l’ordinateur distant (RemoteServer). Toutefois, l’importation réelle utilise
uniquement le fichier sur le serveur distant. Lorsque vous importez ou copiez le fichier Config.xml à
partir du serveur distant, utilisez le même chemin d’accès sur l’ordinateur local.
Service d’authentification Internet
Le logiciel en snap-in IAS (Internet Authentication Service) a été supprimé du pack d’outils d’administration.
Netsh
La sortie de la commande de vidage IP du serveur dhcp netsh est tronquée. La sortie de cette commande
émise à partir d’un ordinateur Windows Server 2003 sur un serveur DHCP Windows Server 2003
renvoie la sortie suivante :
Dhcp Server 157.59.136.135 Add Optiondef 100 « Byte Array » BYTE 1 comment=" » 4 3 2 1 0 Dhcp
Server 157.59.136.135 Add Optiondef 101 « String Array » STRING 1 comment=" » « hello » « « bob
» Dhcp Server 157.59.136.135 Add Optiondef 102 « IP Array » IPADDRESS 1 comment=" » 4.4.4.4
3.3.3.3 2.2.2.2 1.1.1.1
La même commande émise à partir d’un client basé Windows XP est tronquée comme suit :
Dhcp Server 220.0.80.23 Add Optiondef 100 « Byte Array » BYTE 1 comment=" » 4 Dhcp Server
220.0.80.23 Add Optiondef 1 01 " String Array " STRING 1 comment=" » hello Dhcp Server
220.0.80.23 Add Optiondef 102 « IP Array » IPADDRESS 1 comment=" » 4.4.4.4
Par défaut, la netsh dhcp server commande ne s’exécute pas Windows clients BASÉS sur XP. Par exemple,
la commande suivante s’exécute correctement à partir d’un ordinateur Windows Server 2003, mais pas à
partir d’un client Windows XP :
Dhcp Server 157.59.136.135 Add Optiondef 101 « String Array » STRING 1 comment=" » « hello »
« quy » « jim » « bob »
Si vous exécutez cette commande à partir d’un client basé Windows XP, vous recevez le message d’erreur
suivant :
Échec de l’option OptionDef pour le serveur DHCP.

Les paramètres transmis sont incomplets ou non valides.
Pour administrer à distance un serveur DHCP à partir d’un client basé sur Windows XP, installez le pack
d’outils d’administration, puis tapez la commande suivante à l’invite de commandes :
netsh add helper dhcpmon.dll
Gestionnaire d’équilibrage de charge réseau

Aucun problème connu dans la version de publication de Windows Server 2003 Adminpak.
Le Service Pack 2 Adminpak installe un gestionnaire d’équilibrage de charge réseau 32 bits qui ne se lie
pas sur les versions 64 bits de Windows.
Ntdsutil.exe
La commande de restauration faisant autorité dans Ntdsutil dépend Ntdsbsrv.dll. Ntdsbsrv.dll n’est pas inclus
dans Windows XP Professional ou dans le pack d’outils d’administration Windows Server 2003. Effectuer des
restaurations faisant autorité à partir de la console des contrôleurs de domaine basés sur Active Directory. Si
vous devez exécuter cette commande sur des clients Windows XP, copiez le fichier Ntdsbsrv.dll à partir d’une
version finale d’une installation Windows Server 2003.
S picker d’objet
La version d’origine de Windows Server 2003 Administration Tools Pack introduit la signature LDAP. Windows 2
000 contrôleurs de domaine qui sont administrés à distance par des ordinateurs basés sur Windows 2000 qui
exécutent le Service Pack 4 (SP4), par des ordinateurs Windows XP ou par des ordinateurs basés sur Windows
Server 2003 qui utilisent l’authentification NTLM doivent avoir installé Windows 2000 SP3.
Extensions utilisateur d’accès à distance
Les extensions utilisateur d’accès à distance ont été supprimées de la version d’origine du pack d’outils
d’administration Windows Server 2003. Les extensions utilisateur d’accès à distance sont disponibles si la
version du fichier Adminpak.msi inclus dans Windows Server 2003 Service Pack 2 (SP2) est installée sur votre
ordinateur Windows XP Professional. Si vous avez installé la version RTM ou SP1 du fichier Adminpak.msi, vous
devez le désinstaller, puis installer la version Windows Server 2003 SP2.
Bureau à distance
Connecter mode console est pris en charge uniquement sur les ordinateurs basés sur Windows Server 2003 et
Windows XP.
Remote Stockage
L’administration entre versions n’est pas prise en charge. L’administration Stockage à distance à partir
d’ordinateurs basés sur Windows 2000 n’est pas prise en charge par rapport aux ordinateurs basés sur
Windows Server 2003 et Windows XP. Effectuer une administration à distance à partir Windows
ordinateur basé sur 2000, à partir de la console de l’ordinateur de destination ou sur une session des
services Terminal Services.
L’administration entre versions n’est pas prise en charge. Les versions de Windows Server 2003 et
Windows XP qui exécutent le pack d’outils d’administration Windows Server 2003 ne peuvent pas
administrer Windows ordinateurs basés sur 2000. Effectuer une administration à distance à partir d’un
ordinateur Windows Server 2003, à partir d’un ordinateur Windows XP, de la console de l’ordinateur de
destination ou d’une session des services Terminal Server.
Extension d’administration de l’interface utilisateur des services d’installation à distance (RIS)
Routage et accès à distance
Cette suppression a été supprimée du pack d’outils d’administration.
Téléphonie
Les administrateurs de téléphonie ne peuvent pas administrer des lignes distantes sur un ordinateur Windows
2000 Server à partir d’un ordinateur Windows XP Professional. Plus précisément, l’option Modifier les
utilisateurs n’est pas disponible.
Gestionnaire des licences des services Terminal Services
UDDI
Windows Problèmes des outils d’administration Server 2003 sur les versions x64 de Windows Server 2003
Lorsque vous essayez de modifier une stratégie de groupe sur une version x64 de Windows Server 2003 à
partir du logiciel en ligne Utilisateurs et ordinateurs Active Directory, du logiciel en ligne sites et services Active
Directory ou de la console de gestion des stratégies de groupe, vous recevez le message d’erreur suivant :
Windows 'gpedit.msc'. Assurez-vous que vous avez tapé le nom correctement, puis essayez à nouveau. Pour
rechercher un fichier, cliquez sur le bouton Démarrer, puis sur Rechercher
Lorsque vous essayez de modifier un GPO à partir d’un des logiciels en snap-in répertoriés précédemment, un
appel est effectué pour démarrer le fichier Gpedit.msc. Actuellement, les logiciels en snap-in qui appellent le
fichier Gpedit.msc sont des outils 32 bits. Toutefois, sur les versions x64 de Windows Server 2003, Gpedit.msc
est un logiciel en snap-in 64 bits. Ce problème sera résolu dans une prochaine version d’un package
Adminpak.msi 64 bits. Pour contourner ce problème, utilisez l’une des méthodes suivantes.
Mét h o de 1
Modifiez les GGP à partir d’un ordinateur exécutant une version 32 bits de Windows Server 2003, une version
32 bits de Windows XP ou une version de Windows 2000.
Mét h o de 2
Utilisez les commandes suivantes pour démarrer les logiciels en snap-in, puis modifiez les GOS :
Pour démarrer le logiciel en ligne Utilisateurs et ordinateurs Active Directory :
%windir%\syswow64\mmc.exe %windir%\system32\dsa.msc -32
Pour démarrer le logiciel en ligne Sites et services Active Directory :

%windir%\syswow64\mmc.exe %windir%\system32\dssite.msc -32
Compatibilité de la version hors bande (OOB) de la Console de gestion des stratégies de groupe Microsoft (GPMC) avec les versions
64 bits de Windows XP, Windows Server 2003 et Windows Server R2
La version OOB de GPMC doit être exécuté sur des plateformes 32 bits. La version OOB de GPMC n’est pas prise
en charge sur les versions 64 bits de Microsoft Windows. Il n’est pas prévu de mettre à jour la version OOB de
GPMC pour prendre en charge les versions 64 bits de Microsoft Windows pour Windows Server 2003 ou
Windows XP Service Pack 2 (SP2). Dans les versions 64 bits de Windows Vista et de Windows Server 2008. La
version 64 bits de GPMC est prise en charge. Toutefois, les rapports GPMC ne peuvent pas être installés sur
toutes les versions 64 bits de Microsoft Windows. Cette version de GPMC ne fait pas partie d’un package d’outils
d’administration actuel.
En outre, vous pouvez recevoir le message d’erreur suivant lorsque vous essayez d’ouvrir GPMC:Windows
gpEDIT. MSC. Ce problème se produit même si vous utilisez la commande suivante pour ouvrir la GPMC :
%windir%\syswow64\mmc.exe %windir%\system32\gpmc.msc -32
304718 utiliser le pack d’outils d’administration pour administrer à distance les ordinateurs exécutant Windows
Server 2003, Windows XP ou Windows 2000
WINS
La modification de l’API RPC (Remote Procedure Call) Windows Internet Name Service (WINS) entre Windows
Server 2003, Windows XP Professional, Windows 2000 et Windows NT 4.0 empêche l’administration à distance
des serveurs WINS basés sur Windows NT 4.0. Windows versions 2000 du logiciel en snap-in WINS Microsoft
Management Console (MMC) et des versions Windows Server 2003 du logiciel en ligne MMC WINS. Il ne s’agit
pas d’une régression, Windows 2000 partage la même limitation.
Utiliser les outils de ligne de commande du service
d’annuaire pour gérer les objets Active Directory
Cet article explique comment utiliser les outils de ligne de commande du service d’annuaire pour effectuer des
tâches administratives pour Active Directory dans Windows Server 2003. Les tâches suivantes sont
décomposées en groupes de tâches.
Comment gérer les utilisateurs

Les sections suivantes fournissent des étapes détaillées pour gérer les groupes.
Créer un compte d’utilisateur
2. Dans la zone Ouvrir, tapez cmd.
3. Depuis l'invite de commandes, entrez la commande suivante :
dsadd user userdn -samid sam_name
Les valeurs suivantes sont utilisées dans cette commande :

userdn spécifie le nom distinguished (également appelé nom DN) de l’objet utilisateur que vous
souhaitez ajouter.
sam_name spécifie le nom sam (Security Account Manager) utilisé comme nom de compte SAM
unique pour cet utilisateur (par exemple, Elle).
4. Pour spécifier le mot de passe du compte d’utilisateur, tapez la commande suivante, où le mot de passe
est le mot de passe à utiliser pour le compte d’utilisateur :
dsadd user userdn -pwd password
NOTE
Pour afficher la syntaxe complète de cette commande et obtenir plus d’informations sur la saisie d’informations
supplémentaires sur le compte d’utilisateur, à l’invite de commandes, tapez dsadd user /? .
Réinitialiser un mot de passe utilisateur

dsmod user user_dn -pwd new_password
Cette commande utilise les valeurs suivantes :

user_dn spécifie le nom unique de l’utilisateur pour lequel le mot de passe sera réinitialisé.
new_password spécifie le mot de passe qui remplacera le mot de passe utilisateur actuel
4. Si vous souhaitez demander à l’utilisateur de modifier ce mot de passe lors du prochain processus
d’accès, tapez la commande suivante :
dsmod user user_dn -mustchpwd {yes|no}
Si un mot de passe n’est pas attribué, la première fois que l’utilisateur tente de se connecter (à l’aide d’un mot de
passe vide), le message de connexion suivant s’affiche :
Vous devez modifier votre mot de passe à la première fois
Une fois que l’utilisateur a modifié le mot de passe, le processus d’accès se poursuit.
Vous devez réinitialiser les services authentifiés avec un compte d’utilisateur si le mot de passe du compte
d’utilisateur du service est modifié.
NOTE
supplémentaires sur le compte d’utilisateur, à l’invite de commandes, tapez dsmod user /? .
Désactiver ou activer un compte d’utilisateur

dsmod user user_dn -disabled {yes|no}

user_dn spécifie le nom de l’objet utilisateur à désactiver ou à activer.
{yes|no} spécifie si le compte d’utilisateur est désactivé pour l’accès (oui) ou non (non).
NOTE
Par mesure de sécurité, au lieu de supprimer le compte de cet utilisateur, vous pouvez désactiver les comptes d’utilisateur
pour empêcher un utilisateur particulier de se connecter. Si vous désactivez les comptes d’utilisateurs qui ont des
appartenances de groupe courantes, vous pouvez utiliser des comptes d’utilisateur désactivés comme modèles de compte
pour simplifier la création de comptes d’utilisateurs.
Supprimer un compte d’utilisateur

3. À l’invite de commandes, tapez la commande, user_dn spécifie le nom de l’objet utilisateur dsrm user_dn à
supprimer.
Une fois que vous avez supprimé un compte d’utilisateur, toutes les autorisations et appartenances associées à
ce compte d’utilisateur sont définitivement supprimées. Étant donné que l’identificateur de sécurité (SID) de
chaque compte est unique, si vous créez un compte d’utilisateur qui a le même nom qu’un compte d’utilisateur
supprimé précédemment, le nouveau compte n’assume pas automatiquement les autorisations et les
appartenances du compte précédemment supprimé. Pour dupliquer un compte d’utilisateur supprimé, vous
devez créer manuellement toutes les autorisations et appartenances.
NOTE
supplémentaires sur le compte d’utilisateur, à l’invite de commandes, tapez dsrm /? .
Comment gérer des groupes

Les sections suivantes fournissent des étapes détaillées pour gérer les groupes.
Créer un groupe
dsadd group group_dn -samid sam_name -secgrp yes | no -scope l | g | u

group_dn spécifie le nom de l’objet groupe que vous souhaitez ajouter.
sam_name spécifie le nom SAM qui est le nom de compte SAM unique pour ce groupe (par exemple,
opérateurs).
Oui | non spécifie si le groupe que vous souhaitez ajouter est un groupe de sécurité (oui) ou un
groupe de distribution (non).
l | g | u spécifie l’étendue du groupe que vous souhaitez ajouter (domaine local [l], global [g] ou
universel [u]).
Si le domaine dans lequel vous créez le groupe est définie sur le niveau fonctionnel de domaine de Windows
2000 mixte, vous pouvez sélectionner uniquement les groupes de sécurité avec des étendues de domaine
locales ou globales.
supplémentaires sur le groupe, à l’invite de commandes, tapez dsadd group /? .
Ajouter un membre à un groupe
dsmod group group_dn -addmbr member_dn

group_dn spécifie le nom de l’objet groupe que vous souhaitez ajouter.
member_dn spécifie le nom de l’objet que vous souhaitez ajouter au groupe.
Outre les utilisateurs et les ordinateurs, un groupe peut contenir des contacts et d’autres groupes.
supplémentaires sur le compte d’utilisateur et le groupe, à l’invite de commandes, tapez dsmod group /? .
Convertir un groupe en un autre type de groupe
dsmod group group_dn -secgrp {yes|no}

group_dn spécifie le nom de l’objet groupe pour lequel vous souhaitez modifier le type de groupe.
{yes|no} spécifie que le type de groupe est définie sur groupe de sécurité (oui) ou groupe de
distribution (non).
Pour convertir un groupe, la fonctionnalité de domaine doit être définie sur Windows 2000 Native ou
supérieure. Vous ne pouvez pas convertir de groupes lorsque la fonctionnalité de domaine est définie sur
Windows 2000 Mixed.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsmod group /? .
Modifier l’étendue du groupe
dsmod group **group_dn** -scope l|g|u

group_dn spécifie les noms de l’objet de groupe auquel l’étendue sera modifiée.
l|g|u spécifie l’étendue à définir pour le groupe (local, global ou universel). Si le domaine est toujours
Windows 2000 mixte, l’étendue universelle n’est pas prise en charge. En outre, il n’est pas possible de
convertir un groupe local de domaine en groupe global ou vice versa.
NOTE
Vous ne pouvez modifier les étendues de groupe que lorsque le niveau fonctionnel du domaine est Windows 2000 natif
ou supérieur.
Supprimer un groupe
3. À l’invite de commandes, tapez la dsrm group_dn commande.
Le group_dn spécifie le nom de l’objet groupe à supprimer.
NOTE
Si vous supprimez le groupe, il est définitivement supprimé.
Par défaut, les groupes locaux fournis automatiquement dans les contrôleurs de domaine exécutant Windows
Server 2003, tels que les administrateurs et les opérateurs de compte, se trouvent dans le dossier intégré. Par
défaut, les groupes globaux courants, tels que Administrateurs de domaine et Utilisateurs de domaine, se
trouvent dans le dossier Utilisateurs. Vous pouvez ajouter ou déplacer de nouveaux groupes vers n’importe quel
dossier. Microsoft recommande de conserver les groupes dans un dossier d’unité d’organisation.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsrm /? .
Rechercher les groupes dont un utilisateur est membre
dsget user user_dn -memberof
Le user_dn spécifie le nom de l’objet utilisateur pour lequel vous souhaitez afficher l’appartenance au
groupe.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsget user /? .
Comment gérer les ordinateurs

Les sections suivantes fournissent des étapes détaillées pour gérer les ordinateurs.
Créer un compte d’ordinateur
dsadd computer computer_dn
Le computer_dn spécifie le nom de l’ordinateur que vous souhaitez ajouter. Le nom unique indique
l’emplacement du dossier.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsadd computer /? .
Pour modifier les propriétés d’un compte d’ordinateur, utilisez la commande dsmod computer.
Ajouter un compte d’ordinateur à un groupe
dsmod group group_dn -addmbr computer_dn

group_dn spécifie le nom de l’objet groupe auquel vous souhaitez ajouter l’objet ordinateur.
computer_dn spécifie le nom de l’objet ordinateur à ajouter au groupe. Le nom unique indique
l’emplacement du dossier.
Lorsque vous ajoutez un ordinateur à un groupe, vous pouvez attribuer des autorisations à tous les comptes
d’ordinateur de ce groupe, puis filtrer les paramètres de stratégie de groupe sur tous les comptes de ce groupe.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsmod group /? .
Réinitialiser un compte d’ordinateur
dsmod computer computer_dn -reset
Le computer_dn spécifie les noms différents d’un ou plusieurs objets ordinateur que vous souhaitez
réinitialiser.
NOTE
Lorsque vous réinitialisez un compte d’ordinateur, vous cassez la connexion de l’ordinateur au domaine. Vous
devez réinitialiser le compte d’ordinateur sur le compte d’ordinateur de domaine après l’avoir réinitialisé.
Pour afficher la syntaxe complète de cette commande, à l’invite de commandes, tapez dsmod computer /? .
Désactiver ou activer un compte d’ordinateur
dsmod computer computer_dn -disabled {yes|no}

computer_dn spécifie le nom de l’objet ordinateur que vous souhaitez désactiver ou activer.
{yes|no} spécifie si l’ordinateur est désactivé pour l’accès (oui) ou non (non).
Lorsque vous désactivez un compte d’ordinateur, vous cassez la connexion de l’ordinateur avec le domaine et
l’ordinateur ne peut pas s’authentifier auprès du domaine.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsmod computer /? .
Comment gérer les unités d’organisation

Les sections suivantes fournissent des étapes détaillées pour gérer les unités d’organisation.
Créer une unité d’organisation
dsadd ou organizational_unit_dn
Le organizational_unit_dn spécifie le nom de l’unité d’organisation à ajouter.

Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsadd ou /? .
NOTE
Pour modifier les propriétés d’une unité d’organisation, utilisez la dsmod ou commande.
Supprimer une unité d’organisation

3. À l’invite de commandes, tapez la dsrm organizational_unit_dn commande.
Le organizational_unit_dn spécifie le nom de l’unité d’organisation à supprimer.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsrm /? .
NOTE
Si vous supprimez une unité d’organisation, tous les objets qu’elle contient sont supprimés.
Comment effectuer des recherches dans Active Directory

Les sections suivantes fournissent des étapes détaillées pour effectuer des recherches dans Active Directory.
Rechercher un compte d’utilisateur
3. À l’invite de commandes, tapez la dsquery user parameter commande.
Le paramètre spécifie le paramètre à utiliser. Pour obtenir la liste des paramètres, consultez l’aide en
ligne de la squery user commande d.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsquery user /? .
Rechercher un contact
3. À l’invite de commandes, tapez la dsquery contact parameter commande.
ligne pour la commande utilisateur de la demande d’informations.
Rechercher un groupe
3. À l’invite de commandes, tapez la dsquery group parameter commande.
ligne pour la commande utilisateur de la demande d’informations.
Par défaut, les groupes locaux fournis automatiquement dans les contrôleurs de domaine exécutant Windows
Server 2003, tels que les administrateurs et les opérateurs de compte, se trouvent dans le dossier intégré. Par
défaut, les groupes globaux courants, tels que Administrateurs de domaine et Utilisateurs de domaine, se
trouvent dans le dossier Utilisateurs. Vous pouvez ajouter ou déplacer de nouveaux groupes vers n’importe quel
dossier. Microsoft recommande de conserver les groupes dans un dossier d’unité d’organisation.
Rechercher un compte d’ordinateur
3. À l’invite de commandes, tapez la dsquery computer -name name commande.
Le nom spécifie le nom de l’ordinateur recherché par la commande. Cette commande recherche les
ordinateurs dont les attributs de nom (valeur de l’attribut CN) correspondent au nom.
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsquery computer /? .
Rechercher une unité d’organisation
3. À l’invite de commandes, tapez la dsquery ou parameter commande.
ligne pour dsquery ou .
Pour afficher la syntaxe complète de cette commande, à une invite de commandes, tapez dsquery ou /? .
Rechercher un contrôleur de domaine
3. À l’invite de commandes, tapez la dsquery server parameter commande.
Le paramètre spécifie le paramètre à utiliser. Il existe plusieurs attributs d’un serveur que vous pouvez
rechercher à l’aide de cette commande. Pour obtenir la liste des paramètres, consultez l’aide en ligne pour
dsquery server.
Effectuer une recherche personnalisée

3. À l’invite de commandes, tapez la dsquery * parameter commande.
Le paramètre spécifie le paramètre à utiliser. Vous pouvez rechercher plusieurs attributs à l’aide de cette
commande. Pour plus d’informations sur les recherches LDAP, voir Windows Server 2003 Resource Kit.
Références
Pour plus d’informations sur les outils en ligne de commande des services d’annuaire dans Windows Server
2003, cliquez sur Démarrer, cliquez sur Centre d’aide et de suppor t, puis tapez les outils de ligne de
commande du service d’annuaire dans la zone de recherche.
Utiliser les indicateurs UserAccountControl pour
manipuler les propriétés du compte d’utilisateur
Cet article décrit les informations sur l’utilisation de l’attribut UserAccountControl pour manipuler les
propriétés du compte d’utilisateur.
Résumé
Lorsque vous ouvrez les propriétés d’un compte d’utilisateur, cliquez sur l’onglet Compte, puis cochez ou videz
les cases dans la boîte de dialogue Options du compte, les valeurs numériques sont affectées à l’attribut
UserAccountControl . La valeur attribuée à l’attribut indique Windows options ont été activées.
Pour afficher les comptes d’utilisateurs, cliquez sur Démarrer, pointez sur Programmes , pointez sur Outils
d’administration , puis cliquez sur Utilisateurs et ordinateurs Active Director y .
Liste des indicateurs de propriété

Vous pouvez afficher et modifier ces attributs à l’aide de l’outil Ldp.exe ou du logiciel en snap-in Adsiedit.msc.
Le tableau suivant répertorie les indicateurs possibles que vous pouvez attribuer. Vous ne pouvez pas définir
certaines valeurs sur un objet utilisateur ou ordinateur, car ces valeurs peuvent être définies ou réinitialisées
uniquement par le service d’annuaire. Ldp.exe affiche les valeurs en hexadécimal. Adsiedit.msc affiche les valeurs
en décimales. Les indicateurs sont cumulatifs. Pour désactiver le compte d’un utilisateur, définissez l’attribut
UserAccountControl sur 0x0202 (0x002 + 0x0200). En décimal, il s’agit de 514 (2 + 512).
NOTE
Vous pouvez modifier directement Active Directory dans Ldp.exe et Adsiedit.msc. Seuls les administrateurs expérimentés
doivent utiliser ces outils pour modifier Active Directory. Les deux outils sont disponibles après avoir installé les outils de
support à partir de votre support d Windows d’origine.
IN DIC AT EUR DE P RO P RIÉT É VA L EUR H EXA DÉC IM A L E VA L EUR EN DÉC IM A L
SCRIPT 0x0001 1
ACCOUNTDISABLE 0x0002 2
HOMEDIR_REQUIRED 0x0008 8
LOCKOUT 0x0010 16
PASSWD_NOTREQD 0x0020 32
IN DIC AT EUR DE P RO P RIÉT É VA L EUR H EXA DÉC IM A L E VA L EUR EN DÉC IM A L
PASSWD_CANT_CHANGE 0x0040 64
Vous ne pouvez pas attribuer cette

autorisation en modifiant directement
l’attribut UserAccountControl. Pour
plus d’informations sur la définition de
l’autorisation par programme, voir la
section Descriptions de l’indicateur de
propriété .
ENCRYPTED_TEXT_PWD_ALLOWED 0x0080 128
TEMP_DUPLICATE_ACCOUNT 0x0100 256
NORMAL_ACCOUNT 0x0200 512
INTERDOMAIN_TRUST_ACCOUNT 0x0800 2048
WORKSTATION_TRUST_ACCOUNT 0x1000 4096
SERVER_TRUST_ACCOUNT 0x2000 8192
DONT_EXPIRE_PASSWORD 0x10000 65536
MNS_LOGON_ACCOUNT 0x20000 131072
SMARTCARD_REQUIRED 0x40000 262144
TRUSTED_FOR_DELEGATION 0x80000 524288
NOT_DELEGATED 0x100000 1048576
USE_DES_KEY_ONLY 0x200000 2097152
DONT_REQ_PREAUTH 0x400000 4194304
PASSWORD_EXPIRED 0x800000 8388608
TRUSTED_TO_AUTH_FOR_DELEGATIO 0x1000000 16777216

N
PARTIAL_SECRETS_ACCOUNT 0x04000000 67108864
NOTE
Dans un domaine Windows Server 2003, LOCK_OUT et PASSWORD_EXPIRED ont été remplacés par un nouvel attribut
appelé ms-DS-User-Account-Control-Computed. Pour plus d’informations sur ce nouvel attribut, voir l’attribut ms-DS-
User-Account-Control-Computed.
Descriptions de l’indicateur de propriété

SCRIPT : le script d’logon est exécuté.
ACCOUNTDISABLE : le compte d’utilisateur est désactivé.
HOMEDIR_REQUIRED - Le dossier d’accueil est obligatoire.
PASSWD_NOTREQD - Aucun mot de passe n’est requis.
PASSWD_CANT_CHANGE - L’utilisateur ne peut pas modifier le mot de passe. Il s’agit d’une autorisation
sur l’objet de l’utilisateur. Pour plus d’informations sur la façon de définir cette autorisation par
programme, voir Modifying User Cannot Change Password (LDAP Provider).
ENCRYPTED_TEXT_PASSWORD_ALLOWED : l’utilisateur peut envoyer un mot de passe chiffré.
TEMP_DUPLICATE_ACCOUNT : il s’agit d’un compte pour les utilisateurs dont le compte principal se
trouve dans un autre domaine. Ce compte permet à l’utilisateur d’accéder à ce domaine, mais pas à un
domaine qui fait confiance à ce domaine. Il est parfois appelé compte d’utilisateur local.
NORMAL_ACCOUNT : il s’agit d’un type de compte par défaut qui représente un utilisateur classique.
INTERDOMAIN_TRUST_ACCOUNT : permet d’faire confiance à un compte pour un domaine système qui
fait confiance à d’autres domaines.
WORKSTATION_TRUST_ACCOUNT : il s’agit d’un compte d’ordinateur pour un ordinateur qui exécute
Microsoft Windows NT 4.0 Workstation, Microsoft Windows NT 4.0 Server, Microsoft Windows 2000
Professional ou Windows 2000 Server et est membre de ce domaine.
SERVER_TRUST_ACCOUNT : il s’agit d’un compte d’ordinateur pour un contrôleur de domaine membre
de ce domaine.
DONT_EXPIRE_PASSWD - Représente le mot de passe, qui ne doit jamais expirer sur le compte.
MNS_LOGON_ACCOUNT : il s’agit d’un compte d’utilisateur de compte d’utilisateur MNS.
SMARTCARD_REQUIRED - Lorsque cet indicateur est définie, il force l’utilisateur à se connecter à l’aide
d’une carte à puce.
TRUSTED_FOR_DELEGATION - Lorsque cet indicateur est définie, le compte de service (compte
d’utilisateur ou d’ordinateur) sous lequel un service s’exécute est approuvé pour la délégation Kerberos.
Tout service de ce type peut usurper l’identité d’un client qui le demande. Pour activer un service pour la
délégation Kerberos, vous devez définir cet indicateur sur la propriété userAccountControl du compte de
service.
NOT_DELEGATED - Lorsque cet indicateur est définie, le contexte de sécurité de l’utilisateur n’est pas
délégué à un service, même si le compte de service est définie comme étant approuvé pour la délégation
Kerberos.
USE_DES_KEY_ONLY - (Windows 2000/Windows Server 2003) Limiter ce principal pour utiliser
uniquement les types de chiffrement DES (Data Encryption Standard) pour les clés.
DONT_REQUIRE_PREAUTH - (Windows 2000/Windows Server 2003) Ce compte ne nécessite pas la pré-
authentification Kerberos pour la connexion.
PASSWORD_EXPIRED - (Windows 2000/Windows Server 2003) Le mot de passe de l’utilisateur a expiré.
TRUSTED_TO_AUTH_FOR_DELEGATION - (Windows 2000/Windows Server 2003) Le compte est activé
pour la délégation. Il s’agit d’un paramètre sensible à la sécurité. Les comptes pour qui cette option est
activée doivent être étroitement contrôlés. Ce paramètre permet à un service qui s’exécute sous le
compte de supposer l’identité d’un client et de s’authentifier en tant qu’utilisateur sur d’autres serveurs
distants sur le réseau.
PARTIAL_SECRETS_ACCOUNT - (Windows Server 2008/Windows Server 2008 R2) Le compte est un
contrôleur de domaine en lecture seule. Il s’agit d’un paramètre sensible à la sécurité. La suppression de
ce paramètre d’un contrôle RODC compromet la sécurité sur ce serveur.
Valeurs UserAccountControl
Voici les valeurs UserAccountControl par défaut pour certains objets :
Utilisateur type : 0x200 (512)
Contrôleur de domaine : 0x82000 (532480)
Station de travail/serveur : 0x1000 (4096)
Éléments à prendre en compte lorsque vous
hébergez des contrôleurs de domaine Active
Directory dans des environnements d’hébergement
virtuels
Cet article décrit les problèmes qui affectent un contrôleur de domaine Windows server s’exécutant en tant que
système d’exploitation invité dans des environnements d’hébergement virtuels. Il traite également des éléments
à prendre en compte lorsqu’un dc s’exécute dans un environnement d’hébergement virtuel.
Résumé
Un environnement d’hébergement virtuel vous permet d’exécuter plusieurs systèmes d’exploitation invités sur
un seul ordinateur hôte en même temps. Le logiciel hôte virtualise les ressources suivantes :
UC
Mémoire
Disque
Réseau
Appareils locaux
En virtualisant ces ressources sur un ordinateur physique, le logiciel hôte vous permet d’utiliser moins
d’ordinateurs pour déployer des systèmes d’exploitation pour les tests et le développement, ainsi que pour les
rôles de production. Certaines restrictions s’appliquent à un dc Active Directory qui s’exécute dans un
environnement d’hébergement virtuel. Ces restrictions ne s’appliquent pas à un dc qui s’exécute sur un
ordinateur physique.
Cet article traite des éléments à prendre en compte lorsqu’Windows dc basé sur un serveur s’exécute dans un
environnement d’hébergement virtuel. Les environnements d’hébergement virtuel incluent :
Windows Virtualisation de serveur avec Hyper-V.
Famille VMware de produits de virtualisation.
Famille Novell de produits de virtualisation.
Famille Citrix de produits de virtualisation.
Tout produit de la liste des hyperviseurs dans le programme SVVP (Server Virtualization Validation
Program).
Pour plus d’informations sur l’état actuel de la robustesse et de la sécurité du système pour les DCS virtualisés,
consultez l’article suivant :
Virtualisation des contrôleurs de domaine à l’aide d’Hyper-V.
L’article Virtualizing Domain Controllers fournit des recommandations générales qui s’appliquent à toutes les
configurations. Bon nombre des considérations décrites dans cet article s’appliquent également aux hôtes de
virtualisation tiers. Il peut inclure des recommandations et des paramètres spécifiques à l’hyperviseur que vous
utilisez, notamment :
Comment configurer la synchronisation de temps pour les DCS.
Comment gérer les volumes de disque pour l’intégrité des données.
Comment tirer parti de la prise en charge de l’ID de génération dans les scénarios de restauration ou de
migration.
Comment gérer l’allocation et les performances des cœurs de processeur et de RAM sur l’hôte de la machine
virtuelle.
NOTE
Si vous utilisez des hôtes de virtualisation tiers, consultez la documentation de l’hôte de virtualisation pour obtenir des
conseils et des recommandations spécifiques.
Cet article complète l’article Virtualizing Domain Controllers en fournissant d’autres conseils et considérations
qui n’étaient pas dans l’étendue de l’article Virtualizing Domain Controllers.
Éléments à prendre en compte lorsque vous hébergez des rôles DC

dans un environnement d’hébergement virtuel
Lorsque vous déployez un dc Active Directory sur un ordinateur physique, certaines conditions requises doivent
être satisfaites tout au long du cycle de vie du dc. Le déploiement d’un dc dans un environnement
d’hébergement virtuel ajoute certaines exigences et considérations, notamment :
Le service Active Directory permet de préserver l’intégrité de la base de données Active Directory en cas
de perte d’alimentation ou d’une autre défaillance. Pour ce faire, le service exécute des écritures non
mises en mémoire et tente de désactiver le cache d’écriture disque sur les volumes qui hébergent la base
de données Active Directory et les fichiers journaux. Active Directory tente également de fonctionner de
cette manière s’il est installé dans un environnement d’hébergement virtuel.
Si le logiciel de l’environnement d’hébergement virtuel prend correctement en charge un mode SCSI-
emulation qui prend en charge l’accès unitaire forcé (FUA), les écritures non mises en place effectuées par
Active Directory dans cet environnement sont transmises au système d’exploitation hôte. Si LE FUA n’est
pas pris en charge, vous devez désactiver manuellement le cache d’écriture sur tous les volumes du
système d’exploitation invité qui hébergent :
la base de données Active Directory
les journaux
fichier de point de contrôle
NOTE
Vous devez désactiver le cache d’écriture pour tous les composants qui utilisent ESE (Extensible Stockage
Engine) comme format de base de données. Ces composants incluent Active Directory, le service de réplication
de fichiers (FRS), Windows Internet Name Service (WINS) et le protocole DHCP (Dynamic Host Configuration
Protocol).
En tant que meilleure pratique, envisagez d’installer des alimentations sans rupture sur les hôtes d’ordinateurs
virtuels.
Un dc Active Directory est conçu pour exécuter le mode Active Directory en continu dès qu’il est installé.
N’arrêtez pas ou ne suspendez pas la machine virtuelle pendant une période prolongée. Lorsque le dc
démarre, la réplication d’Active Directory doit se produire. Assurez-vous que tous les DCS assurent la
réplication entrante sur toutes les partitions Active Directory localement en fonction de la planification
définie sur les liens de site et les objets de connexion. C’est particulièrement vrai pour le nombre de jours
spécifié par l’attribut de durée de vie de tombstone.
Si la réplication ne se produit pas, le contenu des bases de données Active Directory sur les DCS de la
forêt risque d’être incohérent. L’incohérence se produit car la connaissance des suppressions persiste
pendant le nombre de jours défini par la durée de vie de tombstone. Lorsque les DCS ne terminent pas
de manière transitive la réplication entrante des modifications Active Directory au cours de ce nombre de
jours, les objets sont ajoutés dans Active Directory. Le nettoyage d’objets en attente peut prendre du
temps, en particulier dans les forêts multi-domaines qui incluent de nombreux DCS.
Pour résoudre divers problèmes, un dc Active Directory nécessite des sauvegardes régulières de l’état du
système. La durée de vie utile par défaut d’une sauvegarde d’état système est de 60 ou 180 jours. Cela
dépend de la version du système d’exploitation et de la révision du Service Pack en vigueur pendant
l’installation. Cette durée de vie utile est contrôlée par l’attribut de durée de vie tombstone dans Active
Directory. Au moins un dc dans chaque domaine de la forêt doit être backed up sur un cycle normal,
selon le nombre de jours spécifié dans la durée de vie de tombstone.
Dans un environnement de production, vous devez effectuer des sauvegardes quotidiennes de l’état du
système à partir de deux DCS différents.
NOTE
Lorsque l’hôte de la machine virtuelle prend un instantané d’une machine virtuelle, le système d’exploitation invité
ne détecte pas cet instantané comme une sauvegarde. Lorsque l’hôte prend en charge l’ID de génération Hyper-V,
cet ID est modifié lorsque l’image est démarrée à partir d’une capture instantanée ou d’un réplica. Par défaut, le dc
considère qu’il est restauré à partir d’une sauvegarde.
Éléments à prendre en compte lorsque vous hébergez des rôles DC

sur des hôtes en cluster ou lorsque vous utilisez Active Directory
comme serveur principaux dans un environnement d’hébergement
virtuel
Lorsque vos DCS s’exécutent sur des serveurs hôtes en cluster, vous vous attendez à ce qu’ils soient à
tolérance de panne. Les mêmes attentes s’appliquent aux déploiements de serveurs virtuels qui ne sont
pas de Microsoft. Toutefois, il existe un problème dans cette hypothèse : pour que les nodes, disques et
autres ressources sur un ordinateur hôte en cluster soient automatiquement lancés, les demandes
d’authentification provenant de l’ordinateur doivent être reçues par un dc dans le domaine de l’ordinateur.
Une partie de la configuration de l’hôte en cluster doit également être stockée dans Active Directory.
Pour vous assurer que ces DCS sont accessibles au démarrage du système de cluster, déployez au moins
deux DCS dans le domaine de l’ordinateur sur une solution d’hébergement indépendante en dehors de ce
déploiement de cluster. Vous pouvez utiliser du matériel physique ou une autre solution d’hébergement
virtuel qui n’a pas de dépendance Active Directory. Pour plus d’informations sur ce scénario, voir Éviter
de créer des points de défaillance simples.
Ces DCS sur des plateformes distinctes doivent rester en ligne et être accessibles au réseau (dans DNS et
dans tous les ports et protocoles requis) aux hôtes en cluster. Dans certains cas, les seuls DCS qui peuvent
répondre aux demandes d’authentification au démarrage du cluster sont sur un ordinateur hôte en
cluster en cours de redémarrage. Dans ce cas, les demandes d’authentification échouent et vous devez
récupérer manuellement le cluster.
NOTE
Ne supposez pas que cette situation s’applique uniquement à Hyper-V. Les solutions de virtualisation tierces
peuvent également utiliser Active Directory comme magasin de configurations ou pour l’authentification lors de
certaines étapes de démarrage ou de modification de la configuration d’une ordinateur virtuel.
Prise en charge des DCS Active Directory dans les environnements

d’hébergement virtuel
Pour plus d’informations, voir la stratégie de support pour les logiciels Microsoftqui s’exécutent sur des logiciels
de virtualisation de matériel non Microsoft.
Vous recevez Windows’événement Time Service 24,
29 et 38 sur un contrôleur de domaine virtualisé
Cet article fournit une solution à un problème dans lequel vous recevez les ID d’événement Windows Time
Service 24, 29 et 38 sur un serveur hôte.
NOTE
Si vous êtes un client petite entreprise, recherchez des ressources supplémentaires de dépannage et d’apprentissage sur le
site Support pour les petites entreprises.
Symptômes
Lorsqu’un contrôleur de domaine virtualisé est en cours d’exécution dans un système d’exploitation invité sur un
serveur hôte exécutant Windows Server 2008 avec Hyper-V, et que le service de temps Windows (W32Time) se
synchronise avec un contrôleur de domaine principal, les ID d’événement du service de temps Windows 24, 29
et 38 peuvent être enregistrés dans le journal système sur le contrôleur de domaine virtualisé.
Si vous activez Windows journalisation de débogage des services de temps sur le contrôleur de domaine, les
informations qui ressemblent à ce qui suit sont consignées dans le journal de débogage :
149040 14:15:14.2970940s - Informations de journalisation : le service de temps synchronise désormais

l’heure système avec le fournisseur de synchronisation de temps VM IC source.
Cause
Sur un serveur hôte exécutant Windows Server 2008 avec Hyper-V, les contrôleurs de domaine virtualisés qui
s’exécutent sur un système d’exploitation invité sont autorisés à synchroniser leurs horloges système avec
l’horloge du système d’exploitation hôte. Les événements répertoriés dans la section Symptômes sont
enregistrés dans le journal système, car les contrôleurs de domaine ont leur propre mécanisme de
synchronisation de temps. Si les contrôleurs de domaine synchronisent le temps à partir de leur propre source
et l’heure de synchronisation à partir de l’hôte, l’heure du contrôleur de domaine peut changer fréquemment.
Étant donné que de nombreuses tâches du contrôleur de domaine sont liées à l’heure système, un saut dans le
temps système peut entraîner le laisser dans les caches et entraîner l’arrêt de la réplication.
Résolution
Pour résoudre ce problème, désactivez la synchronisation de l’heure sur l’hôte à l’aide des services d’intégration,
puis configurez le contrôleur de domaine virtualisé pour accepter la synchronisation de temps de hiérarchie de
domaine Windows (W32time) par défaut.
1. Ouvrez le Gestionnaire Hyper-V.
2. Cliquez sur Paramètres .
3. Cliquez sur Ser vices d’intégration.
4. Effacer l’option Synchronisation heure.
5. Quittez le Gestionnaire Hyper-V.
Références
Pour plus d’informations sur les contrôleurs de domaine virtualisés, voir l’article Microsoft TechNet «
Considérations de déploiement pour les contrôleursde domaine virtualisés ».
Comment configurer le service de temps Windows
par rapport à un décalage de temps important
Cet article explique comment configurer le service Windows temps en fonction d’un décalage important.
Introduction
Windows d’exploitation incluent l’outil Time Service (service W32Time) utilisé par le protocole d’authentification
Kerberos. L’authentification Kerberos fonctionne si l’intervalle de temps entre les ordinateurs concernés se
trouve dans l’intervalle de temps maximal activé. La valeur par défaut est 5 minutes. Vous pouvez également
désactiver l’outil Service de temps. Ensuite, vous pouvez installer un service de temps tiers.
L’objectif de l’outil Service de temps est de s’assurer que tous les ordinateurs d’une organisation qui exécutent
Microsoft Windows 2000 ou des versions ultérieures des systèmes d’exploitation Windows utilisent un temps
commun. Pour s’assurer qu’il existe une utilisation courante appropriée du temps, le service de temps utilise une
relation hiérarchique qui contrôle l’autorité. Par défaut, Windows ordinateurs basés sur un ordinateur utilisent la
hiérarchie suivante :
Tous les ordinateurs de bureau clients désignent le contrôleur de domaine d’authentification comme
source de temps faisant autorité.
Dans un domaine, tous les serveurs suivent le même processus que les ordinateurs de bureau clients.
Tous les contrôleurs de domaine d’un domaine désignent le contrôleur de domaine principal comme
source de temps.
Tous les maîtres d’opérations PDC suivent la hiérarchie des domaines dans la sélection de leur source de
temps. Toutefois, les contrôleurs d’opérations PDC peuvent utiliser un contrôleur de domaine parent basé
sur une numéro de base.
NOTE
Un nombre de stratégies définit la proximité d’un serveur de temps avec la source de référence principale.
Plus le nombre est petit, plus le serveur est proche de la source d’heure principale. Dans cette hiérarchie, le
maître des opérations PDC à la racine de la forêt devient le serveur de temps faisant autorité pour l’organisation.
Nous vous recommandons vivement de configurer le serveur de temps faisant autorité pour collecter l’heure à
partir d’une source matérielle. Lorsque vous essayez de configurer le serveur de temps faisant autorité pour
qu’il se synchronise avec une source de temps Internet, il n’y a aucune authentification. Nous vous
recommandons également de réduire vos paramètres de correction du temps pour les serveurs et les clients
autonomes. Lorsque vous suivez ces recommandations, une heure plus précise est fournie au domaine.
Un examen des périodes de récupération a montré que les ordinateurs peuvent adopter des heures qui peuvent
être des jours, des mois, des années, voire des dizaines d’années dans le futur ou dans le passé. Les problèmes
suivants peuvent se produire lorsque les ordinateurs avancent ou avancent vers l’arrière dans le temps :
Les mots de passe des comptes d’ordinateur, des comptes d’utilisateur et des relations d’confiance peuvent
être mis à jour prématurément.
Les quarantaines peuvent être identifiées par l’événement de réplication NTDS 2042 dans la réplication du
service d’annuaire Active Directory.
La non-concordance des mots de passe est restaurée de manière faisant autorité pour les comptes
d’ordinateur, les comptes d’utilisateurs ou les relations d’confiance. La récupération à partir de telles
insématisations peut nécessiter des réinitialisations manuelles de mot de passe sur tous les comptes et les
trusts qui sont affectés.
Comment se protéger contre les temps qui avancent et les périodes
de récupération
Lorsque des ordinateurs et des cycles d’alimentation sont redémarrés, le BIOS conserve le temps dans l’EPROM
local qui se trouve sur la carte mère de l’ordinateur. Au démarrage Windows, le noyau tire l’heure actuelle du
BIOS. Cette heure actuelle est utilisée comme heure initiale jusqu’à ce que le service W32Time puisse se
synchroniser avec une autre source de temps.
Le service Windows 32 heures prend en charge deux entrées de Registre, l’une MaxPosPhaseCorrection et l’autre.
MaxNegPhaseCorrection Ces entrées limitent les échantillons acceptés par le service de temps sur un ordinateur
local lorsque ces exemples sont envoyés à partir d’un ordinateur distant.
Lorsqu’un ordinateur qui s’exécute dans un état stable reçoit un exemple de temps de sa source de temps,
l’exemple est vérifié par rapport aux limites de correction de phase MaxPosPhaseCorrection
MaxNegPhaseCorrection imposées par les entrées de Registre et les entrées de Registre. Si l’exemple de temps se
situe dans les limites que les deux entrées de Registre appliquent, cet exemple est accepté pour traitement
supplémentaire. Si l’exemple de temps ne se trouve pas dans ces limites, l’exemple de temps est ignoré et le
service de temps enregistre le message suivant dans le fichier journal privé W32Time :
TROP GRAND
Si les administrateurs réduisent la valeur des corrections de phases positives et négatives, les administrateurs
peuvent réduire la menace que les ordinateurs reçoivent du temps à partir d’échantillons de temps non valides
pour un ordinateur Windows. En revanche, si les administrateurs réduisent la valeur, les administrateurs peuvent
empêcher les ordinateurs d’être en avance ou en retard par rapport aux limites imposées par ces valeurs.
NOTE
Si les valeurs d’entrée de Registre pour les corrections positives et négatives sont réduites, le temps sera augmenté ou
diminué.
MaxPosPhaseCorrection MaxNegPhaseCorrection La valeur par défaut pour les entrées de Registre et dans
Windows 2000, dans Windows XP, dans Windows Server 2003 et dans Windows Vista est la valeur suivante :
0xFFFFFFF
Cette valeur permet à l’ordinateur de recevoir l’heure contenue dans n’importe quel exemple de temps, quelle
que soit l’imprécision.
Dans Windows Server 2008, une nouvelle valeur par défaut pour les entrées de Registre
MaxPosPhaseCorrection et MaxNegPhaseCorrection a été adoptée. Cette nouvelle valeur par défaut est 48
heures. Cette valeur de 48 heures peut être représentée sous l’une des valeurs suivantes :
2a300 (hexadécimal)
172800 (décimal)
Nous recommandons que les entrées MaxPosPhaseCorrection MaxNegPhaseCorrection de Registre et les entrées
de Registre soient définies sur une valeur autre que la valeur suivante :
MAX (0xFFFFFFFF)
NOTE
Lorsque vous définissez la valeur sur une valeur autre que MAX (0xFFFFFFFF), vous pouvez empêcher les ordinateurs
d’adopter un temps très imprécis dans les scénarios où l’ordinateur est redémarré ou où la connectivité à des sources de
temps externes est interrompue. Par exemple, prenons le cas où les entrées de Registre MaxPosPhaseCorrection et
MaxNegPhaseCorrection sont définies pendant 48 heures sur tous les contrôleurs de domaine de la forêt. Si un contrôleur
de domaine unique subit un saut de temps inhabituel de plus de 48 heures, la valeur que vous définissez pour les entrées
de Registre MaxPosPhaseCorrection et MaxNegPhaseCorrection empêchera les autres ordinateurs d’effectuer le même
saut de temps. Par conséquent, les ordinateurs qui ne sont pas synchronisés peuvent être séparés des autres ordinateurs
jusqu’à ce que l’administrateur puisse examiner et prendre des mesures correctives.
La précision du temps est particulièrement importante sur le contrôleur de domaine principal (PDC) racine de la
forêt. Étant donné que le PDC est la source de temps racine pour le domaine, des changements de temps
incorrects sur le PDC peuvent potentiellement provoquer un saut de temps à l’échelle du domaine. Si vous
imposez des restrictions de correction de phase sur le PDC, vous pouvez empêcher les autres contrôleurs de
domaine de la forêt d’accepter la nouvelle heure.
La valeur par défaut de 48 heures au lieu d’une valeur par défaut de 5 minutes ou 15 minutes est basée sur les
raisons suivantes :
La sortie de l’utilitaire W32TM est difficile à lire.
W32TM ne cible actuellement pas l’heure sur les ordinateurs membres et sur les serveurs membres.
Les erreurs et les événements que le Windows d’exploitation et le journal des applications tierces autonomes
sont hautement incohérents. Les erreurs possibles incluent les codes de retour qui ressemblent à ce qui suit :
accès refusé
Le serveur RPC n’est pas disponible
NOTE
Ces erreurs ont une corrélation faible à l’inclinaison du temps, car la cause peut empêcher les ordinateurs basés
Windows d’adopter une valeur de temps précise.
Les bogues d’heure d’été peuvent provoquer des différences d’heure d’une heure.
Une mauvaise configuration am ou PM peut entraîner une différence de temps de 12 heures.
Les erreurs de jour ou de date peuvent provoquer une différence de temps de 24 heures.
Ainsi, 48 heures étaient le prochain décalage évident après 25 ou 36 heures. Les administrateurs peuvent
également réduire la valeur avec les outils corrects qui signalent l’infrastructure et les tests.
Des recommandations spécifiques en fonction de la version du système d’exploitation et du rôle de l’ordinateur
sont décrites dans les sections suivantes.
Windows XP Professional et toutes les versions de Windows Server

2003
Serveurs de domaine
PDC racine de la forêt (serveur de temps faisant autorité )
partir d’une source matérielle. Lorsque vous configurez le serveur de temps faisant autorité pour qu’il se
synchronise avec une source de temps Internet, il n’y a pas d’authentification. Vous devez reconfigurer les
entrées de Registre suivantes :
MaxPosPhaseCorrection
MaxNegPhaseCorrection
La valeur par défaut de ces deux entrées de Registre est 0xFFFFFFFF. Cette valeur par défaut signifie « Accepter
tout changement d’heure ». Nous vous recommandons une valeur de 48 heures. Il est représenté dans le
Registre en tant que 2a300 (hexadécimal) ou 172800 (décimal). Nous vous recommandons de définir la valeur
de l’entrée de Registre MaxPollInterval sur 10 ou moins, ou de définir la valeur de l’entrée de Registre
SpecialPollInterval sur 3 600 (1 heure) ou moins.
Contrôleurs de domaine et serveurs membres à l’intérieur du domaine
Les MaxPosPhaseCorrection entrées MaxNegPhaseCorrection de Registre et les entrées de Registre ont une valeur
par défaut de 0xFFFFFFFF. Cette valeur par défaut signifie « Accepter tout changement d’heure ». Nous vous
recommandons de définir cette valeur sur 48 heures sur tous les contrôleurs de domaine. La valeur 48 heures
peut également être définie sur les serveurs membres qui exécutent des applications sensibles au temps.
NOTE
Pour plus d’informations sur ces entrées de Registre, consultez la section Windows Server 2003 et Windows d’entrées de
Registre XP Time Service.
Clients autonomes
Les MaxPosPhaseCorrection entrées MaxNegPhaseCorrection de Registre et les entrées de Registre ont une valeur
par défaut de 54 000 (15 heures). En tant que meilleure pratique de sécurité, nous vous recommandons de
réduire cette valeur par défaut. Nous vous recommandons également de définir la valeur sur 3 600 (1 heure) ou
sur une valeur encore plus petite, en fonction de la source horaire, de la condition réseau, de l’intervalle
d’interrogation et des exigences de sécurité.
Windows Server 2003 et Windows de Registre XP Time Service

TYPE DÉTA IL S
Entrée de Registre MaxPosPhaseCorrection
Type de valeur DWORD
Sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
Notes Cette entrée spécifie la plus grande correction de temps

positif en secondes que le service peut effectuer. Si le service
détermine qu’une modification est plus importante que
nécessaire, il enregistre un événement à la place. Cas
particulier : 0xFFFFFFFF de toujours apporter la correction de
l’heure. La valeur par défaut pour les membres du domaine
est 0xFFFFFFFF. La valeur par défaut pour les clients et
serveurs autonomes est 54 000 (15 heures).
Entrée de Registre MaxNegPhaseCorrection
Notes Cette entrée spécifie la plus grande correction de temps

négatif en secondes que le service peut effectuer. Si le service
détermine qu’une modification plus importante que celle-ci
est requise, il enregistre un événement à la place. Cas
particulier : -1 signifie toujours apporter la correction de
l’heure. La valeur par défaut pour les membres du domaine
est 0xFFFFFFFF. La valeur par défaut pour les clients et
serveurs autonomes est 54 000 (15 heures).
Entrée de Registre MaxPollInterval
Notes Cette entrée spécifie le plus grand intervalle, en secondes,

qui est activé pour l’intervalle d’interrogation du système.
Notez que, bien qu’un système doit s’interrogationr en
fonction de l’intervalle prévu, un fournisseur peut refuser de
produire des échantillons lorsque des échantillons sont
demandés. La valeur par défaut pour les membres du
domaine est 10. La valeur par défaut pour les clients et
serveurs autonomes est 15.
Entrée de Registre SpecialPollInterval
Sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClie
Notes Cette entrée spécifie l’intervalle d’interrogation spécial en

secondes pour les homologues manuels. Lorsque l’indicateur
0x1 SpecialInterval est activé, W32Time utilise cet intervalle
de sondage au lieu d’un intervalle de sondage que le
système d’exploitation détermine. La valeur par défaut sur
les membres du domaine est 3 600. La valeur par défaut sur
les clients et serveurs autonomes est 604 800.
NOTE
Nous vous recommandons d’utiliser l’Éditeur d’objets de stratégie globale pour déployer ces paramètres. Pour plus
d’informations sur le service Windows Time service dans une forêt Windows Server 2003, voir Windows Time Service
(W32Time).
Les valeurs de paramètre de service de temps Windows par défaut définies dans l’objet de stratégie de groupe
peuvent ne pas correspondre aux valeurs par défaut définies dans le Registre des contrôleurs de domaine basés
sur Windows Server 2003. Lorsque vous déployez des valeurs MaxPosPhaseCorrection et
MaxNegPhaseCorrection sur des contrôleurs de domaine Windows Server 2003 à l’aide d’un objet de stratégie
de groupe, assurez-vous que l’objet de stratégie de groupe ne modifie pas les valeurs des autres paramètres du
service Windows Time dans le Registre. D Windows valeurs de paramètre time service doivent également être
modifiées dans l’GPO pour correspondre aux valeurs de Registre par défaut dans les contrôleurs de domaine.
Toutes les versions Windows 2000 Service Pack 4 (SP4)

Serveurs de domaine
PDC racine de la forêt (serveur de temps faisant autorité )
partir d’une source matérielle. Lorsque vous configurez le serveur de temps faisant autorité pour qu’il se
synchronise avec une source de temps Internet, aucune authentification n’est en mode manuel. Vous pouvez
reconfigurer l’entrée MaxAllowedClockErrInSecs de Registre. La valeur par défaut est 43 200. La valeur
recommandée est 900 (15 minutes) ou une valeur encore plus petite, en fonction de la source de temps, des
conditions réseau et des exigences de sécurité. Cela dépend également de l’intervalle d’interrogation. Nous vous
recommandons de définir la valeur de l’intervalle d’interrogation sur une heure toutes les 24 heures.
NOTE
Pour plus d’informations sur cette entrée de Registre, voir Windows’entrée de Registre Server 2000 SP 4.
Contrôleurs de domaine et serveurs membres à l’intérieur du domaine

Le type de synchronisation est NT5DS. Le service de temps se synchronise à partir de la hiérarchie de domaine
et le service de temps accepte les modifications en temps réel. Étant donné que NT5DS accepte tout
changement d’heure sans prendre en compte le décalage, il est important de configurer une source de temps
racine de forêt fiable dans le sous-réseau de synchronisation de temps.
NOTE
La valeur NT5DS indique que le type de synchronisation est obtenu à partir d’une entrée de Registre.
Clients autonomes
La MaxAllowedClockErrInSecs valeur par défaut de l’entrée de Registre est 43 200 (12 heures). En tant que
meilleure pratique de sécurité, nous vous recommandons de réduire cette valeur par défaut. Nous vous
recommandons de définir la valeur sur 3 600 (1 heure) ou sur une valeur encore plus petite, en fonction de la
source horaire, des conditions réseau, de l’intervalle d’interrogation et des exigences de sécurité.
Windows registre Server 2000 SP 4
TYPE DÉTA IL S
Entrée de Registre MaxAllowedClockErrInSecs
Sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
TYPE DÉTA IL S
Notes Spécifie la modification maximale de l’horloge activée en

secondes. Lorsque l’événement est journalisé, l’heure n’est
pas ajustée en fonction de la valeur. Ce comportement se
produit pour vous protéger contre toute activité d’horodaté
suspecte. La valeur par défaut pour les membres du
domaine est 43 200.
Comment convertir des attributs date/heure dans
Active Directory au format d’heure standard
Cet article explique comment les attributs qui contiennent une valeur de date/heure peuvent être convertis en
formats de date/heure significatifs standard.
Résumé
Active Directory stocke les valeurs de date/heure sous la forme du nombre d’intervalles de 100 nanosecondes
écoulés entre le 0 heure du 1er janvier 1601 et la date et l’heure stockées. L’heure est toujours stockée à l’heure
de Greenwich (GMT) dans Active Directory. Voici quelques exemples d’attributs Active Directory qui stockent des
valeurs de date/heure : LastLogon, LastLogonTimestamp et LastPwdSet . Pour obtenir la valeur date/heure
stockée dans ces attributs dans un format standard, une conversion est requise. Cet article explique comment
cette conversion peut être effectuée.
Procedure
1. Obtenez la valeur de l’attribut Active Directory à convertir. Il existe plusieurs façons d’extraire les valeurs des
attributs Active Directory. L’utilisation d’ADSI Edit est une méthode.
2. Ouvrez l’invite de commandes.
3. Tapez la commande suivante :
w32tm.exe /ntte [time in Windows NT time format]
4. La valeur date/heure est convertie en heure locale et affichée.
Exemple
La commande produit « w32tm.exe /ntte 128271382742968750 148462 05:57:54.2968750 - 24/06/2007 8:57:54
AM (heure locale) » sur un ordinateur qui se trouve dans un fuseau horaire trois heures avant l’heure de
Greenwich (GMT +3:00). Notez que la première moitié de la sortie affiche l’heure GMT (05:57:54), puis la
convertit en ajoutant le décalage de fuseau horaire (8:57:54).
Community exclusion de responsabilité de contenu des solutions de

contenu
fournisseurs respectifs délament toutes les garanties et conditions concernant ces informations et les
graphiques associés, y compris toutes les garanties implicites et conditions de qualité, l’aptitude à un usage
particulier, l’effort de travail, le titre et la non-contrefaçon. Vous acceptez spécifiquement qu’en aucun cas
Microsoft et/ou ses fournisseurs ne soient responsables de tout dommage direct, indirect, indirect, accidentel,
spécial, conséquencenel, ou de tout dommage quelconque, y compris, sans limitation, de dommages en cas de
perte d’utilisation, de données ou de bénéfices, résultant ou en aucune manière lié à l’utilisation ou à
d’un contrat, d’un délit, d’une négligence, d’une responsabilité stricte ou autre, même si Microsoft ou l’un de ses
fournisseurs a été informé de la possibilité de dommages.
Message d’erreur lorsque vous exécutez la
commande « w32tm /resync » pour synchroniser
Windows Server 2003 ou Windows SBS avec une
source de temps externe : « L’ordinateur n’a pas été
resyncé car aucune donnée de temps n’était
disponible »
Cet article fournit une solution à une erreur qui se produit lorsque vous exécutez la commande pour
synchroniser w32tm /resync Windows Server 2003 ou Windows SBS avec une source de temps externe.
Symptômes
Lorsque vous exécutez la commande pour synchroniser w32tm /resync Microsoft Windows Server 2003 ou
Microsoft Windows Small Business Server 2003 (Windows SBS) avec une source de temps externe, vous
L’ordinateur n’a pas été resyncé car aucune donnée d’heure n’était disponible.
Si vous exécutez la commande ou la commande pour déterminer si Windows est configuré correctement, les
commandes se w32tm /config /syncfromflags:manual w32tm /config/manualpeerlist:peerlist terminent
correctement.
Cause
Ce problème se produit si un objet de stratégie de groupe pour un Windows service de temps est configuré de
manière incorrecte.
Résolution
Pour résoudre ce problème, examinez les stratégies de groupe qui définissent les objets de stratégie de groupe
Windows Time Service sur leurs valeurs par défaut ou sur la valeur Non configuré. Examinez les stratégies de
groupe sur l’ordinateur et dans l’organisation. Définissez ces Windows stratégie de groupe time service pour
utiliser la valeur Non configuré. Pour cela, procédez comme suit :
1. Ouvrez le conteneur qui contient l’objet de stratégie de groupe à modifier. Pour cela, procédez comme
suit.
Pour un objet de domaine
a. Sur un contrôleur de domaine, cliquez sur Démarrer, cliquez sur Exécuter, tapez dsa.msc, puis
cliquez sur OK .
b. Dans le logiciel en ligne de commande Microsoft Management Console (MMC) Utilisateurs et
ordinateurs Active Directory, cliquez avec le bouton droit sur le conteneur qui contient l’objet de
stratégie de groupe, puis cliquez sur Propriétés. Par exemple, cliquez avec le bouton droit sur le
conteneur qui représente le domaine ou l’unité d’organisation, puis cliquez sur Propriétés .
NOTE
Si le serveur qui présente ce problème est un contrôleur de domaine, examinez les objets de stratégie de
groupe dans le conteneur Contrôleurs de domaine.
c. Dans la boîte de dialogue Propriétés containerName, cliquez sur l’onglet Stratégie de

groupe.
d. Cliquez sur l’objet de stratégie de groupe à modifier, puis cliquez sur Modifier. Par exemple, si
vous examinez les objets de stratégie de groupe dans le conteneur Contrôleurs de domaine,
cliquez sur Stratégie des contrôleurs de domaine par défaut, puis cliquez sur Modifier .
Pour un objet ordinateur local
Cliquez sur Démarrer , sur Exécuter , tapez gpedit.msc, puis cliquez sur OK .
2. Dans le snap-in MMC Éditeur d’objets de stratégie de groupe, développez Configuration ordinateur,
développez Modèles d’administration, développez Système, puis cliquez sur Windows Service de
temps.
3. Dans le volet droit, cliquez avec le bouton droit sur Configuration globale Paramètres, puis cliquez sur
Propriétés.
4. Dans la boîte de dialogue Configuration globale Paramètres propriétés, cliquez sur Non
configuré, puis sur OK.
5. Développez Windows time ser vice, cliquez sur Fournisseurs de temps, puis définissez tous les objets
de ce nœud sur Non configuré. Pour cela, procédez comme suit :
a. Dans le volet droit, double-cliquez sur Activer Windows client NTP, cliquez sur Non configuré, puis
cliquez sur OK .
b. Dans le volet droit, double-cliquez sur Configurer Windows client NTP, cliquez sur Non configuré,
puis sur OK .
c. Dans le volet droit, double-cliquez sur Activer Windows ser veur NTP, cliquez sur Non configuré,
puis cliquez sur OK .
6. Quittez l’Éditeur d’objets de stratégie de groupe, puis cliquez sur OK pour quitter la boîte de dialogue
Propriétés containerName.
7. Mettez à jour la stratégie de groupe sur le serveur qui présente ce problème. Pour cela, procédez comme
suit :
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd, puis cliquez sur OK.
b. À l’invite de commandes, gpupdate /force tapez, puis appuyez sur Entrée.
816042 configurer un serveur de temps faisant autorité dans Windows Server 2003
Événement 142 : le service de temps a cessé la
publicité en tant que source de temps
Cet article fournit une résolution pour l’événement 142 : le service de temps a cessé la publicité en tant que
source de temps.
Symptômes
L’événement Microsoft-Windows-Time-Service 142 est journalisé avec l’une des quatre chaînes d’erreur
répertoriées dans le tableau ci-dessous (moins la chaîne event_<hex error> suivante :

Mots clés :
Ordinateur : <hostname>.<domain name>.<top level domain>
Description :
ÉTAT DE L’ERREUR C H A ÎN E D’ERREUR
event_0x0038 Le service de temps a cessé la publicité en tant que source

d’heure, car l’ordinateur local n’est pas un contrôleur de
event_0x0039 Le service de temps a arrêté la publicité en tant que source

de temps, car aucun fournisseur n’est en cours d’exécution.
event_0x003A Le service de temps a arrêté la publicité en tant que source

event_0x003B Le service de temps a cessé de faire de la publicité une

bonne source de temps.
L’horloge locale n’est pas synchronisée
<Event xmlns=" https://schemas.microsoft.com/win/2004/08/events/event ">
<System>
<Provider Name="Microsoft-Windows-Time-Service" Guid="{06EDCFEB-0FD0-4E53-ACCA-
A6F8BBF81BCB}" />
<EventID>142</EventID>
<Version>0</Version>
<Level>3</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="YYYY-MM-DDTHH:MM:SS.MSZ" />
<EventRecordID>3965</EventRecordID>
<Correlation />
<Execution ProcessID="<PID>« ThreadID="<TID> » />
<Channel>Système</Channel>
<Computer> DC1.contoso.com </Computer>
<Security UserID="<SID>« />
</System>
<EventData Name="TMP_EVENT_STOP_ADVERTISING">
</EventData>
</Event>
Cause
C H A ÎN E D’ERREUR C A USE
Le service de temps a cessé la publicité en tant que source L’ordinateur local n’héberge plus le rôle DC ou il existe un
d’heure, car l’ordinateur local n’est pas un contrôleur de problème de configuration avec l’ordinateur local.
Le service de temps a arrêté la publicité en tant que source Le service client NTP s’est arrêté ou ne répond pas
Le service de temps a arrêté la publicité en tant que source Le temps sur l’ordinateur local n’est plus synchronisé avec
de temps, car aucun fournisseur n’est en cours d’exécution. son homologue
Le service de temps a cessé de faire de la publicité une Le dc local n’est pas en mesure de localiser un serveur
bonne source de temps. d’heure
Résolution
La chaîne d’erreur dominante consignée par Microsoft-Windows-Time-Service Event 142 est le troisième
exemple :
« Le service de temps a cessé la publicité en tant que source de temps, car aucun fournisseur n’est en cours
d’exécution. »
1. Exécuter le plan d’action dans l'« ID d’événement 142 - Time Service Advertisement » de Technet
2. Vérifiez que le PDC racine de la forêt est en ligne, sain et que le PDC du domaine racine actuel est
correctement configuré (1.) pour synchroniser l’heure avec une source de temps externe et (2.) en mesure
de source fiable l’heure à partir de cette source.
3. Vérifier les valeurs de démarrage du service et l’état du service : automatique + en cours d’exécution
4. Vérifier que la journalisation dc de l’événement 142 peut découvrir un serveur de temps à l’aide
DCLocator
nltest /dsgetdc:<dns domain> /timeserv /force

nltest /dsgetdc:<dns domain> /gtimeserv /force < si un gtimesrv est configuré dans l’environnement
5. Vérifier la connectivité des ports et des protocoles aux serveurs de temps homologues
w32tm /query /source
6. Vérifiez l’utilisation des protocoles de temps en cherchant les événements suivants :
N OT EZ L E P ROTO C O L E + SO URC E DC DA N S
ÉVÉN EM EN T M IC RO SO F T - W IN DO W S- T IM E- SERVIC E 35 L’ÉVÉN EM EN T
Événement Microsoft-Windows-Time-Service 37 <notez le protocole + source DC dans l’événement
Microsoft-Windows-Kernel-General event 1. L’événement Microsoft-Windows-Kernel-General 1

indique que l’heure a été modifiée dans la VM. Chaque
fois que W32time met à jour l’horloge, cet événement
est journalisé. Chaque fois qu’Hyper-V Time Synch met à
jour l’horloge, l’événement Microsoft-Windows-Kernel-
General 1 est journalisé. Cet événement n’est pas
spécifique aux ordinateurs VM, car il est également
journalisé sur des ordinateurs physiques lorsque
w32time met à jour l’horloge
7. Autres causes premières

AnnounceFlags = 10 sur le PDC racine de la forêt. Ce paramètre peut être explicitement défini ou dans le
Registre ou défini dans la stratégie de groupe.
Si l’ordinateur qui journalise l’événement Microsoft-Windows-Time-Service 142 est un ordinateur invité
virtualisé résidant sur un hôte Hyper-V, désactivez VMICTimeSync sur l’hôte Hyper-V.
Expérience client réelle
Les connexions RDP entre \\workstation1 ( jointes fabrikam.com au domaine) \\DC1 et dans le domaine
nontrus contoso.com échouent avec l’erreur suivante :
Texte de la barre de titre : connexion Bureau à distance

Texte du message de boîte de dialogue : Le Bureau à distance ne peut pas vérifier l’identité de l’ordinateur
distant, car il existe une différence d’heure ou de date entre votre ordinateur et l’ordinateur distant. Assurez-
vous que l’horloge de votre ordinateur est définie à l’heure correcte, puis tentez à nouveau la connexion. Si
le problème se produit à nouveau, contactez votre administrateur réseau ou le propriétaire de l’ordinateur
distant.
Le contoso.com domaine contient deux DCS virtualisés et \\DC1``\\DC2 s’exécute sur le même hôte Hyper-V
W2K8 R2. L’ordinateur hôte Hyper-V \\DC1 fabrikam.com \\DC2 pour et est un serveur membre dans le
domaine, c’est-à-dire, le même domaine que le client RDCP. \\workstation1
L’heure système est signalée \\workstation1 comme étant en secondes à part de l’heure système sur \\DC1 .
L’heure système sur \\DC2.contoso.com le domaine a été signalée comme étant 45 minutes à partir de l’heure
actuelle et de l’heure qui existait le. \\DC1
Un examen du journal des événements SYSTEM pour rechercher les erreurs Kerberos et liées au temps a montré
les événements suivants.
Microsoft-Windows-Time-Service Event 142 a été connecté \\DC2.contoso.com . La cause principale si l’erreur
142 est l’impossibilité de localiser un serveur de temps ou une synchronisation à partir d’un serveur
homologue.

Mots clés :
Description :
Le service de temps a arrêté la publicité en tant que source d’heure, car l’horloge locale n’est pas
synchronisée.
<System>
<Provider Name="Microsoft-Windows-Time-Service" Guid="{<GUID>} » />
<EventID>142</EventID>
<Version>0</Version>
<Level>3</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="YYYY-MM-DDTHH:MM:SS.MSZ" />
<EventRecordID>3965
<Correlation />
<Execution ProcessID="<PID>« ThreadID="<TID> » />
<Computer>DC1.contoso.com</Computer>
<Security UserID="<SID>« />
</System>
<EventData Name="TMP_EVENT_STOP_ADVERTISING">
</EventData>
</Event>
L’événement Microsoft-WIndows-Time-Service 35 a ouvert une session sur la console \\DC1.contoso.com

d’indique que PDC \\DC1 utilise le fournisseur de synchronisation de temps VM IC pour synchroniser l’heure.

Mots clés :
Ordinateur : dc1.contoso.com
Description :
Le service de temps synchronise désormais l’heure système avec le fournisseur de synchronisation de
temps VM IC source.
<Event xmlns=" https://schemas.microsoft.com/win/2004/08/events/event "
<System>
<Provider Name="Microsoft-Windows-Time-Service" Guid="{<GUID>} » /> <EventID>35</EventID>
<Version>0</Version> <Level>4</Level> <Task>0 0 <Keywords><Opcode></Opcode></Task>
0x8000000000000000</Keywords> <TimeCreated SystemTime="<DateTime>" />
<EventRecordID>2614</EventRecordID>
<Correlation />
<Execution ProcessID="1012" ThreadID="2508" />
<Computer>dc1.contoso.com</Computer>
<Security UserID="<sid>« />
</System>
<EventData Name="TMP_EVENT_TIME_SOURCE_CHOSEN">
<Data Name="TimeSource">Fournisseur de synchronisation de temps VM IC
</EventData>
</Event>
L’événement Microsoft-WIndows-Time-Service 37 connecté à la console \\DC2.contoso.com \\DC2 indique qu’il

recherche également du temps NTP à partir de \\DC1.contoso.com

Date : <date><time>
Mots clés :
Description :
Le fournisseur d’heure NtpClient jwesth-t1.jwesth.nttest.microsoft.com reçoit actuellement des données
d’heure valides de (ntp.d|[::]:123->[2001:4898:1b:4:6dd6:3c5c:699d:38cd]:123).
<System>
<Provider Name="Microsoft-Windows-Time-Service" Guid="{<GUID>} » /> <EventID>37 <Version>0
<Level>4 <Task>0 0 <Keywords><Opcode> 0x8000000000000000</Keywords> <TimeCreated
SystemTime="<DateTime>" />
<EventRecordID>3972
<Correlation />
<Execution ProcessID="1012" ThreadID="1596" />
<Computer>DC2.contoso.com</Computer>
<Security UserID="<sid>« />
</System>
<EventData Name="TMP_EVENT_TIME_SOURCE_REACHABLE">
<Data Name="TimeSource"> dc1.contoso.com (ntp.d| [::]:123->[2001:4898:1b:4:6dd6:3c5c:699d:38cd]:123)
</EventData>
</Event>
Un autre événement, Microsoft-Windows-Kernel-General, qui n’a pas été enregistré dans ce cas particulier,
indique que l’ordinateur hôte Hyper-V peut changer d’heure sur les ordinateurs invités d’ordinateurs vm. Un
exemple d’événement est illustré ci-dessous.

Source : Microsoft-Windows-Kernel-General
Mots clés : Heure
Ordinateur : <hostname>.<DNS domain>.<top level domain>
Description :
L’heure système a changé depuis <new time in the format "like" 2010-08-26T20:40:07.210000000Z > <old
time in the format "like" 2010-08-26T20:40:07.210642400Z>.
Cet événement Microsoft-Windows-Kernel-General 1 indique que l’heure a été modifiée dans la VM. Chaque
fois que W32time met à jour l’horloge, cet événement est journalisé. Chaque fois qu’Hyper-V Time Synch met à
jour l’horloge, l’événement Microsoft-Windows-Kernel-General 1 est journalisé. Cet événement n’est pas
spécifique aux ordinateurs VM, car il est également enregistré sur des ordinateurs physiques lorsque w32time
met à jour l’horloge.
Résumé du problème
Le client RDP dépend de SPNego qui choisit le meilleur mécanisme d’authentification disponible, et dans ce cas
a utilisé Kerberos, événement s’il n’y a eu aucune confiance entre le fabrikam contoso.com et les forêts. L’th
kerberos exige que les horloges des deux ordinateurs soient inférieures à 5 minutes, mais ne se soucie pas de la
précision de l’horloge.
L’échec de l’authentification RDP contoso.com est dû au fait que le dc d’authentification dans le domaine (DC1) a
refusé d’authentifier la demande d’authentification du client RDP, car le temps du client ne correspond pas à
l’heure du serveur. Le client ou le serveur, ou les deux, peuvent avoir une horloge nonynchronisée.
La différence de temps dans ce cas a été accentuée par plusieurs facteurs
1. Le client RDP et le serveur KDC/RDP existaient dans deux forêts différentes avec chaque forêt utilisant
différentes configurations de recherche de temps
2. Le KDC et le serveur RDP utilisés par le client RDC sont tous deux des contrôleurs de domaine virtualisés
qui nécessitent des modifications de configuration supplémentaires pour l’heure source précise, puis des
DCS s’exécutant sur du matériel physique.
3. L’ordinateur hôte virtuel était un serveur membre joint au domaine dans un domaine différent des hôtes
Hyper-V
La précision du temps sur les ordinateurs hôtes virtuels est importante, car les ordinateurs invités des
ordinateurs virtuels dérivent initialement du temps de l’ordinateur hôte virtuel au démarrage du système
d’exploitation.
Deux facteurs négatifs pour \\DC1 |DC2 sont que les ordinateurs membres sondent le temps moins
fréquemment par défaut que les contrôleurs de domaine. Deuxièmement, l’ordinateur hôte Hyper-V était
joint à un domaine différent des invités DC et était soumis à différentes configurations de source de
temps
Enfin, VMICTimeSync \\DC2 a été utilisé par l’heure source, ce qui n’est pas recommandé pour les
ordinateurs virtualisés hébergeant les ordinateurs de rôle DC.
4. Le PDC racine de la forêt dans le contoso.com domaine n’a pas été configuré pour l’heure source à partir
d’une source de temps externe
Dans ce cas, l’utilisation de fournisseurs de temps multiples contoso.com dans le domaine ( ntp VMICTimeSync)
a été considérée comme la cause première du temps incorrect qui a conduit à l’échec de la déconnexion RDP.
Il existe des opinions différentes sur la façon de configurer l’heure sur les ordinateurs hôtes et invités au sein
des équipes AD et Hyper-V. La recommandation de Ryan Sizemores 2010.11.22 à ce jour était de laisser VMIC
activé, mais de prêter une attention particulière à la configuration et à la précision du temps sur l’ordinateur
hôte. Par exemple, la section « Configuration du service d’heure Windows pour Windows Server 2008 et
Windows Server 2008 R2 » de « Déploiement de DCS W2K8 et W2K8 R2 dans des domaines existants »
recommande que les ordinateurs hôtes virtuels soient configurés avec des intervalles d’interrogation « dc-like »
et des paramètres de correction max*phase + un serveur de temps précis, semblable à ce que vous feriez sur un
PDC racine de forêt.
L’utilisation de fournisseurs de temps et de sources d’heure différents sur l’hôte virtuel et les environnements
invités virtuels peut entraîner une situation dans laquelle l’heure sur l’ordinateur invité est ping entre les valeurs
VMIC transmises à partir de l’ordinateur hôte. Cette condition peut exister lorsque des invités DC virtualisés
dans une forêt sont hébergés par des ordinateurs hôtes virtuels dans d’autres forêts ou même un ordinateur de
groupe de travail où chacun utilise une configuration de source/heure de temps différente et où les exemples de
temps sont différents entre les deux.
L’équipe Hyper-V recommande de ne pas désactiver VMICTimeSync, car il offre une protection contre les
problèmes de synchronisation de temps si vous avez utilisé l’état enregistré. Le problème clé ici n’est pas
l’utilisation de VMICTimeSync, mais le fait que si vous exécutez un contrôleur de domaine, un élément doit
obtenir un temps précis à partir d’un serveur distant. Vous pouvez le faire en configurant une source de temps
distante à l’intérieur de la machine virtuelle ou en laissant VMICTimeSync activé et en configurant l’hôte pour
utiliser une source de temps fiable.
En mettant en place une machine virtuelle avec VMICTimeSync désactivé (et aucune source de temps externe, le
contrôleur de domaine utilisera l’heure locale), ce qui est toujours garanti comme une erreur dans une machine
virtuelle.
Recommandations de l’équipe de Windows Microsoft pour corriger cet environnement se composait des :
1. Configurez le PDC racine de la forêt avec un serveur NTP.
2. Configurer un serveur GTIME dans le domaine racine de la forêt en tant que sauvegarde
3. Si vous utilisez la virtualisation, désactivez VMICTimeSync (elle est en cours d’évaluation)
4. Configurer des hôtes Hyper-V avec un serveur de temps externe
5. Configurer des hôtes Hyper-V avec les mêmes intervalles d’interrogation que les contrôleurs de domaine
6. Activez la protection de la récupération de temps sur les hôtes Hyper-V.
Commandes utiles (source : Carlos Trueba Sababs)
net stop vmictimesync
sc config vmictimesync start= disabled
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider" /f
w32tm /config /manualpeerlist:ntdev-dc-05.ntdev.corp.microsoft.com /syncfromflags:MANUAL /update
net stop w32time & net start w32time
w32tm /query /source
w32tm /resync /force
ID d’événement 142 - Time Service Advertisement

Time Service Advertisement - Technet
Configuration du service Windows de temps sur l’émulateur PDC dans le domaine racine de la forêt
Configuration du service Windows time pour Windows Server 2008 et Windows Server 2008 R2
Exécution de contrôleurs de domaine dans Hyper-V
Configuration du service Windows temps pour Windows Server - Billet de blog d’Ace Fe ace
Configuration d’un serveur de temps de référence
dans Windows Server
Cet article décrit comment configurer le service de temps Windows et résoudre les problèmes quand il ne
fonctionne pas correctement.
S’applique à : Windows Server 2012 Standard, Windows Server 2012 Essentials
Pour configurer un serveur de temps interne pour qu’il se synchronise avec une source de temps externe,
appliquez l’une des méthodes suivantes :
Pour configurer la synchronisation d’un émulateur PDC dans la racine d’une forêt Active Directory avec une
source de temps externe, procédez comme suit :
1. Changez le type de serveur en NTP. Pour cela, procédez comme suit :
a. Cliquez sur Démarrer > Exécuter , tapez regedit, puis cliquez sur OK .
b. Recherchez puis sélectionnez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
c. Dans le volet droit, cliquez avec le bouton droit sur Type , puis sélectionnez Modifier .
d. Dans Modifier la valeur , tapez NTP dans la boîte de dialogue Données de la valeur , puis
cliquez sur OK .
2. Définissez le paramètre AnnounceFlags sur 5. Pour cela, procédez comme suit :
a. Recherchez, puis sélectionnez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
b. Dans le volet droit, cliquez avec le bouton droit sur AnnounceFlags , puis sélectionnez Modifier .
c. Dans Modifier la valeur DWORD , tapez 5 dans la boîte de dialogue Données de la valeur ,
NOTE
Si un serveur de temps de référence configuré pour utiliser une valeur AnnounceFlag de 0x5 ne se
synchronise pas avec un serveur de temps en amont, il se peut qu’un serveur client ne se synchronise pas
correctement avec le serveur de temps de référence si la synchronisation du temps entre le serveur de temps
de référence et le serveur de temps en amont reprend. Par conséquent, si votre connexion réseau est mauvaise
ou si d’autres problèmes provoquant l’échec de la synchronisation du temps du serveur de référence avec un
serveur en amont surviennent, définissez la valeur AnnounceFlag sur 0xA au lieu de 0x5 .
Si un serveur de temps de référence est configuré pour utiliser une valeur AnnounceFlag de 0x5 et se
synchroniser avec un serveur de temps en amont à un intervalle fixe spécifié dans SpecialPollInterval , il se
peut qu’un serveur client ne se synchronise pas correctement avec le serveur de temps de référence après le
redémarrage du serveur de temps de référence. Par conséquent, si vous configurez votre serveur de temps de
référence pour qu’il se synchronise avec un serveur NTP en amont à un intervalle fixe spécifié dans
SpecialPollInterval , définissez la valeur AnnounceFlag sur 0xA au lieu de 0x5 .
3. Activez NTPServer. Pour cela, procédez comme suit :
a. Recherchez puis sélectionnez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer
b. Dans le volet droit, cliquez avec le bouton droit sur Activé , puis sélectionnez Modifier .
c. Dans Modifier la valeur DWORD , tapez 1 dans la boîte de dialogue Données de la valeur ,
d. Spécifiez les sources de temps. Pour cela, procédez comme suit :
a. Recherchez la sous-clé de Registre suivante, puis cliquez dessus :
b. Dans le volet droit, cliquez avec le bouton droit sur NtpSer ver , puis sélectionnez Modifier .
c. Dans Modifier la valeur , tapez Homologues dans la boîte de dialogue Données de la
valeur , puis cliquez sur OK .
NOTE
Homologues est un espace réservé pour une liste délimitée par des espaces d’homologues à
partir desquels votre ordinateur obtient les informations horaires. Chaque nom DNS répertorié
doit être unique. Vous devez ajouter ,0x1 à la fin de chaque nom DNS. Si vous n’ajoutez pas ,0x1
à la fin de chaque nom DNS, les modifications apportées à l’étape 5 ne prendront pas effet.
4. Configurez les paramètres de correction de temps. Pour cela, procédez comme suit :
a. Recherchez la sous-clé de Registre suivante, puis cliquez dessus :
b. Dans le volet droit, cliquez avec le bouton droit sur MaxPosPhaseCorrection , puis sélectionnez
Modifier .
c. Dans Modifier la valeur DWORD , cliquez pour sélectionner Décimale dans la boîte de dialogue
Base .
d. Dans Modifier la valeur DWORD , tapez TimeInSeconds dans la boîte de dialogue Données de
la valeur , puis cliquez sur OK .
NOTE
TimeInSeconds est un espace réservé pour une valeur raisonnable, par exemple 1 heure (3 600) ou
30 minutes (1 800). La valeur que vous sélectionnez dépend de l’intervalle d’interrogation, des conditions
réseau et de la source de temps externe.
La valeur par défaut de MaxPosPhaseCorrection est de 48 heures dans Windows Server 2008 R2 ou les
e. Recherchez la sous-clé de Registre suivante, puis cliquez dessus :

f. Dans le volet droit, cliquez avec le bouton droit sur MaxNegPhaseCorrection , puis sélectionnez
Modifier .
g. Dans Modifier la valeur DWORD , cliquez pour sélectionner Décimale dans la boîte de dialogue
Base .
h. Dans Modifier la valeur DWORD , tapez TimeInSeconds dans la boîte de dialogue Données de
la valeur , puis cliquez sur OK .
NOTE
TimeInSeconds est un espace réservé pour une valeur raisonnable, par exemple 1 heure (3 600) ou
30 minutes (1 800). La valeur que vous sélectionnez dépend de l’intervalle d’interrogation, des conditions
réseau et de la source de temps externe.
La valeur par défaut de MaxNegPhaseCorrection est de 48 heures dans Windows Server 2008 R2 ou
les versions ultérieures.
5. Fermez l'Éditeur du registre.

6. À l’invite de commandes, tapez la commande suivante pour redémarrer le service de temps Windows et
net stop w32time && net start w32time

Pour que le service de temps Windows fonctionne correctement, l’infrastructure réseau doit fonctionner
correctement. Les problèmes les plus courants du service de temps Windows sont les suivants :
Un problème de connectivité TCP/IP, par exemple une passerelle inactive.
Le service de résolution de noms ne fonctionne pas correctement.
Le réseau rencontre des retards de volume importants, notamment quand la synchronisation se produit sur
des liaisons WAN (Wide Area Network) de latence élevée.
Le service de temps Windows tente une synchronisation avec des sources de temps imprécises.
Il est recommandé d’utiliser l’utilitaire Netdiag.exe pour résoudre les problèmes liés au réseau. Netdiag.exe fait
partie du package d’outils de support Windows Server 2003. Pour une liste complète des paramètres de ligne
de commande que vous pouvez utiliser avec Netdiag.exe, consultez l’aide relative aux outils. Si votre problème
n’est toujours pas résolu, vous pouvez activer le journal de débogage du service de temps Windows. Dans la
mesure où le journal de débogage peut contenir des informations très détaillées, il est recommandé de
contacter les services de support technique Microsoft lorsque vous activez le journal de débogage du service de
temps Windows.
NOTE
Dans certains cas, les frais de support technique par téléphone peuvent être annulés si un professionnel du support
Microsoft détermine qu’une mise à jour spécifique peut résoudre votre problème. Les coûts habituels du support
technique s’appliqueront aux autres questions et problèmes non directement liés à la mise à jour en question.
Windows Server inclut l’outil de service de temps W32Time requis par le protocole d’authentification Kerberos.
Le service de temps Windows veille à ce que tous les ordinateurs d’une organisation qui exécutent le système
d’exploitation Microsoft Windows 2000 Server (ou une version ultérieure) utilisent une heure commune.
Le service de temps Windows utilise une relation hiérarchique qui contrôle l’autorité et interdit les boucles afin
de garantir une utilisation appropriée de l’heure commune. Par défaut, les ordinateurs Windows utilisent la
hiérarchie suivante :
Tous les ordinateurs de bureau clients nomment le contrôleur de domaine d’authentification en tant que
partenaire de temps entrant.
Tous les serveurs membres suivent le même processus que les ordinateurs de bureau clients.
Tous les contrôleurs de domaine d’un domaine nomment le maître d’opérations du contrôleur de domaine
principal comme partenaire de temps entrant.
Tous les maîtres d’opérations du contrôleur de domaine principal suivent la hiérarchie des domaines pour la
sélection de leur partenaire de temps entrant.
Dans cette hiérarchie, le maître d’opérations du contrôleur de domaine principal à la racine de la forêt devient le
serveur de temps de référence de l’organisation. Il est fortement recommandé de configurer le serveur de
temps de référence pour qu’il obtienne le temps d’une source matérielle. Lorsque vous configurez le serveur de
temps de référence pour une synchronisation avec une source de temps Internet, il n’y a pas authentification. Il
est également recommandé de réduire les paramètres de correction de temps pour vos serveurs et clients
autonomes. Ces recommandations apportent davantage de précision et de sécurité à votre domaine.
References
Pour plus d’informations sur le service de temps Windows, consultez :
Comment activer l’enregistrement de débogage pour le service de temps Windows
Comment configurer le service de temps Windows pour un décalage de temps important
Pour plus d’informations sur le service de temps Windows, consultez la page Service de temps Windows
(W32Time).
Comment le service Windows temps d’Windows
traite une seconde bissextile
Cet article décrit comment le service Windows Temps traite une seconde bissextile.
Lorsque le service Windows temps fonctionne en tant que client NTP

(Network Time Protocol)
Le service Windows time n’indique pas la valeur de l’indicateur leap lorsque le service Windows Time reçoit un
paquet qui inclut une seconde bissextile. (L’indicateur de saut indique si une seconde bissextile est à insérer ou à
supprimer dans la dernière minute du jour.) Par conséquent, une fois la seconde bissextile se produit, le client
NTP qui exécute le service Windows temps est une seconde plus rapide que l’heure réelle. Cette différence de
temps est résolue lors de la synchronisation suivante.
Pour plus d’informations Windows la synchronisation de temps, voir Comment Windows time service
fonctionne.
Lorsque le service Windows temps fonctionne en tant que serveur

NTP
Il n’existe aucune méthode pour inclure une seconde bissextile explicitement pour le service Windows time
lorsque le service fonctionne en tant que serveur NTP.
Toutefois, si un serveur NTP externe envoie un indicateur Leap dont la valeur est 01 au serveur NTP du service
de temps Windows, le serveur NTP Windows envoie la même valeur au client NTP suivant.
Prise en charge de la seconde bissextile
Cet article fournit des informations sur la prise en charge de Microsoft pour la seconde bissextile.
R2 Service Pack 1, Windows 10, version 2004, Windows 10, version 1909, Windows 10, version 1803, Windows
10, version 1709, Windows 7 Service Pack 1
Résumé
Cet article contient des informations sur le support Microsoft pour la seconde bissextile. La seconde bissextile
est un ajustement d’une seconde, qui est parfois appliqué au temps universel coordonné (UTC) afin de maintenir
son heure de la journée proche de l’heure thermique moyenne, ou UT1.
NOTE
Windows Server 2019 et Mise à jour d'octobre 2018 de Windows 10 la prise en charge des secondes bissextiles sur la
plateforme. Toutefois, cet article ne s’applique pas strictement à ces systèmes d’exploitation ou ultérieurs. Pour plus
d’informations, reportez-vous aux rubriques suivantes :
Leap Second Announcement
Deuxième validation bissextile pour les professionnels de l’informatique
Deuxième validation bissextile pour les développeurs
(1) Windows
À propos du système d’exploitation
Le second traitement bissextile n’est pas géré séparément par le système d Windows d’exploitation (OS). Par
exemple, les informations sur l’année, le mois, la date et l’heure au format suivant ne sont pas Windows système
d’exploitation :
yyyy/mm/dd 08:59:60
Par conséquent, 2012/7/1 08:59:60 est traitée comme 2012/7/1 09:00:00, selon le format ISO 8601.
À propos du service de synchronisation de temps (Windows Time Service)
Windows Time Service n’implémente pas de seconde bissextile même s’il passe par l’indicateur d’indicateur de
saut (LI) du serveur NTP au serveur qui héberge le service de temps Windows et aux clients de bas niveau qui se
synchronisent à partir de celui-ci. Le Windows Time Synchronization Service (W32Time) n’insère pas de
seconde bissextile et procède plutôt au processus de synchronisation de temps habituel.
Pendant la courte période qui suit l’introduction d’une seconde bissextile sur un serveur NTP en amont (y
compris W32time Server), une différence de temps d’environ une seconde se produit entre ce serveur NTP en
amont et les clients W32time qui se synchronisent à partir de celui-ci. Les clients W32time corrigent leurs
horloges locales lorsqu’ils synchronisent par la suite l’heure à partir de leur serveur en amont.
Pour plus d’informations, consultez l’article suivant de la Base de connaissances Microsoft :
909614 la façon dont Windows Time Service traite une seconde bissextile
En outre, dans le service Windows temps, il n’est pas toujours possible d’empêcher l’occurrence de différences
de temps, telles qu’une seconde. Le système d’exploitation est conçu pour gérer les variations de temps. Les
secondes variantes bissextiles sont gérées correctement, ce qui permet une exécution ininterrompue. Pour plus
d’informations, consultez l’article de la Ko suivant :
939322 prise en charge pour configurer le service Windows temps pour les environnements de haute précision
À propos du service de cluster comme pour la configuration du cluster, il est identique à celui du système
d’exploitation : le second traitement bissextile n’est pas effectué.
(2) SQL Server 2000, 2005, 2008, 2008 R2, 2012 et 2014
SQL Server n’utilise pas les données de temps pour gérer les opérations internes telles que les transactions. Par
conséquent, même si un écart d’une seconde se produit dans le temps système en raison de la seconde
bissextile, il n’affecte pas SQL Server opérations. Comme avec le système d Windows,SQL Server ne reconnaît
pas indépendamment la seconde bissextile.
N’ignorez pas que le type de données de date (par exemple, datetime) ne prend pas en charge le format dans
lequel la valeur des secondes atteint 60 comme 2012/7/1 08:59:60. Par conséquent, si une connexion est établie
à SQL Server à partir d’une application qui s’exécute sur un système d’exploitation qui prend en charge la
seconde bissextile et que le système d’exploitation tente de définir une seconde bissextile (données dans
lesquelles la valeur du second est 60) dans la colonne et la variable du type de données de date, une erreur est
renvoyée. Pour plus d’informations, consultez la section « Informations de référence » suivante.
Informations de référence
[Exemple] Lorsque la seconde bissextile est gérée en tant que type de données de date dans le SQL Server
create table leap_second(

a int,
b datetime,
)
go
insert into [leap_second] values (1,convert(datetime,'2012/07/01 08:59:60'))
go
select convert(datetime,'2012/07/01 08:59:60')
go
select datediff(day,convert(datetime,'2012/07/01 08:59:60'),getdate())
go
declare @b datetime
set @b='2012/07/01 08:59:60'
go
declare @c time
set @c='08:59:60'
go
declare @d datetime2
set @d='2012/07/01 08:59:60'
go
declare @e datetimeoffset
set @e='2012/07/01 08:59:60'
go
Résultat
Message 242, Niveau 16, État 3, Ligne 1
Suite à la conversion du type de données varchar vers le type de données date/heure, la valeur est définie en
dehors de la plage.
L’instruction est terminée.
dehors de la plage.
dehors de la plage.
dehors de la plage.
Le processus de conversion a échoué lors de la conversion de la chaîne de caractères à la date et à l’heure, ou à
l’une des deux.
l’une des deux.
l’une des deux.
(3) Exchange Server 2003, 2007, 2010 et 2013
L’heure utilisée dans Exchange Server inclut l’heure mesurée par l’horloge système et l’heure calculée en tant
que période écoulée depuis le début du service. Dans le traitement qui utilise l’horloge système, le serveur
Exchange fonctionne sans reconnaître la seconde bissextile. En revanche (lorsque la période écoulée est
concernée), bien qu’une différence d’une seconde se produise avec l’insertion de la seconde bissextile, cet écart
peut se produire même dans des circonstances normales. Comme avec le système d Windows, Exchange Server
est conçu pour gérer les variations de temps mineures. Par conséquent, les Exchange Server ne sont pas
affectées.
Outre l’opération interne, une planification au format iCalendar représente un cas dans lequel il est possible de
recevoir (de l’extérieur) une valeur de temps à laquelle une seconde bissextile a été ajoutée. Toutefois, lorsque
Exchange Server reçoit des planifications au format iCalendar, le programme prend en charge uniquement les
formats dans lesquels la notation horaire est définie conformément à la RFC 5545. En ce qui concerne la
seconde bissextile, la notation des secondes est prise en charge dans la plage 060. Si un nombre supérieur à 60
est spécifié comme valeur en secondes, il est traitée comme format non valide et n’est pas reconnu comme
format iCalendar correct.
Dans Outlook, 60 secondes sont considérées comme étant 0. Par conséquent, 2012/07/01 08:59:60 devient
07/02/2012 08:59:00. Cela signifie qu’il existe un écart d’une minute au maximum. Dans ce cas, l’ordre de
réception des e-mails peut sembler avoir dévié, mais dans le cas contraire, il n’y a aucun effet sur les opérations.
Pour plus d'informations, consultez les articles suivants :
2.2.36 [RFC5545] Section 3.3.12 Heure
(4) Internet Information Services (IIS )
La seconde bissextile n’a aucun effet dans IIS.
(5) Autres
Les applications qui s’exécutent Windows utilisent généralement l’horloge système. Par conséquent, ils peuvent
être utilisés sans tenir compte de la seconde bissextile.
Toutefois, si un produit Microsoft est accessible à partir d’une application qui gère le temps seul et qui prend en
charge la seconde bissextile, ou à partir d’une application qui s’exécute sur un système d’exploitation qui prend
en charge la seconde bissextile, des problèmes sont susceptibles de se produire. Cela est dû au fait que les
produits Microsoft ne reconnaissent pas la seconde bissextile.
En outre, les applications ne doivent pas compter sur le temps système pour augmenter de manière monotone.
Au lieu de cela, ils doivent utiliser la fonction GetTickCount64() pour lire le nombre de tick actuel, qui est le
temps depuis le démarrage en millisecondes.
Lorsque SpecialPollInterval est utilisé comme
intervalle d’interrogation, le service Windows Time
ne corrige pas l’heure si le service passe à l’état
Spike
Cet article fournit une résolution du problème qui Windows service de temps ne corrige pas l’heure si le service
passe à l’état Spike.
S’applique à : Windows Server 2012 R2, Windows 10 - toutes les éditions, Windows 7 Service Pack 1
Symptômes
Un ordinateur client NTP qui exécute des éditions Windows Server ou Windows Client peut ne pas corriger
l’heure si les conditions suivantes sont vraies :
Le client NTP synchronise son temps avec le serveur NTP spécifié manuellement.
Le client NTP utilise SpecialPollInterval comme intervalle d’interrogation.
Le décalage entre le client NTP et le serveur NTP est supérieur au largePhaseOffset tel que configuré dans le
client NTP.
Dans ce cas, le client NTP ne peut pas corriger son temps même après avoir attendu la passe de
SpikeWatchPeriod.
Cause
Ce problème se produit car le client NTP passe à l’état SPIKE chaque fois que le client sonde l’exemple de temps
sur le serveur NTP. Le service de temps gère son état interne et, si le client passe à l’état SPIKE, le client ne
synchronise pas son temps.
Résolution
Pour contourner ce problème afin que le client NTP soit activé pour la synchronisation avec le serveur NTP
après un état SPIKE, configurez Windows Time pour utiliser MinPollInterval/MaxPollInterval comme intervalle
d’interrogation.
Pour configurer Windows temps d’utilisation de MinPollInterval/MaxPollInterval comme intervalle
d’interrogation, suivez les étapes suivantes :
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez cmd, puis appuyez sur Entrée.
NOTE
Dans Windows 8 ou Windows Server 2012, appuyez sur la touche Windows logo + R pour ouvrir la zone Exécuter,
tapez cmd dans la zone Exécuter, puis appuyez sur Entrée.
2. À l’invite de commandes, tapez la commande suivante : Après avoir tapé la commande, appuyez sur
Entrée.
w32tm /config /update /manualpeerlist:NTP_server_IP_Address,0x8 /syncfromflags:MANUAL
NOTE
Lorsque vous utilisez l'0x1 avec le commutateur, vous spécifiez /manualpeerlist l’utilisation de
SpecialPollInterval . Pour contourner ce problème, n’utilisez pas l'0x1.
Si vous souhaitez utiliser « SpecialPollinterval », vous devez modifier le Registre suivant :
Clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
Valeur : MinPollInterval
Type : DWORD
Pour éviter ce problème, la clé de Registre doit appliquer l’expression conditionnelle comme suit :
Expression conditionnelle :
SpecialPollInterval<(2^MinPollInterval)*(HoldPeriod+1)
L’ordinateur membre du domaine a des valeurs par défaut :
MinPollInterval=10
HoldPeriod=5
NOTE
Si vous définissez Windows de service de temps par stratégie de groupe ou stratégie de groupe locale, cette solution de
contournement ne fonctionne pas et vous devez supprimer les paramètres de stratégie.
Statut
S’applique à ».
L’intervalle d’interrogation Windows l’heure est définie par la sous-clé de Registre suivante :
Si la valeur de l’entrée NtpServer dans cette sous-clé contient 0x1, Windows Time utilise SpecialPollInterval
comme intervalle d’interrogation. Sinon, Windows Time utilise MinPollInterval/MaxPollInterval. Pour plus
d’informations sur les valeurs Windows Time Service et du Registre, visitez le site Web Microsoft suivant :
La synchronisation de temps risque de ne pas
réussir lorsque vous essayez de synchroniser avec
un serveur NTP Windows non sécurisé
Cet article permet de résoudre le problème de non-réussite de la synchronisation de temps lorsque vous
essayez de synchroniser avec un serveur NTP Windows non sécurisé.
Symptômes
Lorsque vous essayez de synchroniser votre ordinateur microsoft Windows Server 2003 avec un serveur NTP
qui n’exécute pas Microsoft Windows, la synchronisation risque de ne pas réussir. Lorsque ce problème se
produit, les événements suivants peuvent être enregistrés dans le journal système.
Cause
Ce problème peut se produire lorsque votre ordinateur envoie des demandes de synchronisation à l’aide du
mode actif symétrique. Par défaut, Windows de domaine Server 2003 sont configurés en tant que serveurs de
temps et utilisent le mode actif symétrique pour envoyer des demandes de synchronisation. Certains serveurs
NTP qui ne s’exécutent pas Windows répondre uniquement aux demandes qui utilisent le mode client.
Résolution
Pour résoudre ce problème, configurez Windows l’heure d’utilisation du mode client lors de la synchronisation
avec le serveur d’heure. Vous pouvez suivre les étapes suivantes :
2. À l’invite de commandes, tapez les commandes suivantes dans l’ordre donné. Après avoir tapé chaque
commande, appuyez sur Entrée.
w32tm /config /manualpeerlist: NTP_ser ver_IP_Address , 0x8 /syncfromflags: MANUAL
net stop w32time
net start w32time
w32tm /resync
Le mode utilisé par Windows temps pour envoyer des demandes est définie par la sous-clé de Registre suivante
: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer
Si la valeur de l’entrée Enabled dans cette sous-clé est 1, Windows Time utilise le mode actif symétrique. Sinon,
Windows Time utilise le mode client.
Le 0x8 qui est référencé dans la commande de la section « Résolution » Windows le temps d’utiliser le mode
client.
Les paramètres valides pour le mode utilisé avec le commutateur /manualpeerlist sont les suivants :
0x01 - utiliser l’intervalle spécial d’interrogation SpecialInterval
0x02 - UseAsFallbackOnly
0x04 : envoyer une demande en mode SymmetricActive
0x08 : envoyer une demande en mode client
Activer la journalisation du débogage dans
Windows time service
Cet article explique comment activer la journalisation du débogage pour le service Windows time service
(également appelé W32time). Si vous êtes administrateur, vous pouvez utiliser la fonctionnalité de journalisation
du débogage du service Windows Time pour résoudre les problèmes.
S’applique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Window 10 – toutes les
éditions, Windows 7 Service Pack 1
NOTE
Microsoft recommande d’utiliser la journalisation du débogage après avoir effectué toutes les autres étapes de
dépannage. En raison de la nature des informations détaillées dans le journal de débogage, vous de devez peut-être
contacter un support Microsoft Professional.
Activer la journalisation du débogage pour Windows time service

IMPORTANT
Pour activer la journalisation du débogage dans Windows service d’heure :

2. Recherchez, puis cliquez sur la clé de Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config .
3. Dans le menu Modifier, cliquez sur Nouvelle valeur, puis ajoutez les valeurs de Registre suivantes :
Nom de la valeur : FileLogSize
Type de données : DWORD
Cette valeur de Registre spécifie la taille du fichier journal en octets. Une valeur de 100 000 000 octets
limite le fichier journal à environ 10 Mo.
Nom de la valeur : FileLogName
Type de données : String
Données de valeur : C:\Windows\Temp\w32time.log
Cette valeur de Registre spécifie l’emplacement du fichier journal. Le chemin d’accès n’est pas fixe. Vous
pouvez utiliser un autre chemin d’accès.
Nom de la valeur : FileLogEntries
Type de données : String
Valeur : 0-116
Cette valeur de Registre spécifie le niveau de détail des informations dans le journal de débogage. Si vous
devez avoir des informations de journalisation plus détaillées, contactez un support microsoft
Professional.
NOTE
La valeur Type de données doit être de type REG_SZ (String). Vous devez taper la valeur exactement comme
indiqué (autrement dit, tapez 0-116 ). La valeur la plus élevée possible est de 0 à 300 pour la journalisation la plus
détaillée. La signification de cette valeur est la même : journal de toutes les entrées de la plage 0 et 116.
W32Time : Synchronisation : SpecialPollInterval
peut être ignoré sur les ordinateurs de groupe de
travail
Cet article permet de résoudre un problème dans lequel le client NTP ne synchronise pas l’heure à la période
SpecialPollInterval comme prévu.
Symptômes
Supposons que vous modifiez les paramètres W32time pour qu’ils s’exécutent toujours et que l’une des
conditions suivantes est vraie :
Vous utilisez les paramètres de station de travail par défaut.
Vous utilisez des paramètres de synchronisation NTP personnalisés avec une valeur de paramètre
SpecialPollInterval importante.
Dans ce scénario, le client NTP ne synchronise pas l’heure à la période SpecialPollInterval comme prévu.
Cause
En raison de la façon dont Windows Time Service gère les valeurs SpecialPollInterval importantes, le temps peut
être synchronisé à partir du serveur NTP à des intervalles plus longs que prévu.
Résolution
Spécifiez une valeur SpecialPollInterval plus petite que la valeur par défaut. Les valeurs par défaut sont les
suivantes :
MinPollInterval = 0xA (== 2^10 secondes == 1 024 secondes)
MaxPollInterval = 0xF (== 2^15 secondes == 32768 secondes)
SpecialPollInterval = 604800 secondes
Spécifiez une valeur SpecialPollInterval qui se situe entre MinPollInterval et MaxPollInterval. Par exemple, 3 600
secondes (== 1 heure).
Pour configurer W32time avec le nouveau paramètre, suivez les étapes suivantes :
2. Modifiez la valeur de la clé de Registre suivante :
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
Nom de la valeur : SpecialPollInterval

Par défaut : 604800
Valeur modifiée : 3600
3. Redémarrez le Windows time service ou exécutez la commande suivante pour signaler à W32time la
configuration modifiée :
w32tm /config /update
Utilisez les ajustements d’intervalle de sondage intégrés basés sur MinPollInterval, MaxPollInterval au lieu
d’utiliser SpecialPollInterval. Cet outil intégré ajuste automatiquement l’intervalle d’interrogation de
MinPollInterval jusqu’à MaxPollInterval si l’ordinateur client conserve un temps assez précis. Vous devez
uniquement modifier un indicateur dans la configuration NtpServer pour passer de SpecialPollInterval à
l’intervalle d’interrogation automatique, comme suit :
2. Modifiez la valeur de la clé de Registre suivante :
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\W32Time\Parameters
Nom de la valeur : NtpServer

Valeur par défaut time.windows.com : , 0x9
Valeur modifiée : time.windows.com , 0x8
3. Redémarrez Windows service d’heure, ou exécutez la commande suivante :
w32tm /config /update

Windows de service de temps ne sont pas
conservés pendant une mise à niveau sur place vers
Windows Server 2016 ou Windows 10 version 1607
Cet article décrit un problème dans lequel les paramètres du service d’heure Windows sont désactivés dans le
Registre après la mise à niveau vers Windows Server 2016 ou Windows 10 version 1607.
S’applique à : Windows Server 2016, Windows Server 2012 R2, Windows 10 - toutes les éditions
Symptômes
Lorsque vous faites une mise à niveau sur place sur les chemins de mise à niveau des systèmes d’exploitation
suivants, le service Windows Time ne conserve pas sa configuration. Au lieu de cela, il affiche les valeurs par
défaut pour un serveur de groupe de travail ou une station de travail.
M ISE À N IVEA U À PA RT IR DE M ISE À N IVEA U VERS
Windows Server 2012 ou Windows Server 2012 R2 Windows Server 2016
Windows 7, Windows 8 ou Windows 8.1 Windows 10 version 1607
Rôles affectés
Une fois la mise à niveau sur place terminée, les rôles suivants peuvent être affectés.
Contrôleurs de domaine
Les contrôleurs de domaine (DC) qui hébergent le rôle d’émulateur PDC sont le serveur de temps de référence
par défaut pour le domaine. En règle générale, elle est configurée pour être synchronisée avec une source de
temps très précise. Tous les autres DCS du domaine synchronisent leur temps avec le PDC.
Une fois que vous avez mis à niveau sur place, le PDC perd sa connexion au serveur de temps externe avec qui il
est configuré pour la synchronisation. Il n’annonce plus non plus qu’il s’agit d’un serveur de temps.
Tous les autres DCS du domaine n’annoncent plus qu’il s’hui des serveurs de temps et n’utilisent plus la
hiérarchie de domaine pour synchroniser leur temps. Par conséquent, il se peut que leur paramètre d’heure ne
soit plus synchronisé avec le paramètre de leurs homologues et que les membres du domaine ne peuvent plus
synchroniser leur temps.
Vous remarquerez peut-être l’avertissement suivant dans la sortie DCDIAG :
Avertissement : n’est <DCNAME> pas une publicité en tant que serveur de temps
Vous remarquerez peut-être également que le dc ne répond pas aux demandes du client NTP. Il inclut les échecs
qui se produisent lorsque vous testez la disponibilité du serveur NTP à l’aide de l’outil w32tm.exe /stripchart .
Par exemple, la sortie de texte peut ressembler à la sortie suivante :
c:>w32tm /stripchart /computer: <DCName> Tracking <DCName> [10.1.1.100:123]. L’heure actuelle est le
28/10/2016 9:00:00 AM. Erreur 09:00:00 : 0x800705B4 :
Membres du domaine
Les serveurs et ordinateurs membres du domaine mis à niveau ne sont plus configurés pour utiliser la
hiérarchie de domaine pour synchroniser leur temps. Au lieu de cela, ils synchronisent leur temps avec le site
time.windows.com web.
Serveur de temps faisant autorité

Windows ordinateurs configurés manuellement en tant que serveur de temps faisant autorité perdent leur
configuration. Par conséquent, les appareils configurés pour utiliser ces ordinateurs pour synchroniser leur
temps risquent de ne pas être synchronisés.
Vous remarquerez peut-être également que le serveur NTP faisant autorité ne répond pas aux demandes des
clients NTP. Il inclut les échecs qui se produisent lorsque vous testez la disponibilité du serveur NTP à l’aide de
l’outil w32tm.exe /stripchart . Par exemple, la sortie de texte peut ressembler à la sortie suivante :
c:>w32tm /stripchart /computer:<myAuthoritativeTimeServer> Tracking <myAuthoritativeTimeServer>

[10.1.1.100:123]. L’heure actuelle est <DateTime>. <DateTime> error: 0x800705B4:
NOTE
Ce problème ne doit pas se produire lors d’une mise à niveau sur place des systèmes d’exploitation suivants :
Windows 10 version 1507 à Windows 10 version 1511
Windows 10 version 1511 à Windows 10 version 1607
Windows Server 2016 Technical Preview 5 (TP5) à Windows Server 2016 (RTM)
Cause
Il s’agit d’un problème connu dans les chemins Windows de mise à niveau qui sont répertoriés dans la section «
Symptômes ». Ce problème se produit car les valeurs de Registre du service Windows time ne sont pas
conservées pendant une mise à niveau. Par conséquent, toutes les Windows service d’heure sont revenir à l’état
par défaut d’un serveur membre du groupe de travail ou d’un ordinateur autonome.
IMPORTANT
restaurer en cas de problème. Pour plus d’informations sur la façon de la back up et de la restauration du Registre, voir
l’article suivant de la Base de connaissances Microsoft :
NOTE
Sur les PC et les ordinateurs joints à un domaine, le service Netlogon doit être en cours d’exécution pour que le service
W32time puisse démarrer. Après avoir mis à niveau le système, assurez-vous que Netlogon est en cours d’exécution avant
d’essayer l’une de ces solutions de contournement.

Méthode 1
Avant de mettre à niveau vers Windows 10 version 1607 ou Windows Server 2016, vous devez le faire
manuellement sous la clé de Registre w32time . Pour ce faire, procédez comme suit :
1. Ouvrez la zone Exécuter en appuyant sur la touche Windows logo +R.
2. Tapez regedit, puis appuyez sur Entrée.
3. Recherchez, puis sélectionnez l’entrée de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\
4. Sélectionnez FileExpor t > .

5. Dans la boîte de dialogue Exporter le fichier du Registre, sélectionnez l’emplacement où vous souhaitez
enregistrer la copie de sauvegarde, puis tapez un nom pour le fichier de sauvegarde dans le champ Nom
de fichier.
6. Sélectionnez Enregistrer .
7. Enregistrez la configuration W32time pour la validation en exécutant les commandes suivantes à une
invite de commandes avec élévation de niveau élevé :
Net start w32time w32tm /query /configuration /verbose > PreUpgradeW32timeConfiguration.txt
Vous pouvez désormais mettre à niveau l’ordinateur vers Windows Server 2016 ou Windows 10 version 1607.
Une fois la mise à niveau terminée, suivez les étapes suivantes pour restaurer le contenu sous la clé de Registre
w32time :
5. Dans l’Éditeur du Registre, sélectionnez FileImpor t > .
6. Dans la boîte de dialogue Impor ter un fichier du Registre, sélectionnez l’emplacement où vous avez
enregistré la copie de sauvegarde, sélectionnez le fichier de sauvegarde, puis sélectionnez Ouvrir .
8. Exécutez la commande suivante pour supprimer un déclencheur de service supprimé :
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TriggerInfo\1 /f
9. Redémarrez le service W32time pour lui permettre d’utiliser la nouvelle configuration. Pour ce faire,
exécutez les commandes suivantes à une invite de commandes avec élévation de niveau élevé :
net stop w32time
net start w32time
Méthode 2
Si vous rencontrez des problèmes qui affectent le service de temps Windows après la mise à niveau vers
Windows Server 2016 ou Windows 10 Version 1607, w32tm.exe suivez ces étapes pour vous réins inscrit.
NOTE
Cette procédure restaure les paramètres par défaut appropriés pour le rôle d’ordinateur. Il ne restaure pas les
personnalisations qui ont été réalisées par l’administrateur.
À une invite de commandes avec élévation de niveau élevé, exécutez la séquence de commandes suivante :
net stop w32time
w32tm.exe /unregister
w32tm.exe /register
net start w32time
Méthode 3
Si vous rencontrez des problèmes qui affectent le service de temps Windows après la mise à niveau vers
Windows Server 2016 ou Windows 10 Version 1607, suivez ces étapes pour restaurer vos paramètres à partir
du dossier Windows.old.
IMPORTANT
Les étapes suivantes doivent être réalisées uniquement par les utilisateurs avancés.
1. Exportez la clé de Registre à partir Windows.old.

a. Ouvrez la Windows exécuter en appuyant sur la touche Windows logo +R.
b. Tapez regedit, puis appuyez sur Entrée.
c. Recherchez, puis cliquez sur HKEY_LOCAL_MACHINE .
d. Dans le menu Fichier , cliquez sur Charger la ruche .
e. Recherchez le fichier, puis cliquez C:\Windows.old\Windows\System32\Config\System sur Ouvrir .
f. Dans la boîte de dialogue Charger la ruche , tapez Hors connexion, puis cliquez sur OK .
g. Développez Hors connexion .
h. Recherchez, puis cliquez sur la sous-clé de Registre suivante : ControlSet001\Services\W32Time\
i. Cliquez sur FileExpor t > .

j. Dans la boîte de dialogue Exporter le fichier du Registre, sélectionnez l’emplacement sur un disque
dur local où vous souhaitez enregistrer le Registre, puis tapez un nom pour le fichier de
sauvegarde dans le champ Nom de fichier.
k. Cliquez sur Enregistrer .
l. Recherchez, puis cliquez sur la sous-clé de Registre suivante : HKEY_LOCAL_MACHINE\Offline
m. Dans le menu Fichier , cliquez sur Décharger la ruche, puis cliquez sur Oui dans la boîte de
dialogue Confirmer décharger la ruche.
n. Quittez l’éditeur du Registre.
2. Redémarrez l’ordinateur en mode récupération.
a. Select Star t > Paramètres > Update & SecurityRecover y >
b. Dans le volet droit, cliquez sur Redémarrer maintenant sous Démarrage avancé .
c. Après le redémarrage de l’ordinateur, sélectionnez Résoudre les problèmes, puis sélectionnez Invite
de commandes .
d. Sélectionnez un utilisateur administrateur local, puis insérez le mot de passe.
NOTE
Cela redémarre l’ordinateur en mode récupération et fournit une fenêtre d’invite de commandes.
3. Importez la clé de Registre enregistrée à l’étape 1.

a. À l’invite de commandes, tapez regedit, puis appuyez sur Entrée
b. Rechercher, puis sélectionner HKEY_LOCAL_MACHINE
c. Dans le menu Fichier , cliquez sur Charger la ruche .

d. Recherchez et sélectionnez le C:\Windows\System32\Config\System fichier, puis cliquez sur Ouvrir .
e. Dans la boîte de dialogue Charger la ruche , tapez Hors connexion, puis cliquez sur OK
f. Développez Hors connexion .
g. Recherchez, puis cliquez sur la sous-clé de Registre suivante : ControlSet001\Services\W32Time\
h. Cliquez sur FileImpor t > .

i. Dans la boîte de dialogue Impor ter un fichier du Registre, sélectionnez l’emplacement où vous
avez enregistré la copie de sauvegarde, sélectionnez le fichier de sauvegarde, puis cliquez sur
Ouvrir .
j. Recherchez, puis cliquez sur la sous-clé de Registre suivante : HKEY_LOCAL_MACHINE\Offline
k. Dans le menu Fichier , cliquez sur Décharger la ruche, puis cliquez sur Oui dans la boîte de
dialogue Confirmer décharger la ruche.
l. Quittez l’Éditeur du Registre, puis redémarrez l’ordinateur en mode Normal.
Vérifier les résultats de la solution de contournement
Pour vérifier que le service Windows time service peut désormais conserver sa configuration, suivez les étapes
suivantes :
1. Exécutez DCDiag.exe sur les PC pour vous assurer qu’ils font de la publicité en tant que serveur de temps.
2. Assurez-vous que les DCS ou les serveurs NTP faisant autorité répondent aux demandes des clients NTP
sans erreur. Par exemple, la sortie de la commande ressemble à ce qui suit :
c:<w32tm /stripchart /computer:<myTimeServer>

Suivi <myTimeServer> [10.1.1.100:123].
L’heure actuelle est <DateTime>.
<DateTime> d:+00.0013494s o:-00.0891868s [ * ]
3. Pour les utilisateurs avancés, interrogez la configuration W32time et assurez-vous que les fournisseurs
de temps sont configurés comme prévu. Si vous avez utilisé la méthode 1 comme solution de
contournement, vous pouvez comparer la configuration post-mise à niveau aux données de pré-
configuration enregistrées. Par exemple, la sortie de la commande ressemble à ce qui suit :
c:\ >w32tm /query /configuration /verbose > PostUpgradeW32timeConfiguration.txt
References
Pour plus d’informations sur les problèmes Liés à Netlogon, cliquez sur le numéro d’article suivant pour afficher
3201247 service Netlogon ne conserve pas les paramètres après la mise à niveau vers Windows Server 2016
Documentation de dépannage du développement
administrateur pour Windows Server
problèmes liés au développement d’administration et à résoudre eux-mêmes les problèmes liés au
développement. Les rubriques sont divisées en sous-catégories. Parcourez le contenu ou utilisez la
fonctionnalité de recherche pour rechercher du contenu pertinent.
Sous-catégories de développement d’administration

AdsI (Active Directory Services Interface)
WMI (Windows Management Instrumentation)
Windows PowerShell
Windows Gestion à distance (WinRM)
Convertir un GUID au format chaîne en formulaire
de chaîne hexadécimal à utiliser lors de
l’interrogation d’Active Directory
Cet article explique comment convertir un GUID au format chaîne (par exemple, {XXXXXXXX-XXXX-XXXX-XXXX-
XXXXXXXXXXXX}) en sa forme de chaîne hexadécimale pour une utilisation dans une chaîne de liaison GUID dans
Active Directory.
Pour convertir un GUID au format chaîne en forme de chaîne hexadécimale, suivez les étapes suivantes :
1. Collez le code suivant dans un fichier .vbs.
'================================================================
' Replace the value of strGUID with an actual GUID
'================================================================
strGUID = "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"
Set obj = GetObject("LDAP://<GUID=" & ConvertStringGUIDToHexStringGUID(strGUID) & ">")
MsgBox "The octet guid for " & obj.Get("displayname") & " is " & obj.GUID
'================================================================
' ConvertGUIDtoOCTET function
'================================================================
Function ConvertStringGUIDToHexStringGUID(strGUID)
Dim octetStr, tmpGUID
For i = 0 To Len(strGUID)
t = Mid(strGUID, i + 1, 1)
Select Case t
Case "{"
Case "}"
Case "-"
Case Else
tmpGUID = tmpGUID + t
End Select
Next
octetStr = Mid(tmpGUID, 7, 2)' 0

octetStr = octetStr + Mid(tmpGUID, 5, 2)' 1
octetStr = octetStr + Mid(tmpGUID, 17, Len(tmpGUID))
ConvertGUIDtoOCTET = octetStr
End Function
2. Exécutez le script.
Meilleure pratique pour configurer le forwarding
EventLog dans Windows Server 2012 R2
Cet article présente la meilleure pratique pour configurer le forwarding EventLog dans un environnement de
grande Windows Server 2012 R2.
Résumé
Des correctifs importants d’évolutivité ont été déployés sur Windows Server 2016, Windows Server 2019 dans
les mises à jour cumulatives du 25 février 2020.
Voir « Améliore l’évolutivité du transport d’événements pour garantir la sécurité des threads et augmenter les
ressources ». dans les deux articles suivants :
25 février 2020-KB4537806 (os build 14393.3542)
25 février 2020-KB4537818 (os build 17763.1075)
Latence des événements

Dès que des événements sont générés sur le client, le mécanisme de forwarding d’événements prend un certain
temps pour les mettre à la place du collecteur.
Ce retard peut être dû à la configuration de l’abonnement, telle que le paramètre Deliver yMaxLatency , les
performances du collecteur, du forwardeur ou du réseau.
NOTE
Assurez-vous que les événements ne sont pas remplacés sur le client avant d’être transmis. Nous devons généralement
gérer ce problème uniquement lorsque les clients génèrent un grand nombre d’événements, tels qu’un serveur occupé ou
le dc qui a transmis le journal de sécurité.
Limitation et exigence du système

Vous déployez eventlog forwarding dans un environnement de grande taille. Par exemple, vous déployez 40
000 sur 100 000 ordinateurs sources. Dans ce cas, nous vous recommandons de déployer plusieurs collecteurs
de 2 000 à 4 000 clients par collecteur.
En outre, nous vous recommandons d’installer au moins 16 Go de RAM et quatre (4) processeurs sur le
collecteur pour prendre en charge une charge moyenne de 2 000 à 4 000 clients avec un ou deux abonnements
configurés.
Les disques rapides sont recommandés et le journal ForwardedEvents peut être placé sur un autre disque pour
de meilleures performances.
L’utilisation de la mémoire du service Windows event collector dépend du nombre de connexions reçues par le
client. Le nombre de connexions dépend des facteurs suivants :
Fréquence des connexions
Nombre d’abonnements
Nombre de clients
Système d’exploitation des clients
Par exemple, pour les valeurs par défaut de 4 000 clients et de cinq à sept abonnements, la mémoire utilisée par
le service collecteur d’événements Windows peut rapidement dépasser 4 Go et continuer à croître. Cela peut
rendre l’ordinateur indisponible.
Fréquence des connexions client

Trois paramètres contrôlent la fréquence des connexions clientes :
Refresh= (spécifié dans l’URL de configuration de l’GPO)
Deliver yMaxLatency (spécifié dans l’abonnement)
Hear tbeatInter val (spécifié dans l’abonnement)
Paramètre Refresh= dans l’GPO
Ce paramètre est mesuré en secondes. Il contrôle la fréquence à partir de quelle fréquence le client se connecte
à l’URL /WEC pour émaner les abonnements disponibles.
Le collecteur répond en fournissant une liste des abonnements activés pour le client. La réponse inclut les
signets pour chaque canal et la requête Xpath. Dès que le client reçoit les informations, il commence à envoyer
les événements ou les paquets de pulsation à l’URL /Subscriptions. Si les abonnements ne changent pas
fréquemment, ce paramètre peut être configuré pour vérifier toutes les quelques heures, voire moins souvent.
DeliveryMaxLatency
Contrôle la fréquence des connexions client. Pour un déploiement de grande envergure, vous pouvez créer un
abonnement pour les événements urgents avec une fréquence de 5 minutes, et un autre pour les événements
moins urgents sur une fréquence de 2 heures.
HeartbeatInterval
Contrôle l’état Inactif dans la fenêtre d’état d’runtime de la console. Peut être définie sur la même valeur que
Deliver yMaxLatency ou sur une valeur plus élevée pour donner aux clients davantage de temps avant qu’ils
ne soient marqués comme inactifs.
Paramètres personnalisés
Pour configurer des paramètres personnalisés, vous devez utiliser la ligne de commande pour exécuter Wecutil.
Pour plus d’informations, voirWecutil.exe.
Vous pouvez lister l’abonnement configuré en tant que wecutil es .
Vous devez d’abord basculer l’abonnement sur « Personnalisé » :
wecutil ss <SubscriptionName> /cm:"Custom"
Ensuite, définissez le paramètre DeliveryMaxLatency :
wecutil ss <SubscriptionName> /dmlt:7200000
(La valeur est en millisecondes : 7200000 = 2 heures)

Ajustez Hear tbeatInter val à la même valeur. Ce paramètre affecte l’état « Inactif » pour chaque client
dans la console :
wecutil ss <SubscriptionName> /hi:7200000
Optimisation de la distribution des abonnements

Les clients envoient les événements à l’URL /subscriptions. Ces connexions sont très importantes pour
l’utilisation de la mémoire des collecteurs.
Les modes préconfigurés suivants sont disponibles.
Normal
Fournit une remise fiable des événements et ne tente pas d’économiser la bande passante.
Choix approprié, sauf si vous avez besoin d’un contrôle plus étroit sur l’utilisation de la bande
passante ou si vous avez besoin que les événements transmis soient remis aussi rapidement que
possible.
Utilise le mode de remise par pull, par lots cinq éléments à la fois et définit un délai d’exécution par lot
de 15 minutes.
Réduire la bande passante
S’assure que l’utilisation de la bande passante réseau pour la remise d’événements est strictement
contrôlée.
Choix approprié si vous souhaitez limiter la fréquence des connexions réseau pour remettre des
événements.
Utilise le mode de remise Push et définit un délai d’interruption par lot de 6 heures et un intervalle
d’interrogation de 6 heures.
Réduire la latence
Permet de s’assurer que les événements sont remis en ayant un délai minimal.
Choix approprié si vous collectez des alertes ou des événements critiques.
Utilise le mode de remise Push et définit un délai d’exécution par lot de 30 secondes.
Le client se connecte au collecteur à la fréquence spécifiée pour envoyer les événements ou envoyer une
pulsation. Les paramètres « Normal » par défaut peuvent entraîner une utilisation élevée de la mémoire en
ayant entre 2 000 et 4 000 clients par collecteur.
Configurer le nom du collecteur

Vous pouvez configurer le nom du collecteur sur le client en configurant l’objet de stratégie de groupe (GPO)
suivant :
Configuration ordinateur/Modèles d’administration/Composants Windows/Forwarding d’événements/
Configurer le Gestionnaire d’abonnement cible
Vous pouvez également définir des paramètres de Registre dans la sous-clé suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager
Les objets de groupe qui affectent le collecteur à chaque client peuvent être filtrés à l’aide du paramètre de
sécurité sur l’objet de groupe lui-même ou d’un filtre WMI. Par exemple, si le nom de l’ordinateur se termine
toujours par un nombre (tel que computer1, computer2, etc.), nous pouvons créer des objets de groupe pour
faire pointer les clients vers 10 collecteurs différents.
Consolidation des abonnements

La configuration de plusieurs abonnements augmente le nombre de connexions. Les considérations abordées
plus tôt dans cet article s’appliquent à chaque abonnement.
Nous vous recommandons de configurer l’abonnement en éditant la requête Xpath et en mettant plusieurs
requêtes dans le même abonnement.
Suggestions de correctifs pour les problèmes liés à
WMI sur Windows plateformes
Cet article fournit des suggestions de correctifs pour Windows problèmes liés à Management Instrumentation
(WMI) sur Windows plateformes.
Symptômes
En raison du volume d’incidents de support gérés par les services de support Microsoft pour les problèmes liés
aux correctifs suivants, ceux-ci sont recommandés pour l’installation pour les plateformes indiquées ci-dessous.
Ces correctifs sont associés à l’opération et aux fonctionnalités du service WMI et de ses composants connexes.
Lorsque vous rencontrez des problèmes liés à WMI sur un système, les symptômes peuvent varier
considérablement en fonction de la cause première. Voici quelques exemples de symptômes de haut niveau
signalés dans les incidents de support qui peuvent être résolus avec l’application des correctifs indiqués :
Perte de fonctionnalités avec les logiciels de gestion/surveillance d’entreprise pour différents ordinateurs.
Exemples de logiciels : Microsoft SCOM/SMS, IBM Tivoli, LANDesk Management, HP OpenView, BMC(
Surveillance BMC), etc.
Perte de fonctionnalités liée à l’équilibrage de charge des services Terminal 3 Citrix.
Perte de fonctionnalités pour les scripts WMI.
Temps d’accès utilisateur lent sur les serveurs terminal Citrix.
Les temps d’Windows utilisateur sont lents sur les clients où des filtres de stratégie de groupe WMI sont en
place.
Symptômes plus granulaires
Impossible de se connecter aux espaces de noms root\default, root\cimv2 et/ou root\citrix via WBEMTEST.
Référentiel de plus en plus grand lié aux OBJETS. Fichier DATA.
Notez les entrées d’espaces de noms CITRIX imbrmbrées à plusieurs reprises dans WMIMGMT. MSC. Les
contrôles WMI > propriétés > SECURITY > structure RACINE pour noter les espaces de noms
manquants/exexercis.
Résolution
Correctif logiciel pour Windows Vista et Windows Ser ver 2008
2464876 référentiel WMI est endommagé sur un ordinateur exécutant Windows Server 2008 ou
Windows Vista
Liste de correctifs pour Windows 7 et Windows Ser ver 2008 R2
2692929 0x80041001 erreur lorsque la classe WMI Win32_Environment est interrogée par
plusieurs demandeurs dans Windows 7 ou Windows Server 2008 R2
2617858 démarrage ou le processus d’Windows server 2008 R2 ou dans Windows 7
NOTE
La 2617858 MSKB inclut la résolution du correctif processeur élevé dans MSKB 2505348 ET un correctif
pour les référentiels WMI marqués de façon incorrecte après des arrêts inappropriés, ce qui déclenche une
vérification complète au démarrage du système d’exploitation suivant. L'2505348 MSKB est-il en première
place par MKSB 2617858.
2492536 Msinfo32.exe prend beaucoup de temps pour afficher ou exporter des informations
système sur un ordinateur qui dispose de nombreux appareils pris en charge par MSI-X et qui
exécute Windows 7 ou Windows Server 2008 R2
NOTE
MSKB 2492536 mises à jour Cimwin32.dll sur les ordinateurs exécutant Windows 7 et Windows Server
2008 R2 RTM ou avec Service Pack 1 (SP1) installé. Alors que MSKB 2692929 mises à jour Cimwin32.dll
vers une version la plus récente et s’applique à l’ordinateur sur qui SP1 est installé.
982293 Processus Svchost.exe qui a le service WMI se crashe dans Windows Server 2008 R2 ou
dans Windows 7 Remarque : MSKB 982293 s’applique aux ordinateurs exécutant Windows 7 ou
Windows Server 2008 R2 sans Service Pack 1 (SP1)
974930 Une application ou un service qui interroge des informations sur un cluster deover à l’aide
du fournisseur WMI peut faire l’expérience de performances faibles ou d’une exception de délai
d’accès
Le message du journal des événements indique que
Windows installer a reconfiguré toutes les
applications installées
Cet article permet de résoudre les problèmes de démarrage du système ou de connexion lents qui se produisent
lorsqu’une stratégie de groupe avec un filtre WMIFilter ou une application installée interroge la Win32_Product
classe.
Symptôme
Vous pouvez être en situation de ralentissement du démarrage du système ou de problèmes de connexion. En
outre, vous pouvez voir l’événement suivant dans le journal des événements d’application :

Source : MsiInstaller
Date : mmddyyy hh:mm:ss
Utilisateur : SYSTEM
Ordinateur :
Description :
Windows Le programme d’installation a reconfiguré le produit. Nom du produit <ProductName> : . Version
du produit <VersionNumber> : . Langue du produit <languageID> : . État de réussite ou d’erreur de
reconfiguration : 0.
Vous verrez cet événement pour chaque application installée sur l’ordinateur.
Le journal des événements système indique que le service Windows Installer démarre et s’arrête
automatiquement.

Date : mmddyyyy
Heure : hh:mm:ss
Utilisateur : AUTORITÉ NT\SYSTÈME
Description :
Le service Windows Installer a été correctement envoyé un contrôle de démarrage. Pour plus
d’informations, voir centre d’aide et de support < http://go.microsoft.com/fwlink/events.asp >.
Date : mmddyyyy
Heure : hh:mm:ss
Utilisateur : N/A
Description :
Le service Windows Installer est entré dans l’état arrêté.
Pour plus d’informations, voir centre d’aide et de support < http://go.microsoft.com/fwlink/events.asp >.
Cause
Ce problème peut se produire si l’une des conditions suivantes est vraie :
Vous avez une stratégie de groupe avec un filtre WMIFilter qui interroge la Win32_Product classe.
Une application est installée sur l’ordinateur qui interroge la Win32_Product classe.
Résolution
Si vous utilisez une stratégie de groupe avec le filtre WMIFilter qui interroge , modifiez Win32_Product le filtre à
Win32reg_AddRemovePrograms utiliser.
Si vous avez une application qui utilise la classe précédente, contactez le fournisseur pour obtenir une version
mise à jour qui n’utilise pas cette classe.
Pour affiner l’application à l’origine du problème, vous pouvez suivre la méthode de dépannage du démarrage
propre.
Win32_product n’est pas optimisée pour la requête. Requêtes telles que l’utilisation du fournisseur MSI par WMI
pour énumérer tous les produits installés, puis l’énumération séquentielle de la liste complète pour gérer la
select * from Win32_Product where (name like 'Sniffer%') where clause. Ce processus démarre également une
vérification de la cohérence des packages installés, de la vérification et de la réparation de l’installation. Un
compte avec uniquement des privilèges d’utilisateur peut entraîner un retard dans le lancement de l’application
et un événement 11708 indiquant un échec d’installation, car le compte d’utilisateur peut ne pas avoir accès à
un certain nombre d’emplacements.
Win32reg_AddRemovePrograms est un moyen beaucoup plus léger et efficace de le faire, ce qui évite les appels pour
une vérification de résilience, en particulier dans un environnement verrouillé. Ainsi, lors de l’utilisation, nous
n’appelleront pas msiprov.dll et ne lancerons pas de vérification Win32reg_AddRemovePrograms de résilience.
Les événements ne sont pas transmis si le collecteur
exécute Windows Server
Cet article vous aide à résoudre un problème qui se produit lorsque vous utilisez le forwarding d’événement
initié par la source pour envoyer des événements à un collecteur d’événements Microsoft Windows Server.
Symptômes
Vous configurez un ordinateur Windows Server 2019 ou Windows Server 2016 en tant que collecteur
d’événements. Vous configurez également un abonnement à l’origine de la source (et les objets de stratégie de
groupe associés) pour le forwarding d’événement. Toutefois, les événements ne sont pas transmis et les
ordinateurs sources d’événements enregistrent des messages d’événement semblables à ce qui suit :
Log Name: Microsoft-Windows-Forwarding/Operational

Event ID: 105
Task Category: None
User: NETWORK SERVICE
Description:
The forwarder is having a problem communicating with subscription manager at address
http://W19SRV.contoso.com:5985/wsman/SubscriptionManager/WEC. Error code is 2150859027 and Error Message is
The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not
available. This is usually returned by a HTTP server that does not support the WS-Management protocol.
</f:Message></f:WSManFault>.
Cause
Ce comportement est dû aux autorisations configurées pour les URL suivantes :
http://+:5985/wsman/
http://+:5986/wsman/
Sur l’ordinateur du collecteur d’événements, le service de collecteur d’événements Windows (WecSvc) et le

service de gestion à distance Windows (WinRM) utilisent ces URL. Toutefois, les listes de contrôle d’accès par
défaut pour ces URL permettent d’accéder uniquement au processus svchost qui exécute WinRM. Dans la
configuration par défaut de Windows Server 2016, un seul processus svchost exécute WinRM et WecSvc. Étant
donné que le processus a accès, les deux services fonctionnent correctement. Toutefois, si vous modifiez la
configuration de sorte que les services s’exécutent sur des processus hôtes distincts, WecSvc n’a plus accès et le
forwarding d’événements ne fonctionne plus.
Les services fonctionnent différemment dans Windows Server 2019. Si un ordinateur Windows Server 2019
dispose de plus de 3,5 Go de RAM, des processus svchost distincts exécutent WinRM et WecSvc. En raison de
cette modification, le forwarding d’événements peut ne pas fonctionner correctement dans la configuration par
défaut. Pour plus d’informations sur les modifications apportées au service, voir Modifications apportéesau
regroupement de l’hôte de service dans Windows 10 .
Résolution
Pour afficher les autorisations d’URL, ouvrez une fenêtre d’invite de commandes avec élévation de niveaux et
exécutez la netsh http show urlacl commande.
Pour corriger les autorisations d’URL, utilisez la fenêtre d’invite de commandes avec élévation de élévation de
niveaux et exécutez les commandes suivantes :
netsh http delete urlacl url=http://+:5985/wsman/

netsh http add urlacl url=http://+:5985/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-
1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)
netsh http delete urlacl url=https://+:5986/wsman/
netsh http add urlacl url=https://+:5986/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-
1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)
Autorisations d’URL par défaut utilisées par Windows Server 2019 et Windows Server 2016
URL réservée : http://+:5985/wsman/
Utilisateur : NT SERVICE\WinRM
Listen: Yes
Délégué : Non
SDDL : D:(A;; GX;;; S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)
URL réservée : https://+:5986/wsman/
Listen: Yes
Délégué : Pas de SDDL : D:(A;; GX;;; S-1-5-80-569256582-2953403351-2909559716-1301513147-
412116970)
Autorisations d’URL par défaut utilisées par Windows Server 2012 R2

URL réservée : http://+:5985/wsman/
Listen: Yes
Délégué : Non
Utilisateur : NT SERVICE\Wecsvc
Listen: Yes
Délégué : Non
SDDL : D:(A;; GX;;; S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;; GX;;; S-1-
5-80-4059739203-877974739-1245631912-527174227-2996563517)
URL réservée : https://+:5986/wsman/
Listen: Yes
Délégué : Non
Utilisateur : NT SERVICE\Wecsvc
Listen: Yes
Délégué : Non
SDDL : D:(A;; GX;;; S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;; GX;;; S-1-
5-80-4059739203-877974739-1245631912-527174227-2996563517)
Documentation de dépannage de la gestion des
applications pour Windows Server
problèmes liés à la gestion des applications et à leur propre résolution. Les rubriques sont divisées en sous-
Sous-catégories gestion des applications

.NET Framework’installation
Applications 1st Party
Application Compatibility Shared Computer Toolkit (ACT)
Performances et stabilité com et COM+
Programmation COM et DCOM
Administration, configuration et sécurité COM+
Démarrage, configuration, connectivité et cluster DTC
Système d’événements
MSI
interface utilisateur multilingue (MUI) et Input Method Editor (IME)
Windows Hôte de script (CScript ou WScript)
Les services qui dépendent du service d’ASP.NET ne
démarrent pas après la mise à niveau vers .NET
Framework 4.0
Cet article fournit une solution de contournement pour un problème dans lequel les services qui dépendent du
service d’états ne démarrent pas après la mise à niveau vers ASP.NET Microsoft .NET Framework 4.0.
Symptômes
Vous avez un ordinateur qui exécute Windows Server.
Le service ASP.NET’états est installé dans le cadre d’Internet Information Services (IIS).
Un service installé dépend du service ASP.NET d’états.
Vous pouvez mettre à niveau microsoft .NET Framework 3.51 vers .NET Framework 4.0.
Dans ce scénario, vous remarquez qu’après la mise à niveau de .NET Framework, tout service qui dépend du
service d’états ASP.NET ne démarre pas et génère l’erreur suivante :
Windows n’a pas pu démarrer <service name> le service sur <computer name> .
Erreur 1075 : le service de dépendance n’existe pas ou a été marqué pour suppression.
Vous remarquerez également que le service ASP.NET’états n’est plus répertorié dans la console de gestion des
services.
Cause
Il s’agit d’un problème connu qui se produit lorsque vous mettez à jour .NET Framework.
1. Ouvrez la console de gestion des services (services.msc).
2. Changez en Manual the start type of any service that depends on the ASP.NET State Service and that is
set to Automatic .
3. À l’invite de commandes Administrative, tapez la commande suivante, puis appuyez sur Entrée :
%SystemRoot%\ Microsoft.NET\Framework64\v4.0.30319 \aspnet_regiis /iru
5. Ouvrez de nouveau la console de gestion des services (services.msc).
6. Changez en Automatique le type de démarrage du ou des services dont le type de démarrage a été
modifié à l’étape 2, qui dépendent du service d’états ASP.NET et dont le type de démarrage est
maintenant manuel. Redémarrez l’ordinateur, puis confirmez que le problème est résolu.
L’onglet Accès à distance n’est pas disponible dans
le composant logiciel en composant logiciel en ligne
de la MMC Utilisateurs et ordinateurs Active
Directory après l’installation des outils
d’administration de serveur distant pour Windows 7
Cet article fournit des solutions de contournement pour un problème dans lequel l’onglet Numérotation n’est
pas disponible dans le composant logiciel en ligne MMC Utilisateurs et ordinateurs Active Directory.
Symptômes
Après avoir installé les outils d’administration de serveur distant pour Windows 7 sur un ordinateur exécutant
Windows 7, l’onglet Connexion est absent des propriétés d’un compte d’utilisateur dans le composant logiciel en
ligne MMC (Active Directory Users and Computers).
Cause
Ce problème se produit car le manifeste RSAT et le package d’installation n’incluent pas les modules Rasuser.dll
et Rtrfiltr.dll requis pour charger l’onglet Dial-In.
Pour contourner ce problème, utilisez l’une des solutions de contournement suivantes, le cas échéant.
Sur l’ordinateur exécutant Windows 7, utilisez les services Bureau à distance pour vous connecter à un serveur
exécutant Windows Server 2008 R2, Windows Server 2008 ou Windows Server 2003. Ensuite, démarrez le
logiciel en snap-in MMC Utilisateurs et ordinateurs Active Directory sur le serveur.
Solution de contournement 2 (Windows Server 2008)
1. Sur un serveur exécutant Windows Server 2008, installez le rôle services Terminal Server, puis installez
le service de rôle Terminal Ser ver pour activer l’utilisation de RemoteApp Manager.
2. Ajouter des utilisateurs et ordinateurs Active Directory (DSA. MSC) en tant qu’application distante.
3. Sur l’ordinateur qui exécute Windows 7, accédez à la DSA RemoteApp. MSC.
Solution de contournement 2 (Windows Server 2008 R2)
1. Sur le serveur qui exécute Windows Server 2008 R2, installez le rôle Services Bureau à distance, puis
installez le service de rôle Hôte de session Bureau à distance pour activer l’utilisation du Gestionnaire
RemoteApp.
2. Ajouter des utilisateurs et ordinateurs Active Directory (DSA. MSC) en tant qu’application distante.
3. Sur l’ordinateur qui exécute Windows 7, accédez à la DSA RemoteApp. MSC.
Statut
S’applique à ».
Pour plus d’informations Windows Services Terminal Server 2008, consultez le site Web Microsoft suivant
:https://technet.microsoft.com/library/cc268349.aspx
Pour plus d’informations sur Windows Services Bureau à distance Server 2008 R2, visitez le site Web Microsoft
suivant :https://technet.microsoft.com/library/dd647502(WS.10).aspx
L’outil de diagnostic Direct-X peut signaler une
valeur inattendue pour la mémoire des adaptateurs
d’affichage
Cet article décrit un problème dans lequel l’outil de diagnostic Direct-X (DXDIAG) signale une valeur inattendue
pour la mémoire des adaptateurs d’affichage.
Symptômes
Vous avez un système avec 1 Go ou plus de mémoire vidéo et 4 Go ou plus de mémoire système (RAM). Vous
exécutez l’outil Diagnostics Direct-X et signale que vous avez une quantité inattendue de mémoire totale
approximative sous l’onglet d’affichage. Vous pouvez également voir des problèmes avec certains jeux ou
applications qui ne vous permettent pas de sélectionner les paramètres de détail les plus élevés.
Cause
L’API que DXDiag utilise pour approximativement la mémoire système n’a pas été conçue pour gérer les
systèmes de cette configuration
Résolution
Microsoft travaille à résoudre ce problème dans les prochaines publication.
Sur un système avec 1 Go de mémoire vidéo, les valeurs suivantes sont renvoyées avec la mémoire système
associée :
M ÉM O IRE SY ST ÈM E M ÉM O IRE TOTA L E A P P RO XIM AT IVE SIGN A L ÉE
4 Go 3 496 Mo
6 Go 454 Mo
8 Go 1 259 Mo
Erreur « L’analyse Best Practices Analyzer a échoué
» lors de l’exécution de Best Practice Analyzer
Cet article fournit une résolution de l’erreur « L’analyse Best Practices Analyzer a échoué » lors de l’exécution de
Best Practice Analyzer.
Symptômes
Lorsque vous exécutez un best Practices Analyzer (BPA) dans Windows Server 2008 R2 Server Manager, il
renvoie l’erreur suivante :
L’analyse Best Practices Analyzer a échoué.

Une erreur de moteur Best Practice Analyzer s’est produite pour l’ID de modèle : «
Microsoft/Windows/FileServices » lors de l’exécution du modèle. (Exception interne : un ou plusieurs
documents de modèle ne sont pas valides : {0} L’exception de découverte s’est produite dans le fichier {0} de
traitement ' ' .
Windows PowerShell votre stratégie d’exécution a été correctement mise à jour, mais le paramètre est passé
à une stratégie définie à une étendue plus spécifique. En raison du remplacement, votre shell conserve sa
stratégie d’exécution effective actuelle de « RemoteSigned ». Tapez « Get-ExecutionPolicy -List » pour afficher
vos paramètres de stratégie d’exécution. Pour plus d’informations, voir « Get-Help Set-ExecutionPolicy ».)
Cause
L’erreur BPA se produit si vous activez la stratégie Activer l’exécution de script pour contrôler l’exécution des
scripts PowerShell et si vous la définissez sur Autoriser uniquement les scripts signés ou Autoriser les scripts
locaux et les scripts signés à distance. L’erreur se produit également si l’exécution de script d’activer est
définie sur Désactivé.
L’erreur ne se produit pas si la stratégie est définie sur Autoriser tous les scripts.
Résolution
Supprimez, désactivez ou définissez sur « Non configuré » le paramètre de stratégie de groupe suivant qui est
appliqué au serveur avec l’erreur BPA.
Configuration ordinateur\Modèles d’administration\Composants Windows\Windows

PowerShell
Activer l’exécution de script
Le BPA commence à fonctionner une fois que la modification de stratégie s’applique. Aucun redémarrage n’est
nécessaire pour que la modification prenne effet.
Une application COM+ peut cesser de fonctionner
Windows lorsqu’un utilisateur se déconnecte
Cet article fournit une solution à un problème dans lequel une application COM+ cesse de fonctionner Windows
lorsqu’un utilisateur se déconnecte.
les éditions, Windows 7 Service Pack 1
Symptômes
Sur un Windows, vous avez une application serveur COM+ dans laquelle l’identité est configurée pour
s’exécuter en tant qu’utilisateur spécifique. Après un certain temps de travail, l’application peut cesser de
fonctionner et continuer à échouer. Vous devez redémarrer l’application COM+ pour résoudre le problème.
Vous pouvez voir une erreur semblable à ce qui suit dans le journal des applications sur l’ordinateur CLIENT. Si le
exécutable client s’exécute sur le même ordinateur que l’application serveur COM+, vous verrez cette erreur sur
le serveur COM+ :

Source de l’événement : DCOM
Date : <DateTime>
Heure : <DateTime>
Utilisateur : Domaine\utilisateur
Ordinateur : *****
Description :
DCOM a reçu l’erreur « Erreur non spécifiée » de l’ordinateur « servername » lors de la tentative d’activation
du serveur : {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
Dans ce cas, le message d’événement vous indique que l’erreur (E_FAIL ou 80004005 ou une erreur non
spécifiée) est renvoyée à partir du serveur. Le CLSID du composant est répertorié dans l’entrée du journal des
événements.
Vous verrez également des événements semblables à ce qui suit dans le journal des applications de l’ordinateur
sur lequel l’application COM+ s’exécute :

Source : Service de profils Windows-utilisateur Microsoft
Date : <DateTime>
Utilisateur : SYSTÈME
Ordinateur : SERVERNAME
Description :
Windows votre fichier de Registre est toujours en cours d’utilisation par d’autres applications ou services. Le
fichier sera déchargé maintenant. Les applications ou les services qui tiennent votre fichier de Registre
peuvent ne pas fonctionner correctement par la suite.
DETAIL -
1 handles de Registre utilisateur divulgués à partir de \Registry\User\S-1-5-21-1049297961-3057247634-
349289542-1004_Classes :
Le processus 2428 (\Device\HarddiskVolume1\Windows\System32\dllhost.exe) a ouvert la clé
\REGISTRY\USER\S-1-5-21-1123456789-3057247634-349289542-1004_CLASSES
L’appel de création d’une instance du composant peut s'0x800703fa.
Cause
L’identité d’utilisateur associée à l’application COM+ est connectée lors de la première initialisation de
l’application COM+. Si cet utilisateur se déconnecte de l’ordinateur, le profil de l’utilisateur est déchargé et
l’application COM+ ne peut plus lire les clés de Registre dans le profil de l’identité de l’utilisateur. À partir
Windows Vista, le service de profil utilisateur force le déchargement d’un profil utilisateur lorsque cet utilisateur
se déconnecte. Il s’agit d’une situation dans laquelle la fonctionnalité de forcer le déchargement du profil
utilisateur peut rompre une application si les handles de Registre ne sont pas fermés dans le processus. Cette
nouvelle fonctionnalité de service de profil utilisateur est le comportement par défaut.
Résolution
Pour contourner ce problème, il peut être nécessaire de modifier le comportement par défaut du service de
profil utilisateur. Le paramètre de stratégie Ne décharge pas forcément le Registre de l’utilisateur au niveau de
la décodeur de l’utilisateur contre le comportement par défaut des systèmes d’exploitation Vista et les systèmes
d’exploitation plus nouveaux. Lorsqu’il est activé, le service de profil utilisateur ne décharge pas le Registre de
force, mais attend qu’aucun autre processus n’utilise le Registre de l’utilisateur avant de le décharger. La
stratégie se trouve dans l’éditeur de stratégie de groupe (gpedit.msc). La stratégie Ne pas décharger de force
le Registre de l’utilisateur lors de la stratégie de décomft de l’utilisateur se trouve sous Les modèles
d’administration de configuration ordinateur > > modèles système > profils utilisateur .
Modifiez le paramètre de Non configuré à Activé, ce qui désactive la nouvelle fonctionnalité de service de
profil utilisateur. DisableForceUnload est la valeur ajoutée au Registre.
Windows déchargera toujours le Registre des utilisateurs, même s’il existe des poignées ouvertes pour les clés
de Registre par utilisateur lors de la décoff. À l’aide de ce paramètre de stratégie, un administrateur peut annuler
ce comportement, ce qui empêche Windows les utilisateurs de décharger de force le Registre des utilisateurs
lors de la décomffage de l’utilisateur.
NOTE
Cette stratégie doit être utilisée uniquement dans les cas où vous pouvez être en cours d’exécution dans des problèmes
de compatibilité d’application en raison de ce comportement Windows spécifique. Il n’est pas recommandé d’activer cette
stratégie par défaut, car elle peut empêcher les utilisateurs d’obtenir une version mise à jour de leur profil utilisateur
itinérant.
Si vous activez ce paramètre de stratégie, Windows ne décharge pas forcément le Registre des utilisateurs lors
de la fermeture de la logoff, mais décharge le Registre lorsque tous les handles ouverts vers les clés de Registre
par utilisateur sont fermés.
Si vous désactivez ou ne configurez pas ce paramètre de stratégie, Windows déchargera toujours le Registre des
utilisateurs lors de la décoff, même s’il existe des poignées ouvertes pour les clés de Registre par utilisateur lors
de la décoff.
Même si vous avez activé le paramètre Ne pas décharger de force le Registre de l’utilisateur au niveau du
paramètre de stratégie de décomft de l’utilisateur, l’avertissement de l’ID d’événement 1530 peut être
enregistré. L’avertissement est consigné après la première tentative de déchargement de la ruche du Registre. En
cas d’échec, la stratégie est vérifiée pour déterminer si la ruche du Registre doit être forcée de décharger
indépendamment des handles de Registre ouverts.
Les performances se dégradent lorsque vous
accédez à des fichiers de grande
FILE_FLAG_RANDOM_ACCESS
Cet article fournit une solution à un problème de dégradation des performances du système d’exploitation
lorsqu’un ou plusieurs processus accèdent à plusieurs fichiers de grande taille à l’aide de CreateFile() l’API et
de FILE_FLAG_RANDOM_ACCESS l’indicateur.
Symptômes
Les performances du système d’exploitation peuvent se dégrader lorsqu’un ou plusieurs processus accèdent à
plusieurs fichiers de grande taille à l’aide de CreateFile() l’API et de FILE_FLAG_RANDOM_ACCESS l’indicateur. La
dégradation des performances est dû à la consommation de mémoire disponible par le cache système (visible
dans le compteur de performances Memory\Cache Bytes).
Cause
L’indicateur est un indicateur pour le Gestionnaire de cache que le fichier sera ouvert pour des
FILE_FLAG_RANDOM_ACCESS opérations d’opérations d’ouverture aléatoires. Les O/S aléatoires signifient qu’il
n’existe aucun modèle prévisible pour les O/S qui aura lieu. Cet indicateur désactive les avances de lecture
intelligentes et empêche le démapage automatique des vues une fois que les pages sont lues afin de minimiser
le mappage/le démappage lorsque le processus resserre cette partie du fichier. Cela permet de garder les
affichages lus précédemment dans le jeu de travail Gestionnaire de cache. Toutefois, si la taille cumulée des
fichiers accédés dépasse la mémoire physique, le fait de conserver autant d’affichages dans le jeu de travail
Gestionnaire de cache peut nuire aux performances globales du système d’exploitation, car elle peut consommer
une grande quantité de RAM physique.
Résolution
Supprimez FILE_FLAG_RANDOM_ACCESS l’indicateur lorsque l’application ouvre le ou les fichiers avec CreateFile .
Cela permet aux vues d’être non mappées et déplacées vers la liste de veille une fois que les pages lues sont
terminées. Cela nécessite l’intervention du développeur de logiciels.
Références
Fonction CreateFileA (fileapi.h)
0x80004027'erreur lorsque vous essayez d’accéder à
l’objet COM+ à distance après la mise à niveau vers
Windows Server 2016
Cet article fournit une solution à l’erreur 0x80004027-CO_E_CLASS_DISABLED qui se produit lorsque vous
accédez à distance à l’objet COM+ après la mise à niveau vers Windows Server 2016.
Symptômes
Après la mise à niveau d’une version antérieure de Windows Server vers Windows Server 2016, les applications
ne peuvent pas accéder à distance à un objet COM+ et vous recevez le message d’erreur suivant :
0x80004027-CO_E_CLASS_DISABLED
Cause
Ce problème se produit car la prise en charge du rôle serveur d’applications a été supprimée Windows Server
2016. Cette modification bloque les applications qui reposent sur l’accès à distance COM+.
Résolution
IMPORTANT
Pour résoudre ce problème et activer l’accès à distance COM+, suivez les étapes suivantes :
1. Activez l’accès réseau COM+ dans Windows pare-feu. Pour ce faire, ouvrez le Panneau de Windows,
cliquez sur l’élément Pare-feu de Windows, puis cliquez sur Autoriser une application ou une
fonctionnalité via Windows pare-feu.
2. Dans la liste Applications et fonctionnalités autorisées, cochez la case COM+ Accès réseau, puis
sélectionnez l’étendue appropriée requise pour votre application. Pour les entreprises, il s’agit
généralement de Domaine. Toutefois, votre application peut nécessiter des paramètres supplémentaires,
selon le scénario.
3. Définissez la valeur de Registre qui autorise l’accès à distance COM+. Pour cela, procédez comme suit :
a. Dans la zone de recherche Démarrer, tapez regedit, puis cliquezregedit.exedans la liste des résultats.
b. Recherchez la sous-clé suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3
c. Cliquez avec le bouton droit sur le DWORD RemoteAccessEnabled.
d. Dans la zone de données Valeur, entrez 1.
e. Cliquez sur OK .
Erreur lors du démarrage de nombreuses
applications COM+ : Code d’erreur 80080005 --
Échec de l’exécution du serveur
Cet article fournit une solution de contournement pour un problème dans lequel vous recevez des 80080005 de
code d’erreur lorsque vous démarrez manuellement de nombreuses applications Microsoft COM+ à partir d’un
composant logiciel en composant logiciel en ligne microsoft (MMC) Component Services.
Symptômes
Lorsque vous démarrez manuellement de nombreuses applications Microsoft COM+ à partir du composant
logiciel en ligne MMC (Component Services Microsoft Management Console) dans lequel chaque application
COM+ s’exécute sous un compte d’utilisateur différent, vous pouvez recevoir le message d’erreur suivant :
Erreur de catalogue : une erreur s’est produite lors du traitement de la dernière opération. Code d'80080005
- Échec de l’exécution du serveur. Le journal des événements peut contenir des informations de dépannage
supplémentaires.
Vous recevrez un message d’erreur semblable au suivant dans le journal des applications de l’Observateur
d’événements :
Type: Error
Source: DCOM
Category: None
Event ID: 10010
Date: 31/03/2004
Time: 15:13:30
User: NT AUTHORITY\SYSTEM
Computer: MSHSRMSWEBP0007
Description: The server {F1673109-CF44-468D-9E23-FE4116F84CFA} did not register with DCOM within the
required timeout.
Cause
Si de nombreuses applications COM+ s’exécutent sous des comptes d’utilisateur différents spécifiés dans la
propriété This User, l’ordinateur ne peut pas allouer de mémoire pour créer un tas de bureau pour le nouvel
utilisateur. Par conséquent, le processus ne peut pas démarrer.
IMPORTANT
Pour contourner ce problème, modifiez la valeur de la sous-clé de Registre suivante :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

2. Dans l'éditeur du registre, recherchez la sous-clé de registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems
Par défaut, l’entrée Windows dans la sous-clé a une valeur similaire à la suivante (sur une seule ligne) :
%SystemRoot% \ system32 \csrss.exe ObjectDirectory= \ Windows SharedSection=1024,3072
Windows=On SubSystemType=Windows ServerDll=basesrv,1
ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2
ProfileControl=Off MaxRequestThreads=16
3. Cliquez avec le bouton droit sur Windows entrée, puis cliquez sur Modifier. La boîte de dialogue
Modifier la chaîne s’affiche.
4. Dans la zone de données Valeur, recherchez SharedSection, ajoutez 512 à SharedSection, puis cliquez
sur OK .
L’entrée Windows nouvellement modifiée se lit comme suit :
%SystemRoot% \ system32 \csrss.exe ObjectDirectory= \ Windows SharedSection=1024,3072,512
Windows=On SubSystemType=Windows ServerDll=basesrv,1
ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2
ProfileControl=Off MaxRequestThreads=16
Étapes pour reproduire le comportement

1. Créez 100 comptes d’utilisateurs locaux différents sur votre ordinateur.
2. Ouvrez le composant logiciel en snap-in MMC des services de composants. Pour cela, procédez comme
suit :
a. Cliquez sur Démarrer , pointez sur Paramètres , puis cliquez sur Panneau de configuration .
b. Dans le Panneau de contrôle, double-cliquez sur Outils d’administration, puis double-cliquez sur
Ser vices de composants. Le composant logiciel en snap-in MMC des services de composants
s’affiche.
c. Dans le volet gauche, développez Ser vices de composants, Développez Ordinateurs, puis
Développez Mon ordinateur.
3. Créez une application COM+, puis définissez l’identité de l’application COM+. Pour cela, procédez comme
suit :
a. Cliquez avec le bouton droit sur COM+ Applications, pointez sur Nouveau, puis cliquez sur
Application . La boîte de dialogue Bienvenue dans l’Assistant Installation d’application
COM s’affiche.
b. Dans la boîte de dialogue Bienvenue dans l’Assistant Installation d’application COM, cliquez
sur Suivant. La boîte de dialogue Installer ou créer une application s’affiche.
c. Cliquez sur Créer une application vide. La boîte de dialogue Créer une application vide
s’affiche.
d. Dans la zone Entrer un nom pour la nouvelle application, tapez MyCOM1, puis cliquez sur
Suivant . La boîte de dialogue Définir l’identité de l’application s’affiche.
e. Cliquez sur Cet utilisateur, puis tapez un nom d’utilisateur que vous avez créé à l’étape 1 dans la
zone Utilisateur.
f. Dans la boîte de dialogue Définir l’identité de l’application, tapez votre mot de passe dans la zone
Mot de passe et dans la zone Confirmer le mot de passe, puis cliquez sur Suivant . La boîte de
dialogue Merci d’avoir utilisé l’Assistant Installation d’application COM s’affiche.
g. Cliquez sur Terminer .
4. Ajoutez un composant à l’application COM+. Pour cela, procédez comme suit :
a. Dans le volet gauche du composant logiciel en ligne de la MMC Component Ser vices, développez
MyCom1 .
b. Cliquez avec le bouton droit sur Composants, pointez sur Nouveau, puis cliquez sur Composant.
La boîte de dialogue Bienvenue dans l’Assistant Installation de composant COM s’affiche.
c. Cliquez sur Suivant . La boîte de dialogue Impor ter ou installer un composant s’affiche.
d. Cliquez sur Impor ter des composants déjà enregistrés. La boîte de dialogue Choisir les
composants à impor ter s’affiche.
e. Dans la liste Composants sur : Mon ordinateur, cliquez sur un composant, puis sur Suivant . La
boîte de dialogue Merci d’avoir utilisé l’Assistant Installation d’application COM s’affiche.
f. Cliquez sur Terminer .
5. Répétez l’étape 3 pour créer 100 applications COM+ qui s’exécutent sous différents comptes
d’utilisateurs locaux.
6. Répétez l’étape 4 pour ajouter des composants aux 100 applications COM+ que vous avez créées à
l’étape 5.
7. Dans le volet gauche du composant logiciel en ligne de la MMC Ser vices de composants, cliquez avec le
bouton droit sur chaque application COM+ que vous avez créée, puis cliquez sur Démarrer. Après avoir
commencé certaines applications COM+, vous recevez le message d’erreur décrit dans la section
Symptômes.
Références
Création d’une application COM+
Configurer Microsoft Distributed Transaction
Coordinator (DTC) pour qu’il fonctionne à travers
un pare-feu
Cet article explique comment configurer Microsoft Distributed Transaction Coordinator (DTC) pour qu’il
fonctionne à travers les pare-feu.
Vous pouvez configurer le DTC pour communiquer par le biais de pare-feu, y compris les pare-feu de traduction
d’adresses réseau.
DTC utilise l’allocation de port dynamique RPC (Remote Procedure Call). Par défaut, l’allocation de port
dynamique RPC sélectionne de manière aléatoire les numéros de port supérieurs à 1024. En modifiant le
Registre, vous pouvez contrôler quels ports RPC allouent dynamiquement pour les communications entrantes.
Vous pouvez ensuite configurer votre pare-feu pour limiter les communications externes entrantes vers ces
ports et le port 135 (port de mapper du point de terminaison RPC).
Vous devez fournir un port dynamique entrant pour DTC. Vous devrez peut-être fournir davantage de ports
dynamiques entrants pour d’autres sous-systèmes qui reposent sur RPC.
Les clés de Registre et les valeurs décrites dans cet article n’apparaissent pas dans le Registre par défaut . vous
devez les ajouter à l’aide de l’Éditeur du Registre.
IMPORTANT
up and restore the registry in Window.
Suivez ces étapes sur les deux ordinateurs pour contrôler l’allocation de ports dynamiques RPC. Le pare-feu doit
être ouvert dans les deux sens pour les ports spécifiés :
1. Pour démarrer l’Éditeur du Registre, sélectionnez Démarrer, Exécuter, tapez regedt32, puis
sélectionnez OK.
Utilisez Regedt32.exe au lieu de Regedit.exe. Regedit.exe ne prend pas en charge REG_MULTI_SZ type de
données requis pour la valeur Ports.
2. Dans l’Éditeur du Registre, sélectionnez HKEY_LOCAL_MACHINE dans la fenêtre Ordinateur local.
3. Développez l’arborescence en double-sélectionnant les dossiers nommés dans le
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc chemin d’accès.
4. Sélectionnez le dossier RPC, puis sélectionnez Ajouter une clé dans le menu Edition.
5. Dans la boîte de dialogue Ajouter une clé, dans la zone Nom de la clé, tapez Internet, puis sélectionnez
OK.
6. Sélectionnez le dossier Internet, puis sélectionnez Ajouter une valeur dans le menu Edition.
7. Dans la boîte de dialogue Ajouter une valeur, dans la zone Nom de la valeur, tapez Ports.
8. Dans la zone Type de données, sélectionnez REG_MULTI_SZ, puis sélectionnez OK.
9. Dans la boîte de dialogue Éditeur de chaînes multiples, dans la zone Données, spécifiez le ou les ports
que rpc doit utiliser pour l’allocation de ports dynamiques, puis sélectionnez OK .
Chaque valeur de chaîne que vous tapez spécifie soit un seul port, soit une plage de ports inclusive. Par
exemple, pour ouvrir le port 5000, spécifiez 5000 sans les guillemets. Pour ouvrir les ports 5000 à 5020
inclus, spécifiez 5000-5020 sans les guillemets. Vous pouvez spécifier plusieurs ports ou plages de
ports en spécifiant une ou plusieurs plages de ports par ligne. Tous les ports doivent être de la plage
1024 à 65535. Si un port se trouve en dehors de cette plage ou si une chaîne n’est pas valide, RPC
considère toute la configuration comme non valide.
Microsoft recommande d’ouvrir des ports à partir de 5 000 et plus, et d’ouvrir un minimum de 15 à 20
ports.
10. Suivez les étapes 6 à 9 pour ajouter une autre clé Pour Internet, en utilisant les valeurs suivantes :
Valeur : PortsInternetAvailable
Type de données : REG_SZ
Données : Y
Cette valeur signifie que les ports répertoriés sous la valeur Ports doivent être mis à disposition sur
Internet.
11. Suivez les étapes 6 à 9 pour ajouter une autre clé Pour Internet, en utilisant les valeurs suivantes :
Valeur : UseInternetPorts
Type de données : REG_SZ
Données : Y
Cette valeur signifie que RPC doit attribuer dynamiquement des ports à partir de la liste des ports
Internet.
12. Configurez votre pare-feu pour autoriser l’accès entrant aux ports dynamiques spécifiés et pour le port
135 (port Depper du point de terminaison RPC).
13. Redémarrez l'ordinateur. Au redémarrage rpc, il affecte les ports entrants dynamiquement, en fonction
des valeurs de Registre que vous avez spécifiées. Par exemple, pour ouvrir les ports 5000 à 5020 inclus,
créez les valeurs nommées ci-après :
Ports : REG_MULTI-SZ : 5000-5020

PortsInternetAvailable : REG_SZ : Y
UseInternetPorts : REG_SZ : Y
DTC nécessite également que vous pouvez résoudre les noms d’ordinateurs par le moyen de NetBIOS ou DNS.
Testez si NetBIOS peut résoudre les noms à l’aide de ping et du nom du serveur. L’ordinateur client doit pouvoir
résoudre le nom du serveur. Et le serveur doit être en mesure de résoudre le nom du client. Si NetBIOS ne peut
pas résoudre les noms, ajoutez des entrées aux fichiers LMHOSTS sur les ordinateurs.
Comment activer l’accès DTC réseau
Cet article décrit les procédures que vous suivez pour activer l’accès DTC (Network Distributed Transaction
Coordinator).
Résumé
NOTE
La procédure suivante concerne Windows Server 2003. Il ne s’applique pas à Microsoft Windows 2000 Server.
Par défaut, l’accès DTC réseau est désactivé sur les produits Windows Server 2003 mentionnés dans la section «
S’applique à ». Lorsque l’accès DTC réseau n’est pas activé sur le serveur, les applications ne peuvent utiliser que
les transactions restant sur l’ordinateur local. Par exemple, il n’est pas possible de transmettre des transactions
d’un ordinateur local vers une base de données exécutée sur un ordinateur distinct si l’accès DTC réseau est
désactivé.
Lorsque l’accès DTC réseau est désactivé, les clients qui tentent d’accéder à DTC sur le serveur peuvent recevoir
le message d’erreur suivant :
0x8004D025 d’erreur (XACT_E_PARTNER_NETWORK_TX_DISABLED)
Étapes pour activer l’accès DTC réseau
1. Cliquez sur Démarrer , pointez sur Panneau de configuration , puis cliquez sur Ajouter ou supprimer
des programmes .
2. Cliquez sur Ajouter/Supprimer des composants Windows .
3. Sélectionnez Application Ser ver , puis cliquez sur Détails .
4. Sélectionnez Activer l’accès DTC réseau , puis cliquez sur OK .
6. Cliquez sur Terminer .
Si vous exécutez Windows Server 2003 Service Pack 1 (SP1), vous devez suivre ces étapes supplémentaires :
1. Cliquez sur Démarrer , sur Exécuter , tapez comexp.msc, puis cliquez sur OK pour ouvrir Les services de
composants.
2. Développez Ser vices de composants , développez Ordinateurs , cliquez avec le bouton droit sur
Mon ordinateur , puis cliquez sur Propriétés .
3. Sous l’onglet MSDTC , cliquez sur Configuration de la sécurité sous Configuration des
transactions , cliquez pour cocher la case Accès DTC réseau sous Sécurité Paramètres , puis cliquez
pour cocher les cases suivantes sous Communication du Gestionnaire de transactions :
Autoriser le trafic entrant
Autoriser le trafic sor tant
4. Sur les clusters Microsoft Cluster Server (MSCS), vous ne pouvez pas sélectionner l’authentification
mutuelle requise . Par conséquent, cliquez pour sélectionner l’une des cases à cocher suivantes :
Authentification de l’appelant entrant requise
Aucune authentification requise
NOTE
Pour plus d’informations sur ces options, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base
de connaissances Microsoft :
899191 de nouvelles fonctionnalités dans le service Distributed Transaction Coordinator dans Windows Server
2003 Service Pack 1 et dans Windows XP Service Pack 2
5. Assurez-vous que le compte d’ouver ture de session est défini sur NTAUTHORITY\NetworkService.
6. Cliquez sur OK . Une boîte de message explique que le service MS DTC sera arrêté et redémarré, et que
tous les services dépendants seront également arrêtés et redémarrés. Cliquez sur Oui .
NOTE
S’il s’agit d’un cluster MNS (Majority Node Set), n’utilisez pas la ressource MNS comme périphérique de stockage
pour MS DTC. MS DTC nécessite une ressource de stockage telle qu’un disque physique.
References
Pour plus d’informations sur les nouveautés de Microsoft COM+ 1.5, visitez le site web Microsoft Developer
Network (MSDN) suivant :
Nouveautés de COM+ 1.5
Comment reconstruire ou déplacer une installation
MSDTC à utiliser avec un cluster de SQL de travail
Cet article explique comment reconstruire une installation MSDTC (Microsoft Distributed Transaction
Coordinator) rompue pour une utilisation avec une installation en cluster de SQL Server’installation.
Résumé
Le blog suivant présente des informations détaillées sur les modifications apportées au comportement MSDTC
depuis la publication de Windows Server 2008.
MSDTC Recommandations sur SQL cluster de failover
L’objectif des questions fréquemment posées ci-après est de répondre aux questions courantes avec MSDTC
lorsqu’elles sont utilisées avec les instances clustered de SQL Server de failover afin d’inclure les
recommandations actuelles et les meilleures pratiques.
MSDTC est un gestionnaire de transactions qui permet aux applications clientes d’inclure plusieurs sources de
données différentes dans une transaction et qui coordonne ensuite la validation de la transaction distribuée sur
tous les serveurs qui sont inscrits dans la transaction. Cela permet de s’assurer que la transaction est engagée, si
chaque partie de la transaction réussit ou est retentra, en cas d’échec d’une partie du processus de transaction.
De nombreuses personnes se demandent pourquoi nous devons installer MSDTC avant d’installer SQL Server.
Cette opération n’est plus nécessaire. Il s’agissait d’une condition requise SQL Server 2005. Cette version de SQL
Server a terminé son cycle de vie et a donc mis fin à la nécessité d’installer SQL Server.
Lors du déploiement de SQL Server dans un environnement hautement disponible comme le clustering de
Windows failover, certaines meilleures pratiques peuvent rendre le comportement des services MSDTC plus
prévisible.
Lorsque le sujet de la prise en charge des transactions entre bases de données et/ou DTC, sous un groupe
de disponibilité, est abordé, la réponse rapide n’est PAS PRISE EN CHARGE ! .
Il s’agit d’une affirmation vraie et la conversation a tendance à se concentrer sur cette question, mais
pourquoi ? En fait, certaines DBA ont testé différentes formes de ces types de transactions et n’ont pas
rencontré d’erreurs.
Le problème est que le test n’est pas terminé et que l’activité de validation en deux phases requise peut
entraîner une perte de données ou une base de données qui ne récupère pas comme prévu dans
certaines configurations. En fait, les testeurs SQL Server injectent des échecs à des emplacements
stratégiques pour créer des scénarios difficiles (mais pas impossibles) à créer sur un serveur de
production. Pour plus d’informations, voir Not-Supported: AGs with TC/Cross-Database Transaction.
Avec Windows 2008 et les ultérieures, vous n’avez pas besoin de cluster MSDTC pour utiliser les fonctionnalités
du service MSDTC, car MSDTC a été re-conçu dans Windows 2008. Contrairement Windows 2003, si vous
installez Windows cluster de failover, vous deviez regrouper MSDTC. Ce n’est plus le cas lors de l’utilisation de
Windows 2008, car par défaut le service MSDTC est en cours d’exécution localement, même avec le clustering de
failover installé.
Si votre instance de cluster de SQL Server de failover nécessite MSDTC et exige que les ressources MSDTC
échouent avec l’instance SQL Server, nous vous recommandons de créer une ressource MSDTC dans le rôle
FailoverCluster qui contient l’instance SQL Server et qu’elle utilise :
Point d SQL Server d’accès client du nom \ de réseau
Un disque dans le rôle SQL Server de l’ordinateur
Nommez la ressource MSDTC avec le nom SQL serveur virtuel.
Configurer et tester une nouvelle ressource de cluster MSDTC à l’aide

de PowerShell
1. Créez une ressource MSDTC remplaçant le contenu entre les sections <> suivantes, puis exécutez-la.
$SqlRole = <Actual name of the role containing the SQL Server instance>
$SqlNetName = <Actual SQL Servernetwork resourcename>
$VSqlSrv = <Actual SQL Server virtual server name>
$CluDsk = <Actual disk resource name>
Si la ressource MSDTC n’a pas accepté le nom fourni, vous pouvez modifier le nom à l’aide de PowerShell
suivant en remplaçant le New Distributed Transaction Coordinator par RealSqlVsName :
Get-ClusterResource "New Distributed Transaction Coordinator" | %{$_.Name = RealSqlVsName }
Vous pouvez remplacer $VSqlSrv RealSqlVsName s’il est toujours actif.

2. Vérifiez les règles de pare-feu à l’aide du script suivant :
Set-NetFirewallRule -Name 'RPC Endpoint Mapper' -Enabled True

Set-NetFirewallRule -Name 'DTC incoming connections' -Enabled True
Set-NetFirewallRule -Name 'DTC outgoing connections' -Enabled True
3. Définissez l’authentification réseau MSDTC à l’aide du script suivant :
Set-DtcNetworkSetting -AuthenticationLevel Mutual `

-DtcName "Local" -InboundTransactionsEnabled $True `
-LUTransactionsEnabled $True `
-OutboundTransactionsEnabled $True `
-RemoteAdministrationAccessEnabled $False `
-RemoteClientAccessEnabled $False `
-XATransactionsEnabled $True -verbose
4. Vérifiez que la nouvelle ressource MSDTC est désormais répertoriée à l’aide de la commande suivante :
Get-Dtc -Verbose |Sort-Object DtcName
5. Testez la nouvelle ressource MSDTC.
Test-Dtc -LocalComputerName RealSqlVsName -Verbose
Vous pouvez remplacer $VSqlSrv RealSqlVsName s’il est toujours actif. À $Env:COMPUTERNAME utiliser pour
tester l’installation locale. Vous devez exécuter les règles de pare-feu et les commandes PowerShell
d’authentification MSDTC sur tous les autres nodes de cluster existants.
6. Testez MSDTC.
Dans cet exemple, nous allons utiliser la base de données AdventureWorks2012, vous devez remplacer
un nom de base de données réel que vous souhaitez tester. À partir d SQL Server fenêtre de requête,
exécutez l’instruction SQL suivante :
USE AdventureWorks2012;
GO
BEGIN DISTRIBUTED TRANSACTION;
-- Enter fake transaction to the database
INSERT SQL_Statement
DELETE SQL_Statement
COMMIT TRANSACTION
GO
Vous devez maintenant voir qu’une ligne est affectée et que l’enregistrement inséré n’existe pas.
Références
Paramètres MSDTC recommandés pour l’utilisation des transactions distribuées dans SQL Server
Comment résoudre les problèmes de connectivité
dans MS DTC à l’aide de l’outil DTCPing
Cet article explique comment résoudre les problèmes de connectivité dans Microsoft Distributed Transaction
Coordinator (MS DTC) à l’aide de l’outil DTCPing.
Introduction
À l’aide de l’outil DTCPing, vous pouvez tester la résolution des noms entre deux ordinateurs. Vous pouvez
également tester la communication d’appel de procédure distante (RPC) entre deux ordinateurs. En outre, vous
pouvez obtenir les informations suivantes à l’aide de l’outil DTCPing :
Paramètres de sécurité MS DTC.
Informations sur la plage de ports RPC.
Informations sur la clé de Registre MS DTC HKEY_CLASSES_ROOT\CID .
Télécharger des informations

Le fichier suivant est disponible en téléchargement à partir du Centre de téléchargement Microsoft :
Téléchargez le package Dtcping.exe'aide maintenant.
Pour plus d’informations sur le téléchargement des fichiers de support Microsoft, cliquez sur le numéro d’article
suivant pour afficher l’article dans la Base de connaissances Microsoft :
119591 Comment faire pour obtenir des fichiers de support technique Microsoft auprès des services en ligne
Fichiers que le package Dtcping.exe contient

L A TA IL L E DES
N O M DE F IC H IER VERSIO N DU F IC H IER F IC H IERS DAT E T EM P S
Dtcping.exe 1.9.0.1 266,308 29-Jul-2005 00:54
Dtcping.pdb Non applicable 1,000,448 29-Jul-2005 00:54
HowtoAnalyze_Dtcpi Non applicable 4,530 27-Jul-2005 15:38

ng_Output.txt
Machinea_failure.log Non applicable 1,560 24-Nov-2003 22:59
Machinea_success.log Non applicable 1,901 24-Nov-2003 22:21

L A TA IL L E DES
N O M DE F IC H IER VERSIO N DU F IC H IER F IC H IERS DAT E T EM P S
Machineb_failure.log Non applicable 999 24-Nov-2003 22:55
Machineb_success.lo Non applicable 1,750 24-Nov-2003 22:31

g
Readme.txt Non applicable 3,244 27-Jul-2005 15:32
Informations de dépannage
Le package Dtcping.exe inclut les fichiers texte suivants qui décrivent comment utiliser l’outil DTCPing :
Consultez le Readme.txt pour plus d’informations sur le test de la communication RPC et de la
communication DTC MS entre deux ordinateurs.
Consultez le fichier HowtoAnalyze_Dtcping_Output.txt pour plus d’informations sur la façon d’obtenir des
informations sur le port RPC, des informations sur les clés de Registre CID et d’autres informations
relatives à MS DTC.
Description du suivi des événements d’arrêt
Cet article décrit le suivi des événements d’arrêt.

Résumé
Le suivi des événements d’arrêt est une fonctionnalité Microsoft Windows Server 2003 et Microsoft Windows
XP que vous pouvez utiliser pour suivre de manière cohérente la raison des arrêts du système. Vous pouvez
ensuite utiliser ces informations pour analyser les arrêts et développer une compréhension plus complète de
votre environnement système. Shutdown Event Tracker journals events that are similar to the following in the
system event log:
Windows Server 2003 et Windows XP Version 64 bits 2003
Par défaut, le suivi des événements d’arrêt est activé pour tous les systèmes d’exploitation Windows
Server 2003 et Windows XP Version 64 bits 2003.
Pour désactiver le suivi d’événement d’arrêt sur tous les systèmes d’exploitation Windows Server 2003 et
dans Windows XP Version 64 bits version 2003, désactivez la stratégie de suivi des événements d’arrêt
d’affichage à l’aide de la stratégie de groupe. Pour le faire à l’aide de la stratégie de groupe locale, suivez
2. Tapez gpedit.msc, puis sélectionnez OK .
3. Développez la configuration ordinateur, développez modèles d’administration, puis
développez Système.
4. Double-cliquez sur Suivi des événements d’arrêt de l’affichage.
5. Sélectionnez Désactivé, puis OK.
Par défaut, le suivi des événements d’arrêt est désactivé dans Windows XP Professional.
Pour activer le suivi d’événements d’arrêt dans Windows XP Professional, dans Windows XP Tablet PC
Edition et dans Windows XP Media Center Edition, activez la stratégie Display Shutdown Event Tracker à
l’aide de la stratégie de groupe. Pour le faire à l’aide de la stratégie de groupe locale, suivez les étapes
suivantes :
2. Tapez gpedit.msc, puis sélectionnez OK .
3. Développez la configuration ordinateur, développez modèles d’administration, puis
développez Système.
4. Double-cliquez sur Suivi des événements d’arrêt de l’affichage.
5. Sélectionnez Activé .
6. Dans la zone Suivi d’événements d’arrêt, sélectionnez Toujours, puis OK.
Le suivi des événements d’arrêt n’est pas un composant fonctionnel dans Windows XP Édition familiale.
Vous ne pouvez donc pas utiliser le suivi d’événements d’arrêt Windows XP Édition Familiale.
NOTE
Microsoft recommande de ne pas activer le suivi d’événements d’arrêt dans Windows XP Professional, Windows
XP Tablet PC ou Windows XP Media Center Editions. Microsoft ne prend pas en charge l’utilisation de ce
composant dans ces environnements Windows XP.
Options personnalisées pour identifier une cause d’arrêt

IMPORTANT
Windows .
Windows fournit une liste de huit raisons génériques pour lesquelles votre ordinateur a été arrêté. Vous pouvez
modifier cette liste pour inclure vos propres raisons personnalisées. Pour ajouter vos propres raisons, suivez les
étapes suivantes :
2. Recherchez, puis sélectionnez la clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Reliability\UserDefined
3. Dans le menu Édition, sélectionnez Nouveau, puis sélectionnez Valeur multi string . Ce qui crée la
clé et lui donne le nom temporaire « Nouvelle valeur ».
4. Tapez le nom de la clé de Registre au format suivant, puis appuyez sur Entrée : UI_control_flags ;
major_reason_number ; minor_reason_number
La UI_control_flags section du nom de la valeur peut contenir une ou plusieurs des valeurs suivantes :
P (Indique que la raison est planifiée. Si cette valeur est omise, la valeur par défaut n’est pas planifiée.)
C ou B (indique qu’un commentaire est requis.)
S (Indique que la raison doit être affichée dans la boîte de dialogue d’arrêt initiée par l’utilisateur.)
D (Indique que la raison doit être affichée dans la boîte de dialogue arrêt soudain.) Par exemple, si
vous souhaitez afficher une raison dans la boîte de dialogue arrêt soudain, l’arrêt n’est pas planifié et
l’arrêt correspond à une raison principale 2 et à une raison mineure 2, tapez le nom de la valeur
suivante : D;2;2
5. Double-cliquez sur la nouvelle clé, puis définissez les données de valeur au format suivant :
Titre
Description
Chaque valeur est composé de deux chaînes sur des lignes distinctes ; la première chaîne est le titre (elle
est affichée dans la liste) et la deuxième chaîne est la description (c’est le texte qui s’affiche après la raison
sélectionnée).
Par exemple, si vous souhaitez créer une raison personnalisée pour une catastrophe naturelle, vous
pouvez définir les données de valeur comme suit : Natural Disaster (non planifié)
Un débordement, un catastrophe, une catastrophe ou un autre événement naturel non planifié nécessite
que l’ordinateur s’arrête. Spécifiez l’événement naturel dans la zone de commentaire.
Remarques
Vous pouvez spécifier S et D pour UI_control_flags, mais vous devez spécifier au moins l’un d’eux pour que
les paramètres soient valides.
Si la section UI_control_flags contient des caractères autres que ceux répertoriés dans la section « Options
personnalisées pour identifier une cause d’arrêt » de cet article, ou si la section UI_control_flags dépasse
cinq caractères, le message n’est pas valide et n’est pas affiché dans l’interface utilisateur. Vous pouvez
spécifier que les caractères apparaissent dans n’importe quel ordre.
Le major_reason_number est un nombre entre 0 et 255. Si cette section est laissée vide, si elle contient un
nombre qui ne se trouve pas dans la plage valide ou si elle contient un nombre qui n’est pas un nombre
integer, le message n’est pas valide et n’est pas affiché dans l’interface utilisateur.
Le minor_reason_number est un nombre entre 0 et 65 536. Si cette section est laissée vide, si elle contient
un nombre qui ne se trouve pas dans la plage valide ou si elle contient un nombre qui n’est pas un nombre
integer, le message n’est pas valide et n’est pas affiché dans l’interface utilisateur.
Les raisons personnalisées sont triées dans l’interface utilisateur par deux clés dans l’ordre suivant :
MajorReasonNumber , MinorReasonNumber .
La longueur maximale du titre est de 64 caractères et la longueur maximale de la description est de 96
caractères.
Si vous définissez la clé de Registre suivante sur une valeur non nulle et que vous avez correctement défini
au moins une raison personnalisée, les raisons de l’Windows standard ne sont pas affichées dans la boîte de
dialogue Arrêter Windows :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability\ShutdownIgnorePredefinedReasons
Comment supprimer des fichiers journaux de
l’Observateur d’événements endommagés
Cet article décrit une méthode pour renommer ou déplacer ces fichiers à des fins de dépannage.
Symptômes
Lorsque vous lancez Windows’observateur d’événements, l’un des messages d’erreur suivants peut se produire
si l’un des fichiers *.evt est endommagé :
Le handle n’est pas valide
Dr Watson Services.exe
Exception : Violation d’accès (0xc0000005), Adresse : 0x76e073d4
Lorsque vous sélectionnez OK ou annulez le message d’erreur Dr Watson, vous pouvez également recevoir le
Observateur d'événements
Échec de l’appel de procédure distante
Le services.exe peut consommer un pourcentage élevé d’utilisation du processeur.
Cause
Les fichiers journaux de l’Observateur d’événements (Sysevent.evt, Appevent.evt, Secevent.evt) sont toujours
utilisés par le système, ce qui empêche la suppression ou le changement de nom des fichiers. Le service
EventLog ne peut pas être arrêté car il est requis par d’autres services, les fichiers sont donc toujours ouverts.
Résolution
IMPORTANT
restaurer en cas de problème. Pour plus d’informations, voir Comment faire pour la back up et restaurer le Registre dans
Windows
NTFS Partition
1. Sélectionnez le bouton Démarrer, pointez sur Paramètres, sélectionnez Panneau de contrôle, puis
double-cliquez sur Ser vices .
2. Sélectionnez le ser vice EventLog et le démarrage. Modifiez le type de démarrage sur Désactivé,
puis sélectionnez OK. Si vous ne parvenez pas à vous connectez à l’ordinateur mais que vous pouvez
accéder au Registre à distance, vous pouvez modifier la valeur de démarrage dans la clé de Registre
suivante en la 0x4 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog
3. Redémarrez Windows.
NOTE
Au démarrage du système, plusieurs services peuvent échouer . un message informant l’utilisateur d’utiliser
l’Observateur d’événements pour passer en revue les erreurs peut apparaître.
4. Renommons ou déplacez le fichier *.evt endommagé à partir de l’emplacement suivant :

%SystemRoot%\System32\Config
5. Dans l’outil Services du Panneau de configuration, ré-activez le service EventLog en le réamorçage par
défaut du démarrage automatique ou modifiez la valeur de démarrage du Registre en 0x2.
Partition FAT (méthode alternative)

1. Démarrez à une invite MS-DOS à l’aide d’un disque de démarrage DOS.
2. Renommons ou déplacez le fichier *.evt endommagé à partir de l’emplacement suivant :
%SystemRoot%\System32\Config
3. Supprimez le disque et redémarrez Windows.

Lorsque Windows est redémarré, le fichier journal des événements est recréé.
Guide pratique pour déplacer observateur
d'événements fichiers journaux vers un autre
emplacement
Cet article explique comment déplacer des fichiers journaux Windows Server 2016 et Windows Server 2019
observateur d'événements vers un autre emplacement sur le disque dur.
Résumé
Windows Server enregistre les événements dans les journaux suivants :
Journal des applications
Le journal des applications contient des événements qui sont enregistrés par les programmes. Les
événements écrits dans le journal des applications sont déterminés par les développeurs du programme
logiciel.
Journal de sécurité
Le journal de sécurité contient des événements tels que des tentatives d’ouverture de session valides et
non valides. Il contient également des événements liés à l’utilisation des ressources, par exemple, lorsque
vous créez, ouvrez ou supprimez des fichiers. Vous devez être connecté en tant qu’administrateur ou
membre du groupe Administrateurs pour activer, utiliser et spécifier les événements enregistrés dans le
journal de sécurité.
Journal système
Le journal système contient les événements consignés par les composants système Windows. Ces
événements sont prédéterminés par Windows.
Journal du service d’annuaire
Le journal du service d’annuaire contient des événements liés à Active Directory. Ce journal est disponible
uniquement sur les contrôleurs de domaine.
Journal du serveur DNS
Le journal du serveur DNS contient des événements liés à la résolution de noms DNS vers ou à partir
d’adresses IP (Internet Protocol). Ce journal est disponible uniquement sur les serveurs DNS.
Journal du service de réplication de fichiers
Le journal du service de réplication de fichiers contient les événements enregistrés pendant le processus
de réplication entre les contrôleurs de domaine. Ce journal est disponible uniquement sur les contrôleurs
de domaine.
Par défaut, observateur d'événements fichiers journaux utilisent l’extension .evt et se trouvent dans le dossier
%SystemRoot%\System32\winevt\Logs.
Le nom du fichier journal et les informations d’emplacement sont stockés dans le Registre. Vous pouvez
modifier ces informations pour modifier l’emplacement par défaut des fichiers journaux. Vous souhaiterez peut-
être déplacer les fichiers journaux vers un autre emplacement si vous avez besoin d’espace disque
supplémentaire pour journaliser les données.
Créer un dossier de journal des événements dans un autre

emplacement
Créez un dossier dans lequel vous souhaitez stocker les journaux des événements dans votre lecteur local et
attribuer les autorisations appropriées. Voici les étapes à effectuer :
1. Créez un dossier (par exemple, C:\EventLogs).
2. Cliquez avec le bouton droit sur le dossier, puis sélectionnez Propriétés .
3. Sélectionnez l’onglet Sécurité , puis Sélectionnez Avancé pour les autorisations spéciales ou les
paramètres avancés.
NOTE
L'« héritage » du dossier est activé par défaut.
4. Sélectionnez Modifier pour remplacer le propriétaire par SYSTEM, puis désactivez l’héritage comme
suit :
Vous serez invité à convertir ou supprimer les autorisations héritées. Sélectionnez Conver tir les
autorisations héritées en autorisations explicites sur cet objet , et vous verrez les mêmes
autorisations explicitement définies sur le dossier.
NOTE
Pour créer des sous-dossiers pour les journaux d’activité, vérifiez que toutes les entrées d’autorisation
d’objet enfant sont remplacées par des entrées d’autorisations héritées de cette option d’objet . Les
autorisations définies au niveau parent sont appliquées à tous les sous-dossiers et fichiers.
5. Ajustez les autorisations afin que le dossier reçoit les autorisations appropriées et vérifiez la colonne
S’applique à . Ces autorisations doivent être identiques aux autorisations avancées du dossier par
défaut (%SystemRoot%\System32\winevt Logs) qui stocke\ les journaux observateur d'événements.
Assurez-vous que les utilisateurs authentifiés disposent uniquement de l’autorisation lecture pour ce
dossier et sous-dossiers .
NOTE
Pour ajouter l’utilisateur EventLog , accédez à l’onglet Sécurité de la boîte de dialogue Propriétés et procédez
comme suit :
1. Sélectionnez Modifier > l’ajout .
2. Sélectionnez Emplacements , sélectionnez le nom de l’ordinateur local, puis sélectionnez OK .
3. Tapez NT SERVICE\EventLog dans Entrer les noms d’objets à sélectionner et à sélectionner Vérifier les
noms . Le nom doit être résolu en EventLog . Sélectionnez OK pour terminer.
Vérifiez que contrôle total est sélectionné sous Autorisations pour EventLog pour l’utilisateur EventLog .
Déplacer observateur d'événements fichiers journaux vers un autre

emplacement
Vous pouvez déplacer les fichiers journaux vers le dossier créé à l’aide de la obser vateur d'événements
comme suit :
1. Ouvrez le obser vateur d'événements .
2. Cliquez avec le bouton droit sur le nom du journal (par exemple, Système ) sous Journaux Windows
dans le volet gauche, puis sélectionnez Propriétés .
3. Remplacez la valeur du chemin d’accès du journal par l’emplacement du dossier créé et laissez le nom
du fichier journal à la fin du chemin d’accès (par exemple, C:\EventLogs\System.evtx).
4. Sélectionnez Effacer le journal , puis Enregistrer et effacer pour conserver les fichiers journaux des
événements dans un autre emplacement.
5. Sélectionnez Appliquer > OK .
NOTE
Vérifiez le dossier dans lequel vous avez déplacé les journaux des événements. Si les journaux des événements ne
se trouvent pas dans le dossier, redémarrez le système.
Vous pouvez vérifier que le chemin d’accès du journal a été mis à jour à l’aide de l’Éditeur du Registre. Par
exemple, accédez au chemin d’accès au Registre suivant et vérifiez les données de valeur de la valeur de
fichier .
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\System
Déplacer observateur d'événements fichiers journaux à l’aide de

PowerShell
Il est possible d’utiliser PowerShell à cet effet. Dans l’exemple, les journaux des événements de sécurité sont
migrés vers C:\Logs :
$originalFolder = "$env:SystemRoot\system32\winevt\Logs"
$targetFolder = "C:\logs\"
$logName = "Security"
$originalAcl = Get-Acl -Path $originalFolder -Audit -AllCentralAccessPolicies

Set-Acl -Path $targetFolder -AclObject $originalAcl -ClearCentralAccessPolicy
$targetAcl = Get-Acl -Path $targetFolder -Audit -AllCentralAccessPolicies
$targetAcl.SetOwner([System.Security.Principal.NTAccount]::new("SYSTEM"))
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\$logName" -Name "AutoBackupLogFiles" -

Value "1" -PropertyType "DWord"
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\$logName" -Name "Flags" -Value "1" -
PropertyType "DWord"
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\$logName" -Name "File" -Value
"$targetFolder\$logName.evtx"
References
Pour plus d’informations sur l’affichage et la gestion des journaux d’activité dans le observateur d'événements,
consultez Comment supprimer les fichiers journaux endommagés observateur d'événements. Pour en savoir
plus sur l’utilisation générale observateur d'événements, sélectionnez le menu Action dans observateur
d'événements, puis sélectionnez Aide .
Comment résoudre les problèmes d’altération
d’inscription aux mises à jour logicielles MSI
Cet article fournit une solution à un problème qui peut échouer lors de la réparation ou de la désinstallation de
certains produits après l’installation des mises à jour logicielles.
Symptômes
Après avoir installé les mises à jour logicielles, les réparations ou désinstallations de certains produits peuvent
échouer. Si la journalisation MSI est activée, les lignes suivantes sont trouvées dans le journal :
Impossible de trouver le correctif local « ». Recherchez-la à sa source.

...
MainEngineThread retourne 1612
Lorsque vous recherchez dans le Registre, il se peut que vous trouviez que l’inscription du cache de mise à jour
logicielle est manquante dans la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\<SID>\Patches\<SQUID>
Résolution
IMPORTANT
restaurer en cas de problème.

1. Confirmez que le produit est affecté.
Pour ce faire, suivez les étapes suivantes :
a. Recherchez l’inscription de mise à jour logicielle du produit en ouvrant la sous-clé de Registre
suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\<SID>\Products\
<ProductSQUID>\Patches
Sous cette sous-clé, il y aura une sous-clé pour chaque mise à jour logicielle qui a été appliquée au
produit.
b. Pour chaque sous-clé au format suivant, effectuez l’étape suivante :
<ProductSQUID>\Patches\<PatchSQUID>
Vérifiez que la sous-clé suivante existe :

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\<SID>\Patches\
<PatchSQUID>
Si la sous-clé est manquante, le produit est affecté. Continuez à l’étape 2.

Si la sous-clé existe, vérifiez que la valeur de chaîne LocalPackage est définie correctement et que
le package référencé par la valeur de chaîne LocalPackage existe également.
a. Si la valeur de chaîne LocalPackage ou le package référencé est manquant, le produit est
affecté. Continuez à l’étape 2.
b. Si le package référencé existe et qu’aucune action supplémentaire n’est requise.
2. Re-créez les détails du Registre du cache de mise à jour logicielle. Pour cela, procédez comme suit :
a. Recherchez la mise à jour logicielle que vous avez essayé d’installer dans le %windir%\installer \
*.msp. Vérifiez que la mise à jour logicielle possède le GUID (Globally Unique Identifier) correct
dans le flux d’informations récapitulatifs et cible les GUID de produit corrects.
NOTE
Étant donné que ce répertoire sert de cache pour les installations par utilisateur et par ordinateur, vous
pouvez simuler une mise à jour logicielle dans ce répertoire à l’aide d’une installation par utilisateur.
b. Créez la sous-clé suivante :

<PatchSQUID>
NOTE
Il s’agit d’un risque pour la sécurité de la re-création du Registre du cache de mise à jour logicielle.
Toutefois, il s’agit de la seule façon de réparer l’altération. Vous pouvez réduire les risques de sécurité en
vous assurez que la mise à jour logicielle est la mise à jour logicielle correcte. Pour ce faire, vérifiez la liste
de contrôle de la mise à jour logicielle.
c. Créez une valeur de chaîne LocalPackage dans la sous-clé de Registre que vous avez créée à
l’étape 2. Assurez-vous que la valeur de chaîne LocalPackage est définie sur le chemin d’accès de la
mise à jour logicielle.
3. Supprimez les références de mise à jour logicielle restantes. Pour ce faire, suivez les étapes suivantes :
a. Ouvrez la sous-clé suivante, puis supprimez de la valeur <PatchSQUID> multi-sz « AllPatches » :
<ProductSQUID>\Patches
b. Supprimez la sous-clé de Registre suivante :

<ProductSQUID>\Patches\<PatchSQUID>
c. Supprimez la sous-clé de Registre suivante :

<PatchSQUID>
NOTE
Si cette sous-clé est manquante, ignorez cette étape.
d. Si le produit a été installé par ordinateur, suivez les étapes suivantes :

a. Ouvrez la sous-clé suivante :
HKEY_LOCAL_MACHINE\Software\Classes\Installer\Products\<ProductSQUID>\Patches
a. Si la <PatchSQUID> valeur de chaîne est présente, supprimez-la.

b. Si la valeur de chaîne est présente dans la valeur <PatchSQUID> Multi-sz « Patches »,
supprimez <PatchSQUID> la valeur de chaîne.
b. Si la sous-clé de Registre suivante est présente, supprimez-la :
HKEY_LOCAL_MACHINE\Software\Classes\Installer\Patches\<PatchSQUID>
e. Si le produit a été installé par utilisateur sans gestion :

a. Ouvrez la sous-clé de Registre suivante :
HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\<ProductSQUID>\Patches

b. Si la valeur Multi-sz « Patches » est <PatchSQUID> présente, supprimez-la.
HKEY_CURRENT_USER\Software\Microsoft\Installer\Patches\<PatchSQUID>
f. Si le produit a été installé par utilisateur géré :

a. Ouvrez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Managed\
<SID>\Installer\Products\<ProductSQUID>\Patches

b. Si la valeur Multi-sz « Patches » est <PatchSQUID> présente, supprimez-la.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Managed\
<SID>\Installer\Patches\<PatchSQUID>
Références
Cet article n’est pas spécifique aux problèmes survenus par Windows Update ou Microsoft Update.
Erreur 1603 quand vous essayez d’installer un
package Windows Installer : Une erreur
irrécupérable s’est produite lors de l’installation
Cet article vous aide à corriger l’erreur 1603 qui se produit quand vous installez un package Microsoft Windows
Installer.
Applicabilité : Windows 10 - Toutes les éditions
Symptômes
Quand vous essayez d’installer un package Windows Installer, le message d’erreur ci-dessous peut s’afficher :
Erreur 1603 : Une erreur irrécupérable s’est produite lors de l’installation.
Si vous cliquez sur OK dans la zone de message, l’installation est annulée.
Cause
Ce message d’erreur peut s’afficher si l’une des conditions suivantes est remplie :
Windows Installer tente d’installer une application déjà installée sur votre PC.
Le dossier dans lequel vous essayez d’installer le package Windows Installer est chiffré.
Le lecteur qui contient le dossier dans lequel vous essayez d’installer le package Windows Installer est
accessible en tant que lecteur de substitution.
Le compte SYSTÈME ne dispose pas des autorisations Contrôle total pour le dossier dans lequel vous essayez
d’installer le package Windows Installer. Le message d’erreur s’affiche, car le service Windows Installer utilise
le compte SYSTÈME pour installer le logiciel.
Résolution
Pour résoudre ce problème, appliquez l’une des méthodes ci-dessous en fonction de la cause du problème :
Vérifiez si l’application est déjà installée sur le PC. Si c’est le cas, désinstallez puis réinstallez l’application
concernée.
Si vous aviez précédemment un raccourci sur le Bureau pour une application, il se peut que ce raccourci
ait été perdu pendant la mise à niveau vers Windows 10. Dans ce cas, l’application est probablement
toujours installée sur le PC, ce qui entraîne cette erreur quand vous essayez de réinstaller l’application.
Pour restaurer le raccourci, recherchez l’application et, si elle est trouvée, appuyez longuement (ou cliquez
avec le bouton droit) sur l’application, puis sélectionnez Épingler à l’écran de démarrage . Vous pouvez
également résoudre le problème en désinstallant puis en réinstallant l’application. Pour rechercher et
désinstaller une application dans Windows 10 :
1. Dans le menu Démarrer , sélectionnez Paramètres .
2. Dans Paramètres , sélectionnez Système > Applications et fonctionnalités .
3. Si l’application est répertoriée, sélectionnez-la, puis sélectionnez Désinstaller .
4. Suivez les instructions affichées à l’écran.
Installez le package dans un dossier qui n’est pas chiffré.
Utilisez cette méthode si le message d’erreur s’affiche, car vous essayez d’installer le package Windows
Installer dans un dossier chiffré.
Installez le package sur un lecteur qui n’est pas accessible en tant que lecteur de substitution.
Utilisez cette méthode si le message d’erreur s’affiche, car le lecteur qui contient le dossier dans lequel
vous essayez d’installer le package Windows Installer est accessible en tant que lecteur de substitution.
Accordez les autorisations Contrôle total au compte SYSTÈME.
Utilisez cette méthode si le message d’erreur s’affiche, car le compte SYSTÈME ne dispose pas des
autorisations Contrôle total pour le dossier dans lequel vous installez le package Windows Installer.
Pour accorder les autorisations Contrôle total au compte SYSTÈME, procédez comme suit :
1. Ouvrez l’Explorateur de fichiers (ou l’Explorateur Windows), cliquez avec le bouton droit sur le
lecteur sur lequel vous souhaitez installer le package Windows Installer, puis cliquez sur
Propriétés .
2. Cliquez sur l’onglet Sécurité . Vérifiez que la zone Noms de groupes ou d’utilisateurs contient
le compte d’utilisateur SYSTÈME. Si le compte d’utilisateur SYSTÈME n’est pas répertorié dans la
zone, procédez comme suit pour l’ajouter :
a. Cliquez sur Modifier . Si vous y êtes invité, approuvez le contrôle de compte d’utilisateur.
b. Cliquez sur Ajouter . La boîte de dialogue Sélectionnez des utilisateurs ou des groupes
s’affiche.
c. Dans le champ Entrez les noms des objets à sélectionner , tapez SYSTÈME , puis cliquez
sur Vérifier les noms .
d. Cliquez sur OK .
3. Pour modifier les autorisations, cliquez sur Modifier . Si vous y êtes invité, approuvez le contrôle
de compte d’utilisateur.
4. Sélectionnez le compte d’utilisateur SYSTÈME et vérifiez, dans la section Autorisations que la
case Autoriser est activée pour Contrôle total. Si ce n’est pas le cas, activez-la .
5. Fermez la boîte de dialogue Autorisations pour revenir à la boîte de dialogue Propriétés .
Cliquez sur Avancé .
6. Sélectionnez Modifier les autorisations . Si vous y êtes invité, approuvez le contrôle de compte
d’utilisateur.
7. Dans l’onglet Autorisations , sélectionnez l’entrée SYSTÈME , puis cliquez sur Modifier .
8. Cliquez sur la liste déroulante S’applique à , puis sélectionnez Ce dossier, les sous-dossiers et
les fichiers . Cliquez sur OK .
9. Attendez que le système d’exploitation applique les autorisations sélectionnées à tous les dossiers
enfants.
10. Exécutez le package Windows Installer.
Application des paramètres des options régionales
et linguistiques Windows Server 2003
Cet article décrit les paramètres spécifiques à l’utilisateur et à l’échelle de l’ordinateur dans les options
régionales et linguistiques du Panneau de configuration, les implications de la configuration des options
régionales et linguistiques lors de l’installation de Windows et les effets sur le serveur Terminal Server Window
Server 2003.
Introduction
Cet article décrit comment les paramètres des options régionales et linguistiques de Windows Server 2003
sont appliqués. Certains paramètres varient d’un profil utilisateur à l’autre. Les autres paramètres sont à l’échelle
de l’ordinateur. Cet article traite également des effets de la configuration des paramètres Des options
régionales et linguistiques pendant Windows configuration.
Paramètres des options régionales

Les paramètres Des options régionales et linguistiques se trouvent dans le Panneau de configuration sur un
ordinateur Windows Server 2003.
L’onglet Options régionales contient les paramètres suivants :
Normes et formats
Ces paramètres sont spécifiques à l’utilisateur et sont stockés dans le cadre du profil utilisateur.
Location
Il s’agit d’un paramètre spécifique à l’utilisateur et stocké dans le cadre du profil utilisateur.
Paramètres de langue
L’onglet Langues contient les paramètres suivants :
Langue d’entrée par défaut
Il s’agit d’un paramètre spécifique à l’utilisateur et stocké dans le cadre du profil utilisateur.
Ser vices installés
Il s’agit d’un paramètre à l’échelle de l’ordinateur.
NOTE
Pour accéder à ces paramètres de langue, cliquez sur Détails dans les ser vices de texte et les langues d’entrée.
Paramètres avancés
L’onglet Avancé contient les paramètres suivants :
Langue pour les programmes non Unicode
Il s’agit d’un paramètre à l’échelle de l’ordinateur.
Paramètres de compte d’utilisateur par défaut
Cliquez pour sélectionner la case à cocher Appliquer tous les paramètres au compte d’utilisateur actuel et à
la case à cocher de profil utilisateur par défaut pour appliquer les modifications au profil utilisateur par
défaut.
Configurer les options régionales et linguistiques lors de l Windows

configuration
Vous êtes invité à configurer les options régionales et linguistiques pendant Windows configuration. Les
paramètres à l’échelle de l’ordinateur affectent tous les utilisateurs qui se connectent au système. Les
paramètres spécifiques à l’utilisateur affectent uniquement le profil utilisateur par défaut. Les nouveaux profils
utilisateur héritent des paramètres spécifiques à l’utilisateur que vous avez spécifiés lors de l’installation.
Vous pouvez modifier les paramètres spécifiques de l’utilisateur pour le profil utilisateur par défaut en
sélectionnant Appliquer tous les paramètres au compte d’utilisateur actuel et à la case à cocher de profil
utilisateur par défaut sous l’onglet Avancé.
Considérations pour Windows Server 2003 Terminal Server

IMPORTANT
La première fois qu’un utilisateur utilise une connexion Bureau à distance pour se connecter à un serveur sur
qui Terminal Server est activé, un nouveau profil est créé. Le nouveau profil hérite des paramètres Des options
régionales et linguistiques du profil utilisateur par défaut. Le profil peut être local sur le serveur Terminal Server
ou résider sur un partage réseau. Toutefois, le paramètre de langue d’entrée par défaut est obtenu à partir de
l’ordinateur client à l’origine de la connexion Bureau à distance.
Pour modifier le comportement par défaut afin d’obtenir le paramètre de langue d’entrée par défaut à partir du
profil utilisateur par défaut, vous devez définir une valeur d’entrée de Registre sur le serveur Terminal Server.
1. Sur le serveur Terminal Server, cliquez sur Démarrer > l’exécuter, tapez regedit, puis cliquez sur OK .
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
3. Dans le menu Modifier, cliquez sur Ajouter une valeur, puis ajoutez les informations de Registre
suivantes :
Nom de la valeur : IgnoreRemoteKeyboardLayout
Lorsque l’entrée IgnoreRemoteKeyboardLayout est définie sur 1, les nouveaux profils utilisateur héritent du
paramètre de langue d’entrée par défaut du profil utilisateur par défaut utilisé par le compte d’utilisateur.
NOTE
Cette entrée de Registre peut ne pas fonctionner si vous n’exécutez pas Windows Server 2003 Service Pack 1.
Profils utilisateur existants

Si un profil utilisateur existe déjà, les paramètres Des options régionales et linguistiques du profil utilisateur
existant sont appliqués aux nouveaux utilisateurs.
L’écoute HTTP ne parvient pas à s’initialiser lors de
l’échec de SeChangeNotifyPrivilege
Cet article fournit une solution à un problème que l’écoute HTTP ne parvient pas à initialiser lorsque l’utilisateur
ne dispose pas de SeChangeNotifyPrivilege.
Symptômes
Lors de l’initialisation d’un nouveau listener HTTP à l’aide de la fonction ou de la classe .NET, l’opération échoue
et vous recevez HttpInitialize HttpListener ce message d’erreur :
HttpInitialize a échoué avec 5 ( -accès refusé)
Cause
Ce problème se produit lorsque le compte exécutant le code ne dispose pas du privilège
SeChangeNotifyPrivilege.
Accordez au contournement le droit de l’utilisateur de vérification du contournement sur le compte approprié.
Ce privilège est accordé au groupe Tout le monde par défaut.
Comment exécuter un script d’connexion une fois
lorsqu’un nouvel utilisateur se connecte dans
Windows Server 2003
Cet article explique comment configurer un script ou un programme d’accès pour qu’il s’exécute une seule fois
lorsqu’un utilisateur se signe à un ordinateur pour la première fois.
Résumé
IMPORTANT
façon de restaurer, de restaurer et de modifier le Registre, voir Windows registre pour les utilisateurs avancés.
Ces étapes s’appliquent uniquement aux nouveaux utilisateurs qui ne se sont jamais connectés à l’ordinateur. Si
un utilisateur dispose déjà d’un profil utilisateur local ou d’un profil itinérant, le script ou le programme ne
s’exécute pas.
Configurer un script pour qu’il s’exécute une seule fois lorsqu’un

nouvel utilisateur se signe
WARNING
Lorsqu’un Windows Server 2003 est installé, le profil utilisateur par défaut est créé. La première fois qu’un
utilisateur se connecte, le profil utilisateur par défaut est copié dans le profil de l’utilisateur.
Pour configurer un script ou un programme à exécuter lorsqu’un nouvel utilisateur se connecte, suivez les
étapes suivantes :
2. Dans la zone Ouvrir, tapez regedit.exe, puis sélectionnez OK.
HKEY_USERS
4. Dans le menu Fichier, sélectionnez Charger la ruche.
5. Dans la boîte de dialogue Charger la ruche, recherchez le fichier Profilepath \Default User\Ntuser.dat,
où Profilepath est l’emplacement du système de fichiers du profil utilisateur par défaut. Sélectionnez
Ouvrir .
6. Dans la boîte de dialogue Charger la ruche, tapez un nom pour la ruche, puis sélectionnez OK.
NOTE
Le fichier Ntuser.dat est masqué. Si vous ne pouvez pas localiser ou charger le fichier Ntuser.dat, vous devez
modifier vos paramètres d’affichage dans Windows Explorer. Pour ce faire, suivez les étapes suivantes :
a. Sélectionnez Démarrer, puis sélectionnez Windows Explorer.

b. Sélectionnez Outils, puis Options de dossier.
c. Sélectionnez l’onglet Affichage.
d. Cliquez pour effacer la case à cocher Masquer les extensions pour les types de fichiers connus.
e. Sélectionnez Afficher les fichiers et dossiers masqués, puis sélectionnez OK.
HKEY_USERS\Test\Software\Microsoft\Windows\CurrentVersion\Runonce
NOTE
Où Test est le nom que vous avez donné à la ruche Ntuser.dat à l’étape 6.
8. Dans le menu Edition, pointez sur Nouveau, puis sélectionnez Valeur de chaîne.
9. Dans le volet droit, double-cliquez sur la nouvelle valeur.
10. Dans la boîte de dialogue Modifier la chaîne, tapez le chemin d’accès complet et le nom de fichier
pour le script de programme ou d’accès, puis sélectionnez OK.
11. Dans le volet gauche, sélectionnez la ruche Test.
12. Dans le menu Fichier, sélectionnez Unload Hive .
13. Sélectionnez Oui lorsque vous êtes invité à confirmer que vous souhaitez décharger la ruche.
14. Quittez l’Éditeur du Registre. Ce script de programme ou d’logo s’exécute pour un utilisateur qui n’a pas
de profil utilisateur. Pour afficher les profils utilisateur sur l’ordinateur local, suivez les étapes suivantes :
a. Sélectionnez Démarrer, pointez sur le Panneau de contrôle, puis sélectionnez Système.
b. Sélectionnez l’onglet Avancé .
c. Dans la zone Profils utilisateur, sélectionnez Paramètres .
Les profils utilisateur sont répertoriés dans la boîte de dialogue Profils utilisateur.
Documentation de dépannage Stockage et de
sauvegarde pour Windows Server
problèmes liés à la sauvegarde et à la Stockage de secours. Les rubriques sont divisées en sous-catégories.
Parcourez le contenu ou utilisez la fonctionnalité de recherche pour rechercher du contenu pertinent.
Sauvegarder et Stockage sous-catégories

Sauvegarde et restauration Active Directory, ou récupération d’urgence
Configuration et utilisation du logiciel de sauvegarde
Altération des données et erreurs de disque
Déduplication
Gestionnaire de ressources du serveur de fichiers (FSRM)
iSCSI
E/S multipath (MPIO) et Storport
Gestion des volumes et des partitions
Stockage matériel
Espaces de stockage
Restauration ou réinitialisation de votre ordinateur
Service VSS
Durée de vie utile d’une sauvegarde d’état système
Cet article décrit la durée de vie utile d’une sauvegarde d’état système d’Active Directory (AD).
S’applique à : Windows Server 2003, Windows 2000, Windows XP
Résumé
Sauvegarde Windows, l’outil de sauvegarde inclus avec Windows Server 2003 et Windows 2000, peut
sauvegarder et restaurer Active Directory sur les contrôleurs de domaine Windows Server 2003 ou Windows
2000. Ces sauvegardes peuvent être effectuées lorsque le contrôleur de domaine est en ligne. Vous pouvez
restaurer ces sauvegardes uniquement lorsque le contrôleur de domaine est démarré en mode restauration des
services d’annuaire à l’aide de la touche F8 au démarrage du serveur.
Si une restauration non facultative est effectuée à l’aide de la sauvegarde, le contrôleur de domaine contiendra
les paramètres et les entrées qui existaient dans le domaine, le schéma, la configuration et éventuellement les
contextes d’attribution de noms de catalogue global lors de l’opération de sauvegarde. La synchronisation
partielle (réplication) à partir d’autres réplicas au sein de l’entreprise met ensuite à jour tous les contextes
d’attribution de noms hébergés sur le contrôleur de domaine, en aritant les données restaurées.
Windows Server 2003 et Windows 2000 n’autorisent pas la restauration d’anciennes images de sauvegarde
dans une entreprise répliquée. Plus précisément, la durée de vie utile d’une sauvegarde est identique au
paramètre « durée de vie de tombstone » pour l’entreprise. La valeur par défaut de l’entrée de durée de vie de
tombstone est 60 jours. Cette valeur peut être définie sur l’objet de config du service d’annuaire (NTDS).
Si votre seule sauvegarde d’Active Directory est plus ancienne que le paramètre de durée de vie de tombstone,
réinstallez le serveur après avoir confirmé qu’il existe au moins un contrôleur de domaine survivant dans le
domaine à partir duquel les nouveaux réplicas peuvent être synchronisés. Vous pouvez perdre tous les serveurs
sauf un dans le domaine et tout de même récupérer sans perte de données, en supposant que le reste contient
les informations actuelles.
Si chaque serveur du domaine est détruit lorsque vous utilisez le serveur dans une forêt de contrôleurs de
domaine unique ou dans un domaine unique qui contient plusieurs contrôleurs de domaine, restituez un
serveur à partir d’une sauvegarde arbitrairement obsolète. Ensuite, répliquez tous les autres serveurs à partir du
serveur restauré. Toutefois, vous ne pouvez pas restaurer le serveur lorsque vous utilisez le serveur dans une
forêt à plusieurs domaines. Dans ce scénario, les informations écrites dans Active Directory après la sauvegarde
obsolète ne sont pas disponibles.
L’attribut de durée de vie tombstone se trouve sur l’objet de config DS à l’échelle de l’entreprise. The path for this
attribute is:CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=COMPANY,DC=COM
Utilisez l’outil d’édition Active Directory de votre choix pour que l’attribut « tombstoneLifetime » soit plus ancien
que la sauvegarde utilisée pour restaurer Active Directory. Les outils pris en charge incluent adsiedit.msc,
Ldp.exe et les scripts ADSI (Active Directory Service Interfaces).
NOTE
Ces informations supposent que la sauvegarde n’est pas plus ancienne que le paramètre « tombstoneLifetime » par
défaut. Dans le cas contraire, les objets ont déjà été supprimés de la base de données. Dans ce cas, une restauration
faisant autorité peut être la meilleure solution s’il existe plusieurs contrôleurs de domaine.
L’attribut « tombstoneLifetime » représente le nombre de jours pendant lesquels une sauvegarde d’Active
Directory peut être utilisée en plus de la fréquence à laquelle les routines de nettoyage de la garbage collection
(suppression des éléments précédemment marqués pour suppression) sont exécutés. Pour plus d’informations
sur le garbage collection, voir le processus de collecte de la garbage de base de données Active Directory et le
calcul des intervalles autorisés.
Modifications apportées à l’attribut de durée de vie de tombstone

dans Windows Server 2003 Service Pack 1
La valeur de durée de vie de tombstone par défaut s’est parfois montrée trop courte. Par exemple, les
contrôleurs de domaine pré-organisés sont parfois en transit vers leur destination finale pendant plus de 60
jours. Les administrateurs n’activent pas régulièrement les contrôleurs de domaine hors connexion ou ne
résolvent pas les échecs de réplication pendant une durée de vie plus longue que le nombre de jours spécifié
par l’attribut de durée de vie de tombstone par défaut. Windows Server 2003 Service Pack 1 (SP1) augmente la
valeur d’attribut de 60 à 180 jours dans les scénarios suivants :
Vous utilisez le support Windows Server 2003 SP1 pour mettre à niveau un domaine NT 4.0 Windows vers
un domaine Windows Server 2003. Lorsque vous effectuez la mise à niveau, vous créez une forêt.
Vous faites la promotion d’un ordinateur exécutant Windows Server 2003 SP1 vers un contrôleur de
domaine. Lorsque vous faites la promotion du contrôleur de domaine, vous créez une forêt.
La version commerciale d’origine de Windows Server 2003 SP1 ne modifie pas la valeur de l’attribut de durée
de vie de tombstone lorsque les conditions suivantes sont vraies :
Vous pouvez mettre à niveau un domaine Windows 2000 vers un domaine Windows Server 2003 à l’aide du
support Windows Server 2003 SP1.
Vous installez Windows Server 2003 SP1 sur les contrôleurs de domaine qui exécutent la version d’origine
de Windows Server 2003.
L’augmentation de l’attribut de durée de vie tombstone d’un domaine à 180 jours augmente les éléments
suivants :
Durée de vie utile des sauvegardes utilisées pour les scénarios de récupération de données.
Durée de vie utile des sauvegardes d’état système utilisées pour les promotions à l’aide de la fonctionnalité
Installer à partir du média.
Heure à cause de la mise hors connexion des contrôleurs de domaine. (Les ordinateurs qui sont créés dans
un site de transit et expédiés vers des sites de destination approchent fréquemment l’expiration de la durée
de vie de tombstone.)
Durée pendante pendante pour qu’un contrôleur de domaine soit hors connexion et qu’il retourne toujours
au domaine avec succès.
Temps qu’un contrôleur de domaine peut faire l’expérience d’un échec de réplication et revenir au domaine
avec succès.
Le nombre de jours pendantés pendantés par le contrôleur de domaine d’origine conserve la connaissance
des objets supprimés.
Support technique pour Windows éditions x64

Votre fabricant de matériel fournit un support technique et une assistance pour Windows éditions x64. Votre
fabricant de matériel assure la prise en charge car Windows édition x64 a été incluse dans votre matériel. Votre
fabricant de matériel a peut-être personnalisé l’installation Windows édition x64 avec des composants uniques.
Les composants uniques peuvent inclure des pilotes de périphérique spécifiques ou inclure des paramètres
facultatifs pour optimiser les performances du matériel. Microsoft vous fournira une assistance raisonnable si
vous avez besoin d’aide technique Windows édition x64. Toutefois, il se peut que vous deiez contacter
directement votre fabricant. Votre fabricant est le mieux qualifié pour prendre en charge les logiciels que votre
fabricant a installés sur le matériel.
0x80042306 erreur se produit lors de la
configuration de copies d’ombre pour les points de
montage en cluster sur un autre lecteur dans
Windows Server
Cet article vous aide à corriger la 0x80042306 d’erreur qui se produit lorsque vous configurez des versions
précédentes dans Windows Server pour les disques en cluster montés en tant que dossiers sur un volume
différent.
Symptômes
Lorsque vous essayez de configurer des versions précédentes dans Windows Server pour les disques en cluster
montés en tant que dossiers sur un autre volume, il peut échouer. En outre, le message d’erreur suivant peut
s’afficher :
Échec de la création de l’association de la zone de stockage.

Erreur 0x80042306 : le fournisseur de copies de l’ombre a reçu une erreur.
Autres symptômes que vous pouvez observer lorsque vous essayez de configurer des versions précédentes
pour un point de montage sur un autre volume :
Le disque de cluster est hors connexion.
Cause
L’erreur se produit en raison d’un décalage dans les délai d’arrêt en ligne et hors connexion du cluster. Il y a une
sortie prématuré après l’appel de la ressource en ligne/hors connexion.
Pour contourner ce problème, vous pouvez modifier les valeurs du Registre en suivant les étapes mentionnées
ci-dessous.
IMPORTANT
1. Dans l’écran d’accueil, cliquez sur la vignette Rechercher.

2. Tapez regedit dans la fenêtre Recherche, puis double-cliquez sur regedit.exe .
3. Recherchez l’entrée de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings
4. Cliquez avec le bouton droit sur ClusterOfflineTimeout, puis cliquez sur Modifier.
5. Sélectionnez Décimal, puis tapez 2000000000 dans la zone de données Valeur, puis cliquez sur OK .
6. Cliquez avec le bouton droit sur ClusterOnlineTimeout, puis cliquez sur Modifier.
7. Sélectionnez Décimal, puis tapez 2000000000 dans la zone de données Valeur, puis cliquez sur OK .
NOTE
La valeur décimale peut être augmentée selon les besoins.
L’accès est refusé lorsque vous exécutez un travail
par lots sur un ordinateur Windows Server 2003
Cet article fournit une solution à une erreur (Accès refusé) qui se produit lorsque vous exécutez un travail par
lots sur un ordinateur basé sur Microsoft Windows Server 2003.
Symptômes
Lorsque vous exécutez un travail par lots qui s’exécute dans le contexte d’un compte d’utilisateur normal, il se
peut que le script ne s’exécute pas. Si vous exécutez le travail par lots à l’aide de la fonctionnalité Tâches
programmées, le message d’erreur suivant peut être consigné dans le fichier journal des tâches programmées
(Schedlgu.txt) :
0x80070005 : l’accès est refusé.
Si vous utilisez un programme de déboguer pour essayer de déterminer pourquoi le travail par lots ne
fonctionne pas, le message d’erreur suivant peut apparaître dans la sortie de débogage :
Accès refusé (Erreur 5)
Cause
Ce problème se produit si toutes les conditions suivantes sont vraies :
Vous exécutez le traitement par lots sur Windows serveur membre basé sur Server 2003.
Le traitement par lots s’exécute en tant que processus non interactif.
Le traitement par lots est configuré pour s’exécuter dans le contexte d’un compte qui n’est pas membre du
groupe Administrateurs.
Dans Windows Server 2003, le groupe Utilisateurs n’a pas d’autorisations Lecture et Exécution sur le processeur
de commandes (Cmd.exe). Par défaut, le programme Cmd.exe a les paramètres d’autorisation suivants :
Le groupe implicite interactif et le groupe implicite Service ont des autorisations de lecture et d’exécution.
NOTE
Sur un serveur membre, le groupe TelnetClients dispose également des autorisations Lecture et Exécution. Sur un
contrôleur de domaine, le groupe implicite Batch dispose également d’autorisations de lecture et d’exécution.
Le groupe Administrateurs et le groupe implicite Système ont des autorisations Contrôle total.
Résolution 1 : accorder Cmd.exe autorisations de lecture et

d’exécution
Accordez au Cmd.exe programme de lecture et d’exécution des autorisations pour le compte d’utilisateur sous
qui s’exécute la tâche de traitement par lots. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer, puis sur Windows Explorer.
2. Recherchez puis cliquez avec le bouton droit sur Cmd.exe fichier. Le Cmd.exe se trouve dans le dossier
%windir%\System32.
4. Cliquez sur l’onglet Sécurité .
6. Dans la zone Entrez les noms des objets à sélectionner, tapez le nom d’utilisateur sous le lot, puis
cliquez deux fois sur OK.
NOTE
Lorsque vous ajoutez l’utilisateur, les autorisations Lecture et Exécution lui sont automatiquement accordées.
7. Cliquez sur Oui lorsque vous êtes invité à continuer.

Résolution 2 : accorder des autorisations de lecture et d’exécution pour Cmd.exe fichier au groupe batch
Accorder des autorisations de lecture et d’exécution Cmd.exe fichier au groupe Batch. Cela permet à tous les
processus de traitement par lots d’exécuter le processeur de commandes. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer, puis sur Windows Explorer.
2. Recherchez, puis cliquez avec le bouton droit sur le fichier Cmd.exe . Le Cmd.exe se trouve dans le dossier
%windir%\System32.
4. Cliquez sur l’onglet Sécurité .
6. Dans la zone Entrez les noms des objets à sélectionner, tapez Batch, puis cliquez deux fois sur OK.
7. Cliquez sur Oui lorsque vous êtes invité à continuer.
Le comportement décrit dans cet article est différent du comportement par défaut de Microsoft Windows 2000
Server. Par défaut, Windows 2000 Server accorde des autorisations de lecture et d’exécution au groupe
Utilisateurs.
Pour plus d’informations sur les groupes implicites, consultez les sites Web Microsoft suivants :
Comptes et groupes d’utilisateurs par défaut
Utilisation des comptes de groupe par défaut
Le programme de sauvegarde échoue lorsque vous
sauvegardez un volume système important
Cet article fournit une solution au problème où le programme de sauvegarde échoue lorsque vous sauvegardez
un volume système important.
Symptômes
Lorsque vous essayez de créer une sauvegarde à l’aide de NTBackup.exe ou à l’aide d’un programme de
sauvegarde tiers qui utilise l’API de sauvegarde NT, la sauvegarde risque de ne pas s’achever correctement. Ce
comportement peut se produire même si vous exécutez le programme localement sur le serveur. En outre, vous
pouvez avoir un ou plusieurs des symptômes suivants :
Un ou plusieurs des messages d’erreur suivants apparaissent dans le journal des applications :
ERREUR 1450 : des ressources système insuffisantes existent pour terminer le service demandé.
ERREUR 1450 : /hex 0x5aa ERROR_NO_SYSTEM_RESOURCES
Erreur du système d’exploitation 1450 Les ressources système insuffisantes existent pour terminer le
service demandé.
Échec de l’écriture sur « appareil », état = 1450
ERREUR 1130 : un espace de stockage serveur insuffisant est disponible pour traiter cette commande.
ERREUR 1130 / 0x46a ERROR_NOT_ENOUGH_SERVER_MEMORY
L’opération de sauvegarde ou de restauration se termine anormalement.
Les messages ID d’événement 2020 et ID d’événement 2021 peuvent être générés par le service serveur.
NOTE
En règle générale, les messages ID d’événement 2020 et ID d’événement 2021 n’apparaissent pas.
Si vous exécutez le programme de sauvegarde OmniBack Hewlett-Packard (HP), vous pouvez recevoir un
message d’erreur semblable à celui-ci :
[81:78] C:\foldername\file.name
Impossible de lire 57 256 octets au 436176408(:1) : ([1450]
Des ressources système insuffisantes existent pour terminer le service demandé.)
Si vous affichez l’onglet Performances dans Windows du Gestionnaire des tâches, vous remarquerez
que la mémoire du noyau nonpage est faible.
NOTE
Vous pouvez recevoir ces messages d’erreur pour des raisons qui ne sont pas liées au problème décrit dans cet article. Si
vous ne recevez ces messages d’erreur que lorsque vous backez des volumes système importants, les deux causes les plus
probables sont celles que décrit cet article.
Pour déterminer si vous rencontrez ce problème, démarrez Windows Gestionnaire des tâches, puis cliquez sur
l’onglet Performances. En bas à droite, recherchez la zone Mémoire du noyau (K), puis notez la valeur de
Paged . Vous pouvez être face à ce problème dans Microsoft Windows 2000 ou dans Microsoft Windows NT 4.0
lorsque cette valeur atteint environ 160 mégaoctets (Mo). Vous pouvez également faire face à ce problème dans
Microsoft Windows Server 2003 lorsque cette valeur dépasse 160 Mo. Si vous avez fixé une valeur supérieure à
la clé de Registre pour la mémoire de pool pagaie, vous ne serez pas en situation de problème tant qu’une
valeur beaucoup plus élevée de mémoire pagaie du pool n’aura pas été utilisée (le problème peut se produire
lorsque l’utilisation de la mémoire du pool pagaté atteint environ 80 % de la valeur définie). Si le paramètre est
désactivé pour les balises de pool et si vous utilisez l’utilitaire Poolmon, vous constatez une utilisation plus
élevée de la gflags balise MmSt. Il s’agit de la balise de pool utilisée pour maguer la mémoire du système
d’exploitation utilisée pour suivre les fichiers partagés.
Cause
Les deux causes de ce problème sont liées. La cause la plus fréquente est répertoriée en premier :
Le nombre de fichiers ouverts est supérieur au nombre de fichiers gérés par le gestionnaire de cache
mémoire. Par conséquent, le gestionnaire de cache a épuisé la mémoire de pool pagaie disponible.
Le programme de sauvegarde a tenté de sauvegarder un fichier dont la taille est supérieure à celle de
l’API de sauvegarde accessible sur cette version du système d’exploitation. Il a le même résultat
(autrement dit, le pool pagaté est épuisé).
NOTE
Ce deuxième problème est plus susceptible de se produire sur un ordinateur Microsoft Windows NT 4.0.
La résolution de chaque problème varie selon que vous le faites dans Windows Server 2003, dans Microsoft
Windows 2000 ou dans Windows NT 4.0.
Résolution
Windows Server 2003 et Windows 2000
IMPORTANT
Vous de devez peut-être modifier deux paramètres de Registre. Modifiez toujours le premier paramètre. En
fonction de la configuration de votre système, vous de devez peut-être également modifier le deuxième
paramètre.
Paramètre de Registre 1
1. Cliquez sur Démarrer , puis Exécuter , entrez regedit dans la zone Ouvrir et cliquez sur OK .
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
4. Tapez PoolUsageMaximum comme nom d’entrée, puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur PoolUsageMaximum, puis cliquez sur Modifier.
6. Cliquez sur Décimal .
IMPORTANT
Utilisez 60 comme valeur initiale. Si votre sauvegarde ne réussit pas, utilisez 40 comme valeur. Si cela ne
fonctionne pas, vous devez modifier le comportement de votre programme de sauvegarde afin de réduire la
demande de pool pagatique. Si la valeur fonctionne, vous pouvez augmenter la valeur d’environ 25 % jusqu’à
ce que la sauvegarde ne fonctionne pas. Si la sauvegarde échoue, utilisez le deuxième paramètre de Registre
décrit dans cet article.
Assurez-vous que la valeur de ce paramètre de Registre n’est pas plus de 60.
Si vous utilisez le commutateur /3Gb, utilisez 40 comme paramètre initial. Notez que cette valeur est une
valeur de pourcentage.

9. Restart your computer.
Étant donné que vous devez tester ces paramètres pendant les sauvegardes les plus stressantes, vous de devez
peut-être patienter un mois avant la fin d’un cycle de sauvegarde entier si vous ne savez pas quelle sauvegarde
consomme le plus de ressources. En raison de cette situation, Microsoft vous recommande de tester d’abord les
valeurs faibles. Pour plus d’informations, cliquez sur le numéro d’article suivant pour afficher l’article dans la
312362 server is unable to allocate memory from the system pagd pool
Paramètre de Registre 2
1. Cliquez sur Démarrer, sur Exécuter, tapez regedit dans la zone Ouvrir, puis cliquez sur OK
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
3. Dans le menu Edition, pointez sur Nouveau , puis cliquez sur Valeur DWORD .
4. Tapez PagedPoolSize comme nom d’entrée, puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur PagedPoolSize, puis cliquez sur Modifier.
6. Cliquez sur Hexadécimal .
7. Dans la zone de données Valeur, tapez la valeur FFFFFFFF, puis cliquez sur OK.
IMPORTANT
Le fait de définir PagedPoolSize sur 0xFFFFFFFF (-1) alloue le pool paginé maximal au lieu d’autres
ressources à l’ordinateur. Cela est généralement requis sur un contrôleur de domaine ou un serveur
Terminal Server. Par défaut, la plupart Windows 2 000 systèmes semblent être limités à une taille maximale
de pool paginée de 160 Mo. Vous pouvez le vérifier en téléchargeant les déboguer du noyau à partir du
site Web public et en ouvrant un vidage du noyau dans le déboguer que vous souhaitez utiliser. La
commande à utiliser est !vm . Cela indique un pool pagaie maximal de 163 840 Ko, par exemple. L’ajout de
cette valeur réduit les entrées de table de pages (PTE) disponibles sur un système et étend la taille
maximale du pool paginé à 343 Mo en Windows 2000. La taille maximale du pool paginé peut être
étendue à une valeur supérieure dans Windows Server 2003.
Les valeurs de pool paginés par défaut et maximales pour Windows Server 2003 sont beaucoup plus
importantes qu’Windows 2000. En règle générale, les valeurs Windows Server 2003 sont au moins 50 %
plus élevées que les valeurs trouvées dans Windows 2000. Ces valeurs plus importantes rendent plus peu
probable le problème où les valeurs de pool pagyés contribuent au problème décrit dans cet article.
Toutefois, il est toujours possible que ce problème se produise.
Cette valeur limite les ptEs système disponibles. Les ptEs sont une autre ressource système non liée que
votre système utilise. Ce paramètre peut entraîner l’arrêt inattendu de votre système d’exploitation et
l’affichage d’un 0x3F sur un écran bleu au démarrage. Vous pouvez récupérer à partir de cette option à
l’aide de l’option Dernier redémarrage connu good restart dans le menu de redémarrage du système ou la
console de récupération. Utilisez l’Moniteur de performances pour afficher le compteur Entrées du
tableau Des pages du système libre. Vous pouvez ajouter le paramètre PagePoolSize si les valeurs libres
observées sont plus de 40 000.
Si vous exécutez /3 Go et /PAE ensemble, ne définissez pas ce paramètre sans tests approfondis et avant
d’établir exactement le nombre de PTES système que vous devez avoir dans votre environnement. Vous
verrez probablement des valeurs dans la plage de 10 000 à 20 000 gratuites. Utilisez les articles pour
configurer la mémoire pagyée du pool, mais ne jamais passer en dessous de 10 000 ptes système gratuits.
Ne définissez pas cette valeur sur une autre valeur si vous utilisez le commutateur /3Gb. Les seules valeurs
prise en charge sont 0, 0A000000 et FFFFFFFF.

Windows NT 4.0
IMPORTANT
NOTE
Vous devez utiliser Windows NT 4.0 Service Pack 6a.
Résoudre le premier problème

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory_Management
3. Dans le menu Edition, cliquez sur Ajouter une valeur, puis ajoutez la valeur de Registre suivante :
Nom de la valeur : UnusedFileCache
Radix : Décimal
NOTE
Ce nombre représente le pourcentage de pool qui peut être consommé par des segments inutilisés. La valeur 0
indique que le système utilisera le comportement par défaut similaire à celui Windows NT 4.0 Service Pack 3. Une
valeur de 5 à 40 indique que le système découpera le cache de fichiers inutilisé en fonction de l’utilisation du pool.
5 est le plus agressif (autrement dit, il augmente la taille du cache le moins) et 40 est le moins agressif (autrement
dit, il permet au cache d’augmenter le plus grand avant de découper le cache.)
IMPORTANT
Utilisez 15 comme valeur initiale. Si votre sauvegarde ne réussit pas, utilisez 5 comme valeur. Si cela ne
fonctionne pas, vous devez soit modifier le comportement de votre programme de sauvegarde afin de
réduire la demande de pool paginé, soit mettre à niveau vers Windows 2000, où plus du double du pool
paginé est disponible (pour plus d’informations, voir la section « Windows 2000 »). Si cette valeur
fonctionne, vous pouvez l’augmenter d’environ 20 % jusqu’à ce que la sauvegarde échoue. Si la sauvegarde
échoue, utilisez le deuxième paramètre de Registre décrit dans cet article.
Si vous utilisez le commutateur /3Gb, utilisez 5 comme paramètre initial.

Étant donné que vous devez tester ces paramètres pendant les sauvegardes les plus stressantes, vous de devez
peut-être patienter un mois avant la fin d’un cycle de sauvegarde entier si vous ne savez pas quelle sauvegarde
consomme le plus de ressources. Pour cette raison, Microsoft vous recommande de tester d’abord les valeurs
faibles.
Résoudre le deuxième problème
Une solution possible consiste à restreindre la sauvegarde afin qu’elle sauvegarde un fichier à la fois. Elle peut
ou non fonctionner en fonction de la taille des fichiers à back up. (Elle est prévue pour fonctionner sur des
fichiers dont la taille est plus petite que 180 gigaoctets [Go].) Vous pouvez également essayer cette résolution si
vous backing plusieurs fichiers de grande taille, mais que chaque fichier est inférieur à 180 Go. Suivez
également les étapes pour résoudre le premier problème. Pour les fichiers de plus de 180 Go, il n’existe aucune
solution de contournement. Par conséquent, vous devez mettre à niveau le système vers Windows 2000. Si vous
essayez de back up the system remotely as a workaround, you will experience the same problem.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory_Management
3. Dans le menu Edition, cliquez sur Ajouter une valeur, puis ajoutez la valeur de Registre suivante :
Nom de la valeur : DisablePagedPoolHint
Radix : Décimal
Statut
S’applique à ».
NTBackupread et NTBackupwrite utilisent des opérations d’utilisation en mémoire tampon. Cela signifie que
Windows NT met en cache les I/S effectuées par rapport au flux. Il s’agit également de la seule API qui permet de
back up les métadonnées d’un fichier. Ce cache est tiré de ressources limitées : pool et pool nonpaged. Pour cette
raison, un grand nombre de fichiers ou de fichiers de grande taille peut entraîner une baisse des ressources du
pool.
Plusieurs facteurs peuvent épuiser l’approvisionnement de la mémoire pagyée du pool. Vous pouvez activer le
marquage du pool et l’utiliser à différents intervalles de temps pour vous aider à comprendre quel pilote épuise
la mémoire poolsnaps paguée du pool. Si la balise MmSt (ptEs prototype d’objet de section Mm) est la plus
grande consommatrice et qu’elle est supérieure à 80 Mo, un grand nombre de fichiers sont probablement
ouverts sur poolsnaps le serveur.
La mémoire maximale de pool paginée possible sur un ordinateur est de 343 Mo de pool paginé dans Windows
2000 avec la clé de pool paginée définie sur FFFFFFFF, ou de 164 Mo si la clé n’est pas présente. La mémoire
maximale paginée possible du pool est de 192 Mo Windows NT. Par défaut, le Gestionnaire de mémoire tente de
découper la mémoire pagaie allouée du pool lorsque le système atteint 80 % du pool pagaie total. Par exemple,
80 % de 343 Mo sont de 274 Mo. Si le Gestionnaire de mémoire ne peut pas réduire suffisamment rapidement
pour répondre à la demande, l’événement répertorié dans la section « Symptômes » de cet article peut se
produire. Si vous régler le Gestionnaire de mémoire pour démarrer le processus de tri plus tôt (par exemple,
lorsqu’il atteint 40 pour cent), l’ordinateur peut suivre la demande du pool pagyé lors d’une utilisation soudaine
maximale afin qu’il ne manque pas de mémoire pagyée dans le pool.
produits.
Message d’erreur lorsque vous essayez d’ajouter un
disque supplémentaire à une sauvegarde
programmée : le nom de fichier, le nom du
répertoire ou la syntaxe de l’étiquette de volume est
incorrect
Cet article permet de résoudre une erreur (le nom de fichier, le nom du répertoire ou la syntaxe de l’étiquette de
volume est incorrect) qui se produit lorsque vous ajoutez un disque supplémentaire à une sauvegarde
programmée.
Symptômes
Lorsque vous essayez d’ajouter un disque supplémentaire à une sauvegarde programmée à l’aide de l’Assistant
Planification de sauvegarde Windows Server, vous pouvez recevoir le message d’erreur suivant :
« La syntaxe du nom de fichier, du répertoire ou de l’étiquette de volume est incorrecte »
Cause
Ce problème peut se produire si un disque de destination précédemment ajouté n’est pas actuellement attaché
au serveur. Une fois l’Assistant terminé, les disques de destination actuellement répertoriés sont vérifiés. Si l’un
de ces disques est manquant, vous recevez le message d’erreur décrit dans la section « Symptômes ».
Résolution
Pour résoudre ce problème, utilisez l’une des options suivantes.
NOTE
Pour configurer ou modifier une planification de sauvegarde quotidienne, vous devez être membre du groupe
Administrateurs. En outre, vous devez exécuter la commande wbadmin à partir d’une invite de commandes avec
élévation de élévation de niveaux. Pour ouvrir une invite de commandes avec élévation de niveau élevé, cliquez sur
Démarrer, cliquez avec le bouton droit sur Invite de commandes, puis cliquez sur Exécuter en tant
Option 1
1. Rattachez le ou les disques manquants.
2. Assurez-vous que tous les disques définis comme disques de destination de sauvegarde sont attachés au
serveur.
3. Essayez à nouveau d’ajouter un disque supplémentaire à une sauvegarde programmée à l’aide de l’Windows
Planification de sauvegarde du serveur.
NOTE
Si vous utilisez le stockage hors site ou si une autre situation empêche tous les disques de destination d’être attachés en
même temps, utilisez l’option 3.
Option 2
Si le disque manquant n’est plus disponible, supprimez-le en tant que disque de destination de l’Assistant de
sauvegarde.
NOTE
Si le disque manquant est le seul disque de destination défini dans la planification de sauvegarde, vous recevrez
le message d’erreur suivant lorsque vous tenterez de le supprimer. Si cela se produit, cliquez sur Arrêter la
sauvegarde, puis créez une planification de sauvegarde.
« Erreur : vous ne pouvez pas supprimer cette destination de stockage de sauvegarde, sauf si vous ajoutez
une autre destination de stockage ou arrêtez la sauvegarde programmée. Une sauvegarde de planification
nécessite au moins une destination de stockage de sauvegarde.
Pour supprimer un disque de destination d’une sauvegarde programmée, suivez les étapes suivantes :
1. Dans le Windows de sauvegarde du serveur, cliquez sur Planification de sauvegarde.
2. Cliquez sur Modifier la sauvegarde, puis sur Suivant.
3. Laissez le paramètre configuration de sauvegarde inchangé, puis cliquez sur Suivant .
4. Laissez le paramètre Heure de sauvegarde inchangé, puis cliquez sur Suivant .
5. Laissez le paramètre Type de destination inchangé, puis cliquez sur Suivant.
6. Sélectionnez Supprimer les destinations de sauvegarde actuelles, puis cliquez sur Suivant.
7. Sélectionnez la destination de sauvegarde qui n’est plus attachée, puis cliquez sur Suivant .
NOTE
En règle générale, le disque a le nom « (Disque hors connexion). »
8. Vérifiez que la configuration est correcte, puis cliquez sur Terminer.

Option 3
Ajoutez un nouveau disque à la planification de sauvegarde en exécutant la commande wbadmin à partir d’une
invite de commandes avec élévation de élévation de valeurs.
1. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de niveaux pour
déterminer l’identificateur de disque du nouveau disque :
wbadmin get disks
2. En fonction de la sortie, recherchez le disque qui sera ajouté à la sauvegarde programmée. Notez
l’identificateur de disque. La sortie ressemblera à ce qui suit :
Nom du disque : xxxxxxxxxxx

Numéro de disque : x
Identificateur de disque : {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
Espace total :xxx.xxGB
Espace utilisé : xxx.xxGB
3. Exécutez la commande suivante pour ajouter le nouveau disque à la sauvegarde programmée. Utilisez
l’identificateur de disque de l’étape précédente comme paramètre AddTarget.
WBADMIN ENABLE BACKUP -addtarget:{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
4. Lorsque vous recevez l’invite suivante, tapez Y pour Oui.
« Voulez-vous activer les sauvegardes programmées avec les paramètres ci-dessus ? »
Pour plus d’informations, consultez les sites Web Microsoft suivants :
Nouveautés de la sauvegarde Windows server sur Windows Server 2008 R2
Nouveautés de la sauvegarde Windows server
Webadmin
Wbadmin
Les clients DirectAccess ne peuvent pas se
connecter sur IP-HTTPS avec 0x274d ou 0x2afc
Cet article fournit une solution à la 0x274d d’erreur qui se produit lorsque les clients DirectAccess se connectent
à DirectAccess Server à l’aide du protocole Internet sur IP-HTTPS (Secure Hypertext Transfer Protocol).
Symptômes
Les clients DirectAccess peuvent ne pas être en mesure de se connecter au serveur DirectAccess à l’aide de
connexions IP-HTTPS ou de résoudre le nom d’hôte public DirectAccess.
Lorsque vous exécutez netsh interface http show interface la commande, la sortie est la suivante :
Erreur : 0x274d ou 0x2afc

Traduit par : Le nom demandé est valide, mais aucune donnée du type demandé n’a été trouvée
ou
Aucune connexion n’a pu être réalisée car l’ordinateur cible l’a activement refusée.
La suppression de l’GPO DirectAccess permet au client de résoudre le nom d’hôte public DirectAccess.
L’exécution netsh namespace show policy de la commande sur un client affiche une stratégie pour l’espace de
noms .contoso.com.
Dans cette stratégie, l’entrée DirectAccess (Serveurs DNS) sera définie sur l’interface IPv6 interne du serveur
DirectAccess, se terminant généralement par 3333::1.
Cause
Erreur : 0x2AFC
Rôle : Client
URL : https://da.contoso.com/IPHTTPS
Dernier code d’erreur : 0x2AFC
État de l’interface : échec de la connexion au serveur IPHTTPs ; En attente de reconnexion.
0x2AFC se traduit par :
WSANO_DATA
# Le nom demandé est valide, mais aucune donnée du type demandé n’a été trouvée.
WSANO_DATA
# Une valeur NULL a été renvoyée.
Cette erreur peut se produire pour plusieurs raisons :

Un serveur proxy bloque la connexion.
Impossibilité de résoudre le nom du serveur IP-HTTPS (serveur DirectAccess) mentionné dans l’URL de
l’interface IP-HTTPS.
Le pare-feu côté client ou côté serveur peut bloquer la connexion au serveur IP-HTTPS (serveur
DirectAccess).
L’appareil NAT est configuré de manière incorrecte (si un scénario de périphérie est utilisé).
Toutes les connectivités sont bonnes, mais le préfixe IPv6 n’est pas publié sur le serveur, ou le protocole IP-
HTTPS côté serveur est désactivé.
Erreur : 0x274D
Rôle : Client
URL : https://da.contoso.com/IPHTTPS
Dernier code d’erreur : 0x274D
État de l’interface : échec de la connexion au serveur IPHTTPs ; En attente de reconnexion.
0x274D se traduit par :
WSAECONNRE FUSIONNÉ
# Aucune connexion n’a pu être réalisée car l’ordinateur cible l’a activement refusée.
Cette erreur est due aux causes suivantes :

Impossibilité de résoudre le nom du serveur IP-HTTPS (serveur DirectAccess) mentionné dans l’URL de
l’interface IP-HTTPS
Table de stratégie de résolution de noms (NRPT) mal configurée
Le pare-feu côté client bloque peut-être la connexion IP-HTTPS
Le domaine interne et l’entrée DNS externe utilisés par DirectAccess sont tous deux dans le même espace de
noms (par exemple, *.contoso.com)
Résolution
Pour résoudre ce problème, nous devons ajouter une entrée à la NRPT pour demander au client d’utiliser son
DNS Internet pour résoudre le nom d’hôte public du serveur DirectAcess. Pour ce faire, sur le serveur
DirectAcess, ouvrez la console de gestion de l’accès à distance, sous Configuration, sélectionnez DirectAccess et
VPN, recherchez la section Serveurs d’infrastructure sous Étape 3, puis cliquez sur Modifier.
Dans la fenêtre Installation du serveur d’infrastructure, sélectionnez DNS sur le côté gauche pour afficher les
paramètres NRPT du déploiement DirectAccess. La dernière ligne affiche un astérisque (*) sur le côté gauche,
cliquez avec le bouton droit sur cette ligne et sélectionnez nouveau. Dans la fenêtre Adresses du serveur DNS,
entrez le nom d’hôte public du serveur DirectAccess en tant que suffixe DNS (par exemple, DA.contoso.com),
n’essayez pas de détecter ou de valider le suffixe. Laissez plutôt le reste des informations vide et cliquez sur
Appliquer.
Cela crée une entrée avec un suffixe de nom et aucune adresse de serveur DNS, ce qui permet aux clients
d’utiliser leur propre DNS Internet pour résoudre ce nom. Terminez le processus de configuration de
l’infrastructure et mettez à jour l’GPO en cliquant sur Terminer dans la fenêtre Installation de l’accès à distance.
Appliquez le nouvel GPO aux clients et essayez de résoudre le nom d’hôte du serveur DirectAccess.
Les clients DirectAccess utilisent plusieurs méthodes pour se connecter au serveur DirectAccess, ce qui permet
d’accéder aux ressources internes. Les clients ont la possibilité d’utiliser Teredo, 6to4 ou IP-HTTPS pour se
connecter à DirectAccess. Cela dépend également de la configuration du serveur DirectAccess.
Lorsque le client DirectAccess dispose d’une adresse IPv4 publique, il tente de se connecter à l’aide de l’interface
6to4. Toutefois, certains FAI donnent l’illusion d’une adresse IP publique. Ce qu’ils fournissent aux utilisateurs
finaux est une pseudo adresse IP publique. Cela signifie que l’adresse IP reçue par le client DirectAccess (une
carte de données ou une connexion SIM) peut être une adresse IP de l’espace d’adressare public, mais en réalité
se trouve derrière une ou plusieurs nats.
Lorsque le client se trouve derrière un périphérique NAT, il essaie d’utiliser Teredo. De nombreuses entreprises
telles que les hôtels, les aéroports et les cafés n’autorisent pas le trafic Teredo à traverser leur pare-feu. Dans de
tels scénarios, le client se place en IP-HTTPS. IP-HTTPS est basé sur une connexion TCP 443 SSL (TLS). Le trafic
sortant SSL sera probablement autorisé sur tous les réseaux.
Dans cette situation, IP-HTTPS a été conçu pour fournir une connexion de sauvegarde fiable et toujours
accessible. Un client DirectAccess l’utilisera en cas d’échec d’autres méthodes (par exemple, Teredo ou 6to4).
Pour plus d’informations sur les technologies de transition, voir IPv6 Transition Technologies.
Erreur Diskshadow lorsque vous essayez de créer
une capture instantanée VSS
Cet article décrit un problème qui déclenche un message d’erreur lorsque vous essayez de créer une capture
instantanée d’ombre de disque VSS (Volume Shadow Services).
Symptômes
Lorsque vous ouvrez une invite de commandes d’administrateur et créez une capture instantanée d’ombre de
disque VSS dans Windows Server 2012 R2, la sortie peut contenir une erreur :
Commandes :
DISKSHADOW> add volume c:

DISKSHADOW> create
Résultats :
L’appel COM « lvssObject4->GetRootAndLogicalPrefixPaths » a échoué.
Cause
Cette erreur se produit lorsque l’opération de sauvegarde atteint un point, où elle tente de traiter les données de
magasin de données de configuration de démarrage (BCD). Le magasin BCD se trouve dans la partition système.
Toutefois, étant donné que cette partition ne figure pas dans la liste des périphériques montés, l’erreur est
déclenchée.
Résolution
Ce message d’échec d’appel COM particulier est sans danger. Malgré le message, la sauvegarde de l’ombre
portée s’est correctement effectuée. Aucune résolution n’est donc requise.
Microsoft est conscient de ce problème et continuera à rechercher les mises à jour futures.
Comment activer les fonctionnalités de suivi du
débogage du service volume shadow copy dans
Windows Server 2003 et Windows Server 2008
Cet article explique comment activer les fonctionnalités de suivi de débogage du service Volume Shadow Copy
dans Windows Server 2003 et Windows Server 2008.
IMPORTANT
Étapes pour activer les fonctionnalités de suivi de débogage du

service Volume Shadow Copy
NOTE
Toute modification incorrecte du Registre à l’aide de l’Éditeur du Registre ou d’une autre méthode peut entraîner des
problèmes sérieux. Ces problèmes peuvent nécessiter la réinstallation du système d'exploitation. Microsoft ne peut pas
garantir que ces problèmes puissent être résolus. Vous assumez l’ensemble des risques liés à la modification du Registre.
Pour activer les fonctionnalités de suivi de débogage du service volume shadow copy dans Windows Server
2003 et Windows Server 2008, suivez les étapes suivantes :
2. Dans l'éditeur du registre, recherchez la sous-clé de registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS
3. Dans le volet gauche, cliquez avec le bouton droit sur VSS, pointez sur Nouveau, puis cliquez sur
Touche .
4. Tapez Débogage, puis appuyez sur Entrée.
5. Dans le volet gauche, cliquez avec le bouton droit sur Déboguer, pointez sur Nouveau, puis cliquez sur
Touche .
6. Tapez Suivi, puis appuyez sur Entrée.
7. Dans le volet gauche, cliquez avec le bouton droit sur Suivi, pointez sur Nouveau, puis cliquez sur
Valeur DWORD.
8. Tapez TraceLevel, puis appuyez sur Entrée.
9. Double-cliquez sur TraceLevel, puis tapez ffffffff dans la zone de données Valeur. Autrement dit, tapez
f huit fois dans la zone de données Valeur. Cliquez sur OK .
NOTE
L’entrée de Registre TraceLevel détermine le type de suivi de débogage qui se produit. La valeur 0 (valeur par
défaut) indique qu’aucun suivi ne se produit. La valeur ffffffff allume le suivi de tous les événements.
Valeur DWORD.
11. Tapez TraceEnterExit, puis appuyez sur Entrée.
12. Double-cliquez sur TraceEnterExit, tapez 1 dans la zone de données Valeur, puis cliquez sur OK .
NOTE
L’entrée de Registre TraceEnterExit détermine si les informations d’entrée et de sortie de la fonction sont en sortie
dans le fichier de suivi et dans le flux de sortie de débogage. La valeur 0 (valeur par défaut) indique qu’aucune
information d’entrée et de sortie de la fonction n’est produite. La valeur 1 indique que les informations d’entrée et
de sortie de la fonction sont en sortie.
Valeur DWORD.
14. Tapez TraceToFile, puis appuyez sur Entrée.
15. Double-cliquez sur TraceToFile , tapez 1 dans la zone de données Valeur, puis cliquez sur OK .
NOTE
L’entrée de Registre TraceToFile détermine si les informations de suivi sont sorties dans le fichier de suivi. La valeur
0 (valeur par défaut) indique qu’aucune information de suivi n’est produite dans le fichier de suivi. La valeur 1
indique que les informations de suivi sont sorties dans le fichier de suivi. Si vous définissez la valeur sur 1, vous
devez également définir l’entrée de Registre TraceFile. Pour définir l’entrée de Registre TraceFile, suivez les étapes
suivantes :
1. Dans le volet gauche, cliquez avec le bouton droit sur Suivi, pointez sur Nouveau, puis cliquez sur Valeur de
chaîne .
2. Tapez TraceFile, puis appuyez sur Entrée.
3. Double-cliquez sur TraceFile, tapez c: \trace.txt dans la zone de données Valeur, puis cliquez sur OK .
L’entrée de Registre TraceFile ne peut pas être stockée sur le disque où le shadow copy est créé.
Valeur DWORD.
17. Tapez TraceToDebugger, puis appuyez sur Entrée.
18. Double-cliquez sur TraceToDebugger , tapez 1 dans la zone de données Valeur, puis cliquez sur OK .
NOTE
L’entrée de Registre TraceToDebugger détermine si les informations de suivi sont en sortie dans le flux de sortie de
débogage. La valeur 0 (valeur par défaut) indique qu’aucune information de suivi n’est produite dans le flux de
sortie de débogage. La valeur 1 indique que les informations de suivi sont sorties vers le flux de sortie de
débogage.
Valeur DWORD.
20. Tapez TraceTimeStamp, puis appuyez sur Entrée.
21. Double-cliquez sur TraceTimeStamp , tapez 1 dans la zone de données Valeur, puis cliquez sur OK .
NOTE
L’entrée de Registre TraceTimeStamp détermine si les informations d’horodanage sont sorties dans le fichier de
suivi et dans le flux de sortie de débogage. La valeur 0 (valeur par défaut) indique qu’aucune information
d’horodat n’est produite. La valeur 1 indique que les informations d’horodat sont en sortie.
Valeur DWORD.
23. Tapez TraceFileLineInfo, puis appuyez sur Entrée.
24. Double-cliquez sur TraceFileLineInfo , tapez 1 dans la zone de données Valeur, puis cliquez sur OK .
NOTE
L’entrée de Registre FileLineInfo détermine si les informations de nom de fichier du module et les informations de
numéro de ligne sont en sortie dans le fichier de suivi et dans le flux de sortie de débogage. La valeur 0 (valeur
par défaut) indique qu’aucune information sur le nom de fichier du module et aucune information de numéro de
ligne n’est en sortie. La valeur 1 indique que les informations de nom de fichier du module et les informations de
numéro de ligne sont en sortie.
Valeur DWORD.
26. Tapez TraceForceFlush, puis appuyez sur Entrée.
27. Double-cliquez sur TraceForceFlush , tapez 1 dans la zone de données Valeur, puis cliquez sur OK .
NOTE
L’entrée de Registre TraceForceFlush détermine si un purge forcé se produit après l’écriture de chaque message de
suivi dans le fichier de suivi. La valeur 0 (valeur par défaut) indique qu’aucun purge forcé ne se produit. La valeur 1
indique qu’un purge forcé se produit. En cas de purge forcée, aucun enregistrement de suivi n’est perdu, mais les
performances de l’ordinateur sont considérablement réduites.

Pour plus d’informations sur le service Volume Shadow Copy, visitez le site Web Microsoft suivant :
Service de cliché instantané de volume
Erreur 3266 ou 3013 lorsque vous effectuez une
sauvegarde de base de données sur disque ou
bande ou une restauration de base de données à
partir d’un disque ou d’une bande
Cet article permet de résoudre l’erreur 3266 ou 3013 qui se produit lorsque vous effectuez une sauvegarde de
base de données sur disque ou bande ou une restauration de base de données à partir d’un disque ou d’une
bande.
Symptômes
Lorsque vous effectuez une sauvegarde de base de données sur disque ou bande, ou lors d’une restauration à
partir d’un disque ou d’une bande, le message d’erreur suivant peut se produire :
SQL Server 7.0 Server :
Msg 3266, Niveau 16, État 1, Ligne 1

La base de données de signets logiciels MTF (Microsoft Tape Format) sur l’appareil de sauvegarde «
devicename » ne peut pas être lue, ce qui empêche l’accès aléatoire.
Serveur : Msg 3013, Niveau 16, État 1, Ligne 1
L’opération de sauvegarde ou de restauration se termine anormalement.
SQL Server Server 2000 :

Le format des données de sauvegarde dans « devicename » est incorrect. Les sauvegardes ne peuvent pas
être annexes, mais les jeux de sauvegarde existants peuvent toujours être utilisables.
BACKUP DATABASE se termine anormalement.
SQL Server Server 2005 :

Les données de sauvegarde à la fin de « devicename » sont incorrectement formatées. Les jeux de
sauvegarde sur le média peuvent être endommagés et inutilisables. Pour déterminer les jeux de sauvegarde
sur le média, utilisez RESTORE HEADERONLY. Pour déterminer la convivialité des jeux de sauvegarde,
exécutez RESTORE VERIFYONLY. Si tous les jeux de sauvegarde sont incomplets, reformatez le média à l’aide
de BACKUP WITH FORMAT, qui détruit tous les jeux de sauvegarde.
BACKUP DATABASE se termine anormalement.
Cause
Un fichier de l’appareil de sauvegarde n’a pas pu être lu. Il existe de nombreuses raisons pour lesquelles vous
pouvez rencontrer une erreur de fichiermark. Voici quelques-unes des raisons suivantes :
Une défaillance multimédia peut se produire sur l’appareil où se trouve la sauvegarde.
Un échec d’écriture peut se produire lors de la création de la sauvegarde.
Par exemple, une perte de connectivité peut se produire lors d’une sauvegarde réseau. Sinon, un échec du
chemin d’accès d’E/S pour vider l’écriture sur le disque peut se produire après que l’écriture sur le disque
a été signalée SQL serveur comme réussi.
Pour autoriser SQL Server effectuer de nouvelles sauvegardes sur l’appareil de sauvegarde, vous devez
supprimer ou effacer manuellement l’appareil à l’aide de la commande suivante :
BACKUP DATABASE mydatabase TO DISK='C:\MyDatabase.bak' with FORMAT
Si le message d’erreur se produit lors d’une opération de restauration, il peut être possible de récupérer d’autres
jeux de sauvegarde à partir de l’appareil en spécifiant le numéro de fichier. Par exemple, si trois (3) sauvegardes
étaient sur un (1) périphérique de sauvegarde, les jeux de sauvegarde 1 et 2 peuvent être utilisables. Pour
déterminer si plusieurs jeux de sauvegarde sont sur un appareil, exécutez le code suivant à partir de l’Analyseur
de requêtes :
RESTORE HEADERONLY FROM DISK='C:\MyDatabase.bak'
Chaque jeu de sauvegarde possède une entrée dans la sortie. Pour indiquer un jeu de sauvegarde spécifique,
utilisez ce code :
RESTORE DATABASE mydatabase FROM DISK='C:\MyDatabase.bak' WITH FILE = FileNumber
NOTE
FileNumber est le numéro de jeu de sauvegarde à restaurer.
La liste suivante contient des remarques importantes concernant les sauvegardes et les SQL Server.
Une fois SQL Server une erreur de fichier sur un appareil, SQL Server n’écrit pas d’informations
supplémentaires sur l’appareil.
SQL Server stocke toutes les sauvegardes au format Microsoft Tape Format, que la sauvegarde soit
réalisée sur disque ou sur bande. Le format De bande Microsoft utilise des signets de fichier pour
contenir des informations telles que la taille du bloc et le nombre de blocs dans une sauvegarde, en plus
d’autres informations sur la sauvegarde. Le format De bande Microsoft utilise également des signets de
fichier pour délimiter les sauvegardes dans un périphérique de sauvegarde. Le fait qu’un fichier est
manquant ou endommagé suggère qu’au moins une sauvegarde sur l’appareil n’est pas valide.
Bien que vous soyez en mesure de restaurer certains jeux de sauvegarde à partir de l’appareil
endommagé, vous devez vérifier l’intégrité de la base de données restaurée.
SQL Server journal des détails de réussite ou d’échec lors d’une opération de sauvegarde ou de
restauration dans le journal des erreurs SQL Server et dans les tables d’historique de sauvegarde de la
base de données système msdb.
Si vous découvrez une erreur 3266 lors de la restauration d’un journal des transactions ou d’une
sauvegarde de base de données, examinez les journaux suivants pour plus d’informations :
SQL Server’erreurs
Tables d’historique de sauvegarde et de restauration
Journal des événements de l’application
Journal des événements système
S’il n’existe aucun détail sur l’échec dans ces journaux, vous avez peut-être subi un échec non signalé. Vous
devez contacter les services de support technique Microsoft si vous avez besoin d’aide.
Message d’erreur lorsque vous essayez
d’sauvegarder l’état du système dans Windows
Server 2008 et Windows Server 2008 R2
Cet article fournit une solution à une erreur qui se produit lorsque vous essayez d’sauvegarder l’état du système
sur un volume sur lequel le fichier d’état système reste.
S’applique à : Windows Server 2008 R2 Service Pack 1, Windows Server 2012 R2
Symptômes
Lorsque vous essayez d’sauvegarder l’état du système sur un volume sur lequel le fichier d’état système reste,
vous recevez une erreur, comme mentionné ci-dessous :
Dans Windows Server 2008, vous recevez l’erreur suivante :
ERREUR : l’emplacement de sauvegarde est un volume critique.
Dans Windows Server 2008 R2, vous recevez l’erreur suivante :
ERREUR : l’emplacement de stockage de sauvegarde n’est pas valide. Vous ne pouvez pas utiliser un volume
inclus dans la sauvegarde comme emplacement de stockage.
IMPORTANT
Cause
Ce comportement se produit car les sauvegardes de l’état système sur des volumes critiques sont bloquées
dans Windows Server 2008 et Windows Server 2008 R2.
Résolution
Vous pouvez modifier le comportement par défaut de Windows Server 2008 et Windows Server 2008 R2 en
ajoutant une entrée de Registre. Vous devez également vérifier que les conditions préalables suivantes sont
remplies avant de sauvegarder l’état du système sur un volume critique.
Conditions préalables à la sauvegarde de l’état du système sur des volumes critiques
Assurez-vous que le volume cible n’a pas de copie de secours avant le démarrage de la sauvegarde.
Si une sauvegarde d’état système est stockée sur un volume source, les paramètres de sauvegarde doivent
être configurés pour les sauvegardes complètes. Par défaut, les paramètres sont configurés pour les
sauvegardes complètes.
Vérifiez régulièrement qu’aucun autre utilisateur ou programme ne maintient un shadow copy sur le volume
cible.
Ne conservez pas les sauvegardes au niveau du volume et les sauvegardes d’état système au même
emplacement.
Le volume utilisé pour stocker la sauvegarde de l’état système nécessite deux fois plus d’espace libre que la
taille de la sauvegarde de l’état du système jusqu’à ce que la sauvegarde soit terminée.
Remarques
1. Toute écriture sur le volume cible avec des copies d’ombre augmente la taille de la zone de diff. Si la zone
de diff est liée, elle peut entraîner la suppression de copies d’ombre.
2. Les sauvegardes incrémentielles ne laissent pas de copies d’ombre, ce qui provoquera un effet secondaire
au point 1.
3. La sauvegarde stocke différentes versions en tant que copies d’ombre, elle provoquera un effet
secondaire au point 1.
Entrée de Registre pour activer les sauvegardes d’état système sur des volumes critiques
WARNING
que ces problèmes peuvent être résolus. Vous assumez l’ensemble des risques liés à la modification du Registre.
Pour que les fichiers de sauvegarde d’état système soient ciblés sur des volumes critiques, vous devez définir la
valeur de l’entrée de Registre sous la sous-clé de Registre AllowSSBToAnyVolume suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\
Définissez la valeur de cette entrée comme suit :
Name:AllowSSBToAnyVolume
Type de données :DWORD
Données de la valeur :1
NOTE
Lorsque cette valeur est définie sur 1, les sauvegardes d’état système sur n’importe quel volume sont activées. Pour
revenir au comportement par défaut, définissez la valeur sur 0.
La restriction visant à cibler la sauvegarde de l’état système sur n’importe quel volume est une nouvelle
fonctionnalité de Windows Server 2008 et Windows Server 2008 R2.
Si toutes les conditions préalables précédentes ne sont pas remplies, il se peut que vous rencontriez une perte
de copie de secours lors d’une sauvegarde. Dans la pire condition, la sauvegarde elle-même peut échouer en
raison de la capture instantanée à partir de laquelle la sauvegarde a été perdue lors de l’écriture de la
sauvegarde.
Étapes pour reproduire le comportement

1. Installez Windows Server 2008 ou Windows Server 2008 R2.
2. Installez la Windows sauvegarde du serveur à partir du logiciel en ligne du Gestionnaire de serveur.
3. Pour sauvegarder l’état du système, tapez la commande suivante à l’invite de commandes :
wbadmin start systemstatebackup -backuptarget: Drive_Letter:
NOTE
Dans cette commande, Drive_Letter représente un volume critique. Le volume de démarrage et le volume
système sont des exemples de volume critique. En règle générale, ce volume critique est le lecteur C.
Références
Vue d’ensemble de la sauvegarde et de la récupération pour Windows Server 2008
Vue d’ensemble de la sauvegarde et de la récupération pour Windows Server 2008 R2
« Le document XML d’erreur VSS est trop long. hr =
0x80070018 » lorsque vous effectuez une
sauvegarde dans Windows
Cet article fournit une solution à une erreur qui se produit lorsque vous effectuez une sauvegarde dans
Windows.
Symptômes
Lorsque vous effectuez une sauvegarde dans Windows Server 2012 et les précédentes (retour à Windows
Server 2008), l’une des erreurs suivantes est consignée dans le journal des applications :

Source : VSS
Niveau : Error
Description :
Erreur du service de copie de l’ombre du volume : routine d’appel d’erreur inattendue
Le document XML est trop long. hr = 0x80070018, le programme a émis une commande, mais la longueur
de la commande est incorrecte.
Opération : rédacteur modifiant le document de sauvegarde
Contexte : exécution
Contexte : demandeur
ID d’instance writer : {14BE9B90-62D7-4A2D-B57F-53D21EAB0789}
Cause
Lorsqu’une sauvegarde basée sur vsS (Volume Shadow Copy Service) est effectuée, chacun des rédacteurs VSS
abonnés est interrogé pour obtenir une liste de composants. Le problème décrit dans la section Symptômes se
produit lorsque cette liste génère un fichier de métadonnées supérieur à la limite de taille.
Causes courantes :
Trop de fichiers dans le répertoire TemporaryInternetFiles, en C : \ Windows \ Microsoft.NET \ Framework64 \
v2.0.50727 \ TemporaryInternetFiles. Le rédacteur système atteint ainsi la taille limite du fichier de
métadonnées VSS.
Le rédacteur VSS a ajouté trop de composants à son fichier de métadonnées.
Résolution
S’il y a trop de fichiers dans TemporaryInternetFiles, back up and then delete the files from the C: \ \ Windows
Microsoft.NET \ Framework64 \ v2.0.50727 \ TemporaryInternetFiles location. Ensuite, le rédacteur système doit
être en mesure de se terminer sans erreurs.
Si vous ne pouvez pas identifier le rédacteur à l’origine de l’échec, collectez un échantillon du document de
métadonnées du rédacteur, puis examinez les composants de chaque rédacteur.
Pour collecter les métadonnées d’un rédacteur VSS, suivez les étapes suivantes :
1. À une invite de commandes d’administration, exécutez les commandes suivantes :
diskshadow /l
C:\Metadata.txt
list writers detailed
Exit
2. Une fois le fichier généré collecté, examinez et comptez les composants de chaque rédacteur.
3. Une fois l’auteur de l’application identifié, réduisez le nombre de composants jusqu’à ce que la limitation
ne soit plus dépassée.
Exemple de composants d’application
Chaque composant est représenté par les lignes entre le nom « + Composant » et la référence « - Dépendances
du composant : ». Chacun d’eux est compté comme un seul composant.
Exemple Hyper-V
« Microsoft Hyper-V rédacteur VSS :\006F792F-99EA-4A4A-A241-F8853A3B0CB6 »

- Nom : 006F792F-99EA-4A4A-A241-F8853A3B0CB6
- Chemin d’accès logique :
- Chemin d’accès complet : \ 006F792F-99EA-4A4A-A241-F8853A3B0CB6
- Légende : \ I$ hors connexion
- Type : VSS_CT_FILEGROUP [2]
- Est sélectionnable : TRUE
- Niveau supérieur : TRUE
- Avertir à la fin de la sauvegarde : FALSE
- Composants :
- File List: Path = D: \ Hyper-V \ Virtual Machines , \ Filespec = 006F792F-99EA-4A4A-A241-
F8853A3B0CB6.xml
- File List: Path = D: \ Hyper-V\Snapshots, Filespec = A544BB47-0349-4EED-ABDC-DFE66CAF2927.xml
- File List: Path = D: \ Hyper-V \ Snapshots \ A544BB47-0349-4EED-ABDC-DFE66CAF2927, Filespec = *
\ Chemins d’accès affectés par ce composant :
-D : \ Captures instantanées Hyper-V \
- D : \ Captures instantanées Hyper-V \ \ A544BB47-0349-4EED-ABDC-DFE66CAF2927
-D : \ Machines virtuelles Hyper-V \\
- Volumes affectés par ce composant :
-\\?\ Volume{9710864d-1433-11e5-93ef-806e6f6e6963} \ [D: \ ]
SQL exemple :
-Component Dependencies:SQL - + Component « SqlServerWriter: \ SQL2012 \ model »

- Nom : modèle
- Chemin d’accès logique : SQL2012
-Chemin d’accès complet \ : modèle SQL2012 \
- Légende :
- Type : VSS_CT_FILEGROUP [2]
- Est sélectionnable : TRUE
- Niveau supérieur : TRUE
- Avertir à la fin de la sauvegarde : TRUE
- Composants :
-File List: Path = C: \ Program Files \ Microsoft SQL Server \ MSSQL11. MSSQLSERVER \ MSSQL\DATA,
Filespec = model.mdf
-File List: Path = C: \ Program Files \ Microsoft SQL Server \ MSSQL11. MSSQLSERVER \ MSSQL \ DATA,
Filespec = modellog.ldf
- Chemins d’accès affectés par ce composant :
-C : \ Program Files \ Microsoft SQL Server \ MSSQL11. DONNÉES MSSQLSERVER \ \ MSSQL
- Volumes affectés par ce composant :
-\\?\ Volume{e18ba371-5b9e-11e4-9400-806e6f6e6963} \ [C: \ ]
- Dépendances des composants :
Utilisation de la fonctionnalité de sauvegarde pour
sauvegarder et restaurer des données
Cet article pas à pas décrit comment utiliser la fonctionnalité de sauvegarde pour sauvegarder et restaurer des
données sur votre ordinateur Windows Server 2003.
Résumé
Cet article est destiné aux utilisateurs qui back up and restore data, et inclut des informations sur la façon de
restaurer la configuration système et le Registre local.
Pour effectuer les procédures de cet article, vous devez être connecté en tant que membre du groupe
Administrateurs ou du groupe Opérateurs de sauvegarde.
Backing up the server

Vous pouvez sauvegarder manuellement des données ou utiliser l’Assistant Sauvegarde, qui est inclus dans la
fonctionnalité de sauvegarde. Vous pouvez back up the whole contents of the server, selected portions of the
server, or the system state data (the system configuration information).
Pour la back up selected files or folders
1. Cliquez sur Démarrer, pointez sur Tous les programmes, sur Accessoires, sur Outils système, puis cliquez
sur Sauvegarde. L’Assistant Sauvegarde ou restauration démarre.
2. Cliquez sur Mode avancé.
3. Cliquez sur l’onglet Sauvegarde.
4. Dans le menu Travail, cliquez sur Nouveau.
5. Développez le lecteur ou le dossier qui contient les éléments que vous souhaitez récupérer. Cliquez pour
cocher les cases en regard des fichiers, dossiers ou lecteurs que vous souhaitez enregistrer.
6. Dans la zone de destination sauvegarde, spécifiez la destination du nouveau travail. Pour ce faire,
faites l’une des choses suivantes :
Si vous souhaitez récupérer des fichiers et des dossiers dans un fichier, cliquez sur Fichier.
Si vous souhaitez enregistrer sur bande, cliquez sur un périphérique de bande.
NOTE
Si un périphérique de bande n’est pas connecté à votre ordinateur, File est le seul type de support de sauvegarde
disponible dans la zone de destination de sauvegarde.
7. Dans la zone Suppor t de sauvegarde ou nom de fichier, faites l’une des choses suivantes :
Si vous sauvegardez un fichier, spécifiez un chemin d’accès et un nom de fichier pour le fichier de
sauvegarde (.bkf). Vous pouvez également cliquer sur Parcourir, spécifier un nom de fichier et
l’emplacement où vous souhaitez enregistrer le fichier, puis cliquez sur Enregistrer.
Si vous enregistrez sur bande, cliquez sur la bande que vous souhaitez utiliser.
8. Dans le menu Outils, cliquez sur Options. Spécifiez les options de sauvegarde supplémentaires que vous
souhaitez dans les onglets appropriés de la page Options. Cliquez sur OK.
9. Cliquez sur Lancer la sauvegarde.
10. Si vous souhaitez définir des options de sauvegarde avancées, telles que la vérification des données ou
les compressions matérielles, cliquez sur Avancé. Spécifiez les options de votre choix, puis cliquez sur OK.
11. Examinez les paramètres de la page Informations sur le travail de sauvegarde. Spécifiez si vous souhaitez
que cette sauvegarde remplace les informations déjà présentes sur le support de destination ou ajoutez
cette sauvegarde aux informations existantes.
Pour la back up the system state (including registry settings)
Pour back up the system state (including the registry hives system, software, security, the Security Accounts
Manager (SAM) and the default user (but not HKEY_CURRENT_USER)), follow these steps:
5. Cliquez pour cocher la case État du système.
6. Cliquez pour cocher les cases en regard des autres fichiers, dossiers ou lecteurs que vous souhaitez
enregistrer.
NOTE
11. Si vous souhaitez définir des options de sauvegarde avancées, telles que la vérification des données ou
les compressions matérielles, cliquez sur Avancé. Spécifiez les options de votre choix, puis cliquez sur OK.
12. Examinez les paramètres de la page Informations sur le travail de sauvegarde. Spécifiez si vous souhaitez
que cette sauvegarde remplace les informations déjà présentes sur le support de destination ou ajoutez
cette sauvegarde aux informations existantes.
Pour planifier une sauvegarde à une heure ou une date ultérieure
Vous pouvez exécuter une opération de sauvegarde en cas de faible utilisation du système. Toutefois, ces heures
peuvent être tardives la nuit ou le week-end. Vous pouvez planifier des travaux de sauvegarde à exécuter un jour
et une heure spécifiques.
NOTE
Pour planifier une opération de sauvegarde, le service De planification des tâches doit être en cours d’exécution.
5. Développez le lecteur ou le dossier qui contient les éléments que vous souhaitez récupérer. Cliquez pour
cocher les cases en regard des fichiers, dossiers ou lecteurs que vous souhaitez enregistrer.
NOTE
10. Cliquez sur Planifier.
Si un message vous invite à enregistrer vos sélections de sauvegarde actuelles, cliquez sur OK. Dans la
page Enregistrer sous qui s’affiche, spécifiez un nom et un emplacement où vous souhaitez enregistrer la
sauvegarde, puis cliquez sur Enregistrer.
11. Dans la zone Nom du travail, tapez un nom pour le travail de sauvegarde programmé, puis cliquez sur
Propriétés.
12. Cliquez sur l’onglet Planification. Dans la zone Planifier la tâche, cliquez sur la fréquence d’exécuter le
travail de sauvegarde, puis dans la zone d’heure de démarrage, spécifiez l’heure d’exécuter la sauvegarde,
13. Dans la page Définir les informations de compte qui s’affiche, tapez le nom d’utilisateur et le mot de
passe de l’utilisateur pour lequel vous souhaitez exécuter la sauvegarde programmée, puis cliquez sur
OK.
14. Cliquez sur OK.
Le travail de sauvegarde que vous avez programmé apparaît dans le calendrier sous l’onglet Planification
des travaux. Le travail de sauvegarde programmé démarre automatiquement au moment et aux données
que vous avez spécifiés.
15. Fermez la page Utilitaire de sauvegarde.
Pour sauvegarder des données à l’aide de l’Assistant Sauvegarde
3. Sous l’onglet Bienvenue, cliquez sur Assistant Sauvegarde (avancé). L’Assistant Sauvegarde démarre.
Cliquez sur Suivant.
4. Spécifiez ce que vous souhaitez récupérer, puis cliquez sur Suivant.
5. Si vous avez sélectionné Back up selected files, drives, or network data in step 4, expand the drive
or folder that contains the items that you want to back up, click to select the check boxes next to the drive,
folder, or file that you want to back up, and then click Next.
6. Spécifiez le type de sauvegarde, la destination et le nom dans les zones appropriées, puis cliquez sur
Suivant.
NOTE
Si un lecteur de bande n’est pas connecté à votre ordinateur, File est le seul type de support de sauvegarde
disponible dans la zone Sélectionner le type de sauvegarde.
7. Examinez les paramètres qui apparaissent dans la page Fin de l’Assistant Sauvegarde. Si vous
souhaitez spécifier des options de sauvegarde avancées, cliquez sur Options avancées, spécifiez les
options de votre choix, puis cliquez sur OK.
8. Cliquez sur Terminer.
Restauration des données sur le serveur

Si une perte de données se produit, vous pouvez restaurer vos données de sauvegarde manuellement ou à
l’aide de l’Assistant Restauration, qui est inclus dans la fonctionnalité de sauvegarde.
Pour restaurer des fichiers sélectionnés à partir d’un fichier ou d’une bande
3. Cliquez sur l’onglet Restaurer et gérer les médias.
4. Cliquez sur le média à restaurer, puis cochez les cases en regard des lecteurs, dossiers ou fichiers à
restaurer.
5. Dans la zone Restaurer le fichier, spécifiez l’emplacement où vous souhaitez restaurer les fichiers en
faisant l’une des choses suivantes :
Si vous souhaitez restaurer les fichiers ou dossiers à l’emplacement où ils se sont situés lorsque
vous avez restauré les données, cliquez sur Emplacement d’origine, puis allez à l’étape 7.
Si vous souhaitez restaurer les fichiers ou dossiers dans un nouvel emplacement, cliquez sur
Autre emplacement.
Cette option conserve la structure de dossiers des données de la backed-up.
Si vous souhaitez restaurer les fichiers et dossiers à un emplacement unique, cliquez sur Dossier
unique.
6. Si vous avez sélectionné un autre emplacement ou un dossier unique, tapez l’emplacement dans lequel
vous souhaitez restaurer les données, ou cliquez sur Parcourir et sélectionner l’emplacement, puis cliquez
sur OK.
7. Dans le menu Outils, cliquez sur Options. Cliquez sur l’onglet Restaurer, spécifiez l’option de restauration
de votre choix, puis cliquez sur OK.
8. Cliquez sur Lancer la restauration.
9. Dans la page Confirmer la restauration qui s’affiche, cliquez sur Avancé si vous souhaitez définir des
options de restauration avancées, puis cliquez sur OK.
10. Cliquez sur OK pour démarrer l’opération de restauration.
Pour restaurer les données d’état système (y compris les informations de Registre )
3. Cliquez sur l’onglet Restaurer et gérer les médias.
4. Dans la zone Éléments à restaurer, développez le média à restaurer, puis cliquez pour cocher la case
État du système.
5. Cliquez pour cocher les cases en regard des autres lecteurs, dossiers ou fichiers à restaurer.
6. Dans la zone Restaurer le fichier, spécifiez l’emplacement où vous souhaitez restaurer les fichiers en
faisant l’une des choses suivantes :
Si vous souhaitez restaurer les fichiers ou dossiers à l’emplacement où ils se sont situés lorsque vous
avez restauré les données, cliquez sur Emplacement d’origine, puis allez à l’étape 8.
Si vous souhaitez restaurer les fichiers ou dossiers dans un nouvel emplacement, cliquez sur Autre
emplacement. Cette option conserve la structure de dossiers des données de la backed-up.
Si vous souhaitez restaurer les fichiers et dossiers à un emplacement unique, cliquez sur Dossier
unique.
NOTE
Si vous ne désignez pas un autre emplacement pour les données restaurées, l’opération de restauration efface les
données d’état système actuelles et les remplace par les informations que vous restituerez.
7. Si vous avez sélectionné un autre emplacement ou un dossier unique, tapez l’emplacement dans lequel
vous souhaitez restaurer les données, ou cliquez sur Parcourir et sélectionnez l’emplacement.
8. Cliquez sur Lancer la restauration.
9. Dans la page Confirmer la restauration qui s’affiche, cliquez sur Avancé si vous souhaitez définir des
options de restauration avancées, puis cliquez sur OK.
10. Cliquez sur OK pour démarrer l’opération de restauration.
Pour restaurer des données restaurées à l’aide de l’Assistant Restauration
1. Cliquez sur Démarrer, pointez sur Tous les programmes, sur Accessoires, sur Outils système, puis cliquez sur
Sauvegarde. L’Assistant Sauvegarde ou restauration démarre.
3. Sous l’onglet Bienvenue, cliquez sur Assistant Restauration (avancé). L’Assistant Restauration démarre.
Cliquez sur Suivant.
4. Dans la zone Éléments à restaurer, développez le média à restaurer, cliquez pour cocher les cases en regard
des lecteurs, dossiers ou fichiers à restaurer, puis cliquez sur Suivant.
5. Examinez les paramètres qui apparaissent dans la page Fin de l’Assistant Restauration. Si vous souhaitez
spécifier des options de sauvegarde avancées, cliquez sur Options avancées, spécifiez les options de votre
choix, puis cliquez sur OK.
6. Cliquez sur Terminer.

Vous ne pouvez pas back up ou restore data
Vous devez être membre du groupe Administrateurs ou du groupe Opérateurs de sauvegarde sur l’ordinateur
local pour sauvegarder ou restaurer des données.
Vous ne pouvez pas planifier une opération de sauvegarde
Le service De planification des tâches doit être en cours d’exécution avant de pouvoir planifier une sauvegarde.
Si le service De planification des tâches n’est pas déjà en cours d’exécution, suivez les étapes suivantes pour le
démarrer :
2. Dans la zone Ouvrir, tapez cmd, puis cliquez sur OK.
3. À l’invite de commandes, tapez net start schedule, puis appuyez sur Entrée.
Aucun rédacteur VSS n’est répertorié lorsque vous
exécutez la commande vssadmin list writers dans
Windows Server
Cet article permet de résoudre un problème où aucun rédacteur VSS n’est répertorié lorsque vous exécutez la
commande et que les événements vssadmin list writers sont enregistrés.
Symptômes
Lorsque vous exécutez la commande dans Windows Server, aucun rédacteur vssadmin list writers VSS n’est
répertorié. En outre, les événements suivants sont consignés dans le journal des applications :

Source : VSS
Niveau : Error
Description :
Erreur du service de copie de l’ombre du volume : un composant critique requis par le service Volume
Shadow Copy n’est pas enregistré. Cela peut se produire si une erreur s’est produite lors
Windows’installation ou pendant l’installation d’un fournisseur de shadow copy. L’erreur renvoyée par
CoCreateInstance sur la classe avec CLSID {faf53cc4-bd73-4e36-83f1-2b23f46e513e} et le nom VSSEvent
est [0x80040154, classe non enregistrée].

Source : VSS
Niveau : Erreur
Description :
Erreur du service de copie de l’ombre du volume : erreur inattendue appelant la routine CoCreateInstance. hr
= 0x80040154, class not registered.
Si vous ouvrez le Windows server backup, vous recevez le message d’erreur suivant :
Une erreur fatale s’est produite lors d’Windows de sauvegarde serveur en ligne (Wbadmin.msc).
Détails de l’erreur :
Erreur inconnue (0x80042302).
Fermez Wbadmin.msc, puis redémarrez-le
Cause
Ce problème se produit car le chemin d’accès au Registre du Eventcls.dll fichier est incorrect.
Résolution
1. Cliquez sur Démarrer, tapez regedit dans la zone Rechercher des programmes et des fichiers, puis
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\\{26c409cc-ae86-11d1-b616-
00805fc79216}\EventClasses\\{FAF53CC4-BD73-4E36-83F1-2B23F46E513E}-{00000000-0000-0000-0000-
000000000000}-{00000000-0000-0000-0000-000000000000}
3. Double-cliquez sur la valeur de Registre TypeLib.

4. Dans la zone Données de la valeur, tapez %systemroot% \ system32 \EVENTCLS.DLL, puis cliquez sur
OK .
6. Cliquez sur Démarrer, tapez services.msc dans la zone Rechercher des programmes et des fichiers, puis
7. Cliquez avec le bouton droit sur les services suivants, un par un. Cliquez sur Redémarrer pour chaque
service.
Système d'événements COM +
Cliché instantané des volumes
8. Quittez le logiciel en snap-in Services.
9. Ouvrez une invite de commandes avec élévation de niveau élevé, tapez vssadmin list writers, puis
10. Vérifiez que les rédacteurs VSS sont désormais répertoriés.
Codes de retour utilisés par l’utilitaire Robocopy
dans Windows Server 2008 ou Windows Server
2008 R2
Cet article décrit les codes de retour utilisés par l’utilitaire Robocopy dans Windows Server 2008 ou Windows
Server 2008 R2.
S’applique à : Windows Server 2008 R2 Service Pack 1, Windows 7 Service Pack 1, Windows Server 2012 R2
Introduction
Le tableau suivant répertorie et décrit les codes de retour utilisés par l’utilitaire Robocopy.
VA L EUR DESC RIP T IO N
0 Aucun fichier n’a été copié. Aucun échec n’a été rencontré.
Aucun fichier n’a été incompatible. Les fichiers existent déjà
dans le répertoire de destination ; l’opération de copie a
donc été ignorée.
1 Tous les fichiers ont été copiés avec succès.
2 Il existe des fichiers supplémentaires dans le répertoire de

destination qui ne sont pas présents dans le répertoire
source. Aucun fichier n’a été copié.
3 Certains fichiers ont été copiés. Des fichiers supplémentaires

étaient présents. Aucun échec n’a été rencontré.
5 Certains fichiers ont été copiés. Certains fichiers étaient

incompatibles. Aucun échec n’a été rencontré.
6 Des fichiers supplémentaires et des fichiers incompatibles

existent. Aucun fichier n’a été copié et aucun échec n’a été
rencontré. Cela signifie que les fichiers existent déjà dans le
répertoire de destination.
7 Des fichiers ont été copiés, une incompatibilité de fichiers

était présente et des fichiers supplémentaires étaient
présents.
8 Plusieurs fichiers n’ont pas été copiés.
NOTE
Toute valeur supérieure ou égale à 8 indique qu’il y a eu au moins un échec pendant l’opération de copie.
Pour plus d’informations sur l’utilisation de l’utilitaire Robocopy, ouvrez une invite de commandes, tapez la
commande suivante, puis appuyez sur Entrée :
Robocopy /?
Le processus de sauvegarde du serveur échoue et
les erreurs « 0x80070005 » sont consignées dans
Windows Server 2012 Essentials
Cet article décrit un problème dans lequel une erreur d’accès [0x80070005] se produit au cours d’un
processus de sauvegarde du serveur dans Windows Server 2012 Essentials.
Symptômes
Supposons que vous essayez de sauvegarder un serveur qui s’exécute Windows Server 2012 Essentials à l’aide
de la fonctionnalité de sauvegarde Windows Server. Toutefois, l’opération de sauvegarde ne se termine pas et
l’événement suivant est consigné dans le journal des applications :
Description :
L’opération de sauvegarde qui a commencé à « ?2012?-?03?-?31T07:00:05.748719600Z » a rencontré des
erreurs pour le ou les volume(s) F:'. Journal des fichiers qui n’ont pas été correctement backed '
C:\Windows\Logs\WindowsServerBackup\Backup_Error-31-03-2012_02-00-05.log'.
Si vous ouvrez le fichier journal qui est décrit dans l’événement, vous voyez des journaux qui ressemblent à ce
qui suit :
Erreur lors de la sauvegarde de F : $ $ Étendre RmMetadata TxfLog\ pendant l’écriture : Erreur $

[0x80070005] Accès refusé.
Erreur lors de la sauvegarde de F : $ Étendre $ RmMetadata $ TxfLog TxfLog.blf pendant l’écriture : l’accès à
l’erreur $ [0x80070005] est refusé.
Cause
Ce problème se produit lorsqu’un lecteur qui utilise le système de fichiers NTFS est configuré pour la
sauvegarde au niveau du fichier. Étant donné que $RmMetaData répertoire est des données internes NTFS et
n’est pas accessible par un autre processus, ce problème se produit.
Méthode 1
Configurez la stratégie de sauvegarde du serveur sur le lecteur affecté en tant que sauvegarde au niveau du
bloc. Après cela, l’intégralité du volume est sélectionnée pour la sauvegarde.
Méthode 2
Définissez une clé de Registre pour exclure les fichiers mentionnés dans l’événement des sauvegardes au niveau
des fichiers. Ces fichiers sont utilisés par NTFS et peuvent être ignorés en toute sécurité.
IMPORTANT
1. Dans l’Éditeur du Registre, recherchez la sous-clé de Registre suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup
2. Right-Click FilesNotToBackup, pointez sur Nouveau, puis cliquez sur Valeur multi string .
3. Tapez IgnoreNTFS, puis appuyez sur Entrée.
4. Cliquez avec le bouton droit sur IgnoreNTFS, puis cliquez sur Modifier.
5. Dans la zone de données Valeur, \ tapez $Extend \ * /s.
6. Cliquez sur OK, puis fermez l’Éditeur du Registre.
Raison de l’ID d’événement srv du journal des
événements système : 2012 : lors de la transmission
ou de la réception de données, le serveur a
rencontré une erreur réseau
Cet article traite de l’ID d’événement srv du journal des événements système 2012.
Résumé
Vous avez un serveur de Windows Server 2012 basé sur un serveur de fichiers
Windows Les ordinateurs clients server 2003, Windows Server 2003 R2 ou Microsoft Windows XP
Professional accèdent au serveur de fichiers avec le protocole SMB v1
ou tout autre ordinateur basé sur le protocole SMB v1 avec une implémentation CIFS tierce accède au
serveur de fichiers
Dans ce scénario, vous voyez plusieurs événements avec l’ID Srv source 2012 dans le journal des événements
système :

Source : srv
Date : <DateTime>
Utilisateur : N/A
Ordinateur : FILEsrv.fqdn
Description :
Lors de la transmission ou de la réception de données, le serveur a rencontré une erreur réseau. Des erreurs
occasionnelles sont attendues, mais de grandes quantités indiquent une erreur possible dans votre
configuration réseau. Le code d’état d’erreur se trouve dans les données renvoyées (formatées sous forme
de mots) et peut vous faire pointer vers le problème.
<EventData>
<Data>\Device\LanmanServer</Data>
<Binary>0000040001002C000000000DC070080000000000840100C0000000000000000000000000000
000340600000</Binary>
</EventData>
En mots
0000: 00040000 002C0001 00000000 800007DC
0008: 00000000 C0000184 00000000 0000000
0010: 00000000 00000000 00000634
Explication de ces « Mots » consignés dans cet événement :

800007DC = EVENT_SRV_NETWORK_ERROR,
C0000184 = STATUS_INVALID_DEVICE_STATE, l’appareil n’est pas dans un état valide pour effectuer cette
demande. 00000634 hexadécimal = 1 588 décimal, cela pointe vers la ligne 1588 dans Windows Server 2012
code pour les clients de niveau bas.
Ce nombre dépend du système d’exploitation, du Service Pack et éventuellement SRV.SYS niveau de correctif.
Forum Aux Questions (FAQ) :
----------------------------------
Srv 2012 est-il un indicateur d’une erreur grave ?
Non, il s’agit d’un événement de type AVERTISSEMENT, généralement vous pouvez l’ignorer. Voir ci-dessous
pour certains scénarios classiques, où un tel événement est attendu.
Les administrateurs doivent simplement ignorer l’avertissement.
À quoi doit ressembler une communication SMB normale ?
Conformément aux spécifications du protocole CIFS ([MS-CIFS]: Common Internet File System (CIFS) Protocol)
NÉGOCIER LE DIALECTE - CONFIGURATION DE LA SESSION - CONNEXION À L’ARBORESCENCE -
DÉCONNEXION DE L’ARBORESCENCE - DÉCONNEXION
Après avoir mis à niveau notre serveur de fichiers vers Windows Server 2012 nous rencontrons cet événement
plus souvent, pourquoi ?
vous avez un environnement avec de nombreux clients SMB1 de niveau bas comme Windows XP ou
Tentatives d’ouverture de session infructueuses (réponse DE CONFIGURATION DE SESSION avec état
d’erreur) suivies du résultat TCP FIN dans l’événement 2012.
Ces clients ont tendance à terminer leur dernière session SMB avec une commande LOGOFF et TREE
DISCONNEcT SMB, puis à terminer la session de transport normalement avec une fin TCP.
Cette séquence de commandes SMB n’est pas entièrement conforme CIFS, voir ci-dessus, ce qui a pour
résultat l’événement 2012.
vous avez un environnement avec des clients SMB1 de niveau UNIX SAVE/UNIX/MAC.
Ces clients terminent souvent des sessions SMB non conformes au CIFS (en omettant une commande
LOGOFF), ce qui entraîne l’événement 2012.
Les clients de niveau bas avec dossiers redirigés sur le serveur de fichiers Windows Server 2012 sont
déconnectés du réseau sans arrêt approprié.
Le serveur de fichiers envoie dans ce cas des paquets KeepAlive TCP aux clients inactifs et réinitialise la
connexion de transport TCP en l’absence de réponse du client.
Les clients SMB1 rencontrent des problèmes réseau (le serveur de fichiers ne répond pas à leur
commande SMB en suspens dans un délai d’une minute (SessTimeout = 60 sec), donc le client n’envoie
pas de logoFF, mais met fin à la session TCP avec RESET, puis établit une nouvelle session TCP/SMB avec
un nouveau circuit virtuel (VcNumber : 0).
Le serveur de fichiers n’était pas au courant du problème réseau des clients et nettoyagee l’ancienne
session cliente dès qu’il détecte la même ADRESSE IP du client SMB1 avec SESSION SETUP (VcNumber:
0) qui arrive. (Cela peut se produire dans le scénario NAT pour différents clients, ce qui entraîne
également la même adresse IP dans le sous-réseau du serveur de fichiers)
Pour plus d’informations sur cette rubrique, cliquez sur le numéro d’article suivant pour afficher l’article sur
microsoft Web :
[MS-CIFS]: Protocole CIFS (Common Internet File System)
lorsqu’une imagePath non valide est spécifiée pour
les services
Cet article décrit un problème dans lequel la sauvegarde de l’état du système échoue lorsqu’un imagePath non
valide est spécifié pour les services.
Symptôme
Windows La sauvegarde de l’état du système Server 2008 peut échouer avec l’erreur suivante :
Résumé de la sauvegarde :
La sauvegarde de l’état du système a échoué [ <date> <time> ]
Journal des fichiers correctement backed up 'C:\Windows\Logs\WindowsServerBackup\SystemStateBackup
<date> <time> .log'
Journal des fichiers pour lesquels la sauvegarde a échoué
'C:\Windows\Logs\WindowsServerBackup\SystemStateBackup_Error <date> <time> .log'
Échec de l’éumération des fichiers.
Le nom de fichier, le nom du répertoire ou la syntaxe de l’étiquette de volume est incorrect.
Dans le journal des événements, les erreurs suivantes sont consignées :

Source : Microsoft-Windows-Backup
Description : La sauvegarde a démarré à l’échec avec le code d’erreur suivant 2155348237 ' (Échec de <date
time> l’éumération des fichiers). Veuillez réexécuter la sauvegarde une fois le problème résolu.
Nom du journal : Microsoft-Windows-Backup

ID d'événement : 5
Description :
La sauvegarde a démarré à l’échec avec le code d’erreur <date time> 2155348237' suivant.
Cause
La sauvegarde de l’état du système échoue car l’image ImagePath spécifiée par un service ne peut pas être
sauvegarde. Une inspection plus approfondie du journal système indique qu’un service ne démarre pas et que
vous recevez une erreur telle que la suivante.

Description :
Le service n’a pas réussi à démarrer en raison de l’erreur suivante : le système <servicename> ne peut pas
trouver le chemin d’accès spécifié.
La révision de l’imagePath du service défaillant reflète un chemin d’accès ou un nom de fichier non valide.
Résolution
1. Examinez le journal système pour déterminer le service qui ne démarre pas.
2. Contactez le fournisseur de logiciels des services pour connaître les problèmes connus et le package
d’installation mis à jour qui peuvent résoudre le problème ImagePath incorrect.
3. Sélectionnez l’une des options suivantes :
Option 1 : Désinstallez le logiciel lié au service problématique. Dès qu’elle est supprimée, redémarrez la
Option 2 : corrigez ImagePath pour qu’il utilise regedit pour qu’il utilise un chemin d’accès et un nom de
fichier valides.
NOTE
Étant donné que chaque service aura un imagePath unique, vous de devez contacter le fournisseur de logiciels si le
chemin d’accès et le nom de fichier corrects ne sont pas évidents.
NOTE
La publication de blog suivante inclut un exemple de script qui peut être utilisé pour identifier les instructions ImagePath
défectueux. Ce script est fourni tel quelle et sans garantie :
https://blogs.technet.com/b/askcore/archive/2010/06/18/ps-script-for-blog-enumeration-of-the-files-
failed.aspx
Les ID d’événement 12290 et 16387 sont enregistrés
lorsque la sauvegarde de l’état système échoue sur
un ordinateur Windows Server 2008
Cet article fournit une solution à un problème dans lequel les ID d’événement 12290 et 16387 sont enregistrés
en cas d’échec de la sauvegarde de l’état du système.
Symptômes
Lorsque vous essayez d’effectuer une sauvegarde de récupération automatique du système (ASR) d’état système
sur un ordinateur basé sur Windows Server 2008, la sauvegarde échoue et les messages d’erreur semblables à
ce qui suit sont consignés dans le journal des applications.
Cause
Ce problème se produit si la partition EISA active sur l’ordinateur est une partition masquée. Le rédacteur de la
asr dans Windows Server 2008 ne prend pas en charge les partitions actives masquées. Une partition EISA
masquée peut être marquée comme active lorsqu’une nouvelle installation du système d’exploitation est
terminée sur un nouvel ordinateur sans avoir effectué au premier abord le programme OOBE (Out Of Box
Experience) initial du fabricant ou sans utiliser au départ un utilitaire de disque pour effacer le disque.
Ce problème ne se produit pas sur un nouvel ordinateur si le programme OOBE du fabricant de l’ordinateur a
été exécuté avant l’installation Windows. Dans ce scénario, une fois le programme OOBE terminé, la partition
masquée est marquée comme inactive. Vous pouvez ensuite installer Windows et la sauvegarde s’est terminée
correctement.
Résolution
1. Cliquez sur Démarrer, pointez sur Outils d’administration, cliquez sur Gestion de l’ordinateur, puis
sur Gestion des disques.
2. Cliquez sur le volume qui contient l’installation Windows Server 2008 existante. En règle générale, il
s’agit du lecteur C.
3. Cliquez avec le bouton droit sur le volume, puis cliquez sur Marquer la par tition comme étant
active.
4. Cliquez sur Oui pour confirmer l’action.
NOTE
Dans ce scénario, l’installation existante de Windows ne peut pas démarrer tant que les étapes restantes ne sont
pas terminées.
5. Fermez la gestion de l’ordinateur.
6. Insérez Windows DVD d’installation server 2008 dans le lecteur de DVD, puis redémarrez l’ordinateur.
7. Sélectionnez les options suivantes, puis cliquez sur Suivant :
Langue d’installation
Format d’heure et de devise
Disposition du clavier
8. Cliquez sur Réparer votre ordinateur .
9. Dans la boîte de dialogue Options de récupération système, cliquez sur le système d’exploitation que
vous souhaitez réparer, puis cliquez sur Suivant .
10. Sous Choisir un outil de récupération, cliquez sur Invite de commandes.
copy c:\windows\boot\PCAT\bootmgr c:\bootmgr
12. Tapez la commande suivante, puis appuyez sur ENTRÉE :
Attrib +h +s c:\bootmgr
13. Tapez la commande suivante, puis appuyez sur Entrée :
Bootrec /fixboot
Bootrec /rebuildbcd
15. Appuyez sur Y lorsque vous êtes invité à ajouter l’installation à la liste de démarrage.
17. Essayez à nouveau la sauvegarde de la asr de l’état système complet. Confirmez que la sauvegarde a
réussi.
Si le système d’exploitation est installé sur une partition qui ne se trouve pas sur le même disque que la
partition EISA active masquée, vous devez marquer une partition comme active qui se trouve sur le même
lecteur que la partition EISA. Si aucune autre partition n’existe sur le même lecteur que la partition EISA, vous
devez créer une partition et la marquer comme active.
Windows Échec de l’ouverture de la MMC de
sauvegarde du serveur
Cet article fournit une solution à une erreur qui se produit lorsque vous lancez la sauvegarde Windows Server
sur Windows Server 2008.
Symptômes
Lors du lancement de Windows Server Backup sur Windows Server 2008, la MMC s’ouvre avec le message
suivant :
Une erreur fatale s’est produite lors d’une Windows de sauvegarde du serveur.
Détails de l’erreur : le système ne peut pas trouver le chemin d’accès spécifié.
Fermez Windows sauvegarde du serveur, puis redémarrez-la.
Cause
Le dossier de stratégie de sauvegarde programmée dans le programmeur des tâches est manquant ou rompu.
Lors du démarrage des requêtes en snap-in wbadmin.msc, les tâches programmées entraînent une erreur
lorsqu’elles sont manquantes ou rompues.
Résolution
Supprimez les tâches programmées que le logiciel en snap-in MMC tente de lire. Une fois supprimés, de
nouvelles planifications peuvent être créées.
Pour supprimer les tâches programmées, ouvrez une invite de commandes avec élévation de élévation de
niveaux et exécutez la commande suivante :
wbadmin disable backup
NOTE
Si vous arrêtez les sauvegardes prévues, les disques dans lequel vous avez stocké les sauvegardes ne peuvent pas être
utilisés à nouveau pour stocker les sauvegardes tant qu’elles ne sont pas reformatés (afin que toutes les sauvegardes
existantes soient supprimées).
Conseils de dépannage de l’altération des données
et des erreurs de disque
L’altération des données et les erreurs de disque couvrent différents domaines, tels que les problèmes d’accès à
un lecteur, l’altération des lecteurs et la lenteur des performances.
Les ID d’événement suivants indiquent qu’il y a une altération des données ou une erreur de disque :
L’opération d’E/S à l’adresse de bloc logique 123456 pour Disk 2 a été retentée.
La réinitialisation à l’appareil, \Device\RaidPort1, a été émise.
Le disque 2 a été supprimé de surprise.
La structure du système de fichiers sur le disque est endommagée et inutilisable. Exécutez l’utilitaire
chkdsk sur le volume.
Volume C : (\Device\HarddiskVolume3) doit être mis hors connexion pour effectuer un Chkdsk
complet. Exécutez « CHKDSK /F » localement via la ligne de commande ou exécutez « REPAIR-
VOLUME <drive:>» localement ou à distance via PowerShell.

NOTE
Cet article décrit les commandes qui doivent être exécutées à une invite de commandes avec élévation de privilèges.
Dans le journal des événements système, recherchez NTFS (New Technology File System) et les
avertissements et erreurs liés au disque. Par exemple, ID d’événement 55, 153 ou 98.
Exécutez la chkdsk /scan commande et vérifiez le résultat.
NOTE
La chkdsk /scan commande est en lecture seule.
Interrogez un lecteur pour obtenir des informations de volume spécifiques à NTFS en exécutant la
commande suivante :
fsutil fsinfo ntfsinfo <rootpath>:
NOTE
L’espace réservé <rootpath> représente la lettre de lecteur du lecteur racine.
Exécutez la fsutil dirty query <volumepath>: commande pour vérifier si le volume est incorrect.
NOTE
L’espace réservé <volumepath> représente la lettre de lecteur.
Pour un volume dont le système de fichiers est NTFS, exécutez la chkdsk /f /r commande si le
volume est incorrect. La chkdsk /F /R commande a besoin d’un temps d’arrêt, car le disque n’est
pas accessible.
Pour un volume dont le système de fichiers est Resilient File System (ReFS), l’altération du disque
est réparée automatiquement.
Si l’utilitaire « chkdsk » ne corrige pas les erreurs de disque, effectuez une restauration à partir d’une
sauvegarde.
Exécutez une validation de stockage pour vérifier s’il existe des erreurs liées au stockage.
Supprimez les disques du cluster et vérifiez le niveau du système d’exploitation.
Exécutez la chkdsk /f commande sur tous les volumes pour lequel l’événement est enregistré.
Mettez à jour les pilotes de stockage ou le microprogramme tiers.
Si le problème persiste, essayez les méthodes suivantes :
Désinstallez tous les logiciels de gestion de disque tiers (par exemple, Diskeeper).
Supprimez ou mettez à jour les pilotes de filtre.
Contactez le fournisseur de matériel et exécutez les diagnostics matériels pour éviter tout problème
matériel.
Contactez le fournisseur de stockage pour vérifier la configuration multipathing.
Mettez à jour le port SCSI ou les pilotes du contrôleur RAID.
Basculement vers différents types de pilotes. Par exemple, les pilotes de contrôleur RAID ou les pilotes
monolithiques.
Mettez à jour les pilotes HBA (Host Bud Adapter).
Mettez à jour les pilotes multipathing des modules spécifiques à l’appareil (DSM).
Mettez à jour le microprogramme HBA.
Résolution des problèmes liés à l’ID d’événement 153

L’ID d’événement 153 indique qu’il y a une erreur avec le sous-système de stockage. L’ID d’événement 153 est
similaire à l’ID d’événement 129, mais la différence est que l’ID d’événement 129 est journalisé lorsque le pilote
Storport expire une demande sur le disque et que l’ID d’événement 153 est journalisé lorsque le pilote storport
miniport expire une demande. Le pilote miniport peut également être appelé pilote d’adaptateur ou pilote HBA,
qui est généralement écrit par le fournisseur de matériel.
Si l’ID d’événement 153 ou l’ID d’événement 129 est journalisé, le délai d’expiration des E/S de disque est la
cause courante, car le contrôleur de stockage ne peut pas gérer la charge. Dans ce cas, l’opération d’E/S expire et
le pilote miniport (d’un fournisseur) renvoie les messages au pilote Storport (le dernier pilote de stockage
Microsoft dans la pile). Ensuite, le pilote Storport traduit les informations et consigne l’événement dans le
observateur d'événements.
Étant donné que le pilote miniport dispose d’une connaissance suffisante de l’environnement d’exécution de la
demande, certains pilotes miniports délaiisent la demande eux-mêmes au lieu de laisser le pilote Storport gérer
le minutage de la demande. Le pilote miniport peut abandonner une demande individuelle et retourner une
erreur, tandis que le pilote Storport réinitialise le lecteur après un délai d’expiration. La réinitialisation du lecteur
perturbe le sous-système d’E/S et peut ne pas être nécessaire si une seule requête a expiré. Le pilote miniport
renvoie l’erreur au pilote de classe qui enregistre l’ID d’événement 153 et retente la demande.
Voici un exemple d’ID d’événement 153 :
Log Name: System

Source: disk
Event ID: 153
Level: Warning
Description: The IO operation at logical block address 123456 for Disk 2 was retried.
Cet événement indique qu’une demande a échoué et a été retentée par le pilote de classe. Aucun message
d’erreur n’a été consigné dans cette situation, car le pilote Storport n’a pas expiré la demande. L’absence de
messages a entraîné une confusion lors de la résolution des erreurs de disque, car il n’y avait aucune preuve de
l’erreur.
Sous l’onglet Détails du journal des événements , les informations détaillées indiquent l’erreur qui a provoqué
la nouvelle tentative et indiquent si la demande était une demande de lecture ou d’écriture. Par exemple :
0000: 0004010F 002C0003 00000000 80040099

0010: 00000000 00000000 00000000 00000000
0020: 00000000 00000000 28090000
in bytes
0000: 0F 01 04 00 03 00 2C 00 ......,.
0008: 00 00 00 00 99 00 04 80 ......
0010: 00 00 00 00 00 00 00 00 ........
0018: 00 00 00 00 00 00 00 00 ........
0020: 00 00 00 00 00 00 00 00 ........
0028: 00 00 09 28 ...*
Dans cet exemple, le décalage d’octets 29 affiche l’état SCSI, l’offset d’octet 30 affiche l’état du bloc de requête
SCSI (SRB) à l’origine de la nouvelle tentative, et l’offset d’octet 31 affiche la commande SCSI en cours de
nouvelle tentative. Dans ce cas, l’état SCSI est 00 (), l’état SRB est 09 ( SRB_STATUS_TIMEOUT ) et la commande
SCSI ( 28``SCSIOP_READ ). SCSISTAT_GOOD
Voici les commandes SCSI les plus courantes :
SCSIOP_READ - 0x28
SCSIOP_WRITE - 0x2A
Consultez scsi.h pour obtenir la liste des opérations et des états SCSI.
Voici les états SRB les plus courants :
SRB_STATUS_TIMEOUT - 0x09
SRB_STATUS_BUS_RESET - 0x0E
SRB_STATUS_COMMAND_TIMEOUT - 0x0B
Consultez srb.h pour obtenir la liste des états SRB.
NOTE
Les erreurs de délai d’expiration ( SRB_STATUS_TIMEOUT ou SRB_STATUS_COMMAND_TIMEOUT ) indiquent qu’une
demande est expirée dans l’adaptateur. Une demande a été envoyée au lecteur et aucune réponse n’a été envoyée
dans le délai d’expiration.
L’erreur de réinitialisation du bus ( SRB_STATUS_BUS_RESET ) indique que l’appareil a été réinitialisé et que la
demande est retentée en raison de la réinitialisation, car toutes les demandes incomplètes sont abandonnées
lorsqu’un lecteur reçoit une réinitialisation.
Un administrateur doit vérifier l’intégrité du sous-système de disque. Bien qu’un délai d’expiration occasionnel
puisse faire partie du fonctionnement normal d’un système, les demandes de nouvelles tentatives fréquentes
indiquent un problème de performances avec le stockage qui doit être résolu.
Étant donné que le problème se trouve normalement en dehors du système d’exploitation, vérifiez les causes
courantes suivantes :
Un certain type de limitation est configuré, comme les limitations d’E/S. Parfois, Stockage contrôle d’E/S
dans VMware provoque ce problème.
Trop de lecteurs avec une charge élevée se trouvent sur le même contrôleur de stockage. Par conséquent,
les lecteurs doivent être répartis entre différents contrôleurs.
Si l’E/S multipath (MPIO) est configurée, un seul câble ou une carte réseau endommagée peut provoquer
des problèmes avec iSCSI.

L’ID d’événement 129 est enregistré avec le nom du pilote de l’adaptateur de stockage (HBA) comme source. Le
pilote Storport (Storport.sys) consigne cet événement lorsqu’il détecte qu’une demande est expirée. Le nom du
pilote HBA est utilisé dans l’événement, car il s’agit du pilote miniport associé au pilote Storport.
Event Type: Warning

Event Source: <HBA_Name>
Event ID: 129
Computer: <Computer_Name>
Description: Reset to device, \Device\RaidPort1, was issued.
Informations sur Windows architecture de pile d’E/S

Windows opération d’E/S utilise une architecture en couches où les pilotes d’appareil se trouvent sur une pile
d’appareils. Dans un modèle de base, le haut de la pile est le système de fichiers. La suivante est le gestionnaire
de volumes, suivi du pilote de disque. Les pilotes de port et de miniport se trouvent en bas de la pile de
l’appareil. Lorsqu’une demande d’E/S atteint le système de fichiers, elle prend le numéro de bloc du fichier et la
traduit en décalage dans le volume. Ensuite, le gestionnaire de volumes traduit le décalage de volume en
nombre de blocs sur le disque et transmet la demande au pilote de disque. Lorsque la requête atteint le pilote de
disque, elle crée un bloc de descripteur de commande (CDB) et l’envoie à l’appareil SCSI. Le pilote de disque
incorpore la base de données CDB dans la structure SCSI_REQUEST_BLOCK (SRB). Ce SRB est envoyé au pilote
de port dans le cadre du paquet de demande d’E/S (IRP).
Le pilote de port effectue la majeure partie du traitement des demandes. Il existe différents pilotes de port en
fonction de l’architecture. Par exemple, le pilote de port ATA (Ataport.sys) et le pilote de port SCSI (Storport.sys).
Voici quelques responsabilités d’un pilote de port :
Fourniture de services de minutage pour les demandes
Application de la profondeur de file d’attente pour s’assurer qu’un appareil n’a pas plus de demandes
qu’il ne peut gérer
Création de tableaux « scatter » et « gather » pour les mémoires tampons de données
Les interfaces du pilote de port avec le pilote miniport, et le pilote miniport est conçu par le fournisseur de
matériel pour fonctionner avec un adaptateur spécifique. Il est chargé de prendre les demandes du pilote de
port et de les envoyer au numéro d’unité logique (LUN) cible. Le pilote de port appelle la HwStorStartIo()
fonction pour envoyer des demandes au pilote miniport, et le pilote miniport envoie les demandes au pilote
HBA afin qu’elles puissent être envoyées via le support physique (Fibre ou Ethernet) au numéro d’unité logique.
Une fois la demande terminée, le pilote miniport appelle la StorPortNotification() fonction avec le
NotificationType paramètre avec une valeur définie sur RequestComplete , ainsi qu’un pointeur vers le SRB
terminé.
Lorsqu’une demande est envoyée au pilote miniport, le pilote Storport place la demande dans une file d’attente
en attente et elle est chronométrée. Une fois la demande terminée, elle est supprimée de cette file d’attente.
Le mécanisme de minutage est simple. Il existe un minuteur par unité logique, et il est initialisé pour -1 .
Lorsque la première requête est envoyée au pilote miniport, le minuteur est défini sur la valeur de délai
d’expiration dans la SRB. La valeur du délai d’expiration du disque est un paramètre réglable qui se trouve sous
la clé de Registre suivante :
HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue
Certains fournisseurs de matériel régleront cette valeur pour qu’elle corresponde au mieux à leur matériel. Ne
modifiez pas cette valeur sans l’aide de votre fournisseur de stockage.
Le minuteur est décrémenté une fois par seconde. Lorsqu’une demande est terminée, le minuteur est actualisé
avec la valeur de délai d’expiration de la demande de tête dans la file d’attente en attente. Par conséquent, le
minuteur ne passe jamais à zéro tant que les requêtes sont terminées. Si le minuteur passe à zéro, cela signifie
que l’appareil a cessé de répondre. Par exemple, lorsque le pilote Storport enregistre l’ID d’événement 129, le
pilote Storport doit prendre des mesures correctives en essayant de réinitialiser l’unité. Lorsque l’unité est
réinitialisée, toutes les demandes incomplètes sont terminées avec une erreur, et elles sont essayées. Lorsque la
file d’attente en attente est effacée, le minuteur est défini sur -1 , qui est la valeur initiale.
Chaque SRB a une valeur de minuteur définie. Une fois les demandes terminées, le minuteur de file d’attente est
actualisé avec la valeur de délai d’expiration du SRB en tête de la liste.
Les causes les plus courantes de l’ID d’événement 129 sont les LUN non réponses ou une demande supprimée.
Les demandes supprimées peuvent être provoquées par des routeurs défectueux ou d’autres problèmes
matériels sur le réseau de la zone de stockage (SAN).

Cet événement indique que le piloteClasspnp.sys a reçu une demande de suppression surprise du gestionnaire
de plug-and-play (PNP) pour un disque non amovible.
Ce problème se produit le plus souvent lorsque quelque chose perturbe la communication du système avec un
disque, comme une erreur de structure SAN ou un problème de bus SCSI. Les erreurs peuvent également être
provoquées par un disque qui échoue ou lorsqu’un utilisateur débranchez un disque pendant l’exécution du
système. Dans ce cas, un administrateur doit vérifier l’intégrité du sous-système de disque.
Résolution des problèmes liés aux ID d’événement 55 et 98

Si des événements NTFS tels que l’ID d’événement 55, 50, 140 et 98 sont enregistrés, vous devez exécuter
l’utilitaire « chkdsk ».
Comme NTFS n’a pas pu écrire de données dans le journal des transactions, cela peut affecter la capacité de
NTFS à arrêter ou à restaurer les opérations dans lesquelles les données de transaction n’ont pas pu être écrites.
Event Type: Error

Event Source: NTFS
Event ID: 55
Description: The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on
the volume.
En règle générale, l’ID d’événement 55 est journalisé en cas d’altération du système de fichiers. L’altération du
système de fichiers se produit lorsqu’un ou plusieurs des problèmes suivants se produisent :
Un disque a des secteurs incorrects.
Les demandes d’E/S qui sont remises par le système de fichiers au sous-système de disque ne sont pas
terminées correctement.
La plupart des problèmes sont liés au matériel, et le matériel peut être endommagé de manière inattendue.
Vous pouvez essayer les méthodes suivantes pour résoudre les problèmes :
Mettez à jour le port SCSI ou les pilotes du contrôleur RAID.
Supprimez ou mettez à jour les pilotes de filtre.
Mettez à jour les pilotes de stockage ou le microprogramme tiers.
Basculement vers différents types de pilotes. Par exemple, les pilotes de contrôleur RAID ou les pilotes
monolithiques.
Réorganiser le matériel en différentes combinaisons.
produits.
Windows La sauvegarde du serveur ne démarre pas
après avoir effectué une bmr dans Windows Server
2012
Cet article fournit une solution à un problème qui empêche la sauvegarde Windows server de démarrer après
avoir effectué une récupération complète .bmr(BMR).
Symptômes
Vous avez un ordinateur qui exécute Windows Server 2012 ou Windows Server 2012 R2.
Vous utilisez un système UEFI avec deux disques durs et vous avez une partition système EFI sur votre disque
système.
Vous utilisez Windows sauvegarde du serveur pour effectuer une sauvegarde complète.
Vous utilisez ensuite les données de sauvegarde pour effectuer une bmr.
Toutefois, une fois l’opération de récupération terminée, le service Windows sauvegarde du serveur ne peut pas
être démarré.
Cause
Ce problème se produit car le moteur de sauvegarde Windows Server (Wbengine.exe) ne gère pas correctement
les cas lorsque l’emplacement de la partition système EFI est modifié pendant la restauration.
Résolution
Pour résoudre ce problème, Sauvegarde Windows devez reconstruire le catalogue pour refléter les
configurations de disque les plus récentes. Pour déclencher cette action, suivez les étapes suivantes :
1. Ouvrez une invite de commandes d’administration.
wbadmin delete catalog
3. Redémarrez le service Windows de sauvegarde du serveur ou redémarrez l’ordinateur.

Le service Windows Server Backup doit maintenant s’exécuter normalement.
Statut
S’applique à ».
Références
En savoir plus sur la commande de suppression de catalogue wbadmin.
Vous ne pouvez pas supprimer un fichier ou un
dossier sur un volume de système de fichiers NTFS
Cet article explique pourquoi vous ne pouvez pas supprimer un fichier ou un dossier sur un volume de système
de fichiers NTFS. Il fournit également de l’aide pour résoudre ce problème.
NOTE
En interne, NTFS traite les dossiers comme un type spécial de fichier. Par conséquent, le fichier Word de cet article indique
un fichier ou un dossier.
Cause 1 : le fichier utilise une ACL

Vous ne pouvez pas supprimer un fichier si celui-ci utilise une liste de contrôle d’accès (ACL). Pour résoudre ce
problème, modifiez les autorisations sur le fichier. Vous de devez peut-être prendre possession des fichiers pour
modifier les autorisations.
Les administrateurs ont la possibilité implicite de prendre possession d’un fichier, même s’ils n’ont pas été
explicitement autorisés à le faire. Les propriétaires de fichiers ont la possibilité implicite de modifier les
autorisations de fichier, même s’ils ne sont pas explicitement autorisés à le faire. Vous de devez donc prendre
possession d’un fichier, vous accorder des autorisations pour supprimer le fichier, puis le supprimer.
Vous ne pouvez pas utiliser certains outils de sécurité pour afficher ou modifier des autorisations, car le
fichier possède une ACL non canonique
Pour contourner ce problème, utilisez un autre outil (par exemple, une build ultérieure de Cacls.exe).
Les entrées de contrôle d’accès (ACE) d’une ACL ont une certaine séquence préférée en fonction de leur type. Par
exemple, les ace qui refusent l’accès sont généralement avant les ace qui octroient l’accès. Toutefois, rien
n’empêche un programme d’écrire une ACL qui possède des ace dans n’importe quel ordre arbitraire. Dans
certaines versions antérieures de Windows, des problèmes se produisaient Windows essayaient de lire ces ACA
non canoniques. Parfois, vous ne pouvez pas modifier correctement ces ACA à l’aide de l’éditeur de sécurité
graphique Microsoft Windows Explorer. Ce problème a été corrigé dans les versions ultérieures de Windows. Si
vous faites l’expérience de ce problème, utilisez la version la plus récente de Cacls.exe. Même si vous ne pouvez
pas afficher ou modifier une ACL en place, vous pouvez écrire une nouvelle ACL pour accéder au fichier.
Cause 2 : le fichier est utilisé

Vous ne pouvez pas supprimer un fichier si le fichier est utilisé. Pour résoudre ce problème, déterminez le
processus qui possède le handle ouvert, puis fermez ce processus.
Selon la façon dont le fichier est ouvert, il se peut que vous ne soyez pas en mesure de supprimer un fichier en
cours d’utilisation. Par exemple, le fichier est ouvert pour un accès exclusif au lieu d’un accès partagé. Vous
pouvez utiliser différents outils pour déterminer les processus qui ont des dentes ouvertes sur des fichiers
lorsque vous le souhaitez.
Les symptômes de ce problème peuvent varier. Vous pouvez utiliser la commande Supprimer pour supprimer
un fichier. Toutefois, le fichier n’est pas supprimé tant que le processus ouvert n’a pas libéré le fichier. En outre, il
se peut que vous ne soyez pas en mesure d’accéder à la boîte de dialogue Sécurité pour un fichier en attente de
suppression. Pour résoudre ce problème, déterminez le processus qui possède le handle ouvert, puis fermez ce
processus.
Cause 3 : l’altération du système de fichiers empêche l’accès au fichier

Vous ne pouvez pas supprimer le fichier si le système de fichiers est endommagé. Pour résoudre ce problème,
exécutez l’utilitaire Chkdsk sur le volume de disque pour corriger les erreurs éventuelles.
Les raisons suivantes peuvent corrompre le système de fichiers et placer les fichiers dans un état problématique
:
Secteurs défectueux sur le disque
Autres matériels défectueux
Bogues logiciels
Les opérations classiques peuvent échouer de différentes manières. Lorsque le système de fichiers détecte une
altération, il enregistre un événement dans le journal des événements et vous recevez généralement un
message qui vous invite à exécuter Chkdsk. Selon la nature de l’altération, Chkdsk peut ou non récupérer des
données de fichier. Toutefois, Chkdsk renvoie le système de fichiers à un état cohérent en interne.
Cause 4 : des fichiers existent dans des chemins d’accès plus profonds
que MAX_PATH caractères
Vous ne pouvez pas ouvrir, modifier ou supprimer un fichier en cas de problèmes avec le chemin d’accès du
fichier.
Résolution 1 : utiliser un nom 8.3 autogénéré pour accéder au fichier
Pour résoudre ce problème, vous pouvez utiliser le nom 8.3 automatiquement pour accéder au fichier. Cette
résolution peut être la résolution la plus simple si le chemin d’accès est profond, car les noms de dossiers sont
trop longs. Si le chemin d’accès 8.3 est également trop long ou si 8,3 noms ont été désactivés sur le volume,
allez à la résolution 2. Pour plus d’informations sur la désactivation des noms de fichiers 8.3 sur les volumes
NTFS, voir Comment désactiver la création de noms 8.3sur les partitions NTFS .
Résolution 2 : renommer ou déplacer un dossier profond
Renommons le dossier de sorte que les fichiers cibles qui sont plus profonds qu’il MAX_PATH n’existe plus. Si
vous le faites, commencez par le dossier racine ou tout autre emplacement pratique. Renommons ensuite les
dossiers afin qu’ils ont des noms plus courts. Si cette étape ne résout pas ce problème, par exemple, si un fichier
contient plus de 128 dossiers, allez à la résolution 4.
Résolution 3 : ma map miquer un lecteur à un dossier dans la structure du chemin d’accès
Map to a folder inside the structure of the path of the target file or folder. Cette méthode raccourcit le chemin
d’accès virtuel.
Par exemple, supposons que vous avez un chemin d’accès structuré comme suit :
\\ServerName\SubfolderName1\SubfolderName2\SubfolderName3\SubfolderName4\...
Dans ce chemin d’accès, le nombre total de caractères est de plus de 255 caractères. Pour raccourcir la longueur
de ce chemin d’accès, à 73 caractères, mapmage d’un lecteur à SubfolderName4.
Résolution 4 : utiliser un partage réseau aussi profond que le dossier
Si les résolutions 1, 2 et 3 ne sont pas pratiques ou ne résolvent pas le problème, créez un partage réseau aussi
profond que possible dans l’arborescence de dossiers. Renommez ensuite les dossiers en accédant au partage.
Résolution 5 : utiliser un outil qui peut traverser des chemins d’accès profonds
De Windows programmes s’attendent à ce que la longueur maximale du chemin d’accès soit plus courte que
255 caractères. Ces programmes allouent uniquement suffisamment de stockage interne pour gérer ces
chemins d’accès classiques. NTFS n’a pas cette limite et peut contenir des chemins beaucoup plus longs.
Vous pouvez être face à ce problème si vous créez un partage à un moment donné dans votre structure de
dossiers déjà assez profond, puis créez une structure profonde en dessous de ce point à l’aide du partage.
Certains outils qui fonctionnent localement sur l’arborescence de dossiers peuvent ne pas être en mesure de
traverser toute l’arborescence à partir de la racine. Vous de devez peut-être utiliser ces outils d’une manière
spéciale pour qu’ils traversent le partage. La documentation de l’API CreateFile décrit une méthode pour
parcourir l’arborescence entière dans cette situation.
En règle générale, vous pouvez gérer les fichiers à l’aide du logiciel qui les crée. Si vous avez un programme qui
peut créer des fichiers qui sont plus profonds que , vous pouvez généralement utiliser ce même programme
pour MAX_PATH supprimer ou gérer les fichiers. Vous pouvez généralement supprimer des fichiers créés sur un
partage à l’aide du même partage.
Cause 5 : le nom du fichier inclut un nom réservé dans l’espace de

noms Win32
Si le nom de fichier inclut un nom réservé dans l’espace de noms Win32, tel que lpt1, vous ne pouvez pas
supprimer le fichier. Pour résoudre ce problème, utilisez un programme non-Win32 pour renommer le fichier.
Vous pouvez utiliser un outil POSIX ou tout autre outil qui utilise la syntaxe interne appropriée pour utiliser le
fichier.
En outre, vous pouvez utiliser certaines commandes intégrées pour contourner les vérifications de nom réservé
Win32 classiques si vous utilisez une syntaxe particulière pour spécifier le chemin d’accès du fichier.
Si vous ouvrez un handle vers un fichier à l’aide du mécanisme Win32 CreateFile classique, certains noms de
fichiers sont réservés aux anciens périphériques DOS. Pour des raisons de compatibilité ascendante, ces noms
de fichiers ne sont pas autorisés et ne peuvent pas être créés à l’aide d’appels de fichiers Win32 classiques. Ce
problème n’est pas une limitation de NTFS.
Vous pouvez utiliser un programme Win32 pour contourner les vérifications de nom classiques qui sont
réalisées lorsqu’un fichier est créé ou supprimé à l’aide de la même technique que celle utilisée pour parcourir
les dossiers plus profondément que MAX_PATH . En outre, certains outils POSIX ne sont pas soumis à ces
vérifications de nom.
Cause 6 : le nom du fichier inclut un nom non valide dans l’espace de

noms Win32
Vous ne pouvez pas supprimer un fichier si le nom de fichier inclut un nom non valide. Par exemple, le nom du
fichier possède un espace de fin ou une période de fin, ou le nom de fichier est composé d’un espace
uniquement. Pour résoudre ce problème, utilisez un outil qui utilise la syntaxe interne appropriée pour
supprimer le fichier. Vous pouvez utiliser la "\\?\" syntaxe avec certains outils pour travailler sur ces fichiers.
Voici un exemple :
del "\\?\c:\<path_to_file_that contains a trailing space.txt>"
La cause de ce problème est similaire à la cause 4. Si vous utilisez une syntaxe Win32 classique pour ouvrir un
fichier qui possède des espaces de fin ou des périodes de fin dans son nom, les espaces ou les périodes de fin
sont réduits avant l’ouverture du fichier réel. Par exemple, vous avez deux fichiers dans le même dossier nommé
et AFile.txt AFile.txt , notez l’espace après le nom de fichier. Si vous essayez d’ouvrir le deuxième fichier à
l’aide d’appels Win32 standard, vous ouvrez le premier fichier à la place. De même, si vous avez un fichier dont
le nom n’est qu’un espace et que vous essayez de l’ouvrir à l’aide d’appels Win32 standard, vous ouvrez plutôt le
dossier parent du fichier. Dans ce cas, si vous essayez de modifier les paramètres de sécurité de ces fichiers, vous
risquez de ne pas pouvoir le faire ou de modifier de manière inattendue les paramètres de différents fichiers. Si
ce comportement se produit, vous pouvez penser que vous disposez d’autorisations pour un fichier qui possède
réellement une ACL restrictive.
Combinaisons de causes
Parfois, vous pouvez faire l’expérience de combinaisons de ces causes. Cela peut rendre la procédure de
suppression d’un fichier plus complexe. Par exemple, si vous vous connectez en tant qu’administrateur de
l’ordinateur, vous pouvez faire l’expérience d’une combinaison des causes 1 (vous n’êtes pas autorisé à
supprimer un fichier) et Cause 5 (le nom du fichier contient un caractère de fin qui redirige l’accès au fichier vers
un fichier différent ou inexistant) et vous ne pouvez pas supprimer le fichier. Si vous essayez de résoudre la
cause 1 en prenant possession du fichier et en ajoutant des autorisations, il se peut que vous ne soyez toujours
pas en mesure de supprimer le fichier, car l’éditeur ACL dans l’interface utilisateur ne peut pas accéder au fichier
approprié en raison de cause 6.
Dans ce cas, vous pouvez utiliser l’utilitaire Subinacl avec le commutateur (cet utilitaire est inclus dans le Kit de
ressources) pour modifier la propriété et les /onlyfile autorisations d’un fichier inaccessible. Voici un exemple :
subinacl /onlyfile "\\?\c:\<path_to_problem_file>" /setowner= domain\administrator /grant=

domain\administrator=F
NOTE
Cette commande est une ligne de commande unique qui a été wrapped pour une plus grande lisibilité.
Cet exemple de ligne de commande modifie le fichier qui contient un espace de fin afin que le compte domaine
\administrateur soit le propriétaire du fichier et que ce compte dispose d’un contrôle total
C:\<path_to_problem_file> sur le fichier. Vous pouvez désormais supprimer ce fichier à l’aide de la commande
Del avec la même "\\?\" syntaxe.
Modification du comportement de la commande de
format dans Windows Vista et versions ultérieures
Cet article décrit une modification du comportement de la commande de format dans Windows Vista et
versions Windows versions ultérieures.
S’applique à : Windows Server 2012 R2, Window 10 : toutes les éditions
Introduction
Le comportement de la commande de format a changé dans Windows Vista et versions Windows versions
ultérieures. Par défaut dans Windows Vista et les versions ultérieures, la commande de format écrit des zéros
sur le disque entier lorsqu’un format complet est effectué. Dans Windows XP et les versions antérieures de
Windows, la commande de format n’écrit pas de zéros sur l’intégralité du disque lorsqu’un format complet est
effectué.
Le nouveau comportement de format peut entraîner des problèmes pour les modes d’allocation à la demande
qu’un fournisseur de stockage en volume, tel qu’un réseau san Stockage (SAN), prend en charge. Des problèmes
peuvent se produire car le nouveau comportement de format déclenche prématurément l’allocation de l’espace
de stockage.
Dans le scénario à la demande, les zéros n’ont pas besoin d’être écrits sur l’intégralité du disque, car le
fournisseur de stockage en volume initialise les données allouées à la demande. Pour éviter de provoquer des
allocations à la demande inutiles, vous devez utiliser l’option de format rapide.
Option de format rapide

Vous pouvez utiliser quatre méthodes pour mettre en forme un volume dans Windows Vista et les versions
ultérieures. Vous pouvez utiliser l’option de format rapide pour ces quatre méthodes :
Ligne de commande : utilisez la format /q commande.
Diskpart : utilisez la commande de format avec le paramètre rapide.
Windows Explorateur : cliquez pour cocher Exécuter un format rapide.
Gestion des disques (Diskmgmt.msc) : cliquez pour cocher Exécuter un format rapide.
Rechercher et corriger les problèmes d’espace
disque sur les volumes NTFS
Cet article explique comment vérifier l’allocation d’espace disque d’un système de fichiers NTFS pour découvrir
les fichiers et dossiers incriminés ou rechercher une altération du volume sur les ordinateurs basés sur
Microsoft Windows Server 2003.
Résumé
NTFS prend en charge de nombreuses fonctionnalités au niveau du volume et des fichiers qui peuvent entraîner
la perte d’un espace disque disponible ou un rapport incorrect. Par exemple, un volume NTFS peut
soudainement apparaître comme plein sans raison, et un administrateur ne peut pas trouver la cause ou
localiser les dossiers et fichiers incriminés. Cela peut se produire si un accès malveillant ou non autorisé à un
volume NTFS dans lequel des fichiers de grande taille ou une quantité élevée de petits fichiers sont copiés
secrètement s’est produit. Ces fichiers ont ensuite leurs autorisations NTFS supprimées ou restreintes. Ce
comportement peut également se produire après un dysfonctionnement de l’ordinateur ou une panne de
courant qui provoque une altération du volume.
L’allocation d’espace disque d’un volume NTFS peut sembler mal signalé pour l’une des raisons suivantes :
La taille de cluster du volume NTFS est trop importante pour les fichiers de taille moyenne qui y sont stockés.
Les attributs de fichier ou les autorisations NTFS empêchent Windows Explorer ou une invite de commandes
Windows’afficher ou d’accéder à des fichiers ou des dossiers.
Le chemin d’accès du dossier dépasse 255 caractères.
Les dossiers ou les fichiers contiennent des noms de fichiers non valides ou réservés.
Les métafichiers NTFS (tels que la table de fichiers maîtres) ont évolué et vous ne pouvez pas les dé allouer.
Les fichiers ou dossiers contiennent d’autres flux de données.
L’altération NTFS provoque le rapport d’utilisation de l’espace libre.
D’autres fonctionnalités NTFS peuvent provoquer une confusion dans l’allocation de fichiers.
Les informations suivantes peuvent vous aider à optimiser, réparer ou mieux comprendre comment vos
volumes NTFS utilisent l’espace disque.
La taille du cluster est trop grande

Seuls les fichiers et dossiers qui incluent des métafichierS NTFS internes tels que la table MFT (Master File Table),
les index de dossiers et d’autres personnes peuvent consommer de l’espace disque. Ces fichiers et dossiers
consomment toutes les allocations d’espace de fichiers à l’aide de multiples d’un cluster. Un cluster est une
collection de secteurs contigus. La taille du cluster est déterminée par la taille de la partition lorsque le volume
est formaté.
Pour plus d’informations sur les clusters, voir Taille de cluster par défaut pour NTFS, FAT et exFAT.
Lorsqu’un fichier est créé, il consomme au moins un cluster d’espace disque, en fonction de la taille initiale du
fichier. Lorsque des données sont ajoutées ultérieurement à un fichier, NTFS augmente l’allocation du fichier en
plusieurs tailles de cluster.
Pour déterminer la taille actuelle du cluster et les statistiques de volume, exécutez une commande Chkdsk en
lecture seule à partir d’une invite de commandes. Pour ce faire, procédez comme suit :
2. À l’invite de commandes, tapez la commande : chkdsk d: .
Où d : est la lettre du lecteur que vous souhaitez vérifier.
3. Cliquez sur OK .
4. Afficher la sortie résultante. Par exemple :
4096543 ko d’espace disque total. <--- capacité totale des disques formatés.
2906360 KB dans les fichiers 19901. <--- espace utilisé par les données de fichier utilisateur.
6 344 Ko dans 1 301 index. <---'espace utilisé par les index NTFS.
0 Ko dans les secteurs non concernés. <---'espace perdu pour les secteurs non concernés.
49379 Ko utilisés par le système. <--- inclut MFT et d’autres métafichiers NTFS.
2 2544 Ko occupés par le fichier journal. <--- journal NTFS - (peut être ajusté à l’aide de chkdsk
/L:size)
1134460 Ko disponible sur disque. <--- espace disque disponible
4 096 octets dans chaque unité d’allocation. <--- taille du cluster. (4K)
1024135'allocation totale sur le disque. <--- nombre total de clusters sur disque.
283615'allocation disponible sur disque. <--- clusters gratuits disponibles.
NOTE
Multipliez chaque valeur que la sortie signale en kilo-octets (Ko) par 1 024 pour déterminer le nombre d’octets précis. Par
exemple : 2906360 x 1024 = 2 976 112 640 octets. Vous pouvez utiliser ces informations pour déterminer la façon dont
votre espace disque est utilisé et la taille de cluster par défaut.
Pour déterminer s’il s’agit de la taille de cluster optimale, vous devez déterminer l’espace perdu sur votre disque.
1. Cliquez sur Démarrer, sur Mon ordinateur, puis double-cliquez sur la lettre de lecteur (par exemple, D)
du volume en question pour ouvrir le volume et afficher les dossiers et les fichiers que contient la racine.
2. Cliquez sur n’importe quel fichier ou dossier, puis cliquez sur Sélectionner tout dans le menu Modifier.
3. Une fois tous les fichiers et dossiers sélectionnés, cliquez avec le bouton droit sur un fichier ou un dossier,
cliquez sur Propriétés, puis cliquez sur l’onglet Général.
L’onglet Général affiche le nombre total de fichiers et de dossiers sur l’ensemble du volume et fournit
deux statistiques de taille de fichier : TAILLE et TAILLE SUR DISQUE .
Si vous n’utilisez pas la compression NTFS pour les fichiers ou dossiers contenus sur le volume, la différence
entre TAILLE et TAILLE SUR DISQUE peut représenter un espace perdu car la taille du cluster est plus importante
que nécessaire. Vous pouvez utiliser une taille de cluster plus petite pour que la valeur SIZE ON DISK soit aussi
proche que possible de la valeur SIZE. Une grande différence entre la valeur SIZE ON DISK et la valeur SIZE
indique que la taille de cluster par défaut est trop grande pour la taille moyenne de fichier que vous stockez sur
le volume.
Vous pouvez uniquement modifier la taille de cluster que vous utilisez en reformantant le volume. Pour ce faire,
vous pouvez le faire, puis le mettre en forme à l’aide de la commande format et du commutateur pour spécifier
/a l’allocation appropriée. Par exemple : format D: /a:2048 (cet exemple utilise une taille de cluster de 2 Ko).
NOTE
Vous pouvez également permettre à la compression NTFS de reprendre de l’espace perdu en raison d’une taille de cluster
incorrecte. Toutefois, cela peut entraîner une diminution des performances.
Attributs de fichier ou autorisations NTFS

Les Windows’Explorateur et la commande de liste d’annuaires affichent le nombre total de fichiers et de dossiers
statistiques pour les fichiers et dir /a /s dossiers accessibles. Par défaut, les fichiers masqués et les fichiers de
système d’exploitation protégés sont exclus. Ce comportement peut entraîner l Windows explorer ou la
commande dir pour afficher des statistiques inexactes sur les totaux et la taille des fichiers et des dossiers.
Pour inclure ces types de fichiers dans les statistiques globales, modifiez les options de dossier. Pour ce faire,
1. Cliquez sur Démarrer, sur Mon ordinateur, puis double-cliquez sur la lettre de lecteur (par exemple : D ) du
volume. Cela ouvre le volume et affiche les dossiers et les fichiers que contient la racine.
2. Dans le menu Outils, cliquez sur Options de dossier, puis cliquez sur l’onglet Affichage.
3. Cochez la case Afficher les fichiers et dossiers masqués, puis cochez la case Masquer les fichiers protégés
du système d’exploitation.
4. Cliquez sur Oui lorsque vous recevez le message d’avertissement, puis cliquez sur le bouton Appliquer.
Cette modification permet à Windows Explorer et à la commande de totaler tous les fichiers et dossiers que
contient le volume et à qui l’utilisateur est autorisé dir /a /s à accéder.
Pour déterminer les dossiers et les fichiers accessibles, suivez les étapes suivantes :
1. À l’invite de commandes, créez un fichier texte à partir de la sortie de la dir /a /s commande.
Par exemple : à l’invite de commandes, tapez la commande suivante : dir d: /a /s >c:\d-dir.txt .
2. Démarrez l’Assistant Sauvegarde ou restauration.
a. Cliquez sur Démarrer, sur Exécuter, tapez ntbackup, puis cliquez sur OK.
b. Cliquez sur Mode avancé.
3. Cliquez sur Options dans le menu Outils, cliquez sur l’onglet Journal de sauvegarde, cliquez sur
Détails, puis sur OK .
4. Dans l’utilitaire de sauvegarde, cliquez sur l’onglet Sauvegarde, puis cochez la case pour l’ensemble du
volume concerné (par exemple : D :), puis cliquez sur Démarrer la sauvegarde.
5. Une fois la sauvegarde terminée, ouvrez le rapport de sauvegarde et comparez le dossier du dossier de
sortie du journal NTBackup avec la sortie d-dir.txt que vous avez enregistrée à l’étape 1.
Étant donné que la sauvegarde peut accéder à tous les fichiers, son rapport peut contenir des dossiers et des
fichiers Windows Explorer et la commande dir ne s’affichent pas. Il peut être plus facile d’utiliser l’interface
NTBackup pour localiser le volume sans le backing up lorsque vous souhaitez rechercher des fichiers ou
dossiers de grande taille que vous ne pouvez pas accéder à l’aide de Windows Explorer.
Après avoir localisé les fichiers que vous n’avez pas accès, vous pouvez ajouter ou modifier des autorisations à
l’aide de l’onglet Sécurité pendant que vous affichez les propriétés du fichier ou du dossier dans l’Explorateur
Windows. Par défaut, vous ne pouvez pas accéder au dossier Informations sur le volume système. Vous devez
ajouter les autorisations correctes pour inclure le dossier dans la dir /a /s commande.
Vous remarquerez peut-être que des dossiers ou des fichiers n’ont pas d’onglet Sécurité. Vous ne pourrez peut-
être pas ré-attribuer des autorisations aux dossiers et fichiers concernés. Vous pouvez recevoir le message
d’erreur suivant lorsque vous essayez d’y accéder :
D:\folder_name\ n’est pas accessible
Accès refusé
Si vous avez des dossiers de ce type, contactez les services de support technique Microsoft pour obtenir de
l’aide supplémentaire.
Noms de fichiers non valides

Les dossiers ou fichiers qui contiennent des noms de fichiers non valides ou réservés peuvent également être
exclus des statistiques de fichiers et de dossiers. Les dossiers ou fichiers qui contiennent des espaces de début
ou de fin sont valides dans NTFS, mais ils ne le sont pas d’un point de vue du sous-système Win32. Par
conséquent, ni Windows Explorer ni une invite de commandes ne peuvent fonctionner avec eux de manière
fiable.
Vous ne pourrez peut-être pas renommer ou supprimer ces fichiers ou dossiers. Lorsque vous essayez de le
faire, vous pouvez recevoir l’un des messages d’erreur suivants :
Erreur de changement de nom du fichier ou du dossier

Impossible de renommer le fichier : impossible de lire le fichier source ou le disque.
Ou
Erreur lors de la suppression d’un fichier ou d’un dossier

Impossible de supprimer le fichier : impossible de lire le fichier source ou le disque.
Si vous avez des dossiers ou des fichiers que vous ne pouvez pas supprimer ou renommer, contactez les
services de support technique Microsoft.
Développement MFT (Master File Table) NTFS

Lorsqu’un volume NTFS est créé et mis en forme, des métafichierS NTFS sont créés. L’un de ces métafichiers est
nommé MFT (Master File Table). Il est petit lorsqu’il est créé (environ 16 Ko), mais il croît à mesure que des
fichiers et des dossiers sont créés sur le volume. Lorsqu’un fichier est créé, il est entré dans le MFT en tant que
segment d’enregistrement de fichier (FRS). Le frs est toujours de 1 024 octets (1 Ko). À mesure que des fichiers
sont ajoutés au volume, la MFT augmente. Toutefois, lorsque des fichiers sont supprimés, les frs associés sont
marqués comme libres pour réutilisation, mais le nombre total de FRS et l’allocation MFT associée restent. C’est
pourquoi vous ne retrouvez pas l’espace utilisé par le MFT après avoir supprimé un grand nombre de fichiers.
Pour voir exactement la taille du MFT, vous pouvez utiliser le défragmenteur intégré pour analyser le volume. Le
rapport qui en résulte fournit des informations détaillées sur la taille et le nombre de fragments dans le MFT.
Par exemple :
Fragmentation de la table MFT (Master File Table)

Taille totale MFT = 26 203 Ko
Nombre d’enregistrement MFT = 21 444
Pourcentage de MFT en cours d’utilisation = 81 %
Nombre total de fragments MFT = 4
Toutefois, pour obtenir des informations plus complètes sur la quantité d’espace (surcharge) que le NTFS entier
utilise, exécutez la commande chkdsk.exe, puis affichez la sortie pour la ligne suivante :
Utilisé par le système.
Actuellement, seuls les défragmentateurs tiers consolident les enregistrements FRS MFT inutilisés et récupèrent
l’espace alloué MFT inutilisé.
Flux de données de remplacement

NTFS permet aux fichiers et dossiers de contenir d’autres flux de données. Avec cette fonctionnalité, vous pouvez
associer plusieurs allocations de données à un seul fichier ou dossier. L’utilisation de flux de données de
remplacement sur des fichiers et des dossiers présente les limitations suivantes :
Windows L’Explorateur et la commande dir ne signalent pas les données dans d’autres flux de données dans
le cadre de la taille de fichier ou des statistiques de volume. Au lieu de cela, ils n’indiquent que le nombre
total d’octets pour le flux de données principal.
La sortie de chkdsk indique avec précision l’espace utilisé par les fichiers de données d’un utilisateur, y
compris les flux de données de remplacement.
Les quotas de disque s’analysent et signalent avec précision toutes les allocations de flux de données qui font
partie des fichiers de données d’un utilisateur.
NTBackup enregistre le nombre d’octets sauvegarde dans le rapport du journal de sauvegarde. Toutefois, il
ne montre pas quels fichiers contiennent d’autres flux de données. Il n’affiche pas non plus les tailles de
fichiers précises pour les fichiers qui incluent des données dans d’autres flux.
Corruption du système de fichiers NTFS

Dans de rares cas, les métafichiers NTFS $MFT ou $BITMAP peuvent être endommagés et entraîner une perte
d’espace disque. Vous pouvez identifier et résoudre ce problème en exécutant la chkdsk /f commande sur le
volume. Vers la fin de chkdsk, vous recevez le message suivant si vous devez ajuster les erreurs
$BITMAP:Correcting dans l’attribut BITMAP de la table de fichiers maîtres (MFT). CHKDSK a découvert l’espace
libre marqué comme alloué dans l’bitmap de volume. Windows a apporté des corrections au système de
fichiers.
Autres fonctionnalités NTFS qui peuvent provoquer une confusion

dans l’allocation de fichiers
NTFS prend également en charge les liens durs et les points d’parpare qui vous permettent de créer des points
de montage de volume et des jonctions d’annuaire. Ces fonctionnalités NTFS supplémentaires peuvent être
source de confusion lorsque vous essayez de déterminer la quantité d’espace consommée par un volume
physique.
Un lien dur est une entrée de répertoire pour un fichier, quel que soit l’emplacement des données de fichier sur
ce volume. Chaque fichier possède au moins un lien en dur. Sur les volumes NTFS, chaque fichier peut avoir
plusieurs liens durs, et par conséquent, un seul fichier peut apparaître dans de nombreux dossiers (ou même
dans le même dossier avec des noms différents). Étant donné que tous les liens font référence au même fichier,
les programmes peuvent ouvrir n’importe quel lien et modifier le fichier. Un fichier est supprimé du système de
fichiers uniquement après la suppression de tous les liens vers celui-ci. Après avoir créé un lien dur, les
programmes peuvent l’utiliser comme n’importe quel autre nom de fichier.
NOTE
Windows L’Explorateur et une invite de commandes indiquent tous les fichiers liés comme étant de la même taille, même
s’ils partagent tous les mêmes données et n’utilisent pas réellement cette quantité d’espace disque.
Les points de montage de volume et les jonctions d’annuaire permettent à un dossier vide sur un volume NTFS
de pointer vers la racine ou le sous-dossier d’un autre volume. Windows L’Explorateur et une commande dir /s
suivent le point d’parse, comptent tous les fichiers et dossiers sur le volume de destination, puis les incluent
dans les statistiques du volume hôte. Cela peut vous induire en erreur de penser que plus d’espace est utilisé sur
le volume hôte que ce qui est réellement utilisé.
En résumé, vous pouvez utiliser la sortie chkdsk, l’interface graphique graphique NTBackup ou les journaux de
sauvegarde, ainsi que l’affichage des quotas de disque pour déterminer comment l’espace disque est utilisé sur
un volume. Toutefois, Windows Explorer et la commande dir ont certaines limitations et inconvénients
lorsqu’elles sont utilisées à cet effet.
ID d’événement de disque 154 : échec de l’opération
d’IO en raison d’une erreur matérielle
Cet article fournit une solution pour corriger l’ID d’événement 154 qui se produit sur un ordinateur connecté à
un groupe de stockage tel que le stockage Fibre Channel (FC).
IMPORTANT
Symptômes
Sur un ordinateur Windows Server 2012 connecté à un groupe de stockage tel que le stockage Fibre Channel
(FC), l’ID d’événement 154 est consigné dans le journal des événements système.
Cause
Ce comportement peut se produire pour l’une des raisons suivantes :
La connexion FC a déposé un paquet quelque part entre l’adaptateur de bus hôte (HBA) et le groupe de
stockage.
Le contrôleur de tableau ou un périphérique du tableau a répondu à une demande d’O/S et a indiqué que le
matériel excédait les délai d’attente définis par le matériel dans le tableau.
Résolution
Pour résoudre ce problème, contactez le fournisseur de votre adaptateur, commutateur ou tableau pour
déterminer la cause des paquets FC supprimés ou des délai d’arrêt du matériel.
WARNING
L’événement Disk 154 est un nouvel événement système dans Windows Server 2012 conçu pour enregistrer les
cas dans lesquels un paquet FC a peut-être été déposé. L’objectif est de rendre ces problèmes plus découvrables.
Une image FC abandonnée peut avoir un impact important sur l’expérience utilisateur, car le temps d’attente
d’une opération d’entrée/fin par le système d’exploitation est basé sur la valeur disk.sys TimeOutValue et le
système d’exploitation peut sembler figé ou se bloquer pendant qu’il attend la fin de l’opération d’entrée/fin. Une
fois que la valeur du délai d’attente est atteinte, la couche disque/classe réessaye l’opération d’opération
d’opérations d’entreprise huit fois. (Chaque tentative attend la quantité complète de la valeur TimeOutValue).
Actuellement, nous vous recommandons de définir la valeur disk.sys TimeOutValue aussi basse que possible.
(Nous vous recommandons de la définir sur une valeur ne supérieure à 20 à 30 secondes). Toutefois, comme
pour toute modification, la valeur que vous utilisez doit être évaluée dans un environnement de test avant
d’implémenter cette valeur en production.
La valeur est globale. Par conséquent, évitez des valeurs de délai d’délai très courtes. Dans le cas contraire, vous
risquez de faire face à des erreurs de délai d’attente dans des scénarios tels que l’attente d’une rotation vers le
haut d’un disque ou d’un lecteur DE DVD.
Pour définir la valeur disk.sys TimeOutValue, suivez les étapes suivantes :
1. Démarrez l’Éditeur du Registre. Pour ce faire, cliquez sur Démarrer, tapez regedit dans la zone Démarrer
la recherche, puis appuyez sur Entrée.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk
3. Recherchez TimeOutValue .
4. Dans le menu Edition , cliquez sur Modifier .
5. Dans la zone de données Valeur, tapez le nombre de secondes souhaité.
Une ressource de disque physique reste dans l’état
En attente en ligne, ou l’utilitaire Chkdsk commence
automatiquement à s’exécuter sur un serveur qui
exécute Windows Server 2008
Cet article permet de résoudre un problème dans lequel divers messages d’erreur peuvent être consignés
lorsque vous apportez une ressource de disque physique en ligne.
Symptômes
Lorsque vous apportez une ressource de disque physique en ligne sur un serveur exécutant Windows Server
2008, vous pouvez être face à l’un des symptômes suivants :
Symptôme 1
Lorsque vous affichez la ressource de disque physique dans le logiciel en ligne de gestion du cluster de failover,
la ressource peut afficher l’état En attente en ligne. En outre, le message d’erreur suivant est consigné dans le
journal système :

Source : Microsoft-Windows-FailoverClustering
Catégorie de tâche : ressource de disque physique
Description :
La ressource de disque de cluster « Disque de cluster 3 » indique une altération du volume \ \ » ? \
Volume{ec2fa15d-b438-11de-88bc-00155dd99d36}'. Chkdsk est exécuté pour résoudre les problèmes. Le
disque n’est pas disponible tant que Chkdsk n’est pas terminé. La sortie de Chkdsk sera enregistrée dans le
fichier « C: \ Windows Cluster Reports ChkDsk_ResCluster Disk \ \ \ 3_Disk2Part1.log ».
Chkdsk peut également écrire des informations dans le journal des événements de l’application.
En outre, le message d’erreur suivant est consigné dans le journal du cluster :
Err [RES] Physical Disk <Cluster Disk 3> : VerifyFS: Failed to open file \ \ ? \ GlobalROOT \ Device \
Harddisk2 \ Partition1TextDocument.txt \ Error: 5.
Symptôme 2
Lorsque vous affichez la ressource de disque physique dans l’utilitaire Administrateur de cluster Microsoft, vous
pouvez être face à un ou plusieurs des symptômes suivants :
Il se peut que la ressource ne soit pas en ligne ou qu’elle soit mise en ligne après un court délai.
L’utilitaire Chkdsk avec le commutateur /F commence automatiquement à s’exécuter sur le disque dur
partagé.
L’ID d’événement 1066 dont la description est similaire à la suivante apparaît dans le journal système de
l’Observateur d’événements :
Cluster resource Disk Y:: is corrupt. Exécution de ChkDsk /F pour résoudre les problèmes.
Cause
Ces problèmes se produisent pour l’une des raisons suivantes.
Cause du symptôme 1
Ce problème se produit car un fichier en lecture seule se trouve dans le répertoire racine de la ressource.
Lorsqu’une ressource de disque physique partagée est mise en ligne, le service de cluster éume les fichiers du
répertoire racine et tente d’ouvrir chaque fichier avec un accès total. Ce comportement permet de s’assurer que
le système de fichiers est cohérent et que le volume n’est pas endommagé. Si l’un des fichiers est en lecture
seule dans le répertoire racine de la ressource, le volume est considéré comme endommagé et Chkdsk est
démarré. Pour contourner ce problème, utilisez la solution de contournement mentionnée dans la section
Solution de contournement de Symptôme 1.
Cause du symptôme 2
Ce problème se produit car l’indicateur « dirty » pour le volume est définie. Lorsqu’une ressource de disque
physique partagée est mise en ligne, le service de cluster éume les fichiers du répertoire racine et tente d’ouvrir
chaque fichier avec un accès total. Ce comportement permet de s’assurer que le système de fichiers est cohérent
et que le volume n’est pas endommagé. Si l’un des fichiers a l’indicateur « dirty » dans le répertoire racine de la
ressource, le volume est considéré comme endommagé et Chkdsk est démarré. Pour contourner ce problème,
utilisez la solution de contournement mentionnée dans la section Solution de contournement de Symptôme 2.
Solution de contournement de Symptôme 1

Pour contourner ce problème, faites l’une des choses suivantes :
Clear the read-only attribute from the files by either viewing the file properties or by using the attrib -r
command at a command prompt.
Déplacez les fichiers qui ont l’attribut en lecture seule du répertoire racine de la ressource vers un sous-
dossier approprié.
NOTE
Si vous ne parviennent pas à mettre le disque en ligne et à effectuer des vérifications supplémentaires sur les fichiers,
définissez la propriété privée DiskRunChkDsk sur la propriété 4 (ChkDskDontRun). Cela désactive les vérifications de
montage de volume.
Solution de contournement de Symptôme 2

Pour contourner ce problème, déterminez d’abord si l’indicateur « dirty » du volume spécifié est définie.
Pour déterminer si l’indicateur « dirty » est définie pour le volume dans Windows Server 2008, utilisez l’outil
Chkntfs.
Pour plus d’informations sur l’outil Chkntfs, visitez le site Web Microsoft TechNet suivant :
Chkntfs
Pour déterminer si l’indicateur « dirty » est définie pour le volume dans Windows Server 2008 R2, utilisez
l’Assistant Validation d’une configuration.
Pour plus d’informations sur l’Assistant Validation d’une configuration, visitez le site Web Microsoft TechNet
suivant :
Validation d’une configuration de cluster de failover
Si l’indicateur « dirty » est définie pour le volume, exécutez l’utilitaire Chkdsk avec le commutateur /F.
Pour plus d’informations sur l’utilitaire Chkdsk, visitez le site Web Microsoft TechNet suivant :
Chkdsk
État
L’extension d’un CSV à l’aide de Diskpart ou
PowerShell n’est pas bloquée à partir d’un nœud
non-coordinateur
Cet article fournit une solution à un problème dans lequel l’extension d’un volume partagé de cluster à l’aide de
Diskpart ou PowerShell n’est pas bloquée à partir d’un nœud non-coordinateur.
Symptômes
Vous disposez d’un cluster deover avec un volume partagé de cluster (CSV) configuré.
Vous devez étendre le volume CSV.
À partir d’un nœud non-coordinateur, vous utilisez la commande Diskpart ou une cmdlet Windows
PowerShell pour étendre le volume.
Dans ce scénario, le processus d’extension est terminé. Toutefois, la section Capacité de la console gestion des
disques continue d’afficher l’ancienne valeur de la taille du disque avant le processus d’extension. Dans
l’interface graphique graphique du cluster, l’affichage disque indique la taille étendue correcte, mais la taille du
volume reflète les anciennes valeurs.
En outre, vous ne pouvez pas réduire le volume étendu. Si vous essayez de le faire, le processus échoue et vous
pouvez recevoir le message d’erreur suivant :
Paramètre erroné
Cause
Ce problème se produit parce qu’une opération d’écriture étendue entraîne l’extension de l’ensemble ou d’une
partie des valeurs suivantes par le système de fichiers CSVFS (Cluster Shared Volumes File System) :
Taille d’allocation de fichiers
La taille des fichiers
Longueur de données valide
Une opération de lecture peut entraîner l’interrogation de certaines informations de NTFS par le CSVFS. Sur le
nœud coordinateur, le CSVFS envoie les E/S de métadonnées directement au volume NTFS, mais les autres
nœuds utilisent le serveur SMB (Server Message Block) pour transmettre les métadonnées sur le réseau.
Dans l’interface graphique graphique du cluster, vous pouvez remarquer que l’option Étendre le volume est
grisée sur un nœud non-coordinateur.
Résolution
Pour résoudre ce problème, n’exécutez aucune opération de métadonnées à partir d’un nœud non-coordinateur.
Pour plus d’informations sur le clustering et la haute disponibilité, consultez l’article suivant du blog de l’équipe
de clustering de Load-Balancing réseau :
Volume partagé de cluster (CSV) à l’intérieur
Pour contourner ce problème, augmentez l’espace disque alloué au CSV. Pour ce faire, étendez le disque sur le
nœud propriétaire CSV (nœud de coordinateur) à l’aide de l’interface graphique graphique du cluster, de l’outil
Diskpart ou de Windows PowerShell.
NOTE
Après avoir étendu le disque, toutes les tailles de disque affichées et les valeurs de capacité sont mises à jour à la taille
correcte.
Comment définir la valeur de Registre Des attributs
Partmgr à l’aide de PowerShell
Cet article explique comment définir la valeur de Registre Des attributs de Partmgr à l’aide de PowerShell.
Résumé
La clé de Registre partmgr.sys Attributes affecte le comportement en ligne d’un disque donné et la valeur
correspond aux valeurs de stratégie SAN dans VDS, comme indiqué dans l’VDS_SAN_POLICY.
typedef enum _VDS_SAN_POLICY {

VDS_SP_UNKNOWN = 0x0,
VDS_SP_ONLINE = 0x1,
VDS_SP_OFFLINE_SHARED = 0x2,
VDS_SP_OFFLINE = 0x3
} VDS_SAN_POLICY;
Cette valeur est initialement définie lorsqu’un disque est identifié en fonction de la valeur de stratégie SAN en
place à ce moment-là. La stratégie SAN détermine si un disque nouvellement découvert est mis en ligne ou
reste hors connexion, et s’il est mis en lecture/écriture ou reste en lecture seule. Lorsqu’un disque est hors
connexion, la disposition du disque peut être lue, mais aucun périphérique de volume n’est mis en surface via
Plug-and-Play (PnP). Cela signifie qu’aucun système de fichiers ne peut être monté sur le disque. Lorsqu’un
disque est en ligne, un ou plusieurs périphériques de volume sont installés pour le disque.
Cette stratégie peut être vue à l’aide de l’utilitaire DISKPART comme suit :
2. Dans la fenêtre de ligne de commande, tapez diskpart, puis appuyez sur Entrée.
3. SAN Tapez, puis appuyez sur Entrée. Cette commande retourne la stratégie SAN actuelle définie.
4. exit Tapez, puis appuyez sur Entrée.
La définition d’une valeur de 0 ( ) sera mappée sur , donc une valeur de 0 ou 1 peut être utilisée pour mettre
VDS_SP_UNKNOWN VDS_SP_ONLINE un disque en ligne.
Ce script modifie la valeur de Registre Attributes située à

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\SCSI\<device>\<instance>\Device Parameters\Partmgr
l’emplacement .
Pour plus d’informations sur l’écriture de scripts pour Windows PowerShell, voir informations générales sur la
façon d’écrire des scripts pour Windows PowerShell.
Informations du Registre
IMPORTANT
La variable de chaîne du fournisseur est utilisée pour limiter la modification de la valeur à un sous-ensemble de
disques correspondant à l’identificateur d’un fournisseur spécifique. Vérifiez le Registre de la chaîne de&Ven_
disque pour vérifier la valeur à utiliser.
$val = 0
$vendor = Read-Host "Enter Vendor String"
$devIDs = Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Enum\SCSI\Disk*Ven_$vendor*\*\Device Parameters\"
foreach ($id in $devIDs)

{
$error.Clear()
$regpath = $id.PSPath + "\Partmgr\"
Set-ItemProperty -path $regpath -Name Attributes -Value $val -ErrorAction SilentlyContinue
if ($error) # didn't find the path, create it and try again

{
New-Item -Path $id.PSPath -Name Partmgr
Set-ItemProperty -path $regpath -Name Attributes -Value $val -ErrorAction SilentlyContinue
$error.Clear()
}
Get-ItemProperty -Path $regpath -Name Attributes -ErrorAction SilentlyContinue | Select Attributes | fl

| Out-String -Stream
}
Le système enregistre plusieurs événements qui
spécifient l’ID d’événement 640
Cet article fournit des informations sur l’ID d’événement 640.

S’applique à : Windows Server 2019, Windows Server 2016, Windows 10 - toutes les éditions
Symptômes
Le journal des applications répertorie de nombreux événements ESENT qui spécifient l’ID d’événement 640
dans Windows 10, Windows Server 2019 et Windows Server 2016.
Cause
L’ID d’événement 640 indique que le moteur ESE (Extensible Stockage Engine) a détecté qu’un fichier de base de
données et son fichier de carte de purge ne sont pas synchronisés. Cette situation se produit rarement. Elle est
causée par l’une des conditions suivantes :
La base de données a été déplacée, mais tous les fichiers requis n’ont pas été déplacés avec elle.
Le secteur qui héberge l’en-tête de la carte de purge est endommagé. Cette condition est exceptionnellement
rare.
Une base de données ESE existante a été supprimée, puis re-créée, mais son fichier de carte de purge n’a pas
été supprimé ni re-créé. Cette incohérence se produit généralement lorsqu’une application migre ses
données d’une base de données ESE vers une autre base de données ESE, et que l’application ne nettoie pas
correctement. Ces migrations peuvent être plus fréquentes pendant ou peu de temps après Windows mises à
niveau. Une fois la nouvelle base de données créée, le système détecte l’ancien fichier de carte de purge. Ce
fichier n’est pas synchronisé avec la nouvelle base de données. Dans ce scénario, il n’y a aucun risque pour
les données dans la nouvelle base de données. La condition est anodin.
Statut
Une prochaine version de Windows est prévue pour inclure une modification qui empêche le système de
consigner l’ID d’événement 640 dans le cas anodin.
Déterminer la cause de l’ID d’événement 640

Pour déterminer la cause de l’ID d’événement 640, examinez la « ... Champs FromDb » dans les données
d’événement et prenons en compte les situations suivantes :
Tous ou certains de ces champs ne sont pas initialisés et, par conséquent, ont des valeurs de zéro. Dans ce
cas, l’ID d’événement 640 est dû à la création d’une nouvelle base de données. Il s’agit d’un cas anodin.
Vous n’avez pas à prendre de mesures pour l’atténuer.
Toutes les « ... Les champs FromDb ont des valeurs non nulles. Dans ce cas, vous devez examiner le
problème.
Le « ... Les champs FromDb » apparaissent en gras dans l’exemple suivant d’entrée de journal des événements :
services (836,D,35) Erreur -1919 validant la page d’en-tête sur le fichier de carte de purge ' <Drive> : \
<Path> \ <FileName> .jfm'. Le fichier de carte de purge sera invalidé. Informations supplémentaires :
[SignDbHdrFromDb:Create time:00/00/1900 00:00:00.000 Rand:0 Computer :]
[SignFmHdrFromDb:Create time:00/00/1900 00:00:00.000 Rand:0 Computer :]
[SignDbHdrFromFm:Create time: <DateTime> Rand:559408839 Computer:] [SignFmHdrFromFm:Create
time: <DateTime> Rand:4291821429 Computer:]
NOTE
Dans cet exemple, : représente le chemin d’accès et le nom <Drive> \ <Path> \ <FileName> réels du fichier de carte de
purge.
À propos de l’ID d’événement 636

Si Windows journal de l’ID d’événement 640 dans le cas anodin, il peut également enregistrer l’ID d’événement
636. Dans ce cas, vous pouvez également ignorer l’ID d’événement 636.
Stratégie Microsoft pour la duplication de disque
des installations Windows
Cet article décrit le SID et les méthodes prises en charge pour cloner ou dupliquer une installation Windows.
S’applique à : Windows 10, version 2004, Windows 10, version 1909, Windows 10, version 1903, Windows 10,
version 1809, Windows 7 Service Pack 1, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2
Résumé
Lorsque vous déployez une installation Windows dupliquée ou imagenée, il est nécessaire que l’outil de
préparation du système (Sysprep) soit utilisé avant la capture de l’image. Sysprep prépare une installation de
Microsoft Windows pour la duplication, l’audit et la livraison des clients. Pour Windows 2000, Windows XP et
Windows Server 2003, Sysprep est inclus avec la dernière Deploy.cab service pack. Pour les versions ultérieures
de Windows, Sysprep est inclus avec le système d’exploitation et Sysprep se trouve dans le dossier :
%windir%\system32\sysprep
Sysprep est responsable de la suppression des données spécifiques au système de Windows, telles que le SID
d’ordinateur. Lors de l’installation de Windows, un SID d’ordinateur est calculé pour contenir un nombre
statistiquement unique de 96 bits. Le SID d’ordinateur est le préfixe des SID de compte d’utilisateur et de compte
de groupe créés sur l’ordinateur. Le SID d’ordinateur est concaténé avec l’ID relatif (RID) du compte pour créer
l’identificateur unique du compte.
L’exemple suivant affiche les SID de quatre comptes d’utilisateur locaux. Seuls les quatre derniers chiffres sont
incrémentés à mesure que de nouveaux comptes sont ajoutés.
HKEY_USERS sur l’ordinateur local
S-1-5-21-191058668-193157475-1542849698-500 Administrateur S-1-5-21-191058668-193157475-
1542849698-1000 Utilisateur 1a S-1-5-21-191058668-193157475-1542849698-1001 Utilisateur 2 S-1-5-21-
191058668-193157475-1542849698-1002 Utilisateur 3
Le clonage ou le duplicat d’une installation sans effectuer les étapes recommandées peut entraîner des SID en
double. Pour les supports amovibles, un SID en double peut donner à un compte l’accès aux fichiers même si les
autorisations NTFS pour le compte refusent spécifiquement l’accès à ces fichiers. Étant donné que le SID identifie
à la fois l’ordinateur ou le domaine et l’utilisateur, des SID uniques sont nécessaires pour maintenir la prise en
charge des programmes actuels et futurs. Pour plus d’informations sur les problèmes qui peuvent se produire si
vous clonez une installation de Windows 8 ou de Windows Server 2012, accédez à la Windows 8 et Windows
Server 2012 section d’informations spécifique.
Outre le SID de l’ordinateur, de nombreux autres composants et fonctionnalités doivent être nettoyés,
généralisés ou spécialisés pour être imagenés. Voici quelques exemples :
Journaux d’événements
Paramètres réseau
paramètres du lecteur multimédia Windows
Paramètres de l’interpréteur de commandes
Licences
NOTE
Il ne s’agit pas d’une liste complète.
Nous prenons en charge les systèmes d’exploitation suivants qui sont préparés à l’aide de l’utilitaire Sysprep,
puis image :
Windows NT Workstation 4.0
Windows NT Server 4.0 (serveur autonome, pas contrôleurs de domaine principaux ou contrôleurs de
domaine de sauvegarde)
Windows 2000 Professionnel
Windows serveur 2000 (doit être image avant d’exécuter DCPromo)
Windows 2000 Advanced Server
Windows XP Édition familiale
Windows Server 2003, Standard Edition
Windows Server 2003, Datacenter Edition
Windows Server 2003, Enterprise Edition
Windows Server 2003, Web Edition
Toutes les versions de Windows Vista
Toutes les versions de Windows Server 2008
Toutes les versions de Windows 7
Toutes les versions de Windows Server 2008 R2
Toutes les versions de Windows Server, version 1909
Nous ne prenons pas en charge les ordinateurs configurés à l’aide d’outils de duplicatation SID autres que l’outil
de préparation du système. Par exemple, cela inclut les éléments suivants :
Newsid
GhostWalker
technique. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas
l'exactitude des informations concernant les sociétés tierces.
NOTE
Si une image a été créée sans utiliser Sysprep, nous ne prenons pas en charge l’exécution de Sysprep après le déploiement
de l’image pour rétablir la conformité de l’ordinateur. Sysprep doit être exécuté avant la capture de l’image.
Windows 8 et Windows Server 2012 des informations spécifiques

Si vous clonez une Windows 8 ou Windows Server 2012 image ou machine virtuelle sans l’exécuter
sysprep.exe /generalize , P2V et maintenez l’ordinateur physique en cours d’exécution ou créez une sauvegarde
d’un ordinateur, mais que l’ordinateur d’origine s’exécute, vous pouvez rencontrer des problèmes dans lesquels
les notifications Push ne fonctionnent pas. Par exemple, vous pouvez rencontrer les problèmes suivants :
Les notifications par vignette, badge et toast ne sont pas mises à jour même si la connectivité Internet est
disponible.
Les applications qui s’appuient sur la notification RAW ne fonctionnent pas comme prévu. Par exemple, vous
remarquez une réduction significative des fonctionnalités dans la messagerie, le calendrier et la messagerie.
La synchronisation des modifications des paramètres d’itinérance et de sécurité familiale prend beaucoup de
temps. Pour résoudre ces problèmes, utilisez l’une des méthodes suivantes :
Configurez les ordinateurs à l’aide de la commande Sysprep /generalize, puis déployez l’image.
Remplacez le compte d’utilisateur existant par un nouveau compte. L’identificateur de l’appareil est stocké
dans le cadre du profil utilisateur. Chaque nouveau compte NTUser ajouté à un ordinateur recevra un nouvel
identificateur.
References
Pour plus d’informations sur l’outil de préparation du système Windows, visitez les sites web Microsoft suivants :
Windows Server 2003 Qu’est-ce que Sysprep ?
Vue d’ensemble de Windows 8 et Windows Server 2012 Sysprep
produits.
Requêtes Andx en lecture SMB pour les fichiers
gérés par Déduplication des données erreur dans
Windows Server 2012 : La demande n’est pas prise
en charge
Cet article aide à corriger les erreurs qui se produisent dans les requêtes SMB Read Andx pour les fichiers gérés
par Déduplication des données.
Symptômes
Serveur : Windows Server 2012 RTM, avec le paramètre de volume [x] Activer la déduplication des données
Clients SMB v1 : Windows XP SP3, clients CIFS tiers (Macintosh, Unix Samba)
Les clients Windows XP ne peuvent pas ouvrir de fichiers sur les partages Server 2012.
Seuls les fichiers dédupliqués (avec la taille >32 Ko) ne sont pas accessibles sur le volume, les fichiers
développés sont accessibles.
Les messages d’erreur peuvent varier en fonction du type d’accès et du fichier d’accès aux applications sur le
partage Server 2012 avec Déduplication des données.
Explorer : Copier le fichier
Une erreur inattendue vous empêche de copier le fichier. Si vous continuez à recevoir cette erreur,
vous pouvez utiliser le code d’erreur pour rechercher de l’aide sur ce problème.
Erreur 0x80070032 : la demande n’est pas prise en charge.
ou
Erreur lors de la copie d’un fichier ou d’un dossier
Impossible de copier <filename>: impossible de lire à partir du fichier source ou du disque.
ou
Impossible de copier <filename>: la demande n’est pas prise en charge.
Office : Microsoft Excel '
filename.xls' est accessible. Le fichier peut être en lecture seule ou vous essayez peut-être d’accéder à
un emplacement en lecture seule. Ou bien, le serveur sur lequel le document est stocké peut ne pas
répondre.
ou
Impossible d’ouvrir « filename.xls ».
Microsoft Word
Impossible d’ouvrir « filename.doc ».
Adobe : Ouvrir un fichier récent
Une erreur s’est produite lors de l’ouverture de ce document. Accès refusé.
Navisworks
Autodesk Navisworks Simulate 2011
Impossible de charger <filename.nsd> , car le contenu est endommagé
Accès refusé
ERROR_ACCESS_DENIED
La trace réseau montre STATUS_NOT_SUPPORTED pour les requêtes Andx en lecture SMB1 :
1819 <DateTime> XPclient 2012Srv SMB NT Create AndX Request, FID: 0xc003, Path: \Test-Dedup-file.pdf
1820 <DateTime> 2012Srv XPclient SMB NT Create AndX Response, FID: 0xc003
AllocationSize : 0
EndOfFile : 51362
1829 <DateTime> XPclient 2012Srv SMB Read AndX Request, FID: 0xc003, 32768 octets au décalage 0
1830 <DateTime> 2012Srv XPclient SMB Read AndX Response, FID: 0xc003, 0 octets, Erreur :
STATUS_NOT_SUPPORTED
NTStatus : 0xC00000BB, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_ERROR, Code = (187)
STATUS_NOT_SUPPORTED
Code d’erreur 0xc00000bb = STATUS_NOT_SUPPORTED
ou 0x80070032 = ERROR_NOT_SUPPORTED = La demande n’est pas prise en charge.
NOTE
La même action sur un client Windows 7 avec le protocole SMBv2 fonctionne
testé sur le client Windows 7 avec SMB2 : OK
testé sur le client Windows 7 avec SMB1 : échec (SMB2 désactivé à l’aide des informations de la Base de connaissances)
Comment détecter, activer et désactiver SMBv1, SMBv2 et SMBv3 dans Windows
Server 2012 sans paramètre de volume [ ] Activer la déduplication des données
Start-DedupJob E : -Type unOptimization
Applets de commande de déduplication dans Windows PowerShell
Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. Tous droits réservés.
PS C:\Windows\system32> DedupStatus
Get-DedupStatus : renvoie un objet DeduplicationStatus pour chaque volume contenant des métadonnées de
déduplication des données.
Get-DedupSchedule : retourne les objets DeduplicationJobSchedule définis sur le système.
Get-DedupJob : retourne l’état et les informations pour les travaux de déduplication en cours d’exécution ou en
file d’attente.
Update-DedupStatus : analyse un ou plusieurs volumes spécifiés pour calculer des informations d’économies de
déduplication de données actualisées et retourne un objet DeduplicationStatus.
obtenir l’état le plus récent du travail d’inoptimisation en exécutant la commande Get-DedupJob PowerShell
Signalés sur :
Déduplication windows 2012 - Partage d’accès à partir de Windows XP / 7
Cause
Problème d’interopérabilité des composants Dedup, SMB et EnableECP d’entrée non par défaut dans le
Registre du serveur :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanManServer\Parameters
EnableAuthenticateUserSharing REG_DWORD 0x0
ServiceDllUnloadOnStop REG_DWORD 0x1
ServiceDll REG_EXPAND_SZ %SystemRoot%\system32\srvsvc.dll
NullSessionPipes REG_MULTI_SZ
autodisconnect REG_DWORD 0xf
enableforcedlogoff REG_DWORD 0x1
enablesecuritysignature REG_DWORD 0x0 //default = 0x1
requiresecuritysignature REG_DWORD 0x0
restrictnullsessaccess REG_DWORD 0x1
Lmannounce REG_DWORD 0x0
Taille REG_DWORD 0x3
AdjustedNullSessionPipes REG_DWORD 0x3
ClusterPipes REG_MULTI_SZ FssagentRpc
CachedOpenLimit REG_DWORD 0x0 //default = 0x5
>> enableecp REG_DWORD 0x1 << //default = 0x0 ou non défini
Guid REG_BINARY DEF9D10A080B9241932038A7E77DFC2D
NOTE
Cela se produit après l’installation de McAfee ver. 8.8 VirusScan Enterprise + AntiSpyware Enterprise.
La désinstallation de ce produit laisse toujours enableecp=1 derrière, vous devez donc supprimer manuellement la clé de
Registre enableecp .
Résolution
Nous pensons que le problème est dû à l’interopérabilité entre trois composants Dedup, SMB et des tiers tels
que « VMware vShield Endpoint driver (VSEPFLT.SYS) », si la clé de Registre suivante a été définie manuellement
ou par une installation de logiciels tiers :
HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\enableecp = 1
Pour résoudre le problème de déduplication :

Supprimer l’entrée de Registre « EnableECP »
et
1. Redémarrer
ou
2. Redémarrez le service serveur, dans un type de fenêtre CMD avec élévation de privilèges :
NET STOP SERVER && NET START SERVER
NOTE
les étapes ci-dessus ne résolvent pas le problème : il peut y avoir d’autres problèmes liés à l’application :
Lorsque les fichiers dédupliqués sont accessibles à l’aide d’une application comme Adobe sur SMB, il peut échouer.
Adobe a confirmé un problème connu avec Adobe Reader lors de l’accès aux fichiers PDF sur un serveur 2012 avec
des fichiers dédupliqués.
Adobe a résolu le problème à partir de la version 10.3.x. Actuellement, la dernière version d’Adobe Reader
disponible est 11.0.
Voici l’article sur la déduplication du serveur de fichiers PDF 2012 RTM à l’origine de problèmes de fichier PDF
Ce problème est résolu dans la version (10.1.4) d’Acrobat Reader.
État depuis le 8 mars : Réponse du support McAfee : Nous étudions activement la valeur « enableecp » utilisée
dans notre produit et l’impact (le cas échéant) du rétablissement de cette valeur à 0 ou même de la suppression
totale de la valeur.
Si le client s’appuie sur la déduplication des données sur le serveur 2012 accessible par les clients XP dans son
environnement, la recommandation pour l’instant est de définir la clé sur 0 conformément à la suggestion MSFT
pour garantir le bon fonctionnement de l’environnement jusqu’à ce que nous ayons terminé notre investigation
et en arriveons à une conclusion sur la meilleure façon d’aborder ce problème.
KB77623 - est actuellement dans le pipeline et sera publié dans les 5 à 6 prochains jours de travail, la Base de
connaissances sera mise à jour à mesure que notre enquête progresse et plus de détails seront disponibles. Il
contient actuellement une vue d’ensemble du problème et la solution de contournement décrite par MSFT.
19 mars : la Base de connaissances a été publiée et devrait être accessible publiquement par le biais de la base
de connaissances McAfee. L’examen entourant la valeur « enableecp » est en cours.
Les clients Windows 7 ne peuvent pas accéder aux partages sur Windows Server 2012 lorsque Déduplication
des données est activé
Plus d'informations
Info re. Déduplication sur Microsoft Server 2012
Présentation de Déduplication des données dans Windows Server 2012
Vue d’ensemble Déduplication des données
interopérabilité Déduplication des données
Informations sur ECP :
Nouveautés du développement de pilotes
Améliorations apportées aux paramètres de création supplémentaires (ECP)
Le recyclage des ECP précédemment alloués est nouveau dans Windows 8. Pour éviter la surcharge liée à la
libération d’un ecp lors de la fermeture d’un fichier, puis à l’allocation d’un nouveau fichier par la suite, un pilote
de filtre de système de fichiers ou de système de fichiers peut réutiliser un ECP existant.
Server & Tools Blogs > Server & Management Blogs > The Storage Team at Microsoft - File Cabinet
Stockage chez Microsoft
Les fichiers sont endommagés sur les volumes
déduplicés qui ont été créés en tant que compressés
NTFS
Cet article fournit une solution à un problème dans lequel les fichiers ne peuvent pas être ouverts et sont
consignés comme endommagés sur des volumes déduplicés.
Symptômes
Les utilisateurs ne peuvent plus ouvrir de fichiers sur un volume activé pour la déduplication qui a été créé en
activé la compression NTFS à la racine du volume. En outre, le travail de nettoyage de la déduplication des
données peut enregistrer un événement dans le journal des événements pour signaler une altération du volume
de fichiers qu’il ne peut pas réparer.
Cause
Ce problème se produit car les métadonnées de déduplication stockées sur la racine de volume compressée
sont endommagées lorsqu’un processus écrit sur place dans un fichier sur le volume dédupliqué. Les
métadonnées de déduplication stockées sur la racine de volume compressée se trouvent sous le dossier System
Volume Information (SVI).
La duplication n’est pas prise en charge sur les volumes dont la compression est activée à la racine lors de la
création du volume. Toutefois, la déduplication sur les dossiers compressés est prise en charge et fonctionne
comme prévu.
Résolution
Pour résoudre ce problème, n’activez pas la déduplication des données sur un volume NTFS sur qui la
compression au niveau du volume est activée.
Malheureusement, nous ne pouvons pas restaurer les données qui sont déjà endommagées sur les volumes
compressés existants pour qui la déduplication est activée. Les fichiers qui ont déjà été endommagés doivent
être restaurés à partir des sauvegardes, si elles sont disponibles.
Pour décompresser le dossier de métadonnées de déduplication afin que les actions d’écriture dans les fichiers
dédupliqués sur ce volume ne soient plus endommagées, suivez ces étapes.
NOTE
Dans les exemples de commandes, est un volume qui a été créé en tant que compressé et sur qui la <X> déduplication
des données est activée.
1. Téléchargez l’outil PsExec à partir Windows site web Sysinternals : PsExec v2.2
NOTE
L’outil PsExec permet aux utilisateurs d’exécuter des processus en ayant des droits d’utilisateur « SYSTEM ». Cela
est nécessaire pour accéder au dossier de métadonnées de déduplication des données protégées qui se trouve
dans le dossier System Volume Information.
2. Bloquer l’accès aux données pour vos utilisateurs sur le volume concerné. Pour ce faire, exécutez la
commande Windows PowerShell disable-dedupvolume :
disable-dedupvolume X: -dataaccess
NOTE
Cette commande démonte puis démonte le volume sans que le filtre de déduplication des données ne soit
attaché. Cela empêche les utilisateurs d’accéder aux fichiers déduplicés.
L’action de démontage invalide les handles de fichiers ouverts sur ce volume.
3. Utilisez PsExec pour exécuter Cmd.exe en tant qu’utilisateur « SYSTEM ». Pour ce faire, exécutez la
commande suivante :
Psexec.exe -i -s cmd
NOTE
La fenêtre d’invite de commandes s’ouvre désormais en assignant des droits d’utilisateur « SYSTEM ».
Cau t i on
Le compte « SYSTEM » est un compte d’utilisateur dont le niveau d’accès est beaucoup plus élevé qu’un
compte d’administrateur. Les utilisateurs doivent prendre soin d’effectuer uniquement les étapes
mentionnées dans l’article pendant qu’ils exécutent le compte « SYSTEM ». Les utilisateurs doivent être
particulièrement attentifs à ne pas modifier les ACA ou à prendre possession du dossier Informations sur
le volume système.
4. Dans la fenêtre d’invite de commandes PsExec, recherchez le dossier Informations sur le volume système
de votre volume concerné.
5. Vérifiez que le dossier de métadonnées de déduplication du volume est actuellement compressé.
6. Décompresser le dossier de métadonnées de déduplication du volume.
7. Dans la fenêtre d’invite de commandes PsExec, exécutez la commande suivante :
X:\System Volume Information>compact /s:Dedup
Le résultat inclut le message récapitulatif suivant :
Des fichiers M dans les répertoires N

<X> sont compressés <Y> et ne sont pas compressés.
Si <X> la valeur est supérieure à zéro (0), allez à l’étape 8. Dans le cas contraire, allez à l’étape 11, car
votre dossier de métadonnées de déduplication n’est pas compressé.
8. Dans la fenêtre d’invite de commandes PsExec, exécutez la commande suivante :
X:\System Volume Information>compact /u /s:Dedup
9. Attendez que le dossier de métadonnées de déduplication ne soit pas compressé. Le processus

fonctionne sur un fichier à la fois et peut être lent.
NOTE
Le temps requis par ce processus est proportionnel à la quantité de données sur le volume. Pour les volumes qui
contiennent des téraoctets de données, ce processus peut prendre plusieurs heures. Une fois l’état terminé, la
commande se quitte et génère le message d’état suivant :
Les fichiers N dans les répertoires M n’ont pas été compressés.
10. Dans la fenêtre d’invite de commandes PsExec, exécutez la commande « État de compression d’affichage
» suivante pour vérifier qu’il n’existe aucun fichier compressé dans le dossier de métadonnées de
déduplication des données.
X:\System Volume Information>compact /s:Dedup
11. Fermez la fenêtre d’invite de commandes PsExec.

12. Ré-activez l’accès aux données pour vos utilisateurs sur le volume concerné. Pour ce faire, exécutez la
commande suivante :
Enable-DedupVolume X: -DataAccess
NOTE
Cette commande démonte, puis démonte le volume avec le filtre de déduplication des données attaché. Les
utilisateurs pourront désormais accéder aux fichiers déduplicés.
L’action de démontage invalide les handles de fichiers ouverts sur ce volume.
NOTE
Pour éviter que des altérations similaires ne se produisent, exécutez cette procédure sur tous les volumes à déduplication
qui ont été créés en mode compressé.
L’évolution d’un garbage collection complet
pendant la déduplication peut entraîner des
problèmes de performances dans Windows Server
Cet article fournit des solutions de contournement pour les problèmes de performances causés par l’évolution
du garbage collection complet lors de la déduplication.
Symptômes
Les travaux de garbage collection complets récupèrent plus d’espace libre que le garbage collection « normal ».
Toutefois, le garbage collection complet génère beaucoup plus d’évolution sur le volume. Cela est dû au fait que
chaque conteneur de blocs est compacté (réécrit) s’il existe des blocs non indiqués.
Cette évolution sur le volume peut entraîner les problèmes et effets secondaires suivants :
Suppression des copies de l’ombre du service VSS (Volume Shadow Copy Service)
Charge élevée d’opérations d’opérations d’É/S sur le système, en particulier si le serveur exécute déjà une
charge de travail de déduplication à fort taux d’activité ou intensive d’opérations d’IO
Augmentation des charges de travail en volume pour certaines solutions (telles que la sauvegarde
incrémentielle et la réplication de fichiers) qui augmentent en raison de l’évolution des fichiers
Cause
Ce comportement peut se produire dans les situations suivantes :
Lorsqu’une charge de travail inclut de nombreuses suppressions de fichiers ou écritures sur place. Cela
entraîne l’inférence de nombreux blocs. Les problèmes sont également déclenchés par des suppressions qui
entraînent la compaction de nombreux conteneurs de blocs avec des blocs anciens et nouveaux.
Lorsqu’un système dispose d’un espace libre physique relativement faible, NTFS utilise d’abord de l’espace
libre qui ne provoque pas la consommation de la zone de stockage du shadow copy. Si le volume dispose de
peu d’espace libre, NTFS alloue de l’espace pour les nouveaux fichiers dans les zones qui déclenchent le
comportement « copier sur écriture ». Lorsque la zone de stockage est à court, VSS supprime les copies de
l’ombre.
Pour contourner ces problèmes, utilisez l’une des méthodes suivantes :
Configurez VSS pour utiliser un volume distinct (éventuellement dédié) pour sa zone de diff ( « zone de
stockage d’ombre »). Pour ce faire, vous pouvez utiliser Vssadmin.exe et d’autres outils. Cette solution de
contournement vous aide à contourner le problème de suppression des copies de l’ombre.
NOTE
Il existe d’autres avantages en matière de performances si la zone de diff est sur les volumes dédiés.
Configurez la déduplication non pas pour exécuter la gc complète, mais pour exécuter le garbage
collection uniquement en mode normal. Par défaut, les travaux de collecte de la garbage collection sont
programmés pour s’exécuter toutes les semaines. Par ailleurs, par défaut, chaque quatrième travail de
collecte de la garbage collection est définie pour s’exécuter en GC complet (sur une cadence mensuelle).
NOTE
Vous pouvez exécuter le GC complet à la demande en exécutant manuellement la commande Windows PowerShell
suivante :
Start-DedupJob <volume> -Type GarbageCollection -Full
Pour empêcher la gc complète, configurez la clé de Registre suivante :

HKLM\System\CurrentControlSet\Services\ddpsvc\Settings /v DeepGCInterval /t REG_DWORD /d 0xffffffff
Si le système est en cluster, vous devez configurer la clé de Registre suivante à la place :
HKLM\CLUSTER\Dedup\ /v DeepGCInterval /t REG_DWORD /d 0xffffffff
Cette solution de contournement permet de réduire tous les effets secondaires décrits dans la section «
Symptômes ». Toutefois, le nettoyage de la garbage en mode normal n’est pas aussi approfondi que la gc
complète. Certains blocs de déduplication non déférés peuvent ne pas être récupérés si le système n’exécute
jamais la gc complète. Néanmoins, le garbage collection en mode normal doit toujours récupérer plus de 95 %
des données non référées.
Sur un système qui s’exécute Windows Server 2012, assurez-vous que le correctif logiciel 2897997 installé.
(Cela n’est pas nécessaire pour Windows Server 2012 R2.)
Problèmes connus après l’activement de la
déduplication des données sur CSV
Cet article décrit certains problèmes connus qui peuvent se produire après l’application de la déduplication des
données sur CSV.
Résumé
La déduplication des données dans Windows Server 2012 R2 prend en charge l’optimisation du stockage pour
les déploiements VDI (Virtual Desktop Infrastructure) et l’optimisation des volumes partagés de cluster (CSV). La
déduplication des données est prise en charge sur le fichier CSV au format NTFS et n’est pas prise en charge sur
le fichier CSV au format CSV au format ReFS (Resilient File System).
Problèmes connus
Problème 1
La propriété LastWriteTime d’un fichier est modifiée au moment où le fichier est traitée par un travail
d’optimisation de la déduplication des données. En outre, le bit d’archivage du fichier est réinitialisé
lorsque le travail d’optimisation de la déduplication des données est terminé.
Ce comportement n’affecte pas les performances de production ou ne limite pas l’accès aux fichiers
stockés sur le fichier CSV. Toutefois, ce comportement peut affecter certaines applications de sauvegarde
qui utilisent le bit d’archivage ou la propriété LastWriteTime pour détecter les modifications
incrémentielles de fichiers. Par exemple, lorsque les propriétés de fichier sont modifiées par un travail
d’optimisation de la déduplication des données, l’application de sauvegarde peut être déclenchée pour
sauvegarder à nouveau les fichiers.
Problème 2
Lorsque vous utilisez l’cmdlet pour interroger l’état d’un travail de déduplication des données sur un
volume CSV à partir d’un nœud de cluster passif (non-coordinateur), vous recevez une erreur
ressemblant à ce qui suit Update-DedupStatus :
Update-DedupStatus : MSFT_DedupVolumeStatus.Volume=' <CSV volume path> ' - HRESULT

0x80565364, 0x80565304, 0x8056536B
En outre, vous recevez l’un des messages d’erreur suivants :
La déduplication des données ne peut pas exécuter ce travail sur ce volume CSV sur ce nœud.
Essayez d’exécutez le travail sur le nœud propriétaire de la ressource en volume CSV.
La déduplication des données ne peut pas exécuter cette cmdlet sur ce volume CSV sur ce nœud.
Essayez d’exécutez l’cmdlet sur le nœud propriétaire de la ressource de volume CSV.
Ce comportement est attendu, car l’état du travail peut être interrogé uniquement à partir du nœud du
coordinateur. Pour obtenir l’état du travail de déduplication des données, connectez-vous au nœud
coordinateur, puis exécutez la Update-DedupStatus cmdlet.
La déduplication des données a été introduite dans Windows Server 2012. L’activation de la déduplication des
données réduit le nombre de blocs de données en double dans le stockage afin que davantage de données
soient stockées. La déduplication des données est hautement évolutive, efficace en ressources et non importante
et peut s’exécuter sur des dizaines de volumes importants de données primaires en même temps, mais n’avoir
qu’un impact minime sur la charge de travail du serveur. Pour plus d’informations, voir Vue d’ensemble de la
déduplication des données et À propos de la déduplication des données.
L’erreur 10013 (WSAEACCES) est retournée
lorsqu’une deuxième liaison à un port exclu échoue
dans Windows
Cet article vous aide à résoudre un problème où vous ne pouvez plus lier un port exclu, même si l’option
SO_REUSEADDR est définie.
Symptômes
Supposons que vous excluez un port en exécutant la commande suivante sur un ordinateur qui exécute
Windows Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2 :
netsh int ipv4 add excludedportrange protocol = tcp startport = Integer numberofports = 1
En outre, supposons que vous liez le socket SO_REUSEADDR à un port TCP spécifique sur l’ordinateur. Dans ce
cas, lorsque vous essayez de lier à nouveau le socket SO_REUSEADDR au port TCP, la liaison échoue et vous
recevez l’erreur « WSAEACCES (10013) ».
Par conséquent, si vous utilisez une application qui appelle les deux liaisons dans Windows Server 2012 R2,
Windows Server 2012 ou Windows Server 2008 R2, elle ne peut pas fonctionner correctement.
NOTE
Par défaut, Windows Server 2008 R2 ne peut pas utiliser la netsh commande pour exclure les ports. Toutefois, après
avoir appliqué le correctif logiciel 2665809, le système d’exploitation prend en charge cette fonction.
Ce problème ne se produit pas dans Windows Server 2008 ou Windows Server 2003.
Cause
Ce problème se produit en raison d’un problème dans le pilote tcpip.sys. Plus précisément, l’indicateur REUSE a
été remplacé par l’indicateur RESERVED lorsque le pilote tcpip.sys lie un port exclu.
Pour contourner ce problème, appliquez l'une des méthodes suivantes :
Utilisez un port qui n’est pas inclus dans la plage de ports dynamiques par défaut (de 49 152 à 65 535) et ne
spécifiez pas le port comme port exclu en exécutant la netsh commande.
Utilisez les fonctions CreatePersistentTcpPortReservation et LookupPersistentTcpPortReservation pour
réserver un port.
État
Microsoft a confirmé l’existence de ce problème dans les produits Microsoft répertoriés dans la section
« Produits concernés ».
Consultez la fonction setsockopt pour en savoir plus sur l’option SO_REUSEADDR.
Le Gestionnaire de ressources du serveur de fichiers
n’a pas pu charger les objets WMI dans Windows
Server
Cet article permet de résoudre une erreur qui se produit lors du démarrage du Gestionnaire de ressources du
serveur de fichiers dans Windows Server.
Symptômes
Lorsque vous démarrez le Gestionnaire de ressources du serveur de fichiers dans Windows Server, vous pouvez
recevoir le message d’erreur suivant :
Le Gestionnaire de ressources du serveur de fichiers n’a pas pu charger les objets WMI sur « Nom du
serveur ».
Si vous interrogez la classe WMI sous la gestion des Windows FSRM Microsoft racine alors que l’erreur décrite a
été signalée, vous pouvez recevoir l’erreur MSFT_FSRMSettings \ \ \ WMI suivante :
Erreur 0x80041001 (échec générique).
Cause
Ce problème se produit parce que le service Windows Management Instrumentation est redémarré après le
service FSRM et qu’un nouveau chargement/inscription du fournisseur FSRM est nécessaire.
Résolution
Pour résoudre ce problème, redémarrez le service FSRM.
Si vous remarquez qu’il s’agit d’un problème récurrent, deux actions sont nécessaires :
Vérifiez et examinez l’Windows service Management Instrumentation est un problème de redémarrage pour
résoudre le comportement.
Ajoutez une dépendance pour le service FSRM dans le Registre, afin qu’il soit redémarré lors du redémarrage
du service WMI. Pour ajouter la dépendance dans le Registre, suivez les étapes suivantes :
1. Dans l’écran d’accueil, cliquez sur la vignette Rechercher.
2. Tapez regedit dans la fenêtre Recherche, puis double-cliquez sur regedit.exe.
3. Recherchez l’entrée de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\srmsvc
4. Dans le volet droit, cliquez avec le bouton droit sur DependOnSer vice, puis cliquez sur
Modifier.
5. Ajoutez WINMGMT à la valeur multi string .
6. Cliquez sur OK, puis quittez l’éditeur du Registre.
7. Redémarrez l’ordinateur.
Dans un cas particulier, l’Windows Management Instrumentation est redémarré dans le cadre d’une action de
reconstruction du référentiel WMI. Dans ce cas, un examen serait nécessaire pour savoir pourquoi le référentiel
WMI est en cours de reconstruction.
Si vous exécutez SCCM 2012, assurez-vous que vous n’exécutez pas le comportement décrit dans l’article
suivant :
Échec des points de gestion Configuration Manager après l’échec de la tâche d’évaluation de l’état du client
L’utilisation du quota FSRM est incorrecte lorsque
vous modifiez la taille du fichier de page dans
Windows
Cet article fournit une solution de contournement pour un problème dans lequel l’utilisation du quota du
Gestionnaire de ressources du serveur de fichiers (FSRM) est incorrecte.
Symptômes
Ce problème se produit sur un ordinateur qui exécute Windows Server 2012 R2 pour qui la fonctionnalité FSRM
est activée.
Cause
Ce problème se produit car la gestion des données FSRM détecte que la taille du fichier de page est exclue dans
le quota FSRM.
Exécutez la commande dans Windows PowerShell pour effectuer à nouveau Update-FsrmQuota-path paths
l’analyse et recalculer les informations d’utilisation du quota.
Statut
Ce comportement est normal.
Références
Quota Dirquota
Informations générales sur l'Update-FsrmQuota cmdlet
Liste des correctifs logiciels actuellement disponibles
pour les technologies des services de fichiers dans
Windows Server 2008 et Windows Server 2008 R2
Cet article répertorie les correctifs logiciels actuellement disponibles pour les utilisateurs qui ont installé les
technologies des services de fichiers sur un ordinateur basé sur Windows Server 2008 ou sur un ordinateur
S’applique à : Windows 7 Service Pack 1, Windows Server 2008 R2, Windows Server 2008
Résumé
Les services de fichiers fournissent des technologies qui vous permettent de gérer le stockage, d’activer la
réplication de fichiers, de gérer les dossiers partagés, de garantir une recherche rapide de fichiers et d’activer
l’accès UNIX ordinateurs clients. Cet article répertorie également les correctifs qui sont actuellement disponibles
pour les utilisateurs qui utilisent les services de fichiers à partir d’ordinateurs Windows Vista ou d’ordinateurs
Windows 7.
Cet article contient des listes d’articles de la Base de connaissances Microsoft qui décrivent les correctifs
actuellement disponibles. L’article est divisé en deux sections. La première section s’applique à Windows Server
2008 R2 et à Windows 7, et la deuxième section s’applique à Windows Server 2008 et Windows Vista. Chaque
section est divisée en sous-sections pour différents pilotes de composants : SRV, MRXSMB et RDBSS. En règle
générale, les pilotes SRV doivent être mis à jour sur le serveur ou l’ordinateur client qui héberge les données.
Les pilotes MRXSMB et RDBSS doivent être mis à jour sur le serveur ou l’ordinateur client qui lance l’accès aux
données. Si vous ne savez pas quel composant doit être mis à jour sur quel ordinateur, vous pouvez mettre à
jour les trois pilotes de composants à la fois sur l’ordinateur qui héberge les données et sur l’ordinateur qui
accède aux données.
Windows Server 2008 R2 et Windows 7

Composant NTFS
A RT IC L E DE L A P O URQ UO I N O US T Y P E ET
B A SE DE REC O M M A N DO N S DISP O N IB IL IT É DES
DAT E D’A JO UT C O N N A ISSA N C ES T IT L E C E C O RREC T IF C O RREC T IF S
08/08/2016 3121255 0x00000024'erreur Ce correctif contient Pour appliquer ce

d’arrêt dans la version la plus correctif, vous devez
FsRtlNotifyFilterRep récente de ntfs.sys. avoir installé
ortChange et la Windows 7 SP1 ou
sauvegarde VSS du (LDR) Windows Server
serveur de données 2008 R2 SP1.
personnelles Disponible pour
échoue dans téléchargement
Windows individuel.
Composant SRV
12 mai 2016 3161561 MS16-075 et Ce correctif contient Pour appliquer cette

MS16-076 : la version la plus mise à jour de
Description de la récente de sécurité, vous devez
mise à jour de srvnet.sys, srv.sys avoir installé
sécurité pour et srv2.sys. Windows 7 SP1 ou
Windows Netlogon Windows Server
et SMB Server : 14 (LDR) 2008 R2 SP1.
juin 2016 Disponible pour
téléchargement
individuel.
Composant MRXSMB
12 mai 2016 3161561 MS16-075 et Ce correctif de Pour appliquer ce

MS16-076 : sécurité contient la correctif de sécurité,
Description de la version la plus vous devez avoir
mise à jour de récente de installé Windows 7
sécurité pour mrxsmb.sys, SP1 ou Windows
Windows Netlogon mrxsmb10.sys Server 2008 R2
et SMB Server : 14 et mrxsmb20.sys. SP1. Disponible
juin 2016 (LDR) pour
téléchargement
individuel.
Composant RDBSS
12 mars 2015 3044428 0x00000027 ou Ce correctif contient Pour appliquer ce

0x00000050'erreur la version la plus correctif, vous devez
d’arrêt dans le récente de avoir installé
pilote Rdbss.sys rdbss.sys. (LDR) Windows 7 SP1 ou
dans Windows 7 Windows Server
SP1 ou Windows 2008 R2 SP1.
Server 2008 R2 SP1 Disponible pour
téléchargement
individuel.
Windows Server 2008 et Windows Vista

Composant NTFS
02/02/2015 2928562 Événement 55 Ce correctif contient Pour appliquer ce

lorsque vous copiez la version la plus correctif, vous devez
un dossier chiffré récente de ntfs.sys. avoir installé
dans un dossier Windows Vista SP 2
partagé EFS dans Windows Server
Windows 2008 SP2.
Disponible à partir
de Microsoft
Update.
Composant SRV
14 mai/2016 3161561 MS16-075 et Ce correctif contient Pour appliquer cette

MS16-076 : la version la plus mise à jour de
Description de la récente de sécurité, vous devez
mise à jour de srvnet.sys, srv.sys avoir installé
sécurité pour et srv2.sys. Windows Vista SP2
Windows Netlogon ou Windows Server
et SMB Server : 14 (GDR/LDR) 2008 SP2 ou
juin 2016 versions ultérieures.
de Microsoft
Update.
Composant MRXSMB
14 mai/2016 3161561 MS16-075 et Ce correctif de Pour appliquer ce

MS16-076 : sécurité contient la correctif de sécurité,
Description de la version la plus vous devez avoir
mise à jour de récente de mrxsmb installé Windows
sécurité pour .sys, mrxsmb10 .sys Vista SP2 ou
Windows Netlogon et mrxsmb20.sys. Windows Server
et SMB Server : 14 (LDR/GDR) 2008 SP 2.
juin 2016 Disponible pour
téléchargement
individuel.
Composant RDBSS
07/07/2015 3000483 MS15-011 : La Ce correctif de Pour appliquer ce

vulnérabilité dans la sécurité contient la correctif de sécurité,
stratégie de groupe version la plus vous devez avoir
peut autoriser récente de rdbss.sys installé Windows
l’exécution de code pour Windows Vista Vista SP2 ou
à distance : 10 SP 2 et Windows Windows Server
février 2015 2008 SP 2. 2008 SP 2.
(LDR/GDR) Disponible pour
téléchargement
individuel.
Clés de Registre Server 2008 R2 introduites avec des correctifs logiciels ou des mises à jour de sécurité :
DAT E C O N N A ISSA N C ES C L É DU REGIST RE
5/15/2009 971277 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Para

Level2Compatibility

SmbServerNameHardeningLevel

ABELevel
Clés de Registre Server 2008 introduites avec des correctifs logiciels ou des mises à jour de sécurité :
DAT E C O N N A ISSA N C ES C L É DU REGIST RE

SrvMaxThreadsPerQueue

ABELevel
Modèle SMB (Server Message Block)

Le modèle SMB (Server Message Block) se compose de deux entités : le client et le serveur.
Sur le client, les applications effectuent des appels système en demandant des opérations sur des fichiers
distants. Ces demandes sont gérées par le sous-système de redirection (rdbss.sys) et par le mini-redirecteur
SMB (mrxsmb.sys), qui les traduisent toutes les deux en sessions de protocole SMB et en demandes sur TCP/IP. À
partir Windows Vista, le protocole SMB 2.0 est pris en charge. Le mrxsmb10.sys gère le trafic SMB hérité et le
pilote mrxsmb20.sys gère le trafic SMB 2.0.
Sur le serveur, les connexions SMB sont acceptées et les demandes SMB sont traitées en tant qu’opérations du
système de fichiers local via NTFS et la pile de stockage locale. Le srv.sys gère le trafic SMB hérité et le pilote
srv2.sys gère le trafic SMB 2.0. Le srvnet.sys implémente l’interface entre la mise en réseau et le serveur de
fichiers pour les deux protocoles SMB. Les métadonnées et le contenu du système de fichiers peuvent être mis
en cache en mémoire via le cache système dans le noyau (ntoskrnl.exe).
L’image suivante fournit une vue d’ensemble des différentes couches par lesquelles une demande utilisateur sur
un ordinateur client doit être effectuée pour effectuer des opérations de fichiers sur le réseau sur un serveur de
fichiers SMB distant à l’aide de SMB 2.0.
Services pour NFS dans un environnement Windows Server 2008 R2

Composants du serveur de système de fichiers réseau (NFS) 2008 R2
12-Mar-2015 3043762 Le processus ne Cette mise à jour de Pour appliquer ce

peut pas accéder à sécurité contient la correctif, vous devez
l’erreur de fichier version la plus avoir installé
lorsque vous ouvrez récente Nfssvc.exe Windows Server
des fichiers à partir et Nfssvr.sys. 2008 R2 SP1.
du serveur NFS Disponible pour
dans Windows (LDR) téléchargement
Server 2008 R2 SP1 individuel.
de Microsoft
Update.
29-Aug-2014 2957486 La commande LS Ce correctif contient Pour appliquer ce

prend beaucoup de la version la plus correctif, vous devez
temps pour ré lister récente de avoir installé
les fichiers partagés Rpcxdr.sys. (GDR Windows Server
dans 2 fenêtres sur LDR) 2008 R2 ou
un serveur NFS Windows Server
Windows 7 ou 2008 R2 SP1.
Windows Server Disponible pour
2008 R2 téléchargement
individuel.
Composants clients NFS
14-Mai-2014 2956990 Le client NFS ne Ce correctif contient Pour appliquer ce

peut pas se la version la plus correctif, vous devez
reconnecter au récente de avoir installé
serveur NFS dans Nfsnp.dll, Windows 7 SP1 ou
Windows 7 SP1 ou Nfsclnt.exe et Windows Server
Windows Server Nfsrdr.sys. 2008 R2 SP1.
2008 R2 SP1 Disponible pour
téléchargement
individuel.
03 avril 2015 3042826 Le sous-système Ce correctif contient Pour appliquer ce

POSIX se crashe la version la plus correctif, vous devez
lorsque vous récente de Psxdll.dll, avoir installé
essayez de créer Psxdllsvr.dll, Windows 7 SP1 ou
une session Telnet Psxss.exe, Posix.exe. Windows Server
dans Windows 2008 R2 SP1.
Disponible pour
téléchargement
individuel.
Services pour NFS dans un environnement Windows Server 2008

Composants serveur NFS
02/02/2014 2923150 Une fuite de Cette mise à jour de Pour appliquer ce

mémoire se produit sécurité contient la correctif, vous devez
sur un serveur de version la plus avoir installé
partage NFS qui récente Nfssvc.exe, Windows Vista SP2
exécute Windows Nfssvr.sys et ou Windows Server
Server 2008 Msnfsflt.sys. 2008 SP2.
de Microsoft
Update.
25/07/2014 2957486 La commande LS Ce correctif contient Pour appliquer ce

prend beaucoup de la version la plus correctif, vous devez
temps pour ré lister récente de avoir installé
les fichiers partagés Rpcxdr.sys. Windows Vista SP2
dans 2 fenêtres sur ou Windows Server
un serveur NFS 2008 SP2.
Windows 7 ou Disponible à partir
Windows Server de Microsoft
2008 R2 Update.
Composants inclus dans les services pour NFS

Serveur pour NFS
Ce composant correspond à l’implémentation côté serveur du protocole de partage de fichiers NFS. Le
serveur pour NFS permet à un ordinateur exécutant Windows Server 2008 R2 d’agir en tant que serveur
de fichiers pour les ordinateurs clients UNIX base de données.
Client pour NFS
Ce composant correspond à l’implémentation côté client du protocole de partage de fichiers NFS. Client
pour NFS permet à un ordinateur Windows exécutant Windows Server 2008 R2 (ou Windows 7)
d’accéder aux fichiers stockés sur un serveur NFS UNIX.
Windows Server 2008 R2 inclut à la fois le serveur pour NFS et le client pour les composants NFS. Toutefois,
Windows 7 inclut uniquement Client pour NFS.
Pour plus d’informations sur le guide pas à pas pour les services pour NFS, consultez des informations
générales sur le guide pas à pas pour les services pour NFS.
Les services Microsoft pour NFS fournissent une solution de partage de fichiers pour les entreprises qui
disposent d’un environnement Windows et UNIX mixtes. Ce modèle de communication se compose
d’ordinateurs clients et d’un serveur. Les applications sur le client demandent des fichiers qui se trouvent sur le
serveur via le redirecteur (Rdbss.sys) et le mini-redirecteur NFS (Nfsrdr.sys). Le mini-redirecteur utilise le
protocole NFS pour envoyer sa demande via TCP/IP. Le serveur reçoit plusieurs demandes des clients via TCP/IP
et les approvisionnement vers le système de fichiers local (Ntfs.sys), qui accède à la pile de stockage.
References
Liste des correctifs logiciels actuellement disponibles pour les technologies de système de fichiers
distribués (DFS) dans Windows Server 2008 et Windows Server 2008 R2.
Un correctif logiciel d’entreprise est disponible pour Windows 7 SP1 et Windows Server 2008 R2 SP1
Liste des correctifs actuellement disponibles pour les technologies des services de fichiers dans Windows
Optimisation des performances pour les serveurs de fichiers
Erreur lors de l’accès aux partages de fichiers sur un
serveur configuré par SOFS : le stockage du serveur
disponible pour traiter cette commande est
insuffisant
Cet article fournit une solution à un problème qui se produit lorsque vous accédez à des partages de fichiers sur
un serveur SMB sur Scale-Out rôle serveur de fichiers configuré.
Symptômes
Vous configurez le rôle serveur de fichiers avec échelle (SOFS) sur un serveur exécutant Window Server
2012 R2.
Vous avez des applications serveur et des clients qui accèdent fréquemment aux partages de fichiers.
Les applications et les clients ouvrent de nombreuses sessions de courte durée dans lesquelles ils se
connectent, s’authentifier, modifier des fichiers et fermer immédiatement la session.
Dans ce scénario, après un certain temps, l’accès aux partages de fichiers échoue et une erreur
STATUS_INSUFF_SERVER_RESOURCES est enregistrée dans une capture réseau.
En outre, lorsque les utilisateurs tentent de se connecter à des partages SOFS, ils reçoivent le message d’erreur
suivant :
Un espace de stockage serveur insuffisant est disponible pour traiter cette commande.
Vous pouvez également constater un nombre élevé de handles Lsass.exe sur les deux nodes de coordinateur et
non-coordinateur du cluster.
NOTE
Si vous faites échouer la ressource disque vers un autre nœud, le problème ne se produit pas temporairement.
Cause
Ce problème se produit car les applications créent de nouvelles sessions chaque fois qu’elles modifient un
fichier au lieu de les réutiliser pour générer de nombreuses modifications de métadonnées.
Le système de fichiers CSV utilise le protocole SMB pour conserver les informations de métadonnées
cohérentes entre les nodes de cluster. Un volume élevé de modifications de métadonnées génère de
nombreuses sessions SMB entre les nœuds non-coordinator et coordinator du cluster et épuise la table SMB sur
le nœud coordinator.
Résolution
Pour résoudre ce problème pour ces types de charges de travail d’application, nous vous recommandons
d’utiliser le rôle serveur de fichiers à usage général au lieu de SOFS.
NOTE
Le rôle SOFS ne doit pas être utilisé si la charge de travail génère un nombre exceptionnellement élevé d’opérations de
métadonnées, telles que l’ouverture et la création de nouveaux fichiers ou le changement de nom des fichiers existants.
Dans une capture réseau entre les nœuds non-coordinator et coordinator, vous voyez qu’après une demande
d’installation de session SMB, le nœud coordinator répond avec une erreur
STATUS_INSUFF_SERVER_RESOURCES de travail.
Il se peut que les partages de fichiers sur les
appareils iSCSI ne soient pas re-créés lorsque vous
redémarrez l’ordinateur.
Cet article fournit une solution à un problème qui peut empêcher la re-création des partages de fichiers lorsque
vous redémarrez l’ordinateur.
Symptômes
Vous utilisez le service d’initiateur Microsoft iSCSI pour vous connecter à un périphérique de disque Internet
SCSI (iSCSI). Les partages de fichiers que vous créez pour les dossiers situés sur votre appareil iSCSI peuvent ne
pas être re-créés lorsque vous redémarrez l’ordinateur sur qui les partages sont créés.
Cause
Le problème peut se produire lorsque le service initiateur iSCSI n’est pas initialisé lors de l’initialisation du
service serveur. Le service serveur crée des partages de fichiers. Toutefois, étant donné que les périphériques de
disque iSCSI ne sont pas disponibles, le service serveur ne peut pas créer de partages de fichiers pour les
appareils iSCSI tant que le service iSCSI n’a pas été initialisé.
Résolution
Initiateur iSCSI 2.x
Pour résoudre le problème dans l’initiateur iSCSI 2.x, suivez les étapes suivantes sur le serveur concerné :
1. Rendre le service serveur dépendant du service initiateur iSCSI. Pour plus d’informations sur cette
procédure, voir la section « Rendre le service serveur dépendant du service initiateur iSCSI ».
2. Configurez les connexions persistantes à la cible. Pour ce faire, utilisez l’une des méthodes suivantes.
NOTE
Si vous voyez la cible sous l’onglet Cible permanente, les étapes suivantes ne sont pas nécessaires.
Méthode 1 : utiliser l’initiateur iSCSI dans le Panneau de contrôle

a.Dans le Panneau de contrôle, double-cliquez sur l’initiateur iSCSI.
b.Sélectionnez l’onglet Cibles.
c.Sélectionnez une cible dans la liste Sélectionner une cible, puis sélectionnez Se connecter.
d.Sélectionnez la case à cocher Restaurer automatiquement cette connexion lorsque le système
démarre, puis sélectionnez OK.
Méthode 2 : utiliser la fenêtre d’invite de commandes
a. Select Star t , select
Exécuter, taper cmd, puis sélectionner
OK .
b. À l'invite de commandes, tapez la commande suivante, puis appuyez sur Entrée :
iscsicli persistentlogintarget **target_iqn** T * * * * * * * * * * * * * * * 0
NOTE
target_iqn est le nom IQN de la cible.
3. Configurez l’option BindPersistentVolumes pour le service d’initiateur iSCSI. Pour ce faire, utilisez l’une
des méthodes suivantes.
Méthode 1 : utiliser l’initiateur iSCSI dans le Panneau de contrôle
a. Dans le Panneau de contrôle, double-cliquez sur l’initiateur iSCSI.
b. Sélectionnez l’onglet Volumes/Périphériques liés.
c. Sélectionnez Lier tout pour lier toutes les cibles persistantes. Vous pouvez également sélectionner
Ajouter, puis entrer une lettre de lecteur ou un point de montage pour lier une cible spécifique.
d. Sélectionnez OK .
Méthode 2 : utiliser la fenêtre d’invite de commandes
a. Sélectionnez Démarrer, Sélectionnez Exécuter, tapez cmd, puis appuyez sur Entrée.
b. Tapez iscsicli BindPersistentVolumes, puis appuyez sur Entrée.
NOTE
Cela est identique à la sélection de l’option Lier tout dans la méthode 1.
NOTE
Utilisez cette résolution uniquement si vous faites face à ce problème spécifique avec la version 2.x du service d’initiateur
iSCSI.
Rendre le service serveur dépendant du service initiateur iSCSI

Utilisez l’une des méthodes suivantes pour rendre le service serveur dépendant du service initiateur iSCSI.
Méthode 1 : utiliser l’utilitaire Microsoft Service Control (Sc.exe)
NOTE
Il n’est pas nécessaire de modifier le Registre lorsque vous utilisez cette méthode. Par conséquent, cette méthode est la
méthode préférée pour définir la dépendance du service.
2. Tapez sc config LanManServer depend= Samss/Srv/MSiSCSI, puis appuyez sur Entrée.
Si vous avez un accès administratif au serveur, vous pouvez exécuter cette commande à partir d’un
ordinateur réseau. Tapez la commande suivante, puis appuyez sur Entrée : sc \ \ computer_name config
LanManServer depend= Samss/Srv/MSiSCSI
IMPORTANT
Microsoft Windows 2000

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer
3. Dans le menu Edition, cliquez sur Ajouter une valeur.

4. Tapez DependOnService dans la zone Nom de la valeur, cliquez REG_MULTI_SZ dans la zone Type de
données, puis appuyez sur Entrée.
5. Dans la fenêtre Éditeur de chaînes multiples, tapez MSiSCSI dans la zone de données, puis cliquez sur
OK .
Vous pouvez écrire un script pour les procédures décrites dans la section « Résolution » à l’aide Sc.exe et
Iscsicli.exe utilitaires. Pour ce faire, créez un fichier de commandes qui utilise ces commandes, puis exécutez-le
directement ou exécutez-le d’une autre manière. Par exemple, exécutez le fichier de lots à l’aide de la stratégie de
groupe.
Microsoft fournit des exemples de programmation à titre d'illustration uniquement, sans garantie expresse ou
implicite. Cela inclut, sans s’y limiter, les garanties implicites de qualité ou d’aptitude à un usage particulier. Cet
article part du principe que vous êtes familiarisé avec le langage de programmation qui est démontré et avec les
outils utilisés pour créer et déboguer des procédures. Les ingénieurs du support Microsoft peuvent expliquer la
fonctionnalité d'une procédure en particulier. Toutefois, ils ne modifient pas ces exemples pour fournir des
fonctionnalités supplémentaires ou construire des procédures pour répondre à vos besoins spécifiques.
Pour écrire un script pour l’ensemble de l’opération décrite dans la section « Résolution », créez un fichier de lots
contenant le texte suivant :
sc config LanManServer depend= Samss/Srv/MSiSCSI

iscsicli BindPersistentVolumes
Le problème peut également se produire pour le stockage non iscsi si le service serveur est démarré avant
l’initialisation du stockage. Dans ce cas, nous pouvons utiliser la solution de contournement ci-dessous, en
supposant que G est la lettre de lecteur que nous voulons surveiller :
1. Enregistrez le script en tant que *.bat fichier.
:Start
dir G: /AH
if %errorlevel% equ 0 goto :OK
ping 127.0.0.1 /n 5
goto :Start
:OK
net stop browser
net stop netlogon
net stop dfs
net stop lanmanserver /y
net start lanmanserver
net start dfs
net start netlogon
net start browser
2. Nous pouvons ajouter le fichier bat à « Script de démarrage » :

a. Placer le fichier de traitement par lots dans
%systemroot%\System32\GroupPolicy\Machine\Scripts\Startup
b. Exécuter pour gpedit ouvrir la stratégie de l’ordinateur local
c. Ajoutez le fichier de lot dans le script de démarrage.
Les limites de taille de disque virtuel iSCSI dans
l’interface graphique graphique du Gestionnaire de
serveur sont incorrectes
Cet article fournit de l’aide pour résoudre les problèmes qui se produisent lorsque vous provisionner de
nouveaux disques virtuels iSCSI Target via l’Assistant Nouveau disque virtuel cible iSCSI à l’aide du fichier
gestionnaire de serveur et de l’interface graphique graphique Stockage Services.
Symptômes
Dans Windows Server 2012 R2, vous pouvez fournir de nouveaux disques virtuels iSCSI Target via l’Assistant
Nouveau disque virtuel cible iSCSI à l’aide du fichier gestionnaire de serveur et de l’interface graphique
graphique Stockage Services. Cet Assistant présente les deux comportements incorrects suivants :
1. L’Assistant bloque à tort toute taille de disque virtuel >= 16 To. Le comportement par défaut consiste à
autoriser jusqu’à 64 To dans Windows Server 2012 R2. Dans ce cas, l’Assistant échoue avec le message
La taille du disque virtuel iSCSI doit être entre 8 Mo et 16 To
2. L’Assistant bloque à tort une taille de disque virtuel dynamique >= espace libre disponible sur le volume
d’hébergement. Le comportement par défaut consiste à autoriser la création de disque virtuel si le fichier
VHDX dynamique initial (généralement de taille de quelques Mo) peut être créé avec succès sur le
volume. Dans ce cas, l’Assistant échoue avec le message d’erreur suivant :
La taille du disque virtuel iSCSI doit être inférieure ou égale à l’espace libre restant sur le volume.
Cause
Le comportement de l’interface utilisateur graphique correspond Windows Server 2012 limites. Dans Windows
Server 2012 R2, la prise en charge de VHDX comme format de stockage par défaut pour les disques virtuels
iSCSI a augmenté la limite supérieure à 64 To et la prise en charge nouvellement ajoutée de VHDX dynamique
signifie également que le volume d’hébergement n’est pas nécessaire pour avoir la capacité d’un disque virtuel
entièrement mis en service à l’avance lorsqu’un disque virtuel dynamique est créé sur ce volume. Ainsi, le
comportement de l’interface utilisateur graphique dans ces cas-là est Windows Server 2012 R2.
Résolution
À compter d’octobre 2013, il n’existe aucune résolution de l’interface graphique graphique pour contourner ces
problèmes d’interface graphique.
Toutefois, la solution de contournement simple consiste à Windows PowerShell à la place, utilisez
New-iSCSIVirtualDisk l’cmdlet. La documentation de la cmdlet est disponible sur New-IscsiVirtualDisk.
Références
serveur cible iscsi dans Windows Server 2012 R2
Limites de Microsoft iSCSI Software Target 3.3 prise
en charge et testées
Cette rubrique présente les limites 3.3 des logiciels Microsoft iSCSI Software Target 3.3 pris en charge et testés.
Résumé
Les tableaux suivants affichent les limites testées et les limites appliquées le cas échéant. En outre, les limites
suivantes s’appliquent :
1. Vous ne devez pas utiliser l’équipe de carte réseau avec Microsoft iSCSI Software Target 3.3 pour la
communication iSCSI.
2. Si vous prévoyez d’utiliser plusieurs cartes réseau pour la communication iSCSI, vous devez les séparer dans
leurs propres sous-réseaux, configurer des adresses IP virtuelles, puis implémenter MPIO.
Configuration de base
IT EM L IM IT E EN F O RC ED C O M M EN TA IRE
Instances cibles iSCSI par 256 Non appliqué

appliance
Initiateurs qui peuvent se 16 Enforced Lorsqu’il est utilisé avec

connecter à la même MPIO, vous ne pouvez pas
instance cible iSCSI connecter plus de 4
sessions par initiateur.
Initiateurs iSCSI par 256 Non appliqué

appliance
Disques virtuels par 256 Non appliqué

appliance
Disques virtuels par 128 Enforced

instance cible iSCSI
Sessions simultanées 64 Enforced

Captures instantanées par 512 Enforced Il existe une limite de 512

disque virtuel captures instantanées par
volume d’application iSCSI
indépendant et de 64
instantanés pour les
volumes de partage de
fichiers. Si les disques
virtuels iSCSI et les
partages de fichiers se
trouve sur un volume
commun, la limite de
capture instantanée iSCSI
est de 448 (512 - 64).
Disques virtuels ou 32 (sur des captures Enforced

captures instantanées instantanées ou autonomes
montés localement par par appliance)
appliance
Tolérance de panne
Nodes de cluster de failover 5 Non appliqué
Niveau de récupération 0 Enforced

d’erreur (ERL)
Connexions multiples par Non pris en charge Enforced

session (MCS)
Connexions simultanées 64 Non appliqué
Multipath Input/Output Pris en charge N/A

(MPIO)
Chemins d’accès MPIO 4 Non appliqué
Disques virtuels sur MPIO 64 Non appliqué Il existe un délai initial après
par initiateur sur un serveur la création des disques
autonome avant qu’ils apparaissent
dans le service de disque
virtuel et le logiciel en snap-
in Gestion des disques, car
PnP détecte d’abord les
périphériques, puis MPIO
détecte les chemins d’accès
pour chaque disque. Cela se
produit une seule fois par
disque et par appliance.
Disques virtuels sur MPIO 32 Non appliqué

par initiateur sur un serveur
d’applications en cluster
Conversion de la cible Pris en charge N/A Aucun disque dur vhd ou

logicielle iSCSI autonome en cible ne sera conservé.
cluster de failover ou vice
versa
Réseau
Nombre maximal de ports 6 Non appliqué S’applique aux ports réseau

réseau actifs dédiés au trafic iSCSI, plutôt
qu’au nombre total de
ports réseau dans
l’appliance.
Vitesse de port réseau 10 gigabits par seconde Non appliqué

(Gbits/s)
IPv4 Pris en charge
IPv6 Pris en charge
Déchargement TCP Pris en charge
Déchargement iSCSI Non pris en charge
Trames Jumbo Pris en charge
IPsec Pris en charge
Disques virtuels iSCSI
IT EM L IM IT E EN F O RC ED
À partir d’un initiateur iSCSI, qui Non pris en charge Non appliqué
convertit le disque cible iSCSI d’un
disque fixe en disque dynamique
Format de taille minimale vhd 8 Mo Enforced
Taille du disque dur vhd parent 2088890 Mo Enforced
Taille VHd fixe 16776703 Mo Enforced
Différence de taille du disque dur dur 2088960 Mo Enforced

dur (VHD)
Format fixe VHD Pris en charge N/A
Format de differencing VHD Pris en charge N/A
Format dynamique VHD Non pris en charge N/A

IT EM L IM IT E EN F O RC ED
FAT/FAT32 (volume d’hébergement de Non pris en charge Non appliqué

disque dur vhd)
NTFS Pris en charge N/A
Taille du cluster NTFS 4 Ko S/O
Non-Microsoft CFS Non pris en charge Enforced
Nombre de disques durs vhd de 256 Non appliqué

différence par disque dur vhd
Nombre de disques durs (VHD) 1 Enforced

parents par disque dur vhd différent
Nombre de systèmes d’exploitation de 1 Non appliqué

démarrage qui peuvent être installés
sur un disque dur vhd
Approvisionnement fin Non pris en charge N/A
Réduction du LUN Non pris en charge S/O
Clonage LUN Non pris en charge N/A
Windows d’exploitation sur lesquels les fournisseurs de matériel VDS et VSS sont pris en charge
SY ST ÈM E D’EXP LO ITAT IO N L IM IT E EN F O RC ED
Windows Server 2003 R2 x64 Pris en charge Enforced
Windows Server 2008 SP2 x64 Pris en charge Enforced
Windows Server 2008 SP2 x86 Pris en charge Enforced
Windows Stockage Server 2008 x64 Pris en charge Enforced
Windows Stockage Server 2008 x86 Non pris en charge Enforced
Windows Stockage Server 2008 R2 Pris en charge Enforced

x64
Tous les systèmes d’exploitation clients Non pris en charge Enforced

(Windows XP, Windows Vista, Windows
7)
Interopérabilité du fournisseur cible de logiciels iSCSI

VERSIO N C IB L E ISC SI VERSIO N DU F O URN ISSEUR ISC SI P RIS EN C H A RGE
3.1 3.1 Pris en charge
3.2 3.1 Non pris en charge
3.2 3.1 (mise à niveau sur place) Non pris en charge
Remarque : les mises à niveau sur place de Microsoft iSCSI Software Target 3.1 vers Microsoft iSCSI Software
Target 3.3 ne sont pas pris en charge. Pour mettre à niveau vers Microsoft iSCSI Software Target 3.3, vous devez
d’abord désinstaller Microsoft iSCSI Software Target 3.1.
Compatibilité du disque virtuel iSCSI Software Target
C RÉÉ DA N S L A VERSIO N M O N T É DA N S L A VERSIO N P RIS EN C H A RGE
3.0 3.1 Non pris en charge
Interopérabilité du logiciel en snap-in Microsoft iSCSI Software Target
L E LO GIC IEL EN SN A P - IN EST

IN STA L L É SUR GEST IO N DE L A C IB L E ISC SI SUR P RIS EN C H A RGE
Windows Storage Server 2008 R2 Windows Storage Server 2008 R2 Pris en charge
Windows Stockage Server 2008 R2, Windows Stockage Server 2008 R2, Pris en charge
serveur autonome nœud de cluster deover
Windows Stockage Server 2008 R2, Windows Stockage Server 2008 R2, Pris en charge
nœud de cluster deover serveur autonome
Divers
IT EM P RIS EN C H A RGE
Installer le composant logiciel en snap-in Microsoft iSCSI Non pris en charge

Software Target 3.3 sur Windows XP, Windows Vista ou
Windows 7
IT EM P RIS EN C H A RGE
Installer le logiciel en snap-in Microsoft iSCSI Software Target Non pris en charge
3.3 sur la version x86 de Windows Stockage Server 2008
Utiliser le logiciel en snap-in Microsoft iSCSI Software Target Pris en charge

3.3 pour gérer la cible logicielle Microsoft iSCSI 3.2
Utiliser le logiciel en snap-in Microsoft iSCSI Software Target Non pris en charge
3.2 pour gérer la cible logicielle Microsoft iSCSI 3.3
Les sous-réseaux redondants sont créés de manière
incorrecte dans un réseau IPv6 iSCSI
Cet article fournit une solution à un problème dans lequel les sous-réseaux redondants sont créés de manière
incorrecte dans un réseau IPv6 iSCSI.
Symptômes
Vous concevez un réseau IPv6 iSCSI qui contient des serveurs et des périphériques de stockage. Dans ce réseau,
certains serveurs utilisent des adresses de liaison locale.
Dans ce cas, vous rencontrez un problème dans lequel plusieurs passerelles tentent de créer des sous-réseaux
de stockage distincts pour isoler le trafic. Toutefois, les sous-réseaux sont redondants.
Pour contourner ce problème, configurez l’initiateur et la cible sur différents sous-réseaux.
Références
ISCSI Boot Firmware Table (iBFT) as Defined in ACPI 3.0b Specification (download file)
Stockage Vue d’ensemble des protocoles de services
Windows Spécifications et stratégies du programme de compatibilité matérielle pour l’industrie iSCSI et
Microsoft
Adresses IPv6 link-local et site-local
L’initiateur Microsoft iSCSI peut ne pas se connecter
aux cibles favorites après que le nom de l’initiateur a
été modifié dans Windows
Cet article fournit une solution à un problème dans lequel l’initiateur Microsoft iSCSI ne parvient pas à se
connecter aux cibles favorites après que le nom de l’initiateur a été modifié.
S’applique à : Windows Server 2012 R2, Windows 7 Service Pack 1
Symptômes
Prenons le cas de figure suivant. Sur un système exécutant Windows, vous vous connectez au stockage basé sur
iSCSI à l’aide de l’initiateur Microsoft iSCSI. Dans les propriétés de l’initiateur iSCSI, vous avez configuré les
entrées cibles favorites afin que l’initiateur iSCSI se connecte automatiquement à certaines cibles iSCSI. La ou les
cibles iSCSI que vous connectez utilisent le contrôle d’accès, et ce contrôle d’accès utilise le nom de l’initiateur
iSCSI (par exemple, iQN) ou l’adresse IP de l’initiateur pour l’authentification.
Si vous modifiez le nom de l’initiateur dans l’onglet Configuration des propriétés de l’initiateur iSCSI, vous
risquez de ne pas pouvoir accéder à certaines cibles iSCSI contrôlées par l’accès lorsque le système est
redémarrage ou lorsque la connectivité à une cible iSCSI est perdue. Par exemple :
Si une cible iSCSI est configurée pour utiliser le nouveau nom d’initiateur pour l’authentification, l’initiateur
iSCSI peut ne pas se connecter à la cible à l’aide des entrées de la cible favorite créées alors que l’initiateur
iSCSI a été configuré pour utiliser l’ancien nom de l’initiateur.
Si une cible iSCSI est configurée pour utiliser l’ancien nom de l’initiateur pour l’authentification, l’initiateur
iSCSI risque de ne pas pouvoir se connecter à la cible à l’aide des entrées de la cible favorite créées après la
changement du nom de l’initiateur. En outre, vous ne pourrez peut-être plus découvrir la cible iSCSI une fois
le nom de l’initiateur modifié.
Si la cible iSCSI est configurée pour utiliser l’adresse IP de l’initiateur iSCSI pour l’authentification, l’initiateur
iSCSI peut se connecter à l’aide des entrées de la cible favorite qui ont été créées avant et après la
changement du nom de l’initiateur. Toutefois, pour des raisons de sécurité, la cible iSCSI peut empêcher les
connexions à partir d’une seule adresse IP à l’aide de plusieurs noms d’initiateur, et par conséquent, certaines
tentatives d’connexion peuvent échouer.
Cause
Lorsqu’une entrée cible favorite est créée, l’initiateur iSCSI définit l’entrée Cible favorite de manière à utiliser le
nom de l’initiateur configuré au moment de la création. Si le nom de l’initiateur est modifié ultérieurement, les
entrées de la cible favorite pré-existantes ne sont pas mises à jour pour refléter le nom de l’initiateur
nouvellement configuré.
Résolution
Lorsque le nom de l’initiateur est modifié dans les propriétés de l’initiateur iSCSI, toutes les entrées cibles
favorites pré-existantes doivent être supprimées et recréés pour s’assurer qu’elles utilisent le nouveau nom de
l’initiateur. Assurez-vous également que le nom de l’initiateur correspond toujours au nom de l’initiateur que la
cible iSCSI utilise pour le contrôle d’accès.
Windows Installation dans un démarrage à partir de
rapports de configuration SAN : le programme
d’installation n’a pas pu créer une partition système
ou localiser une partition système existante
Cet article fournit des solutions de contournement pour un problème dans lequel vous ne pouvez pas installer
Windows dans le numéro d’accès au démarrage à partir de la configuration SAN lorsqu’il existe plusieurs
chemins d’accès physiques au numéro d’accès au démarrage.
Symptômes
Vous installez Windows Server 2008, Windows Server 2008 R2 ou Window Server 2012 dans un démarrage
à partir de la configuration SAN.
Il existe plusieurs chemins d’accès physiques au LUN de démarrage.
Le LUN de démarrage est brut et n’a pas été initialisé par Windows.
Dans ce scénario, lorsque vous sélectionnez le LUN de démarrage dans le « Où voulez-vous installer Windows ?
» étape de l’Assistant Installation, tous les chemins d’accès au LUN sont affichés séparément et un message
s’affiche :
Windows Server 2012 et Windows Server 2008 R2 :
« Le programme d’installation n’a pas pu créer une partition système ou localiser une partition système
existante. Pour plus d’informations, consultez les fichiers journaux du programme d’installation. »
Windows Server 2008 :
« Windows’est pas en mesure de trouver un volume système qui répond aux exigences d’installation. »
Cause
Windows’installation sur un disque RAW avec plusieurs chemins physiques. Si le LUN de démarrage est
présenté sur un chemin physique unique ou si celui-ci a déjà été initialisé avant l’installation de Windows, le
programme d’installation se déroule comme prévu.
Il existe deux méthodes pour contourner ce comportement.
Solution de contournement 1 : présenter le LUN de démarrage sur un

chemin d’accès unique
Configurez un chemin d’accès unique au LUN de démarrage lors de l’installation Windows. Pour plusieurs
configurations de port HBA, un seul port HBA doit être connecté au SAN lors de l Windows’installation.
Solution de contournement 2 : initialiser le LUN de démarrage avant

l’exécution de l’installation
Cette méthode est idéale pour les scénarios où la déconnexion physique des connexions SAN supplémentaires
n’est pas possible ou est difficile.
Dans les configurations de disque à chemins Windows le programme d’installation ne reconnaît pas un disque
comme amorçable tant que le disque n’est pas initialisé et que la signature du disque n’est pas présente. Pour
initialiser le LUN de démarrage et préparer le disque pour le Windows, vous devez créer une nouvelle partition,
puis supprimer la partition nouvellement créée. La création d’une partition initialise le disque, écrit la signature
du disque et crée une partition. La suppression de la partition supprime la partition nouvellement créée, mais
laisse le disque initialisé avec la signature du disque. Il est important de supprimer la partition pour que
Windows le programme d’installation puisse créer la partition Réservée au système et le volume du système
d’exploitation. Sinon, Windows le programme d’installation ne crée pas la partition Réservée au système.
Les étapes détaillées de la solution de contournement 2 sont les suivantes :
1. Dans la boîte de dialogue Installer Windows du programme d’installation Windows, sous Où voulez-vous
installer Windows ? , sélectionnez Disque 0, puis cliquez sur le lien Options de lecteur (avancé).
2. Sélectionnez Nouveau pour créer une partition.
3. Cliquez sur Appliquer pour accepter la taille de partition par défaut.
4. Cliquez sur OK dans la boîte de dialogue qui explique que des partitions supplémentaires peuvent être
créées automatiquement par Windows.
5. À présent, sélectionnez Supprimer pour supprimer la partition nouvellement créée tout en laissant le
disque dans son état initialisé.
6. Cliquez sur OK dans la boîte de dialogue d’avertissement pour reconnaître que toutes les données sur le
disque seront perdues.
7. Redémarrez le système et exécutez Windows le programme d’installation normalement. Windows Le
programme d’installation reconnaît le disque et le programme d’installation continue.
L’activation de MPIO avec des Stockage SAS réduit
les performances
Cet article fournit de l’aide pour résoudre un problème dans lequel les performances d’écriture séquentielle des
disques diminuent d’environ 50 % après l’utilisation de la fonctionnalité MPIO (Multipath I/O) sur un système à
l’aide de disques SAS (Serial Attached Stockage).
Symptômes
Sur une Windows Server 2012, après l’activation de la fonctionnalité MPIO sur un système utilisant des disques
SAS, les performances d’écriture séquentielles des disques utilisés avec MPIO diminuent d’environ 50 % avec la
stratégie d’équilibrage de charge round robin.
Cause
Ce problème peut se produire lorsque les disques sont configurés comme suit :
La fonctionnalité MPIO est activée pour fournir un accès via les deux ports SAS.
Le microprogramme de disque ne fournit pas de performances optimales lorsque les deux ports SAS sont en
cours d’utilisation.
NOTE
This issue may occur when using espaces de stockage in conjunction with SAS disks and MPIO.
Résolution
Pour résoudre ce problème, obtenez le microprogramme mis à jour auprès de votre fournisseur de disques.
Vous pouvez contourner ce problème en essayant une autre stratégie d’équilibrage de charge à l’aide des
options appropriées mentionnées ci-dessous :
Contourner l’utilisation de espaces de stockage ou lorsque les stratégies de base de données n’ont pas été
définies manuellement par disque
Utilisez la cmdlet Set-MSDSMGlobalDefaultLoadBalancePolicy du module MPIO dans Windows PowerShell pour
spécifier une stratégie de base de données différente à appliquer à tous les disques du pool.
Contourner lorsque vous n’utilisez pas espaces de stockage ou lorsque des stratégies de base de données
ont été définies manuellement par disque
1. Ouvrez Gestion des disques. Pour ouvrir Gestion des disques, sur Windows bureau, cliquez sur Démarrer ;
dans le champ Démarrer la recherche, tapez diskmgmt.msc ; puis, dans la liste Programmes, cliquez sur
diskmgmt.
2. Cliquez avec le bouton droit sur le disque multipathe pour lequel vous souhaitez modifier le paramètre de
stratégie, puis cliquez sur Propriétés.
3. Cliquez sur l’onglet MPIO.
4. Dans la liste finale Sélectionner la stratégie MPIO, sélectionnez une autre stratégie, telle que Les blocs
minimum.
5. Cliquez sur OK.
6. Répétez les étapes ci-dessus pour tous les autres disques multipaths présentant des performances lentes.
Pour obtenir une liste complète des cmdlets contenues dans le module iSCSI pour Windows PowerShell,
reportez-vous aux documents suivants :
iSCSI
Classes WMI de l’initiateur iSCSI
Option MPIO non disponible dans Gestion des
disques dans Windows Server 2019
Cet article décrit une modification de Windows Server 2019, dans laquelle l’option MPIO n’est plus disponible
dans Gestion des disques.
Symptôme
Après avoir installé la fonctionnalité d’E/S multipathe (MPIO) sur un serveur exécutant Windows Server 2019
build 17763, vous remarquerez que l’option MPIO n’est pas disponible sous Gestion des disques Microsoft >
Stockage Space Device, comme c’était le cas dans les versions antérieures de Windows.
Pour contourner ce problème, utilisez une cmdlet PowerShell pour configurer MPIO. Par exemple :
Exécutez Get-MSDSMGlobalDefaultLoadBalancePolicy dans PowerShell pour récupérer la stratégie MPIO.
Exécutez Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR pour configurer la stratégie MPIO en tant
que tour robin.
Référence
Pour plus d’informations, voir MPIO.
Message d’erreur « Vous n’avez pas d’autorisation »
lorsque vous essayez de monter une image ISO
Cet article permet de corriger l’erreur « Vous n’avez pas d’autorisation » lorsque vous essayez de monter une
image ISO.
Symptômes
Lorsque vous essayez de monter une image ISO dans Windows Server 2012 R2, Windows Server 2012,
Windows 8.1 ou Windows 8, vous recevez le message d’erreur suivant :
Impossible de monter le fichier

Vous n’êtes pas autorisé à monter le fichier.
La fenêtre de message est affichée dans la capture d’écran suivante.
Ce problème se produit lorsque vous effectuez l’une des opérations suivantes :

Vous double-cliquez sur un fichier .iso ou utilisez les outils d’image de disque pour monter une image ISO à
partir d’une source locale ou réseau.
Vous essayez de monter une image ISO par le biais du menu raccourci dans Windows Explorer.
NOTE
Bien que vous receviez le message d’erreur, l’image ISO est montée correctement dans la plupart des cas.
Autres symptômes signalés

Lorsque vous cliquez sur un fichier .iso dans Windows Explorer pour essayer de monter l’image ISO,
l’opération échoue et vous recevez le message d’erreur suivant :
Désolé, il y a eu un problème de montage du fichier
Vous recevez le message d’Windows PowerShell suivant :
Error:17098 - Le magasin de composants a été endommagé
Lorsque vous exécutez la commande dans PowerShell, l’opération échoue et mountdiskimage

-imagepath c:\images\windows8.1_enterprise.iso vous recevez le message d’erreur suivant :
mount-diskimage : « La version ne prend pas en charge cette version du format de fichier ».
Hresult 0xc03a0005
Cause
Ce problème peut se produire pour une ou plusieurs des raisons suivantes :
Un lecteur multimédia USB est attaché à l’ordinateur.
Le média amovible est monté sur l’ordinateur.
Le fichier .iso que vous essayez de monter est un fichier peu dispersé.
Pour déterminer si un fichier est un fichier peu dispersé, utilisez l’une des méthodes suivantes.
Méthode 1 : vérifier les propriétés du fichier
1. Dans le C:\images dossier, cliquez avec le bouton droit sur le Windows8.1_Enterprise.iso.
3. Cliquez sur Détails .
4. Vérifiez la ligne Attributs de la lettre « P » pour indiquer un fichier peu clairsemé.
Méthode 2 : utiliser PowerShell
1. Exécutez la commande Windows PowerShell suivante :
(get-item c:\test\mydisk.iso).attributes
2. Recherchez le mot « SparseFile » dans la sortie de commande pour indiquer un fichier peu dispersé.
Résolution
Résolution 1
Copiez le fichier ISO dans un nouveau fichier en l’enregistrer dans un autre dossier ou en lui donnant un autre
nom.
Ce processus doit supprimer l’attribut peu resserre et permettre le montage du fichier.
Résolution 2
Si vous avez un lecteur multimédia flash ou un média amovible, essayez d’éjecter le média amovible. Ensuite,
réaffectez les lettres de lecteur de telle sorte que vous laissez une lettre de lecteur inférieure disponible pour
monter l’image ISO. Le fichier peut ne pas se comporter correctement s’il possède un lecteur affecté qui suit
d’autres lecteurs.
Par exemple, prenons la disposition suivante.
L EC T EUR A F F EC TAT IO N
C Disque dur
D DVD
E Périphérique USB
F ISO (attribué automatiquement)

Dans cette disposition, l’image ISO est automatiquement affectée au lecteur F lors de son montage. Elle
provoque l’erreur mentionnée dans la section « Symptômes ». Toutefois, le lecteur continue de fonctionner.
Après avoir éjecté le lecteur ISO F, réaffectez le lecteur USB au lecteur F. Maintenant, lorsque vous montez
l’image ISO, elle est automatiquement attribuée au lecteur E sans générer d’erreurs. La nouvelle disposition se
fera comme suit.
L EC T EUR A F F EC TAT IO N
C Disque dur
D DVD
E ISO (attribué automatiquement)
F Périphérique USB
Un volume peut s’afficher comme brut dans la
gestion des disques après l’extension de la partition,
mais chkdsk affiche le système de fichiers en tant
que NTFS
Cet article fournit des solutions à un problème dans lequel un volume s’affiche comme brut dans la gestion des
disques, mais chkdsk affiche le système de fichiers en tant que NTFS après l’extension de la partition.
Symptômes
Lorsque vous étendez un volume à l’aide de FSExtend, le volume peut s’afficher comme brut dans la gestion des
disques. Toutefois, lorsque vous exécutez chkdsk, le système de fichiers s’affiche en tant que NTFS.
En outre, vous voyez le message d’erreur suivant dans le journal système :

Source : Ntfs
Niveau : Error
Description :
La structure du système de fichiers sur le disque est endommagée et inutilisable. Exécutez l’utilitaire chkdsk
sur le volume <driveletter> :
Cause
Le problème se produit pour l’une des raisons suivantes :
La structure du système de fichiers sur le disque est endommagée.
L’espace disque n’est pas suffisant pour l’extension du système de fichiers.
Résolution
Méthode 1
S’il y a trop peu d’espace disque pour monter le volume, réduire le journal des transactions NTFS à 4 Mo.
Ensuite, le disque aura suffisamment d’espace pour monter le volume. Pour cela, procédez comme suit.
1. Pour réduire le journal des transactions NTFS à 4 Mo, exécutez la commande suivante :
chkdsk d: /l:4096 /f
2. Déterminez si vous pouvez accéder au disque. Si vous pouvez accéder au disque, vous devez libérer de
l’espace libre, puis renvoyer le journal des transactions NTFS à la valeur par défaut d’environ 65 Mo. Pour
ce faire, exécutez la commande suivante :
chkdsk d: /l: 65536 /f
Méthode 2
Exécutez la commande suivante sur le disque pour corriger les erreurs sur le disque :
chkdsk /f <drive>
Une fois chkdsk terminé, redémarrez le serveur. Ensuite, exécutez FSExtend sur le lecteur pour étendre le
système de fichiers. Pour ce faire, exécutez la commande suivante :
FSExtend <drive>
Cela doit étendre le système de fichiers sur le lecteur et le disque doit être accessible.
Meilleures pratiques pour l’utilisation de disques
dynamiques Windows ordinateurs basés sur Server
2003
Cet article décrit les meilleures pratiques pour l’utilisation de disques dynamiques sur Windows ordinateurs
basés sur Server 2003.
Résumé
Si vous utilisez des disques dynamiques, vous pouvez créer des volumes à tolérance de panne (volumes en
miroir et ensembles RAID-5) et de grands volumes à disques multiples (ou numéro d’unité logique [LUN]) à
l’aide de volumes à bandes et s’étendent. Ces fonctionnalités sont disponibles uniquement sur les disques
dynamiques. Les disques dynamiques sont plus robustes et à tolérance de panne dans la façon dont ils stockent
et répliquent les informations de configuration des disques et des volumes. Les disques dynamiques sont
principalement conçus pour être toujours en ligne. Pour cette raison, ils ne sont pas disponibles sur les supports
amovibles. Suivez les recommandations de cet article pour conserver vos données en ligne et accessibles.
Après avoir créé une partition sur Windows Server 2003, la partition doit être mise en forme et affectée d’une
lettre de lecteur pour que les données y soient stockées. Windows Server 2003 prend en charge deux types
différents de disques pour les partitions, les disques de base et les disques dynamiques. Sur les disques de base,
les partitions sont appelées volumes de base. Les volumes de base incluent les partitions principales et les
lecteurs logiques. Sur les disques dynamiques, les partitions sont appelées volumes dynamiques. Les volumes
dynamiques incluent les volumes simples, à bandes, en spanned, en miroir et RAID-5.
Les volumes sont une zone de stockage sur un disque dur. Un volume est mis en forme à l’aide d’un système de
fichiers, tel qu’une table d’allocation de fichiers (FAT) ou un système de fichiers NTFS, et une lettre de lecteur lui
est affectée. Vous pouvez afficher le contenu d’un volume en cliquant sur son icône dans Windows Explorer ou
my Computer. Un disque dur unique peut avoir plusieurs volumes, et les volumes peuvent également s’étendre
sur plusieurs disques.
Meilleures pratiques et limitations d’utilisation des disques

dynamiques
Les disques dynamiques offrent des avantages par rapport aux disques de base. Les disques de base utilisent les
tables de partition d’enregistrement de démarrage principal (MBR) de style MS-DOS d’origine pour stocker les
informations de partitionnement de disque principale et logique. Les disques dynamiques utilisent une région
privée du disque pour gérer une base de données Logical Disk Manager (LDM). La base de données LDM
contient les types de volume, les décalages, les appartenances et les lettres de lecteur de chaque volume. La
base de données LDM est également répliquée, de sorte que chaque disque dynamique connaît toutes les autres
configurations de disque dynamique. Cette fonctionnalité rend les disques dynamiques plus fiables et
récupérables que les disques de base.
Avant d’utiliser des disques dynamiques, prenons en compte les meilleures pratiques recommandées suivantes
et les limitations d’utilisation des disques dynamiques.
Disques dynamiques et disques de base

Avant de convertir des disques de base en disques dynamiques, déterminez si vous avez besoin des
fonctionnalités fournies par les disques dynamiques. Si vous n’avez pas besoin de volumes s’étendent, de
volumes à bandes, de volumes en miroir ou de jeux RAID-5, il peut être préférable d’utiliser des disques de base.
NOTE
Si vous souhaitez augmenter la taille d’un LUN de disque RAID-5 matériel, mais que vous n’avez pas besoin d’étendre le
volume du système de fichiers NTFS sur différents disques physiques (ou LUN), continuez à utiliser des disques de base.
Vous pouvez utiliser l’utilitaire DiskPart.exe pour étendre le volume NTFS après avoir ajouté une nouvelle capacité de
stockage au volume RAID. DiskPart.exe est un interpréteur de commandes en mode texte que vous pouvez utiliser pour
gérer des objets (disques, partitions ou volumes) à l’aide de scripts ou d’une entrée directe à partir d’une invite de
commandes. Pour plus d’informations, voir Étendre un volume de données dans Windows
Stockage périphériques
Si vous décidez d’utiliser des disques dynamiques et que vous avez à la fois un stockage connecté localement
(stockage basé sur l’IDE ou stockage basé sur l’interface système de petite taille [SCSI] et un stockage situé sur
un réseau san de stockage, prenons en compte les recommandations suivantes, en fonction de votre situation :
Utilisez des disques dynamiques uniquement sur les lecteurs de stockage SAN et conservez le stockage
connecté localement en tant que disques de base.
ou
Utilisez des disques de base sur les lecteurs de stockage SAN et configurez le stockage connecté localement
en tant que disques dynamiques. Ces recommandations sont basées sur la façon dont le LDM suit les disques
dynamiques et synchronise les bases de données. En suivant ces recommandations, si vous faites l’expérience
d’une panne non planifiée et que vous perdez l’accès au stockage SAN qui stocke les disques dynamiques,
tous les disques dynamiques sont déconnectés de l’ordinateur Windows Server 2003 en même temps. Étant
donné qu’aucun disque dynamique n’est attaché localement, il n’existe aucun problème de synchronisation
de base de données LDM à prendre en compte lorsque les disques SAN sont finalement de nouveau en ligne.
Si vous n’avez qu’un seul disque dynamique sur le stockage connecté localement, vous risquez de ne pas être
en même temps que les bases de données LDM, et vous risquez d’avoir des difficultés à remettre en ligne un
ou plusieurs disques dynamiques connectés au SAN.
Si votre environnement nécessite que vous utilisiez des disques dynamiques dans une configuration mixte qui
utilise à la fois un stockage connecté localement et un stockage SAN, il est bon de protéger tous les fibre hubs,
routeurs, commutateurs, cabinets SAN et le serveur contre les pannes d’alimentation à l’aide d’une alimentation
sans rupture (UPS) sur tous les périphériques de connexion.
NOTE
Dans une configuration de disque dynamique mixte, si vous devez mettre le stockage SAN hors connexion pour
maintenance, Microsoft vous recommande d’arrêter le serveur avant de mettre l’unité de stockage SAN hors
connexion, puis de vous assurer que tous les périphériques SAN sont de nouveau disponibles lorsque vous remettrez
le serveur en ligne.
Windows ne prend pas en charge le montage d’un volume de disque sur plusieurs hôtes en même temps. Cette
restriction s’applique aux volumes situés sur un disque BASIC ou un disque dynamique. Une altération du volume peut
se produire si des modifications sont apportées au volume par les deux hôtes. Windows ne prend pas en charge
l’exposition et l’importation simultanées de disques dynamiques sur plusieurs hôtes (nod). Cette pratique peut
également entraîner une perte de données ou une altération de la base de données LDM.
Clusters de serveurs
Les disques dynamiques ne sont pas pris en charge pour une utilisation avec Windows clustering. Cette
restriction ne vous empêche pas d’étendre un volume NTFS contenu sur un disque partagé de cluster (disque
partagé entre les ordinateurs du cluster) qui est de base.
Vous pouvez utiliser un logiciel tiers tel que Veritas Volume Manager pour ajouter les fonctionnalités de disque
dynamique à une infrastructure de cluster Microsoft.
NOTE
Par défaut, Windows 2000 Server et Windows Server 2003 ne sont pas en charge les disques dynamiques dans un
environnement Microsoft Cluster Server (MSCS). Vous pouvez utiliser veritas Volume Manager pour Windows pour
ajouter les fonctionnalités de disque dynamique à un cluster de serveurs Microsoft. Pour obtenir un support technique
concernant les problèmes de cluster après avoir installé le Gestionnaire de volume Veritas, contactez Veritas.
Déplacement de disques dynamiques

Si vous déplacez des disques dynamiques d’un système à l’autre, il se peut que vous ne soyez pas en mesure de
déplacer les disques dynamiques vers l’hôte d’origine. Si vous devez déplacer les disques dynamiques, déplacez
tous les disques dynamiques d’un ordinateur en même temps et assurez-vous qu’ils sont tous en ligne et en
cours d’exécution sur l’ordinateur de destination avant d’essayer de les importer vers le nouvel hôte. Vous devez
le faire car le nom du groupe de disques et l’ID du groupe de disques principal du système hôte (si un disque
dynamique est présent) sont toujours conservés. La différence est qu’il existe au moins un disque dynamique
sur l’ordinateur de destination. Un scénario de problème se produit lorsqu’il n’y a pas de disques dynamiques
sur l’ordinateur de destination (de sorte que l’ordinateur se retrouve avec le même nom de groupe de disques
que l’ordinateur source lorsque les disques y sont déplacés), puis que vous souhaitez déplacer les disques vers
l’ordinateur source. Vous pouvez être à l’origine d’un problème si les disques étrangers réimportés ont le même
nom de groupe de disques que l’ordinateur local.
Signatures de disque
Lorsque vous démarrez le logiciel en snap-in Gestion des disques, tous les disques du système sont indiqués
pour voir si des disques ont changé ou si de nouveaux disques ont été ajoutés au système. Si la gestion des
disques trouve des disques inconnus, qui ne sont pas initialisés ou qui n’ont pas de signature de disque dans le
MBR, la gestion des disques démarre un Assistant. L’Assistant vous invite à sélectionner les disques sur qui vous
souhaitez écrire des signatures de disque. Par défaut, aucun disque n’est sélectionné. Cochez les cases en regard
des numéros de disque pour sélectionner les disques à éumer. Vous êtes ensuite invité à sélectionner les disques
que vous souhaitez mettre à niveau vers les disques dynamiques. Tous les disques que vous mettre à niveau ont
une signature de disque ajoutée et sont mis à niveau vers des disques dynamiques.
Lorsque vous démarrez la gestion des disques, si la valeur MBR d’un disque dynamique est zéro, l’Assistant
démarre.
NOTE
Le MBR d’un disque peut être lu comme zéro en cas de défaillance matérielle.
L’Assistant vous invite à convertir le disque en disque dynamique. Si vous autorisez la reconvertir en disque
dynamique, la base de données LDM d’origine est écrasée par la base de données LDM nouvellement initialisée.
Gestion des disques indique que le disque est sain, mais affiche uniquement l’espace libre non alloué. Si vous
avez un autre disque dynamique sain dans le système au moment de la conversion, sa base de données LDM est
répliquée sur le disque dynamique nouvellement converti et un disque « manquant » qui représente le disque
dynamique d’origine est également affiché dans Gestion des disques.
Disques dynamiques manquants

Si gestion des disques indique un disque dynamique manquant, ce qui signifie qu’un disque dynamique qui
était attaché au système ne peut pas être localisé. Étant donné que chaque disque dynamique du système
connaît tous les autres disques dynamiques, ce disque « manquant » est affiché dans Gestion des disques. Ne
supprimez pas les volumes du disque manquant ou sélectionnez l’option Supprimer le disque dans Gestion des
disques, sauf si vous avez intentionnellement supprimé le disque physique du système et que vous n’avez pas
l’intention de le rattacher. Il est important, car après avoir supprimé les enregistrements de disque et de volume
de la base de données LDM du disque dynamique restant, il se peut que vous ne soyez pas en mesure
d’importer le disque manquant et de le remettre en ligne sur le même système après l’avoir à nouveau rattacher.
Configuration en mode texte et console de récupération

Ne supprimez jamais ou ne créez jamais de partition sur un disque dynamique pendant l’installation en mode
texte de Windows 2000, Windows XP ou Windows Server 2003 ou lorsque vous démarrez l’ordinateur à l’aide
de la console de récupération. Si vous le faites, une perte de données permanente peut se produire.
Lecteur en miroir
Ne cassez jamais un disque système sain ou démarrez un volume dynamique en miroir et attendez-vous à ce
que le lecteur en miroir remplace le lecteur principal d’origine en cas d’échec. La prochaine lettre de lecteur
disponible est affectée au lecteur en miroir rompu manuellement, qui est mise à jour vers l’enregistrement
permanent dans la base de données LDM. Cela signifie que, quelle que soit la position de ce lecteur dans le
processus de démarrage, elle est affectée à la nouvelle lettre de lecteur (et incorrecte), de sorte que le système
d’exploitation ne peut pas fonctionner correctement.
NOTE
Windows la mise en miroir logicielle est une solution à tolérance de panne qui vous permet de conserver l’accès aux
données en cas de défaillance du disque matériel. La mise en miroir logicielle n’est pas destinée à être utilisée comme
mécanisme de sauvegarde hors connexion.
Mise en miroir matérielle

Si vous utilisez des disques dynamiques avec la mise en miroir matérielle, assurez-vous que les deux parties des
lecteurs en miroir matériel ne sont pas exposées au même système d’exploitation en même temps. Sur les
disques en miroir matériel, les bases de données LDM sont exactement identiques, mais chaque disque
dynamique d’un système contient un DiskID unique dans l’en-tête LDM afin que LDM puisse distinguer un
disque dynamique d’un autre.
Pour exposer les deux parties d’un lecteur en miroir matériel, cassez le miroir matériel à l’aide de l’utilitaire de
configuration RAID OEM, puis configurez les deux disques en tant que lecteurs autonomes accessibles au
Un comportement imprévisible peut se produire si deux disques dynamiques identiques sont exposés au
système d’exploitation en même temps.
Références
Pour plus d’informations, voir Comment utiliser le logiciel en snap-in Gestion des disques pour gérer les disques
de base et dynamiques dans Windows Server 2003
produits.
Impossible d’accéder au dossier ClusterStorage sur
un nœud passif dans un cluster de serveurs
Cet article décrit un problème dans lequel vous ne pouvez pas accéder à un volume CSV à partir d’un nœud
passif (non coordinateur) et recevoir l’ID d’événement 5120 ou 5142.
Symptômes
Sur un cluster de serveurs Windows avec la fonctionnalité volume partagé de cluster (CSV) activée, un
utilisateur peut ne pas être en mesure d’accéder à un volume CSV à partir d’un nœud passif (non coordinateur).
Lorsque vous cliquez sur un volume CSV, l’explorateur peut se bloquer. Un ou tous les événements suivants
peuvent être affichés :
Source : Microsoft-Windows-FailoverCluster
Niveau : Error
Description : le volume partagé de cluster « volume_name » n’est plus disponible sur ce nœud en raison de
« STATUS_BAD_NETWORK_PATH(c00000be) ». Toutes les entrées//s sont temporairement mise en file
d’attente jusqu’à ce qu’un chemin d’accès au volume soit rétabli.
Niveau : Error
« STATUS_CONNECTION_DISCONNECTED(c000020c) ». Toutes les entrées/retours sont temporairement en
file d’attente jusqu’à ce qu’un chemin d’accès au volume soit rétabli.
Niveau : Error
« STATUS_MEDIA_WRITE_PROTECTED(c00000a2) ». Toutes les entrées/retours sont temporairement en file
d’attente jusqu’à ce qu’un chemin d’accès au volume soit rétabli.
ID d’événement généré : 5142

Description : le volume partagé de cluster « volume_name » (' Cluster Disk #') n’est plus accessible à partir
de ce nœud de cluster en raison de l’erreur « ERROR_TIMEOUT(1460) ». Veuillez résoudre les problèmes de
connectivité de ce nœud au périphérique de stockage et à la connectivité réseau.
Cause
Lors de l’accès à un volume CSV à partir d’un nœud passif (non-coordinateur), l’E/S disque vers le nœud
propriétaire (coordinateur) est acheminé via une carte réseau « préférée » et nécessite que SMB soit activé sur
cette carte réseau. Pour que les connexions SMB fonctionnent sur ces cartes réseau, les protocoles suivants
doivent être activés :
Client pour les réseaux Microsoft
Partage de fichiers et d'imprimantes pour les réseaux Microsoft
Résolution
Examinez chaque nœud de cluster et vérifiez que les protocoles suivants sont activés pour les cartes réseau
disponibles pour l’utilisation du cluster :
Client pour les réseaux Microsoft
Partage de fichiers et d'imprimantes pour les réseaux Microsoft
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapezncpa.cpl, puis cliquez sur OK.
2. Cliquez avec le bouton droit sur la connexion locale associée à la carte réseau, puis cliquez sur Propriétés.
3. Vérifiez que les protocoles ci-dessus apparaissent dans cette connexion et qu’ils utilisent la zone
d’éléments suivante. Si l’une d’elles est manquante, suivez les étapes suivantes :
a. Cliquez sur Installer, sur Client, puis sur Ajouter.
b. Sélectionnez le protocole manquant, cliquez sur OK, puis sur Oui .
4. Vérifiez que la case à cocher qui apparaît en regard de Client pour les réseaux Microsoft est cocher.
L’ID d’événement 5120 mentionné ci-dessus est enregistré chaque fois qu’un problème se connecte via le
réseau à l’aide de SMB au nœud propriétaire. Si la connexion est restaurée en quelques minutes, il n’y a peut-
être aucun autre effet que la lenteur des VM en raison d’un manque d’exécution des I/S.
La signification des codes d’événement répertoriés ci-dessus est la suivante :
« STATUS_BAD_NETWORK_PATH(c00000be) » : ce code d’erreur signifie que le chemin d’accès réseau au
partage SMB2 créé par le nœud actuellement répertorié comme propriétaire du CSV ne peut pas se trouver.
« STATUS_CONNECTION_DISCONNECTED(c000020c) » : ce code d’erreur signifie qu’un nœud a perdu l’accès
au partage SMB2 créé par le nœud actuellement répertorié comme propriétaire du CSV.
« STATUS_MEDIA_WRITE_PROTECTED(c00000a2) » : ce code d’erreur signifie qu’il n’est pas possible d’écrire
dans le volume. Cela indique généralement que nous avons perdu la réservation sur le disque et que nous
n’avons plus d’I/S direct avec le disque.
L’ID d’événement 5142 indique que le nœud non propriétaire est déconnecté et que le CSV n’est plus en file
d’interrogation des données d’entreprise. Par conséquent, les VM du nœud consignant les erreurs voient le
stockage comme déconnecté au lieu de ralentir la réponse.
Le réseau préféré est le réseau avec la valeur de mesure réseau de cluster la plus faible. Si le réseau préféré n’est
pas disponible (en raison de problèmes ou de reconfiguration), la tolérance de panne du réseau de cluster
entraîne l’utilisation du réseau avec la mesure la plus faible suivante. Si ce réseau n’est pas configuré pour
autoriser la connexion SMB, l’erreur ci-dessus est rencontrée.
La recommandation est pour tout réseau que le cluster peut utiliser (tout réseau non désactivé pour l’utilisation
du cluster) doit être configuré comme indiqué ci-dessus pour autoriser l’utilisation de CSV.
Articles de référence :
Hyper-V : utilisation de la migration en direct avec des volumes partagés de cluster dans Windows Server 2008
R2
Prise en charge des volumes partagés de cluster pour Hyper-V
Vous ne pouvez pas sélectionner ou mettre en
forme une partition de disque dur lorsque vous
essayez d’installer Windows
Cet article fournit des solutions à un problème dans lequel vous ne parviennent pas à sélectionner ou mettre en
forme une partition de disque dur lorsque vous essayez d’installer Windows.
NOTE
La prise en charge Windows Vista sans Service Packs installé a pris fin le 13 avril 2010. Pour continuer à recevoir des mises
à jour de sécurité Windows, assurez-vous que vous exécutez Windows Vista avec Service Pack 2 (SP2). Pour plus
d’informations, voir La prise en charge se termine pour certaines versions de Windows.
IMPORTANT
Les disques dynamiques sont uniquement pris en charge pour :
Windows Vista Professionnel
Windows Vista Entreprise
Windows Vista Ultimate.
Windows 7 Entreprise
Windows 7 Édition Intégrale
Windows Server 2008 R2 Datacenter
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Standard
Windows Web Server 2008 R2
Ils ne sont pas pris en charge pour Windows Vista Home Basic, Windows Vista Home Premium, Windows 7 Édition
Familiale Basique, Windows 7 Édition Starter et Windows 7 Édition Familiale Premium.
Il existe une exception. Lorsque vous faites passer votre ordinateur de Windows XP Media Center Edition à Windows Vista
Home Premium, certains disques dynamiques sont gérés et pris en charge.
Symptômes
Lorsque vous essayez d’installer Windows Vista, Windows 7 ou Windows Server 2008 R2, vous pouvez être face
à un ou plusieurs des symptômes suivants :
Le disque dur sur lequel vous souhaitez installer Windows Vista, Windows 7 ou Windows Server 2008 R2
n’est pas répertorié.
Vous ne pouvez pas sélectionner une partition de disque dur sur laquelle installer Windows Vista,
Windows 7 ou Windows Server 2008 R2.
Vous ne pouvez pas formater une ou plusieurs partitions de disque dur.
Vous ne pouvez pas définir la taille correcte pour une partition de disque dur.
Vous recevez le message d’erreur suivant :
Windows’est pas en mesure de trouver un volume système qui répond à ses critères d’installation
Cause
Ce problème peut se produire pour l’une des raisons suivantes :
Windows est incompatible avec un contrôleur de stockage de masse ou un pilote de stockage de masse.
Un contrôleur de stockage de masse ou un pilote de stockage de masse est obsolète.
Le disque dur sur lequel vous souhaitez installer Windows Vista, Windows 7 ou Windows Server 2008 R2 est
un disque dynamique.
Un câble de données de l’ordinateur est souple ou un autre problème matériel s’est produit.
Le disque dur ou le Windows système de fichiers est endommagé.
Vous avez essayé de sélectionner une partition FAT32 ou un autre type de partition incompatible avec
Windows Vista, Windows 7 ou Windows Server 2008 R2.
Pour résoudre ce problème, utilisez une ou plusieurs des méthodes suivantes.
Résolution 1 : vérifiez que la partition est compatible avec les

Windows
Vous ne pouvez pas installer Windows sur une partition FAT32. En outre, vous devez configurer correctement les
disques dynamiques pour les utiliser avec Windows. Pour vérifier que la partition est compatible avec Windows
Vista, Windows 7 ou Windows Server 2008 R2, suivez les étapes suivantes :
1. Pour un disque dynamique avec un volume simple, utilisez l’utilitaire Diskpart.exe pour configurer le
disque en tant que disque actif. Pour plus d’informations sur l’utilisation de l’utilitaire Diskpart.exe, voir
DiskPart Command-Line Options.
2. Pour une partition FAT32, reformatez la partition ou convertissez la partition en partition de système de
fichiers NTFS à l’aide de Convert.exe commande.
NOTE
Lorsque vous formatez une partition, toutes les données sont supprimées de la partition. Ces données incluent
tous les fichiers de la partition.
Résolution 2 : Mettre à jour les pilotes pour le contrôleur de disque

dur
Si vous souhaitez installer Windows Vista Windows 7 ou Windows Server 2008 R2 en tant que mise à niveau,
mettez à jour les pilotes du contrôleur de disque dur vers les pilotes les plus récents.
NOTE
Windows Le programme d’installation fournit une fonctionnalité pour migrer les pilotes actuels vers le nouveau système
d’exploitation. Par conséquent, Windows le programme d’installation peut utiliser les pilotes actuellement installés sur
l’ordinateur. Si les pilotes les plus récents ne sont pas installés sur l’ordinateur, le programme d’installation peut utiliser les
pilotes obsolètes. Dans ce cas, vous pouvez être en situation de problèmes de compatibilité.
Résolution 3 : fournir des pilotes corrects pour le contrôleur de disque
dur
Si vous essayez d’effectuer une nouvelle installation de Windows, vous devez fournir les pilotes corrects pour le
contrôleur de disque dur. Lorsque vous êtes invité à sélectionner le disque sur lequel installer Windows, vous
devez également cliquer pour sélectionner l’option Charger le pilote. Windows Le programme d’installation
vous guide tout au long du processus.
Résolution 4 : examiner le fichier Setupact.log pour vérifier que la

partition est active
Si vous recevez le message d’erreur suivant, vérifiez que la partition est active en examinant le fichier
Setupact.log :
Windows’est pas en mesure de trouver un volume système qui répond à ses critères d’installation
NOTE
Si vous installez Windows Vista, Windows 7 ou Windows Server 2008 R2 en tant que mise à niveau, le fichier
Setupact.log se trouve dans le dossier Drive : $ WINDOWS.~BT\Sources\Panther. Le lecteur représente le lecteur qui
contient l’installation Windows existante.
Si vous effectuez une nouvelle installation de Windows Vista, Windows 7 ou Windows Server 2008 R2, le fichier
Setupact.log se trouve dans le dossier Drive : $ WINDOWS\Sources\Panther. Le lecteur représente le lecteur DE DVD
qui contient les Windows d’installation.
Pour vérifier que la partition est active, suivez les étapes suivantes :
1. Insérez le DVD dans le lecteur de DVD.
2. Sur l’écran de sélection du disque, appuyez sur Shift+F10. Une fenêtre d’invite de commandes
(CMD) s’ouvre.
3. Modifiez le répertoire pour localiser le fichier Setupact.log, puis ouvrez le fichier Setupact.log.
4. Recherchez la section DumpDiskInformation. Cette section contient des informations sur le mappage
de partition.
5. Dans la section DumpDiskInformation, recherchez l’entrée de journal qui ressemble à ce qui suit.
Partition disque [0] [1] est une partition active
6. Si cette entrée de journal apparaît après une entrée semblable à celle-ci, il se peut que le disque dur ne
soit pas configuré pour utiliser un système d’exploitation Windows base de données.
Inconnu
Dans ce cas, utilisez l’utilitaire Diskpart.exe pour configurer une partition différente en tant qu’active.
NOTE
Cette étape empêche le démarrage d’un système d’exploitation tiers.
7. Fermez la fenêtre Invite de commandes.

Résolution 5 : recherchez les mises à jour du microprogramme et les
mises à jour du BIOS système
Pour les mises à jour du microprogramme et pour les mises à jour du BIOS système, contactez le fabricant du
matériel de l’ordinateur.
Résolution 6 : vérifier que le BIOS système détecte correctement le

disque dur
Pour plus d’informations sur la façon de vérifier que le BIOS système détecte correctement le disque dur,
contactez le fabricant du matériel informatique.
Résolution 7 : utiliser Chkdsk.exe pour vérifier les problèmes

Exécutez lChkdsk.exe pour vérifier la recherche de problèmes de disque. Remplacez le disque dur s’il est
endommagé.
Résolution 8 : utilisez Diskpart.exe pour nettoyer le disque et

réexécuter Windows’installation
Si vous avez essayé toutes les méthodes répertoriées dans cette section et que le problème persiste, utilisez
l’utilitaire Diskpart.exe pour nettoyer le disque, puis exécutez à nouveau Windows Le programme d’installation.
NOTE
Utilisez cette méthode uniquement si vous souhaitez effectuer une nouvelle installation de Windows. Lorsque vous
nettoyez le disque dur, il est formaté. Toutes les partitions et toutes les données sur le disque dur sont définitivement
supprimées. Nous vous recommandons vivement de les archiver sur le disque dur avant de nettoyer le disque.
Pour utiliser l’utilitaire Diskpart.exe pour nettoyer le disque dur, suivez les étapes suivantes :
1. Insérez le DVD dans le lecteur de DVD.
2. Sur l’écran de sélection du disque, appuyez sur Shift+F10. Une fenêtre d’invite de commandes s’ouvre.
3. Tapez diskpart, puis appuyez sur Entrée pour ouvrir l’outil diskpart.
4. list disk Tapez, puis appuyez sur Entrée. La liste des disques durs disponibles s’affiche.
5. sel disk number Tapez, puis appuyez sur Entrée. est le numéro du disque dur que vous souhaitez nettoyer. Le
disque dur est maintenant sélectionné.
6. det disk Tapez, puis appuyez sur Entrée. Une liste de partitions sur le disque dur s’affiche. Utilisez ces
informations pour vérifier que le disque correct est sélectionné.
7. Assurez-vous que le disque ne contient pas les données requises, tapez, puis appuyez sur clean all Entrée
pour nettoyer le disque. Toutes les partitions et toutes les données sur le disque sont définitivement
supprimées.
8. exit Tapez, puis appuyez sur Entrée pour fermer l’outil diskpart.
10. Cliquez sur le bouton Actualiser pour mettre à jour l’écran de sélection de disque. Cette étape
répertorie le disque.
11. Exécutez Windows le programme d’installation pour effectuer une nouvelle installation de Windows.
Vous ne pouvez pas démarrer un ordinateur à partir
d’un disque mémoire USB formaté pour utiliser le
système de fichiers FAT32
Cet article traite d’un échec de démarrage lorsque vous utilisez un disque mémoire USB formaté pour utiliser le
système de fichiers FAT32.
Symptômes
Vous formatez un disque mémoire USB pour utiliser le système de fichiers FAT32. Lorsque vous essayez de
démarrer l’ordinateur à partir de ce disque mémoire USB, le processus de démarrage cesse de répondre et
l’écran est noir.
Cause
Ce problème se produit car le disque mémoire USB est répertorié en tant que média amovible. Par conséquent,
le système d’exploitation Windows ne crée pas d’enregistrement de démarrage maître (MBR) sur le disque
mémoire USB lorsque vous formatez le disque mémoire flash pour utiliser le système de fichiers FAT32. Le
disque mémoire USB est traité comme une disquette super. Le code de démarrage FAT32 ne prend pas en
charge le démarrage d’un ordinateur à partir d’une disquette super sans MBR.
Le BIOS tente de transférer le contrôle du démarrage du disque mémoire USB vers le code de démarrage FAT32.
Toutefois, le code de démarrage FAT32 ne prend pas en charge ce scénario.
Pour contourner ce problème, utilisez l’utilitaire d’invite de commandes pour créer et mettre en forme la
partition de démarrage Diskpart sur le disque mémoire USB.
Pour plus d’informations sur l’utilisation, voir Diskpart DiskPart Command-Line Options.
Comment différencier le MBR du secteur de démarrage

Actuellement, le Windows d’exploitation utilise des signatures au décalage 3 dans le secteur de démarrage pour
déterminer si le secteur est un secteur de démarrage. Ces signatures n’apparaissent pas dans la MBR. Les
signatures sont les suivantes :
FAT16 : MSDOS5.0
FAT32 : MSDOS5.0
NTFS : NTFS
Comment déterminer si le secteur de démarrage est FAT32, FAT16 ou

NTFS
Vérifiez deux chaînes dans le secteur de démarrage pour déterminer si le disque mémoire USB a été formaté à
l’aide de l’un des systèmes de fichiers suivants :
FAT32
FAT16
NTFS
Si les chaînes contiennent FAT32, FAT16 ou NTFS, le secteur de démarrage a été formaté dans ce format de
système de fichiers particulier.
Message d’erreur lorsque vous utilisez la commande
de coupure DiskPart pour rompre un jeu en miroir
Cet article décrit un problème dans lequel une erreur se produit lorsque vous utilisez la commande de coupure
DiskPart pour rompre un jeu en miroir.
Symptômes
Lorsque vous utilisez l’interpréteur de commandes diskPart en mode texte (Diskpart.exe) et que vous
sélectionnez un volume en miroir, puis que vous utilisez la commande de coupure pour décomposer le volume
en miroir en deux volumes, vous pouvez recevoir l’un des messages d’erreur suivants :
Arguments non valides spécifiés pour cette commande.
ou -
Les services de gestion des disques n’ont pas pu terminer l’opération.
Cause
Ce comportement peut se produire si l’un des deux disques contenant les miroirs est manquant et que vous
utilisez une syntaxe incorrecte pour la commande de coupure.
Résolution
Pour résoudre ce problème, utilisez le paramètre de disque pour faire référence au disque manquant et utilisez
le paramètre nokeep.
Sans le paramètre nokeep, la commande break tente de convertir les deux miroirs en volumes simples, en
conservant les données. Si l’un des disques est manquant, cela n’est pas possible. En utilisant le paramètre
nokeep, vous ne conservez qu’une moitié du miroir en tant que volume simple, et l’autre moitié est supprimée
et convertie en espace libre. Aucun des volumes n’est mis au point.
Par exemple, sélectionnez le volume en miroir, émettre la commande « volume de détails », puis rompre le
miroir comme suit :
diskpart> List Volume
Volume ### Ltr Label Fs Type Size Status Info

---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 D data_vol NTFS Mirror 737 KB Failed Rd
Volume 1 C system NTFS Simple 3000 MB Boot
diskpart> select volume 0
Volume 0 is the selected volume.
Diskpart> detail volume
Disk ### Status Size Free Dyn Gpt

---------- ------- ------- --- --- ---
Disk 1 Online 1023 MB 737 KB *
Disk M0 Missing 1022 MB 0 B *
Dans cet exemple, la commande correcte pour rompre le volume en miroir est :
Diskpart> break disk=m0 nokeep
Après l’émission de cette commande, le miroir sur le disque 1 est converti en volume simple et la référence au
miroir manquant est supprimée de la base de données LDM (Logical Disk Management).
Statut
Pour plus d’informations sur l’utilisation de DiskPart pour gérer les disques, cliquez sur le numéro d’article
300415 description de l’utilitaire Command-Line DiskPart
Configurer une alerte d’espace disque faible à l’aide
de la fonctionnalité Journaux et alertes de
performances
Cet article explique comment configurer une alerte d’espace disque faible à l’aide de la fonctionnalité Journaux
et alertes de performances.
Résumé
Cet article détaillé décrit comment créer et configurer une alerte d’espace disque faible à l’aide de la
fonctionnalité Journaux et alertes de performances dans Microsoft Windows Server 2003.
Créer une alerte dans le moniteur système pour suivre l’espace disque disponible
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Performances.
2. Développez les journaux de performances et les aler tes.
3. Cliquez avec le bouton droit sur Alertes, puis cliquez sur Nouvel Paramètres.
4. Dans la zone Nouvelle alerte Paramètres, tapez un nom pour la nouvelle alerte (par exemple, Libérer de
l’espace disque), puis cliquez sur OK.
La boîte de dialogue Aler tName s’affiche, dans laquelle vous configurez les paramètres de l’alerte que
vous avez créée.
5. Cliquez sur l’onglet Général, puis, dans la zone Commentaires, tapez Surveiller l’espace disque libre sur le
lecteur logique.
Configurer l’alerte
1. Cliquez sur Ajouter pour ouvrir la boîte de dialogue Ajouter des compteurs.
2. Cliquez sur Sélectionner des compteurs sur l’ordinateur, puis sélectionnez votre ordinateur dans la
liste.
3. Dans la zone d’objet Performance, cliquez sur LogicalDisk.
4. Cliquez sur Sélectionner des compteurs dans la liste, puis cliquez sur % Espace libre .
5. Cliquez sur Sélectionner des interfaces dans la liste, puis sur le lecteur logique ou le volume que
vous souhaitez surveiller.
6. Cliquez sur Ajouter pour ajouter le compteur, puis cliquez sur Fermer.
7. Dans la zone Aler te lorsque la valeur est zone, cliquez sur Sous, puis tapez la valeur que vous
souhaitez dans la zone Limite. Par exemple, pour déclencher un message d’alerte lorsque l’espace disque
est en dessous de 1 mégaoctet (Mo), tapez 1 000.
8. Acceptez la valeur par défaut de 5 secondes dans l’intervalle exemple de données ou spécifiez la valeur
de votre choix.
9. Cliquez sur Appliquer.
10. Cliquez sur l’onglet Action, puis spécifiez l’action ou les actions que vous souhaitez effectuer lorsqu’une
alerte se produit, comme suit :
Si vous souhaitez que le service Journaux et alertes de performances crée une entrée dans le journal
des applications de l’observateur d’événements lorsqu’une alerte se produit, cochez la case Journal
d’une entrée dans le journal des événements de l’application.
Si vous souhaitez que le service Journaux et alertes de performances déclenche l’envoi d’un message
par le service Messenger, cochez la case Envoyer un message réseau, puis tapez l’adresse IP ou le
nom de l’ordinateur sur lequel l’alerte doit s’afficher.
Pour exécuter un journal des compteurs lorsqu’une alerte se produit, cochez la case Démarrer le
journal des données de performances, puis spécifiez le journal des compteurs à exécuter.
Pour exécuter une commande ou un programme lorsqu’une alerte se produit, cochez la case Exécuter
ce programme, puis tapez le chemin d’accès au fichier et le nom du programme ou de la commande
que vous souhaitez exécuter. Vous pouvez également cliquer sur Parcourir pour localiser le fichier.
Lorsqu’une alerte se produit, le service crée un processus et exécute le fichier de commande spécifié. Le
service copie également tous les arguments de ligne de commande que vous définissez sur la ligne de
commande utilisée pour exécuter le fichier. Cliquez, puis cliquez pour sélectionner les cases à cocher
appropriées afin d’inclure les arguments que vous souhaitez implémenter lors de
Command Line Arguments l’exécution du programme.
11. Cliquez sur Appliquer.

12. Cliquez sur l’onglet Planification, puis spécifiez les paramètres de début et d’arrêt de l’analyse, comme suit
:
a. Sous Démarrer l’analyse, faites l’une des étapes suivantes :
Cliquez manuellement si vous souhaitez démarrer manuellement l’analyse. Après avoir
sélectionné cette option, cliquez avec le bouton droit sur l’alerte dans le volet droit, puis cliquez
sur Démarrer pour démarrer l’analyse.
Cliquez sur À pour démarrer l’analyse à une heure et une date spécifiques, puis spécifiez l’heure
et la date que vous souhaitez.
b. Sous Arrêter l’analyse, faites l’une des étapes suivantes :
Cliquez manuellement si vous souhaitez arrêter manuellement l’analyse. Après avoir cliqué sur
cette option, cliquez avec le bouton droit sur l’alerte dans le volet droit, puis cliquez sur Arrêter
pour arrêter l’analyse.
Cliquez sur Après pour arrêter l’analyse après une durée spécifiée, puis spécifiez l’intervalle de
temps que vous souhaitez.
Cliquez sur À pour arrêter l’analyse à une heure et une date spécifiques, puis spécifiez l’heure et
la date que vous souhaitez.
c. Si vous souhaitez démarrer une nouvelle analyse une fois l’analyse de l’alerte terminée, cliquez sur
Après, puis cochez la case Démarrer une nouvelle analyse.
13. Cliquez sur OK.
Une fois que vous avez terminé les procédures de cet article, la surveillance commence à l’heure prévue et
envoie des messages d’alerte lorsque le seuil est atteint ou dépassé. Toutefois, l’alerte ne redémarre pas
automatiquement à chaque fois après le redémarrage de l’ordinateur. Pour forcer le redémarrage automatique
de l’alerte après le redémarrage de l’ordinateur ou après la connexion et la connexion, suivez les étapes
suivantes :
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Performances.
2. Développez les journaux de performances et les aler tes.
3. Cliquez sur Alertes
4. Dans le volet droit, cliquez avec le bouton droit sur l’alerte que vous avez créée, puis cliquez sur Propriétés.
5. Cliquez sur l’onglet Planification.
6. Sous Arrêter l’analyse, cliquez sur Après (s’il n’est pas déjà sélectionné), puis définissez cette valeur sur un
grand nombre de jours.
La valeur maximale est 100 000. 7. Cliquez pour cocher Démarrer une nouvelle analyse. 8. Cliquez sur OK.
L’alerte s’exécute en continu, même après le redémarrage ou la connexion, puis la connexion à l’ordinateur.
Limitations du défragmenteur de disque dans
Windows
Cet article décrit les limitations du défragmenteur de disque.

Résumé
L’outil Défragmenteur de disque est basé sur la version commerciale complète de Diskeeper par Diskeeper
Corporation. La version incluse dans Windows offre des fonctionnalités limitées pour maintenir les
performances du disque en défragmentant les volumes qui utilisent le fat, fat32 ou le système de fichiers NTFS.
Cette version présente les limitations suivantes :
Il ne peut défragmenter que les volumes locaux.
Il ne peut défragmenter qu’un seul volume à la fois.
Il ne peut pas défragmenter un volume lors de l’analyse d’un autre.
Elle ne peut pas être programmée.
Il ne peut exécuter qu’un seul logiciel en snap-in Microsoft Management Console (MMC) à la fois.
produits.
Suivi des liens distribués sur Windows contrôleurs
de domaine basés sur le système
Cet article explique comment utiliser les services de suivi de liens distribués dans Windows pour suivre la
création et le déplacement de fichiers liés sur des volumes et des serveurs au format NTFS.
Vue d’ensemble du suivi des liens distribués

Vous pouvez utiliser le service serveur de suivi de liens distribués et le service client de suivi de liens distribués
pour suivre les liens vers des fichiers sur des partitions au format NTFS. Le suivi des liens distribués suit les liens
dans les scénarios où le lien est effectué vers un fichier sur un volume NTFS, tels que les raccourcis shell et les
liaisons OLE. Si ce fichier est renommé, déplacé vers un autre volume sur le même ordinateur, déplacé vers un
autre ordinateur ou déplacé dans d’autres scénarios similaires, Windows utilise le suivi des liens distribués pour
rechercher le fichier. Lorsque vous accédez à un lien déplacé, le suivi des liens distribués localise le lien . vous
ignorez que le fichier a été déplacé ou que le suivi des liens distribués est utilisé pour rechercher le fichier
déplacé.
Le suivi des liens distribués se compose d’un service client et d’un service serveur. Le service serveur de suivi
des liens distribués s’exécute exclusivement Windows contrôleurs de domaine basés sur un serveur. Il stocke des
informations dans Active Directory et fournit des services pour aider le service client de suivi des liens
distribués. Le service client de suivi de liens distribués s’exécute sur tous les ordinateurs basés sur Windows
2000 et Microsoft Windows XP, y compris ceux des environnements de groupe de travail ou ceux qui ne sont pas
dans un groupe de travail. Il fournit l’unique interaction avec les serveurs de suivi de liens distribués.
Les clients de suivi de liens distribués fournissent parfois au service serveur de suivi des liens distribués des
informations sur les liens de fichiers, que le service serveur de suivi des liens distribués stocke dans Active
Directory. Les clients de suivi de liens distribués peuvent également interroger le service serveur de suivi des
liens distribués pour obtenir ces informations lorsqu’un raccourci d’shell ou un lien OLE ne peut pas être résolu.
Les clients de suivi de liens distribués invitent le serveur de suivi des liens distribués à mettre à jour les liens
tous les 30 jours. Le service serveur de suivi des liens distribués recherche les objets qui n’ont pas été mis à jour
depuis 90 jours
Lorsqu’un fichier référencé par un lien est déplacé vers un autre volume (sur le même ordinateur ou sur un
autre ordinateur), le client de suivi des liens distribués avertit le serveur de suivi des liens distribués, qui crée un
objet linkTrackOMTEntry dans Active Directory. Un objet linkTrackVolEntry est créé dans Active Directory pour
chaque volume NTFS dans le domaine.
NOTE
Dans Windows Server 2008 et les plus Windows, le service serveur de suivi de liens distribués n’est plus inclus. Vous
pouvez donc supprimer en toute sécurité les objets d’Active Directory.
Suivi des liens distribués et Active Directory

Les objets de suivi des liens distribués sont répliqués entre tous les contrôleurs de domaine dans le domaine qui
héberge le compte d’ordinateur et tous les serveurs de catalogue global dans la forêt. Le service serveur de suivi
des liens distribués crée des objets dans le chemin d’accès au nom principal suivant :
CN=FileLinks,CN=System,DC= conteneur de nom de domaine d’Active Directory
Les objets de suivi des liens distribués existent dans les deux tableaux suivants sous le dossier
CN=FileLinks,CN=System :
CN=ObjectMoveTable,CN=FileLinks,CN=System,DC= domain name :
Cet objet stocke des informations sur les fichiers liés qui ont été déplacés dans le domaine.
CN=VolumeTable,CN=FileLinks,CN=System,DC= domain name :
Cet objet stocke des informations sur chaque volume NTFS dans le domaine.
Les objets de suivi de liens distribués consomment peu d’espace individuellement, mais ils peuvent consommer
de grandes quantités d’espace dans Active Directory lorsqu’ils sont autorisés à s’accumuler au fil du temps.
Si vous désactivez le suivi des liens distribués et supprimez les objets de suivi de liens distribués d’Active
Directory, le comportement suivant peut se produire :
La taille de la base de données Active Directory peut être réduite (ce comportement se produit une fois que
les objets ont été supprimés et la garbage collecté, et après avoir effectué une procédure de défragmentation
hors connexion).
Le trafic de réplication entre les contrôleurs de domaine peut être réduit.
Valeurs par défaut du service serveur de suivi des liens distribués

Windows contrôleurs de domaine basés sur un serveur
Dans Windows 2000, Windows XP et Windows Server 2003, la valeur de début du service client de suivi des
liens distribués est définie sur Automatique. Sur Windows serveurs basés sur 2 000, le service serveur de suivi
des liens distribués démarre manuellement, par défaut. Toutefois, si vous utilisez Dcpromo.exe pour promouvoir
un serveur vers un domaine, le service serveur de suivi des liens distribués est configuré pour démarrer
automatiquement.
Pour Windows serveurs basés sur Server 2003, le service serveur de suivi des liens distribués est désactivé par
défaut. Lorsque vous utilisez Dcpromo.exe pour promouvoir un serveur vers un domaine, le service serveur de
suivi des liens distribués n’est pas configuré pour démarrer automatiquement. Lorsqu’un contrôleur de domaine
Windows 2000 est mis à niveau vers Windows Server 2003, le service serveur de suivi des liens distribués est
également désactivé pendant la mise à niveau. Si vous êtes administrateur et que vous souhaitez utiliser le
service serveur de suivi des liens distribués, vous devez utiliser la stratégie de groupe ou configurer
manuellement le service pour démarrer automatiquement. En outre, le service client de suivi de liens distribués
sur les ordinateurs exécutant Windows Server 2003 ou Windows XP SP1 n’essaie pas d’utiliser le service
serveur de suivi de liens distribués par défaut. Si vous souhaitez configurer ces ordinateurs pour tirer parti du
service serveur de suivi de liens distribués, activez les clients Autoriser le suivi de liens distribués à utiliser le
paramètre de stratégie des ressources de domaine. Pour ce faire, ouvrez le nœud Configuration
ordinateur/Modèles d’administration/Système dans la stratégie de groupe.
Recommandations de Microsoft pour le suivi des liens Windows

serveurs basés sur 2000
Microsoft recommande d’utiliser les paramètres suivants avec le suivi des liens distribués sur Windows serveurs
basés sur 2000 :
1. Désactiver le service serveur de suivi des liens distribués sur tous les contrôleurs de domaine (il s’agit de
la configuration par défaut sur tous les serveurs Windows Server 2003).
En raison de la surcharge de réplication et de l’espace que les tables FileLinks utilisent dans Active
Directory, Microsoft recommande de désactiver le service serveur de suivi des liens distribués sur les
contrôleurs de domaine Active Directory. Pour arrêter le service, utilisez l’une des méthodes suivantes :
Dans le logiciel en ligne Services (Services.msc ou compmgmt.msc), double-cliquez sur le ser vice
serveur de suivi des liens distribués, puis cliquez sur Désactivé dans la zone De démarrage.
Définissez la valeur de démarrage dans le nœud Configuration ordinateur/Windows
Paramètres/Services système de la stratégie de groupe.
Définissez les paramètres de stratégie sur une unité d’organisation qui héberge tous Windows 2
000 contrôleurs de domaine.
Redémarrez les contrôleurs de domaine une fois que la stratégie a été répliquée afin que la stratégie soit
appliquée. Si vous ne redémarrez pas les contrôleurs de domaine, vous devez arrêter manuellement le
service sur chaque contrôleur de domaine.
2. Supprimer des objets de suivi de liens distribués des contrôleurs de domaine Active Directory.
Consultez la section « Comment supprimer un objet de suivi de liens distribués » de cet article pour plus
d’informations sur la suppression d’objets de suivi de liens distribués. Il est recommandé de supprimer
des objets après avoir désactivé le service serveur de suivi des liens distribués.
NOTE
La taille de l’arborescence des informations d’annuaire (DIT) sur les contrôleurs de domaine n’est pas réduite tant
que les actions suivantes ne sont pas terminées.
a. Les objets sont supprimés du service d’annuaire.
NOTE
Les objets supprimés sont stockés dans le conteneur Objets supprimés jusqu’à l’expiration de la durée de
vie de tombstone. La valeur par défaut d’une durée de vie de tombstone est de 60 jours. La valeur
minimale est de deux jours. Par défaut, la valeur est de 180 jours pour les nouvelles forêts installées avec
Windows Server 2003 Service Pack 1 ou une version ultérieure de Windows Server 2003.
Sauf si vous avez une surveillance forte de la réplication Active Directory, nous vous
recommandons d’utiliser la valeur de 180 jours. Ne réduisez pas cette valeur pour gérer les
problèmes de taille DIT. Si vous avez des problèmes avec la taille de la base de données, contactez
les services de support technique Microsoft.
b. Le garbage collection a été exécuté jusqu’à la fin.
c. Vous utilisez Ntdsutil.exe pour défragmenter le fichier Ntds.dit en mode Dsrepair.
Comment supprimer des objets de suivi de liens distribués

Il n’est pas essentiel de supprimer manuellement les objets de suivi des liens distribués après avoir arrêté le
service serveur de suivi des liens distribués, sauf si vous devez récupérer l’espace disque qui est consommé par
ces objets aussi rapidement que possible. Les clients de suivi de liens distribués invitent le serveur de suivi des
liens distribués à mettre à jour les liens tous les 30 jours. Le service serveur de suivi des liens distribués
recherche les objets qui n’ont pas été mis à jour depuis 90 jours.
Lorsque vous exécutez la Dltpurge.vbs VBScript, tous les objets Active Directory utilisés par le service serveur de
suivi des liens distribués sont supprimés du domaine où le script est exécuté. Vous devez exécuter le script sur
un contrôleur de domaine pour chaque domaine d’une forêt. Pour exécuter Dltpurge.vbs :
1. Obtenez le script Dltpurge.vbs du support technique Microsoft.
2. Arrêtez le service serveur de suivi des liens distribués sur tous les contrôleurs de domaine du domaine
ciblé par Dltpurge.vbs.
3. Utilisez les privilèges d’administrateur pour vous connecter à la console d’un contrôleur de domaine ou
d’un ordinateur membre dans le domaine ciblé par Dltpurge.vbs.
4. Utilisez la syntaxe suivante pour exécuter Dltpurge.vbs à partir d’une ligne de commande :
cscript dltpurge.vbs -s myserver -d dc=mydomain,dc=mycompany,dc=com
Dans cette ligne de commande :

-s est le nom d’hôte DNS du contrôleur de domaine sur lequel vous souhaitez supprimer des objets
de suivi de liens distribués.
-d est le chemin d’accès au nom du domaine sur lequel vous souhaitez supprimer des objets de suivi
de liens distribués.
5. Effectuez une procédure de défragmentation hors connexion du fichier Ntds.dit une fois que les objets
ont été supprimés et la garbage collecté. Pour plus d’informations sur le processus de collecte de la
garbage collection, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de
198793 de la base de données Active Directory
Exemple d’expérience client

Le pire scénario décrit dans cette section illustre certains problèmes à prendre en compte lorsque vous
supprimez un grand nombre d’objets de suivi de liens distribués dans un domaine de production important.
Trey Research, un client fictif de Classement 500 avec plus de 40 000 employés dans le monde entier déploie
une forêt Active Directory unique constituée d’un domaine racine vide avec des domaines enfants qui maient les
principales régions géographiques du monde (Amérique du Nord, Asie, Europe, et ainsi de suite). Le plus grand
domaine de la forêt contient environ 35 000 comptes d’utilisateur et le même nombre de comptes d’ordinateur.
Les fichiers Ntds.dit ont été placés sur des tableaux raid de 18 gigaoctets (Go). Depuis le déploiement initial de
Windows 2000, les fichiers catalogues globaux ont augmenté jusqu’à 17 Go.
Trey Research souhaite déployer Windows Server 2003 dans les 10 prochains jours, mais nécessite au moins 1,5
Go d’espace disque disponible sur la partition de base de données avant de lancer la mise à niveau. Ils ont
besoin de cet espace disque, car Adprep.exe est connu pour ajouter trois à cinq aces hérités en fonction des
correctifs logiciels et service packs qui ont été précédemment installés. Les conditions suivantes contribuent à la
taille importante du catalogue global ou au manque d’espace disque :
Condition 1 : Trey Research était un utilisateur précoce de Windows 2000 et les plus grands lecteurs reçus
de leur fournisseur de matériel préféré étaient de 9 Go ou 18 Go lorsqu’ils étaient configurés dans un
groupe raid. Les lecteurs actuels sont deux fois plus grand que la moitié du coût.
Condition 2 : le nettoyage DNS n’a pas été activé sur les zones DNS intégrées à Active Directory
déléguées à chaque domaine de la forêt.
Condition 3 : les utilisateurs de domaine étaient autorisés à créer des comptes d’ordinateur dans le
domaine. Les administrateurs n’avaient pas de processus périodique permettant d’identifier et de
supprimer des comptes d’ordinateur orphelins.
Condition 4 : au fil du temps, les descripteurs de sécurité ont été définis par les administrateurs, les
Service Packs et les correctifs sur les têtes de contexte d’appellation racine (NC) (cn=schema,
cn=configuration, cn= domain ) et d’autres conteneurs qui hébergent des milliers d’objets dans Active
Directory. En outre, l’audit a été activé sur les mêmes partitions. Lorsque vous définissez des autorisations
et activez l’audit sur des objets dans Active Directory, la taille de la base de données augmente. L’outil qui
prépare Windows 2 000 forêts et domaines pour les contrôleurs de domaine Windows Server 2003
(Adprep) ajoute également des aces hérités ; Par conséquent, Trey Research devait libérer de l’espace sur
le lecteur de disque avant de mettre à niveau le domaine.
Condition 5 : Trey Research n’a pas effectué régulièrement de procédures de défragmentation hors
connexion des fichiers Ntds.dit en mode Dsrepair.
Condition 6 : lorsque le conteneur de noms de domaine CN=FileLinks,CN=System,DC= dans le plus
grand domaine a été examiné, il a révélé plus de 700 000 objets distributed Link Tracking. Le descripteur
de sécurité sur chaque objet Descripteur de liens distribués était d’environ 2 kilo-octets (Ko). Chacune de
ces conditions a été évaluée pour sa contribution au fichier .dit de 17 Go :
Condition 1 : Trey Research a décidé de ne pas déployer de nouveaux lecteurs en raison du coût et du
temps nécessaire. En outre, ils n’ont eu besoin que temporairement de l’espace disque, car ils
s’attendaient à ce que la base de données Active Directory diminue après la mise à niveau vers Windows
Server 2003 et la fin du processus du magasin d’instances unique (SIS) (SIS implémente un stockage plus
efficace des autorisations dans les bases de données Active Directory).
Conditions 2 et 3 : Trey Research a décidé que ces conditions étaient les meilleures pratiques ; Toutefois,
même si Trey Research les implémentait, ils n’atteindreaient pas les résultats nécessaires. Ils ont décidé
d’activer le nettoyage DNS, car il est facilement implémenté.
Condition 4 : Trey Research a réalisé que s’il redéfinissait les descripteurs de sécurité et les listes de
contrôle d’accès système (SACL), il aurait obtenu les résultats qu’il recherchait, mais il a décidé que cette
procédure serait longue à implémenter jusqu’à ce qu’elle puisse tester minutieusement la réduction de la
taille, la surcharge de réplication et, plus important encore, la compatibilité entre les programmes et
l’administration dans le scénario de laboratoire qui reflète l’environnement de production.
Étant donné que Trey Research a déployé Windows 2000 SP2 et quelques correctifs, il s’attendait à ce que
les aces hérités incrémentielles ajoutés par Adprep (aux objets du domaine NC) soient aussi petits que
300 mégaoctets (Mo). Ils peuvent vérifier ce comportement dans un environnement de laboratoire utilisé
pour tester les mises à niveau de la forêt de production.
Condition 5 : Trey Research a réalisé que s’il a effectué une procédure de défragmentation hors
connexion, il se peut qu’il ne récupère pas « espace blanc » dans le fichier Ntds.dit. En fait, les
administrateurs Trey Research ont remarqué une augmentation de la taille de la base de données
immédiatement après avoir effectué la procédure de défragmentation hors connexion. Ce comportement
s’est produit en raison d’une insuffisance dans le moteur Windows base de données 2000 . Ce moteur est
amélioré dans Windows Server 2003.
Condition 6 : Trey Research a accepté que l’action évidente serait d’effectuer une suppression en bloc
simple de tous les objets de suivi des liens distribués du conteneur CN=FileLinks,CN=System,DC= sur un
contrôleur de domaine dans chaque domaine de la forêt. Toutefois, ils se sont rendu compte que s’ils le
faisait, l’espace disque supplémentaire ne serait pas libéré tant que les objets n’ont pas été supprimés et la
garbage collecté, et jusqu’à ce qu’ils terminent une procédure de défragmentation hors connexion sur
chaque contrôleur de domaine dans ce domaine. Bien que la valeur de la durée de vie de tombstone
puisse être définie sur des valeurs aussi faibles que deux jours, plusieurs contrôleurs de domaine dans la
forêt Trey Research étaient hors connexion car ils attendaient des mises à jour matérielles et logicielles. Si
des objets sont annulés avant que la réplication de bout en bout puisse avoir lieu, les objets supprimés
peuvent être réanimés ou des données incohérentes peuvent être signalées entre les serveurs de
catalogue global de la forêt. Pour fournir un secours immédiat, Trey Research a effectué la procédure
suivante :
1. Ils ont supprimé le descripteur de sécurité par défaut pour les objets de classe de schéma de suivi de liens
distribués et l’ont remplacé par un principal de sécurité unique (compte d’utilisateur).
2. Ils ont écrit un programme VBScript qui a supprimé tous les descripteurs de sécurité existants, puis les a
remplacés par un ace explicite pour un principal de sécurité unique.
3. Ils ont supprimé les objets de suivi des liens distribués par incréments de 10 000 unités avec un délai de trois
heures entre chaque suppression d’objet.
4. Ils ont effectué une procédure de défragmentation hors connexion sur chaque contrôleur de domaine dans le
domaine après la suppression de tous les objets de suivi des liens distribués. Lorsque Trey Research a
supprimé le descripteur et effectué la procédure de défragmentation, la base de données a récupéré environ
1,5 Go d’espace disque sur tous les contrôleurs de domaine du domaine. Cette quantité d’espace était
suffisante pour exécuter l’outil Adprep et mettre à niveau tous les contrôleurs de domaine et catalogues
globaux basés sur Windows 2000 vers Windows Server 2003.
Une fois que Trey Research a mis à niveau le système d’exploitation vers Windows Server 2003, plus d’espace
disque a été libéré lorsque la fonctionnalité de magasin d’instances unique dans Windows Server 2003 a réduit
la taille de base de données à environ 8 Go (vous devez effectuer une procédure de défragmentation hors
connexion pour obtenir ces résultats). Plus d’espace a été récupéré après l’expiration de l’intervalle TSL, les
objets de suivi de liens distribués ont été collectés à la garbage et ont effectué une procédure de
défragmentation hors connexion.
Trey Research a promu un nouveau réplica Windows contrôleur de domaine basé sur 2000 dans le domaine et a
placé le compte d’ordinateur dans une unité d’organisation différente de celle qu’il utilise habituellement. En
deux jours, environ 8 000 objets de suivi de liens distribués étaient présents sur le contrôleur de domaine
Windows 2000. Trey Research a arrêté le suivi des liens distribués ou créé une stratégie pour arrêter le service,
puis l’a liée à des unités d’organisation qui hébergent des contrôleurs de domaine basés sur Windows 2000.
Enfin, Trey Research a Dltpurge.vbs pour marquer les autres objets distributed Link Tracking pour la suppression.
Anatomie de la suppression d’objet DLT

Les objets DLT eux-mêmes contiennent peu d’attributs et utilisent peu d’espace dans Active Directory. Lorsqu’un
objet est marqué pour suppression (tombstoned), tous les attributs inutiles sont supprimés, à l’exception de ceux
nécessaires pour suivre l’objet jusqu’à ce qu’il soit purgé d’Active Directory.
Dans le cas des objets de suivi des liens, le marquage de l’objet pour suppression ne revient qu’à deux attributs
supprimés : dscorepropagationdata et objectcategory. La suppression des deux attributs entraîne une économie
initiale de 34 octets. Toutefois, le processus de marquage de l’objet de suivi des liens pour la suppression met
également à jour l’objet en ajoutant un attribut IS_DELETED (4 octets) et en mappant les attributs RDN et «
common name », ce qui fait que chacun de ces attributs augmente d’environ 80 octets. En outre, l’attribut «
replication metadata » augmente également d’environ 50 octets pour refléter les mises à jour effectuées sur cet
objet. Ainsi, en marquant un objet de suivi des liens pour la suppression, l’objet augmente d’environ 200 octets.
Les NTDS. Dit n’affiche pas de réduction de taille tant que les objets supprimés n’ont pas été supprimés, que la
garbage collected et une défragmentation hors connexion n’ont pas été effectuées.
NOTE
Si le service est désactivé comme le recommande cet article, le nettoyage automatique ne se produit pas.
Version texte de la Dltpurge.vbs

Pour utiliser ce script :
1. Copiez tout le texte entre la balise et la balise de cet article, puis collez le texte dans un fichier d’éditeur de
texte <Start Copy Here> <End Copy Here> ASCII (par exemple, un fichier Microsoft Bloc-notes).
2. Enregistrez le fichier sous le nom « Dltpurge.vbs ». 3 Effectuer la procédure décrite dans la procédure de
suppression d’objets de suivi de liens distribués
<Start Copy Here>

'==============================================================================
'==============================================================================
'
' Copyright (C) 2001 by Microsoft Corporation. All rights reserved.
'
' This script deletes all Active Directory objects used by the
' Distributed Link Tracking Server service.
'
' It is assumed that the DLT Server service has been disabled,
' and you wish to recover the DIT space these objects occupy.
'
' Usage: cscript DltPurge.vbs <options>
' Options: -s ServerName
' -d distinguishedname dc=mydomain,dc=mycompany,dc=com
' -b BatchSize BatchDelayMinutes
' -t (optional test mode)
'
' The objects are deleted in batches - BatchSize objects are deleted,
' then there is a BatchDelayMinutes delay before the next batch.
'
'==============================================================================
'==============================================================================
Option Explicit
'
' Globals, also local to main.
'
Dim oProvider
Dim oTarget
Dim sServer
Dim sDomain
Dim bTest
Dim BatchSize
Dim BatchDelayMinutes
'
' Set defaults
'
BatchSize = 1000
BatchDelayMinutes = 15
bTest = False
'==============================================================================
'
' ProcessArgs
'
' Parse the command-line arguments. Results are set in global variables
' (oProvider, oTarget, sServer, sDomain, BatchSize, and BatchDelayMinutes).
'
'==============================================================================
public function ProcessArgs
Dim iCount
Dim oArgs
on error resume next

'
' Get the command-line arguments
'
Set oArgs = WScript.Arguments
if oArgs.Count > 0 then
'
' We have command-line arguments. Loop through them.
'
iCount = 0
ProcessArgs = 0
do while iCount < oArgs.Count
select case oArgs.Item(iCount)
'
' Server name argument
'
case "-s"
if( iCount + 1 >= oArgs.Count ) then

Syntax
ProcessArgs = -1
exit do
end if
sServer = oArgs.Item(iCount+1)
if Len(sServer) > 0 then sServer = sServer & "/"
iCount = iCount + 2
'
' Enable testing option
'
case "-t"
iCount = iCount + 1
bTest = True
'
' Domain name option
'
case "-d"

Syntax
ProcessArgs = -1
Exit Do
end if
sDomain = oArgs.Item(iCount+1)
iCount = iCount + 2
'
' Batching option (batch size, batch delay)
'
case "-b"

Syntax
ProcessArgs = -1
ProcessArgs = -1
exit do
end if
Err.Clear
BatchSize = CInt( oArgs.Item(iCount+1) )

BatchDelayMinutes = CInt( oArgs.Item(iCount+2) )
if( Err.Number <> 0 ) then

wscript.echo "Invalid value for -b argument" & vbCrLf
Syntax
ProcessArgs = -1
exit do
end if
iCount = iCount + 3
'
' Help option
'
case "-?"
Syntax
ProcessArgs = -1
exit do
'
' Invalid argument
'
case else
' Display the syntax and return an error
wscript.echo "Unknown argument: " & oArgs.Item(iCount) & vbCrLf

Syntax
ProcessArgs = -1
Exit Do
end select
loop
else
'
' There were no command-line arguments, display the syntax
' and return an error.
'
Syntax
ProcessArgs = -1
end if
Set oArgs = Nothing
end function ' ProcessArgs
'==============================================================================
'
' Syntax
'
' Show the command-line syntax
'
'==============================================================================
public function Syntax
wscript.echo vbCrLf & _

wscript.echo vbCrLf & _
"Purpose: Delete Active Directory objects from Distributed Link Tracking" & vbCrLf & _
" Server service (Assumes that DLT Server has been disabled" & vbCrLf & _
" on all DCs)" & vbCrLf & _
vbCrLf & _
"Usage: " & wscript.scriptname & " <arguments>" & vbCrLf & _
vbCrLf & _
"Arguments: -s Server" & vbCrLf & _
" -d FullyQualifiedDomain" & vbCrLf & _
" -b BatchSize BatchDelayMinutes (default to 1000 and 15)" & vbCrLf & _
" -t (optional test mode, nothing is deleted)" & vbCrLf & _
vbCrLf & _
"Note: Objects are deleted in batches, with a delay between each" & vbCrLf & _
" batch. The size of the batch defaults to 1000 objects, and" & vbCrLf & _
" the length of the delay defaults to 15 minutes. But these" & vbCrLf & _
" values can be overridden using the -b option." & vbCrLf & _
vbCrLf & _
"Example: " & wscript.scriptname & " -s myserver -d distinguishedname
dc=mydomain,dc=mycompany,dc=com "
end function ' Syntax
'==============================================================================
'
' PurgeContainer
'
' Delete all objects of the specified class in the specified container.
' This subroutine is called once for the volume table and once for
' the object move table.
'
'==============================================================================
sub PurgeContainer(ByRef oParent, ByVal strClass)
dim oChild
dim iBatch
dim iTotal
On Error Resume Next
iTotal = 0
iBatch = 0
' Loop through the children of this container
For Each oChild in oParent
'
' Is this a DLT object?
'
if oChild.Class = strClass Then
'
' Yes, this is a DLT object, it may be deleted
'
iTotal = iTotal + 1
iBatch = iBatch + 1
'
' Delete the object
'
if bTest then
wscript.echo "Object that would be deleted: " & oChild.adspath
else
oParent.Delete oChild.Class, oChild.Name
end if
'
' If this is the end of a batch, delay to let replication
' catch up.
'
if iBatch = BatchSize then
iBatch = 0
wscript.stdout.writeline "" ' ignored by wscript

wscript.echo "Deleted " & BatchSize & " objects"
wscript.echo "Pausing to allow processing (will restart at " & DateAdd("n",
BatchDelayMinutes, Time) & ")"
wscript.sleep BatchDelayMinutes * 60 * 1000

wscript.echo "Continuing ..."
end if
else
' oChild.Class didn't match strClass

wscript.echo "Ignoring unexpected class: " & oChild.Class
end if
oChild = NULL
Next
wscript.echo "Deleted a total of " & iTotal & " objects"
end sub ' PurgeContainer
'==============================================================================
'
' Main
'
'==============================================================================
if (ProcessArgs=-1) then wscript.quit
'
' Explain what's about to happen
'

wscript.echo "This script will purge all objects from the Active Directory" & vbCrLf & _
"used by the Distributed Link Tracking Server service (trksvr)." & vbCrLf & _
"It is assumed that this service has already been disabled on" & vbCrLf & _
"all DCs in the domain."
'
' When running in cscript, pause to give an opportunity to break out
' (These 3 lines are for cscript and ignored by wscript.)
'
wscript.stdout.writeline ""
wscript.stdout.writeline "Press Enter to continue ..."
wscript.stdin.readline
'
' Get an ADSI object
'
Set oProvider = GetObject("LDAP:")
'
' Purge the System/FileLinks/ObjectMoveTable
'

wscript.echo "Purging ObjectMoveTable"
Set oTarget = oProvider.OpenDSObject( "LDAP://" & sServer & "cn=ObjectMoveTable,CN=FileLinks,CN=System," &

sDomain ,_
vbNullString, vbNullString, _
1) ' ADS_SECURE_AUTHENTICATION
call PurgeContainer( oTarget, "linkTrackOMTEntry" )

oTarget = NULL
'
' Purge the System/FileLinks/VolumeTable
'

wscript.echo "Purging VolumeTable"
Set oTarget = oProvider.OpenDSObject("LDAP://" & sServer & "cn=VolumeTable,CN=FileLinks,CN=System," &

sDomain ,_
vbNullString, vbNullString, _
1) ' ADS_SECURE_AUTHENTICATION
call PurgeContainer( oTarget, "linkTrackVolEntry" )
oTarget = NULL
oProvider = NULL
<END Copy Here>
Établir et démarrer sur des miroirs GPT dans des
Windows 64 bits
Cet article explique comment configurer la mise en miroir de partition de démarrage dynamique sur des
disques DE TABLE de partition GUID (GPT).
Résumé
Contrairement aux miroirs d’enregistrement de démarrage maître (MBR) dans les Windows 32 bits, il existe
d’autres étapes pour créer et démarrer correctement sur les volumes de démarrage en miroir sur les disques
GPT. Cet article explique également comment récupérer après une défaillance du disque principal si une
partition EFI n’était pas déjà établie sur le disque de l’ombre. Le disque doit avoir une partition EFI pour
démarrer.
Vous devez avoir les utilitaires Diskpart.exe et Bootcfg.exe intégrés pour créer des volumes miroirs amorçables
sur des disques GPT. Vous pouvez suivre certaines de ces étapes avec la console Gestion des disques, mais
d’autres uniquement avec l’utilitaire Diskpart.exe intégré.
Pour des raisons de cohérence et de simplicité d’utilisation, cet article utilise Diskpart.exe utilitaire pour effectuer
les étapes. Pour obtenir de l’aide Diskpart.exe commandes, démarrez Diskmgmt.msc, puis ouvrez les rubriques
d’aide dans le menu d’aide.
Les étapes sont effectuées avec des exemples réels. Les étapes indiquent les résultats attendus renvoyés par
chaque commande. Le disque 0 est le système principal et le lecteur de démarrage. Le disque 1 est le lecteur
d’ombre.
Préparer le lecteur d’ombres pour la mise en miroir

Avant de configurer la mise en miroir de volume de démarrage, il est bon d’avoir un autre disque GPT sur
l’ordinateur qui contient une partition EFI (Extensible Firmware Interface). La partition EFI contient les fichiers
système utilisés pour démarrer le système d’exploitation. Si le lecteur système principal (disk-0) échoue, vous
pouvez utiliser la partition EFI sur le lecteur de l’ombre (disk-1) pour démarrer. Cette étape crée et prépare les
nouvelles partitions EFI et Microsoft Reserved (MSR) sur le lecteur de secours. Vous pouvez utiliser uniquement
l’utilitaire Diskpart.exe pour créer les partitions EFI et MSR requises. Vous ne pouvez pas utiliser la console
gestion des disques pour créer ou mettre en miroir des partitions EFI ou MSR.
Avant de commencer, assurez-vous que vous avez un autre disque BASIC avec tout l’espace libre non alloué
d’une capacité égale ou supérieure à celle du système de disques principaux et des partitions de démarrage. Si
vous avez déjà converti le lecteur de rechange en disque de rechange dynamique, revenir à la base avant de
suivre ces étapes.
1. À l’invite de commandes, exécutez l’utilitaire Diskpart.exe commande.
Cette commande démarre la console diskpart. Une fois initialisé, la>DISKPART s’affiche. Il attend vos
commandes d’entrée.
2. Sélectionnez le disque qui doit être le lecteur d’ombre, puis convertissez le lecteur en GPT. Dans cet
exemple, le disque 1 est utilisé pour le lecteur miroir (ombre).
NOTE
Le disque que vous sélectionnez ne doit contenir aucune partition de données et doit être un disque de base
brut avec uniquement un espace non alloué de capacité égale ou supérieure à celle du disque système
principal.
Voici les commandes que vous tapez à l’invite de commandes.
DISKPART> Select disk 1
Le disque 1 est maintenant le disque sélectionné.
DISKPART> Convert GPT
Diskpart a réussi à convertir le disque sélectionné au format GPT.
DISKPART> List partition
Décalage de taille de type de la partition ###

Partition 1 Réservé 32 Mo 17 Ko
NOTE
Si vous affichez plusieurs partitions à ce stade, vous avez sélectionné le lecteur erroné ou vous n’avez pas
commencé avec un lecteur brut. Corrigez cette situation avant de continuer, sinon une perte de données
peut se produire.
3. Sélectionnez la partition 1 sur le disque 1, puis supprimez-la : vous devez utiliser la commande de
remplacement pour supprimer la partition Microsoft Reserved (MSR). Vous allez créer à nouveau une
partition MSR après avoir créé la partition EFI requise.
DISKPART> Select partition 1
La partition 1 est désormais la partition sélectionnée.
DISKPART> Delete partition override
Diskpart a correctement supprimé la partition sélectionnée.
4. Sélectionnez disk-0, puis listez les partitions sur disk-0. Avec la sortie de la commande de liste, créez de
nouvelles partitions EFI et MSR sur le disque 1 qui ont les mêmes tailles que celles du disque 0.

Partition 1 Système 204 Mo 32 Ko <---- PARTITION EFI
Partition 2 Principale 4996 Mo 204 Mo
Partition 3 Réservé 32 Mo 9 Go <---- PARTITION MSR
DISKPART> select disk 1
DISKPART> create partition efi size=204
Diskpart a réussi à créer la partition spécifiée.
DISKPART> create partition msr size=32
Diskpart a réussi à créer la partition spécifiée.
DISKPART> list partition

Partition 1 Système 204 MO 17 Ko <---- NOUVELLE PARTITION EFI SUR L’OMBRE
*Partition 2 Réservé 32 Mo 204 Mo <---- NOUVELLE PARTITION MSR SUR L’OMBRE
5. Sélectionnez la partition EFI sur le lecteur d’ombres, puis affectez une lettre à la partition EFI afin qu’elle
puisse être mise en forme. Dans cet exemple, la lettre de lecteur S est affectée à la partition EFI de
l’ombre. Vous pouvez utiliser n’importe quelle lettre de lecteur disponible pour cette étape.
DISKPART> Assign letter=S
Diskpart a correctement affecté la lettre de lecteur ou le point de montage.
6. Ouvrez une nouvelle invite de commandes, puis utilisez l’utilitaire de format pour mettre en forme la
partition EFI (S:) avec le système de fichiers FAT. Vous devez le faire pour pouvoir copier les fichiers
système de la partition EFI principale vers cette nouvelle partition EFI. Ne pas formater avec NTFS. Le
système ne peut pas démarrer à partir d’une partition EFI, sauf s’il est formaté avec le système de fichiers
FAT.
C:\> format s: /fs:fat /q /y
Le type du système de fichiers est RAW.

Le nouveau système de fichiers est FAT.
QuickFormatting 204M
Initialisation de la table d’allocation de fichiers (FAT)...
Format complet.
213 680 128 octets d’espace disque total.
213 680 128 octets disponibles sur disque.
4 096 octets dans chaque unité d’allocation.
52 168 unités d’allocation disponibles sur disque.
16 bits dans chaque entrée FAT.
Numéro de série de volume EA34-03C7
7. Appuyez sur ALT+TAB pour revenir à la fenêtre de commande diskpart. Sélectionnez la partition EFI sur le
lecteur principal (disk-0), puis affectez une lettre de lecteur à cette partition EFI. Dans cet exemple, la lettre
de lecteur P est affectée à la partition EFI principale sur disk-0. Vous pouvez utiliser n’importe quelle lettre
de lecteur disponible pour cette étape.
DISKPART> Assign letter=P
Diskpart a correctement affecté la lettre de lecteur ou le point de montage.
8. Appuyez de nouveau sur ALT+TAB pour revenir à l’autre invite de commandes. Utilisez la commande
xcopy pour copier les fichiers système à partir de la partition EFI principale (P:) vers la partition EFI de
l’ombre (S:). Vous devez le faire pour vous assurer que le lecteur d’ombres peut démarrer le système en
cas de panne du disque 0. Veillez à utiliser les lettres de lecteur correctes si vous avez utilisé différentes
lettres pour vos partitions EFI.
C:\> xcopy p:\*.* s: /s /h
p:\EFI\Microsoft\WINNT50\Boot0003
p:\EFI\Microsoft\WINNT50\ia64ldr.efi
p:\EFI\Microsoft\EFIDrivers\fpswa.efi
p:\MSUtil\diskpart.efi
p:\MSUtil\fdisk.efi
p:\MSUtil\format.efi
p:\MSUtil\nvrboot.efi
7 fichiers copiés
9. Supprimez les lettres de lecteur affectées aux deux partitions EFI. Cette étape est facultative, car après un
redémarrage, elles ne seront pas ré-affectées.
DISKPART> Select volume P
Le volume P est le volume sélectionné.
DISKPART> Remove
Diskpart a correctement supprimé la lettre de lecteur ou le point de montage.

Répétez les étapes pour le volume S.
Convertir les lecteurs principal et d’ombre en disques dynamiques

Pour pouvoir établir un miroir, le lecteur principal (source) (Disk-0) et le lecteur d’ombres (destination) (Disk-1)
doivent être convertis en dynamic. Une fois que les disques sont dynamiques (après un redémarrage), vous
pouvez établir le miroir. Vous pouvez le faire avec la console Gestion des disques ou l’utilitaire Diskpart.exe
disque.
1. Avec Diskpart.exe, sélectionnez le disque à convertir en disque dynamique, puis converti en disque
dynamique. Effectuez cette tâche sur les disques GPT principal et de l’ombre. Commencez par le disque
d’ombre.
Le disque 1 est maintenant le disque sélectionné
DISKPART> Convert dynamic
Diskpart a réussi à convertir le disque sélectionné au format dynamique.
Le disque 0 est désormais le disque sélectionné
Vous devez redémarrer votre ordinateur pour effectuer cette opération.
DISKPART> Exit
Quitter Diskpart...
2. Fermez et redémarrez votre ordinateur pour terminer la conversion du lecteur système (disk-0) en lecteur
dynamique. Cela peut nécessiter deux redémarrages.
Établir un miroir du lecteur de démarrage au lecteur d’ombres
Une fois que les lecteurs principaux (disk-0) et shadow (disk-1) sont dynamiques, vous pouvez établir le miroir
du volume de démarrage sur le lecteur d’ombre. Vous pouvez le faire avec la console de gestion des disques ou
l’utilitaire Diskpart.exe disque.
1. Avec Diskpart.exe, sélectionnez le volume de démarrage (C:), puis miroirz le volume sur le disque de
l’ombre (disque-1).
DISKPART> Select volume C
Le volume 1 est le volume sélectionné.
DISKPART> add disk=1
Diskpart a réussi à ajouter un miroir au volume.
2. Attendez la fin de la synchronisation du volume, puis quittez Diskpart.

Utiliser Bootcfg.exe pour ajouter de nouvelles entrées de démarrage
de partition EFI à NVRAM
Maintenant que vous avez correctement établi le miroir de démarrage, une nouvelle entrée de démarrage a été
automatiquement ajoutée à NVRAM afin de pouvoir démarrer sur le lecteur d’ombres. Cette nouvelle entrée
s’affiche sous la forme Boot Mirror C: - plex secondaire dans le menu de démarrage. Si vous la sélectionnez,
elle démarre dans le système d’exploitation sur le lecteur de l’ombre. Toutefois, si un problème se produit pour
l’un des fichiers système ou la partition EFI elle-même sur disk-0 ou si disk-0 a échoué complètement, vous
devez démarrer à partir de la partition EFI sur disk-1. Pour que cela fonctionne, vous devez ajouter des entrées
de démarrage dans NVRAM avec l’utilitaire Bootcfg.exe de démarrage.
1. À l’invite de commandes, exécutez l’utilitaire Bootcfg.exe pour afficher les entrées de démarrage actuelles.
Vous avez une entrée de démarrage pour le système d’exploitation principal (id d’entrée de démarrage :1)
et une entrée de démarrage pour le lecteur Miroir (ombre) (id d’entrée de démarrage :5).
C:> bootcfg
Options de démarrage
Délai d’out : 30
Valeur par défaut : \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDO
CurrentBootEntryID: 5
Entrées de démarrage
ID d’entrée de démarrage : 1
Nom convivial du système d’exploitation : Windows 2003 Server, Enterprise OsLoadOptions :
N/A
BootFilePath: \Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Nom convivial du système d’exploitation : LS120
Nom convivial du système d’exploitation : CDROM
Nom convivial du système d’exploitation : EFI Shell
Nom convivial du système d’exploitation : Boot Mirror C: - plex secondaire
OsLoadOptions : N/A
2. Avant de pouvoir ajouter les nouvelles entrées pour la partition EFI et la partition de démarrage sur le
lecteur de l’ombre à NVRAM, vous devez lister les partitions existantes sur disk-0 afin de pouvoir extraire
les informations guid de partition sur la partition EFI actuelle. Utilisez la bootcfg /list commande sur
disk-0 pour afficher toutes les partitions :
C:\> bootcfg /list 0
Informations sur la table de partition pour le disque : 0

Partition n/ : 1
Style de partition : GPT
Décalage de début : 32 256
Longueur de la partition : 213 825 024
GUID de partition : {68d298c0-1b6a-01c1-507b-9e5f8078f531}
Type de GUID : {c12a7328-f81f-11d2-ba4b-00a0c93ec93b}
Nom de la partition : partition système EFI
Partition n/ : 2
Décalage de début : 213 857 280
Longueur de la partition : 5 142 056 960
GUID de partition : {68d298c0-1b6a-01c1-f1b3-12714f758821}
Type de GUID : {af9b60a0-1431-4f62-bc68-3311714a69ad}
Nom de la partition : partition de données LDM
Partition n/ : 3
Décalage de début : 9 153 031 680
GUID de partition : {73e47280-0d38-11d7-b47f-806e6f6e6963}
Type de GUID : {5808c8aa-7e8f-42e0-85d2-e1e90434cfb3}
Nom de la partition : partition de métadonnées LDM
Partition n/ : 4
GUID de partition : {1ca4672d-a37c-4e12-bacb-c5ae97924965}
Type de GUID : {e3c9e316-0b5c-4db8-817d-f92df00215ae}
Nom de la partition : partition réservée Microsoft
Notez le GUID de partition EFI. {________-____-____-____-____________} Il sera utilisé comme GUID

SOURCE dans une commande ultérieure.
Dans cet exemple, la valeur est {68d298c0-1b6a-01c1-507b-9e5f8078f531} et sera utilisée dans
une commande ultérieure.
3. Utilisez la bootcfg /list commande sur disk-1 pour afficher toutes ses partitions :
C:\> bootcfg /list 1

Partition n/ : 1
GUID de partition : {476688c5-8ebf-47d2-80e7-cf9d065edb81}
Type de GUID : {c12a7328-f81f-11d2-ba4b-00a0c93ec93b}
Nom de la partition : partition système EFI
Partition n/ : 2
GUID de partition : {b72d10f6-e94e-4a4d-bb8e-4da985cc1679}
Partition n/ : 3
GUID de partition : {824858f3-b8d5-4b4d-a3c7-18aac4442b7e}
Partition n/ : 4
GUID de partition : {f3d11286-2582-4d76-889c-b82c346be44e}
Notez le GUID de partition EFI. {________-____-____-____-____________} Il sera utilisé comme GUID

CIBLE dans une commande ultérieure.
Dans cet exemple, la valeur est {476688c5-8ebf-47d2-80e7-cf9d065edb81} et sera utilisée dans
une commande ultérieure.
4. Vous avez maintenant les valeurs GUID EFI SOURCE et TARGET que vous devez cloner les entrées de
démarrage dans NVRAM. Les nouvelles entrées utilisent le nouveau GUID de partition EFI sur le lecteur
d’ombres pour démarrer le système en cas de panne du disque 0. Utilisez la commande pour ajouter de
nouvelles entrées de démarrage NVRAM avec vos valeurs GUID source et cible enregistrées aux
bootcfg /clone étapes 2 et 3.
C: > bootcfg /clone /sg {68d298c0-1b6a-01c1-507b-9e5f8078f531} /tg {476688c5-8ebf-47d2-

80e7-cf9d06 5edb81} /d+ Cloned_Entry
INFO : entrée de démarrage dont l’ID est « 1 » cloné avec succès.

INFO : entrée de démarrage dont l’ID est « 5 » cloné avec succès.
SUCCESS : l’opération s’est terminée correctement.
5. Pour voir les nouvelles entrées clonées ajoutées à NVRAM, utilisez la commande bootcfg et notez que
vous avez désormais sept entrées au lieu de cinq. Les deux dernières entrées sont les entrées clonées et
utiliseront la partition EFI sur le lecteur d’ombres (disque-1) pour démarrer.
C:\>bootcfg
Délai d’out : 30
Valeur par défaut :
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Nom convivial du système d’exploitation : Windows 2003 Server, Enterprise
OsLoadOptions : N/A
OsLoadOptions : N/A
Nom convivial du système d’exploitation : Windows 2003 Server, Enterprise Cloned_Entry
OsLoadOptions : N/A
Nom convivial du système d’exploitation : Boot Mirror C: - plex secondaire Cloned_Entry
OsLoadOptions : N/A
Tester le démarrage du lecteur d’ombres avec les nouvelles entrées de

démarrage
Une fois que vous avez créé les nouvelles entrées de démarrage dans NVRAM, testez les entrées pour vous
assurer que le système peut démarrer sur le lecteur de l’ombre en cas d’échec de disk-0.
1. Effectuez un arrêt et un redémarrage de votre Windows.
2. Dans le menu de démarrage, sélectionnez l’entrée de démarrage nommée Boot Mirror C: - secondar y
plex Cloned_Entr y to boot to the shadow drive. La partition EFI sur le lecteur d’ombres sera utilisée pour
démarrer le Windows d’exploitation. Bien que cela ne soit pas une raison, vous pouvez également désactiver
l’ordinateur, supprimer disk-0, puis refaire le test pour vous assurer que le système sera démorçable si le
disque système d’origine tombe en panne et est supprimé.
Récupérer un lecteur de démarrage de l’ombre avec une partition EFI

manquante ou endommagée
Si le système d’exploitation Windows d’origine était un logiciel en miroir sur un disque GPT dynamique qui ne
contenait pas de partition EFI, ou si la partition EFI est endommagée ou si le disque du système principal
(disque-0) tombe en panne, vous pouvez recevoir le message d’erreur suivant lorsque vous essayez de démarrer
sur le disque de l’ombre :
LOADING.: Boot Mirror C: - Secondary plex

Load of Boot Mirror c: - secondary plex failed: Not Found
Suspendu : appuyez sur n’importe quelle touche pour continuer.
Vous devez maintenant utiliser la procédure suivante pour récupérer le lecteur de système d’exploitation
d’origine (shadow). Les étapes suivantes vous montrent l’ensemble du processus. Le processus inclut le
remplacement du disque défectueux- 0, la réinstallation de Windows sur le nouveau disque de remplacement,
qui crée une nouvelle partition système EFI, puis l’ajout de nouvelles entrées de démarrage dans NVRAM afin
que vous pouvez démarrer à nouveau dans le système d’exploitation d’origine sur le disque d’ombre-1.
1. Supprimez le lecteur système en panne (disk-0) et remplacez-le par un bon disque. Consultez vos
manuels matériels pour savoir comment remplacer correctement le disque défailli. Le disque de
remplacement n’a pas besoin d’être partitioné ou formaté. Il peut s’agit d’un tout nouveau disque.
2. Insérez Windows CD-ROM d’installation du serveur 2003 dans le lecteur de CD-ROM de l’ordinateur, puis
sur le système.
3. Lorsque le menu options de démarrage du système s’affiche, sélectionnez le démarrage à partir du CD-
ROM. Lorsque vous êtes invité à appuyer sur n’importe quelle touche pour démarrer à partir du
CD,appuyez sur n’importe quelle touche.
Cette configuration démarre Windows 2003 Server.
4. Dans l’écran d’Windows d’installation, appuyez sur Entrée pour installer et autoriser le programme
d’installation à créer automatiquement la nouvelle partition système.
Vous devez le faire pour démarrer et permettre à l’installation de continuer.
5. Une fois les nouvelles partitions EFI et MSR créées, sélectionnez l’espace libre sur disk-0 et créez une
partition suffisamment grande pour installer Windows et contenir un fichier de page.
6. Sélectionnez la partition nouvellement créée pour installer Windows sur, puis sélectionnez l’option de
format que vous souhaitez mettre en forme. Le programme d’installation se poursuit. Répondez à toutes
les questions appropriées auxquelles vous êtes invité, puis laissez le programme d’installation se
terminer.
7. Une fois l’installation terminée, connectez-vous à la console en tant qu’administrateur.
8. À l’invite de commandes, exécutez la commande bootcfg pour afficher les éléments de menu de
démarrage actuels à partir de NVRAM.
C:\>bootcfg
Délai d’délai : 5 par défaut : \Device\HarddiskVolume3\WINDOWS CurrentBootEntryID: 1
Nom convivial du système d’exploitation : Microsoft Windows Server 2003, Êdition Entreprise
OsLoadOptions : N/A
OsFilePath: \Device\HarddiskVolume3\WINDOWS
Nom convivial du système d’exploitation : Windows Server 2003, Êdition Entreprise
OsLoadOptions : N/A
BootFilePath : (null)
OsFilePath : (null)
OsLoadOptions : N/A
OsFilePath : (null)
9. Utilisez la commande pour afficher toutes les partitions sur le disque de l’ombre bootcfg /list (disk-1).
Recherchez la partition de démarrage Windows d’origine. Il a le nom de partition de données LDM et a
une longueur de partition de la même taille que la partition de démarrage d’origine.
Dans cet exemple, la partition de démarrage est l’entrée N: 3 avec le GUID {9aee294a-fa7d-4d4a-8a47-
51a1dd1f9867}
C:\bootcfg /list 1

Partition n/ : 1
GUID de partition : {646091f1-b826-47e8-a72c-f22072e9a769}
Partition n/ : 2
GUID de partition : {afb1e6b9-d8a6-456d-8df1-31327f94f3fe}
Partition n/ : 3
GUID de partition : {9aee294a-fa7d-4d4a-8a47-51a1dd1f9867}
Partition n/ : 4
GUID de partition : {ab104fde-0782-4810-842e-0fb291e385ad}
10. Utilisez la commande pour ajouter une entrée de démarrage dans NVRAM pour la partition de
démarrage des disques de l’ombre et lui donner bootcfg /mirror une description significative. Utilisez le
GUID de partition de la partition de démarrage extraite précédemment.
C:\>bootcfg /mirror /add {9aee294a-fa7d-4d4a-8a47-51a1dd1f9867} /D "Original Shadow drive"
SUCCESS : l’entrée de démarrage en miroir a été ajoutée.
11. Utilisez bootcfg pour afficher à nouveau les éléments de menu de démarrage. Notez que la nouvelle
entrée a été ajoutée au bas de la liste. Vous pouvez désormais utiliser cette entrée pour démarrer sur le
système d’Windows d’origine.
- C:\>bootcfg
Délai d’out : 5
Par défaut : \Device\HarddiskVolume3\WINDOWS
Nom convivial du système d’exploitation : Microsoft Windows Server 2003, Êdition Entreprise
OsLoadOptions : N/A
OsFilePath: \Device\HarddiskVolume3\WINDOWS
Nom convivial du système d’exploitation : Windows Server 2003, Êdition Entreprise
OsLoadOptions : N/A
OsFilePath : (null)
OsLoadOptions : N/A
OsFilePath : (null)
Nom convivial du système d’exploitation : lecteur d’ombre d’origine
OsLoadOptions : N/A
OsFilePath : (null)
12. Fermez l’ordinateur, puis redémarrez-le. Sélectionnez l’élément de menu de démarrage Original
Shadow Drive pour démarrer dans le système d’exploitation d’origine. Cela permet au serveur de
revenir en production. Pour corriger la mise en miroir afin que vous pouvez utiliser le nouveau disque-0
comme lecteur de système d’exploitation principal et être à nouveau dans un environnement à tolérance
de panne, poursuivez les étapes suivantes.
Rétablir le miroir du lecteur de démarrage principal

Lors du démarrage dans le lecteur d’ombres (disque-1), vous devez « supprimer » le miroir rompu, puis
supprimer le disque manquant. Vous pouvez le faire avec la console Gestion des disques ou l’utilitaire
Diskpart.exe disque.
NOTE
S’il y avait des volumes supplémentaires sur le disque dynamique d’origine qui a échoué, ils doivent également être
supprimés avant que vous ne soyez autorisé à supprimer le disque manquant.
1. Avec Diskpart.exe, listez les volumes, puis notez le numéro de volume (Volume #) du miroir défaissant.
Sélectionnez le volume miroir (volume #), puis affichez les détails pour voir de quel disque manquant
(m#) vous devez rompre le miroir. Dans cet exemple, vous travaillez avec le volume 0 sur le disque m0
manquant.
DISKPART> list volume

Échec du démarrage rd du volume 0 C PRIMARY NTFS Mirror 2996 Mo
Volume 1 D CD-ROM 0 B Healthy
Volume 2 Partition 2996 Mo Sain
Système sain de partition volume 3 de 102 Mo
DISKPART> select volume 0

Volume de détails> DISKPART
Disk ### Status Size Free Dyn Gpt

Disque M0 manquant 2 996 Mo 0 B *
Disque 1 Online 4149 Mo 1120 Mo **
2. Break the mirror by specifying the missing disk (m0), and then use the no keep option to remove the plex
(partition) from the missing disk. List the volumes to make sure the mirror is gone and the volume is
now listed as a simple volume.
DISKPART> break disk=m0 nokeep
Le service n’a pas mis à jour le fichier de démarrage.

Diskpart a réussi à terminer le volume miroir.

Volume 0 C PRIMARY NTFS Démarrage sain simple de 2 996 Mo
Volume 2 Partition 2996 Mo Sain
3. Sélectionnez le disque manquant (m0), puis supprimez-le.

DISKPART> select disk m0
Le disque M0 est maintenant le disque sélectionné.
DISKPART> delete disk
Diskpart a correctement supprimé le disque manquant.
4. Supprimez la nouvelle partition Windows server d’exploitation sur disk-0, car elle n’est plus nécessaire.
Cela permet de revenir en miroir sur disk-0.
NOTE
Cette étape est facultative si vous avez suffisamment d’espace libre sur disk-0 pour rétablir le miroir.

Partition 1 Système 102 Mo 32 Ko
Partition 2 réservé 31 Mo 102 Mo
Partition 3 principale 2 996 Mo 133 Mo
DISKPART> select partition 3
Partition 3 est désormais la partition sélectionnée.
DISKPART> delete partition
Diskpart a correctement supprimé la partition sélectionnée.
5. Convertissez disk-0 en Dynamic, puis sélectionnez le volume du système d’exploitation sur disk-1 et
rétablir le miroir sur disk-0. Cela place l’ordinateur dans un environnement à tolérance de panne, et une
fois que le miroir est sain, vous pouvez démarrer à nouveau sur disk-0 avec la nouvelle option de
démarrage qui a été automatiquement ajoutée au NVRAM.
DISKPART> convert dynamic
Diskpart a réussi à convertir le disque sélectionné au format dynamique.


Volume 0 C PRIMARY NTFS Démarrage sain simple de 2 996 Mo
DISKPART> select volume 0
Diskpart a réussi à ajouter un miroir au volume.
6. Attendez que l’état de la mise en miroir devienne sain. Vous pouvez utiliser la commande de volume de
liste à plusieurs reprises jusqu’à ce que l’état change de Reconstruction à Sain. Quittez l’utilitaire Diskpart.

Volume 0 C PRIMARY NTFS Mirror Démarrage sain 2996 Mo
DISKPART> exit
Quitter Diskpart...
7. Utilisez la commande bootcfg pour afficher la nouvelle option de démarrage qui a été ajoutée au
NVRAM. Cette nouvelle entrée est nommée Boot Mirror C: - plex secondaire et est très probablement
l’ID d’élément de menu 1. Vous pouvez maintenant nettoyer les entrées de démarrage d’origine pour le
système d’exploitation d’origine et le plex secondaire d’origine avec la bootcfg /delete /ID # commande.
C:\>bootcfg
Délai d’out : 30
Par défaut : (null)
OsLoadOptions : N/A
OsFilePath : (null)
Nom convivial du système d’exploitation : Windows Server 2003, Enterprise
OsLoadOptions : N/A
Nom convivial du système d’exploitation : Miroir de démarrage C : - Plex secondaire
OsLoadOptions : N/A
Nom convivial du système d’exploitation : système d’ombre d’origine
OsLoadOptions : N/A
C:\>bootcfg /delete /ID 6
SUCCESS : l’entrée de démarrage spécifiée a été supprimée.
C:\>bootcfg /delete /ID 2
SUCCESS : l’entrée de démarrage spécifiée a été supprimée.
8. Cette procédure se termine et les entrées de démarrage restantes dans le menu de démarrage sont
toutes des entrées de démarrage valides pour démarrer sur les lecteurs principal et de l’ombre.
Mise en miroir GPT dans Windows Server 2008

Si vous utilisez Windows Server 2008, consultez l’article suivant pour configurer un miroir GPT :
Comment configurer la mise en miroir de partition de démarrage dynamique sur des disques de table de
partition GUID (GPT) dans Windows Server 2008
Étendre un volume de données dans Windows
Cet article décrit les rubriques suivantes :

Utilisation de l’utilitaire d’invite de commandes Diskpart.exe pour étendre un volume de données dans un
espace non alloué dans Windows Server 2003, Windows XP et Windows 2000.
Comment étendre la partition de démarrage dans Windows Server 2008.
Utilisez Diskpart.exe pour étendre un volume de données dans

Windows Server 2003, Windows XP et Windows 2000
Vous pouvez utiliser l’utilitaire Diskpart.exe pour gérer les disques, les partitions et les volumes à partir d’une
interface de ligne de commande. Vous pouvez utiliser Diskpart.exe sur les disques de base et les disques
dynamiques. Si un volume NTFS réside sur un conteneur RAID 5 matériel qui peut ajouter de l’espace au
conteneur, vous pouvez étendre le volume NTFS avec Diskpart.exe alors que le disque reste un disque de base.
Utilisez la commande d’extension pour incorporer de l’espace non alloué dans un volume existant tout en
conservant les données.
Les conditions requises pour la commande d’extension sont les suivantes :
Le volume doit être formaté avec le système de fichiers NTFS.
Pour les volumes de base, l’espace non alloué pour l’extension doit être l’espace contigu suivant sur le
même disque.
Pour les volumes dynamiques, l’espace non alloué peut être n’importe quelle zone vide sur n’importe
quel disque dynamique du système.
Seule l’extension des volumes de données est prise en charge. L’extension des volumes système ou de
démarrage peut être bloquée et vous pouvez recevoir l’erreur suivante :
Diskpart n’a pas réussi à étendre le volume. Assurez-vous que le volume est valide pour l’extension
Vous ne pouvez pas étendre la partition si le fichier de page système se trouve sur la partition. Déplacez
le fichier de page vers une partition que vous ne souhaitez pas étendre.
Pour étendre une partition ou un volume, sélectionnez d’abord le volume pour lui donner le focus, puis spécifiez
la taille de l’extension. Pour étendre un volume, suivez les étapes suivantes :
1. À l’invite de commandes, tapezdiskpart.exe.
2. Tapez le volume de liste pour afficher les volumes existants sur l’ordinateur.
3. Tapez <volume number> Le volume Select où est le numéro du volume que vous <volume number>
souhaitez étendre.
4. Type extend [size=n] [disk=n] [noerr]. La section suivante décrit les paramètres :
size=n
Espace, en mégaoctets (Mo), à ajouter à la partition actuelle. Si vous ne spécifiez pas de taille, le
disque est étendu pour utiliser tout l’espace non alloué contigu suivant.
disk=n
Disque dynamique sur lequel étendre le volume. Un espace égal à size=n est alloué sur le disque.
Si aucun disque n’est spécifié, le volume est étendu sur le disque actuel.
noerr
Pour les scripts uniquement. Lorsqu’une erreur est lancée, ce paramètre spécifie que Diskpart
continue de traiter les commandes comme si l’erreur ne s’était pas produite. Sans le paramètre
noerr, une erreur entraîne la sortie de Diskpart avec un code d’erreur.
5. Tapez exit pour quitter Diskpart.exe.
Une fois la commande d’extension terminée, vous devez recevoir un message qui indique que Diskpart a
correctement étendu le volume. Le nouvel espace doit être ajouté au lecteur existant tout en conservant les
données sur le volume.
Dans Windows XP et Windows 2000, vous ne pouvez pas utiliser Diskpart.exe pour étendre un volume simple
sur un disque dynamique créé à l’origine sur un disque de base. Vous pouvez étendre uniquement les volumes
simples qui ont été créés après la mise à niveau du disque vers le disque dynamique. Si vous essayez d’étendre
un volume simple sur un disque dynamique qui a été créé à l’origine sur un disque de base, vous recevez le
message d’erreur suivant. Cette restriction a été supprimée dans Windows Server 2003.
Diskpart n’a pas réussi à étendre le volume.

Assurez-vous que le volume est valide pour l’extension
NOTE
Windows Server 2003 et Windows XP incluent Diskpart.exe dans le cadre du système d’exploitation de base.
Nous vous recommandons de contacter votre fournisseur système pour obtenir la mise à jour du BIOS, du
microprogramme, des pilotes et des agents avant de les convertir en disques dynamiques.
Étendre la partition de démarrage dans Windows Server 2008

Pour étendre la partition de démarrage dans Windows Server 2008, suivez les étapes suivantes :
1. Cliquez sur Démarrer le Gestionnaire de > ser veur.
2. Dans le volet de navigation, développez Stockage, puis cliquez sur Gestion des disques.
3. Dans le volet d’informations, cliquez avec le bouton droit sur le volume voulu, puis cliquez sur Étendre le
volume.
4. Suivez les instructions de l’Assistant Extension du volume pour étendre la partition de démarrage.
NOTE
Vous pouvez uniquement étendre la partition de démarrage dans un espace disque non alloué contigu.
CORRECTIF : utilisation importante de la mémoire
dans ReFS sur Windows
Cet article fournit une solution aux problèmes de pression de mémoire et de performances qui se produisent
dans le système de fichiers Resilient File System (ReFS) dans Windows.
S’applique à : Windows 10 - toutes les éditions, Windows Server 2016, Windows Server 2019
Symptômes
Vous remarquez une utilisation importante de la mémoire sur un ordinateur exécutant Windows 10, Windows
Server 2016, Windows Server 2019, Windows Server, 1903 ou Windows Server, version 1909.
Cause
Pour renforcer la résilience de ses métadonnées, le système de fichiers résilient (ReFS) dans Windows Server
2016 utilise la sémantique d’allocation sur écriture pour toutes les mises à jour de métadonnées. Ce qui signifie
que ReFS ne met jamais à jour les métadonnées sur place. Au lieu de cela, il effectue toutes les écritures dans les
régions nouvellement allouées.
Toutefois, l’allocation à l’écriture entraîne l’émission par ReFS de plus d’E/S de métadonnées aux nouvelles
régions du volume que les systèmes de fichiers en écriture sur place. En outre, ReFS utilise la logique de mise en
cache de bloc pour mettre en cache ses métadonnées dans la RAM. Il n’est pas aussi efficace en ressources que
la logique de mise en cache des fichiers.
Ensemble, la logique de mise en cache de bloc ReFS et la sémantique d’allocation sur écriture entraînent la taille
des flux de métadonnées ReFS. ReFS utilise le gestionnaire de cache pour créer les flux de métadonnées, et le
gestionnaire de cache décompresse les affichages inactifs. Dans certains cas, ce démapage différé entraîne
l’expansion du jeu de travail actif sur le serveur. Cela crée une pression de mémoire qui peut entraîner des
performances médiocres.
Résolution
This issue is addressed in cumulative update 4013429 that was released on March 14, 2017. La mise à jour
introduit trois paramètres de Registre tunables.
La mise à 4013429 cumulative est disponible via Windows update. Vous pouvez également le télécharger
directement via le catalogue Microsoft Update.
Pour plus d’informations, voir le 14 mars 2017—KB4013429 (os Build 14393.953)
Comment définir les paramètres tunables

Cette mise à jour fournit trois paramètres de Registre tunables pour traiter les flux de métadonnées ReFS
importants. Vous pouvez utiliser les méthodes facultatives suivantes pour définir les paramètres. Ces
paramètres peuvent être utilisés dans n’importe quelle combinaison, car ils ne se chevauchent pas
fonctionnellement.
IMPORTANT
Un redémarrage est nécessaire pour que ces modifications de paramètre prennent effet.
Ces paramètres doivent être définies de manière cohérente sur chaque nœud d’un cluster deover.
Option 1
Cette option permet à ReFS d’essayer d’effectuer une désmap mm de tous les flux de métadonnées à chaque
point de contrôle. Cette option produit le résultat attendu uniquement si le volume est inactif et n’a pas de pages
mappées.
Spécifiez les valeurs indiquées dans la sous-clé suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Nom de la valeur : RefsEnableLargeWorkingSetTrim
Définir RefsEnableLargeWorkingSetTrim = 1
Option 2
ReFS a une logique d’unmap MM différée. Ainsi, lorsque ReFS fait l’intégralité de l’espace de noms pour
terminer un désmap MM, il démasie à une certaine granularité. La quantité d’espace d’adressai virtuel non
mappée est déterminée par la formule suivante :
RefsNumberOfChunksToTrim 128 Mo (pour le volume de taille > 10 To) RefsNumberOfChunksToTrim 64 Mo
(pour le volume de taille < 10 To)
Cette option fonctionne si la plage va qui n’est pas mappée n’a pas de références actives (c’est-à-dire, les pages
de métadonnées mappées).
Nom de la valeur : RefsNumberOfChunksToTrim
VALEUR PAR DÉFAUT (si elle n’est pas définie ou 0) : 4
NOTE
Si refsNumberOfChunksToTrim a des valeurs supérieures, ReFS est plus agressif. Cela réduit la quantité de mémoire
utilisée. Définissez la valeur de trim sur un nombre approprié : 8, 16, 32, etc.
Option 3
Dans cette option, ReFS envoie un trim MM en ligne pendant qu’il démasde sa page de métadonnées. Il s’agit de
l’option la plus agressive, car elle peut entraîner une régression des performances si ReFS est utilisé sur des
supports hautes performances, tels qu’un SSD ou un NVMe.
Nom de la valeur : RefsEnableInlineTrim
Définir RefsEnableInlineTrim = 1
Recommandation :
Si un jeu de travail actif important entraîne des performances médiocres, essayez d’abord de définir
RefsEnableLargeWorkingSetTrim = 1 .
Si ce paramètre ne produit pas de résultat satisfaisant, essayez différentes valeurs pour
RefsNumberOfChunksToTrim , telles que 8, 16, 32, etc.
Si cela ne fournit toujours pas l’effet souhaité, définissez RefsEnableInlineTrim = 1 .
Pour mettre à jour ses métadonnées, ReFS utilise l’allocation sur écriture au lieu d’écrire sur place pour
améliorer sa résilience à l’altération.
L’écriture sur place est susceptible de faire l’objet d’écritures en écriture. Elle se produit si une panne
d’alimentation ou un démontage inattendu entraîne une écriture partiellement terminée.
L’allocation à l’écriture permet à ReFS de maintenir de manière fiable la cohérence des métadonnées après une
panne d’alimentation ou un démontage inattendu. En effet, ReFS peut toujours référencer la copie de
métadonnées cohérente précédente.
Références
Vue d’ensemble du système de fichiers résilient (ReFS)
Les disques d’échange à chaud ne sont pas
reconnus
Cet article fournit des solutions de contournement pour le problème où les disques d’échange à chaud ne sont
pas reconnus.
Symptômes
Supposons que vous avez un ordinateur qui prend en charge les disques SATA de permutation à chaud et
exécute Windows Server 2012 R2. Pour certaines configurations système, lorsque vous insérez un ou plusieurs
lecteurs dans l’ordinateur, Windows ne peut pas détecter tous les lecteurs insérés. Par conséquent, vous ne
pouvez pas voir les lecteurs dans ce PC ou le Windows logiciel en snap-in Gestion des disques.
Cause
Ce problème se produit en raison d’une erreur de communication qui se produit entre les lecteurs concernés et
les Windows.
Pour contourner ce problème, vous pouvez utiliser l’une des méthodes suivantes.
Méthode 1
Supprimez et réinséérer les lecteurs affectés.
Méthode 2
Utilisez l Windows logiciel en ligne Gestion des disques, puis réascanez les disques.
Statut
Microsoft a confirmé qu’il s’agit d’un problème dans les produits Microsoft au début de cet article.
produits.
Comment NTFS réserve de l’espace pour sa table
MFT (Master File Table)
Cet article explique comment NTFS réserve de l’espace pour sa table MFT (Master File Table).
Résumé
Le système de fichiers NTFS contient à son cœur, un fichier appelé MFT (Master File Table). Il existe au moins une
entrée dans le MFT pour chaque fichier sur un volume NTFS, y compris le MFT lui-même.
Étant donné que les utilitaires défragmentant les volumes NTFS ne peuvent pas déplacer les entrées MFT et que
la fragmentation excessive du MFT peut avoir un impact sur les performances, NTFS réserve de l’espace pour le
MFT afin de maintenir le MFT aussi contigu que possible à mesure qu’il croît.
Dans Windows, l’utilitaire défragmente le MFT.
Utilitaire défragmenté
Une opération de défragmentation sur MFT combine un fichier MFT en 1 et l’empêche d’être stocké à plusieurs
endroits qui ne sont pas séquentiels sur le disque. Dans cette classe d’opération, le fichier MFT est plus
séquentiel. Toutefois, il s’agit exactement de la taille du fichier MFT avant l’opération de défragmentation.
Un MFT peut être trop grand si un volume utilisé pour avoir beaucoup de fichiers qui ont été supprimés. Les
fichiers qui ont été supprimés provoquent des trous internes dans la MFT. Ces trous sont des régions
importantes qui ne sont pas inutilisées par les fichiers. Il est impossible de récupérer cet espace. Cela est au
moins vrai sur un volume NTFS en direct.
NTFS utilise des entrées MFT pour définir les fichiers auquel elles correspondent. Toutes les informations
relatives à un fichier, y compris sa taille, ses horodatés, ses autorisations et son contenu de données, sont
stockées dans des entrées MFT ou dans un espace externe au MFT, mais décrit par les entrées MFT.
(Les entrées de répertoire, externes au MFT, contiennent également des informations redondantes concernant
les fichiers. Toutefois, une discussion complète de toutes les structures sur NTFS n’entre pas dans le cadre de cet
article.)
À mesure que des fichiers sont ajoutés à un volume NTFS, davantage d’entrées sont ajoutées au MFT et la taille
du MFT augmente. Lorsque des fichiers sont supprimés d’un volume NTFS, leurs entrées MFT sont marquées
comme gratuites et peuvent être réutilisées, mais le MFT ne se réduit pas. Ainsi, l’espace utilisé par ces entrées
n’est pas récupéré à partir du disque.
En raison de l’importance de la MFT pour NTFS et de l’impact possible sur les performances si ce fichier devient
hautement fragmenté, NTFS s’est donné un effort particulier pour conserver ce fichier contigu. NTFS réserve
12,5 % du volume pour une utilisation exclusive du MFT jusqu’à ce que le reste du volume soit utilisé. Par
conséquent, l’espace pour les fichiers et les répertoires n’est pas alloué à partir de cette zone MFT tant que tout
l’espace n’est pas alloué en premier.
NOTE
Vous pouvez modifier la clé de Registre NtfsMFTZoneReser vation pour augmenter le volume en Windows. Pour plus
d’informations sur le MFT, consultez les éléments clés de la section Sur le processus de défragmentation de disque de
Maintaining Windows 2000 Peak Performance Through Defragmentation.
Selon la taille moyenne du fichier et d’autres variables, la zone MFT réservée ou l’espace non purgé sur le disque
peuvent être utilisés avant l’autre lorsque le disque remplit sa capacité.
Les volumes avec un petit nombre de fichiers relativement grands épuisent d’abord l’espace non servi, tandis
que les volumes avec un grand nombre de fichiers relativement petits épuisent d’abord l’espace de zone MFT.
Dans les deux cas, la fragmentation du MFT commence à se faire lorsqu’une région ou l’autre devient pleine. Si
l’espace non servi devient plein, de l’espace pour les fichiers et répertoires utilisateur commence à être alloué à
partir de la zone MFT en concurrence avec le MFT pour l’allocation. Si la zone MFT devient pleine, l’espace pour
les nouvelles entrées MFT est alloué à partir du reste du disque, en concurrence avec d’autres fichiers.
Un nouveau paramètre de Registre peut augmenter le pourcentage d’un volume que NTFS réserve à sa table de
fichiers maîtres. NtfsMftZoneReser vation est une valeur REG_DWORD qui peut prendre une valeur entre 1 et
4, où 1 correspond à la taille minimale de la zone MFT et 4 correspond à la valeur maximale. Si le paramètre
n’est pas spécifié ou si une valeur non valide est fournie, NTFS utilise une valeur par défaut de 1 pour ce
paramètre. Les ratios exacts qui correspondent à chaque paramètre ne sont pasdocumentés, car ils ne sont pas
standardisés et peuvent changer dans les prochaines sorties. Pour connaître le meilleur paramètre pour votre
environnement, il peut être nécessaire d’expérimenter différentes valeurs.
Pour déterminer la taille actuelle du MFT sur un ordinateur Windows, tapez la commande sur un dir /a $mft
volume NTFS.
Pour déterminer la taille actuelle du MFT sur un ordinateur Windows, utilisez le défragmenteur de disque pour
analyser le lecteur NTFS, puis cliquez sur Afficher le rappor t. Cela affiche les statistiques du lecteur, y compris la
taille MFT actuelle et le nombre de fragments.
Le défragmenteur de disque s’affiche en vert pour ce qu’on appelle les fichiers système et sur un volume au
format NTFS, il s’agit simplement de la combinaison du MFT, du pagefile.sys (s’il en existe un sur ce volume) et
de ce qui est appelé « zone MFT » ou espace réservé pour l’expansion MFT. Le rapport de défragmentation
affiche uniquement des informations sur le fichier d’affichage et MFT . il ne mentionne pas la zone MFT, car elle
n’affecte en aucune façon l’utilisation ou la capacité du disque.
La zone MFT n’est pas soustraite de l’espace disque disponible (gratuit) utilisé pour les fichiers de données
utilisateur, mais uniquement de l’espace utilisé en dernier. Lorsque le MFT doit augmenter en taille, par exemple,
vous avez créé de nouveaux fichiers et répertoires, il est d’abord tiré de la zone MFT, réduisant ainsi la
fragmentation MFT et optimisant les performances MFT.
La zone MFT par défaut est calculée et réservée par Ntfs.sys lors du montage du volume et est basée sur la taille
du volume. Vous pouvez augmenter la zone MFT à l’aide de l’entrée de Registre documentée ci-dessous, mais
vous ne pouvez pas rendre la zone MFT par défaut plus petite que ce qui est calculé par Ntfs.sys. L’augmentation
de la zone MFT ne diminue en aucun cas l’espace disque qui peut être utilisé par les utilisateurs pour les fichiers
de données.
NOTE
Les résultats renvoyés par la commande dir peuvent ne pas être à jour. La taille signalée par la commande dir peut refléter
les données mises en cache qui reflètent la taille du MFT au moment du début du système suite à un arrêt ordonné.
IMPORTANT
Pour ajouter cette valeur, effectuez les étapes suivantes :

1. Exécutez l’Éditeur du Registre (Regedt32.exe), puis allez à la sous-clé suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem
2. Dans le menu Edition, cliquez sur Ajouter une valeur.

3. Tapez les informations suivantes dans la boîte de dialogue :
Nom de la valeur : NtfsMftZoneReser vation
Données : (plage valide de 1 à 4)
4. Quittez l’Éditeur du Registre et redémarrez votre ordinateur.
NOTE
Il s’agit d’un paramètre d’utilisation qui n’affecte pas le format réel d’un volume. Au lieu de cela, il affecte la façon dont
NTFS alloue de l’espace sur tous les volumes sur un système donné. Par conséquent, pour être complètement efficace, le
paramètre doit être en vigueur à partir du moment où un volume est formaté et pendant toute la durée de vie du
volume. Si le paramètre de Registre est ajusté vers le bas ou supprimé, la zone MFT sera réduite en conséquence, mais
cela n’aura aucune incidence sur l’espace MFT déjà alloué et utilisé.
Comment établir un volume à bandes (RAID 0)
Cet article décrit les étapes à suivre pour établir un volume à bandes (RAID 0) dans Windows Server 2003.
Résumé
Un volume à bandes (RAID 0) combine des zones d’espace libre à partir de plusieurs disques durs (n’importe où
de 2 à 32) en un seul volume logique. Les données écrites sur un volume à bandes sont entrecoupées sur tous
les disques en même temps et non séquentiellement. Par conséquent, les performances du disque sont les plus
rapides sur un volume RAID 0 par rapport à tout autre type de configuration de disque. Les administrateurs
préfèrent utiliser des volumes à bandes lorsque la vitesse d’entrée/sortie (E/S) est importante. Tout système de
fichiers, y compris FAT, FAT32 ou NTFS, peut être utilisé sur un volume à bandes.
Il doit y avoir au moins deux disques durs. L’IDE, l’interface SCSI (Small Computer System Interface) ou
l’architecture mixte sont autorisés.
Tous les disques impliqués dans le volume à bandes doivent être des disques dynamiques.
Chaque partie de l’espace libre doit être identique (par exemple, la taille et le type de système de fichiers).
Comment configurer le système de gestion des disques

1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Gestion de l’ordinateur.
2. Développez Stockage nœud.
3. Cliquez sur Gestion des disques.
4. Dans le menu Affichage, pointez sur Haut, puis cliquez sur Liste disque.
Dans le volet droit, une colonne apparaît qui répertorie les attributs de chaque disque du système.
5. Dans le menu Affichage, pointez sur Bas, puis cliquez sur Affichage graphique.
Une vue graphique codée en couleur des disques du système s’affiche.
Le volet Description du disque (qui est affiché en gris) est placé sur le côté gauche de la description du volume,
qui est affiché en couleur. La description du disque contient des informations sur le numéro de disque de chaque
disque, s’il s’agit d’une configuration de base ou dynamique, de sa taille et de son état (en ligne ou hors
connexion).
Les descriptions de volume sont codées en couleur. Elles tiennent des informations sur chaque volume, telles
que la lettre de lecteur (si elle est affectée), si le volume est alloué ou non alloué, la partition ou la taille du
volume, et l’état d’état du volume.
Conditions requises pour s’assurer que les disques sont bien

configurer pour prendre en charge un volume à bandes
Disques : un minimum de deux disques sont nécessaires pour prendre en charge le striping.
Type : tous les disques impliqués dans le striping doivent être dynamiques. La conversion de base en
dynamique se passe très rapidement sans perte de données. Une fois la procédure de conversion terminée,
vous devez redémarrer l’ordinateur.
Capacité : le volume à bandes peut prendre l’intégralité du disque ou jusqu’à 50 mégaoctets (Mo) pour
chaque disque.
Espace non alloué : tous les disques que vous souhaitez mettre à niveau vers un disque dynamique doivent
contenir au moins 1 Mo d’espace libre à la fin du disque pour que la mise à niveau réussisse. La gestion des
disques réserve automatiquement cet espace libre lorsqu’elle crée des partitions ou des volumes sur un
disque, mais les disques avec des partitions ou des volumes créés par d’autres systèmes d’exploitation
peuvent ne pas avoir cet espace disponible.
État : l’état de tous les disques impliqués dans un volume à bandes doit être en ligne lorsque vous créez le
volume à bandes.
Type d’appareil : vous pouvez installer le striping sur n’importe quel disque dynamique, même s’il existe
des architectures de lecteur mixtes sur le système. Par exemple, les lecteurs IDE, Enhanced IDE (EIDE) et SCSI
peuvent tous être utilisés dans un volume à bandes.
Comment mettre à niveau vers des disques dynamiques

Si les disques qui doivent être impliqués dans le volume à bandes sont déjà des disques dynamiques, voir la
section « Conversion en volumes à bandes » de cet article.
NOTE
Vous devez être connecté en tant qu’administrateur ou membre du groupe Administrateurs pour effectuer cette
procédure. Si votre ordinateur est connecté à un réseau, certains paramètres de stratégie réseau peuvent vous empêcher
d’exécuter cette procédure.
Pour mettre à niveau un disque de base vers un disque dynamique :

1. Avant de mettre à niveau les disques, quittez les programmes en cours d’exécution sur ces disques.
2. Cliquez avec le bouton droit sur le volet gris Description du disque situé à gauche des volets de volume
codés en couleur, puis cliquez sur Mettre à niveau vers le disque dynamique.
3. Si le deuxième disque n’est pas un disque dynamique, suivez les étapes 1 et 2 pour le mettre à niveau vers un
disque dynamique.
Conversion en volumes à bandes

Dans ce scénario, il existe deux disques sur l’ordinateur, Disque 0 et Disque 1. Les deux disques sont des disques
dynamiques et ont au moins 1 gigaoctet (Go) d’espace libre non alloué sur chaque disque pour un volume total
de 2 Go.
1. Dans le volet inférieur droit de l’outil Gestion des disques, cliquez avec le bouton droit sur l’espace de
volume libre et non alloué sur l’un ou l’autre disque, puis cliquez sur Créer un volume.
2. Après le démarrage de l’Assistant Création de volume, cliquez sur Suivant.
3. Under Volume Type , click Striped Volume > Next .
4. Dans le volet gauche sous Sélectionner deux disques ou plus, une liste s’affiche qui contient tous les
disques qui ont suffisamment d’espace libre et non alloué pour participer au volume à bandes.
Dans le volet droit sous Sélectionné, le disque sur qui vous avez cliqué avec le bouton droit à l’étape 1
s’affiche.
5. Dans le volet gauche sous Tous les disques dynamiques disponibles, cliquez sur le disque, puis cliquez
sur Ajouter.
Tous les disques affichés dans le volet droit sont étiquetés « Sélectionné ». Affichez le bas de la boîte
de dialogue Sélectionner un disque sous l’étiquette Taille. La zone Pour tous les disques
sélectionnés affiche la taille maximale du volume à bandes que vous pouvez effectuer.
NOTE
Le volume sur chaque disque a la même taille dans le volume à bandes terminé. Par exemple, si vous avez 100 Mo
sur le premier disque, vous avez 100 Mo sur le deuxième disque. Par conséquent, la taille totale de vos volumes
combinés est le double de la plus petite des volumes sur les deux disques.
Vous pouvez réduire la taille du volume en modifiant la valeur dans la zone Taille du disque. N’oubliez
pas que sur un système qui possède deux disques, la taille totale du volume à bandes est deux fois plus
importante que celle que vous entrez. La zone Taille totale du volume sous le volet droit affiche la taille
réelle du volume à bandes.
6. Cliquez sur Suivant pour accéder à la page Affecter le chemin d’accès à la lettre de lecteur de l’Assistant.
7. Pour l’instant, vous pouvez affecter une lettre de lecteur à votre volume à bandes (vous pouvez
également le faire à tout autre moment). Pour ce faire, cliquez sur Affecter une lettre de lecteur, puis
entrez une lettre de lecteur disponible.
Vous pouvez également cliquer sur Ne pas affecter de lettre de lecteur ou de chemin d’accès.
Vous pouvez également cliquer sur Monter ce volume sur un dossier vide qui prend en charge
les chemins d’accès des disques. Toutefois, cette sélection n’entre pas dans le cadre de cet article.
8. Après avoir entré une lettre de lecteur pour votre volume à bandes, cliquez sur Suivant .
9. Cliquez sur Formater cette par tition avec les paramètres suivants, puis suivez les étapes
suivantes :
a. Entrez le type de système de fichiers.
Notez que FAT32 ou NTFS est acceptable.
b. Laissez la sélection par défaut dans la zone Taille de l’unité d’allocation.
c. Dans la zone Étiquette de volume, vous pouvez conserver l’étiquette Nouveau volume par
défaut ou vous pouvez taper votre propre étiquette.
d. Pour l’instant, vous pouvez cliquer pour sélectionner les cases à cocher Format rapide et
Compression des fichiers et des dossiers. Vous pouvez également différer ces deux tâches si vous
le souhaitez.
10. Cliquez sur Suivant, vérifiez votre sélection dans la fenêtre Résumé, puis cliquez sur Terminer.
Les volumes à bandes sont affichés sur les deux disques de votre système. Ils ont le même code de couleur, la
même lettre de lecteur (si vous avez mappé le lecteur au cours de la procédure) et ils ont la même taille.

Ne mélangez pas le matériel RAID 0 avec le logiciel RAID 0.
Un volume à bandes ne peut pas contenir la partition système ou de démarrage d’un système Windows
Server 2003.
Vous ne pouvez pas étendre ou miroirr des volumes à bandes.
Il n’existe aucune tolérance de panne sur un volume à bandes. Cela signifie que si l’un des disques est
endommagé ou ne fonctionne plus correctement, tout le volume est perdu.
Comment mettre en miroir le système et la partition
de démarrage (RAID1)
Cet article explique comment mettre en miroir le système et la partition de démarrage (RAID1).
Résumé
Cet article pas à pas décrit comment mettre en miroir le système et la partition de démarrage dans Windows
Server 2003. Ce scénario repose sur l’hypothèse que le système et les fichiers de démarrage se trouvent sur le
disque 0 et que le disque 1 est un espace non alloué.
Au moins deux disques durs ; L’IDE, l’interface SCSI (Small Computer System Interface) ou l’architecture
mixte sont autorisés.
Le deuxième lecteur doit avoir au moins la taille du volume sur lequel résident le démarrage du système
d’exploitation et les fichiers système pour permettre la mise en miroir.
Le Windows Server 2003 et les fichiers de démarrage doivent résider sur le même volume pour être en
miroir.
NOTE
Le fichier de vidage mémoire est écrit uniquement sur le disque dur de démarrage. Windows Server 2003 peut continuer
à fonctionner avec une configuration de disque système en miroir, même si l’un des disques dans le miroir est supprimé.
Toutefois, le fichier de vidage mémoire ne peut pas être écrit sur le disque système restant dans le miroir. Vous devez
planifier un redémarrage du système pour que le fichier de vidage de mémoire soit écrit sur le disque dur restant.
Configurer le système de gestion des disques

1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Gestion de l’ordinateur pour
ouvrir la console gestion de l’ordinateur.
2. Développez Stockage nœud.
3. Cliquez sur Gestion des disques.
4. Dans le menu Affichage, pointez sur Haut, puis cliquez sur Liste des disques.
Dans le volet droit, les attributs de chaque disque du système sont affichés.
5. Dans le menu Affichage, pointez sur Bas, puis cliquez sur Affichage graphique.
En bas du volet droit, une vue graphique codée en couleur des disques du système s’affiche :
Panneau de description du disque : le panneau de description du disque (gris) se trouve à gauche de la
description du volume, qui est en couleur. La description du disque contient des informations sur le
numéro de disque de chaque disque, si sa configuration est de base ou dynamique, sa taille et son état
en ligne ou hors connexion.
Panneau description du volume : les panneaux description du volume sont codés en couleur. Elles
tiennent des informations sur chaque volume, telles que la lettre de lecteur (si elle est affectée), si le
volume est alloué ou non alloué, la partition ou la taille du volume, et l’état d’état du volume.
Mise à niveau vers des disques dynamiques
Les systèmes RAID nécessitent des disques dynamiques dans Windows Server 2003. Tous les disques que vous
êtes en cours de mise à niveau doivent contenir au moins 1 mégaoctet (Mo) d’espace libre à la fin du disque
pour que la mise à niveau réussisse. La gestion des disques réserve automatiquement cet espace libre
lorsqu’elle crée des partitions ou des volumes sur un disque, mais les disques avec des partitions ou des
volumes créés par d’autres systèmes d’exploitation peuvent ne pas avoir cet espace disponible.
NOTE
procédure. Si votre ordinateur est connecté à un réseau, certains paramètres de stratégie réseau peuvent vous empêcher
d’exécuter cette procédure.
Pour mettre à niveau un disque de base vers un disque dynamique, suivez les étapes suivantes :
1. Avant de mettre à niveau les disques, quittez les programmes en cours d’exécution sur ces disques.
2. Cliquez avec le bouton droit sur le panneau de description du disque gris, puis cliquez sur Mettre à niveau
vers le disque dynamique.
3. Si le deuxième disque n’est pas un disque dynamique, suivez ces étapes pour le mettre à niveau vers un
disque dynamique.
Mise en miroir du démarrage et du volume système
Dans ce scénario, le disque 1 est le disque sur lequel l’image du disque 0 sera mise en miroir.
NOTE
Les partitions sont appelées volumes lorsque les disques sont dynamiques.
1. Le disque 1 doit être un espace non alloué avant de poursuivre la mise en miroir.
2. Cliquez avec le bouton droit sur le disque 0 (qui contient les fichiers système et de démarrage), puis
cliquez sur Ajouter un miroir.
3. Une boîte de dialogue s’ouvre dans laquelle tous les disques de votre système disponibles pour la mise
en miroir sont affichés. Sélectionnez le disque de votre choix (dans cet exemple, il s’agit du disque 1), puis
cliquez sur Ajouter un miroir.
Le disque 0 et le disque 1 auront désormais le même code de couleur, la même lettre de lecteur et la note
d’état « Régénération » s’affichera sur les volumes pendant la copie des informations du premier disque
vers le deuxième disque. Le système dimensionnait automatiquement le volume du nouveau miroir à la
même taille que le démarrage d’origine et le volume système.
4. Si vous souhaitez maintenant démarrer à partir du nouveau disque en miroir, vous devez modifier le
chemin d’accès ARC Boot.ini qui pointe l’ordinateur vers la partition dans laquelle se trouvent les fichiers
système.
Après avoir mis à niveau un disque de base vers un disque dynamique, toutes les partitions existantes sur le
disque de base deviennent des volumes simples (dynamiques). Vous ne pouvez pas revenir aux volumes
dynamiques en partitions.
Un disque dynamique ne peut pas contenir de partitions ou de lecteurs logiques, ni être accessible par MS-DOS
ou par des systèmes d’exploitation Windows autres que Windows Server 2003.
IMPORTANT
N’utilisez pas une solution RAID matérielle et une solution RAID logicielle sur le même disque.
Automatisation de l’outil Nettoyage de disque dans
Windows
Cet article explique comment exécuter l’outil nettoyage de disque (cleanmgr.exe) à l’aide de commutateurs de
ligne de commande. cleanmgr.exe est conçu pour effacer les fichiers inutiles du disque dur de votre ordinateur.
Vous pouvez configurer des cleanmgr.exe avec des commutateurs de ligne de commande pour nettoyer les
fichiers de votre besoin. Vous pouvez ensuite planifier l’exécuter à un moment spécifique à l’aide de l’outil Tâches
programmées.
S’applique à : Windows Server 2008 R2 Service Pack 1, Windows 7 Service Pack 1
Commutateurs de ligne de commande

Vous pouvez démarrer l’outil Nettoyage de disque en exécutant cleanmgr.exe ou en sélectionnant Démarrer
programmes accessoires > > > Outils > système Nettoyage de disque . Le nettoyage de disque prend en
charge les commutateurs de ligne de commande suivants :
: - Ce commutateur sélectionne le lecteur que vous souhaitez nettoyer. Le
/d <driveletter> /d
commutateur n’est pas utilisé avec /sagerun:n .
/sageset:n - Ce commutateur affiche la boîte de dialogue Nettoyage Paramètres disque et crée une clé
de Registre pour stocker les paramètres que vous sélectionnez. La valeur n est stockée dans le Registre et
vous permet de spécifier différentes tâches pour le nettoyage de disque à exécuter. La valeur n peut être
n’importe quelle valeur d’unger entre 0 et 65535. Pour obtenir toutes les options disponibles lorsque
vous utilisez le commutateur, vous devrez peut-être spécifier la lettre de lecteur qui contient la /sageset
Windows’installation.
Pour plus d’informations, voir les informations de clé de Registre.
/sagerun:n - Ce commutateur exécute les tâches spécifiées qui sont affectées à la valeur n à l’aide du
/sageset commutateur. Tous les lecteurs de l’ordinateur sont éumés et le profil sélectionné est exécuté
sur chaque lecteur.
Par exemple, dans Tâches programmées, vous pouvez exécuter la commande suivante après l’avoir
cleanmgr /sageset:11 exécuté :
cleanmgr /sagerun:11 .
Cette commande exécute le nettoyage du disque avec les options qui ont été spécifiées avec la
cleanmgr /sageset:11 commande.
Les options disponibles pour le nettoyage de disque que vous pouvez spécifier à l’aide des commutateurs et
/sageset /sagerun des commutateurs sont les suivantes :
Fichiers d’installation temporaires : ces fichiers ne doivent plus être nécessaires. Ils ont été créés à l’origine
par un programme d’installation qui n’est plus en cours d’exécution.
Fichiers de programmes téléchargés : ils sont ActiveX contrôles et Java qui sont téléchargés
automatiquement à partir d’Internet lorsque vous affichez certaines pages. Ils sont temporairement stockés
dans le dossier Fichiers programmes téléchargés sur votre disque dur. Cette option inclut un bouton
Afficher les fichiers qui vous permet d’afficher les fichiers qui seraient supprimés.
Fichiers Internet temporaires : le dossier Fichiers Internet temporaires contient des pages Web stockées sur
votre disque dur pour un affichage rapide. Vos paramètres personnalisés pour les pages Web restent intacts.
Cette option inclut un bouton Afficher les fichiers qui affiche les fichiers à supprimer.
Anciens fichiers Chkdsk : lorsque Chkdsk vérifie la recherche d’erreurs sur votre disque, il est possible qu’il
enregistre les fragments de fichiers perdus en tant que fichiers dans le dossier racine de votre disque. Ces
fichiers sont inutiles et peuvent être supprimés.
Corbeille : la Corbeille contient les fichiers que vous avez supprimés de votre ordinateur. Ces fichiers ne sont
pas supprimés définitivement tant que vous n’avez pas vide la Corbeille. Cette option inclut un bouton
Afficher les fichiers qui ouvre la Corbeille.
Fichiers temporaires : les programmes stockent parfois des informations temporaires dans un dossier Temp.
Avant de quitter un programme, il supprime généralement ces informations. Vous pouvez supprimer en
toute sécurité les fichiers temporaires qui n’ont pas été modifiés depuis une semaine.
Fichiers hors connexion temporaires : les fichiers hors connexion temporaires sont des copies locales des
fichiers réseau récemment utilisés qui sont automatiquement mises en cache pour vous. Vous pouvez les
utiliser lorsque vous êtes déconnecté du réseau. Un bouton Afficher les fichiers ouvre le dossier Fichiers
hors connexion.
Fichiers hors connexion : les fichiers temporaires sont des copies locales de fichiers réseau que vous avez
spécifiquement rendues disponibles hors connexion. Vous pouvez les utiliser lorsque vous êtes déconnecté
du réseau. Un bouton Afficher les fichiers ouvre le dossier Fichiers hors connexion.
Compresser les anciens fichiers : Windows compresser les fichiers que vous n’avez pas utilisés depuis un
certain temps. La compression des fichiers permet d’économiser de l’espace disque tout en vous permettant
de les utiliser. Aucun fichier n’est supprimé. Étant donné que les fichiers sont compressés à des taux
différents, la quantité d’espace disque que vous gagnerez est approximative. Vous pouvez utiliser le bouton
Options pour spécifier le nombre de jours d’attente avant la compression d’un fichier inutilisé.
Fichiers catalogue pour l’indexeur de contenu : le service d’indexation accélère et améliore les recherches de
fichiers en conservant un index des fichiers sur le disque. Ces fichiers sont laissés à partir d’une opération
d’indexation précédente et peuvent être supprimés en toute sécurité.
Si vous sélectionnez le lecteur qui contient l Windows’installation, toutes ces options sont disponibles sous
l’onglet Nettoyage du disque. Si vous sélectionnez un autre lecteur, seuls les fichiers Corbeille et Catalogue
pour les options d’index de contenu sont disponibles sous l’onglet Nettoyage du disque.
L’onglet Options supplémentaires contient des options pour le nettoyage Windows composants ou
programmes installés. Vous pouvez utiliser l’option Windows composants pour créer de l’espace libre en
supprimant les composants Windows facultatifs que vous n’utilisez pas. La sélection du bouton Nettoyer pour
cette option démarre l’Assistant Windows composants. Vous pouvez utiliser l’option Programmes installés
pour libérer davantage d’espace disque en supprimant les programmes que vous n’utilisez pas. La sélection de
ce bouton Nettoyer démarre l’option Modifier ou supprimer des programmes dans l’outil Ajouter/Supprimer
des programmes.
Informations sur la clé de Registre

Après l'cleanmgr.exe avec le commutateur, certaines des sous-clés de Registre sous la clé de Registre suivante
/sageset:n sont modifiées :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\
Chacune des sous-clés de Registre modifiées peut contenir une valeur de Registre de type REG_DWORD
StateFlags NNNN**, où NNNN est le numéro n spécifié dans le commutateur. Par exemple, après avoir exécuté
la commande, une valeur cleanmgr /sageset:9 de Registre Stateflags0009 est ajoutée. La valeur de Registre
peut être définie comme l’une des valeurs suivantes.
Si la zone d’option n’est pas sélectionnée, la valeur est 00000000 .
Si la zone d’option est sélectionnée, la valeur est 00000002 .
NOTE
Sous la clé de Registre VolumeCaches, la sous-clé de Registre Fichiers de pages hors connexion ne comprend pas les
valeurs stateflags. Il n’est pas possible de supprimer ces fichiers.
Pour plus d’informations, voir Creating a Disk Cleanup Handler.
Pour obtenir une version Microsoft Windows XP de cet article, voir Comment automatiserl’outil de nettoyage de
disque dans Windows XP .
NOTE
L’option Nettoyage du disque sur les propriétés générales et lescleanmgr.exedu lecteur n’est pas présente dans Windows
Server 2008 R2 par défaut. Pour plus d’informations sur la façon d’avoir un bouton nettoyage de disque ou une
cleanmgr.exe sur Windows Server 2008 R2, voir l’option Nettoyage du disque sur les propriétés générales du lecteur
etcleanmgr.exen’est pas présent dans Windows Server 2008 R2 pardéfaut.
Comment configurer la mise en miroir de partition
de démarrage dynamique sur des disques de table
de partition GUID (GPT) dans Windows Server 2008
Cet article contient des étapes et des exemples de la façon de configurer la mise en miroir de partition de
démarrage dynamique sur des disques de table de partition GUID (GPT) dans Windows Server 2008.
Introduction
Cet article pas à pas décrit comment configurer la mise en miroir de partition de démarrage dynamique sur des
disques de table de partition GUID (GPT) dans Windows Server 2008. Contrairement aux miroirs
d’enregistrement de démarrage maître (MBR) sur les versions 32 bits de Windows, il existe d’autres étapes pour
créer et démarrer des volumes de démarrage en miroir sur les disques GPT. Cet article explique également
comment récupérer après une défaillance du disque principal.
Vous devez avoir les utilitaires Diskpart.exe et Bcdedit.exe intégrés pour créer des volumes de démarrage en
miroir sur les disques GPT dans Windows Server 2008. Vous pouvez utiliser la console Gestion des disques pour
effectuer certaines de ces tâches. Toutefois, pour d’autres tâches, vous devez utiliser l’utilitaire Diskpart.exe
intégré.
Pour des raisons de cohérence et de simplicité d’utilisation, cet article utilise l’utilitaire Diskpart.exe dans les
procédures de cet article. Pour obtenir de l’aide sur Diskpart.exe commandes, démarrez Diskmgmt.msc, puis
ouvrez les rubriques d’aide du menu d’aide. Les étapes décrites dans les procédures de cet article utilisent des
exemples réels.
Les procédures de cet article indiquent les résultats attendus que chaque commande renvoie. Dans ces
procédures, le disque 0 est le système principal et le lecteur de démarrage, et le disque 1 est le lecteur
secondaire.
NOTE
Pour Windows Server 2012 documentation, consultez le billet de blog TechNet suivant :
Conseil du jour : configuration de la mise en miroir de disques pour Windows Server 2012
Préparer le lecteur secondaire pour la mise en miroir
Avant de configurer la mise en miroir de volume de démarrage, nous vous recommandons d’avoir un autre
disque GPT sur l’ordinateur qui contient une partition EFI (Extensible Firmware Interface). La partition EFI
contient les fichiers système utilisés pour démarrer le système d’exploitation. Le disque doit avoir une partition
EFI pour démarrer. Si le lecteur système principal (disque 0) échoue, vous pouvez utiliser la partition EFI sur le
lecteur secondaire (disque 1) pour démarrer le système d’exploitation. Cette section décrit comment créer et
préparer de nouvelles partitions EFI et Microsoft Reserved (MSR) sur le lecteur secondaire. Vous pouvez utiliser
uniquement l’utilitaire Diskpart.exe pour créer les partitions EFI et MSR requises. Vous ne pouvez pas utiliser la
console Gestion des disques pour créer ou mettre en miroir des partitions EFI ou MSR.
Avant de commencer la procédure suivante, assurez-vous que vous disposez d’un autre disque de base dont
l’espace libre non alloué est supérieur ou égal à la capacité du système et des partitions de démarrage du disque
principal. Si vous avez déjà converti le lecteur de rechange en disque dynamique, revenir à un lecteur de base
avant de suivre ces étapes.
1. À l’invite de commandes, exécutez Diskpart.exe l’utilitaire.
NOTE
Cette commande démarre la console diskpart. Une fois la console initialisée, la>DISKPART s’affiche. La console
diskpart est maintenant prête pour les commandes d’entrée.
2. Sélectionnez le disque qui doit être le lecteur secondaire, puis convertissez le lecteur en GPT. Dans cet
exemple, le disque 1 est utilisé pour le lecteur miroir (secondaire).
NOTE
Le disque que vous sélectionnez ne doit contenir aucune partition de données. En outre, le disque doit être un
disque de base brut dont l’espace non alloué est supérieur ou égal à la capacité du disque système principal.
Voici les commandes que vous tapez à l’invite de commandes. Les commandes sont en gras et les
commentaires sur la commande ou sur le contenu de l’écran sont formatés en texte simple.

Disk 1 is now the selected disk.
DISKPART> Convert GPT

Diskpart successfully converted the selected disk to GPT format.
Partition ### Type Size Offset

--------------- ---------------- --------- -------
Partition 1 Reserved 128 MB 17 KB
NOTE
Si vous remarquez que plusieurs partitions sont affichées, vous avez sélectionné le lecteur erroné ou vous n’avez
pas commencé avec un lecteur brut. Corrigez cette situation avant de continuer, sinon une perte de données peut
se produire.
3. Sélectionnez la partition 1 sur le disque 1, puis supprimez-la. Vous devez utiliser la commande override
pour supprimer la partition Microsoft Reserved (MSR). Vous allez créer à nouveau une partition MSR
après avoir créé la partition EFI requise.

Partition 1 is now the selected partition.
DISKPART> Delete partition override

Diskpart successfully deleted the selected partition.
4. Sélectionnez le disque 0, puis listez les partitions qui sont sur le disque 0. Avec la sortie de la commande
de liste, créez de nouvelles partitions EFI et MSR sur le disque 1 qui ont les mêmes tailles que les
partitions EFI et MSR sur le disque 0.


----------------- ---------------- --------- -------
Partition 1 System 200 MB 1024 KB <- EFI PARTITION
Partition 2 Reserved 128 MB 201 MB <- MSR PARTITION
Partition 3 Primary 50 GB 329 MB


Diskpart succeeded in creating the specified partition.

Diskpart succeeded in creating the specified partition

------------- ---------------- ------- -------
Partition 1 System 200 MB 1024 KB
*Partition 2 Reserved 128 MB 201 MB
Convertir les lecteurs principaux et secondaires en disques dynamiques

Pour pouvoir créer un miroir, le lecteur principal (source) (disque 0) et le lecteur secondaire (de destination)
(disque 1) doivent être convertis en disques dynamiques. Après avoir converti les deux disques en disques
dynamiques, vous pouvez créer le miroir. Vous pouvez utiliser la console gestion des disques ou l’utilitaire
Diskpart.exe pour convertir le lecteur principal et le lecteur secondaire en disques dynamiques.
Lorsque vous utilisez l’utilitaire Diskpart.exe, sélectionnez le lecteur à convertir en disque dynamique, puis
convertissez-le en disque dynamique. Vous devez suivre cette étape sur les lecteurs GPT secondaires et
principaux. Pour convertir les lecteurs principal et secondaire en disques dynamiques, suivez les étapes
suivantes :

Disk 1 is now the selected disk

Diskpart successfully converted the selected disk to Dynamic format.

Disk 0 is now the selected disk

DiskPart successfully converted the selected disk to dynamic format.
DISKPART> Exit
Leaving Diskpart...
Établir un miroir à partir du volume de démarrage vers le lecteur secondaire

Après avoir converti le lecteur principal (disque 0) et le lecteur secondaire (disque 1) en disques dynamiques,
vous pouvez établir un miroir du volume de démarrage vers le lecteur secondaire. Pour ce faire, vous pouvez
utiliser la console de gestion des disques ou l’utilitaire Diskpart.exe disque. Pour ce faire, utilisez l’utilitaire
Diskpart.exe, suivez ces étapes.
1. À l’invite> DISKPART, sélectionnez le volume de démarrage (C:), puis reflètent le volume sur le lecteur
secondaire (disque 1).
DISKPART> Select volum

Volume 1 is the selected volume.

Diskpart succeeded in adding a mirror to the volume.
2. Attendez la fin de la synchronisation du volume, puis quittez Diskpart.exe. Vous pouvez vérifier la
progression de la synchronisation dans la console Diskmgmt.msc.
Formater la partition EFI
Vous devez maintenant copier le magasin BCD et le contenu de la partition EFI du lecteur principal (disque 0)
vers le lecteur secondaire (disque 1).
NOTE
Vous devez suivre ces étapes lorsque le magasin BCD est modifié sur l’un ou l’autre lecteur.
Utilisez lDiskpart.exe pour sélectionner la partition EFI sur le lecteur secondaire, puis affectez une lettre à la
partition EFI afin qu’elle puisse être mise en forme. Dans l’exemple suivant, la lettre de lecteur « S » est affectée à
la partition EFI sur le lecteur secondaire. Vous pouvez utiliser n’importe quelle lettre de lecteur disponible pour
cette étape.


DISKPART> Assign letter=S

DiskPart successfully assigned the drive letter or mount point.
Utilisez Diskpart pour mettre en forme la partition « S » afin d’utiliser le système de fichiers FAT32. Le système
ne peut pas démarrer à partir d’une partition EFI, sauf s’il est formaté pour utiliser le système de fichiers FAT32.
Pour cela, tapez la commande suivante et appuyez sur Entrée :
DISKPART> format fs=FAT32 quick
Sélectionnez la partition EFI sur le lecteur principal (disque 0), puis affectez une lettre de lecteur à cette partition
EFI. Dans cet exemple, la lettre de lecteur « P » est affectée à la partition EFI principale sur le disque 0. Vous
pouvez utiliser n’importe quelle lettre de lecteur disponible pour cette étape.


DISKPART> Assign letter=P

DiskPart successfully assigned the drive letter or mount point.
Quittez Diskpart.
Utiliser Bcdedit.exe pour configurer les entrées de démarrage pour le disque en miroir
Utilisez la BCDedit commande pour afficher les entrées de démarrage Windows jour. Lors de l’opération «
Ajouter un disque » pour créer le miroir, le service de disque en volume (VDS) a créé une entrée secondaire dans
la configuration de démarrage Windows Server 2008, également appelée magasin BCD, pour le chargeur de
démarrage Windows sur le disque 1. Pour afficher les entrées de démarrage Windows jour, suivez les étapes
suivantes :
1. Ouvrez une invite de commandes.
2. À l’invite de commandes, P: tapez, puis appuyez sur Entrée pour modifier le lecteur P.
3. À l’invite de commandes, cd EFI\Microsoft\Boot tapez, puis appuyez sur Entrée pour accéder au dossier
De démarrage.
4. À l’invite de commandes, bcdedit /enum tapez, puis appuyez sur Entrée. Ensuite, vous voyez une sortie
qui ressemble à ce qui suit :
Windows Gestionnaire de démarrage

--------------------
identificateur {bootmgr}
device partition=P:
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
hériter de {globalsettings}
par défaut {current}
displayorder {current}
{1ba28ce6-d91e-11dc-bc7e-e72bb3afd58e}
toolsdisplayorder {memdiag}
timeout 30
Windows Chargeur de démarrage
-------------------
identificateur {current}
device partition=C:
path \Windows\system32\winload.efi
description Microsoft Windows Server 2008
locale en-US
hériter de {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {b158d5f9-d91f-11dc-bc7e-e72bb3afd58e}
nx OptOut
Windows Chargeur de démarrage
-------------------
identificateur {1ba28ce6-d91e-11dc-bc7e-e72bb3afd58e}
device partition=C:
path \Windows\system32\winload.efi
description Microsoft Windows Server 2008 - plex secondaire
locale en-US
hériter de {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {b158d5f9-d91f-11dc-bc7e-e72bb3afd58e}
nx OptOut
Le chargeur de démarrage Windows avec la description « Microsoft Windows Server 2008 - plex
secondaire » a été créé par VDS lors de l’opération « ajouter un disque ». La Windows chargeur de
démarrage « Partition=C: » représente le volume C qui est en miroir, et cette entrée fait référence à la
copie du fichier Winload.efi sur le disque 1 qui démarrera Windows Server 2008 à partir du disque
1.Ensuite, créez une copie du gestionnaire de démarrage Windows actuel afin qu’il puisse être utilisé à
partir du menu de démarrage du microprogramme EFI pour faire démarrer Windows Server 2008 à
partir du disque 0 ou du disque 1 . La commande bcdedit /copy copie l’entrée actuelle du Gestionnaire de
démarrage Windows vers une nouvelle entrée du Gestionnaire de démarrage Windows dont la
description est « cloné Windows Boot Manager ». La commande bcdedit /set utilise le GUID du nouveau
gestionnaire de démarrage Windows et la commande définit la partition de l’appareil pour référencer la
copie du fichier Bootmgr.efi qui se trouve sur la partition « S » sur le disque 1. Voici un exemple de GUID :
FD221F0A-5B5D-484A-99FE-DEB4B3F90C32
L’exemple suivant montre comment utiliser les commandes bcdedit.
1. À l’invite de commandes, bcdedit /copy {bootmgr} /d "Windows Boot Manager Cloned" tapez, puis appuyez
sur Entrée. Une sortie ressemblant à ce qui suit s’affiche :
L’entrée a été correctement copiée dans { GUID }.
2. À l’invite de commandes, tapez bcdedit /set { GUID } device partition=s:

, puis appuyez sur Entrée. Dans cette commande, remplacez le GUID par le GUID dans la sortie de la
commande précédente. Une sortie ressemblant à ce qui suit s’affiche :
3. À l’invite de commandes, bcdedit /enum all tapez, puis appuyez sur Entrée pour vérifier les
modifications qui ont été apportées. Ensuite, vous voyez une sortie qui ressemble à ce qui suit :
Gestionnaire de démarrage du microprogramme

---------------------
identificateur {fwbootmgr}
displayorder {bootmgr}
{1ba28cdf-d91e-11dc-bc7e-e72bb3afd58e}
{1ba28cde-d91e-11dc-bc7e-e72bb3afd58e}
timeout 2
--------------------
identificateur {1ba28ce8-d91e-11dc-bc7e-e72bb3afd58e}
device partition=S:
description Windows Boot Manager Cloned
locale en-US
timeout 30
--------------------
identificateur {bootmgr}
device partition=P:
description Windows Boot Manager
locale en-US
timeout 30
NOTE
Le dernier GUID de l’ordre d’affichage du Gestionnaire de démarrage du microprogramme est identique à celui du
gestionnaire de démarrage secondaire Windows sur la partition « S ». Cela signifie que le nouveau gestionnaire de
démarrage Windows dont la description est « Windows Boot Manager Cloned » est synchronisé dans le NVRAM
utilisé par le microprogramme lorsque le microprogramme EFI affiche le menu de démarrage du microprogramme.
Il existe maintenant deux entrées NVRAM pour Windows Boot Manager, l’une sur la partition « P » et l’autre sur la
partition « S ». Le microprogramme EFI répertorie ces entrées dans le menu de démarrage EFI.
Copiez la partition EFI et le magasin BCD sur le deuxième lecteur

Pour exporter la partition EFI et le magasin BCD vers le deuxième lecteur, suivez les étapes suivantes :
1. Exportez le magasin BCD vers la partition EFI sur le disque 0. Cela vous permet de copier le magasin BCD
du disque 0 vers le disque 1. Pour cela, procédez comme suit :
a. Ouvrez une invite de commandes.
b. À l’invite de commandes, tapez, puis appuyez sur Entrée pour exporter le magasin BCD vers un
fichier nommé bcdedit /export P:\EFI\Microsoft\Boot\BCD2 « BCD2 ». Une sortie ressemblant à ce
qui suit s’affiche :
2. Utilisez la commande pour copier les fichiers système de « P » (la partition EFI sur le lecteur principal)
vers « S » (la partition EFI sur le Robocopy lecteur secondaire). Vous devez le faire pour vous assurer que
le lecteur secondaire peut démarrer le système en cas de panne du disque 0. Veillez à utiliser les lettres de
lecteur correctes si vous avez utilisé différentes lettres pour vos partitions EFI. Pour ce faire, tapez
robocopy p:\ s:\ /e /r:0 à l’invite de commandes, puis appuyez sur Entrée.
3. Renommez le magasin BCD sur le disque 1 afin qu’il corresponde au nom du magasin sur le disque 0.
Pour ce faire, tapez renommez S:\EFI\Microsoft\Boot\BCD2 BCD À l’invite de commandes, puis appuyez
sur Entrée.
4. Supprimez le magasin BCD en double sur le disque 0. Pour ce faire, tapez del P:\EFI\Microsoft\Boot\BCD2
à l’invite de commandes, puis appuyez sur Entrée.
5. Supprimez les lettres de lecteur affectées aux deux partitions EFI. Cette étape est facultative, car les lettres
de lecteur ne sont pas ré-affectées après un redémarrage du système. Pour supprimer les lettres de
lecteur affectées aux deux partitions EFI, suivez les étapes suivantes :
a. À l’invite de commandes, diskpart.exe tapez, puis appuyez sur Entrée.
b. À DISKPART> l’invite, tapez Select volume P .
c. À DISKPART> l’invite, tapez Remove .
Diskpart a correctement supprimé la lettre de lecteur ou le point de montage.
d. Répétez les étapes 5b et 5c pour la partition « S ».
Tester le lecteur secondaire à l’aide des nouvelles entrées de démarrage Windows Server 2008
Après avoir mis à jour la configuration BCD, testez les entrées pour vous assurer que le système peut
commencer à utiliser le lecteur secondaire en cas de panne du disque 0. Pour cela, procédez comme suit :
1. Arrêter, puis redémarrer l’ordinateur.
2. Dans le menu de démarrage, sélectionnez l’entrée de démarrage dans eFI nommée « Windows Boot
Manager Cloned ». Cette option vous permet de redémarrer le gestionnaire de démarrage Windows sur
la partition EFI du lecteur secondaire. Sélectionnez ensuite « Microsoft Windows Server 2008 - plex
secondaire » pour démarrer Windows Server 2008 à partir du lecteur secondaire.
NOTE
Dans un environnement d’interface utilisateur utilisateur, l’entrée plex secondaire dans le Gestionnaire de
démarrage Windows peut s’afficher comme « Microsoft Windows Server 2008 - ????? ?????". Vous pouvez utiliser
la commande bcdedit /set { GUID } description "Description " pour donner à l’entrée plex secondaire un nom
plus significatif. Par exemple, vous pouvez utiliser la commande suivante : bcdedit /set {7e4632e7-0b4d-11dd-
813b-bcbfbfe8b578} description « Microsoft Windows Server 2008 - Secondary Plex »
Après avoir terminé cette étape pour donner à l’entrée plex secondaire un nom plus significatif, veillez à
copier le magasin BCD sur le lecteur secondaire en utilisant les étapes décrites dans la section « Copier la
partition EFI et le magasin BCD sur le deuxième lecteur ».
Rétablir le miroir du lecteur de démarrage principal
En cas de défaillance du lecteur principal (disque 0), vous devez démarrer l’ordinateur sur le lecteur secondaire
(disque 1), puis re-créer le miroir pour que le volume de démarrage soit à tolérance de panne. Pour cela,
procédez comme suit.
1. Remplacez le disque dynamique 0 défailli par les instructions fournies par votre fournisseur de matériel.
Assurez-vous que le disque ne dispose d’aucune information de partition. La commande de nettoyage
diskpart peut être utilisée pour détruire les informations de partition existantes sur le disque.
NOTE
Soyez prudent lorsque vous exécutez la commande clean diskpart, car elle détruit la table de partition sur le
disque sélectionné et rend le contenu du disque inaccessible.
Tout au long de cette section, l’ancien disque principal continuera d’être appelé disque 0 et l’ancien disque
secondaire continuera d’être appelé disque 1. Toutefois, après avoir suivi ces étapes, le disque 1 sera le
nouveau disque principal et le disque 0 le nouveau disque secondaire.
2. Sélectionnez Windows Boot Manager cloné pour démarrer l’ordinateur à l’aide de la partition EFI sur
le lecteur secondaire. Lorsque le Gestionnaire de démarrage s’affiche, sélectionnez Microsoft
Windows Ser ver 2008 - plex secondaire.
3. Importez le magasin BCD situé sur la partition EFI sur le disque 1. Cela définit le magasin BCD sur le
disque 1 comme magasin système actif et permet sa modification. Pour cela, procédez comme suit :
a. Démarrez DiskPart.
b. Exécutez les commandes suivantes pour sélectionner la partition EFI sur le disque 1 et lui affecter
la lettre de lecteur « S ».

DISKPART> assign letter=s
c. Quittez DiskPart.
d. Exécutez la commande bcdedit /import S:\EFI\Microsoft\Boot\BCD /clean pour importer le
magasin à partir de la partition EFI sur le disque 1.
4. Vous devez rompre le miroir rompu. Toutefois, vous devez d’abord déterminer quel est le disque correct
sur lequel exécuter la commande de coupure de disque. Après cela, sélectionnez le volume miroir
(Volume #), puis affichez les détails pour déterminer le disque manquant (m#) dont vous avez besoin
pour rompre le miroir. Pour cela, procédez comme suit :
b. Sélectionnez le volume miroir, généralement le volume C (volume de démarrage) :
DISKPART> select volume c
c. Utilisez la commande de volume de détails ou de liste de disque pour déterminer l’identificateur

du disque manquant, généralement m0 :
DISKPART> detail volume
d. Cassez le miroir en spécifiant l’identificateur du disque manquant que vous avez obtenu à l’étape
5c (par exemple, m0) :
DISKPART> break disk=m0 nokeep
e. Listez les volumes pour vous assurer que le miroir a disparu et que le volume est maintenant
répertorié en tant que volume simple :
f. Supprimez le disque manquant (m0) :
DISKPART> select disk m0

DISKPART> delete disk
g. Quittez DiskPart.
5. Supprimez toutes les entrées obsolètes du magasin BCD pour remettre le système à un état propre
connu. Renommons également les entrées pour refléter précisément l’état actuel du système. Pour cela,
a. Exécutez la commande pour déterminer le GUID de l’entrée dans NVRAM qui a la description «
gestionnaire de démarrage Windows » et qui possède un paramètre de périphérique inconnu ou
bcdedit /enum all /v manquant. Une fois que vous avez déterminé le GUID de cette entrée, utilisez la
partition=s du périphérique de commande : pour pointer l’entrée vers bcdedit /set {GUID} le disque
1.
b. Utilisez la sortie de la commande pour déterminer le GUID de l’entrée « cloné Windows Boot Manager
» bcdedit /enum all /v dans NVRAM. Après avoir déterminez le GUID de cette entrée, utilisez la
commande pour supprimer l’ancienne entrée du disque bcdedit /delete {GUID} 1 de NVRAM.
c. Dans la sortie de la commande, recherchez une entrée nommée « Windows Resume Application »
dont le paramètre de périphérique est inconnu ou bcdedit /enum all /v manquant. Supprimez cette
entrée à l’aide de bcdedit /delete {GUID} la commande.
d. Dans la sortie, recherchez une entrée dont la description est bcdedit /enum all /v « Windows
Resume Application - Secondary Plex ». Utilisez la commande de commande pour renommer l’entrée
afin de refléter qu’il s’agit désormais de l’entrée reprendre Windows Application pour le
bcdedit /set {GUID} description "Windows Resume Application" plex miroir principal.
e. Dans la sortie de la commande, recherchez une entrée dont la description est bcdedit /enum all /v «
Windows Server 2008 » et dont le paramètre de périphérique est inconnu ou manquant. Supprimez
cette entrée à l’aide de la commande bcdedit /delete {GUID}.
f. Dans la sortie, recherchez une entrée dont la description est bcdedit /enum all /v « Windows Server
2008 - Secondary Plex ». Utilisez la commande pour renommer l’entrée afin de refléter qu’il s’agit
désormais de l’entrée du gestionnaire de démarrage pour le
bcdedit /set {GUID} description "Windows Server 2008" plex miroir principal.
g. Recherchez l’entrée BCD qui a la description « Diagnostic Windows mémoire ». Utilisez la commande
bcdedit /set {GUID} device partition=s: pour pointer l’entrée vers le testeur de mémoire situé sur le
disque 1.
h. Exécutez la commande bcdedit /enum all /v pour vérifier les entrées NVRAM et BCD.
i. Redémarrez l'ordinateur. Sélectionnez « Windows Boot Manager » et « Windows Server 2008 » pour
démarrer sur le disque 1.
6. Convertissez le disque nouvellement ajouté au format GPT, puis créez la structure de partition. Pour cela,
b. Convertissez le disque 0 au format GPT :

DISKPART> convert GPT
c. Supprimez la partition sur le disque 0 qui est créé automatiquement :

DISKPART> delete partition override
d. Enregistrez la disposition de partition pour le disque 1 afin de dupliquer la disposition sur le

disque 0 :

e. Dupliquer la disposition du disque 1 sur le disque 0. Pour calculer la taille de la partition MSR pour
cette étape, ajoutez la taille de la partition MSR « Réservé » et de la partition « Réservé dynamique
» répertoriée dans DiskPart pour le disque 1. Par exemple, si la partition MSR est de 127 Mo sur le
disque 1 et si la partition « Réservé dynamique » est de 1 Mo sur le disque 1, créez une partition
MSR de 128 Mo sur le disque 0. En règle générale, la partition EFI doit être de 200 Mo et la
partition MSR doit être de 128 Mo. Pour dupliquer la disposition du disque 1, exécutez les
commandes ci-après :

f. List the partitions that are on the system to verify that disk 0 contains both an EFI and an MSR
partition:
7. Convertissez les deux disques en disques dynamiques s’ils ne sont pas déjà des disques dynamiques :

8. Ajoutez le nouveau disque 0 à un miroir du volume de démarrage :
DISKPART> select volume c

9. Pendant la resynchronisation en miroir, préparez la partition EFI sur le disque 0 :

DISKPART> format fs=fat32 quick
Quitter DiskPart
10. Attendez la fin de la resynchronisation en miroir. Vous pouvez utiliser la gestion des disques pour vérifier
le processus de resynchronisation.
11. Si la partition EFI sur le disque 0 n’est pas déjà affectée à la lettre de lecteur « P », et si la partition EFI sur
le disque 1 n’est pas déjà affectée à la lettre de lecteur « S », affectez les lettres de lecteur appropriées aux
partitions EFI sur le disque 0 et le disque 1 : Démarrez Diskpart.

DISKPART> assign letter=p
DISKPART> assign letter=s
Quittez DiskPart.
12. Clonez l’entrée du gestionnaire de démarrage dans NVRAM pour le disque 1 :
a. Clonez l’entrée du gestionnaire de démarrage à l’aide de
bcdedit /copy {bootmgr} /d "Windows Boot Manager Cloned" la commande. Enregistrez le GUID de la
nouvelle entrée qui est donnée dans la sortie de cette commande.
b. Définissez le paramètre de l’appareil dans l’entrée clonée de façon à pointer vers la partition EFI sur le
disque 0 à l’aide de la bcdedit /set {GUID} device partition=p: commande. Utilisez le GUID de la
sortie de la bcdedit /copy commande.
c. Exécutez la commande bcdedit /enum all /v pour vérifier les modifications.
13. Copiez le contenu de la partition EFI sur le disque 1 vers la partition EFI sur le disque 0 afin de pouvoir
démarrer à partir du disque 0 :
a. Exporter le magasin BCD actif à l’aide de la commande bcdedit /export S:\EFI\Microsoft\Boot\BCD2
b. Copiez la partition EFI du disque 1 vers le disque 0 à l’aide de la commande robocopy s:\ p:\ /e /r:0
c. Renommez le magasin BCD copié sur le disque 0 en BCD à l’aide de la
rename P:\EFI\Microsoft\Boot\BCD2 BCD commande.
d. Supprimer le magasin BCD exporté en double sur le disque 1 à l’aide de la commande
del S:\EFI\Microsoft\Boot\BCD2
14. Procédez comme suit :
a. Supprimez les lettres de lecteur que vous avez affectées dans DiskPart :
DISKPART> select volume p

DISKPART> remove
DISKPART> select volume s
DISKPART> remove
b. Redémarrez l’ordinateur pour vérifier que vous pouvez démarrer à partir du disque 0 ou du disque
1.
NOTE
Par défaut, les entrées de démarrage pointent vers le disque 1. Si vous démarrez à partir du disque 0 et que vous devez
modifier le magasin BCD lorsque vous démarrez sur le disque 0, vous devez d’abord importer le magasin :
1. Démarrez DiskPart.
2. Sélectionnez la partition EFI sur le disque 0 et affectez-lui la lettre de lecteur « P » :

DISKPART> assign letter=p
3. Quittez DiskPart.
4. Exécutez la commande bcdedit /import P:\EFI\Microsoft\Boot\BCD /clean pour importer le magasin à partir
de la partition EFI sur le disque 0.
NOTE
Vous devez toujours démarrer à partir de l’entrée BCD qui correspond à l’entrée NVRAM que vous avez sélectionnée
lorsque vous avez démarré l’ordinateur. Par exemple, si vous avez sélectionné l’entrée NVRAM « Windows Boot Manager »
(disque principal), vous de devez sélectionner l’entrée BCD « Windows Server 2008 » (disque principal) pour que le
système démarre correctement. Si vous avez sélectionné l’entrée NVRAM « Windows Boot Manager Cloned » (disque
secondaire), vous devez sélectionner l’entrée BCD « Microsoft Windows Server 2008 - plex secondaire » (disque
secondaire).
Les lecteurs Intel SSD D3-S4510 et Intel SSD D3-
S4610 série 1,92 To et 3,84 To ne répond pas après 1
700 heures d’inactivité cumulées
Cet article explique que les lecteurs Intel SSD D3-S4510 et Intel SSD D3-S4610 série 1,92 To et 3,84 To ne
répond plus après 1 700 heures d’inactivité cumulées.
Symptômes
Les lecteurs de série Intel SSD D3-S4510 et Intel SSD D3-S4610 dans les capacités de 1,92 To et de 3,84 To
peuvent faire l’expérience d’une condition de « mise en attente de canal » NAND dans la version du
microprogramme XCV10100 qui pourrait entraîner un arrêt du lecteur après environ 1 700 heures d’inactivité
cumulée.
Lorsque ce problème se produit sur un cluster Windows Server espaces de stockage Direct (S2D), le cluster peut
être l’un des symptômes suivants :
Performances de charge de travail lentes.
Les disques virtuels du cluster ont une valeur d’état opérationnel Detached ou No Redundancy.
Le disque physique signale un état de perte de communication ou d’erreur d’opération d’IO.
Le disque physique signale un état d’erreur temporaire si le nœud de cluster est redémarré alors que le
disque est dans un état de non-réponse.
Résolution
The NAND « channel hang » issue is currently addressed in the Maintenance Release 1 (MR1) of Intel firmware
(version XCV10110) as of March 2019. Nous vous recommandons de mettre à jour le microprogramme le plus
récent avant que le lecteur atteigne 1 700 heures d’inactivité cumulées.
Exécutez l’outil Centre de données Intel SSD pour inspecter tous les disques concernés dès que possible et
prendre les mesures correctives recommandées. Pour plus d’informations, voir l’outil Centre de données Intel
SSD.
Le fichier binaire du microprogramme MR1 suivant peut être utilisé avec la méthode de mise à jour automatisée
du microprogramme espaces de stockage Direct, selon le cas pour votre appareil.
Intel Intel® SSD S4510/S4610 - 2,5 » Material
Dell Serial-ATA_Firmware_8VGP8_WN64_DL63_A00.EXE
Problème SSD Lenovo Intel S4510 et S4610 SATA - Lenovo Server, Lenovo ThinkSystem et IBM Server
NOTE
Il n’existe aucun compteur ou tout autre attribut qui signale les heures d’inactivité du disque. Intel recommande d’utiliser
smart 09h (heures d’alimentation du lecteur) comme estimation des heures d’inactivité. Par conséquent, Intel
recommande vivement de mettre à jour le microprogramme dès que possible afin d’éviter les risques de perte de données
irrécible. Le nouveau microprogramme MR1 ne résout pas les erreurs de lecture incorrable qui existaient avant la mise à
niveau du microprogramme. Intel a publié un outil de centre de données (DCT) pour identifier si le problème a été résolu
avec succès en installant le microprogramme MR1. L’outil décrit également les étapes suivantes possibles.
Le script d’outil DCT est disponible sur ce site web Intel.
Il s’agit d’un problème matériel qui peut affecter les produits Microsoft répertoriés dans la section « S’applique à
». Intel a déterminé la cause première du problème et confirmé que le problème est résolu dans la version du
microprogramme basée sur « Maintenance Release 1 ».
Matériel connu affecté
Matériel basé sur les lecteurs de série Intel SSD D3-S4510 et Intel SSD D3-S4610 dans les capacités de 1,92 To
et 3,84 To.
Matériel connu qui n’est pas affecté
Matériel basé sur les lecteurs de série Intel SSD D3-S4510 et Intel SSD D3-S4610 dans les capacités de 240
Go, 480 Go et 960 Go.
Matériel basé sur la famille d’appareils SATA Intel SSD DC S4500 et Intel SSD DC S4600.
Matériel basé sur la famille d’appareils NVMe Intel SSD DC P4500 et Intel SSD DC P4600.
Références
Pour plus d’informations sur la mise à jour automatisée du microprogramme de périphérique de stockage à
l’aide de espaces de stockage Direct (S2D), consultez le site web Docs suivant :
Mises à jour automatisées du microprogramme avec espaces de stockage Direct
Pour une vidéo pas à pas sur la mise à jour automatisée du microprogramme de périphérique de stockage à
l’aide de espaces de stockage Direct (S2D), consultez le site web du canal Windows suivant :
Mettre à jour le microprogramme du lecteur sans temps d’arrêt espaces de stockage Direct
produits.
Exclusion de responsabilité sur les coordonnées externes
Microsoft fournit des informations de contact tierces pour vous aider à trouver des informations
supplémentaires sur cette rubrique. Ces informations de contact peuvent être modifiées sans préavis. Microsoft
ne garantit pas la précision des informations de contact tierces.
Introduire le nouveau mécanisme de journalisation
pour VDS
Cet article présente le nouveau mécanisme de journalisation pour virtual disk service (VDS) dans Windows
Server 2012.
Introduction
Le service VDS de Microsoft Windows Server est un ensemble d’API qui fournit une interface unique pour gérer
les disques. VDS fournit une solution de bout en bout pour gérer le matériel et les disques de stockage et pour
créer des volumes sur les disques. Cet article présente le nouveau mécanisme de journalisation pour VDS dans
Windows Server 2012. La journalisation VDS pour la version précédente de Windows est supprimée.
Pour vous aider à résoudre les problèmes liés aux VDS, capturez le suivi VDS. Pour capturer le suivi VDS, suivez
1. Ouvrez une invite de commandes avec élévation de niveau élevé, puis exécutez les commandes suivantes :
a. md %systemroot%\system32\LogFiles\VDS
Logman start vds -o %systemroot%\system32\LogFiles\VDS\VdsTrace.etl -ets -p {012F855E-CC34-4da0-
b. 895F-07AF2826C03E} 0xffff 0xff
2. Reproduisez le problème.
3. Après la repro, revenir à l’invite de commandes de l’étape 1 et exécutez la commande suivante pour arrêter
la trace VDS :
a. Logman stop vds -etsTrace file Vds
Trace.etl se trouve sous %systemroot%\system32\LogFiles\VDS\ . Utilisez TraceView.exe pour parcourir le fichier ou

envoyer le fichier VdsTrace.etl au support technique Microsoft. Les clients doivent obtenir les fichiers de
symboles du système d’exploitation correspondants auprès des serveurs de symboles publics Microsoft pour
pouvoir lire le fichier VdsTrace.etl. Pour plus d'TraceView.exe, cliquez sur l’article suivant :
TraceView
Le volume ReFS utilisant DPM ne répond plus sur
Windows Server 2016
Cet article permet de résoudre un problème dans lequel le volume DPM ou ReFS ne répond plus Windows
Server 2016.
Symptôme
Vous remarquerez qu’un volume de système de fichiers résilient (ReFS) qui utilise la gestion de la protection des
données (DPM) ne répond plus ou se fige lorsque vous effectuez des sauvegardes, en particulier lorsque DPM
effectue des opérations de clone de bloc importantes.
Cause
DPM utilise des disques durs vhD montés en boucle. Ces disques apparaissent comme des disques normaux sur
le système d’exploitation. Par conséquent, ces disques sont affichés dans Windows Explorer, Diskmgt et d’autres
outils d’interface graphique graphique. Ces outils analysent régulièrement les disques pour s’assurer qu’ils
fonctionnent correctement. Cela entraîne l’envoi d’IO vers le volume ReFS dans la pile de boucsages. Si le
volume ReFS est occupé, ces IO devront attendre. Par conséquent, lorsque ReFS effectue une opération de
longue durée, telle que le purgement ou un appel de clone de bloc important, ces IO devront patienter plus
longtemps. Lorsque ces E/S sont bloqués, l’interface utilisateur de l’Explorateur ou diskmgt n’est pas actualisée.
Par conséquent, il semble que les disques soient suspendus ou démontés.
En outre, le pilote de miniport de montage en boucle (vhdmp) commence à générer des événements
d’avertissement si les E/S ne se terminent pas dans les 30 secondes.
NOTE
Aucune opération d’IO ou de système de fichiers n’échoue au cours de ce processus. Toutes les opérations abouties et
elles viennent de prendre plus de temps. En outre, aucun volume n’est démonté. This issue is only a file-system-operation
latency issue, which causes the UI to be stuck and port drivers to log errors.
Résolution
This issue is resolved in the July 18, 2017 cumulative update. Le correctif contient :
Trois paramètres de Registre tunables
Modification de stratégie qui évite d’effectuer des purges de volume inutiles, ce qui empêche ReFS d’ajouter
une latence élevée aux E/S ReFS en cours.
Comment définir les paramètres tunables
IMPORTANT
Avant de suivre ces étapes, assurez-vous que vous avez lu et implémenté les trois paramètres de Registre comme décrit
dans l’articlede la base de 4016173 . Si ces paramètres ne vous mentent pas correctement, ne désactivez pas ces
paramètres de Registre. Ces paramètres et ceux décrits dans cette section ne se chevauchent pas fonctionnellement, ils
peuvent donc être utilisés ensemble.
Cette mise à jour décrit des paramètres de Registre supplémentaires qui permettent de résoudre les problèmes
de latence décrits dans la section « Symptômes ». Ces paramètres peuvent être utilisés dans n’importe quelle
combinaison.
WARNING
Des problèmes graves peuvent se produire si vous modifiez le Registre de manière incorrecte à l’aide de l’Éditeur du
Registre ou d’une autre méthode. Ces problèmes peuvent nécessiter la réinstallation du système d’exploitation. Microsoft
ne peut pas garantir que ces problèmes peuvent être résolus. Modifiez le Registre à vos risques et périls.
IMPORTANT
Un redémarrage est nécessaire pour que ces modifications de paramètre prennent effet.
Ces paramètres doivent être définies de manière cohérente sur chaque nœud d’un cluster deover.
Paramètres tunables
Option 1
Cette option désactive les broches mises en cache, qui étaient une cause majeure du jeu de travail actif
important.
Nom de la valeur : RefsDisableCachedPins
Définir RefsDisableCachedPins = 1
Option 2
Cette option ajoute une heuristique à la logique de point de contrôle ReFS, ce qui entraîne le point de contrôle
ReFS lorsque la file d’attente de suppression atteint une certaine taille. Les IO sont bloqués sur ReFS, car la
logique de point de contrôle est bloquée lors du traitement d’une file d’attente de suppression importante.
Nom de la valeur : RefsProcessedDeleteQueueEntryCountThreshold
Définir RefsProcessedDeleteQueueEntryCountThreshold = 2048
NOTE
Si refsProcessedDeleteQueueEntryThreshold a des valeurs inférieures, ReFS est plus fréquemment point de contrôle.
Définissez la valeur sur 2048, puis réduisez la valeur à 1024, puis 512.
Option 3
De grandes extensions des appels introduisent une latence dans le système, car d’autres opérations devront
attendre la fin de ces opérations de longue durée. Cette option réduit la taille de l’appel d’extensions en double.
NOTE
DPM définira cette modification de clé de Registre comme valeur par défaut dans ur4, qui sera publiée en août 2017.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Configuration\DiskStorage
Nom de la valeur : DuplicateExtentBatchSizeinMB
Définir DuplicateExtentBatchSizeinMB = 100. (La valeur par défaut est 2000 [2 Go]. Toute valeur de 1 à 4095
est acceptée).
Option 4
Cette option étend la valeur TimeOutValue.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk
Nom de la valeur : TimeOutValue
Définir TimeOutValue (en secondes) = 0x78
NOTE
La valeur par défaut de TimeOutValue est 0x41 (65 décimales). 0x78 se traduit par 120 décimales.
Restaurer la lettre système ou de lecteur de
démarrage dans Windows
Cet article explique comment modifier la lettre système ou de lecteur de démarrage dans Windows.
Résumé
WARNING
N’utilisez pas la procédure décrite dans cet article pour modifier un lecteur sur un ordinateur sur lequel la lettre de lecteur
n’a pas été modifiée. Si vous le faites, vous ne pourrez peut-être pas démarrer votre système d’exploitation. Suivez la
procédure décrite dans cet article uniquement pour récupérer à partir d’une modification de lettre de lecteur, et non pour
modifier un lecteur d’ordinateur existant en autre chose. Back up your Registry keys before you make this change.
Cet article explique comment modifier la lettre système ou de lecteur de démarrage. En règle générale, il n’est
pas recommandé, en particulier si la lettre de lecteur est identique à celle Windows été installée. La seule fois
que vous souhaitez peut-être le faire, c’est lorsque les lettres de lecteur sont modifiées sans intervention de
l’utilisateur. Cela peut se produire lorsque vous cassez un volume miroir ou qu’une modification de
configuration du lecteur se produit. Cette situation doit être rare et vous devez modifier les lettres de lecteur de
façon à ce qu’elle corresponde à l’installation initiale.
Pour modifier ou permuter des lettres de lecteur sur des volumes qui ne peuvent pas être modifiés à l’aide du
logiciel en snap-in Gestion des disques, utilisez les étapes suivantes.
NOTE
Dans ces étapes, le lecteur D fait référence à la (mauvaise) lettre de lecteur affectée à un volume, et le lecteur C fait
référence à la (nouvelle) lettre de lecteur que vous souhaitez modifier ou à affecter au volume.
Cette procédure remplace les lettres de lecteur par les lecteurs C et D. Si vous n’avez pas besoin d’échanger des
lettres de lecteur, nommez-la en une nouvelle lettre de lecteur \DosDevice\letter: value qui n’est pas en cours
d’utilisation.
Modifier la lettre système ou de lecteur de démarrage

IMPORTANT
1. Effectuer une sauvegarde système complète de l’ordinateur et de l’état du système.

2. Connectez-vous en tant qu’administrateur.
3. Démarrez Regedt32.exe.
4. Localisez la clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
5. Sélectionnez MountedDevices .
6. Dans le menu Sécurité, sélectionnez Autorisations.
7. Vérifiez que les administrateurs ont le contrôle total. Modifiez-la une fois que vous avez terminé ces
étapes.
8. Quittez Regedt32.exe, puis démarrez Regedit.exe.
9. Localisez la clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
10. Recherchez la lettre de lecteur que vous souhaitez modifier (nouvelle). Recherchez \DosDevices\C: .
11. Cliquez avec le \DosDevices\C: bouton droit, puis sélectionnez Renommer.
NOTE
Vous devez utiliser Regedit au lieu de Regedt32 pour renommer cette clé de Registre.
12. Renommons-la en lettre de lecteur \DosDevices\Z: inutilisée.

Il libère la lettre de lecteur C.
13. Recherchez la lettre de lecteur que vous souhaitez modifier. Recherchez \DosDevices\D: .
14. Cliquez avec le \DosDevices\D: bouton droit, puis sélectionnez Renommer.
15. Renommons-le à la (nouvelle) lettre de lecteur \DosDevices\C: appropriée.
16. Sélectionnez la valeur \DosDevices\Z: pour , sélectionnez Renommer, puis nommez-la à
\DosDevices\D: nouveau.
17. Quittez Regedit, puis démarrez Regedt32.

18. Revenir au paramètre précédent pour les administrateurs. Il doit probablement être en lecture seule.
Les volumes simples peuvent devenir inaccessibles si
une perte d’alimentation se produit peu de temps
après la création
Cet article permet de résoudre le problème de non-accès à des volumes simples en cas de perte d’alimentation
peu de temps après la création.
Symptômes
Prenons le cas de figure suivant. Dans Windows 7, vous créez un volume simple dans Gestion des disques ou
DiskPart.exe sur un disque non amovible. Si votre système Windows 7 subit une perte d’énergie soudaine dans
les minutes qui sviennent après la création du volume, vous remarquerez peut-être que le volume que vous
avez créé avant la perte d’alimentation n’est pas accessible et qu’une lettre de lecteur n’est pas affectée lorsque
vous remettrez le système en route.
En outre, dans la gestion des disques, le volume peut ne pas avoir d’état (par exemple, « Sain ») ou de type de
système de fichiers répertorié. Si vous essayez de modifier le volume dans Gestion des disques, vous pouvez
L’opération a échoué car la vue de la console Gestion des disques n’est pas à jour. Actualisez l’affichage à
l’aide de la tâche d’actualisation. Si le problème persiste, fermez la console de gestion des disques, puis
redémarrez Gestion des disques ou redémarrez l’ordinateur.
Cause
Ce problème se produit car les informations de configuration du nouveau volume n’ont pas été écrites sur le
disque au moment où la perte de courant s’est produite.
Résolution
Si vous rencontrez le problème décrit dans la section « Symptômes », la réinstallation du volume résoudra le
problème. Suivez ces étapes pour réinstaller le volume.
1. Ouvrez le Gestionnaire de périphériques. Vous pouvez accéder au Gestionnaire de périphériques en
tapant « Gestionnaire de périphériques » ou « devmgmt.msc » dans la zone Démarrer la recherche.
2. Une fois le Gestionnaire de périphériques ouvert, cliquez sur « Stockage volumes » pour développer la
partie Stockage volumes de l’arborescence de l’appareil.
3. Sous Stockage volumes, vous devez remarquer un volume répertorié comme « appareil inconnu ».
Cliquez avec le bouton droit sur cet appareil et choisissez « Désinstaller ». Lorsque vous avez été invité à
confirmer, choisissez OK.
4. Redémarrez le système si vous y êtes invité. Le volume doit être accessible une fois que le système a
terminé le redémarrage. Si vous n’êtes pas invité à redémarrer le système, cliquez avec le bouton droit
dans le Gestionnaire de périphériques et choisissez « Analyser les modifications matérielles ». Une fois
l’analyse terminée et l’installation du volume terminée, vous pouvez accéder au volume.
NOTE
Si la perte d’énergie se produit dans les quelques secondes qui suivent la création du volume, dans de rares cas,
vous pouvez être invité à mettre en forme le volume après avoir suivi les étapes ci-dessus. Si cela se produit, la
configuration du système de fichiers n’a pas été écrite au moment où la perte de courant s’est produite. Vous
devrez peut-être reformater ou recréer le volume.
Si c'est le cas, vous n'avez plus besoin de cette section. Sinon, vous pouvez contacter le support technique.
Limite d’utilisation du service VSS (Volume Shadow
Copy Service)
Cet article fournit une solution de contournement pour la limite d’utilisation du service VSS (Volume Shadow
Copy Service).
les éditions, Windows 7 Service Pack 1
Symptômes
Vous pouvez recevoir un message d’erreur ou remarquer un échec si vous essayez d’effectuer l’une des
opérations suivantes sur les systèmes d’exploitation Windows client ou Windows Server :
Vous activez le service VSS (Volume Shadow Copy Service) sur un volume supérieur à 64 téraoctets (To).
Vous créez des captures instantanées accessibles en création ou des captures instantanées dont la taille est
supérieure à 64 To.
Vous activez VSS pour un dossier partagé sur un volume supérieur à 64 To.
Vous exécutez une opération de sauvegarde sur un volume supérieur à 64 To avec un shadow copy activé.
Vous exécutez chkdsk.exe sur un volume supérieur à 64 To.
Le message d’erreur peut inclure :
STOP : 0x0000007E
Échec de la création d’un shadow copy du volume < Drive_letter >.
Erreur 0x80042306 : le fournisseur de copies de l’ombre a reçu une erreur. Pour plus d’informations,
consultez les journaux des événements Système et Application.
ID d’événement : 12289. Erreur : 0x80070057. Le paramètre est incorrect.
Cause
Ce problème se produit car Microsoft ne prend pas en charge VSS sur les volumes supérieurs à 64 To. En outre,
les captures instantanées accessibles en writable ou les captures instantanées dont la taille est supérieure à 64
To ne sont pas prises en charge.
Pour contourner ce problème, n’effectuez aucune des opérations décrites dans la section « Symptômes » sur un
volume supérieur à 64 To.
Pour plus d’informations sur VSS, voir les sites web Microsoft suivants :
Service de cliché instantané de volume
Fonctionnement du service Volume Shadow Copy
Facteurs d’évolutivité pour les copies d’ombre
Meilleures pratiques pour les copies de l’ombre des dossiers partagés
Utiliser le composant logiciel enfichable Gestion des
disques pour gérer les disques de base et
dynamiques
Cet article explique comment utiliser le composant logiciel enfichable Gestion des disques pour gérer les
disques de base et dynamiques.
S’applique à : Windows Server 2012 R2, Windows 10 (toutes les éditions)
Résumé
Vous pouvez utiliser le composant logiciel enfichable Gestion des disques de Windows Server 2003 pour gérer
vos disques durs et les volumes ou partitions qu’ils contiennent. Grâce à l’utilitaire Gestion des disques, vous
pouvez créer et supprimer des partitions, formater des volumes avec le système de fichiers FAT, FAT32 ou NTFS,
convertir des disques de base en disques dynamiques et inversement, ainsi que créer des systèmes de disque à
tolérance de panne. Vous pouvez effectuer la majorité des tâches liées au disque sans avoir à redémarrer votre
ordinateur, car, pour la plupart, les modifications apportées à la configuration prennent effet immédiatement.
Cet article décrit certaines des tâches de gestion du stockage sur disque les plus courantes que vous pouvez
effectuer à l’aide de l’utilitaire Gestion des disques.
Démarrer l’utilitaire Gestion des disques
NOTE
Pour pouvoir utiliser l’utilitaire Gestion des disques, vous devez avoir ouvert une session en tant qu’administrateur ou que
membre du groupe Administrateurs.
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Gestion de l’ordinateur.
2. Dans l’arborescence de la console, cliquez sur Gestion des disques.
La fenêtre Gestion des disques qui s’affiche répertorie vos disques et volumes sous forme graphique ou
de liste.
Pour déterminer l’emplacement d’affichage de vos disques et volumes (dans le volet supérieur ou
inférieur de la fenêtre), pointez sur Haut ou sur Bas dans le menu Affichage, puis cliquez sur l’affichage
souhaité.
NOTE
Avant qu’un nouveau disque non partitionné puisse être utilisé dans Windows (partitionné ou mis à niveau vers
un disque dynamique), il doit contenir une signature de disque. Lors de la première exécution du composant
logiciel enfichable Gestion des disques après l’installation d’un nouveau disque dur, l’Assistant de signature de
disque et de mise à niveau du disque démarre. Si vous annulez cet Assistant, vous constaterez peut-être que
quand vous essayez de créer une partition sur le nouveau disque dur, l’option Créer une partition n’est pas
disponible (elle est grisée).
Gérer les disques de base

Le stockage sur disque de base prend en charge les disques orientés partitions. Un disque de base est un disque
physique qui contient des volumes de base (partitions principales, partitions étendues ou lecteurs logiques). Sur
les disques à enregistrement de démarrage principal (Master Boot Record, MBR), vous pouvez créer jusqu’à
quatre partitions principales sur un disque de base ou jusqu’à trois partitions principales et une partition
étendue. Vous pouvez également utiliser l’espace libre d’une partition étendue pour créer des lecteurs logiques.
Sur les disques à table de partition GUID (GPT), vous pouvez créer jusqu’à 128 partitions principales. Étant
donné que vous n’êtes pas limité à quatre partitions sur les disques GPT, vous ne devez pas créer de partitions
étendues sur les lecteurs logiques.
Utilisez des disques de base, au lieu de disques dynamiques, sur les ordinateurs qui exécutent Microsoft
Windows XP Professional ou un membre de Windows Server 2003 qui sont configurés pour le double
démarrage ou le démarrage multiple avec Microsoft Windows XP Édition familiale, Microsoft Windows NT 4.0,
Microsoft Windows Millennium Edition (Me), Microsoft Windows 98 ou version antérieure ou Microsoft MS-
DOS. Ces systèmes d’exploitation ne peuvent pas accéder aux données stockées sur des disques dynamiques.
NOTE
Les systèmes d’exploitation Windows Server 2003 et Windows XP Professionnel ne prennent pas en charge les volumes
de base multidisque (tels que les jeux d’agrégats par bandes fractionnés en miroir ou les jeux d’agrégats par bandes avec
parité) qui ont été créés à l’aide de Windows NT 4.0 ou version antérieure.
Créer une partition ou un lecteur logique

1. Dans la fenêtre Gestion des disques, effectuez l’une des étapes ci-dessous :
Pour créer une partition, cliquez avec le bouton droit sur l’espace non alloué du disque de base
dans lequel vous souhaitez créer la partition, puis cliquez sur Nouvelle partition.
ou -
Pour créer un lecteur logique, cliquez avec le bouton droit sur l’espace libre d’une partition
étendue dans lequel vous souhaitez créer le lecteur logique, puis cliquez sur Nouveau lecteur
logique.
2. Sur la page Bienvenue dans l’Assistant Création d’une nouvelle par tition , cliquez sur Suivant.
3. Sur la page Sélection du type de partition, cliquez sur le type de partition à créer, puis cliquez sur Suivant.
4. Sur la page Spécifier la taille de la partition, indiquez la taille de la partition à créer, en mégaoctets (Mo),
puis cliquez sur Suivant.
5. Sur la page Attribuer une lettre de lecteur ou de chemin d’accès , entrez une lettre de lecteur ou un
chemin d’accès au lecteur, puis cliquez sur Suivant.
6. Sur la page Formater une partition, déterminez les options de formatage de votre choix, puis cliquez sur
Suivant.
7. Sur la page Fin de l’Assistant Création d’une nouvelle par tition , vérifiez que les options
sélectionnées sont correctes, puis cliquez sur Terminer.
L’utilitaire Gestion des disques crée la partition ou le lecteur logique et l’affiche sur le disque de base approprié
dans la fenêtre Gestion des disques. Si vous avez choisi de formater la partition à l’étape 6, la procédure de
formatage démarre maintenant.
Formater une partition ou un lecteur logique
1. Dans la fenêtre Gestion des disques, cliquez avec le bouton droit sur la partition ou sur le lecteur logique à
formater, puis cliquez sur Formater.
2. Indiquez les options de formatage souhaitées, puis cliquez sur OK.
3. Cliquez sur OK quand vous êtes invité à confirmer les modifications de formatage.
Afficher les propriétés d’une partition ou d’un lecteur logique
1. Dans la fenêtre Gestion des disques, cliquez avec le bouton droit sur la partition ou sur le lecteur logique
dont vous souhaitez afficher les propriétés, puis cliquez sur Propriétés.
2. Cliquez sur l’onglet approprié pour afficher une propriété.
Supprimer une partition ou un lecteur logique
1. Dans la fenêtre Gestion des disques, cliquez avec le bouton droit sur la partition ou sur le lecteur logique
à supprimer, puis cliquez sur Supprimer la partition ou Supprimer le lecteur logique.
2. Cliquez sur Oui quand vous êtes invité à confirmer la suppression.
NOTE
Quand vous supprimez une partition ou un lecteur logique, toutes les données de cette partition ou de ce
lecteur logique, ainsi que la partition ou le lecteur logique lui-même sont supprimés.
Il est impossible de supprimer la partition système, la partition de démarrage ou une partition qui contient le
fichier de pagination (d’échange) actif.
Une partition étendue ne peut être supprimée que si elle est vide. Vous devez supprimer tous les lecteurs
logiques avant de pouvoir supprimer la partition étendue.
Convertir un disque de base en disque dynamique

Avant de convertir un disque de base en disque dynamique, tenez compte des points suivants :
Vous devez disposer d’au moins 1 mégaoctet (Mo) d’espace disque non alloué disponible sur le disque de
base à enregistrement de démarrage principal (MBR) à convertir en disque dynamique.
Quand vous convertissez un disque de base en disque dynamique, les partitions existantes du disque de
base sont converties en volumes simples sur le disque dynamique.
Après avoir converti un disque de base en disque dynamique, vous ne pouvez plus rétablir les volumes
dynamiques en partitions. Supprimez d’abord tous les volumes dynamiques du disque, puis reconvertissez le
disque dynamique en disque de base.
Les systèmes d’exploitation Windows Server 2003, Windows XP Professionnel et Windows 2000 prennent en
charge les disques dynamiques. Après avoir converti un disque de base en disque dynamique, vous pouvez
uniquement accéder au disque localement à partir de ces systèmes d’exploitation.
Pour convertir un disque de base en disque dynamique :
1. Dans l’affichage graphique de la fenêtre Gestion des disques, cliquez avec le bouton droit sur le disque de
base à convertir, puis cliquez sur Conver tir en disque dynamique .
NOTE
Pour cliquer avec le bouton droit sur le disque de base, vous devez cliquer avec le bouton droit sur la zone grise
qui contient le titre du disque à gauche du volet des détails de la fenêtre Gestion des disques (par exemple,
Disque 0).
2. Activez la case à cocher située en regard du disque à convertir, puis cliquez sur OK.
3. Si vous souhaitez afficher la liste des volumes du disque, cliquez sur Détails dans la boîte de dialogue
Disques à conver tir .
4. Cliquez sur Convertir.
5. Cliquez sur Oui quand vous êtes invité à confirmer la conversion, puis cliquez sur OK.
Gérer les disques dynamiques
Le stockage sur disque dynamique prend en charge les disques orientés volumes. Un disque dynamique est un
disque physique qui contient des volumes dynamiques. Avec les disques dynamiques, vous pouvez créer des
volumes simples, des volumes qui s’étendent sur plusieurs disques (volumes fractionnés et agrégés par bandes)
et des volumes à tolérance de panne (volumes en miroir et RAID-5). Les disques dynamiques peuvent contenir
un nombre illimité de volumes.
L’accès local aux disques dynamiques (et aux données qu’ils contiennent) est limité aux ordinateurs qui
exécutent les systèmes d’exploitation Windows Server 2003, Windows XP Professionnel ou Windows 2000.
Vous ne pouvez pas créer ou accéder à des volumes dynamiques sur des ordinateurs configurés pour le double
démarrage ou le démarrage multiple avec un système Windows Server 2003, Windows XP Professionnel ou
Windows 2000 et un ou plusieurs systèmes Windows XP Édition familiale, Windows NT 4.0 ou version
antérieure, Windows Millennium Edition, Windows 98 Deuxième Édition ou version antérieure ou MS-DOS.
Vous créez des disques dynamiques quand vous utilisez la commande Conver tir en disque dynamique dans
l’utilitaire Gestion des disques pour convertir un disque de base.
Créer un volume simple ou un volume fractionné
1. Dans la fenêtre Gestion des disques, effectuez l’une des étapes ci-dessous :
Pour créer un volume simple, cliquez avec le bouton droit sur l’espace non alloué du disque
dynamique dans lequel vous souhaitez créer le volume simple, puis cliquez sur Nouveau volume.
ou -
Pour créer un volume fractionné, cliquez avec le bouton droit sur l’espace non alloué du disque
dynamique dans lequel vous souhaitez créer le volume fractionné, puis cliquez sur Nouveau
volume.
2. Sur la page Bienvenue dans l’Assistant Création d’un nouveau volume , cliquez sur Suivant.
3. Sur la page Sélection du type de volume, cliquez sur Volume simple ou sur Volume fractionné , puis
sur Suivant.
4. Sur la page Sélectionner les disques, effectuez l’une des étapes ci-dessous :
Si vous créez un volume simple, vérifiez que le disque sur lequel vous souhaitez créer un volume
simple est répertorié dans la zone Disques dynamiques sélectionnés .
ou -
Si vous créez un volume fractionné, cliquez pour sélectionner les disques souhaités sous Tous les
disques dynamiques disponibles , puis cliquez sur Ajouter.
Vérifiez que les disques sur lesquels vous souhaitez créer un volume fractionné sont répertoriés
dans la zone Disques dynamiques sélectionnés .
5. Dans la zone Taille, spécifiez la taille (en Mo) souhaitée pour le volume, puis cliquez sur Suivant.
6. Sur la page Attribuer une lettre de lecteur ou de chemin d’accès , entrez une lettre de lecteur ou un
chemin d’accès au lecteur, puis cliquez sur Suivant.
7. Sur la page de formatage du volume, indiquez les options de formatage de votre choix, puis cliquez sur
Suivant.
8. Sur la page Fin de l’Assistant Création d’un nouveau volume , vérifiez que les options sélectionnées
sont correctes, puis cliquez sur Terminer.
Étendre un volume simple ou un volume fractionné
Si vous souhaitez augmenter la taille d’un volume simple ou fractionné après l’avoir créé, vous pouvez l’étendre
en ajoutant de l’espace libre non alloué sur le disque dynamique. Pour étendre un volume simple ou fractionné :
1. Dans la fenêtre Gestion des disques, cliquez avec le bouton droit sur le volume simple ou fractionné à
étendre, puis cliquez sur Étendre le volume.
2. Sur la page Bienvenue de l’Assistant Extension du volume , cliquez sur Suivant.
3. Sur la page Sélectionner les disques, cliquez pour sélectionner le ou les disques sur lesquels vous
souhaitez étendre le volume, puis cliquez sur Ajouter.
4. Vérifiez que les disques sur lesquels vous souhaitez étendre le volume sont répertoriés dans la zone
Disques dynamiques sélectionnés .
5. Dans la zone Taille, indiquez la quantité d’espace disque non alloué (en Mo) à ajouter, puis cliquez sur
Suivant.
6. Sur la page Fin de l’Assistant Extension du volume , vérifiez que les options sélectionnées sont
correctes, puis cliquez sur Terminer.
NOTE
Vous ne pouvez étendre que des volumes NTFS ou des volumes qui ne contiennent pas encore de système de
fichiers.
Si vous avez effectué une mise à niveau de Windows 2000 vers Windows Server 2003 (ou vers Windows XP
Professionnel), vous ne pouvez pas étendre un volume simple ou fractionné que vous avez créé à l’origine en
tant que volume de base, puis que vous avez converti en volume dynamique dans Windows 2000.
Il est impossible d’étendre le volume système ou de démarrage.
Créer un volume RAID-5

Un volume RAID-5 est un volume à tolérance de panne dans lequel les données et la parité sont agrégées par
bandes sur trois disques physiques ou plus. Si une partie d’un disque physique échoue, il est possible de
récupérer les données sur le disque défaillant en utilisant les données et les informations de parité sur les
disques fonctionnels.
Formater un volume dynamique
1. Dans la fenêtre Gestion des disques, cliquez avec le bouton droit sur le volume dynamique à formater, puis
cliquez sur Formater.
2. Indiquez les options de formatage souhaitées, puis cliquez sur OK.
3. Cliquez sur OK quand vous êtes invité à confirmer les modifications de formatage.
Afficher les propriétés d’un volume dynamique
1. Dans la fenêtre Gestion des disques, cliquez avec le bouton droit sur le volume dynamique dont vous
souhaitez afficher les propriétés, puis cliquez sur Propriétés.
2. Cliquez sur l’onglet approprié pour afficher une propriété.
Supprimer un volume dynamique
1. Dans la fenêtre Gestion des disques, cliquez avec le bouton droit sur le volume dynamique à supprimer, puis
cliquez sur Supprimer le volume.
2. Cliquez sur Oui quand vous êtes invité à confirmer la suppression.
NOTE
Quand vous supprimez un volume, toutes les données sur le volume et le volume lui-même sont supprimés.
Il est impossible de supprimer le volume système, le volume de démarrage ou un volume qui contient le fichier
de pagination (d’échange) actif.
Convertir un disque dynamique en disque de base
Avant de pouvoir convertir un disque dynamique en disque de base, vous devez supprimer tous les volumes du
disque dynamique.
Pour reconvertir un disque dynamique en disque de base, cliquez avec le bouton droit sur le disque dynamique
à reconvertir en disque de base dans la fenêtre Gestion des disques, puis cliquez sur Conver tir en disque de
base .
NOTE
Pour cliquer avec le bouton droit sur le disque, cliquez avec le bouton droit sur la zone grise qui contient le titre du disque
à gauche du volet de détails de l’utilitaire Gestion des disques (par exemple, Disque 0).

En cas de défaillance d’un disque ou d’un volume, l’utilitaire Gestion des disques affiche les descriptions d’état
des disques et des volumes dans la fenêtre Gestion des disques. Ces descriptions, qui sont reprises dans la liste
ci-dessous, vous informent de l’état actuel du disque ou du volume.
En ligne : il s’agit de l’état normal du disque quand celui-ci est accessible et fonctionne correctement.
Sain : il s’agit de l’état normal du volume quand celui-ci est accessible et fonctionne correctement.
En ligne (erreurs) (affiché avec des disques dynamiques uniquement) : des erreurs d’E/S ont été détectées
sur le disque dynamique.
Pour résoudre ce problème, cliquez avec le bouton droit sur le disque concerné, puis cliquez sur Réactiver
le disque pour rétablir l’état En ligne.
Hors connexion ou Manquant (affiché avec des disques dynamiques uniquement) : le disque est peut-être
inaccessible. Ce problème peut se produire si le disque est endommagé ou temporairement indisponible.
Pour résoudre ce problème, réparez les problèmes de disque, de contrôleur ou de connexion éventuels,
vérifiez que le disque physique est activé et correctement attaché à l’ordinateur, cliquez avec le bouton
droit sur le disque, puis cliquez sur Réactiver le disque pour rétablir l’état En ligne.
Pour obtenir la liste complète des descriptions d’état des disques et des volumes, consultez l’aide sur l’utilitaire
Gestion des disques. (Dans le composant logiciel enfichable Gestion des disques, cliquez sur le menu Action,
puis sur Aide. )
Prise en charge des disques durs de plus de 2 To
dans Windows
Cet article explique comment Windows prend en charge les disques durs d’une capacité de stockage supérieure
à 2 To et comment initialiser et partitionner les disques pour optimiser l’utilisation de l’espace.
Produits concernés : Windows Server 2022 Standard et Datacenter, Windows Server 2019, Windows
Résumé
Pour qu’un système d’exploitation prenne entièrement en charge un dispositif de stockage d’une capacité
supérieure à 2 téraoctets (2 To ou 2 billions d’octets), le dispositif doit être initialisé à l’aide du schéma de
partitionnement Table de partition GUID (GPT). Ce schéma prend en charge l’adressage de l’ensemble de la
capacité de stockage. Si l’utilisateur a l’intention de démarrer l’ordinateur à partir de l’un de ces disques de
grande capacité, l’interface du microprogramme de base du système doit utiliser l’interface UEFI (Unified
Extensible Firmware Interface) au lieu du BIOS.
Cet article décrit la prise en charge dans toutes les versions Windows depuis Windows XP. Il décrit également les
exigences relatives à l’adressage de la capacité de stockage complète de ces dispositifs.
NOTE
Cet article désigne la capacité de disque en puissance de deux au lieu de puissance de 10, ce qui est la désignation la
plus courante sur les étiquettes de capacité des dispositifs de stockage. Par conséquent, la mention 2 To désigne un
produit dont l’étiquette indique une capacité de 2,2 To.
Le comportement propre au système d’exploitation indiqué dans cet article s’applique également aux variantes serveur
de ce système. Par conséquent, une référence à Windows 7 inclut Windows Server 2008 R2, Windows Vista inclut
Windows Server 2008 et Windows XP inclut Windows Server 2003 et Windows Server 2003 R2.
La gestion des dispositifs de stockage modernes est traitée à l’aide d’un schéma appelé « adressage de blocs
logiques » (Logical Block Addressing, LBA). Il s’agit de la disposition des secteurs logiques qui constituent le
support. LBA0 représente le premier secteur logique du dispositif, et la dernière désignation LBA représente le
dernier secteur logique (une étiquette par secteur). Pour déterminer la capacité d’un dispositif de stockage,
multipliez le nombre de secteurs logiques qu’il contient par la taille de chaque secteur logique. La taille standard
par défaut est de 512 octets. Par exemple, pour obtenir un dispositif d’une capacité de 2 To, vous devez disposer
de 3 906 250 000 secteurs de 512 octets. Toutefois, un système informatique nécessite 32 bits (1 et 0)
d’informations pour représenter ce grand nombre. Par conséquent, toute capacité de stockage supérieure à celle
qui peut être représentée en utilisant 32 bits nécessite un bit supplémentaire, à savoir 33 bits.
Le problème de ce calcul est que le schéma de partitionnement utilisé par la plupart des ordinateurs Windows
modernes est Enregistrement de démarrage principal (MBR). Ce schéma définit une limite de 32 pour le nombre
de bits disponibles pour représenter le nombre de secteurs logiques.
La barrière de 2 To est le résultat de cette limitation 32 bits. Le nombre maximal qui peut être représenté en
utilisant 32 bits est 4 294 967 295, soit une capacité de 2,199 To en utilisant des secteurs de 512 octets (environ
2,2 To). Par conséquent, une capacité supérieure à 2,2 To n’est pas adressable à l’aide du schéma de
partitionnement MBR.
Pour rendre plus de bits disponibles pour l’adressage, le dispositif de stockage doit être initialisé à l’aide de GPT.
Ce schéma de partitionnement permet d’utiliser jusqu’à 64 bits d’informations dans les secteurs logiques. Il
entraîne une limite théorique de 9,4 Zo (9,4 zettaoctets, soit 9,4 milliards de téraoctets). Toutefois, le problème
qui touche GPT est que la plupart des systèmes actuellement disponibles reposent sur la plateforme BIOS
vieillissante. BIOS prend uniquement en charge les disques initialisés par MBR pour démarrer l’ordinateur. Pour
redémarrer à partir d’un dispositif initialisé à l’aide de GPT, votre système doit être compatible UEFI. Par défaut,
de nombreux systèmes actuels prennent en charge UEFI. Microsoft prévoit que la plupart des systèmes futurs
bénéficieront de cette prise en charge. Contactez votre fournisseur de systèmes pour savoir si leurs systèmes
prennent en charge UEFI et les disques d’une capacité de stockage supérieure à 2 To.
Exigences générales relatives à un volume de données non

démarrable
Pour qu’un système puisse prendre en charge la capacité maximale d’un dispositif d’une capacité de stockage
supérieure à 2 To, les conditions préalables suivantes doivent être réunies :
Le disque doit être initialisé à l’aide de GPT.
La version de Windows doit être l’une des suivantes (32 bits ou 64 bits, sauf indication contraire, mais y
compris toutes les éditions SKU) :
Windows Server 2008 R2 (uniquement la version 64 bits disponible)
Windows Server 2008
Windows 7
Windows Vista
Les derniers pilotes de stockage du fabricant de votre contrôleur de stockage doivent être installés. Par
exemple, si votre système utilise un contrôleur de stockage Intel défini en mode « RAID », assurez-vous
que vous disposez des derniers pilotes applicables sur le site du support Intel.
Idéalement, vous devez contacter le fabricant de votre ordinateur pour déterminer si celui-ci prend en
charge les dispositifs de stockage supérieurs à 2 To.
Exigences générales concernant un volume système de démarrage

Supposons que vous souhaitez remplir les objectifs suivants :
Tenir en votre possession un dispositif de stockage sur lequel vous pouvez installer Windows.
Convertir ce dispositif en dispositif de stockage de démarrage.
Permettre au système d’exploitation d’allouer une capacité de stockage maximale pour ce dispositif
supérieure à 2 To.
Pour remplir ces objectifs, les conditions préalables suivantes s’appliquent :
Le disque doit être initialisé à l’aide de GPT.
Le microprogramme système doit utiliser l’interface UEFI.
La version de Windows doit correspondre à l’une des versions suivantes (64 bits uniquement, mais
incluant toutes les éditions SKU) :
Windows Server 2008
Windows 7
Windows Vista
Les derniers pilotes de stockage du fabricant de votre contrôleur de stockage doivent être installés. Par
exemple, si votre système utilise un contrôleur de stockage Intel défini en mode RAID , assurez-vous que
les derniers pilotes applicables sont installés sur le site du support Intel.
NOTE
Windows ne prend pas en charge le démarrage de volumes initialisés par GPT à l’aide de systèmes UEFI sur les versions
32 bits de Windows. En outre, les systèmes BIOS hérités ne prennent pas en charge le démarrage de volumes
partitionnés par GPT. Consultez le fabricant de votre ordinateur pour déterminer si ce dernier prend en charge le mode
UEFI ainsi que le démarrage de dispositifs dont la capacité de stockage est supérieure à 2 To.
Matrice de prise en charge

La prise en charge par Microsoft des différents concepts abordés dans cet article est détaillée dans les tableaux
suivants. Ces tableaux fournissent des informations de prise en charge des disques dont la capacité de stockage
est supérieure à 2 To.
Tableau 1 : prise en charge par Windows des schémas de partitionnement en tant que volumes de données
SY ST ÈM E MBR H Y B RID- M B R GP T
Windows 7 Pris en charge Non pris en charge Pris en charge
Windows Vista Pris en charge Non pris en charge Pris en charge
Windows XP Pris en charge Non pris en charge Non pris en charge
Hybrid-MBR est un autre style de partitionnement qui n’est pris en charge par aucune version de Windows.
Tableau 2 : prise en charge par Windows du microprogramme système
SY ST ÈM E B IO S UEF I
Windows 7 Pris en charge Pris en charge
Windows Vista Pris en charge Pris en charge
Windows XP Pris en charge Non pris en charge
Tableau 3 : prise en charge par Windows de combinaisons de microprogrammes de démarrage et de schémas

de partitionnement pour le volume de démarrage
SY ST ÈM E B IO S + M B R UEF I + GP T B IO S + GP T UEF I + M B R
Windows 7 Pris en charge Pris en charge ; Volume de Volume de

nécessite une version démarrage non pris démarrage non pris
64 bits de Windows en charge en charge
Windows Vista Pris en charge Pris en charge ; Volume de Volume de

nécessite une version démarrage non pris démarrage non pris
64 bits de Windows en charge en charge
Windows XP Pris en charge Non pris en charge Volume de Volume de

démarrage non pris démarrage non pris
en charge en charge
Tableau 4 : prise en charge par Windows des disques de grande capacité en tant que volumes de données
uniquement (non destinés à devenir des volumes de démarrage )
>DISQ UE UN IQ UE DE 2 TO - >DISQ UE UN IQ UE DE 2 TO - >DISQ UE UN IQ UE DE 2 TO -
SY ST ÈM E MBR M B R H Y B RIDE GP T
Windows 7 Prend en charge jusqu’à Non pris en charge Prend en charge la pleine
2 To de capacité capacité
adressable**
Windows Vista Prend en charge jusqu’à Non pris en charge Prend en charge la pleine
2 To de capacité capacité
adressable**
Windows XP Prend en charge jusqu’à Non pris en charge Non pris en charge
2 To de capacité
adressable**
Une capacité supérieure à 2 To ne peut pas être adressée par Windows si le disque est initialisé en utilisant le
schéma de partitionnement MBR. Par exemple, pour un disque unique de 3 To initialisé à l’aide de MBR,
Windows peut créer des partitions pour les 2 premiers To. Cependant, la capacité restante ne peut pas être
adressée et ne peut donc pas être utilisée.
Initialiser un disque de données à l’aide de GPT

La procédure suivante explique comment initialiser un nouveau disque à l’aide du schéma de partitionnement
GPT, qui permet de vous assurer que Windows peut adresser la capacité de stockage maximale disponible.
Veillez à sauvegarder les données importantes avant de commencer la procédure.
1. Cliquez sur Démarrer , saisissez diskmgmt.msc dans la zone de recherche , cliquez avec le bouton droit
sur diskmgmt.msc, puis cliquez sur Exécuter en tant qu’administrateur . Si nécessaire, saisissez les
informations d’identification d’un compte d’utilisateur disposant de privilèges d’administrateur.
NOTE
Lorsqu’un disque non initialisé est détecté par Windows, la fenêtre suivante s’affiche pour vous inviter à initialiser
le disque.
2. Dans la boîte de dialogue Initialiser le disque , sélectionnez GUID Par tition Table , puis cliquez sur OK.
NOTE
Si vous sélectionnez cette option, ce disque dur ne sera pas reconnu par Windows XP et versions antérieures.
3. Vérifiez dans la fenêtre Gestion des disques que le disque est initialisé. Si c’est le cas, la ligne d’état de ce
disque, en bas de la fenêtre, doit indiquer que le disque est En ligne .
4. Une fois le disque initialisé, vous devez créer une partition, puis formater cette partition à l’aide d’un
système de fichiers. Le formatage va permettre de stocker des données dans cette partition et de lui
attribuer un nom et une lettre de lecteur. Pour ce faire, cliquez avec le bouton droit sur l’espace non alloué
à droite de la ligne d’état de ce disque, puis cliquez sur Nouveau volume simple . Suivez les étapes de
l’Assistant de partition pour procéder au formatage.
Convertir un disque MBR en GPT
Si vous avez précédemment initialisé le disque à l’aide du schéma de partitionnement MBR, procédez comme
suit pour initialiser le disque à l’aide du schéma GPT. Veillez à sauvegarder les données importantes avant de
commencer la procédure.
1. Cliquez sur Démarrer , saisissez diskmgmt.msc dans la zone de recherche , cliquez avec le bouton droit
sur diskmgmt.msc, puis cliquez sur Exécuter en tant qu’administrateur . Si nécessaire, saisissez les
informations d’identification d’un compte d’utilisateur disposant de privilèges d’administrateur.
2. Dans la fenêtre Gestion des disques, examinez les lignes d’état des disques en bas. Dans l’exemple
suivant, l’utilisateur dispose d’un disque de 3 To qui a été initialisé précédemment à l’aide du schéma de
partitionnement MBR. Ce dispositif de stockage est dénommé ici Disque 1.
3. Le disque 1 contient deux sections distinctes non allouées. Cette séparation indique que les 2 premiers To
de l’espace disque peuvent être utilisés. Cependant, l’espace restant n’est pas adressable en raison de la
limitation de l’espace d’adressage 32 bits du schéma de partitionnement MBR. Pour permettre au
système d’adresser entièrement la capacité totale du dispositif de stockage, vous devez convertir le
disque pour utiliser le schéma de partitionnement GPT.
4. Cliquez avec le bouton droit sur l’étiquette à gauche du disque à convertir, puis cliquez sur Conver tir en
disque GPT .
NOTE
La section en regard de Disque 1 devrait indiquer que la totalité de l’espace disponible est non allouée.
5. Maintenant que le disque est initialisé pour accéder à la pleine capacité de stockage, vous devez créer une
partition, puis formater cette partition en choisissant un système de fichiers. Le formatage va permettre
de stocker des données dans cette partition et de lui attribuer un nom et une lettre de lecteur. Pour ce
faire, cliquez avec le bouton droit sur l’espace non alloué à droite de la ligne d’état de ce disque, puis
cliquez sur Nouveau volume simple . Suivez les étapes de l’Assistant de partition pour procéder au
formatage.
Limitations et problèmes connus

La transition vers les disques uniques d’une capacité supérieure à 2 To est un phénomène récent, qui a poussé
Microsoft à étudier la manière dont Windows allait prendre en charge ces disques de grande taille. Les résultats
ont mis en lumière plusieurs problèmes, qui s’appliquent à Windows 7 avec Service Pack 1 et à
Windows Server 2008 R2 avec Service Pack 1, ainsi qu’à toutes leurs versions antérieures.
Jusqu’à présent, le comportement incorrect suivant est connu pour se produire lorsque Windows gère une
capacité de stockage supérieure à 2 To sur un disque unique :
La capacité numérique au-delà de 2 To dépasse la taille autorisée. En conséquence, le système ne peut
traiter que la capacité supérieure à 2 To. Par exemple, sur un disque de 3 To, la capacité disponible n’est
que de 1 To.
La capacité numérique au-delà de 2 To est tronquée. Seuls 2 To d’espace sont donc adressables. Par
exemple, sur un disque de 3 To, la capacité disponible n’est que de 2 To.
Le dispositif de stockage n’est pas détecté correctement. Dans ce cas, il n’est pas affiché dans les fenêtres
Gestionnaire de périphériques ou Gestion des disques. De nombreux fabricants de contrôleurs de
stockage proposent des pilotes mis à jour qui prennent en charge les capacités de stockage supérieures à
2 To. Contactez le fabricant ou l’OEM de votre contrôleur de stockage pour connaître les solutions de
prise en charge téléchargeables pour les disques uniques disposant d’une capacité supérieure à 2 To.
Données de détection SCSI

Lorsqu’un disque rencontre des erreurs liées à des secteurs illisibles ou protégés en écriture, il signale ces
erreurs et les données de détection SCSI correspondantes au système d’exploitation. Les données de détection
SCSI peuvent contenir des informations sur le LBA pour les secteurs illisibles ou protégés en écriture.
Pour un espace d’adressage LBA supérieur à 2 To, le disque nécessite des données de détection SCSI au format
descripteur. Ce format n’est pas pris en charge par Windows 7 ou Windows Server 2008 R2, qui récupère les
données de détection SCSI au format fixe. Par conséquent, les données de détection SCSI récupérées ne
contiennent pas d’informations sur les secteurs défectueux ou contiennent des informations incorrectes sur les
secteurs défectueux. Les administrateurs doivent tenir compte de cette restriction quand ils recherchent les
informations LBA sur les secteurs défectueux enregistrées dans le journal des événements Windows.
Comment activer ou désactiver manuellement la
mise en cache d’écriture de disque
Cet article décrit les étapes à suivre pour activer ou désactiver manuellement la mise en cache de l’écriture de
disque.
Résumé
Avec certains programmes tiers, la mise en cache d’écriture sur disque doit être mise en cache ou désactivée. En
outre, la mise en cache de l’écriture sur disque peut augmenter les performances du système d’exploitation.
toutefois, elle peut également entraîner la perte d’informations en cas de panne de courant, de panne
d’équipement ou de logiciel. Cet article explique comment activer ou désactiver la mise en cache d’écriture de
disque.
Activer ou désactiver la mise en cache d’écriture de disque

1. Cliquez avec le bouton droit sur Mon ordinateur, puis cliquez sur Propriétés.
2. Cliquez sur l’onglet Matériel, puis sur Gestionnaire de périphériques.
3. Développez les lecteurs de disque.
4. Cliquez avec le bouton droit sur le lecteur sur lequel vous souhaitez activer ou désactiver la mise en cache
d’écriture de disque, puis cliquez sur Propriétés.
5. Cliquez sur l’onglet Stratégies.
6. Cliquez pour activer ou effacer la mise en cache Activer l’écriture sur le disque, le cas échéant.
7. Cliquez sur OK .
Windows Server 2008
1. Cliquez avec le bouton droit sur Ordinateur, puis cliquez sur Propriétés.
2. Cliquez sur le lien Gestionnaire de périphériques sous Tâches.
3. Développez les lecteurs de disque.
4. Cliquez avec le bouton droit sur le lecteur sur lequel vous souhaitez activer ou désactiver la mise en cache
d’écriture de disque, puis cliquez sur Propriétés.
5. Cliquez sur l’onglet Stratégies.
6. Cliquez pour activer ou effacer la mise en cache Activer l’écriture sur le disque, le cas échéant.
7. Cliquez sur OK .
Informations sur l’ID d’événement 51
L’ID d’événement 51 peut se produire lorsque vous écrivez des informations sur le disque physique. Cet article
explique comment décoder la section de données d’un message d’événement ID d’événement 51.
Résumé
Lorsque vous écrivez des informations sur le disque physique, le message d’événement suivant peut être
enregistré dans le journal système :
Event ID: 51
Event Type: Warning
Event Source: Disk
Description: An error was detected on device \Device\Harddisk3\DR3 during a paging operation.
Data:
0000: 04 00 22 00 01 00 72 00
0008: 00 00 00 00 33 00 04 80
0010: 2d 01 00 00 00 00 00 00
0018: 00 00 00 00 00 00 00 00
0020: 00 52 ea 04 15 00 00 00
0028: 01 00 00 00 04 00 00 00
0030: 03 00 00 00 2a 00 00 00
0038: 02 84 00 00 00 29 06 00
0040: 2a 60 0a 82 75 29 00 00
0048: 80 00
NOTE
L’appareil dans la description et les données hexadécimales spécifiques peuvent varier.
Si une erreur générique se produit lorsque votre ordinateur pages des informations vers ou à partir du disque,
un message d’événement ID d’événement 51 est enregistré. Dans une opération de pagination, le système
d’exploitation échange une page de mémoire de la mémoire vers le disque, ou récupère une page de mémoire
du disque vers la mémoire. Cela fait partie de la gestion de la mémoire des Windows.
Toutefois, l’ordinateur peut enregistrer ce message d’événement lorsqu’il charge des images à partir d’un
périphérique de stockage, lit et écrit dans des fichiers mappés localement ou dans n’importe quel fichier (tant
qu’il est mis en mémoire tampon d’E/S). L’ordinateur n’enregistre pas ce message d’événement lorsqu’il effectue
des O/S nonbuffered. Vous pouvez dépanner un message d’événement ID d’événement 51 exactement comme
vous dépanner les messages d’événement ID d’événement 9 ou ID d’événement 11.
Dans certaines circonstances, le système enregistre le message d’événement 51 de l’ID d’événement suivant :
An error was detected on device \Device\DeviceName during a paging operation
Dans ce cas, aucun effet dangereux n’est connu. Par exemple, l’ID d’événement 51 est enregistré lorsque des
supports vides tels que CDR, CDRW, DVDR sont insérés dans un lecteur accessible en lecture alors qu’un
périphérique USB est branché. Le système enregistre l’événement même si le disque est accessible en entrée et
que l’appareil USB est toujours utilisable. Dans ces cas particuliers, vous pouvez ignorer en toute sécurité les
entrées du journal. Aucune action n’est requise.
NOTE
Sur Windows XP et Windows Server 2003, DeviceName peut être tronqué en raison de la limitation de taille de l’entrée du
journal des événements. Par conséquent, le numéro de disque dur affiché ou le nom d’objet de l’appareil lui-même peut
être incorrect. Étant donné qu’une grande quantité d’informations est stockée dans la section de données, l’espace
disponible pour DeviceName est réduit. Dans ce cas, vous pouvez trouver l’appareil approprié en regardant les données
de disque de destination stockées dans la section données. Pour plus d’informations, voir Décoder la section de données
d’un message d’événement ID d’événement 51.
Sur Windows Vista et les versions ultérieures, la taille de l’entrée du journal des événements a été augmentée et
DeviceName n’est pas tronqué.
Vous pouvez utiliser les données binaires associées à toute erreur DISK (ID d’événement 7, 9, 11, 51 et autres ID
d’événement) pour vous aider à identifier le problème en décodant la section de données.
Un ID d’événement 51 dispose d’une zone de bloc de descripteur de commande (CDB) supplémentaire. Prenons
les informations suivantes lorsque vous examinez la section de données d’un message d’événement ID
d’événement 51.
Décoder la section de données d’un message d’événement ID

d’événement 51
Lorsque vous décodez la section de données de l’exemple dans la section Résumé , vous pouvez voir qu’une
tentative d’exécution d’une opération d’écriture dans le LUN 3 à partir du 0x2975820a secteur pour les secteurs
0x0080 échoue car le bus a été réinitialisé, mais la demande est retentée. Plus loin, cet article répertorie les
étapes spécifiques pour décoder cet exemple.
Les tableaux suivants décrivent ce que représente chaque décalage :
O F F SET LO N GUEUR VA L UES
0x00 1 Type d’opération : 0x03 = Lecture,

0x04 = Écriture, 0x0F = IOCTL
0x01 1 Nombre de tentatives restantes
0x02 2 Taille des données de vidage 0x0068
0x04 2 Nombre de chaînes 0x0001
0x06 2 Décalage vers le nom de l’appareil
0x08 2 Inutilisé
0x0a 2 Octets de remplissage
0x0c 4 Code d’erreur NTSTATUS
0x10 4 Valeur d’erreur unique

O F F SET LO N GUEUR VA L UES
0x14 4 État final NTSTATUS 0x00000000 = la

demande sera retentée
0x18 4 Numéro de séquence - Inutilisé
0x1c 4 Code de contrôle Io (ne s’applique pas

à cet événement)
0x20 8 Décalage d’byte vers un secteur non

bon, le cas cas
0x28 8 Nombre de ticks lorsque l’erreur s’est

produite
0x30 4 Numéro de port - Inutilisé
0x34 1 Indicateurs d’erreur
0x35 3 Inutilisé
0x38 88 Structure de bloc de requête SCSI
0x90 18 Structure des données d’sense
Sections clés à décoder

Voici les principales sections à décoder.
Le code d’erreur
Dans l’exemple de la section Résumé , le code d’erreur est répertorié sur la deuxième ligne. Cette ligne
commence par 0008 : et inclut les 4 derniers octets de la ligne.
0008: 00 00 00 00 33 00 04 80
ErrorCode = 0x80040033
Ce code est le code de l’erreur 51. Ce code est le même pour tous les messages d’événement de l’ID
d’événement 51 :
IO_WARNING_PAGING_FAILURE
NOTE
Lorsque vous interprètez les données hexadécimales dans l’ID d’événement sur le code d’état, n’oubliez pas que les
valeurs sont représentées dans le format petit endian.
Le code d’état final

Dans l’exemple de la section Résumé , le code d’état final est répertorié à 0x14 (sur la troisième ligne) qui
commence par 0010 et inclut les quatre derniers octets de cette ligne.
0010: 2d 01 00 00 00 00 00 00
FinalStatus = 0x00000000
Il est mapcé STATUS_SUCCESS et implique que la demande sera retentée.
NOTE
Lorsque vous interprètez les données hexadécimales dans l’ID d’événement sur le code d’état, n’oubliez pas que les
valeurs sont représentées dans le format petit endian.
Disque de destination
Vous pouvez utiliser ces données pour déterminer sur quel disque le problème s’est produit :
0028: 01 00 00 00 04 00 00 00
ID de chemin = 0x0000001, ID cible = 0x0000004
0030: 03 00 00 00 2a 00 00 00
LUN = 0x0000003
Il peut être plus facile d’identifier le volume à l’aide du lien symbolique répertorié sur le lecteur dans la
description de l’ID d’événement. Par exemple : \Device\Harddisk3\DR3 .
NOTE
Les informations de disque de destination sont les informations qui apparaissent dans le système d’exploitation. Stockage
virtualisation et les logiciels d’I/S multipath peuvent masquer ce qui est présenté au système d’exploitation. Ces
informations peuvent ne pas correspondre directement aux mappages physiques.
Paramètres SRB (Request Block) SCSI

Dans l’exemple de la section Résumé , ScsiStatus est 0x02 (premier byte de la ligne 0038 ) et SrbStatus est 0x84
(deuxième sur la ligne 0038 ). Il fournit les informations suivantes :
0038: 02 84 00 00 00 29 06 00
ScsiStatus de 0x02 :
SCSISTAT_CHECK_CONDITION
Codes d’état SCSI : (à partir de SCSI. H)
0x00 = SCSISTAT_GOOD
0x02 = SCSISTAT_CHECK_CONDITION
0x04 = SCSISTAT_CONDITION_MET
0x08 = SCSISTAT_BUSY
0x10 = SCSISTAT_INTERMEDIATE
0x14 = SCSISTAT_INTERMEDIATE_COND_MET
0x18 = SCSISTAT_RESERVATION_CONFLICT
0x22 = SCSISTAT_COMMAND_TERMINATED
0x28 = SCSISTAT_QUEUE_FULL
SrbStatus de 0x84 :
SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_ERROR
0x00 = SRB_STATUS_PENDING
0x01 = SRB_STATUS_SUCCESS
0x02 = SRB_STATUS_ABORTED
0x03 = SRB_STATUS_ABORT_FAILED
0x04 = SRB_STATUS_ERROR
0x05 = SRB_STATUS_BUSY
0x06 = SRB_STATUS_INVALID_REQUEST
0x07 = SRB_STATUS_INVALID_PATH_ID
0x08 = SRB_STATUS_NO_DEVICE
0x09 = SRB_STATUS_TIMEOUT
0x0A = SRB_STATUS_SELECTION_TIMEOUT
0x0B = SRB_STATUS_COMMAND_TIMEOUT
0x0D = SRB_STATUS_MESSAGE_REJECTED
0x0E = SRB_STATUS_BUS_RESET
0x0F = SRB_STATUS_PARITY_ERROR
0x10 = SRB_STATUS_REQUEST_SENSE_FAILED
0x11 = SRB_STATUS_NO_HBA
0x12 = SRB_STATUS_DATA_OVERRUN
0x13 = SRB_STATUS_UNEXPECTED_BUS_FREE
0x14 = SRB_STATUS_PHASE_SEQUENCE_FAILURE
0x15 = SRB_STATUS_BAD_SRB_BLOCK_LENGTH
0x16 = SRB_STATUS_REQUEST_FLUSHED
0x20 = SRB_STATUS_INVALID_LUN
0x21 = SRB_STATUS_INVALID_TARGET_ID
0x22 = SRB_STATUS_BAD_FUNCTION
0x23 = SRB_STATUS_ERROR_RECOVERY
0x24 = SRB_STATUS_NOT_POWERED
0x30 = SRB_STATUS_INTERNAL_ERROR
(used by the port driver to indicate that a non-scsi-related error occurred)
0x38 - 0x3f = Srb status values reserved for internal port driver use.
Masques d’état SRB :
0x80 = SRB_STATUS_AUTOSENSE_VALID
0x40 = SRB_STATUS_QUEUE_FROZEN
Vous devez décomposer les masques d’état SRB, car il s’agit d’un sous-état. Ils sont combinés avec les codes
d’état SRB.
Dans l’exemple 0x84 précédent, 0x8_ est un masque d’état. Par conséquent, SRB_STATUS_AUTOSENSE_VALID et
0x04 est le code d’état SRB. Cela signifie SRB_STATUS_ERROR .
Code de sens
Si l’état SRB est que laense automatique est valide, les codes de sens fournissent plus d’informations. Dans
l’exemple de la section Résumé , le code de sens est 0x06 (septième octet de la ligne 0038 ) et le code de sens
supplémentaire est 0x29 (sixième octet de la ligne 0038 ). Il fournit les informations suivantes :
0038: 02 84 00 00 00 29 06 00
La clé d'0x06 :
L’byte au décalage 003e est la clé de sens. Il est map pour :
0x06 = SCSI_SENSE_UNIT_ATTENTION
Codes de sens : (à partir de SCSI. H)

0x00 = SCSI_SENSE_NO_SENSE
0x01 = SCSI_SENSE_RECOVERED_ERROR
0x02 = SCSI_SENSE_NOT_READY
0x03 = SCSI_SENSE_MEDIUM_ERROR
0x04 = SCSI_SENSE_HARDWARE_ERROR
0x05 = SCSI_SENSE_ILLEGAL_REQUEST
0x06 = SCSI_SENSE_UNIT_ATTENTION
0x07 = SCSI_SENSE_DATA_PROTECT
0x08 = SCSI_SENSE_BLANK_CHECK
0x09 = SCSI_SENSE_UNIQUE
0x0A = SCSI_SENSE_COPY_ABORTED
0x0B = SCSI_SENSE_ABORTED_COMMAND
0x0C = SCSI_SENSE_EQUAL
0x0D = SCSI_SENSE_VOL_OVERFLOW
0x0E = SCSI_SENSE_MISCOMPARE
0x0F = SCSI_SENSE_RESERVED
Code de sens supplémentaire (ASC) de 0x29 :

L’ASC se trouve dans le sixième byte de la ligne 0038 au décalage 003d et a une valeur de 29. Pour la touche de
sens spécifiée, elle est m mapée sur :
0x29 = SCSI_ADSENSE_BUS_RESET
Codes de sens supplémentaires : (à partir de SCSI. H)
0x00 = SCSI_ADSENSE_NO_SENSE
0x02 = SCSI_ADSENSE_NO_SEEK_COMPLETE
0x04 = SCSI_ADSENSE_LUN_NOT_READY
0x0C = SCSI_ADSENSE_WRITE_ERROR
0x14 = SCSI_ADSENSE_TRACK_ERROR
0x15 = SCSI_ADSENSE_SEEK_ERROR
0x17 = SCSI_ADSENSE_REC_DATA_NOECC
0x18 = SCSI_ADSENSE_REC_DATA_ECC
0x20 = SCSI_ADSENSE_ILLEGAL_COMMAND
0x21 = SCSI_ADSENSE_ILLEGAL_BLOCK
0x24 = SCSI_ADSENSE_INVALID_CDB
0x25 = SCSI_ADSENSE_INVALID_LUN
0x27 = SCSI_ADSENSE_WRITE_PROTECT
0x28 = SCSI_ADSENSE_MEDIUM_CHANGED
0x29 = SCSI_ADSENSE_BUS_RESET
0x2E = SCSI_ADSENSE_INSUFFICIENT_TIME_FOR_OPERATION
0x30 = SCSI_ADSENSE_INVALID_MEDIA
0x3a = SCSI_ADSENSE_NO_MEDIA_IN_DEVICE
0x3b = SCSI_ADSENSE_POSITION_ERROR
0x5a = SCSI_ADSENSE_OPERATOR_REQUEST
0x5d = SCSI_ADSENSE_FAILURE_PREDICTION_THRESHOLD_EXCEEDED
0x64 = SCSI_ADSENSE_ILLEGAL_MODE_FOR_THIS_TRACK
0x6f = SCSI_ADSENSE_COPY_PROTECTION_FAILURE
0x73 = SCSI_ADSENSE_POWER_CALIBRATION_ERROR
0x80 = SCSI_ADSENSE_VENDOR_UNIQUE
0xA0 = SCSI_ADSENSE_MUSIC_AREA
0xA1 = SCSI_ADSENSE_DATA_AREA
0xA7 = SCSI_ADSENSE_VOLUME_OVERFLOW
Qualificateur de code de sens supplémentaire (AS...), 0x00 :

L’ASBRÉ se trouve dans le cinquième byte de la ligne 0038 au décalage 003C et a une valeur de 00 . Comme il
s’agit de 00 dans cet exemple, il ne s’applique pas à l’ASC spécifié. Cette liste d’ASCLUT pour chaque code de
sens est trop grande pour être inclue dans cet article. Afficher SCSI. H dans le DDK pour plus d’informations.
NOTE
Toutes les valeurs ASC et ASRC ci-dessus 0x80 sont spécifiques au fournisseur et ne sont pas documentées dans la
spécification SCSI ou le DDK Microsoft. Reportez-vous au fournisseur de matériel.
Paramètres CDB (Command Descriptor Block)

La base de données de base de données commence à la ligne avec un décalage de 0040 :
0040: 2a 60 0a 82 75 29 00 00
0048: 80 00
Les octets au décalage 0x40 représentent le code CDB. Les octets entre 0x43 décalage et 0x46 représentent le
secteur de départ et les 0x47 de décalage 0x49 représentent le nombre de secteurs impliqués dans l’opération.
NOTE
La section de données CDB n’est pas au format petit final. Les octets ne doivent donc pas être retournés. Soyez prudent
lorsque vous décodez cette section, car le format est différent des sections précédentes.
0x2a = Write request

0x0a827529 = The starting sector
0x0080 = The number of sectors
Codes SCSI CDB : (à partir de SCSI. H)
0x00 = SCSIOP_TEST_UNIT_READY
0x01 = SCSIOP_REZERO_UNIT
0x01 = SCSIOP_REWIND
0x02 = SCSIOP_REQUEST_BLOCK_ADDR
0x03 = SCSIOP_REQUEST_SENSE
0x04 = SCSIOP_FORMAT_UNIT
0x05 = SCSIOP_READ_BLOCK_LIMITS
0x07 = SCSIOP_REASSIGN_BLOCKS
0x07 = SCSIOP_INIT_ELEMENT_STATUS
0x08 = SCSIOP_READ6
0x08 = SCSIOP_RECEIVE
0x0A = SCSIOP_WRITE6
0x0A = SCSIOP_PRINT
0x0A = SCSIOP_SEND
0x0B = SCSIOP_SEEK6
0x0B = SCSIOP_TRACK_SELECT
0x0B = SCSIOP_SLEW_PRINT
0x0C = SCSIOP_SEEK_BLOCK
0x0D = SCSIOP_PARTITION
0x0F = SCSIOP_READ_REVERSE
0x10 = SCSIOP_WRITE_FILEMARKS
0x10 = SCSIOP_FLUSH_BUFFER
0x11 = SCSIOP_SPACE
0x12 = SCSIOP_INQUIRY
0x13 = SCSIOP_VERIFY6
0x14 = SCSIOP_RECOVER_BUF_DATA
0x15 = SCSIOP_MODE_SELECT
0x16 = SCSIOP_RESERVE_UNIT
0x17 = SCSIOP_RELEASE_UNIT
0x18 = SCSIOP_COPY
0x19 = SCSIOP_ERASE
0x1A = SCSIOP_MODE_SENSE
0x1B = SCSIOP_START_STOP_UNIT
0x1B = SCSIOP_STOP_PRINT
0x1B = SCSIOP_LOAD_UNLOAD
0x1C = SCSIOP_RECEIVE_DIAGNOSTIC
0x1D = SCSIOP_SEND_DIAGNOSTIC
0x1E = SCSIOP_MEDIUM_REMOVAL
0x23 = SCSIOP_READ_FORMATTED_CAPACITY
0x25 = SCSIOP_READ_CAPACITY
0x28 = SCSIOP_READ
0x2A = SCSIOP_WRITE
0x2B = SCSIOP_SEEK
0x2B = SCSIOP_LOCATE
0x2B = SCSIOP_POSITION_TO_ELEMENT
0x2E = SCSIOP_WRITE_VERIFY
0x2F = SCSIOP_VERIFY
0x30 = SCSIOP_SEARCH_DATA_HIGH
0x31 = SCSIOP_SEARCH_DATA_EQUAL
0x32 = SCSIOP_SEARCH_DATA_LOW
0x33 = SCSIOP_SET_LIMITS
0x34 = SCSIOP_READ_POSITION
0x35 = SCSIOP_SYNCHRONIZE_CACHE
0x39 = SCSIOP_COMPARE
0x3A = SCSIOP_COPY_COMPARE
0x3B = SCSIOP_WRITE_DATA_BUFF
0x3C = SCSIOP_READ_DATA_BUFF
0x40 = SCSIOP_CHANGE_DEFINITION
0x42 = SCSIOP_READ_SUB_CHANNEL
0x43 = SCSIOP_READ_TOC
0x44 = SCSIOP_READ_HEADER
0x45 = SCSIOP_PLAY_AUDIO
0x46 = SCSIOP_GET_CONFIGURATION
0x47 = SCSIOP_PLAY_AUDIO_MSF
0x48 = SCSIOP_PLAY_TRACK_INDEX
0x49 = SCSIOP_PLAY_TRACK_RELATIVE
0x4A = SCSIOP_GET_EVENT_STATUS
0x4B = SCSIOP_PAUSE_RESUME
0x4C = SCSIOP_LOG_SELECT
0x4D = SCSIOP_LOG_SENSE
0x4E = SCSIOP_STOP_PLAY_SCAN
0x51 = SCSIOP_READ_DISK_INFORMATION
0x52 = SCSIOP_READ_TRACK_INFORMATION
0x53 = SCSIOP_RESERVE_TRACK_RZONE
0x54 = SCSIOP_SEND_OPC_INFORMATION
0x55 = SCSIOP_MODE_SELECT10
0x5A = SCSIOP_MODE_SENSE10
0x5B = SCSIOP_CLOSE_TRACK_SESSION
0x5C = SCSIOP_READ_BUFFER_CAPACITY
0x5D = SCSIOP_SEND_CUE_SHEET
0x5E = SCSIOP_PERSISTENT_RESERVE_IN
0x5F = SCSIOP_PERSISTENT_RESERVE_OUT
0xA0 = SCSIOP_REPORT_LUNS
0xA1 = SCSIOP_BLANK
0xA3 = SCSIOP_SEND_KEY
0xA4 = SCSIOP_REPORT_KEY
0xA5 = SCSIOP_MOVE_MEDIUM
0xA6 = SCSIOP_LOAD_UNLOAD_SLOT
0xA6 = SCSIOP_EXCHANGE_MEDIUM
0xA7 = SCSIOP_SET_READ_AHEAD
0xAD = SCSIOP_READ_DVD_STRUCTURE
0xB5 = SCSIOP_REQUEST_VOL_ELEMENT
0xB6 = SCSIOP_SEND_VOLUME_TAG
0xB8 = SCSIOP_READ_ELEMENT_STATUS
0xB9 = SCSIOP_READ_CD_MSF
0xBA = SCSIOP_SCAN_CD
0xBB = SCSIOP_SET_CD_SPEED
0xBC = SCSIOP_PLAY_CD
0xBD = SCSIOP_MECHANISM_STATUS
0xBE = SCSIOP_READ_CD
0xBF = SCSIOP_SEND_DVD_STRUCTURE
0xE7 = SCSIOP_INIT_ELEMENT_RANGE
Disque pass-through en lecture seule après avoir
ajouté le disque à une ordinateur virtuel hautement
disponible dans un cluster de Windows Server 2008
R2 SP1
Cet article décrit les étapes à suivre pour ajouter un disque pass-through à une machine virtuelle à haut niveau
de disponible dans un cluster de pointage basé sur Windows Server 2008 R2 Service Pack 1 (SP1) et permet de
résoudre le problème où l’état du disque pass-through ajouté est affiché en lecture seule.
Ajouter un disque pass-through à une ordinateur virtuel hautement

disponible
Pour ajouter un disque pass-through à une ordinateur virtuel hautement disponible dans un cluster de
Windows Server 2008 R2 SP1, suivez les étapes suivantes :
1. Connectez-vous en tant qu’utilisateur de domaine membre du groupe Administrateurs local sur chaque
nœud de cluster.
2. Configurez le disque pass-through sur le réseau Stockage (SAN) et map passez le disque à chaque nœud
de cluster.
3. Ouvrez le logiciel en ligne Gestion des disques, puis vérifiez que chaque nœud de cluster détecte le
disque et que l’état du disque est hors connexion.
4. Cliquez avec le bouton droit sur le nom du disque, puis cliquez sur En ligne pour mettre le disque en
ligne.
5. Cliquez avec le bouton droit sur le nom du disque, puis cliquez sur Initialiser le disque pour initialiser le
disque.
6. Cliquez avec le bouton droit sur le nom du disque, puis cliquez sur Hors connexion pour mettre le disque
hors connexion.
NOTE
Vous devez mettre le disque hors connexion avant d’ajouter le disque au cluster.
7. Ajoutez le disque au cluster deoverover. Pour cela, procédez comme suit :

a. Ouvrez le logiciel en snap-in Gestionnaire du cluster de failover, cliquez avec le bouton droit
Stockage dans l’arborescence de la console, puis cliquez sur Ajouter un disque.
b. Dans la boîte de dialogue Ajouter des disques à un cluster, cochez la case du disque à ajouter, puis
cliquez sur OK.
c. Dans le Stockage, vérifiez que le disque est répertorié dans l’Stockage disponible et que l’état du
disque est En ligne.
8. Ajoutez le disque à un ordinateur virtuel hautement disponible existant dans le cluster. Pour cela,
a. Dans le logiciel en snap-in Gestionnaire du cluster de failover, cliquez avec le bouton droit sur
l’ordinateur virtuel répertorié sous Machine virtuelle, puis cliquez sur Paramètres .
b. Dans la Paramètres dialogue, sélectionnez un contrôleur de disque, puis cliquez sur Ajouter pour
ajouter le disque au contrôleur de disque. Par exemple, cliquez sur Contrôleur SCSI, puis sur
Ajouter pour ajouter le disque au contrôleur SCSI.
c. Dans le volet Disque dur, sélectionnez le disque dans la liste Des disques durs physiques, puis
cliquez sur OK.
NOTE
Si vous ne trouvez pas le disque dans la liste Des disques durs physiques, vérifiez que l’état du disque est
hors connexion dans le logiciel en snap-in Gestion des disques.
d. Vérifiez que le disque est affiché sous Pilotes de disque de l’ordinateur virtuel. Vérifiez que le
disque est affiché dans l’onglet Dépendances de la boîte de dialogue propriétés de l’ordinateur
virtuel.
9. Dans le logiciel en snap-in Gestionnaire du cluster de failover, cliquez avec le bouton droit sur la VM,
puis cliquez sur Connecter .
10. Dans le logiciel en ligne gestion des disques, vérifiez que le disque est ajouté et que l’état du disque
est hors connexion.
11. Cliquez avec le bouton droit sur le nom du disque, puis cliquez sur En ligne pour mettre le disque en
ligne.
NOTE
Il se peut que vous trouviez que l’état du disque est En lecture seule.
Résoudre le problème d’état du disque en lecture seule

Pour résoudre le problème d’état du disque en lecture seule dans l’ordinateur virtuel, suivez les étapes
suivantes :
1. Ouvrez une invite de commandes sur l’ordinateur virtuel, tapez la commande, puis appuyez sur Entrée pour
arrêter le service de disque virtuel net stop vds (VDS).
2. À l’invite de commandes sur l’machine vm, tapez la commande, puis appuyez sur net start vds Entrée pour
redémarrer VDS.
3. Ouvrez le logiciel en snap-in Gestion des disques et vérifiez l’état du disque. Si l’état du disque est toujours
en lecture seule, redémarrez l’ordinateur virtuel.
Les volumes partagés de cluster répliqués sont hors
connexion après une mise à niveau HCI azure Stack
Cet article fournit des méthodes pour démarrer le service StorageReplica après une mise à niveau de
l’infrastructure hyperconverged (HCI) Azure Stack.
Résumé
Après avoir mis à niveau un cluster étendu à partir d’Azure Stack HCI, version 20H2 vers la version 21H2, tous
les volumes partagés de cluster répliqués sont hors connexion.
En outre, l’ID d’événement 7001 est enregistré dans l’Observateur d’événements.
Event ID: 7001

Event Details: The StorageReplica service depends on the LanmanWorkstation service which failed to start
because of the following error:
The service cannot be started, either because it is disabled or because it has no enabled devices associated
with it.
Le démarrage du service StorageReplica échoue

Ce problème se produit car le démarrage du service StorageReplica échoue. Le service StorageReplica dépend
du service LanmanWorkstation qui ne démarre pas. Après un certain temps, le service LanmanWorkstation est
démarré et en cours d’exécution. Toutefois, le service StorageReplica reste arrêté.
Redémarrer le serveur ou démarrer manuellement le service

StorageReplica
Pour résoudre ce problème, redémarrez le serveur ou démarrez manuellement le service StorageReplica.
NOTE
Ces méthodes ne sont requises qu’une seule fois sur chaque serveur après une mise à Cluster-Aware mise à jour (CAU).
Créer un script post-mise à jour pour éviter le problème

La mise à niveau de clusters étendus avec un script de post-mise à jour CAU est prise en charge à l’aide de
Windows PowerShell. Pour éviter ce problème, exécutez la cmdlet avec un script post-mise à jour Invoke-CauRun
lorsque vous mettez à niveau le cluster.
NOTE
La mise à niveau de clusters étendus à l’Windows’administration centrale n’est pas prise en charge.
1. Créez un script PowerShell (nommé Post_Update_Script.ps1) comme suit :

Get-Service "Storage Replica" | Stop-Service
sleep 20
Get-Service "Storage Replica" | Start-Service
sleep 20
2. Exécutez Invoke-CauRun la cmdlet avec le script post-mise à jour créé :
Invoke-CauRun -ClusterName <ServerName> -CauPluginName "Microsoft.RollingUpgradePlugin" -

CauPluginArguments @{'WuConnected'='true';} -Verbose -EnableFirewallRules -Force -PostUpdateScript
Post_Update_Script.ps1
Stratégie de support Microsoft pour les disques
durs de secteur 4K Windows
Cet article décrit les informations de support pour les lecteurs de grande taille (4K) lorsqu’ils sont utilisés avec
Windows et d’autres produits Microsoft.
S’applique à : Windows 10, version 1809, et versions ultérieures, Windows Server 2019, Windows 7 Service
Pack 1, Windows Server 2016, Windows Server 2012 R2
Résumé
Au cours des prochaines années, l’industrie du stockage de données va passer du format physique des disques
durs de secteurs de 512 byte à 4 096 secteurs d’byte (également appelés secteurs 4K ou 4K). Cette transition est
pilotée par plusieurs facteurs, notamment l’augmentation de la densité et de la fiabilité du stockage. Cette
transition entraîne des problèmes d’incompatibilité avec les logiciels existants (y compris les systèmes
d’exploitation et les applications).
Cet article décrit la stratégie de support Microsoft actuelle pour ces nouveaux types de Windows. Les
applications et les périphériques matériels peuvent avoir des problèmes de fiabilité et de performances
lorsqu’ils sont connectés à ces nouveaux types de lecteurs. Contactez vos fournisseurs d’applications et de
matériel pour obtenir leurs stratégies de support pour ces nouveaux types de disques.
Nous allons aborder trois types de disques ici. Étant donné que la stratégie de support Microsoft diffère pour
chacun d’eux, vous devez vérifier le type de lecteur que vous avez installé avant de lire plus en détail.
TA IL L E DE SEC T EUR TA IL L E DU SEC T EUR W IN DO W S VERSIO N AVEC

N O M S C O M M UN S LO GIQ UE SIGN A L ÉE P H Y SIQ UE SIGN A L ÉE P RISE EN C H A RGE
Natif de 512 byte, 512n 512 octets 512 octets Toutes les Windows
versions
TA IL L E DE SEC T EUR TA IL L E DU SEC T EUR W IN DO W S VERSIO N AVEC
N O M S C O M M UN S LO GIQ UE SIGN A L ÉE P H Y SIQ UE SIGN A L ÉE P RISE EN C H A RGE
Format avancé, 512e, AF, 512 octets 4 Ko Windows Vista avec mise à
émulation de 512 byte jour de la 2553708 mise à
jour
Windows Server 2008with

update KB 2553708
installed
Windows 7 with update KB

982018 installed

with update KB 982018
installed
Toutes Windows versions de

Windows 7 Server Pack 1 et
Toutes les versions server

de Server 2008 R2 Server
Pack 1 et versions
ultérieures.
*Sauf pour Hyper-V.

Consultez la section Sur la
prise en charge des
applications pour les
lecteurs de grande taille.
Format Avancé, AF, Natif 4 Ko 4 Ko Toutes Windows versions de

4K, 4Kn Windows 8 versions
ultérieures. Toutes les
versions de serveur de
Server 2012 et versions
ultérieures.
Autres Pas 4 Ko ou 512 octets Pas 4 Ko ou 512 octets Non pris en charge
Pour vérifier le type de lecteur dont vous avez besoin, suivez les étapes suivantes :
1. Installez les 982018 de la 982018.
2. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de élévation de
niveaux :
Fsutil fsinfo ntfsinfo x:
où x: représente le lecteur que vous vérifiez.

3. Utilisez les valeurs suivantes pour déterminer le type de lecteur dont vous avez.
Octets par secteur
Octets par secteur physique
Pour ce faire, utilisez le tableau suivant :
O C T ET S PA R VA L EUR SEC T EUR
VA L EUR O C T ET S PA R SEC T EUR P H Y SIQ UE T Y P E DE L EC T EUR
4096 4096 4K natif
512 4096 Format avancé (également appelé

512E)
512 512 Natif de 512 byte
Exigences spécifiques pour la prise en charge de Microsoft par version

du système d’exploitation
Windows 8, Windows Server 2012 versions ultérieures
La liste ci-dessous récapitule les nouvelles fonctionnalités Windows 8 et Windows Server 2012 pour
améliorer l’expérience client avec les disques de grande taille. Pour obtenir une description plus détaillée
de chaque élément, voir Mise à jour de compatibilité de disque au format avancé (4K).
S’appuie sur la Windows 7 SP1 pour les disques 4K avec émulation (512e). Il fournit également
une prise en charge complète de la boîte de réception pour les disques de taille de secteur 4K sans
émulation (4K natif). Voici quelques exemples d’applications et de scénarios pris en charge :
Possibilité d’installer Windows et de démarrer à partir d’un disque de secteur 4K sans
émulation (disque natif 4K)
Nouveau format de fichier VHDx
Prise en charge complète d’Hyper-V
Windows sauvegarde
Prise en charge complète avec le système de fichiers NT (NTFS)
Prise en charge complète avec le système de fichiers Résilient (ReFS)
Prise en charge complète avec espaces de stockage
Prise en charge complète avec Windows Defender
Prise en charge des applications de boîte de réception
Windows 7 and Windows Server 2008 R2
Installez le Service Pack 1 (SP1) ou installez la mise à jour 982018.
Assurez-vous que les pilotes et le microprogramme de votre contrôleur de stockage et d’autres
composants matériels sont mis à jour. Assurez-vous également que les lecteurs et
microprogrammes sont en charge des lecteurs de grande taille.
Utiliser l’environnement de préinstallation Windows (Windows PE) mis à jour pour SP1 qui sera
publié dans le cadre des éléments mis à jour du Supplément Kit d'installation automatisée
(Windows AIK) (AIK) pour Windows® 7 SP1 et de la préinstallation OEM Windows Kit (OPK). Ou
bien, incorporez la mise à jour 982018 dans Windows PE.
Conditions requises pour la prise en charge des applications pour les

lecteurs de grande taille
En plus de Windows prise en charge du système d’exploitation, les administrateurs et les utilisateurs doivent
s’assurer que leurs applications peuvent prendre en charge ces lecteurs grand secteur. Les scénarios et les
problèmes à prendre en compte incluent les performances, la fiabilité, la sauvegarde et la récupération. Les
instructions de support de certains produits et applications Microsoft sont les suivantes :
Hyper-V : utilisation d’Hyper-V avec des lecteurs de grande taille dans Windows Server 2008 et Windows
Server 2008 R2
SQL Server : SQL Server - Les nouveaux lecteurs utilisent une taille de secteur de 4K
Exchange Server : options Exchange Server configuration du stockage
Applications et matériels tiers : les applications et les périphériques matériels peuvent avoir des
problèmes de fiabilité et de performances lorsqu’ils sont connectés à ces nouveaux lecteurs. Contactez
vos fournisseurs d’applications et de matériel pour leur stratégie de support pour ces lecteurs.
Problèmes de compatibilité connus

Les problèmes de compatibilité connus qui peuvent se produire lorsque vous utilisez des lecteurs de grande
taille sont les suivants :
Si vos partitions Windows ont été créées à l’aide d’une version de Windows PE (ou du programme
d’installation Windows) basée sur une base de code Windows avant Windows Vista SP1 (y compris
Windows Vista RTM et toutes les versions de Windows XP), les partitions par défaut ne seront pas
alignées. Par conséquent, toutes les E/S émises sur le volume, même avec les correctifs (le cas échéant
pour votre plateforme), ne seront par nature pas alignées. Il est recommandé de créer les partitions à
l’aide d’une version PE Windows basée sur le codebase Windows Vista SP1 ou version plus récente.
Sur Windows 7 et Windows 2008 R2, l’installation échoue avec une erreur Windows Le programme
d’installation n’Windows pas pu configurer le matériel de cet ordinateur. Ce problème se produit dans
les conditions décrites dans l’article suivant :
« Windows le programme d’installation n’a pas pu configurer Windows sur le matériel de cet ordinateur
» sur un ordinateur Windows 7 ou Windows Server 2008 R2.
Si vous utilisez un lecteur de secteur logique d’une taille autre que 512 octets, les opérations Windows de
sauvegarde et de restauration d’image système peuvent échouer. Et vous recevez le message d’erreur
suivant :
L’un des fichiers de sauvegarde n’a pas pu être créé.

Détails : la demande n’a pas pu être effectuée en raison d’une erreur d’appareil d’I/S.
Code d’erreur : 0x8078002A
Si vous créez un disque dur virtuel (VHD) sur un lecteur secteur 4K natif à l’aide de gestion des disques
ou d’Hyper-V dans Windows Server 2008 R2, l’opération échoue avec une erreur De fonction incorrecte.
Dans Gestion des disques, le message d’erreur suivant est généré :
Fonction du Gestionnaire de disque virtuel incorrecte
Dans Hyper-V, le message d’erreur suivant est généré lorsque l’Assistant Nouveau disque dur
virtuel est utilisé :
Le serveur a rencontré une erreur lors de la tentative de création du disque dur virtuel. Le
système n’a pas réussi à créer « I:\Disk0.vhd ». Code d’erreur : fonction incorrecte.
Dans Hyper-V, le message d’erreur suivant est généré lorsque l’Assistant Nouvelle machine
virtuelle est utilisé :
Le serveur a rencontré une erreur lors de la configuration du disque dur sur TestVM. Le
système n’a pas réussi à créer « I:\TestVM\TestVM.vhd ». Code d’erreur : fonction incorrecte.
Si fsutil.exe <Not Suppor ted> continue d’afficher les octets par secteur physique : après avoir appliqué
le dernier pilote de stockage et les correctifs requis, assurez-vous que le chemin de Registre suivant existe
:
Emplacement :
HKEY_LOCAL_MACHINE\CurrentControlSet\Services\<miniport's service name>\Parameters\Device\
Nom : EnableQueryAccessAlignment
Type : REG_DWORD
Valeur : 1 : Activer
Scénarios non pris en charge

Si votre périphérique de stockage et votre système d’exploitation sont signalés comme non pris en charge, le
support Microsoft propose des conseils de dépannage si le client les demande. Microsoft ne garantit pas qu’une
résolution sera trouvée pour les problèmes qui impliquent des périphériques de stockage non pris en compte. Si
aucune résolution n’est trouvée, le coût d’investigation de l’incident n’est pas remboursé. S’il n’est pas d’accord
qu’une solution n’est pas garantie, le support Microsoft ne sera pas en train de résoudre le problème et
remboursementa le coût d’investigation de l’incident.
Le support Microsoft utilisera des processus de dépannage standard pour isoler le problème de stockage. Voici
quelques méthodes de dépannage classiques que le Support Microsoft utilisera :
Consultation de la Base de connaissances Microsoft. La Base de connaissances Microsoft est disponible
pour les clients via le Support Microsoft.
Déterminer si le problème peut être répliqué sur le stockage pris en charge (lorsque cela est possible).
NOTE
Si le stockage n’est pas pris en charge, aucune prise en charge des correctifs n’est disponible. Le support Microsoft
ne peut pas déterminer si le problème est dû à une incompatibilité matérielle ou à un comportement logiciel
indésirable.
S’il n’existe aucune solution au problème, le support Microsoft peut recommander quelques solutions,
notamment :
Demander au client de reproduire le problème sur un appareil de stockage pris en charge
Demander au client de travailler avec le fournisseur de stockage pour une solution
Erreur « Périphérique USB non reconnu » lorsque
vous essayez d’accéder à un disque dur USB
externe.
Cet article fournit des méthodes pour résoudre l’erreur Périphérique USB non reconnu qui se produit
lorsque vous essayez d’accéder à un disque dur USB externe.
Symptômes
Lorsque vous essayez d’accéder à des données sur un disque dur externe USB, le message d’erreur suivant peut
s’afficher :
Périphérique USB non reconnu : l’un des périphériques reliés à cet ordinateur a mal fonctionné et Windows
ne le reconnaît pas.
S ʼapplique à : Windows 10 version 1709, Windows 7 Service Pack 1

Cause
Ce problème peut se produire dans l’une des situations suivantes :
Le pilote USB actuellement chargé est instable ou endommagé.
Votre PC nécessite une mise à jour pour des problèmes de conflit entre un disque dur USB externe et
Windows.
D’autres mises à jour importantes de Windows concernant des problèmes matériels ou logiciels ne sont pas
installées.
Vos contrôleurs USB sont instables ou endommagés.
Votre lecteur externe est passé en suspension sélective.
La carte mère de votre PC nécessite des pilotes mis à jour.
Résolution 1 - Désinstaller puis rebrancher le disque dur externe

Cette méthode permet de résoudre des problèmes lorsque le pilote USB actuellement chargé est devenu
instable ou endommagé.
1. Sélectionnez Démarrer , puis tapez Gestionnaire de périphériques dans la zone Rechercher .
2. Sélectionnez Gestionnaire de périphériques dans la liste des résultats.
3. Sélectionnez Lecteurs de disque dans la liste des composants matériels.
4. Appuyez longuement (ou cliquez avec le bouton droit) sur le disque dur USB externe concerné par le
problème, puis sélectionnez Désinstaller.
5. Une fois le disque dur désinstallé, débranchez le câble USB.
6. Attendez 1 minute, puis rebranchez le câble USB. Le pilote devrait se charger automatiquement.
7. Vérifiez la présence du disque USB dans l’Explorateur Windows.
NOTE
Si vous connectez votre disque dur USB externe sur un concentrateur USB non alimenté, le courant nécessaire au
fonctionnement du disque externe risque d’être insuffisant. Branchez-le plutôt directement sur votre ordinateur.
Si cette méthode ne résout pas votre problème, passez à la résolution 2.
Résolution 2 - Installer des correctifs logiciels pour résoudre des

problèmes présents sous Windows 7
Les correctifs logiciels présentés dans cette méthode permettent de résoudre un conflit connu entre un disque
dur externe USB et Windows.
1. Accédez à l’article KB976972 suivant de la Base de connaissances : Vous pouvez rencontrer des
problèmes lorsque vous déplacez des données sur un périphérique USB à partir d’un ordinateur sous
Windows 7 doté d’un chipset NVIDIA USB EHCI et d’au moins 4 Go de RAM.
2. Sous Informations sur la mise à jour, sélectionnez le lien Télécharger le package de mise à jour
maintenant correspondant à votre version de Windows 7.
a. Si vous avez des doutes concernant votre version de Windows 7, sélectionnez le bouton Démarrer ,
appuyez longuement (ou cliquez avec le bouton droit) sur Ordinateur > Propriétés .
Si la mention « Système d’exploitation 64 bits » figure en regard de Type du système, vous
utilisez la version 64 bits de Windows 7.
Si la mention « Système d’exploitation 32 bits » figure en regard de Type du système, vous
utilisez la version 32 bits (x86) de Windows 7.
3. Cliquez sur Continuer . Si une autorisation de contrôle de compte d’utilisateur s’affiche, sélectionnez Oui .
4. Sélectionnez Télécharger > Ouvrir .
5. Le téléchargement devrait démarrer dans les 30 secondes. Si ce n’est pas le cas, sélectionnez Démarrer
le téléchargement > Ouvrir .
6. Suivez les instructions affichées à l’écran pour exécuter le téléchargement et l’installation.
7. Accédez à l’article KB974476 suivant de la Base de connaissances : L’ordinateur cesse de répondre
lorsqu’un périphérique USB quitte l’état de suspension sélective USB dans Windows 7.
8. Sélectionnez Afficher et demander les téléchargements de correctifs > Sélectionner le correctif.
9. Lisez le contrat de licence. Si vous acceptez les conditions, sélectionnez J’accepte .
10. Activez la case à cocher en regard de votre version de Windows 7, puis entrez votre adresse e-mail dans
les zones du dessous.
11. Entrez la vérification, puis sélectionnez Demande de correctif .
12. Consultez vos messages électroniques. Vous recevez rapidement un e-mail de Microsoft contenant un
lien de téléchargement pour le correctif. Sélectionnez ce lien, puis suivez les instructions affichées à
l’écran pour télécharger et installer le correctif logiciel.
Si le problème persiste, passez à la résolution 3.
Résolution 3 - Installer les dernières mises à jour de Windows

Cette méthode permet d’installer les derniers pilotes de périphérique pour votre disque dur externe USB.
1. Sélectionnez le bouton Démarrer , tapez Windows Update dans la zone de recherche , puis
sélectionnez Windows Update dans la liste de résultats.
2. Sélectionnez Rechercher des mises à jour . Une fois la recherche terminée, sélectionnez Vérifier les
mises à jour facultatives .
3. Activez la case à cocher en regard des mises à jour, puis sélectionnez Installer les mises à jour .
4. Lisez le contrat de licence, puis sélectionnez J’accepte .
5. Suivez les instructions affichées à l’écran pour télécharger et installer les mises à jour.
6. Si nécessaire, redémarrez votre ordinateur.
Résolution 4 - Réinstaller les contrôleurs USB

Cette méthode permet de résoudre des problèmes lorsque le pilote USB actuellement chargé est devenu
instable ou endommagé.
1. Sélectionnez Démarrer , tapez Gestionnaire de périphériques dans la zone de recherche , puis sélectionnez
Gestionnaire de périphériques .
2. Développez Contrôleurs de bus USB. Appuyez longuement (ou cliquez avec le bouton droit) sur un
périphérique, puis sélectionnez Désinstaller. Répétez cette étape pour chaque périphérique.
3. Dès que vous avez terminé, redémarrez votre ordinateur. Vos contrôleurs USB s’installent automatiquement.
Résolution 5 - Désactiver le paramètre de suspension sélective USB

Cette méthode empêche le lecteur externe USB de s’éteindre.
1. Sélectionnez le bouton Démarrer , tapez mode de gestion d’alimentation dans la zone de recherche , puis
sélectionnez Choisir un mode de gestion d’alimentation .
2. En regard du mode actuellement sélectionné, sélectionnez Modifier les paramètres du mode .
3. Sélectionnez Modifier les paramètres d’alimentation avancés .
4. Développez Paramètres USB > Paramètre de la suspension sélective USB .
5. Sélectionnez Sur secteur , sélectionnez le menu déroulant, puis sélectionnez Désactivée .
6. Si vous utilisez un ordinateur portable, sélectionnez Sur batterie , sélectionnez le menu déroulant, puis
sélectionnez Désactivée .
7. Sélectionnez Appliquer > OK .
Résolution 6 - Installer les derniers pilotes de circuit microprogrammé

pour votre carte mère
Cette méthode permet de mettre à jour les pilotes de circuit microprogrammé de votre carte mère afin que
votre ordinateur puisse reconnaître votre disque dur externe USB.
1. Consultez la documentation de l’ordinateur, qui devrait mentionner le nom du fabricant de la carte mère.
2. Visitez le site web de support du fabricant de votre ordinateur. Pour obtenir une liste de sites de support de
fabricants informatiques, consultez la page Coordonnées des fabricants et fournisseurs d’ordinateurs.
3. Recherchez les pilotes appropriés pour votre carte mère sur le site web du fabricant. Pour obtenir de l’aide,
contactez le fabricant de votre ordinateur.
Si le problème persiste, nous vous recommandons de contacter le support technique Microsoft.
Pour plus d'informations, voir Windows Update.
Comment étendre des espaces de stockage à
plusieurs niveaux autonomes
Cet article explique comment étendre des espaces de stockage à plusieurs niveaux autonomes.
L’article suivant explique comment développer des espaces de stockage à plusieurs niveaux sur un serveur
autonome. Voici un exemple d’espace à plusieurs niveaux créé avec une taille de 12,1 To Windows Server 2016.
Voici comment étendre l’espace Stockage niveaux :

1. Ajoutez des disques durs au pool de stockage.
2. Mettez à jour le type de média du nouveau disque ajouté.

3. Exécutez get-physicaldisk | fl * l’cmdlet et copiez l’UniqueId du disque nouvellement ajouté :
4. Exécutez l’cmdlet suivante pour modifier le type de média du disque nouvellement ajouté :
Set-PhysicalDisk -UniqueId 6002 -MediaType HDD
Actualisez le Gestionnaire de serveur pour modifier le type de média.

5. Exécutez cette cmdlet pour développer le disque :
Resize-StorageTier -FriendlyName Vdisk01_Microsoft_HDD_Template -size 16.1TB
6. Resize the disk volume in the Disk Management .
7. Le stockage a été étendu.

Comment restaurer une installation Windows 7
Cet article explique comment créer une sauvegarde de l’état système sur un ordinateur et comment la restaurer
sur le même ordinateur ou sur un autre ordinateur physique de la même création et du même modèle.
Résumé
L’un des problèmes suivants peut se produire avec votre ordinateur :
Défaillance matérielle
Défaillance logicielle
Vol d’ordinateur
une catastrophe naturelle.
Erreur de l’utilisateur
Pour récupérer de l’un de ces problèmes, vous pouvez restaurer le système d’exploitation Microsoft Windows à
partir d’une sauvegarde de l’état du système. Vous pouvez restaurer une sauvegarde d’état système sur le
même ordinateur physique à partir duquel la sauvegarde d’état système a été créée, ou sur un autre ordinateur
physique qui a la même création, le même modèle et la même configuration (matériel identique).
Toutefois, la restauration d’une sauvegarde de l’état du système d’un ordinateur vers un second ordinateur
d’une autre configuration matérielle, de modèle ou de make ne est pas prise en charge. Nous fournissons
uniquement des efforts commerciaux raisonnables pour prendre en charge ce processus. Même si les
ordinateurs source et de destination semblent être des ordinateurs et des modèles identiques, les ordinateurs
sources peuvent avoir des pilotes, du matériel ou des microprogrammes différents des ordinateurs de
destination.
Méthode préférée pour restaurer Windows 7

Pour restaurer Windows ordinateurs basés sur 7, la méthode préférée est une restauration complète du
système. Plus précisément, sans utiliser la fonction de restauration automatique, vous pouvez effectuer une
restauration complète (BMR) pour rétablir les volumes de démarrage mis en forme et les volumes système sur
le serveur à partir de quel serveur la sauvegarde d’origine a été effectuée. Dans ce cas, les dispositions de
volume et les identificateurs sont identiques à ceux utilisés lors de la sauvegarde de l’ordinateur d’origine. En
outre, vous pouvez effectuer une bmr qui utilise la asr sur un ordinateur dont le matériel est différent de celui de
l’ordinateur d’origine.
NOTE
Les bmrs ne peuvent être effectués que lorsque le système est hors connexion.
L’ordinateur cible en cours de restauration et l’ordinateur de destination qui reçoit la restauration doivent être basés sur
l’interface UEFI (Unified Extensible Firmware Interface) ou le BIOS. Vous ne pouvez pas combiner les deux dans un scénario
BMR.
Scénarios de récupération possibles pour Windows 7

Scénario de serveur non redémarrable/migration de serveur (planifié et non planifié)
Dans ce scénario, vous pouvez protéger le serveur en faisant une sauvegarde BMR de tous les volumes
critiques sur le serveur. Vous récupérez ensuite le serveur en faisant une récupération BMR via Windows
Recovery. Dans ce scénario, bmr est pris en charge sur différents matériels.
Scénario de dysfonctionnement du serveur (amorçable) ou de la récupération des rôles serveur
Dans ce scénario, vous pouvez protéger le serveur en faisant une sauvegarde de l’état du système ou une
sauvegarde BMR. Vous pouvez ensuite récupérer le serveur en faisant une récupération d’état du
système à partir du système d’exploitation démarré.
Le tableau suivant décrit les scénarios de récupération système pris en charge et non pris en charge.
SC ÉN A RIO P RIS EN C H A RGE
Récupération d’état du système après la restauration de Oui

BMR/Full Server sur le même matériel
Récupération d’état du système après la restauration de Non

BMR/Full Server sur un autre matériel
Récupération d’état du système après la restauration Non

complète du serveur (sans BMR) sur le même matériel ou
sur un matériel différent
NOTE
Windows sauvegarde du serveur garantit que le système démarre correctement après le processus de restauration BMR.
Les applications/rôles qui s’appuient sur des identificateurs spécifiques au matériel tels que l’adresse de la NIC, etc.,
peuvent nécessiter une reconfiguration ou une récupération supplémentaire pour les rendre fonctionnels.
Recommandations en matière de restauration du Windows

d’exploitation 7
Suivez les instructions des sections suivantes pour vous assurer que l’opération de restauration réussit.
Couche d’abstraction matérielle
Les ordinateurs source et de destination doivent utiliser le même type de couche d’abstraction matérielle (HAL).
Il existe une exception à cette règle. Si l’un des ordinateurs contient la hal multiprocesseur ACPI (Advanced
Configuration and Power Interface), l’autre ordinateur peut en avoir un. La même règle s’applique aux haLs à
processeur multiple MPS et MPS uniprocesseur.
Par exemple, si la source utilise l’hal multiprocesseur MPS, vous pouvez restaurer les données sur un ordinateur
de destination qui utilise l’hal uniprocesseur MPS. Toutefois, vous ne pouvez pas restaurer les données sur un
ordinateur de destination qui utilise l’outil HAL multiprocesseur ACPI.
NOTE
Si le hal de l’ordinateur de destination est compatible, mais pas identique, au hal de l’ordinateur source, vous devez mettre
à jour le hal sur l’ordinateur de destination après avoir terminé la restauration. Par exemple, si l’ordinateur source dispose
d’un seul processeur et utilise la hal de l’uniprocesseur ACPI, vous pouvez restaurer une sauvegarde à partir de cet
ordinateur sur un ordinateur de destination multiprocesseur. Toutefois, l’ordinateur de destination n’utilisera pas plus d’un
processeur tant que vous n’aurez pas mis à jour le hal vers un HAL multiprocesseur ACPI.
Pour déterminer le type d’hal de l’ordinateur que vous utilisez sur chaque ordinateur, suivez les étapes suivantes
:
1. Sélectionnez Démarrer , pointez Paramètres , sélectionnez Panneau de contrôle, puis Sélectionnez
Système .
2. Sous l’onglet Matériel, sélectionnez Gestionnaire de périphériques, puis développez la branche
Ordinateur.
Ordinateur multiprocesseur ACPI = Halmacpi.dll
ORDINATEUR ACPI uniprocesseur = Halaacpi.dll
Ordinateur ACPI (Advanced Configuration and Power Interface) = Halacpi.dll
Ordinateur multiprocesseur MPS = Halmps.dll
Ordinateur uniprocesseur MPS Halapic.dll ordinateur standard = Hal.dll
Compfon SystemPro multiprocesseur ou compatible à 100 % = Halsp.dll
Version du système d'exploitation
Les ordinateurs source et de destination doivent utiliser des versions identiques du système d’exploitation et des
unités Windows stock-keeping (SSO) identiques. Par exemple, vous ne pouvez pas Windows 2000 Server, puis le
restaurer sur un ordinateur exécutant Windows 2000 Advanced Server. En outre, les ordinateurs source et de
destination doivent utiliser les versions commerciales de Windows ou la même version OEM de Windows. La
meilleure pratique consiste à installer Windows sur l’ordinateur de destination à l’aide du même support
d’installation que celui que vous avez utilisé pour installer Windows sur l’ordinateur source.
Pilotes de filtre
Désinstallez les pilotes de filtre tiers sur l’ordinateur source avant d’utiliser la sauvegarde. Ces types de pilotes
peuvent entraîner des problèmes lorsque la sauvegarde est restaurée sur un autre ordinateur.
Windows de dossier et de disque
L’ordinateur de destination doit utiliser la même lettre de lecteur logique (%systemdrive%) et le même chemin
d’accès (%systemroot%) que l’ordinateur source. Pour les contrôleurs de domaine, les emplacements de la base
de données du service d’annuaire Active Directory, des fichiers journaux Active Directory, de la base de données
FRS et des fichiers journaux FRS doivent également être identiques pour les ordinateurs source et de
destination. Par exemple, si les fichiers journaux de base de données Active Directory sur l’ordinateur source ont
été installés sur C:\WINNT\NTDS, l’ordinateur de destination doit également utiliser le chemin d’accès
C:\WINNT\NTDS.
Matériel
Si vous supprimez du matériel sur l’ordinateur de destination qui n’est pas requis pour terminer le processus de
restauration, vous augmentez la probabilité d’une opération de restauration réussie. Par exemple, supprimez ou
désactivez physiquement toutes les cartes réseau à l’exception d’une carte réseau. Installez ou activez les
adaptateurs supplémentaires après le redémarrage du système d’exploitation après l’opération de restauration.
Correctif et niveau de Service Pack
Par exemple, pour Windows 2 000 ordinateurs, les correctifs logiciels 810161 ou Windows 2000 Service Pack 4
doivent être installés sur l’ordinateur source avant de pouvoir les récupérer. Ces éléments doivent également
être installés sur l’ordinateur de destination avant de restaurer la sauvegarde. Windows Server 2003 et
Windows XP n’ont pas de correctifs logiciels ou de niveau service pack requis pour ce type d’opération de
restauration. Un utilisateur n’a pas besoin d’amener l’ordinateur de destination au même service pack et niveau
de correctif logiciel pour Windows Server 2003 ou pour Windows XP. Toutefois, pour restaurer un ordinateur
Windows Server 2003 SP1, vous devez restaurer l’ordinateur de destination vers Windows Server 2003 SP1.
Problèmes possibles et étapes à suivre pour résoudre les problèmes

Après avoir redémarré l’ordinateur de destination, vous pouvez être aux états suivants :
Vous recevez l’un des messages d’erreur d’arrêt suivants :
Arrêter 0x0000007B Inaccessible_Boot_Device

STOP : 0x00000079 Hal_Mismatch
L’ordinateur cesse de répondre au démarrage.

L’ordinateur redémarre automatiquement lorsque vous recevez le message Windows 2000 sur un écran noir
au début du processus de redémarrage.
Vous ne pouvez pas configurer vos paramètres d’affichage.
La carte réseau ne fonctionne pas correctement.
Pour résoudre les problèmes avec les paramètres d’affichage ou avec une carte réseau, supprimez la carte
graphique ou la carte réseau du Gestionnaire de périphériques, puis redémarrez l’ordinateur. Windows détectera
à nouveau l’appareil et vous invitera éventuellement à utiliser des pilotes.
Pour résoudre l’erreur d’arrêt ou le problème où un ordinateur cesse de répondre, faites une mise à niveau sur
place de Windows.
Après avoir terminé la mise à niveau sur place, ClientProtocols vérifiez que la sous-clé de Registre existe et
qu’elle est remplie correctement. Pour ce faire, procédez comme suit :
2. Recherchez, puis cliquez avec le bouton droit sur la sous-clé de Registre suivante. Vérifiez que les valeurs
de la liste suivante existent : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ClientProtocols
N O M DE L A VA L EUR T Y P E DE VA L EUR DO N N ÉES DE L A VA L EUR
ncacn_nb_tcp REG_SZ rpcrt4.dll
3. Si la ClientProtocols sous-clé est manquante, ajoutez-la sous la Rpc sous-clé.

4. Si des valeurs sont manquantes dans la ClientProtocols sous-clé, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur ClientProtocols , pointez sur Nouveau , puis sélectionnez Valeur
de chaîne .
b. Tapez le nom de valeur de l’entrée manquante, puis appuyez sur Entrée.
c. Cliquez avec le bouton droit sur le nom de la valeur que vous avez tapé à l’étape b, puis sélectionnez
Modifier .
d. Tapez les données de valeur appropriées pour le nom de la valeur que vous avez tapé à l’étape b, puis
sélectionnez OK .
5. Répétez l’étape 4 pour chaque valeur manquante dans la ClientProtocols sous-clé.
6. Redémarrez l’ordinateur si des modifications du Registre ont été apportées.
NOTE
Si l’ordinateur source Windows été mis à niveau à partir de NT 4.0, les profils utilisateur peuvent être stockés dans le
dossier %systemroot%\Profiles au lieu du dossier %systemdrive%\Documents et Paramètres. Après avoir effectué une
mise à niveau sur place, vous de devez peut-être revenir à la valeur de Registre suivante en %systemroot%\Profiles .
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
N O M D E L A VA L E U R R É P E R TO I R E D E P R O F I L S
Type de valeur REG_EXPAND_SZ
Données de la valeur %systemroot%\Profiles

Windows La sauvegarde du serveur peut échouer
en raison de l’SQL Server du rédacteur VSS
Cet article fournit une solution à un problème dans lequel la sauvegarde de Microsoft Windows Server échoue
avec une erreur : une opération de service de shadow copy en volume a échoué.
Symptômes
Une sauvegarde du serveur peut échouer avec le message d’erreur suivant :
Échec d’une opération de service de copie de l’ombre du volume. Erreur détaillée : l’opération de copie de
l’ombre du volume a échoué avec une erreur 0x800423F4. Pour plus d’informations, consultez le journal des
événements.
Le message d’erreur suivant est enregistré dans le journal des événements de l’application :
Log Name: Application

Source: Microsoft-Windows-Backup
Event ID: 521
Level: Error
Description:
Backup started at '*\<DateTime>*' failed as Volume Shadow copy operation failed for backup volumes with
following error code '2155348129'. Please rerun backup once issue is resolved.
Si vous examinez davantage le journal des événements de l’application, vous remarquerez de nombreuses
erreurs provenant des sources SQLWriter et SQLVDI.
Les erreurs sont similaires à ce qui suit :

Source: SQLWRITER
Event ID: 24583
Level: Error
Description:
Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr = 0x80040e14. SQLSTATE: 42000,
Native Error: 3013
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 10.0
Error message: BACKUP DATABASE is terminating abnormally.
SQLSTATE: 42000, Native Error: 3271
Error message: A nonrecoverable I/O error occurred on file " {DF1DD65F-F8AD-4946-A764-F62166C541E2}22:"
995(The I/O operation has been aborted because of either a thread exit or an application request.).
Source: SQLVDI
Event ID: 1
Level: Error
Keywords: Classic
User: N/A
Computer: CONTOSOSERVER.contoso.local
Description:
SQLVDI: Loc=TriggerAbort. Desc=invoked. ErrorCode=(0). Process=3720. Thread=9404. Server.
Instance=SBSMonitoring. VD=Global{DF1DD65F-F8AD-4946-A764-F62166C541E2}10_SQLVDIMemoryName_0.
Cause
Lorsque Windows serveur de sauvegarde tente de sauvegarder un volume de disque, une capture instantanée
du cliché instantané du volume est créée pour le volume. Lorsque la capture instantanée est créée, tout
rédacteur VSS (Volume Shadow Copy Service) associé au volume est appelé. Si l’un des rédacteurs VSS
rencontre une erreur, l’intégralité du travail de sauvegarde échoue. Dans cet exemple, l’SQL vsS rencontre une
erreur et entraîne l’échec du travail de sauvegarde.
Résolution
L’erreur est généralement due à un problème avec l’une des SQL Server instances. Pour résoudre le problème,
vous devez d’abord déterminer la SQL Server instance qui a le problème. En règle générale, le SQL Server
instance problématique sera nommé dans la première erreur SQLVDI enregistrée.
Par exemple :

Source: SQLVDI
Event ID: 1
Level: Error
Description:
SQLVDI: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0). Process=4772. Thread=10300. Client.
Instance= SBSMONITORING . VD=Global{3AB8F080-950C-4EF9-B637-0F37B2428F17}1_SQLVDIMemoryName_0.
Dans cet exemple, l’instance SQL Server nommée SBSMONITORING échoue à la capture instantanée.
Il peut également y avoir un message d’erreur de la source SQLWRITER qui se produit à peu près en même
temps que la première erreur SQLVDI. Le message d’erreur SQLWRITER peut identifier le nom de la base de
données qui a un problème avec la capture instantanée.
Par exemple :

Source: SQLWRITER
Event ID: 24583
Description:
Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr = 0x80040e14. SQLSTATE: 42000,
Native Error: 3013
Error message: BACKUP DATABASE is terminating abnormally.
SQLSTATE: 42000, Native Error: 945
Error message: Database 'SBSMonitoring' cannot be opened due to inaccessible files or insufficient memory or
disk space. See the SQL Server errorlog for details.
Dans cet exemple, la base de données nommée SBSMonitoring a un problème.
Une fois que vous avez identifié l’instance SQL Server qui a un problème, la première étape consiste à tester la
sauvegarde avec cette instance SQL Server arrêtée. Dans notre exemple d’instance SBSMonitoring, vous
arrêteriez le ser vice SQL Ser ver (SBSMonitoring) sur le serveur.
Vous devez ensuite exécuter le travail de sauvegarde avec l’instance SQL Server’arrêt. Si la sauvegarde est
terminée, vous savez que l’échec est dû à l’SQL Server instance qui n’est pas en cours d’exécution. Examinez
ensuite les fichiers journaux d’erreurs SQL Server et les journaux d’événements pour voir si nous pouvons
déterminer ce qui ne va pas avec cette instance particulière de SQL Server.
Si vous ne pouvez pas déterminer l’instance de SQL Server problématique à partir des journaux des
événements, vous pouvez toujours arrêter toutes les instances SQL Server sur le serveur et essayer d’exécuter la
sauvegarde avec SQL arrêté. Si toutes les instances SQL Server sont arrêtées, le SQL vsS n’est pas utilisé.
Sur une installation par défaut de Small Business Server 2008, vous arrêtez les services suivants :
SQL Server (SBSMonitoring)
Base de données interne Windows
Sur une installation par défaut de Small Business Server 2011 Standard, vous arrêtez les services suivants :
SQL Server (SharePoint)
SQL Server (SBSMonitoring)
Base de données interne Windows
Échec de la sauvegarde avec l’ID d’événement VSS
12292 et 11 sur Windows Server
Cet article traite d’un problème dans lequel l’opération de sauvegarde à l’aide de Windows Server Backup ou
d’une application de sauvegarde tierce échoue.
Symptômes
Une opération de sauvegarde utilisant Windows Server Backup ou une application de sauvegarde tierce échoue
sur Windows Server.
Dans le journal des événements système, l’événement suivant est enregistré :

Source : Gestionnaire de contrôle des services
Niveau : Erreur
Description :
Le service microsoft Software Shadow Copy Provider s’est terminé par l’erreur suivante :
Dans le journal des événements de l’application, les événements suivants sont enregistrés :

Source : VSS
Niveau : Erreur
Description :
Erreur du service de copie de l’ombre du volume : erreur lors de la création de la classe COM du fournisseur
de copies de l’ombre avec CLSID {65ee1dba-8ff4-4a58-ac1c-3470ee2f376a} [0x80080005].
Opération :
Obtenir une interface appelant pour ce fournisseur
Obtention de l’interface de gestion des fournisseurs
Contexte :
ID de fournisseur : {b5946137-7b9f-4925-af80-51abd60b20d5}
ID de classe : {00000000-0000-0000-0000-000000000000}
Contexte de capture instantanée : -1
Source : VSS
Niveau : Erreur
Description :
Informations du service de copie de l’ombre en volume : le serveur COM avec CLSID {65ee1dba-8ff4-4a58-
ac1c-3470ee2f376a} et le nom SW_PROV ne peuvent pas être démarrés. Il est fort probable que l’UC soit
sous une charge élevée. [0x80080005]
Opération :
Obtenir une interface appelant pour ce fournisseur
Obtention de l’interface de gestion des fournisseurs
Contexte :
ID de classe : {00000000-0000-0000-0000-000000000000}
Contexte de capture instantanée : -1
Sur Windows Server 2008, si Windows Server Backup a été utilisé pour effectuer la sauvegarde, l’opération de
sauvegarde échoue avec l’une des erreurs suivantes :
Échec de la création du shadow copy sur l’emplacement de stockage.

ERROR - Erreur d’opération du service de copie de l’ombre du volume (0x8004230f)
Le fournisseur de copies de l’ombre a eu une erreur inattendue lors de la tentative de traitement de
l’opération spécifiée.
Ou
Échec de la création du shadow copy sur la destination de sauvegarde.

Échec de l’opération de copie de l’ombre du volume avec 0x8004230F.
Pour plus d’informations, consultez le journal des événements.
Sur Windows Server 2008 R2, si Windows Server Backup a été utilisé pour effectuer la sauvegarde, l’opération
de sauvegarde échoue avec l’une des erreurs suivantes :
Sauvegarde Windows pas réussi à créer le shadow copy sur l’emplacement de stockage.
Ou
Échec de la création du shadow copy sur la destination de stockage de sauvegarde.
Cause
Ce problème peut se produire si la valeur de Registre ServiceDll pour Swprv est manquante ou incorrecte.
Résolution
Pour résoudre ce problème, effectuez les étapes suivantes :
1. Cliquez sur Démarrer, tapez regedit dans la zone Démarrer la recherche, puis appuyez sur Entrée.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\swprv\Parameters
NOTE
Si la clé de Registre Parameters est manquante, effectuez les étapes suivantes : cliquez avec le bouton droit sur la
clé de Registre swprv, sélectionnez Nouveau, sélectionnez Clé, tapez Paramètres et appuyez sur Entrée.
3. Une fois la clé de Registre Parameters sélectionnée, vérifiez que la valeur de Registre ServiceDll a la
valeur suivante :
%Systemroot% \ System32 \swprv.dll
NOTE
Si la valeur de Registre ServiceDll est manquante, effectuez les étapes suivantes :
1. Cliquez avec le bouton droit sur la clé de Registre Paramètres, sélectionnez Nouveau, puis sélectionnez
Valeur de chaîne ex expandable.
2. Pour le nom de la valeur, tapez ServiceDll et touchez Entrée.
3. Double-cliquez sur la valeur de Registre Ser viceDll.
4. Dans la zone Données de la valeur, tapez %Systemroot% \ System32 \swprv.dll, puis cliquez sur OK .
4. Effectuez une opération de sauvegarde pour vérifier que le problème est résolu.
Erreur 0x8000FFFF lorsque vous exécutez la
commande des rédacteurs de liste vssadmin sur un
ordinateur Windows Server 2003
Cet article résout un problème qui se produit lorsque vous utilisez la commande sur un vssadmin list writers
ordinateur Windows Server 2003. Lorsque le problème se produit, vous pouvez recevoir un message d’erreur,
un événement ou la liste peut être vide.
Symptômes
Lorsque vous exécutez la commande vssadmin list writers sur un ordinateur Windows Server 2003, vous
pouvez présenter l’un des symptômes suivants.
NOTE
La vssadmin list writers commande répertorie les rédacteurs de copies de l’ombre du volume abonnés.
Erreur : 0x8000FFFF
L’événement suivant peut être consigné dans le journal des applications :

Source de l’événement : VSS
Description : Erreur du service de copie parallèle de volume : une incohérence interne a été détectée
lors de la tentative de contact des rédacteurs du service de copie de l’ombre. Vérifiez que le service
d’événements et le service de copie de l’ombre du volume fonctionnent correctement.
La liste est vide.
Cause
Ce problème peut se produire si la clé de Registre suivante est endommagée :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions
Résolution
IMPORTANT
Cet article n’est pas à utiliser avec Windows Vista, Windows Server 2008 ou les systèmes d’exploitation Windows
ultérieures. Depuis Windows Vista et Windows Server 2008, l’installation Windows composants est basée sur le manifeste.
Essayer d’inscrire manuellement des composants spécifiques, comme décrit dans les étapes suivantes, peut avoir des
résultats inattendus qui peuvent nécessiter la réinstallation Windows résoudre.

1. Cliquez sur Démarrer > l’exécuter, tapez Regedit, puis cliquez sur OK.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions
3. Dans le menu Modifier, cliquez sur Supprimer, puis sur Oui pour confirmer la suppression de la sous-
clé.
5. Cliquez sur > **Démarrer,**tapez services.msc, puis cliquez sur OK.
6. Cliquez avec le bouton droit sur les services suivants un par un. Pour chaque service, cliquez sur
Redémarrer :
Application système COM+
Fournisseur Microsoft Software Shadow Copy
7. Cliquez sur Démarrer > l’exécuter, tapez cmd, puis cliquez sur OK.
8. À l’invite de commandes, tapez les rédacteurs de liste vssadmin, puis appuyez sur Entrée.
9. Si les rédacteurs VSS sont maintenant répertoriés, fermez la fenêtre d’invite de commandes. Vous n’avez
pas besoin d’effectuer les étapes restantes.
Si les rédacteurs VSS ne sont pas répertoriés, tapez les commandes suivantes à l’invite de commandes.
Appuyez sur Entrée après chaque commande.
cd /d %windir%\system32
net stop vss
net stop swprv
regsvr32 ole32.dll
regsvr32 oleaut32.dll
regsvr32 /i eventcls.dll
regsvr32 vss_ps.dll
vssvc /register
regsvr32 /i swprv.dll
regsvr32 es.dll
regsvr32 stdprov.dll
regsvr32 vssui.dll
regsvr32 msxml.dll
regsvr32 msxml3.dll
regsvr32 msxml4.dll
NOTE
La dernière commande risque de ne pas s’exécuter correctement.
10. À l’invite de commandes, tapez les rédacteurs de liste vssadmin, puis appuyez sur Entrée.
11. Confirmez que les rédacteurs VSS sont désormais répertoriés.
Cela a-t-il corrigé le problème ?
Vérifiez si le problème est résolu. Si le problème est résolu, vous avez terminé avec cette section. Si le problème
n’est pas résolu, vous pouvez contacter le support technique.
Message d’erreur lorsque vous effectuez une
opération de restauration du service de copie
parallèle de volume : 0x80042409
Cet article décrit un problème qui se produit lorsque vous restituer une machine virtuelle alors qu’une autre
sauvegarde qui utilise le rédacteur Hyper-V est en cours.
Symptômes
Vous effectuez une sauvegarde VSS (Volume Shadow Copy Service) ou une opération de restauration VSS.
Pendant l’opération de sauvegarde ou de restauration, un événement semblable à ce qui suit est écrit dans le
journal des applications :
Erreur du service de copie de l’ombre du volume : erreur inattendue Un état de session de rédacteur plus
ancien est supprimé. . hr = 0x80042409, l’état rédacteur n’est pas disponible pour un ou plusieurs
rédacteurs. Un rédacteur a peut-être atteint la limite du nombre d’états de session de sauvegarde-
restauration disponibles.
Operation: PreRestore, événement
Contexte :
Ancien jeu de captures instantanées : {41379de8-f7e7-4c76-bb47-7f080443e189}
Ancienne opération : 1019
Ancien état : 5
Ancien échec : 0x800423f4
Ancienne heure d’échec étendu : 0x1
Ancien message d’échec étendu : 0
Contexte d’exécution : Rédacteur
ID de classe writer : {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Writer Name: Microsoft Hyper-V VSS
ID d’instance writer : {7eef8900-84b4-406e-a461-ce19e5e7ae7f}
Cause
Cette erreur se produit parce qu’un état de session de sauvegarde ou de restauration dans le rédacteur VSS n’est
pas nettoyé correctement. L’infrastructure de rédacteur VSS crée des objets d’état de session pour chaque
session de sauvegarde et de restauration à laquelle un rédacteur VSS participe. Dans des circonstances
classiques, les objets d’état de session du rédacteur sont nettoyés lorsqu’ils ne sont pas utilisés. Le nettoyage
normal de l’état de session se produit dans les circonstances suivantes :
L’application de sauvegarde envoie une réponse BackupComplete, puis vérifie l’état du rédacteur en
envoyant un GatherWriterStatus.
L’application de sauvegarde envoie une réponse PostRestore, puis vérifie l’état du rédacteur en envoyant
une requête GatherWriterStatus.
Les rédacteurs reçoivent le rappel d’événement OnAbort pour la session. Le rappel d’événement
OnAbort est appelé lorsque la session de sauvegarde est explicitement échouée par l’application de
sauvegarde, par le rédacteur ou par l’infrastructure VSS.
L’infrastructure du rédacteur VSS effectue un collecte périodique de la garbage collection des états de session
restants. L’infrastructure enregistre ensuite le journal des événements précédent pour chaque objet d’état de
session antérieur à deux jours. Le journal des événements est destiné à aider à identifier les sessions
abandonnées dans l’enregistreur qui peuvent indiquer une application de sauvegarde qui se comporte mal.
Vous pouvez voir plusieurs événements similaires en une succession rapide de plusieurs rédacteurs qui
indiquent qu’une série de sessions de sauvegarde ou de restauration ont été incomplètes. Ce comportement est
le plus souvent observé dans les environnements de test.
Ignorez les occurrences intermittentes de cette erreur. L’événement associé est consigné en réponse aux activités
de nettoyage de la garbage collection démarrées par une opération de sauvegarde ou de restauration. Toutefois,
ces erreurs ne sont pas liées à la session de sauvegarde ou de restauration active. Si l’erreur est reproductible de
façon cohérente, assurez-vous que le fournisseur de l’application de sauvegarde suit toutes les instructions de
nettoyage de session de sauvegarde VSS.
ID d’événement 513 lors de l’exécution de VSS dans
Windows Server
Cet article fournit une solution de contournement à l’ID d’événement 513 lors de l’exécution de VSS dans
Windows Server.
Symptômes
Dans Windows Server, lorsqu’une application appelle le service VSS (Volume Shadow Copy Service) pour
exécuter une sauvegarde, l’événement 513 peut être généré :

Source: Microsoft-Windows-CAPI2
Event ID: 513
Task Category: none
Level: Error
Description:
An error occurred in Cryptographic Services while processing the OnIdentity() call in System Writer Object.
Details:
AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol.
System Error:
Access is denied.
Cause
Ce problème se produit car le rédacteur système VSS n’est pas autorisé à lire le service NT AUTHORITY \
(compte de service). Lorsque le rédacteur système s’exécute en tant que service de chiffrement et tente de lire
les informations Mslldp.sys à partir d’un pilote du protocole de découverte de couche de liens Microsoft, l’erreur
« accès refusé » est générée.
Cette entrée du journal des événements peut être ignorée en toute sécurité. Pour empêcher la journalisation de
cette entrée, accordez l’autorisation requise au pilote microsoft Link-Layer Discovery Protocol (Mslldp.dll) pour
traiter l’auteur du système.
1. Ouvrez une fenêtre d’invite de commandes d’administration, puis exécutez la commande suivante pour
vérifier les autorisations actuelles :
sc sdshow mslldp
2. Copiez la chaîne de sortie de l’étape 1, ajoutez-la, puis exécutez la commande suivante pour ajouter
l’autorisation d’accès (A;;CCLCSWLOCRRC;;;SU) Mslldp.dll :
sc sdset mslldp <string>
Par exemple, exécutez la commande suivante :
sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)

(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-
2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)
Aucun rédacteur VSS n’est répertorié lorsque vous
exécutez des rédacteurs de liste vssadmin
Cet article fournit une solution au problème où aucun rédacteur VSS n’est répertorié lorsque vous exécutez des
rédacteurs de liste vssadmin.
Symptômes
Lorsque vous exécutez des rédacteurs de liste vssadmin sur Windows Server 2008, aucun rédacteur VSS n’est
répertorié.

Source : VSS
Niveau : Error
Description :
Erreur du service vss : la classe d’événement VSS n’est pas enregistrée. Cela empêche les rédacteurs VSS de
recevoir des événements. Cela peut être dû à un échec de l’installation ou à la suite d’un programme
d’installation ou d’une désinstallation d’une application.
Source : VSS
Niveau : Error
Description :
= 0x80040154.
Source : VSS
Niveau : Error
Description :
Informations sur le service de copie de l’ombre du volume : serveur COM avec CLSID {faf53cc4-bd73-4e36-
83f1-2b23f46e513e} et nom
VSSEvent ne peut pas être démarré. [0x80070057]
Source : VSS
Niveau : Error
Description :
= 0x80070057.
Si vous ouvrez le Windows sauvegarde du serveur, l’erreur suivante se produit :
Une erreur fatale s’est produite lors d’une Windows de sauvegarde du serveur.
Détails de l’erreur :
Défaillance catastrophique.
Fermez Windows sauvegarde du serveur, puis redémarrez-la.
Cause
Ce problème se produit parce que le chemin d’accès du Registre Eventcls.dll est incorrect ou parce que le type de
données du Registre pour le paramètre TypeLib est incorrect.
Résolution
Pour résoudre ce problème, effectuez les étapes suivantes.
IMPORTANT
322756 comment restaurer le Registre dans Windows
1. Cliquez sur Démarrer, tapez regedit dans la zone Démarrer la recherche, puis appuyez sur Entrée.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\EventClasses\
{FAF53CC4-BD73-4E36-83F1-2B23F46E513E}-{00000000-0000-0000-0000-000000000000}-{00000000-0000-0000-0000-
000000000000}
3. Recherchez la valeur de Registre TypeLib.
NOTE
Le type de Registre de TypeLib doit être affiché comme REG_EXPAND_SZ . Si ce n’est pas le cas, vous devez supprimer
la clé, puis la recréer. Pour ce faire, suivez les deux étapes suivantes :
a. Sélectionnez la valeur de Registre TypeLib, puis supprimez-la.
b. Créez une nouvelle valeur de chaîne ex expandable, puis nommez-la TypeLib .
4. Double-cliquez sur la valeur de Registre TypeLib. Dans la zone Données de la valeur, tapez
%systemroot%\system32\EVENTCLS.DLL, puis cliquez sur OK.
5. Fermez Regedit.
6. Cliquez sur Démarrer, tapez services.msc dans la zone Démarrer la recherche, puis appuyez sur Entrée.
7. Cliquez avec le bouton droit sur les services suivants un par un, puis cliquez sur Redémarrer :
8. Fermez le logiciel en ligne Services.
9. Ouvrez une invite de commandes avec élévation de élévation de niveaux, tapez les rédacteurs de liste
vssadmin, puis touchez Entrée.
10. Vérifiez que les rédacteurs VSS sont désormais répertoriés.
Les copies de l’ombre sont supprimées sur Windows
Server lorsque vous essayez d’exécuter un travail de
classification FCI
Cet article décrit un problème dans lequel les copies de l’ombre sont supprimées sur Windows Server lorsque
vous essayez d’exécuter un travail de classification FCI. Cela se produit lorsqu’il n’y a pas suffisamment d’espace
sur le volume pour les copies d’ombre.
Symptômes
Sur un ordinateur Windows Server, vous avez un volume sur lequel vous avez activé les copies de l’ombre via un
fournisseur VSS (Volume Shadow Copy). Sur ce volume, vous exécutez un travail de classification de
l’infrastructure de classification des fichiers (FCI). Toutefois, le travail de classification ne se termine pas et les
anciennes copies de l’ombre sont supprimées plus rapidement que prévu de l’espace de stockage des copies
d’ombres. Cela peut entraîner la suppression de tous les copies d’ombre du volume. En outre, plusieurs entrées
semblables à ce qui suit peuvent être enregistrées dans le journal système :
Le plus ancien shadow copy de volume Volume_Letter : a été supprimé pour conserver l’utilisation de
l’espace disque pour les copies d’ombre du volume Volume_Letter : en dessous de la limite définie par
l’utilisateur.
En outre, les entrées qui ressemblent à ce qui suit sont enregistrées dans le journal FSRM :
Warning DD / MM / YYYY hh :mm :ss AM_PM SRMSVC 12310 None

Shadow copy ' \ \ ? \ GlobalROOT \ Device \ HarddiskVolumeShadowCopy_File_Name ' a été supprimé
lors de la génération du rapport de stockage. Le volume « Volume_Letter : » peut être configuré avec une
zone de stockage de copie de l’ombre insuffisante. Stockage rapports peuvent être temporairement
indisponibles pour ce volume.
En outre, si vous exécutez un rapport de stockage FSRM, vous recevez le message d’erreur suivant :
Erreur : RunFileQueries, 0x8004532c, un shadow copy de volume n’a pas pu être créé ou a été supprimé de
façon inattendue.
Le Gestionnaire de ressources du serveur de fichiers a rencontré une erreur inattendue lors de l’analyse en
volume des volumes montés à ' \ \ ? \ Volume{Volume_PID} ' \ ('Volume_Letter :'). Pour plus d’informations
sur la cause première de cette erreur, consultez le journal des événements application/système pour les
autres erreurs FSRM, VSS ou VOLSNAP liées à ces volumes. En outre, vous pouvez vous assurer que vous
pouvez créer des copies d’ombre sur ces volumes à l’aide de la commande VSSADMIN comme celle-ci :
VSSADMIN CREATE SHADOW /For=Volume_Letter :
Erreur lors de la génération du travail de rapport avec le nom de la tâche « Task_name ».
Une fois que vous avez reçu ce message d’erreur, vous constatez que le message d’erreur suivant est consigné
dans le journal système :
Exception rencontrée = Défaillance catastrophique (exception de HRESULT : 0x8000FFFF (E_UNEXPECTED))
Cause
Ce problème se produit car le processus de classification des CI stocke les propriétés dans chaque fichier classé.
Ce comportement modifie le fichier sur le volume sur qui les copies d’ombre sont activées. Ces modifications
sont suivis par le fournisseur VSS et sont ensuite stockés dans la zone de stockage des copies de l’ombre.
Lorsqu’une propriété est stockée dans un fichier texte, seules quelques kilo-octets (Ko) de données sont écrites.
Toutefois, lorsque les propriétés sont stockées dans un Office, la totalité Office fichier est réécrite. Ce
comportement épuise l’espace de stockage VSS beaucoup plus rapidement.
Si l’allocation de la taille maximale Stockage de l’espace est insuffisante pour stocker toutes ces modifications,
VSS supprime d’abord les copies d’ombre les plus anciennes. Si un grand bloc de fichiers est classé, ce processus
peut échouer et supprimer en même temps tous les anciens copies de l’ombre de l’espace de stockage. Cela est
particulièrement vrai lorsque vous effectuez une classification complète sur un volume pour la première fois.
Cette action est très susceptible de générer de nombreuses modifications sur ce volume.
Résolution
Augmenter la taille de la zone de stockage
Avant d’exécuter une classification complète d’un volume pour la première fois, augmentez la taille maximale de
la zone de stockage. Pour cela, procédez comme suit :
1. Cliquez sur Démarrer, sur Tous les programmes, sur Accessoires, puis cliquez avec le bouton droit
sur Invite de commandes.
2. Cliquez sur Exécuter en tant qu’administrateur.
Si vous êtes invité à taper un mot de passe d’administrateur, tapez-le. Si vous êtes invité à confirmer,
cliquez sur Continuer.
vssadmin list shadowstorage /for=Volume_Letter:
4. Notez la valeur Maximum Shadow Copy Stockage Space.

vssadmin resize shadowstorage /for=Volume_Letter: /on=Volume_Letter: /maxsize=Storage_Size mb
Où l’espace réservé, Storage_Size , est une valeur qui est au moins le double de la valeur que vous avez
notée à l’étape 4.
Classification incrémentielle
Lorsque vous effectuez une classification pour la première fois, classifiez un seul espace de noms à la fois. Ne
classez pas tous les espaces de noms dans le même travail de classification.
Désactiver les copies de l’ombre
Vous pouvez désactiver les copies d’ombre sur le volume. Nous vous déconseillons de désactiver les copies
d’ombre sur le volume. Utilisez cette méthode uniquement si vous ne pouvez pas allouer plus de stockage pour
les copies d’ombre et que la méthode de classification incrémentielle dépasse toujours l’allocation de la zone de
stockage.
Pour désactiver les copies d’ombre pour un volume, suivez les étapes suivantes :
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Par tager et Stockage
gestion.
2. Dans le volet d’informations, cliquez sur l’onglet Volumes.
3. Cliquez avec le bouton droit sur le volume pour lequel vous souhaitez désactiver les copies d’ombre, puis
cliquez sur Propriétés.
4. Dans la boîte Volume_Name Propriétés, cliquez sur l’onglet Copies de l’ombre.
5. Cliquez sur Désactiver, puis sur Oui.
La sauvegarde de l’état du système à l’aide
Windows Server Backup échoue avec une erreur : le
rédacteur système est in trouvé dans la sauvegarde
Cet article fournit une solution à un problème dans lequel vous ne parviennent pas à effectuer une sauvegarde
de l’état du système à l’aide Windows sauvegarde du serveur.
Symptômes
Lorsque vous effectuez une sauvegarde de l’état du système à l’aide Windows Server Backup sur Windows
Server 2008, la sauvegarde échoue avec l’erreur suivante :
La sauvegarde de l’état du système a échoué [ <DateTime> ]

Journal des fichiers correctement backed up
'C:\Windows\Logs\WindowsServerBackup\SystemStateBackup <DateTime> .log'
Journal des fichiers pour lesquels la sauvegarde a échoué
'C:\Windows\Logs\WindowsServerBackup\SystemStateBackup_Error <DateTime> .log'
Le rédacteur système est in found in the backup.

Niveau : Error
Description :
La sauvegarde démarrée à ' ' a échoué avec le code d’erreur suivant « 2155348226 » (Le rédacteur système
est in trouvé <DateTime> dans la sauvegarde.) Veuillez réexécuter la sauvegarde une fois le problème
résolu.
Source : Microsoft-Windows-CAPI2
Niveau : Error
Description :
Les services de chiffrement ont échoué lors du traitement de l’appel OnIdentity() dans l’objet System Writer.
Détails :
AddCoreCsiFiles : BeginFileEnumeration() a échoué.
Erreur système :
Cause
Le rédacteur système échoue car les autorisations sur les fichiers dans %windir%\winsxs\filemaps\ le ou
%windir%\winsxs\temp\PendingRenames les répertoires sont incorrectes.
Résolution
Pour résoudre ce problème, tapez les commandes suivantes à partir d’une invite de commandes avec élévation
de niveau élevé :
Takeown /f %windir%\winsxs\temp\PendingRenames /a
icacls %windir%\winsxs\temp\PendingRenames /grant "NT AUTHORITY\SYSTEM:(RX)"
icacls %windir%\winsxs\temp\PendingRenames /grant "NT Service\trustedinstaller:(F)"
icacls %windir%\winsxs\temp\PendingRenames /grant BUILTIN\Users:(RX)
Takeown /f %windir%\winsxs\filemaps\* /a
icacls %windir%\winsxs\filemaps\*.* /grant "NT AUTHORITY\SYSTEM:(RX)"
icacls %windir%\winsxs\filemaps\*.* /grant "NT Service\trustedinstaller:(F)"
icacls %windir%\winsxs\filemaps\*.* /grant BUILTIN\Users:(RX)
net stop cryptsvc
net start cryptsvc
Tapez la commande suivante pour vérifier que le rédacteur système est désormais répertorié :
vssadmin list writers
Si l’enregistreur système est manquant, recherchez l’événement suivant dans le journal des événements de
l’application :

Source : VSS
Niveau : Error
Description :
Erreur du service de copie de l’ombre en volume : le processus qui héberge le rédacteur avec le nom
Rédacteur système et l’ID {e8132975-6f93-4464-a53e-1050253ae220} ne s’exécute pas sous un utilisateur
ayant des droits d’accès suffisants. Envisagez d’exécutez ce processus sous un compte local qui est le
système local, l’administrateur, le service réseau ou le service local.
Opération :
Initialisation du rédacteur
Contexte :
ID de classe writer : {e8132975-6f93-4464-a53e-1050253ae220}
Writer Name: System Writer
La section Détails de l’événement (Données binaires\Octets) s’affiche sous la forme :
0000 : 2D 20 43 6F 64 65 3A 20 - Code :
0008 : 57 52 54 57 52 54 49 43 WRTWRTIC
0010: 30 30 30 30 30 37 32 39 00000729
0018 : 2D 20 43 61 6C 6C 3A 20 - Appel :
0020: 57 52 54 57 52 54 49 43 WRTWRTIC
0028: 30 30 30 30 30 36 34 39 00000649
0030 : 2D 20 50 49 44 3A 20 20 - PID :
0038: 30 30 30 30 31 30 38 34 00001084
0040 : 2D 20 54 49 44 3A 20 20 - TID :
0048: 30 30 30 31 38 39 37 36 00018976
0050 : 2D 20 43 4D 44 3A 20 20 - CMD :
0058: 43 3A 5C 57 69 6E 64 6F C:\Windo
0060: 77 73 5C 73 79 73 74 65 ws\syste
0068 : 6D 33 32 5C 73 76 63 68 m32\svch
0070 : 6F 73 74 2E 65 78 65 20 ost.exe
0078: 2D 6B 20 4E 65 74 77 6F -k Netwo
0080: 72 6B 53 65 72 76 69 63 rkServic
0088: 65 20 20 20 20 20 20 20 e
0090 : 2D 20 55 73 65 72 3A 20 - Utilisateur :
0098: 4E 54 20 41 55 54 48 4F NT AUTHO
00a0 : 52 49 54 59 5C 4E 45 54 RITY\NET
00a8 : 57 4F 52 4B 20 53 45 52 WORK SER
00b0 : 56 49 43 45 20 20 20 20 VICE
00b8 : 2D 20 53 69 64 3A 20 20 - Sid :
00c0 : 53 2D 31 2D 35 2D 32 30 S-1-5-20
Ouvrez Regedit et accédez à la clé suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl .
Modifiez la valeur de NT AUTHORITY\NETWORK SERVICE (REG_DWORD) sur 1.
Vous pouvez également vérifier l’entrée d’autres services (LOCAL SERVICE, NetworkService) comme indiqué par
l’événement 8213.
Le rédacteur système doit maintenant s’afficher dans la vssadmin list writers commande :
Writer name: System Writer

ID du rédacteur : {e8132975-6f93-4464-a53e-1050253ae220}
ID d’instance du rédacteur : {04cf6316-f0c5-4ce7-bbe4-e56e6334124c}
État : [1] Stable
Dernière erreur : aucune erreur
Avertissements de sauvegarde tiers après
l’installation d’une mise à jour de maintenance dans
Windows Server 2016
Cet article fournit une solution aux avertissements de sauvegarde tiers qui se produisent après l’installation
d’une mise à jour de maintenance dans Windows Server 2016.
Symptôme
Sur un ordinateur qui exécute Windows Server 2016 (version 1607, build 14393.693), vous installez une
mise à jour de pile de maintenance. Par exemple, la mise à jour de la pile de maintenance du 14 mars
2017(4013418).
Le dossier C: Windows maintenance \ \ version \ \ 10.0.14393.1051 est automatiquement créé et les fichiers
amd64_installed et x86_installed sont enregistrés dans ce dossier.
Le dossier de version antérieure sous C: \ Windows \ maintenance est vidé. Par exemple, les fichiers suivants
sont supprimés :
C : \ Windows \ la version \ \ 10.0.14393.0 \ amd64_installed
C : \ Windows \ la version \ \ 10.0.14393.0 \ x86_installed
Vous diskshadow /l output.txt exécutez, puis list writers detailed à l’invite diskshadow.
Dans ce scénario, lorsque vous examinez les métadonnées de l’auteur système dans output.txt, vous trouvez que
les fichiers amd64_installed et x86_installed sont répertoriés dans l’ancien chemin d’accès du dossier de version
qui n’existe plus.
Par conséquent, les applications de sauvegarde tierces peuvent renvoyer des avertissements comme suit :
Date/TimeANS4251W System Writer ' \ \ ? \ globalroot \ device \ harddiskvolumeshadowcopy3 \ windows

servicing version \ \ \ 10.0.14393.0 \ amd64_installed': in found. Date/TimeANS4251W System Writer ' \ \ ?
\ globalroot \ device \ harddiskvolumeshadowcopy3 \ windows servicing version \ \ \
10.0.14393.0\x86_installed': in found.
Ce problème ne se produit pas avec Windows Server 2016 version RTM.
NOTE
Ce problème n’affecte pas la sauvegarde de l’état du système Windows sauvegarde du serveur.
Résolution
Pour résoudre le problème, créez de nouveaux fichiers d’espace réservé avec le même nom pour les fichiers
signalés comme in trouvés.
C : \ Windows \ la version \ \ 10.0.14393.0 \ amd64_installed
C : \ Windows \ la version \ \ 10.0.14393.0 \ x86_installed
Les fichiers ne sont plus nécessaires. Toutefois, ils sont toujours répertoriés comme des besoins de la backed up.
Le contenu du fichier n’est pas pertinent et peut être vide.
La mise en ligne des volumes de disque prend plus
de temps lorsque vous utilisez le service Volume
Shadow Copy sur des ordinateurs qui exécutent de
nombreuses opérations d’entreprise
Cet article décrit une solution de contournement pour un problème dans lequel les volumes de disque prennent
plus de temps à se mettre en ligne après l’activer sur les volumes.
IMPORTANT
et modify the registry, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft
:
Symptômes
Lorsque vous utilisez le service de copie de secours en volume sur des ordinateurs basés sur Windows Server
qui exécutent de nombreuses opérations d’entreprise et qui ont beaucoup de données, vous pouvez présenter
les symptômes suivants :
Le temps de failover de cluster est plus long pour les groupes de clusters qui contiennent des ressources
de disque pour lesquelles vous avez activé le service Volume Shadow Copy. En outre, la mise en ligne et
la mise hors connexion des volumes de disque des nodes de cluster prennent plus de temps lors d’un
failover de cluster. La mise hors connexion d’un disque, puis la mise en ligne sur le même nœud a
également le même délai.
Le démarrage des serveurs non-cluster prend plus de temps. Lorsque vous désactivez le service de copie
parallèle de volume sur les volumes du serveur, les serveurs démarrent comme prévu.
Cause
Ce problème se produit en raison de la façon dont le pilote volume shadow copy (Volsnap.sys) gère les fichiers
de shadow copy. Si de nombreux fichiers de copies de l’ombre sont créés sur les volumes de disque, le pilote
Volume Shadow Copy prend plus de temps pour traiter ces fichiers lorsque le système met les volumes de
disque en ligne.
WARNING
Pour contourner ce problème, créez une clé de Registre pour limiter à 20 le nombre de fichiers de shadow copy
créés sur chaque volume de disque.
NOTE
Cette valeur n’est qu’une valeur de départ suggérée. Nous vous recommandons de trouver une valeur adaptée à votre
environnement de travail.
Pour créer la clé de Registre, suivez les étapes suivantes :

1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez regedit, puis appuyez sur Entrée.
2. Recherchez la sous-clé de Registre suivante et cliquez dessus avec le bouton droit :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings
3. Pointez sur Nouveau, puis cliquez sur Valeur DWORD.
4. Tapez MaxShadowCopies, puis appuyez sur Entrée.
5. Double-cliquez sur MaxShadowCopies , tapez 20 dans la zone de données Valeur, puis cliquez sur OK .
L’ID d’événement VSS 8193 est enregistré lorsque
vous redémarrez le service services de chiffrement
après avoir installé le rôle DHCP sur un ordinateur
Cet article décrit un problème dans lequel vous recevez l’ID d’événement 8193 lorsque vous redémarrez le
service services de chiffrement si le rôle DHCP est installé.
Symptômes
Vous installez le rôle DHCP sur un ordinateur. Lorsque vous redémarrez le service services de chiffrement,
l’événement suivant est consigné dans le journal des applications :

Source : VSS
Date : Date/Heure
Niveau : Error
Utilisateur : N/A
Ordinateur :
Description :
Erreur du service vs. de volume : erreur inattendue appelant la routine RegOpenKeyExW(-
147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...). hr = 0x80070005, l’accès est refusé.
Opération :
Initialisation du rédacteur
Contexte :
ID de classe writer : {e8132975-6f93-4464-a53e-1050253ae220}
Writer Name: System Writer
ID d’instance writer : {7bb41431-3960-44bc-a29c-3b42d2301fc3}
NOTE
Bien que cet événement soit enregistré, volume Shadow Copy et DHCP Server continuent de fonctionner comme prévu.
Bien que cet événement soit consigné comme une erreur, il ne doit pas être considéré comme un échec critique qui affecte
le bon fonctionnement de VSS. La clé de Registre est mentionnée à des fins de diagnostic.
Cause
Lorsque le rôle serveur DHCP est installé, les autorisations de la clé de Registre suivante (et de toutes les sous-
clés) sont écrasées lorsque le compte de service DHCP est ajouté :
HKLM\CurrentControlSet\Services\VSS\Diag
Lorsque cela se produit, le compte service réseau est supprimé.

Chaque fois que le service de chiffrement est démarré, il initialise « Rédacteur système » sous le compte de
service réseau et vérifie l’autorisation de lecture/écriture pour la clé de Registre suivante :
HKLM\CurrentControlSet\Services\VSS\Diag
Étant donné que le compte service réseau est utilisé pour obtenir l’accès à cette clé, il n’existe aucune
autorisation pour le service réseau. Par conséquent, VSS enregistre un événement « Accès refusé ».
Résolution
Le copier-coller de volume et le serveur DHCP continuent de fonctionner comme prévu, vous pouvez donc
ignorer l’événement.
Si vous devez éviter l’événement, vous devez suivre les étapes suivantes :
1. Exécutez PowerShell en tant qu’administrateur.
2. Exécutez la commande suivante. Soyez prudent de ne pas inclure une nouvelle ligne au milieu de
$path = 'HKLM:\System\CurrentControlSet\Services\VSS\Diag\'
$sddl = 'D:PAI(A;;KA;;;BA)(A;;KA;;;SY)(A;;CCDCLCSWRPSDRC;;;BO)(A;;CCDCLCSWRPSDRC;;;LS)
(A;;CCDCLCSWRPSDRC;;;NS)(A;CIIO;RC;;;OW)(A;;KR;;;BU)(A;CIIO;GR;;;BU)(A;CIIO;GA;;;BA)(A;CIIO;GA;;;BO)
(A;CIIO;GA;;;LS)(A;CIIO;GA;;;NS)(A;CIIO;GA;;;SY)(A;CI;CCDCLCSW;;;S-1-5-80-3273805168-4048181553-
3172130058-210131473-390205191)(A;ID;KR;;;AC)(A;CIIOID;GR;;;AC)S:ARAI'
$acl = Get-Acl -Path $Path
$acl.SetSecurityDescriptorSddlForm($sddl)
Set-Acl -Path $Path -AclObject $acl

Divers problèmes peuvent se produire sur un
ordinateur Windows Server 2003 qui exécute le
service de copie parallèle de volume
Cet article décrit les problèmes dans lesquels l’ID d’événement 8019, 20, 8193 ou 12302 est enregistré dans le
journal des applications. Vous recevez un message d'0x8004230F erreur ou 0x80004002'erreur.
Symptômes
Sur un ordinateur Basé sur Microsoft Windows Server 2003 qui exécute le service VSS (Volume Shadow Copy
Service), vous pouvez voir l’un des symptômes suivants :
Lorsque vous effectuez une opération de sauvegarde à l’aide de l’outil NTBackup, l’événement suivant est
consigné dans le journal des applications :

Source de l’événement : NTBackup
Description : Opération de fin : des avertissements ou des erreurs ont été rencontrés. Pour plus
d’informations, consultez le rapport de sauvegarde.
NOTE
Si vous affichez le fichier journal de sauvegarde, les informations suivantes s’affichent :
Erreur renvoyée lors de la création du volume shadow copy:0xffffffff
Si vous accédez aux propriétés d’un volume, puis que vous cliquez sur Copies instantanés, vous
recevez l’un des messages d’erreur suivants :
Erreur 0x8004230F : le fournisseur de copies de l’ombre a reçu une erreur inattendue lors de la
tentative de traitement de l’opération spécifiée.
Erreur 0x80004002 : aucune interface de ce type n’est prise en charge
L’un des événements suivants est consigné dans le journal des applications :

Description : Erreur du service de copie de l’ombre du volume : un composant critique requis par le
service volume shadow copy n’est pas enregistré. Cela peut se produire si une erreur s’est produite
lors Windows’installation ou pendant l’installation d’un fournisseur de shadow copy. L’erreur
renvoyée par CoCreateInstance sur la classe avec CLSID {faf53cc4-bd73-4e36-83f1-2b23f46e513e}
et le nom VSSEvent est [0x80040154].
Description : Erreur du service de copie de l’ombre du volume : un composant critique requis par le
service volume shadow copy n’est pas enregistré. Cela peut se produire si une erreur s’est produite
lors Windows’installation ou pendant l’installation d’un fournisseur de shadow copy. L’erreur
renvoyée par CoCreateInstance sur la classe avec CLSID {faf53cc4-bd73-4e36-83f1-2b23f46e513e}
et le nom VSSEvent est [0x80004002].
Description : Erreur du service de copie de l’ombre du volume : erreur inattendue appelant la routine
CoCreateInstance. hr = 0x80040154.
Description : Erreur du service de copie de l’ombre du volume : erreur inattendue appelant la routine
CoCreateInstance. hr = 0x80004002.
Description : Erreur du service de copie parallèle de volume : une incohérence interne a été détectée
lors de la tentative de contact des rédacteurs du service de copie de l’ombre. Vérifiez que le service
d’événements et le service de copie de l’ombre du volume fonctionnent correctement.
Cause
Ce problème se produit car les fichiers système VSS ne sont pas enregistrés.
Résolution
NOTE
Cet article n’est pas à utiliser avec Windows Vista, Windows Server 2008 ou les systèmes d’exploitation ultérieurs. À partir
Windows Vista et Windows Server 2008, l’installation Windows composant est basée sur le manifeste. Si vous essayez
d’inscrire manuellement des composants spécifiques, tels que ceux décrits dans cette section « Résolution », dans les
systèmes d’exploitation mentionnés dans cette remarque, des résultats inattendus peuvent se produire et nécessiter la
résolution de Windows.

2. Tapez les commandes suivantes à une invite de commandes. Appuyez sur Entrée après avoir tapé chaque
commande.
cd /d %windir%\system32
Net stop vss
Net stop swprv
regsvr32 ole32.dll
regsvr32 oleaut32.dll
regsvr32 vss_ps.dll
vssvc /register
regsvr32 /i swprv.dll
regsvr32 /i eventcls.dll
regsvr32 es.dll
regsvr32 stdprov.dll
regsvr32 vssui.dll
regsvr32 msxml.dll
regsvr32 msxml3.dll
regsvr32 msxml4.dll
NOTE
La dernière commande risque de ne pas s’exécuter correctement.
3. Effectuez une opération de sauvegarde pour vérifier que le problème est résolu.
Étapes pour reproduire ce problème
1. Tapez la commande suivante à une invite de commandes. Appuyez sur Entrée après avoir tapé la
commande.
regsvr32 /u swprv.dll
2. Essayez d’effectuer une opération de sauvegarde.

Vous pouvez obtenir des avertissements VSS dans
le journal des événements d’application de SBS 2011
Standard
Cet article fournit une solution de contournement pour un problème dans lequel vous obtenez des
avertissements VSS dans le journal des événements d’application de Microsoft Windows Small Business Server
2011 Standard.
Symptômes
Dans Small Business Server 2011 Standard, des avertissements semblables aux suivants peuvent s’être produits
dans le journal des événements de l’application :

Source : VSS
Date : <DateTime>
Utilisateur : N/A
Ordinateur : CONTOSOSERVER.contoso.local
Description :
Erreur du service de copie de l’ombre du volume : échec de la résolution de la spsearch du compte avec
l’état 1376. Vérifiez la connexion au contrôleur de domaine et à la clé de Registre VssAccessControl.
Les avertissements peuvent également faire référence au compte spfarm.
Cause
SBS 2011 Édition Standard installe SharePoint 2010 Foundation en mode SharePoint batterie de serveurs. Les
comptes de SharePoint batterie de serveurs et SharePoint recherche sont utilisés comme comptes de service
pour certains services SharePoint de service. Pour pouvoir utiliser les rédacteurs VSS, les comptes doivent avoir
accès à VSS. Les comptes sont ajoutés par SBS à la clé de Registre VssAccessControl, mais le service VSS ne
parvient pas à localiser les comptes. Vous pouvez ignorer les avertissements. Les avertissements n’affectent pas
le fonctionnement de VSS. Si vous souhaitez supprimer les avertissements, vous pouvez suivre les étapes de la
section de résolution.
Pour contourner le problème, utilisez les étapes suivantes.
1. Dans utilisateurs et ordinateurs Active Directory, créez un groupe de sécurité local de domaine nommé
VSSRegistryGroup.
2. Ajoutez des comptes SPFARM et SPSEARCH au groupe VSSRegistryGroup.
3. Exécutez regedit.
IMPORTANT
Cet article contient des informations sur la modification du Registre. Avant de modifier le Registre, pensez à le
sauvegarder et assurez-vous que vous savez le restaurer en cas de problème. Pour plus d’informations sur la façon
de la back up, restore et modify the registry, voir How to back up and restore the registry in Windows.
4. Accédez à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\VssAccessControl .
5. Ajoutez la valeur DWORD domain\vssregistrygroup où domain est le nom de domaine netbios (par
exemple, CONTOSO\vssregistrygroup. Le nom de domaine doit être en toutes les limites) définissez la
valeur sur 1
6. Supprimez les valeurs des domaines\spsearch et domain\spfarm.
7. Accédez à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\diag .
8. Cliquez avec le bouton droit sur diag et cliquez sur Autorisations avancées et ajoutez le groupe
VSSRegistrygroup avec Contrôle total.
9. Supprimez les comptes spsearch et spfarm de la liste des autorisations.
Si la clé de Registre VSSAccessControl ne contient pas les comptes exacts, le service Sharepoint 2011 VSS
Writer ne démarre pas et l’erreur suivante est consignée dans le journal des événements de l’application :

Source : VSS
Date : <DateTime>
Niveau : Error
Utilisateur : N/A
Ordinateur : CONTOSOSERVER.contoso.local
Description :
Erreur du service de copie de l’ombre en volume : le processus qui héberge l’auteur avec le nom SharePoint
Services Writer et l’ID {da452614-4858-5e53-a512-38aab25c61ad} ne s’exécute pas sous un utilisateur
ayant des droits d’accès suffisants. Envisagez d’exécutez ce processus sous un compte local qui est le
système local, l’administrateur, le service réseau ou le service local.
Opération : initialisation du rédacteur
Contexte :
ID de classe writer : {da452614-4858-5e53-a512-38aab25c61ad}
Writer Name: SharePoint Services Writer
Les rédacteurs VSS signalent l’échec sur une
machine virtuelle
Cet article fournit des informations sur les rapports des rédacteurs VSS comme échoués sur une machine
virtuelle.
Symptômes
Vous avez un ordinateur Windows Server 2012 R2 avec le rôle Hyper-V.
Vous exécutez une machine virtuelle Windows Server 2003 ou Windows Server 2008.
Vous essayez de sauvegarder la machine virtuelle à l’aide d’une application de sauvegarde à partir de l’hôte
Hyper-V.
Dans ce scénario, les rédacteurs vsS (Volume Shadow Copy Service) sur Windows Server 2003 ou Windows
Server 2008 signalent l’échec. La sortie si vous exécutez la commande des rédacteurs de liste vssadmin est la
suivante :
vssadmin 1.1 : outil de ligne de commande d’administration du service vssadmin
(C) Copyright 2001 Microsoft Corp.
Nom du rédacteur : « Rédacteur système »

ID du rédacteur : {e8132975-6f93-4464-a53e-1050253ae220}
ID d’instance du rédacteur : {0df8b3f5-59ee-4185-983c-f35f16488e17}
État : [9] Échec
Writer name: 'COM+ REGDB Writer'

ID du rédacteur : {542da469-d3e1-473c-9f4f-7847f01fc64f}
ID d’instance du rédacteur : {4a28f97d-5076-4171-b9ac-a0cabd925645}
État : [9] Échec
Writer name: 'MSDEWriter'

ID du rédacteur : {f8544ac1-0611-4fa5-b04b-f7ee00b03277}
ID d’instance du rédacteur : {ecabb5e5-6526-42b4-b008-e74a7ce9edaa}
État : [1] Stable
Writer name: 'Registry Writer'

ID du rédacteur : {afbab4a2-367d-4d15-a586-71dbb18f8485}
ID d’instance writer : {5ee9aebb-1d30-474d-9562-927ba40e2e4e}
État : [9] Échec
Nom du rédacteur : « Rédacteur WMI »
ID du rédacteur : {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
ID d’instance du rédacteur : {0fe76f97-9185-4bb8-b9da-6ce35be4bc01}
État : [9] Échec
Nom du rédacteur : « Enregistreur du journal des événements »

ID du rédacteur : {eee8c692-67ed-4250-8d86-390603070d00}
ID d’instance du rédacteur : {8a2fd6b9-c349-4d3f-9bc2-046e053bee65}
État : [9] Échec
NOTE
Le rédacteur Hyper-V sur l’hôte Window Server 2012 R2 signale que la sauvegarde a réussi.
L’infrastructure VSS utilise le demandeur VSS Microsoft Hyper-V pour créer une capture instantanée dans la machine
virtuelle.
L’infrastructure VSS utilise le Microsoft Hyper-V vss pour créer une capture instantanée sur l’hôte Hyper-V.
Cause
Ce comportement est normal. Ce comportement existe en raison des limitations dans Windows Server 2003 et
Windows Server 2008 qui restreignent la possibilité d’exposer un disque d’ombre au système d’exploitation
selon les besoins de la phase de mise à jour automatique VSS.
En raison de ces limitations, le demandeur Hyper-V qui s’exécute sur Windows Server 2003 ou Windows Server
2008 arrête le processus de sauvegarde VSS suivant la phase OnThaw afin d’ignorer la partie de la mise à jour
automatique. Cela entraîne l’échec du signalement des rédacteurs invités. Avant d’abandonner le processus de
sauvegarde, l’état de la machine virtuelle est conservé. Il est ensuite utilisé pour fournir une sauvegarde
constante pour l’application.
Les rédacteurs VSS sur le rapport invité Windows Server 2003 ou Windows Server 2008 ont échoué tant que le
rédacteur Hyper-V sur l’hôte Windows Server 2012 R2 signale que la sauvegarde a réussi.
Ce qui suit n’est pas affecté par cet état :
Opérations de restauration ou demandes de sauvegarde ultérieures de la machine virtuelle via le rédacteur
Hyper-V sur l’hôte
Sauvegarder les demandes de la machine virtuelle qui utilisent d’autres techniques de sauvegarde telles
qu’une sauvegarde de l’état du système avec Sauvegarde Windows
Stratégie de prise en charge des conteneurs
Windows Server dans les scénarios locaux
Cet article décrit la stratégie de support de Microsoft concernant les conteneurs Windows Server et Mirantis
Container Runtime (anciennement appelé moteur Docker Enterprise (Docker EE)) pour les implémentations sur
site.
S ʼapplique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 (toutes les
éditions)
Microsoft prend en charge Windows server pour les versions et versions Windows suivantes :
Windows Server, version 1909, 2004 et 20H2 Standard Core ou Datacenter Core
Windows Server 2016 (1607)
Windows 10 Professional et Enterprise avec Docker Desktop installé
Azure Stack HCI (lors de l’hébergement d’Azure Kubernetes Service sur Azure Stack HCI)
Windows IoT Core
Reportez-vous à Vue d’ensemble - Fin du support technique pour plus d’informations sur la fin du support.
NOTE
Lorsque les clients rencontrent des problèmes ou ont des questions sur les conteneurs Windows Server sur les
fonctionnalités d’Windows Server et Mirantis Container Runtime, Microsoft est le premier point de contact. Pour obtenir
des informations similaires sur la stratégie de support de Microsoft pour les conteneurs dans Azure, voir stratégie de
support pour les conteneurs et les services associés sur Azure.
Configurations prise en charge pour les hôtes de conteneur

Microsoft définit les configurations d’hôte pris en charge dans les termes suivants :
Système d’exploitation hôte : Windows serveur ou Windows 10. Pour plus d’informations, voir Windows
conteneurs requis.
Hyperviseur : Windows 10 exécuter Hyper-V pour prendre en charge les conteneurs ; Windows Server,
comme indiqué dans le tableau, offre plus de flexibilité.
Mirantis Container Runtime (MCR) : Mirantis Container Runtime est une application tierce utilisée pour créer
et gérer des conteneurs qui s’exécutent sur Windows Server. Pour plus d’informations, voir Windows
conteneurs requis.
Bureau Docker pour Windows s’exécute sur Windows 10.
Type de conteneur : Microsoft prend en charge Windows server avec isolation Hyper-V. Toutefois, toutes les
configurations d’hôte ne peuvent pas prendre en charge n’importe quel type de conteneur. Pour obtenir des
informations générales sur les conteneurs Windows server et les types de conteneurs, voir Images de base
de conteneur et compatibilité Windows version du conteneur.
NOTE
La fonctionnalité Conteneurs Linux sur Windows (LCOW) sur Windows Server est devenu désinscrite.
Prise en charge des composants hôtes

Les clients qui déploient des conteneurs Windows Server sur les versions de Windows Server prises en charge
s’exécutant sur du matériel physique ou des machines virtuelles (VM) sur Hyper-V bénéficieront d’une prise en
charge complète pour les problèmes liés au système d’exploitation, aux images de base de conteneur et/ou au
moteur de conteneur.
Configurations prise en charge pour Windows hôtes de conteneur de

serveur
Pour déployer des conteneurs Windows Server et hyper-V avec isolation, le runtime de conteneur Mirantis doit
être installé (voir Get started: Prep Windows for containers).
Types de conteneur pris en charge sur l’hôte de conteneur physique

H Y P ERVISEUR P RISE EN C H A RGE DES T Y P ES DE C O N T EN EUR
Aucune conteneurs Windows Server
Hyper-V Isolation Hyper-V et conteneurs Windows Server
Types de conteneur pris en charge sur un hôte de conteneur

d’ordinateur virtuel
H Y P ERVISEUR D’H ÔT E SY ST ÈM E D’EXP LO ITAT IO N T Y P ES DE C O N T EN EUR P RIS
D’UN E VM IN VIT ÉS H Y P ERVISEUR IN VIT É EN C H A RGE
Hyper-V Windows Server (complet Aucune conteneurs Windows Server

ou principal)
Hyper-V Windows Server (complet Hyper-V (doit être en cours Windows Server et
ou principal) d’exécution en mode de conteneurs isolés Hyper-V
virtualisation imbréré)
Hyperviseur validé SVVP Windows Server (complet Aucun (Hyper-V non pris en conteneurs Windows Server
ou principal) charge sur VMWare ESX)
Pour plus d’informations sur les hyperviseurs validés SVVP, voir Welcome to the Windows Server Virtualization
Validation Program.
Configurations prise en charge pour les hôtes Windows 10 conteneur

Microsoft prend en charge les conteneurs sur Windows 10 Professional ou Windows 10 Entreprise dans les
conditions suivantes :
Un système d’exploitation d’ordinateur physique Windows 10 Professional ou Enterprise mise à jour
anniversaire (version 1607) ou ultérieure.
Hyper-V est installé.
Le type de conteneur est Hyper-V avec isolation (par défaut).
Docker Desktop for Windows est installé (voir Install Docker Desktop for Windows on Docker’s website).
Docker Desktop pour Windows est la Community Edition (CE) et est idéale pour les développeurs et les
petites équipes qui cherchent à se lancer avec Docker et à expérimenter des applications basées sur des
conteneurs.
NOTE
Les utilisateurs n’ont plus le non-accès à l’exécution de conteneurs Windows Server en mode d’isolation de processus sur
Windows 10 Entreprise ou Professional à des fins de développement/test depuis Windows 10 mise à jour d’octobre 2018.
Consultez le FAQ pour en savoir plus.
Microsoft ne prend pas en charge les configurations suivantes sur Windows 10 Professional ou Windows 10
Entreprise :
Bureau Docker. Vous pouvez obtenir une assistance à partir des forums Community Docker ou de Docker.
Pour plus d’informations, voir Docker Desktop for Windows FAQ.
Windows conteneurs de serveurs ou conteneurs Hyper-V avec isolation sur les machines virtuelles
hébergées sur un système Windows 10 Professional ou Windows 10 Entreprise système. Pour utiliser des
conteneurs sur une machine virtuelle, utilisez Windows Server en tant qu’hôte.
Conditions requises pour les hôtes de conteneur

Pour plus d’informations sur les conditions requises pour les hôtes de conteneurs, voir :
Windows conteneur requis
System requirements for Hyper-V on Windows Server
Exécuter Hyper-V dans une machine virtuelle avec virtualisation imbriée
Windows conteneurs sur Windows 10
Moteur Docker sur Windows
Windows compatibilité de la version du conteneur
Conteneurs Linux sur Windows 10
Pour plus d’informations sur les exigences et les problèmes de compatibilité pour la virtualisation, voir Windows
Server Catalog: Server Virtualization Validation Program.
Exigences relatives aux conteneurs isolés Hyper-V

Pour exécuter des conteneurs Hyper-V, l’hôte de conteneur doit répondre aux exigences d’exécution d’Hyper-V
lui-même. Pour résumer les conditions requises pour Hyper-V Windows Server :
Processeur 64 bits, avec les fonctionnalités suivantes
Traduction d’adresses de second niveau : la fonctionnalité Windows’hyperviseur nécessite SLAT (ce qui
n’est pas le cas des outils de gestion Hyper-V).
Virtualisation avec assistance matérielle : elle est disponible dans les processeurs qui incluent une
option de virtualisation, en particulier les processeurs avec la technologie Intel Virtualization
Technology (Intel VT) ou AMD Virtualization (AMD-V).
La prévention de l’exécution des données (PDP) appliquée au matériel doit être disponible et activée.
Pour les systèmes Intel, il s’agit du bit XD (exécuter le bit de désactivation). Pour les systèmes AMD, il
s’agit du bit NX (aucun bit d’exécution).
Extensions du mode moniteur d’ordinateurs VM.
Au moins 4 Go de RAM. Il est préférable d’avoir plus de mémoire. Vous aurez besoin de suffisamment de
mémoire pour l’hôte et tous les ordinateurs virtuels que vous souhaitez exécuter en même temps.
Prise en charge de la virtualisation désactivée dans le BIOS ou l’UEFI.
Pour plus d’informations sur la sécurité système requise :
System requirements for Hyper-V on Windows Server
Windows 10 du système Hyper-V
Comment activer la virtualisation imbriée dans une VM Azure
Images de conteneur prises en charge

Microsoft propose quatre images de base de conteneur que les utilisateurs peuvent créer. Chaque image de
base est un type différent de Windows d’exploitation, présente une empreinte sur disque différente et un
ensemble différent d’API Windows de base. Pour plus d’informations, voir Images de base de conteneur.
Windows Server Core : prend en charge les applications .NET framework traditionnelles
Nano Server : conçu pour les applications .NET Core
Windows : fournit l’ensemble complet Windows API
Windows IoT Core : conçu pour les applications IoT
Images de système d’exploitation de base de conteneur prises en

charge Windows hôtes de conteneur
Comme indiqué dans les hôtes de conteneur pris en charge, tous les systèmes d’exploitation hôtes ne Windows
pas pris en charge les conteneurs Windows Server et les conteneurs isolés Hyper-V. De même, toutes les images
de base ne sont pas prises en charge dans les deux types de conteneur. Le tableau suivant décrit les types de
conteneur que vous pouvez créer à l’aide de chaque image de base sur chacun des systèmes d’exploitation
hôtes.
SY ST ÈM E W IN DO W S IM A GE DE W IN DO W S IM A GE DE
D’EXP LO ITAT IO N B A SE DU IM A GE DE B A SE DU W IN DO W S IM A GE DE B A SE DU
H ÔT E DE C O N T EN EUR SERVER C O N T EN EUR N A N O B A SE DU C O N T EN EUR IOT
C O N T EN EUR C O RE SERVER C O N T EN EUR C O RE
Windows Server Windows server Windows server Windows server Non pris en charge
2016 ou 2019 containers and containers and containers and
Standard ou Hyper-V containers Hyper-V containers Hyper-V containers
Datacenter with isolation with isolation with isolation
Windows 10 Conteneurs Hyper-V Conteneurs Hyper-V Conteneurs Hyper-V Non pris en charge
Professional ou avec isolation et avec isolation et avec isolation et
Enterprise conteneurs Windows conteneurs Windows conteneurs Windows
Server pour le Server pour le Server pour le
dev/test dev/test dev/test
Windows IoT Core Non pris en charge Non pris en charge Non pris en charge conteneurs Windows
Server
Si vous prévoyez d’utiliser des hôtes de conteneur qui exécutent différentes versions et versions de Windows,
vous devez également prendre en compte les versions et les versions des images de conteneur. Certaines
fonctionnalités de conteneur ne sont pas à compatibilité avec les versions précédentes, de sorte que certaines
images de base de conteneur plus récentes peuvent ne pas s’exécuter sur des hôtes de conteneur avec
d’anciennes versions du système d’exploitation. Pour plus d Windows, voir la compatibilité de la version du
conteneur.
Prise en charge des charges de travail de conteneur
Microsoft prend entièrement en charge les images de base de conteneur, comme décrit dans la section « Images
de conteneur prises en charge ».
Pour la prise en charge d’applications Microsoft telles qu’IIS, SQL et .NET en cours d’exécution dans des
conteneurs, voir référentiel Microsoft sur DockerHub pour obtenir les conseils de prise en charge des images de
conteneur respectives.
NOTE
Si vous essayez de déplacer une application personnalisée ou une application tierce vers des conteneurs Windows Server
exécutant l’image Windows Server Core et que vous avez des problèmes avec manquant. Les DLLs ou d’autres
composants de l’image de base Windows Server Core, essayez d’utiliser l’image de conteneur Windows, car elle dispose de
l’ensemble d’API Windows complète. Évitez de copier . DLLs de l’hôte de conteneur vers l’image de base Windows Server
Core, car cela peut entraîner un comportement de l’application.
Microsoft a fourni un composant. DLLs sous forme de package redistribuable. Par exemple, l’image Windows de
base du conteneur Server Core n’inclut pas les DLLs d’VB runtime. Pour obtenir le . DLLs, téléchargez le package
redistribuable Service Pack 6 pour Visual Basic 6.0 : Run-Time Redistribution Pack (vbrun60sp6.exe) à partir du
Centre de téléchargement Microsoft officiel et installez-le dans l’image du conteneur à l’aide d’un fichier
Dockerfile.
Pour obtenir des conseils sur le déplacement d’applications héritées, voir Lever et passer aux conteneurs.
Configurations réseau prise en charge

Microsoft prend en charge la Windows de mise en réseau de conteneurs. Cette fonctionnalité inclut le service de
mise en réseau hôte (HNS) et le service de calcul hôte (HCS). HNS et HCS fonctionnent ensemble pour créer des
conteneurs (HCS) et attacher des points de terminaison à un réseau (HNS). En outre, il inclut les pilotes réseau
de conteneur suivants (pour obtenir une description complète de ces pilotes, voir Windows Container Network
Drivers) :
Consultez cet article pour les fonctionnalités non pris en compte et les options réseau.
Comptes de service pris en charge pour les conteneurs

Microsoft prend en charge les comptes de service gérés de groupe Active Directory (gMSA) pour les conteneurs.
Les conteneurs ne peuvent pas être joints à un domaine.
À l’aide de gMSA, les conteneurs Windows Server eux-mêmes et le service qu’ils hébergent peuvent être
configurés pour utiliser un gMSA spécifique comme identité de domaine. Tout service s’exécutant avec le
système local ou le service réseau utilise l’identité des conteneurs Windows Server de la même façon qu’ils
utilisent l’identité de l’hôte joint au domaine. Pour plus d’informations, voir Create gMSAs for Windows
containers.
Options de sécurité de point de terminaison pris en charge pour les

conteneurs et les hôtes de conteneur
Windows Defender a été optimisé pour protéger les hôtes de conteneur et est entièrement pris en charge.
Toutefois, Microsoft ne prend pas en charge les Windows Defender’exécution dans les conteneurs Windows
Server.
Lorsque vous utilisez un logiciel tiers de sécurité de point de terminaison/antivirus, vérifiez auprès du
fournisseur que les conteneurs Windows Server sont pris en charge et consultez les documents publics du
fournisseur pour obtenir des recommandations et des exclusions. Pour plus d’informations, voir Optimisation de
la Windows antivirus pour les conteneurs de recherche.
Runtime de conteneur pris en charge sur Windows Server

Mirantis Container Runtime (MCR) est une interface runtime de conteneur recommandée et prise en charge
utilisée pour créer, gérer et exécuter des conteneurs Windows Server sur Windows Server. Pour plus
d’informations, voir Mirantis.
Voir Prise en main: Prep Windows for containers for the recommended and supported installation method on
Windows Server.
ContainerD est un runtime de conteneur standard open source pris en charge par la communauté. ContainerD
s’exécutant sur Windows Server peut créer, gérer et exécuter des conteneurs Windows server, mais Microsoft ne
fournit aucune prise en charge. Pour tout problème ou toute question liée à ContainerD, demandez à GitHub
communauté. Pour plus d’informations, voir GitHub projet ContainerD et ContainerD.
Orchestrators de conteneur pris en charge

Plusieurs orchestrators de conteneur peuvent Windows conteneurs de serveurs. Veuillez résoudre les
problèmes ou les questions avec le fournisseur avant d’engager le support Microsoft.
Docker Swarm est une fonctionnalité de Mirantis Container Runtime qui crée, gère et exécute des conteneurs
Windows Server dans un environnement de nœuds mixtes d’hôtes Linux et Windows. Docker Swarm est
entièrement pris en charge par Mirantis. La prise en charge de Mirantis informe les clients si le support
Microsoft doit être impliqué en ce qui concerne les problèmes ou les questions liées à Windows Server. Pour
plus d’informations sur l’utilisation de Docker Swarm avec des conteneurs Windows Server, voir La mise en
place du mode Swarm et de la vue d’ensemble du mode Swarm sur le site web Mirantis.
Kubernetes est un projet open source qui prend en charge les conteneurs Windows Server sur Windows Server
à partir de Kubernetes 1.14. Pour plus d’informations, voir Introduction à la Windows prise en charge dans
Kubernetes et les fonctionnalités et limitations de prise en charge. Pour plus d’informations, voir Kubernetes sur
Windows.
Pour les problèmes et les questions liés à Kubernetes, voir Reporting Issues and Feature Requests.
Microsoft fournit uniquement la prise en charge Windows de serveurs participant à un cluster Kubernetes.
Microsoft ne prend pas en charge les éléments suivants :
Configuration et configuration des nodes Linux
Binaires Kubernetes
Conteneurs Linux
Plug-ins Kubernetes
Toute question ou problème lié à des éléments non pris en charge doit être adressé à des GitHub pertinentes.
Azure Service Fabric est l’orchestrateur de conteneur de Microsoft pour déployer des microservices sur un
cluster d’ordinateurs. Il est entièrement pris en charge par Azure. Tous les problèmes et questions doivent être
dirigés vers le support Azure à l’aide de « Aide + support » dans le portail Azure. Pour plus d’informations, voir
Présentation du gestionnaire de ressources Service Fabric cluster et des Service Fabric et conteneurs.
Le service Azure Kubernetes sur Azure Stack HCI (AKS-HCI) est une implémentation sur site de l’orchestrator
akbernetes Service (AKS) azure populaire, qui exécute automatiquement des applications en conteneur à
l’échelle.
Microsoft fournit une prise en charge de bout en bout pour Azure Kubernetes Service sur Azure Stack HCI, sauf
pour les éléments suivants :
Code d’application client
Tous les services ou pilotes système non-in-box dans le conteneur ou l’hôte de conteneur
Images de base de conteneur non prises en charge par Microsoft (par exemple, Nginx) ou images de base de
conteneur qui ne sont pas répertoriées dans la liste des modules ajoutés pris en charge
Moby est un projet open source destiné aux ingénieurs, intégrateurs et fans qui cherchent à modifier, pirater,
corriger, expérimenter, réinventer et créer des systèmes basés sur des conteneurs. Pour plus d’informations, voir
le projet Moby sur GitHub.
Microsoft ne prend pas en charge Moby dans un environnement de prise en charge (un hôte de conteneur à
nœud unique exécutant Windows Server). Toutes les questions et tous les problèmes doivent être posées dans
le projet Moby sur GitHub.
Documentation de dépannage du déploiement
pour Windows Server
problèmes liés au déploiement et à résoudre eux-mêmes les problèmes liés au déploiement. Les rubriques sont
divisées en sous-catégories. Parcourez le contenu ou utilisez la fonctionnalité de recherche pour rechercher du
contenu pertinent.
Sous-catégories de déploiement
Activation
Bitlocker
Appareils et pilotes
MDM
Maintenance
Installation
Windows’est pas une erreur authentique
Cet article vous aide à résoudre 0x80070005'erreur qui se produit lorsque vous vous connectez à un ordinateur.
Symptômes
Lorsque vous vous connectez à un ordinateur qui exécute Windows, vous recevez le message d’activation
Windows suivant :
Windows n’est pas authentique

Il se peut que votre ordinateur exécute une copie de contrefaçon de Windows.
En outre, l’arrière-plan du bureau est noir et vous recevez le message d’erreur suivant dans le coin inférieur droit
de l’écran :
Copie de l’Windows non authentique
Lorsque vous affichez les propriétés système dans le Panneau de contrôle, les informations suivantes s’affichent
:
NOTE
Pour afficher les propriétés système, cliquez sur Démarrer, sur Panneau de contrôle, sur Système et sécurité, puis sur
Système.
Vous devez l’activer aujourd’hui. Activez Windows maintenant.

Si vous utilisez le script slmgr.vbs /dlv pour afficher l’état des licences, vous recevez le message suivant :
Erreur : 0x80070005'accès refusé : l’action demandée requiert des privilèges élevés
NOTE
Ce message d’erreur peut également se produire lorsqu’une commande en cours d’exécution nécessite une invite de
commandes avec élévation de niveau élevé et n’est pas liée au problème abordé ici.
Si vous voyez un message qui Windows peut ne pas être authentique et qu’il n’existe aucun code d’erreur, rendez-vous
sur Genuine Windows: frequently asked questions.
Résolution
Pour résoudre ce problème, utilisez les méthodes suivantes, selon votre scénario.
Scénario 1 : manque d’autorisations
Le compte de service réseau doit avoir un contrôle total et des autorisations de lecture dans la sous-clé de
Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Profilelist\S-1-5-20
Les autorisations peuvent avoir été supprimées lorsqu’un objet de stratégie de groupe plug-and-play a été
appliqué.
Pour résoudre le problème dans ce scénario, utilisez la méthode A ou la méthode B.
Méthode 1 : modifier les autorisations de la stratégie de groupe
1. Déterminez la source de la stratégie. Pour cela, procédez comme suit :
a. Sur l’ordinateur qui rencontre le message d’erreur Activation, exécutez l’Assistant Jeu de stratégie
résultant. Pour ce faire, cliquez sur Démarrer, tapez rsop.msc dans la zone De recherche, puis
b. Dans le volet de navigation, développez les conteneurs suivants : Voir l’image
Ordinateur configuration
Windows Paramètres
Paramètres de sécurité
c. Dans le volet de navigation, cliquez sur Ser vices système.
d. Si le service Plug-and-Play est configuré par le biais d’un paramètre de stratégie de groupe, l’GPO
est répertorié ici avec des paramètres autres que Non définis. En outre, vous pouvez voir quel GPO
applique ce paramètre.
2. Ouvrez l’GPO identifié à l’étape 1, puis ouvrez le paramètre de stratégie de groupe correspondant.
3. Cliquez sur Modifier la sécurité, puis sur Avancé.
4. Dans la fenêtre Paramètres sécurité avancée pour plug-and-play, cliquez sur Ajouter, puis ajoutez le
compte SERVICE.
5. Cliquez sur OK .
6. Sélectionnez les autorisations suivantes dans la section Autoriser, puis cliquez sur OK :
Modèle de requête
État de la requête
Éumer les dépendants
Interrogation
Contrôle défini par l’utilisateur
Autorisations en lecture
NOTE
Ce sont les autorisations minimales requises.
7. Exécutez gpupdate /force après avoir appliqué les autorisations précédentes au paramètre de stratégie
de groupe. Pour ce faire, cliquez sur Démarrer, tapez dans la zone gpupdate /force Rechercher, puis
8. Assurez-vous que les autorisations appropriées sont appliquées. Pour ce faire, cliquez sur Démarrer,
tapez dans la zone sc sdshow plugplay De recherche, puis cliquez sur OK.
Voici les autorisations qui sont appliquées au service Plug-and-Play dans le langage de définition de descripteur
de sécurité (SDDL) :
D:(A;; CCDCLCSWRPWPDTLOCRSDRCWDWO;;; SY)

(A;; CCDCLCSWRPWPDTLOCRSDRCWDWO;;; BA)
(A;; CCLCSWLOCRRC;;;I U)
(A;; CCLCSWLOCRRC;; ; SU)
S:(AU;FA; CCDCLCSWRPWPDTLOCRSDRCWDWO;;; WD)
(A;; CC LC SW LO CR RC ;;; SU est une entrée de contrôle d’accès (ACE) qui autorise les droits suivants sur SU
(SDDL_SERVICE - Utilisateur d’accès au service) :
R : Accès autorisé
CC : créer un enfant
LC : Lister les enfants
SW : Écriture autonome
LO : List, objet
CR : contrôler l’accès
RC : Contrôle de lecture
SU : Utilisateur de l’logo de service
Si aucun G STRATÉGIE de groupe n’est en place, les autorisations de Registre par défaut ont été modifiées. Pour
contourner ce problème, suivez les étapes suivantes :
1. Démarrez l’Éditeur du Registre sur l’ordinateur qui reçoit le message d’erreur. Pour ce faire, cliquez sur
Démarrer, tapez regedit dans la zone De recherche, puis appuyez sur Entrée.
2. Cliquez avec le bouton droit sur la clé de HKEY_USERS\S-1-5-20 Registre, puis cliquez sur Autorisations.
3. Si le SERVICE RÉSEAU n’est pas présent, cliquez sur Ajouter.

4. Dans Entrez les noms des objets pour sélectionner la zone, tapez service réseau, cliquez sur
Vérifier les noms, puis cliquez sur OK .
5. Cliquez sur SERVICE RÉSEAU, puis sélectionnez les autorisations Contrôle total et Lecture.
6. Cliquez sur OK .
8. Après avoir redémarré l’ordinateur, vous de devez peut-être activer la copie de Windows. Terminez
l’activation.
Méthode 2 : désactiver l’GPO Plug-and-Play
NOTE
Cette méthode est destinée aux utilisateurs avancés de l’ordinateur et ne peut pas être exécutée sur des ordinateurs
exécutant Windows 7 Édition Familiale Premium, Windows 7 Édition Familiale Basique ou Windows 7 Édition Starter. Pour
obtenir de l’aide sur la résolution avancée des problèmes, demandez à votre administrateur système ou contactez
Microsoft.
Pour désactiver l’GPO Plug-and-Play, suivez les étapes suivantes :

1. Déterminez la source de la stratégie. Pour cela, procédez comme suit :
a. Sur l’ordinateur qui rencontre le message d’erreur Activation, exécutez l’Assistant Jeu de stratégie
résultant. Pour ce faire, cliquez sur Démarrer, tapez rsop.msc dans la zone De recherche, puis appuyez
sur Entrée.
b. Dans le volet de navigation, développez les conteneurs suivants :
Windows Paramètres
Paramètres de sécurité
c. Dans le volet de navigation, cliquez sur Services système.
d. Si le service Plug-and-Play est configuré par le biais d’un paramètre de stratégie de groupe, l’GPO est
répertorié ici avec des paramètres autres que Non définis. En outre, vous pouvez voir quelle
stratégie de groupe applique ce paramètre.
2. Désactivez les paramètres de stratégie de groupe et forcez la réapplicité de la stratégie de groupe. Pour
3. Modifiez la stratégie de groupe identifiée à l’étape 1 et modifiez le paramètre sur Non défini. Vous
pouvez également suivre les étapes de la méthode 1 pour ajouter les autorisations requises pour le
compte service réseau.
4. Réappliquez le paramètre de stratégie de groupe. Pour ce faire, cliquez sur Démarrer, tapez dans la zone
gpupdate /force De recherche, puis appuyez sur Entrée.
NOTE
Vous de devez peut-être redémarrer l’ordinateur.
Scénario 2 : Entrées de Registre manquantes

Une ou plusieurs des sous-clés de Registre suivantes sont manquantes :
Pour résoudre ce problème dans ce scénario, suivez les étapes suivantes :

1. Copiez le texte ci-dessous dans un éditeur de Bloc-notes, puis enregistrez le fichier texte sous
profilelist.reg.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18]
« Flags"=dword:0000000c
« State"=dword:00000000
« RefCount"=dword:00000001
« Sid"=hex:01,01,00,00,00,00,00,05,12,00,00,00
« ProfileImagePath"=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,\
00,6f,00,74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,\
5c,00,63,00,6f,00,6e,00,66,00,69,00,67,00,5c,00,73,00,79,00,73,73,00,74,00,65,\
00,6d,00,70,00,72,00,6f,00,66,00,69,00,6c,00,65,00,00,00
« ProfileImagePath"=hex(2):43,00,3a,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,\
00,73,00,5c,00,53,00,65,00,72,00,76,00,69,00,63,00,65,00,50,00,72,00,6f,00,\
66,00,69,00,6c,00,65,00,73,00,5c,00,4c,00,6f,00,63,00,61,00,6c,00,53,00,65,\
00,72,00,76,00,69,00,63,00,65,00,00,00
« Flags"=dword:00000000
« ProfileImagePath"=hex(2):43,00,3a,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,\
00,73,00,5c,00,53,00,65,00,72,00,76,00,69,00,63,00,65,00,50,00,72,00,6f,00,\
66,00,69,00,6c,00,65,00,73,00,5c,00,4e,00,65,00,74,00,77,00,6f,00,72,00,6b,\
00,53,00,65,00,72,00,76,00,69,00,63,00,65,00,00,00
« Flags"=dword:00000000
2. Fusionner profilelist.reg. Pour ce faire, cliquez avec le bouton droit sur le fichier que vous avez enregistré
à l’étape 1, puis cliquez sur Fusionner.
4. Activez Windows.
n’est pas résolu, vous pouvez contacter le support technique.
Informations avancées
Étant donné que le service de gestion des licences utilise Plug-and-Play pour obtenir des informations sur l’ID
matériel et lie la licence à l’ordinateur, ce paramètre peut entraîner l’apparition d’un système activé comme étant
hors tolérance. Les autorisations par défaut de la stratégie Plug-and-Play n’accordent pas au service de gestion
des licences les droits appropriés pour accéder au service Plug-and-Play. Le service de gestion des licences
s’exécute sous le compte service réseau.
Code d’erreur : 0xc004f063 s’affiche lors de la
tentative d’activation ou de validation d’une version
OEM d Windows 8 ou Windows Server 2012
Cet article fournit une solution à une erreur 0xc004f063 qui se produit lorsque vous essayez d’activer ou de
valider une version OEM de Windows.
Symptômes
Lorsque vous essayez de valider une version OEM de Windows 8 ou Windows Server 2012, vous pouvez
Code d’erreur : 0xc004f063 service de gestion des licences logicielles a signalé que l’ordinateur BIOS
manque une licence requise.
Cause
Cette erreur se produit généralement si un matériel est modifié ou si un périphérique matériel ne fonctionne
pas correctement et Windows ne parvient pas à vérifier à nouveau la licence. Windows ne parvient pas à lire la
table SLIC dans le BIOS requise pour pouvoir activer automatiquement la clé OEM_SLP actuellement en cours
d’utilisation. Cela se produit pour l’une des raisons suivantes :
1. La balise de service ou le numéro de service n’est pas mis à jour par le fournisseur OEM après le
remplacement de la carte mère.
2. Le BIOS contient une valeur par défaut ou une valeur de la garbage pour la balise de service.
3. Le BIOS contient des informations de produit incorrectes.
Résolution
Contactez le fournisseur OEM pour mettre à jour le BIOS qui possède le numéro de série ou la balise de service
mis à jour.
Ce problème se produit principalement sur OEM_SLP ordinateurs sur Windows est lié à la balise de service de
l’ordinateur. Si un OEM_SLP Windows valide sa licence après un changement de matériel en dehors de la clé, il
vérifie également le numéro de balise de service dans le BIOS.
NOTE
Pour vérifier le numéro de balise de service sur un ordinateur, exécutez la wmic bios get serialnumber commande.
La mise à niveau du BIOS est un effort pour placer la table SLIC correcte sur l’ordinateur. La Table de description
des licences logicielles (SLIC) est une signature numérique placée dans le BIOS par le fabricant du système. La
clé OEM-SLP et un certificat OEM au format XML (émis par Microsoft pour chaque OEM) seront vérifiés par
rapport à ce SLIC spécifique à l’OEM et activés automatiquement si tout est dans l’ordre.
L’ID d’avertissement du journal des événements de
l’application 1058 (Security-SPP) peut être enregistré
après le redémarrage sur les systèmes OEM
Cet article fournit des informations sur l’ID d’avertissement du journal des événements d’application
1058(Security-SPP) qui peut être enregistré après le redémarrage sur les systèmes OEM.
Résumé
L’ID d’avertissement du journal des événements d’application 1058 (Security-SPP) peut être enregistré après le
redémarrage d’un système OEM qui utilise l’OA (OEM Activation).
Cause
Cet avertissement est consigné en raison de la présence de données d’activation de test dans le cadre du
processus de fabrication des systèmes OEM.
Cet ID d’avertissement peut être ignoré en toute sécurité dans ce scénario.
Code d'0x8007000D lorsque vous essayez d’activer
un ordinateur Windows 7 à l’aide de n’importe quel
type de clé de produit
Cet article vous aide à résoudre 0x8007000D’erreur qui se produit lorsque vous activez un ordinateur Windows
7 à l’aide de n’importe quel type de clé de produit.
Symptômes
Vous essayez d’activer un ordinateur Windows 7 à l’aide de n’importe quel type de clé de produit. slsmgr -dlv
slmgr -ato L’exécution ou l’exécution à partir d’une ligne de commande génère l’erreur suivante :
Les données ne sont pas valides.

Code d’erreur 8007000d.
Cause
Le compte système dispose par défaut d’autorisations contrôle total sur le chemin d’accès du Registre
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root et toutes les sous-clés.
Si ces autorisations ont été modifiées pour la clé ou une ou plusieurs sous-clés, le code d’erreur Root
s'0x8007000D.
Résolution
Attribuez l’autorisation minimale d’éumérer les sous-clés au compte système pour le chemin d’accès au Registre
et l’une de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root ses sous-clés.
Erreur lors 0xC004E002'activation de Windows
Cet article fournit une solution à une erreur 0xC004E002 lorsque vous essayez d’activer Windows.
Symptômes
Lorsque vous essayez d’activer Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2,
Windows 8, Windows Server 2012, Windows 8.1 ou Windows Server 2012 R2, vous peut recevoir l’un des
messages d’erreur suivants :
Code : 0xC004C003
Description : le serveur d’activation a déterminé que la clé de produit spécifiée a été bloquée.
Code : 0xC004E002
Description : le service de gestion des licences logicielles a signalé que le magasin de licences contient des
données incohérentes.
Cause
Ce problème se produit car les autorisations incorrectes sont définies sur le fichier Tokens.dat ou ce fichier est
endommagé.
Résolution
Pour résoudre ce problème, essayez les méthodes suivantes dans l’ordre.
Méthode 1 : définir les autorisations correctes sur le fichier Tokens.dat
1. Sélectionnez Démarrer, puis tapez cmd dans la zone de recherche.
2. Cliquez avec le bouton droit sur cmd, puis sélectionnez Exécuter en tant qu’administrateur.
3. À l’invite de commandes, tapez la commande suivante en fonction du système d’exploitation, puis
Pour Windows Vista ou Windows Server 2008 :
icacls %windir%\serviceprofiles\networkservice\appdata\roaming\microsoft\softwarelicensing /grant

"BUILTIN\Administrators:(OI)(CI)(F)" "NT AUTHORITY\SYSTEM:(OI)(CI)(F)" "NT Service\slsvc:(OI)(CI)
(R,W,D)"
Les autorisations correctes pour tokens.dat doivent ressembler à la sortie d’icacls :
tokens.dat NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
NT SERVICE\SLSVC:(I)(R,W,D)
Pour Windows 7 ou Windows Server 2008 R2 :

icacls %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform
/grant "BUILTIN\Administrators:(OI)(CI)(F)" "NT AUTHORITY\SYSTEM:(OI)(CI)(F)" "NETWORK SERVICE:(OI)
(CI)(F)"
Les autorisations correctes pour token.dat doivent ressembler à la sortie d’icacls :
NT AUTHORITY\NETWORK SERVICE:(I)(F)
Pour Windows 8, Windows Server 2012, Windows 8.1 ou Windows Server 2008 R2 :
icacls "%windir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\WSLicense" /grant

"BUILTIN\Administrators:(OI)(CI)(F)" "NT AUTHORITY\SYSTEM:(OI)(CI)(F)" "NETWORK SERVICE:(OI)(CI)(F)"
Les autorisations correctes pour tokens.dat doivent ressembler à la sortie d’icacls :
NT SERVICE\WSService:(OI)(CI)(R,W,D)
NOTE
Vous devez taper cette commande à partir d’une invite de commandes avec élévation de élévation de niveaux.
Méthode 2 : renommer le fichier Tokens.dat

1. Sélectionnez Démarrer, puis tapez cmd dans la zone de recherche.
2. Cliquez avec le bouton droit sur cmd, puis sélectionnez Exécuter en tant qu’administrateur.
3. À l’invite de commandes, tapez la commande suivante, puis appuyez sur Entrée.
Pour Windows Vista ou Windows Server 2008
net stop slsvc
Pour Windows 7 ou Windows Server 2008 R2
net stop sppsvc
Pour Windows 8, Windows Server 2012, Windows 8.1 ou Windows Server 2008 R2
net stop sppsvc
NOTE
Si vous recevez un message vous demande si vous souhaitez poursuivre cette opération, tapez Y, puis appuyez sur
Entrée .
4. Tapez la commande suivante, puis appuyez sur Entrée.
cd %windir%\serviceprofiles\networkservice\appdata\roaming\microsoft\softwarelicensing
cd %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform
cd %windir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\WSLicense
ren tokens.dat tokens.bar

net start slsvc
net start sppsvc
net start sppsvc
cd %windir% \System32
cscript slmgr.vbs -rilc
9. Redémarrez l’ordinateur deux fois pour que les modifications s’appliquent.

Cela a-t-il corrigé le problème ?
n’est pas résolu, pour Windows 7 ou Windows Server 2008, vous pouvez contacter le support technique. Le
support assisté n’est plus disponible pour Windows Vista.
Erreur 0xC004F015 lorsque vous activez Windows 10
Entreprise sur un hôte Windows Server 2012 R2
KMS
Cet article fournit une solution à une erreur 0xC004F015 qui se produit lorsque vous activez Windows 10
Entreprise sur un hôte KMS Microsoft Windows Server 2012 R2 et Windows Server 2008 R2.
Symptômes
Sur un ordinateur qui exécute une installation avec licence en volume de Windows 10 Entreprise, vous ne
pouvez pas activer Windows si vous utilisez une clé de licence en volume (CSLVK) du support technique. En
outre, l’entrée d’erreur suivante est consignée dans le journal des événements en tant qu’ID d’événement 12290
:
0xC004F015
Détails de l’erreur
0xc004f042 - SL_E_VL_KEY_MANAGEMENT_SERVICE_ID_MISMATCH
Le service de gestion des licences logicielles a déterminé que la Service de gestion de clés spécifiée (KMS)
ne peut pas être utilisée.
Cause
Ce problème peut se produire si vous utilisez la clé Windows 10 KMS produit hôte dans un environnement
Windows Server 2012 R2 et Windows Server 2008 R2. Vous devez utiliser la clé de produit hôte
WS2012R2+Win10 mise à jour KMS si les conditions suivantes sont vraies.
Les CSVLK clients sont installés sur les ordinateurs clients.
Les CSVLK de serveur sont installés sur les ordinateurs serveurs.
Conditions préalables à l’activation Windows 10 Entreprise

Pour activer Windows 10 Entreprise dans un environnement Windows Server 2012 R2, les conditions préalables
Vous devez avoir Windows Server 2012 R2 avec le rôle d’activation en volume installé.
Vous devez avoir installé 3172614 jour.
Pour activer Windows 10 Entreprise dans un environnement Windows Server 2008 R2, les conditions préalables
Vous devez avoir Windows Server 2008 R2 avec le rôle Activation en volume installé.
La mise à jour 3079821 doit être installée.
Résolution
1. Connectez-vous au Centre de gestion des licences en volume (VLSC).
2. Cliquez sur Licence .
3. Cliquez sur Synthèse des relations.
4. Cliquez sur ID de licence de sa licence active actuelle.
5. Après le chargement de la page, cliquez sur Clés de produit.
6. Dans la liste des clés, recherchez Windows Sr v 2012R2 DataCtr/Std KMS pour Windows 10 .
7. Installez cette clé sur l’KMS hôte.
Pour l’hôte KMS client, ce problème ne doit pas se produire sur un serveur hôte KMS client.
L’activation Windows 10 n’est pas prise en charge si vous exécutez un hôte KMS sur l’un des systèmes
Windows Vista
Windows Server 2008
Windows Server 2003
La clé de licence en volume générique (GVLK) pour Windows 10 éditions se trouve à l’annexe A : KMS clés
d’installation du client.
Erreur 0xC004F074 lors de l’activation de Windows :
Le serveur gestionnaire de clés (KMS) n’est pas
disponible
Cet article vous aide à résoudre l’erreur 0xC004F074 qui se produit quand vous activez Windows.
Produits concernés : Windows 7 Service Pack 1, Windows Server 2012 R2
Symptôme
Quand vous essayez d’activer un ordinateur client KMS Windows 7 ou Microsoft Windows Server 2008 R2, le
message d’erreur ci-dessous peut s’afficher :
0xC004F074 avec la description « Le serveur gestionnaire de clés (KMS) n’est pas disponible »
En parallèle, les entrées ci-dessous peuvent être consignées dans le journal des événements KMS sur le
client KMS et l’hôte KMS.
Dans le journal des événements de l’application sur le client KMS, l’événement suivant est affiché :

Source: Microsoft-Windows-Security-SPP
Date:
Event ID: 12288

Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer:
Description:
The client has sent an activation request to the key management service machine.
Info:
0xC004F06C, 0x00000000, <KMS Host FQDN>:1688, 36f27b39-2fd5-440b-be67-a09996d27a38, 2010/09/29 17:52, 0, 2,
41760, 68531fb9-5511-4989-97be-d11a0f55633f, 5
Dans le journal des événements de l’application sur l’hôte KMS, l’événement suivant est affiché :
Log Name: Key Management Service
Source: Microsoft-Windows-Security-Licensing-SLC
Date:
Event ID: 12290

Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer:
Description:
An activation request has been processed.
Info:
0xC004F06C,5,<KMS Client name>,36f27b39-2fd5-440b-be67-a09996d27a38,2010/9/29 21:46,0,2,41520,68531fb9-5511-
4989-97be-d11a0f55633f
Cause
Cette erreur peut se produire à cause d’une incompatibilité de versions de prise en charge entre le client KMS et
l’hôte KMS.
Le plus souvent, elle se produit quand l’hôte KMS s’exécute sur Windows Server 2003 ou Windows Server 2008
alors que le client KMS est sous Windows 7 ou Windows Server 2008 R2. Une mise à jour est nécessaire pour
les hôtes KMS exécutés sur Windows Server 2003 et Windows Server 2008 afin de pouvoir activer les
clients KMS sous Windows 7 ou Windows Server 2008 R2.
Cette erreur peut également se produire en cas de différence de temps entre le client KMS et l’hôte KMS.
L’erreur 0xC004F06C répertoriée dans la section des informations peut se produire si la différence entre l’heure
système sur l’ordinateur client et celle sur l’hôte KMS est supérieure à 4 heures. Il est recommandé d’utiliser une
source de temps NTP (Network Time Protocol) ou le service Active Directory pour synchroniser l’heure entre les
ordinateurs. Le temps est coordonné entre l’hôte KMS et l’ordinateur client en temps universel coordonné (UTC).
Résolution
Si vous exécutez Windows Server 2008 en tant qu’hôte KMS, vous devez installer le correctif logiciel 968912.
Assurez-vous que l’heure système sur le client et l’hôte KMS est identique.
Le fuseau horaire défini sur l’ordinateur client ne perturbe pas l’activation, car elle est basée sur l’heure UTC.
Exécutez la commande w32tm /resync pour resynchroniser l’heure sur le client.
References
Résoudre les codes d’erreur d’activation de Windows
Message d’erreur lorsque vous essayez de valider
une copie de Windows : l’opération de chiffrement a
échoué en raison d’un paramètre d’option de
sécurité local
Cet article fournit une solution à une erreur qui se produit lorsque vous essayez de valider une copie de
Windows.
Symptômes
Lorsque vous essayez de valider une copie de Windows, vous pouvez recevoir un message d’erreur semblable à
ce qui suit :
Échec de l’installation de la mise à jour. Informations sur l’erreur : 0x80092026
Lorsque vous essayez de valider Windows, Windows télécharge une mise à jour 971033. Toutefois, lorsque
Windows tente d’installer la mise à jour, la mise à jour affiche un message d’erreur mentionné ci-dessus. En
outre, si vous essayez de télécharger la mise à jour KB971033 sur votre ordinateur et de l’exécuter
manuellement, vous pouvez recevoir le message d’erreur suivant :
Le programme d’installation a rencontré une erreur : 0x80092026

L’opération de chiffrement a échoué en raison d’un paramètre d’option de sécurité local.
Cause
Cette erreur se produit lorsque la valeur State de la sous-clé de Registre suivante est incorrectement définie.
Cette valeur correspond au paramètre de sécurité Internet Explorer . Recherchez la révocation des certificats de
l’éditeur et recherchez les signatures sur les programmes téléchargés.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing
Vous pouvez trouver une clé avec le nom État . Par défaut, la valeur est définie sur 23c00 .
Résolution
Pour résoudre ce problème, modifiez la clé de Registre en un paramètre valide, par exemple :
État = 0x00023e00 - Vérifier la révocation de cer tificats de l’éditeur Désactivé
État = 0x00023c00 - Vérifier la révocation de cer tificats de l’éditeur Checked
Utilisez l’une des méthodes suivantes :
Méthode 1 : Modifier le Registre
WARNING
1. Démarrez l’Éditeur du Registre (Regedit.exe).

2. Naviguer vers
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing .
3. Dans le volet gauche, recherchez la clé d’état et double-cliquez pour l’ouvrir.
4. Modifiez les données de valeur sur 23c00 ou 23e00 (hexadécimal).
Méthode 2 : Créer un fichier reg
1. Démarrez Bloc-notes.
2. Dans Bloc-notes, collez les informations suivantes.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software
Publishing
"State"=dword:00023c00
3. Enregistrez le fichier en tant que fichier .reg.

4. Double-cliquez sur le fichier .reg que vous avez enregistré à l’étape 3.
Les modifications de Registre ci-dessus ne nécessitent aucun redémarrage. Vous pouvez essayer d’installer la
mise à jour manuellement.
Vous pouvez valider votre Windows correctement.
Dans certains cas, il peut être nécessaire de mettre à jour la valeur d’état pour les deux registres suivants
également.
HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software
Publishing
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software
Publishing
NOTE
Assurez-vous que la valeur mise à jour pour , doit être exacte pour les deux registres
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing
ci-dessus.
Événement de sécurité 12293 avec erreur lors
0x80072338'enregistrement KMS’hôte
Cet article fournit une résolution pour corriger l’ID d’événement 12293 qui se produit lors de la configuration
d’KMS hôte.
Symptômes
Lors de la configuration d’un KMS, vous pouvez recevoir l’ID d’événement suivant dans le journal des
événements de l’application sur KMS hôte.
Source : Security-SPP
La publication du service de gestion de clés (KMS) sur DNS dans le contoso.com domaine a échoué.
Info : 0x80072338
0x80072338 : DNS_ERROR RCODE_BADSIG
Échec de vérification de la signature DNS.
Cause
Cette erreur peut se produire si l’hôte KMS n’est pas autorisé à modifier l’enregistrement SRV _VLMCS existant
dans DNS.
Résolution
Utilisez les étapes suivantes pour modifier les autorisations afin d’autoriser le nouvel hôte KMS à mettre à jour
l’enregistrement.
1. Dans DNS goto Forward Lookup Zones\Contoso.com \ _tcp.
2. Recherchez l'_VLMCS de recherche
3. Cliquez avec le bouton droit, choisissez les propriétés
4. Sous l’onglet Sécurité, ajoutez le nouveau nom KMS’ordinateur hôte avec Contrôle total
5. Redémarrer le service sppssvc ou slsvc sur KMS hôte
NOTE
Voici des instructions spécifiques au serveur DNS Microsoft. Si vous utilisez un serveur DNS tiers, consultez votre
documentation pour savoir comment modifier les autorisations.
Les enregistrements SRV dans DNS utilisent le nom d’enregistrement comme ID pour tous les enregistrements
de ce type. Le premier KMS’hôte pour créer un enregistrement nommé VLMCS. TCP devient le
créateur/propriétaire des enregistrements SRV de ce nom. Les KMS ne peuvent pas publier d’enregistrements
SRV dans cette zone avec ce nom tant qu’ils n’ont pas été autorisés à le faire.
L_VLMCS SRV peut être pensé comme un tableau avec un seul nom. Dans une configuration DDNS par défaut,
tout ordinateur peut créer un enregistrement SRV unique. Une fois _ qu’un enregistrement VLMCS existe, aucun
autre ordinateur n’a le droit de modifier cet enregistrement. Les secondes et KMS suivantes créent les
enregistrements SRV du même nom. La conception d’enregistrement SRV permet à un administrateur DNS de
contrôler explicitement les ordinateurs autorisés à publier des services dans la zone DNS.
Lorsque la publication sur DNS réussit, l’hôte KMS enregistre un ID d’événement 12294 dans le journal des
événements de l’application.
Échec de l’activation basée sur le jeton
d’avertissement de l’ID d’événement 12321
Cet article fournit une résolution pour l’échec de l’activation basée sur le jeton d’avertissement de l’ID
d’événement 12321.
Symptômes
Le journal des événements d’application peut enregistrer un événement d’avertissement d’ID d’événement
12321 à partir de la source Microsoft-Windows-Security-Licensing-SLC. Le champ de description va faire état de
l’échec de l’activation basée sur le jeton.
HR=0xC004F011
Cause
Cet événement se produit lorsque la licence d’émission de jeton n’est pas installée dans Windows ou que les
certificats sur la carte à puce ne sont pas présents et que l’activation est tentée.
0xC004F011 = SL_E_LICENSE_FILE_NOT_INSTALLED
Windows La gestion des licences logicielles vérifie si l’activation de jeton est disponible sur ce système de
licences en volume et signalant que la licence ou le certificat n’est pas disponible afin que la licence basée sur les
jetons ne fonctionne pas.
Résolution
Ce fichier de licence d’émission ou des certificats de carte à puce ne sont nécessaires que lorsque l’activation
basée sur un jeton est en cours de tentative.
Si vous n’utilisez pas Token-Based Activation automatique, ce message d’avertissement peut être ignoré en
toute sécurité. Et cela n’affectera pas la capacité, qui active les Windows l’KMS ordinateurs hôtes ou les clés MAK.
Si vous utilisez l’activation basée sur un jeton, vous devez réinstaller la licence d’émission de jeton acquise
auprès de Microsoft.
SLMGR /ILC <token-based-license-filename>
Token-Based'activation a été activée dans le Service Pack 2 pour Windows Vista et Windows Server 2008.
L’ID d’événement 8208, 8200 ou 900 est enregistré
Cet article fournit une résolution pour l’ID d’événement 8208, 8200 ou 900.
Symptômes
Un ou plusieurs des ID d’événement suivants sont enregistrés dans le journal des applications :
Source : Microsoft-Windows-Security-SPP
Date : <DateTime>
Utilisateur : N/A
Ordinateur : Server1.contoso.com
Description :
Le service de protection logicielle démarre.
Parameters:caller=wsqmcons.exe
Date : <DateTime>
Utilisateur : N/A
Description :
Le service de protection logicielle démarre.
Parameters:caller=WSHost.exe
Date : <DateTime>
Niveau : Error
Utilisateur : N/A
Description :
Détails de l’échec de l’acquisition de licence.
hr=0x80072EE7
Date : <DateTime>
Niveau : Error
Utilisateur : N/A
Description :
Échec de l’acquisition du ticket authentique (hr=0x80072EE7) pour l’ID de modèle {99d92734-d682-4d71-
983e-d6ec3f16059f}
NOTE
Le code 0x80072EE7'erreur indique que le système n’avait pas l’accès Internet approprié pour obtenir le ticket d’Windows
d’authenticité.
Cause
Ces ID d’événement peuvent être enregistrés si une application ou un composant dans Windows tente de
valider et d’appeler les API Genuine Advantage pour acquérir un ticket d’avantage authentique Windows s’il n’en
existe pas. Par exemple, ces ID d’événement peuvent être enregistrés dans les situations suivantes :
Vous optez pour le Programme d’amélioration de l’expérience utilisateur (CEIP). (Caller=wsqmcons.exe)
Vous installez la fonctionnalité Expérience utilisateur, qui installe ensuite le Microsoft Store.
(Caller=wshost.exe)
NOTE
Lorsque vous essayez d’accéder au Microsoft Store, cela déclenche une demande de ticket d’avantage authentique
Windows et une tentative d’acquisition d’un ticket par validation.
Résolution
Les événements mentionnés dans la section « Symptômes » sont consignés si le système n’a pas accès à
Internet. Pour empêcher ces événements de se produire, connectez le système à Internet, puis vérifiez les
paramètres du pare-feu et du proxy.
Si vous ne pouvez pas connecter le système à Internet, vous pouvez essayer les méthodes suivantes pour
empêcher l’ID d’événement 900, en fonction de l’identité du programme de l’appelant :
Si caller=wsqmcons.exe, ouvrez le Gestionnaire de serveur, puis désouvrez la case à cocher Par ticipants
pour refuser le programme CEIP.
Si Caller=wshost.exe, désactivez l’application Microsoft Store en activant la configuration ordinateur\Modèles
d’administration\Windows Components\Store\Désactiver la stratégie d’application du Store dans la stratégie
de groupe locale ou de domaine.
NOTE
L’impossibilité d’obtenir Windows ticket d’avantage authentique peut ne pas empêcher le composant de fonctionner. La
présence de ces ID d’événement ne signifie pas que l’ordinateur n’est pas authentique ou qu’un problème de licence
existe.
La fonctionnalité Genuine Advantage est conçue pour les systèmes d’exploitation clients et n’est généralement
pas trouvée sur un serveur. Toutefois, il est possible pour un composant Windows’utiliser les API Genuine
Advantage Windows si c’est le cas.
Pour plus d’informations sur l’activation en volume, consultez la rubrique Microsoft TechNet suivante :
Vue d’ensemble de l’activation en volume
Pour plus d’informations Windows l’avantage authentique, consultez l’article Windows suivant :
Authentiques Windows : questions fréquemment posées
Erreur lorsque vous essayez d’activer Windows
Server 2003 sur Internet : Numéro de message
32777
Cet article fournit des solutions de contournement à un problème dans lequel vous voyez une erreur lorsque
vous activez Microsoft Windows Server 2003 sur Internet échoue.
Symptômes
Lorsque vous essayez d’activer Windows Server 2003 sur Internet, Windows Product Activation risque d’être
infructueuse et vous pouvez être face aux problèmes suivants :
Vous recevez un message qui vous demande un nom d’utilisateur et un mot de passe.
Impossible d’établir une connexion avec le serveur d’activation. Vérifiez vos paramètres réseau et
vérifiez que vous êtes en mesure de vous connecter à Internet, puis essayez à nouveau. Numéro de
message 32777.
Windows L’activation du produit échoue si vous entrez ou non votre nom d’utilisateur et votre mot de passe.
Cause
Ce problème se produit si les deux conditions suivantes sont vraies :
La configuration de sécurité renforcée de Microsoft Internet Explorer est activée sur le serveur.
Vous vous connectez à Internet via un serveur proxy où l’authentification de base est activée.
La configuration de sécurité renforcée d’Internet Explorer (également appelée renforcement de la sécurité
Internet Explorer) utilise la révocation de certificats. Ce processus de recherche de révocation de certificats
implique une opération de récupération d’URL. Dans ce cas, la récupération d’URL passe par le serveur proxy et
se produit en dehors du contexte explicite de l’utilisateur connecté. Par conséquent, l’authentification de base
vous invite par erreur à utiliser un nom de compte d’utilisateur et un mot de passe. En tant qu’utilisateur, vous
ne savez généralement pas que les certificats sont en cours de validation et vous pouvez être invité à plusieurs
reprises lors de la validation d’une série de certificats.
NOTE
Les méthodes suivantes sont répertoriées dans l’ordre des méthodes préférées à moins privilégiées, la méthode la plus
préférée apparaissant en premier.
Solution de contournement 1 : ne pas utiliser l’authentification de

base
Évitez d’utiliser l’authentification de base sur le serveur proxy. Si vous devez utiliser l’authentification de base,
excluez les URL des listes de révocation de certificats (CRL) de l’exigence d’authentification de base. Pour ce faire,
configurez la liste suivante de listes de listes de contrôle d’accès pour qu’elle ne soit pas authentifié sur le
serveur proxy :
http://crl.microsoft.com/pki/crl/productsMicrosoftProductSecureServer.crl
http://crl.microsoft.com/pki/crl/products/MicrosoftProductSecureCommunications.crl
http://crl.microsoft.com/pki/crl/products/MicrosoftRootAuthority.crl
http://www.microsoft.com/pki/crl/productsMicrosoftProductSecureServer.crl
http://www.microsoft.com/pki/crl/products/MicrosoftProductSecureCommunications.crl
http://www.microsoft.com/pki/crl/products/MicrosoftRootAuthority.crl
Solution de contournement 2 : activer à l’aide du téléphone

Si vous recevez le message d’erreur décrit dans la section Symptômes de cet article lorsque vous essayez
d’activer Windows, cliquez sur le bouton Téléphone de l’Assistant Activer Windows pour activer Windows par
téléphone.
Solution de contournement 3 : désactiver la révocation de certificats

dans Internet Explorer
Désactivation de la révocation de certificats dans Internet Explorer pour permettre Windows l’activation. Pour ce
faire, procédez comme suit.
NOTE
Microsoft recommande de ne pas désactiver la révocation de certificats dans Internet Explorer.
1. Démarrez Internet Explorer.

2. Dans le menu Outils , cliquez sur Options Internet .
3. Cliquez sur l’onglet Avancé, puis cochez les cases suivantes dans la Paramètres suivante :
Vérifier la révocation de cer tificats de l’éditeur
Vérifier la révocation des cer tificats de ser veur (redémarrage nécessaire)
4. Dans la zone Plan de numérotation (contexte téléphonique) , cliquez sur Parcourir pour localiser le
plan de numérotation de l’utilisateur.
5. Quittez, puis redémarrez Internet Explorer.
6. Activez Windows.
7. Dans Internet Explorer, cliquez sur Options Internet dans le menu Outils.
8. Cliquez sur l’onglet Avancé, puis cochez les cases suivantes dans la Paramètres suivante :
Vérifier la révocation de cer tificats de l’éditeur
Vérifier la révocation des cer tificats de ser veur (redémarrage nécessaire)
9. Dans la zone Plan de numérotation (contexte téléphonique) , cliquez sur Parcourir pour localiser le
plan de numérotation de l’utilisateur.
10. Quittez, puis redémarrez Internet Explorer.
Étant donné que d’autres problèmes peuvent générer le numéro de message d’erreur 32777, vous pouvez
afficher le fichier Setuplog.txt pour déterminer si le problème décrit dans cet article est à l’origine de cette erreur.
Le code d’état 407 indique généralement l’occurrence du problème décrit dans cet article. Voici un exemple de
code d’état 407 tel qu’il apparaît dans Setuplog.txt fichier :
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,4423,,DISPID_EXTERNAL_CONNECTED
TOINTERNETEx
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,1560,,tries to connect to the WPA HTTP
server
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,2170,,Disabled RAS Autodial for current
logon session
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,1480,,HTTP status code from WPA HTTP
server 407
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,2184,,Restore value of RAS Autodial for
current logon session
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobcomm\connmgr.cpp,1657,could connect to WPA HTTP
server
<DateTime>,OOBE Trace,0,,GetPreferredConnection: null
<DateTime>,OOBE Trace,0,,UseModem: false
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,3049,,DISPID_EXTERNAL_CONNECT
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,3054,,DISPID_EXTERNAL_RECONNECT
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,4500,,DISPID_EXTERNAL_ACTIVATE
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,6979,,Waiting for response from
m_pLicenseAgent->AsyncProcessHandshakeRequest()
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,5724,,m_pLicenseAgent-
>AsyncProcessHandshakeRequest() a échoué. Erreur = 32777
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,311,,Windows Product Activation error.
<DateTime>,d:\dnsrv\base\ntsetup\oobe\msobmain\msobmain.cpp,313,,ReturnActivationStatus: Status = 7,
Detail = 32777
<DateTime>,OOBE Trace,0,,Activation failed. Erreur = 7
Comment modifier la clé de produit licence en
volume
Cet article explique comment modifier la clé de produit de licence en volume.

Introduction
WARNING
Les étapes de l’article sont effectives uniquement sur les supports de licence en volume. Si vous essayez ces étapes sur un
support OEM ou sur un support commercial, vous ne modifierez pas la clé de produit.
Lorsque vous installez Windows XP ou Windows Server 2003, le média doit correspondre à la clé de produit.
Autrement dit, le canal (MSDN, vente au détail, OEM, licence en volume, etc.), la référence (Windows XP
Professional, Windows XP Édition familiale, etc.) et la langue (anglais, français, etc.) doivent correspondre entre
la clé de produit et le média. Elle est nécessaire pour que vous parliez correctement de la clé de produit. Si le
support d’installation ne correspond pas à la clé de produit, vous recevez le message d’erreur suivant :
La clé de produit n’est pas valide.
Si vous utilisez une clé de produit « divulguée » (une clé de produit connue du public) pour déployer Windows
XP sur plusieurs ordinateurs (installation de licences en volume), il se peut que vous ne soyez pas en mesure
d’installer Windows XP Service Pack 1 (SP1) et les versions ultérieures de Windows XP, ou d’obtenir
automatiquement des mises à jour à partir du site Web Windows Update. Par exemple, vous pouvez recevoir le
message d’erreur suivant lorsque vous installez Windows XP SP1 et les versions ultérieures de Windows XP :
La clé de produit utilisée pour installer Windows est non valide. Veuillez contacter immédiatement votre
administrateur système ou votre revendeur pour obtenir une clé de produit valide. Vous pouvez également
contacter l’équipe anti-piratage de Microsoft Corporation par courrier électronique si vous pensez avoir
acheté des logiciels piracy@microsoft.com Microsoft pirates. N’hésitez pas à vous assurer que toutes les
informations personnelles que vous envoyez à l’équipe microsoft de lutte contre le piratage resteront
strictement confidentielles.
Cet article est destiné à un utilisateur d’ordinateur avancé. Il vous sera peut-être plus facile de suivre les étapes si
vous imprimez cet article en premier.
Vous devez avoir une clé de produit valide avant de pouvoir utiliser les informations de cet article. Pour obtenir
une clé de produit valide, cliquez sur le lien suivant pour contacter le Centre de gestion des licences en volume
Microsoft :
https://www.microsoft.com/licensing/servicecenter/home.aspx
Étapes pour modifier la clé de produit de licence en volume
Cet article décrit deux méthodes pour modifier la clé de produit XP Windows après une installation de licence en
volume pour résoudre le problème. Une méthode utilise l’interface utilisateur graphique (GUI) Windows
l’Assistant Activation et l’autre utilise un script WMI (Windows Management Instrumentation). La méthode de
l’Assistant Activation est plus simple. Toutefois, si vous devez modifier la clé de produit pour plusieurs
ordinateurs, la méthode de script est plus appropriée.
Méthode 1 : utiliser l’Assistant Activation
IMPORTANT
Si vous n’avez que quelques clés de produit de licence en volume à modifier, vous pouvez utiliser l’Assistant Activation.
NOTE
Nous vous recommandons d’exécuter la restauration du système pour créer un point de restauration avant de suivre ces
étapes.
D é sa c t i v e r l a W i n d o w s

2. Dans la zone Ouvrir, tapez regedit, puis cliquez sur OK.
3. Dans le volet de navigation, recherchez et cliquez sur la clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WPAEvents
4. Dans le volet de rubriques, cliquez avec le bouton droit sur OOBETimer, puis cliquez sur Modifier.
5. Modifiez au moins un chiffre de cette valeur pour désactiver la Windows.
Réac t i ver W i n do w s et aj o u t er u n e n o u vel l e c l é de pr o du i t

2. Dans la zone Ouvrir, tapez la commande suivante, puis cliquez sur OK.
%systemroot%\system32\oobe\msoobe.exe /a
3. Cliquez sur Oui, je veux téléphoner à un représentant du service clientèle pour activer Windows, puis
cliquez sur Suivant .
4. Cliquez sur Modifier la clé de produit.
5. Tapez la nouvelle clé de produit dans les zones de la nouvelle clé, puis cliquez sur Mettre à jour.
Si vous êtes renvoyé à la fenêtre précédente, cliquez sur Me le rappeler ultérieurement, puis redémarrez
l’ordinateur.
6. Répétez les étapes 1 et 2 pour vérifier que Windows est activé. Vous recevez le message suivant :
Windows est déjà activé. Cliquez sur OK pour quitter.
7. Cliquez sur OK .
8. Installez Windows XP Service Pack 1a ou une version ultérieure de Windows XP.
Si vous ne pouvez pas redémarrer Windows après avoir installé Windows XP SP1 ou une version ultérieure de
Windows XP, essayez les étapes suivantes :
1. Redémarrez votre ordinateur et commencez à appuyer sur F8 jusqu’à ce que vous Windows menu Options
avancées.
2. Sélectionnez Dernière bonne configuration connue dans le menu, puis appuyez sur Entrée. Cette option
démarre la Windows à l’aide d’une bonne configuration précédente.
3. Répétez les étapes 1 à 8 sous « Réactiver Windows et ajouter une nouvelle clé de produit ».
Si vous pouvez installer SP1 ou une version ultérieure de Windows XP et redémarrer Windows, vous avez résolu
le problème. Si le problème n’a pas été résolu, essayez la méthode 2 ou consultez la section « Étapes suivantes »
pour plus de ressources de dépannage.
Méthode 2 : Utiliser un script
Si vous devez modifier la clé de produit pour plusieurs ordinateurs, nous vous recommandons cette méthode.
Vous pouvez créer un script WMI qui modifie la clé de produit de licence en volume, puis déployer ce script dans
un script de démarrage.
L’exemple ChangeVLKey2600.vbs script et l’exemple de script ChangeVLKeySP1 décrits dans cette section
utilisent la nouvelle clé de licence en volume que vous souhaitez entrer en tant qu’argument unique. Elle se
trouve sous une forme alphanumérique en cinq partie.
Nous vous recommandons d’utiliser le script ChangeVLKey2600.vbs sur les ordinateurs basés sur Windows XP
qui n’exécutent pas Windows XP SP1 et les versions ultérieures de Windows XP et d’utiliser le script
ChangeVLKeySP1.vbs sur les ordinateurs basés sur Windows XP qui exécutent Windows XP SP1 et les versions
ultérieures de Windows XP. Ces scripts effectuent les fonctions suivantes :
Ils suppriment les caractères de tiret (-) de la clé de produit alphanumérique en cinq partie.
Ils créent une instance de la win32_WindowsProductActivation classe.
Ils appellent la méthode SetProductKey avec la nouvelle clé de produit de licence en volume. Vous pouvez
créer un fichier de lots ou un fichier cmd qui utilise l’un des exemples de scripts suivants, ainsi que la
nouvelle clé de produit comme argument.
Vous pouvez le déployer dans le cadre d’un script de démarrage ou l’exécuter à partir de la ligne de commande
pour modifier la clé de produit sur un seul ordinateur.
Ex e m p l e s
Pour plus d’informations sur la façon de scripter la clé de produit, visitez le site Web Microsoft suivant :
https://technet.microsoft.com/library/bb457096.aspx
C h a n g e V L K e y SP 1 .v b s
'
' WMI Script - ChangeVLKey.vbs
'
' This script changes the product key on the computer
'
'***************************************************************************
if Wscript.arguments.count<1 then
Wscript.echo "Script can't run without VolumeProductKey argument"
Wscript.echo "Correct usage: Cscript ChangeVLKey.vbs ABCDE-FGHIJ-KLMNO-PRSTU-WYQZX"
Wscript.quit
end if
Dim VOL_PROD_KEY
VOL_PROD_KEY = Wscript.arguments.Item(0)
VOL_PROD_KEY = Replace(VOL_PROD_KEY,"-","")'remove hyphens if any
for each Obj in GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf

("win32_WindowsProductActivation")
result = Obj.SetProductKey (VOL_PROD_KEY)
if err <> 0 then
WScript.Echo Err.Description, "0x" & Hex(Err.Number)
Err.Clear
end if
Next
C h a n g e V L K e y 2 6 0 0 .v b s
'
' WMI Script - ChangeVLKey.vbs
'
' This script changes the product key on the computer
'
'***************************************************************************
if Wscript.arguments.count<1 then
Wscript.echo "Script can't run without VolumeProductKey argument"
Wscript.echo "Correct usage: Cscript ChangeVLKey.vbs ABCDE-FGHIJ-KLMNO-PRSTU-WYQZX"
Wscript.quit
end if
Dim VOL_PROD_KEY
VOL_PROD_KEY = Wscript.arguments.Item(0)
VOL_PROD_KEY = Replace(VOL_PROD_KEY,"-","")'remove hyphens if any
Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.RegDelete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WPAEvents\OOBETimer" 'delete OOBETimer
registry value
for each Obj in GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf
("win32_WindowsProductActivation")
result = Obj.SetProductKey (VOL_PROD_KEY)

if err <> 0 then
WScript.Echo Err.Description, "0x" & Hex(Err.Number)
Err.Clear
end if
Next
L’exemple suivant montre comment utiliser le script ChangeVLKeySP1.vbs à partir d’une ligne de commande :
2. Dans la zone Ouvrir, tapez la commande suivante, où AB123-123AB-AB123-123AB-AB123 est la
nouvelle clé de produit que vous souhaitez utiliser, puis cliquez sur OK :
c:\changevlkeysp1.vbs ab123-123ab-ab123-123ab-ab123
Comment reconstruire le fichier Tokens.dat lorsque
vous résolvez les problèmes d’activation de
Windows
Lorsque vous résolvez les problèmes d’activation de Windows, vous devrez peut-être reconstruire le fichier
Tokens.dat.
S’applique à : Windows 10 : toutes les éditions, Windows Server 2012 R2, Windows Server 2019 Windows
Server 2016
Reconstruire le fichier Tokens.dat

1. Ouvrez une invite de commandes avec élévation de privilèges :
a. Ouvrez le menu Démarrer ou l’écran de démarrage, cmd de recherche.
b. Cliquez avec le bouton droit sur l’invite de commandes dans les résultats de la recherche, puis
sélectionnez Exécuter en tant qu’administrateur .
2. Tapez les commandes suivantes dans l’ordre dans lequel elles sont présentées. Appuyez sur Entrée après
chaque commande.
a. net stop sppsvc
b. Pour Windows 10, Windows Server 2016 et versions ultérieures de Windows :

cd %windir%\system32\spp\store\2.0
Pour Windows 8.1 et Windows Server 2012 R2 :

cd %windir%\system32\spp\store\2.0
Pour Windows 8 et Windows Server 2012 :

cd %windir%\system32\spp\store
Pour Windows 7, Windows Server 2008 et Windows Server 2008 R2 :

cd %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform
NOTE
Pour les Windows 8.1 qui ont été mises à niveau à partir de Windows 8, l’emplacement peut toujours être
%windir%\system32\spp\store.
c. ren tokens.dat tokens.bar
d. net start sppsvc
e. cscript.exe %windir%\system32\slmgr.vbs /rilc
Après avoir régénéré le fichierTokens.dat, vous devez réinstaller votre clé de produit à l’aide de l’une des
À la même commande d’invite avec élévation de privilèges, tapez la commande suivante, puis appuyez
sur Entrée :
cscript.exe %windir%\system32\slmgr.vbs /ipk \<product key>
Cliquez avec le bouton droit sur Mon ordinateur , sélectionnez Propriétés , puis sélectionnez
Modifier la clé de produit .
NOTE
Vous ne devez jamais utiliser le /upk commutateur pour désinstaller une clé de produit. Pour installer une clé de
produit sur une clé de produit existante, utilisez le /ipk commutateur.
Pour plus d’informations sur les clés d’installation du client KMS (Key Management Services), consultez l’activation du
client KMS et les clés de produit.
La base de données spécifiée n’est pas un message
d’erreur de base de données Outil Gestion de
l'activation en volume valide lorsque vous essayez
de créer une base de données à l’aide de Outil
Gestion de l'activation en volume 3.0 sur un
ordinateur Windows 8 ou Windows Server 2012.
Cet article décrit un problème dans lequel vous ne pouvez pas créer une base de données à l’aide Outil Gestion
de l'activation en volume 3.0.
Symptômes
Lorsque vous essayez de créer une base de données à l’aide de Outil Gestion de l'activation en volume (Outil
Gestion de l'activation en volume) 3.0 sur un ordinateur exécutant Windows 8 ou Windows Server 2012, vous
La base de données spécifiée n’est pas une base de données Outil Gestion de l'activation en volume valide.
Cause
Le problème se produit car le compte que vous utilisez pour vous connecter à l’ordinateur ne peut pas créer la
base de données.
Résolution
Pour résoudre le problème, connectez-vous à l’ordinateur en tant qu’administrateur local, puis essayez de créer
la base de données. Si le problème se produit toujours, installez Microsoft SQL Server 2008 R2 Management
Studio Express (SSMSE), puis accordez-vous les autorisations pertinentes.
Pour télécharger SSMSE, allez sur le site web Microsoft suivant :
Microsoft SQL Server 2008 R2 RTM - Management Studio Express
Pour plus d’informations SQL Server autorisations d’accès, voir le site web Microsoft suivant :
Sécurité et protection (Moteur de base de données)
Windows L’activation échoue avec un code d’erreur :
0x8007267C
Cet article fournit des solutions à un problème dans lequel l’activation Windows échoue avec le code d’erreur
0x8007267C.
Symptômes
Windows L’activation échoue avec le code d'0x8007267C.
Cause
Ce problème se produit si l’ordinateur qui tente de s’activer n’a pas de serveur DNS enregistré dans ses
propriétés réseau.
Code d’erreur 0x8007267C définition :

Aucun serveur DNS configuré pour le système local
DNS_ERROR_NO_DNS_SERVERS
Résolution 1 : inscrire le serveur DNS dans les propriétés réseau et

tester la résolution des noms
Pour résoudre ce problème, la connectivité du client à un serveur DNS doit être résolue. Les étapes suivantes
peuvent vous aider à exposer le problème :
1. Sur le client obtenant l’erreur, ouvrez une invite de commandes et exécutez IPCONFIG /all .
2. Vérifiez que l’adresse IP affectée, le masque de sous-réseau, le serveur DNS et la passerelle par défaut
sont définies avec les valeurs correctes pour votre environnement.
3. Vérifiez la connectivité IP de base au serveur DNS à l’aide de la commande PING à l’aide de l’adresse du
serveur DNS de l’étape 1.
ping <DNS Server IP address>
Si la connectivité au serveur DNS échoue, envisagez d’utiliser ce qui suit comme guide pour résoudre les
problèmes supplémentaires :
Résolution des problèmes TCP/IP
Après avoir résolu les problèmes de connectivité au serveur DNS, réattemptez l’activation à l’aide de la
commande suivante à partir d’une invite de commandes avec élévation de niveau élevé
cscript \windows\system32\slmgr.vbs -ato
Résolution 2 : utiliser une clé MAK (clé d’activation multiple) et une

activation par téléphone
Si vous n’avez pas de serveur DNS connecté au réseau, vous pouvez basculer vers une clé de produit MAK pour
activer l’installation de votre licence en volume. Si vous utilisez des médias MSDN ou TechNet, vous devez
modifier la clé de produit en clé de produit fournie. La clé de produit MSDN ou la clé de produit TechNet pour
Windows Server 2008 ou Windows Vista Enterprise est la clé de produit MAK.
Utilisez la commande suivante pour modifier la clé de produit en clé de produit MAK :
slmgr -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
Ensuite, lancez l’Assistant Activation de téléphone pour terminer l’activation de la slui 04 de l’ordinateur.
Windows’installation échoue avec une erreur : la clé
de produit entrée ne correspond à aucune des
images Windows disponibles pour l’installation.
Entrer une autre clé de produit
Cet article décrit la clé de produit entrée ne correspond à aucune des images Windows disponibles pour
l’installation. Entrez une autre erreur de clé de produit qui se produit lors de l’installation Windows.
2012 R2
Symptômes
Lors de l’installation Windows, le programme d’installation peut échouer après l’invite de sélections de langue
et de clavier. En outre, le message d’erreur suivant peut s’afficher :
La clé de produit entrée ne correspond à aucune des images Windows disponibles pour l’installation. Entrez
une autre clé de produit.
Cause
Ce problème peut se produire si la clé de produit fournie ne correspond pas au média utilisé pour installer
Windows. La clé de produit fournie peut se présenter dans un fichier sans surveillance, dans l’AE. Fichier CFG,
dans le fichier PID.txt ou dans le microprogramme du BIOS. Windows les ordinateurs qui sont envoyés avec le
système d’exploitation installé sont envoyés avec la clé de produit dans le microprogramme, et si cette clé de
produit ne correspond pas au média, le message d’erreur ci-dessus s’est produit.
Par exemple , l’installation Windows server sur un ordinateur qui provenait du fabricant Windows 10 est
susceptible de provoquer ce problème.
Résolution
Pour résoudre ce problème, utilisez l’une des méthodes suivantes qui s’applique au scénario :
1. S’il existe un fichier sans surveillance, un fichier EI.cfg (Edition Configuration) ou un fichier d’ID de produit
(PID.txt) sur le système, modifiez la clé de produit sur la clé de produit correcte pour le média que vous
essayez d’installer.
2. Si le système dispose d’une clé Product dans la carte mère (O. R. 3.0 [OEM Activation] fournit une clé de
produit OEM dans le microprogramme) vous devez utiliser un fichier sans surveillance, un fichier de
configuration d’édition (EI.cfg) ou le fichier d’ID de produit (PID.txt).
Lors de l’installation Windows, setup.exe utilise la logique de priorité suivante pour les clés de produit :
1. Fichier de réponses (fichier sans surveillance, EI.cfg ou PID.txt)
2. Clé de produit OA 3.0 dans le BIOS/Microprogramme
3. Écran d’entrée de la clé de produit
Si une clé est fournie, la clé est tentée d’être utilisé avec l’image disponible sur le média en cours d’installation.
Si la clé de produit fournie ne correspond pas à l’étape 1 de la logique ci-dessus, une image dans le fichier WIM
échoue avec le message d’erreur mentionné dans la section Symptômes. Si aucune clé de produit n’est fournie
aux étapes 1 et 2, vous recevrez l’invite de clé de produit lors de l’installation.
NOTE
Le support de licence en volume fournit une clé de produit avec le média afin qu’il réussisse avec la logique de l’étape
1.
Vous ne devriez pas voir ce problème avec le support de licence en volume, sauf si vous utilisez un fichier sans
surveillance ou que vous avez modifié des fichiers sur le média pour modifier ou remplacer le fichier EI.cfg ou PID.txt.
Comment déposer une PID.txt avec la clé de produit spécifiée : Windows Configuration de setup Edition et fichiers d’ID
de produit (EI.cfg et PID.txt)
Erreur « Arrêter 0x0000007B » après avoir utilisé un
paramètre de stratégie de groupe pour empêcher
l’installation des appareils
Cet article permet de corriger l’erreur « Arrêter 0x0000007B » après avoir utilisé un paramètre de stratégie de
groupe pour empêcher l’installation des appareils.
Symptômes
Vous avez un ordinateur qui exécute Windows 7 ou Windows Server 2008 R2.
Utilisez le paramètre de stratégie de groupe suivant pour restreindre l’installation des appareils sur
l’ordinateur : Configuration ordinateur\Modèles d’administration\Système\Installation de
périphérique\Restrictions d’installation de périphériques
Par exemple, vous activez l’un des paramètres de stratégie de groupe suivants :
Empêcher l’installation d’appareils qui correspondent à l’un de ces ID d’appareil
Empêcher l’installation d’appareils à l’aide de pilotes qui correspondent à ces classes de configuration
d’appareil
Empêcher l’installation d’appareils amovibles
Empêcher l’installation d’appareils non décrits par d’autres paramètres de stratégie. Pour plus
d’informations sur ce paramètre de stratégie de groupe, voir guide pas à pas pour contrôler
l’installation d’appareils à l’aide de la stratégie de groupe.
Vous désinstallez un pilote de contrôleur SATA (Serial ATA) tiers, puis redémarrez l’ordinateur. Sinon, vous
exécutez sysprep et déployez l’image du système d’exploitation sur un autre ordinateur qui dispose d’un
autre contrôleur de stockage ou qui exécute une révision différente du microprogramme du contrôleur de
stockage.
Dans ce scénario, vous rencontrez une erreur « Arrêter 0x0000007B » lors du redémarrage.
Cause
Une fois que vous avez activé le paramètre de stratégie de groupe, les entrées de Registre suivantes sont
définies de sorte que l’accès à la base de données d’appareils critiques soit interdit et que les périphériques
bruts ne peuvent pas être démarrés :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PnP\DisableCDDB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PnP\DontStartRawDevices
Par conséquent, le pilote du contrôleur de stockage est in trouver et vous rencontrez l’erreur « Arrêter
0x0000007B ».
Résolution
Pour résoudre le problème, définissez les entrées de Registre suivantes sur 0 :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PnP\DisableCDDB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PnP\DontStartRawDevices
1. Démarrez l’ordinateur à Windows PE. Pour créer une image Window PE, voir Walkthrough: Create a
Custom Windows PE Image.
2. Chargez la ruche du Registre système pour la modification du Registre hors connexion. La ruche du
Registre système se trouve dans %SystemRoot%\system32\config. Pour ce faire, suivez les étapes de la
procédure de chargement ou de déchargement des ruches du Registre.
3. Développez la ruche du Registre système que vous avez chargée, puis cliquez sur Sélectionner.
4. Dans le volet d’informations, recherchez Actuel, puis notez la valeur dans la colonne Données.
5. Développez l’entrée de Registre suivante. (L’espace réservé x représente la valeur de la colonne
Données que vous avez notée à l’étape 4.) HKEY_LOCAL_MACHINE\SYSTEM\ControlSet00 x
\Control\PnP
6. Modifiez la valeur de DisableCDDB et DontStartRawDevices sur 0.
7. Déchargez la ruche du Registre.
8. Redémarrez l’ordinateur de manière standard.
NOTE
Ces étapes ne suppriment aucun paramètre de stratégie.
Erreur « Cet appareil ne peut pas démarrer » lors du
déploiement d’un SSD NVMe en plug-in
S’applique à : Windows Serveur, version 2004, toutes les éditions, Windows Server, version 1903, toutes les
éditions, Windows Server 2019, toutes les éditions, Windows Server 2016, Windows Server 2016 Datacenter,
Windows Server 2016 Standard
Lors du déploiement d’un disque SSD (NVM Express) de plug-in à chaud qui prend en charge une taille de
charge utile maximale (MPS) inférieure à la mps de bus PCIe (Peripheral Component Interconnect Express)
actuellement configurée, le périphérique SSD ne peut pas être détecté ni éumé et vous recevez le message
Cet appareil ne peut pas démarrer. Essayez de mettre à niveau les pilotes de périphérique pour cet appareil.
(Code 10)
Tous les périphériques SSD NVMe qui prendre en charge la fonctionnalité de permutation à chaud/plug-in
doivent prendre en charge la même valeur MPS (ou supérieure) que la hiérarchie MPS de bus NVMe PCIe
existante dans Windows Server. Le pilote PCIe ne peut pas modifier dynamiquement la valeur MPS existante de
la hiérarchie. Si un nouvel appareil est branché à chaud sur un bus NVMe PCIe existant qui ne prend pas en
charge la valeur MPS initialisée lors du processus de démarrage, la détection et l’éumération de l’appareil
échouent.
Redémarrez le serveur pour initialiser la valeur MPS de bus NVMe PCIe sur celle de l’appareil SSD qui a le mps
le plus bas. Dans le cas contraire, contactez le fabricant du système ou de l’appareil pour obtenir de l’aide
supplémentaire.
Installation de l’adaptateur microsoft loopback dans
Windows
Cet article vous aide à résoudre un problème dans lequel vous ne trouvez pas l’adaptateur de rappel Microsoft.
S’applique à : Windows 10 : toutes les éditions, Windows Server 2012 R2
Symptômes
Vous essayez d’installer l’adaptateur de rappel Microsoft, mais vous ne pouvez pas le trouver.
Cause
L’adaptateur Microsoft Loopback a été renommé en Windows 8 et Windows Server 2012. Le nouveau nom est «
Microsoft KM-TEST Loopback Adapter ».
Résolution
Lorsque vous utilisez l’Assistant Ajout de matériel pour ajouter manuellement une carte réseau, choisissez
Fabricant « Microsoft » et choisissez carte réseau « Adaptateur de bouclage KM-TEST Microsoft ».
Vous ne pouvez pas installer un pilote VMWare sur
Cet article fournit une solution de contournement pour un problème dans lequel vous ne pouvez pas installer
un pilote VMWare sur un serveur exécutant Windows Server 2008 R2 et sur lequel le service Telnet Server est
installé.
Symptômes
Sur un ordinateur exécutant Windows Server 2008 R2, vous ajoutez un adaptateur Ethernet à un
environnement VMWare vSphere.
Le service Telnet Server est installé.
Dans le logiciel enfichable Services de la console MMC (Microsoft Management Console), vous configurez le
service Telnet Server pour qu’il démarre manuellement ou automatiquement.
Dans le logiciel enfichable Services, vous configurez le service Telnet Server pour qu’il se connecte à l’aide du
compte système local. En outre, vous ne sélectionnez pas la case à cocher Autoriser le ser vice à interagir
avec le Bureau.
Dans ce scénario, lorsque vous essayez d’installer le pilote via le Gestionnaire de périphériques, la tentative
échoue et vous recevez le message d’erreur suivant :
Windows avez trouvé le logiciel de pilote pour votre appareil, mais a rencontré une erreur lors de la
tentative de l’installer.
Après l’échec de l’installation, vous essayez sans succès d’installer un autre adaptateur Ethernet disponible à
partir de la liste des Paramètres vm. Par exemple, vous sélectionnez Intel E1000. Toutefois, le deuxième pilote ne
s’installe pas non plus. En outre, une entrée de journal semblable à ce qui suit est consignée dans
Setupapi.dev.log sous %windir%/inf/ :
dvi : {Plug-and-Play Service: Device Install for

PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01\FF565000B37984FE00}
ump : création du processus d’installation : DrvInst.exe <DateTime>
ump : Le processus d’installation du serveur s’est quitté avec le code 0xc0000142 <DateTime>
ump : {Plug-and-Play Service: Device Install exit(c0000142)}
ndv : Échec de l’installation de l’appareil pour le nouvel appareil... installation du pilote NULL.
Cause
Ce problème se produit car le service Telnet Server modifie certaines autorisations liées à la sécurité lors de
l’initialisation de la station de fenêtre dans qui il s’exécute. Si vous configurez le service Telnet Server pour qu’il
s’exécute à l’aide du compte système local sans pouvoir interagir avec le Bureau, le service démarre sous une
autre station de fenêtre. Cela peut entraîner des conflits avec d’autres processus qui s’exécutent également sous
le compte système local et qui n’interagissent pas avec le Bureau, tels que le processus d’installation d’un
nouveau pilote de périphérique.
Pour contourner ce problème, n’exécutez pas le service Telnet Server sous le compte Système local. Nous vous
recommandons de laisser le service Telnet Server s’exécuter sous son compte de service local par défaut.
Si cela ne corrige pas temporairement le problème, vérifiez que la dernière version des outils VMWare est
installée. Si vous ne pouvez pas mettre à jour ou désinstaller les outils VMWare, suivez les étapes suivantes :
1. Obtenez les fichiers d’installation de la dernière version des outils VMWare.
2. Cliquez sur Démarrer, tapez cmd dans la zone Démarrer la recherche, puis cliquez sur OK.
NOTE
Une fenêtre d’invite de commandes s’ouvre.
3. À l’invite de commandes, modifiez le lecteur en lecteur de CD-ROM (par exemple, lecteur D).
4. Tapez, puis appuyez sur Entrée pour forcer la suppression de toutes les entrées de Registre et supprimer
les versions précédentes setup /c des outils VMware.
NOTE
Pour les systèmes d’exploitation invités 64 bits, tapez setup64 /c à la place.
5. Installez la dernière version des outils VMWare.

6. Vérifiez que le paramètre d’logo du service Telnet est correctement définie.
produits.
Windows Server 2012 Modifications apportées au
comportement de parcer principal par défaut R2
Cet article décrit les modifications apportées au comportement par défaut pour le parcer principal.
Résumé
Le comportement par défaut du parcer principal a changé pour Windows Server 2012. Par défaut, Windows
Server 2012 détecte et active/désactive la fonctionnalité de parceur principal intégrée afin d’optimiser les
performances optimales du processeur en fonction du processeur installé.
Étant donné que le changement de comportement par défaut de Microsoft pour le parcer principal est conçu
pour optimiser les performances du processeur, il n’existe aucune méthode intégrée permettant de réactiver le
parcer principal une fois qu’il est désactivé, car cela peut introduire une dégradation des performances du
processeur.
En raison du risque de dégradation des performances, la modification du comportement par défaut de
l’Windows de parcer principal dans Windows Server 2012 n’est ni recommandée ni prise en charge. Il n’a pas
été conçu/destiné aux fabricants OEM pour modifier la configuration dans l’implémentation actuelle du parcier
principal dans Windows Server 2012.
Actuellement, par défaut, Windows Server 2012 le parcin de base pour les processeurs Intel afin d’optimiser
l’efficacité énergétique et les performances du processeur.
Fonctionnement du parcer principal :
Windows Le parcage de base Windows Server 2012 fonctionne par parcage et par parcage des cœurs selon les
besoins pour s’ajuster à la modification des charges de travail pour des raisons d’efficacité. Le parc d’un cœur, en
soi, n’économise pas d’énergie. Le parcage d’un cœur modifie le comportement du programmeur pour cibler
les threads sur d’autres cœurs. Cela permet au cœur par parcé de rester inactif davantage (réduisant sa
consommation d’énergie), au prix d’un travail supplémentaire sur des cœurs non parcés (augmentation de leur
consommation d’énergie). Le fait que ce compromis entraîne ou non un système plus ou moins efficace dépend
fortement du processeur. Windows est réglé pour sélectionner des paramètres optimaux (parcer le cœur sur ou
hors service) en fonction du processeur installé et selon Windows Server 2012 est considéré comme le plus
efficace.
Activer la détection plug-and-play pour les
appareils de port parallèles
Cet article pas à pas décrit comment activer la fonctionnalité Plug-and-Play sur les appareils qui utilisent un
périphérique de port parallèle.
Résumé
Certains périphériques Plug-and-Play qui utilisent un port parallèle, tels que les versions antérieures des
lecteurs zip Iomega, peuvent ne pas être détectés par les Windows.
Activer la détection plug-and-play

1. Cliquez avec le bouton droit sur l’icône Mon ordinateur sur votre bureau, puis cliquez sur Propriétés.
2. Cliquez sur l’onglet Matériel, puis sur Gestionnaire de périphériques.
3. Cliquez pour développer por ts, cliquez avec le bouton droit sur Port d’imprimante (LPT1), puis cliquez
sur Propriétés.
NOTE
Si plusieurs ports d’imprimante sont installés sur votre ordinateur, cliquez sur LPT2 ou LPT3.
4. Cliquez sur l’onglet Paramètres portage, cliquez sur Activer la détection plug-and-play héritée, puis
cliquez sur OK.
5. Redémarrez votre ordinateur lorsque vous y êtes invité.
Après avoir redémarré votre ordinateur, Windows détecte votre matériel Plug-and-Play et l’Assistant Nouvelle
installation matérielle démarre si le matériel est connecté à l’ordinateur.
NOTE
La case à cocher détection plug-and-play héritée n’est pas sélectionnée par défaut.
produits.
NOTE
Lorsque le Service Pack 2 pour Windows Server 2003 est publié, d’autres périphériques de port parallèle nécessitent que
vous enableiez la détection plug-and-play avant de pouvoir les installer correctement. Plus précisément, vous devez
activer la détection plug-and-play avant d’installer des lecteurs zip Iomega.
ID d’événement d’alimentation du processeur du
noyau 37 après modification de la stratégie
d’alimentation Windows Server 2016
Cet article fournit une solution à un problème dans lequel l’ID d’événement 37 est consigné dans le journal
système après la modification de la stratégie d’alimentation pour un serveur Windows Server 2016 serveur.
Symptômes
Après avoir changé la stratégie d’alimentation d’un serveur Windows Server 2016, vous recevez l’ID
d’événement 37 dans le journal système :
Source : Microsoft-Windows-Kernel-Processor-Power
Description :
La vitesse du groupe y processorxin est limitée par le microprogramme système. Le processeur a été dans
cet état de performances réduites pendant une seconde depuis le dernier rapport.
NOTE
Les valeurs de x, y et z dans le message d’ID d’événement peuvent varier.
Cause
L’ID d’événement 37 est enregistré lorsque la plateforme matérielle détermine que le système d’exploitation ne
peut pas utiliser une plage de fréquences que le processeur prend en charge. Cet événement d’avertissement
avertit l’utilisateur que le processeur ou le cœur de processeur ne peut pas prendre en charge l’exécution à
pleine vitesse.
Résolution
Pour résoudre ce problème, recherchez une stratégie de plafond de l’alimentation du matériel ou vérifiez les
options système pour toute stratégie d’alimentation configurée pour le microprogramme système.
L’ID d’événement 56 est enregistré dans Windows
Server
Cet article fournit de l’aide pour corriger l’ID d’événement 56 qui est enregistré dans Windows Server.
Symptômes
Scénario 1
Au moins deux périphériques de mémoire non volatile (NVMe) de même make/model sont attachés à un
ordinateur Windows Server 2016 ou Windows Server 2019.
Scénario 2
Plusieurs chemins d’accès sont disponibles pour un disque dans Windows Server. Dans ces scénarios, vous
recevez l’ID d’événement 56 dans le journal système.

Source : fenêtre popup d’application
Niveau : Error
Description : Le pilote SCSI a renvoyé un ID non valide pour un appareil enfant (000000).
Cause
Le problème se produit car le gestionnaire plug-and-play (PnP) génère automatiquement des ID d’instance
uniques lorsque des doublons sont trouvés.
Résolution
Cet ID d’événement peut être ignoré en toute sécurité et aucune action de l’utilisateur n’est requise.
NOTE
Dans Windows Server 2012 R2 et Windows Server 2016, l’événement peut s’afficher, mais sans le champ Description
correct, comme illustré ci-dessous. Toutefois, le nom du pilote et le nom de l’appareil enfant sont corrects et peuvent être
utilisés pour identifier le pilote impliqué et le nom de l’appareil enfant.
La description de l’ID d’événement 56 à partir du popup de l’application source est in trouver. Le composant qui
déclenche cet événement n’est pas installé sur votre ordinateur local, ou l’installation est endommagée. Vous
pouvez installer ou réparer le composant sur l’ordinateur local. Si l’événement provient d’un autre ordinateur, les
informations d’affichage ont dû être enregistrées avec l’événement. Les informations suivantes ont été incluses
avec l’événement :
SCSI
000000
La ressource de message est présente, mais le message n’est pas trouvé dans la table chaîne/message.
Message d’erreur lorsque vous insérez une carte à
puce dans un lecteur : le logiciel de pilote de
périphérique n’a pas été installé avec succès
Cet article fournit une solution à une erreur qui se produit lorsque vous insérez une carte à puce dans un lecteur.
Symptômes
Lorsque vous insérez une carte à puce dans un lecteur de carte à puce, Windows tente de télécharger et
d’installer les minidrivers de carte à puce pour la carte via les services Plug-and-Play. Si le pilote de la carte à
puce n’est disponible dans aucun des emplacements préconfigurés, tels que les chemins d’accès Windows
Update, WSUS ou intranet, et qu’un fournisseur de services de chiffrement personnalisé n’est pas déjà installé
sur le système, vous recevez le message d’erreur suivant dans la zone de notification :
Le logiciel de pilote de périphérique n’a pas été installé correctement

Cliquez ici pour plus d’informations.
Ce message d’erreur disparaît après plusieurs secondes.

En outre, dans le Gestionnaire de périphériques, sous Autres appareils, le périphérique de carte à puce présente
l’état DNF (Pilote in trouvé).
Pour résoudre cette erreur, l’utilisateur doit fréquemment obtenir l’un des éléments suivants auprès de
l’émetteur de la carte à puce :
1. Un Windows de carte à puce journalisé.
2. Fournisseur de services de chiffrement personnalisé (CSP) pour la carte à puce.
3. Un Windows de carte à puce sans logo.
4. Autres logiciels intermédiaires tels qu’un ActiveX, un logiciel PKCS#11 ou d’autres logiciels personnalisés.
Toutefois, si l’utilisateur n’est fourni qu’avec l’élément 3 ou 4 de cette liste, la carte à puce continue de
fonctionner sur le système. Toutefois, l’utilisateur reçoit le message d’erreur mentionné dans cette section
chaque fois qu’il insère la carte à puce.
This issue affects all releases of Windows 7, Windows Server 2008 R2, and in later versions of both operating
systems.
Cause
Toutes les cartes à puce nécessitent des logiciels supplémentaires pour fonctionner dans Windows sauf s’il
existe un pilote de boîte de réception qui permet à l’utilisateur d’utiliser la carte sans installer de logiciels
supplémentaires. L’infrastructure de carte à puce Windows a été améliorée dans Windows 7 pour permettre le
téléchargement automatique des minidriveurs de carte à puce à partir de Windows Update ou d’autres
emplacements similaires tels qu’un serveur WSUS lorsque la carte à puce est insérée dans le lecteur. Toutes les
cartes à puce qui réussissent à passer les exigences de logo, telles que publiées par le programme Windows
Logo, bénéficient de cette fonctionnalité.
Toutefois, si le logiciel requis pour utiliser une carte à puce dans Windows n’est pas ouvert ou est d’un type
différent d’un minidriver, tel qu’un pilote PKCS#11, un CSP personnalisé, un logiciel intermédiaire ou un contrôle
ActiveX, l’option de téléchargement automatique échoue car Microsoft certifie uniquement les minidriveurs de
carte à puce. Par conséquent, si l’utilisateur insère une carte pour laquelle un CSP personnalisé n’est pas déjà
inscrit, l’utilisateur reçoit un message d’erreur qui indique que le logiciel de pilote est manquant pour le
périphérique de carte à puce, même si l’utilisateur peut utiliser la carte à puce via un logiciel supplémentaire
installé sur l’ordinateur de l’utilisateur à partir d’une installation personnalisée.
Résolution
Bien que les cartes à puce continuent de fonctionner malgré le message d’erreur que l’utilisateur voit, un
émetteur de carte à puce, un fournisseur ou un fabricant peut utiliser l’une des méthodes suivantes pour
résoudre cette erreur.
Implémenter un minidriver de carte à puce
Nous recommandons aux émetteurs, fournisseurs et fabricants de cartes d’implémenter des minidriveurs de
carte à puce et de participer au programme logo Windows pour bénéficier des améliorations introduites dans la
plateforme, telles que les plug-and-play de carte à puce, l’étape de l’appareil pour les cartes à puce, etc.
Implémenter un pilote NULL pour votre carte à puce
Si un logiciel personnalisé tel qu’un pilote PKCS#11, un contrôle ActiveX ou un autre logiciel intermédiaire est
nécessaire pour activer l’utilisation de la carte à puce sur Windows et si l’implémentation d’un minidriveur de
carte à puce ou d’un fournisseur CSP personnalisé n’est pas une option pratique, nous recommandons aux
émetteurs de cartes, fournisseurs ou fabricants d’envisager d’envoyer des pilotes NULL à Windows Update. Le
processus classique pour s’assurer qu’un pilote NULL est disponible sur Windows Update nécessite une
soumission d’appareil non classifiée réussie via Winqual. Si à l’avenir, un minidriver est disponible pour ces
cartes, le nouveau pilote peut être téléchargé vers Windows Update en participant au programme Windows
Logo. Les pilotes NULL peuvent ensuite être téléchargés manuellement par les utilisateurs finaux ou peuvent
être mis à disposition à l’aide de mises à jour facultatives.
Voici un exemple de modèle pour un pilote NULL pour une carte à puce.
;
; Null Driver for Fabrikam Smartcard installation x86 and x64 package.
;
[Version]
Signature="$Windows NT$"
Class=SmartCard
ClassGuid={990A2BD7-E738-46c7-B26F-1CF8FB9F1391}
Provider=%ProviderName%
CatalogFile=delta.cat
DriverVer=4/21/2006,1.0.0.0
[Manufacturer]
%ProviderName%=Minidriver,NTamd64,NTamd64.6.1,NTx86,NTx86.6.1
[Minidriver.NTamd64]
;This driver has no applicability on OS versions earlier than Windows 7
[Minidriver.NTx86]
;This driver has no applicability on OS versions earlier than Windows 7
[Minidriver.NTamd64.6.1]
%CardDeviceName%=Minidriver64_Install,<DEVICE_ID>
;%CardDeviceName%=Minidriver64_Install,<DEVICE_ID2>
;...
[Minidriver.NTx86.6.1]
%CardDeviceName%=Minidriver32_Install,<DEVICE_ID>
;...
;Leave the following sections blank

[DefaultInstall]
[DefaultInstall.ntamd64]
[DefaultInstall.NTx86]
[DefaultInstall.ntamd64.6.1]
[DefaultInstall.NTx86.6.1]
[Minidriver64_Install.NT]
[Minidriver64_61_Install.NT]
[Minidriver32_Install.NT]
[Minidriver32_61_Install.NT]
[Minidriver64_61_Install.NT.Services]
AddService = ,2
[Minidriver32_61_Install.NT.Services]
AddService = ,2
; =================== Generic ==================================
[Strings]
ProviderName ="Microsoft"
CardDeviceName="Fabrikam Generic Smart card"
Pour générer l’ID de périphérique matériel référencé par la chaîne DEVICE_ID dans l’exemple, suivez les
instructions de la spécification du minidriver de carte à puce.
Pour plus d’informations sur la soumission d’un pilote NULL à Microsoft, contactez les services de support
technique Microsoft.
Désactiver la stratégie de groupe Plug-and-Play de carte à puce pour les ordinateurs gérés
Cette option est recommandée uniquement pour les déploiements d’entreprise où les ordinateurs sont gérés
par des administrateurs et où tous les logiciels nécessaires pour utiliser les cartes à puce utilisées dans
l’entreprise sont installés à l’aide d’outils de gestion de logiciels tels que SMS.
Cette procédure est déconseillée dans les environnements suivants, car elle affecte toutes les cartes à puce de
votre environnement :
Déploiements commerciaux qui ciblent les utilisateurs finaux, tels que les services bancaires en ligne.
Environnements qui incluent des cartes à puce Plug-and-Play et des cartes à puce non plug-and-play qui
utilisent la stratégie de groupe pour désactiver plug-and-play pour les cartes à puce.
Le plug-and-play de carte à puce peut être désactivé dans les entreprises où l’ordinateur de l’utilisateur final est
géré par des mécanismes tels que la stratégie de groupe.
Si votre déploiement utilise uniquement des solutions de carte à puce non plug-and-play, le plug-and-play de
carte à puce peut être désactivé par un administrateur local sur un ordinateur client. La désactivation du plug-
and-play de carte à puce empêche le téléchargement des pilotes de carte à puce, également appelés
minidriveurs de carte à puce. Elle empêche également les invites de lecture et de plug-and-play de carte à puce.
Pour désactiver le plug-and-play de carte à puce dans la stratégie de groupe locale, suivez les étapes suivantes :
1. Cliquez sur Démarrer, tapez gpedit.msc dans la zone Rechercher des programmes et des fichiers, puis
2. Dans l’arborescence de la console, sous Configuration ordinateur, cliquez sur Modèles
d’administration.
3. Dans le volet d’informations, double-cliquez Windows Composants, puis double-cliquez sur Car te à
puce.
4. Cliquez avec le bouton droit sur Activer le ser vice Plug-and-Play de carte à puce, puis cliquez sur
Modifier.
5. Cliquez sur Désactivé, puis sur OK.
Modifier le système de l’utilisateur final et désactiver le plug-and-play de carte à puce pour des cartes
spécifiques
Il s’agit de l’option la moins recommandée. Vous devez utiliser cette option uniquement si les cartes sont des
cartes héritées et qu’il n’est pas prévu d’implémenter des minidrivers de carte à puce à l’avenir. Cette option
nécessite que le logiciel existant déjà installé sur le système avertisse Windows qu’un CSP personnalisé est
installé sur le système, même s’il n’en existe aucun sur le système de l’utilisateur final. Dès que Windows
détermine qu’un CSP personnalisé est déjà installé sur le système, Windows n’essaie pas de télécharger et
d’installer un pilote via plug-and-play de carte à puce. Aucun nœud d’appareil n’est créé pour le périphérique de
carte à puce visible dans le Gestionnaire de périphériques. Cette option entraîne les modifications suivantes
dans le Registre système :
Sous-clé : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\<Smart card name>
Entrées de Registre de sous-clé :

ATR=DWORD hexadécimal : atr délimité par des virgules de la carte à puce.
ATRMask= DWORD hexadécimal : masque délimité par des virgules à appliquer à la atr pour masquer les
octets non significatifs dans la atr.
Crypto Provider=String value: Some string relevant to your smart card.
Par exemple :
Sous-clé : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\Fabrikam ATM card
Entrées de Registre de sous-clé :

ATR=DWORD hexadécimal : 3b,dc,13,00,40,3a,49,54,47,5f,4d,53,43,53,50,5f,56,32
ATRMask= Hexadécimale DWORD: ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff
Crypto Provider=String value: Fabrikam ATM D factice Provider
Pour les systèmes x64 bits, des modifications identiques doivent être apportées sous la sous-clé suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais\SmartCards
Au lieu de modifier directement le Registre système, nous vous recommandons d’utiliser les API WinSCard pour
introduire ces modifications dans le système. Voici un exemple de code qui détecte l’insertion d’une carte à
puce, puis désactive le plug-and-play de carte à puce pour la carte en particulier en créant une entrée de
Registre qui associe la carte à un fournisseur non existant.
implicite. Cela inclut, sans y être limité, les garanties implicites de commercialisation et d'adaptation à un but en
particulier. Cet article considère que vous connaissez le langage de programmation présenté et les outils utilisés
pour créer et déboguer des procédures. Les ingénieurs du support Microsoft peuvent expliquer la fonctionnalité
d'une procédure en particulier. Toutefois, ils ne modifient pas ces exemples pour fournir des fonctionnalités
supplémentaires ou construire des procédures pour répondre à vos besoins spécifiques.
//==============================================================;
//
// Disable Smart card Plug and Play for specific cards
//
// Abstract:
// This is an example of how to create a new
// Smart Card Database entry when a smart card is inserted
// into the computer.
//
// This source code is only intended as a supplement to existing Microsoft
// documentation.
//
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY
// KIND, EITHER EXPRESSED OR IMPLIED. THIS INCLUDES BUT NOT LIMITED TO THE
// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
// PURPOSE.
//
// Copyright (C) Microsoft Corporation. All Rights Reserved.
//==============================================================;
// This code must be compiled with UNICODE support to work correctly

#ifndef UNICODE
#define UNICODE
#endif
#include <windows.h>
#include <winscard.h>
#include <stdio.h>
#include <strsafe.h>
#include <rpc.h>
// Change this prefix to specify what the beginning of the

// introduced card name in the registry will be. This is
// be prepended to a GUID value.
#define CARD_NAME_PREFIX L"MyCustomCard"
// This is the name that will be provided as the CSP for

// the card when introduced to the system. This is provided
// in order to disable Smart Card Plug and Play for this
// card.
#define CARD_CSP L"$DisableSCPnP$"
// This special reader name is used to be notified when

// a reader is added to or removed from the system through
// SCardGetStatusChange.
// SCardGetStatusChange.
#define PNP_READER_NAME L"\\\\?PnP?\\Notification"
// Maximum ATR length plus alignment bytes. This value is

// used in the SCARD_READERSTATE structure
#define MAX_ATR_LEN 36
LONG GenerateCardName(
__deref_out LPWSTR *ppwszCardName)
{
LONG lReturn = NO_ERROR;
HRESULT hr = S_OK;
DWORD cchFinalString = 0;
WCHAR wszCardNamePrefix[] = CARD_NAME_PREFIX;
LPWSTR pwszFinalString = NULL;
UUID uuidCardGuid = {0};
RPC_WSTR pwszCardGuid = NULL;
RPC_STATUS rpcStatus = RPC_S_OK;
// Parameter check
if (NULL == ppwszCardName)
{
wprintf(L"Invalid parameter in GenerateCardName.\n");
return ERROR_INVALID_PARAMETER;
}
// Generate GUID
rpcStatus = UuidCreate(&uuidCardGuid);
if (RPC_S_OK != rpcStatus)
{
wprintf(L"Failed to create new GUID with error 0x%x.\n");
lReturn = (DWORD)rpcStatus;
}
else
{
// Convert GUID to string
rpcStatus = UuidToString(&uuidCardGuid, &pwszCardGuid);
if (RPC_S_OK != rpcStatus)
{
wprintf(L"Failed to convert new GUID to string with error 0x%x.\n", rpcStatus);
lReturn = (DWORD)rpcStatus;
}
else
{
// Allocate memory for final string
// Template is <prefix>-<guid>
cchFinalString = (DWORD)(wcslen(wszCardNamePrefix) + 1 + wcslen((LPWSTR)pwszCardGuid) + 1);
pwszFinalString = (LPWSTR)HeapAlloc(GetProcessHeap(), 0, cchFinalString * sizeof(WCHAR));
if (NULL == pwszFinalString)
{
wprintf(L"Out of memory.\n");
lReturn = ERROR_OUTOFMEMORY;
}
else
{
// Create final string
hr = StringCchPrintf(
pwszFinalString,
cchFinalString,
L"%s-%s",
wszCardNamePrefix,
pwszCardGuid);
if (FAILED(hr))
{
wprintf(L"Failed to create card name with error 0x%x.\n", hr);
lReturn = (DWORD)hr;
}
else
{
// Set output params
// Set output params
*ppwszCardName = pwszFinalString;
pwszFinalString = NULL;
}
}
}
}
if (NULL != pwszCardGuid)
{
RpcStringFree(&pwszCardGuid);
}
if (NULL != pwszFinalString)
{
HeapFree(GetProcessHeap(), 0, pwszFinalString);
}
return lReturn;
}
LONG IntroduceCardATR(
__in SCARDCONTEXT hSC,
__in LPBYTE pbAtr,
__in DWORD cbAtr)
{
LPWSTR pwszCardName = NULL;
// Parameter checks
if (NULL == hSC || NULL == pbAtr || 0 == cbAtr)
{
wprintf(L"Invalid parameter in IntroduceCardATR.\n");
}
// Generate a name for the card

lReturn = GenerateCardName(&pwszCardName);
if (NO_ERROR != lReturn)
{
wprintf(L"Failed to generate card name with error 0x%x.\n", lReturn);
}
else
{
// Introduce the card to the system
lReturn = SCardIntroduceCardType(
hSC,
pwszCardName,
NULL,
NULL,
0,
pbAtr,
NULL,
cbAtr);
if (SCARD_S_SUCCESS != lReturn)
{
wprintf(L"Failed to introduce card '%s' to system with error 0x%x.\n", pwszCardName, lReturn);
}
else
{
// Set the provider name
lReturn = SCardSetCardTypeProviderName(
hSC,
pwszCardName,
SCARD_PROVIDER_CSP,
CARD_CSP);
{
wprintf(L"Failed to set CSP for card '%s' with error 0x%x.\n", pwszCardName, lReturn);
}
}
else
{
wprintf(L"Card '%s' has been successfully introduced to the system and has had Plug and
Play disabled.\n", pwszCardName);
}
}
}
if (NULL != pwszCardName)
{
HeapFree(GetProcessHeap(), 0, pwszCardName);
}
return lReturn;
}
LONG ProcessCard(
__in SCARDCONTEXT hSC,
__in LPSCARD_READERSTATE pRdr)
{
DWORD dwActiveProtocol = 0;
DWORD cbAtr = MAX_ATR_LEN;
DWORD dwIndex = 0;
DWORD cchCards = SCARD_AUTOALLOCATE;
LPWSTR pmszCards = NULL;
BYTE rgbAtr[MAX_ATR_LEN] = {0};
SCARDHANDLE hSCard = NULL;
// Parameter checks
if (NULL == hSC || NULL == pRdr)
{
wprintf(L"Invalid parameter in ProcessCard.\n");
}
// Connect to the card in the provided reader in shared mode

lReturn = SCardConnect(
hSC,
pRdr->szReader,
SCARD_SHARE_SHARED,
SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1,
&hSCard,
&dwActiveProtocol);
{
wprintf(L"Failed to connect to card in reader '%s' with error 0x%x.\n", pRdr->szReader, lReturn);
}
else
{
wprintf(L"Connected to card in reader '%s'.\n", pRdr->szReader);
/*
* In this spot, put any necessary calls needed to identify that this
* is the type of card you are looking for. Usually this is done via
* SCardTransmit calls. For this example, we will grab the ATR of every
* inserted card.
*/
// Obtain the ATR of the inserted card

lReturn = SCardGetAttrib(
hSCard,
SCARD_ATTR_ATR_STRING,
rgbAtr,
&cbAtr);
{
wprintf(L"Failed to obtain ATR of card in reader '%s' with error 0x%x.\n", pRdr->szReader,
lReturn);
lReturn);
}
else
{
// Output the ATR
wprintf(L"ATR of card in reader '%s':", pRdr->szReader);
for (dwIndex = 0; dwIndex < cbAtr; dwIndex++)
{
wprintf(L" %02x", rgbAtr[dwIndex]);
}
wprintf(L"\n");
// Determine if the ATR is already in the Smart Card Database

lReturn = SCardListCards(
hSC,
rgbAtr,
NULL,
0,
(LPWSTR)&pmszCards,
&cchCards);
{
wprintf(L"Failed to determine if card in reader '%s' is currently recognized by the system
with error 0x%x. Skipping.\n", pRdr->szReader, lReturn);
}
else if (NULL == pmszCards || 0 == *pmszCards)
{
// Card not found. We need to add it.
wprintf(L"Card in reader '%s' is not currently recognized by the system. Adding ATR.\n",
pRdr->szReader);
lReturn = IntroduceCardATR(
hSC,
rgbAtr,
cbAtr);
// If an error occurs here, we will continue so we can try the next time
// the card is inserted as well as examine other readers.
}
else
{
wprintf(L"Card in reader '%s' is already known by the system. Not adding ATR.\n", pRdr-
>szReader);
}
}
}
// Disconnect from the card. We do not need to reset it.

if (NULL != hSCard)
{
SCardDisconnect(hSCard, SCARD_LEAVE_CARD);
}
// Free resources
if (NULL != pmszCards)
{
SCardFreeMemory(hSC, pmszCards);
}
return lReturn;
}
LONG MonitorReaders(
__in SCARDCONTEXT hSC)
{
LPWSTR pwszReaders = NULL;
LPWSTR pwszOldReaders = NULL;
LPWSTR pwszRdr = NULL;
DWORD dwRet = ERROR_SUCCESS;
DWORD cchReaders = SCARD_AUTOALLOCATE;
DWORD dwRdrCount = 0;
DWORD dwOldRdrCount = 0;
DWORD dwIndex = 0;
BOOL fDone = FALSE;
SCARD_READERSTATE rgscState[MAXIMUM_SMARTCARD_READERS+1] = {0};
SCARD_READERSTATE rgscOldState[MAXIMUM_SMARTCARD_READERS+1] = {0};
LPSCARD_READERSTATE pRdr = NULL;
// Parameter check
if (NULL == hSC)
{
wprintf(L"Invalid parameter in MonitorReaders.\n");
}
// One of the entries for monitoring will be to detect new readers

// The first time through the loop will be to detect whether
// the system has any readers.
rgscState[0].szReader = PNP_READER_NAME;
rgscState[0].dwCurrentState = SCARD_STATE_UNAWARE;
dwRdrCount = 1;
while (!fDone)
{
while (!fDone)
{
// Wait for status changes to occur
wprintf(L"Monitoring for changes.\n");
lReturn = SCardGetStatusChange(
hSC,
INFINITE,
rgscState,
dwRdrCount);
switch (lReturn)
{
case SCARD_S_SUCCESS:
// Success
break;
case SCARD_E_CANCELLED:
// Monitoring is being cancelled
wprintf(L"Monitoring cancelled. Exiting.\n");
fDone = TRUE;
break;
default:
// Error occurred
wprintf(L"Error 0x%x occurred while monitoring reader states.\n", lReturn);
fDone = TRUE;
break;
}
if (!fDone)
{
// Examine the status change for each reader, skipping the PnP notification reader
for (dwIndex = 1; dwIndex < dwRdrCount; dwIndex++)
{
pRdr = &rgscState[dwIndex];
// Determine if a card is now present in the reader and

// it can be communicated with.
if ((pRdr->dwCurrentState & SCARD_STATE_EMPTY ||
SCARD_STATE_UNAWARE == pRdr->dwCurrentState) &&
pRdr->dwEventState & SCARD_STATE_PRESENT &&
!(pRdr->dwEventState & SCARD_STATE_MUTE))
{
// A card has been inserted and is available.
// Grab its ATR for addition to the database.
wprintf(L"A card has been inserted into reader '%s'. Grabbing its ATR.\n", pRdr-
>szReader);
>szReader);
lReturn = ProcessCard(hSC, pRdr);
// If an error occurs here, we will continue so we can try the next time
// the card is inserted as well as examine other readers.
}
// Save off the new state of the reader

pRdr->dwCurrentState = pRdr->dwEventState;
}
// Now see if the number of readers in the system has changed.

// Save its new state as the current state for the next loop.
pRdr = &rgscState[0];
pRdr->dwCurrentState = pRdr->dwEventState;
if (pRdr->dwEventState & SCARD_STATE_CHANGED)
{
wprintf(L"Reader change detected.\n");
break;
}
}
}
if (!fDone)
{
// Clean up previous loop
if (NULL != pwszOldReaders)
{
SCardFreeMemory(hSC, pwszOldReaders);
pwszOldReaders = NULL;
}
pwszReaders = NULL;
cchReaders = SCARD_AUTOALLOCATE;
// Save off PnP notification reader state and and list of readers previously found in the system
memcpy_s(&rgscOldState[0], sizeof(SCARD_READERSTATE), &rgscState[0], sizeof(SCARD_READERSTATE));
memset(rgscState, 0, sizeof(rgscState));
dwOldRdrCount = dwRdrCount;
pwszOldReaders = pwszReaders;
// Obtain a list of all readers in the system

wprintf(L"Building reader list.\n");
lReturn = SCardListReaders(
hSC,
NULL,
(LPWSTR)&pwszReaders,
&cchReaders);
switch (lReturn)
{
case SCARD_S_SUCCESS:
// Success
break;
case SCARD_E_NO_READERS_AVAILABLE:
// No readers in the system. This is OK.
lReturn = SCARD_S_SUCCESS;
break;
default:
// Error occurred
wprintf(L"Failed to obtain list of readers with error 0x%x.\n", lReturn);
fDone = TRUE;
break;
}
// Build the reader list for monitoring - NULL indicates end-of-list

// First entry is the PnP Notification entry.
pRdr = rgscState;
memcpy_s(&rgscState[0], sizeof(SCARD_READERSTATE), &rgscOldState[0], sizeof(SCARD_READERSTATE));
pRdr++;
pwszRdr = pwszReaders;
while ((NULL != pwszRdr) && (0 != *pwszRdr))
while ((NULL != pwszRdr) && (0 != *pwszRdr))
{
BOOL fFound = FALSE;
dwRdrCount++;
// Look for an existing reader state from a previous loop

for (dwIndex = 1; dwIndex < dwOldRdrCount; dwIndex++)
{
if ((lstrlen(pwszRdr) == lstrlen(rgscOldState[dwIndex].szReader)) &&
(0 == lstrcmpi(pwszRdr, rgscOldState[dwIndex].szReader)))
{
// Found a match. Copy it.
memcpy_s(pRdr, sizeof(SCARD_READERSTATE), &rgscOldState[dwIndex],
sizeof(SCARD_READERSTATE));
fFound = TRUE;
break;
}
}
if (!fFound)
{
// New reader
pRdr->szReader = pwszRdr;
pRdr->dwCurrentState = SCARD_STATE_UNAWARE;
}
// Increment reader indices

pRdr++;
pwszRdr += lstrlen(pwszRdr)+1;
}
}
}
// Clean up resources
if (NULL != pwszReaders)
{
SCardFreeMemory(hSC, pwszReaders);
}
if (NULL != pwszOldReaders)
{
SCardFreeMemory(hSC, pwszOldReaders);
}
return lReturn;
}
LONG __cdecl main(

VOID)
{
DWORD dwRet = ERROR_SUCCESS;
SCARDCONTEXT hSC = NULL;
HANDLE hStartedEvent = NULL;
// Get handle to event that will be signaled when the Smart Card Service is available
hStartedEvent = SCardAccessStartedEvent();
// Wait for the Smart Card Service to become available

dwRet = WaitForSingleObject(hStartedEvent, INFINITE);
if (WAIT_OBJECT_0 != dwRet)
{
wprintf(L"Wait for Smart Card Service failed with error 0x%x.\n", dwRet);
lReturn = dwRet;
}
else
{
// Establish a system-level context with the Smart Card Service
lReturn = SCardEstablishContext(
SCARD_SCOPE_SYSTEM,
SCARD_SCOPE_SYSTEM,
NULL,
NULL,
&hSC);
{
wprintf(L"Failed to establish context with the Smart Card Service with error 0x%x.\n", lReturn);
}
else
{
// Begin monitoring the readers in the system
// This routine could be done in a separate thread so it can be cancelled via SCardCancel().
lReturn = MonitorReaders(hSC);
}
}
// Cleanup resources
if (NULL != hSC)
{
SCardReleaseContext(hSC);
}
if (NULL != hStartedEvent)
{
SCardReleaseStartedEvent();
}
wprintf(L"Done.\n");
return lReturn;
}
Références
Pour plus d’informations sur la résolution des problèmes de plug-and-play de carte à puce, voir le Guide de
résolution des problèmes de carte à puce.
Comment déterminer le type de processeur utilisé
par votre ordinateur
Cet article explique comment déterminer le type de processeur utilisé sur un ordinateur.
Introduction
Cet article explique comment déterminer le type de processeur d’un ordinateur exécutant l’un des systèmes
Microsoft Windows Server 2003, Enterprise x64 Edition
Microsoft Windows Server 2003, Standard x64 Edition
Microsoft Windows Server 2003, Datacenter x64 Edition
Microsoft Windows XP Professional x64 Edition
Les informations sur le type de processeur sont stockées dans l’entrée PROCESSOR_IDENTIFIER registre dans la
sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment
L PROCESSOR_IDENTIFIER de Registre utilise une valeur de chaîne qui est décrite comme suit :
Si la valeur de chaîne contient « AMD64 » (sans guillemets), l’ordinateur dispose d’un processeur AMD64
advanced Micro Devices (AMD).
Si la valeur de chaîne contient « EM64T » (sans guillemets), l’ordinateur dispose d’un processeur INTEL
Extended Memory 64 Technology (EM64T).
NOTE
La valeur de l’entrée PROCESSOR_ARCHITECTURE registre dans la sous-clé de Registre suivante est définie sur AMD64,
quel que soit le type de processeur utilisé par l’ordinateur :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
Pour déterminer le type de processeur, utilisez l’une des méthodes suivantes.
Méthode 1 : utiliser la commande set

Pour utiliser la commande set afin de déterminer le type de processeur, suivez les étapes suivantes :
1. Cliquez sur Démarrer, sur Exécuter, tapez cmd dans la zone Ouvrir, puis appuyez sur Entrée.
2. À l’invite de commandes, tapez set, puis appuyez sur Entrée.
3. Notez la chaîne qui s’affiche en PROCESSOR_IDENTIFIER.
Pour utiliser l’Éditeur du Registre afin de déterminer le type de processeur, suivez les étapes suivantes :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment
3. Dans le volet droit, notez la chaîne qui est affichée dans la colonne Données pour l’entrée
PROCESSOR_IDENTIFIER registre.
Support technique pour les versions x64 de Microsoft Windows
Votre fabricant de matériel fournit un support technique et une assistance pour les versions x64 de Windows.
Votre fabricant de matériel assure la prise en charge car une version x64 de Windows a été incluse dans votre
matériel. Votre fabricant de matériel a peut-être personnalisé l’installation de Windows avec des composants
uniques. Les composants uniques peuvent inclure des pilotes de périphérique spécifiques ou inclure des
paramètres facultatifs pour optimiser les performances du matériel. Microsoft vous fournira une assistance
raisonnable si vous avez besoin d’aide technique avec votre version x64 de votre Windows. Toutefois, il se peut
que vous deiez contacter directement votre fabricant. Votre fabricant est le mieux qualifié pour prendre en
charge les logiciels que votre fabricant a installés sur le matériel.
Comment remplacer un pilote à l’aide de la console
de récupération
Cet article pas à pas décrit comment utiliser la console de récupération pour remplacer un pilote sur un
ordinateur Windows Server 2003 que vous ne pouvez pas démarrer.
Pour remplacer un pilote, vous devez avoir une copie fonctionnelle des fichiers de pilotes et connaître
l’emplacement du dossier qui contient le fichier de pilote.
NOTE
Seul le compte Administrateur peut accéder à la console de récupération.
revenir en haut
Démarrer la console de récupération

Pour démarrer la console de récupération, utilisez l’une des méthodes suivantes.
La console de récupération est installée
1. Démarrez votre ordinateur.
2. Lorsque vous êtes invité à sélectionner un système d’exploitation, sélectionnez Microsoft Windows
Ser ver 2003 Recover y Console .
NOTE
Si la console de récupération n’apparaît pas dans la liste, la console de récupération n’est pas installée. Suivez les
étapes de la section suivante pour démarrer la console de récupération.
3. Sélectionnez l Windows l’installation que vous souhaitez réparer, puis appuyez sur Entrée.
4. Tapez le mot de passe administrateur, puis appuyez sur Entrée.
NOTE
La console de récupération utilise le mot de passe Administrateur que vous avez configuré lors de l’installation
Windows Server 2003. Les modifications apportées au mot de passe administrateur après l’installation Windows
Server 2003 ne s’appliquent pas à recovery Console.
La console de récupération n’est pas installée

1. Démarrez votre ordinateur à l’aide Windows CD-ROM.
2. Dans l’écran d’accueil du programme d’installation, appuyez sur R pour réparer l’installation, puis
appuyez sur C pour démarrer la console de récupération.
3. Sélectionnez l Windows l’installation que vous souhaitez réparer, puis appuyez sur Entrée.
4. Tapez le mot de passe administrateur, puis appuyez sur Entrée.
NOTE
La console de récupération utilise le mot de passe Administrateur que vous avez configuré lors de l’installation
Windows Server 2003. Les modifications apportées au mot de passe administrateur après l’installation Windows
Server 2003 ne s’appliquent pas à recovery Console.
revenir en haut
Extraire les fichiers de pilotes du CD-ROM d’installation Windows

Server 2003
Les fichiers d’installation sont stockés sur le CD-ROM d’installation Windows Server 2003 dans des dossiers
compressés appelés fichiers cabinet (.cab). Les fichiers de pilotes sont stockés dans Driver.cab fichier. Pour
utiliser les fichiers de pilotes d’origine inclus dans le CD-ROM d’installation Windows Server 2003 afin de
remplacer les fichiers de pilotes endommagés :
1. Insérez Windows CD-ROM d’installation de Server 2003 dans le lecteur de CD-ROM.
2. À l’invite de commandes dans la console de récupération, tapez expand d: \i386\driver.cab /f: filename [
chemin ], puis appuyez sur Entrée, où :
d: est la lettre de lecteur de CD-ROM
filename est le nom du fichier que vous souhaitez développer
chemin d’accès est le dossier dans lequel copier le fichier de pilote
En règle générale, les fichiers de pilote (.sys) sont stockés dans le %SystemRoot%\System32\Drivers dossier.
Par exemple, pour remplacer le fichier Atimpab.sys de pilote, vous pouvez utiliser la commande
d:\i386\driver.cab /f:atimpab.sys %systemroot%\System32\Drivers\ développer.
NOTE
Dans cette commande, vous devez utiliser le commutateur /f, car le fichier CAB Driver.cab contient plusieurs
fichiers.
revenir en haut
Remplacer les fichiers de pilotes à l’aide de la commande COPY

Si les fichiers de pilotes que vous souhaitez ne se trouvent pas dans un fichier cabinet (.cab), vous pouvez utiliser
la commande de copie de la console de récupération pour réécrire les fichiers endommagés :
1. À l’invite de commandes, tapez copier [ source_path ] source_filename [ destination_path ]
destination_filename , puis appuyez sur Entrée, où :
source_path est le chemin d’accès du fichier de remplacement de source
source_filename est le nom du fichier de remplacement
destination_path est le chemin d’accès du fichier de pilote à remplacer
destination_filename est le nom du fichier de pilote à remplacer
Par exemple, pour remplacer le fichier Atimpab.sys par une copie bonne connue à partir d’une disquette,
vous pouvez utiliser la commande a:\atimpab.sys c:\winnt\system32\drivers\atimpab.sys copier.
NOTE
La commande copier dans la console de récupération ne prend pas en charge les caractères génériques. Pour cette
raison, vous ne pouvez copier qu’un seul fichier à la fois. Si vous devez remplacer plusieurs fichiers, utilisez
plusieurs commandes de copie.
2. Lorsque vous êtes invité à confirmer que vous souhaitez réécrire le fichier existant, appuyez sur Y, puis
revenir en haut
Ajouter la console de récupération à une installation existante

Vous pouvez ajouter la console de récupération à une installation existante de Windows Server 2003 à l’aide de
la commande winnt32.exe /cmdcons. La console de récupération nécessite environ 7 mégaoctets (Mo) d’espace
disque disponible dans la partition système sur le disque dur.
revenir en haut
Comment utiliser le Gestionnaire de périphériques
pour configurer des appareils dans Windows Server
2003
Cet article explique comment utiliser le Gestionnaire de périphériques pour configurer les périphériques
matériels installés sur votre ordinateur Windows Server 2003.
Résumé
Le Gestionnaire de périphériques affiche une vue graphique du matériel installé sur votre ordinateur. Utilisez cet
outil lorsque vous souhaitez afficher et gérer les périphériques matériels et leurs pilotes. Vous devez être
connecté à l’ordinateur en tant qu’administrateur ou en tant que membre du groupe Administrateurs pour
ajouter ou supprimer des appareils ou pour configurer les propriétés de l’appareil dans le Gestionnaire de
périphériques.
Lorsque vous installez un appareil Plug-and-Play, Windows configure automatiquement l’appareil afin qu’il
fonctionne correctement avec les autres périphériques installés sur l’ordinateur. Pendant le processus de
configuration, Windows affecte un ensemble unique de paramètres de ressources système à l’appareil. La liste
suivante décrit les quatre types de ressources qu’un appareil peut utiliser :
Numéros de ligne de demande d’interruption (IRQ)
Canaux d’accès direct à la mémoire (DMA)
Adresses de port d’entrée/sortie (E/S)
Plages d’adresses de mémoire
Chaque ressource affectée à un appareil se voit attribuer une valeur unique. Parfois, un conflit d’appareil peut se
produire si deux appareils nécessitent les mêmes ressources. Si ce conflit se produit, vous pouvez configurer
manuellement l’appareil pour affecter des ressources uniques à chaque appareil. Dans certains cas, en fonction
des pilotes de périphérique et de l’ordinateur, deux appareils peuvent partager une ressource (par exemple, des
interruptions sur les périphériques de connexion de composants périphériques [PCI].
Lorsque vous installez un appareil non plug-and-play, Windows ne configure pas automatiquement les
paramètres de ressources de l’appareil. Selon le type d’appareil, vous de devez configurer manuellement ces
paramètres. Avant de le faire, contactez le fabricant du matériel ou consultez la documentation incluse avec
l’appareil pour plus d’informations.
En règle générale, Windows les appareils et leurs demandes de ressources, puis fournit automatiquement les
paramètres de ressource pour votre matériel. Dans la plupart des cas, vous n’avez pas besoin de modifier les
paramètres de ressources de votre matériel. Ne modifiez pas les paramètres de ressource d’un appareil Plug-
and-Play, sauf si cela est nécessaire. Lorsque vous configurez manuellement une ressource, le paramètre est
résolu. Par Windows ne peut pas modifier les affectations de ressources si cela est nécessaire, et Windows
pouvez pas affecter cette ressource à un autre appareil.
Comment configurer un appareil dans le Gestionnaire de

périphériques
Pour configurer un appareil dans le Gestionnaire de périphériques, suivez ces étapes.
IMPORTANT
Faites attention lorsque vous configurez les paramètres de ressource d’un appareil. Si vous configurez les ressources de
manière incorrecte, vous pouvez désactiver votre matériel et empêcher votre ordinateur de fonctionner. Modifiez les
paramètres des ressources uniquement lorsque vous êtes sûr que les paramètres que vous souhaitez utiliser sont uniques
et n’entrent pas en conflit avec les paramètres d’autres appareils, ou lorsqu’un fabricant de matériel vous a fourni des
paramètres de ressources spécifiques pour un appareil.
1. Connectez-vous à votre ordinateur en tant qu’administrateur ou en tant que membre du groupe

Administrateurs.
2. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez Gestion de
l’ordinateur.
3. Sous Outils système dans l’arborescence de la console, sélectionnez Gestionnaire de périphériques.
Les appareils installés sur votre ordinateur sont répertoriés dans le volet droit.
4. Double-cliquez sur le type d’appareil que vous souhaitez configurer( par exemple, Por ts (COM & LPT).
5. Cliquez avec le bouton droit sur l’appareil que vous souhaitez configurer, puis sélectionnez Propriétés.
6. Sélectionnez l’onglet Ressources.
7. Cliquez pour effacer la case Utiliser les paramètres automatiques.
NOTE
La case à cocher Utiliser les paramètres automatiques n’est pas disponible et apparaît estommée, à la fois sur
les appareils pour lesquels il n’existe aucun autre paramètre à configurer et sur les appareils contrôlés par les
ressources Plug-and-Play et qui ne nécessitent pas de modification de l’utilisateur.
8. Dans la Paramètres sur la base de la zone, sélectionnez la configuration matérielle que vous souhaitez
modifier , par exemple, Configuration de base 0000 .
9. Sous Type de ressource dans la zone Paramètres de la ressource, sélectionnez le type de ressource
que vous souhaitez modifier ( par exemple, Interrompre la demande ).
10. Sélectionnez Modifier le paramètre .
11. Dans la boîte de dialogue Modifier la ressource, tapez la valeur de votre choix pour la ressource, puis
sélectionnez OK.
12. Répétez les étapes 8 à 11 pour configurer les paramètres de ressource que vous souhaitez pour l’appareil.
13. Quittez le Gestionnaire de périphériques.
Comment afficher les paramètres de ressource dans le Gestionnaire

de périphériques
Pour afficher la liste des ressources et des appareils qui les utilisent par type ou par connexion, suivez les étapes
suivantes :
l’ordinateur.
Les appareils installés sur votre ordinateur sont répertoriés dans le volet droit. L’affichage par défaut
répertorie les appareils par type.
3. Utilisez l’une des méthodes suivantes :
Pour afficher une liste de ressources par type, sélectionnez Ressources par type dans le menu
Affichage.
Pour afficher une liste de ressources par type de connexion, sélectionnez Ressources par
connexion dans le menu Affichage.
Utiliser le Gestionnaire de périphériques pour rechercher les conflits

d’appareils
Un conflit d’appareil se produit lorsque les mêmes ressources sont données à deux appareils ou plus. Utilisez le
Gestionnaire de périphériques pour rechercher les conflits d’appareils. Pour ce faire, procédez comme suit :
l’ordinateur.
3. Double-cliquez sur le type d’appareil que vous souhaitez tester , par exemple, les contrôleurs de son,
vidéo et de jeu.
4. Cliquez avec le bouton droit sur l’appareil que vous souhaitez tester pour les conflits, puis sélectionnez
Propriétés.
5. Sélectionnez l’onglet Ressources.
Les conflits existant pour l’appareil sont répertoriés sous Liste des appareils en conflit.
Windows Dépannage du matériel

Utilisez l’Windows dépannage du matériel pour résoudre un conflit matériel ou d’autres problèmes matériels.
Pour démarrer l’outil de dépannage du matériel, suivez les étapes suivantes :
1. Connectez-vous à votre ordinateur en tant qu’administrateur ou en tant que membre du groupe
Administrateurs.
l’ordinateur.
4. Double-cliquez sur le type d’appareil que vous souhaitez dépanner( par exemple, modems .
5. Cliquez avec le bouton droit sur l’appareil à résoudre, puis sélectionnez Propriétés.
6. Cliquez sur l’onglet Général .
7. Sélectionnez Résoudre les problèmes.
Références
Pour plus d’informations sur la gestion des appareils à l’aide du Gestionnaire de périphériques, voir Codes
d’erreur dans le Gestionnaire de périphériques dans Windows
Stratégie de prise en charge pour les logiciels tiers
au niveau du noyau signés à l’aide du processus
d’attestation Windows
Cet article décrit la prise en charge prise en charge par le Support Microsoft pour les produits logiciels
Microsoft, tels que le système d’exploitation Windows Server (toutes les versions), lorsque vous exécutez ce
produit Microsoft avec des pilotes au niveau du noyau signés par attestation et tout adaptateur physique,
contrôleur ou autre appareil ou application associé.
NOTE
Le processus de signature d’attestation pour un pilote tiers au niveau du noyau ne nécessite pas que le fournisseur de
pilotes fournisse des résultats de test pour obtenir une signature de pilote auprès de Microsoft. Pour plus d’informations,
voir Attestation de signature d’un pilote de noyau pour la publication publique.
Vérifier si les pilotes sont entièrement testés et pris en charge

À l’exception de ce qui est décrit dans cet article, le Support Microsoft ne prend pas en charge les logiciels qui
ont des pilotes au niveau du noyau qui sont signés par attestation. En outre, Microsoft ne prend en charge aucun
appareil physique, pilote de filtre ou application associé à ce logiciel.
Microsoft prend en charge les pilotes pour les appareils physiques, les filtres et les applications testés à l’aide du
kit de test approprié pour la version du système d’exploitation Windows Server pour laquelle le pilote a été
soumis, puis signé ou certifié par Microsoft.
Si un problème signalé par un client est dû à un pilote de noyau signé par attestation, les ingénieurs du Support
Microsoft peuvent tenter de déterminer l’origine du pilote en demandant si des pilotes ont été récemment mis à
jour.
Cela peut être déterminé en vérifiant le fichier Setupapi.dev.log situé à l’emplacement %SystemRoot% \ inf.
Si des pilotes ont été récemment installés, ils peuvent être examinés pour savoir s’ils ont été testés et soumis
pour signature ou signés à l’aide du processus d’attestation.
L’ingénieur du support Microsoft peut également vérifier le catalogue de serveurs Windows ou la liste des
produits compatibles Windows pour déterminer si l’appareil et le pilote ont été testés, soumis et certifiés ou
signés récemment. Pour ce faire, recherchez la valeur du nom du fournisseur dans la liste des produits
compatibles Windows et entrez un astérisque dans le champ Nom du produit. Par exemple, voir la capture
d’écran suivante.
La colonne Cer tifications indique les versions, éditions et plateformes de processeur du système
d’exploitation Windows ou Windows Server pour lesquelles le produit a été testé et soumis.
NOTE
Les mêmes informations sont disponibles dans le rapport de vérification.
Vous pouvez également utiliser Windows Catalogue de serveurs pour vérifier si un produit utilise un pilote qui a
été récemment testé, soumis et signé. Pour ce faire, utilisez la fonctionnalité de recherche dans Windows
Catalogue de serveurs pour le nom du produit, le nom du pilote ou le nom du fournisseur.
NOTE
Un pilote peut être répertorié en tant que Signature uniquement. Il indique que le périphérique ou le pilote n’a pas de
correspondance avec le type de produit défini. Toutefois, les exigences qui s’appliquent à ce produit ont été validées par les
tests du kit approprié et le pilote a été soumis.
Un pilote a peut-être été signé à l’aide du processus d’attestation dans le cadre du scénario suivant :
Le pilote a peut-être déjà été testé et les résultats ont été soumis pour certification ou signature. Le
support peut vérifier les sources de la section précédente pour vérifier ces informations.
Le fournisseur a peut-être dû fournir un correctif logiciel immédiatement au pilote pour atténuer ou
résoudre un problème sérieux pour ce client.
Le fournisseur n’a peut-être pas pu prendre le temps d’exécuter la liste de test complète qui est
obligatoire pour ce type de produit. Cela est dû au fait qu’un tel test peut prendre des jours, voire des
semaines. Par conséquent, le fournisseur a utilisé le processus d’attestation pour offrir un certain relief à
ce client.
NOTE
Dans ce cas, il est peu probable qu’une régression soit survenue à partir d’un seul correctif qui a provoqué un
problème supplémentaire en matière de sécurité, de fiabilité ou de compatibilité.
Dans ce scénario, le pilote doit être considéré comme étant entièrement testé et pris en charge.
Stratégie de support
Un fournisseur peut avoir une relation de support établie avec Microsoft pour l’une des raisons suivantes :
Le fournisseur est membre de TSANet et utilise le processus et le chemin d’accès TSANet.
Le fournisseur dispose d’un contrat de support de niveau Premier.
Pour les clients Microsoft qui disposent d’une prise en charge de niveau Premier et qui disposent de systèmes
Windows Server qui exécutent des pilotes de niveau noyau signés par attestation d’un fournisseur avec lequel
Microsoft a établi une relation de support, Microsoft se coordonnera avec le fournisseur pour examiner
conjointement les problèmes de support.
Dans le cadre de l’examen, Microsoft déterminera s’il existe des résultats du Kit de test pour le kit associé à cette
version du système d’exploitation Windows Server qui ont été soumis dans le passé récent pour le pilote au
niveau du noyau qui est déterminé comme étant actuellement signé par attestation. Dans ce contexte, le « passé
récent » est une période d’au plus deux ou trois mois. Cette valeur est basée sur le temps moyen entre les
soumissions testées pour les produits qui utilisent des pilotes.
Pour les clients Microsoft qui ont une prise en charge de niveau Premier et qui ont des systèmes Windows
Server qui exécutent des pilotes de niveau noyau signés par attestation d’un fournisseur avec lequel Microsoft
n’a pas de relation de support établie, Microsoft étudiera les problèmes potentiels qui affectent les logiciels
Microsoft comme suit :
Si le pilote est certifié ou a été signé dans le passé récent en raison d’une soumission testée précédente,
Microsoft prendra en charge les produits Microsoft comme si le produit fournisseur et le pilote au niveau du
noyau et l’application ou le produit physique associé sont toujours certifiés en fonction des résultats
complets des tests.
Si le pilote n’a pas été certifié ou signé dans le passé récent en raison d’un envoi testé précédent, le client de
niveau Premier est dirigé vers le fournisseur qui a fourni le pilote de niveau noyau signé par attestation pour
toute assistance supplémentaire.
Quelle que soit la relation de support entre Microsoft et le fournisseur qui fournit le pilote signé par attestation,
le fournisseur qui fournit le pilote de noyau est finalement responsable de la prise en charge du produit et du
pilote.
Comment déterminer si un pilote est signé par attestation

1. Dans le répertoire des pilotes %SystemRoot% \ system32, \ cliquez avec le bouton droit sur le nom du
fichier de pilote en question. Sélectionnez Propriétés dans la liste liste liste.
2. Sélectionnez l’onglet Signatures numériques.
3. Sélectionnez l’entrée Microsoft dans la liste signature, puis sélectionnez le bouton Détails.
4. Dans la fenêtre Détails de la signature numérique, sélectionnez l’onglet Avancé.
5. Sélectionnez le bouton Afficher le certificat.

6. Dans la fenêtre Certificat, sélectionnez l’onglet Détails.
7. Dans la zone de liste qui en résulte, faites défiler vers le bas jusqu’à la ligne Utilisation améliorée de la
clé.
Si le texte de cette ligne inclut Windows vérification attestée du pilote matériel, le pilote a été signé par
attestation.
produits.
Échec de l’installation du pilote VMware Windows
Server 2008 R2 SP1
Cet article vous aide à résoudre un problème dans lequel vous ne pouvez pas installer de pilotes sur des
machines virtuelles hébergées sur VMware. Ce problème se produit si vous ne cochez pas la case « Autoriser le
service à interagir avec le bureau ».
Symptômes
Les machines virtuelles dans VMware n’installent pas ou ne mettez pas à jour un pilote avec succès si les
Vous installez le service Telnet Server sur un ordinateur exécutant Windows Server 2008 R2 Service Pack 1
(SP1) et sur qui VMware vSphere est installé.
Vous configurez le service Telnet Server pour qu’il démarre manuellement ou automatiquement dans la
console MMC (Services Microsoft Management Console). En outre, vous modifiez le service Telnet Server
pour vous connecter à l’aide du compte système local et vous ne cochez pas la case « Autoriser le service à
interagir avec le bureau ».
Lorsque vous essayez d’installer le pilote dans le Gestionnaire de périphériques sur des machines virtuelles, il
échoue et vous recevez le message d’erreur suivant :
Windows avez trouvé le logiciel de pilote pour votre appareil, mais a rencontré une erreur lors de la
tentative de l’installer.
En outre, un journal semblable à ce qui suit est consigné dans le fichier setupapi.dev.log situé dans le dossier
%windir%/inf :

ump : création du processus d’installation : DrvInst.exe <DateTime>
ump : Le processus d’installation du serveur s’est quitté avec le code 0xc0000142 <DateTime>
ump : {Plug-and-Play Service: Device Install exit(c0000142)}
ndv : Échec de l’installation de l’appareil pour le nouvel appareil... installation du pilote NULL.
Cause
Ce problème se produit pour des raisons de sécurité. Le service Telnet Server modifie les autorisations de la
station de fenêtre dans laquelle il est en cours d’exécution lors de l’initialisation. Si vous configurez le service
Telnet Server pour qu’il s’exécute à l’aide du compte système local sans pouvoir interagir avec le Bureau, il est
démarré sous une autre station de fenêtre. Cela peut entraîner des problèmes pour d’autres processus qui
s’exécutent également sous le compte système local et n’interagissent pas avec le Bureau. L’un de ces processus
est le processus d’installation du pilote utilisé lors de l’installation d’un nouveau pilote de périphérique.
Pour contourner ce problème, ne modifiez pas le service Telnet Server pour qu’il s’exécute sous le compte
système local. Nous vous recommandons de laisser le service Telnet Server s’exécutant sous son compte de
service local par défaut.
S’il ne résout toujours pas le problème, vous pouvez vérifier que la dernière version des outils VMWare est
installée. Si vous remarquez que vous ne pouvez pas mettre à jour les outils VMWare ou les désinstaller, suivez
1. Obtenez les fichiers d’installation de la dernière version des outils VMWare.
2. Cliquez sur Démarrer , puis sur Exécuter , tapez cmd, puis cliquez sur OK . Une fenêtre d’invite de
commandes s’ouvre.
3. Changez le lecteur en lecteur de CD-ROM où se trouve les fichiers d’installation des outils VMware (par
exemple, D : \ ).
4. Tapez setup /c et appuyez sur Entrée pour forcer la suppression de toutes les entrées de Registre et
supprimer l’ancienne version des outils VMware.
NOTE
Pour les systèmes d’exploitation invités 64 bits, tapez setup64 /c .
5. Toutes les versions antérieures des outils VMware doivent être supprimées.
6. Installez la dernière version des outils VMware, puis effectuez un redémarrage après avoir vérifié que le
paramètre de la configuration de l’accès au service Telnet Server est correctement définie.
produits.
Windows services de déploiement (WDS) pour UEFI
Cet article décrit la prise en charge du déploiement sur des systèmes UEFI à partir de Windows Deployment
Services (WDS).
VERSIO N M IN IM A L E DE VERSIO N W IN P E
SC ÉN A RIO W DS SERVER M IN IM A L E( B O OT. W IM ) N OT ES
X64 Windows Server 2008 Windows PE 2.0(Windows UEFI X64 introduit dans
Server 2008) Windows Server 2008.
Avant 2012, WDS avait pris
en charge UEFI 2.1 pour
X64 et IA64 uniquement
x64 UEFI 2.3.1 Windows Server 2008 R2 Windows PE 4.0(Windows Prise en charge 2.3.1
Server 2012) ajoutée dans Windows
Server 2012
UEFI x86 Windows Server 2012 Windows PE 4.0(Windows Prise en charge de l’UEFI
Server 2012) x86 ajoutée dans Windows
Server 2012
UEFI PXE IPv6 Windows Server 2012 Windows PE 4.0(Windows Prise en charge d’IPv6
Server 2012) ajoutée dans Windows
Server 2012
Pour plus d’informations sur les versions Windows Deployment Services et les systèmes d’exploitation qu’ils
supportent pour le déploiement, consultez l’article suivant :
Nouveautés des services de déploiement Windows dans Windows Server 2012
Échec du déploiement multidiffusion Windows
services de déploiement
Cet article fournit une solution à un problème dans lequel le déploiement d’une image à partir d’un serveur
Windows Deployment Services (WDS) à l’aide de la multidiffusion échoue.
Symptômes
Lors du déploiement d’une image à partir d’un serveur WDS à l’aide de la multidiffusion, vous pouvez
rencontrer un ou plusieurs des problèmes suivants:
La session multidiffusion ne se termine jamais
La session multidiffusion produit un message d’erreur
La session multidiffusion est lente. Si vous modifiez le déploiement en unicast, cela fonctionne.
Cause
Il existe de nombreuses causes possibles à l’échec d’un déploiement multidiffusion. L’une des raisons possibles
est que les routeurs/commutateurs réseau ne gèrent pas correctement la fragmentation IP.
Résolution
Pour modifier WDS afin qu’il n’envoie pas de paquets fragmentés, faites les choses suivantes :
Windows Ser ver 2008 R2
Définissez la clé de Registre suivante et redémarrez la
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Protocol Name
WDSService : Type de valeur ApBlockSize : REG_DWORD données de la valeur : 1385 décimal
Windows Server 2008 utilise des profils réseau pour contrôler les paramètres. Pour le configurer afin de ne pas
envoyer de paquets fragmentés, faites ce qui suit:
1. Cliquez sur Démarrer, Exécuter, WdsMgmt.msc
2. Cliquez avec le bouton droit sur le serveur WDS et choisissez les propriétés
3. Choisir l’onglet Paramètres réseau
4. Modifier le profil réseau en profil personnalisé
Définissez la clé de Registre suivante et redémarrez la
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Profiles\Custom
Name WDSService : Type de valeur ApBlockSize : REG_DWORD données de la valeur : 1385 décimal
Si cela vous permet de terminer la transmission multidiffusion, modifiez la clé de Registre TpCacheSize ci-
dessous pour augmenter les performances. Si vous diminuez ApBlockSize sans augmenter TpCacheSize, les
performances globales diminueront. En bref, ApBlockSize * TpCacheSize = bande passante maximale qui peut
être atteinte.
Windows Ser ver 2008 R2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Protocol Name :
type de valeur TpCacheSize : REG_DWORD valeur : 3145 décimal
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Profiles\Custom
Name : type de valeur TpCacheSize : REG_DWORD valeur : 3145 décimal
Redémarrez le service WDSServer après avoir paramètre cette clé de Registre. Une fois cette configuration
terminée, exécutez un déploiement à vérifier et prenez note du temps de téléchargement de l’image. Augmentez
ensuite cette valeur par incréments jusqu’à ce qu’elle échoue ou atteigne 7550.
Si vous devez désactiver la fragmentation IP pour que la multidiffusion fonctionne, cela peut être indicatif du
matériel de commutation/routage bas de gamme qui ne prend peut-être pas en charge la fragmentation
efficacement ou ne prend pas en charge la multidiffusion efficacement (igmp/snooping MLD, etc.). La
multidiffusion peut être exigeante sur un réseau afin qu’elle puisse exposer des problèmes ou des problèmes
dans l’infrastructure réseau qui étaient inconnus jusqu’à la mise en place de la multidiffusion.
Les autres raisons possibles des échecs de multidiffusion sont les suivantes :
Assurez-vous que la taille du matériel du serveur WDS est correcte. En particulier la quantité de RAM et de
cartes réseau. Pour plus d’informations sur la configuration matérielle recommandée, voir Optimisation des
performances et de l’évolutivité
Si le serveur WDS est Windows Server 2008 R2, vérifiez l’onglet multidiffusion et vérifiez les paramètres de
transfert.
Si des images plus grandes échouent mais que des images plus petites fonctionnent, cela peut être dû à des
délai d’accès. Par exemple, sur les commutateurs Cisco, la valeur par défaut de l’intervalle de requête igmp ip
est de 60 secondes, ce qui signifie que le commutateur arrêtera le transfert du trafic multidiffusion vers le
port après 3 * 60 = 180 secondes s’il ne voit pas de trafic IGMP. Contactez votre fournisseur de commutateur
pour savoir comment configurer ces délai d’accès.
La plage de multidiffusion par défaut dans WDS est de 239.0.0.1 à 239.0.0.254. Selon le réseau, cela peut ne
pas fonctionner. Modifiez la plage de 239.192.0.2 à 239.192.0.250 ou vérifiez auprès de votre administrateur
réseau une plage inutilisée
Testez avec différents ordinateurs. Un ordinateur participant au flux de multidiffusion avec une mauvaise NIC
peut entraîner des problèmes lors de l’exécution de la multidiffusion
Pour plus d’informations sur l’optimisation et la résolution des problèmes, voir Optimisation des performances
et de l’évolutivité
Guide de résolution des problèmes liés à
l’installation des fonctionnalités et des rôles
Windows
Ces conseils sont conçus pour aider à résoudre les problèmes lors de l’ajout ou de la suppression de rôles et de
fonctionnalités dans Windows.

1. Vérifiez les erreurs dans le journal des événements Windows, en particulier le journal des événements
système et le journal des événements Windows Setup. Par exemple, accédez à l’emplacement suivant
dans observateur d'événements et recherchez des ID d’événement compris entre 4 000 et 4 099.
Journaux des applications et des services\Microsoft\Windows\ServerManager-MultiMachine
2. Essayez d’ajouter ou de supprimer un autre rôle ou fonctionnalité. Cette méthode permet de déterminer
si le problème est spécifique à un rôle ou une fonctionnalité.
3. Vérifiez l’état du magasin de composants pour toute altération.
a. Exécutez la commande suivante pour réparer l’image Windows. Pour plus d’informations,
consultez Réparer une image Windows.
Dism /Online /Cleanup-Image /RestoreHealth
b. Les résultats sont consignés dans le fichier journal suivant :

%windir%/Logs/CBS/CBS.log
c. Dans le fichier journal, recherchez la ligne suivante :
Checking System Update Readiness
4. Après avoir vérifié le magasin de composants et corrigé toute altération, exécutez la SFC /scannow
commande à une invite de commandes avec élévation de privilèges pour analyser et restaurer Windows
fichiers. Pour plus d’informations, consultez l’outil Vérificateur de fichiers système pour réparer les
fichiers système manquants ou endommagés.
Scénarios de support courants

Consultez la liste suivante des problèmes courants pour obtenir des conseils spécifiques au scénario :
P RO B L ÈM E O U ERREUR SO L UT IO N
Gestionnaire de serveur collecte des données d’inventaire. Gestionnaire de serveur ne peut pas être utilisé pour gérer
L’Assistant sera disponible une fois la collecte de données les serveurs qui exécutent une version plus récente de
terminée. Windows Server que la version qui exécute Gestionnaire de
serveur. Par exemple, Gestionnaire de serveur en cours
d’exécution dans Windows 8 dans le cadre des outils
d’administration de serveur distant ne peuvent pas être
utilisés pour gérer un serveur qui exécute Windows Server
2012 R2.
P RO B L ÈM E O U ERREUR SO L UT IO N
Erreur 0x00070543 lors de la sélection des rôles dans Erreur 0x00070543

Gestionnaire de serveur
Erreur 0x800706BE et ne peut pas afficher les rôles ou les Erreur 0x800706BE
fonctionnalités
Erreur 0x800F0922 lors de la tentative de désinstallation de Erreur 0x800F0922

rôles ou de fonctionnalités
Erreur 0x800F081F lors de l’installation des fonctionnalités Erreur 0x800F081F
Erreur 0x800F0818 et impossible d’ajouter des rôles ou des Erreur 0x800F0818

fonctionnalités
Pour plus d’informations, consultez Installer ou désinstaller des rôles, des services de rôle ou des fonctionnalités.
Conseils de résolution des problèmes de mise à jour
du serveur Windows
Cette solution est conçue pour vous aider à prendre en main Windows Update scénarios de résolution des
problèmes.

Étape 1 : Identifier le problème en examinant le journal des événements pour détecter des erreurs spécifiques
1. Ouvrez observateur d'événements à partir des outils Panneau de configuration > Administrative.
2. Recherchez les événements Windows Update Agent dans le journal système et les erreurs dans les journaux
système et application au moment où les mises à jour ont été appliquées.
3. Développez l’arborescence observateur d'événements sur Application and Ser vice LogsMicrosoft > >
Windows > WindowsUpdateClientOperational > .
4. Identifiez la mise à jour qui ne parvient pas à s’installer et le code d’échec.
5. Recherchez l’erreur et la résolution dans Erreurs courantes Windows Update ou Windows Update codes
d’erreur par composant.
Étape 2 : Vérifier l’état de redémarrage en attente
Si l’ordinateur n’a pas été redémarré, redémarrez-le.
Étape 3 : Mise à jour de la pile des services
Installez la dernière mise à jour de la pile de maintenance. Consultez les dernières mises à jour de la pile de
maintenance.
Étape 4 : Exécuter l’utilitaire de résolution des problèmes de Windows Update pour Windows
1. Téléchargez l’utilitaire de résolution des problèmes, puis sélectionnez Ouvrir ou Enregistrer dans la fenêtre
contextuelle. (Si vous choisissez Enregistrer , vous devez ouvrir l’utilitaire de résolution des problèmes à
partir de l’emplacement d’enregistrement.)
2. Sélectionnez Suivant pour démarrer l’utilitaire de résolution des problèmes, puis suivez les étapes pour
identifier et résoudre les problèmes.
3. Une fois l’utilitaire de résolution des problèmes terminé, réessayez d’exécuter Windows Update. Dans le
bouton Démarrer , sélectionnez Paramètres > A & > > 0 Windows Update Vérifier les mises à jour et
installer les mises à jour disponibles.
4. Le cas échéant, réinitialiser les composants de mise à jour Windows.
Étape 5 : Utiliser DISM ou l’outil De préparation des mises à jour système pour résoudre Windows Update
problème
Pour plus d’informations, consultez Corriger les erreurs Windows Update à l’aide de l’outil DISM ou System
Update Readiness.

Vous recevez le message d’erreur « Mise à jour non applicable »
Message d’erreur
La mise à jour n’est pas applicable à votre ordinateur.

Cause 1 : La mise à jour est remplacée
Pour résoudre ce problème, vérifiez que le package que vous installez contient des versions plus récentes des
fichiers binaires. Vous pouvez également vérifier que le package est remplacé par un autre nouveau package.
Cause 2 : La mise à jour est déjà installée
Pour résoudre ce problème, vérifiez que le package que vous essayez d’installer n’est pas déjà installé.
Cause 3 : Mise à jour incorrecte pour l’architecture
Pour résoudre ce problème, vérifiez que le package que vous essayez d’installer correspond à la version
Windows que vous utilisez. Les informations de version Windows se trouvent dans la section « S’applique à » de
l’article pour chaque mise à jour. Par exemple, les mises à jour Windows Server 2012 uniquement ne peuvent
pas être installées sur Windows Server 2012 ordinateurs R2.
Vérifiez que le package que vous souhaitez installer correspond à l’architecture de processeur de la version
Windows que vous utilisez. Par exemple, une mise à jour x86 ne peut pas être installée sur les installations x64
de Windows.
Cause 4 : Mise à jour requise manquante
Pour résoudre ce problème, lisez l’article associé au package pour savoir si les mises à jour préalables sont
installées. Par exemple, si vous recevez le message d’erreur dans Windows 8.1 ou Windows Server 2012 R2,
vous devrez peut-être installer la mise à jour d’avril 2014 2919355 comme condition préalable et une ou
plusieurs mises à jour de maintenance préalables (KB 2919442 et KB 3173424).
Pour déterminer si ces mises à jour préalables sont installées, exécutez cette commande PowerShell :
get-hotfix KB3173424, KB2919355, KB2919442
Si les mises à jour sont installées, la commande retourne la date d’installation dans la section InstalledOn de la
sortie.
Les mises à jour ne sont pas téléchargées à partir de Windows Server Update Services (WSUS ) ou de
Configuration Manager
Message d’erreur :
Échec de la connexion à Mux en raison d’erreurs de réseau ou de certificat
Pour résoudre ce problème, vérifiez le code numérique fourni dans le code du message d’erreur : il correspond
au code d’erreur winsock. Les erreurs de certificat sont granulaires (par exemple, le certificat ne peut pas être
vérifié, le certificat non autorisé, etc.)
L’appareil ne reçoit pas de mise à jour que vous avez déployée
1. Vérifiez que les mises à jour de l’appareil pour la catégorie appropriée ne sont pas suspendues. Consultez
Mettre en pause les mises à jour des fonctionnalités et suspendre les mises à jour qualité.
2. Mises à jour des fonctionnalités uniquement : l’appareil peut avoir une conservation de protection
appliquée pour la version de mise à jour des fonctionnalités donnée. Pour plus d’informations sur les
conservations de protection, consultez Conservations de sauvegarde et Refus des conservations de
sauvegarde.
3. Vérifiez que le déploiement auquel l’appareil est affecté dispose de l’offre d’état. Les déploiements dont
les états sont suspendus ou planifiés ne déploient pas de contenu sur les appareils.
4. Vérifiez que l’appareil a analysé les mises à jour et analyse le service Windows Update. Pour en savoir
plus sur l’analyse des mises à jour, consultez Analyse des mises à jour.
5. Mises à jour des fonctionnalités uniquement : vérifiez que l’appareil est correctement inscrit dans la
gestion des mises à jour des fonctionnalités par le service de déploiement. Un appareil inscrit avec succès
est représenté par une ressource d’appareil Azure AD avec une inscription de gestion des mises à jour
pour les mises à jour de fonctionnalités et n’a pas d’erreurs d’inscription d’appareil Azure AD.
6. Mises à jour qualité accélérées uniquement : vérifiez que update Health Tools est installé sur l’appareil
(disponible pour Windows 10 version 1809 ou ultérieure de la mise à jour décrite dans KB 4023057 -
Update for Windows 10 Update Service components, or a recent quality update). Update Health Tools est
requis pour qu’un appareil reçoive une mise à jour de qualité accélérée. L’emplacement du programme
sur l’appareil est C:\Program FilesMicrosoft\ Update Health Tools.
Pour vérifier sa présence, affichez la liste des programmes installés ou utilisez ce script PowerShell :
Get-WmiObject -Class Win32\_Product \| Where-Object {$\_.Name -amatch "Microsoft Update Health

Tools"}
L’appareil reçoit une mise à jour que vous n’avez pas déployée
1. Vérifiez que l’appareil analyse le service Windows Update et non un point de terminaison différent. Si
l’appareil recherche des mises à jour à partir d’un point de terminaison WSUS, par exemple, il peut recevoir
différentes mises à jour. Pour en savoir plus sur l’analyse des mises à jour, consultez Analyse des mises à jour.
2. Mises à jour des fonctionnalités uniquement : vérifiez que l’appareil est correctement inscrit dans la gestion
des mises à jour des fonctionnalités par le service de déploiement. Un appareil qui n’est pas inscrit
correctement peut recevoir des mises à jour différentes en fonction de sa période de report de mise à jour
des fonctionnalités. Un appareil inscrit avec succès est représenté par une ressource d’appareil Azure AD avec
une inscription de gestion des mises à jour pour les mises à jour de fonctionnalités et n’a pas d’erreurs
d’inscription d’appareil Azure AD.
Résolution des problèmes WSUS

Échecs de connexion WSUS
Si vous utilisez WSUS 3.0 SP2 sur Windows Server 2008 R2, une mise à jour 4039929 ou un package de mise à
jour version ultérieure doit être installé sur le serveur WSUS.
Voici comment vérifier la version du serveur :
1. Ouvrez la console WSUS.
2. Sélectionnez le nom du serveur.
3. Recherchez le numéro de version sous Over viewConnectionSer ver > > Version .
4. Vérifiez si la version est 3.2.7600.283 ou une version ultérieure.
Si vous utilisez WSUS sur Windows Server 2012 ou une version ultérieure, vous devez disposer de l’un des
correctifs cumulatifs mensuels de qualité de la sécurité suivants ou d’un correctif cumulatif version ultérieure
installé sur le serveur WSUS :
Windows Server 2012 - KB4039873
Windows Server 2012 R2 - KB4039871
Windows Server 2016 - KB4039396
NOTE
Si vous utilisez Configuration Manager avec le point de mise à jour logicielle installé sur un serveur de système de site
distant, la console d’administration WSUS doit être installée sur le serveur de site. Pour WSUS 3.0 SP2, la base de
connaissances 4039929 ou une mise à jour ultérieure doit également être installée sur la console d’administration WSUS.
Un redémarrage du serveur est nécessaire après l’installation de 4039929 (à distance ou localement). Vérifiez si le
problème persiste après le redémarrage.
Pour résoudre les échecs de connexion, procédez comme suit :
1. Vérifiez que le service Update Ser vices et le ser vice world wide web publishing sont en cours
d’exécution sur le serveur WSUS.
2. Vérifiez que le site web par défaut ou le site web d’administration WSUS s’exécute sur le serveur WSUS.
3. Passez en revue les journaux IIS du site web d’administration WSUS (c:\inetpublogfiles\) et recherchez les
erreurs.
Code d’erreur : 80244007
Message d’erreur :
SyncUpdates_WithRecovery a échoué
Pour résoudre le problème, procédez comme suit sur le serveur WSUS :

1. Ouvrez une fenêtre d’invite de commandes avec élévation de privilèges et accédez à l’emplacement
suivant :
%programfiles%\Update ServicesWebServicesClientWebService\\
takeown /f web.config
icacls web.config /grant administrator:(F)
notepad.exe web.config
3. Recherchez la ligne suivante dans web.config :
<add key="maxInstalledPrerequisites" value="400"/>
4. Modifiez la valeur de 400 à 800 .

5. Enregistrez le fichier web.config.
6. Exécutez IISReset .
Avant de contacter le support Microsoft, vous pouvez collecter des informations sur votre problème.
Prerequisites
1. TSSv2 doit être exécuté par des comptes disposant de privilèges d’administrateur sur le système local, et le
CLUF doit être accepté (une fois le CLUF accepté, TSSv2 n’est plus invité).
2. Nous vous recommandons la stratégie d’exécution PowerShell de l’ordinateur RemoteSigned local.
NOTE
Si la stratégie d’exécution PowerShell actuelle n’autorise pas l’exécution de TSSv2, effectuez les actions suivantes :
Définissez la RemoteSigned stratégie d’exécution pour le niveau de processus en exécutant l’applet de commande
PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned .
Pour vérifier si la modification prend effet, exécutez l’applet de commande PS C:\> Get-ExecutionPolicy -List .
Étant donné que les autorisations au niveau du processus s’appliquent uniquement à la session PowerShell actuelle,
une fois la fenêtre PowerShell donnée dans laquelle TSSv2 s’exécute est fermée, l’autorisation affectée pour le niveau de
processus revient également à l’état précédemment configuré.
Collecter les informations clés avant de contacter le support Microsoft
1. Téléchargez TSSv2 sur tous les nœuds et décompressez-le dans le dossier C:\tss_tool .
2. Ouvrez le dossier C:\tss_tool à partir d’une invite de commandes PowerShell avec élévation de privilèges.
3. Démarrez les traces sur l’ordinateur problématique à l’aide de l’applet de commande suivante :
TSSv2.ps1 -CollectLog DND_SetupReport
4. Répondez à l’invite du CLUF.

5. Attendez que les scripts automatisés terminent la collecte des données requises.
Les traces sont stockées dans un fichier zip dans le dossier C:\MS_DATA\ , qui peut être chargé dans l’espace de
travail à des fins d’analyse.
Référence
Fichiers journaux créés par Windows Update
Dépannage de Windows Update
Windows Update erreurs courantes et l’atténuation
Résolution des problèmes liés aux agents clients WSUS
Script PowerShell pour refuser les mises à jour remplacées dans WSUS
Windows Server Update Services meilleures pratiques
Redémarrage des ordinateurs clients WSUS sans notification
Le client WSUS prend trop de temps pour terminer une analyse de mise à jour
Impossible de se connecter au site web
d’administration WSUS
Cet article fournit une solution à un problème dans lequel vous ne pouvez pas vous connecter au site web
d’administration WSUS.
Symptômes
Vous ne pouvez pas vous connecter au site web d’administration WSUS lors de l’ouverture de «
Windows Ser ver Update Ser vice »
En outre, lorsque vous ouvrez Windows Console Small BusinessServer, vous obtenez le message d’erreur «
Une erreur s’est produite lors de la récupération des informations de mise à jour » sous l’onglet « Mises à
jour ».
Vous voyez l’erreur HTTP 500 dans le fichier journal IIS pour le site web d’administration WSUS :
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 GET /selfupdate/iuident.cab - 8530 -

fe80::e3a4:2b81:92b4:c6e7%11 - 500 24 50 3715
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /reportingwebservice/reportingwebservice.asmx - 8530
- fe80::e3a4:2b81:92b4:c6e7%11 Mozilla/4.0+
(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.4927) 500 24 50 422
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /ApiRemoting30/WebService.asmx - 8530 -
fe80::e3a4:2b81:92b4:c6e7%11 Mozilla/4.0+
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /ServerSyncWebService/serversyncwebservice.asmx -
8530 - fe80::e3a4:2b81:92b4:c6e7%11 Mozilla/4.0+
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /ClientWebService/Client.asmx - 8530 -
fe80::e3a4:2b81:92b4:c6e7 %11 Mozilla/4.0+
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /ReportingWebService/ReportingWebService.asmx -
8530 - fe80::e3a4:2b81:92b4:c6e7%11 Windows-Update-Agent 500 24 50 12078
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /SimpleAuthWebService/SimpleAuth.asmx - 8530 -
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /DssAuthWebService/DssAuthWebService.asmx - 8530 -
<DateTime> fe80::e3a4:2b81:92b4:c6e7%11 POST /ApiRemoting30/WebService.asmx - 8530 -
Après l’activation du suivi des demandes échouées sur les sites web « Administration WSUS » et «
ApiRemoting30 » pour le code d’état Http 500, les erreurs suivantes se sont éventuellement
échouées.
http://<ServerName>:8530/ApiRemoting30/WebService.asmx
Serveur d’authentification WsusPool du pool d’applications NOT_AVAILABLE

Utilisateur à partir du jeton
ID d’activité {00000000-0000-0000-9000-008000000D3}
Site 1572271583
Processus 6860
Motif de l’échec STATUS_CODE
État du déclencheur 500.24
État final 500.24
Durée : 16 msec
ModuleName ConfigurationValidationModule
Notification 1
HttpStatus 500
Erreur de serveur interne HttpReason
HttpSubStatus 24
ErrorCode 2147942450
ConfigExceptionInfo
Notification BEGIN_REQUEST
ErrorCode The request is not supported. (0x80070032)
Erreurs dans les journaux des applications

Source : Windows Server Update Services
Date : <DateTime>
Niveau : Erreur
Utilisateur : N/A
Ordinateur : ServerName.domain.local
Description :
La console d’administration WSUS a rencontré une erreur inattendue. Il peut s’agit d’une erreur passagère .
essayez de redémarrer la console d’administration. Si cette erreur persiste, essayez de supprimer les
préférences persistantes de la console en supprimant le fichier wsus sous %appdata%\Microsoft\MMC \ .
System.InvalidOperationException -- Le client a trouvé le type de contenu de réponse « text/html ;
charset=utf-8', mais attendu 'text/xml'.
La demande a échoué avec le message d’erreur :
.
.
.
Source
System.Web.Services
Trace de pile :
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,
WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.UpdateServices.Internal.ApiRemoting.ExecuteSPGetUpdateServerStatus(Int32 updateSources,
Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String
preferredCulture, Int32 publicationState, Int32 propertiesToGet)
chez Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.
ExecuteSPGetUpdateServerStatus(UpdateSources updateSources, Boolean includeDownstreamComputers,
String updateScopeXml, String computerTargetScopeXml, String preferredCulture, ExtendedPublicationState
publicationState, UpdateServerStatusPropertiesToGet propertiesToGet)
at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetStatus(UpdateSources updateSources,
Boolean includeDownstreamComputers, UpdateScope updatesToInclude, ComputerTargetScope
computersToInclude, UpdateServerStatusPropertiesToGet propertiesToGet) at
Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetReplicaStatus(UpdateSources updateSources)
at Microsoft.UpdateServices.UI.SnapIn.Common.CachedUpdateServerStatus.GetFreshObjectForCache()
at Microsoft.UpdateServices.UI.AdminApiAccess.CachedObject.GetFromCache()
at Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_DoWork(Object
sender, DoWorkEventArgs e)
Cause
Le comportement ci-dessus est dû à des paramètres incorrects sur le site web d’administration WSUS. Par
défaut, nous n’avons pas « activé » pour l’un des sites web ASP.NET Impersonation d’administration WSUS.
Résolution
Ouvrir la console IIS
Mettre en surbrillez le site web d’administration WSUS
Double-cliquez sur «Authentification »
ASP.NET Impersonation Surligner, à droite sous le volet «Action » cliquez sur «Désactiver »
Vérifiez les sites web suivants sous Administration WSUS et ASP.NET Impersonation assurez-vous qu’il est
désactivé. Si l’une des applications Web ci-dessous a ASP.NET Authentication été activée,** désactivez-les.
ApiRemoting30
ClientWebService
Content
DssAuthWebService
Inventaire
ReportingWebService
Selfupdate
ServerSyncWebService
SipleAuthWebService
Redémarrer IIS
Can’t install the .NET Framework 3.5 without a
public Internet environment on an OEM Windows
installation
Cet article fournit une solution de contournement pour un problème dans lequel l’installation de Microsoft .NET
Framework 3.5 échoue sans environnement Internet public sur une installation Windows OEM.
Symptômes
Vous avez un environnement réseau exclusif qui n’est pas connecté à Internet.
Un système d Windows d’exploitation standard est installé à partir d’une image OEM standard dans cet
environnement. Cette image peut inclure une combinaison de langues et les dernières mises à jour
pertinentes pour le système et l’environnement.
Vous essayez d’installer .NET Framework 3.5 ou .NET Framework 3.5 Service Pack 1 (SP1) sur cet ordinateur.
Dans ce scénario, vous recevez un message d’erreur et l’installation .NET Framework’installation échoue.
L.NET Framework’installation échoue également dans l’une des situations suivantes :
Vous utilisez le package autonome .NET Framework redistribuable.
Le dossier sources\sxs du support d’installation d’origine est utilisé comme source alternative.
Cause
Ce problème se produit parce Windows a été conçu dans l’intention que le système d’exploitation aurait accès à
Internet.
Si vous ne pouvez pas accéder à Internet, la .NET Framework 3.5 doit tirer les données d’une autre source. Si
cette source ne correspond pas explicitement au système d’exploitation d’installation (comme un correctif
logiciel, une version de correctif ou un fichier spécifique au pack de langue installé), vous rencontrerez ce
problème.
Pour contourner ce problème, créez un support d’installation .NET Framework 3.5 préinstallé. Pour ce faire,
suivez les étapes de la page web suivante pour chaque langue qui sera installée sur ce système d’exploitation : le
.NET Framework 4.5 est la valeur par défaut et le .NET Framework 3.5 est facultatif Ou, vous pouvez
temporairement connecter l’ordinateur qui a besoin de .NET Framework 3.5 à Internet pour installer le .NET
Framework.
NOTE
Vous devez effectuer ces étapes avant d’installer les packs de langue. Toutefois, les correctifs logiciels doivent
généralement être installés après l’installation des packs de langue.
État
S’applique à ». Actuellement, il n’existe pas de stratégie efficace pour les systèmes d’exploitation existants.
Toutefois, ce problème est en cours d’examen pour les systèmes d’exploitation futurs.
Si vous avez réussi à créer une autre source d’installation à l’aide d’une image de système d’exploitation hors
connexion, sachez qu’avec cette solution, vous devez vous assurer que toutes les mises à jour (correctifs) qui
peuvent se trouver sur les ordinateurs cibles avec tous les packs de langue sont appliquées à cette autre source.
Cette image doit être mise à jour à mesure que de nouvelles mises à jour sont publiées.
NOTE
Certains correctifs ne peuvent être obtenus qu’en contactant Microsoft directement. Ces correctifs doivent également être
pris en compte lorsque vous créez la source d’installation si cet itinéraire est sélectionné.
Notre recommandation concernant la création d’un support d’installation (comme mentionné dans la section «
Solution de contournement ) consiste à créer un support autre source et à le tester, car ce processus s’est révélé
coûteux en raison du temps à passer. Cela est comparé à la création d’un support d’installation à l’aide de
versions de fichier connues.
Vous ne pouvez pas installer certaines mises à jour
ou programmes dans Windows XP
Cet article vous propose des méthodes manuelles avancées qui peuvent être utilisées pour résoudre certains
problèmes qui vous empêchent d’installer certaines mises à jour ou programmes.
Symptômes
Lorsque vous essayez de télécharger un contrôle ActiveX, d’installer une mise à jour sur Windows ou sur un
composant Windows, d’installer un Service Pack pour Windows ou pour un composant Windows, ou d’installer
un programme logiciel Microsoft ou tiers, vous pouvez être face à un ou plusieurs des symptômes suivants :
NOTE
Ces problèmes peuvent se produire pour ces raisons.
Vous recevez le message d’erreur suivant lorsque vous essayez d’installer un programme ou de mettre à
jour :
Signature numérique in trouvée

La signature numérique Microsoft confirme que le logiciel a été testé avec Windows et que le logiciel
n’a pas été modifié depuis qu’il a été testé.
Le logiciel que vous êtes sur le point d’installer ne contient pas de signature numérique Microsoft. Par
conséquent, il n’existe aucune garantie que ce logiciel fonctionne correctement avec Windows.
Nom du package logiciel
Si vous souhaitez rechercher des logiciels signés numériquement par Microsoft, visitez le site Web de
mise à jour Windows microsoft pour voir si un logiciel http://update.microsoft.com est disponible.
Voulez-vous poursuivre l’installation ?
Si vous cliquez sur Plus d’informations, vous recevez le message suivant :
Microsoft Windows
La signature du package logiciel que vous souhaitez installer n’est pas valide. Le package logiciel n’est
pas signé correctement.
Une fois que vous avez cliqué sur OK dans la boîte de dialogue du premier message d’erreur, vous
recevez un message qui indique que l’installation a réussi ou le message d’erreur suivant :
Nom du package de mise à jour

L’opération de chiffrement a échoué en raison d’un paramètre d’option de sécurité local.
Lorsque vous essayez d’installer une mise à jour ou un Service Pack, vous recevez un message d’erreur
semblable à l’un des suivants :
Erreur 1
Nom du package de mise à jour

Le programme d’installation n’a pas pu vérifier l’intégrité du fichier Update.inf. Assurez-vous
que le service de chiffrement est en cours d’exécution sur cet ordinateur.
Erreur 2
Échec de l’installation des fichiers catalogues.
Erreur 3
Le logiciel que vous installez n’a pas Windows le test du logo pour vérifier sa compatibilité
avec Windows XP. (Dites-moi pourquoi ce test est important.)
Ce logiciel ne sera pas installé. Contactez votre administrateur système.
Erreur 4
Le logiciel que vous installez n’a pas Windows le test du logo pour vérifier sa compatibilité
avec cette version de Windows. (Dites-moi pourquoi ce test est important.)
Lorsque vous essayez d’installer un Service Pack Windows XP, vous recevez un message d’erreur
semblable au suivant :
Le programme d’installation du Service Pack 1 n’a pas pu vérifier l’intégrité du fichier. Assurez-vous
que le service de chiffrement est en cours d’exécution sur cet ordinateur.
Lorsque vous tentez d’installer Microsoft Data Access Components (MDAC) 2.8, vous recevez un message
d’erreur semblable au suivant :
Échec de l’installation d’INF. Raison : la signature et/ou le certificat d’timestamp n’ont pas pu être
vérifiés ou sont malformés.
Le %WINDIR%\System32\CatRoot2\Edb.log peut atteindre 20 mégaoctets (Mo) même si le fichier est

généralement inférieur à 1 Mo.
Lorsque vous essayez d’installer un package à partir du site Web Windows Update ou du site Web
Microsoft Update, vous recevez un message semblable à ce qui suit :
Le logiciel n’a pas Windows de logo et ne sera pas installé.
Lorsque vous examinez le fichier %systemroot%\Windowsupdate.log, vous voyez une entrée pour l’une
des erreurs suivantes :
0x80096001
0x80096005
0x80096010
0x800B0001
0x800B0003
0x800B0004
0x800B0109
0x8007f0da
0x8007f01e
Lorsque vous utilisez Microsoft Windows Update sur un ordinateur Windows XP, le processus de mise à
jour échoue et vous recevez un message 0x8007f007'erreur. Cela peut se produire quel que soit le type
de mise à jour que vous sélectionnez.
Le fichier Svcpack.log peut contenir des entrées semblables aux suivantes :
937.406 : GetCatVersion : Échec de la récupération des informations de version de C:\WINDOWS\system32

\CatRoot { F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Tmp.0.scw.cat erreur 0x57 937.437 : GetCatVersion
: Échec de récupération des informations de version à partir de C:\WINDOWS\Tmp.0.scw.cat avec l’erreur
0x80092004 940.344 : InstallSingleCatalogFile : MyInstallCatalog a échoué pour Tmp.0.scw.cat ;
error=0xfffffbfe. 940.344: DoInstallation:MyInstallCatalogFiles failed:STR_CATALOG_INSTALL_FAILED
955.125 : UnRegisterSpuninstForRecovery, échec de suppression de la valeur SpRecoverCmdLine, erreur 0x2
955.125 : DoInstallation : échec de l'spuninst.exe pour la récupération.
962.656 : Désinsinstallation du programme de désinstallation -> Windows Server 2003 Service Pack, 0
962.656 : Échec de l’installation des fichiers catalogue. 1448.406 : Message affiché à l’utilisateur : Échec de
l’installation des fichiers catalogue.
1448.406 : Entrée utilisateur : OK
1448.406 : Update.exe code d’erreur étendu = 0xf01e
1448.406 : Update.exe code de retour a été masqué 0x643 pour la conformité des actions personnalisées
MSI.
Cause
Ces problèmes peuvent se produire dans l’une des situations suivantes :
Le fichier journal ou la base de données est corrompu dans le dossier %Systemroot%\System32\Catroot2.
Les ser vices de chiffrement sont désactivés.
D’Windows fichiers sont endommagés ou manquants.
La signature ou le certificat d’timestamp n’a pas pu être vérifié ou est malformé.
L’attribut masqué est définie pour le dossier %Windir% ou l’un de ses sous-dossiers.
Le paramètre de stratégie de groupe Comportement d’installation non-pilote non signé (Windows 2000
uniquement) est définie sur Ne pas autoriser l’installation ou Avertir, mais autoriser l’installation, ou la
valeur binaire de la stratégie n’est pas définie sur 0 dans la clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Non-Driver Signing
Le paramètre Activer la stratégie de groupe Activer le verrouillage de l’éditeur approuvé est activé et
vous n’avez pas le certificat approprié dans votre magasin de certificats Éditeurs de confiance. Ce paramètre
de stratégie de groupe se trouve sous Configuration utilisateur, sous Windows Paramètres , sous
Maintenance Internet Explorer , sous Sécurité , sous Authenticode Paramètres dans le logiciel en ligne
MMC de stratégie de groupe.
Vous installez Internet Explorer 6 SP1 et la mise à jour de sécurité 823559 (MS03-023) est installée.
Le dossier de distribution de logiciels est endommagé.
Méthode 1 : renommer le fichier Edb.log

Renommez le fichier Edb.log, puis essayez à nouveau d’installer le programme. Pour renommer le fichier
Edb.log, suivez les étapes suivantes :
NOTE
Sur un ordinateur Windows Vista, cliquez sur Démarrer, tapez cmd dans la zone de texte Démarrer la recherche,
cliquez avec le bouton droit sur cmd.exe, puis cliquez sur Exécuter en tant qu’administrateur.
ren %systemroot%\system32\catroot2\Edb.log *.tst
Méthode 2 : désactiver temporairement le verrouillage des éditeurs

de confiance et installer les certificats appropriés dans votre magasin
de certificats d’éditeurs de confiance
Vous pouvez continuer à utiliser le paramètre de stratégie de groupe Activer le verrouillage de l’éditeur
approuvé, mais vous devez d’abord ajouter les certificats appropriés à votre magasin de certificats Éditeurs de
confiance. Pour ce faire, éteillez le paramètre De stratégie de groupe Activer le verrouillage de l’éditeur
approuvé, installez les certificats appropriés dans votre magasin de certificats Éditeurs de confiance, puis activez
à nouveau le paramètre Activer la stratégie de groupe de verrouillage de l’éditeur approuvé. Pour installer le
certificat approprié pour les mises à jour de produits Microsoft Windows et Microsoft Internet Explorer, suivez
1. Téléchargez la mise à jour du produit Microsoft que vous souhaitez installer à partir du Centre de
téléchargement Microsoft, du catalogue Windows Update ou de Microsoft Update.
Pour plus d’informations sur le téléchargement des mises à jour de produits à partir du Centre de
téléchargement Microsoft, voir comment obtenir des fichiers de support Microsoft à partir du catalogue
de services en ligne.
Pour plus d’informations sur le téléchargement des mises à jour de produits à partir du catalogue de
mises à jour Windows, voir comment télécharger des mises à jour qui incluent des pilotes et des
correctifs à partir du catalogue de mises à jour Windows.
2. Extrayer le package de mise à jour du produit dans un dossier temporaire. La commande de ligne de
commande que vous utilisez pour ce faire dépend de la mise à jour que vous essayez d’installer.
Consultez l’article de la Base de connaissances Microsoft associé à la mise à jour pour déterminer les
commutateurs de ligne de commande appropriés que vous utiliserez pour extraire le package. Par
exemple, pour extraire la mise 824146 de sécurité pour Windows XP dans le dossier C:\824146, exécutez
Windowsxp-kb824146-x86-enu -x:c:\824146 . Pour extraire la mise à jour de sécurité 828750 pour Windows
XP dans le dossier C:\828750, exécutez q828750.exe /c /t:c:\828750 .
3. Cliquez avec le bouton droit sur le fichier .cat de numéro de la base de données de la base de données à
partir du package de mise à jour du produit dans le dossier temporaire que vous avez créé à l’étape 2,
puis cliquez sur Propriétés.
NOTE
Le fichier KB Number .cat peut se présenter dans un sous-dossier. Par exemple, le fichier peut se présenter dans le
dossier C:\824146\sp1\update ou dans le dossier C:\824146\sp2\update.
4. Sous l’onglet Signatures numériques, cliquez sur la signature numérique, puis sur Détails.
5. Cliquez sur Afficher le certificat, puis sur Installer le cer tificat.
6. Cliquez sur Suivant pour démarrer l’Assistant Impor tation de certificat.
7. Cliquez sur Placer tous les cer tificats dans le magasin suivant, puis cliquez sur Parcourir.
8. Cliquez sur Éditeurs de confiance, puis sur OK.
9. Cliquez sur Suivant, cliquez sur Terminer, puis sur OK.
Méthode 3 : vérifier l’état de tous les certificats dans le chemin

d’accès de certification et importer les certificats manquants ou
endommagés à partir d’un autre ordinateur
Pour vérifier les certificats dans le chemin d’accès du certificat pour une mise à jour Windows produit Internet
Explorer ou Internet Explorer, suivez les étapes suivantes :
Étape 1 : Vérifier les certificats Microsoft
1. Dans Internet Explorer, cliquez sur Outils , puis cliquez sur Options Internet .
2. Sous l’onglet Contenu, cliquez sur Cer tificats.
3. Sous l’onglet Autorités de cer tification racines de confiance, double-cliquez sur Autorité racine
Microsoft . Si ce certificat est manquant, allez à l’étape 2.
4. Sous l’onglet Général, assurez-vous que les dates valides sont du 10/01/1997 au 31/12/2020 .
5. Sous l’onglet Chemin d’accès de certification, vérifiez que ce cer tificat est OK apparaît sous État du
cer tificat.
6. Cliquez sur OK, puis double-cliquez sur le cer tificat ACCEPTÉ SANS RESPONSABILITÉ.
7. Sous l’onglet Général, assurez-vous que les dates Valides du 11/05/1997 au 07/01/2004 .
8. Sous l’onglet Chemin d’accès de certification, vérifiez que ce certificat a expiré ou n’est pas encore
valide ou que ce certificat est OK apparaît sous État du cer tificat.
NOTE
Bien que ce certificat soit arrivé à expiration, il continuera de fonctionner. Le système d’exploitation peut ne pas
fonctionner correctement si le certificat est manquant ou révoqué. Pour plus d’informations, consultez Certificats
racines de confiance requis.
9. Cliquez sur OK, puis double-cliquez sur le cer tificat GTE CyberTrust Root. Vous pouvez avoir
plusieurs de ces certificats du même nom. Vérifiez le certificat dont la date d’expiration est le 23/02/2006.
10. Sous l’onglet Général, assurez-vous que les dates valides sont du 23/02/1996 au 23/02/2006.
cer tificat.
NOTE
Bien que ce certificat soit arrivé à expiration, il continuera de fonctionner. Le système d’exploitation peut ne pas
fonctionner correctement si le certificat est manquant ou révoqué.
12. Cliquez sur OK, puis double-cliquez sur Thawte Timestamping CA .

13. Sous l’onglet Général, assurez-vous que les dates valides sont du 31/01/12/1996 au 31/12/2020.
cer tificat.
Étape 2 : Importer des certificats manquants ou endommagés
Si un ou plusieurs de ces certificats sont manquants ou endommagés, exportez les certificats manquants ou
endommagés vers un autre ordinateur, puis installez les certificats sur votre ordinateur. Pour exporter des
certificats sur un autre ordinateur, suivez les étapes suivantes :
1. Dans Internet Explorer, cliquez sur Outils , puis cliquez sur Options Internet .
2. Sous l’onglet Contenu, cliquez sur Cer tificats.
3. Sous l’onglet Autorités de cer tification racines de confiance, cliquez sur le certificat à exporter.
4. Cliquez sur Exporter, puis suivez les instructions pour exporter le certificat en tant que fichier binaire codé
DER x.509(. Fichier CER.
5. Une fois le fichier de certificat exporté, copiez-le sur l’ordinateur sur lequel vous souhaitez l’importer.
6. Sur l’ordinateur sur lequel vous souhaitez importer le certificat, double-cliquez sur le certificat.
7. Cliquez sur Installer le certificat, puis sur Suivant.
8. Cliquez sur Terminer , puis sur OK .
Méthode 4 : effacer le fichier temporaire et redémarrer l’installation

de correctifs logiciels ou l’installation du Service Pack
Pour effacer le fichier temporaire et redémarrer l’installation de correctifs ou l’installation du Service Pack,
2. À l’invite de commandes, tapez les commandes suivantes. Appuyez sur Entrée après chaque commande.
net stop cryptsvc

ren %systemroot%\System32\Catroot2 oldcatroot2
net start cryptsvc
exit
3. Supprimez tous les fichiers tmp*.cat dans les dossiers suivants :

%systemroot% \system32\CatRoot { 127D0A1D-4EF2-11D1-8608-00C04FC295EE}
%systemroot% \system32\CatRoot { F750E6C3-38EE-11D1-85E5-00C04FC295EE}
Si aucun fichier qui commence par tmp n’existe dans ce dossier, ne supprimez aucun autre fichier. Les
fichiers .cat de ce dossier sont nécessaires à l’installation de correctifs logiciels et de Service Packs.
IMPORTANT
Ne renommez pas le dossier Catroot. Le dossier Catroot2 est automatiquement recréé par Windows, mais le
dossier Catroot n’est pas recréé si le dossier Catroot est renommé.
4. Supprimez tous les oem . du dossier %systemroot% \inf.

5. Redémarrez l’installation de correctifs ou l’installation du Service Pack qui a échoué.
Méthode 5 : Vider le dossier de distribution de logiciels

NOTE
Sur un ordinateur Windows Vista, cliquez sur Démarrer, tapez services.msc dans la zone Démarrer la recherche,
cliquez avec le bouton droit sur ser vices.msc, puis cliquez sur Exécuter en tant qu’administrateur.
2. Dans le volet Services (local), cliquez avec le bouton droit sur Mises à jour automatiques, puis cliquez
sur Arrêter.
3. Réduisez la fenêtre Services (local).
4. Sélectionnez tout le contenu du dossier Windows distribution, puis supprimez-les.
NOTE
Par défaut, le Windows de distribution est situé dans le dossier drive :\Windows\SoftwareDistribution. À cet
emplacement, le lecteur est un espace réservé pour le lecteur sur lequel Windows est installé.
5. Assurez-vous que le Windows de distribution est vide, puis agrandissez la fenêtre Services (local).
6. Dans le volet Ser vices (local), cliquez avec le bouton droit sur Mises à jour automatiques, puis
cliquez sur Démarrer.
7. Redémarrez l’ordinateur, puis ré-exécutez Windows mise à jour.
Méthode 6 : effectuer une mise à niveau sur place

Si toutes ces méthodes ne résolvent pas votre problème, vous de devez peut-être effectuer une mise à niveau
sur place.
Le fichier CBS.log contient des entrées que certains
fichiers ne sont pas réparés même après avoir
exécuté l’utilitaire SFC sur un ordinateur Windows
Server
Cet article décrit un problème dans lequel le fichier CBS.log enregistre les entrées lorsqu’un fichier statique
change. Étant donné que le fichier statique n’est pas protégé par la fonctionnalité Windows protection des
ressources, la fonctionnalité signale la modification dans le fichier CBS.log.
Symptômes
Vous exécutez l’utilitaire SFC (System File Checker) (Sfc.exe) pour analyser les modifications apportées aux
fichiers système Windows sur un ordinateur Windows Server 2008. Lorsque vous exécutez l’utilitaire SFC, vous
pouvez recevoir le message suivant :
Tous les fichiers et clés de Registre répertoriés dans cette transaction ont été réparés avec succès.
Toutefois, lorsque vous affichez le fichier %windir%\Logs\CBS\CBS.log généré par le programme Sfc.exe, vous
pouvez voir les entrées suivantes :
<Date><Time>, Info CSI 00000142 [SR] Réparation de 1 composants

<Date><Time>, Info CSI 00000143 [SR] Début de la transaction vérifier et réparer
<Date>, Info CSI 00000145 [SR] Impossible de réparer le fichier membre <Time> [l:18 {9} ]"img11.jpg » de
Microsoft-Windows-Shell-Wallpaper-Common, Version = 6.0.5720.0, pA =
PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8
b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
<Date>, Info CSI 00000147 [SR] Impossible de réparer le fichier membre <Time> [l:18 {9} ]"img11.jpg » de
Microsoft-Windows-Shell-Wallpaper-Common, Version = 6.0.5720.0, pA =
PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8
b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
<Date><Time>, Info CSI 00000149 [SR] Réparation terminée
<Date><Time>, Info CSI 0000014a [SR] Validation de la transaction
<Date><Time>, Info CSI 0000014e [SR] Vérifier et réparer la transaction terminée. Tous les fichiers et clés
de Registre répertoriés dans cette transaction ont été réparés avec succès
Cause
Les fichiers statiques et mutables sont les deux types de fichiers définis dans le système. Les fichiers statiques ne
peuvent pas être modifiés. Les fichiers mutables peuvent être modifiés. Les fichiers de Registre et les fichiers
journaux sont des exemples de fichiers mutables. La fonctionnalité Windows protection des ressources
d’exploitation (WRP) n’analyse pas les fichiers mutables. La fonctionnalité WRP analyse les fichiers statiques
lorsque l’utilitaire SFC analyse l’ordinateur. La fonctionnalité WRP permet de protéger la plupart des fichiers
statiques. Toutefois, dans ce cas, la fonctionnalité WRP ne protège pas Img11.jpg fichier statique. Si un fichier
statique change lorsque la fonctionnalité WRP analyse le fichier, la modification est enregistrée dans le fichier
CBS.log. Étant donné que la fonctionnalité WRP ne protège pas le fichier statique Img11.jpg, la fonctionnalité
WRP n’a d’autre option que de signaler la modification dans le fichier CBS.log.
Le Sfc.exe écrit les détails de chaque opération de vérification et de chaque opération de réparation dans le
fichier CBS.log. Chaque SFC.exe du programme dans le fichier CBS.log possède une balise [SR].
NOTE
Le service Windows Modules Installer écrit également dans le fichier CBS.log. Le service Windows Modules Installer
installe des fonctionnalités, des mises à jour et des Service Packs facultatifs.
Vous pouvez rechercher des balises [SR] pour vous aider à localiser SFC.exe entrées de programme. Pour
rechercher des balises [SR] et rediriger les résultats de la recherche vers un fichier texte, suivez les étapes
suivantes :
1. Cliquez sur Démarrer, tapez cmd dans la zone Démarrer la recherche, cliquez avec le bouton droit sur
cmd dans la liste Programmes, puis cliquez sur Exécuter en tant qu’administrateur.
Si vous êtes invité à taper un mot de passe d’administrateur ou à confirmer, tapez le mot de passe ou
cliquez sur Continuer.
findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt
NOTE
Le Sfcdetails.txt inclut les entrées enregistrées chaque fois que le programme SFC.exe'exécute sur l’ordinateur.
3. Tapez exit, puis appuyez sur Entrée pour fermer la fenêtre d’invite de commandes.
Description du contrôle de fichier système (Sfc.exe)
Cet article décrit l’outil System File Checker (Sfc.exe), qui est un utilitaire de ligne de commande utilisé avec la
fonctionnalité WFP (Windows File Protection).
Résumé
Le contrôle de fichiers système permet à un administrateur d’analyser tous les fichiers protégés pour vérifier
leurs versions. Si le vérificationur de fichiers système découvre qu’un fichier protégé a été remplacé, il récupère
la version correcte du fichier à partir du dossier de cache ( ) ou des fichiers sources d’installation Windows, puis
remplace le fichier %Systemroot%\System32\Dllcache incorrect. L’équipe de vérification des fichiers système vérifie
et remplira à nouveau le dossier de cache. Vous devez être connecté en tant qu’administrateur ou membre du
groupe Administrateurs pour exécuter le vérification de fichier système. Si le dossier cache est endommagé ou
inutilisable, vous pouvez utiliser les commandes , la ou les commandes sfc /scannow sfc /scanonce pour
réparer son sfc /scanboot contenu.
Syntaxe de l’outil System File Checker

Sfc [/Scannow] [/Scanonce] [/Scanboot] [/Revert] [/Purgecache] [/Cachesize=x]
/Scannow : analyse immédiatement tous les fichiers système protégés et remplace les versions incorrectes
par les versions correctes de Microsoft. Cette commande peut nécessiter l’accès aux Windows sources
d’installation.
/Scanonce : analyse tous les fichiers système protégés une seule fois lorsque vous redémarrez votre
ordinateur. Cette commande peut nécessiter l’accès aux Windows sources d’installation lorsque vous
redémarrez l’ordinateur. La valeur DWORD SfcScan est définie sur 2 dans la clé de Registre suivante
lorsque vous exécutez cette commande :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
/Scanboot: analyse tous les fichiers système protégés chaque fois que vous démarrez votre ordinateur.
Cette commande peut nécessiter l’accès aux Windows sources d’installation chaque fois que vous
démarrez votre ordinateur. La valeur DWORD SfcScan est définie sur 1 dans la clé de Registre suivante
lorsque vous exécutez cette commande :
: renvoie l’analyse au paramètre par défaut (ne pas analyser les fichiers protégés lorsque vous
/Revert
démarrez l’ordinateur). La taille de cache par défaut n’est pas réinitialisée lorsque vous exécutez cette
commande. Cette commande équivaut au /Enable commutateur dans Windows 2000.
: purge le cache de fichiers et analyse immédiatement tous les fichiers système protégés.
/Purgecache
Cette commande peut nécessiter l’accès aux Windows sources d’installation.
/Cachesize=x : définit la taille du cache de fichiers sur x mégaoctets (Mo). La taille par défaut du cache est
de 50 Mo. Cette commande nécessite de redémarrer l’ordinateur, puis d’exécuter la commande pour
ajuster la taille du /purgecache cache sur disque. Cette commande définit la valeur DWORD SfcQuota
sur x dans la clé de Registre suivante :
Pour plus d’informations sur la fonctionnalité Windows protection des fichiers, voir Description de la
fonctionnalité Windows protection des fichiers.
Description du package Windows Server Update
Services 3.0 Service Pack 1
Cet article fournit des informations sur Windows Server Update Services package 3.0 Service Pack 1.
Introduction
Microsoft a publié un Service Pack pour Microsoft Windows Server Update Services 3.0 (WSUS). Cet article
contient des informations sur l’obtention du Service Pack et sur la façon d’obtenir la liste des problèmes corrigés
par le Service Pack. En outre, cet article inclut des informations sur les problèmes que vous pouvez être face à
l’installation du Service Pack et des informations sur la façon de déterminer si le Service Pack est installé.
Comment obtenir et installer WSUS 3.0 Service Pack 1 (SP1)
Le fichier suivant est disponible en téléchargement à partir du Centre de téléchargement Microsoft :
Téléchargez maintenant le package WSUS 3.0 Service Pack 1.
119591 comment obtenir des fichiers de support Microsoft à partir des services en ligne Microsoft a analysé ce
fichier pour y trouver des virus. Microsoft a utilisé le logiciel de détection de virus le plus actuel disponible à la
date de la date de la mise en ligne du fichier. Le fichier est stocké sur des serveurs à sécurité améliorée qui
permettent d’empêcher toute modification non autorisée du fichier.
Informations de suppression
Vous ne pouvez pas utiliser Ajout ou Suppression de programmes dans le Panneau de contrôle pour supprimer
uniquement WSUS 3.0 Service Pack 1, car il supprimera également tous les WSUS 3.0.
Problèmes corrigés par le Service Pack
L’approbation en bloc des mises à jour ne se fait pas maintenant sur les approbations existantes. Au lieu
de cela, l’approbation en bloc est désormais mise à jour vers un nouveau groupe cible. L’approbation en
bloc n’a pas pour but de réécrire les approbations existantes des anciens groupes cibles. Par défaut,
l’approbation en bloc s’ajoute à l’ensemble d’approbations existant pour une mise à jour qui n’est pas
approuvée.
Les approbations facultatives sont envisagées lors du calcul d’une approbation effective pour les groupes
cibles qui se chevauchent. Une approbation requise remplacera une approbation facultative dans le
scénario suivant :
Un ordinateur est membre de plusieurs groupes cibles.
Une mise à jour est approuvée pour approbation facultative pour l’un des groupes cibles.
La même mise à jour est approuvée pour approbation requise pour au moins l’un des autres groupes
cibles qui se trouve à la même profondeur ou plus approfondie dans l’arborescence de groupes cibles.
NOTE
Nous vous recommandons d’utiliser les API WSUS pour approuver « facultativement » les mises à jour pour WSUS
3.0 SP1 et pour approuver les mises à jour qui ne sont pas des mises à jour critiques ou des mises à jour de
sécurité.
Par exemple, supposons que vous avez une approbation requise sur la mise à jour X pour le groupe A et
une approbation facultative pour le groupe B. Si un ordinateur appartient au groupe A et au groupe B, la
mise à jour est répertoriée comme facultative sur l’ordinateur client. Étant donné que les groupes cibles
sont au même niveau, l’approbation requise doit toujours « gagner ».
Le rapport d’état détaillé de l’ordinateur Excel fonctionne.
L’Assistant Configuration conserve un mot de passe de serveur proxy si un mot de passe est définie avant
la mise à niveau.
La prise en charge est fournie pour un serveur proxy et un port distincts pour le trafic SSL.
Permet d’améliorer les performances en 2013, en 2013, en 2013, en 2013.
Certaines mises à jour du client sont basées sur Windows rapport d’erreurs (Watson).
L’Assistant Ajouter une imprimante fonctionne désormais lorsque vous recevez un grand nombre de
pilotes de Windows Update.
Comment déterminer si le Service Pack est installé
Recherchez « Windows Server Update Services 3.0 SP1 » dans Ajouter ou supprimer des programmes dans le
Panneau de contrôle ou Program Files and Features dans le Panneau de contrôle. Si « Windows Server Update
Services 3.0 SP1 » n’apparaît pas, le Service Pack n’est pas installé.
Améliorations de WSUS 3.0 SP1
WSUS 3.0 SP1 inclut les améliorations suivantes :
Prise en charge supplémentaire de Windows Server 2008.
Ajout d’une nouvelle API de maintenance du client :
Prise en charge de l’inscription du client
Filtre des mises à jour par catégorie et classification
Mécanisme d’extension de règle d’applicabilité
Métadonnées de package et état de mise à jour des rapports pour chaque client
Améliorations ajoutées pour la publication locale. Prend en charge la publication des pilotes au sein de
l’entreprise à l’aide de catalogues fournis par le fournisseur. L’API inclut la prise en charge des offres
groupées et des conditions préalables.
Inclut tous les correctifs qui ont été émis depuis la publication de WSUS 3.0.
Améliorations des performances. Il s’agit notamment de la compression de données en ligne entre le
serveur WSUS et la console d’administration distante.
NOTE
Dans Windows Server 2008, vous devez activer la compression dynamique pour Internet Information Services (IIS).
Package de mise à jour WSUS 3.0 SP1

WSUS 3.0 SP1 est disponible sur Windows Update. Le comportement du package est le suivant :
Une mise à niveau a lieu pour toutes les versions antérieures de WSUS à partir de WSUS 2.0 jusqu’à la
version d’origine de WSUS 3.0. La version d’origine de WSUS 3.0 s’exécute sur des ordinateurs exécutant
Windows Server 2003 SP1 ou versions ultérieures.
Toutes les mises à niveau nécessitent une interaction de l’utilisateur.
Ce package de Service Pack a la place des mises à jour précédentes pour WSUS 3.0.
Les mises à niveau de toutes les installations WSUS qui utilisent des installations SQL Server distantes sont
bloquées. Il s’agit désormais d’un processus de mise à niveau manuelle.
Les mises à niveau des versions antérieures de WSUS qui s’exécutent sur Windows Server 2008 ne sont pas
pris en charge.
La version d’System Center Essentials 1.0 n’est pas mise à niveau vers WSUS 3.0 SP1. Cette situation sera
gérée par une prochaine version de System Center Essentials.>
NOTE
Les packages « WSUS 2.0 SP1 » et « WSUS 2.0 Client SelfUpdate Update for WSUS 2.0 SP1 » vont expirer. Ces mises à
jour sont toujours disponibles sur le site Web Microsoft suivant : https://www.microsoft.com/download/Search.aspx
Problèmes connus avec WSUS 3.0 SP1

Vous recevez un message d’erreur lors de l’installation : « Échec de la propriété SMTP_USERPASSWD à partir
de la valeur de Registre SmtpUserPassword (Erreur 0x800700EA : plus de données sont disponibles.) »
Symptômes
Pendant l’installation de ce package, vous pouvez recevoir un message d’erreur semblable à ce qui suit dans le
fichier %temp%\Wsussetup.log :
Error MWUSSetup CUpgradeDriver::P erformPresetupActions: Failed to set SMTP_USERPASSWD property

from SmtpUserPassword registry value (Error 0x800700EA: More data is available.)
Cause
Ce problème se produit en raison de l’échec d’un mot de passe SMTP (Simple Mail Transfer Protocol) supérieur
à 11 caractères. Cela entraîne l’échec de lagrade WSUS 3.0 SP1upgrade. WSUS ne copie pas sa copie locale du
mot de passe.
Pour contourner ce problème, modifiez temporairement le mot de passe enregistré localement, exécutez la mise
à niveau WSUS 3.0 SP1, puis revenir au mot de passe d’origine utilisé par le compte SMTP. Pour cela, procédez
comme suit :
1. Cliquez sur Démarrer, sur Outils d’administration, puis sur Microsoft Windows Update Ser ver
Ser vices 3.0 .
2. Cliquez pour sélectionner Options, puis cliquez sur Notification par courrier électronique.
3. Sous l’onglet Ser veur de messagerie, entrez un mot de passe de moins de 12 caractères.
4. Cliquez sur OK pour enregistrer le mot de passe.
NOTE
N’utilisez pas Test, car ce mot de passe ne serait pas valide pour le compte SMTP. 5. Quittez l’outil d’administration WSUS.
6. Exécutez la mise à niveau WSUS 3.0 SP1. 7. Après avoir correctement mis à niveau vers WSUS 3.0 SP1, revenir au mot
de passe d’origine.
DISM échoue avec 0x800f0906 ou s’exécute en
continu lorsque vous convertissez Windows Server
2012 R2 Core en Serveur avec une interface
graphique graphique
Cet article traite d’un problème dans lequel la conversion de Windows Server Core en interface graphique
graphique à l’aide d’une commande DISM ou PowerShell échoue avec 0x800f0906.
Symptômes
This issue occurs when you run a DISM command, an equivalent Windows PowerShell command, or another
similar method to convert to GUI.
La commande DISM utilisée pour la conversion contient les commutateurs suivants :
/enable-feature /featurename:ServerCore-FullServer /featurename:Server-Gui-Mgmt /featurename:Server-Gui-Shell
Vous recevez l’un des clusters d’informations suivants dans l’invite de commandes :
Informations d’échec avec code d'0x800f0906 :
Dism.exe /online /enable-feature /featurename:ServerCore-FullServer /featurename:Server-Gui-Mgmt

/featurename:Server-Gui-Shell /source:wim:d:\sources\install.wim:4
Outil gestion et maintenance des images de déploiement

Version : 6.3.9600.17031
Version de l’image : 6.3.9600.17031
Activation des fonctionnalités
[===============================66.7%===== ]
Error: 0x800f0906
Les fichiers source ne peuvent pas être téléchargés.
Utilisez l’option « source » pour spécifier l’emplacement des fichiers requis pour restaurer la
fonctionnalité. Pour plus d’informations sur la spécification d’un emplacement source, consultez la
page http://go.microsoft.com/fwlink/?LinkId=243077 .
Vous trouverez le fichier journal DISM sous C:\Windows\Logs\DISM\dism.log.

Informations pour la commande DISM qui continue de s’exécuter pendant un certain temps sans s’arrêter
:
Dism.exe /online /enable-feature /featurename:ServerCore-FullServer /featurename:Server-Gui-Mgmt

/featurename:Server-Gui-Shell /source:wim:d:\sources\install.wim:4
Outil gestion et maintenance des images de déploiement

Version : 6.3.9600.17031
Version de l’image : 6.3.9600.17031
Activation des fonctionnalités
[===============================66.7%===== ]
NOTE
La barre de progression de l’invite de commandes reste toujours à 66,7 %. La taille du fichier CBS.log qui se trouve sous le
chemin %windir%\logs\cbs continuera d’augmenter.
Erreurs dans les journaux CBS

Le fichier CBS.log affiche l’une des deux erreurs suivantes :
Erreur 1
<DateTime>, Session Info CBS : 30409734_2213032090 initialisé par le client WindowsUpdateAgent.

<DateTime>, Info CBS Opened cabinet package, package directory: \ \ ?
\C:\Windows\SoftwareDistribution\Download\ea6d57731136ce0c61adfa2056bd76ba , sandbox
location: \ \ ? \C:\Windows\SoftwareDistribution\Download\ea6d57731136ce0c61adfa2056bd76ba
cabinet , location: \ \ ?
\C:\Windows\SoftwareDistribution\Download\ea6d57731136ce0c61adfa2056bd76ba\windows8.1-
kb3000850-x64-express.cab, emplacement du manifeste \ \ : ?
\C:\Windows\SoftwareDistribution\Download\ea6d57731136ce0c61adfa2056bd76ba\update.downl
oad
...
...
...
<DateTime>, Info DPX Extraction of file: amd64_microsoft-windows-c.. t-resources-
mrmcore_31bf3856ad364e35_6.3.9600.17418_none_dc8ca600359fa9c4\mrmcorer.dll a échoué car
il n’est pas présent dans le conteneur.
<DateTime>, Session asynchrone Info CBS : 30409734_2213032090 finalisé. [HRESULT =
0x80070002 - ERROR_FILE_NOT_FOUND]
Erreur 2
<DateTime>, Info CBS In able to find package:

Package_for_KB2959977~31bf3856ad364e35~amd64~6.3.1.1 from the cached windows update
index. [HRESULT = 0x800f090d - CBS_E_MISSING_PACKAGE_MAPPING_INDEX]
<DateTime>, Info CBS N’a pas trouvé de package :
Package_for_KB2959977~31bf3856ad364e35~amd64~~6.3.1.1 à partir du mappage d’index
[HRESULT = 0x800f090d - CBS_E_MISSING_PACKAGE_MAPPING_INDEX]
NOTE
Les mises à jour qui s’affichent pendant l’erreur peuvent être différentes. La cause de ces erreurs est le composant CBS et
le fichier d’index, et non les mises à jour elles-mêmes. La sortie de l’exemple et la liste des mises à jour mentionnées dans
l’erreur sont basées sur le test interne d’une installation principale de Windows Server 2012 R2 par défaut mais mise à
jour sans fonctionnalités ou rôles supplémentaires activés.
Cause de l’erreur 1 dans les journaux CBS
Ce problème se produit lorsque la conversion nécessite le téléchargement de fichiers pour les mises à jour
regroupées dans le cadre d’un seul updateID.
Les tests locaux montrent que la présence des mises à jour suivantes sur le serveur principal entraîne l’échec de
la conversion avec les erreurs d’extraction DPX 0x80070002 suivantes :
3000850
3003057
3014442
2919355
2959977
NOTE
Pour voir les exemples de valeurs pour updateID, ouvrez le fichier wuindex.xml sous le chemin
%windir%\servicing\packages, puis recherchez la chaîne updateID.
Cause de l’erreur 2 dans les journaux CBS

La cause est que l’entrée est manquée sous <Map
Package="package_for_kb2959977~31bf3856ad364e35~amd64~~6.3.1.1"/> updateID 8452bac0-bf53-4fbd-
915d-499de08c338b, à l’intérieur du fichier %windir%\servicing\packages\wuindex.xml.
Erreur lors 0x800f0922'échec de l’installation de la
fonctionnalité MPIO
Cet article permet de résoudre les erreurs 0x800f0922 qui se produit en cas d’échec de l’installation de la
fonctionnalité d’E/S multipath (MPIO) de Microsoft.
Symptômes
Lorsque vous essayez d’installer la fonctionnalité MPIO à l’aide de l’interface utilisateur graphique (GUI) ou
Windows PowerShell, vous recevez le message d’erreur suivant :
La demande d’ajout ou de suppression de fonctionnalités sur le serveur spécifié a échoué.

Échec de l’installation d’un ou plusieurs rôles, services de rôle ou fonctionnalités. Erreur : 0x800f0922.
En outre, les informations qui ressemblent à ce qui suit sont consignées dans le journal de maintenance basée
sur les composants (CBS.log) :
<DateTime>, Info CSI 00000029 commencer à exécuter l’index de la phase d’installation avancée 32
(0x00000020) 11 (0x000000000000000b) (séquence 41)
Ancien composant : [l:0]" »
Nouveau composant : [ml:344,l{172}:342{171}]"Microsoft-Windows-MultipathDeviceSpecificModule,
Culture=neutral, Version=6.2.9200.16384,
PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=amd64, versionScope=NonSxS »
Mode d’installation : installer
ID du programme d’installation : {3d07d150-2f3d-4184-9793-d0fd59b0c885}
Nom du programme d’installation : [12]"Root Devices »
<DateTime>, Error CSI 00000001@<DateTime> (F) CMIADAPTER: Inner Error Message from AI HRESULT =
800f0207 [Error,Facility=(000f),Code=519 (0x0207)]
[66] « L’instance de l’appareil ne peut pas être créée, car elle existe déjà. »
]
[gle=0x80004005]
<DateTime>, Erreur CSI 00000002@<DateTime> (F) CMIADAPTER : IA a échoué. HRESULT = 800f0207
[Error,Facility=(000f),Code=519 (0x0207)]
Élément :
[308]"<rootDevices xmlns="urn:schemas-microsoft-com:asm.v3">
<rootDevice classGUID="{4D36E97D-E325-11CE-BFC1-08002BE10318}" deviceName="ROOT\MPIO\0001"
generateId="false">
<properties>
<property name="HardwareIds" value=""ROOT\MSDSM"" />
</properties>
</rootDevice>« [gle=0x80004005]
<DateTime>, Error CSI 00000003@<DateTime> (F) CMIADAPTER: Exiting with HRESULT code = 800f0207
[Error,Facility=(000f),Code=519 (0x0207)].
[gle=0x80004005]
<DateTime>, Info CSI 0000002a Performing 1 operations; 1 ne sont pas verrouillés/déverrouillés et suivent :
(0) LockComponentPath (10) : indicateurs : 0 comp : {l:16 b:0079df39e6ddcf0130000001413a815} pathid:
{l:16 b:0079df39e6ddcf01310000001413a815} :
[l:234{117}] » \SystemRoot\WinSxS\x86_microsoft.windows.s.
ation.badcomponents_31bf3856ad364e35_6.2.9200.16384_none_353ccb4c94858655 » pid: 1314 starttime:
130566894897453336 (0x01cfdde62dc9d918)
<DateTime>, Erreur [0x018005] CSI 0000002b (F) Échec de l’exécution du programme d’installation
d’élément de file d’attente : Périphériques racine ({3d07d150-2f3d-4184-9793-d0fd59b0c885}) avec
HRESULT 800f0207 [Error,Facility=(000f),Code=519 (0x0207)]. L’échec ne sera pas ignoré : une fois toutes
les opérations dans la file d’attente du programme d’installation terminées, une fois toutes les opérations
effectuées dans la file d’attente du programme d’installation sont lancées. le programme d’installation [est
fiable 2](gle=0x80004005)
<DateTime>, Info CBS a ajouté C:\Windows\Logs\CBS\CBS.log au rapport d’wer.
<DateTime>, Info CBS a ajouté C:\Windows\Logs\CBS\CbsPersist_ <DateTime>.log to WER report.
<DateTime>, Info CBS Not able to add pending.xml.bad to Windows Error Report. [HRESULT = 0x80070002
- ERROR_FILE_NOT_FOUND]
<DateTime>, Info CBS Not able to add SCM. EvM to Windows Error Report. [HRESULT = 0x80070002 -
ERROR_FILE_NOT_FOUND]
<DateTime>, Info CSI 0000002c Creating NT transaction (seq 3), objectname [6]"(null) »
<DateTime>, Info CSI 0000002d Created NT transaction (seq 3) result 0x00000000, handle @0x330
<DateTime>, Info CSI 0000002e@<DateTime> début de validation de transaction NT...
<DateTime>, Info CSI 0000002f@<DateTime> suivi perf CSI :
CSIPERF:TXCOMMIT; 15663 <DateTime>, Info CSI 00000030@<DateTime> CSI Advanced installer perf
trace:
CSIPERF:AIDONE; {3d07d150-2f3d-4184-9793-d0fd59b0c885}; Microsoft-Windows-
MultipathDeviceSpecificModule, Version = 6.2.9200.16384, pA = PROCESSOR_ARCHITECTURE_AMD64 (9),
Culture neutre, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutre,
TypeName neutre, PublicKey neutre;199927us
<DateTime>, Info CSI 00000031 fin de l’exécution du programme d’installation avancé (séquence 41) État
d’achèvement : HRESULT_FROM_WIN32(ERROR_ADVANCED_INSTALLER_FAILED)
En outre, les informations suivantes sont consignées dans le journal de texte d’installation de l’appareil
(SetupAPI.dev.log) :
>>> [Setup Root Device - Install]

>>> section <DateTime>
set: {Install Root Device: ROOT\MPIO\0001} <DateTime>
!!! set: Could not create a device information element for device ROOT\MPIO\0001. HRESULT = 0x800f0207
set: {Install Root Device - exit(0x800f0207)} <DateTime>
<<< Section end <DateTime>
<<< [État de sortie : FAILURE(0x00000207)]
Cause
Ce problème se produit en raison de certaines entrées obsolètes dans la clé de Registre pour la fonctionnalité
MPIO.
Résolution
Pour résoudre ce problème, supprimez la clé suivante du Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\MPIO\0001
État
Explication des codes d’erreur

C O DE D'ERREUR SY M B O L E F IC H IER DESC RIP T IO N
0x800f0922 CBS_E_INSTALLERS_FAILED cbsapi.h Échec du traitement des

installers avancés et des
commandes génériques.
0x800f0207 SPAPI_E_DEVINST_ALREADY winerror.h L’instance d’appareil ne peut

_EXISTS pas être créée, car elle existe
déjà.
0x80070002 ERROR_FILE_NOT_FOUND winerror.h Le fichier spécifié est

introuvable.
0x00000207 SE_AUDITID_LPC_INVALID_ msaudite.h Utilisation non valide du

USE port LPC.
Erreur lors 0x800f0922 lors de la tentative de
désinstallation Windows rôles ou fonctionnalités
serveur
Cet article vous aide à résoudre les erreurs 0x800f0922 qui se produit lorsque vous désinstallez les rôles ou
fonctionnalités de Microsoft Windows Server.
Symptômes
Lorsque vous essayez de désinstaller un rôle ou une fonctionnalité Windows Server à l’aide du Gestionnaire de
serveur ou de l’cmdlet PowerShell, la tentative échoue et vous recevez des 0x800f0922 de code d’erreur et le
message d’erreur suivant Uninstall-WindowsFeature :
CBS_E_INSTALLERS_FAILED
Échec du traitement des installers avancés et des commandes génériques
Par exemple, lors de la désinstallation Windows Deployment Services (WDS), les erreurs suivantes ont été
consignées dans cbs.log sous C:\Windows\Logs\CBS :
SQM : signaler les changements de mise à jour sélectionnables pour le package : Microsoft-Windows-
Deployment-Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, update: Microsoft-
Windows-Deployment-Services, start: Installed, applicable: Resolved, target: Resolved, client id: DISM
Gestionnaire de package Provider, initiated offline: False, execution sequence: 1433, first merged séquence :
1433, source de téléchargement : 0, temps de téléchargement (secs) : 4294967295, état de téléchargement :
0x0 (S_OK), redémarrage requis : False, résultat global :0x800f0922 (CBS_E_INSTALLERS_FAILED)
SQM : Télécharger requis pour le rapport : UpdateChange_Microsoft-Windows-Deployment-
Services_Microsoft-Windows-Deployment-Services-Package~31bf3856ad364e35~amd64 ~~
6.3.9600.16384, id de session : 142860, type d’exemple : Standard
SQM : ignorer la demande de chargement car l’exemple de type n’est pas activé : Standard
TI : CBS a interrogé l’état requis du redémarrage actuel : 0
Windows-Deployment-Services-Deployment-Server, start: Staged, applicable: Resolved, target: Resolved,
client id: DISM Gestionnaire de package Provider, initiated offline: False, execution sequence: 1433, première
séquence fusionnée : 1433, source de téléchargement : 0, temps de téléchargement (secs) : 4294967295,
état de téléchargement : 0x0 (S_OK), redémarrage requis : False, résultat global : 0x800f0922
(CBS_E_INSTALLERS_FAILED)
SQM : Télécharger requis pour le rapport : UpdateChange_Microsoft-Windows-Deployment-Services-
Deployment-Server_Microsoft-Windows-Deployment-Services-Package~31bf3856ad364e35~amd64 ~~
Windows-Deployment-Services-Transport-Server, start: Installed, applicable: Resolved, target: Resolved,
client id: DISM Gestionnaire de package Provider, initiated offline: False, execution sequence: 1433, première
état de téléchargement : 0x0 (S_OK), redémarrage requis : False, résultat global :0x800f0922
Transport-Server_Microsoft-Windows-Deployment-Services-Package~31bf3856ad364e35~amd64 ~~
SQM : Modification du package de rapports pour le package : Microsoft-Windows-Deployment-Services-
Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, current: Installed, pending: Default, start:
Installed, applicable: Installed, target: Installed, limit: Installed, hotpatch status:
DisabledBecauseNoHotpatchPackagesInitiated, status: 0x0, failure source: Execute, reboot required: False,
client id: DISM Gestionnaire de package Provider, initiated offline: False, execution sequence: 1433, first
merged sequence: 1433 reboot reason: REBOOT_NOT_REQUIRED RM App session: -1 RM App name: N/A
FileName in use: N/A
SQM : Télécharger pour le rapport : PackageChangeBegin_Microsoft-Windows-Deployment-Services-
Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, id de session : 142859, type d’exemple :
Standard
SQM : Achèvement des changements de package de rapports pour le package : Microsoft-Windows-
Deployment-Services-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, current: Installed, original:
Installed, target: Installed, status: 0x800f0922, failure source: Execute, failure details: « (null) », client id: DISM
Gestionnaire de package Provider, initiated offline: False, execution sequence: 1433, first merged sequence:
1433, décision en attente : InteractiveInstallFailed, contexte d’exécution primitive : Interactif
SQM : le point de données de performances de l’exécution n’est pas valide. [HRESULT = 0x80070490 -
ERROR_NOT_FOUND]
SQM : Échec de l’initialisation de l’évaluation Win SAT. [HRESULT = 0x80040154 - Erreur inconnue]
SQM : le point de données de débit disque moyen n’est pas valide [HRESULT = 0x80040154 - Erreur
inconnue]
SQM : Télécharger requis pour le rapport : PackageChangeEnd_Microsoft-Windows-Deployment-Services-
Standard
Deployment-Services-UI-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, update: Microsoft-
Windows-Deployment-Services-Admin-Pack, start: Staged, applicable: Resolved, target: Resolved, client id:
DISM Gestionnaire de package Provider, initiated offline: False, execution sequence: 1433, première
état de téléchargement : 0x0 (S_OK), redémarrage requis : False, résultat global :0x800f0922
Admin-Pack_Microsoft-Windows-Deployment-Services-UI-Package~31bf3856ad364e35~amd64 ~~
SQM : Modification du package de rapports pour le package : Microsoft-Windows-Deployment-Services-UI-
Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, current: Installed, pending: Default, start:
Installed, applicable: Installed, target: Installed, limit: Installed, hotpatch status:
DisabledBecauseNoHotpatchPackagesInitiated, status: 0x0, failure source: Execute, reboot required: False,
client id: DISM Gestionnaire de package Provider, initiated offline: False, execution sequence: 1433, first
merged sequence: 1433 reboot reason: REBOOT_NOT_REQUIRED RM App session: -1 RM App name: N/A
FileName in use: N/A
SQM : Télécharger pour le rapport : PackageChangeBegin_Microsoft-Windows-Deployment-Services-UI-
Standard
SQM : ignorer la demande de chargement car l’exemple de type n’est pas activé : Standard SQM : fin de
modification du package de rapports pour le package : Microsoft-Windows-Deployment-Services-UI-
Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, current: Installed, original: Installed, target:
Installed, status: 0x800f0922, failure source: Execute, failure details: « (null) », client id: DISM Gestionnaire de
package Fournisseur, initié hors connexion : False, séquence d’exécution : 1433, première séquence fusionnée
: 1433, décision en attente : InteractiveInstallFailed, contexte d’exécution primitive : Interactive
SQM : le point de données de performances de l’exécution n’est pas valide. [HRESULT = 0x80070490 -
ERROR_NOT_FOUND]
SQM : Échec de l’initialisation de l’évaluation Win SAT. [HRESULT = 0x80040154 - Erreur inconnue]
SQM : le point de données de débit disque moyen n’est pas valide [HRESULT = 0x80040154 - Erreur
inconnue]
SQM : Télécharger requis pour le rapport : PackageChangeEnd_Microsoft-Windows-Deployment-Services-
UI-Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384, id de session : 142862, type d’exemple :
Standard
FinalCommitPackagesState : État persistant des packages terminé
Activation de l’option de démarrage LKG
Exec : traitement terminé. Session : 30651968_3203616141, Package : Microsoft-Windows-ServerCore-
Package~31bf3856ad364e35~amd64 ~~ 6.3.9600.16384 [HRESULT = 0x800f0922 -
CBS_E_INSTALLERS_FAILED]
Échec de l’opération. [HRESULT = 0x800f0922 - CBS_E_INSTALLERS_FAILED]
Session : 30651968_3203616141 finalisé. Redémarrage requis : non [HRESULT = 0x800f0922 -
CBS_E_INSTALLERS_FAILED]
Échec de finalisation de FinalizeEx à l’aide de la session de travail [HRESULT = 0x800f0922]
Cause
Ce problème peut se produire s’il existe plus de 65 000 fichiers dans Windows temp. Le Windows temp se
trouve à C:\Windows\Temp l’emplacement . Vérifiez Windows variables d’environnement pour confirmer
l’emplacement du Windows temp.
Résolution
Pour résoudre le problème, supprimez le contenu du dossier temp Windows (normalement), puis réessayez de
supprimer le rôle ou la fonctionnalité C:\Windows\Temp Windows Server.
Erreur C0190003 après l’installation des mises à jour
Cet article fournit une solution de contournement pour un problème qui déclenche une erreur lorsque vous
redémarrez un ordinateur Windows Server 2012 R2 après avoir installé les mises à jour.
Symptômes
Vous essayez d’installer de nombreuses mises à jour à partir Windows Update. Cela inclut les mises à jour
3000850.
Vous utilisez un disque secteur natif de 4K comme lecteur système.
Toutefois, une fois le processus d’installation de la mise à jour terminé et l’ordinateur redémarré, vous pouvez
recevoir l’un des messages d’erreur suivants :
Erreur C0190003 appliquant l’opération de mise à jour 21417 247778 (wow64_microsoft-window
Fatal error C0190003 applying update operation 19505 of 247778 (amd64_microsoft
NOTE
Le nombre d’opérations et de noms de fichiers peut varier.
Dans ce cas, l’ordinateur ne redémarre pas correctement.
Cause
Pendant le processus d’installation, toutes les opérations de fichier (copie, déplacement et suppression, par
exemple) doivent être transactionnelles. Toutefois, s’il y a beaucoup de fichiers à traiter, le journal des
transactions peut devenir plein. Dans ce cas, les transactions sont de retour et le message d’erreur s’affiche.
Si vous n’avez pas encore installé les mises à jour, vous pouvez contourner ce problème en augmentant la taille
du journal des transactions. Pour ce faire, ouvrez cmd.exe en tant qu’administrateur, puis exécutez la commande
suivante :
fsutil resource setlog maxextents 100 C:\

NOTE
Cette commande augmente le nombre maximal de conteneurs pour le lecteur de démarrage (lecteur C) à 100. (La valeur
par défaut est 20.) Si vous définissez la valeur sur 100 et que vous faites toujours l’expérience de la même erreur, vous
pouvez essayer un nombre supérieur.
Si vous avez déjà connu le problème décrit dans la section Symptômes, vous pouvez le récupérer en suivant les
étapes suivantes :
1. Lorsque le message d’erreur s’affiche, appuyez sur le bouton d’alimentation pour désactiver l’ordinateur.
2. Appuyez sur le bouton d’alimentation, puis appuyez immédiatement sur la touche F8. Le menu Options
de démarrage avancées s’affiche.
3. Sélectionnez Réparer votre ordinateur, puis appuyez sur Entrée.
4. Dans le menu Choisir une option, sélectionnez Résoudre les problèmes.
5. Dans le menu Options avancées, sélectionnez Invite de commandes.
6. Sélectionnez le compte d’administrateur, puis entrez le mot de passe.
7. À l’invite de commandes (cmd.exe), exécutez la commande suivante :
Dism /image:C:\ /cleanup-image /revertpendingactions
8. Fermez l'invite de commandes.

9. Dans le menu Choisir une option, sélectionnez Continuer.
État
Microsoft a confirmé qu’il s’agit d’un problème dans Windows Server 2012 R2.
Références
Stratégie de support Microsoft pour les disques durs de secteur 4K Windows
Erreur 0x80004005 lorsque vous essayez d’installer
ou de démarrer le service de rôle serveur de
stratégie de réseau
Cet article fournit une solution pour corriger les erreurs 0x80004005 qui se produit lorsque vous installez ou
démarrez le service de rôle serveur de stratégie de réseau.
Symptômes
Lorsque vous essayez d’installer ou de démarrer le service de rôle serveur de stratégie de réseau sur un
ordinateur exécutant Windows Server 2008 R2, le rôle n’est pas installé ou le service n’est pas démarré. En
outre, vous recevez un message d’erreur semblable au suivant : Windows n’a pas pu démarrer le service serveur
de stratégie réseau sur l’ordinateur local. Erreur 0x80004005'erreur non spécifiée
Résolution
IMPORTANT
Pour résoudre ce problème, définissez la sous-clé NT AUTHORITY\NETWORK SERVICE dans le Registre sur
1. Pour cela, procédez comme suit :
1. Démarrez l’Éditeur du Registre. Pour ce faire, cliquez sur Démarrer, tapez regedit dans la zone Démarrer
la recherche, puis appuyez sur Entrée.
Si vous êtes invité à fournir un mot de passe d’administrateur ou une confirmation, tapez-le ou fournissez
une confirmation.
2. Recherchez, puis cliquez pour sélectionner la clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\VssAccessControl
3. Cliquez avec le bouton droit sur AUTORITÉ NT\SERVICE RÉSEAU, puis cliquez sur Modifier.
4. Dans la zone Données de la valeur , tapez 1, puis cliquez sur OK .
5. Dans le menu Fichier, cliquez sur Quitter pour quitter l’Éditeur du Registre.
6. Arrêtez toutes les instances du processus Lashost.exe de traitement.
7. Redémarrez le service serveur de stratégie de réseau.
Échec de la planification du service de protection
logicielle pour l’erreur de redémarrage dans
Windows Server 2012
Cet article fournit une solution à une erreur qui se produit lorsque le compte de service réseau ne dispose pas
des autorisations pour le SoftwareProtectionPlatform dossier.
S’applique à : Windows Server 2008 R2 Service Pack 1, Windows Server 2012 R2
Symptômes
Vous pouvez fréquemment recevoir l’événement suivant dans le journal des applications pour le service de
protection logicielle :
Cause
Le problème peut se produire si une ou plusieurs des conditions suivantes sont vraies :
Le service De planification des tâches est désactivé.
Le service de plateforme de protection logicielle n’est pas en cours d’exécution sous le compte SERVICE
RÉSEAU.
Les autorisations de lecture pour le compte SERVICE RÉSEAU sont manquantes dans le dossier suivant :
C:\Windows\System32\Tasks\Microsoft\Windows\SoftwareProtectionPlatform
Résolution
1. Vérifiez que le service De planification des tâches est en cours d’exécution.
2. Ouvrez l’outil Gestion de l’ordinateur, puis accédez à la bibliothèque de planification des tâches du
Programmeur de tâches de configuration -> -> -> Microsoft -> Windows ->
SoftwareProtectionPlatform .
3. Sous l’onglet Général de SoftwareProtectionPlatform, sélectionnez les options de sécurité, puis vérifiez
que le service de plateforme de protection logicielle est prêt à utiliser le compte SERVICE RÉSEAU.
4. Dans Windows Explorer, accédez au dossier, puis vérifiez que le compte SERVICE RÉSEAU dispose des
autorisations de C:\Windows\System32\Tasks\Microsoft\Windows\SoftwareProtectionPlatform lecture pour ce
dossier.
5. Redémarrez le service de protection logicielle s’il est en cours d’exécution.
Correction des erreurs de mise à jour de Windows à
l'aide de DISM ou de l'outil d'analyse de
l'installation conforme des mises à jour du système
Produits concernés : Windows 10, version 1809 et versions ultérieures, Windows 8.1,
Windows Server 2012 R2, Windows 7, Windows Server 2008 R2
Symptôme
L’installation des mises à jour et des Service Packs Windows peut échouer en cas d’erreurs d’endommagement.
Par exemple, un fichier système endommagé peut empêcher l'installation d'une mise à jour. L'outil DISM ou
l'outil d'analyse de l'installation conforme des mises à jour du système peut vous aider à corriger certaines
erreurs d'endommagement de Windows.
Cet article s'adresse aux agents de support et aux informaticiens. Si vous êtes des utilisateurs à domicile et que
vous recherchez plus d’informations sur la correction des erreurs de mise à jour de Windows, consultez l’article
Correction d’erreurs de Windows Update.
Résolution pour Windows 8.1, Windows 10 et

Pour résoudre ce problème, utilisez l'outil de gestion et de maintenance des images de déploiement (DISM).
Réinstallez ensuite la mise à jour ou le Service Pack de Windows.
1. Ouvrez une invite de commandes avec élévation de privilèges. Pour ce faire, ouvrez le menu Démarrer
ou l’écran de démarrage , tapez Invite de commandes, faites un clic droit sur l’invite de commandes ,
puis sélectionnez Exécuter en tant qu’administrateur . Si vous êtes invité à entrer un mot de passe
administrateur ou à confirmer l’opération, entrez votre mot de passe ou sélectionnez Autoriser .
2. Taper la commande suivante, puis appuyer sur Entrée : L'opération de commande peut prendre plusieurs
minutes.
DISM.exe /Online /Cleanup-image /Restorehealth
IMPORTANT
lorsque vous exécutez cette commande, DISM utilise Windows Update pour fournir les fichiers nécessaires à la
résolution des problèmes d'endommagement. Toutefois, si votre client Windows Update est déjà endommagé,
utilisez une installation de Windows en cours d'exécution comme source de réparation ou utilisez un dossier
Windows côte à côte depuis un partage réseau ou un support amovible, tel que le DVD de Windows, comme
source des fichiers. Pour ce faire, exécutez plutôt la commande suivante :
DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess

NOTE
remplacez l'espace réservé C:\Source_réparation\Windows par l'emplacement de votre source de réparation. Pour
plus d'informations sur l'utilisation de l'outil DISM pour réparer Windows, consultez l'article Réparer une image
système Windows.
3. Tapez la commande sfc /scannow , puis appuyez sur Entrée. L'opération de commande peut prendre
plusieurs minutes.
4. Fermez l'invite de commandes, puis exécutez à nouveau Windows Update .
DISM crée un fichier journal (%windir%/Logs/CBS/CBS.log) qui consigne tous les problèmes que l'outil a
détectés ou résolus. %windir% est le dossier dans lequel Windows est installé. Par exemple, le dossier %windir%
est C:\Windows.
Résolution pour Windows 7 et Windows Server 2008 R2

Pour résoudre ce problème, utilisez l'outil d'analyse de l'installation conforme des mises à jour du système.
Réinstallez ensuite la mise à jour ou le Service Pack de Windows.
1. Téléchargez l'outil d'analyse de l'installation conforme des mises à jour du système.
Accédez au Microsoft Update Catalog et téléchargez l’outil qui correspond à la version de Windows qui
s’exécute sur votre ordinateur. Pour plus d’informations sur la manière de trouver la version de Windows
que vous avez installée, consultez l’article Identifiez la version (32 ou 64 bits) de Windows de votre
ordinateur.
NOTE
Cet outil est régulièrement mis à jour et nous vous recommandons de toujours télécharger la dernière version.
Cet outil n’est pas disponible dans toutes les langues prises en charge. Consultez le lien ci-dessous pour savoir si
votre langue est disponible.
2. Installez et exécutez l'outil.

a. Sélectionnez Télécharger sur la page web du Centre de téléchargement, puis effectuez l’une des
opérations suivantes :
Pour installer l’outil immédiatement, sélectionnez Ouvrir ou Exécuter , puis suivez les
instructions qui s’affichent à l’écran.
Pour installer l’outil ultérieurement, sélectionnez Enregistrer et téléchargez le fichier
d’installation sur votre ordinateur. Lorsque vous êtes prêt à installer l’outil, double-cliquez sur le
fichier.
b. Dans la boîte de dialogue du programme d’installation autonome Windows Update, sélectionnez
Oui .
3. Lorsque l'outil est installé, il s'exécute automatiquement. L'opération dure généralement moins de
15 minutes, mais peut être plus longue sur certains ordinateurs. Ne sélectionnez pas Annuler même si la
barre de progression semble s’arrêter, car l’analyse est toujours en cours d’exécution.
4. Lorsque le message Installation terminée s’affiche, sélectionnez Fermer .
5. Réinstallez la mise à jour ou le Service Pack que vous tentiez d'installer préalablement.
Pour corriger manuellement les erreurs d’endommagement que l’outil détecte mais ne peut pas résoudre,
consultez la section Procédure de correction des erreurs détectées dans le fichier journal de CheckSUR.
Résolution - Télécharger le package directement depuis le

Catalogue Microsoft Update
Vous pouvez également télécharger directement le package de mise à jour à partir du Catalogue Microsoft
Update, puis l'installer manuellement.
Par exemple, vous pouvez rencontrer des problèmes lors de l’installation des mises à jour partir de
Windows Update. Dans ce cas, vous pouvez télécharger le package de mise à jour et installer manuellement la
mise à jour. Pour cela, procédez comme suit :
1. Ouvrez la page Catalogue Microsoft Update pour KB3006137.
2. Recherchez la mise à jour qui s’applique à votre système d’exploitation dans les résultats de la recherche,
puis sélectionnez le bouton Télécharger .
3. Sélectionnez le lien du fichier pour télécharger la mise à jour.
4. Sélectionnez Fermer une fois le téléchargement terminé. Vous trouverez alors un dossier contenant le
package de mise à jour dans l'emplacement spécifié.
5. Ouvrez le dossier, puis double-cliquez sur le package de mise à jour pour installer la mise à jour.
Si la mise à jour ou le Service Pack de Windows a été installé correctement, vous avez terminé. Si le problème
n’est pas résolu ou si l’outil d’analyse de l’installation conforme des mises à jour du système ne trouve pas la
cause, contactez-vous pour obtenir plus d’aide.
Description des erreurs d'endommagement courantes

Le tableau suivant répertorie pour référence les codes d'erreur possibles liés à Windows Update :
C O DE ERREUR DESC RIP T IO N
0x80070002 ERROR_FILE_NOT_FOUND Le fichier spécifié est introuvable.
0x8007000D ERROR_INVALID_DATA Données non valides.
0x800F081F CBS_E_SOURCE_MISSING La source du package ou du fichier est

introuvable.
C O DE ERREUR DESC RIP T IO N
0x80073712 ERROR_SXS_COMPONENT_STORE_CO Le magasin de composants est dans

RRUPT un état incohérent.
0x800736CC ERROR_SXS_FILE_HASH_MISMATCH Un fichier du composant ne

correspond pas aux informations de
vérification présentes dans le manifeste
du composant.
0x800705B9 ERROR_XML_PARSE_ERROR Impossible d'analyser les données XML

demandées.
0x80070246 ERROR_ILLEGAL_CHARACTER Un caractère non valide a été détecté.
0x8007370D ERROR_SXS_IDENTITY_PARSE_ERROR Une chaîne d'identité est malformée.
0x8007370B ERROR_SXS_INVALID_IDENTITY_ATTRIB Le nom d'un attribut d'une identité

UTE_NAME n'est pas compris dans la plage
autorisée.
0x8007370A ERROR_SXS_INVALID_IDENTITY_ATTRIB La valeur d'un attribut d'une identité

UTE_VALUE n'est pas comprise dans la plage
autorisée.
0x80070057 ERROR_INVALID_PARAMETER Paramètre incorrect.
0x800B0100 TRUST_E_NOSIGNATURE Il n'y avait pas de signature dans le

sujet.
0x80092003 CRYPT_E_FILE_ERROR Une erreur s'est produite lors de la

lecture ou de l'écriture d'un fichier par
Windows Update.
0x800B0101 CERT_E_EXPIRED Un certificat requis n'est pas dans sa

période de validité selon la vérification
par rapport à l'horloge système en
cours ou le tampon daté dans le fichier
signé.
0x8007371B ERROR_SXS_TRANSACTION_CLOSURE_ Un ou plusieurs membres requis de la

INCOMPLETE transaction sont absents.
0x80070490 ERROR_NOT_FOUND Windows n'a pas pu rechercher les

nouvelles mises à jour.
0x800f0984 PSFX_E_MATCHING_BINARY_MISSING Le répertoire des composants

correspondant existe, mais le fichier
binaire est manquant
0x800f0986 PSFX_E_APPLY_FORWARD_DELTA_FAIL Échec de l’application du delta avant

ED
0x800f0982 PSFX_E_MATCHING_COMPONENT_NO Impossible d’identifier le composant

T_FOUND correspondant à l’hydratation
Que fait l’outil d’analyse de l’installation conforme des mises à jour du
système ?
Vérification de l'intégrité des ressources
L’outil d’analyse de l’installation conforme des mises à jour du système vérifie l’intégrité des ressources
suivantes :
Fichiers se trouvant dans les répertoires suivants :
%SYSTEMROOT%\Servicing\Packages
%SYSTEMROOT%\WinSxS\Manifests
Données du Registre situées sous les sous-clés de Registre suivantes :
HKEY_LOCAL_MACHINE\Components
HKEY_LOCAL_MACHINE\Schema
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Component Based Servicing
Cette liste peut être mise à jour à tout moment.
Lorsque l’outil d’analyse de l’installation conforme des mises à jour du système détecte des manifestes, des
fichiers CAB ou des données de Registre incorrects, il peut remplacer les données erronées par une version
corrigée.
Journalisation
L’outil d’analyse de l’installation conforme des mises à jour du système crée un fichier journal qui consigne tous
les problèmes qu’il a détectés ou résolus. Le fichier journal se trouve ici :
%SYSTEMROOT%\Logs\CBS\CheckSUR.log
%SYSTEMROOT%\Logs\CBS\CheckSUR.persist.log
Procédure de correction des erreurs détectées dans le fichier journal

de CheckSUR
Pour corriger manuellement les erreurs d’endommagement que l’outil d'analyse de l’installation conforme des
mises à jour du système détecte mais ne peut pas résoudre, procédez comme suit :
1. Ouvrez %SYSTEMROOT%\Logs\CBS\CheckSUR.log.
NOTE
%SYSTEMROOT% est une variable d’environnement qui enregistre le dossier dans lequel Windows est installé. Par
exemple, en général, le dossier %SYSTEMROOT% est C:\Windows.
2. Identifiez les packages que l'outil ne peut pas réparer. Par exemple, vous pouvez trouver les informations
suivantes dans le fichier journal :
Summary:
Seconds executed: 264

Found 3 errors
CBS MUM Missing Total Count: 3
Unavailable repair files:
servicing\packages\Package_for_KB958690_sc_0~31bf3856ad364e35~amd64~~6.0.1.6.mum
...
Dans ce cas, le package endommagé est KB958690.
3. Téléchargez le package à partir du Centre de téléchargement Microsoft ou du Catalogue Microsoft
Update.
4. Copiez le package (.msu) dans le répertoire %SYSTEMROOT%\CheckSUR\packages . Par défaut, ce répertoire
n'existe pas et vous devez le créer.
5. Réexécutez l’outil d’analyse de l’installation conforme des mises à jour du système.
Si vous êtes un technicien, consultez l’article Procédure de correction des erreurs détectées dans CheckSUR.log
pour plus d’options sur la correction des erreurs dans le fichier CheckSUR.log.
Comment bloquer l’accès des utilisateurs à
Windows mise à jour sur Windows Server
Cet article explique comment bloquer l’accès des utilisateurs à Windows update sur Windows Server.
Symptômes
Les paramètres par défaut dans Windows Server permettent aux utilisateurs qui ne sont pas administrateurs
d’analyser et d’appliquer Windows mises à jour. Les administrateurs peuvent modifier ce paramètre pour limiter
l’accès Windows mises à jour, en particulier dans les déploiements d’hôtes des services Bureau à distance.
Pour modifier ce paramètre, utilisez la stratégie de groupe « Supprimer l’accès pour utiliser toutes les
fonctionnalités Windows mise à jour ». Le chemin d’accès complet à cette stratégie de groupe est :
Modèles \ d’administration de configuration ordinateur Windows composants Windows mise à jour Supprimer
l’accès pour utiliser \ toutes les \ \ fonctionnalités Windows mise à jour
Utilisation de la console de récupération sur un
ordinateur qui ne démarre pas
Cet article explique comment utiliser la console de récupération sur un ordinateur qui ne démarre pas.
Résumé
Cet article pas à pas décrit comment utiliser la console de récupération pour récupérer un ordinateur Windows
Server 2003 qui ne démarre pas.
La console de récupération est un outil en ligne de commande que vous pouvez utiliser pour réparer Windows
si l’ordinateur ne démarre pas correctement. Vous pouvez démarrer la console de récupération à partir du CD-
WINDOWS Server 2003, ou au démarrage, si vous avez précédemment installé la console de récupération sur
l’ordinateur.
Utiliser la console de récupération sur un ordinateur qui ne démarre pas
NOTE
procédure. En outre, si votre ordinateur est connecté à un réseau, les paramètres de stratégie réseau peuvent vous
empêcher d’effectuer cette procédure.
Pour exécuter la console de récupération, suivez les étapes suivantes :

1. Configurez l’ordinateur pour qu’il démarre à partir du CD ou du lecteur de DVD. Pour plus d’informations,
consultez la documentation de l’ordinateur ou contactez le fabricant de l’ordinateur.
2. Insérez le CD Windows Server 2003 dans le CD ou le lecteur de DVD de l’ordinateur.
4. Lorsque vous recevez le message qui vous invite à appuyer sur n’importe quelle touche pour démarrer à
partir du CD-CD, appuyez sur une touche pour démarrer l’ordinateur à partir du CD-WINDOWS Server
2003.
5. Lorsque l’écran d’accueil du programme d’installation s’affiche, appuyez sur la touche R pour
démarrer la console de récupération.
6. Sélectionnez l Windows l’installation à partir de la console de récupération.
7. Suivez les instructions qui apparaissent à l’écran, tapez le mot de passe administrateur, puis appuyez sur
Entrée.
8. À l’invite de commandes, tapez les commandes de la console de récupération appropriées pour réparer
votre installation Windows Server 2003.
Pour obtenir la liste des commandes disponibles dans la console de récupération, tapez
aide à l’invite de commandes, puis appuyez sur Entrée.
NOTE
Vous pouvez également installer la console de récupération en tant qu’option de démarrage sur l’ordinateur afin
qu’elle soit toujours disponible. Pour plus d’informations sur la façon de le faire, voir la section Mesures de
précaution de cet article.
9. Pour quitter la console de récupération et redémarrer l’ordinateur, tapez

quittez l’invite de commandes, puis appuyez sur Entrée.
Commandes de la console de récupération
La liste suivante décrit les commandes disponibles pour la console de récupération :
Attrib modifie les attributs d’un fichier ou d’un dossier.
Batch exécute des commandes que vous spécifiez dans le fichier texte, InputFile. OutputFile contient la
sortie des commandes. Si vous omettez l’argument OutputFile, la sortie s’affiche à l’écran.
Bootcfg est utilisé pour la configuration et la récupération de démarrage. Vous pouvez utiliser la
commande bootcfg pour apporter des modifications au Boot.ini fichier.
Le CD (chdir) fonctionne uniquement dans les répertoires système de l’installation Windows actuelle,
dans un support amovible, dans le répertoire racine d’une partition de disque dur ou dans les sources
d’installation locales.
Chkdsk : le commutateur /p exécute Chkdsk même si le lecteur n’est pas marqué comme étant sale. Le
commutateur /r localise les secteurs non concernés et récupère les informations lisibles. Ce commutateur
implique /p. Chkdsk nécessite Autochk. Chkdsk recherche automatiquement les Autochk.exe dans le
dossier de démarrage ou dans le dossier de démarrage. Si Chkdsk ne trouve pas le fichier dans le dossier
de démarrage, il recherche le CD d’installation Windows Server 2003. Si Chkdsk ne trouve pas le CD
d’installation, il demande à l’utilisateur l’emplacement Autochk.exe.
Cls permet d’effacer l’écran.
Copie un fichier vers un emplacement cible. Par défaut, la cible ne peut pas être un média amovible et
vous ne pouvez pas utiliser de caractères génériques. La copie d’un fichier compressé à partir du CD-
WINDOWS d’installation server 2003 décompresse automatiquement le fichier.
Del (supprimer) supprime un fichier. Del fonctionne dans les répertoires système de l’installation
Windows actuelle, dans un support amovible, dans le répertoire racine d’une partition de disque dur ou
dans les sources d’installation locales. Par défaut, vous ne pouvez pas utiliser de caractères génériques.
Dir affiche la liste de tous les fichiers, y compris les fichiers masqués et système.
Désactive la désactivation d’Windows service système ou d’un Windows pilote. L’argument servicename
est le nom du service ou du pilote que vous souhaitez désactiver. Lorsque vous utilisez cette commande
pour désactiver un service, elle affiche le type de démarrage d’origine du service avant de modifier le
type en SERVICE_DISABLED. Il est bon de noter le type de démarrage d’origine afin de pouvoir utiliser la
commande Activer pour redémarrer le service.
Diskpart gère les partitions sur les volumes de disque dur.
L’option /add crée une partition.
L’option /delete supprime une partition existante.
L’argument nom de l’appareil est le nom de l’appareil d’une nouvelle partition. Un exemple de nom
d’appareil pour une nouvelle partition est \device\harddisk0.
L’argument nom du lecteur est la lettre de lecteur d’une partition que vous êtes en cours de
suppression, telle que D: .
Le nom de partition est le nom basé sur la partition d’une partition que vous êtes en cours de
suppression et peut être utilisé à la place de l’argument nom du lecteur. Un exemple de nom basé sur
une partition est \device\harddisk0\partition1.
L’argument taille est la taille en mégaoctets d’une nouvelle partition.
Enable active un service système Windows ou un pilote Windows client. L’argument servicename est le
nom du service ou du pilote que vous souhaitez activer, et start_type est le type de démarrage pour un
service activé. Le type de démarrage utilise l’un des formats suivants :
SERVICE_BOOT_START
SERVICE_SYSTEM_START
SERVICE_AUTO_START
SERVICE_DEMAND_START
Exit quitte la console de récupération, puis redémarre l’ordinateur.

Développe un fichier compressé. L’argument source est le fichier que vous souhaitez développer. Par
défaut, vous ne pouvez pas utiliser de caractères génériques. L’argument de destination est le répertoire
du nouveau fichier. Par défaut, la destination ne peut pas être un média amovible et ne peut pas être en
lecture seule. Vous pouvez utiliser la attrib commande pour supprimer l’attribut en lecture seule du
répertoire de destination. L’option /f:filespec est requise si la source contient plusieurs fichiers. Cette
option autorise les caractères génériques. Le commutateur /y désactive l’invite de confirmation de
réécriture. Le commutateur /d spécifie que les fichiers ne doivent pas être développés et affiche un
répertoire des fichiers dans la source.
Fixbootécrit un nouveau secteur de démarrage sur la partition système; La fixboot commande est
uniquement prise en charge sur les ordinateurs x86.
Fixmbr répare l’enregistrement de démarrage maître (MBR) de la partition de démarrage. L’argument
nom de l’appareil est un nom facultatif qui spécifie l’appareil qui nécessite un nouveau MBR. Omettez
cette variable lorsque la cible est le périphérique de démarrage. La commande fixmbr est uniquement
prise en charge sur les ordinateurs x86.
Formate un disque. Le commutateur /q effectue un format rapide. Le commutateur /fs: du système de
fichiers spécifie le système de fichiers.
L’aide répertorie toutes les commandes que la console de récupération prend en charge. Pour plus
d’informations sur une commande spécifique, tapez de l’aide
command-name ou
command-name /? .
Listsvc affiche tous les services et pilotes disponibles sur l’ordinateur.
L’affichage de l’Windows affiche les installations détectées et demande le mot de passe administrateur
local pour ces installations. Utilisez cette commande pour passer à une autre installation ou sous-
direction.
La carte affiche les mappages d’appareils actuellement actifs. Incluez l’option arc pour spécifier
l’utilisation des chemins d’accès ARC (Advanced RISC Computing) au lieu de Windows chemins d’accès
des appareils. (ARC est le format utilisé pour le fichier Boot.ini.)
Md (Mkdir) crée un répertoire. La commande fonctionne uniquement dans les répertoires système de
l’installation Windows actuelle, dans les supports amovibles, dans le répertoire racine d’une partition de
disque dur ou dans les sources d’installation locales.
More/Type affiche le fichier texte spécifié à l’écran.
Rd (rmdir) supprime un répertoire. La commande fonctionne uniquement dans les répertoires système
de l’installation Windows actuelle, dans les supports amovibles, dans le répertoire racine d’une partition
de disque dur ou dans les sources d’installation locales.
Ren (renomme) renomme un fichier unique. La commande fonctionne uniquement dans les répertoires
système de l’installation Windows actuelle, dans les supports amovibles, dans le répertoire racine d’une
partition de disque dur ou dans les sources d’installation locales. Vous ne pouvez pas spécifier de
nouveau lecteur ou chemin d’accès comme cible.
Définit les affichages et les variables d’environnement de la console de récupération.
Systemroot définit le répertoire actuel sur %systemroot%.
Mesures de précaution
Comment installer la console de récupération en tant qu’option de démarrage
Vous pouvez installer la console de récupération sur un ordinateur de travail afin qu’elle soit disponible si vous
ne pouvez pas démarrer Windows. Cette mesure de précaution peut vous faire gagner du temps si vous devez
utiliser la console de récupération.
NOTE
procédure. En outre, si votre ordinateur est connecté à un réseau, les paramètres de stratégie réseau peuvent vous
empêcher d’effectuer cette procédure.
Pour installer la console de récupération en tant qu’option de démarrage :

1. Pendant Windows’exécution, insérez le CD Windows Server 2003 dans le CD ou le lecteur de DVD de
l’ordinateur.
3. Dans la zone Ouvrir, tapez la ligne suivante, où
le lecteur est la lettre de lecteur du lecteur CD ou DVD de l’ordinateur qui contient le CD-WINDOWS
Server 2003, puis cliquez sur OK :
**drive: \i386\winnt32.exe /cmdcons
Pour installer la console recovery en tant qu’option de démarrage Windows Server 2003 édition x64,
tapez la ligne suivante :
**drive: \amd64\winnt32.exe /cmdcons
4. Cliquez sur Oui lorsque le message s’affiche, pour installer la console de récupération.
5. Lorsque vous recevez le message qui indique que la console de récupération est correctement installée,
cliquez sur OK.
6. Pour utiliser la console de récupération, redémarrez l’ordinateur, puis utilisez les touches de direction
pour sélectionner microsoft Windows Recover y Console dans la liste De votre choix, sélectionnez le
système d’exploitation à démarrer.
Comment supprimer la console de récupération
Par précaution, ne supprimez pas la console de récupération. Toutefois, si vous souhaitez supprimer la console
de récupération, vous devez le faire manuellement.
Pour supprimer la console de récupération, suivez les étapes suivantes :
2. Cliquez sur Démarrer, puis sur Mon ordinateur.
3. Activer l’option Afficher les fichiers et dossiers masqués (si elle n’est pas déjà allumée). Pour ce faire,
a. Dans le menu Outils, cliquez sur Options de dossier.
b. Cliquez sur l’onglet Affichage.
c. Cliquez sur Afficher les fichiers et dossiers masqués, pour effacer la case à cocher Masquer les
fichiers de système d’exploitation protégés (recommandé) (si elle est sélectionnée), puis cliquez sur
OK.
4. Double-cliquez sur la lettre de lecteur qui représente le disque dur sur lequel vous avez installé la console
de récupération.
5. Supprimez le dossier Cmdcons du dossier racine, puis supprimez le fichier Cmldr. Pour ce faire, procédez
comme suit :
a. Cliquez avec le bouton droit sur Cmdcons, puis cliquez sur Supprimer. Suivez les instructions qui
apparaissent à l’écran, puis cliquez sur Oui pour confirmer la suppression.
b. Cliquez avec le bouton droit sur Cmldr, puis cliquez sur Supprimer. Suivez les instructions qui
apparaissent à l’écran, puis cliquez sur Oui pour confirmer la suppression.
6. Supprimez l’entrée de la console de récupération du Boot.ini de récupération. Pour ce faire, procédez
comme suit.
WARNING
Une modification incorrecte du fichier Boot.ini risque d’empêcher le redémarrage de votre ordinateur. Veillez à
supprimer uniquement l’entrée de la console de récupération.
a. Dans le dossier racine, cliquez avec le bouton droit sur Boot.ini fichier, puis cliquez sur Propriétés.
Cliquez pour effacer la case à cocher En lecture seule, puis cliquez sur OK.
b. Ouvrez le Boot.ini dans Bloc-notes.
c. Recherchez l’entrée de la console de récupération, puis supprimez-la. L’entrée de la console de
récupération ressemble à la ligne suivante :
C:\cmdcons\bootsect.dat="Microsoft Windows Recovery Console » /cmdcons
d. Dans le menu Fichier, cliquez sur Enregistrer, puis sur Quitter pour quitter Bloc-notes.
7. Modifiez l’attribut du fichier Boot.ini en lecture seule. Pour ce faire, cliquez avec le bouton droit Boot.ini,
puis cliquez sur Propriétés. Cliquez pour cocher la case En lecture seule, puis cliquez sur OK.
Outil de rapports du support technique Microsoft
pour Microsoft Software Update Services v
5.2.2003.0
Cet article fournit quelques étapes pour l’installation de l’outil de rapports du support technique Microsoft pour
Microsoft Software Update Services.
Résumé
Cet article explique comment installer l’outil de rapports du support technique Microsoft pour Microsoft
Software Update Services. L’outil de rapports du support technique Microsoft (également appelé
MPS_REPORTS) est un package logiciel compressé qui contient des scripts et des utilitaires que vous pouvez
utiliser pour capturer des informations critiques sur le système, les diagnostics et la configuration de votre
ordinateur. Cet outil inclut l’édition Software Update Services décrite dans cet article et d’autres éditions conçues
pour des problèmes de prise en charge spécifiques.
Vous pouvez utiliser l’outil de rapport du support technique Microsoft pour software update services pour
collecter des informations détaillées sur la configuration actuelle d’un ordinateur. Les informations que vous
collectez aident un support Microsoft à Professional le problème.
L’outil de rapports du support technique Microsoft pour software update services fonctionne sur Windows
Server 2003, Windows XP, Windows 2000 et Windows NT 4.0. Lorsque l’outil s’exécute, il détecte Windows
système d’exploitation installé pour déterminer les commandes qu’il utilisera pour collecter des informations.
L’outil de création de rapports ne modifie aucune entrée de Registre et ne modifie pas le système d’exploitation.
Utilisation de l’outil de rapports du support technique Microsoft pour software update services
Pour utiliser l’outil de rapports du support technique Microsoft pour software update services, suivez les étapes
suivantes :
1. Téléchargez Mpsrpt_sus.exe.
2. Double-cliquez sur la copie des Mpsrpt_sus.exe que vous avez enregistrées sur votre ordinateur, puis
cliquez sur Oui pour accepter le contrat de licence utilisateur final (CLLA).
NOTE
Soyez patient pendant que l’outil collecte des informations. L’outil peut cesser de répondre pendant cinq à quinze
minutes.
3. L’outil crée un fichier .cab nommé Computer_name MPSReports Date .cab dans le dossier
SYSTEM_ROOT \ MPSReports \ Msus \ Cab. Le .cab contient les rapports générés par l’outil de rapports
du support technique Microsoft. Si le .cab n’est pas créé, copiez tous les fichiers du dossier
SYSTEM_ROOT \ MPSReports Msus dans un fichier \ compressé (compressé).
NOTE
Le System_root dossier est celui dans lequel vous avez installé le système d’exploitation. En règle générale, ce
dossier est le dossier C: \ Winnt ou C: \ Windows dossier.
4. Envoyez le .cab ou compressé (compressé) à votre support Microsoft Professional à l’aide de l’adresse de
messagerie que le support Microsoft Professional fournit.
Liste des mises à jour dans Windows Server 2003
Service Pack 2
Cet article répertorie les problèmes résolus dans Microsoft Windows Server 2003 Service Pack 2 (SP2).
Résumé
Les Service Packs sont cumulatifs. Cela signifie que les problèmes résolus dans un Service Pack sont également
résolus dans les Service Packs ultérieurs.
Cet article contient une référence à l’utilitaire de système de prise de décision de maintenance (MDSS), qui est
un utilitaire que le Support Microsoft fournit en l’états et ne prend pas en charge. Microsoft n’offre aucune
garantie, implicite ou autre, concernant les performances ou la fiabilité de l’utilitaire MDSS.
Cet article contient une liste d’articles de la Base de connaissances Microsoft qui décrivent les correctifs et les
mises à jour contenus dans Microsoft Windows Server 2003 Service Pack 2 (SP2).
Cet article est principalement destiné à aider les professionnels de l’informatique et les supports d’entreprise à
prendre en charge et maintenir le système informatique d’une entreprise.
Pour plus d’informations sur Windows Server 2003 SP2, voir Notes de publication pour Microsoft Windows
Server 2003 Service Pack 2.
NOTE
Les versions x64 de Windows Server 2003 et Microsoft Windows XP Professional x64 Edition sont basées sur
l’arborescence de code Windows Server 2003. Les activités de service et de support pour Windows XP Professional x64
Edition utilisent l’arborescence Windows Server 2003 et n’utilisent pas l’arborescence Windows client XP.
Mettre à jour la liste

Pour plus d’informations sur les mises à jour incluses dans Microsoft Windows Server 2003 SP2, cliquez sur les
numéros d’article suivants pour afficher les articles de la Base de connaissances Microsoft.
N UM ÉRO D’A RT IC L E T IT RE DE L’A RT IC L E C AT ÉGO RIE
925104 Le journal système signale de Outils d’administration

nombreuses erreurs « ID d’événement
PerfOS : 2001 » lorsque vous utilisez
un ordinateur basé sur Microsoft
Windows Server 2003 avec plus de 32
processeurs
902400 MS05-051 : Les vulnérabilités dans MS COM+

DTC et COM+ peuvent autoriser
l’exécution de code à distance
910695 CORRECTIF : Vous ne pouvez pas COM+

obtenir d’informations détaillées sur les
erreurs DCOM 10009 dans Windows
Server 2003
244139 Windows vous permet de générer un Pilotes

fichier de vidage mémoire à l’aide du
clavier
898544 CORRECTIF : Vous ne pouvez pas Pilotes

graver un CD ou un DVD sur un
ordinateur exécutant Windows Server
2003
921883 MS06-040 : Vulnérabilité dans le Systèmes distribués (DS)

service serveur peut autoriser
l’exécution de code à distance
906866 Vous pouvez recevoir un message Systèmes de fichiers

d’erreur « ARRÊTER 0x00000035
NO_MORE_IRP_STACK_LOCATIONS »
lorsque vous essayez de vous
connecter à un domaine
922582 Message d’erreur lorsque vous essayez Systèmes de fichiers

de mettre à jour un ordinateur
Windows Microsoft : « 0x80070002 »
896358 MS05-026 : Une vulnérabilité dans Aide

l’aide HTML peut autoriser l’exécution
de code à distance
917557 CORRECTIF : les performances peuvent IIS 6.0

être lentes lorsque vous utilisez
l’authentification Windows intégrée
avec le protocole d’authentification
Kerberos dans IIS 6.0
896688 MS05-052 : Mise à jour de sécurité Internet Explorer

cumulative pour Internet Explorer
899812 Vous recevez une erreur « Internet Internet Explorer

Explorer a rencontré un problème et
doit se fermer » lorsque vous utilisez
Internet Explorer 6 pour afficher une
page Web qui héberge un contrôle
ActiveX
912812 MS06-013 : Mise à jour de sécurité Internet Explorer

cumulative pour Internet Explorer
894081 Nlb Réseau

904942 L’authentification échoue lorsque vous Sécurité

utilisez Outlook ou Outlook Express
pour essayer de vous connecter à un
serveur de messagerie HTTP si vous
utilisez Internet Explorer version 7.0
919557 Vous recevez des erreurs de pré- Sécurité

authentification lorsque vous utilisez
des fichiers keytab générés à l’aide de
l’outil Ktpass.exe sur un ordinateur
922706 Utilisation des pages d’inscription Web Sécurité

des services de certificats avec
Windows Vista
824995 Windows l’heure d’été commence et se Shell

termine de manière incorrecte si le
fuseau horaire est définie sur
(GMT+02:00)
901115 Un ordinateur client des services Terminal Server

Terminal Server peut faire sons sonores
après vous être connecté à un
ordinateur Windows Server 2003
Service Pack 1
902346 CORRECTIF : Messages d’erreur WMI

lorsque vous utilisez une requête WMI
(Windows Management
Instrumentation) pour inscrire des
événements WMI sur un ordinateur
exécutant Windows Server 2003 ou
Windows XP : « 0x80041032 » et «
0x80041003 »
Ce Service Pack inclut également les correctifs et les mises à jour contenus dans Windows Server 2003 Service
Pack 1 (SP1).
Comment réins inscrire Windows client/serveur
dans WSUS
Cet article décrit les étapes à suivre pour réins inscrire un client/Windows client/serveur dans Windows Server
Update Services (WSUS).
Résumé
Cet article vous aidera à réins inscrire Windows client/serveur dans WSUS.
Conseils
Pour ré-inscrire un client/Windows serveur dans WSUS, ez les instructions suivantes :
1. Exécutez la commande sur Windows client/serveur qui ont un gpupdate /force problème d’inscription
dans WSUS.
2. Exécutez la commande sur Windows client/serveur qui ont un wuauclt /detectnow problème
d’inscription dans WSUS.
TIP
Vous pouvez utiliser l’Observateur d’événements pour passer en revue la ré-inscription.
3. Dans de rares cas, vous devrez peut-être exécuter une commande sur Windows client/serveur qui ont un
problème d’inscription wuauclt.exe /resetauthorization /detectnow dans WSUS.
La partition système est déconnectée après
l’installation d’un disque tiers ou d Stockage
logiciels de gestion
Cet article fournit une solution à un problème dans lequel la partition système passe hors connexion après
l’installation d’un disque tiers ou d Stockage logiciels de gestion.
Symptômes
Problème 1
Lors de l’installation du rôle Hyper-V, vous pouvez obtenir l’erreur suivante :
Échec de la configuration des fonctionnalités Windows

Recontentation des modifications
Ne pas désactiver votre ordinateur
Sous CBS.log, recherchez le journal suivant :
Sortie du processus : [l:100 [100]"Le magasin de données de configuration de démarrage n’a pas pu
être ouvert. Le système ne peut pas trouver le fichier spécifié.] [gle=0x80004005]
Problème 2
Lorsque vous exécutez la validation de cluster, Stockage validation échoue, sous Rapports de validation
de cluster, nous pouvons voir l’erreur suivante :
List all disks visible to one or more nodes (including non-cluster disks).
Préparer le stockage pour les tests
Préparation du stockage pour les tests sur les nœuds Node1.contoso.com
Préparation du stockage pour les tests sur le nœud Node1
Échec de la préparation du stockage pour le test sur l’état 87 du nœud Node1
Échec de la préparation du stockage pour le test sur l’état 87 du nœud Node1
Problème 3
Lorsque vous Bcdedit /enum all exécutez, vous obtenez l’erreur suivante :
Le magasin de données de configuration de démarrage n’a pas pu être ouvert. Le système ne peut
pas trouver le fichier spécifié. »
Recherchez la clé de Registre HKEY_LOCAL_MACHINE\BCD00000000. Si nous vérifions sous HKLM, vous

ne trouverez pas la clé BCD00000000.
Cause
Si un disque de stockage ou un logiciel de gestion Stockage tiers est installé, tout le volume peut être mis hors
connexion sans lettre de lecteur.
En règle générale, la partition de 100 Mo est une partition système qui contient la base de données de
configuration de démarrage et n’a pas de lettre de lecteur affectée.
Résolution
Pour résoudre ce problème, utilisez l’une des méthodes suivantes :
À partir de l’invite de commandes, exécutez les commandes suivantes :
C:\\>Diskpart
C:\Diskpart> List volume
C:\Diskpart> Select volume 1 (Considering this is 100-MB system partition)
c:\Diskpart> Online volume
C:\Diskpart> exit
À partir de la console gestion des disques, affectez la lettre de lecteur à la partition de 100 Mo qu’elle doit
mettre en ligne le disque.
Pour accéder à gestion des disques, ouvrez l’invite de commandes, exécutez la commande suivante :
C : > Diskmgmt.msc
Sélectionnez le volume de 100 Mo ; Cliquez avec le bouton droit sur la lettre de lecteur Change de
volume & Chemin d’accès, affectez une lettre de lecteur.
L’affectation de la lettre de lecteur garantit que le volume n’est pas de nouveau hors connexion après un
redémarrage.
Les volumes peuvent être mis hors connexion si AUTOMOUNT est désactivé lors de l’utilisation d’un
logiciel de stockage tiers ou si l’utilisateur a désactivé manuellement le démontage automatique pour le
volume. Pour vérifier cela, tapez la DISKPART> automount commande après avoir exécutez diskpart dans
l’invite de commandes de l’administrateur.
Le montage automatique des nouveaux volumes est désactivé.
Pour activer AUTOMOUNT, exécutez la commande suivante
DISKPART> automount enable
Redémarrez le serveur et le volume ne sera pas mis hors connexion.

SystemInfo.exe n’affiche pas toutes les mises à jour
Cet article fournit une solution de contournement pour un problème dans lequel SystemInfo.exe ne peut pas
afficher toutes les mises à jour installées.
Symptômes
Lorsque vous utilisez SystemInfo.exe dans Windows Server 2003 pour afficher la liste des correctifs installés,
certains correctifs peuvent ne pas être répertoriés si plus de 200 sont installés.
Cause
Il existe une limitation de taille de mémoire tampon qui n’autorise pas l’affichage de tous les correctifs logiciels
de mise à jour du système.
Microsoft est actuellement informé de ce problème. Pour contourner ce problème, exécutez la commande
suivante à une invite Windows commande suivante :
wmic qfe list
Windows Server 2003 est actuellement en fin de cycle de vie et les Service Packs ne sont plus développés pour
ce produit. Lors de l’installation d’un Service Pack, le nombre de correctifs affichés par l’outil SystemInfo.exe est
réduit à un nombre beaucoup plus petit.
Comment désactiver temporairement le pilote de
filtre en mode noyau dans Windows
Cet article explique comment désactiver le pilote de filtre en mode noyau sans supprimer le logiciel
correspondant.
IMPORTANT
Cet article contient des informations qui vous montrent comment réduire les paramètres de sécurité ou désactiver les
fonctionnalités de sécurité sur un ordinateur. Vous pouvez apporter ces modifications pour contourner un problème
spécifique. Avant d’apporter ces modifications, nous vous recommandons d’évaluer les risques associés à l’implémentation
de cette solution de contournement dans votre environnement particulier. Si vous implémentez cette solution de
contournement, prenez les mesures supplémentaires appropriées pour protéger votre système.
Résumé
Vous pouvez désactiver le pilote de filtre lorsque vous dépannagez les problèmes suivants :
Problèmes de copie de fichier ou de sauvegarde.
Erreurs de programme qui se produisent lorsque vous ouvrent des fichiers à partir de lecteurs réseau ou
lorsque vous les sauvegardez. Pour plus d’informations sur ces erreurs de programme, voir Performances
réseau lentes lorsque vous ouvrez un fichier situé dans un dossier partagé sur un ordinateur réseau
distant.
Les messages d’erreur de l’ID d’événement 2022 qui se produisent dans le journal système, par exemple :
Désactiver les pilotes de filtre

Lorsque vous dépannagez l’un de ces problèmes, vous devez souvent faire plus que simplement arrêter ou
désactiver les services associés au logiciel. Même si vous désactivez le composant logiciel, le pilote de filtre est
toujours chargé lorsque vous redémarrez l’ordinateur. Vous pouvez être obligé de supprimer un composant
logiciel pour trouver la cause d’un problème. Au lieu de supprimer le composant logiciel, vous pouvez arrêter
les services appropriés et désactiver les pilotes de filtre correspondants dans le Registre. Par exemple, si vous
empêchez les logiciels antivirus d’analyser ou de filtrer des fichiers sur votre ordinateur, vous devez également
désactiver les pilotes de filtre correspondants.
Pour désactiver les pilotes de filtre, vous devez d’abord identifier les services tiers et leurs pilotes de filtre
correspondants. Après cela, suivez ces étapes.
WARNING
Ce contournement peut rendre votre ordinateur ou réseau plus vulnérable aux attaques provenant d'utilisateurs ou de
logiciels (virus, par exemple) malveillants. Nous ne recommandons pas cette solution de contournement, mais fournissons
ces informations afin que vous pouvez implémenter cette solution de contournement à votre propre discrétion. Son
utilisation relève de votre responsabilité.
IMPORTANT
Un programme antivirus est conçu pour protéger votre ordinateur contre les virus. Vous ne devez pas télécharger ou
ouvrir des fichiers à partir de sources non fiables, visiter des sites Web que vous n’avez pas confiance ou ouvrir des pièces
jointes par courrier électronique lorsque votre programme antivirus est désactivé.
Pour plus d’informations sur les virus informatiques, voir Comment prévenir et supprimer des virus et d’autres
programmes malveillants.
1. Arrêtez tous les services qui appartiennent au package logiciel.
2. Définissez le type de démarrage sur Désactivé . Pour ce faire, procédez comme suit :
a. Cliquez sur Démarrer, sur Panneau de contrôle, double-cliquez sur Outils d’administration, puis
double-cliquez sur Ser vices .
b. Dans le volet Détails , cliquez avec le bouton droit sur le service que vous souhaitez configurer, puis
c. Sous l’onglet Général , cliquez sur Désactivé dans la zone De démarrage .
3. Définissez la clé de Registre de démarrage des pilotes de filtre correspondants sur 0x4 . Une valeur de
0x4 désactivera le pilote de filtre. Pour cela, procédez comme suit.
IMPORTANT
Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations sur la procédure de sauvegarde et de
restauration du Registre, consultez l’article Comment sauvegarder et restaurer le Registre dans Windows.

b. Créez une sauvegarde de la ruche HKEY_LOCAL_MACHINE\System registre.
c. Recherchez, puis cliquez sur la sous-clé de Registre
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services .
d. Cliquez sur l’entrée du pilote de filtre que vous souhaitez désactiver.
e. Double-cliquez sur le paramètre démarrer le Registre, puis définissez-le sur la valeur 0x4 .
NOTE
Cette entrée de Registre a généralement la valeur 0x3.
La plupart des logiciels antivirus utilisent des pilotes de filtre qui fonctionnent avec un service pour analyser la
recherche de virus. Ces pilotes de filtre sont toujours chargés après la désactivation du service. Ces pilotes de
filtre analysent les fichiers à mesure qu’ils sont ouverts et fermés sur un disque dur. Pour résoudre les
problèmes, supprimez temporairement le logiciel antivirus ou contactez le fabricant du logiciel pour déterminer
si une version plus récente est disponible.
Exemple de pilotes de filtre

Cette section décrit certains noms de pilotes de filtre classiques par produit :
Antivirus
Inoculan : INO_FLPY et INO_FLTR
Contrôle : SYMEVENT, NAVAP, NAVEN et NAVEX
Mc Antivirus (), à l’aide de la cmd de l’un des dossiers de l’équipe de sécurité et de l’équipe de sécurité de
l’équipe d’administration de l’équipe de
Trend Micro : Tmfilter.sys et Vsapint.sys
Agent de sauvegarde
Agent de sauvegarde pour les fichiers ouverts : Ofant.sys
Ouvrez le Gestionnaire de transactions à partir de Veritas BackupExec : Otman.sys (Otman4.sys ou
Otman5.sys)
NOTE
Faites attention si vous désactivez ces pilotes de filtre à l’aide de la méthode décrite dans cet article. Si vous faites
cela, vous pouvez recevoir un message d'0x7b’arrêt .
Le message d’erreur d’arrêt 0x7b Inaccessible_Boot_Device peut se produire si les clés de Registre
suivantes existent et contiennent des références au pilote Otman5 lorsque le pilote Otman5.sys n’existe
pas sur le disque dur ou si le pilote est désactivé.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325 -11CE-BFC1-
08002BE10318}\UpperFilters
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{71A27CDD-812A -11D0-BEC7-
08002BE2092F}\UpperFilters
Si vous découvrez l’arrêt 0x7b message d’erreur, vous devez back up these registry keys and delete
the Otman5 reference.
Paramètres de Registre des pilotes

Le tableau suivant répertorie les paramètres valides et leur description pour les paramètres de Registre
Démarrer et Type du pilote :
DESC RIP T IO N DU PA RA M ÈT RE DE
N O M DE L A VA L EUR PA RA M ÈT RE DE VA L EUR VA L EUR
Début 0 = SERVICE_BOOT_START Ntldr ou Osloader précharge le pilote

afin qu’il soit en mémoire au
démarrage de l’ordinateur.
Ces pilotes sont initialisés juste avant

les SERVICE_SYSTEM_START pilotes.
Début 1 = SERVICE_SYSTEM_START Le pilote se charge et s’initialise après

SERVICE_BOOT_START pilotes ont été
initialisés.
Début 2 = SERVICE_AUTO_START Le Gestionnaire de contrôle de service

démarre le pilote ou le service.
Début 3 = SERVICE_DEMAND_START SCM doit démarrer le pilote ou le

service à la demande.
Début 4 = SERVICE_DISABLED Le pilote ou le service ne se charge pas

ou ne s’initialise pas.
DESC RIP T IO N DU PA RA M ÈT RE DE
N O M DE L A VA L EUR PA RA M ÈT RE DE VA L EUR VA L EUR
Type 1 = SERVICE_KERNEL_DRIVER Pilote de périphérique.
Type 2 = SERVICE_FILE_SYSTEM_DRIVER Pilote de système de fichiers en mode

noyau.
Type 8 = SERVICE_RECOGNIZER_DRIVER Pilote de reconnaissance du système

de fichiers.

produits.
Pourquoi être invité à redémarrer votre ordinateur
après avoir installé une mise à jour de sécurité sur
Windows ordinateur basé sur un ordinateur
Cet article explique pourquoi vous pouvez être invité à redémarrer votre ordinateur microsoft Windows après
avoir installé une mise à jour de sécurité.
Pourquoi être invité à redémarrer votre ordinateur

Après avoir installé une mise à jour de sécurité, vous pouvez être invité à redémarrer votre ordinateur si l’une
La mise à jour de sécurité met à jour une DLL chargée dans un ou plusieurs processus requis par Windows.
La mise à jour de sécurité ne peut pas être effectuée pendant le chargement de la DLL. La mise à jour de
sécurité doit donc arrêter le processus qui entraîne le chargement de la DLL. L’arrêt du processus déchargera
la DLL requise pour terminer la mise à jour. Toutefois, le processus dans lequel la DLL est chargée ne peut pas
être arrêté pendant Windows en cours d’exécution. Par exemple, la mise à jour de sécurité décrite dans le
bulletin de sécurité MS04-011 met à jour de nombreuses DLL chargées dans les processus de système
d’exploitation principaux qui ne peuvent pas être arrêtés sans l’arrêt Windows.
La mise à jour de sécurité met à jour .exe fichier en cours d’exécution en tant que processus requis par
Windows. La mise à jour ne peut pas être effectuée pendant l’exécution de ce processus. Toutefois, vous ne
pouvez pas forcer l’arrêt de ce processus, sauf si vous arrêtez Windows. Par exemple, Csrss.exe est un
processus obligatoire dans Windows.
La mise à jour de sécurité met à jour un pilote de périphérique qui est en cours d’utilisation et qui est requis
par Windows. La mise à jour ne peut pas être effectuée pendant l’utilisation de ce pilote de périphérique.
Toutefois, vous ne pouvez pas décharger ce pilote de périphérique à moins d’arrêter Windows. Par exemple,
Disk.sys est un pilote de périphérique requis par Windows.
La mise à jour de sécurité modifie le Registre. Ces modifications nécessitent le redémarrage de votre
ordinateur.
La mise à jour de sécurité modifie les entrées de Registre qui sont lues uniquement lorsque vous démarrez
votre ordinateur.
Comment réduire vos risques d’être invité à redémarrer votre

ordinateur
Pour réduire vos risques d’être invité à redémarrer votre ordinateur après avoir installé une mise à jour de
sécurité, vous pouvez essayer de mettre fin aux processus à l’utilisation des fichiers mis à jour par la mise à jour
de sécurité.
Pour déterminer si les fichiers mis à jour par une mise à jour de sécurité sont utilisés par votre ordinateur, vous
pouvez utiliser l’Explorateur de processus à partir de Sysinternals pour examiner la façon dont les fichiers sont
utilisés et les processus qu’ils utilisent. Vous pourrez peut-être arrêter les services ou mettre fin aux processus
qui utilisent les fichiers. Pour plus d’informations sur l’Explorateur de processus, Windows Sysinternals.
À l’exception de nos propres produits, Microsoft ne prend pas en charge ou ne recommande pas ce produit par
rapport à d’autres personnes dans la même zone. Nous fournissons ces informations uniquement à titre
pratique pour nos clients et, à l’exception de nos propres produits, ne fournissons aucune garantie, qu’elle soit
express ou implicite. Les garanties que nous ne fournissons pas incluent, mais ne sont pas limitées aux garanties
implicites de qualité ou d’aptitude à un usage particulier.
Comment supprimer le message pour redémarrer votre ordinateur

Pour supprimer le message de redémarrage de votre ordinateur, utilisez un commutateur de ligne de
commande. Le commutateur de ligne de commande que vous utilisez dépend du programme d’installation
utilisé par la mise à jour de sécurité. Pour plus d’informations sur les commutateurs de ligne de commande pour
Windows et les packages de mise à jour logicielle IExpress, voir Comment fonctionne Windows Update ?
Lorsque vous utilisez Windows Installer, une mise à jour de sécurité qui utilise l’extension de nom de fichier .msi
ou .msp est installée sur votre ordinateur. Pour plus d’informations sur les options de ligne de commande, voir
Options de ligne de commande.
IMPORTANT
Dans certains cas, vous devez redémarrer votre ordinateur pour appliquer entièrement la mise à jour de sécurité. Votre
ordinateur peut rester vulnérable si la mise à jour de sécurité n’est pas entièrement appliquée.
Support technique pour les versions x64 de Microsoft Windows

produits.
S’applique à
Cet article s’applique à tous les systèmes d’exploitation Microsoft actuellement pris en charge.
Comment obtenir le dernier Service Pack pour
Windows Server 2008
Cet article explique comment obtenir Windows Server 2008 Service Pack 2 (SP2).
S’applique à : Windows Server 2008 Service Pack 2
Résumé
Windows Les mises à jour de Server 2008 sont distribuées dans des Service Packs. Les Service Packs permettent
de maintenir Windows Server 2008 à jour. En outre, les Service Packs étendent et met à jour les fonctionnalités
de votre ordinateur.
Les Service Packs incluent des mises à jour, des outils d’administration système, des pilotes et des composants
supplémentaires. Ces composants sont facilement regroupés pour faciliter le téléchargement. Les Service Packs
sont cumulatifs. Chaque nouveau Service Pack contient tous les correctifs inclus dans les Service Packs
précédents et contient également de nouveaux correctifs. Vous n’avez pas besoin d’installer un Service Pack
précédent avant d’installer le dernier Service Pack.

Date de publication : 26 mai 2009
Vous pouvez télécharger Windows Server 2008 SP2 à partir du site Windows Update et du Centre de
téléchargement Microsoft. Les versions suivantes de Windows Server 2008 SP2 sont disponibles :
Une version 32 bits
Une version 64 bits (x64)
Version itanium
Obtenir Windows Server 2008 SP2 à partir de Windows Update
Vous pouvez télécharger Windows Server 2008 SP2 à partir de Microsoft Windows Update.
Obtenir Windows Server 2008 SP2 à partir du Centre de téléchargement Microsoft
Pour télécharger Windows Server 2008 SP2 à partir du Centre de téléchargement Microsoft, visitez le site Web
Microsoft approprié :
Windows Server 2008 Service Pack 2 et Windows Vista Service Pack 2 - CINQ DVD autonomes linguistiques
ISO
NOTE
Si vous avez installé une version antérieure de Windows Server 2008 SP2, désinstallez la version prérequise du Service
Pack, puis installez le produit final à partir du Centre de téléchargement Microsoft.
Correctifs et mises à jour de sécurité inclus dans Windows Server

2008 SP2
Pour obtenir la liste des correctifs logiciels et des mises à jour de sécurité dans Windows Server 2008 SP2, voir
Correctifs logiciels et mises à jour de sécurité dans Windows Server 2008 SP2et Windows Vista SP2 .
Notes de publication
Pour plus d’informations sur les problèmes avec Windows Server 2008 Service Pack 2, voir Notes de
publication pour Windows Server 2008 avec Service Pack 2.
Pour plus d’informations, voir Informations sur le Service Pack 2 pour Windows Vista et Windows Server 2008.
Ressources supplémentaires
Pour obtenir de la documentation, des outils et des ressources pour vous aider à évaluer, déployer et gérer
Windows Server 2008 SP2 sur les serveurs de votre organisation, voir Nouveautés du déploiement Windows
10.
Pour les questions fréquemment posées sur Windows Server 2008 Service Pack 2 et sur Windows Vista Service
Pack 2, voir Questions fréquemment posées : Windows Server 2008 Service Pack 2et Windows Vista Service
Pack 2 .
Le package Windows Server Update
Services’installation 3.0 est disponible
Cet article fournit des informations sur Windows Server Update Services package d’installation 3.0.
Introduction
Cet article décrit la version release-to-web (RTW) de Windows Server Update Services (WSUS) 3.0. WSUS 3.0
permet de mettre à niveau la version antérieure de ce produit. Vous pouvez installer la version RTW de WSUS
3.0 sur les systèmes d’exploitation suivants :
Microsoft Windows Server 2003 avec Service Pack 1 ou un Service Pack ultérieur
Microsoft Windows XP avec Service Pack 2
Windows Vista
WSUS 3.0 offre de nouvelles fonctionnalités qui permet aux administrateurs de déployer plus facilement les
mises à jour et de gérer les mises à jour au sein d’une organisation. Cette mise à jour peut mettre à niveau les
ordinateurs exécutant les versions suivantes de WSUS vers WSUS 3.0 RTW :
WSUS 2.0
WSUS 2.0 Service Pack 1 (SP1)
WSUS 3.0 RC
Avant d’installer WSUS 3.0, assurez-vous que l’ordinateur répond à la minimale requise.
Conditions préalables du logiciel WSUS 3.0 Server
Windows Server 2003 avec Service Pack 1 ou un Service Pack ultérieur
WSUS 2.0, WSUS 2.0 Service Pack 1 ou WSUS 3.0 RC
Internet Information Services (IIS) 6.0 ou une version ultérieure
Microsoft .NET Framework 2.0
Microsoft Management Console 3.0
Microsoft Report Viewer
Facultatif : Microsoft SQL Server 2005 avec Service Pack 1
NOTE
Si une version compatible de SQL Server n’est pas installée, WSUS 3.0 installe Base de données interne Windows.
Conditions préalables logicielles de la console d’administration WSUS 3.0

Windows Vista, Windows XP avec Service Pack 2 ou Windows Server 2003 avec Service Pack 1 ou un Service
Pack ultérieur
WSUS 3.0 RC
Microsoft .NET Framework 2.0
Microsoft Management Console 3.0
Microsoft Report Viewer
Mettre à jour les informations
119591 obtenir des fichiers de support Microsoft à partir de services en ligne
Vous trouverez le raccourci permettant de démarrer la console d’administration WSUS 3.0 dans le dossier Outils
d’administration. Dans Windows XP avec SP2 et dans Windows Vista, le dossier Outils d’administration se
trouve dans le Panneau de commande.
Problème de configuration important
Si vous utilisez un serveur proxy qui nécessite une authentification, vous devez réécrire le mot de passe du
serveur proxy dans l’Assistant Configuration de WSUS Server. Si vous ne le faites pas, le serveur WSUS risque
de ne pas synchroniser les mises à jour. Étant donné que l’Assistant Configuration démarre automatiquement à
la fin du processus d’installation, ce problème peut provoquer des erreurs de synchronisation après la mise à
niveau vers WSUS 3.0. Vous pouvez éviter ce problème en anérant l’Assistant Configuration après la mise à
niveau ou en réentrez le mot de passe de proxy correct lors de l’exécuteur de l’Assistant. Pour résoudre ce
problème une fois qu’il s’est produit, suivez les étapes suivantes :
1. Dans l’arborescence de la console WSUS 3.0, cliquez sur Options.
2. Dans le volet d’informations, cliquez sur Mettre à jour la source et le ser veur proxy.
3. Dans la boîte de dialogue Mettre à jour la source et le serveur proxy, cliquez sur l’onglet Ser veur proxy.
4. Reentez le mot de passe proxy. Ensuite, enregistrez le paramètre.
Pour plus d’informations Windows Server Update Services, visitez le site Web Microsoft suivant :
WSUS TechNet Center
https://technet.microsoft.com/wsus/default.aspx
Windows Server Update Services 3.0 SP2 Dynamic
Installer pour le Gestionnaire de serveur
Cet article décrit le programme d Windows Server Update Services dynamique 3.0 SP2 pour le Gestionnaire de
serveur.
Introduction
Microsoft a publié l’installation dynamique Windows Server Update Services (WSUS) 3.0 Service Pack 2 (SP2)
pour Windows Server 2008. WSUS permet aux administrateurs informatiques de gérer entièrement la
distribution des mises à jour publiées via Microsoft Update sur les ordinateurs de leur réseau.
Cet article contient des informations sur le contenu du Service Pack, des liens vers des instructions et des
exigences système pour l’installation sur les systèmes d’exploitation Windows Server 2008 pris en charge à
l’aide du Gestionnaire de serveur et comment déterminer si le Service Pack est installé.
Améliorations des fonctionnalités et mises à jour logicielles

importantes dans Le Service Pack 2
Intégration à Windows Server 2008 R2
Prise en charge de la fonctionnalité BranchCache sur Windows Server 2008 R2
Prise en charge Windows 7 clients
Améliorations des fonctionnalités WSUS

Règles d’approbation automatique : les règles d’approbation automatique incluent désormais la possibilité de
spécifier la date et l’heure d’échéance de l’approbation pour tous les ordinateurs ou des groupes
d’ordinateurs spécifiques.
Mettre à jour les fichiers et les langues : la gestion améliorée de la sélection de la langue pour les serveurs en
aval inclut une nouvelle boîte de dialogue d’avertissement qui s’affiche lorsque vous décidez de télécharger
les mises à jour uniquement pour les langues spécifiées.
Mise à niveau facile : WSUS 3.0 SP2 peut être installé en tant que mise à niveau sur place à partir de versions
antérieures de WSUS et conserve tous les paramètres et approbations. L’interface utilisateur est compatible
entre WSUS 3.0 SP1 et SP2 sur le client et le serveur.
Rapports : les nouveaux rapports de mise à jour et d’état de l’ordinateur vous permet de filtrer les mises à
jour approuvées pour l’installation. Vous pouvez exécuter ces rapports à partir de la console WSUS ou
utiliser l’API pour incorporer cette fonctionnalité dans vos propres rapports.
Mises à jour logicielles

Correctifs de stabilité et de fiabilité pour le serveur WSUS 3.0, tels que la prise en charge des adresses IPv6
de plus de 40 caractères.
La boîte de dialogue d’approbation trie désormais les groupes d’ordinateurs par ordre alphabétique par nom
de groupe.
Les icônes de tri des rapports d’état de l’ordinateur sont désormais fonctionnelles dans les environnements
x64.
Une nouvelle version de Windows Update Agent est incluse avec WSUS 3.0 SP2. Cette nouvelle version
apporte des améliorations et des correctifs, tels que la prise en charge des API appelées par une session
callnoninteractiveteractive du système nonlocal.
Par défaut, Windows Server 2008 SP2 inclut la possibilité d’installer le service de rôle WSUS à l’aide du
Gestionnaire de serveur. Ce rôle vous permet d’utiliser le logiciel enfichable MMC Server Manager et les
Assistants pour installer, configurer et gérer WSUS 3.0 SP2. Le package dynamique pour WSUS 3.0 SP2 s’installe
uniquement à l’aide du Gestionnaire de serveur.
Le package WSUS 3.0 SP2 présente les caractéristiques et la logique de détection Microsoft Update suivantes :
Classification : Mise à jour
Supersedes : WSUS 3.0 SP1
Ce package s’applique uniquement aux systèmes d’exploitation Windows Server suivants avec
l’intégration WSUS-Server Manager :
Windows Server 2008 SP1 avec le Gestionnaire de serveur
Pour plus d’informations, cliquez sur le numéro d’article suivant pour afficher l’article de la Base de
connaissances Microsoft : 940518 Une mise à jour est disponible et intègre Windows Server
Update Services (WSUS) 3.0 au Gestionnaire de serveur dans Windows Server 2008
Windows Server 2008 R2, édition x64 uniquement
Règles d’applicabilité :
Est installé = Non
Est installable
Centre de téléchargement :
Le site Web centre de téléchargement WSUS 3.0 SP2 inclut les termes du contrat de licence utilisateur
RTM Microsoft.
Les versions antérieures à la version 3.0 SP1 de WSUS 3.0 ne sont plus disponibles en
téléchargement.
Une fois que WSUS 3.0 est détecté comme étant installé par le Gestionnaire de serveur, il peut être configuré et
géré dans l’interface utilisateur du Gestionnaire de serveur ou le logiciel enfichable WSUS 3.0. Pour installer
WSUS 3.0 SP2 sur un serveur qui exécute Windows Server 2008 SP2 mis à jour par un serveur WSUS 3.0,
approuvez l’installation dynamique Windows Server Update Services 3.0 SP2 pour Windows Server 2008, puis
installez le rôle WSUS à l’aide du Gestionnaire de serveur.

Recherchez « Windows Server Update Services 3.0 SP2 » dans Ajouter ou supprimer des programmes ou des
fichiers et fonctionnalités de programme dans le Panneau de contrôle. Si « Windows Server Update Services 3.0
SP2 » n’apparaît pas, le Service Pack n’est pas installé.
Vous ne pouvez pas utiliser l’ajout ou la suppression de programmes dans le Panneau de contrôle pour
supprimer uniquement WSUS 3.0 Service Pack 2, car il supprimera également tous les WSUS 3.0.
Pour supprimer WSUS 3.0 SP2 à l’aide du Gestionnaire de serveur, suivez les étapes suivantes :
1. Connectez-vous au serveur sur lequel vous prévoyez de supprimer WSUS 3.0 SP2 à l’aide d’un compte
membre du groupe Administrateurs local.
2. Cliquez sur Démarrer , pointez sur Outils d’administration , puis cliquez sur Gestionnaire de ser veur .
3. Dans le volet droit de la fenêtre Gestionnaire de serveur, dans la section Résumé des rôles, cliquez sur
Supprimer des rôles.
4. Si la page Avant de commencer s’affiche, cliquez sur Suivant.
5. Dans la page Sélectionner des rôles ser veur, Windows Server Update Services case à cocher.
6. Dans la page Windows Ser ver Update Ser vices, cliquez sur Suivant.
7. Dans la page Confirmer les sélections d’installation, cliquez sur Supprimer.
8. Dans la page Supprimer Windows Ser ver Update Ser vices 3.0 SP2, sélectionnez les éléments
supplémentaires à supprimer, puis cliquez sur Suivant .
9. Cliquez sur Terminer pour quitter l’Assistant lorsque l’Assistant Suppression de WSUS 3.0 SP2 est terminé.
Le service WSUS SelfUpdate n’envoie pas de mises
à jour automatiques
Cet article fournit une solution à un problème dans lequel les ordinateurs clients ne reçoivent pas de mises à
jour lorsque vous utilisez un service AutoUpdate Microsoft Windows Server Update Services (WSUS) pour
envoyer des mises à jour automatiques.
Symptômes
Lorsque vous essayez d’utiliser le service WSUS SelfUpdate pour envoyer des mises à jour automatiques aux
ordinateurs clients, les ordinateurs clients ne reçoivent pas les mises à jour. En outre, les ordinateurs clients ne
signalent pas au serveur WSUS.
Lorsque cela se produit, la console d’administration WSUS enregistre le message d’erreur suivant :
Vérifiez la configuration de votre serveur. Un ou plusieurs composants du service de mise à jour n’ont pas
pu être contactés. Vérifiez l’état de votre serveur et assurez-vous que Windows service de mise à jour du
serveur est en cours d’exécution.
Services non en cours d’exécution : SelfUpdate
Le journal des événements peut également inclure l’événement suivant :
Cause
Ce problème peut se produire si une ou plusieurs des conditions suivantes sont vraies :
Les autorisations sur C:\Program Files\Update Service\SelfUpdate l’annuaire sont manquantes ou mal
configurées, ou le compte IUSR_ ComputerName a été supprimé du groupe Utilisateurs.
Le répertoire virtuel SelfUpdate est absent du serveur WSUS.
Le répertoire virtuel SelfUpdate n’est pas configuré pour le site par défaut sur le port 80.
Le répertoire virtuel SelfUpdate ne comprend pas d’autorisations d’accès anonyme.
Le site Web par défaut est configuré pour utiliser les adresses IP spécifiées et il manque une entrée pour
127.0.0.1.
Le site Web par défaut n’a pas d’autorisations d’accès anonyme.
Le serveur WSUS est également Microsoft Windows SharePoint Services installé. Les ressources WSUS n’ont
pas été exclues de SharePoint gestion.
L’installation Selfupdate.msi'installation a été défectueuse. Par conséquent, les fichiers sont manquants dans
les sous-dossiers ~\Selfupdate.
Résolution
Pour résoudre ce problème, vous devez avoir les autorisations minimales suivantes sur le répertoire C:\Program
Files\Update Service\SelfUpdate.
GRO UP A UTO RISAT IO N S
Administrateurs Contrôle total
Système Contrôle total
Domaine/Utilisateurs ou Local/Utilisateurs Lire&exécuter, lire, ré lister des dossiers
IUSR_ ComputerName Lire&exécuter, lire, ré lister des dossiers
NOTE
IUSR_ ComputerName représente le nom d’hôte du serveur qui exécute IIS où WSUS est installé. Si ce compte est
membre du groupe Utilisateurs, vous n’avez pas besoin de définir explicitement ces autorisations.
Pour résoudre un problème où le répertoire virtuel SelfUpdate est manquant ou qu’aucun répertoire virtuel
SelfUpdate n’est répertorié sous le site Web lié au port 80, exécutez le fichier Selfupdate.msi qui se trouve dans
le dossier Program files\Update services\Setup.
Pour résoudre les problèmes où le répertoire virtuel SelfUpdate ne contient pas d’autorisations d’accès
anonyme, ouvrez le Gestionnaire des services Internet( IIS), développez le site Web par défaut, cliquez avec le
bouton droit sur le répertoire virtuel SelfUpdate, puis cliquez sur Propriétés . Sous l’onglet Sécurité de
l’annuaire , cliquez sur Modifier sous Authentification et contrôle d’accès . Assurez-vous que l’accès
anonyme est activé.
NOTE
Cette étape doit également être effectuée pour le site Web par défaut. L’arborescence SelfUpdate ne fonctionne pas si
vous avez un site Web lié à une adresse IP spécifique dans votre configuration IIS. La solution consiste à définir votre
configuration IIS pour répondre à « Toutes les adresses non définies » ou à ajouter 127.0.0.1 à la liste des adresses IP
utilisées pour SelfUpdate.
Utilisez Internet Information Services console de gestion (IIS) pour vérifier que le serveur est installé avec l’une
des deux configurations suivantes.
Configuration 1 : WSUS est installé sur le site Web par défaut
Configurez le site Web par défaut à l’aide des paramètres suivants :
SelfUpdate
Contenu
ClientWebService
SimpleAuthWebService
WSUSAdmin
ReportingWebService
DssAuthWebService
Configuration 2 : WSUS est installé sur un site Web personnalisé
Configurez le site Web par défaut sur le port 80 à l’aide des paramètres suivants :
SelfUpdate
ClientWebService
Configurez l’administration WSUS sur le port 8530 avec les paramètres suivants :
SelfUpdate
Contenu
ClientWebService
SimpleAuthWebService
WSUSAdmin
ReportingWebService
DssAuthWebService
Quelle que soit la configuration que vous sélectionnez, vous devez également vérifier les paramètres suivants :
Vous devez configurer le répertoire virtuel SelfUpdate sous le site Web par défaut ou tout autre site Web
pour écouter le port 80.
Le répertoire virtuel SelfUpdate pointe vers C:\Program Files\Update Service\SelfUpdate.
Le répertoire virtuel WSUSAdmin est le seul répertoire virtuel dans IIS dont la sécurité doit être définie sur
Integrated Windows Authentication. Définissez la sécurité de tous les autres répertoires virtuels sur Accès
anonyme activé .
Statut
Microsoft a confirmé qu’il s’agit d’un problème.
Lorsque vous utilisez IIS, vous pouvez déplacer le répertoire SelfUpdate vers un autre site Web. Pour ce faire,
1. Cliquez sur Démarrer, sur Exécuter , tapez Admintools du contrôle, puis double-cliquez Internet Information
Services (IIS).
2. Développez le dossier Sites Web , puis cliquez sur le nœud Administration WSUS .
3. Cliquez avec le bouton droit sur le nœud SelfUpdate , pointez sur Toutes les tâches, puis cliquez sur
Enregistrer la configuration dans le fichier .
4. Tapez un nom pour le fichier, puis enregistrez-le dans un autre dossier. Vous utiliserez ce fichier aux étapes 9
à 12.
5. Cliquez avec le bouton droit sur le nœud ClientWebSer vice , sélectionnez Toutes les tâches, puis cliquez
sur Enregistrer la configuration dans le fichier .
6. Tapez un nom pour le fichier et enregistrez-le dans le dossier que vous avez utilisé à l’étape 4. Vous utiliserez
ce fichier aux étapes 13 à 15.
7. Sélectionnez le site Web par défaut ou un autre site Web qui s’exécute sur le port 80.
8. Cliquez avec le bouton droit sur le site Web, pointez sur Nouveau , puis cliquez sur Réper toire vir tuel (à
par tir du fichier).
9. Sélectionnez le répertoire dans lequel vous avez enregistré les fichiers SelfUpdate et ClientWebService.xml
aux étapes 4 et 6.
10. Sélectionnez le SelfUpdate.xml, puis cliquez sur Ouvrir .
11. Cliquez sur Lire le fichier, cliquez sur le fichier SelfUpdate qui est maintenant répertorié sous Sélectionner
une configuration à importer, puis cliquez sur OK .
12. Dans la boîte de dialogue Gestionnaire des ser vices IiS , tapez le nom d’un nouveau répertoire virtuel
dans la zone Alias , puis cliquez sur OK .
13. Sélectionnez le fichier.xml ClientWebSer vice , puis cliquez sur Ouvrir .
14. Cliquez sur Lire le fichier, cliquez sur le fichier SelfUpdate qui est maintenant répertorié sous Sélectionner
une configuration à importer, puis cliquez sur OK .
15. Dans la boîte de dialogue Gestionnaire des ser vices IiS , tapez le nom d’un nouveau répertoire virtuel
dans la zone Alias , puis cliquez sur OK .
16. S’il s’agit d’un nouveau site Web, démarrez le site Web à partir du Gestionnaire des services Internet( IIS). S’il
s’agit d’un site Web existant, redémarrez le site Web à partir du Gestionnaire des services Internet( IIS).
References
Pour plus d’informations sur les mises à jour automatiques dans Windows, voir Description de la fonctionnalité
Mises à jour automatiques dans Windows.
Windows Update Standalone Installer (WUSA)
renvoie 0x5 ERROR_ACCESS_DENIED lors du
déploiement de fichiers .msu via WinRM et
Windows Remote Shell
Cet article vous aide à contourner un problème qui se produit lorsque vous déployez Windows Mettre à jour les
fichiers .msu via Windows Remote Management 2.0 et Windows Remote Shell.
Symptômes
Windows Update Standalone Installer (WUSA) renvoie des 0x5 ERROR_ACCESS_DENIED lors du déploiement de
fichiers .msu de mise à jour Windows via Windows Remote Management 2.0 et Windows Remote Shell. Vous
pouvez également voir ce qui suit dans le journal des événements d’application :
Source : Microsoft-Windows-WUSA
Niveau : Erreur
Description : Windows mise à jour n’a pas pu être installée en raison de l'2147942405 « L’accès est refusé ».
L’installation d’une mise à jour à l’aide de WUSA ou des API WUA sur un ordinateur distant n’est pas prise en
charge.
Pour contourner ce problème, utilisez la méthode suivante :
Extrayez le fichier .msu via Windows Shell distant avec WUSA à l’aide de la commande suivante :
winrs.exe -r:<computername> wusa.exe <update> /extract:<destination>
Lorsque vous avez terminé, installez .cab package avec dism.exe ou Gestionnaire de package. Pour utiliser
dism.exe, utilisez la commande ci-dessous :
winrs.exe -r:<computername> dism.exe /online /add-package /PackagePath:<Path_To_Package>\KBnnnnnnn.cab
Le programme Windows installer autonome de mise à jour utilise l’API Windows Update Agent pour installer les
packages de mise à jour. Les packages de mise à jour ont une extension de nom de fichier .msu. L’extension de
nom de fichier .msu est associée au programme d’installation Windows update autonome.
Les restrictions de sécurité sur l’utilisation à distance des API WUA sont documentées ici :
Utilisation de WUA à partir d’un ordinateur distant
Vous ne pouvez pas installer de fonctionnalités dans
Cet article fournit une solution à un problème qui vous empêche d’ajouter des fonctionnalités à un ordinateur
Windows Server 2012 R2 qui exécute l’option d’installation server core.
Symptômes
Vous avez un ordinateur qui exécute Windows Server 2012 R2.
L’ordinateur exécute l’option d’installation server core.
L’option Server Core a été installée à l’aide du support de licence en volume qui n’a pas accès à Windows
Update.
Dans ce scénario, l’installation de la fonctionnalité échoue. En outre, vous recevez le message d’erreur suivant :
Erreur : 0x800f081f
Les fichiers source sont introuvables. Utilisez l’option « Source » pour spécifier l’emplacement des fichiers
requis pour restaurer la fonctionnalité. Pour plus d’informations sur la spécification d’un emplacement
source, voir Configure a Windows Repair Source.
Résolution
Méthode 1 : Connecter internet
Si le serveur peut se connecter à Windows mise à jour pour l’installation de la fonctionnalité, laissez le serveur
établir la connexion.
Méthode 2 : utiliser Windows Server 2012 d’installation R2
Si le serveur ne peut pas se connecter à Windows Update, téléchargez le nouveau support de licence en volume
(publié le 11 décembre 2013) et utilisez la commande Install-WindowsFeature PowerShell. Pour ce faire, suivez
1. Insérez le DVD Windows Server 2012 R2 mis à jour dans le lecteur de DVD de l’ordinateur.
2. Tapez la commande suivante pour déterminer le numéro d’index requis pour les étapes 3 et 4.
Dism /get-wiminfo /wimfile:<drive>:\sources\install.wim
NOTE
Dans cette commande, <drive> représente la lettre de lecteur réelle.
Exemple de sortie de la commande DISM :
Index : 1
Name : Windows Server 2012 R2 SERVERSTANDARDCORE
Description : Windows Server 2012 R2 SERVERSTANDARDCORE
Size : 6,653,342,051 bytes
Index : 2
Name : Windows Server 2012 R2 SERVERSTANDARD
Description : Windows Server 2012 R2 SERVERSTANDARD
Size : 11,807,528,410 bytes
Index : 3
Name : Windows Server 2012 R2 SERVERDATACENTERCORE
Description : Windows Server 2012 R2 SERVERDATACENTERCORE
Size : 6,653,031,430 bytes
Index : 4
Name : Windows Server 2012 R2 SERVERDATACENTER
Description : Windows Server 2012 R2 SERVERDATACENTER
Size : 11,809,495,151 bytes
NOTE
Lorsque vous spécifiez le numéro dans la cmdlet Install-WindowsFeature PowerShell à l’étape 4, vous devez utiliser
le numéro d’index pour la version complète (non principale) de la référence (SKU) que vous avez actuellement
<index> installée. Par exemple, si vous avez installé Windows Server 2012 R2 Datacenter, le numéro d’index requis
est 4. Si vous avez installé Windows Server 2012 R2 Standard, le numéro d’index requis est 2.
3. Ouvrez une invite de commandes PowerShell en tapant la commande suivante :
Powershell.exe
4. Tapez la commande PowerShell suivante, dans laquelle représente l’emplacement des fichiers
d’installation Windows Server 2012 R2 et représente l’index numéroé de <drive> <index> l’étape 2 :
Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Source wim:

<drive>:\sources\install.wim:<index>
Par exemple : si votre média se trouve sur le lecteur F et que vous installez la version complète du centre
de données, entrez la commande suivante :
Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Source wim:f:\sources\install.wim:4
Le support de licence en volume Windows Server 2012 R2 a été conçu pour exiger l’accès à Windows Update
pour ajouter des composants ou fonctionnalités facultatifs qui ne sont pas inclus dans le référentiel côte à côte.
Si le serveur n’a pas accès à Internet ou si l’accès à Windows Update a été restreint, vous ne pouvez pas activer
les composants ou fonctionnalités facultatifs à l’aide de la commande DISM, des cmdlets Windows PowerShell
ou du Gestionnaire de serveur.
Statut
Microsoft a confirmé qu’il s’agit d’un problème dans l’empaquetage des supports avec licence en volume
Windows Server 2012 R2. Ce comportement n’est pas d’actualité et a été corrigé dans la version de licence en
volume publiée le 11 décembre 2013. Utilisez le nouveau média pour les installations Windows Server 2012 R2.
Consultez la section Résolution pour résoudre ce problème sur les serveurs sur lesquels vous ne pouvez pas
installer de fonctionnalités.
Ajouter des pilotes plug-and-play OEM à Windows
installations
Cet article décrit les étapes à suivre pour ajouter des pilotes fournis par le fabricant de l’équipement d’origine
(OEM) Windows installations.
Résumé
Cet article inclut uniquement les pilotes qui sont généralement installés lors de l’installation en mode interface
utilisateur graphique (GUI) ou après l’installation par l’éumération Plug-and-Play. Cela vous permet de pré-
charger les pilotes plug-and-play OEM que vous pouvez utiliser si le matériel associé est ajouté ultérieurement
au système.
Cet article explique comment ajouter des pilotes plug-and-play OEM dans les situations suivantes :
Installation sans assistance
Installation de Sysprep
Installations du service d’installation à distance (RIS)
Images DePérég
Installations de Windows existantes
Les pilotes installés pendant la partie « Installation d’appareils » du programme d’installation en mode
GRAPHIQUE doivent être trouvés à certains emplacements. À ce stade, le programme d’installation installe les
appareils à l’aide d’ID Plug-and-Play qui ont été Windows plug-and-play. Le programme d’installation recherche
un chemin d’accès prédéfiqué sur le lecteur, en regardant dans les fichiers .inf pour trouver la meilleure
correspondance pour l’ID plug-and-play de l’appareil. Par défaut, ce chemin d’accès est défini à l’emplacement
de Registre suivant et est défini sur %SystemRoot%\Inf :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath: REG_EXPAND_SZ:%SystemRoot%\Inf
Le programme d’installation utilise ce chemin d’accès pour localiser les fichiers .inf pour l’installation de
l’appareil. Après l’installation, ce chemin d’accès est également utilisé pour tout nouveau matériel trouvé et
installé. Si vous modifiez cette clé lors de l’installation à l’aide du fichier Sysprep.inf ou du fichier de réponses
sans surveillance, la valeur est enregistrée et est également utilisée après l’installation.
Les sections suivantes contiennent les étapes à suivre pour ajouter des pilotes fournis par OEM aux installations
d’installation sans surveillance ou Sysprep de Windows.
Pour Microsoft Windows 2000
Configuration sans surveillance
Lorsque vous ajoutez des pilotes au programme d’installation sans surveillance, suivez ces étapes. Si les pilotes
fournis par l’OEM ne sont pas signés numériquement, vous pouvez recevoir un message concernant les pilotes
1. Créez votre partage de distribution sur un serveur en copiant le contenu du dossier Windows
d’installation I386. Vous pouvez utiliser le programme Setupmgr.exe pour créer ce partage et le fichier
Unattended.txt partage. Le programme Setupmgr.exe se trouve sur le disque d’installation Windows dans
le dossier Support\Tools du fichier Deploy.cab et dans le fichier Unattend.doc qui contient des
informations sur le programme d’installation Windows sans assistance.
2. Créez un $oem$ $ 1\Drivers dans le dossier I386. Vous pouvez créer des dossiers supplémentaires dans
le sous-dossier Drivers, en fonction du matériel que vous souhaitez installer. Par exemple, vous pouvez
installer une carte réseau, un modem ou une vidéo. Le dossier $1 est résolu en %SystemDrive%. Lors de
l’installation en mode texte, ces dossiers et fichiers sont copiés dans les dossiers %SystemDrive%\Drivers
comme suit :
\i386
\$oem$
- - \$1
- - - \Drivers
- - - - - \network adapter
- - - - - \MODEM
- - - - - \VIDEO
3. Copiez tous les fichiers de pilotes fournis par le OEM pour l’appareil dans les dossiers que vous avez
créés à l’étape précédente.
4. Ajoutez l’entrée OemPnPDriversPath = Driver_Paths dans la section [Sans surveillance] du fichier de
réponses du programme d’installation. Vous pouvez énumérer plusieurs chemins d’accès dans cette clé
en les séparant par un point-virgule (;). Par exemple, ajoutez l’entrée suivante.
[Sans surveillance]
OemPnPDriversPath = « Drivers\network adapter;Drivers\Modem;Drivers\Video »
NOTE
La chaîne de variable d’environnement %SystemDrive% est automatiquement insérée avant chacun des chemins
de recherche répertoriés.
5. Enregistrez le fichier de réponses.

Lors de l’installation en mode GUI lorsque le système recherche des ID plug-and-play dans les fichiers .inf, il
recherche également les chemins d’accès indiqués dans OemPnPDriversPath et le chemin d’accès par défaut
standard de %WinDir%\Inf. Le chemin d’accès %WinDir%\Inf est répertorié en premier dans l’ordre de
recherche, mais si vous avez un appareil pris en charge par plusieurs fichiers .inf, le programme d’installation
continue de rechercher tous les chemins d’accès spécifiés dans l’entrée OemPnPDriversPath. ((Windows peut
inclure un pilote qui offre des fonctionnalités génériques.) Bien qu’il puisse trouver plusieurs correspondances,
Plug-and-Play utilise le fichier .inf qui a la meilleure correspondance, puis installe le pilote de périphérique
associé pour prendre en charge l’appareil.
Configuration de Sysprep
Les étapes d’ajout de pilotes OEM à un programme d’installation Sysprep Windows ressemblent aux étapes de
la section « Installation sans surveillance », sauf que vous n’avez pas besoin de créer le partage de distribution.
Pour ajouter des pilotes à l’assistant mini-Sysprep, suivez ces étapes.
NOTE
Pour ajouter des pilotes de stockage de masse OEM tiers à l’image Sysprep que vous utilisez pour démarrer l’ordinateur,
vous avez besoin d’au moins la version 1.1 de Sysprep. Il y a eu de nombreuses mises à jour de l’outil Sysprep et des outils
de déploiement qui incluent Sysprep. Par conséquent, nous vous recommandons d’utiliser la dernière version de l’outil
Sysprep et les outils de déploiement spécifiques au système d’exploitation que vous déployez.
1. À la racine du volume où se trouve le dossier %WinDir%, créez une structure de dossiers pour contenir
les pilotes fournis par le OEM comme suit :
\Drivers
- - \network adapter
- - \VIDEO
\Sysprep
\WINNT
2. Copiez les pilotes fournis par l’OEM dans leurs sous-foldeurs appropriés.
3. Ajoutez l’entrée OemPnPDriversPath = Driver_Paths dans la section [Sans surveillance] du fichier
Sysprep.inf. Vous pouvez énumérer plusieurs chemins d’accès dans cette clé en les séparant par un point-
virgule (;) comme illustré dans l’exemple suivant.
[Sans surveillance]
OemPnPDriversPath = « Drivers\network adapter;Drivers\Video »
NOTE
Si vous ne souhaitez pas que les pilotes fournis par l’OEM restent sur le volume une fois le mini-Assistant
terminé, vous pouvez ajouter la structure de dossiers que vous avez créée à l’étape précédente sous le dossier
Sysprep. Vous devez ajuster la clé OemPnPDriversPath = de manière appropriée. Le dossier Sysprep et ses sous-
dossiers sont automatiquement supprimés une fois l’installation terminée.
Enregistrez le fichier Sysprep.inf dans le dossier Sysprep, puis exécutez Sysprep.exe. Tous les périphériques Plug-
and-Play sont automatiquement installés pendant l’Assistant de mini-installation sur les ordinateurs cibles. (Ces
fichiers incluent ceux trouvés à l’aide des fichiers .inf du pilote OEM.)
NOTE
Vous n’avez pas besoin de spécifier le commutateur de ligne de commande -pnp, sauf s’il existe des appareils isa
précédents sur les ordinateurs cibles. Si vous utilisez le commutateur de ligne de commande -pnp, une nouvelle
éumération Plug-and-Play complète de tous les appareils est effectuée, qui ajoute 5 à 10 minutes au processus du mini-
Assistant Sysprep. En outre, si vous spécifiez des contrôleurs de stockage de masse supplémentaires à l’aide de Sysprep
version 1.1 ou ultérieure, le commutateur de ligne de commande -pnp peut entraîner l’apparition de certains contrôleurs
de disque dur supplémentaires dans le Gestionnaire de périphériques.
Si les pilotes fournis par l’OEM ne sont pas signés numériquement, le mini-Assistant reporte l’installation de l’appareil
jusqu’à ce qu’un administrateur se connecte à l’ordinateur. Il s’agit de l’installation côté client ou côté serveur qui se
produit lors de l’installation d’un mini-Assistant.
Installations RIS
L’ajout de pilotes plug-and-play OEM à des installations RIS implique les mêmes étapes que dans la section «
Installation sans surveillance », avec deux petits ajustements :
1. Placez le $oem$ au même niveau que le dossier \I386 de l’image RIS. Par exemple, utilisez la structure de
dossiers suivante :
RemoteInstall\Setup % language\Images % dir_name%\i386

RemoteInstall\Setup % language\Images % dir_name% $ oem$ $ 1\Drivers
adaptateur \network
\MODEM
\VIDEO
2. Modifiez le modèle par défaut de l’image RIS (Ristndrd.sif). Dans la section [Sans surveillance], modifiez
la valeur de clé OemPreinstall = de Non à Oui, puis ajoutez les entrées OemPnPDriversPath =
Driver_Path. Vous pouvez énumérer plusieurs chemins d’accès dans cette clé en les séparant par un point-
virgule (;) comme illustré dans l’exemple suivant.
[Sans surveillance]
OemPreinstall = Oui
NOTE
Si l’un des pilotes fournis par L’OEM est pour un périphérique de carte réseau, le serveur RIS doit avoir ce fichier
disponible au redémarrage en mode texte.
3. Si vous copiez la carte réseau ou les pilotes de stockage de masse supplémentaires dans le dossier \i386
comme décrit dans l’article de la Base de connaissances 246184, arrêtez et redémarrez le service BINL
sur le serveur RIS. Pour arrêter et redémarrer le service BINL, tapez les commandes suivantes à l’invite de
commandes, puis appuyez sur Entrée après chaque commande :
net stop « boot information negotiation layer »
net start « boot information negotiation layer »
Images DePérég
Ces deux fonctionnalités sont en grande partie identiques. Par conséquent, l’ajout de pilotes plug-and-play OEM
à des ordinateurs qui seront représentés implique des étapes semblables à celles utilisées pour Sysprep. Avant
d’exécuter Contrôlerep sur l’ordinateur image pour le copier sur le serveur RIS, suivez les étapes suivantes :
1. Créez un dossier nommé Sysprep dans le dossier %SystemDrive%.. (Il s’agit très probablement du lecteur
C, Riprep.exe ne peut copier qu’un seul volume/partition.)
2. À la racine du même volume, créez une structure de dossiers pour contenir les pilotes fournis par le OEM
comme suit :
\Drivers
- - \VIDEO
\Sysprep
\WINNT
3. Copiez les pilotes fournis par le OEM dans leurs sous-folders appropriés.
4. Créez un fichier Sysprep.inf dans le dossier Sysprep, puis ajoutez les entrées [Sans surveillance] et
OemPnPDriversPath = Driver_Path. Vous pouvez énumérer plusieurs chemins d’accès dans cette clé en
les séparant par un point-virgule (;). Par exemple :
[Sans surveillance]
OemPnPDriversPath = « Drivers\network adapter;Drivers\Video »
NOTE
La variable d’environnement %SystemDrive% est automatiquement insérée avant chacun des chemins de
recherche répertoriés spécifiés.
Si l’appareil a déjà été reconnu par le système d’exploitation en tant qu’appareil connu ou inconnu, vous devez le
supprimer à l’aide du Gestionnaire de périphériques avant d’exécuter Sysprep ou les pilotes mis à jour ne sont pas
installés au démarrage pendant la mini-installation.
5. Exécutez le programme Riprep.exe à partir du dossier \ RisSer ver \Reminst\Admin\I386 sur l’ordinateur
client pour copier l’image sur le serveur RIS sélectionné. Il recherche un fichier Sysprep.inf dans le dossier
Sysprep, lit la clé OemPnPDriversPath= et met à jour la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Devicepath Then,Érrep copies the registry
up to the server so that it can be used during the mini-Setup wizard.
NOTE
L’entrée dans le fichier Sysprep.inf qui a été créé au cours des étapes précédentes n’affecte pas le fichier Par défaut
Derrep.sif créé au cours de ce processus.
NOTE
Si l’un des pilotes fournis par L’OEM est pour la carte réseau principale, le serveur RIS doit également avoir ce
fichier disponible à partir d’une image plate RIS classique avant le téléchargement de l’image Derrep.
Si l’image est déjà créée et que vous souhaitez ajouter des pilotes Plug-and-Play fournis par l’OEM, nous vous
recommandons d’utiliser RIS pour télécharger l’image sur un ordinateur, de suivre les étapes répertoriées dans la
section précédente « Images Derrep », puis de remettre l’image sur le serveur RIS.
L’un des effets secondaires est que les chemins d’accès du pilote sont entrés deux fois dans la clé
Software\Microsoft\Windows\CurrentVersion\DevicePath.

Vous de devez peut-être ajouter de nouveaux périphériques matériels à des ordinateurs Windows existants qui
nécessitent des pilotes fournis par le OEM. Bien que ce processus nécessite l’installation du nouvel appareil,
vous souhaitez peut-être que les pilotes fournis par l’OEM soient distribués de manière contrôlée ou qu’ils
soient situés de manière centralisée sur un serveur. Pour cela, procédez comme suit :
1. Déterminez si vous souhaitez copier les pilotes localement ou si vous souhaitez les stocker sur un serveur
de distribution central. Si vous souhaitez stocker les pilotes localement sur le disque dur de l’ordinateur,
vous devez avoir une procédure pour copier les pilotes sur l’ordinateur. (Par exemple, utilisez des scripts
d’accès, des travaux de lots Microsoft Systems Management Server (SMS) ou d’autres méthodes.)
2. Une fois la méthode de distribution déterminée, obtenez le chemin d’accès des pilotes de périphérique. Si
vous souhaitez les copier localement, le chemin d’accès peut être C:\Drivers\network. Si vous souhaitez
qu’ils soient copiés sur un serveur central, le chemin d’accès peut être Pilote de nom de serveur \ncarte
de travail \ \ \ (où Drivers est un dossier partagé).
3. La clé DevicePath dans le Registre de l’ordinateur local doit être mise à jour pour refléter les nouveaux
emplacements de pilotes OEM. Vous devez avoir une méthode automatisée de mise à jour à distance de
la clé de Registre. Vous pouvez utiliser des fichiers Regedit avec des scripts d' logon ou avec un traitement
par lots SMS. La valeur par défaut se trouve dans la clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath:
REG_EXPAND_SZ:%SystemRoot%\Inf
4. Modifiez la clé DevicePath à l'Regedt32.exe de sorte que le chemin d’accès où se trouvent les pilotes soit
inclus dans le chemin de recherche.
IMPORTANT
Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations sur la façon de la back up et de la
restauration du Registre, cliquez sur le numéro d’article suivant pour afficher l’article de la Base de connaissances
Microsoft : 322756 How to back up and restore the Registry in Windows
Par exemple, si les pilotes sont copiés localement à la racine du lecteur où réside le dossier %WinDir%
(adaptateur Etwork Drivers\n), la valeur finale de DevicePath doit être lue :
DevicePath: REG_EXPAND_SZ:%SystemRoot%\Inf;%SystemRoot%\Drivers\network adapter Si les pilotes sont
conservés sur un serveur central ou un point de distribution, vous devez ajouter le chemin d’accès UNC
aux pilotes fournis par le OEM. Par exemple :
DevicePath : REG_EXPAND_SZ:%SystemRoot%\Inf; \ \ Ser verName \ ShareName \Drivers\network
adapter
NOTE
%SystemRoot% n’est pas ajouté automatiquement, car le processus d’installation n’ajoute pas les valeurs. Vous
devez taper manuellement la valeur de %SystemRoot% si vous modifiez le Registre.
Une fois ces étapes effectuées et le nouveau matériel installé, lorsqu’un utilisateur se connecte, Plug-and-Play
localise le nouveau matériel et recherche les chemins d’accès des appareils que vous avez spécifiés pour
localiser les pilotes fournis par le OEM. Notez que toutes les règles qui s’appliquent aux pilotes signés/non
signés s’appliquent également aux appareils installés après l’installation. Si les pilotes fournis par le OEM pour le
nouvel appareil ne sont pas signés numériquement et qu’un utilisateur non administrateur se connecte à
l’ordinateur après l’installation du nouveau matériel, l’utilisateur ne peut pas terminer l’installation de l’appareil
tant qu’un administrateur ne s’est pas connecté à l’ordinateur.
NOTE
supprimer via le Gestionnaire de périphériques avant d’exécuter Sysprep ou que les pilotes mis à jour soient installés au
démarrage pendant la mini-installation.
Pour Windows Server 2003

Configuration sans surveillance
Lorsque vous ajoutez des pilotes au programme d’installation sans surveillance, suivez ces étapes. Si les pilotes
fournis par l’OEM ne sont pas signés numériquement, vous pouvez recevoir un message concernant les pilotes
1. Créez votre partage de distribution sur un serveur en copiant le contenu du CD-ROM I386
Windows’installation. Vous pouvez utiliser Setupmgr.exe pour créer ce partage et votre Unattended.txt
fichier. Vous trouverez Setupmgr.exe sur le CD-ROM Windows ou Service Pack dans le dossier
Support\Tools du fichier Deploy.cab et les fichiers d’aide deploy.chm et ref.chm qui contiennent des
informations sur le programme d’installation Windows sans assistance. Vous pouvez également
télécharger les fichiers les plus récents à partir du site Web Microsoft.
2. Créez un $oem$ $ 1\Drivers dans le dossier I386. Vous pouvez créer des dossiers supplémentaires dans
le sous-dossier Pilotes, en fonction du matériel que vous souhaitez installer (par exemple, carte réseau,
modem ou vidéo). Le dossier $1 est résolu en %SystemDrive%. Lors de l’installation en mode texte, ces
dossiers et fichiers sont copiés dans les dossiers %SystemDrive%\Drivers. Par exemple :
\i386
$oem$
- - $1
- - - \Drivers
- - - - - \network adapter
- - - - - \MODEM
- - - - - \VIDEO
3. Copiez tous les fichiers de pilotes fournis par le OEM pour l’appareil dans les dossiers que vous avez
créés à l’étape précédente.
4. Ajoutez l’entrée OemPnPDriversPath = Driver_Paths dans la section [Sans surveillance] du fichier de
réponses du programme d’installation. Vous pouvez énumérer plusieurs chemins d’accès dans cette clé
en les séparant par un point-virgule (;). Par exemple :
[Sans surveillance]
OemPnPDriversPath = Drivers\network adapter;Drivers\Modem;Drivers\Video
UpdateInstalledDrivers = Yes | Non
NOTE
5. Enregistrez le fichier de réponses.

Lors de l’installation en mode GUI lorsque le système recherche des ID plug-and-play dans les fichiers .inf, il
recherche également les chemins d’accès indiqués dans OemPnPDriversPath et le chemin d’accès par défaut
standard de %WinDir%\Inf. Le chemin d’accès %WinDir%\Inf est répertorié en premier dans l’ordre de
recherche, mais si vous disposez d’un appareil pris en charge par plusieurs fichiers .inf (Windows peut inclure
un pilote offrant une fonctionnalité générique), le programme d’installation continue de rechercher tous les
chemins d’accès spécifiés dans l’entrée OemPnPDriversPath. Bien qu’il puisse trouver plusieurs
correspondances, Plug-and-Play utilise le fichier .inf qui a la meilleure correspondance, puis installe le pilote de
périphérique associé pour prendre en charge l’appareil.
Configuration de Sysprep
Les étapes d’ajout de pilotes OEM à un programme d’installation Sysprep Windows ressemblent aux étapes de
la section « Installation sans surveillance », sauf que vous n’avez pas besoin de créer le partage de distribution.
Pour ajouter des pilotes à l’assistant mini-Sysprep, suivez ces étapes.
NOTE
Nous vous recommandons d’utiliser la dernière version de Sysprep disponible pour votre système d’exploitation.
1. À la racine du volume où se trouve le dossier %WinDir%, créez une structure de dossiers pour contenir
les pilotes fournis par le OEM. Par exemple :
\Drivers
- - \VIDEO
\Sysprep
\WINNT
3. Ajoutez l’entrée OemPnPDriversPath = Driver_Paths dans la section [Sans surveillance] du fichier
Sysprep.inf. Vous pouvez énumérer plusieurs chemins d’accès dans cette clé en les séparant par un point-
virgule (;). Par exemple :
[Sans surveillance]
OemPnPDriversPath = Drivers\network adapter;Drivers\Video UpdateInstalledDrivers = Yes | Non
NOTE
Si vous ne souhaitez pas que les pilotes fournis par le OEM restent sur le volume une fois le mini-Assistant
terminé, vous pouvez ajouter la structure de dossiers que vous avez créée à l’étape précédente sous le dossier
Sysprep. Vous devez ajuster la clé OemPnPDriversPath = de manière appropriée. Le dossier Sysprep (et ses
sous-dossiers) est automatiquement supprimé une fois l’installation terminée.
Enregistrez le fichier Sysprep.inf dans le dossier Sysprep et exécutez Sysprep.exe. Tous les périphériques Plug-
and-Play (y compris ceux trouvés à l’aide des fichiers .inf du pilote OEM) sont automatiquement installés
pendant l’Assistant de mini-installation sur les ordinateurs cibles. Notez que vous n’avez pas besoin de spécifier
le commutateur de ligne de commande -pnp, sauf s’il existe des périphériques isa précédents sur les ordinateurs
cibles. Si vous utilisez le commutateur de ligne de commande -pnp, une nouvelle éumération Plug-and-Play
complète de tous les appareils est effectuée, ce qui ajoute 5 à 10 minutes au processus du mini-Assistant
Sysprep. En outre, si vous spécifiez un contrôleur de stockage de masse supplémentaire, le commutateur de
ligne de commande -pnp peut entraîner l’apparition de certains contrôleurs de disque dur supplémentaires
dans le Gestionnaire de périphériques.
NOTE
Si les pilotes fournis par l’OEM ne sont pas signés numériquement, le mini-Assistant reporte l’installation de l’appareil
jusqu’à ce qu’un administrateur se connecte à l’ordinateur. Il s’agit de l’installation côté client ou côté serveur qui se
produit lors de l’installation d’un mini-Assistant.
Installations RIS
L’ajout de pilotes plug-and-play OEM à des installations RIS implique les mêmes étapes que dans la section «
Installation sans surveillance », avec deux petits ajustements :
1. Placez le $oem$ au même niveau que le dossier \I386 de l’image RIS. Par exemple, utilisez la structure
suivante :
RemoteInstall\Setup % language\Images % dir_name%\i386

RemoteInstall\Setup % language\Images % dir_name% $ oem$ $ 1\Drivers
adaptateur \network
\MODEM
\VIDEO
2. Modifiez le modèle par défaut de l’image RIS (Ristndrd.sif). Dans la section [Sans surveillance], modifiez
la valeur de clé OemPreinstall = de Non à Oui, puis ajoutez les entrées OemPnPDriversPath =
Driver_Path. Vous pouvez énumérer plusieurs chemins d’accès dans cette clé en les séparant par un point-
virgule (;) comme suit :
[Sans surveillance]
OemPreinstall = Oui
UpdateInstalledDrivers = Oui | Non
NOTE
d’accès de recherche répertoriés.
NOTE
Si l’un des pilotes fournis par L’OEM est pour un périphérique de carte réseau, le serveur RIS doit avoir ce fichier
disponible au redémarrage en mode texte.
3. Si vous copiez la carte réseau ou les pilotes de stockage de masse supplémentaires dans le dossier \i386
comme décrit dans l’article de la Base de connaissances 246184, arrêtez et redémarrez le service BINL
sur le serveur RIS. Pour arrêter et redémarrer le service BINL, tapez les commandes suivantes à l’invite de
commandes, puis appuyez sur Entrée après chaque commande :
net stop « boot information negotiation layer »
net start « boot information negotiation layer »
Images DePérég
Ces deux fonctionnalités sont en grande partie identiques. Par conséquent, l’ajout de pilotes plug-and-play OEM
à des ordinateurs qui seront représentés implique des étapes semblables à celles utilisées pour Sysprep. Avant
d’exécuter Contrôlerep sur l’ordinateur image pour le copier sur le serveur RIS, suivez les étapes suivantes :
1. Créez un dossier nommé Sysprep dans le dossier %SystemDrive%.. (Il s’agit très probablement du lecteur
C, Riprep.exe ne peut copier qu’un seul volume ou partition.)
2. À la racine du même volume, créez une structure de dossiers pour contenir les pilotes fournis par le OEM
comme suit :
\Drivers
- - \VIDEO
\Sysprep
\WINNT
4. Créez un fichier Sysprep.inf dans le dossier Sysprep, puis ajoutez les entrées [Sans surveillance] et
OemPnPDriversPath = Driver_Path. Vous pouvez énumérer plusieurs chemins d’accès dans cette clé en
les séparant par un point-virgule (;) comme suit :
[Sans surveillance]
OemPnPDriversPath = Drivers\network adapter;Drivers\Video UpdateInstalledDrivers = Yes | Non
NOTE
La variable d’environnement %SystemDrive% est automatiquement insérée avant chacun des chemins de
recherche répertoriés spécifiés.
NOTE
supprimer via le Gestionnaire de périphériques avant d’exécuter Sysprep ou les pilotes mis à jour ne sont pas
installés au démarrage pendant la mini-installation.
5. Exécutez le programme Riprep.exe à partir du dossier \ \ RisSer ver \Reminst\Admin\I386 sur

l’ordinateur client pour copier l’image sur le serveur RIS sélectionné. Ce dernier recherche un fichier
Sysprep.inf dans le dossier Sysprep.inf, lit la clé OemPnPDriversPath= et met à jour la sous-clé de
Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Devicepath
Then,Érrep copies the registry up to the server so that it can be used during the mini-Setup wizard.
NOTE
L’entrée dans le fichier Sysprep.inf qui a été créé au cours des étapes précédentes n’affecte pas le fichier Par défaut
Derrep.sif créé au cours de ce processus.

Vous de devez peut-être ajouter de nouveaux périphériques matériels à des ordinateurs Windows existants qui
nécessitent des pilotes fournis par le OEM. Bien que ce processus nécessite l’installation du nouvel appareil,
vous souhaitez peut-être que les pilotes fournis par l’OEM soient distribués de manière contrôlée ou qu’ils
soient situés de manière centralisée sur un serveur. Pour cela, procédez comme suit :
1. Déterminez si vous souhaitez copier les pilotes localement ou si vous souhaitez les stocker sur un serveur
de distribution central. Si vous souhaitez stocker les pilotes localement sur le disque dur de l’ordinateur,
vous devez avoir une procédure pour copier les pilotes sur l’ordinateur. Par exemple, utilisez des scripts
d’accès, des travaux de lots Microsoft Systems Management Server (SMS) ou d’autres méthodes.
2. Une fois la méthode de distribution déterminée, obtenez le chemin d’accès des pilotes de périphérique. Si
vous souhaitez les copier localement, le chemin d’accès peut être C:\Drivers\network. Si vous souhaitez
qu’ils soient copiés sur un serveur central, le chemin d’accès peut être \ \ \n \ carte de travail. (Les
pilotes sont un dossier partagé.)
3. La clé DevicePath dans le Registre de l’ordinateur local doit être mise à jour pour refléter les nouveaux
emplacements de pilotes OEM. Vous devez avoir une méthode automatisée de mise à jour à distance de
la clé de Registre. Vous pouvez utiliser des fichiers Regedit avec des scripts d' logon ou avec un traitement
par lots SMS. La valeur par défaut se trouve dans la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath:
REG_EXPAND_SZ:%SystemRoot%\Inf
4. Modifiez la clé DevicePath à l’aide de l’Éditeur du Registre afin que le chemin d’accès où se trouvent les
pilotes soit inclus dans le chemin de recherche.
IMPORTANT
Vous pouvez alors le restaurer en cas de problème. Pour plus d’informations sur la façon de la back up et de la
restauration du Registre, cliquez sur le numéro d’article suivant pour afficher l’article de la Base de connaissances
Microsoft : 322756 How to back up and restore the Registry in Windows
Par exemple, si les pilotes sont copiés localement à la racine du lecteur où réside le dossier %WinDir%
(carte etwork Drivers\n), la valeur finale devicePath doit être lue comme suit :
DevicePath: REG_EXPAND_SZ:%SystemRoot%\Inf;%SystemRoot%\Drivers\network adapter Si les pilotes sont
conservés sur un serveur central ou un point de distribution, vous devez ajouter le chemin d’accès UNC
aux pilotes fournis par le OEM. Par exemple :
DevicePath: REG_EXPAND_SZ:%SystemRoot%\Inf;\\\\**ServerName**\\**ShareName**\Drivers\network adapter
NOTE
%SystemRoot% n’est pas ajouté automatiquement, car le processus d’installation n’ajoute pas les valeurs. Vous
devez taper manuellement la valeur de %SystemRoot% si vous modifiez le Registre.
Supposons que vous avez effectué ces étapes et que de nouveaux matériels sont installés. Lorsqu’un utilisateur
se connecte, Plug-and-Play localise le nouveau matériel et recherche les chemins d’accès de l’appareil que vous
avez spécifiés pour localiser les pilotes fournis par le OEM. Notez que toutes les règles qui s’appliquent aux
pilotes signés et non signés s’appliquent également aux appareils installés après l’installation. Supposons que
les pilotes fournis par l’OEM pour le nouvel appareil ne soient pas signés numériquement et qu’un utilisateur
non administrateur se connecte à l’ordinateur après l’installation du nouveau matériel. Dans ce cas, l’utilisateur
ne peut pas terminer l’installation de l’appareil tant qu’un administrateur ne se connecte pas à l’ordinateur.
NOTE
Si l’appareil a déjà été reconnu par le système d’exploitation comme un appareil connu ou inconnu, vous devez le
supprimer à l’aide du Gestionnaire de périphériques avant d’exécuter Sysprep ou que les pilotes mis à jour soient installés
au démarrage pendant la mini-installation.
Comment éviter les GUID en double lorsque vous
imagez des ordinateurs clients System Management
Server 2003
Cet article explique comment éviter les doublons d’identificateurs globaux uniques (GUID) lorsque vous utilisez
l’imagerie ou le clonage de disque pour déployer les clients Microsoft Systems Management Server (SMS)
2003.
IMPORTANT
et assurez-vous que vous savez le restaurer en cas de problème. Pour plus d’informations sur la façon de restaurer, de
restaurer et de modifier le Registre, cliquez sur le numéro d’article suivant pour afficher l’article de la Base de
connaissances Microsoft : 256986 Description du Registre Microsoft Windows
Dans SMS 2003, tous les clients sont identifiés de manière unique par un GUID. Un GUID est une combinaison
de l’adresse MAC (Media Access Control) du client et de l’heure à quel moment le GUID est affecté. Cette
combinaison produit un nombre qui est presque toujours unique. L’affectation de GUID se produit pendant les
processus de découverte et d’installation du client SMS 2003.
Le GUID est stocké dans le Registre du client et dans un fichier binaire sur le disque dur du client. De nombreux
problèmes dans un environnement SMS 2003 peuvent se produire si plusieurs clients SMS 2003 ont le même
GUID. L’intégralité du site peut même être désactivée. Si vous utilisez un logiciel de duplication de disque, vous
devez vous assurer que les GUID clients SMS 2003 ne sont pas dupliqués lors de la copie ou de l’imagerie.
Pour dupliquer un disque, vous créez une image maître à partir d’un ordinateur hôte, puis vous déployez (ou
copiez) l’image maître sur d’autres ordinateurs. La duplication de disque permet de s’assurer que les paramètres
du système d’exploitation et du programme de chaque ordinateur sont identiques. Le client hérité SMS 2003 et
le client avancé SMS 2003 utilisent différentes méthodes pour éviter la duplication des GUID lorsque vous
dupliquer des disques durs pour le déploiement du client SMS 2003.
Préparation de l’ordinateur client hérité SMS 2003 pour l’imagerie
WARNING
Pour préparer l’ordinateur image maître à la duplication et éviter les GUID en double pour le client hérité SMS
2003 :
1. Utilisez l’Assistant Installation Push SMS pour installer le logiciel client sur l’ordinateur client master-
image :
a. Cliquez sur Démarrer, pointez sur Programmes, cliquez sur Systems Management Ser ver,
puis sur Console d’administrateur SMS.
b. Développez base de données de sites, développez Collections, puis développez Tous les
systèmes.
c. Dans le volet droit, cliquez avec le bouton droit sur un client SMS 2003 découvert, cliquez sur
Toutes les tâches, puis cliquez sur Installer le client.
d. Dans l’écran d’accueil de l’Assistant Installation Push client, cliquez sur Suivant.
e. Dans l’écran Options d’installation, cliquez sur Installer le client SMS, puis cliquez sur Client
hérité.
f. Dans l’écran Options du client, vous pouvez sélectionner une ou plusieurs des options suivantes
:
Inclure des contrôleurs de domaine
Inclure uniquement les clients affectés à ce site
Inclure des sous-collections
Toujours installer (réparer ou mettre à niveau le client existant)
g. Cliquez sur Suivant , puis sur Terminer .
2. Redémarrez l’ordinateur client, puis connectez-vous en tant qu’administrateur.
3. Sur l’ordinateur client master-image, utilisez l’Éditeur du Registre pour supprimer la valeur de Registre
d’identificateur unique SMS :
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez Regedit dans la zone Ouvrir, puis cliquez sur
OK.
b. Recherchez la clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client Properties
c. Cliquez avec le bouton droit sur la valeur de Registre de l’identificateur unique SMS, puis cliquez
sur Supprimer.
4. Supprimez toutes les copies du fichier Smsuid.dat du disque dur de l’ordinateur image maître.
5. Supprimez le fichier %SystemRoot%\Smscfg.ini.
6. Utilisez l’Éditeur du Registre pour supprimer toutes les clés sous la valeur de Registre AbExprtDB :
a. Cliquez sur Démarrer, cliquez sur Exécuter, tapez Regedit dans la zone Ouvrir, puis cliquez sur
OK.
b. Recherchez la clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NAL\Client\AbExprtDB
c. Supprimez toutes les clés de Registre sous la valeur de Registre AbExpr tDB.
Préparation de l’ordinateur client avancé SMS 2003 pour l’imagerie
Vous pouvez préparer les ordinateurs clients avancés SMS 2003 pour la création d’images lorsque vous installez
les composants principaux de SMS 2003 Advanced Client sur l’ordinateur image maître sans spécifier de code
de site SMS 2003 pour l’affectation. Tous les ordinateurs qui sont imageés ultérieurement à partir de cette
image maître contiendra les composants principaux du client avancés sans code de site. Toutefois, les
ordinateurs image ne seront pas des clients SMS 2003 fonctionnels tant que les clients SMS 2003 ne seront pas
affectés à un site SMS 2003.
Pour préparer l’ordinateur client avancé SMS 2003 pour l’imagerie :
1. Désignez un ordinateur maître. L’ordinateur maître est l’ordinateur qui sera dupliqué sur les ordinateurs
clients de destination.
2. Sur l’ordinateur maître, utilisez l’utilitaireCCMSetup.exe pour installer le client avancé à partir du
dossier \\ SiteServer \SMSClient\i386.
3. Une fois le client avancé installé, assurez-vous que le service hôte d’agent SMS (Ccmexec.exe) n’est pas en
cours d’exécution sur l’ordinateur maître. Pour ce faire, tapez la commande suivante à l’invite de
commandes :
net stop ccmexec
4. Sur l’ordinateur maître, exécutez l’utilitaireCCMDelCer t.exe pour supprimer les certificats du client
avancé.
NOTE
LCCMDelCert.exe'utilitaire fait partie de Systems Management Server 2003 Shared Computer Toolkit 2. Pour
obtenir ce kit de ressources, visitez le site Web Microsoft suivant : documentation Microsoft et formation pour les
développeurs et les professionnels de la technologie
5. Créez l’image de l’ordinateur maître à l’aide de votre logiciel d’imagerie.

6. Restituer l’image sur les ordinateurs de destination.
Références
Pour plus d’informations sur la résolution des problèmes d’installations Push client avancées, consultez l’article
suivant dans la Base de connaissances Microsoft :
928282 comment résoudre les problèmes d’installation push de client avancée dans Systems Management
Server 2003 et System Center Configuration Manager 2007
Can’t open EXE files
Cet article fournit une solution au problème qui vous permet d’obtenir des erreurs lors de l’ouverture de fichiers
exe.
Symptômes
Lorsque vous essayez d’ouvrir des fichiers EXE, vous pouvez obtenir des messages d’erreur tels que : « Refus
d’accès », « Erreur d’runtime », etc.
Cause
Les paramètres de Registre endommagés ou certains produits tiers (ou virus) peuvent modifier la configuration
par défaut pour l’exécution des fichiers EXE. L’opération peut échouer lorsque vous essayez d’exécuter des
fichiers EXE.
Résolution
1. Cliquez sur Démarrer, puis sélectionnez Exécuter.
2. Tapez "command.com" , puis appuyez sur Entrée. (Une fenêtre DOS s’ouvre.)
3. Tapez les lignes de commande suivantes :
cd\
cd \windows
Appuyez sur Entrée après avoir tapé chacun d’eux.

4. Tapez « regedit.exe regedit.com », puis appuyez sur Entrée.
5. Tapez « démarrer regedit.com » et appuyez sur Entrée.
6. Accédez à la clé et sélectionnez-la :
HKEY_CLASSES_ROOT\exefile\shell\open\command
7. Dans le volet droit, double-cliquez sur la valeur (par défaut).

8. Supprimez les données de la valeur actuelle, puis tapez :
"%1" %*
Conseil : tapez les caractères : quote-percent-one-quote-space-percent-asterisk.
9. Fermez l’utilitaire Regedit.
NOTE
Si vous utilisez Windows XP et que vous activez la restauration du système, vous devez désactiver « Restauration
système » en « mode Coffre » avant d’utiliser les instructions ci-dessus.

Les dictionnaires IME chinois indiquent « pas encore
prêt » dans Windows Server 2022
Cet article fournit une solution de contournement pour résoudre le problème qui se produit lorsqu’un
utilisateur Standard active les dispositions du clavier chinois.
Erreur : les dictionnaires IME chinois ne sont pas encore prêts

Dans Windows Server 2022, lorsqu’un utilisateur Standard active une disposition de clavier en chinois, telle que
le chinois (simplifié, chine), chinois (traditionnel, HongKong R.A.S.) ou chinois (traditionnel , Taïwan),
l’utilisateur ne peut pas entrer de caractères chinois et voit un message d’erreur semblable au suivant :
Les dictionnaires IME chinois simplifiés ne sont pas encore prêts.

Veuillez vérifier l’état à partir du paramètre de langue.
Le problème se produit car les dictionnaires IME chinois sont inclus dans le package de saisie de base des
fonctionnalités à la demande (FOD) au lieu de Windows fichiers image.
NOTE
L’ajout du package de saisie de base des foDs nécessite l’autorisation de l’administrateur.
Solutions de contournement
Pour contourner le problème, utilisez l’une des méthodes suivantes en tant qu’administrateur :
Pour contourner le problème à l’utilisation de la commande hors connexion, suivez les étapes suivantes :
1. Exécutez la commande DISM (Deployment Image Servicing and Management) suivante dans votre
fenêtre d’invite de commandes pour monter Windows image :
md C:\mount\windows
Dism /Mount-Image /ImageFile:install.wim /Index:1 /MountDir:"C:\mount\windows"
2. Ajoutez le package FODs en exécutant la commande

Dism /Image:"C:\mount\windows" /Add-Package /PackagePath:"<FilePath>\<PackageName>.cab" dans
votre fenêtre d’invite de commandes. Par exemple :
Dism /Image:"C:\mount\windows" /Add-Package

/PackagePath:"C:\users\Administrator\Desktop\Microsoft-Windows-LanguageFeatures-Basic-zh-cn-
Package~31bf3856ad364e35~amd64~~.cab"
3. Démontez l’image en exécutant la commande suivante dans votre fenêtre d’invite de

commandes :
Dism /Unmount-Image /MountDir:C:\mount\windows /Commit

Pour contourner le problème à l’aide de la commande en ligne,
exécutez la commande dans
Dism /online /Add-Package /PackagePath:"<FilePath>\<PackageName>.cab"
votre fenêtre d’invite de commandes pour ajouter des FOD. Par exemple :
Dism /online /Add-Package /PackagePath:"C:\users\Administrator\Desktop\Microsoft-Windows-

LanguageFeatures-Basic-zh-cn-Package~31bf3856ad364e35~amd64~~.cab"
NOTE
Lorsque vous exécutez la commande, utilisez votre propre chemin d’accès et le package cab que vous avez
téléchargé.
Ajouter des langues à Windows images
Ajout ou suppression de fonctionnalités à la demande
Les utilisateurs de domaine ne peuvent pas taper
chinois (simplifié) dans Windows Server 2016
Cet article permet de résoudre un problème dans lequel Windows continue à taper et à s’afficher en anglais
lorsqu’un utilisateur de domaine utilise la méthode d’entrée en chinois (simplifié).
Symptômes
Dans un domaine, un utilisateur se connecte à un ordinateur Windows Server 2016 et définisse la langue par
défaut sur Chinois (simplifié) dans le Panneau de contrôle. Lorsque l’utilisateur tente de taper à l’aide de la
méthode d’entrée en chinois, Windows continue à taper et à s’afficher en anglais.
NOTE
Ce problème se produit uniquement avec la méthode d’entrée en chinois (simplifié). Les autres méthodes d’entrée des
langues, telles que le chinois (traditionnel), fonctionnent parfaitement.
Cause
Ce problème se produit car la clé de Registre suivante est manquante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LexiconUpdate\loc_0804
Résolution
2. Recherchez HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft et créez une clé nommée LexiconUpdate.
3. Créez une clé sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LexiconUpdate et nommez-la loc_0804 .
Créer une image ISO pour les plateformes UEFI
pour Windows CD-ROM PE
Cet article explique comment créer une image ISO pour les plateformes UEFI pour Windows CD-ROM PE.
Introduction
Cet article explique comment créer une image ISO (International Standards Organization) pour un CD-ROM
Windows Preinstallation Environment (Windows PE). Ce CD-ROM démarre l’ordinateur à l’aide du
microprogramme UEFI (Unified Extensible Firmware Interface).
Vous avez installé l’une des configurations suivantes :
Kit Windows de préinstallation OEM (OPK) avec Windows Server
Le Kit d'installation automatisée (Windows AIK) (PROXYK) avec Windows Server
La plateforme cible est une version x64 (amd64) de Windows Server.
Le Windows pe CD-Rom peut être démarré à partir du microprogramme BIOS ou du microprogramme UEFI. Le
CD-ROM contient deux entrées de catalogue de démarrage. Une entrée d’ID de plateforme correspond au BIOS
et l’autre à l’UEFI.
Pour créer une image ISO pour Windows PE sur un CD-ROM, suivez les étapes suivantes :
1. Utilisez les informations d’identification d’administration pour vous connecter à un Windows Server.
2. Dans le menu Programmes, cliquez Windows kit de préinstallation OEM (OPK), puis cliquez sur
Windows’invite de commandes des outils PE.
3. Tapez copype.cmd amd64 winpe_x64, puis appuyez sur Entrée. Cette commande crée la structure du
répertoire et copie les fichiers requis.
4. Tapez winpe.wim .\ISO\sources\boot.wim, puis appuyez sur Entrée. Cette commande copie le fichier
winpe.wim créé sous winpe_x64 dans le dossier ISO\sources en tant que boot.wim.
oscdimg -m -o -u2 -udfver102 -

bootdata:2#p0,e,bc:\winpe_x64\etfsboot.com#pEF,e,bc:\winpe_x64\efisys.bin c:\winpe_x64\ISO
c:\winpe_x64\winpeuefi.iso
NOTE
Pour plus d’informations sur cette commande, voir la section « Définitions ».
6. Graver l’image ISO (Winpeuefi.iso) sur un CD ou un DVD.
Arguments de commande Oscdimg
m
Ignore la limite de taille maximale de l’image.
o
Optimise le stockage en encodant les fichiers en double une seule fois.
u2
Produit une image ISO qui ne dispose que du système de fichiers UDF (Universal Disk Format).
udfver102
Spécifie le format UDF version 1.02.
bootdata
Spécifie une image de redémarrage multiple. Cette image utilise un secteur de démarrage x86 comme image
par défaut. Ce secteur démarre le code Etfsboot.com démarrage. Une image de démarrage EFI secondaire
démarre une application de démarrage EFI.
c:\winpe_x64\ISO
Représente le chemin d’accès des fichiers pour l’image.
c:\winpe_x64\winpeuefi.iso
Représente le fichier image de sortie.
Arguments de commande Bootdata
2
Spécifie le nombre d’entrées de catalogue de démarrage.
#
Fonctionne comme séparateur entre les entrées racines à placer dans le catalogue de démarrage.
p0
Définit l’ID de plateforme sur 0 pour la première entrée de démarrage par défaut pour le BIOS.
e
Spécifie l’émulation de disquette dans le catalogue El Torito.
bc:\winpe_x64 \etfsboot.com
Place le fichier spécifié (Etfsboot.com) dans les secteurs de démarrage du disque.
#
Fonctionne comme séparateur entre la première et la deuxième entrée de démarrage.
pEF
Définit l’ID de plateforme sur « EF », tel que défini par la spécification UEFI.
bc:\winpe_x64\efisys.bin
Place le fichier spécifié (Efisys.bin) dans le secteur de démarrage du disque. Efisys.bin est la disposition de
disquette binaire du code de démarrage EFI. Cette image de disque contient les fichiers utilisés pour
démarrer à partir du microprogramme EFI dans le dossier Efi\boot\x64boot.efi.
Comment activer la journalisation dans WDS dans
Windows
Cet article explique comment activer la journalisation dans Windows Deployment Services (WDS) dans
Windows Server.
IMPORTANT
Introduction
Cet article explique comment activer la journalisation dans WDS dans Windows Server. En outre, cet article
explique comment collecter des données dans WDS.
Vous pouvez utiliser ces informations pour résoudre les problèmes que vous pouvez connaître dans WDS.
Présentation
WARNING
Chaque composant WDS dispose d’un mécanisme que vous pouvez activer pour la journalisation et le suivi.
Vous pouvez ensuite analyser les résultats pour la résolution des problèmes. Utilisez les informations des
sections suivantes pour activer la journalisation et le suivi des composants WDS.
État général du serveur WDS

Tapez la commande suivante pour générer des informations générales sur l’état du serveur :
WDSUTIL /get-server /show:all /detailed
Cette commande entraîne la journalisation des informations générales sur l’état du serveur dans le journal des
applications et dans le journal système.
Composant serveur WDS

Tapez la commande suivante pour générer des informations d’état d’état sur le composant serveur WDS :
Cette commande permet de consigner les informations WDS dans le journal des applications et dans le journal
système.
Obtenir les journaux de suivi pour Windows Server

Pour obtenir des informations de suivi pour Windows Server, faites les choses suivantes :
1. Ouvrez l’Obser vateur d’événements (eventvwr).
2. Accédez à Windows Journaux \ des applications et des ser vices \ Microsoft \ Windows \
Deployment-Ser vices-Diagnostics .
3. Cliquez avec le bouton droit sur le canal et choisissez Activer le journal.
Ensuite, configurez les composants que vous souhaitez journaliser en configurant une ou plusieurs des clés de
Registre suivantes sur une valeur de 0.
Multidiffusion WDS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSMC\TraceDisabled
WDS PXE
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE\TraceDisabled
WDS TFTP
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSTFTP\TraceDisabled
Les serveurs WDS supportent également le suivi supplémentaire suivant :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSTFTP\TraceFlags
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSMC\TraceFlags
Vous pouvez définir ces clés de Registre sur les valeurs suivantes pour contrôler ce qui est inclus :
7F0000 : cette valeur inclut le suivi des paquets et le suivi de protocole.
3F0000 : cette valeur exclut le suivi des paquets.
3E0000 : cette valeur exclut le suivi des paquets et le suivi de protocole. Par défaut, cette valeur est utilisée.
NOTE
Un processus de suivi peut affecter les performances. Par conséquent, nous vous recommandons de désactiver la
fonctionnalité de suivi lorsque vous n’avez pas besoin de générer de journal.
Une fois cette entrée de Registre définie, les informations de suivi du composant serveur WDS sont enregistrées
dans le fichier suivant : %windir% \ Tracing \ wdsserver.log
Composants de gestion WDS

Tapez la commande suivante pour générer des informations d’état du composant de gestion :
Cette commande permet de consigner les informations d’état du composant WDS dans le journal des
applications et dans le journal système.
Activation du suivi
Pour obtenir des informations de suivi, vous devez activer le suivi dans le composant de gestion WDS et dans le
composant MMC (Microsoft Management Console) WDS. Pour ce faire, définissez les entrées de Registre
suivantes :
Pour le composant de gestion
Chemin d’accès : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT
Nom : EnableFileTracing
Pour le composant MMC
Chemin d’accès : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC
Une fois ces entrées de Registre définies, les informations de suivi du composant de gestion WDS sont
enregistrées dans le fichier %windir% \ Tracing \ wdsmgmt.log.
En outre, les informations de suivi pour le composant MMC WDS sont enregistrées dans le fichier %windir% \
Tracing \ wdsmmc.log.
NOTE
Bien que le composant MMC WDS et le composant WDSUTIL partagent la même couche API, MMC ajoute parfois un
traitement et des fonctionnalités. Si une erreur se produit, il est souvent intéressant d’utiliser WDSUTIL pour essayer de
reproduire l’échec. WDSUTIL peut vous aider à déterminer si l’erreur est locale pour MMC ou si l’erreur est un échec de
l’API de gestion générale. Souvent, le composant WDSUTIL fournit une sortie d’erreur plus détaillée lorsque le suivi n’est
pas activé. Le cas échéant, utilisez les options suivantes pour obtenir des informations supplémentaires :
/detailed
/verbose
/progress
Composants hérités WDS

Si vous effectuez des fonctions de gestion héritées, définissez l’entrée de Registre suivante pour activer le suivi
dans le composant RISetup :
Chemin d’accès : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\RISetup
Pour obtenir le journal de suivi dans l’opération WDSCapture, suivez les étapes suivantes :
1. Démarrez l’image Windows de démarrage PE.
2. Lorsque l’Assistant Capture démarre, appuyez sur Shift+F10 pour ouvrir une invite de commandes.
3. Activez le suivi dans le composant WDSCapture. Pour cela, procédez comme suit :
b. Définissez l’entrée de Registre suivante pour activer le suivi dans le composant WDSCapture :
Chemin d’accès : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSCapture
4. Démarrez une deuxième instance du composant WDSCapture. Ensuite, reproduisez le problème à l’aide
de la deuxième instance de WDSCapture.
NOTE
Ne fermez pas l’instance d’origine de WDSCapture. Si vous fermez l’instance d’origine de WDSCapture, Windows pe
redémarre. Appuyez plutôt sur ALT+TAB pour basculer entre les instances de WDSCapture.Le fichier journal de suivi
suivant est généré : X : \ Windows \ Tracing \ WDSCapture.log.
Composants clients WDS

Pour activer la fonctionnalité de journalisation du client, exécutez la commande suivante sur le serveur WDS :
WDSUTIL /Set-Server /WDSClientLogging /Enabled:Yes
Ensuite, exécutez la commande suivante sur le serveur WDS pour modifier les événements qui sont enregistrés :
WDSUTIL /Set-Server /WDSClientLogging /LoggingLevel:{None|Errors|Warnings|Info}
NOTE
Chaque catégorie inclut tous les événements des catégories précédentes.
Les définitions des niveaux de journalisation sont les suivantes :

Le niveau de journalisation NONE désactive la fonctionnalité de journalisation. Par défaut, ce niveau de
journalisation est utilisé.
Le niveau de journalisation ERRORS enregistre uniquement les erreurs.
Le niveau de journalisation WARNINGS enregistre les avertissements et les erreurs.
Le niveau de journalisation INFO enregistre les erreurs, les avertissements et les événements
d’information. Ce niveau de journalisation est le niveau de journalisation le plus élevé.
Pour afficher les journaux des événements, suivez les étapes suivantes :
1. Ouvrez le Gestionnaire de serveur, puis cliquez sur Diagnostics.
2. Cliquez sur Obser vateur d’événements.
3. Cliquez sur Journaux des applications et des ser vices.
4. Cliquez sur Microsoft, sur Windows, puis sur Deployment-Ser vices-Diagnostics .
Dans l’arborescence des journaux des événements, le journal d’administration contient toutes les erreurs et le
journal des opérations contient les messages d’informations. Voici les définitions des architectures répertoriées
pour certaines erreurs dans ces journaux :
Architecture 0 est l’architecture du processeur x86.
Architecture 6 est l’architecture du processeur IA-64.
Architecture 9 est l’architecture du processeur x64.
Journaux d’installation à partir de l’ordinateur client

L’emplacement des journaux d’installation dépend du moment où l’échec se produit.
Si l’échec se produit dans Windows PE avant la fin de la page de configuration du disque du client WDS, les
journaux se trouvent dans le dossier X: \ Windows \ Panther. Utilisez Shift+F10 pour ouvrir une invite de
commandes, puis modifiez le répertoire à l’emplacement.
Si la défaillance se produit dans Windows PE une fois la page de configuration de disque du client WDS
terminée, vous pouvez trouver les journaux sur le volume de disque local dans le dossier $Windows.~BT \
Sources \ Panther. Le volume de disque local est généralement le lecteur C . Utilisez Shift+F10 pour ouvrir
une invite de commandes, puis modifiez le répertoire à l’emplacement.
Si l’échec se produit au premier démarrage après l’application de l’image, vous pouvez trouver les journaux
dans le dossier \ Windows \ Panther du volume de disque local. Le volume de disque local est généralement
le lecteur C .
L’ID d’événement 307 et l’ID d’événement 304 sont
enregistrés après le déploiement Windows sur un
appareil
Cet article fournit une résolution pour les ID d’événement 307 et 304 qui sont enregistrés lorsque vous
déployez Windows sur un appareil.
S’applique à : Windows 10 - toutes les éditions, Windows Server 2019
Symptôme
Lorsque vous déployez Windows sur un appareil, ces événements sont enregistrés :
Log Name: Microsoft-Windows-User Device Registration/Admin

Source: User Device Registration
Event ID: 307
Level: Error
Description:
Automatic registration failed. Failed to lookup the registration service information from Active Directory.
Exit code: Unknown HResult Error code: 0x801c001d. See https://go.microsoft.com/fwlink/?LinkId=623042
Log Name: Microsoft-Windows-User Device Registration/Admin

Source: Microsoft-Windows-User Device Registration
Event ID: 304
Level: Error
Description:
Automatic registration failed at join phase. Exit code: Unknown HResult Error code: 0x801c001d. Server
error:. Debug Output:\r\n undefined.
Voici un exemple d’ID d’événement :

Cause
Ces ID d’événement se produisent lorsque l’infrastructure n’est pas préparée pour la jointation hybride. Lorsque
l’appareil tente d’utiliser la jointage hybride, l’inscription échoue et les événements sont enregistrés.
Résolution
Si l’infrastructure se trouve dans un environnement de jointation non hybride, ces ID d’événement sont attendus
pendant Windows 10 déploiement. Elles peuvent être ignorées.
Si vous avez un scénario hybride, consultez Dépannage des Azure Active Directory joints Windows 10 et
Windows Server 2016 pour les étapes de résolution des problèmes.
Message d’erreur « Le sous-système nécessaire pour
prendre en charge le type d’image n’est pas présent
» lors de l’installation ou de l’exécution
d’applications sur Server Core
Cet article permet de résoudre une erreur (le sous-système nécessaire pour prendre en charge le type d’image
n’est pas présent) qui se produit lorsque vous exécutez ou installez des applications sur un ordinateur Windows
Server exécuté en tant que serveur principal.
Publication rapide
Microsoft. Les informations contenues ici sont créées en réponse à des rubriques émergentes ou uniques, ou
Symptôme
Lorsque vous exécutez ou installez des applications sur un ordinateur Windows Server exécuté en tant que
serveur principal, vous recevez le message suivant :
« Le sous-système nécessaire pour prendre en charge le type d’image n’est pas présent »
Cause
La prise en charge du sous-système 32 bits a été supprimée du serveur, manuellement ou via un processus de
build automatisé. Pour ce faire, exécutez la commande suivante :
dism /online /get-features /format:table
Examinez et confirmez la sortie suivante :
ServerCore-WOW64 | Désactivé
Résolution
Pour activer le sous-système 32 bits :
1. Logon sur l’ordinateur Server Core en tant qu’administrateur.
2. Exécutez la commande suivante exactement comme indiqué :
DISM.EXE /online /enable-feature /featurename:ServerCore-WOW64
NOTE
Le nom de la fonctionnalité « ServerCore-WOW64 » est sensible à la cas.
3. Redémarrez l’ordinateur à l’invite.
Pour reproduire ce scénario :
Pour activer le sous-système 32 bits :
1. Logon sur l’ordinateur Server Core en tant qu’administrateur.
2. Exécutez la commande suivante exactement comme indiqué :
DISM.EXE /online /enable-feature /featurename:ServerCore-WOW64
NOTE
Le nom de la fonctionnalité « ServerCore-WOW64 » est sensible à la cas.
3. Redémarrez l’ordinateur à l’invite.

Toutes les applications compilées avec du code 32 bits ne s’exécuteront pas sur Server Core lorsque le sous-
système 32 bits a été supprimé. This issue also includes the installers of 64-bit applications, where the installer
itself contains 32-bit code.
Références
Pour plus d’informations, examinez :
Nouveautés de l’option d’installation principale du serveur

Dans la mesure maximale autorisée par la loi applicable, Microsoft et/ou ses fournisseurs délament et excluent
toutes les représentations, garanties et conditions, qu’elles soient express, implicites ou statutaires, y compris,
mais sans s’y limiter, à des représentations, des garanties ou des conditions de titre, de non-contrefaçon, de
le matériel.
Comment effectuer une mise à niveau sur place sur
Windows
Une fois que vous avez effectué le processus de réparation d’urgence, l’ordinateur ne fonctionne toujours pas
normalement. Dans ce cas, vous souhaiterez peut-être effectuer une réparation ou une mise à niveau sur place
de l’installation existante.
S’applique à : Numéro de base de connaissances d’origine de toutes les versions Windows : 2255099
Une mise à niveau sur place est l’alternative finale avant de devoir réinstaller le système d’exploitation.
NOTE
La mise à niveau prend le même temps que pour réinstaller le système d’exploitation. En outre, certains de vos
paramètres de Windows personnalisés peuvent être perdus au cours de ce processus.
Comment effectuer une installation de réparation de Windows

Une installation de réparation restaure l’installation Windows actuelle à la version du DVD d’installation. Il
nécessite également l’installation de toutes les mises à jour qui ne sont pas incluses sur le DVD d’installation.
NOTE
Une installation de réparation n’endommagera pas les fichiers et les applications qui sont actuellement installés sur votre
ordinateur.
Pour effectuer une installation de réparation de Windows, procédez comme suit :

1. Fermez toutes les applications en cours d’exécution.
2. Insérez le DVD Windows dans le lecteur de DVD de l’ordinateur.
3. Dans la fenêtre d’installation , sélectionnez Installer maintenant .
NOTE
Si Windows ne détecte pas automatiquement le DVD, procédez comme suit :
a. Sélectionnez Démarrer , puis tapez Drive:\setup.exe dans la zone Démarrer la recherche.
NOTE
L’espace réservé lecteur est la lettre de lecteur du lecteur DE DVD de l’ordinateur.
b. Dans la liste Programmes, sélectionnez Setup.exe .

c. Dans la fenêtre d’installation , sélectionnez Installer maintenant .
4. Sélectionnez Go online pour obtenir les dernières mises à jour pour l’installation
(recommandé).
5. Tapez la clé CD si vous y êtes invité.
6. Sélectionnez le système d’exploitation dans la page Installer Windows que vous souhaitez mettre à
niveau ou Inplace .
7. sélectionnez Oui pour accepter les termes du contrat de licence logiciel Microsoft.
8. Dans l’écran De quel type d’installation voulez-vous ? , sélectionnez Mettre à niveau .
9. Une fois l’installation terminée, redémarrez votre ordinateur.
La mise à niveau sur place des contrôleurs de
domaine se bloque à l’écran noir
Cet article fournit une solution au problème où la mise à niveau sur place des contrôleurs de domaine se bloque
à l’écran noir.
Symptômes
Vous avez un ordinateur qui exécute Windows Server 2008 R2 Server-Core edition
Server-Core héberge le rôle contrôleur de domaine
Sur Server Core, vous exécutez une mise à niveau sur place vers Windows Server 2012
Dans ce scénario, la mise à niveau Windows Server 2012 installation se bloque sur un écran noir plein avec un
pointeur de souris comme le montre l’image ci-dessous.
NOTE
Le problème décrit dans cet article est spécifique aux contrôleurs de domaine activés pour le serveur qui sont mis à
niveau sur place vers Windows Server 2012 serveur principal. Cette condition ne se produit pas sur les interfaces
graphiques graphiques ou Full-DCs qui sont mises à niveau sur place vers Windows Server 2012.
Cause
Les NTDSA.DLL & NTDSAI.DLL ne sont pas installés lorsque Windows Server 2008 R2 Server Core DC est mis à
niveau vers Windows Server 2012. Cela est confirmé par l’analyse du débogage et de l’image du système
d’exploitation. Une session de débogage à partir de NTSD attachée à LSASS.EXE avec des snaps de chargeur
activés montre la séquence suivante lors de la tentative de chargement NTDSA.DLL
023c:0240 @ 00048468 - LdrpLoadDll - ENTER: Nom de la DLL : C:\Windows\system32\ntdsa.dll
023c:0240 @ 00048468 - LdrpLoadDll - INFO : Chargement de la DLL C:\Windows\system32\ntdsa.dll
023c:0240 @ 00048468 - LdrpFindOrMapDll - Enter: Nom de la DLL : C:\Windows\system32\ntdsa.dll
023c:0240 @ 00048468 - LdrpResolveDllName - Enter: DLL name: C:\Windows\system32\ntdsa.dll
023c:0240 @ 00048468 - LdrpResolveDllName - RETURN: Status: 0xc0000135
023c:0240 @ 00048468 - LdrpResolveDllName - Enter: DLL name: C:\Windows\system32\ntdsa.dll
023c:0240 @ 00048468 - LdrpResolveDllName - RETURN: Status: 0xc0000135
023c:0240 @ 00048468 - LdrpFindOrMapDll - RETURN: Status: 0xc0000135
023c:0240 @ 00048468 - LdrpLoadDll - RETURN : État : 0xc0000135
023c:0240 @ 00048468 - LdrLoadDll - RETURN : État : 0xc0000135
où le code 0xc0000135 d’état se map après :
C H A ÎN E D’ERREUR
H EX DÉC IM A L SY M B O L IQ UE C O N VIVIA L E
0xc0000135 -1073741515 STATUS_DLL_NOT_FOUND Cette application n’a pas

réussi à démarrer car %hs
est in trouvé. La
réinstallation de l’application
peut résoudre ce problème.
Ces binaires sont installés dans le cadre du rôle facultatif « Services de domaine Active Directory ». Le rôle
DirectoryServices-DomainController est désactivé par défaut et n’est pas activé, car il n’existe aucun rôle de ce
nom sur le système d’exploitation Windows Server 2008 R2. Étant donné qu’il n’y a rien à faire correspondre
entre les manifestes Windows Server 2012 disponibles, la mise à niveau se bloque.
Résolution
Pour résoudre la situation où le serveur est bloqué lors de la mise à niveau, continuez à redémarrer le serveur
jusqu’à ce que la remise à l’état et à la version précédentes du système d’exploitation soit déclenchée. Après le
verrouillage permanent sur l’écran noir, redémarrez le serveur deux fois. Le programme d’installation détecte
l’échec de la tentative de mise à niveau et retourne le système à la version précédente du système d’exploitation.
NOTE
Vous ne devez pas faire face à une perte de données dans ce processus. Les DCS de cœur de serveur qui étaient sains et
opérationnels avant la tentative de mise à niveau de la version du système d’exploitation doivent continuer à fonctionner.
Vous pouvez faire en sorte que la mise à niveau sur place réussisse en ajoutant un « manifeste de remplacement
» aux fichiers sources d’installation. Veuillez contacter le support technique du client Microsoft pour récupérer le
manifeste. Veillez à référencer cet article afin que l’agent puisse vous fournir le fichier manifeste gratuitement.
Voici les étapes à suivre pour utiliser ce manifeste pour mettre à niveau un contrôleur de domaine principal de
serveur :
1. Développez le contenu du fichier CAB récupéré auprès de Microsoft pour obtenir le fichier manifeste «
DirectoryServices-DomainController-ServerCoreUpg-Replacement.man ».
2. Copiez le Windows Server 2012 DVD d’installation dans un dossier de disque dur tel que d:\products\ws12.
3. Créez un dossier d:\products\ws12\sources\replacementmanifests.
4. Placez le fichier manifeste récupéré de Microsoft dans le nouveau dossier.
5. Utilisez l’emplacement du serveur créé à l’étape 2 comme source pour la mise à niveau de votre serveur.
Solution de contournement pour sortir de cette situation si vous ne pouvez pas utiliser l’approche mentionnée
ci-dessus :
1. Promouvoir de Windows Server 2012 DCS principaux du serveur sur différents ordinateurs physiques ou
physiques. Au lieu de mettre à niveau sur place les DCS W2K8 R2 Server core existants, faites la
promotion de nouveaux DCS principaux du serveur Windows Server 2012 sur de nouveaux ordinateurs
physiques ou virtuels. Retirez les DCS principaux du serveur W2K8 R2 de niveau inférieur, si nécessaire.
2. Supprimez le rôle ADDS sur l’ordinateur principal du serveur W2K8 R2 avant la mise à niveau sur place
vers Windows Server 2012.
Lorsque la mise à niveau se bloque et que vous réinitialisez l’ordinateur, Windows chargeur de démarrage par
défaut démarre « Windows Server 2012 ». Vous pouvez déclencher la récupération dans le chargeur de
démarrage Windows en sélectionnant l’option de démarrage « Windows de l’installation ». Vous pouvez
également démarrer l’ordinateur avec le paramètre par défaut :
Si l’option de démarrage « Windows Server 2012 » a été utilisée, le programme d’installation détecte l’échec de
la mise à niveau sur place et déclenche automatiquement la remise à la version précédente du système
d’exploitation.
NOTE
La taille et les proportions des captures d’écran décrites dans cet article ont été modifiées pour des raisons de concision.
Vous pouvez avoir un problème avec Internet Explorer après le rembobinage :
Un problème est à l'iernonce.dll

Le module spécifié est in trouver.
Une mise à jour est disponible Windows Server
Update Services (WSUS) 3.0 dans le Gestionnaire de
serveur
Cet article permet de résoudre un problème dans lequel vous ne pouvez pas utiliser le logiciel en snap-in
Gestionnaire de serveur pour installer WSUS, ou WSUS n’apparaît pas dans le logiciel en snap-in du
Gestionnaire de serveur.
INTRODUCTION
Le logiciel enfichable Gestionnaire de serveur est une nouvelle fonctionnalité de Windows Server 2008 qui
guide les administrateurs dans l’installation, la configuration et la gestion des rôles et fonctionnalités Windows
Server 2008. Pour plus d’informations sur le Gestionnaire de serveur, visitez le site Web Microsoft suivant :
https://www.microsoft.com/windowsserver2008/servermanagement.mspx
Par défaut, Windows Server 2008 inclut plusieurs rôles serveur. Le Gestionnaire de serveur permet l’intégration
de rôles et de fonctionnalités supplémentaires disponibles à partir du Centre de téléchargement Microsoft et de
Windows Mettre à jour les sites Web en tant que mises à jour facultatives vers Windows Server 2008. Un rôle
disponible en tant que mise à jour est Windows Server Update Services (WSUS) 3.0 avec Service Pack 1 (SP1).
Cette mise à jour pour le Gestionnaire de serveur Windows Server 2008 intègre entièrement WSUS 3.0 SP1 au
Gestionnaire de serveur. Cette mise à jour vous permet d’utiliser le logiciel enfichable Gestionnaire de serveur et
les Assistants pour installer, configurer et gérer WSUS 3.0 SP1.
Si vous ne prévoyez pas d’installer l’installation de serveur complet WSUS 3.0 SP1 qui inclut la console
d’administration ou si vous envisagez d’installer la console d’administration WSUS 3.0 SP1 uniquement,
n’appliquez pas cette mise à jour. Si l’installation complète du serveur WSUS 3.0 SP1 qui inclut la console
d’administration est installée sur l’ordinateur, cette mise à jour vous permet d’utiliser le Gestionnaire de serveur
pour gérer WSUS.
Mettre à jour les informations
Les fichiers suivants peuvent être téléchargés à partir du Centre de téléchargement Microsoft :
Windows Server 2008
Téléchargez maintenant la mise à jour Windows Server 2008 Server Manager (KB940518).
119591 comment obtenir des fichiers de support Microsoft à partir des services en ligne Microsoft a analysé ce
fichier pour y trouver des virus. Microsoft a utilisé le logiciel de détection de virus le plus actuel disponible à la
date de la date de la mise en ligne du fichier. Le fichier est stocké sur des serveurs à sécurité améliorée qui
permettent d’empêcher toute modification non autorisée du fichier.
Recherchez Update for Windows (KB940518) dans l’élément Afficher les mises à jour installées ou dans
l’élément Programmes et fonctionnalités du Panneau de contrôle. Si Update for Windows (KB940518)
n’apparaît pas, la mise à jour n’est pas installée.
Instructions d’installation
Pour éviter le redémarrage de l’ordinateur, vérifiez que les tâches de configuration initiales, le Gestionnaire de
serveur et le processus Servermanagercmd.exe ne sont pas en cours d’exécution pendant le processus
d’installation. Vous devez également vous connecter à l’ordinateur en tant qu’administrateur pour installer cette
mise à jour.
1. Sur un ordinateur exécutant Windows Server 2008, téléchargez le package de mise à jour à partir du site
Web Microsoft répertorié dans la section « Informations de mise à jour ».
2. Double-cliquez sur le package de téléchargement pour démarrer l’Assistant Installation. Suivez les
instructions de l’Assistant pour terminer l’installation.
3. Utilisez l’une des méthodes suivantes pour ouvrir le Gestionnaire de serveur :
Cliquez sur Démarrer , cliquez avec le bouton droit sur Ordinateur et cliquez sur Gérer .
Cliquez sur Démarrer , pointez sur Outils d’administration , puis cliquez sur Gestionnaire de
ser veur .
Cliquez sur la barre de lancement rapide, puis sur Gestionnaire de ser veur.
NOTE
Si WSUS 3.0 SP1 est déjà installé sur votre ordinateur, vous n’avez pas besoin d’effectuer les étapes restantes.
4. Dans la page d’accueil du Gestionnaire de serveur, cliquez sur Ajouter des rôles dans la section
Résumé des rôles.
5. Dans la page Sélectionner des rôles de l’Assistant Ajout de rôles, cliquez pour sélectionner Windows
Server Update Services dans la liste des rôles disponibles.
6. Suivez les instructions de l’Assistant Ajout de rôles pour terminer l’installation.
Pour désinstaller le Gestionnaire de serveur, suivez les étapes suivantes :
1. Cliquez sur Démarrer , sur Panneau de configuration , puis sur Programmes .
2. Sous Programmes et fonctionnalités, cliquez sur Afficher les mises à jour installées.
3. Dans la liste des mises à jour à installer sous le groupe Microsoft Windows, double-cliquez sur Mise à
jour pour Windows (KB940518), puis suivez les instructions pour supprimer la mise à jour pour le
Gestionnaire de serveur.
Si vous installez cette mise à jour et la console d’administration WSUS 3.0 SP1 uniquement, vous ne pouvez pas
installer d’autres rôles à l’aide de l’Assistant Ajout de rôles du Gestionnaire de serveur
Pour contourner ce problème, supprimez la mise à jour pour Windows Server 2008 Server Manager
(KB940518).
NOTE
This issue is fixed in Windows Server 2008 SP2 and higher.
Le Gestionnaire de serveur signale de manière incorrecte un échec d’installation

Le Gestionnaire de serveur signale un échec d’installation dans les scénarios suivants :
Vous avez utilisé le Gestionnaire de serveur pour installer WSUS 3.0 SP1 et vous devez redémarrer
l’ordinateur pour terminer l’installation.
Vous avez redémarré l’ordinateur après avoir installé WSUS 3.0 SP1. Dans ce scénario, le Gestionnaire de
serveur signale à tort que l’installation a échoué et qu’il a généré le message d’erreur suivant :
La mise à jour a été trouvée, mais n’a pas pu être téléchargée.
Aucune action n’est requise pour contourner ce problème. Après avoir fermé l’Assistant Ajout de rôles, le
Gestionnaire de serveur indique que WSUS 3.0 SP1 a été installé.
Sur un ordinateur exécutant Windows Web Server 2008 avec mise à jour pour Windows Server 2008 Server
Manager (KB940518) installé, les rôles serveur et les services de rôle répertoriés ci-dessous s’affichent en plus
des Windows Server Update Services. Toutefois, l’installation de ces rôles serveur n’est pas prise en charge sur
Windows Web Server 2008 et seul le rôle serveur Web doit être installé.
Serveur d’applications
Application Server Foundation
Prise en charge des serveurs web (IIS)
COM+ Accès réseau
Partage de port TCP
Windows prise en charge du service d’activation des processus
Activation HTTP
Message Queuing Activation
TCP Activation
Activation de canaux nommés
Transactions distribuées
Transactions distantes entrantes
Transactions distantes sortantes
WS-Atomic transactions
Services de fichiers
Système de fichiers distribués
Réplication DFS
En outre, la fonctionnalité Gestionnaire de ressources du serveur de fichiers (FSRM) et la fonctionnalité Service
d’indexation apparaissent en tant que services de rôle du rôle Services de fichiers. Vous pouvez installer ces
fonctionnalités à l’aide de l’Assistant Ajout de rôles.
Services de fichiers
Gestionnaire de ressources du serveur de fichiers
Windows Services de fichiers server 2003
Service d'indexation
NOTE
Si vous choisissez d’installer le Gestionnaire de ressources du serveur de fichiers, l’installation du Gestionnaire de
ressources du serveur de fichiers réussit. Toutefois, vous recevez un message d’erreur, car la configuration ne peut pas être
appliquée à cette fonctionnalité sur Windows Web Server 2008. Le Gestionnaire de ressources du serveur de fichiers est
toujours entièrement fonctionnel en tant que fonctionnalité malgré ce message d’erreur.
Configuration requise du système

Vous devez être en cours d’exécution une version release de Windows Server 2008 avec une option
d’installation autre que Server Core.
Conditions requises pour le redémar
Pour éviter le redémarrage de l’ordinateur, assurez-vous que les tâches de configuration initiales, le Gestionnaire
de serveur et le processus Servermanagercmd.exe ne sont pas en cours d’exécution pendant le processus
d’installation.
Fonctionnalités linguistiques
Ce package d’installation est conçu pour toutes les versions linguistiques Windows Server 2008. Il s’agit
notamment des versions anglaises, des versions localisées et des packs linguistiques d’interface.
Le package d’installation de la mise à jour pour le Gestionnaire de serveur installe automatiquement la mise à
jour pour le pack linguistique du Gestionnaire de serveur qui correspond aux paramètres régionaux
sélectionnés pour le système d’exploitation.
La mise à jour du Gestionnaire de serveur est entièrement localisée dans toutes les langues qui sont Windows
Server 2008. Ces langues sont les suivantes :
Chinois simplifié
Chinois traditionnel
Tchèque
Néerlandais
Hongrois
Anglais
Français
Allemand
Italien
Japonais
Coréen
Portugais
Russe
Espagnol
Suédois
Turc
Références
948014 description du package Windows Server Update Services 3.0 Service Pack 1
Problèmes connus affectant la tâche de
maintenance de nettoyage AppX dans Windows 8.1
et Windows Server 2012 R2
Cet article fournit des solutions aux problèmes connus qui impliquent la tâche de maintenance de nettoyage
AppX.
S’applique à : Windows 8.1, Windows Server 2012 R2
Introduction
Pour réduire l’encombrement disque global, une fois que vous avez installé Windows 8.1 ou Windows Server
2012 R2, une tâche de maintenance de nettoyage AppX préinstallée est exécuté après 60 minutes d’utilisation
de l’ordinateur suivi de 15 minutes de temps d’inactivité de l’ordinateur. Cette tâche de maintenance
programmée récupère de l’espace disque après le Windows’installation. Pour ce faire, la tâche supprime les
packs de ressources du package d’application (.appx) en fonction de la langue, de l’échelle et du niveau de
fonctionnalité DirectX (DXFL) qui ne sont pas utilisés actuellement pour les comptes d’utilisateurs actuels.
Symptômes
Si vous exécutez Sysprep après cette tâche de maintenance de nettoyage AppX, il enregistre le message
d’avertissement suivant dans le journal Setupact dans le dossier C:\Windows\System32\Sysprep :
<Date>, Avertissement SYSPRP N’a pas pu ré armer la sélection de région, certains fichiers et clés de
Registre ne sont <Time> plus récupérables.
<Date><Time>, Info SYSPRP exiting SysprepGeneralize (Appx).
Si vous capturez et déployez cette image, l’utilisateur final peut être aux états suivants :
L’échelle d’affichage des applications modernes est utilisée (un affichage hautes valeurs DEPI au lieu d’un
affichage à faible taux de dpi).
Une langue d’affichage incorrecte est utilisée pour certaines applications modernes si des packs linguistiques
supplémentaires sont installés.
NOTE
Dans ce cas, les applications modernes fonctionnent toujours. Toutefois, il se peut qu’ils ne disposent pas des ressources
nécessaires pour l’ordinateur.
Cause
Ce problème est dû à la suppression de packs de ressources.
Si vous créez une image pour le déploiement, exécutez Sysprep dans les 75 minutes après la première
Windows 8.1 ou Windows Server 2012 R2. Si vous ne pouvez pas le faire, essayez la solution de contournement
2.
Désactivez la tâche de maintenance immédiatement après la première logon. Pour désactiver automatiquement
la tâche de maintenance, exécutez la commande suivante à une invite de commandes avec élévation de niveau
élevé :
Schtasks.exe /change /disable /tn "\Microsoft\Windows\AppxDeploymentClient\Pre-staged app cleanup"
Pour désactiver automatiquement la tâche de maintenance dans le cadre de la séquence de tâches build-and-
capture configuration Manager, insérez une nouvelle étape « Exécuter la ligne de commande » immédiatement
après l’étape « Setup Windows and Configuration Manager ». Cette nouvelle étape utilise la commande suivante
:
Schtasks.exe /change /disable /tn "\Microsoft\Windows\AppxDeploymentClient\Pre-staged app cleanup"
NOTE
Insérez cette nouvelle étape uniquement dans les séquences de tâches qui exécutent Sysprep Windows 8.1 ou Windows
Server 2012 R2. Windows active automatiquement la tâche de maintenance pendant la phase de généralisation de
Sysprep.
Si vous créez une image pour le déploiement, démarrez l’ordinateur en mode audit Sysprep pour apporter des
modifications de configuration avant d’exécuter SysprepGeneralize pour capturer l’image mentionnée dans la
section « Symptômes ».
NOTE
La tâche programmée ne s’exécute pas en mode Audit.
Patientez 24 heures pour que le processus de mise à jour automatique du Store s’exécute. Sinon, recherchez
manuellement les mises à jour du Store.
Si vous déployez l’image mentionnée dans la section « Symptômes » sur un ordinateur qui nécessite certains
des packages de ressources qui ont été supprimés, les ressources requises sont mises à jour automatiquement
si l’utilisateur qui se connecte à l’ordinateur a accès au Microsoft Store. Cette mise à jour se produit 24 heures
après la première ouverture de connexion après l’utilisation de Sysprep si Microsoft Store connectivité est
disponible. Il existe un paramètre de stratégie de groupe qui désactive les mises à jour Microsoft Store
automatiques. Ce paramètre empêche la restauration des packs de ressources manquants. Si les packs de
ressources sont manquants, l’utilisateur Microsoft Store accès pour mettre à jour les packs de ressources
applicables pour l’ordinateur.
Statut
Si vous supprimez la tâche de maintenance, les ressources ne sont pas supprimées et la tâche n’est jamais
exécuté. Étant donné que la tâche de maintenance n’est pas disponible après l’installation, les ressources utilisent
toujours de l’espace disque sur l’ordinateur.
Les noms de fichiers longs ou les chemins d’accès
comportant des espaces nécessitent des guillemets.
Cet article fournit une solution à un problème qui se produit lorsque vous spécifiez des noms de fichiers longs
ou des chemins d’accès comportant des espaces.
Applicabilité : Windows 10 - toutes les éditions, Windows Server 2012 R2
Symptômes
Le message d’erreur suivant est envoyé lors de la spécification de noms de fichiers longs ou de chemins d’accès
comportant des espaces sous Windows NT :
Le système ne trouve pas le fichier spécifié
Cause
Les noms de fichiers longs ou les chemins d’accès comportant des espaces sont pris en charge par le système
de fichiers NTFS sous Windows NT. Toutefois, ces noms de fichiers ou de répertoires doivent être entourés de
guillemets lorsqu’ils sont spécifiés dans une opération de l’invite de commande. Si vous n’utilisez pas les
guillemets, le message d’erreur s’affiche.
Résolution
Utilisez des guillemets lors de la spécification de noms de fichiers longs ou de chemins d’accès comportant des
espaces. Par exemple, si vous saisissez la commande copy c:\my file name d:\my new file name à l’invite de
commandes, le message d’erreur suivant s’affiche :
La syntaxe correcte est la suivante :
copy "c:\my file name" "d:\my new file name"
NOTE
Les guillemets doivent être utilisés.
Les espaces sont autorisés dans les noms de fichiers longs ou les chemins d’accès, qui peuvent comporter
jusqu’à 255 caractères dans le système de fichiers NTFS. Toutefois, toutes les opérations à l’invite de
commandes impliquant des noms longs comportant des espaces doivent être traitées différemment. L’insertion
d’un espace après un mot pour spécifier un paramètre est le fruit d’une convention MS-DOS. La même
convention est suivie dans les opérations de l’invite de commande de Windows NT, même en cas d’utilisation de
noms de fichiers longs.
Modifier manuellement le fichier Boot.ini dans un
environnement Windows Server 2003
Cet article explique comment modifier manuellement le fichier Boot.ini dans un environnement Microsoft
Résumé
Le fichier Ntldr utilise les informations du fichier Boot.ini pour afficher l’écran du chargeur d’a bootstrap à partir
duquel vous sélectionnez le système d’exploitation. Cet écran est basé sur les informations du fichier Boot.ini de
données. Si vous ne sélectionnez pas une entrée avant que le compteur n’atteigne la valeur 0 (zéro), Ntldr
charge le système d’exploitation spécifié par le paramètre par défaut dans le fichier Boot.ini.
Windows Le programme d’installation de Server 2003 place Boot.ini fichier à la racine de la partition système.
Avant de modifier le fichier Boot.ini, modifiez vos options de dossier afin de pouvoir afficher les fichiers
masqués, puis Boot.ini fichier.
NOTE
Vous pouvez également modifier le fichier Boot.ini à l’aide de l’utilitaire de configuration système (Msconfig.exe). Pour
démarrer l’utilitaire de configuration système, cliquez sur Démarrer, cliquez sur Exécuter, tapez msconfig dans la zone
Ouvrir, puis cliquez sur OK.
Modifier les options de dossier

1. Cliquez avec le bouton droit sur Démarrer, puis cliquez sur Explorer.
2. Dans le menu Outils, cliquez sur Options de dossier, puis sur Afficher.
3. Sous Advanced Paramètres , cliquez sur Afficher les fichiers et dossiers masqués, cliquez pour effacer la
case à cocher Masquer les fichiers de système d’exploitation protégés (recommandé), cliquez sur Oui, puis
sur OK.
4. Recherchez la partition système, recherchez et cliquez avec le bouton droit sur Boot.ini fichier, puis cliquez sur
Propriétés.
5. Cliquez pour effacer la case à cocher En lecture seule, puis cliquez sur OK.
Enregistrer une copie de sauvegarde du fichier Boot.ini de sauvegarde

1. Cliquez avec le bouton droit sur Démarrer, puis cliquez sur Explorer.
2. Recherchez la partition système, recherchez et cliquez avec le bouton droit sur Boot.ini fichier, puis cliquez sur
Copier .
3. Recherchez et cliquez sur le dossier dans lequel vous souhaitez copier Boot.ini fichier, puis cliquez sur Coller
dans le menu Modifier.
Exemple Boot.ini fichier

Voici un exemple d’un fichier Boot.ini par défaut à partir d’un ordinateur Windows Server 2003 :
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows .NET Standard Server" /fastdetect
Voici un exemple du même fichier Boot.ini après l’ajout d’une autre partition qui exécute Microsoft Windows XP
Professional.
[boot loader]
timeout=30
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows .NET Standard Server" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional"
Modifier le fichier Boot.ini de données

1. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Accessoires, puis cliquez sur Bloc-notes .
2. Dans le menu Fichier, cliquez sur Ouvrir.
3. Dans la zone Rechercher dans, cliquez sur la partition système, dans la zone Fichiers de type, cliquez sur
Tous les fichiers, recherchez et cliquez sur le fichier Boot.ini, puis cliquez sur Ouvrir .
4. A apporté les modifications que vous souhaitez au fichier Boot.ini, puis cliquez sur Enregistrer dans le
menu Fichier.
Les exemples de modifications que vous pouvez apporter sont décrits dans les sections suivantes de cet article.
Supprimer un système d’exploitation du menu

Pour supprimer un système d’exploitation du menu, suivez les étapes suivantes :
1. Dans Bloc-notes, sélectionnez la ligne qui contient des informations sur le système d’exploitation à
supprimer, puis cliquez sur Supprimer dans le menu Modifier. Par exemple, sélectionnez la ligne suivante :
multi(0)disk(1)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
2. Dans le menu Fichier , cliquez sur Enregistrer .
Modifier l’ordre de menu du système d’exploitation

Pour modifier l’ordre de menu du système d’exploitation, suivez les étapes suivantes :
1. Dans Bloc-notes, sélectionnez la ligne à déplacer, cliquez sur Copier dans le menu Modifier, puis appuyez sur
SUPPRIMER.
2. Cliquez sur l’endroit où vous souhaitez insérer la ligne, puis cliquez sur Coller dans le menu Edition.
3. Répétez les étapes 1 et 2 pour chaque ligne à déplacer, puis cliquez sur Enregistrer dans le menu Fichier.
Modifier le système d’exploitation par défaut

Le système d’exploitation par défaut est le système d’exploitation qui est démarré si aucune sélection n’est faite
avant le délai d’utilisation. (Le délai d’délai est le nombre de secondes pendant lesquelles vous pouvez
sélectionner un système d’exploitation dans le menu avant le chargement du système d’exploitation par défaut.)
Pour modifier le système d’exploitation par défaut, suivez les étapes suivantes :
1. Dans Bloc-notes, modifiez la ligne suivante pour modifier le système d’exploitation par défaut :
Par exemple, pour modifier le système d’exploitation par défaut de Windows Server 2003 à Windows XP
Professional, modifiez les paramètres suivants :
linedefault=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
à ce qui suit :
Modifier le délai d’délai

Pour modifier la valeur du délai d’accès, suivez les étapes suivantes :
1. Dans Bloc-notes, modifiez la ligne suivante pour modifier le délai d’attente (où la valeur est de 30
secondes) :
timeout=30

En cas de problème avec le fichier Boot.ini que vous avez modifié, copiez le fichier Boot.ini d’origine (celui que
vous avez précédemment secours) dans la partition système.
Lecteur USB mdT Media Deployment non
démorçable sur le système UEFI x86
Cet article fournit une solution à une erreur qui se produit lorsque vous essayez de démarrer un lecteur USB de
déploiement multimédia Microsoft Deployment Shared Computer Toolkit 2012 Update 1 sur un système UEFI
x86.
Symptômes
Lorsque vous tentez de démarrer un lecteur USB de déploiement multimédia Microsoft Deployment Shared
Computer Toolkit 2012 Update 1 sur un système UEFI x86, il se peut que le lecteur n’apparaisse pas dans les
options de démarrage du système.
Cause
Si vous créez un média à l’aide de MDT qui sélectionne les plateformes x86 et x64, MDT génère un message qui
indique « Ne pas ajouter d’entrée de démarrage x86 à UEFI BCD car le support UEFI de démarrage double n’est
pas pris en charge »
Résolution
Pour démarrer un déploiement de média MDT sur un système UEFI x86, vous devez décocher x64 lors de la
création du média MDT. Pour résoudre ce problème, faites les choses suivantes :
1. Dans le partage de déploiement, accédez à Advanced Configuration > Media .
2. Cliquez avec le bouton droit sur le média et choisissez les propriétés.
3. Sous plateformes, décochez l’image de démarrage Générer x64.
NOTE
Assurez-vous que le lecteur est également au format FAT32.
Le lecteur USB doit apparaître comme amorçable dans l’ordre de démarrage.
Les systèmes UEFI peuvent uniquement démarrer les systèmes d’exploitation et Windows images de démarrage
PE qui correspondent à l’architecture du processeur de l’ordinateur. Par exemple, les systèmes Intel Atom ne
peuvent prendre en charge que les systèmes x86, tandis que les systèmes Intel Core ne peuvent prendre en
charge que x64 (sans utiliser la compatibilité BIOS héritée).
En raison des limitations du processus de démarrage UEFI, il n’est pas possible de créer un média qui fonctionne
avec les systèmes UEFI x86 et x64. Ainsi, pour les médias MDT qui spécifient la prise en charge des architectures
x86 et x64, MDT ne peut prendre en charge qu’une architecture pour le démarrage UEFI. (X86 et x64
fonctionnent parfaitement pour les systèmes non UEFI.) Au lieu de générer une erreur, MDT enregistre un
message indiquant que le média résultant ne prendra en charge que les systèmes UEFI x64.
Pour prendre en charge les systèmes UEFI x86, vous devez avoir un média distinct qui sélectionne uniquement
l’architecture x86.
Microsoft Deployment Shared Computer Toolkit
cycle de vie de support
Cet article traite du cycle de vie de support pour Microsoft Deployment Toolkits.
2012 R2
Résumé
La dernière version de Microsoft Deployment Shared Computer Toolkit peut être téléchargée à partir du site
web du Centre de téléchargement Microsoft suivant : Centre de téléchargement Microsoft
Pour plus d’informations sur la Shared Computer Toolkit de déploiement Microsoft, consultez la documentation
Windows site web microsoft deployment Shared Computer Toolkit suivante:
Microsoft Deployment Toolkits utilise le cycle de vie de support suivant :
Les releases MDT ne ront en charge que les scénarios qui utilisent des technologies de sous-programme qui
font toujours l’objet de leur stratégie de support classique.
Les versions MDT seront pris en charge pendant un (1) an après la publication de la prochaine version, quelle
que soit la date de la dernière. Version actuellement prise en charge : Microsoft Deployment Shared
Computer Toolkit (dernière version publiée)
Ces versions antérieures du produit ne sont pas disponibles en téléchargement et ne sont plus pris en charge
:
Microsoft Deployment Shared Computer Toolkit 2013 (8443)
Microsoft Deployment Shared Computer Toolkit 2013 Update 2
Microsoft Deployment Shared Computer Toolkit (MDT) 2013 Update 1
Microsoft Deployment Shared Computer Toolkit (MDT) 2012 Update 1
Microsoft Deployment Shared Computer Toolkit (MDT) 2013
Microsoft Deployment Shared Computer Toolkit 2010 Update 1, version de septembre 2010
Microsoft Deployment Shared Computer Toolkit 2010 (RTW), version de septembre 2009
Version de Microsoft Deployment Shared Computer Toolkit 2008 Update 1, septembre 2008
Microsoft Deployment Shared Computer Toolkit version 2008, mars 2008
Microsoft Deployment, version de novembre 2007
Version de mars 2008 de Business Desktop Deployment 2007 Update 2
Version de mai 2007 de Business Desktop Deployment 2007 Update 1
Version de Business Desktop Deployment 2007, janvier 2007
Business Desktop Deployment 2.5, version d’août 2005 de Microsoft Deployment Shared Computer Toolkit
est pris en charge uniquement pendant les heures d’ouverture locales.
Autres produits « S’applique à »

Microsoft Deployment Shared Computer Toolkit 2013 Update 1 Microsoft Deployment Business Desktop
Deployment 2007 Update 1 Business Desktop Deployment 2007 Business Desktop Deployment 2.5
La tâche de configuration post-déploiement peut
échouer après l’installation du rôle Windows Server
Essentials Experience
Cet article fournit une solution à un problème dans lequel la tâche de configuration post-déploiement échoue
après l’installation du rôle Windows Server Essentials Experience.
Symptômes
Après avoir installé le Windows Server Essentials Experience sur Windows Server 2012 R2, la tâche de
configuration post-déploiement peut échouer. En outre, vous recevez l’erreur suivante :
La configuration a rencontré certains problèmes

Veuillez cliquer sur Réessayer. Si le problème existe toujours, consultez le lien d’aide pour plus d’étapes de
résolution des problèmes.
Vous pouvez également recevoir l’un des messages d’erreur suivants dans le journal système :

Niveau : Error
Utilisateur : N/A
Description :
Le service Windows Server Essentials Management Service n’a pas réussi à démarrer en raison de l’erreur
suivante :
Le service n’a pas commencé en raison d’une défaillance de l’accès.
ou -

Niveau : Error
Utilisateur : N/A
Description :
Le service WseMgmtSvc n’a pas pu se connecter en tant que CONTOSO.local \ Ser verAdmin$ avec le mot
de passe actuellement configuré en raison de l’erreur suivante :
Échec de la logon: l’utilisateur n’a pas reçu le type de logon sur cet ordinateur.
Service : WseMgmtSvc
Domaine et compte : CONTOSO.local \ Ser verAdmin$
Ce compte de service n’a pas le droit d’utilisateur requis « Se connecter en tant que service ».
ou -

Niveau : Error
Utilisateur : N/A
Description :
Le service WseMediaSvc n’a pas pu se connecter en tant que CONTOSO.local \ MediaAdmin$ avec le mot
de passe actuellement configuré en raison de l’erreur suivante :
Service : WseMediaSvc
Domaine et compte : CONTOSO.local \ MediaAdmin$
NOTE
Les noms des comptes de service mentionnés dans ces erreurs peuvent parfois avoir un numéro supplémentaire ajouté si
le compte était déjà présent dans Active Directory. Par exemple, Ser verAdmin1$ ou MediaAdmin2$ peut être ajouté.
Vous devez noter ces noms de compte de service, car vous utiliserez le même nom de compte dans la section « Résolution
».
Cause
Ce comportement peut se produire si le paramètre de stratégie de groupe « Connexion en tant que service » est
configuré dans votre environnement.
Pendant l’exécution de la tâche de configuration post-déploiement, le service de gestion Windows Server
Essentials est configuré pour utiliser le compte Ser verAdmin$ pour se connecter en tant que service et
effectuer la tâche. Une fois les configurations Essentials terminées, le service est configuré pour utiliser le
compte Système local.
De même, le Windows Server Essentials Media Streaming Service est configuré pour utiliser le compte
MediaAdmin$.
Résolution
Pour résoudre ce problème, suivez ces étapes pour ajouter les comptes de service mentionnés dans l’ID
d’événement 7041 (autrement dit, DOMAIN\Ser verAdmin$ et DOMAIN\MediaAdmin$ ) au paramètre de
stratégie de groupe « Se connecter en tant que service ».
1. Démarrez la Console de gestion des stratégies de groupe (GPMC). Pour ce faire, exécutez l’une des actions
suivantes : appuyez sur la touche de logo Windows + R pour ouvrir la boîte de dialogue EXÉCUTER, tapez
gpmc.msc dans la zone de texte, puis cliquez sur OK ou appuyez sur Entrée. Sinon, cliquez sur Démarrer,
cliquez dans la zone Démarrer la recherche, tapez gpmc.msc, puis appuyez sur Entrée.
2. Cliquez avec le bouton droit sur Stratégie des contrôleurs de domaine par défaut , puis cliquez sur
Modifier .
3. Accédez à Configuration ordinateur\Windows Paramètres\Sécurité Paramètres\Stratégies locales\Attribution
des droits d’utilisateur.
4. Dans le volet d’informations, double-cliquez sur Ouvrir une session en tant que ser vice.
5. Assurez-vous que la case à cocher Définir ces paramètres de stratégie est sélectionnée, puis cliquez sur
Ajouter un utilisateur ou un groupe.
6. Tapez le nom du compte de service mentionné dans l’ID d’événement 7041 Par exemple, tapez
DOMAIN\Ser verAdmin$ ou DOMAIN\MediaAdmin$ . Vous pouvez également cliquer sur Parcourir
pour rechercher le compte dans la boîte de dialogue Sélectionner des utilisateurs, des ordinateurs ou des
groupes, puis cliquez sur OK.
7. Une fois que vous avez entré le nom du compte, cliquez sur OK dans la boîte de dialogue Ajouter un
utilisateur ou un groupe, puis cliquez sur OK dans la boîte de dialogue Autoriser le journal sur les propriétés
localement.
8. Pour mettre à jour manuellement la stratégie de groupe modifiée, à l’invite de commandes, tapez gpupdate,
puis appuyez sur Entrée.
9. Réexécutez la tâche de configuration post-déploiement.
Windows Server 2012 configuration R2 peut
échouer sur un ordinateur virtuel configuré pour
utiliser la mémoire minimale requise
Cet article fournit des solutions de contournement pour un problème dans lequel l’installation Windows Server
2012 R2 échoue avec une erreur 0xE0000100 sur un ordinateur virtuel.
Symptômes
Vous créez une machine virtuelle configurée pour utiliser la quantité minimale de RAM requise (512
mégaoctets [Mo]).
Vous démarrez la machine virtuelle à partir d’un fichier image ISO.
Vous essayez de configurer Windows Server 2012 R2 sur la machine virtuelle.
Dans ce scénario, l’installation échoue et vous recevez le message d’erreur suivant :
Windows’installation a rencontré une erreur inattendue. Vérifiez que les sources d’installation sont
accessibles et redémarrez l’installation.
Code d’erreur : 0xE0000100
Cause
Ce problème se produit en raison d’une mémoire insuffisante pendant l’installation.
Pour contourner ce problème, appliquez l'une des méthodes suivantes :
Créez un fichier de page. Pour cela, procédez comme suit :
1. Lorsque la machine virtuelle démarre, appuyez sur Shift + F10 pour ouvrir la fenêtre d’invite de
commandes.
2. Exécutez Diskpart.exe pour créer et mettre en forme la partition (par exemple, C:) sur lequel vous
souhaitez installer Windows Server 2012 R2.
3. Exécutez la commande suivante pour créer un fichier de page dont la taille par défaut est de 64 Mo
:
wpeutil createpagefile /path=C:\pf.sys
4. Quittez la fenêtre d’invite de commandes, puis poursuivez l’installation.

Augmentez la mémoire allouée de la machine virtuelle avant l’installation.
Créez et configurez une autre machine virtuelle configurée pour utiliser davantage de mémoire, puis
attachez le disque dur virtuel.
La séquence de tâches SYSPREP et CAPTURE
échoue avec une erreur 0x80070070
Cet article permet de résoudre une erreur 0x80070070 qui se produit lorsque Deployment Shared Computer
Toolkit ne parvient pas à terminer la séquence de tâches sysprep et de capture.
Symptômes
Microsoft Deployment Shared Computer Toolkit ne parvient pas à terminer la séquence de tâches sysprep et de
capture s’il existe une lettre de lecteur affectée à la première partition ou si l’espace libre disponible dans la
première partition est insuffisant. Les détails suivants avec l’erreur sont affichés dans l’écran Résumé.
ERREUR ZTI - Erreur non dirigée renvoyée par LTIApply : (-2147024784 0x80070070)
Échec du déploiement de Litetouch, Code renvoyé = -2147467259 0x80004005
Messages du moteur de séquence de tâches :
Échec de l’action : Appliquer Windows PE.
Il n’y a pas suffisamment d’espace sur le disque. (Erreur : 80070070; Source : Windows)
L’exécution du groupe (Capture Image) a échoué et l’exécution a été abandonnée.
Une action a échoué.
Opération abandonnée (Erreur : 80004004; Source : Windows)
Échec de l’application de la dernière action : Appliquer Windows PE. Échec de l’exécution de la séquence de
tâches.
Dans BDD.log, nous pouvons voir les informations suivantes :
--- application d’une Windows image PE -----

Application LTI Windows PE
Démarre dans Windows architecture PE x64 pour correspondre au système d’exploitation en cours de
déploiement. Copie du \ \ démarrage \ deploymentshare \ du serveur \ LiteTouchPE_x64.wim sur E : \
sources.boot.wim
MDT copiait LiteTouchPE.wim sur E : LiteTouchPE.wim qui est la première partition du \ disque dur.
Cause
Par défaut, MDT copie LiteTouchPE.wim à partir du partage de déploiement vers la première partition (à laquelle
une lettre de lecteur est affectée) sur le disque dur pour terminer la séquence de tâches sysprep et capturer.
Dans l’exemple ci-dessus, la lettre de lecteur a été affectée en tant que E: \ pour la partition « System Reserved ».
Résolution
Pour résoudre ce problème particulier, suivez les étapes ci-dessous :
N’affectez aucune lettre de lecteur à la partition « System Reserved » afin que MDT puisse copier vers la
partition suivante qui possède la lettre de lecteur.
Ce problème peut également se produire si vous n’avez pas d’espace libre dans le lecteur C, où le lecteur C
est la première partition.
Par défaut, Windows 7 est installé à partir d’un support ou d’un WDS, vous aurez la première partition en tant
que partition « Réservée au système » de taille 100 Mo, sur le disque sélectionné (généralement le disque 0) et
une lettre de lecteur ne sera pas affectée. Si l’image est déployée à partir de MDT (2010), la partition « Réservé
au système » sera de 300 Mo et sera allouée après la partition du système d’exploitation.
Comment capturer l’image à l’aide de MDT : comment exécuter une séquence de tâches Sysprep et capturer à
partir de MDT 2010
Le serveur WDS peut ne pas démarrer et une erreur
est consignée dans le journal système lorsque vous
démarrez le serveur WDS.
Cet article fournit une solution à un problème qui se produit lorsque vous démarrez le serveur Windows
Deployment Services (WDS), il se peut que le serveur WDS ne démarre pas.
Symptômes
Sur un ordinateur Windows server 2008, lorsque vous essayez de démarrer un serveur WDS, il se peut que le
serveur WDS ne démarre pas. En outre, vous pouvez recevoir un message d’erreur et le message est enregistré
dans le journal du serveur WDS.
Ce problème se produit si les conditions suivantes sont vraies :
Le serveur DHCP et le serveur WDS sont installés sur le même ordinateur.
L’option Ne pas écouter sur le por t 67 n’est pas activée dans l’onglet DHCP.
Cause
Lorsque le serveur DHCP et le serveur WDS sont installés sur le même ordinateur, le service WDS tente
d’utiliser le port 67. Toutefois, le serveur DHCP utilise déjà ce port.
Résolution
Pour résoudre ce problème, configurez le client PXE (Pre-boot execution Environment) WDS pour arrêter
l’écoute sur le port 67. Pour ce faire, utilisez l’une des méthodes suivantes, selon votre situation.
Méthode 1
À l’invite de commandes, tapez la commande suivante, puis appuyez sur Entrée :
wdsutil /set-Server /UseDhcpPorts:No
Méthode 2
1. Sélectionnez Démarrer, sélectionnez Exécuter, tapez wdsmgmt.msc, puis appuyez sur OK.
2. Dans la Windows Ser vices de déploiement, développez Ser veurs, cliquez avec le bouton droit sur le
nom du serveur WDS, puis sélectionnez Propriétés.
3. Dans la boîte de dialogue Propriétés du serveur, sélectionnez l’onglet DHCP.
4. Cliquez pour cocher la case Ne pas écouter sur le por t 67, puis sélectionnez Appliquer.
La sous-clé de Registre suivante contrôle si le serveur PXE écoute sur le port DHCP :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE
Pour permettre au serveur PXE d’écouter sur le port 67, définissez la valeur de l’entrée de Registre UseDHCPPorts
sur 1. Utilisez ce paramètre dans les configurations où le serveur PXE Windows services de déploiement et le
serveur DHCP sont installés sur différents ordinateurs.
Pour désactiver l’écoute du serveur PXE sur le port 67, définissez la valeur de Registre UseDHCPPorts sur 0.
Utilisez ce paramètre dans les configurations où le serveur PXE Windows services de déploiement et le serveur
DHCP sont installés sur le même ordinateur.
Références
Pour plus d’informations sur la façon d’activer la journalisation WDS Server, voir Comment activer la
journalisation dans Windows Deployment Services (WDS) dans Windows Server 2003, Windows Server 2008,
Windows Server 2008 R2 et dans Windows Server 2012.
Le programme d’installation sans surveillance
n’utilise pas le nom d’ordinateur spécifié par
l’utilisateur pendant la OOBE pour rejoindre le
domaine
Cet article fournit une solution au problème où le programme d’installation sans surveillance n’utilise pas le
nom d’ordinateur spécifié par l’utilisateur pendant la OOBE pour rejoindre le domaine.
Publication rapide
microsoft. Les informations contenues ici sont créées en réponse à des rubriques émergentes ou uniques, ou
Résultat
Après avoir déployé une image Windows Vista ou une image Windows Server 2008, vous pouvez rencontrer les
Lorsque vous vous connectez à l’ordinateur, vous recevez le message d’erreur suivant : « Échec de la relation
d’confiance entre cette station de travail et le domaine principal ».
Le compte d’ordinateur dans Active Directory est un nom d’ordinateur aléatoire au lieu du nom d’ordinateur
spécifié lors de la première utilisation de l’image lors de la première utilisation de l’image.
Cause
Ce comportement est inhérent au produit. La jointation de domaine se produit beaucoup plus tôt dans le
processus que la page Nom de l’ordinateur en OOBE. La phase OOBE de l’installation ne peut pas modifier
correctement le nom de l’ordinateur dans le domaine si l’ordinateur a déjà été joint à un domaine au cours de
l’installation.
Résolution
Une solution de contournement est la suivante :
1. N’utilisez pas la section Microsoft-Windows-UnattendedJoin pour joindre automatiquement le domaine.
2. Utilisez la section Microsoft-Windows-Shell-Setup\FirstLogonCommands pour exécuter
automatiquement un script post-installation. Ce script consiste à joindre l’ordinateur au domaine et à
redémarrer.
Ce problème est résolu dans Windows 7, car un nom d’ordinateur aléatoire est utilisé et les utilisateurs ne sont
plus invités à entrer le nom de l’ordinateur pendant la phase OOBE.
Exemple de script : joindre un ordinateur à un domaine
https://www.microsoft.com/technet/scriptcenter/scripts/ad/computer/cptrvb06.mspx?mfr=true

fournisseurs respectifs délament toutes les garanties et conditions relatives à ces informations et graphiques
connexes, y compris toutes les garanties implicites et conditions de qualité, l’aptitude à un usage particulier,
l’effort de travail, le titre et la non-contrefaçon. Vous acceptez spécifiquement qu’en aucun cas Microsoft et/ou
ses fournisseurs ne soient responsables de tout dommage direct, indirect, indirect, accidentel, spécial,
conséquencenel, ou de tout dommage quelconque, y compris, sans limitation, de dommages en cas de perte
d’utilisation, de données ou de bénéfices, résultant ou de quelque manière que ce soit lié à l’utilisation ou à
d’un contrat, d’un délit, d’une négligence, d’une responsabilité stricte ou autrement, même si Microsoft ou l’un
de ses fournisseurs a été informé de la possibilité de dommages.
Windows Server 2012 mise à niveau peut échouer
avec une erreur 0x000000C4
Cet article fournit une solution pour corriger les erreurs qui se 0x000000C4 lors de la mise à niveau d’un
Windows Server.
Symptômes
Lorsque vous essayez de mettre à niveau Windows Server 2008 R2 vers Windows Server 2012, le programme
d’installation peut échouer sur les machines virtuelles VMware ESXi avec le message d’erreur suivant :
Votre PC doit redémarrer. Maintenez le bouton d’alimentation enfoncé. Code d’erreur : 0x000000C4
Cause
Windows Server 2012 fenêtre 8 nécessitent des processeurs qui la prise en charge de PAE/NX/SSE2. ESXi
dispose d’une fonctionnalité appelée masquage d’identification du processeur qui masque l’indicateur NX/XD
de l’invité. Le masquage des bits AMD No eXecute (NX) et Intel eXecute Disable (XD) empêche la machine
virtuelle d’utiliser ces fonctionnalités.
Même si PAE/NX/SSE2 sont activés au niveau du matériel hôte, s’ils sont masqués au niveau de l’hyperviseur, les
ordinateurs VM ne peuvent pas utiliser ces fonctionnalités de processeur. Cela entraîne l’échec de l’installation
de Windows.
Ce problème se produit uniquement lorsque WinPE 4.0 ou 5.0 est impliqué dans le processus de mise à
niveau/installation.
Résolution
Pour résoudre ce problème, vous devez « Exposer l’indicateur NX/XD à l’invité » à l’aide des paramètres de
machine virtuelle du client vSphere sous masque CPUID.
This issue is normally not noticed when you create a new VM and select Window Server 2012 during VM
creating as it seems to enable « Expose the NX/XD flag to guest » setting for that VM.
Étant donné que le problème est remarqué avec WinPE 4.0 et 5.0, ce problème est également remarqué lorsque
vous déployez le système d’exploitation à l’aide de System Center 2012 Configuration Manager.
Des informations pas à pas sur la modification de ces paramètres sur le client vSphere sont documentées dans
le document VMware.
Utilisation des ID de langue pour identifier les packs
de langue pour les contrôleurs de domaine AD DS
et AD LDS
Cet article explique comment résoudre l’ID de langue par le nom du pack de langue à installer.
Résumé
Vous pouvez remarquer qu’un événement semblable à l’événement suivant est enregistré sur les contrôleurs de
domaine AD DS (Active Directory Domain Services) ou AD LDS (Active Directory Lightweight Directory
Services) :
Type d’événement :
Erreur
Source de l’événement : ISAM NTDS
Catégorie d'événement : Général
Description :
NTDS (248) Doit installer la prise en charge de la langue pour les ID de langue 0x411.
IMPORTANT
de façon incorrecte. Avant de le modifier, voir Comment faire pour la back up et la restauration du Registre dans Windows
cas de problèmes se produisent.
Vous pouvez identifier le nom du pack de langue à installer en cherchant l’ID de langue.
Vous pouvez trouver l’ID de langue dans Windows registre. Pour ce faire, démarrez l’Éditeur du Registre, puis
regardez sous la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NTDS\Language
Vous pouvez également rechercher l’ID de langue dans la table de mappage LCID-Paramètres régionaux. Pour
l’exemple d’ID de langue (411) mentionné dans la section Résumé, la valeur indique la langue japonaise
(répertoriée comme 0411 dans le tableau de mappage).
Pour plus d’informations sur les identificateurs d’objets de tri (OID) que le contrôle de tri utilise, voir
LDAP_SERVER_SORT_OID et LDAP_SERVER_RESP_SORT_OID.
Windows Le service de déploiement ne parvient
pas à démarrer avec les informations d’erreur 0x5
Cet article fournit de l’aide pour corriger les erreurs 0x5 qui se produit lorsque vous démarrez le service
Windows Déploiement.
Symptômes
Lorsque vous essayez de démarrer le service Windows Déploiement, les ID d’événement suivants peuvent être
enregistrés :
Source de l’événement : WDSServer

Description :
Une erreur s’est produite lors de la tentative de démarrage du Windows services de déploiement.
Informations sur l’erreur : 0x5
Source de l’événement : WDSServer
Description :
Une erreur s’est produite lors de la tentative d’initialisation du fournisseur WDSPXE à partir
C:\WINDOWS\system32\wdspxe.dll. Windows Le serveur des services de déploiement sera arrêté.
Informations sur les erreurs 0x5
Source de l’événement : WDSPXE
Description :
Une erreur s’est produite lors de la tentative d’initialisation du fournisseur BINSVC. Étant donné que le
fournisseur est marqué comme critique, le serveur des services de déploiement Windows sera arrêté.
Informations sur l’erreur : 0x5
Cause
Cela peut se produire si vous êtes connecté en tant qu’administrateur local ou si le compte d’ordinateur du
serveur WDS ne présente pas les autorisations de sécurité correctes
Résolution
Pour résoudre ce problème, assurez-vous que vous êtes connecté en tant qu’administrateur de domaine ou
Enterprise et vérifiez les autorisations pour le compte d’ordinateur en faisant ce qui suit :
1. Connectez-vous à un contrôleur de domaine et lancez Utilisateurs et ordinateurs Active Director y
2. Activer les fonctionnalités avancées à partir du menu Affichage
3. Recherchez l’objet serveur pour le serveur WDS et, dans Propriétés, sélectionnez l’onglet Sécurité
4. Vérifiez les autorisations suivantes :
Administrateurs de domaine : contrôle total
Administrateurs de l’entreprise : contrôle total
Opérateurs de compte : contrôle total
Système : contrôle total
SELF : créer tous les objets enfants, supprimer tous les objets enfants, écriture validée dans le nom d’hôte
DNS, écriture validée dans le nom principal de service, lecture d’informations personnelles, écriture
d’informations personnelles
Pour plus d’informations, voir ID d’événement 1804 — Intégration Active Directory
Erreur lors de l’installation du wi-fi dans Windows
Server 2012 : le service
MSSQL$MICROSOFT##WID n’a pas pu se
connecter en tant que service
NT\MSSQL$MICROSOFT##WID
Cet article traite d’un problème dans lequel vous ne pouvez pas installer Base de données interne Windows
(WID) sur un ordinateur exécutant Windows Server 2012.
Symptômes
Lorsque vous installez les services AD FS (Active Directory Federation Services) à l’aide de l’Assistant Ajout de
rôles et de fonctionnalités dans Windows Server 2012, l’installation wid échoue. Et vous recevez le message
Le service MSSQL$MICROSOFT##WID n’a pas pu se connecter en tant que service

NT\MSSQL$MICROSOFT##WID avec le mot de passe actuellement configuré en raison de l’erreur suivante :
Service : MSSQL$MICROSOFT##WID
Domaine et compte : NT SERVICE\MSSQL$MICROSOFT##WID
Affectez « Se connecter en tant que service » au compte de service sur cet ordinateur. Vous pouvez utiliser
l’Paramètres de sécurité locale (Secpol.msc) pour ce faire. Si cet ordinateur est un nœud dans un cluster,
vérifiez que ce droit d’utilisateur est affecté au compte de service de cluster sur tous les nœuds du cluster. Si
vous avez déjà affecté ce droit d’utilisateur au compte de service et que le droit d’utilisateur semble être
supprimé, vérifiez auprès de votre administrateur de domaine si un objet de stratégie de groupe associé à ce
nœud peut supprimer le droit.
Cause
Lorsque WID est installé, le NT SERVICE\MSSQL$MICROSOFT##WID compte virtuel local est créé. Ce compte est
accordé à Log on as a service l’utilisateur par la stratégie de groupe locale. Si un objet de stratégie de groupe
lié à un site, un domaine ou une unité d’organisation a la valeur du paramètre de stratégie de groupe local, le
compte NT SERVICE\MSSQL$MICROSOFT##WID n’a pas les droits d’utilisateur nécessaires. Ainsi, WID ne peut
pas être installé.
Pour contourner le problème, utilisez l’une des méthodes suivantes :
Attribuez Log on as a service à l’utilisateur le droit à NT SERVICE\ALL SERVICES dans l’GPO qui définit le
droit de l’utilisateur.
Exclure l’ordinateur de l’GPO qui définit le droit de l’utilisateur.
Vous pouvez également faire face à d’autres symptômes dans cette situation. Par exemple, le service WID peut
sembler installé, mais il ne démarre pas. En outre, l’Assistant Ajout de rôles et de fonctionnalités indique qu’un
redémarrage est en attente.
Windows Server affiche la configuration PCR7
comme « Liaison impossible »
Cet article présente le problème de liaison impossible dans msinfo32 et la cause du problème. Cela s’applique
aux clients Windows client et Windows Server.
Configuration de PCR7 dans msinfo32

Windows Server est installé sur une plateforme de démarrage sécurisée.
Vous activez le module de plateforme fiable (TPM) 2.0 dans l’interface UEFI (Unified Extensible Firmware
Interface).
Vous pouvez activer BitLocker.
Vous installez les pilotes de chipset et mettez à jour le dernier rapport mensuel Microsoft.
Vous exécutez également tpm.msc pour vous assurer que l’état du TPM est correct. L’état affiche Le TPM est
prêt à être utilisé .
Dans ce scénario, lorsque vous exécutez msinfo32 pour vérifier la configuration de PCR7, la liaison n’est pas
possible .
Cause du message inattendu

BitLocker accepte uniquement le certificat MICROSOFT Windows PCA 2011 à utiliser pour signer les
composants de démarrage précoce qui seront validés lors du démarrage. Toute autre signature présente dans le
code de démarrage entraîne l’utilisation par BitLocker du profil de TPM 0, 2, 4, 11 au lieu de 7, 11. Dans certains
cas, les binaires sont signés avec le certificat UEFI CA 2011, ce qui vous empêche de lier BitLocker à PCR7.
NOTE
L’AC UEFI peut être utilisée pour signer des applications tierces, des roms d’option ou même des chargeurs de démarrage
tiers qui peuvent charger du code malveillant (signé par l’ac UEFI). Dans ce cas, BitLocker bascule vers PCR 0, 2, 4, 11.
Dans le cas de PCR 0,2,4,11, Windows mesure les h biens binaires exacts au lieu du certificat de l’ac.
Windows est sécurisé indépendamment de l’utilisation du profil de TPM 0, 2, 4, 11 ou profil 7, 11.
Pour vérifier si votre appareil répond aux exigences :
1. Ouvrez une invite de commandes avec élévation de niveau élevé et exécutez la msinfo32 commande.
2. Dans le résumé système , vérifiez que le mode BIOS est UEFI et que la configuration PCR7 est liée .
3. Ouvrez une invite de commandes PowerShell avec élévation de élévation de niveaux et exécutez la
commande suivante :
Confirm-SecureBootUEFI
Vérifiez que la valeur True est renvoyée.
4. Exécutez la commande PowerShell suivante :
manage-bde -protectors -get $env:systemdrive
Vérifiez que le lecteur est protégé par PCR 7.
PS C:\Windows\system32> manage-bde -protectors -get $env:systemdrive

BitLocker Drive Encryption: Configuration Tool version 10.0.22526
Copyright (C) 2013 Microsoft Corporation. All rights reserved.
Volume C: [OSDisk]
All Key Protectors
TPM:
ID: <GUID>
PCR Validation Profile:
7, 11
(Uses Secure Boot for integrity validation)
Windows server support and installation instructions
for the AMD EPYC 7000 Series server processors
Cet article présente les instructions d’installation et les instructions de prise en charge du système d’exploitation
Windows Server pour les processeurs de serveurs de la série EPYC AMD. En outre, cet article décrit plusieurs
limitations connues de la prise en charge de ces processeurs.
prise en charge Windows server

Cette section fournit la Windows server par rapport au nombre total de processeurs logiques.
Windows Server 2019
Windows Server 2019 prend en charge tous les processeurs AMD EPYC 7000 Series. Pour les
processeurs AMD EPYC 7002 et EPYC 7003 Series, utilisez au moins l’image multimédia actualisée
publiée début octobre 2019.
Windows Server 2016
Windows Server 2016 prend en charge tous les processeurs EPYC AMD. La prise en charge est limitée à
un maximum de 255 processeurs logiques. Windows Server 2016 ne prend pas en charge le mode
x2APIC. Pour les processeurs de série AMD EPYC 7002 et 7003, désactivez le mode x2APIC et LOMMU
dans le système d’entrée/sortie de base (BIOS) de l’ordinateur. Pour les serveurs à double processeur
utilisant des processeurs AMD EPYC 7002 ou 64 cœurs série 7003, assurez-vous que l’outil SMT est
également désactivé dans le BIOS.
Windows Server 2012 R2 prend en charge tous les processeurs EPYC AMD. La prise en charge est limitée
à un maximum de 255 processeurs logiques. Windows Server 2012 R2 ne prend pas en charge le mode
x2APIC. Pour les processeurs AMD EPYC 7002 et 7003 Series, désactivez le mode x2APIC et l’IOMMU
dans le BIOS. Pour les serveurs à double processeur utilisant 64 cœurs, assurez-vous que l’outil SMT est
également désactivé dans le BIOS.
NOTE
Windows Server 2012 R2 est en cycle de prise en charge étendu. Nous vous recommandons de mettre à niveau le
système d’Windows Server 2019 le plus récent.
Prise en charge de la référence SKU du processeur AMD EPYC

AMD offre un large éventail de processeurs EPYC 7000 Series, y compris les processeurs EPYC 7002 et EPYC
7003 Series. Vous pouvez déterminer les SSO de modèle de processeur spécifiques et les threads maximum
correspondants dans les articles suivants :
Processeurs AMD EPYC ™ 7002 Series
Processeurs AMD EPYC ™ 7003 Series
Pour les version du système d’exploitation Windows Server antérieures à Windows Server 2019 et sur les
configurations de serveur où les deux sockets de processeur sont remplies, le nombre total de threads de
processeur activés doit être inférieur à 256 et le rester pendant le processus d’installation et de redémarrage du
Installer Windows server sur un ordinateur qui utilise les processeurs

AMD EPYC 7002 et 7003 Series
NOTE
Lors de l’installation d’une version de Windows Server, utilisez la dernière image multimédia d’installation à partir d’un
canal de licence approprié. Une fois l’installation Windows initiale terminée, mettez à jour le système vers la version la
Windows update la plus récente.
Pour les serveurs configurés pour activer 256 threads processeur et qui exécutent Windows Server 2012 R2,
Windows Server 2016 ou Windows Server 2019 (avant octobre 2019), suivez les étapes suivantes :
1. Désactivez les paramètres SMT (tels que le paramètre processeurs logiques) dans le BIOS.
2. Désactivez les paramètres x2APIC et IOMMU dans le BIOS.
3. Utilisez le support du système d’exploitation pour installer Windows Server.
4. Installez les dernières mises à jour Windows Server.
5. Redémarrez le système et activez les paramètres SMT, x2APIC et IOMMU pour Windows Server 2019 dans le
BIOS.
Limitations connues de l’interface utilisateur pour les requêtes

Windows Server 2012R2/2016 Task Manager, WMI ou PowerShell
pour obtenir des informations sur l’UC
Le Gestionnaire des tâches n’affiche pas les tailles de cache L2 et L3, ni les tailles de cache L2 et L3
incorrectes
Par exemple, voir la figure suivante.
Le Gestionnaire des tâches affiche un nombre incorrect de sockets avec plus de 64 processeurs logiques
activés
Par exemple, pour un système à un seul socket UC, le Gestionnaire des tâches affiche deux sockets. Pour un
système à deux sockets, le Gestionnaire des tâches affiche quatre sockets.
Le Gestionnaire des tâches affiche un nombre incorrect de nodes NUMA avec plus de 64 processeurs
logiques activés
Par exemple, pour un système à un seul socket, le Gestionnaire des tâches affiche deux nodes NUMA. Pour un
système à deux sockets, le Gestionnaire des tâches affiche quatre nodes NUMA.
Les clients WSUS (Windows Server Update
Services) ne peuvent pas installer les mises à jour
lorsque Symantec Endpoint Protection est installé
sur le même site Web avec WSUS
Cet article fournit une solution à un problème dans lequel les clients Windows Server Update Services (WSUS)
ne peuvent pas installer de mises à jour lorsque Symantec Endpoint Protection est installé sur le même site
Web.
Symptôme
Les clients WSUS n’installent pas les mises à jour approuvées à partir de WSUS.
Symantec Endpoint Protection Manager est en mesure de télécharger les définitions actuelles sur les clients.
Les ordinateurs clients WSUS sont configurés correctement pour se connecter à WSUS et s’affichent sur la
console d’administration WSUS. Le serveur WSUS est fonctionnel à tous les égards.
Cause
WSUS et symantec Endpoint Protection Manager utilisent tous deux un répertoire virtuel appelé « Contenu ». Si
WSUS et Symantec sont tous deux installés sur le même site Web par défaut à l’aide du port 80, seule la
dernière installation pourra servir les mises à jour aux clients.
Choisissez l’une des méthodes suivantes pour résoudre ce problème.
Résolution 1 : déplacer le répertoire de contenu WSUS vers un nouvel

emplacement à l’aide de l’utilitaire Wsusutil
Pour déplacer le répertoire de contenu WSUS, suivez les étapes suivantes :
1. Connectez-vous au serveur WSUS à l’aide d’un compte membre du groupe Administrateurs local.
2. Créez un dossier de destination pour le répertoire de contenu WSUS sur une partition NTFS. Le nouveau
dossier de destination doit avoir les mêmes autorisations que celle définies sur le dossier d’origine.
3. Cliquez sur Démarrer, cliquez avec le bouton droit sur Invite de commandes, puis cliquez sur Exécuter
en tant qu’administrateur.
4. Accédez au répertoire qui contient l’utilitaire Wsusutil.exe:
cd WSUSInstallDir\Tools
wsusutil movecontent contentpath logfile -skipcopy

NOTE
L’espace réservé de chemin de contenu est la nouvelle racine des fichiers de contenu (le chemin d’accès doit
exister) et logfile est le chemin d’accès et le nom de fichier du fichier journal à créer.
6. Appuyez sur ENTRÉE. Wsusutil fait les choses suivantes :

a. Met à jour la base de données WSUS pour faire référence au nouvel emplacement des fichiers de
mise à jour.
b. Garantit que le contenu et les métadonnées sont synchronisés.
c. Conserve l’ancien répertoire de contenu. Il reste intact et n’est pas supprimé par l’utilitaire.
d. L’utilisation du paramètre garantit que les fichiers du répertoire de contenu existant ne sont pas
copiés dans le nouveau -skipcopy dossier de destination WSUS.
7. Symantec Endpoint Protection Manager peut désormais utiliser le répertoire de contenu par défaut.
NOTE
Vous devrez peut-être réparer ou réinstaller Symantec Endpoint Protection Manager.
Résolution 2 : déplacer WSUS vers le port 8530 à l’aide de l’utilitaire

Wsusutil
Cette option fait en sorte qu’IIS utilise l’autre port, mais tous les fichiers restent en place et sont toujours utilisés.
Vous devrez peut-être reconfigurer les paramètres de stratégie de groupe du client WSUS pour le nouveau port.
Pour déplacer WSUS vers le port 8530, suivez les étapes suivantes :
1. Connectez-vous au serveur WSUS à l’aide d’un compte membre du groupe Administrateurs local.
2. Sur le serveur WSUS, cliquez sur Démarrer, cliquez avec le bouton droit sur Invite de commandes, puis
cliquez sur Exécuter en tant qu’administrateur.
3. Accédez au répertoire qui contient l’utilitaire Wsusutil.exe:
cd WSUSInstallDir\Tools
wsusutil usecustomwebsite true
5. Appuyez sur ENTRÉE. WSUS s’exécute désormais sur le port 8530.

6. Le cas échéant, reconfigurer le paramètre de stratégie de groupe du client WSUS pour le port 8530.
7. Symantec Endpoint Protection Manager peut désormais utiliser le répertoire de contenu par défaut et le
port 80.
NOTE
Vous devrez peut-être réparer ou réinstaller Symantec Endpoint Protection Manager.
Résolution 3 : déplacer Symantec Endpoint Protection Manager vers
un autre port
Pour plus d’informations, voir la documentation Symantec sur les autres numéro de port et procédures pris en
charge.
Documentation de résolution des problèmes de
stratégie de groupe pour Windows Server
problèmes liés à la stratégie de groupe et à les résoudre eux-mêmes. Les rubriques sont divisées en sous-
Sous-catégories de stratégie de groupe

AppLocker ou stratégies de restriction logicielle
Déploiement de logiciels via une stratégie de groupe
Gestion des stratégies de groupe : GPMC ou AGPM
Gestion des mappages de disques par le biais d’une stratégie de groupe
Gestion des paramètres Internet Explorer par le biais d’une stratégie de groupe
Gestion des imprimantes par le biais d’une stratégie de groupe
Gestion des appareils amovibles via la stratégie de groupe
Problèmes liés à l’application d’objets de stratégie de groupe à des utilisateurs ou des ordinateurs
Filtrage de sécurité et ciblage au niveau de l’élément
Problèmes d’accès ou de réplication Sysvol
Comment appliquer des objets de stratégie de
groupe aux serveurs Terminal Services
Cet article explique comment appliquer des objets de stratégie de groupe aux serveurs des services Terminal
Services.
Résumé
Les serveurs Windows Terminal Server 2003 et les serveurs Des services Terminal Server 2000 de Microsoft
Windows 2000 sont installés pour les utilisateurs en mode serveur d’applications. Lorsque les serveurs Des
services Terminal Server sont dans un domaine Active Directory, l’administrateur de domaine implémente des
objets de stratégie de groupe (GGP) sur le serveur des services Terminal Server pour contrôler l’environnement
utilisateur. Cet article décrit le processus recommandé d’application des G GPO aux services Terminal Services
sans affecter les autres serveurs du réseau.
Il existe deux méthodes pour appliquer des G GPO aux services Terminal Services sans affecter les autres
serveurs du réseau.
Méthode 1
Placez les ordinateurs Terminal Server dans leur propre unité d’organisation. Cette configuration permet de
placer des paramètres de configuration d’ordinateur pertinents dans des G GPO qui s’appliquent uniquement
aux ordinateurs Terminal Server. Cette configuration n’affecte pas l’expérience utilisateur sur les stations de
travail ou sur d’autres serveurs et vous permet de créer une expérience Terminal Server étroitement contrôlée
pour les utilisateurs. Cette OU ne doit pas contenir d’utilisateurs ou d’autres ordinateurs afin que les
administrateurs de domaine peuvent affiner l’expérience des services Terminal Services. L’ou peut également
être déléguée pour le contrôle à des groupes subordonnés tels que des opérateurs serveur ou des utilisateurs
individuels.
Pour créer une nouvelle ouo pour les serveurs des services Terminal Services, suivez les étapes suivantes :
1. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis cliquez sur
Utilisateurs et ordinateurs Active Director y.
2. Développez le volet gauche.
3. Cliquez sur domainname.xxx .
4. Dans le menu Action, cliquez sur Nouveau, puis sur Unité d’organisation.
5. Dans la zone Nom, tapez un nom pour le serveur des services Terminal Server.
6. Cliquez sur OK.
La nouvelle ou les services Terminal Services apparaît désormais dans la liste dans le volet gauche et ne
contient aucun objet par défaut. Les serveurs des services Terminal Services résident dans l’ou des
ordinateurs ou dans l’ou des contrôleurs de domaine.
7. Recherchez, puis cliquez sur le ou les serveurs des services Terminal Server, cliquez sur Action, puis sur
Déplacer.
8. Dans la boîte de dialogue Déplacer, cliquez sur le ou les nouveaux serveurs des services Terminal Server,
9. Cliquez sur la nouvelle ou des services Terminal Services pour vérifier que le déplacement s’est
correctement produit.
Pour créer un objet de stratégie de groupe des services Terminal Services, suivez les étapes suivantes :
1. Cliquez sur la nouvelle ou des services Terminal Services.
2. Dans le menu Action, cliquez sur Propriétés.
3. Cliquez sur l’onglet Stratégie de groupe.
4. Cliquez sur Nouveau pour créer l’objet Nouvelle stratégie de groupe.
5. Cliquez sur Modifier pour modifier la stratégie de groupe.
NOTE
La plupart des paramètres pertinents sont sous Configuration ordinateur, Sécurité Paramètres ou Stratégies
locales . Par exemple, sous Attribution des droits d’utilisateur dans la liste à droite, vous trouverez Log on
Locally . Ce paramètre est requis pour la connexion à une session sur les services Terminal Services. Vous
trouverez également Access sur cet ordinateur à par tir du réseau. Ce paramètre est requis pour se
connecter au serveur en dehors d’une session des services Terminal Server. C’est également là que vous pouvez
empêcher les utilisateurs de pouvoir arrêter le système. Le dossier Options de sécurité est l’endroit où de
nombreuses restrictions doivent être imposées et où il existe des paramètres similaires au fichier NTConfig.pol
dans Windows NT 4.0 Server et Terminal Server Edition. Paramètres la partie utilisateur de la stratégie ne doit pas
être appliquée ici, car les utilisateurs n’ont pas été placés dans cette ouv. avec le serveur des services Terminal
Server. Cet article est écrit pour l’implémentation de la stratégie d’ordinateur.
6. Lorsque les modifications sont terminées, fermez l’éditeur de stratégie de groupe, puis cliquez sur Fermer
pour fermer les propriétés de l’ou.
Méthode 2
Utilisez la fonctionnalité de bouclation de stratégie de groupe pour appliquer les paramètres d’un GPO de
configuration utilisateur aux utilisateurs uniquement lorsqu’ils se connectent aux serveurs Terminal Servers.
Lorsque le traitement en boucle des GPO est activé pour les ordinateurs d’une ou d’une autre personne qui ne
contient que des serveurs Terminal Servers, ces ordinateurs appliquent les paramètres de configuration
utilisateur de l’ensemble des GPO qui s’appliquent à cette ou. En outre, ces ordinateurs appliquent les
paramètres de configuration utilisateur des G GPO qui sont liés ou hérités par l’ou qui contient le compte de
l’utilisateur.
Cette implémentation est décrite dans l’article suivant de la Base de connaissances :
231287 loopback de la stratégie de groupe
Dans la mesure du possible, les services Terminal Services doivent être installés sur des serveurs membres
plutôt que sur des contrôleurs de domaine, car les utilisateurs doivent se connecter aux droits d’utilisateur
localement. Lorsque le droit d’accès local est affecté aux contrôleurs de domaine, il est affecté à chaque
contrôleur de domaine dans le domaine en raison de la base de données Active Directory partagée. Par défaut,
les serveurs membres se sont vus accorder des droits d’accès local aux utilisateurs dans la stratégie de sécurité
locale lorsque les services Terminal Server sont installés en mode Serveur d’applications.
186529 stratégie locale ne vous permet pas de vous connecter de manière interactive
Le compte d’ordinateur du serveur Terminal Server doit être ajouté aux propriétés de sécurité de l’objet de
groupe en cours de création pour la boucle. Pour ce faire, suivez les étapes suivantes :
1. Sélectionnez l’GPO créé pour la boucle, puis cliquez sur Propriétés.
2. Cliquez sur l’onglet Sécurité, puis sur Ajouter.
3. Dans la zone Sélectionner des utilisateurs, des ordinateurs ou des groupes, sélectionnez le compte
d’ordinateur, puis cliquez sur OK.
4. Cliquez sur le compte d’ordinateur dans la zone Groupes ou noms d’utilisateurs.
5. Dans la zone Autorisations pour le nom de l’ordinateur, cliquez pour cocher les cases à cocher Lecture et
Appliquer la stratégie de groupe dans la colonne Autoriser.
6. Cliquez deux fois sur OK pour fermer et enregistrer les paramètres de stratégie.
Comment modifier l’emplacement du fichier MSI
dans l’GPO de déploiement de logiciel (plusieurs
chemins d’accès UNC pour le même package)
Cet article explique comment modifier l’emplacement du fichier MSI dans l’objet de groupe de déploiement de
logiciels et définir les chemins d’accès UNC multiples pour le même package MSI.
Résumé
Scénario : 1
Vous créez un GPO pour le déploiement d’un package MSI et devez modifier l’emplacement du package MSI
(chemin UNC). Vous devez créer un nouvel GPO pour le package et ce nouvel GPO sera appliqué à tous les
ordinateurs de l’ou, ce qui permettra de redéployer le même package sur les ordinateurs qui ont déjà le logiciel
(installé à partir de l’GPO précédent).
Scénario : 2
Vous souhaitez fournir plusieurs chemins d’accès pour le même package d’installation et le faire passer via un
GPO, mais l’interface utilisateur graphique ne vous offre qu’une seule option pour sélectionner l’emplacement
du package.
Vous pouvez contourner ce sujet à l’aide des méthodes suivantes :
1. Ouvrez l’objet de groupe dans l’objet package qu’il est défini, cliquez avec le bouton droit sur l’objet
Package, puis sélectionnez Propriétés.
2. Cliquez sur l’onglet Déploiement, puis sur le bouton Avancé. Notez l’emplacement du nom du script. Vous
aurez besoin du CLSID (nombre alphanumérique long) directement après la notation \Policies.
3. Ouvrez l’éditeur ADSI, connectez-vous à votre domaine et accédez à l’arborescence Système\Stratégies
sur le côté gauche de la fenêtre. Recherchez le CLSID que vous avez noté ci-dessus.
4. Développez cette arborescence CLSID, puis développez les arborescences suivantes pour obtenir l’objet
package défini réel : CN=Ordinateur \ CN=Magasin de classes \ CN=Packages.
5. Cliquez avec le bouton droit sur l’objet Package et sélectionnez Propriétés. Accédez à la propriété
Facultative ' msiFileList '. Cette propriété contient le chemin d’accès UNC de l’emplacement du fichier MSI
Installer. Modifiez cette valeur pour représenter le nouveau chemin d’accès UNC.
NOTE
Il est possible de définir plusieurs chemins UNC pour un objet package, en commençant par 0:, puis 1: et ainsi de
suite. Si vous modifiez le chemin d’accès UNC, tapez le nouveau chemin d’accès UNC, avec le préfixe 0, puis cliquez
sur le bouton Ajouter. Sélectionnez l’ancien chemin d’accès UNC et cliquez sur le bouton Supprimer.
6. Le chemin UNC de l’objet Package a été mis à jour pour refléter le nouveau chemin d’accès UNC.
Comment résoudre les problèmes d’installations
logicielles à l’aide Windows journalisation de
débogage de gestion des applications
Cet article explique comment résoudre les problèmes d’installation de logiciels à l’aide Windows journalisation
de débogage de gestion des applications.
IMPORTANT
et assurez-vous que vous savez le restaurer en cas de problème. Pour plus d’informations sur la façon de restaurer, de
restaurer et de modifier le Registre, cliquez sur le numéro d’article suivant pour afficher l’article de la Base de
connaissances Microsoft : 256986 Description du Registre Microsoft Windows

Résumé
Lorsqu’un problème se produit avec un programme déployé sur un ordinateur client à l’aide de la stratégie de
groupe, un fichier journal (Appmgmt.log) peut être généré. Ce fichier journal enregistre les informations
relatives à l’annonce, à la publication ou à l’affectation d’applications Windows Installer à l’aide de la stratégie de
groupe. Ces informations, en association avec la journalisation à partir du service Windows Installer, peuvent
aider à déterminer la cause d’un problème d’installation de logiciels.
Pour plus d’informations sur l’Windows journalisation du programme d’installation, cliquez sur le numéro
223300 Comment activer Windows journalisation du programme d’installation
Pour activer la journalisation des diagnostics du traitement de l’installation des logiciels de la stratégie de
groupe, modifiez le Registre sur l’ordinateur sur lequel le programme sera installé.
Pour activer la journalisation des diagnostics du traitement de l’installation des logiciels de la stratégie de
groupe, suivez les étapes suivantes :
WARNING
2. Dans le volet gauche, recherchez la sous-clé de Registre suivante, puis cliquez dessus :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics
NOTE
Vous de devez peut-être créer la sous-clé de Registre Diagnostics.
4. Tapez AppMgmtDebugLevel, puis appuyez sur Entrée.
5. Double-cliquez sur AppMgmtDebugLevel , tapez 4b dans la zone de données Valeur, puis cliquez sur OK .
Une fois cette modification apportée au Registre, un fichier journal nommé Appmgmt.log est créé lors du
traitement de la stratégie de groupe. Le fichier Appmgmt.log se trouve dans le dossier %SystemRoot% Debug
UserMode sur l’ordinateur sur lequel la valeur de Registre \ \ AppMgmtDebugLevel est activée.
NOTE
Après avoir dépanner les installations logicielles à l’aide de la journalisation de débogage de gestion des applications
Windows, nous vous recommandons de supprimer la valeur de Registre AppMgmtDebugLevel afin d’éviter la
dégradation des performances.
En raison des modifications apportées au code dans la gestion des applications Windows 8, la journalisation du
débogage ne fonctionne pas dans Windows 8 ou Windows Server 2012.
Comment utiliser la stratégie de groupe pour
configurer l’Windows services Terminal Server 2003
Cet article pas à pas décrit comment utiliser la stratégie de groupe pour configurer l’accès automatique aux
services Terminal Server 2003 de Microsoft Windows Server 2003.
Résumé
Lorsque vous utilisez la connexion Bureau à distance pour vous connecter à un ordinateur Windows Server
2003 exécutant les services Terminal Server, vous pouvez fournir vos informations de connexion avant d’établir
la connexion. De cette façon, vous passez automatiquement ces informations d’identification au serveur.
Vous spécifiez votre nom d’utilisateur, votre mot de passe et votre domaine d’ouverture de connexion sous
l’onglet Général dans la boîte de dialogue Connexion Bureau à distance (dans la fenêtre client Connexion Bureau
à distance, cliquez sur Options, puis cliquez sur l’onglet Général). Lorsque vous cliquez sur Connecter, les
informations de connexion que vous avez tapées deviennent le paramètre par défaut pour toutes les connexions
Bureau à distance et sont enregistrées dans le fichier Default.rdp.
Étapes d’utilisation de la stratégie de groupe pour configurer

l’Windows services Terminal Server 2003
Pour implémenter entièrement une connexion automatique dans laquelle l’utilisateur n’est pas invité à fournir
un mot de passe lors de la connexion, le client Always prompt pour le mot de passe lors du paramètre de
stratégie de connexion doit être désactivé sur le serveur. Ainsi, les utilisateurs peuvent se connecter
automatiquement aux services Terminal Services en fournissant leur mot de passe dans le client De connexion
Bureau à distance.
1. Cliquez sur Démarrer, cliquez sur Exécuter, tapez mmc dans la zone de texte Ouvrir, puis cliquez sur OK.
2. Dans le menu Fichier, cliquez sur Ajouter/Supprimer un composant logiciel enfichable .
3. Cliquez sur Ajouter.
4. Cliquez sur Éditeur d’objets de stratégie de groupe, puis sur Ajouter.
5. Cliquez sur l’objet de stratégie de groupe (GPO) cible. L’objectif de groupe par défaut est Ordinateur local.
Cliquez sur Parcourir pour sélectionner l’GPO de votre choix, puis cliquez sur Terminer.
6. Cliquez sur Fermer, puis sur OK.
7. Développez l’objet de stratégie de groupe, développez Configuration ordinateur, développez Modèles
d’administration, développez Windows Composants, développez les services Terminal Services, puis cliquez
sur Chiffrement et sécurité.
8. Dans le volet droit, double-cliquez sur Toujours invite le client à obtenir le mot de passe lors de la
connexion.
9. Cliquez sur Désactivé.
10. Cliquez sur OK, puis quittez le logiciel en snap-in Éditeur d’objets de stratégie de groupe.
Comment utiliser stratégie de groupe pour
déployer une restauration de problème connu
Cet article explique comment configurer stratégie de groupe pour utiliser une définition de stratégie kir (Known
Issue Rollback) qui active un KIR sur les appareils gérés.
S’applique à : Windows Server 2019, version 1809 et versions ultérieures ; Windows 10, version 1809 et
versions ultérieures
Résumé
Microsoft a développé une nouvelle technologie de maintenance Windows nommée KIR pour Windows Server
2019 et Windows 10, versions 1809 et ultérieures. Pour les versions prises en charge de Windows, un KIR
restaure une modification spécifique qui a été appliquée dans le cadre d’une mise en production de Windows
Update non-sécurité. Toutes les autres modifications apportées dans le cadre de cette version restent intactes. À
l’aide de cette technologie, si une mise à jour Windows provoque une régression ou un autre problème, vous
n’avez pas besoin de désinstaller l’intégralité de la mise à jour et de retourner le système à la dernière bonne
configuration connue. Vous ne restrimez que la modification à l’origine du problème. Cette restauration est
temporaire. Une fois que Microsoft a publié une nouvelle mise à jour qui résout le problème, la restauration
n’est plus nécessaire.
IMPORTANT
Les kirs s’appliquent uniquement aux mises à jour non liées à l’insécurité. Cela est dû au fait que le fait de restaurer un
correctif pour une mise à jour non sécurisée ne crée pas de vulnérabilité de sécurité potentielle.
Microsoft gère le processus de déploiement KIR pour les appareils non professionnels. Pour les appareils
d’entreprise, Microsoft fournit des fichiers MSI de définition de stratégie KIR. Les entreprises peuvent ensuite
utiliser stratégie de groupe pour déployer des KIR dans des domaines Azure Active Directory (Azure AD) ou
services de domaine Active Directory (AD DS) hybrides.
NOTE
Vous devez redémarrer les ordinateurs affectés pour appliquer cette modification stratégie de groupe.
Processus KIR
Si Microsoft détermine qu’une mise à jour de non-sécurité présente une régression critique ou un problème
similaire, Microsoft génère une KIR. Microsoft annonce la KIR dans le tableau de bord d’intégrité Windows et
ajoute les informations aux emplacements suivants :
Section Problèmes connus de l’article Windows Update KB applicable
Liste des problèmes connus dans le tableau de bord de mise en production de Windows Health pour
https://aka.ms/windowsreleasehealth les versions affectées de Windows (par exemple, Windows 10, version
20H2 et Windows Server, version 20H2)
Pour les clients non professionnels, le processus Windows Update applique automatiquement la KIR. Aucune
action de l’utilisateur n’est requise.
Pour les clients d’entreprise, Microsoft fournit un fichier MSI de définition de stratégie. Les clients d’entreprise
peuvent propager le KIR aux systèmes managés à l’aide de l’infrastructure stratégie de groupe d’entreprise.
Pour voir un exemple de fichier MSI KIR, téléchargez Windows 10 (2004 & 20H2) Known Issue Rollback 031321
01.msi.
Une définition de stratégie KIR a une durée de vie limitée (quelques mois, au maximum). Une fois que Microsoft
a publié une mise à jour modifiée pour résoudre le problème d’origine, le KIR n’est plus nécessaire. La définition
de stratégie peut ensuite être supprimée de l’infrastructure stratégie de groupe.
Appliquer KIR à un seul appareil à l’aide de stratégie de groupe

Pour utiliser stratégie de groupe pour appliquer un KIR à un seul appareil, procédez comme suit :
1. Téléchargez le fichier MSI de définition de stratégie KIR sur l’appareil.
IMPORTANT
Assurez-vous que le système d’exploitation répertorié dans le nom de fichier .msi correspond au système
d’exploitation de l’appareil que vous souhaitez mettre à jour.
2. Exécutez le fichier .msi sur l’appareil. Cette action installe la définition de stratégie KIR dans le modèle
d’administration.
3. Ouvrez l’éditeur de stratégie de groupe local. Pour ce faire, sélectionnez Démarrer , puis entrez gpedit.msc.
4. Sélectionnez Local Computer Policy > Computer Configuration > Administrative Templates > KB
####### Issue XXX Rollback > Windows 10, version YYMM .
NOTE
Dans cette étape, ####### il s’agit du numéro d’article de la base de connaissances de la mise à jour à l’origine du
problème. XXX est le numéro de problème et YYMM est le numéro de version Windows 10.
5. Cliquez avec le bouton droit sur la stratégie, puis sélectionnez Modifier > désactivé OK > .
6. Redémarrez lʼappareil.
Pour plus d’informations sur l’utilisation de l’éditeur de stratégie de groupe local, consultez Utilisation des
paramètres de stratégie de modèle d’administration à l’aide de l’éditeur de stratégie de groupe local.
Appliquer une KIR à des appareils dans un domaine Azure AD ou AD

DS hybride à l’aide de stratégie de groupe
Pour appliquer une définition de stratégie KIR aux appareils qui appartiennent à un domaine Azure AD ou AD
DS hybride, procédez comme suit :
1. Télécharger et installer les fichiers MSI KIR
2. Créez un objet stratégie de groupe (GPO).
3. Créez et configurez un filtre WMI qui applique l’objet de stratégie de groupe.
4. Liez l’objet de stratégie de groupe et le filtre WMI.
5. Configurez l’objet de stratégie de groupe.
6. Surveillez les résultats de l’objet de stratégie de groupe.
1. Télécharger et installer les fichiers MSI KIR
1. Vérifiez les informations de publication KIR ou les listes de problèmes connus pour identifier les versions de
système d’exploitation que vous devez mettre à jour.
2. Téléchargez la définition de stratégie KIR .msi fichiers que vous devez mettre à jour sur l’ordinateur que vous
utilisez pour gérer stratégie de groupe pour votre domaine.
3. Exécutez les fichiers .msi. Cette action installe la définition de stratégie KIR dans le modèle d’administration.
NOTE
Les définitions de stratégie sont installées dans le dossier C:\Windows\PolicyDefinitions . Si vous avez implémenté
le magasin central stratégie de groupe, vous devez copier les fichiers .admx et .adml dans le Magasin central.
2. Créer un objet de stratégie de groupe

1. Ouvrez stratégie de groupe console de gestion, puis sélectionnez Forêt : Domaines DomainName > .
2. Cliquez avec le bouton droit sur votre nom de domaine, puis sélectionnez Créer un objet de stratégie
de groupe dans ce domaine, puis liez-le ici .
3. Entrez le nom du nouvel objet de stratégie de groupe (par exemple, KIR Problème XXX ), puis sélectionnez
OK .
Pour plus d’informations sur la création d’objets de stratégie de groupe, consultez Créer un objet stratégie de
groupe.
3. Créer et configurer un filtre WMI qui applique l’objet de stratégie de groupe
1. Cliquez avec le bouton droit sur Filtres WMI , puis sélectionnez Nouveau .
2. Entrez un nom pour votre nouveau filtre WMI.
3. Entrez une description de votre filtre WMI, telle que Filtrer pour tous les appareils Windows 10
version 2004 .
4. Sélectionnez Ajouter .
5. Dans Requête , entrez la chaîne de requête suivante :
SELECT version, producttype from Win32_OperatingSystem WHERE Version = <VersionNumber>

IMPORTANT
Dans cette chaîne, <VersionNumber> représente la version de Windows à laquelle vous souhaitez appliquer l’objet
de stratégie de groupe. Le numéro de version doit utiliser le format suivant (exclure les crochets lorsque vous
utilisez le nombre dans la chaîne) :
10.0.xxxxx
où xxxxx est un nombre à cinq chiffres. Actuellement, les KIR prennent en charge les versions suivantes :
VER SIO N NU M ÉRO D E B U IL D
Windows 10, version 20H2 10.0.19042
Windows 10, version 2004 10.0.19041
Pour obtenir une liste à jour des versions de Windows et des numéros de build, consultez Windows 10 -
informations de publication.
IMPORTANT
Les numéros de build répertoriés dans la page d’informations de mise en production Windows 10 n’incluent pas le
préfixe 10.0 . Pour utiliser un numéro de build dans la requête, vous devez ajouter le préfixe 10.0 .
Pour plus d’informations sur la création de filtres WMI, consultez Créer des filtres WMI pour l’objet de stratégie
de groupe.
4. Lier l’objet de stratégie de groupe et le filtre WMI
1. Sélectionnez l’objet de stratégie de groupe que vous avez créé précédemment, ouvrez le menu Filtrage
WMI , puis sélectionnez le filtre WMI que vous venez de créer.
2. Sélectionnez Oui pour accepter le filtre.
5. Configurer l’objet de stratégie de groupe
Modifiez votre objet de stratégie de groupe pour utiliser la stratégie d’activation KIR :
1. Cliquez avec le bouton droit sur l’objet de stratégie de groupe que vous avez créé précédemment, puis
sélectionnez Modifier .
2. Dans l’éditeur stratégie de groupe, sélectionnez GPOName _ > _ Computer Configuration >
Administrative Templates > KB ######## Problème XXX Rollback > Windows 10, version
YYMM *.
3. Cliquez avec le bouton droit sur la stratégie, puis sélectionnez Modifier > désactivé OK > .
Pour plus d’informations sur la modification d’objets de stratégie de groupe, consultez Modifier un objet
stratégie de groupe à partir de GPMC.
6. Surveiller les résultats de l’objet de stratégie de groupe
Dans la configuration par défaut de stratégie de groupe, les appareils gérés doivent appliquer la nouvelle
stratégie dans les 90 à 120 minutes. Pour accélérer ce processus, vous pouvez exécuter gpupdate les appareils
affectés pour rechercher manuellement les stratégies mises à jour.
Assurez-vous que chaque appareil affecté redémarre après l’application de la stratégie.
IMPORTANT
Le correctif qui a introduit le problème est désactivé une fois que l’appareil a appliqué la stratégie, puis redémarré.
Déployer une activation KIR à l’aide Microsoft Intune’ingestion de

stratégie ADMX sur les appareils gérés
NOTE
Pour utiliser les solutions de cette section, vous devez installer la mise à jour cumulative publiée le 26 juillet 2022 ou une
version ultérieure sur l’ordinateur.
Les stratégies de groupe et les objets de stratégie de groupe ne sont pas compatibles avec les solutions basées
sur la gestion des appareils mobiles (GPM), telles que Microsoft Intune. Ces instructions vous guident tout au
long de l’utilisation Intune paramètres personnalisés pour l’ingestion ADMX et configurent les stratégies MDM
ADMX pour effectuer une activation KIR sans nécessiter d’objet de stratégie de groupe.
Pour effectuer une activation KIR sur Intune appareils gérés, procédez comme suit :
1. Téléchargez et installez le fichier MSI KIR pour obtenir des fichiers ADMX.
2. Créez un profil de configuration personnalisé dans Microsoft Endpoint Manager.
3. Surveillez l’activation kir.
1. Télécharger et installer le fichier MSI KIR pour obtenir des fichiers ADMX
1. Vérifiez les informations de publication KIR ou les listes de problèmes connus pour identifier les versions
de système d’exploitation que vous devez mettre à jour.
2. Téléchargez la définition de stratégie KIR requise .msi fichiers sur l’ordinateur que vous utilisez pour vous
connecter à Microsoft Endpoint Manager.
NOTE
Vous devez accéder au contenu d’un fichier ADMX d’activation KIR.
3. Exécutez les .msi fichiers. Cette action installe la définition de stratégie KIR dans le modèle
d’administration.
NOTE
Les définitions de stratégie sont installées dans le dossier C:\Windows\PolicyDefinitions.
Si vous souhaitez extraire les fichiers ADMX vers un autre emplacement, utilisez la msiexec commande avec la
propriété TARGETDIR . Par exemple :
msiexec /i c:\admx_file.msi /qb TARGETDIR=c:\temp\admx
2. Créer un profil de configuration personnalisé dans Microsoft Endpoint Manager

Pour configurer des appareils afin d’effectuer une activation KIR, vous devez créer un profil de configuration
personnalisé pour chaque système d’exploitation de vos appareils gérés. Pour créer un profil personnalisé,
1. Sélectionnez des propriétés et ajoutez des informations de base du profil.
2. Ajoutez un paramètre de configuration personnalisé pour ingérer des fichiers ADMX pour l’activation KIR.
3. Ajoutez un paramètre de configuration personnalisé pour définir une nouvelle stratégie d’activation KIR.
4. Affectez des appareils au profil de configuration personnalisé d’activation KIR.
5. Utilisez des règles d’applicabilité pour cibler les appareils afin de recevoir les paramètres de configuration
personnalisés KIR par système d’exploitation.
6. Examinez et créez le profil de configuration personnalisé d’activation KIR.
R : Sélectionner des propriétés et ajouter des informations de base sur le profil
1. Connectez-vous au Centre d’administration Microsoft Endpoint Manager.
2. SélectionnezProfils > de configurationdes appareils >Créer un profil .
3. Sélectionnez les propriétés suivantes :
Plateforme : Windows 10 et versions ultérieures
Profil : Modèles personnalisés >
4. Sélectionnez Créer .
5. Dans Informations de base , entrez les propriétés suivantes :
Nom : attribuez un nom descriptif à la stratégie. Nommez vos stratégies afin de pouvoir les identifier
facilement ultérieurement. Par exemple, un bon nom de stratégie est « Activation 04/30 KIR –
Windows 10 21H2 ».
Description : entrez une description pour la stratégie. Ce paramètre est facultatif, mais recommandé.
NOTE
Les valeurs de plateforme et de profil doivent déjà être sélectionnées.
NOTE
Pour plus d’informations sur la création de profils de configuration et de paramètres de configuration personnalisés,
consultez Utiliser les paramètres d’appareil personnalisés dans Microsoft Intune.
Avant de passer aux deux étapes suivantes, ouvrez le fichier ADMX dans un éditeur de texte (par exemple, bloc-
notes) où le fichier a été extrait. Le fichier ADMX doit se trouver dans le chemin D:\Windows\PolicyDefinitions si
vous l’avez installé en tant que fichier MSI.
Voici un exemple de fichier ADMX :
<policies>
<policy name="KB5011563_220428_2000_1_KnownIssueRollback" … >
<parentCategory ref="KnownIssueRollback_Win_11" />
<supportedOn ref="SUPPORTED_Windows_11_0_Only" />
<enabledList…> … </enabledList>
<disabledList…>…</disabledList>
</policy>
</policies>
Enregistrez les valeurs pour policy name et parentCategory . Ces informations se trouve dans le nœud «
stratégies » à la fin du fichier.
B. Ajouter un paramètre de configuration personnalisé pour ingérer des fichiers ADMX pour l’activation KIR
Ce paramètre de configuration est utilisé pour installer la stratégie d’activation KIR sur les appareils cibles.
Procédez comme suit pour ajouter les paramètres d’ingestion ADMX :
1. Dans Paramètres de configuration , sélectionnez Ajouter .
2. Entrez les propriétés suivantes :
Nom : entrez un nom descriptif pour le paramètre de configuration. Nommez vos paramètres
pour pouvoir les identifier facilement ultérieurement. Par exemple, un bon nom de paramètre est «
Ingestion ADMX : activation 04/30 KIR – Windows 10 21H2 ».
Description : entrez une description pour le paramètre. Ce paramètre est facultatif, mais
recommandé.
OMA-URI : entrez la chaîne
./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/KIR/Policy/<ADMX Policy Name>.
NOTE
Remplacez <ADMX Policy Name> par la valeur du nom de stratégie enregistré à partir du fichier ADMX.
Par exemple, « KB5011563_220428_2000_1_KnownIssueRollback ».
Type de données : Sélectionnez Chaîne .

Valeur : ouvrez le fichier ADMX avec un éditeur de texte (par exemple, bloc-notes). Copiez et collez
l’intégralité du contenu du fichier ADMX que vous envisagez d’ingérer dans ce champ.
C. Ajouter un paramètre de configuration personnalisé pour définir une nouvelle stratégie d’activation KIR
Ce paramètre de configuration est utilisé pour configurer la stratégie d’activation KIR, qui est définie à l’étape
précédente.
Procédez comme suit pour ajouter les paramètres de configuration de l’activation KIR :
1. Dans Paramètres de configuration , sélectionnez Ajouter .
2. Entrez les propriétés suivantes :
Nom : entrez un nom descriptif pour le paramètre de configuration. Nommez vos paramètres
pour pouvoir les identifier facilement ultérieurement. Par exemple, un bon nom de paramètre est «
Activation KIR : activation 04/30 KIR – Windows 10 21H2 ».
Description : entrez une description pour le paramètre. Ce paramètre est facultatif, mais
recommandé.
OMA-URI : entrez la chaîne
./Device/Vendor/MSFT/Policy/Config/KIR~Policy~KnownIssueRollback~<Parent
Category>/<ADMX Policy Name>.
NOTE
Remplacez <Parent Category> par la chaîne de catégorie parente enregistrée à l’étape précédente. Par
exemple, « KnownIssueRollback_Win_11 ». Remplacez par <ADMX Policy Name> le même nom de
stratégie que celui utilisé à l’étape précédente.
Type de données : Sélectionnez Chaîne .
Valeur : Entrez <disabled/>.
D. Affecter des appareils au profil de configuration personnalisé d’activation KIR
Une fois que vous avez défini ce que fait le profil de configuration personnalisé, procédez comme suit pour
identifier les appareils que vous allez configurer :
1. Dans Affectations , sélectionnez Ajouter tous les appareils .
E. Utiliser des règles d’applicabilité pour cibler les appareils afin de recevoir des paramètres de configuration personnalisés KIR par
système d’exploitation
Pour cibler les appareils par système d’exploitation applicables à la stratégie de groupe, ajoutez une règle
d’applicabilité pour vérifier la version du système d’exploitation de l’appareil (build) avant d’appliquer cette
configuration. Vous pouvez rechercher les numéros de build du système d’exploitation pris en charge sur les
pages suivantes :
Informations sur les versions Windows 11
Informations sur les versions Windows 10
Informations de publication de Windows Server
Les numéros de build affichés dans les pages sont mis en forme en MMMMM.mmmm (M= version majeure et
m= version mineure). Les propriétés de version du système d’exploitation utilisent les chiffres de version
principaux. Les valeurs de version du système d’exploitation entrées dans les règles d’applicabilité doivent être
mises en forme comme « 10.0.MMMMM ». Par exemple, « 10.0.22000 ».
Suivez ces instructions pour définir les règles d’applicabilité appropriées pour votre activation KIR :
1. Dans Règles d’applicabilité , créez une règle d’applicabilité en entrant les propriétés suivantes sur la
règle vide déjà sur la page :
Règle : sélectionnez Affecter un profil dans la liste déroulante.
Propriété : Sélectionnez la version du système d’exploitation dans la liste déroulante.
Valeur : entrez les numéros de version Min et Max OS au format « 10.0.MMMMM ».
NOTE
La version du système d’exploitation d’un appareil est disponible en exécutant la winver commande à partir du menu
Démarrer. Il affiche un numéro de version en deux parties séparé par un « . ». Par exemple, « 22000.613 ». Vous pouvez
ajouter le numéro de gauche à « 10.0 ». pour la version minimale du système d’exploitation. Obtenez le numéro de
version maximale du système d’exploitation en ajoutant 1 au dernier chiffre du numéro de version du système
d’exploitation minimal. Pour cet exemple, vous pouvez utiliser les valeurs suivantes :
Version minimale du système d’exploitation : « 10.0.22000 »
Version maximale du système d’exploitation : « 10.0.22001 »
F. Examiner et créer un profil de configuration personnalisé d’activation KIR

Passez en revue vos paramètres du profil de configuration personnalisé, puis sélectionnez Créer .
3. Surveiller l’activation kir
Votre activation KIR doit être en cours. Suivez ces étapes pour surveiller la progression du profil de
configuration :
1. Accédez aux profils de configuration des appareils >, puis sélectionnez un profil existant. Par
exemple, sélectionnez un profil macOS.
2. Sélectionnez l’ongletVue d’ensemble . Dans cette vue, l’état de l’affectation de profil inclut les états
suivants :
Réussite : la stratégie est correctement appliquée.
Erreur : impossible d’appliquer la stratégie. Le message affiche généralement un code d’erreur lié à
une explication.
Conflit : deux paramètres sont appliqués au même appareil et Intune ne peut pas résoudre le conflit.
Un administrateur doit examiner le conflit.
En attente : l’appareil n’a pas vérifié auprès d’Intune pour recevoir la stratégie.
Non applicable : l’appareil ne peut pas recevoir la stratégie. Par exemple, la stratégie met à jour un
paramètre spécifique à iOS 11.1, mais l’appareil utilise iOS 10.
Pour plus d’informations, consultez Surveiller les profils de configuration d’appareil dans Microsoft Intune.
Éditeur de stratégie de groupe local
Utilisation des paramètres de stratégie de modèle d’administration à l’aide de l’éditeur de stratégie de
groupe local
Vue d’ensemble de stratégie de groupe
Guide pratique pour GPMC
Créer des filtres WMI pour l’objet de stratégie de groupe (Windows 10) - Sécurité Windows
Modifier un objet stratégie de groupe à partir de GPMC
Créer et gérer une stratégie de groupe dans Azure AD Domain Services
Utiliser des modèles Windows 10/11 pour configurer les paramètres de stratégie de groupe dans Microsoft
Intune
Utiliser une stratégie de groupe pour installer un
logiciel à distance
Cet article explique comment utiliser une stratégie de groupe pour distribuer automatiquement des
programmes vers des ordinateurs clients ou des utilisateurs.
Résumé
Vous pouvez utiliser la stratégie de groupe pour distribuer des logiciels à l’aide des méthodes suivantes :
Attribution de logiciels
Vous pouvez attribuer une distribution de programmes à des utilisateurs ou des ordinateurs. Si vous
attribuez le programme à un utilisateur, il est installé lorsque l’utilisateur ouvre une session sur
l’ordinateur. L’installation est terminée lorsque l’utilisateur exécute le programme pour la première fois. Si
vous attribuez le programme à un ordinateur, il est installé lorsque l’ordinateur démarre et il est
disponible pour tous les utilisateurs qui ouvrent une session sur l’ordinateur. L’installation est terminée
lorsqu’un utilisateur exécute le programme pour la première fois.
Publication de logiciels
Vous pouvez publier une distribution de programme pour des utilisateurs. Lorsque l’utilisateur ouvre une
session sur l’ordinateur, le programme publié est affiché dans la boîte de dialogue Ajout/Suppression
de programmes et peut être installé à partir de cet emplacement.
NOTE
L’installation de programme automatisée de la stratégie de groupe de Windows Server 2003 requiert des ordinateurs
clients qui exécutent Microsoft Windows 2000 ou une version ultérieure.
Création d’un point de distribution

Pour publier ou attribuer un logiciel, vous devez créer un point de distribution sur le serveur de publication.
1. Ouvrez une session sur le serveur en tant qu’administrateur.
2. Créez un dossier réseau partagé dans lequel vous placerez le package Windows Installer (fichier .msi) que
vous voulez distribuer.
3. Définissez les autorisations du partage afin de permettre l’accès au package de distribution.
4. Copiez ou installez le package sur le point de distribution. Par exemple, pour distribuer un fichier .msi,
exécutez l’installation administrative ( setup.exe /a ) pour copier les fichiers vers le point de distribution.
Création d’un objet de stratégie de groupe

Pour créer un objet de stratégie de groupe à utiliser pour distribuer le package logiciel, procédez comme suit :
1. Démarrez le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory. Pour ce faire, cliquez
sur Démarrer , puis Outils d’administration , puis cliquez sur Utilisateurs et ordinateurs Active
Director y .
2. Dans l’arborescence de la console, cliquez avec le bouton droit sur votre domaine, puis cliquez sur
Propriétés .
3. Cliquez sur l’onglet Stratégie de groupe , puis sur Nouveau .
4. Entrez le nom de la nouvelle stratégie, puis appuyez sur Entrée.
5. Cliquez sur Propriétés , puis sur l’onglet Sécurité .
6. Décochez la case Appliquer la stratégie de groupe pour les groupes de sécurité auxquels vous ne
souhaitez pas appliquer cette stratégie.
7. Cochez la case Appliquer la stratégie de groupe pour les groupes auxquels vous souhaitez appliquer
cette stratégie.
8. Lorsque vous avez terminé, cliquez sur OK .
Attribution d’un package

Pour attribuer un programme à des ordinateurs sous Windows Server 2003, Windows 2000 ou Windows XP
Professionnel, ou à des utilisateurs qui se connectent à l’une de ces stations de travail, procédez comme suit :
1. Démarrez le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory. Pour ce faire,
cliquez sur Démarrer , puis Outils d’administration , puis cliquez sur Utilisateurs et ordinateurs
Active Director y .
Propriétés .
3. Cliquez sur l’onglet Stratégie de groupe , sélectionnez la stratégie souhaitée, puis cliquez sur Modifier .
4. Sous Configuration ordinateur , développez Paramètres du logiciel .
5. Cliquez avec le bouton droit sur Installation de logiciel , pointez sur Nouveau , puis cliquez sur
Package .
6. Dans la boîte de dialogue Ouvrir , tapez le chemin UNC complet du package d’installation partagé
souhaité. Par exemple : \\<file server>\<share>\<file name>.msi .
IMPORTANT
N’utilisez pas le bouton Parcourir pour accéder à l’emplacement. Assurez-vous que vous utilisez le chemin UNC
du package du programme d’installation partagé.
7. Cliquez sur Ouvrir .

8. Cliquez sur Attribué , puis sur OK . Le package s’affiche dans le volet droit de la fenêtre Stratégie de
groupe .
9. Fermez le composant logiciel enfichable Stratégie de groupe , cliquez sur OK , puis fermez le composant
logiciel enfichable Utilisateurs et ordinateurs Active Directory.
10. Lorsque l’ordinateur client démarre, le package géré est installé automatiquement.
Publication d’un package

Pour publier un package pour les utilisateurs et le rendre disponible à l’installation depuis la liste
Ajout/Suppression de programmes du Panneau de configuration, procédez comme suit :
Active Director y .
Propriétés .
3. Cliquez sur l’onglet Stratégie de groupe , cliquez sur la stratégie souhaitée, puis cliquez sur Modifier .
4. Sous Configuration utilisateur , développez Paramètres du logiciel .
5. Cliquez avec le bouton droit sur Installation de logiciel , pointez sur Nouveau , puis cliquez sur
Package .
6. Dans la boîte de dialogue Ouvrir , tapez le chemin UNC complet du package d’installation partagé que
vous souhaitez. Par exemple : \\file server\share\file name.msi .
IMPORTANT
N’utilisez pas le bouton Parcourir pour accéder à l’emplacement. Assurez-vous que vous utilisez le chemin UNC
du package du programme d’installation partagé.
7. Cliquez sur Ouvrir .

8. Cliquez sur Publier , puis sur OK .
9. Le package s’affiche dans le volet droit de la fenêtre Stratégie de groupe .
10. Fermez le composant logiciel enfichable Stratégie de groupe, cliquez sur OK , puis fermez le composant
11. Testez le package.
NOTE
Étant donné qu’il existe plusieurs versions de Windows, la procédure peut être différente pour votre ordinateur. Si
tel est le cas, reportez-vous à la documentation de votre produit pour exécuter cette procédure.
a. Connectez-vous à une station de travail Windows 2000 Professionnel ou Windows XP Professionnel

en utilisant un compte sur lequel vous avez publié le package.
b. Dans Windows XP, cliquez sur Démarrer , puis sur Panneau de configuration .
c. Double-cliquez sur Ajouter ou supprimer des programmes , puis cliquez sur Ajouter de
nouveaux programmes .
d. Dans la liste Ajouter des programmes à par tir de votre réseau , cliquez sur le programme que
vous avez publié, puis sur Ajouter . Le programme est installé.
e. Cliquez sur OK , puis sur Fermer .
Redéploiement d’un package

Dans certains cas, vous pouvez souhaiter redéployer un package logiciel (par exemple, si vous effectuez une
mise à niveau ou si vous modifiez le package). Pour redéployer un package, procédez comme suit :
Active Director y .
Propriétés .
3. Cliquez sur l’onglet Stratégie de groupe , cliquez sur l’objet de stratégie de groupe utilisé pour déployer
le package, puis sur Modifier .
4. Développez le conteneur Paramètres du logiciel qui contient l’élément d’installation du logiciel utilisé
pour déployer le package.
5. Cliquez sur le conteneur d’installation du logiciel qui contient le package.
6. Dans le volet droit de la fenêtre Stratégie de groupe , cliquez avec le bouton droit sur le programme,
pointez sur Toutes les tâches , puis cliquez sur Redéploiement des applications . Le message suivant
s’affiche :
Le redéploiement de cette application réinstallera celle-ci partout où elle est déjà installée. Voulez-
vous continuer ?
7. Cliquez sur Oui .

8. Quittez le composant logiciel enfichable Stratégie de groupe, cliquez sur OK , puis fermez le composant
Suppression d’un package

Pour supprimer un package publié ou attribué, procédez comme suit :
1. Démarrez le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory. Pour ce faire, cliquez
sur Démarrer , puis Outils d’administration , puis cliquez sur Utilisateurs et ordinateurs Active
Director y .
Propriétés .
3. Cliquez sur l’onglet Stratégie de groupe , cliquez sur l’objet de stratégie de groupe utilisé pour déployer le
package, puis sur Modifier .
4. Développez le conteneur Paramètres du logiciel qui contient l’élément d’installation du logiciel utilisé
pour déployer le package.
5. Cliquez sur le conteneur d’installation du logiciel qui contient le package.
6. Dans le volet droit de la fenêtre Stratégie de groupe , cliquez avec le bouton droit sur le programme,
pointez sur Toutes les tâches , puis cliquez sur Supprimer .
Cliquez sur Désinstaller immédiatement le logiciel des utilisateurs et des ordinateurs , puis
cliquez sur OK .
Cliquez sur Autoriser les utilisateurs à continuer à utiliser le logiciel, mais interdire de
nouvelles installations , puis cliquez sur OK .
8. Fermez le composant logiciel enfichable Stratégie de groupe, cliquez sur OK , puis fermez le composant
Résoudre des problèmes

Les packages publiés sont affichés sur un ordinateur client après que vous avez utilisé une stratégie de groupe
pour les supprimer
Cette situation peut se produire lorsqu’un utilisateur a installé le programme mais ne l’a pas utilisé. L’installation
est terminée lorsque l’utilisateur démarre le programme publié pour la première fois. La stratégie de groupe
supprime ensuite le programme.
Erreur 0x8007000D lors de l’exécution de l’cmdLet
Backup-GPO PowerShell dans Windows Server
Core edition
Sur un ordinateur qui exécute Windows Server 2016 ou Windows Server 2019 Core edition et sur qui la
fonctionnalité Console de gestion des stratégies de groupe (GPMC) est installée, vous ne pouvez pas utiliser la
cmdlet PowerShell pour back Backup-GPO up a group policy that contains folder redirection settings.
S’applique à : Windows Server 2016 Édition principale, Windows Server 2019 Core
Exemple de sortie PowerShell

Ce résultat apparaît dans la fenêtre PowerShell :
PS C:\> Backup-GPO -Name FolderRedirection -Path <path>
Backup-GPO : The data is invalid. (Exception from HRESULT: 0x8007000D)

At line:1 char:1
+ Backup-GPO -Name FolderRedirection -Path <path>
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Backup-GPO], COMException
+ FullyQualifiedErrorId :
System.Runtime.InteropServices.COMException,Microsoft.GroupPolicy.Commands.BackupGpoComm
and
NOTE
Le code d'0x8007000D signifie ERROR_INVALID_DATA .
Le problème ne se produit pas lorsque vous exécutez cette commande sur une version Windows Server 2016 ou
Windows Server 2019 Desktop.
Cause
Ce problème est connu. Certains modules ne sont pas présents par défaut dans Windows éditions Server Core.
Pendant le processus de sauvegarde, le système vérifie les paramètres liés au type de stratégie trouvé. Sur
Windows version Server Core, une bibliothèque associée Client-Side (CSE) utilisée pour les stratégies de
redirection de dossiers n’est pas présente. Cela provoque une exception COM.
Comment contourner ce problème

Voici trois solutions de contournement :
Exécutez des sauvegardes de stratégie de groupe sur la version de bureau Windows Server 2016 ou
Exécutez des sauvegardes de stratégie de groupe à distance à partir Windows 10 station de travail à l’aide
des outils d’administration des services distants (RSAT) installés pour gpMC.
Exécutez wbadmin plutôt systemstatebackup l’application avec l’option. Cette sauvegarde inclut à la fois la
base de données Active Directory et le contenu du dossier sysvol.
Référence
Pour plus d’informations sur la syntaxe wbadmin, voir wbadmin start systemstatebackup.
AGPM et GPRESULT ne fonctionnent pas dans
Windows Server Core
Cet article fournit une solution à une erreur qui se produit lorsque AGPM et GPRESULT ne fonctionnent pas sur
une installation Windows Server Core.
Symptômes
Scénario de gestion avancée des stratégies de groupe (AGPM ) Microsoft
Supposons que le serveur AGPM soit installé sur un ordinateur exécutant Windows Server Core (Windows
Server 2008 R2, Windows Server 2012, Windows Server 2012 R2). AGPM est installé sur un ordinateur client
qui exécute Windows Server ou un système d’exploitation client Windows sur qui les outils d’administration de
serveur distant sont installés. Dans ce cas, l’erreur suivante se produit chaque fois qu’un administrateur tente de
prendre le contrôle d’un objet de stratégie de groupe (GPO) nonmanaté :
GPO de contrôle : < nom d'> GPO... Échec

L’erreur globale était : les données ne sont pas valides. (Exception de HRESULT : 0x8007000D)
D’autres détails suivent.
[Erreur] Impossible de caster l’objet de type « System.DBNull » pour taper «
Microsoft.Agpm.GroupPolicy.Interop.GPMBackup »
Scénario GPRESULT
Sur un ordinateur Windows Server Core, lorsqu’un administrateur exécute la commande gpresult /h pour
récupérer les paramètres gPO de cet ordinateur ou de cet utilisateur, GPRESULT renvoie le message d’erreur
suivant <filename.htm> :
ERREUR : le paramètre est incorrect.
Cause
Ces problèmes se produisent car le composant AGPM Server et la commande GPRESULT /h nécessitent
l’installation de la console de gestion des stratégies de groupe (GPMC) sur le système local. Plusieurs interfaces
GPMC sont installées sur le système uniquement lorsque la GPMC est installée.
GPMC Interfaces
Étant donné Windows Server Core n’a pas les interfaces GPMC installées, les applications qui utilisent cette
interface échouent.
Résolution
Résolution pour AGPM
Installez le composant AGPM Server sur un ordinateur Windows serveur sur qui l’interface utilisateur graphique
est installée.
Résolution pour GPRESULT
Exécutez le rapport GPRESULT à partir d’un ordinateur distant sur l’ordinateur Windows Server Core.
Les modifications apportées aux autorisations des
objets de stratégie de groupe via AGPM sont
ignorées
Cet article fournit une solution de contournement pour un problème dans lequel les modifications apportées
aux autorisations d’objet de stratégie de groupe contrôlées dans la Gestion avancée des stratégies de groupe
(AGPM) ne sont pas enregistrées comme prévu.
2012 R2
Symptômes
Pour modifier les autorisations sur un objet de stratégie de groupe contrôlé dans AGPM, vous devez d’abord
vérifier la stratégie dans AGPM, puis modifier les autorisations sous l’onglet Sécurité de l’objet de stratégie. Par
exemple, vous ajoutez l’autorisation Lecture seule aux utilisateurs authentifiés. Toutefois, une fois que vous avez
enregistré vos modifications dans la stratégie, puis que vous avez vu l’onglet Sécurité de la stratégie, vous
constatez que vos modifications ne sont pas enregistrées comme prévu.
Cause
Ce comportement est par conception dans AGPM 4.0 Service Pack 3 (SP3) et les versions antérieures. Pour
ajouter des autorisations aux objets de stratégie de groupe nouvellement créés, nous vous recommandons
d’utiliser l’onglet Délégation de production dans AGPM.
1. Installez microsoft Desktop Optimization Pack version de mars 2017 servicing release sur le serveur
AGPM.
2. Définissez la clé de Registre et les valeurs suivantes sur le serveur AGPM.
Chemin d’accès : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Agpm
Nom de la valeur : OverrideRemovePermissionsWithoutReadAndApply
Type de valeur : chaîne REG_SZ
3. Redémarrez le serveur AGPM.
Si OverrideRemovePermissionsWithoutReadandApply est définie sur 1, les autorisations de lecture sont
enregistrées une fois que la stratégie est enregistrée dans AGPM, mais les autorisations d’écriture sont
supprimées.
Si OverrideRemovePermissionsWithoutReadAndApply n’est pas définie ou est définie sur une valeur autre que
1, AGPM se comporte de la manière décrite dans la section Symptômes.
Références
Guide pas à pas pour la gestion avancée des stratégies de groupe Microsoft 4.0
Série de présentations : Gestion avancée des stratégies de groupe
Guide des opérations pour Microsoft AGPM 4.0
Comment créer le magasin central pour les fichiers
de modèle d’administration de stratégie de groupe
dans Windows Vista
Cet article explique comment utiliser les nouveaux fichiers .admx et .adml pour créer et administrer des
paramètres de stratégie basés sur le Registre dans Windows Vista, et comment le magasin central est utilisé
pour stocker et répliquer des fichiers de stratégie Windows Vista dans un environnement de domaine.
S’applique à : Windows Vista
Présentation
Windows Vista utilise un nouveau format pour afficher les paramètres de stratégie basés sur le Registre. Ces
paramètres de stratégie basés sur le Registre apparaissent sous Modèles d’administration dans l’Éditeur
d’objets de stratégie de groupe. Dans Windows Vista, ces paramètres de stratégie basés sur le Registre sont
définis par des fichiers XML basés sur des normes qui ont une extension de nom de fichier .admx. Le format de
fichier .admx remplace le format de fichier .adm hérité. Le format de fichier .adm utilise un langage de marque
propriétaire.
Dans Windows Vista, les fichiers de modèles d’administration sont divisés en fichiers .admx et en fichiers .adml
spécifiques à la langue qui sont disponibles pour les administrateurs de stratégie de groupe. Les modifications
implémentées dans Windows Vista permet aux administrateurs de configurer le même ensemble de stratégies à
l’aide de deux langues différentes. Les administrateurs peuvent configurer des stratégies à l’aide des fichiers
.adml spécifiques à la langue et des fichiers .admx indépendants de la langue.
Stockage de fichiers de modèles d’administration

Dans les systèmes d’exploitation précédents, tous les fichiers de modèle d’administration par défaut sont ajoutés
au dossier ADM d’un objet de stratégie de groupe (GPO) sur un contrôleur de domaine. Les G STRATÉGIE de
groupe sont stockées dans le dossier SYSVOL. Le dossier SYSVOL est automatiquement répliqué sur d’autres
contrôleurs de domaine dans le même domaine. Un fichier de stratégie utilise environ 2 mégaoctets (Mo)
d’espace disque. Étant donné que chaque contrôleur de domaine stocke une version distincte d’une stratégie, le
trafic de réplication est augmenté.
Windows Vista utilise un magasin central pour stocker les fichiers de modèles d’administration. Dans Windows
Vista, le dossier ADM n’est pas créé dans un GPO comme dans les versions antérieures de Windows. Ainsi, les
contrôleurs de domaine ne stockent pas ou ne répliquent pas les copies redondantes des fichiers .adm.
NOTE
Si vous utilisez un client qui exécute une version antérieure de Windows pour modifier une stratégie créée ou administrée
sur un ordinateur Windows Vista, le client crée le dossier ADM et réplique les fichiers.
Pour plus d’informations, voir Recommandations pour la gestion des fichiers de modèle d’administration de
stratégie de groupe (.adm).
Magasin central
Pour tirer parti des avantages des fichiers .admx, vous devez créer un magasin central dans le dossier SYSVOL
sur un contrôleur de domaine. Le magasin central est un emplacement de fichier vérifié par les outils de
stratégie de groupe. Les outils de stratégie de groupe utilisent tous les fichiers .admx du magasin central. Les
fichiers du magasin central sont répliqués ultérieurement sur tous les contrôleurs de domaine du domaine.
Pour créer un magasin central pour les fichiers .admx et .adml, créez un dossier nommé PolicyDefinitions à
l’emplacement suivant : \\FQDN\SYSVOL\FQDN\policies
NOTE
Le nom de domaine complet est un nom de domaine complet.
Par exemple, pour créer un magasin central pour le domaine Test.Microsoft.com, créez un dossier
PolicyDefinitions à l’emplacement suivant :
\\Test.Microsoft.Com\SYSVOL\Test.Microsoft.Com\Policies
Copiez tous les fichiers du dossier PolicyDefinitions sur un ordinateur client Windows Vista vers le dossier
PolicyDefinitions sur le contrôleur de domaine. Le dossier PolicyDefinitions sur un ordinateur Windows Vista
reste dans le même dossier que Windows Vista. Le dossier PolicyDefinitions de l’ordinateur Windows Vista
stocke tous les fichiers .admx et .adml pour toutes les langues activées sur l’ordinateur client.
Les fichiers .adml sur l’ordinateur Windows Vista sont stockés dans un dossier spécifique à la langue. Par
exemple, les fichiers adml en anglais (États-Unis) sont stockés dans un dossier nommé « en-US ». Les fichiers
.adml coréens sont stockés dans un dossier nommé « ko_KR ». Si des fichiers .adml pour d’autres langues sont
requis, vous devez copier le dossier qui contient les fichiers .adml pour cette langue dans le magasin central.
Lorsque vous avez copié tous les fichiers .admx et .adml, le dossier PolicyDefinitions sur le contrôleur de
domaine doit contenir les fichiers .admx et un ou plusieurs dossiers qui contiennent des fichiers .adml
spécifiques à la langue.
NOTE
Lorsque vous copiez les fichiers .admx et .adml à partir d’un ordinateur Windows Vista, vérifiez que les dernières mises à
jour de ces fichiers et de Windows Vista sont installées. Assurez-vous également que les fichiers de modèle
d’administration les plus récents sont répliqués. Ce conseil s’applique également aux Service Packs, le cas échéant.
Administration de la stratégie de groupe

Windows Vista n’inclut pas les modèles d’administration qui ont une extension .adm. En outre, les versions
antérieures Windows ne peuvent pas utiliser le nouveau format d’administration. Ainsi, les ordinateurs clients
qui exécutent des versions antérieures de Windows ne peuvent pas administrer les nouvelles stratégies incluses
dans Windows Vista. Nous vous recommandons d’utiliser des ordinateurs exécutant Windows Vista ou des
versions ultérieures de Windows pour l’administration de la stratégie de groupe.
Mise à jour des fichiers de modèles d’administration

Dans la stratégie de groupe pour les versions de Windows antérieures à Windows Vista, si vous modifiez les
paramètres de stratégie de modèle d’administration sur les ordinateurs locaux, le partage Sysvol sur un
contrôleur de domaine au sein de votre domaine est automatiquement mis à jour avec le nouveau . Fichiers
ADM. À leur tour, ces modifications sont répliquées sur tous les autres contrôleurs de domaine du domaine. Cela
peut entraîner une augmentation de la charge réseau et des besoins en stockage. Dans la stratégie de groupe
pour Windows Server 2008 et Windows Vista, si vous modifiez les paramètres de stratégie de modèle
d’administration sur les ordinateurs locaux, Sysvol ne sera pas automatiquement mis à jour avec le nouveau .
ADMX ou . Fichiers ADML. Ce changement de comportement est implémenté pour réduire la charge réseau et
les besoins en stockage de disque, et pour éviter les conflits entre . Fichiers ADMX et . Fichiers ADML lorsque les
modifications des paramètres de stratégie des modèles d’administration sont réalisées dans différents
paramètres régionaux. Pour vous assurer que les mises à jour locales sont reflétées dans Sysvol, vous devez
copier manuellement les mises à jour. ADMX ou . Fichiers ADML du fichier PolicyDefinitions de l’ordinateur local
vers le dossier Sysvol\PolicyDefinitions sur le contrôleur de domaine approprié.
Pour télécharger les fichiers de modèles d’administration pour Windows Server 2008, voir Modèles
d’administration (ADMX) pour Windows Server 2008.
L’outil Dcgpofix ne restaure pas les paramètres de
sécurité dans la stratégie de contrôleur de domaine
par défaut à leur état d’origine
Cet article explique que l’outil Dcgpofix ne restaure pas les paramètres de sécurité de la stratégie de contrôleur
de domaine par défaut à l’état dans le même état qu’après avoir correctement terminé Dcpromo et qu’il est
préférable d’utiliser cet outil uniquement dans le cadre d’un scénario de récupération d’urgence.
Symptômes
La documentation de l’outil Dcgpofix.exe indique à tort que l’outil Dcgpofix restaurera les paramètres de sécurité
dans la stratégie de contrôleur de domaine par défaut dans le même état que celui où ils se sont produits
immédiatement après la fin de Dcpromo. Ce n’est pas le cas.
Il est préférable d’utiliser l’outil Dcgpofix uniquement dans les scénarios de récupération d’urgence. L’opération
Dcpromo modifie la sécurité du domaine de manière incrémentielle, en fonction des paramètres de sécurité
existants sur ce serveur. Par conséquent, après avoir exécuté Dcpromo, l’ensemble final des paramètres de
sécurité dans la stratégie de contrôleur de domaine par défaut dépend à la fois de l’opération Dcpromo et de
l’état de sécurité du système qui existait avant d’exécuter Dcpromo. Avant d’exécuter Dcpromo, l’état de sécurité
du système peut être modifié par un certain nombre de mécanismes. Par exemple, lorsque vous installez
certaines applications serveur, des modifications peuvent être apportées aux droits d’utilisateur accordés aux
comptes d’utilisateurs locaux, tels que le SUPPORT_388945a0 client.
Cause
L’outil Dcgpofix ne peut pas savoir dans quel état les paramètres de sécurité se sont produits avant d’exécuter
Dcpromo. Par conséquent, l’outil Dcgpofix ne peut pas renvoyer les paramètres de sécurité à l’état d’origine. Au
lieu de cela, l’outil Dcgpofix recrée les deux objets de stratégie de groupe (GPO) par défaut et crée les
paramètres en fonction des opérations effectuées uniquement pendant Dcpromo.
Si vous avez une nouvelle installation de Windows Server et qu’aucune modification de sécurité n’est apportée
au système d’exploitation avant d’exécuter Dcpromo, la stratégie de contrôleur de domaine par défaut créée par
Dcgpofix sera presque identique à la stratégie de contrôleur de domaine par défaut juste après l’utilisation de
Dcpromo. Toutefois, il y aura des différences dans les paramètres de la stratégie de contrôleur de domaine par
défaut dans ce cas.
Résolution
Pour la sauvegarde et la restauration générales de la stratégie de domaine par défaut et de la stratégie de
contrôleur de domaine par défaut, ainsi que pour d’autres G GPO, Microsoft recommande d’utiliser la Console
de gestion des stratégies de groupe (GPMC) pour créer des sauvegardes régulières de ces GGP. Vous pouvez
ensuite utiliser gpmc conjointement avec ces sauvegardes pour restaurer les paramètres de sécurité exacts
contenus dans ces G STRATÉGIE de groupe.
Si vous êtes dans un scénario de récupération d’urgence et que vous n’avez aucune version de la stratégie de
domaine par défaut ou de la stratégie de contrôleur de domaine par défaut, vous pouvez envisager d’utiliser
l’outil Dcgpofix. Si vous utilisez l’outil Dcgpofix, Microsoft recommande de passer en revue les paramètres de
sécurité de ces GPO dès que vous l’exécutez et d’ajuster manuellement les paramètres de sécurité en fonction de
vos besoins. Un correctif n’est pas prévu pour être publié, car Microsoft vous recommande d’utiliser gpmc pour
la back up et la restauration de tous les G GPOs dans votre environnement. L’outil Dcgpofix est un outil de
récupération d’urgence qui restaure votre environnement à un état fonctionnel uniquement. Il est préférable de
ne pas l’utiliser en remplacement d’une stratégie de sauvegarde à l’aide de gpmc. Il est préférable d’utiliser
l’outil Dcgpofix uniquement lorsqu’une sauvegarde DCG pour la stratégie de domaine par défaut et la stratégie
de contrôleur de domaine par défaut n’existe pas.
Le tableau suivant répertorie les différences de paramètres de sécurité dans la stratégie de contrôleur de
domaine par défaut après avoir exécuté l’outil Dcgpofix et les paramètres sur une nouvelle installation de
Windows Server après avoir exécuté Dcpromo. Microsoft recommande d’ajuster ces paramètres de sécurité
pour qu’ils correspondent aux exigences de votre environnement après avoir exécuté l’outil Dcgpofix.
PA RA M ÈT RE DA N S L A ST RAT ÉGIE DE VA L EUR A P RÈS L’EXÉC UT IO N DE

C O N T RÔ L EUR DE DO M A IN E PA R DC P RO M O SUR UN SERVEUR VA L EUR A P RÈS L’EXÉC UT IO N DE
DÉFA UT W IN DO W S C O RREC T EM EN T IN STA L L É DC GP O F IX
Auditer Paramètres
Auditer la gestion des comptes Opération réussie Aucun audit
Auditer l’accès au service d’annuaire Opération réussie Aucun audit
Auditer la modification de la stratégie Opération réussie Aucun audit
Auditer les événements système Opération réussie Aucun audit
Droits d’utilisateur
Créer des objets globaux Non défini SERVICE, Administrateurs
Refuser l’accès à l’ordinateur à partir du SUPPORT_388945a0 (Vide)

réseau
Refuser l’logo en local SUPPORT_388945a0 (Vide)
Emprunter l’identité d’un client après Non défini SERVICE, Administrateurs

l’authentification
Charger et décharger les pilotes de Administrateurs, opérateurs Administrateurs

périphérique d’impression
Se connecter en tant que travail par lot SERVICE LOCAL, SUPPORT_388945a0 (Vide)
Ouvrir une session en tant que service SERVICE RÉSEAU (Vide)
Arrêter le système Administrateurs, opérateurs de Opérateurs de compte,

sauvegarde, opérateurs de serveur, administrateurs, opérateurs de
opérateurs d’impression sauvegarde, opérateurs de serveur,
opérateurs d’impression
Les paramètres suivants changent après avoir exécuté l’outil Dcgpofix :
AuditAccountManage
AuditDSAccess
AuditPolicyChange
AuditSystemEvents
SeCreateGlobalPrivilege
SeImpersonatePrivilege
SeLoadDriverPrivilege
SeShutdownPrivilege
En fonction des options de configuration, les paramètres suivants peuvent également modifier les paramètres
suivants :
SeBatchLogonRight (uniquement LE SERVICE LOCAL, et non le SUPPORT_388945a0)
SeServiceLogonRight
Description des groupes restreints de stratégie de
groupe
Cet article fournit une description des groupes restreints de stratégie de groupe dans Windows Server 2016,
Windows Server 2012 R2 et Windows Server 2008 R2 Service Pack 1.
S’applique à : Windows Server 2016, Windows Server 2012 R2, Windows Server 2008 R2 Service Pack 1
Les groupes restreints permettent à un administrateur de définir les deux propriétés suivantes pour les groupes
sensibles à la sécurité (restreints) :
Members
Membre de
La liste Membres définit qui doit et ne doit pas appartenir au groupe restreint. La liste Membre de spécifie
les autres groupes auquel le groupe restreint doit appartenir.
Utiliser la partie groupe restreint Membres de la stratégie

Lorsqu’une stratégie de groupe restreinte est appliquée, tout membre actif d’un groupe restreint qui ne figure
pas dans la liste Membres est supprimé, à l’exception de l’administrateur du groupe Administrateurs. Tout
utilisateur de la liste Membres qui n’est pas membre du groupe restreint est ajouté.
Utiliser la partie Membre du groupe restreint de la stratégie
Seule l’inclusion est appliquée dans cette partie d’une stratégie de groupe restreinte. Le groupe restreint n’est
pas supprimé des autres groupes. Il permet de s’assurer que le groupe restreint est membre des groupes
répertoriés dans la boîte de dialogue Membre de.
Gérer l’appartenance à des groupes de domaines à l’aide de groupes restreints
Microsoft ne prend pas en charge l’utilisation de groupes restreints dans ce scénario. Les groupes restreints sont
des moyens de configuration client qui ne peuvent pas être utilisés avec des groupes de domaines. Les groupes
restreints sont spécifiquement conçus pour fonctionner avec des groupes locaux. Les objets de domaine doivent
être gérés dans les outils AD traditionnels. Pour l’instant, nous ne prévoyons pas d’ajouter ou de prendre en
charge l’utilisation de groupes restreints comme moyen de gérer des groupes de domaines.
Traitement en boucle de la stratégie de groupe
Cet article vous aide à résoudre le problème d’application de la fonction de bouclage de stratégie de groupe
lorsqu’un utilisateur se signe à un ordinateur dans une unité d’organisation spécifique.
Résumé
La stratégie de groupe s’applique à l’utilisateur ou à l’ordinateur d’une manière qui dépend de l’emplacement
des objets utilisateur et ordinateur dans Active Directory. Dans certains cas, les utilisateurs peuvent avoir besoin
d’une stratégie qui leur soit appliquée en fonction de l’emplacement de l’objet ordinateur uniquement. Vous
pouvez utiliser la fonctionnalité de bouclation de stratégie de groupe pour appliquer des objets de stratégie de
groupe qui dépendent uniquement de l’ordinateur auquel l’utilisateur se connecté.
Pour définir la configuration utilisateur par ordinateur, suivez les étapes suivantes :
1. Dans la console de gestion Microsoft (MMC) de stratégie de groupe, sélectionnez Configuration
ordinateur.
2. Recherchez des modèles d’administration, sélectionnez Système, sélectionnez stratégie de groupe,
puis activez l’option De stratégie de bouc.boucle.
Cette stratégie demande au système d’appliquer l’ensemble des GGPD de l’ordinateur à tout utilisateur qui se
connecte à un ordinateur affecté par cette stratégie. Cette stratégie est destinée aux ordinateurs à usage spécial
où vous devez modifier la stratégie utilisateur en fonction de l’ordinateur utilisé. Par exemple, les ordinateurs des
zones publiques, des laboratoires et des salles de classe.
NOTE
La boucle de rappel est prise en charge uniquement dans un environnement Active Directory. Le compte d’ordinateur et
le compte d’utilisateur doivent tous deux se trouver dans Active Directory. Si un contrôleur de domaine Microsoft
Windows NT 4.0 gère l’un ou l’autre compte, la boucle de rappel ne fonctionne pas. L’ordinateur client doit être un des
systèmes d’exploitation suivants :
Windows 2000 Server
Windows 2000 Advanced Server
Windows Server 2003
Lorsque les utilisateurs travaillent sur leurs propres stations de travail, vous souhaitez peut-être que les
paramètres de stratégie de groupe s’appliquent en fonction de l’emplacement de l’objet utilisateur. Nous vous
recommandons donc de configurer les paramètres de stratégie en fonction de l’unité d’organisation dans
laquelle réside le compte d’utilisateur. Lorsqu’un objet ordinateur réside dans une unité d’organisation
spécifique, les paramètres utilisateur d’une stratégie doivent être appliqués en fonction de l’emplacement de
l’objet ordinateur au lieu de l’objet utilisateur.
NOTE
Vous ne pouvez pas filtrer les paramètres utilisateur qui sont appliqués en refusant ou en supprimant les droits AGP et
Read de l’objet ordinateur spécifié pour la stratégie de bouc-boucle.
Le traitement normal de la stratégie de groupe utilisateur spécifie que les G STRATÉGIE de groupe sont
appliquées dans l’ordre des ordinateurs situés dans leur unité d’organisation au démarrage de l’ordinateur. Les G
GPO sont appliqués aux utilisateurs de leur unité d’organisation dans l’ordre pendant l’connexion, quel que soit
l’ordinateur sur lequel ils se connectent.
Cet ordre de traitement peut ne pas être approprié dans certains cas. Par exemple, lorsque vous ne souhaitez
pas que les applications qui ont été affectées ou publiées aux utilisateurs dans leur unité d’organisation soient
installées lorsque l’utilisateur est connecté à un ordinateur dans une unité d’organisation spécifique. Avec la
fonctionnalité de prise en charge de bouclation de stratégie de groupe, vous pouvez spécifier deux autres façons
de récupérer la liste des G STRATÉGIE de groupe pour n’importe quel utilisateur des ordinateurs de cette unité
d’organisation spécifique :
Mode fusion
Dans ce mode, lorsque l’utilisateur se connecte, la liste des GPO de l’utilisateur est généralement
rassemblée à l’aide de la fonction GetGPOList. La fonction GetGPOList est ensuite appelée à nouveau à
l’aide de l’emplacement de l’ordinateur dans Active Directory. La liste des G GPO de l’ordinateur est
ensuite ajoutée à la fin des GGP de l’utilisateur. Cela entraîne une priorité plus élevée pour les GO de
l’ordinateur que les G GPO de l’utilisateur. Dans cet exemple, la liste des G GPO de l’ordinateur est ajoutée
à la liste de l’utilisateur.
Mode de remplacement
Dans ce mode, la liste des G GPO de l’utilisateur n’est pas rassemblée. Seule la liste des objets de groupe
basés sur l’objet ordinateur est utilisée.
Comment définir la sécurité du journal des
événements localement ou à l’aide de la stratégie
de groupe
Vous pouvez personnaliser les droits d’accès de sécurité à leurs journaux d’événements Windows Server 2012.
Ces paramètres peuvent être configurés localement ou par le biais d’une stratégie de groupe. Cet article
explique comment utiliser ces deux méthodes.
S’applique à : Windows Server 2012 Standard, Windows Server 2012 Datacenter
Résumé
Vous pouvez accorder aux utilisateurs un ou plusieurs des droits d’accès suivants aux journaux des événements :
Lecture
Écriture
Effacer
IMPORTANT
Vous pouvez configurer le journal de sécurité de la même manière. Toutefois, vous pouvez modifier uniquement les
autorisations d’accès Lecture et Effacer. L’accès en écriture au journal de sécurité est réservé uniquement à l’Windows de
sécurité locale (LSA).
Vous pouvez utiliser une stratégie de modèle d’administration à cet effet. Le chemin d’accès du system Eventlog,
par exemple, est :
Configuration ordinateur\Modèles d’administration\Composants Windows\Service journal des

événements\Système
Le paramètre configure l’accès au journal et prend la même chaîne SDDL (Security Descriptor Definition
Language).
Microsoft suggère de passer à cette méthode une fois que vous êtes Windows Server 2012.
Configurer localement la sécurité du journal des événements

IMPORTANT
La sécurité de chaque journal est configurée localement via les valeurs de la clé de
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog Registre.
Par exemple, le descripteur de sécurité du journal des applications est configuré via la valeur de Registre
suivante : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD
Et le descripteur de sécurité du journal système est configuré via
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD .
Le descripteur de sécurité de chaque journal est spécifié à l’aide de la syntaxe SDDL. Pour plus d’informations
sur la syntaxe SDDL, voir le SDK platform ou l’article mentionné dans la section Références de cet article.
Pour construire une chaîne SDDL, notez qu’il existe trois droits distincts qui se rapportent aux journaux des
événements : Lecture, Écriture et Effacer. Ces droits correspondent aux bits suivants dans le champ de droits
d’accès de la chaîne ACE :
1 = Lecture
2 = Écriture
4 = Effacer
Voici un exemple de SDDL qui affiche la chaîne SDDL par défaut pour le journal des applications. Les droits
d’accès (en hexadécimal) sont en gras pour l’illustration :
O:BAG:SYD:(D;; 0xf0007 ;;; AN)(D;; 0xf0007 ;;; BG)(A;; 0xf0007 ;;; SY)(A;; 0x5 ;;; BA)(A;; 0x7 ;;; SO)(A;; 0x3 ;;;I U)
(A;; 0x2 ;;; BA)(A;; 0x2 ;;; LS)(A;; 0x2 ;;; NS)
Par exemple, la première ace refuse l’accès en lecture, en écriture et en clair aux utilisateurs anonymes au
journal. La sixième ACE permet aux utilisateurs interactifs de lire et d’écrire dans le journal.
Modifier votre stratégie locale pour permettre la personnalisation de

la sécurité de vos journaux d’événements
1. Back up the %WinDir%\Inf\Sceregvl.inf file to a known location.
2. Ouvrez %WinDir%\Inf\Sceregvl.inf dans Bloc-notes.
3. Faites défiler jusqu’au milieu du fichier, puis placez le pointeur immédiatement avant [Chaînes].
4. Insérez les lignes suivantes :
MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD,1,%AppLogSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD,1,%SysLogSD%,2
5. Faites défiler jusqu’à la fin du fichier, puis insérez les lignes suivantes :
AppLogSD="Event log: Specify the security of the application log in Security Descriptor Definition
Language (SDDL) syntax »
SysLogSD="Event log: Specify the security of the System log in Security Descriptor Definition
Language (SDDL) syntax »
6. Enregistrez et fermez le fichier.

7. Sélectionnez Démarrer, Sélectionnez Exécuter, tapez regsvr32 scecli.dll dans la zone Ouvrir, puis
8. Dans la boîte de dialogue DllRegisterSer ver scecli.dll a réussi, sélectionnez OK .
Utiliser la stratégie de groupe locale de l’ordinateur pour définir la
sécurité de votre application et du journal système
1. Sélectionnez Démarrer, sélectionnez Exécuter, tapez gpedit.msc, puis sélectionnez OK.
2. Dans l’éditeur de stratégie de groupe, développez Windows paramètre, développez Sécurité Paramètres,
développez Stratégies locales, puis développez Options de sécurité.
3. Double-cliquez sur journal des événements : fichier SDDL du journal des applications, tapez la chaîne SDDL
que vous souhaitez pour la sécurité du journal, puis sélectionnez OK .
4. Double-cliquez sur journal des événements : SDDL du journal système, tapez la chaîne SDDL que vous
souhaitez pour la sécurité du journal, puis sélectionnez OK .
Utiliser une stratégie de groupe pour définir la sécurité de votre

application et du journal système pour un domaine, un site ou une
unité d’organisation dans Active Directory
IMPORTANT
Pour afficher les paramètres de stratégie de groupe décrits dans cet article dans l’éditeur de stratégie de groupe,
complétez d’abord les étapes suivantes, puis continuez à la stratégie de groupe Utiliser pour définir la sécurité de votre
application et du journal système :
1. Utilisez un éditeur de texte tel Bloc-notes pour ouvrir le fichier Sceregvl.inf dans le dossier %Windir%\Inf.
2. Ajoutez les lignes suivantes à la section [Enregistrer les valeurs du Registre] :
MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD,1,%AppCustomSD%,
2
MACHINE\System\CurrentControlSet\Services\Eventlog\Security\CustomSD,1,%SecCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD,1,%SysCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\Directory
Service\CustomSD,1,%DSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\DNS
Server\CustomSD,1,%DNSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\File Replication
Service\CustomSD,1,%FRSCustomSD%,2
3. Ajoutez les lignes suivantes à la section [Chaînes] :
AppCustomSD="Eventlog: Security descriptor for Application event log »

SecCustomSD="Eventlog: Security descriptor for Security event log »
SysCustomSD="Eventlog: Security descriptor for System event log »
DSCustomSD="Eventlog: Security descriptor for Directory Service event log »
DNSCustomSD="Eventlog: Security descriptor for DNS Server event log »
FRSCustomSD="Eventlog: Security descriptor for File Replication Service event log »
4. Enregistrez les modifications que vous avez apportées au fichier Sceregvl.inf, puis exécutez la
regsvr32 scecli.dll commande.
5. Démarrez Gpedit.msc, puis double-cliquez sur les branches suivantes pour les développer :
Paramètres Windows
Sécurité Paramètres
Stratégies locales
Options de sécurité
6. Affichez le panneau droit pour rechercher les nouveaux paramètres eventlog.
Utiliser une stratégie de groupe pour définir la sécurité de votre application et du journal système
1. Dans le snap-in Sites et services Active Directory ou utilisateurs et ordinateurs Active Directory, cliquez
avec le bouton droit sur l’objet pour lequel vous souhaitez définir la stratégie, puis sélectionnez
Propriétés.
2. Sélectionnez l’onglet Stratégie de groupe.
3. Si vous devez créer une stratégie, sélectionnez Nouveau, puis définissez le nom de la stratégie. Sinon,
passez à l’étape 5.
4. Sélectionnez la stratégie de votre choix, puis sélectionnez Modifier.
Le logiciel en snap-in MMC de stratégie de groupe locale s’affiche.
5. Développez Configuration ordinateur, développez Windows Paramètres, développez Sécurité
Paramètres, développez Stratégies locales, puis sélectionnez Options de sécurité.
6. Double-cliquez sur journal des événements : fichier SDDL du journal des applications, tapez la chaîne
SDDL que vous souhaitez pour la sécurité du journal, puis sélectionnez OK .
7. Double-cliquez sur journal des événements : SDDL du journal système, tapez la chaîne SDDL que vous
souhaitez pour la sécurité du journal, puis sélectionnez OK .
Références
Pour plus d’informations sur la syntaxe SDDL et sur la construction d’une chaîne SDDL, voir Security Descriptor
String Format.
Comment accorder aux utilisateurs l’accès aux objets
de stratégie de groupe
Cet article explique comment accorder aux utilisateurs l’autorisation d’accéder à l’objet de stratégie de groupe si
la liste de contrôle d’accès a été modifiée afin que les autorisations Lecture et Application soient restreintes.
Résumé
Vous ne pourrez peut-être pas appliquer un objet de stratégie de groupe si la liste de contrôle d’accès (ACL) a
été configurée pour restreindre les autorisations de lecture et d’application pour l’objet de stratégie de groupe.
Par défaut, si vous êtes membre du groupe Utilisateurs authentifiés, vous avez accès aux objets de stratégie de
groupe. Le groupe Utilisateurs authentifiés dispose d’autorisations de lecture et d’application de stratégie de
groupe sur les objets de stratégie de groupe. Si le groupe Utilisateurs authentifiés est supprimé de la ACL sur
l’objet de stratégie de groupe, vous n’avez pas d’autorisations lecture et application pour cet objet de stratégie
de groupe.
En tant qu’administrateur, vous pouvez accorder aux utilisateurs l’accès à l’objet de stratégie de groupe à l’aide
de l’une des méthodes suivantes :
Ajoutez explicitement l’utilisateur à la ACL de l’objet de stratégie de groupe, puis accordez à cet utilisateur des
autorisations de lecture et d’application de la stratégie de groupe.
Donnez au groupe Utilisateurs authentifiés des autorisations de lecture et d’application de stratégie de
groupe.
Créez un groupe de sécurité, ajoutez les utilisateurs nécessaires à ce groupe, puis accordez à ce groupe des
autorisations de lecture et d’application de stratégie de groupe sur la ACL de l’objet de stratégie de groupe.
NOTE
Vous devez également vous assurer que l’utilisateur ou le groupe à qui il appartient n’est pas explicitement refusé d’accès
à l’objet de stratégie de groupe. Une autorisation de refus explicite remplace toujours une autorisation Autoriser.
Recommandations gestion des fichiers de modèle
d’administration de stratégie de groupe (.adm)
Cet article décrit le fonctionnement des fichiers ADM, les paramètres de stratégie disponibles pour gérer leur
fonctionnement et des recommandations sur la gestion des scénarios de gestion de fichiers ADM courants.
NOTE
Nous vous recommandons d’utiliser Windows Vista pour gérer l’infrastructure de stratégie de groupe à l’aide d’un
magasin central. Cette recommandation est valable même si l’environnement possède un mélange de clients et de
serveurs de bas niveau, tels que des ordinateurs exécutant Windows XP ou Windows Server 2003. Windows Vista utilise
un nouveau modèle qui utilise des fichiers ADMX et ADML pour gérer les modèles de stratégie de groupe.
Pour plus d’informations, consultez les sites Web suivants :
Déploiement d’une stratégie de groupe à l’Windows Vista
Comment créer le magasin central pour les fichiers de modèle d’administration de stratégie de groupe dans Windows
Vista
Si vous devez utiliser Windows ordinateurs basés sur XP ou Windows Server 2003 pour gérer l’infrastructure de stratégie
de groupe, consultez les recommandations de cet article.
Présentation des fichiers ADM

Les fichiers ADM sont des fichiers modèles utilisés par les stratégies de groupe pour décrire l’endroit où les
paramètres de stratégie basés sur le Registre sont stockés dans le Registre. Les fichiers ADM décrivent
également l’interface utilisateur que les administrateurs voient dans le logiciel en ligne éditeur d’objets de
stratégie de groupe. L’Éditeur d’objets de stratégie de groupe est utilisé par les administrateurs lorsqu’ils créent
ou modifient des objets de stratégie de groupe.
Stockage de fichiers ADM et valeurs par défaut

Dans le dossier Sysvol de chaque contrôleur de domaine, chaque GPO de domaine conserve un dossier unique,
nommé GPT (Group Policy Template). La stratégie de groupe stocke tous les fichiers ADM utilisés dans l’Éditeur
d’objets de stratégie de groupe lors de la dernière création ou modification des objets de stratégie de groupe.
Chaque système d’exploitation comprend un ensemble standard de fichiers ADM. Ces fichiers standard sont les
fichiers par défaut chargés par l’Éditeur d’objets de stratégie de groupe. Par exemple, Windows Server 2003
inclut les fichiers ADM suivants :
System.adm
Inetres.adm
Conf.adm
Wmplayer.adm
Wuau.adm
Fichiers ADM personnalisés
Les fichiers ADM personnalisés peuvent être créés par des développeurs de programmes ou des professionnels
de l’informatique pour étendre l’utilisation des paramètres de stratégie basés sur le Registre à de nouveaux
programmes et composants.
NOTE
Les programmes et les composants doivent être conçus et codés pour reconnaître les paramètres de stratégie décrits
dans le fichier ADM et y répondre.
Pour charger des fichiers ADM dans l’Éditeur d’objets de stratégie de groupe, suivez les étapes suivantes :
1. Démarrez l’Éditeur d’objets de stratégie de groupe.
2. Cliquez avec le bouton droit sur Modèles d’administration, puis cliquez sur Ajouter/Supprimer des
modèles.
NOTE
Les modèles d’administration sont disponibles sous Configuration de l’ordinateur ou de l’utilisateur.
Sélectionnez la configuration qui est correcte pour votre modèle personnalisé.

4. Cliquez sur un fichier ADM, puis sur Ouvrir.
5. Cliquez sur Fermer .
6. Les paramètres de stratégie de fichier ADM personnalisés sont désormais disponibles dans l’Éditeur
d’objets de stratégie de groupe.
Mettre à jour les fichiers et les timestamps ADM

Chaque station de travail d’administration utilisée pour exécuter l’Éditeur d’objets de stratégie de groupe stocke
les fichiers ADM dans le dossier %windir% \ Inf. Lorsque des GFO sont créés et modifiés pour la première fois,
les fichiers ADM de ce dossier sont copiés dans le sous-dossier Adm dans le GPT. Cela inclut les fichiers ADM
standard et tous les fichiers ADM personnalisés ajoutés par l’administrateur.
NOTE
La création d’un GPO sans modification ultérieure crée un GPO sans fichiers ADM.
Par défaut, lorsque les objets de stratégie de groupe sont modifiés, l’Éditeur d’objets de stratégie de groupe
compare les timestamps des fichiers ADM du dossier %windir% Inf de la station de travail à ceux stockés dans le
dossier \ Adm gpts. Si les fichiers de la station de travail sont plus nouveaux, l’Éditeur d’objets de stratégie de
groupe copie ces fichiers dans le dossier GPT Adm, en éritant les fichiers existants du même nom. Cette
comparaison se produit lorsque le nœud Modèles d’administration (configuration ordinateur ou utilisateur) est
sélectionné dans l’Éditeur d’objets de stratégie de groupe, que l’administrateur modifie ou non l’objet de
NOTE
Les fichiers ADM stockés dans le GPT peuvent être mis à jour en visualisé un objet de stratégie de groupe dans l’Éditeur
d’objets de stratégie de groupe.
En raison de l’importance des timestamps sur la gestion des fichiers ADM, la modification des fichiers ADM
fournis par le système n’est pas recommandée. Si un nouveau paramètre de stratégie est requis, Microsoft vous
recommande de créer un fichier ADM personnalisé. Cela empêche le remplacement des fichiers ADM fournis
par le système lorsque des Service Packs sont publiés.
Console de gestion des stratégies de groupe
Par défaut, la Console de gestion des stratégies de groupe (GPMC) utilise toujours les fichiers ADM locaux, quel
que soit leur horodat, et ne copie jamais les fichiers ADM dans le Sysvol. Si un fichier ADM est in found, GPMC
recherche le fichier ADM dans le GPT. En outre, l’utilisateur GPMC peut spécifier un autre emplacement pour les
fichiers ADM. Si un autre emplacement est spécifié, cet autre emplacement est prioritaire.
Réplication des GPO

Le service de réplication de fichiers (FRS) réplique les GTE pour les G STRATÉGIE de groupe dans l’ensemble du
domaine. Dans le cadre du GPT, le sous-dossier Adm est répliqué sur tous les contrôleurs de domaine du
domaine. Étant donné que chaque objet de stratégie de groupe stocke plusieurs fichiers ADM et que certains
d’entre eux peuvent être très importants, vous devez comprendre comment les fichiers ADM ajoutés ou mis à
jour lorsque vous utilisez l’Éditeur d’objets de stratégie de groupe peuvent affecter le trafic de réplication.
Utiliser les paramètres de stratégie pour contrôler les mises à jour des
fichiers ADM
Deux paramètres de stratégie disponibles pour faciliter la gestion des fichiers ADM. Ces paramètres rendent
possible pour l’administrateur d’affiner l’utilisation des fichiers ADM pour un environnement spécifique. Il s’agit
des paramètres « Désactiver les mises à jour automatiques des fichiers ADM » et « Toujours utiliser les fichiers
ADM locaux pour l’Éditeur de stratégie de groupe ».
Désactiver les mises à jour automatiques des fichiers ADM
Ce paramètre de stratégie est disponible sous Stratégie de groupe système modèles d’administration de
configuration utilisateur dans \ \ Windows Server \ 2003, Windows XP et Windows 2000. Ce paramètre peut
être appliqué à n’importe quel client activé pour la stratégie de groupe.
Toujours utiliser les fichiers ADM locaux pour l’éditeur de stratégie de groupe
Ce paramètre de stratégie est disponible sous Stratégie de groupe système \ modèles d’administration de
configuration \ \ ordinateur. Il s’agit d’un nouveau paramètre de stratégie. Il peut être appliqué uniquement aux
clients Windows Server 2003. Le paramètre peut être déployé sur des clients plus anciens, mais il n’aura aucun
effet sur leur comportement. Si ce paramètre est activé, l’Éditeur d’objets de stratégie de groupe utilise toujours
des fichiers ADM locaux dans le dossier %windir% Inf du système local lorsque vous modifiez un objet de
stratégie \ de groupe.
NOTE
Si ce paramètre de stratégie est activé, la désactiver les mises à jour automatiques du paramètre de stratégie de fichiers
ADM est implicite.
Scénarios courants et recommandations pour les problèmes

d’administration multilangue
Dans certains environnements, les paramètres de stratégie peuvent être présentés à l’interface utilisateur dans
différentes langues. Par exemple, un administrateur aux États-Unis peut vouloir afficher les paramètres de
stratégie pour un GPO spécifique en anglais, et un administrateur en France peut afficher le même GPO en
utilisant le français comme langue préférée. Étant donné que gpt ne peut stocker qu’un seul ensemble de
fichiers ADM, vous ne pouvez pas utiliser le GPT pour stocker des fichiers ADM pour les deux langues.
Pour Windows 2000, l’utilisation de fichiers ADM locaux par l’Éditeur d’objets de stratégie de groupe n’est pas
prise en charge. Pour contourner ce besoin, utilisez le paramètre de stratégie « Désactiver les mises à jour
automatiques des fichiers ADM ». Étant donné que ce paramètre de stratégie n’a aucun effet sur la création de
nouveaux GPO, les fichiers ADM locaux seront téléchargés vers le GPT dans Windows 2000 et la création d’un
GPO dans Windows 2000 définit effectivement « la langue de l’GPO ». Si le paramètre de stratégie « Désactiver
les mises à jour automatiques des fichiers ADM » est en vigueur sur toutes les stations de travail Windows 2000,
la langue des fichiers ADM dans le GPT est définie par la langue de l’ordinateur utilisé pour créer l’GPO.
Pour les administrateurs qui utilisent Windows XP et Windows Server 2003, le paramètre de stratégie « Toujours
utiliser les fichiers ADM locaux pour l’éditeur de stratégie de groupe » peut être utilisé. Cela permet à
l’administrateur français d’afficher les paramètres de stratégie à l’aide des fichiers ADM installés localement sur
sa station de travail (français), quel que soit le fichier ADM stocké dans le GPT. Lorsque vous utilisez ce
paramètre de stratégie, il est implicite que le paramètre de stratégie « Désactiver les mises à jour automatiques
des fichiers ADM » est activé pour éviter les mises à jour inutiles des fichiers ADM vers le GPT.
Envisagez également de standardiser le système d’exploitation le plus récent de Microsoft pour les stations de
travail d’administration dans un environnement d’administration multi-langue. Configurez ensuite les
paramètres de stratégie « Toujours utiliser les fichiers ADM locaux pour l’éditeur de stratégie de groupe » et «
Désactiver les mises à jour automatiques des fichiers ADM ».
Si Windows 2 000 stations de travail sont utilisées, utilisez le paramètre de stratégie « Désactiver les mises à
jour automatiques des fichiers ADM » pour les administrateurs et considérez les fichiers ADM dans le GPT
comme la langue efficace pour toutes les stations de travail Windows 2000.
NOTE
Windows Les stations de travail XP peuvent toujours utiliser leurs versions locales spécifiques à la langue.
Scénarios courants et recommandations pour les problèmes de

publication du système d’exploitation et du Service Pack
Chaque version de système d’exploitation ou de Service Pack inclut un sur-ensemble des fichiers ADM fournis
par les précédentes, y compris les paramètres de stratégie spécifiques aux systèmes d’exploitation qui sont
différents de ceux de la nouvelle version. Par exemple, les fichiers ADM fournis avec Windows Server 2003
incluent tous les paramètres de stratégie pour tous les systèmes d’exploitation, y compris ceux qui ne sont
pertinents que pour Windows 2000 ou Windows XP Professional. Cela signifie que seul l’affichage d’un GPO à
partir d’un ordinateur avec la nouvelle version d’un système d’exploitation ou d’un Service Pack permet de
mettre à niveau efficacement les fichiers ADM. Comme les versions ultérieures sont généralement un sur-
ensemble des fichiers ADM précédents, cela ne crée généralement pas de problèmes, en supposant que les
fichiers ADM utilisés n’ont pas été modifiés.
Dans certains cas, une version de service pack ou de système d’exploitation peut inclure un sous-ensemble des
fichiers ADM fournis avec les version antérieures. Cela peut présenter un sous-ensemble précédent des fichiers
ADM, ce qui a pour effet que les paramètres de stratégie ne sont plus visibles pour les administrateurs lorsqu’ils
utilisent l’Éditeur d’objets de stratégie de groupe. Toutefois, les paramètres de stratégie resteront actifs dans
l’GPO. Seule la visibilité des paramètres de stratégie dans l’Éditeur d’objets de stratégie de groupe est affectée.
Tous les paramètres de stratégie actifs (activés ou désactivés) ne sont pas visibles dans l’Éditeur d’objets de
stratégie de groupe, mais restent actifs. Étant donné que les paramètres ne sont pas visibles, il n’est pas possible
pour l’administrateur d’afficher ou de modifier ces paramètres de stratégie. Pour contourner ce problème, les
administrateurs doivent se familiariser avec les fichiers ADM inclus dans chaque version de système
d’exploitation ou de Service Pack avant d’utiliser l’Éditeur d’objets de stratégie de groupe sur ce système
d’exploitation, en gardant à l’esprit que le fait d’afficher un objet de stratégie de groupe est suffisant pour mettre
à jour les fichiers ADM dans le GPT, lorsque la comparaison d’timestamps détermine qu’une mise à jour est
appropriée.
Pour planifier cela dans votre environnement, Microsoft vous recommande soit :
Définissez un système d’exploitation/Service Pack standard à partir duquel l’affichage et la modification
des G STRATÉGIE de groupe ont lieu, en vous assurez que les fichiers ADM utilisés incluent les
paramètres de stratégie pour toutes les plateformes.
Utilisez le paramètre de stratégie « Désactiver les mises à jour automatiques des fichiers ADM » pour
tous les administrateurs de stratégie de groupe pour vous assurer que les fichiers ADM ne sont pas
remplacés dans le GPT par une session de l’Éditeur d’objets de stratégie de groupe et assurez-vous que
vous utilisez les derniers fichiers ADM disponibles auprès de Microsoft.
NOTE
La stratégie « Toujours utiliser les fichiers ADM locaux pour l’éditeur de stratégie de groupe » est généralement utilisée
avec cette stratégie, lorsqu’elle est prise en charge par le système d’exploitation à partir duquel l’Éditeur d’objets de
stratégie de groupe est exécuté.
Supprimer des fichiers ADM du dossier Sysvol

Par défaut, les fichiers ADM sont stockés dans le GPT, ce qui peut augmenter considérablement la taille du
dossier Sysvol. En outre, une modification fréquente des G STRATÉGIE de groupe peut entraîner une quantité
importante de trafic de réplication. L’utilisation d’une combinaison des paramètres de stratégie « Désactiver les
mises à jour automatiques des fichiers ADM » et « Toujours utiliser les fichiers ADM locaux pour l’éditeur de
stratégie de groupe » peut considérablement réduire la taille du dossier Sysvol et réduire le trafic de réplication
lié à la stratégie dans lequel un nombre important de modifications de stratégie se produit.
Si la taille du volume Sysvol ou du trafic de réplication lié à la stratégie de groupe devient problématique,
envisagez d’implémenter un environnement dans lequel Sysvol ne stocke aucun fichier ADM. Ou envisagez de
gérer des fichiers ADM sur des stations de travail d’administration. Ce processus est décrit dans la section
suivante.
Pour effacer le dossier Sysvol des fichiers ADM, suivez les étapes suivantes :
1. Activez le paramètre de stratégie « Désactiver la mise à jour automatique des fichiers ADM » pour tous les
administrateurs de stratégie de groupe qui modifiera les G STRATÉGIE de groupe.
2. Assurez-vous que cette stratégie a été appliquée.
3. Copiez les modèles ADM personnalisés dans le dossier %windir% \ Inf.
4. Modifiez les G GPO existants, puis supprimez tous les fichiers ADM du GPT. Pour ce faire, cliquez avec le
bouton droit sur Modèles d’administration, puis cliquez sur Ajouter/Supprimer un modèle.
5. Activez le paramètre de stratégie « Toujours utiliser les fichiers ADM locaux pour la modification des objets
de stratégie de groupe » pour les stations de travail d’administration.
Gérer les fichiers ADM sur les stations de travail d’administration

Lorsque vous utilisez le paramètre de stratégie « Toujours utiliser les fichiers ADM locaux pour l’éditeur de
stratégie de groupe », assurez-vous que chaque station de travail dispose de la dernière version des fichiers
ADM par défaut et personnalisés. Si tous les fichiers ADM ne sont pas disponibles localement, certains
paramètres de stratégie contenus dans un GPO ne seront pas visibles par l’administrateur. Évitez cela en
implémentant un système d’exploitation standard et une version de Service Pack pour tous les administrateurs.
Si vous ne pouvez pas utiliser un service pack et un système d’exploitation standard, implémentez un processus
pour distribuer les derniers fichiers ADM à toutes les stations de travail d’administration.
NOTE
Étant donné que les fichiers ADM de la station de travail sont stockés dans le dossier %windir% Inf, tout processus
utilisé pour distribuer ces fichiers doit s’exécuter dans le contexte d’un compte qui dispose d’informations
d’identification administratives sur la station de \ travail.
Windows XP ne prend pas en charge la modification des G STRATÉGIE de groupe lorsqu’il n’existe aucun fichier ADM
dans le dossier Sysvol. Dans un environnement dynamique, vous devez tenir compte de cette limitation de conception.
Le message « Les autorisations pour cet GPO dans
le dossier SYSVOL sont incohérentes avec celles
d’Active Directory » lorsque vous exécutez gpMC
Cet article fournit une solution à un problème d’autorisations qui se produit lorsque vous exécutez la Console de
gestion des stratégies de groupe dans un domaine Windows 2008 ou Windows Server 2003.
Symptômes
Lorsque vous exécutez la Console de gestion des stratégies de groupe (GPMC) dans un domaine Windows
Server 2008 ou Windows Server 2003, puis que vous sélectionnez stratégie de domaine par défaut ou stratégie
de contrôleurs de domaine par défaut, vous recevez l’un des messages suivants :
Les autorisations pour cet GPO dans le dossier SYSVOL sont incohérentes avec celles d’Active
Directory. Il est recommandé que ces autorisations soient cohérentes. Pour modifier les autorisations
dans SYSVOL en celles d’Active Directory, cliquez sur OK.
Vous recevez ce message si vous avez les autorisations de modifier la sécurité sur les objets de stratégie
de groupe (G OBJETS).
Directory. Il est recommandé que ces autorisations soient cohérentes. Contactez un administrateur
qui dispose des droits pour modifier la sécurité de cet GPO.
Vous recevez ce message si vous n’êtes pas autorisé à modifier la sécurité sur les objets de stratégie de
groupe (G OBJETS).
Cause
Ce problème se produit pour l’une des raisons suivantes :
La liste de contrôle d’accès (ACL) sur la partie Sysvol de l’objet de stratégie de groupe est définie pour hériter
des autorisations du dossier parent.
L’autorisation spéciale (objet List) est définie pour le groupe Utilisateurs authentifiés. Toutefois, le groupe
Utilisateurs authentifiés est absent de l’onglet Délégation de l’objet de stratégie de groupe.
Résolution
Si vous êtes autorisé à modifier la sécurité sur les G GPO par défaut, sélectionnez OK en réponse au message
mentionné dans la section Symptômes. Cette action modifie les ACA sur la partie Sysvol de l’objet de stratégie
de groupe et les rend cohérentes avec les ACA sur le composant Active Directory. Dans ce cas, la stratégie de
groupe supprime l’attribut d’héritage dans le dossier Sysvol.
Si vous recevez toujours le message, suivez les étapes suivantes :
1. Assurez-vous que vous exécutez le dernier Service Pack pour le système. Pour plus d’informations,
reportez-vous aux rubriques suivantes :
Comment obtenir le dernier Service Pack pour Windows Server 2008
2. Vérifiez si l’autorisation d’objet Liste est définie pour le groupe Utilisateurs authentifiés et si le groupe
Utilisateurs authentifiés est absent de l’onglet Délégation de l’objet de stratégie de groupe.
Si ces conditions sont vraies, réalisez l’une des actions suivantes :

1. Sélectionnez Restaurer les valeurs par défaut pour rétablir les autorisations par défaut.
2. Supprimez le groupe Utilisateurs authentifiés qui dispose de l’autorisation d’objet Liste (non recommandé).
Comportement de l’option « Supprimer cet élément
s’il n’est plus appliqué » dans les préférences de
stratégie de groupe
Cet article décrit le comportement de l’option Supprimer cet élément s’il n’est plus appliqué dans les préférences
de stratégie de groupe.
Résumé
Windows Server 2008 et les versions ultérieures de Windows la fonctionnalité préférences de stratégie de
groupe. Sous l’onglet Commun des préférences de stratégie de groupe, il existe une option Supprimer cet
élément lorsqu’il n’est plus appliqué. Cette option supprime un élément de préférences s’il a été appliqué
auparavant. Il existe une base de données locale sur l’ordinateur qui stocke ces informations.
Étant donné que l’option Supprimer cet élément lorsqu’il n’est plus appliqué est envisagée par ordinateur, cette
base de données n’est pas itinérante dans les profils utilisateur itinérants. Par conséquent, si une modification est
réalisée par les préférences de stratégie de groupe pour des parties du profil utilisateur itinérantes entre les
ordinateurs (par exemple, le Registre d’utilisateur), l’option Supprimer cet élément s’il n’est plus appliqué ne doit
pas être utilisée. Cette option ne fonctionne pas dans un scénario d’itinérance.
Pour un paramètre de stratégie d’ordinateur, la base de données est stockée à l’emplacement suivant :
C:\ProgramData\Microsoft\Group Policy\History
Pour un paramètre de stratégie utilisateur, la base de données est stockée à l’emplacement suivant :
C:\Users % username%\AppData\Local\Microsoft\Group Policy\History
Comment réinitialiser les droits utilisateur dans la
stratégie de groupe de domaine par défaut dans
Windows Server 2003
Cet article explique comment réinitialiser les droits utilisateur dans l’objet de stratégie de groupe (GPO) de
domaine par défaut dans Windows Server 2003.
Résumé
L’GPO de domaine par défaut contient de nombreux paramètres de droits d’utilisateur par défaut. Parfois, si
vous modifiez les paramètres par défaut, des restrictions inattendues peuvent être imposées aux droits des
utilisateurs. Si les modifications sont inattendues ou si les modifications n’ont pas été enregistrées afin de ne pas
savoir quelles modifications ont été apportées, vous de devez rétablir les valeurs par défaut des paramètres des
droits utilisateur.
Réinitialiser les droits d’utilisateur pour l’GPO de domaine par défaut
Pour restaurer les droits des utilisateurs afin d’utiliser les paramètres par défaut de l’GPO de domaine par
défaut, suivez les procédures décrites dans cette section dans l’ordre dans l’ordre indiqué.
WARNING
Veillez à faire preuve de prudence lorsque vous effectuez les procédures suivantes. Si vous configurez le modèle d’GPO de
manière incorrecte, vos contrôleurs de domaine risquent d’être inopérants.
Modifier le fichier Gpttmpl.inf

Pour modifier le fichier Gpttmpl.inf, suivez ces étapes.
IMPORTANT
Back up the Gpttmpl.inf file before you perform this procedure.
1. Démarrez Windows Explorer et ouvrez le dossier suivant, où Sysvol_path est le chemin d’accès du
dossier Sysvol :
Sysvol_path \ Stratégies Sysvol \ DomainName \ \ {31B2F340-016D-11D2-945F-00C04FB984F9} \
Machine\Microsoft \ Windows NT \ SecEdit
NOTE
Le chemin d’accès par défaut du dossier Sysvol est %SystemRoot% \ Sysvol.
2. Cliquez avec le bouton droit sur Gpttmpl.inf, puis cliquez sur Ouvrir.
3. Pour réinitialiser complètement les droits d’utilisateur sur les paramètres par défaut, remplacez les
informations existantes dans le fichier Gpttmpl.inf par les informations de droits d’utilisateur par défaut
suivantes. Pour ce faire, collez le texte suivant dans la section appropriée de votre fichier Gpttmpl.inf
actuel :
Unicode=yes
[System Access]
MinimumPasswordAge = 0
MaximumPasswordAge = 42
MinimumPasswordLength = 0
PasswordComplexity = 0
PasswordHistorySize = 1
LockoutBadCount = 0
RequireLogonToChangePassword = 0
ForceLogoffWhenHourExpire = 0
ClearTextPassword = 0
[Kerberos Policy]
MaxTicketAge = 10
MaxRenewAge = 7
MaxServiceAge = 600
MaxClockSkew = 5
TicketValidateClient = 1
[Version]
signature="$CHICAGO$"
Revision=1
4. Dans le menu Fichier, cliquez sur Enregistrer, puis sur Quitter.
NOTE
Les paramètres d’autorisations résultant de cette procédure sont les mêmes que les autorisations compatibles
avec les utilisateurs pré-Microsoft Windows 2000 et les autorisations compatibles uniquement avec Windows 2
000 utilisateurs.
Modifier le fichier Gpt.ini de données

Le fichier Gpt.ini contrôle les numéros de version du modèle de GPO. Vous devez modifier le fichier Gpt.ini pour
augmenter le numéro de version du modèle d’GPO. Pour ce faire, procédez comme suit :
1. Démarrez Windows Explorer et ouvrez le dossier suivant, où Sysvol_path est le chemin d’accès du
dossier Sysvol : Sysvol_path \ Sysvol \ Domain Policies \ \ {31B2F340-016D-11D2-945F-
00C04FB984F9}
NOTE
Le chemin d’accès par défaut du dossier Sysvol est %SystemRoot% \ Sysvol.
2. Cliquez avec le boutonGpt.ini, puis cliquez sur Ouvrir.

3. Augmentez le numéro de version à un nombre suffisant pour garantir que la réplication classique
n’obsolète pas le nouveau numéro de version avant la réinitialisation de la stratégie. Incrémenter le
nombre en ajoutant le nombre « 0 » à la fin du numéro de version ou le nombre « 1 » au début du
numéro de version.
4. Dans le menu Fichier, cliquez sur Enregistrer, puis sur Quitter.
Utiliser GPUpdate pour actualiser la stratégie de groupe
Appliquez le nouvel GPO à l’aide de l’outil GPUpdate pour réappliquer manuellement tous les paramètres de
stratégie. Pour ce faire, procédez comme suit :
2. Dans la zone Ouvrir, tapez cmd, puis cliquez sur OK.
3. À l’invite de commandes, tapez la ligne suivante, puis appuyez sur Entrée : GPUpdate /Force
4. Tapez exit, puis appuyez sur Entrée pour quitter l’invite de commandes.
NOTE
Pour rechercher des erreurs dans le traitement des stratégies, examinez le journal des événements.
Utilisez l’Observateur d’événements pour vérifier que l’GPO a été correctement appliqué. Pour ce faire, procédez
comme suit :
1. Cliquez sur Démarrer , pointez sur Outils d’administration , puis cliquez sur Obser vateur
d’événements .
2. Cliquez sur Application .
Recherchez l’ID d’événement 1704 pour vérifier que l’GPO a été correctement appliqué.
L’importation d’un GPO à l’aide de gpMC échoue
avec « L’annuaire n’est pas vide »
Cet article fournit des solutions à un problème dans lequel l’importation d’un objet de stratégie de groupe
enregistré à l’aide de la Console de gestion des stratégies de groupe (GPMC) échoue.
Symptômes
L’importation d’un GPO enregistré à l’aide de la Console de gestion des stratégies de groupe (GPMC) échoue de
manière inerrable avec une boîte de dialogue d’erreur « L’annuaire n’est pas vide ».
Cause
Lors de l’importation des paramètres de stratégie, la GPMC crée plusieurs répertoires temporaires
(intermédiaire) et sauvegarde les anciens paramètres dans des dossiers distincts.
Lorsque l’importation est effectuée sur le partage SysVol, la réplication DFSR peut interférer avec la séquence
d’importation et par conséquent afficher l’erreur ci-dessus.
Résolution 1
Pour éviter que des opérations conflictuelles ne se produisent, utilisez DFSRDIAG.EXE pour suspendre la
réplication sur le dc sur qui l’importation GPMC se produit. La commande exige que l’utilisateur spécifie le nom
du groupe de réplication, le nom du partenaire (dans ce cas, le dc utilisé pour l’importation est le partenaire) et
la durée en minutes de suspension de la réplication. DFSR reprend automatiquement la réplication une fois que
le nombre de minutes spécifié est écoulé.
1. Ouvrez une fenêtre d’invite de commandes d’administration.
2. Exécutez cette commande :
DFSRDIAG StopNow /rgname:"Domain System Volume" /partner:<DcName> /time:<number of minutes to suspend
replication>
.
NOTE
Dans cette commande, représente le nom du contrôleur de domaine et la durée de la réplication <DcName>
<number of minutes to suspend replication> suspendue.
3. Importer la stratégie de groupe.
NOTE
La réplication DFS enregistre l’événement 5106 lorsque la réplication est arrêtée et à nouveau lorsqu’elle reprend. Vous
pouvez utiliser ces événements pour surveiller l’état du service.
Événement 5106 lorsque la réplication est suspendue :
Nom du journal : réplication DFS

Source : DFSR
Utilisateur : N/A
Description :
Le mode de réplication sur la connexion au <Dc Name> partenaire a changé.
Mode de réplication précédent : respecter la planification configurée
Mode de réplication actuel : arrêter la réplication
Utilisation actuelle de la bande passante : complète
Durée, en minutes, du mode actuel : 5
ID de connexion : 79E6D60D-6044-4775-A9BE-D98DAF557BD6
ID de groupe de réplication : volume du système de domaine
Événement 5106 lors de la reprise de la réplication :

Source : DFSR
Utilisateur : N/A
Description :
Le mode de réplication sur la connexion au <DC Name> partenaire a changé.
Mode de réplication précédent : arrêter la réplication
Mode de réplication actuel : respecter la planification configurée
Utilisation actuelle de la bande passante : respecter la planification configurée
Durée, en minutes, du mode actuel :
ID de connexion : 79E6D60D-6044-4775-A9BE-D98DAF557BD6
ID de groupe de réplication : volume du système de domaine
Résolution 2
Pour résoudre le problème, au cas où l’importation devrait se produire plus souvent, ajoutez un filtre pour DFSR
afin d’exclure les répertoires temporaires de la réplication. Ces répertoires temporaires sont :
MachineOld
UserOld
MachineStaging
UserStaging
AdmOld
Pour modifier le filtre DFSR, modifiez cet objet dans AD comme indiqué ci-dessous :
CN=SYSVOL Share,CN=Content,CN=Domain System Volume,CN=DFSR-
GlobalSettings,CN=System,DC=Contoso,DC=Com
et modifiez l’attribut msdfsr-directoryfilter.
L’application des cinq répertoires à la fin des exclusions existantes doit ressembler à ceci :
DO_NOT_REMOVE_NtFrs_PreInstall_Directory,NtFrs_PreExisting___See_EventLog,MachineOld,UserOld,Machine
Staging,UserStaging,AdmOld
Pour que la DFSR lue les nouveaux paramètres à partir d’AD, exécutez dfsrdiag PollAD .
Erreur Adprep /gpprep (le système ne peut pas
trouver le fichier spécifié) ou incident de l’outil
Cet article fournit une solution aux erreurs qui se produisent lorsque vous utilisez l’outil Adprep avec /gpprep
l’argument.
Symptômes
Vous utilisez l’outil Adprep avec /gpprep l’argument Windows Server 2012 R2. Par exemple, vous exécutez les
arguments suivants :
adprep.exe /domainprep /gpprep
Lorsque vous faites cela, vous recevez l’erreur suivante :
Les informations à l’échelle du domaine ont déjà été mises à jour.

[État/Conséquence]
Adprep n’a pas tenté de réexécuter cette opération.
Adprep est sur le point de mettre à niveau les informations d’objet de stratégie de groupe (GPO) sur le
FSMO maître dc1.corp.contoso.com d’infrastructure.
Échec de l’opération Gpprep 3.
Échec de la mise à niveau des objets de stratégie de groupe de domaine.
[Action de l’utilisateur]
Vérifiez le fichier journal ADPrep.log et gpprep.log dans le répertoire
C:\Windows\debug\adprep\logs\20120809082547 pour la cause possible de l’échec.
Adprep a rencontré une erreur Win32.
Code d’erreur : 0x2 message d’erreur : le système ne peut pas trouver le fichier spécifié.
Échec de la mise à niveau de la stratégie de groupe.
Échec de la mise à niveau des objets de stratégie de groupe de domaine.
[Action de l’utilisateur]
Vérifiez le fichier journal ADPrep.log dans le répertoire C:\Windows\debug\adprep\logs\20120809082547
pour la cause possible de l’échec.
Adprep a rencontré une erreur Win32.
Code d’erreur : 0x2 message d’erreur : le système ne peut pas trouver le fichier spécifié.
Si vous utilisez la Adprep.exe incluse dans Windows Server 2012 R2, Adprep.exe se crashe et vous recevez une
erreur ressemblant à ce qui suit :
Nt5DS a cessé de fonctionner

Signature du problème :
Nom de l’événement problème : APPCRASH
Nom de l’application : adprep.exe
Version de l’application : 6.1.7601.17514
Timestamp de l’application : 4ce7a045
Nom du module d’erreur : StackHash_9a46
Version du module d’erreur : 6.1.7601.17725
Fault Module Timestamp: 4ec4aa8e
Code d’exception : c0000374
Décalage d’exception : 0000000000c40f2
Version du système d’exploitation : 6.1.7601.2.1.0.274.10
ID de paramètres régionaux : 1033
Informations supplémentaires 1 : 9a46
Informations supplémentaires 2 : 9a46fc9b92ce31eadc29a5f5673559ea
Informations supplémentaires 3 : ec6e
Informations supplémentaires 4 : ec6ee41ac19ad12f608f0599c2c1bb6f
Cause
Le détenteur de rôle principal des opérations d’infrastructure dans ce domaine implémente un espace de noms
disjoint. Adprep.exe suppose que les noms d’ordinateurs correspondent à leurs noms de domaine, car cette
correspondance est le comportement par défaut dans toutes les versions de Windows.
Résolution
NOTE
Toutes les étapes nécessitent l’appartenance au groupe Administrateurs du domaine. Exécutez également des commandes
à une invite de commandes avec élévation de niveau élevé.
1. Recherchez le titulaire du rôle principal d’infrastructure dans le domaine. Pour ce faire, exécutez la
commande : netdom.exe query fsmo .
2. Désactivez la réplication entrante et sortante (également appelée réplication entrante et sortante) sur le
serveur avec le rôle Infrastructure Master. Pour ce faire, exécutez la commande suivante :
repadmin.exe /options <infrastructure_master_name> +DISABLE_OUTBOUND_REPL +DISABLE_INBOUND_REPL
3. Connectez-vous au serveur avec le rôle Infrastructure Master et modifiez son suffixe DNS (Domain Name
System). Pour cela, procédez comme suit :
a. Démarrez SYSDM.CPL, sélectionnez OK, sélectionnez Modifier, puis sélectionnez Plus
b. Définissez le suffixe dans le suffixe DNS principal de cette zone d’ordinateur pour qu’il corresponde
au nom de domaine des services de domaine Active Directory (AD DS) au lieu du nom disjoint actuel.
4. Redémarrez et connectez-vous au serveur avec le rôle Infrastructure Master, puis exécutez la commande :
adprep.exe /domainprep /gpprep .
5. Utilisez SYSDM.CPL, puis suivez les étapes de l’étape 3, sauf que cette fois à l’étape 3B, vous devez définir
le suffixe dans le suffixe DNS principal de cette zone d’ordinateur pour qu’il corresponde au nom
disjoint d’origine sur le serveur avec le rôle Maître d’infrastructure.
6. Redémarrez, puis connectez-vous au serveur avec le rôle Infrastructure Master, puis activez la réplication
entrante et sortante. Pour ce faire, exécutez la commande suivante :
repadmin.exe /options <infrastructure_master_name> -DISABLE_OUTBOUND_REPL -DISABLE_INBOUND_REPL
Gpprep ajoute des fonctionnalités de planification entre domaines pour la stratégie de groupe et le mode de
planification de l’ensemble de stratégies résultante (RSOP). L’ajout de cette fonctionnalité nécessite la mise à jour
du système de fichiers dans les autorisations SYSVOL et AD DS pour les stratégies de groupe existantes.
L’environnement peut déjà contenir des autorisations personnalisées ou déléguées qui ont été implémentées
manuellement par les administrateurs. Dans ce cas, gpprep déclenche la réplication de tous les fichiers de
stratégie de groupe dans SYSVOL et peut refuser la fonctionnalité RSOP aux utilisateurs délégués jusqu’à ce que
leurs autorisations soient recréés par les administrateurs. Les administrateurs doivent donc exécuter gpprep une
seule fois dans l’historique d’un domaine. Gpprep ne doit pas être exécuté à chaque mise à niveau.
Remarques
Gpprep a été introduit dans Windows Server 2003.
Les espaces de noms disjoints ne sont pas une meilleure pratique de Microsoft.
Pour plus d’informations sur la prise en charge et les limitations des espaces de noms disjoints dans AD DS, voir
le site web Microsoft TechNet suivant :
https://technet.microsoft.com/library/cc731125(v=WS.10).aspx
Résoudre les problèmes des événements SCECLI
1202
Cet article décrit les méthodes de dépannage et de résolution des événements SCECLI 1202.
Résumé
La première étape du dépannage de ces événements consiste à identifier le code d’erreur Win32. Ce code
d’erreur distingue le type d’échec à l’origine de l’événement SCECLI 1202. Voici un exemple d’événement SCECLI
1202. Le code d’erreur est affiché dans le champ Description. Dans cet exemple, le code d’erreur est 0x534. Le
texte après le code d’erreur est la description de l’erreur. Une fois que vous avez trouvé le code d’erreur,
recherchez cette section de code d’erreur dans cet article, puis suivez les étapes de résolution des problèmes de
cette section.
0x534 : aucun mappage entre les noms de compte et les ID de sécurité n’a été effectué.
ou
0x6fc : la relation d’confiance entre le domaine principal et le domaine approuvé a échoué.
Code d'0x534 : aucun mappage entre les noms de compte et les ID

de sécurité n’a été effectué
Ces codes d’erreur signifient que la résolution d’un compte de sécurité en un identificateur de sécurité (SID) a
échoué. L’erreur se produit généralement soit en raison d’un nom de compte mal type, soit parce que le compte
a été supprimé après son ajout au paramètre de stratégie de sécurité. Elle se produit généralement dans la
section Droits de l’utilisateur ou dans la section Groupes restreints du paramètre de stratégie de sécurité. Elle
peut également se produire si le compte existe dans une relation d’confiance, puis si la relation d’confiance est
rompue.
1. Déterminez le compte à l’origine de l’échec. Pour ce faire, activez la journalisation du débogage pour
l’extension côté client configuration de la sécurité :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\
{827D319E-6EAC-11D2-A4EA-00C04F7 9F83A}
c. Dans le menu Edition, sélectionnez Ajouter une valeur, puis ajoutez la valeur de Registre
suivante :
Nom de la valeur : ExtensionDebugLevel
2. Actualisez les paramètres de stratégie pour reproduire l’échec. Pour actualiser les paramètres de
stratégie, tapez la commande suivante à l’invite de commandes, puis appuyez sur Entrée :
secedit /refreshpolicy machine_policy /enforce
Cette commande crée un fichier nommé Winlogon.log dans le %SYSTEMROOT%\Security\Logs dossier.

3. Recherchez le compte à problème. Pour ce faire, tapez la commande suivante à l’invite de commandes,
puis appuyez sur Entrée :
find /i "cannot find" %SYSTEMROOT%\security\logs\winlogon.log
La sortie Rechercher identifie les noms des comptes problématiques, par exemple, Impossible de
trouver Michael Namesier . Dans cet exemple, le compte d’utilisateur MichaelTiertier n’existe pas dans
le domaine. Ou elle a une orthographe différente, par exemple MichelleTiertier.
Déterminez pourquoi ce compte ne peut pas être résolu. Par exemple, recherchez des erreurs
typographiques, un compte supprimé, la stratégie erronée qui s’applique à cet ordinateur ou un
problème d’confiance.
4. Si vous déterminez que le compte doit être supprimé de la stratégie, recherchez la stratégie de problème
et le paramètre de problème. Pour déterminer quel paramètre contient le compte non résolu, tapez la
commande suivante à l’invite de commandes sur l’ordinateur qui produit l’événement SCECLI 1202, puis
c:\>find /i "account name" %SYSTEMROOT%\security\templates\policies\gpt*.*
Pour cet exemple, la syntaxe et les résultats sont les suivantes :
c:\>find /i "MichaelPeltier" %SYSTEMROOT%\security\templates\policies\gpt*.*

---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00000.DOM
---------- D:\WINNT\SECURITY\TEMPLATES\POLICIES\GPT00001.INF
SeInteractiveLogonRight = TsInternetUser,*S-1-5-32-549,*S-1-5-32-550,MichaelPeltier,*S-1-5-32-551,*S-
1-5-32-544,*S-1-5-32-548
Il identifie GPT00002.inf comme modèle de sécurité mis en cache à partir de l’objet de stratégie de
groupe (GPO) à problème qui contient le paramètre de problème. Il identifie également le paramètre de
problème en tant que SeInteractiveLogonRight. Le nom complet de SeInteractiveLogonRight est Logon
localement.
Pour obtenir une carte des constantes (par exemple, SeInteractiveLogonRight) à leurs noms complets
(par exemple, Se logon localement), voir microsoft Windows 2000 Server Resource Kit( Guide des
systèmes distribués). La carte se trouve dans la section Droits de l’utilisateur de l’Annexe.
5. Déterminez quel GPO contient le paramètre de problème. Recherchez le texte dans le modèle de sécurité
mis en cache identifié à l’étape GPOPath= 4. Dans cet exemple, vous verrez :
GPOPath={6AC1786C-016F-11D2-945F-00C04FB984F9}\MACHINE
{6AC1786C-016F-11D2-945F-00C04FB984F9} est le GUID de l’GPO.

6. Pour trouver le nom convivial de l’GPO, utilisez l’utilitaire kit de ressources Gpotool.exe. Tapez la
commande suivante à l’invite de commandes, puis appuyez sur Entrée :
gpotool /verbose
Recherchez la sortie du GUID identifié à l’étape 5. Les quatre lignes qui suivent le GUID contiennent le
nom convivial de la stratégie. Par exemple :
Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}
Policy OK
Details:
------------------------------------------------------------
DC: domcntlr1.wingtiptoys.com
Friendly name: Default Domain Controllers Policy
Vous avez maintenant identifié le compte à problème, le paramètre de problème et l’GPO du problème. Pour
résoudre le problème, supprimez ou remplacez l’entrée du problème.
Code d'0x2 : le système ne peut pas trouver le fichier spécifié

Cette erreur est similaire à 0x534 et à 0x6fc. Elle est causée par un nom de compte irrésolvable. Lorsque l 0x2 se
produit, il indique généralement que le nom de compte irrésolvable est spécifié dans un paramètre de stratégie
groupes restreints.
1. Déterminez le service ou l’objet qui a échoué. Pour ce faire, activez la journalisation du débogage pour
{827D319E-6EAC-11D2-A4EA-00C04F7 9F83A}
suivante :

find /i "cannot find" %SYSTEMROOT%\security\logs\winlogon.log
La sortie Rechercher identifie les noms des comptes problématiques, par exemple, Impossible de
trouver Michael Namesier . Dans cet exemple, le compte d’utilisateur MichaelTiertier n’existe pas dans
le domaine. Ou elle a une orthographe différente( par exemple, MichelleTiertier.
Déterminez pourquoi ce compte ne peut pas être résolu. Par exemple, recherchez des erreurs
typographiques, un compte supprimé, une stratégie erronée s’appliquant à cet ordinateur ou un
problème d’confiance.
4. Si vous déterminez que le compte doit être supprimé de la stratégie, recherchez la stratégie de problème
et le paramètre de problème. Pour trouver le paramètre qui contient le compte non résolu, tapez la
commande suivante à l’invite de commandes sur l’ordinateur qui produit l’événement SCECLI 1202, puis
c:\>find /i "account name" %SYSTEMROOT%\security\templates\policies\gpt*.*
Pour cet exemple, la syntaxe et les résultats sont les suivantes :
c:\>find /i "MichaelPeltier" %SYSTEMROOT%\security\templates\policies\gpt*.*

SeInteractiveLogonRight = TsInternetUser,*S-1-5-32-549,*S-1-5-32-550,JohnDough,*S-1-5-32-551,*S-1-5-
32-544,*S-1-5-32-548
Il identifie GPT00002.inf comme modèle de sécurité mis en cache à partir de l’GPO de problème qui
contient le paramètre de problème. Il identifie également le paramètre de problème en tant que
SeInteractiveLogonRight. Le nom complet de SeInteractiveLogonRight est Logon localement.
Pour obtenir une carte des constantes (par exemple, SeInteractiveLogonRight) à leurs noms complets
(par exemple, Se logon localement), voir le kit de ressources du serveur Windows 2000, distributed
Systems Guide. La carte se trouve dans la section Droits de l’utilisateur de l’Annexe.

gpotool /verbose
Recherchez le RÉSULTAT pour le GUID que vous avez identifié à l’étape 5. Les quatre lignes qui suivent le
GUID contiennent le nom convivial de la stratégie. Par exemple :
Policy OK
Details:
------------------------------------------------------------
Vous avez maintenant identifié le compte à problème, le paramètre de problème et l’GPO du problème. Pour
résoudre le problème, recherchez des instances du compte de problème dans la section Groupes restreints de la
stratégie de sécurité (dans cet exemple, MichaelTiertier), puis supprimez ou remplacez l’entrée du problème.
Code d'0x5 : accès refusé

Cette erreur se produit généralement lorsque le système n’a pas reçu les autorisations correctes pour mettre à
jour la liste de contrôle d’accès d’un service. Elle peut se produire si l’administrateur définit des autorisations
pour un service dans une stratégie, mais n’accorde pas au compte système des autorisations contrôle total.
1. Déterminez le service ou l’objet qui a échoué. Pour ce faire, activez la journalisation du débogage pour
{827D319E-6EAC-11D2-A4EA-00C04F7 9F83A}
suivante :

3. À l’invite de commandes, tapez ce qui suit, puis appuyez sur Entrée :
find /i "error opening" %SYSTEMROOT%\security\logs\winlogon.log
La sortie Rechercher identifie le service avec les autorisations mal configurées, par exemple, Erreur
d’ouver ture de Dbnache . Dbnache est le nom court du service client DNS.
4. Découvrez quelle stratégie ou quelles stratégies tentent de modifier les autorisations de service. Pour ce
faire, tapez la commande suivante à l’invite de commandes, puis appuyez sur Entrée :
find /i "service" %SYSTEMROOT%\security\templates\policies\gpt*.*".

Voici un exemple de commande et sa sortie :
d:\>find /i "dnscache" %windir%\security\templates\policies\gpt*.*
Dnscache,3,"D:AR(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;LA)"

gpotool /verbose
Recherchez la sortie du GUID identifié à l’étape 5. Les quatre lignes qui suivent le GUID contiennent le
nom convivial de la stratégie. Par exemple :
Policy OK
Details:
------------------------------------------------------------
Vous avez maintenant identifié le service avec les autorisations mal configurées et l’GPO de problème. Pour
résoudre le problème, recherchez dans la section Services système de la stratégie de sécurité les instances du
service avec les autorisations mal configurées. Ensuite, prenez des mesures correctives pour accorder au compte
système des autorisations contrôle total sur le service.
Code d'0x4b8 : une erreur étendue s’est produite

L 0x4b8 d’erreur est générique et peut être causée par de nombreux problèmes différents. Pour résoudre ces
erreurs, suivez les étapes suivantes :
1. Activez la journalisation du débogage pour l’extension côté client configuration de la sécurité :
{827D319E-6EAC-11D2-A4EA-00C04F7 9F83A}
suivante :

3. Voir les ID d’événement ESENT 1000, 1202, 412 et 454sont consignés à plusieurs reprises dans le journal
des applications. Cet article décrit les problèmes connus à l’origine 0x4b8'erreur.
Utiliser des GFO pour modifier le nom de domaine
par défaut de la logon dans l’écran d’accueil
Cet article explique comment utiliser les objets de stratégie de groupe (G OBJETS) pour modifier le nom de
domaine par défaut de l’accès.
S’applique à : Windows 10 - toutes les éditions
Symptômes
Dans un environnement multi-domaines, il existe des scénarios dans lequel les utilisateurs se connectent de
manière cohérente aux stations de travail qui sont jointes à un domaine différent de celui de l’utilisateur
connecté. Par défaut, le domaine à qui la station de travail est jointe est répertorié comme nom de domaine par
défaut et les autres utilisateurs de domaine doivent toujours fournir le nom d’utilisateur sous la forme domaine
\nom d’utilisateur pour se connecter correctement. Il existe également des scénarios où l’ordinateur est joint à
un domaine, mais où les connexions sont presque toujours en cours avec les comptes d’utilisateurs locaux (à
l’aide de .\username).
Cause
Il s’agit d’une erreur courante que les utilisateurs font pour ignorer le nom de domaine et tenter sans le savoir
de se connecter à un autre domaine que le leur et entraîner des échecs. Pour éviter ces problèmes et améliorer
l’expérience utilisateur, vous pouvez choisir un nom de domaine d’accès par défaut différent du nom de domaine
de station de travail.
Résolution
Le paramètre de stratégie de groupe suivant est disponible dans Windows d’exploitation Vista ou ultérieur :
Affectation d’un domaine par défaut pour la logon
Pour activer le domaine par défaut pour l’accès, suivez les étapes suivantes :
2. Dans la zone Ouvrir, tapez gpedit.msc, puis cliquez sur OK .
3. Sous Configuration ordinateur, développez Administrative Paramètres, expand System, puis cliquez
sur Logon .
4. Dans le volet droit, double-cliquez sur le paramètre Affecter un domaine par défaut pour la logon, puis
choisissez Activé.
5. Sous Options, vous pouvez fournir le nom du domaine que vous souhaitez définir comme domaine par
défaut
NOTE
Utilisez la console de gestion des stratégies de groupe (GPMC.msc) pour créer un GPO et configurer les paramètres au
niveau du domaine ou de l’ou.
La stratégie d’attribution d’un domaine par défaut pour la stratégie de groupe d’logonage spécifie un domaine
d’enregistrement par défaut qui peut être différent du domaine joint à l’ordinateur. Vous pouvez activer ce
paramètre de stratégie et ajouter le nom de domaine préféré afin que le nom de domaine d’accès par défaut soit
définie sur le domaine spécifié qui n’est peut-être pas le domaine joint à l’ordinateur. Si vous activez cette
stratégie et définissez le nom de domaine comme un point (.), une fois la stratégie appliquée à l’ordinateur, les
utilisateurs voient un point (.) comme leur domaine par défaut et, sauf si les utilisateurs spécifient un nom de
domaine ou un nom d’utilisateur pour se connecter, tous les utilisateurs seront traités comme des utilisateurs
locaux. (.\username)
NOTE
Conditions requises : cette stratégie s’applique à Windows Vista ou une ultérieure.
Utiliser l’ensemble résultant de la journalisation des
stratégies pour collecter des informations de
stratégie d’ordinateur
Cet article explique comment utiliser l’utilitaire Rsop.msc (Resultant Set of Policy) pour collecter uniquement des
informations de stratégie spécifiques à l’ordinateur.
Utiliser Rsop.msc
Lorsque vous utilisez l’utilitaire Jeu de stratégie résultant, vous pouvez collecter uniquement les informations de
stratégie spécifiques à l’ordinateur :
1. Cliquez sur Démarrer , cliquez sur Exécuter , tapez mmc dans la zone de texte Ouvrir , puis cliquez sur OK .
2. Cliquez sur Fichier, sur Ajouter/Supprimer un snapin, puis sur Ajouter dans la boîte de dialogue
Ajouter/Supprimer.
3. Cliquez sur Jeu de stratégie résultant, cliquez sur Ajouter, puis cliquez sur Fermer dans la boîte de
dialogue Ajouter/Supprimer un snapin autonome.
4. Cliquez sur OK dans la boîte de dialogue Ajouter/Supprimer. Le snapin Jeu de stratégie résultant s’affiche
dans la MMC.
5. Cliquez sur Générer des données RSOP dans le menu Action.
6. Cliquez sur Suivant, sur Mode journalisation, puis sur Suivant.
7. Cliquez sur cet ordinateur ou sur un autre ordinateur, puis tapez le nom de l’ordinateur.
8. Cliquez sur Sélectionner un utilisateur spécifique, puis cliquez sur l’espace vide qui se trouve sous les
utilisateurs répertoriés. Cela a le même effet que le fait de cliquer sur Ne pas afficher les paramètres de
stratégie utilisateur dans les résultats.
9. Cliquez sur Suivant, puis sur Suivant. Seuls les paramètres spécifiques à l’ordinateur sont affichés.
Conflit WinStoreUI.admx lorsque le magasin central
est mis à jour Windows 10 fichiers ADMX version
1511
Cet article fournit de l’aide pour résoudre un conflit WinStoreUI.admx qui se produit lorsque le magasin central
est mis à jour à l’aide de fichiers ADMX Windows 10 version 1511.
Symptômes
Le fichier WinStoreUI.admx est disponible dans Windows Server 2012 R2, mais n’est pas inclus dans la version
initiale de Windows 10. Toutefois, une fois que vous avez mis à jour le magasin central à l’aide des fichiers .admx
de Windows 10 Version 1511, l’erreur suivante s’affiche dès que vous commencez à modifier un objet de
stratégie de groupe ( GPO) :
L’espace de noms « Microsoft.Policies.WindowsStore » est déjà défini comme espace de noms cible pour un
autre fichier dans le magasin.
La comparaison des fichiers .admx de Windows Server 2012 R2 et Windows 10 Version 1511 indique que
WindowsStore.admx contient les mêmes informations que WinStoreUI.admx, ainsi que quelques paramètres de
stratégie supplémentaires. Une fois que vous avez supprimé WinStoreUI.admx, cette erreur ne se produit plus.
Toutefois, l’ensemble de stratégies résultant sur un ordinateur basé sur R2 2012 contient l’erreur suivante :
Une erreur s’est produite lors de la collecte de données pour les modèles d’administration. Les erreurs suivantes
ont été rencontrées
Impossible de trouver un fichier de ressources approprié pour \ \ <domain> \sysvol \

<domain.dns>policies\PolicyDefinitions\WinStoreUI.admx ( error = 2) : le système ne peut pas trouver le
fichier spécifié.
Cause
Dans Windows 10 version 1507, le fichier .admx Store a été supprimé. Un correctif a restauré le fichier .admx.
Toutefois, ce fichier a maintenant un nouveau nom. Une fois la version 1511 installée, lorsque les clients met à
jour leur magasin central, ils ont désormais deux fichiers .admx qui ont des paramètres identiques. Comme cela
n’est pas autorisé, l’erreur décrite dans la section « Symptômes » se produit.
Les fichiers .admx sont les suivants :
Nom du fichier de stratégie de groupe du Magasin d’origine : winstoreui.admx
Nouveau nom de fichier de stratégie de groupe du Windows Store : windowsstore.admx
Résolution
This problem is fixed in Windows 10 Version 1511 and by the most recent cumulative update. Dans la mesure
du possible, les clients concernés doivent mettre à niveau vers cette version. Pour éviter que l’erreur ne se
produise lorsque vous ouvrez Gpedit.msc et lorsque vous exécutez Gpresult.exe, suivez les étapes suivantes :
1. Vérifiez que vous avez à la fois winstoreui.admx et windowsstore.admx dans le magasin central.
2. Supprimez les fichiers winstoreui.admx et winstoreui.adml du magasin central.
3. Vérifiez que l’ouverture de Gpedit.msc et l’exécution Gpresults.exe fonctionnent sans erreur.
Message d’erreur erroné pour les fichiers .adml
manquants
Cet article fournit une solution à un problème dans lequel des messages d’erreur erronés sont renvoyés lorsque
des fichiers .adml sont manquants.
Symptômes
Symptômes de la SR :
Le contrôleur de domaine EN-US tente de créer un rapport de paramètres pour un GPO. Le rapport est créé
avec le message :
Impossible de trouver un fichier de ressources approprié pour le fichier (erreur = 2) : le système ne peut
\\domainname.com\sysvol\domainname.com\Policies\PolicyDefinitions\anyfile.admx pas trouver le fichier
spécifié.
Les fichiers .admx signalés comme manquants sont présents dans le dossier spécifié.
Symptômes de répropres :
La modification du nom du dossier qui contient les fichiers .adml appropriés renvoie l’erreur :
Impossible de trouver un fichier de ressources approprié pour le fichier (erreur = 3) : le système ne peut pas
\\domainname.com\sysvol\domainname.com\Policies\PolicyDefinitions\anyfile.admx trouver le chemin d’accès
spécifié.
Cette erreur se produit également lorsque le dossier EN-US n’existe pas et est manquant.
La modification des G GPO affectés devient impossible, les rapports sont imprécis. Le problème ne se produit
pas de la même manière lorsque d’autres fichiers et dossiers de langue sont manquants, car EN-US est la langue
de retour et il est chargé à la place lorsqu’une autre langue est manquante.
Cause
Pour générer des rapports ou modifier l’GPO, le fichier .admx doit être chargé, ainsi que le fichier de langage
.adml approprié. Selon l’utilisateur de langue native qui demande l’opération de modification/de rapport, le
fichier .adml est recherché dans le dossier de langue approprié (en for en, de de, an so on). Si, par exemple,
l’utilisateur à l’origine de l’interrogation souhaite obtenir l’anglais et que seuls les fichiers .adml allemands sont
installés, une telle erreur se produit.
Le rapport d’erreurs est incorrect, car il fait référence au fichier .admx comme manquant, alors que ce fichier est
présent à l’emplacement spécifié.
Résolution
Le fait de rendre les fichiers .adml disponibles pour la langue pour le dossier approprié résout le problème.
Découvrez comment créer le magasin central pourles fichiers de modèle d’administration de stratégie de
groupe dans Windows Vista .
Les préférences de stratégie de groupe suppriment
les mappages de lecteur manuels si le premier
paramètre d’utilisation disponible est activé
Cet article fournit une solution à un problème dans lequel les mappages de lecteur manuels sont supprimés
après le déploiement des mappages de disques via les préférences de stratégie de groupe.
Symptômes
Une fois les cartes de lecteur déployées par le biais des préférences de stratégie de groupe (GPP), les utilisateurs
observent que les lecteurs précédemment mappés ne sont plus disponibles après une nouvelle logon. En outre,
seul un sous-ensemble de lecteurs mappés configurés via GPP est présent si plusieurs stratégies sont
configurées par le biais d’éléments de carte de lecteur.
Cause
Dans un élément de carte de lecteur, il existe une option Lettre de lecteur permettant d’activer la première
option d’utilisation disponible, en commençant par le paramètre. Ce paramètre (désigne l’élément dans le
XML de carte de lecteur) est défini comme suit dans useLetter attributs spécifiques à l’élément:
useLetter - Si 1, la lettre fait référence à une lettre de lecteur unique sur laquelle l’action doit fonctionner. Si la
plage est 0, la lettre est le début alphabétique d’une plage de lettres de lecteur à laquelle l’action peut
s’appliquer. Lorsque l’élément de préférence est configuré avec Utiliser d’abord disponible, en commençant à :
(ou dans le XML), l’extension côté client préférence effacera tous les lecteurs mappés commençant par ce dernier
lecteur par la lettre useLetter=0 Z. Si plusieurs stratégies GPP sont appliquées, l’ordre de traitement des cartes
de lecteur peut entraîner une suppression aléatoire des lecteurs mappés par GPP.
Résolution
Par conception, les cartes de lecteur sont effacées lorsque l’utilisation est disponible pour la première fois, en
commençant par le paramètre activé.
Si la première utilisation disponible, en commençant à la configuration est requise, assurez-vous que les
conditions suivantes sont remplies :
Les lecteurs mappés manuellement sont configurés pour utiliser des lettres de lecteur antérieures dans
l’alphabet que celles configurées par les cartes de lecteur GPP.
Une seule stratégie de carte de lecteur GPP est appliquée à l’utilisateur.
Vous pouvez également affecter des lettres de lecteur spécifiques à chaque carte de lecteur et ne pas utiliser la
première option Utiliser disponible, en commençant à l’option sur n’importe quel plan de lecteur. Par la suite,
un nombre quelconque de stratégies de carte de lecteur GPP peuvent être appliquées à l’utilisateur sans perte
de lecteurs mappés manuellement ou de cartes de lecteur GPP configurées dans plusieurs stratégies qui
s’appliquent à l’utilisateur.
Le paramètre de stratégie de groupe « Autoriser le
contenu actif à exécuter des fichiers sur mon
ordinateur » ne fonctionne pas comme prévu
Cet article fournit de l’aide pour résoudre un problème dans lequel le paramètre Autoriser le contenu actif à
exécuter des fichiers sur le paramètre de stratégie de groupe Mon ordinateur ne fonctionne pas.
Symptômes
Si vous utilisez Windows ou les outils d’administration de serveur distant (RSAT) pour Windows pour activer le
paramètre De préférence de stratégie de groupe Autoriser le contenu actif à exécuter des fichiers sur Mon
ordinateur reste désactivé lorsque la stratégie est appliquée sur les ordinateurs clients. Si vous désactivez le
paramètre de stratégie, vous constatez qu’il est activé sur les ordinateurs clients après la prochaine actualisation
de la stratégie de groupe.
Le paramètre Autoriser le contenu actif à exécuter des fichiers sur Mon ordinateur est configuré dans l’Éditeur
de gestion des stratégies de groupe en naviguant vers Configuration utilisateur\Préférences\Panneau de
configuration Paramètres\Internet Paramètres et en sélectionnant Nouveau, puis Internet Explorer 7 . Sous
l’onglet Avancé, faites défiler vers le bas jusqu’à la section Sécurité pour afficher le paramètre Autoriser le
contenu actif à exécuter des fichiers sur le paramètre Mon ordinateur.
Cause
Pour autoriser le contenu actif à exécuter des fichiers sur Mon ordinateur, la valeur de Registre suivante
doit être définie sur 0 :
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_LOCALMACHINE_LOCKDOWN
Nom de la valeur : iexplore.exe

Données de la valeur : 0
Lorsque vous configurez ce paramètre, la valeur est écrite en tant que « iexplore.exe » =dword:00000001 et
par conséquent, le paramètre est désactivé.
La mauvaise valeur est écrite à partir du fichier de paramètres XML préférences de stratégie de groupe :
<Reg id="LocalMachineFilesUnlock" type="REG_DWORD" hive="HKEY_CURRENT_USER" key="SOFTWARE\Microsoft\Internet

Explorer\Main\FeatureControl\FEATURE_LOCALMACHINE_LOCKDOWN" name="iexplore.exe" value="00000001"/>
L’emplacement par défaut du fichier de paramètreS de stratégie de groupe XML est :

%windir%\SYSVOL\sysvol\domain\Policies \ {GUID} \
<user/computer>\Preferences\InternetSettings\InternetSettings.xml
Résolution
Pour contourner ce problème, vous pouvez désactiver le paramètre Autoriser le contenu actif à exécuter des
fichiers sur le paramètre de stratégie My Computer et ce paramètre est activé lorsque la stratégie est appliquée
aux ordinateurs clients.
contrôler l’accès aux sites web
Cet article vous aide à utiliser Windows de groupe pour contrôler l’accès aux sites web.
Conseils
NOTE
L’utilisation des instructions ne fournit pas de solutions de gestion complète.
Pour les grandes entreprises/entreprises ayant des exigences de sécurité particulières, envisagez d’utiliser une solution de
gestion centrale, telle que Microsoft ISA Server.
1. Créer un objet de stratégie de groupe (objet de stratégie de groupe).

2. Sous le nouvel objet de groupe, accédez à : Configuration utilisateur\Windows
Paramètres\Maintenance Internet Explorer\Connexion\Connexion .
3. Double-cliquez sur proxy Paramètres .
4. Marquez la case à cocher Activer les paramètres de proxy.
5. Sous Adresse du proxy, écrivez le nom d’hôte du proxy local (dans le cas où vous n’avez pas de serveur
proxy, écrivez 0.0.0.0 comme adresse IP du serveur).
6. Sous Exceptions, écrivez le site web à qui vous autorisez l’accès (Pour utiliser plusieurs noms de site
web, ajoutez ; entre chaque nom de site web.
7. Appuyez sur le bouton Ok , puis fermez la MMC.
8. Appliquez le nouvel GPO à l’ou/domaine requis.
La stratégie de groupe Préférences d’imprimante ne
parvient pas à définir l’imprimante par défaut lors
de la création d’un profil utilisateur
Cet article fournit une solution de contournement pour un problème dans lequel les préférences d’imprimante
de stratégie de groupe ne parvient pas à définir l’imprimante par défaut.
Symptômes
Utilisation des préférences de stratégie de groupe pour créer un mappage d’imprimante et définir cette
imprimante comme imprimante par défaut échoue sur Windows Vista et les clients supérieurs lorsque
l’utilisateur se connecte pour la première fois. Le mappage d’imprimante a été créé avec succès, mais n’est pas
définie comme imprimante par défaut dans le Registre. Un suivi des préférences d’imprimante affiche l’erreur
suivante :
<VALUE>Le nom de l’imprimante n’est pas valide.</VALUE></PROPERTY>-</INSTANCE>

L’ID d’événement 4098 est consigné dans le journal des applications :
Source : imprimantes de stratégie de groupe
Date : <DateTime>
Catégorie de tâche : (2)
Ordinateur : server.fabrikam.com
Description :
L’élément de préférence « Imprimante HP » de l’objet de stratégie de groupe « Définir les imprimantes {XXX-
XXXX-XXXX-XXXX-XXXXXXXXXXXX} » ne s’est pas appliqué car il a échoué avec le code d’erreur «
0x80070709 Le nom de l’imprimante n’est pas valide ». Cette erreur a été supprimée.
Cause
Les préférences de stratégie de groupe créent le mappage d’imprimante réseau et appellent l’API
SetDefaultPrinterW() avant la fin de la connexion utilisateur. À ce stade, la connexion réseau sous Software \
Microsoft \ Windows NT \ CurrentVersion Devices \ n’est pas encore créée. Ainsi, lorsqu’elle appelle l’API
SetDefaultPrinterW(), elle échoue avec le code d’erreur 0x80070709 « Le nom de l’imprimante n’est pas valide ».
Les valeurs de Registre de connexion d’imprimante ne sont créées que par le service Spooler lorsqu’il reçoit la
notification SERVICE_CONTROL_SESSIONCHANGE de connexion. Ce message de notification ne sera envoyé
qu’une fois que l’utilisateur s’est terminé. Ainsi, lorsque les préférences de stratégie de groupe appellent
SetDefaultPrinterW() la première fois, l’imprimante par défaut n’est pas définie.
Résolution
Il n’existe actuellement aucun correctif pour ce problème. Les solutions de contourner le cas sont les suivantes :
1. Forcer la mise à jour d’une stratégie de groupe après l’utilisation de la GPUPDATE /FORCE commande
2. Redémarrer le service depooler (spooler) d’impression après l’utilisateur
3. Utiliser une tâche programmée pour exécuter un script après l’ment pour définir l’imprimante par défaut
4. Utiliser les préférences de Registre pour configurer l’imprimante par défaut
Utiliser la stratégie de groupe pour désactiver les
pilotes USB, CD-ROM, Disquette et LS-120
Cet article décrit un modèle ADM qui permet à un administrateur de désactiver les pilotes respectifs de ces
appareils.
Symptômes
Par défaut, la stratégie de groupe ne permet pas de désactiver facilement les lecteurs contenant des supports
amovibles, tels que les ports USB, les lecteurs de CD-ROM, les disques disquettes et les lecteurs de disquette LS-
120 haute capacité. Toutefois, la stratégie de groupe peut être étendue pour utiliser des paramètres
personnalisés en appliquant un modèle ADM. Le modèle ADM de cet article permet à un administrateur de
désactiver les pilotes respectifs de ces appareils, en s’assurant qu’ils ne peuvent pas être utilisés.
Résolution
Importez ce modèle d’administration dans la stratégie de groupe en tant que fichier .adm. Si vous ne savez pas
comment faire, consultez le lien dans la section « Plus d’informations ».
ORDINATEUR DE CLASSE
CATEGORY !) category
CATEGORY !) categoryname
POLICY !) policynameusb
KEYNAME « SYSTEM\CurrentControlSet\Services\USBSTOR »
EXPLAIN ! explaintextusb
PART ! labeltextusb DROPDOWNLIST REQUIRED
VALUENAME « Start »
ITEMLIST
NAME ! VALEUR NUMÉRIQUE DÉSACTIVÉE 3 PAR DÉFAUT
NAME ! VALEUR NUMÉRIQUE ACTIVÉE 4
END ITEMLIST
PARTIE DE FIN
STRATÉGIE DE FIN
POLICY !) policynamecd
KEYNAME « SYSTEM\CurrentControlSet\Services\Cdrom »
EXPLAIN ! explaintextcd
PART ! LABELtextcd DROPDOWNLIST OBLIGATOIRE
ITEMLIST
END ITEMLIST
PARTIE DE FIN
STRATÉGIE DE FIN
POLICY !) policynameflpy
KEYNAME « SYSTEM\CurrentControlSet\Services\Flpydisk »
EXPLIQUER ! explaintextflpy
PART ! LABELtextflpy DROPDOWNLIST OBLIGATOIRE
ITEMLIST
END ITEMLIST
PARTIE DE FIN
STRATÉGIE DE FIN
POLICY !) policynamels120
KEYNAME « SYSTEM\CurrentControlSet\Services\Sfloppy »
EXPLIQUER ! explaintextls120
PART ! labeltextls120 DROPDOWNLIST REQUIRED
ITEMLIST
END ITEMLIST
PARTIE DE FIN
STRATÉGIE DE FIN
CATÉGORIE DE FIN
CATÉGORIE DE FIN
[chaînes]
category="Custom Policy Paramètres »
categoryname="Restrict Drives »
policynameusb="Disable USB »
policynamecd="Disable CD-ROM »
policynameflpy="Disable Disquette »
policynamels120="Disable High Capacity Floppy »
explaintextusb="Disables the computers USB ports by disabling the usbstor.sys driver »
explaintextcd="Disables the computers CD-ROM Drive by disabling the cdrom.sys driver »
explaintextflpy="Disables the computers Disquepy Drive by disabling the flpydisk.sys driver »
explaintextls120="Disables the computers High Capacity Disquepy Drive by disabling the sfloppy.sys
driver »
labeltextusb="Disable USB Ports »
labeltextcd="Disable CD-ROM Drive »
labeltextflpy="Disable Disquette Drive »
labeltextls120="Disable High Capacity Disquepy Drive »
Enabled="Enabled »
Disabled="Disabled »
Pour plus d’informations sur l’application de fichiers de modèles d’administration, notamment des instructions
sur l’utilisation du modèle ci-dessus, téléchargez le livre blanc Microsoft « Using Administrative Template Files
with Registry-Based Group Policy » à partir d’ici.
Ce modèle est considéré comme une préférence plutôt qu’une véritable stratégie et il est conçu pour le registre
des ordinateurs clients avec ses paramètres. Si ce modèle est déplacé hors de l’étendue de la stratégie de
groupe qui l’applique, les modifications de Registre qu’il effectue restent. Si vous souhaitez inverser les
paramètres créés par ce modèle, inversez les options pour ré-activer les pilotes.
Les paramètres de préférence sont masqués par défaut dans l’éditeur de modèle de stratégie de groupe.
Lorsque vous appliquez ce modèle, suivez ces instructions pour modifier les paramètres d’affichage qui
autorisent l’affichage des préférences.
Community Exclusion de responsabilité de contenu de solutions

fournisseurs respectifs délament toutes les garanties et conditions concernant ces informations et les
graphiques associés, y compris toutes les garanties implicites et conditions de qualité, l’aptitude à un usage
particulier, l’effort de travail, le titre et la non-contrefaçon. Vous acceptez spécifiquement qu’en aucun cas
Microsoft et/ou ses fournisseurs ne soient responsables de tout dommage direct, indirect, indirect, accidentel,
spécial, conséquencenel, ou de tout dommage quelconque, y compris, sans limitation, de dommages en cas de
perte d’utilisation, de données ou de bénéfices, résultant ou en aucune manière lié à l’utilisation ou à
d’un contrat, d’un délit, d’une négligence, d’une responsabilité stricte ou autre, même si Microsoft ou l’un de ses
fournisseurs a été informé de la possibilité de dommages.
Application de ‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬conseils de résolution
des problèmes
Ce guide vous fournit les concepts fondamentaux utilisés pour résoudre les problèmes ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬. Vous
apprendrez à :
Comment rechercher de nouvelles informations de dépannage.
Comment utiliser la ‫ ﻋﺎرض اﻷ ﺣﺪاث‬pour filtrer des informations ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬spécifiques.
Comment lire et interpréter des données d’événement.
Méthodes correctes pour localiser le point de défaillance.

1. Commencez par lire ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬événements enregistrés dans le journal des événements système.
Les événements d’avertissement fournissent des informations supplémentaires à suivre pour vous
assurer que le service ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬reste sain.
Les événements d’erreur vous fournissent des informations qui décrivent l’échec et les causes
probables.
Utilisez le lien Plus d’informations inclus dans le message d’événement.
Utilisez l’onglet Détails pour afficher les codes d’erreur et les descriptions.
2. Utilisez le journal des opérations ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬.
Identifiez l’ID d’activité de l’instance de ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬traitement que vous résolvez.
Créez une vue personnalisée du journal des opérations.
Divisez le journal en phases : prétraitement, traitement et post-traitement.
Consolidez chaque événement de départ avec son événement de fin correspondant. Examinez tous les
événements d’avertissement et d’erreur.
Isoler et résoudre les problèmes du composant dépendant.
Utilisez la commande de mise à jour ‫( ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬GPUPDATE) pour actualiser ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬. Répétez
ces étapes pour déterminer si l’avertissement ou l’erreur existe toujours.
IMPORTANT
L’actualisation ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬modifie l’ID d’activité dans votre affichage personnalisé. Veillez à mettre à jour votre vue
personnalisée avec l’ID d’activité le plus actuel lors de la résolution des problèmes.
Déterminer l’instance de traitement ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬

Avant d’afficher le journal des opérations ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬, vous devez d’abord déterminer l’instance de ‫ﻧﮫﺞ‬
‫ ا ﻟﻤﺠﻤﻮﻋﺔ‬traitement qui a échoué.
Pour déterminer une instance de traitement ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬, procédez comme suit :
1. Ouvrez le ‫ﻋﺎرض اﻷ ﺣﺪاث‬.
2. Sous ‫( ﻋﺎر ض اﻷﺣﺪاث‬local), sélectionnez Système de journaux > Windows.
3. Double-cliquez sur l’événement d’avertissement ou d’erreur ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬que vous souhaitez résoudre.
4. Sélectionnez l’onglet Détails , puis vérifiez l’affichage Convivial . Sélectionnez Système pour développer
le nœud système .
5. Recherchez l’ActivityID dans les détails du nœud système . Vous utilisez cette valeur (sans accolades
ouvrantes et fermantes) dans votre requête. Copiez cette valeur dans le Bloc-notes afin qu’elle soit disponible
ultérieurement, puis sélectionnez Fermer .
Créer une vue personnalisée d’une instance ‫ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
Un ordinateur a souvent plusieurs instances de traitement ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬. Les ordinateurs dédiés à l’exécution de
Terminal Services ont généralement plusieurs instances de traitement ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬et fonctionnent
simultanément. Par conséquent, il est important de filtrer le ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬journal des événements opérationnels
pour afficher uniquement les événements de l’instance que vous dépannez.
Utilisez la procédure suivante pour créer une vue personnalisée d’une instance ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬. Pour ce faire,
utilisez une requête ‫ﻋﺎرض اﻷ ﺣﺪاث‬. Cette requête crée une vue filtrée du journal des opérations ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬
pour une instance spécifique du traitement ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬.
Pour créer une vue personnalisée d’une instance ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬, procédez comme suit :
1. Ouvrez le ‫ﻋﺎرض اﻷ ﺣﺪاث‬.
2. Cliquez avec le bouton droit sur Affichages personnalisés , puis sélectionnez Créer un affichage
personnalisé .
3. Sélectionnez l’onglet XML , puis cochez manuellement la case Modifier la requête. Le ‫ﻋﺎرض اﻷ ﺣﺪاث‬
affiche une boîte de dialogue expliquant que la modification manuelle d’une requête vous empêche de
modifier la requête à l’aide de l’onglet Filtre . Sélectionnez Oui .
4. Copiez la requête ‫( ﻋﺎرض اﻷ ﺣﺪاث‬fournie à la fin de cette étape) dans le Presse-papiers. Collez la requête
dans la zone Requête .
<QueryList><Query Id="0" Path="Application"><Select Path="Microsoft-Windows-GroupPolicy/Operational">*
[System/Correlation/@ActivityID='{INSERT ACTIVITY ID HERE}']</Select></Query></QueryList>
5. Copiez l’ActivityID que vous avez précédemment enregistré à partir de la section Déterminer l’instance
de ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬traitement dans le Presse-papiers. Dans la zone de requête , mettez en surbrillance «
INSERT ACTIVITY ID HERE », puis appuyez sur Ctrl+V pour coller l’ActivityID sur le texte.
NOTE
Veillez à ne pas coller sur les accolades de début et de fin ({ }). Vous devez inclure ces accolades pour que votre
requête fonctionne correctement.
6. Dans la boîte de dialogue Enregistrer le filtre dans l’affichage personnalisé , tapez un nom et une
description significatifs pour la vue que vous avez créée. Sélectionnez OK .
7. Le nom de la vue enregistrée s’affiche sous Vues personnalisées . Sélectionnez le nom de la vue
enregistrée pour afficher ses événements dans le ‫ﻋﺎرض اﻷ ﺣﺪاث‬.
IMPORTANT
Le service ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬affecte un ID d’activité unique pour chaque instance de traitement de stratégie. Par exemple, le
service ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬affecte un ActivityID unique lorsque le traitement de la stratégie utilisateur se produit pendant
l’ouverture de session de l’utilisateur. Lorsque ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬actualise, le service ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬affecte un autre ActivityID
unique à l’instance de ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬responsable de l’actualisation de la stratégie utilisateur.
Vérifiez que la stratégie de groupe a tous les paramètres que vous recherchez et qu’elle est correctement liée.
Vous trouverez ci-dessous les onglets que vous devez parcourir. Si tous sont corrects, accédez à la machine
cliente problématique.
1. Ouvrez une invite de commandes avec élévation de privilèges et exécutez la commande suivante.
gpresult /h gp.html
2. Vérifiez la gpresult sortie que vous avez capturée et recherchez l’objet de stratégie de groupe avec
lequel vous rencontrez des problèmes. Cela donne une erreur sur la raison pour laquelle l’objet de
stratégie de groupe n’est pas appliqué.
3. Si vous avez une erreur dans la gpresult sortie, nous pouvons résoudre le problème en fonction de
celui-ci. Autrement, passez à l’étape suivante.
4. Ouvrez le ‫ ﻋﺎرض اﻷ ﺣﺪاث‬et accédez aux journaux des événements de l’application et du système. Le
journal des événements de l’application vous donne les détails sur la raison pour laquelle la mise à jour
de la stratégie de groupe échoue positivement.
5. Ouvrez le journal des événements opérationnels pour plus d’informations. Il existe des événements avec
la liste des objets de stratégie de groupe appliqués et une liste d’objets de stratégie de groupe refusés
avec la raison.
La plupart des problèmes d’objet de stratégie de groupe peuvent être résolus à l’aide de ces journaux de base.
‫ ﻧﻬﺞ اﻟﻤﺠﻤﻮﻋﺔ‬fichiers journaux
Vous pouvez activer la journalisation détaillée et examiner les fichiers journaux résultants. La journalisation
détaillée peut réduire les performances et consommer de l’espace disque significatif. Par conséquent, il est
recommandé d’activer la journalisation détaillée uniquement si nécessaire.
Activer la journalisation ‫ ﻧ ﻬ ﺞ اﻟ ﻤ ﺠ ﻤ ﻮ ﻋ ﺔ‬Service (GPSvc)
Sur le client où le problème d’objet de stratégie de groupe se produit, procédez comme suit pour activer ‫ﻧﮫﺞ‬
‫ ا ﻟﻤﺠﻤﻮﻋﺔ‬journalisation du débogage de service.

2. Recherchez puis sélectionnez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
3. Dans le menu Modifier , sélectionnez Nouvelle > clé .

4. Tapez Diagnostics, puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur la sous-clé Diagnostics , sélectionnez Nouvelle > valeur DWORD
(32 bits ).
6. Tapez GPSvcDebugLevel, puis appuyez sur Entrée.
7. Cliquez avec le bouton droit sur GPSvcDebugLevel , puis sélectionnez Modifier .
8. Dans la zone de données Valeur , tapez 30002 (hexadécimal), puis sélectionnez OK .
10. Dans une fenêtre d’invite de commandes, exécutez la gpupdate /force commande, puis appuyez sur
Entrée.
Ensuite, affichez le fichier Gpsvc.log dans le dossier suivant : %windir%\debug\usermode
NOTE
Si le dossier usermode n’existe pas, créez-le sous %windir%\debug. Si le dossier usermode n’existe pas sous
%WINDIR%\debug\, le fichier gpsvc.log ne sera pas créé.

L’ID d’événement 1129 est enregistré lorsque le ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬ne s’applique pas en raison de problèmes de
connectivité réseau.
Dans ce cas, la connectivité au port LDAP (Lightweight Directory Access Protocol) 389 est bloquée sur dc. La
gpupdate commande échoue avec l’erreur suivante :
Lors de la vérification du journal des événements, vous pouvez trouver la description d’événement suivante :
The processing of Group Policy failed because of lack of network connectivity to a domain controller. This
may be a transient condition. A success message would be generated once the machine gets connected to the
domain controller and Group Policy has successfully processed. If you do not see a success Message for
several hours, then contact your administrator.
Dans ce cas, activez le journal de débogage gpsvc. Dans le journal gpsvc, vous pouvez trouver la sortie «
GetLdapHandle: Failed to connect <DC> with 81 ».
Activez une trace réseau pour vérifier :
Une requête ldap est effectuée au niveau du site.
La requête retourne deux entrées pour ce site qui détiennent le rôle de service ldap.
Pour l’un d’eux, nous pouvons voir qu’une résolution de noms est en cours.
Étant donné que la résolution de noms réussit, elle tente d’effectuer une liaison ldap, mais échoue lors de
l’établissement d’une liaison TCP, car le port 389 est bloqué.
S’il n’existe aucune réponse du contrôleur de domaine pour notre établissement de liaison TCP sur le port
389, les étapes suivantes consistent à impliquer l’équipe du réseau client et à lui fournir ces informations.
Assurez-vous que, dans de tels scénarios, vous utilisez tous les journaux spécifiés dans le plan d’action
mentionné ci-dessus, mettez-les en corrélation et qu’ils vous mèneront à la cause racine ou du moins
affinerez le problème.
Voici la description de l’ID d’événement 1002 :
The processing of Group Policy failed because of a system allocation failure. Please ensure the computer is
not running low on resources (memory, available disk space). Group Policy processing will be attempted at
the next refresh cycle.
Cet événement d’erreur est généralement résolu lorsque l’ordinateur retourne un état de faible ressource.
Résolutions possibles :
1. Assurez-vous que l’ordinateur ne manque pas de mémoire ou d’espace disque disponible.
2. Redémarrez l’ordinateur s’il fonctionne depuis une période prolongée.
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a
domain controller. (LDAP Bind function call failed). Look in the Details tab for error code and description.
Cet événement d’erreur est généralement résolu après la correction de la liaison au répertoire. Le service ‫ﻧﮫﺞ‬
‫ ا ﻟﻤﺠﻤﻮﻋﺔ‬consigne un code d’erreur, qui apparaît sous l’onglet Détails du message d’erreur dans ‫ﻋﺎرض اﻷ ﺣﺪاث‬.
Le code d’erreur (affiché sous forme de décimale) et les champs de description d’erreur identifient davantage la
raison de l’échec. Évaluez le code d’erreur avec la liste ci-dessous :
Code d’erreur 5 (Accès refusé)
Ce code d’erreur peut indiquer que l’utilisateur n’est pas autorisé à accéder à Active Directory.
Code d’erreur 49 (informations d’identification non valides)
Ce code d’erreur peut indiquer que le mot de passe de l’utilisateur a expiré pendant que l’utilisateur est
toujours connecté à l’ordinateur. Pour corriger les informations d’identification qui ne sont pas valides :
1. Modifiez le mot de passe de l’utilisateur.
2. Verrouillez/déverrouillez la station de travail.
3. Vérifiez si des services système s’exécutent en tant que compte d’utilisateur.
4. Vérifiez que le mot de passe dans la configuration du service est correct pour le compte d’utilisateur.
Le code d’erreur est 258 (délai d’expiration)
Ce code d’erreur peut indiquer que la configuration DNS est incorrecte. Pour corriger les problèmes de
délai d’expiration, utilisez l’outil nslookup pour confirmer _ldap._tcp.<domain-dns-name> les
enregistrements sont enregistrés et pointent vers les serveurs corrects (où <domain-dns-name> se
trouve le nom de domaine complet de votre domaine Active Directory).
NOTE
Ces étapes peuvent avoir des résultats variables si votre réseau restreint ou bloque les paquets ICMP (Internet
Control Message Protocol).
The processing of Group Policy failed. Windows attempted to retrieve new Group Policy settings for this user
or computer. Look in the Details tab for error code and description. Windows will automatically retry this
operation at the next refresh cycle. Computers joined to the domain must have proper name resolution and
network connectivity to a domain controller for discovery of new Group Policy objects and settings. An event
will be logged when Group Policy is successful.
Vérifiez si les ports LDAP sont ouverts. Si ce n’est pas le cas, vérifiez que les ports sont ouverts sur le pare-feu et
localement sur le client et le contrôleur de domaine.
Comment déterminer le bloc de port
Utilisez l’outil portqueryUI pour déterminer les ports bloqués. Pour plus d’informations, consultez Comment
utiliser PortQry pour résoudre les problèmes de connectivité Active Directory.
Utilisez telnet pour le port 389 pour vérifier la connectivité sur le port ldap.
Comment configurer des ports de domaine et d’approbation.
Configuration du comportement par défaut du pare-feu sortant.
Configurez les exigences de port de pare-feu pour ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬.
Assurez-vous que la résolution de noms DNS dans laquelle le client ne parvient pas à résoudre un nom d’hôte
Si un client ne peut pas résoudre un nom d’hôte, il est préférable de vérifier la séquence de résolution de
nom d’hôte répertoriée ci-dessus que le client doit utiliser. Si le nom n’existe dans aucune des ressources
utilisées par le client, vous devez décider quelle ressource l’ajouter. Si le nom existe dans l’une des ressources,
comme un serveur DNS ou un serveur WINS (Windows Internet Name Service), et que le client ne résout
pas correctement le nom, concentrez votre attention sur la résolution des problèmes de cette ressource
spécifique.
Vérifiez également que le client tente de résoudre un nom d’hôte et non un nom NetBIOS. De nombreuses
applications ont plusieurs méthodes qu’elles peuvent utiliser pour résoudre les noms. Cela est
particulièrement vrai pour les applications de messagerie et de base de données. L’application peut être
configurée pour se connecter aux ressources à l’aide de NetBIOS. Selon la configuration du client, le client
peut contourner la résolution de nom d’hôte. À partir de là, il sera nécessaire de modifier le type de
connexion en sockets TCP/IP ou de résoudre le problème en tant que problème NetBIOS.
autorisation de conteneur ‫ﻧ ﻬ ﺞ اﻟ ﻤ ﺠ ﻤ ﻮ ﻋ ﺔ‬
Utilisez l’applet de commande PowerShell Get-GPPermission suivante pour obtenir le niveau d’autorisation de
tous les principaux de sécurité sur l’objet de stratégie de groupe spécifié :
Get-GPPermission -Name "TestGPO" -All
The processing of Group Policy failed. Windows attempted to read the file %9 from a domain controller and
was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be
transient and could be caused by one or more of the following:
1. Name Resolution/Network Connectivity to the current domain controller.
2. File Replication Service Latency (a file created on another domain controller has not replicated to the
current domain controller).
3. The Distributed File System (DFS) client has been disabled.
Connectivité correcte au modèle ‫ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬. Le service ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬enregistre le nom du contrôleur de
domaine et le code d’erreur, qui s’affiche sous l’onglet Détails du message d’erreur dans ‫ﻋﺎرض اﻷ ﺣﺪاث‬. Le code
d’erreur (affiché sous forme de décimale) et les champs de description d’erreur identifient davantage la raison de
l’échec. Évaluez le code d’erreur avec la liste ci-dessous :
Code d’erreur 3 (Le système ne trouve pas le chemin spécifié)
Ce code d’erreur indique généralement que l’ordinateur client ne trouve pas le chemin spécifié dans
l’événement. Pour tester la connectivité du client au sysvol du contrôleur de domaine :
1. Identifiez le contrôleur de domaine utilisé par l’ordinateur. Le nom du contrôleur de domaine est
enregistré dans les détails de l’événement d’erreur.
2. Identifiez si l’échec se produit pendant le traitement de l’utilisateur ou de l’ordinateur. Pour le
traitement de la stratégie utilisateur, le champ Utilisateur de l’événement affiche un nom
d’utilisateur valide ; pour le traitement de la stratégie d’ordinateur, le champ Utilisateur affiche «
SYSTEM ».
3. Composez le chemin d’accès réseau complet au gpt.ini en tant que \\<domaine
dcName>\SYSVOL\<>\Policies\<guid\>gpt.ini où <dcName> est le nom du contrôleur de
domaine, <domain> le nom du domaine et <guid> le GUID du dossier de stratégie. Toutes les
informations apparaissent dans l’événement.
4. Vérifiez que vous pouvez lire gpt.ini à l’aide du chemin d’accès réseau complet obtenu à l’étape
précédente. Pour ce faire, ouvrez une fenêtre d’invite de commandes et tapez <file_path>, où
<file_path> se trouve le chemin d’accès construit à l’étape précédente, puis appuyez sur Entrée.
NOTE
Vous devez exécuter cette commande en tant qu’utilisateur ou ordinateur dont les informations
d’identification ont échoué précédemment.
Code d’erreur 5 (Accès refusé)

Ce code d’erreur indique généralement que l’utilisateur ou l’ordinateur ne dispose pas des autorisations
appropriées pour accéder au chemin spécifié dans l’événement. Sur le contrôleur de domaine, vérifiez
que l’utilisateur et l’ordinateur disposent des autorisations appropriées pour lire le chemin d’accès
spécifié dans l’événement. Pour tester les informations d’identification de l’ordinateur et de l’utilisateur :
1. Déconnectez-vous et redémarrez l’ordinateur.
2. Connectez-vous à l’ordinateur avec les informations d’identification de domaine précédemment
utilisées.
Code d’erreur 53 (le chemin d’accès réseau est introuvable)
Ce code d’erreur indique généralement que l’ordinateur ne peut pas résoudre le nom dans le chemin
d’accès réseau fourni. Pour tester la résolution de noms de chemin d’accès réseau :
1. Identifiez le contrôleur de domaine utilisé par l’ordinateur. Le nom du contrôleur de domaine est
consigné dans les détails de l’événement d’erreur.
2. Essayez de vous connecter au partage netlogon sur le contrôleur de domaine à l’aide du chemin \\
<dcName>\netlogon où <dcName> se trouve le nom du contrôleur de domaine dans l’événement
d’erreur.
The processing of Group Policy failed. Windows could not resolve the user name. This could be caused by one
or more of the following:
1. Name Resolution failure on the current domain controller.
2. Active Directory Replication Latency (an account created on another domain controller has not replicated
to the current domain controller).
Le service ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬enregistre le nom du contrôleur de domaine et le code d’erreur. Ces informations
apparaissent sous l’onglet Détails du message d’erreur dans ‫ﻋﺎرض اﻷ ﺣﺪاث‬. Le code d’erreur (affiché sous forme
de décimale) et les champs de description d’erreur identifient davantage la raison de l’échec. Évaluez le code
d’erreur avec la liste ci-dessous :
Code d’erreur 5 (Access est refusé) : ce code d’erreur peut indiquer que le mot de passe de l’utilisateur a
expiré alors que l’utilisateur était toujours connecté à l’ordinateur. Si l’utilisateur a récemment modifié son
mot de passe, le problème peut disparaître après avoir laissé le temps à la réplication Active Directory de
réussir.
1. Modifiez le mot de passe de l’utilisateur.
2. Verrouillez/déverrouillez la station de travail.
3. Vérifiez si des services système s’exécutent en tant que compte d’utilisateur.
4. Vérifiez que le mot de passe dans la configuration du service est correct pour le compte d’utilisateur.
Code d’erreur 14 (Stockage insuffisant disponible pour terminer cette opération)
Ce code d’erreur peut indiquer que Windows ne dispose pas de suffisamment de mémoire pour terminer
la tâche. Examinez le journal des événements système pour tout autre problème spécifique à la mémoire.
Code d’erreur 525 (l’utilisateur spécifié n’existe pas)
Ce code d’erreur peut indiquer des autorisations incorrectes sur l’unité d’organisation. L’utilisateur a
besoin d’un accès en lecture à l’unité d’organisation qui contient l’objet utilisateur. De même, les
ordinateurs nécessitent un accès en lecture à l’unité d’organisation qui contient l’objet ordinateur.
Code d’erreur 1355 (le domaine spécifié n’existe pas ou n’a pas pu être contacté)
Ce code d’erreur peut indiquer une erreur ou une configuration incorrecte avec résolution de noms
(DNS). Permet nslookup de confirmer que vous pouvez résoudre les adresses des contrôleurs de
domaine dans le domaine utilisateur.
Code d’erreur 1727 (L’appel de procédure distante a échoué et n’a pas été exécuté)
Ce code d’erreur peut indiquer que les règles de pare-feu empêchent la communication avec un
contrôleur de domaine. Si vous avez installé un logiciel de pare-feu tiers, vérifiez la configuration du
pare-feu ou essayez de le désactiver temporairement et de vérifier que ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬processus
correctement.
The processing of Group Policy failed. Windows could not determine the computer account to enforce Group
Policy settings. This may be transient. Group Policy settings, including computer configuration, will not be
enforced for this computer.
Les ordinateurs de domaine s’authentifient auprès du domaine, tout comme les utilisateurs du domaine.
Windows exige que l’ordinateur se connecte avant de pouvoir appliquer ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬à l’ordinateur. Résolutions
possibles :
Vérifiez que l’heure sur l’ordinateur est synchronisée avec l’heure sur le contrôleur de domaine.
Comptez les erreurs de configuration de fuseau horaire si l’ordinateur est configuré dans un fuseau horaire
différent du contrôleur de domaine.
Un intervalle de temps supérieur à cinq minutes entre l’ordinateur et le contrôleur de domaine peut entraîner
l’échec de l’authentification de l’ordinateur auprès du domaine. Forcez la synchronisation de l’heure par
rapport au service de temps à l’aide de la w32tm /resync commande.
Redémarrez l'ordinateur.
Collectez les informations clés avant de contacter pomoc techniczna

firmy Microsoft
Avant de terminer votre demande de support, nous vous recommandons d’utiliser la fonctionnalité Windows
Live Dump pour enregistrer un instantané de la mémoire du noyau sur l’ordinateur affecté. Pour cela, procédez
comme suit :
1. Capturez ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬journalisation détaillée du service en exécutant les commandes suivantes :
md %windir%\debug\usermode
reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t

REG_DWORD /d "0x00030002"
2. Actualisez les paramètres de ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬locaux et AD à l’aide de la gpupdate /force commande.

TIP
Utilisez l’une des commandes ci-dessous si vous résolvez les problèmes liés aux paramètres manquants d’un
utilisateur ou d’un ordinateur particulier :
Gpupdate /force /target:computer
Gpupdate /force /target:user
3. Enregistrez le rapport RSoP (Resultant Set of Policy) dans un fichier HTML en exécutant la commande
suivante :
gpresult /h %Temp%\GPResult.htm
4. Enregistrez les données récapitulatives RSoP dans un fichier txt en exécutant la commande suivante :
gpresult /r >%Temp%\GPResult.txt
5. Exportez les clés de Registre GPExtensions en exécutant la commande suivante :
reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions"

%Temp%\GPExtensions.reg
6. Exportez le système, l’application et ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬journaux de l’observateur d’événements opérationnels

en exécutant les commandes suivantes :
wevtutil.exe export-log Application %Temp%\Application.evtx /overwrite:true
wevtutil.exe export-log System %Temp%\System.evtx /overwrite:true
wevtutil.exe export-log Microsoft-Windows-GroupPolicy/Operational %Temp%\GroupPolicy.evtx

/overwrite:true
7. Capturez les fichiers suivants :

%Temp%\Application.evtx
%Temp%\System.evtx
%Temp%\GroupPolicy.evtx
%Temp%\GPExtensions.reg
%Temp%\GPResult.txt
%Temp%\GPResult.html
%windir%\debug\usermode\gpsvc.log
8. Lorsque vous avez terminé, vous pouvez arrêter ‫ ﻧﮫﺞ اﻟﻤﺠﻤﻮﻋﺔ‬journalisation du service en exécutant la
commande suivante :
reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t

REG_DWORD /d "0x00000000" /f
Erreur lorsque vous modifiez une stratégie dans
Windows :
Microsoft.Policies.Sensors.WindowsLocationProvided
est déjà défini
Cet article permet de résoudre un problème qui déclenche une erreur lorsque le magasin central contient les
fichiers .admx de Windows 10.
S’applique à : Windows 10 - toutes les éditions, Windows Server 2012 R2, Windows Server 2016, Windows
Server 2019
Symptômes
Envisagez les scénarios suivants.
Scénario 1 :
Vous avez un contrôleur de domaine qui exécute Windows Server.
Vous créez un magasin central pour les fichiers de modèles d’administration de stratégie de groupe (fichiers
.admx) sur l’ordinateur. Pour plus d’informations, voir Comment créer le magasin centralpour les fichiers de
modèle d’administration de stratégie de groupe dans Windows Vista .
Vous joignez un ordinateur Windows 10 au domaine.
Sur l’ordinateur basé sur Windows 10, vous copiez les fichiers sous le répertoire
%systemroot%\PolicyDefinitions, collez-les dans le magasin central ADMX, puis vous devez réécrire tous les
fichiers *.admx et *.adml existants. Ensuite, ouvrez la Console de gestion des stratégies de groupe (GPMC)
pour modifier une stratégie.
Vous cliquez sur le nœud Stratégies sous Configuration ordinateur ou Configuration utilisateur.
Scénario 2 :
Vous avez un ordinateur qui s’exécute Windows 10 RTM (build 10240).
Vous devez mettre à niveau l’ordinateur vers des builds ultérieures de Windows 10.
Dans ces scénarios, vous recevez le message d’erreur suivant :
Modèles d’administration
L’espace de noms « Microsoft.Policies.Sensors.WindowsLocationProvider » du texte du message de boîte de
dialogue est déjà défini comme espace de noms cible pour un autre fichier du magasin.
Fichier
\\<forest.root>\SysVol<\ forest.root>\Policies\PolicyDefinitions\Microsoft-Windows-Geolocation-
WLPAdm.admx, ligne 5, colonne 110
NOTE
L<'espace réservé forest.root > représente le nom de domaine.
Par exemple, le message d’erreur ressemble au message de la capture d’écran suivante :
NOTE
Vous ne remarquerez peut-être pas ce problème si vous êtes en cours de mise à niveau de Windows 7 ou Windows 8.1
vers Windows 10 version 1511 (ignorer Windows 10 RTM).
Cause
Ce problème se produit car le fichier LocationProviderADM.admx a été renommé Microsoft-Windows-
Geolocation-WLPAdm.admx dans Windows 10 RTM.
Scénario 1
Après avoir copié les fichiers .admx de Windows 10 vers un magasin central qui contient un fichier
LocationProviderADM.ADMX issu d’une version antérieure de Windows, il existe deux fichiers .admx qui
contiennent les mêmes paramètres, mais qui ont des noms différents. Cela déclenche l’erreur « l’espace
de noms est déjà défini ».
Scénario 2
Lorsque vous faites une mise à niveau de Windows 10 RTM vers Windows 10 version 1511, le nouveau
fichier LocationProviderAdm.admx est copié dans le dossier tout en conservant l’ancien fichier Microsoft-
Windows-Geolocation-WLPAdm.admx. Par conséquent, il existe deux fichiers ADMX qui s’adressent au
même espace de noms de stratégie.
Méthode 1
Cliquez sur OK pour ignorer le message d’erreur. Le message d’erreur est d’information et le paramètre
de stratégie de groupe fonctionne comme prévu.
Méthode 2
Supprimez les fichiers LocationProviderADM.admx et LocationProviderADM.adml, puis modifiez
Microsoft-Windows-Geolocation-WLPAdm.admx et Microsoft-Windows-Geolocation-WLPAdm.adml avec
les noms corrects.
Scénario 1 :
1. Supprimez les fichiers LocationProviderADM.admx et LocationProviderADM.adml du magasin central.
2. Renommez Microsoft-Windows-Geolocation-WLPAdm.admx comme LocationProviderADM.admx.
3. Renommez Microsoft-Windows-Geolocation-WLPAdm.adml en tant que LocationProviderADM.adml.
Scénario 2 :
Supprimez le fichier Microsoft-Windows-Geolocation-WLPAdm.admx du magasin local. Le chemin d’accès au
magasin de stratégies local est C:\Windows\PolicyDefinitions.
Les fichiers DMX et ADML sont protégés par le système. Pour renommer ou supprimer ces fichiers, vous devez
ajouter des autorisations NTFS aux fichiers. Pour ce faire, utilisez les commandes suivantes :
1. Ouvrez une invite de commandes avec élévation de takeown.exe pour accorder la propriété aux
administrateurs locaux :
takeown /F " C:\Windows\PolicyDefinitions\Microsoft-Windows-Geolocation-WLPAdm.admx" /A
takeown /F " C:\Windows\PolicyDefinitions\en-US\Microsoft-Windows-Geolocation-WLPAdm.adml" /A
2. Accorder aux administrateurs des autorisations de contrôle total sur les deux fichiers.
3. Renommez les deux fichiers avec l’extension .old et vous ne recevrez plus les fenêtres de géolocalisation
lorsque vous ouvrirez GPEDIT. MSC.
Il n’existe qu’une seule ligne de différence entre le contenu du fichier LocationProviderADM.admx pré-Windows
10 et le fichier Windows 10 Microsoft-Windows-Geolocation-WLPAdm.admx.
Dans le fichier Windows 10 LocationProviderADM.admx, la ligne apparaît <supportedOn> comme suit :
<supportedOn ref="windows:SUPPORTED_Windows8"/>
Dans la Windows 10 LocationProviderADM.admx, la ligne <supportedOn> apparaît comme suit :
<supportedOn ref="windows:SUPPORTED_Windows8_Or_Windows_6_3_Only"/>
Cette erreur se produit lorsque vous cliquez sur le nœud de stratégie sous Configuration ordinateur ou
Configuration utilisateur.
Le chemin d’accès définir le profil itinérant pour tous
les utilisateurs qui se connectent à cet ordinateur
paramètre de stratégie de groupe s’applique
également aux comptes d’utilisateurs locaux
Cet article décrit le comportement dans lequel le chemin d’accès définir le profil d’itinérance pour tous les
utilisateurs qui se connectent à ce paramètre de stratégie de groupe d’ordinateur s’applique à tous les comptes
d’utilisateurs, y compris les comptes d’utilisateurs locaux, car la stratégie de groupe remplacera la stratégie de
l’ordinateur local.
Symptômes
Vous appliquez le chemin d’accès définir le profil d’itinérance pour tous les utilisateurs qui se connectent à ce
paramètre de stratégie de groupe d’ordinateur dans un domaine pour les serveurs membres. Dans ce cas, le
paramètre de stratégie de groupe s’applique à tous les comptes d’utilisateur, y compris les comptes
d’utilisateurs locaux.
Cause
Ce comportement est attendu car le chemin d’accès définir le profil d’itinérance pour tous les utilisateurs qui se
connectent à ce paramètre de stratégie de groupe d’ordinateur est présent sous le nœud Configuration de
l’ordinateur dans la stratégie de groupe. Même si vous spécifiez une stratégie d’ordinateur local, la stratégie de
groupe remplace la stratégie de l’ordinateur local. Ainsi, le paramètre de stratégie de groupe s’applique à tous
les utilisateurs, y compris les utilisateurs locaux.
IMPORTANT
Prenons le cas de figure suivant. Vous pouvez configurer un profil sur un serveur membre. Le profil inclut certains
paramètres importants. Dans ce scénario, si vous appliquez le chemin d’accès Définir le profil itinérant pour tous les
utilisateurs qui se connectent à ce paramètre de stratégie de groupe d’ordinateur, vous perdez votre profil actuel. En
outre, un profil temporaire par défaut vous est affecté.
Ce comportement se produit car le paramètre de stratégie de groupe définit un profil d’itinérance pour tous les
utilisateurs, même si les utilisateurs sont locaux sur le serveur membre. Dans le Registre Windows, une valeur
de Registre nommée CentralProfile dans la sous-clé de Registre suivante est utilisée pour définir le chemin
d’accès de partage du profil itinérant mentionné dans la stratégie de groupe pour les utilisateurs locaux :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<userSID>\CentralProfile
NOTE
<userSID>L’espace réservé spécifie l’identificateur de sécurité (SID) de l’utilisateur.
Vous êtes donc affecté à un profil temporaire par défaut, car vous n’avez pas accès au partage distant.
Les paramètres de stratégie de profil itinérant suivants sont actuellement disponibles dans Windows Server :
Définir le chemin d’accès pour le profil utilisateur itinérant TS
Définir le chemin d’accès du profil itinérant pour tous les utilisateurs qui se connectent à cet
ordinateur
Définir le chemin d’accès pour le profil utilisateur itinérant TS
Le paramètre Définir le chemin d’accès pour la stratégie de groupe profil utilisateur itinérantE TS vous permet
de spécifier le chemin d’accès réseau utilisé par les services Terminal Services pour les profils utilisateur
itinérants.
Par défaut, les services Terminal Server stockent tous les profils utilisateur localement sur le serveur Terminal
Server. Vous pouvez utiliser le paramètre Définir le chemin d’accès pour la stratégie de groupe profil utilisateur
itinérantE TS pour spécifier un partage réseau dans lequel les profils utilisateur peuvent être stockés de
manière centralisée. Lorsque les profils sont stockés de manière centralisée, les utilisateurs peuvent accéder au
même profil pour les sessions sur tous les serveurs terminal configurés pour utiliser le partage réseau pour les
profils utilisateur.
NOTE
Les profils utilisateur itinérants activés par le paramètre Définir le chemin d’accès pour le paramètre de stratégie de
groupe Profil utilisateur itinérant TS s’appliquent uniquement aux connexions des services Terminal Services. Il se peut
également que vous Windows profil utilisateur itinérant configuré. Le profil utilisateur itinérant des services Terminal
Services est toujours prioritaire dans une session des services Terminal Services.
Si vous configurez le chemin d’accès De définition pour le paramètre de stratégie de groupe profil utilisateur itinérant
TS, chaque utilisateur qui se connecte à l’aide d’une session terminal utilise le chemin d’accès spécifié en tant
qu’emplacement de profil itinérant.
Définir le chemin d’accès du profil itinérant pour tous les utilisateurs qui se connectent à cet ordinateur
Pour utiliser le chemin d’accès définir le profil itinérant pour tous les utilisateurs qui se connectent à ce
paramètre de stratégie de groupe d’ordinateur, tapez le chemin d’accès du partage réseau sous la forme
suivante :
\\Computername \ Sharename \
Si vous activez le chemin d’accès définir le profil itinérant pour tous les utilisateurs qui se connectent à ce
paramètre de stratégie de groupe d’ordinateur, tous les utilisateurs qui se connectent à l’ordinateur utilisent le
chemin d’accès de profil itinérant spécifié dans le paramètre de stratégie de groupe. Ce comportement est
inhérent au produit.
NOTE
Vous devez vous assurer que vous avez bien définie la sécurité appropriée sur le dossier pour que tous les
utilisateurs accèdent au profil.
Si vous utilisez un compte d’utilisateur local, le chemin d’accès du profil peut échouer en raison d’un manque
d’autorisations.
Il existe quatre façons de configurer un profil d’itinérance pour un utilisateur. Windows lit la configuration de profil
dans l’ordre suivant et Windows utilise le premier paramètre configuré qu’il lit :
Chemin d’accès de profil d’itinérance des services Terminal Services spécifié par la stratégie des services Terminal
Services
Chemin d’accès de profil itinérant des services Terminal Services spécifié par l’objet utilisateur
Un chemin d’accès de profil d’itinérance par ordinateur spécifié dans le chemin d’accès Définir le profil itinérant
pour tous les utilisateurs qui se connectent à ce paramètre de stratégie de groupe d’ordinateur
Chemin d’accès de profil itinérant par utilisateur spécifié dans l’objet utilisateur
Si vous configurez le chemin d’accès de profil d’itinérance Définir pour tous les utilisateurs qui se connectent à ce
paramètre de stratégie de groupe d’ordinateur, chaque utilisateur qui se connecte au serveur membre utilise le
chemin d’accès spécifié en tant qu’emplacement de profil itinérant.
Un paramètre de stratégie de groupe n’est pas
disponible dans la liste des paramètres de stratégie
de sécurité
Cet article décrit un problème dans lequel le paramètre de stratégie de groupe « Objets système : propriétaire
par défaut pour les objets créés par les membres du groupe Administrateurs » n’est pas disponible dans la liste
des paramètres de stratégie de sécurité.
Symptômes
Lorsque vous essayez d’accéder au paramètre de stratégie de groupe « Objets système : propriétaire par défaut
pour les objets créés par les membres du groupe Administrateurs » sur un ordinateur exécutant Windows Vista
ou une nouvelle génération, ce paramètre n’est pas disponible dans la liste des paramètres de stratégie de
sécurité.
Lorsque le paramètre est présent dans votre stratégie de groupe de sécurité, il est ignoré par Windows Vista et
les membres de domaine plus nouveaux.
Cause
Windows Vista, Windows 7, Windows Server 2008 et Windows Server 2008 R2 ne sont plus en charge.
Lorsqu’il est activé, le contrôle de compte d’utilisateur (UAC) garantit que le compte d’utilisateur est utilisé
comme propriétaire pour tous les objets créés localement. Pour l’accès à distance, le groupe des administrateurs
sera utilisé, il n’y a pas de jeton restreint pour les sessions réseau.
Étant donné que la prise en charge du paramètre a été supprimée, le paramètre de stratégie de sécurité système
« Objets système : propriétaire par défaut des objets créés par les membres du groupe Administrateurs » n’est
plus disponible dans l’interface utilisateur des modèles de sécurité.
Résolution
Vous pouvez ajouter le paramètre de stratégie de groupe « Objets système : propriétaire par défaut pour les
objets créés par les membres du groupe Administrateurs » à l’interface utilisateur des modèles de sécurité.
Conseil : cette procédure ne fera PAS en sorte Windows Vista et les plus nouveaux respectent le paramètre
comme Windows XP et Windows Server 2003.
Pour pouvoir créer ce paramètre de stratégie de groupe pour certains ordinateurs exécutant Windows XP ou
Windows Server 2003, suivez ces étapes sur un ordinateur exécutant Windows Server 2008 :
1. Connectez-vous en tant qu’administrateur local pour configurer le paramètre de stratégie de groupe.
2. Effectuer une copie de sauvegarde du fichier c:\windows\inf\Sceregvl.inf.
3. Prenez possession de ce fichier et donnez au groupe Administrateurs des droits d’utilisateur d’accès total.
NOTE
Ce fichier appartient au groupe TrustedInstaller. Par conséquent, les administrateurs ont uniquement des droits
d’accès en lecture seule.
a. Cliquez avec le bouton droit sur le fichier c:\windows\inf\Sceregvl.inf, puis cliquez sur Propriétés.
b. Cliquez sur l’onglet Sécurité .
c. Cliquez sur Avancé .
d. Cliquez sur l’onglet Propriétaire.
e. Cliquez sur Modifier .
f. Sous Modifier le propriétaire, cliquez sur le groupe Administrateurs, puis cliquez sur OK.
g. Cliquez sur OK à trois reprises.
4. Pour accorder au groupe Administrateurs des droits d’utilisateur d’accès total au fichier, suivez ces étapes.
NOTE
Après avoir donné au groupe Administrateurs des droits d’utilisateur d’accès total, vous pouvez modifier et
enregistrer les modifications apportées au fichier.
c. Cliquez sur Modifier .
d. Sous Noms de groupes ou d’utilisateurs, cliquez sur le groupe Administrateurs.
e. Sous Autorisations pour les administrateurs, cliquez pour cocher la case Autoriser le contrôle
total, puis cliquez sur OK.
f. Cliquez sur OK pour fermer la boîte de dialogue Propriétés Sceregvl.inf.
5. Ouvrez et modifiez le fichier c:\windows\inf\Sceregvl.inf à l’aide Bloc-notes.
6. Copiez le texte suivant qui doit tous se faire sur une seule ligne :
MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\nodefaultadminowner,3,"System objects: Default
owner for objects created by members of the Administrators group »,3,0| Groupe Administrateurs,1|
Créateur d’objet
7. Collez le texte juste après la ligne suivante dans le fichier :
(MACHINE\System\CurrentControlSet\Control\Lsa\SCENoApplyLegacyAuditPolicy,4,%SCENoAp
plyLegacyAuditPolicy%,0)
8. Enregistrez les modifications apportées au fichier, puis quittez Bloc-notes.
9. Réinitialisez la propriété et les autorisations du fichier c:\windows\inf\Sceregvl.inf aux paramètres par
défaut. Pour cela, procédez comme suit :
c. Cliquez sur Avancé .
d. Cliquez sur l’onglet Propriétaire.
e. Cliquez sur Modifier .
f. Cliquez sur Autres utilisateurs ou groupes.
g. Cliquez sur Emplacements .
h. Sous Emplacements, cliquez sur le nom de votre ordinateur local, puis cliquez sur OK.
i. Dans la fenêtre Sélectionner des utilisateurs ou un groupe, tapez NT SERVICE\TrustedInstaller sous
Entrez le nom de l’objet à sélectionner, puis cliquez sur OK .
j. Dans la fenêtre Paramètres sécurité avancée pour Sceregvl.inf, cliquez sur le compte
TrustedInstaller sous Modifier le propriétaire, puis cliquez sur OK .
k. Cliquez sur OK à trois reprises.
10. Réinitialisez les autorisations d’accès au groupe Administrateurs pour le fichier
c:\windows\inf\Sceregvl.inf en lecture seule & exécuter et lire . Pour cela, procédez comme suit :
c. Cliquez sur Modifier .
d. Sous Noms de groupes ou d’utilisateurs, cliquez sur le groupe Administrateurs.
e. Sous Autorisations pour les administrateurs, cliquez pour effacer toutes les cases à cocher à
l’exception de la case à cocher & exécuter la case à cocher Et la case à cocher Lecture, puis cliquez sur
OK.
f. Cliquez sur OK pour fermer la boîte de dialogue Propriétés Sceregvl.inf.
11. Réenregistrement de l’extension côté client pour le fichier de stratégie Scecli.dll groupe. Pour ce faire,
ouvrez une invite de commandes avec élévation de scecli.dll cliquez sur OK.
12. Pour appliquer le paramètre de stratégie de groupe « Objets système : propriétaire par défaut pour les
objets créés par les membres du groupe Administrateurs » dans les paramètres de stratégie de sécurité
locale, suivez ces étapes.
NOTE
Si l’ordinateur est un contrôleur de domaine, utilisez le logiciel en snap-in « Stratégie de sécurité du contrôleur de domaine
».
1. Cliquez sur Démarrer, sur Panneau de contrôle, sur Outils d’administration, puis sur Stratégie de
sécurité locale.
2. Déplacez-vous vers l’emplacement Paramètres\Stratégies locales\Options de sécurité.
3. Dans le volet droit de la fenêtre, cliquez avec le bouton droit sur le paramètre de stratégie de groupe « Objets
système : propriétaire par défaut des objets créés par les membres du groupe Administrateurs », puis cliquez
sur Propriétés.
4. Dans la zone de la zone de baisse, cliquez sur Créateur d’objet, puis sur OK.
5. Vous pouvez recevoir un avertissement dans une Sécurité Windows message. Lisez l’avertissement, puis
cliquez sur Oui .
Échec d’AuthZ avec une erreur d’accès refusé
lorsqu’une application vérifie l’accès dans Windows
Server
Cet article fournit une solution à un problème dans lequel AuthZ échoue avec une erreur d’accès refusé
lorsqu’une application vérifie l’accès dans Windows Server.
Symptômes
Vous travaillez dans un environnement Active Directory basé sur Windows Server 2008 R2 ou une version
ultérieure.
Vous exécutez une application qui utilise l’interface d’autorisation (AuthZ). Ces applications incluent Microsoft
Exchange 2016 et Microsoft Exchange 2013.
Dans ce scénario, lorsque l’application tente de vérifier l’accès, AuthZ échoue et renvoie un message d’erreur
Accès refusé.
Cause
Ce problème se produit car la stratégie d’accès réseau : restreindre les clients autorisés à effectuer des
appels distants à la stratégie SAM est activée. La stratégie contrôle les utilisateurs qui peuvent éumer les
utilisateurs et les groupes dans la base de données SAM (Security Accounts Manager) locale et dans Active
Directory.
Cette stratégie est introduite après l’installation des versions Windows ou Windows mises à jour suivantes :
Windows 10 version 1607 et versions ultérieures
Windows 10 version 1511 avec la base de 4103198 installée
Windows 10 version 1507 avec la base de 4012606 installée
Windows 8.1'installation d'4102219 kb
Windows 7 avec la mise à 4012218 kb
Windows Server 2016 RS1 et versions ultérieures
Windows Server 2012 R2 avec la 4012219 kb installée
Windows Server 2012'installation d'4012220 kb
Windows Server 2008 R2 avec la mise à 4012218 kb
Noms de stratégie et de Registre

NOM DESC RIP T IO N
Nom de la stratégie Accès réseau : restreindre les clients autorisés à

effectuer des appels distants à SAM
Emplacement Configuration de l’ordinateur \ \ Windows Paramètres

Security Paramètres \ Local PoliciesSecurity \ Options
Sous-clé de Registre HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RestrictRemoteSam

NOM DESC RIP T IO N
Type de registre REG_SZ
Valeur de Registre Chaîne qui contient le SDDL du descripteur de sécurité à

déployer.
Lorsque vous définissez la stratégie à l’aide des outils d’administration Windows Server 2016, la valeur par
défaut est d’autoriser uniquement les administrateurs à accéder à cette interface.
L’erreur mentionnée dans la section « Symptômes » se produit si les conditions suivantes sont vraies :
La stratégie est activée sur les contrôleurs de domaine.
Le compte du serveur qui exécute Exchange Server n’est pas autorisé à utiliser l’interface.
Résolution
Méthode 1 : mettre à jour la stratégie pour autoriser l’accès
Dans le groupe, les serveurs qui doivent accéder à l’interface sont ajoutés en tant que membres.
Par exemple, le groupe universel « Exchange Serveurs » requiert cet accès.
Si l’application ne contient pas de groupe contenant les comptes requis, vous de devez peut-être créer et gérer
ce groupe. Il s’agit de la solution recommandée, car elle permet d’accéder à un groupe spécifique à la tâche.
Méthode 2 : désactiver la stratégie
Supprimez l’entrée de Registre RestrictRemoteSAM ou supprimez la stratégie.
NOTE
Sur les contrôleurs de domaine, vous pouvez définir des autorisations par objet pour contrôler la visibilité des comptes.
Ces autorisations sont honorées par les appels RPC SAM distants. Vous ne pouvez pas le faire pour les comptes de
membres ou d’ordinateurs autonomes.
Pour plus d’informations, consultez l’article suivant :
Accès réseau : restreindre les clients autorisés à effectuer des appels distants à SAM
Exemple de problème dans Exchange Server
Vous exécutez Active Directory avec Windows Server 2008 R2 ou une version ultérieure.
Vous exécutez Microsoft Exchange 2016 ou Microsoft Exchange 2013 en tant que plateforme de
collaboration par courrier électronique.
NOTE
Bien que cet exemple spécifie Exchange Server, ce problème s’applique de la même manière aux autres applications qui
utilisent AuthZ de cette manière.
Dans ce scénario, la génération du carnet d’adresses en mode hors connexion sur le serveur qui exécute
Exchange Server 2016 échoue.
En outre, vous voyez une entrée pour l’événement 17004 (source : fournisseur d’assistants de boîte aux lettres
MSExchange) qui ressemble à ce qui suit. Cette entrée est enregistrée dans le journal des applications sur le
serveur sur lequel la boîte aux lettres d’arbitrage « SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} »
utilisée pour générer le carnet d’adresses en carnet d’adresses est montée.
Échec de la génération du carnet d’adresses\ en mode hors connexion par défaut.

Dn : CN=Carnet d’adresses en mode hors connexion par défaut,CN=Listes d’adresses en mode hors
connexion,CN=Listes d’adresses
Container,CN=Companyname,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=company,DC=com ObjectGuid: 543b7f18-2750-4969-9afd-
e333a0542406
Statistiques :
S:Exp=Microsoft. Exchange. Security.Authorization.AuthzException: AuthzInitializeContextFromSid failed for
User SID: S-1-5-21-.... ---> System.ComponentModel.Win32Exception: Access is denied
--- fin de la trace de pile des exceptions internes ---
at
Microsoft. Exchange.
Security.Authorization.ClientSecurityContext.InitializeContextFromSecurityAccessToken(AuthzFlags flags)
chez Microsoft. Exchange. Security.Authorization.ClientSecurityContext.. ctor(indicateurs
ISecurityAccessToken securityAccessToken, AuthzFlags)
chez Microsoft. Exchange. MailboxAssistants.Assistants.OABGenerator.PropertyManager..
ctor(OfflineAddressBook offlineAddressBook, SecurityIdentifier userSid, String userDomain, Boolean
habEnabled, Boolean ordinalSortedMultivaluedProperties, Int32 httpHomeMdbFixRate, IOABLogger logger)
chez Microsoft. Exchange. MailboxAssistants.Assistants.OABGenerator.OABGenerator.Initialize()
chez Microsoft. Exchange. MailboxAssistants.Assistants.OABGenerator.OABGeneratorAssistant.
BeginProcessingOAB(AssistantTaskContext assistantTaskContext)
<>c__DisplayClass12.<SafeExecuteOabTask> b__e()
chez Microsoft. Exchange. Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func2` filterDelegate,
Action1` catchDelegate)
chez Microsoft. Exchange.
MailboxAssistants.Assistants.OABGenerator.OABGeneratorAssistant.SafeExecuteOabTask(OABGeneratorTask
Context context)
<>c__DisplayClassc.<ProcessAssistantStep> b__9()
chez Microsoft. Exchange. Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func2` filterDelegate,
Action1` catchDelegate)
Lorsque le carnet d’adresses en mode hors connexion est généré, Exchange vérifie si le Mailbox-Assistant est
autorisé à exécuter la tâche. La boîte aux lettres système SystemMailbox{bb558c35-97f1-4cb9-8ff7-
d53741dc928c} est un compte d’utilisateur désactivé dans le conteneur d’utilisateurs du domaine racine de la
forêt. Exchange utilise le moteur AuthZ de Windows pour cette tâche.
Lorsque vous examinez le suivi réseau de ce que fait le serveur qui exécute Exchange Server, vous remarquez
l’échec d’une demande Kerberos S4U qui ressemble à ce qui suit :
KerberosV5 10.10.10.11 16268 10.10.10.10 Kerberos(88) KRB_TGS_REQ, Realm: AND. CORP, Sname: XXXXX
PADataType PA-FOR-USER (129) 12408 48 Int64
UserRealm AND 296 56 String
UserName SM_0ddc5cc213b943a5b 16 280 KerberosV5.PrincipalName
-> Cela vous indique qu’AuthZ tente Kerberos S4U.
2017-10-27T16:34:52.1334577 0,0041316 10772 15016 KerberosV5 10.10.10.10 Kerberos(88) 10.10.10.11
16268 KRB_ERROR, KDC_ERR_CLIENT_REVOKED : les informations d’identification des clients ont été
révoquées, status:
STATUS_ACCOUNT_DISABLED
-> Cela est excpecté car le compte de boîte aux lettres système est désactivé.
AuthZ tente de récupérer à partir de cet échec en interrogeant l’attribut tokenGroupsGlobalAndUniversal de

la boîte aux lettres système, puis en continuant à réexer les groupes Domain-Local. La session LDAP est chiffrée.
Par conséquent, vous ne pouvez pas voir le résultat dans un suivi réseau.
L’étape suivante consiste à récupérer les groupes Domain-Local de données. AuthZ utilise SAM RPC pour
récupérer ces appartenances de groupe. Lorsque le programme se connecte au contrôleur de domaine, vous
recevez une notification d’échec semblable à ce qui suit :
12035 SAMR 10.10.10.11 6457 10.10.10.16 SMB(445) _SamrConnect5Request{ServerName=\\

Cont-DC1.company.com
,DesiredAccess=32,InVersion=1,InRevisionInfo=SAMPR_REVISION_INFO{V1=SAMPR_REVISION_INFO_V1{
Revision=3,SupportedFeatures=0}}}
FileId Persistent = 0x0000002800008761 , Volatile = 0x0000002800000005 576 128 SMB2. SMB2Fileid
Cette erreur échoue et renvoie le message suivant :
12036 MSRPCE 0 10.10.10.16 SMB(445) 10.10.10.11 6457 RpcconnFaultHdrT, Call: 0x00000002, Context:
0x0001, Status: ERROR_ACCESS_DENIED , Cancels: 0x00
SMB2 0 10.10.10.16 SMB(445) 10.10.10.11 6457 IoctlResponse, Status: Success, FileName:
samr@# 0x0000002800008761 , CtlCode : FSCTL_PIPE_TRANSCEIVE
Dans le journal des événements système du contrôleur de domaine, l’événement 16969 est consigné, comme
suit :

Source : Microsoft-Windows-Directory-Services-SAM
Description :
8 appels distants à la base de données SAM ont été refusés au cours des 900 dernières secondes.
Pour plus d’informations, voir https://go.microsoft.com/fwlink/?LinkId=787651.
Si la limitation est désactivée, vous verrez un événement 16965 pour chaque incident de refus d’accès avec les
informations client.
Impossible de créer un DSN à l’aide des préférences
de stratégie de groupe, erreur non spécifiée
0x80004005
Cet article fournit de l’aide pour corriger l’erreur 0x80004005 qui se produit lorsque vous configurez un nom de
source de données (DSN) à l’aide des préférences de stratégie de groupe (GPP).
Symptômes
Les tentatives de configuration d’un DSN à l’aide de GPP peuvent entraîner des événements d’erreur semblables
à ce qui suit :
Source : DataSources de stratégie de groupe
Description : l’élément <Preference Name> de préférence de l’ordinateur dans <GPO Name> le . L’objet de
stratégie de groupe ne s’est pas appliqué car il a échoué avec le code d'0x80004005'erreur non spécifiée.
Cette erreur a été supprimée.
Si la journalisation du débogage côté client est activée, les messages d’erreur suivants peuvent être enregistrés
dans le journal de débogage :
<DateTime> [pid=0x70,tid=0x91c] Paires mot clé-valeur non valide [ hr = 0x80004005 " Erreur non
spécifiée " ]
<DateTime> [pid=0x70,tid=0x91c] createDsn [ hr = 0x80004005 « Unspecified error » ]
<DateTime> [pid=0x70,tid=0x91c] Propriétés gérées. [ hr = 0x80004005 « Unspecified error » ]
Pour activer la journalisation du débogage GPP, activez le paramètre de stratégie approprié ci-dessous :
Configuration ordinateur\Stratégies\Modèles d’administration\Système\Stratégie de groupe\Journalisation et
suivi\Traitement de la stratégie de source de données
Windows Ser ver 2008 R2, Windows 7
suivi\Configurer la journalisation et le suivi des préférences des sources de données
Dans la section Journalisation des événements, sélectionnez Informations, Aver tissements et Erreurs.
Le suivi doit être sur « On ».
Les emplacements par défaut du fichier journal sont répertoriés ci-dessous. L’emplacement et le nom du fichier
journal sont configurables.
Windows Ser ver 2003, Windows XP
%SystemDrive%\Documents and Paramètres\All Users\Application
Data\GroupPolicy\Preference\Trace\Computer.log
Windows Ser ver 2008 R2, Windows 7, Windows Ser ver 2008, Windows Vista
%SystemDrive%\ProgramData\GroupPolicy\Preference\Trace\Computer.log
Cause
La condition d’erreur se produit si vous tentez de configurer le nom d’utilisateur et le mot de passe pour la
stratégie DSN à l’aide de GPP. Le nom d’utilisateur et le mot de passe ne sont pas des mots clés valides lors de la
configuration SQL Server DSN. Pour plus d’informations sur les paires SQL Server mot clé/valeur spécifiques
pour les chaînes d’attributs de configuration de source de données, visitez ce site WebMicrosoft.
Résolution
Lors de la configuration SQL connexions, la seule façon de rendre la connexion transparente pour l’utilisateur
consiste à définir Trusted_Connection sur Oui . Dans le cas contraire, l’utilisateur sera invité à entrer ses
informations d’identification lors de la tentative de connexion. Vous devez également vous assurer que les
attributs non répertoriés dans le lien MSDN ci-dessus, y compris le nom d’utilisateur et le mot de passe, restent
vides (non configurés) dans la stratégie lors de la configuration SQL connexions.
Événement 1202 avec état 0x534 connecté à
Windows de domaine Server 2008 R2 après
modification de la stratégie de sécurité
Cet article fournit une solution à un événement connecté aux contrôleurs de domaine après la modification de la
stratégie de sécurité.
Symptômes
Le journal des applications sur les contrôleurs de domaine Windows Server 2008 R2 contient l’ID d’événement
1202 avec le code d’état « 0x534 : aucun mappage entre les noms de comptes et les ID de sécurité n’a été
effectué » chaque fois que la stratégie de sécurité est appliquée. La partie pertinente de l’ID d’événement 1202
est indiquée ci-dessous :

Source : SceCli
Date : MM/JD/AAA HH:MM:SS AM | PM
Utilisateur : N/A
Ordinateur : <computer name>
Description :
Les stratégies de sécurité ont été propagées avec un avertissement. 0x534 : aucun mappage entre les noms
de compte et les ID de sécurité n’a été effectué.
L’aide avancée pour ce problème est disponible sur https://support.microsoft.com . Requête de « dépannage
des événements 1202 ».
Une erreur 0x534 se produit lorsqu’un compte d’utilisateur dans un ou plusieurs objets de stratégie de
groupe n’a pas pu être résolu en SID. Cette erreur est peut-être due à un compte d’utilisateur mal type ou
supprimé référencé dans la branche Droits des utilisateurs ou Groupes restreints d’un GPO. Pour résoudre
cet événement, contactez un administrateur du domaine pour effectuer les actions suivantes :
The WINLOGON. LOG contient le texte suivant :
...
Configurez S-1-1-0.
Configurez S-1-5-11.
Configurez S-1-5-32-554.
Configurez S-1-5-9.
Configurez WdiServiceHost.
Erreur 1332 : aucun mappage entre les noms de compte et les ID de sécurité n’a été effectué.
Impossible de trouver WdiServiceHost.
Configurez S-1-5-21-2125830507-553053660-2246957542-519.
ajoutez SeTimeZonePrivilege.
La configuration des droits utilisateur s’est terminée avec une ou plusieurs erreurs. ...
Par défaut, GPTMPL. La stratégie INF dans la stratégie des contrôleurs de domaine par défaut ressemble à ceci :
SeSystemProfilePrivilege = S-1-5-80-3139157870-2983391045-3678747466-658725712-1809340420, S-
1-5-32-544
Une fois qu’un paramètre de sécurité non lié est modifié dans la stratégie des contrôleurs de domaine par
défaut, l’entrée dans stratégie des contrôleurs de domaine par défaut SeSystemProfilePrivilege apparaît comme
suit :
SeSystemProfilePrivilege = *S-1-5-32-544,WdiServiceHost
Pour plus d’informations, voir les événements SceCli 1202 enregistréschaque fois que les paramètres de
stratégie de groupe de l’ordinateur sont actualisé sur un ordinateur exécutant Windows Server 2008 R2 ou
Windows 7.
Cause
Lors de la modification d’un paramètre de sécurité dans la stratégie des contrôleurs de domaine par défaut à
l’aide de la Console de gestion des stratégies de groupe (GPMC) à partir de la console d’un contrôleur de
domaine Windows Server 2008 R2, gpMC traduit à tort le SID du compte Wdiservice dans la stratégie en un
nom d’utilisateur qui n’est pas reconnu par les ordinateurs locaux sur lequel la stratégie est appliquée. This issue
also occurs when a Windows 7 or Windows Server 2008 R2 member computer modifies any security settings in
the Default Domain Controllers Policy on a Windows Server 2008 R2 domain controller.
En tant que solution de contournement temporaire, modifiez manuellement le GPTMPL. Fichier INF en ajoutant
le préfixe du ser vice \ NT devant le nom du compte wdiser vicehost pour l’utilisateur des performances du
système de profil directement dans la stratégie des contrôleurs de domaine par défaut. Ce qui doit être fait
chaque fois qu’un paramètre de sécurité dans la stratégie des contrôleurs de domaine par défaut est administré
avec gpmc.
Cette étape empêche l’enregistrement de l’événement 1202 jusqu’à la prochaine modification de la stratégie de
sécurité dans la stratégie des contrôleurs de domaine par défaut par les versions de système d’exploitation
pertinentes.
1. Ouvrez GPTTMPL. Fichier INF pour la stratégie de contrôleurs de domaine par défaut d’un contrôleur de
domaine qui journalisation l’ID d’événement 1202. Chemin d’accès au GPTTMPL. Fichier INF lorsque
SYSVOL se trouve sous %SystemRoot% est :
%SystemRoot%\Sysvol\domain\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows
NT\SecEdit\GPTTMPL.INF
2. Recherchez SeSystemProfilePrivilege l’entrée dans GPTTMPL. INF et modifiez-le comme suit :

Before: SeSystemProfilePrivilege = *S-1-5-32-544,WdiServiceHost
After: SeSystemProfilePrivilege = *S-1-5-32-544,nt service\WdiServiceHost
NOTE
Ser vice NT \ doit apparaître après le délimiteur « , ». Ne préfixez pas NT Ser vice \ avec le caractère « * ».
3. Enregistrez les modifications dans GPTTMPL.INF.

4. À partir d’une invite de commandes sur la console du contrôleur de domaine dont GPTTMPL. Le fichier
INF a été modifié à l’étape 1, tapez Gpupdate /force.
5. Affichez le journal des applications pour voir si un ID d’événement 1202 avec code d'0x534 a été
enregistré. Si c’est le cas, examinez WINLOGON. LOG pour voir si l’événement a été provoqué par le
principal de sécurité WdiServiceHost.
Dans la stratégie de contrôleurs de domaine par défaut sur un contrôleur de domaine Windows Server 2008 R2,
le SID du compte d’hôte de service de diagnostics (wdiservicehost) se voit accorder l’emplacement où il est
ajouté au sam local de l’ordinateur, choisi par SCE, puis ajouté au SeSystemProfilePrivilege GPTTMPL.INF.
Lorsqu’un paramètre de sécurité est modifié dans la stratégie des contrôleurs de domaine par défaut sur un
contrôleur de domaine Windows Server 2008, un défaut de code entraîne le remplacement du SID du compte
Wdiservicehost par son compte SAM, mais ne parvient pas à ajouter le préfixe de \ ser vice NT requis par
SCECLI pour résoudre le nom du compte. (autrement dit, NT Service\Wdiservicehost).
1. Le problème décrit dans cette stratégie se produit lorsque l’Éditeur de gestion des stratégies de groupe
sur les ordinateurs Windows 7 ou Windows Server 2008 R2 est utilisé pour modifier les paramètres de
sécurité dans la stratégie des contrôleurs de domaine par défaut sur un contrôleur de domaine Windows
Server 2008.
2. Ce problème ne se produit pas lorsque la stratégie de sécurité est modifiée dans des stratégies autres
que la stratégie des contrôleurs de domaine par défaut.
3. Malgré la journalisation de l’ID d’événement 1202 avec des 0x534 de code d’état, ce problème n’empêche
pas les ordinateurs Windows d’appliquer la stratégie de sécurité contenue dans la stratégie des
contrôleurs de domaine par défaut. Toutefois, il n’existe aucun moyen de distinguer un événement faux
positif provoqué par ce problème d’une mauvaise configuration légitime qui empêchera l’application de
la stratégie de sécurité, identifiée par le même ID d’événement 1202 et 0x534 code d’état.
L’ID d’événement 1053 est enregistré lorsque vous
utilisez la commande Gpupdate /force, ou que vous
redémarrez un contrôleur de domaine
Cet article fournit une solution au problème de journal de l’ID d’événement 1053 lorsque vous utilisez la
commande ou que vous redémarrez un Gpupdate /force contrôleur de domaine.
Symptômes
Lorsque vous utilisez la commande sur un contrôleur de domaine Microsoft Windows Server 2003 ou que vous
redémarrez un contrôleur de domaine basé sur Windows Server 2003, le message d’erreur suivant peut être
consigné dans le journal des applications Gpupdate /force :

Source de l’événement : Userenv
Date : Date
Time: Time
Utilisateur : SYSTÈME D’AUTORITÉ NT \
Computer: Computername
Description :
Windows ne peut pas déterminer le nom de l’utilisateur ou de l’ordinateur. (Un espace de stockage
insuffisant est disponible pour effectuer cette opération. ). Le traitement de la stratégie de groupe a été
abandonné. Pour plus d’informations, voir Centre d’aide et de support.
En outre, si vous activez la journalisation USERENV, les entrées suivantes peuvent être enregistrées dans le
fichier Userenv.log :
USERENV(1b4.eb4) <DateTime> MyGetUserName: GetUserNameEx failed with 14.

USERENV(1b4.eb4) MyGetUserName : nouvelle tentative d’appel à <DateTime> GetUserNameEx en 1/2
seconde.
Résolution
IMPORTANT
Pour résoudre ce problème, ajoutez l’entrée de Registre MaxTokenSize et l’entrée de Registre MaxUserPort sur
les contrôleurs de domaine concernés. Pour cela, procédez comme suit :
2. Recherchez, puis cliquez avec le bouton droit sur la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
NOTE
Si la clé Parameters n’est pas disponible, vous devez la créer. Pour créer la clé Parameters, suivez les étapes
suivantes :
1. Cliquez sur la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos
2. Dans le menu Edition , cliquez sur Nouveau , puis sur Clé .
3. Tapez Paramètres, puis appuyez sur Entrée.
3. Cliquez sur la touche Paramètres, cliquez sur Nouveau dans le menu Edition, puis sur Valeur
DWORD.
4. Tapez MaxTokenSize, puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur MaxTokenSize, puis cliquez sur Modifier.
6. Dans la zone Données de la valeur, tapez 65535, cliquez sur Décimal, puis cliquez sur OK .
7. Recherchez, puis cliquez avec le bouton droit sur la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
8. Dans le menu Édition, cliquez sur Nouveau, cliquez sur Valeur DWORD, tapez MaxUserPort, puis
9. Dans la zone de données Valeur, tapez une valeur entre 5 000 et 65 534, cliquez sur Décimal, puis sur
OK .
NOTE
La valeur par défaut de l’entrée de Registre MaxUserPort est 5 000.

Les événements 1101 et 1030 sont enregistrés dans le
journal des applications lors de l’application d’une
Cet article fournit une solution au problème où les événements 1101 et 1030 sont enregistrés dans le journal
des applications lors de l’application d’une stratégie de groupe.
Symptômes
Sur un ordinateur qui exécute Microsoft Windows XP ou une édition plus nouvelle, vous pouvez voir les entrées
d’événement Error suivantes dans le journal des applications : Si vous activez l’environnement utilisateur ou la
journalisation de débogage GPSVC, les entrées suivantes sont enregistrées :
ProcessGPOs : Nom d’utilisateur est : UserOrComputerDN , Domain name is: DomainName

ProcessGPOs : Le contrôleur de domaine est : nom de domaine de domaine du nom de domaine de
domaine de \ \ dc est DomainName
...
EvaluateDeferredOUs: Object OUName cannot be accessed
GetGPOInfo : EvaluateDeferredOUs a échoué. Sortie
NOTE
Dans ces entrées, OUName est l’unité d’organisation parente du compte d’utilisateur ou d’un objet ordinateur.
Cause
Ce problème se produit car le moteur de stratégie de groupe dans Windows XP Professional et les plus
nouveaux n’a pas d’autorisations de lecture sur les attributs suivants des O parent :
distinguishedNanme (utilisé dans le filtre de recherche)
gPLink (demandé en tant que données)
gPOptions (demandé en tant que données)
Si le moteur de stratégie de groupe ne comprend pas ces autorisations, il ne peut pas appliquer les paramètres
de stratégie de groupe.
Dans Microsoft Windows Server 2000, les événements décrits dans la section « Symptômes » ne sont pas
enregistrés. Le moteur de stratégie de groupe Windows Server 2000 ignore ensuite les paramètres de stratégie
de groupe qui sont liés à l’ou. Windows XP a été modifié pour ne pas ignorer cette erreur.
Par défaut, l’accès à toutes les OUS est accordé en fonction d’une entrée de contrôle d’accès dans le descripteur
de sécurité par défaut. Ce descripteur de sécurité fait partie du schéma qui permet au groupe Utilisateurs
authentifiés de lire toutes les propriétés.
Résolution
Pour résoudre ce problème, accordez des autorisations suffisantes pour accéder aux O parent pour tous les
comptes d’utilisateurs et tous les ordinateurs qui appliquent les paramètres de stratégie de groupe via les O.
L’octroi d’autorisations sur l’attribut « distinguishedName » par le biais de l’éditeur ACL vous oblige à modifier la
visibilité de l’attribut dans DSSEC. DAT dans la section « [organizationalUnit] ». Vous devez modifier la ligne «
distinguishedname=7 » en « distinguishedname=0 ».
Lorsque vous redémarrez ensuite l’application affichant aCL Editor, l’attribut doit être visible.
Erreur de stratégie de groupe : « La clé donnée
n’était pas présente dans le dictionnaire »
Cet article fournit une solution à une erreur de stratégie de groupe (la clé donnée n’était pas présente dans le
dictionnaire) qui se produit lorsque vous exécutez l’Assistant Modélisation de stratégie de groupe sur un
nouveau paramètre de stratégie de groupe.
Symptômes
Vous créez un nouveau paramètre de stratégie de groupe et configurez certains éléments de Registre
sous Préférences (utilisateur ou ordinateur). Pour ce faire, utilisez l’Assistant Registre pour ajouter
des clés ou des valeurs au Registre. Par exemple, sous Computer configuration\Preferences\Registry ,
vous cliquez avec le bouton droit, puis sélectionnez Assistant -> Nouveau Registre. Cela ouvre une
interface utilisateur qui vous permet de manipuler des éléments de Registre.
Sur Windows Server 2008 R2 et Windows Server 2008, vous exécutez l’Assistant Modélisation de
stratégie de groupe sur le nouveau paramètre de stratégie de groupe. Dans ce scénario, vous faites face à
l’un des symptômes suivants, en fonction de votre version d’Internet Explorer :
Dans Internet Explorer 8, vous recevez le message d’erreur et le code d’erreur suivants 80131577 : Une
erreur s’est produite lors de la génération du rapport. La clé donnée n’était pas présente dans le
dictionnaire
Dans Internet Explorer 9, l’Assistant s’exécute mais ne signale aucun paramètre de Registre. En outre, la
section Préférences de Registre est vide.
Cause
Il existe un élément de Registre défectueux dans le fichier XML qui est associé aux paramètres de Registre de
Résolution
Pour résoudre ce problème, re-créez la stratégie de groupe et les paramètres de Registre. Toutefois, pendant que
vous utilisez le navigateur du Registre pour sélectionner des valeurs dans une clé de Registre, ne sélectionnez
pas la clé parente avec les valeurs qu’elle int. La clé parente est automatiquement sélectionné. En d’autres mots,
lorsque vous sélectionnez une valeur dans une clé, une coche rouge s’affiche automatiquement dans le dossier
de la clé parente. Il n’est pas nécessaire également de sélectionner la clé parente.
Les stratégies de groupe de redirection de dossiers
et de profils utilisateur ne sont pas appliquées
Cet article permet de résoudre un problème qui empêche les profils utilisateur et les stratégies de redirection de
dossiers de fonctionner dans Microsoft System Center Configuration Manager (SCCM).
Symptômes
Les ordinateurs exécutant Windows 8 versions ultérieures peuvent ne pas appliquer les objets de stratégie de
groupe de redirection de dossiers et de profils utilisateur comme prévu. Ce problème peut se produire si les
ordinateurs sont des clients de domaine et sont gérés par System Center 2012 Configuration Manager Service
Pack 1 (ConfigMgr 2012 SP1) ou une ultérieure.
Resolution
Pour contourner ce problème, désactivez le paramètre d’appareil Activer les données utilisateur et les profils
dans la console Configuration Manager System Center 2012.
Pour plus d’informations, voir Créer des éléments de configuration de profils et de données utilisateur dans
Configuration Manager.
Événements d’erreur de stratégie de groupe
consignés lorsque la variable d’environnement
inconnue est utilisée
Cet article permet d’éviter les événements d’erreur de stratégie de groupe qui sont enregistrés lorsque la
variable d’environnement inconnue est utilisée.
Symptômes
Si vous exécutez une forêt Active Directory et utilisez une stratégie de sécurité de système de fichiers, les
événements suivants peuvent être enregistrés :
Windows Vista, Windows Server 2008, Windows 7 et Windows Server 2008 R2 enregistreront cet
événement dans le journal opérationnel de la stratégie de groupe :
Nom du journal : Microsoft-Windows-GroupPolicy/Operational

Source : Microsoft-Windows-GroupPolicy
Niveau : Error
Mots clés :
Description :
Traitement des extensions de sécurité terminé en 20984 millisecondes.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
...
<EventData>
<Data Name="CSEElaspedTimeInMilliSeconds">20984</Data>
<Data Name="ErrorCode">1252</Data>
<Data Name="CSEExtensionName">Sécurité</Data>
<Data Name="CSEExtensionId">{827D319E-6EAC-11D2-A4EA-00C04F79F83A}</Data>
</EventData>
</Event>
Windows XP et Windows Server 2003 enregistreront cet événement dans le journal des applications :
Catégorie : Aucun
Source : Userenv
Tapez : Erreur
Message : la sécurité de l’extension côté client de la stratégie de groupe n’a pas réussi à enregistrer les
données RSOP (Jeu de stratégie résultant). Recherchez les erreurs signalées précédemment par cette
extension.
Toutes Windows version journalisée enregistreront cet événement dans le journal des applications :
Catégorie : Aucun
Source : SceCli
Message : les stratégies de sécurité ont été propagées avec un avertissement. 0xd : les données ne
sont pas valides.
Selon la configuration réelle de la stratégie, les paramètres des stratégies de sécurité peuvent être
présents ou non. La section Plus d’informations explique les conditions d’échec ou de réussite de la
stratégie (malgré les erreurs).
Cause
Les événements sont consignés car les paramètres de sécurité du système de fichiers d’une stratégie
contiennent une variable d’environnement inconnue sur l’ordinateur client. Pour en savoir plus sur le problème,
activez la journalisation de l’extension côté client de configuration de sécurité :
Résoudre les problèmes des événements SCECLI 1202.
Dans le fichier %windir%\security\logs\winlogon.log, vous verrez une entrée telle que :
Process GP template gpt0000x.inf.

Erreur 13 : les données ne sont pas valides.
Erreur lors de la conversion de %PROGRAMFILES(X86)%\MyApplication.
%PROGRAMFILES(X86)% n’est qu’un exemple. Elle est utilisée lorsque la stratégie est modifiée sur une version
64 bits de Windows et que des paramètres de sécurité sont créés pour le dossier C:\PROGRAM FILES (X86) ou
l’un de ses sous-dossiers.
Le fichier gpt0000x.inf, un fichier texte contenant les paramètres de stratégie, se trouve dans le dossier
%windir%\security\templates\policies. Il contient également l’emplacement de la stratégie dans Active Directory
dans la ligne commençant par GPOPath , ce qui vous permet d’identifier la stratégie qui possède la variable
d’environnement inconnue.
Résolution
Pour éviter le problème, créez une stratégie au même niveau que celle qui reçoit les paramètres référencant la
variable d’environnement manquante. Ensuite, utilisez un filtre WMI pour autoriser la stratégie à s’appliquer
uniquement aux ordinateurs dont la variable d’environnement est définie.
Par exemple, le filtre WMI pour %PROGRAMFILES(X86)% serait :
Select * from Win32_Envrionment where Name = 'PROGRAMFILES(X86)'
Cette section explique pourquoi, dans certains cas, les paramètres de stratégie s’appliquent correctement, mais
dans d’autres cas, ils ne s’appliquent pas.
La stratégie de groupe de sécurité est pilotée par la bibliothèque Userenv.dll en cours d’exécution dans le
processus Winlogon.exe ou sur Windows Vista et ultérieur, le service de stratégie de groupe (GPSvc). Il s’agit du
composant qui obtient la liste des stratégies attribuées à l’ordinateur et filtre ceux qui ne s’appliquent pas. Ils
peuvent être filtrés en fonction des autorisations sur la stratégie ou un filtre WMI.
Userenv/GPSvc trie ensuite les stratégies en fonction de leur priorité. La première stratégie appliquée est celle
qui a la priorité la plus faible, la dernière est celle qui a la priorité la plus élevée. Pour la stratégie de sécurité,
Userenv/GPSvc appelle l’extension côté client de stratégie de sécurité (SCECLI) avec le fichier de paramètres de
stratégie téléchargé à partir de SYSVOL.
SCECLI possède deux phases. Dans la première phase, elle prend les paramètres qui lui sont transmis et les
insécure dans la base de données de sécurité. La deuxième phase consiste à appliquer ces paramètres au
système, par exemple, définir des droits d’utilisateur, des options de sécurité ou définir des descripteurs de
sécurité sur le Registre et les fichiers.
La première phase est active jusqu’à ce que la dernière stratégie soit traitée. L’appel de Userenv/GPSvc à SCECLI
pour la dernière stratégie est un cas particulier. Lorsque l’appel est effectué, la première phase est toujours
active et les paramètres de la dernière stratégie sont lus dans la base de données de sécurité comme avec toutes
les autres stratégies. Mais avant le retour de l’appel, SCECLI voit qu’il s’agit de la dernière stratégie et, dans le
même appel, exécute la deuxième phase.
Les paramètres du Registre et de la stratégie de système de fichiers sont considérés comme coûteux à valider,
SCECLI ne les exécute pas dans le thread appelant en mode premier plan. Pour ces paramètres, Userenv/GPSvc
créerait un thread supplémentaire afin que le traitement puisse se terminer tant que l’utilisateur peut déjà se
logon. Les contrôleurs de domaine sont une exception à cette règle. Ils terminent toujours d’abord toutes les
applications de stratégie de sécurité avant que l’utilisateur puisse s’y logo.
En ce qui concerne les variables d’environnement manquantes, SCECLI lit les paramètres de la première phase et
rencontre une erreur lorsqu’il résout la variable d’environnement sur le chemin d’accès réel. SCECLI ignore
l’entrée et continue d’ajouter des paramètres à la base de données de sécurité, puis retourne une erreur à
Userenv/GPSVC.
Lorsque le problème se produit dans une stratégie à l’exception de la dernière stratégie, Userenv/GPSVC traite
l’erreur comme un problème fatal et abandonne la stratégie de groupe de sécurité. Par conséquent, la deuxième
phase ne se produit jamais. Lorsque le problème se produit dans la dernière stratégie, SCECLI ignore l’erreur et
exécute la deuxième phase. Userenv/GPSVC abandonne toujours l’application de stratégie avec une erreur, mais
en réalité, le traitement de la stratégie a été effectué à ce stade.
La stratégie de groupe avec des filtres WMI peut
être refusée ou ralentir l’accès/démarrage
Cet article fournit une solution à un problème dans lequel la stratégie de groupe avec des filtres WMI peut être
refusée ou entraîner une lenteur d’accès/démarrage.
Symptômes
La stratégie de groupe avec filtre WMI ne s’applique pas. La requête WMI (filtre WMI lié à un GPO) sort du
temps en raison de laquelle l’GPO ne s’applique pas aux ordinateurs, par intermittence.
Les journaux GPSVC indiquent les informations suivantes :
GPSVC(320.af8) <DateTime> FilterCheck : évaluer l’erreur renvoyée. hr=0x80041069

GPSVC(320.af8) ProcessGPO : l’GPO ne passe pas la vérification de filtre et ne <DateTime> sera donc pas
appliqué.
Err pour 0x80041069 donne le résultat suivant :
# pour les 0x80041069 hexadécimales /décimales -2147217303

WBEM_E_TIMED_OUT wbemcli.h
# as an HRESULT: Severity: FAILURE (1), FACILITY_ITF (0x4), Code 0x1069
# pour les 0x1069 hexadécimal 4201
ERROR_WMI_INSTANCE_NOT_FOUND winerror.h
# Le nom d’instance transmis n’a pas été reconnu comme valide par un fournisseur # de données WMI
# 2 correspondances trouvées pour « 0x80041069 »
Cause
Le filtrage WMI prenait du temps lors du traitement. Elle tentait d’éumer tous les noms de domaine comme
requête utilisée :
Select * from Win32_NTDomain where ClientSiteName = "XYZ"
Résolution
Ajoutez un composant de nom de domaine à la requête WMI pour résoudre le problème (avec l’opérateur AND)
:
Select * from Win32_NTDomain where DomainName = "Domain_name" AND ClientSiteName = "XYZ"
Assurez-vous que le correctif logiciel ci-dessous est déjà installé :

Une fois que vous avez appliqué un filtre WMI, l’GPO ne prend pas effet sur un ordinateur client qui exécute
Windows 7 ou Windows Server 2008 R2
Délai d’out pour les requêtes WMI :
Per-Vista = Aucun
Vista et plus = 30 secondes (codé en dur)
Dans l’un des cas, il a été informé que la suppression du filtrage de sécurité personnalisé de l’objet de groupe
(qui a configuré le filtre WMI) a résolu le problème, mais qu’il n’a pas été testé ou vérifié.
L’ID d’événement Netlogon 5719 ou l’événement de
stratégie de groupe 1129 est enregistré lorsque vous
démarrez un membre de domaine
Cet article résout l’ID d’événement Netlogon 5719 ou l’événement de stratégie de groupe 1129 enregistré
lorsque vous démarrez un membre de domaine.
Symptômes
IMPORTANT
Envisagez ce scénario :
Vous avez un ordinateur qui exécute Windows 10 ou Windows Server 2012 R2.
L’ordinateur est joint à un domaine.
L’une de ces conditions est vraie :
Une carte réseau Gigabit est installée sur l’ordinateur.
Vous sécurisation de l’accès réseau à l’aide de la protection d’accès réseau (NAP), de l’authentification
réseau (à l’aide de 802.1 x ) ou d’une autre méthode.
Dans ce scénario, l’événement suivant est consigné dans le journal système lorsque vous démarrez l’ordinateur
dans Windows 8.1 versions antérieures. Dans Windows 10 versions ultérieures, l’événement 5719 n’est plus
enregistré dans cette situation. Les lignes suivantes sont enregistrées dans Netlogon.log à la place :
[CRITICAL] [960] CONTOSO: NlSessionSetup: Session setup: cannot pick trusted DC

[SESSION] [960] No IP addresses present, skipping No DC event log
Une fois ce problème se produit, une adresse IP est attribuée à l’ordinateur :
[SESSION] [960] V6 Winsock Addrs: fe80::5faf:632a:f22c:644a%2 (1) V6WinsockPnpAddresses List used to be

empty.
[SESSION] [960] Winsock Addrs: 10.1.1.80 (1) List used to be empty.
Sur Windows 10 versions ultérieures, vous ne verrez que les événements par composant, en fonction de la
connectivité du contrôleur de domaine (telle que la stratégie de groupe). Les entrées suivantes sont enregistrées
dans le journal de débogage de la stratégie de groupe :
CGPApplicationService::MachinePolicyStartedWaitingOnNetwork.
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Average is 388.
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Current is -1.
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Taking min of 776 and 30000.
Waiting for SamSs with timeout 776
NlaQueryNetSignatures returned 1 networks

NSI Information (Network GUID) : {395DB3C8-CE45-11E5-9739-806E6F6E6963}
NSI Information (CompartmentId) : 1
NSI Information (SiteId) : 134217728
NSI Information (Network Name) :
NlaGetIntranetCapability failed with 0x15
There is no domain compartment
ProcessGPOs(Machine): MyGetUserName failed with 1355.
Opened query for NLA successfully
NlaGetIntranetCapability returned Not Ready error. Consider it as NOT intranet capable.
GPSVC(530.ae0) <DateTime> There is no connectivity

GPSVC(530.8e0) <DateTime> ApplyGroupPolicy: Getting ready to create background thread GPOThread.
La première section indique le calcul du délai d’délai à utiliser pour faire monter le réseau. Il peut être basé sur
des démarrages rapides précédents.
La deuxième section montre que la sensibilisation à l’emplacement réseau (NLA) ne parvient pas à signaler un
réseau de travail dans l’intervalle d’attente autorisé, et que le traitement de démarrage de la stratégie de groupe
échoue. La troisième section montre que le moteur de stratégie de groupe démarre une procédure en arrière-
plan, puis attend une minute après qu’un réseau soit disponible.
Cause
Ce problème peut se produire pour l’une des raisons suivantes :
Le service Netlogon démarre avant que le réseau ne soit prêt. L’initialisation de la pile réseau et de la carte
commence souvent à peu près en même temps. Certaines cartes réseau et commutateurs ont des
vérifications d’arbitrage des liens et d’unicité d’adresse MAC qui prennent plus de temps que le délai
d’attente qui est fixé pour que Netlogon détecte la connectivité réseau.
Les solutions qui vérifient l’état du nouveau membre du réseau retardent la connexion réseau et votre
capacité à accéder aux contrôleurs de domaine. Si vous avez activé une connexion automatique au canal
d’accès direct, cela peut également nécessiter plus de temps que ne le permet Netlogon.
Le processus d’authentification 802.1X retarde les connexions aux contrôleurs de domaine.
Le client subit un délai pour récupérer une adresse IP à partir du serveur DHCP. Elle retarde l’affichage de
l’interface réseau.
La stratégie de groupe dans Windows Vista et les versions ultérieures est écrite pour négocier l’état du réseau
pour qui le NLA est activé. Et il attend un réseau qui dispose d’une connectivité DC. Toutefois, la stratégie de
groupe peut commencer prématurément en raison d’une application de stratégie. Cette situation est
particulièrement vraie lorsque le délai de recherche d’un réseau est alternatif entre les démarrages.
WARNING
Résolution 1
Pour résoudre ce problème, installez le pilote le plus actuel pour la carte réseau Gigabit. Vous pouvez également
activer l’option Por tFast sur les commutateurs réseau.
Résolution 2
Pour résoudre ce problème, utilisez le Registre pour modifier les paramètres associés qui affectent la
connectivité DC. Pour ce faire, utilisez les méthodes suivantes.
Méthode 1
Ajustez les paramètres de pare-feu ou les stratégies IPSEC qui sont modifiés pour autoriser la connectivité DC.
Ces modifications sont apportées lorsque le client reçoit une adresse IP, mais nécessite plus de temps pour
accéder à un contrôleur de domaine, par exemple, après une vérification réussie via Cisco CISCO ou Microsoft
NPS Services.
Méthode 2
Configurez le paramètre de Registre sur une valeur qui dépasse en toute sécurité le temps nécessaire pour
autoriser la Netlogon connectivité DC.
NOTE
Cela n’est efficace que si l’ordinateur dispose déjà d’une adresse IP. Cela s’applique aux scénarios où une solution NAP
place l’ordinateur dans un réseau de mise en quarantaine. Utilisez les paramètres suivants comme instructions.
Sous-clé du Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

Nom de la valeur : ExpectedDialupDelay
La valeur de données est en secondes (valeur par défaut = 0 )
La plage de données est entre 0 et 600 secondes (10 minutes)
Pour plus d’informations, voir Paramètres pour réduire le trafic WAN périodique.
Méthode 3
La pile IP tente de vérifier l’adresse IP à l’aide d’une diffusion ARP. Elle retarde la mise en ligne de l’adresse IP.
Vous pouvez définir l’entrée de Registre ArpRetryCount sur un (1), afin que l’attente pour l’unicité soit raccourcie.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TcpIp\Parameters\
3. Dans le menu Edition, pointez sur Nouveau, puis sélectionnez Valeur DWORD.
4. Tapez ArpRetryCount.
5. Cliquez avec le bouton droit ArpRetryCount sur l’entrée de Registre, puis sélectionnez Modifier.
6. Dans la zone Données de la valeur, tapez 1, puis sélectionnez OK.
NOTE
La plage de données est entre 0 et 3 (3 est la valeur par défaut).

Méthode 4
Réduisez la période de cache négatif Netlogon en modifiant l’entrée de Registre NegativeCachePeriod dans la
sous-clé suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\NegativeCachePeriod
Après avoir fait cette modification, le service Netlogon ne se comporte pas comme si les contrôleurs de
domaine étaient hors connexion pendant 45 secondes. L’événement 5719 est toujours journalisé. Toutefois,
l’événement ne provoque aucun autre problème important. Ce paramètre permet au membre d’essayer les
contrôleurs de domaine plus tôt si le processus a échoué précédemment.
Suggestion : essayez de définir une valeur faible, par exemple trois secondes. Dans les environnements LAN,
vous pouvez utiliser la valeur 0 pour désactiver le cache négatif.
Pour plus d’informations sur ce paramètre, voir Paramètres pour réduire le trafic WAN périodique.
Méthode 5
Configurez le paramètre de Registre sur une valeur qui dépasse en toute sécurité le temps nécessaire pour
autoriser la Kerberos connectivité DC. Utilisez les paramètres suivants comme instructions.
NOTE
Ce paramètre s’applique uniquement Windows XP et Windows Server 2003 ou versions antérieures de ces systèmes.
Windows Vista et Windows Server 2008 et versions ultérieures utilisent une valeur par défaut de 0 . Cette valeur éteint la
fonctionnalité UDP (User Datagram Protocol) pour le client Kerberos.
Sous-clé du Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Nom de la valeur : MaxPacketSize
Par défaut : (dépend de la version du système)
Pour plus d’informations, voir Comment forcer Kerberos àutiliser TCP au lieu d’UDP dans Windows .
Méthode 6
Désactivez l’sense multimédia pour TCP/IP en ajoutant la valeur suivante à la Tcpip sous-clé de Registre :
Sous-clé du Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Nom de la valeur : DisableDHCPMediaSense
Plage de valeurs : Boolean ( 0 =False, 1 =True)
Valeur par défaut : 0 (False)
Pour plus d’informations, voir Comment désactiver la fonctionnalité de détection des médias pour TCP/IP dans
Windows.
Méthode 7
La stratégie de groupe dispose de paramètres de stratégie pour contrôler le délai d’attente pour le traitement de
la stratégie de démarrage :
1. Réseau lan d’entreprise ou WLAN :
Dossier de stratégie : « Configuration ordinateur\Modèles d’administration\Système\Stratégie de

groupe"
Nom de la stratégie : « Spécifier le délai d’attente de traitement de la stratégie de démarrage »
2. LaN externe ou WLAN :
Dossier de stratégie : « Configuration ordinateur\Modèles d’administration\Système\Stratégie de

groupe"
Nom de la stratégie : « Spécifier le temps d’attente de connectivité de l’espace de travail pour le
traitement de la stratégie »
Le temps qu’il faut à Netlogon pour acquérir une adresse IP de travail peut être la base du paramètre. Pour les
scénarios d’accès direct, vous pouvez mesurer le retard typique de votre base d’utilisateurs jusqu’à ce que la
connexion soit établie.
Méthode 8
Si le paramètre de Registre est en place et a une valeur incorrecte de 0xfffffff , supprimez la clé ou modifiez-la à
la valeur prévue de DisabledComponents 0xff .
IMPORTANT
Le protocole Internet version 6 (IPv6) est une partie obligatoire de Windows Vista et des versions ultérieures de Windows.
Nous vous déconseillons de désactiver IPv6 ou ses composants. Si vous le faites, certains Windows composants peuvent
ne pas fonctionner. En outre, le démarrage du système sera retardé de cinq secondes si IPv6 est désactivé de manière
incorrecte en activant le paramètre de Registre sur une valeur de DisabledComponents 0xfffffff . La valeur correcte est
0xff .
Méthode 9
Le comportement peut être dû à une condition de course entre l’initialisation du réseau, la recherche d’un
contrôleur de domaine et le traitement de la stratégie de groupe. Si le réseau n’est pas disponible, un contrôleur
de domaine ne sera pas localisé et le traitement de la stratégie de groupe échouera. Une fois que le système
d’exploitation est chargé et qu’une liaison réseau est négociée et établie, l’actualisation en arrière-plan de la
stratégie de groupe réussit.
Vous pouvez définir une valeur de Registre pour retarder l’application de la stratégie de groupe :
3. Dans le menu Edition, pointez sur Nouveau, puis sélectionnez Valeur DWORD.
4. Tapez GpNetworkStartTimeoutPolicyValue.
5. Cliquez avec le bouton droit GpNetworkStartTimeoutPolicyValue sur l’entrée de Registre, puis sélectionnez
Modifier.
6. Sous Base, sélectionnez Décimal .
9. Si le script de démarrage de la stratégie de groupe ne s’exécute pas, augmentez la valeur de
GpNetworkStartTimeoutPolicyValue l’entrée de Registre.
Si vous pouvez vous connecter au domaine sans problème, vous pouvez ignorer en toute sécurité l’ID
d’événement 5719. Étant donné que le service Netlogon peut démarrer avant que le réseau ne soit prêt, il se
peut que l’ordinateur ne parvient pas à localiser le contrôleur de domaine d’accès. Par conséquent, l’ID
d’événement 5719 est enregistré. Une fois que le réseau est prêt, l’ordinateur tente à nouveau de localiser le
contrôleur de domaine d’accès. Dans ce cas, l’opération doit réussir.
Dans un fichier Netogon.log, les entrées qui ressemblent à l’exemple suivant peuvent être enregistrées :
DateTime [CRITICAL] <domain>: NlDiscoverDc: Cannot find DC. DateTime [CRITICAL] <domain>: NlSessionSetup:
Session setup: cannot pick trusted DC DateTime [MISC] Eventlog: 5719 (1)"<domain>" 0xc000005e ... DateTime
[SESSION] WPNG: NlSetStatusClientSession: Set connection status to c000005e ... DateTime [SESSION]
\Device\NetBT_Tcpip_{4A47AF53-40D3-4F92-ACDF-9B5E82A50E32}: Transport Added (10.0.64.232) -> Getting a
proper IP address takes >15 seconds.
Des erreurs similaires peuvent être signalées par d’autres composants qui nécessitent la connectivité du
contrôleur de domaine pour fonctionner correctement. Par exemple, la stratégie de groupe peut ne pas être
appliquée au démarrage du système. Dans ce cas, les scripts de démarrage ne s’exécutent pas. Les échecs de
stratégie de groupe peuvent être liés à l’échec de Netlogon pour localiser un contrôleur de domaine. Vous
pouvez définir une stratégie de groupe pour qu’elle soit plus réactive à l’arrivée tardive de la connectivité réseau.
Les modifications ne sont pas appliquées lorsque
vous modifiez la stratégie de mot de passe
Cet article permet de résoudre un problème dans lequel les modifications ne sont pas appliquées comme prévu
lorsque vous modifiez la stratégie de mot de passe.
Symptômes
Lorsque vous modifiez la stratégie de mot de passe, les modifications ne sont pas appliquées comme prévu.
Cause
Ce problème peut se produire dans l’un des scénarios suivants :
L’option Bloquer l’héritage des stratégies est activée sur l’unité d’organisation Contrôleurs de domaine.
La stratégie de mot de passe n’est pas définie dans la stratégie de domaine par défaut.
Résolution
Pour résoudre ce problème, désactivez l’option Bloquer l’héritage des stratégies sur l’unité d’organisation
Contrôleurs de domaine :
1. Démarrez le logiciel en ligne Utilisateurs et ordinateurs Active Directory.
2. Cliquez avec le bouton droit sur l’unité d’organisation Contrôleurs de domaine, cliquez sur Propriétés, puis
cliquez pour effacer la case à cocher Bloquer l’héritage des stratégies.
3. Sur les contrôleurs de domaine, exécutez la commande suivante : secedit/refreshpolicy
machine_policy/enforce
Si ce problème se produit parce que vous n’avez pas définie de stratégie de mot de passe dans la stratégie de
domaine par défaut, définissez toutes les stratégies de mot de passe dans la stratégie de domaine par défaut.
Statut
Dans Windows 2000, les stratégies de mot de passe sont en lecture seule au niveau du domaine. La stratégie
doit être appliquée aux contrôleurs de domaine pour que la stratégie soit appliquée. Si vous initiez une
modification de mot de passe pour un mot de passe de domaine à partir de n’importe où dans le domaine, la
modification se produit réellement sur un contrôleur de domaine.
Les paramètres de redirection de dossiers sont
toujours appliqués à partir des paramètres de
stratégie de groupe, même si vous avez activer le
traitement en boucle dans la stratégie de groupe.
Cet article fournit une solution à un problème : les paramètres de redirection de dossiers sont appliqués à partir
des paramètres de stratégie de groupe qui sont déployés sur l’ordinateur de l’utilisateur, même si vous activer le
traitement en boucle dans la stratégie de groupe.
Symptômes
Lorsque vous activer le traitement en boucle dans la stratégie de groupe, vous pouvez remarquer que les
paramètres de redirection de dossiers sont appliqués à partir des paramètres de stratégie de groupe déployés
sur l’ordinateur de l’utilisateur. Tous les paramètres configurés par la stratégie de boucage prennent effet à
l’exception des paramètres de redirection de dossier.
Vous remarquez ce problème uniquement lorsqu’un utilisateur dispose déjà d’un paramètre de stratégie de
groupe pour la redirection de dossiers et que vous essayez d’activer le traitement en boucle sur son ordinateur.
Vous ne remarquez pas ce problème lorsque les utilisateurs ont un paramètre de stratégie de groupe appliqué
pour la redirection de dossiers, qu’ils ont le traitement en boucle en même temps, et que ce traitement en
boucle est en cours d’application pour la première fois.
Cause
Ce problème se produit lorsque vous allumez le traitement en boucle avec le mode Remplacement dans la
stratégie de groupe, mais que vous ne configurez aucun paramètre de redirection de dossier pour cette
stratégie.
Lorsque vous ne configurez aucun paramètre de redirection de dossier, le paramètre par défaut pour les
dossiers de redirection de dossiers, tel que le dossier Mes documents, n’est aucune stratégie d’administration
spécifiée. Ce paramètre ne supprime pas ou ne désaffecte pas la fonctionnalité de redirection de dossiers si elle
est désactivée pour l’utilisateur par un autre paramètre de stratégie de groupe.
Résolution
Pour résoudre ce problème, configurez les paramètres de redirection de dossiers pour le paramètre de stratégie
de groupe.
Par exemple, pour rediriger le dossier Mes documents, suivez les étapes suivantes :
1. Modifiez le paramètre du dossier Mes documents dans la stratégie de bouc de boucle pour rediriger le
dossier de tous les utilisateurs vers le même emplacement.
2. Définissez l’emplacement du dossier de destination comme %LOCALPROFILE%\My Documents .
Le dossier Mes documents pointe alors vers le chemin d’accès du dossier Mes documents du profil local de
l’utilisateur. Vous pouvez activer ou désactiver la fonctionnalité Déplacer le contenu de Mes documents vers un
nouveau paramètre d’emplacement, selon que vous souhaitez déplacer ou non la copie du dossier Mes
documents à partir du partage de serveurs.
NOTE
Lorsque le paramètre Déplacer le contenu de Mes documents vers un nouvel emplacement est allumé, le contenu du
dossier Mes documents est redirigé chaque fois que l’utilisateur passe de l’ordinateur affecté par la stratégie de bouc-
boucle à un autre ordinateur. En 2013, vous évitez ce paramètre.
Les organisations qui utilisent des paramètres de stratégie de groupe de distribution de logiciels et de
redirection de dossiers peuvent ne pas utiliser ces paramètres pour les utilisateurs qui ont des connexions
Internet lentes. Ces organisations peuvent activer le traitement en boucle afin que les utilisateurs utilisent deux
paramètres de stratégie de groupe différents, en fonction de l’ordinateur qu’ils utilisent pour se connecter au
réseau.
Certaines zones de stratégie de groupe sont
manquantes dans l’Éditeur de stratégie de groupe
Cet article fournit une solution à un problème dans lequel certains domaines de stratégie de groupe sont
manquants dans l’Éditeur de stratégie de groupe.
Symptômes
Lorsque vous ouvrez l’outil en ligne MMC Éditeur de stratégie de groupe et que vous vous concentrez sur un
objet de stratégie de groupe local ou un objet de stratégie de groupe basé sur Active Directory, il se peut que
certaines zones de stratégie de groupe qui devraient apparaître soient in trouvées. Ces zones de stratégie
manquantes sont différentes de celles qui sont normalement manquantes lorsque vous vous concentrez sur un
objet de stratégie de groupe local.
Cause
Chaque domaine de fonctionnalité de stratégie est implémenté par une DLL de composant logiciel en snap-in
MMC enregistrée par défaut sur une installation Windows 2000, 2003 ou XP standard. Il peut arriver que ces
DLL ne soient pas enregistrées ou supprimées et, lorsque cela se produit, la fonctionnalité de modification de
stratégie de groupe sous-jacente qu’elles implémentent n’apparaît pas dans l’interface utilisateur de l’éditeur de
Résolution
Pour résoudre ce problème, enregistrez à nouveau la DLL en snap-in MMC appropriée qui implémente la
fonctionnalité manquante en émettant la commande suivante à une invite de commandes Windows suivante
regsvr32 <snap-in DLL name>
Par défaut, toutes les DLLs MMC associées à la stratégie de groupe se trouvent dans %systemroot%\system32.
Les listes suivantes répertorient les DLLs de stratégie de groupe par défaut que vous pouvez ré-inscrire :
Modèles et scripts d’administration : gptext.dll
Redirection de dossier : fde.dll
Maintenance Internet Explorer : ieaksie.dll
Sécurité IP : ipsecsnp.dll
Clé publique et restriction logicielle : certmgr.dll
Services d’installation à distance : rigpsnap.dll
Sécurité : wsecedit.dll
Installation logicielle : appmgr.dll
Lorsque vous vous concentrez sur l’objet de stratégie de groupe local avec le logiciel en snap-in Éditeur de
stratégie de groupe MMC, il est normal que certains domaines de stratégie normalement vus lors de la
modification d’un objet de stratégie de groupe basé sur Active Directory ne soient pas présents. Il s’agit d’un
comportement attendu, car l’GPO local prend uniquement en charge un sous-ensemble des fonctionnalités d’un
GPO basé sur Active Directory. Toutefois, parfois même lorsque vous vous concentrez sur les G GPO basés sur
Active Directory, certains domaines de stratégie qui doivent être présents sont manquants. Dans ce cas, la cause
la plus probable est l’absence d’inscriptions pour les DLL en snap-in MMC qui implémentent cette fonctionnalité,
et en ré-enregistrant la DLL manquante et en redémarré l’Éditeur de stratégie de groupe, le problème peut être
résolu.
ajouter l’entrée de Registre MaxTokenSize à
plusieurs ordinateurs
Cet article explique comment utiliser la stratégie de groupe pour ajouter l’entrée de Registre MaxTokenSize à
plusieurs ordinateurs.
Introduction
Sur un contrôleur de domaine exécutant Windows Server 2003, Windows Server 2008, Windows Server 2008
R2 ou Windows Server 2012, vous pouvez utiliser la stratégie de groupe pour ajouter l’entrée de Registre
suivante à plusieurs ordinateurs :
Clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Entrée : MaxTokenSize
Valeur : 48000
Cet article explique comment le faire, afin que vous pouvez facilement faire passer ce paramètre à tous les
membres de vos domaines. Le processus est différent, selon la version de Windows Server que le contrôleur de
domaine exécute.
NOTE
La valeur maximale autorisée de MaxTokenSize est 65 535 octets. Toutefois, en raison du codage EN BASE64 des jetons de
contexte d’authentification, il est déconseillé de définir l’entrée de Registre maxTokenSize sur une valeur supérieure à 48
000 octets. À partir Windows Server 2012, la valeur par défaut de l’entrée de Registre MaxTokenSize est 48 000 octets.
Comment configurer MaxTokenSize à l’aide de l’objet de stratégie de groupe (GPO ) dans Windows Server
2003
Pour ajouter l’entrée de Registre à plusieurs ordinateurs dans un domaine qui ne Windows Server 2012 pas de
contrôleur de domaine basé sur Windows Server 2012, suivez les étapes suivantes :
1. Créez un fichier de modèle d’administration (ADM) pour l’entrée de Registre MaxTokenSize. Pour ce faire,
a. Démarrez Bloc-notes.
b. Copiez le texte suivant, puis collez-le dans Bloc-notes :
ORDINATEUR DE CLASSE
CATEGORY !) KERB
KEYNAME « SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters »
POLICY !) MaxToken
VALUENAME « MaxTokenSize »
VALUEON NUMERIC 48000
VALUEOFF NUMERIC 0
STRATÉGIE DE FIN
CATÉGORIE DE FIN
[chaînes]
KERB="Kerberos Maximum Token Size »
MaxToken="Kerberos MaxTokenSize »
NOTE
La valeur de l’entrée de Registre MaxTokenSize est définie sur 48000. Il s’agit de la valeur suggérée.
c. Enregistrez le document Bloc-notes sous le nom MaxTokenSize.adm dans le dossier %windir%\Inf\

sur le contrôleur de domaine que vous utiliserez pour configurer l’GPO afin de déployer le
paramètre.
d. Quittez Bloc-notes.
2. Importez L’ADM dans un GPO et définissez l’entrée de Registre MaxTokenSize sur la valeur souhaitée.
a. Créez un objet de stratégie de groupe lié au niveau du domaine ou lié à l’unité d’organisation qui
contient vos comptes d’ordinateur. Vous pouvez également sélectionner un GPO déjà déployé.
b. Ouvrez l’Éditeur d’objets de stratégie de groupe. Pour ce faire, cliquez sur Démarrer, sur Exécuter,
tapez gpedit.msc, puis cliquez sur OK.
c. Dans l’arborescence de la console, développez Configuration ordinateur, développez Modèles
d’administration, puis cliquez sur Modèles d’administration.
d. Dans le menu Action, pointez sur Toutes les tâches, puis cliquez sur Ajouter/Supprimer des
modèles.
e. Cliquez sur Ajouter.
f. Cliquez pour sélectionner le fichier MaxTokenSize.adm que vous avez créé à l’étape 1, puis cliquez
sur Ouvrir.
g. Cliquez sur Fermer.
h. Dans le menu Affichage, cliquez sur Filtrage.
i. Cliquez pour effacer la case à cocher Afficher uniquement les paramètres de stratégie qui peuvent
être entièrement gérés, puis cliquez sur OK.
j. Développez modèles d’administration, puis cliquez sur Taille maximale du jeton Kerberos.
k. Cliquez avec le bouton droit sur Kerberos MaxTokenSize dans le volet droit, puis cliquez sur
Propriétés pour ouvrir la boîte de dialogue Propriétés.
l. Cliquez sur Activé, puis cliquez sur OK.
NOTE
Pour que l’GPO prenne effet, la modification de l’GPO doit être répliquée sur tous les contrôleurs de
domaine du domaine, et les ordinateurs affectés doivent être redémarrés une fois que la stratégie leur est
appliquée.
Comment configurer l’entrée de Registre MaxTokenSize à l’aide d’un GPO dans Windows Server 2008 et
Dans les domaines Windows Server 2008 et Windows Server 2008 R2, vous pouvez utiliser l’extension Client-
Side registre pour déployer la valeur de Registre MaxTokenSize sur plusieurs ordinateurs d’un domaine. Pour
créer le paramètre de valeur MaxTokenSize dans un GPO, suivez les étapes suivantes :
1. Cliquez sur Démarrer, sur Exécuter, tapez gpmc.msc, puis cliquez sur OK pour ouvrir la console de gestion des
stratégies de groupe.
2. Dans la console de gestion des stratégies de groupe, créez un GPO lié au niveau du domaine ou lié à l’ou qui
3. Cliquez avec le bouton droit sur l’GPO, puis cliquez sur Modifier pour ouvrir la fenêtre Éditeur de gestion des
4. Développez Configuration ordinateur, Préférences, puis développez Windows Paramètres.
5. Cliquez avec le bouton droit sur Registre, pointez sur Nouveau, puis cliquez sur Élément de Registre. La boîte
de dialogue Nouvelles propriétés du Registre s’affiche.
6. Dans la liste Action, cliquez sur Créer.
7. Dans la liste Ruche, cliquez sur HKEY_LOCAL_MACHINE.
8. Dans la liste Chemin d’accès clé, cliquez sur SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
9. Dans la zone Nom de la valeur, tapez MaxTokenSize.
10. Dans la zone Type de valeur, cliquez pour cocher REG_DWORD cocher.
11. Dans la zone de données Valeur, tapez 48000.
12. En regard de Base, cliquez pour sélectionner la case à cocher Décimal.
13. Cliquez sur OK.
NOTE
Pour que l’GPO prenne effet, la modification de l’GPO doit être répliquée sur tous les contrôleurs de domaine dans le
domaine, et les ordinateurs affectés doivent être redémarrés après avoir appliqué la stratégie.
Comment configurer l’entrée de Registre MaxTokenSize à l’aide d’un GPO dans Windows Server 2012
Pour déployer la valeur de l’entrée de Registre MaxTokenSize dans un domaine Windows Server 2012 de
domaine basé sur des contrôleurs de domaine, suivez les étapes suivantes :
1. Ouvrez le Gestionnaire de serveur, cliquez sur Outils, puis cliquez sur Gestion des stratégies de groupe pour
ouvrir la console de gestion des stratégies de groupe.
2. Dans la console de gestion des stratégies de groupe, créez un GPO lié au niveau du domaine ou lié à l’ou qui
3. Cliquez avec le bouton droit sur l’GPO, puis cliquez sur Modifier pour ouvrir la fenêtre Éditeur de gestion des
4. Développez configuration ordinateur, développez Stratégies, puis développez Modèles d’administration.
5. Développez System, puis cliquez sur Kerberos.
6. Cliquez avec le bouton droit sur Définir la taille maximale de mémoire tampon de jeton de contexte SSPI
Kerberos dans le volet droit, puis cliquez sur Modifier.
7. Cliquez sur Activé, puis tapez 48000 dans la zone Taille maximale.
8. Cliquez sur OK.
NOTE
Pour que l’GPO prenne effet, la modification de l’GPO doit être répliquée sur tous les contrôleurs de domaine dans
le domaine, et les ordinateurs affectés doivent être redémarrés après avoir appliqué la stratégie.
Le paramètre de stratégie définir la taille maximale de mémoire tampon de jeton de contexte Kerberos est ajouté
dans Windows Server 2012 et dans Windows 8. Le paramètre de stratégie est pris en charge dans Windows XP,
dans Windows Server 2003, dans Windows Vista, dans Windows Server 2008, dans Windows 7 et dans Windows
Server 2008 R2. Pour utiliser ce paramètre de stratégie de groupe, vous devez modifier l’GPO dans une version de
Windows Server 2012 ou dans Windows 8 où les outils RSAT sont installés.
Références
Pour plus d’informations sur l’entrée de Registre MaxTokenSize, cliquez sur le numéro d’article suivant pour
327825 nouvelle résolution des problèmes liés à l’authentification Kerberos lorsque les utilisateurs
appartiennent à de nombreux groupes
Échec de l’application de l’élément Tâche
programmée GPP de l’utilisateur et enregistre l’ID
d’événement : 4098 avec 0x80070005'accès est
refusé
Cet article fournit une solution à un problème dans lequel l’élément de tâche programmée GPP (User Group
Policy Preference) ne s’applique pas.
Symptômes
Vous configurez l’élément GPP (User Group Policy Preference) suivant dans un domaine Active Directory basé
sur Windows 2008/2008 R2.
User Configuration\Preferences\Control Panel Settings\Scheduled Tasks\New\"Scheduled Task (Windows Vista
and later)"
Sous l’onglet Paramètres, sélectionnez l’option Exécuter dans le contexte de sécurité de l’utilisateur
connecté (option de stratégie utilisateur). Une fois la stratégie de groupe appliquée à un utilisateur,
vous constatez que l’élément de préférence ne prend pas effet.
En outre, vous voyez le journal des événements suivant dans le journal des applications :
En outre, si vous activez le suivi de stratégie de groupe pour l’extension côté client GPP Tâches programmées, les
messages suivants sont enregistrés dans le fichier journal de l’utilisateur GPP :
<DateTime>[pid=0x3a0,tid=0x8c8] Cours de <TaskV2> - <GPP item name> début.

<DateTime> [pid=0x3a0,tid=0x8c8] Définissez le contexte de sécurité utilisateur.
<DateTime> [pid=0x3a0,tid=0x8c8] Ajout d’éléments enfants à RSOP.
<DateTime> [pid=0x3a0,tid=0x8c8] WorkItem.Init [hr = 0x80070005 « Accès refusé."]
<DateTime> [pid=0x3a0,tid=0x8c8] Propriétés gérées. [hr = 0x80070005 « L’accès est refusé. »
<DateTime> [pid=0x3a0,tid=0x8c8] Définir le contexte de sécurité du système.
<DateTime> [pid=0x3a0,tid=0x8c8] ÉVÉNEMENT : l’élément de préférence de l’utilisateur dans l’objet de
stratégie de groupe « <GPP item name> {GPO GUID} » ne s’est pas appliqué, car il a échoué avec le code
d’erreur « 0x80070005 l’accès est <GPO name> refusé ». %100790273
<DateTime> [pid=0x3a0,tid=0x8c8] Erreur supprimée. [hr = 0x80070005 « L’accès est refusé. »
<DateTime>[pid=0x3a0,tid=0x8c8] Classe <TaskV2> - <GPP item name> terminée.
<DateTime> [pid=0x3a0,tid=0x8c8] Classe <ScheduledTasks> terminée.
Vous pouvez activer le suivi GPP par le biais de la stratégie de groupe :

Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and Tracing\Configure
Schedulled Tasks preference logging and tracing
Une fois configuré, le fichier journal est créé dans :

%SystemDrive%\ProgramData\GroupPolicy\Preference\Trace\User.log
Cause
L’élément Tâches programmées GPP utilisateur n’a pas été conçu pour s’exécuter dans le contexte de sécurité
des utilisateurs actuellement connectés et doit être appliqué dans le contexte de sécurité du système par défaut.
Résolution
Pour éviter ce problème, n’activez pas l’option Exécuter dans le contexte de sécurité de l’utilisateur connecté
(option de stratégie utilisateur) Option courante lors de la configuration des éléments tâches programmées GPP
de l’utilisateur.
Le contexte de sécurité dans lequel la tâche programmée s’exécute une fois déployée peut être spécifié dans
l’onglet Paramètres généraux lors de la création de l’élément Tâche programmée GPP de l’utilisateur :
User Configuration\Preferences\Control Panel Settings\Scheduled Tasks\New\"Scheduled Task (Windows Vista and
later)"
Général :
Options de sécurité : > « Lors de l’exécution de la tâche, utilisez le compte d’utilisateur suivant : »
Par défaut, elle est définie sur : %LogonDomain%\%LogonUser%
C’est là que le contexte de sécurité dans lequel la tâche programmée s’exécutera doit être configuré.
Des erreurs Userenv se produisent et des
événements sont consignés après l’application de la
stratégie de groupe aux ordinateurs exécutant
Windows Server 2003, Windows XP ou Windows
2000
Cet article fournit une solution aux problèmes où les ordinateurs de votre réseau ne peuvent pas se connecter
aux objets de stratégie de groupe (GPO) dans les dossiers Sysvol sur vos contrôleurs de domaine réseau.
Résumé
Vous pouvez faire l’expérience d’un ou de plusieurs événements et erreurs si la stratégie de groupe est
appliquée aux ordinateurs de votre réseau. Pour déterminer la cause du problème, vous devez résoudre les
problèmes de configuration des ordinateurs de votre réseau. Suivez ces étapes pour résoudre la cause du
problème :
1. Examinez les paramètres DNS et les propriétés réseau sur les serveurs et les ordinateurs clients.
2. Examinez les paramètres de signature de blocage des messages serveur sur les ordinateurs clients.
3. Assurez-vous que le service d’aide NetBIOS TCP/IP, le service Net Logon et le service d’appel de procédure
distante (RPC) sont démarrés sur tous les ordinateurs.
4. Assurez-vous que le système de fichiers distribués (DFS) est activé sur tous les ordinateurs.
5. Examinez le contenu et les autorisations du dossier Sysvol.
6. Assurez-vous que le droit de vérification du contournement est accordé aux groupes requis.
7. Assurez-vous que les contrôleurs de domaine ne sont pas dans un état de wrap wrap de journal.
8. Exécutez la commande dfsutil /purgemupcache .
Symptômes
Vous pouvez voir un ou plusieurs des symptômes suivants sur un ordinateur exécutant Microsoft Windows
Server 2003, Microsoft Windows XP ou Microsoft Windows 2000 :
Les paramètres de stratégie de groupe ne sont pas appliqués aux ordinateurs.
La réplication de stratégie de groupe n’est pas terminée entre les contrôleurs de domaine sur le réseau.
Vous ne pouvez pas ouvrir les logiciels en snap-in de stratégie de groupe. Par exemple, vous ne pouvez
pas ouvrir le logiciel en snap-in Stratégie de sécurité du contrôleur de domaine ou le logiciel en snap-in
Stratégie de sécurité du domaine.
Si vous essayez d’ouvrir un logiciel en snap-in de stratégie de groupe, vous recevez l’un des messages
d’erreur suivants :
Échec de l’ouverture de l’objet de stratégie de groupe. Vous n’avez peut-être pas les droits appropriés.
Détails : le compte n’est pas autorisé à se connecter à partir de cette station.
Vous n’êtes pas autorisé à effectuer cette opération.
Détails : l’accès est refusé.
Échec de l’ouverture de l’objet de stratégie de groupe. Vous n’avez peut-être pas les droits appropriés.
Détails : le système ne peut pas trouver le chemin d’accès spécifié.
Si vous essayez d’accéder à des fichiers partagés sur un contrôleur de domaine, vous recevez un message
d’erreur. Ce symptôme se produit même si vous êtes connecté au serveur et que vous essayez d’accéder à
un partage local. Plus précisément, ce symptôme peut affecter l’accès au partage Sysvol d’un contrôleur
de domaine.
Si vous essayez d’accéder à un partage de fichiers, un mot de passe vous est demandé à plusieurs
reprises.
Si vous essayez d’accéder à un partage de fichiers, vous recevez un message d’erreur semblable à l’un
des messages d’erreur suivants :
\\Ser ver_Name \ Share_Name n’est pas accessible. Vous n’êtes peut-être pas autorisé à utiliser
cette ressource réseau. Contactez l’administrateur de ce serveur pour savoir si vous avez des
autorisations d’accès.
Le compte n’est pas autorisé à se connecter à partir de cette station.
\\Ser ver_Name \ Share_Name n’est pas accessible.

Le compte n’est pas autorisé à se connecter à partir de cette station.
Si vous affichez le journal des applications dans l’Observateur d’événements sur Windows XP ou Windows
Server 2003, vous voyez des événements similaires aux événements suivants :

Date : Date
Heure :
Time
Utilisateur :
User_Name
Ordinateur :
Computer_Name
Description : Windows ne peut pas accéder au gpt.ini de fichier pour GPO CN={31B2F340-016D-11D2-
945F-00C04FB984F9},CN=Policies,CN=System,DC= domainname ,DC=com . Le fichier doit être présent à
l’emplacement <\ \ domainname .com\sysvol \ domainname .com\Policies \ {31B2F340-016D-11D2-
945F-00C04FB984 F9}\gpt.ini>. (Error_Message ). Le traitement de la stratégie de groupe a été abandonné.
Pour plus d’informations, consultez le Centre d’aide et de support à https://support.microsoft.com l’aide.
Le message d’erreur qui apparaît dans l’espace réser vé Error_Message’événement dans l’ID d’événement
1058 peut être l’un des messages d’erreur suivants :

Les informations de configuration n’ont pas pu être lues à partir du contrôleur de domaine, soit parce
que l’ordinateur n’est pas disponible, soit parce que l’accès a été refusé.

Date :
Date
Heure :
Time
Utilisateur :
User_Name
Ordinateur :
Computer_Name
Description : Windows ne peut pas interroger la liste des objets de stratégie de groupe. Un message qui
décrit la raison de cette erreur a été précédemment enregistré par le moteur de stratégie. Pour plus
d’informations, consultez le Centre d’aide et de support à https://support.microsoft.com l’aide.
En règle générale, si l’ID d’événement 1058 et l’ID d’événement 1030 se produisent, ils sont enregistrés par les
ordinateurs clients et les serveurs membres au démarrage de l’ordinateur. Les contrôleurs de domaine
enregistrent ces événements toutes les cinq minutes.
Si vous affichez le journal des applications dans l’Observateur d’événements sur un ordinateur Windows 2000,
vous voyez des événements similaires aux événements suivants :

Date :
Date
Heure :
Time
Utilisateur : AUTORITÉ NT\SYSTÈME
Ordinateur :
Computer_Name
Description : Windows ne peut pas accéder aux informations du Registre sur le site \ \
domainname .com\sysvol \ domainname .com\Policies \ {31B2F340-016D-11D2-945F-00C04FB984F
9}\Machine\registry.pol with (Error_Code ).
Le code d’erreur qui apparaît dans l Error_Code un espace réservé dans l’ID d’événement 1000 peut être l’un
des codes d’erreur suivants :
5
51
53
1231
1240
1722
Cause
Ces problèmes se produisent si les ordinateurs de votre réseau ne peuvent pas se connecter à certains objets de
stratégie de groupe. Plus précisément, ces objets sont dans les dossiers Sysvol sur les contrôleurs de domaine
de votre réseau.
Résolution
IMPORTANT
problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Veillez donc à suivre ces étapes
avec soin. Pour une meilleure protection, sauvegardez le registre avant de le modifier. Vous pouvez alors le restaurer en
cas de problème. Pour plus d’informations sur la façon de back up et restore the registry, voir How to back up and restore
the registry in Windows.
Pour résoudre ce problème, vous devez résoudre les problèmes de configuration de votre réseau pour réduire la
cause du problème, puis corriger la configuration. Pour résoudre la cause possible de ce problème, suivez les
étapes suivantes :
Étape 1 : Examiner les paramètres DNS et les propriétés réseau sur les serveurs et les ordinateurs clients
Dans les propriétés de connexion locale, client pour les réseaux Microsoft doit être activé sur tous les serveurs et
ordinateurs clients. Le composant Partage de fichiers et d’imprimantes pour les réseaux Microsoft doit être
activé sur tous les contrôleurs de domaine.
En outre, chaque ordinateur du réseau doit utiliser des serveurs DNS qui peuvent résoudre les enregistrements
SRV et les noms d’hôte pour la forêt Active Directory dont l’ordinateur est membre. En règle générale, une
erreur de configuration courante est que les ordinateurs clients utilisent les serveurs DNS qui appartiennent à
votre fournisseur de services Internet (ISP).
Sur tous les ordinateurs qui ont enregistré les erreurs Userenv, examinez les paramètres DNS et les propriétés
réseau. En outre, vérifiez ces paramètres sur tous les contrôleurs de domaine, qu’ils enregistrent ou non les
erreurs Userenv.
Pour vérifier les paramètres DNS et les propriétés réseau sur les Windows XP de votre réseau, suivez les étapes
suivantes :
1. Sélectionnez Démarrer, puis sélectionnez Panneau de contrôle.
2. Si le Panneau de contrôle est définie sur Affichage catégorie, sélectionnez Basculer en mode classique.
3. Double-cliquez sur Connexions réseau, cliquez avec le bouton droit sur Connexion locale, puis
4. Sous l’onglet Général, cochez la case Client pour Les réseaux Microsoft.
5. Sélectionnez Le protocole Internet (TCP/IP), puis sélectionnez Propriétés.
6. Si vous sélectionnez les adresses de serveur DNS suivantes, assurez-vous que les adresses IP des serveurs
DNS préférés et alternatifs sont les adresses IP des serveurs DNS qui peuvent résoudre les enregistrements
SRV et les noms d’hôte dans Active Directory. Plus précisément, l’ordinateur ne doit pas utiliser les serveurs
DNS qui appartiennent à votre isp. Si les adresses du serveur DNS ne sont pas correctes, tapez les adresses
IP des serveurs DNS corrects dans les zones Serveur DNS préféré et Serveur DNS de remplacement.
7. Sélectionnez Avancé, puis l’onglet DNS.
8. Cliquez pour sélectionner la case à cocher Enregistrer les adresses de cette connexion dans le DNS, puis
sélectionnez OK trois fois.
9. Démarrez une invite de commandes. Pour ce faire, sélectionnez Démarrer, Exécuter, tapez cmd, puis
sélectionnez OK.
10. Tapez ipconfig /flushdns, puis appuyez sur Entrée . Tapez ipconfig /registerdns, puis appuyez sur
Entrée .
11. Redémarrez l’ordinateur pour que vos modifications prennent effet.
Pour vérifier les paramètres DNS et les propriétés réseau sur Windows 2000 de votre réseau, suivez les étapes
suivantes :
1. Sélectionnez Démarrer, pointez sur Paramètres, puis sélectionnez Panneau de contrôle.
2. Double-cliquez sur Connexions réseau et numérotation.
3. Cliquez avec le bouton droit sur Connexion à la zone locale, puis sélectionnez Propriétés.
5. Si l’ordinateur est un contrôleur de domaine, cochez la case Partage de fichiers et d’imprimantes pour
Microsoft Networks.
NOTE
Sur les serveurs d’accès à distance multi-accueil et les serveurs basés sur un serveur IsA (Microsoft Internet
Security and Acceleration), vous pouvez désactiver le composant Partage de fichiers et d’imprimantes pour les
réseaux Microsoft pour l’adaptateur réseau connecté à Internet. Toutefois, le composant Client pour les réseaux
Microsoft doit être activé pour tous les adaptateurs réseau du serveur.
6. Sélectionnez Protocole Internet (TCP/IP), puis cliquez sur Propriétés.

7. Si vous sélectionnez les adresses de serveur DNS suivantes, assurez-vous que les adresses IP des
serveurs DNS préférés et alternatifs sont les adresses IP des serveurs DNS qui peuvent résoudre les
enregistrements SRV et les noms d’hôte dans Active Directory. Plus précisément, l’ordinateur ne doit pas
utiliser les serveurs DNS qui appartiennent à votre isp. Si les adresses du serveur DNS ne sont pas
correctes, tapez les adresses IP des serveurs DNS corrects dans les zones Serveur DNS préféré et
Serveur DNS de remplacement.
10. Démarrez une invite de commandes. Pour ce faire, sélectionnez Démarrer, Exécuter, tapez cmd dans
la zone Ouvrir, puis sélectionnez OK.
Entrée .
Pour vérifier les paramètres DNS et les propriétés réseau sur les ordinateurs Windows Server 2003 de votre
réseau, suivez les étapes suivantes :
1. Sélectionnez Démarrer, pointez sur Le Panneau de contrôle, puis double-cliquez sur Connexions
réseau.
2. Cliquez avec le bouton droit sur la connexion locale, puis sélectionnez Propriétés.
4. Si l’ordinateur est un contrôleur de domaine, cochez la case Partage de fichiers et d’imprimantes pour
Microsoft Networks.
NOTE
Sur les serveurs d’accès à distance multi-accueil et les serveurs ISA Server, vous pouvez désactiver le composant
Partage de fichiers et d’imprimantes pour les réseaux Microsoft pour l’adaptateur réseau connecté à Internet.
Toutefois, le composant Client pour les réseaux Microsoft doit être activé pour tous les adaptateurs réseau du
serveur.
5. Sélectionnez Le protocole Internet (TCP/IP), puis sélectionnez Propriétés.

6. Si vous sélectionnez les adresses de serveur DNS suivantes, assurez-vous que les adresses IP des
serveurs DNS préférés et alternatifs sont les adresses IP des serveurs DNS qui peuvent résoudre les
enregistrements SRV et les noms d’hôte dans Active Directory. Plus précisément, l’ordinateur ne doit pas
utiliser les serveurs DNS qui appartiennent à votre isp. Si les adresses du serveur DNS ne sont pas
correctes, tapez les adresses IP des serveurs DNS corrects dans les zones Serveur DNS préféré et
Serveur DNS de remplacement.
9. Démarrez une invite de commandes. Pour ce faire, sélectionnez Démarrer, Exécuter, tapez cmd, puis
sélectionnez OK.
Entrée .
11. Redémarrez l’ordinateur pour que vos modifications prennent effet.
Si les ordinateurs clients de votre réseau sont configurés pour obtenir leurs adresses IP automatiquement,
assurez-vous que l’ordinateur qui exécute le service DHCP affecte les adresses IP des serveurs DNS qui peuvent
résoudre les enregistrements SRV et les noms d’hôte dans Active Directory.
Pour déterminer les adresses IP qu’un ordinateur utilise pour le DNS, suivez les étapes suivantes :
1. Démarrez une invite de commandes. Pour ce faire, sélectionnez Démarrer, Exécuter, tapez cmd dans la
zone Ouvrir, puis sélectionnez OK.
2. Tapez ipconfig /all, puis appuyez sur Entrée .
3. Notez les entrées DNS répertoriées à l’écran.
Si les ordinateurs configurés pour obtenir automatiquement des adresses IP n’utilisent pas les serveurs DNS
corrects, consultez la documentation de votre serveur DHCP pour plus d’informations sur la configuration de
l’option de serveurs DNS. En outre, assurez-vous que chaque ordinateur peut résoudre l’adresse IP du domaine.
Pour ce faire, tapez ping Your_Domain_Name . Your_Domain_Root à une invite de commandes, puis appuyez
sur Entrée. Au lieu de cela, tapez nslookup Your_Domain_Name . Your_Domain_Root, puis appuyez sur
Entrée.
NOTE
Il est prévu que ce nom d’hôte soit résolu en adresse IP de l’un des contrôleurs de domaine sur le réseau. Si l’ordinateur
ne peut pas résoudre ce nom ou s’il est résolu en une adresse IP erronée, assurez-vous que la zone de recherche avant du
domaine contient des enregistrements d’hôte (A) valides (identiques au dossier parent).
Pour vous assurer que la zone de recherche avant pour le domaine contient des enregistrements d’hôte (A)
valides (identiques au dossier parent) sur un ordinateur Windows 2000, suivez les étapes suivantes :
1. Sur un contrôleur de domaine qui exécute le DNS, sélectionnez Démarrer, pointez sur Programmes,
pointez sur Outils d’administration, puis sélectionnez DNS .
2. Développez Your_Ser ver_Name, développez Zones de recherche avant, puis sélectionnez la zone de
recherche avant pour votre domaine.
3. Recherchez (comme le dossier parent) les enregistrements d’hôte (A).
4. Si un enregistrement d’hôte (A) (identique au dossier parent) n’existe pas, suivez les étapes suivantes
pour en créer un :
a. Dans le menu Action, sélectionnez Nouvel hôte.
b. Dans la zone d’adresse IP, tapez l’adresse IP de l’adaptateur réseau local du contrôleur de domaine.
c. Cliquez pour cocher la case Créer un enregistrement de pointeur associé (PTR), puis
sélectionnez Ajouter un hôte.
d. Lorsque vous recevez le message suivant, sélectionnez Oui :
(identique au dossier parent) n’est pas un nom d’hôte valide. Voulez-vous vraiment
ajouter cet enregistrement ?
5. Double-cliquez sur l’enregistrement hôte (A) (identique au dossier parent).

6. Vérifiez que l’adresse IP correcte est répertoriée dans la zone d’adresse IP.
7. Si l’adresse IP dans la zone d’adresse IP n’est pas valide, tapez l’adresse IP correcte dans la zone
d’adresse IP, puis sélectionnez OK .
8. Au lieu de cela, vous pouvez supprimer l’enregistrement hôte (A) (dossier parent) qui contient une
adresse IP non valide. Pour supprimer l’enregistrement hôte (A) (identique au dossier parent),
cliquez dessus avec le bouton droit, puis sélectionnez Supprimer.
9. Si le serveur DNS est un contrôleur de domaine qui est également un serveur de routage et d’accès à
distance, consultez La résolution des noms et les problèmes de connectivité sur un serveur de routage et
d’accès à distance qui exécute également DNSou WINS .
10. Sur tous les ordinateurs où vous ajoutez, supprimez ou modifiez des enregistrements DNS, tapez
ipconfig /flushdns à une invite de commandes, puis appuyez sur Entrée .
Pour vous assurer que la zone de recherche avant pour le domaine contient des enregistrements d’hôte (A)
valides (identiques au dossier parent) sur un ordinateur Windows Server 2003, suivez les étapes suivantes :
1. Sur un contrôleur de domaine qui exécute le DNS, sélectionnez Démarrer, pointez sur Outils
d’administration, puis sélectionnez DNS .
2. Développez Your_Ser ver_Name, développez Zones de recherche avant, puis sélectionnez la zone de
recherche avant pour votre domaine.
3. Recherchez l’enregistrement hôte (A) (identique au dossier parent).
4. Si l’enregistrement hôte (A) (identique au dossier parent) n’existe pas, suivez les étapes suivantes
pour en créer un :
a. Dans le menu Action, sélectionnez Nouvel hôte (A).
b. Dans la zone d’adresse IP, tapez l’adresse IP de l’adaptateur réseau local du contrôleur de domaine.
c. Cliquez pour cocher la case Créer un enregistrement de pointeur associé (PTR), puis
sélectionnez Ajouter un hôte.
d. Lorsque vous recevez le message suivant, sélectionnez Oui :
(identique au dossier parent) n’est pas un nom d’hôte valide. Voulez-vous vraiment
ajouter cet enregistrement ?
5. Double-cliquez sur l’enregistrement hôte (A) (identique au dossier parent).

6. Vérifiez que l’adresse IP correcte est répertoriée dans la zone d’adresse IP.
7. Si l’adresse IP est dans la zone d’adresse IP non valide, tapez l’adresse IP correcte dans la zone d’adresse
IP, puis sélectionnez OK .
8. Au lieu de cela, vous pouvez supprimer l’enregistrement (identique au dossier parent) Hôte (A) qui
contient l’adresse IP non valide. Pour supprimer l’enregistrement hôte (A), cliquez avec le bouton droit de
la souris (comme le dossier parent), puis sélectionnez Supprimer.
9. Si le serveur DNS est un contrôleur de domaine qui est également un serveur de routage et d’accès à
distance, consultez La résolution des noms et les problèmes de connectivité sur un serveur de routage et
d’accès à distance qui exécute également DNSou WINS .
10. Sur tous les ordinateurs où vous ajoutez, supprimez ou modifiez des enregistrements DNS, tapez
ipconfig /flushdns à une invite de commandes, puis appuyez sur Entrée .
Étape 2 : Examiner les paramètres de signature de blocage des messages du serveur sur les ordinateurs
clients et les serveurs membres
Les paramètres de signature SMB (Server Message Block) définissent si les ordinateurs du réseau signent
numériquement les communications. Si les paramètres de signature SMB ne sont pas configurés correctement,
les ordinateurs clients ou les serveurs membres risquent de ne pas pouvoir se connecter aux contrôleurs de
domaine.
Par exemple, la signature SMB peut être requise par les contrôleurs de domaine, mais la signature SMB peut être
désactivée sur les ordinateurs clients. Si ce problème se produit, la stratégie de groupe ne peut pas être
appliquée correctement. Ainsi, les ordinateurs clients enregistrent les erreurs de l’environnement utilisateur
(Userenv) dans le journal des applications. Parfois, les paramètres de signature SMB pour le service serveur et le
service Station de travail sur un contrôleur de domaine peuvent être en conflit les uns avec les autres.
Par exemple, la signature SMB peut être désactivée pour le service Station de travail du contrôleur de domaine,
mais la signature SMB est requise pour le service serveur du contrôleur de domaine. Dans ce scénario, vous ne
pouvez pas ouvrir un ou plusieurs partages de fichiers locaux du contrôleur de domaine si vous êtes connecté
au serveur. En outre, vous ne pouvez pas ouvrir les logiciels en snap-in de stratégie de groupe si vous êtes
connecté au serveur.
Pour plus d’informations sur la résolution de ce problème sur un contrôleur de domaine, voir You cannot open
file shares or Group Policy snap-ins on a domain controller.
Si des erreurs de stratégie de groupe se produisent uniquement sur les ordinateurs clients et les serveurs
membres, ou si vous déterminez que vous ne pouvez pas ouvrir de partages de fichiers ou de logiciels en snap-
in de stratégie de groupe sur un contrôleur de domaine ne s’applique pas à votre situation, continuez à résoudre
le problème.
Par défaut, la signature SMB est activée, mais n’est pas requise pour la communication client sur les ordinateurs
clients et les serveurs membres exécutant Windows XP, Windows 2000 ou Windows Server 2003. Nous vous
recommandons d’utiliser la configuration par défaut, car les ordinateurs clients peuvent utiliser la signature
SMB lorsque cela est possible, mais communiquent toujours avec les serveurs pour qui la signature SMB est
désactivée.
Pour configurer les ordinateurs clients et les serveurs membres afin que la signature SMB soit activée mais non
requise, vous devez modifier les valeurs de certaines entrées de Registre. Pour apporter des modifications au
Registre sur les ordinateurs clients, suivez les étapes suivantes :
1. Select Star t , select Run , type regedit in the Open box, and then select OK .
2. Développez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
3. Dans le volet droit, cliquez avec le bouton droit sur enablesecuritysignature, puis sélectionnez Modifier .
5. Cliquez avec le bouton droit sur requiresecuritysignature, puis sélectionnez Modifier .
7. Développez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters
8. Dans le volet droit, cliquez avec le bouton droit sur enablesecuritysignature, puis sélectionnez Modifier .
10. Cliquez avec le bouton droit sur requiresecuritysignature, puis sélectionnez Modifier .
Après avoir changé les valeurs du Registre, redémarrez les services Serveur et Station de travail. Ne redémarrez
pas les ordinateurs, car cela peut entraîner l’application de stratégies de groupe, et les paramètres de stratégie
de groupe peuvent à nouveau configurer des valeurs conflictuelles.
Après avoir changé les valeurs du Registre et redémarré les services Serveur et Station de travail sur les
ordinateurs concernés, suivez les étapes suivantes :
1. Afficher les paramètres de stratégie de groupe pour les GPO ou les GPO qui s’appliquent aux comptes
d’ordinateur affectés.
2. Assurez-vous que les stratégies de groupe ne sont pas en conflit avec les paramètres de Registre requis.
3. Utilisez l’Éditeur d’objets de stratégie de groupe pour afficher les paramètres de stratégie dans le dossier
suivant : Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options
Sur un ordinateur exécutant Windows Server 2003, les paramètres de stratégie de groupe de signature SMB ont
les noms suivants :
Serveur réseau Microsoft : communications avec signature numérique (toujours)
Serveur réseau Microsoft : communications avec signature numérique (si le client l’accepte)
Client réseau Microsoft : communications avec signature numérique (toujours)
Client réseau Microsoft : communications avec signature numérique (si le serveur l’accepte)
Sur un ordinateur exécutant Windows Server 2000, les paramètres de stratégie de groupe de signature SMB ont
les noms suivants :
Communication avec le serveur signé numériquement (toujours)
Communication avec le serveur signé numériquement (dans la mesure du possible)
Communications client signe numériquement (toujours)
Signature numérique des communications clientes (dans la mesure du possible)
En règle générale, les paramètres de stratégie de groupe de signature SMB sont configurés comme « Non défini
». Si vous définissez les paramètres de stratégie de groupe de signature SMB, assurez-vous de comprendre la
façon dont ces paramètres peuvent affecter la connectivité réseau.
Pour plus d’informations sur les paramètres de signature SMB, voir Les problèmes de client, de service et de
programme peuvent se produire si vous modifiez les paramètres de sécurité et les attributions de droits
d’utilisateur.
Si vous modifiez les paramètres d’un GPO sur un contrôleur de domaine qui exécute Windows Server 2000,
2. Tapez secedit /refreshpolicy machine_policy /enforce, puis appuyez sur Entrée .
3. Redémarrez les ordinateurs clients concernés.
4. Revérifiez les valeurs de signature SMB dans le Registre sur les ordinateurs clients pour vous assurer qu’elles
n’ont pas changé de manière inattendue.
Si vous modifiez les paramètres d’un GPO sur un contrôleur de domaine qui exécute Windows Server 2003,
2. Tapez gpupdate /force, puis appuyez sur Entrée .
3. Redémarrez les ordinateurs clients concernés.
4. Revérifiez les valeurs de signature SMB dans le Registre sur les ordinateurs clients pour vous assurer qu’elles
n’ont pas changé de manière inattendue.
Si les valeurs de signature SMB dans le Registre changent de manière inattendue après le redémarrage des
ordinateurs clients, utilisez l’une des méthodes suivantes pour afficher les paramètres de stratégie appliqués à
un ordinateur client :
Sur un ordinateur Windows XP, utilisez le composant logiciel en snap-in MMC (Rsop.msc) résultant de
l’ensemble de stratégies. Pour plus d’informations sur l’ensemble de stratégie résultant, voir Jeu de
stratégie résultant.
Sur Windows 2000, utilisez l’outil Gpresult.exe ligne de commande pour examiner les résultats de la
stratégie de groupe. Pour ce faire, suivez les étapes suivantes :
1. Installez Gpresult.exe à partir du kit de ressources Windows 2000.
2. À l’invite de commandes, tapez gpresult /scope computer, puis appuyez sur Entrée .
3. Dans la section Objets de stratégie de groupe appliqués de la sortie, notez les objets de stratégie
de groupe qui sont appliqués au compte d’ordinateur.
4. Comparez les objets de stratégie de groupe qui sont appliqués au compte d’ordinateur qui
possède les paramètres de stratégie de signature SMB sur le contrôleur de domaine pour ces
objets de stratégie de groupe.
Étape 3 : Assurez-vous que le service d’aide NetBIOS TCP/IP est démarré sur tous les ordinateurs
Tous les ordinateurs du réseau doivent exécuter le service d’aide NetBIOS TCP/IP.
Pour vérifier que le service d’aide NetBIOS TCP/IP est en cours d’exécution sur un ordinateur Windows XP, suivez
1. Sélectionnez Démarrer, puis sélectionnez Panneau de contrôle.
2. Si le Panneau de contrôle est en mode Catégorie, sélectionnez Basculer en mode classique.
3. Double-cliquez sur Outils d’administration.
4. Double-cliquez sur Ser vices .
5. Dans la liste Ser vices, sélectionnez L’aide netBIOS TCP/IP. Vérifiez que la valeur sous la colonne État est
démarrée. Vérifiez que la valeur sous la colonne Type de démarrage est Automatique . Si les valeurs État
ou Type de démarrage ne sont pas correctes, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur L’aide TCP/IP NetBIOS, puis sélectionnez Propriétés.
b. Dans la liste des types de démarrage, sélectionnez Automatique.
c. Dans la zone État du ser vice, si le service n’est pas démarré, sélectionnez Démarrer.
Pour vérifier que le service d’aide NetBIOS TCP/IP est en cours d’exécution sur un ordinateur Windows Server
2003, suivez les étapes suivantes :
2. Dans la liste Ser vices, sélectionnez L’aide netBIOS TCP/IP. Vérifiez que la valeur sous la colonne État est
démarrée. Vérifiez que la valeur sous la colonne Type de démarrage est Automatique . Si les valeurs État
ou Type de démarrage ne sont pas correctes, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur L’aide TCP/IP NetBIOS, puis sélectionnez Propriétés.
Pour vérifier que le service d’aide NetBIOS TCP/IP est en cours d’exécution sur un ordinateur Windows 2000,
1. Sélectionnez Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis sélectionnez
Ser vices.
2. Dans la liste Ser vices, sélectionnez Service d’aide NetBIOS TCP/IP. Vérifiez que la valeur sous la colonne
État est démarrée. Vérifiez que la valeur sous la colonne Type de démarrage est Automatique . Si les
valeurs État ou Type de démarrage ne sont pas correctes, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur le ser vice d’aide NetBIOS TCP/IP, puis sélectionnez Propriétés.
En outre, assurez-vous que vous n’avez pas désactivé un ou plusieurs des services système requis à l’aide
d’objets de stratégie de groupe. Affichez ces paramètres de stratégie à l’aide de l’Éditeur d’objets de stratégie de
groupe dans le Computer Configuration/Windows Settings/Security Settings/System Services dossier.
Sur Windows Server 2003 et Windows XP, vous pouvez utiliser le composant logiciel en snap-in MMC
(Rsop.msc) résultant pour vérifier tous les paramètres de stratégie appliqués à un ordinateur. Pour ce faire,
sélectionnez Démarrer, Exécuter, tapez rsop.msc dans la zone Ouvrir, puis sélectionnez OK.
Sur Windows 2000, utilisez l’outil Gpresult.exe ligne de commande pour examiner les résultats de la stratégie de
groupe. Pour ce faire, suivez les étapes suivantes :
1. Installez Gpresult.exe à partir du kit de ressources Windows 2000.
2. À l’invite de commandes, tapez gpresult /scope computer, puis appuyez sur Entrée .
3. Dans la section Objets de stratégie de groupe appliqués de la sortie, notez les objets de stratégie de groupe
qui sont appliqués au compte d’ordinateur.
4. Comparez les objets de stratégie de groupe qui sont appliqués au compte d’ordinateur aux paramètres de
stratégie de signature SMB sur le contrôleur de domaine pour ces objets de stratégie de groupe.
NOTE
Si le service d’aide NetBIOS TCP/IP est désactivé sur de nombreux ordinateurs de bureau, vous pouvez utiliser l’exemple de
script Microsoft Visual Basic suivant pour démarrer le service d’aide NetBIOS TCP/IP sur tous les ordinateurs d’une unité
d’organisation en même temps.
implicite. Cela inclut, sans s’y limiter, les garanties implicites de qualité ou d’aptitude à un usage particulier. Cet
article part du principe que vous êtes familiarisé avec le langage de programmation qui est démontré et avec les
outils utilisés pour créer et déboguer des procédures. Les ingénieurs du support technique De Microsoft
peuvent expliquer les fonctionnalités d’une procédure particulière, mais ils ne modifient pas ces exemples pour
fournir des fonctionnalités supplémentaires ou construire des procédures qui répondent à vos besoins
spécifiques.
Set objDictionary = CreateObject("Scripting.Dictionary")

i = 0
Set objOU = GetObject("LDAP://OU=Computers, OU=OUName, OU=OUName, DC=OUName,
DC=OUName,DC=CompanyName,
DC=com")
objOU.Filter = Array("Computer")
For Each objComputer In objOU
objDictionary.Add i, objComputer.CN
i = i + 1
Next
For Each objItem In objDictionary
strComputer = objDictionary.Item(objItem)
Set objWMIService =
GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer &
"\root\cimv2")
Set colServices = objWMIService.ExecQuery _

("Select * from Win32_Service where Name = 'LmHosts'")
For Each objService In colServices
If objService.StartMode = "Disabled" Then
objService.Change( , , , , "Automatic")
End If
Next
Next
Étape 4 : Assurez-vous que le système de fichiers distribués (DFS ) est activé sur tous les ordinateurs
Tous les contrôleurs de domaine doivent exécuter le service système de fichiers distribués, car le partage Sysvol
est un volume DFS. En outre, le client DFS doit être activé dans le Registre sur tous les ordinateurs.
Pour vous assurer que le service de système de fichiers distribués est en cours d’exécution Windows contrôleurs
de domaine basés sur Windows Server 2003, suivez les étapes suivantes :
2. Dans la liste Ser vices, sélectionnez Service de système de fichiers distribués. Vérifiez que la valeur sous la
colonne État est démarrée. Vérifiez que la valeur sous la colonne Type de démarrage est Automatique .
Si les valeurs État ou Type de démarrage ne sont pas correctes, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur Système de fichiers distribués, puis sélectionnez Propriétés.
Pour vous assurer que le service de système de fichiers distribués s’exécute sur Windows 2000 Server, suivez les
étapes suivantes :
Ser vices.
2. Dans la liste Ser vices, sélectionnez Service de système de fichiers distribués. Vérifiez que la valeur sous la
colonne État est démarrée. Vérifiez que la valeur sous la colonne Type de démarrage est Automatique .
Si les valeurs État ou Type de démarrage ne sont pas correctes, suivez les étapes suivantes :
a. Cliquez avec le bouton droit sur Système de fichiers distribués, puis sélectionnez Propriétés.
Pour vous assurer que le client de système de fichiers distribués est activé sur tous les ordinateurs clients, suivez
1. Select Star t , select Run , type regedit in the Open box, and then select OK .
2. Développez la sous-clé suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup
3. Sélectionnez Mup, puis dans le volet droit, recherchez une entrée de valeur DWORD nommée DisableDFS .
4. Si l’entrée DisableDFS existe et que les données de valeur sont 1, double-cliquez sur DisableDFS . Dans la
zone Données de la valeur, tapez 0, puis sélectionnez OK. Si les données de la valeur DisableDFS sont déjà
0 ou si l’entrée DisableDFS n’existe pas, n’a aucune modification.
6. Si vous avez modifié les données de valeur DisableDFS, redémarrez l’ordinateur.
Étape 5 : Examiner le contenu et les autorisations du dossier Sysvol
Par défaut, le dossier Sysvol se trouve dans le %systemroot% dossier. Le dossier Sysvol contient les objets de
stratégie de groupe du domaine, les partages Sysvol et Netlogon et le dossier intermédiaire du service de
réplication de fichiers (FRS).
Si les autorisations sur le dossier Sysvol ou le partage Sysvol sont trop restrictives, les stratégies de groupe ne
peuvent pas être appliquées correctement et provoquent des erreurs d’environnement utilisateur (Userenv). En
outre, des erreurs Userenv peuvent se produire si le partage Sysvol ou les objets de stratégie de groupe sont
manquants.
Pour vous assurer que le partage Sysvol est disponible, exécutez la commande de partage net à une invite de
commandes sur chaque contrôleur de domaine. Pour ce faire, suivez les étapes suivantes :
1. Sélectionnez Démarrer, Sélectionnez Exécuter, tapez cmd dans la zone Ouvrir, puis sélectionnez OK.
2. Tapez net share, puis appuyez sur Entrée .
3. Recherchez SYSVOL et NETLOGON dans la liste des dossiers.
Si les partages Sysvol ou Netlogon sont absents d’un ou de plusieurs contrôleurs de domaine, vous devez
résoudre la cause du problème.
Pour plus d’informations sur la résolution des problèmes des partages Sysvol et Netlogon manquants dans
Windows 2000 Server, voir Troubleshooting missing SYSVOL and NETLOGON shares on Windows domain
controllers.
Pour plus d’informations sur la reconstruction du partage Sysvol dans Windows Server 2003, voir Comment
reconstruire l’arborescence SYSVOLet son contenu dans un domaine .
Une fois que vous vous êtes assuré que le partage Sysvol est disponible, assurez-vous que le dossier Sysvol, le
partage Sysvol et le dossier racine du volume qui contient le dossier Sysvol sont configurés avec les
autorisations correctes.
En outre, sur Windows 2000 Server, le groupe Tout le monde doit obtenir l’autorisation Contrôle total sur le
dossier racine du volume qui contient le dossier Sysvol. Sur Windows Server 2003, le groupe Tout le monde doit
être autorisé à lire & Exécuter une autorisation spéciale sur « Ce dossier uniquement », et le groupe
domaine\Utilisateurs doit se voir accorder les autorisations standard suivantes :
Lire & Exécuter
Contenu du dossier de liste
Lecture
En outre, sur Windows Server 2003, le groupe domaine\Utilisateurs doit avoir les autorisations spéciales
suivantes :
Lisez & l’autorisation Exécuter sur « Ce dossier, les sous-dossiers et les fichiers ».
Autorisation Créer un dossier/ Append Data sur « Ce dossier et ses sous-dossiers ».
Créer des fichiers / Autorisation Écrire des données dans « Sous-dossiers uniquement ».
Après avoir vérifié les autorisations Sysvol, assurez-vous que le dossier Sysvol contient les objets de stratégie de
groupe requis. Pour rechercher les objets de stratégie de groupe requis, utilisez le programme Gpotool.exe du
kit de ressources Windows 2000 ou Windows Server 2003.
Si vous exécutez le programme Gpotool.exe sans options, il recherche tous les objets de stratégie de groupe sur
tous les contrôleurs de domaine du domaine. Si vous incluez le commutateur, l’outil analyse également la liste
de contrôle d’accès /checkacl (ACL) Sysvol. Pour obtenir une sortie détaillée lorsque vous exécutez Gpotool.exe
programme, utilisez le /verbose commutateur.
Au lieu de cela, vous pouvez vérifier manuellement l’GPO individuel dans le dossier SYSVOL. Par exemple, si la
description de l’événement Userenv 1058 répertorie le nom d’un GPO, vous pouvez vérifier manuellement le
GPO individuel dans le dossier SYSVOL. Vous pouvez le faire pour vous assurer qu’il contient un dossier USER,
un dossier MACHINE et un Gpt.ini fichier. Pour vérifier manuellement l’GPO individuel dans le dossier SYSVOL,
2. Tapez à l’heure /interactive/suivante : cmd.exe, puis appuyez sur Entrée , où l’heure est 1 ou 2 minutes plus
tard que l’heure actuelle et est écrite au format d’heure 24 heures. Par exemple, 3 minutes après 13 h 00
serait 13:03 au format d’heure 24 heures.
3. Au moment où vous spécifiez dans la commande précédente, une nouvelle fenêtre d’invite de commandes
s’ouvre. Type net use j: \ \ domainname.com\sysvol\domainname.com\Policies \ {GUID }, and then press
Enter , where GUID is the GUID of the GPO that is in the Userenv event description. Par exemple, si la
description de l’événement Userenv 1058 indique : « Le fichier doit être présent à l’emplacement <\ \
Domain_Name .com\sysvol \ Domain_Name .com\Policies \ {31B2F340-016D-11D2-945F-00C04FB984
F9}\gpt.ini> », le GUID que vous utiliseriez dans la commande est 31B2F340-016D-11D2-945F-
00C04FB984F9.
4. Tapez dir j: \ * .*, puis appuyez sur Entrée .
5. Vérifiez qu’un dossier UTILISATEUR, un dossier MACHINE et un fichier Gpt.ini sont répertoriés dans la liste
des dossiers du lecteur I. Si l’un de ces dossiers et fichiers est manquant, les ordinateurs du réseau sont
susceptibles d’enregistrer les erreurs Userenv dans le journal des applications.
Si un ou plusieurs objets de stratégie de groupe sont manquants dans le dossier Sysvol, exécutez l’utilitaire de
restauration de stratégie de groupe par défaut de Windows Server 2003 (Dcgpofix.exe) ou l’outil de restauration
de stratégie de groupe par défaut Windows 2000 (Recreatedefpol.exe) pour créer à nouveau les objets de
stratégie de groupe par défaut.
Le Dcgpofix.exe est inclus dans Windows Server 2003. Pour plus d’informations sur Dcgpofix.exe programme,
exécutez dcgpofix /? la commande à l’invite de commandes.
Veillez à définir les exclusions recommandées lorsque vous analysez le lecteur Sysvol avec un logiciel antivirus.
L’analyse avec un logiciel antivirus peut bloquer l’accès aux fichiers requis, tels que Gpt.ini fichier. Vous devez
configurer ces exclusions pour toutes les analyses antivirus en temps réel, programmées et manuelles.
Étape 6 : assurez-vous que le droit de vérification de la déviation du contournement est accordé aux groupes
requis
Le droit de vérification de la traversée de contournement doit être accordé aux groupes suivants sur les
contrôleurs de domaine :
Administrateurs
Tout le monde
Accès compatible Windows 2000 pré-édition 2000
Pour vérifier que le droit de vérification du contournement a été accordé sur un contrôleur de domaine
Windows Server 2003, suivez les étapes suivantes :
1. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez Stratégie de sécurité du
2. Développez les stratégies locales, puis sélectionnez Attribution des droits d’utilisateur.
3. Double-cliquez sur Ignorer la vérification de la traversée.
4. Cochez la case Définir ces paramètres de stratégie.
5. Vérifiez que les groupes Administrateurs, Utilisateurs authentifiés, Tout le monde et Pré-Windows 2000 Sont
répertoriés pour ce paramètre de stratégie. Si l’un de ces groupes est manquant, suivez les étapes suivantes :
a. Sélectionnez Ajouter un utilisateur ou un groupe.
b. Dans la zone Noms d’utilisateur et de groupe, tapez le nom du groupe manquant, puis
sélectionnez OK.
6. Sélectionnez OK pour fermer le paramètre de stratégie.
8. Tapez gpupdate /force, puis appuyez sur Entrée .
Pour vérifier que le droit de vérification du contournement a été accordé à un contrôleur de domaine Windows
Server 2000, suivez les étapes suivantes :
Stratégie de sécurité du contrôleur de domaine.
2. Développez Sécurité Paramètres, développez Stratégies locales, puis sélectionnez Attribution des
droits d’utilisateur.
3. Double-cliquez sur Ignorer la vérification de la traversée.
4. Cochez la case Définir ces paramètres de stratégie.
5. Vérifiez que les groupes Administrateurs, Utilisateurs authentifiés, Tout le monde et Pré-Windows 2000 Sont
répertoriés pour ce paramètre de stratégie. Si l’un de ces groupes est manquant, suivez les étapes suivantes :
a. Sélectionnez Ajouter .
b. Dans la zone Noms d’utilisateur et de groupe, tapez le nom du groupe manquant, puis
sélectionnez OK.
6. Sélectionnez OK pour fermer le paramètre de stratégie.
8. Tapez secedit /refreshpolicy machine_policy /enforce, puis appuyez sur sélectionner.
Étape 7 : Assurez-vous que les contrôleurs de domaine ne sont pas dans un état d’encapsuler le journal
Pour voir si un contrôleur de domaine est dans un état de wrapot de journal, affichez le journal du service de
réplication de fichiers dans l’Observateur d’événements et recherchez l’ID d’événement NTFRS 13568. L’ID
d’événement 13568 est similaire à l’ID d’événement suivant :
Si l’ID d’événement NTFRS 13568 est enregistré sur un contrôleur de domaine, pour plus d’informations sur la
résolution des erreurs de journal wrap, voir Comment résoudre les erreurs journal_wrap sur les jeux de réplicas
Sysvol et DFS.
Étape 8 : Exécuter la commande Dfsutil /PurgeMupCache
Exécutez le Dfsutil.exe avec le commutateur pour vider les informations /PurgeMupCache DFS/MUP locales mises
en cache. Le Dfsutil.exe est inclus dans les outils de support Windows Server 2000 et Windows Server 2003.
Les filtres de stratégie de groupe WMI qui
comparent Win32_OperatingSystem BuildNumber
ne fonctionnent pas comme prévu
Cet article fournit une solution à un problème dans lequel les filtres de stratégie de groupe Windows
Management Instrumentation (WMI) qui comparent Win32_OperatingSystem BuildNumber ne fonctionnent pas
comme prévu dans Windows 10.
S’applique à : Windows 10 - toutes les éditions
Symptômes
Vous souhaitez que la stratégie de groupe s’applique Windows 8.1 versions ultérieures de Windows.
Vous souhaitez utiliser Win32_OperatingSystem BuildNumber pour ce faire.
Vous créez le filtre WMI suivant, en fonction des numéros de build connus des versions Windows
suivantes :
"Select BuildNumber from Win32_OperatingSystem WHERE BuildNumber >= 9200 "
N UM ÉRO DE B UIL D VERSIO N DE W IN DO W S
9200 Windows 8
9600 Windows 8.1
10240 Windows 10
10586 Windows 10, version 1511
Dans ce scénario, bien que vous vous attendiez à ce que le filtre WMI entraîne l’application du paramètre de
stratégie de groupe au numéro de build 9200 et aux builds ultérieures, les builds Windows 10 sont exclues.
Cause
Ce problème se produit car le type de données pour BuildNumber est String et non Integer. Par conséquent,
10*** < 9600.
Résolution
Pour résoudre ce problème, utilisez un filtre qui ressemble à l’exemple suivant.
NOTE
Il existe plusieurs façons de forcer la comparaison de chaînes pour renvoyer le résultat que vous souhaitez. Vous pouvez
utiliser n’importe quelle méthode de votre préférence. L’exemple est entièrement fonctionnel.
Select BuildNumber from Win32_OperatingSystem WHERE BuildNumber >= 10000 AND BuildNumber LIKE "%[123456789]
[0123456789][0123456789][0123456789][0123456789]%" OR BuildNumber >= 9200 AND BuildNumber LIKE "%[123456789]
[0123456789][0123456789][0123456789]%"
Comment configurer des stratégies de groupe pour
définir la sécurité des services système
Cet article explique comment configurer des stratégies de groupe pour définir la sécurité des services système.
Résumé
Cet article explique comment utiliser la stratégie de groupe pour définir la sécurité des services système pour
une unité d’organisation dans Windows Server 2003.
Lorsque vous implémentez la sécurité sur les services système, vous pouvez contrôler qui peut gérer les
services sur une station de travail, un serveur membre ou un contrôleur de domaine. Actuellement, la seule
façon de modifier un service système consiste à utiliser un paramètre d’ordinateur de stratégie de groupe.
Si vous implémentez la stratégie de groupe en tant que stratégie de domaine par défaut, la stratégie est
appliquée à tous les ordinateurs du domaine. Si vous implémentez la stratégie de groupe en tant que stratégie
des contrôleurs de domaine par défaut, la stratégie s’applique uniquement aux serveurs de l’unité d’organisation
du contrôleur de domaine. Vous pouvez créer des unités d’organisation qui contiennent des ordinateurs de
station de travail sur lesquels des stratégies peuvent être appliquées. Cet article décrit les étapes à suivre pour
implémenter une stratégie de groupe sur une unité d’organisation afin de modifier les autorisations sur les
services système.
Comment attribuer des autorisations de service système
1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Utilisateurs et ordinateurs
Active Director y.
2. Cliquez avec le bouton droit sur le domaine auquel vous souhaitez ajouter l’unité d’organisation, pointez
sur Nouveau, puis cliquez sur Unité d’organisation.
3. Tapez un nom pour l’unité d’organisation dans la zone Nom, puis cliquez sur OK.
La nouvelle unité d’organisation est répertoriée dans l’arborescence de la console.
4. Cliquez avec le bouton droit sur la nouvelle unité d’organisation que vous avez créée, puis cliquez sur
Propriétés.
5. Cliquez sur l’onglet Stratégie de groupe, puis sur Nouveau. Tapez un nom pour le nouvel objet de
stratégie de groupe (par exemple, utilisez le nom de l’unité d’organisation pour laquelle il est
implémenté), puis appuyez sur Entrée.
6. Cliquez sur le nouvel objet de stratégie de groupe dans la liste Liens des objets de stratégie de groupe
(s’il n’est pas déjà sélectionné), puis cliquez sur Modifier.
7. Développez Configuration ordinateur, développez Windows Paramètres, développez Sécurité Paramètres,
puis cliquez sur Services système.
8. Dans le volet droit, double-cliquez sur le service auquel vous souhaitez appliquer des autorisations.
Le paramètre de stratégie de sécurité pour ce service spécifique s’affiche.
9. Cliquez pour cocher Définir ce paramètre de stratégie.
10. Cliquez sur Modifier la sécurité.
11. Accordez les autorisations appropriées aux comptes et groupes d’utilisateurs que vous souhaitez, puis
cliquez sur OK.
12. Sous Sélectionner le mode de démarrage du ser vice, cliquez sur l’option de mode de démarrage de
votre choix, puis cliquez sur OK.
13. Fermez l’Éditeur d’objets de stratégie de groupe, cliquez sur OK, puis fermez l’outil Utilisateurs et
ordinateurs Active Directory.
NOTE
Vous devez déplacer les comptes d’ordinateur à gérer dans l’unité d’organisation. Une fois que les comptes d’ordinateur
sont contenus dans l’unité d’organisation, l’utilisateur ou les groupes autorisés peuvent gérer le service.
Informations sur les événements préférences de
Cet article fournit des informations sur les événements de préférences de stratégie de groupe.
Résumé
Les préférences de stratégie de groupe (GPP) vous permettent de spécifier les paramètres de configuration de
l’ordinateur et de l’utilisateur. Ces paramètres permettent une configuration granulaire qui n’est pas disponible à
l’aide d’une stratégie de groupe normale. GPP fournit également le filtrage des paramètres à l’aide du ciblage au
niveau de l’élément qui permet une application granulaire des paramètres à un sous-ensemble d’utilisateurs ou
d’ordinateurs.
Vous souhaiterez peut-être connaître les événements possibles qui peuvent être enregistrés par un composant,
afin de les classer correctement dans les solutions de gestion du système. Vous trouverez ci-dessous la liste des
événements pour les préférences de stratégie de groupe.
Les événements Préférences de stratégie de groupe sont écrits dans le journal des applications. Les événements
d’information sont enregistrés uniquement lorsque les paramètres de stratégie de groupe appropriés sont
activés. Le chemin d’accès aux paramètres par zone de préférence est :
suivi
Les sources d’événements possibles de ces événements sont :
Environnement de stratégie de groupe
Utilisateurs et groupes locaux de stratégie de groupe
Appareils de stratégie de groupe Paramètres
Options de réseau de stratégie de groupe
Lecteur de stratégie de groupe Cartes
Dossiers de stratégie de groupe
Partages réseau de stratégie de groupe
Fichiers de stratégie de groupe
Sources de données de stratégie de groupe
Fichiers Ini de stratégie de groupe
Services de stratégie de groupe
Options de dossier de stratégie de groupe
Tâches programmées de stratégie de groupe
Registre de stratégie de groupe
Applications de stratégie de groupe
Imprimantes de stratégie de groupe
Raccourcis de stratégie de groupe
Stratégie de groupe internet Paramètres
Menu Démarrer de la stratégie de groupe Paramètres
Options régionales de stratégie de groupe
Options d’alimentation de stratégie de groupe
Événements de préférences de stratégie de groupe
ÉVÉN EM EN T S SEVERIT Y M ESSA GE
MessageId=0x1000 (4096) Opération réussie L’élément de préférence %1 « %2 »

dans l’objet de stratégie de groupe «
%3 » s’est correctement appliqué.
MessageId=0x1002 (4098) Avertissement L’élément de préférence %1 « %2 »

%3 » ne s’est pas appliqué car il a
échoué avec le code d’erreur « %4
'%%100790273
MessageId=0x1003 (4099) Avertissement L’extension côté client n’a pas pu

enregistrer les données RSoP car elle a
échoué avec le code d’erreur « %1 ».
MessageId=0x1004 (4100) Opération réussie Service arrêté.
MessageId=0x1005 (4101) Opération réussie L’élément de préférence %1 « %2 »

%3 » a été supprimé avec succès.
MessageId=0x1006 (4102) Avertissement Diagnostic ODBC (%1), %2

obtenir les éléments de préférence %1
%2 pour l’objet de stratégie de groupe
« %3 » car Windows s’arrête ou
l’utilisateur se dé connecte.

%3 » ne s’est pas appliqué car un
élément de ciblage a échoué avec le
code d’erreur « %4'%%100790273 ».
MessageId=0x100A (4106) Avertissement L’élément de préférence %1 « %2 »

%3 » ne s’est pas appliqué car son
code d’erreur « %4'%%100790273 ».
MessageId=0x1013 (4115) Opération réussie Service démarré.

%3 » ne s’est pas appliqué car il a
»%%100790275.
ÉVÉN EM EN T S SEVERIT Y M ESSA GE

%3 » ne s’est pas appliqué car son
code d’erreur « %4'%%100790275 ».

définir les paramètres de stratégie %1
%2 pour « %3 » car elle a échoué avec
le code d’erreur « %4 '%%100790275
».
Dans Windows XP et Windows Server

2003 des préférences de stratégie de
groupe, l’ID d’événement 8194
présente une gravité d’erreur au lieu
d’avertissement.
MessageId=0x2004 (8196) Avertissement L’extension côté client a capturé

l’exception non prise en main « %1 » à
l’intérieur : « %2'%%100790275 .

%3 » n’a pas été supprimé car il a
'%%100790275 ».

%3 » ne s’est pas appliqué car un
code d’erreur « %4'%%100790275 ».
MessageId=0x201D (8221) Avertissement Une erreur s’est produite lors de

l’écriture dans le fichier de suivi. Erreur
%1.
MessageId=0x2023 (8227) Avertissement Le processus a lancé l’exception %1 à

l’intérieur de %2.
MessageId=0x2024 (8228) Avertissement Erreur %1 lors de l’obtention du

message de diagnostic ODBC.
MessageId=0x2025 (8229) Avertissement Erreur ODBC %1, %2.
MessageId=0x1A00 (6656) Opération réussie Un filtre masqué n’a pas réussi.
MessageId=0xF001 (61441) Opération réussie Cette erreur a été supprimée.%0
MessageId=0xF003 (61441) Opération réussie Voir le fichier de suivi pour plus

d’informations.%0
Comment modifier les autorisations par défaut sur
les G GPO dans Windows Server
Cet article explique comment modifier les autorisations par défaut sur les objets de stratégie de groupe (G
OBJETS).
Résumé
Vous souhaitez peut-être renforcer la sécurité sur les G STRATÉGIE de groupe pour empêcher tout groupe
d’administrateurs, sauf un groupe approuvé, de modifier la stratégie de groupe. Vous pouvez le faire en
modifiant l’attribut DefaultSecurityDescriptor sur l’objet classScema du conteneur de stratégie de groupe.
Toutefois, la modification affecte uniquement les G GPO nouvellement créés. Pour les G STRATÉGIE de groupe
existantes, vous pouvez modifier les autorisations directement sur le conteneur de stratégie de groupe (CN=
{GPO_GUID},CN=Système,DC=domaine...) et le modèle de stratégie de groupe ( \ \ stratégies SYSVOL de
domaine \ \ \ {GPO_GUID}). Cette procédure permet également d’empêcher la mise à jour accidentelle des
modèles d’administration (fichiers ADM) des modèles de stratégie de groupe par les fichiers ADM sur les
stations de travail non gestion.
Lorsqu’un nouvel objet Active Directory est créé, les autorisations spécifiées dans l’attribut
DefaultSecurityDescriptor de son objet classSchema dans le schéma lui sont appliquées. Pour cette raison,
lorsqu’un objet de stratégie de groupe est créé, son objet groupPolicyContainer reçoit sa ACL de l’attribut
DefaultSecurityDescriptor dans cn=Group-Policy-Container,CN=Schema,CN=Configuration,DC=forestroot... .
L’éditeur de stratégie de groupe applique également ces autorisations au dossier, aux sous-dossiers et aux
fichiers dans le modèle de stratégie de groupe (Stratégies SYSVOL \ \ {GPO_GUID}).
Vous pouvez utiliser le processus suivant pour modifier l’attribut DefaultSecurityDescriptor de l’objet
classSchema de conteneur de stratégie de groupe. Comme il s’agit d’un changement de schéma, il démarre une
réplication complète pour tous les GCs dans la forêt. Les autorisations de schéma sont écrites à l’aide du langage
SDDL (Security Descriptor Definition Language). Pour plus d’informations sur SDDL, visitez le site Web
Microsoft suivant :
Langage de définition du descripteur de sécurité
Pour modifier l’attribut DefaultSecurityDescriptor pour l’objet classSchema de conteneur de stratégie de groupe :
1. Connectez-vous au contrôleur de domaine du contrôleur de schéma de forêt avec un compte membre du
groupe Administrateurs de schéma.
2. Démarrez Mmc.exe, puis ajoutez le logiciel en snap-in Schéma.
3. Cliquez avec le bouton droit sur Schéma Active Director y, puis cliquez sur Operations Master .
4. Cliquez sur Le schéma peut être modifié sur ce contrôleur de domaine, puis cliquez sur OK .
5. Utilisez ADSI Editor pour ouvrir le contexte d’appellation de schéma, puis recherchez l’objet CN=Group-
Policy-Container avec le type classSchema.
6. Affichez les propriétés de l’objet, puis recherchez l’attribut defaultSecurityDescriptor.
7. Collez la chaîne suivante dans la valeur pour supprimer les autorisations d’écriture pour les
administrateurs de domaine afin que seuls les administrateurs d’entreprise ont des autorisations
d’écriture :
D:P(A;CI;RPLCLOLORC;;;DA)(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;CO)
(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-
00a0c968f939;;AU)
Pour accorder à un groupe supplémentaire des autorisations d’écriture, ajoutez le texte suivant à la fin du
texte précédent :
(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;; <Group_SID>)
<Group_SID> est le SID du groupe auquel vous accordez des autorisations.
NOTE
La modification de l’attribut defaultSecurityDescriptor ne modifie pas les descripteurs de sécurité pour les GCO
pré-existants. Vous pouvez toutefois utiliser la chaîne complète ci-dessus pour remplacer la liste de contrôle
d’accès sur les GCO pré-existants conjointement avec un outil tel que sdutil.exe.
8. Collez la nouvelle chaîne dans la zone d’attribut d’édition, cliquez sur Définir, cliquez sur Appliquer, puis
sur OK.
NOTE
Si vous essayez de restreindre l’accès aux administrateurs de domaine ou d’entreprise, vous devez placer un refus
dans les autorisations de schéma par défaut pour l’objet Grouppolicycontainer. Ces groupes ajoutent une ACL
addional à l’objet de stratégie de groupe lors de sa création. Pour les administrateurs de domaine, vous devez
ajouter administrateurs de domaine et administrateurs d’entreprise ajouter Administrateur. L’ajout d’un refus est le
seul moyen de restiricter ces groupes.
Support technique pour les versions x64 de Windows

DFSR SYSVOL ne parvient pas à migrer ou
répliquer, SYSVOL non partagé, ID d’événement
8028 ou 6016
Cet article fournit une solution aux problèmes où la réplication du système de fichiers distribués (DFSR) ne
parvient pas à migrer ou à répliquer, ou SYSVOL SYSVOL n’est pas partagée.
Symptômes
Scénario 1 : Après le démarrage d’une migration du service de réplication de fichiers (FRS) vers DFSR, aucun
contrôleur de domaine n’entre dans la phase préparée et reste bloqué lors de SYSVOL la préparation. Ce
problème se poursuit même après que vous avez vérifié que la réplication Active Directory (AD) a convergé sur
tous les contrôleurs de domaine. Le problème persiste même sur les DCS dans le même site AD que PDCE, où la
réplication AD se produit toutes les 15 secondes et où vous avez exécuté DFSRDIAG.EXE POLL AD sur tous les
DCS. L’exécution /GETMIGRATIONSTATE de la commande de rapport indique :
DFSRMIG.EXE /GETMIGRATIONSTATE
Contrôleur de domaine (état de migration local) - Type dc
===================================================
2008R2-MIG-01 ('Preparing') - Primary DC
2008R2-MIG-02 ('Preparing') - Writable DC
La migration n’a pas encore atteint un état cohérent sur tous les contrôleurs de domaine.
Les informations d’état peuvent être obsolètes en raison de la latence AD.
L’examen du signe d’événement de réplication DFS dans le contrôleur de domaine principal (PDC) Emulator
affiche :
Log Name: DFS Replication

Source: DFSR
Date: <DateTime>
Event ID: 8028
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: 2008r2-mig-01.cohowinery.com
Description:
DFSR Migration was unable to transition to the 'PREPARED' state for Domain Controller 2008R2-MIG-01. DFSR
will retry the next time it polls the Active Directory. To force an immediate retry, execute the command
'dfsrdiag /pollad'.
Domain Controller: 2008R2-MIG-01
Error: 5 (Access is denied.)
L’examen du signe débogage DFSR dans la PDCE indique :

<DateTime> 1524 CFAD 2836 Config::AdObjectEditor::AddObject Add cn=DFSR-LocalSettings,CN=2008R2-MIG-
01,OU=Domain
Controllers,DC=cohowinery,DC=com
<DateTime> 1524 ADWR 633
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [SYSVOL] Local settings object already exists.
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [SYSVOL] Got Local Setting's SD for adding ACE
Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [SYSVOL] Going to set new SD
<DateTime> 1524 CFAD 2570 [ERROR] Config::AdAttrEditor::ModifyValue Failed to ldap_modify_s(). dn:cn=DFSR-
LocalSettings,CN=2008R2-MIG-01,OU=Domain Controllers,DC=cohowinery,DC=com Error:Insufficient Rights
<DateTime> 1524 SYSM 586 [ERROR] Migration::SysvolMigrationTask::Step [MIG] Failed Migration task.Error:
+ [Error:5(0x5) Migration::SysVolMigration::Migrate migrationserver.cpp:1200 1524 W Access is denied.]
+ [Error:5(0x5) Migration::SysVolMigration::StepToNextStableState migrationserver.cpp:1271 1524 W Access is
denied.]
+ [Error:5(0x5) Migration::SysVolMigration::Prepare migrationserver.cpp:1431 1524 W Access is denied.]
+ [Error:5(0x5) Migration::SysVolMigration::CreateLocalAdObjects migrationserver.cpp:2694 1524 W Access is
denied.]
+ [Error:5(0x5) Config::AdWriter::CreateSysVolMigrationLocalObjects adwriterserver.cpp:1965 1524 W Access is
denied.]
+ [Error:5(0x5) Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc adwriterserver.cpp:726 1524 W Access is
denied.]
+ [Error:5(0x5) Config::AdAttrEditor::ReplaceValue ad.cpp:2702 1524 W Access is denied.]
+ [Error:5(0x5) Config::AdAttrEditor::ModifyValue ad.cpp:2578 1524 W Access is denied.]
+ [Error:50(0x32) Config::AdAttrEditor::ModifyValue ad.cpp:2578 1524 U Insufficient Rights]
Scénario 2 : Un domaine réplique déjà à SYSVOL l’aide de DFSR. Lorsqu’un nouveau dc est promu, il ne
parvient pas à répliquer et les partages et les SYSVOL SYSVOL NETLOGON partages ne sont pas créés.
L’examen de la signature d’événement de réplication DFS dans ce nouveau dc affiche :
Log Name: DFS Replication

Source: DFSR
Date: <DateTime>
Event ID: 6016
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: 2008-R2-TSPDC2.tailspintoys.com
Description:
The DFS Replication service failed to update configuration in Active Directory Domain Services. The service
will retry this operation periodically.
Object Category: msDFSR-LocalSettings
Object DN: CN=DFSR-LocalSettings,CN=2008-R2-TSPDC2,OU=Domain Controllers,DC=tailspintoys,DC=com**
Error: 5 (Access is denied.)
Domain Controller: 2008-R2-TSPDC1.tailspintoys.com
Polling Cycle: 60
L’examen du signe débogage DFSR dans ce dc indique :

<DateTime> 1712 CFAD 2836 Config::AdObjectEditor::AddObject Add cn=DFSR-LocalSettings,CN=2008-R2-
TSPDC2,OU=Domain Controllers,DC=tailspintoys,DC=com
<DateTime> 1712 ADWR 633 Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [`SYSVOL`] Local settings
object already exists.
<DateTime> 1712 ADWR 655 Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [`SYSVOL`] Got Local
Setting's SD for adding ACE
<DateTime> 1712 ADWR 678 Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc [`SYSVOL`] Going to set new
SD
<DateTime> 1712 CFAD 2570 [ERROR] Config::AdAttrEditor::ModifyValue Failed to ldap_modify_s(). dn:cn=DFSR-
LocalSettings,CN=2008-R2-TSPDC2,OU=Domain Controllers,DC=tailspintoys,DC=com Error:Insufficient Rights
<DateTime> 1712 CFAD 11508 [ERROR] Config::AdReader::Read [SYSVOL] (Ignored) Failed to create SysVol
objects, Error:
+ [Error:5(0x5) Config::AdWriter::CreateSysVolObjects adwriterserver.cpp:1360 1712 W Access is denied.]
+ [Error:5(0x5) Config::AdWriter::CreateSysVolObjectsWithParams adwriterserver.cpp:1457 1712 W Access is
denied.]
+ [Error:5(0x5) Config::AdWriter::CreateSysVolLocalObjectsOnLocalDc adwriterserver.cpp:726 1712 W Access is
denied.]
+ [Error:5(0x5) Config::AdAttrEditor::ReplaceValue ad.cpp:2702 1712 W Access is denied.]
+ [Error:5(0x5) Config::AdAttrEditor::ModifyValue ad.cpp:2578 1712 W Access is denied.]
+ [Error:50(0x32) Config::AdAttrEditor::ModifyValue ad.cpp:2578 1712 U Insufficient Rights]
L’examen du signe de débogage DFSR dans la PDCE indique :
<DateTime> 1792 CFAD 6160 [ERROR] Config::AdSnapshot::BuildPartnersSubTree Failed to create computer tree
for partner:CN=2008-R2-TSPDC2,CN=Topology,CN=Domain System Volume,CN=DFSR-
GlobalSettings,CN=System,DC=tailspintoys,DC=com, Error:
+ [Error:1168(0x490) Config::AdSnapshot::BuildPartnerComputerSubTree ad.cpp:6018 1792 W Element not found.]
+ [Error:1168(0x490) Config::AdSnapshot::BuildLocalSettingsTree ad.cpp:6408 1792 W Element not found.]
+ [Error:1168(0x490) Config::AdSnapshot::GetSubscriber ad.cpp:4112 1792 W Element not found.]
+ [Error:1168(0x490) Config::AdSnapshot::GetSubscriber ad.cpp:4108 1792 W Element not found.]
Cause
L’attribution de droits d’utilisateur par défaut « Gérer le journal d’audit et de sécurité » (SeSecurityPrivilege) a
été supprimée du groupe Administrateurs intégré. La suppression de ce droit d’utilisateur des administrateurs
sur les contrôleurs de domaine n’est pas prise en charge. Cela entraîne l’échec de la migration DFSR. SYSVOL
Migration de DFSR et doit être exécuté par un utilisateur membre du groupe Administrateurs intégré dans ce
domaine. Tous les PC sont automatiquement membres du groupe Administrateurs intégré.
Résolution
Pour résoudre le problème, suivez toutes les étapes de l’ordre, à l’aide d’une invite CMD avec élévation de
privilèges lors de l’exécution en tant qu’administrateur de domaine :
Scénario 1 :
1. Déterminez la stratégie de groupe de sécurité qui applique ce paramètre aux PC en exécutant PDCE :
GPRESULT.EXE /H secpol.htm
2. Ouvrez secpol.htm dans un navigateur web, puis sélectionnez Afficher tout. Recherchez l’entrée
Gérer le journal d’audit et de sécurité. Il liste la stratégie de groupe qui applique ce paramètre.
3. À l’aide de GPMC.MSC , modifiez cette stratégie de groupe pour inclure les administrateurs de
groupe.
4. Autorisez AD et SYSVOL la réplication à converger sur tous les DCS. Sur la PDCE, exécutez :
GPUPDATE /FORCE
5. Déconnectez-vous de la PDCE et connectez-vous pour mettre à jour votre jeton de sécurité avec
l’affectation de droit de l’utilisateur.
6. Exécutez :
DFSRMIG.EXE /CREATEGLOBALOBJECTS
7. Autorisez AD et SYSVOL la réplication à converger sur tous les DCS. Sur la PDCE, exécutez :
DFSRDIAG.EXE POLLAD
DFSRMIG.EXE /GETMIGRATIONSTATE
8. Vérifier que tout ou partie des DCS ont atteint l’état préparé et sont prêts à être redirigés. À ce stade, vous
pouvez procéder normalement à la migration. Consultez la section Plus d’informations ci-dessous.
Scénario 2 :
1. Déterminez la stratégie de groupe de sécurité qui applique ce paramètre aux PC en exécutant PDCE :
GPRESULT.EXE /H secpol.htm
2. Ouvrez secpol.htm dans un navigateur web, puis sélectionnez Afficher tout. Recherchez l’entrée
Gérer le journal d’audit et de sécurité. Il liste la stratégie de groupe qui applique ce paramètre.
3. À l’aide de GPMC.MSC , modifiez cette stratégie de groupe pour inclure les administrateurs de
groupe.
4. Autorisez AD et SYSVOL la réplication à converger sur tous les DCS. Sur le dc affecté, exécutez :
GPUPDATE /FORCE
5. Redémarrez le service DFSR sur ce dc.

6. Validez que le dc partage maintenant SYSVOL et NETLOGON et réplique les SYSVOL données entrantes.
Il est possible que le partage sysvol ne soit pas possible sur les DCS. Ce qui vous empêche de modifier ou
d’appliquer une stratégie de groupe. Comme solution de contournement, vous pouvez partager manuellement
le droit d’utilisateur « Gérer le journal d’audit et de sécurité » et forcer une mise à jour sysvol de la gp.
Étapes :
1. Partager manuellement sysvol la valeur - Modifier cette valeur de Registre
Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\parameters
Valeur SysvolReady = 1
exécutez le partage net pour vous assurer sysvol qu’il est partagé.
2. Ouvrez la stratégie et ajoutez l’utilisateur ou le groupe au droit d’utilisateur « Gérer le journal d’audit et
de sécurité ».
3. Exécutez :
gpupdate force.
NOTE
Vous de devez peut-être partager à nouveau le sysvol à l’étape 3, car un processus en arrière-plan de la migration
peut le partager avant d’avoir terminé la modification SYSVOL de la stratégie.
4. Poursuivez avec le scénario 1 ou 2, comme indiqué ci-dessus.

Il est possible pour DFSNBG de mettre à jour AD avec succès, mais ne parviennent pas à mettre à jour le
Registre. Si les mises à jour AD sont correctement réalisées pour créer le groupe de réplication sysvol mais que
le registre modifie le service DFSR n’est pas effectué en raison de droits d’utilisateur manquants, vous verrez
uniquement les événements 8010 que la migration est en cours.
Il est normal que les DCS restent à l’état préparation pendant une période prolongée pendant une migration, en
particulier dans les environnements plus grands où la réplication AD peut prendre plusieurs heures ou jours
pour converger. Il n’est pas normal qu’ils restent dans cet état même une fois que la réplication AD a atteint ces
DCS et que 15 minutes se sont écoulées pour l’interrogation AD DFSR.
Ne partagez pas SYSVOL et NETLOGON manuellement pour contourner ce problème. Ne définissez pas
SYSVOLREADY=1 pour contourner ce problème. Ainsi, le dc se contacte lui-même pour la stratégie de groupe.
Étant donné qu’il ne peut pas remplir son , les modifications apportées pour corriger les droits SYSVOL
d’utilisateur ne seront pas appliquées.
Pour plus d’informations sur la réduction du temps de convergence de réplication AD à l’aide de la notification
de modification intersite, consultez l’Annexe B - Référence des procédures.
Pour plus d’informations sur la migration de FRS vers DFSR, voir Migrer la réplication SYSVOL vers la SYSVOL
réplication DFS.
Message « Les autorisations pour cet GPO dans le
dossier sysvol sont incohérentes avec celles d’Active
Directory » lorsque vous exécutez gpMC
Cet article fournit de l’aide pour corriger les erreurs qui se produisent lorsque vous exécutez la Console de
gestion des stratégies de groupe (GPMC).
Symptômes
Lorsque vous exécutez gpMC dans un domaine Microsoft Windows Server, puis que vous cliquez sur Stratégie
de domaine par défaut ou Stratégie des contrôleurs de domaine par défaut, vous recevez l’un des messages
suivants :
Si vous êtes autorisé à modifier la sécurité sur les objets de stratégie de groupe, vous recevez le message
suivant :
Les autorisations pour cet GPO dans le dossier sysvol sont incohérentes avec celles d’Active Directory.
Il est recommandé que ces autorisations soient cohérentes. Pour modifier les autorisations dans
SYSVOL sur celles d’Active Directory, cliquez sur OK
Si vous n’êtes pas autorisé à modifier la sécurité sur les objets de stratégie de groupe, vous recevez le
message suivant :
Les autorisations pour cet GPO dans le dossier sysvol sont incohérentes avec celles d’Active Directory.
Il est recommandé que ces autorisations soient cohérentes. Contactez un administrateur qui dispose
des droits pour modifier la sécurité de cet GPO.
Cause
Ce problème se produit car la liste de contrôle d’accès (ACL) sur la partie Sysvol de l’objet de stratégie de groupe
est définie pour hériter des autorisations du dossier parent.
Statut
S’applique à » de cet article.
Si vous êtes autorisé à modifier la sécurité sur les G GPO par défaut, cliquez sur OK en réponse au message
décrit dans la section « Symptômes ». Cette action modifie les ACA sur la partie Sysvol de l’objet de stratégie de
groupe et les rend cohérentes avec les ACA sur le composant Active Directory. Dans ce cas, la stratégie de
groupe supprime l’attribut d’héritage dans le dossier Sysvol
Chaque objet de stratégie de groupe (GPO) est stocké en partie dans le dossier Sysvol sur le contrôleur de
domaine et en partie dans le service d’annuaire Active Directory. La GMC, l’Éditeur d’objets de stratégie de
groupe et l’ancienne interface utilisateur de stratégie de groupe fournies dans les logiciels en snap-in Active
Directory présentent et gèrent un objet de stratégie de groupe en tant qu’unité unique. Par exemple, lorsque
vous définissez des autorisations sur un objet de stratégie de groupe dans gpmc, gpmc définit des autorisations
sur les objets à la fois dans Active Directory et dans le dossier Sysvol. Pour chaque GPO, les autorisations dans
Active Directory doivent être cohérentes avec les autorisations dans le dossier Sysvol. Vous ne devez pas
modifier ces objets distincts en dehors de la GPMC et de l’Éditeur d’objets de stratégie de groupe. Si vous le
faites, cela peut entraîner l’échec du traitement de la stratégie de groupe sur le client, ou certains utilisateurs qui
ont généralement accès ne peuvent plus modifier un GPO.
En outre, les objets système de fichiers et les objets du service d’annuaire ne disposent pas des mêmes
autorisations disponibles, car il s’agit de différents types d’objets. Lorsque les autorisations ne correspondent
pas, il peut ne pas être facile de les rendre cohérentes. Pour vous aider à vous assurer que la sécurité pour Active
Directory et pour les composants Sysvol d’un GPO est cohérente, gpmc vérifie automatiquement la cohérence
des autorisations de tout GPO lorsque vous cliquez sur l’GPO dans GPMC. Si la GpMC détecte un problème avec
un GPO, vous recevez l’un des messages décrits dans la section « Symptômes », selon que vous avez ou non les
autorisations pour modifier la sécurité de cet GPO.
Comment forcer la synchronisation faisant autorité
et non faisant autorité pour la réplication sysvol
répliquée par DFSR
Cet article explique comment forcer une synchronisation faisant autorité et non faisant autorité pour la
réplication sysvole répliquée par DFSR.
Résumé
Vous souhaitez forcer la synchronisation non faisant autorité de la réplication sysvole sur un contrôleur de
domaine (DC). Dans le service de réplication de fichiers (FRS), il était contrôlé par les valeurs de données D2 et
D4 pour les valeurs du Registre, mais ces valeurs n’existent pas pour le service de réplication du système de
fichiers Bur Flags distribués (DFSR). Vous ne pouvez pas utiliser le logiciel enfichable DFS Management
(Dfsmgmt.msc) ou l’outil en ligne de commande Dfsradmin.exe pour y parvenir. Contrairement aux dossiers
répliqués par DFS personnalisés, la réplication sysvol est intentionnellement protégée contre toute modification
par le biais de ses interfaces de gestion afin d’éviter les accidents.
Comment effectuer une synchronisation non faisant autorité de la

réplication sysvol répliquée par DFSR (comme D2 pour FRS)
1. Dans l’ADSIEDIT. L’outil MSC modifie la valeur et l’attribut DN (Distinguished Name) suivants sur chacun
des contrôleurs de domaine (DCS) que vous souhaitez rendre non faisant autorité :
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain

Controllers,DC=<domain>
msDFSR-Enabled=FALSE
2. Forcer la réplication Active Directory dans l’ensemble du domaine.

niveaux sur les serveurs que vous avez définies comme ne faisant pas autorité :
DFSRDIAG POLLAD
4. Vous verrez l’ID d’événement 4114 dans le journal des événements DFSR indiquant que la réplication
sysvole n’est plus répliquée.
5. Sur le même DN de l’étape 1, définissez msDFSR-Enabled=TRUE .
6. Forcer la réplication Active Directory dans l’ensemble du domaine.
niveaux sur les serveurs que vous avez définies comme ne faisant pas autorité :
DFSRDIAG POLLAD
8. Vous verrez l’ID d’événement 4614 et 4604 dans le journal des événements DFSR indiquant que la
réplication sysvole a été initialisée. Ce contrôleur de domaine a maintenant effectué une réplication
sysvol D2.
Comment effectuer une synchronisation faisant autorité de la

réplication sysvol répliquée par DFSR (comme D4 pour FRS)
1. Définissez le type de démarrage du service de réplication DFS sur Manuel et arrêtez le service sur tous
les contrôleurs de domaine dans le domaine.
2. Dans l’ADSIEDIT. L’outil MSC, modifiez le DN suivant et deux attributs sur le contrôleur de domaine que
vous souhaitez faire autorité (de préférence le Emulator PDC, qui est généralement le plus à jour pour le
contenu de réplication sysvol) :
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain

Controllers,DC=<domain>
msDFSR-options=1
3. Modifiez le DN et l’attribut unique suivants sur tous les autres contrôleurs de domaine de ce domaine :
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server

name>,OU=Domain Controllers,DC=<domain>
4. Forcez la réplication Active Directory dans l’ensemble du domaine et validez sa réussite sur tous les DCS.
5. Démarrez le service DFSR sur le contrôleur de domaine qui a été définie comme faisant autorité à l’étape
2.
sysvole n’est plus répliquée.
7. Sur le même DN de l’étape 1, définissez msDFSR-Enabled=TRUE .
8. Forcez la réplication Active Directory dans l’ensemble du domaine et validez sa réussite sur tous les DCS.
9. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de niveaux sur le
serveur que vous définissez comme faisant autorité :
DFSRDIAG POLLAD
sysvol a été initialisée. Ce contrôleur de domaine a maintenant effectué une réplication sysvol D4.
11. Démarrez le service DFSR sur les autres DCS ne faisant pas autorité. Vous verrez l’ID d’événement 4114
dans le journal des événements DFSR indiquant que la réplication sysvole n’est plus répliquée sur chacun
d’eux.
12. Modifiez le DN et l’attribut unique suivants sur tous les autres contrôleurs de domaine de ce domaine :
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server

name>,OU=Domain Controllers,DC=<domain>
msDFSR-Enabled=TRUE
13. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de niveau élevé sur
tous les DCS ne faisant pas autorité (à l’aide de l’ensemble des DCS faisant autorité auparavant) :
DFSRDIAG POLLAD
14. Renvoyer le service DFSR à son type de démarrage d’origine (automatique) sur tous les DCS.
Si vous devez définir l’indicateur faisant autorité sur un dc, vous devez synchroniser tous les autres DCS du
domaine sans faire autorité. Dans le cas contraire, vous verrez des conflits sur les DCS, provenant de n’importe
quel DCS pour lequel vous n’avez pas mis auth/non auth et redémarré le service DFSR. Par exemple, si tous les
scripts d’accès ont été supprimés accidentellement et qu’une copie manuelle de ces scripts a été placée sur le
titulaire du rôle PDC Emulator, le fait de faire autorité sur ce serveur et sur tous les autres serveurs ne faisant
pas autorité garantirait le succès et empêcherait les conflits.
Si vous faites autorité sur un dc, il est préférable que le PDC Emulator faisant autorité, car son contenu de
réplication sysvol est le plus à jour.
L’utilisation de l’indicateur faisant autorité n’est nécessaire que si vous devez forcer la synchronisation de tous
les DCS. Si vous réparez uniquement un dc, faites-le ne pas faire autorité et ne touchez pas les autres serveurs.
Cet article est conçu avec un environnement 2D à l’esprit, pour des raisons de simplicité de description. Si vous
avez plusieurs dc affectés, développez les étapes pour les inclure toutes également. Cela suppose également que
vous avez la possibilité de restaurer des données qui ont été supprimées, écrasées, endommagées, etc.
auparavant s’il s’agit d’un scénario de récupération d’urgence sur tous les DCS du domaine.
Comment réduire la taille de SYSVOL en
supprimant des modèles d’administration (fichiers
.adm)
Cet article explique comment réduire la taille de SYSVOL en supprimant des modèles d’administration (fichiers
.adm).
Résumé
Pour les domaines avec de nombreuses stratégies et les contrôleurs de domaine avec des lignes de réseau large
(WAN) lentes, la réplication du partage SYSVOL peut prendre beaucoup de temps. Il est most noticeable lorsque
vous faites la promotion d’un nouveau contrôleur de domaine à un emplacement avec une connectivité lente ou
lorsque vous exécutez une restauration non faisant autorité de SYSVOL. Pour accélérer le processus, réduisez le
nombre de fichiers et la quantité de données qui doivent être répliquées dans le partage SYSVOL.
Étant donné que les modèles d’administration (c’est-à-dire les fichiers .adm) prennent le plus d’espace dans les
stratégies, supprimez-les pour réduire considérablement la taille de SYSVOL. Par exemple, avec les modèles
d’administration par défaut, chaque stratégie prend jusqu’à 870 kilo-octets (Ko) d’espace disque. Si vous avez 1
300 stratégies, vous pouvez réduire la taille de SYSVOL de 1 100 mégaoctets (Mo) à 35 Mo (ou 27 Ko par
stratégie).
Vous pouvez utiliser les paramètres de stratégie de groupe pour modifier le comportement de l’Éditeur de
stratégie de groupe concernant les fichiers .adm dans Microsoft Windows Server 2003. Pour plus
d’informations, voir Recommandations pour la gestion des fichiers de modèle d’administration de stratégie de
groupe (.adm).
Seul l’ordinateur que vous ciblez avec l’Éditeur d’objets de stratégie de groupe doit avoir les modèles
d’administration. Par défaut, il s’agit de l’émulateur du contrôleur de domaine principal (PDC).
La suppression des fichiers ADM de la réplication SYSVOL est un processus en trois étapes.
1. Les fichiers ADM doivent être supprimés des stratégies.
2. Un filtre est définie dans FRS ou DFSR pour SYSVOL afin que les fichiers ADM ne soient plus répliqués.
3. Les fichiers ADM sont copiés dans le SYSVOL sur le PDC Emulator.
Étape 1 : Supprimer les fichiers ADM
Un moyen simple de supprimer des modèles d’administration si vous n’avez pas ajouté de modèles spéciaux ou
personnalisés consiste à rechercher des fichiers *.adm dans l’Explorateur sur l’émulateur PDC. Tez les résultats
par nom, puis supprimez tous les dossiers modèles d’administration. Une fois ces modifications apportées,
patientez jusqu’à ce que le processus de réplication ait correctement répliqué les modifications apportées aux
autres contrôleurs de domaine. Pour terminer le processus, définissez le filtre pour les modèles d’administration.
Si vous avez des modèles d’administration personnalisés, copiez-les dans une structure de répertoire différente.
Pour obtenir de meilleurs résultats, utilisez l’utilitaire robust File Copy (Robocopy.exe) du Kit de ressources. La
syntaxe de la commande est la suivante :
robocopy PDC sysvol backup_directory *.adm /s /mov
Voici un exemple de commande pour copier des modèles d’administration personnalisés dans une structure de
répertoire différente :
robocopy \\mydom-pdc\sysvol\mydom.com\policies c:\sysvol-adm-backup\ *.adm /s /mov
Après avoir exécutez cette commande pour supprimer le fichier ADM des stratégies dans le SYSVOL, la
modification est répliquée sur tous les autres DCS du domaine. Attendez que la réplication des fichiers se
termine avant de procéder à l’étape 2.
NOTE
Sauvegardez votre Sysvol avant d’apporter des modifications à la structure de fichiers
Étape 2 : Définir le filtre de réplication pour les fichiers ADM

Le système de réplication de fichiers (FRS) ou la réplication du système de fichiers distribués (DFSR) peut être
utilisé pour répliquer le SYSVOL. Utilisez la méthode correcte pour le domaine cible.
Étapes pour FRS
Vous pouvez spécifier un filtre de fichier dans l’objet FRS pour le jeu de réplicas (après avoir supprimé les
modèles d’administration). Pour obtenir de meilleurs résultats, utilisez Adsiedit.msc des outils de support.
L’attribut est fRSFileFilter. Par défaut, son contenu * est .tmp, * .bak , ~ * .
Pour modifier cet attribut :
1. Dans ADSIEDIT, recherchez l’objet suivant :
CN=Volume du système de domaine (partage SYSVOL),CN=Service de réplication de
fichiers,CN=Système,DC= your_domain
2. Dans les propriétés de l’objet, sélectionnez fRSFileFilter dans Sélectionner une propriété à afficher.
La valeur apparaît dans la ligne Valeur.
3. Sélectionnez Effacer pour porter l’attribut à la ligne Modifier l’attribut.
4. Changez cette ligne * en .tmp, * .bak , * .adm, ~ * .
5. Sélectionnez Définir .
Étapes pour la DFSR
1. Ouvrez ADSIEDIT. MSC.
2. Accédez à DC= <DominanName> ,CN=System,CN=DFSR GlobalSettings, CN=Domain System
Volume,CN=Content.
3. Cliquez avec le bouton droit sur CN=Par tage Sysvol et sélectionnez Propriétés. Recherchez l’attribut
msDFSR-FileFiler.
4. Modifiez l’attribut msDFSR-FileFiler et ajoutez ,*.ADM.
5. Sélectionnez Appliquer, puis OK.
Étape 3 : Copier les fichiers ADM vers le SYSVOL du PDC
Vous pouvez ensuite utiliser l’utilitaire robust File Copy pour copier les dossiers de modèles d’administration
dans les dossiers guid si vous le souhaitez. La syntaxe de la commande est la suivante :
robocopy backup_directory PDC sysvol /s
Voici un exemple de commande pour copier les dossiers de modèles d’administration dans les dossiers GUID :
robocopy c:\sysvol-adm-backup\\mydom-pdc\sysvol\mydom.com\policies /s
Techniquement, si vous n’avez pas de modèles d’administration personnalisés, vous n’avez pas besoin d’ajouter
les dossiers modèles d’administration à l’émulateur PDC. Les dossiers sont automatiquement régénérés à l’aide
des modèles d’administration locaux chaque fois qu’une personne modifie l’objet de stratégie de groupe (GPO).
Si vous déplacez le rôle d’émulateur PDC, vous pouvez également déplacer les modèles d’administration. Pour
obtenir de meilleurs résultats, utilisez l’utilitaire robust File Copy. La syntaxe de la commande est la suivante :
robocopy old_PDC_SYSVOL PDC_SYSVOL *.adm /s /mov
Voici un exemple de commande pour déplacer les modèles d’administration :

robocopy \\mydom-pdc\sysvol\mydom.com\policies \\mydom-res-pdc\sysvol\mydom.com\policies *.adm /s /mov
Si vous avez des modèles d’administration personnalisés, assurez-vous qu’ils ont des noms de fichiers uniques
dans les stratégies. Vous pouvez ensuite distribuer ces modèles d’administration à tous les ordinateurs qui
exécutent l’Éditeur d’objets de stratégie de groupe. Copiez les fichiers de modèle d’administration dans le
dossier NT \ Inf.
Sauf si vous avez des exigences spécifiques relatives aux modèles d’administration (par exemple, vous utilisez
certains modèles d’administration uniquement pour certaines stratégies), il est bon de combiner ces approches
pour avoir un ensemble complet de modèles d’administration pour modifier un GPO.
Windows 2000, Windows 2003, Windows 2003 R2 et Windows XP utilisent des fichiers ADM. Windows OSs
2008 et ultérieures utilisent des fichiers ADMX et peuvent également utiliser des fichiers ADM personnalisés.
Pour plus d’informations sur les fichiers ADMX, voir le Guide pas à pas de gestion des fichiers ADMXde stratégie
de groupe.
Comment reconstruire l’arborescence SYSVOL et
son contenu dans un domaine
L’article explique comment utiliser l’entrée de Registre Burflags pour reconstruire la copie de chaque contrôleur
de domaine de l’arborescence du volume système (SYSVOL) sur tous les contrôleurs de domaine dans un
domaine de service d’annuaire Active Directory commun.
Introduction
Le terme SYSVOL fait référence à un ensemble de fichiers et de dossiers qui résident sur le disque dur local de
chaque contrôleur de domaine dans un domaine et qui sont répliqués par le service de réplication de fichiers
(FRS). Les clients réseau accèdent au contenu de l’arborescence SYSVOL à l’aide des dossiers partagés suivants :
NETLOGON
SYSVOL
Nous recommandons la procédure décrite dans cet article en dernier recours pour restaurer l’arborescence
SYSVOL d’un domaine et son contenu. Utilisez cette procédure uniquement si vous ne pouvez pas rendre le
service FRS fonctionnel sur des contrôleurs de domaine individuels dans le domaine. Utilisez cette procédure
uniquement si le redémarrage en bloc peut être effectué plus rapidement que le dépannage et la résolution des
incohérences de réplication, et que le temps de résolution est un facteur critique.
IMPORTANT
Les contrôleurs de domaine ne feront pas de demande d’authentification de service pendant la procédure. Ce n’est que
lorsque les dossiers SYSVOL et NETLOGON sont partagés à nouveau que le contrôleur de domaine authentifiera les
demandes. Cette procédure ne doit pas être effectuée pendant les heures de pointe.
NOTE
Consultez la section Comment stabiliser temporairement l’arborescence SYSVOL du domaine de cet article pour plus
d’informations sur la stabilisation temporaire de l’arborescence SYSVOL du domaine jusqu’à ce que vous pliiez toutes les
étapes de la section Comment reconstruire le réplica SYSVOL de domaine dans les environnements d’entreprise.
Nous vous recommandons vivement de surveiller les performances et l’état de FRS à l’aide des outils d’analyse.
À l’aide des outils de surveillance, vous pouvez empêcher la nécessité d’un jeu de réplicas faisant autorité et de
restaurations non faisant autorité. En outre, à l’aide des outils d’analyse, vous pouvez fournir des informations
sur la cause première des défaillances FRS.
L’outil d’analyse Analyse est disponible en téléchargement.
La puissance de l’appareil est un outil puissant qui mesure le fonctionnement des jeux de réplicas FRS en
fournissant des évaluations d’état d’état et des informations historiques de ces ensembles. L’outil d’évaluation
est un système d’analyse sophistiqué qui utilise des fournisseurs WMI (Windows Management Instrumentation),
un service de collecte de données, une base de données Microsoft SQL Server Desktop Engine (MSDE) et une
interface utilisateur puissante.
Conseils
IMPORTANT
Utilisez les instructions suivantes pour configurer l’entrée de Registre Burflags :

Si vous démarrez le service FRS avec l’entrée de Registre Burflags définie sur D4, le service FRS traite
initialement les fichiers et dossiers sur sa copie locale de l’arborescence SYSVOL comme faisant autorité
pour le jeu de réplicas. Un seul membre d’un jeu de réplicas FRS doit être initialisé avec le paramètre D4.
Si vous démarrez le service FRS avec l’entrée de Registre Burflags définie sur D2, le service FRS effectue
une synchronisation complète des fichiers et des dossiers à partir d’un partenaire de réplication directe
ou transitive qui héberge la copie faisant autorité des fichiers et dossiers dans le jeu de réplicas.
Lorsque vous démarrez le service FRS avec l’entrée de Registre Burflags définie sur D4, la configuration
est appelée « restauration faisant autorité » pour le contenu d’un jeu de réplicas FRS, même si aucune
restauration réelle de l’état du système ne s’est produite. Pensez au paramètre D4 comme à la
reconstruction de la partie FRS du premier contrôleur de domaine dans un nouveau domaine.
Lorsque vous démarrez le service FRS avec l’entrée de Registre Burflags définie sur D2, la configuration
est appelée restauration sans référence, même si aucune restauration de l’état du système ne s’est
produite. Pensez au paramètre D2 comme à la reconstruction de la partie FRS du contrôleur de domaine
réplica comme si le contrôleur de domaine était nouveau.
Une fois que chacun des ordinateurs restaurés faisant autorité ou non a terminé l’initialisation, le frS
prend en compte les multi-maîtres.
Si vous définissez Burflags sur D4 sur un seul contrôleur de domaine et que vous définissez Burflags sur
D2 sur tous les autres contrôleurs de domaine de ce domaine, vous pouvez reconstruire l’arborescence
SYSVOL dans ce domaine. Ce processus de reconstruction en bloc est appelé redémarrage de hub, de
branche ou frs en bloc.
La section suivante répertorie les utilisations valides d’un redémarrage en bloc du jeu de réplicas SYSVOL :
Les membres d’un jeu de réplicas FRS actuellement incohérents peuvent effectuer une synchronisation
complète de tous les fichiers et dossiers dans l’arborescence SYSVOL plus rapidement que les membres
ne peuvent traiter le journal des modifications qui résident dans les journaux sortants des partenaires de
réplication en amont.
La plupart des membres d’un jeu de réplicas FRS ont des erreurs, telles que journal_wrap erreurs. Pour
plus d’informations sur journal_wrap d’erreurs de journal_wrap, voir Comment résoudre les erreurs de
journal_wrap sur les jeux de réplicas Sysvol et DFS.
La table ID de la plupart des membres du jeu de réplicas contient une description incomplète des fichiers
qui doivent être hébergés dans le jeu de réplicas.
Les fichiers de base de données FRS sont compromis en raison d’une suppression accidentelle, d’erreurs
de système de fichiers ou d’erreurs de fichier de base de données, y compris d’une altération identifiée
par les outils de validation de base de données JET.
La plupart des membres d’un jeu de réplicas FRS ne peuvent pas répliquer des fichiers et des dossiers, et
une configuration D4 ou D2 en bloc est un moyen de réinitialiser tous les membres en tant que nouveaux
membres.
NOTE
Si le frs est dans un état d’erreur sur un seul membre, vous pouvez définir BurFlags sur D2 uniquement sur ce membre
unique.
Si vous régénétez l’arborescence SYSVOL en raison de problèmes environnementaux ou si une topologie
problématique a affecté la cohérence des fichiers et des dossiers dans un jeu de réplicas FRS, seuls des avantages
temporaires peuvent se présenter. Par exemple, ce scénario se produit lorsque trop de partenaires en aval existent ou
qu’un nombre excessif de modifications ont été apportées au contenu répliqué. Dans ce cas, nous vous
recommandons de résoudre la cause première d’un problème sous-jacent. Dans le cas contraire, les problèmes qui ont
d’abord provoqué la reconstruction de l’arborescence SYSVOL peuvent se produire à nouveau.
Pour reconstruire l’arborescence SYSVOL, nous vous recommandons d’installer Windows 2000 Service Pack 3 (SP3) ou
une version ultérieure du fichier NTFRS.exe sur tous les contrôleurs de domaine basés sur Windows 2000 dans le
domaine. Si votre version du fichier NTFRS.exe est antérieure à Windows 2000 Service Pack 3, installez le dernier
Service Pack Windows 2000.
Comment recréer le jeu de réplicas SYSVOL de domaine dans les

environnements d’entreprise
Cette section explique comment reconstruire le réplica SYSVOL de domaine dans les environnements
d’entreprise.
Résumé des étapes
La liste suivante récapitule les étapes effectuées dans un redémarrage de hub ou de branche :
1. Arrêtez le frs sur tous les contrôleurs de domaine dans le domaine.
2. Déplacez tous les fichiers et dossiers qui doivent résider dans l’arborescence SYSVOL vers un dossier
temporaire sur le contrôleur de domaine de référence. Le dossier temporaire doit se trouver sur la même
partition que l’arborescence SYSVOL.
Lorsque vous déplacez des fichiers au sein d’une partition, les fichiers ne sont pas modifiés. Par
conséquent, ils conservent leurs paramètres de sécurité d’origine. Les fichiers ou dossiers qui sont des
partitions déplacées ou copiées dans ou entre des partitions héritent de la sécurité du répertoire parent
de destination. Par conséquent, toutes les délégations personnalisées de gestion des GPO peuvent être
perdues. En outre, la liste de contrôle d’accès (ACL) de la partie SYSVOL de l’objet de stratégie de groupe
est définie pour hériter des autorisations du dossier parent. Par conséquent, vous pouvez recevoir le
message d’erreur suivant lorsque vous ouvrez un GPO à l’aide de gpmc :
Directory
Si vous êtes autorisé à modifier la sécurité sur l’GPO, sélectionnez OK lorsque vous recevez ce message
d’erreur. Cette action modifie les ACA sur la partie Sysvol de l’objet de stratégie de groupe et les rend
cohérentes avec les ACA sur le composant Active Directory. Dans ce cas, la stratégie de groupe supprime
l’attribut d’héritage dans le dossier Sysvol.
3. Vérifiez les points de jonction et les dossiers requis sur chaque contrôleur de domaine dans le domaine.
4. Redémarrez le service FRS sur le contrôleur de domaine de référence avec le jeu d’entrées de Registre D4.
5. Redémarrez le service FRS sur tous les autres contrôleurs de domaine du domaine avec l’ensemble
d’entrées de Registre D2.
6. Sur le contrôleur de domaine de référence, déplacez tous les fichiers et dossiers vers le dossier racine du
jeu de réplicas. Par défaut, ce dossier est le dossier C: \ Windows \ Sysvol \ Domain.
7. Surveillez la cohérence des fichiers et des dossiers pour tous les contrôleurs de domaine dans le
domaine.
NOTE
Si un membre d’un jeu de réplicas a été redémarré avec l’entrée de Registre Burflags définie sur D4, redémarrez le service
FRS sur tous les autres membres du jeu de réplicas avec l’entrée de Registre Burflags définie sur D2. Cette configuration
empêche les dossiers morphose.
Lorsque l’entrée de Registre Burflags est définie sur D2 ou D4, et que le service FRS est redémarré, le GUID
d’origine (OrigGUID) change. Si vous souhaitez suivre la source d’une activité spécifique, vous pouvez exécuter
l’Outil de diagnostic du service de réplication de fichiers (FRSDiag) pour obtenir GUID2Name avant de définir
l’entrée de Registre Burflags.
Liste détaillée des étapes
La liste suivante indique les étapes détaillées effectuées dans un redémarrage de hub ou de branche :
1. Sur tous les contrôleurs de domaine du domaine, arrêtez le service FRS, puis définissez la valeur de type
de démarrage du service frS sur Désactivé.
2. Sur un seul contrôleur de domaine, configurez le jeu de réplicas SYSVOL pour qu’il fait autorité. Ce
contrôleur de domaine de référence contient la copie faisant autorité de l’arborescence SYSVOL pour
tous les autres membres du jeu de réplicas. Par exemple, d’autres contrôleurs de domaine dans le
domaine répliquent directement ou transitivement à partir de ce contrôleur de domaine de référence.
Choisissez le contrôleur de domaine de référence en fonction de la connectivité et des ressources de
serveur physiques. Ce contrôleur de domaine sera appelé « contrôleur de domaine de référence » dans
toutes les étapes suivantes.
Pour configurer le jeu de réplicas SYSVOL comme faisant autorité, suivez les étapes suivantes :
a. Go to Star t , select Run , type regedit, and then select OK .
b. Recherchez puis sélectionnez l’entrée BurFlags sous la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica
Sets\GUID
GUID est le GUID du jeu de réplicas de volume du système de domaine qui est illustré dans la
sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID
c. Cliquez avec le bouton droit sur BurFlags, puis sélectionnez Modifier .

d. Tapez D4 dans le champ Données de la valeur (HexaDecimal), puis sélectionnez OK .
3. Sur tous les contrôleurs de domaine du domaine, vérifiez que la structure de fichier et les points de
jonction sont corrects. Vous pouvez suivre les étapes suivantes :
a. Vérifiez que les dossiers suivants existent dans l’arborescence SYSVOL :
\SYSVOL
\Domaine \ SYSVOL
\Domaine intermédiaire \ SYSVOL \
\Zones de transit SYSVOL \
\Stratégies de domaine SYSVOL \ \
\Scripts de domaine SYSVOL \ \
\SYSVOL \ SYSVOL
b. Vérifiez que les points d’parpare suivants existent :
\Nom de domaine \ DNS SYSVOL \ SYSVOL
Ce point d’parement doit être lié au dossier de \ domaine SYSVOL. \
\Nom de domaine \ \ DNS des zones de transit SYSVOL
Ce point d’parage doit être lié au dossier de domaine \ intermédiaire SYSVOL. \ \
Le chemin d’accès par défaut de l’arborescence SYSVOL se trouve sous le dossier WINDOWS ou
WINNT sur la partition où le système \ \ d’exploitation est installé. Toutefois, l’arborescence
SYSVOL peut être installée sur n’importe quelle partition mise en forme à l’aide du système de
fichiers NTFS.
Vérifiez que chaque contrôleur de domaine dans le domaine dispose de tous les dossiers requis et
que les points d’parpare existent. Re-créez les dossiers manquants selon vos besoins. N’utilisez pas
Windows Explorer pour déplacer ou copier le contenu de l’arborescence SYSVOL, sinon les points
d’parse peuvent être endommagés.
L’arborescence SYSVOL contient des points d’parse vers d’autres dossiers dans l’arborescence SYSVOL. Ces
points d’examen sont dans le système de fichiers NTFS. Pensez à un point d’parse comme un dossier source qui
est mapré ou pointe vers un dossier de destination lorsque le dossier source est accessible. Le contenu des
dossiers reparés s’affiche sous forme d’images miroir les uns des autres.
Les deux points d’parpare suivants pour une arborescence SYSVOL sont installés dans le dossier C: \ WINNT \
SYSVOL :
C: \ WINNT \ SYSVOL \ SYSVOL \ DNS Domain Name .
Ce point d’parse est lié au dossier de domaine \ SYSVOL C: \ WINNT. \
C : \ WinNT \ SYSVOL \ staging areas \ DNS Domain Name
Ce point d’parage est lié au dossier de domaine intermédiaire \ SYSVOL C: \ \ \ WINNT.
Sur chaque contrôleur de domaine du domaine, suivez les étapes suivantes :
1. Go to Star t , select Run , type cmd, and then select OK .
2. Tapez net start ntfrs pour démarrer le service de réplication de fichiers.
3. ntfrsutl ds |findstr /i "root stage" Tapez, puis appuyez sur Entrée. La commande NTFRSUTIL renvoie
le répertoire racine actuel pour le jeu de réplicas SYSVOL appelé « racine du jeu de réplicas » et le dossier
intermédiaire. Par exemple, cette commande renvoie :
Root: C:\WINNT\SYSVOL\domain
Stage: C:\WINNT\SYSVOL\staging\domain
4. Linkd %systemroot%\SYSVOL\SYSVOL\DNS Domain name Tapez, puis appuyez sur Entrée. La commande LINKD
renvoie les informations suivantes :
Source DNS Domain Name is linked to %systemroot%\SYSVOL\domain

5. linkd "%systemroot%\SYSVOL\staging areas\DNS Domain Name" Tapez, puis appuyez sur Entrée. Cette
commande renvoie les informations suivantes :
Source DNS Domain Name is linked to %systemroot%\SYSVOL\Staging\domain
NOTE
Le chemin d’accès signalé par la commande LINKD varie en fonction de l’emplacement du dossier nom de domaine
\ \ DNS SYSVOL SYSVOL. Si le dossier SYSVOL se trouve à l’emplacement par défaut dans le dossier
%systemroot% SYSVOL, utilisez les commandes \ répertoriées. Dans le cas contraire, tapez le chemin d’accès réel
des dossiers SYSVOL.
Par exemple, si les commandes NTFRSUTL et LINKD sont exécutés sur un contrôleur de domaine dans le
domaine et que le dossier SYSVOL se trouve dans le dossier C: Windows SYSVOL, la syntaxe de
commande et les résultats pour les contoso.com \ dossiers SYSVOL et Staging s’afficheront de la même
façon que dans la sortie suivante \ :
C:\>ntfrsutl ds |findstr /i "root stage"
Résultats :
Root: C:\windows\sysvol\domain
Stage: C:\windows\\sysvol\staging\domain
C:\>Linkd %systemroot%\SYSVOL\SYSVOL\Contoso.com
Résultats :
Source domain.com is linked to C:\WINDOWS\SYSVOL\domain
C:\>linkd "%systemroot%\SYSVOL\<staging areas>\Contoso.com
Résultats :
Source domain.com is linked to C:\WINDOWS\SYSVOL\staging\domain
Pour re-créer les points de jonction si la commande LINKD signale des points de jonction manquants ou
non valides, suivez les étapes suivantes :
a. Type , où Source est le chemin d’accès racine déterminé à l’aide de la commande
linkd C:\WINNT\SYSVOL\sysvol\DNS_Domain_Name Source NTFRSUTL.
b. Type , où Source est le chemin d’accès de l’étape qui est déterminé à l’aide de
C:\linkd "C:\WINNT\SYSVOL\staging areas\DNS_Domain_Name" Source la commande NTFRSUTL.
6. Sur tous les contrôleurs de domaine du domaine, vérifiez qu’un espace de transit suffisant est disponible.
Le rapport entre la taille de la zone de transit et la taille des ensembles de données dépend d’une plage
de facteurs.
Pour déterminer la taille de la racine du jeu de réplicas, cliquez avec le bouton droit sur la racine du jeu de
réplicas qui utilise le dossier de domaine Winnt SYSVOL dans l’Explorateur Windows, puis sélectionnez \
\ Propriétés.
Pour ajuster la taille du dossier intermédiaire, suivez les étapes suivantes :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters
c. Cliquez avec le bouton droit sur Limite d’espace de transit dans la Ko, puis sélectionnez Modifier.
d. Sélectionnez la décimale, tapez la taille du dossier intermédiaire en kilo-octets, puis sélectionnez OK .
7. Sur le contrôleur de domaine de référence, créez un bon ensemble de stratégies et de scripts, puis placez-
les dans un dossier temporaire en dehors des dossiers du jeu de réplicas SYSVOL sur le contrôleur de
domaine de référence FRS.
Pour effectuer cette étape, examinez Active Directory pour déterminer les stratégies de groupe qui sont
toujours utilisées et qui contiennent des données orphelines. Les informations de stratégie se trouvent
dans le conteneur stratégies de groupe. Pour afficher ce conteneur, suivez les étapes suivantes :
a. Démarrez Utilisateurs et ordinateurs Active Directory.
b. Dans le menu Affichage, sélectionnez Fonctionnalités avancées s’il n’est pas déjà sélectionné.
c. Développez le conteneur de domaine, le conteneur système, puis le conteneur Stratégies.
Dans le volet droit des utilisateurs et ordinateurs Active Directory, tous les objets de stratégie de
groupe dans Active Directory sont répertoriés. Il doit y avoir un mappage un-à-un entre des G
GPO valides dans Active Directory avec des dossiers de stratégie de groupe dans l’arborescence
SYSVOL.
Si le dossier SYSVOL contient un nom de dossier dont le GUID n’est pas répertorié dans Active
Directory, le système de fichiers contient un GPO orphelin et vous pouvez supprimer en toute
sécurité le dossier du système de fichiers.
Si Active Directory contient un GUID de stratégie de groupe qui n’est pas mapqué à un GUID
dans le dossier des stratégies de domaine SYSVOL sur un contrôleur de domaine dans le
domaine, vous pouvez supprimer en toute sécurité ce paramètre de stratégie \ \ d’Active
Directory.
NOTE
Si un contrôleur de domaine participant au domaine possède une version plus récente d’une stratégie de
groupe dans son arborescence SYSVOL locale, assurez-vous qu’il est copié dans un emplacement
temporaire sur le contrôleur de domaine de référence.
d. Sur le contrôleur de domaine de référence, supprimez les fichiers ou dossiers qui se sont dans la
racine du jeu de réplicas FRS ou dans les dossiers de l’étape du jeu de réplicas.
Pour les jeux de réplicas SYSVOL par défaut, supprimez les fichiers et dossiers sous les deux
dossiers suivants :
C : \ domaine \ WINNT SYSVOL \
C : \ Domaine intermédiaire \ WINNT SYSVOL \ \
NOTE
Ne supprimez pas les dossiers eux-mêmes.
e. Sur le contrôleur de domaine de référence, déplacez les dossiers de stratégies et de scripts et le
contenu du dossier de l’emplacement temporaire que vous avez utilisé à l’étape c vers le dossier
racine du jeu de réplicas FRS. Pour le dossier SYSVOL, l’emplacement par défaut de la racine du jeu
de réplicas est le dossier : C : \ domaine \ WINNT SYSVOL. \
f. Sur tous les contrôleurs de domaine à l’exception du contrôleur de domaine de référence,
configurez le frS pour qu’il ne fait pas autorité. Vous pouvez suivre les étapes suivantes :
b. Recherchez puis sélectionnez l’entrée BurFlags sous la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica
Sets\GUID
GUID est le GUID du jeu de réplicas de volume du système de domaine qui est illustré dans
la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID
c. Dans le menu Edition, pointez sur Nouveau, puis sélectionnez Valeur DWORD.
d. Tapez D2 pour le nom de la DWORD, puis appuyez sur Entrée.
NOTE
Pour les contrôleurs de domaine qui ne participent pas à la réplication du système de fichiers distribués
(DFS), définissez DWORD sur D2 dans la sous-clé de Registre pour les modifications en bloc
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
atStartup\BurFlags
:
g. Quittez l’Éditeur du Registre.

Le frs est invité à réinitialiser sa base de données et à overwrite le contenu de l’arborescence SYSVOL
avec les données d’un partenaire en amont.
Dans les sites de grande taille, nous vous recommandons d’utiliser une approche échelonnée pour
reconstruire l’arborescence SYSVOL. Cette approche permet d’éviter la surcharge d’un contrôleur de
domaine unique ou la source du contenu du frS à partir d’un contrôleur de domaine qui n’a pas effectué
sa propre ré-recherche du volume système. Ce processus implique la définition de l’entrée de Registre
Burflags sur D2 sur tous les contrôleurs de domaine de site hub avant de procéder à la succursale ou aux
sites satellites.
Utilisez l’entrée de Registre Replica Set Parent pour spécifier un contrôleur de domaine source pour le
paramètre D2 :
Chemin d’accès :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\SYSVOL Seeding\DOMAIN SYSTEM
VOLUME (SYSVOL SHARE)
Nom de la valeur : jeu de réplicas parent
Type de valeur : REG_SZ
Données de valeur : contrôleur de domaine source
NOTE
Si cette entrée de Registre n’existe pas, vous devez la créer.
Il n’est pas recommandé qu’un contrôleur de domaine unique devienne la source de plus de 10 à 15
contrôleurs de domaine en même temps. Si vous devez approvisionner plus de 15 contrôleurs de
domaine à partir d’une seule source, démarrez le service FRS sur seulement 15 partenaires en aval d’un
contrôleur de domaine source particulier, puis attendez qu’ils terminent la recherche de l’arborescence
SYSVOL avant le démarrage du service FRS sur le groupe suivant de 15 ordinateurs.
NOTE
Il n’est pas recommandé que plus de 15 contrôleurs de domaine sourcent leur contenu d’un seul contrôleur de
domaine en même temps.
La réplication entrante dépend d’une planification définie sur la liaison de site pertinente ou sur l’objet de
connexion utilisé par le contrôleur de domaine de destination qui autorise la réplication. Si la planification de
réplication est désactivée, la réplication entrante est retardée.
Si l’entrée de Registre « Replica set parent » est utilisée, le service FRS source des données au redémarrage du
service, indépendamment du fait que la réplication soit activée ou désactivée le jour ou l’heure de redémarrage
du service. Une fois la source initiale terminée, toutes les réplications supplémentaires sont basées sur les
planifications de connexion. Si l’entrée de Registre n’est pas utilisée, le service FRS lance la réplication en
fonction de la planification définie sur l’objet de lien de site ou de connexion approprié.
8. Sur tous les contrôleurs de domaine du domaine à l’exception du contrôleur de domaine de référence,
supprimez les fichiers ou dossiers sous la racine du jeu de réplicas FRS et les répertoires de l’étape du jeu
de réplicas. Par exemple, pour les jeux de réplicas SYSVOL par défaut, supprimez les fichiers et les
dossiers aux deux emplacements suivants :
C : \ domaine \ WINNT SYSVOL \
C : \ Domaine intermédiaire \ WINNT SYSVOL \ \
NOTE
Ne supprimez pas les dossiers eux-mêmes.
Cette étape permet une réplication plus rapide de l’arborescence SYSVOL pour la source donnée. Cette
étape élimine la nécessité pour le serveur FRS de déplacer le contenu existant avant de répliquer les
nouvelles données. Cette étape n’est pas obligatoire, mais elle est recommandée.
9. Sur tous les contrôleurs de domaine du site hub, à l’exception du contrôleur de domaine de référence,
redémarrez FRS, puis vérifiez que SYSVOL et NETLOGON sont partagés.
NOTE
Le type de démarrage de service pour le service FRS doit être définie sur Automatique .
10. Sur tous les contrôleurs de domaine non référencés dans les sites de succursale, démarrez le service FRS
et vérifiez que SYSVOL et NETLOGON sont partagés.
Comment stabiliser temporairement l’arborescence SYSVOL du

domaine
1. Arrêtez FRS sur tous les contrôleurs de domaine dans le domaine et définissez le service sur Désactivé.
2. Copiez manuellement l’ensemble complet des stratégies dans le dossier suivant sur chaque contrôleur de
domaine :
\Stratégies de nom de \ domaine SYSVOL SYSVOL \ dns \
En règle générale, les deux stratégies suivantes sont requises pour l’authentification :
Stratégie de contrôleurs de domaine par défaut{6AC1786C-016F-11D2-945F-00C04fB984F9}
Stratégie de domaine par défaut {31B2F340-016D-11D2-945F-00C04FB984F9}
NOTE
Vous pouvez être dans l’obligation de copier des stratégies supplémentaires en fonction des exigences de stratégie
de groupe pour l’environnement.
3. Copiez manuellement tous les scripts nécessaires dans le dossier suivant :

\Scripts de nom de domaine \ SYSVOL SYSVOL \ DNS \
Les événements 6804 et 2843 sont enregistrés et les
rodcs ne répliquent pas SYSVOL
Cet article fournit une solution à un problème dans lequel les événements 6804 et 2843 sont enregistrés
lorsque les contrôleurs de domaine en lecture seule (RODC) ne répliquent pas le répertoire partagé du volume
système (SYSVOL).
R2 Service Pack 1
Symptômes
Un ou plusieurs contrôleurs de domaine en lecture seule (RODC) ne répliquent pas le répertoire partagé du
volume système entrant (SYSVOL). This issue occurs even though multiple inbound Active Directory
connections are listed when Active Directory Sites and Services (Dssite.msc) is pointed at an affected RODC.
Lorsque ce problème se produit, l’entrée suivante est consignée dans le journal des événements DFSR :

Source : DFSR
Description :
Le service de réplication DFS a détecté qu’aucune connexion n’est configurée pour le groupe de réplication
Domain System Volume. Aucune donnée n’est répliquée pour ce groupe de réplication.
En outre, l’entrée suivante est consignée dans le journal des événements du service d’annuaire :

Catégorie de tâche : Vérification de la cohérence des connaissances
Niveau : Error
Description :
Le vérifieur de cohérence des connaissances n’a pas pu localiser une connexion de réplication pour le
service d’annuaire local en lecture seule. Une connexion de réplication avec l’option suivante doit exister
dans la forêt pour que le comportement du système FRS soit correct.
Option : 64
Restituer la connexion de réplication d’origine pour l’instance du service d’annuaire local sur une instance de
service d’annuaire accessible en ligne.
Lorsque ce problème se produit, les nouveaux SCS promus fonctionnent correctement. En outre, la
rétrogradation et la promotion d’un RODC affecté résout le problème.
NOTE
La réplication sortante ne se produit pas non plus. Toutefois, ce comportement est par conception sur un rodc.
Cause
Ce problème se produit parce qu’un administrateur a supprimé les objets « RODC Connection (FRS) générés
automatiquement » pour ces rodcs concernés. Cette action peut avoir été effectuée pour l’une des raisons
suivantes :
Un client remarque que les connexions sont nommées « FRS » et, par conséquent, pense que les connexions
ne sont plus nécessaires, car DFSR réplique SYSVOL.
L’administrateur a créé des objets de connexion manuelle par processus local. Les rodcs nécessitent un
indicateur spécial sur leurs objets de connexion pour que la réplication SYSVOL fonctionne. Si l’indicateur
n’est pas présent, SYSVOL ne fonctionne pas pour FRS ou DFSR.
Résolution
1. Connectez-vous à un dc accessible en écriture dans la forêt concernée en tant qu’administrateur
d’entreprise.
2. Démarrez Dssite.msc.
3. Accédez à un rodc affecté au sein de son site et faites défiler vers le bas jusqu’à l’objet Paramètres
NTDS.
NOTE
Il est possible qu’aucune connexion ne soit répertoriée ici ou qu’il y a des connexions créées manuellement.
4. Créez un objet de connexion et donnez-lui le même nom que l’objet par défaut. Par exemple, nommez
l’objet RODC Connection (FRS).
5. Modifiez la nouvelle connexion dans Adsiedit .msc ou à l’aide de l’onglet Éditeur d’attributs Dssite.msc.
Accédez à l’attribut options, puis entrez 0x40 dans le champ Valeur.
6. Répétez les étapes 4 et 5 pour créer d’autres connexions, si nécessaire.
7. Forcez la réplication Active Directory à sortir de ce dc vers les rodcs, ou attendez que la convergence se
produise. Lorsque le service DFSR sur le RODC voit ces connexions, SYSVOL commence à se répliquer à
nouveau.
À propos de RT (NTDSCONN_OPT_RODC_TOPOLOGY, 0x00000040)

Le bit NTDSCONN_OPT_RODC_TOPOLOGY dans l’attribut options indique si la connexion peut être utilisée pour
la réplication DRS (MS-DRDM). Lorsque la connexion est définie, elle doit être ignorée par la réplication DRS et
utilisée uniquement par la réplication FRS.
NOTE
La 0x40 est requise pour DFSR et FRS. D’autres connexions pour la réplication Active Directory sont toujours requises
séparément et elles existent localement sur le RODC.
Références
7.1.1.2.2.1.2.1.3 RODC NTFRS Connection Object
Résoudre les problèmes de partages SYSVOL et
NETLOGON manquants sur Windows contrôleurs
de domaine
Cet article décrit les étapes de résolution des problèmes à utiliser sur Windows 2000 contrôleurs de domaine
manquants de partages netlogon et sysvol.
NOTE
Résumé
Le service de réplication de fichiers (FRS) est un moteur de réplication multi-thread multi-maîtres qui remplace
le service LMREPL dans Windows NT 3.x et 4.0. Windows serveurs et contrôleurs de domaine 2000 utilisent FRS
pour répliquer la stratégie système et les scripts de connexion pour Windows 2000 et les clients de niveau
inférieur.
FRS peut également répliquer du contenu entre Windows 2 000 serveurs hébergeant les mêmes racines DFS à
tolérance de panne ou réplicas de nœuds enfants.
Les partages netlogon et sysvol manquants se produisent généralement sur les contrôleurs de domaine
répliqués dans un domaine existant, mais peuvent également se produire sur le premier contrôleur de domaine
dans un nouveau domaine. Les étapes suivantes s’adressent davantage au scénario du contrôleur de domaine
réplica, mais peuvent être appliquées au premier contrôleur de domaine du domaine en ignorant les étapes
spécifiques à la réplication.
1. Les objets de connexion NTDS existent dans les DS de chaque partenaire de réplication.
Les connexions NTDS sont des connexions à sens seul utilisées par le service d’annuaire pour répliquer
Active Directory, et le service de réplication de fichiers (FRS) pour répliquer la partie système de système
de fichiers dans le dossier SYSVOL. Le contrôleur de cohérence des connaissances (KCC) est responsable
de la création d’objets de connexion NTDS pour former une topologie bien connectée entre les
contrôleurs de domaine dans le domaine et la forêt. Au lieu des connexions automatiques, les
administrateurs peuvent également créer des objets de connexion manuels.
Utilisez le logiciel en ligne « Sites et services » (Dssite.msc) pour examiner les objets de connexion qui
existent entre l’ordinateur à problème et les contrôleurs de domaine existants. Pour que la réplication se
produise entre l’ordinateur M1 et \ \ \ \ M2, \ \ M1 \ \ \ \ \ \ doit avoir un objet de connexion entrant à
partir de M2 et M2 un objet de connexion entrant à partir de M1. Utilisez la commande « Connecter au
contrôleur de domaine... » dans Dssite.msc pour afficher et comparer chaque perspective des contrôleurs
de domaine des objets de connexion intra-domaine.
S’il n’existe aucun objet de connexion pour le nouveau membre du réplica, utilisez la commande Vérifier
la topologie de réplication dans Dssite.msc pour forcer le KCC à créer les objets de connexion
automatique nécessaires (appuyez sur F5 pour actualiser l’affichage par la suite).
Si le KCC ne parvient pas à créer des connexions automatiques, les administrateurs doivent intervenir en
construisant des objets de connexion manuels pour les contrôleurs de domaine qui n’ont aucune
connexion entrante ou sortante vers ou depuis d’autres contrôleurs de domaine dans le domaine.
Souvent, la création d’un seul objet de connexion manuelle de travail permet au KCC de créer les objets
de connexion automatique souhaités. Les connexions manuelles et/ou automatiques en double à partir
du même contrôleur de domaine dans le domaine doivent être supprimées pour éviter une configuration
de blocage de la réplication.
2. La réplication Active Directory a lieu entre les contrôleurs de domaine nouveaux et existants dans le
domaine.
Utilisez Repadmin.exe pour vérifier que la réplication Active Directory a lieu entre les contrôleurs de
domaine source et de destination dans le même domaine dans l’intervalle de réplication programmée.
Les intervalles de réplication par défaut sont de cinq minutes entre les contrôleurs de domaine dans le
même site et une fois toutes les trois heures entre les contrôleurs de domaine dans différents sites (au
minimum 15 minutes).
REPADMIN /SHOWREPS %UPSTREAMCOMPUTER%

REPADMIN /SHOWREPS %DOWNSTREAMCOMPUTER%
La réplication FRS dépend d’Active Directory pour répliquer les informations de configuration nécessaires
entre les contrôleurs de domaine dans le domaine. Si la réplication est suspecte, examinez les
événements de réplication dans l’Observateur d’événements après avoir définir l’entrée « réplication
événements » sur 5 sur les ordinateurs sources potentiels ( M1) et l’ordinateur de destination ( M2), puis
forçant la réplication de M1 à M2 et M2 à M1 à l’aide de la commande « répliquer maintenant » dans
HKEY_LOCAL_MACHINE\system\ccs\services\ntds\diagnostics\ \ \ \ \ \ \ \ \ \ \ \ \ Dssite.msc ou son équivalent
dans REPLMON.
3. Le serveur utilisé pour la source des dossiers Active Directory et SYSVOL doit avoir créé les partages
NETLOGON et SYSVOL lui-même.
Une fois que le programme Dcpromo.exe a redémarré l’ordinateur, FRS tente d’abord d’établir la source
du SYSVOL à partir de l’ordinateur identifié dans la clé de Registre « Replica Set Parent » sous :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters\SysVol\DomainName
NOTE
Cette clé est temporaire et supprimée une fois que SYSVOL est source, ou que les informations sous SYSVOL ont
été répliquées avec succès.
La version 2195 de Ntfrs.exe empêche la réplication à partir de ce serveur source initial, retardant la
réplication SYSVOL jusqu’à ce que frS puisse tenter la réplication à partir d’un partenaire de réplication
entrant dans le domaine sur un objet de connexion NTDS automatique ou manuel.
Tous les contrôleurs de domaine source potentiels dans le domaine doivent eux-mêmes avoir partagé les
partages NETLOGON et SYSVOL et appliqué la stratégie de contrôleurs de domaine et de domaine par
défaut.
Structure du répertoire SYSVOL :
domaine
DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Stratégies
{GUID}
Adm
MACHINE
USER
{GUID}
Adm
MACHINE
USER
{etc.,}
scripts
staging
zones de transit
MyDomainName.com
scripts
sysvol(sysvol share)
MyDomainName.com
DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Stratégies
{GUID}
Adm
MACHINE
USER
{GUID}
Adm
MACHINE
USER
{etc.,}
scripts(partage NETLOGON)
4. Le groupe « contrôleurs de domaine Enterprise » doit se faire accorder le droit « accéder à cet ordinateur
à partir du réseau » dans la stratégie de contrôleurs de domaine par défaut sur l’ou des contrôleurs de
domaine.
La réplication d’Active Directory pendant l’utilisation du programme Dcpromo.exe utilise les informations
d’identification spécifiées dans l’Assistant Installation d’Active Directory. Au redémarrage, la réplication se
produit dans le contexte du compte d’ordinateur du contrôleur de domaine. Tous les contrôleurs de
domaine source dans le domaine doivent répliquer et appliquer la stratégie accordant au groupe «
Contrôleurs de domaine Enterprise » le droit « Accéder à cet ordinateur à partir du réseau ». Pour une
vérification rapide, recherchez l’événement dans le journal des applications des contrôleurs de 1704s
domaine source potentiels. Pour une vérification détaillée, exécutez l’analyse de la configuration de la
sécurité sur le modèle Basicdc.inf (nécessite la définition de variables d’environnement pour SYSVOL,
DSLOG et DSIT, et examinez la sortie du journal qui en résulte.
Le droit « Accéder à cet ordinateur à partir du réseau » est souvent manquant sur Windows NT 4.0 qui
sont mis à niveau vers Windows 2000. Ce problème entraîne l’échec d’Active Directory et de la réplication
FRS avec des messages d’erreur « accès refusé ».
5. Chaque contrôleur de domaine doit être en mesure de résoudre (ping) les noms d’ordinateurs complets
(%nom de l’ordinateur%. ) des ordinateurs participant au jeu <domain name> de réplicas.
Pour SYSVOL, cette étape consiste à pinger le nom d’ordinateur FQ de tous les contrôleurs de domaine
dans le domaine. Confirmez que l’adresse renvoyée par la commande ping correspond à l’adresse IP
renvoyée par IPCONFIG sur la console de chaque partenaire de jeu de réplicas.
6. Le service FRS doit avoir créé une base de données NTFRS jet.
Exécutez cette commande sur chaque contrôleur de domaine du domaine pour confirmer la présence du
fichier DIR \\<computername>\admin$\ntfrs\jet NTfrs.jdb. La date et la taille de la base de données jet
peuvent être incorrectes pendant l’exécution du service NTFRS (par conception).
7. Chaque contrôleur de domaine doit être membre du jeu de réplicas SYSVOL.
NTFRSUTL DS [COMPUTERNAME] S’exécute sur tous les membres du jeu de réplicas. Confirmez que tous les
contrôleurs de domaine du domaine s’afficheront sous la partie « SET: DOMAIN SYSTEMVOLUME
(SYSVOL SHARE) » de la sortie NTFRSUTL. Le jeu de réplicas SYSVOL et ses membres peuvent également
être affichés sous cn="volume du système de domaine »,cn=service de réplication de
fichiers,cn=système,dc= dans le logiciel en ligne Utilisateur et <FQDN> ordinateurs (Dsa.msc) lorsque «
Fonctionnalités avancées » est activé sous le menu Affichage.
8. Chaque contrôleur de domaine doit être abonné au jeu de réplicas.
NTFRSUTL DS [COMPUTERNAME] S’exécute sur tous les membres du jeu de réplicas. L’objet Subscriber apparaît
dans cn=domain system volume (partage SYSVOL),cn=NTFRS
Subscriptions,CN=%DCNAME%,OU=Domain Controllers,DC= <FQDN> . L’exécution de cette commande
nécessite que l’objet ordinateur existe et ait été répliqué dans. NTFRSUTL signale ce qui suit lorsque l’objet
abonné est manquant :
SUBSCRIPTION: NTFRS SUBSCRIPTIONS DN: cn=ntfrs

subscriptions,cn=W2KPDC,ou=domain controllers,dc=d... Guid:
5c44b60b-8f01-48c6-8604c630a695dcdd
Working: f:\winnt\ntfrs
Actual Working: f:\winnt\ntfrs
WIN2K-PDC IS NOT A MEMBER OF A REPLICA SET!
9. La planification de réplication doit être activée.

10. Le lecteur logique hébergeant le partage SYSVOL et le dossier intermédiaire dispose d’un espace disque
disponible en quantité sur les partenaires en amont et en aval. Par exemple, 50 % de la quantité de
contenu que vous essayez de répliquer et trois fois la plus grande taille de fichier répliquée.
11. Vérifiez le dossier de destination et le dossier de transit (affiché dans « NTFRSUTL DS ») du nouveau
réplica pour voir si les fichiers sont répliqués. Les fichiers du dossier intermédiaire doivent être déplacés
vers l’emplacement final. Le fait que le nombre de fichiers dans le dossier intermédiaire ou de destination
change constamment est un bon signe, car les fichiers sont répliqués ou sont transitionn s vers le dossier
de destination.
NOTE
Ntfrsutl.exe est un utilitaire inclus dans le Kit de ressources Windows 2000.
Documentation de résolution des problèmes de
haute disponibilité pour Windows Server
problèmes liés à la haute disponibilité et à les résoudre eux-mêmes. Les rubriques sont divisées en sous-
Sous-catégories haute disponibilité

Impossible de mettre une ressource en ligne
Impossible de faire échouer un groupe
Nœud de cluster en suspension
Le service de cluster ne parvient pas à démarrer
Cluster-Aware updating (CAU)
Erreurs lors de l’exécution de l’Assistant Validation
Nœud initial de création ou d’ajout de cluster
Clusters d’impression et impression haute disponibilité
Remplacement du matériel et mise à jour du système d’exploitation
Cause première d’un changement inattendu
Installation et configuration des applications et services en cluster
Impossible d’apporter des conseils de résolution des
problèmes liés à une ressource en cluster en ligne
Ces conseils sont conçus pour vous aider à résoudre les problèmes de mise en ligne des ressources en cluster
dans un environnement de cluster Windows.

1. Lorsqu’une ressource ne parvient pas à être mise en ligne, l’ID d’événement 1069 est journalisé sur le
serveur qui héberge la ressource préoccupante :
L’erreur 1069 Microsoft-Windows-FailoverClustering Cluster resource '<Name of the Resource>' de

type '<Resource Type>' dans le rôle cluster '<Available Storage>' a échoué.
2. Recherchez l’ID d’événement dans le journal des événements système, puis vérifiez si d’autres erreurs ou
avertissements sont enregistrés. Par exemple :
Si une ressource de disque physique ne peut pas être mise en ligne, recherchez les erreurs ou
avertissements liés au disque. Par exemple, l’ID d’événement 129 (réinitialisation de bus) ou l’ID
d’événement 153 (nouvelle tentative d’E/S).
Si une ressource de nom de réseau ne peut pas être mise en ligne, recherchez les entrées liées au
DNS.
Si une ressource d’adresse IP ne peut pas être mise en ligne, recherchez les événements, erreurs
ou avertissements liés à la carte réseau.
3. Si rien d’autre que l’ID d’événement 1069 n’est journalisé, passez en revue le journal du cluster pour plus
d’informations sur la résolution des problèmes. Ouvrez une invite PowerShell avec élévation de privilèges
et exécutez l’applet de commande suivante :
Get-ClusterLog -Destination C:\temp
NOTE
Cette applet de commande génère les journaux de cluster sur tous les membres du cluster et les copie dans le
dossier C:\temp sur le serveur sur lequel l’applet de commande a été exécutée.
4. Recherchez des chaînes dans le journal du cluster qui peuvent être corrélées avec l’ID d’événement 1069 :
[RCM] rcm::RcmResource::HandleFailure
[RHS] Online for resource
OnlineThread: Error <Code> bringing resource online.
[RHS] RhsCall::DeadlockMonitor: Call ONLINERESOURCE
NOTE
L’espace réservé <Code> représente le code d’erreur et peut différer en fonction du problème.
Scénarios de support courants

Impossible d’ajouter un nom de réseau en ligne
Impossible d’apporter un disque physique en ligne
Impossible d’apporter une adresse IP en ligne
Avant de contacter Support Microsoft, vous pouvez collecter des informations sur le problème.
1. TSSv2 doit être exécuté dans le contexte d’un compte avec des droits d’administrateur sur le système
local, et le CLUF doit être accepté (une fois le CLUF accepté, TSSv2 ne l’invite plus).
2. Nous recommandons que l’ordinateur local utilise la stratégie d’exécution RemoteSigned PowerShell.
NOTE
Si la stratégie d’exécution PowerShell actuelle n’autorise pas l’exécution de TSSv2, les actions suivantes peuvent être
effectuées :
Définissez RemoteSigned pour le niveau Processus et exécutez l’applet de commande suivante :
PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned
Vérifiez si la modification a pris effet, exécutez l’applet de commande suivante :

PS C:\> Get-ExecutionPolicy -List
Étant donné que les autorisations de niveau processus s’appliquent uniquement à la session PowerShell actuelle, une fois
la fenêtre PowerShell donnée dans laquelle TSSv2 s’exécute est fermée, l’autorisation attribuée pour le niveau processus
revient également à l’état précédemment configuré.
Collectez les informations clés avant de contacter Support Microsoft

1. Téléchargez TSSv2 et décompressez-le dans le dossier C:\tss_tool .
2. Ouvrez une invite PowerShell avec élévation de privilèges et remplacez le répertoire par le dossier
C:\tss_tool .
3. Démarrez la trace en exécutant l’applet de commande sur les nœuds source et de destination.
.\Get-psSDP.ps1
Impossible de mettre un nom réseau en ligne dans
un cluster de basculement

1. Examinez le système et le journal du cluster pour trouver les erreurs ou avertissements exacts qui
empêchent la mise en ligne du nom du réseau. En règle générale, en plus de l’ID d’événement 1069, l’ID
d’événement 1207 est également enregistré :
L’erreur 1069 Microsoft-Windows-FailoverClustering Cluster resource '<Name of the

Resource>' de type '<Resource Type>' dans le rôle cluster '<Available Storage>' a échoué.
La ressource de nom de réseau de cluster « Nom du cluster » ne peut pas être mise en ligne.
L’objet ordinateur associé à la ressource n’a pas pu être mis à jour dans le domaine «
domainname.com » pour la raison suivante.
2. Vérifiez que l’objet VCO (Virtual Computer Object) ou l’objet CNO (Cluster Name Object) dispose des
autorisations appropriées dans Active Directory. Pour plus d’informations, consultez Prestage Cluster
Computer Objects in services de domaine Active Directory.
3. Si c’est le cas, après avoir ajusté les autorisations, vous pouvez exécuter l’option Réparer pour
synchroniser à nouveau le mot de passe AD pour l’objet CNO. Pour plus d’informations, consultez
Understanding the Repair Active Directory Object Recovery Action.
4. Vous pouvez exécuter une validation de cluster (sans la section de stockage) pour vérifier la prise en
charge du cluster et voir s’il existe des configurations incorrectes.
5. Le CNO ou le VCO peut ne pas être en mesure de se connecter en raison de problèmes DNS. Les
autorisations pour les enregistrements CNO ou VCO doivent également être vérifiées. Les traces réseau
indiquent la cause du problème.

Pour obtenir les ID d’événement suivants, consultez les journaux d’activité pour trouver plus d’informations sur
le problème.
Impossible de mettre en ligne la ressource de nom de réseau de cluster « %1 », car le nom « %2 »
correspond à ce nom de nœud de cluster. Assurez-vous que les noms réseau sont uniques.
La ressource de nom de réseau de cluster « %1 » ne peut pas être mise en ligne.
Dans un cluster, une ressource de nom réseau peut être importante, car d’autres ressources en dépendent.
Une ressource Network Name ne peut être mise en ligne que si elle est configurée correctement et est prise
en charge correctement par les réseaux et les configurations réseau disponibles.
Impossible de mettre en ligne la ressource nom réseau du cluster « %1 », car le nom n’a pas pu être ajouté
au système.
Cet événement indique que le cluster n’a pas pu localiser un contrôleur de domaine accessible en écriture.
Cet événement indique que le cluster n’a pas pu localiser un contrôleur de domaine accessible en écriture.
La ressource de nom de réseau de cluster « %1 » n’a pas pu effectuer une opération de modification de nom
(tentative de modification du nom d’origine « %3 » en nom « %4 »)
Cet événement indique que le cluster n’a pas trouvé l’objet CNO dans Active Directory. La prochaine fois que
vous essayerez de mettre le cluster en ligne, il tentera de recréer l’objet CNO.
La ressource de nom de réseau de cluster « %1 » n’a pas pu effectuer une opération de modification de nom
Cet événement indique que le cluster n’a pas pu contacter un contrôleur de domaine.
Passez en revue les journaux d’activité pour trouver plus d’informations sur le problème
Pour l’ID d’événement 1050, 1051, 1052, 1211, 1212, 1218 et 1219, procédez comme suit :
1. Utilisez observateur d'événements pour examiner les journaux d’activité de l’application et du système.
NOTE
En particulier, recherchez tous les événements liés à la fonctionnalité du contrôleur de domaine.
2. Pour rechercher des informations sur un code d’erreur, utilisez l’une des méthodes suivantes :
Consultez les codes d’erreur système.
À l’invite de commandes, exécutez la commande suivante :
NET HELPMSG <Code>
NOTE
L’espace réservé <Code> représente le code d’erreur.
3. Générez un nouveau journal de cluster et passez-le en revue. Pour générer un nouveau journal de cluster,
reproduisez le problème et ouvrez une invite PowerShell avec élévation de privilèges. À l’invite
PowerShell avec élévation de privilèges, exécutez l’applet de commande suivante :
Get-ClusterLog -Destination C:\temp\ -TimeSpan 5 -UseLocalTime
Si vous identifiez un problème que vous pouvez résoudre, corrigez-le et essayez de redémarrer la ressource
cluster affectée.
Impossible de mettre un disque physique en ligne
dans un cluster de basculement

empêchent la mise en ligne du disque physique.
2. Définissez le journal du cluster sur un niveau de détail de 5 pour obtenir des informations détaillées à
partir de la tentative en ligne :
Set-ClusterLog -Level 5
3. Capturez un journal de l’analyseur de performances ou une trace Storport pour vérifier les performances
médiocres du disque, ce qui peut retarder le processus en ligne.
4. La validation de cluster est également utile dans ce scénario. Vous pouvez créer un disque de cluster à
partir du même SAN et pointer la validation du cluster vers ce disque.
5. Si le processus de sous-système d’hébergement de ressources de cluster (Rhs.exe) se bloque pendant la
tentative en ligne ayant échoué, vous devez configurer le serveur pour générer un vidage de mémoire
complet et définir les clés de Registre suivantes :
Pour Windows Server 2012 :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Failover
Clusters\DebugBreakOnDeadlock to DWORD 3.
Pour Windows Server 2012 R2 :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters\DebugBreakOnDeadlock to
DWORD 3.
NOTE
Une fois la clé de Registre configurée, le serveur sur lequel se produit l’interblocage RHS affiche un écran bleu et
génère un arrêt 0x9E vidage de mémoire. Vous pouvez ensuite l’analyser et résoudre la cause.
Solutions possibles
Si les temps de réponse de lecture ou d’écriture des disques sont lents (performances de disque lentes),
contactez le fournisseur de stockage.
Si l’antivirus interfère avec la tentative en ligne, désinstallez et redémarrez le serveur pour supprimer les
pilotes de filtre.
Les pilotes du contrôleur HBA ou RAID doivent être mis à jour.
Les autorisations sur les disques racine sont manquantes.
En cas de problèmes de réservation persistants, il est recommandé de contacter le fournisseur de
stockage pour diagnostiquer les problèmes.
Vous pouvez également exécuter l’applet Clear-ClusterDiskReservation -Disk <Number> de commande
pour effacer la réservation persistante.
NOTE
L’espace réservé <Number> représente le numéro de disque.

Pendant que la ressource de disque « %1 » était mise en ligne, l’accès à un ou plusieurs volumes a échoué
avec l’erreur « %2 ».
Dans un cluster de basculement, la plupart des services ou applications en cluster utilisent au moins un
disque, également appelé ressource de disque, que vous affectez lorsque vous configurez le service ou
l’application en cluster. Les clients ne peuvent utiliser le service ou l’application en cluster que lorsque le
disque fonctionne correctement.
NOTE
NET HELPMSG <Code>
NOTE
Si vous identifiez un problème que vous pouvez résoudre, corrigez-le et essayez de remettre la ressource de
cluster en ligne avant de continuer.
NOTE
Si vous modifiez la configuration de stockage, nous vous recommandons d’utiliser l’Assistant Validation d’une
configuration pour valider la configuration de stockage.
La ressource de disque de cluster « %1 » contient un point de montage non valide.
Dans un cluster de basculement, la plupart des services ou applications en cluster utilisent au moins un
disque, également appelé ressource de disque, que vous affectez lorsque vous configurez le service ou
l’application en cluster. Les clients ne peuvent utiliser le service ou l’application en cluster que lorsque le
disque fonctionne correctement.
Vérifier la configuration du disque

Vérifiez que le disque monté est configuré conformément aux instructions suivantes :
Les disques en cluster peuvent uniquement être montés sur des disques en cluster (et non sur des
disques locaux).
Le disque monté et le disque sur lequel il est monté doivent faire partie du même service ou application
cluster. Les disques ne peuvent pas se trouver dans deux services ou applications cluster différents, et ils
ne peuvent pas se trouver dans le pool général de stockage disponible dans le cluster.
Pour plus d’informations, consultez Utiliser des volumes partagés de cluster dans un cluster de basculement.
Générer un nouveau journal de cluster qui enregistre le problème
Pour générer un nouveau journal de cluster, reproduisez le problème et ouvrez une invite PowerShell avec
élévation de privilèges. À l’invite PowerShell avec élévation de privilèges, exécutez l’applet de commande
suivante :
Si vous identifiez un problème que vous pouvez résoudre, corrigez-le et essayez de remettre la ressource en
ligne avant de continuer.
Le service de cluster a rencontré des erreurs de stockage lors de la tentative de mise en ligne du pool de
stockage.
Vérifier l’état des disques

1. Dans Gestion des disques (disponible dans le menu Stockage dans Gestionnaire de serveur), assurez-
vous que les disques sont sains et connectés.
2. Dans Gestion de l’ordinateur (disponible dans le menu Outils de Gestionnaire de serveur),
sélectionnez Gestionnaire de périphériques et assurez-vous que les disques sont en ligne avec les
derniers pilotes et microprogrammes installés.
Utiliser l’Assistant Validation d’une configuration pour passer en revue la configuration du stockage
IMPORTANT
N’oubliez pas que le service ou l’application en cluster reste hors connexion pendant la durée du test de validation du
stockage.
1. Dans le composant logiciel enfichable Gestionnaire du cluster de basculement , sélectionnez

Failover Cluster ManagementManagementValidate > > a Configuration .
2. Suivez les instructions de l’Assistant pour spécifier le cluster que vous souhaitez tester.
3. Dans la page Options de test , sélectionnez Exécuter uniquement les tests que je sélectionne .
4. Dans la page Sélection des tests, désactivez toutes les cases à cocher à l’exception des Stockage et des
tests d’inventaire qui semblent pertinents pour votre situation.
5. Suivez les instructions de l’Assistant pour exécuter les tests.
6. Dans la page Résumé , sélectionnez Afficher le rappor t .
Impossible d’apporter une adresse IP en ligne dans
un cluster de basculement

empêchent l’adresse IP de se connecter.
2. Vérifiez l’adresse IP de cette ressource et vérifiez que l’état du réseau de cluster correspondant est UP
sous Réseaux dans le Gestionnaire de cluster de basculement.
3. Si vous créez une adresse IP dans un groupe vide à partir du même réseau de cluster, est-ce qu’elle est en
ligne ?
4. Vérifiez la sortie de la ipconfig /all commande et comparez les informations du réseau affecté à celles
qui fonctionnent.
5. Désactivez ou activez la carte d’interface réseau correspondant au réseau de cluster pour l’adresse IP
affectée.
6. Mettez à jour le pilote pour la carte réseau ou l’association.

Essayez l’une des solutions suivantes en fonction de l’ID d’événement :
Pour l’ID d’événement 1046, 1047, 1048, 1049, 1078 et 1223, vérifiez le rôle configuré pour un réseau de
cluster.
Pour l’ID d’événement 1360, 1361 et 1362, consultez les journaux pour trouver plus d’informations sur le
problème.
Impossible de mettre en ligne la ressource d’adresse IP du cluster « %1 », car la valeur du masque de sous-
réseau n’est pas valide.
Dans un cluster, une ressource d’adresse IP est importante, car dans la plupart des cas, d’autres ressources
(comme une ressource de nom de réseau) en dépendent. Une ressource d’adresse IP ne peut être mise en
ligne que si elle est configurée correctement et qu’elle est prise en charge correctement par les réseaux et les
configurations réseau disponibles.
La ressource d’adresse IP du cluster « %1 » ne peut pas être mise en ligne, car la valeur de l’adresse n’est pas
valide.
La ressource d’adresse IP du cluster « %1 » n’a pas pu être mise en ligne.
Impossible de mettre en ligne la ressource d’adresse IP du cluster « %1 », car une adresse IP en double « %2
» a été détectée sur le réseau.
Impossible de mettre en ligne la ressource d’adresse IP du cluster « %1 », car l’inscription WINS a échoué
sur l’interface « %2 » avec l’erreur « %3 ».
Cet événement indique qu’il existe un problème avec la configuration Windows Service de noms Internet
(WINS).
La ressource d’adresse IP du cluster « %1 » ne peut pas être mise en ligne, car le réseau de cluster « %2 »
n’est pas configuré pour autoriser l’accès client.
Les réseaux de cluster sont automatiquement créés pour tous les sous-réseaux logiques connectés à tous les
nœuds du cluster. Chaque carte réseau connectée à un sous-réseau commun est répertoriée dans le
Gestionnaire de cluster de basculement. Les réseaux de cluster peuvent être configurés pour différentes
utilisations.
Vérifier le rôle configuré pour un réseau de cluster

Pour l’ID d’événement 1046, 1047, 1048, 1049, 1078 et 1223, procédez comme suit :
1. Dans le Gestionnaire du cluster de basculement , si le cluster que vous souhaitez configurer ne
s’affiche pas, dans l’arborescence de la console, cliquez avec le bouton droit sur Gestionnaire du
cluster de basculement , sélectionnez Gérer un cluster , puis sélectionnez ou spécifiez le cluster
souhaité.
2. Si vous réduisez l'arborescence de la console, développez l'arborescence sous le cluster que vous
souhaitez configurer.
3. Développez les réseaux .
4. Cliquez avec le bouton droit sur le réseau pour lequel vous souhaitez vérifier les paramètres, puis
sélectionnez Propriétés .
5. Si vous souhaitez utiliser ce réseau pour le cluster, assurez-vous que l’option Autoriser le cluster à
utiliser cette option réseau est sélectionnée. Si vous sélectionnez cette option et souhaitez que le
réseau soit utilisé par les clients (pas seulement les nœuds), assurez-vous que l’option Autoriser les
clients à se connecter via cette option réseau est sélectionnée.
Si vous modifiez l’un des paramètres, essayez de remettre la ressource en ligne avant de continuer.
La ressource d’adresse IP du cluster « %1 » n’a pas pu être mise en ligne.
Un cluster de basculement nécessite une connectivité réseau entre les nœuds et entre les clients et les
nœuds. Les problèmes liés à une carte réseau ou à un autre appareil réseau (problèmes physiques ou de
configuration) peuvent interférer avec la connectivité.
IPv6 Tunnel ressource d’adresse « %1 » n’a pas pu être mise en ligne, car elle ne dépend pas d’une ressource
d’adresse IP (IPv4).
Cet événement indique que les dépendances correctes ne sont pas configurées pour la ressource IPv6 Tunnel
Address.
La ressource d’adresse IP du cluster « %1 » n’a pas pu être mise en ligne, car la propriété « %2 » n’a pas pu
être lue.
Pour l’ID d’événement 1360, 1361 et 1362, procédez comme suit :
NOTE
NET HELPMSG <Code>
NOTE
Si vous identifiez un problème que vous pouvez résoudre, corrigez-le et essayez de redémarrer la ressource
cluster affectée.
Erreur (le paramètre est incorrect) et échec de la
validation du cluster par rapport à l’état « Valider la
ressource »
Cet article permet de résoudre l’erreur « Le paramètre est incorrect » qui se produit lorsque la validation du
cluster échoue par rapport à l’état Valider la ressource.
Symptômes
Lorsque vous vérifiez l’unité d’organisation Active Directory, la validation du cluster échoue par rapport à l’état «
Valider la ressource » et vous recevez le message d’erreur suivant :
Une erreur s’est produite lors de l’exécution du test. L’opération a échoué. Une erreur s’est produite lors de la
vérification de l’unité d’organisation Active Directory pour la ressource de nom de cluster. Le paramètre est
incorrect.
Si vous essayez de créer les points d’accès client, le processus peut échouer si l’adresse IP utilisée est identique à
l’adresse du message d’erreur.
Ce problème peut également se produire après l’octroi de l’autorisation CNO à l’ou de cluster, et l’utilisateur
dispose également d’autorisations de contrôle total sur l’objet CNO.
Cause
L’erreur de paramètre est due au fait que les utilisateurs authentifiés n’ont pas d’autorisations de lecture par
défaut sur le conteneur Ordinateurs par défaut.
Résolution
Pour résoudre ce problème, accordez l’autorisation lecture aux utilisateurs authentifiés. Les utilisateurs
authentifiés ont besoin d’autorisations de lecture pour les objets qui se trouver dans le conteneur Ordinateurs,
même si les objets ordinateur ne sont pas là.
État
Un test a été ajouté à la validation de cluster pour vérifier spécifiquement l’autorisation CNO.
Itinéraire actif supprimé sur le cluster de Windows
serveur
Cet article fournit une solution à un problème de suppression de l’itinéraire actif lorsque vous ajoutez un
itinéraire statique persistant à une carte réseau.
Symptômes
Lorsque vous ajoutez un itinéraire statique persistant à une carte réseau qui se trouve sur un cluster de failover
Windows Server 2008 et que vous déconnectez une adresse IP en cluster (ou que vous la déplacez vers un autre
nœud), l’itinéraire « Actif » est supprimé et aucune connexion ne peut être réalisée à l’aide de cet itinéraire,
même s’il s’affiche toujours comme persistant lors de l’exécution de la commande ROUTE PRINT. Une fois que
vous avez remis l’adresse IP en cluster en ligne, l’itinéraire actif est renvoyé.
Cause
Lorsqu’une adresse IP en cluster est déconnectée, elle prend également l’itinéraire « actif » ajouté en tant
qu’itinéraire persistant. Cela se produit uniquement lorsque les deux cas suivants sont vrais :
1. Windows Le clustering de serveur 2008 ou de serveur 2008 R2 est configuré
2. Des itinéraires statiques sont ajoutés avec ROUTE.EXE
Résolution
Lorsque vous utilisez la ROUTE.EXE, la commande la plus courante pour ajouter une commande persistante est
la commande la plus courante :
route -p add 10.51.0.0 mask 255.255.0.0 10.44.60.1
Cette commande ne spécifie pas l’interface spécifique à lier. Comme il n’est pas lié à une interface spécifique, il
est supprimé en tant qu’itinéraire actif. Dans l’exemple ci-dessus, l’itinéraire spécifié vers la passerelle est la
même carte (réseau) que l’adresse IP en cluster.
Pour conserver l’itinéraire « actif », vous devez également spécifier l’interface dans le cadre de la commande. Par
exemple, si l’interface de carte réseau est 18, la commande sera : route -p add 10.51.0.0 mask 255.255.0.0
10.44.60.1 if 18*
Dans Windows 2008 et supérieures, la méthode prise en charge pour ajouter un itinéraire persistant consiste
également à inclure l’interface de carte réseau. Il existe deux méthodes pour déterminer le numéro d’interface
de la carte réseau. Lors de l’exécution de la commande ROUTE PRINT ou NETSH, elle vous donne d’abord les
interfaces en haut. Voici un problème semblable à celui-ci :
C:\>route print
IPv4 Route Table
========================================
Interface List
23 ...00 15 5d 4a ac 06 ...... Local Gigabit Controller
19 ...00 15 5d 4a ac 01 ...... Local Gigabit Controller #2
18 ...00 15 5d 4a ac 00 ...... Local Gigabit Controller #3
========================================
ou -
C:\>netsh int ipv4 show int

Idx Met MTU State Name
--- --- ----- ----------- -------------------
18 50 4294967295 connected Local Gigabit Controller #3
19 5 1500 connected Local Gigabit Controller #2
23 5 1500 connected Local Gigabit Controller
Une ressource de disque de cluster peut ne pas être
mise en ligne et exécuter chkdsk lorsqu’un caractère
non valide est utilisé dans le nom de la ressource
Cet article fournit de l’aide pour résoudre un problème dans lequel la ressource de disque ne parvient pas à être
mise en ligne lorsque le nom de la ressource de disque de cluster a un caractère non valide.
Symptômes
Si le nom d’une ressource de disque de cluster possède un caractère non valide du point de vue NTFS ' '/' et
qu’il existe un fichier à la racine du lecteur où le cluster ne dispose pas de l’autorisation READ ou si le fichier est
en cours d’utilisation, la ressource de disque ne parvient pas à être mise en \ ligne.
Cause
Le nom de la ressource « Disque physique » possède une barre oblique inverse ou une barre oblique inverse
dans le nom de la ressource. Exemple : « Disque G : » et « Système local » ne peuvent pas ouvrir un handle vers
un fichier à la racine du lecteur (qu’il soit utilisé ou \ autorisé).
Résolution
Pour résoudre ce problème, installez le correctif logiciel 3033918.
Pour contourner ce problème, supprimez le(s) caractère(s) non valide(s) dans les noms de ressources pour les
types de ressources « Disque physique » ou avez au moins le compte « Système local » autorisation de lecture
sur les fichiers à la racine du lecteur. Après avoir apporté les modifications, vous devez être en mesure de mettre
la ressource de disque en ligne.
NOTE
Il n’est pas recommandé de stocker des fichiers à la racine d’un disque en cluster, car le cluster doit ouvrir des handles vers
des fichiers et des dossiers dans le cadre du mécanisme de détection d’état utilisé pour déterminer les problèmes d’accès
possibles au stockage. Étant donné que le service de cluster s’exécute dans le contexte du compte « Système local » , si ce
compte n’a pas l’autorisation d’accès aux fichiers à la racine d’un lecteur, la vérification d’état peut échouer.
Le cluster tente d’éumer les fichiers sur le disque pendant un événement en ligne et s’il n’est pas en mesure
d’éumérer les fichiers sur la racine du disque de cluster, il échouera sur le disque.
Extrait des journaux du cluster :
00001668.00001f88:: <DateTime> WARN [RES] Physical Disk <G: \>: OnlineThread: Failed to get volume
guid for device \ \ ? \ GLOBALROOT \ Device \ Harddisk2 \ Partition1 \ . Erreur 3
00001668.00001f88:: <DateTime> WARN [RES] Physical Disk <G: \>: OnlineThread: Failed to set volguid \
?? \ Volume{aaeb0322-6921-11e0-a955-00155d50c903}. Erreur : 183.
00001668.00001f88:: <DateTime> INFO [RES] Physical Disk <G: \>: Found 2 mount points for device \
Device \ Harddisk2 \ Partition1
00001668.00001f88:: <DateTime> INFO [RES] Physical Disk <G: \>: VolumeIsNtfs: Volume \ \ ? \
GlobalROOT \ Device \ Harddisk2 \ Partition1 a le type \ FS NTFS
00001668.00001f88:: <DateTime> ERR [RES] Physical Disk <G: \>: VerifyFS: Failed to open file \ \ ? \
GlobalROOT \ Device \ Harddisk2 \ Partition1kilo.docx \ Error: 5.
00001668.00001f88:: <DateTime> ERR [RES] Physical Disk <G: \>: VerifyFS: Failed to open file \ \ ? \
GlobalROOT \ Device \ Harddisk2 \ Partition1kilo.docx \ Error: 5.
00001668.00001f88:: <DateTime> ERR [RES] Physical Disk <G: \>: OnlineThread: Error 123 bringing
resource online.
00001668.00001e3c:: <DateTime> ERR [RES] Physical Disk: Failed to get partition size, status 3
00001668.00001e3c:: <DateTime> ERR [RHS] Erreur 5023 de ResourceControl pour la ressource G : \ .
00001920.00000808:: <DateTime> WARN [RCM] ResourceControl(STORAGE_GET_DIRTY) to G: \ returned
5023.
Le disque est marqué comme étant incorrecte car le nom avait un caractère non valide et exécuterait chkdsk
avant que le disque soit mis en ligne correctement la prochaine fois. Les événements suivants peuvent être
notés dans le journal des événements système une fois que vous avez corrigez le problème et que vous avez en
ligne le disque pour la première fois.

Date : <DateTime>
Catégorie de tâche : ressource de disque physique
Mots clés :
Ordinateur : XXXXXXXXXXX.com
Description : La ressource de disque de cluster « Disque de cluster 1 » indique une altération du volume \ \ ?
\ Volume{aaeb0322-6921-11e0-a955-00155d50c903}'. Chkdsk est exécuté pour résoudre les problèmes. Le
disque n’est pas disponible tant que Chkdsk n’est pas terminé. La sortie de Chkdsk sera enregistrée dans le
fichier « C: \ Windows Cluster Reports ChkDsk_ResCluster Disk \ \ \ 1_Disk2Part1.log ». Chkdsk peut
également écrire des informations dans le journal des événements de l’application.

Source : Chkdsk
Date : <DateTime>
Utilisateur : N/A
Ordinateur : XXXXXXXXXXXXXXX.com
Description : Chkdsk a été exécuté en mode lecture/écriture.
Cela n’indique pas que le disque est réellement corrompu. Ce qui s’est passé, c’est que le cluster a réglé le bit
défectueux sur le disque afin que chkdsk soit exécuté pour vérifier un système de fichiers intact.
La ressource de partage de fichiers de cluster
échoue sur un nœud de cluster de failover et le
journal du cluster contient l'« état 5. Tolérance...
Cet article fournit une solution à un problème dans lequel la ressource de partage de fichiers de cluster échoue
sur un nœud de cluster de failover.
Symptômes
Dans Windows Server 2008, 2008 R2 ou 2012, vous pouvez configurer un cluster de Windows avec un
serveur de fichiers hautement disponible.
Les nodes de cluster sont configurés avec un espace de noms disjoint dans lequel le DNS principal de
l’ordinateur ne correspond pas au domaine DNS dont il est membre.
Dans ce scénario, vous remarquerez peut-être que le serveur de fichiers hautement disponible fonctionne
correctement sur certains des serveurs de cluster, mais qu’il échoue constamment sur d’autres. En examinant le
journal de cluster, vous voyez quelque chose de semblable aux entrées suivantes avec la première entrée faisant
référence à «état 5. Tolérance..." :
00001b6c.000008c8:: <DateTime> WARN [RES] File Server <FileServer-(yoel-cluster)(Cluster Disk 6)>:

Failed in NetShareGetInfo(yoel-cluster, share2), status 5. Tolérance...
00001b6c.000008c8:: <DateTime> ERR [RES] File Server <FileServer-(yoel-cluster)(Cluster Disk 6)>: Not a
single share among 1 configured shares is online
00001b6c.000008c8:: <DateTime> ERR [RES] File Server <FileServer-(yoel-cluster)(Cluster Disk 6)>: File
system check failed, number of shares verified: 1, last share status: 5.
00001b6c.000008c8:: <DateTime> ERR [RES] File Server <FileServer-(yoel-cluster)(Cluster Disk 6)>:
Fileshares failed health check during online, status 5.
Cause
Un ou plusieurs nodes du cluster de failover peuvent contenir des entrées insérables dans la liste de recherche
de suffixe DNS.
Résolution
Pour résoudre le problème, vérifiez que tous les nodes de cluster sont configurés avec la même liste de
recherche de suffixe DNS et que les entrées sont répertoriées dans le même ordre. La liste de recherche de
suffixe DNS peut être modifiée à l’aide des étapes suivantes :
1. Ouvrez la page des propriétés de la carte réseau.
2. Ouvrez la page des propriétés pour le protocole Internet version 4 (TCP/IPv4).
3. Sélectionnez le bouton Avancé sous l’onglet Général.
4. Sélectionnez l’onglet DNS.
Pour plus d’informations sur la configuration et l’utilisation d’un espace de noms disjoint, reportez-vous au lien
suivant :
Créer un espace de noms disjoint
Clustering Information on IP Address Failover
Cet article décrit les informations de clustering sur le failover d’adresse IP.
Résumé
Microsoft Cluster Server (MSCS) offre la possibilité de définir une ressource d’adresse IP au sein d’un cluster et
de faire échouer d’un nœud à un autre.
La capacité deover d’adresse IP dépend de deux choses :
Prise en charge de l’inscription dynamique et de l’inscription des adresses IP.
Possibilité de mettre à jour les caches de traduction d’adresses réseau d’autres systèmes connectés au
sous-réseau sur lequel une adresse est enregistrée.
L’inscription et l’inscription d’adresses dynamiques sont déjà implémentées dans le système d’exploitation
Microsoft Windows NT pour prendre en charge le bail d’adresses IP à l’aide du protocole DHCP (Dynamic Host
Configuration Protocol).
Microsoft Cluster Server utilise les fonctionnalités existantes dans Windows NT pour l’inscription et l’inscription
des adresses IP. Lorsque le composant de cluster tente de mettre en ligne une ressource d’adresse IP, le logiciel
envoie une commande au pilote TCP/IP pour inscrire l’adresse spécifiée. Une commande similaire existe pour
désinsser une adresse lorsque la ressource correspondante est mise hors connexion.
Le logiciel de cluster met à jour les caches de traduction d’autres systèmes sur le lan via la spécification ARP
(Address Resolution Protocol) (RFC 826), qui est implémentée par Windows NT. La spécification indique que
tous les systèmes recevant une demande ARP doivent mettre à jour leur adresse IP en mappage d’adresses
physiques pour la source de la demande (l’adresse IP source et les adresses réseau physiques sont contenues
dans la demande).
En outre, dans le cadre du processus d’inscription des adresses IP, le pilote TCP/IP Windows NT diffuse plusieurs
fois une demande ARP sur le réseau lan approprié. La demande demande au propriétaire de l’adresse IP
spécifiée de répondre avec son adresse réseau physique. En envoyant ces demandes pour l’adresse IP
enregistrée, Windows NT peut détecter des conflits d’adresses IP . si une réponse est reçue, l’adresse ne peut pas
être utilisée en toute sécurité.
Lorsque le pilote envoie ces demandes, Windows NT spécifie l’adresse IP inscrite comme source de la demande.
Par conséquent, tous les systèmes sur le réseau metront à jour leurs entrées de cache ARP pour l’adresse
spécifiée. Par conséquent, le système d’inscription devient le nouveau propriétaire de l’adresse.
NOTE
En cas de conflit d’adresses, le système de réponse peut envoyer une autre demande ARP pour la même adresse, forçant
les autres systèmes sur le sous-réseau à mettre à jour leurs caches à nouveau. Windows NT le fait lorsqu’il détecte un
conflit avec une adresse qu’il a correctement inscrite.
Pour plus d’informations sur les informations connexes, cliquez sur le numéro d’article ci-dessous pour afficher
Modifications d’adresse MAC pour un serveur virtuel lors d’un failover avec clustering
Le compte de validation de cluster provoque des
événements ou des messages
S’applique à : Windows Server 2016, toutes les éditions, Windows Server 2012 R2 Datacenter
Symptômes
Dans un environnement de clustering de basculement, lorsque vous exécutez le processus de validation de
cluster, Windows crée un compte d’utilisateur. Après cela, vous remarquerez peut-être des événements de
sécurité ou des messages qui décrivent ce compte. Le compte est temporaire. Windows supprime le compte à la
fin du processus de validation du cluster.
Pendant le processus de validation du cluster, Windows crée un compte d’utilisateur qui a les propriétés
suivantes :
Nom d’utilisateur : CliTest2
Mot de passe : 12 caractères
Appartenances aux groupes : Aucune
Le processus de validation de cluster utilise ce compte pour se connecter à des partages en cluster entre des
nœuds de cluster. Lorsque le processus de validation du cluster se termine, Windows supprime le compte.
« Erreur 0x8000ffff : défaillance catastrophique »
lorsque vous essayez de modifier les paramètres de
copie de l’ombre d’un lecteur dans Windows Server
2008
Cet article fournit une solution à une erreur (Erreur 0x8000ffff : Défaillance catastrophique) qui se produit
lorsque vous modifiez les paramètres de copie de l’ombre d’un lecteur.
Symptômes
Dans Windows Server 2008, vous ouvrez Windows Explorer, vous cliquez avec le bouton droit sur un lecteur,
puis vous cliquez sur Propriétés.
Sous l’onglet Copies de l’ombre, sélectionnez une lettre de lecteur, puis cliquez sur Paramètres bouton.
Dans ce scénario, vous recevez le message d’erreur suivant :
Échec de l’initialisation de la boîte de Paramètres pour le volume O:\
Erreur 0x8000ffff : défaillance catastrophique
En outre, l’événement suivant est consigné dans le journal des applications :
Nom du journal : Source de l’application : ID d’événement VSS : Catégorie de tâche 12311 : Aucun niveau :
Description de l’erreur : Erreur du service vss : erreur inattendue pResource->get_Disk(&pDisk) : hr =
0x80070490.
Cause
Ce problème se produit s’il existe des ressources de disque dans le cluster de failover qui ne sont pas associées
à une ressource de disque physique. Ce comportement peut se produire si vous déconnectez une ressource de
disque et supprimez le disque associé du serveur, mais que vous ne supprimez pas la ressource disque dans le
cluster deover.
Résolution
Dans le cluster deover, supprimez la ressource de disque à qui aucun disque physique n’est associé.
Des messages d’erreur se produisent si vous essayez
de mettre un groupe de cluster en ligne après l’arrêt
d’un cluster
Cet article explique comment résoudre les messages d’erreur lorsque vous essayez de mettre un groupe de
cluster en ligne après l’arrêt d’un cluster.
Symptômes
Après avoir manuellement éteint un cluster ou après une panne d’un cluster, un groupe et toutes ses ressources
peuvent échouer si le cluster subit une perte de nœud. Toutefois, le groupe peut également passer à l’état hors
connexion. Si vous essayez de mettre le groupe ou la ressource en ligne, vous pouvez recevoir le message
Une erreur s’est produite lors de la tentative de mise en ligne du groupe «GroupName » :
Le nœud de cluster n’est pas le propriétaire de la ressource.
ID d’erreur : 5015 (00001397).
Si vous essayez de mettre en ligne une ressource individuelle dans le groupe, vous pouvez recevoir l’un des
messages d’erreur suivants :
Une erreur s’est produite lors de la tentative de mise en ligne de la ressource ResourceName :
La ressource de cluster ne peut pas être mise en ligne. Le nœud propriétaire ne peut pas exécuter cette
ressource.
ID d’erreur : 5071 (000013df).
ou -
Aucun propriétaire possible n’est spécifié pour cette ressource. Cela signifie que cette ressource ne peut être
mise en ligne sur aucun nœud du cluster.
Cause
Si vous utilisez la fonctionnalité Déplacer un groupe pour déplacer manuellement un groupe d’un nœud vers un
autre, ou si le cluster échoue, une liste des propriétaires possibles est conçue pour l’ensemble du groupe et pour
toutes les ressources du groupe. Le comportement décrit dans la section « Résumé » de cet article peut se
produire si l’une des ressources du groupe qui n’est pas disponible en ligne n’a pas de nœud en ligne répertorié
dans la liste Des propriétaires possibles.
Résolution
Pour contourner ce problème, remettre en ligne le nœud qui a été mis hors connexion. Déplacez le groupe vers
le nœud que vous venez de mettre en ligne, puis vérifiez la liste des propriétaires possibles de chaque ressource
pour vérifier que le nœud sur lequel le groupe n’a pas été mis en ligne est répertorié.
Si vous ne pouvez pas mettre le nœud en ligne car le nœud a véritablement échoué, ajoutez le nœud approprié
à la liste des propriétaires possibles :
1. Dans Administrateur de cluster, ouvrez les propriétés générales de chaque ressource et examinez la liste
des propriétaires possibles.
Une fois que vous avez trouvé la ressource qui a une liste de propriétaires possibles vide et un bouton
Modifier estommé, notez le nom de cette ressource.
2. Ouvrez une invite de commandes et tapez la commande suivante. le nom de la ressource est celui de
la ressource que vous avez noté à l’étape 1 :
cluster res name of resource /listowners
Une liste des propriétaires possibles de la ressource s’affiche. Cette liste indique que le seul propriétaire
possible est le nœud qui est en panne.
3. À partir de l’invite de commandes, exécutez la commande suivante pour ajouter l’autre nœud à la liste
des propriétaires possibles, où le nœud manquant est le nœud qui est en panne :
cluster res name of resource /addowner: missing node
4. Dans l’Administrateur de cluster, recommencez à mettre en ligne le groupe qui était auparavant dans
l’état hors connexion.
NOTE
Une fois le groupe en ligne, si vous avez des difficultés à passer en revue les ressources dans l’administrateur de cluster,
quittez l’administrateur de cluster, puis reconnectez-vous au cluster.
Statut
La liste Des propriétaires possibles n’est pas utile sur un cluster qui possède moins de trois nodes. Le service de
cluster crée une liste des propriétaires possibles pour un groupe. L’emplacement sur lequel le groupe qui
contient cette ressource est hébergé est affecté si vous modifiez la liste des propriétaires possibles d’une
ressource. En interne, une liste ordonnée est conservée pour l’emplacement sur lequel le groupe est hébergé. Si
vous supprimez un propriétaire possible pour une ressource, vous supprimez ce nœud de la liste des
propriétaires possibles.
Vous pouvez recevoir des messages d’erreur lorsque
vous partagez un dossier dans un cluster de
Windows Server 2008
Cet article fournit une solution à une erreur qui se produit lorsque vous provisionniez un dossier partagé sur
une ressource de disque physique de cluster.
Beta Information
Cet article traite d’une version bêta d’un produit Microsoft. Les informations de cet article sont fournies telles
qu’elle sont et sont sujettes à modification sans préavis.
Aucun support technique formel n’est disponible auprès de Microsoft pour ce produit bêta. Pour plus
d’informations sur la façon d’obtenir la prise en charge d’une version bêta, consultez la documentation incluse
dans les fichiers de produit bêta ou vérifiez l’emplacement Web où vous avez téléchargé la version.
Symptômes
Dans Windows Server 2008, vous pouvez utiliser les outils suivants pour mettre en service un dossier partagé
sur une ressource de disque physique de cluster :
Utilisez le logiciel en un clin d’œil Gestion du cluster de failover.
Utilisez le logiciel en Stockage gestion des partages et des partages.
Utilisez Windows Explorer.
Toutefois, lorsque vous utilisez ces outils pour partager un dossier dans un cluster de Windows Server 2008,
vous pouvez être face aux symptômes suivants.
Symptôme 1
Lorsque vous cliquez avec le bouton droit sur un dossier dans Windows Explorer, puis que vous cliquez sur
Par tager, vous pouvez recevoir le message d’avertissement suivant :
Votre dossier n’a pas pu être partagé
Symptôme 2
Vous cliquez avec le bouton droit sur un dossier dans Windows Explorer, puis cliquez sur Propriétés. Si vous
cliquez ensuite sur Partager ce dossier sous Partage avancé sous l’onglet Partage, vous pouvez recevoir le
Une erreur s’est produite lors de la tentative de partage folder_name . La ressource de cluster est
indessable. La ressource partagée n’a pas été créée pour le moment.
Symptôme 3
Lorsque vous essayez d’utiliser l’Assistant Mise en service d’un dossier partagé dans le logiciel en snap-in
Gestion du cluster de failover ou dans le snap-in Gestion du partage et Stockage pour partager un dossier, vous
pouvez recevoir le message d’avertissement suivant :
Le dossier partagé réside sur un volume hautement disponible, mais aucun nom de serveur réseau
hautement disponible n’est associé au volume. Une ressource de cluster peut être créée pour le dossier
par tagé, mais les clients peuvent uniquement accéder au dossier partagé par le biais du nom de serveur
local server_name . Voulez-vous vraiment utiliser cet emplacement spécifié ?
Si vous cliquez sur Oui, vous recevez le message d’erreur suivant :
Partager sur SMB
Si vous cliquez sur l’onglet Détails associé à ce message d’erreur, vous recevez le message d’erreur suivant :
\\ ser ver_name \ folder_name : impossible de créer un dossier partagé SMB. La ressource de cluster est
indessable.
NOTE
Le logiciel en snap-in Gestion du cluster de failover et le logiciel en Stockage Share and Stockage Management utilisent
l’Assistant Mise en service d’un dossier partagé pour mettre en service un dossier partagé. Par conséquent, la mise en
service d’un dossier partagé dans le logiciel en snap-in Gestion du cluster de failover est fondamentalement identique à la
mise en service d’un dossier partagé dans le logiciel en snap-in Gestion du partage et Stockage.
Cause
Ces problèmes se produisent parce que vous essayez de mettre en service un dossier partagé sur une ressource
de disque physique de cluster qui n’est pas membre du groupe Application ou Ser vice hautement disponible.
Les ressources de disque physique de cluster sont répertoriées dans le groupe Stockage disponible. Pour
afficher ce groupe, cliquez sur Stockage dans le logiciel en snap-in Gestion du cluster de failover.
Résolution
Pour résoudre ce problème, assurez-vous que la ressource de disque physique est membre du groupe
Applications ou ser vices hautement disponibles dans le cluster qui dispose déjà d’un point d’accès client (CAP)
configuré. Assurez-vous également que l’état de la ressource de disque physique est « En ligne ».
Disques SAS locaux ajoutés dans le cluster de
Windows serveur
Cet article fournit une solution de contournement pour le problème d’ajout de disques SAS locaux dans
Windows cluster de basculement de serveur.
Symptômes
Sur un cluster de Windows Server 2012 ou Windows Server 2012 R2, les lecteurs SAS locaux peuvent être
regroupés. Après avoir ajouté la ressource Disque physique, il se peut qu’elles ne parviennent pas à se mettre en
ligne. En outre, le message d’erreur suivant peut s’afficher :
Code d’erreur : 0x80070001
Fonction incorrecte
Si vous regardez les journaux des événements, vous remarquerez peut-être que l’événement suivant est
consigné dans le journal des événements système :
Cause
Un lecteur SAS local peut être mis en cluster en raison de modifications apportées au comportement par défaut
des critères de disque en mesure de cluster introduits dans Windows Server 2012.
Pour contourner ce problème, supprimez la ressource disque du Gestionnaire du cluster de failover (FCM) si
vous ne souhaitez pas qu’elles font partie du cluster. En outre, vous devez mettre ces lecteurs en ligne dans
gestion des disques une fois que vous les avez supprimés du Gestionnaire du cluster de failover.
Identifiez les signatures de disque non partagées sur les nodes de cluster (par exemple, utilisez f6f6806f Disk
Signature qui est mis en évidence par le rapport de validation dans la section Plus d’informations).
Méthode 1
1. Ouvrez une invite PowerShell avec élévation de niveau élevé (cliquez avec le bouton droit sur la vignette ou
l’icône et il s’agit d’une option dans la barre inférieure).
2. Copier et coller la commande ci-dessous pour identifier uniquement les lecteurs SAS
$signature = @{Label="Signature »; Expression={[System.Convert]::ToString($.signature, 16) }} Get-Disk |?
{$.bustype -eq « SAS"} | ft Number, $signature, Bustype -a
Exemple de sortie de la commande PowerShell ci-dessus :
Number Signature BusType
--------- ----------- ----------
0 daf34ee4 SAS
1 F6f6806f SAS
Méthode 2
1. Ouvrez la Windows’exécuter à l’aide du clavier, appuyez sur Windows touche de logo +R
2. Tapez Regedit et appuyez sur Entrée
3. Recherchez et accédez à HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
4. La lecture de la signature de disque à partir du Registre ci-dessus est un peu difficile, vous devez lire la clé
dans l’ordre inverse
6f 80 f6 f6 serait lu en tant que F6F6806F

5. Répétez les mêmes étapes sur tous les nodes du cluster. Remarque : si vous ne lisez pas la lettre de
lecteur, vous devrez peut-être comparer tous les GUID de volume et lire les données dans l’ordre inverse
comme mentionné à l’étape 4 ci-dessus.
Une nouvelle amélioration de la fonctionnalité de clustering de Windows Server 2012 et Windows Server 2012
R2 est qu’elle prend en charge une configuration Stockage asymétrique. Dans Windows Server 2012 un disque
est considéré comme clusterable s’il est présenté à un ou plusieurs nodes et n’est pas le disque de
démarrage/système, ou s’il contient un fichier de page. Dans les versions précédentes, un disque devait être
présenté à tous les nodes du cluster. Ce type de configuration est plus courant dans les clusters multisesses. Le
Gestionnaire du cluster de failover (FCM) ajoute automatiquement ces lecteurs SAS qui sont exposés à un ou
plusieurs nœuds lors de l’ajout d’un nœud dans le cluster.
Pour un contrôle plus explicite des disques en cluster, les utilisateurs peuvent désactiver le clustering des disques
de clustering automatique en désactivant « Ajouter toutes les Stockage éligibles au cluster » lors de la création
de l’Assistant ou Ajouter le disque souhaité ultérieurement à l’aide de « Ajouter un disque » dans fcM.
Utilisez la validation de cluster pour déterminer si le disque peut être utilisé dans cluster. Dans l’exemple ci-
dessous, la validation indique clairement que le disque n’est visible que sur un nœud qui peut généralement se
produire si les disques sont saS locaux sur le nœud.
Liste des disques de cluster potentiels
Le disque physique f6f6806f n’est visible qu’à partir d’un seul nœud et ne sera pas testé. La validation nécessite
que le disque soit visible à partir d’au moins deux nodes. Le disque est signalé comme visible au niveau du
nœud :<Node Name>
Sous la section Causes possibles, vous trouverez le message d’avertissement suivant : *Le cluster n’utilise pas le
stockage partagé. Un cluster doit utiliser une solution matérielle basée sur le stockage partagé ou sur la
réplication entre les différents nodes. Si votre solution est basée sur la réplication entre les nodes, vous n’avez
pas besoin de réexécuter Stockage tests. Au lieu de cela, travaillez avec le fournisseur de votre solution de
réplication pour vous assurer que les copies répliquées de la base de données de configuration de cluster
peuvent être conservées sur les différents nodes.
Le cluster de failover n’ajouterait pas de lecteurs SAS s’ils contiennent les informations suivantes :
Fichiers de démarrage
Fichier système ou fichier de page
Passer par Hyper-V
Échec de la mise en ligne de la ressource Nom
réseau dans un cluster de Windows Server 2008 R2
Service Pack 1
Cet article fournit une solution à un problème dans lequel la ressource Nom du réseau ne parvient pas à être
mise en ligne dans un cluster de Windows Server 2008 R2.
Symptômes
Dans un cluster Windows Server 2008 R2 Service Pack 1, lorsque vous tentez de mettre en ligne les ressources
nom réseau pour les services et applications, le nom du réseau passe à l’état d’échec. Toutefois, le nom du
réseau de cluster est en ligne. Si vous vérifiez les journaux des événements, certains événements peuvent être
enregistrés.
En outre, lorsque vous générez le journal de cluster sur le nœud d’échec, vous pouvez voir les entrées suivantes
:
INFO [RES] Nom du réseau <VCO> : GetCoreNetnameObject_VSToken renvoyer l’état 0

INFO [RES] Nom du réseau : j’ai obtenu le <VCO> jeton de sécurité pour le compte de nom de cluster.
INFO [RES] Nom du réseau : l’échec de l’accès au cache KDC local pour le domaine <VCO> \ \ <Member DC
Name> , état <DC Name> = 0 .
INFO [RES] Nom du réseau : l’échec de l’accès au cache KDC local pour le domaine <VCO> \ \ <Member DC
Name> , état <DC Name> = 0 .
Err [RES] Nom du réseau <VCO> : impossible de se logon. winError 1326
WARN [RES] Network Name <VCO> : Impossible d’éumer les transports de serveur, erreur 5.
.
.
INFO [RES] Network Name <VCO> : adaptateur Local Area Connection 2 (1)
ERR [RES] Nom du réseau : le nom de réseau spécifié est actuellement hébergé par un autre système dans le
réseau. Aucune tentative de réinitialisation du mot de passe de l’objet ordinateur associé à <VCO> <VCO> .
Cause
Le mot de passe de l’objet VCO (Virtual Computer Object) n’est pas synchronisé avec Active Directory. L’objet
CNO (Cluster Name Object) tente toutefois de le réinitialiser avant de pouvoir le faire, il vérifie s’il existe un
autre ordinateur du même nom sur le réseau, afin de ne pas réinitialiser le mot de passe de l’objet Active
Directory de cet ordinateur par erreur. Elle échoue car cette vérification retourne true si le fichier
C:\Windows\System32\drivers\etc\hosts contient une entrée pour le nom NetBIOS du nœud de cluster.
Résolution
Modifiez le fichier C:\Windows\System32\drivers\etc\hosts et supprimez l’entrée du nœud cluster.
Il se peut qu’une ressource de disque physique ne
soit pas disponible en ligne sur un nœud de cluster
Cet article permet de résoudre un problème dans lequel une ressource de disque physique n’est pas mise en
ligne sur un nœud de cluster.
Symptômes
Sur un nœud de cluster qui exécute Windows Server, une ressource de disque physique peut entrer l’état Échec
lorsque vous essayez de déplacer un groupe qui contient la ressource de disque physique. Si vous redémarrez le
nœud de cluster qui dispose de la ressource de disque physique qui n’a pas été mise en ligne, le problème est
temporairement résolu.
Lorsque ce problème se produit, les entrées suivantes sont enregistrées dans le journal du cluster pour la
ressource de disque physique qui est entrée dans l’état d’échec :
000020cc.000014d0:: <DateTime> ERR Physical Disk <Disk Q:> :

DiskspCheckPath : GetFileAttrs(Q:) état renvoyé de 87.
000020cc.000014d0:: <DateTime> WARN Physical Disk <Disk Q:> :
DiskspCheckDriveLetter : vérification du nom du lecteur (Q:) renvoie 87
En outre, les événements suivants sont consignés dans le journal des événements système :

Source de l’événement : ClusSvc
Catégorie d’événement : ressource de disque physique
Date : <date>
Heure : <time>
Utilisateur : N/A
Ordinateur : <node name>
Description : la ressource de disque de cluster « Disk Q: » est endommagée. Exécutez « ChkDsk /F » pour
résoudre les problèmes. Le nom de volume de cette ressource est « <\ ?\Volume{4323d41e-1379-11dd-
9538-001e0b20dfe6} > ». Si disponible, la sortie ChkDsk sera dans le fichier «
C:\WINDOWS\Cluster\ChkDsk_Disk2_SigB05E593B.log ». ChkDsk peut écrire des informations dans le
journal des événements d’application avec l’ID d’événement 26180.
Source de l’événement : ClusSvc
Catégorie d’événement : ressource de disque physique
Date : <date>
Heure : <time>
Utilisateur : N/A
Ordinateur : <node name>
Description : La ressource de disque de cluster « Disk Q: » n’a pas pu être montée.
De même, sur un nœud de cluster Windows serveur, vous pouvez voir que les entrées suivantes sont
enregistrées dans le journal du cluster :
00000db0.00000868:: <DateTime> WARN [RES] Physical Disk <Cluster Disk 1> : OnlineThread: Failed to get
volume guid for device \ ?\GLOBALROOT\Device\Harddisk15\Partition1. Erreur 3
00000db0.00000868:: <DateTime> WARN [RES] Physical Disk <Cluster Disk 1> : OnlineThread: Failed to set
volguid ? ?\Volume{3cb36133-0d0b-11df-afcf-005056ab58b9}. Erreur : 183.
00000db0.00000868:: <DateTime> INFO [RES] Physical Disk <Cluster Disk 1> : VolumeIsNtfs: Volume \ ?
\GLOBALROOT\Device\Harddisk15\Partition1\ has FS type NTFS
Cause
Ce problème se produit généralement lorsque des logiciels antivirus non pris en compte pour le cluster sont
installés, mis à niveau ou reconfigurés. Par exemple, ce problème est connu après l’installation ou la migration
vers Symantec Endpoint Protection 11.0 Release Update 5 (RU5) sur les nodes de cluster.
Résolution
1. Vérifiez que ce problème est dû à Symantec Endpoint Protection (SEP) 11.0 Release Update 5 (RU5). Pour
ce faire, exécutez l’utilitaire Handle.exe immédiatement après le problème sur le nœud de cluster où la
ressource de disque physique n’a pas été mise en ligne.
À une invite de commandes avec élévation de niveau élevé, tapez la commande suivante, puis appuyez
sur Entrée Handle.exe -a -u drive_letter :
NOTE
L drive_letter un espace réservé est la désignation de lecteur pour le lecteur de cluster qui n’a pas été en ligne.
Par exemple, supposons que la désignation de lecteur pour le lecteur de cluster qui n’a pas été en ligne
est le lecteur Q. Pour exécuter l’utilitaire Handle.exe dans ce scénario, tapez la commande suivante, puis
appuyez sur Entrée : Handle.exe -a -u Q: .
Le problème est dû à l’application Symantec si vous recevez le message suivant qui identifie le processus
Smc.exe comme étant le processus propriétaire du handle :
Gérer la v3.42
Copyright (C) 1997-2008 Mark Russinov
Sysinternals - www.sysinternals.com
Smc.exe pid: 856 NT AUTHORITY\SYSTEM 66C: Q:
2. Si le problème est dû à l’application Symantec, contactez Symantec pour obtenir Symantec Endpoint
Protection 11 Version Update 6 (RU6), qui a été publiée pour résoudre ce problème.
Pour plus d’informations sur Handle.exe'utilitaire, voir Handle v4.22.
produits.
Comment récupérer un objet ordinateur supprimé
qui prend en charge une ressource Nom de réseau
dans un cluster deover
Cet article explique comment récupérer un objet ordinateur supprimé qui prend en charge une ressource Nom
de réseau dans un cluster deover.
Résumé
Par défaut, le nouveau modèle de sécurité dans le clustering de Windows Server 2008 ou Windows Server 2008
R2 inclut l’authentification Kerberos. Pour créer ce modèle de sécurité, chaque point d’accès au client (CAP) créé
dans un cluster de point d’accès au client Windows Server 2008 ou Windows Server 2008 R2 contient une
ressource nom de réseau. La ressource Nom du réseau possède un compte d’ordinateur correspondant qui est
créé dans le service d’annuaire Active Directory lorsque la ressource est en ligne pour la première fois.
Par défaut, le compte d’ordinateur est créé dans le conteneur Ordinateurs. Toutefois, le compte d’ordinateur peut
être déplacé vers une autre unité d’organisation. Le compte d’ordinateur peut également être pré-mis en place
dans une ou plusieurs autres personnes avant la création de la limite d’expérience utilisateur. Si ces comptes
d’ordinateur sont supprimés d’Active Directory, la disponibilité de la ressource Nom du réseau sera réduite.
Les comptes d’ordinateur créés dans Active Directory représentent les ressources nom réseau dans un cluster
deover. Ces comptes ont les types distincts suivants :
Le compte d’ordinateur qui représente le nom du cluster est appelé objet CNO (Cluster Name Object). Ce
compte est le contexte de sécurité principal pour un cluster.
Les autres comptes d’ordinateur qui appartiennent aux ressources Nom de réseau dans le même cluster sont
appelés objets d’ordinateur virtuel (VCOs). Ces comptes sont créés par l’autre CNO. Si l’un de ces comptes est
supprimé d’Active Directory, la prochaine fois que le nom du réseau tente d’être en ligne, le nom du réseau
échoue et le message d’erreur suivant est consigné dans le journal système : ID d’événement : 1207
Niveau d’événement : erreur
Source de l’événement : FailoverClustering
Description : ResourceName du nom de réseau de cluster ne peut pas être mis en ligne. L’objet ordinateur
associé à la ressource n’a pas pu être mis à jour dans domain DomainName pour la raison suivante :
Le texte du code d’erreur associé est : Il n’existe aucun objet de ce type sur le serveur.
L’identité de cluster CNO$Name peut ne pas avoir les autorisations requises pour mettre à jour l’objet.
Travaillez avec votre administrateur de domaine pour vous assurer que l’identité du cluster peut mettre à jour
les objets ordinateur dans le domaine.
et les messages suivants sont consignés dans le journal du cluster :
WARN [RES] Network Name: Trying to remove credentials for LocalSystem returned status C0000225,
STATUS_NOT_FOUND est un échec non critique pour un nom de réseau INFO [RES] opération de suppression : à
l’origine de l’opération Nom du réseau : « Vérification de l’objet ordinateur associé à la ressource nom réseau
FSCAP01 » INFO [RES] Nom du réseau : tentative de recherche du GUID de l’objet <FSCAP01> FSCAP01 du
compte d’ordinateur(d66e09dd8857e84da1f3a26fb1903e38) sur n’importe quel contrôleur de domaine
<FSCAP01> <FSCAP01> disponible. WARN [RES] Nom du réseau : la <FSCAP01> recherche du compte
d’ordinateur existant a échoué. status 80072030 WARN [RES] Network <FSCAP01> Name: Search for existing
computer account failed. status 80072030 INFO [RES] Network Name <FSCAP01> : Trying to find object
d66e09dd8857e84da1f3a26fb1903e38 on a PDC. WARN [RES] Nom du réseau : la <FSCAP01> recherche du
compte d’ordinateur existant a échoué. status 80072030 INFO [RES] Network Name : Impossible de trouver
l’objet <FSCAP01> d66e09dd8857e84da1f3a26fb1903e38 sur un PDC. INFO [RES] Nom du réseau
<FSCAP01> : Échec de GetComputerObjectViaGUIDEx(), État 80072030. WARN [RES] Nom du réseau : si vous
essayez de supprimer les informations d’identification de l’état renvoyé par LocalSystem C0000225,
STATUS_NOT_FOUND est un échec non critique pour une opération de suppression que la ressource
<FSCAP01> WARN [RHS] FSCAP01 a indiqué qu’elle ne peut pas être mise en ligne sur ce nœud. WARN [RCM]
HandleMonitorReply: ONLINERESOURCE for 'FSCAP01', gen(8) result 5015.
Remarque : status 80072030 = Il n’existe aucun objet de ce type sur le serveur
Toutefois, des problèmes se produisent même avant que la ressource Nom du réseau ne soit cycle hors
connexion et en ligne. Par exemple, un utilisateur ou une application hautement disponible peut ne pas être en
mesure d’accéder aux ressources lorsqu’un jeton de sécurité qui représente l’objet ordinateur de cluster dans
Active Directory ne peut pas être obtenu.
La récupération à partir de la suppression d’un objet Ordinateur associé à une ressource nom de réseau de
cluster est différente pour un objet réseau de cluster par rapport à la récupération à partir de la suppression
d’un objet ordinateur pour un objet VCO.
Pour récupérer un objet ordinateur supprimé qui correspond à l’objet réseau de réseau de point de récupération,
1. Coordonner avec un administrateur de domaine pour récupérer d’abord l’objet ordinateur supprimé à
partir du conteneur Objets supprimés dans Active Directory.
2. Vérifiez que l’objet Ordinateur a été restauré à l’emplacement correct, puis activez le compte.
3. Forcer la réplication de domaine ou attendre l’intervalle de réplication configuré.
4. Dans le snap-in MMC (Failover Cluster Management Console), cliquez avec le bouton droit sur le nom du
réseau qui correspond au nom du cluster, pointez sur Plus d’actions, puis cliquez sur Réparer l’objet
Active Director y.
NOTE
L’utilisateur qui suit ces étapes dans le snap-in MMC Gestion du cluster de failover doit également avoir l’autorisation «
Réinitialiser les mots de passe » dans le domaine.
Pour récupérer un objet ordinateur supprimé qui correspond à un objet VCO, suivez les étapes suivantes :
1. Coordonner avec un administrateur de domaine pour récupérer d’abord l’objet ordinateur supprimé à partir
du conteneur Objets supprimés dans Active Directory.
2. Vérifiez que l’objet ordinateur a été restauré à l’emplacement correct, puis activez le compte.
3. Affichez les paramètres de sécurité de l’objet ordinateur, puis vérifiez que l’objet réseau de mise en réseau
dispose toujours d’autorisations sur l’objet.
4. Forcer la réplication de domaine ou attendre l’intervalle de réplication configuré.
5. Dans le snap-in MMC Gestion du cluster de failover, cliquez avec le bouton droit sur la ressource Nom de
réseau qui a échoué, puis cliquez sur **Mettre cette ressource en ligne. Si un objet ordinateur supprimé
n’existe plus dans le conteneur Objets supprimés, l’objet n’a jamais exister ou a été supprimé et la garbage
collected après la réunion ou le dépassement de la durée de vie de tombstone. Ne restituer jamais AD à
partir d’une sauvegarde plus ancienne que la durée de vie de tombstone. Cela peut induire des objets en
attente dans l’environnement.
Références
Pour plus d’informations, consultez les sites Web Microsoft suivants :
Récupération d’un objet CNO (Deleted Cluster Name Object) dans un cluster de Windows Server 2008
ID d’événement 1207 - Autorisations Active Directory pour les comptes de cluster
Sauvegarde et restauration d’Active Directory
Nouvelles fonctionnalités SMB 3.0 dans le serveur
de fichiers Windows Server
Cet article décrit les nouvelles fonctionnalités du protocole SMB (Server Message Block) 3.0.
S’applique à : Windows 8.1 - toutes les éditions, Windows Server 2012 R2 et les versions ultérieures de
Windows
Résumé
Windows Le serveur introduit de nouvelles fonctionnalités de serveur de fichiers SMB (Server Message Block).
Pour tirer parti de ces nouvelles fonctionnalités, le client SMB et le serveur SMB doivent prendre en charge SMB
3.0.
Le protocole SMB 2.x a été introduit dans Windows Server 2008 et Windows Vista.
Le protocole SMB 3.0 a été introduit dans Windows Server 2012 et dans Windows 8.
Nouvelles fonctionnalités SMB introduites dans le serveur Windows

fichiers
SMB Transparent Failover
SMB Scale Out
SMB multicanal
SMB direct
Chiffrement SMB
VSS pour les partages de fichiers SMB
Location d'annuaire SMB
PowerShell SMB
SMB Transparent Failover
Le client SMB et le serveur SMB doivent prendre en charge SMB 3.0 pour tirer parti de la fonctionnalité deover
transparent SMB.
Les clients SMB 1.0 et SMB 2.x peuvent se connecter aux partages configurés pour utiliser la propriété
Continuously Available et y accéder. Toutefois, les clients SMB 1.0 et SMB 2.x ne bénéficieront pas de la
fonctionnalité deover transparent SMB. Si le nœud de cluster actuellement accessible devient indisponible ou si
l’administrateur effectue des modifications administratives sur le serveur de fichiers en cluster, le client SMB 1.0
ou SMB 2.x perd la session SMB active et les poignées ouvertes sur le serveur de fichiers en cluster. L’utilisateur
ou l’application sur l’ordinateur client SMB doit prendre des mesures correctives pour rétablir la connectivité au
partage de fichiers en cluster.
NOTE
Le failover transparent SMB n’est pas compatible avec les volumes activés pour la prise en charge du nom de fichier court
(8.3 nom de fichier) ou avec les fichiers compressés (tels que les fichiers compressés NTFS).
SMB Scale Out
Le client SMB et le serveur SMB doivent prendre en charge SMB 3.0 pour tirer parti de la fonctionnalité SMB
Scale Out.
Les clients SMB 1.0 ne contiennent pas les fonctionnalités client requises pour accéder aux partages de fichiers
avec mise à l’échelle SMB et recevront un message d’erreur Accès refusé lorsqu’ils essaieront de se connecter à
un partage de fichiers avec mise à l’échelle.
Les partages de fichiers avec mise à l’échelle SMB sont toujours configurés de sorte que la propriété
Continuously Available (Disponible en continu) soit définie. Les clients SMB 2.x pourront se connecter aux
partages de fichiers avec échelle SMB, mais ne bénéficieront pas de la fonctionnalité deover transparent SMB.
SMB multicanal
Le client SMB et le serveur SMB doivent prendre en charge SMB 3.0 pour tirer parti de la fonctionnalité SMB
Multichannel. Les clients SMB 1.0 et SMB 2.x utiliseront une seule connexion SMB.
SMB Direct (SMB over Remote Direct Memory Access [RDMA ])
SMB Direct est disponible dans Windows Server 2012, Windows 10 (Enterprise, Éducation et Pro pour les
éditions Workstations) et versions ultérieures. La fonctionnalité SMB Direct nécessite que le client SMB et le
serveur SMB la prise en charge de SMB 3.0.
Chiffrement SMB
Le client SMB et le serveur SMB doivent prendre en charge SMB 3.0 pour tirer parti de la fonctionnalité de
chiffrement SMB.
VSS pour les partages de fichiers SMB
Le client SMB et le serveur SMB doivent prendre en charge SMB 3.0 pour tirer parti de la fonctionnalité vsS
(Volume Shadow Copy Service) pour les partages de fichiers SMB.
Location d'annuaire SMB
Le client SMB et le serveur SMB doivent prendre en charge SMB 3.0 pour tirer parti de la fonctionnalité de bail
d’annuaire SMB.
PowerShell SMB
Les cmdlets de gestion SMB PowerShell ont été introduites dans Windows Server 2012 et dans Windows 8. Les
anciens clients SMB et serveurs SMB devront continuer à utiliser des outils de bas niveau pour la gestion (par
exemple, net.exe) et les API (par exemple, les API Win32).
Références
Pour plus d’informations sur les erreurs courantes que vous pouvez constater avec SMB 3.0, voir
/troubleshoot/windows-server/networking/error-messages-smb-connections.
Fichier de vidage mémoire endommagé lorsque
vous essayez d’obtenir un fichier de vidage mémoire
complet à partir d’une machine virtuelle en cours
d’exécution dans un environnement de cluster
Cet article fournit une solution à un problème dans lequel un fichier de vidage de mémoire endommagé est
généré lorsque vous essayez d’obtenir un fichier de vidage mémoire complet à partir d’une machine virtuelle.
Symptômes
Vous avez une machine virtuelle qui s’exécute dans un environnement de cluster dans Windows Server 2012 ou
Windows Server 2008 R2. Lorsque vous essayez d’obtenir un fichier de vidage mémoire complet à partir de la
machine virtuelle, un fichier de vidage de mémoire endommagé est généré. Pendant le chargement du fichier de
vidage mémoire, vous pouvez recevoir le message suivant :
CE FICHIER DE VIDAGE EST PARTIELLEMENT ENDOMMAGÉ.

KdDebuggerDataBlock n’est pas présent ou illisible.
Échec de GetContextState, 0xD0000147

Impossible d’obtenir le compteur de programme
Échec de GetContextState, 0xD0000147
Impossible d’obtenir le contexte de l’ordinateur actuel, NTSTATUS 0xC0000147
En outre, vous remarquerez peut-être que l’écriture d’un fichier de vidage mémoire complet ne se termine pas
et que la machine virtuelle est redémarré sur un autre nœud du cluster.
Cause
Ce problème se produit car l’option Activer la surveillance de pulsations pour l’ordinateur virtuel est
sélectionnée pour la machine virtuelle. Cette option réinitialise la machine virtuelle en cluster après une minute
(valeur par défaut), et la machine virtuelle en cluster nécessite plus d’une minute pour terminer l’écriture du
vidage de mémoire.
NOTE
Les pulsations entre la machine virtuelle et Virtual Machine Manager se produisent toutes les quelques secondes. Il peut
prendre jusqu’à une minute pour détecter que la machine virtuelle est en panne, car la ressource de la machine virtuelle
vérifie l’état de pulsation à partir de Virtual Machine Manager dans sa fonction de point d’entrée isAlive. Par défaut, isAlive
se produit une fois par minute. Toutefois, les pulsations peuvent s’arrêter 30 secondes avant l’intervalle d’une minute.
Dans ce cas, le cluster peut redémarrer la machine virtuelle sur le même serveur ou la faire échouer sur un autre nœud.
Résolution
Pour résoudre ce problème, désactivez l’option Activer la sur veillance de pulsations pour l’ordinateur
virtuel.
Option 1 : modifier les paramètres à partir de l’interface graphique graphique
1. Ouvrez le Gestionnaire du cluster de failover.
2. Cliquez sur Rôles, puis recherchez la ressource de machine virtuelle.
3. Sous l’onglet Ressources, cliquez avec le bouton droit sur la machine virtuelle.
4. Cliquez sur Propriétés, puis cliquez sur l’Paramètres’onglet.
5. Dans Paramètre de pulsation, cliquez pour effacer la case à cocher Activer la récupération automatique
pour l’analyse de l’état de l’application.
6. Cliquez pour activer la case à cocher Activer l’analyse de pulsations pour la machine virtuelle, puis cliquez
sur OK.
Option 2 : modifier les paramètres à l’aide de Windows PowerShell
1. Démarrez Windows PowerShell.
2. Vérifiez le nom de la machine virtuelle. Pour ce faire, tapez la commande Windows PowerShell suivante :
PS C:\> Get-ClusterResource
3. Vérifiez si l’option Activer la surveillance de pulsations pour l’ordinateur vir tuel et Activer la
récupération automatique pour les options d’analyse de l’état des applications est sélectionnée. Pour ce
faire, tapez la commande Windows PowerShell suivante :
PS C:\> Get-ClusterResource <VirtualMachineName> | Get-ClusterParameter CheckHeartbeat
4. Lorsque la valeur CheckHeartbeat est 1, les deux options sont sélectionnées. Pour annuler les deux
options, modifiez cette valeur sur 0. Pour ce faire, tapez la commande Windows PowerShell suivante :
PS C:\> Get-ClusterResource <VirtualMachineName> | Set-ClusterParameter CheckHeartbeat 0
Si vous souhaitez annuler uniquement l’option Activer la récupération automatique pour l’analyse de
l’état de l’application, vous devez exécuter la commande Windows PowerShell suivante :
PS C:\> (Get-ClusterResource <Object>).EmbeddedFailureAction = 1
Les fichiers de vidage mémoire mini et noyau sont écrits avec succès. Cela se produit car le temps nécessaire à
l’écriture de ces fichiers ne dépasse pas le seuil d’une minute.
Le service de cluster ne parvient pas à démarrer les
conseils de résolution des problèmes

Vérifier les ports utilisés par le service de cluster
Assurez-vous que les ports suivants sont ouverts au trafic de cluster sur les pare-feu :
Port 135 : Mappeur de point de terminaison d’appel de procédure distante (RPC) ou modèle objet de
composant distribué (DCOM).
Port 135 : mappeur de point de terminaison RPC sur le protocole UDP (User Datagram Protocol).
Port 3343 : pilote réseau de cluster.
Port 445 : bloc de messages serveur (SMB).
Port 139 : service de session NetBIOS.
Ports compris entre 5 000 et 5 099 : si l’ID d’événement 1721 est journalisé lorsque vous vous connectez
à un cluster en tant qu’administrateur de cluster, essayez d’ouvrir les ports de cette plage (ou d’autres
ports) au trafic RPC. Les ports prennent en charge la communication via RPC, sauf si vous tapez
simplement un caractère de point (.).
Ce problème peut se produire car le service de cluster utilise au moins 100 ports pour la communication
RPC. Le nombre de ports disponibles pour le service de cluster peut devenir trop faible lorsque d’autres
services utilisent certains des ports nécessaires. Ces services peuvent inclure Windows service DNS,
Windows service WINS (Internet Name Service) ou Microsoft SQL Server service.
Ports compris entre 8 011 et 8 031 : si les pare-feu séparent les nœuds de cluster, les ports compris entre
8011 et 8031 doivent être ouverts au trafic RPC d’internode. Sinon, les erreurs dans le journal du cluster
indiquent qu’un nœud sponsor n’est pas disponible. Ces erreurs se produisent parce qu’il n’y a pas
suffisamment de ports disponibles pour la communication RPC entre un nœud qui tente de joindre le
cluster et un nœud qui peut parrainer ce nœud.
Pour plus d’informations sur la configuration d’un réseau et des ports réseau pour un cluster, consultez les
articles suivants :
Activer un réseau pour l’utilisation du cluster
Vue d'ensemble des services et exigences de ports réseau pour Windows
Après avoir modifié les paramètres de port, essayez de remettre le nœud en ligne avant de continuer.
Exécuter l’outil de validation de cluster
1. Ouvrez le composant logiciel enfichable Gestionnaire du cluster de basculement (CluAdmin.msc).
2. Sélectionnez Gestionnaire du cluster de basculement dans la colonne supérieure gauche.
3. Sélectionnez Valider la configuration .
4. Tapez le nom de chaque nœud du cluster, puis sélectionnez Ajouter après chacun d’eux.
5. Lorsque tous les nœuds ont été ajoutés aux ser veurs sélectionnés : liste, sélectionnez Suivant .
6. Sélectionnez Exécuter tous les tests (recommandés) > NextNext > .
7. Autorisez la fin du test. Une fois l’opération terminée, sélectionnez Afficher le rappor t .
8. Passez en revue les résultats des tests étiquetés Échec ou Aver tissement . Ces informations peuvent
vous aider à fournir des étapes actionnables pour résoudre le problème.
9. Pour obtenir un fichier téléchargeable, accédez au dossier C:\Windows\Cluster\Reports et ouvrez le
rapport de validation (. Fichier MHT).
NOTE
Dans Windows Server 2016 et versions ultérieures, il s’agit d’un fichier .HTM.
Vérifier les stratégies de sécurité susceptibles d’affecter le nœud de cluster

Dans l’éditeur d’objet stratégie de groupe, ces objets de stratégie se trouvent dans Configuration
ordinateur\Windows Paramètres\Sécurité Paramètres\Stratégies locales\Attribution des droits utilisateur.
NOTE
Pour accéder aux paramètres de stratégie de sécurité locale, sélectionnez Démarrer , tapez une stratégie de sécurité
locale , puis sélectionnez Stratégie de sécurité locale .
Assurez-vous que la liste des comptes inclut les comptes responsables de l’exécution du nœud de cluster.
Pour plus d’informations, consultez Comment accéder à cet ordinateur à partir du réseau et autoriser la
connexion au paramètre de stratégie de sécurité locale.
Assurez-vous que la liste des comptes n’inclut pas les comptes locaux. Pour plus d’informations,
consultez Comment refuser l’accès à cet ordinateur à partir du réseau.
Assurez-vous que la liste des comptes et des groupes n’inclut pas le groupe « Tout le monde ». Pour plus
d’informations, consultez Refuser le paramètre de stratégie de sécurité locale.
Après avoir modifié les paramètres de stratégie, essayez de remettre le nœud en ligne avant de continuer.
Désactiver temporairement les pare -feu
Désactivez le pare-feu entre le nœud et le reste du cluster, puis essayez de le remettre en ligne. Si le nœud n’est
toujours pas en ligne, le pare-feu peut en être la cause.
IMPORTANT
Ne laissez pas cette modification en place une fois que vous avez terminé la résolution des problèmes. Après avoir utilisé
cette modification pour le test, retournez ces paramètres à la configuration d’origine.
Rechercher les problèmes liés au matériel et aux logiciels réseau

Recherchez dans le journal des événements système les erreurs matérielles ou logicielles liées aux cartes
réseau sur ce nœud.
Vérifiez la carte réseau, les câbles et la configuration réseau des réseaux qui connectent les nœuds.
Si vous associez les cartes réseau, assurez-vous que la configuration d’association est correcte.
Vérifiez les hubs, commutateurs ou ponts dans les réseaux qui connectent les nœuds.
Passer en revue les fichiers journaux
Pour identifier la source du problème, passez en revue les informations de journal provenant de plusieurs
sources. Par exemple :
Dans observateur d'événements, accédez aux journaux des applications et
services\Microsoft\Windows\FailoverClustering-Client\Diagnostic, puis passez en revue les journaux de
suivi du débogage de l’API de cluster.
Générez un nouveau journal de cluster pour le nœud. Sur le serveur qui exécute le nœud affecté, ouvrez
une invite PowerShell avec élévation de privilèges et exécutez l’applet de commande suivante :
Get-ClusterLog -Node 'Local Node Name' -Destination c:\temp -UseLocalTime
Pour générer une trace plus détaillée, procédez comme suit :

1. À une invite PowerShell avec élévation de privilèges, exécutez l’applet de commande suivante pour
démarrer la trace :
logman create trace "base_cluster" -ow -o c:\base_cluster.etl -p "Microsoft-Windows-
FailoverClustering-Client" 0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode Circular -f bincirc -max
4096 -ets
2. Reproduisez le problème.
3. Pour arrêter la trace, exécutez l’applet de commande suivante :
Logman stop base_cluster.etl -ets
4. Pour convertir la trace, exécutez l’applet de commande suivante :

Netsh trace convert base_cluster.etl
5. Pour générer un journal de cluster à partir des données, exécutez l’applet de commande suivante :
Get-ClusterLog -Node 'Local Node Name' -Destination c:\temp -UseLocalTime
Pour plus d’informations sur le suivi et d’autres problèmes à rechercher, consultez Comment résoudre les
problèmes de création d’échecs de cluster.
Options de démarrage du service de cluster
Cet article répertorie tous les commutateurs disponibles qui peuvent être utilisés comme paramètres de
démarrage pour démarrer le service de cluster.
Résumé
Il s’agit d’une liste de tous les commutateurs disponibles qui peuvent être utilisés comme paramètres de
démarrage pour démarrer le service de cluster.
Pour ce faire, allez aux propriétés du service, placez le commutateur approprié dans la zone Paramètres de
démarrage, puis cliquez sur Démarrer.
Vous pouvez également utiliser les commutateurs lorsque vous démarrez le service de cluster à partir de la
ligne de commande. Par exemple :
net start clussvc.exe / switch
NOTE
Incluez un tiret (-) avant le commutateur pour Microsoft Windows 2000 Server et les versions antérieures.
Le commutateur de débogage possède des paramètres de démarrage spéciaux. Pour une utilisation correcte, consultez la
section Débogage plus loin dans cet article.
Windows Server 2003 inclut des abréviations pour chaque commutateur. Cela simplifie l’utilisation des
commutateurs de démarrage du service de cluster. Par exemple, vous pouvez démarrer le service avec le
/FixQuorum commutateur ou le /FQ commutateur.
Les commutateurs d’options valides sont les suivants :
C O M M UTAT EUR F O N C T IO N W IN DO W S A B RÉVIAT IO N 2003
FixQuorum Ne montez pas le périphérique de FQ

quorum et la journalisation du quorum
est désactivée.
NoQuorumLogging Journalisation du quorum désactivée. NQ
Débogage Affiche les événements au début du

service de cluster. Pour obtenir une
syntaxe spéciale, consultez la section «
Débogage » plus loin dans cet article.
LogLevel N Définit le niveau de journal pour le

mode débogage.
DebugResMon Le service de cluster attend qu’un DR

débogger soit joint à tous les
processus du Moniteur de ressources
au démarrage.
Windows commutateurs 2000 et ultérieurs sont les suivants uniquement.
ResetQuorumLog Re-crée dynamiquement le journal de RQ

quorum et les fichiers de point de
contrôle (cette fonctionnalité est
automatique dans Microsoft Windows
NT 4.0).
NoRepEvtLogging Aucune réplication des entrées du

journal des événements.
Windows Server 2003 et les commutateurs ultérieurs incluent uniquement les commutateurs suivants.
ForceQuorum ou <N1,N2,...> Forcer un nœud majoritaire avec la FO

liste de nœuds N1, N2, etc. (Applicable
uniquement pour le quorum de jeu de
nœuds majoritaires.)
NoGroupInfoEvtLogging Ne journalez pas les événements dans NG

le journal des événements associé au
groupe en ligne et hors connexion.
Description des commutateurs

Voici une description de certains commutateurs :
Débogage
Fonction : la journalisation du cluster peut ne pas contenir d’informations utiles lors du diagnostic du service de
cluster pour démarrer les défaillances. Cela est dû au fait que le service de cluster peut échouer avant le
démarrage de Cluster.log. Le démarrage du service de cluster avec ce commutateur affiche l’initialisation du
service de cluster et peut vous aider à identifier ces problèmes précoces.
Conditions requises : utilisez ce commutateur uniquement à des fins de diagnostic temporaire. Si le service de
cluster ne parvient pas à démarrer en raison d’une erreur d’accès au compte de service ou d’une autre erreur
liée au système, il se peut que le service n’a pas la possibilité de s’exécuter. Par conséquent, il se peut qu’un
fichier cluster.log ne soit pas créé. Cette méthode exécute le service en dehors de l’environnement normal donné
par le Gestionnaire de contrôle de service. Pour utiliser ce commutateur, vous devez être connecté localement
avec des droits d’administration et démarrer la commande à partir de l’invite de commandes. N’utilisez pas le
commutateur de débogage pour une utilisation normale ou pour une durée quelconque. Le service ne s’exécute
pas aussi efficacement avec l’option définie.
Scénarios d’utilisation : ce commutateur ne doit être utilisé que lorsque le démarrage du service de cluster
échoue. Ce commutateur affiche à l’écran le fonctionnement du service de cluster à mesure qu’il tente de
démarrer. Ce commutateur ne peut être utilisé que lors du démarrage du service à partir de l’invite de
commandes, et vous devez vous trouver dans le dossier où le service de cluster est installé. Par défaut, il s’agit
de %SystemRoot%\Cluster. Il s’agit également du seul commutateur que vous n’utilisez pas avec la commande
net start pour démarrer le service.
Opération : Ouvrez une invite de commandes, modifiez le dossier %SystemRoot%\cluster, puis tapez ce qui suit
clussvc /debug [loglevel#] " .
où loglevel# est l’un des suivants.
# DESC RIP T IO N
0 Aucune journalisation n’a lieu.
1 Seules les erreurs sont consignées.
2 Les erreurs et avertissements sont consignés.
3 Tous les événements, y compris ceux qui ne sont pas écrits

dans le journal des événements, sont enregistrés.
Vous pouvez également utiliser la commande set pour contrôler le niveau de journal de cluster lorsque vous
utilisez le commutateur de débogage. À partir de l’invite de commandes, tapez l’ensemble clusterloglevel= x où
x est l’une des valeurs indiquées dans le tableau précédent.
Le service de cluster envoie une sortie à la fenêtre semblable à ce que vous voyez dans cluster.log. Vous pouvez
également capturer ces informations dans un fichier à l’aide de la syntaxe de commande suivante :
clussvc /debug > c:\debug.log
Lorsque le service de cluster s’exécute correctement, appuyez sur Ctrl+C pour arrêter le service.
NOTE
Vous pouvez utiliser la variable d’environnement ClusterLogLevel pour contrôler le niveau de sortie lorsque vous utilisez le
commutateur de débogage.
FixQuorum
Fonction : permet au service de cluster de démarrer malgré des problèmes avec le périphérique de quorum. Les
seules ressources qui seront mise en ligne une fois le service démarré sont l’adresse IP du cluster et le nom du
cluster. Vous pouvez ouvrir l’administrateur de cluster et mettre d’autres ressources en ligne manuellement.
Conditions requises : ce commutateur DOIT être utilisé uniquement en mode de diagnostic sur une base très
temporaire et non pendant un fonctionnement normal. Un seul nœud doit être démarré à l’aide de ce
commutateur et un second nœud ne doit pas être tenté d’être joint au nœud démarré à l’aide de ce
commutateur. En règle générale, ce commutateur est utilisé seul.
Scénarios d’utilisation : Si le service de cluster ne parvient pas à démarrer normalement en raison de l’échec de
la ressource de quorum, les utilisateurs peuvent démarrer le service de cluster dans ce mode et tenter de
diagnostiquer l’échec.
Opération : Une fois le service de cluster démarré, toutes les ressources, y compris la ressource de quorum,
restent hors connexion. Les utilisateurs peuvent ensuite essayer manuellement de mettre la ressource de
quorum en ligne et de surveiller les entrées du journal de cluster, ainsi que les nouvelles entrées du journal des
événements, et tenter de diagnostiquer les problèmes liés à la ressource de quorum. La syntaxe est la suivante :
net start clussvc /fixquorum .
ResetQuorumLog
Fonction : si le journal de quorum et le fichier de point de contrôle sont in trouvés ou endommagés, vous
pouvez utiliser cette fonction pour créer des fichiers en fonction des informations de la ruche du Registre
%SystemRoot%\Cluster\CLUSDB du nœud local. Si le fichier journal de quorum est trouvé dans un ordre
correct, ce commutateur n’a aucun effet.
Conditions requises : en règle générale, un seul nœud est démarré à l’aide de ce commutateur, et ce
commutateur est utilisé seul. Il doit être utilisé uniquement par les utilisateurs expérimentés qui comprennent
les conséquences de l’utilisation d’informations potentiellement insoumses pour créer un fichier journal de
quorum.
Scénarios d’utilisation : ce commutateur ne doit être utilisé que lorsque le service de cluster ne parvient pas à
démarrer sur un ordinateur Windows 2000 ou ultérieur en raison d’un journal de quorum manquant ou
endommagé (Quolog.log) et de fichiers Chkxxx.tmp. Windows NT 4.0 re-crée automatiquement ces fichiers s’ils
n’existent pas. Cette fonctionnalité a été ajoutée dans Windows 2000 pour mieux contrôler le démarrage du
service de cluster.
NOTE
Si le cluster est en cours d’exécution Windows 2000 Service Pack 4 (SP4) et que le correctif logiciel 872970 a été installé
précédemment, /resetquorumlog n’est plus nécessaire. Le comportement par défaut consiste à créer un nouveau fichier
journal au démarrage si l’ancien fichier est manquant ou endommagé.
Opération : le service de cluster réinitialise automatiquement le fichier journal de quorum s’il est trouvé
manquant ou endommagé à l’aide des informations de la ruche de cluster actuellement chargée à l’aide du
fichier %systemroot%\Cluster\CLUSDB. La syntaxe est la suivante :
net start clussvc /resetquorumlog
DebugResMon
Fonction : vous permet de déboguer le processus de surveillance des ressources et, par conséquent, les
bibliothèques de liens dynamiques de ressources (DLL) chargées par le moniteur de ressources. Vous pouvez
utiliser n’importe quel débo Windows standard.
Conditions requises : ne peut être utilisé que lorsque le service de cluster est démarré à partir de l’invite de
commandes et lors de l’utilisation du commutateur de débogage. Il n’existe aucun paramètre de Registre
équivalent qui peut être utilisé lorsque le service de cluster est exécuté en tant que service. Le débogger doit
être disponible pour être attaché au moniteur de ressources au démarrage. En règle générale, ce commutateur
est utilisé seul.
Scénarios d’utilisation : les développeurs peuvent utiliser ce commutateur pour déboguer le processus du
moniteur de ressources et leurs DLLs de ressources personnalisées. Cette option est extrêmement utile si un
bogue dans une DLL de ressource entraîne un arrêt inattendu du processus du moniteur de ressources peu de
temps après sa mise en route par le service de cluster et avant que les utilisateurs ne peuvent joindre
manuellement un débogger au processus du moniteur de ressources.
Opération : juste avant le début du processus de surveillance des ressources, le processus de service de cluster
attend avec un message (En attente de la connexion du débogger au processus de resmon X ), où X est l’ID de
processus (PID) du processus de surveillance des ressources. Le service de cluster le fait en attendant que tous
les processus de surveillance des ressources créés par celui-ci. Une fois que l’utilisateur joint un débogger au
processus de surveillance des ressources et que le processus du moniteur de ressources démarre, le service de
cluster poursuit son initialisation.
NoRepEvtLogging
Fonction : le commutateur norepevtlogging empêche la réplication de ces événements enregistrés dans le
journal des événements. Ce commutateur est utile pour réduire la quantité d’informations affichées dans la
fenêtre de commande en filtrant les événements déjà enregistrés dans le journal des événements. La réplication
du journal des événements est une fonctionnalité ajoutée dans Windows 2000.
Scénarios d’utilisation : ce commutateur est utilisé pour empêcher la réplication des journaux d’événements. S’il
existe un grand nombre d’entrées du journal des événements, le service de cluster réplique ces entrées et les
enregistre dans cluster.log. Cela peut entraîner l’encapsuler rapidement du fichier cluster.log. Le commutateur
peut également être utilisé pour démarrer le service de cluster et consigner les événements qui ne sont pas
enregistrés dans le journal des événements dans un fichier local, Debugnorep.log. La syntaxe est la suivante :
clussvc /debug /norepevtlogging > c:\debugnorep.log\
Opération : la commande norepevtlogging peut être définie comme paramètre de démarrage lors du
démarrage du service de cluster à partir de la console de gestion de l’ordinateur.
La syntaxe de ligne de commande est la suivante :
net start clussvc /norepevtlogging
Cette commande empêche le nœud qui a été démarré avec ce commutateur de répliquer ses informations vers
d’autres nœuds, mais elle recevra toujours des informations d’autres nœuds démarrés normalement.
NoQuorumLogging
Fonction : éteint toutes les modifications apportées au registre de cluster sur le disque de quorum. Le pointage
de vérification du Registre n’affecte pas les autres ressources.
Conditions requises : ce commutateur doit être utilisé uniquement en mode diagnostic pour diagnostiquer les
problèmes liés au fichier journal de quorum (Quolog.log) ou au fichier de point de contrôle de la ruche de
cluster (Chkxxx.tmp) dans le répertoire \MSCS sur le lecteur de quorum. Si un nœud est démarré à l’aide de ce
commutateur, tout autre nœud doit également être démarré à l’aide de ce commutateur. En règle générale, ce
commutateur est utilisé sur un seul nœud.
Scénarios d’utilisation : utilisez ce commutateur lorsque le fichier journal de quorum ou les fichiers de point de
contrôle sont endommagés et que vous souhaitez remplacer manuellement ces fichiers par des copies de
sauvegarde.
Opération : le service de cluster ignore complètement la fonctionnalité de journalisation dans ce cas. Lorsqu’il
est exécuté dans ce mode, des scénarios de « partition dans le temps » peuvent se produire. Si tel est le cas, les
entrées de Registre de nœud de cluster peuvent ne plus être synchronisées et de nouvelles modifications
peuvent être perdues. La syntaxe est la suivante : net start clussvc /noquorumlogging .
ForceQuorum
Fonction : lorsque vous utilisez un modèle de quorum MNS (Majority Node Set) sur un cluster Windows Server
2003, dans certains cas, un cluster doit être autorisé à continuer à s’exécuter même s’il n’a pas de quorum
(majoritaire). Prenons le cas d’un cluster géographiquement dispersé avec quatre nodes sur le site principal et
trois sur le site secondaire. Bien qu’il n’y a pas d’échec, le cluster est un cluster à sept nœuds où les ressources
peuvent être hébergées sur n’importe quel nœud, sur n’importe quel site. En cas d’échec des communications
entre les sites ou si le site secondaire est mis hors connexion (ou échoue), le site principal peut continuer car il
aura toujours le quorum. Toutes les ressources seront ré-hébergées et mise en ligne sur le site principal.
Toutefois, en cas de défaillance catastrophique du site principal, le site secondaire perd le quorum et, par
conséquent, toutes les ressources sont terminées sur ce site. L’un des principaux objectifs d’un cluster multisesse
consiste à résister à un sinistre sur le site principal ; toutefois, le logiciel de cluster lui-même ne peut pas
déterminer l’état du site principal. Le logiciel de cluster ne peut pas faire la différence entre un échec de
communication entre les sites et un sinistre sur le site principal. Cette opération doit être effectuée
manuellement. En d’autres termes, le site secondaire peut être forcé de continuer même si le service de cluster
pense qu’il n’a pas de quorum. C’est ce qu’on appelle le forçage du quorum.
Étant donné que ce mécanisme est en train de rompre efficacement la sémantique associée au jeu de réplicas de
quorum, il ne doit être effectué que dans des conditions contrôlées. Dans l’exemple ci-dessus, si le site
secondaire et le site principal perdent la communication et qu’un administrateur force le quorum sur le site
secondaire, les ressources sont mise en ligne sur les deux sites, ce qui permet d’obtenir des données
incohérentes ou une altération des données dans le cluster.
Conditions requises : forcer le quorum est un processus manuel qui nécessite l’arrêt du service de cluster sur
TOUS les autres nodes. Le service de cluster doit être informé des nodes qui doivent être considérés comme
ayant le quorum.
Scénarios d’utilisation : une attention particulière doit être prise si et quand le site principal revient, car les nodes
sont configurés dans le cadre du cluster. Lorsqu’un cluster est en cours d’exécution dans l’état de quorum de
force, il est entièrement fonctionnel. Par exemple, les nodes peuvent être ajoutés ou supprimés du cluster ; de
nouvelles ressources, de nouveaux groupes, etc., peuvent être définis.
NOTE
Le service de cluster sur tous les nœuds NON dans la liste des nœuds de quorum de force doit rester arrêté jusqu’à ce
que les informations de quorum de force soient supprimées. Si vous ne le faites pas, cela peut entraîner des incohérences
de données ou une altération des données.
Opération : configurer les paramètres de démarrage du service de cluster sur TOUS les autres nodes du cluster.
Pour ce faire, démarrez le panneau de contrôle Services, sélectionnez le service de cluster, puis entrez ce qui suit
dans l’option Paramètres de démarrage :
net start clussvc /forcequorum node_list
Par exemple, si le site secondaire contient Node5, Node6 et Node7, et que vous voulez démarrer le service de
cluster et que ces derniers soient les seuls nœuds du cluster, utilisez la commande suivante :
net start clussvc /forcequorum /forcequorum node5,node6,node7
NOTE
Il ne doit y avoir aucun espace dans la clé (sauf s’il y a des espaces dans les noms de nœuds eux-mêmes).
Le service de cluster cesse de répondre sur un
nœud de cluster lorsque vous redémarrez le nœud
actif
Cet article fournit une solution au problème où le service de cluster cesse de répondre sur un nœud de cluster
lorsque vous redémarrez le nœud actif.
Symptômes
Lorsque vous redémarrez le nœud actif d’un cluster de serveurs composé d’au moins deux nœuds, vous pouvez
voir tous les symptômes suivants :
Si vous exécutez l’administrateur de cluster sur les autres, vous recevez le message d’erreur suivant
lorsque vous essayez de vous connecter au cluster :
Cluster 'ClusterName ' n’est plus disponible.
Si vous essayez de démarrer l’administrateur de cluster, l’administrateur de cluster cesse de répondre et

vous pouvez recevoir le message d’erreur suivant :
Une erreur s’est produite lors de la tentative d’ouverture du cluster sur «Ser verName » :
L’interface est inconnue.
ID d’erreur : 1717 (000006b5).
Lorsque vous affichez le contenu de C:\Winnt \ Cluster.log, vous voyez des informations semblables à :
[FM] OnlineGroup : Échec sur la ressource e3f4af72-6454-4199-b9af-fa6f57032a65. État 70

Le service de clustering Microsoft a subi une erreur fatale inattendue
à la ligne 701 du module source D:\nt\private\cluster\service\fm\group.c. Le code d’erreur était 70.
Lorsque le nœud de cluster redémarré démarre correctement, le programme Administrateur de cluster

qui s’exécute sur les autres nœuds répond comme prévu.
Cause
Ce problème se produit si vous suspendez un nœud d’un cluster de serveurs, puis que vous redémarrez le
nœud de cluster actif. Lorsque le nœud actif redémarre, le nœud suspendu tente de mettre en ligne des groupes
de ressources. Étant donné que ce nœud est suspendu, il ne peut pas établir de connexions supplémentaires et il
ne peut pas mettre en ligne le groupe de disques Quorum. Le code d’erreur 70 correspond au message d’erreur
suivant :
Le serveur distant a été suspendu ou est en cours de mise en place.

NOTE
Ces résultats se produisent également dans les clusters qui ont plus de deux nodes. Même si un nœud non suspendu
existe dans un état de fonctionnement lorsque le nœud actif est redémarré, si le nœud en pause est le premier nœud
contacté pour prendre possession du disque de quorum. Le nœud non suspendu n’a pas la possibilité d’arbitrage pour le
disque de quorum.
Résolution
Pour résoudre ce problème, recommenciez le nœud de cluster en pause avant de redémarrer le nœud de cluster
actif.
NOTE
Avant de reprendre un nœud de cluster en pause, vous devez d’abord déterminer si un nœud de cluster est suspendu.
2. À l’invite de commandes, tapez nœud de cluster, puis appuyez sur Entrée. La sortie est similaire à :
NOTE
L’exemple de sortie suivant est basé sur une configuration de cluster à deux nœuds. Si vous avez plus de deux
nodes, les autres apparaissent également dans la liste.
État de l’ID du nœud du nœud

-------------- --------- ---------------------
CLUSTER-1 1 suspendu
CLUSTER-2 Haut
NOTE
Si le seul nœud de cluster qui n’est pas suspendu est en cours de redémarrage, vous recevez le message d’erreur
suivant :
L’erreur système 1753 s’est produite. Aucun point de terminaison n’est disponible à partir du mappeur de point de
terminaison.
3. À l’invite de commandes, tapez nœud de cluster node_name /resume (où node_name est le nom du
nœud de cluster), puis appuyez sur Entrée.
Par exemple, tapez nœud de cluster cluster-1 /resume, puis appuyez sur Entrée. Les informations qui
s’affiche sont similaires à :
Reprise du nœud « cluster-1 » ...

État de l’ID du nœud du nœud
-------------- --------- ---------------------
CLUSTER-1 1 Haut
Comment résoudre les problèmes du compte de
service de cluster lorsqu’il modifie des objets
ordinateur
Cet article explique comment résoudre les problèmes du service de cluster lorsqu’il crée ou modifie un objet
ordinateur dans Active Directory pour un cluster de serveurs (serveur virtuel).
Droits d’accès Active Directory pour la création d’un objet ordinateur

Par défaut, les membres du groupe Utilisateurs du domaine se sont vu accorder le droit d’ajouter des stations de
travail à un domaine. Par défaut, ce droit d’utilisateur est fixé à un quota maximal de 10 objets ordinateur dans
Active Directory. Si vous dépassez ce quota, le message d’ID d’événement suivant est enregistré :
Si plusieurs clusters utilisent le même compte de domaine que leur compte de service de cluster, vous
pouvez recevoir ce message d’erreur avant de créer dix objets ordinateur dans un cluster donné. Une façon
de résoudre ce problème consiste à accorder au compte de service de cluster l’autorisation Créer des objets
ordinateur sur le conteneur Ordinateurs. Cette autorisation remplace l’option Ajouter des stations de travail
à un droit d’utilisateur de domaine, qui a un quota par défaut de dix.
Pour vérifier que le compte de service de cluster dispose du droit Ajouter des stations de travail à un droit
d’utilisateur de domaine :
1. Connectez-vous au contrôleur de domaine sur lequel le compte de service de cluster est stocké.
2. Démarrez le programme stratégie de sécurité du contrôleur de domaine à partir des outils
d’administration.
3. Cliquez pour développer les stratégies locales, puis pour développer les attributions de droits
d’utilisateur.
4. Double-cliquez sur Ajouter des stations de travail à un domaine et notez les comptes répertoriés.
5. Le groupe Utilisateurs authentifiés (groupe par défaut) doit être répertorié. S’il n’est pas répertorié, vous
devez accorder à cet utilisateur le droit d’accès au compte de service de cluster ou à un groupe qui
contient le compte de service de cluster sur les contrôleurs de domaine.
NOTE
Vous devez accorder à cet utilisateur le droit d’accès aux contrôleurs de domaine, car les objets ordinateur sont
créés sur les contrôleurs de domaine.
6. Si vous ajoutez explicitement le compte de service de cluster à cet utilisateur à droite, exécutez-le sur le
contrôleur de domaine (ou exécutez-le pour gpupdate Windows 2000) afin que le nouveau droit
d’utilisateur soit répliqué sur tous les contrôleurs de secedit domaine.
7. Vérifiez que la stratégie ne sera pas écrasée par une autre stratégie.
Le compte de service de cluster n’a pas les droits d’utilisateur
appropriés sur le nœud local
Vérifiez que le compte de service de cluster dispose des droits d’utilisateur appropriés sur chaque nœud du
cluster. Le compte de service de cluster doit se trouver dans le groupe Administrateurs local et doit avoir les
droits répertoriés ci-dessous. Ces droits sont attribués au compte de service de cluster pendant la configuration
du nœud de cluster. Il est possible qu’une stratégie de niveau supérieur sur-écrit la stratégie locale ou qu’une
mise à niveau à partir d’un système d’exploitation précédent n’ajoute pas tous les droits requis. Pour vérifier que
ces droits sont accordés sur le nœud local, suivez les procédures ci-après :
1. Démarrez la console de sécurité Paramètres locale à partir du groupe Outils d’administration.
2. Accédez aux attributions de droits d’utilisateur sous Stratégies locales.
3. Vérifiez que les droits suivants ont été explicitement attribués au compte de service de cluster :
Se connectez en tant que service
Agir en tant que partie du système d’exploitation
Back up files and directories
Ajuster les quotas de mémoire pour un processus
Augmenter la priorité de planification
Restaurer des fichiers et des répertoires
NOTE
Si le compte de service de cluster a été supprimé du groupe Administrateurs local, re-créez manuellement le
compte de service de cluster et donnez au service de cluster les droits requis.
Si l’un des droits est manquant, accordez au compte de service de cluster des droits explicites pour celui-
ci, puis arrêtez et redémarrez le service de cluster. Les droits ajoutés ne prennent effet qu’après le
redémarrage du service de cluster. Si le compte de service de cluster ne peut toujours pas créer d’objet
ordinateur, vérifiez qu’une stratégie de groupe n’écrit pas trop la stratégie locale. Pour ce faire, vous
pouvez taper gpresult à l’invite de commandes si vous êtes dans un domaine Windows 2000 ou un jeu
de stratégie résultant (RSOP) à partir d’un logiciel en snap-in MMC si vous êtes sur un domaine Windows
Server 2003.
Si vous êtes dans un domaine Windows Server 2003, recherchez dans l’aide et le support sur « RSOP »
des instructions sur l’utilisation du jeu de stratégie résultant.
Si le compte de service de cluster n’a pas le droit « Agir dans le cadre du système d’exploitation », la
ressource Nom du réseau échoue et Cluster.log enregistre le message suivant :
Utilisez les étapes ci-dessus pour vérifier que le compte de service de cluster dispose de tous les
droits requis. Si les stratégies de sécurité locales sont sur-écrites par une stratégie de groupe de
domaine ou d’unité d’organisation, plusieurs options s’offrent à vous. Vous pouvez placer les nodes
de cluster dans leur propre ouvée qui possède la désélection « Autoriser les autorisations héritées du
parent à se propager à cet objet ».
Droits d’accès requis lors de l’utilisation d’un objet ordinateur pré-

créé
Si la création d’un objet ordinateur est bloquée pour les membres du groupe Utilisateurs authentifiés ou du
compte de service de cluster, si vous êtes l’administrateur de domaine, vous devez pré-créer l’objet ordinateur
serveur virtuel. Vous devez accorder certains droits d’accès au compte de service de cluster sur l’objet
ordinateur pré-créé. Le service de cluster tente de mettre à jour l’objet ordinateur qui correspond au nom
NetBIOS du serveur virtuel.
Pour vérifier que le compte de service de cluster dispose des autorisations adéquates sur l’objet ordinateur :
1. Démarrez le logiciel en ligne Utilisateurs et ordinateurs Active Directory à partir des outils
d’administration.
2. Dans le menu Affichage, sélectionnez Fonctionnalités avancées.
3. Recherchez l’objet ordinateur que vous souhaitez que le compte de service de cluster utilise.
4. Cliquez avec le bouton droit sur l’objet ordinateur, puis sélectionnez Propriétés.
5. Sélectionnez l’onglet Sécurité, puis sélectionnez Ajouter.
6. Ajoutez le compte de service de cluster ou un groupe dont le compte de service de cluster est membre.
7. Accordez à l’utilisateur ou au groupe les autorisations suivantes :
Réinitialiser le mot de passe
Validation de l’écriture dans le nom d’hôte DNS
Validated Write to Service Principal Name
8. Sélectionnez OK . S’il existe plusieurs contrôleurs de domaine, vous devrez peut-être attendre que la
modification des autorisations soit répliquée sur les autres contrôleurs de domaine (par défaut, un cycle
de réplication se produit toutes les 15 minutes).
La ressource nom réseau n’est pas disponible en ligne lorsque

kerberos est désactivé
Une ressource Nom réseau n’est pas disponible en ligne si un objet ordinateur existe, mais vous ne sélectionnez
pas l’option Activer l’authentification Kerberos. Pour résoudre le problème, utilisez l’une des procédures
suivantes :
Supprimez l’objet ordinateur correspondant dans Active Directory.
Sélectionnez Activer l’authentification Kerberos sur la ressource Nom du réseau.
Comment résoudre les problèmes de démarrage du
service de cluster dans Windows Server 2003
Cet article décrit les étapes de dépannage de base que vous pouvez utiliser pour diagnostiquer les problèmes de
démarrage du service de cluster avec Windows Server 2003.
Résumé
Cet article décrit les étapes de dépannage de base que vous pouvez utiliser pour diagnostiquer les problèmes de
démarrage du service de cluster avec Windows Server 2003. Bien qu’il ne s’agit pas d’une liste complète de tous
les problèmes qui peuvent entraîner le non-démarrage du service de cluster, il ne permet pas de résoudre une
majorité des problèmes de démarrage de Windows Server 2003. Le contenu de cet article ne s’applique PAS à
Windows Server 2008 ou ultérieur.
Au démarrage initial du service de cluster, il tente de joindre un cluster existant. Pour ce faire, le service de
cluster doit être en mesure de contacter un nœud de cluster existant. Si la procédure de jointrement ne réussit
pas, le cluster continue jusqu’à l’étape du formulaire ; La principale exigence de cette étape est la possibilité de
monter le périphérique de quorum.
Voici les étapes du processus de démarrage dans l’ordre :
Authentifier le compte de service.
Chargez la copie locale de la base de données de cluster.
Utilisez les informations de la base de données locale pour essayer de contacter d’autres nodes pour
commencer la procédure de joint. Si un nœud est contacté et que l’authentification réussit, la procédure de
jointeur réussit.
Si aucun autre nœud n’est disponible, le service de cluster utilise les informations de la base de données
locale pour monter le périphérique de quorum et met à jour la copie locale de la base de données en
chargeant le dernier fichier de point de contrôle et en relisant le journal de quorum.
Résolution des problèmes de démarrage du service de cluster
IMPORTANT
1. Vérifiez que le nœud de cluster qui a des problèmes est en mesure d’authentifier correctement le compte
de service. Vous pouvez le déterminer en vous connectant à l’ordinateur avec le compte de service de
cluster ou en vérifiant le journal des événements système pour les messages d’événement de problème
d’ouverture de session du service de cluster.
2. Vérifiez que le dossier %SystemRoot%\Cluster contient un fichier Clusdb valide et que le service de
cluster a tenté de démarrer. Démarrez l’Éditeur du Registre (Regedt32.3xe) et vérifiez que la clé de
Registre suivante est valide et chargée : HKEY_LOCAL_MACHINE\Cluster
La ruche de cluster doit avoir une structure très similaire à celle de l’administrateur de cluster. Notez les
clés de réseau et de quorum. Si la base de données n’est pas valide, vous pouvez copier et utiliser la base
de données de cluster à partir d’un nœud en direct.
3. Si le nœud n’est pas le premier nœud du cluster, vérifiez la connectivité à d’autres nœuds de cluster sur
tous les réseaux disponibles. Utilisez lPing.exe pour vérifier la connectivité TCP/IP et utilisez
l’administrateur de cluster pour vérifier que le service de cluster peut être contacté. Utilisez les adresses
TCP/IP des cartes réseau dans les autres Connecter boîte de dialogue De l’administrateur de cluster.
4. S’il ne peut pas contacter d’autre nœud, le service continue avec la phase de formulaire. Il tente de
localiser des informations sur le quorum dans la base de données de clusters locale, puis tente de monter
le disque. Si le disque de quorum ne peut pas être monté, le service ne démarre pas. Si un autre nœud a
démarré correctement et qu’il est propriétaire du quorum, le service ne démarre pas. Cela est
généralement dû à des problèmes de connectivité ou d’authentification. Si ce n’est pas le cas, vous pouvez
vérifier l’état du périphérique de quorum en démarrage du service avec le commutateur -fixquorum, et
essayer de mettre le disque de quorum en ligne ou de modifier l’emplacement du quorum pour le
service. En outre, vérifiez le journal des événements système pour les erreurs de disque. Si le disque de
quorum est correctement mis en ligne, il est probable que le quorum soit endommagé.
5. Vérifiez les attributs du fichier Cluster.log pour vous assurer qu’il n’est pas en lecture seule et assurez-
vous qu’aucune stratégie n’est en vigueur qui empêche la modification du fichier Cluster.log. Si l’une de
ces conditions existe, le service de cluster ne peut pas démarrer.
Si ces étapes ne résolvent pas le problème, vous devez prendre des mesures de dépannage supplémentaires. Le
fichier journal de cluster peut être utile pour la résolution des problèmes supplémentaires. Par défaut, la
journalisation de cluster est activée Windows ordinateurs basés sur 2000 qui exécutent le service de cluster.
Guide de résolution des problèmes liés à l’ID
d’événement 5120 Cluster Shared Volume
Cette aide est conçue pour aider à résoudre les problèmes liés aux codes d’état relatifs au volume partagé du
cluster Event ID 5120.

L’ID d’événement 5120 indique qu’il y a eu une interruption de la communication entre un nœud de cluster et
un volume dans les volumes partagés de cluster (CSV). Cette interruption peut être suffisamment courte pour
ne pas être visible ou suffisamment longue pour interférer avec les services et les applications utilisant le
volume. Si l’interruption persiste, consultez d’autres événements dans les journaux des événements système ou
d’application pour plus d’informations sur la communication entre le nœud et le volume.
1. Vérifiez que le volume partagé de cluster peut être en ligne. Pour confirmer qu’un volume partagé de
cluster peut être en ligne :
a. Pour ouvrir le composant logiciel enfichable de cluster de basculement, sélectionnez Démarrer > le
Gestionnaire de cluster de basculement des outils > d’administration. Si la boîte de dialogue
Contrôle de compte d’utilisateur s’affiche, vérifiez que l’action qu’il affiche correspond à ce que vous
voulez, puis sélectionnez Oui .
b. Dans le composant logiciel enfichable Gestionnaire du cluster de basculement , vérifiez si le
cluster que vous souhaitez gérer s’affiche. S’il n’est pas affiché, dans l’arborescence de la console,
cliquez avec le bouton droit sur Gestionnaire du cluster de basculement , sélectionnez Gérer un
cluster , puis sélectionnez ou spécifiez le cluster souhaité.
c. Si l’arborescence de la console est réduite, développez l’arborescence sous le cluster que vous
souhaitez gérer, puis sélectionnez Volumes par tagés de cluster .
d. Dans le volet central, développez la liste du volume que vous vérifiez et affichez l’état du volume.
e. Si un volume est hors connexion, mettez-le en ligne en cliquant avec le bouton droit sur le volume,
puis en sélectionnant Mettre cette ressource en ligne .
2. Utilisez une applet de commande Windows PowerShell pour vérifier l’état d’une ressource dans un
cluster de basculement :
a. Sur un nœud du cluster, sélectionnez Démarrer , pointez sur Outils d’administration, puis
sélectionnez Windows PowerShell Modules . Si la boîte de dialogue Contrôle de compte
d’utilisateur s’affiche, vérifiez que l’action qu’il affiche correspond à ce que vous voulez, puis
sélectionnez Oui . Exécutez la l’applet commande suivant :
Get-ClusterSharedVolume
b. Si vous exécutez l’applet de commande précédente sans spécifier de nom de ressource, l’état
s’affiche pour tous les volumes partagés de cluster dans le cluster.
3. Si vous voyez quelques événements aléatoires ID 5120 avec une erreur de
STATUS_CLUSTER_CSV_AUTO_PAUSE_ERROR ou de code d’erreur c0130021, ils peuvent être ignorés en
toute sécurité. Nous reconnaissons que ce n’est pas optimal, car ils créent des alarmes faux positifs et
déclenchent des alertes dans les logiciels de gestion.
4. Si vous voyez que l’ID d’événement 5120 est enregistré avec des codes d’erreur autres que
STATUS_CLUSTER_CSV_AUTO_PAUSE_ERROR, il s’agit d’un signe de problème. Veillez à consulter le code
d’erreur dans la description de chaque ID d’événement 5120 enregistré. Veillez à ne pas ignorer
l’événement en raison d’un événement unique avec STATUS_CLUSTER_CSV_AUTO_PAUSE_ERROR. Si
d’autres erreurs sont consignées, des correctifs doivent être appliqués.

Si vous voyez l’ID d’événement 5120, le champ Description de l’événement inclut un message d’état qui
indique la cause de l’événement. La liste suivante se compose de 20 messages d’état :
Code d’état : STATUS_BAD_IMPERSONATION_LEVEL (0xC00000A5)
Certaines opérations, telles que le changement de nom que vous effectuez sur des fichiers ou des dossiers sur
un volume partagé de cluster, peuvent échouer avec l’erreur « STATUS_BAD_IMPERSONATION_LEVEL
(0xC00000A5) ». Ce problème se produit lorsque vous effectuez l’opération sur un nœud propriétaire CSV à
l’aide du contexte d’un processus qui ne dispose pas d’autorisations d’administrateur.
Pour contourner ce problème, effectuez l’une des opérations suivantes :
1. Effectuez l’opération à l’aide du contexte d’un processus disposant d’autorisations d’administrateur.
2. Effectuez l’opération à l’aide d’un nœud qui n’a pas la propriété CSV.
Microsoft travaille sur une résolution et fournira une mise à jour dans une prochaine version, comme décrit le
12 février 2019 : KB4487020 (build 15063.1631 du système d’exploitation).
Code d’état : STATUS_BAD_NETWORK_NAME(c000000cc)
1. Recherchez dans votre journal des événements système des événements qui indiquent des problèmes de
connectivité réseau, des problèmes de carte de bus hôte (HBA) ou des problèmes de disque.
2. Assurez-vous que les dernières versions des pilotes réseau et de stockage et du microprogramme sont
installées sur le système concerné. En outre, assurez-vous que les mises à jour et les correctifs logiciels de
Microsoft sont à jour.
Code d’état : STATUS_BAD_NETWORK_PATH (c000000be )
Vérifiez la configuration du stockage et les paramètres d’E/S multipath (MPIO). Vous pouvez activer la
vérification du chemin MPIO sur tous les nœuds de cluster à l’aide de l’applet Set-MPIOSetting de commande
PowerShell. Procédez comme suit sur chaque nœud de cluster :
1. Ouvrez une fenêtre d’invite de commandes PowerShell.
2. Exécutez les applets de commande suivantes :
Set-MPIOSetting -NewPathVerificationState Enabled

Set-MPIOSetting -NewPathVerificationPeriod <integer>
NOTE
Dans cette applet de commande, <integer> correspond à la durée pendant laquelle le serveur doit vérifier
chaque chemin d’accès (en secondes). La valeur par défaut est 30 secondes.
Code d’état : STATUS_CLUSTER_CSV_AUTO_PAUSE_ERROR (c0130021)

Assurez-vous que les dernières versions des pilotes réseau et de stockage et du microprogramme sont
En particulier, assurez-vous que la mise à jour suivante est installée sur tous les serveurs Windows Server 2012
R2 et antérieurs.
Mise à jour disponible qui améliore la résilience du fournisseur de services cloud dans Windows : décembre
2013 (KB2878635)
NOTE
Dans Windows Server 2016 et versions ultérieures, le nom de ce code d’état est STATUS_CLUSTER_CSV_NO_SNAPSHOTS.
Code d’état : STATUS_CONNECTION_DISCONNECTED(c000020c)

La communication entre un nœud de cluster et un CSV a été interrompue. Cette interruption peut être
suffisamment courte pour ne pas être visible ou suffisamment longue pour interférer avec les services et les
applications qui utilisent le volume. Si l’interruption persiste, consultez d’autres événements dans les journaux
des événements système ou d’application pour plus d’informations sur la communication entre le nœud et le
volume.
En outre, vérifiez que le CSV peut être en ligne en procédant comme suit :
NOTE
Pour effectuer les procédures suivantes, le compte que vous utilisez doit être un compte de domaine et doit appartenir au
groupe Administrateurs local sur chaque serveur cluster, ou il doit avoir l’autorité équivalente.
1. Sélectionnez Démarrer > le Gestionnaire de cluster de basculement des outils d’administration > .
2. Dans le composant logiciel enfichable Gestionnaire du cluster de basculement , vérifiez si le cluster que
vous souhaitez gérer s’affiche. S’il n’est pas affiché, dans l’arborescence de la console, cliquez avec le bouton
droit sur Gestionnaire du cluster de basculement , sélectionnez Gérer un cluster , puis sélectionnez ou
spécifiez le cluster souhaité.
3. Dans le volet central, développez la liste du volume que vous vérifiez. Affichez l’état du volume.
4. Si un volume est hors connexion, mettez-le en ligne en cliquant avec le bouton droit sur le volume, puis en
sélectionnant Mettre cette ressource en ligne .
Pour utiliser une applet de commande PowerShell pour vérifier l’état d’une ressource dans un cluster de
basculement, ouvrez une fenêtre d’invite de commandes PowerShell sur un nœud du cluster, puis exécutez
Get-ClusterSharedVolume .
NOTE
Si vous exécutez l’applet de commande précédente sans spécifier de nom de ressource, l’état s’affiche pour tous les CSV
du cluster.
Pour plus d’informations, consultez l’ID d’événement 5120 — Fonctionnalités de volume partagé de cluster.
Code d’état : STATUS_CONNECTION_RESET (c000020d)
3. Vérifiez les exclusions configurées pour votre solution antivirus.
Code d’état : STATUS_DEVICE_BUSY (80000011)
1. Vérifiez l’état des ressources de stockage. Ce message peut indiquer que la réservation persistante du
volume a été perdue.
Code d’état : STATUS_DEVICE_NOT_CONNECTED(c000009d)
Ce code d’état indique que la connectivité entre les nœuds de cluster et le stockage a été perdue.
Code d’état : STATUS_FILE_CLOSED(c0000128)
1. Vérifiez la connectivité réseau. Recherchez dans les journaux des événements d’autres événements liés à la
connectivité, tels que l’ID d’événement 1135. En outre, vérifiez l’état des charges de travail qui génèrent un
trafic réseau important (comme les sauvegardes).
Code d’état : STATUS_FILE_NOT_AVAILABLE(c0000467)
1. Vérifiez l’état d’intégrité de Smart Array. Assurez-vous que les pilotes et microprogrammes associés sont à
jour.
Code d’état : STATUS_INSUFFICIENT_RESOURCES (c000009a)
Code d’état : STATUS_IO_TIMEOUT (c00000b5)
Ce code d’état indique qu’une opération d’E/S du système de fichiers redirigé a pris plus de temps que le temps
autorisé. Le délai d’expiration est de deux minutes pour les opérations synchrones et de quatre minutes pour les
opérations asynchrones.
La cause du délai d’expiration varie. Cela peut indiquer un problème de logiciel, de configuration ou de matériel.
Microsoft sont à jour. En particulier, assurez-vous que le 18 octobre 2018 —KB4462928 (build du système
d’exploitation 14393.2580) est installé. Cette mise à jour résout un problème qui se produit lors du
redémarrage d’un nœud après le vidage du nœud. L’ID d’événement 5120 s’affiche dans le journal avec un
message « STATUS_IO_TIMEOUT c00000b5 ». Cela peut ralentir ou arrêter l’entrée et la sortie (E/S) vers les
machines virtuelles, et parfois les nœuds peuvent abandonner l’appartenance au cluster.
Code d’état : STATUS_MEDIA_WRITE_PROTECTED(c00000a2)
Ce code d’état indique qu’il existe un problème de connectivité. Assurez-vous que le protocole SMB (Server
Message Block) est activé.
Code d’état : STATUS_NETWORK_UNREACHABLE(c000023c)
Ce code d’état indique qu’il existe une erreur réseau entre le nœud et le CSV ou que le Gestionnaire de contrôle
de disque (DCM) a mappé un chemin incorrect au volume.
Code d’état : STATUS_NO_MEDIA_IN_DEVICE(c0000013)
Ce code d’état indique un problème dans le système de stockage. Vérifiez l’état d’intégrité du système de
stockage.
Code d’état : STATUS_NO_SUCH_DEVICE(c000000e )
Ce code indique que la connectivité entre un nœud et le CSV a été perdue.
1. Vérifiez la connectivité réseau et l’exclusion de cluster dans le pare-feu.
Code d’état : STATUS_UNEXPECTED_NETWORK_ERROR (c00000c4)
Code d’état : STATUS_UNSUCCESSFUL (c0000001)
1. Vérifiez la connectivité entre les nœuds et le CSV.
Code d’état : STATUS_USER_SESSION_DELETED(c0000203)
En particulier, assurez-vous que le 18 octobre 2018 —KB4462928 (build du système d’exploitation 14393.2580)
est installé. Cette mise à jour résout un problème qui génère ce code d’état dans le cas de plusieurs clusters
Hyper-V Windows Server 2016.
Code d’état : STATUS_VOLUME_DISMOUNTED(c000026e )
1. Recherchez dans votre journal des événements système les événements qui indiquent des problèmes de
stockage, des problèmes de connectivité réseau, des problèmes de carte de bus hôte (HBA) ou des
problèmes de disque.
Avant de contacter Support Microsoft, vous pouvez collecter des informations sur votre problème.
Reportez-vous aux prérequis pour que l’ensemble d’outils s’exécute correctement.
Collectez les informations clés avant de contacter Support Microsoft
Utilisez la fonctionnalité de vidage en direct Windows pour enregistrer un instantané de la mémoire du noyau
sur l’ordinateur affecté. Pour cela, procédez comme suit :
1. Recherchez les fichiers de vidage en direct précédents dans le dossier de vidage en direct
(C:\Windows\LiveKernelReports\).
2. Assurez-vous que la fonctionnalité de vidage en direct a été activée. Pour plus d’informations sur
l’activation de la fonctionnalité, consultez Résolution des problèmes liés aux blocages à l’aide du vidage
en direct.
3. Téléchargez TSSv2 et décompressez-le dans le dossier C:\tss_tool .
4. Ouvrez une version avec élévation de privilèges de PowerShell et remplacez le répertoire par le dossier
C:\tss_tool .
5. Exécutez l’outil SDP pour collecter les journaux à partir des nœuds source et de destination.
6. Décompressez le fichier et exécutez l’applet de commande suivante sur les deux nœuds :
TSSv2.ps1 -SDP Cluster -SkipSDPList skipHang,skipBPA,skipSDDC
7. Collectez tous les journaux d’activité. Compressez et attachez les fichiers de vidage en direct à votre
demande de support.
Correctifs et mises à jour recommandés pour les
clusters de basculement Windows Server 2012
Cet article décrit les correctifs logiciels qui sont actuellement disponibles pour les clusters de Windows Server
2012 et qui sont vivement recommandés pour être installés sur chaque serveur d’un cluster de point de non-
remise.
Résumé
La gestion du cluster de failover permet à plusieurs serveurs de fournir une haute disponibilité des rôles
serveur. La gestion du cluster de failover est souvent utilisée pour les services de fichiers, les machines
virtuelles, les applications de base de données et les applications de messagerie.
IMPORTANT
Le processus d’installation des Service Packs et des correctifs logiciels sur Windows Server 2012 diffère du processus des
versions antérieures. Dans Windows Server 2012, vous pouvez utiliser la fonctionnalité Cluster-Aware à jour (CAU). CAU
automatise le processus de mise à jour logicielle sur les serveurs en cluster tout en conservant la disponibilité. Pour plus
d’informations, voir Cluster-Aware Updating Overview.
Introduction
Les articles suivants de la Base de connaissances Microsoft décrivent les correctifs actuellement disponibles qui
sont vivement recommandés pour être installés sur tous les clusters deover. La plupart des mises à jour
s’appliquent aux ordinateurs qui exécutent Windows Server 2012. Certaines mises à jour, telles que les 976424
de la Ko, peuvent être nécessaires sur les ordinateurs exécutant Windows Server 2008 R2 ou Windows Server
2008 si ces systèmes d’exploitation sont présents dans l’environnement.
Ces mises à jour sont considérées comme importantes à installer pour garantir le niveau de fiabilité le plus
élevé.
NOTE
Vous pouvez remplacer un nouveau nombre de rapports mensuels à la place de la base de 4282815. Le reste des mises à
jour de cette liste est toujours nécessaire, car certains composants de ces mises à jour publiées avant septembre 2016 ne
sont pas inclus dans le nouveau déploiement mensuel.
DAT E À L A Q UEL L E L E P O URQ UO I N O US

C O RREC T IF A ÉT É A RT IC L E DE L A B A SE REC O M M A N DO N S
A JO UT É DE C O N N A ISSA N C ES T IT L E C O M P O SA N T C E C O RREC T IF
30 septembre 2016 3185280 Rollup de mise à jour Clussvc.exe Résout un problème

de septembre 2016 lorsqu’un nœud de
pour Windows Server cluster envoie une
2012 demande ICMP
(Internet Control
Message Protocol) à
une passerelle, le
protocole TCPIP
renvoie une erreur de
délai (code d’erreur
11010,
IP_REQ_TIMED_OUT),
même si ICMP ne
reçoit pas de délai.
Windows Update.
Inclut les correctifs
dans 3090343 et
3076953.
22 juillet 2015 3062586 0x000000D1'erreur Netft Empêche l’arrêt d

d’arrêt sur Windows 0xD1 lors du
Server 2012 cluster traitement d’une liste
basé sur un cluster de mémoires
tampons réseau
(NBL). Toutes les
erreurs 0x000000D1
arrêter sont dues à
ce problème.
Disponible pour
téléchargement
individuel.
6 juillet 2015 3018489 Erreur « Aucun Storport Pour recevoir les

adaptateur de bus fonctionnalités de
hôte n’est présent » journalisation mises à
lors de l’interrogation jour des storport.sys
de problèmes de couvertes dans la
câble SAS dans 2819476 de la Base
Windows Server de données, ainsi que
2012 R2 ou Windows les correctifs dans les
Server 2012 3018489 de la Base
de données, les
2908783 de la Base
de 2908783 et les
2867201 de la Base
de 2867201.
Disponible pour
téléchargement
individuel.
22 avril 2015 3048474 Le fournisseur WMI WMI Récupère un

ne peut pas démarrer fournisseur WMI
lorsque vous gérez lorsqu’il a atteint le
Hyper-V ou le cluster seuil de mémoire
de Windows 8 ou WMI afin que vous
Windows Server pouvez continuer à
2012 gérer Hyper-V ou
cluster de percutant
dans Windows 8 ou
Windows Server
2012. Disponible
pour téléchargement
individuel.
13.01.15 3004098 Une fuite de Csvfs.sys Empêche toute fuite

mémoire se produit de mémoire lorsque
lorsque vous créez vous créez ou
ou supprimez des supprimez des
captures captures
instantanées CSV à instantanées CSV à
l’aide d’un l’aide d’un
fournisseur de fournisseur de
matériel VSS dans service VSS (Volume
Windows Shadow Copy
Service) matériel.
Disponible pour
téléchargement
individuel.
mardi 8 avril 2014 2916993 Arrêt de la 0x9E dans Ntoskrnl.exe Empêche un conflit
Windows Server de verrous et l’arrêt
2012 ou Windows 8 0x9e lorsqu’un fichier
de grande taille est
mappé dans le cache
système, par exemple
une opération de
sauvegarde copie des
fichiers à partir de
captures
instantanées.
Disponible pour
téléchargement
individuel.
lundi 17 mars 2014 2929869 Le fichier instantané Csvflt.sys Empêche l’altération

CSV est endommagé Csvfs.sys du fichier instantané
lorsque vous créez Volsnap.sys CSV lorsqu’un fichier
des fichiers sur le est supprimé et
volume en direct recréé sur le volume
en direct. Disponible
individuel.
15 janvier 2014 2913695 OffloadWrite fait NTFS.sys Amélioration des

prepareForCriticalIo performances en cas
pour l’intégralité du de déchargement
disque dur vhd dans d’écriture pour un
un Windows Server disque dur virtuel
2012 ou Windows (VHD) dans l’hôte.
Server 2012 hôte Disponible pour
Hyper-V R2 téléchargement
individuel.
2 janvier 2014 2878635 Mise à jour Multiple Ce correctif empêche

disponible qui un changement de
améliore la résilience CSV en corrigeant un
du fournisseur de problème sous-jacent
services cloud dans NTFS, les
Windows Server captures
2012 : décembre instantanées
2013 logicielles et en
augmentant la
résilience globale du
service de cluster et
du CSV pendant les
états de pause
attendus. Disponible
individuel.
14 novembre 2013 2894464 Message d’erreur DLL de ressource de Ce correctif permet

lorsque vous essayez cluster de failover de résoudre une
de planifier une tâche erreur lorsque vous
de copie de Windows essayez de planifier
Server 2012 une tâche de copie
de l’ombre sur un
disque partagé.
Disponible pour
téléchargement
individuel.
14 juin 2013 2838043 Can’t access a DLL de ressource de Ce correctif logiciel

resource that is cluster de failover empêche toute
hosted on a erreur lorsque des
Windows Server ressources hébergées
2012-based failover sur un cluster de
cluster Windows 8 ou de
Windows Server
2012 sont accessibles
à partir d’un
ordinateur client basé
sur Windows XP ou
Windows Server
2003.
Ce correctif permet
également de
résoudre un ID
avec une erreur : le
handle n’est pas
valide lorsque la
ressource de nom de
réseau de cluster
n’est pas mise en
ligne et ne s’inscrit
pas dans DNS.
Disponible pour
téléchargement
individuel et inclus
dans 2889784
(Windows RT,
Windows 8 et
Windows Server
2012 de mise à jour :
novembre 2013).
23 janvier 2013 2803748 Le logiciel en un clin Logiciel en snap-in Résout un incident

d’œil Gestion du Gestion du cluster de dans le 2750149
cluster de Windows failover gestion du cluster de
Server 2012 se Windows Server
crashe après 2012 de mise à jour.
l’installation de la Disponible à partir
mise à jour 2750149 Windows Update ou
sur un cluster de du Centre de
Windows Server téléchargement
2012 de mise à jour Microsoft.
13 novembre 2012 2770917 Windows 8 et Multiple Améliore les

Windows Server performances et la
2012 cumulative de fiabilité des serveurs
novembre 2012 en cluster dans les
scénarios de serveur
de fichiers Scale-Out
Hyper-V. Améliore la
fiabilité du service
SMB et du client
dans certaines
conditions de
contrainte. Installez la
mise à 2770917 à
l’aide Windows mise
à jour cumulative afin
de recevoir la mise à
jour cumulative
comme décrit dans la
base de 2770917.
13 novembre 2012 976424 Code d’erreur lorsque KDCSVC Installez sur chaque
le protocole kpasswd contrôleur de
échoue après avoir domaine exécutant
effectué une Windows Server
restauration faisant 2008 Service Pack 2
autorité : « ou Windows Server
KDC_ERROR_S_PRIN 2008 R2 afin
CIPAL_UNKNOWN » d’ajouter un cluster
de Windows Server
2012 de serveurs.
Dans le cas contraire,
la création d’un
cluster peut échouer
avec un message
d’erreur :
CreateClusterNameC
OIfNotExists (6783
<ClusterName$> ) :
impossible de définir
le mot de passe
lorsqu’il tente de
définir le mot de
passe de l’objet
ordinateur de cluster.
Ce correctif est inclus
dans Windows Server
2008 R2 Service Pack
1.
Pour plus d’informations sur les correctifs et les mises à jour recommandés pour les serveurs Hyper-V Windows
Server 2012 et les clusters de Windows Server 2012 R2, consultez les ressources suivantes :
Hyper-V : Liste des mises à jour pour Windows Server 2012
Correctifs et mises à jour recommandés pour les clusters de basculement Windows Server 2012 R2
Message d’erreur « Impossible d’obtenir l’objet
ordinateur à l’aide du GUID » en cas d’échec d’une
demande de nom de réseau dans un cluster de
Windows Server
Cet article fournit une solution pour résoudre un problème dans lequel un point d’accès au client (CAP) dans un
cluster de failover n’est pas disponible en ligne comme prévu.
Symptômes
Une limite d’accès au Windows cluster de serveurs de serveurs n’est pas mise en ligne comme prévu. Dans ce
cas, l’événement Error suivant est consigné :

Catégorie de tâche : ressource nom réseau
Niveau : Erreur
Description :
La ressource de nom de réseau de cluster <Resource Name> ' ' ne peut pas être mise en ligne. L’objet
ordinateur associé à la ressource n’a pas pu être mis à jour dans le domaine <domain FQDN> ' ' pour la
raison suivante :
Impossible d’obtenir Computer Object à l’aide du GUID.
Le texte du code d’erreur associé est le suivant : Le domaine spécifié n’existe pas ou n’a pas pu être
contacté.
L’identité de cluster « $ » peut ne pas avoir les <Cluster CNO or Node> autorisations requises pour mettre à
jour l’objet. Travaillez avec votre administrateur de domaine pour vous assurer que l’identité du cluster peut
mettre à jour les objets ordinateur dans le domaine.
En outre, lorsque vous affichez le journal du cluster, le message d’erreur suivant s’affiche :
La recherche du compte d’ordinateur existant a échoué. status 8007054B
NOTE
Code d'0x8007054b = « ERROR_NO_SUCH_DOMAIN // Le domaine spécifié n’existe pas ou n’a pas pu être contacté. »
Cause
Au cours d’une opération de cluster, des tâches de maintenance peuvent être requises sur des objets ordinateur
dans Active Directory. Par exemple, il se peut que des mots de passe doivent être créés, supprimés, activés,
désactivés et pivotés, et que les SSN doivent être mis à jour. Lorsque des serveurs sont situés dans des réseaux
de périmètre (également appelés DMZ, zones démilitarisées et sous-réseaux filtrés) qui n’ont accès qu’aux
contrôleurs de domaine Read-Only( RODC), vous pouvez contourner certaines de ces tâches en créant et
supprimant manuellement des objets ordinateur. D’autres opérations sont transmis par des contrôleurs de
domaine à un contrôleur de domaine accessible en écriture ailleurs dans le domaine. Toutefois, le cluster
effectue certaines opérations de modification dans lesquelles un contrôleur de domaine accessible en écriture
est explicitement demandé.
Résolution
Pour résoudre ce problème, fournissez l’accès du cluster deover à un contrôleur de domaine accessible en
écriture.
Pour en savoir plus sur les conditions requises par Active Directory pour le clustering deover, visitez le site Web
Microsoft suivant :
Guide pas à pas du cluster de failover : configuration des comptes dans Active Directory
Échec du test de validation de cluster sur la
configuration Active Directory dans un scénario de
cluster multisesse
Cet article décrit l’échec possible de la validation de la configuration d’Active Directory dans un scénario de
cluster multisesse.
Symptômes
Lorsque vous exécutez un test de validation de cluster pour votre cluster de failover multisesse, le test peut
échouer lors de la validation de la configuration Active Directory avec l’un des messages d’erreur suivants :
La connectivité à un contrôleur de domaine accessible en writable à partir d’un nœud n’a pas pu être
déterminée en raison de cette erreur : L’ordinateur Computer2 n’a pas pu obtenir le nom du contrôleur de
Computer2.contoso.com domaine.
Le nom de site du nœud n’a pas pu être déterminé en raison de cette erreur : L’ordinateur n’a pas pu obtenir
le nom Computer2.contoso.com du contrôleur de Computer2.contoso.com domaine.
Quelles que soient les erreurs, les nodes de cluster peuvent communiquer avec succès avec un contrôleur de
domaine et former un cluster deover.
Lorsque vous démarrez un test de validation de cluster sur un nœud, le nœud sélectionne un contrôleur de
domaine à utiliser pour le test. Pendant la validation de la configuration Active Directory, tous les ordinateurs
sélectionnés dans le cadre de la validation sont pointés vers ce contrôleur de domaine. Dans un scénario de
cluster multisesse, les communications réseau peuvent être conçues de manière à ce que les ordinateurs soient
uniquement autorisés à communiquer avec les contrôleurs de domaine qui se trouve sur leur site local. Par
conséquent, ces ordinateurs ne sont pas en communication avec les contrôleurs de domaine distants. Dans ce
scénario, les ordinateurs des autres sites ne peuvent pas communiquer avec le contrôleur de domaine
sélectionné, ce qui entraîne l’échec du test de validation de cluster.
Si les ordinateurs peuvent communiquer avec un contrôleur de domaine dans le domaine et que les contrôleurs
de domaine sont correctement réplicas, la fonctionnalité de votre cluster de failover n’est pas impactée.
Dans un scénario de cluster multisesse, vous pouvez ignorer en toute sécurité l’échec de la validation. Pendant
ce temps, votre cluster deover est toujours pris en charge par le support technique Microsoft.
Erreur : « Un élément avec la même clé a déjà été
ajouté »
Cet article permet de corriger l’erreur « Un élément avec la même clé a déjà été ajouté ».
Symptômes
Lorsque vous exécutez l’Assistant Validation d’une configuration Windows Cluster de failover Server 2008, vous
pouvez recevoir l’erreur suivante :
« Une erreur s’est produite lors de l’exécution du test. Une erreur s’est produite lors de la
vérification de la configuration du pare-feu. Un élément avec la même clé a déjà été ajouté. »
Cause
Cette erreur est signalée si des cartes réseau ont le même GUID (Globally Unique Identifier) sur tous les nodes
du cluster. Cela peut être déterminé en exécutant la requête WMI suivante sur chaque nœud du cluster et en
comparant les résultats :
Par exemple, à partir de PowerShell, exécutez : - Get-WMIObject Win32_NetworkAdapter | fl Name, Guid
Un exemple de sortie pour une carte ressemblerait à ceci :
Nom : Intel(R) PRO/1000 MT Desktop Adapter GUID: {7488FB48-851A-40B6-AB47-
1EA7408C762F}
NOTE
Ce scénario se produit généralement si une image de système d’exploitation est utilisée pour déployer des nodes de
cluster et que cette image n’a pas été correctement préparée pour le déploiement en exécutant sysprep.
Résolution
Pour résoudre ce problème, le GUID de l’interface réseau sur chacun des nodes doit être unique. Un nœud peut
être laissé inchangé. Toutefois, le processus suivant doit être effectué sur les autres.
1. Téléchargez, puis installez la dernière version du pilote de carte réseau sur l’ordinateur.
2. Cliquez sur Démarrer , puis sur Exécuter , tapez regedit, puis cliquez sur OK .
3. Recherchez et supprimez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\Config
4. Si votre serveur est un contrôleur de domaine, allez à l’étape 5. Si votre serveur n’est pas un contrôleur
de domaine, supprimez les sous-clés de Registre suivantes :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\Tcpip\Parameters\Adapters\
{GUID}
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\Tcpip\Parameters\Interfaces\
{GUID}
5. Cliquez sur Démarrer, cliquez sur Exécuter, tapez sysdm.cpl, puis cliquez sur OK.
6. Dans la boîte de dialogue Propriétés système, cliquez sur l’onglet Matériel, puis sur Gestionnaire de
périphériques.
7. Dans le Gestionnaire de périphériques, développez cartes réseau, cliquez avec le bouton droit sur la
carte réseau que vous souhaitez, puis cliquez sur Désinstaller.
Pour vérifier que le GUID de l’interface réseau a été mis à jour, utilisez l’une des méthodes suivantes.
Méthode 1 : Effectuez les méthodes suivantes :
Get-WMIObject Win32_NetworkAdapter | fl Name, Guid
Méthode 2 : exécutez l’Assistant Valider une configuration du cluster de failover et assurez-vous que l’erreur ne
se produit pas.
La validation échoue lorsque vous exécutez un
assistant de validation de cluster pour un cluster
Windows Server 2008
Cet article fournit une solution à un problème dans lequel une erreur d’adresse en double se produit lorsque
vous validez un cluster de Windows Server 2008.
IMPORTANT
restore et modify the registry, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances
Microsoft : 322756 Comment faire pour la back up et restaurer le Registre dans Windows

Symptômes
Lorsque vous exécutez un Assistant Validation de cluster pour un cluster Windows Server 2008, la validation
échoue. En outre, vous pouvez recevoir une erreur qui ressemble au message d’erreur suivant :
Vérification de l’absence d’adresses IP en double entre deux nodes.

Adresse physique dupliquée 02-10-18-39-6D-38 sur l’adaptateur de nœud Local Area Connection 19 et
connexion de la zone locale de la carte de servername.domainname.com server2name.domainname.com nœud 19.
Adresse IP fe80::100:7f:fffe%14 dupliquée sur l’adaptateur de nœud Local Area Connection 11 et la
connexion de zone locale 11 de la carte de servername.domainname.com server2name.domainname.com nœud. »
Cause
Ce problème se produit lorsque l’une des conditions suivantes est vraie :
La technologie de transition Teredo est activée sur un nœud de cluster Windows Server 2008. Teredo permet
aux communications IPv6 de passer par des nats IPv4 et des serveurs IPv4. Toutefois, Teredo donne la même
adresse IPv6 à ses interfaces réseau. Le clustering de clustering de failover le signale comme une erreur, car il
requiert des adresses IP uniques.
Les serveurs référencés sont créés à partir de la même image et créent automatiquement l’adaptateur NetFT
de cluster sur chaque nœud avec une adresse MAC identique. Le clustering de pointage de fait état d’une
erreur, car il nécessite des adresses physiques uniques.
Résolution
Il existe deux solutions possibles, selon la combinaison des messages d’erreur que vous recevez.
Problème 1
Si le message d’erreur n’inclut pas de référence à une « adresse physique en double », Teredo est probablement
la cause du problème. Pour résoudre ce problème, désactivez Teredo à l’aide de l’une des deux méthodes
suivantes.
NOTE
Les tests de validation de cluster de failover ont été modifiés dans Windows Server 2008 SP2 et les ultérieurs et Windows
Server 2008 R2 afin que les adresses Teredo ne provoquent pas de défaillance ou d’avertissement du test.
Méthode 1 : Désactiver Teredo à l’aide d’une commande Netsh

NOTE
Si la boîte de dialogue Contrôle de compte d’utilisateur s’affiche, confirmez que l’action affichée par la boîte de
dialogue est celle que vous souhaitez, puis cliquez sur Continuer .
2. À l’invite de commandes, tapez les lignes suivantes (appuyez sur Entrée après chaque ligne) :
netsh
interface
teredo
set state disabled
3. Fermez l'invite de commandes.

Méthode 2 : désactiver Teredo en spécifiant un paramètre de Registre dans Windows Server 2008
IMPORTANT
1. Pour obtenir de meilleurs résultats, fermez tous les programmes sur l’ordinateur sur lequel vous modifiez
le paramètre de Registre.
NOTE
Si la boîte de dialogue Contrôle de compte d’utilisateur s’affiche, confirmez que l’action affichée par la boîte de
dialogue est celle que vous souhaitez, puis cliquez sur Continuer .
3. Tapez regedit à la ligne de commande.

4. Recherchez la clé de Registre suivante : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6
5. Cliquez avec le bouton droit sur Paramètres, cliquez sur Nouveau, sur DWORD, puis tapez le nom
DisabledComponents pour la nouvelle valeur. Veillez à taper le nom exactement comme indiqué, y
compris la majuscules. Ensuite, cliquez sur Entrée.
6. Double-cliquez sur DisabledComponents .
7. Dans la boîte de dialogue Modifier la valeur DWORD, cliquez sur Hexadécimal sous le champ De base,
puis tapez 8 dans le champ Données de la valeur.
8. Cliquez sur OK .
NOTE
Vous pouvez également désactiver Teredo à l’aide du Gestionnaire de périphériques. Toutefois, cela désactive
uniquement l’adaptateur Teredo afin que le système n’affiche plus la carte. Cela ne désactive pas la logique sous-
jacente pour Teredo. Cela peut entraîner des problèmes ultérieurement. Par conséquent, nous vous
recommandons de désactiver Teredo par le biais de la ligne de commande ou de l’entrée de Registre.
Problème 2
Si le message d’erreur inclut une référence à une « adresse physique en double », le problème se produit
probablement parce que les serveurs référencés sont basés sur la même image. Pour résoudre ce problème,
supprimez puis réinstallez la fonctionnalité cluster de failover. Pour cela, procédez comme suit :
1. Supprimez la fonctionnalité cluster de failover. Pour cela, procédez comme suit :
a. Ouvrez le Gestionnaire de serveur.
b. Dans le volet de navigation, cliquez sur Fonctionnalités, puis sur Supprimer des fonctionnalités.
c. Cliquez pour effacer la case à cocher Clustering deover.
d. Examinez la boîte de dialogue d’avertissement pour vous assurer que vous êtes prêt à continuer.
Cliquez sur Oui, puis sur Suivant.
e. Vérifiez que les options que vous souhaitez supprimer, cliquez sur Supprimer, puis sur Fermer .
2. Réinstallez la fonctionnalité cluster de failover. Pour cela, procédez comme suit :
a. Ouvrez le Gestionnaire de serveur.
b. Dans le volet de navigation, cliquez sur Fonctionnalités, puis sur Ajouter des fonctionnalités.
c. Cliquez pour cocher la case Clustering de failover, puis cliquez sur Suivant .
d. Vérifiez que les options de votre choix sont ajoutées, cliquez sur Installer, puis fermez .
NOTE
La commande Sysprep n’est pas prise en charge lorsqu’une image est capturée après l’ajout de la fonctionnalité clustering
de failover. Si vous installez la fonctionnalité clustering deover, puis exécutez la commande sysprep sur l’image, la carte
virtuelle de tous les nodes aura la même adresse MAC. La carte réseau virtuelle (NetFT) prend une adresse MAC basée
sur l’une des adresses des cartes d’interface réseau physiques (CCI) lors de l’installation de la fonctionnalité clustering
deover.
Statut
S’applique à » de cet article.
Pour plus d’informations sur la technologie de transition Teredo, visitez les sites Web suivants :
Protocole Internet version 6, Teredo et technologies associées dans Windows Vista
Pour plus d’informations sur l’exécuter pour un cluster de cluster de Windows Server 2008, consultez le site
Web suivant :
Guide pas à pas du cluster deover : validation du matériel pour un cluster de failover
La validation du cluster échoue au test de
réservation permanente SCSI-3 dans Windows
Server
Cet article fournit une solution à un problème dans lequel le test de réservation permanente SCSI-3 échoue
lorsque vous exécutez le rapport de validation du cluster de failover.
Symptômes
Lors de l’exécution du rapport de validation du cluster de failover sur un cluster existant configuré dans
Windows Server 2008 R2 Service Pack 1, le test de réservation permanente SCSI-3 peut échouer avec l’erreur
suivante :
Échec de l’accès au disque de cluster 0 à partir de <node name> l’état du nœud 31

Le disque de cluster 0 ne prend pas en charge les réservations permanentes. Certains périphériques de
stockage nécessitent des versions ou des paramètres de microprogramme spécifiques pour fonctionner
correctement avec les clusters deover. Veuillez contacter votre administrateur de stockage ou votre
fournisseur de stockage pour vérifier la configuration du stockage afin qu’il fonctionne correctement avec
les clusters deover.
Cause
Certains Stockage appareils ont une limite définie en termes d’inscriptions ou de réservations SCSI-3 qu’ils
peuvent gérer. Le problème survient lorsque vous avez dépassé cette limite.
Résolution
Travaillez avec le fournisseur de stockage pour voir s’il existe une mise à jour du microprogramme qui peut
augmenter cette limite. Si une mise à jour du microprogramme n’est pas disponible, il peut être nécessaire de
déplacer une partie de votre stockage vers différents tableaux.
La validation échoue lorsque vous exécutez le test
de resserrement de disque sur un cluster de
Windows Server 2012 de disque
Cet article fournit une solution à un problème dans lequel la validation échoue lorsque vous exécutez le test de
failover de disque sur un cluster de Windows Server 2012 de données.
Symptômes
Lorsque vous exécutez le rapport de validation du cluster sur un cluster de Windows Server 2012, le test valider
le test de failover disque peut échouer et vous pouvez recevoir des erreurs semblables à ce qui suit :
Node contient le PR SCSI sur le disque de test 1, mais n’a pas réussi à mettre 2012N2.burragevmlab.com le
disque en ligne. L’appareil n’est pas prêt.
Cause
Ce problème se produit car la Automount fonctionnalité est désactivée. Pour déterminer si cette option est
désactivée, suivez les étapes suivantes :
1. Ouvrez une invite de commandes d’administration, puis exécutez la commande suivante : Diskpart
2. À Diskpart l’invite, exécutez la commande suivante : Automount
Les résultats vous indiquent Automount s’il est activé ou désactivé.
Résolution
Pour résoudre ce problème, activez Automount . Pour ce faire, exécutez la commande suivante à partir d’une
invite de commandes d’administration : Mountvol.exe /E
Aucun redémarrage n’est nécessaire pour que cela prenne effet.
NOTE
Veillez à vérifier ces informations sur tous les nodes que vous allez ajouter au cluster.
Vous ne voyez pas le disque de cluster dans
l’explorateur ou diskmgmt lors du failover dans un
cluster Windows 2008 ou Windows 2008 R2
Cet article fournit une solution à un problème dans lequel le disque de cluster est in trouver dans l’explorateur
ou diskmgmt lors du failover.
Symptômes
Le passage de la ressource de partage de fichiers du nœud A au nœud B et du disque de partage de fichiers
(exemple N :) ne s’affiche pas dans l’explorateur ou la console de gestion des disques. Nous voyons les
événements suivants, car la lettre de lecteur a été permutée lors du permutation et la ressource de partage de
fichiers ne sera pas mise en ligne même si les dépendances du partage de fichiers (disque et IP) étaient en ligne.

Catégorie de tâche : ressource du serveur de fichiers
Niveau : Error
Description :
La ressource de serveur de fichiers de cluster « AdminData » ne peut pas être mise en ligne. La ressource n’a
pas réussi à créer le partage de fichiers « NAMEOF FILESHARE RESOURCE$ » associé au nom réseau «
NAMEOF FILESHARE RESOURCE ». Le code d’erreur était « 3 ». Vérifiez que les dossiers existent et sont
accessibles. En outre, confirmez l’état du service serveur sur ce nœud de cluster à l’aide du Gestionnaire de
serveur et recherchez d’autres événements connexes sur ce nœud de cluster. Il peut être nécessaire de
redémarrer la ressource de nom de réseau « NAMEOF FILESHARE RESOURCE » dans ce service ou cette
application en cluster.
Nous pouvons également voir :

Source : Microsoft-Windows-Kernel-Tm
Mots clés : Aucun
Description :
La transaction (UOW=%1, Description='%3') n’a pas pu être engager et a été revenir en arrière . Elle est due
à un message d’erreur renvoyé par CLFS lors de la tentative d’écriture d’un enregistrement de préparation
ou de validation pour la transaction. L’erreur CLFS renvoyée était : %4.
Source : Microsoft-Windows-UserPnp
Catégorie de tâche : (7010)
Ordinateur :
Description :
Un ou plusieurs sous-systèmes du service Plug-and-Play ont changé d’état.
PlugPlay install subsystem enabled: 'true'
Sous-système de mise en cache PlugPlay activé : « true »
Cause
Cet événement se produit si un lecteur réseau est mappé sur le nœud B avec la même lettre de lecteur (c’est-à-
dire N:) qui a été affecté au disque de cluster sur le nœud actif.
Cela se produit si le lecteur réseau mappé est affecté avec la même lettre de lecteur, qui a été maintenue par la
ressource de disque de cluster sur le nœud actif ou sur le nœud avant le failover. S’il existe le disque dur local
avec la même lettre de lecteur, ce problème ne se produit pas lorsque le gestionnaire de partie affecte la même
lettre de lecteur en la permutant.
Résolution
Vous pourrez voir le disque avec la lettre de lecteur N: sur le nœud B dans l’explorateur et la gestion des disques,
une fois que vous déconnectez le lecteur réseau mappé. Même si vous ne déconnectez pas le lecteur réseau, la
lettre de lecteur reste accessible avec le partage et peut également être vue avec la même lettre de lecteur N:
sous le cluster de failover MMC.
Références
Guide pas à pas du cluster de failover : configuration d’un cluster de Two-Node de serveur de fichiers
Erreur (le nœud de cluster existe déjà) peut
apparaître lors de l’installation du cluster
Cet article fournit une solution à l’erreur (le nœud de cluster existe déjà) qui se produit lors de l’installation du
cluster.
Symptômes
Lors de la création d’un cluster via l’administrateur de cluster ou cluster.exe ligne de commande, l’erreur suivante
peut apparaître :
Le nœud de cluster existe déjà
Cause
Si le serveur actuel est membre du cluster sortant ou/et que la ressource actuelle (le plus souvent le disque de
quorum) est disponible.
Résolution
Le processus de résolution dépend de l’état actuel du membre du cluster :
1. Si le serveur actuel doit appartenir au cluster sortant, veritéz ce disque de quorum en ligne et toutes les
ressources de cluster disponibles pour une utilisation régulière. Le serveur ne doit pas être utilisé comme
nouveau membre du cluster.
2. Si le cluster actuel ne doit pas appartenir à la sortie du cluster ou/et que la configuration du cluster ne
peut pas être restaurée ou corrigée, suivez les instructions suivantes :
Le processus suivant est irréversible et peut nécessiter une réinstallation du cluster.
a. Go to Star t > Run .
b. Écrivez Cmd et appuyez sur le bouton Entrée.
c. Écrivez cluster node nodename /forcecleanup et appuyez sur Entrée.
d. Le message doit apparaître après quelques secondes : nettoyage réussi.
La validation du cluster échoue au test « Valider la
configuration du réseau de cluster » avec l’erreur
80070005
Cet article fournit une solution à l’erreur 80070005 qui se produit en cas d’échec de la validation du cluster de
failover.
Résumé
Sur un cluster de Windows Server 2008 ou Windows Server 2008 R2, validate peut échouer avec l’une des
erreurs suivantes :
Valider la configuration du réseau de cluster

Validez les réseaux de cluster qui seraient créés pour ces serveurs.
Une erreur s’est produite lors de l’exécution du test.
Une erreur s’est produite lors de l’initialisation des tests réseau.
Une erreur s’est produite lors de la création de l’agent côté serveur (CPrepSrv).
La création d’une instance du composant COM avec CLSID {E1568352-586D-43E4-933F-8E6DC4DE317A} à
partir de IClassFactory a échoué en raison de l’erreur suivante : 80070005.
OR
Valider la configuration IP
Vérifier que les adresses IP sont uniques et que les sous-réseaux sont configurés correctement.
Une erreur s’est produite lors de l’exécution du test.
Une erreur s’est produite lors de l’initialisation des tests réseau.
Une erreur s’est produite lors de la création de l’agent côté serveur (CPrepSrv).
La création d’une instance du composant COM avec CLSID {E1568352-586D-43E4-933F-8E6DC4DE317A} à
partir de IClassFactory a échoué en raison de l’erreur suivante : 80070005.
Cause
Cela peut être dû au déploiement d’une image clonée du système d’exploitation qui n’a pas été correctement
préparée à l’aide de l’Outil de préparation du système (Sysprep).
Résolution
Si l’image de base n’a pas été générée à l’aide de Sysprep avec l’option /Generalize, vous devez reconstruire
l’image de base, puis réinstaller Windows Server.
Il n’est pas pris en charge pour les serveurs SysPrep sur qui la fonctionnalité clustering de failover est installée.
La fonctionnalité cluster de failover doit être installée une fois que le système a été cloné et SysPreped.
La création d’un cluster de failover échoue avec
l’erreur 0xc000005e
Cet article fournit une solution pour corriger les erreurs 0xc000005e qui se produit lorsque vous créez un
cluster de Windows Server 2012.
Symptômes
Lorsque vous tentez d’exécuter l’Assistant Création d’un cluster pour créer un cluster de Windows Server 2012,
l’opération peut échouer. En outre, vous pouvez recevoir l’erreur suivante :
Une erreur s’est produite lors de la création du cluster. Une erreur s’est produite lors de la création du cluster «
MyCluster ». Erreur inconnue (0xc000005e)
Remarque : une erreur signifie 0xc000005e’STATUS_NO_LOGON_SERVER
Lorsque vous examinez le createCluster.mht situé sous le répertoire C:\Windows\Cluster\Reports, vous
remarquerez peut-être que l’échec de l’opération se produit au cours des opérations suivantes :
Vérification de l’objet ordinateur « MyCluster » dans le domaine. Nettoyage impossible.
Cause
Ce problème peut se produire si le port TCP ou UDP 464 est bloqué.
Résolution
Pour résoudre ce problème, assurez-vous que le port 464 pour TCP et UDP est ouvert sur tous les périphériques
réseau de pare-feu entre les nodes du cluster et le contrôleur de domaine.
L’erreur STATUS_NO_LOGON_SERVER est due au fait que les nodes du cluster n’ont pas pu communiquer avec
un contrôleur de domaine pour définir le mot de passe lors de la tentative de configuration des objets
ordinateur dans Active Directory. Le port 464 est activé par défaut dans Windows pare-feu sur Windows Server
2012.
Pour plus d’informations sur les conditions requises pour les ports du service Active Directory, voir l’article
suivant : Active Directory and Active Directory Domain Services Port Requirements
Vous recevez un message d’erreur et l’ID
d’événement 1289 est enregistré lorsque vous
essayez de créer un cluster.
Cet article permet de résoudre un problème qui se produit lorsque vous essayez de créer un cluster sur un
ensemble d’ordinateurs sur qui la fonctionnalité clustering de failover est installée.
Symptômes
Vous installez la fonctionnalité clustering de failover sur un ensemble d’ordinateurs Windows Server 2008.
Vous essayez de créer un cluster deover sur ces ordinateurs à l’aide du logiciel en ligne de commande MMC
(Failover Cluster Management Console) ou de l’outil Cluster.exe de gestion du cluster de Cluster.exe.
Dans ce scénario, la création du cluster échoue et vous recevez le message d’erreur suivant :
Une erreur s’est produite lors de la création du cluster. Une erreur s’est produite lors de la création du cluster
« clustername ». Le service n’a pas été démarré.
En outre, l’événement suivant est consigné dans le journal système :
Cause
Pour éliminer les points de défaillance liés à la communication réseau, le clustering deover utilise le pilote
miniport virtuel du cluster de failovers Microsoft. En outre, ce pilote génère une adresse physique au
démarrage. Toutefois, l’une des situations suivantes peut faire échouer la création du cluster :
Aucune carte physique ne dispose d’une adresse MAC administrée universellement.
La configuration du cluster n’est pas entièrement nettoyée après une séquence d’installation et de
suppression répétées de la fonctionnalité clustering de failover.
Résolution
Pour résoudre ce problème, suivez les étapes suivantes pour réinstaller la fonctionnalité clustering deover :
1. Sur chaque ordinateur sur qui vous souhaitez faire un nœud de cluster, utilisez la console Gestionnaire de
serveur pour supprimer la fonctionnalité clustering de failover.
2. Redémarrez chaque ordinateur à partir duquel vous avez supprimé la fonctionnalité clustering deover.
3. Ajoutez à nouveau la fonctionnalité clustering de failover sur tous ces ordinateurs.
4. Exécutez la validation de cluster sur ces ordinateurs.
5. Essayez de créer un cluster.
Si le problème n’est pas résolu après avoir réinstallé la fonctionnalité clustering deover, suivez ces étapes, puis
ré-exécutez la réinstallation.
IMPORTANT

2. Trouvez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class{ 4D36E972-E325-11CE-
BFC1-08002BE10318}
3. Sous cette sous-clé, recherchez la sous-clé qui contient une entrée de valeur de chaîne DriverDesc dont
la valeur est « Microsoft Failover Cluster Virtual Adapter ».
4. Sous la sous-clé trouvée à l’étape 3, ajoutez l’entrée de Registre de valeur de chaîne suivante :
Nom : DatalinkAddress
Données de valeur : 02-AA-BB-CC-DD-01
6. Répétez les étapes 1 à 5 sur les autres ordinateurs sur lesquels vous faites l’expérience de ce problème.
Lorsque vous le faites sur d’autres ordinateurs, remplacez les données de valeur du Registre par des
valeurs différentes afin de définir une valeur unique pour chaque nœud. Par exemple, définissez la valeur
du deuxième nœud sur 02-AA-BB-CC-DD-02 et la valeur sur le troisième nœud sur 02-AA-BB-CC-DD-03.
Si vous remarquez ce comportement sur des clusters distincts, veillez à utiliser une adresse pour chaque
nœud qui est unique dans tous les clusters.
7. Essayez de créer à nouveau le cluster.
Implications de l’utilisation du commutateur
/forcequorum pour démarrer le service de cluster
Cet article décrit les implications du démarrage du service de cluster à l’aide du commutateur /forcequorum
Beta Information
Cet article traite d’une version bêta d’un produit Microsoft. Les informations de cet article sont fournies telles
qu’elle sont et sont sujettes à modification sans préavis.
Aucun support technique formel n’est disponible auprès de Microsoft pour ce produit bêta. Pour plus
d’informations sur la façon d’obtenir la prise en charge d’une version bêta, consultez la documentation incluse
dans les fichiers de produit bêta ou vérifiez l’emplacement Web où vous avez téléchargé la version.
Introduction
Dans Windows Server 2003, les clusters de serveurs configurés pour utiliser un modèle de quorum MNS
(Majority Node Set) peuvent forcer le démarrage du service de cluster lorsque le nombre minimal de nœuds de
cluster requis est inférieur au nombre requis de nœuds de cluster participant au cluster. La formule suivante
permet de déterminer le nombre minimal de nodes de cluster requis :
( <Total configured cluster nodes> /2) + 1
Par exemple, un cluster MNS à 4 nœuds requiert au moins trois nœuds à considérer comme fonctionnels ((4/2)
+ 1 = 3).
Pour démarrer le service de cluster à l’aide de la méthode de modèle de quorum MNS, utilisez la clé de Registre
ForceQuorum ou utilisez un paramètre de démarrage, tel que le commutateur /forcequorum.
NOTE
La clé de Registre ForceQuorum se trouve sous la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters
Il existe des procédures spéciales qui sont requises pour une récupération correcte après l’utilisation du
commutateur /forcequorum. Cet article décrit les implications de l’utilisation du commutateur /forcequorum
pour démarrer le service de cluster dans Windows Server 2008. Dans les clusters de basculement basés sur
Windows Server 2008, le démarrage du service de cluster avec un commutateur /forcequorum a plus
d’implications que dans les systèmes d’exploitation précédents.
Dans les clusters de Windows Server 2008, les informations de configuration de cluster sont suivis sur tous les
nodes du cluster et sur un disque témoin, si un cluster est configuré. Un processus de marquage Paxos est utilisé
pour garantir la cohérence de la configuration du cluster sur tous les nodes et sur le disque témoin. L’algorithme
Paxos est utilisé pour garantir la cohérence entre les systèmes distribués. L’algorithme est utilisé par le service
de cluster pour garantir la cohérence des données lorsque les mises à jour de la configuration du cluster sont
propagées sur tous les nodes du cluster.
Dans Windows clusters deover basés sur Server 2008, la balise Paxos se compose de trois nombres. Chaque
nombre est séparé par un deux-points. Par exemple, une balise peut ressembler à ce qui suit :
3:3:276
Ces nombres représentent le numéro NextEpoch, le numéro LastUpdateEpoch et le numéro de séquence. Dans
l’idéal, la balise Paxos doit être identique sur tous les réplicas de la configuration de cluster. Les nombres Époque
sont modifiés chaque fois que le cluster est formé. Le numéro de séquence est modifié chaque fois qu’une mise
à jour est mise à jour de la configuration du cluster. Le processus de synchronisation dans un cluster envoie une
proposition à tous les nodes du cluster. La proposition se compose d’un numéro de séquence et d’un numéro de
proposition. Un nœud de cluster vérifie sa copie locale de la configuration de cluster pour voir s’il a un numéro
de séquence plus nouveau ou un numéro de proposition supérieur. Si le nœud ne comprend pas d’informations
plus à jour (nombres plus élevés), il renvoie une acceptation au nœud de proposition. Si la plupart des nœuds
du cluster (un « consensus ») renvoient une acceptation au nœud de proposition, les données sont envoyées à
chaque nœud de cluster pour être incorporées localement.
Lorsqu’un nœud de cluster rejoint un cluster, il envoie ses informations de balise Paxos dans le cadre du
processus de jointage. Si les informations de balise Paxos pour le nœud de jointage sont plus anciennes que la
configuration de cluster actuelle, une copie complète de la configuration de cluster est poussée vers le nœud
dans le cadre du processus de jointage. Cette copie de la configuration de cluster est appelée ruche de Registre
de cluster. Ce comportement garantit que tous les nodes qui rejoignent un cluster ont les informations de
configuration les plus à jour.
Le format de balise Paxos dans un cluster ne peut changer que dans les deux scénarios suivants :
Lors de l’exécution d’une restauration faisant autorité de la configuration de cluster.
Lorsque le service de cluster est démarré à l’aide du commutateur /forcequorum. Le raccourci du
commutateur est /fq.
La nouvelle mise en forme de balise Paxos utilise des horodatages. Voici un exemple de la nouvelle mise en
forme :
12/2007/31-15 35 55.889_4:2007/12/31-15 35 55.889_4:294
Ce format garantit que les nodes qui exécutent le service de cluster avec ce format de balise Paxos auront la
copie de référence ou faisant autorité de la configuration du cluster. Cette copie de la configuration du cluster est
automatiquement poussée vers tout nœud qui rejoint le cluster pendant le processus de jointage. Par
conséquent, lorsque vous décidez de forcer le service de cluster à démarrer sur un nœud spécifique dans un
cluster de serveurs de Windows Server 2008, il est important de sélectionner le nœud qui dispose des
informations de configuration de cluster les plus à jour. Dans le cas contraire, certains paramètres de
configuration risquent d’être perdus.
Références
Pour plus d’informations sur le modèle de quorum MNS, visitez le site Web Microsoft suivant :
Pour plus d’informations sur l’algorithme Paxos, visitez le site Web Microsoft suivant :
https://research.microsoft.com/users/lamport/pubs/paxos-simple.pdf
Déplacer un cluster Windows d’un domaine vers un
autre
Windows clustering fournit une haute disponibilité des ressources serveur. Cet article explique comment
déplacer un cluster de serveurs Windows d’un domaine à un autre.
NOTE
Nous vous déconseillons d’effectuer ce type de déplacement dans un environnement de production.
En raison d’une dépendance accrue envers les services de domaine Active Directory, Microsoft ne prend pas en
charge le déplacement d’un cluster de Windows Server 2008, Windows Server 2008 R2 et Windows Server
2012 déjà installé et configuré d’un domaine à un autre. Les étapes suivantes ne sont pas Windows Server
2008, Windows Server 2008 R2 et Windows Server 2012 vous devez créer un cluster. En outre, vous devez
recluster les applications hautement disponibles.
Bien que vous pouvez déplacer un cluster de serveurs Microsoft Windows 2000 ou un cluster de serveurs
Windows Server 2003 d’un domaine à un autre, nous vous recommandons de reconstruire le cluster dans le
nouveau domaine afin que tous les services et applications installés soient configurés correctement dans le
nouveau domaine. Vous pouvez utiliser les étapes de cet article pour permettre au service de cluster de
démarrer et de fonctionner dans un nouveau domaine. Toutefois, ces étapes ne vous assurent pas que toutes les
ressources seront disponibles dans le nouveau domaine.
NOTE
Microsoft ne prend pas en charge les administrateurs qui tentent de déplacer des ressources d’un domaine vers un
autre si l’opération sous-jacente n’est pas prise en charge. Par exemple, Microsoft ne prend pas en charge les
administrateurs qui tentent de déplacer un serveur Microsoft Exchange d’un domaine vers un autre.
Vous ne pouvez pas déplacer Windows clusters NT 4.0 d’un domaine vers un autre si l’un des noms de ces derniers est
un contrôleur de domaine.
WARNING
Nous vous recommandons d’effectuer une sauvegarde complète de toutes les données sur tous les disques durs partagés
sur chaque nœud du cluster avant d’essayer de déplacer le cluster.
Les étapes de cet article permettent au service de cluster de démarrer dans le nouveau domaine. Toutefois, il se
peut que vous ne parvenez pas à mettre les ressources en ligne dans le nouveau domaine et que les ressources
qui peuvent être mise en ligne risquent de ne pas fonctionner correctement.
Pour déplacer le cluster :
1. Créez un compte d’utilisateur pour le service de cluster dans le nouveau domaine. Vous devez vous
assurer qu’aucun objet de stratégie de groupe ou aucune exigence de modèle de sécurité ne supprime
l’un de ces droits. Le compte d’utilisateur doit avoir les droits suivants :
Verrouillez les pages en mémoire.
Connectez-vous en tant que service.
Agir dans le cadre du système d’exploitation. (Windows 2000 et Windows Server 2003)
Back up files and directories.
Augmenter les quotas.
Augmentez la priorité de planification.
Charger et décharger les pilotes de périphériques.
Restaurer des fichiers et des répertoires.
Ajuster les quotas de mémoire pour un processus (Windows Server 2003).
En outre, le compte de service de cluster doit avoir des autorisations administratives sur tous les nodes
du cluster.
2. Définissez la valeur de démarrage du service de cluster sur Manuelle sur tous les nodes du cluster :
a. Cliquez sur Démarrer, pointez Paramètres, cliquez sur Panneau de contrôle, puis double-cliquez sur
Services.
b. Cliquez sur Ser vice de cluster, puis sur Démarrage.
c. Modifiez le type de démarrage de Automatique à Manuel.
d. Cliquez sur OK.
3. Arrêtez le service de cluster sur tous les nodes de cluster :
a. Cliquez sur Démarrer, pointez Paramètres, cliquez sur Panneau de contrôle, puis double-cliquez sur
Services.
b. Cliquez sur Ser vice de cluster, puis sur Arrêter.
4. Désactiver tous les nodes à l’exception d’un.
5. Déplacez le nœud dans le nouveau domaine à l’aide des procédures appropriées à votre système
d’exploitation. Terminez le processus, puis redémarrez le nœud.
6. Sur le nœud, modifiez le compte de service utilisé par le service de cluster pour vous connecter au
domaine en compte d’utilisateur que vous avez créé.
7. Démarrez le service de cluster sur ce nœud.
8. Utilisez l’administrateur de cluster pour vérifier qu’il n’y a aucun problème. Essayez de mettre toutes les
ressources en ligne. Testez la fonctionnalité de toutes les ressources des ordinateurs clients, puis
recherchez les messages d’erreur dans le journal système de l’Observateur d’événements.
NOTE
À ce stade, vous pouvez toujours annuler le déplacement en déplaçant ce nœud vers l’ancien domaine et en
délant les nœuds qui ne sont pas déplacés.
9. Si le premier déplacement de nœud réussit, continuez à migrer les autres nœuds du cluster vers le
nouveau domaine en commençant par l’étape 5 pour chaque nœud.
WARNING
Si vous déplacez un ordinateur qui possède une instance Virtual Microsoft SQL Server 7.0 vers un autre domaine et que
vous n’êtes pas d’abord uncluster SQL Server 7.0, les ressources du cluster SQL risquent d’échouer. En raison de l’échec de
SQL Server 7.0, vous de devez peut-être travailler avec Microsoft CSS pour unter manuellement SQL Server 7.0. Une fois
que vous n’avez pas SQL Server 7.0, vous devez utiliser l’Assistant Deover de cluster SQL pour rétablir vos ordinateurs
SQL Server cluster. Vous de devez également supprimer complètement SQL Server 7.0, puis le réinstaller.
NOTE
Si votre serveur DNS se trouve dans une zone sécurisée, les inscriptions DNS peuvent être affectées. Dans une zone DNS
sécurisée, les informations d’identification du compte qui effectue l’inscription sont capturées et stockées avec les
enregistrements. Cela les protège contre le remplacement malveillant par des valeurs incorrectes. Pour un serveur virtuel
de cluster, le compte de service de cluster d’origine serait utilisé à cet effet. Vous pouvez voir des échecs d’inscription DNS
dans les journaux des événements système, généralement l’erreur 9005 (refusée). Si cela se produit, supprimez les
enregistrements sur le serveur DNS et déconnectez le nom du réseau, puis de nouveau en ligne afin que les nouvelles
informations d’identification soient enregistrées avec l’inscription.
Message d’erreur « Échec de chargement du
fournisseur » lorsque vous essayez d’ajouter un
nœud à un cluster de Windows Server 2008
Cet article fournit une solution à une erreur qui se produit lorsque vous essayez d’ajouter un nœud à un cluster
de Windows Server 2008.
Symptômes
Lorsque vous essayez d’ajouter un nœud à votre cluster de Windows Server 2008 existant à l’aide de l’Assistant
Add-Node, vous recevez le message d’erreur suivant en bas de l’écran de l’Assistant Add-Node :
Échec de chargement du fournisseur
Cause
L’erreur « Échec de chargement du fournisseur » est renvoyée par WMI lorsqu’une requête est exécutée et
qu’elle ne peut pas charger les fournisseurs requis pour satisfaire la requête. Dans ce cas, l’Assistant « Ajouter un
nœud » du cluster fait une requête pour identifier le domaine du serveur et le fournisseur n’est pas
correctement enregistré sur le serveur.
Suivez ces étapes pour déterminer si vous rencontrez ce problème, à la fois sur le serveur que vous tentez
d’ajouter au cluster et sur le nœud qui fait déjà partie du cluster :
1. Ouvrez WMI Tester - wbemtest.exe.
2. Sélectionnez Connecter .
3. Dans la zone Espace de noms, entrez \ cimv2 racine, puis sélectionnez Connecter .
4. Sélectionnez Requête, puis entrez SELECT Domain FROM Win32_ComputerSystem .
Si vous obtenez l’erreur « Échec de chargement du fournisseur », vous rencontrez le problème documenté dans
cet article, sur ce serveur.
Résolution
IMPORTANT
Pour résoudre ce problème, vous devez corriger les informations d’inscription du fichier Cimwin32.dll dans le
Registre, en utilisant les étapes suivantes :
1. Identifiez un ordinateur Windows Server 2008 qui se trouve au même niveau service pack et correctif
que le serveur à problème et vous pouvez exécuter correctement la requête mentionnée ci-dessus,
Wbemtest.exe.
NOTE
Il ne s’agit pas nécessairement d’un nœud de cluster.
2. Pour ouvrir l’Éditeur du Registre, sélectionnez Démarrer, puis entrez regedit.

Autorisation d’administrateur requise si vous êtes invité à fournir un mot de passe administrateur ou une
confirmation, tapez le mot de passe ou fournissez une confirmation.
3. Accédez à la clé suivante :
HKEY_CLASSES_ROOT\CLSID\{D63A5850-8F16-11CF-9F47-00AA00BF345C}\InprocServer32
4. Sélectionnez la clé ou la sous-clé que vous souhaitez récupérer.

5. Sélectionnez le menu Fichier, puis sélectionnez Expor ter.
6. Dans la zone Enregistrer dans, sélectionnez l’emplacement où vous souhaitez enregistrer la copie de
sauvegarde, puis tapez un nom pour le fichier de sauvegarde dans la zone Nom de fichier. Enregistrez-le
en tant que . Fichier REG.
7. Copiez le texte enregistré ci-dessus. Fichier REG vers le serveur à problème.
8. Accédez au fichier sur le serveur à problème et double-cliquez sur le fichier pour le fusionner dans le
Registre.
Les nodes de cluster invité dans Hyper-V peuvent
ne pas être en mesure de créer ou de rejoindre
Cet article fournit des solutions de contournement à un problème que les nodes de cluster invité dans Hyper-V
peuvent ne pas être en mesure de créer ou de rejoindre.
Symptômes
Les clusters deover qui sont en cours d’exécution sur des machines virtuelles (parfois appelés « clusters invités
») peuvent avoir des problèmes avec les nodes qui rejoignent le cluster.
À l’aide de l’Assistant Création d’un cluster, la création du cluster peut échouer. En outre, le rapport de
l’Assistant peut avoir le message suivant :
Une erreur s’est produite lors de la création du cluster.

Une erreur s’est produite lors de la création du cluster <clustername> ' '.
Cette opération a été renvoyée car le délai d’expiration a expiré
NOTE
Les erreurs ci-dessus sont également visibles chaque fois que les communications entre les serveurs spécifiés pour faire
partie de la création du cluster ne sont pas terminées. Une cause connue est décrite dans cet article.
Dans certains scénarios, les nœuds de cluster sont correctement créés et joints si les VM sont hébergés sur le
même nœud. Toutefois, une fois que les VM sont déplacés vers différents nodes, les communications entre les
nodes du cluster invité commencent à échouer. Par conséquent, les nodes du cluster peuvent être supprimés du
cluster.
Cause
Ce problème peut se produire en raison de paquets qui n’atteignent pas les ordinateurs virtuels, lorsque les
ordinateurs virtuels sont hébergés sur des serveurs de cluster de Windows Server 2012, en raison d’un
composant de cluster deover lié aux cartes réseau des hôtes. Le composant est appelé « filtre de performances
de carte virtuelle de cluster de failover Microsoft » et il a été introduit pour la première fois dans Windows
Server 2012.
Le problème affecte uniquement les paquets réseau adressés aux nodes de cluster hébergés sur des machines
virtuelles.
Si le cluster de basculement Windows Server 2012 doit héberger des machines virtuelles faisant partie de
clusters invités, il est recommandé de l’liez l’objet « Filtre de performances de carte virtuelle du cluster de
basculement Microsoft » de toutes les cartes réseau de commutateur virtuel sur les serveurs de cluster de
basculement Windows Server 2012.
NOTE
Ce problème peut affecter toute version Windows cluster de serveurs de failover qui s’exécute à l’intérieur de machines
virtuelles en tant que cluster invité. Les informations mentionnées dans la cause et la solution de contournement de cet
article sont spécifiques Windows Server 2012 clusters de basculement utilisés pour héberger des machines virtuelles.
Vous pouvez désactiver l’objet « Filtre de performances de la carte virtuelle du cluster de failover » à l’aide de
l’une des méthodes ci-dessous :
Désactivation de l’utilisation de l’interface graphique graphique
Ouvrez Connexions réseau pour obtenir la liste des cartes réseau. Toutes les cartes réseau avec le « vEthernet
» (nom par défaut) sont les réseaux virtuels (c’est-à-dire, le commutateur virtuel). Les cartes physiques qui ont
également une carte virtuelle Hyper-V configurée pour celle-ci n’auront pas la liaison « Filtre de performances
de la carte virtuelle du cluster de failover Microsoft », il n’y a donc rien à désactiver pour ces cartes.
1. Cliquez avec le bouton droit sur l’une des cartes « v » et sélectionnez Propriétés dans le menu.
2. Décochez l’élément étiqueté « Filtre de performances de la carte virtuelle du cluster de failover Microsoft ».
3. Cliquez sur OK pour fermer la boîte de dialogue et désactiver la liaison pour l’élément désactivé.
4. Répétez cette répétition pour toutes les cartes.
Désactivation de l’utilisation Windows PowerShell
Le processus suivant désactive la carte réseau, qui est une liaison pour « Filtre de performances de la carte
virtuelle du cluster de failover Microsoft » sur chaque carte sur le serveur dont le componentid est « vms_mp ».
Ce Componentid indique que la carte est une carte Hyper-V utilisée par le commutateur virtuel.
Vous pouvez exécuter ce processus sur chaque nœud du serveur afin que la liaison soit désactivée pour chaque
serveur pour les adaptateurs utilisés par le commutateur virtuel.
Ouvrez la console Windows PowerShell avec accès administrateur à l’aide de l’option Exécuter en tant
Exécutez la commande suivante :
Get-netadapter | Disable-NetAdapterBinding -DisplayName "Microsoft Failover Cluster Virtual Adapter

Performance Filter"
NOTE
Si vous souhaitez activer à nouveau la liaison, remplacez simplement « Disable-NetAdapterBinding » par « Enable-
NetAdapterBinding ».
Pour vérifier quelles cartes réseau ont l’élément « Filtre de performances de la carte virtuelle du cluster
de failover » lié à celui-ci, vous pouvez exécuter le processus suivant :
PS C:\Windows\system32> Get-NetAdapterBinding | Where-Object {$_.DisplayName -eq "Microsoft Failover
Cluster Virtual Adapter Performance Filter"} | FT Name,DisplayName,Enabled
Name DisplayName Enabled

------- --------------- ----------
vEthernet Microsoft Failover Cluster Virtual A... False
vEthernet 2 Microsoft Failover Cluster Virtual A... False
vEthernet 3 Microsoft Failover Cluster Virtual A... False
Ethernet 3 Microsoft Failover Cluster Virtual A... False
Ethernet 2 Microsoft Failover Cluster Virtual A... False
Ethernet Microsoft Failover Cluster Virtual A... False
La propriété « Enabled » de la liaison pour chaque carte est « False », ce qui signifie qu’elle n’est pas liée à
cette carte.
Windows Server 2012 cluster de commutation d’ordinateurs dispose d’un composant lié aux cartes réseau
appelées « Filtre de performances de la carte virtuelle du cluster de commutation Microsoft » et il peut entraîner
l’in-passage de certains paquets adressés aux nodes de cluster de la machine virtuelle. Si ce problème se
produit lorsqu’un nœud rejoint le cluster à l’intérieur de la machine virtuelle, il se peut qu’il ne puisse pas être
ajouté au cluster ou qu’il rejoigne le cluster.
Le composant « Microsoft Failover Cluster Virtual Adapter Performance Filter » est utilisé par la carte virtuelle
NetFT du cluster de failover pour router certaines communications spécifiques du cluster entre les serveurs du
cluster. Il n’est pas nécessaire que la liaison de cet élément soit activée pour que NetFT fonctionne. Par
conséquent, pour les hôtes Hyper-V exécutant Windows Server 2012, il est recommandé de désactiver la liaison
de ce composant sur toutes les cartes des hôtes Hyper-V qui sont membres d’un cluster deover.
Vous ne pouvez pas joindre un nœud à un cluster si
le port UDP 3343 est bloqué
Cet article fournit une solution à un problème dans lequel les utilisateurs ne peuvent pas joindre un nœud à un
cluster si le port UDP 3343 est bloqué.
Symptômes
Sur un ordinateur exécutant Windows Server 2008 ou Windows Server 2008 R2.
Vous essayez de joindre le nœud à un cluster.
Dans ce scénario, il se peut que vous ne soyez pas en mesure de joindre le nœud au cluster et que vous receviez
l’erreur suivante dans le journal des événements système :

Date : <date>
Catégorie de tâche : Carte virtuelle de cluster
Niveau : Critique
Mots clés :
Ordinateur : <computer>
Description :
Le nœud n’a pas pu rejoindre le cluster car il n’a pas pu envoyer et recevoir de messages réseau de
détection d’échec avec <computer> d’autres nœuds de cluster. Exécutez l’Assistant Valider une configuration
pour vérifier les paramètres réseau. Vérifiez également la Windows règles de pare-feu « Clusters de failover
».
Cause
Les nodes de cluster communiquent sur le port UDP (User Datagram Protocol) 3343. Le problème peut se
produire car le port UDP 3343 n’est pas ouvert.
Résolution
Pour résoudre le problème, ouvrez le port UDP 3343 requis sur le cluster.
Il s’agit d’un exemple de journal de cluster. Le port UDP 3343 sur le cluster est bloqué :
00001344.0000043c::2010/07/27-12:54:42.832 INFO [CORE] Nœud 88f462ac-eb7c-4b57-aaf2-

7a989aa38806: Cookie Cache 88f462ac-eb7c-4b57-aaf2-7a989aa38806
00001344.0000043c::2010/07/27-12:54:42.832 DBG [CHANNEL 10.100.20.27:~3343~] Poignée de
fermeture non valide.
00001344.0000043c::2010/07/27-12:54:42.832 WARN cxl::ConnectWorker::operator ():
GracefulClose(1226)' because of 'channel to remote endpoint 10.100.20.27:~3343~ is closed'
00001344.00001b8c::2010/07/27-12:54:43.815 INFO [JPM] Node 3: Selected partition 904(1 2 4 5) as a
target for join
00001344.00001b8c::2010/07/27-12:54:43.815 WARN [JPM] Node 3: No connection to node(s) (2).
Impossible de rejoindre l’équipe
00001344.0000043c::2010/07/27-12:54:44.813 INFO [JPM] Node 3: Selected partition 904(1 2 4 5) as a
target for join
00001344.0000043c::2010/07/27-12:54:44.813 WARN [JPM] Node 3: No connection to node(s) (2).
00001344.00001b8c::2010/07/27-12:54:45.827 INFO [JPM] Node 3: Selected partition 904(1 2 4 5) as a
target for join
00001344.00001b8c::2010/07/27-12:54:45.827 WARN [JPM] Node 3: No connection to node(s) (2).
00001344.0000043c::2010/07/27-12:54:46.825 INFO [JPM] Node 3: Selected partition 904(1 2 4 5) as a
target for join
00001344.0000043c::2010/07/27-12:54:46.825 WARN [JPM] Node 3: No connection to node(s) (2).
Vous pouvez confirmer le port UDP 3343 par netstat -ano commande.
Pour plus d’informations, voir ID d’événement 1572 — Connectivité réseau et configuration.
Les ressources d’adresse IP de cluster échouent sur
les deux nœuds d’un cluster à deux nœuds à deux
sites lorsqu’un nœud se déconnecte du réseau
VLAN public
Cet article décrit le comportement qui se produit lorsqu’un nœud d’un cluster à deux nœuds à deux sites se
déconnecte du VLAN du cluster public. Dans ce cas, les ressources d’adresse IP et leurs groupes de clusters
correspondants échouent sur les deux nodes.
Symptômes
Vous disposez d’un cluster à deux sites qui possède un nœud dans chaque site. Le cluster utilise une ressource
de témoin de partage de fichiers (FSW). Les nodes de cluster sont connectés par les réseaux suivants :
Un VLAN privé étiré
Un VLAN public non étendu
Dans ce scénario, l’un des nodes se déconnecte du VLAN public. La figure suivante illustre la configuration qui
en résulte.
Le cluster détecte l’interruption et marque la carte réseau VLAN publique sur le nœud 2 comme « Échec ». Par
conséquent, toutes les ressources d’adresse IP de cluster sur le nœud 2 échouent. Les groupes de clusters
associés à ces ressources échouent également. Le cluster génère des messages qui ressemblent à ce qui suit :
000005ec.000011e4::2020/09/19-19:41:51.777 DBG [IM - public-1.0.0] Ajout d’états d’interface pour les

interfaces inter-sous-réseau uniquement
000005ec.000011e4::2020/09/19-19:41:51.777 DBG [IM - public-1.0.0] Interface 1ee3567e-84f7-459a-
a39e-a5c44de643fa has no up cross-subnet routes. Marquage de l’échec
Étant donné que les deux sites ne peuvent pas communiquer sur le réseau local (VLAN) public, le cluster marque
également la carte réseau VLAN publique sur le nœud 1 comme « Échec ». Par conséquent, toutes les
ressources d’adresse IP de cluster et les groupes de clusters associés sur le nœud 1 échouent.
00001790.000006ac::2020/09/19-19:41:51.780 INFO [IM] Modification de l’état des adaptateurs en fonction

des résultats : <class mscs::InterfaceResult>
00001790.00001678::2020/09/19-19:41:51.780 DBG [IM] EventManager::P rocessInterfaceChanged:
Ignoring event for Node1- 1.0.0-range that should not be published.
00001790.00001678::2020/09/19-19:41:51.780 DBG [NM] Got interface changed event for adapter Node1 -
1.0.0-range, new state 1
000012dc.00001664::2020/09/19-19:41:51.796 WARN [RES] Adresse IP <Cluster IP Address x.x.x.x> :
WorkerThread: NetInterface 1ee3567e-84f7-459a-a39e-a5c44de643fa has failed. Ressource défaillante.
Au final, la connexion perdue à un nœud entraîne l’échec des groupes de clusters sur les deux nœuds. Vous
devez mettre manuellement les nodes en ligne à nouveau.
Si les deux nœuds de cluster se trouveraient dans le même site, une déconnexion réseau similaire entraînerait
l’échec de la carte réseau VLAN publique sur le nœud 2 de la même manière. Toutefois, dans ce cas, tous les
groupes de cluster sur le nœud 2 sont retentés sur le nœud 1. Les ressources d’adresse IP de cluster sur le
nœud 1 ne échouerait pas.
Statut
Ce comportement est inhérent au produit. Nous vous recommandons d’utiliser quatre nodes au lieu de deux
pour les clusters multisesses. Les clusters HCI Azure AzS nécessitent quatre nodes.
Pour éviter ce comportement, vous pouvez modifier votre configuration de cluster à l’aide de l’une des
Ajoutez au moins un nœud de cluster à chaque site. Dans cette configuration, si un nœud sur un site se
déconnecte, le nœud restant continue de communiquer avec l’autre site. Les ressources de cluster sur le
nœud restant et sur les nœuds du site non affecté restent en ligne.
Ajoutez un autre nœud de cluster sur un troisième site. Dans cette configuration, si un nœud se déconnecte,
les deux nœuds restants restent en ligne et la communication intersession continue.
Modifiez le réseau de cluster privé en réseau local local (VLAN) non étendu. Dans cette configuration, si un
nœud se déconnecte, le cluster démarre l’algorithme d’arbitrage pour déterminer la propriété des ressources
et du quorum.
Si vous avez la configuration décrite dans la section « Symptômes » et que vous devez déconnecter un nœud de
manière contrôlée (par exemple, pour une fenêtre de maintenance planifiée), préparez le cluster avant de vous
déconnecter. Utilisez l’une des approches suivantes :
Désactivez tous les réseaux à l’exception du VLAN de cluster public.
Fermez tous les nodes de cluster à l’exception d’un.
Lorsque vous êtes prêt à reprendre les opérations classiques, commencez par activer les réseaux (ou redémarrer
les nodes).
Comment configurer un serveur d’impression en
cluster
Cet article décrit les étapes à suivre pour configurer un serveur d’impression en cluster.
Vous pouvez utiliser Windows clustering pour héberger les fonctionnalités du serveur d’impression. Les étapes
de configuration de Microsoft Windows Server 2003 diffèrent de celles de Microsoft Windows NT Server 4.0,
Êdition Entreprise, Microsoft Windows 2000 Advanced Server et Microsoft Windows 2000 Datacenter Server.
Pour configurer un serveur d’impression en cluster, vous devez configurer uniquement la ressource Spooler
dans l’administrateur de cluster, puis vous connecter au serveur virtuel pour configurer les ports et les files
d’attente d’impression. Il s’agit d’une amélioration par rapport aux versions précédentes du clustering Windows
dans laquelle vous deviez répéter les étapes de configuration sur chaque nœud du cluster.
Comment configurer la ressource depooler pour le cluster
La première étape de la configuration d’un serveur d’imprimantes en cluster consiste à créer une ressource
Spooler pour le service sur un serveur en cluster. Les ressources appropriées doivent être disponibles pour le
service depooler. Pour ce faire, créez une ressource Spooler dans l’administrateur de cluster :
1. Pour ouvrir l’administrateur de cluster, cliquez sur Démarrer, cliquez sur Exécuter, tapez cluadmin, puis
cliquez sur OK.
2. Cliquez avec le bouton droit dans le volet gauche, puis cliquez sur Configurer l’application.
3. Dans l’écran d’accueil, cliquez sur Suivant, puis sur Suivant à nouveau pour créer un serveur virtuel.
4. Cliquez sur Utiliser un groupe de ressources existant, puis sur un groupe existant qui possède une
ressource disque dans laquelle vous souhaitez stocker les pilotes depooler et d’imprimante. Cliquez sur
Suivant .
5. Pour le nom du groupe de ressources, fournissez un nom qui représente précisément le groupe, tel que «
SPOOLER ».
NOTE
Ce nom est uniquement à des fins administratives dans Administrateur de cluster.
6. Dans l’écran Informations d’accès au serveur virtuel :

a. Sous Nom du réseau, entrez un nom NetBIOS auquel les clients se connectera. Il s’agit du nom du
serveur virtuel NetBIOS utilisé par les clients pour accéder aux imprimantes :
\\Vir tualSer ver \Printer
NOTE
Microsoft recommande d’adhérer à la norme d’attribution de noms 8.3 pour assurer la compatibilité avec
les versions antérieures du client.
b. Entrez l’adresse IP que les clients utiliseront pour se connecter à ce serveur d’impression virtuel. Si les
services d’impression pour Unix sont installés et en cours d’exécution sur les nodes du cluster, les
clients peuvent se connecter à cette adresse IP à l’aide d’une imprimante de ligne distante (LPR).
8. Dans l’écran Propriétés avancées, vous pouvez apporter des modifications aux ressources qui sont sur le
point d’être créées, puis cliquer sur Suivant .
9. Dans l’écran Créer une ressource pour mon application, cliquez sur Suivant.
10. Cliquez sur Imprimer lepooler, puis sur Suivant .
11. Nommez la ressource Spooler.
NOTE
Ce nom est uniquement à des fins administratives dans Administrateur de cluster.
12. Définissez les dépendances pour la ressource Spooler :

a. Cliquez sur Propriétés avancées et, sous l’onglet Dépendances, cliquez sur Modifier.
b. Double-cliquez sur la ressource de disque physique sur laquelle vous souhaitez que les fichiers
dupooler soient situés et sur la ressource Nom du réseau que vous avez créée.
c. Cliquez deux fois sur OK .
14. Cliquez sur Terminer pour terminer l’Assistant.
15. Vérifiez la configuration et testez le failover :
a. Cliquez avec le bouton droit sur le groupe depooler, puis cliquez sur Mettre en ligne.
b. Vérifiez que toutes les ressources sont en ligne, puis vérifiez la présence d’erreurs dans les journaux
d’événements.
c. Cliquez avec le bouton droit sur le groupe depooler, cliquez sur Déplacer le groupe, déplacez la
ressource Spooler vers chaque nœud du cluster qui est un propriétaire possible, puis vérifiez que
toutes les ressources sont en ligne.
NOTE
Si vous définissez un serveur d’impression actif/actif, vous devez créer un groupe pour chaque nœud et définir
chaque groupe depooler avec un propriétaire préféré différent. Vous ne pouvez pas avoir plusieurs ressources
Spooler dans le même groupe. Une configuration de serveur d’impression active/active est une configuration dans
laquelle plusieurs nodes dans le cluster traitent les travaux d’impression pour les clients avec plusieurs spoolers.
Cela peut inclure jusqu’à deux à quatre nodes qui gèrent activement les demandes.
Lorsqu’un nœud unique héberge plusieurs groupes avec despoolers d’impression, vous pouvez parcourir toutes
les imprimantes de tous les groupes.
Comment créer les files d’attente d’imprimantes
Maintenant que vous avez correctement configuré la ressource Spooler avec les ressources nécessaires, vous
pouvez créer toutes les files d’attente d’impression pour toutes les imprimantes physiques. Vous pouvez
également utiliser l’utilitaire Clustool du Kit de ressources pour migrer les files d’attente d’imprimantes
existantes sur un serveur vers un serveur en cluster. Ensuite, utilisez l’utilitaire Print Migrate pour migrer les
pilotes d’imprimante. Pour de meilleurs résultats, évitez d’avoir plusieurs serveurs configurés pour
communiquer directement avec la même imprimante.
1. À partir d’un des serveurs ou d’un ordinateur distant qui dispose d’autorisations administratives pour le
cluster, cliquez sur Démarrer, cliquez sur Exécuter, tapez \ \ Vir tualSer ver où Vir tualSer ver est le
nom spécifié pour la ressource Nom du réseau dont dépend la ressource Spooler.
2. Double-cliquez sur le dossier Imprimantes.
3. Double-cliquez sur Ajouter des imprimantes pour ouvrir l’Assistant Ajouter une imprimante, puis
4. Sélectionnez Créer un por t, puis cliquez sur Suivant.
NOTE
Les ports TCP/IP sont le seul type de port pris en charge sur Windows clustering. Utilisez l’option Por t TCP/IP
standard, sauf si les clients d’impression ont besoin de ports LPR conformes À la norme RFC. Si tel est le cas,
1. Dans le Panneau de contrôle, double-cliquez sur Ajouter/Supprimer des programmes, puis cliquez sur
Ajouter/Supprimer des composants Windows pour démarrer l’Assistant Windows composants.
2. Sous Composants, faites défiler vers le bas et cliquez pour cocher Autre fichier réseau et Ser vices
d’impression.
3. Cliquez sur Détails pour ouvrir la fenêtre Autres fichiers réseau et services d’impression, cochez la case
Services d’impression pour UNIX, puis cliquez sur OK pour fermer la fenêtre Autres fichiers réseau et Services
d’impression.
4. Cliquez sur Suivant pour poursuivre avec l’Assistant Windows composants.
Lorsque vous aurez terminé l’Assistant, le port LPR sera disponible en tant que type de port. Par défaut,
conformément à la RFC 1179, LPR utilise uniquement 11 ports TCP.
5. Tapez l’adresse IP de l’imprimante réseau que vous souhaitez traiter les tâches d’impression dans la zone
Nom de l’imprimante ou Adresse IP.
NOTE
L’impression bi-directionnelle peut également être un problème lors de l’utilisation de l’impression LPR. Certains
pilotes d’imprimante activent cette option par défaut. Lorsque vous créez le port et l’imprimante LPR, désactivez
l’option d’impression bi-directionnelle. Si cette option est activée, une imprimante peut accepter un ou
plusieurs travaux d’impression, puis cesser d’accepter les travaux jusqu’à ce que l’imprimante soit réinitialisée
physiquement.
Vous n’avez plus besoin de créer une configuration de port d’imprimante définie localement pour chaque
nœud. Dans Windows 2000 (et ultérieures), la configuration de port est stockée dans le Registre de
cluster et est donc partagée entre tous les nodes de cluster, sous la clé suivante :
HKEY_Local_Machine\Cluster\Resources\%Spooler GUID%\Parameters\Monitors\
6. Choisissez le pilote approprié pour cette imprimante, puis cliquez sur Suivant .
7. Donnez à l’imprimante un nom unique sur le serveur de cluster.
8. Choisissez un nom de partage pour l’imprimante ; Ce nom doit également être unique sur ce cluster.
Vous ne souhaitez pas avoir d’autres imprimantes avec le même nom de partage sur ce cluster, même si
elles font partie d’un autre groupe et sont associées à une ressource Spooler différente. En cas de
défaillance, dans une configuration active/active, le même nœud dans le cluster peut posséder les deux
groupes depooler. Si cela se produit, les imprimantes qui partagent un nom commun ne seront pas
disponibles. Là encore, il est recommandé d’adhérer à la norme d’attribution de noms 8.3 pour des
raisons de compatibilité avec les versions antérieures.
NOTE
Le processus d’installation copie ensuite les fichiers de pilote d’imprimante dans le partage \ \
Vir tualSer ver \print$. Les pilotes d’imprimante sont copiés dans le dossier
%SystemRoot%\System32\Spool\Drivers \ Spooler GUID \Drivers du nœud dans le cluster qui possède la
ressource Nom du réseau pour ce nom virtuel. Les pilotes sont également copiés sur le disque partagé dans le
dossier \PrinterDrivers.
9. Testez l’impression de cette imprimante :

Après avoir ajouté toutes les files d’attente d’impression souhaitées, utilisez l’administrateur de cluster
pour déplacer le groupe qui contient la ressource Spooler d’impression vers tous les autres nodes. Cela
copie les pilotes d’imprimante du dossier \PrinterDrivers sur le disque partagé dans le dossier
%SystemRoot%\System32\Spool\Drivers % Spooler GUID%\Drivers sur ce nœud.
NOTE
L’impression est immédiatement disponible pour les clients lorsque la file d’attente a été créée, même si les pilotes
n’ont pas été copiés sur tous les autres nodes disponibles. Il n’est pas nécessaire de déplacer le groupe depooler
vers tous les autres nodes immédiatement après la création des files d’attente pour que le cluster fonctionne. Vous
pourrez le faire ultérieurement lorsque vous pourrez planifier une brève panne pendant laquelle vous pourrez
déconnecter la ressource Spooler.
Lorsque vous définissez un cluster d’impression, vous devez définir la taille du journal de quorum sur une taille
suffisamment grande pour respecter le nombre d’imprimantes qui seront installées. Vous devez augmenter la
taille du journal de quorum de réinitialisation lorsque vous augmentez la taille du journal de quorum. Pour
déterminer si vous devez augmenter la valeur de la taille du journal de quorum de réinitialisation, vérifiez la
taille du fichier Clusdb. Chaque nœud inclut une copie locale de ce fichier dans le dossier
%SystemRoot%\Cluster. La taille du journal de quorum de réinitialisation du journal transactionnel doit être
supérieure à la taille du fichier Clusdb pour le Registre de cluster.
Par exemple, si vous avez installé des imprimantes et que la taille du fichier Clusdb est de 6 mégaoctets (Mo),
vous devez augmenter la taille du journal de quorum de réinitialisation à 8 192 octets (8 Mo). Par défaut, la taille
du journal de quorum de réinitialisation Windows Server 2003 est de 4 Mo. Vous devez augmenter la taille du
journal de quorum de réinitialisation par incréments de 64 Ko. Une bonne règle consiste à doubler la taille
actuelle du journal de quorum de réinitialisation.
Vous ne pouvez pas mettre à niveau le système
d’exploitation d’un serveur en cluster Windows
Server 2003 ou versions ultérieures
Cet article fournit des solutions de contournement pour un problème dans lequel vous ne pouvez pas mettre à
niveau le système d’exploitation d’un serveur en cluster à partir de Windows Server 2003 ou des versions
ultérieures.
Symptômes
Lorsque vous essayez d’effectuer l’une des mises à niveau suivantes du système d’exploitation serveur, la mise à
niveau est bloquée :
Windows Server 2003 vers Windows Server 2008 ou Windows Server 2008 R2
Windows Serveur 2008 vers Windows Server 2008 R2 ou Windows Server 2012
Windows Serveur 2008 R2 vers Windows Server 2012 ou Windows Server 2012 R2
Windows Server 2012 à Windows Server 2012 R2
Lorsque ce problème se produit, le message d’erreur suivant est enregistré dans le rapport de compatibilité
système :
Vous devez apporter les modifications suivantes avant de mettre à niveau Windows
Désinstallez les composants Windows composants et fonctionnalités suivants :
Clustering de serveurs : veuillez lire l’article de la Base de connaissances Microsoft : 935197
Cause
Ce comportement se produit car le serveur est membre du cluster. Windows Server 2008, Windows Server
2008 R2, Windows Server 2012 et Windows Server 2012 R2 ne prisent pas en charge une mise à niveau de
serveurs en cluster à partir des versions précédentes. Cela est dû à des incompatibilités entre les versions de
cluster.
Pour contourner ce problème, utilisez l’une des méthodes suivantes, selon votre situation.
Méthode 1 : Nouvelle installation
1. Effectuez une nouvelle installation de Windows Server 2008 ou une version ultérieure sur les serveurs du
cluster.
2. Installez la fonctionnalité clustering de failover, créez un cluster, puis reconfigurez les paramètres du cluster.
Méthode 2 : migration sur place
Pour effectuer la migration sur place, pour plus d’informations, voir le site web Microsoft suivant :
Migration vers un cluster de Windows Server 2008 R2
Statut
Les fichiers d’aide pour Windows Server 2008 et les versions ultérieures contiennent plus d’informations sur les
chemins d’accès pris en charge par les versions précédentes des serveurs en cluster.
Mise à jour des clusters de Windows serveur
Cet article explique comment mettre à jour des clusters de Windows Server.
Résumé
Cet article explique comment installer des Service Packs ou des correctifs logiciels sur un cluster de Windows
Server. L’application d’un Service Pack ou d’un correctif logiciel à un cluster de serveurs est identique à
l’application d’un Service Pack ou d’un correctif à Windows Server. Toutefois, vous devez tenir compte de
certaines conditions particulières pour vous assurer que les clients ont un niveau d’accès élevé pendant
l’installation.
Pour installer Windows Service Packs ou correctifs logiciels sur un cluster de Windows Server, suivez ces étapes,
en fonction de la version de Windows Server que vous exécutez. Installez toujours les mêmes Service Packs ou
correctifs logiciels sur chaque nœud de cluster. Suivez ces étapes, sauf si vous êtes dirigé autrement par les
instructions pour une version de Service Pack particulière.
Windows Server 2012 - 2019
L’installation de Service Packs et de correctifs Windows Server 2012 - 2019 nécessite un processus différent.
Pour plus d’informations, voir Draining Nodes for Planned Maintenance with Windows Server.
Installer des Service Packs ou des correctifs logiciels à l’aide du Gestionnaire du cluster de Windows Server
2008 R2
L’appartenance au groupe Administrateurs local sur chaque serveur en cluster ou un équivalent est nécessaire
pour effectuer cette procédure.
1. Vérifiez la recherche d’erreurs dans le journal système et assurez-vous que le système fonctionne
correctement.
2. Assurez-vous que vous avez un disque de sauvegarde et de réparation d’urgence mis à jour pour chaque
système. S’il existe des fichiers endommagés, une panne d’alimentation ou une incompatibilité, vous de
devez peut-être revenir à l’état du système avant d’essayer d’installer les Service Packs ou les correctifs
logiciels.
3. Dans le snap-in Gestionnaire du cluster de failover, cliquez avec le bouton droit sur Nœud A, puis
cliquez sur Pause .
4. Sur le nœud A, développez Ser vices et Applications, puis cliquez sur le service ou l’application.
5. Sous Actions (sur le côté droit), cliquez sur Déplacer ce service ou cette application vers un autre
nœud, puis sélectionnez le nœud.
NOTE
À mesure que le service ou l’application se déplace, son état s’affiche dans le volet d’informations (volet central).
6. Suivez les étapes 4 et 5 pour chaque service et application configuré sur le cluster. Sur un cluster qui
possède plus de deux nœuds, à partir des options à côté de Déplacer ce service ou cette application vers
un autre nœud, vous pouvez sélectionner Meilleur possible. Cette option n’a aucun effet si aucune liste de
propriétaires privilégiés n’est configurée pour le service ou l’application que vous souhaitez déplacer.
(Dans ce cas, le nœud est sélectionné de manière aléatoire.) Si vous avez configuré une liste de
propriétaires privilégiés, la meilleure option possible déplace le service ou l’application vers le premier
nœud disponible de la liste.
7. Installez les Service Packs ou les correctifs logiciels sur le nœud A, puis redémarrez l’ordinateur.
8. Recherchez des erreurs dans le journal système. Si vous trouvez des erreurs, dépannagez-les avant de
poursuivre ce processus.
9. Dans le snap-in Gestionnaire du cluster de failover, cliquez avec le bouton droit sur Nœud A, puis cliquez
sur Reprendre .
10. Dans le snap-in Gestionnaire du cluster de failover, cliquez avec le bouton droit sur Nœud B, puis
cliquez sur Pause .
11. Sous Actions (sur le côté droit), cliquez sur Déplacer ce service ou cette application vers un autre
nœud, puis sélectionnez le nœud.
NOTE
À mesure que le service ou l’application se déplace, son état s’affiche dans le volet d’informations (volet central).
12. Suivez les étapes 10 et 11 pour chaque service et application configuré sur le cluster.
13. Installez les Service Packs ou les correctifs logiciels sur le nœud B, puis redémarrez l’ordinateur.
15. Dans le Gestionnaire du cluster de failover, cliquez avec le bouton droit sur Nœud B, puis cliquez sur
Reprendre .
16. Cliquez avec le bouton droit sur chaque groupe, cliquez sur Déplacer le groupe, puis déplacez les
groupes vers leur propriétaire préféré. Pour plus d’informations, voir Tester le failover d’un service ou
d’une application en cluster et suspendre ou reprendre un nœud dans un cluster de failover.
Installer des Service Packs ou des correctifs logiciels à l’Windows PowerShell cmdlets Windows Server 2008
R2
L’appartenance au groupe Administrateurs local sur chaque serveur en cluster ou un équivalent est nécessaire
pour effectuer cette procédure.
1. Vérifiez la recherche d’erreurs dans le journal système et assurez-vous que le système fonctionne
correctement.
2. Assurez-vous que vous avez un disque de sauvegarde et de réparation d’urgence mis à jour pour chaque
système. S’il existe des fichiers endommagés, une panne d’alimentation ou une incompatibilité, vous de
devez peut-être revenir à l’état du système avant d’essayer d’installer les Service Packs ou les correctifs
logiciels.
3. Dans Windows Server 2008 R2, utilisez le lien Modules Windows PowerShell sous Outils
d’administration pour importer automatiquement tous les modules Windows PowerShell pour les
fonctionnalités ou les rôles que vous avez installés.
4. Utilisez le raccourci des outils d’administration pour démarrer la gestion PowerShell du cluster de failover.
Sinon, démarrez Windows PowerShell sur votre ordinateur en cliquant avec le bouton droit, puis en
sélectionnant Exécuter en tant qu’administrateur.
5. Chargez le module clusters de failover en exécutant la commande suivante
Import-Module FailoverClusters :
6. Suspendre (suspendre) l’activité sur le nœud de cluster de failover A en exécutant la commande suivante
Suspend-ClusterNode nodeA :
7. Déplacez un service ou une application en cluster (un groupe de ressources) d’un nœud vers un autre en
exécutant la commande suivante Move-ClusterGroup \<clustered service> -Node nodeB :
TIP
Vous pouvez également utiliser la commande suivante pour déplacer tous les groupes du nœud vers le
propriétaire préféré du meilleur nœud possible :
Get-ClusterNode NodeA | Get-ClusterGroup | Move-Cluster Group .
8. Installez le Service Pack sur le nœud A, puis redémarrez l’ordinateur.

10. Reprendre l’activité sur le nœud A qui a été suspendu à l’étape 5 en exécutant la commande suivante
Resume-ClusterNode nodeA :
11. Suspend (Suspendre) l’activité sur un autre nœud de cluster de failover en exécutant la commande
suivante : Suspend-ClusterNode nodeB .
12. Déplacez un service ou une application en cluster (un groupe de ressources) d’un nœud vers un autre en
exécutant la commande suivante Move-ClusterGroup <clustered service> -Node nodeB :
NOTE
Vous pouvez de nouveau utiliser la commande suivante pour déplacer tous les groupes du nœud vers le
propriétaire préféré du meilleur nœud possible :
Get-ClusterNode NodeB | Get-ClusterGroup | Move-Cluster Group .
13. Installez le Service Pack sur le nœud B, puis redémarrez l’ordinateur.

15. Reprendre l’activité sur le nœud B qui a été suspendu à l’étape 10 en exécutant la commande suivante
Resume-ClusterNode nodeB :
16. Déplacez le service ou l’application en cluster (un groupe de ressources) vers son propriétaire préféré en
exécutant la commande suivante Move-ClusterGroup <CusteredService> -Node <NodeName> :
Pour plus d’informations, voir les sites web Microsoft suivants :

Cmdlets de cluster de Windows PowerShell
Vue d’ensemble des commandes du Gestionnaire de serveur
Correctifs et mises à jour recommandés pour
Windows serveurs basés sur Server 2008 R2
Cet article décrit les correctifs logiciels et les mises à jour que nous vous recommandons d’installer sur chaque
nœud d’un cluster de Windows Server 2008 R2.
Résumé
Lorsque vous mettez à jour votre cluster de Windows Server 2008 R2, vous réduisez les temps d’arrêt. Vous
contribuez également à réduire le nombre d’erreurs, les travaux d’impression qui ont échoué et d’autres
problèmes de support que vous découvrez.
NOTE
Nous vous recommandons d’évaluer ces correctifs et mises à jour pour déterminer s’ils peuvent résoudre des problèmes
dans votre environnement. Si vous déterminez que les nœuds de cluster se trouve dans votre environnement peuvent
être affectés par les problèmes qu’une mise à jour ou un correctif logiciel résout, installez le correctif logiciel ou la mise à
jour sur chaque nœud de cluster qui se trouve dans votre environnement.
Utilisez les informations de la section Plus d’informations pour déterminer si un correctif logiciel ou une mise à
jour particulier s’applique au cluster de serveurs. Avant d’installer un correctif logiciel ou une mise à jour
spécifique, nous vous recommandons de consulter l’article de la Base de connaissances Microsoft d’origine qui
décrit ce correctif ou cette mise à jour.
Nous vous recommandons d’installer Windows Server 2008 R2 Service Pack 1 (SP1), car il présente de
nombreux correctifs pour les problèmes liés Windows clustering. Nous vous recommandons également
d’installer les correctifs logiciels référencés dans les correctifs logiciels recommandés et les mises à jour pour les
clusters de Windows Server 2008 R2 SP1. Si, pour une raison quelconque, vous ne pouvez pas appliquer
immédiatement SP1, nous vous recommandons d’installer les correctifs Windows Server 2008 R2 suivants, en
fonction de votre environnement.
Correctifs généraux
Nous vous recommandons d’installer les correctifs suivants si vous envisagez d’installer la fonctionnalité de
clustering de Windows Server 2008 R2 Core :

samedi 3 août 2013 2685891 Cap n’est pas Clusres.dll Empêche la panne de
disponible en ligne cluster en cas d’échec
dans un cluster de de la mise en ligne de
Windows Server LAT. Disponible pour
2008 R2 ou Windows téléchargement
Server 2008 individuel.
25 avril 2012 2559392 Le test Processus en Plusieurs fichiers de Empêche l’échec de

cours d’exécution de .dll validation validation de cluster.
liste échoue lorsque La validation de
vous exécutez passage est
l’Assistant Validation nécessaire pour avoir
du cluster de failover une configuration de
sur un nœud de cluster prise en
cluster Windows 7 ou charge. Disponible
Windows Server pour téléchargement
2008 R2 individuel.
16 mars 2012 2639032 0x0000003B, Clusauthmgr.dll Empêche une erreur

0x00000027 et d’arrêt. Disponible
0x0000007e les Csvfilter.sys pour téléchargement
erreurs d’arrêt en cas individuel.
de perte d’une
connexion à un CSV.
22 novembre 2012 2687646 Un LUN inscrit dans clussvc.exe Empêche un LUN de

un volume partagé ne pas être détecté
de cluster est cluswmi.dll par le système
invisible et d’exploitation.
inaccessible Disponible pour
téléchargement
individuel.
17 janvier 2012 2524478 Le profil Ncsi.dll Empêche toute perte

d’emplacement potentielle de
réseau change de Nlaapi.dll communication de
Domaine en Public cluster. Disponible
dans Nlasvc.dll pour téléchargement
Windows 7 ou dans individuel.
Windows Server
2008 R2
14 mai 2011 2545850 Les utilisateurs ne DLL Empêche les objets

peuvent pas accéder d’authentification CNO et VCO de ne
à un site web multiple pas s’inscrire dans
hébergé par IIS une DNS en raison du
fois que le mot de non-fonctionnement
passe de l’ordinateur de l’authentification
du serveur a été Kerberos après la
modifié dans changement du mot
Windows 7 ou de passe de
Windows Server l’ordinateur.
2008 R2
24 mars 2010 978309 Les technologies de Tunnel.sys Corrige les

transition IPv6, telles composants exploités
que ISATAP, 6to4 et par le cluster deover
Teredo, ne sur les installations
fonctionnent pas sur 2008 R2 Server Core.
un ordinateur Disponible pour
exécutant Windows téléchargement
Server 2008 R2 individuel.
Server Core
4 septembre 2010 976571 Mise à jour de Win32spl.dll Corrige la stabilité du

stabilité Windows cluster d’impression.
clusters d’impression S’applique
de failover Server uniquement si les
2008 R2 ressources de cluster
d’impression sont
configurées.
Disponible pour
téléchargement
individuel.
Pour éviter les problèmes qui affectent l’opération de cluster lorsque le réseau n’est pas fiable, installez le
correctif logiciel suivant :
2552040 cluster de Windows Server 2008 R2 perd le quorum en cas de défaillance d’une communication
asymétrique
Pour éviter les problèmes de performances sur le cluster et les incidents système possibles, installez le correctif
logiciel suivant :
2520235 0x0000009E’arrêt lorsque vous ajoutez un disque de stockage supplémentaire à un cluster de
Correctifs spécifiques aux ressources
Nous vous recommandons d’installer les correctifs suivants, en fonction des ressources en cours d’exécution sur
le cluster de serveurs. Vous n’avez pas besoin d’installer ces correctifs si vous n’exécutez pas ces ressources sur
le cluster de serveurs.
976571 de stabilité de Windows Server 2008 R2
Conseils de résolution des problèmes de
basculement de cluster inattendus
Un cluster ne déclenche pas de basculement, sauf s’il existe un problème réel avec l’un des composants du
cluster (logiciel ou matériel). Il effectue une étape de récupération de base et la ressource affectée bascule vers
un autre nœud en raison des causes possibles suivantes :
Défaillance de la ressource
Problème de mise en réseau, tel que l’éviction de nœud
Échec du disque CSV (Cluster Shared Volume)

1. Identifiez l’horodatage d’occurrence dans le journal des événements système. Ensuite, recherchez des
événements sur la source Microsoft-Windows-FailoverClustering et recherchez l’ID d’événement 1069,
1146 ou 1230.
2. Faites correspondre le fuseau horaire du journal des événements système au fuseau horaire GMT dans le
journal du cluster.
NOTE
Pour trouver rapidement la différence de fuseau horaire, recherchez The current time is .
3. Accédez à l’horodatage d’occurrence dans le journal du cluster et identifiez la ligne correspondante. Vous
pouvez rencontrer une erreur telle que :
Resource <name> IsAlive has indicated failure
IsAlive sanity check failed
NOTE
L’erreur peut être différente en fonction du problème.
4. Faites défiler le journal du cluster et essayez d’identifier s’il existe une autre erreur susceptible d’en être la
cause réelle.
5. Faites défiler le journal du cluster et recherchez Group move ou Move of group recherchez la ressource
affectée. Notez l’horodatage exact et le nœud de destination.
6. Basculez vers le journal de cluster du nœud de destination et vérifiez le comportement de la ressource
lorsqu’elle est en ligne. Si la ressource parvient à être mise en ligne, vous trouverez le journal suivant :
Resource <name> has come online
Group move for <name> has completed
Sinon, vous trouverez le journal suivant :

Online for resource <name> failed
Sous-système d’hébergement de ressources (RHS) dans Windows clusters de basculement de serveur
Comportement de basculement sur des clusters de trois nœuds ou plus
Comportement deover sur les clusters de trois ou
plusieurs nodes
Cet article documente la logique selon laquelle les groupes échouent d’un nœud à un autre lorsqu’il y a au
moins trois membres de nœud de cluster.
Résumé
Le déplacement d’un groupe peut être provoqué par un administrateur qui déplace manuellement un groupe ou
par une défaillance de nœud ou de ressource. L’endroit où le groupe se déplace dépend de la façon dont le
déplacement est initié et de la façon dont la liste des propriétaires préférés est définie.
Les informations sur la liste des propriétaires préférés sont couvertes dans le fichier d’aide sous « Clusters de
serveurs », y compris les informations sur la planification et l’optimisation des clusters de serveurs. Cet article
décrit les quatre scénarios possibles suivants :
1. Un nœud ou une ressource a échoué et la liste des propriétaires par défaut est définie.
2. Un nœud ou une ressource a échoué et la liste des propriétaires préférés n’est pas définie.
3. L’administrateur déplace manuellement le groupe vers « Best Possible » et la liste des propriétaires préférés
est définie.
4. L’administrateur déplace manuellement le groupe vers « Best Possible » et la liste des propriétaires préférés
n’est pas définie.
Scénario 1
Si un nœud ou une ressource échoue et que la liste des propriétaires préférés a été définie, le service de cluster
échoue au groupe au nœud disponible suivant dans la liste des nœuds. La liste des nœuds se compose de la
liste des propriétaires préférés suivie des nœuds restants organisés par leur ID de nœud. L’ID de nœud est
défini lorsqu’un nœud est joint à un cluster ou si un nœud est délogé ou ajouté à nouveau.
Vous pouvez afficher l’ordre d’ID de nœud en examinant le Registre sous la clé
\HKEY_LOCAL_MACHINE\Cluster\Nodes.
Par exemple, supposons que nous avons un cluster de six nœuds et que les nœuds ont été installés et joints au
cluster dans l’ordre suivant : NodeA, NodeB, NodeC, NodeD, NodeE et NodeF. Supposons qu’un groupe possède
NodeA, NodeC et NodeE répertoriés comme propriétaires préférés.
Avec ces informations, la liste des nœuds pour le groupe serait alors la suivante :
1. NodeA - Propriétaire préféré numéro 1
2. NodeC - Propriétaire privilégié numéro 2
3. Nœud - Propriétaire privilégié numéro 3
4. NodeB - Deuxième nœud installé
5. Nœud - Quatrième nœud installé
6. NodeF - Sixième nœud installé
Dans ce scénario, si un échec de nœud ou un échec d’une ressource devait se produire et que son seuil de
redémarrage était atteint, le groupe entier échouerait au nœud suivant vers le bas dans la liste des nœuds. Par
exemple, si NodeC contenait la ressource qui a échoué, le groupe entier échouerait sur NodeE. NodeA
n’échouerait pas même s’il est répertorié en premier dans la liste des propriétaires préférés. En cas d’échec de
NodeE, le groupe se place sur NodeB et non sur NodeA.
Scénario 2A
Si une ressource échoue et que la liste des propriétaires préférés n’est pas définie, le groupe suit une liste de
nœuds de la même manière que dans le scénario 1. La liste des nœuds est construite uniquement à partir de
l’ID de nœud. En cas de défaillance d’un nœud ou d’une ressource, les ressources suivent un chemin vers le bas
qui échoue au nœud suivant dans la liste des nœuds. Lorsqu’elle atteint le dernier nœud répertorié dans la liste
des nœuds, elle commence par le premier nœud de la liste des nœuds.
1. NodeA - Premier nœud installé
2. NodeC - Deuxième nœud installé
3. Nœud - Troisième nœud installé
4. NodeB - Quatrième nœud installé
5. Nœud - Cinquième nœud installé
Par exemple, cette liste a l’ordre d’installation des différents nodes de cluster. En cas d’échec de NodeE, tous les
groupes qu’il possédait seraient retentés sur NodeB et non sur NodeF.
Scénario 2B
Si un nœud échoue et que la liste des propriétaires préférés n’est pas définie pour un groupe sur ce nœud, un
nœud disponible est sélectionné de manière aléatoire pour le groupe vers qui déplacer. Cela répartit les groupes
entre les nodes disponibles.
Scénario 3
Si un administrateur de cluster choisit manuellement Move group et sélectionne Best Possible et que la liste
des propriétaires préférés est configurée, le groupe démarre toujours en haut de la liste des nœuds. Comme
dans le scénario 1, la liste des nœuds est composée de la liste des propriétaires préférés et de l’ordre
d’installation.
1. NodeA - Propriétaire préféré numéro 1
2. NodeC - Propriétaire privilégié numéro 2
3. Nœud - Propriétaire privilégié numéro 3
4. NodeB - Deuxième nœud installé
5. Nœud - Quatrième nœud installé
Dans cet exemple, lorsque Best Possible est sélectionné, le groupe tente toujours de passer à NodeA. Si le
groupe est déjà sur NodeA ou nodeA n’est pas disponible, le groupe tente de passer à NodeC. Si un groupe se
trouve sur NodeD et que l’administrateur choisit de le déplacer vers Le meilleur possible, le groupe passe à
NodeA. Si NodeA, NodeC ou NodeE ne sont pas actifs, NodeB ou NodeF est choisi de manière aléatoire.
Scénario 4
Si, en tant qu’administrateur de cluster, vous choisissez manuellement Move group et que vous sélectionnez
Best Possible et que la liste des propriétaires préférés n’est pas configurée, un nœud actif est choisi de manière
aléatoire pour héberger le groupe. Si la liste des propriétaires préférés n’est pas configurée, il est possible qu’un
groupe passe à un nœud qui exécute déjà plusieurs autres groupes.
Nous vous recommandons de configurer la liste des propriétaires préférés sur un cluster de nœuds de grande
taille si la charge entre les nœuds est sensiblement différente ou si les nœuds ne sont pas homogènes.
NOTE
L’exception au comportement de changement de nom mentionné ici concerne le groupe par défaut qui contient la
ressource Quorum nommée Groupe de clusters. Le groupe de clusters ne suit pas le comportement classique de la liste
des propriétaires préférés. Au lieu de cela, en cas d’échec du propriétaire de la ressource Quorum, le nouveau propriétaire
sera le groupe précédent propriétaire de la ressource Quorum.
La propriété publique AntiAffinityClassNames peut également avoir une incidence sur l’endroit vers lequel un
groupe va échouer.
Exécuter la commande chkdsk /f sur un disque de
cluster partagé
Cet article explique comment exécuter la commande chkdsk /f sur un disque de cluster partagé.
Résumé
Lorsque vous essayez d’exécuter la ou la commande sur un lecteur de cluster partagé, il se peut que chkdsk /f
Chkdsk ne s’exécute pas et que le lecteur ne puisse pas être verrouillé pour chkdsk /f /r une utilisation
exclusive. Si vous programmez l’opération Chkdsk après le redémarrage de l’ordinateur, Chkdsk peut générer le
message d’erreur suivant pendant le processus de démarrage :
Impossible de déterminer le système de fichiers sur la ? lettre de lecteur ?\ .
Dans la plupart des cas, l’exécution de Chkdsk avec le commutateur ou le commutateur nécessite le
redémarrage de l’ordinateur en raison des /F /R poignées ouvertes sur le disque partagé. En règle générale,
aucun service ou pilote n’est en cours d’exécution qui empêche le autochk (une dérivée de Chkdsk) de vérifier le
disque au redémarrage de l’ordinateur. Toutefois, si vous utilisez le clustering Windows, le système de fichiers ne
monte pas le disque partagé tant que le service de cluster ne démarre pas, car le propriétaire du disque partagé
est inconnu. Chkdsk signale alors qu’il ne peut pas déterminer le système de fichiers sur un disque de cluster
partagé. L’exécution de Chkdsk en mode Read-Only semble fonctionner, mais Chkdsk ne corrige aucun
problème.
Si vous pensez qu’il y a un fichier défectueux sur le disque partagé, utilisez les étapes suivantes pour fermer
toutes les poignées ouvertes sur le disque partagé et exécuter Chkdsk sur le lecteur :
1. Quittez tous les programmes et arrêtez tous les services non pris en compte dans le cluster.
2. Démarrez l’outil Administrateur de cluster, cliquez avec le bouton droit sur le nom du cluster, puis cliquez
sur Propriétés.
3. Sous l’onglet Quorum, notez quel disque dur est le disque dur de quorum. Si le disque dur sur lequel
vous souhaitez exécuter Chkdsk contient le journal de quorum, déplacez temporairement le quorum vers
un autre disque partagé.
4. Utilisez l’outil Administrateur de cluster pour rechercher le groupe qui contient le disque dur partagé sur
lequel vous souhaitez exécuter Chkdsk.
5. Une fois que vous avez trouvé la ressource de disque physique sur laquelle vous souhaitez exécuter
Chkdsk, déconnectez l’ensemble du groupe, y compris le disque partagé. Cette approche ferme toutes les
poignées sur le disque physique. Pour mettre le groupe hors connexion, cliquez avec le bouton droit sur
le nom du groupe, puis cliquez sur Hors ligne.
6. Dans l’outil Administrateur de cluster, cliquez sur le disque partagé sur lequel vous souhaitez exécuter
Chkdsk, puis apportez-le en ligne. Pour ce faire, cliquez avec le bouton droit sur la ressource disque, puis
cliquez sur Mettre en ligne.
NOTE
Si le bit défectueux a été précédemment définie, Chkdsk peut s’exécuter automatiquement et la ressource disque
physique peut prendre un certain temps pour être mise en ligne. Dans Windows NT 4.0, une fenêtre d’invite de
commandes avec Chkdsk s’exécute. Dans Windows 2000, si vous ouvrez le Gestionnaire des tâches, Chkdsk
s’exécute en tant que processus.
7. À l’invite de commandes, modifiez un lecteur autre que le lecteur sur lequel vous tentez d’exécuter
Chkdsk, puis tapez la commande, où X est le disque chkdsk **x**: /f /r partagé.
Si vous recevez un message d’erreur disque ne peut pas être verrouillé lorsque vous essayez d’exécuter Chkdsk,
vérifiez que tous les services et outils qui ont accès au lecteur sont arrêtés, puis essayez à nouveau d’exécuter
Chkdsk. Tout service ou programme en cours d’exécution qui dispose d’un handle ouvert sur le lecteur peut
empêcher l’exécution de Chkdsk. Windows 2000 et versions ultérieures de Windows pouvez tenter de fermer
des handles ouverts sur le disque partagé. Si vous êtes invité à fermer les poignées ouvertes, appuyez sur la
touche Y.
Si les handles restent ouverts ou si le cluster contient un disque partagé unique
Si des programmes ou des pilotes conservent une poignée ouverte sur le disque partagé, ou s’il n’existe qu’un
seul disque partagé (sur lequel le journal de quorum est stocké), vous devez descendre tout le cluster. Pour ce
faire, vous devez désactiver temporairement les composants de clustering afin que le système de fichiers puisse
monter le disque partagé lorsque vous redémarrez le nœud. Vous devez également arrêter les autres nœuds du
cluster afin qu’ils ne prennent pas possession du disque partagé au redémarrage du nœud.
Pour ce faire, utilisez les étapes de la section appropriée.
Windows Server 2003
Vous devez placer la ressource de disque physique en mode maintenance avant d’exécuter une commande «
chkdsk /F » sur un volume sur un ordinateur microsoft Windows Server 2003. Vous devez le faire pour
empêcher la ressource de disque physique de passer à un état d’échec.
Windows 2000
1. Quittez tous les programmes, arrêtez tous les programmes qui ne sont pas pris en charge par le cluster, puis
connectez-vous au serveur avec un compte qui dispose d’informations d’identification administratives.
2. Démarrez Administrateur de cluster, cliquez avec le bouton droit sur nom du cluster, puis cliquez sur
Propriétés.
3. Cliquez sur l’onglet Quorum, puis notez quel lecteur est le disque de quorum. Si le lecteur sur lequel vous
souhaitez exécuter Chkdsk contient le journal de quorum, déplacez temporairement le disque de quorum
vers un autre lecteur partagé.
4. Copiez FSUtil.exe du dossier sur un ordinateur basé sur XP ou version ultérieure Windows sur le lecteur local
sur l’ordinateur %SystemRoot%\System32 Windows 2000.
5. Sur l’ordinateur Windows 2000, à l’invite de commandes, modifiez le dossier qui contient FSUtil.exe, puis
tapez la commande, où le lecteur est le lecteur fsutil dirty set drive: partagé.
6. Utilisez l’administrateur de cluster pour rechercher le groupe qui contient le lecteur partagé sur lequel vous
souhaitez exécuter Chkdsk.
7. Cliquez avec le bouton droit sur le nom du groupe, puis cliquez sur Hors connexion. Cela met l’ensemble
du groupe hors connexion, y compris le lecteur partagé, et ferme toutes les poignées sur le lecteur physique.
8. Cliquez avec le bouton droit sur la ressource Disque physique, puis cliquez sur Mettre en ligne. Le lecteur
est ainsi en ligne. Chkdsk s’exécute sur le volume et peut être en attente en ligne pendant un certain temps.
9. Une fois Chkdsk s’exécute sur le volume, apportez toutes les autres ressources du groupe en ligne.
Windows NT 4.0
1. Désactiver le nœud B.
2. Connectez-vous au nœud A en tant qu’administrateur.
3. Exécutez chkdsk /f la commande sur le disque partagé. Lorsque vous êtes invité à planifier chkdsk pour
l’exécuter au prochain redémarrage de l’ordinateur, appuyez sur Y.
4. Dans l’outil Périphériques du Panneau de contrôle, cliquez sur Disque de cluster, puis sur Démarrage.
5. Modifiez le type de démarrage sur Désactivé.
6. Dans l’outil Services du Panneau de contrôle, cliquez sur le service serveur de cluster, puis sur Démarrage.
7. Modifiez le type de démarrage sur Désactivé.
8. Quittez le Panneau de contrôle, puis redémarrez le nœud A. Chkdsk s’exécute sans interférences du pilote de
disque de cluster ou de tout autre service.
9. Une fois Chkdsk terminé, modifiez le type de démarrage à son paramètre d’origine, puis redémarrez
l’ordinateur pour activer le cluster.
10. Activer le nœud B.
Correctifs et mises à jour recommandés pour les
clusters de basculement Windows Server 2012 R2
Cet article décrit les correctifs logiciels actuellement disponibles pour les clusters de Windows Server 2012 R2
et il est vivement recommandé d’installer ces derniers sur chaque serveur d’un cluster deover.
Résumé
La gestion du cluster de failover permet à plusieurs serveurs de fournir une haute disponibilité des rôles
serveur. La gestion du cluster de failover est souvent utilisée pour les services de fichiers, les machines
virtuelles, les applications de base de données et les applications de messagerie.
IMPORTANT
Le processus d’installation des Service Packs et des correctifs logiciels pour Windows Server 2012 R2 diffère du processus
des versions antérieures de Windows Server. Dans Windows Server 2012 R2, vous pouvez utiliser la fonctionnalité de mise
à jour Cluster-Aware (CAU). CAU automatise le processus de mise à jour logicielle sur les serveurs en cluster et maintient
la disponibilité. Pour plus d’informations, voir Cluster-Aware Updating Overview.
Les articles suivants de la Base de connaissances Microsoft décrivent les correctifs actuellement disponibles qui
sont vivement recommandés pour être installés sur tous les clusters deover. La plupart des mises à jour
s’appliquent aux ordinateurs qui exécutent Windows Server 2012 R2. Certaines mises à jour, telles que les
976424 de la Ko, peuvent être requises sur les ordinateurs exécutant Windows Server 2008 R2 ou Windows
Server 2008 si ces systèmes d’exploitation sont présents dans l’environnement.
Ces mises à jour sont considérées comme des installations importantes pour garantir le niveau de fiabilité le
plus élevé.
Tout cluster Windows Server 2012 R2

NOTE
Vous pouvez remplacer un nouveau nombre de rapports mensuels à la place de la base de 4282815. Le reste des mises à
jour de cette liste est toujours nécessaire, car certains composants de ces mises à jour publiées avant septembre 2016 ne
sont pas inclus dans le nouveau déploiement mensuel.
DAT E À L A Q UEL L E L A A RT IC L E DE L A B A SE P O URQ UO I N O US

M ISE À JO UR A ÉT É DE C O N N A ISSA N C ES REC O M M A N DO N S
A JO UT ÉE A SSO C IÉE T IT L E C O M P O SA N T C ET T E M ISE À JO UR
14 juin 2018 4284815 12 juin 2018- Multiple Ce correctif de mise à

KB4284815 jour de sécurité inclut
(déploiement des améliorations et
mensuel) des correctifs qui ont
été publiés après
septembre 2016.
Windows update ou
individuel à partir du
catalogue Microsoft
Update et du Centre
de téléchargement
Microsoft. Pour
appliquer cette mise
à jour, vous devez
d’abord installer la
mise à jour 2919355
sur Windows Server
2012 R2.
21 juin 2017 3137728 Échec de la Vssvc Inclut le correctif de

restauration VSS 3123538. Disponible
lorsque vous utilisez à partir Windows
l’API VSS ResyncLuns update ou pour
dans Windows Server téléchargement
2012 cluster deover individuel à partir du
basé sur R2 catalogue Microsoft
Update et du Centre
de téléchargement
Microsoft. Pour
à jour, vous devez
sur Windows Server
2012 R2.
22 août 2016 3179574 Mise à jour d’août Multiple Ce correctif inclut un

2016 pour Windows correctif qui résout
RT 8.1, Windows 8.1 un problème avec les
et Windows Server services de cluster
2012 R2 qui peuvent cesser
de fonctionner
lorsque la
journalisation des
pertes réseau se
produit lorsqu’une
connexion réseau est
en panne et que les
ordinateurs virtuels
sont configurés avec
un propriétaire
possible. Disponible à
partir Windows
update ou pour
téléchargement
catalogue Microsoft
Update. Pour
à jour, vous devez
sur Windows Server
2012 R2.
21 juillet 2016 3172614 Rollup de mise à jour Multiple Ce correctif

de juillet 2016 pour comprend des
Windows RT 8.1, améliorations et des
Windows 8.1 et correctifs de la
Windows Server 3161606 de la base
2012 R2 de données de mise
à jour de juin 2016 et
de la 3156418 de la
base de données de
correctifs de mise à
jour de mai 2016, y
compris une mise à
jour (3153887) qui
augmente les valeurs
par défaut de
SameSubnetThres
hold ,
CrossSubnetThreshol
d et
RouteHistoryLength
afin d’améliorer la
tolérance des brefs
problèmes de réseau
temporaires.
Disponible sur
Windows mise à jour
ou en
téléchargement
catalogue Microsoft
Update. Pour
à jour, vous devez
sur Windows Server
2012 R2.
28 octobre 2015 3091057 Échec de la validation Égepsrv Modifie le minutage

du cluster dans le du test De validation
test Valider le test de simultanée de la
resserrement synchronisation pour
simultané dans un vérifier plus
cluster de Windows précisément la
Server 2012 R2 compatibilité du
stockage avec le
cluster deover.
Disponible pour
téléchargement
individuel.
18 décembre 2014 3013769 Rollup de mise à jour Multiple Un package de mise

de décembre 2014 à jour qui résout les
pour Windows RT problèmes et inclut
8.1, Windows 8.1 et des améliorations en
Windows Server matière de
2012 R2 performances et de
fiabilité. Disponible à
partir Windows mise
à jour et pour
téléchargement
Centre de
téléchargement. Pour
à jour, vous devez
sur Windows Server
2012 R2.
18 novembre 2014 3000850 Rollup de mise à jour Multiple Mise à jour

de novembre 2014 cumulative qui inclut
pour Windows RT les mises à jour de
8.1, Windows 8.1 et sécurité et les mises à
Windows Server jour non en matière
2012 R2 de sécurité, y compris
les mises à jour du
clustering de failover
publiées entre avril
2014 et novembre
2014. Disponible à
partir Windows mise
à jour et pour
téléchargement
Centre de
téléchargement. Pour
à jour, vous devez
sur Windows Server
2012 R2.
mardi 8 avril 2014 2919355 Windows RT 8.1, Multiple Une mise à jour
Windows 8.1 et cumulative qui inclut
Windows Server les mises à jour de
2012 R2 d’avril 2014 sécurité et les mises à
jour non en matière
de sécurité, y compris
les mises à jour de
clustering de failover
publiées avant mars
2014. Disponible à
partir Windows mise
à jour et pour
téléchargement
Centre de
téléchargement.
18 décembre 2013 976424 Code d’erreur lorsque KDCSVC Permet d’ajouter un

le protocole kpasswd cluster de Windows
échoue après avoir Server 2012 de
effectué une travail. Installez sur
restauration faisant chaque contrôleur de
autorité : « domaine exécutant
KDC_ERROR_S_PRIN Windows Server
CIPAL_UNKNOWN » 2008 Service Pack 2
(SP2) ou Windows
Server 2008 R2.
Dans le cas contraire,
la création d’un
cluster peut échouer
lorsque vous essayez
de définir le mot de
passe de l’objet
ordinateur de cluster
et que vous recevez
un objet
CreateClusterNam
eCOIfNotExists
(6783)
<ClusterName$> :
impossible de définir
le mot de passe sur
le message d’erreur.
Ce correctif est inclus
dans Windows Server
2008 R2 Service Pack
1 (SP1).
Windows Server 2012 clusters Hyper-V R2

Outre les mises à jour répertoriées ci-dessus, les articles suivants de la Base de connaissances Microsoft
décrivent les correctifs actuellement disponibles qui sont vivement recommandés pour être installés sur des
clusters deover Hyper-V. Ces mises à jour ciblent des améliorations de fiabilité lors de la backing up virtual
machines on Hyper-V failover clusters.
21 juin 2017 3145384 La limite de valeur de Volsnap.sys Décrit une mise à

Registre jour qui augmente la
MinDiffAreaFileSize limite de valeur de clé
est augmentée de 3 de Registre
Go à 50 Go dans MinDiffAreaFileSize
Windows 8.1 ou de 3 Go à 50 Go
Windows Server dans Windows 8.1 et
2012 R2 Windows Server
2012 R2. Avant
d’installer cette mise
à jour, consultez la
section « Conditions
préalables ». Inclut le
correctif de 3060678.
Windows update ou
catalogue Microsoft
Update. Pour
à jour, vous devez
sur Windows Server
2012 R2.
15 septembre 2015 3063283 Mise à jour pour Services d’intégration Augmente le délai
améliorer la Hyper-V d’accès pour détecter
sauvegarde des les volumes à copier
composants intégrés de l’ombre lorsque le
Hyper-V dans Hyper- système
V Server 2012 R2 d’exploitation invité a
plusieurs volumes.
Disponible pour
téléchargement
individuel. Pour
à jour, vous devez
sur Windows Server
2012 R2.
References
Pour plus d’informations sur les correctifs et les mises à jour recommandés pour les serveurs Hyper-V Windows
Server 2012 et les clusters de Windows Server 2012 basé sur un Windows Server 2012, voir :
Hyper-V : Liste des mises à jour pour Windows Server 2012
2784261
Ajout de la prise en charge de plus de huit réseaux
luns dans Windows Server
Cet article décrit la prise en charge d’un grand nombre de numéros d’unité logique dans les produits Windows
Server.
IMPORTANT

Résumé
Cet article décrit la prise en charge d’un grand nombre de numéros d’unité logique dans les produits Windows
Server. Lorsque vous configurez un serveur avec plus de huit SLAN, le fournisseur de matériel doit être impliqué
dans la planification et la configuration. Il peut y avoir plusieurs façons d’obtenir la configuration que vous
souhaitez ; Le fournisseur de matériel est le mieux équipé pour fournir les informations nécessaires. Cet article
n’est pas destiné à être tout inclus en raison des différentes implémentations qu’un fournisseur de matériel peut
utiliser. Contactez votre fabricant de matériel pour déterminer si et comment votre matériel peut prendre en
charge plus de huit réseaux d’accès au réseau.
Windows Server 2008 et Windows Server 2008 R2 peuvent prendre en charge jusqu’à :
Huit bus par carte
128 ID cibles par bus
255 luns par ID cible
Windows Server 2012 versions ultérieures de Windows prise en charge jusqu’à :
255 bus par adaptateur
128 ID cibles par bus
255 luns par ID cible
WARNING
Terminologie utilisée dans cet article

Adaptateur de bus hôte (HBA) : il s’agit du contrôleur connecté au périphérique de stockage. Il peut s’agit
d’un contrôleur SCSI ou Fibre, car les deux topologies peuvent prendre en charge plus de huit LO.
Stockage : il s’agit du contrôleur dans le tableau auquel le HBA s’attache. Il s’agit de l’appareil qui contrôle les
lecteurs.
Grande LUN : il s’agit d’un terme couramment utilisé pour la pratique de prise en charge de plus de huit
noms lun.
Windows Le serveur prend en charge les grandes luns, mais la méthode pour l’activer dépend de
l’implémentation matérielle et des pilotes. Si le périphérique de stockage signale le bit HiSupport dans ses
données standard d’interrogation, Windows active automatiquement les grandes luns sans nécessiter d’entrées
de Registre manuelles. Contactez le fournisseur de matériel pour déterminer si le périphérique de stockage
signale le bit HiSupport. Les pilotes matériels peuvent également activer la prise en charge d’un numéro
d’utilisateur principal important au cours de leurs routines d’installation.
Si le matériel ne signale pas le bit HiSupport ou si les pilotes n’activent pas la prise en charge des noms lun de
grande taille, une entrée de Registre manuelle est requise. Cette fonctionnalité fonctionne uniquement si les
périphériques de stockage prise en charge la commande SCSI REPORT LUNS. Notez que la modification du
Registre pour activer les grandes luns nécessite une connaissance détaillée des ID matériels et des entrées de
Registre des appareils . Il s’agit de la méthode la moins privilégiée. Pour plus d’informations, contactez le
fournisseur de matériel. Pour configurer l’entrée de Registre requise, suivez les étapes suivantes :
1. Recherchez l’ID matériel de l’appareil de stockage. Pour trouver l’ID matériel :
a. Démarrez Regedit.exe, puis recherchez et cliquez sur l’emplacement suivant :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI
b. Les périphériques de disque et de stockage énumérés par le système sont répertoriés. L’appareil de
stockage sur lequel vous souhaitez activer les largesluns doit apparaître dans la liste en commençant
par Disk&Ven_. Le nom du périphérique de stockage doit être reconnaissable après la&Ven_ texte.
c. Pour trouver l’ID matériel du périphérique de stockage approprié, ouvrez les différentes clés&Ven_
disque pour afficher les différentes instances des périphériques de stockage. Une valeur étiquetée
FriendlyName avec une description à droite apparaît sous chacune des instances.
d. Après avoir localisé le périphérique de stockage, double-cliquez sur hardwareID pour l’un des noms
d’instance. Elle est généralement répertoriée sous la valeur FriendlyName.
e. Les données de valeur répertorient l’ID matériel de l’appareil de stockage. Souvent, plusieurs ID
matériels sont répertoriés. Copiez uniquement l’un de ces ID matériels. Veillez à copier uniquement la
partie de la valeur après « SCSI » \ dans le Presse-papiers.
NOTE
Il peut y avoir plusieurs ID matériels pour le même appareil. Cela se produit car l’appareil peut être détecté de
différentes manières pour différentes révisions de microprogramme du même appareil. Vous de devez peut-être
essayer chacun des différents ID matériels dans les étapes suivantes. Si vous avez des problèmes avec ce
problème, contactez le fabricant du matériel de votre appareil de stockage.
2. Avec l’ID matériel des étapes précédentes, suivez les étapes suivantes pour activer la prise en charge du
grand LUN pour le périphérique de stockage approprié :
a. Recherchez et cliquez sur la clé suivante dans le Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ScsiPort\SpecialTargetList
b. Dans le menu Edition , pointez sur Nouveau , puis cliquez sur Clé .
c. Une nouvelle clé nommée New Key #1 est créée. Cliquez avec le bouton droit sur #1, puis
cliquez sur Coller pour coller l’ID matériel que vous avez copié précédemment.
NOTE
Le fait de cliquer avec le bouton droit sur Nouveau #1 affiche également une commande Renommer que
vous pouvez utiliser pour essayer de coller à nouveau les données si l’état de la nouvelle #1 clé n’est pas
correct.
d. Après avoir créé la clé, créez une valeur DWORD nommée LargeLuns avec la valeur 1.
NOTE
« LargeLuns » est au pluriel.
Problèmes impliqués dans l’activation manuelle de la prise en charge du numéro d’utilisateur de grande taille
Des disques en double peuvent apparaître après l’activer. Cela peut se produire si le pilote HBA active la prise en
charge de l’un de grande taille d’une manière propriétaire couplée à l’entrée de Registre manuelle. Le problème
se produit si la fonctionnalité Windows LargeLuns et la fonctionnalité LargeLuns du HBA sont activées.
Si l’unité logique 0 n’est pas présente, la commande REPORT LUNS ne peut pas être envoyée à l’appareil cible.
Windows seulement huit unités logiques, même si plus d’unités sont présentes dans le tableau de disques. Pour
prendre en charge les configurations de grande taille, le temps nécessaire pour déterminer la configuration de
taille à réduire. Étant donné que le nombre d’unités logiques peut être aussi élevé que 255 sur certains systèmes
(0 - 254), beaucoup de temps peut être consacré à l’envoi de commandes de réponse à des unités logiques
inexistantes. Notez que n’importe quel numéro de numéro d’Stockage doit être dans la plage de 0 à 254.
Tout numéro d’téléphone lun avec un numéro d’un supérieur à 254 ne sera pas reconnu par le Windows
d’exploitation. Consultez votre fabricant de matériel sur les différents paramètres qui doivent être utilisés avec
votre matériel particulier.
Même si Windows peuvent accéder à des réseaux luniques de grande taille, il peut y avoir d’autres variables
d’environnement à prendre en considération.
Paramètres supplémentaires pour la clé SpecialTargetList
Pour Windows Server, vous pouvez utiliser plusieurs paramètres supplémentaires sous la clé SpecialTargetList.
Ce sont :
SparseLun : autoriser la liste des noms lun discontinus.
OneLun - Analysez uniquement zéro LUN.
LargeLuns : l’appareil prend en charge plus de sept luns.
SetLunInCdb : l’appareil nécessite le LUN dans les CDB qui lui sont envoyés.
NonStandardVPD : l’appareil prend en charge les 0x83 VPD, 0x80.
BinarySN : l’appareil renvoie un numéro de série binaire.
Ces clés sont vérifiées dans l’ordre dans lequel elles sont répertoriées ; les informations à chaque niveau sont
logiquement « OR’ed » par rapport à celle du niveau précédent.
Les logiciels antivirus qui ne prennent pas en
compte le cluster peuvent entraîner des problèmes
avec Cluster Services
Cet article fournit de l’aide pour résoudre les problèmes liés aux services de cluster qui sont causés par des
logiciels antivirus qui ne prennent pas en compte le cluster.
S’applique à : Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012
R2
Résumé
Les logiciels antivirus qui ne prennent pas en compte le cluster peuvent provoquer des problèmes inattendus
sur un serveur qui exécute Cluster Services. Par exemple, vous pouvez rencontrer des défaillances ou des
problèmes de ressources lorsque vous essayez de déplacer un groupe vers un autre nœud.
WARNING
Cette solution de contournement peut rendre votre ordinateur ou réseau plus vulnérable aux attaques par des utilisateurs
ou des logiciels malveillants comme des virus. Nous ne recommandons pas cette solution de contournement, mais nous
fournissons ces informations afin que vous puissiez implémenter cette solution à votre discrétion. Son utilisation relève de
votre responsabilité.
NOTE
Les logiciels antivirus protègent votre ordinateur contre les virus. Vous ne devez pas télécharger ou ouvrir des fichiers à
partir de sources auxquelles vous ne faites pas confiance, visiter des sites Web auxquels vous n’avez pas confiance ou
ouvrir des pièces jointes de messagerie lorsque le logiciel antivirus est désactivé.
Pour plus d’informations sur les virus informatiques, consultez Comment prévenir et supprimer les virus et
autres programmes malveillants.
La plupart des logiciels antivirus utilisent des pilotes de filtre (pilotes d’appareil) qui fonctionnent avec un
service pour rechercher des virus. Ces pilotes de filtre résident au-dessus du module de reconnaissance du
système de fichiers et analysent les fichiers lorsqu’ils sont ouverts et fermés sur un disque dur local. Les logiciels
antivirus peuvent ne pas comprendre le modèle de disque partagé et ne pas autoriser correctement le
basculement.
Si vous résolvez des problèmes de basculement ou des problèmes généraux avec les services de cluster et que
les logiciels antivirus sont installés, désinstallez temporairement le logiciel antivirus ou contactez le fabricant du
logiciel pour déterminer si le logiciel antivirus fonctionne avec les services de cluster. La désactivation du logiciel
antivirus est insuffisante dans la plupart des cas. Même si vous désactivez le logiciel antivirus, le pilote de filtre
est toujours chargé lorsque vous redémarrez l’ordinateur.
Même si vous ne surveillez pas le disque partagé, les pilotes de filtre sont toujours chargés et peuvent affecter le
fonctionnement du cluster.
Vous pouvez exécuter un logiciel antivirus sur un cluster SQL Server. Toutefois, vous devez vous assurer que le
logiciel antivirus prend en compte le cluster. Contactez votre fournisseur de logiciels antivirus pour connaître les
versions compatibles avec le cluster et l’interopérabilité.
En outre, vous devez exclure les emplacements de système de fichiers suivants et les processus de l’analyse
antivirus sur un serveur qui exécute Cluster Services :
Répertoire
Chemin d’accès du \Cluster dossier sur le disque dur du quorum. Par exemple, excluez le dossier de
l’analyse Q:\Cluster antivirus.
Dossier %Systemroot%\Cluster .
Dossier temporaire pour le compte de service de cluster. Par exemple, excluez le dossier de l’analyse
\cliusr\Local Settings\Temp antivirus.
Processus
clussvc.exe ( %systemroot%\Cluster\clussvc.exe )
Ce fichier peut être configuré en tant qu’exclusion de processus dans le logiciel antivirus.
rhs.exe ( %systemroot%\Cluster\rhs.exe )
Ce fichier peut être configuré en tant qu’exclusion de processus dans le logiciel antivirus.
Pour plus d’informations sur l’exécution de logiciels antivirus sur des serveurs qui exécutent SQL Server,
consultez Comment choisir un logiciel antivirus à exécuter sur les ordinateurs qui exécutent SQL Server.
Modification de l’adresse IP des cartes réseau dans
le serveur de cluster
Cet article explique comment modifier les adresses IP des cartes réseau dans les nodes d’un cluster.
Au cours de cette procédure, il est important que le serveur de cluster conserve une connexion au réseau. Cela
est nécessaire pour qu’il puisse communiquer avec un contrôleur de domaine pour valider le compte de service
du serveur de cluster.
Cet article part du principe qu’il existe deux nodes nommés A et B.
NOTE
Pour plus d’informations sur les installations Microsoft SQL Server cluster, cliquez sur le numéro d’article suivant pour
244980 Comment modifier les adresses IP réseau des instances de cluster de SQL Server de changement
1. Modifiez l’adresse IP de la carte réseau sur le nœud A. Cela peut nécessiter le redémarrage de
l’ordinateur. Si vous êtes invité à redémarrer l’ordinateur, faites-le.
2. Démarrez l’administrateur de cluster et ouvrez une connexion au cluster. Pour administrer le cluster, vous
devez ouvrir une connexion à « ». (sans guillemets) dans l’Administrateur de cluster lorsque vous êtes
invité à le faire. Vous devez effectuer ce processus sur l’un des nodes du cluster. Si vous le faites à
distance, il peut être possible d’ouvrir une connexion au nom du nœud lui-même. Au cours de ce
processus, l’administrateur de cluster peut répondre avec le message d’erreur suivant :
Une connexion au cluster à l'

Le nom du cluster n’a pas pu être ouvert. Cela peut être dû au fait que le service de cluster sur le
nom du cluster de nœuds n’a pas démarré. Voulez-vous que l’administrateur de cluster tente de
démarrer le service de cluster sur le nom du cluster de nœuds ?
Cela est dû au fait que l’administrateur de cluster tente de se connecter au dernier cluster qu’il a
administré.
3. Double-cliquez sur la ressource d’adresse IP pour ouvrir ses propriétés.
4. Sous l’onglet Paramètres des propriétés de la ressource Adresse IP, assurez-vous que la zone Réseau à
utiliser contient le nouveau réseau en tant que réseau à utiliser.
5. Faire échouer tous les groupes vers le nœud fonctionnel A.
6. Modifiez les adresses IP des cartes réseau dans le nœud B.
8. Lorsque les deux nodes sont d’accord sur les sous-réseaux, les anciens réseaux disparaissent et les
nouveaux réseaux sont créés.
9. Pour l’instant, vous pouvez renommer les réseaux.
Vous utilisez « . » pour administrer le cluster, car la ressource d’adresse IP n’est pas mise en ligne lorsque le
service de cluster reconnaît un nouveau réseau et n’utilise plus l’ancien réseau.
Configurer la fonctionnalité Copies de l’ombre des
dossiers partagés sur un partage de fichiers de
cluster de serveurs Windows Server 2003
Cet article explique comment configurer une cible Shadow Copies of Shared Folders sur un cluster de serveurs
dans Microsoft Windows Server 2003.
Résumé
Windows Server 2003 inclut la fonctionnalité Copies de secours des dossiers partagés pour vous permettre de
revenir à une version antérieure d’un fichier spécifique ou d’un groupe de fichiers dans un dossier.
Configurer un shadow copy

Pour configurer un shadow copy, vous devez d’abord créer une ressource de partage de fichiers dans votre
cluster de serveurs à l’aide de l’outil Administrateur de cluster. En outre, Microsoft recommande d’ajouter un
autre disque dur au même groupe qui contient la ressource de partage de fichiers. Ce disque supplémentaire
fonctionne comme lecteur de destination pour les sauvegardes de copies de secours. Pour plus d’informations
sur la création d’un partage de fichiers sur un cluster de serveurs Microsoft Windows 2000, cliquez sur le
numéro d’article suivant pour afficher l’article sur la création de partages de fichiers sur un cluster.
NOTE
Bien que vous pouvez utiliser le même lecteur qui contient votre ressource de partage de fichiers que le lecteur de
destination pour vos copies d’ombre, pour des raisons de performances, Microsoft recommande d’utiliser un disque dur
physique distinct.
IMPORTANT
Vous devez affecter une lettre de lecteur au disque dur que vous utilisez pour les sauvegardes de copies de secours. Dans
la mesure du possible, évitez de créer un shadow copy sur un point de montage. La définition du stockage de l’ombre sur
un point de montage dans un cluster est prise en charge sur un cluster de serveurs dans Windows Server 2003.
Lorsque vous configurez des copies de l’ombre sur le cluster de serveurs, une dépendance est automatiquement
configurée entre le lecteur hôte et le lecteur de destination. Il n’est pas nécessaire de créer manuellement cette
dépendance. Pour configurer des copies d’ombres, suivez les étapes suivantes :
1. Cliquez sur Démarrer, cliquez avec le bouton droit sur Mon ordinateur, puis cliquez sur Gérer.
2. Cliquez avec le bouton droit sur Dossiers par tagés, pointez sur Toutes les tâches, puis cliquez sur
Configurer les copies de l’ombre.
3. Dans la liste Sélectionner un volume, cliquez sur le lecteur qui contient la ressource de partage de
fichiers pour qui vous souhaitez créer un shadow copy. Par exemple, cliquez sur lecteur R.
4. Cliquez Paramètres, puis cliquez sur le lecteur de destination pour le shadow copy dans la liste Située
sur cette liste de volumes.
NOTE
Pour apparaître dans la liste Des emplacements de cette liste de volumes, le lecteur de destination doit
contenir un partage.
5. Si vous ne souhaitez pas configurer de limite à la taille du shadow copy, cliquez sur Aucune limite.
6. Cliquez sur OK, puis sur Activer.
7. Cliquez sur Oui pour activer les copies d’ombre.
NOTE
Il peut y avoir un délai pendant la création du shadow copy initial.
8. Cliquez sur OK .
Lorsque vous activez les copies d’ombre, le comportement suivant se produit :
Le lecteur hôte devient dépendant du lecteur de destination.
Un type de ressource Tâche de service de copie parallèle de volume est créé dans le groupe de ressources qui
contient les lecteurs sur qui vous avez créé le shadow copy. Cette ressource est utilisée pour synchroniser les
planifications des copies de l’ombre.
Configurer des points de montage de volume sur
un cluster de serveurs dans Windows Server
Cet article explique comment créer des points de montage de volume sur un cluster de serveurs à l’aide de la
fonctionnalité de points de montage de volume NTFS.
Résumé
À l’aide de points de montage de volume, vous pouvez oser ou monter une partition cible sur un dossier sur un
autre disque physique. Vous pouvez également dépasser la limite de 26 lettres pour les références de lettre de
lecteur.
Vous pouvez utiliser les méthodes suivantes pour ajouter des points de montage dans Windows Server.
NOTE
Ces méthodes sont les mêmes pour les ordinateurs en cluster ou non.
Utilisez logical Disk Manager (Diskmgmt.msc).
Utilisez Mountvol.exe à une invite de commandes.
Écrivez votre propre .exe à l’aide des fonctions Win32 SetVolumeMountPoint et DeleteVolumeMountPoint.
Lorsque vous créez un point de montage de volume sur un cluster de Windows Server, vous devez prendre en
compte les éléments clés suivants :
Un point de montage de volume ne peut pas être créé entre les disques en cluster et les disques noncluster.
Vous ne pouvez pas créer de point de montage de volume sur le disque témoin ou sur le disque utilisé pour
le type de quorum « Aucune majorité : Disque uniquement ».
Les points de montage de volume sont transparents pour les programmes.
Comment configurer des points de montage de volume sur les disques qui ne sont pas une ressource dans le
cluster
1. Connectez-vous à l’ordinateur local à l’aide des droits d’administration sur le nœud de cluster qui
héberge le point de montage et le volume du point de montage.
2. Sur chaque nœud du cluster, utilisez la console Gestion des disques pour vous assurer qu’un seul nœud a
chaque disque à l’état « en ligne ». Les disques doivent être en ligne sur le même nœud et uniquement
sur ce nœud.
3. Sur le disque qui hébergera le volume pour le point de montage, suivez les étapes suivantes :
a. Dans le volet du milieu de la console gestion des disques, cliquez avec le bouton droit sur l’élément de
disque où le numéro de disque est affiché, puis cliquez sur En ligne si le disque n’est pas déjà en ligne.
b. Cliquez à nouveau avec le bouton droit sur l’élément de disque, puis cliquez sur Initialiser le disque
si le disque n’est pas déjà initialisé.
c. Si le disque n’a pas de volume, terminez les étapes 3d-3g. Si le disque possède un volume, allez à
l’étape 3h.
d. Cliquez avec le bouton droit sur un espace non alloué, puis cliquez sur Nouveau volume simple.
e. Lorsque l’Assistant Nouveau volume simple démarre, cliquez sur Suivant, entrez la taille du volume,
f. Dans l’écran Affecter une lettre de lecteur ou un chemin d’accès, affectez une lettre de lecteur, puis
g. Formatez la partition à l’aide du système de fichiers NTFS, cliquez sur Suivant, puis cliquez sur
Terminer .
h. Si le volume ne comprend pas de lettre de lecteur, remplissez les étapes 3i-3j. Si le volume possède
une lettre de lecteur, allez à l’étape 4.
i. Cliquez avec le bouton droit sur le disque, puis cliquez sur Modifier la lettre de lecteur et les
chemins d’accès.
j. Cliquez sur Ajouter, affectez une lettre de lecteur, puis cliquez sur OK.
4. Sur le disque qui hébergera le point de montage, suivez les étapes suivantes :
a. Dans le volet du milieu de la console gestion des disques, cliquez avec le bouton droit sur l’élément de
disque où le numéro de disque est affiché, puis cliquez sur En ligne si le disque n’est pas déjà en ligne.
b. Cliquez à nouveau avec le bouton droit sur l’élément de disque, puis cliquez sur Initialiser le disque
si le disque n’est pas déjà initialisé.
c. Si le disque n’a pas de volume, terminez les étapes 4d-4i. Si le disque possède un volume, allez à
l’étape 4j.
d. Cliquez avec le bouton droit sur un espace non alloué, puis cliquez sur Nouveau volume simple.
e. Lorsque l’Assistant Nouveau volume simple démarre, cliquez sur Suivant.
f. Entrez la taille du volume, puis cliquez sur Suivant.
g. Dans l’écran Attribuer une lettre de lecteur ou un chemin d’accès, cliquez sur Monter dans le
dossier NTFS vide suivant, puis cliquez sur Parcourir.
h. Développez X :, où X représente le lecteur racine qui héberge le point de montage. Sélectionnez un
dossier vide ou créez un dossier, cliquez sur OK, puis sur Suivant .
i. Formatez la partition à l’aide du système de fichiers NTFS, cliquez sur Suivant, puis cliquez sur
Terminer .
j. Assurez-vous qu’une lettre de lecteur n’est pas affectée au volume.
k. Cliquez avec le bouton droit sur le disque, cliquez sur Modifier la lettre du lecteur et les chemins
d’accès, puis cliquez sur Ajouter .
l. Cliquez sur Monter dans le dossier NTFS vide suivant, puis cliquez sur Parcourir.
m. Développez le lecteur racine qui héberge le volume pour le point de montage. Sélectionnez un dossier
vide ou créez-en un, puis cliquez deux fois sur OK.
5. Suivez ces étapes pour ajouter les disques suivants au cluster :
Disque qui contient le point de montage
Disque qui héberge le volume pour le point de montage
a. Ouvrez le logiciel en un clin d’œil Gestion du cluster de failover. Pour ce faire, cliquez sur
Démarrer, sur Outils d’administration, puis sur Gestion du cluster de failover. Si la
boîte de dialogue Contrôle de compte d’utilisateur s’affiche, confirmez que l’action qu’il
affiche est celle que vous souhaitez, puis cliquez sur Continuer .
b. Dans le volet de navigation, cliquez sur Stockage .
c. Dans le volet Actions, cliquez sur Ajouter un disque.
d. Sélectionnez le disque qui héberge le point de montage et le volume pour le point de
montage, puis cliquez sur OK . Les deux disques apparaissent maintenant dans la Stockage
disponible du volet de stockage.
e. Cliquez avec le bouton droit sur la ressource de disque qui héberge le point de montage,
puis cliquez sur Propriétés.
f. Dans la colonne Ressource, cliquez sur l’onglet Dépendances.
g. Cliquez sur le disque racine, cliquez sur Appliquer, puis sur OK. Cette dépendance
entraîne la mise en ligne de la ressource après la mise en ligne de la ressource de disque
qui héberge le point de montage.
6. Cliquez avec le bouton droit sur les ressources de disque nouvellement ajoutées, puis cliquez sur Plus
d’actions.
7. Cliquez sur Déplacer cette ressource vers un autre ser vice ou une autre application pour
déplacer la ressource vers l’application ou le groupe de services approprié.
Comment configurer des points de montage de volume sur les disques en cluster
NOTE
Suivez ces étapes sur le nœud sur lequel le groupe « Services et applications » est hébergé.
Dans ces étapes, le volume N et le volume Y existent déjà dans le même groupe « Service de cluster et Application ».
Le volume N représente le volume qui hébergera le dossier de point de montage. Le volume Y représente le volume
monté par le point de montage. Le volume Y ne nécessite pas de lettre de lecteur affectée avant de suivre ces étapes.
Si vous recevez un message d’erreur « paramètre incorrect » lorsque vous accédez à Gestion des disques sur l’un des
serveurs de votre cluster, quittez Gestion des disques, démarrez le Gestionnaire du cluster de récupération, accédez à
Stockage, puis placez le volume N en mode maintenance.
1. Dans le volet du milieu de la console gestion des disques du nœud de cluster qui possède les volumes N et Y,
cliquez avec le bouton droit sur le volume Y, puis cliquez sur Modifier la lettre du lecteur et les chemins
d’accès.
2. Cliquez sur Ajouter, cliquez sur Monter dans le dossier NTFS vide suivant, puis cliquez sur Parcourir.
3. Cliquez sur volume N, cliquez sur Nouveau dossier, tapez un nom pour le nouveau dossier, puis cliquez deux
fois sur OK pour revenir à la console du Gestionnaire de serveur.
4. Ouvrez la console de gestion du cluster de failover.
5. Testez le point de montage sur chaque nœud en déplaçant le groupe « Service et Application » qui contient
les deux ressources de disque vers chaque nœud. Assurez-vous que les disques sont en ligne sur chaque
nœud et que les informations du volume monté sont accessibles via l’Explorateur Windows ou à l’aide de la
ligne de commande et du chemin d’accès « N: \ <mount point folder name> ».
Meilleures pratiques lorsque vous utilisez des points de montage de volume
Créez une dépendance dans la ressource de disque de volume montée qui spécifie le disque qui héberge
le dossier de point de montage. Cela rend le volume monté dépendant du volume hôte et permet de
s’assurer que le volume hôte est en ligne en premier.
NOTE
Cette pratique n’est plus nécessaire dans Windows Server 2008 et les versions ultérieures de Windows.
Si vous déplacez un point de montage d’un disque partagé vers un autre disque partagé, assurez-vous
que les disques partagés se trouvent dans le même groupe.
Essayez d’utiliser le volume racine (hôte) exclusivement pour les points de montage. Le volume racine est
le volume qui héberge les points de montage. Cette pratique réduit considérablement le temps
nécessaire pour restaurer l’accès aux volumes montés si vous devez exécuter l’outil Chkdsk.exe. Cela
réduit également le temps nécessaire à la restauration à partir d’une sauvegarde sur le volume hôte.
Si vous utilisez le volume racine (hôte) exclusivement pour les points de montage, la taille du volume
hôte doit être d’au moins 5 mégaoctets (Mo). Cela réduit la probabilité que le volume soit utilisé pour
tout autre chose que les points de montage.
Dans un cluster où la haute disponibilité est importante, vous pouvez faire des points de montage
redondants sur des volumes hôtes distincts. Cela garantit que si un volume racine (hôte) est inaccessible,
vous pouvez toujours accéder aux données qui se trouvent sur le volume monté via l’autre point de
montage. Par exemple, si HOST_VOL1 (D :) se trouve sur Mountpoint1, les données utilisateur sont
situées sur LUN3. Ensuite, si HOST_VOL2 (E:) se trouve sur Mountpoint1, les données utilisateur sont
situées sur LUN3. Par conséquent, les clients peuvent accéder à LUN3 à l’aide de D: \ mountpoint1 ou E: \
mountpount1.
NOTE
Étant donné que les données utilisateur situées sur LUN3 dépendent des volumes D et E, vous devez
temporairement supprimer la dépendance de n’importe quel volume d’hôte en échec jusqu’à ce que le volume
soit de nouveau en service. Dans le cas contraire, les données utilisateur situées sur LUN3 restent dans un état
d’échec.
Comment créer des partages de fichiers sur un
cluster
Cet article explique comment créer des partages de fichiers sur un cluster.
Résumé
Pour créer des partages de fichiers hautement disponibles sur un cluster, vous devez les créer à l’aide de
l’administrateur de cluster (CluAdmin.exe) ou de l’ensemble d’API de cluster. Lorsque le partage est placé dans
un groupe avec d’autres ressources associées (adresse IP, nom du réseau et périphérique de stockage), le
partage est disponible à partir de n’importe quel nœud du cluster qui possède le groupe de ressources. Cet
article répertorie les étapes de base pour la création d’une ressource de partage de fichiers de base.
Étapes de création d’un partage de fichiers sur un cluster de serveurs

Pour créer un partage de fichiers sur un cluster de serveurs, suivez les étapes suivantes :
NOTE
Les informations de cet article sont également valides pour le service Windows cluster 2000.
1. Ouvrez Windows Explorer et créez un dossier sur un disque partagé que vous souhaitez partager pour
les utilisateurs.
2. Attribuez les autorisations de niveau de fichier NTFS appropriées sur le dossier. Assurez-vous que le
compte utilisé pour démarrer le service de cluster dispose au moins des droits READ sur le dossier.
NOTE
Ne partagez pas le dossier dans Windows explorer comme vous le feriez normalement pour un partage de fichiers.
Si vous n’accordez pas au compte de cluster les autorisations appropriées ou ne partagez pas le dossier via
Windows Explorer, cela peut entraîner l’échec du partage de fichiers de cluster. Cela inclut également tous les
partages d’administration qui existent déjà, vous ne voulez pas créer de partages pour la racine du lecteur (Q$),
par exemple.
3. Démarrez l’administrateur de cluster (CluAdmin.exe).

4. Sélectionnez un groupe qui dispose d’une adresse IP et de ressources de nom de réseau existantes. Si
vous n’avez pas créé ces ressources, vous devrez effectuer cette chose avant de continuer.
5. Cliquez avec le bouton droit et sélectionnez Nouveau, puis Ressource .
6. Remplissez un nom d’administration et une description pour la ressource. À partir du type de
ressource tirer vers le bas, sélectionnez Partage de fichiers, cliquez sur Suivant .
NOTE
Il s’agit du nom qui s’affiche dans l’administrateur de cluster et qui est utilisé uniquement à des fins
administratives. Il ne s’agit pas du nom de partage à qui les utilisateurs se connectent, donnez à la ressource un
nom facile à identifier et à gérer.
7. Sélectionnez les nodes que vous souhaitez voir être les propriétaires possibles de la ressource. Cliquez
sur Suivant pour laisser tous les nodes comme propriétaires possibles.
NOTE
Les propriétaires possibles définissent si une ressource est en mesure de faire un failover vers un nœud spécifique.
Utilisez la prudence extrême pour définir les propriétaires possibles, car la définition d’un propriétaire possible pour
une seule ressource affectera le failover pour l’ensemble du groupe.
8. Sélectionnez un nom de réseau et une ressource de disque physique dont dépend le partage de fichiers.
NOTE
Les dépendances servent deux fonctions.
a. Ils définissent les liaisons pour une ressource. Vous souhaitez que le partage de fichiers dépende
de la ressource Nom de réseau que les clients vont utiliser lors de la connexion au partage de
fichiers. La ressource Adresse IP dont dépend la ressource Nom de réseau est l’adresse IP qui sera
utilisée lors de la connexion à ce partage. Vous ne souhaitez jamais qu’une ressource de partage
de fichiers dépende de la ressource « Cluster Name ».
b. Ils définissent l’ordre de début d’une ressource. Vous souhaitez vous assurer que le nom réseau
sous lequel le partage va être créé et que le disque physique dans lequel réside le dossier à
partager est en ligne et disponible avant d’essayer de mettre le partage de fichiers en ligne.
Lorsque vous créez une dépendance « Tree » (Arborescence), il est préférable de la garder aussi simple
que possible. Une ressource de partage de fichiers doit toujours dépendre d’un nom de réseau que les
clients utiliseront pour se connecter à ce partage et à la ressource de disque physique où se trouve le
dossier. La ressource Disque physique ne doit jamais dépendre de rien. La ressource Nom du réseau doit
dépendre d’une ressource d’adresse IP à associer au serveur virtuel. La ressource d’adresse IP ne doit
dépendre d’rien.
9. Dans l’écran Paramètres du par tage de fichiers, remplissez les informations suivantes, puis cliquez
sur Terminer :
a. Le « Nom du partage » est le nom du partage qui sera créé pour l’UNC lorsque les clients se
connectent. Il doit s’agit d’un nom NetBIOS valide et il est également recommandé d’en faire un
nom d’URL valide.
b. Le chemin d’accès est le chemin d’accès complet sur le nœud local vers le disque partagé où se
trouve le dossier. Par exemple : T : \ Utilisateurs.
c. Le « commentaire » est les informations sur le partage qui s’affichent lorsqu’un client pare le
partage.
10. Par défaut, lorsque des ressources sont créées, elles sont dans un état hors connexion. Les étapes
suivantes sont une meilleure pratique. Suivez-les pour isoler l’effet de la défaillance des ressources sur les
autres ressources de production. Cela vous aidera jusqu’à ce que la ressource soit prête à être mise en
production pour les utilisateurs.
a. Cliquez avec le bouton droit sur la ressource, puis cliquez sur Propriétés.
b. Cliquez sur l’onglet Avancé, cliquez pour sélectionner le bouton Ne pas redémarrer, puis cliquez sur
OK.
c. Mettre la ressource en ligne. Assurez-vous qu’il fonctionne correctement.
d. Une fois que vous avez confirmé que la ressource fonctionne correctement et que vous êtes prêt à la
mettre en production, déconnectez la ressource. Ensuite, cliquez pour sélectionner le bouton
Redémarrer.
e. Mettre la ressource en ligne.
NOTE
La boîte de dialogue Limite utilisateur peut être utilisée pour limiter le nombre d’utilisateurs simultanés.
Cliquez sur le bouton Autorisations pour définir les autorisations de niveau partage. Seuls les groupes au niveau
du domaine doivent être utilisés pour définir les autorisations au niveau du partage, car les groupes locaux et les
comptes d’utilisateurs ne résident pas sur l’autre nœud et les autorisations ne prennent pas effet lorsque le partage de
fichiers est bas de la ligne. La seule exception à ce problème est que tous les nodes du cluster sont des contrôleurs de
domaine. Il est recommandé d’utiliser des autorisations NTFS au lieu d’autorisations de niveau partage sur un cluster
de serveurs.
La boîte de dialogue Avancé peut être utilisée pour créer un partage de fichiers dynamiques ou une racine DFS. Le
bouton Avancé était une fonctionnalité ajoutée dans Windows NT 4.0 Service Pack 4. Si vous exécutez Windows NT
4.0, mais que vous ne voyez pas le bouton Avancé, réappliquez Windows NT 4.0 Service Pack 4 ou supérieur.
Lorsque vous parcourez le partage de fichiers, les partages de fichiers pour d’autres serveurs virtuels sur le
même cluster peuvent être visibles. Si vous comptez créer un grand nombre de ressources de partage de
fichiers, il peut être plus facile de créer un script à l’aide de Cluster.exe.
Activer la prise en charge des serveurs Windows
cluster qui utilisent des contrôleurs RAID en cluster
Cet article fournit une solution à un problème dans lequel la validation peut échouer lorsque vous exécutez un
assistant de validation de cluster pour le cluster de Windows basé sur un serveur.
Symptômes
Lorsque vous exécutez un assistant de validation de cluster pour Windows Server 2008 R2 ou un cluster de
Windows Server 2012, la validation peut échouer. En outre, vous pouvez recevoir un message d’erreur
semblable à ce qui suit :
Le type de bus disque ne prend pas en charge le clustering
Cause
Ce problème se produit si le type de stockage partagé utilisé par le système est contrôleurs RAID en cluster
direct.
Résolution
Pour résoudre ce problème, ajoutez une clé de Registre qui permet la prise en charge du stockage partagé à
l’aide de contrôleurs RAID en cluster direct.
IMPORTANT
Pour ajouter la clé au Registre, suivez les étapes suivantes :

1. Ouvrez l’Éditeur du Registre (regedit.exe).
2. Recherchez puis sélectionnez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusDIsk\Parameters
3. Cliquez avec le bouton droit sur Paramètres, puis sélectionnez Nouveau.

4. Sélectionnez DWORD et nommez-le AllowBusTypeRAID.
5. Une fois la clé créée, donnez-lui la valeur 0x01.
6. Cliquez sur OK .
7. Quittez l’éditeur du Registre.
Pour plus d’informations sur les solutions validées pour cluster dans un kit de validation box, consultez l’article
suivant :
Windows Documentation sur Stockage serveur
ID d’événement 1222 lorsque vous créez un cluster
de Windows Server 2012 de l’événement
Cet article fournit une solution pour résoudre un problème dans lequel l’ID d’événement 1222 est journalisé
lorsque vous créez un cluster de Windows Server 2012 de données.
Symptômes
Lorsque vous créez un cluster de Windows Server 2012, l’ID d’événement 1222 est consigné dans le journal
système.
Cause
Lorsque vous créez un cluster de Windows Server, un objet Ordinateur de cluster pour le nom du cluster est
créé dans les services de domaine Active Directory (AD DS). L’objet est appelé objet CNO (Cluster Name Object).
Une nouvelle fonctionnalité dans Windows Server 2012 les objets Ordinateur de cluster pour empêcher leur
suppression accidentelle. Si vous n’avez pas les droits suffisants sur l’unité d’organisation (OU) dans AD DS où
les objets Computer sont créés, un événement est journalisé qui vous informe que les objets de cluster ne sont
pas protégés contre une suppression

Windows Server 2003

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Windows Server 2003

Transféré par

Droits d'auteur :

Formats disponibles

Contents

Sous-catégories Active Directory

dism.exe /online /get-features

dism.exe /online /enable-feature /featurename:DirectoryServices-DomainController

5. Redémarrez et sélectionnez de nouveau le mode de restauration des services d’annuaire.

dism.exe /online /get-features

4. Ajoutez DirectoryServices-DomainController rôle de serveur au serveur. Pour ce faire, utilisez la

dism.exe /online /enable-feature /featurename:DirectoryServices-DomainController

5. Redémarrez, sélectionnez de nouveau le mode de restauration des services d’annuaire et connectez-

To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or

Méthodes prise en charge pour la back up Active Directory sur les

Méthodes prise en charge pour la back up Active Directory sur les

Comportement classique qui se produit lors de la restauration d’une

Logiciels et méthodologies qui entraînent des mises à jour usn

Les effets d’une rollback USN

L’existence de partitions de domaine et d’application dans la forêt

Détecter une rollback USN sur un contrôleur de domaine Windows

Récupérer à partir d’une rollback USN

Type d'événement : Avertissement

La ligne suivante est un exemple d’utilisation de cette commande :

repadmin /sync DC=domain,DC=root good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force /full

Dans l’exemple de commande :

repadmin /sync cn=configuration,DC=domain,DC=root good_DC dc1 122a5239-36b3-488a-b24c-971ed0ca8a46 /force

Type d'événement : Informations

S’applique à : Windows 10, Windows Server 2012 R2

Suppression de domaines orphelins d’Active Directory

DSACLS "OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:DC"/

DSACLS "OU=Users,OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:SDDT"

Méthode 1 : restaurer les comptes d’utilisateur supprimés, puis

repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL

Les administrateurs de Windows Server 2003 et des contrôleurs de domaine ultérieurs

ntdsutil "authoritative restore" "restore object <object DN path>" q q

ntdsutil "authoritative restore" "restore object cn=JohnDoe,ou=Mayberry,dc=contoso,dc=com" q q

Pour restaurer le groupe de sécurité supprimé ContosoPrintAccess dans l’ou Contoso.com

ntdsutil "authoritative restore" "restore object

ntdsutil "authoritative restore" "restore subtree <container DN path>" q q

ntdsutil "authoritative restore" "restore subtree ou=Mayberry, dc=contoso,dc=com" q q

repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL

repadmin /syncall /d /e /P <recovery dc> <Naming Context>

repadmin /options <recovery dc name> -DISABLE_INBOUND_REPL

Méthode 2 : restaurer les comptes d’utilisateur supprimés, puis

repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL

Les administrateurs de Windows Server 2003 et des contrôleurs de domaine ultérieurs

ntdsutil "authoritative restore" "restore object <object DN path>" q q

ntdsutil "authoritative restore" "restore object cn=JohnDoe,ou=Mayberry,dc=contoso,dc=com" q q

Pour restaurer le groupe de sécurité supprimé ContosoPrintAccess dans l’ou Contoso.com

ntdsutil "authoritative restore" "restore object

ntdsutil "authoritative restore" "restore subtree object DN path"

ntdsutil "authoritative restore" "restore object \"CN=John Doe,OU=Mayberry

ntdsutil "authoritative restore" "restore object \"CN=Doe\, John,OU=Mayberry

ntdsutil "authoritative restore" "restore object \"CN=Doe\, John,OU=Mayberry

ntdsutil "popups off" "authoritative restore" "restore object \"CN=John Doe,OU=Mayberry

ntdsutil "authoritative restore" "restore subtree <container DN path>" q q

ntdsutil "authoritative restore" "restore subtree ou=Mayberry, dc=contoso,dc=com" q q

repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL

repadmin /syncall /d /e /P <recovery dc> <Naming Context>

ldifde -d <dn path of container that hosts deleted users> -r "(objectClass=computer)" -l

Groupadd / after_restore users_membership_after_restore.ldf

repadmin /syncall /d /e /P <recovery dc> <Naming Context>

repadmin /options +DISABLE_OUTBOUND_REPL

repadmin /options -DISABLE_OUTBOUND_REPL

Méthode 3 : restaurer les utilisateurs supprimés et les groupes de

a. Sélectionnez Démarrer , puis Exécuter .

Ce contrôleur de domaine est appelé contrôleur de domaine de récupération.