Author Posts

September 23, 2016 at 5:33 pm

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

September 23, 2016 at 5:36 pm

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.

September 23, 2016 at 5:37 pm

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.

October 9, 2016 at 3:17 pm

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

October 9, 2016 at 4:13 pm

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

October 9, 2016 at 4:31 pm

Appreciate your help!

October 13, 2016 at 11:33 am

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.

July 5, 2018 at 1:21 pm

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