Dreaming in PowerShell

Downloading Images from Webpages

Tobias — Wed, 17 Mar 2010 01:35:00 GMT

In a training, recently a participant asked about an HTML parser to analyze and harvest data from web pages. Unfortunately, there is no .NET type for this so PowerShell can't help. Or can it? Well, as it turns out, there is a HTML parser after all. Let's create code that downloads all images from any web page you want!

Accessing the IE Parser from PowerShell

A browser like Internet Explorer needs a way to analyze and display HTML code so it most certainly has a parser. To connect to the IE intrinsics, PowerShell can use a COM object named "InternetExplorer.Application". Here is how to load and display a web page:

$ie = New-Object -COMObject InternetExplorer.Application
$ie.visible = $true
$ie.Navigate('http://www.powershell.com')
While ($ie.Busy) { Start-Sleep -Milliseconds 400 }
'Done!'

Note how I hold the script until the web page is completely loaded and displayed. That's a good idea because when you want to access the document object model (DOM), you want to be sure the document has been fully loaded.

Next, you can use your IE-object to access the internal HTML document model through its Document property. It provides access to all kinds of clever methods:

$ie.Document | Get-Member

Finding Images (or Links)

One of the most useful methods is called getElementbyTagName(). It returns all HTML elements with a given tag. To scrape all images from that web page, simply ask for all elements with a tag name of 'img' like this:

$ie.document.getElementsByTagName('img')

PowerShell will throw tons of img-Objects at you. As it turns out, the image url is stored in its src property, so to get all urls from all images, refine your line just a little bit:

$ie.document.getElementsByTagName('img') | Select-Object -ExpandProperty src

Likewise, to collect all links on that page, search for the tag "a" and output its href property:

$ie.document.getElementsByTagName('a') | Select-Object -ExpandProperty href

Downloading all Images on a Web Page

Our initial objective was to harvest all images from that web page. We already got the image urls. Next, I need a way to download them to my hard drive.

While there are plenty of ways to download stuff using PowerShell, one of the more clever approaches uses the "Background Intelligent Transfer Service (BITS)". That's smart because BITS knows how to download and is very robust. It is the same technology used by Windows Update. Which raises the question how to get to BITS.

If you are running Windows 7 or better, that's easy because it comes with a module called "BitsTransfer". It also comes with PowerShell V2 updates I believe. Simply import it and have a look at the arsenal of new cmdlets it provides:

Import-Module BitsTransfer
Get-Command -Module BitsTransfer

CommandType Name Definition
----------- ---- ----------
Cmdlet Add-BitsFile Add-BitsFile [-BitsJob] <BitsJ...
Cmdlet Complete-BitsTransfer Complete-BitsTransfer [-BitsJo...
Cmdlet Get-BitsTransfer Get-BitsTransfer [[-Name] <Str...
Cmdlet Remove-BitsTransfer Remove-BitsTransfer [-BitsJob]...
Cmdlet Resume-BitsTransfer Resume-BitsTransfer [-BitsJob]...
Cmdlet Set-BitsTransfer Set-BitsTransfer [-BitsJob] <B...
Cmdlet Start-BitsTransfer Start-BitsTransfer [-Source] <...
Cmdlet Suspend-BitsTransfer Suspend-BitsTransfer [-BitsJob...

As it turns out, to download a file use Start-BitsTransfer and provide the URL and a filename to store the downloaded file.

The Solution: Get-WebPageImages

Here is a ready-to-use function called Get-WebPageImages. It's pretty small and efficient, like most PowerShell code:

function Get-WebPageImages($url, $folder) {
Import-Module BitsTransfer
if (-not (Test-Path $folder)) { md $folder }
$ie = New-Object -COMObject InternetExplorer.Application
$ie.Navigate($url)
while ($ie.Busy) { Start-Sleep -Milliseconds 400 }
$sources = $ie.document.getElementsByTagName('img') | Select-Object -ExpandProperty src
$destinations = $sources | ForEach-Object { "$folder\$($_.Split('/')[-1])" }
$displayname = $url.Split('/')[-1]
$ie.Quit()
Start-BitsTransfer $sources $destinations -Prio High -Display $displayname
}

To start downloading the images, use it like this:

Get-WebPageImages 'http://www.powershell.com' 'c:\webimages'

You will see a progressbar while the function downloads all images to your machine. Once done, all images are automatically moved into the folder you provided.

To download images asynchronously, add the parameter -Async to Start-BitsTransfer. Downloading asynchronously occurs transparently in the background and is no longer bound to PowerShell. You can close PowerShell and even restart your machine. The download continues silently in the background. To check download progress, use this line:

Get-BitsTransfer |
Select-Object DisplayName,
@{Name='Progress'; Expression={ $_.BytesTotal * 100 / $_.BytesTransferred }},
JobState

Watch out, though: to actually receive the files downloaded asynchronously, you need to manually complete the job once all files are transferred using Complete-BitsTransfer.

Get-BitsTransfer | Where-Object { $_.JobState -eq 'transferred' } | Complete-BitsTransfer

Learning Points

Downloading images from a web page is fun, and so is PowerShell, but the real learning points here are the different ways how PowerShell techniques work like small building blocks and utilize all kinds of technology to solve the problem.

I used an old COM object (IE automation interface) to access and parse HTML and identify image urls. I used the pipeline to get the information in shape. I used a PowerShell extension (BitsTransfer) to actually download the images to our machine.

And guess what? That's all perfectly fine. PowerShell is pragmatic, and with PowerShell, anything can be used and tied together. That's awesome. As a side effect, you used the BitsTransfer module quite a bit. It is a great solution for downloading (and uploading) files.

Cheerio for today, and don't forget to give PowerShellPlus a try! It makes exploring and developing PowerShell code so much easier!
Thanks for your support,

Tobias
Microsoft MVP PowerShell
PowerShellPlus Architect

Are you using the correct PowerShell version?

Tobias — Wed, 20 Jan 2010 23:50:00 GMT

Recently, when I was training a group of enterprise admins, a question came up: Why is PowerShell remoting not working on Windows XP? Well, it does! As it turned out, they had downloaded the "wrong" PowerShell version. How come?

When you search for PowerShell V2 downloads, you will find tons of articles and download links. Only some of them point to the correct final "RTM" link. A lot of people are still blogging about "CTP" versions which really were beta versions with limited functionality. Even worse, it turned out that these out-dated PowerShell versions are still up for download from the Microsoft Download center, so when you follow the "wrong" link, you could get the impression that these CTP versions really were official and up-to-date releases.

This was brought up in our PowerShell MVP chat, and as a consequence, we are trying to get the old out-dated downloads offline. At the same time, we were tossing together ideas that help you identify which version you already have and whether it is the correct one. The results of this joined MVP effort I would like to share with you today.

PowerShell Versions - Watch Out!

Basically, there are two kinds of PowerShell: PowerShell V1 which dates back to 2006, and PowerShell V2 which was released in Oct 09. PowerShell V2 is downwards compatible to V1 so all of your V1 stuff still runs, but in addition, V2 has tons of important new features such as Remoting (executing code on other machines), Modules (the "new" Snapins to load more commands), background jobs (executing code in a separate thread asynchronously) and more. So it is an excellent idea to upgrade to V2. Both versions are supported on Windows XP and up. They do not run side-by-side, so you have to install V2 over V1.

One very easy way of distinguishing both versions is to look for a PowerShell variable called $psversiontable. If it is undefined, then you are running V1. If it is there, you have V2. From outside PowerShell, you can also look at a registry key to differentiate between V1 and V2: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine\PowerShellVersion.

Note that PowerShell often was installed as update package so you do not find it in the list of installed software. You have to look at the update packages. Fortunately, though, the final PowerShell V2 can be installed over V1 without having to uninstall V1 first. Only the outdated CTP versions make you find and manually uninstall V1 first. So if you are trying to install V2 on your machine, and it complains about an existing V1, you may well be using the wrong installation package.

Beginning with Windows 7 / Server 2008 R2, you are on the safe side anyway because these OS are the first to ship with PowerShell included, and they always ship with the final version.

CTP PowerShell V2 is WRONG!

The PowerShell team has prereleased V2 a long time before the final version was done and called these preview versions "CTP" (Community Technology Preview). You can still find links to CTP1, CTP2 and CTP3. All of these versions are outdated and should no longer be used unless some other beta software on your machine really requires it. One reason why you should not use CTPs anymore is because they are lacking some functionality such as Remoting on Windows XP. Other reasons are that CTP versions are unsupported, still had some bugs and also some naming changes were made, so scripts created on CTP1 might not run on the final version of PS V2 anymore.

Unfortunately, it is not a trivial task to identify whether you have the final PowerShell V2 or some of the preview versions because - CTP versions have a $psversiontable variable, and the versions reported by it can differ from OS to OS and CTP to CTP. So if you do get back a result from $psversiontable, make sure the BuildVersion is equals or greater than 6.0.6002.18111.

If you want to check your local PowerShell version, you could wrap that logic into a function like this:

function Test-PowerShellVersion {

if (Test-Path variable:psversiontable) {
$versionPresent = $psversiontable.buildversion

if (

($versionPresent.Major -ge 6) -and

($versionPresent.Build -ge 6002) -and

($versionPresent.Revision -ge 18111)

) {
"V2 RTM"
} else {
"V2 CTP Prerelease - Update to V2 RTM!"
}
} else {
"V1 - Update to V2 RTM!"
}
}

It tells you exactly whether you have the final V2 or some outdated prerelease installation. Thanks Max for investigating the version numbers and Shay for tossing in version checking!

Wait a minute - How can I check my enterprise?

Of course, the quick solution I just presented will not help when you need to investigate your entire network. It also helps only when you examine PowerShell from within. What if you have no access to the $psversiontable variale because you are not checking from within a PowerShell script?

As it turns out, the BuildVersion reported by $psversiontable really is the version found in the PowerShell assembly. You could get to it from other programming languages by instantiating a PS object and then looking at the version. This is the route to take for anyone wanting to create an inventory solution based on VB.NET or C#. Here is a PowerShell line that illustrates how to get to the version (thanks Oisin!):

([psobject].assembly.getcustomattributes(

[reflection.assemblyfileversionattribute], $false)

)[0].version

If you just wanted to check computers in your network, you can use a PowerShell script. Since PowerShell V2 Remoting is not available on downlevel installations, in order to get the file version remotely, use WMI. The following script Test-PSVersion represents all I thought was useful and consists of a lot of individual contributions made in our MVP list. So it is by no means my function or accomplishment alone but instead the result of a joined team effort in our MVP group. Special thanks go to Alexander for bringing up the WMI queries and Kirk for perfecting the parameter decoration and reading the OS info via WMI. There were many other MVPs involved. So forgive me if I do not credit everyone.

Should you find errors in this script, they are my fault alone (as I was putting together this specific script ;-) ). In this case, I kindly ask you to leave a comment below. You can download the function here: http://powershell.com/cs/media/p/4591.aspx

function Test-PSVersion {
[CmdletBinding()]
param(
[parameter(Position=0,ValueFromPipeline=$true)]
[ValidateNotNullOrEmpty()]
[String[]]
$ComputerName = @('.'),

[Parameter()]
[ValidateNotNull()]
[System.Management.Automation.Credential()]
$Credential = [System.Management.Automation.PSCredential]::Empty
)
process {

if (Test-Connection -ComputerName $computername -Count 1 -ErrorAction SilentlyContinue) {
try {
$OS = Get-WmiObject -Namespace root\CIMV2 -Class Win32_OperatingSystem `
-ComputerName $computername -Credential $credential -ErrorAction SilentlyContinue
if ($OS) {
$path = "$($OS.SystemDirectory -replace '\\','\\')\\WindowsPowerShell\\v1.0\\powershell.exe"
$OSName = $OS.Name.Split('|')[0]
$query = "SELECT Version FROM CIM_DataFile WHERE Name = '$path'"
$PSEXE = Get-WmiObject -Query $query -ComputerName $computername -Credential $credential
if ($PSEXE.Version) {
$buildversion = $PSEXE.Version.Split()[0]
$versionPresent = [version]$buildversion
$versionRequired = [version]'6.0.6002.18111'
if ($versionPresent -ge $versionRequired) {
$psversion = "V2 RTM"
} elseif ($versionPresent.Major -ge 6) {
$psversion = "V2 CTP Prerelease - Update to V2 RTM!"
} else {
$psversion = "V1"
}

New-Object PSObject -Property @{
ComputerName=$OS.__SERVER;
BuildVersion=[version]$buildversion
Version=$psversion;
Status=$true;Description='OK';
OSName = $OSName

}
} else {
New-Object PSObject -Property @{
ComputerName=$computername[0];
BuildVersion=[version]$null;
Version='n/a';
Status=$false;
Description='Unable to access OS information via WMI.';
OSName = 'n/a'
}
}
}
}
catch {
New-Object PSObject -Property @{
ComputerName=$computername[0];
BuildVersion=[version]$null;
Version='n/a';
Status=$false;
Description=($_.Exception.Message);
OSName='n/a'
}
continue
}

} else {
New-Object PSObject -Property @{
ComputerName=$computername[0];
BuildVersion=[version]$null;
Version='n/a';
Status=$false;
Description='Computer did not respond to ping, skipped.';
OSName='n/a'
}
}
}
}

"localhost", "pc77", "localhost", "storage1" |
Test-PSVersion

You can call this script over the pipeline and pipe a list of computers into it, or you can call Get-Content and read in the content of a list of computernames and pipe the result to Test-PSVersion. What you should get in return should look similar to this:

Version : V2 RTM
OSName : Microsoft Windows 7 Ultimate
Status : True
ComputerName : DEMO5
Description : OK
BuildVersion : 6.1.7600.16385

Version : n/a
OSName : n/a
Status : False
ComputerName : pc77
Description : Computer did not respond to ping, skipped.
BuildVersion :

Version : V2 RTM
OSName : Microsoft Windows 7 Ultimate
Status : True
ComputerName : DEMO5
Description : OK
BuildVersion : 6.1.7600.16385

Version : V2 RTM
OSName : Microsoft Windows Server 2003 for Small Business Server
Status : True
ComputerName : STORAGE1
Description : OK
BuildVersion : 6.0.6002.18139

Conclusion

It is time to check your PowerShell version! Make sure you are not using any prerelease software (unless you need to for obscure reasons). And if you find yourself using PS V1, consider an upgrade. It is free and worth it!

I hope on behalf of all of us PowerShell MVPs, with the code and examples in this post, we provided you with the inventory tools you need to make this happen. To get your hands on PowerSjell V2 RTM, there are (too) many dowload pages. To download PowerShell V2 and learn all about prerequisites etc. I found this link up-to-date and useful: http://support.microsoft.com/kb/968929

Have fun! Hey, and watch out for PowerShellPlus 3.1! Did you try the beta yet?

And one more thing: if you happen to be located in Germany, Switzerland or Austria, rent me!

I am doing inhouse trainings, tutorials and projects. Simply drop a mail to tobias@powershell.com, and maybe we meet in person some time soon...! I have tons of tricks for you and do trainings for midsize and large enterprises on a regular basis - it's always a lot of fun!

Cheers

Tobias

1 equals "Running"? - Melting Integer and String Objects together

Tobias — Thu, 07 Jan 2010 08:19:00 GMT

By coincidence, I stumbled upon an article in the PS team blog which talks about comparing different object types. It definitely is worth looking at, but let's take it a step further.

Recently, while I was deserializing service objects, I found that "status" was returned as friendly text such as "Running" or "Stopped" BUT when I took a deeper look, it turned out this property returned Int32, numeric values.

So naturally, two questions arose:

first, how mad can it get when Int32 suddenly starts outputting text?
and second, why did I take a deeper look at this in the first place? (aka, what is the real world relevance?)

WYSINAWYG - What you see is NOT ALWAYS what you get

Usually, when you output objects to the console, you can safely look at the columns, pick some values and use them for future filtering on those properties, just like this:

Get-Service | Where-Object { $_.Status -eq 'Running' }

With deserialized service objects, this suddenly fails which was when I started to scratch my head:

Get-Service | Export-CliXML $home\services.xml
$services = Import-CliXML $home\services.xml
$services
$services | Where-Object { $_.Status -eq 'Running' }

The last line simply does not return anything although there definitely are running service objects. Crazy.

Guess why? With deserialized service objects, Status returns text that really is numeric:

$services | Foreach-Object { $_.Status.GetType().FullName }
System.Int32
System.Int32
(...)

So, you would have to compare against the numeric value, not the text that was displayed in the Status column inside the console:

$services | Where-Object { $_.Status -eq 4 }

Uh, that is strange... Do I have your attention now?

Override toString() to get Int32-Mutations...

To make an integer appear as something different, all you need to do is override its toString() method. Replace it with whatever you would like to use to display the variable. Here is a sample:

$b = 1
$b
1

I stored a numeric value in a variable called $b, and naturally, when I output it, it shows what it is: a numeric value. No surprises. But wait!

Next, I override its toString() method with my own ScriptMethod:

$b = $b | Add-Member scriptMethod -pass toString -force { "Running" }
$b
Running

Tada! Now, when I output $b, it changes nature and returns whatever I specified in my toString() method. So my Int32 now looks like a string.

"Oh yeah", you may mumble, "so smarty, why did you not use a string in the first place?" Well, because although $b looks like a string, it is still an Integer:

$b -eq 1
True
$b -eq 'Running'
False

In fact, $b now behaves exactly like the deserialized Status property I received back from my initial service objects. With hybrid Integers, you output information as nice & friendly text so you don't have to look up geeky values to understand what them numbers stand for. Still, you can efficiently compare them against numeric values if you need to.

-like to the Rescue

The only problem with this is that you run into problems like I did if you don't know about this masquerade. You *think* it is text but once you compare it with text, the comparison mumbles "nope, it's an integer, so I return $false" - well it does not even mumble this but silently leaves you puzzling.

A somewhat useful workaround for these cases is -like which compares the value of a variable based on its toString() result as Jason pointed out (thanks for correcting me). Have a look:

$b -like 1
False
$b -like 'Running'
True

So this conclusion helped solve my initial problem. By replacing -eq with -like, all worked fine:

Get-Service | Export-CliXML $home\services.xml
$services = Import-CliXML $home\services.xml
$services
$services | Where-Object { $_.Status -like 'Running' }

Have a great 2010 and keep tuned,
hey and go ahead and try our PowerShellPlus smart PS console if you are at it, Richard and I would appreciate it!

Tobias

P.S.

Richard just commented on my post: "VERY geeky, but nice!" So let's boil it down to one sentence: "If -eq does not seem to work, try -like instead."

Cancelling a Pipeline

Tobias — Fri, 01 Jan 2010 10:17:00 GMT

Once a PowerShell pipeline runs, it runs. There is no way of cancelling it. This is bad news. Or is there a way?

Runaway Pipeline

Just imagine you are retrieving tons of data to find a piece of information. Once you found it, you do not need to retrieve the rest. Since you cannot cancel the pipeline, you are stuck and have to wait until the initial pipeline command finishes.

There is a cmdlet that seems to provide an answer: Select-Object. This cmdlet has a parameter called -First, so you could try and output only the first n elements like this:

PS> 1..10 | Select-Object -First 5
1
2
3
4
5

As it turns out, though, Select-Object simply filters out the first 5 elements but does not stop the pipeline:

PS> 1..10 | % { Write-Host "PROCESSING $_" -ForegroundColor red ; $_ } |
Select-Object -First 5 | % { "Outputting $_" }
PROCESSING 1
Outputting 1
PROCESSING 2
Outputting 2
PROCESSING 3
Outputting 3
PROCESSING 4
Outputting 4
PROCESSING 5
Outputting 5
PROCESSING 6
PROCESSING 7
PROCESSING 8
PROCESSING 9
PROCESSING 10

Or in a more practical example, the next line will continue to run even though you have received the information you were after, causing a delay and unnecessary system load:

PS> Get-EventLog Application | Select-Object -First 5

Index Time EntryType Source InstanceID Message
----- ---- --------- ------ ---------- -------
53391 Jan 16 02:53 Error TracerX - PowerSh... 1001 ...
53390 Jan 16 00:04 Information VSS 8224 ....
53389 Jan 15 23:51 Information VSS 8224 ....
53388 Jan 15 22:39 Information Outlook 1073741856 ..
53387 Jan 15 22:38 Information Outlook 1073741856 ...

A Surprising Answer: Yes you can!

With a little trick, you can cancel the pipeline and stop any cmdlet upstream immediately. You need to use continue.

The next line "simulates" Select-Object -First by using a Foreach-Object (alias: %) statement. It counts up and once it received more than 5 elements, it calls continue. There is another Foreach-Object clause right before it, showing you the objects traversing the pipeline. As you will see, this approach not just filters the output but also cancels the upstream cmdlets.

PS> 1..10 | % { Write-Host "PROCESSING $_" -ForegroundColor red ; $_ } |
% { $i=0 } {$i++; if ($i -gt 5) { continue }; "Outputting $_" }
PROCESSING 1
Outputting 1
PROCESSING 2
Outputting 2
PROCESSING 3
Outputting 3
PROCESSING 4
Outputting 4
PROCESSING 5
Outputting 5
PROCESSING 6

You may be wondering why you need to call continue to not continue - doesn't exactly sound right. Continue was originally designed to skip a loop or continue with the next statement after an exception was trapped, so its name does make sense. The only problem with this is that in the previous example, continue stops everything, so if you use it inside a script, the entire script gets cancelled. Not good.

This is because we called continue directly, not from within a loop or an error handler, so continue really continues with the next statement outside the loop or trap, and since there is none, everything stops. The real problem is that PowerShell does not identify a pipeline as a loop which it really is. If it did, we would be done already. Instead, we need to work around it by wrapping the pipeline inside a dummy loop like this:

PS> for ($x=1; $x -lt 2; $x++) {
1..20 | % { Write-Host "Processing $_" -ForegroundColor red ; $_ } |
% { $i=0 } {$i++; if ($i -gt 5) { continue }; "Outputting $_" } }
Processing 1
Outputting 1
Processing 2
Outputting 2
Processing 3
Outputting 3
Processing 4
Outputting 4
Processing 5
Outputting 5
Processing 6

Here again is a more practical example. It will output all events from your Application log until it hits one with an InstanceID of greater than 10000. Once hit, it cancels the entire pipeline upstream and continues with the next command:

for ($x = 1; $x -lt 2; $x++) {
Get-Eventlog Application |
% {
$_
if ($_.InstanceID -gt 10000) { continue }
}
}

Index Time EntryType Source InstanceID
----- ---- --------- ------ ----------
53391 Jan 16 02:53 Error TracerX - PowerSh... 1001
53390 Jan 16 00:04 Information VSS 8224
53389 Jan 15 23:51 Information VSS 8224
53388 Jan 15 22:39 Information Outlook 1073741856

Wrapping the pipeline inside a dummy loop looks ugly but is key to using continue not just in regular loops but also to immediately cancel the pipeline.

Beware of the Spirits you called...

This is a hack. It works beautifully if done right, but it also poses some risk. Here is why.

When you call continue, somehow all upstream cmdlets (the ones before the continue) need to notice that continue has been called and respond to it. In other words, continue needs to actively communicate to all previous cmdlets in the pipeline that they need to stop because the pipeline is shutted down. This is necessary in order to gracefully shut down all upstream cmdlets. You do not want to just pull the plug on them.

Most cmdlets do that just fine. Sometimes, though, this red alert gets lost, so upstream cmdlets continue to run and are surprised when the pipeline is taken away under their feet. When cmdlets get surprised, they throw an exception (a red bulk of text with glibberishy technical stuff in it). This is the worst it can get, fortunately. No chance of blowing something up.

The message is sent to upstream cmdlets by throwing a PipelineStopped exception. Upstream cmdlets receive this exception. If they are done right, they will do two things:

abort whatever they were doing
passing on the exception so the next cmdlet gets a chance to see it and act accordingly

The problem can occur when a cmdlet fails to do either one.

If it does not abort, it might throw an exception because the pipeline is gone with all the side effects arising from this
If it does not pass on the exception, the cmdlet before this one might throw an exception for the very same reason: pipeline is gone

How come a cmdlet would not pass on the exception? Easy. If the author implemented a generic trap and catches all exceptions, and if the author chose continue at the end of his trap, the exception then is "handled" and no longer bubbles up to the other cmdlets in the pipe. You can illustrate this quite easily:

for ($x = 1; $x -lt 2; $x++) {
Get-Eventlog Application |
& {
process {
trap { Write-Host -fore Red "I ate the exception so the upstream cmdlet continues: $_"; continue }
$_
}
} |
% {
$_
if ($_.InstanceID -gt 10000) { continue }
}
}

When you run this, the scriptblock following Get-Eventlog has its own trap. When you call continue downstream, it catches the PipelineStopped exception and handles it. This way, Get-EventLog never gets to see it and happily continues to spit out results, causing additional exceptions for any piece of result that no longer can be handled.

To correct this, the trap would have to call break instead of continue to signal back the exception it received.

Creating your own Stop-Pipeline command

Now, you may argue this concept creates spaghetti code and makes the pipeline look ugly, and you are right. When you use continue, having to wrap the whole enchilada in a loop is not exactly esthetic. It also violates the modular philosophy of PowerShell and instead uses the old and ugly "onion" concept. As it turns out, you do not need the wrapping loop. Think on.

As you have seen, upstream cmdlets are cancelled by sending them a PipelineStopped-Exception. In the previous examples, I did this indirectly using continue, and since continue can only live inside a loop, I had to place a loop around the pipeline. Why not throw a PipelineStopped-Exception myself and not use continue in the first place? As it turns out, this works just as well. So in order to retrieve only Application log events until I find one with InstanceID greater than 10000, I could do this:

filter Stop-Pipeline([scriptblock]$condition={$true}) {
$_
if (& $condition) {
Throw (New-Object System.Management.Automation.PipelineStoppedException)
}
}

Get-EventLog Application | Stop-Pipeline { $_.InstanceID -gt 10000}

I use a filter called Stop-Pipeline which takes a condition. When the condition is met, the filter raises the PipelineStopped-Exception directly. It gets passed on to the upstream cmdlets and cancels them. No need for continue, no need for a wrapper loop, and a very straight-forward pipeline design.

Since this kind of exception is a terminating error, the exception will cancel the entire script, so you should wrap the pipeline in a try/catch-block like this:

'Start'
try {
Get-EventLog Application | Stop-Pipeline { $_.InstanceID -gt 10000}
} catch {}
'Done'

Unfortunately, when the pipeline is cancelled this way, it also cancels an important last task a pipeline usually does: should you want to store the result in a variable, this no longer happens. Take a look:

$result = "No result"
try {
$result = Get-EventLog Application | Stop-Pipeline { $_.InstanceID -gt 10000}
} catch {}

$result

The answer is: "No result". Bummer.

Going back to the continue approach, it turns out this cancels the pipeline more gracefully after all, so the final solution looks like this:

filter Stop-Pipeline([scriptblock]$condition = {$true}) {
$_
if (& $condition) {continue}
}

$result = "No result"
$result = do {

Get-EventLog Application | Stop-Pipeline { $_.InstanceID -gt 10000}

} while ($false)
$result

Conclusion

Don't be overwhelmed by this. Being able to stop a pipeline can be a wonderful trick. Just make sure you "know" the cmdlets involved.

As long as they honor and pass on the PipelineStopped exception, you are fine. So in your cozy PS shop at your workbench, test the pipeline you designed and make sure no exceptions are raised by upstream parts of your pipeline so that you can safely assume they know how to pass on the exception correctly. Once you know that, you also know that your particular pipeline is safe for this kind of technique. Thanks to Jaykul (fellow PS MVP) to pointing me to the PipelineStopped-side effects.

It really boils down to this simple filter:

filter Stop-Pipeline([scriptblock]$condition = {$true}) {
$_
if (& $condition) {continue}
}

Make sure you embed your pipeline in a do/while-block if it runs as part of a script so that only the particular pipeline is cancelled:

$result = do {
Get-EventLog Application | Stop-Pipeline { $_.InstanceID -gt 10000}
} while ($false)

Notice that Stop-Pipeline assigns a default script block to $condition so if you call Stop-Pipeline without argument, it will pass the first object through the pipeline and then cancels it:

Get-Process | Stop-Pipeline

Maybe we will see this functionality as a built-in cmdlet in a future release of PowerShell. Meanwhile, simply copy & paste it into your scripts whenever you need it.

Have fun! Hey, and watch out for PowerShellPlus 3.1! Did you try the beta yet?

And one more thing: if you happen to be located in Germany, Switzerland or Austria, rent me!

Cheerio

Tobias
PowerShellPlus-Editor Architect

Part 1 - What's New In PowerShell V2: Computer Cmdlets

Tobias — Mon, 28 Sep 2009 01:03:00 GMT

PowerShell V2 contains a lot of new cmdlets and has added many more useful parameters to existing cmdlets. In this series, we look at all the new things you can now do with PowerShell V2.

How do I know which PS Version I run?

It's pretty easy to find out whether PowerShell is installed or not: simply press WIN+R and try to run powershell.exe. If PowerShell is installed, the next thing you probably want to know is which version you are running. The best thing is to check the automatic variable $psversiontable which is present only in V2 and tells you the exact version.

Alexander has created a function called Get-PSVersion for that (http://powershell.com/cs/media/p/2617.aspx ), and we also have a Power Tip for this (http://powershell.com/cs/blogs/tips/archive/2009/09/11/which-powershell-version-am-i-running.aspx).

Should you find that you are still using PowerShell V1, you may want to upgrade to V2. V2 is the default version on Windows 7 and Windows Server 2008 R2 but is also available down to Windows XP. Currently, Microsoft has made available PowerShell Version 2 RC for these older platforms (avoid PowerShell V2 CTP3 as this version is outdated by now and still had some limitations with remoting).

Eleven New Computer Cmdlets

PowerShell V2 contains eleven new cmdlets with the noun Computer (or related to it):

PS> Get-Command -Noun *computer* | Format-Table Name, PSSnapin

Name                             PSSnapIn
----                             --------
Add-Computer                     Microsoft.PowerShell.Management
Checkpoint-Computer              Microsoft.PowerShell.Management
Disable-ComputerRestore          Microsoft.PowerShell.Management
Enable-ComputerRestore           Microsoft.PowerShell.Management
Get-ComputerRestorePoint         Microsoft.PowerShell.Management
Remove-Computer                  Microsoft.PowerShell.Management
Reset-ComputerMachinePassword    Microsoft.PowerShell.Management
Restart-Computer                 Microsoft.PowerShell.Management
Restore-Computer                 Microsoft.PowerShell.Management
Stop-Computer                    Microsoft.PowerShell.Management
Test-ComputerSecureChannel       Microsoft.PowerShell.Management

With these cmdlets, you can basically do three things: manage domain join, restart and shutting down machines and manage system restore points.

Domain And Workgroup Join And Unjoin

If you ever wanted to automatically join computers to a new domain or a peer-to-peer-workgroup, you can now do so using Add-Computer. To make the change happen, append Restart-Computer which is generally a great way of restarting machines:

add-computer -domainname Domain01; restart-computer

add-computer -workgroupname WORKGROUP-A

Add-Computer always works on the local computer. You cannot use it to join a remote computer. To get more examples, use this:

Get-Help Add-Computer -examples

To remove a computer from a domain or workgroup, use Remove-Computer. And if you'd like to reset the computer password, use Reset-ComputerMachinePassword. You can even diagnose and repair the secure channel used by a domain-joined client and his domain. Test-ComputerSecureChannel will tell you if everything is fine, and when you add the switch parameter -repair, the channel is automatically repaired.

Restarting And Shutting Down Machines

Restart-Computer allows you to restart one or more machines, locally and remote. To simply restart your local machine, use this:

restart-computer

To restart a bunch of computers remotely and also your own machine, use the -computerName parameter and a comma-delimited list:

restart-computer -computername Server01, Server02, localhost

To shut down a machine (turn it off), use Stop-Computer instead of Restart-Computer. It works the same way.

If you want to log off users (rather than restarting or stopping machines), use Get-WMIObject Win32_OperatingSystem and take advantage of its Win32Shutdown() method which also works locally and remotely.

Managing Restore Points

Restore points are system snapshots designed to conserve some system state so in case something bad happens, you can easily recover. PowerShell now allows you to manage restore points through cmdlets. Note that managing restore points requires Admin privileges.

To list all available restore points created earlier, use Get-ComputerRestorePoint:

PS> Get-ComputerRestorePoint

CreationTime           Description                    SequenceNumber    EventType         RestorePointType
------------           -----------                    --------------    ---------         ----------------
03.07.2009 05:21:46    Windows Update                 18                BEGIN_SYSTEM_C... 18
09.07.2009 20:51:12    Installiert TIPCI              21                BEGIN_SYSTEM_C... APPLICATION_I...
10.07.2009 08:51:09    Windows Update                 22                BEGIN_SYSTEM_C... 18
10.07.2009 12:16:03    Snagit 9.1.2 wird installiert 23                BEGIN_SYSTEM_C... APPLICATION_I...
14.07.2009 09:34:59    Windows Update                 24                BEGIN_SYSTEM_C... 18
16.07.2009 17:51:09    Windows Update                 25                BEGIN_SYSTEM_C... 18
17.07.2009 01:11:21    Installed Microsoft Office ... 26                BEGIN_SYSTEM_C... APPLICATION_I...
17.07.2009 10:27:10    Installed Idera PowerShellP... 28                BEGIN_SYSTEM_C... APPLICATION_I...
18.07.2009 11:40:42    Windows Update                 29                BEGIN_SYSTEM_C... 18
19.07.2009 00:42:36    Windows Update                 30                BEGIN_SYSTEM_C... 18
19.07.2009 00:48:06    Windows Modules Installer      31                BEGIN_SYSTEM_C... APPLICATION_I...
22.09.2009 13:48:14    Installed PowerShell Commun... 60                BEGIN_SYSTEM_C... APPLICATION_I...
27.09.2009 22:47:32    Installed SystemScripter       64                BEGIN_SYSTEM_C... APPLICATION_I...

The list will show all available restore points. SequenceNumber is the unique identifier for any given restore point, and you can use this id to selectively access an individual restore point. RestorePointType tells you who has created the restore point, and the switch parameter -lastStatus tells you the result of the last restore point operation.

To manually create a new restore point, for example at the beginning of a critical system change, use Checkpoint-Computer. If you'd like to restore the system to a previous restore point, use Restore-Computer and specify the restore point you want to use. To change the scope of your restore points, use Enable-ComputerRestore and Disable-ComputerRestore. These cmdlets manage which drives should be included or excluded in your snapshots. And if you'd like to quickly check results with the GUI, call rstrui.exe.

What's Next?

All of the new cmdlets covered here live in the Microsoft.PowerShell.Management Snapin. This snapin isn't new, it was already part of PowerShell V1. While in PowerShell V1 it contained 47 cmdlets, it now delivers a solid 92 cmdlets - 45 new cmdlets! We looked at 11 new cmdlets, leaving 34 new cmdlets to check out in the next parts. Hang in!

Cheers

Tobias

Removing Private Key From Certificate

Tobias — Tue, 08 Sep 2009 14:58:00 GMT

Ok, this may be not be the typical every-day question but I just had a friend ask how to remove a private key from a digital certificate. As it turned out, this is tricky.

Accessing Certificates

PowerShell does provide easy access to all of your installed digital certificates through its cert: drive. So you could easily go ahead and search for any certificate. Let's say you have a certificate installed with 'test' in its subject name. Then this would be a way to get your hands on it:

dir cert:\ -recurse | ? { $_.Subject -like '*test*' }

To pick the first certificate found, you could store the result as an array and pick the first element like this:

$certs = @(dir cert:\ -recurse | ? { $_.Subject -like '*test*' })
$cert = $certs[0]
$cert

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

Thumbprint Subject
---------- -------
BE20521E22EA2920478F0DC9E172B0F1A431E054 CN=test1

Now, you could access the private key stored in it:

PS> $cert.HasPrivateKey
True
PS> $cert.PrivateKey

PublicOnly           : False
CspKeyContainerInfo : System.Security.Cryptography.CspKeyContainerInfo
KeySize              : 1024
KeyExchangeAlgorithm :
SignatureAlgorithm   : http://www.w3.org/2000/09/xmldsig#rsa-sha1
PersistKeyInCsp      : True
LegalKeySizes        : {System.Security.Cryptography.KeySizes}

Unfortunately, there is no way of deleting the private key (at least none I found). This is strange because the oldfashioned CAPICOM used with VBScript did have the ability to remove a private key from a certificate.

After searching MSDN for a while I decided to head another route which coincidentally demonstrates some other useful tricks with certificates. In order to remove the private key, I decided to export the existing certificate without private key, then delete the installed certificate and re-import it from the exported data. Here is how you do that:

Step 1: Get The Certificate

First, make sure you retrieve the certificate you want to strip the private key from. You have seen already how to do that. For example:

$cert = @(dir cert:\CurrentUser\My -recurse | ? { $_.Subject -like '*TEST*' })[0]

You may want to check whether the certificate has a private key at all:

PS> $cert.HasPrivateKey
True

Step 2: Export Certificate Without Private Key

Next, you need to export the certificate without the private key and store it as byte array. That is pretty easy because the certificate has an Export() method you can use:

# export certificate
$bytes = $cert.Export('Cert')

Step 3: Delete Installed Certificate

Now, to get rid of the private key, delete the installed certificate. Of course, before you do that you should be aware of the consequences. You are losing the private key this way (but, after all, that was the idea). You also need admin privileges so be sure to launch PowerShell in elevated mode if you are using UAC.

Deleting a certificate is not just as straight-forward because the cert: provider implemented in PowerShell does not support deleting certificates. So you need to resort to the raw .NET framework methods. First, open the certificate store the certificate resides in (read/write mode) and then remove the certificate:

# delete certificate
$store = new-object system.security.cryptography.x509certificates.x509Store 'My', 'CurrentUser'
$store.Open('ReadWrite')
$store.Remove($cert)

Step 4: Re-Import Certificate w/o Private Key

Since you exported the certificate without private key, all you need to do is re-import the exported certificate. It will be restored but has now no private key anymore. To re-import a certificate, simply create a .NET x509Certificate2Collection object and use its Import() method to read in the byte array you exported earlier. BTW you could also specify a path to a .cert file to import regular filebased certificates this way. Then, add the first element of your certificate collection to the certificate store you deleted the certificate from:

# re-import certificate
$container = new-object system.security.cryptography.x509certificates.x509certificate2collection
$container.Import($bytes)
$store.Add($container[0])

Step 5: Clean Up

Done. Almost. For sanitary reasons, don't forget to close the certificate store you opened earlier:

$store.close()

That's it: you successfully removed the private key from the certificate you chose. You also learned a couple of new ways to deal with certificate stores using raw .NET objects. Specifically, you have seen how you can delete and export/import certificates. Hope that helped...

Cheers

Tobias

Test-Driving Remoting In Windows 7

Tobias — Sat, 29 Aug 2009 08:32:00 GMT

Remoting is among one of the most popular and powerful new PowerShell V2 features. What this means is that starting with PowerShell V2 (and starting with Windows 7 only because downlevel OS will support V2 remoting only in a future update), you can connect to other PowerShell V2 machines and run commands, scripts and jobs remotely. Very cool.

Unless you work in a configured AD-Environment, setting up and test-driving remoting isn't that easy, though. By default, in a peer-to-peer environment, remoting is dead. I'd like to show you today in three easy steps how to set up a test peer-to-peer environment that you can use to play, show off and demo V2 remoting.

This will show you how to set up the "new" V2 remoting using WinRM which requires PowerShell V2 on both ends.
Yes, there are other remoting techniques such as the old DCOM which will continue to work and neither require WinRM nor PS V2 (for example, use Get-WMIObject -computerName 10.10.10.10 to connect to that machine using classic DCOM)

What you need to make it happen...

To play with V2 remoting in a peer-to-peer scenario, this is what you need:

Ingredients:

2x Windows 7 (one of which can be running inside Windows Virtual PC if you like)
both machines may not be joined to a domain(!)

Things are turned off out-of-the-box...

First of all, figure out the IP addresses assigned to both machines and make sure they can reach each other via network. In this example, I will be using machine A with 192.168.2.105 and machine B with 192.168.2.107, so make sure you replace the IP addresses with yours.

If you'd like to establish a remote connection from machine A to machine B, you would use Enter-PSSession, but if you try like this:

Enter-PSSession 192.168.2.107

the cmdlet will bark at you and come up with all kinds of reasons in red letters stating why what you are trying to do is absolutely ridiculous.

The simple fact is: the mechanism behind remoting which is called WinRM has not yet been set up to accept a remoting connection nor is it likely that the WinRM service is running at all yet. WinRM is secure by default, so you need to start it and open doors manually. What it also means is that you and only you will be liable if things go wrong and you trash your corporate infrastructure. So to prevent this from becoming a career-limiting move, you should set up a separate test environment to play with.

Step 1: Enable WinRM on both machines

The first thing you want to do is call Set-WSManQuickConfig. This is actually your door-opener, and to successfully launch this command, you will need to (a) have admin privs and (b) be sure you do want to open the doors. Specifically, the command does the following:

It makes sure the WinRM service is running and sets the startmode to Automatic so WinRM will be started automatically in the future. This enabled the computer to be connected via WinRM
It sets up a WinRM "listener" which is listening to incoming WinRM requests via http: from any IP address
It sets up a firewall exception so incoming WinRM requests aren't rejected by your firewall any longer and make it to the WinRM service

As you can see, these really are door-openers, and unless you are working with a test system in your closet, you may want to find out more about the possible security implications. Note also that Set-WSManQuickConfig might return an Access Denied if you try and run it on a machine that is domain-joined. Everything you read here applies to a simple peer-to-peer scenario only. Domain-joined machines are a different ballgame because they use Kerberos to securely authenticate requests and chances are in a domain-based environment you do not need all of this anyway because your IT department has decided for you.

Once you ran Set-WSManQuickConfig on both machines, your Enter-PSSession command still fails because again, for security reasons, WinRM rejects requests unless they are guarded by Kerberos or an equally safe mechanism. However, if you did everything right, both machines can now at least use WinRM to talk to each other:

Test-WSMan 192.168.2.107

This should return some protocol information.

Step 2: Add Computers to TrustedHosts list

Next, since you are working in a basic peer-to-peer environment, you need to convince WinRM that it is actually safe to accept requests from the other machine. You do this by adding the machine IPs to the list of so called "trusted hosts" - or, if you want to open the door even more, simply add a "*" to that list and allow any IP to talk to the machine. So on both machines, execute this:

Set-Item WSMan:\localhost\client\trustedhosts * -force

Step 3: Enjoy!

Once you did this last step, you are up and running. When you now enter

Enter-PSSession 192.168.2.107

after a couple of seconds of finger crossing (while WinRM sets up the remote PS session), you see the PS prompt of the remote system and now can work remotely on that machine. Everything is working fine now, and you can also explore all the other fine remoting features. Dunno which remoting features there are? Hang in, we'll be back shortly with more examples!

Oh, by the way, this will only work if you have created the same user account with the same password on both machines (remember, we are in a peer-to-peer environment here). Of course, the user on machine A initiating the connection needs to have admin privs on the target machine. To authenticate as someone else, use -credential (Get-Credential) as parameter.

ff you are wondering how to leave the remoting session you just opened, simply type:

exit-pssession

Have a wonderful day (and fun with the awesome V2 remoting!)

Yours, Tobias

Using PowerShell in Windows 7 - Part 1

Tobias — Thu, 16 Jul 2009 14:47:00 GMT

Windows 7 is going to be the first operating system that actually ships with Windows PowerShell (rather than having to install PowerShell separately) and comes with the new PowerShell V2. Enough great reasons to take a closer look.

Ín this first part of what is going to be an ongoing series, we start small. You will only learn about one new V2 feature: Modules. You will, however, get all the information you need to start playing with PowerShell on W7. As we continue, we dive deeper and eventually touch all of the new features - and believe me, there are a lot!

Pinning PowerShell

To launch PowerShell, you could press WIN+R and enter powershell. That's ok. That's how we did it with the old console, too. However, in W7 there are smarter ways.

One is to pin PowerShell to the new taskbar. Simply right-click the PowerShell icon in the taskbar (which appears automatically once you launch PowerShell) and choose "Pin this program to the taskbar". That's it. Now, you got a PowerShell icon in your taskbar, and it stays there even if no PowerShell window is open anymore. And yes, pinning an application to the taskbar has a *lot* of additional advantages, it's not just good for making applications more accessible. Hang in a second.

You first may want to move the new PowerShell icon in your taskbar more to the left. It is more organized that way when all pinned applications are located on the left side. If you do move the PowerShell icon to the very first position in your taskbar, you now can even launch PowerShell without touching the mouse, simply by pressing WIN+1 (and, uhm, yes, you can press WIN+2 if it is the second icon in your taskbar. Go figure.).

Pinning PowerShell to the taskbar makes the console prettier, too. It will launch with the typical blueish background and in a larger console. Even more benefits are waiting for you in its new jump list. Right click your PowerShell icon (or drag it towards the desktop) to open the jump list. It contains all the commands you may ever need to launch PowerShell: launch it with or without administrator privileges, launch the PowerShell ISE, launch it with all modules auto-imported, or simply open the electronic manual. Hey, that's a convenient one-stop-shop.

Exploring Modules

Windows 7 includes not just PowerShell V2 but also comes with a number of modules. Modules are new in PowerShell V2. They are actually extensions much similar to the V1 Snapins. Unlike Snapins, Modules do not require installation. To see the modules Windows brings along, fire up this command:

Get-Module -ListAvailable

Windows 7 comes with these modules preconfigured: AppLocker (allows you to control which applications and installation packages a user can run, based on local or domain-wide policies), BitsTransfer (opens up the intelligent background transfer service to you so you can silently upload and download large files in the background), PSDiagnostics and TroubleshootingPack (which both refer to the built-in PowerShell-based self-diagnosis we will cover later). You may also see a module named GroupPolicy which comes with the R2 GPMC and enables you to view, analyze and even create group policy objects and links.

There are even more modules available when you install RSAT for Windows 7. RSAT (Remote Server Administration Tools) is like adminpak.msi in earlier windows versions and installs all the administration tools you may be used to. In addition, it also installs a module called ActiveDirectory with tons of Cmdlets to manage your Active Directory - finally!

Watch out: Once you downloaded and installed RSAT, the Active Directory module still isn't there. It is not installed by default. You need to open control panel first, go to Software and then look at the available Windows features. In this list, you will eventually find the Remote Server Administration Tools, and when you dig deeper into its options, you stumble over the PowerShell ActiveDirectory module. Check it, and click OK. A minute later, PowerShell finds and lists the new ActiveDirectory module.

Using Modules

Before you can use a module, you need to import it using Import-Module. So for example, to use the new Cmdlets contained in the AppLocker module, fire up this one:

Import-Module AppLocker

Or, you open the jump list of your pinned powershell console as described earlier and open PowerShell with all available modules preloaded automatically. Note however that this console will also enable all Admin rights.

To check out which new Cmdlets you got, use this line:

Get-Command -Module AppLocker

And to see a bunch of real-life scenarios and examples, simply extend the line and use the good old pipeline to pipe the Cmdlets to Get-Help:

Get-Command -Module AppLocker | Get-Help -example

What's Next?

I guess this is a pretty quick start to begin playing. You now know how to pin PowerShell, open it with and without admin privileges and modules. You also know how to find out which modules exist, which commands exist in each module, and how to get help for them. Ain't enough? In the next part, we'll look at remoting and how to enable it in a simple peer-to-peer test environment:
Part 2: Make remoting work in Windows 7

Have a great weekend!

Tobias

Embedding native commands

Tobias — Sun, 24 May 2009 21:13:00 GMT

One little known fact is that you can use the PowerShell pipeline to actually feed information into a native command. Why would that be breath taking?

Automating Native Commands

Because there are tools like DiskPart. They are important but they only support an interactive mode or batch files. With the PowerShell pipeline, you can feed your commands into the native command as if you had typed them in interactively. Now, isn't that awesome?

Before you try for yourself, be aware that DiskPart requires admin privileges. So on a box with UAC, make sure you launch PowerShell with full admin rights in the first place. If you don't, DiskPart will elevate itself automatically and break the pipeline.

Let's try and get the list of drives:

"list disk" | diskpart

It works. The result is plain text, and of course you probably get a lot more information than you wanted. Fortunately, DiskPart indents the important information so you could add a little filter, letting through only lines that start with two blank spaces:

"list disk" | diskpart | ? { $_.StartsWith(' ') }

Not bad. So the first learning point here is: whenever a command (any command, not just DiskPart) requires interactive information, simply place it onto the pipeline and pass it on to the command. It is a bit like writing to StdIn in earlier days, just a lot easier.

Creating New Virtual Hard Drives (VHDs)

The really exciting part starts when you combine batches of commands to do more complex things. For example, I played a bit with Windows 7 virtual hard drives (VHD). The following code will generate a new VHD for you:

$path = Read-Host "Enter Path to VHD"
$label = Read-Host "Enter Drive Label"
$maximum = Read-Host "Enter maximum Size in MB"

$type = "fixed"

$command= @"
create vdisk file="$path" maximum=$maximum type=$type
select vdisk file="$path"
attach vdisk
create partition primary
assign letter=$letter
format quick label="$label"
"@

$command|
DiskPart |
Where-Object { $_.Length -gt 0 } |
Foreach-Object { Write-Progress -Activity "Creating New VHD" -Status $_ -Id 1}

Adding "UI" to Native Commands

What you see here is a batch of six commands. DiskPart accepts them step by step and executes the appropriate action.

Normally, DiskPart would output progress information directly to the console. Here, Write-Progress takes the results from DiskPart in real time as they occur and displays them in a neat progress bar, preventing garbage information to appear in your console.

The second learning point is: pipe the results from any native command to Write-Progress, and you will immediately get a nice output. Low hanging fruits to convert a nasty old command line tool into something more sophisticated.

New-VHD - a home-made new PowerShell function for Windows 7

Taking all of this and combining it, here is a quick and dirty new PowerShell function called New-VHD. It takes care of the most common errors (target file already exists, drive letter already exists) and uses DiskPart (on Windows 7) to create new virtual hard disks.

function New-VHD {
param($path, $maximum=200, $letter='r', $label='New Disk', $type='fixed')

if (test-path $path) {
Throw "Target path '$path' exists and cannot be overwritten."
}

if (test-path "$($letter):\") {
Throw "Drive letter '$letter' is taken. Choose another one."
}

$command= @"
create vdisk file="$path" maximum=$maximum type=$type
select vdisk file="$path"
attach vdisk
create partition primary
assign letter=$letter
format quick label="$label"
"@

$command|
DiskPart |
Where-Object { $_.Length -gt 0 } |
Foreach-Object { Write-Progress -Activity "Creating New VHD" -Status $_ -Id 1}
}

One important thing to note: Whenever you batch-process more than one command, you run into the risk that something unexpected happens. For example, when you try and create a new VHD and this fails, all subsequent commands will still run and maybe cause undesired effects. So there is some risk attached to this. This is why you should take this into account and wrap appropriate error handling around it.

Have fun and don't forget to enjoy the sun!

-Tobias

Test driving Windows 7 RC and PowerShellPlus 3.0 on Virtual PC

Tobias Weltner — Sat, 02 May 2009 12:00:00 GMT

Windows 7 RC is out, and finally a bug has been fixed that prevented PowerShellPlus from running.

If you'd like to play with our brand new PowerShell Plus 3.0 on the brand new Windows 7 Release Candidate, here is what you need:

First, get Windows 7 RC. MSDN and TechNet subscribers can download it via their subscriptions. Microsoft announced a publicly available version starting May 5.

Next, if you want to install it in a virtual environment, be sure you have upgraded to VirtualPC 2007 SP1 (6.0.192.0). Older versions of VirtualPC 2007 will present a blue screen once you install the VM additions. You can get VirtualPC 2007 SP1 here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=28c97d22-6eb8-4a09-a7f7-f6c7a1f000b5&displaylang=en

(thanks Alex for this link!)

Finally, download a free trial copy of PowerShell Plus 3.0 here:

http://www.idera.com/Products/PowerShell/PowerShell-Plus/

Have fun!

Tobias

Using QuickClick Solutions in Beta2

Tobias Weltner — Mon, 09 Mar 2009 08:16:00 GMT

PowerShell Plus Beta2 has a significant new feature: QuickClick solutions. Since it is new and pretty cool, I'd like to give you a quick walk-through.

QuickClick Solutions are trees that can store either simple one-liner commands or complex scripts. With a QuickClick Solutions Tree, you can

Reminder: quickly and conveniently save commands you often need
Organizer: use the tree as your personal PowerShell script organizer
Solutions Pack: transfer knowledge from an experienced PS user to beginners
Demo: create interactive demos
Share: share PowerShell expertise from a specific area with others

Showing And Hiding QuickClick Solutions

To show or hide the QuickClick Solutions panel, simply hit CTRL+I or use View-QuickClick Solutions. Note that this feature was introduced in version 2.1.0.45 (Beta2). You may want to upgrade to that version.

The tree panel is a regular docking window so you can pin, dock and undock the panel. However, the best way is to keep the tree docked at the left side and use CTRL+I to show and hide when necessary. Position your mouse cursor over the right border of the docked control to make it wider.

Using Existing QuickClick Solutions

From an end-users perspective, all you need to do is to expand a QuickClick solutions tree and select the command you would like to try. When you hover over a node, a tooltip appears and shows you a preview of the code stored in this node, along with a description (if the node has one).

You can either double-click a selected tree node or select it and press ENTER. In both cases, the command stored inside the selected node is typed into your console. Press ENTER again to actually execute the code.

Note: The tree will never execute code right away because you and only you can decide whether code is beningn or not and whether you want to execute it. This is why the tree only inserts code into the console but leaves it to you to actually press ENTER to execute it. If you must execute code in one step, hold CTRL while double-clicking a node.

There are a couple of tricks you can use:

When you insert a node code by pressing ENTER, you typically press ENTER again to try out the code. Then, you can press TAB to return selection back to the tree. This way, you do not need to use the mouse to work your way through a tree.
You can drag & drop a node into any text-based program that accepts text drag&drop such as the script editor.

Reorganizing Your Tree

You can easily reorganize your tree in any way you want. Simply drag and drop tree folders or tree nodes to other locations in your tree. This way, you can change order, place items inside a container, etc.

To delete folders or nodes you no longer need, select them and press DEL.

Note: Currently, you cannot select more than one item in the tree which is a limitation of the underlying treeview control.

Adding New Items To Your Tree

Your QuickClick Solutions Tree can grow. To add new folders or items, right click the folder or item you would like to use as a starting point, then choose New in the context menu. Or, use these keyboard shortcuts:

CTRL+SHIFT+F: New Folder
CTRL+SHIFT+L: New One-Liner
CTRL+SHIFT+N: New Script

To rapidly add code to your tree, you can also create a new one-liner that automatically contains the text you entered into the console or a script that contains the script actively open in the script editor.

Here is how you add a new one-liner:

Play with code in the interactive console until it really works the way you like.
Press ARROWUP to bring back the code you entered last into the console
Press CTRL+SHIFT+C to create a new One-Liner node in your solutions tree. Its name is selected so you can immediately assign it a new name.
Optionally, drag and drop the new node to a better position in your tree
Whenever you select your new item and press ENTER, the code you saved is typed into the console

With this approach, you can rapidly create demos, too.

And here is how you add a new script node:

Open the built-in editor, i.e. press CTRL+E
Load a script, or create a script and make sure you save it
Go back to the console, and press CTRL+SHIFT+S. A new script item is inserted into the tree. Its name is selected so you can assign a better name.

Note: When you insert a script into the tree, the node gets a blue PS icon. This is a script link. The node points to your actual script. Script nodes are a great way for you to organize your PowerShell scripts because once you have inserted a script file into the tree, you can safely drag&drop it inside the tree and categorize it into whatever folder you want without touching the original script the node points to.

To make organizing even easier, you can also drag and drop PS1 script files right into the tree.

Alternatively, you can embed scripts into the tree, too. This way, the tree stores the script code, and the external script reference is no longer needed. Embedding scripts is cool when you plan to share your tree with others. To embed a script, right-click it and choose Embed. It turns into a green icon.

Creating A New QuickClick Solutions Tree

You can create and use as many QuickClick Solutions trees as you want. To create a new tree, To create a new solutions tree, right-click the name of an existing tree and choose Add New. A submenu opens:

Blank Panel: opens a new blank panel. This is best when you plan to create a new panel from scratch
Load Panel: enables you to open a panel you saved before. Use this if you share trees and would like to load a new one you have received from a friend
Factory Default: Preloads the standard panel we ship with the product

Note: You can copy and paste items between trees. Simply select a node or container, then press CTRL+C to copy. Select a different panel and different tree, and press CTRL+V to insert the selected item.

Exporting Trees To Share With Others

To export a tree, all you really need to do is to save it as XML to file. Right-click the tree to open a context menu with the Save As-command. Once saved, you simply share the XML file with others (see below).

Note: When you export a tree, make sure you convert all script nodes to embedded scripts so you do not break links between your tree and external scripts. There is currently no way to do that automatically yet.

Do not use Save As and save the tree to a USB stick directly because when you remove the stick and restart PowerShellPlus, it would no longer find the tree file and remove it automatically from your panels.

Loading And Merging Panels

The best way of loading new trees is by dragging and dropping one or more XML definition files into the QuickClick Solutions panel. You then get options:

Merge: The content is merged into the existing tree. This way, you can add new items to an existing tree
Replace: The current tree is closed and the new one loaded instead
New Panel: The new tree is opened inside a new panel

Note: There is still a bug. When you choose Cancel, the tree is still loaded.

Call To Action

Please let us know what you think and share feedback: Visit Beta Place

To read more about PowerShell Plus Beta2 and where to get it, here are all details.

Have a lot of fun,

may the PowerShell be with you,

-Tobias

XML Part 2: Write, Add And Change XML Data

Tobias Weltner — Mon, 02 Feb 2009 02:11:00 GMT

In the previous post, I demonstrated how PowerShell handles XML data and how easy it is to load XML from a file or the Internet and then analyze its content. Today, I'd like to share how you can change and append XML data.

Creating Sample XML

I'd like to start this by creating an XML template. I don't bother using special XML functionality. Instead, I simply write the XML template using plain text like this:

PS> $template = "<employee version='1.0'>
>> <person>
>> <firstname>Tobias</firstname>
>> <lastname>Weltner</lastname>
>> </person>
>> </employee>
>> "
>>
PS> $template
<employee version='1.0'>
<person>
<firstname>Tobias</firstname>
<lastname>Weltner</lastname>
</person>
</employee>


PS> $template | Out-File $home\template.xml

Loading Sample XML

Next, I load my XML template into an XML object. This gives me the ability to browse and analyze the content of my XML file. If you have questions regarding browsing the XML content, please take a look at Part1 of this blog.

PS> $xml = New-Object XML
PS> $xml.Load("$home\template.xml")
PS> $xml

employee
--------
employee
PS> $xml.employee

version                                                       person
-------                                                       ------
1.0                                                           person
PS> $xml.employee.person

firstname                                                     lastname
---------                                                     --------
Tobias                                                        Weltner
PS> $xml.employee.person.firstname
Tobias

Manipulating XML Content

Once you have loaded the XML into an XML object, it is amazingly simple to change and update its content. Let's say I'd like to change my lastname to a different name. First, I select the data I want to change. Next, I change it. That is all:

PS> $xml.employee.person | Where-Object { $_.lastname -eq 'Weltner' }

firstname                                                     lastname
---------                                                     --------
Tobias                                                        Weltner
PS> $xml.employee.person | 
>> Where-Object { $_.lastname -eq 'Weltner' } | 
>> ForEach-Object { $_.lastname = 'NewName' }
>>
PS> $xml.employee.person

firstname                                                     lastname
---------                                                     --------
Tobias                                                        NewName

Saving Changes As New XML File

All changes occur in memory inside your loaded XML object. To persist your changes to an updated XML file, you use the Save() method found as part of your XML object. Before I save my changes to a new file, I also update the version attribute I originally added to the <employee> node:

PS> $xml.employee.version = "2.0"
PS> $xml.Save("$home\updated.xml")
PS> Get-Content $home\updated.xml
<employee version="2.0">
  <person>
    <firstname>Tobias</firstname>
    <lastname>NewName</lastname>
  </person>
</employee>

As you can see, all changes have been written to proper XML. I do not need to fiddle with XML object model methods to make all of this happen.

Adding New Data To XML

Changing existing data inside an XML file is easy. But how do I add new data? Let's say I want to add a new person to my employee list. Here is how you do it:

PS> $oldperson = @($xml.employee.person)[0]
PS> $oldperson

firstname                                                       lastname
---------                                                       --------
Tobias                                                          NewName
PS> $newperson = $oldperson.Clone()
PS> $newperson.firstname = "Cofi"
PS> $newperson.lastname = "Weltner"
PS> $newperson

firstname                                                       lastname
---------                                                       --------
Cofi                                                            Weltner

To add a new entry to my XML, I first grab an existing entry. Since my XML only contains one person at this time, I make sure I wrap the call in @(). This way, I always receive an array even though there is only one entry. Without this statement, PowerShell would have returned the person item right away. Next, I read the first person from that array using index #0 and store it as $oldperson.

$oldperson is still connected to my XML file and still represents the old person. So if I made changes to this object, I would actually manipulate the existing person. To add a new person, I call Clone() to create an independent clone of that object and store it in $newperson. This object now is a new data entry, and I can go ahead and change its properties to anything I want.

Inserting New Data Into XML

Right now, $newperson is not connected to my XML. Instead, it just hangs around in memory. To make it part of my XML file, I need to insert it into my XML at the position I want. I want $newperson to be part of my employees so I add it like this:

PS> $xml.employee.AppendChild($newperson)

firstname                             lastname
---------                             --------
Cofi                                  Weltner
PS> $xml.employee.person

firstname                             lastname
---------                             --------
Tobias                                NewName
Cofi                                  Weltner

It worked: The new person now is part of my XML, and all I needed to do now is to save the appended XML to file to persist my changes. It really is that easy!

Creating A List Of Local Users

To illustrate how all of this works, I'd like to show you a quick example. It queries WMI for all local user accounts and creates a nice XML file.

First of all, I need to figure out how to get the user data I want to wrap as XML. As it turns out, Get-WMIObject does the job for me. The information is contained in the Win32_UserAccount class. Since I am only interested in local accounts, I make sure I query only for instances with LocalAccount set to true. I filter this on the server side because querying all accounts in a large enterprise could otherwise take a long time:

PS> Get-WmiObject win32_useraccount -filter 'LocalAccount=true'


AccountType : 512
Caption     : PCNEU01\Administrator
Domain      : PCNEU01
SID         : S-1-5-21-2613171836-1965730769-3820153312-500
FullName    :
Name        : Administrator

AccountType : 512
Caption     : PCNEU01\ASPNET
Domain      : PCNEU01
SID         : S-1-5-21-2613171836-1965730769-3820153312-1001
FullName    : ASP.NET Machine Account
Name        : ASPNET

AccountType : 512
Caption     : PCNEU01\Fred
Domain      : PCNEU01
SID         : S-1-5-21-2613171836-1965730769-3820153312-1016
FullName    : Fred
Name        : Fred

(...)

Next, I create my XML template designed to hold the data I am after. I want to store these properties: Name, Fullname, Description, SID, PasswordRequired, Disabled. J

ust in case you are wondering why only part of these properties appeared in the last screenshot, always remember: PowerShell only shows you the most important properties of an object. To see all properties, you need to add to your pipeline either | Format-List * or | Get-Member.

Here is my XML template:

PS> $template = "
>> <localusers machine='pc1' version='1.0'>
>> <users>
>> <Name></Name>
>> <Fullname></Fullname>
>> <Description></Description>
>> <SID></SID>
>> <PasswordRequired></PasswordRequired>
>> <Disabled></Disabled>
>> </users>
>> </localusers>
>> "
>>
PS> $template


<localusers machine='pc1' version='1.0'>
<users>
<Name></Name>
<Fullname></Fullname>
<Description></Description>
<SID></SID>
<PasswordRequired></PasswordRequired>
<Disabled></Disabled>
</users>
</localusers>


PS> $template | Out-File $home\users.xml

Next, I load the template into my XML object:

PS> $xml = New-Object xml
PS> $xml.Load("$home\users.xml")
PS> $xml

localusers
----------
localusers
PS> $xml.localusers

machine                  version                  users
-------                  -------                  -----
pc1                      1.0                      users
PS> $xml.localusers.users


Name             :
Fullname         :
Description      :
SID              :
PasswordRequired :
Disabled         :

Now, I grab an existing entry and use this as template for my new entries:

PS> $newuser = (@($xml.localusers.users)[0]).Clone()
PS> $newuser


Name             :
Fullname         :
Description      :
SID              :
PasswordRequired :
Disabled         :

Finally, I ask WMI for the actual user information and write it to my XML file. Just be aware that XML can only store string data. This is why I convert boolean values to string using toString():

PS> Get-WmiObject Win32_UserAccount -filter 'LocalAccount=true' |
>> ForEach-Object {
>> $newuser = $newuser.clone()
>> $newuser.Name = $_.Name
>> $newuser.Fullname = $_.FullName
>> $newuser.Description = $_.Description
>> $newuser.SID = $_.SID
>> $newuser.PasswordRequired = $_.PasswordRequired.toString()
>> $newuser.Disabled = $_.Disabled.toString()
>> $xml.localusers.AppendChild($newuser) > $null
>> }
>>
PS> $xml.localusers.users.Count
17
PS> $xml.localusers.users | Format-Table Name, SID, Description

Name                     SID                      Description
----                     ---                      -----------


Administrator            S-1-5-21-2613171836-1... Predefined Account ...
ASPNET                   S-1-5-21-2613171836-1... Account used for runn...
Fred                     S-1-5-21-2613171836-1... Pension
(...)

It worked! One last clean up thing to do is to remove the empty template. To remove all entries with an empty Name property, I do this:

PS> $xml.localusers.users |
>> Where-Object { $_.Name -eq '' } |
>> ForEach-Object { $xml.localusers.RemoveChild($_) }
>>


Name             :
Fullname         :
Description      :
SID              :
PasswordRequired :
Disabled         :

PS> $xml.localusers.users.Count
16

Now I can save the XML to file and take a look at the XML I just created:

PS> $xml.Save("$home\userlist.xml")
PS> Get-Content $home\userlist.xml
<localusers machine="pc1" version="1.0">
  <users>
    <Name>Administrator</Name>
    <Fullname>
    </Fullname>
    <Description>Predefined Account</Description>
    <SID>S-1-5-21-2613171836-1965730769-3820153312-500</SID>
    <PasswordRequired>True</PasswordRequired>
    <Disabled>True</Disabled>
  </users>
  <users>
    <Name>ASPNET</Name>
    <Fullname>ASP.NET Machine Account</Fullname>
    <Description>Account used for running the ASP.NET worker process (aspn
et_wp.exe)</Description>
    <SID>S-1-5-21-2613171836-1965730769-3820153312-1001</SID>
    <PasswordRequired>False</PasswordRequired>
    <Disabled>False</Disabled>
  </users>
  <users>
    <Name>Fred</Name>
    <Fullname>Fred</Fullname>
    <Description>Pension</Description>
    <SID>S-1-5-21-2613171836-1965730769-3820153312-1016</SID>
    <PasswordRequired>True</PasswordRequired>
    <Disabled>False</Disabled>
  </users>
(...)

Wrap Up

Here is a script that creates the XML local user list for you and demonstrates the individual steps in one file:

# create a template XML to hold data
$template = @'

<localusers machine='pc1' version='1.0'>

<users>

<Name></Name>

<Fullname></Fullname>

<Description></Description>

<SID></SID>

<PasswordRequired></PasswordRequired>

<Disabled></Disabled>

</users>

</localusers>

'@

$template | Out-File $home\users.xml -encoding UTF8

# load template into XML object
$xml = New-Object xml
$xml.Load("$home\users.xml")

# grab template user
$newuser = (@($xml.localusers.users)[0]).Clone()

# use template to add local user accounts to xml 
Get-WmiObject Win32_UserAccount -filter 'LocalAccount=true' |
ForEach-Object {
	$newuser = $newuser.clone()
	$newuser.Name = $_.Name
	$newuser.Fullname = $_.FullName
	$newuser.Description = $_.Description
	$newuser.SID = $_.SID
	$newuser.PasswordRequired = $_.PasswordRequired.toString()
	$newuser.Disabled = $_.Disabled.toString()
	$xml.localusers.AppendChild($newuser) > $null
}

# remove users with undefined name (remove template)
$xml.localusers.users | 
Where-Object { $_.Name -eq "" } | 
ForEach-Object  { [void]$xml.localusers.RemoveChild($_) }

# save xml to file
$xml.Save("$home\userlist.xml")

# play with results

$xml.localusers.users | Sort-Object Name | Format-Table name, description, SID

& "$home\userlist.xml"

Cheerio

-Tobias

XML Part 1: Playing with RSS Feeds and XML Content

Tobias Weltner — Sat, 17 Jan 2009 09:37:00 GMT

A lot of data these days is wrapped as XML, and up until now, handling XML data wasn't a piece of cake. PowerShell makes handling XML a lot easier. This is the first part of a little series about XML and PowerShell. We start with accessing XML documents and reading data.

Getting XML Data

Let's first look how PowerShell can lay hands on XML data. One way is to create a new and empty XML document:

$xml = New-Object XML

Next, you can use your new XML document to load XML data, either from a local file or from the Internet. Use the Load() method. Let's for example load the www.powershell.com RSS ticker:

PS> $a = New-Object XML
PS> $a.Load("http://powershell.com/cs/blogs/MainFeed.aspx")
PS> $a

xml                                   xml-stylesheet                       rss
---                                   --------------                       ---
                                                                           rss
PS>

As long as you have access to the Internet, these lines will download the RSS news ticker into $a as an XML document, and when you output $a, you see a number of properties.

Browsing XML Data

What exactly is their meaning? To find out, let's first save the downloaded RSS ticker to file using the built-in Save() method. Next, we take a look at the first lines in that XML document by reading the xml file using Get-Content and selecting only the first 3 lines using Select-Object -First:

PS> $a.save("$home\rssticker.xml")
PS> Get-Content $home\rssticker.xml | Select-Object -first 3
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="http://powershell.com/cs/utility/FeedStylesheets/rss.xsl" media="screen"
?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/sla
sh/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
>

As it turns out, the PowerShell xml document in $a returns the top XML nodes: xml, xml-stylesheet and rss. Diving into nested information inside an XML document is very easy because it works in pretty much the same way as with objects. So if you'd like to see all the nodes below the root node rss, you use the rss property:

PS> $a.rss


version : 2.0
dc      : http://purl.org/dc/elements/1.1/
slash   : http://purl.org/rss/1.0/modules/slash/
wfw     : http://wellformedweb.org/CommentAPI/
itunes  : http://www.itunes.com/dtds/podcast-1.0.dtd
channel : channel

PS>

Again, if you'd looked at the raw XML data, you would see that the RSS node has these children: version, dc, slash, wfw, itunes and channel. Most of these are attributes with pieces of information. Channel however is another parent node and has a bunch of children. To look at the children, again use this property name:

PS> $a.rss.channel
format-default : The member "Item" is already present.

Property Name Conflict - And A Simple Workaround

Bang! You get a red error message. You cannot list the children inside the channel parent node. This is a bug, or rather, a conceptional weakness in design.

If you look at the raw XML data, you will see that the channel node contains a bunch of item nodes, and these item nodes are the ones with the interesting stuff: the feed messages. Unfortunately, the XML document object already has its own item property. The moment PowerShell tries to add the item property for the item children, you get the error message. An object cannot have two properties with the same name.

And here is the workaround: work in "blind" mode and just assume the children elements are named "item" (or whatever the error message indicates):

PS> $a.rss.channel.item


title       : Group Policy Cmdlets in Windows 7
link        : http://powershell.com/cs/blogs/windows-powershell-team/archive/2009/01/16/group-policy-cmdlets-in
              -windows-7.aspx
pubDate     : Sat, 17 Jan 2009 04:46:08 GMT
guid        : guid
creator     : Windows PowerShell Blog
comments    : 0
description : Lilia Gutnik has posted a blog entry HERE showing an example of the Windows 7 Group Policy cmdlet
              s.&#160; Check it out. &#160; Experiment!&#160; Enjoy!&#160; Engage! Jeffrey Snover [MSFT] Window
              s Management Partner Architect Visit the Windows PowerShell Team blog at:&#160;&#160;&#160; http:
              //blogs.msdn.com/PowerShell Visit the Windows PowerShell ScriptCenter at:&#160; http://www.micros
              oft.com/technet Read More......(<a href="http://powershell.com/cs/blogs/windows-powershell-team/a
              rchive/2009/01/16/group-policy-cmdlets-in-windows-7.aspx">read more</a>)<img src="http://powershe
              ll.com/cs/aggbug.aspx?PostID=899" width="1" height="1">

title       : Jeffrey Snover and Bruce Payette on the PowerScripting Podcast
link        : http://powershell.com/cs/blogs/under-the-stairs/archive/2009/01/16/jeffrey-snover-and-bruce-payet
              te-on-the-powerscripting-podcast.aspx
pubDate     : Fri, 16 Jan 2009 14:35:00 GMT
guid        : guid
creator     : Under The Stairs
comments    : 0
description : I love downloading podcasts to my Zune and listening to them as I travel. I ve got a bit of a bac
              klog, but one I ve just downloaded and will be listening to shortly (possibly tomorrow as I head
              from Milan back to London) is the PowerScripting Podcast Read More......(<a href="http://powershe
              ll.com/cs/blogs/under-the-stairs/archive/2009/01/16/jeffrey-snover-and-bruce-payette-on-the-power
              scripting-podcast.aspx">read more</a>)<img src="http://powershell.com/cs/aggbug.aspx?PostID=898"
              width="1" height="1">
category    : {category, category}

title       : How To Make Your Own Module Repository
link        : http://powershell.com/cs/blogs/windows-powershell-team/archive/2009/01/16/how-to-make-your-own-mo
              dule-repository.aspx
pubDate     : Fri, 16 Jan 2009 08:52:13 GMT
guid        : guid
creator     : Windows PowerShell Blog
comments    : 0
description : Andy Schneider (from Get-PowerShell.com ) recently asked me how he could make sure that everyone
              at Avanade could get a consistent set of modules. I run into a somewhat similar problem here at M
              icrosoft, where I want to take scripts I&#39;ve built to work with internal applications and make
               them easy for people to use, even if they&#39;re not already using PowerShell. I don&#39;t want
              the scripts to Read More......(<a href="http://powershell.com/cs/blogs/windows-powershell-team/ar
              chive/2009/01/16/how-to-make-your-own-module-repository.aspx">read more</a>)<img src="http://powe
              rshell.com/cs/aggbug.aspx?PostID=895" width="1" height="1">
category    : {category, category}


(...)

Now you get to the good stuff! These are the headlines you're after.

Using The PowerShell Pipeline

You just learned that you can access any RSS feed in the world by loading it into a new and empty XML document.

Since RSS feeds are XML documents and adhere to a defined format, you can always list all RSS messages by looking at the RSS.Channel.Item property. This returns all raw data contained in the individual RSS items. From here, simply use PowerShell Pipeline tricks to filter what you are looking for.

First, I'd like to filter the information. I only want to see the blog entry title and the link. Easy: use Format-Table:

PS> $a = New-Object XML
PS> $a.Load("http://powershell.com/cs/blogs/MainFeed.aspx")
PS> $a.rss.channel.item | Format-Table Title, Link

title                                                   link
-----                                                   ----
Group Policy Cmdlets in Windows 7                       http://powershell.com/cs/blogs/windows-powershell-te...
Jeffrey Snover and Bruce Payette on the PowerScripti... http://powershell.com/cs/blogs/under-the-stairs/arch...
How To Make Your Own Module Repository                  http://powershell.com/cs/blogs/windows-powershell-te...
Please Join Me for a Power Scripting Podcast Tonight... http://powershell.com/cs/blogs/windows-powershell-te...
Running PowerShell Scripts via Email                    http://powershell.com/cs/blogs/under-the-stairs/arch...
Date and Time in PowerShell (and WMI)                   http://powershell.com/cs/blogs/under-the-stairs/arch...
Date and Time in PowerShell                             http://powershell.com/cs/blogs/powershell-scripts/ar...
Windows 7 Troubleshooting                               http://powershell.com/cs/blogs/windows-powershell-te...
Podcast Discussing WSMAN 1/14/2008                      http://powershell.com/cs/blogs/windows-powershell-te...
Get-UpTime.ps1                                          http://powershell.com/cs/blogs/powershell-scripts/ar...
Interactive remoting in CTP3                            http://powershell.com/cs/blogs/windows-powershell-te...
How to copy colorized script from PowerShell ISE        http://powershell.com/cs/blogs/windows-powershell-te...
Please Give Us Feedback                                 http://powershell.com/cs/blogs/windows-powershell-te...
Blogging in 2008                                        http://powershell.com/cs/blogs/under-the-stairs/arch...
V2 Blog Entries                                         http://powershell.com/cs/blogs/windows-powershell-te...
Copy console screen to system clipboard                 http://powershell.com/cs/blogs/windows-powershell-te...
Get-Screensaver.ps1                                     http://powershell.com/cs/blogs/powershell-scripts/ar...
Colorized capture of console screen in HTML and RTF.    http://powershell.com/cs/blogs/windows-powershell-te...
Finding a URL For File Transfer Cmdlets                 http://powershell.com/cs/blogs/windows-powershell-te...
Transferring (Large) Files Using BITs                   http://powershell.com/cs/blogs/windows-powershell-te...
Test-PSCmdlet                                           http://powershell.com/cs/blogs/windows-powershell-te...
Capture console screen                                  http://powershell.com/cs/blogs/windows-powershell-te...
Get-Hash2.ps1                                           http://powershell.com/cs/blogs/powershell-scripts/ar...
PowerShell as Inventory Tool                            http://powershell.com/cs/blogs/windows-powershell-te...
Windows 7 Beta Has Arrived   But Not For Everyone       http://powershell.com/cs/blogs/under-the-stairs/arch...

Next, I only want the top 5 entries, and I do not want the link to be cut off. So I insert a Select-Object -First (remember, the Format cmdlets always have to be the last element in your pipeline), and I add a -wrap parameter to Format-Table:

PS> $a.rss.channel.item | Select-Object -first 5 | Format-Table Title, Link -wrap

title                                                   link
-----                                                   ----
Group Policy Cmdlets in Windows 7                       http://powershell.com/cs/blogs/windows-powershell-team/
                                                        archive/2009/01/16/group-policy-cmdlets-in-windows-7.as
                                                        px
Jeffrey Snover and Bruce Payette on the PowerScripting  http://powershell.com/cs/blogs/under-the-stairs/archive
Podcast                                                 /2009/01/16/jeffrey-snover-and-bruce-payette-on-the-pow
                                                        erscripting-podcast.aspx
How To Make Your Own Module Repository                  http://powershell.com/cs/blogs/windows-powershell-team/
                                                        archive/2009/01/16/how-to-make-your-own-module-reposito
                                                        ry.aspx
Please Join Me for a Power Scripting Podcast Tonight @  http://powershell.com/cs/blogs/windows-powershell-team/
9PM EST (6PM PST)                                       archive/2009/01/15/please-join-me-for-a-power-scripting
                                                        -podcast-tonight-9pm-est-6pm-pst.aspx
Running PowerShell Scripts via Email                    http://powershell.com/cs/blogs/under-the-stairs/archive
                                                        /2009/01/15/running-powershell-scripts-via-email.aspx

Can I filter based on topic, too? Sure thing. If you are interested in Windows 7, the upcoming new Windows client, and you'd like to see only blogs about Windows 7, then add a Where-Object into your pipeline.

Inside of it, the $_ placeholder represents the actual blog entry as it is running over the pipeline, and you then can check whether the title property contains one or more keywords.

PS> $a.rss.channel.item | Where-Object { $_.Title -like '*Windows 7*' } | Format-Table Title, Description

title                                                   description
-----                                                   -----------
Group Policy Cmdlets in Windows 7                       Lilia Gutnik has posted a blog entry HERE showing an...
Windows 7 Troubleshooting                               Windows 7 has a cool new extensible troubleshooting ...
Windows 7 Beta Has Arrived   But Not For Everyone       The Windows 7 and Windows Server 2008 R2 beta versio...

Maybe you'd like to output this as a nice report. Here is the thing to remember: Never use Format-... cmdlets when you plan to output results to sources other than the console. Use Select-Object instead. To create a simple HTML report, this is what I'd do:

PS> $a.rss.channel.item | Where-Object { $_.Title -like '*Windows 7*' } | Select-Object Title, Description | 
ConvertTo-Html | Out-File $home\report.htm; & "$home\report.htm"

This is what the resulting report looks like:

title	description
Group Policy Cmdlets in Windows 7	Lilia Gutnik has posted a blog entry HERE showing an example of the Windows 7 Group Policy cmdlets.  Check it out.   Experiment!  Enjoy!  Engage! Jeffrey Snover [MSFT] Windows Management Partner Architect Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet Read More......(<a href="http://powershell.com/cs/blogs/windows-powershell-team/archive/2009/01/16/group-policy-cmdlets-in-windows-7.aspx">read more</a>)<img src="http://powershell.com/cs/aggbug.aspx?PostID=899" width="1" height="1">
Windows 7 Troubleshooting	Windows 7 has a cool new extensible troubleshooting framework which is entirely based on PowerShell scripts.  Rafael Rivera has written a very good step-by-step guide for how to author a Win7 Troubleshooting Pack HERE . Check it out. Experiment!  Enjoy!  Engage! Jeffrey Snover [MSFT] Windows Management Partner Architect Visit the Windows PowerShell Team blog at:    http Read More......(<a href="http://powershell.com/cs/blogs/windows-powershell-team/archive/2009/01/14/windows-7-troubleshooting.aspx">read more</a>)<img src="http://powershell.com/cs/aggbug.aspx?PostID=880" width="1" height="1">
Windows 7 Beta Has Arrived – But Not For Everyone	The Windows 7 and Windows Server 2008 R2 beta versions were released this week. I got the ISOs myself during the week, and finished off today loading R2, Win7 Ultimate and WIn7 Home Premium as VMware virtual machines. But it looks like Microsoft has totally Read More......(<a href="http://powershell.com/cs/blogs/under-the-stairs/archive/2009/01/10/windows-7-beta-has-arrived-but-not-for-everyone.aspx">read more</a>)<img src="http://powershell.com/cs/aggbug.aspx?PostID=848" width="1" height="1">

Admittedly, the HTML report does not really look very stylish, but you could change that as well:

PS> $head = '<style> BODY{font-family:Verdana; background-color:lightblue;} TABLE{border-width: 1px;border-style
: solid;border-color: black;border-collapse: collapse;} TH{font-size:1.3em; border-width: 1px;padding: 2px;borde
r-style: solid;border-color: black;background-color:#FFCCCC} TD{border-width: 1px;padding: 2px;border-style: sol
id;border-color: black;background-color:yellow}</style>'
PS> $title = "My Report"
PS> $body = "<H1>New Windows 7 + PowerShell Blogs</H1>"
PS> $a.rss.channel.item | Where-Object { $_.Title -like '*Windows 7*' } | Select-Object Title, Description | 
ConvertTo-Html -title $title -head $head -body $body    | Out-File $home\report.htm; & "$home\report.htm"

Here is more brainfood on colorizing HTML reports: http://powershell.com/cs/blogs/tips/archive/2009/01/05/outputting-html-reports.aspx

Convert Text to XML

To wrap up this first part of our XML series, let's finally look at two more ways to read XML data into PowerShell. At the beginning of this article, we loaded the XML via Internet into an empty XML object. From here, you can save the XML as file. Using the same Load() method, you can also load XML data from an XML file:

PS> $a = New-Object XML
PS> $a.Load("http://powershell.com/cs/blogs/MainFeed.aspx")
PS> $a.Save("$home\myxml.xml")
PS>
PS> $b = New-Object XML
PS> $b.Load("$home\myxml.xml")
PS> $b

xml                                   xml-stylesheet                       rss
---                                   --------------                       ---
                                                                           rss

So the second approach is to load a file-based XML into an empty XML object. The third approach uses type conversion. You read in XML data as plain text, then convert this into the XML data type.

Remember two things here: Type conversion works by writing the type (in square brackets) in front of the data you want to convert, and second: use parenthesis around Get-Content because you do not want to convert the Get-Content cmdlet of course but rather its result.

PS> $c = [xml] (Get-Content $home\myxml.xml)
PS> $c

xml                                   xml-stylesheet                       rss
---                                   --------------                       ---
                                                                           rss

Next Steps...

Next time, we will create our own XML documents, look at some more advanced data analysis and update and change XML data in an XML file. Make sure to check back next week! Which you now by the way could automate, too. Simply use the RSS ticker in the examples above to check for new blog entries on powershell.com!

Cheers and a great and relaxing weekend to you,
and don't forget to check out PowerShell Plus! It's great and simply one of the best ways to learn PowerShell!

-Tobias

MVP Windows PowerShell

Tipps & Tricks Using Compare-Object

Tobias Weltner — Fri, 09 Jan 2009 00:47:00 GMT

Compare-Object is a very powerful Cmdlet that can compare different result sets. The funny thing is: when you try to use Compare-Object in simple scenarios, all works fine. Once you put it to work in production environments, it often fails. Here is why. This article describes what to watch out for and how to correctly configure Compare-Object to make it work for you.

Using Compare-Object To Find New Processes

PowerShell can easily compare result sets for you and filter out only those items that have changed. Let's say you'd like to know which processes have been started after a given point in time. How can you do that?

The workhorse doing the comparinson is called Compare-Object. This Cmdlet takes two resultsets and automatically analyzes them. It then outputs only those items present in either one of the result sets. To find out the processes started after a given point in time, you first create a base resultset of all currently running processes like this:

PS> $shot1 = Get-Process
PS> notepad
PS> $shot2 = Get-Process
PS> Compare-Object $shot1 $shot2

InputObject                                                SideIndicator
-----------                                                -------------
System.Diagnostics.Process (notepad)                       =>
System.Diagnostics.Process (WmiPrvSE)                      =>

Now, whenever you want to see what has changed in your environment, create a second snapshot and compare both. Let's start notepad.exe really quick, then create another snapshot and compare both:

Compare-Object returns only those processes that exist in either $shot1 or $shot2, and the SideIndicator property tells you in which result set the object was present. A SideIndicator "=>" indicates that processes existed in only the second result set so you know these must be new processes. Interestingly enough, when I launched notepad, Windows also launched a process called WmiPrvSE.

Finding New Files And Folders

Wow, that's easy! Why not use this to find new files and folders added to a folder you'd like to monitor? To do that, you'd first generate a snapshot of that folder, then wait for content to be changed, and finally create another snapshot and compare contents. Let's take a look:

PS> $shot1 = Dir $home
PS> Set-Content $home\testfile1.txt "A new file"
PS> $shot2 = Dir $home
PS> Compare-Object $shot1 $shot2

InputObject                                                SideIndicator
-----------                                                -------------
testfile1.txt                                              =>

It worked. It will not always work like a charm, though. There is an important caveat you need to know about: SyncWindow.

Adjusting SyncWindow

Whenever Compare-Object compares object sets, it uses a SyncWindow to resync both lists when there is no match. The default SyncWindow setting in PowerShell V1 is 5, so whenever the result sets has too many consecutive differences, the result will not be what you expected. Here is an example:

PS> $shot1 = 1..10
PS> $shot2 = 10..1
PS> Compare-Object $shot1 $shot2

PS> $shot1 = 1..15
PS> $shot2 = 15..1
PS> Compare-Object $shot1 $shot2

                                     InputObject SideIndicator
                                     ----------- -------------
                                              15 =>
                                               1 <=
                                              14 =>
                                               2 <=
                                               2 =>
                                               1 =>
                                              14 <=
                                              15 <=

In the first part, Compare-Object compares two lists of numbers. Both lists contain the same numbers but in reverse order. The result is nothing, and that is correct since both sets contain the same numbers.

In the second part, there are 15 numbers in each set. This time, Compare-Object returns a bunch of nonsense information, claiming for example that the number 15 is present only in $shot1 and then only in $shot2. Why?

The default SyncWindow is 5, so whenerver there is no match, Compare-Object uses a delta of +/- 5 items to find the next matching item. When there are 10 elements in a set, a SyncWindow of 5 is sufficient to resync both lists (plus/minus 5 results in a maximum of 10 allowable consecutive differences). When there are 15 elements, SyncWindow would need to be at least 7 (the first comparison would be number 1 of $shot1 against number 15 of $shot2; with a SyncWindow of 7, Compare-Object would move 14 elements in $shot2 to find a match and would indeed find the matching number 1).

Fortunately, you can change the SyncWindow property using the parameter -syncWindow:

PS> $shot1 = 1..15
PS> $shot2 = 15..1
PS> Compare-Object $shot1 $shot2 -syncWindow 7
PS> Compare-Object $shot1 $shot2 -syncWindow 6

                                      InputObject SideIndicator
                                      ----------- -------------
                                               15 =>
                                                1 <=
                                                1 =>
                                               15 <=

Now, what would the SyncWindow need to be with an array of 16 or 25 elements? Easy: Take the array size, divide it by two and there you go. For an array of 16 elements, the minimum SyncWindow needs to be 8, and for an array of 25 elements it needs to be 12.

PS> $shot1 = 1..5
PS> $shot2 = 5..1
PS> Compare-Object $shot1 $shot2
PS> $shot1 = 1..10
PS> $shot2 = 10..1
PS> Compare-Object $shot1 $shot2
PS> $shot1 = 1..15
PS> $shot2 = 15..1
PS> Compare-Object $shot1 $shot2

                                       InputObject SideIndicator
                                       ----------- -------------
                                                15 =>
                                                 1 <=
                                                14 =>
                                                 2 <=
                                                 2 =>
                                                 1 =>
                                                14 <=
                                                15 <=


PS> $shot1 = 1..15
PS> $shot2 = 15..1
PS> Compare-Object $shot1 $shot2 -syncWindow 7
PS> Compare-Object $shot1 $shot2 -syncWindow 6

                                       InputObject SideIndicator
                                       ----------- -------------
                                                15 =>
                                                 1 <=
                                                 1 =>
                                                15 <=

Here are a couple of things to note regarding SyncWindow:

When SyncWindows is too low, Compare-Object returns false information and reports objects twice, once for each result set
The default SyncWindow setting of 5 is sufficient only when you expect very small changes in your result sets
To make sure you catch all matches, you would have to set SyncWindow to half of the number of expected differences. You can also set SyncWindow to a very large number like 1000 as catch-all. This however may cause long delays and a lot of memory consumption
In PowerShell V2, the default syncWindow setting has been raised as a consequence of this

Picking Properties

Remember everything in PowerShell is represented as object, and objects have properties. If you don't care about properties, Compare-Object picks the information to use for comparison automatically. This may not be what you want. Have a look:

PS> $shot1 = Dir $home
PS> Add-Content $home\testfile1.txt "Another line"
PS> $shot2 = Dir $home
PS> Compare-Object $shot1 $shot2

PS> Compare-Object $shot1 $shot2 -property Name, Length

Name                               Length SideIndicator
----                               ------ -------------
testfile1.txt                          26 =>
testfile1.txt                          12 <=

This is actually a little modification to the example script earlier. I create a folder snapshot, then I add a line to the file I created in the earlier example. Next, I create another snapshot and compare both. The result is: nothing. Why?

Because I did not pick an object property. So Compare-Object simply looked at the file name, and since I added a line to an existing file, no new file name was created.

To monitor file changes, I need to explicitly tell Compare-Object to compare both the name and the Length property. Once I do that, I get back two results. The SideIndicator tells me that the file testfile1.txt was 12 Bytes in the initial snapshot and now is 26 Bytes.

Working With Results

The results delivered by Compare-Object are custom objects returning the properties you selected as well as the SideIndicator property. You can filter and return only selected information. For example, if you'd like to filter the result to show only new elements (SideIndicator equals "=>"), use Where-Object like this:

PS> Compare-Object $shot1 $shot2 -property Name, Length | Where-Object { $_.SideIndicator -eq '=>' }

Name                            Length SideIndicator
----                            ------ -------------
testfile1.txt                       26 =>

You could also use the -passThru parameter to actually return the original objects compared by Compare-Object. When you do this, the SideIndicator property is appended to the original object and you can still use it for filtering:

PS> Compare-Object $shot1 $shot2 -property name, length | fl *


name          : testfile.txt
length        : 51
SideIndicator : =>

name          : testfile.txt
length        : 39
SideIndicator : <=



PS> Compare-Object $shot1 $shot2 -property name, length -passThru


    Directory: Microsoft.PowerShell.Core\FileSystem::C:\Users\Tobias


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---          1/9/2009  11:38 AM         51 testfile.txt
-a---          1/9/2009  11:34 AM         39 testfile.txt


PS> Compare-Object $shot1 $shot2 -property name, length -passThru | fl *


PSPath            : Microsoft.PowerShell.Core\FileSystem::C:\Users\Tobias\testfile.txt
PSParentPath      : Microsoft.PowerShell.Core\FileSystem::C:\Users\Tobias
PSChildName       : testfile.txt
PSDrive           : C
PSProvider        : Microsoft.PowerShell.Core\FileSystem
PSIsContainer     : False
SideIndicator     : =>
Mode              : -a---
Name              : testfile.txt
Length            : 51
DirectoryName     : C:\Users\Tobias
Directory         : C:\Users\Tobias
IsReadOnly        : False
Exists            : True
FullName          : C:\Users\Tobias\testfile.txt
Extension         : .txt
CreationTime      : 1/9/2009 11:31:05 AM
CreationTimeUtc   : 1/9/2009 10:31:05 AM
LastAccessTime    : 1/9/2009 11:31:05 AM
LastAccessTimeUtc : 1/9/2009 10:31:05 AM
LastWriteTime     : 1/9/2009 11:38:17 AM
LastWriteTimeUtc  : 1/9/2009 10:38:17 AM
Attributes        : Archive

PSPath            : Microsoft.PowerShell.Core\FileSystem::C:\Users\Tobias\testfile.txt
PSParentPath      : Microsoft.PowerShell.Core\FileSystem::C:\Users\Tobias
PSChildName       : testfile.txt
PSDrive           : C
PSProvider        : Microsoft.PowerShell.Core\FileSystem
PSIsContainer     : False
SideIndicator     : <=
Mode              : -a---
Name              : testfile.txt
Length            : 39
DirectoryName     : C:\Users\Tobias
Directory         : C:\Users\Tobias
IsReadOnly        : False
Exists            : True
FullName          : C:\Users\Tobias\testfile.txt
Extension         : .txt
CreationTime      : 1/9/2009 11:31:05 AM
CreationTimeUtc   : 1/9/2009 10:31:05 AM
LastAccessTime    : 1/9/2009 11:31:05 AM
LastAccessTimeUtc : 1/9/2009 10:31:05 AM
LastWriteTime     : 1/9/2009 11:34:58 AM
LastWriteTimeUtc  : 1/9/2009 10:34:58 AM
Attributes        : Archive



PS> Compare-Object $shot1 $shot2 -property name, length -passThru | Where-Object { $_.SideIndicator -eq '=>' }


    Directory: Microsoft.PowerShell.Core\FileSystem::C:\Users\Tobias


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---          1/9/2009  11:38 AM         51 testfile.txt

Persisting Comparison Information

All comparisons so far have taken place in memory because we created the result sets on the fly. What if I'd like to compare folder content against a predefined base set?

You can easily do that. Simply export the result sets to XML, then reload them and do the comparison. There are three important rules when you do that:

Use Select-Object to select only the object properties you really need for your comparison prior to exporting objects to XML or else the XML will be very large
The result sets you compare both need to be written to XML and re-imported. Do not compare an imported XML result set against a live result set because object types are different
Specify the properties you want to compare when you use Compare-Object

Here is an example of persisting result sets. First, I create a snapshot of my $home drive and export it as XML. Since I am interested in new files and changed files, I only export Name and Length.

Next, whenever I am in need, I can import the base folder set and compare it against the current folder content. To do that, I export the current folder content as XML, too, and reimport it so that

PS> Dir $home | Select-Object Name, Length | Export-Clixml $home\baseline.xml
PS> Add-Content $home\testfile.txt "Hello World"
PS> $shot1 = Import-Clixml $home\baseline.xml
PS> Dir $home | Select-Object Name, Length | Export-Clixml $home\temp.xml
PS> $shot2 = Import-Clixml $home\temp.xml
PS> Compare-Object $shot1 $shot2 -property Name, Length

Name                             Length SideIndicator
----                             ------ -------------
baseline.xml                     58150 =>
temp.xml                         45056 =>
testfile.txt                        39 =>
baseline.xml                      8192 <=
temp.xml                         58152 <=
testfile.txt                        26 <=

Note that in this example, since I stored the xml files in the same folder I monitored, they will also show up in the result set.

Summary

Compare-Object is a great way of comparing result sets. You just need to be careful to make sure:

you are comparing the same object types (do not mix imported xml data with live data)
the syncWindow is large enough to cover the number of expected differences
you specify the properties you really want to compare

Use the SideIndicator property to filter result so you only get the changes in one of the result sets. And use the -passThru parameter to get the real objects.

Cheerio

-Tobias

Using PowerShellPlus with PowerShell V2 (CTP3)

Tobias Weltner — Sun, 04 Jan 2009 21:54:00 GMT

The great news is: PowerShellPlus works as-is with PowerShell V1 and PowerShell V2, indicating the stable and solid approach of its engine. No updates needed. From the very beginning, we took care to use only approved and backwards-compatible PowerShell APIs.

You don't use PowerShellPlus yet? It is an awesome interactive console and PowerShell editor, and you should really try it! It is derived from famous "PowerShellIDE" which was the world's first PowerShell GUI, editor and debugger (surfaced June 2006). Yet again, it pays off to have solid 4 years of experience in this product.

There are a couple of things you should know when you just upgraded from V1 to V2 to get PSP to recognize the new V2 features.

Update the Cache

For speed purposes, PowerShellPlus caches information regarding available Snap-Ins and Cmdlets. So when you have been using PSP on PowerShell V1 for a while and upgrade to PowerShell V2 CTP3, things continue to work as expected except all new V2 specific Cmdlet parameters and help pages are still missing.

Normally, PSP detects at startup all freshly added Snapins and adds them to its cache. Upgrading PowerShell is a whole new ballgame though because actually no new snapins is added. Instead, existing snapins are updated.

To manually reset and update PSPs internal cache, do this:

Launch PowerShell Plus
Hold down SHIFT when the splash screen opens to open the startup management dialog
Check the option "Clear cached Cmdlet info", then click OK
PSP starts and re-examines all available snapins. This may take a minute or two, and you will see a green bar with progress information. Once the green bar is gone, you are all set.

Once you cleared and updated the cache, try this:

Get-WMIObject -

Code completion will show the complete list of V2 parameters.

Update the Learning Center

If you'd also like to update the learning center help pages, keep this in mind: the procedure you just executed automatically adds all new help topics to the learning center. It does not update existing topics though. So to update the learning center, simply delete its cache before you do the procedure above ("Yeah, thanks for telling me now! Just did it!" - oh well, ok, just do it again)!

How do I clear the learning center cache? For example like this:

del $env:localappdata\PowerShellPlus\manpages\*.htm -whatif

(Remove the -whatif if you are confident you typed in the correct line)

What's Next?

Of course there are plenty of additional extras in PowerShell V2 like block comments and inline code. We will support them with one of our next maintenance releases but for now, isn't it good to know that PowerShellPlus runs beautifully with PowerShell V2 CTP3?

Cheers

-Tobias