Monthly Archives: April 2015

Twitter Reply – Rebel Doesn’t Mean Rebel to Everyone

Twitter Reply to: no link

I saw a recent Twitter #PowerShell post and while I wanted to respond to it on Twitter, I didn’t. I was opposed to what it said, but I didn’t feel it was my place to call anyone out in that fashion. That’s why there isn’t a link above, where they might’ve been otherwise.

The twitter post in which I’m referring indicated that a person was a “rebel” by not using an approved PowerShell verb. I saw the included :P, and that’s fine, but only if the author is joking about the whole thing — I didn’t get that they were.

To use an unapproved verb, especially while knowing you shouldn’t, is everything that PowerShell is trying to stay away from. Part of the success of PowerShell has been the consistency in which it’s been developed by Microsoft, and others. While you might consider yourself a rebel, I consider what you’re doing, a problem.

I will admit, there has been a time or two that I’ve struggled with the best option for my verb, but I’ve always found one. Here’s my recommendation if you are not satisfied with the list of approved verbs: Use an alias; don’t be a “rebel.”

Let’s say I have a function I want to invoke using the name Smack-Yourself, and it looks like this:

Function Smack-Yourself {
    Write-Output -Verbose "I've been smacked!"
}

I can tell you without looking; smack is not an approved verb. We’ll check if it exists anyway.

PS C:\> Get-Verb -Verb Smack
PS C:\>

Nope, this verb hasn’t (yet?) been approved by Microsoft.

Instead of using an unapproved verb, let’s give our function an approved verb and then make an alias we can use instead. There’s no best practice for aliases; name them whatever you want. As far as your function name, please stay consistent and follow the verb dash noun naming convention, using an approved verb.

Set-Alias -Name Smack-Yourself -Value Pop-Yourself

Function Pop-Yourself {
    Write-Output -Verbose "I've been smacked!"
}

In the example above, we’ve used Set-Alias to modify (or create) an alias, called Smack-Yourself. When run, this alias will ultimately execute the Pop-Yourself function, where Pop is an approved verb. Even if the approved verb you choose doesn’t perfectly align with the verb you wanted to use, you can use whatever you want, if you’re using an alias.

Extra – PowerShell Summit North America 2015 [#3]

Read them all here: http://tommymaynard.com/extra-powershell-summit-north-america-2015-0-2015/

Well, I did it; I figured out what sessions I want to attend at next week’s PowerShell Summit North America 2015. It wasn’t easy, and I had to con-tin-u-al-ly remind myself that the sessions are being recorded, and that I’ll have an option to watch the ones I missed at a later time.

The sessions I selected are going to offer me the ability to hear various PowerShell big names speak. I’m mean seriously, when this event is over, I’ll be able to say that I’ve heard Don Jones and Jeffrey Snover speak (again), Mike Robbins (who recently followed me on Twitter — what!?), Dave Wyatt, Jeffery Hicks, Lee Holmes, Richard Siddaway and June Blender — the list goes on. That’s an accomplishment for me, and I’m not even doing anything but sitting and listening. It’s hardly any work on my part, but I’ll do it.

Here’s a screen capture of the sessions I plan to attend. While the speaker is important, the content is as well. We’re just days away, now, so I’ll be back to write more soon.

MyAgendaReduced85

Extra – PowerShell Summit North America 2015 [#2]

Read them all here: http://tommymaynard.com/extra-powershell-summit-north-america-2015-0-2015/

I cannot believe how quickly April has come. The last, and first, time I decided to write about the upcoming PowerShell Summit North America 2015, it was 55 days away. Today, it’s only 9 days away — well, that’s exciting! I took a command from my previous post about this topic and wrapped it in a function. While I may never use it again, here it is: proof that this event is ridiculously close — as if you needed a function to tell you this.

Function Get-TMDaysUntilPSSummit2015 {
    [CmdletBinding()]
    Param ()

    Begin {
    } # End Begin.

    Process {
        Write-Output -Verbose "$((New-TimeSpan -Start (Get-Date) -End 4/20/2015).Days) Days"
    } # End Process.
} # End Function

Get-TMDaysUntilPSSummit2015
9 Days

As of recent, we now have a downtown venue for the meet-and-greet Sunday night. While all the details haven’t been worked out, I supposedly have a ride there with a PowerShell MVP — how cool is that? The sessions have been updated, too. I’m suddenly second guessing all the sessions I should attend.

The Scripting Wife has been adding to the excitement with a recent series of posts about the summit’s speakers, which I’ve linked below. I’ve read all of these, and they’re great. While I haven’t spoken to anyone but Don Jones and The Scripting Guy and Wife in person (and I doubt they remember that anyway), I am quite aware of the big names in PowerShell. I read their blogs and articles; I read their posts on forums and social media. There’s going to be a ridiculous amount of PowerShell talent at this event.

Meet the PowerShell Summit 2015 Speakers #1
Meet the PowerShell Summit 2015 Speakers #2
Meet the PowerShell Summit 2015 Speakers #3
Meet the PowerShell summit 2015 Speakers #4
Meet the PowerShell summit 2015 Speakers #5

While I’m short on things to say today, I will reiterate that I’m so excited to get this summit underway. On that note, I should mention that I am very grateful to my employer for this opportunity, and for my family, to help keeps things in order while I’m gone. Of course, my wife pretty much owns that anyway.

Back to my employer: I want to note that I’m grateful working in an environment where my desire to know and implement PowerShell is supported. I’m pleased that they understand the importance of PowerShell and automation, and that having me attend this summit is seen as beneficial.

Give a Parameter a Default Value

Part II: http://tommymaynard.com/quick-learn-give-a-parameter-a-default-value-part-ii-2015/

If you’re into Windows PowerShell, then you probably think a little like me. You want to do things fast, and efficiently. There’s a reason we pound out commands and write scripts: we want to make the most of our time, and PowerShell let’s us do that. With that in mind, I decided I should modify a cmdlet I often use, so that using it takes less time, by default.

The Test-Connection cmdlet does for us what ping always has. It sends ICMP request packets to a remote computer or device. If the remote computer or device sends us a reply, then we know the device is up. It should be stated, that ICMP replies can be restricted so that a computer or device that is up, may not reply. Although I’ve opted to use Test-Connection for my example, this concept can be used with any number of other cmdlets and their parameters.

Let’s start by taking a look at the default output of the Test-Connection cmdlet. By default, Test-Connection will ping a given computer four times. If I were checking for latency, four replies would probably be better than one, but because I just want to know if the computer is up or down, a single reply is suitable.

PS C:\> Test-Connection -ComputerName bing.com

Source        Destination     IPV4Address      IPV6Address                              Bytes    Time(ms)
------        -----------     -----------      -----------                              -----    --------
TOMMYMAYNA... bing.com        204.79.197.200                                            32       14
TOMMYMAYNA... bing.com        204.79.197.200                                            32       13
TOMMYMAYNA... bing.com        204.79.197.200                                            32       14
TOMMYMAYNA... bing.com        204.79.197.200                                            32       13

This cmdlet includes a -Count parameter, and so I could have used that, as -Count 1, so that my computer only sent a single packet. But remember, I want be fast and efficient — I don’t want type more to see less. I want to type the same and make things faster. To accomplish this, what I’ll do is change the default behavior of this command to only send one packet. These means I’ll need to make use of the $PSDefaultParameterValues variable.

The $PSDefaultParameterValues variable stores any modifications to the default values of any of our cmdlet’s parameters. Since I don’t have any modified default values, the variable has nothing to return.

PS C:\> $PSDefaultParameterValues
PS C:\>

In the example below, we’ll use the Add() method to add a key/value pair to the variable. The keys are anything in the Name property, and the values are anything in the Value property. There is a one-to-one ratio between keys and values. These are also referred to as hash tables, associative arrays, or a dictionary object.

After we’ve added our key/value pair, we’ll try Test-Connection again, as we did in the first example.

PS C:\> $PSDefaultParameterValues.Add('Test-Connection:Count','1')
PS C:\> $PSDefaultParameterValues

Name                           Value
----                           -----
Test-Connection:Count          1

PS C:\> Test-Connection -ComputerName bing.com

Source        Destination     IPV4Address      IPV6Address                              Bytes    Time(ms)
------        -----------     -----------      -----------                              -----    --------
TOMMYMAYNA... bing.com        204.79.197.200                                            32       13

PS C:\>

As we can see, Test-Connection will now only ping a computer one time by default. Now, what happens when I do want to test for latency? I can use the -Count parameter and supply whatever number I want, so long as it’s 1 through 2147483647. Using zero or less, or 2147483648 will not work. I know, I tried.

You can read more information on the about_Parameters_Default_Values page here: https://technet.microsoft.com/en-us/library/hh847819.aspx.