Le Blog Technique

Utiliser MDT/WDS – Partie 2

par Hatem Djelassi | 7 Juin 2013 | Déploiement (MDT, WDS, AIK, SCCM)

Prérequis

Avoir réaliser la partie 1 ou, avoir un serveur avec le rôle WDS et un master généralisé,
Avoir un serveur avec le rôle MDT.

Intérêt de MDT

L’intérêt de MDT est la gestion pour un OS unique de plusieurs tasks sequences, prenons un exemple, une société a trois type d’utilisateurs tous sur le même OS mais utilisant des applications différentes, des machines différentes (en fonction de la division) et nécessitant chacun une configuration spécifique. Plutôt que de créer trois masters (un pour chaque division), MDT permet en n’utilisant qu’un seul master, de paramétrer plusieurs séquences de tâches spécifiques, évitant à l’administrateur de créer un nouveau master si de nouveaux besoins apparaissent.

Plus encore, synchronisé avec l’AD c’est lors du déploiement que la machine ira automatiquement s’enregistrer sur la bonne OU, avec les administrateurs locaux désignés.

MDT est divisé en plusieurs “Deployment Share” qui peuvent contenir plusieurs OS et plusieurs séquences de tâches.

Liaison entre WDS et MDT

Dans le précèdent poste, nous avons vu que lorsque l’on boot en PXE, WDS ne nous propose que les différentes images de boot. Seulement, une fois notre task sequence prête nous voudrons accéder à celle-ci !

C’est lors de l’import du premier OS que nous allons créer ce qui seras l’interface entre WDS et le Deployment Share de MDT.

Lors de l’ajout d’un OS à un Deployment Share, MDT va générer un ISO nommé ‘LiteTouchPE’, il s’agit d’un « petit Windows » qui va nous permettre de booter et de choisir une task séquence.

Cet ISO est stocké dans :

[DeploymentShare]\Boot\LiteTouchPE_x64/86.iso

Pour accéder au Deployment Share lors d’un démarrage en PXE il va falloir ajouter l’ISO généré dans le dossier ‘Boot Images’ de l’interface WDS.

Import d’une image sysprepé

Après avoir créé un Deployment Share, la première chose à faire est d’importer une image dans le dossier Operating System.

Clique-droit sur ‘Operating Systems’ puis ‘Import Operating System’ :

Sélectionner ‘Custom image file’ puis choisir le fichier .WIM créé dans la partie 1, le sysprep ayant déjà été réalisé choisir ‘Setup and Sysprep files are not needed’ :

Puis terminer l’assistant d’installation.

Task Sequence

Une fois la task sequence créé, il faut lui indiquer l’OS contenu dans le Deployment Share à utiliser :

Et enfin ajouter les applications à installer, par défaut l’étape est déjà présente dans une task sequence tout juste créé, je recommande d’ajouter une étape par application, et de les placer après celle déjà présente (encadré en bleu).

Lorsqu’un changement est fait sur un Deployment Share, il faut actualiser ce dernier :

Choisir ‘Optimize the boot image updating process’ puis terminer l’assistant

Applications

Lorsqu’une application est ajoutée, MDT vous demande comment l’installer et ce via la ‘Quiet install command’, par exemple pour Office, c’est la commande :

setup.exe /config WW\config.xml

Vous l’aurez compris, tout dépend de l’application à installer. Pour office (et la plupart des applications Microsoft, on utilise un fichier de config au format XML où toute la configuration y est indiquée.

Pour d’autre applications, comme celles de Symantec, qui n’utilisent pas de fichier de config, il faudra trouver les bonne commande pour l’installation silencieuse, le lien suivant présente les commandes utilisées par les produits Symantec :http://www.symantec.com/business/support/index?page=content&id=TECH83882.

Configuration de MDT

Afin d’augmenter la productivité de MDT, les deux points suivants sont à configurer comme ceci.

Rules

[Default]
DriverSelectionProfile=Nothing
SkipTaskSequence=YES
TaskSequenceID=
OSInstall=YES
SkipAdminPassword=YES
SkipApplications=NO
SkipAppsOnUpgrade=YES
SkipBDDWelcome=YES
SkipBitLocker=YES
SkipCapture=YES
SkipComputerName=NO
SkipComputerBackup=YES
SkipDeploymentType=YES
DeploymentType=NEWCOMPUTER
SkipDomainMembership=YES
SkipFinalSummary=No
SkipLocaleSelection=YES
KeyboardLocale=fr-FR
UserLocale=fr-FR
UILanguage=fr-FR
SkipPackageDisplay=YES
SkipProductKey=YES
SkipSummary=YES
SkipTaskSequence=NO
SkipTimeZone=YES
TimeZone=105
TimeZoneName=Romance Standard Time
SkipUserData=Yes
UserDataLocation=AUTO
JoinDomain=
DomainAdmin=
DomainAdminDomain=
DomainAdminPassword=

Bootstrap.ini

[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES
KeyboardLocalePE=040c:0000040c
DeployRoot= »Chemin du deployment share »
UserID= »Utilisateur ayant les droits d’accès au deployment share »
UserDomain= »Nom du domaine »
UserPassword= »Mot de passe du userID »

Installation de Windows (x64) sur une partition GPT

par Hatem Djelassi | 6 Juin 2013 | Déploiement (MDT, WDS, AIK, SCCM)

Depuis l’apparition de l’UEFI (Unified Extensible Firmware Interface) supposé à terme remplacer le BIOS, les disques MBR laissent peu à peu leurs place aux disques GPT qui permettent par disque physique la cohabitation de 128 partitions de 9,4 milliards de To ce qui laisse loin derrière le BIOS et ses 4 partitions de 2,2 To par disque…

Lorsque l’on tente de réinstaller Windows via une clé USB sur une partition de disque en GPT l’erreur suivante apparait :

“Windows cannot be installed on this disk. The selected disk is of the GPT partition style.”

Ce message d’erreur bien peu bavard ne dit rien sur la cause de l’échec, si ce n’est que la partition est de type GPT. L’erreur ici vient en fait de la clé USB, n’étant pas reconnue comme un périphérique compatible UEFI, c’est le BIOS qui prend la relève, et celui-ci voit les partitions GPT uniquement comme étant réservées au données, donc impossible d’y installer d’OS.

Cependant, en modifiant la structure des fichiers d’installation de Windows sur la clé USB, l’installation se déroule comme prévue.

Step 1 – Formater la clé en FAT32

Et oui FAT32 est le format utilisé par l’UEFI, inutile de s’inquiéter pour le moment les fichiers d’installation de Windows 7 et 8 ne dépassent pas les 4Go, de plus le mode de compatibilité permet d’utiliser le NTFS.

Step 2 – Copier les fichiers d’installations à la racine de la clé

Step 3 – Récuperer le fichier bootmgfw.efi

Depuis une version x64 de Windows installée sur un système UEFI, récupérer le fichier bootmgfw.efi disponible à cet emplacement : C:\Windows\Boot\EFI\bootmgfw.efi

Step 4 – Modifier l’emplacement du fichier boot

Modifier l’emplacement du fichier boot depuis G:\efi\microsoft vers G:\efi.

Step 5 – Renommer et déplacer bootmgfw.efi

Renommer bootmgfw.efi en bootx64.efi et le copier vers G:\efi\boot.

Maintenant que la clé est prête, l’erreur apparue plus tôt n’est plus là, et l’installation de Windows peut continuer normalement.

Powershell : Définir la liste d’adresse par défaut d’Outlook

par Florian Alikoff | 5 Juin 2013 | Exchange 2010, Poste de travail, PowerShell

Problème rencontré

Lors d’une migration Exchange inter organisation visant à la consolidation des infrastructure de messagerie des filiales d’une entreprise, il s’est présenté la problématique suivante. Il fallait que les utilisateurs aient accès dans leur client Outlook à une liste d’adresse correspondant à leur filiale. Cette dernière devait être la liste visible par défaut.

Solution proposée

Pour se faire, il est nécessaire de modifier une clé de registre sur les postes clients.
Dans la ruche : "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\", sont listés les profiles du client Outlook. Une ruche est présente dans chacun de ceux-ci : "9207f3e0a3b11019908b08002b2a56c2". Celle-ci contient la clé "01023d06" qui définit la liste d’adresse qui sera affiché par défaut à l’ouverture du carnet d’adresse. Attention la valeur est encodé au format Bytes HEX. Nous verrons comment la définir.

S’agissant d’appliquer une modification du registre à l’ensemble des postes clients d’une filiale, la solution la plus simple était d’implémenter cela dans le login script. Cela sera fait en Powershell. Il est bien entendu aussi possible de réaliser cette opération en VBS.

Il est à savoir que la vue par défaut du carnet d’adresse est la "Global Address List". De plus, si une valeur erronée est inscrite dans la clé de registre (ne correspondant à aucune liste d’adresse) alors Outlook repositionnera automatiquement le carnet d’adresse sur la liste d’adresse globale.

Récupération des paramètres

Afin de connaitre la valeur que nous devons positionner sur la clé "01023d06", il faut paramétrer manuellement Outlook afin de récupérer la valeur que l’on devra positionner. Pour cela, on définit la liste d’adresse sur laquelle on souhaite que nos utilisateurs se trouvent par défaut.

Ensuite, on peut ouvrir la clé de registre qui nous intéresse et observer sa valeur.

Si l’on modifie plusieurs fois cette valeur, on remarque le phénomène suivant. Elle se découpe en 3 parties :
– Une première qui est généré dynamiquement par utilisateur (avant le trait rouge)
– Une seconde qui est fixe qui va nous être utile pour récupérer la partie dynamique (entre le trait rouge et vert).
– Une troisième partie fixe (après le trait vert).

Ces trois éléments ont toujours une longueur fixe.

Il faut ensuite reformater les deux dernières parties sous forme de tableau de bytes. Il suffit devant chaque valeur en byte d’ajouter “0x” et de mettre une virgule entre toutes les bytes (syntaxe d’un tableau en Powershell).
Exemple :

01 00 00 00 00 01 00 00 2F devient 0x01,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x2F. Dans le script cette valeur sera définit par la variable $GALSuffix.

67 75 69 64 3D 38 42 34 39 43 31 36 34 45 44 35 41 36 34 30 39 34 42 30 42 4236 35 43 34 45 38 46 39 42 39 00 devient 0x67,0x75,0x69,0x64,0x3D,0x34,0x38,0x42,0x34,0x39,0x43, 0x31,0x36,0x34,0x45,0x44,0x35,0x41,0x36,0x34,0x30,0x39,0x34,0x42,0x30,0x42,0x42, 0x36,0x35,0x43,0x34,0x45,0x38,0x46,0x39,0x42,0x39,0x00.

Dans le script cette valeur sera définit par la variable $GALDefaultValue.

Script

Ci-dessous, le script commenté, où l’on va appliquer les paramètres que l’on a récupéré précédemment. Ceux-ci seront comparés avec ceux que l’on retrouve dans la clé de registre "11023d05" qui contient une configuration de sauvegarde. Cela permet de récupérer la première partie qui est dynamique.

Entre la ligne 37 et 47 on compare un à un les bytes rencontrés dans la clé de registre "11023d05" afin de retrouver l’index ou se trouve le tableau de bytes contenu dans $GALSuffix. Une fois cette valeur obtenue, on sait que la partie dynamique à rechercher est définie dans les 20 bytes précédentes.

Toutes les astuces #tech des collaborateurs de PI Services.

Retrouvez les articles à la une