Tag Archives: ErrorAction

New-Event

NAME
    New-Event

SYNOPSIS
    Creates a new event.

SYNTAX
    New-Event [-SourceIdentifier] <string> [[-Sender] <psobject>] [[-EventArguments] <PSObject[]>] [[-MessageData] <psobject>] [<CommonParameters>]

DESCRIPTION
    The New-Event cmdlet creates a new custom event.

    You can use custom events to notify users about state changes in your program and any change that your program can detect, including hardware or system conditions, application status, disk status, network status, or the completion of a background job.

    Custom events are automatically added to the event queue in your session whenever they are raised; you do not need to subscribe to them. However, if you want to forward an event to the local session or specify an action to respond to the event, use the Register-EngineEvent cmdlet to subscribe to the custom event.

    When you subscribe to a custom event, the event subscriber is added to your session. If you cancel the event subscription by using the Unregister-Event cmdlet, the event subscriber and custom event are deleted from the session. If you do not subscribe to the custom event, to delete the event, you must change the program conditions or close the Windows PowerShell session.

PARAMETERS
    -EventArguments <PSObject[]>
        Specifies an object that contains options for the event.

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

    -MessageData <psobject>
        Specifies additional data associated with the event. The value of this parameter appears in the MessageData property of the event object.

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

    -Sender <psobject>
        Specifies the object that raises the event. The default is the Windows PowerShell engine.

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

    -SourceIdentifier <string>
        Specifies a name for the new event. This parameter is required, and it must be unique in the session.

        The value of this parameter appears in the SourceIdentifier property of the events.

        Required?                    true
        Position?                    1
        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.Management.Automation.PSEventArgs

NOTES

        The new custom event, the event subscription, and the event queue exist only in the current session. If you close the current session, the event queue is discarded and the event subscription is canceled.

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

    C:\PS>New-Event -SourceIdentifier Timer -Sender windows.timer -MessageData “Test”

    Description
    ———–
    This command creates a new event in the Windows PowerShell event queue. It uses a Windows.Timer object to send the event.

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

    C:\PS>function Enable-ProcessCreationEvent
    {
     $query = New-Object System.Management.WqlEventQuery “__InstanceCreationEvent”, (New-Object TimeSpan 0,0,1), “TargetInstance isa ‘Win32_Process'”
     $processWatcher = New-Object System.Management.ManagementEventWatcher $query
     $identifier = “WMI.ProcessCreated”

     Register-ObjectEvent $processWatcher “EventArrived” -SupportEvent $identifier -Action {
         [void] (New-Event -sourceID “PowerShell.ProcessCreated” -Sender $args[0] -EventArguments $args[1].SourceEventArgs.NewEvent.TargetInstance)
     }
    }

    Description
    ———–
    This sample Function uses the New-Event cmdlet to raise an event in response to another event. The command uses the Register-ObjectEvent cmdlet to subscribe to the Windows Management Instrumentation (WMI) event that is raised when a new process is created. The command uses the Action parameter of the cmdlet to call the New-Event cmdlet, which creates the new event.

    Because the events that New-Event raises are automatically added to the Windows PowerShell event queue, you do not need to register for that event.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=135234
    Register-ObjectEvent
    Register-EngineEvent
    Register-WmiEvent
    Unregister-Event
    Get-Event
    Remove-Event
    Wait-Event

New-EventLog

NAME
    New-EventLog

SYNOPSIS
    Creates a new event log and a new event source on a local or remote computer.

SYNTAX
    New-EventLog [-LogName] <string> [-Source] <string[]> [[-ComputerName] <string[]>] [-CategoryResourceFile <string>] [-MessageResourceFile <string>] [-ParameterResourceFile <string>] [<CommonParameters>]

DESCRIPTION
    This cmdlet creates a new classic event log on a local or remote computer. It can also register an event source that writes to the new log or to an existing log.

    The cmdlets that contain the EventLog noun (the Event log cmdlets) work only on classic event logs. To get events from logs that use the Windows Event Log technology in Windows Vista and later versions of Windows, use Get-WinEvent.

PARAMETERS
    -CategoryResourceFile <string>
        Specifies the path to the file that contains category strings for the source events. This file is also known as the Category Message File.

        The file must be present on the computer on which the event log is being created. This parameter does not create or move files.

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

    -ComputerName <string[]>
        Creates the new event logs on the specified computers. The default is the local computer.

        Type the NetBIOS name, an Internet Protocol (IP) address, or a fully qualified domain name of a remote computer. To specify the local computer, type the computer name, a dot (.), or “localhost”.

        This parameter does not rely on Windows PowerShell remoting. You can use the ComputerName parameter of Get-EventLog even if your computer is not configured to run remote commands.

        Required?                    false
        Position?                    3
        Default value                .
        Accept pipeline input?     false
        Accept wildcard characters? false

    -LogName <string>
        Specifies the name of the event log.

        If the log does not exist, New-EventLog creates the log and uses this value for the Log and LogDisplayName properties of the new event log. If the log exists, New-EventLog registers a new source for the event log.

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

    -MessageResourceFile <string>
        Specifies the path to the file that contains message formatting strings for the source events. This file is also known as the Event Message File.

        The file must be present on the computer on which the event log is being created. This parameter does not create or move files.

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

    -ParameterResourceFile <string>
        Specifies the path to the file that contains strings used for parameter substitutions in event descriptions. This file is also known as the Parameter Message File.

        The file must be present on the computer on which the event log is being created. This parameter does not create or move files.

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

    -Source <string[]>
        Specifies the names of the event log sources, such as application programs that write to the event log. This parameter is required.

        Required?                    true
        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.Diagnostics.EventLogEntry

NOTES

        To use New-EventLog on Windows Vista and later versions of Windows, open Windows PowerShell with the “Run as administrator” option.

        To create an event source in Windows Vista, Windows XP Professional, or Windows Server 2003, you must be a member of the Administrators group on the computer.

        When you create a new event log and a new event source, the system registers the new source for the new log, but the log is not created until the first entry is written to it.

        The operating system stores event logs as files. When you create a new event log, the associated file is stored in the %SystemRoot%\System32\Config directory on the specified computer. The file name is the first eight characters of the Log property with an .evt file name extension.

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

    C:\PS>New-Eventlog -Source TestApp -LogName TestLog -MessageResourceFile C:\Test\TestApp.dll

    Description
    ———–
    This command creates the TestLog event log on the local computer and registers a new source for it.

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

    C:\PS>$file = “C:\Program Files\TestApps\NewTestApp.dll”

    C:\PS> New-Eventlog -ComputerName Server01 -Source NewTestApp -LogName Application -MessageResourceFile $file -CategoryResourceFile $file

    Description
    ———–
    This command adds a new event source, NewTestApp, to the Application log on the Server01 remote computer.

    The command requires that the NewTestApp.dll file is located on the Server01 computer.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=135235
    Clear-EventLog
    Get-EventLog
    Limit-EventLog
    New-EventLog
    Remove-EventLog
    Show-EventLog
    Write-EventLog
    Get-WinEvent

New-Item

NAME
    New-Item

SYNOPSIS
    Creates a new item.

SYNTAX
    New-Item [-Path] <string[]> [-Credential <PSCredential>] [-Force] [-ItemType <string>] [-Value <Object>] [-Confirm] [-WhatIf] [-UseTransaction] [<CommonParameters>]

    New-Item -Name <string> [[-Path] <string[]>] [-Credential <PSCredential>] [-Force] [-ItemType <string>] [-Value <Object>] [-Confirm] [-WhatIf] [-UseTransaction] [<CommonParameters>]

DESCRIPTION
    The New-Item cmdlet creates a new item and sets its value. The types of items that can be created depend upon the location of the item. For example, in the file system, New-Item is used to create files and folders. In the Registry, New-Item creates Registry keys and entries.

    New-Item can also set the value of the items that it creates. For example, when creating a new file, New-Item can add initial content to the file.

PARAMETERS
    -Credential <PSCredential>
        Specifies a user account that has permission to perform this action. The default is the current user.

        Type a user name, such as “User01” or “Domain01\User01”, or enter a PSCredential object, such as one generated by the Get-Credential cmdlet. If you type a user name, you will be prompted for a password.

        This parameter is not supported by any providers installed with Windows PowerShell

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

    -Force [<SwitchParameter>]
        Allows the cmdlet to create an item that writes over an existing read-only item. Implementation varies from provider to provider. For more information, see about_providers. Even using the Force parameter, the cmdlet cannot override security restrictions.

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

    -ItemType <string>
        Specifies the provider-specified type of the new item.

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

    -Name <string>
        Specifies the name of the new item. You can use this parameter to specify the name of the new item, or include the name in the value of the Path parameter.

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

    -Path <string[]>
        Specifies the path to the location of the new item. Wildcards are permitted.

        You can specify the name of the new item in the Name parameter, or include it in the Path parameter.

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

    -Value <Object>
        Specifies the value of the new item. You can also pipe a value to New-Item.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     true (ByValue, ByPropertyName)
        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

    -UseTransaction [<SwitchParameter>]
        Includes the command in the active transaction. This parameter is valid only when a transaction is in progress. For more information, see about_transactions.

        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.Object
        You can pipe a value for the new item to the New-Item cmdlet.

OUTPUTS
    System.Object
        New-Item returns the item that it creates.

NOTES

        The New-Item cmdlet is designed to work with the data exposed by any provider. To list the providers available in your session, type “Get-PSProvider“. For more information, see about_providers.

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

    C:\PS>New-Item -Path . -name testfile1.txt -type “file” -Value “This is a text string.”

    Description
    ———–
    This command creates a text file named testfile1.txt in the current directory. The dot (.) in the value of the Path parameter indicates the current directory. The quoted text that follows the Value parameter is added to the file as content.

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

    C:\PS>New-Item -Path c:\ -name logfiles -type directory

    Description
    ———–
    This command creates a directory named Logfiles in the C: drive. The Type parameter specifies that the new item is a directory, not a file or other file system object.

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

    C:\PS>New-Item -Path $profile -type file -Force

    Description
    ———–
    This command creates a Windows PowerShell profile in the path that is specified by the $profile Variable.

    You can use profiles to customize Windows PowerShell. $Profile is an automatic (built-in) Variable that stores the path and file name of the CurrentUser/CurrentHost profile. By default, the profile does not exist, even though Windows PowerShell stores a path and file name for it.

    In this command, the $profile Variable represents the path to the file. The Type parameter (or InfoType) specifies that the command creates a file. The Force parameter lets you create a file in the profile path, even when the directories in the path do not exist (Windows PowerShell creates them).

    After you use this command to create a profile, you can enter Aliases, Functions, and scripts in the profile to customize your shell.

    For more information, see about_Automatic_Variables and about_profiles.

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

    C:\PS>New-Item -type directory -Path c:\ps-test\scripts

    Description
    ———–
    This command creates a new Scripts directory in the C:\PS-Test directory.

    The name of the new directory item, Scripts, is included in the value of the Path parameter, instead of being specified in the value of the Name parameter. As indicated by the syntax, either command form is valid.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113353
    about_providers
    Get-Item
    Set-Item
    Remove-Item
    Clear-Item
    Invoke-Item
    Rename-Item
    Move-Item
    Copy-Item

New-ItemProperty

NAME
    New-ItemProperty

SYNOPSIS
    Creates a new property for an item and sets its value. For example, you can use New-ItemProperty to create and change Registry values and data, which are properties of a Registry key.

SYNTAX
    New-ItemProperty [-LiteralPath] <string[]> [-Name] <string> [-Credential <PSCredential>] [-Exclude <string[]>] [-Filter <string>] [-Force] [-Include <string[]>] [-PropertyType <string>] [-Value <Object>] [-Confirm] [-WhatIf] [-UseTransaction] [<CommonParameters>]

    New-ItemProperty [-Path] <string[]> [-Name] <string> [-Credential <PSCredential>] [-Exclude <string[]>] [-Filter <string>] [-Force] [-Include <string[]>] [-PropertyType <string>] [-Value <Object>] [-Confirm] [-WhatIf] [-UseTransaction] [<CommonParameters>]

DESCRIPTION
    The New-ItemProperty cmdlet creates a new property for a specified item and sets its value. Typically, this cmdlet is used to create new Registry values, because Registry values are properties of a Registry key item.

    This cmdlet does not add properties to an object. To add a property to an instance of an object, use the Add-Member cmdlet. To add a property to all objects of a particular type, edit the Types.ps1xml file.

PARAMETERS
    -Credential <PSCredential>
        Specifies a user account that has permission to perform this action. The default is the current user.

        Type a user name, such as “User01” or “Domain01\User01”, or enter a PSCredential object, such as one generated by the Get-Credential cmdlet. If you type a user name, you will be prompted for a password.

        This parameter is not supported by any providers installed with Windows PowerShell.

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

    -Exclude <string[]>
        Omits the specified items. Wildcards are permitted.

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

    -Filter <string>
        Specifies a filter in the provider’s format or language. The value of this parameter qualifies the Path parameter.

        The syntax of the filter, including the use of wildcards, depends on the provider. Filters are more efficient than other parameters, because the provider applies them when retrieving the objects rather than having Windows PowerShell filter the objects after they are retrieved.

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

    -Force [<SwitchParameter>]
        Allows the cmdlet to create a property on an object that cannot otherwise be accessed by the user. Implementation varies from provider to provider. For more information, see about_providers.

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

    -Include <string[]>
        The value of this parameter qualifies the Path parameter. Enter a path element or pattern, such as “*.txt”. Wildcards are permitted.

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

    -LiteralPath <string[]>
        Specifies a path to the item property. The value of LiteralPath is used exactly as it is typed. No characters are interpreted as wildcards. If the path includes escape characters, enclose it in single quotation marks. Single quotation marks tell Windows PowerShell not to interpret any characters as escape sequences.

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

    -Name <string>
        Specifies a name for the new property. If the property is a Registry entry, this parameter specifies the name of the entry.

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

    -Path <string[]>
        Specifies the path to the item. This parameter identifies the item to which the new property will be added.

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

    -PropertyType <string>
        Specifies the type of property that will be added.

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

    -Value <Object>
        Specifies the property value. If the property is a Registry entry, this parameter specifies the value of the entry.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     true (ByPropertyName)
        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

    -UseTransaction [<SwitchParameter>]
        Includes the command in the active transaction. This parameter is valid only when a transaction is in progress. For more information, see about_transactions.

        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
    None
        You cannot pipe input to New-ItemProperty.

OUTPUTS
    System.Management.Automation.PSCustomObject
        New-ItemProperty returns a custom object that contains the new property.

NOTES

        The New-ItemProperty cmdlet is designed to work with the data exposed by any provider. To list the providers available in your session, type “Get-PSProvider“. For more information, see about_providers.

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

    C:\PS>New-Itemproperty -Path HKLM:\Software\MyCompany -Name NoOfEmployees -Value 822

    C:\PS> Get-Itemproperty hklm:\software\mycompany

    PSPath        : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software\mycompany
    PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software
    PSChildName : mycompany
    PSDrive     : HKLM
    PSProvider    : Microsoft.PowerShell.Core\Registry
    NoOfLocations : 2
    NoOfEmployees : 822

    Description
    ———–
    This command adds a new Registry entry, NoOfEmployees, to the MyCompany key of the HKLM:\Software hive.

    The first command uses the Path parameter to specify the path to the MyCompany Registry key. It uses the Name parameter to specify a name for the entry and the Value parameter to specify its value.

    The second command uses the Get-ItemProperty cmdlet to see the new Registry entry.

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

    C:\PS>Get-Item -Path HKLM:\Software\MyCompany | New-Itemproperty -Name NoOfLocations -Value 3

    Description
    ———–
    This command adds a new Registry entry to a Registry key. To specify the key, it uses a pipeline operator (|) to send an object representing the key to the New-ItemProperty cmdlet.

    The first part of the command uses the Get-Item cmdlet to get the MyCompany Registry key. The pipeline operator (|) sends the results of the command to the New-ItemProperty cmdlet, which adds the new Registry entry, NoOfLocations, and its value, 3, to the MyCompany key.

    This command works because the parameter-binding feature of Windows PowerShell associates the path of the RegistryKey object that Get-Item returns with the LiteralPath parameter of New-ItemProperty. For more information, see about_pipelines.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113354
    about_providers
    Clear-ItemProperty
    Copy-ItemProperty
    Move-ItemProperty
    Rename-ItemProperty
    Get-ItemProperty
    Set-ItemProperty
    Remove-ItemProperty

New-Module

NAME
    New-Module

SYNOPSIS
    Creates a new dynamic module that exists only in memory.

SYNTAX
    New-Module [-Name] <string> [-ScriptBlock] <scriptblock> [-ArgumentList <Object[]>] [-AsCustomObject] [-Cmdlet <string[]>] [-Function <string[]>] [-ReturnResult] [<CommonParameters>]

    New-Module [-ScriptBlock] <scriptblock> [-ArgumentList <Object[]>] [-AsCustomObject] [-Cmdlet <string[]>] [-Function <string[]>] [-ReturnResult] [<CommonParameters>]

DESCRIPTION
    The New-Module cmdlet creates a dynamic module from a script block. The members of the dynamic module, such as Functions and Variables, are immediately available in the session and remain available until you close the session.

    Like static modules, by default, the cmdlets and Functions in a dynamic module are exported and the Variables and Aliases are not. However, you can use the Export-ModuleMember cmdlet and the parameters of New-Module to override the defaults.

    Dynamic modules exist only in memory, not on disk. Like all modules, the members of dynamic modules run in a private module scope that is a child of the global scope. Get-Module cannot get a dynamic module, but Get-Command can get the exported members.

    To make a dynamic module available to Get-Module, pipe a New-Module command to Import-Module, or pipe the module object that New-Module returns to Import-Module. This action adds the dynamic module to the Get-Module list, but it does not save the module to disk or make it persistent.

PARAMETERS
    -ArgumentList <Object[]>
        Specifies arguments (parameter values) that are passed to the script block.

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

    -AsCustomObject [<SwitchParameter>]
        Returns a custom object with members that represent the module members.

        When you use the AsCustomObject parameter, New-Module creates the dynamic module, imports the module members into the current 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.

        If the module has multiple members with the same name, such as a Function and a Variable that are both named “A,” only one member with each name is accessible from the custom object.

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

    -Cmdlet <string[]>
        Exports only the specified cmdlets from the module into the current session. Enter a comma-separated list of cmdlets. Wildcard characters are permitted. By default, all cmdlets in the module are exported.

        You cannot define cmdlets in a script block, but a dynamic module can include cmdlets if it imports the cmdlets from a binary module.

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

    -Function <string[]>
        Exports only the specified Functions from the module into the current session. Enter a comma-separated list of Functions. Wildcard characters are permitted. By default, all Functions defined in a module are exported.

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

    -Name <string>
        Specifies a name for the new module. You can also pipe a module name to New-Module.

        The default value is an autogenerated name that begins with “__DynamicModule_” and is followed by a GUID that specifies the path to the dynamic module.

        Required?                    true
        Position?                    1
        Default value                “__DynamicModule_” + GUID
        Accept pipeline input?     true (ByValue)
        Accept wildcard characters? false

    -ReturnResult [<SwitchParameter>]
        Runs the script block and returns the script block results instead of returning a module object.

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

    -ScriptBlock <scriptblock>
        Specifies the contents of the dynamic module. Enclose the contents in braces ( { } ) to create a script block. 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
    System.String
        You can pipe a module name string to New-Module.

OUTPUTS
    System.Management.Automation.PSModuleInfo, System.Management.Automation.PSCustomObject, or None
        By default, New-Module generates a PSModuleInfo object. If you use the AsCustomObject parameter, it generates a PSCustomObject object. If you use the ReturnResult parameter, it returns the result of evaluating the script block in the dynamic module.

NOTES

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

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

    C:\PS>New-Module -ScriptBlock {function Hello {“Hello!”}}

    Name             : __DynamicModule_2ceb1d0a-990f-45e4-9fe4-89f0f6ead0e5
    Path             : 2ceb1d0a-990f-45e4-9fe4-89f0f6ead0e5
    Description     :
    Guid             : 00000000-0000-0000-0000-000000000000
    Version         : 0.0
    ModuleBase        :
    ModuleType        : Script
    PrivateData     :
    AccessMode        : ReadWrite
    ExportedAliases : {}
    ExportedCmdlets : {}
    ExportedFunctions : {[Hello, Hello]}
    ExportedVariables : {}
    NestedModules     : {}

    Description
    ———–
    This command creates a new dynamic module with a Function called “Hello”. The command returns a module object that represents the new dynamic module.

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

    C:\PS>New-Module -ScriptBlock {function Hello {“Hello!”}}

    Name             : __DynamicModule_2ceb1d0a-990f-45e4-9fe4-89f0f6ead0e5
    Path             : 2ceb1d0a-990f-45e4-9fe4-89f0f6ead0e5
    Description     :
    Guid             : 00000000-0000-0000-0000-000000000000
    Version         : 0.0
    ModuleBase        :
    ModuleType        : Script
    PrivateData     :
    AccessMode        : ReadWrite
    ExportedAliases : {}
    ExportedCmdlets : {}
    ExportedFunctions : {[Hello, Hello]}
    ExportedVariables : {}
    NestedModules     : {}

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

    C:\PS> Get-Command Hello

    CommandType     Name Definition
    ———–     —- ———-
    Function        Hello “Hello!”

    Description
    ———–
    This example demonstrates that dynamic modules are not returned by the Get-Module cmdlet, but the members that they export are returned by the Get-Command cmdlet.

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

    C:\PS>New-Module -ScriptBlock {$SayHelloHelp=”Type ‘SayHello’, a space, and a name.”; Function SayHello ($name) { “Hello, $name” }; Export-ModuleMember -Function SayHello -Variable SayHelloHelp}

    C:\PS> $SayHelloHelp
    Type ‘SayHello’, a space, and a name.

    C:\PS> SayHello Jeffrey
    Hello, Jeffrey

    Description
    ———–
    This command uses the Export-ModuleMember cmdlet to export a Variable into the current session. Without the Export-ModuleMember command, only the Function is exported.

    The output shows that both the Variable and the Function were exported into the session.

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

    C:\PS>New-Module -ScriptBlock {function Hello {“Hello!”}} -name GreetingModule | Import-Module

    C:\PS> Get-Module

    Name             : GreetingModule
    Path             : d54dfdac-4531-4db2-9dec-0b4b9c57a1e5
    Description     :
    Guid             : 00000000-0000-0000-0000-000000000000
    Version         : 0.0
    ModuleBase        :
    ModuleType        : Script
    PrivateData     :
    AccessMode        : ReadWrite
    ExportedAliases : {}
    ExportedCmdlets : {}
    ExportedFunctions : {[Hello, Hello]}
    ExportedVariables : {}
    NestedModules     : {}

    C:\PS> Get-Command hello

    CommandType     Name                                                             Definition
    ———–     —-                                                             ———-
    Function        Hello                                                             “Hello!”

    Description
    ———–
    This command demonstrates that you can make a dynamic module available to the Get-Module cmdlet by piping the dynamic module to the Import-Module cmdlet.

    The first command uses a pipeline operator (|) to send the module object that New-Module generates to the Import-Module cmdlet. The command uses the Name parameter of New-Module to assign a friendly name to the module. Because Import-Module does not return any objects by default, there is no output from this command.

    The second command uses the Get-Module cmdlet to get the modules in the session. The result shows that Get-Module can get the new dynamic module.

    The third command uses the Get-Command cmdlet to get the Hello Function that the dynamic module exports.

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

    C:\PS>$m = New-Module -ScriptBlock {function Hello ($name) {“Hello, $name”}; Function Goodbye ($name) {“Goodbye, $name”}} -AsCustomObject

    C:\PS> $m

    C:\PS> $m | 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()
    Goodbye     ScriptMethod System.Object Goodbye();
    Hello     ScriptMethod System.Object Hello();

    PS C:\ps-test> $m.goodbye(“Jane”)
    Goodbye, Jane

    PS C:\ps-test> $m.hello(“Manoj”)
    Hello, Manoj

    PS C:\ps-test> goodbye Jane
    Goodbye, Jane

    PS C:\ps-test> hello Manoj
    Hello, Manoj

    Description
    ———–
    This example shows how to use the AsCustomObject parameter of New-Module to generate a custom object with script methods that represent the exported Functions.

    The first command uses the New-Module cmdlet to generate a dynamic module with two Functions, Hello and Goodbye. The command uses the AsCustomObject parameter to generate a custom object instead of the PSModuleInfo object that New-Module generates by default. The command saves the custom object in the $m Variable.

    The second command attempts to display the value of the $m Variable. No content appears.

    The third command uses a pipeline operator (|) to send the custom object to the Get-Member cmdlet, which displays the properties and methods of the custom object. The output shows that the object has script methods that represent the Hello and Goodbye Functions.

    The fourth and fifth commands use the script method format to call the Hello and Goodbye Functions.

    The sixth and seventh commands call the Functions by specifying the Function name and parameter value.

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

    C:\PS>New-Module -ScriptBlock {function SayHello {“Hello, World!”}; SayHello} -ReturnResult

    Hello, World!

    Description
    ———–
    This command uses the ReturnResult parameter to request the results of running the script block instead of requesting a module object.

    The script block in the new module defines the SayHello Function and then calls the Function.

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

New-ModuleManifest

NAME
    New-ModuleManifest

SYNOPSIS
    Creates a new module manifest.

SYNTAX
    New-ModuleManifest [-Path] <string> -Author <string> -CompanyName <string> -Copyright <string> -Description <string> -FileList <string[]> -FormatsToProcess <string[]> -ModuleToProcess <string> -NestedModules <string[]> -RequiredAssemblies <string[]> -TypesToProcess <string[]> [-AliasesToExport <string[]>] [-ClrVersion <Version>] [-CmdletsToExport <string[]>] [-DotNetFrameworkVersion <Version>] [-FunctionsToExport <string[]>] [-Guid <Guid>] [-ModuleList <Object[]>] [-ModuleVersion <Version>] [-PassThru] [-PowerShellHostName <string>] [-PowerShellHostVersion <Version>] [-PowerShellVersion <Version>] [-PrivateData <Object>] [-ProcessorArchitecture {None | MSIL | X86 | IA64 | Amd64}] [-RequiredModules <Object[]>] [-ScriptsToProcess <string[]>] [-VariablesToExport <string[]>] [-Confirm] [-WhatIf] [<CommonParameters>]

DESCRIPTION
    The New-ModuleManifest cmdlet creates a new module manifest (.psd1) file, populates its values, and saves the manifest file in the specified path.

    Module authors can use this cmdlet to create a manifest for their module. A module manifest is a .psd1 file that contains a hash table. The keys and values in the hash table describe the contents and attributes of the module, define the prerequisites, and determine how the components are processed. Manifests are not required for a module.

    New-ModuleManifest creates a manifest that includes all of the commonly used manifest keys, so you can use the default output as a manifest template. To add or change values, or to add module keys that this cmdlet does not add, open the resulting file in a text editor.

    Each parameter of this cmdlet (except for Path and PassThru) creates a module manifest key and its value. In a module manifest, only the ModuleVersion key is required. However, several other parameters of this cmdlet are mandatory. As a result, you can type a “New-ModuleManifest” command without parameters and the cmdlet will prompt you for values for other commonly used keys. To leave the value empty, press ENTER.

    For a complete description of the format, effects, and requirements of a module manifest, see “How to Write a Module Manifest” in the MSDN (Microsoft Developer Network) library at http://go.microsoft.com/fwlink/?LinkId=143613.

PARAMETERS
    -AliasesToExport <string[]>
        Specifies the Aliases that the module exports. Wildcards are permitted.

        You can use this parameter to restrict the Aliases that are exported by the module. It can remove Aliases from the list of exported Aliases, but it cannot add Aliases to the list.

        If you omit this parameter, New-ModuleManifest creates an AliasesToExport key with a value of * (all), meaning that all Aliases that are exported by the module are exported by the manifest.

        Required?                    false
        Position?                    named
        Default value                * (all)
        Accept pipeline input?     false
        Accept wildcard characters? true

    -Author <string>
        Specifies the module author.

        This parameter is required by the cmdlet, but the Author key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates an Author key with the name of the current user.

        Required?                    true
        Position?                    named
        Default value                Name of the current user
        Accept pipeline input?     false
        Accept wildcard characters? false

    -ClrVersion <Version>
        Specifies the version of the Common Language Runtime (CLR) of the Microsoft .NET Framework that the module requires.

        If you omit this parameter, New-ModuleManifest creates a CLRVersion key with an empty string value.

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

    -CmdletsToExport <string[]>
        Specifies the cmdlets that the module exports. Wildcards are permitted.

        You can use this parameter to restrict the cmdlets that are exported by the module. It can remove cmdlets from the list of exported cmdlets, but it cannot add cmdlets to the list.

        If you omit this parameter, New-ModuleManifest creates a CmdletsToExport key with a value of * (all), meaning that all cmdlets that are exported by the module are exported by the manifest.

        Required?                    false
        Position?                    named
        Default value                * (all)
        Accept pipeline input?     false
        Accept wildcard characters? true

    -CompanyName <string>
        Identifies the company or vendor who created the module.

        This parameter is required by the cmdlet, but the CompanyName key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a CompanyName key with a value of “Unknown”.

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

    -Copyright <string>
        Specifies a copyright statement for the module.

        This parameter is required by the cmdlet, but the Copyright key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a Copyright key with a value of “(c) <year> <username>. All rights reserved.” where <year> is the current year and <username> is the value of the Author key (if one is specified) or the name of the current user.

        Required?                    true
        Position?                    named
        Default value                (c) <year> <username>. All rights reserved.
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Description <string>
        Describes the contents of the module.

        This parameter is required by the cmdlet, but the Description key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a Description key with an empty string value.

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

    -DotNetFrameworkVersion <Version>
        Specifies the version of the Microsoft .NET Framework that the module requires.

        If you omit this parameter, New-ModuleManifest creates a DotNetFrameWorkVersion key with an empty string value.

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

    -FileList <string[]>
        Specifies all items that are included in the module.

        This key is designed to act as a module inventory. These files are not automatically exported with the module.

        This parameter is required by the cmdlet, but the FileList key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a FileList key with an empty array value.

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

    -FormatsToProcess <string[]>
        Specifies the formatting files (.ps1xml) that run when the module is imported.

        When you import a module, Windows PowerShell runs the Update-FormatData cmdlet with the specified files. Because formatting files are not scoped, they affect all session states in the session.

        This parameter is required by the cmdlet, but the FormatsToProcess key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a FormatsToProcess key with an empty array value.

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

    -FunctionsToExport <string[]>
        Specifies the Functions that the module exports. Wildcards are permitted.

        You can use this parameter to restrict the Functions that are exported by the module. It can remove Functions from the list of exported Aliases, but it cannot add Functions to the list.

        If you omit this parameter, New-ModuleManifest creates an FunctionsToExport key with a value of * (all), meaning that all Functions that are exported by the module are exported by the manifest.

        Required?                    false
        Position?                    named
        Default value                * (all)
        Accept pipeline input?     false
        Accept wildcard characters? true

    -Guid <Guid>
        Specifies a unique identifier for the module. The GUID can be used to distinguish among modules with the same name.

        If you omit this parameter, New-ModuleManifest creates a GUID key in the manifest and generates a GUID for the value.

        To create a new GUID in Windows PowerShell, type “[guid]::NewGuid()”.

        Required?                    false
        Position?                    named
        Default value                A GUID generated for the module
        Accept pipeline input?     false
        Accept wildcard characters? false

    -ModuleList <Object[]>
        Lists all modules that are packaged with this module.

        Enter each module name as a string or enter a hash table with ModuleName and GUID keys. The hash table can also have an optional ModuleVersion key.

        This key is designed to act as a module inventory. These modules are not automatically processed.

        If you omit this parameter, New-ModuleManifest creates a ModuleList key in the manifest with an empty array value.

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

    -ModuleToProcess <string>
        Specifies the primary or “root” file of the module. When the module is imported, the members that are exported from the root module file are imported into the caller’s session state. Enter the file name of one script module (.psm1) or binary module (.dll).

        If a module has a manifest file and no root file has been designated in the ModuleToProcess key, the manifest becomes the primary file for the module, and the module becomes a “manifest module” (ModuleType = Manifest).

        To export members from .psm1 or .dll files in a module that has a manifest, the names of those files must be specified in the values of the ModuleToProcess or NestedModules keys in the manifest. Otherwise, their members are not exported.

        This parameter is required by the cmdlet, but the ModuleToProcess key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a ModuleToProcess key with an empty string value.

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

    -ModuleVersion <Version>
        Specifies the version of the module.

        This parameter is not required by the cmdlet, but a ModuleVersion key is required in the manifest. If you omit this parameter, New-ModuleManifest creates a ModuleVersion key with a value of “1.0”.

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

    -NestedModules <string[]>
        Specifies script modules (.psm1) and binary modules (.dll) that are imported into the module’s session state. The files in the NestedModules key run in the order in which they are listed in the value.

        Typically, nested modules contain commands that the root module needs for its internal processing. By default, the commands in nested modules are exported from the module’s session state into the caller’s session state, but the root module can restrict the commands that it exports (for example, by using an Export-Module command).

        Nested modules in the module session state are available to the root module, but they are not returned by a Get-Module command in the caller’s session state.

        Scripts (.ps1) that are listed in the NestedModules key are run in the module’s session state, not in the caller’s session state. To run a script in the caller’s session state, list the script file name in the value of the ScriptsToProcess key in the manifest.

        This parameter is required by the cmdlet, but the NestedModules key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a NestedModules key with an empty array value.

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

    -PassThru [<SwitchParameter>]
        Writes the resulting module manifest to the console, in addition to creating a .psd1 file. By default, this cmdlet does not generate any output.

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

    -Path <string>
        Specifies the path and file name of the new module manifest. Enter a path and file name with a .psd1 file name extension, such as “$pshome\Modules\MyModule\MyModule.psd1”. This parameter is required.

        If you specify the path to an existing file, New-ModuleManifest replaces the file without warning unless the file has the read-only attribute.

        The manifest should be located in the module’s directory, and the manifest file name should be the same as the module directory name, but with a .psd1 file name extension.

        Note: You cannot use Variables, such as $pshome or $home, in response to a prompt for a Path parameter value. To use a Variable, include the Path parameter in the command.

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

    -PowerShellHostName <string>
        Specifies the name of the Windows PowerShell host program that the module requires. Enter the name of the host program, such as “Windows PowerShell ISE Host” or “ConsoleHost”. Wildcards are not permitted.

        To find the name of a host program, in the program, type “$host.name”.

        If you omit this parameter, New-ModuleManifest creates a PowerShellHostName key with an empty string value.

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

    -PowerShellHostVersion <Version>
        Specifies the minimum version of the Windows PowerShell host program that works with the module. Enter a version number, such as 1.1.

        If you omit this parameter, New-ModuleManifest creates a PowerShellHostName key with an empty string value.

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

    -PowerShellVersion <Version>
        Specifies the minimum version of Windows PowerShell that will work with this module. Enter 1.0 or 2.0. Requirements for versions greater than 2.0 are not enforced.

        If you omit this parameter, New-ModuleManifest creates a PowerShellVersion key with an empty string value.

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

    -PrivateData <Object>
        Specifies data that is passed to the module when it is imported.

        If you omit this parameter, New-ModuleManifest creates a PrivateData key with an empty string value.

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

    -ProcessorArchitecture <ProcessorArchitecture>
        Specifies the processor architecture that the module requires. Valid values are x86, AMD64, IA64, and None (unknown or unspecified).

        If you omit this parameter, New-ModuleManifest creates a ProcessorArchitecture key with an empty string value.

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

    -RequiredAssemblies <string[]>
        Specifies the assembly (.dll) files that the module requires. Windows PowerShell loads the specified assemblies before updating types or formats, importing nested modules, or importing the module file that is specified in the value of the ModuleToProcess key.

        Use this parameter to list all the assemblies that the module requires, including assemblies that must be loaded to update any formatting or type files that are listed in the FormatsToProcess or TypesToProcess keys, even if those assemblies are also listed as binary modules in the NestedModules key.

        This parameter is required by the cmdlet, but the RequiredAssemblies key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a RequiredAssemblies key with an empty array value.

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

    -RequiredModules <Object[]>
        Specifies modules that must be in the global session state. If the required modules are not in the global session state, attempts to import this module will fail.

        Enter each module name as a string or enter a hash table with the ModuleName and GUID keys. The hash table can also have an optional ModuleVersion key. For more information, see the examples.

        Windows PowerShell does not import required modules automatically. It verifies only that the required modules are present. However, modules can include scripts (.ps1) that import the required modules into the global session state.

        If you omit this parameter, New-ModuleManifest creates a RequiredModules key with an empty array value.

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

    -ScriptsToProcess <string[]>
        Specifies script (.ps1) files that run in the caller’s session state when the module is imported. You can use these scripts to prepare an Environment, just as you might use a login script.

        To specify scripts that run in the module’s session state, use the NestedModules key.

        If you omit this parameter, New-ModuleManifest creates a ScriptsToProcess key with an empty array value.

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

    -TypesToProcess <string[]>
        Specifies the type files (.ps1xml) that run when the module is imported.

        When you import the module, Windows PowerShell runs the Update-TypeData cmdlet with the specified files. Because type files are not scoped, they affect all session states in the session.

        This parameter is required by the cmdlet, but the TypesToProcess key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a TypesToProcess key with an empty array value.

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

    -VariablesToExport <string[]>
        Specifies the Variables that the module exports. Wildcards are permitted.

        You can use this parameter to restrict the Variables that are exported by the module. It can remove Variables from the list of exported Variables, but it cannot add Variables to the list.

        If you omit this parameter, New-ModuleManifest creates a VariablesToExport key with a value of * (all), meaning that all Variables that are exported by the module are exported by the manifest.

        Required?                    false
        Position?                    named
        Default value                * (all)
        Accept pipeline input?     false
        Accept wildcard characters? true

    -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
    None
        You cannot pipe input to this cmdlet.

OUTPUTS
    None or System.String
        By default, New-ModuleManifest does not generate any output. However, if you use the PassThru parameter, it generates a System.String object representing the module manifest..

NOTES

        Module manifests are usually optional. However, a module manifest is required to export an assembly that is installed in the global assembly cache.

        To add or change files in the $pshome\Modules directory (%Windir%\System32\WindowsPowerShell\v1.0\Modules), start Windows PowerShell with the “Run as administrator” option.

        A “session” is an instance of the Windows PowerShell execution Environment. A session can have one or more session state. By default, a session has only a global session state, but each imported module has its own session state. Session states allow the commands in a module to run without affecting the global session state.

        The “caller’s session state” is the session state into which a module is imported. Typically, it refers to the global session state, but when a module imports nested modules, the “caller” is the module and the “caller’s session state” is the module’s session state.

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

    C:\PS>New-ModuleManifest

    Path: C:\Users\User01\Documents\WindowsPowerShell\Modules\Test-Module\Test-Module.psd1
    NestedModules[0]: BackgroundModule.psm1
    Author: Jinghao Liu
    CompanyName: Fabrikam, Inc.
    Copyright: Copyright © 2009 Liu Jinghao. All rights reserved.
    ModuleToProcess: TestModule.psm1
    Description: Cmdlets to find common errors in scripts.
    TypesToProcess[0]: TestTypes.ps1xml
    FormatsToProcess[0]: TestFormat.ps1xml
    RequiredAssemblies[0]: Test.dll
    FileList[0]: Test-Module.psd1
    FileList[1]: Test-Module.psm1
    FileList[2]: BackgroundModule.psm1
    FileList[3]: TestTypes.ps1xml
    FileList[4]: TestFormat.ps1xml
    FileList[5]: Test.dll
    FileList[6]: TestIcon.ico

    Description
    ———–
    This command creates a new module manifest. The cmdlet prompts you for the parameters that it requires, including the Path parameter, and creates a manifest file in the specified location.

    The output of this command shows sample responses to the prompts. To use default values, press ENTER.

    The actual prompt, and its handling of quoted and non-quoted phrases, depends on the host program in which Windows PowerShell is running.

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

    C:\PS>New-ModuleManifest -PowerShellVersion 1.0 -AliasesToExport JKBC, DRC, TAC

    Description
    ———–
    This command creates a new module manifest. The command includes parameters that the cmdlet does not require (or prompt for). You can include other manifest key values at the prompt.

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

    C:\PS>New-ModuleManifest -RequiredModules FileTransfer,@{ModuleName=”BackgroundModule”;GUID=”486569a2-2784-48bf-af15-70ba837a64d0″;ModuleVersion=”3.5″}

    Description
    ———–
    This example shows how to use the string and hash table formats of the RequiredModules parameter value. Strings and hash tables can be used in the same command.

    This command commands creates a module manifest for a module that requires the FileTransfer module and a (fictitious) module named “BackgroundModule”.

    The command uses a string format to specify the name of the FileTransfer module and the hash table format to specify the name, a GUID, and a version of the BackgroundModule.

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

Group-Object

NAME
    Group-Object

SYNOPSIS
    Groups objects that contain the same value for specified properties.

SYNTAX
    Group-Object [-AsHashTable] [-AsString] [[-Property] <Object[]>] [-CaseSensitive] [-Culture <string>] [-InputObject <psobject>] [-NoElement] [<CommonParameters>]

DESCRIPTION
    The Group-Object cmdlet displays objects in groups based on the value of a specified property. Group-Object returns a table with one row for each property value and a column that displays the number of items with that value.

    If you specify more than one property, Group-Object first groups them by the values of the first property, and then, within each property group, it groups by the value of the next property.

PARAMETERS
    -AsHashTable [<SwitchParameter>]
        Returns the group as a hash table. The keys of the hash table are the property values by which the objects are grouped. The values of the hash table are the objects that have that property value.

        By itself, the AsHashTable parameter returns each hash table in which each key is an instance of the grouped object. When used with the AsString parameter, the keys in the hash table are strings.

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

    -AsString [<SwitchParameter>]
        Converts the hash table keys to strings. By default, the hash table keys are instances of the grouped object. This parameter is valid only when used with the AsHashTable parameter.

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

    -CaseSensitive [<SwitchParameter>]
        Makes the grouping case-sensitive. Without this parameter, the property values of objects in a group might have different cases.

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

    -Culture <string>
        Specifies the culture to use when comparing strings.

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

    -InputObject <psobject>
        Specifies the objects to group. Enter a Variable that contains the objects, or type a command or expression that gets the objects.

        When you use the InputObject parameter to submit a collection of objects to Group-Object, Group-Object receives one object that represents the collection. As a result, it creates a single group with that object as its member.

        To group the objects in a collection, pipe the objects to Group-Object.

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

    -NoElement [<SwitchParameter>]
        Omits the members of a group from the results.

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

    -Property <Object[]>
        Specifies the properties for grouping. The objects are arranged into groups based on the value of the specified property.

        The value of the Property parameter can be a new calculated property. To create a calculated, property, create a hash table with an Expression key that specifies a string or script block value.

        Required?                    false
        Position?                    1
        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.Management.Automation.PSObject
        You can pipe any object to Group-Object

OUTPUTS
    Microsoft.PowerShell.Commands.GroupInfo or System.Collections.Hashtable
        When you use the AsHashTable parameter, Group-Object returns a hash table. Otherwise, it returns a GroupInfo object.

NOTES

        You can also use the GroupBy parameter of the formatting cmdlets (such as Format-Table [m2] and Format-List [m2]) to group objects. Unlike Group-Object, which creates a single table with a row for each property value, the GroupBy parameters create a table for each property value with a row for each item that has the property value.

        Group-Object does not require that the objects being grouped be of the same Microsoft .NET Framework type. When grouping objects of different .NET Framework types, Group-Object uses the following rules:

        — Same Property Names and Types: If the objects have a property with the specified name, and the property values have the same .NET Framework type, the property values are grouped by using the same rules that would be used for objects of the same type.

        — Same Property Names, Different Types: If the objects have a property with the specified name, but the property values have a different .NET Framework type in different objects, Group-Object uses the .NET Framework type of the first occurrence of the property as the .NET Framework type for that property group. When an object has a property with a different type, the property value is converted to the type for that group. If the type conversion fails, the object is not included in the group.

        — Missing Properties: Objects that do not have a specified property are considered ungroupable. Ungroupable objects appear in the final GroupInfo object output in a group named AutomationNull.Value.

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

    C:\PS>Get-ChildItem *.doc | Group-Object -Property length

    Description
    ———–
    This command gets the files in the current location that have a .doc extension and groups them by size.

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

    C:\PS>Get-ChildItem | Sort-Object -Property extension | Group-Object -Property extension

    Description
    ———–
    This command gets the files in the current location, sorts them by file name extension, and then groups them by file name extension. Note that the files are sorted before they are grouped.

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

    C:\PS>1..35 | Group-Object -Property {$_ % 2},{$_ % 3}

    Description
    ———–
    This example shows how to use script blocks as the value of the Property parameter.

    This command displays the integers from 1 to 35, grouped by the remainder left when they are divided by 2 or 3.

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

    C:\PS>$events = Get-Eventlog -logname system -newest 1000

    C:\PS> $events | Group-Object -Property eventID

    Count Name                     Group
    —– —-                     —–
     44 Information             {System.Diagnostics.EventLogEntry,
        5 Error                     {System.Diagnostics.EventLogEntry,
        1 Warning                 {System.Diagnostics.EventLogEntry}

    Description
    ———–
    These commands display the 1,000 most recent entries in the System event log, grouped by Event ID.

    The first command uses the Get-EventLog cmdlet to retrieve the events and the assignment operator (=) to save them in the $events Variable.

    The second command uses a pipeline operator (|) to send the events in the $events Variable to the Group-Object cmdlet. The command uses the Property parameter to specify that the events should be grouped according to the value of their EventID property.

    In the output, the Count column represents the number of entries in each group, the Name column represents the EventID values that define a group, and the Group column represents the objects in each group.

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

    C:\PS>Get-Process | Group-Object -Property priorityclass

    Count Name                Group
    —– —-                —–
     55 Normal             {System.Diagnostics.Process (AdtAgent), System.Diagnostics.Process (alg), System.Dia…
        1                     {System.Diagnostics.Process (Idle)}
        3 High                {System.Diagnostics.Process (Newproc), System.Diagnostics.Process (winlogon), System.D…
        2 BelowNormal         {System.Diagnostics.Process (winperf),

    C:\PS>Get-Process | Group-Object -Property company -NoElement
    Count Name
    —– —-
     55 Normal
        1
        3 High
        2 BelowNormal

    Description
    ———–
    This example demonstrates the effect of the NoElement parameter. These commands group the processes on the computer by priority class.

    The first command uses the Get-Process cmdlet to get the processes on the computer. It uses a pipeline operator (|) to send the results to Group-Object, which groups the objects by the value of the PriorityClass property of the process.

    The second command is identical to the first, except that it uses the NoElement parameter to eliminate the members of the group from the output. The result is a table with only the count and property value name.

    The results are shown in the following sample output.

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

    C:\PS>Get-Eventlog -logname system -newest 1000 | Group-Object -Property {$_.TimeWritten – $_.TimeGenerated}

    Description
    ———–
    This command demonstrates how to provide the value of the Property parameter as a script block.

    This command displays the most recent 1,000 entries from the system event log, grouped according to the time between when they were generated and when they were written to the log.

    The command uses the Get-EventLog cmdlet to get the event log entries. It uses a pipeline operator (|) to send the entries to the Group-Object cmdlet. The value of the Property parameter is specified as a script block (an expression in braces). The result of evaluating the script block is the time between when the log entry was generated and when it was written to the log. That value is used to group the 1,000 most recent events.

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

    C:\PS>Get-ChildItem | Group-Object extension -NoElement

    Count Name
    —– —-
     21
     82 .txt
        9 .cmd
        5 .log
     12 .xml
        5 .htm
     36 .ps1
        1 .psc1
        3 .exe
        6 .csv
        1 .psd1
        2 .bat

    Description
    ———–
    This command groups the items in the current directory by file name extension. It uses the NoElement parameter to omit the members of the group.

    The results are shown in the following sample output.

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

    C:\PS>”a”, “b”, “c”, “c”, “d” | Get-Unique

    a
    b
    c
    d

    C:\PS> “a”, “b”, “c”, “c”, “d” | Group-Object -NoElement | where {$_.Count -gt 1}
    Count Name
    —– —-
        2 c

    C:\PS> Get-Process | Group-Object -Property Name -NoElement | where {$_.count -gt 1}
    Count Name
    —– —-
        2 csrss
        5 svchost
        2 winlogon
        2 wmiprvse

    Description
    ———–
    This example shows how to find the unique and non-unique (repeated) property values in a collection.

    The first command gets the unique elements of an array by piping the array to the Get-Unique cmdlet.

    The second command gets the non-unique elements of an array. It pipes the array to the Group-Object cmdlet, which groups the objects by value. The resulting groups are piped to the Where-Object cmdlet, which selects objects with groups with more than one member.

    The third command shows a practical use for this technique. It uses the same method to find processes on the computer that have the same process name.

    The results are shown in the following sample output.

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

    C:\PS>$a = Get-Command get-*, set-* -type cmdlet | Group-Object -Property verb -AsHashTable -AsString

    C:\PS> $a

    Name    Value
    —-    —–
    Get     {Get-PSCallStack, Get-PSBreakpoint, Get-PSDrive, Get-PSSession…}
    Set     {Set-Service, Set-StrictMode, Set-PSDebug, Set-PSSessionConfiguration…}

    C:\PS> $a.get

    CommandType     Name                 Definition
    ———–     —-                 ———-
    Cmdlet         Get-PSCallStack     Get-PSCallStack [-Verbose] [-Debug] [-ErrorAction <ActionPrefer…
    Cmdlet         Get-PSBreakpoint     Get-PSBreakpoint [[-Id] <Int32[]>] [-Verbose] [-Debug] [-ErrorA…
    Cmdlet         Get-PSDrive         Get-PSDrive [[-Name] <String[]>] [-Scope <String>] [-PSProvider…
    …

    Description
    ———–
    This example uses the AsHashTable and AsString parameters to return the groups in a hash table, that is, as a collection of key-value pairs.

    In the resulting hash table, each property value is a key, and the group elements are the values. Because each key is a property of the hash table object, you can use dot notation to display the values.

    The first command gets the Get and Set cmdlets in the session, groups them by verb, returns the groups as a hash table, and saves the hash table in the $a Variable.

    The second command displays the hash table in $a. There are two key-value pairs, one for the Get cmdlets and one for the Set cmdlets.

    The third command uses dot notation to display the values of the Get key in $a. The values are CmdletInfo object. The AsString parameter does not convert the objects in the groups to strings.

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

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