One of the lesser known features in PowerShell 2.0 is that it supports string localization and pretty simply I might add.  Now for most developers and admins script localization probably isn’t going to be something you’ll worry about.  However if you are providing PowerShell based solutions to an international audience this feature will come in very handy in terms of broadening your reach.

I believe the driving force behind this feature’s inclusion in PowerShell is that a critical component of Windows 7 – the Windows Troubleshooting Platform and associated troubleshooting packs – use PowerShell scripts extensively.  Obviously Windows is localized to the extreme so it stands to reason that the troubleshooting scripts, which can interact with the end user via text prompts, were required to be localized.  Enough context.  Let’s look at how localization works in PowerShell 2.0.

First, the feature in PowerShell is referred to as “Data Sections” and is covered by the help topics:

• about_data_sections
• about_script_internationalization

Let’s start by creating our string table file.  This is created as a .psd1 (data) file.  In this case, we will call it messages.psd1 and its contents are simply:

# Contents of .\messages.psd1
ConvertFrom-StringData @'
Hello_F1=Hello {0}
Goodbye=Goodbye
'@ 

This is a bit odd looking for a “data” file but the gist is that the ConvertFrom-StringData cmdlet returns a ordinary hashtable.  The string that ConvertFrom-StringData operates on has to be in a special format which is essentially one key/value pair per line where the key and value are separated by an “=”.  The “key” is how you will reference the “value” (actual localized string) from your script.  FWIW you could just have the psd1 file return a hashtable directly but then you have to quote each value.  So the format above is a bit cleaner and more like a traditional string table file.

Now at this point you could and might be tempted to do something like this in your script:

$msgs = .\messages.psd1

But there is one tiny little problem - .psd1 files are not executable like .ps1 or .psm1 files are.  Hey, that’s probably why they are called “data” files.  :-)  Obviously PowerShell must provide a way to load these files and that mechanism is the Import-LocalizedData cmdlet.  It takes the path to a .psd1 file, loads it and then assigns the resulting hashtable to a variable name provided to the cmdlet.  Let’s see an example of this:

# Contents of test.ps1
Import-LocalizedData -BindingVariable msgs -FileName Messages.psd1
$msgs.Hello_F1 -f "John"
$msgs.Goodbye

The output of this script is:

PS> .\test.ps1
Hello John
Goodbye

You may be thinking that this seems like a pretty simple task, not worthy of requiring a dedicated cmdlet.  However there is one very important piece of “non-trivial” functionality that the Import-LocalizedData cmdlet provides and that is it searches through various culture specific sub directories looking for a matching .psd1 file for the user’s culture.  For those familiar with .NET development this is very similar to how the .NET binder looks through application’s base sub dirs for the appropriate satellite assembly for the user’s culture.  Let’s see an example of how this works.

First, let’s create a German version of our string resources and put the file in a sub dir titled de-DE.  The name of this sub dir is important.  The name reflects the <language>-<region> that the localized strings target.  Here are the contents of .\de-DE\messages.psd1:

# Contents of .\de-DE\messages.psd1
ConvertFrom-StringData @'
Hello_F1=Wie Geht {0}
Goodbye=Auf Wiedersehen
'@

At this point our dir structure looks like this:

.\test.ps1
.\messages.psd1 (English – fallback)
.\de-DE\messages.psd1

Now I need to introduce a somewhat orthogonal but very handy function called Using-Culture that the PowerShell team blogged a long time ago.  I have updated it for PowerShell 2.0 and I use it to effectively simulate running PowerShell scripts in different cultures.

function Using-Culture ([System.Globalization.CultureInfo]$culture =(throw "USAGE: Using-Culture -Culture culture -Script {scriptblock}"),
                        [ScriptBlock]$script=(throw "USAGE: Using-Culture -Culture culture -Script {scriptblock}"))
{    
    $OldCulture = [System.Threading.Thread]::CurrentThread.CurrentCulture
    $OldUICulture = [System.Threading.Thread]::CurrentThread.CurrentUICulture
    try {
        [System.Threading.Thread]::CurrentThread.CurrentCulture = $culture
        [System.Threading.Thread]::CurrentThread.CurrentUICulture = $culture        
        Invoke-Command $script    
    }    
    finally {        
        [System.Threading.Thread]::CurrentThread.CurrentCulture = $OldCulture        
        [System.Threading.Thread]::CurrentThread.CurrentUICulture = $OldUICulture    
    }    
}

Now let’s try running out test.ps1 script under the German language/region:

PS> Using-Culture de-DE { .\test.ps1 }
Wie Geht John
Auf Wiedersehen

Now that’s what I’m talking about!  Script localization without requiring an advanced degree.  Now, you might ask – what happens when somebody run’s in a culture that I have not localized for?  Let’s see:

PS> Using-Culture fr-FR { .\test.ps1 }
Hello John
Goodbye

When I listed the dir contents above I mentioned that the top-level messages.psd1 was the “fallback”.  Essentially if PowerShell can’t find the specified data file for the current culture it will “fallback” to the top-level data file or .\messages.psd1 in this case (which is English).  This may very well be a feature you never use but if you desire to reach a broad audience with your PowerShell 2.0 modules, consider pulling out your strings into a data file even if you only provide a data file for your native language.  This gives others a much better chance of localizing your module into other languages for you!

Congratulations to the Windows and Windows PowerShell teams for two very excellent releases.  I’ve been using Windows 7 daily since January’s beta release and PowerShell 2.0 drops for even longer.  Both products are destined to be smash hits in my humble opinion.  I’m very excited about the new capabilities of PowerShell 2.0 and the fact that it’s a built-in and required component of Windows 7 means that the time when we can count on PowerShell “just being there” is getting closer.

I’m relaying this invite from Hal & Jonathan – hosts of the PowerScripting Podcast.

Windows isn’t just about the GUI. Starting with Windows 7, you have built-in access to PowerShell version 2, an object-oriented scripting language and command shell. Please join PowerScripting Podcast hosts Jonathan Walz and PowerShell MVP Hal Rottenberg as they interview Distinguished Engineer Jeffrey Snover on launch day! Jeffrey is the chief architect responsible for PowerShell at Microsoft, and he’ll be covering what’s new with the tool and why every system administrator on the planet needs to be using it. If you’ve never attended PowerScripting Live, you are missing out on a great time. The show will be streamed live via Ustream, and viewers can chat with each other, as well as submit questions for the guest.

• When: Thursday, October 22nd, 9:30 PM EDT (GMT-4)
• Where: PowerScripting Live on Ustream, and follow the blog and podcast at PowerScripting.net

Tonight I gave a presentation on the new features in Windows PowerShell 2.0.  I also demo how to create a Windows Troubleshooting Platform that is new in Windows 7.  WTP uses PowerShell scripts to do the heavy lifting of detecting and resolving root causes i.e. problems that need fixing.  I gave this presentation at the Northern Colorado.NET Special Interest Group.  As promised, here are the presentation materials: slide deck and Start-Demo samples.

Before PowerShell came along I had a number of doskey aliases set up like “gt” to go to the temp dir.  I have since converted those aliases to a single g function (short for “go”):

   1: function g($shortcut) {

   2:     $ht = @{

   3:         bin = "C:\Bin";

   4:         doc = "$([Environment]::GetFolderPath('MyDocuments'))";

   5:         sys = "$env:SystemRoot\System32";

   6:         t   = "$env:Temp";

   7:         win = "$env:SystemRoot";

   8:         cf  = "$env:CommonProgramFiles";

   9:         pf  = "$env:ProgramFiles";

  10:         www = "$env:SystemDrive\inetpub\wwwroot";

  11:         gac = "$env:SystemRoot\Assembly\GAC";

  12:         tfs = "C:\Tfs"

  13:         clr = "$([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory())";

  14:     }

  15:  

  16:     if ($shortcut) {

  17:         if (!$ht["$shortcut"]) { 

  18:             throw "$shortcut isn't valid shortcut. Execute g with no params to see valid shortcuts." 

  19:         }

  20:         cd $ht.$shortcut

  21:     }

  22:     else {

  23:         "Valid shortcuts are:"

  24:         $ht.Keys | Sort | select @{n='Shortcut';e={$_}},@{n='Destination';e={$ht.$_}}

  25:     }

  26: }

Usage is pretty simple.  Execute g to see all shortcuts and the associated location:

PS C:\> g
Valid shortcuts are:

Shortcut    Destination
--------   -----------
bin         C:\Bin
cf          C:\Program Files\Common Files
clr         C:\Windows\Microsoft.NET\Framework64\v2.0.50727\
doc         C:\Users\Keith\Documents
gac         C:\Windows\Assembly\GAC
pf          C:\Program Files
sys         C:\Windows\System32
t           C:\Users\Keith\AppData\Local\Temp
tfs         C:\Tfs
win         C:\Windows
www         C:\inetpub\wwwroot

To set-location to the wwwroot dir execute the following:

PS C:\> g www
C:\inetpub\wwwroot

It’s a trivial function but if you spend a lot of time at the PowerShell prompt, it (or something similar) is quite handy.

There are a number of extra steps to take to get V2 remoting to work on workgroup joined computers like the ones in your home – unless you’re running a DC at home (sick puppy).  First up, is a registry setting that makes V2 remoting work on workgroup computers:

PS> new-itemproperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -name LocalAccountTokenFilterPolicy -propertyType DWord -value 1

Be sure to run this from an elevated prompt.  Then from that same elevated prompt, execute the following cmdlet:

PS> Enable-PSRemoting

To verify that remoting is working on this PC by executing the following command (also from an elevated prompt):

PS> Enter-PSSession localhost

If remoting is working you should get a prompt something like this:

[localhost]: PS C:\Users\Keith\Documents>

Note: If you are trying to get PowerShell 2.0 remoting working on an XPMode virtual machine (you know the one you get for free with Windows 7 Pro or higher) then you need to enable Classic share & security model for local accounts like so: 

1. Run Secpol.msc
2. Navigate to Security Settings -> Local Policies -> Security Options -> "Network access: Share and security model for local accounts
3. Change it to "Classic" mode.

Now try re-running Enable-PSRemoting and it should work.

Finally, on the PC(s) that you want to use to initiate remoting, execute this command so that all the local target computers are trusted:

PS> set-item wsman:localhost\client\trustedhosts -value *

Now, at this point you should be able to enter a new pssession to a remote computer.  Note that you don’t have to be in an elevated prompt to do this.  However you will need to pass your credentials to the remote computer like so:

PS> $cred = Get-Credential  # Type in the username/password for an admin account on the remote PC
PS> Enter-PSSession MediaCenterPC –cred $cred

Credential Delegation

One other area that can bite you is credential delegation.  Here is the scenario.  Say you remote into a PC and from that PC you want to access files on another PC via a UNC share.  As things stand now, you run into the following error:

[mediacenterpc]: PS C:\Users\Keith\Documents> dir \\homeserver\photos
Get-ChildItem : Cannot find path '\\homeserver\photos' because it does not exist.
    + CategoryInfo          : ObjectNotFound: (\\homeserver\photos:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

To fix this you have to enable credential delegation (second hop) and use CredSSP authentication.  First on the target/remote computer you need to run this in an elevated prompt:  Note that you can’t run this from a V2 remoting session (you’ll get “access is denied”):

PS> Enable-WSManCredSSP –Role Server

Now on your client/local computer execute the following from an elevated prompt for each remote computer you need credential delegation for:

PS> Enable-WSManCredSSP –Role Client –DelegateComputer <computer_name>

We are close but there is one last step and it requires a tweak via the global policy editor.  Run gpedit.msc and navigate to Computer Configuration –> Administrative Templates –> System –> Credential Delegation as shown below:

Open up the “Allow Delegating Fresh Credentials with NTLM-only Server Authentication” setting.  Enable the setting and then click on the “Show…” button to add a server to the list.  I added mine like so:

Press OK and then press the “Apply” button on the previous dialog to apply the setting.  Now credential delegation will work for that configured remote computer.  Note that when you enter a new PSSession you have to use CredSSP authentication as shown below:

PS> Enter-PSSession MediaCenterPC -Cred $cred -Authentication CredSSP
[mediacenterpc]: PS C:\Users\Keith\Documents> dir \\HomeServer\Software

    Directory: \\HomeServer\Software

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----         7/21/2008   9:37 PM            Add-Ins
d----         7/21/2008  10:01 PM            Home PC Restore CD

Note that from the remoting session on MediaCenterPC, I can now see the files shared from my Windows Home Server.  Woohoo!  It isn’t exactly as straight forward as I would like but it can be done.

One of the best parts of being a Microsoft MVP is having conversations with all the other, really bright MVPs.  The PowerShell team just recently added Doug Finke as an MVP – congratulations Doug!  It isn’t too uncommon for the PowerShell MVPs to challenge and push one another.  It is a great learning experience!

Over the weekend, Doug and I engaged in one of these and in the end we came up with a little bit of PowerShell script (V2 required for the generics support) that can automatically generate wrapper functions around the constructors of public .NET types in an assembly.  These wrapper functions are strongly typed (well mostly) and support generic types.  Here’s the script:

param($assemblyName)
Set-StrictMode -Version Latest

[Reflection.Assembly]::LoadWithPartialName($assemblyName).GetExportedTypes() |
% {
    $fname = $_.FullName
    $typeArgs  = @($_.GetGenericArguments() | %{"`$Of" + $_.Name})
    $typeDecls = @($_.GetGenericArguments() | %{"[string]`$Of" + $_.Name})
    $_.GetConstructors('Instance,Public') |
    % {
        $paramArgs  = @($_.GetParameters() | %{"`$" + $_.Name})
        $paramDecls = @($_.GetParameters() | 
            %{"$(if (!$_.ParameterType.ContainsGenericParameters) {"[$($_.ParameterType)]"})`$$($_.Name)"})
        if ("$paramDecls" -notmatch '\*') {
            $OFS = ','
            if ($typeArgs.Length -gt 0) {
                $genFname = $fname.Substring(0, $fname.LastIndexOf('`'))
                $decls = $typeDecls + $paramDecls
                @"
function New-$($genFname.Replace('.','')) {
    param($decls)
    New-Object `"$genFname$("`[$typeArgs`]")`" $paramArgs
}
 

"@            
            }
            else {
                @"
function New-$($fname.Replace('.','')) {
    param($paramDecls)
    New-Object `"$fname`" $paramArgs
}
 
"@        
            }
        }
    }
}

If you run it on mscorlib, it will product wrapper functions like so:

function New-SystemGuid {
    param([int]$a,[System.Int16]$b,[System.Int16]$c,[System.Byte[]]$d)
    New-Object "System.Guid" $a,$b,$c,$d
}


function New-SystemCollectionsGenericDictionary {
    param([string]$OfTKey,[string]$OfTValue)
    New-Object "System.Collections.Generic.Dictionary[$OfTKey,$OfTValue]"
}




function New-SystemCollectionsGenericList {
    param([string]$OfT)
    New-Object "System.Collections.Generic.List[$OfT]"
}

Then you can create a generic list like so:

PS> $list = New-SystemCollectionsGeneicList –OfT double
PS> $list.add(1.1)
PS> $list.add("two")
Cannot convert argument "0", with value: "two", for "add" to type "System.Double"

PowerShell allows you to use many different characters in your function names besides [_aA-zZ][_aA-zA0-9], which is the typical regex recipe for function and method identifiers in a fair number of languages.  However, in PowerShell you have a much larger palette of characters to choose from e.g.:

function ?? ($expr, $default = $(throw "Must specify default value")) {
    if ($expr -ne $null) {
        $expr
    }
    else {
        $default
    }
}

Function names like these can help you create operators for an internal DSL.  The primary downside is that the operator has to be used in a pre-fix manner e.g.:

PS> ?? ($env:LogDir) $env:temp
C:\Users\Keith\AppData\Local\Temp

Things get really interesting when you start to use mathematical symbols.  Check this out:

PS> function √($num) { [Math]::Sqrt($num) }
PS> √ 81
9
PS> function φ { (1 + (√ 5)) / 2 }
PS> φ
1.61803398874989

This is not really practical since the mathematical symbol characters (0x221A and 0x3C6) aren’t easy to type at the console but it shows the extent to which you can use radically different characters to name your functions.

psmdtag:script - function name

I was excited to hear that the PowerShell ISE editor was based on the new WPF editor that will ship in Visual Studio 2010.  However I was disappointed when I couldn’t find one of my favorite shortcuts in the script editor: Ctrl+L a.k.a. yank line.  Fortunately the object model for the editor is capable enough to support this capability.  Here’s a pretty simple custom menu entry with an assigned keyboard shortcut (Ctrl+L) to perform a yank line in the editor:

   1: [void]$psISE.CustomMenu.Submenus.Add(

   2:     'Yank Line', 

   3:     {

   4:       $editor = $psise.CurrentOpenedFile.Editor

   5:       $line = $editor.CaretLine

   6:       $lineLen = $editor.GetLineLength($line)

   7:       if ($line -lt $editor.LineCount) 

   8:       {

   9:         $editor.Select($line, 1, $line + 1, 1)

  10:       }

  11:       else

  12:       {

  13:         $editor.Select($line, 1, $line, $lineLen + 1)

  14:       }

  15:       [System.Windows.Clipboard]::SetText($editor.SelectedText)

  16:       $editor.InsertText('')

  17:     }, 

  18:     'Ctrl+L'

  19: )

I find this handy for copying an entire line.  I yank the line that I want to copy to the clipboard.  Once it is yanked, I can paste it back as many times as I need.

psmdtag:ise - CustomMenu

Necessity is the mother of invention, or in the case of Windows PowerShell, a new script.  I have a set of 23 large (28 MB) log files on a remote machine in which I need to verify that the last line of each of them is identical.  My first “naive” approach was to do this:

PS> get-content \\server\share\logs\*26_03.csv  | select -last 1

Yeah unfortunately that took so long that I killed it and set out to create a script that would “efficiently” tail a file.  Now my log files were ASCII encoded so it made the task much easier.  Bottom line is that there is FileStream object in .NET that allows you to start at the end of a file and work backwards.  The approach above using Get-Content requires that PowerShell get every single line from a log file with ~1,000,000 lines in it and over the network to boot. 

With FileStream you can read from the end of the file backwards.  Because my files are ASCII, that is very easy to do.  So I created a Tail-Content.ps1 script that you can download.  Note that it doesn’t work on Unicode encoded files and it doesn’t do active tailing.  However, it is very fast for large files.  There are a few interesting parts of the code to examine.  First, if you want to handle paths like PowerShell does, the snippets below show you how to setup your parameters to handle wildcard expansion and literal paths.  This does require that you are on version 2 of PowerShell:

   1: [CmdletBinding(DefaultParameterSetName="Path")]

   2: param(

   3:     [Parameter(Mandatory=$true, 

   4:                Position=0, 

   5:                ParameterSetName="Path", 

   6:                ValueFromPipeline=$true, 

   7:                ValueFromPipelineByPropertyName=$true)]

   8:     [string[]]

   9:     $Path,

  10:     

  11:     [Alias("PSPath")]

  12:     [Parameter(Mandatory=$true, 

  13:                Position=0, 

  14:                ParameterSetName="LiteralPath", 

  15:                ValueFromPipelineByPropertyName=$true)]

  16:     [string[]]

  17:     $LiteralPath,

  18:     

  19:     <elided>

  20: )

Note that the default parameter set is “Path” and the Path parameter accepts pipeline input by name and by value.  This means that raw strings will work as paths assuming they actually contain valid paths.  Also note that both parameters are of type string array.  The LiteralPath parameter is defined in a different, mutually exclusive parameter set named “LiteralPath” and it binds to pipeline input only by property name.  It is important that we also decorated the LiteralPath parameter with the Alias attribute “PSPath”.  This way output of Get-ChildItem (FileInfo) gets bound by property name to the LiteralPath parameter by virtue that PSPath is an alias for the same parameter.  This happens because there is no Path property on FileInfo but there is a PSPath property.  Remember that PowerShell extends the FileInfo type by adding the PSPath NoteProperty.

That sets up the parameters, now here is what you need to do in your Process function to handle Path parameters which could specify paths with wildcards in them:

   1: Process 

   2: {

   3:     if ($psCmdlet.ParameterSetName -eq "Path")

   4:     {

   5:         # In the non-literal case we may need to resolve a wildcarded path

   6:         $resolvedPaths = @()

   7:         foreach ($apath in $Path) 

   8:         {

   9:             $resolvedPaths += @(Resolve-Path $apath | Foreach { $_.Path })

  10:         }

  11:     }

  12:     else 

  13:     {

  14:         $resolvedPaths = $LiteralPath

  15:     }

  16:             

  17:     foreach ($rpath in $resolvedPaths) 

  18:     {

  19:         $PathIntrinsics = $ExecutionContext.SessionState.Path

  20:         

  21:         if ($PathIntrinsics.IsProviderQualified($rpath))

  22:         {

  23:             $rpath = $PathIntrinsics.GetUnresolvedProviderPathFromPSPath($rpath)

  24:         }

  25:         

  26:         Write-Verbose "<cmdlet-name> processing $rpath"

  27:  

  28:         #process file here

  29:     }

  30: }

On line 3 I test which ParameterSet is being used.  If it is the Path parameter set then we need to resolve the paths specified because they may contain wildcards.  I do that on line 9 using Resolve-Path.  Then on line 17 we iterate through each path and process it.  One other detail that you may or may not need to worry about is that $rpath at this point may contain a provider qualified path e.g. Microsoft.PowerShell.Core\FileSystem::C:\foo.txt.  These work fine with PowerShell however if you need to pass this path to a .NET object it won’t recognize that as a valid path.  So on line 21 I check to see if we have a provider qualified path and if I do I get the raw path using $ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath as shown on line 23.  The rest of this script just does low-level byte reads from the end of the file. 

I went back and measured my original approach of using { Get-Content \\server\share\logs\*_26_03.csv | Select -Last 1} and it took ~13 minutes.  Using my Tail-Content script, it took < 1 second.  That is a speed up of about 1789x!

psmdtag:dotnet: FileStream
psmdtag:script: Tail-Content
psmdtag:sample: Advanced Function

I got a very nice email today telling me that I have been awarded as a MVP for Windows Server - Admin Frameworks (aka Windows PowerShell).  Woohoo!  Not sure if I’ll get to make it to the summit this year because of an uncertain job situation but I’m going to try.

Often it is the "little things" that put a smile on your face.  PowerShell does that for me a lot.  Take for instance a simple little problem I ran into today while unit testing some code that generates log files.  I wanted to know how long it took to write all the log files to disk.  Due to the way the code works on a background thread, it wasn't particularly easy to use a System.Diagnostics.Stopwatch to do this.  You could do this manually by inspecting the file dates (DateCreated and DateModified) in Windows Explorer but it only shows resolution down to minutes and I have to do the math myself.  No good.  Well this information is easy to figure out with PowerShell.  Just CD into the log dir and execute:

PS> $start = dir | foreach {$_.CreationTime} | sort | select -first 1
PS> $stop  = dir | foreach {$_.LastWriteTime} | sort -desc | select -first 1
PS> $stop - $start

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 10
Milliseconds      : 734
Ticks             : 107341689
TotalDays         : 0.000124238065972222
TotalHours        : 0.00298171358333333
TotalMinutes      : 0.178902815
TotalSeconds      : 10.7341689
TotalMilliseconds : 10734.1689

:-)

Yes PowerShell can do all sorts of acrobatics WRT managing and querying a computer but it can also do the simple stuff in a pretty straight forward manner.

Sign up for some free PowerShell training via this TechNet webcast.  Here’s the overview:"

In this webcast, we provide an introduction to Windows PowerShell for IT professionals and show how to automate client administrative activities in the Windows Server 2008 and Windows Vista operating systems. We explore the features and capabilities of Windows PowerShell, describe customer scenarios to manage day-to-day server and client administration activities, and discuss command-line syntax usage.

Presenters: John Baker, IT Pro Evangelist, Microsoft Corporation, and Yung Chou, IT Pro Evangelist, Microsoft Corporation

I like these because you usually get some decent info for very little investment and if it doesn’t turn out to be right for you, you can bail easily with very little time lost.

Oh thank you, thank you TFS team!!!  This is a great development because it enables version control queries for mere mortals (ie those of us not well versed in SQL Reporting Services).  It also enables easily scriptable queries.  With the October Team Foundation Power Tools drop, you get a PowerShell console icon in the start menu or you can just add the following to your profile:

Add-PSSnapin Microsoft.TeamFoundation.PowerShell

Once you’ve done that, here are the new cmdlets you get:

• Add-TfsPendingChange
• ConvertTo-FixedByte
• ConvertTo-FixedPath
• Get-TfsChangeset
• Get-TfsChildItem
• Get-TfsItemHistory
• Get-TfsItemProperty
• Get-TfsPendingChange
• Get-TfsServer
• Get-TfsShelveset
• Get-TfsWorkspace
• New-TfsChangeset
• New-TfsShelveset
• Remove-TfsPendingChange
• Remove-TfsShelveset
• Restore-TfsShelveset
• Select-TfsItem
• Set-TfsChangeset
• Update-TfsWorkspace

Now that you have the Team Foundation snapin loaded, you can start doing some interesting stuff like finding out who has pending changes older than 30 days:

PS> Get-TfsPendingChange . -User * -Recurse | 
    where {$_.CreationDate -lt (get-date).AddDays(-30)} | 
    select OwnerName -expand PendingChanges | 
    format-table Filename, ChangeType, OwnerName, @{l="Server Folder";e={$_.ServerItem}} -auto

Or say you want to see the level of checkin activity over the past 30 days:

PS> $history = Get-TfsItemHistory . -Recurse -Stopafter 1000 | 
               Where {$_.CreationDate -gt (get-date).AddDays(-30)} | 
               Sort CreationDate | 
               Select Owner,@{n='CreationDate';e={$_.CreationDate.ToShortDateString()}}
PS> $history | Group CreationDate -noelem

Count Name                     
----- ----                     
    4 10/12/2008               
    7 10/13/2008               
  103 10/14/2008                
   67 10/15/2008                
   23 10/16/2008                
   13 10/17/2008                
    3 10/19/2008                
    3 10/20/2008                
   23 10/21/2008                
   19 10/22/2008                
   31 10/23/2008                
   67 10/24/2008                
   10 10/27/2008                
   13 10/28/2008                
   29 10/29/2008                
    7 10/30/2008                
    4 10/31/2008                
    3 11/3/2008                 
    2 11/4/2008                 
    7 11/5/2008                 
   10 11/6/2008                 
    3 11/7/2008                 

If you have the excellent PowerGadgets, then you could do this:

PS> $history | group CreationDate | Out-Chart -Caption "Checkins/Day" -Size 480,320 -modal

And get this nice graph:

Now if I’m a project manager on a large team, I might want to see “who” is checking in a bunch of code right before a deadline.  That is easy enough:

67> $history | Group CreationDate | 
    Foreach { "$($_.Name) - Total Checkins: $($_.Count)";
              $_.Group | group Owner | 
                  sort @{e={$_.Count};asc=$false},Name | 
                  Format-Table Count,Name -auto }

10/12/2008 - Total Checkins: 4

Count Name
----- ----
    4 Acme\moe


10/13/2008 - Total Checkins: 7

Count Name
----- ----
    3 Acme\moe
    2 Acme\socrates
    1 Acme\curly
    1 Acme\optimus

Querying is an especially powerful aspect of PowerShell and teamed with these new Team Foundation version control cmdlets, you have access to some interesting information.

psmdtag:snapin: Team Foundation Power Tools
psmdtag:snapin: TFPT

I’ll be at the PDC next week.  I get there Saturday night to attend a Sunday pre-con.  If any of you PowerShellers are going to be at the PDC, drop me a line.  I’d like to meet you and talk PowerShell.  There will be one session on PowerShell at the PDC that Jeffrey Snover will be presenting:

PowerShell: Creating Manageable Web Services

This session is on Thursday from 8:30 am to 9:45 am in 406A.  If you haven’t seen Jeffrey talk, he is a great speaker and passionate advocate of PowerShell (he should be, he’s the primary architect of PowerShell).

See you there!

The popularity of PowerShell is shooting through the roof right now.  Check out this TIOBE index from August 2008.  Notice the delta in position rating on PowerShell. What is that, like 10 up arrows. Impressive.

I got asked this question by someone I can't seem to reply to. Anyway the scenario involves Unix, Macs and PCs writing to the same Samba server.  The file attributes indicate readonly, hidden and system.  The use of the -force parameter will get PowerShell to display hidden/system files.  However the OP reports that Windows Explorer gets the same error.  This smells like invalided characters in the path.  This Microsoft KB article gives some guidance on this sort of problem in the "Invalid File Names" section.  If anyone else has run into this issue specifically, feel free to post a comment on how you eventually removed the offending files.

Raymod Chen wrote a blog post called "Don't be helpless: ..." where he shows a batch command to start the process of finding which executables use a particular DLL entry point.

for /f %i in (dlls.txt) do ^
@echo %i & link /dump /imports %i | findstr PostThreadMessage

The hard work is done by link (dumpbin really) so the script provides the glue code and formatting support.  I just had to give this a go in PowerShell where I knew the formatting would be superior plus I wanted to support searching on multiple entry points.  Here is the script I came up with:

param([string[]]$filter=$(throw "-filter parameter is required"))

get-process | select ProcessName -expand Modules -ea 0 |
    foreach {
        $dll = $_
        link /dump /imports $_.filename | 
            select-string $filter | 
            select @{n='Process';e={$dll.ProcessName}}, 
                   @{n='Dll';    e={$dll.ModuleName}}, 
                   @{n='Entry';  e={$_.Line.Substring(6)}} 
    } | 
    format-table Dll, Entry -groupby Process 

The script output looks like this:

PS> .\FindDllEntryPoint.ps1 'PostThreadMessage','QueueUserWorkItem'


   Process: apcsystray

Dll                       Entry
---                       -----
SHELL32.dll               77E19FF7    35F QueueUserWorkItem
SHELL32.dll               77D718C9    222 PostThreadMessageW
SHLWAPI.dll               77E09FF7    35F QueueUserWorkItem
SHLWAPI.dll               77D5B4B9    221 PostThreadMessageA
ole32.dll                 77D618C9    222 PostThreadMessageW
MSCTF.dll                 77D618C9    222 PostThreadMessageW
DpOFeedb.dll                          205 PostThreadMessageW


   Process: DPAgnt

Dll                       Entry
---                       -----
DPAgnt.exe                            205 PostThreadMessageW
SHELL32.dll               77E19FF7    35F QueueUserWorkItem

Now that is some nice formatting made possible by the Format-Table -GroupBy parameter.

The following is a script that I have set up on my dev PCs to run nightly via a scheduled task:

## CatalogFileSystem.ps1
param([string[]]$paths)
Set-PSDebug -Strict

function Main {
    foreach ($path in $Paths) {
        if (!(Test-Path $path -PathType Container)) {
            Write-Error "'$path' doesn't exist or isn't a directory"
            exit 1
        }
		
        $filelist = Join-Path $path filelist.txt
        $dirlist  = Join-Path $path dirlist.txt
		
        Remove-Item $filelist -ErrorAction SilentlyContinue
        Remove-Item $dirlist  -ErrorAction SilentlyContinue
		
        CatalogFolder $path	
    }
}

function CatalogFolder($path) {
    Get-ChildItem $path -ErrorAction SilentlyContinue | sort FullName | foreach {
        if ($_.PSIsContainer) {
            $_.FullName >> $dirlist
            CatalogFolder $_.FullName
        }
        else {
            $_.FullName >> $filelist
        }
    }
}

. Main
## End of CatalogFileSystem.ps1

My scheduled task is configured like so (and runs everyday at 4 am):

Program: C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe
Arguments: -Command C:\Bin\CatalogFileSystem C:, D:

I also set this task to run with highest privileges on Vista so it can catalog more of the nooks and crannies of my filesystem.  This script creates two files setting at the root of each path supplied.  In my case:

C:\dirlist.txt
C:\filelist.txt
D:\dirlist.txt
D:\filelist.txt

Searching for files on my filesystem is now very easy:

PS> Select-String afxwin\.h \filelist.txt | select Line

Line
----
C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\include\afxwin.h
C:\Program Files\Microsoft Visual Studio 9.0\VC\ce\atlmfc\include\afxwin.h

In fact I have created a shortcut function for the above I call Find-File (alias ff):

Set-Alias ff Find-File
function Find-File($pattern) {
    $filelist = Join-Path $pwd.drive.root filelist.txt
    if (!(Test-Path $filelist -PathType Leaf)) {
        Write-Error "$filelist doesn't exist or isn't a file"
    }
    Select-String $pattern $filelist | foreach {$_.Line}
}

And then this sort of filename search gets even easier:

PS> ff afxwin\.h
C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\include\afxwin.h
C:\Program Files\Microsoft Visual Studio 9.0\VC\ce\atlmfc\include\afxwin.h

Now you might be wondering why I don't just use the search built into Vista.  Well first off, Vista's search doesn't index your whole hard drive or any volumes other than the contents of C: by default.  While it can be set up to index more locations I worry about the performance hit because the second issue is that the Vista search indexer runs in the background all the time.  The CatalogFileSystem script runs just once a day (or however often you schedule it) when you're typically not using the computer.  Yeah, it could be as much as 24 hours out of date but the vast majority of the time I'm searching for files that have been on my system for a while: C++ header files, SDK header files, C runtime source files, windows DLLs, etc.

I'm sure some folks are going to think this is goofy but honestly I do search the filelist.txt file quite often (not so much the dirlist.txt file).  Do you have any similar convenience scripts like this?  If you do, please add a comment and let me know.