PowerShell modules allow you to combine multiple scripts to simplify code management, accessibility and sharing. Scripts are useful. However, they can become unwieldy over time as you create more and more of them. Modules allow you to combine script collections into cohesive units. They make managing code much easier; when code is more easily accessible, you can share it with others conveniently.
We’ll explain PowerShell modules and detail when and how to create them.
If PowerShell scripts become complex and difficult to manage, consider breaking them down into individual functions and creating a module for them. This will make it easier for you and others to edit and maintain.
In simplest terms, a module is a grouping of functions and code around a central theme. Modules are created for applications like Microsoft Exchange, Active Directory and VMware. You can even manage IIS application pools using PowerShell.
Beyond applications, modules can be used for print management, network adapter configurations and more. There’s always a central theme or object that modules are created to manage.
There are four different PowerShell modules:
Module types serve specific purposes. However, you’re most likely to create script modules. Script modules don’t require knowledge of C# or the compilation process; they’re the most common module type, especially among IT pros.
You can easily decide whether you should create a module by answering the following questions while writing a script:
If you answered yes to at least three of these questions, it’s a good bet you should be writing a module instead of a PS1 script.
With modules, you can manage and organize scripts more effectively around a central theme. This will make them easier to share and more accessible to other users.
Open Notepad. Save the file with a PSM1 extension. Done.
No, really, that’s it. That’s all it takes to create a script module. Granted, it won’t be a very functional module, but technically, it is a script module. Let’s concentrate on something more useful, though.
Examples are always a great way to demonstrate a concept, so let’s create a module to manage houses in a subdivision. This isn’t a practical example (at least not until the PowerShell team figures out how to integrate PowerShell into the physical world), but it will show off a little of what a module is capable of. In more practical situations, you could use PowerShell to create a web scraping tool, for example.
Every function is there, including the ability to:
The houses managed with this module happen to be in the “fancy subdivision” neighborhood, so it’s good practice to set that as a module variable at the top. This way, you can reference that variable in any of the PowerShell functions, making it easier to improve the readability and maintenance of your coding.
If you want to share this module with your contractors but don’t want them to build any new houses or remove any houses without your permission, you should allow them only the Get-* functions and Set-* functions. In a similar way, you can use PowerShell to manage user profiles controlling what each user can do.
But because you want your contractors to be able to tell what neighborhood they’ll be working in, you allow them to see the value of $Neighborhood in their PowerShell console.
If you regularly want to reuse code, share code with co-workers, manage a single object or entity, or break complex scripts into manageable functions, PowerShell modules will save you a lot of time.
Now you have the house module created; let’s call it House.psm1. If you want your contractors to use it, place it in a shared folder called HOMESERVERfileshare on your network (try syncing folders with PowerShell so that all contractors have the latest module version).
Next, tell each contractor to open their PowerShell console and import it.
Importing the module brings all the functions and variables into each contractor’s PowerShell session.
If you import a module into PowerShell, you can access it in that current session only. For new sessions, you’ll need to import it again unless you place it in the PSModulePath.
You can see that they can run Get-House and Set-House, but the moment they try to run Remove-House, PowerShell throws an error. This is because PowerShell doesn’t recognize this function. You didn’t allow it to load into the current session.
At this point, they can still use this module with no problem. However, if they close the console and open it again, the Remove-House function won’t be available.
Whenever you run Import-Module (or use PowerShell’s auto-loading feature), it loads only the module in the current session. It will not load it again. The contractor must either load the module again or, preferably, place the module into the PsModulePath so it auto-loads the next time a House function is needed.
This should get you started using modules.
Mark Fairlie contributed to this article.