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.

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…

1. We will validate the MOF when it is passed in as part of our API (i.e. Set-DscLocalConfigurationManager) and error if the values are not valid.
2. We will write a warning when Get-DscLocalConfigurationManager reads a MOF that has invalid values and at LCM startup. The resultant behavior will behave like it does today where invalid values will be read as the default value by the LCM.

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.').

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.…

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.

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.

I propose that it might be worth it to simply special case PSReadline to not append a trailing backslash while in the AD provider, but I think you should probably also file something on the AD team’s UserVoice to support trailing backslashes (though this work might be more difficult): https://windowsserver.uservoice.com/forums/304621-active-directory

After much discussion with Aaron Nelson and Chrissy LeMaire, and thanks to the enormous amount of support for this item, we’ve recognized that this is something we need to accomplish, one way or another.

We don’t want to offer an ETA on this as the work is not well understood by our team yet, and no one currently has immediate bandwidth on starting that investigation. But I want to stress the fact that is an important ask that we’re taking seriously as a priority.

In the meantime, it would be immensely useful if someone with expertise in the DataTable space could submit an RFC (basically a brief spec) to our PowerShell-RFC repository on GitHub. That way, we can have a discussion about what the design of a ConvertTo-DataTable cmdlet might look like before we dive in on an implementation. The process for doing so is located here: https://github.com/PowerShell/PowerShell-RFC/blob/master/RFC0000-RFC-Process.md#draft

I should also note that, given our desire to shrink the size of the PowerShell runtime over time, we believe that the development of this cmdlet/module should start on the PowerShell Gallery. However, this does not preclude us adding it to PowerShell 6.x as its quality improves and as others validate its usefulness.

Thanks everyone!
-Joey

After much discussion with Aaron Nelson and Chrissy LeMaire, and thanks to the enormous amount of support for this item, we’ve recognized that this is something we need to accomplish, one way or another.

We don’t want to offer an ETA on this as the work is not well understood by our team yet, and no one currently has immediate bandwidth on starting that investigation. But I want to stress the fact that is an important ask that we’re taking seriously as a priority.

In the meantime, it would be immensely useful if someone with expertise in the DataTable space could submit an RFC (basically a brief spec) to our PowerShell-RFC repository on GitHub. That way, we can have a discussion about what the design of a ConvertTo-DataTable cmdlet might look like before we dive in on an implementation. The process for doing so is located here: https://github.com/PowerShell/PowerShell-RFC/blob/master/RFC0000-RFC-Process.md#draft

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.

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…

"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
============================================

"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
============================================

Currently, when installing WMF5 on Windows 7, there is a pre-req of installing WMF4 first.

Please ensure that all supported operating systems can install the latest version of Windows Management Framework without having to do incremental upgrades. This will significantly reduce the complexity of deployment in production environments and during operating system deployment.

When a #Requires -Module version requirement (ModuleVersion, MaximumVersion, RequiredVersion) is not satisfied, the error message says that the module isn't found, not that the *version* of the module isn't found.

This is potentially very confusing.

& : The script 'Module.Help.Tests.ps1' cannot be run because the following modules that are specified by the "#requires" statements of the script are missing: Pester.
At C:\ps-test\Test-PesterScriptParameter.ps1:18 char:3
+ & $TestPath -ModuleName PSScriptAnalyzer
+ ~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (Module.Help.Tests.ps1:String) [], ScriptRequiresException
+ FullyQualifiedErrorId : ScriptRequiresMissingModules

Drag and drop to upload a zip file with all the powershell scripts (Eg. *.ps1, *.psd1 and *.psm1 files) just like OneDrive uploading of files.

It will be great if it is possible to drag and drop all the powershell scripts (Eg. *.ps1, *.psd1 and *.psm1 files) without compressing it to a zip file. The upload will automatically detect multiple PowerShell scripts uploaded and either smart enough to know all the uploaded multiple files are considered as one functional module or zip it up at the server end for processing it as it is functioning now.

Right now, the UX for enabling / disabling the listing status for PowerShell modules and scripts is a bit challenging, if you have many versions. Could we improve upon this somehow, to enable batch enable / disable of module / script versions?

I reproduced this error on PowerShell 5.1 and 4.0 on multiple systems. The behavior I expected was to receive the most recent event from any of the event logs. I feel this error could be prevented by using proper parameter validation.