How and When to Create and Use PowerShell Modules

What is a PowerShell module?

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:

• Script modules: Script modules are PSM1 files that typically contain functions. However, they can contain any valid PowerShell code.
• Binary modules: Binary modules are compiled DLL files typically not created by IT pros; these are usually left up to developers.
• Manifest modules: Manifest modules are script modules that contain a manifest.
• Dynamic modules: Dynamic modules are never written to disk and are available only in memory.

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.

When should you create a PowerShell module?

You can easily decide whether you should create a module by answering the following questions while writing a script:

1. Will the code I’m writing need to be used more than once?
2. Does this code essentially manage a single object or entity?
3. As I write this code, do I find that I’m breaking it apart into functions because it’s getting too complex to be in a single script?
4. Do I need to share the code with others?

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.

How do I create a PowerShell module?

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:

• Create new houses
• Find all the houses created
• Modify the houses
• Remove houses

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.

How do you use a PowerShell module?

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.

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.