A PowerShell module is a package containing PowerShell cmdlets, providers, functions, workflows, variables and aliases. Modules are suitable for organizing, bundling and sharing PowerShell commands easily.
A PowerShell module is, in the simplest terms, a conjoined amount of PowerShell functions or grouped code, centered around a general main theme. All PowerShell cmdlets and providers are added by a module or a snap-in.
The receivers of these modules can add the commands contained in the module to their PowerShell sessions to use them like built-in commands. To succeed in orientating all functions in a module around the same concept, there are some guidelines to follow, such as names hinting relations. E. g. the ActiveDirectory module contains functions that interact in some sort with the Active Directory. In addition, all the nouns in the function names begin with an AD, so it’s simpler to discover certain functions with an organized name structure.
Different types of PowerShell modules
There are 4 different types of PowerShell modules:
The most common type of module, which does not require any C# knowledge, basically any PSM1 files that contains mainly functions and code, used by script developers and administrators
Contain compiled code, based on a .NET Framework assembly (DLL), used by cmdlet developers to create modules containing cmdlets, providers, etc.
Script modules containing a manifest with e.g. information about the author, etc.
A special type of module that is never written to disk and exists only in memory, members of the dynamic module (functions/variables) are immediately available in the PowerShell session until the session is closed.
When to use PowerShell modules
The answer to this question is more subjective than it might seem, as it depends on each one’s manual implementation speed of code, but the following points may work as a good indicator whether to begin using modules or stay with ad-hoc scripting:
How intense is the repeated usage of code?
Is a single object or an entire entity managed by the code essentially?
Does the complexity of the code result in a segmented code instead of a single script?
Is there a need to share the code (on a regular basis)?
In most cases the main tasks of DevOps are focussed on the automation of processes (“infrastructure as code”). To provide a continuous integration (CI) or even continuous deployment (CD), teams with a DevOps-mindset may have multiple usages for modules. The use cases for modules may vary from script analyzers, to push your code to follow some accepted best practices, to testing and validation of environments.
How to create a PowerShell module
Basically, a module contains a couple of functions, which bound together with the .psm1 file-extension already make up one. Every file containing functions can be changed from a script file to a module by altering the extension to .psm1.
In order to create a Manifest Module, just make use of the simple New-ModuleManifest-cmdlet, the manual alternative: creating a .psd1 file containing the requirements and placing it in the module folder.
After the New-ModuleManifest-cmdlet has been run, it prompts the user for a path to the module manifest file. Right after defining the path, one must add an author and a ModuleToProcess, which acts as the name of the functions storing .psm1 file. To have a look into more options for the manifest, simply run Get-Help New-ModuleManifest. Once a manifest has been added to a module, it should be listed as a “manifest” type on the available module list (via Get-Module -ListAvailable).
A new dynamic module can be created by using the New-Module command of the preinstalled Microsoft.PowerShell.Core module, which will only exist in memory.
Tutorial: Building Your first PowerShell Module
Adam Bertram guides you through the process of building your first PowerShell module, including detailed instructions and code examples. Head over to our blog for the article.
Some “core” PowerShell modules are already preinstalled by PowerShell, but if you want to add some more, you have to install them by adding the files as a folder to your modules directory.
Start by creating a modules’ directory by using the command New-Item -Type Directory -Path $HOMEDocumentsWindowsPowerShellModules and complete it by adding the module folder to the directory, using Windows Explorer, Cmd.exe or PowerShell.
The Import-Module command can be used to selectively import commands by adding the “Function” parameter, in order to save time when importing modules from remote systems, such as the Office365 modules.
By default, all installed modules for all users are being placed into the module folder (C:ProgramFilesWindowsPowerShellModules). If a certain module should be used by only a single user, the scope “CurrentUser” can narrow it down.
Any version of PowerShell since 3.0 is capable of auto-loading modules automatically once any command of an installed module is being executed. That cuts out any set-up or configuration, making it simple to use. To find installed but not yet invoked modules, run the now known Get-Module -ListAvailable-command. To list only imported modules in the current session, simply run Get-Module. If you want to find specific commands in a module, you can achieve this by Get-Command -Module.
You can even find help for the commands in a module (Get-Help ). To function properly via the Get-Help-command after the import, the functions are required to have added # .ExternalHelp -Help.xml. Another way to seek help are external help files in some modules, identified by the file extension -Help.xml.
Importing PowerShell modules
Importing Remote Modules or, as it is called, Implicit Remoting describes commands being executed on a remote machine, rather than locally. It is intermittently used with Microsoft’s Office 365 modules. The vast majority of them connects to an Office 365 server, followed by importing a module. Or in other words, if one of the commands is run, they directly get forwarded to be run on the remote server and the output is being sent back to the current session.
To import a remote module, a PSSession has to be created first (via New-PSSession). The next step is to import the module available on the remote device (Import-Module -Name ActiveDirectory -PSSession $AdminServer -Prefix ‘Rmt’).
To remove a module, the command Remove-Module does the job. Once removed, all commands that the module once added are deleted from the session, it works quite as the reversion of importing a module. Note that only the module will be removed from the local session, but without removing the module files.
Where do I find third-party PowerShell modules and scripts?
Aside from the preinstalled modules of Windows PowerShell itself, there is an enormous amount of third-party modules out there.
ScriptRunner, for example, provides with the so-called ActionPacks and ExtensionPacks a range of free and ready-to-use PowerShell script collections, which cover typical use cases in IT operations and are written according to Microsoft Best Practices.
For finding specific modules, we recommend the PowerShellGallery. It functions as a central repository for sharing and acquiring PoSh code, such as modules, scripts and more. They are mainly distributed through a PSRepository, which are generally web servers where files can be published, whereas these PSRepos can be hosted by yourself or used via online options like PowerShellGallery.
Get-PSRespository will unveil a list of the available PSRepositories, tagged with the information whether a source publishes code approved by Microsoft or not (trusted/untrusted). To change the trust state of PowerShellGallery e.g, use Get-PSRepository -Name PSGallery | Set-PSRepository -InstallationPolicy Trusted.