Erreur 1069 sur cluster Hyper-V 2008 R2

Aujourd’hui, j’ai été confronté à une prolifération d’erreurs 1069 dans le journal d’événements d’une machine Hyper-V sous Windows 2008 R2.

Cette erreur indique qu’un élément présent dans le cluster n’est pas joignable.

Un petit tour dans la console FailOver Cluster Management et je constate qu’en effet, certaines ressources sont indisponibles tandis que les disques attachés le sont toujours.

Etat d’une ressource du cluster

Après une petite recherche, il s’est avéré que les machines en question ont été éteintes dans le cadre d’un projet de démantèlement et que le cluster n’avait pas été nettoyé ; il ne m’a resté qu’à sélectionner chaque machine éteinte et démantelée et à la supprimer du cluster afin qu’il ne reste plus aucune référence.

Création d’un support USB bootable d’installation de Windows

Il y avait aujourd’hui besoin de déployer un Windows Server 2016 sur une machine qui n’est pas supportée par le WDS. Situation habituelle dans un service IT : il y avait 3 clefs USB destinées aux installations de Windows, mais on en a prêté une, l’autre on s’en est servie pour faire du transfert de data, et l’autre… ben y a un 2012 dessus. Du coup, on se retrouve toujours dans la situation où l’on finit par trouver quelque part une clef USB et qu’on doit en faire un support d’installation. Et là, aussi con que ça puisse paraître, il y a toujours la petite question qu’on se pose : « comment on fait pour créer un support d’install de Windows déjà ? »..

Si il est possible d’utiliser par exemple une appli tierce comme Rufus, ou des outils Microsoft, j’ai découvert – à ma grande surprise d’ailleurs – qu’il était possible de réaliser une clef USB bootable d’installation de Windows grâce à diskpart et le fichier ISO du système d’exploitation que l’on va installer.
On ouvre une invite de commande, puis on exécute diskpart.
list disk nous renvoie tous les disques qui sont connectés au système, on va donc select disk xx est bien évidemment le numéro représentant le support USB.
clean efface les partitions présentes ; bien évidemment on aura pris le soin de choisir une clef dont le contenu n’est pas important…
create partition primary pour recréer une partition principale ;
active comme son nom l’indique, active la partition ;
format fs=ntfs quick pour formater ladite partition ; le quick permet de faire un formatage rapide, qui ne dure que quelques secondes ;
Et enfin, on finit par un assign pour donner une lettre dans l’explorateur à cette partition fraîchement formatée.
Ensuite, il ne reste plus qu’à décomposer avec 7-Zip par exemple le fichier ISO d’installation de Windows et à copier les répertoires extraits sur le support USB. Le fichier sources\boot.wim est le fichier qui va permettre au système d’installation de s’amorcer proprement.

Erreur 2203 renvoyée par Windows Installer

En déployant deux serveurs avec une clef USB cause WDS ne fonctionnant pas sur les machines en question, une fois l’installation finie, j’ai eu à installer plusieurs paquets, notamment de drivers, en MSI, nécessitant donc Windows Installer.

J’ai été surpris de rencontrer une erreur 2203 lors de la tentative d’installation du paquet. Après un peu de recherches, cette erreur apparaît lorsque Windows Installer a besoin d’accéder au répertoire temporaire de l’utilisateur (variable d’environnement %TEMP%), mais qu’il ne peut pas, soit car celui-ci n’existe pas, où parce que les droits sont insuffisants.

En ouvrant un cmd, et en tapant cd %temp%, je tombe sur un répertoire inaccessible. Et pour cause : le script post-déploiement que j’ai utilisé pour terminer la configuration de la machine qui va fonctionner en workgroup initialise la valeur du répertoire temporaire de cet utilisateur sur le disque D:, disque qui était le support d’installation de Windows ; en effet, le script a été conçu pour des installation de serveurs standards utilisant deux disques, avec un disque D utilisable.

Les variables d’environnement à régler : TEMP et TMP

Dans mon cas, après avoir modifié la variable d’environnement, fermé et rouvert la session de l’utilisateur, j’ai pu installer correctement mon package MSI. Une erreur toute simple mais qui m’a fait perdre une dizaine de précieuses minutes.

Contourner l’erreur 124 d’installation de Google Chrome

Je ne suis pas un grand fan de Google Chrome, mais il faut parfois bien l’installer et s’en servir pour réaliser du troubleshooting ou s’assurer de la compatibilité de certaines applications ou appels du navigateur par défaut. Et aujourd’hui, en essayant de réinstaller Chrome 64 bits sur un poste d’entreprise après être passé de la version 64 bits à la 32 bits, j’ai eu cette belle erreur, en étant administrateur local de mon poste de travail.

Après avoir trouvé un log portant le doux nom de chrome_installer.log dans le répertoire C:\Users\<mnémonyme\>AppData\Local\Temp, j’y ai trouvé des informations plus ou moins intéressantes :

[1031/165307.958:VERBOSE1:setup_main.cc(1350)]
Command Line: « C:\Program Files
(x86)\Google\Chrome\Application\62.0.3202.75\Installer\setup.exe »
–uninstall –msi –system-level –verbose-logging –force-uninstall
[1031/165307.959:VERBOSE1:setup_main.cc(1356)] system install is 1
[1031/165307.959:VERBOSE1:installer_state.cc(74)] Uninstall distribution: Google Chrome
[1031/165307.959:VERBOSE1:setup_main.cc(1364)] is_migrating_to_single is 0
[1031/165307.970:VERBOSE1:install_util.cc(217)] Windows NT 6.1.7601 SP1
[1031/165307.971:VERBOSE1:installer_state.cc(74)] Uninstall distribution: Google Chrome
[1031/165307.971:VERBOSE1:setup_main.cc(576)] version on the system: 62.0.3202.75
[1031/165307.971:VERBOSE1:uninstall.cc(810)] UninstallProduct: Google Chrome
Apparemment, le setup trouve toujours un Chrome installé sur le système ; un reboot n’y fera rien, pas plus que la suppression des clefs de registre liées à Google Chrome – par ailleurs, le fichier de log fait mention d’un bon nom de clefs que le programme d’installation a supprimé avant de tenter d’installer Chrome 64 bits, sans qu’il précise si c’est cette installation détectée qui fait avorter le processus d’installation, ni même si l’installation qu’il trouve est celle qu’il vient de tenter de réaliser.
Ne pouvant donc trouver la cause exacte de la non-réinstallation de Chrome 64 bits sur le poste – et soupçonnant une restriction liée à une GPO car j’ai eu le cas sur un autre poste de test sur le même domaine et en utilisant le même compte utilisateur -, j’ai donc dû ruser pour tout de même rétablir l’application.
Lorsque le setup télécharge les fichiers de Chrome avant de mentionner l’erreur, il créé un répertoire Google, dans le Program Files x86, avec deux répertoires : CrashReports et Update. Dans le répertoire Update, se trouve un autre répertoire Install, qui contient lui-même un répertoire portant un GUID. Dans ce tout dernier dossier, se trouve le setup complet de Chrome, pesant dans mon cas un peu plus de 44 Mo.
Un petit coup de 7-Zip sur cet exécutable nous donne un fichier chrome.7z, qu’il faudra lui-même décompresser pour obtenir enfin le dossier Chrome-bin qui contient chrome.exe et son dossier de ressources.