Compartir a través de


Get-Module

Enumere los módulos importados en la sesión actual o que se pueden importar desde PSModulePath.

Sintaxis

Get-Module
   [[-Name] <String[]>]
   [-FullyQualifiedName <ModuleSpecification[]>]
   [-All]
   [<CommonParameters>]
Get-Module
   [[-Name] <String[]>]
   [-FullyQualifiedName <ModuleSpecification[]>]
   [-All]
   [-ListAvailable]
   [-PSEdition <String>]
   [-SkipEditionCheck]
   [-Refresh]
   [<CommonParameters>]
Get-Module
   [[-Name] <String[]>]
   [-FullyQualifiedName <ModuleSpecification[]>]
   [-ListAvailable]
   [-PSEdition <String>]
   [-SkipEditionCheck]
   [-Refresh]
   -PSSession <PSSession>
   [<CommonParameters>]
Get-Module
   [[-Name] <String[]>]
   [-FullyQualifiedName <ModuleSpecification[]>]
   [-ListAvailable]
   [-SkipEditionCheck]
   [-Refresh]
   -CimSession <CimSession>
   [-CimResourceUri <Uri>]
   [-CimNamespace <String>]
   [<CommonParameters>]

Description

El Get-Module cmdlet enumera los módulos de PowerShell que se han importado o que se pueden importar en una sesión de PowerShell. Sin parámetros, Get-Module obtiene los módulos que se han importado en la sesión actual. El parámetro ListAvailable se usa para enumerar los módulos que están disponibles para importarse desde las rutas de acceso especificadas en la variable de entorno PSModulePath ($env:PSModulePath).

El objeto de módulo que Get-Module devuelve contiene información valiosa sobre el módulo. También puede canalizar los objetos de módulo a otros cmdlets, como los Import-Module cmdlets y Remove-Module .

Get-Module enumera los módulos, pero no los importa. A partir de Windows PowerShell 3.0, los módulos se importan automáticamente cuando se usa un comando en el módulo, pero un Get-Module comando no desencadena una importación automática. También puede importar los módulos en la sesión mediante el Import-Module cmdlet .

A partir de Windows PowerShell 3.0, puede obtener y, a continuación, importar módulos desde sesiones remotas a la sesión local. Esta estrategia usa la característica de comunicación remota implícita de PowerShell y es equivalente al uso del Import-PSSession cmdlet . Cuando se usan comandos en módulos importados desde otra sesión, los comandos se ejecutan implícitamente en la sesión remota. Esta característica le permite administrar el equipo remoto desde la sesión local.

Además, a partir de Windows PowerShell 3.0, puede usar Get-Module y Import-Module para obtener e importar módulos de Common Information Model (CIM). Los módulos CIM definen cmdlets en archivos XML de definición de cmdlet (CDXML). Esta característica permite usar cmdlets que se implementan en ensamblados de código no administrados, como los escritos en C++.

La comunicación remota implícita se puede usar para administrar equipos remotos que tienen habilitada la comunicación remota de PowerShell. Cree una PSSession en el equipo remoto y, a continuación, use el parámetro PSSession de Get-Module para obtener los módulos de PowerShell en la sesión remota. Al importar un módulo desde la sesión remota, los comandos importados se ejecutan en la sesión del equipo remoto.

Puede usar una estrategia similar para administrar equipos que no tengan habilitada la comunicación remota de PowerShell. Estos incluyen equipos que no ejecutan el sistema operativo Windows y equipos que tienen PowerShell, pero que no tienen habilitada la comunicación remota de PowerShell.

Empiece por crear una sesión CIM en el equipo remoto. Una sesión CIM es una conexión a Instrumental de administración de Windows (WMI) en el equipo remoto. A continuación, use el parámetro CIMSession de Get-Module para obtener módulos CIM de la sesión CIM. Al importar un módulo CIM mediante el Import-Module cmdlet y, a continuación, ejecutar los comandos importados, los comandos se ejecutan implícitamente en el equipo remoto. Puede recurrir a esta estrategia de WMI y CIM para administrar el equipo remoto.

Ejemplos

Ejemplo 1: Obtención de módulos importados en la sesión actual

Get-Module

Este comando obtiene los módulos que se han importado a la sesión actual.

Ejemplo 2: Obtener módulos instalados y módulos disponibles

Get-Module -ListAvailable

Este comando obtiene los módulos que están instalados en el equipo y que se pueden importar a la sesión actual.

Get-Module busca los módulos disponibles en la ruta de acceso especificada por la variable de entorno $env:PSModulePath . Para obtener más información sobre PSModulePath, consulte about_Modules y about_Environment_Variables.

Ejemplo 3: Obtener todos los archivos exportados

Get-Module -ListAvailable -All

Este comando obtiene todos los archivos exportados de todos los módulos disponibles.

Ejemplo 4: Obtener un módulo por su nombre completo

$FullyQualifiedName = @{ModuleName="Microsoft.PowerShell.Management";ModuleVersion="3.1.0.0"}
Get-Module -FullyQualifiedName $FullyQualifiedName | Format-Table -Property Name,Version

Name                             Version
----                             -------
Microsoft.PowerShell.Management  3.1.0.0

En este ejemplo se obtiene el módulo Microsoft.PowerShell.Management especificando el nombre completo del módulo mediante el parámetro FullyQualifiedName. A continuación, el comando canaliza los resultados en el Format-Table cmdlet para dar formato a los resultados como una tabla con Name y Version como encabezados de columna.

En un nombre completo para un módulo, el valor ModuleVersion actúa como versión mínima. Por lo tanto, en este ejemplo, coincide con cualquier módulo Microsoft.PowerShell.Management que sea versión 3.1.0.0 o superior.

Ejemplo 5: Obtener propiedades de un módulo

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

Este comando obtiene las propiedades del objeto PSModuleInfo que Get-Module devuelve. Hay un objeto para cada archivo de módulo.

Puede usar las propiedades para dar formato y filtrar los objetos de módulo. Para obtener más información sobre las propiedades, vea Propiedades de PSModuleInfo.

La salida incluye las nuevas propiedades, como Author y CompanyName, que se introdujeron en Windows PowerShell 3.0.

Ejemplo 6: Agrupar todos los módulos por nombre

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

Este comando obtiene todos los archivos de módulo, importados y disponibles, y luego los agrupa por nombre del módulo. Esto permite ver los archivos de módulo que cada script está exportando.

Ejemplo 7: Mostrar el contenido de un manifiesto de módulo

Estos comandos muestran el contenido del manifiesto del módulo para el módulo BitsTransfer de Windows PowerShell.

No es necesario que los módulos tengan archivos de manifiesto. Cuando tienen un archivo de manifiesto, el archivo de manifiesto solo es necesario para incluir un número de versión. Sin embargo, los archivos de manifiesto suelen proporcionan información útil sobre un módulo, sus requisitos y su contenido.

# First command
$m = Get-Module -list -Name BitsTransfer

# Second command
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"
}

El primer comando obtiene el objeto PSModuleInfo que representa el módulo BitsTransfer. Guarda el objeto en la $m variable .

El segundo comando usa el Get-Content cmdlet para obtener el contenido del archivo de manifiesto en la ruta de acceso especificada. Usa la notación de puntos para obtener la ruta de acceso al archivo de manifiesto, que se almacena en la propiedad Path del objeto . La salida muestra el contenido del manifiesto del módulo.

Ejemplo 8: Enumerar archivos en el directorio del módulo

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

Este comando enumera los archivos del directorio del módulo. Esta es otra manera de determinar qué hay en un módulo antes de importarlo. Algunos módulos pueden tener archivos de ayuda o archivos Léame que describen el módulo.

Ejemplo 9: Obtener módulos instalados en un equipo

$s = New-PSSession -ComputerName Server01

Get-Module -PSSession $s -ListAvailable

Estos comandos obtienen los módulos que están instalados en el equipo Server01.

El primer comando usa el New-PSSession cmdlet para crear una PSSession en el equipo Server01. El comando guarda la PSSession en la $s variable .

El segundo comando usa los parámetros PSSession y ListAvailable de Get-Module para obtener los módulos de PSSession en la $s variable .

Si canaliza módulos de otras sesiones al Import-Module cmdlet , Import-Module importa el módulo a la sesión actual mediante la característica de comunicación remota implícita. Esto equivale a usar el Import-PSSession cmdlet . Puede usar los cmdlets del módulo en la sesión actual, pero los comandos que usan estos cmdlets se ejecutan realmente en la sesión remota. Para obtener más información, vea Import-Module y Import-PSSession.

Ejemplo 10: Administrar un equipo que no ejecuta el sistema operativo Windows

Los comandos de este ejemplo permiten administrar los sistemas de almacenamiento de un equipo remoto que no ejecuta el sistema operativo Windows. En este ejemplo, y debido a que el administrador del equipo ha instalado al proveedor de WMI de detección de módulos, los comandos de CIM pueden usar los valores predeterminados, que están diseñados para el proveedor.

$cs = New-CimSession -ComputerName RSDGF03
Get-Module -CimSession $cs -Name Storage | Import-Module
Get-Command Get-Disk

CommandType     Name                  ModuleName
-----------     ----                  ----------
Function        Get-Disk              Storage

Get-Disk

Number Friendly Name              OperationalStatus          Total Size Partition Style
------ -------------              -----------------          ---------- ---------------
0      Virtual HD ATA Device      Online                          40 GB MBR

El primer comando usa el New-CimSession cmdlet para crear una sesión en el equipo remoto RSDGF03. La sesión se conecta a WMI en el equipo remoto. El comando guarda la sesión CIM en la $cs variable .

El segundo comando usa la sesión CIM en la $cs variable para ejecutar un Get-Module comando en el equipo RSDGF03. El comando usa el parámetro Name para especificar el módulo Storage. El comando usa un operador de canalización (|) para enviar el módulo Storage al Import-Module cmdlet , que lo importa en la sesión local.

El tercer comando ejecuta el Get-Command cmdlet en el Get-Disk comando del módulo Storage. Al importar un módulo CIM en la sesión local, PowerShell convierte los archivos CDXML que representan el módulo CIM en scripts de PowerShell, que aparecen como funciones en la sesión local.

El cuarto comando ejecuta el Get-Disk comando . Aunque el comando se escribe en la sesión local, se ejecuta implícitamente en el equipo remoto desde el que se importó. El comando obtiene objetos del equipo remoto y los devuelve a la sesión local.

Parámetros

-All

Indica que este cmdlet obtiene todos los módulos de cada carpeta de módulo, incluidos los módulos anidados, los archivos de manifiesto (.psd1), los archivos del módulo de script (.psm1) y los archivos del módulo binario (.dll). Sin este parámetro, Get-Module obtiene solo el módulo predeterminado en cada carpeta del módulo.

Tipo:SwitchParameter
Posición:Named
Valor predeterminado:False
Requerido:False
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

-CimNamespace

Especifica el espacio de nombres de otro proveedor de CIM que expone módulos CIM. El valor predeterminado es el espacio de nombres del proveedor de WMI de detección de módulos.

Use este parámetro para obtener módulos CIM de equipos y dispositivos que no ejecutan el sistema operativo Windows.

Este parámetro se incorporó en Windows PowerShell 3.0.

Tipo:String
Posición:Named
Valor predeterminado:None
Requerido:False
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

-CimResourceUri

Especifica una ubicación alternativa para los módulos CIM. El valor predeterminado es el URI de recurso del proveedor de WMI de detección de módulos en el equipo remoto.

Use este parámetro para obtener módulos CIM de equipos y dispositivos que no ejecutan el sistema operativo Windows.

Este parámetro se incorporó en Windows PowerShell 3.0.

Tipo:Uri
Posición:Named
Valor predeterminado:None
Requerido:False
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

-CimSession

Especifica una sesión CIM en el equipo remoto. Escriba una variable que contenga la sesión CIM o un comando que obtenga la sesión CIM, como un comando Get-CimSession .

Get-Module usa la conexión de sesión CIM para obtener módulos del equipo remoto. Al importar el módulo mediante el Import-Module cmdlet y usar los comandos del módulo importado en la sesión actual, los comandos se ejecutan realmente en el equipo remoto.

Puede usar este parámetro para obtener módulos de equipos y dispositivos que no ejecutan el sistema operativo Windows y equipos que tienen PowerShell, pero que no tienen habilitada la comunicación remota de PowerShell.

El parámetro CimSession obtiene todos los módulos de CIMSession. Sin embargo, solo puede importar módulos basados en CIM y basados en XML de definición de cmdlet (CDXML).

Tipo:CimSession
Posición:Named
Valor predeterminado:None
Requerido:True
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

-FullyQualifiedName

El valor puede ser un nombre de módulo, una especificación de módulo completa o una ruta de acceso a un archivo de módulo.

Cuando el valor es una ruta de acceso, la ruta de acceso puede ser completa o relativa. Se resuelve una ruta de acceso relativa con respecto al script que contiene la instrucción using.

Cuando el valor es un nombre o especificación de módulo, PowerShell busca en el módulo especificado la psModulePath .

Una especificación de módulo es una tabla hash que tiene las siguientes claves.

  • ModuleName - Obligatorio Especifica el nombre del módulo.
  • GUID - Opcional Especifica el GUID del módulo.
  • También es necesario especificar al menos una de las tres claves siguientes.
    • ModuleVersion : especifica una versión mínima aceptable del módulo.
    • MaximumVersion : especifica la versión máxima aceptable del módulo.
    • RequiredVersion : especifica una versión exacta y necesaria del módulo. Esto no se puede usar con las otras claves de versión.

No se puede especificar el parámetro FullyQualifiedName en el mismo comando que un parámetro Name .

Tipo:ModuleSpecification[]
Posición:Named
Valor predeterminado:None
Requerido:False
Aceptar entrada de canalización:True
Aceptar caracteres comodín:False

-ListAvailable

Indica que este cmdlet obtiene todos los módulos instalados. Get-Module obtiene módulos en rutas de acceso enumeradas en la variable de entorno PSModulePath . Sin este parámetro, Get-Module obtiene solo los módulos que aparecen en la variable de entorno PSModulePath y que se cargan en la sesión actual. ListAvailable no devuelve información sobre los módulos que no se encuentran en la variable de entorno PSModulePath , incluso si esos módulos se cargan en la sesión actual.

Tipo:SwitchParameter
Posición:Named
Valor predeterminado:None
Requerido:False
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

-Name

Especifica nombres o patrones de nombre de módulos que obtiene este cmdlet. Se permite el uso de caracteres comodín. También puede canalizar los nombres a Get-Module. No se puede especificar el parámetro FullyQualifiedName en el mismo comando que un parámetro Name .

Name no puede aceptar un GUID de módulo como un valor. Para devolver módulos especificando un GUID, use FullyQualifiedName en su lugar.

Tipo:String[]
Posición:0
Valor predeterminado:None
Requerido:False
Aceptar entrada de canalización:True
Aceptar caracteres comodín:True

-PSEdition

Obtiene los módulos que admiten la edición especificada de PowerShell.

Los valores permitidos para este parámetro son los siguientes:

  • Desktop
  • Core

El Get-Module cmdlet comprueba la propiedad CompatiblePSEditions del objeto PSModuleInfo para el valor especificado y devuelve solo los módulos que lo tienen establecido.

Nota:

  • Desktop Edition: basado en .NET Framework y proporciona compatibilidad con scripts y módulos destinados a las versiones de PowerShell que se ejecutan en las ediciones de superficie completa de Windows como Server Core y Windows Desktop.
  • Core Edition: basado en .NET Core y proporciona compatibilidad con scripts y módulos destinados a las versiones de PowerShell que se ejecutan en las ediciones de superficie completa de Windows como Nano Server y Windows IoT.
Tipo:String
Posición:Named
Valor predeterminado:None
Requerido:False
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

-PSSession

Obtiene los módulos de la sesión de PowerShell administrada por el usuario especificada (PSSession). Escriba una variable que contenga la sesión, un comando que obtiene la sesión, como un Get-PSSession comando o un comando que crea la sesión, como un New-PSSession comando.

Cuando la sesión está conectada a un equipo remoto, debe especificar el parámetro ListAvailable .

Un Get-Module comando que usa el parámetro PSSession equivale a usar el Invoke-Command cmdlet para ejecutar un Get-Module -ListAvailable comando en una PSSession.

Este parámetro se incorporó en Windows PowerShell 3.0.

Tipo:PSSession
Posición:Named
Valor predeterminado:None
Requerido:True
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

-Refresh

Indica que este cmdlet actualiza la memoria caché de comandos instalados. La caché de comandos se crea cuando se inicia la sesión. Permite al Get-Command cmdlet obtener comandos de módulos que no se importan en la sesión.

Este parámetro está diseñado para escenarios de desarrollo y pruebas en los que el contenido de los módulos ha cambiado desde que se inició la sesión.

Al especificar el parámetro Refresh en un comando, debe especificar ListAvailable.

Este parámetro se incorporó en Windows PowerShell 3.0.

Tipo:SwitchParameter
Posición:Named
Valor predeterminado:False
Requerido:False
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

-SkipEditionCheck

Omite la comprobación del campo CompatiblePSEditions .

De forma predeterminada, Get-Module omite los módulos del %windir%\System32\WindowsPowerShell\v1.0\Modules directorio que no se especifican Core en el campo CompatiblePSEditions . Cuando se establece este modificador, se devuelven los módulos sin Core incluirlos, de modo que se devuelvan los módulos de la ruta de acceso del módulo de Windows PowerShell incompatibles con PowerShell v6 y versiones posteriores.

En macOS y Linux, este parámetro no hace nada.

Consulte about_PowerShell_Editions para obtener más información.

Tipo:SwitchParameter
Posición:Named
Valor predeterminado:None
Requerido:False
Aceptar entrada de canalización:False
Aceptar caracteres comodín:False

Entradas

String

Puede canalizar los nombres de módulo a este cmdlet.

Salidas

PSModuleInfo

Este cmdlet devuelve objetos que representan módulos. Al especificar el parámetro ListAvailable , Get-Module devuelve un objeto ModuleInfoGrouping , que es un tipo de objeto PSModuleInfo que tiene las mismas propiedades y métodos.

Notas

PowerShell incluye los siguientes alias para Get-Module:

  • Todas las plataformas:

    • gmo
  • A partir de Windows PowerShell 3.0, los comandos principales que se incluyen en PowerShell se empaquetan en módulos. La excepción es Microsoft.PowerShell.Core, que es un complemento (PSSnapin). De forma predeterminada, solo se agrega el complemento Microsoft.PowerShell.Core a la sesión. Los módulos se importan automáticamente en el primer uso y puede usar el Import-Module cmdlet para importarlos.

  • En Windows PowerShell 2.0 y en programas host que crean sesiones de estilo anterior en versiones posteriores de PowerShell, los comandos principales se empaquetan en complementos (PSSnapins). La excepción es Microsoft.PowerShell.Core, que siempre es un complemento. Además, las sesiones remotas, como las iniciadas por el New-PSSession cmdlet, son sesiones de estilo anterior que incluyen complementos principales.

    Para obtener información sobre el método CreateDefault2 que crea sesiones de estilo más reciente con módulos principales, vea CreateDefault2 Method.

  • Get-Module solo obtiene módulos en ubicaciones almacenadas en el valor de la variable de entorno PSModulePath ($env:PSModulePath). El Import-Module cmdlet puede importar módulos en otras ubicaciones, pero no puede usar el Get-Module cmdlet para obtenerlos.

  • Además, a partir de PowerShell 3.0, se han agregado nuevas propiedades al objeto que Get-Module devuelve que facilitan la información sobre los módulos incluso antes de importarlos. Todas las propiedades se rellenan antes de importar. Estos incluyen las propiedades ExportedCommands, ExportedCmdlets y ExportedFunctions que enumeran los comandos que exporta el módulo.

  • El parámetro ListAvailable solo obtiene módulos bien formados, es decir, carpetas que contienen al menos un archivo cuyo nombre base es el mismo que el nombre de la carpeta del módulo. El nombre base es el nombre sin la extensión de nombre de archivo. Las carpetas que contienen archivos que tienen nombres diferentes se consideran contenedores, pero no módulos.

    Para obtener módulos que se implementan como archivos DLL, pero no se incluyen en una carpeta de módulos, especifique los parámetros ListAvailable y All .

  • Para usar la característica de sesión CIM, el equipo remoto debe disponer de comunicación remota de WS-Management y de Instrumental de administración de Windows (WMI), que es la implementación de Microsoft del Modelo de información común (CIM) estándar. El equipo también debe tener el proveedor de WMI para la detección de módulos u otro proveedor de WMI que tenga las mismas características básicas.

    Puede usar la característica de sesión CIM en equipos que no ejecutan el sistema operativo Windows y en equipos Windows que tienen PowerShell, pero que no tienen habilitada la comunicación remota de PowerShell.

    También puede usar los parámetros CIM para obtener módulos CIM de equipos que tengan habilitada la comunicación remota de PowerShell. Esto incluye el equipo local. Al crear una sesión CIM en el equipo local, PowerShell usa DCOM, en lugar de WMI, para crear la sesión.