Éléments de préférences de stratégie de groupe prennent beaucoup de temps à appliquer en raison de la synchronisation d’espace de noms DFS complète

Symptômes

Considérez le scénario suivant :

• Vous avez un environnement qui utilise des éléments de préférences de stratégie de groupe qui utilisent des fichiers, des dossiers ou raccourcis.

• Les éléments sont accessibles à partir de la 8.1 de Windows, Windows Server 2012 R2, Windows 7 Service Pack 1 (SP1) ou Windows Server 2008 R2 SP1 via un partage de système de fichiers distribués (DFS, Distributed File System) basé sur un domaine.

Dans ce scénario, il prend plus de temps que prévu pour appliquer un paramètre de stratégie de groupe. Vous pouvez également voir des retards lorsque vous examinez l’enregistrement dans le fichier Gpsvc.log. Ces délais ne se produisent pas lorsque le serveur de fichiers derrière l’espace de noms DFS est utilisé par un client particulier.

En outre, le comportement suivant peut se produire :

• Lorsque vous affichez les traces réseau des opérations lentes, vous remarquez qu’un NetrDfsGetInfo ou un dfs_GetInfo demande d’API de DFS prend plus de temps que prévu pour se terminer.

• Vous permet d’afficher le traitement de la demande sur le serveur DFS. La plupart du temps, ce doit être le contrôleur de domaine local. Vous trouvez qu’un retard dans la communication avec le contrôleur de domaine principal (PDC) du domaine. Il existe deux raisons de base pourquoi un délai se produit :

  • Raison 1 : Lorsque le volume DFS a de nombreux liens et que le contrôleur principal de domaine est connecté via une liaison WAN à faible bande passante, elle peut prendre beaucoup de temps à récupérer les données que le contrôleur de domaine local demande à l’aide du protocole LDAP.
    
    La charge combinée de tous les contrôleurs de domaine dans un domaine de grande taille sur le contrôleur principal de domaine peut devenir très volumineuses, la connexion à un contrôleur principal de domaine échoue et l’API DFS ne répond pas avec un chemin d’accès valide. Dans ce cas, l’élément Préférences de stratégie de groupe n’est pas appliquée après le délai. Pour plus d’informations, consultez la section « Informations complémentaires ».
    
    

  • Raison 2 : Lorsque le contrôleur de domaine ne peut pas atteindre le contrôleur principal de domaine, il consacre beaucoup de temps à essayer de se reconnecter à celui-ci.

Cause

Ce problème se produit lorsque l’emplacement réel d’un chemin d’accès d’un volume DFS est déterminée. L’extension côté client des préférences de stratégie de groupe contacte le service DFS via un appel de NetDfsGetInfo . Pour cela, dans la mesure où le contrôleur de domaine permet de s’assurer que l’appel de NetDfsGetInfo a les informations les plus récentes sur le volume DFS et interroge le contrôleur principal de domaine pour lui. L’appel de NetDfsGetInfo n’a pas de conditions préalables, mais il est considéré comme une API de gestion.

Résolution

Pour résoudre ce problème dans Windows 8.1 et Windows Server 2012 R2, installez la mise à jour 2967917. Pour plus d’informations, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :

2967917 juillet 2014 correctif cumulatif pour Windows RT 8.1, 8.1 de Windows et Windows Server 2012 R2Pour résoudre ce problème dans Windows 7 et Windows Server 2008 R2, installez le correctif qui est décrit dans la section « Informations sur le correctif » de cet article.

Solution de contournement

Pour contourner ce problème, désactivez le mode de RootScalability. Le serveur DFS utilise ensuite le contrôleur principal de domaine à synchroniser. Toutefois, il utilisera la synchronisation incrémentielle pour le contrôleur principal de domaine, et il est généralement plus rapide. Pour ce faire, exécutez la commande suivante :

Dfsutil /root:\\domain\dfsroot /RootScalability/EnablePour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

Résumé des 305027 des scénarios de « accumulation » dans les domaines Active Directory

État

Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».

Plus d'informations

Avec ce correctif installé, les préférences de stratégie de groupe ne s’appuie pas sur les API de NetDfs plus que nécessaire pour le service DFS pour contacter le contrôleur principal de domaine. Préférences de stratégie de groupe utilise une méthode différente qui s’appuie sur la commande SMB de redirection DFS obtenir. Pour en savoir plus sur le fonctionnement de DFS sur le site Web TechNet de Microsoft.

Si vous rencontrez cette combinaison de comportement GPP et le Service DFS, nous vous recommandons d’appliquer cette mise à jour sur tous les ordinateurs où les utilisateurs qui ont en général des éléments GPP ouvrent une session. Ceci s’applique généralement à toutes les stations de travail et serveurs de bureau à distance.

Le problème est que les liens de profil utilisateur sont manquants après que la mise à jour est déjà résolu par une mise à jour pour le Service DFS :

2916267 le point d’analyse de la Namespace de DFS pour les dossiers cibles sont manquants dans Windows Server 2008 R2
Remarque Cette mise à jour ne résout pas le problème de performances derrière la dépendance du contrôleur principal de domaine.

Un problème semblable qui se produit les profils itinérants sont utilisés sur les serveurs de fichiers qui sont accessibles via un espace de noms DFS, comme décrit dans l’article suivant de la Base de connaissances Microsoft :

2915094 chargement du profil prend beaucoup de temps en raison de la synchronisation d’espace de noms DFS complète avec le contrôleur principal de domaine

Références

Obtenir des informations sur la terminologie que Microsoft utilise pour décrire les mises à jour logicielles.