PowerShell is an awesome scripting language and a must-have for any IT professional’s tool kit. I am by no means a PowerShell Master, but if you’re just starting to pick up PowerShell, here are a few tips that I’ve learned along the way that may help you get started on the right path.

Find a good ISE to write your scripts

An ISE is an Integrated Scripting Environment. This is generally an advanced text editor with tools built in to help you write working code. I started out writing all of my scripts in Notepad++, and while Notepad++ has some decent features for writing quick scripts, it can be a little clunky.

PowerGUI

For the last couple of years, I’ve used PowerGUI almost daily for writing my scripts, and would highly recommend it. PowerGUI includes a bunch of additional features over NotePad++, including variable tools and an integrated shell, making it a much more robust application for developing PowerShell than NotePad++. And it’s free! PowerGUI is no longer in development, but you can still find ways to download it. For example, you can install it using Chocolatey.

 

VS Code

I’ve recently begun testing Visual Studio Code, another free ISE. VS Code is an open source and highly-customizable ISE from Microsoft that supports a ton of great features, including extensions, and has a ton of developer support.

In short, find an ISE that you feel comfortable working in, and you’ll find yourself writing better scripts faster and with fewer headaches.

Organize and source protect your scripts

When I first starting writing PowerShell, I would write a script local to the system that I was trying to automate and would just leave it in a local folder like ‘C:\scripts’. This got the job done, but after writing a couple dozen scripts, it got more difficult to keep track of which scripts were running where and what they were doing.

To address this, I deployed a new VM and set up a handful of environment-specific repos in GitHub, which I then cloned to the VM. I migrated all of my scripts from the various systems in our environment to these repositories. The end result was that all of my scripts were now located in a single, manageable location.

By source-protecting these scripts in GitHub, it also took out the hassle of figuring out which version of  a script was the latest and greatest one I was last working on (instead of sorting through script.ps1, script-new.ps1, script-new2017.ps1, etc.). I ended up with a single master copy of the script, source-protected in GitHub, which made it easier to organize and schedule the correct scripts.

Use PowerShell Profiles

PowerShell provides a few different custom profiles that you can configure within Windows to execute code when you first launch a PowerShell console. You can use these custom profiles to:

• Load modules
• Set up console output to a log file
• Define aliases
• etc.

I can’t even count the number of times I had to type ‘Import-module ActiveDirectory’ after launching a new PowerShell window over the years before just setting up my custom profile to load it automatically. Having my PowerShell windows load in a desired state automatically has been a game-changer, and has simplified the process of using PowerShell in my environment.

The PowerShell profile specific to your user account on your machine is probably located in your Documents folder.

Leave Comments for Yourself

After thinking of an idea for a script, writing it up and putting it into production, it’s not uncommon for me to have an idea for a piece of logic or functionality to improve the original script later down the road. Some of the scripts I’ve written (like Active Directory settings managers, Citrix profile cleaners, etc.) can wind up being several hundred lines of code when they’re all said and done. Opening up a script that I wrote 6 months before and figuring out how I wrote it can be difficult without good comments.

Get into the habit of adding comments throughout your scripts as you’re writing them. It will pay off time and time again when you think of new features and improvements to your scripts and can just easily open them back up and follow the comments.

Set up Logging And Reports

Automating technical environments with PowerShell is great. Automating technical environments AND seeing HOW they’re automating is awesome.

The great thing about PowerShell is that it can perform routine tasks for us without our involvement. This means less stress and more uninterrupted sleep. However, we are still responsible for the impact that these scripts have in our environment and for how well they’re doing their job. Setting up HTML email reporting and/or console exports to log files for us to review later help us keep a finger on the pulse of what our environment is doing behind the scenes. Having this kind of feedback can keep us from checking up on what a script is doing months later and finding that a bug in the logic has created a huge and unexpected issue for us that has to be addressed.

Check out my tutorial on creating email reports.