Making your (Powershell) job work for you

Jobs are a in many ways the key to Powershell multithreading. Having jobs running in the background not only allows you to keep working in your console while your script is silently churning away in the background, but it also lets you run multiple commands or scripts simultaneously executed from console.

When to use jobs

Whenever you’d like to run a command or a scriptblock without locking up your console, or when you’d like to run multiple commands simultaneously. Jobs are “fire and forget” tasks that you don’t review until they’ve completed or failed.

When not to use jobs

When running basic administration tasks where you’re reviewing output or the result of command continuously, or when working with result sets in variables where you’d like to keep reviewing the current value of the variable.

Ways to use jobs

There are two ways of using jobs in Powershell. First of all, many cmdlets have the parameter “-AsJob” to allow them run in the background directly. Alternatively you can use the cmdlet Start-Job to initiate a job with any cmdlet of combination of commands.


Some cmdlets that has the -AsJob parameter are:

If you like to find a more complete list, use the following command.

NB. Keep in mind that you need to load the modules your looking for commands in, in advance. Module autoloading doesn’t work when looking for parameters (Tested with Powershell 5.0 in Windows 10 Technical Preview)


There are 4 cmdlets that are key to using Powershell jobs:


Starts a background job to execute one or more Powershell commands.


Collects and lists the running and completed jobs currently in memory


Presents the result of a job to screen, or otherwise lets you collect or manipulate the result


Removes one or more jobs from memory

 Other useful cmdlets:

Suspend-Job: Pauses a job.
Resume-Job: Resumes a paused job.
Stop-Job: Stops a job.
Wait-Job: Suspends the command prompt until a job is finished, preventing you from making the input.

SQL non-system database backup using Powershell

Traditionally most People have been automating database backups in Microsoft SQL server using TransactSQL, and then using osql to execute the code through Windows Task Scheduler. With the advent of MSSQL 2012, using Powershell to automate SQL related taks has suddenly become a lot easier.

This script selects only user databases though, ignoring system databases and leaves you with only what should be important to you.

As a part of a migration at a client, I was given the task of creating an efficient backup strategy with minimal effort. Using TransactSQL would definitely solve the task, but for future reference, I always try to use Powershell when applicable.

So how does the script work? Well, first we collect paths and dates necessary to perform the backup and name the file for the backup set. The backup file is tagged with the week number and the script is meant to create a backup set every week.

Next we create two Functions. The first creates a full backup, the second will add incremental backups to the backup set file created by the first function. I.e., the second will be pointless if the first has not run.

Last, we choose which of the previously created functions to run. This is also where you choose when to create the full backup set. Simply change the weekday in the script. Mind your spelling though, it needs to be accurate.

So this is all nice and dandy. It’ll keep churning out backup sets every week, filling up your storage SAN, local hard drive, cloud storage or what ever storage you choose to add the backup set to. So what can we do to clean it up?

Well, keep in mind that all backup sets are tagged with the week number in the file name. This makes it easy to choose which backup set to restore, but it also makes it easy to choose which to delete. Simply {$CurrentWeek – 2}. Here a script that does exactly that:

Please feel free to leave your comments if you have and questions regarding this solution, and I’d love to hear from anyone who uses this fully or partially 🙂

Powershell Port Scanner

Would you like to know what ports are open on a host? With the introduction of Powershell 4.0 there’s a new cmdlet called Test-Netconnection which in it’s simples form basically is ping. It does, however, have some more advanced features, like scanning towards ports on a host.

Here’s a quick and dirty script to scan a single host for single port, or a sequential range of ports.

I have to admit that I miss the -Source switch in “Test-Connection” that allows you to choose where the connection request should originate, but perhaps we’ll see that in Powershell/WMF 5.0?

Working around number ranges limited to 32 bit integers

I head a real brain teaser when working a script earlier today. Basically I was modifying a script which lists out unused phone numbers in a range. It turns out German phone numbers (and any number greater than 2147483647) are incompatible with number ranges. Here’s why, and how to solve it.

When using number ranges, you are limited to signed 32 bit integers (-2147483646 to +2147483647). This is rarely an issue, but when working with untypical numbers, like unformatted phone numbers or the byte value of very large files, it can pose a problem.

This is an example of a range that will work:

This however, won’t work:

The high number is above the max value for a signed 32 bit integer.

Solving required a bit of a hack. To work around this limitation, use a While loop to create an array with the number series you’d like to feed into to your variable. Below is an example:

$Counter is initially set to be the starting number of your range. It will be the control parameter that the While loop uses to check if it’s done working.
$NumberStart is the starting (low) number in you range.
$NumberEnd is the end (high) number in you range
$Array is your range (or it’s equivalent). It gets fed each value from $NumberStart to $NumberEnd. This array will hold 64 bit integers.


Autodeploy one or more servers without System Center

I use this script to deploy one or more identical servers in Hyper-V. The script handles both the use of a Golden Image template .VHDX file, or a clean installation using an ISO install image and will provide you with a question by question gathering of the most common installation parameters.


  • Windows Server 2012 release candidate or above
  • Powershell 3.0
  • Hyper-V role installed on the server
  • Hyper-V Powershell module installed on the server
  • A template VHDX file for each operating system you’d like to be able to deploy
  • ISO-files for each operating system you’d like to be able to deploy

Powershell: Share size reporting

A security admin came to me the other day and asked me if I could measure the size of each individual share on the system. I asked him if this wasn’t something most easily done by using Explorer, but since he wanted every single share on all file servers, it would a lot of “right click->Properties”, so I took pitty on him and got to work 😉

I created a script where you’re asked the name of the file server. The script then lists out the shares and writes out their individual size to a text file.

Here’s the script:

This script takes a long time to complete in large environments. If anyone has tips on how to streamline the code for better performance, please add a comment 🙂

Automating best pratice for security groups in Active Directory

In order to maintain best practices in a multi domain forest, we occasionally have to create file and application access groups to secure sensitive resources we manage. Creating a 3 groups to do this is a lot of hassle, but it needs to be done, however you don’t need to do it manually.

I created a script to take care of this day to day task for me. The script basically does 3 thing:

  1. It checks if a security group with that name already exists and if so it aborts.
  2. It creates 3 security groups: a “Domain Local” group for rights assignment, a “Global” group to put my users in, and a “Universal” group to link the Global and Domain Local groups, as well as to link groups from other domains in our forest.
  3. It asks the user what folder to add rights to and what rights to add (Read, Write and/or Modify) and then sets those rights on the appropriate folder.

The script uses Quest Active Roles AD Management snapin for Powershell (available here)

I’ve added logging using the transcript functionality, and if you check out line 19 and 114 you see that I’m starting and stopping logging to a specific file using the “Start-Transcript” and “Stop-Transcript” cmdlets. This means that the script will throw and error in ISE since it doesn’t support transcripting, but running it in a normal powershell windows will ensure that everything happing between line 15 to 113 get’s logged!

Without further ado, heres the script:


I still consider myself a novice at Powershell, however and advanced one at that, and I’d love to get feedback on better approaches to my scripting, both in the sense of optimizing the script for performance, and simplifying the script itself. I’d also be happy to answer any questions regarding the script 🙂