Powershell Gallery Powershellget 2.x

Tell us about your PDF experience.
PowerShellGet and the PowerShell

Gallery
Article • 04/12/2023
The PowerShell Gallery is the central repository for PowerShell content. In it, you can
find
PowerShell scripts, modules containing PowerShell cmdlets and Desired State
Configuration (DSC)
resources. Some of these packages are authored by Microsoft, and
others are authored by the
PowerShell community.
The PowerShellGet module contains cmdlets for discovering, installing, updating, and
publishing
PowerShell packages from the PowerShell Gallery. These packages can
contain artifacts such as
Modules, DSC Resources, Role Capabilities, and Scripts. Make
sure you have the latest version of
PowerShellGet installed.
For more information see:
Install PowerShellGet
Update PowerShellGet for Windows PowerShell
Getting Started with the PowerShell Gallery

Check out the Getting Started page for more information on how to use PowerShellGet
commands with the Gallery. You can also run Update-Help -Module PowerShellGet -
Force to install
local help for these commands.
Giving feedback
Provide feedback and report issues in the GitHub repository . To see the current status
of the
PowerShell Gallery services, see the PowerShell Gallery Status page on GitHub.
The PowerShellGet module
Article • 06/30/2023
The PowerShellGet module contains cmdlets for discovering, installing, updating, and
publishing
PowerShell packages from the PowerShell Gallery . These packages can
contain artifacts such as
Modules, DSC Resources, and Scripts.
Supported versions:
Current release - PowerShellGet 2.2.5 with PackageManagement 1.4.8.1

Preview release - Microsoft.PowerShell.PSResourceGet 0.5.22-beta22
The preview release is now included in PowerShell 7.4.0-preview.4 and newer
releases
Version history
Windows PowerShell 5.1 comes with version 1.0.0.1 of PowerShellGet and
PackageManagement preinstalled.
） Important
The 1.0.0.1 version of PowerShellGet has limited features and must be

updated to work properly
with the PowerShell Gallery. To be supported, you
must update to the latest version. For upgrade
instructions, see Installing
PowerShellGet on Windows.
PowerShell 6.0.0 shipped with PowerShellGet 1.6.0 and PackageManagement

1.1.7.
PowerShell 7.0.0 shipped with PowerShellGet 2.2.3 and PackageManagement

1.4.6.
PowerShell 7.0.4, PowerShell 7.1.1, and higher shipped with PowerShellGet 2.2.5
and
PackageManagement 1.4.7.
PowerShell 7.4.0-preview.2 shipped with PowerShellGet 2.2.5 and

PackageManagement
1.4.8.1.
Future versions of PowerShell 7.4.0 will ship with

Microsoft.PowerShell.PSResourceGet.
７ Note
Microsoft.PowerShell.PSResourceGet is a standalone module and no longer

depends on the
PackageManagement module.
For best results, use the latest version of the Microsoft.PowerShell.PSResourceGet

module.
See also
Install PowerShellGet
PowerShellGet cmdlet reference
Microsoft.PowerShell.PSResourceGet cmdlet reference
How to Install PowerShellGet
Article • 07/26/2023
Prerequisites
Ensure that you have a version of PowerShellGet and PackageManagement newer than
1.0.0.1 installed. The latest stable versions are 2.2.5 for PowerShellGet and 1.4.8.1 for
PackageManagement.
If you're running Windows PowerShell 5.1 with PowerShellGet 1.0.0.1, see Update
PowerShellGet for Windows PowerShell 5.1.
To access the PowerShell Gallery, you must use Transport Layer Security (TLS) 1.2 or
higher. Use the following command to enable TLS 1.2 in your PowerShell session.
PowerShell
[Net.ServicePointManager]::SecurityProtocol =
[Net.ServicePointManager]::SecurityProtocol -bor
[Net.SecurityProtocolType]::Tls12
Add this command to your PowerShell profile script to ensure TLS 1.2 is configured for
every PowerShell session. For more information about profiles, see about_Profiles.
If you're running PowerShell 6.0 or later, you already have a newer version of
PowerShellGet and PackageManagement installed. You can upgrade to a newer version
if necessary or install the preview release. You should always install the latest stable
release.
Use the following command to see what version is installed.
PowerShell
Get-Module PowerShellGet, PackageManagement -ListAvailable
The following output shows that the latest stable version needs to be installed.
Output
Directory: C:\Program Files\WindowsPowerShell\Modules
ModuleType Version Name ExportedCommands

---------- ------- ---- ----------------
Binary 1.0.0.1 PackageManagement {Find-Package, Get-Package, ...
Script 1.0.0.1 PowerShellGet {Install-Module, Find-Module, ...
Install the latest stable release

To install the latest versions of these modules run the following:
PowerShell
Install-Module PowerShellGet -Force -AllowClobber
Install the Preview release

To install this preview release side-by-side with your existing PowerShellGet version,
open any PowerShell console and run:
PowerShell
Install-Module Microsoft.PowerShell.PSResourceGet -AllowClobber -

AllowPrerelease
Update PowerShellGet for Windows
PowerShell 5.1
Article • 06/09/2023
Windows PowerShell 5.1 comes with version 1.0.0.1 of the PowerShellGet and
PackageManagement
preinstalled. This version of PowerShellGet has a limited features
and must be updated to work
with the PowerShell Gallery. To be supported, you must
update to the latest version.
Prerequisites
PowerShellGet requires .NET Framework 4.5 or above. For more information, see
Install the .NET Framework for developers.
To access the PowerShell Gallery, you must use Transport Layer Security (TLS) 1.2 or
higher. Use
the following command to enable TLS 1.2 in your PowerShell session.
PowerShell
Add this command to your PowerShell profile script to ensure TLS 1.2 is configured
for every
PowerShell session. For more information about profiles, see
about_Profiles.
Installing the latest version of PowerShellGet

The PowerShellGet module includes cmdlets to install and update modules:
Install-Module installs the latest (non-prerelease) version of a module.

Update-Module installs the latest (non-prerelease) version of a module if it's newer
than the
currently installed module. However, this cmdlet only works if the
previous version was installed
using Install-Module .
To update the preinstalled module you must use Install-Module . After you have
installed the new
version from the PowerShell Gallery, you can use Update-Module to
install newer releases.
Windows PowerShell 5.1 comes with PowerShellGet version 1.0.0.1, which doesn't
include the NuGet
provider. The provider is required by PowerShellGet when working
with the PowerShell Gallery.
７ Note
The following commands must be run from an elevated PowerShell session. Right-
click the PowerShell
icon and choose Run as administrator to start an elevated
session.
There are two ways to install the NuGet provider:
Use Install-PackageProvider to install NuGet before installing other modules
Run the following command to install the NuGet provider.
PowerShell
Install-PackageProvider -Name NuGet -Force
After you have installed the provider you should be able to use any of the
PowerShellGet
cmdlets with the PowerShell Gallery.
Let Install-Module prompt you to install the NuGet provider
The following command attempts to install the updated PowerShellGet module

without the NuGet
provider.
PowerShell
Install-Module PowerShellGet -AllowClobber -Force
Install-Module prompts you to install the NuGet provider. Type Y to install the
provider.
Output
NuGet provider is required to continue
PowerShellGet requires NuGet provider version '2.8.5.201' or newer to

interact with NuGet-based
repositories. The NuGet provider must be available in 'C:\Program

Files\PackageManagement\ProviderAssemblies'
or 'C:\Users\user1\AppData\Local\PackageManagement\ProviderAssemblies'.
You can also install the
NuGet provider by running 'Install-PackageProvider -Name NuGet -

MinimumVersion 2.8.5.201 -Force'.
Do you want PowerShellGet to install and import the NuGet provider now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y
VERBOSE: Installing NuGet provider.
After installing PowerShellGet

After you have installed the new version of PowerShellGet, you should open a new
PowerShell
session. PowerShell automatically loads the newest version of the module
when you use a
PowerShellGet cmdlet.
We also recommend that you register the PowerShell Gallery as a trusted repository. Use
the
following command:
PowerShell
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
For more information, see Set-PSRepository.

Installing PowerShellGet on older
Windows systems
Article • 06/09/2023
Older versions of Windows shipped with different versions of PowerShell. The

PowerShellGet
module requires PowerShell 3.0 or newer.
PowerShellGet requires .NET Framework 4.5 or above. For more information, see
Install
the .NET Framework for developers.
） Important
As of April 2020, the PowerShell Gallery no longer supports Transport Layer Security
(TLS)
versions 1.0 and 1.1. If you are not using TLS 1.2 or higher, you will receive an
error when
trying to access the PowerShell Gallery. Use the following command to
ensure you are using TLS
1.2:
PowerShell
For more information, see the

announcement in the
PowerShell blog.
For computers running PowerShell 3.0 or

PowerShell 4.0
These instructions apply to computers that have the PackageManagement Preview
installed or don't
have any version of PowerShellGet installed.
The Save-Module cmdlet is used in both sets of instructions. Save-Module downloads and
saves a
module and any dependencies from a registered repository. The module's most
current version is saved
to a specified path on the local computer, but isn't installed. To
install the modules in PowerShell
3.0 or 4.0, copy the saved module folders to
$env:ProgramFiles\WindowsPowerShell\Modules .
For more information, see Save-Module.

７ Note
PowerShell 3.0 and PowerShell 4.0 only supported one version of a module. Starting
in PowerShell
5.0, modules are installed in <modulename>\<version> folders. This
allows you to install
multiple versions side-by-side. After downloading the module
using Save-Module you must copy the
files from the <modulename>\<version> folder
to the <modulename> folder on the destination
machine, as shown in the instructions
below.
Preparatory Step on computers running PowerShell 3.0

The instructions in the sections below install the modules in directory
$env:ProgramFiles\WindowsPowerShell\Modules . In PowerShell 3.0, this directory isn't
listed in
$env:PSModulePath by default, so you'll need to add it in order for the modules
to be autoloaded.
Open an elevated PowerShell session and run the following command:
PowerShell
$NewPSModulePath = [Environment]::GetEnvironmentVariable('PSModulePath',
'Machine') +
";$env:ProgramFiles\WindowsPowerShell\Modules"
[Environment]::SetEnvironmentVariable('PSModulePath', $NewPSModulePath,
'Machine')
The updated value of $env:PSModulePath isn't available in the current session. You must
open a
new PowerShell session.
For computers with the PackageManagement Preview

installed
７ Note
PackageManagement Preview was a downloadable component that made

PowerShellGet available to
PowerShell versions 3 and 4, but it's no longer available.
To test if it was installed on a given
computer, run Get-Module -ListAvailable
PowerShellGet .
1. From a PowerShell session, use Save-Module to download the current version of
PowerShellGet. Two folders are downloaded: PowerShellGet and
PackageManagement. Each
folder contains a subfolder with a version number.
PowerShell
Save-Module -Name PowerShellGet -Path C:\LocalFolder -Repository

PSGallery
2. Ensure that the PowerShellGet and PackageManagement modules aren't loaded

in any other
processes.
3. Reopen the PowerShell console with elevated permissions and run the following
command.
PowerShell
'PowerShellGet', 'PackageManagement' | % {
$targetDir = "$env:ProgramFiles\WindowsPowerShell\Modules\$_"
Remove-Item $targetDir\* -Recurse -Force
Copy-Item C:\LocalFolder\$_\*\* $targetDir\ -Recurse -Force
How to add credentials to repositories

in Microsoft.PowerShell.PSResourceGet
Article • 06/28/2023
Microsoft.PowerShell.PSResourceGet allows you to register private repositories that

contain
installable PSResource packages. Typically, private repositories require you to
have credentials to
access them. JFrog Artifactory is a service that allows you to create
private NuGet
repositories. This article demonstrates how to use SecretStore credentials
with an Artifactory
repository.
Prerequisites
Set up a SecretManagement vault
Create a credential to be used with Artifactory
７ Note
This example uses SecretStore, but you can use any SecretManagement extension
vault and
with any repository.
Use Get-SecretInfo to verify that the vault contains the credential you need.
PowerShell
Get-SecretInfo
Output
Name Type VaultName
---- ---- ---------
JFrogCred PSCredential SecretStore
For more information about SecretManagement, see

Overview of the
SecretManagement and SecretStore modules.
Add a credential to a PSResourceRepository

Once you have a store credential, you need to add it to the registered repository. Create
a
PSCredentialInfo object that references the store credential. You can register a new
PSResourceRepository or add the credential to an existing one using the
Set-
PSResourceRepository cmdlet. This example shows how to register a new repository.
PowerShell
$registerPSResourceRepositorySplat = @{
Name = 'artifactory'
Uri = 'https://myaccount.jfrog.io/artifactory/api/nuget/v3/myrepository'
Trusted = $true
CredentialInfo =
[Microsoft.PowerShell.PowerShellGet.UtilClasses.PSCredentialInfo]::new(
'SecretStore', 'JFrogCred')
Register-PSResourceRepository @registerPSResourceRepositorySplat
Run Get-PSResourceRepository to see the registered repositories.
PowerShell
PS C:\Users > Get-PSResourceRepository
Output
Name Uri
Trusted Priority
---- ---
------- --------
artifactory https://myaccount.jfrog.io/artifactory/api/nuget/v3/myrepository
True 50
PSGallery https://www.powershellgallery.com/api/v2
False 50
Publishing resources to the repository

To publish resources to a secured repository, you must provide the credential you
configured. This
example show how to publish a resource to the artifactory repository
using your stored credential.
PowerShell
Publish-PSResource -Path .\Get-Hello\ -Repository artifactory -ApiKey (Get-

Secret JFrogPublish)
Once you have provided the credential, PowerShellGet reuses the credential for
subsequent
commands that target the same repository. The following examples show
how to find and install a
resource. Notice that the credential isn't required.
PowerShell
Find-PSResource -Name Get-Hello -Repository artifactory
Output
Name Version Prerelease Repository Description
---- ------- ---------- ---------- -----------
Get-Hello 0.0.2.0 artifactory test module
PowerShell
PS C:\Users> Install-PSResource Get-Hello
Supported repository configurations

Article • 07/20/2023
The Microsoft.PowerShell.PSResourceGet module, also known as PowerShellGet v3,

works with NuGet package repositories and local file stores. In general, the cmdlets
should work with any artifact repository that supports the NuGet protocol. However, not
all NuGet repositories support all the features of PSResourceGet.
The following repositories have been tested with PSResourceGet.
The PowerShell Gallery

The PowerShell Gallery is the default repository for PSResourceGet. The Gallery is a
NuGet repository that uses the NuGet v2 protocol.
You don't need credentials to search, download, or install packages from the PowerShell
Gallery. You must create an account and API key to publish packages to the PowerShell
Gallery. For more information, see Creating and publishing an item.
The PowerShell Gallery supports all the features of PSResourceGet.
NuGet.org
NuGet.org is a public host of NuGet packages used by millions of .NET and .NET Core
developers every day. NuGet.org provides a NuGet repository that uses the NuGet v3
protocol.
Use the following command to register NuGet.org as a PSResource repository:
PowerShell
$params = @{
Name = 'NuGetGallery'
Uri = 'https://api.nuget.org/v3/index.json'
}
Register-PSResourceRepository @params
You don't need credentials to search, download, or install packages from NuGet.org. You
must create an account and API key to publish packages to NuGet.org. For more
information about getting a NuGet API key, see Quickstart: Create and publish a NuGet
package.
NuGet.org limitations
The Microsoft.PowerShell.PSResourceGet module doesn't support the following
scenarios for NuGet.org repositories:
Wildcard search by name, for example:

Find-PSResource -Name '*'
Search by command or DSC resource name, for example:

Find-PSResource -Command commandname
Find-PSResource -DSCResource dscresourcename
Publishing to NuGet.org
You don't need to use the Credential parameter of the Publish-PSResource cmdlet, but
you must use the ApiKey parameter. You can provide credentials, but NuGet.org doesn't
use them. To create an API key, see How to publish NuGet packages. For example:
PowerShell
$publishPSResourceSplat = @{
Path = 'D:\MyModule'
Repository = 'AzArtifactFeed'
ApiKey = '<nuget-api-key>'
}
Publish-PSResource @publishPSResourceSplat
Ｕ Caution
You should never use plaintext credentials in a script. Use the SecretManagement
module or other methods to store and retrieve your credentials securely. For more
information, see Overview of the SecretManagement and SecretStore modules.
Azure Artifacts
Azure Artifacts is a feature of Azure DevOps. Azure Artifacts enables developers to share
their code efficiently and manage all their packages from one place. With Azure
Artifacts, developers can publish packages to their feeds and share it within the same
team, across organizations, and even publicly.
Azure Artifacts supports the NuGet v3 protocol. Azure Artifacts feed URIs use the
following format:
https://dev.azure.com/<organization-name>/<project-name>/_packaging/<feed-
name>/v3/index.json
Substitute the placeholder values with your organization, project, and feed names. For
example, use the following command to register an Azure Artifacts feed as a PSResource
repository:
PowerShell
$params = @{
Name = 'MyAdoFeed'
Uri =
'https://pkgs.dev.azure.com/MyOrg/MyProject/_packaging/MyFeed/nuget/v3/index
.json'
}
Azure DevOps allows you to create public or private feeds for your Azure Artifacts. You
don't need credentials to search, download, or install packages from an Azure Artifacts
public feed. To publish artifacts or access private feeds, you must have an account and
an API key. For more information about getting an API key, see Connect to feed as a
PowerShell repository.
Azure Artifacts limitations

scenarios for Azure Artifacts repositories:

Find-PSResource -Name 'Az*'

Find-PSResource -Name 'Az*' -Tag compute
Search by tag, for example:

Find-PSResource -Tag compute
Publishing to Azure Artifacts

You must use the Credential and ApiKey parameters of the Publish-PSResource cmdlet
to publish packages to an Azure Artifacts feed. The credential must be a personal access
token (PAT) that has the Packaging (read, write, and manage) scope. For more
information, see Use Azure Artifacts feeds as a private PowerShell repository - Azure
Artifacts. The value of the ApiKey parameter is not important. It can be any arbitrary
string, but it must be included. For example:
PowerShell
$patToken = ConvertTo-SecureString -String '<personal-access-token>' -

AsPlainText -Force
$Credential = [System.Management.Automation.PSCredential]::new('<username>',
$patToken)
Repository = 'AzArtifactFeed'
ApiKey = 'AzureDevOps'
Credential = $Credential
}
For this example <personal-access-token> is the token you created for publishing.
<username> is your Azure DevOps user name.
Ｕ Caution
GitHub Packages
GitHub Packages is a software package hosting service that allows you to host your
software packages privately or publicly and use packages as dependencies in your
projects. For more information, see Introduction to GitHub Packages .
The GitHub Packages feed is a NuGet repository that uses the NuGet v3 protocol. The
feed URI has the following format:
https://nuget.pkg.github.com/<namespace>/index.json . Replace <namespace> with the
name of the personal account or organization to which your packages are scoped. For
example, use the following command to register an GitHub Packages feed as a
PSResource repository:
PowerShell
$params = @{
Name = 'MyGitHubFeed'
Uri = 'https://nuget.pkg.github.com/MyGitHubOrg/index.json'
}
The Github Packages service doesn't support NuGet feeds that are scoped to a
repository. The feed must be associated with a user account or organization.
You must use credentials for all operations with a GitHub Packages feed. For more
information, see the Authenticating to GitHub Packages section of Working with the
NuGet registry .
GitHub Packages limitations

scenarios for GitHub Packages repositories:

Search by tag For example:


Publish packages to a feed

The package is published as a private package. After publishing, you can use the
GitHub interface to link it to the desired repository and change the visibility.
Publishing to GitHub Packages

You can use either the Credential or ApiKey parameter of the Publish-PSResource
cmdlet to publish packages to a GitHub Package feed. You must create a personal
access token (PAT) with the necessary scopes enabled. For more information on scopes
and permissions, see About permissions for GitHub Packages .
If you use the Credential parameter, the value must be a PSCredential object that
contains your username and the PAT. For this example <personal-access-token> is the
token you created for publishing. <username> is your GitHub username.
PowerShell
$patToken = ConvertTo-SecureString -String '<personal-access-token>' -
AsPlainText -Force
$Credential = [System.Management.Automation.PSCredential]::new('<username>',
$patToken)
Repository = 'MyGitHubFeed'
}
If you use the ApiKey parameter, the value must be the plaintext PAT. For example:
PowerShell
ApiKey = '<personal-access-token>'
}
Ｕ Caution
JFrog Artifactory
JFrog Artifactory is a hosting service for NuGet repositories. Artifactory feeds use the
NuGet v3 protocol. The feed URI has the following format:
https://<jfrog-account>.jfrog.io/artifactory/api/nuget/v3/nuget/index.json .
Replace <jfrog-account> with the name of your JFrog account. For example, use the
following command to register an Artifactory feed as a PSResource repository:
PowerShell
$params = @{
Name = 'MyJFrogFeed'
Uri =
'https://myjfrogaccount.jfrog.io/artifactory/api/nuget/v3/nuget/index.json'
}
You must use credentials for all operations with a JFrog Artifactory feed. For more
information, see Creating Access Tokens in Artifactory .
JFrog Artifactory limitations

scenarios for JFrog Artifactory repositories:


Publishing to JFrog Artifactory

You must use the Credential parameter of the Publish-PSResource cmdlet to publish
packages to a JFrog Artifactory feed. The value of the Credential parameter must be a
PSCredential object constructed from your email address and the access token that was
created when you configured the NuGet repository in your JFrog account. For example:
PowerShell
$patToken = ConvertTo-SecureString -String '<jfrog-access-token>' -

AsPlainText -Force
$Credential = [System.Management.Automation.PSCredential]::new('<email-
address>', $patToken)
Repository = 'MyJFrogFeed'
}
For this example <jfrog-access-token> is the token you created for publishing. <email-
address> is your email address associated with your JFrog account.
Ｕ Caution
MyGet.org
MyGet.org is a hosting service for NuGet repositories.
The Microsoft.PowerShell.PSResourceGet module supports MyGet feeds that use the

NuGet v3 protocol. The feed URI has the following format:
https://www.myget.org/F/<feedname>/api/v3/index.json
Replace <feedname> with the name of your MyGet feed. For example, use the following
command to register a MyGet feed as a PSResource repository:
PowerShell
$params = @{
Name = 'PublicMyGetFeed'
Uri = 'https://www.myget.org/F/mypackagefeed/api/v3/index.json'
}
MyGet allows you to create public or private feeds. You don't need credentials to search,
download, or install packages from a public MyGet feed. To publish artifacts or access
private feeds, you must have an account and an API key. For more information about,
see MyGet Security .
MyGet limitations
scenarios for MyGet repositories:

Search by tag, for example:


Publishing to a MyGet feed
You must use the ApiKey parameter of the Publish-PSResource cmdlet with personal
access token (PAT) to publish packages to a MyGet feed. The value of the ApiKey
parameter must be a plaintext PAT from your MyGet account that has read and write
permissions. For more information about creating access tokens, see MyGet Security .
For example:
PowerShell
ApiKey = '<personal-access-token>'
}
Ｕ Caution
File-share-based repositories
You can create your own package repository as a local file share. For more information,
see Working with local PSRepositories. You access file-share-based repositories using
local filesystem APIs or remote filesystem protocols, such as SMB or NFS.
The permissions set by the filesystem and the file sharing protocol control access to the
files. You can't use the Credential parameter of the
Microsoft.PowerShell.PSResourceGet cmdlets to access to the files using alternate user
credentials.
The Microsoft.PowerShell.PSResourceGet module supports all search scenarios for file

share repositories.
Self-hosted NuGet repositories

You can create your own package repository by hosting your own NuGet server.
NuGet.Server is a package provided by the .NET Foundation. You can use this package
to create an ASP.NET application that hosts a package feed on any Windows server
running IIS. This server uses the NuGet v2 protocol. For more information, see Working
with local PSRepositories.
The Microsoft.PowerShell.PSResourceGet module supports NuGet.Server feeds. The

feed URI has the following format:
http://<server-host-name>/nuget
７ Note
The Microsoft.PowerShell.PSResourceGet module expects the URI to end with

/nuget . Any URI that ends with /nuget is treated as a NuGet.Server feed.
Use the following command to register your self-hosted server as a PSResource

repository:
PowerShell
$params = @{
Name = 'SelfHostedNuGet'
Uri = 'https://host.contoso.net/nuget'
}
You don't need credentials to search, download, or install packages from your self-
hosted server.
Self-hosted NuGet server limitations

scenarios for self-hosted NuGet servers:
General search that uses the Type parameter

Find-PSResource finds resources that match by name, but the value of the Type
parameter is ignored. The cmdlet returns all modules and scripts that match the
name.
Publishing to a NuGet.Server instance

When you first setup a NuGet.Server instance, there is no API key defined and pushing
packages to the feed is disabled. To configure an API key, see the Adding packages to
the feed section of Using NuGet.Server to Host NuGet Feeds. The following example
shows how to publish a package using the configured API key.
PowerShell
ApiKey = '<apikey>'
}
Ｕ Caution
Getting Started with the PowerShell
Gallery
Article • 04/17/2023
The PowerShell Gallery is a package repository containing scripts, modules, and DSC
resources you
can download and leverage. You use the cmdlets in the PowerShellGet
module to install packages
from the PowerShell Gallery. You don't need to sign in to
download items from the PowerShell
Gallery.
７ Note
It's possible to download a package from the PowerShell Gallery directly, but this
isn't a
recommended approach. For more details, see Manual Package Download.
Discovering packages from the PowerShell

Gallery
You can find packages in the PowerShell Gallery using the Search control on the
PowerShell
Gallery's home page , or by browsing through the Modules and Scripts
from the
Packages page . You can also find packages from the PowerShell Gallery by
running the
Find-Module , Find-DscResource , and Find-Script cmdlets, depending on
the package type, with
-Repository PSGallery .
You can filter results from the Gallery using the following parameters:
Name
AllVersions
MinimumVersion
RequiredVersion
Tag
Includes
DscResource
RoleCapability
Command
Filter
If you're only interested in discovering specific DSC resources in the Gallery, you can run
the
Find-DscResource cmdlet. Find-DscResource returns data on DSC resources
contained in the Gallery.
Because DSC resources are always delivered as part of a
module, you still need to run
Install-Module to install those DSC resources.
Learning about packages in the PowerShell

Gallery
Once you've identified a package that you're interested in, you may want to learn more
about it. You
can do this by examining that package's specific page on the Gallery. On
that page, you'll be able
to see all the metadata uploaded with the package. This
metadata is provided by the package's
author, and is not verified by Microsoft. The
Owner of the package is strongly tied to the Gallery
account used to publish the
package, and is more trustworthy than the Author field.
If you discover a package that you feel isn't published in good faith, click Report Abuse
on
that package's page.
If you're running Find-Module or Find-Script , you can view this data in the returned
PSGetModuleInfo object. The following example returns data on the PSReadLine
module in the
Gallery.
PowerShell
Find-Module -Name PSReadLine -Repository PSGallery | Get-Member
Downloading packages from the PowerShell

Gallery
We encourage the following process when downloading packages from the PowerShell
Gallery:
Inspect
To download a package from the Gallery for inspection, run either the Save-Module or
Save-Script
cmdlet, depending on the package type. This lets you save the package
locally without installing it,

and inspect the package contents. Remember to delete the
saved package manually.
Some of these packages are authored by Microsoft, and others are authored by the
PowerShell
community. Microsoft recommends that you review the contents and code
of packages on this gallery
before installation.
If you discover a package that you feel isn't published in good faith, click Report Abuse
on
that package's page.
Install
To install a package from the Gallery for use, run either the Install-Module or Install-
Script
cmdlet, depending on the package type.
Install-Module installs the module to $env:ProgramFiles\WindowsPowerShell\Modules by
default.
This requires an administrator account. If you add the -Scope CurrentUser
parameter, the module is
installed to $HOME\Documents\WindowsPowerShell\Modules .
Install-Script installs the script to $env:ProgramFiles\WindowsPowerShell\Scripts by
default.
This requires an administrator account. If you add the -Scope CurrentUser
parameter, the script is
installed to $HOME\Documents\WindowsPowerShell\Scripts .
By default, Install-Module and Install-Script installs the most

current version of a
package. To install an older version of the package, add the -RequiredVersion
parameter.
Deploy
To deploy a package from the PowerShell Gallery to Azure Automation, click Azure
Automation,
then click Deploy to Azure Automation on the package details page. You
are redirected to the
Azure Management Portal where you sign in using your Azure
account credentials. Note that
deploying packages with dependencies deploys all the
dependencies to Azure Automation. The 'Deploy
to Azure Automation' button can be
disabled by adding the AzureAutomationNotSupported tag to
your package metadata.
To learn more about Azure Automation, see the Azure Automation documentation.
Updating packages from the PowerShell

Gallery
To update packages installed from the PowerShell Gallery, run either the Update-Module
or
Update-Script cmdlet. When run without any additional parameters, Update-Module
attempts to
update all modules installed by running Install-Module . To selectively
update modules, add the
-Name parameter.
Similarly, when run without any additional parameters, Update-Script also attempts to
update all
scripts installed by running Install-Script . To selectively update scripts, add
the -Name
parameter.
List packages that you have installed from the

PowerShell Gallery
To find out which modules you have installed from the PowerShell Gallery, run the
Get-
InstalledModule cmdlet. This command lists all the modules you have on your system
that were
installed directly from the PowerShell Gallery.
Similarly, to find out which scripts you have installed from the PowerShell Gallery, run
the
Get-InstalledScript cmdlet. This command lists all the scripts you have on your
system that were
installed directly from the PowerShell Gallery.
Network access to the PowerShell Gallery

These hostnames should be added to the allow lists that control access from your
network.
Hosts required for package discovery and download:
onegetcdn.azureedge.net - CDN hostname

psg-prod-centralus.azureedge.net - CDN hostname
psg-prod-eastus.azureedge.net - CDN hostname

az818661.vo.msecnd.net - CDN hostname
７ Note
The CDN for the PowerShell gallery is active for one name, psg-prod-
eastus.azureedge.net or
psg-prod-centralus.azureedge.net , at any given time. The
inactive name becomes the valid, active

name if there is a need to failover the
service. Therefore, both names should be included in your
allow lists.
Hosts required when using the PowerShell Gallery website:
devopsgallerystorage.blob.core.windows.net - storage account hostname

*.powershellgallery.com - website
go.microsoft.com - redirection service

） Important
As of April 2020, the PowerShell Gallery no longer supports Transport Layer Security
(TLS)
versions 1.0 and 1.1. If you are not using TLS 1.2 or higher, you will receive an
error when
trying to access the PowerShell Gallery. Use the following command to
ensure you are using TLS
1.2:
PowerShell
For more information, see the

announcement in the
PowerShell blog.
Related links
Find-DscResource
Find-Module
Find-Script
Get-InstalledModule
Get-InstalledScript
Install-Module
Install-Script
Publish-Module
Publish-Script
Register-PSRepository
Save-Module
Save-Script
Update-Module
Update-Script
Frequently asked questions about
the PowerShell Gallery
FAQ
What is a PowerShell module?

A PowerShell module is a reusable package containing some PowerShell functionality.
Everything in PowerShell (functions, variables, DSC resources, etc.) can be packaged in
modules. Typically, modules are folders containing specific types of files stored on a
specific path. There are a few different types of PowerShell modules out there.
What is a PowerShell script?

A PowerShell script is a series of commands that are stored in a .ps1 file to enable reuse
and sharing. PowerShell workflows are also PowerShell scripts, which outline a set of
tasks and provide sequencing for those tasks. For more information, please visit Getting
Started with PowerShell Workflow.
How are PowerShell Scripts different

from PowerShell Modules?
Modules are generally better for sharing, but we are enabling script sharing to make it
easier for you to contribute workflows and scripts to the community. For more
information, see the following blogs:
Don't Write Scripts, Write PowerShell Modules

Understanding PowerShell Modules
How can I publish to the PowerShell

Gallery?
You must register an account in the PowerShell Gallery before you can publish packages
to the Gallery. This is because publishing packages requires a NuGetApiKey, which is
provided upon registration. To register, use your personal, work, or school account to
sign in to the PowerShell Gallery. A one-time registration process is required when you
sign in for the first time. Afterwards, your NuGetApiKey is available on your profile page.
Once you have registered in the Gallery, use the Publish-Module or Publish-Script
cmdlets to publish your package to the Gallery. For more details on how to run these
cmdlets, visit the Publish tab, or read the Publish-Module and Publish-Script
documentation.
You do not need to register or sign in to the Gallery to install or save packages.
I received "Failed to process request."

when I tried to publish a package to the
PowerShell Gallery. What does that
mean?
The full error message is: "Failed to process request." 'The specified API key is invalid or
does not have permission to access the specified package.'. The remote server returned
an error: (403) Forbidden."
This error can occur for the following reasons:
The specified API key is invalid. Ensure that you have specified the valid API key
from your account. To get your API key, view your profile page.
The specified package name is not owned by you. If you have confirmed that
your API key is correct, then there may already exist a package with the same name
as the one you are trying to use. The package may have been unlisted by the
owner, in which case it will not appear in any search results. To determine if a
package with the same name already exists, open a browser and navigate to the
package's details page:
https://www.powershellgallery.com/packages/<packageName> . For example,
navigating directly to https://www.powershellgallery.com/packages/pester will

take you to the Pester module's details page, whether it is unlisted or not. If a
package with a conflicting name already exists and is unlisted, you can:
Select another name for your package.
Contact the owners of the existing package.
Why can't I sign in with my personal

account, but I could sign in yesterday?
Please be aware that your gallery account does not accommodate changes to your
primary email alias. For more information, see Microsoft Email Aliases .
Why don't I see all the gallery packages
when I select all the Category
checkboxes on the packages tab?
By selecting a Category checkbox, you are stating "I would like to see all packages in this
category." Only the packages in the selected categories will be displayed. So similarly, by
selecting all the Category checkboxes, you are stating "I would like to see all packages in
any category." But some packages in the gallery do not belong to any of the categories
listed, so they will not appear in the results. To see all packages in the gallery, uncheck
all the Categories, or select the packages tab again.
What are the requirements to publish a

module to the PowerShell Gallery?
Any kind of PowerShell module (script modules, binary modules, or manifest modules)
can be published to the gallery. To publish a module, PowerShellGet needs to know a
few things about it - the version, description, author, and how it is licensed. This
information is read as part of the publishing process from the module manifest (.psd1)
file, or from the value of the Publish-Module cmdlet's LicenseUri parameter. All modules
published to the Gallery must have module manifests. Any module that includes the
following information in its manifest can be published to the Gallery:
Version
Description
Author
A URI to the license terms of the module, either as part of the PrivateData section
of the manifest, or in the LicenseUri parameter of the Publish-Module cmdlet.
How do I create a correctly-formatted

module manifest?
The easiest way to create a module manifest is to run the New-ModuleManifest cmdlet.
In PowerShell 5.0 or newer, New-ModuleManifest generates a correctly-formatted
module manifest with blank fields for useful metadata like ProjectUri, LicenseUri, and
Tags. Simply fill in the blanks, or use the generated manifest as an example of correct
formatting.
To verify that all required metadata fields have been properly filled, use the Test-
ModuleManifest cmdlet.
To update the module manifest file fields, use the Update-ModuleManifest cmdlet.
What are the requirements to publish a

script to the Gallery?
Any kind of PowerShell script (scripts or workflows) can be published to the gallery. To
publish a script, PowerShellGet needs to know a few things about it - the version,
description, author, and how it is licensed. This information is read as part of the
publishing process from the script file's PSScriptInfo section, or from the value of the
Publish-Script cmdlet's LicenseUri parameter. All scripts published to the Gallery must
have metadata information. Any script that includes the following information in its
PSScriptInfo section can be published to the Gallery:
Version
Description
Author
A URI to the license terms of the script, either as part of the PSScriptInfo section of
the script, or in the LicenseUri parameter of the Publish-Script cmdlet.
How do I search?
Type what you are looking for in the text box. For example, if you want to find modules
that are related to Azure SQL, just type "azure sql". Our search engine will look for those
keywords in all published packages, including titles, descriptions and across metadata.
Then, based on a weighted quality score, it will display the closest matches. You can also
search by specific field using field:"value" syntax in the search query for the following
fields:
Tags
Functions
Cmdlets
DscResources
PowerShellVersion
So, for example, when you search for PowerShellVersion:"2.0" only results that are
compatible with PowerShellVersion 2.0 (based on their module/script manifest) will be
displayed.
How do I create a correctly-formatted
script file?
The easiest way to create a properly-formatted script file is to run the New-ScriptFileInfo
cmdlet. In PowerShell 5.0, New-ScriptFileInfo generates a correctly-formatted script file
with blank fields for useful metadata like ProjectUri, LicenseUri, and Tags. Simply fill in
the blanks, or use the generated script file as an example of correct formatting.
To verify that all required metadata fields have been properly filled, use the Test-
ScriptFileInfo cmdlet.
To update the script metadata fields, use the Update-ScriptFileInfo cmdlet.
What other types of PowerShell

Modules exist?
The term PowerShell module also refers to the files that implement actual functionality.
Script module files (.psm1) contain PowerShell code. Binary module files (.dll) contain
compiled code.
Here is one way to think about it: the folder that encapsulates the module is the module
folder. The module folder can contain a module manifest (.psd1) that describes the
contents of the folder. The files that actually do the work are the script module files
(.psm1) and the binary module files (.dll). DSC resources are located in a specific sub-
folder, and are implemented as script module files or binary module files.
All of the modules in the Gallery contain module manifests, and most of these modules
contain script module files or binary module files. The term module can be confusing
because of these different meanings. Unless explicitly stated otherwise, all uses of the
word module on this page refer to the module folder containing these files.
How does PackageManagement relate

to PowerShellGet? (High Level Answer)
PackageManagement is a common interface for working with any package manager.
Eventually, whether you're dealing with PowerShell modules, MSIs, Ruby gems, NuGet
packages, or Perl modules, you should be able to use PackageManagement's commands
(Find-Package and Install-Package) to find and install them. PackageManagement does
this by having a package provider for each package manager that plugs into
PackageManagement. Providers do all of the actual work; they fetch content from
repositories, and install the content locally. Often, package providers simply wrap
around the existing package manager tools for a given package type.
PowerShellGet is the package manager for PowerShell packages. There is a PSModule

package provider that exposes PowerShellGet functionality through
PackageManagement. Because of this, you can either run Install-Module or Install-
Package -Provider PSModule to install a module from the PowerShell Gallery. Certain
PowerShellGet functionality, including Update-Module and Publish-Module, cannot be

accessed through PackageManagement commands.
In summary, PowerShellGet is solely focused on having a premium package

management experience for PowerShell content. PackageManagement is focused on
exposing all package management experiences through one general set of tools. If you
find this answer unsatisfying, there is a long answer at the bottom of this document, in
the How does PackageManagement actually relate to PowerShellGet? section.
For more information, please visit the PackageManagement project page .
How does NuGet relate to

PowerShellGet?
The PowerShell Gallery is a modified version of the NuGet Gallery . PowerShellGet uses
NuGet provider to work with NuGet based repositories like the PowerShell Gallery.
You can use PowerShellGet against any valid NuGet repository or file share. You simply
need to add the repository by running the Register-PSRepository cmdlet.
Does that mean I can use NuGet.exe to

work with the Gallery?
Yes.
How does PackageManagement actually

relate to PowerShellGet? (Technical
Details)
Under the hood, PowerShellGet heavily leverages PackageManagement infrastructure.
At the PowerShell cmdlet layer, Install-Module is actually a thin wrapper around
Install-Package -Provider PSModule .
At the PackageManagement package provider layer, the PSModule package provider

actually calls into other PackageManagement package providers. For example, when you
are working with NuGet-based galleries (such as the PowerShell Gallery), the PSModule
package provider uses the NuGet Package Provider to work with the repository.
Figure 1: PowerShellGet Architecture
What is required to run PowerShellGet?

In general we recommend picking the latest version of PowerShellGet module (note that
it requires .NET 4.5).
The PowerShellGet module requires PowerShell 3.0 or newer.
Therefore, PowerShellGet requires one of the following operating systems:
Windows 10
Windows 8.1 Pro
Windows 8.1 Enterprise
Windows 7 SP1
Windows Server 2016
Windows Server 2012 R2
Windows Server 2008 R2 SP1
PowerShellGet also requires .NET Framework 4.5 or above. For more information, see
Install the .NET Framework for developers.
Is it possible to reserve names for

packages that will be published in
future?
It is not possible to squat package names. If you feel that an existing package has taken
the name which suits your package more, try contacting the owner of the package. If
you didn't get response within a couple of weeks, you can contact support and the
PowerShell Gallery team will look in to it.
How do I claim ownership for packages?

Check out Managing Package Owners on PowerShellGallery.com for details.
How do I deal with a package owner

who is violating my package license?
We encourage the PowerShell community to work together to resolve any disputes that
may arise between package owners and the owners of other packages. We have crafted
a dispute resolution process that we ask you to follow before PowerShellGallery.com
administrators intercede.
Gallery Search Syntax
Article • 04/17/2023
You can search the PowerShell Gallery using the

PowerShell Gallery's web site .
PowerShell Gallery web site
offers a text searchbox where you can use words, phrases
and keyword expressions to narrow down
search results.
Search by Keywords
Syntax
dsc azure sql
Search attempts to find relevant documents containing all 3 keywords, and return
matching documents.
Search using Phrases and keywords

Syntax
"azure sql" deployment
Entering a phrase between quotation marks ("") change the search to look for the
particular phrase
instead of separate keywords. Matching documents should usually
contain the exact phrase "azure
sql", including variations on capitalization e.g. "Azure
SQL", and also usually contain the word
'deployment'.
Filtering on fields
You can search for a specific package ID (or 'Id' or 'id'), or certain other fields by
prefixing
search terms with the field name.
Currently the searchable fields are 'Id', 'Version', 'Tags', 'Author', 'Owner', 'Functions',
'Cmdlets', 'DscResources' and 'PowerShellVersion'.
ID is the name you use in the console.

Title is what is shown at the top of the package page in search results.
Examples
Syntax
ID:PSReadline
finds packages with an ID containing "PSReadline".
Syntax
Id:"AzureRM.Profile"
is another way to find packages with "AzureRM.Profile" in their ID field.
The 'Id' filter is a substring match, so if you search for the following:
Syntax
Id:"azure"
This provides results that include AzureRM.Profile' and 'Azure.Storage'.
You can also search for multiple keywords in a single field.
Syntax
id:azure tags:intellisense
And you can perform phrase searches using double quotes:
Syntax
id:"azure.storage"
To search all packages with DSC tag.
Syntax
Tags:DSC
To search all packages with the specified function.
Syntax
Functions:Get-TreeSize
To search all packages with the specified cmdlet.
Syntax
Cmdlets:Get-AzureRmEnvironment
To search all packages with the specified DSC Resource name.
Syntax
DscResources:xArchive
To search all packages with the specified PowerShellVersion
Syntax
PowerShellVersion:2.0
Finally, if you use a field we don't support, such as 'commands', we'll just ignore it and
search
all the fields. So the following query
Syntax
commands:blobs storage
Is interpreted exactly the same as this query:
Syntax
blobs storage
Packages with compatible PowerShell

Editions or Operating Systems
Article • 04/17/2023
Starting with version 5.1, PowerShell is available in different editions which denote
varying
feature sets and platform compatibilities.
Searching by PowerShell Edition

The two editions of PowerShell are:
Desktop Edition: Built on .NET Framework and provides compatibility with scripts
and modules
targeting versions of PowerShell running on full footprint editions of
Windows such as Server Core
and Windows Desktop.
Core Edition: Built on .NET Core and provides compatibility with scripts and
modules
targeting versions of PowerShell running on reduced footprint editions of
Windows such as Nano
Server and Windows IoT.
PowerShell Gallery allows you to filter packages

compatible for specific PowerShell Editions
If a package has compatible PSEditions specified, they are listed as part of 'PowerShell
Editions' in the package display page and also in packages results.
You can also search
for compatible packages using PowerShell.
Search for packages in the gallery UI that work on
PowerShell 6 and higher
Use Tags:"PSEdition_Desktop" and Tags:"PSEdition_Core" to filters the packages on
PowerShell Gallery.
Use Tags:"PSEdition_Core" to search items compatible

with PowerShell Core Edition
Use Tags:"PSEdition_Desktop" to search items compatible
with PowerShell Desktop Edition
Search for packages to find compatible editions using

PowerShell
You can specify tags to filter for the PowerShell edition and OS. You use the Find-
Package cmdlet
specifying the -Tag parameter to specify the edition (and OS) you are
targeting. Like this:

PowerShell
# Find modules compatible with PowerShell Core:
Find-Module -Tag PSEdition_Core
# Find modules compatible with PowerShell on Linux:
Find-Module -Tag PSEdition_Core, Linux
Searching by Operating System

Since PowerShell is available for Windows, Linux, and MacOS, packages in the Gallery
may be designed
for any combination of these operating systems. In the gallery UI use
the following searches tags to
find packages tagged by operating system:
Tags: "Windows"
Tags: "Linux"
Tags: "MacOS"
You can specify these tags on Find-Module (and other cmdlets in the PowerShellGet
module), like
this:
PowerShell
# Find Modules compatible with Windows
Find-Module -Tag Linux
Searching for Multiple Compatibilities

You can look for a package that has multiple compatibilities by using the syntax:
Tags: "Compatibility1" "Compatibility2"
For example, if you are looking for a package that runs on both Windows and Linux
machines, use
the search tags:
Tags: "PSEdition_Core" "Windows" "Linux"
To search using PowerShell, you can use the Find-Module (and the other cmdlets in the
PowerShellGet module), like this:
PowerShell
# Find scripts compatible with PowerShell, Windows, and Linux
Find-Script -Tag PSEdition_Core,Linux,Windows
# Find modules compatible with PowerShell and MacOS
Find-Module -Tag PSEdition_Core,MacOS
More details on authoring and finding the

packages with compatible PowerShell Editions
Modules with PSEditions
Scripts with PSEditions
Filtering search results
Article • 04/17/2023
The Packages tab displays all available packages in

the PowerShell Gallery.
There are several ways to filter, sort, and search the packages. To see more details about
a
particular package, click the package.
Filter By
The drop-down under "Filter By" allows users to filter the results by:
Include Prerelease
Stable Only
For information about "Prerelease" and "Stable", see

Prerelease Versioning Added to
PowerShellGet and PowerShell Gallery
in the PowerShell Team Blog.
The checkboxes under the drop-down allow users to filter the results by:
Package Types
Module
Script
Categories
Cmdlet
DSC Resource
Function
Role Capability
Workflow
To see only modules in the PowerShell Gallery, check Module in the Package Types.
Similarly, to see
only scripts in the PowerShell Gallery, check Script in the Package Types.
７ Note
Filters are inclusive. Example: A package containing both cmdlets and functions will
appear if
either Cmdlet or Function (or both) are checked. If neither are selected,
the package will not
appear. Similarly, if all categories are selected, only packages
containing one of those
categories will appear. Packages that do not belong to
any of those categories will not
appear.
Sort By
The Sort By drop-down allows users to sort the results by:
Popularity - Popularity is determined by Download Count

A-Z - Alphabetically by package name
Recent - Packages appear in order of publish date
Search Box
The Search Box allows users to search the packages on keywords.
For more information,
see Gallery Search Syntax.
Creating and publishing an item
Article • 04/17/2023
The PowerShell Gallery is the place to publish and share stable PowerShell modules,
scripts, and
Desired State Configuration (DSC) resources with the broader PowerShell
user community.
This article covers the mechanics and important steps for preparing a script or module,
and
publishing it to the PowerShell Gallery. We strongly encourage that you review the
Publishing Guidelines to understand how to ensure that
the items you publish will be
more widely accepted by PowerShell Gallery users.
The minimum requirements to publish an item to the PowerShell Gallery are:
Have a PowerShell Gallery account, and the API Key associated with it
Ensure Required Metadata is in your item
Use the pre-validation tools to ensure your item is ready to publish
Publish the item to the PowerShell Gallery using the Publish-Module and Publish-
Script commands
Respond to questions or concerns about your item
The PowerShell Gallery accepts PowerShell modules and PowerShell scripts. When we
refer to scripts,
we mean a PowerShell script that is a single file, and not part of a larger
module.
PowerShell Gallery Account and API Key

See Creating a PowerShell Gallery Account for how to set up your
PowerShell Gallery
account.
Once you have created an account, you can get the API Key needed to publish an item.
After you sign
in with the account, your username will be displayed at the top of the
PowerShell Gallery pages
instead of Register. Clicking on your username will take you to
the My Account page, where you will
find the API Key.
） Important
The API Key must be treated as securely as your login and password. With this key
you, or anyone
else, can update any item you own in the PowerShell Gallery. We
recommend updating the key
regularly, which can be done using Reset Key on your
My Account page.
Required Metadata for Items Published to the
PowerShell Gallery
The PowerShell Gallery provides information to gallery users drawn from metadata fields
that are
included in the script or module manifest. Creating or modifying items for
publication to the
PowerShell Gallery has a small set of requirements for information
supplied in the item manifest. We
strongly encourage that you review the Item
Metadata section of the
Publishing Guidelines to learn how to provide the best
information to users with your items.
The New-ModuleManifest and

New-ScriptFileInfo cmdlets will create the
manifest
template for you, with placeholders for all the manifest elements.
Both manifests have two sections that are important for publishing, the Primary Key
Data and PSData
area of PrivateData. The primary key data in a PowerShell module
manifest is everything outside of
the PrivateData section. The set of primary keys is tied
to the version of PowerShell in use, and
undefined are not supported. PrivateData
supports adding new keys, so the elements specific to the
PowerShell Gallery are in
PSData.
Manifest elements that are most important to fill in for item you publish to the
PowerShell Gallery
are:
Script or Module Name - Those are drawn from the names of the .PS1 for a script,
or the .PSD1 for
a module.
Version - this is a required primary key, format should follow SemVer guidelines.
See Best
Practices for details.
Author - this is a required primary key, and contains the name to be associated
with the item. See
Authors and Owners below.
Description - this is a required primary key, used to briefly explain what this item
does and any
requirements for using it
ProjectURI - this is a strongly recommended URI field in PSData that provides a link
to a GitHub
repo or similar location where you do development on the item
Tags - it is a strong recommendation to tag your package based on its
compatibility with
PSEditions and platforms. For details, see the
Publishing
Guidelines.
Authors and Owners of PowerShell Gallery items are related concepts, but do not always
match. Item
Owners are users with PowerShell Gallery accounts that have permission to
maintain the item. There
may be many Owners who can update any item. The Owner is
only available from the PowerShell Gallery,
and is lost if the item is copied from one
system to another. Author is a string that is built into
the manifest data, so it is always
part of the item. The recommendations for items from Microsoft
products are:
Have multiple owners, with at least one being the name of the team that produces
the item
Have the Author be a well-known team name (such as Azure SDK Team), or
Microsoft Corporation
Pre-Validate Your Item

There are a few tools you need to run against your code before publishing your item to
the
PowerShell Gallery:
PowerShell Script Analyzer , which

is in the PowerShell Gallery
For modules, Test-ModuleManifest which is part of PowerShell
For scripts, Test-ScriptFileInfo which comes with PowerShell Get
PowerShell Script Analyzer is a

static code analysis tool that will scan your code to
ensure it meets basic PowerShell coding
guidelines. This tool will identify common and
critical issues in your code, and should be run
regularly during development to help you
get your item ready to publish. PowerShell Script Analyzer
will provide list of issues
identified as Errors, Warning, and Information. All errors must be
addressed before you
publish to the PowerShell Gallery. Warnings need to be reviewed, and most
should be
addressed. PowerShell Script Analyzer is run every time an item is published or updated
in
the PowerShell Gallery. The Gallery Operations team will contact item owners to
address errors that
are found.
If the manifest information in your item cannot be read by the PowerShell Gallery
infrastructure,
you will not be able to publish.
Test-ModuleManifest will catch
common
problems that would cause the module to not be usable when it is installed. It must be
run
for every module prior to publishing it to the PowerShell Gallery.
Likewise, Test-ScriptFileInfo validates the

metadata in a script, and must be run on every
script (published separate from a module) prior to
publishing it to the PowerShell
Gallery.
Publishing Items
You must use the Publish-Script or
Publish-Module to publish items to the PowerShell
Gallery. These commands both require:
The path to the item you will publish. For a module, use the folder named for your
module. If you
specify a folder that contains multiple versions of the same module,
you must specify
RequiredVersion.
A Nuget API key. This is the API key found in the My Account page on the
PowerShell Gallery.
Most of the other options in the command line should be in the manifest data for the
item you are
publishing, so you should not need to specify them in the command.
To avoid errors, it is strongly recommended that you try the commands using -WhatIf -
Verbose,
before publishing. This will save considerable time, since every time you
publish to the PowerShell
Gallery, you must update the version number in the manifest
section of the item.
Examples would be:
Publish-Module -Path ".\MyModule" -NugetAPIKey "GUID" -WhatIf -Verbose
Publish-Script -Path ".\MyScriptFile.PS1" -NugetAPIKey "GUID" -WhatIf -

Verbose
Review the output carefully, and if you see no errors or warnings, repeat the command
without
-WhatIf.
All items that are published to the PowerShell Gallery will be scanned for viruses, and
will be
analyzed using the PowerShell Script Analyzer. Any issues that arise at that time
will be sent back
to the publisher for resolution.
Once you have published an item to the PowerShell Gallery, you will need to watch for
feedback on
your item.
Ensure you monitor the email address associated with the account used to publish.
Users, and the
PowerShell Gallery Operations team will provide feedback via that
account, including issues from
the PSSA or antivirus scans. If the email account is
invalid, or if serious issues are reported to
the account and left unresolved for a
long time, items can be considered abandoned and will be
removed from the
PowerShell Gallery as described in our
Terms of Use .
Creating a PowerShell Gallery account
Article • 08/15/2023
You must create a PowerShell Gallery account before publishing anything to the
PowerShell Gallery. PowerShell Gallery accounts must be linked to an email-enabled
login account. This account can be an Microsoft Entra ID account or a Microsoft ID, like
an email account from outlook.com or hotmail.com .
To create a PowerShell Gallery account, go to https://PowerShellGallery.com and click

on Sign in as shown in the following image.
To use an Azure Active Directory account, select Work or School Account, and sign in
with your account. To use a Microsoft ID, choose Personal Account and sign in.
Next, you are prompted to create a username for the PowerShell Gallery. Review the
Terms of Use and Privacy Policy, enter a username, and then click Register.
７ Note
The account name can't be changed once it's created. For more information, see
Managing Package Owners.
Recommended practices for PowerShell Gallery

accounts
It's important to actively monitor the email account used with your PowerShell Gallery
account. All communication with owners of PowerShell Gallery packages is through this
email address. If the PowerShell Gallery Operations team is unable to contact a package
owner, we may be required to delete a package.
Organizations that publish to the PowerShell Gallery often create a unique external
account for that purpose. We recommend you use email forwarding to forward
notifications to an address within your organization.
When multiple owners are associated with a package, all PowerShell Gallery notifications
are sent to all owners. For more information, see Managing Package Owners.
Unlisting Packages
Article • 04/17/2023
Why is removing a package from PowerShell Gallery not exposed as an option?
The PowerShell Gallery does not support users permanently deleting their packages.
This enables
others to take dependencies on your packages without worrying about
possible breaks in the future.
For example, if the Pester module depends on the Azure
module and the Azure module is removed from
the gallery, then users can no longer
use the Pester module.
Instead of removing a package you can unlist it.
What does unlisting a package on PowerShell Gallery do?
Unlisting a package such as a module or script in the PowerShell Gallery removes it from
the
Packages tab. In addition, unlisted packages will not be discoverable using the
search bar. The only
way to download an unlisted package is to specify the exact name
and version of the package. Because
of this, the unlisting of a package will not break
other modules or scripts that depend on it.
To unlist your package, visit the package details page and select 'Delete Module'.
Uncheck the
'Listed' checkbox, and select 'Save'.
How can I remove a package?
If you experience a scenario where package deletion is necessary, contact the

PowerShell Gallery
Administrators. Valid deletion scenarios are:
Issues of copyright infringement.

Package contains potentially harmful content.
Package contains sensitive data.
To submit a Delete Package Request to the PowerShell Gallery Administrators, visit your
package's
detail page and select Contact Support.
Deleting Packages
Article • 04/17/2023
The PowerShell Gallery does not support permanent deletion of packages, because that
would break
anyone who is depending on it remaining available.
Instead, the PowerShell Gallery supports a way to 'unlist' a package, which can be done
in the
package management page on the web site. When a package is unlisted, it no
longer shows up in search
and in any package listing, both on the PowerShell Gallery
and using PowerShellGet commands.
However, it remains downloadable by specifying
its exact version, which is what allows the automated
scripts to continue working.
If you run into an exceptional situation where you think one of your packages must be
deleted, this
can be handled manually by the PowerShell Gallery team. For example, if
there is a copyright
infringement issue, or potentially harmful content, that could be a
valid reason to delete it. You
should submit a support request through PowerShell
Gallery in
that case.
Managing package owners
Article • 04/17/2023
Ownership of a package in the PowerShell Gallery is defined by who published the

package to the
gallery. Sometimes this metadata needs to be managed beyond the
initial package publishing, which
means the owner metadata needs to be mutable while
the package itself is not.
All package owners are peers. This means any package owner can publish a new version
of an package.
It also means that any package owner can remove any other package
owner. No owner has more authority
than other owners.
Setting a Package's Initial Owner

When a new package is published to PowerShell Gallery, the initial owner is defined by
the user that
published the package. This is determined by whose API key was used in
the Publish-Module cmdlet.
Adding Owners
Once a package has been published to the PowerShell Gallery, it's easy to invite
additional users to
become owners of a package.
1. Log on to the PowerShell Gallery with the

account that is the current owner of a
package.
2. Navigate to a package page using the 'Items' tab, searching, or clicking your
username and then
Manage My Packages .
3. When logged on as an package's owner, there is a 'Manage Owners' link on the
left side to click.
4. Enter the username of the person to add as an owner and click 'Add'.
5. An email is then sent to the new co-owner, as an invitation to become an owner of
a package.
6. Once that user clicks the link, they are a full co-owner with full control over a
package,
including the ability to remove other users as owners.
７ Note
Until the new owner confirms ownership, they will not be listed as an owner of a
package. When
viewing the Manage Owners page, you will see a "pending
approval" entry in the current owners.
That invitation can be removed; just as other
owners can be removed. This process of invitations
prevents users from falsely
adding other users as owners of their packages.
The "Authors" metadata is purely freeform text; only "Owners" are controlled.
Removing Owners
When a package has multiple owners and one needs to be removed, the process is
simple:
1. Log on to PowerShell Gallery with the

account that is the current owner of a
package;
2. Navigate to a package page using the Packages tab, searching, or clicking your
username and then
Manage My Packages .
3. When logged on as a package's owner, there is a 'Manage Owners' link on the left
side to click;
4. Click the 'remove' link next to the owner to be removed.
Transferring Package Ownership

We sometimes get support requests to transfer package ownership from one user to
another, but you
can almost always accomplish this yourself. Transferring ownership
from one user to another is
simply a combination of the two features above.
1. The current owner invites the new user to become a co-owner and the new user
accepts the invite;
2. The new user removes the old user from the list of owners.
This request has come in under a couple forms but the process works the same.
The package ownership is changing from one developer to another

The package was accidentally published using the wrong account
Orphaned Packages
One last scenario has occurred, but not many times. Packages have become orphans
and the only
package owner account cannot be used to add new owners. Here are some
examples of this scenario:
The owner's account is associated with an email address that no longer exists and
the user has
forgotten their password
The registered owner has left the company that produces the package and cannot
be reached to
update the package ownership
Due to a bug that has only affected a handful of packages, the package is
somehow ownerless on the
gallery
The PowerShell Gallery Administrators can access the 'Manage Owners' link for any
package. If you
are the rightful owner of a package and cannot reach the current owner
to gain ownership
permissions, then use the 'Report Abuse' link on the gallery to reach
the PowerShell Gallery
Administrators. We will then follow a process to verify your
ownership of the package. If we
determine you should be an owner of the package, we
will use the 'Manage Owners' link for the
package ourselves and send you the invite to
become an owner. We will only do this after verifying
that you should be an owner and
the process for this varies by circumstances. Often times, we will
use the package's
Project URL to find a way to contact the project owner, but we may also use
Twitter,
Email, or other means for contacting the project owner.
FileList feature in the Gallery
Article • 04/17/2023
You are able to view the contents in all packages published in the gallery.
This feature includes two parts: listing the files within the package, and displaying file
contents
for supported file types. Currently we support displaying the contents of the
following file
extensions: .ps1, .psm1, .psd1, .ps1xml, .xml and .txt. We will be supporting
more file extensions
in the next releases.
Where to Find FileList

On each individual package page, you will be able to find FileList section and a Show
link.
Click on the Show and you will find a complete list of items contained in the
package.
Each supported file type is displayed as a hyperlink, and clicking it will take you to a new
page
with file contents displayed in PowerShell syntax highlighting. Clicking on the title
or the version
of the package, which is displayed at the top of the screen, will bring you
back to package detail
page.
Deploy to Azure Automation
Article • 04/17/2023
The Deploy to Azure Automation button on the package details page will deploy the
package from
the PowerShell Gallery to Azure Automation.
When clicked, it will redirect you to the Azure Management Portal, where you sign in
using your
Azure account credentials. If the package includes dependencies, all the
dependencies will be
deployed to Azure Automation as well.
２ Warning
If the same package and version already exists in your Automation account,
deploying it again from
the PowerShell Gallery overwrites the package in your
Automation account.
If you deploy a module, it will appear in the Modules section of Azure Automation. If
you deploy a
script, it will appear in the Runbooks section of Azure Automation.
The Deploy to Azure Automation button can be disabled by adding the

AzureAutomationNotSupported tag to the package metadata.
） Important
The Deploy to Azure Automation feature does not work for sovereign (air-gapped)
clouds like
Azure Government, Azure Germany, or
Azure China 21Vianet.
We recommend setting up a private repository as described in

Working with
private PowerShellGet repositories.
Require License Acceptance on Deploy to Azure

Automation
If the module being deployed to Azure Automation requires license acceptance, portal
UI will show a
disclaimer saying 'This module requires license acceptance. By clicking OK,
you are accepting
license terms.'
More details
Require License Acceptance in PowerShellGet
Require License Acceptance in PowerShell Gallery
Azure Automation website
Manual Package Download
Article • 04/17/2023
The PowerShell Gallery supports downloading a package from the website directly,
without using the
PowerShellGet cmdlets. You can download any package as a NuGet
package ( .nupkg ) file, which you
can then copy to an internal repository.
７ Note
Manual package download is not intended as a replacement for the Install-

Module cmdlet.
Downloading the package doesn't install the module or script.
Dependencies aren't included in the
NuGet package downloaded. The following
instructions are provided for reference purposes only.
Using manual download to acquire a package

Each page has a link for Manual Download, as shown here:
To download manually, click on Download the raw nupkg file. A copy of the package is
copied to
the download folder for your browser with the name <name>.<version>.nupkg .
A NuGet package is a ZIP archive with extra files containing information about the
contents of the
package. Some browsers, like Internet Explorer, automatically replace
the .nupkg file extension
with .zip . To expand the package, rename the .nupkg file to
.zip , if needed, then extract the
contents to a local folder.
A NuGet package file includes the following NuGet-specific elements that aren't part of
the
original packaged code:
A folder named _rels - contains a .rels file that lists the dependencies
A folder named package - contains the NuGet-specific data
A file named [Content_Types].xml - describes how extensions like PowerShellGet
work with NuGet
A file named <name>.nuspec - contains the bulk of the metadata
Installing PowerShell modules from a NuGet

package
７ Note
These instructions DO NOT give the same result as running Install-Module . These
instructions
fulfill the minimum requirements. They aren't intended to be a
replacement for Install-Module .
Some steps performed by Install-Module aren't
included.
The easiest approach is to remove the NuGet-specific elements from the folder.
Removing the elements
leaves the PowerShell code created by the package author.
For
the list of NuGet-specific elements, see Using manual download to acquire a package.
The steps are as follows:
1. Unblock the Internet-downloaded NuGet package ( .nupkg ) file, for example using
Unblock-File -Path C:\Downloads\module.nupkg cmdlet.
2. Extract the contents of the NuGet package to a local folder.
3. Delete the NuGet-specific elements from the folder.
4. Rename the folder. The default folder name is usually <name>.<version> . The
version can
include -prerelease if the module is tagged as a prerelease version.
Rename the folder to just
the module name. For example, azurerm.storage.5.0.4-
preview becomes azurerm.storage .
5. Copy the folder to one of the folders in the $env:PSModulePath value .
$env:PSModulePath is a
semicolon-delimited set of paths in which PowerShell
should look for modules.
） Important
The manual download doesn't include any dependencies required by the module. If
the package has
dependencies, they must be installed on the system for this
module to work correctly. The
PowerShell Gallery shows all dependencies required
by the package.
Installing PowerShell scripts from a NuGet

package
７ Note
These instructions DO NOT give the same result as running Install-Script . These
instructions
fulfill the minimum requirements. They aren't intended to be a
replacement for Install-Script .
The easiest approach is to extract the NuGet package, then use the script directly.
The steps are as follows:
1. Unblock the Internet-downloaded NuGet package ( .nupkg ) file, for example using
Unblock-File -Path C:\Downloads\package.nupkg cmdlet.
2. Extract the contents of the NuGet package.

3. The .PS1 file in the folder can be used directly from this location.
4. You may delete the NuGet-specific elements in the folder.
For the list of NuGet-specific elements, see Using manual download to acquire a
package.
） Important
The manual download doesn't include any dependencies required by the module. If
the package has
dependencies, they must be installed on the system for this
module to work correctly. The
PowerShell Gallery shows all dependencies required
by the package.
Require license acceptance
Article • 04/17/2023
Require License Acceptance text shows up on item details page for modules that require
license
acceptance. License for module can be viewed by clicking on View License.txt
link.
Users will be prompted to accept the license when installing, saving or updating the
module through
PowerShellGet or when deploying to Azure Automation.
Require License Acceptance on Deploy to Azure

Automation
If the module being deployed to Azure Automation requires license acceptance, portal
UI will show a
disclaimer saying 'This module requires license acceptance. By clicking OK,
you are accepting
license terms.'
More details
Require License Acceptance in PowerShellGet
Azure Automation website
Contacting package owners
Article • 04/17/2023
To contact owner of a particular package, navigate to the package detail page. There is a
contact
Owners link in the left menu bar. Clicking on the link will take you to a new
page. You can send a
message from here.
PowerShell Gallery Account Settings
Article • 04/17/2023
Your PowerShell Gallery account is a publicly visible name that is linked to an identity.
That
identity is either a Microsoft ID, like user@hotmail.com or user@outlook.com , or an
Azure
Active Directory (AAD) account.
The PowerShell Gallery provides the following account settings:
The email account associated with your PowerShell Gallery account

Options for email notifications sent from the PowerShell Gallery
The user account associated with your PowerShell Gallery account
The picture associated with your PowerShell Gallery account
Email address
The email address is the destination for PowerShell Gallery notifications. It does not have
to
match the login account. You may use any email account you have access to. Your
email address is
never directly provided by the PowerShell Gallery to other users.
When you enter a new email address, the PowerShell Gallery sends a verification mail to
that
address. The verification mail contains a link back to the PowerShell Gallery to
complete the
change process. Until you complete the verification process, all
notifications are sent to the
previous address.
Email notifications
PowerShell Gallery provides the following notification options:
Users can contact me through the PowerShell Gallery

Notify me when an package is pushed to the PowerShell Gallery using my account
As noted on the page, critical notifications from the PowerShell Gallery can't be
disabled.
These include:
Security notifications
Account management notifications from PowerShell Gallery administrators
Notifications about the tests run by the PowerShell Gallery for submissions you
have made
Change your login account

To change the login account, you must be signed in with the current account. Use the
following
steps to complete the change.
1. Click on Change Account. A pop-up window explains that changing the login
account applies to
all uses of that account in the PowerShell Gallery. Review the
information, then click OK to
continue.
2. You are then prompted to sign in using the new account.

3. When you click Next, you see a message that you are signed in using the current
account.
Click Sign out and sign in with a different account.
4. Enter the password of the new account. After entering the password, you are
returned to the
Account Settings page showing you that the login account has
been updated.
Enable Two-Factor Authentication (2FA)
Two-factor authentication is recommended for all users who publish manually to the
PowerShell
Gallery. To enable two-factor authentication, the login account must have at
least two forms of
authentication registered. One is a password and the other forms can
be:
A phone number that can receive text messages

A registered authenticator application, such as Microsoft Authenticator for your
mobile phone
These forms of authentication must be configured in your AAD account information or

in your
Microsoft ID Account Security settings.
Once 2FA is enabled, you are required to authenticate using the configured forms of
authentication
every time you sign in to the PowerShell Gallery.
） Important
Enabling two-factor authentication for the PowerShell Gallery site does not require
you to enable
2FA for all uses of your login account. For more information, see
About two-step verification .
Change your profile picture

The PowerShell Gallery relies on Gravatar to store and display the picture associated
with your
profile. To update your profile image, visit Gravatar.com .
Managing API keys
Article • 04/17/2023
The PowerShell Gallery supports creating multiple API keys to support a range of
publishing
requirements. An API key can apply to one or more packages, grants specific
privileges, and has an
expiration date.
） Important
Users who published to the PowerShell Gallery prior to the introduction of scoped
API keys will
have a "Full access API key". The full access keys do not have the
security improvements built
into scoped API keys. The full access keys never expires
and apply to everything owned by the
user. If you delete this key, it cannot be
recreated.
The following image shows the options available when creating a scoped API key.
In this example, we created an API key named AzureRMDataFactory. This key value can
be used to
push packages with names that begin with 'AzureRM.DataFactory' and is
valid for 365 days. This is a
typical scenario when different teams within the same
organization work on different packages. The
members of the team have a key that
grants them privileges for the specific package they work on.
The expiration value
prevents the use of stale or forgotten keys.
Using glob patterns

If you work on multiple packages, you can use globbing patterns to match multiple
packages as a
group. API key permissions apply to all new packages matching the glob
pattern. For example, the
previous example uses a Glob Pattern value of
'AzureRM.DataFactory*'. You can push a package
named
'AzureRm.DataFactoryV2.Netcore' using this key since the package matches the glob
pattern.
Create API keys securely

For security, a newly created key value is never shown on the screen and is only
available with the
Copy button, as shown below.
） Important
You can only copy the API key value immediately after creating or refreshing it. It
will not be
displayed, and will not be accessible again after the page is refreshed. If
you lose the key
value, you must use Regenerate, and copy the key after it is
regenerated.
Key permissions and expiration

Scoped API keys can assign any of the following permissions:
Push new packages

Push new or update packages
Unlist packages
Every new key has an expiration. The expiration value is measured in days. The possible
values for expiration are:
1 day
90 days
180 days
270 days
365 days (default)
These settings cannot be changed once the key is created. You cannot create a new key
that never
expires.
Editing and deleting existing API keys

You can change some settings of an existing key. As previously noted, you cannot
modify the
security scope for an existing API key or change the expiration. The
changeable options are shown in
the following screenshot:
To change the packages controlled by a key, you can choose individual packages from
the list or
change the glob pattern.
Clicking Regenerate creates a new key value. Just like when you initially created the key,
you
must Copy the key value immediately after updating it. The Copy option is not
available
once you leave this page.
Clicking Delete displays a confirmation message. Once a key is deleted, it will be

unusable.
Key expiration
Ten days before the expiration, the PowerShell Gallery sends a warning email the
account holder of
the API key. After expiration, the key is unusable. A warning message
is displayed at the top of
the API key management page showing which keys are no
longer valid. You can generate a new key
value.
Working with Private PowerShellGet
Repositories
Article • 08/04/2023
The PowerShellGet module support repositories other than the PowerShell Gallery.
These cmdlets enable the following scenarios:
Support a trusted, pre-validated set of PowerShell modules for use in your

environment
Testing a CI/CD pipeline that builds PowerShell modules or scripts
Deliver PowerShell scripts and modules to systems that can't access the internet
Deliver PowerShell scripts and modules only available to your organization
This article describes how to set up a local PowerShell repository. The article also covers
the OfflinePowerShellGetDeploy module available from the PowerShell Gallery. This
module contains cmdlets to install the latest version of PowerShellGet into your local
repository.
Local repository types

There are two ways to create a local PSRepository: NuGet server or file share. Each type
has advantages and disadvantages:
NuGet Server
Advantages Disadvantages
Mimics PowerShellGallery functionality Multi-tier app requires operations planning & support
NuGet integrates with Visual Studio, Authentication model and NuGet accounts
other tools management needed
NuGet supports metadata in .Nupkg Publishing requires API Key management &
packages maintenance
Provides search, package administration,

etc.
File Share
Advantages Disadvantages
Easy to set up, back up, and maintain No UI beyond basic file share
Simple security model - user permissions on Limited security and no recording of who
the share updates what
No constraints such as replacing existing items
PowerShellGet works with either type and supports locating versions and dependency
installation. However, some features that work for the PowerShell Gallery aren't available
for base NuGet servers or file shares. There is no differentiation of scripts, modules, DSC
resources, or role capabilities.
Creating a NuGet.Server repository

The following article lists the steps for setting up your own NuGet Server.
NuGet.Server
Follow the steps up to the point of adding packages. The steps for publishing a package
are covered later in this article.
For a file share-based repository, make sure that your users have permissions to access
the file share.
Registering a local repository

Before a repository can be used, it must be registered using the Register-PSRepository
command. In the examples below, the InstallationPolicy is set to Trusted , on the
assumption that you trust your own repository.
PowerShell
# Register a NuGet-based server

$registerPSRepositorySplat = @{
Name = 'LocalPSRepo'
SourceLocation = 'http://MyLocalNuget/Api/V2/'
ScriptSourceLocation = 'http://MyLocalNuget/Api/V2'
InstallationPolicy = 'Trusted'
}
Register-PSRepository @registerPSRepositorySplat
# Register a file share on my local machine

$registerPSRepositorySplat = @{
Name = 'LocalPSRepo'
SourceLocation = '\\localhost\PSRepoLocal\'
ScriptSourceLocation = '\\localhost\PSRepoLocal\'
InstallationPolicy = 'Trusted'
}
Register-PSRepository @registerPSRepositorySplat
Take note of the difference between how the two commands handle
ScriptSourceLocation. For a file share-based repositories, the SourceLocation and
ScriptSourceLocation must match. For a web-based repository, they must be different,
so in this example a trailing "/" is added to the SourceLocation.
If you want the newly created PSRepository to be the default repository, you must
unregister all other PSRepositories. For example:
PowerShell
Unregister-PSRepository -Name PSGallery
７ Note
The repository name 'PSGallery' is reserved for use by the PowerShell Gallery. You
can unregister PSGallery, but you can't reuse the name PSGallery for any other
repository.
If you need to restore the PSGallery, run the following command:
PowerShell
Register-PSRepository -Default
Publishing to a local repository

Once you've registered the local PSRepository, you can publish to your local
PSRepository. There are two main publishing scenarios: publishing your own module
and publishing a module from the PSGallery.
Publishing a module you authored

Use Publish-Module and Publish-Script to publish your module to your local
PSRepository the same way you do for the PowerShell Gallery.
Specify the location for your code

Supply an API key
Specify the repository name. For example, -PSRepository LocalPSRepo
７ Note
You must create an account in the NuGet server, then sign in to generate and save
the API key. For a file share, use any non-blank string for the NuGetApiKey value.
Examples:
PowerShell
# Publish to a NuGet Server repository using my NuGetAPI key

$publishModuleSplat = @{
Path = 'c:\projects\MyModule'
Repository = 'LocalPsRepo'
NuGetApiKey = $nuGetApiKey
}
Publish-Module @publishModuleSplat
） Important
To ensure security, API keys shouldn't be hard-coded in scripts. Use a secure key
management system. When executing a command manually, API keys shouldn't be
passed as plain-text to avoid it being logged, the Read-Host cmdlet can be used to
safely pass the value of the API key.
PowerShell
# Publish to a file share repo - the NuGet API key must be a non-blank
string
Path = 'c:\projects\MyModule'
NuGetApiKey = 'AnyStringWillDo'
}
Publishing a module from the PSGallery

To publish a module from the PSGallery to your local PSRepository, you can use the
Save-Package cmdlet.
Specify the Name of the Package
Specify 'NuGet' as the Provider
Specify the PSGallery location as the source
( https://www.powershellgallery.com/api/v2 )
Specify the path to your local Repository
Example:
PowerShell
# Publish from the PSGallery to your local Repository

$savePackageSplat = @{
Name = 'PackageName'
ProviderName = 'NuGet'
Source = 'https://www.powershellgallery.com/api/v2'
Path = '\\localhost\PSRepoLocal\'
}
Save-Package @savePackageSplat
If your local PSRepository is web-based, it requires an additional step that uses

nuget.exe to publish. See the documentation for using nuget.exe.
Installing PowerShellGet on a disconnected

system
Deploying PowerShellGet is difficult in environments that require systems to be
disconnected from the internet. PowerShellGet has a bootstrap process that installs the
latest version the first time it's used. The OfflinePowerShellGetDeploy module in the
PowerShell Gallery provides cmdlets that support this bootstrap process.
To bootstrap an offline deployment, you need to:
Download and install the OfflinePowerShellGetDeploy your internet-connected

system and your disconnected systems
Download PowerShellGet and its dependencies on the internet-connected system
using the Save-PowerShellGetForOffline cmdlet
Copy PowerShellGet and its dependencies from the internet-connected system to
the disconnected system
Use the Install-PowerShellGetOffline on the disconnected system to place
PowerShellGet and its dependencies into the proper folders
The following commands use Save-PowerShellGetForOffline to put all the components

into a folder f:\OfflinePowerShellGet
PowerShell
# Requires -RunAsAdministrator
#Download the OfflinePowerShellGetDeploy to a location that can be accessed
# by both the connected and disconnected systems.
Save-Module -Name OfflinePowerShellGetDeploy -Path 'F:\' -Repository
PSGallery
Import-Module F:\OfflinePowerShellGetDeploy
# Put PowerShellGet somewhere locally

Save-PowerShellGetForOffline -LocalFolder 'F:\OfflinePowerShellGet'
At this point, you must make the contents of F:\OfflinePowerShellGet available to your
disconnected systems. Run the Install-PowerShellGetOffline cmdlet to install
PowerShellGet on the disconnected system.
７ Note
It's important that you don't run PowerShellGet in the PowerShell session before
running these commands. Once PowerShellGet is loaded into the session, the
components can't be updated. If you do start PowerShellGet by mistake, exit and
restart PowerShell.
PowerShell
Import-Module F:\OfflinePowerShellGetDeploy
Install-PowerShellGetOffline -LocalFolder 'F:\OfflinePowerShellGet'
After running these commands, you are ready to publish PowerShellGet to your local
repository.
PowerShell
# Publish to a NuGet Server repository using my NuGetAPI key

Path = 'F:\OfflinePowershellGet'
NuGetApiKey = $nuGetApiKey
}
） Important
To ensure security, API keys shouldn't be hard-coded in scripts. Use a secure key
management system. When executing a command manually, API keys shouldn't be
passed as plain-text to avoid it being logged, the Read-Host cmdlet can be used to
safely pass the value of the API key.
PowerShell
# Publish to a file share repo - the NuGet API key must be a non-blank
string
Path = 'F:\OfflinePowerShellGet'
NuGetApiKey = 'AnyStringWillDo'
}
Use Packaging solutions to host PowerShellGet

repositories
You can also use packaging solutions like Azure Artifacts to host a private or public
PowerShellGet repository. For more information and instructions, see the Azure Artifacts
documentation.
PowerShellGallery Publishing Guidelines
and Best Practices
Article • 04/17/2023
This article describes recommended steps used by Microsoft teams to ensure the
packages published to
the PowerShell Gallery will be widely adopted and provide high
value to users, based on how the
PowerShell Gallery handles manifest data and on
feedback from large numbers of PowerShell Gallery
users. Packages that are published
following these guidelines will be more likely to be installed,
trusted, and attract more
users.
Included below are guidelines for what makes a good PowerShell Gallery package, what
optional
Manifest settings are most important, improving your code with feedback from
initial reviewers and
Powershell Script Analyzer , versioning your module,
documentation, tests and examples for how to use what you have shared. Much of this
documentation
follows the guidelines for publishing
High Quality DSC Resource
Modules .
For the mechanics of publishing a package to the PowerShell Gallery, see

Creating and
Publishing a Package.
Feedback on these guidelines is welcomed. If you do have feedback, please open issues
in our
GitHub documentation repository .
Best practices for publishing packages

The following best practices are what the users of PowerShell Gallery items say is
important, and
are listed in nominal priority order. Packages that follow these guidelines
are far more likely to
be downloaded and adopted by others.
Use PSScriptAnalyzer
Include documentation and examples
Be responsive to feedback
Provide modules rather than scripts
Provide links to a project site
Tag your package with the compatible PSEdition(s) and platforms
Include tests with your modules
Include and/or link to license terms
Sign your code
Follow SemVer guidelines for versioning
Use common tags, as documented in Common PowerShell Gallery tags
Test publishing using a local repository
Use PowerShellGet to publish
Each of these is covered briefly in the sections below.
Use PSScriptAnalyzer
PSScriptAnalyzer is a free static
code analysis tool that works on PowerShell code.
PSScriptAnalyzer will identify the most common
issues seen in PowerShell code, and
often a recommendation for how to fix the issue. The tool is
easy to use, and categorizes
the issues as Errors (severe, must be addressed), Warning (need to be
reviewed and
should be addressed), and Information (worth checking out for best practices). All
packages published to the PowerShell Gallery will be scanned using PSScriptAnalyzer,
and any
errors will be reported back to the owner and must be addressed.
The best practice is to run Invoke-ScriptAnalyzer with -Recurse and -Severity

Warning.
Review the results, and ensure that:
All Errors are corrected or addressed in your documentation.

All Warnings are reviewed, and addressed where applicable.
Users who download packages from the PowerShell Gallery are strongly encouraged to
run
PSScriptAnalyzer and evaluate all Errors and Warnings. Users are very likely to
contact package
owners if they see that there's an error reported by PSScriptAnalyzer. If
there's a compelling
reason for your package to keep code that is flagged as an error,
add that information to your
documentation to avoid having to answer the same
question many times.
Include documentation and examples

Documentation and examples are the best way to ensure users can take advantage of
any shared code.
Documentation is the most helpful thing to include in packages published to the

PowerShell Gallery.
Users will generally bypass packages without documentation, as the
alternative is to read the code
to understand what the package is and how to use it.
There are several articles available about how
to provide documentation with
PowerShell packages, including:
Guidelines for providing help are in How to Write Cmdlet Help .
Creating cmdlet help, which is the best approach for any PowerShell script,
function, or cmdlet.
For information about how to create cmdlet help, start with
How to Write Cmdlet Help .
To add help within a script, see
About Comment
Based Help.
Many modules also include documentation in text format, such as MarkDown files.
This can be
particularly helpful when there's a project site in GitHub, where
Markdown is a heavily used
format. The best practice is to use GitHub-flavored
Markdown .
Examples show users how the package is intended to be used. Many developers will say
that they look
at examples before documentation to understand how to use something.
The best types of examples show
basic use, plus a simulated realistic use case, and the
code is well-commented. Examples for modules
published to the PowerShell Gallery
should be in an Examples folder under the module root.
A good pattern for examples can be found in the PSDscResource module

under the
Examples\RegistryResource folder. There are four sample use cases with a brief
description at the top of each file that documents what is being demonstrated.
Manage Dependencies
It's important to specify modules that your module is dependent on in the Module
Manifest. This
allows the end user to not have to worry about installing the proper
versions of modules that yours
take a dependency on. To specify dependent modules,
you should use the required module field in the
module manifest. This will load any
listed modules into the global environment prior to importing
your module unless
they've already been loaded. For example, some modules may already be loaded by a
different module. It's also possible to specify a specific version to load using the
RequiredVersion field rather than the ModuleVersion field. When using ModuleVersion,
it
will load the newest version available with a minimum of the version specified. When
not using the
RequiredVersion field, to specify a specific version it's important to
monitor version updates
to the required module. It's especially important to be aware of
any breaking changes that could
affect the user experience with your module.
PowerShell
Example: RequiredModules = @(@{ModuleName="myDependentModule";

ModuleVersion="2.0"; Guid="cfc45206-1e49-459d-a8ad-5b571ef94857"})
Example: RequiredModules = @(@{ModuleName="myDependentModule";

RequiredVersion="1.5"; Guid="cfc45206-1e49-459d-a8ad-5b571ef94857"})
Respond to feedback
Package owners who respond properly to feedback are highly valued by the community.
Users who
provide constructive feedback are important to respond to, as they're
interested enough in the
package to try to help improve it.
There is one feedback method available in the PowerShell Gallery:
Contact Owner: This allows a user to send an email to the package owner. As a
package owner, is
important to monitor the email address used with the
PowerShell Gallery packages, and respond to
issues that are raised. The one
disadvantage to this method is that only the user and owner will
ever see the
communication, so the owner may have to answer the same question many times.
Owners who respond to feedback constructively are appreciated by the community. Use
the opportunity
in the report to request more information. If needed, provide a
workaround, or identify if an update
fixes a problem.
If there's inappropriate behavior observed from either of these communication channels,

use the
Report Abuse feature of the PowerShell Gallery to contact the Gallery
Administrators.
Modules Versus Scripts

Sharing a script with other users is great, and provides others with examples of how to
solve
problems they may have. The issue is that scripts in the PowerShell Gallery are
single files without
separate documentation, examples, and tests.
PowerShell Modules have a folder structure that allows multiple folders and files to be
included
with the package. The module structure enables including the other packages
we list as best
practices: cmdlet help, documentation, examples, and tests. The biggest
disadvantage is that a
script inside a module must be exposed and used as a function.
For information on how to create a
module, see
Writing a Windows PowerShell Module.
There are situations where a script provides a better experience for the user, particularly
with DSC
configurations. The best practice for DSC configurations is to publish the
configuration as a script
with an accompanying module that contains the docs,
examples, and tests. The script lists the
accompanying module using RequiredModules =
@(Name of the Module) . This approach can be used with
any script.
Standalone scripts that follow the other best practices provide real value to other users.
Providing
comment-based documentation and a link to a Project Site are highly
recommended when publishing a
script to the PowerShell Gallery.
Provide a link to a project site
A Project Site is where a publisher can interact directly with the users of their PowerShell
Gallery
packages. Users prefer packages that provide this, as it allows them to get
information about the
package more easily. Many packages in the PowerShell Gallery
are developed in GitHub, others are
provided by organizations with a dedicated web
presence. Each of these can be considered a project
site.
Adding a link is done by including ProjectURI in the PSData section of the manifest as
follows:
# A URL to the main website for this project.
ProjectUri = 'https://github.com/powershell/powershell'
When a ProjectURI is provided, the PowerShell Gallery will include a link to the Project
Site on the
left side of the package page.
Tag your package with the compatible

PSEdition(s) and platforms
Use the following tags to demonstrate to users which packages will work well with their
environment:
PSEdition_Desktop: Packages that are compatible with Windows PowerShell

PSEdition_Core: Packages that are compatible with PowerShell 6 and higher
Windows: Packages that are compatible with the Windows Operating System
Linux: Packages that are compatible with Linux Operating Systems
MacOS: Packages that are compatible with the Mac Operating System
By tagging your package with the compatible platform(s) it will be included in the
Gallery search
filters on the left pane of the search results. If you host your package on
GitHub, when you tag
your package, you can also take advantage of our
PowerShell
Gallery compatibility shields
platform windows | linux | macos .
Include tests
Including tests with open-source code is important to users, as it gives them assurance
about what
you validate, and provides information on how your code works. It also
allows users to ensure they
don't break your original functionality if they modify your
code to fit their environment.
It's strongly recommended that tests be written to take advantage of the Pester test
framework,
which has been designed specifically for PowerShell. Pester is available in
GitHub , the
PowerShell Gallery , and ships in Windows 10,
Windows Server 2016,
WMF 5.0 and WMF 5.1.
The Pester project site in GitHub includes good documentation on

writing Pester tests,
from getting started to best practices.
The targets for test coverage are called out in the

High Quality Resource Module
documentation ,
with 70% unit test code coverage recommended.
Include and/or link to license terms

All packages published to the PowerShell Gallery must specify the license terms, or be
bound by the
license included in the Terms of Use under
Exhibit A. The best approach
to specifying a different license is to provide a link to the
license using the LicenseURI in
PSData. For more information, see
Packages manifest and Gallery UI.
PowerShell
PrivateData = @{
PSData = @{
# Tags applied to this module. These help with module discovery in

online galleries.
Tags = @('.net','acl','active-directory')
# A URL to the license for this module.
LicenseUri = 'http://www.apache.org/licenses/LICENSE-2.0'
Sign your code

Code signing provides users with the highest level of assurance for who published the
package, and
that the copy of the code they acquire is exactly what the publisher
released. To learn more about
code signing generally, see
Introduction to Code Signing.
PowerShell supports validation of code signing through two primary approaches:
Signing script files

Catalog signing a module
Signing PowerShell files is a well-established approach to ensuring that the code being
executed was
produced by a reliable source, and hasn't been modified. Details on how
to sign PowerShell script
files is covered in the
About Signing article. In
overview, a
signature can be added to any .PS1 file that PowerShell validates when the script is
loaded. PowerShell can be constrained using the
Execution Policy
cmdlets to ensure use
of signed scripts.
Catalog signing modules is a feature added to PowerShell in version 5.1. How to sign a
module is
covered in the
Catalog Cmdlets article.
In overview, catalog signing is done by
creating a catalog file, which contains a hash value for
every file in the module, and then
signing that file.
The PowerShellGet Publish-Module , Install-Module , and Update-Module cmdlets will

check the
signature to ensure it's valid, then confirm that the hash value for each
package matches what is in
the catalog. Save-Module doesn't validate a signature. If a
previous version of the module is
installed on the system, Install-Module will confirm
that the signing authority for the new
version matches what was previously installed.
Install-Module and Update-Module will use the
signature on a .PSD1 file if the package
isn't catalog signed. Catalog signing works with, but

doesn't replace signing script files.
PowerShell doesn't validate catalog signatures at module load
time.
Follow SemVer guidelines for versioning

SemVer is a public convention that describes how to structure and change a
version
to allow easy interpretation of changes. The version for your package must be included
in
the manifest data.
The version should be structured as three numeric blocks separated by periods, as

in 0.1.1 or
4.11.192 .
Versions starting with 0 indicate that the package isn't yet production ready, and
the first
number should only begin with 0 if that's the only number used.
Changes in the first number ( 1.9.9999 to 2.0.0 ) indicate major and breaking
changes between
the versions.
Changes to the second number ( 1.1 to 1.2 ) indicate feature-level changes, such
as adding new
cmdlets to a module.
Changes to the third number indicate non-breaking changes, such as new
parameters, updated
samples, or new tests.
When listing versions, PowerShell will sort the versions as strings, so 1.01.0 will be
treated
as greater than 1.001.0 .
PowerShell was created before SemVer was published, so it provides support for most
but not all
elements of SemVer, specifically:
It doesn't support prerelease strings in version numbers. This is useful when a

publisher wishes
to deliver a preview release of a new major version after
providing a version 1.0.0 . This will
be supported in a future release of the
PowerShell Gallery and PowerShellGet cmdlets.
PowerShell and the PowerShell Gallery allow version strings with 1, 2, and 4
segments. Many early
modules did not follow the guidelines, and product releases
from Microsoft include build
information as a 4th block of numbers (for example
5.1.14393.1066 ). From a versioning
standpoint, these differences are ignored.
Test using a local repository

The PowerShell Gallery isn't designed to be a target for testing the publishing process.
The best
way to test out the end-to-end process of publishing to the PowerShell Gallery
is to set up and use
your own local repository. This can be done in a few ways, including:
Set up a local PowerShell Gallery instance, using the

PS Private Gallery project in
GitHub. This
preview project will help you set up an instance of the PowerShell
Gallery that you can control,
and use for your tests.
Set up an
internal Nuget repository .
This will require more work to set up, but
will have the advantage of validating a few more of the
requirements, notably
validating use of an API key, and whether or not dependencies are present in
the
target when you publish.
Set up a file share as the test repository. This is easy to set up, but since it's a file
share, the validations noted above will not take place. One potential advantage in
this case is
that the file share doesn't check the required API key, so you can use
the same key you would use
to publish to the PowerShell Gallery.
With any of these solutions, use Register-PSRepository to define a new repository,

which you
use in the -Repository parameter for Publish-Module .
One additional point about test publishing: any package you publish to the PowerShell
Gallery can't
be deleted without help from the operations team, who will confirm that
nothing is dependent upon
the package you wish to publish. For that reason, we don't
support the PowerShell Gallery as a
testing target, and will contact any publisher who
does so.
Use PowerShellGet to publish

It's strongly recommended that publishers use the Publish-Module and Publish-Script
cmdlets when
working with the PowerShell Gallery. PowerShellGet was created to help
you avoid remembering
important details about installing from and publishing to the
PowerShell Gallery. On occasion,
publishers have chosen to skip PowerShellGet and use
the NuGet client, or
PackageManagement cmdlets, instead of Publish-Module . There
are a number of details that are
easily missed, which results in a variety of support
requests.
If there's a reason that you can't use Publish-Module or Publish-Script , please let us
know.
File an issue in the PowerShellGet GitHub repo, and provide the details that cause
you to choose
NuGet or PackageManagement.
Recommended workflow
The most successful approach we have found for packages published to the PowerShell
Gallery is this:
Do initial development in an open-source project site. The PowerShell Team uses

GitHub.
Use feedback from reviewers and PowerShell Script Analyzer to
get the code to
stable state.
Include documentation, so others know how to use your work.
Test out the publishing action using a local repository.
Publish a stable or Alpha release to the PowerShell Gallery, making sure to include
the
documentation and link to your project site.
Gather feedback and iterate on the code in your project site, then publish stable
updates to the
PowerShell Gallery.
Add examples and Pester tests in your project and your module.
Decide if you want to code sign your package.
When you feel the project is ready to use in a production environment, publish a
1.0.0 version
to the PowerShell Gallery.
Continue to gather feedback and iterate on your code based on user input.
Package metadata values that impact
the PowerShell Gallery UI
Article • 04/17/2023
This article explains how the metadata in your packages is used by the PowerShell
Gallery. For
modules, the metadata is stored in the module manifest. For scripts, the
metadata is store using
comment-based keywords. The following cmdlets are use to
create or update this metadata:
New-ModuleManifest
Update-ModuleManifest
New-ScriptFileInfo
Update-ScriptFileInfo
PowerShell Gallery feature elements controlled

by the module manifest
The following list shows the elements of the PowerShell Gallery package page UI that
are controlled
by the module manifest.
Title - The name of the package published to the Gallery.
Version - The version displayed is the version string in the metadata, and a
prerelease label
if is specified. The specified prerelease string is appended to the
ModuleVersion. For
information about prerelease strings in modules, see
Prerelease Module Versions.
Description - This is the Description in the module manifest.
Require license acceptance - A module can require that the user accept a license,
by setting
RequireLicenseAcceptance = $true , supplying a LicenseURI, and
providing a license.txt file
in the root of the module folder. For more
information, see Require License Acceptance.
Release notes - This information is comes from the ReleaseNotes section, under
PSData\PrivateData .
Owners - Owners are the list of users in the PowerShell Gallery who can update a
package. The
owner list isn't included in the package manifest. Additional
documentation describes how to
manage item owners.
Author - This is included in the module manifest as the Author. The Author field is
often
used to specify a company or organization associated with a package.
Copyright - This is the Copyright field in the module manifest.
FileList - The file list is created when the package is published to the PowerShell
Gallery.
It's not controllable by the manifest information. The PowerShell Gallery
creates .nuspec file
that appears in the file list of each package. This file isn't
installed with the package on a
system. This is the NuGet package manifest for the
package and can be ignored.
Tags - Tags are included under PrivateData\PSData in the module manifest. Tags
have
specific requirements and meanings that are described in the Tag Details
section.
Cmdlets - This is provided in the module manifest using CmdletsToExport. It's a

best
practice to explicitly list the cmdlet names rather than using the wildcard * .
Having a list
improves the load-module performance.
Functions - This is provided in the module manifest using FunctionsToExport. It's a

best
practice to explicitly list the cmdlet names rather than using the wildcard * .
Having a list
improves the load-module performance.
DSC Resources - This is provided in the manifest using DscResourcesToExport.

This value is
only supported for modules in PowerShell 5.0 and higher.
Role capabilities - Roles are listed when the module has one or more role
capability ( .psrc )
files. These files are used by JEA. For more information, see role
capabilities.
PowerShell Editions - For modules designed for PowerShell 5.0 and lower, this is
controlled
using Tags. For Desktop, use the tag PSEdition_Desktop, and for core,
use the tag
PSEdition_Core. For modules designed for PowerShell 5.1 and higher,
there is a
CompatiblePSEditions key in the manifest. For more information, see
PSEdition support for modules.
Dependencies - This is provided in the manifest using RequiredModules.
Minimum PowerShell version - This is provided in the manifest using

PowerShellVersion.
Version History - Shows a list of versions of the module that have been published
to the
Gallery. Packages hidden using the Delete feature aren't displayed in the
version history
unless you are a package owner.
Project Site - The project site is provided for modules in the PrivateData\PSData
section of
the module manifest by specifying a ProjectURI.
License - A license link is provided for modules in the PrivateData\PSData section

of the
module manifest by specifying a LicenseURI.
） Important
If a license isn't provided via the LicenseURI or within the package then the
Terms of Use
for the PowerShell Gallery apply to the package. For more
information, see the
Terms of Use .
Icon - A link is provided for modules in the PrivateData\PSData section of the

module
manifest by specifying an IconURI. The URI should point to an 85x85
image with transparency
background. The URI must be a direct link to the image
file and must not go to a web page
or a file in the PowerShell Gallery package.
PowerShell Gallery feature elements controlled

by the script metadata
The following list shows the elements of the PowerShell Gallery package page UI that
are controlled
by the comment-based metadata in a script file.
Title - This is the name of the package that is published to the Gallery
Version - The version displayed is the version string in the metadata, and a
prerelease label
if is specified. The value comes from the .VERSION keyword in the
metadata comment block. When
publishing prerelease script, append the
prerelease string to the version. For information about
specifying prerelease strings
in modules, see Prerelease versions of scripts.
Description - This information comes from the .DESCRIPTION keyword in the

comment-based help
of a script file.
Require license acceptance - License Acceptance is not supported for scripts.

However, the
scenario where a script depends on a module that requires license
acceptance is supported. For
more information, see Requiring license acceptance
for scripts.
Release notes - This information comes from the .RELEASENOTES keyword in the
comment-based
metadata of a script file.
Owners - Owners are the list of users in the PowerShell Gallery who can update a
package. The
owner list isn't included in the package manifest. For more
information, see
manage item owners.
Author - This information comes from the .AUTHOR keyword in the comment-
based metadata of a
script file. The Author field is often used to specify a company
or organization associated with a
package.
Copyright - This information comes from the .COPYRIGHT keyword in the

comment-based metadata
of a script file.
FileList - The file list is created when the package is published to the PowerShell
Gallery.
It's not controllable by the manifest information. The PowerShell Gallery
creates .nuspec file
that appears in the file list of each package. This file isn't
installed with the package on a
system. This is the NuGet package manifest for the
package and can be ignored.
Tags - *This information comes from the .TAGS keyword in the comment-based
metadata of a
script file. Tags have specific requirements and meanings that are
described in the
Tag Details section.
PowerShell Editions - For modules designed for PowerShell 5.0 and lower, this is
controlled
using Tags. For Desktop, use the tag PSEdition_Desktop, and for core,
use the tag
PSEdition_Core. For modules designed for PowerShell 5.1 and higher,
there is a
CompatiblePSEditions key in the manifest. For more information, see
PSEdition support for modules.
Version History - Shows a list of versions of the module that have been published
to the
Gallery. Packages hidden using the Delete feature aren't displayed in the
version history
unless you are a package owner.
Project Site - This information comes from the .PROJECTURI keyword in the
comment-based
metadata of a script file.
License - This information comes from the .LICENSEURI keyword in the comment-
based metadata
of a script file.
） Important
If a license isn't provided via the .LICENSEURI or within the package then the
Terms of Use
for the PowerShell Gallery apply to the package. For more
information, see the
Terms of Use .
Icon - This information comes from the .ICONURI keyword in the comment-based
metadata of a
script file. The URI should point to an 85x85 image with
transparency background. The URI must
be a direct link to the image file and must
not go to a web page or a file in the PowerShell
Gallery package.
Editing package details

The PowerShell Gallery Edit package page allows publishers to change several of the
fields displayed
for a package, specifically:
Title
Description
Summary
Icon URL
Project home page URL
Authors
Copyright
Tags
Release notes
Require license
You should only edit this information in the Gallery to correct what's displayed for an
older
version of a module. Users that download the package will see the metadata
doesn't match the
PowerShell Gallery. Any time you change information in the Gallery,
you should publish a new version
of the package with the same changes.
Tag details
Tags are simple strings consumers use to find packages. Tags are most valuable when
they're used
consistently across related packages. Using variations of the same word, for
example database and
databases or test and testing, provides little benefit. Tags are
single-word case-insensitive
strings and can't include blanks. If there is a phrase that
you believe users will search for, add
that to the package description so that it can be
found in the search results. Use Pascal casing,
hyphens, underscores, or periods to
improve readability. Be cautious about creating long, complex,
and unusual tags that are
easily misspelled.
The PowerShell Gallery and PowerShellGet cmdlets have special meanings for the
PSEdition_Desktop
and PSEdition_Core tags. See the preceding discussion of
PowerShell Editions.
As noted previously, tags provide the most value when they're specific, and used
consistently across
many packages. As a publisher trying to locate the best tags to use,
the easiest approach is to
search the PowerShell Gallery for tags you are considering.
Ideally, the packages returned align
with your use of that keyword.
The following table shows some of the most commonly used tags. The preferred tag
should return the
best search results.
Preferred tag Alternatives and notes
ActiveDirectory AD isn't currently used by itself
Appveyor
Automation
AWS
Azure
AzureAD
AzureAutomation
AzureRm Used primarily for the AzureRM modules
Backup
Build
ChatOps
Cloud
Color
Configuration
CrescendoBuilt This tag is added automatically by Crescendo when you export the
module
Database Databases (plural) is less desirable
DBA
Deployment Deploy is used somewhat less often
DevOps
DNS
Docker
DSC DesiredStateConfiguration is less desirable, it's too long
DSCResource
DSCResourceKit
Excel
Exchange
Firewall
GIT
GitHub
Gitlab
Google
HTML
Hyper-V HyperV is less common as a tag
IaaS
IIS
Json
Linux
Log Preferred use of Log as a thing
Logging Preferred use of logging as an action
MacOS
Monitoring
MSI
Network Networking is similar, less often used
Office365 Spelling out Office is preferable. O365 is less commonly used, although
shorter
PackageManagement
Pester
PoshBot
Report Report is a thing
Reporting Reporting is an action, report is a thing
ResourceManager "Arm" is used to describe group of processors, and shouldn't be used for
Azure Resource Manager
REST
Security Defense is less precise
SharePoint
SQL
SQLServer
Storage
Test Testing is less desirable
VersionControl Version is less precise, although used more frequently
VSTS
Windows
WinRM
WMI
Zip
Script with compatible PowerShell
editions
Article • 04/17/2023
Starting with version 5.1, PowerShell is available in different editions which denote
varying
feature sets and platform compatibility.
Desktop Edition: Built on .NET Framework and provides compatibility with scripts
and modules
targeting versions of PowerShell running on full footprint editions of
Windows such as Server
Core and Windows Desktop.
Core Edition: Built on .NET Core and provides compatibility with scripts and
modules
targeting versions of PowerShell running on reduced footprint editions of
Windows such as Nano
Server and Windows IoT.
The running edition of PowerShell is shown in the PSEdition property of

$PSVersionTable.
PowerShell
$PSVersionTable
Name Value
---- -----
PSVersion 5.1.14300.1000
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
CLRVersion 4.0.30319.42000
BuildVersion 10.0.14300.1000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Script authors can prevent a script from executing unless it is run on a compatible
edition of
PowerShell using the PSEdition parameter on a #requires statement.
PowerShell
Set-Content C:\script.ps1 -Value "#requires -PSEdition Core
Get-Process -Name PowerShell"
Get-Content C:\script.ps1
#requires -PSEdition Core
Get-Process -Name PowerShell
C:\script.ps1
C:\script.ps1 : The script 'script.ps1' cannot be run because it contained a

"#requires" statement for PowerShell editions 'Core'. The edition of
PowerShell that is required by the script does not match the currently
running PowerShell Desktop edition.
At line:1 char:1
+ C:\script.ps1
+ ~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (script.ps1:String) [],

RuntimeException
+ FullyQualifiedErrorId : ScriptRequiresUnmatchedPSEdition
PowerShell Gallery users can find the list of scripts supported on a specific PowerShell
Edition.
Scripts without PSEdition_Desktop and PSEdition_Core tags are considered to
work fine on PowerShell
Desktop edition.
PowerShell
# Find scripts supported on PowerShell Desktop edition
Find-Script -Tag PSEdition_Desktop
# Find scripts supported on PowerShell Core edition
Find-Script -Tag PSEdition_Core
More details
Modules with PSEditions
PSEditions support on PowerShellGallery
Modules with compatible PowerShell
Editions
Article • 04/17/2023
Starting with version 5.1, PowerShell is available in different editions, which denote
varying
feature sets and platform compatibility.
Desktop Edition: Built on .NET Framework, applies to Windows PowerShell v4.0

and below as well
as Windows PowerShell 5.1 on Windows Desktop, Windows
Server, Windows Server Core and most other
Windows editions.
Core Edition: Built on .NET Core, applies to PowerShell 6.0 and above as well as
Windows
PowerShell 5.1 on reduced footprint Windows Editions such as Windows
IoT and Windows Nano Server.
For more information on PowerShell editions, see

about_PowerShell_Editions.
Declaring compatible editions

Module authors can declare their modules to be compatible with one or more
PowerShell editions using
the CompatiblePSEditions module manifest key. This key is
only supported on PowerShell 5.1 or
later.
７ Note
Once a module manifest is specified with the CompatiblePSEditions key or uses the
$PSEdition
variable, it can not be imported on PowerShell v4 or lower.
PowerShell
New-ModuleManifest -Path .\TestModuleWithEdition.psd1 -CompatiblePSEditions

Desktop,Core -PowerShellVersion 5.1
$ModuleInfo = Test-ModuleManifest -Path .\TestModuleWithEdition.psd1
$ModuleInfo.CompatiblePSEditions
Output
Desktop
Core
PowerShell
$ModuleInfo | Get-Member CompatiblePSEditions
Output
TypeName: System.Management.Automation.PSModuleInfo
Name MemberType Definition
---- ---------- ----------
CompatiblePSEditions Property
System.Collections.Generic.IEnumerable[string] CompatiblePSEditions {get;}
When getting a list of available modules, you can filter the list by PowerShell edition.
PowerShell
Get-Module -ListAvailable -PSEdition Desktop
Output
Directory: C:\Program Files\WindowsPowerShell\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 1.0 ModuleWithPSEditions
PowerShell
Get-Module -ListAvailable -PSEdition Core | % CompatiblePSEditions
Output
Desktop
Core
Beginning in PowerShell 6, the CompatiblePSEditions value is used to decide if a module

is
compatible when modules are imported from
$env:windir\System32\WindowsPowerShell\v1.0\Modules .
This behavior only applies to
Windows. Outside of this scenario, the value is only used as metadata.
Finding compatible modules

PowerShell Gallery users can find the list of modules supported on a specific PowerShell
Edition
using tags PSEdition_Desktop and PSEdition_Core.
Modules without PSEdition_Desktop and PSEdition_Core tags are considered to work

fine on
PowerShell Desktop editions.
PowerShell
# Find modules supported on PowerShell Desktop edition
Find-Module -Tag PSEdition_Desktop
# Find modules supported on PowerShell Core editions
Find-Module -Tag PSEdition_Core
Targeting multiple editions

Module authors can publish a single module targeting to either or both PowerShell
editions (Desktop
and Core).
A single module can work on both Desktop and Core editions, in that module author
has to add
required logic in either RootModule or in the module manifest using
$PSEdition variable. Modules
can have two sets of compiled DLLs targeting both
CoreCLR and FullCLR. Here are the

packaging options with logic for loading proper
DLLs.
Option 1: Packaging a module for targeting multiple

versions and multiple editions of PowerShell
Module folder contents
Microsoft.Windows.PowerShell.ScriptAnalyzer.BuiltinRules.dll
Microsoft.Windows.PowerShell.ScriptAnalyzer.dll
PSScriptAnalyzer.psd1
PSScriptAnalyzer.psm1
ScriptAnalyzer.format.ps1xml
ScriptAnalyzer.types.ps1xml
coreclr\Microsoft.Windows.PowerShell.ScriptAnalyzer.BuiltinRules.dll
coreclr\Microsoft.Windows.PowerShell.ScriptAnalyzer.dll
en-US\about_PSScriptAnalyzer.help.txt
en-US\Microsoft.Windows.PowerShell.ScriptAnalyzer.dll-Help.xml
PSv3\Microsoft.Windows.PowerShell.ScriptAnalyzer.BuiltinRules.dll
PSv3\Microsoft.Windows.PowerShell.ScriptAnalyzer.dll
Settings\CmdletDesign.psd1
Settings\DSC.psd1
Settings\ScriptFunctions.psd1
Settings\ScriptingStyle.psd1
Settings\ScriptSecurity.psd1
Contents of PSScriptAnalyzer.psd1 file
PowerShell
@{
# Author of this module
Author = 'Microsoft Corporation'
# Script module or binary module file associated with this manifest.
RootModule = 'PSScriptAnalyzer.psm1'
# Version number of this module.
ModuleVersion = '1.6.1'
# ---
Below logic loads the required assemblies depending on the current edition or version.
Contents of PSScriptAnalyzer.psm1 file:
PowerShell
# Script module for module 'PSScriptAnalyzer'
Set-StrictMode -Version Latest
# Set up some helper variables to make it easier to work with the module
$PSModule = $ExecutionContext.SessionState.Module
$PSModuleRoot = $PSModule.ModuleBase
# Import the appropriate nested binary module based on the current

PowerShell version
$binaryModuleRoot = $PSModuleRoot
if (($PSVersionTable.Keys -contains "PSEdition") -
and ($PSVersionTable.PSEdition -ne 'Desktop')) {
$binaryModuleRoot = Join-Path -Path $PSModuleRoot -ChildPath 'coreclr'
else
if ($PSVersionTable.PSVersion -lt [Version]'5.0')
$binaryModuleRoot = Join-Path -Path $PSModuleRoot -ChildPath 'PSv3'
}
$binaryModulePath = Join-Path -Path $binaryModuleRoot -
ChildPath 'Microsoft.Windows.PowerShell.ScriptAnalyzer.dll'
$binaryModule = Import-Module -Name $binaryModulePath -PassThru
# When the module is unloaded, remove the nested binary module that was
loaded with it
$PSModule.OnRemove = {
Remove-Module -ModuleInfo $binaryModule
Option 2: Use $PSEdition variable in the PSD1 file to load

the proper DLLs
In PS 5.1 or newer, $PSEdition global variable is allowed in the module manifest file.
Using this
variable, module author can specify the conditional values in the module
manifest file. $PSEdition
variable can be referenced in restricted language mode or a
Data section.
Sample module manifest file with CompatiblePSEditions key.
PowerShell
@{
# Script module or binary module file associated with this manifest.
RootModule = if($PSEdition -eq 'Core')
'coreclr\MyCoreClrRM.dll'
}
else # Desktop
'clr\MyFullClrRM.dll'
# Supported PSEditions
CompatiblePSEditions = 'Desktop', 'Core'
# Modules to import as nested modules of the module specified in

RootModule/ModuleToProcess
NestedModules = if($PSEdition -eq 'Core')
'coreclr\MyCoreClrNM1.dll',
'coreclr\MyCoreClrNM2.dll'
else # Desktop
'clr\MyFullClrNM1.dll',
'clr\MyFullClrNM2.dll'
Module contents
ModuleWithEditions\ModuleWithEditions.psd1
ModuleWithEditions\clr\MyFullClrNM1.dll
ModuleWithEditions\clr\MyFullClrNM2.dll
ModuleWithEditions\clr\MyFullClrRM.dll
ModuleWithEditions\coreclr\MyCoreClrNM1.dll
ModuleWithEditions\coreclr\MyCoreClrNM2.dll
ModuleWithEditions\coreclr\MyCoreClrRM.dll
More details
Scripts with PSEditions
PSEditions support on PowerShellGallery
Update module manifest
about_PowerShell_Editions
Requiring license acceptance for scripts
Article • 04/17/2023
License Acceptance is not supported for scripts. However, the scenario where a script
depends on a
module that requires license acceptance is supported.
The PowerShellGet script commands support the parameter AcceptLicense that behaves
as though
user saw the license. If AcceptLicense is not specified the user is shown the
license.txt file
for dependent module and prompted to accept the license.
EXAMPLES
Example 1: Install Script with dependencies requiring

license acceptance
Script 'ScriptRequireLicenseAcceptance' depends on module
'ModuleRequireLicenseAcceptance'. User is
prompted to Accept License.
PowerShell
PS> Install-Script -Name ScriptRequireLicenseAcceptance
License Acceptance
MIT License 2.0
Copyright (c) 2016 PowerShell Team
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to

deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software.
Do you accept the license terms for module 'ModuleRequireLicenseAcceptance'.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "N"):
Example 2: Install Script with dependencies requiring

license acceptance and -AcceptLicense
Script 'ScriptRequireLicenseAcceptance' depends on module
'ModuleRequireLicenseAcceptance'. User is
not prompted to accept license as -
AcceptLicense is specified.
PowerShell
PS> Install-Script -Name ScriptRequireLicenseAcceptance -AcceptLicense
More details
Require License Acceptance support for Modules
Require License Acceptance support on PowerShellGallery
Require License Acceptance on Deploy to Azure Automation
Modules Requiring License Acceptance
Article • 04/17/2023
SYNOPSIS
Legal departments for some module publishers require that customers must explicitly
accept the
license before installing their module from PowerShell Gallery. If a user
installs, updates, or
saves a module using PowerShellGet, whether directly or as a
dependency for another package, and
that module requires the user to agree to a
license, the user must indicate they accept the license
or the operation fails.
Publish Requirements for Modules

Modules that would like to require users to accept license should fulfill following
requirements:
PSData section of module manifest should include RequireLicenseAcceptance =

$True.
Module should contain license.txt file in root directory.
Module manifest should contain License Uri.
Module should be published with PowerShellGet Format Version 2.0 and above.
Impact on Install/Save/Update-Module
Install/Save/Update cmdlets support a new parameter AcceptLicense that behaves
as though
the user saw the license.
If RequiredLicenseAcceptance is True and AcceptLicense is not specified, the user
is shown
the license.txt , and prompted with: Do you accept these license terms
(Yes/No/YesToAll/NoToAll) .
If the license is accepted
Save-Module: the module is copied to the user's system
Install-Module: the module is copied to the user's system to the proper
folder (based on
scope)
Update-Module: the module is updated.
If the license is declined.
Operation is canceled.
All cmdlets check for the metadata (requireLicenseAcceptance and Format
Version) that says
a license acceptance is required
If format version of client is older than 2.0, operation fails and asks the user
to update the
client.
If module was published with format version older than 2.0,
requireLicenseAcceptance flag is
ignored.
Module Dependencies
During Install/Save/Update operation, if a dependent module(something else
depends on the module)
requires license acceptance, then the license acceptance
behavior (above) is required.
If the module version is already listed in the local catalog as being installed on the
system, we
would bypass the license checking.
During Install/Save/Update operation, if a dependent module requires a license,
and the license
acceptance does not occur, the operation fails and follows normal
processes for the package
failed to install/save/update.
Impact on -Force
Specifying –Force is NOT sufficient to accept a license. –AcceptLicense is required for
permission to install. If –Force is specified, RequiredLicenseAcceptance is True, and
–
AcceptLicense is NOT specified, the operation fails.
EXAMPLES
Example 1: Update Module Manifest to require license

acceptance
PowerShell
Update-ModuleManifest -Path C:\modulemanifest.psd1 -RequireLicenseAcceptance

-PrivateData @{
PSData = @{
# Flag to indicate whether the module requires explicit user

acceptance
RequireLicenseAcceptance = $true
} # End of PSData hashtable
} # End of PrivateData hashtable
This command updates the manifest file and sets the RequireLicenseAcceptance flag to
true.
Example 2: Install Module requiring license acceptance
PowerShell
Install-Module -Name ModuleRequireLicenseAcceptance
Output
License Acceptance
License 2.0

deal
(default is "N"):
This command shows the license from license.txt file and prompts the user to accept
the license.

with -AcceptLicense
PowerShell
Install-Module -Name ModuleRequireLicenseAcceptance -AcceptLicense
Module is installed without any prompt to accept license.

with -Force
PowerShell
Install-Module -Name ModuleRequireLicenseAcceptance -Force
Output
PackageManagement\Install-Package : License Acceptance is required for
module 'ModuleRequireLicenseAcceptance'. Please specify '-AcceptLicense' to
perform this operation.
At C:\Program
Files\WindowsPowerShell\Modules\PowerShellGet\1.1.3.3\PSModule.psm1:1837
char:21
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument:
(Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], E
xception
+ FullyQualifiedErrorId : ForceAcceptLicense,Install-
PackageUtility,Microsoft.PowerShell.PackageManagement.Cmdlets
.InstallPackage
Example 5: Install Module with dependencies requiring

license acceptance
Module ModuleWithDependency depends on module
ModuleRequireLicenseAcceptance. User is
prompted to accept license.
PowerShell
Install-Module -Name ModuleWithDependency
Output
License Acceptance
MIT License 2.0

deal
(default is "N"):
Example 6: Install Module with dependencies requiring

license acceptance and -AcceptLicense
Module ModuleWithDependency depends on module
ModuleRequireLicenseAcceptance. User is not
prompted to accept license as
AcceptLicense is specified.
PowerShell
Install-Module -Name ModuleWithDependency -AcceptLicense
Example 7: Install module requiring license acceptance on

a client older than PSGetFormatVersion 2.0
PowerShell
Install-Module -Name ModuleRequireLicenseAcceptance
Output
WARNING: The specified module 'ModuleRequireLicenseAcceptance' with

PowerShellGetFormatVersion
'2.0' is not supported by the current version of PowerShellGet. Get the

latest version of the
PowerShellGet module to install this module,

'ModuleRequireLicenseAcceptance'.
Example 8: Save Module requiring license acceptance

PowerShell
Save-Module -Name ModuleRequireLicenseAcceptance -Path C:\Saved
Output
License Acceptance
License 2.0

deal
(default is "N"):
the license.
Example 9: Save Module requiring license acceptance

with -AcceptLicense
PowerShell
Save-Module -Name ModuleRequireLicenseAcceptance -AcceptLicense -Path

C:\Saved
Module is saved without any prompt to accept license.
Example 10: Update Module requiring license acceptance

PowerShell
Update-Module -Name ModuleRequireLicenseAcceptance
Output
License Acceptance
License 2.0

deal
(default is "N"):
the license.
Example 11: Update Module requiring license acceptance

with -AcceptLicense
PowerShell
Update-Module -Name ModuleRequireLicenseAcceptance -AcceptLicense
Module is updated without any prompt to accept license.
More details
Require License Acceptance for Scripts
Require License Acceptance support on PowerShellGallery
Require License Acceptance on Deploy to Azure Automation

Prerelease Module Versions
Article • 04/17/2023
Starting with version 1.6.0, PowerShellGet and the PowerShell Gallery provide support
for tagging
versions greater than 1.0.0 as a prerelease. Prior to this feature, prerelease
packages were limited
to having a version beginning with 0. The goal of these features
is to provide greater support for
SemVer v1.0.0 versioning convention without
breaking
backwards compatibility with PowerShell versions 3 and above, or existing
versions of
PowerShellGet. This topic focuses on the module-specific features. The
equivalent features for
scripts are in the Prerelease Versions of Scripts topic. Using these
features, publishers can identify a module or script as version 2.5.0-alpha, and later
release a
production-ready version 2.5.0 that supersedes the prerelease version.
At a high level, the prerelease module features include:
Adding a Prerelease string to the PSData section of the module manifest identifies
the module as
a prerelease version. When the module is published to the
PowerShell Gallery, this data is
extracted from the manifest, and used to identify
prerelease packages.
Acquiring prerelease packages requires adding -AllowPrerelease flag to the
PowerShellGet commands
Find-Module , Install-Module , Update-Module , and Save-
Module . If the flag is not specified,
prerelease packages will not be shown.
Module versions displayed by Find-Module , Get-InstalledModule , and in the

PowerShell Gallery
will be displayed as a single string with the Prerelease string
appended, as in 2.5.0-alpha.
Details for the features are included below.
These changes do not affect the module version support that is built into PowerShell,
and are
compatible with PowerShell 3.0, 4.0, and 5.
Identifying a module version as a prerelease

PowerShellGet support for prerelease versions requires the use of two fields within the
Module
Manifest:
The ModuleVersion included in the module manifest must be a 3-part version if a

prerelease
version is used, and must comply with existing PowerShell versioning.
The version format would be
A.B.C, where A, B, and C are all integers.
The Prerelease string is specified in the module manifest, in the PSData section of
PrivateData.
Detailed requirements on the Prerelease string are below.
An example section of a module manifest that defines a module as a prerelease would

look like the
following:
PowerShell
@{
ModuleVersion = '2.5.0'
#---
PrivateData = @{
PSData = @{
Prerelease = 'alpha'
The detailed requirements for Prerelease string are:
Prerelease string may only be specified when the ModuleVersion is 3 segments for
Major.Minor.Build. This aligns with SemVer v1.0.0.
A hyphen is the delimiter between the Build number and the Prerelease string. A
hyphen may be
included in the Prerelease string as the first character, only.
The Prerelease string may contain only ASCII alphanumerics [0-9A-Za-z-]. It is a
best practice to
begin the Prerelease string with an alpha character, as it will be
easier to identify that this
is a prerelease version when scanning a list of packages.
Only SemVer v1.0.0 prerelease strings are supported at this time. Prerelease string
must not
contain either period or + [.+], which are allowed in SemVer 2.0.
Examples of supported Prerelease string are: -alpha, -alpha1, -BETA, -
update20171020
Prerelease versioning impact on sort order and

installation folders
Sort order changes when using a prerelease version, which is important when publishing
to the
PowerShell Gallery, and when installing modules using PowerShellGet commands.
If the Prerelease
string is specified for two modules, the sort order is based on the string
portion following the
hyphen. So, version 2.5.0-alpha is less than 2.5.0-beta, which is less
than 2.5.0-gamma. If two
modules have the same ModuleVersion, and only one has a
Prerelease string, the module without the
Prerelease string is assumed to be the
production-ready version and will be sorted as a greater
version than the prerelease
version (which includes the Prerelease string). As an example, when
comparing releases
2.5.0 and 2.5.0-beta, the 2.5.0 version will be considered the greater of the
two.
When publishing to the PowerShell Gallery, by default the version of the module being
published
must have a greater version than any previously-published version that is in
the PowerShell
Gallery.
Finding and acquiring prerelease packages

using PowerShellGet commands
Dealing with prerelease packages using PowerShellGet Find-Module, Install-Module,
Update-Module, and
Save-Module commands requires adding the -AllowPrerelease
flag. If -AllowPrerelease is specified,
prerelease packages will be included if they are
present. If -AllowPrerelease flag is not specified,
The only exceptions to this in the PowerShellGet module commands are Get-
InstalledModule, and some cases with Uninstall-Module.
Get-InstalledModule always will automatically show the prerelease information in

the version
string for modules.
Uninstall-Module will by default uninstall the most recent version of a module, if
no version
is specified. That behavior has not changed. However, if a prerelease
version is specified using
-RequiredVersion, -AllowPrerelease will be required.
Examples
Assume the PowerShell Gallery has TestPackage module versions 1.8.0 and 1.9.0-alpha. If
-AllowPrerelease is not specified, only version 1.8.0 will be returned.
PowerShell
find-module TestPackage
Output
Version Name Repository Description
------- ---- ---------- -----------
1.8.0 TestPackage PSGallery Package used to validate changes

to the PowerShe...
PowerShell
find-module TestPackage -AllowPrerelease
Output
------- ---- ---------- -----------
1.9.0-alpha TestPackage PSGallery Package used to validate changes

to the PowerShe...
To install a prerelease, always specify -AllowPrerelease. Specifying a prerelease version

string is not sufficient.
PowerShell
Install-module TestPackage -RequiredVersion 1.9.0-alpha
Output
PackageManagement\Find-Package : No match was found for the specified search

criteria and module name 'TestPackage'.
Try Get-PSRepository to see all available registered module repositories.
At C:\Program
Files\WindowsPowerShell\Modules\PowerShellGet\1.6.0\PSModule.psm1:1455
char:3
+ PackageManagement\Find-Package @PSBoundParameters | Microsoft ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound:
(Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exception
+ FullyQualifiedErrorId :
NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindP
ackage
The previous command failed because -AllowPrerelease was not specified. Adding -
AllowPrerelease
will result in success.
PowerShell
Install-module TestPackage -RequiredVersion 1.9.0-alpha -AllowPrerelease
Get-InstalledModule TestPackage
Output
------- ---- ---------- -----------

to the PowerShe...
Side-by-side installation of versions of a module that differ only due to the prerelease
specified
is not supported. When installing a module using PowerShellGet, different
versions of the same
module are installed side-by-side by creating a folder name using
the ModuleVersion. The
ModuleVersion, without the prerelease string, is used for the
folder name. If a user installs
MyModule version 2.5.0-alpha, it will be installed to the
MyModule\2.5.0 folder. If the user then
installs 2.5.0-beta, the 2.5.0-beta version will
overwrite the contents of the folder

MyModule\2.5.0 . One advantage to this approach is
that there is no need to un-install the
prerelease version after installing the production-
ready version. The example below shows what to
expect:
PowerShell
C:\windows\system32> Get-InstalledModule TestPackage -AllVersions
------- ---- ---------- -----------

to the PowerShe...

to the PowerShe...
1.1.3.2 TestPackage PSGallery Package used to validate changes

to the PowerShe...
C:\windows\system32> find-module TestPackage -AllowPrerelease
------- ---- ---------- -----------
1.9.0-beta TestPackage PSGallery Package used to validate changes

to the PowerShe...
C:\windows\system32> Update-Module TestPackage -AllowPrerelease
------- ---- ---------- -----------

to the PowerShe...

to the PowerShe...

to the PowerShe...
Uninstall-Module will remove the latest version of a module when -RequiredVersion is

not supplied.
If -RequiredVersion is specified, and is a prerelease, -AllowPrerelease must
be added to the command.
PowerShell
------- ---- ---------- -----------
2.0.0-alpha1 TestPackage PSGallery Package used to validate changes

to the PowerShe...

to the PowerShe...

to the PowerShe...

to the PowerShe...
C:\windows\system32> Uninstall-Module TestPackage -RequiredVersion 1.9.0-

beta
Uninstall-Module : The '-AllowPrerelease' parameter must be specified when

using the Prerelease string in
MinimumVersion, MaximumVersion, or RequiredVersion.
At line:1 char:1
+ Uninstall-Module TestPackage -RequiredVersion 1.9.0-beta
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Uninstall-Module],

ArgumentException
AllowPrereleaseRequiredToUsePrereleaseStringInVersion,Uninstall-Module
C:\windows\system32> Uninstall-Module TestPackage -RequiredVersion 1.9.0-

beta -AllowPrerelease
------- ---- ---------- -----------
2.0.0-alpha1 TestPackage PSGallery Package used to validate changes

to the PowerShe...

to the PowerShe...

to the PowerShe...
C:\windows\system32> Uninstall-Module TestPackage
------- ---- ---------- -----------

to the PowerShe...

to the PowerShe...
More details
Prerelease Script Versions
Find-Module
Install-Module
Save-Module
Update-Module
Get-InstalledModule
UnInstall-Module
Prerelease versions of scripts
Article • 04/17/2023
Starting with version 1.6.0, PowerShellGet and the PowerShell Gallery provide support
for tagging
versions greater than 1.0.0 as a prerelease. Prior to this feature, prerelease
packages were limited
to having a version beginning with 0. The goal of these features
is to provide greater support for
SemVer v1.0.0 versioning convention without
breaking
backwards compatibility with PowerShell versions 3 and above, or existing
versions of
PowerShellGet. This topic focuses on the script-specific features. The
equivalent features for
modules are in the Prerelease Module Versions topic. Using these
features, publishers can identify a script as version 2.5.0-alpha, and later release a
production-ready version 2.5.0 that supersedes the prerelease version.
At a high level, the prerelease script features include:
Adding a PrereleaseString suffix to the version string in the script manifest. When
the scripts
is published to the PowerShell Gallery, this data is extracted from the
manifest, and used to
identify prerelease packages.
Acquiring prerelease packages requires adding -AllowPrerelease flag to the
PowerShellGet commands
Find-Script, Install-Script, Update-Script, and Save-
Script. If the flag is not specified,
Script versions displayed by Find-Script, Get-InstalledScript, and in the PowerShell
Gallery will
be displayed with the PrereleaseString, as in 2.5.0-alpha.
Details for the features are included below.
Identifying a script version as a prerelease

PowerShellGet support for prerelease versions is easier for scripts than modules. Script
versioning
is only supported by PowerShellGet, so there are no compatibility issues
caused by adding the
prerelease string. To identify a script in the PowerShell Gallery as a
prerelease, add a prerelease
suffix to a properly-formatted version string in the script
metadata.
An example section of a script manifest with a prerelease version would look like the
following:
PowerShell
<#PSScriptInfo
.VERSION 3.2.1-alpha12
.GUID
...
#>
To use a prerelease suffix, the version string must meet the following requirements:
A prerelease suffix may only be specified when the Version is 3 segments for
Major.Minor.Build.
This aligns with SemVer v1.0.0
The prerelease suffix is a string which begins with a hyphen, and may contain ASCII
alphanumerics
[0-9A-Za-z-]
Only SemVer v1.0.0 prerelease strings are supported at this time, so the prerelease
suffix
must not contain either period or + [.+], which are allowed in SemVer 2.0
Examples of supported PrereleaseString strings are: -alpha, -alpha1, -BETA, -
update20171020
Prerelease versioning impact on sort order and

installation folders
Sort order changes when using a prerelease version, which is important when publishing
to the
PowerShell Gallery, and when installing scripts using PowerShellGet commands. If
two scripts
versions with the version number exist, the sort order is based on the string
portion following the
hyphen. So, version 2.5.0-alpha is less than 2.5.0-beta, which is less
than 2.5.0-gamma. If two
scripts have the same version number, and only one has a
PrereleaseString, the script without
the prerelease suffix is assumed to be the
production-ready version and will be sorted as a greater
version than the prerelease
version. As an example, when comparing releases 2.5.0 and 2.5.0-beta,
the 2.5.0 version
will be considered the greater of the two.
When publishing to the PowerShell Gallery, by default the version of the script being
published
must have a greater version than any previously-published version that is in
the PowerShell
Gallery. A publisher may update version 2.5.0-alpha with 2.5.0-beta, or
with 2.5.0 (with no
prerelease suffix).
Finding and acquiring prerelease packages

using PowerShellGet commands
Dealing with prerelease packages using PowerShellGet Find-Script, Install-Script,
Update-Script, and
Save-Script commands requires adding the -AllowPrerelease flag. If -
AllowPrerelease is specified,
prerelease packages will be included if they are present. If -
AllowPrerelease flag is not specified,
The only exceptions to this in the PowerShellGet script commands are Get-
InstalledScript, and some
cases with Uninstall-Script.
Get-InstalledScript always will automatically show the prerelease information in the

version
string if it is present.
Uninstall-Script will by default uninstall the most recent version of a script, if no
version
is specified. That behavior has not changed. However, if a prerelease
version is specified using
-RequiredVersion , -AllowPrerelease will be required.
Examples
PowerShell
# Assume the PowerShell Gallery has TestPackage versions 1.8.0 and 1.9.0-
alpha.
# If -AllowPrerelease is not specified, only version 1.8.0 will be returned.
C:\windows\system32> Find-Script TestPackage
Version Name Repository

Description
------- ---- ---------- ----

-------
1.8.0 TestPackage PSGallery

Package used to validate changes to the PowerShe...
C:\windows\system32> Find-Script TestPackage -AllowPrerelease

Description
------- ---- ---------- ----

-------
1.9.0-alpha TestPackage PSGallery

Package used to validate changes to PowerShe...
# To install a prerelease, you must specify -AllowPrerelease. Specifying a

prerelease version string is not sufficient.
C:\windows\system32> Install-Script TestPackage -RequiredVersion 1.9.0-alpha
PackageManagement\Find-Package : No match was found for the specified search

criteria and script name 'TestPackage'.
Try Get-PSRepository to see all available registered script repositories.
At C:\Program
Files\WindowsPowerShell\Modules\PowerShellGet\1.6.0\PSModule.psm1:1455
char:3
+ PackageManagement\Find-Package @PSBoundParameters | Microsoft ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Microsoft.Power...ets.FindPackage:FindPackage)[Find-Package], Exception
NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindP
ackage
# The previous command failed because -AllowPrerelease was not specified.
# Adding -AllowPrerelease will result in success.
C:\windows\system32> Install-Script TestPackage -RequiredVersion 1.9.0-alpha

-AllowPrerelease
C:\windows\system32> Get-InstalledScript TestPackage

Description
------- ---- ---------- ---

--------

# Note that Get-InstalledScript shows the prerelease version.
# If -RequiredVersion is not specified, all installed scripts will be

displayed by Get-InstalledScript
Uninstall-Script will remove the current version of a script when -RequiredVersion is not
supplied.
If -RequiredVersion is specified, and is a prerelease, -AllowPrerelease must be
added to the command.
PowerShell
C:\windows\system32> Get-InstalledScript TestPackage

Description
------- ---- ---------- ---

--------

C:\windows\system32> Uninstall-Script TestPackage -RequiredVersion 1.9.0-

alpha
Uninstall-Script: The '-AllowPrerelease' parameter must be specified when

using the Prerelease string in
MinimumVersion, MaximumVersion, or RequiredVersion.
At line:1 char:1
+ Uninstall-Script TestPackage -RequiredVersion 1.9.0-beta
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Uninstall-Script],

ArgumentException
AllowPrereleaseRequiredToUsePrereleaseStringInVersion,Uninstall-script
C:\windows\system32> Uninstall-Script TestPackage -RequiredVersion 1.9.0-

alpha -AllowPrerelease
# Since script versions are not installed side-by-side, the above could be
simply "Uninstall-Script TestPackage"
C:\windows\system32> Get-Installedscript TestPackage
PackageManagement\Get-Package : No match was found for the specified search

criteria and script names 'testpackage'.
At C:\Program
Files\WindowsPowerShell\Modules\PowerShellGet\1.5.0.0\PSModule.psm1:4088
char:9
+ PackageManagement\Get-Package @PSBoundParameters | Microsoft. ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Microsoft.Power...lets.GetPackage:GetPackage) [Get-Package], Exception
NoMatchFound,Microsoft.PowerShell.PackageManagement.Cmdlets.GetPackage
More details
Prerelease Module Versions
Find-script
Install-script
Save-script
Update-script
Get-Installedscript
UnInstall-script
ScriptAnalyzer rule profile for Gallery
Article • 04/17/2023
To ensure the quality of packages published to PowerShell Gallery, we run

PSScriptAnalyzer rules to determine if there are
any violations in the scripts submitted.
You can find the list of rules we are running on ScriptAnalyzer

GitHub page .
If you
have any concerns regarding the rules we are running, please contact PowerShell Gallery
Administrators, or open an issue for ScriptAnalyzer.
ScriptAnalyzer results will be displayed on each individual package page in Gallery in the
coming
release. We encourage package owners to check their packages to make sure
there are no severe errors
in published packages.
Report abuse
Article • 04/17/2023
If you find a package that is in violation of any of these items, click the Report Abuse
link on
the package details page and submit a report.
Dispute resolution
Article • 04/17/2023
This document is a recommended dispute resolution process for community members

to help resolve
disputes with other PowerShell Gallery publishers.
Process
1. Contact the owners of the package you have the dispute with using the Contact
Owners link on
the package details page. Explain your issue in a kind and direct
manner.
2. Send a copy of your message to cgadmin@microsoft.com so that
PowerShell
Gallery Administrators are aware of your dispute.
3. Wait a maximum of 30 days and if you don't have resolution notify
cgadmin@microsoft.com again.
The PowerShellGallery.com support team will get involved and try to work this out.
Prohibited Use
The following things are not allowed on the public PowerShell Gallery and will be
immediately
removed without discussion. Package owners will be notified if their
package is removed.
Malware, adware, or any kind of spyware

Packages that are designed to harm the user systems;
Copyright infringement or license violation;
Illegal content;
"Squatting" on package names that you plan to use but are not actually using. This
also includes
publishing packages that have zero productive content. Either publish
code and get going or
concede the name to someone who actually has a product
to ship; and
Attempting to make the gallery do something that it is not explicitly designed to
do.
If you find a package that is in violation of any of these items, click the 'Report Abuse'
link on
the package details page and submit a report.
This policy is subject to change at the discretion of the PowerShell Gallery.

Contact Gallery administrators
Article • 04/17/2023
When to Contact Gallery Administrators

You should contact gallery administrators when:
1. You need to delete a package that you published.

2. You need help with your account.
3. You want to report an issue in the packages in the gallery.
4. You have package name dispute with other users and you are not able to resolve it
by contacting
the users.
5. You were contacted by Gallery Administrators, regarding your packages in the
gallery and you want
to respond.
How to Contact Gallery Administrators

1. Send us an email: cgadmin@microsoft.com.
2. If you are reporting abuse of a package, you can find Report Abuse link below the
package
information on the left panel.
3. For any other general questions regarding the Gallery, please submit your question
to the
PowerShell Gallery Issues
page on GitHub.
Troubleshooting cmdlets
Article • 04/17/2023
How to resolve "WARNING: Package 'your

package name' failed to download" issue
It is reported that Install-Module or Update-Module sometimes fails on some machines.
Based on
our investigation, it is something to do with the networking connection.
Recently we updated NuGet
provider so that it can reliably download packages. You can
follow the instructions below to install
the latest build of NuGet provider and then install
or update your module. Let's use 'Azure' module
as an example below.
PowerShell
Install-PackageProvider NuGet -MinimumVersion 2.8.5.206 -Force
Launch new PowerShell Console
Update-Module Azure -Verbose
Required network endpoints

The Install and Update cmdlets require internet access to connect to the network
endpoints used
by the PowerShell Gallery. Ensure that your network access policies
allow you to connect to the
following endpoints.
Hosts required for package discovery and download:
onegetcdn.azureedge.net - CDN hostname
psg-prod-centralus.azureedge.net - CDN hostname
psg-prod-eastus.azureedge.net - CDN hostname

az818661.vo.msecnd.net - CDN hostname
７ Note
The CDN for the PowerShell gallery is active for one name, psg-prod-
eastus.azureedge.net or
psg-prod-centralus.azureedge.net , at any given time. The
inactive name becomes the valid, active

name if there is a need to failover the
service. Therefore, both names should be included in your
allow lists.
Hosts required when using the PowerShell Gallery website:

devopsgallerystorage.blob.core.windows.net - storage account hostname
*.powershellgallery.com - website
go.microsoft.com - redirection service
７ Note
Cmdlets that interact with the PowerShell Gallery can fail with unexpected errors
when there is an
outage of the PowerShell Gallery services. To see the current status
of the PowerShell Gallery,
see the PowerShell Gallery Status
page on GitHub.
Bootstrap the NuGet provider and
NuGet.exe
Article • 04/17/2023
NuGet.exe is not included in the latest NuGet provider. For publish operations of either
a module
or script, PowerShellGet requires the binary executable NuGet.exe. Only the
NuGet provider is
required for all other operations, including find, install, save, and
uninstall.
PowerShellGet includes logic to handle either a combined bootstrap of the
NuGet provider and
NuGet.exe, or bootstrap of only the NuGet provider. In either case,
only a single prompt message
should occur. If the machine is not connected to the
Internet, the user or an administrator must
copy a trusted instance of the NuGet
provider and/or the NuGet.exe file to the disconnected
machine.
７ Note
Starting with version 6, the NuGet provider is included in the installation of

PowerShell.
Resolving error when the NuGet provider has

not been installed on a machine that is Internet
connected
PowerShell
Find-Module -Repository PSGallery -Verbose -Name Contoso
Output


Files\PackageManagement\ProviderAssemblies' or
'C:\Users\user1\AppData\Local\PackageManagement\ProviderAssemblies'. You can

also install the NuGet
provider by running 'Install-PackageProvider -Name NuGet -MinimumVersion

2.8.5.201 -Force'. Do you
want PowerShellGet to install and import the NuGet provider now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): n
Find-Module : NuGet provider is required to interact with NuGet-based

repositories. Please ensure
that '2.8.5.201' or newer version of NuGet provider is installed.
At line:1 char:1
+ Find-Module -Repository PSGallery -Verbose -Name Contoso
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Find-Module],

InvalidOperationException
+ FullyQualifiedErrorId : CouldNotInstallNuGetProvider,Find-Module
PowerShell
Find-Module -Repository PSGallery -Verbose -Name Contoso
Output


Files\PackageManagement\ProviderAssemblies' or
'C:\Users\user1\AppData\Local\PackageManagement\ProviderAssemblies'. You can

also install the NuGet
provider by running 'Install-PackageProvider -Name NuGet -MinimumVersion

2.8.5.201 -Force'. Do you
want PowerShellGet to install and import the NuGet provider now?
Version Name Type Repository

Description
------- ---- ---- ----------

-----------
2.5 Contoso Module PSGallery

Contoso module
Resolving error when the NuGet provider is

available and NuGet.exe is not available during
the publish operation on a machine that is
Internet connected
PowerShell
Publish-Module -Name Contoso -Repository PSGallery -Verbose
Output
NuGet.exe is required to continue
PowerShellGet requires NuGet.exe to publish an item to the NuGet-based
repositories. NuGet.exe must
be available under one of the paths specified in PATH environment variable

value. Do you want
PowerShellGet to install NuGet.exe now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): N
Publish-Module : NuGet.exe is required to interact with NuGet-based

repositories. Please ensure
that NuGet.exe is available under one of the paths specified in PATH

environment variable value.
At line:1 char:1
+ Publish-Module -Name Contoso -Repository PSGallery -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Publish-Module],

+ FullyQualifiedErrorId : CouldNotInstallNuGetExe,Publish-Module
PowerShell
Output
NuGet.exe is required to continue

PowerShellGet requires NuGet.exe to publish an item to the NuGet-based
repositories. NuGet.exe must
be available under one of the paths specified in PATH environment variable

value. Do you want
PowerShellGet to install NuGet.exe now?
VERBOSE: Installing NuGet.exe.
VERBOSE: Successfully published module 'Contoso' to the module publish

location 'https://www.powershellgallery.com/api/v2/'.
Please allow few minutes for 'Contoso' to show up in the search results.
Resolving error when both NuGet provider and

NuGet.exe are not available during the publish
operation on a machine that is Internet
connected
PowerShell
Output
NuGet.exe and NuGet provider are required to continue
PowerShellGet requires NuGet.exe and NuGet provider version '2.8.5.201' or

newer to interact with
the NuGet-based repositories. Do you want PowerShellGet to install both

NuGet.exe and NuGet provider
now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): N
Publish-Module : PowerShellGet requires NuGet.exe and NuGet provider version

'2.8.5.201' or newer
to interact with the NuGet-based repositories. Please ensure that

'2.8.5.201' or newer version of
NuGet provider is installed and NuGet.exe is available under one of the

paths specified in PATH
environment variable value.
At line:1 char:1
+ Publish-Module -Name Contoso -Repository PSGallery -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Publish-Module],

+ FullyQualifiedErrorId : CouldNotInstallNuGetBinaries,Publish-Module
PowerShell
Output
NuGet.exe and NuGet provider are required to continue
PowerShellGet requires NuGet.exe and NuGet provider version '2.8.5.201' or

newer to interact with
the NuGet-based repositories. Do you want PowerShellGet to install both

NuGet.exe and NuGet provider
now?
VERBOSE: Installing NuGet.exe.
VERBOSE: Successfully published module 'Contoso' to the module publish

location 'https://www.powershellgallery.com/api/v2/'.
Please allow few minutes for 'Contoso' to show up in the search results.
Manually bootstrapping the NuGet provider on

a machine that is not connected to the Internet
The processes demonstrated above assume the machine is connected to the Internet
and can download
files from a public location. If that is not possible, the only option is
to bootstrap a machine
using the processes given above, and manually copy the
provider to the isolated node through an
offline trusted process. The most common use
case for this scenario is when a private gallery is
available to support an isolated
environment.
After following the process above to bootstrap an Internet connected machine, you will
find
provider files in the location:
C:\Program Files\PackageManagement\ProviderAssemblies\
The folder/file structure of the NuGet provider will be (possibly with a different version
number):
NuGet
--2.8.5.208
----Microsoft.PackageManagement.NuGetProvider.dll
Copy these folders and file using a trusted process to the offline machines. To use the
provider on
the offline machine, it must be imported. Run the following command on
the offline machine:
PowerShell
Import-PackageProvider -Name NuGet
Manually bootstrapping NuGet.exe to support

publish operations on a machine that is not
connected to the Internet
In addition to the process to manually bootstrap the NuGet provider, if the machine will
be used to
publish modules or scripts to a private gallery using the Publish-Module or
Publish-Script
cmdlets, the NuGet.exe binary executable file will be required.
The most common use case for this scenario is when a private gallery is available to
support an
isolated environment. There are two options to obtain the NuGet.exe file.
One option is to bootstrap a machine that is Internet connected and copy the files to
the offline
machines using a trusted process. After bootstrapping the Internet connected
machine, the NuGet.exe
binary will be located in one of two folders:
If the Publish-Module or Publish-Script cmdlets were executed with elevated
permissions (As
an Administrator):
PowerShell
$env:ProgramData\Microsoft\Windows\PowerShell\PowerShellGet
If the cmdlets were executed as a user without elevated permissions:
PowerShell
$HOME\AppData\Local\Microsoft\Windows\PowerShell\PowerShellGet\
A second option is to download NuGet.exe from the NuGet.Org website:

https://dist.nuget.org/index.html When selecting a NugGet
version for production
machines, make sure it is later than 2.8.5.208, and identify the version
that has been
labeled "recommended". Remember to unblock the file if it was downloaded using a
browser. This can be performed by using the Unblock-File cmdlet.
In either case, the NuGet.exe file can be copied to any location in $env:PATH , but the
standard
locations are:
To make the executable available so that all users can use Publish-Module and
Publish-Script
cmdlets:
PowerShell
$env:ProgramData\Microsoft\Windows\PowerShell\PowerShellGet
To make the executable available to only a specific user, copy to the location within
only that
user's profile:
PowerShell
$HOME\AppData\Local\Microsoft\Windows\PowerShell\PowerShellGet\
PowerShell Gallery GDPR compliance

Article • 04/17/2023
Overview
In May 2018, a European privacy law, the General Data Protection Regulation (GDPR),
took effect. The
GDPR imposes new rules on companies, government agencies, non-
profits, and other organizations that
offer goods and services to people in the European
Union (EU), or that collect and analyze data tied
to EU residents. The GDPR applies no
matter where you are located.
７ Note
This article provides steps for how to delete personal data from the PowerShell
Gallery and can be
used to support your obligations under the GDPR. If you're
looking for general info about GDPR,
see the
GDPR section of the Service Trust
portal .
Personally identifiable data

The PowerShell Gallery stores the following information that may be provided by users,
which may
contain personal information:
PowerShell Gallery account

Packages published to the PowerShell Gallery
Email correspondence with the PowerShell Gallery team
Most users do not create a PowerShell Gallery account. An account is not required
unless you are
going to publish a package or use the "Contact Owner" feature in the
PowerShell Gallery. Other than
email correspondence initiated by the user, the
PowerShell Gallery does not store personally
identifiable data for users who have not
created an account.
Users who create a PowerShell Gallery account can publish packages to the PowerShell
Gallery. Those
packages are expected to be PowerShell code, but may contain other
information including personal
information. The information below will show how you
can get all the packages you have published to
the PowerShell Gallery.
DSR Export of PowerShell Gallery Data
The following sections describe how the PowerShell Gallery supports data subject
requests (DSR), by
explaining how to export information stored in the PowerShell
Gallery, and how to request deletion
of this information.
Email
Email correspondence may include any of the following:
Email sent to the owners of PowerShell Gallery packages if the code analysis scans
detected an
issue with any package they have published to the PowerShell Gallery
Email sent by anyone to the PowerShell Gallery team using the email address in the
"Contact Us"
page cgadmin@microsoft.com
Registered users who use the "Contact Owner" feature in the PowerShell Gallery to
send email to
the owner of a package in the PowerShell Gallery
Emails sent by or to the PowerShell Gallery have a retention policy of 90 days to support
possible
security investigations should malicious code be discovered on the PowerShell
Gallery. Emails are
deleted by policy after 90 days.
You may request copies of all emails sent to or from your email address and the
PowerShell Gallery
within the previous 90 days. To request this correspondence, send an
email to
cgadmin@microsoft.com, with the title: "DSR Request for emails
relating to this
account". In the body of the message, state what information you are requesting
(for
example: Please send all emails sent to or received from this email address.) All emails
involving your email address within 90 days of the request will be sent within 7 business
days.
PowerShell Gallery Account Information

If you have created a PowerShell Gallery account, you can find all personal information
that has
been stored in PowerShell Gallery by taking the following steps:
1. Sign in to the PowerShell Gallery, then click on your username

2. The next page displayed is the Account page, which shows the email address used
for the
PowerShell Gallery account
If you have created more than one account in the PowerShell Gallery, you will need to
repeat these
steps for each account.
Packages in the PowerShell Gallery

To facilitate exporting packages published to the PowerShell Gallery, we have published
the script
"GetPSGalleryItemsForAuthor" to the PowerShell Gallery. This script exports a
copy of every version
of every package put into the PowerShell Gallery based on the
author information stored in the
package.
７ Note
The Author is stored in the package manifest when you publish your package.
There is no guarantee
that the Author is the same identity as the account you use
in the PowerShell Gallery. If you use
some other value in the Author field, you will
need to supply that value when using this script.
You may download the script by using the following PowerShell command:
PowerShell
Save-Script Get-repository psgallery
You can then run the script directly, by running the following PowerShell commands:
PowerShell
# cd <local folder location>
.\GetPSGalleryItemsForAuthor.ps1
You will be prompted to supply the Author and a folder on your system where you want
the packages to
be saved.
Deleting Personal Data From The PowerShell

Gallery
To delete your PowerShell Gallery account or any package you own in the PowerShell
Gallery, send
email to cgadmin@microsoft.com with the title: "GDPR Request for items
relating to this account". In
the body of the message state what information you want
deleted. For example:
Please delete version x.y.z of my package "package name"

Please delete all versions of my package "package name"
Please delete my PowerShell Gallery account
The PowerShell Gallery administrators will reply within 7 business days.
The packages
specified will be deleted within 30 days after the request is sent.

Powershell Gallery Powershellget 2.x

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Powershell Gallery Powershellget 2.x

Uploaded by

Copyright:

Available Formats

Tell us about your PDF experience.

PowerShellGet and the PowerShell

For more information see:

Getting Started with the PowerShell Gallery

Current release - PowerShellGet 2.2.5 with PackageManagement 1.4.8.1

The 1.0.0.1 version of PowerShellGet has limited features and must be

PowerShell 6.0.0 shipped with PowerShellGet 1.6.0 and PackageManagement

PowerShell 7.0.0 shipped with PowerShellGet 2.2.3 and PackageManagement

PowerShell 7.4.0-preview.2 shipped with PowerShellGet 2.2.5 and

Future versions of PowerShell 7.4.0 will ship with

Microsoft.PowerShell.PSResourceGet is a standalone module and no longer

For best results, use the latest version of the Microsoft.PowerShell.PSResourceGet

Use the following command to see what version is installed.

Get-Module PowerShellGet, PackageManagement -ListAvailable

Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version Name ExportedCommands

Install the latest stable release

Install-Module PowerShellGet -Force -AllowClobber

Install the Preview release

Install-Module Microsoft.PowerShell.PSResourceGet -AllowClobber -

Installing the latest version of PowerShellGet

Install-Module installs the latest (non-prerelease) version of a module.

There are two ways to install the NuGet provider:

Use Install-PackageProvider to install NuGet before installing other modules

Run the following command to install the NuGet provider.

Install-PackageProvider -Name NuGet -Force

Let Install-Module prompt you to install the NuGet provider

The following command attempts to install the updated PowerShellGet module

Install-Module PowerShellGet -AllowClobber -Force

NuGet provider is required to continue

PowerShellGet requires NuGet provider version '2.8.5.201' or newer to

repositories. The NuGet provider must be available in 'C:\Program

NuGet provider by running 'Install-PackageProvider -Name NuGet -

[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y

VERBOSE: Installing NuGet provider.

After installing PowerShellGet

Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

For more information, see Set-PSRepository.

Older versions of Windows shipped with different versions of PowerShell. The

For more information, see the

For computers running PowerShell 3.0 or

For more information, see Save-Module.

Preparatory Step on computers running PowerShell 3.0

Open an elevated PowerShell session and run the following command:

For computers with the PackageManagement Preview

PackageManagement Preview was a downloadable component that made

Save-Module -Name PowerShellGet -Path C:\LocalFolder -Repository

2. Ensure that the PowerShellGet and PackageManagement modules aren't loaded

Remove-Item $targetDir\* -Recurse -Force

Copy-Item C:\LocalFolder\$_\*\* $targetDir\ -Recurse -Force

How to add credentials to repositories

Microsoft.PowerShell.PSResourceGet allows you to register private repositories that

Name Type VaultName

---- ---- ---------

JFrogCred PSCredential SecretStore

For more information about SecretManagement, see

Add a credential to a PSResourceRepository

Run Get-PSResourceRepository to see the registered repositories.

PS C:\Users > Get-PSResourceRepository

Publishing resources to the repository

Publish-PSResource -Path .\Get-Hello\ -Repository artifactory -ApiKey (Get-

Find-PSResource -Name Get-Hello -Repository artifactory

Name Version Prerelease Repository Description

---- ------- ---------- ---------- -----------

Copy-Item C:\LocalFolder\$_\\ $targetDir\ -Recurse -Force