Summary: Microsoft MVP, Arnaud Petitjean, provides expert commentary for 2012 Scripting Games Advanced Event 9.

Microsoft Scripting Guy, Ed Wilson, is here. Arnaud Petitjean is the expert commentator for Advanced Event 9.

Arnaud is an author, speaker, system engineer, and trainer. Arnaud is the founder of the French-speaking Windows PowerShell Community. He specializes in managing VMware (by using Windows PowerShell and PowerCLI) and in desktop virtualization.

Website: www.PowerShell-Scripting.com

Hi! This is Arnaud Petitjean from Montreal. Today we are going to learn how to deal with XML files. Like almost everything with Windows PowerShell, you will see that it is very easy and straightforward.

But first, before generating any file, we need to gather the data about the computer hardware. When we deal with system information, you should immediately start thinking about Windows Management Instrumentation (WMI). Indeed, WMI is a real gold mine. With it, you can collect hardware and software information, as well as interact with a computer locally or remotely in an easy manner. The only “complicated” part of WMI is to find out where the information we need is located.

You should keep in mind that for how huge WMI is, most information related to computer hardware and the operating system are located in the classes respectively named Win32_ComputerSystem and Win32_OperatingSystem.

How do I know that? Well, it’s called “experience.” And it comes over time…

One of the trickiest parts of this event is, in my opinion, to get the MAC address of the primary network interface. To achieve this goal, we need to find out (one more time), where this property is located. One possibility would be to use a tool like WMI Explorer to search for the property name. We could also create our proper Windows PowerShell script based on the Get-WmiObject cmdlet to look for this property. Or best of all, we could use the new cmdlet called Get-CimClass in Windows PowerShell 3.0 (currently in the Beta version). This specific cmdlet has been designed to ease the WMI discoverability process.

The following example shows finding the MacAddress property.

The latest solution is the fastest and the easiest. Instantaneously, we get two results, which are the class names on which the MacAddress property relies. Then we have to explore one of those to see what is inside it. I personally chose the Win32_NetworkAdapter class because I already solved a similar issue, and I remembered that this class worked for me. But after investigating the other one, Win32_NetworkAdapterConfiguration, I can assure you that the MacAddress is also there.

After we apply a filter on the adapter type to get rid of all adapters except the Ethernet adapters, and we apply a filter based on the connection status to get only the connected adapters, we remove all the virtual ones from VMWare (if any). Then we select only the first one because we suppose this is the primary one.

After we capture all the needed properties and place the result inside of some variables, we now have to put all the properties in common. This is when the New-Object cmdlet comes into play. We now are creating a custom hash table with the property names of our choice and mapping the right properties to them. Then we pass this hash table to the Property parameter and we are almost done!

Regarding the PhysicalMemory property, we can notice several things. The first is the use of the megabyte quantifier (MB). This is basically a predefined constant that aims to ease the readability of a script. It is the same but nicer and more understandable than writing 1024*1024. We divide by 1 MB to get the result in megabytes instead of bytes. The second thing is that we truncate the result thanks to the floor static method from the .NET Math class.

Then we create the file name (no difficulty here) and the path to store our XML file. Because there’s no environment variable that stores the “My documents” location, we are using the System.Environment .NET class to gain access to the system special folders. For more information about all the other special folders, please read Environment.SpecialFolder Enumeration in the MSDN Library.

Last but not least, we can convert our final object into an XML string only by using the ConvertTo-XML cmdlet, and then redirect the result to disk.

Getting the five extra points

It can happen that on some machines, some properties are null, for example, the manufacturer’s name or the computer’s model. In that case we would like our script to handle that and provide a way to add a nice ‘N/A’ string instead of a blank value.

So, one way to get the five extra points for this event, could be to check each individual property value of our resulting object (stored in the $result variable), and if we detect a null value, we replace it with the string ‘N/A’.

To do so, a generic approach is needed instead of having a ton of if instructions in our script for every property. Indeed, no matter what the number of properties the object has, accessing the raw Windows PowerShell object via the PSObject property, followed by a simple loop on each of the properties will do the trick. Using this technique will ensure that we won’t miss any property.

~Arnaud

The 2012 Scripting Games Guest Commentator Week Part 2 will continue tomorrow when we will present the scenario for Event 10.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Summary: Windows PowerShell MVP, Jonathan Medd, provides expert commentary for 2012 Scripting Games Beginner Event 9.

Microsoft Scripting Guy, Ed Wilson, is here. Jonathan Medd is the expert commentator for Beginner Event 9.

Jonathan has been working with IT infrastructure products since 1997. A few years ago, he discovered Windows PowerShell, and he now cohosts the Get-Scripting PowerShell podcast. Since April 2010, he has been a Microsoft MVP for Windows PowerShell, and in 2011 was honored as a VMware vExpert. He is co-author of VMware vSphere PowerCLI Reference.

Wherever possible, when you are working with the Windows PowerShell pipeline, it is beneficial to carry out filtering as close to the left side of the set of commands as possible. Consequently, it is always worth checking out the first cmdlet in the pipeline to see if it has built-in possibilities for filtering, rather than having to pipe the results of the cmdlet into Where-Object and carrying out the filtering there.

In Event 9, we are using the Get-EventLog cmdlet, so it is worth examining the Help for Get-EventlLog to see what, if any, filtering options are available.

First of all though, I like to run a quick check on a cmdlet to see what parameters are potentially available. Rather than start reading through the Help, I use Shay Levy’s Get-Parameter function, which you can get from his blog, Get-Parameter - Learn more about your cmdlets.

For Get-EventLog, it produces the following results:

Get-Parameter Get-EventLog

From this information, we can quickly see that there are some possibilities for filtering at the beginning of the pipeline to match the requirements of the event, that is, -InstanceId and -Source.

If you want to find out more about these parameters you can use

Get-Help Get-EventLog –Detailed

or

Get-Help Get-EventLog –Parameter InstanceID

So our initial query of the event log makes use of the following parameters, and we don’t need to pipe the results into Where-Object to carry out the filtering.

Get-EventLog -LogName Application -InstanceId 10001 -EntryType Information -Source Winsrv -Message "The following application attempted to veto the shutdown*" 

So it looks like the properties we need to work with for this event are Time and Message.

Get-EventLog -LogName Application -InstanceId 10001 -EntryType Information -Source Winsrv -Message "The following application attempted to veto the shutdown*” | Select Time,Message

However, Time is empty. Puzzling? Something I always remind students in my Windows PowerShell workshops is, “What you see is not necessarily what you get.” That is, the cmdlet designer has chosen to present the output of their cmdlet to the console in a certain way, and that may not necessarily match up with the object that has been returned by the cmdlet.

So, we should pipe our Get-EventLog query into the Get-Member cmdlet to have a closer look.

Get-EventLog -LogName Application -InstanceId 10001 -EntryType Information -Source Winsrv -Message "The following application attempted to veto the shutdown*” | Get-Member

We can see that we actually need to work with the TimeGenerated property—one called Time does not exist.

With the Message property, we don’t need the whole message, just the part that contains the application that is vetoing the shutdown. For that, we can create a calculated property, that is, a custom property of our own. You can see how we do that in the following code. In the expression, we expand the Message property, split it at the ‘:’ character, and use the second element in the array. (Arrays start at 0, so we need to use [1].)

Get-EventLog -LogName Application -InstanceId 10001 -EntryType Information -Source Winsrv -Message "The following application attempted to veto the shutdown*"  | select TimeGenerated,@{n='Application';e={(($_ | Select -ExpandProperty Message) -split ':')[1]}}

This gives us the solution to the event as shown here.

While checking out this event, I needed to generate some events in the Application log to match those of the requirements. To do so, I used the Write-EventLog cmdlet to create some (fake) matching entries.

Write-EventLog -LogName Application -Source Winsrv -Category 0 -EventId 10001 -Message "The following application attempted to veto the shutdown: BTTray.exe."

However, when I first ran this on my Windows 7 system, I received the following result.

To have an event in the log of Source Winsrv, it first needs to be registered, and this does not appear to be so by default. You can use the following .NET code to determine if this is the case for any event source.

[system.diagnostics.eventlog]::sourceexists("Winsrv")

And use this code to create one for the Application log:

[system.diagnostics.eventlog]::CreateEventSource("Winsrv",'Application')

Now I can create my required event log entry.

~Jonathan

The 2012 Scripting Games Guest Commentator Week Part 2 will continue tomorrow when we will present the scenario for Event 10.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Summary: Windows PowerShell MVP, Marco Shaw, provides expert commentary for 2012 Scripting Games Beginner Event 10.

Microsoft Scripting Guy, Ed Wilson, is here. Marco Shaw is the expert commentator for Beginner Event 10.

Marco has been in the IT industry for almost 15 years, and he is currently working for the IT consulting company CGI. He supports Windows servers and Linux, and he enjoys the various daily challenges he faces. He is a five-time recipient of the Microsoft MVP award for his support of Windows PowerShell online and offline communities.

First off, if I go back to last year—that was an “epic fail” on my part. I completely missed it. My solution didn’t even provide a solution to the problem. I will do better this year…

The first part of Beginner Event 10 is simple enough: get the performance counters. I already knew about Get-Counter because it is one of the core cmdlets in Windows PowerShell 2.0. It was simple enough to come up with:

get-counter -counter "\processor(*)\*" -sample 5 -max 3

However, it did take a bit of digging to get the counter parameter value right.

Next, I decided to tackle the “special documents folder.” I never pretend to know everything—not even close. I forget stuff all of the time, and I have to revert to using Bing a lot. I’m not embarrassed to say it. I’ve gotten used to it because I use multiple technologies at work, so I’m a “master of none.”

There is a way using .NET to get this special folder directly, but Ed made a point of adding a design point that indicates “use native Windows PowerShell commands.” If we were talking about more than a simple one-liner with a few cmdlets, I’d go with .NET, but I won’t this time. I played around a bit and came up with:

${env:userprofile}"\Documents\"${env:computername}"_ProcessorCounters.txt"

Not exactly pretty, but it meets the following requirements:

• The documents folder
• The server name in the output file
• The file ending with _ProcessorCounters.txt

So, I naively went with:

get-counter -counter "\processor(*)\*" -sample 5 -max 3|add-content -path ${env:userprofile}"\Documents\"${env:computername}"_ProcessorCounters.txt"

Then I looked at the resulting text file to see the fruits of my labor—which turned out to be a lemon as shown here:

Microsoft.PowerShell.Commands.GetCounter.PerformanceCounterSampleSet

Microsoft.PowerShell.Commands.GetCounter.PerformanceCounterSampleSet

Microsoft.PowerShell.Commands.GetCounter.PerformanceCounterSampleSet

Ugh! The perfmon objects are getting written to the file, not their string-based counterparts. This simple change worked:

get-counter -counter "\processor(*)\*" -sampleinterval 5 -maxsamples 3|out-string|add-content -path ${env:userprofile}"\Documents\"${env:computername}"_ProcessorCounters.txt"

Success! I simply needed to pipe to Out-String to transform my objects into basic string objects, then pipe them to a text file.

~Marco

WOW! This also concludes the 2012 Scripting Games. I want to especially thank all of the judges and the expert commentators for all of their hard work. I also want to thank Dia Reeves (my editor) who has done much more than basic editing these past several months leading up to the Scripting Games. I also want to extend a special thank-you to our wonderful sponsors for all their support of this great event. I hope you had fun, and that you also found it to be a worthwhile learning endeavor.

Join me tomorrow as we return to our regularly scheduled Weekend Scripter. I promise that I will not talk about the Scripting Games tomorrow—well, maybe a little. By the way, if you happen to be in Virginia Beach, VA tomorrow, the Scripting Wife and I will be at the Mark Minasi Conference where I (along with Don Jones) will be speaking. With people like Mark Minasi and Don Jones on the agenda, how can it fail to be an exciting and fun time? Hope to see you there.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Summary: Microsoft MCC, Rich Prescott, provides expert commentary for 2012 Scripting Games Advanced Event 10.

Microsoft Scripting Guy, Ed Wilson, is here. Rich Prescott is the expert commentator for Advanced Event 10.

Rich is currently working as a Windows Engineer for a market-leading global financial services firm in New York City. He started learning Windows PowerShell in 2009 while he was working as a desktop engineer. He is an author for the Microsoft TechNet Wiki. He is also a moderator on the Official Scripting Guys Forum, and he recently received the Microsoft Community Contributor award.

Personal blog: Engineering Efficiency
Microsoft blog: WikiNinjas - Official Blog of TechNet Wiki
Microsoft profile: Rich Prescott on TechNet
Twitter: @Rich_Prescott

Part one: The manual way

Having been a server admin previously, I have dealt with misbehaving servers on multiple occasions. Typically this led to creating a data collector set in Performance Monitor, and then viewing a chart with the information or exporting the information to a BLG file for later viewing.

When we had the BLG file, it could be converted into a CSV file by using the relog executable. This would create a CSV file that could satisfy three out of four of the requirements for Advanced Event 10.

Relog.exe Processor.blg –f CSV –o LT_processorCounters.csv

But this is the 2012 Scripting Games, and what would it be without some scripting!

Part two: The one-liner

After loading the Windows PowerShell console, I checked what available options there were for counters by using the following command:

Get-Command *counter*

After checking out the Get-Help listings for the Get-Counter and Export-Counter cmdlets, I was able to create a simple one-liner to generate the required CSV file:

 Get-Counter -Counter (Get-Counter -ListSet Processor).Paths -MaxSamples 10 -SampleInterval 2 |

 Export-Counter -Path "$($Env:ComputerName)_processorCounters.csv" -FileFormat csv

To fulfill the requirement of placing it in the Documents special folder, we can use Join-Path and a shortcut for the user’s documents folder.

 Get-Counter -Counter (Get-Counter -ListSet Processor).Paths -MaxSamples 10 -SampleInterval 2 |

 Export-Counter -Path (Join-Path ([environment]::getfolderpath("mydocuments")) "$($Env:ComputerName)_processorCounters.csv") -FileFormat csv

Now we have a mirror CSV file to what we created by using Relog.exe. However, if you read the Event Scenario carefully, it states that you must capture snapshots at two-second intervals for a total of ten snapshots, and there appears to be a row missing in both of the CSV files that we generated. If we wanted to be lazy, we could simply increment the MaxSamples parameter by 1, delete the first empty row in the CSV file, and call it a day. But this is the 2012 Scripting Games, and if you are going to do something, do it right!

Part three: The advanced way

In my testing, I found that the Get-Counter cmdlet was pulling all of the information correctly, but the Export-Counter and Relog.exe were not correctly outputting the data. To get around this, we can use Get-Counter to pull all of the information required, parse through it ourselves, and then output to a CSV file. I created the following function, which creates an array, loops through the objects piped from Get-Counter, converts them into custom PSObjects, and adds them to the array.

function Convert-RPCounter {

  Param(

    [Parameter(Mandatory=$true,ValuefromPipeline=$true)]

    $PerfData

    )

Begin {$Results = @()}

Process

  {

  ForEach ($Sample in $PerfData){

    $obj = New-Object PSObject -Property @{TimeStamp = $Sample.TimeStamp}

    ForEach($CounterSample in $Sample.CounterSamples){

      $obj | Add-Member -MemberType NoteProperty -Name $CounterSample.Path -Value $CounterSample.CookedValue

      }

    $Results += $obj

    }

  }

End {$Results}

}

We then call the function as follows:

Get-Counter -Counter (Get-Counter -ListSet "Processor").Paths -MaxSamples 10 -SampleInterval 2 |

 Convert-RPCounter |

 Export-Csv -Path (Join-Path ([environment]::getfolderpath("mydocuments")) "$($Env:ComputerName)_processorCounters.csv") -NoTypeInformation

As you can see in the previous image, we now have 10 full samples at two-second intervals as required. And that’s all there is to capturing performance data with Windows PowerShell.

Now starts the fun process of troubleshooting what is eating up all of my CPU…

…mumbles to himself, “Where is that bothersome Script Monkey? I thought I told him to stay away from my computer!”

~Rich

WOW! This also concludes the 2012 Scripting Games. I want to especially thank all of the judges and the expert commentators for all of their hard work. I also want to thank Dia Reeves (my editor) who has done much more than basic editing these past several months leading up to the Scripting Games. I also want to extend a special thank-you to our wonderful sponsors for all their support of this great event. I hope you had fun, and that you also found it to be a worthwhile learning endeavor.

Join me tomorrow as we return to our regularly scheduled Weekend Scripter. I promise that I will not talk about the Scripting Games tomorrow—well, maybe a little. By the way, if you happen to be in Virginia Beach, VA tomorrow, the Scripting Wife and I will be at the Mark Minasi Conference where I (along with Don Jones) will be speaking. With people like Mark Minasi and Don Jones on the agenda, how can it fail to be an exciting and fun time? Hope to see you there.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

This is the Advanced leaderboard of the 2012 Scripting Games. Keep in mind that the rankings are constantly changing throughout the day as event submissions are graded by the judges. No more scripts are being accepted. 

How are scripts scored? Learn more about judging criteria.

Top Submitters for the Advanced Events

This is the Beginner leaderboard of the 2012 Scripting Games. Keep in mind that the rankings are constantly changing throughout the day as event submissions are graded by the judges. No more scripts are being accepted. 

How are scripts scored? Learn more about judging criteria.

Top Submitters for the Beginner Events

Summary: Microsoft Scripting Guy, Ed Wilson, discusses several different ways to handle string output from inside Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. It is official—the 2012 Scripting Games are finally over (actually they were over yesterday, and I promised not to say any more about the games). Today the Scripting Wife and I are heading to Virginia Beach where I will speak at the Mark Minasi Conference. If you happen to be in the area, stop by and check it out. It will be a great conference, and I am really looking forward to it.

One of the things that beginners have a problem with is formatting output. In particular forming strings that contain data. One of the things Windows PowerShell does really well is handle input and output seamlessly. For example, many cmdlets automatically emit data. For example, the Get-Process cmdlet returns a nicely formatted table as shown here.

But things begin to go downhill really fast. Suppose you have a process named Notepad and you want to display the name and the process ID (PID). One way to approach this task is to use the Get-Process cmdlet to retrieve the instance of the Notepad process with which you are interested in working. Next you could store this process object into a variable, and then use expanding quotation marks (double quotation marks as opposed to literal quotation marks, which are single quotation marks) to expand the Name and ID properties. This technique is shown here.

PS C:\> notepad

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

PS C:\> "the name is $n.Name and the PID is $n.Id"

The problem is that when the string displays to the Windows PowerShell console, the object unravels and you do not get the property value that you might have been expecting to obtain. Instead, you get a jumble of letters that do not seem to make any sense. These commands and their associated output are shown here.

There are several ways to suppress the unraveling of the objects. One way is to use a subexpression. A subexpression is comprised of a dollar sign, and a pair of parentheses. The subexpression forces the evaluation of the object/property value and then returns the value of the property back to the string for display. A pair of parentheses causes Windows PowerShell to evaluate an expression prior to displaying the output. Therefore, it can display the contents of things like variables. A subexpression takes this a step further and causes the evaluation of the value of a property from an object. The syntax of this is shown here.

PS C:\> notepad

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

PS C:\> "the name is $($n.Name) and the PID is $($n.Id)"

the name is notepad and the PID is 2816

The command to start notepad, retrieve an instance of the object and store it in the $n variable, and display the property values is shown here with the associated output.

Another approach to this problem is to use concatenation. The concatenation operator is the plus sign (+). Concatenation glues the output together so it will display on the same line. By using concatenation, you place your string values inside quotation marks. You then close the quotation marks and call the object/property to display it. You then open another pair of quotation marks to add your additional string data. You continue with this pattern until you have completed displaying your data.

This approach to merging data from property values and strings is essentially unchanged from the earliest VBScript days. The big trick with this technique is that you must remember to include spacing between the string and the property value. If you do not, the concatenation operator will glue your string together. This approach is shown here.

PS C:\> notepad

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

PS C:\> "the name is " + $n.name + " and the PID is " + $n.id

The commands and the output associated with the commands are shown here.

A different problem exists when working with multiple objects. In this situation, the properties appear to disappear. This is because the process objects (in this example) hide inside an array and when attempting to access directly the property values. You must first deal with the array, and then you can work with the property values. If you do not first deal with the array, when you attempt to display the property values, nothing appears in the output. This situation is shown in the image here.

Because there are multiple objects in the array, it is necessary to walk through the array so that the individual values from the properties of the individual objects are accessible. The easiest way to accomplish this is to pipe the array of objects to the Foreach-Object cmdlet. In the script block portion of the Foreach-Object cmdlet, add the code from the previous examples. This technique is shown here (this example uses the % symbol, which is an alias for the Foreach-Object cmdlet).

PS C:\> 1..3 | % {notepad}

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

PS C:\> $n | % {"the name is " + $_.name + " and the PID is " + $_.id}

The code, from this technique, along with the associated output appears here.

You can use a similar technique to using the Foreach-Object cmdlet by using the ForEach language statement to walk through the array and display the property values. The ForEach language statement is a bit more complex to use than the Foreach-Object cmdlet, but it has the advantage of being a bit easier to read, and of being generally faster due to not involving the overhead of the pipeline. The use of the ForEach language statement to walk through the array is shown here.

PS C:\> 1..3 | % {start-process notepad -WindowStyle minimized}

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

PS C:\> foreach($a in $n) {"the name is " + $a.name + " and the PID is " + $a.id}

Because an array contains the objects, it is possible to index the array to display the property values. One easy way to do this is to use the same type of range operator that created the three instances of Notepad in the first place. When it is created, the $n variable stores the objects that are returned by the Get-Process cmdlet. The range operator passes the numbers that become the index indicators to select the specific element from the array. The dotted notation selects the applicable properties from the process object. This technique is shown here.

PS C:\> 0..2 | % {start-process notepad -WindowStyle minimized}

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

0..2 | % {"the name is " + $n[$_].name + " and the PID is " + $n[$_].id}

Rather than using concatenation or a subexpression to display the values from the object/property, a cleaner (and therefore, more reliable) method uses parameter substitution and the format operator. At first glance, this technique appears strange—although not necessarily any stranger than indexing into the array to retrieve the property values. When you become familiar with this technique, you may find that you like it better than using concatenation or a subexpression. The basic pattern is shown here.

This pattern with the associated output is shown in the following example.

PS C:\> "The first number {0} marks the first pattern" -f "zero"

The first number zero marks the first pattern

The advantage of using parameter substitution is that it is easier to format the output exactly as required. Going back to the example of indexing into the array, parameter substitution replaces the concatenation previously used. The revised example is shown here.

PS C:\> 0..2 | % {start-process notepad -WindowStyle minimized}

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

PS C:\> 0..2 | % {"The name is {0} and the PID is {1}" -f $n[$_].name, $n[$_].id}

The following output illustrates the use of parameter substitution to retrieve the property values from the array and to format the output.

Well, that is enough for now about formatting output. Join me tomorrow when I will continue the discussion by examining the use of various cmdlets.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Summary: Microsoft Scripting Guy, Ed Wilson, talks about handling output to the Windows PowerShell console while using the pipeline.

Microsoft Scripting Guy, Ed Wilson, is here. The Scripting Wife and I are enjoying Virginia Beach. We have met some really cool and smart people here at the Mark Minasi Conference. We had a chance to go to the huge naval museum here. It was cool. In the museum, they have different types of exhibits. Some of them have a button that you push, and you listen to it, then you go to the next exhibit. Others have drawings and diagrams that you read, and then you go to the next exhibit. Still others have brochures that you can skim and take with you when you leave the museum.

In a way, Windows PowerShell output behaves the save way. Some things we write to the Windows PowerShell console, others we write to files. Some things display to the console and write to files, and still others appear and then they are gone, never to return. It is the ease-of-use plus the diversity of options for creating output from inside Windows PowerShell that is a source of confusion for beginning (and even for some advanced) Windows PowerShell scripters. Simply put…

Like the child who comes home from the grocery store with a loaf of bread and 12 candy bars, we often do not make the best choices. Just like the child with the dozen candy bars and a loaf of bread, some of the options seem too compelling. We get over-awed with the choices—in short, we zone out into a sort of geek trance. In the following command, I use the Get-Command cmdlet, the Sort-Object cmdlet, the Select-Object cmdlet, and the Format-Wide cmdlet to produce a list of the more common output and formatting cmdlets. Twenty cmdlets appear on this list (Measure-Command tells me that). The dizzying array of choices are shown here.

PS C:\> gcm -Verb write, out, tee, format | sort verb | select name  | fw -a

Format-Table     Format-Wide      Format-Custom    Format-List      Out-Null

Out-Printer      Out-String       Out-Host         Out-Default      Out-File

Out-GridView     Tee-Object       Write-Progress   Write-Output     Write-Warning

Write-Verbose    Write-Error      Write-Debug      Write-Host       Write-EventLog

The easiest way to write output

The easiest way to write output is not to use any of the twenty cmdlets listed previously. Rather, it is to place the output into a string. There are two types of strings in Windows PowerShell, the expanding string and the literal string. The difference is twofold; an expanding string uses double quotation marks, and a literal string uses single quotation marks. The practical application of these different types of strings is also twofold. A literal string means that what you type is what you get. This is, in fact, the way that strings worked in other languages (for example in VBScript). The difference, with VBScript anyway, is that the string indicator was the double quotation mark.

Using literal strings

The following example illustrates how a literal string works. It uses single quotation marks and contains a variable. When the string displays to the Windows PowerShell console, the variable appears exactly as typed. That is, the variable does not expand to display the value that the variable contains.

In the following example, in the first line, a string assigns to the variable $a. The double quotation marks do this, but you could just as easily (and with no difference in the outcome of the code) use single quotation marks for this string. This is because the string contains no variables to expand. In the second line of code, a pair of single quotation marks delineates the string. This time, the string contains two variables. The output displays to the Windows PowerShell concole, but the values contained inside the $a variables do not unravel. Instead, only the literal $a appears on the outputted line.

PS C:\> $a = "this is a string contained in a variable"

PS C:\> 'The value of the $a variable is actually $a'

The value of the $a variable is actually $a

PS C:\>

Using expanding strings

If you replace the single quotation marks in the second line of code with double quotation marks, the difference is dramatic. For each of the two locations where the $a variable appears in the code, the value contained in the variable replaces the literal variable name. The resulting output is not very useful, but it is different.

PS C:\> "The value of the $a variable is actually $a"

The value of the this is a string contained in a variable variable is actually this

is a string contained in a variable

PS C:\>

Suppress automatic expansion

What you might want to do is to use the expanding or unraveling feature of the expanding string for the second appearance of the $a variable, but suppress it for the first appearance. To suppress the expansion of the first variable, use the grave accent (also called back-tick) character (`) immediately prior to the first appearance of the $a variable. This is shown here.

PS C:\> "The value of the `$a variable is actually $a"

The value of the $a variable is actually this is a string contained in a variable

PS C:\>

These examples of using literal and expanding strings are shown with their associated output in the image that follows.

Writing output to the console

Most of the time, beginners who are learning Windows PowerShell use the Write-Host cmdlet to display output to the Windows PowerShell console. One reason for doing this is that people coming from a VBScript background (where they used “Wscript.Echo” to write output) feel that they need to do something similar to this. They find Write-Host, and they see it as the direct replacement. Next, they proceed with a line-by-line adaptation of their previous VBScript to the new Windows PowerShell script. Unfortunately, this does not take advantage of an inherent Windows PowerShell strength —it works with objects, not strings.

There are occasions when using Write-Host is the right thing to do. For example, if you are at the end of a command and you want to take advantage of the Foreground or the Background color abilities of the Write-Host cmdlet, the command makes sense. On the other hand, if you are not using the color capabilities of the Write-Host cmdlet, it makes sense to use the Write-Output cmdlet instead. The reason is that Write-Host is a terminal cmdlet—that is, after you use it, you can do nothing else. If you try to pipe the output from the Write-Host cmdlet to a text file, no error generates, but the text file is empty. This is because no objects return from the Write-Host cmdlet. The commands are shown here.

The Out-File cmdlet creates the writehost.txt file, but because Write-Host passes no objects along the pipeline, the text file contains no text. The empty file is shown here.

Choosing both console and file

You do not need to write complicated duplicate code to write data to the Windows PowerShell console and to write to a file. In fact, you do not need to store the data in an intermediate variable—it can be done with a single command. The cmdlet to use is Tee-Object. The Tee-Object cmdlet accepts a single input and then splits the output to multiple locations. It can display data to the Windows PowerShell console and write it to a file. It can also display to the console and write back to a variable. The basic syntax is shown here.

"output from the Tee-Object" | Tee-Object -FilePath c:\fso\tee.txt

The command and its associated output are shown in the following image.

A quick check of the text file reveals that the text file does indeed contain the text output to the console. The Tee.txt file is shown here.

You are not limited to only sending the output to the Windows PowerShell console and a file, or to a variable and the console. This is because the cmdlet splits the output. You can use a variable to hold part of the output, and you can still send it to a text file. When you have the output in a variable, you can easily display the contents of the variable to the console. This is shown here.

PS C:\> $t = "output from the Tee-Object. Test 2" | Tee-Object -FilePath c:\fso\tee2.

txt

PS C:\> $t

output from the Tee-Object. Test 2

PS C:\>

That is about all there is for now. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Summary: After four months of meetings, leaders of two successful Windows PowerShell Users Groups discuss what went well and what didn't.

Microsoft Scripting Guy, Ed Wilson, is here. Today we will not be as technical; but hopefully, this still will be useful Windows PowerShell information. We have Adam Driscoll and Jim Christopher to tell us firsthand about their recent experiences starting new Windows PowerShell Users Groups.

Adam Driscoll is a software developer team lead at Quest Software. He works closely with the Windows PowerShell module for their vWorkspace product. Adam is a cofounder of the Madison, WI Windows PowerShell Users Group and is facilitating this spring’s PowerShell Deep Dive in San Diego. He is also the author of the PowerGUI Visual Studio Extension.

Blog: PS Adam Driscoll:\> Start-Sharpening_

Madison, WI PowerShell Users Group blog

Jim Christopher is the owner and principle developer for Code Owls LLC, a company focused on software services and toolset development for Windows PowerShell. He is a Microsoft MVP for Windows PowerShell and a frequent speaker at users groups and conferences, where he enjoys promoting Windows PowerShell as a tools and automation platform. Jim helps organize the Charlotte PowerShell Users Group in Charlotte, North Carolina.

Blog: beefycode: serving all of your beefy code needs

For this post, Jim (JC) and Adam (AD) answered questions about how they started and run their respective Windows PowerShell Users Groups. The hope is that these questions and their answers will help you start your own local Windows PowerShell community.

Where is your PowerShell Users Group located, and how long have you been meeting?

AD: Our group is located in Madison, WI. We have members coming from the near Madison area, but we have had some interest from as far away as the Twin Cities. We held out first meeting in January 2012.

JC: Our group serves Charlotte, NC and the surrounding areas. Our first meet-up was in January 2012.

Was there any particular catalyst that prompted you to start the users group?

JC: I’ve been speaking for a few years about Windows PowerShell, and I’ve noticed a few things. My talks target developers, but my audience consists of developers, dev-ops, database administrators (DBAs), and support engineers. Also, I have to start every talk with the same 20 minute overview of Windows PowerShell—what I call ”PowerShell for n00bs.” There is an obvious cross-discipline interest in Windows PowerShell, and a lack of general knowledge. So there’s the opportunity. Also, Ed “Scripting Guy” Wilson and the Scripting Wife live and work near the Charlotte Microsoft office. We were on the same page about forming a local community, and having such prominent figures available creates a lot of motivation.

AD: In my experience, there was no definitive catalyst. I‘ve spent a lot of time networking with Windows PowerShell community members over the Internet, but I had little face-to-face contact with people that were passionate about it. Although we have a growing adoption for Windows PowerShell at our R&D lab, the number of frequent users was limited. I wanted to get out in the community and learn how a wider audience was using Windows PowerShell. I also wanted to be able to share whatever I could with anyone looking to learn. What really decided it for me was when I talked to our cofounder, Lee Berg, about starting a group, and he was just as excited about the idea as I was.

How are the meetings typically structured?

JC: We meet monthly and alternate between formats. Odd months are a typical users group experience—a speaker prepares an hour’s worth of material about a topic and delivers it in a lecture. For example, next month, Brian Hitney (a developer evangelist at Microsoft), is showing how he uses Windows PowerShell to manage Windows Azure applications. Even months are Script Clubs. Members bring scripts or ideas they are working on and get assistance from other members.

AD: Yep, we are starting to follow that format also. The first two meetings, we did not. The initial plan was to have a regular presentation, followed by a Script Club format. What we found was that after an hour or longer presentation, members didn’t necessarily want to stick around to delve deep into scripts. We’ve only had a single session that was Script Club style but I think it was a lot of fun and really informative for everyone involved.

Are your Script Clubs structured or ad-hoc?

JC: Our group treats them like an open space. I ask volunteers to describe an interest or problem, and attendees decide how to group up. Some like to help, others like to chat and learn. For instance, last month, someone brought an incomplete script to read remote event logs and modify Windows services. She had two members helping her and more looking on. The group of six spent 90 minutes teaching each other Windows PowerShell scripting techniques.

AD: Our format has been very organic. I notify members via our blog and Google Group to come prepared with some scripts or ideas to share. Because our group is smaller, it is easy to pass around the reigns and look over the scripts as a group. We also spend time on PoshCode and playing with some general tips and tricks. It‘s a blast and we can dig deep into some really interesting problems.

How did you promote the group in your area when you were getting started?

AD: Word-of-mouth has, by far, been our best advertisement. Most of the members hear about the group through coworkers. We also have a blog and Google Group, but they seem to provide less advertising and more communication. We’ve tried every social network in the book (Facebook, Twitter, LinkedIn, reddit), but there has been little influence locally from any of them. We did find that promoting ourselves on sites like this did prompt some interest from Windows PowerShell users outside the Madison area. We are still working out the kinks involved in becoming truly remote-capable.

JC: We also rely heavily on word-of-mouth. We told a lot of other local IT and development users groups about us, and they helped promote the first couple of meetings to their members. And of course we reciprocate. There are also several community websites we use to promote the group. PowerShell Community Groups is an obvious choice when you’re looking for a Windows PowerShell users group, but I want to make sure people find the group even if they’ve never heard of Windows PowerShell. So we also use Meetup. I tag our Windows PowerShell Users Group with various interest labels (.NET, dev-ops, Windows Server, IT administration), and Meetup notifies users who have listed overlapping interests. We’ve even had local Linux admins who wanted to see what Windows PowerShell was all about.

Of the members in your group, what is the ratio between developers and IT administrators?

JC: It seems to be about 60% IT administrators and dev-ops, and the other 40% developers and DBAs. It’s a nice cross-section of the technology stack, actually.

AD: Our typical crowd is primarily IT administrators. We will usually have a developer or two, but it’s usually the result of me inviting my coworkers.

Windows PowerShell topics can be pretty specific (Hyper-V, WSUS, and SCM). How to you manage the diversity among member specialization and experience levels?

AD: Our meetings have been about very general Windows PowerShell topics thus far. We have had some focus on WMI, with more of that coming in June with Trevor Sullivan. One of the most important facets of Windows PowerShell is that it integrates with so many technologies. Because of this, we will definitely be mixing in more specific sessions in the future.

JC: We literally have the widest experience gap possible: in one seat is the Microsoft Scripting Guy, and sitting right behind him is someone who’s never opened a shell. I don’t ask speakers to dumb down their information, but I do ask that they spend time explaining the Windows PowerShell choices they make, no matter how mundane they seem. To quote the Scripting Guy, “PowerShell is PowerShell is PowerShell.” My hope is that a DBA watching someone manage Windows Azure with PowerShell is learning techniques that they can apply to SQL Server administration.

How do you find presenters for your group?

JC: Up to this point, I’ve been asking people I know from the community. The group is registered with INETA, which may help in the coming months. I give speaking priority to group members, something I consider keystone to the community experience. I gave my first talk to the Charlotte ALT.NET group. I learned that I love the experience (even when I do it poorly), and I want to give others the chance to learn that for themselves.

AD: So far, finding speakers has been pretty easy. I’m amazed by the willingness of the experts in the Windows PowerShell community to offer their time to present to a group of people they don’t know.

Do you collaborate with other Windows PowerShell groups?

JC: At the moment the only collaboration we’ve participated in is International PowerShell User Group Day. We’ve discussed having “Iron Scripter” competitions, which would be a mini Scripting Games that’s isolated to our group. Other groups would run their own Iron Scripter games, growing it into a bracket where people can win badges like Iron Scripter: Charlotte, Iron Scripter: North Carolina, Iron Scripter: East Coast, and so on. The hope is that the friendly competition will motivate members to learn and apply Windows PowerShell.

AD: We were also a part of the International PowerShell User Group Day. Aside from that, we have talked about holding joint, remote meetings with the Twin Cities group, and we had Steve Murawski of the Milwaukee Script Club join us.

What has been hardest part about starting the users group? What turned out to be easy?

AD: The hardest part has been spreading the word. Our group has been relatively small with a couple of regular attendees. I hope through some diligence, we will be able to grow the group a bit more.

JC: I thought finding members would be difficult; but honestly, finding a good day to hold the monthly meeting was a lot harder than I expected. I wanted to pick a day that didn’t interfere with other local groups; however, since Windows PowerShell crosses so many technologies and interests, that proved rather difficult. Oh, and lining up corporate sponsors has been a challenge. A lot of companies offer generous community programs, but it can take months to get their attention.

Would you consider your group successful?

AD: Yes, I would. The regular members are really what constitute a success in my eyes. The fact that they are showing up consistently shows that we must be providing some value. That said, I would love to see our group grow. We have 5 to 7 members at a typical meeting, and it would be great to see that number double or triple.

JC: I do consider the group a success. We have almost 60 members and a consistent attendance of 10-15 at each meet-up. I think there is a lot of work ahead to keep the group viable. One thing I’m watching for is fragmentation. With such a diverse base, it’s only natural for members to partition off by specialty.

Is there anything you would have done differently?

AD: Yes, definitely. Our facilities have been phenomenal, but our remote access has been very sub-par. We have tried Live Meeting, and it did not work out for our remote users. We are still experimenting with how we can reach a larger audience, but haven’t nailed down a good tool. I hope that we haven’t lost too many attendees due to technical difficulties!

JC: I mishandled the food sponsor one month. We had a conversation about sponsorship, but I didn’t follow up quickly enough. I had to scramble at the last minute to line-up food. It was a learning experience, and now I make sure to line-up food sponsors well in advance and follow up several times.

What one piece of advice would you give someone considering starting a group?

AD: Starting a group is a lot of work. Reach out as much as you can to the community for guidance and assistance. It will make your group a better experience for you and your members.

JC: Agreed. And in all decisions, choose what keeps the group relevant to your members. After all, it isn’t your group, it’s theirs.

Thank you, Jim and Adam. Wishing you much success with both users groups.

That is all there is to creating a Windows PowerShell Users Group. You may also want to review the Practical Tips for Starting a PowerShell User Group blog post and the Mark Schill Discusses PowerShell User Groups post for additional information about starting and maintaining a Windows PowerShell Users Group. Tomorrow we will announce the winners of the 2012 Scripting Games.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

This is the FINAL Advanced leaderboard of the 2012 Scripting Games. Congratulations to our winners! For more information about this year's Scripting Games, see the blog post Winners of the 2012 PowerShell Scripting Games Announced!

How were the scripts scored? Learn more about the judging criteria.

Top Submitters for the Advanced Events