February 19, 2016


Grumpy Admin here – with a sore head from banging the desk too much I might add! First I strongly admire that PowerShell is making inroads here in the office, and is slowly becoming used more and more :). It is the future, we been saying it, I been laughed at and slowly they are coming around to my PowerShell indoctrination.

Using my slow and manipulating ways, PowerShell is creeping in to everyday use here, maybe one day I will get to replace my boss with a script! (we can hope!!!) We all use NLP right to get what we want!!!!…right????

This happy steak didn’t last for long… When someone in the office was trying to script something that needed to use the computer name. He is from the generation like me that used %computername% all the time in dos etc.

He was starting to get an even bigger bold spot on his head from scraping so much when he encountered the following line…



Now you can see why my head hurts…. It is understandable as someone transitions and is learning PowerShell that these sort of things that seem intuitive as we used them for years but suddenly don’t work. So a after correcting him, I thought i would share a couple of things about Environmental Variables in PowerShell. Yes – it’s a slow day in the office… Mind you, yesterday we had a Goat escape a farmers field and invade the office Car Park – You can imagine the jokes and email chains that produced! Anyway….

echo while works isn’t in my mind PowerShell – it’s not a cmdlet it is in fact an alias for write-output!!! I suspect it was created as an alias to help people who use echo as habit!

If we do a simple get-alias we can clearly see it is an alias!




I had to explain how environmental variables are handled in PowerShell. The concept not hard and 3 seconds is all it took really. After all, I might dish my co-works but I only jest they are quite smart really! However, sometimes, it good to explain the basis stuff, as we can easily skip over stuff the basics and look at the complex and more fun stuff when learning something! I do this all the time!!!

So let’s have a look, at what environment variables there are in my systems. First let’s look at the old cmd prompt way which this person was most used to doing things with!

For them old enough to remember – we can use the old dos command prompt command



as seen here


So Grumpy Admin what is the PowerShell equivalent? I hear you ask, but expect if you are reading this you already know!

get-childitem env:


we can see all the local variables; it is the exact output as the SET command in CMD




Excellent, and how do we reference it in scripting then? Well it’s a PowerShell variable so we can just

$Env:<variable name>

so our echo %computername% becomes

write-output $Env:ComputerName




Simple, Done – Well, there are some other things I should mention as I am doing a blog post, and blog post about reading a variable isn’t well an exciting or useful read is it!  I actually question, if this blog is worth posting! Meh! Not posted in ages so going to bore you all with it anyway!

So we can read them, what about creating new ones?

This can be done very simple using standard variable declaration method.

$Env:GrumpyAdmin = "Grrrrr"



You can use this exact same method of modify the content of a variable already declared! I will spare you that! However, will this be a permanent variable – Sadly NO! Think of scopes of variables. It isn’t saved!

So how do we get something changed so that it lasts forever!

Well let’s have a look – TechNet for the win of course.


Now if you notice, this is a PowerShell 1 article, this show that this is been there from the beginning! It’s a fundamental aspect but we can understand how things like this can be over looked!

TechNet teaches us to use the .Net framework to do this. This gives us a bit more control over the scope of things… However, typically you keep it at the User Level!

The three scopes that a variable can actually have is:


The basic syntax used is the SetEnvironmentVariable function in the [Environment] namespace. Grumpy Admin just loves it when things are simple and very clear!

[Environment]::SetEnvironmentVariable(“Variable”, “Value.”, “Scope”)

Let create one and give it a try!

[Environment]::SetEnvironmentVariable("GrumpyAdmin2", "More Grrrrr", "User")



and lets do a GCI on ENV: and have look


Excellent, confirmed!!! Let reload the DOS CMD prompt and see if we can see this variable now in the SET command. Note: we have to reload the CMD prompt as when it load it grabs the variables so it won’t know about our new one till it is reloaded!



Wow excellent You can see it there!

Hang on!!!! Where did that GrumpyAdmin 3 = More Grrrr come from?

You got me, I added in an extra variable!  Cause I might as well demo how to delete variables as well! Grumpy Admin doesn’t do half-job except if it’s the washing up or system documentation.

Here all we need to do is $null the variable and it will be destroyed!


[Environment]::SetEnvironmentVariable("GrumpyAdmin3", $null, "User")




There as you can see from these two screenshots, the variable is killed, gone and is no more!!!

So there you go, very quick and simple… now you understand why Grumpy Admin had to just bang his head on the table! Was that hard! No….

I just don’t know what annoyed me the most, being asked about this and having to show and explain or the fact the person was tooooooo lazy to google! I know, I know I always say IT administrators are lazy, but too lazy to google! that a new low! On the other hand, learning and self-improving is always good and should be rewarded! We are all student in life right?

Meh! COFFEE time!