Perhaps the number one reason to write a Windows PowerShell script is to address recurring needs. As an example, consider the activity of producing a directory listing. The simple Get-ChildItem cmdlet does a good job, but after you decide to sort the listing and filter out only files of a certain size, you end up with the command shown here:
Get-ChildItem c:\fso | Where-Object {$_.Length -gt 1000} | Sort-Object -Property name
Even using Tab Completion, the previous command requires a bit of typing. One way to shorten it would be to create a user-defined function, and we will examine that technique later. For now, the easiest solution is to write a Windows PowerShell script. The DirectoryListWithArguments.ps1 script is shown here:
DirectoryListWithArguments.ps1
foreach ($i in $args) {Get-ChildItem $i | Where-Object {$_.length -gt 1000} | Sort-Object -property name}
The DirectoryListWithArguments.ps1 script takes a single, unnamed argument that allows the script to be modified when it is run. This makes the script much easier to work with and adds flexibility.
An additional reason that network administrators write Windows PowerShell scripts is to run the script as a scheduled task. In the Windows world, there are multiple task scheduler engines. Using the WIN32_ScheduledJob Windows Management Instrumentation (WMI) class, you can create, monitor, and delete scheduled jobs. This WMI class has been available since the Windows NT 4 days. On Windows XP and Windows Server 2003, the schtasks.exe utility offers more flexibility than the WIN32_ScheduledJob WMI class. On Windows Vista, a Schedule.Service object is available to simplify configuration of scheduled jobs.
The ListProcessesSortResults.ps1 script is a script that a network administrator may want to schedule to run several times a day. It produces a list of currently running processes and writes the results out to a text file as a formatted and sorted table.
ListProcessesSortResults.ps1
$args = "localhost","loopback","127.0.0.1" foreach ($i in $args) {$strFile = "c:\mytest\"+ $i +"Processes.txt" Write-Host "Testing" $i "please wait ..."; Get-WmiObject -computername $i -class win32_process | Select-Object name, processID, Priority, ThreadCount, PageFaults, PageFileUsage | Where-Object {!$_.processID -eq 0} | Sort-Object -property name | Format-Table | Out-File $strFile}
One other reason for writing Windows PowerShell scripts is that it makes it easy to store and share both the “secret commands” and the ideas behind the scripts. For example, suppose you develop a script that will connect remotely to workstations on your network and search for user accounts that do not require a password. Obviously, an account without a password is a security risk! After some searching around, you discover the WIN32_UserAccount WMI class and develop a script that performs to your expectation. Because this is likely a script you would want to use on a regular basis, and perhaps share with other network administrators in your company, it makes sense to save it as a script. A sample of such a script is AccountsWithNoRequiredPassword.ps1, which is seen here.
AccountsWithNoRequiredPassword.ps1
$args = "localhost" foreach ($i in $args) {Write-Host "Connecting to" $i "please wait ..."; Get-WmiObject -computername $i -class win32_UserAccount | Select-Object Name, Disabled, PasswordRequired, SID, SIDType | Where-Object {$_.PasswordRequired -eq 0} | Sort-Object -property name | Write-Host}