Gestion des partitions dans SCCM

Cela se déroule au sein des séquences de tâche dans l’étape « Partition Disk 0 » dans le but de définir la configuration des partitions sur les futurs postes de travail Windows 7. Voir figure 2.

Il faut cocher la case « Make this the boot partition » afin de stocker les fichiers liés au secteur de démarrage sur la partition « System Reserved » qui ne sera pas chiffré par BitLocker. Nous pourrons ainsi démarrer notre système d’exploitation Windows 7. Il est possible de définir une variable sur une partition qui va nous permettre d’appliquer l’image Windows 7 sur la partition voulue. Pour cela, il suffit de réutiliser cette variable dans l’étape « Apply Operating System ».

Déplacement automatique de WinRE

Windows 7 apporte nativement WinRE lors de son installation. Il n’y a donc plus besoin de charger le média d’installation comme avec Windows Vista pour lancer la console de récupération. Dans le cas de BitLocker, nous avons vu dans la 1ère partie que son déplacement n’était prévu qu’à travers l’assistant dans Windows. Pour rappel, le déplacement de WinRE permet aux équipes Support de démarrer sur WinRE car la partition sur laquelle est stockée WinRE n’est pas chiffrée par BitLocker. Bien évidemment pour accéder au disque système, il faudra taper la clef de récupération BitLocker, ainsi que le mot de passe de l’administrateur local.

Pour revenir au déplacement de WinRE, cela n’est pas prévu dans SCCM. Il faut donc chercher à l’automatiser via script car il n’y a pas de solution magique pour :

• Capturer la configuration actuelle des partitions ;
• Vérifier le statut de WinRE à travers la commande « reagentc.exe » ;
• Attribuer une lettre de lecteur à la partition « System Reserved » afin de pouvoir déplacer notre fichier « winre.wim » pouvant contenir les outils DaRT comme expliqué dans la 1ère partie;
• Modifier les ACL afin d’être autorisé à faire la copie du WinRE ;
• Déplacer l’environnement WinRE ;
• Modifier à nouveau les ACL et modifier les attributs du fichier « winre.wim » afin qu’il soit caché et en lecture seule ;

Réactiver WinRE à travers la commande « reagentc.exe ». Notons que cela va générer un nouveau GUID dans le secteur de démarrage pour WinRE;
Supprimer la lettre de partition attribuée pour la partition « System Reserved ».

Ça fait peur, non ? Ne vous inquiétez pas, un script provenant de MDT est disponible et permet d’effectuer ces opérations simplement.

Dualboot Windows 7 et WinRE

Certaines entreprises souhaitent que WinRE soit proposé à chaque démarrage d’un ordinateur en plus de Windows 7 en cas de problème. Il y aurait donc deux entrées au démarrage, « Windows 7 » et généralement appelé « Dépannage » pour WinRE. Si un problème se produit, il est donc possible aux équipes Support de lancer la console de récupération (WinRE) en sélectionnant « Dépannage ». C’est un choix mais cela est possible par défaut soit par la touche espace F8 au démarrage de l’ordinateur (ou directement par la touche F8 qui est un raccourci vers les options avancées de démarrage), soit via la commande « reagentc.exe /boottore ». Cela est permis car lors de l’installation de Windows 7, une entrée est créée dans le secteur de démarrage pour WinRE. Nous pouvons vérifier la présence de cette entrée en tapant « bcdedit.exe /enum all ». Voir figure 3.

Comme vous pouvez le voir, le chemin du WinRE est spécifié sur la ligne Device. Cet imprime écran représente la configuration par défaut de Windows. Nous n’avons pas encore déplacé l’environnement WinRE. Comme expliqué dans la partie précédente, le déplacement de WinRE impose la génération d’un nouveau GUID représenté par la ligne « Identifier » dans l’outil BCDEdit. L’impact de ce nouveau GUID signifie que si nous voulons automatiser le dualboot de WinRE avec Windows 7, nous allons devoir l’identifier (le parser plus précisément) pendant le déploiement.

Il n’y a toujours pas de magie pour cela mais PowerShell peut s’avérer un bon facilitateur. J’ai mis personnellement du temps à comprendre que le GUID généré après le déplacement de WinRE différenciait d’un seul caractère. Voici un exemple de script PowerShell pour réaliser le dualboot : voir figure 4.

Pour conclure, il faut penser au bon ordonnancement de toutes ces étapes dans la séquence de tâches SCCM.

Pour aller plus loin avec Microsoft SCCM :