PowerShell : comment vérifier l’existence d’un chemin d’accès

Dans le domaine de l’administration des systèmes et de la gestion informatique, l’automatisation des contrôles de routine est essentielle. L’un de ces contrôles de routine consiste à vérifier l’existence d’un chemin d’accès ou d’un dossier spécifique, une action souvent effectuée pour s’assurer qu’un logiciel particulier ou des fichiers critiques sont en place. PowerShell s’est imposé comme un puissant langage de script qui facilite ces tâches et permet aux professionnels de l’informatique de rationaliser les opérations avec précision.

Contexte

Le script en question vise à simplifier le processus de vérification des chemins en vérifiant non seulement si un chemin spécifié existe, mais aussi en mettant à jour un champ personnalisé en fonction de ce résultat. Cette double fonctionnalité est inestimable pour les professionnels de l’informatique et les fournisseurs de services gérés (MSP) qui s’appuient sur des données en temps réel pour surveiller les installations, les mises à jour ou l’état des logiciels sur plusieurs systèmes. En intégrant un mécanisme de feedback personnalisé, le script permet aux utilisateurs de l’adapter à leurs outils de surveillance et tableaux de bord spécifiques.

Le script

<#
.SYNOPSIS
    Updates a custom field with Yes or No, depending if the path exists or not.
.DESCRIPTION
    Updates a custom field with Yes or No, depending if the path exists or not.
.EXAMPLE
     -Path "$env:APPDATAZoombin" -CustomField "Zoom"
    Check if Zoom is installed for the current user. Set custom field "Zoom" to "Yes" if the folder exists or "No" if it doesn't.
.EXAMPLE
    PS C:> Set-IfPathExists.ps1 -Path "$env:APPDATAZoombin" -CustomField "Zoom"
    Check if Zoom is installed for the current user. Set custom field "Zoom" to "Yes" if the folder exists or "No" if it doesn't.
.OUTPUTS
    None
.NOTES
    Minimum OS Architecture Supported: Windows 7, Windows Server 2008
    Release Notes:
    Initial Release
 By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
#>
[CmdletBinding()]
param (
    # Path to file or folder
    [Parameter(Mandatory = $true)][String]$Path,
    # THe custom field that we will be updating
    [Parameter(Mandatory = $true)][String]$CustomField,
    # Text that will be saved to the custom field when file/folder exists
    [Parameter(Mandatory = $false)][String]$Exists = "Yes",
    # Text that will be saved to the custom field when file/folder does not exist
    [Parameter(Mandatory = $false)][String]$NotExist = "No"
)

begin {}
process {
    $CustomFieldValue = $(
        if ($(Test-Path -Path $Path -ErrorAction SilentlyContinue)) {
            $Exists
        }
        else {
            $NotExist
        }
    )
    Ninja-Property-Set -Name $CustomField -Value $CustomFieldValue
}
end {}

 

Description détaillée

Décomposons les éléments du script :

Paramètres :

• $Path : Spécifie l’emplacement du fichier ou du dossier.
• $CustomField : Renvoie au champ personnalisé à mettre à jour en fonction du résultat.
• $Exists : Champ de texte indiquant la présence d’un chemin d’accès.
• $NotExist : Champ de texte indiquant l’absence de chemin d’accès.

Bloc « process » :

• La cmdlet Test-Path vérifie si le $Path spécifié existe.
• En fonction du résultat, la variable $CustomFieldValue se voit attribuer la valeur $Exists ou $NotExist.
• Ninja-Property-Set met à jour le champ $CustomField avec la valeur $CustomFieldValue.

Cas d’utilisation potentiels

Prenons l’exemple d’un responsable informatique qui supervise le déploiement de logiciels au sein d’une entreprise. Il veut s’assurer que Zoom est installé sur le poste de travail de chaque employé. Au lieu de naviguer manuellement sur chaque poste de travail, il déploie ce script à l’échelle du réseau. Il vérifie l’existence du chemin d’installation de Zoom et met à jour un tableau de bord centralisé, permettant au gestionnaire de voir, en un coup d’œil, quelles machines ont Zoom d’installé.

Comparaisons

Bien qu’il existe des méthodes manuelles pour vérifier l’existence d’un chemin, telles que la navigation dans les dossiers ou l’utilisation de l’option Propriétés de l’interface graphique, la fonction Test-Path de PowerShell est efficace et évolutive. En outre, l’intégration du test de cheminement avec un mécanisme de feedback personnalisé, comme le montre ce script, offre un degré supplémentaire de personnalisation que l’on ne trouve généralement pas dans les solutions prêtes à l’emploi.

FAQ scripts et chemin d’accès

• Que se passe-t-il si le chemin d’accès spécifié ($Path) est incorrect ?
  Le script renvoie la valeur $NotExist s’il ne trouve pas le chemin.
• Comment Ninja-Property-Set est-il utilisé ici ?
  Il s’agit d’un espace réservé pour une fonction hypothétique qui met les propriétés à jour. Dans une application réelle, vous le remplaceriez par une fonction réelle compatible avec votre outil de surveillance.

Implications

Bien que le script facilite l’automatisation, il a une incidence sur la sécurité informatique. Si des entités malveillantes accèdent au tableau de bord, elles peuvent détecter les vulnérabilités des logiciels en fonction des installations. Il est essentiel de veiller à ce que les résultats de ce script soient conservés dans un environnement sécurisé.

Recommandations

• Testez toujours le script dans un environnement contrôlé avant de le déployer.
• Mettez régulièrement à jour la liste des chemins d’accès à vérifier, en veillant à ce qu’elle reste pertinente.
• Veillez à ce que les données générées par le script soient stockées et transmises en toute sécurité.

Conclusion

NinjaOne, en tant que solution de gestion informatique intégrée, peut exploiter encore davantage les capacités du script. En intégrant des scripts de ce type, NinjaOne peut offrir des informations plus précises en temps réel, ce qui permet aux professionnels de l’informatique de gérer et de surveiller les systèmes de manière efficace. Associer la polyvalence de PowerShell à la plateforme complète de NinjaOne garantit des opérations informatiques performantes et rationalisées.