The PowerShell gallery should allow users to create "lists" of modules (think of it as an Amazon wish list).

A user could create a "favorites" list and add modules and scripts to it to keep track of their favorites over time (maybe even "subscribe" to notifications of new releases of things on the list).

A user could also create a "user management modules" list or a "stretching PowerShell's limits" list or a "should have been in the box" list, or a "things I use in my prompt" list ...

But most importantly, users should be able to SHARE those lists, and other users should be able to download and install a list (maybe something like Install-Module -ListName MyPrompt -Author Jaykul).

Additionally, if you could show a count of how many users have added the module to at least one list, and a count of how many lists it's on, these would potentially be useful non-download metrics for popularity.

It would be awesome if there was a way to get additional sorting metrics for the gallery (downloads in the last week, vs. all-time, perhaps), and this would give you several possible additional metrics (users, lists, and the "all time" vs "last month" or "last week" to get hotness).

We started to use results from Get-DscConfigurationStatus in our monitoring (SCOM) and while analyzing the results we noticed that some partials are not showing up in the results of this command even though tests/set/get is performed on the target node. After analyzing different methods we found out that:

* MOF documents generated in C:\Windows\System32\Configuration\ConfigurationStatus seem to limit the results to ~40 last items in DSC configuration
* Get-DscConfigurationStatus and Test-DscConfiguration -Detail all use the same source of information, thus provide same, truncated output
* The only reliable source of information is details.json file generate when -Verbose output is requested, but information there is limited to only part of the info provided by MOF files and works only for interactive runs (when providing Verbose parameter is possible).

It looks to me like some sort of rolling-logs mechanism is used, but instead of keeping multiple files per run, final file is overwritten and thus only recent actions are recorded.

When defining a function, I would like to use an environment variable as the default value. If the environment variable exists and has a value that value will be used. For example,

function Get-Info ([Alias("name")] [Parameter(Mandatory=$true, ValueFromPipelineByPropertyName=$true)] [string] $projectName = $env:Project_Name)
{
}

Instead of having to passing in the Project Name for each call I would like to store it in an environment variable. When I do it would allow me to call Get-Info with no parameters and the value in the environment variable would be used. If the environment variable does not exist or is empty the user would be prompted for a value if it was not provided on the command line.
I tried writing the code as I have above but it never seemed to work. Even when the environment variable was set I was always prompted for projectName.
I know I could remove the mandatory attribute and add code in my function to set to the environment variable if it exists. But it would be much easier if what I am proposing was possible.

When using Format-Hex ( PowerShell version 5.0.10586.672 as returned by $PSVersionTable.PSVersion ), at least with the "-path" parameter, the final line of output -- if more than 1 line of output -- will duplicate the previous line's characters, starting with the first position after the final character of the file.

Meaning, if there are two rows of output ( each row displaying 16 characters ) and the file naturally ends at the third character position (i.e. "02") in the second (and final) row, then character positions 4 - 16 (i.e. "03" - "0F") will duplicate character positions 4 - 16 of the previous line (i.e. line #1 in this example).

You can see this easily by testing with two files, first one being just under one full line / 16 characters and the second one being just over one full line.

File 1 contents:
This is a test.

PS> Format-Hex -path .\Format-Hex-Bug-Test-1.txt

Returns:
00000000 54 68 69 73 20 69 73 20 61 20 74 65 73 74 2E 00 This is a test..

File 2 contents:
This is a longer test.

PS> Format-Hex -path .\Format-Hex-Bug-Test-2.txt

Returns:

00000000 54 68 69 73 20 69 73 20 61 20 6C 6F 6E 67 65 72 This is a longer
00000010 20 74 65 73 74 2E 73 20 61 20 6C 6F 6E 67 65 72 test.s a longer

Let me explain. I have a script that is collecting data, and I send it to StdOut by simply piping it into Select (but problem also happens if I add a ForEach loop and simply make [PSCustomObject] objects). Then my script loops to the next server. That output is not displaying on the screen. All is not lost though, when the script loops to the second server and displays both the first and second will now display. When the third server finishes it displays OK, as does the 4th.

So it looks like it's just the first one. Normally I would be OK with this, except that if the name of the second server is inputted wrong, my script will abort and the data from the first server disappears forever.

Has anyone else noted this behavior? I don't remember this happening before 5.1 and I have had multiple people able to reproduce this issue.

Good evening

Since years(!), it's well known that if we map SMB Shares using the New-SmbMapping command,
then the Windows Explorer does not recognize the new Drives: we have to kill and restart explorer.exe.
Well, we can be happy that we do not have to reboot...

We can not believe that this bug was never fixed and that we have to raise our user voice to solicitation so that such annoying bugs get finally fixed.

Of course, we could use the New-PSDrive command.
Unfortunately, this command is even worse: it does not validate if the credentials are valid nor if the SMB UNC Path is valid. This will lead to 'mapped' Drive letters which are not accessible at all. Therefore, Users have to deconnect the invalid drive - and to reconnect it again. Manually.
You probably remember: 20 years ago, Windows detected such problems during the onconnect event and asked the user for the missing / wrong information. Automatically.

Of course, we could use "net use". Of course, we could us batch files, too.
But for sure, it would be much more useful if powershell commands just works as expected.
The 1st time right.

I'm pretty sure it's not presumptuous if Microsoft starts spending some of the billions profit to write again software which accomplish the basics as expected.

Maybe you could start anf fixing this uservoice-form so that this textbox will display more than 4x100 characters. You know: some useful thing.

Kind regards,
Thomas

When importing this module in a restricted session type or when making a function or a cmdlet from this module visible, i.e:
VisibleFunctions = 'Get-FileHash'
the following message is returned:
WARNING: The 'Microsoft.PowerShell.Utility' module was not imported because the 'Microsoft.PowerShell.Utility' snap-in was already imported.
In practice, the module is not being imported.
Get-PSSnapin shows that a snapin with the same name is indeed loaded:
Name : Microsoft.PowerShell.Utility
PSVersion : 5.1.14409.1005
Description : This Windows PowerShell snap-in contains utility
cmdlets that are used to view and organize data in different ways.
but exposes no commands
Get-PSSnapin from a regular (not remote) session does not show this snapin.

With default session type everything is working as expected.