Le petit monde de Zany & Open Eyes: Unleash the Power of MDT2010/2012

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: </job

Pour 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.

Retrouvez-ci dessous l’ensemble des billets de la série “ Unleash the power of MDT2010/2012” :

Le petit monde de Zany & Open Eyes

lundi 26 décembre 2011

Unleash the Power of MDT2010/2012 – Part 8 : Scripts VBS

Template

Objets et fonctions prédéfinis

Environnements de test

Aucun commentaire:

Enregistrer un commentaire

Archives

BlogRoll

Billets les plus populaires