Use CIM cmdlets not WMI cmdlets

WMI and CIM seem to cause a LOT of confusion. Its really simple. CIM is an industry standard from 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 Smile

Posted in PowerShell and CIM | 3 Comments

PowerShell templating systems

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 –

PSScaffold –

PowerShell template –

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

Posted in Powershell | Leave a comment

PowerShell Trim

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

Posted in Powershell | Leave a comment

PowerShell editors

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:

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) 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.

Posted in Powershell | 1 Comment

Call for topics closing 1 October

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 – highly recommended – and the cut off is automatic.


Posted in Powershell, Summit | Leave a comment

DSC–the future?

I was incredibly excited when I first saw DSC – it was in April 2013 as a special MVP only preview at the first PowerShell Summit – as a work in progress. Since that time my excitement has waned to the point that I now ask DSC – the future?

Looking at the PowerShell Team announcement about the introduction of DSC core –

I have to question if a complete new version of DSC is worth my time investigating especially when backward compatibility isn’t guaranteed.

Don Jones has question where DSC is going –

Overall, I’d say that DSC has had a mixed success since its introduction due to changes and the difficulty around preforming some activities. The integration with Azure hasn’t been smooth.

Is it time to look at another configuration tool set. Microsoft’s  current rush to embrace Linux may make Chef or Puppet a better option for you. Read the comments on the PowerShell Team announcements to see what other people think about DSC.

Posted in DSC, Powershell | 1 Comment

PowerShell comments

Putting comments into your code has been a long established practice – this is how you do PowerShell comments

A single line comment is indicated by the # symbol

# This is a comment

You can put a comment at the end of a line but not in the middle. Once you’ve added a comment that’s it for the rest of the line

Get-Process    # This is a comment

In ISE and Visual Studio Code comments are shown in green by default

You can also create multi-line comments

This is
a multi-line

Be careful if you use # symbols in file names or other data in PowerShell – you may end up with PowerShell thinking you’ve declared a comment

Posted in Powershell | 1 Comment