L'installation de la stratégie de groupe a échoué erreur 1274
J'essaie de déployer un MSI via la stratégie de groupe dans Active Directory. Mais ce sont les erreurs que j'obtiens 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 de 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 connexion car les modifications doivent être appliquées avant la connexion 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 l'ouverture de session pour cet utilisateur, ce qui peut entraîner des performances de démarrage et de démarrage lentes.
Lorsque je redémarre et me reconnecte, 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 la 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 peux installer le MSI en utilisant la ligne de commande et msiexec lorsque je suis connecté à l'ordinateur, donc je sais que le MSI fonctionne au moins correctement.
Vous voyez le fléau redouté du traitement des politiques asynchrones. Ce n'est pas une "fonctionnalité" (et était désactivée par défaut dans Windows 2000 mais activée par défaut dans Windows XP et supérieur) et provoque exactement ce que vous voyez - comportement non déterministe avec le traitement certains types de paramètres GPO.
Dans un GPO 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 de l'ordinateur et ouvrez une session - Activé
- Se connecter
- Système
- Modèles d'administration
Après avoir défini cela (et autoriser le GPO à répliquer si vous êtes dans un environnement multi-DC), faites un "gpupdate/force/boot" sur le PC en question. Il redémarrera et vous devriez voir l'installation du logiciel se produire.
La fonction "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 GPO sont autorisées à traiter, mais l'avantage est que toutes les 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é de la réponse de @Evan Anderson, mais ce n'est que lorsque j'ai ajouté ce paramètre ci-dessous également qui a permis l'installation du logiciel. Je ne sais pas si c'était une combinaison des deux paramètres ou non. Cela fonctionne maintenant, donc je laisse les deux paramètres.
Dans une stratégie de groupe appliquée à ces postes de travail, accédez à:
Configuration ordinateur> Stratégies> Modèles d'administration> Système> Stratégie de groupe
Activez le Spécifiez le temps d'attente de traitement de la politique de démarrage . Définir Temps d'attente (en secondes) : = 120
120 pourrait être exagéré, mais cela a fonctionné pour moi. D'autres forums ont suggéré de régler cela à 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 eux.
Cela peut se produire si l'application est déjà installée mais que msiexec n'est pas en mesure de la désinstaller. Le scénario le plus courant est une installation manuelle précédente avec "Seulement pour moi" sélectionné au lieu de "Tous ceux qui se connectent à cet ordinateur".
Vous pouvez utiliser l'utilitaire de nettoyage de Windows Installer ( http://support.Microsoft.com/kb/290301 ) pour tromper le PC en lui faisant croire que l'application n'est plus présente, puis qu'elle devrait bien se passer .
Et je viens de trouver une autre cause différente de cette erreur. Si "Spanning Tree" est configuré sur le commutateur Ethernet connecté à la station de travail à problème, cela retardera l'activation du port du commutateur au démarrage du PC. La désactivation de Spanning Tree pour le port de commutateur ou l'activation de "Spanning Tree Portfast" pour le port de commutation 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'il y avait un autre GPO essayant d'installer un logiciel avant le mien, et il échouait avec l'erreur %% 1274 parce que le GPO lui-même avait les mauvaises autorisations. Pour une raison quelconque, cet échec empêchait alors mon GPO de s'installer, même si le mien avait les autorisations appropriées. Une fois que j'ai désactivé l'autre objet GPO, mon GPO s'est installé correctement.
Changer le 'temps d'attente de 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 augmenté à 90 secondes et ils étaient contents.
J'ai fait face au même comportement avec quelques ordinateurs portables. Ils ont bien fonctionné pendant quelques années, puis soudainement, ils n'ont installé aucun nouveau logiciel via gpo. Forcer le paramètre "Temps d'attente de traitement de la politique de démarrage" semble avoir corrigé le problème. Comme indiqué précédemment devrait être 30 secondes par défaut, mais pour moi, il semblait que les ordinateurs portables n'attendaient pas du tout au démarrage pour les politiques mais sautaient directement. Tous les ordinateurs portables étaient win7x64, DCs Server2008R2 et Server2012.
Parfois, votre politique de groupe peut être foirée. Essayez de supprimer l'intégralité de la clé de registre HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Group Policy. Vous trouverez probablement tout de GP réinstallé au redémarrage. Vous voudrez peut-être d'abord sauvegarder votre registre ...
On avait le même problème. Nous avons finalement compris que nos ordinateurs portables étaient RADIUS authentifiés sur le WiFi, et l'installation réseau ne pouvait pas démarrer jusqu'à ce que l'utilisateur se connecte avec les informations d'identification AD (car aucune connectivité réseau jusque-là pour exécuter l'installation à distance) Et après la connexion de l'utilisateur, il était trop tard car l'installation devait commencer avant cela.
Lorsque le client est connecté via Ethernet, cela fonctionne comme un charme!
La réponse d'Evan Anderson est très bien, 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 cela GPO consiste simplement à redémarrer deux fois, je ne vois pas vraiment pourquoi quelqu'un prendrait ce compromis.
Problème résolu!
Je me connectais aux machines clientes en tant qu'utilisateur de domaine avec des privilèges d'administrateur Entreprise/Domaine et j'étais en mesure d'accéder sans problème à un dossier partagé contenant les packages d'installation MSI. Cependant, à un moment donné, j'ai essayé d'y accéder via\IP\share_path_to_msi_packages_folder à partir d'un autre PC n'appartenant pas au domaine et j'ai continué à obtenir une fenêtre de connexion. Fondamentalement, même si l'on autorise tous les utilisateurs/groupes du domaine et non-domaine ou les autorisations de lecture/écriture de "Tout le monde" sur le dossier partagé, cela ne fonctionnerait toujours pas et me demander un nom d'utilisateur/mot de passe ne permettant pas ainsi au client local de dérouler les packages pointés par le GPO . Cela est dû à accès anonyme désactivé par défaut. Après l'avoir activé et avoir accordé des autorisations de lecture/écriture au dossier MSI, la majorité des packages a pu être déployée avec succès et seul synology-cloud-station-3.1.-3320.msi a échoué (besoin de l'examiner). J'ai également pu accéder au dossier partagé à partir de n'importe quelle machine n'appartenant pas au domaine.
J'obtenais 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 de la politique DOMAIN 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 de la stratégie DOMAIN 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 connexion car les modifications doivent être appliquées avant la connexion 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 connexion car les modifications doivent être appliquées avant la connexion de l'utilisateur. L'erreur était: %% 1274
Installer:
SERVEURS DC1 (PDC) + DC2 (BDC) + DC3 (DBC) Windows 2012 R2 Standard entièrement mis à jour
CLIENTS Windows 7 Pro SP1 (restauration Dell propre, packages entièrement mis à jour et conflictuels tels que l'ancien Adobe Flash désinstallé)
Ont déjà essayé des clients:
- gpupdate/force
- gpupdate/force/boot (les deux demandent de redémarrer et de renvoyer une erreur indiquant que les politiques n'ont pas été appliquées)
- gpresult/r (beau)
- les serveurs et les clients peuvent accéder au lecteur partagé sur lequel les packages MSI sont stockés
- redémarré plusieurs fois DC1 et les clients après des modifications de GPO
GPO désactiver l'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 GPO sont placés dans des objets de stratégie de groupe, puis liés à partir des GPO directement sous notre domaine. D'autres paramètres tels que IE restrictions d'un autre GPO configuration de la même manière s'appliquent correctement au client).
Il n'y a pas d'autres erreurs dans AD, DHCP, DNS fonctionne parfaitement, les machines obtiennent des adresses IP et peuvent résoudre les noms via nslookup ainsi que se pinguer sur IPv4/IPv6.