Category Archives: Import

Import-Alias

NAME
    Import-Alias

SYNOPSIS
    Imports an Alias list from a file.

SYNTAX
    Import-Alias [-Path] <string> [-Force] [-PassThru] [-Scope <string>] [-Confirm] [-WhatIf] [<CommonParameters>]

DESCRIPTION
    The Import-Alias cmdlet imports an Alias list from a file.

PARAMETERS
    -Force [<SwitchParameter>]
        Allows the cmdlet to import an Alias that is already defined and is read only. You can use the following command to display information about the currently-defined Aliases:

        Get-Alias | Select-Object name,Options
        The value of the Options property will include “ReadOnly” if the corresponding Alias is read only.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -PassThru [<SwitchParameter>]
        Returns an object representing the Alias. By default, this cmdlet does not generate any output.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Path <string>
        Specifies the path to a file that includes exported Alias information. Wildcards are allowed but they must resolve to a single name.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue, ByPropertyName)
        Accept wildcard characters? false

    -Scope <string>
        Specifies the scope into which the Aliases are imported. Valid values are “Global”, “Local”, or “Script”, or a number relative to the current scope (0 through the number of scopes, where 0 is the current scope and 1 is its parent). “Local” is the default. For more information, see about_scopes.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Confirm [<SwitchParameter>]
        Prompts you for confirmation before executing the command.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -WhatIf [<SwitchParameter>]
        Describes what would happen if you executed the command without actually executing the command.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        “Get-Help about_CommonParameters“.

INPUTS
    System.String
        You can pipe a string that contains a path to Import-Alias.

OUTPUTS
    None or System.Management.Automation.AliasInfo
        When you use the Passthru parameter, Import-Alias returns a System.Management.Automation.AliasInfo object that represents the Alias. Otherwise, this cmdlet does not generate any output.

NOTES

    ————————– EXAMPLE 1 ————————–

    C:\PS>Import-Alias test.txt

    Description
    ———–
    This command imports Alias information from a file named test.txt.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113339
    Export-Alias
    Get-Alias
    New-Alias
    Set-Alias

Import-Clixml

NAME
    Import-Clixml

SYNOPSIS
    Imports a CLIXML file and creates corresponding objects within Windows PowerShell.

SYNTAX
    Import-Clixml [-Path] <string[]> [<CommonParameters>]

DESCRIPTION
    The Import-Clixml cmdlet imports a CLIXML file with data that represents Microsoft .NET Framework objects and creates the objects in Windows PowerShell.

PARAMETERS
    -Path <string[]>
        Specifies the location of the XML files to be converted into Windows PowerShell objects.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue, ByPropertyName)
        Accept wildcard characters? false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        “Get-Help about_CommonParameters“.

INPUTS
    System.String
        You can pipe a string that contains a path to Import-Clixml.

OUTPUTS
    PSObject
        Import-Clixml returns objects that have been deserialized from the stored XML files.

NOTES

        When specifying multiple values for a parameter, use commas to separate the values. For example, “<parameter-name> <value1>, <value2>”.

    ————————– EXAMPLE 1 ————————–

    C:\PS>Get-Process | Export-Clixml pi.xml

    C:\PS> $processes = Import-Clixml pi.xml

    Description
    ———–
    This command uses the Export-Clixml cmdlet to save a serialized copy of the process information returned by Get-Process. It then uses Import-Clixml to retrieve the contents of the serialized file and re-create an object that is stored in the $processes Variable.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113340

Import-Counter

NAME
    Import-Counter

SYNOPSIS
    Imports performance counter log files (.blg, .csv, .tsv) and creates the objects that represent each counter sample in the log.

SYNTAX
    Import-Counter [-Path] <string[]> [-Counter <string[]>] [-EndTime <DateTime>] [-MaxSamples <Int64>] [-StartTime <DateTime>] [<CommonParameters>]

    Import-Counter [-Path] <string[]> -ListSet <string[]> [<CommonParameters>]

    Import-Counter [-Path] <string[]> -Summary <switch> [<CommonParameters>]

DESCRIPTION
    The Import-Counter cmdlet imports performance counter data from performance counter log files and creates objects for each counter sample in the file. The PerformanceCounterSampleSet objects that it creates are identical to the objects that Get-Counter returns when it collects performance counter data.

    You can import data from comma-separated value (.csv), tab-separated value ( .tsv), and binary performance log (.blg) performance log files. If you are using .blg files, you can import multiple files (up to 32 different files) in each command. And, you can use the parameters of Import-Counter to filter the data that you import.

    Along with Get-Counter and Export-Counter, this feature lets you collect, export, import, combine, filter, manipulate, and re-export performance counter data within Windows PowerShell.

PARAMETERS
    -Counter <string[]>
        Imports data only for the specified performance counters. By default, Import-Counter imports all data from all counters in the input files. Enter one or more counter paths. Wildcards are permitted in the Instance part of the path.

        Each counter path has the following format. Notice that the ComputerName value is required in the path, even on the local computer.
             “\\<ComputerName>\<CounterSet>(<Instance>)\<CounterName>”

        For example:
                “\\Server01\Processor(2)\% User Time”
                “\Processor(*)\% Processor Time

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? true

    -EndTime <DateTime>
        Imports only counter data with a timestamp less than or equal to the specified date and time. Enter a DateTime object, such as one created by the Get-Date cmdlet. By default, Import-Counter imports all counter data in the files specified by the Path parameter.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -ListSet <string[]>
        Gets the performance counter sets that are represented in the exported files. Commands with this parameter do not import any data.

        Enter one or more counter set names. Wildcards are permitted. To get all counter sets in the file, type “Import-Counter -listset *”.

        Required?                    true
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? true

    -MaxSamples <Int64>
        Specifies the maximum number of samples of each counter to import. By default, Get-Counter imports all of the data in the files specified by the Path parameter.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Path <string[]>
        Specifies the file paths of the files to be imported. This parameter is required.

        Enter the path and file name of a, .csv,, .tsv, or .blg file that you exported by using the Export-Counter cmdlet. You can specify only one .csv or .tsv file, but you can specify multiple .blg files (up to 32) in each command. You can also pipe file path strings (in quotation marks) to Import-Counter.

        Required?                    true
        Position?                    2
        Default value
        Accept pipeline input?     true (ByValue)
        Accept wildcard characters? true

    -StartTime <DateTime>
        Imports only counter data with a timestamp greater than or equal to the specified date and time. Enter a DateTime object, such as one created by the Get-Date cmdlet. By default, Import-Counter imports all counter data in the files specified by the Path parameter.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Summary <switch>
        Gets a summary of the imported data, instead of getting individual counter data samples.

        Required?                    true
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        “Get-Help about_CommonParameters“.

INPUTS
    System.String
        You can pipe performance counter log paths to Import-Counter.

OUTPUTS
    Microsoft.PowerShell.Commands.GetCounter.PerformanceCounterSampleSet, Microsoft.PowerShell.Commands.GetCounter.CounterSet, Microsoft.PowerShell.Commands.GetCounter.CounterFileInfo
        By default, Import-Counter returns a Microsoft.PowerShell.Commands.GetCounter.PerformanceCounterSampleSet. If you use the ListSet parameter, Import-Command returns a Microsoft.PowerShell.Commands.GetCounter.CounterSet object. If you use the Summary parameter, Import-Command returns a Microsoft.PowerShell.Commands.GetCounter.CounterFileInfo object.

NOTES

        The Import-Counter cmdlet does not have a ComputerName parameter. However, if the computer is configured for Windows PowerShell remoting, you can use the Invoke-Command cmdlet to run an Import-Counter command on a remote computer.

    ————————– EXAMPLE 1 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This command imports all of the counter data from the ProcessorData.csv file into the $data Variable.

    C:\PS> $data = Import-Counter -Path ProcessorData.csv

    ————————– EXAMPLE 2 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This command imports only the Processor(_total)\Interrupts\sec counter data from the ProcessorData.blg file into the $i Variable.

    C:\PS> $i = Import-Counter -Path ProcessorData.blg -Counter “\\SERVER01\Processor(_Total)\Interrupts/sec”

    ————————– EXAMPLE 3 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This example shows how to select data from a performance counter log file (.blg) and then export the selected data to a .csv file.

    The first four commands get the counter paths from the file and save them in a Variable. The last two commands import selected data and then export only the selected data.

    The first command uses Import-Counter to import all of the performance counter data from the ProcessorData.blg files. The command saves the data in the $data Variable.

    C:\PS> $data = Import-Counter .\processordata.blg

    The second command displays the counter paths in the $data Variable. The display is shown in the command output.

    C:\PS> $data[0].countersamples | Format-Table path

    Path
    —-
    \\SERVER01\Processor(_Total)\DPC Rate
    \\SERVER01\Processor(1)\DPC Rate
    \\SERVER01\Processor(0)\DPC Rate
    \\SERVER01\Processor(_Total)\% Idle Time
    \\SERVER01\Processor(1)\% Idle Time
    \\SERVER01\Processor(0)\% Idle Time
    \\SERVER01\Processor(_Total)\% C3 Time
    \\SERVER01\Processor(1)\% C3 Time
    …

    The third command gets the counter paths that end in “Interrupts/sec” and saves the paths in the $IntCtrs Variable.

    C:\PS> $IntCtrs = $data[0].countersamples | where {$_.path -like “*interrupts/sec”} | foreach {$_.path}

    The fourth command displays the selected counter paths.

    C:\PS> $IntCtrs

    \\SERVER01\Processor(_Total)\Interrupts/sec
    \\SERVER01\Processor(1)\Interrupts/sec
    \\SERVER01\Processor(0)\Interrupts/sec

    The fifth command uses the Import-Counter cmdlet to import the data. It uses the Counter parameter with the $IntCtrs Variable to import only data for the counter paths in $IntCtrs.

    C:\PS> $i = Import-Counter -Path .\processordata.blg -Counter $intCtrs

    The sixth command uses the Export-Counter cmdlet to export the data.

    C:\PS> $i | Export-Counter -Path .\interrupts.csv -format CSV

    ————————– EXAMPLE 4 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This example shows how to display all the counter paths in a group of imported counter sets.

    The first command uses the ListSet parameter to get all of the counter sets that are represented in a counter data file.

    C:\PS> Import-Counter -Path processordata.csv -listset *

    CounterSetName     : Processor
    MachineName        : \\SERVER01
    CounterSetType     : MultiInstance
    Description        :
    Paths             : {\\SERVER01\Processor(*)\DPC Rate, \\SERVER01\Processor(*)\% Idle Time, \\SERVER01
                         \Processor(*)\% C3 Time, \\SERVER01\Processor(*)\% Interrupt Time…}
    PathsWithInstances : {\\SERVER01\Processor(_Total)\DPC Rate, \\SERVER01\Processor(1)\DPC Rate, \\SERVER01
                         \Processor(0)\DPC Rate, \\SERVER01\Processor(_Total)\% Idle Time…}
    Counter            : {\\SERVER01\Processor(*)\DPC Rate, \\SERVER01\Processor(*)\% Idle Time, \\SERVER01
                         \Processor(*)\% C3 Time, \\SERVER01\Processor(*)\% Interrupt Time…}

    The second command gets all of the counter paths from the list set.

    C:\PS> Import-Counter -Path processordata.csv -listset * | foreach {$_.paths}

    \\SERVER01\Processor(*)\DPC Rate
    \\SERVER01\Processor(*)\% Idle Time
    \\SERVER01\Processor(*)\% C3 Time
    \\SERVER01\Processor(*)\% Interrupt Time
    \\SERVER01\Processor(*)\% C2 Time
    \\SERVER01\Processor(*)\% User Time
    \\SERVER01\Processor(*)\% C1 Time
    \\SERVER01\Processor(*)\% Processor Time
    \\SERVER01\Processor(*)\C1 Transitions/sec
    \\SERVER01\Processor(*)\% DPC Time
    \\SERVER01\Processor(*)\C2 Transitions/sec
    \\SERVER01\Processor(*)\% Privileged Time
    \\SERVER01\Processor(*)\C3 Transitions/sec
    \\SERVER01\Processor(*)\DPCs Queued/sec
    \\SERVER01\Processor(*)\Interrupts/sec

    ————————– EXAMPLE 5 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This example imports only the counter data that has a time stamp between the starting an ending ranges specified in the command.

    The first command lists the time stamps of all of the data in the ProcessorData.blg file.

     C:\PS> Import-Counter -Path .\disk.blg | Format-Table timestamp

    The second and third commands save particular time stamps in the $start and $end Variables. The strings are cast to DateTime objects.

     C:\PS> $start = [datetime]”7/9/2008 3:47:00 PM”
     C:\PS> $end = [datetime]”7/9/2008 3:47:59 PM”

    The fourth command uses Import-Counter to get only counter data that has a time stamp between the start and end times (inclusive). The command uses the StartTime and EndTime parameters to specify the range.

     C:\PS> $t-data = Import-Counter -Path disk.blg -StartTime $start -EndTime $end

    ————————– EXAMPLE 6 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This example shows how to import the five oldest and five newest samples from a performance counter log file.

    The first command uses the Import-Counter cmdlet to import data from the Disk.blg file. The command uses the MaxSamples parameter to limit the import to five counter samples. This command gets the first (oldest) five samples in the file.

    C:\PS> Import-Counter -Path disk.blg -MaxSamples 5

    The second command uses array notation and the Windows PowerShell range operator (..) to get the last five counter samples from the file. These are the five newest samples.

    C:\PS> (Import-Counter -Path disk.blg)[-1 .. -5]

    ————————– EXAMPLE 7 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This command uses the Summary parameter to get a summary of the counter data from the Memory.blg file.

    C:\PS> Import-Counter D:\Samples\memory.blg -summary

    OldestRecord            NewestRecord            SampleCount
    ————            ————            ———–
    7/10/2008 2:59:18 PM    7/10/2008 3:00:27 PM    1000

    ————————– EXAMPLE 8 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This example updates a performance counter log file.

    The first command uses the ListSet parameter of Import-Counter to get the counters in OldData.blg, an existing counter log file. The command uses a pipeline operator (|) to send the data to a ForEach-Object command that gets only the values of the PathsWithInstances property of each object.

    C:\PS> $counters = Import-Counter olddata.blg -ListSet * | foreach {$_.PathsWithInstances}

    The second command uses those same counters in a new Get-Counter command to get a current sample, and export it to the NewData.blg file.

    C:\PS> Get-Counter -Counter $counters -MaxSamples 20 | Export-Counter c:\Logs\newdata.blg

    ————————– EXAMPLE 9 ————————–

    C:\PS># Import-Counter

    Description
    ———–
    This command imports performance log data from two logs and saves the data in the $counters Variable. The command uses a pipeline operator to send performance log paths to Import-Counter.

    C:\PS> $counters = “d:\test\pdata.blg”, “d:\samples\netlog.blg” | Import-Counter

    Notice that each path is enclosed in quotation marks and that the paths are separated from each other by a comma.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=138338
    Get-Counter
    Export-Counter

Import-Csv

NAME
    Import-Csv

SYNOPSIS
    Converts object properties in a comma-separated value (CSV) file into CSV versions of the original objects.

SYNTAX
    Import-Csv [[-Delimiter] <char>] [-Path] <string[]> [-Header <string[]>] [<CommonParameters>]

    Import-Csv -UseCulture [-Path] <string[]> [-Header <string[]>] [<CommonParameters>]

DESCRIPTION
    The Import-Csv cmdlet creates objects from CSV Variable-length files that are generated by the Export-Csv cmdlet.

    You can use the parameters of the Import-Csv cmdlet to specify the column header row, which determines the property names of the resulting objects; to specify the item delimiter; or to direct Import-Csv to use the list separator for the current culture as the item delimiter.

    The objects that Import-Csv creates are CSV versions of the original objects. The property values of the CSV objects are string versions of the property values of the original objects. The CSV versions of the objects do not have any methods.

    You can also use the ConvertTo-Csv and ConvertFrom-Csv cmdlets to convert objects to CSV strings (and back). These cmdlets are the same as the Export-Csv and Import-Csv cmdlets, except that they do not save the CSV strings in a file.

PARAMETERS
    -Delimiter <char>
        Specifies the delimiter that separates the property values in the CSV file. The default is a comma (,). Enter a character, such as a colon (:). To specify a semicolon (;), enclose it in quotation marks.

        If you specify a character other than the actual string delimiter in the file, Import-Csv cannot create objects from the CSV strings. Instead, it returns the strings.

        Required?                    false
        Position?                    2
        Default value                ,
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Header <string[]>
        Specifies an alternate column header row for the imported file. The column header determines the names of the properties of the object that Import-Csv creates.

        Enter a comma-separated list of the column headers. Enclose each item in quotation marks (single or double). Do not enclose the header string in quotation marks. If you enter fewer column headers than there are columns, the remaining columns will have no header. If you enter more headers than there are columns, the extra headers are ignored.

        When using the Header parameter, delete the original header row from the CSV file. Otherwise, Import-Csv creates an extra object from the items in the header row.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Path <string[]>
        Specifies the path to the CSV file to import. You can also pipe a path to Import-Csv.

        Required?                    true
        Position?                    1
        Default value                None
        Accept pipeline input?     true (ByValue, ByPropertyName)
        Accept wildcard characters? false

    -UseCulture [<SwitchParameter>]
        Use the list separator for the current culture as the item delimiter. The default is a comma (,).

        To find the list separator for a culture, use the following command: (Get-Culture).TextInfo.ListSeparator. If you specify a character other than the delimiter used in the CSV strings, ConvertFrom-Csv cannot create objects from the CSV strings. Instead, it returns the strings.

        Required?                    true
        Position?                    named
        Default value                Comma
        Accept pipeline input?     false
        Accept wildcard characters? false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        “Get-Help about_CommonParameters“.

INPUTS
    System.String
        You can pipe a string that contains a path to Import-Csv.

OUTPUTS
    Object.
        Import-Csv returns the objects described by the content in the CSV file.

NOTES

        Because the imported objects are CSV versions of the object type, they are not recognized and formatted by the Windows PowerShell type formatting entries that format the non-CSV versions of the object type.

        In the CSV file, each object is represented by a comma-separated list of the property values of the object. The property values are converted to strings (by using the ToString() method of the object), so they are generally represented by the name of the property value. Export-Csv does not export the methods of the object.

    ————————– EXAMPLE 1 ————————–

    C:\PS>Get-Process | Export-Csv processes.csv

    C:\PS> $p = Import-Csv processes.csv

    C:\PS> $p | Get-Member

     TypeName: CSV:System.Diagnostics.Process

    Name                     MemberType Definition
    —-                     ———- ———-
    Equals                     Method     System.Boolean Equals(Object obj)
    GetHashCode                Method     System.Int32 GetHashCode()
    GetType                    Method     System.Type GetType()
    ToString                 Method     System.String ToString()
    BasePriority             NoteProperty System.String BasePriority=8
    Company                    NoteProperty System.String Company=Microsoft Corporation
    …

    C:\PS> $p | Out-GridView

    Description
    ———–
    This example shows how to export and then import a CSV file of Microsoft .NET Framework objects.

    The first command uses the Get-Process cmdlet to get the process on the local computer. It uses a pipeline operator (|) to send the process objects to the Export-Csv cmdlet, which exports the process objects to the Processes.csv file in the current directory.

    The second command uses the Import-Csv cmdlet to import the processes in the Import-Csv file. Then it saves the resulting process objects in the $p Variable.

    The third command uses a pipeline operator to pipe the imported objects to the Get-Member cmdlets. The result shows that they are CSV:System.Diagnostic.Process objects, not the System.Diagnostic.Process objects that Get-Process returns.

    Also, because there is no entry type in the formatting files for the CSV version of the process objects, these objects are not formatted in the same way that standard process objects are formatted.

    To display the objects, use the formatting cmdlets, such as Format-Table and Format-List, or pipe the objects to Out-GridView.

    ————————– EXAMPLE 2 ————————–

    C:\PS>Get-Process | Export-Csv processes.csv -Delimiter :

    C:\PS> $p = Import-Csv processes.csv -Delimiter :

    Description
    ———–
    This example shows how to use the Delimiter parameter of Import-Csv. In this example, the processes are exported to a file that uses a colon (:) as a delimiter.

    When importing, the Import-Csv file uses the Delimiter parameter to indicate the delimiter that is used in the file.

    ————————– EXAMPLE 3 ————————–

    C:\PS>$p = Import-Csv processes.csv -UseCulture

    C:\PS> (Get-Culture).textinfo.listseparator

    ,

    Description
    ———–
    This example shows how to use the UseCulture parameter of Import-Csv.

    The first command imports the objects in the Processes.csv file into the $p Variable. It uses the UseCulture parameter to direct Import-Csv to use the list separator defined for the current culture.

    The second command displays the list separator for the current culture. It uses the Get-Culture cmdlet to get the current culture. It uses the dot (.) method to get the TextInfo property of the current culture and the ListSeparator property of the object in TextInfo. In this example, the command returns a comma.

    ————————– EXAMPLE 4 ————————–

    C:\PS>Start-Job -scriptblock { Get-Process } | Export-Csv jobs.csv

    C:\PS> $header = “MoreData”,”StatusMessage”,”Location”,”Command”,”State”,”Finished”,”InstanceId”,”SessionId”,”Name”,”ChildJobs”,”Output”,”Error”,”Progress”,”Verbose”,”Debug”,”Warning”,”StateChanged”

    # Delete header from file
    C:\PS> $a = (Get-Content jobs.csv)
    C:\PS> $a = $a[0], $a[2..($a.count – 1)]
    C:\PS> $a > jobs.csv

    C:\PS> $j = Import-Csv jobs.csv -Header $header

    C:\PS> $j

    MoreData     : True
    StatusMessage :
    Location     : localhost
    Command     : Get-Process
    State         : Running
    Finished     : System.Threading.ManualResetEvent
    InstanceId    : 135bdd25-40d6-4a20-bd68-05282a59abd6
    SessionId     : 1
    Name         : Job1
    ChildJobs     : System.Collections.Generic.List`1[System.Management.Automation.Job]
    Output        : System.Management.Automation.PSDataCollection`1[System.Management.Automation.PSObject]
    Error         : System.Management.Automation.PSDataCollection`1[System.Management.Automation.ErrorRecord]
    Progress     : System.Management.Automation.PSDataCollection`1[System.Management.Automation.ProgressRecord]
    Verbose     : System.Management.Automation.PSDataCollection`1[System.String]
    Debug         : System.Management.Automation.PSDataCollection`1[System.String]
    Warning     : System.Management.Automation.PSDataCollection`1[System.String]
    StateChanged :

    Description
    ———–
    This example shows how to use the Header parameter of Import-Csv to change the names of properties in the resulting imported object.

    The first command uses the Start-Job cmdlet to start a background job that runs a Get-Process command on the local computer. A pipeline operator (|) sends the resulting job object to the Export-Csv cmdlet, which converts the job object to CSV format. An assignment operator (=) saves the resulting CSV in the Jobs.csv file.

    The second command saves a header in the $header Variable. Unlike the default header, this header uses “MoreData” instead of “HasMoreData” and “State” instead of “JobStateInfo”.

    The next three commands delete the original header (the second line) from the Jobs.csv file.

    The sixth command uses the Import-Csv cmdlet to import the Jobs.csv file and convert the CSV strings into a CSV version of the job object. The command uses the Header parameter to submit the alternate header. The results are stored in the $j Variable.

    The seventh command displays the object in the $j Variable. The resulting object has “MoreData” and “State” properties, as shown in the command output.

    ————————– EXAMPLE 5 ————————–

    C:\PS>”.\processes.csv” | Import-Csv

    Description
    ———–
    This command imports the objects from the Processes.csv file.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113341
    Export-Csv
    ConvertTo-Csv
    ConvertFrom-Csv

Import-LocalizedData

NAME
    Import-LocalizedData

SYNOPSIS
    Imports language-specific data into scripts and Functions based on the UI culture that is selected for the operating system.

SYNTAX
    Import-LocalizedData [-BindingVariable] <string> [[-UICulture] <string>] [-BaseDirectory <string>] [-FileName <string>] [-SupportedCommand <string[]>] [<CommonParameters>]

DESCRIPTION
    The Import-LocalizedData cmdlet dynamically retrieves strings from a subdirectory whose name matches the UI language set for the current user of the operating system. It is designed to enable scripts to display user messages in the UI language selected by the current user.

    Import-LocalizedData imports data from .psd1 files in language-specific subdirectories of the script directory and saves them in a local Variable that is specified in the command. The cmdlet selects the subdirectory and file based on the value of the $PSUICulture automatic Variable. When you use the local Variable in the script to display a user message, the message appears in the user’s UI language.

    You can use the parameters of Import-LocalizedData to specify an alternate UI culture, path, and file name, to add supported commands, and to suppress the error message that appears if the .psd1 files are not found.

    The Import-LocalizedData cmdlet supports script internationalization in Windows PowerShell 2.0. This initiative aims to better serve users worldwide by making it easy for scripts to display user messages in the UI language of the current user. For more information about this and about the format of the .psd1 files, see about_script_internationalization.

PARAMETERS
    -BaseDirectory <string>
        Specifies the base directory where the .psd1 files are located. The default is the directory where the script is located. Import-LocalizedData searches for the .psd1 file for the script in a language-specific subdirectory of the base directory.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -BindingVariable <string>
        Specifies a Variable into which the text strings are imported. Enter a Variable name without a dollar sign ($).

        When using Import-LocalizedData to replace default text strings specified in the DATA section of a script, assign the DATA section to a Variable and enter the name of the DATA section Variable in the value of the BindingVariable parameter. Then, when Import-LocalizedData saves the imported content in the BindingVariable, the imported data will replace the default text strings. If you are not specifying default text strings, you can select any Variable name.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -FileName <string>
        Specifies the name of the .psd1 file to be imported. Enter a file name without the .psd1 file name extension.

        The default is the name of the script. For example, if the script is FindFiles.ps1, Import-LocalizedData searches for FindFiles.psd1. You can use this parameter to direct Import-LocalizedData to search for a different .psd1 file.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -SupportedCommand <string[]>
        Specifies cmdlets and Functions that generate only data.

        Use this parameter to include cmdlets and Functions that you have written or tested. For more information, see about_script_internationalization.

        Required?                    false
        Position?                    named
        Default value                None
        Accept pipeline input?     false
        Accept wildcard characters? false

    -UICulture <string>
        Specifies an alternate UI culture. The default is the value of the $PsUICulture automatic Variable. Enter a UI culture in “<language>-<region>” format, such as en-US, de-DE, or ar-SA.

        The value of the UICulture parameter determines the language-specific subdirectory (within the base directory) from which Import-LocalizedData gets the .psd1 file for the script.

        The cmdlet searches for a subdirectory with the same name as the value of the UICulture parameter or the $PsUICulture automatic Variable, such as “de-DE” or “ar-SA”. If it cannot find the directory, or the directory does not contain a .psd1 file for the script, it searches for a subdirectory with the name of the language code, such as “de” or “ar”. If it cannot find the subdirectory or .psd1 file, the command fails and the data is displayed in the default language specified in the script.

        Required?                    false
        Position?                    2
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        “Get-Help about_CommonParameters“.

INPUTS
    None
        You cannot pipe input to this cmdlet.

OUTPUTS
    System.Collections.Hashtable
        Import-LocalizedData saves the hash table in the Variable that is specified by the value of the BindingVariable parameter.

NOTES

        Before using Import-LocalizedData, localize your user messages. Format the messages for each locale (UI culture) in a hash table of key/value pairs, and save the hash table in a file with the same name as the script and a .psd1 file name extension. Create a directory under the script directory for each supported UI culture, and then save the .psd1 file for each UI culture in the directory with the UI culture name.

        For example, localize your user messages for the de-DE locale and format them in a hash table. Save the hash table in a <ScriptName>.psd1 file. Then create a de-DE subdirectory under the script directory, and save the de-DE <ScriptName>.psd1 file in the de-DE subdirectory. Repeat this method for each locale that you support.

        Import-LocalizedData performs a structured search for the localized user messages for a script.

        Import-LocalizedData begins the search in the directory where the script file is located (or the value of the BaseDirectory parameter). It then searches within the base directory for a subdirectory with the same name as the value of the $PsUICulture Variable (or the value of the UICulture parameter), such as “de-DE” or “ar-SA”. Then, it searches in that subdirectory for a .psd1 file with the same name as the script (or the value of the FileName parameter).

        If Import-LocalizedData cannot find a subdirectory with the name of the UI culture, or the subdirectory does not contain a .psd1 file for the script, it searches for a .psd1 file for the script in a subdirectory with the name of the language code, such as “de” or “ar”. If it cannot find the subdirectory or .psd1 file, the command fails, the data is displayed in the default language in the script, and an error message is displayed explaining that the data could not be imported. To suppress the message and fail gracefully, use the ErrorAction common parameter with a value of SilentlyContinue.

        If Import-LocalizedData finds the subdirectory and the .psd1 file, it imports the hash table of user messages into the value of the BindingVariable parameter in the command. Then, when you display a message from the hash table in the Variable, the localized message is displayed.

        For more information, see about_script_internationalization.

    ————————– EXAMPLE 1 ————————–

    C:\PS>Import-LocalizedData -BindingVariable messages

    Description
    ———–
    This command imports text strings into the $messages Variable. It uses all of the default values for the cmdlet parameters.

    If the command is included in the Archives.ps1 script in the C:\test directory, and the value of the $PsUICulture automatic Variable is zh-CN, Import-LocalizedData imports the Archives.psd1 file in the C:\test\zh-CN directory.

    ————————– EXAMPLE 2 ————————–

    C:\PS>Import-LocalizedData -BindingVariable msgTbl -UICulture ar-SA -FileName Simple -BaseDirectory C:\Data\Localized

    Description
    ———–
    This command imports text strings into the $msgTbl Variable of a script.

    It uses the UICulture parameter to direct the cmdlet to import data from the Simple.psd1 file in the ar-SA subdirectory of C:\Data\Localized.

    ————————– EXAMPLE 3 ————————–

    C:\PS># In C:\Test\en-US\test.psd1:

    ConvertFrom-StringData @’
     # English strings
    Msg1 = “The Name parameter is missing from the command.”
    Msg2 = “This command requires the credentials of a member of the Administrators group on the computer.”
    Msg3 = “Use $_ to represent the object that is being processed.”
    ‘@

    # In C:\Test\Test.ps1

    Import-LocalizedData -BindingVariable messages
    Write-Host $messages.msg2

    # In Windows PowerShell

    C:\PS> .\test.ps1
    This command requires the credentials of a member of the Administrators group on the computer.

    Description
    ———–
    This example shows how to use localized data in a simple script.

    The first part of the example shows the contents of the Test.psd1 file. It contains a ConvertFrom-StringData command that converts a series of named text strings into a hash table. The test.psd1 file is located in the en-US subdirectory of the C:\Test directory that contains the script.

    The second part of the example shows the contents of the Test.ps1 script. It contains an Import-LocalizedData command that imports the data from the matching .psd1 file into the $Messages Variable and a Write-Host command that writes one of the messages in the $Messages Variable to the host program.

    The last part of the example runs the script. The output shows that it displays the correct user message in the UI language set for the current user of the operating system.

    ————————– EXAMPLE 4 ————————–

    C:\PS># In TestScript.ps1

    $UserMessages = DATA {
        ConvertFrom-StringData @’
        # English strings
            Msg1 = “Enter a name.”
            Msg2 = “Enter your employee ID.”
            Msg3 = “Enter your building number.”
    ‘@ }

    Import-LocalizedData -BindingVariable UserMessages

    $UserMessages.Msg1
    …

    Description
    ———–
    This example shows how to use Import-LocalizedData to replace default text strings defined in the DATA section of a script.

    In this example, the DATA section of the TestScript.ps1 script contains a ConvertFrom-StringData command that converts the contents of the DATA section to a hash table and stores in the value of the $UserMessages Variable.

    The script also includes an Import-LocalizedData command, which imports a hash table of translated text strings from the TestScript.psd1 file in the subdirectory specified by the value of the $PsUICulture Variable. If the command finds the .psd1 file, it saves the translated strings from the file in the value of the same $UserMessages Variable, overwriting the hash table saved by the DATA section logic.

    The third command displays the first message in the $UserMessages Variable.

    If the Import-LocalizedData command finds a .psd1 file for the $PsUICulture language, the value of the $UserMessages Variable contains the translated text strings. If the command fails for any reason, the command displays the default text strings defined in the DATA section of the script.

    ————————– EXAMPLE 5 ————————–

    C:\PS># In Day1.ps1
    Import-LocalizedData -BindingVariable Day
    Day.MessageDate

    # In Day2.ps1
    Import-LocalizedData -BindingVariable Day -ErrorAction:silentlycontinue
    Day.MessageDate

    C:\PS> .\Day1.ps1

    Import-LocalizedData : Cannot find PowerShell data file ‘Day1.psd1’ in directory ‘C:\ps-test\fr-BE\’ or any parent culture directories.
    At C:\ps-test\Day1.ps1:17 char:21
    + Import-LocalizedData <<<< Day
    Today is Tuesday

    C:\PS> .\Day2.ps1

    Today is Tuesday

    Description
    ———–
    This example shows how to suppress the error messages that appear when Import-LocalizedData cannot find the directories that match the user’s UI culture or cannot find a .psd1 file for the script in those directories.

    You can use the ErrorAction common parameter with a value of “SilentlyContinue” to suppress the error message. This is especially useful when you have provided user messages in a default or “fallback” language, and no error message is needed.

    This example compares two scripts, Day1.ps1 and Day2.ps1, that include an Import-LocalizedData command. The scripts are identical, except that Day2 uses the ErrorAction common parameter with a value of SilentlyContinue.

    The sample output shows the results of running both scripts when the UI culture is set to fr-BE and there are no matching files or directories for that UI culture. Day1.ps1 displays an error message and English output. Day2.ps1 just displays the English output.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113342
    about_script_internationalization

Import-Module

NAME
    Import-Module

SYNOPSIS
    Adds modules to the current session.

SYNTAX
    Import-Module [-Name] <string[]> [-Alias <string[]>] [-ArgumentList <Object[]>] [-AsCustomObject] [-Cmdlet <string[]>] [-Force] [-Function <string[]>] [-Global] [-PassThru] [-Prefix <string>] [-Variable <string[]>] [-Version <Version>] [<CommonParameters>]

    Import-Module [-Assembly] <Assembly[]> [-Alias <string[]>] [-ArgumentList <Object[]>] [-AsCustomObject] [-Cmdlet <string[]>] [-Force] [-Function <string[]>] [-Global] [-PassThru] [-Prefix <string>] [-Variable <string[]>] [-Version <Version>] [<CommonParameters>]

    Import-Module [-ModuleInfo] <PSModuleInfo[]> [-Alias <string[]>] [-ArgumentList <Object[]>] [-AsCustomObject] [-Cmdlet <string[]>] [-Force] [-Function <string[]>] [-Global] [-PassThru] [-Prefix <string>] [-Variable <string[]>] [-Version <Version>] [<CommonParameters>]

DESCRIPTION
    The Import-Module cmdlet adds one or more modules to the current session.

    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, or ModuleInfo parameter 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.

    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.

    For more information about modules, see about_modules.

PARAMETERS
    -Alias <string[]>
        Imports only the specified Aliases from the module into the current session. Enter a comma-separated list of Aliases. Wildcard characters are permitted.

        Some modules automatically export selected Aliases into your session when you import the module. This parameter lets you select from among the exported Aliases.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? true

    -ArgumentList <Object[]>
        Specifies arguments (parameter values) that are passed to a script module during the Import-Module command. This parameter is valid only when you are importing a script module.

        You can also refer to ArgumentList by its Alias, “args”. For more information, see about_aliases.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -AsCustomObject [<SwitchParameter>]
        Returns a custom object with members that represent the imported module members. This parameter is valid only for script modules.

        When you use the AsCustomObject parameter, Import-Module imports the module members into the session and then returns a PSCustomObject object instead of a PSModuleInfo object. You can save the custom object in a Variable and use dot notation to invoke the members.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Assembly <Assembly[]>
        Imports the cmdlets and providers implemented in the specified assembly objects. Enter a Variable that contains assembly objects or a command that creates assembly objects. You can also pipe an assembly object to Import-Module.

        When you use this parameter, only the cmdlets and providers implemented by the specified assemblies are imported. If the module contains other files, they are not imported, and you might be missing important members of the module. Use this parameter for debugging and testing the module, or when you are instructed to use it by the module author.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue)
        Accept wildcard characters? false

    -Cmdlet <string[]>
        Imports only the specified cmdlets from the module into the current session. Enter a list of cmdlets. Wildcard characters are permitted.

        Some modules automatically export selected cmdlets into your session when you import the module. This parameter lets you select from among the exported cmdlets.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? true

    -Force [<SwitchParameter>]
        Re-imports a module and its members, even if the module or its members have an access mode of read-only.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Function <string[]>
        Imports only the specified Functions from the module into the current session. Enter a list of Functions. Wildcard characters are permitted.

        Some modules automatically export selected Functions into your session when you import the module. This parameter lets you select from among the exported Functions.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? true

    -Global [<SwitchParameter>]
        When used in a script module (.psm1), this parameter imports modules into the global session state.

        This parameter is effective only when it appears in a script module. Otherwise, it is ignored.

        By default, the commands in a script module, including commands from nested modules, are imported into the caller’s session state. To restrict the commands that a module exports, use an Export-ModuleMember command in the script module.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -ModuleInfo <PSModuleInfo[]>
        Specifies module objects to import. Enter a Variable that contains the module objects, or a command that gets the module objects, such as a “Get-Module -listavailable” command. You can also pipe module objects to Import-Module.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue)
        Accept wildcard characters? false

    -Name <string[]>
        Specifies the names of the modules to import. Enter the name of the module or the name of a file in the module, such as a .psd1, .psm1, .dll, or ps1 file. File paths are optional. Wildcards are not permitted. You can also pipe module names and file names to Import-Module.

        If you omit a path, Import-Module looks for the module in the paths saved in the PSModulePath Environment Variable ($env:PSModulePath).

        Specify only the module name whenever possible. When you specify a file name, only the members that are implemented in that file are imported. If the module contains other files, they are not imported, and you might be missing important members of the module.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue)
        Accept wildcard characters? false

    -PassThru [<SwitchParameter>]
        Returns objects that represent the modules that were imported. By default, this cmdlet does not generate any output.

        Notes
        — When you pipe the output of a “Get-Module -listavailable” command to an Import-Module command with the PassThru parameter, Import-Module returns the object that Get-Module passed to it without updating the object. As a result, the Exported and NestedModules properties are not yet populated.

        — When you use the Prefix parameter to specify a prefix for the member, the prefix does not appear in the member names in the properties of the module object. The object records what was exported before the prefix was applied.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Prefix <string>
        Adds the specified prefix to the nouns in the names of imported module members.

        Use this parameter to avoid name conflicts that might occur when different members in the session have the same name. This parameter does not change the module, and it does not affect files that the module imports for its own use (known as “nested modules”). It affects only the names of members in the current session.

        For example, if you specify the prefix “UTC” and then import a Get-Date cmdlet, the cmdlet is known in the session as Get-UTCDate, and it is not confused with the original Get-Date cmdlet.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Variable <string[]>
        Imports only the specified Variables from the module into the current session. Enter a list of Variables. Wildcard characters are permitted.

        Some modules automatically export selected Variables into your session when you import the module. This parameter lets you select from among the exported Variables.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? true

    -Version <Version>
        Specifies the version of the module to import. Use this parameter when you have different versions of the same module on your system.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        “Get-Help about_CommonParameters“.

INPUTS
    System.String, System.Management.Automation.PSModuleInfo, System.Reflection.Assembly
        You can pipe a module name, module object, or assembly object to Import-Module.

OUTPUTS
    None, System.Management.Automation.PSModuleInfo, or System.Management.Automation.PSCustomObject
        By default, Import-Module does not generate any output. If you use the PassThru parameter, it generates a System.Management.Automation.PSModuleInfo object that represents the module. If you use the AsCustomObject parameter, it generates a PSCustomObject object.

NOTES

        You can also refer to Import-Module by its Alias, “ipmo”. For more information, see about_aliases.

        Before you can import a module, the module directory must be copied to a directory that is accessible to your local computer. For more information, see about_modules.

        Module members run in their own private module session state, so the commands that they use for internal processing do not affect your session state.

        If you import members with the same name and the same type into your session, Windows PowerShell uses the member imported last by default. Variables and Aliases are replaced, and the originals are not accessible. Functions, cmdlets and providers are merely “shadowed” by the new members, and they can be accessed by qualifying the command name with the name of its snap-in, module, or Function path.

        To update the formatting data for commands that have been imported from a module, use the Update-FormatData cmdlet. Update-FormatData also updates the formatting data for commands in the session that were imported from modules. If the formatting file for a module changes, you can run an Update-FormatData command to update the formatting data for imported commands. You do not need to import the module again.

        To import a module that is created by Import-PSSession or Export-PSSession, the execution policy in the current session cannot be Restricted or AllSigned, because the modules that Import-PSSession and Export-PSSession create contains unsigned script files that are prohibited by these policies. To use Import-Module without changing the execution policy for the local computer, use the Scope parameter of Set-ExecutionPolicy to set a less restrictive execution policy for a single process.

    ————————– EXAMPLE 1 ————————–

    C:\PS>Import-Module -Name BitsTransfer

    Description
    ———–
    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 ————————–

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

    Description
    ———–
    This command imports all available modules in the path specified by the PSModulePath Environment Variable ($env:psmodulepath) into the current session.

    ————————– EXAMPLE 3 ————————–

    C:\PS>$m = Get-Module -ListAvailable BitsTransfer, ServerBackup

    C:\PS> Import-Module -moduleInfo $m

    Description
    ———–
    These commands import the members of the BitsTransfer and ServerBackup modules into the current session.

    The first command uses the Get-Module cmdlet to get PSModuleInfo objects that represent the BitsTransfer and ServerBackup 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 ————————–

    C:\PS>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-parm’.
    VERBOSE: Exporting Function ‘get-spec’.
    VERBOSE: Exporting Function ‘get-specDetails’.

    Description
    ———–
    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 ————————–

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

    C:\PS> 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], [Rem
                        ove-BitsTransfer, Remove-BitsTransfer]…}
    ExportedFunctions : {}
    ExportedVariables : {}
    NestedModules     : {Microsoft.BackgroundIntelligentTransfer.Management}

    C:\PS> Get-Command -module BitsTransfer

    CommandType Name                Definition
    ———– —-                ———-
    Cmdlet     Add-BitsTransfer    Add-BitsTransfer [-BitsJob] <BitsJob[]> [-Source] <String[]> [[-Destination] <String[]>] [-Verbose] [-Debug] [-ErrorA…
    Cmdlet     Get-BitsTransfer    Get-BitsTransfer [[-Name] <String[]>] [-AllUsers] [-Verbose] [-Debug] [-ErrorAction <ActionPreference>] [-WarningActi…

    Description
    ———–
    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 ————————–

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

    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], [Remove-BitsTransfer, Remove-BitsTransfer], [Complete-BitsTransfer, Complete-BitsTransfer]
                        , [Get-BitsTransfer, Get-BitsTransfer]…}
    ExportedFunctions : {}
    ExportedVariables : {}
    NestedModules     : {Microsoft.BackgroundIntelligentTransfer.Management}

    C:\PS> Get-Command -module bitstransfer

    CommandType     Name                        Definition
    ———–     —-                        ———-
    Cmdlet         Add-PSBitsTransfer         Add-PSBitsTransfer [-BitsJob] <BitsJob[]> [-Source] <String[]> …
    Cmdlet         Complete-PSBitsTransfer     Complete-PSBitsTransfer [-BitsJob] <BitsJob[]> [-Verbose] [-Deb…
    Cmdlet         Get-PSBitsTransfer         Get-PSBitsTransfer [[-Name] <String[]>] [-AllUsers] [-Verbose] …
    Cmdlet         Remove-PSBitsTransfer     Remove-PSBitsTransfer [-BitsJob] <BitsJob[]> [-Verbose] [-Debug
    Cmdlet         Resume-PSBitsTransfer     Resume-PSBitsTransfer [-BitsJob] <BitsJob[]> [-Asynchronous] [-…
    Cmdlet         Set-PSBitsTransfer         Set-PSBitsTransfer [-BitsJob] <BitsJob[]> [-DisplayName <String…
    Cmdlet         Start-PSBitsTransfer        Start-PSBitsTransfer [[-Source] <String[]>] [[-Destination] <St…
    Cmdlet         Suspend-PSBitsTransfer     Suspend-PSBitsTransfer [-BitsJob] <BitsJob[]> [-Verbose] [-Debu…

    Description
    ———–
    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 module object that the command returns has an ExportedCmdlets property that lists the exported members. The prefix does not appear in the cmdlet names, because it is applied after the members are exported (but before they are imported).

    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 ————————–

    C:\PS>Get-Module -list | Format-Table -property name, moduletype -auto

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

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

    C:\PS> $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();

    C:\PS> $a.”show-calendar”()

    Description
    ———–
    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 with 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 Show-Calendar script module. The command uses the AsCustomObject parameter to request a custom 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 ————————–

    C:\PS>Import-Module BitsTransfer

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

    Description
    ———–
    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 ————————–

    C:\PS>Get-Date

    Saturday, September 12, 2009 6:47:04 PM

    C:\PS> Import-Module TestModule

    C:\PS> Get-Date
    09255

    C:\PS> Get-Command Get-Date | Format-Table -property commandtype, name, pssnapin, module -auto

    CommandType Name     pssnapin                     Module
    ———– —-     ——–                     ——
     Function Get-Date                                 TestModule
         Cmdlet Get-Date Microsoft.PowerShell.Utility

    C:\PS> Microsoft.PowerShell.Utility\Get-Date

    Saturday, September 12, 2009 6:33:23 PM

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

    The first command run the Get-Date cmdlet that comes with Windows PowerShell. 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 Julian date.

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

    The fourth command shows that there are two Get-Date commands in the session, a Function from the TestModule module and a cmdlet from the Microsoft.PowerShell.Utility snap-in.

    The fifth command runs the hidden cmdlet by qualifying the command name with the snap-in name.

    For more information about command precedence in Windows PowerShell, see about_command_precedence.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=141553
    Get-Module
    New-Module
    Remove-Module
    Export-ModuleMember
    about_modules

Import-PSSession

NAME
    Import-PSSession

SYNOPSIS
    Imports commands from another session into the current session.

SYNTAX
    Import-PSSession [-Session] <PSSession> [[-CommandName] <string[]>] [[-FormatTypeName] <string[]>] [-AllowClobber] [-ArgumentList <Object[]>] [-CommandType {Alias | Function | Filter | Cmdlet | ExternalScript | Application | Script | All}] [-Module <string[]>] [-Prefix <string>] [<CommonParameters>]

DESCRIPTION
    The Import-PSSession cmdlet imports commands (such as cmdlets, Functions, and Aliases) from a PSSession on a local or remote computer into the current session. You can import any command that Get-Command can find in the PSSession.

    Use an Import-PSSession command to import commands from a customized shell, such as a Microsoft Exchange Server shell, or from a session that includes Windows PowerShell modules and snap-ins or other elements that are not in the current session.

    To import commands, first use the New-PSSession cmdlet to create a PSSession. Then, use the Import-PSSession cmdlet to import the commands. By default, Import-PSSession imports all commands except for commands that have the same names as commands in the current session. To import all the commands, use the AllowClobber parameter.

    You can use imported commands just as you would use any command in the session. When you use an imported command, the imported part of the command runs implicitly in the session from which it was imported. However, the remote operations are handled entirely by Windows PowerShell. You need not even be aware of them, except that you must keep the connection to the other session (PSSession) open. If you close it, the imported commands are no longer available.

    Because imported commands might take longer to run than local commands, Import-PSSession adds an AsJob parameter to every imported command. This parameter allows you to run the command as a Windows PowerShell background job. For more information, see about_jobs.

    When you use Import-PSSession, Windows PowerShell adds the imported commands to a temporary module that exists only in your session and returns an object that represents the module. To create a persistent module that you can use in future sessions, use the Export-PSSession cmdlet.

    The Import-PSSession cmdlet uses the implicit remoting feature of Windows PowerShell. When you import commands into the current session, they run implicitly in the original session or in a similar session on the originating computer.

PARAMETERS
    -AllowClobber [<SwitchParameter>]
        Imports the specified commands, even if they have the same names as commands in the current session.

        If you import a command with the same name as a command in the current session, the imported command hides or replaces the original commands. For more information, see about_command_precedence.

        By default, Import-PSSession does not import commands that have the same name as commands in the current session.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?     false
        Accept wildcard characters? false

    -ArgumentList <Object[]>
        Imports the variant of the command that results from using the specified arguments (parameter values).

        For example, to import the variant of the Get-Item command in the Certificate (Cert:) drive in the PSSession in $s, type “Import-PSSession -Session $s -command Get-Item -ArgumentList cert:”.

        Required?                    false
        Position?                    named
        Default value                All command in the PSSession, except for commands with the same names as commands in the current session.
        Accept pipeline input?     false
        Accept wildcard characters? false

    -CommandName <string[]>
        Imports only the commands with the specified names or name patterns. Wildcards are permitted. Use “CommandName” or its Alias, “Name”.

        By default, Import-PSSession imports all commands from the session, except for commands that have the same names as commands in the current session. This prevents imported commands from hiding or replacing commands in the session. To import all commands, even those that hide or replace other commands, use the AllowClobber parameter.

        If you use the CommandName parameter, the formatting files for the commands are not imported unless you use the FormatTypeName parameter. Similarly, if you use the FormatTypeName parameter, no commands are imported unless you use the CommandName parameter.

        Required?                    false
        Position?                    3
        Default value                All commands in the PSSession, except for commands with the same names as commands in the current session.
        Accept pipeline input?     false
        Accept wildcard characters? true

    -CommandType <CommandTypes>
        Imports only the specified types of command objects. The default value is Cmdlet. Use “CommandType” or its Alias, “Type”.

        Valid values are:
        — Alias: The Windows PowerShell Aliases in the remote session.
        — All: The cmdlets and Functions in the remote session.
        — Application: All the files other than Windows-PowerShell files in the paths that are listed in the Path Environment Variable ($env:path) in the remote session, including .txt, .exe, and .dll files.
        — Cmdlet: The cmdlets in the remote session. “Cmdlet” is the default.
        — ExternalScript: The .ps1 files in the paths listed in the Path Environment Variable ($env:path) in the remote session.
        — Filter and Function: The Windows PowerShell Functions in the remote session.
        — Script: The script blocks in the remote session.

        Required?                    false
        Position?                    named
        Default value                All command in the PSSession, except for commands with the same names as commands in the current session.
        Accept pipeline input?     false
        Accept wildcard characters? false

    -FormatTypeName <string[]>
        Imports formatting instructions for the specified Microsoft .NET Framework types. Enter the type names. Wildcards are permitted.

        The value of this parameter must be the name of a type that is returned by a Get-FormatData command in the session from which the commands are being imported. To get all of the formatting data in the remote session, type *.

        If the command does not include either the CommandName or FormatTypeName parameters, Import-PSSession
        imports formatting instructions for all .NET Framework types returned by a Get-FormatData command in the remote session.

        If you use the FormatTypeName parameter, no commands are imported unless you use the CommandName parameter.
        Similarly, if you use the CommandName parameter, the formatting files for the commands are not imported unless you use the FormatTypeName parameter.

        Required?                    false
        Position?                    4
        Default value                Types in the System.Management.Automation namespace
        Accept pipeline input?     false
        Accept wildcard characters? true

    -Module <string[]>
        Imports only the commands in the specified Windows PowerShell snap-ins and modules. Enter the snap-in and module names. Wildcards are not permitted.

        For more information, see about_PSSnapins and Import-Module.

        Required?                    false
        Position?                    named
        Default value                All command in the PSSession, except for commands with the same names as commands in the current session.
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Prefix <string>
        Adds the specified prefix to the nouns in the names of imported commands.

        Use this parameter to avoid name conflicts that might occur when different commands in the session have the same name.
        For example, if you specify the prefix “Remote” and then import a Get-Date cmdlet, the cmdlet is known in the session as Get-RemoteDate and it is not confused with the original Get-Date cmdlet.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Session <PSSession>
        Specifies the PSSession from which the cmdlets are imported. Enter a Variable that contains a session object or a command that gets a session object, such as a New-PSSession or Get-PSSession command. You can specify only one session. This parameter is required.

        Required?                    true
        Position?                    1
        Default value                None
        Accept pipeline input?     false
        Accept wildcard characters? false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        “Get-Help about_CommonParameters“.

INPUTS
    None
        You cannot pipe objects to this cmdlet.

OUTPUTS
    System.Management.Automation.PSModuleInfo
        Import-PSSession returns the same module object that New-Module and Get-Module return. However, the imported module is temporary and exists only in the current session. To create a permanent module on disk, use the Export-PSSession cmdlet.

NOTES

        Import-PSSession relies on the Windows PowerShell remoting infrastructure. To use this cmdlet, the computer must be configured for WS-Management remoting. For more information, see about_remote and about_remote_requirements.

        You cannot use Import-PSSession to import Variables or Windows PowerShell providers.

        When you import commands that have the same names as commands in the current session, the imported commands can hide Aliases, Functions, and cmdlets in the session and they can replace Functions and Variables in the session. For more information, see about_command_precedence.

        Import-PSSession converts all commands into Functions before it imports them. As a result, imported commands behave a bit differently than they would if they retained their original command type. For example, if you import a cmdlet from a PSSession and then import a cmdlet with the same name from a module or snap-in, the cmdlet that is imported from the PSSession always runs by default because Functions take precedence over cmdlets. Conversely, if you import an Alias into a session that has an Alias with the same name, the original Alias is always used, because Aliases take precedence over Functions. For more information, see about_command_precedence.

        Import-PSSession uses the Write-Progress cmdlet to display the progress of the command. You might see the progress bar while the command is running.

        To find the commands to import, Import-PSSession uses the Invoke-Command cmdlet to run a Get-Command command in the PSSession. To get formatting data for the commands, it uses the Get-FormatData cmdlet. You might see error messages from Invoke-Command, Get-Command, and Get-FormatData when you run an Import-PSSession command. Also, Import-PSSession cannot import commands from a PSSession that does not include the Get-Command, Get-FormatData, Select-Object, and Get-Help cmdlets.

        Imported commands have the same limitations as other remote commands, including the inability to start a program with a user interface, such as Notepad.

        Because Windows PowerShell profiles are not run in PSSessions, the commands that a profile adds to a session are not available to Import-PSSession. To import commands from a profile, use an Invoke-Command command to run the profile in the PSSession manually before importing commands.

        The temporary module that Import-PSSession creates might include a formatting file, even if the command does not import formatting data. If the command does not import formatting data, any formatting files that are created will not contain formatting data.

        To use Import-PSSession, the execution policy in the current session cannot be Restricted or AllSigned, because the module that Import-PSSession creates contains unsigned script files that are prohibited by these policies. To use Import-PSSession without changing the execution policy for the local computer, use the Scope parameter of Set-ExecutionPolicy to set a less restrictive execution policy for a single process.

    ————————– EXAMPLE 1 ————————–

    C:\PS>$s = New-PSSession -computername Server01

    C:\PS> Import-PSSession -Session $s

    Description
    ———–
    This command imports all commands from a PSSession on the Server01 computer into the current session, except for commands that have the same names as commands in the current session.

    Because this command does not use the CommandName parameter, it also imports all of the formatting data required for the imported commands.

    ————————– EXAMPLE 2 ————————–

    C:\PS>$s = New-PSSession https://ps.testlabs.com/powershell

    C:\PS> Import-PSSession -Session $s -CommandName *-test -FormatTypeName *

    C:\PS> new-test -name test1

    C:\PS> get-test test1 | run-test

    Description
    ———–
    These commands import the commands with names that end in “-test” from a PSSession into the local session, and then they show how to use an imported cmdlet.

    The first command uses the New-PSSession cmdlet to create a PSSession. It saves the PSSession in the $s Variable.

    The second command uses the Import-PSSession cmdlet to import commands from the PSSession in $s into the current session. It uses the CommandName parameter to specify commands with the Test noun and the FormatTypeName parameter to import the formatting data for the Test commands.

    The third and fourth commands use the imported commands in the current session. Because imported commands are actually added to the current session, you use the local syntax to run them. You do not need to use the Invoke-Command cmdlet to run an imported command.

    ————————– EXAMPLE 3 ————————–

    C:\PS>$s1 = New-PSSession -computername s1

    C:\PS> $s2 = New-PSSession -computername s2

    C:\PS> Import-PSSession -Session s1 -type cmdlet -name New-Test, Get-Test -FormatTypeName *

    C:\PS> Import-PSSession -Session s2 -type cmdlet -name Set-Test -FormatTypeName *

    C:\PS> new-test Test1 | set-test -runtype full

    Description
    ———–
    This example shows that you can use imported cmdlets just as you would use local cmdlets.

    These commands import the New-Test and Get-Test cmdlets from a PSSession on the Server01 computer and the Set-Test cmdlet from a PSSession on the Server02 computer.

    Even though the cmdlets were imported from different PSSessions, you can pipe an object from one cmdlet to another without error.

    ————————– EXAMPLE 4 ————————–

    C:\PS>$s = New-PSSession -computername Server01

    C:\PS> Import-PSSession -Session $s -CommandName *-test* -FormatTypeName *

    C:\PS> $batch = new-test -name Batch -asjob

    C:\PS> Receive-Job $batch

    Description
    ———–
    This example shows how to run an imported command as a background job.

    Because imported commands might take longer to run than local commands, Import-PSSession adds an AsJob parameter to every imported command. The AsJob parameter lets you run the command as a background job.

    The first command creates a PSSession on the Server01 computer and saves the PSSession object in the $s Variable.

    The second command uses Import-PSSession to import the Test cmdlets from the PSSession in $s into the current session.

    The third command uses the AsJob parameter of the imported New-Test cmdlet to run a New-Test command as a background job. The command saves the job object that New-Test returns in the $batch Variable.

    The fourth command uses the Receive-Job cmdlet to get the results of the job in the $batch Variable.

    ————————– EXAMPLE 5 ————————–

    C:\PS>$s = New-PSSession -comp Server01

    C:\PS> Invoke-Command -Session $s {Import-Module TestManagement}

    C:\PS> Import-PSSession -Session $s -Module TestManagement

    Description
    ———–
    This example shows how to import the cmdlets and Functions from a Windows PowerShell module on a remote computer into the current session.

    The first command creates a PSSession on the Server01 computer and saves it in the $s Variable.

    The second command uses the Invoke-Command cmdlet to run an Import-Module command in the PSSession in $s.

    Typically, the module would be added to all sessions by an Import-Module command in a Windows PowerShell profile, but profiles are not run in PSSessions.

    The third command uses the Module parameter of Import-PSSession to import the cmdlets and Functions in the module into the current session.

    ————————– EXAMPLE 6 ————————–

    C:\PS>Import-PSSession $s -CommandName Get-Date, SearchHelp -FormatTypeName * -AllowClobber

    Name             : tmp_79468106-4e1d-4d90-af97-1154f9317239_tcw1zunz.ttf
    Path             : C:\Users\User01\AppData\Local\Temp\tmp_79468106-4e1d-4d90-af97-1154f9317239_tcw1zunz.ttf\tmp_79468106-4e1d-4d90-af97-1154f9317239_
                        tcw1zunz.ttf.psm1
    Description     : Implicit remoting for http://server01.corp.fabrikam.com/wsman
    Guid             : 79468106-4e1d-4d90-af97-1154f9317239
    Version         : 1.0
    ModuleBase        : C:\Users\User01\AppData\Local\Temp\tmp_79468106-4e1d-4d90-af97-1154f9317239_tcw1zunz.ttf
    ModuleType        : Script
    PrivateData     : {ImplicitRemoting}
    AccessMode        : ReadWrite
    ExportedAliases : {}
    ExportedCmdlets : {}
    ExportedFunctions : {[Get-Date, Get-Date], [SearchHelp, SearchHelp]}
    ExportedVariables : {}
    NestedModules     : {}

    Description
    ———–
    This example shows that Import-PSSession creates a module in a temporary file on disk. It also shows that all commands are converted into Functions before they are imported into the current session.

    The command uses the Import-PSSession cmdlet to import a Get-Date cmdlet and a SearchHelp Function into the current session.

    The Import-PSSession cmdlet returns a PSModuleInfo object that represents the temporary module. The value of the Path property shows that Import-PSSession created a script module (.psm1) file in a temporary location. The ExportedFunctions property shows that the Get-Date cmdlet and the SearchHelp Function were both imported as Functions.

    ————————– EXAMPLE 7 ————————–

    C:\PS>Import-PSSession $s -CommandName Get-Date -FormatTypeName * -AllowClobber

    C:\PS> Get-Command Get-Date

    CommandType Name     Definition
    ———– —-     ———-
    Function     Get-Date
    Cmdlet        Get-Date Get-Date [[-Date] <DateTime>] [-Year <Int32>] [-Month <Int32>]

    C:\PS> Get-Date
    09074

    C:\PS> (Get-Command -type cmdlet -name Get-Date).pssnapin.name
    Microsoft.PowerShell.Utility

    C:\PS> Microsoft.PowerShell.Utility\Get-Date

    Sunday, March 15, 2009 2:08:26 PM

    Description
    ———–
    This example shows how to run a command that is hidden by an imported command.

    The first command imports a Get-Date cmdlet from the PSSession in the $s Variable. Because the current session includes a Get-Date cmdlet, the AllowClobber parameter is required in the command.

    The second command uses the Get-Command cmdlet to get the Get-Date commands in the current session. The output shows that the session includes the original Get-Date cmdlet and a Get-Date Function. The Get-Date Function runs the imported Get-Date cmdlet in the PSSession in $s.

    The third command runs a Get-Date command. Because Functions take precedence over cmdlets, Windows PowerShell runs the imported Get-Date Function, which returns a Julian date.

    The fourth and fifth commands show how to use a qualified name to run a command that is hidden by an imported command.

    The fourth command gets the name of the Windows PowerShell snap-in that added the original Get-Date cmdlet to the current session.

    The fifth command uses the snap-in-qualified name of the Get-Date cmdlet to run a Get-Date command.

    For more information about command precedence and hidden commands, see about_command_precedence.

    ————————– EXAMPLE 8 ————————–

    C:\PS>Import-PSSession -Session $s -CommandName *Item* -AllowClobber

    Description
    ———–
    This command imports commands whose names include “Item” from the PSSession in $s. Because the command includes the CommandName parameter but not the FormatTypeData parameter, only the command is imported.

    Use this command when you are using Import-PSSession to run a command on a remote computer and you already have the formatting data for the command in the current session.

    ————————– EXAMPLE 9 ————————–

    C:\PS>$m = Import-PSSession -Session $s -CommandName *bits* -FormatTypeName *bits*

    C:\PS> Get-Command -Module $m

    CommandType     Name
    ———–     —-
    Function        Add-BitsFile
    Function        Complete-BitsTransfer
    Function        Get-BitsTransfer
    Function        Remove-BitsTransfer
    Function        Resume-BitsTransfer
    Function        Set-BitsTransfer
    Function        Start-BitsTransfer
    Function        Suspend-BitsTransfer

    Description
    ———–
    This command shows how to use the Module parameter of Get-Command to find out which commands were imported into the session by an Import-PSSession command.

    The first command uses the Import-PSSession cmdlet to import commands whose names include “bits” from the PSSession in the $s Variable. The Import-PSSession command returns a temporary module, and the command saves the module in the $m Variable.

    The second command uses the Get-Command cmdlet to get the commands that are exported by the module in the $m Variable.

    The Module parameter takes a string value, which is designed for the module name. However, when you submit a module object, Windows PowerShell uses the ToString method on the module object, which returns the module name.

    The Get-Command command is the equivalent of “Get-Command $m.name”.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=135221
    about_command_precedence
    New-PSSession
    Export-PSSession
    about_jobs
    about_pssessions