2 votes

Comment vérifier qu'un champ de journal personnalisé IIS existe avec PowerShell ?

Je déploie une paire de scripts via SCCM pour définir une grande variété d'éléments de configuration IIS - des choses comme les emplacements de journal par défaut, les valeurs de troncature, et ainsi de suite. L'une des choses que j'ajoute est un champ de fichier journal personnalisé :

Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -filter "system.applicationHost/sites/$Sitename/logFile/customFields" -name "." -value @{logFieldName='Original-IP';sourceName='X-Forwarded-For';sourceType='RequestHeader'}

Cela fonctionne bien ; je peux y accéder manuellement avec l'éditeur de configuration dans IIS, et il s'affiche dans l'interface graphique des paramètres de journalisation. Cependant, je rencontre un problème. Une partie du déploiement de SCCM consiste à exécuter un script qui vérifie que les valeurs sont correctes sur chaque serveur. avant il exécute la correction script. Ceci sera exécuté périodiquement contre notre environnement (3000+ serveurs Windows), et les résultats de cette script de vérification déterminent si SCCM exécute la script de remédiation qui définit les valeurs.

Je veux éviter d'exécuter le script quand ce n'est pas nécessaire (et mon patron aime les choses qui disent 100%), mais je n'arrive pas à comprendre l'erreur que je reçois. Je sais que j'interroge la valeur de manière erronée, donc je ne peux pas lui dire ce qu'il faut faire correspondre. Quelqu'un peut-il m'aider à résoudre ce problème ?

$SiteLogFileCustom = Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -filter "system.applicationHost/sites/$Sitename/logFile/customFields" -name Original-IP

if (($SiteLogFileCustom) -eq ('Original-IP'))
    {
        write-host "Match!"
    }
else
    {
        write-Error "Mismatched values!" -Category NotInstalled -ErrorId MisMatch

Les retours :

\\tsclient\D\share\scripts\IIS-Settings\Check-iisSettings.ps1 : Mismatched values!
+ CategoryInfo          : NotInstalled: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : MisMatch,Check-iisSettings.ps1

Ce qui est attendu, puisque la valeur retourne vide. Comment puis-je interroger la collection customFields pour obtenir une liste des noms des champs personnalisés, puis les comparer à une liste prédéterminée ?

PS - Il ne devrait y avoir qu'un seul champ, Original-IP.

1voto

Amareswar Points 1397

De sharkbite0141 via /r/PowerShell envoyé il y a 19 heures :

Il s'agit d'une combinaison de problèmes avec vos paramètres Get-WebConfigurationProperty Filter et Name, ainsi qu'un problème avec votre instruction if :

$SiteLogFileCustom = Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -filter "system.applicationHost/sites/site[@name='$Sitename']/logFile/customFields" -Name 'Collection'

if ($SiteLogFileCustom.logFieldName -match 'Original-IP')
{write-output "Match!"}
   else
{write-Error "Mismatched values!" -Category NotInstalled -ErrorId MisMatch}

Pour expliquer :

Tout d'abord, dans la propriété Filter, il y avait quelques bizarreries avec l'interrogation du nom du site. Le paramètre site[@name='$Sitename'] fait un meilleur travail de correspondance avec le nom du site. Deuxièmement, le paramètre -Name devait être "Collection" car le nom de la propriété de configuration que vous recherchez dans la configuration customFields est un ensemble de collections de propriétés personnalisées. Selon la documentation, un simple point "." aurait dû fonctionner comme un joker sur une configuration possédant une propriété Collection, mais pour une raison quelconque, cela n'a fonctionné pour moi que lorsque j'ai spécifiquement nommé la propriété "Collection".

Ensuite, dans votre instruction if, vous devez également spécifier la propriété pour laquelle vous faites correspondre une valeur. Dans ce cas, la valeur Original-IP est stockée dans la propriété logFieldName. Nous l'avons donc ajouté à la fin de $SiteLogFileCustom et voilà !

Et une petite remarque : à moins que vous n'ayez besoin d'un formatage en couleur, il est préférable d'utiliser Write-Output plutôt que Write-Host. En effet, Write-Output écrit dans le pipeline, ce qui signifie que vous pouvez le transmettre à une autre cmdlet ou le stocker dans une variable, alors que Write-Host sort dans la console visuelle.

Edit : formatage et une note supplémentaire

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X