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]C__Temp__1", "[File]C__Temp__1"};

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

The example command given under "INVESTIGATING PIPELINE ERRORS" in the about_Pipelines help topic is incorrrect. the example situation is moving a registry entry from one key to another, in the example it's trying to move the entry "product" from the hklm:\software\mycompany\design registry key to the hklm:\software\mycompany\sales key. The second ("fixed") command at the end:

get-item -path hklm:\software\mycompany\design |
move-itemproperty -dest hklm:\software\mycompany\design -name product

should be:

get-item -path hklm:\software\mycompany\design |
move-itemproperty -dest hklm:\software\mycompany\sales -name product

I also think the source and destination seem switched or misplaced throughout that section of the topic, unrelated to the example error given for the purpose of that section (tracing an error in pipeline binding).

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.

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.

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';
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'; is total nonsense. Enter it in a web-browser, and you'll see. (Even if you replace de-de with en-us.)