Deploy Custom PowerShell Modules to an Enterprise

Hi,

We are looking to start using a number of various Custom PowerShell Modules in our business, some of which will be using during PS Remoting.

For this reason, I thought that it would be more efficient and convenient to have these custom modules deployed to “C:\Program Files\WindowsPowerShell\Modules” for quick use during Invoke-command and PS Remoting sessions.

I know that this can be easily achieved via Group Policy and the Replace File option or similar, but I don’t think that this would be very efficient

The other option would be to possibly use a logon script to check if the files differ and update them - again, I wasn’t sure if this would be practical.

Does anyone have any suggestions how we can deploy Custom PowerShell Modules centrally and keep them up-to-date in a timely manner with minimal administrative overhead?

My guess is that in the early days, we might update them to LIVE a couple times a week or month it would be great to barley worry about them and still have consistent functionality on each machine.

Any suggestions are greatly appreciated (my best is a logon script that checks to see if the modules have been modified)

Kind regards

Josh

The best approach would be to ensure you’ve deployed PowerShell Package Manager and PowerShellGet, and then set up a private PowerShell Gallery. Nodes can then use Install-Module and Update-Module (which can be run whenever you feel it’s needed) to pull modules down from your gallery. For example, scripts might proactively check for their dependencies as a first step, pull down whatever is needed, etc.

Obviously, DSC is another way to declare which modules a node should have, and to ensure they have the latest version.

But to more strongly make a point - I don’t think logon scripts are a good approach. You’ll be forever maintaining that script. Each script should check its own dependencies, which becomes a way of documenting, in the script, which modules the script depends on.

Hi Don,

Thank you very much for your suggestions, I think these could be a great choice when we get up to Version 5.0

Do you know of any enterprise level & supported products to use for a private PowerShell Gallery?
I can see that PSPrivateGallery and NuGet are popular, but without a paid and supported version, it could be hard to authorisation to get this into production.

Thanks again

Josh

Nope. Those are all open source technologies; I’m not aware of anyone marketing a paid version.

Appreciate your help!

All you need is a NuGet feed, there are a number of companies that offer paid versions. We use Artifactory in our enterprise which can do it.

Are you using Artifactory to mirror PowerShellGallery.com? I’m trying to accomplish this with a NuGet repo in Artifactory and am running into what I hope to be my last issue. I can register the repo and find modules, but when I try to install I get an error message stating “End of Central Directory record could not be found”.

Install-Module -Name AzureAD -Verbose -Scope CurrentUser -Force
VERBOSE: Using the provider 'PowerShellGet' for searching packages.
VERBOSE: The -Repository parameter was not specified.  PowerShellGet will use all of the registered repositories.
VERBOSE: Getting the provider object for the PackageManagement Provider 'NuGet'.
VERBOSE: The specified Location is 'https://(server name)/artifactory/api/nuget/vnuget' and PackageManagementProvider is 'NuGet'.
VERBOSE: Searching repository 'https://(server name)/artifactory/api/nuget/vnuget/FindPackagesById()?id='AzureAD'' for ''.
VERBOSE: Total package yield:'1' for the specified package 'AzureAD'.
VERBOSE: Performing the operation "Install-Module" on target "Version '2.0.1.16' of module 'AzureAD'".
VERBOSE: The installation scope is specified to be 'CurrentUser'.
VERBOSE: The specified module will be installed in 'C:\Users\(user name)\Documents\WindowsPowerShell\Modules'.
VERBOSE: The specified Location is 'NuGet' and PackageManagementProvider is 'NuGet'.
VERBOSE: Downloading module 'AzureAD' with version '2.0.1.16' from the repository 'https://(server name)/artifactory/api/nuget/vnuget'.
VERBOSE: Searching repository 'https://(server name)/artifactory/api/nuget/vnuget/FindPackagesById()?id='AzureAD'' for ''.
VERBOSE: InstallPackage' - name='AzureAD', version='2.0.1.16',destination='C:\Users\(user name)\AppData\Local\Temp\503539549'
VERBOSE: DownloadPackage' - name='AzureAD', version='2.0.1.16',destination='C:\Users\(user name)\AppData\Local\Temp\503539549\AzureAD\AzureAD.nupkg', uri='https://(server name):44
3/artifactory/api/nuget/vnuget/Download/AzureAD/2.0.1.16'
VERBOSE: Downloading 'https://(server name):443/artifactory/api/nuget/vnuget/Download/AzureAD/2.0.1.16'.
VERBOSE: Retry downloading 'https://(server name):443/artifactory/api/nuget/vnuget/Download/AzureAD/2.0.1.16' for '2' more times
VERBOSE: Download is incomplete. Downloaded '6950328' out of '6950328' bytes.
VERBOSE: Retry downloading 'https://(server name):443/artifactory/api/nuget/vnuget/Download/AzureAD/2.0.1.16' for '1' more times
VERBOSE: Download is incomplete. Downloaded '6950328' out of '6950328' bytes.
VERBOSE: Retry downloading 'https://(server name):443/artifactory/api/nuget/vnuget/Download/AzureAD/2.0.1.16' for '0' more times
VERBOSE: Download is incomplete. Downloaded '6950328' out of '6950328' bytes.
VERBOSE: Completed downloading 'AzureAD'.
VERBOSE: Hash for package 'AzureAD' does not match hash provided from the server.
VERBOSE: InstallPackageLocal' - name='AzureAD', version='2.0.1.16',destination='C:\Users\(user name)\AppData\Local\Temp\503539549'
PackageManagement\Install-Package : Package 'AzureAD' failed to be installed because: End of Central Directory record could not be found.
At C:\Users\(user name)\Documents\WindowsPowerShell\Modules\PowerShellGet\1.6.5\PSModule.psm1:9385 char:21