How Hard Are You Working?

031313_1656_WordBlogDem1.pngRecently in the PowerShell community on Google Plus, there was a discussion about software for creating graphical PowerShell scripts. This is a discussion I’ve seen many times over the years and extends beyond something to create graphical PowerShell tools. Sadly, the root issue of this discussion centers on the mind-set of today’s IT Pro, and probably by extension to management of these professionals. Here’s my two cents on the subject based on years of experience as an IT Pro and my involvement with the IT Pro and PowerShell communities over the last 10 years or so.

The general argument is that an IT Pro wants a tool to help them do their job but don’t want to spend that much (if any money). In PowerShell this discussion most likely is centered on products from SAPIEN Technologies. [Disclaimer: While I have worked for SAPIEN in the past, and am a fan of their products, this article is my unsolicited opinion alone.] Compared to other products in the market, SAPIEN solutions appear to be expensive when looking at the total in your shopping cart. But it could be application “Great Balls of Awesomeness” from Vandelay Industries. It doesn’t really matter.

What often happens is that the IT Pro says while they like product X, it really needs to cost half as much or they are looking for a free alternative. Don’t get me wrong, I like free as much as the next professional, but realize you are still “paying” something. Often you are “paying” in the way of limited features and/or limited (if any) support. Sure, they may get the job done, but do they accomplish everything you need? How often is the product upgraded? What can you do when you run into a problem?

The larger issue in my opinion, is that IT Pros have been “trained” to get by with very little. Whether it is a piece of software that can make them more productive or a little training. If an IT Pro wants something, they often need to find an inexpensive, usually free, alternative. Contrast this with what I’ve seen and heard about in the developer community. If a developer needs a piece of software for their job or need to get some training it seems to me they have a much easier task. I don’t mean to pit IT Pro against Developer. I’m merely pointing out that there appear to be cultural differences which I can only attribute to respective management layers. Perhaps, in many organizations developers are seen as adding value and IT Pros are a fixed cost. I can only hope that as the DevOps culture spreads, this will change.

Since I can’t do anything about your corporate culture let’s look at this from another angle. My Mom always said, “You get what you pay for” and I’ve generally found that to be true. Yes, Great Balls of Awesomeness or PowerShell Studio may command a larger asking price than you think you want to spend. In this case you need to take the time to calculate your own ROI. I’m amazed at how many IT Pros (and probably managers) look at the dollar sign and immediately dismiss it as “too expensive”. Don’t be that person.

In terms of software, most products offer a free trial period. In SAPIEN’s case it is 45 days. And that is usually 45 days of complete functionality. Take advantage of it. Install the product and explore all of the features. Are there features you would take advantage of that perhaps you weren’t aware of at first glance? What features do you not need. If the latter list is greater than the first, then this probably isn’t the right product for you. But then take it a step further. I’m assuming you are looking at a product to solve some problem or task. Let’s take PowerShell Studio as an example. While it is a very feature rich program, many PowerShell pros are looking at it to help create graphical scripts.

First, create a simple graphical PowerShell script manually or using other free or less expensive tools. How long did it take and what is the quality of the result? Repeat the process using PowerShell Studio. Compare how long it tool and the quality of the end result. In this scenario, based on my own experience I’m betting you could easily spend 4 hours working on a script manually yet accomplish the same result with PowerShell Studio in about an hour. Now do the math. To keep the numbers easy let’s say your time is worth $50 an hour. This means you spent $200 creating something manually. Using PowerShell Studio only cost you $50 or a savings of $150. Rounding up you spent $500 for the product and support. By the 3 or 4th script the product has paid for itself. Plus you now have 3 hours to devote to something else! While I was using PowerShell Studio as an example you plug in any product.

But I don’t want you to take my word for it. Take the time to do your own research. Come up with hard numbers especially in dollars or euros or whatever. If you don’t take the time to recognize the value to your work, you are probably working much harder than you need. This type of ROI testing should also make it an easier “sell” to management.

IT Pros have long shown a reluctance or inability to spend money for tools and services that can make them more productive and save the company money. This is something that needs to change. I hope you’ll do your part.

So…am I totally out of touch with reality? What do you think? I hope you’ll let me know

Verbose or Debug?

This morning there was some discussion on Twitter about when to use Write-Verbose and when to use Write-Debug. They both can provide additional information about what your script or function is doing, although you have to write the code. Typically, I use Write-Verbose to provide trace and flow messages. When enabled, it makes it easier to follow what the script is doing and often the messages include variable information. Write-Debug is helpful for providing detailed debug messages, but it also has the effect of turning on debuggging when you include it.

Here’s a sample script that uses both cmdlets.

[cc lang=”PowerShell”]

#requires -version 2.0

[cmdletbinding()]
Param([string]$computername=$env:computername)

$start=Get-Date
Write-Verbose “Starting $($myinvocation.mycommand)”
Write-Debug “`$computername is $computername”
Write-Verbose “Connecting to $computername”

Try {
Write-Debug “Trying WMI”
$cs=get-wmiobject -class win32_computersystem -ComputerName $computername -errorAction Stop
}
Catch {
Write-Debug “Exception caught”
Write-Warning (“Failed to get WMI information from $computername. {0}” -f $_.Exception.Message)
}

if ($cs) {
Write-Verbose “Processing Results”
Write-Debug ($cs | Select * | Out-string)
$cs | Select Model,Manufacturer
}
$end=Get-Date
Write-Debug (“Total processing time {0}” -f ($end-$start).ToString())
Write-Verbose “Ending $($myinvocation.mycommand)”
[/cc]

The script can use the common -Verbose and -Debug common parameters because I include the [cmdletbinding()] attribute. You don’t need to define the parameters. When I run the script normally it runs as expected.

[cc lang=”DOS”]
PS S:\> .\debugdemo.ps1

Model Manufacturer
—– ————
Qosmio X505 TOSHIBA
[/cc]

When I use -Verbose, all the Write-Verbose commands “work”.

The -Debug parameter does the same thing for Write-Debug, but it also turns on debugging:

Not only do I get the Write-Debug messages, but I get a prompt for every command. I can drop into the debug prompt using the Suspend option and look at variables or run any other PowerShell commands. Some 3rd party script editors, like PrimalScript, also take advantage of Write-Debug messages. I can load the script into the editor and run it with Debug turned on (F7 or F5) and the debug messages show in the Debug window.

This ability to step through a script is very handy, but often (personally) I just need to see where I’m at in the script and Write-Verbose suffices. As you see you can have both types of commands, and you can certainly run the script with both parameters. One last note, both cmdlets require that the message be a string. When I want to write objects using either Write-Debug or Write-Verbose, I use expressions like this:

[cc lang=”PowerShell”]
Write-Debug ($cs | Select * | Out-string)
[/cc]

I encourage you to include Verbose/Debug messages from the very beginning of your script development. You only see the messages when you use the appropriate parameter. It may seem like a lot of work up front, but when the time comes to debug or trace a problem, you’ll realize it was time well spent.

Friday Fun Add Scripting Signing to the ISE

Today’s fun involves adding a menu item to the PowerShell ISE to make it easy to sign your scripts. I’m not going to go into the details about getting and installing a code signing certificate. I also assume you only have one installed. You can get this certificate by seasrching the CERT: PSDrive.

[cc lang=”PowerShell”]
PS S:\> dir cert:\CurrentUser\My -CodeSigningCert

Directory: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint Subject
———- ——-
6372DB82AEB690C620E45675C464254FD58FAA97 CN=Jeffery Hicks
[/cc]

To sign a script use the Set-AuthenticodeSignature cmdlet specifying the file and certificate. With these two pieces of information I wrote a function to be used in the ISE that signs the currently active script.

[cc lang=”PowerShell”]
Function Sign-ISEScript {

Param()

Set-StrictMode -Version Latest

#get the certificate
$cert=get-childitem -Path cert:\currentuser\my -CodeSigningCert
if ($cert) {

#save the file if necessary
if (!$psise.currentfile.IsSaved) {
$psise.CurrentFile.Save()
}

#if the file is encoded as BigEndian, resave as Unicode
if ($psise.currentfile.encoding.encodingname -match “Big-Endian”) {
$psise.CurrentFile.Save([Text.Encoding]::Unicode) | Out-Null
}

#save the filepath for the current file so it can be re-opened later
$filepath=$psise.CurrentFile.FullPath

#sign the file
Try {
Set-AuthenticodeSignature -FilePath $filepath -Certificate $cert -errorAction Stop
#close the file
$psise.CurrentPowerShellTab.Files.remove($psise.currentfile) | Out-Null

#reopen the file
$psise.CurrentPowerShellTab.Files.add($filepath) | out-null
}
Catch {
Write-Warning (“Script signing failed. {0}” -f $_.Exception.message)
}

} #if code cert found

else {
Write-Warning “No code signing certificate found.”
}
} #end function
[/cc]

The function saves the script if it needs to be so that it can be properly signed. The other check I have to make is the file encoding. By default when you create a new script in the ISE, the encoding is set to Big-Endian. Unfortunately, you can’t sign scripts with this type of encoding so if the encoding is Big-Endian, the file gets saved as a Unicode file.

[cc lang=”PowerShell”]
if ($psise.currentfile.encoding.encodingname -match “Big-Endian”) {
$psise.CurrentFile.Save([Text.Encoding]::Unicode) | Out-Null
}
[/cc]

Now we’re ready to sign the script. But first I grab the full path and save it to a variable because after I sign the script I want to close the file and re-open it so you can see that it has been signed.

[cc lang=”PowerShell”]
#save the filepath for the current file so it can be re-opened later
$filepath=$psise.CurrentFile.FullPath

#sign the file
Try {
Set-AuthenticodeSignature -FilePath $filepath -Certificate $cert -errorAction Stop
#close the file
$psise.CurrentPowerShellTab.Files.remove($psise.currentfile) | Out-Null

#reopen the file
$psise.CurrentPowerShellTab.Files.add($filepath) | out-null
}
[/cc]

Once the function is loaded in the ISE, I could run it any time from the command prompt to sign the current file. But I add the script file to my ISE profile and then insert a menu item.

[cc lang=”PowerShell”]
#this goes in my ISE profile
. c:\scripts\Sign-ISEScript.ps1

$psISE.CurrentPowerShellTab.AddOnsMenu.submenus.Add(“Sign Script”,{Sign-ISEScript},$null) | Out-Null
[/cc]

Now I have a menu choice under Add-Ons for “Sign Script”. I can click it and the current file will be signed, closed and reopened. If you edit the file again, don’t forget you’ll need to resign the script. Commercial editors like PrimalScript can be configured to automatically sign scripts whenever they are saved. The ISE is much more limited.

Still, I hope you can have some fun with this and maybe even pick up a PowerShell tidbit or two.

Download Sign-ISEScript.ps1.

Get Your Free Scripting Toolkit

If you were at this year's TechEd event in New Orleans, I hoped you dropped by the SAPIEN Technologies booth and picked up your free Scripting Toolkit. What's that you say? Check it out on the SAPIEN blog and then download your free copy.

Putting the Squeeze on Files with PowerShell

My December Mr. Roboto column is now online This month’s tool is a PowerShell WinForm script that uses WMI to compress files. I used PrimalForms 2009 to build the graphical interface. The interface is essentially a wizard that lets you build a WMI query to find files and compress them. 

captured_Image.png

Results can be logged to a CSV file or you can merely list the files that match the search criteria. Here’s a code excerpt.


The script has (I think) a nice example of providing popup help. Download SearchSqueeze.zip

Thanks to Wes Stahler for being such a willing lab rat.