In my recent interview on the PowerScripting Podcast, one of the excellent questions was “What are the 5 misconceptions or hurdles people have when they start learning PowerShell?” I thought the question merited a longer reply, and of course these are my opinions.
#5. PowerShell security isn’t important
I spend time discussing why and how PowerShell is secure by design and default. I explain about signing scripts and PowerShell’s execution policy. But I don’t think the importance really sinks in. And it probably won’t until some company practices poor PowerShell security and gets stung. In a production environment you should settle for nothing less than the AllSigned execution policy. The primary purpose here, and something I’ll have to stress even further in class, is to protect your profile. Your PowerShell profile is a simple text file that lives in your documents folder. There are any number of ways that malware, could attack it and add a line like:
get-qaduser | remove-qadobject -force
The next time you started PowerShell, your profile would load and this line would run. Hope your resume is up to date. Yeah, I know that this won’t run if you don’t have the right permissions but most administrators are likely to start PowerShell with elevated privileges. That’s a topic for another day. But pick your own worst nightmare. The point is, if you policy is set to AllSigned, if your profile is modified without your knowledge, it won’t run when you start PowerShell because the signature is broken. We’ll revisit this topic in the future I’m sure.
#4. Not asking for help
PowerShell itself is a fantastic source of information on how to use it. The help system can teach you quite a bit if you know how to ask. All Microsoft cmdlets and most 3rd party have extensive help files with detailed information and examples. I always have fun with this and say that nothing replaces a well written book, but the truth is, if you don’t have a book handy and are trying to figure something out, look at the PowerShell help. I see a number of questions in forums these days that could have easily been solved by looking at cmdlet help.
#3. PowerShell is just another scripting language
I believe many first time students think PowerShell is going to be just another scripting language like VBScript. This couldn’t be further from the truth. In my opinion, PowerShell is an advanced management shell that happens to support automation via PowerShell scripts. But a PowerShell script is no different than what you type interactively in the shell. All the script does is save typing. You can spend all your time in PowerShell and not write a single script. Its just that more complicated or repetitive tasks are more efficient when executed from a script.
#2. VBScript thinking
There is nothing wrong with VBScript and I expect it to be around for a while but many people come to PowerShell with a VBScript mindset. I think they are expecting to use VBScript-type structures and commands. They approach automating in PowerShell the way they would VBScript. I see a lot of scripts in discussion forums that are merely PowerShell versions of VBScript. The scripts will work, but they don’t take advantage of PowerShell which leads into the number 1 misconception and hurdle.
#1. PowerShell is like CMD
Many administrators who have previous shell experience, be it with the CDM shell or even a *nix shell, initially treat PowerShell the same way. They look for ways to manipulate the text output they see on the screen. The challenge is to get your head around the object-based approach to PowerShell. Instead of parsing text to get specific values, manipulate the object properties and instruct PowerShell how to display them to the screen. The end result is text on the screen, but how it got there is very different than what are used to. Once you understand how to work with objects and leverage the pipeline, PowerShell becomes easier to use and is the key to mastering it.