Pas de commentaire

Powershell : récupération des informations sur le(s) pagefile.sys

  de

Dans l’idée du billet d’hier concernant la résolution de problématiques d’espace disque, j’ai codé rapidement un petit script Powershell pour récupérer les informations système propres au(x) fichiers de pagination.

En passant en argument du script un nom de machine, on récupère le chemin du fichier, sa taille de base, l’utilisation actuelle et maximale de celui-ci.

Param
([string]$Comp)

$pfsys = Get-WmiObject Win32_PagefileUsage -Computer $Comp | select Name, CurrentUsage, PeakUsage, AllocatedBaseSize
foreach ($pf in $pfsys)
{
echo "Location: "$pf.Name
echo "File base size in MB: "$pf.AllocatedBaseSize
echo "Current usage: "$pf.CurrentUsage
echo "Max. usage: "$pf.PeakUsage
}
Télécharger
Pas de commentaire

Quelques techniques de sioux pour gratter un peu d’espace disque

  de

Aujourd’hui, j’ai dû mettre à jour des machines Windows qui n’avaient pas été mises à jour depuis un bon bout de temps… comprendre que j’ai dû déployer des Service Pack 1 pour Windows 2008 R2 pour ensuite pouvoir patcher ces serveurs à jour, notamment contre Meltdown et Spectre.

Seulement, ces machines ont généralement été peu suivies et on se retrouve avec des serveurs physiques avec un RAID 1 de 150 ou 300 Go… et une partoche système de 15 Go, ce qui n’est déjà pas très large sur un OS tout juste installé mais qui s’avère vite bloquant lorsque les KB s’accumulent. 🙄

Mmmm… Imagine que t’es fauché, la paire de chaussures que tu vises est en promo mais en pointure 41 et tu fais du 44. Même avec un chausse-pieds, ça s’annonce difficile.

Le SP1 de 2008 R2 installé en standalone nécessite 7 Go de libre sur le disque système pour s’installer. Partant d’1,8 Go libre, j’ai donc dû ruser et fouiner vraiment partout pour libérer le maximum d’espace possible… le redimensionnement des partitions n’étant dans mon cas une option pas envisageable.

La base des bases : vider les répertoires temporaires.

Pour chaque utilisateur. Dans le répertoire AppData\Local\Temp : on vide. C:\Windows\Temp, pareil, tout part à la corbeille, sans oublier de la vider bien évidemment.

Le contrôle des profils utilisateurs.

En fonction de qui se connecte sur le serveur, il peut y avoir des fichiers stockés dans les profils : fichier d’installation, backups perso… on peut pas forcément supprimer sur le champ mais on a déjà une bonne piste pour savoir si on peut récupérer quelques Mo. Si un profil est indiqué comme « inconnu » ou n’est qu’un GUID ActiveDirectory (reconnaissable, de type {S-1-5-12-39837-XH273-E8732} par exemple), il est plutôt safe de détruire l’entrée.

Propriétés système > Avancé > Profils utilisateurs

Si jamais un profil prend une place énorme, il se peut qu’il reste certains reliquats de profil de connexion. En rendant visible les fichiers cachés, on peut retrouver une foultitude de fichiers .DAT dans le répertoire de l’utilisateur, pesant 2 ou 512 Ko, par paire, et généralement une fois par connexion. Encore une fois, il est plutôt safe de supprimer tous ceux plus vieux d’un mois ; je n’ai pas trouvé la cause de l’accumulation de tels fichiers mais j’ai déjà pu libérer plusieurs Go.

Le Windows Update.

Un contrôle rapide de C:\Windows\SoftwareDistribution pour voir sa taille, si elle est excessive, une petite suppression du contenu du répertoire Download ne peut pas faire de mal. Ce répertoire contient les fichiers de mises à jour téléchargés depuis le WSUS ou Windows Update ; cela signifie que le serveur ira retélécharger les mises à jour lorsqu’il en aura besoin. Il est également possible de supprimer le fichier datastore.edb présent dans le répertoire DataStore.

Le pagefile.sys.

Une opération pas toujours possible et qui nécessite un reboot mais qui peut libérer pas mal d’espace disque en le déplaçant sur une autre partition (dans cet exemple, 6 Go !). Tout d’abord, paramétrer le même fichier sur le deuxième disque, puis passer le premier à No paging file. Quitte à ensuite le redéplacer à l’emplacement initial si c’est possible pour garder la configuration d’origine.

Propriétés système > Avancé > Performances > Avancé > Mémoire virtuelle

La centralisation des sources.

Placer dans un seul et même répertoire les sources qui peuvent être déployées à droite à gauche et les placer ne serait-ce que temporairement sur un autre disque, voire même les supprimer si elles sont disponibles sur un repository facile d’accès.

Le journal d’événements.

Peu de chances de récupérer beaucoup d’espace mais cela dépend de la configuration. Il n’est pas nécessaire de vider le log complet, simplement de limiter sa taille maximale. Il peut d’ailleurs être intéressant de voir si il n’est pas possible de compresser ou de déplacer les archives des logs sur un autre disque si l’option est activée. A titre d’exemple, j’ai déjà compressé des fichiers d’événements de 600 voire 700 Mo à 90%, résultant en des fichiers bien plus petits qu’à l’origine.

Dans l’observateur d’événements eventvwr, et en allant sur chaque type de journal : Application, System, Security…

Et au final, après avoir appliqué tout ça, j’ai pu installer mon SP1 et déployer mes patchs 💪

Et en bonus, une autre astuce pour les Windows Server 2003, car oui, bien qu’ils ne soient plus supportés, ils existent encore… Pour libérer de l’espace disque, il est possible de supprimer les répertoires $hf_mig$, $NtUninstallKB et $NtServicePackUninstall du répertoire système. Pour ma part, plutôt que de les supprimer, je préfère les déplacer ailleurs… sait-on jamais ce qui peut être demandé sur un tel ancêtre !

Pas de commentaire

Powershell : désactivation de TLS 1.0 et 1.1, activation de TLS 1.2

  de

En lien direct avec le billet d’hier, j’ai donc concocté un script permettant d’automatiser les modifications requises en base de registre pour l’activation de TLS 1.2 au profit de TLS 1.0 et 1.1.

Naturellement, le script est à exécuter avec un compte d’utilisateur ayant les droits d’écrire en base de registre.

echo "This script will create or write over some registry keys related to TLS 1.0, TLS 1.1 and TLS 1.2 - make sure to be aware of the effect of those modifications."
$continue = Read-Host "Are you sure you want to execute this script ? Type 'Y' to continue or any other character to abort"
if ($continue -ne 'Y') {break}
$pathtls10 = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0"
$pathtls11 = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1"
$pathtls12 = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2"
$pathprtcl = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\"
echo "Creating TLS keys..."
New-Item -Path $pathprtcl -Name "TLS 1.0" -Force | Out-Null
New-Item -Path $pathprtcl -Name "TLS 1.1" -Force | Out-Null
New-Item -Path $pathprtcl -Name "TLS 1.2" -Force | Out-Null
New-Item -Path $pathtls10 -Name "Server" -Force | Out-Null
New-Item -Path $pathtls10 -Name "Client" -Force | Out-Null
New-Item -Path $pathtls11 -Name "Server" -Force | Out-Null
New-Item -Path $pathtls11 -Name "Client" -Force | Out-Null
New-Item -Path $pathtls12 -Name "Server" -Force | Out-Null
New-Item -Path $pathtls12 -Name "Client" -Force | Out-Null
echo "Adding DWORD properties..."
New-ItemProperty -Path $pathtls10Client -PropertyType DWORD -Name "DisabledByDefault" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls10Server -PropertyType DWORD -Name "DisabledByDefault" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls11Client -PropertyType DWORD -Name "DisabledByDefault" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls11Server -PropertyType DWORD -Name "DisabledByDefault" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls12Client -PropertyType DWORD -Name "DisabledByDefault" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls12Server -PropertyType DWORD -Name "DisabledByDefault" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls10Client -PropertyType DWORD -Name "Enabled" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls10Server -PropertyType DWORD -Name "Enabled" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls11Client -PropertyType DWORD -Name "Enabled" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls11Server -PropertyType DWORD -Name "Enabled" -Value "0x00000000" -Force | Out-Null
New-ItemProperty -Path $pathtls12Client -PropertyType DWORD -Name "Enabled" -Value "0x00000001" -Force | Out-Null
New-ItemProperty -Path $pathtls12Server -PropertyType DWORD -Name "Enabled" -Value "0x00000001" -Force | Out-Null
echo "Done."
$reboot = Read-Host "Server has to reboot in order to apply the modifications made. Type 'Y' if you want to start a reboot countdown of 2 minutes."
if ($reboot -ne 'Y') {break}
shutdown -r -t 120
echo "Server will reboot in 2 minutes."

Si jamais l’accès Terminal Server est impossible au redémarrage, il faut contrôler les réglages de sécurité du serveur RDP et être sûr que le KB3080079 est installé si l’OS est Windows Server 2008 R2. Tout est expliqué dans l’article que j’ai publié hier sur les manipulations d’origine.

Télécharger
Pas de commentaire

Désactivation de TLS 1.0, TLS 1.1 et activation de TLS 1.2 sur Windows Server 2008 R2 et +

  de

Il a été décidé par les responsables d’une plateforme sur laquelle je suis intervenu ce jour de la désactivation de TLS 1.0 et 1.1 au profit de 1.2 sur un serveur Windows 2008 R2 utilisant IIS 7. Je vais donc décrire dans cet article les modifications qui sont à réaliser en base de registre – je pense réaliser par la suite un script permettant l’automatisation de la création et peuplement de ces clefs.

En préalable, il est important de vérifier que le KB 3080079 soit installé sur le serveur si 2008 R2, sans quoi une fois la désactivation de TLS 1.0 effective il ne sera plus possible d’accéder en Remote Desktop sur le serveur. Je renvoie à cette page pour plus d’informations.

J’ai réalisé une archive ZIP des clefs de registre évoquées dans ce billet sur mon miroir de téléchargement.

Dans la base de registre, on ira jusqu’à la clef suivante :
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Une fois dans cette clef, il suffira de créer une clef supplémentaire par protocole. On créé donc 3 clefs : TLS 1.0, TLS 1.1 et TLS 1.2. A noter qu’il est fort probable que soient déjà présentes d’autres clefs pour SSL, comme sur cette capture d’écran.

Dans chacune des clefs TLS, il faudra créer 2 sous-clefs : Client et Server. L’arborescence ressemble donc à cela :

Dans chacune des 6 clefs qui ont été crées, il faudra ajouter 2 valeurs DWORD en hexadécimal :

  • DisabledByDefault, qui aura toujours la valeur 0
  • Enabled, qui aura la valeur 0 pour TLS 1.0 et TLS 1.1 et la valeur 1 pour TLS 1.2.

Ce qui donne, pour TLS 1.0\Client, TLS 1.0\Server, TLS 1.1\Client et TLS 1.1\Server :

Pour TLS 1.2\Client et TLS 1.2\Server :

Ensuite, un redémarrage du serveur suffit pour que les modifications soient prises en compte. Les protocoles TLS 1.0 et 1.1 ne sont plus actifs. A noter que ces clefs de registre peuvent également être appliquées sur Windows Server 2012 et R2.

Si jamais le Remote Desktop ne fonctionne plus une fois TLS 1.0 désactivé et que le patch est bien installé sur le serveur (si antérieur à 2012), il faut forcer le Terminal Server à utiliser son encryption et non celle de TLS 1.0. Pour ce faire, on ouvrira tsconfig.msc, puis les propriétés du serveur. Cette fenêtre s’ouvre :

 

Il est important que le Security Layer soit basculé sur RDP Security Layer et non TLS 1.0, faute de quoi la connexion sera impossible.