By default tab completion is disabled in JEA endpoints- and there is no guidance on how (or if) it can be enabled safely.
Without tab completion it is
1. Harder to discover available commands (no Get-<tab>)
2. Harder to execute available commands with correct parameter name spelling etc.
3. Harder to populate correct values (e.g., no help with ValidateSet scenarios)
This all works against the applicability of JEA for delegation scenarios where a less expert sub-admin has to blindly type out a potentially complex and unfamiliar command.
Please make some basic level of tab completion work by default, and please provide guidance around tab completion and endpoint safety so we don't accidentally undermine the security boundary while adding or modifying tab completion in the field.

Votes from Connect: 17

Original Date Submitted: 6/21/2013 12:41:41 AM

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

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

Problem Description:
It would be nice in PS ISE if when you have multiple files open, that you could drag the tabs at the top of the Script Pane window (i.e. the file names) to rearrange them. Right now if you want to rearrange the order of the tabs, you have to actually close the tabs and re-open them in the order that you want them.

This is a standard feature in most tabbed editors.

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

Repro Steps:
Open multiple files in the PS ISE Script Pane. Use the mouse to try and drag one tab to the left/right of another tab; nothing happens.

Expected Results:
Open multiple files in the PS ISE Script Pane. Use the mouse to try and drag one tab to the left/right of another tab; the tab should move to where it is being dragged.

Internal BugId: 4262

When using a foreach loop to create a set of resources and trying to set the previous item key as the dependsOn resource, it adds it twice in the mof file.

Configuration example:
configuration Test-DependsOnWithLoop {

param([string[]]$Directories)

Import-DscResource -ModuleName PSDesiredStateConfiguration

node localhost {

    $dependsOn = $null

    $dirs.ForEach({

        $res = $_ -replace '\\|:', '_'

        File $res {

            Ensure = 'Present'

            DestinationPath = $_

            DependsOn = $dependsOn

            Type = 'Directory'

        }

        $dependsOn = "[File]$res"

    })

}

}

$dirs = 1..10 | % { "C:\Temp_$_" }
Test-DependsOnWithLoop -Directories $dirs

And if you look at the localhost.mof you'll see:
DependsOn = { "[File]CTemp1", "[File]CTemp1"};

I traced it back to the Test-DependsOn function in CimDSCParser.cs, though in this case, it's not a composite resource

Once a node meta configuration is enacted, it is easy for an administrator or process (with malicious intent) to modify the MetaConfig.mof file in C:\Windows\System32\Configuration directory. The GetMetaConfiguration method in MSFT_DscMetaConfiguration class does not validate the property values against the allowed values of the CIM properties.

Steps to reproduce this behavior:
- Enact a simple meta configuration and enact it.
- Open the MetaConfig.MOF file in your favorite editor and change the value of ConfigurationMode to some random text.
- Save the file and close it.
- Run Get-DscLocalConfigurationManager.
- You will see the random value assigned to ConfigurationMode in the output although it is not a valid value for the ConfigurationMode property.

You can see this in action at https://pbs.twimg.com/media/DFervKvUIAA-7Na.jpg:large

This comment pertains to the help entry for Get-Content (https://msdn.microsoft.com/en-us/powershell/reference/5.0/microsoft.powershell.management/get-content) I Tried to enter the feedback into the actual page but my browser reloaded the page and lost the floating feedback link. Perhaps it was already submitted.

The description attached to the parameters
-Delimiter
-Encoding
-Raw
-Stream
-Wait
(This parameter is not supported by any providers that are installed with Windows Powershell.)
is both incorrect and useless.

It is incorrect because the parameters are supported by the FileSystem provider (at least).

It is useless because it gives no information about the reason for the existence of the parameter. Is it a deleted function for which the parameter name is retained for legacy scripts? Is it a planned future addition?

My suspicion is that it is a place holder description that was never updated. (As an aside, there are/were many help entries where the description for some parameters had been replaced by that for -UseCredential)

Additionally, where it is decided that a cmdlet should have multiple help entries if a it has different behaviour depending upon which provider is invoked then the general (non-provider specific) version should clearly indicate that fact (with appropriate links). So '-Delimiter' would be described thus:

-Delimiter
(FileSystem provider, ...)
Provider specific behaviour.

where 'FileSystem provider' is a link to 'Get-Content for FileSystem'. Indeed, if the behaviour is the same for all applicable providers then the behaviour could be described in the general help entry (instead of just 'Provider specific behaviour.').

I am experiencing an issue with Windows 10 and the PSReadline module. Apparently when the PSReadline module is in memory, the default behavior for tab completion is to append a trailing backslash to the relative path. This is not too much of a problem with the file provider and the registry providers but it appears to wreak havoc on the Active Directory PS Provider.

This may be reproduced by navigating to the AD: drive and they trying to use tab completion for the Set-Location or Get-ChildItem cmdlets. You will receive the error Cannot find path because it does not exist.

The two workarounds are to use the backspace key to manually remove the trailing backslash or run Remove-Module PSReadline.

Documentation Bug: Wrong Language + Wrong Country + Wrong HelpInfoUri

"Update-Help -Verbose -Force" gives:

Update-Help : Failed to update Help for the module(s)
'Microsoft.PowerShell.Operation.Validation' with UI culture(s) {en-US} : The value of the
HelpInfoUri key in the module manifest must resolve to a container or root URL on a website
where the help files are stored. The HelpInfoUri 'https://www.msn.com/de-de/?ocid=NEFLS000&#39;
does not resolve to a container.
At line:1 char:1
+ Update-Help -Verbose -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidOperation: (:) [Update-Help], Exception

+ FullyQualifiedErrorId : InvalidHelpInfoUri,Microsoft.PowerShell.Commands.UpdateHelpCommand

============================================

But this is the current configuration:

PS C:\WINDOWS\system32> $PSCulture
en-US
PS C:\WINDOWS\system32> $PSUICulture
en-US

The HelpInfoUri 'https://www.msn.com/de-de/?ocid=NEFLS000&#39; is total nonsense. Enter it in a web-browser, and you'll see. (Even if you replace de-de with en-us.)