Saturday, December 15, 2018

Calling a PowerShell Function like a Method is a Bad Idea

As a frequent contributor to Spiceworks’s PowerShell forum (come visit at:, from time to time I see a post that contains bad practice and sometimes worse.  One thing I see more often than I’d like, is post that calls a PowerShell function like a .NET method. This is, as the subject to this article suggests, is a very bad idea. Let me explain why.

First, let’s create a really simple function Add, like this:

Function ADD {
   Param ($A, $B)
   $A + $B

This function just adds two values and returns the results. Now, go and use the function both as a proper function call, then as a method call:

Psh[C:\foo]> Add 1 2

Psh[C:\foo]> Add(1,2)

As Iyou can see, the two uses of the Add function return decidedly different results. But why? At first sight, it appears quite illogical. To work out what is going on, under the covers,  create a richer Add function that describes what is being passed to and from the function, like this:

Function WhatAdd {
   Param ($A, $B)
   # Set to avoid error if GetType fails
   $ErrorActionPreference = 'SilentlyContinue'
   # Display the type and value of the first parameter
   "A is type   : [$($A.GetType())]"
   "A has value : [$A]"
   # Display the type and value of the second parameter
   "B is type   : [$($B.GetType())]"
   "B has value : [$B]"
   # Now calculate and describe the sum:
   $Result = $A + $B
   "Result has type  : [$($Result.GetType())]"
   "Result has value : [$Result]"
   # Return the result
   Return $Result

This function performs the same calculations and returns a results. It also displays the type and value of each input parameter and the result.  First try it out with calling a function like a cmdlet:

Psh[Cookham24:C:\foo]> WhatAdd 1 2
A is type   : [int]
A has value : [1]
B is type   : [int]
B has value : [2]
Result has type  : [int]
Result has value : [3]

Next, try calling Add like a method:

Psh[Cookham24:C:\foo]> WhatAdd(1,2)
A is type   : [System.Object[]]
A has value : [1 2]
B is type   : []
B has value : []
Result has type  : [System.Object[]]
Result has value : [1 2 ]

As you can see, the results of calling a function like a method are not what you might have expected.  What is happening is that when you call the Add function like a method, PowerShell assumes that the stuff inside the parentheses is an array of values that is passed to the first parameter of the function, not two separate parameter values. This means PowerShell passes an untyped array of two numbers as the value of the first parameter, and Null as the value of the second. The result of Adding Null to an array of values is an just an array of values (the input values) and not the addition of anything.

Of course, had you indicated in the function’s parameter block of the exact type of the parameters, PowerShell would have indicated the mismatch (passing an array into an parameter with a type of Int.

So two best practices in a single article.

  • First, avoid calling functions like a method. The results can be very much not what you were expecting or wanting.  As a user of someone else’s function, you don;t know how well, or badly they wrote it. Just call a function like a cmdlet.
  • Second, if you are writing functions, assume ALL user input is evil until you prove other wise and that your user will pass you data you were not expecting (like an array not a single integer). At a minimum, ensure that ALL parameters in your functions are explicitly typed. And consider ensuring that what you return is properly typed.  It all cuts down on bad input ruining your day.

Saturday, October 27, 2018

There's always a way...

I teach my classes that there's always more than one way to do almost anything. This week was a nice reminder of how true that is.

The client had a legacy script that scans their client's AD attached computers. One small thing this script does is to determine the Domain Functional Level and whether the domain is still in mixed mode.

The 'old' script we were looking at was a very long, comment-free VBS script using LDAP to get the Domain Object in the AD to get the values for those two attributes to determine the domain level. You might think you could convert that horrid VB code into a simple Get-ADDomain, pick out the two properties.

Sadly, that does not work. The Get-ADDomain cmdlet returns a number of properties that represent the attribute values inside the AD.  But not all!

Here is a screenshot of LDP.EXE showing the domain object and two properties inside my AD:

As you can see, the domain object has two attributes/properties (msDS-Behavior-Version and ntMixedDomain. But Get-ADDomain does not return those properties, as you can see here:

The solution, however, is pretty easy. Get-ADDomain returns an object with the Distinguished Name of the domainDNS object. That object represents the domain inside the AD and it is that object which has the needed properties. So, use Get-ADDomain to get the Domain object's Distinguished Name (DN), then use Get-ADObject to get the object whose identity is that DN. It looks like this:

An interesting thing is that some AD objects, like the domainDNS object, have attribute names that contain a hyphen, eg the msDS-Behavior-Version attribute. This can confuse PowersShell's parser. So the solution is to enclose the property names in braces, as you can see in the final line of the snippet above. An obscure feature of PowerShell that in this case is useful.

All in all, I'd like to think Jimmy Andersen would be impressed. Well, a bit anyway!

Thursday, October 04, 2018

Installing RSAT tools

I've been installing 1803 (and for reasons I can not explain, 1709)  on a bunch of workstations - but needed the RSAT tools. I HATE having to use the GUI - so here's a PowerShell script:

# Install-RSATTools.PS1 # Thomas Lee - # 1. Get Windows Client Version and Hardware platform $Key = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' $CliVer = (Get-ItemProperty -Path $Key).ReleaseId $Platform = $ENV:PROCESSOR_ARCHITECTURE "Windows Client Version : $CliVer" "Hardware Platform : $Platform" # 2. Create URL for download file # NB: only works with 1709 and 1803. $LP1 = ''+ '1D8B5022-5477-4B9A-8104-6A71FF9D98AB/' $Lp180364 = 'WindowsTH-RSAT_WS_1803-x64.msu' $Lp170964 = 'WindowsTH-RSAT_WS_1709-x64.msu' $Lp180332 = 'WindowsTH-RSAT_WS_1803-x86.msu' $Lp170932 = 'WindowsTH-RSAT_WS_1709-x86.msu' If ($CliVer -eq 1803 -and $Platform -eq 'AMD64') { $DLPath = $Lp1 + $lp180364} ELSEIf ($CliVer -eq 1709 -and $Platform -eq 'AMD64') { $DLPath = $Lp1 + $lp170964} ElseIf ($CliVer -eq 1803 -and $Platform -eq 'X86') { $DLPath = $Lp1 + $lp180332} ElseIf ($CliVer -eq 1709 -and $platform -eq 'x86') { $DLPath = $Lp1 + $lp170932} Else {"Version $cliver - unknown"; return} # 3. Display the download details "RSAT MSU file to be downloaded:" $DLPath # 4. Use BITS to download the file $DLFile = 'C:\foo\Rsat.msu' Start-BitsTransfer -Source $DLPath -Destination $DLFile # 5. Check Authenticode signature $Authenticatefile = Get-AuthenticodeSignature $DLFile If ($Authenticatefile.status -NE "Valid") {'File downloaded fails Authenticode check'} Else {'Downloaded file passes Authenticode check'} # 6. Install the RSAT tools $WusaArguments = $DLFile + " /quiet" 'Installing RSAT for Windows 10 - Please Wait...' $Path = 'C:\Windows\System32\wusa.exe' Start-Process -FilePath $Path -ArgumentList $WusaArguments -Wait # 7. Get RSAT Modules Get-Module -Listavailable | Where-Object Name -like '*rsat*'

Friday, August 03, 2018

PSReadline V2 Can Break PowerShell Profile Scripts in Latest Insider's RS5 Preview

The Windows Insider programme provides access to the latest pre-release versions of Windows 10 and Windows Server 2019. Earlier this week, Microsoft released a new preview of what is coming with Windows 10 RS5. This build, 17728.1000, contains an updated version of the module PSReadLine. PowerShell uses this module to enable you to, inter alia, set the colours of tokens in the PowerShell command console.

I love this feature, as it allows me to override the default colours that PowerShell uses. One particular issue for me is that the colours can look less good when displaying on some of the lower quality projectors I get stuck with!  One example - the parameter name token is set, by default, to gray. Displaying from my laptop, this has been hard to see at some sites. So I just added this line to my profile:
Set-PSReadlineOption -TokenKind Parameter -ForegroundColor Cyan
Simple and this is highly useful for me ainsome places I teach. However, with the latest release of the RS5 preview, Microsoft has  now included an updated version of PSReadline (2.0 vs 1.2). Taking the new version was done to enable a fix to an accessibility issue. If you run PowerShell after the upgrade, you might see this error when you run PowerShell:

This is both a breaking change and one not described in the release notes. And, if you use Bing or Google to search for Set-PSReadLine, the page at shows the old version of the cmdlet - you need to dive into the actual PSReadLine repository (ie the modules 'source' code!) to discover the answer.

The solution is simple - change that line to:
Set-PSReadLineOption -Colors @{"parameter" = [ConsoleColor]::Cyan}
I've opened issues at, the PsRadline repo and with the Insider's programme, so hopefully going forward this issue is no longer an issue.

Friday, July 20, 2018

My Book Scripts

I saw a comment over on Amazon relating to my last PowerShell book (see Amazon Book Listing) from Long Time Programmer. His comment is that he couldn’t download the code. I wish there was a way I could comment on his comment as there is a way. I’ve put all my scripts up on GitHub!  If you go to you can see the scripts there.  Although I have to say some of them – getting the scripts onto GitHub is a work in progress.

As an aside and for background: the publication process at the time this book was published had a few issues.  The web site used to enter content  was literally eating content so we switched over to word at last hour. In doing so, the longer-line scripts ended up broken in the final PDF and thus the published version.

To be helpful to my readers, I’ve slowly retrieved the scripts from inside the VMs and have published them to GitHub, Which is less simple than it sounds and it not yet complete. At present, I’ve ported over the recipe scripts for chapters 1-4, 8, 10, 11 (7 out  of 13). And I hope to have the updates soon.
Please download any of the scripts – and file issues if you find problems.

The conversion has been completed and I've created a version 1.0 of the scripts on the GitHub repository. . You can consume the scripts by navigating the GitHub UI or you can take a fork and clone to a local machine. The release mechanism in GitHub provides a zipped up Go to the GitHub Release page and download a .gz or .zip file depending on your tastes. I may do some further tidying up. 

Wednesday, July 18, 2018

Please Buy This PowerShell Conference In A Book


A couple of months ago, M:Ike Robbins (the tech editor of my last PowerShell book (, sent me mail about a project that he and a few others were planning. The idea was to develop a PowerShell Conference in a book. Mike invited some of the big PowerShell community members to each contribute one chapter. The proceeds are intended to help the DevOps community. Any royalties are to go towards OnRamp Scholarships with the DevOps Collective. Of course I said yes.

Well – now that book is published to which I have contributed a chapter. You can read about the book and buy it here: The book has an impressive list of contributors and is pretty reasonably priced! Of course, if you are feeling generous, LearnPub is happy to enable you to pay more.

The On-Ram Scholarship is a great cause, bringing new people into the DevOps field. You can read about the scholarship here:

My chapter in the book is entitled ‘A Lap Around .NET’ in which I look at what is .NET and some of the things you can do with it.

Saturday, July 14, 2018

Keeping PowerShell Modules Up To Date

At one time, many (most?) IT Pros did not worry to much about updating PowerShell modules,relying for the most part on whatever cmdlets come with the Application, PowerShell, and/or the OS. But times have changed. With the release of Windows PowerShell 5.1, work on modules both inside and outside Microsoft has not stopped. And a number of modules now have updates that might be useful.

Another big change in the PowerShell world is the movement towards holding these new versions on Repositories that you can access via built-in commands (i.e. Find-Module, Update-Module, etc). The question then becomes what modules need updating? Turns out there is a script or two for that!

The first question is whether you care enough about module updates to worry about dealing with updates, and the side effects of module changes.

As I was writing this article, I encountered an interesting example of this issue. The version of the PSReadline module has been updated  to Version2.0 This version has a breaking change in how you set UI token colours. it took a while to sort out but it drove home to me the need to test new versions and not just update because you can. Unless, I suppose, you like living on the edge.

So how do you tell what modules need updating. And as ever, there’s a script for that ™.

Here is a simple function that looks at all the modules you have on your system (well those pointed to via $env:PSModulePath), and checks to see if that module is available via the PSGallery. For every module the founction returns an object with three properties: the module name, the version on the local system and the version on PSGallery. For modules that do not exist on PSGallery, the script returns a PSGallery version of ‘zero’. Here’s the function:

Function Get-ModuleVersionInformation {


# Startup
$Start = Get-Date
Write-Verbose 'Get-ModuleVersionInformation'
Write-Verbose 'started at: [$start]'

# Get the modules on the local system
$Modules = Get-Module -ListAvailable -Verbose:$False
Write-Verbose ("{0} modules locally" -f $modules.count)

# For each module, see if it exists on PSGallery
# Create/emit an object for each module with the name,
# and the version number of local and remote versions
Foreach ($Module in $Modules) {
  Write-Verbose "Processing $($"
  $UpdateHt         = [ordered] @{}    # create the hash table
  $UpdateHt.Name    = $Module.Name     # Add name
  $UpdateHt.Version = $Module.Version  # And local version

try {
#  Find module, and add gallery version number to hash table
    $GalMod = Find-Module $ -ErrorAction Stop
    $Updateht.GalVersion = $GalMod.Version
  # here - find module could not find the module in the gallery
Catch {  
   # If module isn't in the gallery
  $Updateht.GalVersion = [System.Version]::new(0,0) 

# now emit the object
New-Object -TypeName PSObject -Property $UpdateHt

} # End foreach

$End = Get-Date
Write-Verbose "Stopped at: [$End]"
Write-Verbose "Took $(($End-$Start).TotalSeconds) seconds"
} # End Function

On my system, the output looks like this:

Psh[Cookham24:C:\foo]> $mods = Get-ModuleVersionInformation
Psh[Cookham24:C:\foo]> $mods

Name                     Version     GalVersion
----                     -------     ----------
Buildlab                 1.0         0.0       
NetCmdlets               16.0.6446.0 16.0.6592.0
tfl                      1.0         0.0       
Azure.AnalysisServices   0.5.0       0.5.2     
Azure.Storage            4.1.0       4.3.1     
AzureRM                  5.2.0       6.4.0                      
AzureRM.RedisCache       4.1.0       0.0       
AzureRM.Relay            0.3.1       0.0

… Etc.

Loaded with this function you can then do this:

$zero = [System.Version]::new(0,0)
foreach ($mod in $mods) {
  If ($mod.galversion -eq $zero) {
  $msg = "Module [$($] does not exist in PSGallery"
  If ($mod.galversion -gt $mod.version){
  $msg = "Module [$($] should be updated from v$($mod.version) to v$($mod.galversion)"
  Else {
  $msg = "Module [$($] does not need to be updated - current version $($mod.version)"

} # End foreach

The output, again in my main workstation looks like this:

Module [Buildlab] does not exist in PSGallery
Module [NetCmdlets] should be updated from v16.0.6446.0 to v16.0.6592.0
Module [ScriptBrowser] does not need to be updated - current version
Module [tfl] does not exist in PSGallery
Module [Azure.AnalysisServices] should be updated from v0.5.0 to v0.5.2
Module [Azure.Storage] should be updated from v4.1.0 to v4.3.1
Module [AzureRM] should be updated from v5.2.0 to v6.4.0
Module [AzureRM.AnalysisServices] should be updated from v0.6.2 to v0.6.9
Module [AzureRM.ApiManagement] should be updated from v5.1.0 to v6.1.1
Module [AzureRM.ApplicationInsights] should be updated from v0.1.1 to v0.1.4
Module [AzureRM.Automation] should be updated from v4.2.0 to v5.0.1
Module [AzureRM.Backup] should be updated from v4.0.2 to v4.0.6
Module [AzureRM.Batch] should be updated from v4.0.4 to v4.1.1
Module [AzureRM.Billing] should be updated from v0.14.0 to v0.14.3

This leaves me with a bit of work to do – updating PSReadLine, as I discovered did have some unfortunate side effects (and I suspect I am not the only one to have fallen over this issue!).

If I was brave, I could have updated that last script fragment to actually update each of the older modules. Not sure I’m ready for that, just yet…

Saturday, May 19, 2018

Free Cheat Sheets, Revision Aids and Quick References

A cheat sheet is a simple short document, typically 1-2 pages of notes designed to aid your memory.  I discovered an interesting site today, This site has over 2500 cheat sheets for all manner of topics, including Office, Business, Technology, kitchen and garden, travel, and a whole lot more.  The site has 17 cheat sheets relating to PowerShell as well as  35 cheat sheets relating to PHP. The most viewed cheat sheet relates to Regular Expressions (a technology I have yet to master).

The site also enables you to create your own cheat sheets.

Friday, April 06, 2018

Method Chaining–A Neat PowerShell Trick

I discovered an interesting  with PowerShell. It’s known as method chaining. Before explaining it – look at an example:

# c:\foo\testit.ps1
# Test of method chaining
$StringBuilder = [System.Text.StringBuilder]::New()
# Build up string contents
[string] $S1 = Get-ChildItem -Path c:\*.pdf | out-string
# Now build the string
$Null = $StringBuilder.
   AppendLine('Using String Builder as opposed to string concatenation').
   AppendFormat('This uses a cool feature: {0}', 'Method Chaining').
   AppendLine('.NET has other "builder" classes operate the same way.').
# Output the resultant string

This produces the following output:


With Method Chaining, you have an object with methods. You specify the object name (i.e. $StringBuilder) followed by a ‘.’ character. On subsequent lines you specify a method call followed by another ‘.’ character. In this case, I created the $StringBuilder object, then chained several method calls. Each method call added lines to the $StringBuilder object. You end the method chaining by omitting the .’ on the final method in the chain (the directory listing).

I’m not too sure I’d advocate using this. It is an obscure trick of the PowerShell parser and as such might fail my “3:00 in the Morning Test” (if woken at 3:00, could you figure this out before a cup of coffee?). But is pretty cool. Yet another example of how awesome the PowerShell parser is!

Wednesday, March 21, 2018

Code Signing Certificates and PowerShell

When creating PowerShell scripts for distribution, it can be useful to digitally sign the script. This ensures the person getting your code knows it has not changed since you sent it, and can verify you as the person signing the code. If you put code on GitHub, for example, a signature might be a great idea. To do this, you need to have a code signing certificate.

In terms of certificates, you have two main options. You can use your own CA to issue the certificate(s) – or use a public CA. The benefit of the public CA is that their root CAs tend to be fully trusted making it more useful. If you issue your own certs, you may have trouble with other people trusting your code signing certificates.

I have recently obtained a new code signing certificate from DigiCert ( It was really very easy:

1. Open an account and order your cert.

2. Validate you are who you say you are. This involves sending DigiCert some documentation (eg your Passport) to prove you are who you way you are.

3. Do a Skype call, where they watch you sign their Identify Verification and Authorization document.

4. Generate, download, and install the certificate.

The validation process was easy although I had issues with the Skype call, initially. Mainly because I was flat out ill for weeks. Then when I was better, I had some difficulty getting the Skype call going. Entirely my issue, although it has to be said, Digicert support are really very, very, very busy. Between being ill and their overload, it took a bit longer to organise – but today it’s done. I did the call, they saw me sign the form and within an hour or so, the cert was working.

To use the cert to sign something is pretty easy. First you start with the script you want to sign:

# C:\Foo\Certs\Cert1.ps1
Write-Host "I got my cert from DigiCert"

A simple script saved as C:\Foo\Certs\cert1.ps1. To sign it it is simple:

$Cert = Get-ChildItem -Path Cert:\CurrentUser\My\ –CodeSigningCert
Set-AuthenticodeSignature -Certificate $Cert -FilePath C:\Foo\Certs\Cert1.ps1

Once signed, you can verify the signature by using Get-AuthenticodeSignature, like this:


Very simple and very straightforward. If you, for some reason, have multiple signing certificates then you’d need to adjust call to Get-ChildItem to ensure you get the right certificate.

Friday, February 23, 2018

PowerShell’s $OFS built-in Variable And What It Does

The other day, I was working on converting some C'# to PowerShell. 95% was trivial and almost muscle memory. Then I came to this block of C#

char[] chars = { 'w', 'o', 'r', 'd' };
string string1 = new string(chars);

The output is:


So I initially translated it as:

[char[]] $Chars =  ('w', 'o', 'r', 'd' )
[String $String1 = $Chars
Write-Host $String1

But that produced:

w o r d

The same characters but with spaces between which seemed illogical (at first!). I scratched my head, and did a bit of digging over at Spiceworks, where I was introduced to the $OFS PowerShell Variable. $OFS holds a string, known as the Output Field Separator.   PowerShell uses this character string to separate array elements when it coverts the array to the string, PowerShell has a default value of  ” ”, but you can change at the command line, in a script, or in your Profile. The issue here is that PowerShell is doing the array to string conversion and separates each character in the char array with the separator (“ “). You can read a bit more about this in an old blog post by Jeffrey Snover:

This gave rise to two solutions. The first is to let .NET do the conversion and the second was to leverage $OFS. Here  are two ways to do it:

# Leveraging $OFS
[char[]] $Chars =  ('w', 'o', 'r', 'd' )
$OFS = ''  # Set separator to null
[String] $String1 = $Chars
Write-Host $String1
# Or using .NET directly
[char[]] $chars =  ('w', 'o', 'r', 'd' )
$String2 = [System.String]::New($Chars)
Write-Host $string2

This is interesting, but there is a highly practical solution to an issue I’ve seen brought up in several PowerShell support places. The issue if how to construct a comma separated string of words. So if you had an array of several words such as (‘X423q420’, ‘JG75-01-27’,”PCNY”) you could easily concatenate them as follows:

$Array = (‘X423q420’, ‘JG75-01-27’,”PCNY”)
[string] $Array

Which produces:


You could also create the array from properties then force it to be separated by $OFS, like so:

$F = Get-ChildItem –Path X.XML
$OFS = ','
$Sring3 = [string] ($F.Fullname, ($f.length/1kb).ToString('n3'))
Write-Host $String3

Which produces this:


You learn something nearly every day!

Sunday, February 18, 2018

Using Azure PowerShell and PowerShell 3 or 4? You need to update PowerShell SOON (probably).

I recently saw a GitHub Pull Request ( for the Azure PowerShell cmdlets (the PR was merged into Version 5.3.0 of the Azure cmdlets). Besides from the continuing improvements that each version brings, I noted one very interesting sentence: 'PowerShell version 3 and 4 will no longer be supported starting in May 2018. Please update to the latest version of PowerShell 5.1 '

What does this mean? Well – it means that after May this year, if you are running either PowerShell V3 or V4, new versions of the Azure cmdlets may not longer work – and are not supported in any case. That is not to say that either the sky is going to fall in! Older versions of the cmdlets should continue to work and most of the newer cmdlets should work too. Note the ‘should’. But why take the risk. You have several months before the lack of support begins. But you should start to plan now if you are still using PowerShell V3 or V4 to manage Azure.

So what should you do? The answer should be fairly obvious – if you are using Azure and the Azure cmdlets, just upgrade to the latest version of PowerShell (i.e. 5.1). This new version of PowerShell should work just fine on all supported versions of Windows. Of course, if you are still using XP to manage Azure then you may have some issues trying to upgrade, although an OS upgrade to Windows 10 would fix this problem.

The upgrade of PowerShell should be a no brainer. I suspect many (most?) readers here are already running later versions!  There should be no issue, but if you are using Exchange, tread carefully to ensure that the version of PowerShell you are thinking of upgrading to is going to work with and is supported by your version of Exchange.  This is probably not going to be an issue if you using hosted Exchange (O365).

It seems to me that this is the start of removing all support for PowerShell V3 and V4. V5 and V5.1 are sufficiently better to make the upgrade most welcome. Loads more cmdlets, improvements in workflows etc are all goodness that comes from the Upgrade.

What is your take?

Saturday, January 20, 2018

Power-User–a great productivity add-in for PowerPoint

I do a lot of PowerPoint presentation – I train on a variety of technical subjects and PowerPoint has been my ‘friend’ for as long as I can remember! Over the years, PowerPoint has evolved, but I still prefer the older menu structure vs the ribbon. But such is life – with the menu or ribbon, PowerPoint is an awesome product. With that said, I do find remembering where the key features are to be found.

I’ve just started using a new tool, Power-User ( which is an add-in for both PowerPoint or Excel. When you open PowerPoint, once this add-in is installed, you get a new ribbon item with great tools, which looks like this:


Thus, you see all the useful PowerShell features all in one place. Power-User helps with creating a variety of effects including icons, diagrams, colour management etc., etc., etc. And as if that were not enough, Power-User also has some cool Excel tools as well, like this:


I love this tool and would not be without it!  For more details on this cool product, see the presentation video at:

Power-User is, however, a commercial product. Students and teachers can get this for free, but for commercial use individual licenses are €198/year. For larger companies, a bulk license can reduce the cost per user. So not free, but well worth the fee if you are doing a lot of PowerPoint. My only regret is that I did not find this tool years ago!

Friday, November 10, 2017

Major updates to PowerShell Azure Module

Like the rest of Azure, the Azure PowerShell cmdlets are truly a work in progress. I've written many times before about the cmdlets, including details of the great cmdlet renaming ( I've also demoed these cmdlets on a variety of occasions.

Microsoft has just released a major new revision to these cmdlets, version 5.0.0. The details can be found over on GitHub at:

This is a major update, as evidenced by the major version number change (from 4.x.x to 5.x.x). Additionally, there are several breaking changes - changes that could break your code if you update just the module itself.  You can see a list of updates at:

If you are using Azure cmdlets - then you probably have some work to do to update to the new cmdlets. But all in all, such is the price of progress.

Monday, October 16, 2017

A Cool Azure Resource

I spent the weekend attending a Train-The-Trainer event at Microsoft UK (Thanks Ed Baker!). The event was focused on Azure and both what it was and how to teach it. A cool event which led to a lot of sharing of tips, tricks, and cool links.

One particularly cool link I discovered was to When you navigate there, you see a page like this:

Each tile on the page represents one Azure service. Click on a service and a neat pop-up appears providing more details of that service. Clicking on Virtual Machines, for example, shows this:

A great launching pad for discovering more about Azure.

Thursday, October 12, 2017

Events in the Security Event Log

I was answering a question in the Spiceworks PowerShell Forum concerning the event log. The poster was looking for how to find out who had logged on to a particular computer. The answer was to use Get-WinEvent and search the Security log for the relevant event. Easy.

But how do you know which event to look for? There are so many events! Well, there's a PowerShell script for that. To find the different event codes and roughly what they mean looks like this:

# Get all the security even  
$e = Get-WinEvent -LogName Security
# Get the different message kinds:
$ids = $e | Sort-Object Name |Group-Object -property id
# And print the event types 
Foreach ($id in $Ids) {
$m = ($id.Group[0].Message).SPLIT("`n")[0] 
" {0:N5}    {1}" -f ($id.NAME), $m }
This code first gets all the security events and sorts them by Event ID. Then the code extracts the first line of the Event Log message and displays the event ID and that first line. On my the output looks like this:
 4624    An account was successfully logged on.
 4672    Special privileges assigned to new logon.
 4634    An account was logged off.
 4648    A logon was attempted using explicit credentials.
 5058    Key file operation.
 5061    Cryptographic operation.
 4798    A user's local group membership was enumerated.
 4799    A security-enabled local group membership was enumerated.
 4904    An attempt was made to register a security event source.
 4905    An attempt was made to unregister a security event source.
 4907    Auditing settings on object were changed.
 5059    Key migration operation.
 4688    A new process has been created.
 4608    Windows is starting up.
 4902    The Per-user audit policy table was created.
 1100    The event logging service has shut down.
 4616    The system time was changed.
 4826    Boot Configuration Data loaded.
 5033    The Windows Firewall Driver started successfully.
 5024    The Windows Firewall service started successfully.
 4647    User initiated logoff:
So knowing this, finding out who logged in is simple, right? You might think. It takes a bit of tinkering with the object, but here's my code:

# Get logon users
$le = $e | where id -eq 4624
$x =
foreach ($event in $le) {
$time = $event.timecreated
$username = $[5].value
$domain = $event.Properties[6].value
If (($username -ne '') -or ($Username -ne 'System')) {
$ht = @{}
$ht.time = $time
$ht.user = "$domain/$username"
New-object psobject -property $ht
# And display the results:
$x | group user | sort count -desc| ft name, count
This code creates a simple object for each event log entry for the relevant ID. This object just has the time, username and domain name from the event log entry. I create an object to, at the end, group then sort the logon events. The result is almost like this:
Name                                                    Count
----                                                    -----
COOKHAM.NET/JerryGarcia                                  7576
NT AUTHORITY/SYSTEM                                       746
COOKHAM.NET/COOKHAM24$                                     73
COOKHAM/BobWeir                                            36
NT VIRTUAL MACHINE/27A96661-D855-4286-81D6-BBB32172CCED     6
COOKHAM.NET/MickyHart                                       5
Window Manager/DWM-1                                        2
NT AUTHORITY/NETWORK SERVICE                                1
NT VIRTUAL MACHINE/55C8EC55-6D2B-421D-A454-28FCF4680366     1
NT VIRTUAL MACHINE/53EC57B5-BAB2-4A29-A34B-19A8BB857C42     1
NT VIRTUAL MACHINE/45FF27A5-C133-4213-9A4A-DBF4317D55D0     1
NT VIRTUAL MACHINE/4459B92D-0476-4815-B2DE-C3243CD2D82B     1
NT VIRTUAL MACHINE/370E6442-86B5-4310-BDAB-1882DAE4E5C6     1
NT VIRTUAL MACHINE/33872EB0-2259-4312-83F4-AE783B9D817C     1
NT VIRTUAL MACHINE/289DD95C-0454-4D51-93FC-F4D7502D894B     1
NT VIRTUAL MACHINE/596834C2-6B40-47E6-9EC5-3231BAD2C01B     1
NT VIRTUAL MACHINE/125EFD6E-2F88-4E2E-A0F2-BDA9516B2B59     1
NT VIRTUAL MACHINE/0C77EC57-8A20-4533-A4E1-5CDB93CB1DC2     1
NT AUTHORITY/ANONYMOUS LOGON                                1
NT AUTHORITY/LOCAL SERVICE                                  1
NT VIRTUAL MACHINE/2FAD3305-C65D-4304-AFF1-F4CFC0C96381     1
NT VIRTUAL MACHINE/64D69931-57FE-491F-96C8-215DE6B3D3FC     1
NT VIRTUAL MACHINE/880CD2FD-7304-4CE1-B831-87ED01DD0BD7     1
NT VIRTUAL MACHINE/7A4205E9-D2C6-466C-82BE-80CFF9947738     1
NT VIRTUAL MACHINE/FA3ADF88-EA85-43A4-AE49-5551186977DB     1
NT VIRTUAL MACHINE/EBF0AAF0-2300-4CD3-9B92-BCA29896DD90     1
NT VIRTUAL MACHINE/E4B8AA47-B256-4918-9098-A80C09DC91ED     1
NT VIRTUAL MACHINE/DC824601-E4F9-445D-BFE4-44FB83D7B733     1
NT VIRTUAL MACHINE/DA85B909-A42E-400F-96CB-340BBB6E0DC0     1
NT VIRTUAL MACHINE/D5420357-DF18-4140-B986-B85CF25D8FF1     1
NT VIRTUAL MACHINE/6A8984FD-8774-447A-9F35-4FD97766E303     1
NT VIRTUAL MACHINE/BE427F4F-C3AC-4086-B58D-8B5B8B8C7863     1
NT VIRTUAL MACHINE/A20EA3B5-7926-4AE4-96D7-4AFE2E34D80A     1
NT VIRTUAL MACHINE/9C00DC59-E565-4B88-88D0-CEE2AC08E870     1
NT VIRTUAL MACHINE/95D96D7E-9A2F-46D8-8E02-0FC0B2F9E594     1
NT VIRTUAL MACHINE/9353F711-F39C-47E0-B41A-9E85D70997D8     1
NT VIRTUAL MACHINE/88536766-EF5D-4AE9-A343-B3713EA912DF     1
Font Driver Host/UMFD-1                                     1
NT VIRTUAL MACHINE/BFAFEC2C-5565-4458-A359-A4EC6F62079C     1
Font Driver Host/UMFD-0                                     1
Fun and games with the event log!

Wednesday, October 04, 2017

Free Microsoft Azure Symbol/Icon Set

Over the years, many Microsoft groups have created sets of downloadable symbols and icons so you can create nice diagrams to represent your Azure service architecture. The latest set of tools includes Azure services which can be used in PowerPoint or Viso making it easy to create professional looking content.

You can get this icon pack at: Note the download is 23.3MB.

Wednesday, September 20, 2017

The PowerShell Book Is Complete

Since late last year, I have been working on a book. Titled  Windows Server 2016 Automation with PowerShell Cookbook (ISBN: 978-1-78712-204-8), it was finally completed and sent to the printers. The book is published by Packt Publishers.

It's taken 10 months to complete and we face some serious issues during the writing. We had been using a neat web portal, but it suddenly started 'eating' bits of code. It was a nightmare and cost weeks of extra effort to fix (and we'd fix it only for the portal to eat the code again). 

Then disaster struck in the form of my co-author having to drop out for personal reasons. This is never nice. I ended up picking up the extra chapters, but due to time, space and personal commitments, we did have to drop some of the chapters.  And during the final chapter reviews, we found that code that looked great in the Word Documents had been badly borked in the final PDFs (so HOURS or detailed proofreading). I just hope I picked up all the errors.

But it's done. The printers are doing their best now to print it, and Amazon is now selling the book. I have to say I get a kick out of seeing that page.

The code is planned to be uploaded to a GITHUB repository, so you can download and leverage it. This should happen soon!

So with this book done, my fifth, I am never going to do this again. Way too much work, way too many late nights and early mornings, way too much stress. Never again. But having said that, my super-star tech reviewer, Mike Robbins, has suggested another book. Hmmm.

In any event, let me know if you get this book and what you think!

Wednesday, August 30, 2017

VSCode as a replacement for the ISE

VSCode is a free source code editor developed by Microsoft and aimed at WIndows, Linux, and MACOS. VScode includes support for various languages, such as PowerShell, as well as embedded GIT control, syntax highlighting, code completion, and more.

Mike Robbins has produced a nice video, which you can find at This video takes you through the process of downloading VSCode, and setting it up as a replacement for the ISE.

It turns out to be remarkably simple to do this. Downloading is easy - and the installation process the normal clickercise approach. Once you get VS Code installed, you can easily configure it to act as the replacement for the ISE.

Once you have your settings configured, you end up with something that looks like this:

It looks and feels almost like the ISE, but with a lot of extra features above and beyond the basics provided by the ISE. These include the ability to determine aliases (and replace them with full cmdlet names), GIT hub/VSTeam Services/Hg integration and a lot more.

If you like the ISE, you are likely to enjoy VS Code!

Wednesday, August 16, 2017

Creating a SHA1 Hash - Using PowerShell

I recently saw a query about how to create a SHA1 hash, using Powershell. The post was looking at using a web site for this and accessing it via PowerShell's web processing. But there is a much simpler way - just using the .NET Framework. Here's a simple script that hashes a string:

# Create Input Data 
$enc      = [system.Text.Encoding]::UTF8
$string   = "This is a string to hash< $data     = $enc.GetBytes($string)
# Create a New SHA1 Crypto Provider
$sha1 = New-Object System.Security.Cryptography.SHA1CryptoServiceProvider
# Now hash and display results 
$ResultHash = $sha1.ComputeHash($data)

The trick to this approach is to convert the string into a byte array and then pass the byte array to the ComputeHash method.

Saturday, July 15, 2017

Managing Azure with PowerShell - A Spiceworks Blog Series

One of my fun tasks these days is being a group administrator and moderator on Spiceworks community forums. The forums are IT Pro focused and include a great group dedicated to all things PowerShell. If you have issues or questions, you are most welcome to come on over and post away. If you know PowerShell, we'd love to have more folks answering the torrent of questions we get.

In that role, Spiceworks asked me to create a series of blog posts on the Spiceworks Cloud blog which covers PowerShell and how you use it in the context of Azure. I offered to update some of the content in my upcoming book (See for details). The publisher (Packt Publishing) kindly agreed.

The first article, Introduction to Managing Azure Services Using Windows PowerShell, was posted this week. The next blog post, which looks at getting the modules you need to manage  Azure whould be posted sometime next week. A third article on the basics of Azure storage and how to create an SMB share (and access the share across the Internet) is planned and should follow on in due course.

I have a number of additional posts to create, including one on building a Virtual Machine, and another on virtual networks and creating a P2S VPN into the VM. I am very much open to suggestions for more in this series.

Thursday, July 13, 2017

Hyper-V and PowerShell - A Tale of Two Modules

I've been working on a book project (see: for details!) and have been working a lot with Hyper-V. I've built a nice farm of VMs (18 or so) representing a bunch of server roles and features. Then, I've been using PowerShell to exercise those roles and features.

These VMs all run on client Hyper-V, on a Windows 10 (AU) host that has 96gb or ram, 2x6-core XEON processors, and loads of disk. The VMs are nearly all running Windows 2016 Server. The chapters all utilise AD/DNS/DHCP/CA etc. A nice setup for writing a book.

In writing, I've noticed that Windows 10 as well as Windows Server 2016 both ship with two Hyper-V modules. The two modules are version 1.1 and, as you can see here:

The version module is a superset of the version 1.1 module. Version 1.1 contains 178 cmdlets, while  version contains 235. Both modules have display XML included. Both versions use the same file name, but the Version copy is larger.

You could, or course, manually load version 1.1 module like this:
Import-Module -Name Hyper-V -MaximumVersion 1.1
So long as you just use the cmdlets in the 1.1 version, you would be safe, but if your script did load 1.1, then trying to use cmdlets in the module generates what at first sight is a curious message:

The error message is also both wrong and, if taken, confusing. Importing the module as suggested by the error message generates more error messages. The error messages (Error in TypeData, etc) occur because Powershell is trying to load the version copy of the display XML, and most of the components were already loaded from the 1.1 version. And even if you ignore the display XML errors, the suggested solution still fails with the same error message.

The solution to this error is easy: update your scripts to not explicitly load v1.1. OR, if you do need for some reason to use the 1.1 version and use cmdlets in, then pressed them with a 'Get-Module Hyper-V | Remove-Module Hyper-V' and then follow the cmdlet with commands to remove the module and reload the 1.1 version. Personally, while that could work, it's awfully messy and possibly not needed.

Does having two versions really matter?  If you just use cmdlet names in the Hyper-V module, such as Get-VM, then PowerShell by default loads version  If your script uses Import-Module to load the Hyper-V module explicitly, then again by default, PowerShell loads  Having written over 100 scripts across a dozen different Server 2016 features and roles - I never noticed any problems. My scripts, with a few exceptions, relied on PowerShell's module autoload feature - I called the cmdlet and PowerShell loaded one.

If your scripts, on the other hand, explicitly load V 1.1 (as shown above), then you may get a strange error. But in most cases, that can be avoided by simply not explicitly loading version 1.1 of the module. Now I know there may be cases where you may need to use a V 1.1 cmdlet, but those cases should be pretty rare.

Monday, June 26, 2017

Setting Application Pool Recycling Values with PowerShell

As I mentioned a while ago, I'm working on a new PowerShell book (See for details! In writing the book, I've been creating simple scripts to do useful things. In researching them, I found a number of aspects really well covered, reference wise. Other things were not covered well if at all. I hope to post some things I've discovered in the coming months.

With IIS, you can create applications that run in application pools. An application is some set of web pages (with related executables). An application pool is a process, or processes, that run this application. This provides process isolation between applications reducing the impact a badly behaved application can have on other applications running on the same server. Resource leaks can bring an entire web server down, for example.

One way to minimise these sorts of issues is to recycle the application pool - just stop then restart the processes running the application. A neat trick that reduces the risks of resource leaks. One downside is that any state within the application is lost. Needless to say, there are other ways to save state that are not affected by an application pool restart. For a fuller look at the things you can do to configure application pools, see: This document is old, but is a good starting point (and worked fine on IIS 10 for my needs).

You set application pool recycling values, using PowerShell, by setting item properties on certain items within the WebAdministration provider (the IIS: drive). This is simple, but the property names are not all that obvious at first.

What I wanted to do was:

  • Set specific times at which to recycle the application pool
  • Set the pool to automatically if private memory rises beyond a limit, say 1GB.
  • Set the pool to recycle the pool after the pool processes a certain number of requests, say 1 million.

In PowerShell, once you know where to look, this is simple:

# Set Application Pool Restart time
Clear-ItemProperty IIS:\AppPools\WWW2Pool -Name Recycling.periodicRestart.schedule
$RestartAt = @('07:55', '19:55') 
New-ItemProperty -Path 'IIS:\AppPools\WWW2Pool' -Name Recycling.periodicRestart.schedule -Value $RestartAt

# Set Application Pool Maximum Private memory
Clear-ItemProperty IIS:\AppPools\WWW2Pool -Name Recycling.periodicRestart.privatememory
[int32] $PrivMemMax = 1GB
Set-ItemProperty -Path "IIS:\AppPools\WWW2Pool" -Name Recycling.periodicRestart.privateMemory -Value $PrivMemMax

# Set max requests before a recycle
Clear-ItemProperty IIS:\AppPools\WWW2Pool -Name Recycling.periodicRestart.requests
[int32] $MaxRequests = 100000
Set-ItemProperty -Path "IIS:\AppPools\www2POOL" -Name Recycling.periodicRestart.requests -Value $MaxRequests

Some things that caught me out a bit:
1. Finding out the property names. In the case of recycling after 1m hits, the property name is 'Recycling.periodicRestart.PrivateMemory'. I suspect this naming is used by the provider to access the underlying XML that IIS actually uses to hold configuration information.
2. Finding values is easy, if there is one. I found the easitest way to set these values was to first clear the property, then set it.
3. Some item properties take properties of a certain type. It helps to specify the type (as shown above) as some times PowerShell tries to be helpful which can confuse the provider.

Tuesday, May 02, 2017

AD User Properties In PowerShell

I spend a lot of time as a Group Administrator looking after the PowerShell forum over on Spiceworks. The PowerShell group has an active forum  which you can find over at,

One issue that arises often is around getting properties back from a user object in Windows Active Directory. Typically we see posters knowing the GUI interface in Active Directory Users and Computers (ADUC), and wanting to get the same details. Although it is NOT new, I found a great resource the other day: Mappings for the Active Directory Users and Computers Snap-in.

This page, which has numerous subpages, maps the fields you find on the property sheets inside the ADUC MMC snap-in to the properties names you get/set using the Microsoft provided AD cmdlets.

For example, if you have set an Office address on the OU Managed By property sheet, you need to use the Physical-Delivery-Office-Name property from Get-Organizational unit to obtain that information. Likewise, the General Property Page for a user object shows First Name (property givenName), Last Name (sn), and the Display Name (displayName).

This page has links for:

  • Computer Object User Interface Mapping
  • Domain Object User Interface Mapping
  • Group Object User Interface Mapping
  • Object Property Sheet
  • Organizational Unit User Interface Mapping
  • Printer Object User Interface Mapping
  • Shared Folder Object User Interface Mapping
  • User Object User Interface Mapping
If you are working with the AD cmdlets and you need to map what you see in the ADUC GUI to what you need to use in PowerShell.

Saturday, April 29, 2017

Top 50 PowerShell Blogs

I just got e-mail that this blog has been included in the Feedspot.Com's Top 50 PowerShell Blogs list. You can see this list over at

I started this blog in 2003 - and first blogged about PowerShell (well, it was called Monad in those days) on 1 Nov 2003. It's been a long run with PowerShell - since that first day when Jeffrey Snover presented 'Batch Scripting, what you can do in 7 lines of code' to PDC 2003.

As Robert Hunter once wrote (and the Grateful Dead sang) "What a long strange trip it's been".

My Next PowerShell Book

I'm working on a new PowerShell book. The book's title is Windows Server 2016 Automation with PowerShell Cookbook (ISBN: 978-1-78712-204-8).  The focus of the book is showing how to manage key Windows Server 2016 features using the latest versions of PowerShell. For each area covered, I show how to do things using Powershell, in the form of recipes. The intention is to both teach a bit about the feature itself, and show you how to manage the feature using built-in and add-on modules.

In a few cases, there is no built-in way to perform some operation using PowerShell. My favourite example is that the Printing cmdlets provide no way to create a printer pool, but you can in the UI. In that case, and others, the book shows useful Win32 console applications. In the case of printer pools, we show how to use PrintUI.DLL and RunDll32.EXE to set up a printer pool. IT pros can't yet do everything with PowerShell, out of the box - but in many cases, that's just not a problem.

The book has 13 chapters, as follows:
  • What’s New in PowerShell
  • Implementing NanoServer
  • Managing Windows Updates
  • Managing Printers
  • Managing Server Backup
  • Managing Performance
  • Troubleshooting Servers
  • Managing Windows Network Services
  • Managing Network Shares
  • Managing IIS
  • Managing Hyper-V
  • Managing Azure
  • Using Desired State Configuration
At the time of this post, I'm nearly done the drafting of the book's contents, and entering into the slow, tedious, and boring part: the editing and final proofing. It may be slow, tedious, and boring, but it's very important, as any writer knows.

There were several hiccoughs with the writing, but it's looking now like this book will be published in the autumn. As soon as I have a more definitive date, I'll post it.

Publication should be early October. Sadly, my planned co-author had to drop out of the writing due to personal commitments. Additionally, I had to scale back a bit on the contents. The original plan was to write 450 pages. The book ended up something like 650!

Saturday, January 28, 2017

Nested Hyper-V with Windows 10

I've been away all week, teaching in Trondheim Norway. A nice place, great students and a useful Microsoft training course. In the course, Hyper-V features quite a lot - one cool feature discussed in nested Hyper-V.

Nested Hyper-V is a feature that enables you to create a virtual machine, and then load Hyper-V into that machine. So you can have a VM running VMs. This feature is cool, certainly at a technical level. No doubt someone is going to point out that VMware supports this, but the feature is new in Hyper-V on Server 2016. And interestingly enough, it works in Windows 10 Anniversary Update too!

Why does it matter?  For me, it matters since I am writing a book on PowerShell showing its range and depth. One chapter covers Hyper-V and having Nested Hyper-V means I can create two VMs (HV1, HV2) cluster the VMs, then create clustered virtual machines, The chapter is now easier to write.

The feature matters for customers too.  This enables you to use Hyper-V containers within a VM on a VM. And, it's a fantastic training tool when using on-line labs. The lab vendor, such as Virsoft (a great hosted labs experience!), to provide a student with a VM, in which they can load and use Hyper-V. Previously that was unsupported.

Getting nested Hyper-V to work is great news. For some time, I believed that this would not work on my systems. I have three big Dell Precision 7500 systems. When I tried this during the beta of Windows Server 2016, Coreinfo.exe suggested that my system did not support SLAT. And that meant I could not use nested Hyper-V. But it was wrong!

Here's a picture of a VM hosting a nested VM:
As you can see, a VM running a nested VM. The nested VM, which I called 'embedded' is in the midst on installation.

It turns out that the fix was pretty simple. In the host VM, I just had to issue a simple PowerShell command:

Set-VMProcessor -VMname DC1-ExposeVirtualizationExtensions $True
I had to shut down the  VM first, then reboot. Once rebooted, I was able to bring up the Hyper-V console and create the embedded VM.