In order to determine how much the PC sleeps I wrote a small PowerShell script to analyze event log entries.  Here are the contents of the script Get-SleepInfo.ps1:

param($Newest = 50)

function Parse-EventLogEntry
{
    param(
        [Parameter(Mandatory=$true, Position=0, ValueFromPipeline=$true)]
        [System.Diagnostics.EventLogEntry[]]
        $eventInfo
    )

    Process
    {
        foreach ($info in $eventInfo)
        {
            $enterSleep = [DateTime]::Parse($info.ReplacementStrings[0]);
            $exitSleep = [DateTime]::Parse($info.ReplacementStrings[1]);
            $duration = $exitSleep - $enterSleep
            $wakeSource = 'Unknown'
            if ($info.Message -match 'Wake Source:\s*(.*)$')
            {
                $wakeSource = $matches[1]
            }
            new-object psobject -Property @{Duration = $duration; Sleep = $enterSleep; 
                                            Wake = $exitSleep; WakeSource = $wakeSource}
        }
    }
}

Get-EventLog -LogName System -Source Microsoft-Windows-Power-Troubleshooter -Newest $Newest | 
     Sort TimeGenerated | Parse-EventLogEntry

After running this on my MediaCenter PC, I get the following data:

Duration         Sleep                Wake                 WakeSource
--------         -----                ----                 ----------
01:04:22.2225162 5/2/2013 2:47:08 PM  5/2/2013 3:51:31 PM  5Windows will exec...
00:44:42.9902954 5/3/2013 12:33:23 AM 5/3/2013 1:18:06 AM  5Windows will exec...
00:12:56.0674401 5/3/2013 2:18:08 AM  5/3/2013 2:31:05 AM  5Windows will exec...
06:59:43.2874463 5/3/2013 3:31:08 AM  5/3/2013 10:30:52 AM 0
05:54:48.3185846 5/4/2013 5:01:08 AM  5/4/2013 10:55:57 AM 0
00:30:09.8591193 5/5/2013 1:15:01 AM  5/5/2013 1:45:11 AM  5Windows will exec...
05:30:49.2332622 5/5/2013 5:01:04 AM  5/5/2013 10:31:54 AM 0
03:12:13.2579267 5/6/2013 5:02:20 AM  5/6/2013 8:14:33 AM  0
00:14:30.6312742 5/7/2013 1:25:14 AM  5/7/2013 1:39:45 AM  5Windows will exec...
00:11:23.6864251 5/7/2013 2:39:59 AM  5/7/2013 2:51:23 AM  5Windows will exec...
04:18:45.8838138 5/7/2013 4:34:44 AM  5/7/2013 8:53:30 AM  0
01:19:03.7671589 5/7/2013 12:46:44 PM 5/7/2013 2:05:48 PM  0
00:37:13.6740184 5/8/2013 12:59:29 AM 5/8/2013 1:36:43 AM  5Windows will exec...
00:01:11.1209186 5/8/2013 2:36:57 AM  5/8/2013 2:38:09 AM  5Windows will exec...
02:13:18.0939494 5/8/2013 3:38:12 AM  5/8/2013 5:51:31 AM  5Windows will exec...

The problematic wake source above (truncated in this output to fit the blog post width) is:

5Windows will execute ‘\Microsoft\Windows\Media Center\mcupdate_scheduled’ scheduled task that requested waking the computer.

Ah, good ol’ mcupdate_scheduled is configured to wake the computer if it is asleep.  This situation is quickly fixed with a little tweak to the scheduled task to a) not wake the computer and b) change the trigger to a time the computer is likely to be on.  With this tweak hopefully the MediaCenter will now sleep through the night.

Update: after tweaking the scheduled task “mcupdate_scheduled”, my Media Center PC slept for a good 12 hours before *I* woke it up:

02:13:18.0939494 5/8/2013 3:38:12 AM  5/8/2013 5:51:31 AM  5Windows will exec...
12:15:24.3601661 5/9/2013 1:24:42 AM  5/9/2013 1:40:07 PM  0

It would be nice to build a mechanism into our script to “auto-elevate” if UAC is enabled.  The trick to doing this is to run Start-Process –verb runas.  After that you only need to figure out if the current user is an administrator and if UAC is enabled.  And you have to package up the script’s parameters as an array of strings.  All of this can be accomplished fairly easily with this bit of PowerShell script:

function IsAdministrator
{
    $Identity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
    $Principal = New-Object System.Security.Principal.WindowsPrincipal($Identity)
    $Principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
}


function IsUacEnabled
{
    (Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System).EnableLua -ne 0
}

#
# Main script
#
if (!(IsAdministrator))
{
    if (IsUacEnabled)
    {
        [string[]]$argList = @('-NoProfile', '-NoExit', '-File', $MyInvocation.MyCommand.Path)
        $argList += $MyInvocation.BoundParameters.GetEnumerator() | Foreach {"-$($_.Key)", "$($_.Value)"}
        $argList += $MyInvocation.UnboundArguments
        Start-Process PowerShell.exe -Verb Runas -WorkingDirectory $pwd -ArgumentList $argList 
        return
    }
    else
    {
        throw "You must be administrator to run this script"
    }
}

If you launch this script from a non-elevated context, it will fire up a new PoweShell session that is elevated assuming UAC is enabled.

The second package is Pscx-3.0.0-RC.msi.  This is a traditional Windows installer package.  The benefit of using an MSI is that the user doesn’t have to worry about unblocking the file before installing it.  The MSI file is also Authenticode signed with an extended validation code signing certificate so it should make it past Windows 8 SmartScreen.  I’d like to extend a big thanks to DigiCert for graciously donating the EV code signing certificate to us.

INSTALLATION NOTE: the WiX-based installer modifies the PSModulePath environment variable but the modification doesn’t always seem to be in effect after installation.  If Import-Module Pscx –RequiredVersion 3.0.0.0 fails to load PSCX, import the module by path (C:\Program Files (x86)\PowerShell Community Extensions\Pscx3\Pscx\Pscx.psd1) until you get a chance to reboot.  After that, you shouldn’t have to specify the path.

Another aspect of Pscx 3.0 is that it is compiled against .NET 4.0 and takes advantage of some features specific to Windows PowerShell 3.0.  Over time, we will focus our new feature efforts on the Pscx 3.0 branch.

PSCX 2.1 and 3.0 Side-by-Side Support

With this release, you can install Pscx 2.1 and 3.0 side-by-side.  Note however that if you xcopy install Pscx 2.1 into your user’s Modules directory, PowerShell will find that version of Pscx before the 3.0 version.  In order to ensure you load a specific version of Pscx, use the –RequiredVersion parameter on Import-Module e.g.

Import-Module Pscx -RequiredVersion 3.0.0.0

Support for AllSigned Execution Policy

Each of the two packages above (2.1 and 3.0) supported execution in an AllSigned environment.  All of the script files (*.ps1, *.psm1 and *.ps1xml) have been signed.  Of course, this means you can’t modify these scripts (i.e. to fix bugs) and still run them AllSigned.

New Features

There are not a lot of new features in this release but there are a few handy additions including:

• Get-Parameter – thanks to Jason Archer for contributing this great way to visual a command’s parameter information.
• Import-VisualStudioVars – for developers who like to spend their time in PowerShell instead of cmd.exe, this function takes care of importing the build environment for the specified version of Visual Studio.  The 2008, 2010 and 2012 versions of Visual Studio are supported.
• Start-PowerShell – a wrapper for PowerShell.exe that utilizes the PowerShell parameter parsing engine to make invocation of various flavors of PowerShell (from PowerShell obviously) easier.  While testing the AllSigned support I used this command a lot:

  Start-PowerShell -NoProfile -ExecutionPolicy AllSigned -Version 2

• Get-ExecutionTime – since PowerShell 2.0, the HistoryInfo object for a command has included both the StartExecutionTime and the EndExecutionTime. This command makes it easy to see the total execution time for any command e.g.:

C:\PS> Get-ExecutionTime

  Id ExecutionTime    HistoryInfo
  -- -------------    -----------
   1 00:00:02.9919258 Get-ChildItem C:\Windows\System32
   2 00:00:00.2650339 Get-Process
   3 00:00:00.2499424 Get-Service

Bug Fixes

Oisin spent a good deal of time fixing issues in the Read-Archive and Expand-Archive cmdlets.  We updated the version of 7z that we are using (to 9.x) and modified the cmdlets to use SevenZipSharp.  I also fixed a number of bugs in Invoke-Elevated (alias su), Set-Writable, Edit-File and type accelerators breaking on PowerShell 3.0.

As you use these release candidates please report any issues to the Pscx CodePlex project.  Thanks for supporting Pscx!

Be sure to read the installation notes on the download page.  If you’re having problems importing the PSCX module, you might need to reboot.  Yeah I know that sucks but either WiX 3.6 just isn’t handling environment variable updates quite right or I’m not using WiX right. 

If you’re using PSCX and Windows PowerShell 3.0, please take this version for a spin.  You can use it side-by-side with your current version of PSCX 2.x.  When you import PSCX specify the RequiredVersion parameter as shown below e.g.:

Import-Module pscx –RequiredVersion 3.0.0.0

And please, report problems back to the CodePlex site.  I haven’t always been able to reply quickly to issues but we do monitor them.  Thanks!

As we work on PSCX 3.0 there are a few binary cmdlets that we will mark with this attribute to let you know to switch over to PowerShell’s built-in equivalent before we eliminate the cmdlet completely in the next release.  Here’s a snippet that shows how to apply the ObsoleteAttribute in your source code:

1 [OutputType(typeof(MailMessage))]
2 [Cmdlet(VerbsCommunications.Send, PscxNouns.SmtpMail,
3         DefaultParameterSetName = "Authenticated",
4         SupportsShouldProcess = true)]
5 [Obsolete(@"The PSCX\SendSmtpMail cmdlet is obsolete " +
6            "and will removed in the next version of " +
7            "PSCX. Use the built-in Send-MailMessage.")]
8 public class SendSmtpMailCommand : PscxCmdlet
9 {

The resulting of executing this cmdlet with PSCX v3 loaded is:

C:\PS> Send-SmtpMail
WARNING: The PSCX\SendSmtpMail cmdlet is obsolete and will removed in the next version of 
PSCX. Use the built-in Send-MailMessage.

There is an ObsoleteAttribute constructor overload that takes a boolean that converts the warning to an error.  I’m not sure how useful that is but PowerShell does honor that setting and will generate a terminating error in this case:

C:\PS> Send-SmtpMail
The PSCX\SendSmtpMail cmdlet is obsolete and will removed in the next version of PSCX. Use 
the built-in Send-MailMessage.
At line:1 char:1
+ Send-SmtpMail
+ ~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (Send-SmtpMail:String) [], RuntimeException
    + FullyQualifiedErrorId : UseOfDeprecatedCmdlet

It’s nice to see PowerShell honoring more of the .NET attributes – where it makes sense that is.

A common use of ADS is to indicate that a file downloaded by Internet Explorer came from the Internet Zone.  Files coming from the internet could be potentially dangerous.  Various applications check for this stream and if it is present and contains information indicating the “Internet” zone, they might block access or in the case of PowerShell’s RemoteSigned execution policy, only execute the file if it is signed.

Previous to PowerShell V3, you could use the SysInternals streams.exe tool to list and remove alternate data streams.  A common application of this tool was to delete all streams in a file.  That was a rather crude but effective way to “unblock” a file downloaded from the internet.

This is also one area where CMD.EXE was one up on PowerShell.  From a CMD prompt, you can use “dir /r” to list files and their alternate data streams.  You can also create/overwrite streams with CMD.exe like so “echo.>test.exe:Zone.Identifier” which would “unblock” an internet zone file.  You can also unblock such files by selecting the file’s Properties in Windows Explorer and pressing the “Unblock” button at the bottom right of the general tab.  However this is not convenient if you need to do this to dozens or hundreds of files.  With the PowerShell Community Extensions 2.0, we introduced an Unblock-File cmdlet that would delete only the stream named Zone.Identifier.  That is the stream that Internet Explorer creates when you download a file.  Fortunately with PowerShell V3, we can obsolete that cmdlet because V3 offers several ways to manage alternate data streams.

First up is PowerShell’s own Unblock-File cmdlet which, like the PSCX equivalent, is quite easy to use:

C:\PS> Get-Command Unblock-File -All

Capability      Name   ModuleName
----------      ----                                     ----------
Cmdlet          Unblock-File                             Pscx
Cmdlet          Unblock-File                             Microsoft.PowerShell.Utility

C:\PS> Get-ChildItem *.ps1 | Microsoft.PowerShell.Utility\Unblock-File

Note that you wouldn’t normally need to prefix Unblock-File with Microsoft.PowerShell.Utility.  In this case, I wanted to make sure I was using the PowerShell Unblock-File and not the one from PSCX.

In addition to using the big gun of Unblock-File you can also manipulate streams with the following cmdlets:

C:\PS> Get-Command -ParameterName Stream | Where ModuleName -match 'Microsoft.*?Manag' 

Capability Name          ModuleName
---------- ----          ----------
Cmdlet     Add-Content   Microsoft.PowerShell.Management
Cmdlet     Clear-Content Microsoft.PowerShell.Management
Cmdlet     Get-Content   Microsoft.PowerShell.Management
Cmdlet     Get-Item      Microsoft.PowerShell.Management
Cmdlet     Remove-Item   Microsoft.PowerShell.Management
Cmdlet     Set-Content   Microsoft.PowerShell.Management

Here is how you can list all the alternate data streams in a file and the contents of any particular data stream:

C:\PS> Get-Item .\Pscx-2.0.0.1.zip -Stream *

   FileName: C:\Users\Keith\Downloads\Pscx-2.0.0.1.zip

Stream                   Length
------                   ------
:$DATA                  1799345
Zone.Identifier              26

C:\PS> Get-Content .\Pscx-2.0.0.1.zip -Stream Zone.Identifier
[ZoneTransfer]
ZoneId=3

Note that :$DATA is the main stream i.e. the file’s primary contents.

If you need to clear the contents of a data stream without removing the stream completely, you can use Clear-Content’s –Stream parameter e.g.:

C:\PS> Clear-Content .\Pscx-2.0.0.1.zip -Stream Zone.Identifier
C:\PS> Get-Content .\Pscx-2.0.0.1.zip -Stream Zone.Identifier
C:\PS> Get-Item .\Pscx-2.0.0.1.zip -Stream *

   FileName: C:\Users\Keith\Downloads\Pscx-2.0.0.1.zip

Stream                   Length
------                   ------
:$DATA                  1799345
Zone.Identifier               0

To completely remove the stream, use Remove-Item’s –Stream parameter e.g.:

C:\PS> Remove-Item .\Pscx-2.0.0.1.zip -Stream Zone.Identifier
C:\PS> Get-Item .\Pscx-2.0.0.1.zip -Stream *

   FileName: C:\Users\Keith\Downloads\Pscx-2.0.0.1.zip

Stream                   Length
------                   ------
:$DATA                  1799345

And if you need to create an alternate stream, you can do so using Add-Content’s –Stream parameter e.g.:

C:\PS> Add-Content Pscx-2.0.0.1.zip -Str Zone.Identifier "[ZoneTransfer]`r`nZoneId=3"
C:\PS> Get-Item Pscx-2.0.0.1.zip -Stream *

   FileName: C:\Users\Keith\Downloads\Pscx-2.0.0.1.zip

Stream                   Length
------                   ------
:$DATA                  1799345
Zone.Identifier              26

C:\PS> Get-Content .\Pscx-2.0.0.1.zip -Stream Zone.Identifier
[ZoneTransfer]
ZoneId=3

Finally, Set-Content –Stream can be used to modify the content of an existing stream.

The new  Unblock-File cmdlet as well as the upgrades to the *-Content and Get/Remove-Item  cmdlets are a very welcome enhancement to PowerShell’s file handling capabilities.

C:\PS> ipconfig -all

However passing arguments to certain exes can become surprising difficult when their command line parameter syntax is complex i.e. they require quotes and use special PowerShell characters such as @ $ ;.  A lot of these problems can be solved by placing single or double quotes in the right places or by escaping PowerShell’s special characters e.g.:

C:\PS> tf.exe status . /workspace:HILLR1;hillr /r
There are no pending changes.
The term 'hillr' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:35
+ tf.exe status . /workspace:HILLR1;hillr /r
+                                   ~~~~~
    + CategoryInfo          : ObjectNotFound: (hillr:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Note that in the command line above the “/workspace” parameter value is specified using a special syntax that TF.exe recognizes i.e. <workspace_name>;<username>.  Unfortunately the semicolon is a statement separator in PowerShell which means that TF.exe only sees the parameters before the semicolon.  We can use the ECHOARGS.exe utility from the PowerShell Community Extensions to verify this:

C:\PS> echoargs.exe status . /workspace:HILLR1;hillr /r
Arg 0 is <status>
Arg 1 is <.>
Arg 2 is </workspace:HILLR1>

In this case, the solution is simple – just escape the semicolon e.g.:

C:\PS> tf.exe status . /r /workspace:HILLR1`;hillr
File name     Change Local path
------------- ------ -----------------------------------------
$/Foo/Trunk/Tools/Bin
TfsTools.psm1 edit   C:\Tfs\Foo\Trunk\Tools\Bin\TfsTools.psm1

1 change(s)

This works up to the point where you get quite frustrated figuring out which characters to escape and which parameter/argument pairs need to be quoted and whether you should use single quotes or double quotes.  Fortunately, it looks like we will get a way to tell the PowerShell argument parser to stop doing so much work for us and just pass the args through “as-is”.  In other words, you can tell PowerShell to become a “dumber” command line parser.  This mode is invoked using the character sequence: –% and it works from the point it appears on the command line to the end of that line.  Note that the character sequence may change or the feature could be completely removed before V3 ships.

Given this new feature, here’s how you use it.  Take this example of a problematic set of command line parameters:

C:\PS> sqlcmd -S .\SQLEXPRESS -v lname="Gates" -Q "SELECT FirstName,LastName FROM
AdventureWorks.Person.Contact WHERE LastName = '$(lname)'"
The term 'lname' is not recognized as the name of a cmdlet, function, script
file, or operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.
At line:1 char:126
+ ...  LastName = '$(lname)'"
+                    ~~~~~
    + CategoryInfo          : ObjectNotFound: (lname:String) [], CommandNotFou
   ndException
    + FullyQualifiedErrorId : CommandNotFoundException

C:\PS> sqlcmd --% -S .\SQLEXPRESS -v lname="Gates" -Q "SELECT FirstName,LastName F
ROM AdventureWorks.Person.Contact WHERE LastName = '$(lname)'"
FirstName                                          LastName

---------------------------------- -----------------------------------
Janet                              Gates

(1 rows affected)

You can put the –% later in the parameter list if you want.  You might want to do this if you need to use PowerShell variable expansion in some of the arguments.  Just note that once you specify –% the rest of the command line will be parsed “dumbly”.  You will get no PowerShell variable expansion or grouping expressions and you won’t be able to escape newlines.  One thing you can do in this special parsing mode is expand environment variables using the batch syntax of %ENV_VAR% e.g.:

C:\PS> $env:colname = "LastName"
C:\PS> sqlcmd -S .\SQLEXPRESS -v lname="Gates" --% -Q "SELECT FirstName,LastName F
ROM AdventureWorks.Person.Contact WHERE %colname% = '$(lname)'"
FirstName                                          LastName

---------------------------------- -----------------------------------
Janet                              Gates

(1 rows affected)

So far my favorite two features new to this drop are both in the Integrated Scripting Editor (ISE). The first is the “most recently opened files list” on the File menu and second is the switch to a two pane ISE (combines the output and command panes into one). Oh yeah, there isn’t much in the help system until you run Update-Help from an elevated prompt.

C:\PS> Get-Process | Where PM -gt 100MB
...
C:\PS> Get-Process | Foreach Name
...

The intent of this “syntax” is to make it easier for folks get started with PowerShell.  Compared to the commands below, I can see the value of the simplified syntax:

C:\PS> Get-Process | Where {$_.PM -gt 100MB}
...
C:\PS> Get-Process | Foreach {$_.Name}
...

When folks are first learning PowerShell, the special variable $_ is one of those mental model hurdles they have to get over.  The simplified syntax feature of V3 seems to generate a fair amount of controversy (is it really necessary, doesn’t this just complicate things more, etc).  Regardless of where you stand on the simplified syntax it is useful to understand how it works.

Given that it appears to be a simplified expression syntax you might think this required a change to the PowerShell parser’s grammar but you would be wrong.  It turns out that the simplified syntax is implemented by additional parameter sets – lots of additional parameter sets. In fact, for every operator supported, there is an additional parameter set to support that operator.  Let’s see this with the Where-Object cmdlet by listing out all of its parameter set names:

C:\PS> Get-Command Where-Object | Select -Expand ParameterSets | Format-Table Name

Name
----
EqualSet
ScriptBlockSet
CaseSensitiveGreaterThanSet
CaseSensitiveNotEqualSet
LessThanSet
CaseSensitiveEqualSet
NotEqualSet
GreaterThanSet
CaseSensitiveLessThanSet
GreaterOrEqualSet
CaseSensitiveGreaterOrEqualSet
LessOrEqualSet
CaseSensitiveLessOrEqualSet
LikeSet
CaseSensitiveLikeSet
NotLikeSet
CaseSensitiveNotLikeSet
MatchSet
CaseSensitiveMatchSet
NotMatchSet
CaseSensitiveNotMatchSet
ContainsSet
CaseSensitiveContainsSet
NotContainsSet
CaseSensitiveNotContainsSet
InSet
CaseSensitiveInSet
NotInSet
CaseSensitiveNotInSet
IsSet
IsNotSet

Most of these correspond to the operators you are already familiar with such as: –GT, –LT, –GE, –LE, –LIKE, –MATCH, –NOTMATCH, –CONTAINS, –NOTCONTAINS, etc.  Note however there are two new operators in PowerShell V3: –In and –NotIn which you can use like so:

C:\PS> 1 -In 1..10
True
C:\PS> 20 -NotIn 1..10
True

Let’s look at the interesting parameters on these operator specific parameter sets.  Let’s look at the EqualsSet parameter set:

C:\PS> Get-Command Where-Object | Select -Expand ParameterSets | Where Name -eq EqualSet | 
           Select -Expand Parameters | Where Position -ge 0 | 
           Format-Table Name,Position,IsMandatory -AutoSize
    
Name     Position IsMandatory
----     -------- -----------
Property        0        True
Value           1       False

As it turns out, these results are the same for all the operator oriented parameter sets.  At the very minimum, the Property parameter is required and is always the first positional parameter.  And as you would expect, if you don’t provide it, you get prompted for a value:

C:\PS> Get-Process | Where -eq

cmdlet Where-Object at command pipeline position 2
Supply values for the following parameters:
Property:

Now even though Value parameter is specified as not mandatory, in many cases if you don’t provide it you will get a terminating error e.g.:

C:\PS> Get-Process | Where Name -eq
Where-Object : The specified operator requires both the -Property and -Value parameters. Supply both parameters and
retry.
At line:1 char:15
+ Get-Process | Where Name -eq
+               ~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Where-Object], PSArgumentException
    + FullyQualifiedErrorId : ValueNotSpecifiedForWhereObject,Microsoft.PowerShell.Commands.WhereObjectCommand

There are some cases where you don’t have to provide the value nor the operator e.g.:

C:\PS> Get-Process | Where Responding

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    216      10     3560       2896    73            4000 atieclxx
    130       7     2380       1028    33            1020 atiesrxx
    157      11    17288      13344    49            7876 audiodg
     28       6     1256        420    42     0.06   2752 BluetoothHeadsetProxy
...

This works because A) the EqualsSet parameter set is the default parameter set and B) the Where-Object implementation appears to coerce the property specified (Responding in this case) to Boolean. If the result is $true then the object is output by Where-Object and sent on its way down the pipeline.

So all this simplified syntax really is, is a bunch of operator specific parameter sets on Where-Object that have a positional and mandatory Property parameter of type [string] and a positional Value parameter of type [object].  In the case of Foreach-Object it is one extra parameter set called PropertyAndMethodSet which has one mandatory, positional parameter called MemberName.  And as with any cmdlet, you provide the parameter values and the cmdlet determines how to interpret them.  In fact, given standard parameter parsing behavior the below is as valid as the conventional notation:

C:\PS> Get-Process | Where -GT PM 100MB
...
C:\PS> Get-Process | Where PM 100MB -GT
...
C:\PS> Get-Process | Where -Value 100MB -Property PM -GT
...

C:\PS> Get-Process | Where Threads.Count -GT 100

C:\PS> Get-Process | Where {$_.Threads.Count -GT 100}

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
   2080     126   155680     139928   531   113.68   4920 msnmsgr
   1087       0      312       8800    15               4 System

C:\PS> 1 | Foreach {Get-Variable _,psitem; $_ = 4; Get-Variable _,psitem}

Name                           Value
----                           -----
_                              1
PSItem                         1
_                              4
PSItem                         4