Jak zainstalować i zarządzać modułami w PowerShellu?

Cześć, witaj w kolejnym wpisie dotyczącym podstaw PowerShella. Do tej pory powinieneś zbudować już solidne fundamenty. Powoli zbliżamy się do końca tego cyklu. Przypomnę tylko szybko, że za nami takie tematy jak praca z plikami, danymi, funkcjami czy sterowanie logiką. Dziś wchodzimy na kolejny poziom i zobaczysz jak instalować i wykorzystywać moduły w PowerShellu. A zatem nie ma co zwlekać, zabieramy sie do roboty.

Spis treści

Czym właściwie jest moduł?
Przykłady praktyczne
Typowe problemy z modułami
Dobre praktyki pracy z modułami
Podsumowanie

Czym właściwie jest moduł?

Moduł to paczka zawierająca różne komponenty PowerShella. Znajdziesz tam funkcje, cmdlety, zmienne, aliasy, a nawet własne typy obiektów. Moduły pozwalają rozszerzyć możliwości PowerShella o dodatkowe polecenia, dzięki czemu środowisko staje się elastyczne i naprawdę potężne. Możesz traktować moduł jak skrzynkę z narzędziami: wszystko, co jest niezbędne do wykonania jakiegoś zadania, masz pod ręką w jednym miejscu, gotowe do użycia w dowolnym momencie. A cała magia polega na tym, że PowerShell załaduje poszczególne moduły tylko wtedy, gdy naprawdę ich potrzebujesz

PowerShell instalacja i zarządzanie modułami — Moduł to paczka zawierająca różne komponenty PowerShella (funkcje, cmdlety, zmienne, aliasy, a nawet własne typy obiektów). Moduły pozwalają rozszerzyć możliwości PowerShella.

Dlaczego warto korzystać z modułów?

Moduły w PowerShellu są jednym z kluczowych elementów wykorzystywanych w codziennej pracy. Pozwalają rozszerzać jego funkcjonalność w sposób uporządkowany, przewidywalny i skalowalny. Dzięki nim nie musi pisać wszystkiego od zera, zamiast tego korzystasz z gotowych i przetestowanych rozwiązań, które można łatwo instalować, aktualizować i ponownie wykorzystywać w różnych projektach oraz środowiskach. Poniżej trzy główne powody, dla których warto pochylić się nad modułami:

Reużywalność

Tworzysz kod raz, pakujesz w moduł i możesz używać, kiedy tylko chcesz lub udostępniasz innym.

Porządek

Moduły pomagają utrzymywać kod w czytelnej, modularnej i uporządkowanej formie.

Możliwości

Istnieją tysiące gotowych modułów: od obsługi Azure po automatyzację Active Directory.

Rodzaje modułów

W PowerShellu występuje kilka rodzajów modułów, różniących się sposobem implementacji, przeznaczeniem oraz scenariuszami użycia. Zrozumienie tych różnic pozwala świadomie wybrać odpowiedni typ modułu – zarówno przy korzystaniu z gotowych narzędzi, jak i przy tworzeniu własnych rozwiązań automatyzacyjnych.

Script modules (.psm1): zwykły kod PowerShella: funkcje, zmienne, logika i cała reszta.
Binary modules (.dll): skompilowane biblioteki .NET zawierające cmdlety.
Manifest modules (.psd1): pliki opisujące moduł: wersja, autor, zależności i zawartość.
Dynamic modules: moduły tworzone w pamięci przez bardziej zaawansowane skrypty (rzadko spotykane na początku).

💡Warto wiedzieć

W starszych wersjach PowerShella (wersja 2.0) trzeba było jawnie importować każdy moduł, przykadowo:
Import-Module -Name ActiveDirectory
Od PowerShella 3.0 działa tzw. auto-loading, czyli moduły ładują się automatycznie, gdy wywołasz ich cmdlety. Mimo to nadal zdarzają się sytuacje, w których jawne Import-Module jest potrzebne, np. gdy zależy Ci na konkretnej wersji danego modułu.

Gdzie PowerShell trzyma moduły?

Domyślnie PowerShell korzysta z zestawu lokalizacji zapisanych w zmiennej środowiskowej $env:PSModulePath. To właśnie te lokalizacje są przeszukiwane podczas automatycznego ładowania lub w momencie wywołania Import-Module. W praktyce mechanizm ten przypomina nieco działanie ścieżki systemowej w systemie Windows.

PowerShell uzyskując dostęp do konkretnych ścieżek, sprawdza katalogi po kolei i pobiera pierwszy moduł o danej nazwie, jaki znajdzie. Dlatego kolejność ścieżek ma znaczenie, zwłaszcza gdy masz różne wersje tego samego modułu. W standardowej konfiguracji najczęściej spotkasz trzy główne lokalizacje:

PS C:\Users\Admin> $env:PSmodulepath -split ';'
C:\Users\Admin\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

Moduły użytkownika (User Scope): C:\Users\<User>\Documents\WindowsPowerShell\Modules To miejsce, z którego zwykle korzystasz podczas tworzenia własnych modułów lub instalowania czegoś tylko dla swojego profilu. Do tego katalogu masz zawsze dostęp, więc nie potrzebujesz uprawnień administratora.

Moduły systemowe (All Users Scope): C:\Program Files\WindowsPowerShell\Modules Tutaj trafiają moduły instalowane globalnie, dostępne dla wszystkich użytkowników systemu. Ten katalog jest wykorzystywany przez PowerShellGet, MSI instalujące moduły, a także przez większość narzędzi Microsoftu.

Moduły wbudowane (System32): C:\Windows\System32\WindowsPowerShell\v1.0\Modules To zestaw modułów dostarczanych razem z samym systemem operacyjnym lub środowiskiem PowerShell. Nie modyfikuje się ich ręcznie. Jest to część systemu i aktualizuje się wraz z Windows.

Do przedstawionych wyżej informacji warto dodać kilka praktycznych wskazówek:

PowerShell 7 ma własne ścieżki modułów, niezależne od Windows PowerShella. Oznacza to, że moduły nie zawsze są współdzielone.

Możesz rozszerzyć ścieżki modułów dodając własne katalogi do $env:PSModulePath. Jest to przydatne np. przy pracy zespołowej lub w środowiskach serwerowych.

Opanuj PowerShell w praktyce dzięki 101 gotowym zadaniom, które zautomatyzują Twoją codzienną pracę i oszczędzą Twój czas. Sięgnij po konkretną wiedzę i wejdź na wyższy poziom administrowania systemem!

Przykłady praktyczne

Podgląd dostępnych modułów

PowerShell udostępnia kilka sposobów na sprawdzenie, jakie moduły są dostępne oraz które są aktualnie używane w bieżącej sesji. To ważne, szczególnie gdy pracujesz na środowiskach serwerowych, masz wiele wersji tego samego modułu lub rozwiązujesz problemy z autoloadingiem modułów.

Moduły aktualnie załadowane do sesji:

PS C:\Users\Admin> Get-Module

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Manifest   2.0.0.0    Hyper-V                             {Add-VMAssignableDevice, Add-VMDvdDrive, Add-VMFibreChanne...
Manifest   3.1.0.0    Microsoft.PowerShell.Utility        {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Script     2.0.0      PSReadLine                          {Get-PSReadLineKeyHandler, Get-PSReadLineOption, Remove-PS...

Co tu się dzieje?

Polecenie Get-Module pokazuje, jakie moduły są aktywnie używane w bieżącej sesji. Automatyczne ładowanie sprawia, że moduł nie pojawia się tutaj, dopóki faktycznie nie wywołasz jednego z jego cmdletów. W praktyce to szybki sposób, by sprawdzić, czy PowerShell dobrał poprawną wersję modułu lub, czy moduł w ogóle został załadowany.

Wszystkie dostępne moduły:

PS C:\Users\Admin> Get-Module -ListAvailable

    Directory: C:\Users\Admin\Documents\PowerShell\Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     2.6.0                 QRCodeGenerator                     Core,Desk {New-PSOneQRCodeGeolocation, New-PSOneQ…

    Directory: C:\program files\powershell\7\Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Manifest   7.0.0.0               CimCmdlets                          Core      {Get-CimAssociatedInstance, Get-CimClas…
Manifest   1.2.5                 Microsoft.PowerShell.Archive        Desk      {Compress-Archive, Expand-Archive}
Manifest   7.0.0.0               Microsoft.PowerShell.Diagnostics    Core      {Get-WinEvent, New-WinEvent, Get-Counte…
Manifest   7.0.0.0               Microsoft.PowerShell.Host           Core      {Start-Transcript, Stop-Transcript}
Manifest   7.0.0.0               Microsoft.PowerShell.Management     Core      {Add-Content, Clear-Content, Get-Clipbo…
Binary     1.1.1                 Microsoft.PowerShell.PSResourceGet  Core,Desk {Compress-PSResource, Find-PSResource,

Co tu się dzieje?

Polecenie Get-Module wzbogacone o parametr -ListAvailable skanuje wszystkie lokalizacje wymienione w zmiennej $env:PSModulePath i zwraca listę modułów dostępnych do zaimportowania. Jeżeli wykonasz to z poziomu PowerShell 7 zobaczysz również jego lokalizacje. Jeśli zdarzy się, że masz kilka wersji tego samego modułu – pojawią się wszystkie. To ułatwia kontrolę środowiska, bo czasem starsza wersja potrafi „przysłonić” nowszą.

Wyszukanie konkretnego modułu:

PS C:\Users\Admin> Get-Module -ListAvailable -Name ActiveDirectory

    Directory: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Manifest   1.0.1.0               ActiveDirectory                     Core,Desk {Add-ADCentralAccessPolicyMember, Add-A…

Co tu się dzieje?

Początek jak poprzednio, a dodatkowy parametr -Name pozwala skupić się na konkretnej nazwie modułu.

Wylistowanie cmdletów z danego modułu:

PS C:\Users\Admin> Get-Command -Module ActiveDirectory

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Add-ADCentralAccessPolicyMember                    1.0.1.0    ActiveDirectory
Cmdlet          Add-ADComputerServiceAccount                       1.0.1.0    ActiveDirectory
Cmdlet          Add-ADDomainControllerPasswordReplicationPolicy    1.0.1.0    ActiveDirectory
Cmdlet          Add-ADFineGrainedPasswordPolicySubject             1.0.1.0    ActiveDirectory
Cmdlet          Add-ADGroupMember                                  1.0.1.0    ActiveDirectory
Cmdlet          Add-ADPrincipalGroupMembership                     1.0.1.0    ActiveDirectory

Co tu się dzieje?

Z cmdletu Get-Command z parametrem -Module skorzystaj, jeżeli chcesz szybko sprawdzić, co właściwie daje Ci dany moduł lub jakie cmdlety i funkcje dokładnie udostępnia. Sprawdza się to świetnie przy modułach, które widzisz pierwszy raz lub przy debugowaniu, kiedy nie wiesz, które polecenie pochodzi z którego modułu.

Wyładowanie modułu z aktywnej sesji:

PS C:\Users\Admin> Get-Module

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Manifest   3.1.0.0    Microsoft.PowerShell.Management     {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Con...
Manifest   3.1.0.0    Microsoft.PowerShell.Utility        {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Manifest   1.0.0.0    NetTCPIP                            {Find-NetRoute, Get-NetCompartment, Get-NetIPAddress, Get-...
Script     2.0.0      PSReadLine                          {Get-PSReadLineKeyHandler, Get-PSReadLineOption, Remove-PS...


PS C:\Users\Admin> Remove-Module NetTCPIP
PS C:\Users\Admin> Get-Module

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Manifest   3.1.0.0    Microsoft.PowerShell.Management     {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Con...
Manifest   3.1.0.0    Microsoft.PowerShell.Utility        {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Script     2.0.0      PSReadLine                          {Get-PSReadLineKeyHandler, Get-PSReadLineOption, Remove-PS...

Co tu się dzieje?

Na początek sprawdzamy załadowane moduły za pomocą Get-Module, następnie w celu wyładowania danego modułu korzystam z Remove-Module i podaję nazwę konkretneo modułu. W tym przypadku NetTCPIP, Następnie w celu weryfikacji ponownie Get-Module.

Działanie choć z pozoru pozbawione sensu jest przydatne np. podczas testowania zmian w module lub gdy chcesz wymusić ponowne załadowanie innej wersji. Jeśli moduł ma zależności, PowerShell może odmówić w takim przypadku konieczna jest nowa sesja.

Instalacja modułów z internetu (PowerShell Gallery)

PowerShell Gallery to centralne repozytorium modułów tworzone przez Microsoft i społeczność. To tu znajdziesz narzędzia do Azure, Active Directory, obsługi chmury, CI/CD, automatyzacji serwerowej i wiele innych.

Sprawdzenie dostępnych wersji modułu:

PS C:\Users\Admin> Find-Module -Name Burnttoast

Version              Name                                Repository           Description
-------              ----                                ----------           -----------
1.1.0                BurntToast                          PSGallery            Module for creating and displaying Toast…

Instalacja modułu:

PS C:\Users\Admin> Install-Module -Name BurntToast -Verbose
VERBOSE: Using the provider 'PowerShellGet' for searching packages.
VERBOSE: The -Repository parameter was not specified. PowerShellGet will use all of the registered repositories.
VERBOSE: Getting the provider object for the PackageManagement Provider 'NuGet'.
VERBOSE: The specified Location is 'https://www.powershellgallery.com/api/v2' and PackageManagementProvider is 'NuGet'.
VERBOSE: Searching repository 'https://www.powershellgallery.com/api/v2/FindPackagesById()?id='BurntToast'' for ''.
VERBOSE: Total package yield:'1' for the specified package 'BurntToast'.
VERBOSE: Performing the operation "Install-Module" on target "Version '1.1.0' of module 'BurntToast'".
VERBOSE: The installation scope is specified to be 'CurrentUser'.
VERBOSE: The specified module will be installed in 'C:\Users\Admin\Documents\PowerShell\Modules'.
VERBOSE: The specified Location is 'NuGet' and PackageManagementProvider is 'NuGet'.
VERBOSE: Downloading module 'BurntToast' with version '1.1.0' from the repository 'https://www.powershellgallery.com/api/v2'.
VERBOSE: Searching repository 'https://www.powershellgallery.com/api/v2/FindPackagesById()?id='BurntToast'' for ''.
VERBOSE: InstallPackage' - name='BurntToast', version='1.1.0',destination='C:\Users\Admin\AppData\Local\Temp\1205399831'
VERBOSE: DownloadPackage' - name='BurntToast', version='1.1.0',destination='C:\Users\Admin\AppData\Local\Temp\1205399831\BurntToast.1.1.0\BurntToast.1.1.0.nupkg', uri='https://www.powershellgallery.com/api/v2/package/BurntToast/1.1.0'
VERBOSE: Downloading 'https://www.powershellgallery.com/api/v2/package/BurntToast/1.1.0'.
VERBOSE: Completed downloading 'https://www.powershellgallery.com/api/v2/package/BurntToast/1.1.0'.
VERBOSE: Completed downloading 'BurntToast'.
VERBOSE: InstallPackageLocal' - name='BurntToast', version='1.1.0',destination='C:\Users\Admin\AppData\Local\Temp\1205399831'
VERBOSE: Validating the 'BurntToast' module contents under 'C:\Users\Admin\AppData\Local\Temp\1205399831\BurntToast.1.1.0' path.
VERBOSE: Test-ModuleManifest successfully validated the module manifest file 'C:\Users\Admin\AppData\Local\Temp\1205399831\BurntToast.1.1.0'.
VERBOSE: Validating the authenticode signature and publisher of the catalog file or module manifest file of the module 'BurntToast'.
VERBOSE: Catalog file 'BurntToast.cat' is not found in the contents of the module 'BurntToast' being installed.
VERBOSE: Checking for possible command collisions for the module 'BurntToast' commands.
VERBOSE: Module 'BurntToast' was installed successfully to path 'C:\Users\Admin\Documents\PowerShell\Modules\BurntToast\1.1.0'.

Co tu się dzieje?

Cmdlet Install-Module odpowiada za instalacje danego modułu, dzięki parametrowi -Verbose możemy zaobserować jego działanie w następujących etapach:

Odpytanie repozytoriów – PowerShellGet pobiera z PSGallery (lub innych repozytoriów) metadane modułu: wersje, zależności, wymagania, itd.
Analiza zależności – PowerShell tworzy graf zależności i dobiera kompatybilne wersje wszystkich wymaganych modułów.
Pobranie pakietów – Do lokalnego cache pobierane są pliki .nupkg dla modułu i jego zależności.
Weryfikacja bezpieczeństwa – Sprawdzane są hashe, źródło repozytorium i ewentualne podpisy.
Instalacja plików – Pakiety są rozpakowywane do katalogu modułów (CurrentUser lub AllUsers) w strukturze wersjonowanej.
Rejestracja w PowerShellu – Moduł zostaje zarejestrowany w systemie i jest widoczny dla Get-Module -ListAvailable.

To dokładnie ten sam model, który stosują profesjonalne menedżery pakietów w świecie Linuxa, chmury i DevOps.

Sprawdzenie instalacji (dostępnych wersji):

PS C:\Windows\System32> Get-Module -ListAvailable

    Directory: C:\Users\Admin\Documents\PowerShell\Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     5.3.1                 Az.Accounts                         Core,Desk {Disable-AzDataCollection, Disable-AzCo…
Script     3.0.0                 Az.Advisor                          Core,Desk {Disable-AzAdvisorRecommendation, Enabl…
Script     7.0.0                 Az.Aks                              Core,Desk {Disable-AzAksAddOn, Enable-AzAksAddOn,…
Script     1.2.0                 Az.AnalysisServices                 Core,Desk {Add-AzAnalysisServicesAccount, Export-…
Script     4.1.0                 Az.ApiManagement                    Core,Desk {Add-AzApiManagementApiToGateway, Add-A…
Script     2.0.1                 Az.App                              Core,Desk {Disable-AzContainerAppRevision, Enable…
Script     2.0.1                 Az.AppConfiguration                 Core,Desk {Clear-AzAppConfigurationDeletedStore, …
Script     3.0.0                 Az.ApplicationInsights              Core,Desk {Get-AzApplicationInsights, Get-AzAppli…
Script     2.0.0                 Az.ArcResourceBridge                Core,Desk {Get-AzArcResourceBridge, Get-AzArcReso…
Script     1.0.0                 Az.ArizeAI                          Core,Desk {Get-AzArizeAIOrganization, New-AzArize…
Script     3.0.0                 Az.Attestation                      Core,Desk {Add-AzAttestationPolicySigner, Get-AzA…
Script     2.0.0                 Az.Automanage                       Core,Desk {Get-AzAutomanageBestPractice, Get-AzAu…
Script     1.11.2                Az.Automation                       Core,Desk {Export-AzAutomationDscConfiguration, E…
Script     4.0.0                 Az.Batch                            Core,Desk {Disable-AzBatchAutoScale, Disable-AzBa…
Script     2.2.0                 Az.Billing                          Core,Desk {Get-AzBillingAccount, Get-AzBillingInv…
Script     6.0.0                 Az.Cdn                              Core,Desk {Add-AzCdnEdgeActionAttachment, Clear-A…
Script     2.1.1                 Az.CloudService                     Core,Desk {Get-AzCloudService, Get-AzCloudService…
Script     1.16.0                Az.CognitiveServices                Core,Desk {Add-AzCognitiveServicesAccountNetworkR…
Script     1.1.0                 BurntToast                          Desk      {Get-BTHeader, Get-BTHistory, New-BTAct…
Script     2.6.0                 QRCodeGenerator                     Core,Desk {New-PSOneQRCodeGeolocation, New-PSOneQ…

Co tu się dzieje?

Cmdlet Get-Module -ListAvailable przeszukuje wszystkie ścieżki zdefiniowane w zmiennej $PSModulePath i wyświetla dostępne moduły.

Podobny efekt uzyskamy korzystając z Get-InstalledModule. W tym wypadku jednak skupiamy się typowo na modułach zainstalowanych przez PowerShellGet (z wykorzystaniem cmdletów Install-Module oraz Update-Module).

PS C:\Users\Admin> Get-InstalledModule

Version              Name                                Repository           Description
-------              ----                                ----------           -----------
5.3.1                Az.Accounts                         PSGallery            Microsoft Azure PowerShell - Accounts cr…
3.0.0                Az.Advisor                          PSGallery            Microsoft Azure PowerShell: Advisor cmdl…
7.0.0                Az.Aks                              PSGallery            Microsoft Azure PowerShell - Azure manag…
1.2.0                Az.AnalysisServices                 PSGallery            Microsoft Azure PowerShell - Analysis Se…
4.1.0                Az.ApiManagement                    PSGallery            Microsoft Azure PowerShell - Api Managem…
2.0.1                Az.App                              PSGallery            Microsoft Azure PowerShell: App cmdlets
2.0.1                Az.AppConfiguration                 PSGallery            Microsoft Azure PowerShell: AppConfigura…
3.0.0                Az.ApplicationInsights              PSGallery            Microsoft Azure PowerShell: ApplicationI…
2.0.0                Az.ArcResourceBridge                PSGallery            Microsoft Azure PowerShell: ArcResourceB…
1.0.0                Az.ArizeAI                          PSGallery            Microsoft Azure PowerShell: ArizeAI cmdl…
3.0.0                Az.Attestation                      PSGallery            Microsoft Azure PowerShell - Attestation…
2.0.0                Az.Automanage                       PSGallery            Microsoft Azure PowerShell: Automanage c…
1.11.2               Az.Automation                       PSGallery            Microsoft Azure PowerShell - Automation …
4.0.0                Az.Batch                            PSGallery            Microsoft Azure PowerShell - Batch servi…
2.2.0                Az.Billing                          PSGallery            Microsoft Azure PowerShell - Billing ser…
6.0.0                Az.Cdn                              PSGallery            Microsoft Azure PowerShell: Cdn cmdlets
2.1.1                Az.CloudService                     PSGallery            Microsoft Azure PowerShell: CloudService…
1.16.0               Az.CognitiveServices                PSGallery            Microsoft Azure PowerShell - Cognitive S…
1.1.0                BurntToast                          PSGallery            Module for creating and displaying Toast…
2.6.0                QRCodeGenerator                     PSGallery            creates QR codes offline

💡Warto wiedzieć

Przy pierwszym uruchomieniu PowerShell zapyta o zaufanie do repozytorium — wystarczy zaakceptować lub ewentualnie dodać PSGallery jako zaufane repozytorium (Set-PSRepository -Name PSGallery -InstallationPolicy Trusted). Proszę jednak o zachowanie szczególnej ostrożności.

Moduły instalowane „globalnie” wymagają PowerShell uruchomionego jako Administrator.

Jeśli pracujesz za proxy, może być konieczne skonfigurowanie Net.WebRequest lub zmiennych środowiskowych.

Przy instalacji konkretnej wersji wystarczy dodać parametr -RequiredVersion <wersja>

Aktualizacja i usuwanie modułów

Aktualizacja modułu do najnowszej wersji:

PS C:\Users\Admin> Update-Module -Name BurntToast -Verbose
VERBOSE: Checking for updates for module 'BurntToast'.
VERBOSE: Suppressed Verbose Repository details, Name = 'PSGallery', Location =
'https://www.powershellgallery.com/api/v2'; IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Repository details, Name = 'PSGallery', Location = 'https://www.powershellgallery.com/api/v2'; IsTrusted =
'True'; IsRegistered = 'True'.
VERBOSE: Using the provider 'PowerShellGet' for searching packages.
VERBOSE: Using the specified source names : 'PSGallery'.
VERBOSE: Getting the provider object for the PackageManagement Provider 'NuGet'.
VERBOSE: The specified Location is 'https://www.powershellgallery.com/api/v2' and PackageManagementProvider is 'NuGet'.
VERBOSE: Searching repository 'https://www.powershellgallery.com/api/v2/FindPackagesById()?id='BurntToast'' for ''.
VERBOSE: Total package yield:'1' for the specified package 'BurntToast'.
VERBOSE: Performing the operation "Update-Module" on target "Version '0.8.5' of module 'BurntToast', updating to
version '1.1.0'".
VERBOSE: The installation scope is specified to be 'CurrentUser'.
VERBOSE: The specified module will be installed in 'C:\Users\Admin\Documents\WindowsPowerShell\Modules'.
VERBOSE: An update for the module 'BurntToast' was found with version '1.1.0'.
VERBOSE: The specified Location is 'NuGet' and PackageManagementProvider is 'NuGet'.
VERBOSE: Downloading module 'BurntToast' with version '1.1.0' from the repository
'https://www.powershellgallery.com/api/v2'.
VERBOSE: Searching repository 'https://www.powershellgallery.com/api/v2/FindPackagesById()?id='BurntToast'' for ''.
VERBOSE: InstallPackage' - name='BurntToast', version='1.1.0',destination='C:\Users\Admin\AppData\Local\Temp\434968056'
VERBOSE: DownloadPackage' - name='BurntToast',
version='1.1.0',destination='C:\Users\Admin\AppData\Local\Temp\434968056\BurntToast.1.1.0\BurntToast.1.1.0.nupkg',
uri='https://www.powershellgallery.com/api/v2/package/BurntToast/1.1.0'
VERBOSE: Downloading 'https://www.powershellgallery.com/api/v2/package/BurntToast/1.1.0'.
VERBOSE: Completed downloading 'https://www.powershellgallery.com/api/v2/package/BurntToast/1.1.0'.
VERBOSE: Completed downloading 'BurntToast'.
VERBOSE: Hash for package 'BurntToast' does not match hash provided from the server.
VERBOSE: InstallPackageLocal' - name='BurntToast',
version='1.1.0',destination='C:\Users\Admin\AppData\Local\Temp\434968056'
VERBOSE: Validating the 'BurntToast' module contents under
'C:\Users\Admin\AppData\Local\Temp\434968056\BurntToast.1.1.0' path.
VERBOSE: Test-ModuleManifest successfully validated the module manifest file
'C:\Users\Admin\AppData\Local\Temp\434968056\BurntToast.1.1.0'.
VERBOSE: Validating the authenticode signature and publisher of the catalog file or module manifest file of the module
'BurntToast'.
VERBOSE: Catalog file 'BurntToast.cat' is not found in the contents of the module 'BurntToast' being installed.
VERBOSE: For publisher validation, current module 'BurntToast' with version '1.1.0' with publisher name '' from root
certificate authority ''. Is this module signed by Microsoft: 'False'.
VERBOSE: For publisher validation, using the previously-installed module 'BurntToast' with version '0.8.5' under
'C:\Users\Admin\Documents\WindowsPowerShell\Modules\BurntToast\0.8.5' with publisher name '' from root certificate
authority ''. Is this module signed by Microsoft: 'False'.
VERBOSE: Checking for possible command collisions for the module 'BurntToast' commands.
VERBOSE: Module 'BurntToast' was installed successfully to path
'C:\Users\Admin\Documents\WindowsPowerShell\Modules\BurntToast\1.1.0'.

Co tu się dzieje?

CmdletUpdate-Module korzysta z tej samej infrastruktury co Install-Module, ale działa na już zainstalowanych pakietach. W praktyce wykonuje następujące kroki:

Skanowanie lokalnych modułów – PowerShell dokonuje sprawdzenia, jakie moduły są zainstalowane w systemie oraz jakie ich wersje znajdują się w katalogach modułów.
Porównanie z repozytoriami – Dla każdego modułu PowerShellGet pobiera z PSGallery metadane i sprawdza, czy istnieje nowsza wersja.
Ocena kompatybilności – Sprawdzane są wymagania nowej wersji (PowerShell, .NET, OS) oraz zgodność z już zainstalowanymi zależnościami.
Rozwiązanie zależności – Jeżeli nowa wersja wymaga innych lub nowszych modułów pomocniczych, PowerShell buduje nowy graf zależności.
Pobranie nowych pakietów – Do cache pobierane są nowe pliki .nupkg dla modułu i jego zależności.
Weryfikacja bezpieczeństwa – Sprawdzane są hashe, źródło repozytorium i podpisy pakietów.
Instalacja nowej wersji obok starej – Nowa wersja trafia do katalogu modułów w osobnym folderze wersji. Stara wersja nie jest usuwana automatycznie.
Aktualizacja rejestru modułów – PowerShell rejestruje nową wersję jako najnowszą dostępną.
Załadowanie przy kolejnym imporcie – Przy kolejnym wywołaniu Import-Module lub pierwszym użyciu danego modułu, PowerShell wybierze najwyższą dostępną wersję.

To zachowanie jest kluczowe w środowiskach produkcyjnych, gdyż pozwala na aktualizacje bez ryzyka natychmiastowego złamania istniejących skryptów. Dodatkowo warto wspomnieć, że PowerShell pobierze nowszą wersję, ale NIE usunie starszych, te nadal będą dostępne. zobacz przykład poniżej.

PS C:\Users\Admin> Get-Module -ListAvailable | ? name -like 'BurntToast'


    Directory: C:\Users\Admin\Documents\WindowsPowerShell\Modules


ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     1.1.0      BurntToast                          {Get-BTHeader, Get-BTHistory, New-BTAction, New-BTAudio...}
Script     0.8.5      BurntToast                          {Get-BTHistory, New-BTAction, New-BTAppId, New-BTAudio...}

Dwie wersje tego samego modułu. To całkowicie normalne zachowanie, ale czasem warto posprzątać ręcznie, szczególnie jeżeli lubisz porządek zależy Ci na uniknięciu konfliktów.

Usuwanie modułu z dysku:

W praktyce administratorzy usuwają moduły w przypadku gdy przestały być już potrzebne lub dlatego, że zagrażają naszemu środowisku (konflikty wersji, błędy, wymagania bezpieczeństwa, audyty itp.). Co tego celu służy polecenie Uninstall-Module, jak na przykładzie poniżej.

PS C:\Users\Admin> Uninstall-Module -Name BurntToast -Verbose
VERBOSE: Performing the operation "Uninstall-Module" on target "Version '1.1.0' of module 'BurntToast'".
VERBOSE: Successfully uninstalled the module 'BurntToast' from module base
'C:\Users\Admin\Documents\WindowsPowerShell\Modules\BurntToast\1.1.0'.

Co tu się dzieje?

Cmdlet Uninstall-Module odpowiedzialny jest za usunięcie danego modułu. Jeżeli masz wiele wersji tego modułu, PowerShell usunie tylko najnowszą. Możesz oczywiście wskazać usunięcie konkretnej wersji:

PS C:\Users\Admin> Uninstall-Module -Name BurntToast -RequiredVersion 0.8.5
VERBOSE: Performing the operation "Uninstall-Module" on target "Version '0.8.5' of module 'BurntToast'".
VERBOSE: Successfully uninstalled the module 'BurntToast' from module base
'C:\Users\Admin\Documents\WindowsPowerShell\Modules\BurntToast\0.8.5'.

Typowe problemy z modułami

Praca z modułami w PowerShellu jest prosta o ile Twoje środowisko jest uporządkowane. W praktyce jednak bardzo często pojawiają się konflikty wersji, problemy z ładowaniem lub błędnie ustawione ścieżki. Poniżej znajdziesz kilka najczęstrzych sytuacji z życia oraz sposoby ich rozwiązania.

Moduł jest zainstalowany, ale PowerShell go nie widzi

Zwykle przyczyna leży w tym, że moduł znajduje się w katalogu, który nie jest uwzględniony w zmiennej $env:PSModulePath. Co należy zrobić? Przede wszystkim sprawdź dostępne ścieżki:

$env:PSModulePath -split ';'

Następnie w zależności od potrzeb przenieś moduł do:

katalogu użytkownika: C:\Users\<User>\Documents\WindowsPowerShell\Modules
lub do katalogu globalnego: C:\Program Files\WindowsPowerShell\Modules
ewentualnie dodaj własną ścieżkę: $env:PSModulePath += ";C:\MójModuł"

PowerShell ładuje nie tę wersję modułu

Gdy masz kilka wersji tego samego modułu, PowerShell załaduje tę, która znajduje się najwyżej na liście w zmiennej $PSModulePath. Aby rozwiązać ten problem, sprawdź wszystkie dostępne wersje:

Get-Module -ListAvailable -Name <TwójModuł>

i załaduj konkretną wersję:

Import-Module -Name <TwójModuł> -RequiredVersion <TwojaWersja>

W przypadku zależności od konkretnej wersji w skrypcie dopisz ją jawnie. W ten sposób unikniesz niespodzianek i problemów w środowisku produkcyjnym.

Po aktualizacji modułu stara wersja nadal jest ładowana

To dość częsty problem, szczególnie przy modułach instalowanych globalnie. Po Update-Module nowe pliki trafiają do katalogu użytkownika, ale stary moduł w katalogu systemowym może być ładowany w pierwszej kolejności, bo znajduje się wyżej na liście ścieżek. W tym wypadku sprawdź, z jakiego miejsca załadował się moduł:

(Get-Module -Name &lt;TwójModuŁ>).Path

Następnie:

usuń starą wersję:

Uninstall-Module -Name &lt;TwójModuł> -RequiredVersion &lt;wersja>

lub przenieś / usuń katalog ręcznie (jeśli instalacja odbyła się z plików MSI).

Moduł jest załadowany i nie da się go nadpisać albo przeładować

Podczas pracy nad własnym modułem .psm1 czasai spotkasz się z blokadą plików. Dzieje się tak ponieważ PowerShell ładuje moduł do pamięci, a pliki pozostają zablokowane do końca sesji.

Rozwiązania:

wyładuj moduł:

Remove-Module -Name MyTools

jeżeli to nie wystarczy (bo moduł ma zależności), uruchom nową sesję, np.: pwsh lub powershell.exe
możesz też użyć:

Import-Module .\\MyTools.psm1 -Force

Force nadpisze definicje funkcji w pamięci, ale nie przeładuje pliku z dysku, jeśli mechanika ładowania go blokuje.

Błąd instalacji z PowerShell Gallery — brak uprawnień

Czasami przy próbie instalacji modułu z zewnętrzego repozytorium pojawia się błąd:

Access to the path is denied.

Powód: instalacja wykonywana jest do katalogu globalnego, a sesja nie ma uprawnień administratora.

Rozwiązania:

uruchom PowerShell jako Administrator
albo instaluj lokalnie:

Install-Module -Name Az -Scope CurrentUser

Brak modułu w PowerShell Core (pwsh), mimo że działa w Windows PowerShell

Oba środowiska mają inne lokalizacje modułów, a niektóre moduły (np. ActiveDirectory) nie są kompatybilne z Core.

Sprawdź dostępne ścieżki:

$env:PSModulePath -split ';'

Jeśli moduł działa tylko w Windows PowerShell:

uruchom powershell.exe, nie pwsh
sprawdź, czy istnieje wersja kompatybilna (np. AzureAD → Microsoft.Graph)

Auto-loading nie działa

Może się zdarzyć, że chociaż od PowerShella v3+ moduły powinny ładować się automatycznie, to w praktyce nie zawsze tak to działa. Wtedy sprawdź czy:

moduł zawiera poprawny plik manifestu,
nazwy funkcji są zgodne ze schematem autoloadingu,
moduł znajduje się w ścieżkach PSModulePath,
nazwa funkcji z modułu nie koliduje z inną funkcją.

Dodatkowo można sprawdzić wartość zmiennej: $PSModuleAutoloadingPreference. Powinno zwracać: All, ale pewnie wartość nie będzie ustawiona co jest równoważne. W przypadku tej zmiennej możesz ustawić wartości:

ModuleQualified: Moduły ładują się automatycznie tylko wtedy, gdy użyjesz pełnej nazwy komendy z prefiksem (np. NetTCPIP\Get-NetTCPConnection).

None: Automatyczne ładowanie jest całkowicie wyłączone.

Konflikt nazw funkcji lub cmdletów

Czasami może się zdarzyć, że dwa moduły posiadają tę samą nazwę funkcji. Dla naszego przykładu niech będzie to Get-Info. W tym przypadku, przy wywołaniu tej funkcji nastąpi konflikt, PowerShell nie będzie wiedział konkretnie który moduł powinien załadować i zwykle załaduje pierwszy z listy, co nie zawsze było intencją administratora. Aby zidentyfikować ten problem w pierwszej kolejności sprawdź mapowanie poleceń:

Get-Command Get-Info | Select-Object Name, ModuleName, Source

Jeżeli rzeczywiście występuje konflikt to masz kilka opcji do wyboru:

wywołuj polecenie kwalifikowane:

ModuleX\Get-Info

wymuszaj import konkretnego modułu:

Import-Module -Name ModuleX -Prefix X

Potem polecenia będą wyglądać np. tak:

Get-XInfo

generalnie dbaj o unikalność identyfikatorów funkcji i poleceń.

Dobre praktyki pracy z modułami

Zarządzanie modułami stanowi fundament profesjonalnej automatyzacji i pracy z PowerShellem. Poniżej zebrałem kilka zasad, których stosowanie pozwoli Ci uniknąć błędów i ułatwi współpracę w zespole:

Weryfikuj źródła i certyfikaty: Instaluj moduły wyłącznie z zaufanych repozytoriów, takich jak oficjalne repo PowerShell Gallery. Przed instalacją warto sprawdzić liczbę pobrań, oceny oraz to, czy moduł jest podpisany cyfrowo, co gwarantuje, że kod nie został zmodyfikowany przez osoby trzecie.
Automatyzacja aktualizacji i audyt: Regularnie sprawdzaj dostępność nowych wersji poleceniem Update-Module. Nowe wydania to nie tylko funkcje, ale przede wszystkim krytyczne łatki bezpieczeństwa i poprawki wydajności, które mogą uchronić Twoje skrypty przed awarią. Dodatkowo systemetycznie pozbywaj się starszych wersji, aby nie potrzebnie nie zaśmiecać dysku.
Kontrola wersji i środowiska: W krytycznych skryptach czy automatyzacjach zamiast polegać na automatycznym ładowaniu, używaj Import-Module -RequiredVersion X.X.X. Dzięki temu masz pewność, że Twóje polecenia zadziałąją dokładnie tak samo na każdym serwerze, unikając konfliktów wynikających z różnic w wersjach modułów.
Modularność kodu (Pliki .psm1): Gdy Twój zbiór funkcji rośnie, przenieś je do modułu skryptowego (.psm1). Pozwala to na oddzielenie logiki biznesowej od narzędzi, ułatwia testowanie jednostkowe i sprawia, że Twój kod staje się wielokrotnego użytku w wielu różnych projektach.
Używaj manifestów (.psd1): Każdy profesjonalny moduł powinien posiadać manifest. Pozwala on zdefiniować metadane, wymagane wersje PowerShell oraz precyzyjnie określić, które funkcje mają być widoczne dla użytkownika końcowego (eksportowanie), co przyspiesza ładowanie sesji.

Podsumowanie

Moduły są jednym z kluczowych elementów, które sprawiają, że PowerShell jest tak rozbudowany i wszechstronny. Pozwalają w prosty sposób rozszerzyć możliwości środowiska o nowe polecenia, funkcje, klasy i dostawców, bez konieczności pisania wszystkiego od zera. Dzięki nim kod staje się bardziej uporządkowany, czytelny i łatwiejszy w utrzymaniu, a administrator może logicznie podzielić funkcjonalności według obszarów odpowiedzialności, takich jak Active Directory, Azure, Exchange czy bezpieczeństwo.

Dodatkowo moduły wspierają ponowne wykorzystanie kodu oraz standaryzację pracy w zespołach IT. Raz przygotowany lub zainstalowany moduł może być używany na wielu systemach i przez wielu administratorów w identyczny sposób. Ogromnym atutem PowerShella jest również dostęp do rozbudowanej bazy gotowych modułów publikowanych przez społeczność i producentów, m.in. w PowerShell Gallery, co znacząco przyspiesza automatyzację codziennych zadań i wdrażanie sprawdzonych rozwiązań w środowiskach produkcyjnych.

Dla chętnych:

Eksploracja lokalna: Użyj polecenia Get-Module -ListAvailable. Sprawdź, ile modułów masz obecnie zainstalowanych w systemie i odszukaj na liście ścieżkę do folderu, w którym znajduje się moduł Microsoft.PowerShell.Management.
Bezpieczne wyszukiwanie: Znajdź w oficjalnym repozytorium PowerShell Gallery moduł o nazwie SqlServer. Wyświetl informacje o nim za pomocą Find-Module, ale nie instaluj go – sprawdź jedynie w opisie, jaką ma obecnie wersję i kto jest jego autorem.

To wszystko na dziś!

Jeśli masz ciekawe spostrzeżenia lub doświadczenia w tym temacie – koniecznie podziel się nimi w komentarzach.
A jeśli moje materiały są dla Ciebie pomocne, możesz postawić mi wirtualną kawę.

Dzięki za wsparcie!

Adam Pietrzak

Administrator | Trener i autor szkoleń | Entuzjasta PowerShella

Administrator systemów i sieci wsparcia działań wojskowych z ponad 10-letnim doświadczeniem. Praktyk w dziedzinie zarządzania Active Directory, bezpieczeństwa systemu Windows oraz automatyzacji zadań (PowerShell). Trener i twórca materiałów edukacyjnych (szkolenia, warsztaty, artykuły, podręczniki). Pasjonat dzielenia się wiedzą i wspierania początkujących administratorów IT. Prywatnie – amator aktywnego wypoczynku i rodzinnych podróży.

PowerShell - 10 sposobów na optymalizację codziennej pracy

Podziel się

Jak zainstalować i zarządzać modułami w PowerShellu?

Czym właściwie jest moduł?

Dlaczego warto korzystać z modułów?

Reużywalność

Porządek

Możliwości

Rodzaje modułów

💡Warto wiedzieć

Gdzie PowerShell trzyma moduły?

Przykłady praktyczne

Podgląd dostępnych modułów

Instalacja modułów z internetu (PowerShell Gallery)

Aktualizacja i usuwanie modułów

Typowe problemy z modułami

Moduł jest zainstalowany, ale PowerShell go nie widzi

PowerShell ładuje nie tę wersję modułu

Po aktualizacji modułu stara wersja nadal jest ładowana

Moduł jest załadowany i nie da się go nadpisać albo przeładować

Błąd instalacji z PowerShell Gallery — brak uprawnień

Brak modułu w PowerShell Core (pwsh), mimo że działa w Windows PowerShell

Auto-loading nie działa

Konflikt nazw funkcji lub cmdletów

Dobre praktyki pracy z modułami

Podsumowanie

Dla chętnych:

Adam Pietrzak

Dodaj komentarz Anuluj pisanie odpowiedzi