Déploiement systèmes

Mise en contexte

  • ​Objectif du projet :

 

Le service infrastructure d’Emin Leydier Emballages et Service avait besoin d’une solution de déploiement de systèmes d’exploitation. Elle aura pour objectif d’installer plus facilement et rapidement les ordinateurs sur les six sites concernés.

 

 

  • Analyse de l'existant :

L'infrastructure de déploiement système d'Oyonnax (01) et Châteauneuf-la-Forêt (87), comprenait pour chacun des sites :

 

Un contrôleur de domaine pour le service d’annuaire Active Directory, avec le service DNS et DHCP. Un autre serveur était dédié au déploiement système avec le service WDS et au déploiement des mises à jour système avec WSUS. D'autres font office de serveur KMS, pour l'activation de Windows 7 et 8.1, ainsi que pour Microsoft Office 2013.

  • Contraintes : 

La solution trouvée devra être efficace et efficiente. Elle ne concernera pas l'entité Les Papeteire Emin Leydier, car les besoins ne sont pas les mêmes.

On pourra automatiser l'installation des applications nécessaires aux différents services de l’entreprise, avec les pilotes adéquats pour chaque modèle d’ordinateur en parc.

On pourra choisir l’installation d’un Windows 7, d’un Windows 8.1 ou d’un Windows 10 selon le modèle d’ordinateur.

 

La personnalisation des systèmes déployés sera aux couleurs d’Emin Leydier.

Seuls ces deux sites ont un service informatique, il faudra donc se déplacer sur les quatre autres sites pour installer les ordinateurs physiquement. En cas d'urgence, nous avons des référents informatiques pour aider. Il est toujours possible d'envoyer l'ordinateur déjà déployé et de se connecter à distance pour finir la configuration utilisateur. 

Microsoft Windows sera le type de système d'exploitations déployés.

La solution devra être installé sur les ressources disponibles de l’infrastructure existante.

Réalisations​​​​

  • Veille informatique :

 

J'ai commencé par effectuer une veille technologique pour savoir quelles sont les solutions de déploiement système qui existent aujourd'hui. MDT (Microsoft Deployment Toolkit) a été retenue. Même si sa configuration est assez longue à mettre en place, il est gratuit, adaptable et simple d’utilisation. De plus cet outil a largement fait ses preuves dans diverses entreprises.

 

La solution très onéreuse de Microsoft, SCCM (System Center Configuration Manager) propose un déploiement ZeroTouch. Ce qui est de déployer le système sans aucune aucune interaction humaine. Mais ce n'est pas proportionné à nos besoins. Et l'installation nécessite de très gros pré-requis matériel.

En effet, MDT répond aux différents critères et contraintes définis au préalable.

  • Banc de préparation :

Sur Oyonnax, quand je dois déployer des ordinateurs, je m'installe sur le banc de préparation qui se trouve dans notre bureau. C'est une table avec un commutateur KVM (écran, clavier, souris) de 4 ports. Chaque entrée est munie d'un câble Ethernet qui sont reliés à un switch non manageable HP 12 ports. 

  • Configuration de WDS et PXE :

 

Le service WDS assure la fourniture d’images de démarrage au format .WIM. Cela via PXE, pour que les ordinateurs client puissent charger le noyau système minimaliste WinPE, afin d'initialiser le processus d’installation système par le réseau

Options de l'étendue DHCP :


Le service DHCP est indispensable pour le service WDS fonctionne. En effet il va permettre d'attribuer automatiquement une adresse IP à la machine cliente et afin de pouvoir le faire.

 

Il faut ajouter les options d’étendues suivantes sur le serveur :

   - Option 66 : Nom d’hôte du serveur WDS : x.x.x.x
   - Option 67 : Nom du fichier de démarrage : boot\x86\wsdnbp.com


Si les deux services sont installés sur le même serveur, le service DHCP écoute sur le port serveur 67 et rentre en conflit avec l’option DHCP 67 du NBP (Network Boot Program) de WDS.


Il faut cocher ces deux cases, dans l'onglet DHCP des propriétés du serveur :

Le serveur DHCP d’un Windows Server ne comporte pas l’option PXE dans la liste de ses options. Pour l’ajouter, il faut passer par l’invite de commande en élévation de privilège, pour utiliser le logiciel utilitaire netsh :


   >netsh
   >dhcp
   >server \\<OYO-ELE-MDT>
   >add optiondef 60 PXEClient String 0 comment=PXE support
   >set optionvalue 60 STRING PXEClient


Cela débloque ensuite la fonction dans la console de gestion DHCP :

   - 60 : PXE support .

 

Plage IP de l'étendue DHCP : 

J’ai décidé de dédier seulement 153 octets pour la page d’adresse IP, car je ne déploierais jamais autant d’ordinateurs simultanément. Et pour éviter la saturation des baux disponibles, j’ai configuré une limite de baille d’un jour seulement.

Démarrage PXE :

Etape de boot PXE, pour démarrer sur l’une des deux images de démarrage WDS :
   - Il est nécessaire d’appuyer sur la touche F12, au démarrage de l’ordinateur client pour déclencher le démarrage sur le         réseau.
   - Et une nouvelle fois pour valider la détection du serveur DHCP.

 

  • Configuration des deux switchs HP de la salle serveur :


J'ai configuré le switch cœur de réseau des deux sites. Pour donner l'identifiant du VLAN MDT à la prise du banc de préparation, et donc aussi, au switch non manageable installé sur la table.

Les étapes pour créer et configurer le VLAN dédié :

   - Sélectionner le vlan 12 et le nommer.
   - Saisir l'adresse IP et le masque de sous-réseau du VLAN, l’adresse IP sera la passerelle par défaut de ce réseau.
   - Activer le mode DHCP relay, pour pouvoir communiquer avec le bon serveur DHCP.
   - Sélectionner le serveur MDT comme serveur DHCP.

 

#

vlan 12

name vlan MDT

#

#

interface vlan-interface12
 description vlan MDT
 ip address x.x.x.x x.x.x.x
 dhcp select relay
 dhcp relay server-address x.x.x.x

#

 

Configurer le port relier de l’Atelier SI :

   - Configurer le port en mode access VLAN 12, car seul le vlan 12 a besoin d’être identifié.
   - Stp edged-port est un type de protocole RSTP. Cela active le port en mode forwarding quand il est directement                   connecté un ordinateur client, ou un switch non manageable et permet d'activer la liaison plus rapidement.


#
interface GigabitEthernet1/0/43
 description Atelier SI
 port access vlan 12
 stp edged-port
#

J'ai ajouté ce VLAN à la configuration du trunk des ports dédié aux serveurs de virtualisation. 

Grâce à cela, les flux réseaux sont réduit, car WDS fonctionne beaucoup avec le broadcast. Mais j'ai aussi sécurisé aussi les PC clients, car je peux démarrer en PXE seulement via le port Atelier SI. Cela évite le risque, qu’un utilisateur mal expérimenté formate sa partition avec un nouveau déploiement, en cas de défaillance sur le disque dur.

Connexion réseau de la machine virtuelle : 

Ayant installé le service DHCP directement sur le serveur MDT, pour qu'il puisse distribuer des baux sur le VLAN MDT. J'ai configuré un groupe de port sur notre hyperviseur, pour identifier le VLAN MDT sur le serveur MDT. Et configurer l'étiquette réseau de la carte réseau virtuelle, pour lui indiquer ce groupe de port.

Sites ans Services :

Et j'ai déclaré ce nouveau sous-réseau sur le service "Sites and Services" de nos contrôleurs de domaine, pour les annoncer dans la topologie physique de notre infrastructure Active Directory.

  • DeploymentWorkbench et DeploymentShare :

MDT se configure avec une console graphique de type MMC (DeploymentWorkbench), son objectif est de fédérer des sources, en réaliser l’assemblage et proposer des séquences de tâches pour piloter le tout.

Au niveau de la ressource partagée ou aussi appelé point de distribution (DeploymentShare$ par défaut), on distingue particulièrement des dossiers qui contiennent les fichiers suivants :


   - Boot : WIM et éventuellement .ISO correspondants aux images WinPE (LiteTouche.wim).
   - Operating Systems : Les sources des distributions Windows (copies intégrales des CD ou DVD d’origine ou images             .WIM issues de capture de référence)
   - Out-of-Box Drivers : les pilotes tiers au format .INF nécessaires aux images WinPE et aux systèmes d’exploitation à                installer.
   - Control : Contient les séquences de tâches à exécuter dans des sous-dossiers, ainsi que la plupart des fichiers .xml de         configuration du MDT. C’est là où se situent les 2 fichiers .INI particulièrement intéressants et importants que sont               “bootstrap.ini ” et “CustomSettings.ini”.

  • Génération du client LiteTouch :

Après chaque modification apportée aux DeploymentShares, une régénération du client LiteTouch est nécessaire. Il est même parfois obligatoire d’utiliser l’option « Completely regenerate the boot images » qui permet de créer une image "propre" après d’importantes configurations, ou par exemple si des modifications des drivers WinPE ont été faites.

 

C’est ensuite cette image WinPE, nommée par défaut LiteTouchePE_x64.wim que j’insère dans l'image de démarrage WDS, afin la lancer en PXE.

  • Permissions Active Directory :

Le compte MDT_BuildAccount est un simple compte utilisateur du domaine dédié à MDT. Il est utilisé pour se connecter au partage de déploiement.


Un droit de lecture et d’exécution est configuré sur MDT-Production pour pouvoir déployer :

Un droit de lecture et d’exécution est configuré sur le dossier MDT-Référence pour pouvoir capturer :

  • Image de référence :

La création d’une image de référence est importante parce que cette image sert de base pour les ordinateurs du parc informatique. Il faut qu’elle soit la plus propre et stable possible, voilà comment j'ai procédé :


   - L’image de référence doit idéalement être créée sur une machine virtuelle, cela évite qu’on y injecte des drivers de               constructeurs.

   - Installer les applications pour le bon fonctionnement du système :

      - Tous les packages "Redistribuable Visual C++", qui installent les composants d'exécution nécessaires pour exécuter           les applications C++ créées à l'aide de Visual Studio 2015, ceci pour la compatibilité des applications.

      - Ainsi que le Microsoft .NET Framework 3.5 et 4.6, toujours pour la compatibilité des applications. Que j'ai installé                grâce au menu de la TaskSequence, et l’option « Install Roles and Features ».

MDT va aussi faire automatiquement :

   - La mise à jour système avec le service WSUS.   

   - Une capture de l’image directement en extension .WIM, grâce au compte MDT-BuildAccount.
   - Une généralisation sysprep, ce qui efface l’identité de la machine, pour ne pas créer de conflits sur le réseau, dont :
      - L’identification produit.
      - Les paramètres régionaux.
      - Nom utilisateur et société.
      - Nom de l’ordinateur et mot de passe administrateur.

      - ...

  • Les systèmes d’exploitations :

Pour insérer un système d’exploitation dans les DeploymentShare, il faut passer par le dossier « Operating Systems » de la console DeploymentWorkbench.


   - Dans le cas de MDT-Reference : Je télécharge la dernière version des systèmes d’exploitation Microsoft. Et je                        la monte dans un lecteur disque virtuel, grâce au bouton « Monter » du menu contextuel de Windows.
   - Dans le cas de MDT-Production : Je récupère, l’image de référence .WIM capturée précédemment, pour ensuite                   l’insérer dans les TaskSequences crées.

  • La TaskSequence :

 

J'installe différentes versions du système d’exploitation Microsoft Windows, selon la génération de modèle d’ordinateur que nous avons en parc. Toujours en version professionnel et sous l’infrastructure x64.

​MDT propose différents modèles de TaskSequence, mais j'utilise seulement la « Standard Client Task Sequence » qui est la configuration par défaut pour le déploiement d’ordinateurs clients.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Installation de pilotes :

 

Extension .CAB :

 

Pour installer notre parc informatique composé d'ordinateurs de deux constructeurs différents. Sur leur site, j'ai téléchargé les pilotes de chaque modèle au format .CAB.

Out-Box-Of Drivers :


Pour l’installation des pilotes, il est important de configurer correctement l’arborescence du dossier Out-Box-Of Drivers de la console DeploymentWorbench, cela est nécessaire pour que la TaskSequence repère correctement les bons pilotes à installer.

 

 

 

 

 

 

 

Fichiers driver .inf :


Après extraction du fichier .CAB, les drivers sont injectés dans le DeploymentShare au format .INF. J'ai supprimé les fichiers .INF pour l’infrastructure x86. Ce qui apporte un gain de temps pendant la génération de l’image LiteTouchePE_x64.wim.

Variable %Make% and %Model% pour que la TaskSequence se repère :


Dans chaque TaskSequence, une variable Windows XXx64\%Make%\%Model% y est ajoutée pour que MDT puisse parcourir l’arborescence des dossiers et installer les drivers correspondants au système d’exploitation et au modèle de l’ordinateur déployé.

 

 

 

 

 

 

 

 

Commande WMIC

Pour être certain du modèle des ordinateurs, j’utilise cette commande WMIC, via l’invite de commande sur le PC concerné :
   - wmic csproduct getname

  • Ajout d’un driver comme application :

Problème rencontré et résolution pour les drivers :


Durant l’insertion de certains fichiers .CAB, je me suis rendu compte que certains drivers ne voulaient pas s’intégrer au DeploymentShare, j’ai donc choisi l’option d’installer ces trois drivers comme une application :

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Filtre WMI :


Sur la TaskSequence du système d’exploitation Windows 10, j'ai configuré un filtre WMI aux 3 tâches d’installation de pilote. Pour qu’ils s’installent seulement sur les deux modèles concernés :

 

   - SELCT * FROM Win32_ComputerSystem WHERE Model LIKE “%NOM DU MODÈLE PC%”

 

 

 

 

 

 

 

 


Méthode de déploiement d'application :

Pour configurer l’installation d’une application il faut passer par le dossier Application de la console DeploymentWorkbench.


Pour atteindre notre DFS "Installation" où se trouvent les sources, il faut utiliser un chemin UNC. Si possible avec le FQDN pour assurer la connexion, mais aussi pour améliorer sa rapidité :

 

   - EXE : "\\fqdn\DFS_Installation\Logiciels\application.exe" /paramètres

   - MSI : msiexec /i "\\fqdn\DFS_Installation\Logiciels\application.msi" /paramètres

 

  • Bundles d'application

Pour gérer proprement le déploiement d’application par service, j'ai opté pour l’utilisation de Bundles d’application.

Pour concevoir l’organisation de ces bundles, j’ai créé un tableau sur Google Drive. Pour prendre du recul et voir quel service a besoin de quelle application. J’ai ensuite réalisé un second tableau qui regroupe toute la configuration de nos installations silencieuses. Afin de pouvoir réaliser des tests et valider le bon déroulement des installations à chaque test de déploiement. Ce qui m'a permis de suivre l’avancée de cette étape, qui était la plus grosse partie du projet.


 

Création des Bundles :


J’ai essayé d’organiser mes dossiers d’applications dans la console DeploymentWorkbench de façon à me repérer entre :
   - Les applications installées sur tous les ordinateurs.
   - Celles installés seulement sur les ordinateurs de différents services.
   - Celles dédiés aux ordinateurs portables.

   - Les script de configuration.

   - Les pilotes additionnels.

 

J’ai ensuite créé un dossier qui regroupe les bundles d’application pour :
   - Les ordinateurs fixes.
   - Les ordinateurs portables, seulement pour les services avec des employés nomades.
   - Un Test pour vérifier mes configurations d’installations d’applications.

 

 

 

 

 

 

 

 

  • Configuration du service KMS :


C’est un service permettant de répondre aux demandes d’activation des systèmes en volume. Les ordinateurs clients sont activés sans spécifier la clé d’activation produit. Quand l’ordinateur a besoin de contacter les services d’activation de Microsoft, il ne passe plus par Internet.

Il faut installer la clé de licence KMS sur un serveur correspondant à la même génération du système d’exploitation ou du logiciel à activer sur les ordinateurs clients.


Les ordinateurs clients découvrent l’hôte KMS sur le réseau via le serveur DNS et demandent une activation. C’est ensuite lui qui les stockera et contactera le service sur internet du MHAS, une fois seulement.

Il est nécessaire d’avoir au moins 25 ordinateurs clients s’activant sur le même hôte KMS. Une fois atteint ce compteur atteint, les ordinateurs clients réclamant une activation pourront être activés.


J'utilise la commande slmgr.vbs pour appeler le script qui sert à gérer les activations en volume, avec l’option /dlv pour avoir quelques informations sur l’activation des clients.


Nous sommes client de contrats de licences en volume, donc pour être est plus précis nous passons directement par le portail VLSC de Microsoft pour avoir des informations sur le nombre de licences disponibles.


Nous pouvons donc utiliser un service d’activation hébergé KMS. Ou alors, des clés de produit de type MAK pour nos clients, pour des activations individuelles (non applicables dans ce projet).

Configuration DNS du service KMS pour Windows 10 et Microsoft Office 2016 :

J'ai référencé les nouveaux serveurs KMS dans nos zones DNS, dans le dossier _tcp. En créant un nouvel enregistrement SRV avec les champs suivants :

   - Service : _VLMCS

   - Protocole : _tcp

   - Port number : 1688

   - Nom FQDN de nos serveurs KMS.

  • Service de mise à jour WSUS :

Le service WSUS est installé sur le serveur qui faisait aussi office de serveur WDS, il est maintenant dédié à ce service. Il me permet de maintenir le parc informatique à jour. Mais je m’en sers aussi pour mettre à jour les images déployées de façon à ce qu’elle soit le plus à jours possible.


Je mets l'image de référence MDT à jour tous les trois mois, pour avoir un gain de temps sur le déploiement des images de production.

  • Service de la réplications DFS

Pour pouvoir homogénéiser notre parc informatique d’Emin Leydier Emballages et d’Emin Leydier Services et permettre à mes collègues d’autres sites géographiques de mettre à profit mon travail pour déployer des PC. J'ai choisi de répliquer notre MDT-Production, par le biais du service de réplication DFS-R. Ce service est très rapide, fiable et simple à mettre en place.

Réplications :


Les dossiers locaux du DeploymentShare D:\MDT-Production des deux serveurs MDT sont répliqués la journée avec une limitation de 1Mb/s de la bande passante et la nuit avec aucune limitation.


Grâce à cela, si des petites modifications sont apportées sur un site, le DeploymentShare sera identique sur le second, le temps de que la réplication s’effectue.Si des grosses modifications sont réalisées, MDT-Production sera à jour le lendemain matin.

 

 

 

 

 

 

 

 

 

 

 

 

 


Le service d’espace de nom DFS est obligatoire afin que les ordinateurs clients puissent contacter le DeploymentShare du bon site. Ce service est déjà en production chez Emin Leydier pour nos différents dossiers partagés, dont notre DFS « \\<Nom du domaine>\SI».


Ce sont nos contrôleurs de domaine qui font office de serveur d’espace de nom.
Dans le cadre de ce projet, j’ai créé et configuré l'espace de nom DFS  : « \\<Nom du domaine>\SI\MDT ».


Dans les priorités de ce dossier MDT, dans l’onglet préférence. Il faut cocher l’option « Exclure les cibles en dehors du site client », pour être certain de se connecter sur le dossier du bon site.

 

 

 

 

 

 

 

 

 

 

 

 

 

J'ai configuré à l'identique l'infrastructure de déploiement système de Châteauneuf-La-Forêt. Nous pouvons maintenant déployer via l’espace de nom DFS « \\<Nom du domaine>\SI\MDT », sur les deux sites.

 

 

  • Fichier de configuration CustomSettings.ini et Boostrap.ini

 

Pour ces deux fichiers la première propriété est celle des [Settings], elle sert à déclarer des propriétés par défaut [Default] pour nos deux sites. Et des propriétés plus précises avec la propriété [DefaultGateway], obligatoire pour viser les bons dossiers de la DFS.
Pour la propriété [DefaultGateway], nous insérons les deux passerelles par défaut des deux sites dans une variable [OYO] et [CLF], que nous utilisons ensuite pour configurer des chemins spécifiques à chacun des deux sites.

MDT utilise son script ZTIGather.wsf qui est pré-configuré dans la Standard Client Task Sequence. Pour convertir les propriétés de ces deux fichiers en variable, que MDT se sert pour configurer le déploiement.

CustomSettings.ini :


Il y a plus d’une centaine de propriétés disponibles dans ce fichier, pour configurer automatiquement des étapes WinPE, mais aussi des paramètres nécessaires au bon déroulement du déploiement, voici quelques précisions :


Pour [Default] :


J'ai configuré cette propriété pour savoir quelle est la TaskSequence et le modèle d'ordinateur en déploiement :
   - _SMSTSORGNAME=Deploying %TaskSequenceID% on %Model% KVM.

 

Pour configurer l’heure de l’ordinateur et passer l’étape WinPE de cette configuration, celles-ci :
   - TimeZoneName=Romance Standard Time
   - TimeZone=105
   - Display=(GMT+01:00) Brussels, Copenhagen, Madrid, Paris
   - SkipTimeZone=YES

 

Pour MDT-Reference, cette option doit être mise sur NO, pour pouvoir configurer le chemin du dossier de capture de l’image :
   - SkipCapture=NO


Pour [OYO] et [CLF] :
   - Pour pouvoir le serveur de mise à jour durant le déploiement : WSUSServer=http://<Nom du serveur>.<FQDN>
   - Le dossier de logs pour avoir un suivit des déploiements : SLShare=\\<Nom du serveur MDT>.<FQDN>\MDT-Logs$\

J’ai configuré le domaine à joindre et le mot de passe de l’administrateur local grâce :
   - JoinDomain=<Nom du Domaine>
   - AdminPassword=MotDePasse


Il est aussi possible de préconfigurer un compte administrateur du domaine et son mot de passe avec ces propriétés:  DomainAdmin, DomainAdminDomain, DomainAdminPassword. Mais celui-ci apparaît en clair dans le fichier .INI et ceci est contraire à nos règles de sécurités. Donc nous renseignons nos informations d’authentification manuellement.

BootStrap.ini :


Il permet de configurer l’environnement WinPE, il est le premier point d’entrée du déploiement. Il permet de renseigner le chemin du point de distribution lors de l’initialisation du client LiteTouch. Pour ce fichier, vu que la configuration est identique sur les deux sites, je laisse tout dans [Default].

 

Configuration du clavier sous l’environnement WinPE, et aussi sous l’environnement Windows :
   - KeyboardLocalePE=040c:0000040c
   - KeyboardLocale=040c:0000040c

 

Le chemin pour atteindre la DFS MDT :
   - DeployRoot=\\<FQDN>\SI\MDT

 

Configuration pour le compte MDT_BuildAccount
   - UserDomain=<Nom de domaine>
   - UserID=MDT_BuildAccount
   - UserPassword=installation

  • Documentation :

Durant la veille technologie réalisé en début de projet, j'ai fait des tableaux comparatifs de 3 solutions de déploiement système.

Tout au long de la mise en place, j'ai rédigé des procédures pour que toutes les personnes du service sachent comment configurer et utiliser MDT.

 

Conclusion

  • Tableau avantages et inconvénients fait durant la veille :

WDS : 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MDT :

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SCCM :

 

 

 

 

 

 

 

  • Résultats obtenus : ​

 

Sur Oyonnax, grâce au banc de préparation, je peux déployer quatre ordinateurs en une heure.

MDT est en production sur Oyonnax et Châteauneuf-la-Forêt, nous pouvons déployer et remplacer tous les ordinateurs présents sur le parc informatique d’Emin Leydier Emballages et Services.

 

Grâce à DFS-R, les DeploymentShare des serveurs MDT sont identiques.


J’ai passé beaucoup de temps à découvrir chacune des façons de personnaliser les systèmes Microsoft, mais maintenant nous pouvons personnaliser le système à notre image.

 

Seule une modification des bundles est nécessaire si nos besoins applicatifs évoluent.

  • Possibilité d'évolution :

Il est toujours possible d’améliorer la configuration des ordinateurs via les GPO et cela nous permet une meilleure maintenance pour apporter des modifications en cas de problème.

Nous nous orienterons vers la solution SCCM de Saica. Comme tous les autres standards de l'entreprise.

Compétences techniques associées

Administration réseau

Microsoft Deployment Toolkit

Administration système

Compétences humaines associées

Force de propositions

CONTACT
Curriculum vitæ
  • Black LinkedIn Icon

© 2019 By Brice POINTET.