Richard Siddaway's Blog

Scripting Games - Filter early again

Grading the scripts in Event 4 and the one thing that jumps out is the amount of unnecessary data being carried through the scripts

You were asked for 7 properties off 20 random users

Get-ADUser has a –properties parameter. USE it to restrict the properties you return. You don’t NEED all the other properties

Next select you 20 users as soon as possible

get-aduser | get-random

will do that.  You can then format just the few properties you need on the 20 objects you have left

FILTER EARLY

Scripting Games - Win32_LogicalDisk or Win32_Volume

I have heard some discussions recently regarding whether Win32_LogicalDisk or Win32_Volume should be used in the answer to event 3 in the Scripting Games.

The problem requires you pull the drive letter, drive size and freespace for local disks on the server. Notice the emphasis – that will be important.

Looking at Win32_Volume

PS> Get-CimClass -ClassName Win32_Volume | select -ExpandProperty CimClassproperties  | select Name

Name
----
Caption
Description
InstallDate
Name
Status
Availability
ConfigManagerErrorCode
ConfigManagerUserConfig
CreationClassName
DeviceID
ErrorCleared
ErrorDescription
LastErrorCode
PNPDeviceID
PowerManagementCapabilities
PowerManagementSupported
StatusInfo
SystemCreationClassName
SystemName
Access
BlockSize
ErrorMethodology
NumberOfBlocks
Purpose
Automount
BootVolume
Capacity
Compressed
DirtyBitSet
DriveLetter
DriveType
FileSystem
FreeSpace
IndexingEnabled
Label
MaximumFileNameLength
PageFilePresent
QuotasEnabled
QuotasIncomplete
QuotasRebuilding
SerialNumber
SupportsDiskQuotas
SupportsFileBasedCompression
SystemVolume

You see 3 properties that might be of use

Get-CimInstance -ClassName Win32_Volume | select DriveLetter, Capacity, FreeSpace

is a start but I get two drives with no capacity & freespace – must by my DVD drives

I can filter those out using drive type.  DriveType =3 gives me local disks

So the WMI call I need is

Get-CimInstance -ClassName Win32_Volume -Filter "DriveType=3"  | select DriveLetter, Capacity, FreeSpace

Get-WmiObject -Class Win32_Volume -Filter "DriveType=3"  | select DriveLetter, Capacity, FreeSpace

Now lets look at Win32_LogicalDisk

PS> Get-CimClass -ClassName Win32_Logicaldisk | select -ExpandProperty CimClassproperties  | select Name

Name
----
Caption
Description
InstallDate
Name
Status
Availability
ConfigManagerErrorCode
ConfigManagerUserConfig
CreationClassName
DeviceID
ErrorCleared
ErrorDescription
LastErrorCode
PNPDeviceID
PowerManagementCapabilities
PowerManagementSupported
StatusInfo
SystemCreationClassName
SystemName
Access
BlockSize
ErrorMethodology
NumberOfBlocks
Purpose
FreeSpace
Size
Compressed
DriveType
FileSystem
MaximumComponentLength
MediaType
ProviderName
QuotasDisabled
QuotasIncomplete
QuotasRebuilding
SupportsDiskQuotas
SupportsFileBasedCompression
VolumeDirty
VolumeName
VolumeSerialNumber

I can’t find a DriveLetter but I know that DeviceId supplies that information – if in doubt check by displaying all properties of one instance or do this

PS> Get-CimInstance -ClassName Win32_Logicaldisk | ft -a

DeviceID DriveType ProviderName VolumeName      Size         FreeSpace
-------- --------- ------------ ----------      ----         ---------
C:       3                                      249951154176 146292559872
D:       3                      System Reserved 104853504    69279744
E:       2
F:       5

Drivetype matches with Win32_Volume so we get

Get-CimInstance -ClassName Win32_Logicaldisk | Select Deviceid, Size, FreeSpace
Get-WmiObject -Class Win32_Logicaldisk | Select Deviceid, Size, FreeSpace

You’ll have noticed that D: has a volume name of System Reserved. This means its a system disk that you shouldn’t be touching. Technically the event asked for information on local disks so it should be included. I know that some purists will argue against this so to remove the system volume you can

PS>  Get-CimInstance -ClassName Win32_Volume -Filter "DriveType=3 AND SystemVolume = $false"  | select DriveLetter, Capacity, FreeSpace

or

PS> Get-CimInstance -ClassName Win32_Logicaldisk -Filter "DriveType = 3 AND VolumeName <> 'System Reserved'" | select DeviceId, Size, FreeSpace

So either will give you the results you need.  You just need to dig into the classes a bit.

Scripting Games-Subfunctions

One of the principles of writing scripts (or any code) is the KISS principle – Keep It Simple Scripter.

That principle is being abused al lot in event 3

I am seeing numerous entries that define an advanced function as the solution and then inside the PROCESS block define one or more functions.  You PROCESS block is executed once for EVERY object on your pipeline. For 1 object might not matter but for 100s of objects it will adversely affect performance.

The solutions are such that they sensibly fit in a single solution.  If you must define additional functions make the solution a module so you only load them once.

Scripting Games–filtering on remote server

In event 3 you have to get information on hard disk capacity.  I’ve only looked at the first couple of dozen scripts but seen this too many times

Get-WmiObject -Class Win32_LogicalDisk | where DriveType -eq 3

or if you prefer the version 2 way

Get-WmiObject -Class Win32_LogicalDisk | where {$_.DriveType -eq 3}

If puppies get terminated for using Write-Host this sort of construct should triggers a mass extinction.

When pulling information back with WMI (or any other technique) from a remote server ALWAYS, ALWAYS, ALWAYS filter on the remote server.  What you are doing here is pulling back all of the data and filtering on the client. This is grossly inefficient when you are dealing with hundreds of machines.

The PowerShell team gave us the –Filter parameter on Get-WmiObject for a reason. Its to do the filtering on the remote server.

Get-WmiObject -Class Win32_LogicalDisk -Filter "DriveType = 3"

If you are guilty of not using –Filter write out 100 times “I must filter on the remote server”

And no – you can’t write a PowerShell script to do it for you!

Scripting games–ErrorActionPreference

I’ve seen a lot of this type of thing in events 1 and 2

$ErrorPref = $ErrorActionPreference
$ErrorActionPreference = "Stop"

Don’t

The default for $ErrorActionPreference is Continue.  This means that the error message is shown and the cmdlet attempts to continue. The possible values (from about_Preference_Variables)

Stop:               Displays the error message and stops  executing.

Inquire:            Displays the error message and asks you  whether you want to continue.

Continue:           Displays the error message and continues executing.
(Default)          

SilentlyContinue:   No effect. The error message is not displayed and execution continues without interruption.

This preference variable only affects non-terminating errors. A terminating error will still stop processing.  Using

$ErrorActionPreference = "Stop"

effectively turns all errors in to terminating errors.

There are times when you want to stop processing and deal with the error such as

try {

some cmdlet

}

catch {

do something

}

In this case use –ErrorAction Stop  on the cmdlet to force errors to be terminating. Just makes sure you have the code in place to catch the error.

Scripting Games–making work

I saw this in one of the submissions:

$Properties = @{}
$Properties['Computer'] = $SystemInfo.__SERVER
$Properties['OperatingSystem'] = "$($OSInfo.Caption) - $($OSInfo.CSDVersion)"
$Properties['PhysicalMemory'] = $SystemInfo.TotalPhysicalMemory  

My immediate thought was the entrant likes making work for themselves. The hash table can be created in a much simpler manner

$Properties = @{
Computer = $SystemInfo.__SERVER
OperatingSystem = "$($OSInfo.Caption) - $($OSInfo.CSDVersion)"
PhysicalMemory = $SystemInfo.TotalPhysicalMemory
}

Same result. Less typing and easiert o read when you come back to the script in 6 months time

AD MoL Chapter 10 MEAP

Chapter 10 of AD Management in a Month of Lunches is now available.

http://www.manning.com/siddaway3/

The chapter covers Fine Grained Password Policies

Scripting Games–new Get-ChildItem parameters

One improvement that came with PowerShell v3 is the –File and –Directory parameters on Get-ChildItem

If I run this

Get-ChildItem -Path c:\mydata

I will get a mixture of directories and files

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        19/11/2012     20:19            Delivery
d----        26/02/2013     19:24            Demo
d----        05/05/2013     11:26            ScriptingGames 2013
d-r--        07/05/2013     18:17            SkyDrive
d----        24/01/2013     20:08            Summit NA 2012
-a---        06/05/2013     15:26    1336320 2013May_ErrorHandling.doc

If I add the –Recurse parameter it gets worse – I know I’ve got a lot of files and directories in here.

In PowerShell v2 you could separate the directories and files by using PSISContainer

Get-ChildItem -Path c:\mydata | where {$_.PSIsContainer}
Get-ChildItem -Path c:\mydata | where {!$_.PSIsContainer}

will give you the directories only and files only respectively.

It gets easier in PowerShell v3

Get-ChildItem -Path c:\mydata -Directory
Get-ChildItem -Path c:\mydata –File

simple and obvious when you read it.

if you are using PowerShell v3 don’t forget these parameters

Scripting Games-don’t repeat the work

There are some good features to this script but what really hurts is the two trips to the server for the Win32_Computersystem class

Foreach ($IP in (Get-Content "C:\IPList.txt"))
{
  $Name = (Get-WMIObject Win32_ComputerSystem -ComputerName $ip).Name
  $Mem = [math]::truncate((Get-WMIObject Win32_ComputerSystem -ComputerName $ip).TotalPhysicalMemory / 1MB)
  $Ver = (Get-WMIObject Win32_OperatingSystem -ComputerName $ip).Caption
  [Array]$Cpus = (Get-WMIObject Win32_Processor -ComputerName $ip)
  $CpuCount = $Cpus.Count
  $Cores = 0
  Foreach ($Socket in $Cpus)
    {
    $Cores = $Cores + $Socket.NumberOfCores
    }
  "$Name,$Mem,$Ver,$CpuCount,$Cores" | Out-File output.csv -Append
}

it would be better to do this 

$comp = Get-WMIObject Win32_ComputerSystem -ComputerName $ip

$name = $comp.Name

$mem = [math]::truncate($comp.TotalPhysicalMemory / 1MB)

Dropping one round trip on a few servers isn’t that big a deal.  dropping it on 3000 servers will make a difference

Always think about how your scripts may need to scale one day

Scripting Games–how not to output data

I haven’t finished blogging about event 1 yet but this caught my eye.

Things aren’t too bad until we hit the bunch of  write-host calls

$wrks = (Get-Content -path C:\IPList.txt)
foreach ($wrk in $wrks)
{
    $osver = Get-WMIObject -class win32_operatingsystem -ComputerName $wrk
    $procs = @(Get-WMIObject -class win32_processor -ComputerName $wrk)
    $psok=($procs.SocketDesignation).count
    $pcors=(($procs.numberofcores[0])*$psok)
    $plog=($pcors * 2)
    $psped=$procs.MaxClockSpeed[0]
    $mem = Get-WMIObject -class win32_physicalmemory -ComputerName $wrk
    $memtotal = ($mem | Measure-Object -Property capacity -Sum)
    $memgb = $memtotal.sum/1gb
Write-host "*******************************************************"
Write-Host "Machine Name: " $osver.CSName
Write-Host "OS: "$osver.caption
Write-Host "Service Pack: "$osver.csdversion
Write-Host "Build #: "$osver.version
Write-Host "*********** "
Write-Host "Memory Installed:"
Write-Host "*********** "
Write-Host "Memory (GB): $memgb "
Write-Host "Slots used:" $memtotal.Count
Write-Host "*********** "
Write-Host "Processor(s) Installed:"
Write-Host "*********** "
Write-Host "Sockets:" $psok
Write-Host "Cores:" $pcors
Write-Host "Logical Procs:" $plog
Write-Host "*********** "
Write-Host "Processor Details:"
Write-Host "*********** "
$procs
Write-Host ""
}

The correct way is to create an object and output that

I’ll be blogging a sample answer when the games are over.  for now be aware that write-host is worse than backticks

Scripting Games: event 1–use of robocopy

The object of the exercise in both the beginners and advanced sections of event 1 was to move a set of log files older than a give data to an archive folder.

A number of solutions were presented that used robocopy.

This is a workable solution that meets the lettter of the objective but it doesn’t really meet the spirit of the games.

The Scripting Games is about learning to use PowerShell.  Within PowerShell there is a move-item cmdlet.

Robocopy isn’t required. Using non-Powershell tools can often be harder than using PowerShell.  In your work, and especially in the games, think very carefully before reaching for a non-PowerShell command

And its not PowerShell!

Scripting Games–major dislike #2

I’ve already blogged about incorrect use of backticks.  Here is another example of un-necessary use of backticks

$Files= Get-ChildItem `
        -Path $Path `
        -include $Type `
        -Recurse `
        -File |
Where-Object {$_.LastWriteTime -lt (get-date).AddDays(-$OlderThan) }

Spreading out one parameter per line like this doesn’t add anything to the script and makes working on the get-childitem cmdlet code harder if you want to change it.

Don’t do this

Scripting games-major dislike

One of the things we were asked to blog about as Scripting Games judges was things we liked and disliked. This code is a major dislike

Get-ChildItem $sourceDirectory | ? {$_.PsISContainer } |
     % { $subDirectory = $_ ; Get-ChildItem ("$sourceDirectory\$subDirectory") -Include *.LOG -Recurse } |
         ? { $logFile = $_ ; $logFile.LastWriteTime -le $modifiedCutOffDate } |
             %  { $logFileAndSubDirDictionary.Add($logFile, $subDirectory) }

Two things really make this stand out as how not to do things:

1. Using % & ? as aliases in a script. They are tolerable (just) in an interactive command but have no place in a script. Tab completion is so easy. Use the proper command.
2. Putting multiple commands on a line separated by ;      It makes the code hard to read and awkward to work out whats going on. It also makes script testing, debug and maintenance much more difficult

Avoid these two things in your scripts

Scripting Games–integer parameters

I keep seeing paramter constructs like this:

[int]$age = '90'

Why set the parameter to an integer and then set the default as a string.  PowerShell will convert but it just doesn’t make sense.

All you need is

[int]$age = 90

Scripting games–using parameters

I am seeing an incredible number of scripts that have this sort of coding round parameters

# Input from the user
    [Parameter(Mandatory=$false,
               ValueFromPipeline=$False,
               Position=0)]
    [ValidateScript({Test-Path $_ })]
    [String]$SourcePath = 'C:\Application\Log',
 
 
    [Parameter(Mandatory=$false,
               ValueFromPipeline=$False,
               Position=1)]
    [ValidateScript({Test-Path $_ })]
    [String]$ArchivePath = '\\NASServer\Archives',
 
 
    [Parameter(Mandatory=$false,
               ValueFromPipeline=$False,
               Position=2)]
    [Int]$Days = 90

Why do you need to state that Mandatory=$false or that ValueFromPipeline=$False.  The DEFAULT values are false.  You only need to use them if you are setting them to TRUE.

Its a waste of coding time and processing time when you run the script.

I remember blogging about this last year.

Please stop doing it so I don’t to blog about it next year

Scripting Games–observation

I don’t have the numbers to back this up but my feeling is that the Scripting Community is marking the entries for this years Games in a harsher manner than the judges did over the last few games.

What will be very interesting is the level, type and usefulness of the comments that come through. if you do mark low please explain why

Whether this relaxes over the next few entries will be interesting to see.

Scripting Games–a word of advice for competitors

At the moment it isn’t necessary to run your script to give a vote.

Probably the quickest way to lose points is have an obvious and glaring error in your script such as

. . . | where {$_.LastWriteTime –lt (date).ADDdays(-90)} | . . .

or

. . . | where {$_.LastWriteTime –lt (get-date).ADDseconds(-90)} | . . .

Both of which I’ve seen today.

Please make sure your script syntax is correct before you submit otherwise all your hard work will be for nothing

Filter vs Include

I’ve gone through most of the Beginner event submissions over the last couple of days.  One thing that has jumped out is the potential misunderstanding around using the –include or –filter  parameters on get-childitem.

If we look at the two parameters

-Include <String[]>
    Gets only the specified items. The value of this parameter qualifies the Path parameter. Enter a path element or  pattern, such as "*.txt". Wildcards are permitted.
    The Include parameter is effective only when the command includes the Recurse parameter or the path leads to the contents of a directory, such as C:\Windows\*, where the wildcard character specifies the contents of the C:\Windows directory.

-Filter <String>
    Specifies a filter in the provider's format or language. The value of this parameter qualifies the Path parameter.
    The syntax of the filter, including the use of wildcards, depends on the provider. Filters are more efficient than other parameters, because the provider applies them when retrieving the objects, rather than having Windows PowerShell filter the objects after they are retrieved.

These are best explained by some examples. Lets start with the current directory

PS> Get-ChildItem -Filter *.csv | select -First 1

    Directory: C:\MyData\SkyDrive\Data\scripts

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        12/09/2012     19:07       2665 log.csv

but

Get-ChildItem -include *.csv | select -First 1

returns nothing

To get –Include to work you need to do this

PS> Get-ChildItem  -path .\*  -include *.csv | select -First 1

    Directory: C:\MyData\SkyDrive\Data\scripts

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        12/09/2012     19:07       2665 log.csv

The path has to be given for –Include to return anything

Looking at another folder

These work

Get-ChildItem -Path C:\MyData\SkyDrive\Data\scripts -Filter *.csv

Get-ChildItem -Path C:\MyData\SkyDrive\Data\scripts\* -Filter *.csv

Get-ChildItem -Path C:\MyData\SkyDrive\Data\scripts\* -Include *.csv

Get-ChildItem -Path C:\MyData\SkyDrive\Data\scripts -Include *.csv -Recurse

But these don’t

Get-ChildItem -Path C:\MyData\SkyDrive\Data\scripts -Include *.csv

Get-ChildItem -Path C:\MyData\SkyDrive\Data\scripts\ -Include *.csv

If you want to use –Include remember the path and wildcard or use recurse

Getting the folder name

Consider the file information from get-childitem

PS> $file = ls servicesv0.6.txt

Fullname gives the full path to the file

PS> $file.Fullname
C:\MyData\SkyDrive\Data\scripts\servicesv0.6.txt

if you use DirectoryName you get the full path to the parent directory

PS> $file.DirectoryName
C:\MyData\SkyDrive\Data\scripts

The easiest way to get the folder holding the path is like this

PS> Split-Path -Path $file.DirectoryName -Leaf
scripts

However on a Windows 8/PS 3 setup you can also do this

PS> $file.Directory | select -ExpandProperty Name
scripts

Don’t go mad on a one liner

Looking at my first group of entries for Beginners Event 1 I’ve noticed what seems like a fanatical attempt to squash everything onto one line.

command; command; command; command 

is NOT a one liner.  The ; marks the end of a line

command | command | command | command

IS a one liner, even if it goes onto multiple lines!

Don’t think one liner – think one PIPELINE