- Activate BitLocker with manage-bde, PowerShell, or WMI - Wed, Sep 20 2023
- Join Azure Active Directory with Windows 11 - Tue, Sep 12 2023
- Manage enhanced security mode in Microsoft Edge using Group Policy - Fri, Sep 8 2023
Previous Windows updates often introduced a new PowerShell version with a vastly enhanced feature set. Thus, in mixed environments, you can’t rely on the availability of all the cmdlets and language elements that you used in your script. It is therefore recommended to get the PowerShell version of the system your code runs on or check the availability of modules to prevent your script from failing.
Requiring a PowerShell version
If you already know which PowerShell version is required, you can use the #requires statement to ensure that the script only runs in a suitable environment.
For instance, with the command below, you can instruct your script to abort if PowerShell version 3.0 or higher is not installed:
#requires -version 3.0
The script requires PowerShell 3.0
Checking the module version
In some cases, not the PowerShell version but the availability of a module or a particular version of it is crucial to execute a script properly. The #requires statement with the parameter -module only helps in PowerShell version 3.0 or higher.
In the next example, the availability of the Hyper-V module is necessary to execute the script. If the module is not loaded, PowerShell will import it automatically. If the module is not installed at all on the computer, PowerShell will abort the script.
#requires -modules Hyper-V
As in the command below, you can use a hash table to make the execution of your script dependent on a particular version of a module.
#requires -modules @{ModuleName="Hyper-V";ModuleVersion=1.1.0.0}
By the way, the #requires statement is also useful if you have to ensure that the script runs with administrator privileges (-RunAsAdministrator) or that a particular snap-in is available (-PSSnapin).
Getting the PowerShell version
To determine which PowerShell version a script requires or which module version is installed on the system, you will often test the script in different environments. If you run into problems for which no workaround exists in an older version, you will want to know more about the system—in particular, you need to get the PowerShell version number in your script.
Various ways exist to accomplish this. The easiest option is to read the system variable $PSVersionTable and its property PSVersion, which offers detailed information about the installed PowerShell version:
$PSVersionTable.PSVersion
Another option is the Get-Host cmdlet:
Get-Host | Select Version
If you want to find out if necessary modules are available, you can use the Get-Module cmdlet:
Get-Module Hyper-V
The above command also gets you the version number of the module. It is important to note that the module won’t be loaded this way and, if the module is unavailable, no error message will be generated.
Trying to import a module
If you need to be sure that a module is really available, you can try to import the module and execute alternative code if the module is unavailable. For example:
Try { Import-Module Hyper-V -ErrorAction Stop Write-Host "This line will only be executed if the Hyper-V module was imported." } Catch { Write-Host "Could not find the Hyper-V module." } Write-Host "The script proceeds if the module is available or not."
The common parameter -ErrorAction with the value “stop” ensures that the script continues in the catch block if the module couldn’t be imported. The script then proceeds with executing the code after the try/catch block.
Importing the Hyper-V module failed.
What about SnapIns? Is there a way to check for say the Quest.ActiveRoles.ADManagement snapin with this?
James, if you want to check for the availability of a specific Snap-in, you should use the Cmdlet Get-PSSnapin.