PowerShell: update-help fails for 'ConfigDefenderPerformance, PSReadline' -UICulture en-US.

@theJasonHelmick Some sort of block list would provide relief from the symptoms

However the right fix is that any module which ships as part of Windows, but not from the PowerShell team gets its house in order and not ship with a broken link. Having one part of Microsoft shipping things to hide other parts’ bugs is masking the problem not fixing it. If we use ConfigDefenderPerformance as an example: it has a link, http://go.microsoft.com/fwlink/?linkid=390762 which gives a 404 error. Either whoever owns that link needs to figure out why it isn’t going to the right place and fixes it OR the owners ConfigDefenderPerformance need to add something to the next cumulative windows update to move from 1.0 to 1.0.1 and have different, working link . I’m hoping someone from the PowerShell team has filed bugs internally for all the modules known to have broken help links.

Masking it while that happens is good (and addresses modules - MSFT or otherwise - which won’t ever get updated) but the masking process needs to handle the link being fixed or a new version being made available.

<div>404 - File or directory not found.</div>

Try Update-Help -Force -ErrorAction SilentlyContinue

For PSReadline module you need to rename PSReadline to PSReadLine in “C:\Program Files\WindowsPowerShell\Modules” and reload module PSReadLine in PowerShell

Just FYI, the issue about Update-Help PSReadLine is a known issue due to the in-box PSReadLine module folder name, which has been fixed in newer versions of Windows. Please see this blog for workarounds: https://devblogs.microsoft.com/powershell/updating-help-for-the-psreadline-module/

For what it’s worth, I have a new work laptop and a new personal laptop and both still have problems updating PowerShell help for several modules, including PSReadLine/PSReadline. The “out-of-box experience” has not changed at all from what I can tell.

The personal laptop is running Windows 11 21H2 (OS Build 22000.739) and still has this problem. The work laptop is running a slightly older build at Windows 10 21H2 (OS Build 19044.1706). So while I’m glad people are paying attention to this (quite old) problem, it’s really not solved in a way that works for end-users on a fresh install. These are the modules that will not update help on pwsh 7.2.5 on my Windows 11 laptop.

Get-Module -ListAvailable `
>>     Dism,
>>     Get-NetView,
>>     Kds,
>>     NetQos,
>>     PcsvDevice,
>>     PKI,
>>     PSReadLine,
>>     Whea,
>>     WindowsUpdate | Select Name, Version

Name          Version
----          -------
PSReadLine    2.1.0
PSReadline    2.0.0
Dism          3.0
Get-NetView   2021.3.23.142
Kds           1.0.0.0
NetQos        2.0.0.0
PcsvDevice    1.0.0.0
PKI           1.0.0.0
Whea          2.0.0.0
WindowsUpdate 1.0.0.0

<div> PowerShell Team</div><div>Updating help for the PSReadLine module</div><div>Describes how to workaround the error when you try to update help for PSReadline.</div>

Does anyone know why “ConfigDefenderPerformance, Dism, Get-NetView, Kds, NetQos, PcsvDevice, PKI, Whea, WindowsUpdate” might fail with a 404?

They fail because what is displayed and stored in your module path is actually folders with incorrect names, either the module author/owner/microsoft changed name completely or casing (PKI>pki)

PKI should be pki Dism should be DISM ConfigDefenderPerformance should be (even more strange) Defender Kds should be KDS And so on

A work-around is to rename them with their newer name as described here: https://devblogs.microsoft.com/powershell/updating-help-for-the-psreadline-module-in-windows-powershell-5-1/

Note that this will probably only work well for modules with the “wrong” casing, some modules like ConfigDefenderPerformance actually have dead links in their HelpInfoURI in their manifest, so it’s an actual case of 404

issue is tracked here: https://github.com/MicrosoftDocs/windows-powershell-docs/issues/2247

Does anyone know why “ConfigDefenderPerformance, Dism, Get-NetView, Kds, NetQos, PcsvDevice, PKI, Whea, WindowsUpdate” might fail with a 404?

Adding to the list of @ehmiiz items here.

Original Directory Names:

C:\Program Files\WindowsPowerShell\Modules\Pester\3.4.0
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ConfigDefenderPerformance
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\DefenderPerformance
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Dism
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Get-NetView
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Kds
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\NetQos
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PcsvDevice
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PKI
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Whea
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate

We have the new names:

*           Pester
=           ConfigDefenderPerformance
Defender    DefenderPerformance
DISM        Dism
*           Get-NetView
KDS         Kds
NetQoS      NetQos
PCSVDevice  PcsvDevice
pki         PKI
WHEA        Whea
*           WindowsUpdate
      

Where * need special treatment as their correct naming can’t be found. Also, Pester has a good description of the issue here (and how to fix it.)

Most of the correct info I got from looking at this page:

• https://learn.microsoft.com/en-us/powershell/module/activedirectory/?view=windowsserver2022-ps

Fixing a few of these:

Rename-Item -Path "C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PKI" -NewName "pki" -Force
Rename-Item -Path "C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Kds" -NewName "KDS" -Force
Rename-Item -Path "C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Dism" -NewName "DISM" -Force
Rename-Item -Path "C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PcsvDevice" -NewName "PCSVDevice" -Force
Rename-Item -Path "C:\Windows\system32\WindowsPowerShell\v1.0\Modules\NetQos" -NewName "NetQoS" -Force
Rename-Item -Path "C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Whea" -NewName "WHEA" -Force

So the reamianing list of items to fix are:

Pester
ConfigDefenderPerformance
DefenderPerformance
Get-NetView
WindowsUpdate

The outdated Pester can be partially fixed with adding new version side-by-side:

Install-Module -Name Pester -Force -SkipPublisherCheck

Clearly the update function is case sensitive while someone has been using some weird Camel-case during dev…

@eabase This is not an issue that can be solved by the PowerShell team. This is a problem with the module shipped by the Windows team. For modules that ship in Windows, use the Windows Feedback Hub. For more information, see Send feedback to Microsoft with the Feedback Hub app.

This is a duplicate of the following issues:

• #13591
• #17534
• #17577
• #18064
• #18869

This issue occurs for me as well and has on every version of PowerShell I’ve used. It seems to me that the solution to appease users is rather simple:

1. If a module fails to update, continue silently.

I honestly don’t care much if a module fails to update. I just want to know the help that COULD be updated HAS been updated. The rest falls on the developers for these modules.

1. There is no reason to tell me I can run Update-Help -UICulture en-US when that is the exact command I just ran.

At the very least, detect what command I used, and skip this part if they match up.

Here’s my output from 7.3.6 (x64) on Windows 11.

PS> Update-Help -UICulture en-US

Update-Help: Failed to update Help for the module(s) 'ConfigDefenderPerformance, DefenderPerformance, Dism, Get-NetView, Kds, LAPS, NetQos, PcsvDevice, Pester, PKI, Whea, WindowsUpdate' with UI culture(s) {en-US} : One or more errors occurred. (Response status code does not indicate success: 404 (The specified blob does not exist.).).
English-US help content is available and can be installed using: Update-Help -UICulture en-US.

Here’s some additional information in case it is useful.

PS> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.3.6
PSEdition                      Core
GitCommitId                    7.3.6
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

See also #13591, via https://github.com/MicrosoftDocs/windows-powershell-docs/issues/2247 (thanks, @ehmiiz )

@theJasonHelmick, Thanks, I do think that would be helpful. However, my opinion is that it’s more important to get the help that is available instead of allowing me to hide legitimate messages telling me that I’ve failed to update help that is available. If we are going to do that, we might as well just have Update-Help ignore all errors. An example of a module that might wind up on the “block list” when it shouldn’t be there is PSRead(L|l)ine. People would be really tempted to add it just to make the errors go away, but this would be a disservice to the community because that help is actually available. Our fix should make the help available, not just let users ignore the error telling them that PowerShell failed to get the update for them.

To be more specific, in addition to giving options to squelch errors, I think it would be good to add more little intelligence to how potential upgrade modules are matched. Let me explain a proposal as a starting point for discussion.

Suppose that there is a signed module from author X called Abc, with version 1, and another signed module, also from author X, called ABC, with version 2. In this case, if you ask PowerShell to find modules named abc, it will tell you about both of these versions, even though abc does not match the case of either release. Using everyone’s favorite example, PSRead(L|l)ine, I can search for psreadline in lower case and get back matches that are not lowercase, even in Linux:

Get-Module -Name PSReadLine -ListAvailable -All | Select-Object -Property Name, Version | Where-Object Version -ne "0.0"

Name       Version
----       -------
PSReadLine 2.1.0
PSReadline 2.0.0

It is an inconsistent user experience to have this consistently case-insensitive policy changed when we run Update-Help.

So I think that the best solution has two parts:

1. Make Update-Help case-insensitive with respect to module names, so that PSReadline matches PSReadLine, as it should in the context of the PowerShell user experience; and
2. Also implement a block list, and repopulate it with modules and versions that the PowerShell team knows to be “terminal,” meaning that they do not , and will not/cannot work with Update-Help.

The end state would be that if I have help installed for PSReadline 2.0.0 and there is help available for PSReadLine 2.1.0, running Update-Help -Module PSReadLine should succeed (no matter how the user capitalizes PSReadLine) and there should be a list of known “offenders” that Update-Help will not generate errors for if they fail to process successfully, with users able to append to that list.

I’m investigating ways to improve the situation with Update-Help, so let me ask here: what if there was a way you could easily configure a ‘block’ list to prevent retrying an update for missing modules. The error messages would remain the same. This configurable list may initially ship with the modules that we know will not be updated in the future. You can add additional modules if that is needed. Would that be helpful?

@meyerovb

The module ConfigDefenderPerformance is included with Windows PowerShell , not bundled with PowerShell 7 If you do get-module -list ConfigDefenderPerformance | fl * You’ll see the path to module is under C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
and help info URI for the module is http://go.microsoft.com/fwlink/?linkid=390762 but if you go to that link it returns a 404 error. When update help tries to find the help files it gets the same 404 error and that is what you are seeing.

Some other modules bundled with Windows do the same (I listed ones I know about above). The way to raise problems with these is via the Windows 10/11 feedback hub but that is slow to get any response, and the PowerShell team should report these ti the team which contributes the module to Windows - @daxian-dbw I think you have reported some has anyone done the exercise of adding all Windows components, and running update-help from PowerShell 7, and logging bugs with other MSFT teams whose components don’t download help successfully ? It’s a really boring job but it would do a lot for the perception of quality.

<div>404 - File or directory not found.</div>

I do suggest opening up an issue in the PSReadLine repo as that we can definitely fix. Marking as enhancement for the suggestion for catching the 404 error.

PSReadline Ships with PowerShell itself and really should be tidied up. It has it’s own repo and it might be good to cross post there.

Config Defender Performance is delivered as a part of Windows and depending on OS version the list of modules missing help will vary. My Windows 11 machine lists ConfigDefenderPerformance, Dism, Get-NetView, Kds, NetQos, PcsvDevice, PKI, Whea and WindowsUpdate as missing in 7.2.2 and 5.1 adds ConfigDefender, HostNetworkingService, StorageBusCache, VMDirectStorage - which I’m assuming PowerShell 7 won’t load. For a few that I’ve checked, the stub help that is present has a link to the web page with the help so it has been written, it just can’t be downloaded locally.

Sadly this has been the case for a long time, and the chances of the PowerShell team getting the various Microsoft teams who deliver modules to do their jobs properly were never good, and seem to have grown worse.