PowerShell for Windows Admins

October 27, 2017  1:37 PM

Windows 2016 1709 release

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Windows Server 2016

The Windows 2016 1709 release is the first of the semi-annual updates for Windows Server – interestingly its referred to as Windows Server 1709 in the documentation.

Its now available for download through your Software Assurance channels and Windows evaluation centre. MSDN subscribers can also get a copy.

A big surprise is that 1709 is Server Core only!  You can’t get a GUI version. The suggestion is to use the (very) incomplete project Honolulu web browser based admin tool to manage the servers. More on that in another post.

Windows Server 1709 new features are described here


The standouts are the new features for containers and virtual machines.

October 26, 2017  5:35 AM

Windows 10 Fall Creators Update

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Windows 10

The Windows 10 fall Creators Update arrived this morning.

After the usual long download, install and then updating bits after I first log on (that last bit is really irritating – thought it was going away) I got into the machine.

First impression is that there are some minor cosmetic changes. Some icons (extensions) appear on the Edge menu bar that I didn’t have before and don’t want now so I have to waste my time undoing changes Microsoft, in their infinite wisdom, have imposed on me because they know better than I do how I want to work!  same with automatically adding the People icon to the taskbar. Stop changing my settings!

So what’s in FCU. Unless you’re a developer – on the surface there’s not a lot to be honest.

For Admins


For developers



Having feature updates every 6 months is a great idea but actually getting something useful would be better. Maybe some of the new features in PowerShell v6 being back ported would be a good one.

October 25, 2017  5:32 AM

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
CIM, Powershell

A question on the forum about getting monitor resolution led to this code

Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorId |
foreach {
 $filter = ("InstanceName = '$($psitem.InstanceName)'").Replace("`\", "`\`\")
 $maxres = Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorListedSupportedSourceModes -Filter $filter |
 Select-Object -ExpandProperty MonitorSourceModes | 
 Sort-Object -Property {$_.HorizontalActivePixels * $_.VerticalActivePixels} -Descending |
 Select-Object -First 1
 if ($psitem.UserFriendlyNameLength -gt 0) {
 $name = ($psitem.UserFriendlyName -notmatch '^0$' | foreach {[char]$_}) -join ""
 else {
 $name = 'Unknown'

$props = [ordered]@{
 Manufacturer = ($psitem.ManufacturerName -notmatch '^0$' | foreach {[char]$_}) -join ""
 Name = $name
 Serial = ($_.SerialNumberID -notmatch '^0$' | foreach {[char]$_}) -join ""
 MaximumResolution = "$($maxres.HorizontalActivePixels) x $($maxres.VerticalActivePixels)"
 New-Object -TypeName PSObject -Property $props


NOTE – we’re working in the root\wmi namespace not PowerShell’s default of root\cimv2

Use WmiMonitorId to get the attached monitors and for each of them create a filter using the instance name. You have to replace \ with \\ when dealing with WMI.

Use WmiMonitorListedSupportedSourceModes and expand MonitorSourceModes. use sort-object to find the maximum resolution (multiply horizontal by vertical)

Create an output object. I had to deal with the name of the monitor separately because one of my monitors didn’t have a user friendly name.

Results look like this

Manufacturer   Name    Serial       MaximumResolution
------------  ----     ------       -----------------
GSM           22EA63   304NDJX51788 1920 x 1080 
LEN           Unknown  0            1600 x 900

October 24, 2017  2:17 PM

PowerShell + DevOps Summit 2018 schedule

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The schedule for the 2018 Summit still needs a little bit of polishing to finish it but it’s taking shape. I’ve started releasing information on sched.com that we’re using for all our scheduling needs for the Summit. The one and only truth regarding the sessions and their times can be found at https://powershelldevopsglobalsummit2018.sched.com/ 

I’ll be adding sessions over the next few days so keep checking.

I’m really excited about the schedule for the 2018 Summit. We’ll have 4 rooms for sessions with many of your favourite speakers returning and many new speakers which is really good to see. The Community Lightning Demos return by popular acclaim and we’ll be running an Iron Scripter competition as well. The PowerShell Team will be presenting all day Monday and at other sessions through out the Summit.

Registration opens 1 November and once you’re registered through eventbrite your information will be sync’d to sched.com so that you can access the schedule and use the scheduling app.

October 24, 2017  1:32 PM

PowerShell v6: #1 major differences

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

In August 2016 PowerShell went open source. Since then we’ve seen 18 releases of alpha code and 8 beta release with another beta release imminent. This post – https://blogs.msdn.microsoft.com/powershell/2017/07/14/powershell-6-0-roadmap-coreclr-backwards-compatibility-and-more/ – from the PowerShell Team suggested a full release of PowerShell v6 before the end of 2017.

I’ve not written much about PowerShell v6 so far as its been rapidly changing but we’re beginning to see where PowerShell v6 is going. In this and a series of posts I’ll show you what’s different in PowerShell v6 – some good and some bad – what the important changes are and what impact that might have on your administration strategies.

The current version of Windows PowerShell – in Windows 10 and Server 2016 or WMF download is 5.1. As the above blog post states PowerShell 5.1 requires the FULL .NET Framework – currently 4.x – and will NOT receive major feature updates or low priority bug fixes (I read that as only security related bug fixes are likely).

PowerShell v6 is a fork of the v5.1 code but is based on .NET Core and will address bugs in the original 5.1 code, which won’t be ported back to PowerShell 5.1. PowerShell 6 uses .NET Standard 2.0 to provide binary compatibility with existing .NET assemblies which means that some but not all existing PowerShell modules will work under PowerShell v6.

PowerShell v6 isn’t an upgrade for PowerShell 5.1. It installs side-by-side meaning you can have multiple versions of PowerShell on the same machine.

Windows PowerShell (v1 – v5.1) is the Windows only version that shipped as part of the OS. PowerShell core (v6) is cross-platform with releases for Windows, Linux, macOS and docker – https://github.com/PowerShell/PowerShell

The major differences between PowerShell v6 and the Windows PowerShell you’ve come to know and love are detailed on the v6 release notes – https://github.com/PowerShell/PowerShell/releases.  In summary these include:

Allow * to be used in registry paths – breaking change
Remove -ShowWindow from Get-Help – breaking change
Fix incorrect position of a parameter which resulted in the args passed as input instead of as args for InvokeScript()  – breaking change
Enable transcription of native commands on non-Windows platforms
Add Remove-Service cmdlet
Added functionality to set credentials on Set-Service
Get-Date now supports more argument completion scenarios
Exclude -ComObject parameter of New-Object on unsupported (currently non-Windows)
Remove Workflows
Get-Content -Delimiter to not include the delimiter in the array elements returned
Add support for converting enums to string
Support SSH for remoting as well as WSMAN
Remove WMI cmdlets – CIM cmdlets are still available
Remove the *-Counter cmdlets
Move-Item cmdlet honors -Include, -Exclude, and -Filter parameters
Change positional parameter for powershell.exe from -Command to -File  – breaking change
Make change across PowerShell to support case sensitivity on *nix
Putting & at the end of a pipeline will cause the pipeline to be run as a PowerShell job.
Add -Extension and -LeafBase switches to Split-Path so that you can split paths between the filename extension and the rest of the filename
Fix Get-Help to not return multiple instances of the same help file

Plus a whole load of smaller changes to enable PowerShell to work on Linux and macOS

These changes are in the pipeline
Rename powershell.exe to pwsh.exe – Linux admins don’t like typing more than 4 characters at a time evidently
Standarize encoding for cmdlets that write to files
Remove the -ComputerName parameter from many cmdlets e.g. *-Service & *-Process so that individual cmdlet based remoting (over DCOM) isn’t available. All remoting goes through SSH or WSMAN


There are also a few issues to consider:

Case sensitivity – Windows is case-insensitive but Linux and macOS are case sensitive. You need to use the correct casing on Linux and mac
File path delimiters – non-Windows must use /
File extensions – not usually used on non-Windows but are required by PowerShell e.g. .ps1 and .psm1
Aliases that match linux commands – ls, cp, mv etc – are removed on Linux and macOS
JEA isn’t supported on non-Windows
Snapins aren’t available on v6 so some functionality e.g. Active Directory cmdlets can’t be used

PowerShell v6 is a major change – probably best regarded as a breaking change. I’ll investigate some of these issues in more depth in subsequent posts

This is a useful list of packages and resources irrespective of version- https://github.com/janikvonrotz/awesome-powershell

October 5, 2017  4:10 AM

Use CIM cmdlets not WMI cmdlets

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

WMI and CIM seem to cause a LOT of confusion. Its really simple. CIM is an industry standard from DMTF.org. WMI was Microsoft’s implementation of CIM way back in Windows NT days. The complication is that Microsoft had a set of WMI cmdlets in PowerShell v2. In PowerShell v3 they introduced a set of CIM cmdlets that work differently. The bottom line is you should use CIM cmdlets not WMI cmdlets.

Here’s three reasons  why you should use CIM cmdlets not WMI cmdlets.

Reason 1: the WMI cmdlets are deprecated and won’t have much if any further work done on them. The WMI help files tell you to use the CIM cmdlets! PowerShell v6 doesn’t have the WMI cmdlets – just the CIM cmdlets.

Reason 2: the CIM cmdlets use WS-MAN for remote access. The WMI cmdlets use DCOM which is blocked by default on Windows firewall. Using the CIM cmdlets makes your remoting easier.

Reason 3: The CIM cmdlets do some extra work for you. For instance finding the time a machine was started:

PS> Get-WmiObject -Class Win32_OperatingSystem | select LastBootUpTime


Read it left to right = Year = 2017; Month = 10; day = 01; hour = 11; minute = 35; second = 46.966894 with a +60 minute offset for daylight saving time.

That date format is painful to deal with so you convert it. the nice PowerShell Team added a conversion method for you

PS> Get-WmiObject -Class Win32_OperatingSystem | select @{N=’LastBootUpTime’; E={$_.ConvertToDateTime($_.LastBootUpTime) }}

01/10/2017 11:35:46

It works great but means you have to do more work.

By contrast the CIM cmdlets do the work for you

PS> Get-CimInstance -ClassName Win32_OperatingSystem | select LastBootUpTime

01/10/2017 11:35:46

On a slightly off topic point anyone thinking of attending the PowerShell Summit next April will be aware that we have an Iron Scripter event planned for the last day. IF access to WMI classes is required anyone using the WMI cmdlets instead of the CIM cmdlets will be marked down. You have been warned 🙂

October 1, 2017  9:06 AM

PowerShell templating systems

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Code reuse is a big plus when you’re developing lots of scripts. The ability to create templates for your code can also save you lots of time – for instance when advanced functions first appeared I create myself a template the included all of the validation checks, the code to switch functionality based on parameter sets and code to handle –whatif and –confirm.  Things have moved on since then and there are a number of PowerShell templating systems.

Plaster – https://github.com/PowerShell/Plaster

PSScaffold – https://github.com/RedeployAB/PSScaffold

PowerShell template – https://github.com/kayasax/PowershellTemplate

Check them out – one or more maybe the thing you need or they may inspire you to create something better.


September 30, 2017  3:30 PM

PowerShell Trim

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

PowerShell Trim – no its not a new slimming fad. Trimming is the act of removing characters – usually white space – from the beginning or end of a string.

You have three methods on the String class you can use


PS> $str = ” abcdefghijk ”
PS> $str.TrimStart()
PS> $str.TrimEnd()
PS> $str.Trim()

You can also trim specific characters from the beginning or end of a string

PS> $str = “.,:abcdefghijk:,.”

PS> $tc = [char]’.’, [char]’,’, [char]’:’

PS> $str.TrimStart($tc)
PS> $str.TrimEnd($tc)
PS> $str.Trim($tc)

You should now be able to handling any string trimming required in your code

September 30, 2017  1:45 PM

PowerShell editors

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

PowerShell works great when you use it interactive;y but at some point you’re likely to want to write substantial pieces of code – scripts or functions – for which you’ll need an editor. This is my take on PowerShell editors.

There are PowerShell add-ins for Visual Studio – one of the best is PowerShell Tools by Adam Driscoll: https://marketplace.visualstudio.com/items?itemName=AdamRDriscoll.PowerShellToolsforVisualStudio2017-18561

If you’re working with Visual Studio already and need to add PowerShell to your project then this is a good option. if you’re only creating PowerShell code then Visual Studio has too much overhead.

PowerShell ISE (Integrated Scripting Environment) was introduced with PowerShell v2. Its gone through a number of updates with subsequent versions of PowerShell. It’s the tool I normally use. It supplies access to the debugger and happily runs across a number of PowerShell runspaces. You can use it to run and debug code on remote machines.

ISEs drawback is that its Windows only and it isn’t part of PowerShell v6.

As far as I can tell all of the editor related development work is going into VSC (Visual Studio Code) https://code.visualstudio.com/. VSC is a lightweight editor like ISE but can also work with a large number of other languages. You can tailor VSC by only downloading those extensions you need. I have extensions for PowerShell, JSON, XML MSSQL, markdown and Docker among others.

VSC has good debugging tools. I do miss the ability to run selected lines of code like ISE. I’ll be sticking with ISE for demos for now.

VSC has the advantage that its available for Windows and Linux (and mac) so you can use the same editor cross platforms if need be.

There are other products you can consider. ISE Steroids (from the PowerShell studio) is a great add-in for ISE. Sapien have tools such as PowerShell Studio and Primal Script. Idera have PowerShell Plus. These and other tools have to be paid for.

So what editor should you use.

ISE is great for Windows only environments. If you need cross-platform or multi-language consider VSC.

I use ISE but I’m increasingly turning to VSC as that seems to be getting the development effort and evolving very quickly with updates most months.


September 30, 2017  9:20 AM

Call for topics closing 1 October

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The call for topics is closing 1 October at 23:59 GMT. We’ve had a fantastic set of submissions. Creating an agenda for the 2018 Summit is going to be very difficult because we’ve had so many fantastic sessions submitted and I don’t have enough slots to  take them all.

The call for topics is hosted by papercall.io – highly recommended – and the cut off is automatic.





Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: