La gestion des disques Windows lors d’une Reprise d’Activité Informatique

Une solution de reprise d’activité d’informatique dans un Cloud public se base de manière générale une technologie de virtualisation différente de l’hyperviseur source (souvent VMware/Hyper-V).

Cette différence peut-être la cause d’incidents lors de la restauration des disques Windows lors de l’exécution de la reprise d’activité informatique (PRA).

En effet, lors de la remontée de l’infrastructure système dans le Cloud, les services peuvent ne pas redémarrer et nécessiter une intervention humaine. Cette action peut impacter le délai de redémarrage (RTO) du serveur et ajouter une charge de travail aux équipes opérationnelles.

Qui plus est, lors de l’activation des serveurs, les disques peuvent ne pas avoir la bonne lettre associée. Alors, chaque lettre de lecteur est à changer. Cela arrive généralement quand le serveur a été configuré avec des lecteurs dont les lettres ne suivent pas l’ordre alphabétique. Par exemple : un serveur utilisant les disques C:, U: et W:.

Donc, afin de pouvoir automatiser le PRA dans un Cloud public, le sujet de la restauration des disques Windows devient un sujet d’importance vitale.

Les causes de la problématique de restauration automatique : Online Disk, Root Cause Analysis

Depuis Windows Server 2008 R2, le mécanisme d’activation des disques ne les place pas en ligne automatiquement, ce qui permettrait d’éviter de corrompre les données de disques partagées ou liées à un cluster de fichiers. Ce paramètre affecte tous les disques SCSI dont l’identifiant matériel n’a pas encore été reconnu au préalable par l’OS.

Notre solution, UCover, utilise un Cloud public pour fournir l’infrastructure sur laquelle sont restaurées les données. Nous n’avons pas le choix des identifiants matériels présentés aux OS invités.

Un disque sauvegardé qui, in-situ, est connecté en IDE ou SATA, sera alors présenté sous forme de disque Virtuel KVM ou Xen lors de sa restauration. Le choix du format de restauration se fera en fonction du besoin de performances de la machine. Ce changement entrainera au passage une modification d’identifiants matériels. Le disque est donc bloqué au démarrage par cette protection Windows.

Comment nous avons corrigé et industrialisé ce modèle

Dans UCover, nous avons trouvé un moyen de corriger et d’industrialiser ce modèle pour l’intégrer dans notre solution.
Le mécanisme de gestion des disques est normalement piloté via les outils diskpart (CLI) et la console diskmgmt.msc (GUI). 
Cependant, la correction doit avoir lieu avant le premier démarrage de la machine restaurée, donc à l’instar de l’injection de drivers, il s’agit de modifier le paramètre approprié sans que l’OS ait démarré. Pour ce faire, il est nécessaire d’éditer la base de registre de la machine restaurée, et d’y changer les paramètres de gestion de disques.

Nos investigations ont menées à deux clés de registres : 

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mountmgr
    • propriété « NoAutoMount » => a placer à « 0 » (DWORD)
      • On change ce paramètre afin d’éviter un blocage du montage des disques, analogue à une sécurité que l’on retire.
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\partmgr\Parameters
    •  propriété « SanPolicy » => à placer à « 1 » (DWORD)
      • Ici, on change le comportement de Windows quand un nouveau disque est branché. 1 équivalant à « tous les disques en ligne » (OnlineAll)

Edition de Hive registre Windows hors-ligne pour automatisation

Lors du montage de la hive HKLM d’un serveur restauré, le petit détail qui vient mettre un grain de sable dans la machine, c’est que sous « HKLM/SYSTEM », il n’existe pas de clé « CurrentControlSet ».

En effet, Windows ne stocke dans la Hive que les clés « ControlSet1 » et « ControlSet2 ». « CurrentControlSet » est en fait un lien symbolique vers une des deux sous-clés. L’autre sert de « dernière configuration valide avec lequel le système à démarré ».

Gestion de lettres de lecteur et orchestration

Si nous nous en tenons là, les disques remontent tout seul, mais rapidement un autre problème apparait. Dans certains cas : les disques s’activent bien, mais avec des lettres différentes de celles prévues à la base.

Le lecteur W: est remonté sur D:, et F: remonté sur E: …

Cela n’aide pas beaucoup un administrateur qui devra encore effectuer ce travail de remise des lettres à la main.

Root cause analysis 2 : le retour

L’association entre une partition et sa lettre de lecteur est enregistrée sous « HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ».

A chaque lettre de lecteur est associé une clé de registre, qui conserve la signature de la partition vers laquelle elle pointe.

Par exemple : « \DosDevices\G: »=*Du binaire sous forme hexadécimale ici*

Si aucune lettre ne correspond à une partition, par exemple lors de l’ajout d’un nouveau disque, Windows assigne la prochaine lettre disponible dans l’ordre alphabetique et enregistre la signature dans une nouvelle clé.

Automatisation de la réparation

Dans notre modèle, chaque lecteur Windows est restauré séparément. Il nous est donc possible, en fin de la restauration, d’extraire la nouvelle signature d’un disque restauré.

Lorsque tous les lecteurs d’une machine ont fini leur restauration et nous disposons de toutes les signatures, une étape supplémentaire à été ajoutée au processus automatisé afin de

  1. monter le disque système de la machine
  2. monter le registre HKLM restauré
  3. écraser les précédentes clés de registre avec les nouvelles signatures.

Pour conclure, toute cette procédure a pour but de consacrer le moins de temps possible à exécuter un processus automatisable. Cela afin d’éviter une perte de temps, souvent précieux lors de la restauration de l’infrastructure d’un client.

J’espère que cela vous permets de voir le résultat technique d’une période de recherche et développement face à un problème que nous avons rencontré à de multiples reprises.

Si cela vous interesse d’en savoir plus, venez dire bonjour sur notre Twitter @nuabee_fr !

Pour aller plus loin

Vous souhaitez en savoir plus sur Nuabee et sur nos solutions ?

Pourquoi ne pas commencer par livre notre livre blanc, disponible sur notre page d’accueil en téléchargement gratuit.

Ainsi, vous serez au fait de nos principes fondateurs et de notre mission au quotidien : accompagner les petites et moyennes entreprises françaises dans la gestion de crise cyber. A moindre frais 😉

Nuabee | Spécialiste du Plan Reprise Activité Cloud managé


Ecrit par : Eric Deronzier

UCover by Nuabee, la solution de PRA Cloud innovante

La solution de protection de la totalité de votre infrastructure, avec 3 classes de protection qui vous permettent d'adapter votre solution en fonction de vos besoins.

NUABEE

76 rue Denfert-Rochereau
69004 Lyon
Tel : 04.28.29.79.01

NEWSLETTER

Inscrivez-vous pour ne rater aucune de nos actualités.
Nous n'avons pas pu confirmer votre inscription.
Votre inscription est confirmée !

© 2014–2022 NUABEE. TOUS DROITS RÉSERVÉS.