Powershell fails with Update
workaround:
Update-Help -Verbose -Force -ErrorAction SilentlyContinue
-verbose
will output whatever command is doing,
-force
will forcefully complete the script even if error occurs in between,
-ErrorAction SilentlyContinue
will do similar stuff like above.
In short, modules still won't get updated which were not updating earlier
TL;DR and Workaround
Years later, this is still a problem for most users. I thought I'd give a thorough explanation here.
Two problems:
Update-Help
needs PowerShell with Run As Administrator- Microsoft has broken update links, which throws errors on every system. To this day, certain modules you have mentioned continue to throw errors
Your first error is blatant and straight forward, with this output being directly included in your first error output:
Access is denied. The command could not update Help topics for the Windows PowerShell core modules, or for any modules in the $pshome\Modules directory. To update these Help
topics, start Windows PowerShell by using the "Run as Administrator" command, and try running Update-Help again.
To suppress the errors, but still download everything you are able to, you can run the following (within a PowerShell console launched via Run as Administrator):
Update-Help -Verbose -Force -ErrorAction SilentlyContinue
OR
Update-Help -Verbose -Force -ErrorAction SilentlyContinue -ErrorVariable UpdateErrors
Fixing PSReadLine
EDIT (09/01/2021): PSReadLine
has specific directions available, if that is one of the modules you want to fix:
Rename C:\Program Files\WindowsPowerShell\Modules\PSReadline
to C:\Program Files\WindowsPowerShell\Modules\PSReadLine
(this is because it is case-sensitive, so we need PSReadLine, not PSReadline).
More might be needed, though. Here is a full walkthrough from one of the blog posts:
- Close all
powershell.exe
processes. Then rename thePSReadline
module folder name toPSReadLine
. - Open an
powershell.exe
session in Administrator privilege. - Run
Remove-Module PSReadLine
to remove the auto-loaded PSReadLine module. - Run
Import-Module PSReadLine
(use PSReadLine with capital L). - Then run
Update-Help -Module PSReadLine -Force
Blog posts referenced for the PSReadLine
updates fix:
- https://devblogs.microsoft.com/powershell/updating-help-for-the-psreadline-module/
- https://devblogs.microsoft.com/powershell/updating-help-for-the-psreadline-module-in-windows-powershell-5-1/
Explanation of Workaround/Solution
This is an explanation of
Update-Help -Verbose -Force -ErrorAction SilentlyContinue -ErrorVariable UpdateErrors
, how it works, and why it is needing to be done until certain fixes may be done by Microsoft for specific modules, or forUpdate-Help
itself.
From the help documentation for Update-Help
, this is why Administrator priviliges are needed:
Update-Help requires administrative privileges.
You must be a member of the Administrators group on the computer to update the help files for the PowerShell Core modules.
To download or update the help files for modules in the PowerShell installation directory ($PSHOME\Modules), including the PowerShell Core modules, start PowerShell by using the Run as administrator option. For example: Start-Process powershell.exe -Verb RunAs.
You can also update help files by using the Update Windows PowerShell Help menu item in the Help menu in Windows PowerShell Integrated Scripting Environment (ISE).
The Update Windows PowerShell Help item runs an Update-Help cmdlet without parameters. To update help for modules in the $PSHOME directory, start Windows PowerShell ISE by using the Run as administrator option.
As for the parameters used:
-Force
means a few things, also as quoted directly from the documentation forUpdate-Help
:
Indicates that this cmdlet doesn't follow the once-per-day limitation, skips version checking, and downloads files that exceed the 1 GB limit.
Without this parameter, Update-Help runs only once in each 24-hour period. Downloads are limited to 1 GB of uncompressed content per module and help files are only installed when they're newer than the existing files on the computer.
The once-per-day limit protects the servers that host the help files and makes it practical for you to add an Update-Help command to your PowerShell profile without incurring the resource cost of repeated connections or downloads.
-Verbose
just means it will be providing a wall of yellow text describing which modules are attempting to be updated, URIs being resolved, etc.-ErrorVariable UpdateErrors
saves errors to a variable that are retrievable via the$UpdateErrors
variable-ErrorAction SilentlyContinue
means to simply ignore any errors, and move on to the next module that can be updated
You may wonder why suppressing an error is considered a fix. It is because:
- If you have a script running this command, and you wouldn't want the script to exit out on account of these errors.
- It suppresses the errors only for the modules it fails to download help for, and still downloads the help for all other modules it can.
- If the errors still wish to be investigated, they at least are available within the
$UpdateErrors
variable and can be saved to file or dealt with in some other way. - To truly resolve the errors being thrown, Microsoft has to do something to fix their own help documentation endpoints.
Wait, but why is this Microsoft's problem?
Here is an example on the latest Windows 10 system (as of Q4 2019 / Q1 2020):
$PSVersionTable
Name Value
---- -----
PSVersion 5.1.18362.145
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.18362.145
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Get-WmiObject win32_operatingsystem | select Caption, Version
Caption Version
------- -------
Microsoft Windows 10 Pro 10.0.18363
For those both new and experienced with PowerShell on Windows, seeing these Update-Help
errors during the first steps of updating help documentation is a major turn off and point of confusion. Most of the errors aren't some kind of misconfiguration on the users end, but it has unfortunately been the default and continued expectation of the command output for the past few years.
Yes, the workaround command works. But, if people are moving toward running a built-in command by suppressing error output and moving on, that's a bad customer experience (and maybe not the best practice to teach people, in the event that some other errors are occurring?). Suppressing the errors is all people are left with. Even here from 2016 where it is the highest up-voted answer:
- PowerShell (5)Update-Help throws error after installing Windows 10 Anniversary Update
Note that the marked accepted answer (which should NOT be the accepted answer) for the update error related to the HelpInfoUri
here says:
I think you will need to contact MS support for this.
The issue is with your machine and its installation and you will need to get support to help you. I think the only suggestion we can make is to re-install Windows. (!!)
Crazy stuff! DO NOT REINSTALL IF YOU GET THIS ERROR! I hope the user didn't go through some re-install because of a HelpInfoUri
being wrong.
As said by SamB in this GitHub issue directly focused on trying to resolve this continuing problem, the HelpInfoURI
values set by Microsoft in their PowerShell manifest files are at fault:
Well, the Module Manifest for WindowsUpdateProvider on this machine doesn't give any attribution beyond "Microsoft Corporation", but it does specify a
HelpInfoUri
of https://go.microsoft.com/fwlink/?linkid=390794, so there's actually no need to futz around figuring out where the module comes from and somehow make the case that this warrants issuing a patch to WindowsUpdateProvider -- it's just necessary to get that redirect pointed somewhere appropriate.
If you run the following on a system where these Update-Help
errors appear, you should see the output:
Import-Module WindowsUpdateProvider
Get-Module WindowsUpdateProvider | select HelpInfoURI,Version
HelpInfoUri Version
----------- -------
https://go.microsoft.com/fwlink/?linkid=390794 1.0.0.2
With the source module manifest for WindowsUpdateProvider, as an example, being located here:
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdateProvider\WindowsUpdateProvider.psd1
Microsoft could definitely redirect the link to a working HelpInfoUri
, which would mean zero-change on the client end.
On a side-note, people using -ErrorAction SilentlyContinue
on the regular are missing that several other modules have their help broken. As of today, these are broken on a standard Windows 10 desktop:
$TestModules = @("Microsoft.PowerShell.ODataUtils", "Microsoft.PowerShell.Operation.Validation", "UEV", "Whea", "WindowsDeveloperLicense", "defender", "configdefender", "appvclient")
Import-Module $TestModules
$BorkedHelp = Get-Module $TestModules | select Name, Version, HelpInfoUri
$BorkedHelp
Name Version HelpInfoUri
---- ------- -----------
appvclient 1.0.0.0 https://go.microsoft.com/fwlink/?LinkId=403112
configdefender 1.0 https://go.microsoft.com/fwlink/?linkid=390762
defender 1.0 https://go.microsoft.com/fwlink/?linkid=390762
Microsoft.PowerShell.ODataUtils 1.0 https://go.microsoft.com/fwlink/?LinkId=509916
Microsoft.PowerShell.Operation.Validation 1.0.1 https://go.microsoft.com/fwlink/?LinkId=808399
UEV 2.1.639.0 https://go.microsoft.com/fwlink/?LinkId=826061
Whea 2.0.0.0 https://go.microsoft.com/fwlink/?linkid=390848
WindowsDeveloperLicense 1.0.0.0 https://go.microsoft.com/fwlink/?linkid=285578
foreach ($uri in $BorkedHelp.helpinfouri) {Invoke-WebRequest $uri}
Welcome to a sea of red 404 - File or directory not found.
errors, with all the endpoints needing to be redirected. Some endpoints have been broken for years, at the moment, while others have for maybe less.
These should be fixable by Microsoft, with whatever tooling they have around their link forwarding, unless they instead update the module manifests themselves in order to point to newly-working HelpInfoURI
endpoints, which would be the less-friendly option to all users.
If the issue for Microsoft is that there is no downloadable documentation for these by default, and that links are perhaps auto-generated reservations to use later when there is documentation to download, they should at least have a bare-minimum HelpInfoURI
endpoint instead of a broken one.
Helping Make Microsoft Aware
Users who run into this problem, and found this explanation helpful, should visit this issue on GitHub: MicrosoftDocs/windows-powershell-docs: Update-Help fails for WindowsUpdateProvider
EDIT (09/01/2021): The above issue has since been closed, and Microsoft no longer uses UserVoice for feedback (was mentioned as the appropriate place when the issue was closed). It looks like the best bet is to go to the Microsoft Tech Community: PowerShell, due to the notice in Microsoft support docs around UserVoice:
Note: We will be moving away from UserVoice feedback sites on a product-by-product basis throughout the 2021 calendar year. We will leverage 1st party solutions for customer feedback. Reference
If any of the problematic PowerShell modules have public repositories, those would be the appropriate places to otherwise raise issues on broken Update-Help
functionality. If it is a PowerShell module that comes with a Microsoft product, then the issue needs to be raised with some kind of report to the product itself.
An Alternative Fix
For any known PowerShell Modules that have help-documentation endpoints broken, you can also comment out the HelpInfoURI
value in the PowerShell manifest. Update-Help
only attempts to download updates for modules where HelpInfoURI
has a value. This could be helpful for knowing if a new error has arisen, due to a problem with the endpoint (such as a HelpInfoURI
hosting your own module documentation).