Install-PackageProvider cannot retrieve the list of available providers if the machine doesn't have direct access to the internet.

PS C:\Windows\system32> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
WARNING: Unable to download the list of available providers. Check your internet connection.
Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package
provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac
kageProvider], Exception
+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
vider

How to reproduce:
1. Setup a network completely separate from the internet.
2. Setup an HTTP-proxy in that network as following:
2.1. The machine with HTTP-proxy has 2 network interfaces: 1 connected to a LAN and another one - to the internet.
2.2. Configure the proxy in a way to require authentication, not allowing anonymous connections. Configure Kerberos authentication.
2.3. Allow access to the internet via the proxy for AD user accounts only, not for the computer ones.
3. Publish the proxy with WPAD.
4. Use Group Policy to configure Internet Explorer throughout the network to use WPAD as a source of proxy settings.
5. Try access the internet (http://example.com) via Internet Explorer - everything works fine.
6. Launch PowerShell console as an administrator, using AD account allowed to access internet via the proxy.
7. Try to download NuGet provider using Install-PackageProvider cmdlet - you receive an error shown above.

Steps to reproduce:

1. Install WMF5 RTM on a fresh Windows 2012 R2 system
2. Open an Administrator PS prompt and run "Install-Module Pester -Force"

Expected result: The -Force parameter causes the NuGet client to be installed without user intervention.

Actual result: The following message is displayed:

NuGet-anycpu.exe is required to continue.
PowerShellGet requires NuGet-anycpu.exe to interact with NuGet based galleries. NuGet-anycpu.exe must be available in
'C:\Program Files\PackageManagement\ProviderAssemblies' or
'C:\Users\Administrator\AppData\Local\PackageManagement\ProviderAssemblies'. For more information about NuGet provider,
see http://OneGet.org/NuGet.html. Do you want PowerShellGet to download NuGet-anycpu.exe now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):

The MSDN documentation for $PSCmdlet.ShouldContinue (https://msdn.microsoft.com/en-us/library/ms568259%28v=vs.85%29.aspx) states "Cmdlets calling ShouldContinue should also implement a Force parameter that allows the cmdlet to bypass these calls. If this is not done, it will be difficult to use the cmdlet from scripts and noninteractive hosts." I'm trying to use Install-Module from an automated setup script on a fresh machine, and this prompt causes the script to hang.

Workaround: Before using Install-Module for the first time, run the following command to fetch NuGet-anycpu.exe (this is what Install-Module is doing internally):

PackageManagement\Get-PackageProvider -Name NuGet -Force

In order to register external module dependencies (dependencies living in another repository), the name has to be registered in a string array property within the PSData Hashtable property in the PrivateData section in the psd1 manifest like so for registering module 'psFtp':

PrivateData = @{
PSData = @{
# ExternalModuleDependencies
ExternalModuleDependencies = @('psFtp')
}
} # End of PrivateData hashtable

However, the new-modulemanifest doesn't have an -ExternalModuleDepencies parameter, nor is it possible to register externalmoduledependencies like so:

-PrivateData @{ PSData = @{ ExternalModuleDependencies = @('psFtp') } }

Which from a client perspective of the the existing new-modulemanifest api, would be an intuitive way of setting ExternalModuleDependencies.

Suggestion is:
Either make -ExternalModuleDependencies available as parameter or let the processing of the -PrivateData arguments handle nested hashtables (such as PSData in this case).

When you run Install-Module to install one or more modules from the PowerShell Gallery, by default those modules will be placed into %ProgramFiles%\WindowsPowerShell\Modules, yet on PowerShell 3.0, that path is not part of PSModulePath by default. That path only became part of the default PSModulePath in PowerShell 4.0 or later.

This is a big problem for PowerShell 3.0 because after a module is "installed", the commands within that module won't be discoverable and the module will not autoload without manual intervention (loading the module via the path or manual update of the PSModulePath environment variable).

PowerShellGet should address this problem by automatically adding %ProgramFiles%\WindowsPowerShell\Modules to the beginning of PSModulePath if it is missing and if the environment is running PowerShell 3.0. I just searched the PowerShellGet psm1 file in version 1.0.0.1 and couldn't find anything indicating to me that it does this today.

To see tested code that does this today and that is used to install modules hosted on GitHub, have a look at lines 95-119 in the Install-ModuleFromGitHub gist, which can be found here: https://gist.github.com/KirkMunro/131308abfb2d857bea40. It updates the appropriate system environment variable and PSModulePath in memory, placing %ProgramFiles%\WindowsPowerShell\Modules in the appropriate position in each of locations.

There are a few additional properties that should be returned when you query the PowerShell Gallery using Find-Module or Find-Script that are currently not exposed although they are accessible via the PowerShell Gallery Website.

As the PowerShell Gallery Website already has this information it shouldn't be too taxing to include this as an exposed property when accessing the Gallery via PowerShell

Although it is possible to get this information via using WebScraping methods from the Gallery website - this adds unneeded requests when this could be included by default.

The Additional Properties I would like to see included would be

Owner
Total Downloads
Statistics

This will then reduce the overhead on the AutoBot (@ThePSGallery) that I've created and could be more useful for the end users as well as Module Owners.

Update-ScriptFileInfo only has a couple of mandatory fields. However when you leave them blank the cmdlet returns errors from the validation.

The variable cannot be validated because the value is not a valid value for the CompanyName variable.
The variable cannot be validated because the value is not a valid value for the Copyright variable.
The variable cannot be validated because the value $null is not a valid value for the RequiredModules variable.
The variable cannot be validated because the value $null is not a valid value for the ExternalModuleDependencies variable.
The variable cannot be validated because the value $null is not a valid value for the RequiredScripts variable.
The variable cannot be validated because the value $null is not a valid value for the ExternalScriptDependencies variable.
The variable cannot be validated because the value $null is not a valid value for the Tags variable.
The variable cannot be validated because the value $null is not a valid value for the ProjectUri variable.
The variable cannot be validated because the value $null is not a valid value for the LicenseUri variable.
The variable cannot be validated because the value $null is not a valid value for the IconUri variable.
You cannot call a method on a null-valued expression.

This can be reproduced by running the example from msdn.

New-ScriptFileInfo -Path "\temp\temp-scriptfile.ps1" -Version 1.0 -Author "pattif@contoso.com" -Description "my test script file description goes here"

Update-ScriptFileInfo -Path "\temp\temp-scriptfile.ps1" -Version 2.0 -PassThru

When I publish my Carbon module, I get these warnings:

WARNING: Tags are now supported in the module manifest file (.psd1). Update the module manifest file of module 'Carbon' in 'C:\Users\ajensen\AppData\Local\Temp\Carbon+34y02ccd.v5v\Carbon' with the newest tag changes. You can run Update-ModuleManifest -Tags to update the manifest wi
th tags.
WARNING: ReleaseNotes is now supported in the module manifest file (.psd1). Update the module manifest file of module 'Carbon' in 'C:\Users\ajensen\AppData\Local\Temp\Carbon+34y02ccd.v5v\Carbon' with the newest ReleaseNotes changes. You can run Update-ModuleManifest -RleaseNotes to
update the manifest with ReleaseNotes.
WARNING: LicenseUri is now supported in the module manifest file (.psd1). Update the module manifest file of module 'Carbon' with the newest LicenseUri changes. You can run Update-ModuleManifest -LicenseUri to update the manifest with LicenseUri.
WARNING: ProjectUri is now supported in the module manifest file (.psd1). Update the module manifest file of module 'Carbon' in 'C:\Users\ajensen\AppData\Local\Temp\Carbon+34y02ccd.v5v\Carbon' with the newest ProjectUri changes. You can run Update-ModuleManifest -ProjectUri to upda
te the manifest with ProjectUri.
WARNING: This module 'C:\Users\ajensen\AppData\Local\Temp\661067551\Carbon\Carbon.psd1' has exported DscResources. As a best practice, include exported DSC resources in the module manifest file(.psd1). If your PowerShell version is higher than 5.0, run Update-ModuleManifest -DscRes
ourcesToExport to update the manifest with ExportedDscResources field.

Even though my module manifest contains that data (https://bitbucket.org/splatteredbits/carbon/src/2.1.1/Carbon/Carbon.psd1?fileviewer=file-view-default).

I expect not to get warnings about data that isn't missing. Otherwise, I will learn to ignore warnings and when something warning-worthy actually happens, I won't notice.

currently it is not possible to specify RequiredModules for a script published to a repository.
This is awkward as it is quite likely for simple scripts to have a dependency on a module.

The goal would be for the module to be installed automatically during install-Script; using the same logic and conditions as the a REQUIREDSCRIPT
1) Interestingly there appears to be (partial) logic to test for RequiredModules, however this always fails as a .Name addtibute of the module cannot be found.
and the syntax used in modules :
.RequiredModules @{ModuleName = 'foo'; GUID = '1234565-2784-48bf-af15-70ba837a64d0'; ModuleVersion = '3.5'; }
is not parsed correctly, and is just stored as a string

This appears to be either a parsing bug, or an incomplete implementation

2) it is possible to specify EXTERNALMODULEDEPENDENCIES, but that is a partial substitute as it does not perform the installation of the module.

This is possible for a