Category Archives: cmdlet

Write-Progress

NAME
    Write-Progress

SYNOPSIS
    Displays a progress bar within a Windows PowerShell command window.

SYNTAX
    Write-Progress [-Activity] <string> [-Status] <string> [[-Id] <int>] [-Completed] [-CurrentOperation <string>] [-ParentId <int>] [-PercentComplete <int>] [-SecondsRemaining <int>] [-SourceId <int>] [<CommonParameters>]

DESCRIPTION
    The Write-Progress cmdlet displays a progress bar in a Windows PowerShell command window that depicts the status of a running command or script. You can select the indicators that the bar reflects and the text that appears above and below the progress bar.

PARAMETERS
    -Activity <string>
        Specifies the first line of text in the heading above the status bar. This text describes the activity whose progress is being reported.

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

    -Completed [<SwitchParameter>]
        Indicates whether the progress bar is visible. If this parameter is omitted, Write-Progress displays progress information.

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

    -CurrentOperation <string>
        Specifies the line of text below the progress bar. This text describes the operation that is currently taking place.

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

    -Id <int>
        Specifies an ID that distinguishes each progress bar from the others. Use this parameter when you are creating more than one progress bar in a single command. If the progress bars do not have different IDs, they are superimposed instead of being displayed in a series.

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

    -ParentId <int>
        Identifies the parent activity of the current activity. Use the value -1 if the current activity has no parent activity.

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

    -PercentComplete <int>
        Specifies the percentage of the activity that is completed. Use the value -1 if the percentage complete is unknown or not applicable.

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

    -SecondsRemaining <int>
        Specifies the projected number of seconds remaining until the activity is completed. Use the value -1 if the number of seconds remaining is unknown or not applicable.

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

    -SourceId <int>
        Identifies the source of the record.

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

    -Status <string>
        Specifies the second line of text in the heading above the status bar. This text describes current state of the activity.

        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
    None
        Write-Progress does not generate any output.

NOTES

        If the progress bar does not appear, check the value of the $ProgressPreference Variable. If the value is set to SilentlyContinue, the progress bar is not displayed. For more information about Windows PowerShell preferences, see about_preference_variables.

        The parameters of the cmdlet correspond to the properties of the ProgressRecord class (System.Management.Automation.ProgressRecord). For more information, see the ProgressRecord topic in the Windows PowerShell Software Development Kit (SDK).

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

    C:\PS>for ($i = 1; $i -lt 101; $i++ )
    {for ($j=0;$j -lt 10000;$j++) {} Write-Progress -Activity “Search in Progress” -Status “% Complete:” -PercentComplete $i;}

    Description
    ———–
    This command displays the progress of two nested For loops. The first loop counts to 100. For each increment of that loop, the second loop counts to 10,000.
    The Write-Progress command includes a status bar heading (“activity”), a status line, and the Variable $i (the counter in the For loop), which indicates the relative completeness of the task.

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

    C:\PS>for($i = 1; $i -lt 101; $i++ ) {Write-Progress -Activity Updating -Status progress-> -PercentComplete $i -CurrentOperation OuterLoop} for($i = 1; $i -lt 101; $i++ ) {Write-Progress -Activity Updating -Status progress -PercentComplete $i -Id 1 -CurrentOperation InnerLoop}

    Updating
     progress ->
     [oooooooooooooooooo                                                 ]

     OutsideLoop

    Updating
     progress
     [oooooooooooooooooo                                                    ]

     InnerLoop

    Description
    ———–
    This example displays the progress of two nested For loops, each of which is represented by a progress bar.

    The Write-Progress command for the second progress bar includes the Id parameter that distinguishes it from the first progress bar. Without the Id parameter, the progress bars would be superimposed on each other instead of being displayed one below the other.

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

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

    C:\PS> $events | ForEach-Object -begin {clear-host;$i=0;$out=””} `
    -process {if($_.message -like “*bios*”) {$out=$out + $_.Message};
    $i = $i+1;`
    Write-Progress -Activity “Searching Events” `
    -Status “Progress:” -PercentComplete ($i/$events.count*100)} `
    -end {$out}

    Description
    ———–
    This command displays the progress of a command to find the string “bios” in the System event log.

    In the first line of the command, the Get-EventLog cmdlet gets the events in the System log and stores them in the $events Variable.

    In the second line, the events are piped to the ForEach-Object cmdlet. Before processing begins, the Clear-Host cmdlet is used to clear the screen, the $i counter Variable is set to zero, and the $out output Variable is set to the empty string.

    In the third line, which is the Process script block of the ForEach-Object cmdlet, the cmdlet searches the message property of each incoming object for “bios”. If the string is found, the message is added to $out.

    In the fourth line, the $i counter Variable is incremented to record that another event has been examined.

    The fifth line uses the Write-Progress cmdlet with values for the Activity and Status text fields that create the first and second lines of the progress bar heading, respectively. The PercentComplete parameter value is calculated by dividing the number of events that have been processed ($i) by the total number of events retrieved ($events.count) and then multiplying that result by 100.

    In the last line, the End parameter of the ForEach-Object cmdlet is used to display the messages that are stored in the $out Variable.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113428
    Write-Verbose
    Write-Error
    Write-Host
    Write-Debug
    Write-Output
    Write-Warning

Write-Verbose

NAME
    Write-Verbose

SYNOPSIS
    Writes text to the verbose message stream.

SYNTAX
    Write-Verbose [-Message] <string> [<CommonParameters>]

DESCRIPTION
    The Write-Verbose cmdlet writes text to the verbose message stream in Windows PowerShell. Typically, the verbose message stream is used to deliver information about command processing that is used for debugging a command.

    By default, the verbose message stream is not displayed, but you can display it by changing the value of the $VerbosePreference Variable or using the Verbose common parameter in any command.

PARAMETERS
    -Message <string>
        Specifies the message to display. This parameter is required. You can also pipe a message string to Verbose-Message.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue)
        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 the message to Write-Verbose.

OUTPUTS
    None
        Write-Verbose writes only to the verbose message stream.

NOTES

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

    C:\PS>Write-Verbose -Message “Searching the Application Event Log.”

    C:\PS> Write-Verbose -Message “Searching the Application Event Log.” -Verbose

    Description
    ———–
    These commands use the Write-Verbose cmdlet to display a status message. By default, the message is not displayed.

    The second command uses the Verbose common parameter, which displays any verbose messages, regardless of the value of the $VerbosePreference Variable.

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

    C:\PS>$VerbosePreference = “Continue”

    C:\PS> Write-Verbose “Copying file $filename”

    Description
    ———–
    These commands use the Write-Verbose cmdlet to display a status message. By default, the message is not displayed.

    The first command assigns a value of “Continue” to the $VerbosePreference preference Variable. The default value, “SilentlyContinue”, suppresses verbose messages.

    The second command writes a verbose message.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113429
    Write-Error
    Write-Warning
    about_preference_variables

Write-Warning

NAME
    Write-Warning

SYNOPSIS
    Writes a warning message.

SYNTAX
    Write-Warning [-Message] <string> [<CommonParameters>]

DESCRIPTION
    The Write-Warning cmdlet writes a warning message to the Windows PowerShell host. The response to the warning depends on the value of the user’s $WarningPreference Variable and the use of the WarningAction common parameter.

PARAMETERS
    -Message <string>
        Specifies the warning message.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue)
        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 the warning to Write-Warning.

OUTPUTS
    None
        Write-Warning writes only to the warning stream. It does not generate any other output.

NOTES

        The default value for the $WarningPreference Variable is “Continue”, which displays the warning and then continues executing the command. To determine valid values for a preference Variable such as $WarningPreference, set it to a string of random characters, such as “abc”. The resulting error message will list the valid values.

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

    C:\PS>Write-Warning “This is only a test warning.”

    Description
    ———–
    This command displays the message “WARNING: This is only a test warning.”

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

    C:\PS>$w = “This is only a test warning.”

    C:\PS> $w | Write-Warning

    Description
    ———–
    This example shows that you can use a pipeline operator (|) to send a string to Write-Warning. You can save the string in a Variable, as shown in this command, or pipe the string directly to Write-Warning.

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

    C:\PS>$warningpreference

    Continue

    C:\PS> Write-Warning “This is only a test warning.”
    This is only a test warning.

    C:\PS> $warningpreference = “SilentlyContinue”

    C:\PS> Write-Warning “This is only a test warning.”
    C:\PS>

    C:\PS> $warningpreference = “Stop”

    C:\PS> Write-Warning “This is only a test warning.”
    WARNING: This is only a test message.
    Write-Warning : Command execution stopped because the shell Variable “WarningPreference” is set to Stop.
    At line:1 char:14
    + Write-Warning <<<< “This is only a test message.”

    Description
    ———–
    This example shows the effect of the value of the $WarningPreference Variable on a Write-Warning command.

    The first command displays the default value of the $WarningPreference Variable, which is “Continue”. As a result, when you write a warning, the warning message is displayed and execution continues.

    When you change the value of the $WarningPreference Variable, the effect of the Write-Warning command changes again. A value of “SilentlyContinue” suppresses the warning. A value of “Stop” displays the warning and then stops execution of the command.

    For more information about the $WarningPreference Variable, see about_preference_variables.

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

    C:\PS>Write-Warning “This is only a test warning.” -WarningAction Inquire

    WARNING: This is only a test warning.

    Confirm
    Continue with this operation?
    [Y] Yes [A] Yes to All [H] Halt Command [S] Suspend [?] Help (default is “Y”):

    Description
    ———–
    This example shows the effect of the WarningAction common parameter on a Write-Warning command. You can use the WarningAction common parameter with any cmdlet to determine how Windows PowerShell responds to warnings resulting from that command. The WarningAction common parameter overrides the value of the $WarningPreference only for that particular command.

    This command uses the Write-Warning cmdlet to display a warning. The WarningAction common parameter with a value of “Inquire” directs the system to prompt the user when the command displays a warning.

    For more information about the WarningAction common parameter, see about_CommonParameters.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113430
    about_preference_variables
    about_CommonParameters
    Write-Debug
    Write-Error
    Write-Host
    Write-Output
    Write-Progress
    Write-Verbose

Update-TypeData

NAME
    Update-TypeData

SYNOPSIS
    Updates the current extended type configuration by reloading the *.types.ps1xml files into memory.

SYNTAX
    Update-TypeData [[-AppendPath] <string[]>] [-PrependPath <string[]>] [-Confirm] [-WhatIf] [<CommonParameters>]

DESCRIPTION
    The Update-TypeData cmdlet updates the current extended type configuration by reloading the *.types.ps1xml files into memory. Extended type information is normally loaded when Windows PowerShell requires the type information it contains. The Update-TypeData cmdlet can be used to preload all type information. It is particularly useful when you are developing types and want to load those new types for testing purposes.

    For more information about the *types.ps1xml files in Windows PowerShell, see about_types.ps1xml.

PARAMETERS
    -AppendPath <string[]>
        Specifies the path to the optional .ps1xml files that will be included in the list of files loaded. These are processed after the built-in files are loaded.

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

    -PrependPath <string[]>
        Specifies the path to the optional .ps1xml files that will be included in the list of files loaded. However, these files are processed in the order they are specified and before the built-in files are loaded.

        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 the append path to Update-TypeData.

OUTPUTS
    None
        This cmdlet does not return any output.

NOTES

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

    C:\PS>Update-TypeData

    Description
    ———–
    This example updates the extended type configuration from the *.types.ps1xml files.

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

    C:\PS>Update-TypeData -PrependPath typesA.types.Ps1xml, typesB.types.Ps1xml

    Description
    ———–
    This example updates the extended type configuration from the *.types.ps1xml files, processing the typesA and typesB files first.

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

Use-Transaction

NAME
    Use-Transaction

SYNOPSIS
    Adds the script block to the active transaction.

SYNTAX
    Use-Transaction [-TransactedScript] <scriptblock> [-UseTransaction] [<CommonParameters>]

DESCRIPTION
    The Use-Transaction cmdlet adds a script block to an active transaction. This enables you to do transacted scripting using transaction-enabled Microsoft .NET Framework objects. The script block can contain only transaction-enabled .NET Framework objects, such as instances of the Microsoft.PowerShell.Commands.Management.TransactedString class.

    The UseTransaction parameter, which is optional for most cmdlets, is required when using this cmdlet.

    The Use-Transaction cmdlet is one of a set of cmdlets that support the transactions feature in Windows PowerShell. For more information, see about_transactions.

PARAMETERS
    -TransactedScript <scriptblock>
        Specifies the script block that is run in the transaction. Enter any valid script block enclosed in braces ( { } ). This parameter is required.

        Required?                    true
        Position?                    1
        Default value                None
        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 this cmdlet.

OUTPUTS
    PSObject
        Use-Transaction returns the result of the transaction.

NOTES

        The Use-Transaction parameter includes the command in the active transaction. Because the Use-Transaction cmdlet is always used in transactions, this parameter is required to make any Use-Transaction command effective.

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

    C:\PS>Start-Transaction

    C:\PS> $transactedString = New-Object Microsoft.PowerShell.Commands.Management.TransactedString

    C:\PS> $transactedString.Append(“Hello”)
    C:\PS> Use-Transaction -TransactedScript { $transactedString.Append(“, World”) } -UseTransaction

    C:\PS> $transactedString.ToString()
    Hello

    C:\PS> Use-Transaction -TransactedScript { $transactedString.ToString() } -UseTransaction
    Hello, World

    C:\PS> Complete-Transaction
    C:\PS> $transactedString.ToString()
    Hello, World

    Description
    ———–
    This example shows how to use the Use-Transaction cmdlet to script against a transaction-enabled .NET Framework object. In this case, the object is a TransactedString object.

    The first command uses the Start-Transaction cmdlet to start a transaction.

    The second command uses the New-Object command to create a TransactedString object. It stores the object in the $TransactedString Variable.

    The third and fourth commands both use the Append method of the TransactedString object to add text to the value of $TransactedString. One command is part of the transaction; the other is not.

    The third command uses the Append method of the transacted string to add “Hello” to the value of $TransactedString. Because the command is not part of the transaction, the change is applied immediately.

    The fourth command uses the Use-Transaction cmdlet to add text to the string within the transaction. The command uses the Append method to add “, World” to the value of $TransactedString. The command is enclosed in braces ( {} ) to make it a script block. The UseTransaction parameter is required in this command.

    The fifth and sixth commands use the ToString method of the TransactedString object to display the value of the TransactedString as a string. Again, one command is part of the transaction; the other is not.

    The fifth command uses the ToString method to display the current value of the $TransactedString Variable. Because it is not part of the transaction, it displays only the current state of the string.

    The sixth command uses the Use-Transaction cmdlet to run the same command within the transaction. Because the command is part of the transaction, it displays the current value of the string within the transaction, much like a preview of the transaction changes.

    The seventh command uses the Complete-Transaction cmdlet to commit the transaction.

    The final command uses the ToString method to display the resulting value of the Variable as a string.

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

    C:\PS>Start-Transaction

    C:\PS> $transactedString = New-Object Microsoft.PowerShell.Commands.Management.TransactedString

    C:\PS> $transactedString.Append(“Hello”)
    C:\PS> Use-Transaction -TransactedScript { $transactedString.Append(“, World”) } -UseTransaction

    C:\PS> Undo-Transaction

    C:\PS> $transactedString.ToString()
    Hello

    Description
    ———–
    This example shows the effect of rolling back a transaction that includes Use-Transaction commands. Like all commands in a transaction, when the transaction is rolled back, the transacted changes are discarded and the data is unchanged.

    The first command uses the Start-Transaction cmdlet to start a transaction.

    The second command uses the New-Object command to create a TransactedString object. It stores the object in the $TransactedString Variable.

    The third command, which is not part of the transaction, uses the Append method to add “Hello” to the value of $TransactedString.

    The fourth command uses the Use-Transaction cmdlet to run another command that uses the Append method within the transaction. The command uses the Append method to add “, World” to the value of $TransactedString.

    The fifth command uses the Undo-Transaction cmdlet to roll back the transaction. As a result, all commands performed within the transaction are reversed.

    The final command uses the ToString method to display the resulting value of $TransactedString as a string. The results show that only the changes made outside of the transaction were applied to the object.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=135271
    about_transactions
    Start-Transaction
    Get-Transaction
    Complete-Transaction
    Undo-Transaction

Wait-Event

NAME
    Wait-Event

SYNOPSIS
    Waits until a particular event is raised before continuing to run.

SYNTAX
    Wait-Event [[-SourceIdentifier] <string>] [-Timeout <int>] [<CommonParameters>]

DESCRIPTION
    The Wait-Event cmdlet suspends execution of a script or Function until a particular event is raised. Execution resumes when the event is detected. To cancel the wait, press CTRL+C.

    This feature provides an alternative to polling for an event. It also allows you to determine the response to an event in two different ways: by using the Action parameter of the event subscription and by waiting for an event to return and then respond with an action.

PARAMETERS
    -SourceIdentifier <string>
        Waits only for events with the specified source identifier. By default, Wait-Events waits for any event.

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

    -Timeout <int>
        Determines the maximum time, in seconds, that Wait-Event waits for the event to occur. The default, -1, waits indefinitely. The timing starts when you submit the Wait-Event command.

        If the specified time is exceeded, the wait ends and the command prompt returns, even if the event has not been raised. No error message is displayed.

        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

OUTPUTS
    System.String

NOTES

        Events, event subscriptions, 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>Wait-Event

    Description
    ———–
    This command waits for the next event that is raised.

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

    C:\PS>Wait-Event -SourceIdentifier “ProcessStarted”

    Description
    ———–
    This command waits for the next event that is raised and that has a source identifier of “ProcessStarted”.

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

    C:\PS>$timer.Interval = 2000
    C:\PS> $timer.Autoreset = $false
    C:\PS> $timer.Enabled = $true; Wait-Event Timer.Elapsed

    # After 2 seconds

    EventIdentifier : 12
    Sender         : System.Timers.Timer
    SourceEventArgs : System.Timers.ElapsedEventArgs
    SourceArgs     : {System.Timers.Timer, System.Timers.ElapsedEventArgs}
    SourceIdentifier : Timer.Elapsed
    TimeGenerated    : 6/10/2008 3:24:18 PM
    MessageData     :
    ForwardEvent     : False

    Description
    ———–
    This command uses the Wait-Event cmdlet to wait for a timer event on a timer that is set for 2000 milliseconds.

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

    C:\PS>Wait-Event -SourceIdentifier “ProcessStarted” -Timeout 90

    Description
    ———–
    This command waits up to 90 seconds for the next event that is raised and that has a source identifier of “ProcessStarted”. If the specified time expires, the wait ends.

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

Wait-Job

NAME
    Wait-Job

SYNOPSIS
    Suppresses the command prompt until one or all of the Windows PowerShell background jobs running in the session are complete.

SYNTAX
    Wait-Job [[-InstanceId] <Guid[]>] [-Any] [-Timeout <int>] [<CommonParameters>]

    Wait-Job [-Job] <Job[]> [-Any] [-Timeout <int>] [<CommonParameters>]

    Wait-Job [[-Name] <string[]>] [-Any] [-Timeout <int>] [<CommonParameters>]

    Wait-Job [-Id] <Int32[]> [-Any] [-Timeout <int>] [<CommonParameters>]

    Wait-Job [-State {NotStarted | Running | Completed | Failed | Stopped | Blocked}] [-Any] [-Timeout <int>] [<CommonParameters>]

DESCRIPTION
    The Wait-Job cmdlet waits for Windows PowerShell background jobs to complete before it displays the command prompt. You can wait until any background job is complete, or until all background jobs are complete, and you can set a maximum wait time for the job.

    You can use Wait-Job to get background jobs that were started by using Start-Job or the AsJob parameter of Invoke-Command.

    When the commands in the job are complete, Wait-Job displays the command prompt and returns a job object so that you can pipe it to another command.

PARAMETERS
    -Any [<SwitchParameter>]
        Displays the command prompt (and returns the job object) when any job completes. By default, Wait-Job waits until all of the specified jobs are complete before displaying the prompt.

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

    -Id <Int32[]>
        Waits for jobs with the specified IDs.

        The ID is an integer that uniquely identifies the job within the current session. It is easier to remember and type than the InstanceId, but it is unique only within the current session. You can type one or more IDs (separated by commas). To find the ID of a job, type “Get-Job” without parameters.

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

    -InstanceId <Guid[]>
        Waits for jobs with the specified instance IDs. The default is all jobs.

        An instance ID is a GUID that uniquely identifies the job on the computer. To find the instance ID of a job, use Get-Job.

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

    -Job <Job[]>
        Waits for the specified jobs. Enter a Variable that contains the job objects or a command that gets the job objects. You can also use a pipeline operator to send job objects to the Wait-Job cmdlet. By default, Wait-Job waits for all jobs created in the current session.

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

    -Name <string[]>
        Waits for jobs with the specified friendly name.

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

    -State <JobState>
        Waits for jobs in the specified state. Valid values are NotStarted, Running, Completed, Stopped, Failed, and Blocked.

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

    -Timeout <int>
        Determines the maximum wait time for each background job, in seconds. The default, -1, waits until the job completes, no matter how long it runs. The timing starts when you submit the Wait-Job command, not the Start-Job command.

        If this time is exceeded, the wait ends and the command prompt returns, even if the job is still running. No error message is displayed.

        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.Management.Automation.RemotingJob
        You can pipe a job object to Wait-Job.

OUTPUTS
    System.Management.Automation.RemotingJob
        Wait-Job returns job objects that represent the completed jobs. If the wait ends because the value of the Timeout parameter is exceeded, Wait-Job does not return any objects.

NOTES

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

    C:\PS>Get-Job | Wait-Job

    Description
    ———–
    This command waits for all of the background jobs running in the session to complete.

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

    C:\PS>$s = New-PSSession server01, server02, server03

    C:\PS> Invoke-Command -session $s -scriptblock {Start-Job -name Date1 -scriptblock {Get-Date}}

    C:\PS> $done = Invoke-Command -session $s -command {Wait-Job -name Date1}

    C:\PS> $done.count
    3

    Description
    ———–
    This example shows how to use the Wait-Job cmdlet with jobs started on remote computers by using the Start-Job cmdlet. Both the Start-Job and Wait-Job commands are submitted to the remote computer by using the Invoke-Command cmdlet.

    This example uses Wait-Job to determine whether a Get-Date command running as a background job on three different computers is complete.

    The first command creates a Windows PowerShell session (PSSession) on each of the three remote computers and stores them in the $s Variable.

    The second command uses the Invoke-Command cmdlet to run a Start-Job command in each of the three sessions in $s. All of the jobs are named Date1.

    The third command uses the Invoke-Command cmdlet to run a Wait-Job command. This command waits for the Date1 jobs on each computer to complete. It stores the resulting collection (array) of job objects in the $done Variable.

    The fourth command uses the Count property of the array of job objects in the $done Variable to determine how many of the jobs are complete.

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

    C:\PS>$s = New-PSSession (Get-Content machines.txt)

    C:\PS> $c = ‘Get-Eventlog -log system | where {$_.EntryType -eq “error” -and $_.Source -eq “LSASRV”} | Out-File errors.txt’

    C:\PS> Invoke-Command -session $s -scriptblock {param($c)Start-Job -scriptblock {$c}} -ArgumentList $c

    C:\PS> Invoke-Command -session $s -scriptblock {Wait-Job -Any}

    Description
    ———–
    This example uses the Any parameter of Wait-Job to determine when the first of many background jobs running in the current session are complete. It also shows how to use the Wait-Job cmdlet to wait for remote jobs to complete.

    The first command creates a PSSession on each of the computers listed in the Machines.txt file and stores the PSSessions in the $s Variable. The command uses the Get-Content cmdlet to get the contents of the file. The Get-Content command is enclosed in parentheses to ensure that it runs before the New-PSSession command.

    The second command stores a Get-EventLog command string (in quotation marks) in the $c Variable.

    The third command uses the Invoke-Command cmdlet to run a Start-Job command in each of the sessions in $s. The Start-Job command starts a background job that runs the command in $c.

    Because the $c Variable is on the local computer, the command uses the “param” keyword to declare the local Variables in the command and the ArgumentList parameter to supply the values for those Variables.

    The fourth command uses the Invoke-Command cmdlet to run a Wait-Job command in the sessions. It uses the Wait-Job cmdlet to wait until the first job on the remote computers is complete.

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

    C:\PS>$s = New-PSSession Server01, Server02, Server03

    C:\PS> $jobs = Invoke-Command -session $s -scriptblock {Start-Job -script {Get-Date}}

    C:\PS> $done = Invoke-Command -session $s -scriptblock {Wait-Job -Timeout 30}

    Description
    ———–
    This example shows how to use the Timeout parameter of Wait-Job to set a maximum wait time for the jobs running on remote computers.

    The first command creates a PSSession on each of three remote computers (Server01, Server02, and Server03), and it saves the PSSessions in the $s Variable.

    The second command uses the Invoke-Command cmdlet to run a Start-Job command in each of the PSSessions in $s. It saves the resulting job objects in the $jobs Variable.

    The third command uses the Invoke-Command cmdlet to run a Wait-Job command in each of the PSSessions in $s. The Wait-Job command determines whether all of the commands have completed within 30 seconds. It uses the Timeout parameter with a value of 30 (seconds) to establish the maximum wait time and saves the results of the command in the $done Variable.

    In this case, after 30 seconds, only the command on the Server02 computer has completed. Wait-Job ends the wait, displays the command prompt, and returns the object that represents the job that was completed.

    The $done Variable contains a job object that represents the job that ran on Server02.

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

    C:\PS>Wait-Job -Id 1,2,5 -Any

    Description
    ———–
    This command identifies three jobs by their IDs and waits until any of them are complete. The command prompt returns when the first job completes.

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

    C:\PS>Wait-Job -name DailyLog -Timeout 120

    Description
    ———–
    This command waits 120 seconds (two minutes) for the DailyLog job to complete. If the job does not complete in the next two minutes, the command prompt returns anyway, and the job continues to run in the background.

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

    C:\PS>Wait-Job -name Job3

    Description
    ———–
    This Wait-Job command uses the job name to identify the job to wait for.

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

    C:\PS>C:\PS> $j = Start-Job -script {Get-ChildItem *.ps1| where {$_lastwritetime -gt ((Get-Date) – (New-TimeSpan -days 7))}}

    C:\PS> $j | Wait-Job

    Description
    ———–
    This example shows how to use the Wait-Job cmdlet with jobs started on the local computer by using the Start-Job cmdlet.

    These commands start a job that gets the Windows PowerShell script files that were added or updated in the last week.

    The first command uses the Start-Job cmdlet to start a background job on the local computer. The job runs a Get-ChildItem command that gets all of the files with a “.ps1” file name extension that were added or updated in the last week.

    The third command uses the Wait-Job cmdlet to wait until the job is complete. When the job completes, the command displays the job object, which contains information about the job.

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

    C:\PS>$s = New-PSSession Server01, Server02, Server03

    C:\PS> $j = Invoke-Command -session $s -scriptblock {Get-Process} -asjob

    C:\PS> $j | Wait-Job

    Description
    ———–
    This example shows how to use the Wait-Job cmdlet with jobs started on remote computers by using the AsJob parameter of the Invoke-Command cmdlet. When using AsJob, the job is created on the local computer and the results are automatically returned to the local computer, even though the job runs on the remote computers.

    This example uses Wait-Job to determine whether a Get-Process command running in the sessions on three remote computers is complete.

    The first command creates PSSessions on three computers and stores them in the $s Variable.

    The second command uses the Invoke-Command cmdlet to run a Get-Process command in each of the three PSSessions in $s. The command uses the AsJob parameter to run the command asynchronously as a background job. The command returns a job object, just like the jobs started by using Start-Job, and the job object is stored in the $j Variable.

    The third command uses a pipeline operator (|) to send the job object in $j to the Wait-Job cmdlet. Notice that an Invoke-Command command is not required in this case, because the job resides on the local computer.

    ————————– EXAMPLE 10 ————————–

    C:\PS>Get-Job

    Id Name     State     HasMoreData     Location             Command
    — —-     —–     ———–     ——–             ——-
    1    Job1     Completed True            localhost,server01.. Get-Service
    4    Job4     Completed True            localhost            dir | where

    C:\PS> Wait-Job -Id 1

    Description
    ———–
    This command waits for the job with an ID value of 1.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113422
    about_jobs
    about_job_details
    about_remote_Jobs
    Start-Job
    Get-Job
    Receive-Job
    Stop-Job
    Remove-Job
    Invoke-Command

Wait-Process

NAME
    Wait-Process

SYNOPSIS
    Waits for the processes to be stopped before accepting more input.

SYNTAX
    Wait-Process [-Id] <Int32[]> [[-Timeout] <int>] [<CommonParameters>]

    Wait-Process -InputObject <Process[]> [[-Timeout] <int>] [<CommonParameters>]

    Wait-Process [-Name] <string[]> [[-Timeout] <int>] [<CommonParameters>]

DESCRIPTION
    The Wait-Process cmdlet waits for one or more running processes to be stopped before accepting input. In the Windows PowerShell console, this cmdlet suppresses the command prompt until the processes are stopped. You can specify a process by process name or process ID (PID), or pipe a process object to Wait-Process.

    Wait-Process works only on processes running on the local computer.

PARAMETERS
    -Id <Int32[]>
        Specifies the process IDs of the processes. To specify multiple IDs, use commas to separate the IDs. To find the PID of a process, type “Get-Process“. The parameter name (“Id”) is optional.

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

    -InputObject <Process[]>
        Specifies the processes by submitting process objects. Enter a Variable that contains the process objects, or type a command or expression that gets the process objects, such as a Get-Process command.

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

    -Name <string[]>
        Specifies the process names of the processes. To specify multiple names, use commas to separate the names.

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

    -Timeout <int>
        Determines the maximum time, in seconds, that Wait-Process waits for the specified processes to stop. When this interval expires, the command displays a non-terminating error that lists the processes that are still running, and ends the wait.

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

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

INPUTS
    System.Diagnostics.Process
        You can pipe a process object to Wait-Process.

OUTPUTS
    None
        This cmdlet does not generate any output.

NOTES

        This cmdlet uses the WaitForExit method of the System.Diagnostics.Process class. For more information about this method, see the Microsoft .NET Framework SDK.

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

    C:\PS>$nid = (Get-Process notepad).id

    C:\PS> Stop-Process -id $nid

    C:\PS> Wait-Process -id $nid

    Description
    ———–
    These commands stop the Notepad process and then wait for the process to be stopped before proceeding with the next command.

    The first command uses the Get-Process cmdlet to get the ID of the Notepad process. It saves it in the $nid Variable.

    The second command uses the Stop-Process cmdlet to stop the process with the ID saved in $nid.

    The third command uses the Wait-Process cmdlet to wait until the Notepad process is stopped. It uses the ID parameter of Wait-Process to identify the process.

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

    C:\PS>$p = Get-Process notepad

    C:\PS> Wait-Process -id $p.id

    C:\PS> Wait-Process -Name notepad

    C:\PS> Wait-Process -inputobject $p

    Description
    ———–
    These commands show three different methods of specifying a process to the Wait-Process cmdlet. The first command gets the Notepad process and saves it in the $p Variable.

    The second command uses the ID parameter, the third command uses the Name parameter, and the fourth command uses the InputObject parameter.

    These commands have the same results and can be used interchangeably.

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

    C:\PS>Wait-Process -Name outlook, winword -Timeout 30

    Description
    ———–
    This command waits 30 seconds for the Outlook and Winword processes to stop. If both processes are not stopped, the cmdlet displays a non-terminating error and the command prompt.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=135277
    Get-Process
    Start-Process
    Stop-Process
    Wait-Process
    Debug-Process

Where-Object

NAME
    Where-Object

SYNOPSIS
    Creates a filter that controls which objects will be passed along a command pipeline.

SYNTAX
    Where-Object [-FilterScript] <scriptblock> [-InputObject <psobject>] [<CommonParameters>]

DESCRIPTION
    The Where-Object cmdlet selects objects from the set of objects that are passed to it. It uses a script block as a filter and evaluates the script block for each object. If the result of the evaluation is True, the object is returned. If the result of the evaluation is not True, the object is ignored.

PARAMETERS
    -FilterScript <scriptblock>
        Specifies the script block that is used to filter the objects. Enclose the script block in braces ( {} ).

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

    -InputObject <psobject>
        Specifies the objects to be filtered. You can also pipe the objects to Where-Object.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     true (ByValue)
        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 the objects to be filtered to Where-Object.

OUTPUTS

NOTES

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

    C:\PS>Get-Service | Where-Object {$_.Status -eq “Stopped”}

    Description
    ———–
    This command gets a list of all services that are currently stopped. The “$” symbol represents each object that is passed to the Where-Object cmdlet.

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

    C:\PS>Get-Process | Where-Object {$_.workingset -gt 25000*1024}

    Description
    ———–
    This command lists processes that have a working set greater than 25,000 kilobytes (KB). Because the value of the WorkingSet property is stored in bytes, the value of 25,000 is multiplied by 1,024.

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

    C:\PS>Get-Process | Where-Object { $_.ProcessName -match “^p.*” }

    Description
    ———–
    This command gets the processes with a ProcessName property that begins with the letter “p”. The match operator enables you to use regular expressions within a Where clause.

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

    C:\PS>Get-Process -name svchost | Where-Object {$True}

    Description
    ———–
    This command lists all of the processes named “svchost”.

    The Where-Object cmdlet evaluates the script block, which typically includes a reference to the object currently in the pipeline ($_), and casts the results to a Boolean type: True or False. If the result is True, the object is returned. Otherwise, it is discarded.

    In this case, the script block just returns True, so all the objects are returned.

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

Write-Debug

NAME
    Write-Debug

SYNOPSIS
    Writes a debug message to the console.

SYNTAX
    Write-Debug [-Message] <string> [<CommonParameters>]

DESCRIPTION
    The Write-Debug cmdlet writes debug messages to the console from a script or command.

    By default, debug messages are not displayed in the console, but you can display them by using the Debug parameter or the $DebugPreference Variable.

PARAMETERS
    -Message <string>
        Specifies the debug message to send to the console.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue)
        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 debug message to Write-Debug.

OUTPUTS
    None
        Write-Debug writes only to the debug stream. It does not return any output.

NOTES

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

    C:\PS>Write-Debug “Cannot open file.”

    Description
    ———–
    This command writes a debug message. Because the value of $DebugPreference is “SilentlyContinue”, the message is not displayed in the console.

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

    C:\PS>$DebugPreference

    SilentlyContinue

    C:\PS> Write-Debug “Cannot open file.”
    C:\PS>

    C:\PS> Write-Debug “Cannot open file.” -Debug
    DEBUG: Cannot open file.

    Description
    ———–
    This example shows how to use the Debug common parameter to override the value of the $DebugPreference Variable for a particular command.

    The first command displays the value of the $DebugPreference Variable, which is “SilentlyContinue”, the default.

    The second command writes a debug message but, because of the value of $DebugPreference, the message does not appear.

    The third command writes a debug message. It uses the Debug common parameter to override the value of $DebugPreference and to display the debug messages resulting from this command.

    As a result, even though the value of $DebugPreference is “SilentlyContinue”, the debug message appears.

    For more information about the Debug common parameter, see about_CommonParameters.

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

    C:\PS>$DebugPreference

    SilentlyContinue

    C:\PS> Write-Debug “Cannot open file.”
    C:\PS>

    C:\PS> $DebugPreference = “Continue”

    C:\PS> Write-Debug “Cannot open file.”
    DEBUG: Cannot open file.

    Description
    ———–
    This command shows the effect of changing the value of the $DebugPreference Variable on the display of debug messages.

    The first command displays the value of the $DebugPreference Variable, which is “SilentlyContinue”, the default.

    The second command writes a debug message but, because of the value of $DebugPreference, the message does not appear.

    The third command assigns a value of “Continue” to the $DebugPreference Variable.

    The fourth command writes a debug message, which appears on the console.

    For more information about $DebugPreference, see about_preference_variables.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113424
    Write-Verbose
    Write-Error
    Write-Host
    Write-Progress
    Write-Output
    Write-Warning