{"id":2813,"date":"2013-09-28T00:01:00","date_gmt":"2013-09-28T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2013\/09\/28\/weekend-scripter-max-out-powershell-in-a-little-bit-of-timepart-1\/"},"modified":"2013-09-28T00:01:00","modified_gmt":"2013-09-28T00:01:00","slug":"weekend-scripter-max-out-powershell-in-a-little-bit-of-timepart-1","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/weekend-scripter-max-out-powershell-in-a-little-bit-of-timepart-1\/","title":{"rendered":"Weekend Scripter: Max Out PowerShell in a Little Bit of Time—Part 1"},"content":{"rendered":"

Summary<\/strong>: Microsoft PFE, Jason Walker, talks about how to maximize performance from Windows PowerShell in the enterprise.<\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. Jason Walker<\/a> is our guest blogger this weekend. Today is Part 1 of a 2 part series. Here’s Jason…<\/p>\n

I work in an environment with widely dispersed datacenters and I am often tasked with searching for events from multiple servers. It becomes a challenge to quickly query the event logs of 5, 10, or even 20 servers, not to mention 70 servers.<\/p>\n

Let us look at our options. Immediately, Windows PowerShell remoting comes to mind. Windows PowerShell jobs is a possibility, and for those developer types, runspaces is an option.<\/p>\n

Let’s look at remoting first.<\/p>\n

Invoke-Command<\/strong> has a ComputerName<\/strong> parameter, which accepts an array, and a ThrottleLimit<\/strong> parameter. It’s as if Invoke-Command<\/strong> was made for this type of stuff! Let’s see how it works.<\/p>\n

I’m going to query the System log for event 1074 on five servers. And for instructional purposes, I will specify a MaxEvents<\/strong> of 1:<\/p>\n

$Servers = “mail01″,”mail02″,”mbx01″,”mbx02″,”mbx03”<\/p>\n

$Events = Invoke-Command -ComputerName $Servers -ScriptBlock {$sb=@{Logname=’System’;Id=1074};Get-WinEvent -FilterHashtable $sb -MaxEvents 1}<\/p>\n

$Events<\/p>\n

\"Image<\/a><\/p>\n

These commands could easily be combined into a one-liner. Using Invoke-Command<\/strong> is easy and straightforward. When you want to run a cmdlet across multiple machines and the cmdlet’s ComputerName<\/strong> parameter doesn’t accept an array, Invoke-Command<\/strong> easily adds that functionality. We see that Invoke-Command<\/strong> runs and returns results almost instantly.<\/p>\n

\"Image<\/a><\/p>\n

Using Measure-Command<\/strong> shows that the series of commands took 742 milliseconds. But let’s take a closer look at the objects that are returned. If I take the first object that is returned, it looks like I ran Get-WinEvent<\/strong> without leveraging remoting:<\/p>\n

\"Image<\/a><\/p>\n

However, notice the value of the Properties<\/strong> property. It has depth (nested objects). Let’s expand that and see what we get.<\/p>\n

\"Image<\/a><\/p>\n

Only the names of the nested objects are returned as strings. Let’s run Get-WinEvent<\/strong> by itself to compare.<\/p>\n

$Event = Get-WinEvent -cn mail01 -FilterHashtable @{Logname=’System’;id=1074} -MaxEvents 1<\/p>\n

$Event | select *<\/p>\n

\"Image<\/a><\/p>\n

It looks the same so far. Now let’s look at the nested objects in Properties<\/strong>:<\/p>\n

\"Image<\/a><\/p>\n

Now we have values. Awesome!<\/p>\n

When using Get-WinEvent<\/strong>, I always want the values within Properties<\/strong>, but if I’m using a different cmdlet or function, this might not be an issue. For example, let’s say I want to know who rebooted my server mail01. All I know is that the server has been rebooted.<\/p>\n

I could use Get-WinEvent<\/strong> and parse through the blob of text that is the Message<\/strong> property, or I could look at the seventh value contained in the Properties<\/strong> property. In the previous example, vmicsvc.exe has initiated a shutdown on behalf of NT Authority\\System. So it’s safe to say that a user shut down the virtual machine with the Hyper-V management console or by using the Stop-VM<\/strong> cmdlet. To drive my point home, I can easily get the data I want from the Properties<\/strong> property versus parsing through a paragraph of text, for example:<\/p>\n

$Event = Get-WinEvent -cn mail01 -FilterHashtable @{Logname=’System’;id=1074} -MaxEvents 1<\/p>\n

$Event | Format-Table MachineName,@{name=”ShutdownByUser”;Expression={$_.Properties[6].value}}<\/p>\n

\"Image<\/a><\/p>\n

In the previous example, with only two lines of code (which could easily be one line of code), I can report the user name who initiated the shutdown. Super, super easy.<\/p>\n

Let’s look at using jobs. Jobs are cool because when a cmdlet is run inside a job, the work is being done asynchronously in its own thread. So if you run a cmdlet as a job, the prompt will be instantly returned, and you can continue to Windows PowerShell as the job runs in the background. We could talk about jobs forever (for more information, see Using Windows PowerShell Jobs<\/a>)—but let’s see them in action.<\/p>\n

$Servers = “mail01″,”mail02″,”mbx01″,”mbx02″,”mbx03”<\/p>\n

Foreach($Server in $Servers){<\/p>\n

 Start-Job -ScriptBlock {Get-WinEvent -ComputerName $using:Server -FilterHashtable @{LogName=’System’;Id=1074} -MaxEvents 1}<\/p>\n

 }<\/p>\n

$EventsUsingJobs = Get-Job | Wait-Job | Receive-Job<\/p>\n

$EventsUsingJobs<\/p>\n

\"Image<\/a><\/p>\n

When using jobs there are a few more steps involved. Start-Job<\/strong> doesn’t have a ComputerName<\/strong> parameter, so I have to iterate through an array of server names and supply Get-WinEvent<\/strong> with each of the unique computer names. You can see the jobs being created, and when the jobs are finished, I have to use Receive-Job<\/strong> to see the results. I will use Measure-Command<\/strong> to see how long everything took to run.<\/p>\n

\"Image<\/a><\/p>\n

By using jobs, it took four seconds to query the five servers. That is considerably longer than using Invoke-Command<\/strong>, but less than a server a second isn’t bad. I mean, I couldn’t manually run the command five times in four seconds.<\/p>\n

\"Image<\/a><\/p>\n

When we look at the objects returned, again we see that we lose the nested objects. As a work around, I could pipe the results of Get-WinEvent<\/strong> to Export-CliXml<\/strong> inside the script block, but the results have to be written to disk and then imported by using Import-CliXml<\/strong>, which adds more time to task.<\/p>\n

Let’s use runspaces. Here I wrote a function that I named Get-AsyncEvent<\/strong> that runs Get-WinEvent<\/strong> in asynchronous runspaces. Here is what happened when ran it with the exact filters as the previous examples:<\/p>\n

\"Image<\/a><\/p>\n

We find that runspaces are significantly faster than using Invoke-Command<\/strong>, taking less than half the time to run the command. But do we get nested objects back? Let’s run the command again and take a look:<\/p>\n

\"Image<\/a><\/p>\n

Jackpot! Not only are runspaces the fastest solution, but they return objects in their entirety.<\/p>\n

Let’s recap…<\/p>\n