Welcome to Day 14 of the “100 Days of DevOps with PowerShell”! For background on our goals in this series, see Announcing the “100 Days of Devops with PowerShell” Series here at SCC.
In Windows Management Framework 5.0 (WMF 5.0) OneGet was considered a key feature of the release for discovering and installing packages. Also included in that release was PowerShellGet, which is similar to OneGet but focusing on finding and installing PowerShell Desired State Configuration (DSC) resources and modules.
Up until WMF 5.0 discovering and installing modules has been done by using your favourite search engine, downloading the zip file of the module, unblocking it and extracting it to the $env:USERPROFILE\WindowsPowerShell\Modules folder. Not a particularly efficient method for a product that is automation tool! There have been attempts to overcome this challenge in the past, notably PSGet and PoshCode. PSGet is still being maintained, but PoshCode’s development seems to have ground to a halt with the release of WMF 5.0.
Microsoft’s answer to the work already started by PSGet and PoshCode is PowerShellGet, a module that allows for the easy discovery and installation of PowerShell modules and DSC resources. As DSC continues to gather traction in the enterprise the need for for easy access to DSC resources is becoming a necessity.
The PowerShellGet cmdlets are part of the PowerShellGet module, of which there are four:
For OneGet the default provider was Chocolatey and there are cmdlets available to manage additional providers, but with PowerShellGet there is no cmdlet to specify the provider or repository from which to install modules or at least int this CTP version. instead the default repository is stored in the variable $PSGallerySourceUri and to check the value of this variable you must import the module first.
A good tip is here whenever importing a module for the first time always use –Verbose. Not only do you get the list of cmdlets being imported, but also specific variables associated with the module as well as aliases. Looking at the value of $PSGallerySourceUri you can see it points to a Microsoft hosted repository which redirects to https://msconfiggallery.cloudapp.net/api/v2/. If you drop the “api/v2” off the URL you reach the homepage of the PowerShell Resource Gallery, where you will find a list of all the modules as well as statistics on the downloads of each package:
At present uploading to the PowerShell Resource Gallery is by invite only, so the cmdlets to publish and update modules: Publish-Module and Update-Module are not applicable to most. However, the Find-Module and Install-Module cmdlets are available to anyone.
Finding and Installing Modules
Finding and installing modules is, like OneGet, very straight forward as shown below installing the PowerShell Community Extensions:
As well as the –MinimumVersion and –RequiredVersion parameters we can also get a little more creative on searching for modules and this may become more useful in the future as PowerShellGet becomes the primary mechanism for retrieving the latest modules.
#Finding modules updated in the last day
Find-Module | Where DateUpdated -gt (Get-Date).addDays(-1)
#Finding any experimental DSC resources
Find-Module -Name x*
#Find modules related to SQL
Find-Module | Where Description -like '*sql*'
#Find modules produced by Microsoft
Find-Module | Where Author -like 'Microsoft*'
Only the basics of PowerShellGet have been covered here, but in the future we’re going to look at one of the most common requests I hear and that is if it’s possible to create your own repository. This is a key piece in solving the DevOps puzzle of “how can I share my code and modules with my co-workers?”
To see the previous installments in this series, visit “100 Days of DevOps with PowerShell”.