Dynamic parameters of a cmdlet that are added by a provider are documented in the <providerHelp>&lt;cmdletHelpPaths> element of the help XML file.

The FileSystem provider adds the following parameters to Add-Content:

PS C:&gt; (Get-Command Add-Content).ParameterSets.Parameters | Where IsDynamic | foreach Name | Sort -Unique
Encoding
NoNewline
Stream

However, the Encoding and Stream parameters are documented in the primary help file, Microsoft.PowerShell.Commands.Management.dll-help.xml, so they appear in Get-Help even in provider drives where the parameter is not valid.

PS Function:&gt; (Get-Help Add-Content -Path function:).Parameters.Parameter | where Name -notin $common | foreach Name | Sort -Unique
Credential
Encoding # <----
Exclude
Filter
Force
Include
LiteralPath
PassThru
Path
Stream # <---
UseTransaction
Value
PS Function:&gt; (Get-Command Add-Content).ParameterSets.Parameters | where Name -notin $common | foreach Name | Sort -Unique
Credential
Exclude
Filter
Force
Include
LiteralPath
PassThru
Path
UseTransaction
Value

To complicate matters, the <providerHelp>&lt;cmdletHelpPaths> section of the help file that stores the content for this feature, documents the following parameters:

PS C:\ps-test> $sma.helpItems.providerHelp.CmdletHelpPaths.CmdletHelpPath.command | Where {$.details.name.trim() -eq 'Add-Content'} | foreach {$
.Parameters.Parameter.Name}
Encoding
Force #<-- Not dynamic
Stream
Confirm #<-- SupportsShouldProcess; not dynamic
WhatIf #<-- SupportsShouldProcess; not dynamic
UseTransaction #<-- SupportsTransactions; not dynamic

And, it is missing the NoNewLine dynamic parameter.

PS C:&gt; (Get-Command Add-Content).ParameterSets.Parameters.Name -eq 'NoNewLine'
NoNewline
NoNewline

PS C:&gt; Get-Help Add-Content -Parameter NoNewLine
Get-Help : No parameter matches criteria NoNewLine.
At line:1 char:1
+ Get-Help Add-Content -Parameter NoNewLine
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (System.Manageme...CommandHelpInfo:ProviderCommandHelpInfo) [Get-Help], PSArgu

mentException

+ FullyQualifiedErrorId : NoParmsFound,Microsoft.PowerShell.Commands.GetHelpCommand

Add-Computer, Incorrect Help Info for parameters: InformationVariable, InformationAction

It looks to me like the help documentation for these parameters may be wrong.

-InformationAction [<System.Management.Automation.ActionPreference]>]

Type the NetBIOS name, an Internet Protocol (IP) address, or a fully qualified domain name of each of the  remote computers. To specify the local

computer, type the computer name, a dot (.), or "localhost".


This parameter does not rely on Windows PowerShell remoting. You can use the ComputerName parameter of Add-Computer even if your computer is not

configured to run remote commands.

This parameter is introduced in Windows PowerShell 3.0.

Required?                    false

Position?                    named

Default value                none

Accept pipeline input?       false

Accept wildcard characters?  false

-InformationVariable [<System.String]>]

Type the NetBIOS name, an Internet Protocol (IP) address, or a fully qualified domain name of each of the  remote computers. To specify the local

computer, type the computer name, a dot (.), or "localhost".


This parameter does not rely on Windows PowerShell remoting. You can use the ComputerName parameter of Add-Computer even if your computer is not

configured to run remote commands.

This parameter is introduced in Windows PowerShell 3.0.

Required?                    false

Position?                    named

Default value                none

Accept pipeline input?       false

Accept wildcard characters?  false

The FileSystem provider adds the following dynamic parameters to Get-ChildItem:

PS C:&gt; (Get-Command Get-ChildItem).ParameterSets.Parameters | where IsDynamic | foreach Name | Sort -Unique

Attributes

Directory
File
Hidden
ReadOnly
System

But, these are all failing in Get-Help in the file system drives.

PS C:&gt; $dynam | foreach { if (!(Get-Help Get-ChildItem -Parameter $ -ErrorAction SilentlyContinue)) { $ } }
Attributes
Directory
File
Hidden
ReadOnly
System

Unlike the related bugs I've filed, I can't find the error in the help file. These parameters are (correctly) not documented in the cmdlet help, and they are correctly documented in the provider help.

PS C:&gt; [xml]$sma = cat $pshome\en-us\System.Management.Automation.dll-help.xml
PS C:&gt; $sma.helpItems.providerhelp | where { $.Name.trim() -eq 'FileSystem' } |
>> foreach { $.CmdletHelpPaths.CmdletHelpPath.command } |
>> where { $.details.name.Trim() -eq 'Get-ChildItem' } |
>> foreach { $.parameters.parameter.name }
>>
Attributes
Directory
File
Hidden
ReadOnly
System

This might be an actual code error in Get-Help, but it's more likely to be an error in the help XML file that I just haven't detected.
Force
UseTransaction

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

I know that there are many cmdlets help documentation not completed yet. But, it's a pain when trying to use the "Update-help" cmdlet and see it error-out due to an unfinished module help.

I think it should be a good idea to display the error and continue (or try) update the rest of our installed module(s).

In my case, I'm getting an error update the help on the new SQLServer module. But this is now completing the update for the rest of my existing module.

If this update is done alphabetically then the update is stopping at the SQLServer module and the rest could be ignored.

So, Get-Help cmdlet beside displaying error (and stopping), should continue updating the rest of the help doc.

Or, instead of an error, make it a warning to continue update.

sample error displayed:
PS C:\WINDOWS\system32> Update-Help -Force;
Update-Help : Failed to update Help for the module(s) 'Microsoft.PowerShell.Operation.Validation' with UI culture(s)
{en-US} : Unable to retrieve the HelpInfo XML file for UI culture en-US. Make sure the HelpInfoUri property in the
module manifest is valid or check your network connection and then try the command again.
At line:1 char:1
+ Update-Help -Force;
+ ~~~~~~~~~~~~~~~~~~

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

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

Update-Help : Failed to update Help for the module(s) 'SqlServer' 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://technet.microsoft.com/library/cc732148.aspx&#39; does not resolve to a container.
At line:1 char:1
+ Update-Help -Force;
+ ~~~~~~~~~~~~~~~~~~

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

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

Thanks,
Maximo Trinidad

Description of the parameter claims, wildcards are accepted, but the "Accept wildcard character?" value is false. Running
get-netfirewallrule -description *
results in the retrieval of a portion of the firewall rules retrieved without the parameter (535/556 when I ran it). I suggest editing the help file, as well as checking why the parameter discludes a portion of the firewall rules.
-Description <String[]>

    Specifies that matching firewall rules of the indicated description are retrieved. Wildcard characters are

    accepted.


    This parameter provides information about the firewall rule. This parameter specifies the localized,

    user-facing description of the IPsec rule.

    Required?                    false

    Position?                    named

    Default value

    Accept pipeline input?       false

    Accept wildcard characters?  false

Short Version: Please put up a diagram showing exactly which profiles get called by which hosts in which order !

I have recently starting using ISE - having previously just used the Console. Now I am using both. So they apparently have two different profiles. So I tried to copy my existing one - but then (because I use aliases) I get a 'double-loading' effect. Also I'm on powershell 4.0, but my $pshome still have v1.0 in the path ? Additionally: when I tried editing a profile.ps1 from a Windows explorer - it was showing as an empty file in my (gvim) editor ??? (That might be something else entirely?)