Export (0) Print
Expand All

Get-Module

Updated: May 8, 2014

Applies To: Windows PowerShell 4.0

Get-Module

Gets the modules that have been imported or that can be imported into the current session.

Aliases

The following abbreviations are aliases for this cmdlet:

  • gmo

Syntax

Parameter Set: Loaded
Get-Module [[-FullyQualifiedName] <String[]> ] [[-Name] <String[]> ] [-All] [ <CommonParameters>]

Parameter Set: Available
Get-Module [[-FullyQualifiedName] <String[]> ] [[-Name] <String[]> ] -ListAvailable [-All] [-Refresh] [ <CommonParameters>]

Parameter Set: CimSession
Get-Module [[-Name] <String[]> ] -CimSession <CimSession> [-CimNamespace <String> ] [-CimResourceUri <Uri> ] [-ListAvailable] [-Refresh] [ <CommonParameters>]

Parameter Set: PsSession
Get-Module [[-FullyQualifiedName] <String[]> ] [[-Name] <String[]> ] -PSSession <PSSession> [-ListAvailable] [-Refresh] [ <CommonParameters>]




Detailed Description

The Get-Module cmdlet gets the Windows PowerShell modules that have been imported, or that can be imported, into a Windows PowerShell session. The module object that Get-Module returns contains valuable information about the module. You can also pipe the module objects to other cmdlets, such as the Import-Module and Remove-Module cmdlets.

Without parameters, Get-Module gets modules that have been imported into the current session. To get all installed modules, use the ListAvailable parameter.

Get-Module gets modules, but it does not import them. Beginning in Windows PowerShell 3.0, modules are automatically imported when you use a command in the module, but a Get-Module command does not trigger an automatic import. You can also import the modules into your session by using the Import-Module cmdlet.

Beginning in Windows PowerShell 3.0, you can get (and then, import) modules from remote sessions into the local session. This strategy uses the Implicit Remoting feature of Windows PowerShell and is equivalent to using the Import-PSSession cmdlet. When you use commands in modules imported from another session, the commands run implicitly in the remote session, allowing you to manage the remote computer from the local session.

Also, beginning in Windows PowerShell 3.0, you can use Get-Module and Import-Module to get and import Common Information Model (CIM) modules, in which the cmdlets are defined in Cmdlet Definition XML (CDXML) files. This feature allows you to use cmdlets that are implemented in non-managed code assemblies, such as those written in C++.

With these new features, the Get-Module and Import-Module cmdlets become primary tools for managing heterogeneous enterprises that include Windows computers and computers that are running other operating systems.

To manage remote Windows computers that have Windows PowerShell and Windows PowerShell remoting enabled, create a PSSession on the remote computer and then use the PSSession parameter of Get-Module to get the Windows PowerShell modules in the PSSession. When you import the modules, and then use the imported commands in the current session, the commands run implicitly in the PSSession on the remote computer. You can use this strategy to manage the remote computer.

You can use a similar strategy to manage computers that do not have Windows PowerShell remoting enabled, including computers that are not running a Windows operating system, and Windows computers that have Windows PowerShell, but do not have Windows PowerShell remoting enabled.

Begin by creating a "CIM session" on the remote computer; a connection to Windows Management Instrumentation (WMI) on the remote computer. Then use the CIMSession parameter of Get-Module to get CIM modules from the CIM session. When you import a CIM module (by using the Import-Module cmdlet) and then run the imported commands, the commands run implicitly on the remote computer. You can use this WMI and CIM strategy to manage the remote computer.

Parameters

-All

Gets all modules in each module folder, including nested modules, manifest (.psd1) files, script module (.psm1) files, and binary module (.dll) files. Without the All parameter, Get-Module gets only the default module in each module folder.


Aliases

none

Required?

false

Position?

named

Default Value

False

Accept Pipeline Input?

false

Accept Wildcard Characters?

false

-CimNamespace<String>

Specifies the namespace of an alternate CIM provider that exposes CIM modules. The default value is the namespace of the Module Discovery WMI provider.

Use this parameter to get CIM modules from computers and devices that are not running a Windows operating system.

This parameter is introduced in Windows PowerShell 3.0.


Aliases

none

Required?

false

Position?

named

Default Value

None

Accept Pipeline Input?

false

Accept Wildcard Characters?

false

-CimResourceUri<Uri>

Specifies an alternate location for CIM modules. The default value is the resource URI of the Module Discovery WMI provider on the remote computer.

Use this parameter to get CIM modules from computers and devices that are not running a Windows operating system.

This parameter is introduced in Windows PowerShell 3.0.


Aliases

none

Required?

false

Position?

named

Default Value

None

Accept Pipeline Input?

false

Accept Wildcard Characters?

false

-ListAvailable

Gets all installed modules. Get-Module gets modules in paths listed in the PSModulePath environment variable. Without this parameter, Get-Module gets only the modules that are both listed in the PSModulePath environment variable, and that are loaded in the current session. ListAvailable does not return information about modules that are not found in the PSModulePath environment variable, even if those modules are loaded in the current session.


Aliases

none

Required?

true

Position?

named

Default Value

none

Accept Pipeline Input?

false

Accept Wildcard Characters?

false

-FullyQualifiedName<String[]>

Gets modules with names that are specified in the form of ModuleSpecification objects (described by the Remarks section of ModuleSpecification Constructor (Hashtable) on MSDN). For example, the FullyQualifiedName parameter accepts a module name that is specified in the format @{ModuleName = "modulename"; ModuleVersion = "version_number"} or @{ModuleName = "modulename"; ModuleVersion = "version_number"; Guid = "GUID"}. ModuleName and ModuleVersion are required, but Guid is optional.

You cannot specify the FullyQualifiedName parameter in the same command as a Name parameter; the two parameters are mutually exclusive.


Aliases

none

Required?

false

Position?

1

Default Value

All imported or available modules.

Accept Pipeline Input?

true (ByValue)

Accept Wildcard Characters?

true

-Name<String[]>

Gets only modules with the specified names or name patterns. Wildcards are permitted. You can also pipe the names to Get-Module. You cannot specify the FullyQualifiedName parameter in the same command as a Name parameter; the two parameters are mutually exclusive. The Name parameter cannot accept a module GUID as a value; to return modules by specifying a GUID, use the FullyQualifiedName parameter instead of the Name parameter.


Aliases

none

Required?

false

Position?

1

Default Value

All imported or available modules.

Accept Pipeline Input?

true (ByValue)

Accept Wildcard Characters?

true

-CimSession<CimSession>

Specifies a CIM session on the remote computer. Enter a variable that contains the CIM session or a command that gets the CIM session, such as a Get-CIMSession command.

Get-Module uses the CIM session connection to get modules from the remote computer. When you import the module (by using the Import-Module cmdlet) and use the commands from the imported module in the current session, the commands actually run on the remote computer.

You can use this parameter to get modules from computers and devices that are not running a Windows operating system, and Windows computers that have Windows PowerShell, but do not have Windows PowerShell remoting enabled.

The CimSession parameter gets all modules in the CIMSession. However, you can import only CIM-based and Cmdlet Definition XML (CDXML)-based modules.


Aliases

none

Required?

true

Position?

named

Default Value

none

Accept Pipeline Input?

false

Accept Wildcard Characters?

false

-PSSession<PSSession>

Gets the modules in the specified user-managed Windows PowerShell session (PSSession). Enter a variable that contains the session, a command that gets the session, such as a Get-PSSession command, or a command that creates the session, such as a New-PSSession command.

When the session is connected to a remote computer, the ListAvailable parameter is required.

A Get-Module command with the PSSession parameter is equivalent to using the Invoke-Command cmdlet to run a Get-Module -ListAvailable command in a PSSession.

This parameter is introduced in Windows PowerShell 3.0.


Aliases

none

Required?

true

Position?

named

Default Value

None

Accept Pipeline Input?

false

Accept Wildcard Characters?

false

-Refresh

Refreshes the cache of installed commands. The command cache is created when the session starts. It enables the Get-Command cmdlet to get commands from modules that are not imported into the session.

This parameter is designed for development and testing scenarios in which the contents of modules have changed since the session started.

When the Refresh parameter is used in a command, the ListAvailable parameter is required.

This parameter is introduced in Windows PowerShell 3.0.


Aliases

none

Required?

false

Position?

named

Default Value

False

Accept Pipeline Input?

false

Accept Wildcard Characters?

false

<CommonParameters>

This cmdlet supports the common parameters: -Verbose, -Debug, -ErrorAction, -ErrorVariable, -OutBuffer, and -OutVariable. For more information, see  about_CommonParameters (http://go.microsoft.com/fwlink/p/?LinkID=113216).

Inputs

The input type is the type of the objects that you can pipe to the cmdlet.

  • System.String

    You can pipe module names to Get-Module.


Outputs

The output type is the type of the objects that the cmdlet emits.

  • System.Management.Automation.PSModuleInfo

    Get-Module returns objects that represent modules. When you use the ListAvailable parameter, Get-Module returns a ModuleInfoGrouping object, which is a type of PSModuleInfo object that has the same properties and methods.


Notes

  • Beginning in Windows PowerShell 3.0, the core commands that are included in Windows PowerShell are packaged in modules. The exception is Microsoft.PowerShell.Core, which is a snap-in (PSSnapin). By default, only the Microsoft.PowerShell.Core snap-in is added to the session by default. Modules are imported automatically on first use and you can use the Import-Module cmdlet to import them.

  • Beginning in Windows PowerShell 3.0, the core commands that are installed with Windows PowerShell are packaged in modules. In Windows PowerShell 2.0, and in host programs that create older-style sessions in later versions of Windows PowerShell, the core commands are packaged in snap-ins ("PSSnapins"). The exception is Microsoft.PowerShell.Core, which is always a snap-in. Also, remote sessions, such as those started by the New-PSSession cmdlet, are older-style sessions that include core snap-ins.

    For information about the CreateDefault2 method that creates newer-style sessions with core modules, see "CreateDefault2 Method" in MSDN at http://msdn.microsoft.com/en-us/library/windows/desktop/system.management.automation.runspaces.initialsessionstate.createdefault2(v=VS.85).aspx.

  • Get-Module only gets modules in locations that are stored in the value of the PSModulePath environment variable ($env:PSModulePath). You can use the Path parameter of the Import-Module cmdlet to import modules in other locations, but you cannot use the Get-Module cmdlet to get them.

  • Also, beginning in Windows PowerShell 3.0, new properties have been added to the object that Get-Module returns that make it easier to learn about modules even before they are imported. All properties are populated before importing, including the ExportedCommands, ExportedCmdlets and ExportedFunctions properties that list the commands that the module exports.

  • The ListAvailable parameter gets only well-formed modules, that is, folders that contain at least one file whose base name (the name without the file name extension) is the same as the name of the module folder. Folders that contain files with different names are considered to be containers, but not modules.

    To get modules that are implemented as .dll files, but are not enclosed in a module folder, use both the ListAvailable and All parameters.

  • To use the CIM session feature, the remote computer must have WS-Management remoting and Windows Management Instrumentation (WMI), which is the Microsoft implementation of the Common Information Model (CIM) standard. The computer must also have the Module Discovery WMI provider or an alternate WMI provider that has the same basic features.

    You can use the CIM session feature on computers that are not running a Windows operating system and on Windows computers that have Windows PowerShell, but do not have Windows PowerShell remoting enabled.

    You can also use the CIM parameters to get CIM modules from computers that have Windows PowerShell remoting enabled, including the local computer. When you create a CIM session on the local computer, Windows PowerShell uses DCOM, instead of WMI, to create the session.

Examples

-------------------------- EXAMPLE 1 --------------------------

This command gets modules that have been imported into the current session.


PS C:\> Get-Module

-------------------------- EXAMPLE 2 --------------------------

This command gets the modules that are installed on the computer and can be imported into the current session.

Get-Module looks for available modules in the path specified by the $env:PSModulePath environment variable. For more information about PSModulePath, see about_Modules and about_Environment_Variables.


PS C:\> Get-Module -ListAvailable

-------------------------- EXAMPLE 3 --------------------------

This command gets all of the exported files for all available modules.


PS C:\> Get-Module -ListAvailable -All

-------------------------- EXAMPLE 4 --------------------------

This command gets the Microsoft.PowerShell.Management module by specifying the module’s fully qualified name, with the FullyQualifiedName parameter. The command then pipes the results into Format-Table, to format the results as a table with Name and Version as the column headings.


PS C:\> Get-Module –FullyQualifiedName @{ModuleName="Microsoft.PowerShell.Management";ModuleVersion="3.1.0.0"} | Format-Table -Property Name,Version
Name                                                                                 Version                                                                             
---- -------
Microsoft.PowerShell.Management 3.1.0.0

-------------------------- EXAMPLE 5 --------------------------

This command gets the properties of the PSModuleInfo object that Get-Module returns. There is one object for each module file.

You can use the properties to format and filter the module objects. For more information about the properties, see "PSModule Properties" in the MSDN (Microsoft Developer Network) library at http://go.microsoft.com/fwlink/?LinkId=143624.

The output includes the new properties, such as Author and CompanyName, that were introduced in Windows PowerShell 3.0


PS C:\> Get-Module | Get-Member -MemberType Property | Format-Table Name
Name
----
AccessMode
Author
ClrVersion
CompanyName
Copyright
Definition
Description
DotNetFrameworkVersion
ExportedAliases
ExportedCmdlets
ExportedCommands
ExportedFormatFiles
ExportedFunctions
ExportedTypeFiles
ExportedVariables
ExportedWorkflows
FileList
Guid
HelpInfoUri
LogPipelineExecutionDetails
ModuleBase
ModuleList
ModuleType
Name
NestedModules
OnRemove
Path
PowerShellHostName
PowerShellHostVersion
PowerShellVersion
PrivateData
ProcessorArchitecture
RequiredAssemblies
RequiredModules
RootModule
Scripts
SessionState
Version

-------------------------- EXAMPLE 6 --------------------------

This command gets all module files (imported and available) and groups them by module name. This lets you see the module files that each script is exporting.


PS C:\> Get-Module -ListAvailable -All | Format-Table -Property Name, Moduletype, Path -Groupby Name
   Name: AppLocker

Name ModuleType Path
---- ---------- ----
AppLocker Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\AppLocker\AppLocker.psd1


Name: Appx

Name ModuleType Path
---- ---------- ----
Appx Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\en-US\Appx.psd1
Appx Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\Appx.psd1
Appx Script C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\Appx.psm1


Name: BestPractices

Name ModuleType Path
---- ---------- ----
BestPractices Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\BestPractices\BestPractices.psd1


Name: BitsTransfer

Name ModuleType Path
---- ---------- ----
BitsTransfer Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\BitsTransfer\BitsTransfer.psd1

-------------------------- EXAMPLE 7 --------------------------

These commands display the contents of the module manifest for the Windows PowerShell BitsTransfer module.

Modules are not required to have manifest files and, when they do have a manifest file, the manifest file is required only to include a version number. However, manifest files often provide useful information about a module, its requirements, and its contents.


 

The first command gets the PSModuleInfo object that represents BitsTransfer module. It saves the object in the $m variable.


PS C:\> $m = Get-Module -list -Name BitsTransfer

 

The second command uses the Get-Content cmdlet to get the content of the manifest file in the specified path. It uses dot notation to get the path to the manifest file, which is stored in the Path property of the object.

The output shows the contents of the module manifest.


PS C:\> Get-Content $m.Path
                
@{
GUID="{8FA5064B-8479-4c5c-86EA-0D311FE48875}"
Author="Microsoft Corporation"
CompanyName="Microsoft Corporation"
Copyright="© Microsoft Corporation. All rights reserved."
ModuleVersion="1.0.0.0"
Description="Windows Powershell File Transfer Module"
PowerShellVersion="2.0"
CLRVersion="2.0"
NestedModules="Microsoft.BackgroundIntelligentTransfer.Management"
FormatsToProcess="FileTransfer.Format.ps1xml"
RequiredAssemblies=Join-Path $psScriptRoot "Microsoft.BackgroundIntelligentTransfer.Management.Interop.dll"
}

-------------------------- EXAMPLE 8 --------------------------

This command lists the files in the module's directory. This is another way to determine what is in a module before you import it. Some modules might have help files or ReadMe files that describe the module.


PS C:\> dir (Get-Module -ListAvailable FileTransfer).ModuleBase
Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules\FileTransfer
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 12/16/2008 12:36 PM en-US
-a--- 11/19/2008 11:30 PM 16184 FileTransfer.Format.ps1xml
-a--- 11/20/2008 11:30 PM 1044 FileTransfer.psd1
-a--- 12/16/2008 12:20 AM 108544 Microsoft.BackgroundIntelligentTransfer.Management.Interop.dll

-------------------------- EXAMPLE 9 --------------------------

These commands get the modules that are installed on the Server01 computer.

The first command uses the New-PSSession cmdlet to create a PSSession on the Server01 computer. The command saves the PSSession in the $s variable.

The second command uses the PSSession and ListAvailable parameters of Get-Module to get the modules in the PSSession in the $s variable.

If you pipe modules from other sessions to the Import-Module cmdlet, Import-Module imports the module into the current session by using the implicit remoting feature. This is equivalent to using the Import-PSSession cmdlet. You can use the cmdlets from the module in the current session, but commands that use these cmdlets actually run the remote session. For more information, see Import-Module and Import-PSSession.


PS C:\> $s = New-PSSession -ComputerName Server01
PS C:\>Get-Module -PSSession $s -ListAvailable

-------------------------- EXAMPLE 10 --------------------------

The commands in this example enable you to manage the storage systems of a remote computer that is not running a Windows operating system. In this example, because the administrator of the computer has installed the Module Discovery WMI provider, the CIM commands can use the default values, which are designed for the provider.


 

The first command uses the New-CimSession cmdlet to create a session on the RSDGF03 remote computer. The session connects to WMI on the remote computer. The command saves the CIM session in the $cs variable.


PS C:\> $cs = New-CimSession -ComputerName RSDGF03

 

The second command uses in the CIM session in the $cs variable to run a Get-Module command on the RSDGF03 computer. The command uses the Name parameter to specify the Storage module.

The command uses a pipeline operator (|) to send the Storage module to the Import-Module cmdlet, which imports it into the local session.


PS C:\> Get-Module -CimSession $cs -Name Storage | Import-Module

 

The third command runs the Get-Command cmdlet on the Get-Disk command in the Storage module.

When you import a CIM module into the local session, Windows PowerShell converts the CDXML files that represent in the CIM module into Windows PowerShell scripts, which appear as functions in the local session.


PS C:\> Get-Command Get-Disk
CommandType     Name                  ModuleName
----------- ---- ----------
Function Get-Disk Storage

 

The fourth command runs the Get-Disk command. Although the command is typed in the local session, it runs implicitly on the remote computer from which it was imported.

The command gets objects from the remote computer and returns them to the local session.


PS C:\> Get-Disk
Number Friendly Name              OperationalStatus          Total Size Partition Style
------ ------------- ----------------- ---------- ---------------
0 Virtual HD ATA Device Online 40 GB MBR

Related topics



Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft