Introduction

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

• Partie 1 : introduction et syntaxe
• Partie 2 : configuration du mode push
• Partie 3 : configuration du mode pull (via smb)
• Partie 4 : configuration du mode pull (via web service)
• Partie 5 : création d’une ressource personnalisée

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Winsows 2012/8 et Windows 2008 R2/7.

Il s’agit de la seconde partie qui traite de la configuration du mode Push. Pour rappel, il existe deux modes d’application d’une configuration avec la technologie DSC :

• Push
• Pull

Ainsi, nous verrons comment le mode Push fonctionne. Nous nous attarderons ensuite sur la configuration du mode push via une ressource. Enfin, j’expliquerai comment appliquer une configuration en mode Push à distance.

Fonctionnement

Le mode Push est le mode par défaut dans Desired State Configuration. Chaque configuration est poussé par l’utilisateur via ligne de commande ou script directement depuis le serveur concerné ou à distance depuis un autre serveur. L’intérêt de la deuxième option est de centraliser les fichiers “.mof” sur un seul serveur. Pour appliquer la configuration il faut utiliser la commande Start-DscConfiguration (comme vu dans la partie 1).

Ressource LocalConfigurationManager

L’une des nombreuses ressources disponibles lors d’une configuration est nommée : LocalConfigurationManager. Cette dernière permet de définir quand et comment seront appliquées les configurations. Elle est décrite dans le lien ci-dessous :

http://technet.microsoft.com/en-us/library/dn249922.aspx

NB : Au 16/12/2013, le lien comporte des erreurs. Nous allons donc voir ici les différents attributs qui peuvent nous intéresser pour le mode Push.

La ressource LocalConfigurationManager s’utilise comme toutes les autres ressources de DSC. Il va donc être nécessaire de générer un “.mof” contenant cette ressource, puis l’appliquer. Pour récupérer la configuration actuelle  du LocalConfigurationManager  du serveur, il faut utiliser la commande :

Le résultat par défaut est le suivant : Les attributs intéressants pour le mode Push sont :

• RefreshMode : La valeur doit être à PUSH.
• ConfigurationMode : Apply, ApplyAndMonitor, ApplyAndAutoCorrect sont les valeurs possibles. Apply définit qu’il faut simplement appliquer la configuration. ApplyAndMonitor ajoute une phase de contrôle et loguera les éventuelles dérives de configuration (dans l’observateur d’événements). ApplyAndAutoCorrect réapplique la configuration après chaque nouveau test, s’il y a une dérive.
• RefreshFrequencyMins : Il s’agit de l’intervalle de temps pour l’actualisation du fichier de configuration. La valeur minimal est 15 minutes.
• ConfigurationModeFrequencyMins : C'est le temps entre chaque vérification de conformité.
• RebootNodeIfNeeded : C’est un booléen autorisant ou non le redémarrage automatique de la machine si celui-ci est nécessaire.

Voici un exemple de script configurant la ressource LocalConfigurationManager :

001 002 003 004 005 006 007 008 009 010 011

Configuration SetPushMode {     Node WEBSRV01 {                 LocalConfigurationManager {             ConfigurationMode = "ApplyandMonitor"              RefreshMode = "Push"             RefreshFrequencyMins = 30         }     } }

On invoque ensuite le bloc Configuration (ligne 1) et on l’applique (ligne 2) afin que la configuration soit prise en compte.

001 002

SetPushMode -OutputPath C:\DSCConfig Set-DscLocalConfigurationManager -Path C:\dscconfig\ -ComputerName WEBSRV01 -Credential "WEBSRV01\Administrator" -Verbose

Ici, les paramètres Credendial et ComputerName sont renseignés permettant d’appliquer la configuration de la ressource à distance.

Pour que la connexion à distance fonctionne, il est nécessaire de pouvoir se connecter en WMI à distance à “root/Microsoft/Windows/DesiredStateConfiguration”. Pour configurer ce pré-requis, il faut se référer à l’article suivant : http://blog.piservices.fr/post/Powershell-Gestion-a-distance.aspx.

Application d’une configuration à distance

Nous avons vu l’application d’une configuration en mode Push lors de la partie 1. Nous verrons donc ici simplement un complément permettant d’appliquer une configuration à distance. On peut ainsi imaginer un script s’exécutant sur un serveur central possédant tout les fichiers “.mof”. Ce script bouclera sur l’ensemble des serveurs d’une liste et lance les commandes de configuration. Dans cet exemple, on considère qu’un fichier “.mof” a été généré dans “C:\DSCConfig”.

Les paramètres utilisés ainsi que les pré requis sont les mêmes que précédemment, seul la cmdlet utilisée change.

Contexte

System Center Configuration manager offre la possibilité de gérer des rapports via SQL Server. Vous souhaitez ajouter le rôle Reporting Services point sur votre site Config Mgr.
Lors de l’installation du rôle, l’assistant vous demande de renseigner une instance Reporting Services Server sur la page Specify Reporting Services Settings. Vous vous trouvez dans une impasse car aucune instance n’est disponible.

Explication

L’implémentation du rôle Reporting Services point s’appuie sur la fonctionnalité SQL Reporting Services.

Il est obligatoire de créer une base de données Report Server Database. Sans cette configuration préalable, le service de rapport n’est pas fonctionnel. Dans ses conditions, impossible d'installer le Reporting Services point dans notre site Config Mgr. La résolution du problème consiste donc à configurer le service SQL Reporting Services.

Résolution

1. Dans un premier temps, vérifier que votre instance SQL comporte la fonctionnalité Reporting Services – Native.

2. Lancer l’utilitaire Reporting Services Configuration Manager

3. Tous d’abord rendez-vous dans l’onglet Web Services URL.

a. Dans cet onglet, il est possible de modifier différents paramètres. Tel que le nom du répertoire virtuel et les paramètres réseaux.

b. Valider la configuration en appuyant sur Apply. Le fait d’appliquer la configuration va permettre de créer la base de données du serveur de rapports. Cliquez sur Apply même si vous n’avez pas modifié les paramètres.

c. Quelques instants plus tard, la zone Results vous informe que le répertoire virtuel a bien été créé. Vous devriez à présent voir apparaitre le lien dans le champ Report Server Web Service URLs.

4. Rendez-vous ensuite dans l’onglet « Report Manager URL »

a. Valider la configuration en appuyant sur Apply.

5. Quelques instants plus tard, la zone Results vous informe que le répertoire virtuel a bien été créé.

6. Le service SQL Reporting Services est maintenant configuré et fonctionnel. Vous pouvez relancer l’assistant Config Mgr pour ajouter le rôle Reporting Services point à votre site 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"

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.

Lors de la création d’un master dans MDT, l’une des des étapes est l’intégration des pilotes. En principes ceux-ci sont généralement extractibles et il est possible de retrouver le .inf permettant l’installation du périphérique. Cependant dans quelques cas, cela n’est pas possible.

Pour pallier à ce problème, l’une des solutions est d’ajouter l’exécution d’un script Powershell dans la séquence de tâches.

Récupération des valeurs sur les postes cibles :

Tout d’abord il est nécessaire de récupérer certaines valeurs sur le modèle d’ordinateur concerné :

# Récupération du model via une requête WMI

$ModelName = wmic csproduct get name

# Récupération de la marque via une requête WMI

$VendorName = wmic csproduct get vendor

Celles-ci vont nous permettre de détecter au moment du déploiement le modèle.

Script à intégrer dans la séquence de tâches :

Le script suivant est celui qui est intégré à la séquence de tâches (ici, le déploiement a été effectué sur un Elitebook 8440p de Hewlett-Packard) :

# Récupération du model via une requête WMI

$ModelName = wmic csproduct get name

# Récupération de la marque via une requête WMI

$VendorName = wmic csproduct get vendor

$ModelName = $ModelName[2].replace(" ", "")

$VendorName = $VendorName[2].replace(" ", "")

if(($ModelName -eq "HPEliteBook8440p") -and ($VendorName -eq "Hewlett-Packard") ){

    Invoke-Expression "ligne_de_commande"

}

On récupère les mêmes valeurs que précédemment et ci ces dernières correspondent aux valeurs récupérées alors on exécute une commande permettant l’installation silencieuse du pilote.