Skip to main content

Reading Help Files (Part 5 of 7)

The full help file for any cmdlet is the golden ticket to getting the PowerShell pipeline to work.  Go ahead and get the full help file for Stop-Process.

Get-Help Stop-Process –Full

The full help file contains everything.  Let’s look at some of the differences between Full and Detailed help.

The first difference is with the parameters section.  Extra data is displayed for each parameter.

     -Id
        Specifies the process IDs of the processes to be stopped. 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                none
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

The Required attribute tells us if this is a mandatory parameter.

Position will let you know if this is a positional parameter or a named parameter.  In this case, let’s stop the process with an ID of 6944.  Since the ID parameter is positional, we can accomplish this in one of two ways.

Stop-Process –ID 6924
Stop-Process 6924

With positional parameters, you can omit the parameter name as long as you provide a value of the correct data type.  If the parameter is named, you must provide the parameters name to use it.  In this case, -ID­ is in position #1.

The Default value will tell me if a default value is provided if I do not specify one.  Ypu will find that many cmdlets with a –ComputerName parameter has a default value of LocalHost.

We use the Accept pipeline input attribute to determine if we can use the PowerShell pipeline with this parameter.  In this case, we can.

The final attribute tells us if a wild card is accepted for the argument of this parameter.  In this case, no it is not.

Next is the INPUTS and OUTPUTS:
INPUTS
    System.Diagnostics.Process
       
       
   
        You can pipe a process object to Stop-Process.
   
   
OUTPUTS
    None or System.Diagnostics.Process
       
       
   
        When you use the PassThru parameter, Stop-Process returns a System.Diagnostics.Process object that represents the stopped process. Otherwise, this
        cmdlet does not generate any output.

This section tells us what kind of object can be passed to this cmdlet and what we should expect out of it.

The NOTES section provides extra information that may not fall under any of the other categories.
    
NOTES
   
   
        You can also refer to Stop-Process by its built-in aliases, "kill" and "spps". For more information, see about_Aliases.
       
        You can also use the properties and methods of the Windows Management Instrumentation (WMI) Win32_Process object in Windows PowerShell. For more
        information, see Get-WmiObject and the WMI SDK.
       
        When stopping processes, be aware that stopping a process can stop process and services that depend on the process. In an extreme case, stopping a
        process can stop Windows.
        


Tomorrow we will wrap things up with regards to cmdlets with a few extra tips.

Comments

Popular posts from this blog

Sticky Key problem between Windows Server 2012 and LogMeIn

This week I instructed my first class using Windows Server 2012 accessed via LogMeIn and discovered a Sticky Key problem every time you press the Shift key. Here is my solution to resolve this.  First off, in the Preferences of LogMeIn for the connection to the Windows Server, click General . Change the Keyboard and mouse priority to Host side user and click Apply at the bottom. On the Windows 2012 server, open the Control Panel – Ease of Access – Change how your keyboard works . Uncheck Turn on Sticky Keys . Click Set up Sticky Keys . Uncheck Turn on Sticky Keys when SHIFT is pressed five times . Click OK twice. If you are using Windows Server 2012 as a Hyper-V host, you will need to redo the Easy of Use settings on each guest operating system in order to avoid the Sticky Key Problem. Updated Information: March 20, 2013 If you continue to have problems, Uncheck Turn on Filter Keys .

Where did a User’s Account Get Locked Out?

Updated: May 15, 2015 When this article was originally published, two extra carriage returns were add causing the code to malfunction.  The code below is correct.   My client for this week’s PowerShell class had a really interesting question. They needed to know where an account is being locked out at. OK, interesting. Apparently users hop around clients and forget to log off, leading to eventual lock out of their accounts. The accounts can be unlocked, but are then relocked after Active Directory replication. This problem is solved in two parts. The first one is to modify the event auditing on the network. The second part is resolved with PowerShell. The first part involves creating a group policy that will encompass your Domain Controllers. In this GPO, make these changes. Expand Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy Configuration \ Audit Policies \ Account Management Double click User Account Management C...

How to run GPResult on a remote client with PowerShell

In the past, to run the GPResult command, you would need to either physically visit this client, have the user do it, or use and RDP connection.  In all cases, this will disrupt the user.  First, you need PowerShell remoting enabled on the target machine.  You can do this via Group Policy . Open PowerShell and type this command. Invoke-Command –ScriptBlock {GPResult /r} –ComputerName <ComputerName> Replace <ComputerName> with the name of the target.  Remember, the target needs to be online and accessible to you.