How to Check if a Path Exists Using PowerShell

In the realm of system administration and IT management, automating routine checks is pivotal. One such routine check is verifying the existence of a specific path or folder, an action often performed to ensure that particular software or critical files are in place. PowerShell has emerged as a powerful scripting language that makes these tasks easier, enabling IT professionals to streamline operations with precision.

Background

The script in focus aims to simplify the process of path verification by not only checking if a specified path exists but also updating a custom field based on this outcome. This dual functionality is invaluable for IT professionals and Managed Service Providers (MSPs) who rely on real-time data to monitor installations, updates, or software health across multiple systems. By integrating a custom feedback mechanism, the script allows users to tailor it according to their specific monitoring tools and dashboards.

The 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 {}

 

Detailed Breakdown

Let’s break down the script’s components:

Parameters:

• $Path: Specifies the file or folder’s location.
• $CustomField: Refers to the custom field to be updated based on the result.
• $Exists: A text field indicating the presence of a path.
• $NotExist: A text field indicating the absence of a path.

Process Block:

• The Test-Path cmdlet checks if the specified $Path exists.
• Based on the result, the $CustomFieldValue variable is assigned either the $Exists or $NotExist value.
• Ninja-Property-Set updates the $CustomField with the $CustomFieldValue.

Potential Use Cases

Consider an IT manager overseeing software deployments in an organization. They want to confirm that Zoom is installed on every employee’s workstation. Instead of manually navigating each workstation, they deploy this script network-wide. It checks the existence of the Zoom installation path and updates a centralized dashboard, letting the manager see, at a glance, which machines have Zoom installed.

Comparisons

While there are manual methods of checking path existence, such as navigating folders or employing the GUI-based properties option, PowerShell’s Test-Path is efficient and scalable. Moreover, integrating the path test with a custom feedback mechanism, as seen in this script, offers an added layer of customization not typically found in out-of-the-box solutions.

FAQs

• What if the specified $Path is incorrect?
  The script will return the $NotExist value if it doesn’t find the path.
• How is Ninja-Property-Set used here?
  This is a placeholder for a hypothetical function that updates properties. In a real-world application, you’d replace it with an actual function compatible with your monitoring tool.

Implications

While the script aids automation, there’s an implication concerning IT security. If malicious entities access the dashboard, they can discern software vulnerabilities based on installations. Ensuring this script’s results are kept in a secure environment is crucial.

Recommendations

• Always test the script in a controlled environment before deployment.
• Regularly update the list of paths to be checked, ensuring that it remains relevant.
• Ensure data generated by the script is stored and transmitted securely.

Final Thoughts

NinjaOne, as an integrated IT management solution, can further harness the script’s capabilities. By integrating scripts like these, NinjaOne can offer more granular, real-time insights, allowing IT professionals to manage and monitor systems efficiently. The combination of PowerShell’s versatility and NinjaOne’s comprehensive platform ensures robust and streamlined IT operations.