Month of Lunches - Day 17

Day 17 - You call this scripting

Today we get into PowerShell and scripting with PowerShells Integrated Scripting environment or ISE. So far we have been using single line commands and lthough they are powerful there is a lot more we can do. If the shell prompt is like a new world opened up to us, then the ISE is like the final frontier.

Don likens basic PowerShell scripting to writing a batch file, and he is correct. Basic PowerShell scripts are nothing more than a series of commands written one after the other that run in sequence. We can link anything that we have learned so far (as long as there is a reason for the madness) into a couple of lines of PowerShell code in the ISE script pane and save it as a PS1 file (PowerShell script file). We glossed over the ISE and what it is in a little bit in the first couple of chapters. Just a couple of notes on the ISE. It has a couple of really nice features such as tab completion (same as in the command shell), script color coding to make it easier to read, and run all or just a portion of the code you have written with the click of a button. Here is an example I wrote during this learning process:

                $computerSystem = Get-WmiObject win32_computerSystem

                write-host -NoNewLine "Computer Manufacturer: "

                Write-Host -ForeGroundColor red ` $computerSystem.manufacturer

                write-host -NoNewLine "Computer Model: "

                Write-Host -ForeGroundColor red ` $computerSystem.model

Basically what this is (and I reset it to lookup the local host information) is a way to return the manufacturer and model. The -NoNewLine parameter just makes the information return on the same line as the title. Just for fun I returned them in red.

In this script I would have to define the variable but say I wanted to give it out for someone else's use. The next section of the book covers parameterizing commands. It would be a simple change to Get-WmiObject to have it looking up remote PC's from text files, csv files, or return result queries, but if you paramatize it then you don’t have to worry about it. Like so:

                param (

                    $computer = 'localhost'

                    )

                $computerSystem = Get-WmiObject -ComputerName $computer win32_computerSystem

                    write-host -NoNewLine "Computer Manufacturer: "

                    Write-Host -ForeGroundColor red ` $computerSystem.manufacturer

                    write-host -NoNewLine "Computer Model: "

                    Write-Host -ForeGroundColor red ` $computerSystem.model

Now you only need to save this file under whatever name in whatever directory you want ( in this example C:\Man_Mod.PS1) and use the -computer parameter to specify which one you want. now you can change directory to the C: drive and run:

               

                .\man_mod.ps1 -computername *Whatever you want*

And it will run basically just like as if it was a cmdlet. Now notice that the script file is preceded with a .\ and this annotates for the shell to look in the current folder for a script file (which you specified by name. All scripts that are run in the shell must be preceded with the .\. Now im sure there are easier ways to do this (as with everything in PowerShell) but this is the one that worked for me.

                                                                                                                                                                                              

The next section is documenting your script. This is something that is very important to me as a person who is not good at writing his own scripts (YET!). Knowing what the script is doing and how makes it very easy to see what is going on, how to modify to get the results you want, and (if you’re a visual learner like me) learn how to put a script together.

The last thing that we covered today was PowerShell scopes. Each PowerShell session has its own scope and child scopes that are created when a script or command is run. These are created by other elements of PowerShell, aliases, variables, or functions (which we haven't learned about yet). These elements will search for whatever they are looking for inside there own scope first, if they don’t find what they want they will go to there parent scope. They will continue up the line until they either find what they want or run out of places to look once they reach the PowerShell session scope otherwise known as a global scope. They will not look into other sibling scopes for information.