Week 2: ISE, ExecutionPolicy, and Popup

DISCLAIMER: This was originally a way to document what I was learning when I first ran into PowerShell as a student who had no prior scripting experience. The examples given and the posts done in relation to the project most likely do not follow best practices and should definitely be reviewed if they are going to be used in any fashion. You have been warned! 🙂

Here is some script prepping. Also, some resource links should be thrown up on The PowerShell Project page fairly soon.

What is this post about?

  • ServerManager
  • PowerShell ISE
  • Execution Policy
  • Super Simple Script II
  • Mistake of The Week

ServerManager

Anybody who uses Windows Server 2008 R2 is familiar with Server Manager. It is the hub for roles and features: installing, uninstalling, and merely looking at it’s information.

Import-Module ServerManager

Now you have extra cmdlets available to you to look at enabled roles/features.

Get-Command -module servermanager
Add-WindowsFeature
Get-WindowsFeature
Remove-WindowsFeature

Feel free to check the hep files, but start with “getting” the WindowsFeature list. On the right hand side are the parameters you would use when running the other two servermanager cmdlets.

PowerShell ISE

On that note, let’s add this feature! The PowerShell ISE, or Integrated Scripting Environment, has helped me immensely when writing scripts. Color-coded script commands, much like using an IDE, help in reading your scripts. Built-in to the ISE is a PowerShell prompt for testing commands as you go along. You can press the play button along the top to do a full-run of your current script, or even highlight a portion of text to run through a right-click menu.

# Here we are making the ISE available to you
Add-WindowsFeature PowerShell-ISE
ISE

Just typing “ISE” in PowerShell will launch it. Now that it’s launched, I advise pinning it to your taskbar (right click the ISE icon currently on the taskbar, and choose “Pin This Program to Taskbar”).

Tip: Now you can use the Windows shortcut to run ISE (or other unworthy applications) from the taskbar! Just hold [Win + #] to launch it, with the # really being how many icons away it is from the start menu. Example: [Win + 1] will launch whichever application you have closest to the start menu.

Execution Policy

I went through the pains of installing the .NET SDK, making my own machine-based certificate, making a script that signs other scripts, made sure to sign the script that signs first (or else it wouldn’t run), then ran happy self-signed scripts under the “AllSigned” execution policy.

For testing purposes, I would simply tell you to avoid this. Completely. Turn your execution policy to “Unrestricted” and you should be happy.

# I wants all scripts to runs, don’t bother me! I’m using a VM anyway!
Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Super Simple Script II

After all of that long-road for a signature, let’s go with something simple. This one is about adding a special end-line that gives a confirmation window. We want the user to know it was a accepted, and to include a variable or two within the message.

# First line calls the ingredients for a GUI “form”
 [System.Reflection.Assembly]::LoadWithPartialName(“System.Windows.Forms”)
$wat =Read-Host “Type something here” 
 [System.Windows.Forms.MessageBox]::Show(“You typed “$wat” and this box is showing you stuff.”, “Awesome”)

When defining the variable, we chose it to be defined by the user each time the script would be run. User-interaction is really a big part of script development. It makes it so that the user wouldn’t have to manually edit the script everytime it wishes a variable to have a different definition.

Mistake of The Week

Confirmation windows shouldn’t always be accepted with open arms. What if your script didn’t care in the event of an error, and still gave the thumbs up? -ErrorAction or -ErrorVariable

# Let’s totally fail at making a .txt
Write-Host “Let’s make a text document!”
$dafile = Read-Host “Name the text document”
new-itme -ItemType file -Name $dafile.txt # <– Look! I sucked and made a cmdlet typo
[System.Reflection.Assembly]::LoadWithPartialName(“System.Windows.Forms”)
[System.Windows.Forms.MessageBox]::Show(“$dafile was successfully made.”, “Awesome”)

Yeah, uh, we need to adjust this script for error-checking. Error checks are a big part of scripting, because error-log creation and error messages tell you what went wrong…or at least, that something went wrong. Otherwise, what you see up above just gave a thumbs up even though there was a failure.

So, I’m about to tell you about error checking right?

Nope. I’m not. You will have to stare when failures happen for now.

That’s going to be in one of the upcoming posts, which will include “If” statements for what to do in the event that an error occurs. See you next week with Active Directory!

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s