A PowerShell Wander: ToolBox Mindset, –ExpandProperty, DMZs and Remote Profiles

PowerShell Team

I was reading PowerShell remoting in Windows Server 2008 R2.  The great thing about this article is that it documents how to use Group Policy to enable PSRemoting on lots of machines automatically.  In the article there was the following heads up:

Commands that are executed against a remote machine do not have access to information defined within your local profile. As such, commands that use a function or alias defined in your local profile will fail unless they are defined on the remote machine as well.

The great thing about PowerShell is that it is a toolbox

The great thing about toolboxes is that they have general purpose utilities that creative people can use their inspiration to do things that the tool designers didn’t think of when they developed the tool.  One of my favorite examples of this came from a problem with SELECT.  SELECT is a utility which selects a set of properties from the incoming object.  It creates a new object and adds those selected properties as NoteProperties on that new object.  e.g.

PS> Get-Process *ss

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
——-  ——    —–      —– —–   ——     — ———–
    917      14     3420       2364    52     9.97    424 csrss
    771      27     3484      13428   189   108.02    512 csrss
   1989      45    18272      17820    87    95.83    556 lsass
     30       2      476        124     5     0.06    320 smss

PS> Get-Process *ss |Select ID,Handles,ProcessName

                      Id                  Handles ProcessName
                      —                  ——- ———–
                     424                      930 csrss
                     512                      770 csrss
                     556                     1984 lsass
                     320                       30 smss

PS> Get-Process *ss |Select ID,Handles,ProcessName |Get-Member

   TypeName: Selected.System.Diagnostics.Process

Name        MemberType   Definition
—-        ———-   ———-
Equals      Method       bool Equals(System.Object obj)
GetHashCode Method       int GetHashCode()
GetType     Method       type GetType()
ToString    Method       string ToString()
Handles     NoteProperty System.Int32 Handles=925
Id          NoteProperty System.Int32 Id=424
ProcessName NoteProperty System.String ProcessName=csrss

PS> Get-Process *ss |Select ProcessName


Sidenote: notice that the TYPE of the result is Selected.System.Diagnostics.Process.  We did that in V2 to be consistent with our principle of always trying to help you keep track of where information came from.  The idea is that if you are debugging a script and have an examine an object and see this typename, you have more information about where it came from to help debug your script.

Anyway, that is great but notice what happens when you select a single property you get an object with a single property.  Often you just want the values of the property not an object with a single property.  The solution to that has been:

PS> Get-Process *ss |foreach {$_.ProcessName}

That works but I don’t like it very much.  We had lots of discussions about what to do about this.  Some people wrote a function which did this operation and thought we should include it in the next version.  Others felt like we ought to put a switch on Select which say something like –VALUEONLY.  It was Lee Holmes that pointed out that we already support this.  I looked at him like he had a rat’s tail hanging out of his mouth when he said that.  He said that Select –ExpandProperty did the trick.  This switch was designed to work with objects that have properties which are collections.  For instance: 

PS> Get-Service WinMgmt |Select DependentServices

{wscsvc, SharedAccess, iphlpsvc}

PS> Get-Service WinMgmt |Select -ExpandProperty DependentServices

Status   Name               DisplayName
——   —-               ———–
Running  wscsvc             Security Center
Stopped  SharedAccess       Internet Connection Sharing (ICS)
Running  iphlpsvc           IP Helper

Pretty cool right?  This tool was designed to work on properties which are collections.  Lee Holmes wondered, “What would it do on a property which wasn’t a collection?”.

PS> Get-Process *ss |Select -ExpandProperty ProcessName

OH YEAH BABY!  You asked for it you got it!  Using the toolkit mindset, Lee was able to figure out that we already supported this function.  (You might point out that this is longer than the foreach but it turns out to be a ton easier because of tab completion.)

So – what does this have to do with the remoting warning about not having access to any of the functions you defined in your profile file?  Well, it turns out that the command Invoke-Command has a parameter –FILEPATH which allows you to specify a file that you want to run on the remote machine.  We added this feature to help people machine machines in DMZs where it can be difficult to ensure that the script you want to run will be on that machine and it can be difficult for that machine to have access to a shared folder of scripts.  We send the file across and execute it so there is deployment free script execution.  (This is a super important feature that people haven’t quite tuned into yet.  I’m going to write a blog in the future about how to use this capability to use PowerShell as a bootstrap management agent to do all of your management functions.)  So the example of this is something like

PS> $DmzMachines = New-PSSession -ComputerName (cat DmzMachines.txt)
PS> Invoke-Command $DmzMachines -FilePath c:\scripts\Get-Inventory.ps1

PowerShell transfers and executes the Get-Inventory.ps1 script to all the machines.  From there, you can connect the dots to putting the functions you want everywhere into a file called RemoteProfile and doing the following:

PS> Invoke-Command $DmzMachines -FilePath c:\scripts\RemoteProfile.ps1

Be aware that this mechanism has limitations.  In a local profile, you can invoke other files on your system.  Using this technique, those files aren’t on the other system so that won’t work – the files have to be self contained.  That is why I called it RemoteProfile.ps1 .  I keep it separate from my normal profile.


Jeffrey Snover [MSFT]
Distinguished Engineer
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx


Discussion is closed.

Feedback usabilla icon