Search results for 'app:weblogs' matching tags 'Scripting Guy!' and 'Weekend Scripter'

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.

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

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

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: Use PowerShell to Upload a New File Version to SharePoint

Anonymous — Sun, 28 Apr 2013 05:00:00 GMT

Summary: Microsoft PowerShell MVP, Niklas Goude, talks about using Windows PowerShell to upload a new version of a file to SharePoint.

Microsoft Scripting Guy, Ed Wilson, is here. Today Niklas Goude is our guest blogger. You can read more from Niklas in his past Hey, Scripting Guy! Blog posts.

Take it away Niklas…

In a previous post, Use PowerShell Cmdlets to Manage SharePoint Document Libraries, we talked about uploading files to a share in SharePoint 2010. Now we'll take this a step further and update a minor or a major version of an existing document.

Here’s a quick recap of the code used to upload the file:

# Add the Snapin
Add-PSSnapin Microsoft.SharePoint.PowerShell

# Retrieve specific Site
$spWeb = Get-SPWeb http://SP01

# Create instance of Folder
$spFolder = $spWeb.GetFolder("Shared Documents")

# Get the file on Disk that we want to upload
$file = Get-Item C:\Documents\MyDoc.docx

# upload the file.
$spFolder.Files.Add("Shared Documents/MyDoc.docx",$file.OpenRead(),$false)

What we’ve done so far is to upload a single document to a document library in SharePoint 2010. The file used in this example is stored on drive C:

The document contains a single line:

After we run the Windows PowerShell code, the document gets uploaded to a document library in SharePoint 2010.

We can check the versioning for the document by clicking Version History in SharePoint:

We’ll see that the version number is set to 0.1:

Now, let’s open the file that is stored on drive C and modify it:

Back in Windows PowerShell, we use SPFileCollection to pick up the document we just uploaded. In this example, we are going to filter out the document where the name is equal to MyDoc.docx by using the Where-Object cmdlet.

# Retrieve specific Site
$spWeb = Get-SPWeb http://SP01

# Create instance of Folder
$spFolder = $spWeb.GetFolder("Shared Documents")

# Retrieve a Specific File.
$spFile = $spFolder.Files | Where-Object { $_.Name -eq "MyDoc.docx" }

We pick up the file because we want to use some of its properties for the new version that we want to upload. When we upload a new version of the document, we still use the Add method that is provided by the Microsoft.SharePoint.SPFileCollection, but with a different overload definition. Here’s the definition on MSDN: SPFileCollection.Add method (String, Stream, SPUser, SPUser, DateTime, DateTime).

The parameters we want to use are: urlOfFile, File, CreatedBy, ModifiedBy, TimeCreated, and TimeLastModified.

We can get the following values from the existing document in SharePoint 2010: UrlOfFile, CreatedBy, ModifiedBy, and TimeCreated. We can get File by using Get-Item, and we can get TimeLastModified by simply using Get-Date.

First, let’s get the modified MyDoc.docx from drive C:

$file = Get-Item C:\Documents\MyDoc.docx

Next we run the method:

$newVersion = $spFolder.Files.Add($spFile.Name, $file.OpenRead(), $spFile.Author, $spFile.ModifiedBy, $spFile.TimeCreated, (Get-Date))

If we open the SharePoint document library again, we’ll see that we have a new minor version of our document, .02.

And finally, if we want to add the modified document as a major version, we use the Publish method:

$newVersion.Publish("")

Now we have a new major version, 1.0, instead.

~Niklas

Thank you, Niklas, for taking your time to share your knowledge.

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

Use PowerShell to modify WMI data such as drive label

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

Summary: The Scripting Wife learns how to use the CIM cmdlets and Windows PowerShell to assign a new drive label by modifying WMI data Weekend Scripter: Changing WMI information Microsoft Scripting Guy, Ed Wilson, is here. Well yesterday, after...(read more)

Weekend Scripter: Use PowerShell to Find the Version of Windows

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

Summary: The Scripting Wife learns about using Windows PowerShell to find computer hardware information in prep for the 2013 Scripting Games.

Microsoft Scripting Guy, Ed Wilson, is here. This morning did not start with a nice leisurely cup of tea on the lanai at home. Instead, it started by rushing around to get packed, loading up the vehicle, vying for a parking place at the airport, taking a shuttle from parking to the Charlotte terminal, standing in line for an hour for a security screen that was more intimate than my last physical exam, putting shoes and belt back on and repacking my suitcase, and standing in another really long line to buy an overpriced cup of warm milk with a shot of acidic coffee in it. Then another long line to board a really, really cramped airplane. Luckily, the Scripting Wife is with me, and she helps make the entire process a little more pleasant. Yep, we are finally on our way to Seattle for the Windows PowerShell Summit.

Scripting Wife uses WMI

After takeoff, I open my laptop and the Windows PowerShell console and start playing around. Before long the Scripting Wife is poking me in my shoulder.

“Yes,” I say.

“So I think this would be the perfect time for you to talk to me about using WMI with Windows PowerShell,” she stated.

“OK, good idea,” I said as I slid my laptop over to allow her to use it.

“So what now?” she asked.

“Well the first thing to know about WMI is that there are lots of WMI classes. They are also arranged into different namespaces, but we will not get into that right now. To find WMI classes, use the Get-CimClass cmdlet in Windows PowerShell 3.0,” I said.

“Well, that makes sense. So what do I do if I need to find the name of my operating system?” she asked.

“Why don’t you try it? Use the Get-CimClass cmdlet, and put os into a pair of wildcard characters,” I suggested.

She typed the following:

Get-Cimc<tab><Space>*os*<enter>

The command is shown here:

Get-CimClass *os*

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

“Well, that did not do what I expected it to do,” she said.

“So, you have found out that WMI does not really have a class named OS, or anything similar to OS. What are you really looking for?” I asked.

“I want to know the version of Windows,” she said.

“The cool thing about Get-CimClass is that you can search for classes that contain a specific property. So why don’t you look for WMI classes that contain a property of version?” I suggested.

The Scripting Wife typed the following:

Get-Cimc<tab><space>-p<tab><space>version<enter>

The following is the command she created.

Get-CimClass -PropertyName version

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

“It is still a lot of stuff,” she complained.

“Well one of the things you need to know about WMI is that there are abstract and dynamic classes,” I began.

“And why do I need to know that?” she interrupted.

“Maybe you do not need to know all that, but keep in mind you want to use dynamic classes,” I began again.

“Why?” she asked.

“Because dynamic WMI classes go off and get information. So they are the ones that you want to use. The abstract classes are more used by developers,” I said.

“Well OK. So I only need to remember to use dynamic classes. I got it. Now what?” she said.

“The Get-CimClass cmdlet has a QualifierName parameter. You can specify that you only want dynamic WMI classes returned. It will give you a better output,” I said.

“Cool. So let’s do it,” she said energetically.

“Use the Up arrow to retrieve your previous command. Go to the end of the command and add the QualifierName parameter,” I said. “And don’t forget to use tab completion to help you.”

The Scripting Wife typed:

<uparrow><space>-q<tab><space>dynamic<enter>

Here is the command she created:

Get-CimClass -PropertyName version -QualifierName dynamic

The command and associated output are shown here.

“Cool,” she said. “So where do I find the version?”

“Look at the output. See the Win32_OperatingSystem?” I started.

“Oh yeah, I get it,” she said.

“Now use Get-CimInstance to retrieve the operating system information,” I said.

She typed the following:

Get-Cimi<tab><space>Win32_Op<tab><enter>

Here is the command:

Get-CimInstance Win32_OperatingSystem

Here is the command and the output from the command:

“Well ain’t that just special,” she said as she pushed the laptop back over to me. She then opened her Surface and began reading a book that she had downloaded.

I returned to my Windows PowerShell console, and tried to make sense of life.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Modify WMI Data Such as Drive Labels

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

Summary: The Scripting Wife learns how to use the CIM cmdlets and Windows PowerShell to assign a new drive label by modifying WMI data.

Weekend Scripter: Changing WMI information

Microsoft Scripting Guy, Ed Wilson, is here. Well yesterday, after we got through an extremely long security line at the airport, and we jiggled around in a very cramped airplane for over five hours on our flight to Seattle for the Windows PowerShell summit, we met up with Windows PowerShell MVP Jeff Wouters at the SEATAC airport. We gave him a ride into Redmond and spent some time hanging out. Here is a picture of Jeff and the Scripting Wife I took near the Seattle Space Needle. You see, Jeff has never been to Seattle, and so we thought we would show him around.

The Windows PowerShell summit has already been a success, in my mind, and the first session has not even kicked off. Of course, the biggest thing for the summit for me is not the sessions, but the chance to talk and to interact with members of the community. In this regard, the summit has already exceeded expectations.

I decided to head down to the lobby of the hotel to grab something to eat this morning. It is still very early for people from the West Coast, but for the Scripting Wife and I it is already late due to the three time zone change for us. Of course, for our European friends the change is twice as great. I am sipping a cup of English Breakfast tea, munching on a croissant, and checking my email, when a loud thudding sound accompanied by a sudden shaking of the table woke me from my revelry–it is the Scripting Wife.

I hazard a query, “Why are you are up so early?”

“Hey, it is nearly noon back in Charlotte–I am ready to go,” she chirped.

“Go? Go where?” I ventured.

“Out. We are getting together a group, and we are heading out,” she explained.

“Where is out? Have you no specific destination in mind?” I asked.

“Well, maybe downtown Seattle. There is great shopping there, a cool aquarium, ferry terminals, and wonderful restaurants. We are in a real city my friend, and I for one am not going to let the opportunity pass,” she pontificated.

“I can appreciate that. But before you go, let me show you something you might need to know for the 2013 Scripting Games,” I said.

“OK, but make it quick, because when the group shows up, I am out of here,” she said.

Using the CIM cmdlets to set a WMI property

I opened the Windows PowerShell console with admin rights by right clicking the Windows PowerShell console icon and selecting Run As Administrator from the action menu. Admin rights are required to modify WMI objects.

“OK. Look over here,” I directed. “Find WMI classes related to disks.”

Find disk classes

The Scripting Wife thought for a few minutes, and typed the following.

Get-Cimc<tab><space>*disk*<enter>

The command she typed appears here.

Get-CimClass *disk*

Get dynamic classes

“Now, narrow your output to only dynamic WMI classes,” I instructed.

She used the Up arrow to retrieve the previous command and she added the Dynamic qualifier to her command. Here is what she typed:

<up arrow><space>-q<tab>dynamic<enter>

The command looks like this when complete.

Get-CimClass *disk* -QualifierName dynamic

Get logical disk info

“Cool. Now what we want to do is to find out information about drive C. To do this use the Get-CimInstance cmdlet and retrieve information about the Win32_LogicalDisk WMI class,” I said.

The Scripting Wife thought for a second, and then she began to type. Here is what she did:

Get-CimI<tab><space>Win32_LogicalDisk<enter>

The command looks like the following:

Get-CimInstance win32_logicaldisk

“OK, now look at the output and see if you can tell the property that indicates that it references the drive names,” I said.

She looked at the laptop screen. The output looks like the following:

PS C:\> Get-CimInstance win32_logicaldisk

DeviceID DriveType ProviderName VolumeName Size FreeSpace

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

C: 3 159486308352 10707682...

D: 3 System Reserved 366997504 113971200

F: 3 ExtraDisk 499738734592 43558884...

Narrow down the drives by letter

“So you did a good job. You found information about all of the logical disks. What I want you to do now, is to return only drive C . To do that you will need to use the Filter property,” I said.

It did not take the Scripting Wife long at all before she used the Up arrow to retrieve her previous command and to add the Filter parameter. Here is what she typed.

<up arrow><space>-f<tab><space>’DeviceID=’c:’”<enter>

Here is the command she created.

Get-CimInstance win32_logicaldisk -Filter "deviceid='c:'"

The command and output from the command are shown here:

PS C:\> Get-CimInstance win32_logicaldisk -Filter "deviceid='c:'"

DeviceID DriveType ProviderName VolumeName Size FreeSpace

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

C: 3 159486308352 10707628...

Setting a WMI property

“Notice that you have no label, or VolumeName,” I said. “To set that you will use the Set-CimInstance cmdlet and use a hash table for the Property parameter,” I said.

“Huh?” she asked. “You know that I do not speak geek.”

“It makes more sense when you just do it,” I said.

“Well, hurry up. I just got an email on my phone and they will be here in a few minutes,” she said.

“OK. First of all, you need to use the Up arrow and retrieve your previous command. Then you need to pipe the command to the Set-CimInstance cmdlet. Do that, but do not press ENTER because there is more to the command than that,” I said.

The Scripting Wife thought for a few minutes, and then began typing. Here is what she typed.

She paused.

“OK, now you need to add the Property parameter and an ampersand and an opening and a closing curly bracket. Do not press ENTER,” I said.

This time, she did not hesitate. Here is what she typed:

-p<tab><space>@{}

“Good. Now inside the two curly brackets you add your 'property name equals new value' statement. Here, you are going to set a value for the VolumeName. Give it a value of SSD_Drive,” I said.

Here is what she typed:

volumename='SSD_Drive'

“Awesome. You are nearly there. Add the PassThru parameter so the modified WMI object returns to the Windows PowerShell line, and press ENTER,” I said.

Here is what she typed:

-p<tab><enter>

The complete command is shown here. (This is a one-line command,broken at the pipe so it is more readable.)

Get-CimInstance -ClassName win32_Logicaldisk -Filter "deviceid='c:'" |

Set-CimInstance -Property @{volumename='SSD_Drive'} –PassThru

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

“Well, isnt that special,” she mocked.

“Actually, I think it is pretty cool,” I said somewhat defensively.

“I do too. I was just giving you a hard time,” She said.

At that instant, the automatic doors to the lobby swung open and in walked a couple of obvious PowerShellers. I could tell by the T-shirts, but the Scripting Wife obviously knew them.

“Well, I am outta here. Have fun working on your presentation,” she said.

“So when will I see you again?” I asked.

“We’re meeting Don Jones and others at Azteca at 5:00,” she said.

“Zulu?”

Without missing a beat, she said “No. Pacific Standard Time.” And she was gone.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Use PowerShell to Clean Out Temp Folders

Anonymous — Sun, 14 Apr 2013 05:00:00 GMT

Summary: Guest blogger, Bob Stevens, talks about using Windows PowerShell to clean out temporary folders on desktops following a malware infection.

Microsoft Scripting Guy, Ed Wilson, is here. Today, we welcome back our newest guest blogger, Bob Stevens. Yesterday Bob wrote about a quick script that he developed to pick out comments from a Windows PowerShell script: Weekend Scripter: Pick Comments from a PowerShell Script.

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

Take it away, Bob…

For a local service desk systems analyst, nothing is more frustrating than malware. Not only is it a time sink—it also has the indented potential to cause irreparable damage. No network that connects to the Internet is immune to it.

Most organizations have their own standard operating procedures regarding malware removal. Even so, individuals technician have their special tweaks and tricks to increase the likelihood of success. I like to target the malware where it resides: Temp Folders. And after cleaning and clearing a number of workstations, it occurred to me that I could use a Windows PowerShell script to do just that, saving myself five minutes of hoping that the computer will let me open a folder.

I started by creating a list of the locations that temporary files are automatically placed by the Windows XP operating system (starting with Windows Vista, they are in the C:\Users folder):

C:\Windows\Temp
C:\Windows\Prefetch
C:\Documents and Settings\*\Local Settings\Temp
C:\Users\*\Appdata\Local\Temp

Now that I have defined our locations, I need to define what I want to do. For this, I create a flowchart:

I start with the Set-Location command and define the location as “C:\Windows\Temp”:

Set-Location “C:\Windows\Temp”

Now that I am located in the Windows temp folder, I need to delete the files. This can be done with the old DOS command Del, but I prefer using the Windows Powershell cmdlet Remove-Item to standardize the script. The items need to be removed indiscriminately, so I use a wildcard character. A wildcard character is a special character that represents one or more other characters. The question mark (?) wildcard stands for one character and the asterisk (*) wildcard stands for any number of characters. Because I do not want to discriminate between different files, I use the asterisk.

Remove-Item *

Next I tell the Remove-Item cmdlet to also remove all files in subdirectories with the -recurse switch:

Remove-Item * -recurse

And I tell it to select hidden files with the -force switch:

Remove-Item * -recurse -force

Together the two lines looked like this:

Set-Location “C:\Windows\Temp”
Remove-Item * -recurse -force

I do the same for the rest of the folders and the complete script begins to take shape:

Set-Location “C:\Windows\Temp”
Remove-Item * -recurse -force

Set-Location “C:\Windows\Prefetch”
Remove-Item * -recurse -force

Set-Location “C:\Documents and Settings”
Remove-Item “.\*\Local Settings\temp\*” -recurse -force

Set-Location “C:\Users”
Remove-Item “.\*\Appdata\Local\Temp\*” -recurse -force

Wait. Why is there an asterisk in the middle of the last path? You can use wildcard characters to do this:

Remove-Item “.\*\Appdata\Local\Temp\*” -recurse -force

This says, “Look in all folders in this directory with the path structure that matches this.” In my case, this is all of the user profile Local Settings\temp folders.

But this looks very busy, so at Ed Wilson’s suggestion, an array would prevent all the unnecessary jumping around with the Set-Location command. So we change our flowchart to look something like this:

Arrays are a nifty programming feature that groups a number of strings together into one variable, while remaining individual strings. They are defined much like a normal variable—they start with the variable ($) indicator followed by the array name:

$tempfolders

Just like a variable, I use the equal sign (=) to define it.

$tempfolders =

Here is where the arrays and variables differ when defining. I start with the array indicator (@):

$tempfolders = @

And I follow it with parentheses to group strings together:

$tempfolders = @()

What you put inside the parentheses is your choice. For my purposes, I fill it with temp folder paths:

$tempfolders = @( "C:\Windows\Temp\*", "C:\Windows\Prefetch\*", "C:\Documents and Settings\*\Local Settings\temp\*", "C:\Users\*\Appdata\Local\Temp\*" )

Notice that each string is neatly encapsulated by double quotation marks (“ ”) and separated by a comma and a space (, ). The quotation marks are necessary for any string with a space in it, and the comma with a space separates the values. Both are essential to define an array. Additionally you can see that each string ends with a wildcard character. This is going to remove the necessity for me to define exactly what to remove in the next line.

Now I use the Remove-Item cmdlet again; but this time for the -path operator, I use the $tempfolders array variable:

Remove-Item $tempfolders -force -recurse

This line instructs Windows Powershell to do exactly the same as previously, but for every item in the array.

Side-by-side, here are the two versions of the script:

1 Set-Location “C:\Windows\Temp”

2 Remove-Item * -recurse -force

3 Set-Location

4 “C:\Windows\Prefetch”

5 Remove-Item * -recurse -force

6 Set-Location “C:\Documents and Settings”

7 Remove-Item “.\*\Local

8 Settings\temp\*” -recurse -force

9 Set-Location “C:\Users”

10 Remove-Item “.\*\Appdata\Local\Temp\*” -recurse -force

1 $tempfolders = @("C:\Windows\Temp\*", "C:\Windows\Prefetch\*", "C:\Documents and Settings\*\Local Settings\temp\*", "C:\Users\*\Appdata\Local\Temp\*")

2 Remove-Item $tempfolders -force -recurse

With two lines of code, I was able to save myself between three minutes and 30 minutes of work. This is the purpose of scripting at its finest: automate repetitive tasks to allow the technician to do more in-depth work. Thank you all for reading, and as always, let me know if you have developed a better way!

~Bob

Bob, thanks again for a real world example and a great suggestion. Join us tomorrow for a blog post by Boe Prox about installing WSUS on Windows Server 2012. It is a great blog and I am sure you will enjoy it.

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