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 !!!

vendredi 30 septembre 2011

Unleash the Power of MDT 2010/2012 – Part 7 : Web Services

bata486

MDT à la possibilité de collecter des information en utilisant un Web Service.

Un Web Service est un site web qui lorsqu’on lui envoie une requête via une URL, répond en renvoyant les informations sous la forme d’un Blob XML (ni plus, ni moins les données demandées formatée en XML).

Les données du Blob sont alors exploitables par MDT et peuvent êtres mises dans des variables.

Un web service peut être très pratique pour, par exemple : aller rechercher une information dans Active Directory ou une base SQL afin de configurer une machine en conséquence.

Le problème c’est que si aucun Web Service n’a été développé dans votre entreprise, alors, c’est qu'il n’en existe pas !

Quelque solutions pour vous faire la main existent  cependant:

Vous pouvez installer le Web Service de Maik Koster qui vous permettra non seulement de demander des informations sur la Base Active Directory, la database de MDT et celle de SCCM, mais également d’aller y écrire vos propres données.

Imaginez : vous souhaitez changer une machine d’OU..Hop ! une petite requête via le web service et le tour est joué. C’est beaucoup plus simple que d’avoir à utiliser les utilitaires classique (Tuto. de mise en place ici !).

Vous pouvez également utiliser des Web Services publique gratuit. Evidement leur intérêt est moindre dans la mesure ou les données qu’ils renvoient sont peut utiles lors d’un déploiement : Vous pouvez par exemple récupérer les donnée météorologique de votre ville, ou envoyer un code postal est recevoir ne nom de la ville en retour… l’intérêt reste donc limité mais vous permettra malgré tout de tester cette fonctionnalité MDT sans avoir à développer quoi que ce soit.

voici deux adresses pour vous faire la main :

La récupération de Blob XML est extrêmement simple et se configure via les Rules ; en indiquant l’URL du Web Service, et le sujet de la requête :

[Settings]
Priority=Default, Zip
Properties=USZip, City, State, Area_Code, Time_Zone

[Default]
USZip=98029

[Zip]
webService=http://www.webservicex.net/uszip.asmx/GetInfoByZip
Parameters=USZip

Les Propriétés City, State, Area_Code et Time_Zone seront automatiquement utilisées pour contenir les réponses du Web Service.

Ces Propriétés correspondent aux balises XML qui seront renvoyées dans la réponse :

xml blob

Vous pouvez, comme nous l’avons vu précédemment ; tester vos requetés sans avoir à lancer un déploiement complet :

Ouvrez une invite de commande en mode administrateur dans le sous répertoire Scripts de votre Deployment Share, et tapez :

Cscript ZTIGather.wsf /inifle:..\control\CustomSetting.ini

MDT va alors procéder à la collecte des informations du système ainsi que celle du Web Service. Vous pourrez constater que les données ont bien étés récupérées lors de l’exécution du script :zipcode

Ou dans les logs d’MDT dans C:\minint\smsosd\osdlogs\bdd.log (Utilisez Trace32 ou Trace64 pour clarifier la lecture.)

Voila, vous pouvez dés à présent utiliser les resultats de vos requetés comme des variables classique d’MDT, et les utiliser dans vos Rules, vos scripts et vos Task Sequence.

Notez également qu’MDT supporte les Web Services en HTTPS et qu’il est possible de spécifier des login/mot de passe pour s’y connecter.

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

Unleash the Power of MDT 2010/2012 – Part 6 : SQL Database

images-istockphoto-iStock_000006412772XSmall-database

Sixième épisode consacré à l’ajout d’une base de donnée à MDT :

Les Rules d’MDT (customsetting.ini) sont statiques, et permettent peu d’interaction avec un script ou une source de donnée externe. L’ajout d’une base SQL à MDT va rendre vos déploiements beaucoup plus dynamique, et permettre de définir les configurations pour un parc complet de machines en fonction de 4 grands critères :

  1. Ordinateurs: En fonction de la Mac adresse/UUID/Numéro de série du PC ou Asset Tag vous pourrez définir une configuration particulière.
  2. Location : Vous pourrez créer des configuration différentes en fonction de la localisation géographique des PC (Défini en fait, par l’adresse de sous réseau dans lequel se trouve la machine.)
  3. Make & Model : En spécifiant la marque et/ou le model du PC cible, vous pouvez définir des paramétrage qui incluent par exemple les drivers du dit model.
  4. Role : Définissez des rôles “métier” à vos machines. Ainsi, les machines des commerciaux recevront une config différentes de celle des ressources humaine…

En dehors du fait d’avoir installé et configuré la base SQL, les prérequis d’utilisation sont les suivant :

  • Maintenir une connexion réseau constante entre la base de donnée et le partage de déploiement dans le cas ou ils ne se trouveraient pas sur la même machine.
  • Etre propriétaire de de l’instance (db_owner) utilisée par MDT.

Vous n’êtes pas non plus obligé d’installer un nouveau serveur SQL. Si vous avez déjà un serveur SQL/SQL Express sur votre réseaux. Indiquez à MDT le nom du serveur ainsi que le nom de la base initiale est MDT créera une nouvelle instance sans altérer vos autres bases.

Vous retrouverez toutes les informations nécessaire à l’Installation/configuration de SQL Server Express pour MDT dans ce billet.

 

Optimisation des bases pour les requêtes

Il est important de savoir avec précision quels sont les informations qui vous sont vraiment nécessaires avant qu‘MDT ne lance ces requêtes sur la database, vous éviterez ainsi de ralentir vos déploiement inutilement.

Le choix des tables qui seront traités par la requête sont défini dans MDT en cliquant sur : Deployement share>Advanced>Bouton droit sur Database puis Configure Database rules.

DBrulesCFG_thumb2

Cette action, une foie complétée, va remplir le fichier CustomSettings.ini avec les paramètres nécessaire pour interroger chacune des tables que vous aurez choisi.

db rules

Voici quelques exemple pour optimiser vos requêtes :

Sur chacun des quarte critères précités, vous pouvez vous affranchir des SMS Packages si vous n’utilisez pas SCCM et des Assigned Administrators si toutes les machines du parc sont gérées par les même groupe d’administrateurs.

vous pouvez également vous passer du critère Location et ne rien y configurer si vous n’avez pas de sous réseau qui nécessite de configuration particulière (langue différentes par exemple ou application spécifique à une succursale).

Pour que cela soit le plus claire possible, voici quelque exemples d’implémentation pour chacune des options :

Pour Computer Options, sélectionner les requêtes :

  • Computer specific settings : pour préconfigurer, les noms des PC, leur résolution d’écran, une adresse ip statique etc..
  • Role assigned : pour dire ; ce PC fait partie de la compta, il aura toutes les applications définie dans le rôle compta !

Pour Location Options, dans le cas ou vous avez des agences annexe,sélectionner les requêtes :

  • Location Name : pour défini le sous réseau en 10.133.5.0 comme étant votre agence à Madrid
  • Location specific setting : pour que les machines sur Madrid reçoivent les paramètres linguistique appropriés.
  • Applications to be installed  : pour que les applications de R&D spécifiques à cette agence soient installés.

Pour Make/Model Options, sélectionner les requêtes :

  • Model Specific settings : pour que les Probook 5210 reçoivent un paramétrage d’écran en 1400x800, alors que les Elite 830 recevront un paramétrage de 1600x1200.
  • Application to be installed : pour installer les applications constructeur spécifiques à chaque modelés.

Pour Role Options, sélectionner les requêtes :

  • Role Specific : pour définir le role “Force de vente” pour lequel Bitlocker sera systématiquement installé !
  • Applications to be installed pour que les PC forces de vente aient Bussiness Everywhere, les Pc Développeurs Visual studio…

Si au cours de votre déploiement, vous vous rendez compte que vous avez besoin d’ajouter une requête supplémentaire à celle que vous aviez précédemment configuré.Rien de plus simple : relancer ‘Configure Database Rules’ au temps de fois que vous en avez besoin. CustomSettings.ini sera automatiquement remis à jours avec les paramètres de connexion à la Database adéquate.

 

Database Debbuging

A des fin de débogage, vous avez la possibilité de savoir ce qu‘SQL à transmit comme valeurs à MDT.

Cette opération de requête sur la base s’effectue dans l’étape “Gather” de la Task Sequence qui en faite, lance un script nommé ZTIGather.wsf.

Vous pouvez donc utiliser ce script pour tester vos requêtes sans avoir à lancer une installation complète de machine.

Ouvrez pour cela une invite de commande en mode administrateur dans le sous répertoire Scripts de votre partage de déploiement, et tapez :

Cscript ZTIGather.wsf /inifle:..\control\CustomSetting.ini

une fois l’exécution terminée,vous pourrez connaitre les propriétés qu‘MDT à créer à partir de la base de donner en allant lire le fichier de log qui se trouve dans C:\minint\smsosd\osdlogs\bdd.log (Utilisez Trace32 ou Trace64 pour clarifier la lecture.)

Pensez à effacer le fichiers variables.dat à chaque fois que vous souhaitez réutiliser cette commande.

Vous pouvez utiliser cette commande même si vous n’utilisez pas de database.(Dans ce cas, les propriétés seront construites à partir de vos paramètres système, et des valeurs trouvées dans CustomSettings.ini)

Si une propriété à été defini à la fois dans la base de donnée, et dans CustomSetting.ini, MDT procèdera de la manière suivante : La première valeur lue, sera la valeur utilisé.

Exemple :

dbPriority

la priorité des tache (Priority=…) va d'abord utiliser les informations contenue dans la section [Default] puis se connecter à la database pour le reste des propriétés via la section [CSettings].

Si la propriété OSDComputerName existe au sein de la database, elle ne sera pas transmise à MDT, car elle à déjà été définie dans la section [Default].

 

Placer tout les paramètres  de CustomSettings.ini dans la database 

Vous pouvez, pour des raisons esthétiques, pratiques ou sécuritaires, vouloir que les principaux paramètres du fichier CustomSettings.ini ( les _SMSTSOrgName,  les logins/password des comptes habilités à rejoindre le domaine etc…) soit stockés et lus depuis la base de donnée.

Pour cela, créer un rôle dans la database en lui donnant un nom qui vous conviens (ici j’ai choisi myDefaultConfig).

Roledb

Dans l’onglet détails configurez les options dont vous avez besoin.

Roledb2

Enfin dans le fichier CustomSettings.ini qui ne doit normalement contenir que vos paramètres de requetés sur la database :

Ajouter dans la ligne Priority en 1er paramètre : Priority=GlobalConfig,Default

Ajouter en dessous la section correspondante avec

[GlobalConfig]
Role001=myDefaultConfig

rulesDB

 

Etendre les possibilité de la database

Le principal problème lié à la database d’MDT est sont interface peu ergonomique qui ne permet pas d’y injecter massivement des informations sans que cela ne devienne un calvaire.

Il existe cependant quelques solutions pour palier à cette lacune :

Mick Niehaus et Mitch Tulloch vous expliquent comment, grâce à des scripts Powershell, pré remplir la database avec les adresses MAC des machines à déployer.

Johan Arwidmark, vous explique comment le faire en utilisant une ‘Stored Procedure’.

Maik Koster à quand à lui, créé une interface WEB, beaucoup plus intuitive qui vous permet de vous affranchir à 100% de l’interface poussive d’MDT.

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

mardi 30 août 2011

Unleash the Power of MDT 2010/2012 – Part 5 : Applications

shippingcontainer

Dans cette 5 eme partie, vous aller apprendre comment rendre l’installation de certaines applications obligatoire :

Effectivement, vous pouvez forcer une application à s’installer, il suffit pour cela d’jouter dans les Rules (Customsettings.ini) la commande suivante :

MendatoryApplications001=<GUID d’application>

Ou <GUID Application> est le code hexadécimal unique que vous pouvez retrouver pour chaque application en cliquant propriétés sur l’une d’elle puis General> Application GUID.

Mdt--appli2011-04-19-09h25_07_thumb3

L’application apparaitra déjà cochée dans le Wizard de MDT et s’installera obligatoirement !

Il est possible de détecter si une application est déjà installée, et le cas échéant de ne pas la réinstaller une deuxième fois en spécifiant dans les propriétés, onglet Détails de l’application le Uninstall Registry Key GUID.

Le GUID se récupère dans la base de registre à l’adresse :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall pour les applications 32 bits,

et HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall pour les application 64 bits.

Pour office 2010 le GUID est Office14ProPlus

Recommandation : Si une application doit rebooter pour s’installer correctement, il est important qu’elle ne le fasse pas elle-même, mais qu’elle laisse MDT maitriser le reboot. Pour cela, l’application doit être installée avec un switch /Norestart ou équivalent. L’ordre de reboot est transféré à MDT via le bouton à cocher : Reboot the computer after installing this application (onglet Détails).

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

Unleash the Power of MDT 2010/2012 – Part 4 : CustomSettings.ini


14695844_14695844_xl

Cette partie est consacrée aux Rules de MDT. Comme le nombre d’option configurables doit dépasser la centaine, je ne reprendrais que ce qu’il y a dans la vidéo, Michael Niehaus ayant opté pour des commandes moins classique ou qui posent régulièrement des problèmes aux utilisateurs.

Les Rules sont accessibles en cliquant bouton droit sur : Deployement share>propriétés>Rules

Mdt-rulesPanel_thumb2

Les Rules définissent des propriétés qui seront partagés à tout les éléments de votre  Deployment Share, cela signifies que toutes vos Task Sequence utilisent les même Rules.

Les Rules sont stockées dans un fichier CustomSettings.ini stockée dans le répertoire ..DeplomentShare\Control

Vous pouvez ajoutez des commentaires avec le caractère “:”.

Les variables d’environnement de type %var% sont supportées.

L’ensemble des propriétés utilisables utilisables dans CustomSettings.ini sont décrites dans le fichier d’aide de MDT à la section : Microsoft deployment toolkit documentation libraire > Microsoft deployment toolkit Reference > Properties > Property Definition

De nouvelles propriétés, non incluses dans l’aide d’MDT sont également décrites ici. 

 

Voici maintenant quelques propriétés  utiles que vous pouvez y inclure.

Fichier de Logs

  • SLShare=\\mdt-server\logs : copie les logs du client dans le répertoire du serveur à la fin du déploiement.
  • SLShareDynamicLogging=\\mdt-server\log\dynamic\%ComputerName% Copie les logs en temps réel sur le serveur. (Le nom de répertoire dynamique est obligatoire pour que cela fonctionne).

Rejoindre un domaine

  • Voici les commandes à ajouter pour que votre machine puisse rejoindre un domaine  automatiquement :

JoinDomain=MonDomain.com
DomainAdmin=administrateur
DomainAdminDomain=MonDomain.com
DomainAdminPassword=P@ssW0rd
SkipDomainMembership=YES
(évite d’afficher la fenêtre pendant le déploiement)
MachineObjectOU=OU=Workstation, DC=MonDomain, DC=Com

Attention ne pas spécifier de valeur CN, cela ne fonctionne pas ! Toujours spécifier une OU et pas un conteneur !

Recommandation : le mot de passe sera écrit en claire dans le fichier CustomSettings.ini, il faut donc :

Protéger l’accès du Deployment Share en autorisant que les comptes habilités à déployer.

N’utiliser que le compte utilisateur spécial qui a les droits de rejoindre le domaine , et ne jamais utiliser le compte d’administrateur de domaine.

Si la machines déclarée existe déjà dans l’OU spécifié, elle ne sera pas mise à jour. Le compte d’ordinateur restera dans son OU d’origine est sera mis à jour au niveau du mot de passe, mais ne bougera pas !

 

Reboot

  • Voici comment spécifier un reboot à la fin de l’installation

FinishAction = Logoff
ou Reboot
ou shutdown
ou restart

Variables

  • Si vous avez besoin d’ajouter vos propres variables pour y stocker des valeurs intermédiaires. Utilisez la propriété Properties afin de les créer :

Properties=MaVariable01,MaVariable02

Puis, lorsque vous en avez besoin :

MaVariable01=OSDComputerName

 

Customsettings.ini vs Boostrap.ini

Même si les deux fichiers peuvent contenir sensiblement les mêmes informations, ils ne s’utilisent pas dans les mêmes phases et son utilisés à des endroits différents.

Customsettigs.ini. est stocké sur le partage de déploiement. Il ne sera utilisé qu’une fois que WinPE aura démarré et se sera connecté au partage de déploiement.

Bootstrap.ini est copié dans l’image WinPE lorsque vous mettez à jour votre Deployment Share.

Il contient toutes les informations nécessaire à MDT pour établir une connexion avec le partage de déploiement :

  • Le chemin UNC du partage de déploiement.
  • Les login/password pour s’y connecter.
  • La langue clavier
  • Facultatif : le skip de la page d’accueil de MDT (SkipBDDwelcome = Yes)

Lorsque vous modifiez Bootstrap.ini il est impératif de mettre à jour le partage de déploiement (Update deployment share) afin que le fichier à jour soit intégré à la nouvelle images 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

samedi 27 août 2011

Unleash the Power of MDT 2010/2012 – Part 3 : Securité

j0442310

Dans cette troisième partie, je reviens sur la manière la plus simple de sécuriser MDT sans en restreindre les possibilités. En dehors de la sécurisation du Deployment Share avec NTFS (interdictions à tout le monde sauf aux utilisateurs authentifiés). Voici quelques considérations sur les comptes utilisateurs employés pour travailler avec MDT.

Sachez, qu’Il n’est nullement besoin de disposer d’un compte administrateur de domaine pour qu’ MDT puisse déployer des postes. Vous pouvez travailler avec 2 comptes aux droits restreint :

  • Un compte utilisateur standard du domaine : pour permettre aux scripts MDT s’exécutant sur les postes client de se connecter au partage de déploiement.
  • Un compte utilisateur capable uniquement d’autoriser les machine à rejoindre le domaine.

Je ne reviens pas sur la création d’un compte standard, par contre voici les options à spécifier pour créer un compte standard capable de rejoindre un domaine :

Votre organisation dispose probablement dans Active Directory d’une OU dans laquelle sont placés toutes les machines du domaine. Nous allons travailler sur cette OU. Si vous êtes en environnement de test , créez une OU que vous pourrez nommer par exemple Workstations.

  • Créez un compte utilisateur standard, J’ai crée pour cet exemple un compte nommé MDT-Join.
  • Dans la console Active Directory cliquez sur le Menu Affichage>Fonctionnalités avancés
  • Sur votre OU, en cliquant bouton droit, sélectionnez Propriétés puis l’onglet Sécurité. Cliquez ensuite sur le bouton Avancé
  • Dans la fenêtre qui vend de s’ouvrir, cliquez sur Ajouter, et choisirez votre compte MDT-Join

cap1_thumb5

  • Dans la fenêtre Autorisation pour Workstations, faites défiler la liste pratiquement jusqu'à la fin, et cochez les autorisations de création et de suppression d’objets ordinateur. Puis validez par le bouton OK.

cap2_thumb2

  • Sur la Fenêtre Paramètres de sécurité avancés pour Workstations, cliquez à nouveau sur Ajouter en choisissant toujours le compte MDT-Join.
  • Dans la fenêtre Autorisation pour Workstations, changer le champ Appliquer à par Objets Ordinateur descendants, puis autorisez les options suivantes :
    • Lire toutes les propriétés
    • Ecrire toutes les propriétés
    • Autorisations de lecture
    • Modifier les autorisations
    • Ecriture validée vers le nom d’hôte DNS
    • Ecriture validée vers le nom principal
    • Modifier le mot de passe
    • Réinitialiser le mot de passecap3_thumb2

cap4_thumb3

  • Validez par OK toutes les fenêtres ouvertes, le compte MDT-Join est Opérationnel !

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

Unleash the power of MDT 2010/2012 – Part 2 : Tests & logs

 bildschirmgeraete-gross

Dans ce billets vous apprendrez comment tester Task Sequences et Applications ainsi que l’emplacement des logs qui vous permettrons de troubleshooter.

Tester sans déployer !

-Vous souhaitez tester une partie de votre séquence de déploiement sans avoir à ‘jouer’ toute l’installation ?

- Vous souhaiter vérifier qu’une application ou qu'un groupe d’applications s’installent correctement ? 

Voici comment tester uniquement les partie de votre choix.

Ouvrez MDT, puis, avec le bouton droits sur Task Sequence : Créer une nouvelle “Task Sequence”.

Choisissez le template “Custom task sequence” (Pas besoin de mettre à jour le deployment share)

Vous constatez que la séquence de déploiement ne contient qu’une étape. Cette étape une fois exécutée affichera le panel de sélection des applications. Vous n’aurez plus qu’a sélectionner celles dont vous voulez vérifier le bon fonctionnement. 

Pensez à mettre l’option  SkipApplications=YES à NO si vous l’avez spécifié dans vos Rules. Sinon le Panel de sélection d’Application restera invisible.

Customsequence

Cependant, rien ne vous empêche d’ ajouter à cette séquence toutes étapes dont vous souhaiteriez vérifier le bon  fonctionnement.

Si ces étapes s’appuient sur des informations que vous avez définies dans vos Rules ou alors sur des Proprietes d’MDT (isDesktop, isVM etc..) ; Ajoutez l’étape Gather avant vos étapes de test.

Custom TS

Enfin, le lancement de cette Task Sequence ne s’effectue pas par un démarrage de WinPE, mais bien sur un ordinateur déjà allumé de la manière suivante :

Sur le poste client de test,

Se connecter au Deployment Share en mappant un drive (Z dans cet exemple), puis dans le sous répertoire Scripts, lancer litetouche.vbs. Voici l’ensemble des commandes à saisir pour realiser cette tache :

Net Use Z: \\mdt-server\deploymenshare$ /user:MyDomain\admindc P@ssW0rd
Z :
Cd scripts
Cscript Litetouch.vbs

Si vous avez plusieurs Depolyment Share, et que les bonnes Task Sequences ne s’affichent pas lorsque vous lancez le script, c’est que vous devez effacer ou renommer (rmdir) le répertoire local C:\MININT sur le poste client

La séquence se lance et fait toutes les opérations contenu dans la Task Saquence sans déployer d’OS ! Simple et pratique !… 

 

Logs Divers

Comme nous venons de le voir, LiteTouch.vbs est le script qui permet de lancer MDT. Ce script va logger l’ensemble du déploiement, lancer le wizard en fonction des paramètres définis dans les Rules (CustomSettings.ini). Mais également mettre en places les variables définies dans les Rules ou la Database.

Vous pouvez avoir un aperçu détaillé de ces variables en allant voir à tout moment le fichier de log de MDT. Le fichier de Log permet également de savoir quels informations WMI ont étés remontés du poste client. Ces Logs sont dans :

C:\MININT\SMSOSD\OSDLOGS  au cours du déploiement

C:\Windows\Temp\DeploymentLogs si le déploiement est fini !

X:\MININT\SMSOSD\OSDLOGS si vous êtes sous WinPE est que le disque local n’as pas encore été formaté

Si vous ne souhaitez pas parcourir tout les logs et connaitre directement les variables d’environnement que litetouch.vbs à généré, vous pouvez aller les lire dans le fichier xml : C:\MININT\SMSOSD\VARIABLE.DAT (changez le .DAT en .XML pour qu’il s’ouvre dans IE)

Vous y trouverez notamment le model et la marque de PC que le script à détecté, le type de machine (isDesktop/isLaptop/isVM) etc etc…

L’ensemble de ces variables pourront êtres utilisées dans vos scripts, vos Task Sequences et vos Rules tout au long du déploiement.

 

Les Logs sont accessibles à tout moment du déploiement, cependant vous aurez peu être besoin d’ouvrir une invite de commande pour aller les lires :

Appuyez sur F8 lorsque vous êtes sous WinPE pour ouvrir une invite de commande.

Appuyez sur SHIFT+F10 durant toutes les autres Phases du déploiement.

Enfin,  Pour rendre la lecture des logs moins aride, utilisez Trace32 ou Trace64 pour en avoir une vision claire :Trace32

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