Search results for 'app:weblogs' matching tags 'Windows PowerShell' and 'scripting techniques'

Variable Substitution in a PowerShell Script Block

Anonymous — Wed, 22 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about performing variable substitution inside a Windows PowerShell script block.

Hey, Scripting Guy! I am trying to create a command. The command contains variables that I would like to assign prior to creating the command. However, when I get to the script block portion of my code, it does not do the variable substitution for the value the way an expanding string normally works. Can you help me?

—SW

Hello SW,

Microsoft Scripting Guy, Ed Wilson, is here. Last week at the first ever Northern Virginia PowerShell User Group, the Scripting Wife and I found a great little tea shop. I can’t help but thinking about the scone I got there—it was pretty good.

Expanding variable values

One of the really cool things about Windows PowerShell is the expanding strings—I absolutely love them. It surely beats having to do lots of string concatenation like I had to do back in the VBScript days. To illustrate this technique, I assign a string to the value of a variable—in this case, the $a variable. I look at the value contained in the variable. This code is shown here.

PS C:\> $a = "This is a string"

PS C:\> $a

This is a string

Now, by using the expanding string, I can see the value that is contained inside the $a variable. To suppress the variable expansion, I escape it with the grave accent character as shown here.

PS C:\> "The value of `$a is $a"

The value of $a is This is a string

The problem with a script block

If, on the other hand, I want to expand the value of a variable inside a script block, it does not work. This is shown in the code that follows.

PS C:\> $a = "This is a string"

PS C:\> $a

This is a string

PS C:\> $b = {"The value of `$a is $a"}

PS C:\> $b

"The value of `$a is $a"

Solving the problem with variable expansion in a script block

The solution to expanding a variable inside a script block is to do two things. First create the script block as an expanding string. This is shown here:

PS C:\> $a = "This is a string"

PS C:\> $a

This is a string

PS C:\> $b = "The value of `$a is $a"

PS C:\> $b

The value of $a is This is a string

Now, I use the static Create method from the [scriptblock] class. This will create a script block. To do this, I use the [scriptblock] class and then call the Create method while passing the string contained in the $b variable. This is shown here.

PS C:\> [scriptblock]::Create($b)

The value of $a is This is a string

I can confirm that it is in fact a script block by piping the results to the Get-Member cmdlet as shown here:

PS C:\> [scriptblock]::Create($b) | gm

TypeName: System.Management.Automation.ScriptBlock

Name MemberType Definition

---- ---------- ----------

CheckRestrictedLanguage Method void CheckRestrictedLanguage(System.Collection...

Equals Method bool Equals(System.Object obj)

GetHashCode Method int GetHashCode()

GetNewClosure Method scriptblock GetNewClosure()

GetObjectData Method void GetObjectData(System.Runtime.Serializatio...

GetPowerShell Method powershell GetPowerShell(Params System.Object[...

GetSteppablePipeline Method System.Management.Automation.SteppablePipeline...

GetType Method type GetType()

Invoke Method System.Collections.ObjectModel.Collection[psob...

InvokeReturnAsIs Method System.Object InvokeReturnAsIs(Params System.O...

ToString Method string ToString()

Ast Property System.Management.Automation.Language.Ast Ast ...

Attributes Property System.Collections.Generic.List[System.Attribu...

File Property string File {get;}

IsFilter Property bool IsFilter {get;set;}

Module Property psmoduleinfo Module {get;}

StartPosition Property System.Management.Automation.PSToken StartPosi...

Now, the cool thing about this is that I can also store the script block into another variable. This is shown here:

$sb = [scriptblock]::Create($b)

After I have stored the script block into the variable, I can also call any of the methods or properties of the script block. For example, here is the AST:

PS C:\> $sb.Ast

ParamBlock :

BeginBlock :

ProcessBlock :

EndBlock : The value of $a is This is a string

DynamicParamBlock :

ScriptRequirements :

Extent : The value of $a is This is a string

Parent :

It is not horribly exciting in this example, but for more complex code, it is definitely exciting stuff. We have a great Hey, Scripting Guy! Blog post written by Bartek Bielawski, which offers several good ideas for further exploration: Learn How IT Pros Can Use the PowerShell AST.

SW, that is all there is to using variable expansion and substitution in a Windows PowerShell script block. Join me tomorrow when I will talk about way cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

PowerShell Hash Tables that Contain Keywords...hmm...

Anonymous — Tue, 21 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about dealing with Windows PowerShell hash tables that contain keywords. Dude!

Hey, Scripting Guy! I have a problem in that I want to create a hash table from an array. This is easy enough to do, but if the array contains keywords, then everything goes pear shaped. Any ideas?

—GP

Hello GP,

Microsoft Scripting Guy, Ed Wilson, is here. Things are certainly becoming exciting around here. The Scripting Wife and I have been busy planning for TechEd North America in New Orleans and TechEd Europe in Madrid. As it turns out, we will have a Scripting Guys booth in both New Orleans and Madrid. In addition, we are sharing our booth with the folks from PowerShell.org; so, that means that Windows PowerShell people like Don Jones will be there. I am also going to be working with the Windows PowerShell team on a couple of instructor lead labs that (to be quite honest) will absolutely knock your socks off —they are that cool. More details to follow.

Creating a hash table that contains keywords

Well GP, I have never actually run across your problem before. This is because I avoid using Windows PowerShell keywords. I refer to the Help topic, about_Language_Keywords, from time to time to refresh my mind when it comes to reserved keywords.

Note As an aside, I do the same thing for automatic variables. For more information, see about_Automatic_Variables in the Script Center.

Here is the easy way to bring up the about_Language_Keywords Help topic:

help -Category helpfile -Name *keyword*

So, this is all on the preventive side of things. To experiment with this, the first thing I do is create an array that contains a few keywords—in addition to other words. I then use the ForEach command to add the items in the array to a hash table. This technique is shown here:

PS C:\> $a = "key","keys","property","properties","red","blue","green"

PS C:\> $h = @{}

PS C:\> foreach ($wd in $a) {$h[$wd] = $true}

If I look at the hash table that is contained in the $h variable, I see the following:

PS C:\> $h

Name Value

---- -----

red True

property True

green True

keys True

properties True

blue True

key True

So far, so good. But suppose I want to look at the properties or the keys of my hash table. I try the following:

PS C:\> $h.Keys

True

PS C:\> $h.key

True

PS C:\> $h.property

True

PS C:\> $h.properties

True

So I am wondering what the properties really are for this hash table. I can find out by using the Get-Member command as shown here.

PS C:\> Get-Member -InputObject $h -MemberType Properties

TypeName: System.Collections.Hashtable

Name MemberType Definition

---- ---------- ----------

Count Property int Count {get;}

IsFixedSize Property bool IsFixedSize {get;}

IsReadOnly Property bool IsReadOnly {get;}

IsSynchronized Property bool IsSynchronized {get;}

Keys Property System.Collections.ICollection Keys {get;}

SyncRoot Property System.Object SyncRoot {get;}

Values Property System.Collections.ICollection Values {get;}

There really is a property called Keys, and I really cannot seem to access it. So what do I do?

I imagine that I will take a look at the base Windows PowerShell object. To do this, I use the PSBase property. All Windows PowerShell objects have a base object, but most of the time, it is not necessary to fool with it. Here, however, I suspect that I will be able to get past the keys keys kind of thing. Here is the base object:

PS C:\> $h.psbase

IsReadOnly : False

IsFixedSize : False

IsSynchronized : False

Keys : {red, property, green, keys...}

Values : {True, True, True, True...}

SyncRoot : System.Object

Count : 7

Now, I see there is a Keys property on the base object. So I attempt to access it. Here is how I do it:

PS C:\> $h.psbase.keys

red

property

green

keys

properties

blue

key

GP, that is all there is to using PSBase when dealing with hash tables. By the way, I tested this on Windows PowerShell 2.0 and on Windows PowerShell 3.0, so you should be safe to use this technique. Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Add Power and Functionality to the PowerShell ISE Part 2

Anonymous — Sun, 19 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, adds more power and functionality to the Windows PowerShell ISE with a modified module.

Microsoft Scripting Guy, Ed Wilson, is here. This is Part 2 of a two part series where I edit my Windows PowerShell ISE module and add five new functions. The five new functions are:

Add-RemarkedText
Remove-MarkedText
Edit-Module
Import-EveryModule
Switch-OutLineView

Yesterday, in Add Power and Functionality to the PowerShell ISE Part 1, I talked about the Add-RemarkedText and the Remove-MarkedText functions. Today I am going to talk about the remaining three functions.

The Edit-Module function

The Edit-Module function is a function that I have wanted to write for a long time. The scenario goes like this: I am in the Windows PowerShell ISE working on a script. I realize I want to add or to edit something to an installed Windows PowerShell module. So I have to click around and find the module, and then open it in the Windows PowerShell ISE so I can check something or edit something in the module.

Granted, it is not a huge problem, but it does slow things down a bit. Slow no longer—not with my Edit-Module function. To use it, all I need to do is type Edit-Module (em is an alias), and provide enough of the module name to distinguish it to Windows PowerShell. Yes, this function uses wildcard characters. For example, if I want to edit my PowerShellIseModule.psm1 file, I can type all of that, or I can just type PowerShell* (on my system) to gain access to the file. This technique is shown here:

Here is the complete Edit-Module function:

Edit-Module

Function Edit-Module

{

.Synopsis

This opens a module stored in the $env:PSModulePath location on a new tab in ISE

.Description

This function uses Get-Module to retrieve a module from $env:PSModulePath and then

it opens the module from that location into a new tab in ISE for editing. Wildcard

characters that resolve to a single module are supported.

.Example

Edit-Module PowerShellISEModule

Edit-Module PowerShellISEModule opens the PowerShellISEModule into a new tab in the

ISE for editing

.Example

Edit-Module PowerShellISE*

Edit-Module PowerShellISE* opens the PowerShellISEModule into a new tab in the

ISE for editing by using a wild card character for the module name

.Parameter Name

The name of the module. Wild cards that resolve to a single module are supported

.Notes

NAME: Edit-Module

AUTHOR: ed wilson, msft

LASTEDIT: 05/16/2013 18:14:19

KEYWORDS: Scripting Techniques, Modules

HSG: WES-5-18-2013

.Link

Http://www.ScriptingGuys.com

#Requires -Version 2.0

Param($name)

ISE (Get-Module -ListAvailable $name).path

} #end function Edit-Module

Importing every module

Yes, there are times when I need to import every module in Windows PowerShell. I used to type the following command:

Get-Module –ListAvailable | Import-Module

Even with aliases such as gmo and ipmo, the command got a bit tedious. So I finally decided to quit typing that command by creating my Import-EveryModule function. The previous code is the gist of the function,—he remainder is the gravy. Here is the complete function:

Import-EveryModule

Function Import-EveryModule

{

.Synopsis

This imports all modules from the $env:PSModulePath

.Description

This function imports all modules from $env:psmodulepath

.Example

Import-EveryModule

Import-EveryModule imports all modules from $env:psmodulepath

.Notes

NAME: Import-EveryModule

AUTHOR: ed wilson, msft

LASTEDIT: 05/16/2013 18:24:26

KEYWORDS: Scripting Techniques, Modules

HSG: Wes-5-18-2013

.Link

Http://www.ScriptingGuys.com

#Requires -Version 2.0

Get-Module -ListAvailable |

Import-Module -Force

} #end function Import-Everymodule

To make it easier to call this useful bit of code, I create an alias iem for Import-EveryModule.

Toggling the Outline view in the Windows PowerShell ISE

The last function I want to talk about is the Switch-OutlineView function. What this function does is toggle the Outline view in the current Windows PowerShell ISE script pane. This function is very helpful when working on a long script (such as the 500+ line PowerShellISEModule.PSM1 file). The best way to show this is to show you the script pane with the Outline view set to On:

Now I can expand the Outline view to full code mode by typing Switch-OutlineView in the execution pane (sov is an alias that I created for this).

Here is the complete text of the Switch-OutlineView function:

Switch-OutlineView

Function Switch-OutlineView

{

.Synopsis

This function toggles the outline view in the ISE

.Description

This function toggles the outline view in the ISE. It will expand

or collapse all functions in the current script pane.

.Example

Switch-OutlineView

Switch-OutlineView will either expand or collapse all functions

.Notes

NAME: Switch-OutlineView

AUTHOR: ed wilson, msft

LASTEDIT: 05/16/2013 19:28:37

KEYWORDS: Scripting Techniques, Modules

HSG: wes-5-18-2013

.Link

Http://www.ScriptingGuys.com

#Requires -Version 3.0

$psise.CurrentFile.Editor.ToggleOutliningExpansion()

} #end function switch-outlineview

The revised PowerShellISEModule and profile is available via the Scripting Guys Script Repository: Windows PowerShell ISE Profile and Modules.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Add Power and Functionality to the PowerShell ISE Part 1

Anonymous — Sat, 18 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, begins a revision of his Windows PowerShell ISE Module by adding five new functions.

Microsoft Scripting Guy, Ed Wilson, is here. I decided to block off the weekend to work on my Windows PowerShell ISE module. There are several things that I want to add to it because the “annoyance” factor has finally caught up with me. In fact my criteria, when a repetitive task gets to the point that it annoys me, I will write a bit of code and solve the annoying problem. I have a list of five functions that I want to write and add to my Windows PowerShell ISE module. Here are the functions I want to add:

Add-RemarkedText
Remove-MarkedText
Edit-Module
Import-EveryModule
Switch-OutLineView

So after I make a pot of Gunpowder Green Tea with jasmine, lemon grass, and a half spoonful of spearmint, I head back to my office, and my laptop is busy blaring Willie Nelson. I look over at the Scripting Wife and say, “I thought I was playing Mott the Hoople when I left. What happened?”

The Scripting Wife said, “You shouldn’t have left your computer unattended.” I guess she has a point, after all. Today I am going to talk about the first two functions: Add-RemarkedText and Remove-MarkedText. Tomorrow I will talk about the other three functions.

Comment (remark) out a block of selected script code

When I have a block of code that I want to comment (or remark) out, I generally use the Windows PowerShell 2.0 block quote feature of the <# to open the comment and #> to close the comment. This technique is shown here.

"this is my code"

"that I want to comment (remark) out"

"for now"

The problem with this is that one way I troubleshoot my scripts is by commenting out sections of my code. In the Windows PowerShell ISE, I would like to be able to use the mouse (or keyboard shortcuts) to select a block of code and then to comment it out. Using the <# and #> seems to be a bit cumbersome for me.

Note If I am going to make major changes to a script, I use my Copy-ScriptToNewTab function, which is already in my Windows PowerShell ISE module.

My solution for this dilemma is my new Add-RemarkedText function. To use it, I simply select a portion of the code in the current tab in the Windows PowerShell ISE, and in the command pane, I type Add-RemarkedText. This is shown in the image that follows.

When the Add-RemarkedText function runs, the selected code is now commented (remarked) out, and it will not execute when the script runs. The commented section is shown in the image that follows.

Here is the complete Add-RemarkedText function.

ADD-RemarkedText function

Function Add-RemarkedText

{

.Synopsis

This function will add a remark # character to beginning of line

.Description

This function will add a remark character # to selected text in the ISE.

These are comment characters, and is great when you want to comment out

a section of PowerShell code.

.Example

Add-RemarkedText

adds the comment / remark character to beginning of each selected line

.Notes

NAME: Add-RemarkedText

AUTHOR: ed wilson, msft

LASTEDIT: 05/16/2013

KEYWORDS: Windows PowerShell ISE, Scripting Techniques

HSG: wes-5-18-13

.Link

Http://www.ScriptingGuys.com

#Requires -Version 2.0

$text = $psISE.CurrentFile.editor.selectedText

foreach ($l in $text -split [environment]::newline)

{

$newText += "{0}{1}" -f ("#" + $l),[environment]::newline

}

$psISE.CurrentFile.Editor.InsertText($newText)

} #End function add-remarkedtext

Removing a commented section of code

After I have remarked out a portion of code, and I have completed my troubleshooting/testing scenario, it is time to remove the comments. In the past, this meant using the down arrow and the delete key, and hoping the mind numbing repetition did not lull me to sleep and cause me to delete a critical portion of the script.

With my Remove-RemarkedText function, this is no longer a problem. First I highlight (select) the commented out portion of the script, and then in the execution pane of the Windows PowerShell ISE, I type Remove-RemarkedText (rr is an alias). This technique is shown in the following image.

When I press ENTER, the comment character (remarked out code) is removed as shown here:

Keep in mind that the code is still selected, and you should click away to remove the selection to protect yourself from accidently deleting the section of your script.

Here is the complete text of the Remove-RemarkedText function.

Remove-RemarkedText

Function Remove-RemarkedText

{

.Synopsis

This function will remove a remark # character to beginning of line

.Description

This function will remove a remark character # to selected text in the ISE.

These are comment characters, and is great when you want to clean up a

previously commentted out section of PowerShell code.

.Example

Remove-RemarkedText

Removes the comment / remark character to beginning of each selected line

.Notes

NAME: Add-RemarkedText

AUTHOR: ed wilson, msft

LASTEDIT: 05/16/2013

KEYWORDS: Windows PowerShell ISE, Scripting Techniques

HSG: wes-5-18-13

.Link

Http://www.ScriptingGuys.com

#Requires -Version 2.0

$text = $psISE.CurrentFile.editor.selectedText

foreach ($l in $text -split [environment]::newline)

{

$newText += "{0}{1}" -f ($l -replace '#',''),[environment]::newline

}

$psISE.CurrentFile.Editor.InsertText($newText)

} #End function remove-remarkedtext

Join me tomorrow when I will complete my discussion of the other three new ISE functions for my Windows PowerShell ISE module. Tomorrow I will also share the link to the Windows PowerShell ISE module project in the Scripting Guys Script Repository.

Ed Wilson, Microsoft Scripting Guy

I Found This Module—What Do I Do?

Anonymous — Wed, 15 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about how to use a Windows PowerShell module.

Hey, Scripting Guy! I found this module in the Scripting Guys Script Repository. Now what do I do?

—SH

Hello SH,

Microsoft Scripting Guy, Ed Wilson, is here. This morning I have been busy booking travel to Madrid, Spain for TechEd 2013. I will have a booth there with the Scripting Wife. In addition, I will be joining the Windows PowerShell team for their instructor led lab—it will be way cool. Air travel these days is so much fun, I genuinely look forward to each upcoming flight. This includes my flight to TechEd 2013 in New Orleans, where you can also find the Scripting Wife and me. (I am also conducting a Windows PowerShell instructor led lab in the big easy.)

Note This is the fourth part of a multipart series about using Windows PowerShell functions and modules. Prior to reading this blog, you should read the previous posts:

What do I do with a module I find?

Let us suppose that I find a module such as the Windows Update PowerShell Module in the Scripting Guys Script Repository. What do I do with it? Well, the first thing I need to do is to download and to install the module. But this is where things are actually a bit confusing. This is because I can put the module anywhere I want to put it. One of the great things about Windows PowerShell modules is that no installer is required. Most modules, in fact, use a simple copy and paste type of installation (the so-called XCOPY deployment, but you do not need to use XCOPY if you do not wish to do so).

Where do I put the module?

There are two places I can put modules so that Windows PowerShell will automatically recognize them, and will automatically import them. These locations are stored in the PSModulePath environmental variable. From a basic categorization standpoint, one is in my profile/home directory, and the other one is in System32. This output on my computer is shown here.

PS C:\> $env:PSModulePath -split ";"

C:\Users\ed.IAMMRED\Documents\WindowsPowerShell\Modules

C:\Windows\system32\WindowsPowerShell\v1.0\Modules\

It requires admin rights to copy something into the System32 folder, and that is where people sometimes place modules that require admin rights. The problem with this location is that when Windows undergoes servicing, it remotes items from the system folders that it does not know about. This means that your admin type of modules can easily become deleted the next time you run Windows update or apply a service pack.

The problem with storing all modules in my profile/home directory location occurs if I am running as a normal user, and then I need to elevate to an account with admin rights so I can run a module that requires admin rights. My profile/home directory is now a NEW location because I am running as a different user. This makes it painful to navigate back to the old user profile location to launch the module manually.

The answer is simple. Modify the $env:PSModulePath location to include an additional folder—either one on a network, or a folder in an easily accessible location. For example, I have a central data folder that I use to simplify backups (an XCOPY backup, so to speak). I could easily create a central modules folder that is accessible for all users on the computer. This technique is shown here.

PS C:\> $env:PSModulePath = $env:PSModulePath + ';c:\data\modules'

PS C:\> $env:PSModulePath -split ";"

C:\Users\ed.IAMMRED\Documents\WindowsPowerShell\Modules

C:\Windows\system32\WindowsPowerShell\v1.0\Modules\

c:\data\modules

How do I put the module in its location?

Let’s go back to the Windows Update PowerShell Module from the Scripting Guys Script Repository. It is contained in a file called PSWindowsUpdate.zip. I click the PSWindowsUpdate.zip file in the Script Repository, and after I agree to the terms of use, Internet Explorer asks if I want to Open, Save, or Cancel my action. This is shown in the image that follows.

If I select Open, the zipped file opens revealing a subfolder as shown here:

Cool, it seems that all I need to do is to open my module directory and drag the folder from the zipped folder to my module home directory. The problem if I do this is the files in the folder will all be blocked. This is shown in the following image.

I can use Windows PowerShell 3.0 to unblock the files, but it is easier to unblock the files before installation. To do this, save the .zip file, then right-click it to unblock the file prior to extraction. In this way, all the files contained therein are unblocked. However, if I forget to do this, I can use a command such as the following to unblock the files:

PS C:\Users\ed.IAMMRED\Documents\WindowsPowerShell\Modules> gci .\PSWindowsUpdate -Re

curse | Unblock-File

After I copy the unzipped and unblocked Windows PowerShell module files to the module directory, I can import the module and use the cmdlets. Because I am dealing with Windows update, the Windows PowerShell console needs to be elevated. The following error appears if the Windows PowerShell console is not elevated.

After I elevate Windows PowerShell, I use the Import-Module cmdlet to import the module, and I use the Get-Command cmdlet to see what commands are exposed by the module. This is shown here.

Now that I see the commands, I can use them just like any other Windows PowerShell command from any other module. So I can check to see what updates are available via the Get-WUList cmdlet (function) as shown here:

PS C:\> Get-WUList

ComputerName Status KB Size Title

------------ ------ -- ---- -----

EDLT ---H-- KB2694771 5 MB Bing Desktop v1.2

To install an update, I use the Get-WUInstall function, and to hide an update I use the Hide-WUUpdate command. Pipeline support is available.

I can even check to see if a reboot is required as shown here:

PS C:\> Get-WURebootStatus

Reboot is not Required.

SH, that is all there is to using a Windows PowerShell module. Join me tomorrow when I will reveal the 2013 Scripting Games Event 4.

Ed Wilson, Microsoft Scripting Guy

I Found this PowerShell Function—Now What Do I Do? Part 3

Anonymous — Tue, 14 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about combining functions into a single function file, and using them in scripts.

Microsoft Scripting Guy, Ed Wilson, is here. This morning is sort of mellow. It seems as if the clouds are touching the ground, and all sound is suppressed by a thick cloth batten. After seemingly weeks of rain, it is nice to have a not so wet day. I am on the lanai sitting in our porch swing reading my email via Outlook Web Access on my Surface RT. I love the long battery life and the portability of this device, and the fact that it has Windows PowerShell makes it even better.

Note This is the third part of a multipart series about using Windows PowerShell functions and modules. Prior to reading this blog, you should read the previous posts:

If one function is cool, then two are even better

Yesterday in Part 2, I talked about dot sourcing a script that contains a function into the Windows PowerShell console so I could use the function just like it was a cmdlet. Today I want to expand on that idea just a bit by including two functions in a script file. The two functions use WMI to create a similar output to standard CIM functions in Windows 8. The equilivant functions in Windows 8 are Get-Volume and Get-NetAdapter. Here is the content of the two WMI functions:

TwoWmiFunctions.ps1

Function Get-Volume

{

Param($cn = $env:computername)

Get-WmiObject -class win32_volume -ComputerName $cn|

Select-Object driveletter, @{LABEL='FileSystemLabel';EXPRESSION={$_.label}},

filesystem,

@{LABEL="Size";EXPRESSION={"{0:N2} Gigabytes" -f ($_.capacity/1GB) }},

@{LABEL="SizeRemaining";EXPRESSION={"{0:N2} Gigabytes" -f ($_.freespace/1GB) }}

} #end function Get-Volume

Function Get-NetAdapter

{

Param($cn = $env:computername)

Get-WmiObject win32_networkadapter |

Where-Object {$_.netconnectionstatus} |

Select-Object name,

@{LABEL='InterfaceDescription';EXPRESSION={$_.Description}},

@{LABEL='ifIndex';EXPRESSION={$_.Index}},

@{LABEL='Status';EXPRESSION={

If($_.netconnectionstatus -eq 2){"not present"}

If($_.netconnectionstatus -eq 4){"up"}}}

} # end function get-NetAdapter

For ease of use, I have uploaded these functions to the Scripting Guys Script Repository: Two WMI Functions.

Using the function script by dot sourcing it

To dot source the script that contains the two functions, all I need to do is to place a period (dot) at the beginning of the console line, and then use the path to the script that contains the functions. I can then use the functions directly. This is shown here.

. C:\fso\TwoWmiFunctions.ps1

The following image shows dot sourcing the script that contains the two functions and then using the two functions.

Dot source to interop between Windows versions

Lots of people are migrating to Windows 8 on their desktops; but unfortunately for many network administrators, they are forced to interop between Windows 8 and other versions of Windows. One of the things that is great about Windows 8 (and Windows Server 2012 for that matter) are the many CIM functions that wrap WMI classes. These are convenient and easy to use. However, for down-level systems, I still need to use the WMI classes. To avoid really cluttering up a script with a bunch of WMI code, I can use dot sourcing to handle the transition period. Here is an example of how that might work:

if(gcm get-volume){Get-Volume} ELSE {. C:\fso\TwoWmiFunctions.ps1; Get-Volume}

So all I need to do is to use Get-Command to see if the Get-Volume function (available in Windows 8) exists. If it does, I call the Get-Volume command. If the Get-Volume function is not available (because the version of Windows is older than Windows 8), I dot source my TwoWMIFunctions.ps1 script that contains my two functions, and then I call Get-Volume from the dot-sourced script. This makes for a nice transitional bit of code.

Note When you create this sort of transitional function, ensure that the property names are the same. In this way, using one function or the other will also be the same. In my example TwoWmiFunctions.ps1 script, I had to rename several WMI class property names for compatibility.

In the following image, I use the dot-source technique to bring in the script that contains the compatibility functions.

Now What Do I Do? Week will continue tomorrow when I will talk about using a Windows PowerShell module. It is really cool, and you do not want to miss it.

Ed Wilson, Microsoft Scripting Guy

I Found this PowerShell Function—Now What Do I Do? Part 2

Anonymous — Mon, 13 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, continues his discussion about what to do with a Windows PowerShell function.

Microsoft Scripting Guy, Ed Wilson, is here. Last week I did not get a chance to finish answering a question from JB about how to use a Windows PowerShell function.

Note This is the second part of a multipart series about using Windows PowerShell functions and modules. You should read the first blog post, I Found this PowerShell Function—Now What Do I Do? – Part 1 prior to reading this post.

Functions promote code reuse

In the first installment in this series about using functions, I talked about the more traditional technique of copying and pasting the function directly into a script. This works well if you want to write a script. But one of the powerful things about Windows PowerShell is that I do not have to write a script. In fact, the great thing about Andy Schneider’s Set-ScreenResolution function is that he wrote it as a function.

Top ten Windows PowerShell function best practices

Of course, being able to reuse the code depends on a well written function. Here is my top ten list of Windows PowerShell function best practices.

A function should:

Use the standard Verb-Noun naming convention.
Do one thing and do it well.
Return an object.
Incorporate comment-based Help.
Expose parameters instead of using hard-coded values.
Accept piped input if it makes sense for the use-case scenario.
Run and return default information if it makes sense for the use-case scenario (instead of requiring input, or returning an error when it is run without parameters).
Offer parameter aliases for common parameters (for example, CN for ComputerName).
Name parameters in accordance with standard Windows PowerShell cmdlets (for example ComputerName instead of server, laptop, or machine).
Use parameter validation techniques to limit user input.

Note For more information about Windows PowerShell functions, see this collection of Hey, Scripting Guy! Blog posts.

Save the function into a .ps1 script file

So suppose you find a well-written function and you want to be able to use it in the Windows PowerShell console. A well-written Windows PowerShell function will, in fact, act and behave like a Windows PowerShell cmdlet. So bringing it into the Windows PowerShell console will enhance the interactive use experience of Windows PowerShell.

Let’s go back to the Set-ScreenResolution function that I used last week (written by Andy Schneider). I go to the Scripting Guys Script Repository, find the Set-ScreenResolution script and copy it to the clipboard. Now, I paste it into the Windows PowerShell ISE, and I save it with a file name like Set-ScreenResolutionFunction.ps1. Here is the script:

Dot source the script file

When I have the function stored in a script file, I can use the function in my Windows PowerShell console, or even in another Windows PowerShell script. The key to doing this is to store the script file that contains the function in an easily locatable folder. For me, that folder is off the root of drive C (C:\fso). I have used this folder for my scratch folder for over a decade.

Keys to success for using dot sourcing

Save the function into a script file with a similar name to the function.
Save the script file that contains the function in an easily accessed location.
Make sure that the script file contains only the function, and no “entry code” that will automatically launch the function.
Dot source functions into scripts that may have code that changes for ease of update.
Use the syntax: period, space, path to script (<.><space><path>).

To dot source the Set-ScreenResolutionFunction.ps1 script into the Windows PowerShell console, I use the syntax shown here:

. C:\fso\Set-ScreenResolutionFunction.ps1

To call the Set-ScreenResolution function, I type the function name, just like I would do with a regular Windows PowerShell cmdlet. In fact, tab expansion even works. This is shown here:

Set-ScreenResolution -Width 800 -Height 600

This technique is shown in the image that follows.

I can also use this technique in the Windows PowerShell ISE. In the image that follows, I dot source the Set-ScreenResolutionFunction.ps1 script into my script.

Well, that is about all for now. Now What Do I Do? Week will continue tomorrow when I will continue to talk about using Windows PowerShell functions.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Playing with PowerShell's Get-Variable Cmdlet

Anonymous — Sat, 11 May 2013 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, spends some time playing around with the Get-Variable cmdlet.

Microsoft Scripting Guy, Ed Wilson, is here. This morning I am doing something a little different. Instead of drinking English Breakfast tea, I woke up feeling like I wanted Oolong tea instead. So I made a pot of Oolong tea with a spoonful of jasmine buds, a half spoon of peppermint leaves, three juniper berries, and half of a crushed cinnamon stick. It is quite invigorating, without being too overbearing.

Checking the value of a variable

So I am sitting on the lanai in my porch swing, and I just finished checking the email for the scripter@microsoft.com email alias. I received an email asking why I would bother using the Get-Variable cmdlet, when I can simply reference the variable to see the value? The reason is that there are many more things I need to do with variables than simply see the value contained inside the variable. The following example assigns a directory listing to the $dir variable:

$dir = dir -Directory | ? lastwritetime -gt $([datetime]'4/1/13')

To see the value that is contained in the $dir variable, I can type $dir. The command and the output are shown in the image that follows.

Use Get-Variable

I can also do this by using the Get-Variable cmdlet. When use Get-Variable, both the name and the value appear. To return only the value, I group the expression, and get the Value property as shown here:

(Get-Variable dir).value

This command and the associated output are shown in the image that follows.

Use the Variable provider

But there are other ways to retrieve values from Windows PowerShell variables. For example, I can use the Variable provider and access the value from the Windows PowerShell Variable drive. I do this by using the command shown here:

$variable:dir

The command and the output are shown in the following image.

Because the Variable provider creates a PSDrive named Variable, I can use the standard Windows PowerShell cmdlets to work with the variable. For example, I can use Get-Item as shown in this example:

Get-Item -Path Variable:\dir

But if I only want the value of the Dir variable, I need to select the Value property:

(Get-Item -Path Variable:\dir).value

The commands and associated output are shown in the image that follows.

One of the cooler things to do is to use the Get-Content cmdlet to obtain the contents of the variable. When using this technique, only the first value from the array returns. This is shown here:

PS C:\> Get-Content variable:\dir

Directory: C:\

Mode LastWriteTime Length Name

---- ------------- ------ ----

d---- 4/23/2013 12:41 PM fso

Examining the type of a variable

I am sure you know that there are different types of variables in Windows PowerShell. If I use the Get-Variable cmdlet, pipe the results to the Format-List cmdlet, and choose all of the properties, I obtain some pretty interesting information. This is shown here:

PS C:\> Get-Variable dir | fl *

PSPath : Microsoft.PowerShell.Core\Variable::dir

PSDrive : Variable

PSProvider : Microsoft.PowerShell.Core\Variable

PSIsContainer : False

Name : dir

Description :

Value : {fso, fsox, Program Files, Program Files (x86)...}

Visibility : Public

Module :

ModuleName :

Options : None

Attributes : {}

If I take the $dir variable and pipe it to the Get-Member cmdlet, it returns information about the objects that are contained in the variable, and not about the variable itself.

$dir | get-member

The command and output from the command are shown in the image that follows.

To find information about the variable itself, I use Get-Variable to return the variable, and then I pipe the result to the Get-Member cmdlet:

Get-Variable dir | Get-Member

The command and output from the command are shown here.

Finding different types of variables

Unfortunately, this does not return anything about the type of Windows PowerShell variable. So what is the easy way to find the variable type? Use the Get-Variable cmdlet and pipe the returned objects to the Get-Member cmdlet. Next, I select only the TypeName property, and I use the Unique switch to ensure only unique instances return. Here is the command and the results:

PS C:\> Get-Variable | Get-Member | select typename -Unique

TypeName

--------

System.Management.Automation.PSVariable

System.Management.Automation.QuestionMarkVariable

System.Management.Automation.LocalVariable

System.Management.Automation.SessionStateCapacityVariable

System.Management.Automation.NullVariable

When I know the different types of variables, I can use Windows PowerShell to list a particular type of variable. To do this, I pipe the results of Get-Variable to the Where-Object. In my Where-Object filter, I use the PSObject property so I can reference the underlying type. This technique is shown here where I find all variables of the type LocalVariable.

Get-Variable | where {$_.psobject.typenames -match 'local'}

The command and output from the command are shown here.

Join me tomorrow for the exciting conclusion to the Windows PowerShell and Security series by Yuri Diogenes and Tom Schinder. To catch up, read the two previous posts in this series.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Improve Performance When Combining PowerShell Arrays

Anonymous — Sat, 27 Apr 2013 05:00:00 GMT

Summary: Microsoft premier field engineer, Chris Wu, talks about combining Windows PowerShell arrays.

Microsoft Scripting Guy, Ed Wilson, is here. Chris Wu, a Microsoft PFE, is back to share his knowledge. See previous Hey, Scripting Guy! Blog guest posts from Chris.

Here is contact information for Chris:

Twitter: https://twitter.com/chwu_ms
Facebook: https://www.facebook.com/mschwu
LinkedIn: http://ca.linkedin.com/in/mschwu

Take it away Chris…

While teaching a Windows PowerShell workshop, I was asked about how to combine two arrays of different objects (which share one key property) into one that contains objects with properties from both source objects. One real world scenario is to merge information retrieved from Active Directory (a list of Active Directory users and their properties) and Exchange Server (mailboxes).

The current approach by the student is to use two-level loops, which has seen performance issues when source arrays become huge in size (the following code snippet uses dummy data for demonstration purposes).

$ADList = @"

chwu,chwu@microsoft.com,Chris Wu

tst1,,Test User1

tst2,tst2@contoso.com,Test User2

"@ | ConvertFrom-Csv -Header Name,mail,CN

$EXList = @"

chwu,ex1.contoso.com

tst2,ex2.contoso.com

"@ | ConvertFrom-Csv -Header Name,MailServer

$Result = @()

foreach($ad in $ADList) {

$Match = $false

foreach($ex in $EXList) {

if ($ad.Name -eq $ex.Name) {

$Result += New-Object PSObject -Property @{Name=$ad.Name; mail=$ad.mail; CN=$ad.CN; MailServer=$ex.MailServer}

$Match = $true

}

if(-not $Match) {

$Result += New-Object PSObject -Property @{Name=$ad.Name; mail=$ad.mail; CN=$ad.CN}

}

In this post, I will explore several options to improve the performance and cleanness of this code snippet.

The first thing we can do is remove the use of the $Result array, which has two drawbacks:

Every assignment operation will create a new array in memory with data copied from the source, which is inefficient.
It defeats the streaming benefit of the WindowsPowerShell pipeline because it returns all objects as a whole at the end of the processing. A best practice in Windows PowerShell is to emit an individual object whenever it’s ready.

Another performance issue stems from the use of an inner loop to search for a matching record in the second array, which basically multiplies the total number of iterations. We can utilize a hash table for faster lookup. The Group-Object cmdlet offers a convenient AsHashTable parameter that can be used here.

Please be warned that the value portion of each entry is an array of matching records. If we are grouping records by using a property with unique values (such as SamAccountName), those arrays will apparently contains one single element each.

So an enhanced version of the code snippet is like this (with the constructing source arrays removed):

$h = $EXList | Group-Object -Property Name -AsHashTable

$ADList | %{

if($h[$_.Name]) {

New-Object PSObject -Property @{Name=$_.Name; mail=$_.mail; CN=$_.CN; MailServer=$h[$_.Name][0].MailServer}

} else {

New-Object PSObject -Property @{Name=$_.Name; mail=$_.mail; CN=$_.CN}

}

The last (but not the least) idea is to sort both arrays based on the key property (user name) beforehand, then we can pair records in a single iteration. Note that in this particular example, users found in Active Directory is a superset of users in Exchange, so we need a pointer variable to deal with this little quirk.

$ADList = @"

chwu,chwu@microsoft.com,Chris Wu

tst1,,Test User1

tst2,tst2@contoso.com,Test User2

"@ | ConvertFrom-Csv -Header Name,mail,CN | Sort-Object -Property Name

$EXList = @"

chwu,ex1.contoso.com

tst2,ex2.contoso.com

"@ | ConvertFrom-Csv -Header Name,MailServer | Sort-Object -Property Name

$ADList | % {$p = 0} {

if($_.Name -eq $EXList[$p].Name) {

New-Object PSObject -Property @{Name=$_.Name; mail=$_.mail; CN=$_.CN; MailServer=$EXList[$p].MailServer}

$p++

} else {

New-Object PSObject -Property @{Name=$_.Name; mail=$_.mail; CN=$_.CN}

}

The last two snippets perform much better than the original one, but which one is faster remains a question (I haven’t tested them against large arrays just yet). I would like to hear about your results, and I welcome your thoughts and ideas.

~Chris

Thanks Chris excellent blog post. Join me tomorrow for more cool Windows PowerShell stuff.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Pick Comments from a PowerShell Script

Anonymous — Sat, 13 Apr 2013 05:00:00 GMT

Summary: Guest blogger, Bob Stevens, shares a script to pick out comments from a Windows PowerShell script.

Microsoft Scripting Guy, Ed Wilson, is here. Today we have a new guest blogger, Bob Stevens. I made Bob’s virtual acquaintance recently when I did a Live Meeting presentation to the Twin Cities PowerShell User Group.

Here is Bob’s contact information:

Blog: Help! I’m Stuck in My Powershell!
Twitter: @B_stevens6
LinkedIn: Robert Stevens

The floor is yours, Bob…

As a local Help Desk technician, I run into many repetitive support tasks. From low toners to Internet Explorer issues, I have done it all. About three months ago I discovered that I could use PowerShell to automate a number of these tasks, thereby freeing my time for some of the more unusual issues. Fortunately, all of the computers at my site have Windows PowerShell 2.0 installed, so it was a matter of ensuring that they can run scripts. This can be done by changing the Set-ExecutionPolicy cmdlet to Unrestricted in the following manner:

Set-ExecutionPolicy Unrestricted

When the work is done, switch it back to the organization default with:

Set-ExecutionPolicy Remote-Signed

Set-ExecutionPolicy governs which scripts can be run on any given system. By setting it as Unrestricted, I am removing all restrictions. I switch it back to Remote-Signed to prevent users from running scripts that can potentially damage a system, thereby presenting a potential for data loss.

Fast forward three months and multiple scripts later…

It dawned on me that I would need to create documentation for each of these scripts. Documentation provides my coworkers with the insight they need to understand the purpose and functionality of my work and to pick up where I left off should the script need to be altered. Thankfully, like a good Windows PowerShell scripter, I commented liberally throughout my scripts to ensure that I knew where I would need to alter it in the future. To this end I started working on a script to pull comments. I knew that I habitually use single line comments for documentation and block comments for commenting out blocks of code. Happy accident because the script I devised only pulls the first and the last lines of a block comment.

Note For simplicity, I name all directories a variation of “foo” and all input files a variation of “foo.*”. You can set foo as whatever you want.

As usual I started with setting my location:

Set-Location “C:\foo”

Next we set our source script file as a variable. I use variables in my scripts to enable me to change one line of code, rather than five lines, thereby reducing the chance of an error. Variables are defined by the dollar sign ($).

$script = “foo.ps1”

We need to define an output variable as $out. Note that I used the $script variable in the variable value. This will result in the file name of foo.ps1 comments.txt. This is to differentiate between output files. For this to work, there must be a space between $script and comments.txt:

$out = “$script comments.txt”

Now that we have defined the output file name, we need to create the output file itself, and I do this with the New-Item cmdlet. Of course, we need to define the object as a file—otherwise we get a dialog box asking us if it’s a file or folder:

New-Item “out” -ItemType File

Now our preparation is complete:

Set-Location "c:\foo"

$script = "foo.ps1"

$out = "$script comments.txt"

New-Item "$out" -ItemType File

We need to pull the content of our source file with the Get-Content cmdlet:

Get-Content $script

The next line is to prevent Windows PowerShell from appending the output to output that already exists in the variable by creating an array, this is done with the array (@) operator, followed by both parentheses:

$comments = @()

This is where the magic takes place. We need to use the Select-String cmdlet. This command requires two parameters: Pattern and File. Both values need to be quoted if you are not using a variable to define it. As we are searching for comments, we are going to select strings that contain “#”:

Select-String -Pattern “#” $script

This is a bit more complex, and it requires stringing three commands together, so we use the pipe (|) operator. The pipe operator merely states do “this” and then do “that” with the output of “this.” Pipe operators must always have a space preceding and succeeding it:

Select-String -Pattern “#” $script |

For our purposes, we are going to say, “For each object, do this.” Coincidentally (or not), Microsoft decided to add a Foreach-Object cmdlet for just this purpose! And everything that you are doing with Foreach-Object must be in braces to group them together:

Select-String - Pattern “#” $script |

Foreach-Object {}

When we string commands like this together, formatting is important—not for functionality, but for readability. Now we need to comment the full line where “#” appears. It is important to note that you must use “+=”, or you will end up with an empty file:

Select-String - Pattern “#” $script |

Foreach-Object {

$comments += $_.line

}

We need to tell Windows PowerShell to grab everything after “#” in that string. This is tricky, but it can be done with the context.postcontext definition:

Select-String - Pattern “#” $script |

Foreach-Object {

$comments += $_.line

$comments += $_.context.postcontext

}

We now need to tell Windows PowerShell to extract everything that we just defined within the Foreach-Object curly brackets:

Select-String - Pattern “#” $script |

Foreach-Object {

$comments += $_.line

$comments += $_.context.postcontext

}

$comments

Finally, we dump our output into the output file $out with the Set-Content cmdlet:

Select-String - Pattern “#” $script |

Foreach-Object {

$comments += $_.line

$comments += $_.context.postcontext

}

$comments | Set-Content $out

The complete script looks something like this:

Set-Location "c:\foo"

$script = "foo.ps1"

$out = "$script comments.txt"

New-Item "$out" -ItemType File

Get-Content $script

$comments = @()

Select-String -Pattern "#" $script |

Foreach-Object {

$comments += $_.line

$comments += $_.context.postcontext

}

$comments | Set-Content $out

The result should take the following input:

And give you the following output (Select-String -pattern “#” shows up because it contains a “#”):

This saved me an hour now and countless future hours that I would spend extracting comments for documentation.

When I was verifying my work, I ran across the following note to myself stating that I referenced a Rob Campbell in another script. Some of the code made it in here.

Rob Campbell, Mjolinor: How do you extract data from a txt file with powershell. As always, input is always appreciated.

Thank you for your time. I uploaded the complete script to the Script Center Repository: Extracting Comments from a Script with PowerShell.

~Bob

Thank you, Bob, for sharing your script and your insight with us today. Join us tomorrow when Bob talks about a script he wrote to clean up user profiles. It is cool, and you do not want to miss it.

Ed Wilson, Microsoft Scripting Guy