Monthly Archive


Monthly Archives: August 2017

PowerShell string concatenation

Strings -  a list of characters such as ‘abcd’ – are a common feature of programming or scripting. Sometimes you need to join – concatenate – two or more strings together. This is how PowerShell string concatenation works.

First you need to know that strings can be defined with single quotes or double quotes:

PS> $sq = 'A single quoted string'
PS> $sq
A single quoted string

PS> $dq = "A double quoted string"
PS> $dq
A double quoted string

The difference is that you can substitute into a double quoted string. Best practice is to use single quotes UNLESS you intend to substitute into the string

PS> 'I am $sq'
I am $sq
PS> "I am $sq"
I am A single quoted string

String concatenation can be performed using the concatenation operator – a plus sign or through string substitution

PS> $s1 = 'abcd' + 'defg'
PS> $s1

You can use variables

PS> $s1 = 'abcd'
PS> $s2 = 'defg'
PS> $s3 =  $s1 + $s2
PS> $s3

When you concatenate strings like this you’re actually creating a new string not extending an existing one.

Alternatively, use string substitution

PS> $s4 = "$s1$s2"
PS> $s4

PowerShell operators

PowerShell has operators – lots of operators. So many operators that it took us TWO chapters to work through them all in PowerShell in Action, third edition - Here’s how you can discover the PowerShell operators.

PS> Get-Help about*operator*


A quick listing gives us:

Arithmetic operators (+, -, *, /, %)

Assignment operators (=, +=, -=, *=, /=, %=)

Comparison operators (-eq, -ne, -gt, -lt, -le, -ge)  (-match, -notmatch) (-like, -notlike)

(-in, -notin, -contains,  -notcontains) (-bAND, -bOR, -bXOR, -bNOT)

Logical opertors (-and, -or, -xor, -not, !)

Redirection operators (>, >>, 2>, 2>, and 2>&1)

Type operators (-is, -isnot, -as)

And a  bunch of special operators @(), & (call), [] (cast),  comma, dot, –f , index opertor, pipeline operator, range operator, :: static member operator, $()

Also don’t forget –split, –join, –replace

Comparing AD group membership on EmployeeId

Back in this post - I showed how to compare the membership of two groups using Compare-Object. The comparison was based on the samAccountName. A question raised the issue of comparing AD group membership on EmployeeId

In the case in particular users have multiple accounts BUT the EmployeeId is correct on all and will therefore show matching users. Assuming the EmployeeId is correct on all accounts it still leaves a problem.

When you run Get-ADGroupMember you get a very limited number of properties returned:

PS>  Get-ADGroupMember -Identity Testgroup1

distinguishedName : CN=JONES James,OU=UserAccounts,DC=Manticore,DC=org 
 name              : JONES James 
objectClass       : user 
objectGUID        : 027cb406-a3b0-4f45-9bbd-db47ccfb9212 
 SamAccountName    : JamesJones 
 SID               : S-1-5-21-759617655-3516038109-1479587680-1225

First thing I needed to do was set up some users with an EmployeeId

$ei = 1 
 Get-ADUser -Filter {Name -like "*Jones*"} -Properties EmployeeId | 
foreach { 
  $id =  23945 + $ei 
  $psitem | Set-ADUser -EmployeeID $id

  $ei = $ei + (Get-Random -Minimum 3 -Maximum 12) 

Get a set of users – including the EmployeeId – and forech of them set the id. The id is randomly generated based on a starting value and increment.

Now that the users have an Employeeid you can use that for comparison purposes

$group1 = Get-ADGroupMember -Identity Testgroup1 | 
foreach { 
  Get-ADUser -Identity $psitem.distinguishedName -Properties EmployeeId | 
  select -ExpandProperty EmployeeId 

$group2 = Get-ADGroupMember -Identity Testgroup2 | 
foreach { 
  Get-ADUser -Identity $psitem.distinguishedName -Properties EmployeeId | 
  select -ExpandProperty EmployeeId 

 Compare-Object -ReferenceObject $group1 -DifferenceObject $group2 -IncludeEqual |             
 where SideIndicator -eq "==" |            
foreach {            
  $id = ($_.InputObject)        
  Get-ADUser -Filter {EmployeeId -eq $id} -Properties EmployeeId            

Get the membership of the first group and for each member use Get-ADUser to return the EmployeeId. Repeat for the second group.

Use  Compare-Object to compare the two sets of group members – you’re looking for matches indicated by “==”

Foreach match get the AD user account filtering on the EmployeeID.

The PROBLEM with this approach is that you’ll get all user accounts returned that have the particular EmployeeId.   You can replace the line

Get-ADUser -Filter {EmployeeId -eq $id} -Properties EmployeeId


Get-ADUser -Filter {EmployeeId -eq $id} -Properties EmployeeId, MemberOf | where {$_.MemberOf -like "*Testgroup1*" -AND $_.MemberOf -like  "*Testgroup2*"}

Which should resolve the problem

PowerShell substrings

PowerShell is all about working with objects but you often have to drop to a lower level and work with properties and their values. Many objects have properties that are strings – a string is one of the standard PowerShell literals – and sometimes you want to extract part of a string – a substring. This post shows how PowerShell substrings work.

First thing to note is that PowerShell doesn’t have a substring command or keyword. A string in PowerShell is an instance of the System.String class and so you use the Substring method of the String class.

You have 2 options – technically known as overloads. You can view a methods overloads by using the method name without brackets

PS> 'abcdefghijklmnopqrstuvwxyz'.Substring

string Substring(int startIndex)
string Substring(int startIndex, int length)

In the first case you give a starting index into the string and the substring starts at that point and takes everything to the end of the string:

PS> 0..25 | foreach {'abcdefghijklmnopqrstuvwxyz'.Substring($psitem)}

Remember that in .NET indices start at 0 so the string is 26 characters long with indices 0-25

If you supply an index that would be beyond the end of the string:

PS> 'abcdefghijklmnopqrstuvwxyz'.Substring(26)

PS> 'abcdefghijklmnopqrstuvwxyz'.Substring(30)
Exception calling "Substring" with "1" argument(s): "startIndex cannot be larger than length of string.
Parameter name: startIndex"
At line:1 char:1
+ 'abcdefghijklmnopqrstuvwxyz'.Substring(30)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentOutOfRangeException

In the first case you get nothing back because the string is 26 characters long. Anything larger than that and you get an error.

The second overload of substring involves supplying a starting index and the number of characters you want to take (including the starting character):

PS> 0..25 | foreach {'abcdefghijklmnopqrstuvwxyz'.Substring($psitem, 3)}
Exception calling "Substring" with "2" argument(s): "Index and length must refer to a location within the string.
Parameter name: length"
At line:1 char:18
+ 0..25 | foreach {'abcdefghijklmnopqrstuvwxyz'.Substring($psitem, 3)}
+                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentOutOfRangeException

Exception calling "Substring" with "2" argument(s): "Index and length must refer to a location within the string.
Parameter name: length"
At line:1 char:18
+ 0..25 | foreach {'abcdefghijklmnopqrstuvwxyz'.Substring($psitem, 3)}
+                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentOutOfRangeException

Notice the error when you would go beyond the end of the string

PowerShell substrings depend on using the SubString method of the System.String class. The examples here will help you decide which overload to use.

Further information on PowerShell 2.0 deprecation

The PowerShell team have provided further information about the deprecation of PowerShell 2.0

One point that didn’t come out is that if you remove PowerShell 2.0 your CIM sessions can all run over WS-MAN. DCOM isn’t required any more - YAY

PowerShell pause

PowerShell pause – how can you pause a PowerShell script?

Two ways come to mind.

First if you just want the script to pause for a specified time period then you can use Start-Sleep

1..10 |
foreach {
  if ($PSItem -eq 5) {
    Write-Warning -Message "Starting sleep"
    Start-Sleep -Seconds 5

Run this and you’ll see the numbers 1-5 output then then warning message. After the delay you’ll see the numbers 6-10 output.

But what if you want to control the pause manually? Not sure if there are advantages to this approach but if you do need to do this you can use Read-Host

1..10 |
foreach {
  if ($PSItem -eq 5) {
    Read-Host -Prompt "Press Enter key to continue"

You’ll see the numbers 1-5 output then the message

Press Enter key to continue:

After pressing the enter key the script continues and outputs 6-10

Don’t know why you’d want to do this in an automation scenario but the technique is there if you need it – I don’t recommend the approach.

There are also a few cmdlets that can be used under specific circumstances:


Also check the –wait parameter on Restart-Computer

PowerShell 2.0 to be deprecated in Windows 10

You’ve been able to install the PowerShell 2.0 engine side by side with the latest version of PowerShell for the last few versions of PowerShell. Not any more. PowerShell 2.0 to be deprecated in Windows 10 Fall Creators update later this year.

Presumably this will also apply to Windows Server 2016 which is also moving to a twice yearly update

PowerShell for loop

Loops are a construction seen in most scripting and programming languages. A loop is used to repeat a set of statements a set number of times or until a specific criterion is met or while a specific criterion is true. In this post I’ll describe the PowerShell for loop.

For loops are found in many languages. A for loop is sometimes referred to as a counting loop as it will have a counter that starts at a pre-set value and counts up to a specific value. The counter is usually incremented by 1 for each iteration of the loop.

A PowerShell for loop looks like this

for ($i=1; $i -le 10; $i++){$i}

The counter – $i – is initialised to 1. The loop will execute while $i is less than or equal to 10 and $i is incremented by 1 for each turn round the loop. In this case the loop lists the value of the counter.  You can see the results like this

PS> $results = for ($i=1; $i -le 10; $i++){$i}
PS> "$results"
1 2 3 4 5 6 7 8 9 10

You can also run loops where the counter decreases

PS> $results = for ($i=10; $i -ge 1; $i--){$i}
PS> "$results"
10 9 8 7 6 5 4 3 2 1

A for loop is great when you need to perform the loop and exact number of times but if your loop depends on a specific criterion you’re better off using a while loop or a do loop which I’ll cover in another post

Create a directory

PowerShell enables you to work with the file system on your machine – one question that often comes up is how to create a directory.

When working interactively you can use md

PS> md c:\testf1

    Directory: C:\

 Mode                LastWriteTime         Length Name 
 ----                -------------         ------ ---- 
 d-----       19/08/2017     14:24                testf1

md doesn’t look like a PowerShell command – more like an old style DOS command.

Its actually an alias for mkdir

PS> Get-Command md

CommandType     Name                                               Version    Source 
 -----------     ----                                               -------    ------ 
 Alias           md –> mkdir

Which raises the question – what’s mkdir?

PS> Get-Command mkdir

CommandType     Name                                               Version    Source 
 -----------     ----                                               -------    ------ 
 Function        mkdir

Its a function that PowerShell creates for you

Digging into the function

PS> Get-ChildItem -Path function:\mkdir | select  -ExpandProperty  Definition


    [Parameter(ParameterSetName='nameSet', Position=0, ValueFromPipelineByPropertyName=$true)] 
    [Parameter(ParameterSetName='pathSet', Mandatory=$true, Position=0, ValueFromPipelineByPropertyName=$true)] 

    [Parameter(ParameterSetName='nameSet', Mandatory=$true, ValueFromPipelineByPropertyName=$true)] 

    [Parameter(ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)] 



begin {

    try { 
        $wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('New-Item', [System.Management.Automation.CommandTypes] 
        $scriptCmd = {& $wrappedCmd -Type Directory @PSBoundParameters } 
        $steppablePipeline = $scriptCmd.GetSteppablePipeline() 
    } catch { 


shows that its based on New-Item

PS> New-Item -Path c:\ -Name testf2 -ItemType Directory

    Directory: C:\

 Mode                LastWriteTime         Length Name 
 ----                -------------         ------ ---- 
 d-----       19/08/2017     14:32                testf2

The default for New-Item in the filesystem is to create a file so you need to use –ItemType Directory to create the folder.

If the folder you’re creating is a subfolder of a non-existent folder you can create the hierarchy is one go

PS> New-Item -Path c:\ -Name testf3\tests1 -ItemType Directory

    Directory: C:\testf3

 Mode                LastWriteTime         Length Name 
 ----                -------------         ------ ---- 
 d-----       19/08/2017     14:33                tests1

 PS> Get-ChildItem -Path c:\testf3 -Recurse

    Directory: C:\testf3

 Mode                LastWriteTime         Length Name 
 ----                -------------         ------ ---- 
 d-----       19/08/2017     14:33                tests1

This can get complicated if you try to nest too many levels so I recommend explicitly creating each level of your folder hierarchy. Its much easier to maintain and modify

PowerShell foreach

PowerShell has a number of ways to perform a loop – I recently counted seven distinct methods. If you can’t list them all don’t worry one is very esoteric and unexpected. I’ll enumerate them in a future post. For now I want to concentrate on a source of confusion – especially to newcomers to PowerShell – namely the PowerShell foreach statements.

The confusion arises because there are effectively two foreach statements. One is a PowerShell keyword that initiates a loop and the other is an alias for  a cmdlet.

Lets start with the foreach loop.

$numbers = 1..10
foreach ($number in $numbers){
  [math]::Pow($number, 2)

foreach in this case is used to iterate over a collection. In the example above $numbers is an array of numbers 1 to 10. Foreach number in the array it is raised to the power 2 – squared.

Remember that PowerShell is unique among shells in that you can use pipelines in many places that other languages insist on variables so you could change the example to

foreach ($number in 1..10){
  [math]::Pow($number, 2)

The array is generated and then iterated over as earlier.

If you see foreach as the first command on a line you’re dealing with the foreach keyword and therefore a loop.

On the other hand if you see foreach in a pipeline

1..10 | foreach {
  [math]::Pow($_, 2)


1..10 | foreach {
  [math]::Pow($psitem, 2)

you’re dealing with the cmdlet. $_ or $psitem denote the object currently on the pipeline. foreach is an alias for the Foreach-Object cmdlet and you’re using –Process as a position parameter for the scriptblock. Written in full you’re doing this

1..10 | ForEach-Object -process {
  [math]::Pow($_, 2)


1..10 | ForEach-Object -process {
  [math]::Pow($psitem, 2)

Just to add to the confusion you also have the option to use the foreach method on the collection

(1..10).foreach({[math]::Pow($psitem, 2)})

This isn’t seen as much though it should be remembered as this is the fastest way to iterate over a collection.

In summary

foreach starting a line is the looping keyword. Faster than the pipeline but increases memory overheads as  the collection has to pre-generated

foreach on the pipeline is an alias for foreach-object. Lower memory requirements as the collection is passed down the pipeline but a bit slower

().foreach({}) is a method on the collection (we treat it as an operator in PowerShell in Action) and is fast but in terms of coding style may be more intuitive to developers than admins.