Pourquoi gpedit et les entrées de registre correspondantes ne sont pas synchronisés?

Je suis sur Windows 10 Pro. J'ai remarqué que lorsque j'applique certaines politiques via gpedit, les entrées correspondantes sont créées dans le registre. Si j'annule, les entrées sont également supprimées du registre.

Je m'attendais donc à ce que cela fonctionne également dans l'autre sens, mais si je définis manuellement la même stratégie via le registre, les entrées gpedit correspondantes s'affichent toujours comme "non configurées".

Suis-je en train de manquer quelque chose? la politique gpedit est-elle autre chose qu'une entrée de registre? alors ... où sont-ils stockés?

Étant donné que les modifications que vous apportez dans l'éditeur de stratégie de groupe affectent ce que vous voyez dans le Registre, il est parfaitement logique de supposer que l'inverse est également vrai. Cependant, cela ne fonctionne pas de cette façon.

Les paramètres de stratégie de groupe locale (ce à quoi je pense que vous faites référence dans votre message) sont stockés dans des registry.polfichiers situés dans C:\Windows\system32\GroupPolicy. Ces fichiers remplacent les clés correspondantes dans le registre chaque fois que le système effectue une actualisation de la stratégie de groupe. L'éditeur ne lit jamais réellement le registre pour voir quels paramètres il contient.

Une actualisation de la stratégie de groupe est déclenchée chaque fois que l'un des événements suivants se produit:

• À un intervalle de rafraîchissement régulièrement planifié (toutes les 90 minutes par défaut)
• Un événement d'ouverture ou de fermeture de session utilisateur (stratégie utilisateur uniquement)
• Un redémarrage de l'ordinateur (stratégie informatique uniquement)
• Une actualisation déclenchée manuellement via gpupdate
• Une commande d'actualisation de stratégie émise par un administrateur à partir du contrôleur de domaine (si l'ordinateur est joint au domaine).

Il est important de se rappeler que si l'ordinateur est joint au domaine, les stratégies de domaine seront appliquées après le traitement des fichiers de stratégie de groupe local (ce qui signifie que certains paramètres peuvent être remplacés par la stratégie de domaine). Vous ne pourrez pas voir les stratégies de domaine dans l'éditeur de stratégie de groupe local.

Cela fonctionne comme ceci pour trois raisons:

• La stratégie de groupe est conçue en gardant à l'esprit un «push» à partir d'un contrôleur de domaine Active Directory. Les ordinateurs ne sont pas destinés à contrôler la stratégie sur le contrôleur de domaine.

• La notion de politiques et d'Active Directory a été développée à une époque où les connexions d'accès à distance étaient très courantes et pas le haut débit. Pour que les modifications du registre soient renvoyées à un contrôleur de domaine dans cette situation, cela consomme probablement beaucoup de bande passante très limitée et les situations où les systèmes ne parlent qu'occasionnellement à un contrôleur de domaine via des sessions d'accès à distance ici et il n'y a pas eu de cas inconnus dans le NT4 jours je crois.

• Vous avez probablement remarqué que de nombreuses stratégies ont un paramètre «Non configuré», «Activé» ou «Désactivé». La stratégie de groupe a le paramètre «Non configuré» pour permettre au paramètre local de rester intact par la stratégie. Cela signifie spécifiquement que vous, une application ou un administrateur local pouvez modifier les entrées de registre pertinentes et qu'une stratégie ne les modifiera pas. Vous ne voudrez peut-être pas contrôler tous les aspects du système par le biais d'une stratégie.

Ainsi, le registre local et une stratégie de groupe ne se synchronisent pas à partir de la machine-> AD par conception. La stratégie de groupe locale gpedit.mscfonctionne de la même manière même si elle n'est synchronisée avec aucun contrôleur de domaine.