Skip to main content

Comparing Optimization of Filtering in PowerShell

This morning in my Hunt Valley, MD PowerShell class, I extended yesterdays lesson (see yesterday’s post) into filtering optimization.  In the PowerShell world, we have a saying: “Filter to the Left”.  That means that you filter out as many objects as possible as close to the beginning of the piped commands as possible.  What we did was use the Get-EventLog cmdlet and filtered it in two ways.  We wanted to filter for Event ID 12.  In the Get-EventLog cmdlet, we used the InstanceID parameter with a value of 12.  In the second execution of Get-EventLog, we piped everything to Where-Object and filtered on the property InstanceID for a value of 12.  We then executed our code from yesterday to test the runtime for each one.

# Optimizing for Performance.

# Get-Help Get-EventLog -Parameter Newest

 

# Execute each section individually by highlighting

# the code and pressing F8.

Clear-History

 

# This is optimized

Get-EventLog -LogName System -InstanceId 12

 

# This is not Optimized

Get-EventLog -LogName System |

Where-Object InstanceID -eq 12

 

 

# Get the history information and execution times.

Get-History |

    Select-Object -Property CommandLine,

    @{N="ExecutionTime";

        E={($_.EndExecutionTime - $_.StartExecutionTime).TotalSeconds}} |

    Select-Object -Last 2

Here is the output from the fourth section.

CommandLine                                                                  ExecutionTime

-----------                                                                  -------------

Get-EventLog -LogName System -InstanceId 12                                      8.9346474

Get-EventLog -LogName System |...                                               14.6560631

You can see that the first command using its built in filtering capabilities is much faster than piping all the objects to Where-Object.

Comments

Popular posts from this blog

Determine which Domain Controller a client is connected to with PowerShell

When a Windows client comes online, it must find a domain controller to bind to.  Either through a static configuration or DHCP, the client will request a list of all Domain Controllers in the domain from a DNS server.  Once the list is received, the client will randomly go through the list to find a DC that will respond.  Once the client has authenticated itself with the DC, the DC will transmit the site information to the client.  The site information will contain the site name, the subnet(s) associated with that site, and any domain controllers in that site.  The client will then take a look at it’s own IP address to determine which site it is in.  From the list of DCs in the same site, it will attempt to bind to one of those DCs to receive it’s Group Policies.You can use PowerShell and WMI to locate the domain controller that a client is connected to.Get-WMIObject Win32_NTDomainLook for the DomainControllerName property.

Test to see what that data type of a value is in PowerShell

PowerShell has a comparison operator called –is.  The –is operator simply response True or False when you use it to verify the data type of a value.  The valid data types in PowerShell are:
[string]    Fixed-length string of Unicode characters
[char]      A Unicode 16-bit character
[byte]      An 8-bit unsigned character
[int]       32-bit signed integer
[long]      64-bit signed integer
[bool]      Boolean True/False value
[decimal]   A 128-bit decimal value
[single]    Single-precision 32-bit floating point number
[double]    Double-precision 64-bit floating point number
[DateTime]  Date and Time
[xml]       Xml object
[array]     An array of values
[hashtable] Hashtable object

Below is a script that will use –is to test some values.
$String="Hello"$Boolean=$True$Int=15Write-Host"Test for string"$String-is [String] $Boolean-is [String] $Int-is [String] Write-Host" "Write-Host"Test for Boolean"…

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 ManagementDouble click User Account ManagementCheck Configure the f…