PowerShell Logo Small

Import-Module



This is the built-in help made by Microsoft for the command 'Import-Module', in PowerShell version 5 - as retrieved from Windows version 'Microsoft Windows Server 2012 R2 Standard' PowerShell help files on 2016-06-23.

For PowerShell version 3 and up, where you have Update-Help, this command was run just before creating the web pages from the help files.

SYNOPSIS

Adds modules to the current session.

SYNTAX


Import-Module [-Name] <String[]> [-Alias [<String[]>]] [-ArgumentList [<Object[]>]] [-AsCustomObject] [-Cmdlet [<String[]>]] [-DisableNameChecking] [-Force] [-Function
[<String[]>]] [-Global] [-MaximumVersion [<String>]] [-MinimumVersion [<Version>]] [-NoClobber] [-PassThru] [-Prefix [<String>]] [-RequiredVersion [<Version>]] [-Scope
{Local | Global}] [-Variable [<String[]>]] [<CommonParameters>]
Import-Module [-Assembly] <Assembly[]> [-Alias [<String[]>]] [-ArgumentList [<Object[]>]] [-AsCustomObject] [-Cmdlet [<String[]>]] [-DisableNameChecking] [-Force] [-Function
[<String[]>]] [-Global] [-NoClobber] [-PassThru] [-Prefix [<String>]] [-Scope {Local | Global}] [-Variable [<String[]>]] [<CommonParameters>]
Import-Module [-Name] <String[]> [-Alias [<String[]>]] [-ArgumentList [<Object[]>]] [-AsCustomObject] [-CimNamespace [<String>]] [-CimResourceUri [<Uri>]] [-Cmdlet
[<String[]>]] [-DisableNameChecking] [-Force] [-Function [<String[]>]] [-Global] [-MaximumVersion [<String>]] [-MinimumVersion [<Version>]] [-NoClobber] [-PassThru] [-Prefix
[<String>]] [-RequiredVersion [<Version>]] [-Scope {Local | Global}] [-Variable [<String[]>]] -CimSession <CimSession> [<CommonParameters>]
Import-Module [-Name] <String[]> [-Alias [<String[]>]] [-ArgumentList [<Object[]>]] [-AsCustomObject] [-Cmdlet [<String[]>]] [-DisableNameChecking] [-Force] [-Function
[<String[]>]] [-Global] [-MaximumVersion [<String>]] [-MinimumVersion [<Version>]] [-NoClobber] [-PassThru] [-Prefix [<String>]] [-RequiredVersion [<Version>]] [-Scope
{Local | Global}] [-Variable [<String[]>]] -PSSession <PSSession> [<CommonParameters>]
Import-Module [-ModuleInfo] <PSModuleInfo[]> [-Alias [<String[]>]] [-ArgumentList [<Object[]>]] [-AsCustomObject] [-Cmdlet [<String[]>]] [-DisableNameChecking] [-Force]
[-Function [<String[]>]] [-Global] [-NoClobber] [-PassThru] [-Prefix [<String>]] [-Scope {Local | Global}] [-Variable [<String[]>]] [<CommonParameters>]
Import-Module [-FullyQualifiedName] <ModuleSpecification[]> [<CommonParameters>]
Import-Module [-FullyQualifiedName] <ModuleSpecification[]> [<CommonParameters>]



Search powershellhelp.space

DESCRIPTION


The Import-Module cmdlet adds one or more modules to the current session. The modules that you import must be installed on the local computer or a remote computer.


Beginning in Windows PowerShell 3.0, installed modules are automatically imported to the session when you use any commands or providers in the module. However, you can still
use the Import-Module command to import a module and you can enable and disable automatic module importing by using the $PSModuleAutoloadingPreference preference variable.
For more information about modules, see about_Modules (http://go.microsoft.com/fwlink/?LinkID=144311). For more information about the $PSModuleAutoloadingPreference
variable, see about_Preference_Variables (http://go.microsoft.com/fwlink/?LinkID=113248).


A module is a package that contains members (such as cmdlets, providers, scripts, functions, variables, and other tools and files) that can be used in Windows PowerShell.
After a module is imported, you can use the module members in your session.


To import a module, use the Name, Assembly, ModuleInfo, MinimumVersion and RequiredVersion parameters to identify the module to import. By default, Import-Module imports
all members that the module exports, but you can use the Alias, Function, Cmdlet, and Variable parameters to restrict the members that are imported. You can also use the
NoClobber parameter to prevent Import-Module from importing members that have the same names as members in the current session.


Import-Module imports a module only into the current session. To import the module into all sessions, add an Import-Module command to your Windows PowerShell profile. For
more information about profiles, see about_Profiles (http://go.microsoft.com/fwlink/?LinkID=113729).


Also, beginning in Windows PowerShell 3.0, you can use Import-Module to 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, Import-Module cmdlet becomes a primary tool 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 Import-Module to import CIM modules from the remote computer. When you import a CIM module 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.



<

RELATED LINKS

Online Version: http://go.microsoft.com/fwlink/p/?linkid=289591
Export-ModuleMember
Get-Module
New-Module
Remove-Module
Get-Verb
about_Modules

REMARKS

<

Examples


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

PS C:\>Import-Module -Name BitsTransfer



This command imports the members of the BitsTransfer module into the current session.

The Name parameter name (-Name) is optional and can be omitted.

By default, Import-Module does not generate any output when it imports a module. To request output, use the PassThru or AsCustomObject parameter, or the Verbose common
parameter.






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

PS C:\>Get-Module -ListAvailable | Import-Module



This command imports all available modules in the path specified by the PSModulePath environment variable ($env:PSModulePath) into the current session.










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

PS C:\>$m = Get-Module -ListAvailable BitsTransfer, ServerManager
PS C:\>Import-Module -ModuleInfo $m



These commands import the members of the BitsTransfer and ServerManager modules into the current session.

The first command uses the Get-Module-Module cmdlet to get the BitsTransfer and ServerManager modules. It saves the objects in the $m variable. The ListAvailable parameter
is required when you are getting modules that are not yet imported into the session.

The second command uses the ModuleInfo parameter of Import-Module to import the modules into the current session.

These commands are equivalent to using a pipeline operator (|) to send the output of a Get-Module command to Import-Module.






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

PS C:\>Import-Module -Name c:\ps-test\modules\test -Verbose
VERBOSE: Loading module from path 'C:\ps-test\modules\Test\Test.psm1'.
VERBOSE: Exporting function 'my-parm'.
VERBOSE: Exporting function 'Get-Parameter'.
VERBOSE: Exporting function 'Get-Specification'.
VERBOSE: Exporting function 'Get-SpecDetails'.



This command uses an explicit path to identify the module to import.

It also uses the Verbose common parameter to get a list of the items imported from the module. Without the Verbose, PassThru, or AsCustomObject parameter, Import-Module does
not generate any output when it imports a module.






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

PS C:\>Import-Module BitsTransfer -cmdlet Add-BitsTransferFile, Get-BitsTransfer
PS C:\>Get-Module BitsTransfer

Name : BitsTransfer
Path : C:\Windows\system32\WindowsPowerShell\v1.0\Modules\BitsTransfer\BitsTransfer.psd1
Description :
Guid : 8fa5064b-8479-4c5c-86ea-0d311fe48875
Version : 1.0.0.0
ModuleBase : C:\Windows\system32\WindowsPowerShell\v1.0\Modules\BitsTransfer
ModuleType : Manifest
PrivateData :
AccessMode : ReadWrite
ExportedAliases : {}
ExportedCmdlets : {[Add-BitsTransfer, Add-BitsTransfer], [Complete-BitsTransfer, Complete-BitsTransfer],
[Get-BitsTransfer, Get-BitsTransfer], [Remove-BitsTransfer, Remove-BitsTransfer]...}
ExportedFunctions : {}
ExportedVariables : {}
NestedModules : {Microsoft.BackgroundIntelligentTransfer.Management}

PS C:\>Get-Command -Module BitsTransfer

CommandType Name ModuleName
----------- ---- ----------
Cmdlet Add-BitsFile bitstransfer
Cmdlet Complete-BitsTransfer bitstransfer
Cmdlet Get-BitsTransfer bitstransfer
Cmdlet Remove-BitsTransfer bitstransfer
Cmdlet Resume-BitsTransfer bitstransfer
Cmdlet Set-BitsTransfer bitstransfer
Cmdlet Start-BitsTransfer bitstransfer
Cmdlet Suspend-BitsTransfer bitstransfer



This example shows how to restrict the module members that are imported into the session and the effect of this command on the session.

The first command imports only the Add-BitsTransfer and Get-BitsTransfer cmdlets from the BitsTransfer module. The command uses the Cmdlet parameter to restrict the cmdlets
that the module imports. You can also use the Alias, Variable, and Function parameters to restrict other members that a module imports.

The second command uses the Get-Module cmdlet to get the object that represents the BitsTransfer module. The ExportedCmdlets property lists all of the cmdlets that the
module exports, even when they were not all imported.

The third command uses the Module parameter of the Get-Command cmdlet to get the commands that were imported from the BitsTransfer module. The results confirm that only the
Add-BitsTransfer and Get-BitsTransfer cmdlets were imported.






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

PS C:\>Import-Module BitsTransfer -Prefix PS -PassThru

ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest bitstransfer {Add-BitsFile, Complete-...

PS C:\>Get-Command -Module BitsTransfer

CommandType Name ModuleName
----------- ---- ----------
Cmdlet Add-BitsFile bitstransfer
Cmdlet Add-PSBitsFile bitstransfer
Cmdlet Complete-BitsTransfer bitstransfer
Cmdlet Complete-PSBitsTransfer bitstransfer
Cmdlet Get-BitsTransfer bitstransfer
Cmdlet Get-PSBitsTransfer bitstransfer
Cmdlet Remove-BitsTransfer bitstransfer
Cmdlet Remove-PSBitsTransfer bitstransfer
Cmdlet Resume-BitsTransfer bitstransfer
Cmdlet Resume-PSBitsTransfer bitstransfer
Cmdlet Set-BitsTransfer bitstransfer
Cmdlet Set-PSBitsTransfer bitstransfer
Cmdlet Start-BitsTransfer bitstransfer
Cmdlet Start-PSBitsTransfer bitstransfer
Cmdlet Suspend-BitsTransfer bitstransfer
Cmdlet Suspend-PSBitsTransfer bitstransfer



These commands import the BitsTransfer module into the current session, add a prefix to the member names, and then display the prefixed member names.

The first command uses the Import-Module cmdlet to import the BitsTransfer module. It uses the Prefix parameter to add the PS prefix to all members that are imported from
the module and the PassThru parameter to return a module object that represents the imported module.

The second command uses the Get-Command cmdlet to get the members that have been imported from the module. It uses the Module parameter to specify the module. The output
shows that the module members were correctly prefixed.

The prefix that you use applies only to the members in the current session. It does not change the module.






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

PS C:\>Get-Module -List | Format-Table -Property Name, ModuleType -AutoSize

Name ModuleType
---- ----------
Show-Calendar Script
BitsTransfer Manifest
PSDiagnostics Manifest
TestCmdlets Script

PS C:\>$a = Import-Module -Name Show-Calendar -AsCustomObject -Passthru

PS C:\>$a | Get-Member

TypeName: System.Management.Automation.PSCustomObject
Name MemberType Definition
---- ---------- ----------
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
Show-Calendar ScriptMethod System.Object Show-Calendar();

PS C:\>$a."Show-Calendar"()



These commands demonstrate how to get and use the custom object that Import-Module returns.

Custom objects include synthetic members that represent each of the imported module members. For example, the cmdlets and functions in a module are converted to script
methods of the custom object.

Custom objects are very useful in scripting. They are also useful when several imported objects have the same names. Using the script method of an object is equivalent to
specifying the fully qualified name of an imported member, including its module name.

The AsCustomObject parameter can be used only when importing a script module, so the first task is to determine which of the available modules is a script module.

The first command uses the Get-Module cmdlet to get the available modules. The command uses a pipeline operator (|) to pass the module objects to the Format-Table cmdlet,
which lists the Name and ModuleType of each module in a table.

The second command uses the Import-Module cmdlet to import the PSDiagnostics script module. The command uses the AsCustomObject parameter to request a custom object and the
PassThru parameter to return the object. The command saves the resulting custom object in the $a variable.

The third command uses a pipeline operator to send the $a variable to the Get-Member cmdlet, which gets the properties and methods of the PSCustomObject in $a. The output
shows a Show-Calendar script method.

The last command uses the Show-Calendar script method. The method name must be enclosed in quotation marks, because it includes a hyphen.










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

PS C:\>Import-Module BitsTransfer
PS C:\>Import-Module BitsTransfer -force -Prefix PS



This example shows how to use the Force parameter of Import-Module when you are re-importing a module into the same session.

The first command imports the BitsTransfer module. The second command imports the module again, this time using the Prefix parameter.

The second command also includes the Force parameter, which removes the module and then imports it again. Without this parameter, the session would include two copies of
each BitsTransfer cmdlet, one with the standard name and one with the prefixed name.






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

PS C:\>Get-Date
Thursday, March 15, 2012 6:47:04 PM

PS C:\>Import-Module TestModule

PS C:\>Get-Date
12075

PS C:\>Get-Command Get-Date -All | Format-Table -Property CommandType, Name, ModuleName -AutoSize

CommandType Name ModuleName
----------- ---- ----------
Function Get-Date TestModule
Cmdlet Get-Date Microsoft.PowerShell.Utility

PS C:\>Microsoft.PowerShell.Utility\Get-Date
Saturday, September 12, 2009 6:33:23 PM



This example shows how to run commands that have been hidden by imported commands.

The first command run the Get-Date cmdlet. It returns a DateTime object with the current date.

The second command imports the TestModule module. This module includes a function named Get-Date that returns the year and day of the year.

The third command runs the Get-Date command again. Because functions take precedence over cmdlets, the Get-Date function from the TestModule module runs, instead of the
Get-Date cmdlet.

The fourth command uses the All parameter of the Get-Command to get all of the Get-Date commands in the session. The results show that there are two Get-Date commands in the
session, a function from the TestModule module and a cmdlet from the Microsoft.PowerShell.Utility module.

The fifth command runs the hidden cmdlet by qualifying the command name with the module name.

For more information about command precedence in Windows PowerShell, see about_Command_Precedence (http://go.microsoft.com/fwlink/?LinkID=113214).






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

PS C:\>Import-Module -Name PSWorkflow -MinimumVersion 3.0.0.0



This command imports the PSWorkflow module. It uses the MinimumVersion (alias=Version) parameter of Import-Module to import only version 3.0.0.0 or greater of the module.

You can also use the RequiredVersion parameter to import a particular version of a module, or use the Module and Version parameters of the #Requires keyword to require a
particular version of a module in a script.






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

The first command uses the New-PSSession cmdlet to create a remote session (PSSession) to the Server01 computer. The command saves the PSSession in the $s variable
PS C:\>$s = New-PSSession -ComputerName Server01

The second command uses the PSSession parameter of the Get-Module cmdlet to get the NetSecurity module in the session in the $s variable.This command is equivalent to using
the Invoke-Command cmdlet to run a Get-Module command in the session in $s (Invoke-Command $s {Get-Module -ListAvailable -Name NetSecurity).The output shows that the
NetSecurity module is installed on the computer and is available to the session in the $s variable.
PS C:\>Get-Module -PSSession $s -ListAvailable -Name NetSecurity
ModuleType Name ExportedCommands
---------- ---- ----------------
Manifest NetSecurity {New-NetIPsecAuthProposal, New-NetIPsecMainModeCryptoProposal, New-Ne...

The third command uses the PSSession parameter of the Import-Module cmdlet to import the NetSecurity module from the session in the $s variable into the current session.
PS C:\>Import-Module -PSSession $s -Name NetSecurity

The fourth command uses the Get-Command cmdlet to get commands that begin with "Get" and include "Firewall" from the Net-Security module.The output gets the commands and
confirms that the module and its cmdlets were imported into the current session.
PS C:\>Get-Command -Module NetSecurity -Name Get-*Firewall*
CommandType Name ModuleName
----------- ---- ----------
Function Get-NetFirewallAddressFilter NetSecurity
Function Get-NetFirewallApplicationFilter NetSecurity
Function Get-NetFirewallInterfaceFilter NetSecurity
Function Get-NetFirewallInterfaceTypeFilter NetSecurity
Function Get-NetFirewallPortFilter NetSecurity
Function Get-NetFirewallProfile NetSecurity
Function Get-NetFirewallRule NetSecurity
Function Get-NetFirewallSecurityFilter NetSecurity
Function Get-NetFirewallServiceFilter NetSecurity
Function Get-NetFirewallSetting NetSecurity

The fifth command uses the Get-NetFirewallRule cmdlet to get Windows Remote Management firewall rules on the Server01 computer. This command is equivalent to using the
Invoke-Command cmdlet to run a Get-NetFirewallRule command on the session in the $s variable (Invoke-Command -Session $s {Get-NetFirewallRule -DisplayName "Windows Remote
Management*"}).
PS C:\>Get-NetFirewallRule -DisplayName "Windows Remote Management*" | Format-Table -Property DisplayName, Name -AutoSize
DisplayName Name
----------- ----
Windows Remote Management (HTTP-In) WINRM-HTTP-In-TCP
Windows Remote Management (HTTP-In) WINRM-HTTP-In-TCP-PUBLIC
Windows Remote Management - Compatibility Mode (HTTP-In) WINRM-HTTP-Compat-In-TCP



This example shows how to use the Import-Module cmdlet to import a module from a remote computer. This command uses the Implicit Remoting feature of Windows PowerShell.

When you import modules from another session, you can use the cmdlets in the current session. However, commands that use the cmdlets actually run in the remote session.






-------------------------- EXAMPLE 11 --------------------------

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 the CIM session in the $cs variable to run an Import-Module command on the RSDGF03 computer. The command uses the Name parameter to specify the
Storage CIM module.
PS C:\>Import-Module -CimSession $cs -Name Storage

The third command runs the a Get-Command command 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 for each command 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



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.