When working with data sets and PowerShell, knowing how to handle them can be a tricky proposition. It also depends on the size of the data that is being analyzed or manipulated with PowerShell. What works for one, ten or even a hundred objects, may not scale efficiently past 1,000, 10,000 or even more. In this Tip of the Week we discuss two common methods for working with data sets and PowerShell.
Where
This commonly used operator allows us to decide what to tell PowerShell to look for in a set of results. For example, if we are working in Exchange Online and moving mailboxes to or from an on-premises server, we may want to look at only complete migrations or maybe any migration that has failed to see what is wrong with this. This can be performed with the Where operator, like so:
[sourcecode language=”powershell”]
Get-MigrationUsers | Where {$_.Status -eq 'Failed'}
[/sourcecode]
This one-liner works well for finding these results.
Filter
However, the same operator when working with large data sets, could cause performance issues. For example, if we were to work within PowerShell and perform AD queries for managers or users, the Where operator is actually very slow and could add seconds or maybe even an additional minute to process a single user object. Filter is our other option for narrowing down the results:
[sourcecode language=”powershell”]
Get-ADUser -Filter {SamAccountName -eq $ManagerID}
[/sourcecode]
With the use of the Filter operator, this one-liner now only takes about a second per object versus over a minute in some environments. Depending on a script, this could shorten a long running script to a much more manageable time frame.
Caveat
Filter is not available with every cmdlet, so your mileage will vary!
To Filter or Be Where?
Categories:
