Windows Administration with PowerShell #1: Introduction

Over the past decade, Microsoft has been making a push to place PowerShell as the tool of choice for all Administrative tasks in a Windows environment. The problem is that a lot of people still see it as “the blue version of the cmd prompt.” However, it’s so much more than that. More cmdlets are added every day which enable administrators to accomplish increasingly complicated tasks in a couple lines of code. We at Automox believe in doing everything in our power to make administration of your environment as easy as possible. Part of that means ensuring that you are familiarized with the tools available to you as administrators/engineers. As such, we will be releasing a weekly blog detailing some of the more impressive feats you can accomplish with PowerShell.

Gee, Brain, what do you want to do tonight?

The same thing we do every night, Pinky, talk about PowerShell. Joking aside, today’s installment will cover some of the basics of working with PowerShell. Let’s dive right in.

PowerShell File Formats

PowerShell actually supports quite a few different file formats. Determining which format to use can be confusing at times, but are ultimately very useful.

  • .ps1 - The ps1 format is the most common format you will encounter. These are referred to as PowerShell scripts and generally, contain simple functions and/or workflows which accomplish relatively menial tasks.
  • .psm1 - These are referred to as PowerShell Modules and generally contain advanced functions that can be used across multiple scripts. Instead of copy and pasting the same code to various scripts, you can place it in a .psm1 file which can be referenced from those scripts. The included functions can then be utilized as needed.
  • .psd1 - These are referred to as PowerShell Data Files and are generally used as manifests to group together multiple Powershell Modules.

Think of these three file types as building blocks. When your scripts start to get too large, you can begin to move code into modules. Similarly, when your modules start to get too large, you can begin to organize your code into separate modules and reference them all in a PowerShell data file. This makes referencing your code in multiple areas much simpler as you only have to reference the one data file.

Integrated Scripting Environment (ISE)

So where do we develop all this PowerShell code? In reality, you can use any text editor at your disposal to write up some PowerShell code. That being said, ISEs generally provide some pretty useful features including, but not limited to, syntax highlighting, multiline editing, selective execution, and code debugging tools. In the screenshot below, you can see how helpful syntax highlighting can be. On the left is PowerShell code as it appears in notepad. The image on the right shows the same code in PowerShell ISE:

PowerShell ISE

Choosing which ISE to use is all about preference. For the sake of this series, I will be using the PowerShell ISE which is included in the majority of Windows operating systems, after Windows 7. There are, however, a plethora of other ISEs which can be used.

Common PowerShell Terminology

Now that you are familiar with the different file types and ISE’s, we can begin to talk about some of the common terminologies you will run across during your PowerShell adventures.


Cmdlets, pronounced “command-lets”, are lightweight commands that can be used in the PowerShell environment which perform defined tasks. These tasks can range anywhere from redirecting output to a file to creating new users (Active Directory/Local). You can even create your own cmdlets to perform administrative tasks unique to your environment. Most cmdlets follow a similar naming standard as seen in the examples below:

  • Get-Content
  • Get-Property
  • Set-Property

As you can see, the cmdlets are named in a Verb-Noun standard. In other words, “What am I doing?” (Get), and “What am I doing it to?” (Content).


Cmdlet names can get pretty long. As such, aliases were introduced as a way to streamline PowerShell use. Instead of having to always type in the longer cmdlet name, users can reference the same functionality using shorthand aliases. Some examples include:

  • Get-Content - gc
  • Get-Property - gp
  • Set-Property - sp
Execution Policy

Execution policies determine the conditions in which PowerShell scripts can run in any given environment. These can be configured at the machine, user, or session level depending on the needs of your organization. Additionally, you can utilize GPOs to enforce these settings across your entire environment. The different policies include:

  • Restricted - Does not allow execution of PowerShell scripts, but does allow use of individual commands.
  • AllSigned - Any script that is signed can execute. Explicitly prevents unsigned scripts from running.
  • RemoteSigned - Prevents unsigned scripts downloaded from the internet from running, however, locally developed scripts can run without signatures
  • Unrestricted - All scripts can run. Warnings are presented when running scripts downloaded from the internet.
  • Bypass - Nothing is blocked and no warnings are presented.

Deciding which policy to use is up to you. Whatever policy you decide to use should reflect the security requirements of your organization. More information on Execution Policies can be found here.

Next Week

That’s it for today, folks! The first couple of installments in this weekly series will focus on getting people introduced to PowerShell. After that, we will begin to dive into more complex ways it can help you manage your environment. Next week, we will go over some cmdlets that you will find extremely useful as you begin to develop your PowerShell scripts and how to go about using them. Stay tuned!

About Automox

Facing growing threats and a rapidly expanding attack surface, understaffed and alert-fatigued organizations need more efficient ways to eliminate their exposure to vulnerabilities. Automox is a modern cyber hygiene platform that closes the aperture of attack by more than 80% with just half the effort of traditional solutions.

Cloud-native and globally available, Automox enforces OS & third-party patch management, security configurations, and custom scripting across Windows, Mac, and Linux from a single intuitive console. IT and SecOps can quickly gain control and share visibility of on-prem, remote and virtual endpoints without the need to deploy costly infrastructure.

Experience modern, cloud-native patch management today with a 15-day free trial of Automox and start recapturing more than half the time you're currently spending on managing your attack surface. Automox dramatically reduces corporate risk while raising operational efficiency to deliver best-in-class security outcomes, faster and with fewer resources.

Dive deeper into this topic