Étiquette : Windows

Pas de commentaire

Réguler la consommation de RAM sur un serveur WSUS

  de

Il arrive que WSUS et IIS qui fonctionnent de pair puissent déclencher fréquemment des alertes de sur-consommation de mémoire vive. Bien que cela n’impacte pas forcément les performances dudit serveur, il peut être nécessaire de forcer une « purge » du processus IIS exécutant le pool applicatif de WSUS afin que la consommation en RAM redescende.

Par exemple, ce matin :

Dans IIS, on peut « forcer » le pool applicatif de WSUS simplement nommé WsusPool à faire un recyclage des ressources systèmes qu’il occupe. Il suffit de sélectionner ce pool et de cliquer sur les options de recyclage (et non l’action de recyclage elle-même avec son icône de flèches vertes). Une fenêtre s’ouvre alors, proposant diverses options :

La fenêtre des options de recyclage permet de choisir une échéance de temps, de nombre de requêtes ou de consommation de mémoire vive, ou plusieurs à la fois.

On choisit donc les options qui nous conviennent : dans mon cas, en plus de l’intervalle de temps entre deux recyclages, j’ai défini un maximum de mémoire vive (à adapter en fonction de la charge souhaitée sur le serveur, il est évident que si l’on décide de n’y allouer que 500 Mo, les performances vont en pâtir), mais c’est optionnel. Une fois ce choix validé, nous pouvons lancer à la main un recyclage :

IIS va donc recycler le pool : cela signifie qu’il va créer un autre processus exécutant ce pool, puis transférer la charge mémoire du premier vers le nouveau, en faisant le « ménage » parmi ce dont il n’a plus besoin.

Le recyclage est en cours, le premier processus se vide en faveur du deuxième avant de disparaître.

Ainsi, la consommation en RAM a bien chuté et ne pourra dépasser 4 Go. Bien évidemment, cette limite n’est pas obligatoire ; en cas de surcharge ponctuelle du serveur, on peut toujours déclencher un recyclage manuel qui aura le même effet.

Pas de commentaire

Powershell : fermeture de session inactives à distance

  de

Suite à un besoin récurrent, j’ai développé un script Powershell permettant de mettre fin à tous les sessions déclarées comme inactives sur un serveur Windows distant. Il est constitué d’une fonction qui est chargée de terminer les sessions et de quelques instructions appelant cette fonction ; une fois un serveur traité, le script demande si l’utilisateur souhaite traiter un autre serveur.

A noter qu’il faut naturellement des droits d’administration sur les serveurs sur lesquels une session doit être terminée.

$kick = "Y"
function Kick {
param ($srv)
$quout = quser /server:$srv
$status = "Disc"
$indexs = 2
$indexu = 1
$sid = (($quout | Where-Object { $_ -match $status }) -split ' +')[2]
while ($sid -ne $null)
{
$username = (($quout | Where-Object { $_ -match $status }) -split ' +')[$indexu]
$sid = (($quout | Where-Object { $_ -match $status }) -split ' +')[$indexs]
if ($sid -eq $null) { break }
Write-Host "User :"$username
Invoke-RDUserLogoff -HostServer $srv -Unifiedsid $sid -Force
$indexu = $indexu+8
$indexs = $indexs+8
Write-Host "Session has been terminated."
Start-Sleep -Seconds 3
}
}
Write-Host "Force close disconnected session script for Windows 2008 and 2012"
while ($kick -eq "Y")
{
$srv = Read-Host "Server Name"
kick($srv)
$kick = Read-Host "Do you want to process another server ? Y/N"
}
Télécharger
Pas de commentaire

Une bien fine technique de sioux pour récupérer en local un bloc-notes OneNote stocké sur OneDrive

  de

J’utilise OneNote pour prendre des notes, stocker des scripts et de la documentation personnelle. Pour des raisons pratiques, je garde mon bloc-notes en local et fais régulièrement un upload du répertoire du bloc-notes sur OneDrive.

Cependant, j’ai commis l’erreur d’ouvrir depuis l’application intégrée à Windows 10 (qui est aussi pauvre et mal pensée que celle sur OS X), ce qui fait qu’au lieu d’avoir dans mon répertoire avec les fichiers de manière éclatée comme en local, j’obtiens un simple lien :

Un simple lien insupportable car OneNote 2010 est incapable de le lire alors que c’est sa version d’origine, et une ouverture avec un Office complet en 2016 est également impossible. En gros, mon notebook était tout simplement condamné à être utilisé en web ou via les versions gratuites de OneNote. Je décide donc de tenter de ruser :

  • Tout d’abord, télécharger le répertoire qui contient le lien via un navigateur web : aucun effet, un zip de 657 octets avec un fichier dedans m’indiquant que OneDrive n’a pas pu récupérer le fichier notebook. 
  • Deuxième essai : via le client OneDrive ; pas mieux, je récupère un fichier .url tout aussi inutile.
  • Troisième essai : j’ouvre le fichier sur OneNote pour macOS et je fouine dans le cache dans la librairie utilisateur et les répertoires Microsoft ; je n’ai qu’une liste de dizaines de fichiers de cache complètement inexploitables qui ne ressemblent pas aux fichiers habituels .one qui constituent un notebook.
La quatrième tentative fut la bonne, et elle m’a demandé de creuser un peu ; il faut donc vraiment avoir besoin de son notebook (en réalité, copier-coller le contenu des nouvelles sections et pages vers une version de backup locale aurait pris moins de temps mais hors de question de m’avouer vaincu par cette politique de OneDrive ou rien). J’ai donc utilisé une vieille VM Windows 7 équipée d’un pack Office 2016 et pour récupérer la vue éclatée de mes fichiers (car en réalité sur OneDrive Web, l’affichage montre un simple fichier tandis que l’explorateur montre la version complète), j’ai utilisé le navigateur par défaut de Windows 7 qui est IE8, puis j’ai été sur OneDrive, et j’ai pu récupérer le lien WebDav de mon répertoire grâce à une option accessible uniquement sur les navigateurs qui ne sont plus officiellement pris en charge, grâce au formulaire d’upload de fichiers :
En cliquant, cela m’ouvre un explorateur Windows, depuis lequel un simple aperçu des propriétés me permet de récupérer le chemin WebDav que je vais pouvoir ensuite exploiter sur n’importe quelle autre machine :
Du coup, sur mon OneNote 2016 et ma VM Windows 7, pas de problèmes pour l’ouvrir et le modifier après avoir réalisé une copie locale du contenu du répertoire, par contre, il semblerait qu’il n’y ait pas de rétrocompatibilité avec Office 2010 (testé sur une autre machine en Windows 10)… ce qui ne me pose finalement pas de problème. J’ai donc mon notebook en local et il ne me reste plus qu’à rester fidèle au client lourd OneNote… et à ne plus synchroniser sur OneDrive mais simplement sauvegarder une archive zip du notebook.
Pas de commentaire

Impossible d’exécuter un script VBS sur 2012

  de

J’ai rencontré sur quelques serveurs des messages d’erreurs suite à des tentatives de traitement de scripts VBS, comme quoi le système était incapable de trouver le moteur VBScript : Can’t find script engine « VBScript » for script … étant donné que VBS est utilisé pour des générer des indicateurs, sans le moteur de script il n’y avait donc aucune remontée d’informations.

Le moteur VBS est une vulgaire librairie située dans le répertoire C:\Windows\System32 :

Ensuite, une clef de registre bien planquée permet de faire le lien entre cette DLL et le système ; c’est celle-ci qui sera appelée par Windows lorsqu’un script VBS sera exécuté. Cette clef de registre est la suivante : HKCR\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32 et c’est sa valeur par défaut qui contient le chemin vers la DLL.

Certains programmes – principalement des antivirus – remplacent la valeur par un chemin vers une autre DLL, qui leur permet d’exécuter des scripts VBS mais qui communiquent avec l’antivirus afin de détecter du code malveillant ; ce qui était exactement mon cas :

Seulement, en allant dans le repértoire de cette DLL, elle n’y était pas, d’où le message d’erreur donné plus haut. Il y avait donc trois solutions ou workarounds possibles :

  1. Réinstaller l’antivirus pour forcer ce dernier à réécrire tous ses fichiers proprement et à recopier la DLL ; ou à défaut copier la DLL d’un serveur qui la possède.
  2. Modifier la clef de registre pour reprendre sa valeur originale.
  3. Copier la DLL d’origine et la renommer pour correspondre au nom donné dans la base de registre.

D’emblée, la solution 2 n’est pas envisageable car cela serait trop facile pour un virus ou code malveillant de modifier la clef de registre afin de bypasser les contrôles de l’AV sur les scripts VBS. Même en tant qu’administrateur local de la machine et en ayant shunté l’AV, il m’a été impossible de modifier la valeur dans la clef, ni même de modifier les autorisations sur celles-ci, que ce soit directement ou via un fichier .reg ; la solution 3 fonctionne mais n’est pas la plus sécurisante car de ce fait, les scripts VBS ne sont pas contrôlés par l’antivirus.

J’ai donc choisi la première solution : la réinstallation. Une simple copie de la DLL d’un autre serveur aurait pu suffire mais après avoir comparé les répertoires des AV entre le serveur posant problème et un autre sain, j’ai constaté de belles différences, preuve que l’AV n’avait pas correctement été déployé et que l’installation a été d’une manière ou d’une autre avortée.

Une fois la réinstallation de l’AV effectuée, la DLL était en effet visible dans le répertoire et il m’a été possible d’appeler des scripts VBS sans message d’erreur.