mardi 27 décembre 2011

Unleash the Power of MDT2010/2012 – Part 9 : UserExit Scripts

on_the_road_by_phanox

Il est possible d’ajouter vos propres fonctionnalités à la séquence customsettings.ini d’MDT. Pour cela il existe la fonction UserExit.

Cette fonction permet d’utiliser des scripts qui interagissent avec Customsettings.ini, c’est-à-dire qu’ils peuvent récupérer les variables de customsettings.ini, mais également les modifier. Et en sens inverse Customsettings.ini peut appeler directement les nouvelles fonctionnalités contenues dans le script UserExit est en récupérer les résultats.

A quoi cela peut-il servir ?

  • Toute les opérations qui nécessite d’effectuer des tests avant de savoir si on va ’installer tel ou tel composant peuvent se faire via cette fonctionnalité.

  • Toutes opérations qui a besoin d’effectuer un traitement spécial sur une chaine de caractère, d’aller lire ou écrire dans un fichier peuvent également se faire via UserExit.

  • Tout ce que vous pouvez imaginer !

Voici quelque exemple glanés sur le net :

Michael Niehaus l’utilise pour retrouver les différents types de modelés de la marque Lenovo qui ne sont jamais identique pour un même model.

Michael Murgolo l’utilise pour récupérer le fuseau horaire défini sur une machine source afin de configurer ce même paramètre sur la machine de destination.

Chris Nackers l’utilise pour choisir entre différentes Task Sequence en fonction de la quantité de ram trouvée.

Johan Arwidmark l’utilise pour modifier dynamiquement le serveur WDS auquel il doit se connecter.

Pour l’implémenter, ajouter la commande suivante dans vos rules(customsettings.ini) :

UserExit = MyCustomscript.vbs

MyCustomeScript.vbs étant un script dans lequel vous avez créé une ou des fonctions que vous appelez directement depuis les rules en y ajoutant des ‘#’.

Imaginons que votre script comprenne une fonction nommé ModifyComputerName() dont le but serait de couper tout nom qui ferait plus de 8 caractères, elle sera appelable simplement de la façon suivante MaVariable=#ModifyComputerName()#

Evidement, comme c’est une fonction, vous pouvez y passer des paramètres, et notamment n’importe quel variable d’MDT en y ajoutant des ‘%’. Ce qui donne par exemple MaVariable=#ModifyComputerName(%OSDComputerName%)#

Le résultat retourné par la fonction peut être utilisé pour modifier directement une variable d’MDT, dans notre cas, nous pourrions écrire ceci dans les rules pour que le nom modifié soit pris en compte : OSDComputerName=#ModifyComputerName(%OSDComputerName%)#

Enfin, vous pouvez passer directement une commande vbscript au sein de vos rules en la mettant entre des ‘#’ : OSDComputerName=#Left("%OSDComputerName%", 4)#

Voila, vous connaissez maintenant les principales fonctionnalités des scripts UserExit. Je vous parlerez dans le prochain épisode de ce qu’ MDT est capable de faire avec WinPE.

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

Unleash the power of MDT 2010/2012 – Part 1 : Présentation
Unleash the power of MDT 2010/2012 – Part 2 : Tests & logs
Unleash the Power of MDT 2010/2012 – Part 3 : Securité
Unleash the Power of MDT 2010/2012 – Part 4 : CustomSettings.ini
Unleash the Power of MDT 2010/2012 – Part 5 : Applications
Unleash the Power of MDT 2010/2012 – Part 6 : SQL Database
Unleash the Power of MDT 2010/2012 – Part 7 : Web Services
Unleash the Power of MDT 2010/2012 – Part 8 : Scripts VBS
Unleash the Power of MDT 2010/2012 – Part 9 : UserExit Scripts
Unleash the Power of MDT 2010/2012 – Part 10 : WinPE

lundi 26 décembre 2011

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

19

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 :


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

mdt pause

Dans la fenêtre de droite, dans le champs commande saisissez Cscript.exe LTISuspend.wsf

image

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” :


Unleash the power of MDT 2010/2012 – Part 1 : Présentation
Unleash the power of MDT 2010/2012 – Part 2 : Tests & logs
Unleash the Power of MDT 2010/2012 – Part 3 : Securité
Unleash the Power of MDT 2010/2012 – Part 4 : CustomSettings.ini
Unleash the Power of MDT 2010/2012 – Part 5 : Applications
Unleash the Power of MDT 2010/2012 – Part 6 : SQL Database
Unleash the Power of MDT 2010/2012 – Part 7 : Web Services
Unleash the Power of MDT 2010/2012 – Part 8 : Scripts VBS
Unleash the Power of MDT 2010/2012 – Part 9 : UserExit Scripts
Unleash the Power of MDT 2010/2012 – Part 10 : WinPE

vendredi 23 décembre 2011

jeudi 22 décembre 2011

Patch Management : Gestion des KB “superseded”

 

WindowsUpdatePetit billet rapide pour vous communiquer une information qui peut changer votre vie (qui sait si ça ne sauvera pas également votre mariage vacillant…).

Vous avez surement déjà dû faire face à cette situation :

Vous gérez manuellement un certain nombre de KB (patch de sécurité Microsoft) pour l’image de votre master, et pour garder une certaine cohérence à l’ensemble, vous souhaitez supprimer les KB “superseded”, c’est à dire les KB que des patchs plus récents ont rendu obsolète…

Derrière cette idée toute simple, une vraie crise de nerf peut vite vous envahir si vous ne savez pas où aller chercher l’information. Mais tranquillisez-vous, vous êtes au bon endroit !

Microsoft maintient à jour une page qui contient toutes ces informations (oui cette page existe), et qui pour une raison qui m’échappe est assez peu connu…

le bonheur est ici : http://support.microsoft.com/kb/894199/en-us

Vivez éternellement !!!