Votes from Connect: 3

Original Date Submitted: 6/8/2015 2:40:45 PM

Description:
Contact Information
Handle: aL3891
Site Name: PowerShell
Feedback ID: 1411231

Problem Description:
At the moment all dsc resources are executed serially. given that dependencies are allready specified, it would in theory be safe to execute steps in parallel.

I'm guessing this is planned at some point but i could really use a way to enable parallel execution because I'm using dsc to spin up test environments with a bunch of services and having those being set up in parallel would speed things up considerably.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1411231 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1411231).

Repro Steps:

Internal BugId: 14550

In a recent change, the new database for the on-prem Pullserver is now ESENT. Had a question for clarification.

As an old Exchange guy, I have fears that immediately pop into mind. The logs files do not appear to be using circular logging (a way of self cleaning and restricting the amount of log files) – Is this true?

If so, then I’m guess that the log files will continue to grow until the disk is full – which happens to exchange if the log files are not truncated. Is there a way today or in the future we will be able to manage the log files?

Thanks for the help understanding!

Votes from Connect: 11

Original Date Submitted: 2/6/2013 3:35:55 AM

Description:

Contact Information
Handle: DougBB
Site Name: PowerShell
Feedback ID: 778597

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
Under certain circumstances, when Write-Progress is used in Windows PowerShell ISE and a new tab is opened, the Write-Progress output does not display properly. Closing tabs makes it appear.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 778597 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=778597).

Repro Steps:
1. Run "powershell_ise.exe -noprofile"
2. Paste the following code in the script pane:

$i = 1..100

$i | % {

    write-progress -Activity "Testing Output" -Status $_ -PercentComplete $_

    sleep 1

}

1. Note the progress bar works properly


2. Open a new tab by pressing Ctrl+T


3. Switch back to the first tab


4. Note the progress bar continues to works properly


5. Close the second tab


6. Open a new tab by pressing Ctrl+T


7. Switch back to the first tab and note the progress bar is missing


8. Close the third tab


9. Note that the progress bar displays properly again

Expected Results:
The progress bar from Write-Progress is displayed regardless of the state of the tabs in the ISE.

Internal BugId: 4106

Votes from Connect: 42

Original Date Submitted: 4/10/2015 11:19:28 PM

Description:
Contact Information
Handle: Trevor Sullivan [MVP]
Site Name: PowerShell
Feedback ID: 1238786

Problem Description:
The Out-GridView command displays all of the properties of each object that is fed into it. Consequently, in order to make the tool more usable, the Select-Object command can be used to inclusively filter the key properties of each object, to display to the end user. Unfortunately, this process results in a modified object, that cannot be used for all intended purposes.

Instead of using Select-Object, a -DisplayProperty parameter should be added to Out-GridView, so that unmodified objects can be piped into it, while only the specified properties are displayed. The pipeline output from Out-GridView should emit the unmodified objects.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1238786 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1238786).

Repro Steps:

Internal BugId: 14376

Managing registry keys and values on local and remote systems with PowerShell is a pain.

Reviewing the articles, forums and blogs on the Internet clearly shows that new PowerShell users struggle to understand how to use registry provider drives and the cmdlets like New-Item, Get-ItemProperty, New-ItemProperty, and so on. This has prompted the creation of a variety of home-brew modules and functions to deal with the problem, like this one, which is extremely useful, but is not built into PowerShell by default of course:

https://gallery.technet.microsoft.com/RegistryLibrarypsm1-b38a81ba

PowerShell needs a proper set of built-in, dedicated registry cmdlets that 1) are easy to understand and use, even by PoSh newbies, 2) work on both local and remote registries, 3) can handle default values in keys, 4) can create the entire subkey path to a target value in one shot, 5) can create and set a value in one shot, 6) can handle all registry value types, including REG_BINARY, 7) export and import entire branches, 8) query and edit registry key permissions, and 9) which handle problems somewhat gracefully in a way that does not always require coders to write a bunch of tests or Try{}Catch{} constructs.

In general, just as we need a PowerShell version of ROBOCOPY.EXE, we need a PowerShell replacement for everything REG.EXE can do (and more).

For remote registry access, it would be nice to have support for both WSMAN and RPC, but RPC at a minimum (for those who don't configure WinRM/WSMAN on client devices). These registry cmdlets also need a -Credential parameter for connecting to stand-alone boxes in a workgroup that only have local accounts.

It's not enough to just have a nice registry module in the PSGallery, it needs to be built in so that we can rely on it everywhere; for example, these new registry cmdlets should ideally work on Linux or Mac OS machines using PowerShell to access the registry on remote Windows boxes.

REG.EXE is not good enough either: it's not object-oriented, does not support tab completion, does not support -WhatIf or -Verbose or -Recurse, etc. Same for ROBOCOPY.EXE.

And having just a DSC resource module is not good enough either. DSC is too complex or heavyweight for many organizations or scenarios.

Adding new registry cmdlets would not break any existing scripts that modify the local registry. And depending on how the network registry access is implemented, might not require a particular minimum version of WMF/PowerShell at the remote system either (though it may require WinRM to be configured).

Just as others have proposed or written functions for already, the names of the cmdlets might be like:

Get-RegistryValue
Set-RegistryValue
New-RegistryKey
Remove-RegistryValue
Remove-RegistryKey
Export-RegistryKey
Import-RegistryKey
And so on...

As others have already done, the cmdlets might just be wrappers for existing cmdlets, providers, classes or modules, which would be just fine, but they need to be built-in by default in the next version of WMF/PowerShell.

The above suggestion is not new and definitely not my idea, but I was hoping a new post in UserVoice would help to spark discussion about what is (not) needed and attract enough votes to get the ball rolling before the next version of WMF/PowerShell gets feature-locked.

Thanks,
Jason

I am unable to authenticate with a client certificate generated from OpenSSL or New-SelfSignedCertificate from a Windows 10 or 2012R2 powershell remoting client (likely broken in 8.1 but I did not test). I receive the following error:

new-PSSession : The WinRM client cannot process the request. If you are using a machine certificate, it must contain a DNS name in the Subject Alternative Name extension or in the Subject Name field, and no UPN name. If you are using a user certificate, the Subject Alternative Name extension must contain a UPN name and must not contain a DNS name. Change the certificate structure and try the request again.

The UPN is correctly specified in the SAN and there is no DNS entry.

I CAN authenticate with the same certificates from windows 7 or 2008R2 and I can also authenticate from windows 10/2012R2 if I use the ruby or python winrm libraries.

I checked the binary contents of both an ADCS gernerated cert and an OpenSSL one and my SAN contents are binary identical.

Please see http://www.hurryupandwait.io/blog/certificate-password-less-based-authentication-in-winrm for more details

NuGet feeds allow security around both listing/retrieving packages as well as pushing packages. NuGet.exe and other clients further allow you to persist credentials for listing/retrieving packages using the "nuget sources" command. (https://docs.nuget.org/consume/command-line-reference#sources-command)

This persistence is important for two reasons:

1) When you push a package to a secured NuGet feed, NuGet clients generally do a list/read operation first. That list/read operation doesn't contain any API key that you pass along in the push operation. In order for a push to succeed with an API key, you also need to have credentials set for the read operation. You can read about some folks who have been affected by that here: http://inedo.com/support/questions/2319

2) In an unattended/build server scenario, you need the ability to provide credentials for list/read and push in a non-interactive way. If the only way to provide credentials is interactive (e.g., Get-Credential) then there's no way to, say, enable a build server agent to automatically install required scripts to execute a build.

This may somewhat overlap with this other note about Register-PSRepository failing against authenticated endpoints: http://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11678499-register-psrepository-fails-against-authenticated

Votes from Connect: 12

Original Date Submitted: 4/4/2015 8:50:49 AM

Description:
Contact Information
Handle: Arnoud Jansveld
Site Name: PowerShell
Feedback ID: 1224213

Frequency: PowerShell ISE
Regression: function Show-Form
{

[reflection.assembly]::LoadWithPartialName("System.Windows.Forms") >$null

$form = New-Object System.Windows.Forms.Form

$label = New-Object System.Windows.Forms.Label

$label.Text = "Please close this form"

$label.AutoSize = $true

$form.Controls.Add($label)

$form.ShowDialog()

}

$result = Show-Form

Workaround (slow):

$result = Start-Job ${function:Show-Form} | Receive-Job -Wait -AutoRemoveJob

"Form result: " + $result.ToString()

Write-Warning "The following step may hang PowerShell ISE, save your work!"
Read-Host -Prompt "Hit Enter or Ctrl-C to abort"

This generates a WM_SETTINGCHANGE broadcast message

Problem Description:
After using ShowDialog() to display a Windows Forms dialog, the ISE will hang when it receives a WM_SETTINGCHANGE broadcast message (e.g. when changing display resolution, switching from a laptop screen to an external monitor or connecting to the current session from another machine via RDP).

This was reproduced on PowerShell ISE version 4 and 5 (Feb preview). Sadly it affects many useful scripts, including Lee Holmes' (awesome) Show-Object.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1224213 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1224213).

Repro Steps:
function Show-Form
{

[reflection.assembly]::LoadWithPartialName("System.Windows.Forms") >$null

$form = New-Object System.Windows.Forms.Form

$label = New-Object System.Windows.Forms.Label

$label.Text = "Please close this form"

$label.AutoSize = $true

$form.Controls.Add($label)

$form.ShowDialog()

}

$result = Show-Form

Workaround (slow):

$result = Start-Job ${function:Show-Form} | Receive-Job -Wait -AutoRemoveJob

"Form result: " + $result.ToString()

Write-Warning "The following step may hang PowerShell ISE, save your work!"
Read-Host -Prompt "Hit Enter or Ctrl-C to abort"

This generates a WM_SETTINGCHANGE broadcast message

Expected Results:
The script should show an empty dialog; after closing it and hitting Enter at the prompt the ISE should remain responsive (on some occasions the script has to be run more than once for the problem to occur).

This works fine in the regular PowerShell console.

Internal BugId: 14363

Votes from Connect: 3

Original Date Submitted: 10/30/2014 5:41:25 PM

Description:
Contact Information
Handle: ulrichb
Site Name: PowerShell
Feedback ID: 1015225

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
New-ScheduledTaskTrigger offers just a subset of the trigger options. Things like "On an (event log) event", or "On workstation (un)lock" are missing.

We just found ugly workarounds to add these (e.g. event log) triggers by using "schtasks.exe /create /xml" or using the COM "TaskScheduler" class.

New-ScheduledTaskTrigger should allow specifying all options the Task Scheduler UI offers. As there already exists an XML representation of these triggers (e.g. <EventTrigger>, <SessionStateChangeTrigger>, ...) it would also be possible to offer a "-Custom" parameter which takes such an XML fragment to specify a trigger.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1015225 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1015225).

Repro Steps:
Expected Results:

Internal BugId: 13076

Votes from Connect: 33

Original Date Submitted: 6/20/2013 11:48:19 PM

Description:
Contact Information
Handle: deadlydog
Site Name: PowerShell
Feedback ID: 790578

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
It would be great if PS ISE had the ability to allow you to save and restore all of your open tabs and files. Ideally, there would be an option to automatically save the session when ISE is closed, and automatically load it when ISE is started.

The PowerShell Team has blogged about how to save/load your session by writing an add-on (http://blogs.msdn.com/b/powershell/archive/2010/06/05/export-and-import-powershell-ise-opened-files.aspx), and I have blogged about how to automatically load the session when ISE starts using their solution (http://blog.danskingdom.com/powershell-ise-multiline-comment-and-uncomment-done-right-and-other-ise-gui-must-haves/), but it would be great if this functionality was provided out of the box.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 790578 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=790578).

Repro Steps:
Open some files in PS ISE and then close ISE. When you open ISE again the tabs and files that you had open will not be automatically opened. You will need to go open each file again.

Expected Results:
When opening ISE any tabs and files that you had open previously should be restored.

Internal BugId: 4258

Invoke-RestMethod and Invoke-WebRequest Encoding bug

This is 4 years old bug,from Invoke-RestMethod and Invoke-WebRequest was born.

【Cause of the bug】
Utf8 web page incorrectly identified as iso8859-1.
Mistakenly convert THE! utf8("false ISO-8859-1") source string to utf8.
There may be more encoding incorrectly identified,encoding incorrectly conversion errors.

【bug with powershell version】
all version
powershell 5.0 with windows10 10586 ：yes tested.

【test code】
Invoke-WebRequest -Uri 'http://www.msn.com&#39; # return chinese messy code
(Invoke-WebRequest -Uri 'http://www.msn.com').BaseResponse.CharacterSet # utf8 web page,but return ISO-8859-1

Invoke-RestMethod -Uri 'http://www.msn.com&#39;

【how to fix】
convert string encoding.
from utf8 to THE! "false ISO-8859-1"

$utf8 = [System.Text.Encoding]::GetEncoding(65001)
$iso88591 = [System.Text.Encoding]::GetEncoding(28591) #ISO 8859-1 ,Latin-1

$wrongstring = Invoke-RestMethod -Uri 'http://www.msn.com&#39;
$wrongbytes = $utf8.GetBytes($wrong_string)

$rightbytes = [System.Text.Encoding]::Convert($utf8,$iso88591,$wrongbytes) #Look carefully
$rightstring = $utf8.GetString($rightbytes) #Look carefully
write-host $right_string

【reporter】
I've been searching this bugs history list, I was the first reporter.
By the chinese powershell study & research group. QQ group No. is 183173532

【date】
2016-05-01

Votes from Connect: 13

Original Date Submitted: 11/1/2012 3:56:26 AM

Description:
Contact Information
Handle: J Stangroome
Site Name: PowerShell
Feedback ID: 769359

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
In the PSv3 documentation, $PSScriptRoot is now an automatic variable that is populated for both modules and ps1 scripts. It works from PowerShell.exe but not from the ISE

Product Studio item created by Connect Synchronizer due to creation of feedback ID 769359 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=769359).

Repro Steps:
1. Create a new script (eg c:\test.ps1) with the contents: gv PSScriptRoot
2. From PowerShell.exe, execute the script and see PSScriptRoot has a value.
3. From the ISE Console pane, execute the script and see PSScriptRoot had a value.
4. Open the script file in the ISE Script Pane and press F5 to run the script and see PSScriptRoot is blank.

Expected Results:
The $PSScriptRoot automatic variable should have a value when run via F5 in the ISE.

Internal BugId: 3931