powershell vs GPO pour l'installation, la configuration, la maintenance

Il n'y a pas de "bonne" réponse ici. Ma préférence personnelle serait d'utiliser la stratégie de groupe pour les paramètres / politiques, mais pour le déploiement des applications, utilisez PowerShell (ou même les scripts WSH hérités ou les fichiers batch), en supposant que vous ayez un seul domaine sans problèmes de confiance complexes. Cependant, il y a des compromis à faire. Tout faire en PowerShell est certainement légal.

Déploiement d'applications (GPO vs script) :

Avec le déploiement de logiciels basé sur les GPO, vous êtes limité aux paquets MSI. Cela peut être gênant pour les produits qui ne sont pas distribués via MSI (par exemple setup.exe). Dans ce cas, vous devez le conditionner sous forme de MSI. Profitez de la distribution MSI+MSP d'Adobe Reader (il faut faire un AIP). Si vous avez besoin de personnaliser l'installation, vous devez utiliser les transformations MSI. Quelque chose qui pourrait être une simple ligne dans un script peut devenir un processus compliqué en plusieurs étapes.

Lorsque tout ce que vous déployez est facilement disponible sous forme de MSI et que vous pouvez l'installer sans personnalisation particulière, le déploiement de GPO est assez simple. Vous pouvez utiliser le ciblage WMI et désinstaller automatiquement les éléments qui ne font pas partie de la politique. Mais dès que vous sortez des limites de cette boîte, les choses se compliquent. En outre, lorsque 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 tout, MSI, EXE, etc. Si vous devez effectuer un travail de nettoyage avant l'installation (par exemple, purger les anciennes clés de registre d'une version précédente qui n'a pas été désinstallée proprement), vous pouvez le faire. Si quelque chose se passe mal, vous pouvez ajouter autant de code de débogage/répétition/contournement que vous le souhaitez, et vous pouvez exécuter msixec 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 invoquer l'installateur si nécessaire. Si vous n'avez pas de connaissances en programmation, cela peut être intimidant. Il ne s'agit plus d'une solution de type "pointer-cliquer". Vous avez également plus de chances de vous tromper puisque vous l'avez écrit vous-même.

Nous sommes passés de GPO à PowerShell pour le déploiement de nos applications, et cela nous a grandement facilité la tâche. Quand une nouvelle version sort, tout ce que nous devons 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 également adopter une approche hybride où vous utilisez GPO pour les éléments MSI et scripts pour tout le reste. Je ne suis pas un fan de cela parce que j'aime avoir un seul endroit où aller pour voir ce qui est installé.

Notez qu'avec la stratégie de groupe, le déploiement des applications ne se fait pas avant un redémarrage. Si vous utilisez Startup scripts, c'est également vrai. Cependant, si vous utilisez Remoting PowerShell ou d'une tâche planifiée, vous pouvez peut-être le faire sans redémarrage (mais cela peut être compliqué).

Paramètres et configuration (GPO vs script) :

Les préférences de stratégie de groupe sont vraiment simples à utiliser pour faire 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 dispose d'un rafraîchissement en arrière-plan est astucieux car vous pouvez appliquer des paramètres sans obliger les utilisateurs à redémarrer. Le ciblage au niveau de l'élément vous donne beaucoup de flexibilité (et ceci en plus du filtrage WMI et de sécurité au niveau de la GPO).

Cependant, les préférences de la politique de groupe sont loin d'être parfaites. Quelques-uns de mes défauts :

1. Il y a beaucoup trop de méthodes pour gérer Internet Explorer, certaines d'entre elles sont dépréciées, d'autres ne fonctionnent pas avec le dernier IE. Je finis toujours par gérer directement les paramètres du registre.

2. Erreurs aléatoires dans l'observateur d'événements qui sont stupides. Exemple : J'ai créé un élément pour supprimer une tâche programmée. Super, elle a disparu de tous mes postes de travail. Maintenant l'Observateur d'événements commence à se remplir d'erreurs "Je n'ai pas pu supprimer la tâche car elle n'existe pas". Duh !

3. Appliquez une fois et ne réappliquez pas vous baisera au moins une fois dans votre carrière .

4. Mise à jour ou remplacement . Faites attention car vous allez probablement choisir le mauvais.

5. Il y a des limites à ce que vous pouvez faire avec le ciblage au niveau des éléments. Si vous avez besoin d'une boucle for() ou de manipuler des chaînes de caractères (couper les caractères, ajuster la casse), vous devrez revenir à un script.

6. Les opérations sur les fichiers GPP ont toujours lieu, même si les fichiers n'ont pas été modifiés. 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 mettre à mal votre serveur et votre réseau de manière inattendue. Le ciblage au niveau des éléments peut contribuer à atténuer ce phénomène, mais faites attention si vous avez coché la case "Supprimer si non appliqué".

7. De nombreuses 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 présente aussi quelques inconvénients :

1. La gestion des paramètres du registre avec PowerShell peut être compliquée (du moins avec le fournisseur de registre natif). À mon avis, Microsoft s'est trompé en faisant des valeurs de registre des "propriétés" plutôt que des éléments réels. Cela rend les choses beaucoup plus complexes qu'elles ne devraient l'être. 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.

2. Il existe un grand nombre de tâches d'administrateur système "de base" que vous ne pouvez pas effectuer nativement dans PowerShell (par exemple, la création d'un raccourci, la gestion d'une tâche planifiée). Vous devez invoquer Wsh, le .Net Framework ou utiliser un module tiers.

3. scripts s'exécutent au démarrage/à la connexion uniquement. Pas de rafraîchissement en arrière-plan (sauf si vous configurez une tâche programmée).

4. Si vous devez faire appel à des utilitaires de commandes Windows (net.exe, schtasks.exe), il peut être difficile d'appeler la commande, et encore plus difficile de faire en sorte que son affichage à l'écran soit compatible avec celui de PowerShell. Il se peut que vous ayez une commande qui échoue et que vous ne le sachiez pas.

Quelques autres commentaires généraux sur les scripts (PowerShell ou autre) par rapport aux GPO :

1. Les scripts sont en fait des projets de programmation. Le code sera grandissent et deviennent plus complexes au fil du temps. Si vous ne le traitez pas comme un "vrai" projet de programmation, avec des commentaires, un historique des versions, des sous-routines, etc. sera se transformer en un fouillis impossible à entretenir que votre successeur finira par mettre au rebut parce qu'il ne l'a pas compris.

2. Les administrateurs système ne sont (généralement) pas des programmeurs. Ils ne connaissent pas les disciplines de programmation appropriées (voir point 1). Même un code bien structuré peut être intimidant et illisible pour un administrateur qui n'a pas de connaissances en programmation. Soyez attentif aux compétences de votre personnel actuel et futur.

3. Les scripts ont un avantage dans la mesure où ils peuvent être vérifiés dans le contrôle de version et diffed. Avec les GPOs, c'est un peu plus difficile à faire.

4. Les scripts sont plus faciles à copier sur une clé USB et à emporter avec soi. C'était probablement le cas pour votre entrepreneur. Il avait probablement des scripts existants provenant de projets précédents qu'il a pu recycler pour votre projet. Dans mon environnement, j'ai deux réseaux qui sont air-gapped (ne demandez pas), mais qui ont des configurations similaires, donc nous utilisons des scripts PowerShell partout où cela est possible afin de pouvoir recycler le code entre les deux réseaux.

5. Les GPO ont un avantage : vous pouvez utiliser des outils tels que 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.

6. Les GPO sont plus "découvrables". Je peux arriver dans un environnement non familier et me mettre assez rapidement au courant des politiques et des paramètres appliqués. Avec un script, je dois commencer à étudier le code et espérer qu'il est bien commenté.

7. Remoting PowerShell peut être très pratique pour une commande unique que vous voulez exécuter sur un grand nombre de systèmes, et vous ne voulez pas que ce soit une politique "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 devez documenter les choses à l'étape micro -("Mise en œuvre du paramètre x pour tous les postes de travail de la comptabilité afin de résoudre le problème de l'application y"), mais aussi au niveau de l'utilisateur. macro -level ("Tous les paramètres de notre poste de travail sont stockés dans la GPO appelée x").

ÉDITION DE SUIVI : PowerShell 4 ajoute une nouvelle fonctionnalité appelée Configuration de l'état souhaité . Il semble qu'il puisse être utilisé pour réaliser 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 cool.

ÉDITION DE SUIVI 2 : Je me suis rendu compte que je n'avais pas bien fait la différence entre Politique de groupe Politiques vs Préférences . Les préférences sont à peu près analogues à un script PowerShell. Les politiques sont un peu plus "rigides", et sont plus délicates à mettre en œuvre dans un script. Pour ce faire, vous devez faire en sorte que votre script remplisse HKLM \Software\Policies mais vous devez faire attention aux collisions avec les GPO. Dans ce cas, faites l'un ou l'autre, pas les deux.