Monthly Archive


Monthly Archives: February 2019

PowerShell interviews

Following my last post about sample questions for PowerShell interviews that I’d stumbled across I’ve been asked what sort of questions I’d ask – given my statement that many of the question sets were out of date.


I’ve thought about it and decided I’ll run an occasional series of questions and the information I’d expect.


Before I start that I’ve thought some more around the whole issue of PowerShell interviews and there are some things to think about before jumping into performing an interview.


The most important thing is what are you interviewing for. What exactly does the role entail? There are a number of possibilities:


You want a PowerShell developer – the person will spend all of their time writing and maintaining code. Requirements and and specifications will be given to them. for this sort of role you’ll need to be mixing developer technique questions in with the powershelll questions.


You want someone to automate your administrative processes. Again development techniques ae going to feature alongside PowerShell questions. Ideally, you’d also want some one who would question the processes because automating what you have now is necessarily the best thing. I can remember being asked to generate a report about some products when I worked for a financial services organisation. Easy enough to do. I then asked 1 question – what was the report used for. It turned out that the data on the report was keyed into another system. The job then became extract data from system a and feed into system b and produce a report of what happened. That single question saved the users a bunch of time, effort and reduced errors from the re-keying of data.


You want an administrator who can also automate the administration of some or all of your environment. At this point you’re looking for someone who can administer X (or a bunch of Xs) and write PowerShell code that’ll make that job easier. You need to ensure that the person actually understand the system[s] as well as PowerShell.


Once you know the sort of person you want its time to think about the questions to ask. I’m going to assume that any other questions and just concentrate on questions about PowerShell from a theoretical and practical perspective. If you can sit the candidate down and make them write some code for you – but we’ll get to that another time.

PowerShell interview questions

For some bizarre reason I ended up looking at various sets of PowerShell interview questions and answers.


For the most part they scared me – due to their outdated nature.


Many, if not most, of the question sets hadn’t been brought up to date for PowerShell v5.1 and very few even mentioned v6.x. The remoting and CIM answers were often misleading.


And that’s just what I picked up on a quick scan through.


Bottom line is that if you need to prepare for an interview and you’re going to get PowerShell questions then make sure that you actually know the subject and don’t rely on dubious online sources.

Execution policy

PowerShell gives you a number of options regarding execution policy. You use one of the following options with Set-Execution policy:

Restricted – won’t run scripts or profiles. This is the default execution policy

Allsigned – only scripts (and profiles) signed with a trusted certificate can run. This includes anything you create on local machine.

RemoteSigned – Scripts (and profiles) on local drives will run. Scripts downloaded from Internet or from network drives are blocked

Unrestricted – anything runs though you are prompted before a downloaded unsigned script is run. This setting is what’s generally called a bad idea as its too permissive.

Bypass – everything runs without warnings or prompts. In most cases a worse idea than unrestricted

Undefined – removes currently assigned execution policy from the current scope though it won’t work if policy set by GPO


Just to add to the fun you have to think about the scope as well:

Process – only the current PowerShell process

CurrentUser –only the current user

LocalMachine – all users on the computer. This is the default setting.


I normally use RemoteSigned as it offers the best choice between ease of use and security. For an organisation that makes extensive use of PowerShell I’d recommend Allsigned with the code signing certificate only available to a small number of users who were responsible for performing quality assurance checks on the code.

Processing files with switch

The switch statement has a –file parameter that can be used to give the path to a file. The file is read one line at a time and processed through the switch statement. The example from last time can be used to demonstrate processing files with switch.


$fnum = 1

switch -file C:\test\Data.txt {
{$_ -like 'HOST*'} {
$file = "C:\test\outdata{0:00}.txt" -f $fnum
$fnum ++
Add-Content -Path $file -Value $_
default {Add-Content -Path $file -Value $_}


Initialize the counter as before. Use switch with the –file parameter to read the file. If the line is like HOST* then its the start of a block so create a new file name, increment the counter and add the content to the file.


Otherwise use the switch’s default option just to write the content to the file. If the data is more complicated then introduce additional processing options and allow default to just write out the data to the file.


This option on switch isn’t used much from what I’ve seen but is worth considering as it can offer some performance gains over other approaches.

Splitting a file

Saw a question about splitting a file that had repeating data blocks.

Each block starts with HOST so the code to split becomes:

$fnum = 1

Get-Content -Path C:\test\Data.txt |
ForEach-Object -Process {
if ($_ -like 'HOST*') {
$file = "C:\test\outdata{0:00}.txt" -f $fnum
$fnum ++

Add-Content -Path $file -Value $_


Initialise a counter variable $fnum


Get the file content and for each line test if it starts with HOST. If so create a new file name by using the format operator to substitute $fnum into the file path. {0:00} means put $fnum into the filed and ensure that its 2 digits so outdata01.txt instead of outdata1.txt. Increment $fnum


Write the line to the file.

PowerShell operators

PowerShell has operators – lots of operators. This is a quick overview of the PowerShell Operators.

The obvious place to start is the arithmetic operators - see about_Arithmetic_Operators

+, –, *, / perform the four arithmetic operations

% is for modular arithmetic – get the remainder after division

-shl and –shr perform shift left and right operations for bitwise operations


Assignment operators are used to assign a value to a variable – see about_Assignment_Operators

= is the basic assignment

+=, –=, *=, /= and %= perform the appropriate arithmetic operation and assign the result

++, -- increment and decrement a value respectively


Comparison operators are heavily used in branching and testing logic – see about_Comparison_Operators

-eq, ne equals and not equals

-gt, -ge, –lt, –le greater or lesser comparisons

-like, –notlike – wildcard comparisons

-match, notmatch – regular expression (shudder) comparisons

-contains, –notcontains, –in, –notin tests array membership

-replace – replace part of a string with another


By default comparison operators are case insensitive. To get a case sensitive operation give the operator a c prefix - -ceq rather than –eq. Likewise an i prefix states explicitly that you want a case insensitive comparison.


Logical operators – see about_Logical_Operators

-and, –or

-xor logical exclusive or

-not (also written as !) – negates following statement

-band, –bor, bxor, –bnot for working with binary


Type operators for testing or converting types – see about_Type_Operators

-is, –isnot – test a type

-as converts to the type


The help file about_operators covers a surprising set of operators – some you may not consider.

You should spend some time reading the operator help files so you get the best out of the many, many PowerShell operators

Summing multiples

Came across the project Euler web site – It has literally hundreds of problems – mainly mathematical – that’ll illustrate some useful PowerShell techniques. The first problem is summing multiples.


You need to sum all of the multiples of 3 or 5 below 1000.


The first thing to do is to read the problem very carefully. Using the supplied example of multiples of 3 or 5 below 10 you don’t include 1000 in the solution. Its less than not less than or equal to.


The PowerShell solution is one pipeline:

1..999 |
Where-Object {($_ % 3) -eq 0 -OR ($_ % 5) -eq 0} |
Measure-Object –sum


Use the range operator to put the numbers 1 to 999 on to the pipeline. Use Where-Object to filter for multiples of 3 or 5. The filter consists of performing modulo arithmetic of the number and accepting those numbers where the result is zero i.e. a multiple of 3 or a multiple of 5


You don’t need to worry about numbers that are multiples of 3 AND 5 as the –OR in the Where-Object passes the number when the first test is passed.


The sum is calculated using Measure-Object.

The source of PowerShell cmdlets

The source of PowerShell cmdlets seems to cause a lot of confusion.

The first point is that the PowerShell team, and now the open source project, are only responsible for the PowerShell engine and the core modules – basically most of what you’ll find in C:\Program Files\PowerShell\6\Modules\



You’ll also find



But they aren’t classed as part of the core engine.


ALL other PowerShell functionality comes from one of these sources:

- Modules created by other Microsoft teams and shipped as part of Windows 10 or Windows Server

- Modules installed when a Windows feature is installed – again created by the appropriate team

- Modules installed when the Remote Server Admin Tools (RSAT) are installed (can overlap with the preceding group)

- Modules available when an application is installed e.g. Exchange or SQL server

- Modules available from the PowerShell Gallery e.g. Pester

-Modules available from third parties


The only area the PowerShell team control is the core group of modules mentioned at the beginning. For problems with anything else you should raise the issue with the appropriate team or vendor rather than the PowerShell project.

PowerShell v6.1.3 install problem

PowerShell v6.1.3 install problem prevented my from changing the working directory.


The introduction of the –WorkingDirectory parameter pwsh.exe has caused problems – usually forcing PowerShell to ignore any directives in your profile to set a working folder.


In previous versions this was overcome by changing the –WorkingDirectory parameter on the icon. This only worked if I started pwsh.exe as Administrator.


I had to uninstall PowerShell v6.1.3 (I done an install over the top of v6.1.2) and then reinstall and then set the –WorkingDirectory parameter.


Not the best of experiences.


PowerShell v6.2 preview 4 had a better install experience – hopefully the issues from v6.1.3 won’t be copied forward. Between the –WorkingDirectory issue and the issue where an over the top install causes PowerShell to open and immediately close so you have to re-install the recent releases have been less than stellar as far as install and configuration have gone.

PowerShell v6.1.3

PowerShell v6.1.3 has been released -

It primarily fixes the security issues from



which are to do with User Mode Code Integrity policy bypasses




which is to do with domain spoofing


I expect the fixes to appear in the next release of v6.2 preview