Vous pouvez créer vos propres VB-scripts pour faire faire à MDT à peu près tout ce que vous voulez. La version 2012 vous permet également de le faire en Powershell, mais nous n’aborderons pas le point dans ce billet.
Afin de faciliter vos développements, MDT dispose d’une architecture qui peut prendre en charge pour vos scripts des fonctionnalités telle que la gestion des erreurs ou la gestion des variables MDT.
l’utilisation des scripts peut se faire à différents endroits :
- soit en tant que tâche particulière dans une Task Sequence.
- soit en tant qu'application.
- soit en tant que ‘UserExit script’ dans customsettings.ini.
Je vous présenterai les ‘UserExit Script’ dans un prochain billet, en attendant, voici comment lancer les scripts depuis une tâche ou une application :
Cscript CHEMIN\MonScript.wsf /DebugCapture
- Dans cet exemple, le chemin du script peut varier en fonction de l’endroit ou vous l’avez sauvegardé. Si vous l’avez mis dans le répertoire Scripts, le chemin sera %scriptroot%\MonScript.wsf Si il est dans le répertoire application, le chemin sera alors %ResourceDrive%\Applications\MonAppli\MonScript.wsf
- L’option /DebugCapture permet de rendre les messages d’erreurs loggués par MDT plus lisible, en effet, si une erreur est trouvée dans un de vos script, MDT ne vous précisera pas à quelle ligne ni avec quelle variable. L’option /DebugCapture introduite dans la version 2010 permet de rétablir cette facilité.
Template
Pour pouvoir exploiter les ressources d’MDT de façon optimal, il est recommandé de ne pas utiliser directement de fichiers .VBS, mais plutôt des fichiers .WSF
Quel est l’avantage ? Les fichiers .WSF permettent d’inclure d’autre vbscripts et d’accéder à leurs fonctions. Ils vous permettent également de faire cohabiter dans un même fichier Vbscript et Javascript.
Pour vous faciliter la tâche, un Template contenant les principales informations utiles à l’exploitation d’ MDT a été crée :
1: <job id=”MyScriptJob”> 2: <script language=”VBScript” src=”ZTIUtility.vbs”/> 3: <script language=”VBScript”> 4: 5: Option Explicit
6: RunNewInstance 7: 8: ‘//—————————————————————————-9: ‘// Global Constants
10: ‘//—————————————————————————- 11: 12: Const ANSWER_TO_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42
13: 14: ‘//—————————————————————————-15: ‘// Main Class
16: ‘//—————————————————————————- 17: 18: Class ScriptName
19: 20: ‘//—————————————————————————-21: ‘// Global constant and variable declarations
22: ‘//—————————————————————————- 23: 24: Dim iRetVal
25: 26: ‘//—————————————————————————-27: ‘// Constructor to initialize needed global objects
28: ‘//—————————————————————————- 29: 30: Private Sub Class_Initialize
31: 32: End Sub
33: ‘//—————————————————————————- 34: ‘// Main routine 35: ‘//—————————————————————————- 36: 37: Function Main
38: 39: ‘Insert your code here 40: 41: End Function
42: 43: End Class
44: 45: </script> 46: </jobPour adapter le Template à vos besoins, modifiez le de la manière suivante :
Ligne 1 : remplacez la valeur du job ID par un nom rappelant à quoi sert votre script, ce nom sera reprit dans les fichier de logs.
Ligne 18 : remplacer la valeur de la class en utilisant exactement le même nom que vous avez utilisé pour sauver votre script : si votre script s’appelle MonSuperScript.wsf, alors la ligne 18 s’écrira de la façon suivante : Class MonSuperScript.
Lignes 24 : Déclarez vos propres variables.
Ligne 39 : Insérez votre code à partir d’ici.
Objets et fonctions prédéfinis
Comme vous l’avez constaté, le script fait appel à un autre script à la ligne 2. Il s’agit de ZTIutiliy.vbs. Ce script initialise l’environnement MDT et va référencer plusieurs objets qui vous serviront dans vos propres développements.
parmi ces objets :
- oFSO – File System Object
- oShell – Wscript Shell Object
- oEnv – Process Environment Object
- oNetwork – WScript Network Object
- oUtility – Fonctions additionnelles d’MDT
Vous disposez également de fonctionnalités de logging, c’est à dire que vous pouvez directement écrire les informations qui vous semblent importantes dans le fichier C:MININT\BDD.log
l’implémentation s’effectue de la manière suivante :
- oLogging.CreateEntry “L’installation est reussi”, LogTypeInfo pour écrire un message informatif (apparait sur fond blanc dans trace32), ou
- oLogging.CreateEntry “Houston nous avons un problème !!!”, LogTypeError pour écrire un message d’erreur (apparait sur fond rouge dans trace32).
Vous pouvez accéder à l’ensemble des variables d’environnement de Windows:
- MaVariable = oEnv(“windir”) renvoie la valeur de la variable %Windir% soit C:\Windows
Mais également à l’ensemble des variables d’MDT :
- MaVariable = oEnvironment.Item(“OSDComputerName”) renverra la valeur OSDComputerName que vous avez définie dans vos Rules (customesettings.ini).
- Par ailleurs, rien ne vous empêche d’utiliser la fonction dans l’autre sens pour déclarer ou modifier les variables d’MDT soit : oEnvironment.Item(“OSDComputerName”) = “MyBigFatPC”
Comme, je vous l’ai expliqué, ces fonctionnalités sont la conséquence directe de l’inclusion de ZTIutility.vbs dans votre script, notez bien que vous n’étés pas limité à cette unique inclusion et que vous pouvez ajouter tous les autres scripts provenant d’MDT dont vous auriez besoin d’exploiter une fonction.
Dernier détail, selon l’endroit ou vous placez vos scripts, la ligne 2 est à modifier de la façon suivante :
- Si votre script se trouve dans le même répertoire que ZTIUtility : <script language="VBScript" src="ZTIUtility.vbs"/>
- Si votre script se trouve dans le sous-répertoire application\MonApplication : <script language="VBScript" src="..\..\ZTIUtility.vbs"/>
Environnements de test
La partie la plus problématique ici, est de pouvoir s’affranchir de relancer une installation complète pour tester ces scripts tout en bénéficiant des variables et fonctions fournies par MDT.
Plusieurs méthodes existent, vous aurez probablement à les utiliser toutes en fonction de la fasse de test ou de déploiement dans laquelle vous vous trouvez…
1 – le custom Script
J’ai déjà décrits cette méthode dans un précèdent billet. L’idée étant de lancer une Task Sequence ne contenant que vos propres scriptes sur une machine se trouvant sur le même nœud réseau qu’ MDT.
2 – La pause au milieu d’un déploiement.
Vous pouvez grâce au script LTISuspend.wsf mettre momentanément en pause votre séquence de déploiement via l’ajout d’un simple script. Cet état vous place dans les conditions idéales pour tester vos scriptes :
- le Deployments Share est connecté
- les variables d’environnement MDT sont initialisées
- Le tout s’exécute avec droits d’admin.
Ajoutez le script à votre Task Sequence de la manière suivante :
Choisissez un endroits stratégique pour faire votre pause (Avant ou Après l’installation d’application est un bon compromis) et cliquez sur dans le menu sur ADD>General>New Command Line
Dans la fenêtre de droite, dans le champs commande saisissez Cscript.exe LTISuspend.wsf
Votre Task Sequence va maintenant s’arrêter juste après avoir installer vos applications, c’est le moment de tester qu’elles se sont toutes installées correctement, mais c’est surtout le moment de vous connecter à vos scriptes personnels sur le Deployment share (mappé automatiquement sur la lettre Z) et de les tester :
Si vos scripts sont stockés dans votre répertoire application ; ouvrez une invite de commande et tapez les commande suivantes :
Z:
cd z:\applications\MonAppliScriptATester
cscript MonScriptPerso.wsf /debugcapture
3 – Le bac à sable
probablement la méthode la plus simple à mettre en œuvre pour tester vos scripts ; le bac à sable ! Dans un simple répertoire nous allons copier les principaux scripts d’MDT ainsi que nos scripts personnels. Puis en lançant l’environnement d’MDT nous pourront initialiser ces variables avant de tester/exécuter nos propres scripts.
Depuis le dossier : C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Scripts
copiez dans un dossier de votre choix les scripts suivant :
- ZTIGather.wsf
- ZTIGather.xml
- ZTIUtility.vbs
- ZTIDataAccess.vbs
Depuis le répertoire DeploymentShare\Control, copier le fichier customsettings.ini
Depuis DeploymentShare\Tools\x64 ou x86 en fonction de votre OS, copiez le fichier Microsoft.BDD.Utility.dll que vous replacerez dans un sous-répertoire x86 ou x64 au sein de votre répertoire bac à sable de destination.
Enfin, ajoutez au répertoire bac à sable tous les scripts que vous souhaitez tester.
une particularité à ne pas oublier lorsque vous tester dans ce mode : modifier dans vos scripts WSF le chemin d’appel au script ZTIUtility.vbs ligne 2 qui doit alors s’écrire : <script language="VBScript" src="ZTIUtility.vbs"/>
L”exécution se déroule de la manière suivante :
Dans votre répertoire bac à sable, ouvrez une invite de commande en mode administrateur.
- Créez vous un fichier batch, par exemple Gather.cmd, et copiez-y le code suivant :
If exist C:\MININT\Nul rd C:\MININT /s /q
Cscript ZTIGather.wsf
- lancez Gather.cmd,vous allez ainsi initialiser l’environnement et les variables d’MDT.
- lancez ensuite vos propre scripte par la commande Cscript MonScript.wsf /debugcapture
Voila, avec tout cela, vous devriez être capable de développer dans des conditions optimales… Prochain billet sur les “UserExit” scripts.
Jeu de briques
Snake
Pacman
Bubble