Automating Tasks in PowerShell: Embracing DRY (Don’t Repeat Yourself) with Cmdlets

Alright, PowerShell heroes, let’s talk about something fundamental in the world of programming and scripting: Automation. If you’ve ever had to perform the same task repeatedly, you’ve probably thought, “There’s got to be a better way to do this!” Enter cmdlets—your trusty sidekicks in automating repetitive tasks.

At the heart of efficient script writing is the DRY principle: Don’t Repeat Yourself. It’s a simple but powerful idea: Avoid duplicating code by creating reusable components. In the world of PowerShell, these reusable components come in the form of cmdlets (pronounced “command-lets”). Think of cmdlets like your personal superheroes that do the heavy lifting so you don’t have to keep repeating the same tedious tasks over and over again.

So, how does this all relate to MSI files? While MSI management is useful, the real lesson here is how to write reusable cmdlets that simplify your workflow and allow you to automate any task—be it installing, repairing, or removing software or something else entirely.

The DRY Principle in Action: Why Write Repetitive Code?

Imagine you’re a system administrator juggling multiple tasks: installing software, checking for updates, and cleaning up old programs. If you’re doing this by hand every time, that’s a whole lot of manual repetition. But what if you could automate those tasks? What if you could just type a few commands and let your scripts do the heavy lifting?

That's the magic of cmdlets.

When you find yourself repeating the same actions in scripts or PowerShell commands, that's a red flag. It's time to apply DRY and create cmdlets that you can reuse in future projects or different parts of the same project. You’ll save time, reduce errors, and get back more hours of your life. Here’s an example using MSI installation as the vehicle for understanding this concept, but you can apply the same logic to any repetitive task.

Using Cmdlets to Automate MSI Management (Without Rewriting the Wheel)

Here’s the deal: If you’re installing or uninstalling MSIs on multiple machines, you could write out every individual command and go through the pain of doing it manually. Or, you could create reusable cmdlets that handle these tasks in a way that makes it easy to change parameters, adjust configurations, and automate tasks across different systems.

Let’s take a look at an example that encapsulates automation and DRY in action—without making it all about the MSIs.

1. The Power of Modular Cmdlets: A Simple Example

Instead of writing out commands for every single MSI install, repair, or removal, you can wrap them into cmdlets that allow you to pass parameters. These cmdlets can take arguments (like the name of the software or the path to the installer) and act accordingly—making your scripts flexible and reusable.

Let’s look at a generic MSI installer cmdlet:

function Install-Software {
    <#
    .SYNOPSIS
    Installs MSI-based software.
    .PARAMETER SoftwarePath
    The full path to the MSI installer.
    .PARAMETER Arguments
    Optional. Arguments to pass to msiexec.exe.
    #>
    [CmdletBinding()]
    Param(
        [Parameter(Mandatory = $true)]
        [string]$SoftwarePath,

        [Parameter(Mandatory = $false)]
        [string]$Arguments
    )

    Process {
        if (Test-Path $SoftwarePath) {
            Write-Host "Installing $SoftwarePath..." -ForegroundColor Yellow
            $arguments = "/i $SoftwarePath /quiet $Arguments"
            Start-Process msiexec.exe -ArgumentList $arguments -Wait -ErrorAction Stop
            Write-Host "Installation completed for $SoftwarePath." -ForegroundColor Green
        } else {
            Write-Error "Installer not found at path: $SoftwarePath"
        }
    }
}

How This Saves You Time:

• Reusable: You can call this cmdlet anywhere you need to install software, without rewriting the same msiexec command.
• Flexible: The Arguments parameter means you can change how the software installs based on your needs (quiet mode, logging, etc.).
• Readable: No need for long, unwieldy scripts—just call Install-Software and pass the right parameters.

2. Extending This to Other Tasks (DRY in Action)

The same principle applies to other tasks, such as uninstalling, repairing, or finding installed software. Let’s say you also want to automate the process of removing software. Instead of writing a separate script for each application, you could build a reusable Remove-Software cmdlet:

function Remove-Software {
    <#
    .SYNOPSIS
    Removes MSI-based software.
    .PARAMETER SoftwareName
    The name of the software to remove.
    #>
    [CmdletBinding()]
    Param(
        [Parameter(Mandatory = $true)]
        [string]$SoftwareName
    )

    Process {
        $uninstallString = Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*$SoftwareName*" } | Select-Object -ExpandProperty IdentifyingNumber
        if ($uninstallString) {
            Write-Host "Removing $SoftwareName..." -ForegroundColor Red
            Start-Process msiexec.exe -ArgumentList "/x $uninstallString /quiet" -Wait -ErrorAction Stop
            Write-Host "$SoftwareName removed successfully." -ForegroundColor Green
        } else {
            Write-Error "Software $SoftwareName not found."
        }
    }
}

Why Does This Work?

• Consistency: You use the same core logic to handle software removal.
• DRY: Same principle, different task—now your script isn’t littered with the same removal logic over and over again.

3. Keeping It Dry (And Not Dry in a Bad Way)

By keeping your scripts modular and reusing cmdlets across different tasks, you're also improving your code's maintainability. If you need to update a part of your logic (say, a switch to msiexec or a custom logging feature), you can do it once—and it’s applied across your entire automation ecosystem.

Think about it this way: If you had to update the logic for installing MSIs in 10 different places, you'd spend all day editing your scripts. But if you had one centralized Install-Software cmdlet, you’d just tweak that, and voila, all of your software installs are updated.

4. Real-World Application: From MSI to Everything Else

It’s important to note that this isn’t just about MSIs. The DRY principle extends far beyond just installing software. In fact, it applies to virtually any repetitive task you do in PowerShell, such as:

• System updates: Automate downloading and applying patches.
• User management: Create cmdlets for adding, removing, and modifying user accounts.
• File management: Automate backup tasks, file cleanups, and data transfers.
• Monitoring: Set up reusable cmdlets to monitor system health or log events.

Once you get the hang of automating tasks this way, you’ll quickly realize that you’re writing less code, fixing fewer bugs, and spending more time doing cool stuff instead of repeating manual processes.

Conclusion: PowerShell—Your DRY Superpower

The bottom line is that PowerShell cmdlets are your best friend when it comes to automating repetitive tasks. When you write modular, reusable cmdlets that follow the DRY principle, you unlock a world of efficiency. You reduce errors, increase maintainability, and—let’s be honest—look like a total wizard to anyone who sees your clean, efficient scripts.

So, the next time you’re faced with a task you’ve already done 10 times, ask yourself: “Is there a way to automate this?” The answer is almost always, “Yes, there is.” And PowerShell is here to help make that magic happen.

Now go forth, automate, and never write the same code twice—unless you’re copying this article for reference (we won’t judge).