Étiquette : WMI

Pas de commentaire

Manipulation du pagefile avec Powershell et scripting diskpart

  de

Récemment, j’ai modifié mon template de machine virtuelle Windows Server porté par VMware pour y intégrer un deuxième disque virtuel afin d’y placer le fichier d’échange de Windows. Seulement, après génération de mon image Windows avec sysprep, mon deuxième disque n’est plus monté sur le système, et par conséquent ma configuration de fichier d’échange est invalide. J’ai donc dû traiter ce problème en deux temps : la première étape a été de faire en sorte de faire un batch pour diskpart afin de monter mon deuxième disque et l’initialiser correctement, et la deuxième étape a été de configurer le pagefile via Powshell afin de pouvoir intégrer le tout dans mon script de post-installation.

Tout d’abord, j’ai appris qu’il était possible de faire avaler à diskpart un fichier texte contenant les instructions qu’il doit exécuter à la suite. Par exemple, si je veux initialiser mon deuxième disque et affecter la lettre E à ma partition, je vais créer un fichier texte nommé « diskinit.txt » contenant ceci :

select disk 1
online disk
select partition 1
assign letter=E

Je conseille tout de même de tester une par une les commandes à la main pour s’assurer que cela fonctionne avant de les placer à la suite dans le fichier. Une fois que le fichier existe, il est possible d’appeler diskpart pour lui demander de traiter celui-ci, grâce au paramètre /s :

diskpart.exe /s diskinit.txt

Puisque cela fonctionne, j’ai dû m’atteler à la gestion du fichier d’échange sous Powershell. Il n’y a pas de commandlet natif sous Windows Server 2016 pour gérer le fichier d’échange comme un paramètre système standard. Il faut passer par WMI. Cette commande permet d’afficher les fichiers d’échange configurés sur la machine, uniquement si le fichier d’échange n’est pas gérée de manière automatique pour tous les disques du système :

Get-CimInstance -ClassName Win32_PagefileSetting

Maintenant que j’ai bien mon disque E:, je peux rajouter mon fichier d’échange sur cette partition et retirer celui présent sur le disque système.

New-CimInstance -ClassName Win32_PagefileSetting -Property @{Name "E:\pagefile.sys"}
Get-CimInstance -ClassName Win32_PagefileSetting | Where-Object { $_.Name -like "C:\pagefile.sys" } | Remove-CimInstance

A noter que cette instruction créée un fichier d’échange dont la taille est gérée par le système. Il est possible de spécifier une taille minimale et/ou maximale, en procédant par exemple comme ceci pour une taille mini de 1024 Mo et une taille maxi de 2048 Mo :

Get-CimInstance -ClassName Win32_PagefileSetting | Where-Object { $_.Name -like "E:\pagefile.sys" } | Set-CimInstance -Property @{InitialSize = 1024; MaximumSize = 2048}

Alternativement, ce qui est passé dans le dernier pipe peut être passé en pipe de l’instruction New-CimInstance exécutée en premier, afin d’avoir le bon réglage dès la création.

Vous pouvez trouver avoir bien plus de détails sur cette classe WMI et un script complet de gestion du pagefile via Powershell en suivant ce lien qui m’a aidé à comprendre et à scripter cette opération. 🙂

Pas de commentaire

Monitoring de serveurs Windows avec PRTG

  de

Ce billet fait suite au précédent, quelque peu similaire puisque je suis en phase d’études pour l’adoption d’un outil de monitoring. Après Cacti, je me suis penché sur l’outil PRTG.

Tout comme Cacti, PRTG utilise SNMP pour récupérer des informations concernant l’état des hôtes qu’il surveille. Cependant, il est également capable d’utiliser par exemple WMI, ce qui est très intéressant dans mon cas puisque je souhaite monitorer uniquement des machines Windows. Par rapport à Cacti, cela m’évite d’avoir à déployer un outil SNMP et à configurer le service. Cet article est donc une introduction à PRTG ; je vais y présenter ma maquette et expliquer les diverses opérations que j’ai réalisé pour surveiller celle-ci.

Sur un serveur Hyper-V 2016, j’ai donc installé les machines suivantes :

  • un DC/DNS en 2019
  • un Server 2019 avec IIS pour la fonctionnalité FTP
  • un Windows 10
  • un Server 2019 avec 2 vCPU et 4 Go de RAM pour héberger PRTG

Première note : je ne sais pas si c’est PRTG qui est gourmand ou si ma console Hyper-V était en souffrance mais avec un seul vCPU l’interface web de l’application était très pénible à utiliser. Avec deux vCPU cela fonctionnait un peu mieux mais sans être spécialement fluide. Cela doit mieux fonctionner en utilisant une station de travail et en passant par le web, il est possible que la console Hyper-V ne soit pas le meilleur moyen d’agir sur des interfaces web chargées, le client lourd étant bien plus agréable.

L’éditeur de PRTG met à disposition une version d’essai presque complète (jusqu’à 10000 sensors) pour découvrir leur application. Le setup se télécharge depuis le site directement et pèse environ 180 Mo. Une licence est fournie. Ce setup devra être exécuté sur le serveur PRTG, l’installation se déroulant simplement à base de Next, next, next.

Il sera nécessaire de copier-coller la clef de licence fournie lors du téléchargement.

Lorsque l’installation est terminée, le serveur s’exécute et le navigateur web apparaît. Cela peut prendre quelques minutes avec des erreurs répétées de connexion, mais rien d’inquiétant.

Connexion à l’interface d’administration avec les credentials par défaut

Le login effectué, il est nécessaire d’activer la licence. Si le serveur n’est pas relié à internet – mon cas pour cette maquette – cela fonctionnera tout de même, il faudra simplement suivre les instructions demandant de se rendre sur le site de l’éditeur pour générer un fichier dont le contenu sera à coller dans le champ correspondant.

L’activation terminée, on arrive sur la page principale.

Quelques sensors sont déjà déployés en fonction de ce que PRTG a trouvé sur le réseau. Ici, on voit qu’il a découvert que la gateway de la carte réseau renvoyait vers un serveur Windows portant les rôles DNS et ADDS. De base, il monitore donc le service DNS et le temps de réponse du serveur. Sur cette capture d’écran, j’ai déjà dégrossi et supprimé pas mal de groupes de base. Comme sur n’importe quel outil de supervision ou de monitoring, les hôtes peuvent bien évidemment être séparés en groupes différents. Je n’ai conservé que ceux qui vont nous intéresser pour la suite.

Afin d’ajouter des hôtes à surveiller, il est nécessaire de valider plusieurs pré-requis : la validité des credentials utilisés par PRTG pour interroger WMI sur les serveurs Windows ainsi que l’activation des règles dans les firewall Windows autorisant l’interrogation de WMI ; les credentials peuvent soit être placés par machine, ou par groupe. Dans cet exemple, j’ai placé ces identifiants à la racine : cela signifie que par défaut, tous les serveurs Windows utiliseront ces derniers pour être interrogés. Bien évidemment, on évitera d’utiliser le compte d’administrateur du domaine pour cette tâche sur un environnement de production 😊

Ce compte sera celui utilisé pour interroger WMI sur les serveurs placés dans ce groupe, ici Root, donc tous les serveurs Windows (si l’héritage est activé).

Ensuite, sur les firewall Windows, activer ces règles, sans quoi les sensors ne remonteront aucune information puisque la communication WMI sera bloquée.

Tous les prérequis ayant été validés, je vais donc procéder à l’ajout d’un device dans PRTG et y coupler des sensors. Un device peut être un serveur, mais également un switch ou une imprimante. Un sensor est tout simplement un indicateur. Rien de spécialement sorcier ici.

Différents templates de sensors peuvent être implémentés en même temps que la création du device. Il est possible de procéder à un ajout nu, à une identification automatique (qui semble plutôt bien fonctionner et ajoute une foultitude de capteurs pour un serveur Windows standard : RAM, CPU, disque, I/O réseau, fichier de pagination…) ou à une création sur base d’un template XML reprenant les divers sensors ajoutés dont la création peut se faire une fois qu’un device a été créé. Plusieurs templates sont proposés de base avec l’installation. Par ailleurs, il est possible d’attacher des sensors à des groupes de devices, qui seront automatiquement ajoutés à la création d’un device dans un groupe.

Je suis parti sur un device nu, sans sensor, car je vais les ajouter moi-même pour bien choisir ce qui m’intéresse. Cela se déroule sur la page suivante, où il est possible de rechercher ce que l’on souhaite monitorer ; on dégrossira la recherche avec des critères (dans ce cas : Windows et WMI).

Pour surveiller et obtenir l’état du CPU, il me suffit de choisir Windows CPU Load dans la liste. Je peux ensuite personnaliser ce sensor : nom, rafraîchissement, etc. En répétant cette opération plusieurs fois, j’obtiens un tableau de bord qui commence à ressembler à quelque chose.

Je peux donc désormais consulter l’état global de mon serveur ainsi que du service FTP installé dessus, avec un historique détaillé pour aller jusqu’à un an (les divers historiques disponibles sont paramétrables, le maximum étant de 750 jours). Pour me faciliter la tâche par la suite, je me suis créé un template : un simple clic-droit sur cette machine dans l’interface suivi d’un clic sur Create Template permet sa réalisation. Ensuite, ce template peut être repris pour importer directement les sensors sur d’autres appareils équivalents.

Deuxième note : la gestion des templates pourrait cependant être améliorée ; celle-ci n’apparaît nulle part sur l’interface. Il n’est donc pas possible de modifier facilement un template une fois celui-ci créé. Après avoir recherché dans l’aide de l’application, j’ai appris que les templates sont des fichiers XML au format ODT qui se trouvent dans un sous-répertoire du serveur PRTG et que leur modification ou suppression ne peut se faire que par ce biais… sous-répertoire inaccessible si l’on opte pour la formule SaaS de PRTG ! On peut alors se demander si il n’est pas préférable de procéder à un clonage (grâce la fonction du même nom disponible) du device lorsqu’on souhaite en déployer un nouveau plutôt que de passer par un template ou d’affecter les sondes à un groupe directement.

Si l’interface web fonctionne bien, il existe un client PRTG nommé Enterprise Console qu’il est possible d’installer sur un serveur d’administration par exemple.

PRTG peut fonctionner avec des Remote Probe. Il s’agit d’installations réduites de PRTG déployées qui possèdent leurs propres devices, tout en étant rattachés au serveur PRTG principal. Cela peut permettre de surveiller des sous-réseaux ou des machines isolées. L’installation se fait en quelques minutes, l’unique prérequis étant d’avoir autorisé les connexions en dehors de la boucle local sur l’hôte PRTG principal.

Cette installation de PRTG ne permet pas de réaliser un cluster, elle est toujours dépendante de l’installation principale.

Les 2 noeuds PRTG sont bien visibles et distincts

PRTG est un outil très puissant et bien plus accessible que Cacti que j’ai pu manipuler auparavant car tous les modules y sont intégrés et développés par l’éditeur. Sa compatibilité avec WMI est un atout indéniable pour moi. Le coût financier peut porter à réflexion car si PRTG est payant et Cacti gratuit, le temps à consacrer pour développer des templates pour Cacti ainsi que l’obtention d’une couche SNMP décente sur Windows capable de renvoyer les informations désirées ne l’est pas.

Pas de commentaire

Introduction au Windows Admin Center

  de

Après avoir déployé mon premier Windows Server 2019 sur une plateforme de tests, j’ai été invité à essayer le Windows Admin Center au premier démarrage. Cet outil se veut être le futur de l’administration des plateformes Windows, serveurs et clientes et souhaiterait bien rendre le besoin d’interfaces graphiques sur les serveurs obsolète.

Basé sur une interface web, le Windows Admin Center – que j’appellerai WAC par la suite – est une grosse évolution du Server Manager qui n’avait pas bougé d’un iota ou presque depuis la sortie de Windows Server 2012. Tout comme lui, il fonctionne principalement grâce à WMI et offre un panel d’options pour gérer des serveurs distants (nativement à partir de 2016, avec une installation supplémentaire sur 2012 R2), mais aussi des postes de travail sous Windows 10, des clusters ou des infrastructures plus complètes, en local ou également dans Azure.

Idéalement, on installe le petit MSI d’une soixantaine de méga-octets du WAC sur une machine d’administration et ensuite on attaque cette interface web depuis n’importe quel navigateur, en local ou à distance.

Connexion à l’interface avec prompt de login.

Bien que l’outil soit utilisable en production selon Microsoft, il y a quand même quelques choix de design qui me perturbent : la connexion se fait via un vulgaire prompt et l’outil n’est pas compatible avec Internet Explorer, mais Edge, qui n’est pas disponible sur Windows Server. Cette restriction – techniquement compréhensible – pourrait se révéler handicapante dans certains environnements où l’administration ne se fait qu’à partir d’un serveur et sur lequel aucun autre navigateur est installé.

Au moins Microsoft ne manque pas d’humour quant à l’abandon d’Internet Explorer !

Pour la suite des événements, j’ai donc dû déployer un Firefox sur mon serveur pour naviguer. L’interface est plutôt agréable, typique des produits Microsoft actuels.

La page d’accueil d’un système présente les informations de base, à peu près comme on pouvait les trouver sur le Server Manager avant.

Très peu de dépaysement mais également très peu de nouvelles fonctionnalités. Ce qui est appréciable, c’est que l’on regroupe sous un même outil le Server Manager mais aussi les différentes consoles (regedit, mmc), sans oublier la possibilité d’exécuter du Powershell à distance !

Bon, ça n’a pas fonctionné du premier coup, mais après avoir martelé la touche entrée et saisi mes identifiants, c’est bien passé :

On peut même en théorie se passer des partages administratifs. Cependant, il faudra utiliser un autre navigateur que Firefox car il m’était impossible de parcourir l’arborescence jusqu’au bout. Microsoft ne supporte officiellement que Edge et Chrome – ce qui encore une fois, me paraît être un choix douteux étant donné la réputation de Chrome par rapport au soin apporté concernant la confidentialité des données de navigation.

Le panneau des rôles et fonctionnalités est évidemment inclus dans le WAC

Les fonctionnalités sont plus ou moins les mêmes lorsqu’on administre une station de travail avec Windows 10 ; étant donné qu’il existe déjà des outils de gestion de parc bien installés sur le marché, le WAC devrait rester cantonné à la gestion des serveurs et des infrastructures, d’autant plus qu’il y a de nombreuses intégrations possibles avec Azure (notamment une fonctionnalité de sauvegarde de serveur, que j’aimerais tester dès que possible).

Au final, après quelques heures passées sur l’outil, j’ai plus le sentiment d’avoir à faire à une évolution plus qu’une révolution, même si c’est une petite révolution qui pourra être menée par rapport aux habitudes sur les plateformes Windows. Une évolution, car le WAC ne reste qu’un Server Manager en plus moderne, un peu moins complexe, moins rigide et intégrant différentes consoles MMC ; une révolution car cet outil permet de pousser un peu plus les versions headless (sans interfaces graphiques) de Windows, plus légères et plus facilement administrables à distance. Si les interfaces graphiques avaient un sens pour une facilité d’administration avant et de gestion des fichiers (lorsqu’elles n’étaient pas requises pour un applicatif particulier, évidemment), c’est désormais le cas inverse : elles n’ont plus grand intérêt lorsqu’on peut tout réaliser à distance. Si cela est depuis longtemps possible avec Powershell, les outils de management déployés ici et là sur les stations, les consoles MMC ou encore le Server Manager, le WAC a l’intérêt d’offrir une centralisation sur un seul outil accessible depuis n’importe quelle station du réseau. J’ai hâte de pouvoir utiliser un peu plus cet outil dans un cadre plus consistant que sur une maquette de test. 😀

Vous pouvez télécharger le setup du Windows Admin Center directement sur le site de Microsoft.