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