Skip to main content

Posts

Showing posts from March, 2013

Extract a Cmdlet’s Parameters into a Collection with PowerShell

While building a script to help out a reader of this blog, I came up with a handy little cmdlet to retrieve the parameters of a cmdlet and place them into a collection. Function Get-ParameterList {     [ cmdletBinding () ]     Param ( $Cmdlet )         Write-Verbose "== Cmdlet: Get-ParameterList =========================="         Write-Verbose "Parameter - `$Cmdlet: $Cmdlet "         $List = ( get-help $Cmdlet -parameter * |             Select-Object -Property Name |             ForEach -Process { $_ . name})           Write-Verbose "Sending $( $List . count) Items to the pipeline."         Write-Output $List         Write-Verbose "__ End Function: Get-ParameterList ____________________"     <#     .SYNOPSIS     Extracts cmdlet parameters       .DESCRIPTION     Extracts the parameters from a supplied cmdelt and sends then as a collection     into the PowerShell Pipeline.       .PARAMETER Cmdlet     Th

Test your scripts without your profile

Many of you who have taken my PowerShell class may remember that I strongly advocate to not use person aliases in your scripts. They are fine for shell use, but not in scripts. This is for two reasons. The first reason is that they make your scripts less readable to others. These are your personal aliases that no help file exists for.  The second, and most important, is that your scripts are not portable. For someone else to use a script with your custom alias in it, they would have to add to their profile the code to create your alias. If you do utilize aliases, you will want to load a PowerShell session that does not load your profile to test your script prior to delivery. This way you will know for sure if your script is portable or not with regards to aliases.  To add code to make sure the other client as the modules that you need, check out my code for Confirm-Module . To open a PowerShell session without your profile: PowerShell.exe –NoProfile

Writing Event Log Entries with PowerShell

PowerShell contains a cmdlet, Write-EventLog that will allow you to place custom events generated by your scripts into the clients event logs.  One problem that I have had with this approach is that the source that is generating the event log entry needs to be registered with the log you are writing to.  In other words, an extra procedure on each client/server that needs to be completed before the script can be used.  Another option is to use the Windows PowerShell event log itself.  Take a look at this code: Write-EventLog -Source PowerShell -LogName "Windows PowerShell" -EventId 10000 -EntryType Information -Message "This is a test"   Here you can see that we are using the Source of PowerShell with the event log of Windows PowerShell .  The key to using the Windows PowerShell event log for your own purposes is to make sure that you are using event IDs that are unique. Using this code, I was able to get an idea for the Event IDs being used by the Wi

New Way to add Note Properties with PowerShell V3

For those of you who have taken my PowerShell V2 class probably remember the step-by-step exercise that I took you through to help you build a custom object.  In PowerShell V3, we can create a new NoteProperty with a smaller amount of code.  Below is code that creates an object with a single note property. $Obj = New-Object -TypeName PSObject $Obj | Add-Member -MemberType NoteProperty -Name "Value1" -Value 10 Using the Add-Member cmdlet, we declare the member type that we are adding “NoteProperty”. Then we provide it with a name and a value.  In PowerShell V3, two new parameters were added to the Add-Member cmdlet.  They are –NotePropertyName and –NotePropertyValue.  Below is the same object created with this new method. $Obj = New-Object -TypeName PSObject $Obj | Add-Member -NotePropertyName "Value1" -NotePropertyValue 10 If your code will be running on clients or servers using PowerShell V2, do not use this new method.  Take a look

Utilizing PowerShell’s String Manipulation

The System.String object in PowerShell is a very useful object to get to know.  Many times I see Network Admins trying to create a lot of extra code that is not necessary when it comes to manipulating the contents of a string.  Even though I instruct that outputting data as a string is not a good PowerShell process, we need to be able to handle string data as input.  A case in point, what if you need to extract data from the message portion of an event log entry?  To simulate a string with multiple lines, I use this code: $String = "This is a set of data.`n" $String += "It has multiple lines.`n" $String += "I need to extract the name of a computer.`n" $String += "Computer Name: Indy-DC1.`n" $String += "Now, try to extract it." You can see that the string is telling us our objective.  I want to extract the name of the computer, Indy-DC1, from this string. The `n provides for a carriage return.  This is what the stri