Modules and commands

In PowerShell, you use commands to have PowerShell carry out some operation, whether it be displaying a file, adding a user to Active Directory, or setting the IP address of a computer.

Commands

In PowerShell, a command is something you can run from a script file or at the console that performs some operation. There are several types of PowerShell commands:

• Cmdlets: These are small programs (technically written as a .NET class).
• Functions: These are, in effect, script cmdlets, which are small scripts that emulate the behavior of a cmdlet. You can think of them as script cmdlets.
• Scripts: These are sets of PowerShell commands, which you save with the extension .ps1.

In addition, the term command also applies to the many Win32 console applications, shipped with Windows 11 (over 300). Many of these are familiar to IT professionals, such as ipconfig.exe and ping.exe).

All PowerShell commands can accept and produce objects. The Win32 console applications, on the other hand, only take parameters (which tend to be unique to each console application) and output a string.

Console applications are very useful, although they can be harder to use in an automation scenario. If you need to, you can capture the output of a console application and use string manipulation to pull out the specific information you need. This approach, often called prayer-based parsing, is common in the Unix/Linux world. PowerShell objects make this process easier, and in most cases, there are PowerShell commands that can replace old console applications.

Modules

In PowerShell, a module contains a set of PowerShell commands, module metadata, and other information (such as help or formatting information). Before using any PowerShell command, PowerShell first loads the module containing that command.

By default, if you use a command in a module stored in one of a set of well-known folders, PowerShell automatically loads the module and then executes the command. Powershell has several default locations from which to load modules. The Windows PSModulePath environment variable defines PowerShell’s paths to discover and load modules (by default). Every time PowerShell starts up, it examines the current value of the module path variable and determines all the commands available (in those locations). This process creates a cache of all commands and which module to use.

For example, to use the Get-Process command to view all the running processes, PowerShell needs to load the Microsoft.PowerShell.Management module. This is the module that contains this command. Once PowerShell loads the module, it can execute the command.

Each time PowerShell starts up, it caches the location of every command in every module (for those modules located in one of those well-known places). This means that, in most cases, you only need to type a command, and the rest of the magic happens behind the scenes. You can put a module into any location on the disk and manually load it using Import-Module.

You can get modules from a variety of places:

• Built-in modules: These are modules that come with Windows PowerShell and PowerShell 7. They provide the basic PowerShell functionality.
• With applications or features: Some applications or Windows optional features come with PowerShell management tools. These enable you to manage the feature or the application. See Chapter 5 for more details on the RSAT.
• From the PowerShell Gallery: This is a Microsoft-maintained repository of community-authored modules. There are thousands of modules to choose from, as you can see at https://packt.link/ghY17.
• Commercial software offerings: Some software firms provide commercial modules. For example, /n software offers a suite of cmdlets with great communication capabilities. For more information about the cmdlets, see https://packt.link/FLF11.
• DIY: You are free to develop and use modules you have written or that your organization has developed. DIY modules exist (in the PowerShell Gallery) for a huge range of uses. For example, a Grateful Dead enthusiast created a module of scripts (https://packt.link/gq1Lb). These scripts may not help you manage Windows 11, but they indicate the breadth of available modules. Seek, and ye shall find, as the saying goes.

No matter where you get them from, modules are a critical component of PowerShell that help the authors of PowerShell package and ship their PowerShell modules.

If you want to learn more about building your own PowerShell 7 module, see https://packt.link/wvznY.

Discovery

In PowerShell, the term discovery means using built-in commands to find information on how to use PowerShell and PowerShell commands. The more you can discover, the less you need to memorize. Discovery is an extremely useful feature that the PowerShell team designed in the first versions and refined later. Without discovery, using thousands of commands and hundreds of potential modules would be much more difficult.

There are four key aspects of discovery within PowerShell:

• Discovering modules: Since modules contain commands, finding likely modules is useful. You can use the Get-Module -ListAvailable cmdlet to see all the modules that PowerShell can discover on your host. You can also use Find-Module to find the modules contained in the PowerShell Gallery that may be interesting.
• Discovering commands: Once you have a module, you can find the commands within the module by using Get-Command and specifying the module name like this:

Figure 2.11 – Discovering commands in a module

• Discovering cmdlet details: Once you know the commands, you can learn how a given command works – what parameters you can specify, what it outputs, and most importantly, what this command does. Using Get-Help, as noted earlier, helps you to work out what a cmdlet, function, or script does. For example, you can determine more details of the Start-BitsTransfer command like this:

Figure 2.12 – Getting help on a cmdlet

The help text gives you more details about what a command does.

• Discovering what a cmdlet returns (that is, the objects emitted by the command): If you have a cmdlet that returns a value, remember that what you see in the console represents the objects returned from the cmdlet. The actual objects may contain more information that PowerShell does not display by default. To discover the details of the objects returned, you can do this: if you are using Windows 11’s Hyper-V function, you can use Get-VM to determine the VMs on your host.

Figure 2.13 – Getting the members of a class

These four discovery approaches help you use PowerShell – to find modules and commands, determine what a PowerShell command does, and establish which outputs, if any, result.