Топ-3 модуля power shell

What is a PowerShell Module?

Put briefly, a PowerShell module — similar to a Python module — is a way to organize a collection of related code, variables, aliases, etc. in a contained workspace.

There are two types of PowerShell modules:

• Script modules (PowerShell scripts)
• Binary modules (compiled DLLs)

Module Loading Paths

If you inspect this PowerShell environment variable, you can see from which folders your PowerShell modules will be loaded.

$env:PSModulePath

If you install a module from PowerShell Gallery, you can use the Scope parameter to determine which folder in $env:PSModulePath the module will be downloaded.

# Local User
# Install the module to C:\Users\user.name\Documents\WindowsPowerShell\Modules\ on Windows
# Install the module to /home/user.name/.local/share/powershell/Modules on Linux
Install-Module -Name <module-name> -Scope CurrentUser
# Global Module
# Install the module to C:\Program Files\WindowsPowerShell\Modules on Windows
# Install the module to /usr/local/share/powershell/Modules on Linux
Install-Module -Name <module-name>

Why mention this?

When to Create a Module

1. Create a script for a distinct purpose or project
2. Additional scripts continue to be added
   • Adding helper scripts
   • Or, extending the scope of the project
3. The project scope continues to grow, we need a place to keep things organized

Scaffolding the Module

Module Directory Structure

ModuleName
|___ModuleName.psd1
|___ModuleName.psm1
|___Private
| |___ps1
| |___Verb-Noun.ps1
| |___Verb-Noun.ps1
|
|___Public |___ps1 |___Verb-Noun.ps1 |___Verb-Noun.ps1

• ModuleName — Name the module after the project or its intended purpose
• ModuleName.psd1 — This is the module manifest, we’ll cover this later
• ModuleName.psm1 — This is your script module, we’ll cover this later as well
• Private — This is the directory to store your private functions and variables (eg. helper functions)
  • ps1 — The PowerShell functions are stored here and are not directly referenced by the user
    • Verb-Noun.ps1 — the script file containing the private PowerShell function.
• Public — This is directory to store your public functions and variables
  • ps1 — The PowerShell function code is stored here and these are the cmdlets the user will be directly running
    • Verb-Noun.ps1 — the script file containing the public PowerShell function

Commands to Create the Module Structure

# Variables
$year = (Get-Date).Year
$moduleName = 'TestModule'
$templateString = 'Test Module'
$version = '1.0'
# Create the "TestModule" top-level directory
New-Item -ItemType Directory -Name $moduleName
# Create subdirectories
# TestModule
# |___ ...
# |___ ...
# |___Private
# | |___ps1
# |___ ...
New-Item -Path "$PWD\$moduleName\Private\ps1" -ItemType Directory -Force
# Create subdirectories
# TestModule
# |___ ...
# |___ ...
# |___ ...
# |___Public
# |___ps1
New-Item -Path "$PWD\$moduleName\Public\ps1" -ItemType Directory -Force
# Create the script module
# TestModule
# |___ ...
# |___ TestModule.psm1
New-Item -Path "$PWD\$moduleName\$moduleName.psm1" -ItemType File
# Create the module manifest
# TestModule
# |___TestModule.psd1
# |___ ...
$moduleManifestParameters = @{ Path = "$PWD\$moduleName\$moduleName.psd1" Author = $templateString CompanyName = $templateString Copyright = "$year $templateString by Benjamin Heater" ModuleVersion = $version Description = $templateString RootModule = "$moduleName.psm1"
}
New-ModuleManifest @moduleManifestParameters

Inspecting the Manifest

ModuleName
|___ModuleName.psd1
|___ ...
|___ ...

Get-Content "$PWD\TestModule\TestModule.psd1"`

#
# Module manifest for module 'TestModule'
#
# Generated by: Test Module
#
# Generated on: 8/17/2023
#
@{
# Script module or binary module file associated with this manifest.
RootModule = 'TestModule.psm1'
# Version number of this module.
ModuleVersion = '1.0'
# Supported PSEditions
# CompatiblePSEditions = @()
# ID used to uniquely identify this module
GUID = '147cfba3-3c6d-4260-aeca-f99aa900cc0c'
# Author of this module
Author = 'Test Module'
# Company or vendor of this module
CompanyName = 'Test Module'
# Copyright statement for this module
Copyright = '2023 Test Module by Benjamin Heater'
# Description of the functionality provided by this module
Description = 'Test Module'
# Minimum version of the Windows PowerShell engine required by this module
# PowerShellVersion = ''
# Name of the Windows PowerShell host required by this module
# PowerShellHostName = ''
# Minimum version of the Windows PowerShell host required by this module
# PowerShellHostVersion = ''
# Minimum version of Microsoft .NET Framework required by this module. This prerequisite is valid for the PowerShell Desktop edition only.
# DotNetFrameworkVersion = ''
# Minimum version of the common language runtime (CLR) required by this module. This prerequisite is valid for the PowerShell Desktop edition only.
# CLRVersion = ''
# Processor architecture (None, X86, Amd64) required by this module
# ProcessorArchitecture = ''
# Modules that must be imported into the global environment prior to importing this module
# RequiredModules = @()
# Assemblies that must be loaded prior to importing this module
# RequiredAssemblies = @()
# Script files (.ps1) that are run in the caller's environment prior to importing this module.
# ScriptsToProcess = @()
# Type files (.ps1xml) to be loaded when importing this module
# TypesToProcess = @()
# Format files (.ps1xml) to be loaded when importing this module
# FormatsToProcess = @()
# Modules to import as nested modules of the module specified in RootModule/ModuleToProcess
# NestedModules = @()
# Functions to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no functions to export.
FunctionsToExport = '*'
# Cmdlets to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no cmdlets to export.
CmdletsToExport = '*'
# Variables to export from this module
VariablesToExport = '*'
# Aliases to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no aliases to export.
AliasesToExport = '*'
# DSC resources to export from this module
# DscResourcesToExport = @()
# List of all modules packaged with this module
# ModuleList = @()
# List of all files packaged with this module
# FileList = @()
# Private data to pass to the module specified in RootModule/ModuleToProcess. This may also contain a PSData hashtable with additional module metadata used by PowerShell.
PrivateData = @{ PSData = @{ # Tags applied to this module. These help with module discovery in online galleries. # Tags = @() # A URL to the license for this module. # LicenseUri = '' # A URL to the main website for this project. # ProjectUri = '' # A URL to an icon representing this module. # IconUri = '' # ReleaseNotes of this module # ReleaseNotes = '' } # End of PSData hashtable
} # End of PrivateData hashtable
# HelpInfo URI of this module
# HelpInfoURI = ''
# Default prefix for commands exported from this module. Override the default prefix using Import-Module -Prefix.
# DefaultCommandPrefix = ''
}

When we ran the New-ModuleManifest command before, PowerShell added our inputs to a .psd1 file with the above template.

The module manifest is responsible for declaring some important things about our module, including:

• The RootModule script (eg. TestModule.psm1)
• The GUID to uniquely identify the module
• FunctionsToExport for function names that should be executable by the user
• CmdletsToExport for compiled cmdlets that should be executable by the user
• VariablesToExport for any module-specific variables
• AliasesToExport for any aliases defined in your functions or cmdlets
• And, many more configurations

Inspecting the Script Module

ModuleName
|___ ...
|___ModuleName.psm1
|___ ...

Get-Content "$PWD\TestModule\TestModule.psm1"

$directorySeparator = [System.IO.Path]::DirectorySeparatorChar
$moduleName = $PSScriptRoot.Split($directorySeparator)[-1]
$moduleManifest = $PSScriptRoot + $directorySeparator + $moduleName + '.psd1'
$publicFunctionsPath = $PSScriptRoot + $directorySeparator + 'Public' + $directorySeparator + 'ps1'
$privateFunctionsPath = $PSScriptRoot + $directorySeparator + 'Private' + $directorySeparator + 'ps1'
$currentManifest = Test-ModuleManifest $moduleManifest
$aliases = @()
$publicFunctions = Get-ChildItem -Path $publicFunctionsPath | Where-Object {$_.Extension -eq '.ps1'}
$privateFunctions = Get-ChildItem -Path $privateFunctionsPath | Where-Object {$_.Extension -eq '.ps1'}
$publicFunctions | ForEach-Object { . $_.FullName }
$privateFunctions | ForEach-Object { . $_.FullName }
$publicFunctions | ForEach-Object { # Export all of the public functions from this module # The command has already been sourced in above. Query any defined aliases. $alias = Get-Alias -Definition $_.BaseName -ErrorAction SilentlyContinue if ($alias) { $aliases += $alias Export-ModuleMember -Function $_.BaseName -Alias $alias } else { Export-ModuleMember -Function $_.BaseName }
}
$functionsAdded = $publicFunctions | Where-Object {$_.BaseName -notin $currentManifest.ExportedFunctions.Keys}
$functionsRemoved = $currentManifest.ExportedFunctions.Keys | Where-Object {$_ -notin $publicFunctions.BaseName}
$aliasesAdded = $aliases | Where-Object {$_ -notin $currentManifest.ExportedAliases.Keys}
$aliasesRemoved = $currentManifest.ExportedAliases.Keys | Where-Object {$_ -notin $aliases}
if ($functionsAdded -or $functionsRemoved -or $aliasesAdded -or $aliasesRemoved) { try { $updateModuleManifestParams = @{} $updateModuleManifestParams.Add('Path', $moduleManifest) $updateModuleManifestParams.Add('ErrorAction', 'Stop') if ($aliases.Count -gt 0) { $updateModuleManifestParams.Add('AliasesToExport', $aliases) } if ($publicFunctions.Count -gt 0) { $updateModuleManifestParams.Add('FunctionsToExport', $publicFunctions.BaseName) } Update-ModuleManifest @updateModuleManifestParams } catch { $_ | Write-Error }
}

I use the script module as an initialization script for when the module is first imported. Looking at the code from top to bottom, I’ll briefly summarize what the script module is doing.

1. Dynamically determine the module name using $PSScriptRoot
2. Assume the .psd1 file shares the same name as the parent directory
   (the .psd1 is invoking this .psm1 script module)
3. Pull the current module manifest using Test-ModuleManifest, in order to compare and update things as necessary
4. Discover all .ps1 files in private and public directories and source them in
5. Loop over each public function and determine if any aliases are defined and export them as module members
6. Do some comparisons against the current module manifest to see if any functions or aliases have been added or removed, and if so, update the module manifest

Adding Code to the Module

ModuleName
|___ ...
|___ ...
|___Private <--- May not be referenced by user
| |___ps1 <--- Script files
| |___Verb-Noun.ps1 <--- Private function 1
| |___Verb-Noun.ps1 <--- Private function 2
| |___etc.
|
|___Public <--- May be referenced by user |___ps1 <--- Script files |___Verb-Noun.ps1 <--- Public function 1 |___Verb-Noun.ps1 <--- Public function 2 |___etc.

Adding a Private Function

ModuleName
|___ ...
|___ ...
|___Private
| |___ps1
| |___Confirm-CoffeeTime.ps1
| |___ ...
|
|___ ...

function Confirm-CoffeeTime { [CmdletBinding()] param ( [Parameter(Mandatory = $true)] [ValidateSet('Regular', 'Decaf')] [String]$CoffeeType ) begin { $currentDateTime = Get-Date $regularCoffeeHours = 4..20 $decafCoffeeHours = 0..3 + 21..23 } process { if ($CoffeeType -eq 'Regular') { if ($currentDateTime.Hour -in $regularCoffeeHours) { $result = $true } else { $result = $false } } else { if ($currentDateTime.Hour -in $decafCoffeeHours) { $result = $true } else { $result = $false } } } end { if ($result -eq $true) { return "Enjoy your cup of $CoffeeType coffee!" } else { throw "You may not drink $CoffeeType right now!" } }
}

Adding a Public Function

ModuleName
|___ ...
|___ ...
|___ ...
|
|___Public |___ps1 |___Get-Coffee.ps1 |___ ...

function Get-Coffee { [CmdletBinding()] param ( [Parameter(Mandatory = $true, Position = 0)] [ValidateSet('Regular', 'Decaf')] [String]$CoffeeType ) begin {} process { try { # Call the private function to confirm coffee time $confirmation = Confirm-CoffeeTime -CoffeeType $CoffeeType Write-Host $confirmation -ForegroundColor Green } catch { throw $_ } } end {}
}

Importing and Using the Module

What we should expect to happen:

• Import the module
• Run Get-Command -Module <module_name>
• Observe that we have only one user-executable command

Import-Module .\TestModule

Get-Command -Module TestModule

Perfect! Our public Get-Coffee function is performing as expected — calling the private Confirm-CoffeeTime function and returning stdout or stderr.

Applying this to Real Projects

As mentioned before, the examples above are contrived, and not great at demonstrating how a PowerShell module could be used for real projects. Some examples of how you might create a PowerShell module:

• API clients
• CTF tools
• Hacking tools
• Forensic tools
• Diagnostic tools
• Etc.

Some Modules I’ve Written

Wrapping Up

I want to emphasize that this post is a demonstration of the way that I create PowerShell modules. It is not the only way to create PowerShell modules.

That said, I do hope that I gave you some ideas on how to get started with creating your own modules, and how you can keep your related code organized.

Here’s a quick fix if you see the modules installed in the system, but the commands don’t work.

Step 1: Run the get module command and and copy the locations (can be 2 or more)

Get-Module -ListAvailable

$Env:PSModulePath
[Environment]::GetEnvironmentVariable("PSModulePath")

Step 3: If the location(s) in Step 1 are missing in the output of Step 2, then add the locations using the below script:

#Save the current value in the $p variable.
$p = [Environment]::GetEnvironmentVariable("PSModulePath")
#Add the new path to the $p variable. Begin with a semi-colon separator.
$p += ";C:Program Files (x86)MyCompanyModules" ## Update path here
#Add the paths in $p to the PSModulePath value.
[Environment]::SetEnvironmentVariable("PSModulePath",$p)

Step 4: Reboot the system and check if the path has been added.

To check if all paths are up-to-date and being used by PowerShell, run the below script and any missing paths will be reported in Red Colour (Green outputs are good)

# Step 1: Get all available modules and their directory paths
$modules = Get-Module -ListAvailable | Select-Object Name, ModuleBase
# Step 2: Get the list of directories in $env:PSModulePath
$modulePaths = $env:PSModulePath -split ";" # Splitting the paths
$missingPaths = @()
foreach ($module in $modules) { # Extract the parent directory path until "Modules" $moduleParentPath = Split-Path $module.ModuleBase -Parent # Ensure $moduleParentPath is not empty to avoid the error while ($moduleParentPath -and (Split-Path $moduleParentPath -Leaf) -ne 'Modules') { $moduleParentPath = Split-Path $moduleParentPath -Parent } # Check if the parent directory is present in $env:PSModulePath if ($moduleParentPath -and -not ($modulePaths -contains $moduleParentPath)) { Write-Host "$($module.Name) module directory ($($module.ModuleBase)) is missing from $env:PSModulePath." -ForegroundColor Red # Add the missing path to the list if not already present if (-not ($missingPaths -contains $moduleParentPath)) { $missingPaths += $moduleParentPath } }
}
# If there are missing paths, prompt the user to fix
if ($missingPaths.Count -gt 0) { $action = Read-Host "There are missing paths. Do you want to 'Fix' or 'Ignore'?" if ($action -eq 'Fix') { foreach ($path in $missingPaths) { $env:PSModulePath += ";$path" } Write-Host "Paths added to $env:PSModulePath for this session." -ForegroundColor Green } elseif ($action -eq 'Ignore') { Write-Host "Ignoring missing paths." -ForegroundColor Yellow } else { Write-Host "Invalid choice. Exiting without action." -ForegroundColor Yellow }
} else { Write-Host "All module paths are up to date." -ForegroundColor Green
}

And don’t forget to keep your modules updated: Remove Old PowerShell Modules (arnav.au)

Q: How do you install a PowerShell module?

A: You can install a PowerShell module using the Install-Module cmdlet. For example: Install-Module -Name <ModuleName>.

Q: What is the difference between Windows PowerShell and PowerShell Core?

A: Windows PowerShell is built on the .NET Framework and is exclusive to Windows. PowerShell Core, often simply called “PowerShell”, is built on .NET Core and is cross-platform, meaning it can run on Windows, Linux, and macOS.

Q: How can I find available modules in the PowerShell Gallery?

A: You can use the Find-Module cmdlet to search for modules in the PowerShell Gallery.

Q: What are cmdlets in PowerShell?

A: Cmdlets are lightweight commands that are used in the Windows PowerShell environment. They are specialized .NET classes.

Q: How can I import a PowerShell module that I’ve installed?

Q: How do I check if a specific module is installed?

A: You can use the Get-Module -ListAvailable -Name <ModuleName> command to check if a specific module is installed.

Q: Can I install PowerShell on operating systems other than Windows?

A: Yes, PowerShell Core is cross-platform and can be installed on Linux and macOS in addition to Windows.

Q: I’m using Windows Server 2008 R2, can I install the latest version of PowerShell?

A: Windows Server 2008 R2 originally came with Windows PowerShell 2.0. You can upgrade to newer versions, but the highest supported version for Windows Server 2008 R2 is Windows PowerShell 5.1.

Q: Is there a difference between cmdlet and command in PowerShell?

A: In PowerShell, a cmdlet is a single-function command that manipulates objects in the shell. On the other hand, a command can refer to both cmdlets and other command-line utilities available in the operating system.

Q: How do I set permissions in PowerShell for executing scripts?

A: You can set the execution policy in PowerShell using the Set-ExecutionPolicy cmdlet. For example, Set-ExecutionPolicy RemoteSigned allows you to run scripts that you’ve written and scripts from trusted publishers.

Q: What is the purpose of the -Name parameter in many PowerShell cmdlets?

A: The -Name parameter typically specifies the name of an object, like a module or service, that you want to interact with using the cmdlet.

Q: How can I verify the version of my PowerShell installation?

A: You can use the $PSVersionTable.PSVersion command in PowerShell to check the version.

Q: Is PowerShell available for non-Windows operating systems?

A: Yes, PowerShell Core is a cross-platform version that’s available for Windows, Linux, and macOS.

Q: Can I run PowerShell scripts on Windows 7 or Windows Server 2008?

A: Yes, both Windows 7 and Windows Server 2008 support Windows PowerShell. However, you might need to update to a newer version to access all features.

Q: What is the significance of the PSModulePath environment variable in PowerShell?

Q: If I encounter an error like “operable program or batch file not found”, what might be the issue?

A: Such an error often indicates that the command you’re trying to run isn’t recognized, either because it’s not installed, the spelling is incorrect, or its path isn’t included in the system’s PATH environment variable.

Q: How do I specify which user account should run a PowerShell script?

Q: What are the differences between the parameters AllUsers and CurrentUser in PowerShell?

Q: What does the repository parameter usually indicate in a PowerShell cmdlet?

A: The repository parameter typically refers to a location or source where modules, packages, or other data can be fetched. For example, the PowerShell Gallery is a default repository for many modules.

Q: How can I create a new folder using PowerShell?

A: You can use the New-Item cmdlet with the -type parameter set to “directory”. For example: New-Item -Path C:example -Name "NewFolder" -Type Directory.

Q: What is the significance of the -name parameter in PowerShell?

A: The -name parameter is used to specify the name of an item, be it a module, file, folder, or other entities in PowerShell. It helps to define or identify the target or source item for various cmdlets.

Q: How is the automation capability of PowerShell?

keywords: install the module in microsoft OS active directory want to install powershell modules