Learn about Windows PowerShell
Summary: Microsoft Scripting Guy, Ed Wilson, talks about using a preference variable to provide detailed Windows PowerShell command lifecycle information.
Microsoft Scripting Guy, Ed Wilson, is here. This has certainly been an interesting Windows PowerShell week. Yes indeed, it has been a fine Windows PowerShell week. The week began with a trip to Redmond to meet with the members of the Windows PowerShell team, my manager, and other teammates; and it ended with Windows PowerShell Saturday in Charlotte, North Carolina. In between, I had a few minutes to play around with Windows PowerShell 3.0 (on the plane going to and coming from Seattle, in my room at night, and between meetings). I was also able to catch up a bit on some email. So yes, all-in-all it was a fine Windows PowerShell week!
There are 30 Windows PowerShell 3.0 preference variables. These variables change and control the way that Windows PowerShell behaves. In fact, I would say that in 99.99 percent of the cases, the default values are perfect. For special situations or for unique requirements, I need to know what the preference variables are, what they do, and how to change them.
Luckily, there is About Help. In Windows PowerShell, there are two types of Help, the cmdlet Help (these topics get all the good press) and About Help. About Help is conceptual in nature. Many of these topics have quite detailed information (I know because I wrote some of them). About Help is ignored by the majority of Windows PowerShell users, but these topics should be read by anyone who desires to have a deeper understanding of how Windows PowerShell works.
I still find myself reading certain topics again and again just to verify that I have not forgotten some particular nuance about the way Windows PowerShell works or picked up any “bad habits” (I had to retype this sentence because Word autocorrected to “bad hobbits.” Personally, I have never met a bad hobbit.”) To find all About Help, use the Get-Help cmdlet, and supply about* to it (the Help function contains more, and it therefore pages results one at a time). The command is shown here.
To log the lifecycle of Windows PowerShell commands to the Windows PowerShell event log, set the value of LogCommandLifecycleEvent to true as shown here.
$LogCommandLifecycleEvent = $true
I do not need to restart Windows, nor do I need to restart Windows PowerShell—all I need to do is to type a command. At that point, the lifecycle of the command writes to the Windows PowerShell log. I can, of course, use Windows PowerShell to obtain the information. To query the Windows PowerShell event log, I can use the Get-EventLog cmdlet. Keep in mind, that there is a space in Windows PowerShell, and therefore, you need quotation marks around the log name. The command is shown here.
Get-EventLog -LogName "windows powershell"
Command lifecycle Started are Event ID 500. Command lifecycle Stopped are Event ID 501. Therefore, typing a simple command like Get-Process generates a number of events. These events are shown here.
Get-EventLog -LogName "windows powershell" | ft timegenerated, instanceid, message -auto –Wrap
The command and the associated output are shown here.
To get a better idea of what is going on, select only the Message property as shown here.
Get-EventLog -LogName "windows powershell" | select message
When I do this, I see the lifecycle. Get-Process starts, then Out-Lineoutput, then Format-Default. This is shown here. The commands appear in reverse order, so read from bottom to top.
Command "format-default" is Started. ...
Command "out-lineoutput" is Started. ...
Command "Get-Process" is Started. ...
Next, the same commands stop. This is shown here.
Command "out-lineoutput" is Stopped. ...
Command "format-default" is Stopped. ...
Command "Get-Process" is Stopped. ...
Can this information help me troubleshoot a Windows PowerShell issue? Who knows, but it is interesting; and I can definitely say that if I had not run across it, I would not be able to use it if or when an issue did arise. Play with the preference variables, see what you can come up with that will help, and then share your results with the community. After all, that is what community is all about.
Join me tomorrow when I will talk about more cool Windows PowerShell stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
This is interesting, I had no idea this existed. I've had some trouble with gwmi -asjob's running remotely and I'll have to use this to see what details are exposed.
To make it short, always helpful. :)
@Brian Wilhite yes, it is not something one would use on a regular basis, but it can provide great insight when needed.
@Livio von Buren thanks! You are welcome. Glad you like it.