Chapter 17. Processes, Services, Event Logs

In your daily work as an administrator, you often have to deal with programs (processes), services, and innumerable entries in event logs so this is a good opportunity to put into practice the basic knowledge you gained from the first 12 chapters. The examples and topics covered in this chapter are meant to give you an idea of the full range of options.

In the course of your reading, you will no doubt rack your brains occasionally and find yourself flipping back pages to the introductory chapters. What's really astonishing are the many and diverse options you have in using the PowerShell pipeline (as discussed in Chapter 5) and associated formatting cmdlets to wring out every last bit of data from pipeline objects. What was just dry theory in Chapter 5 will now become very interesting in the following.

Topics Covered:

• Processes
  • Starting Processes
  • Monitoring Processes
  • Filtering and Clearly Displaying Processes
  • Counting Processes
  • Accessing Process Objects
  • Stopping Processes
• Services
  • Table 17.1: Cmdlets for managing services
  • Listing Services
  • Starting, Stopping, Suspending, Resuming Services
  • Figure 17.1: Use the services snap-in to check your modifications
• Event Log
  • Figure 17.2: Picking out PowerShell events and exporting them to Excel
  • Writing Entries to the Event Log
  • Figure 17.3: Events you make may look a little strange

Processes

Processes are basically running programs as most routine tasks can be mastered using the cmdlets Get-Process and Stop-Process. In addition, processes can also be controlled directly by the objects and methods of the .NET framework.

Starting Processes

Starting processes is inherent in the console. You can launch any executable program in a directory named in the PATH environment variable simply by typing its name:

But note how PowerShell loses control over Windows applications. After applications start, they are left to their own devices since PowerShell can't directly access these processes once they've started. Direct control of a process is only possible if you start the process using the Start() .NET method, which enables you to check whether a process still responds or is terminated. You can also force a process to stop running:

You can even use WaitForExit() to get PowerShell to wait until the process exits, which comes in handy inside PowerShell scripts when you want to make sure that a process has completed its task before you go on to the next step:

Monitoring Processes

Get-Process retrieves all running processes. What applies here applies in general to PowerShell: the cmdlet retrieves Process objects as result, not text. Text will appear only if you output the result of Get-Process to the console:

Each Process object contains more information than is displayed in the console. To view all properties, send the result to a formatting cmdlet like Format-List and append with an asterisk:

Filtering and Clearly Displaying Processes

As described in Chapter 5, you can use pipeline filters to work on lists of processes. If you were only interested in processes that have been running for less than three hours, you could find them like this:

If you want start times displayed, append the property you seek to Format-Table. As shown in Chapter 5, the next statement adds a new Minutes column that calculates the elapsed time in minutes since a program began running:

Counting Processes

Processes can be counted rather easily because the result of Get-Process is (nearly) always an array, which comes with the Count property. Get-Process won't necessarily return the result as an array; only if the result is a single process or no process at all. That's why you should always first convert the result into an array before you determine the number of array elements:

Another sort of "measurement" is carried out by Measure-Object. It makes a statistical evaluation of a particular object property. For example, if you wanted to know what the minimum, maximum, and average values of the PagedSystemMemorySize property are, proceed as follows:

Accessing Process Objects

Each Process object contains methods and properties. As discussed in detail in Chapter 6, many properties may be read as well as modified, and methods can be executed like commands. This allows you to control many fine settings of processes. For example, you can specifically raise or lower the priority of a process. The next statement lowers the priority of all Notepads:

Stopping Processes

You can use Stop-Process to stop running processes, but that can be risky because PowerShell makes it so very easy to do. The following statement closes all opened Notepads and does so without asking for confirmation—even when the Notepads contain unsaved text:

However, a small safety measure is integrated that forces you to specify the -name parameter. The standard parameter that you can use even without a parameter name is for Stop-Process the process ID.

Services

Services are special programs, which are executed unsupervised and require no interactive logon session. Services provide functions usually not linked to any individual user. You should use the following PowerShell cmdlets to manage services:

Listing Services

Get-Service works like Get-Process and Get-ChildItem: it returns service objects that meet your criterion. All services will be listed if you don't specify any criterion. Use Where-Object in the pipeline if you want to filter the result:

Starting, Stopping, Suspending, Resuming Services

To start, stop, temporarily suspend, or restart a service, all you have to do is to clearly identify the service. Get-Service will retrieve the service for you, which you can then pass on to one of the other cmdlets listed in Table 17.1.

For example, the following statement stops the service called Parental Controls on Windows Vista. Of course, this will only work if you have administrator rights (and the service has to be running as well):

Figure 17.1: Use the services snap-in to check your modifications

Event Log

Windows makes records of all malfunctions, warnings, and other information in its event logs. You can use the Get-Eventlog cmdlet to access log entries. That's a prudent thing to do because event logs are jam-packed with information, and PowerShell is absolutely the right tool to extract the important information they contain.

Use the -list parameter to find out what event logs are on your system. The Entries column should already give you a rough idea of how much information is being collected in some of your event logs:

If you wanted to get a display of all the entries in the System log, you would no doubt agree that there's just too much information to be helpful:

That's why you should use the PowerShell filters. Use Where-Object to pass the information retrieved by Get-Eventlog through the pipeline while allowing only those entries through that meet your criteria. The next statement reads only those events from the PowerShell event log that match the type, "Information", and have today's date. To do so, PowerShell compares the contents of the TimeWrittenproperty with today's date. Since only the date, and not the time, are supposed to be compared, PowerShell compares the result of Date(), a method of the DateTime type that sets the time to zero.

Access to the event logs is easy, but it's a more difficult matter to find your way around the information in the logs and to create the right filters to extract the right information. However, once you have mastered that, you can process information in Excel by using Export-Csv:

Figure 17.2: Picking out PowerShell events and exporting them to Excel

Writing Entries to the Event Log

PowerShell officially supports only the reading of events. However, since you can always resort to the methods of the .NET framework, making your own entries is no problem:

The Event Viewer shows you that it was successful:

Figure 17.3: Events you make may look a little strange

What happened here is that the event you made was properly written, but because you aren't known as an event log source, the event display is hard to understand.