Depuis maintenant deux ans, Google Now est utilisable sur les smartphones et activable simplement en prononçant “OK Google”. Cependant, jusqu’ici pour utiliser cet assistant il fallait être impérativement connecté à internet. Ceci pourrait changer dans les semaines à venir, ou plus, mais ce n’est pas ce que l’on souhaite.

La nouvelle version des applications Google, à savoir la version 4.8, intègre du code qui laisse entrevoir cette possibilité. De plus, de nouvelles fonctionnalités semblent être prévues.

Ce mode hors ligne, c’est-à-dire sans connexion Internet, permettrait différentes actions :

– Appeler un contact,
– Envoyer un message,
– Écouter de la musique,
– Activer et désactiver le Wi-Fi

C’est limité dans un premier temps, mais il y a de fortes chances que de nouvelles fonctionnalités soient intégrées au fur et à mesure.

De manière générale, Google Now devrait intégrer de nouvelles fonctionnalités :

– Régler le volume
– Régler la luminosité de l’écran
– Recevoir un avertissement lorsque l’on se connecte à un réseau internet non sécurisé
– Intégration d’une nouvelle carte (au sens Google Now), afin d’indiquer si votre appareil est connecté à un écran externe ou à un haut-parleur externe. Une option de déconnexion sera ajoutée.

Source

I. Présentation

Ce tutoriel s’adresse aux néophytes en matière de déploiement Windows, et a plus précisément pour but de vous de présenter l’installation de base de la solution de déploiement gratuite de Microsoft. J’ai nommé le désormais célèbre “Microsoft Deployment Toolkit” alias “MDT“.

Vous trouverez probablement sur la toile de nombreux tutoriels relatifs à MDT, et celui-ci n’a pas la prétention d’être meilleur que les autres. En fait, il s’agit là de vous présenter quelques fondamentaux que j’enrichirais par des articles complémentaires permettant de progresser à votre rythme et selon vos besoins.

 

II. Un peu de théorie

Loin de moi l’idée de détailler l’intégralité d’un outil aussi riche et complexe que le MDT, mais je pense quelques points de repères et de vocabulaire sont toujours bons à prendre pour les débutants :

A. Architecture et composants

Sur le plan technique, le MDT repose principalement sur le kit de déploiement Windows ADK, (anciennement WAIK) constituant un prérequis impératif. L’architecture de cet outil est articulée autour de 3 parties fondamentales :

• La console de gestion : Alias “Deployment Workbench” (ou “Atelier de déploiement”) : C’est une console graphique de type MMC, exécutée sur un poste Windows (32 ou 64 bits) sur lequel ont été installés le kit de déploiement Windows ADK, et le package MDT. Notez que Powershell est également un prérequis.

• Le point de distribution : Sauf  dans le cas particulier d’usage d’un “Media”, il s’agit d’un dossier partagé (Nom par défaut “DeploymentShare$“) – Tout serveur de fichier SMB/CIFS, Windows ou Linux peut faire l’affaire…

• Le client LiteTouch : Basé sur un noyau WinPE utilisant principalement un script “LiteTouch.wsf“, ce client chargé de connecter et d’interpréter des scripts (.vbs/.wsf) et directives publiées (.xml) sur le point de distribution. Comme tous les noyaux WinPE, il peut être utilisé sur des supports flash USB, des CD/DVD ou bien via le réseau PXE, typiquement via les services WDS (Windows Deployment Services)

 

 

Pour rappel : Les services de déploiement Windows (WDS) constituent une composante facultative de l’architecture MDT.

Au besoin, reportez-vous à ma présentation sur “Vue d’ensemble de MDT-WDS et WinPE” qui aborde une synthèse de ces concepts.

B. Mécanismes et éléments clés de configuration

A l’usage, vous constaterez que le MDT draine des notions de “scénarios de déploiement”. En fait, cela désigne la logique que les scripts vont emprunter pour traiter les différents cas de figures possibles.

Cette logique très complexe de scripts, sera pondérée et contrôlée par les réglages que vous pourrez définir dans les “séquences de taches“. Pour traiter les cas courants, le MDT propose des séquences de taches prédéfinies qui vous pourrez adapter à votre guise.

1. Les scénarios possibles

Les scénarios sont donc composés d’un ensemble de taches pouvant débuter par un test de prérequis(*), une sauvegarde des données d’utilisateur ou une capture de référence puis installer un système d’exploitation et d’éventuelles applications, pour s’achever par une restauration des données d’utilisateur. Les scénarios prennent en charge 4 cas de figure :

• Upgrade Computer : Mise à jour sur place d’un même ordinateur (Sous réserve que le système d’exploitation soit supporté)

• Refresh Computer : Réinstallation sur un même ordinateur (récupération préalable des données d’utilisateur)

• Remplace Computer : Installation sur un nouvel ordinateur (récupération des données d’utilisateur à partir de l’ancien ordinateur)

• New Computer : Installation d’un nouvel ordinateur (L’éventuel contenu existant est supprimé) – Ce scénario ne peut être exécuté que lorsque l’ordinateur est démarré à partir d’un noyau WinPE (Client LiteTouch) – En fait, c’est plutôt rationnel puisqu’il n’est tout bonnement pas possible de supprimer les partitions d’un système en cours d’utilisation.

(*) – Pour votre gouverne et bien qu’il s’agisse d’un concept avancé, voire de spécialiste, sachez que durant l’initialisation du client LiteTouch, le script “ZTIGather.wsf” effectue une collecte d’informations sur l’environnement afin de positionner des variables qui influenceront les séquences de taches par la suite.

 

2. La ressource partagée “DeploymentShare”

Au niveau de la ressource partagée (“DeploymentShare$” par défaut), on distingue particulièrement les dossiers suivants :

• Boot : Contient les fichiers .WIM et éventuellement .ISO correspondants aux images WinPE modifiées “LiteTouch”, nécessaires à l’initialisation de la connexion et l’exécution des tâches définies sur le serveur de fichiers.
• Operating Systems : Contient les fichiers sources des distributions Windows (Copies intégrales des CD ou DVD d’origine ou images .WIM issues de capture)
• Out-of-Box Drivers : Contient les fichiers de pilote tiers au format .INF nécessaires aux images WinPE et aux systèmes d’exploitation à installer
• Packages : Contient les packs de langues, correctifs et mises à jour des systèmes d’exploitation au format .CAB ou .MSU
• Applications : Contient les applications au format .MSI ou .EXE. qui seront exécutées en post-installation.
• Control : Contient les séquences de tâches à exécuter (“ts.xml”) dans des sous-dossiers, ainsi que la plupart des fichiers .xml de configuration du MDT. Au passage, j’attire juste votre attention sur la présence de 2 fichiers .INI particulièrement intéressants et importants que sont “bootstrap.ini ” et “CustomSettings.ini” sur lesquels nous aurons l’occasion de revenir.

En bref, la majeure partie des réglages du MDT est contenue dans des fichiers .XML Il fortement déconseillé de modifier ces fichiers, ou toute autre manipulation directement au sein de cette structure. En effet, la quasi-totalité des actions de configuration MDT, mais aussi les copies, renommages, déplacements, etc doivent impérativement être réalisés via la console “Deployment Workbench“.

Pour finir sur cette présentation théorique, notez que la structure MDT est “transportable”. Vous pouvez à loisir stocker vos travaux sur un disque amovible, un lecteur réseau ou un média de votre choix. Pour l’exploiter, il suffira d’utiliser une machine sur laquelle le MDT est installé, de connecter la ressource puis d’ouvrir cette structure existante à partir de la console.

 

III. Installation de MDT 2013

A. Téléchargements

A partir d’un ordinateur ayant un accès Internet, vous devez commencer par télécharger les éléments suivants:

Windows ADK : La version 8.1 est disponible sur le site de Microsoft  ici. Vous remarquerez que ce kit est en fait téléchargé en 2 étapes. En premier lieu vous obtenez le fichier ” adksetup.exe” qui une fois exécuté, vous proposera 2 options:

• Soit une installation en ligne via un téléchargement dynamique
• Soit un téléchargement pour une installation ultérieure – typiquement sur votre futur ordinateur MDT qui n’aura pas nécessairement d’accès à l’Internet. – Je vous conseille ce second choix pour cette démonstration.

Notez que ce kit unique contient les binaires nécessaires aux architectures 32 et 64 bits.

Microsoft Deployment Toolkit (MDT) : La version 2013 est disponible sur le site de Microsoft ici. Contrairement au kit ADK, Microsoft propose des packages distincts pour les architectures 32 ou 64 bits.

Cochez les éléments désirés afin de les télécharger.

B. Installation

Pour installer une solution de déploiement MDT, il vous faut un poste et/ou un serveur : Pour débuter, je vous propose d’utiliser un serveur Windows 2012R2, mais un poste Windows 7, 32 ou 64 bits peut également faire l’affaire. Je considère que les fichiers précédemment téléchargés ont été déposés sur une ressource locale de cette machine telle que “F:\Download“.

En premier lieu, et après avoir installé et configuré ce serveur avec les valeurs de votre choix, vous devez installer le kit ADK en exécutant le programme “F:\Download\adksetup.exe“. Validez le chemin d’installation proposé par l’assistant, puis cliquez 2 fois sur le bouton “Suivant” puis sur “Accepter” pour le contrat de licence. Vous devrez alors choisir les fonctionnalités à installer :

Il n’est pas nécessaire de conserver toutes les fonctionnalités. Pour les besoins du MDT, vous limiter la sélection aux options suivantes :

• Outils de déploiement
• Env. de pré installation de Windows (Windows PE)
• Outil de migration utilisateur (USMT) – A conserver si vous souhaitez utiliser des scénarios qui préservent les données locales.

Note : Depuis ADK8.1, la migration Windows XP n’est plus supportée

Cochez les cases désirées puis cliquez ensuite sur le bouton “Installer“.

Une fois l’ADK installé, étant sur un serveur Windows 2012R2, donc un système 64 bits, exécutez le package “F:\Download\MicrosoftDeploymentToolkit2013_x64.msi” via un double-clic.

Cliquez sur le bouton “Next“.

Cochez la case “I accept the terms in the License Agreement” puis cliquez sur le bouton “Next”

Conservez les fonctionnalités (features) proposées, vérifiez ou modifiez éventuellement le chemin d’installation (location) puis cliquez sur le bouton “Next“.

Conservez le choix par défaut puis cliquez de nouveau sur “Next“.

Enfin, cliquez sur le bouton “Install” puis sur le bouton “Finish” une fois l’installation achevée.

IV. 1er contact avec la console MDT 2013

A ce stade, le MDT est encore bien loin d’être opérationnel. En effet, nous avons installé les programmes nécessaires mais il reste encore à alimenter la fameuse structure évoquée précédemment.

Suite à l’installation précédente, plusieurs raccourcis de programmes ont été créés, mais seul “Deployment Workbench” vous sera utile pour l’usage des scénarios LiteTouch.

Pour ouvrir la console MMC de gestion MDT, exécutez “Deployment Workbench“. Il est souhaitable que cet outil soit exécuté “en tant qu’administrateur“.

Vous pouvez constater que la console d’administration du MDT est principalement organisée autour de 2 rubriques générales :

• “Information center” : Contient les explications de démarrage et les documentations et nouveautés en anglais (“Getting Started”, “Documentations”, “News”), ainsi que les liens de téléchargement relatifs aux technologies de déploiement (“Components”).

• “Deployment Shares” : Contient la ou les structures de référence que nous allons détailler ci-après. C’est à ce niveau que des structures MDT peuvent être crées ou attachées si elles existent déjà.

A. Déclaration d’un point de déploiement

Étant donné qu’il s’agit d’une présentation, nous allons procéder à la création de notre premier point de déploiement. Pour cela, sélectionnez la rubrique “Deployment Shares” puis utilisez le menu “Action … New Deployment Share” ou le menu contextuel pour créer une nouvelle structure.

Le nom et l’emplacement proposé par défaut peut être modifié. Pour rappel, il peut s’agir d’une ressource locale (NTFS de préférence, mais ce n’est pas une obligation) ou distante sur n’importe quel serveur SMB/CIFS. Dans ce deuxième cas, vous devrez indiquer le chemin UNC et vous assurer que le partage est effectif et offre les autorisations d’accès en écriture.

Pour cet exemple, nous conservons cette proposition. Cliquez sur le bouton “Next”

Du fait que nous avons conservé un chemin local, l’assistant vous propose d’effectuer le partage du dossier sous le nom “DeploymentShare$“. Vous pouvez modifier ou conserver ce nom par défaut, sachant qu’il est possible d’héberger plusieurs structures MDT sur une même machine. Cliquez ensuite sur le bouton “Next“.

Là encore, vous allons modifier le nom en “MDT Demo” mais vous pouvez conserver le nom proposé par défaut. Celui-ci vous permet de distinguer les différentes structures que vous auriez à administrer, par exemple au sein de différents environnements. Cliquez ensuite sur le bouton “Next“.

Cette première série d’options peut être déroutante au début. En fait, il s’agit là de définir les principaux réglages qui seront appliqués par défaut aux séquences de taches. Pour votre gouverne, ces réglages peuvent être modifiés par la suite et éditant le fichier “[MDTShare]\ControlCustomSettings.ini“. Vous pouvez décocher toutes les cases si vous le souhaitez, sachant que nous reviendrons ultérieurement sur les différents écrans des séquences de taches.

Pour votre gouverne, les choix proposés ici correspondent respectivement aux valeurs suivantes :

SkipComputerBackup=NO
SkipProductKey=YES
SkipAdminPassword=YES
SkipCapture=NO
SkipBitLocker=NO

Cliquez ensuite sur le bouton “Next“, vérifiez les informations du résumé (summary) puis cliquez de nouveau sur “Next” afin de procéder à la création de cette première structure.

Une fois l’installation achevée, vous pourrez remarquer l’exécution d’un script Powershell dont vous pouvez éditer et/ou conserver le contenu, via le bouton “View script“. Par exemple :

Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\Microsoft\DeploymentToolkit.psd1"
new-PSDrive -Name "DS002" -PSProvider "MDTProvider" -Root "C:\DeploymentShare" -Description "MDT Demo" -NetworkPath "WDS-MDT\DeploymentShare$" -Verbose | add-MDTPersistentDrive -Verbose

Cliquez sur le bouton “Finish“.

 

B. Vérification de la configuration initiale

A ce stade, via l’explorateur ou une invite de commande, assurez-vous de la présence d’une structure de dossiers et de fichiers, et que le partage associé est bien effectif :

dir C:\DeploymentShare /s /p
net share

De retour dans la console, votre structure MDT doit être également visible (certains dossiers sont toutefois masqués)

Sélectionnez votre nouveau point de déploiement, ici “MDT Demo” puis utilisez le menu “Action … Propriétés” ou le menu contextuel.

Sous l’onglet “General“, vous pouvez vérifier ou modifier vos préférences initialement définies.

Si vous souhaitez déployer qu’un seul type d’architecture, comme par exemple 64 bits, vous pouvez décocher la case “x86“. Cela permet d’optimiser sensiblement la structure et les temps de fabrication.

Nous allons maintenant nous attarder particulièrement sur l’onglet “Rules“, sous lequel vous retrouvez les 2 fichiers principaux de configuration du MDT

Le cadre est en fait un éditeur du contenu du fichier “MDTShare]\Control\CustomSettings.ini” que vous pourriez également modifier via le bloc-notes. En revanche, pour éditer le fichier “[MDTShare]\Control\Bootstrap.ini“, la console ne propose pas d’édition directe mais un bouton “Bootstrap.ini” qui ouvrira le bloc-notes.

Nous reviendrons ultérieurement sur cet élément fondamental de configuration qu’est le fichier “CustomSettings.ini “, mais j’attire votre attention sur le fait que le fichier “Bootstrap.ini” est le premier point d’entrée d’un scénario de déploiement.

Ce fichier sera intégré lors du processus de fabrication de vos clients LiteTouch, qui nous allons évoquer juste après.

Contenu initial du fichier “Bootstrap.ini” :

En l’état, il permet d’effectuer la connexion vers votre point de déploiement lors de l’initialisation du client LiteTouch. Toutefois, vous serez systématiquement invité à saisir les identifiants nécessaires à la connexion.

A ce propos, je vous suggère de créer un compte d’utilisateur (local ou de domaine) qui servira aux phases de déploiement. Il est possible de créer d’autres comptes avec des privilèges plus ou moins élevés, mais celui-ci n’a besoin que des droits de lecture sur le partage. Vous pouvez créer rapidement ce compte via la commande suivante :

net user MDT-Depl "Pa$$w0rd" /add

Pour les droits, il n’y a rien à faire du fait que les utilisateurs ont déjà un droit de lecture par défaut. Toutefois, si vous le souhaitez, vous pouvez revoir ces autorisations via les commandes suivantes:

net share DeploymentShare$ /delete
net share DeploymentShare$=C:DeploymentShare /grant:"MDT-Depl",READ /remark:"MDT Demo"

Ou plus simplement via l’interface graphique

Pour éviter l’authentification systématique, même si certains nous reprocherons une entorse à la sécurité, je vous propose donc de modifier le fichier “Bootstrap.ini” comme suit :

[Settings]
Priority=Default

[Default]
DeployRoot=WDS-MDTDeploymentShare$
SkipBDDWelcome=YES
UserID=MDT-Depl
UserDomain=WDS-MDT
UserPassword=Pa$$w0rd
KeyboardLocalePE=040c:0000040c

Si vous n’utilisez pas de compte de domaine, comme dans cet exemple, indiquez le nom ou l’adresse IP de votre serveur MDT pour la valeur de la variable “UserDomain”. La variable “KeyboardLocalePE” stipule ici un clavier de type “fr-FR”.

Pensez à enregistrer vos modifications puis fermez le bloc-notes.

Sous l’onglet “Windows PE“, vous pouvez stipuler les différentes options de fabrication des clients LiteTouch et noyaux WinPE. Détaillons maintenant cet onglet, particulièrement fourni….

Premièrement, faites attention à la liste de choix “Platform“, en haut à gauche, qui permet de basculer sur vos préférences relatives au client 32 bits “x86” ou au client 64 bits “x64“.

Dans les 2 cas, vous disposez de 3 sous-onglets, que nous allons détailler :

1. Sous-onglet “General” :

Permet de définir le type d’image WinPE qui sera généré ainsi que certaines personnalisations.

Vous remarquerez que la première case à cocher “Generate a Lite Touch Windows PE WIM File” est obligatoirement cochée et seule le champ “Description” peut être modifié. Pour rappel, le fichier WIM généré nécessitera son insertion dans une structure d’amorçage tel qu’un serveur de déploiement WDS au niveau des images de démarrage.

Pour une utilisation autonome, incluant une structure de démarrage, cochez la seconde case “Generate a Lite Touch bootable ISO image“. Le fichier .ISO ainsi généré pourra être gravé sur un média ou bien être associé à une machine virtuelle.

Sous la partie centrale “Windows PE Customizations“, vous pouvez modifier :

• “Custom background bitmap file” : Permet de stipuler le fond d’écran de WinPE en indiquant le chemin d’un fichier bmp de votre choix. La variable %INSTALLDIR% pointe par défaut vers le dossier où vous avez installé le kit ADK (ie “C:\Program Files\Microsoft Deployment Toolkit”)

• “Extra directory to add” : Permet de stipuler un dossier quelconque (incluant par exemple vos propres outils) qui sera intégré au noyau WinPE.

• “Scratch space size” : Définit l’espace de travail temporaire affecté en complément du disque mémoire “Ramdrive” de WinPE (variable de 32 à 512 Mo) principalement utilisé par les pilotes. Evitez de modifier cette valeur sans motivation particulière.

Enfin, la zone “Generic Boot Image Settings” permet de décliner ces opérations vers un noyau générique. Autrement dit, un client dépourvu du lancement automatique du script LiteTouch. Un démarrage sur ce type d’image s’achève donc sur une simple invite de commande de WinPE.

2. Sous-onglet “Features” :

Vous trouvez ici, l’ensemble des fonctionnalités optionnelles qu’il est possible d’intégrer au noyau WinPE. Le nombre de ces fonctionnalités s’est enrichi au fil des versions et nous ne détaillerons pas ces composants dans cette présentation.

Toutefois, je ne peux m’empêcher de relever que cette mouture MDT2013 offre (enfin) la possibilité d’ajouter le framework .NET, Windows Powershell , et même des modules “cmdlet” complémentaires : Je pense que les aficionados apprécieront 

Cet écran permet également d’ajouter quelques compléments linguistiques tels que les polices de caractères asiatiques.

Vérifiez simplement que l’option “Microsoft Data Object Components (MDAC/ADO) support” est cochée.

3. Sous-onglet “Drivers and Patches “

Cet écran est particulièrement important du fait qu’il détermine les pilotes qui seront intégrés aux noyaux WinPE. Ces réglages sont donc déterminants du bon déroulement des processus de déploiement et d’installation, et je pense qu’une petite explication s’impose.

En premier lieu, vous constaterez la présence d’une liste déroulante “Selection profile” permettant de choisir un “magasin” à partir duquel les pilotes et packages seront recherchés. Notez que la console MDT permet de créer préalablement un profil de sélection, qui correspond en fait, à une sélection de dossier(s) dans la structure MDT.

Lorsque le nombre de pilotes est conséquent, il est conseillé de créer un sous-dossier contenant les pilotes propres à WinPE et de le référencer par un profil de sélection dédié. Par défaut, le profil “All Drivers and Packages” pointe vers les dossiers “Out-of-Box Drivers” et “Packages” de la structure MDT.

Note : N’oubliez pas que les pilotes peuvent être différents selon l’architecture 32 ou 64 bits.

Les noyaux WinPE n’ont pas pour vocation d’inclure tous les pilotes, mais uniquement les pilotes nécessaires à une installation. Autrement dit, le MDT distingue 4 types de périphériques particulièrement cruciaux pour les noyaux WinPE :

Désignation MDT	Class ID	Description	A sélectionner
network drivers	“Net”	pilotes de cartes réseau	Fortement conseillé
mass storage drivers	hdc”,  “SCSIAdapter”, “DiskDrive	pilotes de stockage (disques durs)	Fortement conseillé
video drivers	“Display”	pilotes de cartes graphiques	Facultatif : Le support d’un format VGA Standard peut vous affranchir de ces pilotes
system-class drivers	“System”	pilotes de composants électroniques intégrés spécialisés (Egalement connus sous l’anglicisme “Chipsets”)	Conseillé : Certains pilotes réseau ou disques ont des dépendances.

Pour en revenir à notre MDT, le réglage proposé par défaut, est plutôt adapté aux situations courantes puisqu’il effectue une requête de recherche des pilotes dans les dossiers référencés par le profil de sélection, en fonction de la classe de ces derniers ainsi que de l’architecture 32 ou 64 bits.

Note : Sous la rubrique “Out-of-box Drivers“, la liste des pilotes tiers présentée dans le tableau peut être triée selon les colonnes. Ainsi, en effectuant un tri sur “Platform” et “Class” vous pouvez avoir une idée précise du nombre de pilote potentiellement ajoutés dans les noyaux WinPE

Aparté sur les pilotes :

Le rangement des pilotes dans des sous-dossiers est une bonne pratique. Cela vous permettra par la suite de distribuer ces pilotes de manière ciblée sur les bons ordinateurs. Une des techniques courante de classement consiste à utiliser des noms de dossiers basés sur les variables “Make” et “Model“, soit respectivement le nom du fabriquant et le modèle d’ordinateur, pour y stocker les pilotes associés.

Pour récupérer ces informations, vous pouvez utiliser, soit :

• L’outil “msinfo32.exe“, puis identifiez les champs “Fabriquant” (Make) et “Modèle” (Model)

• Via Powershell

Get-WmiObject Win32_ComputerSystem | Select Model,Manufacturer

Collectez les valeurs “Manufacturer” (Make) et “Model” (Model)

• Via la console WMI

WMIC CSProduct Get Name, Vendor

Collectez les valeurs “Vendor” (Make) et “Name” (Model)

Note : L’avantage de cette dernière technique est que vous pourrez l’exécuter sur n’importe quel ordinateur à partir d’un simple invite WinPE (ie DVD d’installation via [Maj]+[F10] , Client LiteTouch via [F8] )

Sachez que les éléments stockés dans cette structure MDT peuvent être réorganisés ultérieurement. Nous reviendrons sur cette mise en œuvre des pilotes dans un prochain tutoriel dédié à la configuration avancée du MDT.

 

C. Génération des clients “LiteTouch”

La génération du client “LiteTouch” constitue une étape fondamentale avant la mise en exploitation du MDT. Pensez à réitérer cette opération dès lors que vous appliquez des modifications telles que l’ajout de pilotes concernant WinPE, des modifications relatives au partage MDT, et de manière plus générale, dès qu’il y a une modification des thèmes précédemment évoqués.

Pour générer (ou actualiser) la fabrication des clients “LiteTouch”, vous devez sélectionner la racine du partage dans l’arborescence de la console MDT, comme par exemple “Deployment Shares … MDT Demo” puis utiliser le menu “Action … Update Deployment Share” ou le menu contextuel.

Vous disposez alors de 2 options de génération des images :

• “Optimize the boot image updating process” – Permet de travailler sur des images existantes et permet de gagner en rapidité de création hormis la première fois. La case à cocher “Compress the boot image …” est censée optimiser la taille du noyau WinPE en supprimant les composants inutilisés.

• “Completely regenerate the boot images” – Ce processus de génération est plus long mais permet d’obtenir des images fiables. Utilisez cette option suite à des modifications importantes du MDT. Préférez cette option si vous constatez un comportement anormal des clients “LiteTouch”

Dans notre exemple, sélectionnez la seconde options puis cliquez 2 fois sur le bouton “Next“. Cette opération nécessite plusieurs minutes d’attente en fonction des performances de votre ordinateur. Cliquez sur le bouton “Finish” une fois l’opération achevée.

Vous trouverez les fichiers résultants de cette génération dans le dossier “Boot” situé à la racine du point de déploiement.

Une fois générées, les images .WIM LiteTouch peuvent ensuite être intégrées aux images de démarrage d’un serveur de déploiement Windows (WDS) afin de bénéficier du démarrage PXE et éventuellement bénéficier du mode “Multicast*” lors du déploiement des images de distribution. (cf Multicast WDS et MDT)

 

D. Alimentation de la structure

Maintenant que votre structure MDT est déclarée, vous devez encore l’alimenter afin qu’elle soit opérationnelle. En fait cette arborescence est principalement destinée à recueillir l’ensemble de vos sources de distribution : systèmes d’exploitation, pilotes, mises à jour et autres applications. Pensez à provisionner un espace de stockage relativement conséquent, selon l’usage prévu.

Pour votre premier essai avec MDT, il faudra ajouter à minima, un système d’exploitation Windows (NT6.x) de votre choix. Sous MDT, c’est le dossier “Operating System” qui est destiné à recevoir les sources des systèmes d’exploitation provenant des CD/DVD originaux ou d’une distribution .WIM personnalisée (issue d’une capture) – Dans le premier cas, l’ensemble de la structure du média est recopié dans ce répertoire.

Important : Commencez toujours par l’ajout d’une distribution originale de Microsoft, de type DVD ou .ISO. En effet, ce point de détail est souvent perdu dans la masse des informations relatives au MDT mais il faut considérer que l’ajout d’une image .WIM personnalisée doit se faire dans un second temps. Ceci est principalement lié au fait que le MDT n’inclus pas différents fichiers relatifs à l’installation, et réutilise ces derniers pour gérer les autres déclinaisons.

A toutes fins utiles, voici une petite illustration d’une structure de DVD Windows NT6.x

Pour procéder à l’ajout de la première distribution, munissez-vous du support DVD original du système d’exploitation ou du fichier .ISO correspondant – Depuis Windows 8/2012, ce format est (enfin) nativement reconnu par Windows, et vous n’avez plus besoin de recourir à des outils tiers. Pour notre exemple, nous allons ajouter l’image d’un système Windows 8.1 x64 en procédant comme suit :

Insérez le DVD dans le lecteur ou montez l’image .ISO via l’explorateur Windows

Note : Je vous passe ce conseil, qui pourra être appliqué plus tard, mais une bonne pratique consisterait à créer un sous-dossier (“New folder“) que l’on pourrait nommer par exemple “DVD Original W8.1 x64” afin d’identifier facilement l’origine de cette distribution, et la distinguer explicitement des images personnalisées que vous ajouterez par la suite.

Au niveau de la console MDT, sélectionnez le dossier “Operating System” puis utilisez le menu “Action … Import Operating System” ou le menu contextuel.

L’assistant vous demande ensuite quel type d’importation vous souhaitez entreprendre. Vous aurez alors 3 choix possibles :

• “Full set of source files” : Intègre la copie conforme et intégrale du média de distribution du système d’exploitation. (pas uniquement l’image WIM contenue dans “Sources”)

• “Custom image file” : Intègre une image .WIM d’un système personnalisé – Typiquement une image de référence, dite “Master”, contenant des applications ou composants préinstallés.

• “Windows Deployment Services images” : Ajoute les images d’installation hébergées sur un serveur de déploiement WDS. Notez qu’il s’agit alors d’un référencement et que les fichiers .WIM demeurent sur le serveur WDS sans être recopiés dans la structure MDT. De plus, l’importation ajoute l’ensemble des images présentes, sans possibilité de sélection unitaire.

Sélectionnez la première option puis cliquez sur le bouton “Next”

Au niveau du champ “Source Directory“, utilisez le bouton “Browse” ou indiquez simplement la racine du média ou dossier contenant les sources originales puis cliquez sur le bouton “Next”

L’assistant détecte automatiquement le système d’exploitation à importer et propose un nom par défaut. Conservez ou modifiez le nom proposé puis cliquez sur le bouton “Next“. Cette valeur correspond au nom du sous-dossier qui sera créé dans l’arborescence MDT.

Vérifiez vos sélections au niveau de l’écran de synthèse puis cliquez sur le bouton “Next” afin de déclencher le processus de copie. Cliquez sur le bouton “Finish” une fois l’opération achevée.

Recommencez cette opération pour chaque système d’exploitation concerné.

Conseil : Si vous disposez de plusieurs systèmes d’exploitation, n’hésitez pas à créer et déplacer ces derniers dans des dossiers explicites tels que “x86″, “x64″ afin d’épurer l’affichage et faciliter le repérage. Pour déplacer les éléments dans un dossier de la console MDT, sélectionnez-les puis utilisez la touche [MAJ] lors du déplacement. Il est ensuite nécessaire d’appuyer sur la touche [F5] pour réactualiser l’affichage.

 

Note : Si votre distribution .WIM contient plusieurs images, l’intégralité de ces dernières est ajoutée à la console MDT. Pour alléger l’affichage, particulièrement lorsque certaines images vous sont inutiles, vous pouvez les sélectionner puis utiliser le menu “Action … Supprimer” ou le menu contextuel.

Normalement, il faudrait poursuivre par l’installation des pilotes, des applications, voire des packages et autres mises à jour, mais pour cette présentation, nous disposons des éléments suffisants à la réalisation d’un premier déploiement automatisé via MDT.

E. Création de votre première séquence de tache

A ce stade, l’ultime étape consiste à déclarer votre première séquence de tâche de déploiement. Situé au cœur des principes du MDT, ces séquences de tâches ont en charge le pilotage des différents scénarios possibles dans le cadre d’un déploiement ou d’une fabrication d’un système Windows. Je vais donc concentrer mes explications ce premier cas d’école.

En premier lieu, au niveau de la console MDT, sélectionnez le dossier “Task Sequences” puis utilisez le menu “Action … New Task sequence” ou le menu contextuel.

Entrez un identifiant unique pour ce scénario dans le champ “Task sequence ID“. Ce nom correspond au sous-dossier qui sera créé pour y héberger les fichiers propres à cette séquence. Hormis l’unicité de cette référence, aucune règle de nommage n’est imposée mais contrairement aux autres informations, ce nom restera délicat à modifier par la suite.

Choisissez par exemple “Depl-W8x64pro-01” puis entrez une information explicite dans le champ “Task sequence Name“. Cette indication apparaitra dans le menu de l’installateur coté client au même titre que les éventuels commentaires que vous pouvez ajouter dans le champ “Task sequence Comments“. Ces champs pourront être facilement modifiés par la suite au niveau des propriétés de la séquence de tâche.

Une fois ces champs renseignés, cliquez sur le bouton “Next”

L’écran suivant vous affiche une liste de modèles prédéfinis de scénarios (séquence de taches) que nous allons décrire brièvement :

• “Sysprep and Capture” : Ce scénario est chargé de réaliser une tache de préparation d’un poste de référence via l’outil sysprep correspondant puis réalise une capture de l’image .WIM résultante vers la structure MDT. Cette image de capture peut ensuite être importée en tant qu’image personnalisée “Custom Image” de la rubrique “Operating System“.

Dans certains cas et surtout pour les néophytes, il peut s’avérer plus simple de préparer manuellement le poste de référence, puis de solliciter cette séquence dédiée à la préparation et à la capture de l’image. Contrairement aux séquences d’installation sollicitées via un démarrage à partir du client LiteTouch, ce scénario doit être déclenché à partir d’un poste opérationnel.

Autrement dit, vous pouvez procéder à la préparation et la configuration du poste en toute liberté, y compris dans un environnement virtuel. Une fois les applications, les mises à jour et les réglages achevés, vous n’avez plus qu’à solliciter cette séquence. Connectez un lecteur réseau, tel que “Z:” vers la ressource “ServeurMDT\DeploymentShare$” avec les identifiants d’un compte disposant à minima des droits d’écriture dans le sous-dossier “Z:\Captures” puis exécutez le script suivant via une connexion réseau “Z:\Scripts\LiteTouch.vbs“.

Astuce : Si vous réalisez votre image de référence à partir d’un ordinateur virtuel, exécutez une capture instantanée (snapshot) de celui-ci juste avant d’exécuter la séquence de préparation. Cette opération vous permettra de conserver une configuration type et gagner un temps précieux si vous souhaitez reprendre ou compléter une configuration existante.

• “Standard Client Task Sequence” : Ce scénario proposé par défaut est chargé de réaliser une installation traditionnelle d’un nouveau poste client.

• “Standard Client Replace Task Sequence” : Ce scénario, proche du précédent, sauvegarde préalablement l’intégralité du poste existant et exporte les paramètres et données d’utilisateur vers un chemin réseau avant d’effacer les disques et procéder à l’installation. Nécessite que le composant User State Migration Tool (USMT) soit installé préalablement installé. (cf Installation du kit ADK)

• “Custom Task Sequence” : Ce scénario ne contient aucune tâche par défaut et peut être utilisé pour effectuer des tâches ponctuelles et/ou complémentaires de déploiement.

• “LiteTouch OEM Task Sequence” : Ce scénario principalement est destiné aux intégrateurs de matériel (Original Equipment Manufacturer) et s’appuie sur un mécanisme de déploiement par média (Ne nécessite pas d’infrastructure réseau).

• “Standard Server Task Sequence” : Ce scénario est chargé de réaliser une installation d’un nouveau système d’exploitation serveur et piloter la configuration de certains rôles tels que les services DNS (Domain Name Service), DHCP (Dynamic Host Configuration Protocol), ou encore ADDS (Contrôleur de domaine Active Directory). Les directives d’installation des rôles (ou fonctionnalités) peuvent également être définies dans un fichier de réponse associé.

• “Post OS Installation Task Sequence” : Ce scénario apparu avec le MDT2010 update 1 permet d’effectuer un ensemble de tâches complémentaires à partir d’un système Windows déjà installé (indépendamment du client “LiteTouch”). Pour déclencher cette séquence, vous devrez solliciter directement le script “PartageMDT]\Scripts\LiteTouch.vbs” comme dans l’exemple précédent puis sélectionner la séquence de tache désirée.

• “Deploy to VHD Client Task Sequence” : Ce scénario apparu avec le MDT2012 permet de déployer des disques virtuels. Sous réserve de disposer d’un chargeur approprié (BOOTMGR et BCD) sur une partition physique, les éditions Entreprise et Intégrale de Windows 7 ont la capacité de démarrer nativement à partir d’un disque virtuel.

• “Deploy to VHD Server Task Sequence” : Ce scénario est identique au précédent pour les systèmes “serveur” depuis Windows Server 2008R2.

Note : Les services de déploiement Windows sont en mesure de diffuser ce genre d’image de disque virtuel au même titre que les images .WIM.

Pour revenir à notre exemple, sélectionnez la séquence par défaut, “Standard Client Task Sequence” puis cliquez sur le bouton “Next“.

La liste des systèmes d’exploitation référencés par le MDT est alors affichée.

Sélectionnez le système désiré parmi ceux installés précédemment puis cliquez sur le bouton “Next”

L’écran suivant permet de stipuler la clé de licence du produit afin d’en éviter la saisie par l’installateur.

Pour les distributions Windows 7 et ultérieures, utilisez la seconde option afin d’affecter une licence d’activation multiple (MAK : Multiple Activation Key).

La dernière option est utilisée pour stipuler une clé de licence unitaire (Retail). De fait, cette option n’est utilisable que sur une seule machine.

Aparté sur les clés de licences et le fichier de réponse :

Les clés de licences peuvent être renseignées dans le fichier de réponse “unattend.xml” (associé et propre à chaque séquence de tache). Celui-ci peut être édité via les “Propriétés” d’une séquence de tache de déploiement, sous l’onglet “OS Info“:

En cliquant sur ce bouton, un fichier catalogue (.clg) est nécessaire. En cas d’absence, celui-ci est régénéré et l’ouverture de ce contenu dans “Windows System Image Manager” (WSIM) peut alors prendre un certain temps.

Attention, selon le type d’image x86 versus x64, la génération d’un catalogue peut poser problème sur une plateforme MDT/ADK 64 bits – cf Support Microsoft

Je vous concède, que pour un néophyte, la richesse de l”interface peut paraître déconcertante !…

Dans cet exemple, si vous souhaitez stipuler une clé de licence, vous devez renseigner le champ “ProductKey” situé sous le composant “…Windows-Shell-Setup_neutral“, dans la phase “4 specialise”

Cette technique peut être utilisée pour stipuler les clés de licence en volume d’entreprise KMS (Key Management Service), ou les clés par défaut – Ces dernières n’ont aucune valeur en matière d’activation mais sont imposées par les processus d’installation depuis Windows 8. Vous trouverez ces clés KMS par défaut sur le site de Microsoft : Clé KMS.

Note : Une clé KMS présente l’avantage d’être unique pour toute l’entreprise, mais nécessite un serveur d’activation au sein de cette dernière. Lorsqu’une machine dispose de ce genre de clé, la localisation du serveur est automatique sous réserve qu’un service DNS le résolve via un enregistrement de ressource SRV, de type ” _VLMCS“. Cf Microsoft Technet

Je ne souhaite pas vous égarer, mais sachez que le script “slmgr.vbs“, vous sera d’une grande utilité en matière de gestion de ces fameuses clés de licence.

A défaut d’être renseignée dans un fichier de réponse, la saisie d’une clé de licence sera proposée à l’installeur au début d’un déploiement LiteTouch à condition que la directive “SkipProductKey = NO” soit définie dans le fichier “CustomSettings.ini” ou dans la base de donnée associée à MDT.

Dans cet exemple basique, conservez l’option par défaut “Do not specify a product key at this time” puis cliquez sur le bouton “Next“.

L’écran suivant vous permet de saisir les informations de votre société habituellement relatives au propriétaire de la licence, respectivement dans les champs “Full Name” et “Organization”

Bien que facultatif, vous pouvez également préciser la page d’accueil par défaut du navigateur Internet Explorer puis cliquez ensuite sur le bouton “Next“.

L’écran suivant vous permet de saisir le mot de passe de l’administrateur local intégré. Cette donnée sensible est stockée dans le fichier de réponse correspondant sous forme encodée.

Si vous conservez la première option, “Use the specified local Administrator password“, la saisie d’un mot de passe sera proposée à l’installeur lors du déploiement LiteTouch. Ce choix correspond à la directive “SkipAdminPassword = NO” définie dans le fichier “CustomSettings.ini” ou dans la base de donnée associée à MDT.

Si vous optez pour la seconde option, “Do not specify an Administrator password at this time“, aucune saisie de mot de passe ne proposé. Notez toutefois que, pour les distributions originales, bien que désactivé par défaut, ce compte administrateur n’a aucun mot passe, et restera donc vide !… Pour vos images de référence, c’est le dernier mot de passe renseigné dans la base SAM qui sera conservé.

Pour cette démonstration, entrez un mot de passe de votre choix, puis cliquez 2 fois sur le bouton “Next” et sur le bouton “Finish” une fois l’opération achevée.

A ce stade, le scénario est opérationnel. Vous pouvez le tester à partir d’un poste, ou machine virtuelle en les démarrant à partir d’une image de client LiteTouch. (Disponibles sous le dossier “Boot” du partage de déploiement)

 

F. Facultatif : Une petite cerise sur le gâteau :

Malgré la relative longueur de cette présentation, vous êtes encore bien d’avoir exploré tout le potentiel de ce fabuleux outil qu’est le MDT. Toutefois, avant de conclure et sans attendre la parution d’articles complémentaires et avancés sur ces concepts, je vous propose une légère personnalisation du “Control\CustomSettings.ini“. Ceci afin d’affecter une valeur telles que le nom de votre société dans la variable “_SMSTSORGNAME” (par défaut = “IT Organization”). Par la suite, vous pourrez également jouer sur cette valeur affichée dans la barre de titre de progression, afin informer l’installateur sur une séquence de tache en cours.

Afin de lever toute ambiguïté, voici le contenu du fichier “CustomSettings.ini” utilisé dans cette démonstration.

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipCapture=YES
SkipAdminPassword=NO
SkipProductKey=YES
SkipComputerBackup=YES
SkipBitLocker=YES

_SMSTSORGNAME=cnf1g MDT - IT Demo

 

V. Tests et commentaires sur le résultat attendu

Admettons que nous démarrions une machine virtuelle (sous Hyper-V afin de s’affranchir d’éventuelles difficultés sur les pilotes de carte réseau), et ce à partir des fichiers .ISO que nous avons récupéré sous le dossier “Boot”, le premier écran que vous obtiendrez après la séquence d’amorçage devrait correspondre à ceci :

Vous pouvez choisir le clavier approprié, via la liste “Keyboard Layout“, stipuler une adresse IP en l’absence de serveur DHCP.

Cliquez ensuite sur le gros bouton “Run the Deployment Wizard to install a new Operating System”

Vous serez ensuite invité à renseigner les identifiants nécessaires à la connexion réseau vers le serveur MDT.

Si votre serveur MDT n’appartient pas à un domaine Active Directory, indiquez le nom ou l’adresse IP dans le champ “Domain” obligatoire.

Ces opérations deviendrons rapidement de l’histoire ancienne, si vous procédez à la modification du fichier “Bootstrap.ini” comme mentionné précédemment dans le paragraphe “Vérification de la configuration initiale“. Si vous effectuer cette modification que maintenant, n’oubliez pas de régénérer les images de vos clients LiteTouch, via le menu “Update Deployment Share”

Astuce : Si cela ne fonctionne pas, ou simplement pour vérifier, vous pouvez utiliser la touche [F8], puis taper la commandes suivantes :

type X:\Deploy\Scripts\Bootstrap.ini

net use

Si aucune connexion au lecteur “Z:” n’apparaît, tapez la commande suivante en utilisant les valeurs des éléments “DeployRoot“, “UserDomain“, “UserID“et “UserPassword” contenus dans le fichier “bootstrap.ini“, comme par exemple :

Net use z: \\WDS-MDT\DeploymentShare$ /user:WDS-MDT\MDT-Depl Pa$$w0rd

En cas d’échec, vérifiez que le dossier est bien partagé sous le nom mentionné et que l’utilisateur dispose bien des autorisations nécessaires sur le partage MDT.

Vérifiez également que cet utilisateur bénéficie à minima des autorisations NTFS en lecture sur la structure, via une simple commande “dir” ou “tree”.

tree z: | more

A. Détails d’une séquence de taches

Ensuite, les séquences de taches disponibles sont proposées. Dans notre exemple, l’unique séquence de déploiement de Windows 8 Pro 64 bits est affichée.

Notez toutefois, que le MDT a évalué que la machine utilisée était compatible avec une architecture 64 bits. Dans le cas contraire, la séquence ne s’afficherait pas. Pour un usage avancé, il est également possible de masquer, désactiver, ou ajouter une condition de client WinPE pour chaque séquence de taches.

Sélectionnez la séquence “Windows 8.1 Pro 64 bits” puis cliquez sur “Next” .

Un nom d’ordinateur, commençant par “MININT-…” est automatiquement renseigné, ainsi que la jonction à un groupe de travail “WORKGROUP“.

Dans un prochain article, dédié à la configuration avancée de MDT, nous verrons que toutes ces variables “OSDComputerName“,”JoinWorkgroup” peuvent être contrôlées et renseignées automatiquement via le fichier “customSetting.ini” ou de préférence dans une base de données associée à MDT.

Pour ce premier contact, conservez les valeurs par défaut puis cliquez sur “Next” .

Les 2 écrans suivants correspondent à la phase de migration des données et paramètres d’utilisateur alias “USMT” (User State Migration Tool) – L’utilisation de cette fonctionnalité ne sera pas détaillée ici

Dans cette démonstration, je n’ai pas choisi d’installer l’outillage USMT lors de la configuration du kit ADK. En conséquence, il aurait été judicieux de masquer systématiquement ces écrans en ajoutant la directive “SkipUserData=YES” dans le fichier de configuration global “ControlCustomSettings.ini”

Note : MDT 2013 propose de conserver les partitions existantes afin de préserver le contenu (Directive “DoNotFormatAndPartition=YES“).

Sur le premier écran concernant la sauvegarde, conservez l’option sélectionnée par défaut “Do not move user data and settings“, puis cliquez sur le bouton “Next“.

Sur le second écran concernant la restauration, conservez l’option sélectionnée par défaut “Do not restore user data and settings“, puis cliquez sur le bouton “Next“.

Si l’étape suivante vous demande la saisie d’une clé de licence, c’est que vous avez conservé la directive “SkipProductKey=NO” dans le fichier “Control\CustomSettings.ini“.

Une étape supplémentaire peut apparaître ici, si vous avez ajouté des packs de langues supplémentaires au niveau de la rubrique “packages”. Dans ce cas l’étape vous proposera d’en sélectionner en fonction de vos besoins mais le pack de langue intégré au sein du système d’exploitation choisi sera automatiquement détecté et présélectionné.

L’étape suivante vous demande de valider les préférences régionales du système d’exploitation installé.

Là encore, les préférences du système sont automatiquement détectées et présélectionnées, à l’exception du fuseau horaire. Pour automatiser systématiquement cette étape, et passer cet écran, vous devrez ajouter les directives suivantes dans le fichier “Control\CustomSettings.ini” (Pour des réglages “France Métropolitaine“)

• Pour stipuler le clavier et la langue du système installé
  

  KeyboardLocale=040C:0000040C
  UserLocale=fr-FR
  UILanguage=fr-FR

• Pour stipuler le fuseau horaire
  

  TimeZone=105
  TimeZoneName=Romance Standard Time

• Pour masquer complètement cet écran, il faut 2 directives
  

  SkipLocaleSelection=YES 
  SkipTimeZone=YES

Pour cet exemple, sélectionnez le fuseau horaire approprié puis cliquez sur le bouton “Next“.

Là encore, une étape supplémentaire peut apparaître ici, si vous avez ajouté des applications au niveau de la rubrique “Applications ” du MDT. Une liste vous sera alors proposée afin de choisir facilement celles que vous souhaitez installer. Je reviendrais sur cet aspect particulièrement important dans un prochain article sur la gestion des applications et consacré à ce sujet.

L’avant dernier écran, permettant de stipuler le mot de passe qui sera affecté au compte d’administrateur local s’affichera ou non, selon le choix retenu précédemment. Autrement dit, il s’affichera dès lors que la directive “SkipAdminPassword = NO” est définie dans le fichier “CustomSettings.ini”

Entrez le mot de passe souhaité puis cliquez sur le bouton “Next“.

Le dernier écran vous informe que la séquence est prête à commencer et affiche un résumé des paramètres, en cliquant sur le bouton “Details“.

Notez que les informations affichées ici correspondent en fait aux variables qui pourraient être stipulées dans le fichier de configuration “CustomSetting.ini” ou dans une base de données associée au MDT.

Cet écran peut être masqué en ajoutant la directive “SkipSummary=YES” dans le fichier “CustomSettings.ini”

Cliquez sur le bouton “Begin” pour démarrer l’installation.

Vous pourrez constater que la modification de la barre de titre est bien prise en compte.

Le processus d’installation est relativement long, mais ne nécessite plus aucune intervention humaine, jusqu’à son achèvement. A la fin de cette séquence, un écran de résumé des éventuelles erreurs rencontrées sera affiché.

• fond blanc : Aucune erreur
• fond jaune : Avertissements non bloquants
• fond rose : Erreur(s) bloquant(s) – La séquence a échouée

Bien que ce réglage puisse être gênant au début, cet écran peut également être masqué via la directive “SkipFinalSummary=YES” dans le fichier “CustomSettings.ini”. Toutefois, j’attire votre attention sur le fait que la session reste ouverte avec le compte administrateur en fin de déploiement, et donc exposé aux indiscrétions et malveillances éventuelles. En ajoutant une directive telle que “FinishAction=LOGOFF“, vous pourrez définir le comportement souhaité (“LOGOFF | SHUTDOWN | RESTART | REBOOT”) à l’issue du déploiement.

Test Facultatif :

La démonstration peut être achevée ici, toutefois, à partir de ce poste fraichement installé, essayez de démarrer la même séquence de tache, en connectant un lecteur réseau sur la ressource “WDS-MDTDeploymentShare$” puis en exécutant le script “ScriptsLiteTouch.wsf“.

Vous serez invité à sauvegarder les paramètres et remarquerez que le scénario de déploiement sera de type “REFRESH” et non plus “NEW COMPUTER“.

B. Les journaux d’activité et d’erreurs

Si vous rencontrez des difficultés, notez que MDT gères de nombreux journaux d’activité et d’erreurs. Les principaux (à mon avis, les plus significatifs) sont “BDD.log” et “smsts.log“. Le premier est plutôt “très fourni” du fait qu’il consigne l’ensemble des différents journaux du MDT. Le second est plutôt utilisé pour identifier des anomalies sur les séquences de taches.
L’emplacement de ces journaux change en fonction de l’avancement du déploiement :

• [Avant] sous WinPE : “X:\MININT\SMSOSD\OSDLOGS”
• [Pendant] sur l’ordinateur “C:\MININT\SMSOSD\OSDLOGS”
• [Après] sur l’ordinateur “%WINDIR%\TEMP\DeploymentLogs”

Pour terminer, sachez que ces journaux peuvent être ouverts et consultés via le bloc-notes mais la lecture risque d’être délicate et fastidieuse. Pour faciliter la lecture de ces journaux, vous pouvez également utiliser “CMTrace” (anciennement Trace32.exe) qui fait partie de l’outillage “Microsoft System Center 2012R2 Toolkit” disponible à l’adresse suivante : SC 2012 R2 Toolkit

Exemple d’affichage du journal “BDD.log” dans “CMTrace”

Complément facultatif : Durant les phases de développement, il est possible de centraliser les journaux sur le serveur MDT, mais cela engendre un trafic supplémentaire sur le réseau. Pour cela, vous devez créer un dossier partagé et accessible en lecture/écriture, comme par exemple “WDS-MDT\Logs“, puis ajouter l’une des directives suivantes dans le fichier “Control\CustomSettings.ini“.

SLShare=192.168.100.201\Logs
SLShareDynamicLogging=192.168.100.201\Logs

Préférez l’adresse IP du serveur afin de s’affranchir de la résolution de nom.

Note : A des fins de traçage et d’inventaire, sachez que les déploiements réalisés via MDT laissent des informations dans le registre “HKEY_LOCAL_MACHINE\Software\MicrosoftDeployment\4” telles que la méthode, le type et la date de déploiement, ainsi que l’identifiant, le nom et la version de la séquence de tache utilisée.

 

VI .Conclusion et consignes

Cette longue présentation vous a démontré comment débuter avec MDT. Il faut bien reconnaître que c’est un peu long d’alimenter cette structure au début, mais c’est un capital qui va fructifier et évoluer au fil du temps

Vous pouvez récupérer facilement vos travaux en ajoutant une structure MDT existante via le menu “Open Deployment Share“.

Faites toutefois attention aux versions de MDT. En effet, si vous tentez d’ouvrir une structure MDT existante à partir d’une version supérieure à celle utilisé pour sa création, vous serez invité à mettre automatiquement la structure. Toutefois, le retour arrière ne sera plus possible. Si vous utilisez plusieurs versions de MDT, vous devez vous astreindre à utiliser plusieurs structures MDT distinctes.

A l’heure où je rédige ces lignes, la disponibilité Windows 10 est annoncée pour les prochaines semaines. Ceci induit une mise à jour de version avec MDT 2013 Update1 (technical preview) permettant de déployer ce nouveau système d’exploitation. Vous devrez préalablement télécharger et installer le nouveau kit “Windows 10 ADK”, incompatible avec la version actuelle de MDT2013.

Afin de poursuivre cette présentation des solution de déploiement Microsoft, je vous propose de consulter mon tutoriel sur WDS  – A paraître très prochainement.

 

Un expert Windows a découvert un programme bloquant WS Update sous les versions XP à 8.1.

Cet expert est Patrick Barker, expert en bug, et expert Windows, a découvert mardi dernier qu’un programme signé numériquement Samsung bloque Windows Update. Bien entendu, cela n’affecte que les appareils Samsung. Ce programme bloquant les mises à jour Windows favorise donc le PC à de potentielles failles de sécurité.

D’après l’expert, la cause serait le programme de mise à jour Samsung (SW Update), qui désactiverait le service Windows Update. Samsung a son propre gestionnaire de mises à jour afin que leurs appareils bénéficient d’une compatibilité accrue en terme de pilotes et afin que leurs appareils disposent également de leurs logiciels tiers.

Un manque de bon sens de la part de Samsung

L’expert a découvert le programme (Disable_Windowsupdate.exe), celui-ci s’installe sous les versions XP à 8.1 de Windows. Il a contacté le support, ce dernier a justifié cette anomalie : “Par exemple, si un ordinateur portable dispose de l’USB 3.0, les ports peuvent ne pas fonctionner avec l’installation des mises à jour. Donc, pour éviter cela, l’outil SW empêche les mises à jour Windows”. La question posée est maintenant : Faut-il préférer une machine s’exposant plus facilement aux failles, ou bien avoir un port USB désactivé ?

La rétorque de Microsoft

Microsoft affirme avoir pris connaissance du problème, et s’engage à travailler avec Samsung pour corriger ce problème. Le porte-parole de Redmond déclare : “Nous ne recommandons pas de désactiver ou modifier Windows Update en aucune façon, car cela pourrait exposer un client à des risques de sécurité accrus”. Actuellement, aucune solution n’a encore été trouvée du côté de l’utilisateur.

Désinstaller SW ou WS Update n’est d’aucune utilité, puisque WS Update ne peut être désinstallé en son intégralité, et SW Update se réinstallera dès le démarrage de la machine.

Source

I. Présentation

En tant qu’informaticien, il est fréquent de devoir réaliser des documentations dans le cadre de ses missions en entreprise. Parfois, il peut être nécessaire d’intégrer des lignes de code, que ce soit un script ou le code d’un programme. Le logiciel Notepad++ est utilisé par de nombreuses personnes, moi le premier, et comme vous le savez il colore le texte afin de le rendre plus agréable à lire.

Un simple copier-coller de Notepad++ vers Word ne permet pas de conserver les couleurs du texte, alors, comment procéder ? La réponse dans ce tutoriel.

II. Procédure

Ouvrez Notepad++ ainsi qu’un fichier contenant du code colorisé. Ensuite, cliquez sur “Compléments” et sous “NppExport” cliquez sur “Copy HTML to clipboard“. Le contenu de votre script sera alors copié dans le presse-papier. Il est à noter que le plugin “NppExport” est présent nativement dans Notepad++.

Maintenant, ouvrez un document Word et collez le texte. Par magie, le texte sera collé avec ses couleurs à l’identique que dans Notepad++ !

J’en conviens, cette procédure est vraiment toute simple, mais elle est à connaître pour réaliser de belles documentations. C’est tellement plus agréable de lire un script coloré qu’un script unicolore…

I. Présentation

Nous aborderons ici les principaux éléments nécessaires pour écrire son plugin de supervision. Pour rappel, les plugins, ce sont des scripts exécutés pour réaliser un contrôle. Ils retournent des informations qui seront ensuite interprétées par le système de supervision. Les plugins sont intégrables à n’importe quel outil de supervision du moment qu’il interprète de manière identique les retours décrits dans cet article. À ma connaissance, je n’ai pas d’exemple d’outils ne respectant pas ces règles.

Ici le but est de comprendre le principe du plugin afin que vous puissiez ensuite adapter le vôtre. Vous pourrez l’écrire dans le langage de votre choix, à vous de voir ce qui est le plus adapté pour votre script. Vous trouverez souvent en cherchant un peu sur le net un script qui correspond à vos besoins. Parfois, ils ne seront pas totalement adaptés ou bien pires, vous ne trouverez pas ce que vous cherchez! Dans ce cas vous devez vous lancer dans la création de votre plugin. Ou bien vous pouvez le faire tout simplement pour le fun :). Ready ?!

II. Les codes de retour

La première base indispensable pour votre plugin, retourner un code pour déterminer l’état de votre contrôle. Selon le « type » de votre plugin (hôte ou service) les codes retournés seront différents :

Pour un hôte :

• 0 : UP
• 1 : DOWN

Pour un service :

• 0 : OK
• 1 : WARNING
• 2 : CRITICAL
• 3 : UNKNOWN

En théorie vous n’aurez jamais besoin d’écrire un plugin pour un contrôle d’hôte. Le contrôle d’hôte détermine si votre équipement est en vie ou non. Par défaut (et dans la majorité des cas) c’est un ping et ça fait son job !

III. Messages de sortie

La deuxième partie à retourner dans votre script sont les messages de sorties. Ils sont de 3 types :

A. OUPUT

Il donne un descriptif rapide du contrôle. C’est le minimum obligatoire, sa taille est limitée à 255 caractères.

Cette sortie sert dans l’affichage des contrôles. Ses données :

Vous pourrez récupérer ces valeurs sur votre système de supervision dans la macro $SERVICEOUTPUT$.

B. LONGOUTPUT

Cette sortie donne les détails sur le contrôle effectué. Elle sert à retourner des informations complémentaires à la sortie principale. Elle n’est pas obligatoire, vous pourrez récupérer ces valeurs sur votre système de supervision dans la macro $LONGSERVICEOUTPUT$.

C. PERFDATA

Ou données de performances. Optionnels également, elles sont utilisées pour générer des graphiques. La sortie des données de performance est « normalisée » afin d’élargir les compatibilités entre les outils.

Voici une sortie complète de type perfdata : ‘label’=value[UOM];[warn] ;[crit];[min];[max]

Seuls le label et la valeur mesurée sont obligatoires. Si le label contient des espaces, il faut l’entourer de simples quottes. Concernant les unités, vous avez le choix parmi les suivantes.

• Secondes : us, s et ms
• Bytes : B, KB, MB, GB, TB
• Pourcentage : %
• Nombre entier : c

Ces données stockées précieusement permettront de créer des graphs. Vous pourrez retourner plusieurs séries de données de performances, sur vos graphs apparaitrons alors une courbe pour chaque série. Pour différencier deux séries, entre chacune d’entre elles nous mettrons un espace.

Exemple :

/=1300MB;15329;17244;0;19159 /home=1300MB;15329;17244;0;19159

IV. Mettre en forme la sortie

Comme précisé juste avant, tout plugin doit retourner au moins une ligne de texte sur la sortie standard et renvoyer un code de retour compris entre 0 et 3. On appelle la sortie standard STDOUT.

Prenons le script, ou plutôt les lignes de code suivantes en bash :

#!/bin/bash
echo "Attention j'ai un code 2!"
exit 2

Avec ce code vous retournez le strict minimum, vous avez une sortie texte, et un code 2. Si vous voulez intégrer les données de performances, il faudra les séparer de votre sortie texte avec le pipe (|) comme ceci :

#!/bin/bash
echo "Attention j'ai un code 2! | graph1=5000MB;15000;17000;0;19000"
exit 2

Pour rajouter encore une nouvelle sortie texte contenant des informations complémentaires vous pouvez le faire sur la ligne du dessous :

#!/bin/bash
echo "Attention j'ai un code 2! | graph1=5000MB;15000;17000;0;19000"
echo "Pour rappel 2 = critique!"
exit 2

Si vous souhaitez ajouter de nouvelles données de performances, vous pouvez le faire sur la 2eme ligne. Mais toujours avec le pipe pour séparer. Après le pipe, vous pourrez ne mettre que les perfdata. N’oubliez pas qu’il est possible de mettre plusieurs séries de donnés à suivre séparés par un espace, ci-dessous un exemple sur la ligne 2.

#!/bin/bash
echo "Attention j'ai un code 2! | graph1=5000MB;15000;17500;0;20000"
echo "Pour rappel 2 = critique! | ‘graph 2’=16000MB;15000;17500;0;20000 graph_3=18000MB;15000;17500;0;20000"
exit 2

À savoir que votre système se fiche complètement de ce que contient votre script entre la 1ere ligne et la sortie. Il interprète le retour qu’il reçoit, point final. Ceci veut dire qu’en passant ces 3 bouts de code comme un plugins et qu’on simule un contrôle, on obtient ça :

Le code 2 remonte bien une erreur critique et on repère bien la sortie OUTPUT. En cliquant sur les détails nous pourrons avoir la sortie complémentaire LONGOUTPUT et les PERFDATA.

V. Conclusion

Vous avez tous les éléments pour renvoyer une sortie propre et interprétable à votre système de supervision. À vous d’écrire le contenu du script. Je ne suis pas le mieux placé pour donner des conseils en développement, mais essayez d’optimiser au maximum votre code. C’est aussi avec des scripts de qualité qu’on assure la performance d’un système de supervision.