Hello person who is reading this!

Today we’ll examine part 2 of our discussion on $variables, with a focus on PowerShell, though this really can apply to most any Object Oriented Programming (OOP) situations.

Hopefully you are either not too terribly new to this, or you read my last post about what an $object is, but we will now revisit the definition provided last time. A variable is an object that stores data for later use. Now that we understand what $object is, we can really open this up and explore.

The best way to explore is to start thinking about it in PowerShell formats. The first thing you can do is run this command in the PowerShell window:

$object = "This is an Object"

If you now put $object into the prompt, it will respond with:

This is an Object

Now why in the world would we use this? Well let’s add a new line of code to see what happens:

$object = Read-Host "Please input your name!"
Write-Host "Hello, $object! How are you?"

If you punch that into PowerShell it will first prompt you for your input (I.E. your name, and yes… you can put anything you’d like you juvenile delinquent), then it will write back the following sentence:

Hello, Nic! How are you?

(Seriously though, this is about to get a WHOLE lot more exciting I promise!)

So now we’ve created our first script, and it does absolutely nothing! WOO! Drop the confetti! (Wait… There is no confetti!? What the hell kind of blog are we running here!?)

So let’s move onto a much more practical use of a variable for your interactive enjoyment!

You will, at some point in your career, need to run a cmdlet on a remote machine. There are several ways you can do this, but if you are wanting an interactive session you’ll want to run code like this:

$cred = Get-Credential
$remoteSession = New-PSSession -ComputerName SillyServer -Credential $cred
Import-PSSession $remoteSession

We used TWO whole variables there (Oh crap, it’s getting real in here). The first is $cred (Which is short for Credential, in case the cmdlet following it didn’t tip you off… But seriously, if it didn’t, this might not be the blog for you. ((Sorry Mom!)) ), which is used to save your credentials. It creates an interesting object that we can dissect.

credential

You’ll notice I used a method call against the variable. THIS is possibly one of the greatest tools that you could ever have in PowerShell. (Seriously, like… This is almost on par with Get-Help, and I literally had an entire post about that. Yay for insulting my readership’s intelligence! Not you! No no! Don’t click to the next site! I swear I’ll appreciate you baby! It won’t happen again! I LOOOOOVE YOU!)

With the $variable.GetType() method call, we can look and see what sort of $variable we have. As an aside, PowerShell has a kabillion .Net object types, but the vast majority of them are just ‘special’ [hashtable].

So when we look at our $cred.GetType() we see it is a PSCredential type object. In the script above, we simply use it as is to pass credentials to the remote computer, but there are a lot more interesting things that can be done. (Though, admitibly, not nearly as interesting as those crazy penguins in Madagascar. Those guys are nuts!)

First we’ll look at the other ways we can use the .method to examine the variable. Remember, it is a [hashtable] so we can call attributes and get the responses back:

Credentials2

As we can see, it has two attributes, $cred.UserName and $cred.Password. The great part of this is that we can call them and use them as strings. (We’ll touch more on the usefulness of this feature in a bit, but FIRST!) Additionally, we can call the .GetType() method to examine what each of these attributes actually are:

Credential3

The first is our good old buddy [string], and the second is a special type of [string] called [securestring]. It isn’t really any different other than it is stored after going through an encryption algorithm to hide the actual content of the string. PowerShell generates this based on your user account and the computer itself, so you can’t unencrypt it unless you log into the same computer and use the same credentials.

So to wrap this all up, we created a [hashtable] (Object) that stores our credentials (Data) for later use.

The second variable is not quite as exciting, but it is still interesting. It is another [hashtable] that references an interactive PowerShell session on a remote computer. You can play with all of the modifiers for this as well.

So, the last thing I’m going to do before I wrap up this post is discuss the true usefulness of being able to take objects and refer to their strings. Sometimes, you will only want some parts of data, other times, you’ll find that certain cmdlets just don’t like what other cmdlets are passing. In these instances, being able to pull the string (Or whatever for that matter) out of an object is extremely powerful. Let’s look at an example.

In Exchange Online, if we run the Get-Mailbox cmdlet, we get a few parts of information. The displayname, the quota limits, the alias… Etc… Now, what if we want to find all of our users who have a quota limit of less than 5 GB of data? We can’t just pass our mailbox object because it isn’t an [int] that we can do basic math against. So instead we would do this:

$mailbox = Get-Mailbox
if($mailbox.ProhibitSendQuota -lt 5)
     {
     Write-Host $mailbox.Name
     }

As we can see, we used two attributes of the $mailbox variable. the first, ProhibitSendQuota, is a numerical value based on how many GB the mailbox sendquota limit is at.
The second is just .Name so that we don’t get an entire output, but just the name of the user who is affected.

The practical applications of the methods and attributes for $variables is almost endless.

Anyway, that about wraps this post up. If you have any questions or comments feel free to leave them below!

Leave a Reply

Your email address will not be published. Required fields are marked *