Erreur 1274 de l'échec de l'installation de la stratégie de groupe

J'essaie de déployer un MSI via la stratégie de groupe dans Active Directory. Mais ce sont les erreurs que je reçois dans le journal des événements système après la connexion:

• L'affectation de l'application XStandard à partir de l'installation de la stratégie a échoué. L'erreur était: %% 1274
• La suppression de l'affectation de l'application XStandard depuis l'installation de la stratégie a échoué. L'erreur était: %% 2
• Échec de l'application des modifications aux paramètres d'installation du logiciel. L'installation du logiciel déployé via la stratégie de groupe pour cet utilisateur a été retardée jusqu'à la prochaine ouverture de session, car les modifications doivent être appliquées avant l'ouverture de session de l'utilisateur. L'erreur était: %% 1274
• L'installation du logiciel d'extension côté client de stratégie de groupe n'a pas pu appliquer un ou plusieurs paramètres, car les modifications doivent être traitées avant le démarrage du système ou la connexion de l'utilisateur. Le système attendra que le traitement de la stratégie de groupe se termine complètement avant le prochain démarrage ou la prochaine ouverture de session pour cet utilisateur, ce qui peut ralentir les performances de démarrage et d’amorçage.

Lorsque je redémarre et que je me connecte à nouveau, je reçois simplement les mêmes messages sur la nécessité d'effectuer la mise à jour avant la prochaine connexion. Je suis sur un ordinateur portable Windows Vista 32 bits. Je suis plutôt nouveau dans le déploiement via une stratégie de groupe, alors quelles autres informations seraient utiles pour déterminer le problème? J'ai essayé un MSI différent avec les mêmes résultats. Je suis en mesure d'installer le fichier MSI à l'aide de la ligne de commande et de msiexec une fois connecté à l'ordinateur. Je sais donc que le fichier MSI fonctionne correctement.

Vous constatez le fléau redouté du traitement de stratégie asynchrone. Ce n'est pas une "fonctionnalité" (et était désactivé par défaut dans Windows 2000 mais activé par défaut dans Windows XP et versions ultérieures) et provoque exactement ce que vous constatez: un comportement non déterministe lors du traitement de certains types de paramètres d'objet de stratégie de groupe.

Dans un objet de stratégie de groupe qui s'applique à cet ordinateur, ajoutez le paramètre suivant:

• Paramètres de l'ordinateur
  • Modèles d'administration
    • Système
      • Se connecter
        • Attendez toujours le réseau au démarrage et à la connexion de l'ordinateur - Activé

Une fois que vous avez défini cette option (et autorisé le GPO à se répliquer si vous êtes dans un environnement multi-contrôleurs), effectuez une opération "gpupdate / force / boot" sur le PC en question. Il va redémarrer et vous devriez voir l'installation du logiciel se produire.

L'option «Toujours attendre le réseau au démarrage et à la connexion de l'ordinateur» ralentit légèrement le démarrage et la connexion, car toutes les extensions de GPO sont autorisées à traiter, mais le bon côté des choses est que toutes les extensions de GPO sont autorisées à traiter.

J'ai essayé le paramètre Toujours attendre le réseau au démarrage et à la connexion de l'ordinateur - Activé à partir de la réponse de @Evan Anderson, mais ce n'est que lorsque j'ai ajouté ce paramètre ci-dessous que le logiciel a pu être installé. Pas sûr que ce soit une combinaison des deux paramètres ou non. Cela fonctionne maintenant, alors je laisse les deux paramètres.

Dans une stratégie de groupe appliquée à ces postes de travail, accédez à:

Configuration de l'ordinateur> Stratégies> Modèles d'administration> Système> Stratégie de groupe

Activez le délai d’attente de traitement de la stratégie de démarrage . Définir le délai d'attente (en secondes) : = 120

120 pourrait être exagéré, mais cela a fonctionné pour moi. D'autres forums ont suggéré de le définir à 30 secondes. Même si 30 secondes par défaut (lorsque la stratégie n'est pas définie), le forcer à 30 secondes a fonctionné pour elles.

Cela peut arriver si l'application est déjà installée mais que msiexec ne parvient pas à la désinstaller. Le scénario le plus courant est une précédente installation manuelle avec "Seulement pour moi" sélectionné au lieu de "Tous ceux qui se connectent à cet ordinateur".

Vous pouvez utiliser l'utilitaire Windows Installer Cleanup ( http://support.microsoft.com/kb/290301 ) pour amener le PC à penser que l'application n'est plus présente, et que tout devrait bien se passer.

Et je viens de trouver une autre cause différente de cette erreur. Si vous avez "Spanning Tree" configuré sur le commutateur Ethernet connecté au poste de travail posant problème, cela retardera l’activation du port du commutateur lors de l’amorçage du PC. La désactivation de Spanning Tree pour le port du commutateur ou l'activation de "Spanning Tree Portfast" pour le switchport a résolu ce problème sur quelques-uns de mes postes de travail.

J'ai eu le même problème, mais aucune des corrections ci-dessus n'a fonctionné. J'ai finalement compris qu'un autre GPO essayait d'installer un logiciel avant le mien et qu'il échouait avec l'erreur %% 1274 car le GPO lui-même disposait de mauvaises autorisations. Pour une raison quelconque, cet échec empêchait alors mon GPO de s'installer, même si le mien disposait des autorisations appropriées. Une fois que j'ai désactivé l'autre objet de stratégie de groupe posant problème, mon objet de stratégie de groupe s'est installé correctement.

Changer le " temps d'attente pour le traitement de la politique de démarrage " a fonctionné pour moi. Il était réglé sur 30 secondes, mais certains postes de travail échouaient toujours avec %% 1274.

Je l'ai porté à 90 secondes et ils étaient heureux.

Parfois, votre stratégie de groupe peut être gâchée. Essayez de supprimer la clé de registre complète HKLM / SOFTWARE / Microsoft / Windows / CurrentVersion / Stratégie de groupe. Vous trouverez probablement que tout de GP est installé à nouveau au redémarrage. Vous voudrez peut-être d'abord sauvegarder votre base de registre ...

J'ai eu le même comportement avec deux ordinateurs portables. Ils ont bien fonctionné pendant quelques années, puis n’ont soudainement pas installé de nouveau logiciel via gpo. Forcer le paramètre "Délai d'attente du traitement de la stratégie de démarrage" semble avoir corrigé le problème. Comme il a été dit précédemment, la durée par défaut devrait être de 30 secondes, mais pour moi, les ordinateurs portables ne semblaient pas attendre du tout au démarrage, mais étaient ignorés. Tous les ordinateurs portables étaient win7x64, les contrôleurs de domaine Server2008R2 et Server2012.

On avait le même problème. Nous avons finalement découvert que nos ordinateurs portables étaient authentifiés par RADIUS en WiFi et que l'installation du réseau ne pouvait pas démarrer tant que l'utilisateur ne se connectait pas avec les informations d'identification AD (car aucune connectivité réseau jusque-là n'exécutait les fichiers d'installation à distance). Et après la connexion de l'utilisateur, il était trop tard, car l'installation devait commencer avant.

Lorsque le client était connecté via Ethernet, cela fonctionnait à merveille!

Problème résolu!

Je me connectais aux ordinateurs clients en tant qu'utilisateur de domaine avec des privilèges d'administrateur Enterprise / Domain et je pouvais accéder à un dossier partagé contenant les packages d'installation MSI sans aucun problème. Cependant, à un moment donné, vous avez essayé d'y accéder via \ IP \ share_path_to_msi_packages_folder à partir d'un autre PC n'appartenant pas au domaine et de continuer à afficher une fenêtre de connexion. Fondamentalement, même si on autorise tous les utilisateurs / groupes de domaine et non-domaine ou les autorisations de lecture / écriture 'Tout le monde' sur le dossier partagé, cela ne fonctionnerait toujours pas et je ne demanderais pas de nom d'utilisateur / mot de passe, ce qui ne permettrait pas au client local d'extraire les packages pointés par le GPO. . Ceci est causé par accès anonyme désactivé par défaut. Après l'avoir activé et avoir donné des autorisations de lecture / écriture au dossier MSI, la majorité des paquets ont pu être déployés avec succès. Seul Synology-cloud-station-3.1.-3320.msi a échoué (il faut l'examiner). J'ai également pu accéder au dossier partagé à partir de n'importe quelle machine ne faisant pas partie du domaine.

Je recevais ces messages d'erreur à peu près toutes les 5 minutes dans Événements> Système:

101 L'affectation de l'application 7-Zip 9.20 (édition x64) à partir de l'installation des packages de base DOMAIN de la stratégie a échoué. L'erreur était: %% 1274

103 L'affectation de l'application 7-Zip 9.20 (édition x64) à partir de l'installation des packages de base DOMAIN de la stratégie a échoué. L'erreur était: %% 1274

108 Échec de l'application des modifications aux paramètres d'installation du logiciel. L'installation du logiciel déployé via la stratégie de groupe pour cet utilisateur a été retardée jusqu'à la prochaine ouverture de session, car les modifications doivent être appliquées avant l'ouverture de session de l'utilisateur. L'erreur était: %% 1274

1112 Échec de l'application des modifications aux paramètres d'installation du logiciel. L'installation du logiciel déployé via la stratégie de groupe pour cet utilisateur a été retardée jusqu'à la prochaine ouverture de session, car les modifications doivent être appliquées avant l'ouverture de session de l'utilisateur. L'erreur était: %% 1274

Installer:

SERVERS DC1 (PDC) + DC2 (BDC) + DC3 (DBC) Windows 2012 R2 Standard entièrement mis à jour

CLIENTS Windows 7 Pro SP1 (restauration propre de Dell, paquets en conflit entièrement mis à jour, tels que le vieil Adobe Flash désinstallé)

J'ai déjà essayé des clients:

• gpupdate / force
• gpupdate / force / boot (les deux demandent de redémarrer et jettent une erreur indiquant que les stratégies n'ont pas été appliquées)
• gpresult / r (bien paraître)
• les serveurs et les clients peuvent accéder au lecteur partagé où les packages MSI sont stockés
• redémarré plusieurs fois DC1 et les clients après les modifications apportées à l'objet de stratégie de groupe

GPO désactiver UAC:

* Computer Configuration * Policies * Windows Settings * Security Settings * Local Policies * Security Options ELEVATE WITHOUT PROMPTING: User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode DISABLE: User Account Control: Detect application installation and prompt for elevation DISABLE: User Account Control: Run all administrators in Admin Approval Mode

GPO deploy base software: * Computer Configuration * Policies * Administrative Templates * System * Logon ENABLE: Always wait for the network at computer startup logon * Group Policy ENABLE: Specify startup policy processing wait time (temporarily set to 120 will change to 30 later)

* Computer Configuration * Policies * Software Installation * 7-Zip 9.20 (x64 edition) v9.20 Assigned \LANIP\Utils\Software\GPO\7zip-7z920-x64.msi * Google Chrome v66.41 Assigned \LANIP\Utils\Software\GPO\googlechromestandaloneenterprise.msi * Mozilla Firefox (en-GB) v35.0 Assigned \LANIP\Utils\Software\GPO\firefox-35.0.1-en-gb-msi * Synology Cloud Station v3.1 Assigned \LANIP\Utils\Software\GPO\synology-cloud-station-3.1.-3320.msi

Tous les objets de stratégie de groupe sont placés dans des objets de stratégie de groupe, puis liés à des objets de stratégie de groupe directement dans notre domaine. D'autres paramètres, tels que les restrictions IE provenant d'une autre configuration d'objet de stratégie de groupe, s'appliquent de la même manière au client.

Il n'y a pas d'autres erreurs dans AD, DHCP, le DNS fonctionnent parfaitement, les machines obtiennent des adresses IP et peuvent résoudre des noms via nslookup, ainsi que des requêtes ping sur IPv4 / IPv6.

La réponse d'Evan Anderson est correcte, mais il manque un avertissement assez important:

Cela peut considérablement ralentir les connexions hors domaine pour les ordinateurs portables et les clients sans fil.

Compte tenu de la solution de contournement sans cet objet de stratégie de groupe, qui consiste simplement à redémarrer deux fois, je ne vois pas vraiment pourquoi quelqu'un supprimerait ce compromis.

Windows 2012 R2

Dans une stratégie de groupe appliquée à ces postes de travail, accédez à:

Configuration de l'ordinateur> Stratégies> Modèles d'administration> Système> Stratégie de groupe

Activez le délai d’attente de traitement de la stratégie de démarrage. Définir le délai d'attente (en secondes): = 120