« Toucher » une stratégie de groupe de déploiement logiciel de manière programmatique ou via un script

J’ai une application interne qui utilise Windows Installer. Chaque mise à jour de cette application est une « mise à niveau majeure » (code produit différent, même code de mise à niveau) et elle appelle RemoveExistingProducts. (En effet, cela signifie qu’à chaque fois qu’une nouvelle version est créée, vous pouvez l’installer en cliquant simplement sur le fichier MSI, puisqu’il désinstallera l’ancienne version puis installera la nouvelle.)

Elle est actuellement déployée via une configuration machine dans la stratégie de groupe. Toute GPO liée installera le logiciel au prochain démarrage, et cela fonctionne très bien.

J’ai également un serveur d’intégration continue (TeamCity) qui compile et exécute les tests pour ce logiciel chaque fois que nous validons quelque chose dans le contrôle de source et le « marquons » pour déploiement. Je peux même copier le fichier MSI fraîchement compilé sur le partage réseau en préparation du déploiement.

Malheureusement, je ne vois pas de moyen d’indiquer à la GPO de redéployer le fichier MSI nouvellement mis à jour de manière programmatique dans le cadre de mon processus d’intégration.

Si j’écrase simplement le fichier MSI existant sans toucher à la GPO, le changement n’est pas remarqué par les machines qui ont l’ancien MSI installé, et les nouvelles machines paniquent lorsqu’elles ne trouvent pas le fichier MSI avec le code produit dans le script généré par l’éditeur de gestion des stratégies de groupe. D’accord, c’est logique.

Le même comportement semble se produire si j’écrase simplement le fichier MSI existant et clique sur “Redéployer l’application” dans GPME. Encore une fois, nous semblons mécontents de tenter un redéploiement avec un fichier MSI dont le code de package ne correspond pas à celui du script généré par GPME. D’accord, c’est logique.

Ce qui fonctionne, c’est de faire un clic droit sur le package d’installation dans GPME, cliquer sur “Supprimer immédiatement”, puis rajouter le package d’installation – cela crée un nouveau script *.aas et l’ancien package est supprimé et le nouveau installé au prochain démarrage. Existe-t-il un moyen de faire cela via un script batch que je pourrais ajouter au processus de compilation de mon serveur d’intégration ?

Merci !

Mise à jour de suivi

Après avoir examiné les remarques d’Evan, j’ai fini par écrire un petit script batch qui s’exécute au démarrage. J’ai également écrit un petit utilitaire appelé msicheck qui détermine si un package MSI donné est installé. Cela répondait suffisamment à mes besoins, et c’est bien mieux que de parcourir des pages de spécification LDAP ! =)

J’ai eu le désir de faire quelque chose de similaire et j’ai fait quelques recherches sur le sujet par le passé.

Il n’y a pas d’API exposée que j’ai pu trouver pour faire ce que l’éditeur de stratégie de groupe fait pour créer ces fichiers de script de publication d’application (.aas) et les enregistrements correspondants dans AD. L’API PowerShell de stratégie de groupe vous permet de configurer des paramètres basés sur le registre, mais pas des paramètres pour d’autres extensions de stratégie de groupe.

Il existe maintenant une référence au Group Policy Software Installation Protocol Extension (merci au règlement antitrust de l’UE !) et je suppose que vous pourriez essayer de créer un moteur pour effectuer les assignations vous-même. Les transactions LDAP nécessaires pour effectuer l’ajout du package et le format des fichiers .aas sont dedans. Cela semble un peu intimidant (mais amusant)…

Franchement, votre souci du détail concernant les tests de déploiement est à saluer. J’aimerais que vous écriviez des logiciels que mes clients utilisent. Le fait que vous utilisiez Windows Installer seul vous met en avance sur le peloton. Que vous connaissiez le déploiement de logiciels par stratégie de groupe et que vous le testiez réellement me ravit ! J’aimerais qu’une fraction mesurable des développeurs se soucie autant que vous visiblement le faites.