Powershell : vérification de l’installation d’un KB

Etant donné que je participe à la préparation d’une campagne de patchs suite aux failles Meltdown et Spectre, je me suis développé rapidement un script qui me permettra de vérifier si le(s) KB que nous allons installer l’auront bien été sur les systèmes en question.

Param
([string]$m,[string]$id)
$id = "KB"+$id
$KBlist = Get-Hotfix -ComputerName $m | Select HotfixID
foreach ($KB in $KBlist)
{
if ([string]$KB.HotfixID -ne $id){continue}
echo $id" effectif sur "$m
}

On exécutera simplement le script avec deux arguments :

.\win_kbcheck.ps1 -m <NomMachine> -id <NoDeKB>

Si le script ne retourne rien, c’est que le numéro de patch paramétré n’est pas installé sur la machine.

Powershell : listing des disques locaux d’une machine distante et export CSV

Pour un besoin ponctuel, j’ai eu à faire un recensement des disques locaux et de leur état sur de multiples machines distantes. J’ai donc réalisé un script Powershell permettant de les lister et d’obtenir d’autres informations et d’en faire un export CSV qui devient finalement exploitable sous Excel grâce à la conversion (onglet Données > Convertir).

Ce script utilise WMI, il est donc important que le service soit en fonctionnement sur les machines cibles et que le pare-feu autorise la communication. Si il s’agit du pare-feu Windows, cela est très facile dans les réglages de ce dernier :

Pour autoriser WMI, on coche les cases « Domaine » ou « Domestique/entreprise » en fonction de sa situation.

A noter que le script commenté est également téléchargeable sur mon miroir de téléchargement.

Le script nécessite de placer simplement en paramètre le nom de la machine en question. On l’appellera par l’instruction suivante :

PS> .\win_listdisks.ps1 server.local
Param
    ([string]$Comp)
    
$output = @()
$DiskList = Get-WmiObject Win32_LogicalDisk -ComputerName $Comp
foreach ($Disk in $DiskList){
    if ($Disk.DriveType -ne 3){continue}
    $DiskLetter = $Disk.DeviceID
    $DiskName = $Disk.VolumeName
    $DiskSize = $Disk.Size
    $DiskFS = $Disk.FreeSpace
    $DiskSize = [long]$DiskSize/1073741824
    $DiskFS = [long]$DiskFS/1073741824
    $DiskPerc = ($DiskFS/$DiskSize)*100
    
    echo "Disk $DiskLetter"
    echo "Name: $DiskName"
    echo "Size: $DiskSize"
    echo "Free: $DiskFS"
    echo "Percentage Free: $DiskPerc"
    
	$DiskObj = New-Object PSCustomObject
	$DiskObj | Add-Member -Type NoteProperty -Name 'DiskLetter' -Value $DiskLetter
	$DiskObj | Add-Member -Type NoteProperty -Name 'DiskName' -Value $DiskName
	$DiskObj | Add-Member -Type NoteProperty -Name 'DiskSize' -Value $DiskSize
	$DiskObj | Add-Member -Type NoteProperty -Name 'DiskFS' -Value $DiskFS
	$DiskObj | Add-Member -Type NoteProperty -Name 'DiskPerc' -Value $DiskPerc
	$output+=$DiskObj
}
$output | Export-CSV disks-$comp.csv

Ensuite, dans Excel, en convertissant le CSV en tableau en choisissant la virgule comme élément délimitant les données, on obtient quelque chose de lisible :

Harmonisation de la synchronisation du temps sur Debian et Windows

Aujourd’hui j’ai pris un peu le temps de mettre à plat ma configuration concernant les horloges et la synchronisation de celles-ci sur les différents serveurs que je fais fonctionner sur mon environnement personnel. Les horloges étant disparates sur les systèmes, j’ai donc défini la configuration suivante :

  • L’hyperviseur ESXi se synchronisant sur des serveurs NTP publics : http://www.pool.ntp.org/ ;
  • Mes deux contrôleurs de domaine Windows se synchronisant sur ces mêmes serveurs NTP ;
  • Toutes mes autres machines se synchronisant sur mes contrôleurs de domaine.

Sur Windows, j’ai développé un script Powershell – qu’il m’aurait été possible d’appliquer via GPO – qui s’occupe de modifier la configuration dans la base de registre afin que le serveur utilise comme source les contrôleurs de domaine. Ce script (disponible sur mon miroir de téléchargement) nécessite évidemment des droits d’administration sur le serveur pour être exécuté – on s’assurera de remplacer time-srvX par le nom du serveur de temps, en conservant bien ,0x1 et en séparant les noms de serveurs par un espace :

Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\w32time\Config -name « AnnounceFlags » -value « 5 »
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\w32time\Parameters -name « Type » -value « NTP »
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\w32time\TimeProviders\NtpServer -name « Enabled » -value « 1 »
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\w32time\Parameters -name « NtpServer » -value « time-srv1,0x1 time-srv2,0x1 »

A noter qu’en fonction de la politique d’exécution des scripts sur la machine, il est possible que le script ne s’exécute pas, on va donc l’autoriser si cette politique n’est pas gérée au niveau du domaine.

Set-ExecutionPolicy Unrestricted

Une fois ces instructions interprétées par Powershell, on redémarre le service de temps :

net stop w32time
net start w32time

Puis, on peut s’assurer que la source est correcte et faire une synchronisation grâce aux commandes suivantes – l’interrogation de la source devrait renvoyer l’un des serveurs spécifiés plus haut :

w32tm /query /source
w32tm /resync

Ensuite, sur mes machines Debian, grâce au paquet ntpdate, il est possible de spécifier au système l’adresse d’un serveur sur lequel synchroniser l’horloge.

apt-get install ntpdate

On modifie le fichier de configuration :

nano /etc/default/ntpdate

Afin de forcer ntpdate a bien utiliser ce fichier de configuration, on passe le paramètre NTPDATE_USE_NTP_CONF à no, puis on modifie NTPSERVERS pour y intégrer les serveurs de temps, ce qui donne ceci :

NTPDATE_USE_NTP_CONF=no
NTPSERVERS= »time-srv1 time-srv2″

Et enfin, pour synchroniser la machine avec les serveurs tout juste renseignés :

ntpdate-debian

Charge CPU bloquée à 100% sur le serveur hébergeant les Office WebApps pour SharePoint 2013

Toujours dans la lignée de mon travail sur les serveurs WAC (Office WebApps pour SharePoint, voir ce précédent billet), j’ai été confronté à un problème de consommation CPU sur un des deux serveurs WAC ; le CPU était en charge maximale en permanence, même sans aucun appel des Office WebApps de la part des utilisateurs, un arrêt/relance des services et un redémarrage de la plateforme n’ayant rien changé.

svchost.exe consomme 100% du CPU

Le journal d’événements ne présentant aucune erreur particulière, je n’avais pas de piste à creuser, et le système semblait en bonne santé. Je décide alors de couper le service Windows Update qui n’a aucun impact sur le service rendu en production, et miracle :

La charge CPU retombe à des niveaux très faibles, ce qui est normal lorsque le WAC n’est pas sollicité. Dans mon environnement, laisser le service Windows Update désactivé n’est pas problématique car nous gérons à la main le patching des serveurs via des campagnes – il suffira de réactiver le service au moment de mettre à jour la machine et de le désactiver après si la consommation de CPU reste bloquée à 100%.