Backticks are baaaaaad; don’t do backticks

The voting/judging process has started for event 1 in the 2013 Scripting Games.  What I’m going to be doing over the next few weeks is point out some of the things that I’ve noticed when judging. Some will be good things that I think you should adopt; others will be bad things that you should avoid. There even may be some interesting stuff to get you thinking.

First off is the use of the backtick as a line continuation:

Get-Process | ` sort Handles –Descending

You don’t need a backtick at this point.  The pipe symbol acts as a line continuation marker so the backtick is redundant. All you need to do is this:

Get-Process | sort Handles -Descending

Its the same with commas. You don’t need to do this:

Get-Process | select Name, Id, ` Handles, CPU

because it works without the backtick

Get-Process | select Name, Id, Handles, CPU

You may see backticks used a lot in books but that is an attempt to reduce the width of the code to make it fit the page. We want you to be able to copy the code from the ebook and run it. The alternative is a line continuation marker which you would have to remove.

Bottom line – 99.9% recurring of the time you don’t need backticks as line continuation markers

CIM vs WMI cmdlets-remote execution speed

Following on from my previous post we’ll look at how the two types of cmdlets compare for accessing remote machines.

I used a similar format to the previous tests but was accessing a remote machine.

First off was the WMI cmdlet – using DCOM to access the remote Windows 2012 server

PS> 1..100 | foreach { Measure-Command -Expression{1..100 | foreach {Get-WmiObject -Class Win32_ComputerSystem -ComputerName W12SUS }}
} | Measure-Object -Average TotalMilliseconds

Count    : 100 Average  : 2084.122547 Sum      : Maximum  :
Minimum  : Property : TotalMilliseconds

The CIM cmdlets are similar but apparently a bit slower – probably due to having to build the WSMAN connection and teat it down each time.

PS> 1..100 | foreach { Measure-Command -Expression{1..100 | foreach {Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName W12SUS }} } | Measure-Object -Average TotalMilliseconds

Count    : 100 Average  : 2627.287458 Sum      : Maximum  :
Minimum  : Property : TotalMilliseconds

So what happens is you run the CIM command over a CIM session?

PS> $sess = New-CimSession -ComputerName W12SUS PS> 1..100 | foreach { Measure-Command -Expression{1..100 | foreach {Get-CimInstance -ClassName Win32_ComputerSystem -CimSession $sess }} } |
Measure-Object -Average TotalMilliseconds

Count    : 100 Average  : 877.746649999999 Sum      :
Maximum  : Minimum  : Property : TotalMilliseconds

This removes the setup and tear-down of the WSMAN connection. It suggests that the actual retrieval time for the CIM cmdlets should be reduced to 1749.540808 milliseconds for 100 accesses which is faster than the WMI cmdlets

It looks like the fastest way to access WMI information is across a CIM session. Next time we’ll look at running multiple commands

AD Management in a Month of Lunches– chapter 9 in MEAP

The MEAP for AD Management in a Month of Lunches has been updated with the release of chapter 9 on managing group policies

CIM cmdlets vs WMI cmdlets–speed of execution

One question that came up at the summit was the comparative speed of execution of the new CIM cmdlets vs the old WMI cmdlets.  No of us knew the answer because we’d never tried measuring the speed.

I decided to perform some tests.

This first test is accessing the local machine.  In both cases the cmdlets are using COM.  WMI uses COM and CIM will use COM if a –ComputerName parameter isn’t used.

The results are as follows:

PS> 1..100 |
foreach {Measure-Command -Expression {
1..100 | foreach {Get-WmiObject -Class Win32_ComputerSystem} }
} | Measure-Object -Average TotalMilliseconds

Count    : 100
Average  : 2008.953978
Sum      :
Maximum  :
Minimum  :
Property : TotalMilliseconds

PS> 1..100 |
foreach {Measure-Command -Expression {
1..100 | foreach {Get-CimInstance -ClassName Win32_ComputerSystem} }
} | Measure-Object -Average TotalMilliseconds

Count    : 100
Average  : 2078.763174
Sum      :
Maximum  :
Minimum  :
Property : TotalMilliseconds

So for pure COM access the WMI cmdlets are marginally (3.4%) faster.

What if we use the ComputerName parameter?

PS> 1..100 |
foreach {
Measure-Command -Expression {
1..100 | foreach {Get-WmiObject -Class Win32_ComputerSystem -ComputerName $env:COMPUTERNAME } }
} | Measure-Object -Average TotalMilliseconds

Count    : 100
Average  : 1499.14379
Sum      :
Maximum  :
Minimum  :
Property : TotalMilliseconds

PS> 1..100 |
foreach {
Measure-Command -Expression {
1..100 | foreach {Get-CimInstance -ClassName Win32_ComputerSystem -ComputerName $env:COMPUTERNAME } }
} | Measure-Object -Average TotalMilliseconds

Count    : 100
Average  : 3892.921851
Sum      :
Maximum  :
Minimum  :
Property : TotalMilliseconds

This one surprised me – the WMI cmdlets are 2.5 times faster.  I suspect that is because the CIM cmdlet has to build and then breakdown the WSMAN connection each time.

Next time we’ll look at accessing a remote machine.

Time for D-CRUD?

I was thinking on the plane back from the PowerShell summit about the CRUD activities. They are a concept we have inherited from the database world:

C = Create

R = Read

U = Update

D= Delete

Create, Update and Delete correspond directly to the PowerShell verbs – New,Set and Remove respectively.

The Read action corresponds to the Get verb.

Well sort of.

Get-* is used in two distinct scenarios.  Firstly we know of an object and we we want to read its properties – for example:

Get-Process -Name powershell

We are reading the information about the PowerShell process. That corresponds directly to the Read action in the CRUD paradigm.

However, we also use Get* when we want to Discover the processes that are running:

Get-Process

In which case we are Discovering the processes that are running.

I think its time to update the CRUD concept and make it DCRUD where D stands for discovery.

Scripting Games 2013 have started

The 2013 Scripting Games kicked off during the PowerShell summit.  Event 1 is open and you can submit entries up until 23:59:59 GMT on 29 April 2013.  Voting on the entries starts at at midnight on 30 April.

You can enter and you can vote on the entries.  This is a community games run by powershell.org – all are welcome.

If you haven’t entered yet there is still plenty of time to get you entry in for event 1.  Start by reviewing the information at http://powershell.org/wp/the-scripting-games/

Enjoy and good luck

PowerShell Summit–thank you

I’d like to extend a huge thank you to everyone who attended the PowerShell Summit this last week.  The Summit was a success – in no small part due to you. Your questions, and discussions, are what this is all about.

It was a pleasure meeting you all and I hope to return next year – I hope to see many of you there as well.

PowerShell Deep Dives–another MEAP release

Manning have released another set of chapters in their early access program for PowerShell Deep Dives.

If you have an interest in PowerShell I would strongly urge you to buy a copy. It has chapters from a number of well known PowerShell authors together with some very good material from new authors.  Best of all the royalties are going to charity.

Busy, busy, busy

A very busy time coming up in PowerShell land with the first PowerShell Summit kicking off in just over a week’s time.  The 2013 Scripting Games will also be starting very soon.

I’ll try and post about both of them as time allows

Creating a new disk

I really like Windows Server Core. The concept has come of age in Windows 2012.

I needed to add a new disk to a virtual machine  – that’s easy using the Hyper-V cmdlets. But what about formating the disk.

A module new to Windows 2012 & Windows can be used.  Its the Storage module.  I’ve not had chance, or reason, to play with this module yet. So many cmdlets so little time.

Start with viewing the disks:

PS C:\Users\richard> Get-Disk | ft -a

Number Friendly Name          OperationalStatus Total Size Partition Style
—— ————-          —————– ———- —————
0      Virtual HD ATA Device  Online                120 GB MBR
1      Microsoft Virtual Disk Offline               127 GB RAW

Disk 1 is the new disk so need to initialise it.

PS C:\Users\richard> Initialize-Disk -Number 1 -PartitionStyle MBR

View the disks again

PS C:\Users\richard> Get-Disk | ft -a

Number Friendly Name          OperationalStatus Total Size Partition Style
—— ————-          —————– ———- —————
0      Virtual HD ATA Device  Online                120 GB MBR
1      Microsoft Virtual Disk Online                127 GB MBR

Create a partition on the disk -   -useMaximimSize means use all of the disk for this partition

PS C:\Users\richard> New-Partition -DiskNumber 1 -UseMaximumSize -DriveLetter R

Now view the partitions

PS C:\Users\richard> Get-Partition | ft -a

   Disk Number: 0

PartitionNumber DriveLetter Offset         Size Type
————— ———– ——         —- —-
1                           1048576      350 MB IFS
2               C           368050176 119.66 GB IFS

   Disk Number: 1

PartitionNumber DriveLetter Offset    Size Type
————— ———– ——    —- —-
1               R           1048576 127 GB Logical

And finally format the new disk:

PS C:\Users\richard> Get-Volume | where DriveLetter -eq R | Format-Volume -FileSystem NTFS -NewFileSystemLabel Backup

Confirm
Are you sure you want to perform this action?
Warning, all data on the volume will be lost!
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Y

You get a nice friendly warning (you could bypass using –Confirm $false) and the format happens

You could pipe the cmdlets together to do everything in one pass. Best of all – the cmdlets are WMI based.