For the core modules in PowerShell 5.0, Get-Help -Online opens the help for PowerShell 4.0, not for PowerShell 5.0. Typically, -online gets help for the latest version of the module by default.

For example: Get-Help Import-Module -Online
...opens "https://technet.microsoft.com/library/af616c24-e122-4098-930e-1e3ea2080ade(v=wps.630).aspx", the 4.0 version of help.

That's because the first related link in the XML help topic has the FWLink for the 4.0 topic.

I suspect this is a bug caused by an incomplete understanding of how -Online works. The tool (or person?) that was supposed to update the links for 5.0 didn't know how it worked and updated only the HelpUri attribute.

The URI for online help can be added in one of two places:
-- First related link of cmdlet/function help
-- HelpUri attribute of the cmdlet

When both are populated, the first related link takes precedence.

For core cmdlets, the URI in the first related link is the URI to the PowerShell 4.0 version of the help topic. For example:

(Get-Help Import-Module).relatedLinks.navigationlink[0].uri
http://go.microsoft.com/fwlink/p/?linkid=289591

The link to the Import-Module help for PowerShell 5.0 is the value of the HelpUri attribute of the cmdlet.

(gcm Import-Module).helpuri
http://go.microsoft.com/fwlink/?LinkID=141553

We should fix this and make sure that the tools for 6.0 do it right.

The ProviderHelp section of the System.Management.Automation.dll-help.xml file is missing from PowerShell 5.1 and later versions of PowerShell 5.0., including 5.0.10586.494.

As a result, users can't get help for the core providers (except for the certificate provider, which is in the security file), and help is missing for all of the dynamic parameters that the providers add to the cmdlets.

Also, the Security help file has the provider help section, so Get-Help Certificate works, but even though it has the CmdletHelpPaths section, it is not working (not sure why), so there is no help for the dynamic parameters that the Certificate provider adds to provider cmdlets.

Upgraded from WMF 4.0 to WMF 5.0 on Windows 7 SP1 x64 with .NET 4.6.1 and can't get NuGet/OneGet etc. to work at all. Already tried uninstall of WMF 5.0 and reinstall to no avail.

PS T:> Install-PackageProvider -Name NuGet -ForceBootstrap
Install-PackageProvider : Unable to find repository with SourceLocation ''. Please use Get-PSRepository to see all
available repositories.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -ForceBootstrap
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac

kageProvider], Exception

+ FullyQualifiedErrorId : RegisterPackageSourceRequired,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPack

ageProvider

PS T:> Get-PSRepository
PackageManagement\Get-PackageSource : Unable to find module providers (PowerShellGet).
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:3544 char:31
+ ... ckageSources = PackageManagement\Get-PackageSource @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (Microsoft.Power...etPackageSource:GetPackageSource) [Get-PackageSource

], Exception

+ FullyQualifiedErrorId : UnknownProviders,Microsoft.PowerShell.PackageManagement.Cmdlets.GetPackageSource

PS T:> Get-PackageProvider
PS T:> Get-PackageProvider -ListAvailable
PS T:> dir "$env:LOCALAPPDATA\Microsoft\Windows\PowerShell\PowerShellGet"
PS T:> [environment]::OSVersion.Version

Major Minor Build Revision

6 1 7601 65536

PS T:\Win\Too\admin\DHE> $PSVersionTable

Name Value

PSVersion 5.0.10586.117
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10586.117
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

This should speak for itself:

PS > Get-PackageSource

Name ProviderName IsTrusted IsRegistered IsValidated Location

PSGallery PowerShellGet False True False https://www.powershellgallery.com/api/v2

PS > find-module ise -Verbose
VERBOSE: Using the provider 'PowerShellGet' for searching packages.
VERBOSE: The -Repository parameter was not specified. PowerShellGet will use all of the registered repositories.
VERBOSE: Getting the provider object for the PackageManagement Provider 'NuGet'.
VERBOSE: The specified Location is 'https://www.powershellgallery.com/api/v2' and PackageManagementProvider is 'NuGet'.
VERBOSE: No module found matching 'ise' .

Find-Module works fine in the console host.

Spying with Wireshark reveals that while the console host connects to https://www.powershellgallery.com as part of the execution of Find-Module, this is not the case for the ISEs...

Hello,

Since WMF 5.0, I encountered abnormal disk latency, when running DSC.
Process Monitor showed that WMI host process was doing a lot of WriteFile operation to the folder: C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis\PowerShellAnalysisCacheEntry*
the amount of operation is increasing over time (up to 200.000 write operations in my case) each time dsc configuration is being executed…
All those operations are triggered when calling get-psdrive which is calling the module manifest Microsoft.Powershell.Security.psd1

I could reproduce it on a new VM with only WMF 5.0 installed, LCM configured in push mode using the default settings and a single test resource in the configuration which only call get-psdrive..
After running the start-dscconfiguration command several times, I did experience the same behavior as described before, it first only make 2 write operation in the cache folder, and then it quickly increases each time it runs again.

I'd be more than happy to share any log/dump files if it can help solving this issue (the stack trace is to long to be pasted here).
Those are the exception I got from a memory dump file:
System.UriFormatException
Invalid URI: The format of the URI could not be determined.
System.Uri.CreateThis(System.String, Boolean, System.UriKind)
System.Management.Automation.ModuleIntrinsics.GetModulePath(Boolean, System.Management.Automation.ExecutionContext)

System.Management.Automation.PSArgumentException
No Windows PowerShell snap-ins matching the pattern 'Microsoft.PowerShell.Security' were found. Check the pattern and then try the command again.
System.Uri.CreateThis(System.String, Boolean, System.UriKind)
System.Management.Automation.ModuleIntrinsics.GetModulePath(Boolean, System.Management.Automation.ExecutionContext)

System.Management.Automation.ItemNotFoundException
Cannot find path 'C:\WSMan.format.ps1xml' because it does not exist.

System.Management.Automation.LocationGlobber.ExpandMshGlobPath(System.String, Boolean, System.Management.Automation.PSDriveInfo, System.Management.Automation.Provider.ContainerCmdletProvider, System.Management.Automation.CmdletProviderContext)

Thanks

briac

I have the execution policy set Unrestricted, I've added the folder to the modules path, I have a module in the folder with the same name as the folder, yet I can only load the modules by file path. Any idea why? I need modules to load other modules, I'd like my own folder, and I'd like to not have to keep calling scripts in the same folder.

PS C:\Users\russell.GOISC> $env:PSModulePath
[...];C:\Projects\OI2\SiteMaintenanceScripts\PowerShellModules

PS C:\Users\russell.GOISC> Get-ExecutionPolicy
Unrestricted

PS C:\Users\russell.GOISC> Import-Module EZTNameExtensions -Verbose
Import-Module : The specified module 'EZTNameExtensions' was not loaded because no valid module file was found in any module directory.
...

PS C:\Users\russell.GOISC> Import-Module C:\Projects\OI2\SiteMaintenanceScripts\PowerShellModules\EZTNameExtensions.psm1
-Verbose
VERBOSE: Loading module from path 'C:\Projects\OI2\SiteMaintenanceScripts\PowerShellModules\EZTNameExtensions.psm1'.
WARNING: The names of some imported commands from the module 'EZTNameExtensions' include unapproved verbs...

PS C:\Users\russell.GOISC> Import-Module PowerShellModules
Import-Module : The specified module 'PowerShellModules' was not loaded because no valid module file was found in any module directory.
...

PS C:\Users\russell.GOISC> Import-Module C:\Projects\OI2\SiteMaintenanceScripts\PowerShellModules\PowerShellModules.psm1
-Verbose
VERBOSE: Loading module from path 'C:\Projects\OI2\SiteMaintenanceScripts\PowerShellModules\PowerShellModules.psm1'.
VERBOSE: Exporting function 'Get-Function'.
VERBOSE: Importing function 'Get-Function'.

When publishing DSC resources to the PowerShell Gallery, the PS Script Analyzer incorrectly flags errors any examples with the following error:

Parse error in file ...\Documents\WindowsPowerShell\Modules\Lability\0.9.8\DSCResources\xHyper-V\Examples\Sample_xVhdFileExamples.ps1: The DSC engine could not load the module 'xHyper-V'. It was not found on the system at line 27 column 9.

I would image that this affects the MS published DSC resources too. Now, I know that this doesn't currently stop the modules from being published, but presumably at some point any errors will reject the module from submission.

We need a reliable way of turning that rule off for example files. The last thing we want happening is people removing examples to get modules published!