Runspaces made simple

PowerShell is great at simplifying and automating your daily tasks. And it’s only natural that after you have automated or scripted most of your simple tasks, you start creating bigger scripts. If you work in a large environment, running for instance a script that uses WMI to query computers for data can take a long time to complete. The solution? Multi-threading of course. One way of doing this is using the built-in ‘Jobs’ cmdlets, but what this post is about is Runspaces.


Logging made simple

Logging is perhaps not the first thing you think about when making small scripts that is only intended to be used by yourself, but the moment other people are involved, the probability of something going wrong is going up. And making scripts intended for others usually means the size and complexity goes up as well. At some point, you will get tired of feedback from others that are hard to debug, and wish you wrote logging into your script! What if logging was as simple as just adding a bunch of “Write-Log”‘s in your code? I’ll show you how.

Quick tip: Enum with string values

Using enums can come in handy in many situations. When writing an advanced function in PowerShell, using an enum as the parameter type will ensure that only valid values are used, as well as give you tab-complete functionality (The same can be achieved using ValidateSet).

Now, I was working on extending my Mockaroo function when I found myself in a position where I needed to validate a large amount of values for a parameter. I decided on an enum, but I had problem – some of the values where strings with spaces in them, and I was going to use the parameter value when creating a URI for the Mockaroo API, so I’d rather avoid using a huge switch-statement translating the enum values to strings.

Quick tip: Dealing with special characters in Variables and Property names

Ask anyone who have worked with PowerShell for a while, and they will all tell you to try to avoid spaces and special characters in variable names and property names of custom objects or hash tables. Even though it’s possible to use them, there is a reason why it’s not recommended, but unfortunately you might come up in a situation where such things are out of your control, and you just have to deal with it.

In this quick tip I will show you how to handle variable names and property names with spaces and special characters.

A PowerShell implementation of Touch

Touch is a well known command in the Unix/Linux world. It is used to update the time stamp of files, and additionally will create a new empty file if it doesn’t exist already (unless you use the -c parameter, which will suppress this behaviour).

Invoke-Touch is a PowerShell implementation of Touch, and supports all the functionality of the original command. I have added the Unix/Linux parameter names as aliases, so if you are familiar with touch, you shouldn’t have any problems using this function.


Resolve-PathEx is a wrapper around Resolve-Path that adds support for resolving paths for files that don’t exist. Why would you ever want that? Have you ever created a function with a path parameter and a file name parameter, where the function itself would create a new file? With this function you could combine those two parameters into one. The great thing about Resolve-PathEx is that it supports wildcards (the same as Resolve-Path).