It would be very useful if Out-Gridview provided a build in display of the number of objects in the grid. This could be in a status bar at the bottom or at the top along with the Add Criteria button.

This would update as the filters are applied. It would also be nice if the selected items had a count as well.

It would be especially useful with -passthru as you could have an estimate on the number of objects being passed to the next cmdlet in the pipeline.

You can come up with the count by using measure-object, but that number only comes after committing to pass objects back through the pipeline.

I often pass things from the clipboard or csv files to cmdlets and it would be nice to know how many are going through at execution time.

Love PowerShell!

In 5.0, objects returned from a script will appear in the console only after the script has completely finished if no formatting data is defined for that object type.

Example:

Write-Warning "Before"

Get-Service E* | select Status, Name, DisplayName

Write-Warning "After"

Output:

WARNING: Before


WARNING: After

 Status Name        DisplayName                       

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

Stopped EapHost     Extensible Authentication Protocol

Running EFS         Encrypting File System (EFS)      

Running eventlog    Windows Event Log                 

Running EventSystem COM+ Event System               

Details
- This did not happen before PowerShell 5.0
- This happens both in the PowerShell console and ISE
- The issue affects all objects that have no formatting data, for example:

<anything> | Select-Object -Property …

[pscustomobject]@{one=1;two=2}

Get-Acl C:\

Get-Location

• Output that is sent to other streams is not affected (errors, Write-Host, Write-Warning, Write-Verbose etc.)


• The issue only occurs in table view (i.e. does not happen if the object has more than 4 properties)


• The issue also occurs if the script output is piped to a file, but not if it is piped to another command (e.g. Out-GridView).

This issue can create unexpected results for scripts that worked fine in previous PowerShell versions. Running this (contrived) script will highlight the issue:

$RandomProcess = Get-Process | Get-Random

Write-Host "Random process:"

$RandomProcess | select Name, ID

Read-Host "Press Enter to stop the listed process"

$RandomProcess | Stop-Process -WhatIf

What makes this potentially dangerous is that making subtle changes to the code (e.g. in the previous examples, removing the select command) could change the output significantly. At the very least it violates the "principle of least surprise".

This may be caused by the new default formatter waiting for all pipeline objects so it can display them in the new auto-sized column layout (essentially an implicit Format-Table -AutoSize). It would be better if the behavior reverted to the previous formatting style for “unknown” objects so it displays all output in the proper order.

Workarounds:

• If the objects do not really need to be sent to the pipeline, append “| Out-Host" or "| Out-String" to the command generating the objects.

Delegating access to Windows Server functions (e.g., create a DHCP reservation, modify a DNS record, provision a share, etc.) in a heterogeneous, modern, self-service environment is greatly hindered by available protocols. While RPC, CIM, psremoting/wsman/soap, et al. are technically open, they are far enough from modern mainstream app heterogeneous ease of use that they are practically Windows only.
Windows should provide a facility to easily expose Windows functions as simple REST-ish APIs accessible to any calling platform. JEA makes a great engine for executing delegated functions, so I would imagine using JEA or similar as the execution context, but with a REST-ish API in front of it to take requests and return results as JSON or whatnot.
This isn't a new idea (see https://blogs.msdn.microsoft.com/powershell/2014/09/29/simple-http-api-for-executing-powershell-scripts/ and https://technet.microsoft.com/en-us/library/hh880865(v=vs.85).aspx ), but currently it is difficult to implement. Windows should embrace this scenario and make it easier to configure and deploy with strong security assurances and clear guidance.

There seems to be a bug in Group-Object when using the -AsHashTable switch and where any custom expression that returns a string is used. The hashtable is created, can be enumerated, but trying to get an entry from it using the indexer doesn't work. This seems to be the case exclusively when the expression returns a string.

Consider the following:

PS C:\Windows> $Items = Get-ChildItem | Group-Object -Property Extension -AsHashTable

PS C:\Windows> $Items


Name                           Value

----                           -----

.DMP                           {MEMORY.DMP}

.bin                           {mib.bin}

.xml                           {Enterprise.xml, Starter.xml}

.NET                           {Microsoft.NET}

.INI                           {HPMProp.INI, init.ini, msdfmap.ini, SMSCFG.INI...}

.dat                           {bootstat.dat, ConnectionProfiles.dat}

.dll                           {ISMIF32.dll, twain.dll, twain_32.dll}

.exe                           {bfsvc.exe, DfsrAdmin.exe, explorer.exe, fveupdate.exe...}

.prx                           {WMSysPr9.prx}

                               {ADAM, addins, AppCompat, AppPatch...}

PS C:\Windows> $Items[".bin"]

    Directory: C:\Windows

Mode                LastWriteTime     Length Name

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

-a---        2009-07-14     01:06      43131 mib.bin

PS C:\Windows>

As you can see, this works as expected. Now, if we try this instead:

PS C:\Windows> $Items = Get-ChildItem | Group-Object -Property { $_.Extension } -AsHashTable

PS C:\Windows> $Items


Name                           Value

----                           -----

.DMP                           {MEMORY.DMP}

.exe                           {bfsvc.exe, DfsrAdmin.exe, explorer.exe, fveupdate.exe...}

.bin                           {mib.bin}

.dat                           {bootstat.dat, ConnectionProfiles.dat}

.INI                           {HPMProp.INI, init.ini, msdfmap.ini, SMSCFG.INI...}

.dll                           {ISMIF32.dll, twain.dll, twain_32.dll}

.xml                           {Enterprise.xml, Starter.xml}

.NET                           {Microsoft.NET}

                               {ADAM, addins, AppCompat, AppPatch...}

.prx                           {WMSysPr9.prx}

PS C:\Windows> $Items[".bin"]

PS C:\Windows>

All of a sudden, the indexer no longer returns a result. I've tried typecasting, using the exact same value as "extracted" from the Keys property, nothing works. I'm thinking the hash code of the entries are calculcated differently, seeing as the entries are returned in a different order than the first example. The expression in itself doesn't seem to matter as long as it returns a string. Using { $_.GetType().Name } produces an equal result.

Indexing the hash table using other objects, such as Int32 and RuntimeType, seems to work correctly: { $.GetType() } and { $.Name.Length }, for instance.

Consider a workflow which is given a list of servers. The workflow contains a ForEach -Parallel block, which invokes a nested workflow tor each server from the list (using -PSComputerName). In this scenario, activities from some of the nested workflow instances sometimes execute on different servers than they should.

Repro:
workflow Reproduce-ForEachParallelRemotingBugChild
{

Param ([string] $s)

Write-Verbose "(s=$s) PSComputerName $PSComputerName"

Write-Verbose "(s=$s) sleeping"

Start-Sleep -Seconds 1

Write-Verbose "(s=$s) getting item"

$x = Get-Item -Path C:\

Write-Verbose "(s=$s) $($x.Name) $($x.PSComputerName)"

Write-Verbose "(s=$s) PSComputerName $PSComputerName" # this is OK (PSComputerName does not get corrupted)

if ($x.PSComputerName -ne $s)

{

    Write-Error "BUG! This workflow was set to run on $s, but Get-Item statement ran on $($x.PSComputerName)!"

}

}

workflow Reproduce-ForEachParallelRemotingBug
{

Param ([string[]] $Server, [PSCredential] $Credential)

ForEach -Parallel ($s in $Server)

{

    Sequence

    {

        Write-Verbose "Processing $s"

        Reproduce-ForEachParallelRemotingBugChild -s $s -PSComputerName $s -PSUseSSL $true -PSCredential $Credential -Verbose $true

    }

}

}

Reproduce-ForEachParallelRemotingBug -Server @('server-alpha.mycompany.com', 'server-beta.mycompany.com') -Credential (Get-Credential X\admin) -Verbose

Output:
VERBOSE: [localhost]:Processing server-beta.mycompany.com
VERBOSE: [localhost]:Processing server-alpha.mycompany.com
VERBOSE: [server-alpha.mycompany.com]:(s=server-alpha.mycompany.com) PSComputerName server-alpha.mycompany.com
VERBOSE: [server-beta.mycompany.com]:(s=server-beta.mycompany.com) PSComputerName server-beta.mycompany.com
VERBOSE: [server-beta.mycompany.com]:(s=server-alpha.mycompany.com) sleeping
VERBOSE: [server-beta.mycompany.com]:(s=server-beta.mycompany.com) sleeping
VERBOSE: [server-beta.mycompany.com]:(s=server-alpha.mycompany.com) getting item
VERBOSE: [server-beta.mycompany.com]:(s=server-beta.mycompany.com) getting item
VERBOSE: [server-beta.mycompany.com]:(s=server-beta.mycompany.com) C:\ server-beta.mycompany.com
VERBOSE: [server-beta.mycompany.com]:(s=server-beta.mycompany.com) PSComputerName server-beta.mycompany.com
VERBOSE: [server-alpha.mycompany.com]:(s=server-alpha.mycompany.com) C:\ server-beta.mycompany.com
VERBOSE: [server-alpha.mycompany.com]:(s=server-alpha.mycompany.com) PSComputerName server-alpha.mycompany.com
Microsoft.PowerShell.Utility\Write-Error : BUG! This workflow was set to run on server-alpha.mycompany.com, but Get-Item statement ran on server-beta.mycompany.com!
At Reproduce-ForEachParallelRemotingBugChild:14 char:14
+

+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException

+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Microsoft.PowerShell.Commands.WriteErrorCommand

+ PSComputerName        : [server-alpha.mycompany.com]

The Verbose output shows that activities which should target server-alpha were actually executed on server-beta. (This happens very often, but not every time.)

Once -Parallel is removed, the workflows execute sequentially successfully on correct computers - however, one of the primary advantages of using workflows in the first place is lost.

Currently you can define what parameters are exposes and if needed, you can provide a validateset or validatepattern for the parameter. What I can't do is specify the parameter in question should be mandatory even though the cmdlet or function does not enforce its usage.
E.g.: I define the following in my psrc
VisibleCmdlets = @{

Name = 'Get-Process'

Parameters = @{

    Name = 'Name'

    ValidateSet = 'ZoomIt'

}

}

this does not restrict the user from just typing Get-Service and have every service returned.
Current workaround is to create a proxy function and expose that instead of the cmdlet.
I think overwriting the Mandatory attribute on parameters like these would be a common thing so I'm hoping the implementation can be expanded to also implement the Mandatory attribute without the need for my own proxy functions.

This used to work with Powershell 4.

Try following code (call 'Test-TranscriptWarningFromInvokeCommand') and inspect the transcription file - the warning and verbose output from the 'remote' machine (visible on the console) is not in there!
function Test-TranscriptWarningFromInvokeCommand {

Start-Transcript -LiteralPath:"C:\Users\Public\Documents\Transcript-$(Get-Date -Format:"yyyy'-'MM'-'dd HH'-'mm'-'ss").txt" -Force

Write-Host "Local: This is a write-host!"

Write-Warning "Local: This is a write-warning!"

Write-Verbose "Local: This is a write-verbose!" -Verbose

#Write-Error "Local: This is a write-error!"

try {

    Invoke-Command -ComputerName:$Env:ComputerName `

                   -ScriptBlock:{   Write-Host "Remote: This is a write-host!"

                                    Write-Warning "Remote: This is a write-warning!"

                                    Write-Verbose "Remote: This is a write-Verbose!" -Verbose

                                    #Write-Error "Remote: This is a write-error!"

                                }

} finally {

    Stop-Transcript

}

}
Test-TranscriptWarningFromInvokeCommand

To get blocks of text from a file, e.g. config sections from an opening tag to a closing line. All log lines for a reboot, starting with "System Booting at" and ending with "Boot Finished".

Example:

Select-String -Beginning '^FastEthernet' -Ending '^!'

Output: Multiple arrays of lines taken from a Cisco switch config, each array containing the lines for a FastEthernet interface configuration.

Example:

Select-String -Between '^User: .*'

Output: Arrays of lines from one "User: name" line to the next, to isolate blocks of settings for each user. Probably including the first match and excluding the second match, in the same way the range operator does: 1..5 includes the first number and excludes the second.

Reason for suggestion: People are bad at making nicely structured text output from things, and it's quite common to have needs like "I need X line and all the following lines until Y, but the number of lines can vary so I cannot use Select-String -Context".

The leading alternative is a multiline regex, which is effective but quite hard to use and read, hard to see the intended meaning.

It's entirely possible to do with a loop and a few lines of pattern matching and flag variable, but conceptually it's very close to Select-String -Context and I think would be a useful addition to Select-String's abilities.