Il n’y a pas de réponse “juste” ici. Ma préférence personnelle serait d’utiliser la stratégie de groupe pour les paramètres/stratégies, mais pour le déploiement d’applications d’utiliser PowerShell (ou même des scripts WSH hérités ou des fichiers batch), en supposant que vous avez un seul domaine sans problèmes de confiance complexes. Cependant, il y a des compromis. Tout faire en PowerShell est certainement possible.
Déploiement d’applications (GPO vs Script) :
Avec le déploiement de logiciels basé sur GPO, vous êtes limité aux packages MSI. Cela peut être ennuyeux pour les produits qui ne sont pas distribués via MSI (par exemple setup.exe). Dans ce cas, vous devez l’empaqueter en MSI. Appréciez la distribution MSI+MSP d’Adobe Reader (vous devez créer un AIP). Si vous devez personnaliser l’installation, vous devez vous occuper des transformations MSI. Quelque chose qui pourrait être une seule ligne dans un script peut devenir un processus compliqué en plusieurs étapes.
Quand tout ce que vous déployez est facilement disponible en MSI, et que vous pouvez l’installer sans personnalisations particulières, le déploiement par GPO est assez fluide. Vous pouvez utiliser le ciblage WMI et désinstaller automatiquement ce qui n’est pas conforme à la stratégie. Mais dès que vous sortez des limites de ce cadre, les choses se compliquent. De plus, quand quelque chose ne va pas, il peut être difficile de comprendre ce qui s’est passé à partir de l’Observateur d’événements.
Avec un script, vous pouvez installer ou désinstaller à peu près n’importe quoi, MSI, EXE, peu importe. Si vous devez faire un nettoyage avant l’installation (par exemple purger les anciennes clés de registre d’une version précédente qui ne s’est pas désinstallée proprement), vous pouvez le faire. Si quelque chose ne va pas, vous pouvez ajouter autant de code de débogage/relance/contournement que nécessaire, et vous pouvez exécuter msiexec avec la journalisation activée.
Votre script aura généralement besoin d’une logique conditionnelle pour vérifier si le logiciel est déjà installé (et quelle version), puis appeler l’installateur si nécessaire. Si vous n’avez pas de formation en programmation, cela peut être intimidant. Ce n’est plus une solution pointer-cliquer. Il y a aussi plus de possibilités de faire une erreur puisque c’est vous qui l’avez écrit.
Nous sommes passés du GPO à PowerShell pour notre déploiement d’applications, et cela a simplifié les choses. Quand une nouvelle version sort, tout ce que nous avons à faire est de déposer les nouveaux fichiers d’installation dans notre partage AppDeployment et de mettre à jour la variable $expected_version dans notre script. Cela prend environ 1/10e du temps.
Vous pouvez aussi adopter une approche hybride où vous utilisez GPO pour les MSI et les scripts pour tout le reste. Je ne suis pas fan de cela parce que j’aime avoir un seul endroit pour voir ce qui est installé.
Notez qu’avec la stratégie de groupe, le déploiement d’applications ne se produit pas avant un redémarrage. Si vous utilisez des scripts de démarrage, c’est également vrai. Cependant, si vous utilisez PowerShell Remoting ou une tâche planifiée, vous pourriez réussir sans redémarrage (mais cela pourrait devenir compliqué).
Paramètres et configuration (GPO vs Script) :
Les préférences de stratégie de groupe sont vraiment simples à utiliser pour des choses comme créer des valeurs de registre, mapper des lecteurs réseau, créer des raccourcis, etc. Le fait que la stratégie de groupe ait un rafraîchissement en arrière-plan est élégant car vous pouvez appliquer des paramètres sans forcer les utilisateurs à redémarrer. Le ciblage au niveau de l’élément vous donne beaucoup de flexibilité (et cela s’ajoute au filtrage WMI et de sécurité au niveau du GPO).
Cependant, les préférences de stratégie de groupe sont loin d’être parfaites. Voici quelques-uns de mes griefs :
Il y a beaucoup trop de méthodes pour gérer Internet Explorer, certaines obsolètes, certaines ne fonctionnent pas avec les dernières versions d’IE. Je finis toujours par gérer les paramètres de registre directement.
Des erreurs aléatoires dans l’Observateur d’événements qui sont stupides. Exemple : J’ai créé un élément pour supprimer une tâche planifiée. Bien, elle a disparu de tous mes postes de travail. Maintenant l’Observateur d’événements se remplit d’erreurs “Je n’ai pas pu supprimer la tâche car elle n’existe pas”. Évidemment !
Appliquer une fois et ne pas réappliquer vous jouera des tours au moins une fois dans votre carrière.
Mettre à jour vs Remplacer. Faites attention car vous choisirez probablement le mauvais.
Il y a des limites à ce que vous pouvez faire avec le ciblage au niveau de l’élément. Si vous avez besoin d’une boucle for() ou d’une manipulation de chaînes (supprimer des caractères, ajuster la casse), vous reviendrez à un script.
Les opérations sur les fichiers GPP se produisent toujours, même si le fichier n’a pas été modifié. Vos postes de travail continueront à copier le même fichier depuis le serveur encore et encore, même s’ils n’en ont pas besoin. Cela peut surcharger de manière inattendue votre serveur et votre réseau. Le ciblage au niveau de l’élément peut aider à atténuer cela, mais attention si vous avez coché Supprimer si non appliqué.
Beaucoup d’erreurs GPP dans l’Observateur d’événements ne contiennent aucune information utile pour résoudre le problème. Vous devez activer le traçage.
Vous pouvez utiliser PowerShell pour les paramètres, mais cela a aussi des inconvénients :
Gérer les paramètres de registre avec PowerShell devient confus (au moins avec le fournisseur Registry natif). À mon avis, Microsoft a fait une erreur en faisant des valeurs de registre des “propriétés” au lieu d’éléments réels. Cela rend les choses bien plus complexes que nécessaire. Vous avez besoin d’un tas de logique conditionnelle pour tester les clés de registre et les créer avant de créer les valeurs. La stratégie de groupe est beaucoup plus simple dans ce domaine.
Il y a beaucoup de tâches d’administration “basiques” que vous ne pouvez pas faire nativement en PowerShell (par exemple créer un raccourci, gérer une tâche planifiée). Vous devez invoquer Wsh, le Framework .Net, ou utiliser un module tiers.
Les scripts ne s’exécutent qu’au démarrage/à la connexion. Pas de rafraîchissement en arrière-plan (sauf si vous configurez une tâche planifiée).
Si vous devez appeler des utilitaires Windows hérités (net.exe, schtasks.exe), il peut être délicat d’appeler la commande, et encore plus “délicat” de faire jouer sa sortie écran correctement avec la sortie de PowerShell. Vous pourriez avoir une commande qui échoue sans que vous le sachiez.
Quelques autres commentaires généraux sur les scripts (PowerShell ou autres) vs GPO :
Les scripts sont essentiellement des projets de programmation. Le code va grandir et devenir plus complexe au fil du temps. Si vous ne le traitez pas comme un “vrai” projet de programmation, avec des commentaires, un historique de versions, des sous-routines, etc., il va devenir un fouillis impossible à maintenir que votre successeur finira par abandonner parce qu’il ne le comprend pas.
Les administrateurs système ne sont (généralement) pas des programmeurs. Ils ne connaissent pas les disciplines de programmation appropriées (voir point n°1). Même un code bien structuré peut être intimidant et illisible pour un administrateur sans formation en programmation. Soyez attentif aux compétences de votre personnel actuel et futur.
Les scripts ont l’avantage de pouvoir être versionnés dans un système de contrôle de version et comparés (diff). Avec les GPO, c’est un peu plus difficile à faire.
Les scripts sont plus faciles à copier sur une clé USB et à emporter avec vous. C’était probablement le cas pour votre prestataire. Il avait probablement des scripts existants de projets précédents qu’il a pu recycler pour votre projet. Dans mon environnement, j’ai deux réseaux isolés (ne demandez pas), mais avec des configurations similaires, donc nous utilisons des scripts PowerShell partout où c’est possible pour recycler le code entre les deux réseaux.
Les GPO ont l’avantage que vous pouvez utiliser des outils comme RSoP pour obtenir un rapport de tous les paramètres appliqués à un poste de travail/utilisateur particulier. Cela peut être important pour l’audit et le dépannage.
Les GPO sont plus “découvrables”. Je peux arriver dans un environnement inconnu et me mettre à niveau assez rapidement sur les stratégies et paramètres appliqués. Avec un script, je dois commencer à étudier le code et espérer qu’il est bien commenté.
PowerShell Remoting peut être très pratique pour une commande ponctuelle que vous voulez exécuter sur un ensemble de systèmes, et que vous ne voulez pas en faire une stratégie “permanente” (par exemple tout le monde supprime ce fichier temporaire).
Quelle que soit l’approche que vous utilisez, assurez-vous que les choses sont bien documentées. Vous devriez documenter les choses au niveau micro (“Paramètre x implémenté pour tous les postes de comptabilité pour résoudre le problème avec l’application y”), et aussi au niveau macro (“Tous nos paramètres de postes de travail sont stockés dans le GPO appelé x”).
MODIFICATION DE SUIVI : PowerShell 4 ajoute une nouvelle fonctionnalité appelée Desired State Configuration. Cela semble pouvoir être utilisé pour accomplir une partie de ce que font les préférences de stratégie de groupe. Cela pourrait changer la donne. Je n’ai pas encore travaillé avec mais cela semble vraiment bien.
MODIFICATION DE SUIVI 2 : Une chose que j’ai réalisé est que je n’ai pas correctement différencié entre les stratégies vs préférences de stratégie de groupe. Les préférences sont essentiellement analogues à un script PowerShell. Les stratégies sont un peu plus “rigides” et sont plus délicates à implémenter dans un script. Pour ce faire, vous devez faire remplir par votre script HKLM\Software\Policies, mais vous devez être attentif aux collisions avec les GPO. Dans ce cas, faites l’un ou l’autre, pas les deux.