Package and Module management can be a pretty important piece of using PowerShell to automate or to just run simple scripts to father information. There are some nuances and things to remember when working with these parts of PowerShell. Here are some tips and tricks I’ve run across:
(1) NuGet (Specific Package Example)
Querying to see if the module is installed and instead get a question back if I want to install it:
Not exactly what I would have expected. If I want to query for NuGet and get an answer as to whether it is installed, I need to do something like this: First, look for all PowerShell Package Providers:
[sourcecode language=”powershell”]
$PackageProviders = (Get-PackageProvider -ListAvailable).
[/sourcecode]
Name Then we can query the variable to see if the list of all providers contains NuGet:
[sourcecode language=”powershell”]
If ($PackageProviders -NotContains 'NuGet'){
[/sourcecode]
If it does, then we can check the version and move on to the next step or, if it is not in the list, we could install the latest version for example like so:
[sourcecode language=”powershell”]
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201
/[sourcecode]
Notice the -MinimumVersion parameter. This can be useful if you are looking to guarantee a particular level of functionality from the item you are installing. For the above example, the version specified was the minimum needed for another requirement in a script.
<strong>(2) Installing Modules</strong>
If you are not familiar with how PowerShell works, cmdlets are provided by Modules. The PowerShell Modules contain groups of cmdlets that are then exposed and made visible depending on what rights you have according to RBAC. Now, if you are working on a new server or jump box to manage a particular product, you may need to install new modules to make this possible, These modules may be loaded manually by downloading the files and storing them in a folder like other modules are on that computer. For example:
Or, with newer versions of PowerShell, we can also install the modules with the PowerShell cmdlet 'Install-Module'. There are some caveats and things to remember with this method. One, we need a newer version of PowerShell (5.0+). We need permissions to install the module on the machine (could be blocked by GPO or an administrator) and this may need to be verified ahead of time. We would also need to know the exact name of the module and possibly even the PowerShell Gallery that it can be downloaded from (some modules exist in multiple repositories). Lastly, we may need to grant permission for PowerShell to download a module from that gallery with a one-liner like so:
[sourcecode language="powershell"]
Set-PSRepository -Name "PSGallery" -InstallationPolicyTrusted
[/sourcecode]
Once installed we should be able to import it and start working with the cmdlets it provides.
(3) Importing Modules (with Error Checking)
When loading modules to be used, say with a script or just to run some cmdlets, it might be necessary to add some sort of error checking. The error checking could be present to force a script to exit if the modules does not load or at the very least report the issue so that it can be fixed at a later time.
An example of this could be trying to load the Active Directory PowerShell module. We can wrap the import with a Try{}Catch{} code block like so:
[sourcecode language=”powershell”]
$ADModuleLoad = $True
Try {
Import-Module ActiveDirectory -ErrorAction STOP Write-Host "Active Directory Module was loaded."
} Catch {
Write-Host "Active Directory Module could not be loaded!"
$ADModuleLoad = $False
}
[/sourcecode]
We can visually indicate the failure with the above code.
Caveats To The Above
Some modules and even packages are subject to prerequisites. You may need to walk-through multiple steps in order to get a new module installed. You may even need to upgrade the PackageManagement package provider and this requires restarting the shell after it is complete. So do not assume a new module install in always going to be quick and painless.
