PowerShell How-To

How To Design a PowerShell Module

Modules help to make your code easier to move from one place to another.

One of the features of Window PowerShell is modules. Introduced in version 2, modules allows you to group like functions together that make your code modular, easily transportable and shareable. Modules are a great way to begin making your scripts more professional. Modules are extremely flexible in that they allow you to write whatever you'd like in them. I could simply create a module called AdamModule and just throw a bunch of random functions in there if I want to. PowerShell doesn't care. The flexibility is nice but, at the same time, it's important to adhere to what modules were designed for: groupings of like functions around a central theme.

When you first open up PowerShell you'll find a lot of modules out of the box. Below is just a small example:

[Click on image for larger view.]  Figure 1.

Modules Only Do One Thing
Notice how they're all based around a central theme of some sort. All functions inside the module only do "stuff" with AD, functions in the DnsClient module only do "stuff" that has to do with DNS client behavior. The DnsClient module will not contain any functions that do anything with a DNS server or the ActiveDirectory module won't do anything with DHCP, for example. Those are their own modules. It's important to take your cue from these modules and how they're grouped.

Custom Modules Should Build on Default Modules
I wrote an article awhile back for Pluralsight which was based on writing scripts as building blocks. It's a well-known strategy in software development to modularize code so that it can be reused and built upon. The same goes for module design. You should only write modules that essentially are smaller, more tightly-defined niches of the default PowerShell modules.

For example, the Microsoft.PowerShell.Management module that comes preloaded with PowerShell has seven different cmdlets related to the Windows event log.

[Click on image for larger view.]  Figure 2.

You can do quite a bit with these cmdlets but what if you're designing a log management project that will require some detailed event log analysis and management. This project might require functions like Test-EventLog to ensure the event log is available, Set-EventLogwhere you're making changes to the event log or even perhaps Write-ProductXLog or Write-ProductYLog if the activities those functions are doing are different enough to warrant different functions. These requirements might mean you'll need a specific EventLog module.

Do you see how I'm niching down based on existing cmdlets? I'm building upon existing code.I could do the same for the ActiveDirectory where I might have an ActiveDirectorySite module or maybe an ActiveDirectoryUser module. I'm niching down getting more specific as I go.

Module Functions Should Talk to Each Other
PowerShell has the pipeline for a reason. You can easily design functions that can pass information back and forth between each of them.

Let's say I built that log management module and have Get-ProductXLog, Move-ProductXLog and Remove-ProductXLog.I could build these in a way that doesn't use the pipeline.

$XLogs = Get-Product

XLogMove-ProductXLog -Log $XLogs

Remove-ProductXLog -Log $XLog

However, I could also prevent code duplication and easily pass logs from one to the other.

Get-ProductXLog | Move-ProductXLog | Remove-ProductXLog
The code is more succinct and easily understood.

I hope that these three tips gave you some good ideas when you start to design your next module. If designed right from the start you'll see that you're code will be more modular, understandable and easily extensible in the long run.

About the Author

Adam Bertram is a 20-year veteran of IT. He's an automation engineer, blogger, consultant, freelance writer, Pluralsight course author and content marketing advisor to multiple technology companies. Adam also founded the popular TechSnips e-learning platform. He mainly focuses on DevOps, system management and automation technologies, as well as various cloud platforms mostly in the Microsoft space. He is a Microsoft Cloud and Datacenter Management MVP who absorbs knowledge from the IT field and explains it in an easy-to-understand fashion. Catch up on Adam's articles at adamtheautomator.com, connect on LinkedIn or follow him on Twitter at @adbertram or the TechSnips Twitter account @techsnips_io.


comments powered by Disqus

SharePoint Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.