Scripting et déploiement d’applications (Série AppScript-X)

I. Présentation

 

L’idée de cet article consiste à vous présenter quelques techniques d’intégration des applications dans vos processus de déploiement. En effet, dans mon article http://www.it-connect.fr/mdt-integration-dapplications/ je vous présentais les rudiments pour la mise en œuvre de ces techniques mais je n’avais pas étayé mes propos  avec quelques exemples concrets. Je vais donc essayer d’y remédier en exposant quelques retours d’expérience sur ce vaste sujet

Je ne reviendrais par sur la notion d’application dont les capacités d’automatisation reste inhérentes à chaque éditeur et je me contenterais de proposer des techniques de « pilotage » des processus d’installation, que vous pourrez ensuite intégrer dans vos séquences de taches MDT ou vos propres scénarios de déploiement.

Dans la mesure du possible, j’essaierais de vous proposer une technique pour les 3 principaux langages de script sous Windows, que sont le batch, le vbscript et bien-sûr Powershell, mais cela n’exclut pas le recours à d’autres solutions telles que Auto-IT ou variantes.

 

II. Concevoir une structure de script

Bien que l’usage d’un langage de script unique ne soit pas impératif, (.bat, .vbs, .ps1…) il est souhaitable de commencer par définir une structure cohérente et réutilisable afin que les méthodes d’installation restent homogènes et plus facile à maintenir.

Toutefois, pour de nombreuses raisons, il est difficile de vous livrer un exemple ou un modèle de script qui corresponde parfaitement à votre besoin. J’ai donc opté pour une approche modulaire des différents points que je vais vous présenter Cette méthode permettra d’accéder plus efficacement aux différentes parties en fonction de vos intérêts, et pour ma part d’en maitriser l’avancement.

A. Récupérer le dossier courant

Comme vous pouvez l’imaginer, l’objectif de ce sujet est de présenter quelques techniques de détection du répertoire de travail d’un script.

_CurrentFolderPour le détail, c’est ici

B. Détecter l’architecture pour les packages mixtes x86/x64

Il est toujours possible de créer des scripts indépendants pour des packages d’applications dont l’architecture est différente mais il me semble plus élégant, lorsque le cas se présente, de les regrouper au sein d’un même script qui fera la distinction.

_32-64bitPour le détail, c’est ici

C. Définir un journal d’installation

Comme vous vous en doutez, la consignation des erreurs ou informations lors de l’exécution d’un script est fondamentale mais souvent négligée (On y pense que lors de la maintenance ou qu’il y a des problèmes, n’est-ce pas ?)

_LogPour le détail, c’est ici 

D. Gérer les codes retour

Dans la même logique que celle d’un journal de suivi d’installation, il convient de prendre en considération les éventuelles erreurs ou l’absence d’anomalie afin d’enchaîner correctement les opérations.

_Return_CodesPour le détail, c’est ici

E. Attendre la fin des processus

C’est à mon avis, un point incontournable pour la maîtrise de l’enchaînement des différentes opérations. Cette gestion est généralement prise en charge par les solutions d’ordonnancement, mais en matière de scripting, cela constitue un point de vigilance pour garantir un déroulement de vos installations automatisées.

Les méthodes consistant à intégrer des boucles d’attente arbitraires sont à proscrire.

Wait-ProcessPour le détail, c’est ici

F. Facultatif : Informer de la progression

Cette étape n’est pas cruciale, mais pour les processus d’installation relativement longs, il peut être intéressant d’ajouter une indication de progression. Dans certains cas de traitement parallèle, il faut également traiter des processus d’arrière-plan.

_ProgressPour le détail, c’est ici 

G. Facultatif : Mesurer la durée d’exécution

Il est parfois intéressant de prendre en compte les temps d’exécution, particulièrement en matière d’évaluation des performances. Certes, des outils existent, mais une mesure régulière, consignée dans les journaux peut éventuellement servir à mesurer certaines dérives. Cette approche s’applique plus à des scripts récurrents qu’a des scénarios d’installation mais au cas où …

ChronoPour le détail, c’est ici (Prochainement disponible)

H. Facultatif : tester la présence des prérequis

Cette étape est une bonne pratique au même titre que le contrôle du contexte (architecture, privilèges…). Les prérequis d’une application peuvent prendre différentes formes, telles que des composants système, des correctifs particuliers (KB), la version du système ou d’un produit, voire la présence ou bien l’absence d’une autre application.

_PrerequisitesPour le détail, c’est ici 

I. Facultatif : Tester si le niveau de privilège nécessaire à une installation

Vous n’êtes pas sans savoir que les opérations d’installation ou de configuration d’un système Windows nécessitent des privilèges. Toutefois, depuis Vista, en raison de l’UAC (Contrôle de compte d’utilisateur) vous savez que l’appartenance à un groupe Administrateur n’est pas suffisante pour garantir un niveau de privilège nécessaire à une installation. Quelques techniques de script peuvent vous assurer ce contrôle.

_IsAdminPour le détail, c’est ici 

 


 

J. Autre thème à venir…

En fonction de mon courage et de ma motivation, je vous proposerais peut être une suite sur la gestion des packages MSI/MST/MSU. Certes, le sujet sort quelque peu de la thématique du scripting, mais lui est également régulièrement associé.

 

III. Lancement des scripts

Pour garantir une bonne exécution des scripts indépendamment des contextes, il est souhaitable de stipuler l’interpréteur utilisé et quelques paramètres.

Icon_BAT

 

Pour les batches, l’interpréteur est « CMD.exe » (situé dans %windir%\system32 et/ou %windir%\sysWOW64) mais vous pouvez aussi le référencer par la variable d’environnement « %COMSPEC% ». L’usage de commutateurs est plutôt rare pour lancement d’un .bat ou d’un .cmd, mais vous pouvez consulter l’aide « cmd /? » pour les connaitre. Donc généralement, le lancement s’effectue ainsi

%COMSPEC% /C .\MonScript.bat

 

Icon_VBS

Pour les scripts vbscript, nous disposons de 2 interpréteurs « CSCRIPT.exe » et  « WSCRIPT.exe« , également déclinés en 32 et 64 bits. Le premier, en mode console, est généralement préférable dans les opérations d’installation, du fait qu’il simplifie la gestion des affichages.

Note : Si vous souhaitez bénéficier du débogueur intégré sur les systèmes 64 bits, je vous conseille d’utiliser l’interpréteur 32 bits situé « %windir%\sysWOW64 » sous  (cf http://cnf1g.com/?p=721 )

La encore, vous pouvez consulter l’aide « cscript /? » ou « cscript /? » pour connaitre les commutateurs. Dans la plupart des cas, le lancement s’effectue ainsi :

%windir%\system32\cscript.exe //nologo .\MonScript.vbs

 

Icon_PSH

 

Pour les scripts Powershell, les options sont implicitement plus nombreuses. En effet, vous savez probablement que cet interpréteur est soumis à des restrictions  (cf « Get-ExecutionPolicy / Set-ExecutionPolicy »), qui interdisent par défaut l’exécution des scripts.Le second « risque » porte sur la notion de profil qui peut interférer avec le script.

Une fois de plus, vous pouvez consulter l’aide « powershell /? » pour connaitre les commutateurs disponibles. Dans la plupart des cas, le lancement s’effectue ainsi :

powershell.exe -ExecutionPolicy bypass -NoProfile -NoLogo -File .\MonScript.vbs

Pour rappel,  si vous souhaitez préciser le chemin du moteur Powershell, celui-ci est situé sous « %windir%\system32\WindowsPowerShell\v1.0 », et pour sa déclinaison 32 bits/ Windows x64, vous le trouverez sous :  « %windir%\sysWOW64\WindowsPowerShell\v1.0 »

 

Bonne lecture.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *