Mastering PowerShell Version Auditing: A Comprehensive Guide for IT Professionals and MSPs

Key takeaways

• PowerShell version auditing is crucial for system compatibility and security.
• The script automates auditing of both PowerShell Desktop and Core versions.
• It uses environmental variables and a hypothetical ‘Ninja-Property-Set’ cmdlet for versatility.
• Designed for PowerShell version 3 or higher, ensuring compatibility with modern systems.
• Offers a more efficient approach compared to manual version checking methods.
• Essential for IT administrators and MSPs to ensure system compliance and security.
• Regular use of the script is recommended for ongoing system health checks.
• Integrating such scripts into platforms like NinjaOne can enhance IT management efficiency.

The dynamism of Information Technology (IT) mandates continual adaptation and understanding of the tools and environments we interact with daily. One such tool, PowerShell, plays a critical role in the management and automation of Windows systems. Auditing the version of PowerShell in use is not only a matter of compliance but also a crucial step in ensuring system security and compatibility.

Background

PowerShell, Microsoft’s task automation and configuration management framework, has become an integral part of the IT landscape. The script in question is designed to audit the versions of PowerShell installed on a system, a task of significant importance for IT professionals and Managed Service Providers (MSPs). Knowing the PowerShell version helps maintain system compatibility, troubleshoot issues, and ensure that the latest security features are in use.

The script:

<#
.SYNOPSIS
    Saves PowerShell Desktop and/or Core Version(s) to a Custom Field.
.DESCRIPTION
    Saves PowerShell Desktop and/or Core Version(s) to a Custom Field.

.EXAMPLE
    (No Parameters)
    ## EXAMPLE OUTPUT WITHOUT PARAMS ##
    PowerShell Desktop: 5.1.19041.3570 - PowerShell Core: 7.3.9

PARAMETER: -CustomField "PowerShellVersion"
    Name of the custom field to save the version of PowerShell to.
.EXAMPLE
    -CustomField "PowerShellVersion"
    ## EXAMPLE OUTPUT WITH CustomField ##
    PowerShell Desktop: 5.1.19041.3570 - PowerShell Core: 7.3.9

.OUTPUTS
    None
.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2012 R2
    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 (
    [Parameter()]
    [String]$CustomField
)

begin {
    if ($env:customField) {
        $CustomField = $env:customField
    }
}
process {
    # Get PowerShell Desktop Version
    $PSDesktop = "PowerShell Desktop: $($PSVersionTable.PSVersion)"

    $PSVersionCF = if ($(Get-Command -Name "pwsh.exe" -ErrorAction SilentlyContinue)) {
        # Get PowerShell Core Version
        $pwshVersion = "$(pwsh.exe -version)" -split ' ' | Select-Object -Last 1
        $PSCore = "PowerShell Core: $($pwshVersion)"
        Write-Output "$PSDesktop - $PSCore"
    }
    else {
        Write-Output "$PSDesktop"
    }
    
    Write-Host "`n$PSVersionCF`n"

    if($PSVersionTable.PSVersion.Major -lt 3){
        Write-Error "Can only set Custom Fields on PowerShell Versions 3 or higher."
        exit 1
    }

    # Save Version(s) to custom field
    Ninja-Property-Set -Name $CustomField -Value $PSVersionCF
    
}
end {
    
    
    
}

 

Detailed breakdown

The script starts with standard PowerShell CmdletBinding and a parameter declaration for a custom field. The ‘begin’ block checks for an environmental variable named ‘customField’ and sets it as the script’s $CustomField if present.

In the ‘process’ block, the script first retrieves the PowerShell Desktop version. It then checks for the presence of PowerShell Core by trying to find ‘pwsh.exe’. If found, it retrieves the Core version. The versions are then concatenated and displayed. Notably, the script checks if the major version of PowerShell is less than 3, which is a prerequisite for setting custom fields.

Lastly, in the ‘end’ block, the script uses a hypothetical cmdlet ‘Ninja-Property-Set’ to save these versions in a custom field, leveraging the value of $CustomField.

Potential use cases

Imagine an IT administrator at a large organization needs to ensure all systems are running compatible PowerShell versions for a new deployment. Using this script, they can quickly audit the PowerShell versions across various systems, facilitating a smooth and secure deployment.

Comparisons

Alternative methods to audit PowerShell versions include manual checking or using different scripts. However, this script streamlines the process, offering a consolidated view of both PowerShell Desktop and Core versions, a feature lacking in many other approaches.

FAQs

Q1: Can this script differentiate between PowerShell Desktop and Core versions? 
A1: Yes, it distinctly identifies and displays both versions.

Q2: What happens if PowerShell Core is not installed on the system? 
A2: The script will only display the PowerShell Desktop version.

Q3: Is this script compatible with older PowerShell versions? 
A3: It requires PowerShell version 3 or higher for full functionality.

Implications

Using outdated or incompatible PowerShell versions can lead to security vulnerabilities and compatibility issues. This script aids in proactively identifying such scenarios, contributing to a more secure IT environment.

Recommendations

Best practices include regularly running this script for version audits, especially before major deployments or updates. It’s also recommended to integrate this script into regular system health checks.

Final thoughts

In an era where efficient and secure IT management is paramount, tools like NinjaOne offer a platform that can integrate such scripting solutions, providing streamlined management and enhanced security. PowerShell version auditing is a small yet critical part of maintaining system integrity, and NinjaOne can be instrumental in ensuring that such tasks are performed with ease and precision.