Give some way to configure psrepos via GPO or other method

We use an internal NuGet feed to host a lot of our module/scripts for people in IT. but everytime they get on a new box, they need to register that repo, which is very cumbersome, it would be nice if the PSRepository was not stored in CLIXML because that makes it pretty cumbersome to try and deploy those settings. i guess a logon script to be used, but that seems like the wrong direction to go to accomplish this.

Expected Behavior

maybe allow to have a machine targeted repo, similar to how powershell profiles work, where we can deploy an internal default PSRepo to machines.

Current Behavior

currently the PSRepository is user based, so this makes it hard to setup an internal repo on multipule machines.

Possible Solution

see expected behavor

Steps to Reproduce (for bugs)

Context

as we publish more our scripts and build internal modules, that cannot be published publicaly, i need a way to configure our internal repo on all machines. so users can use install/find-module/script OOB.

Your Environment

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.14393.693
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.693
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Get-Module

Get-Module -ListAvailable PowerShellGet,PackageManagement

Get-PackageProvider

Get-PackageProvider -ListAvailable

[Glober777]

I’d really like if there was a machine level configuration as I don’t really like the idea of logon scripts, because they tend to increase the logon time experience, require someone to interactively login for them to apply, etc. Besides, those require additional efforts to make sure they’re running without issues.

If there’s a service account that is used to schedule a script that relies upon PackageManagement, currently one would need to make sure that the repo is pre-configured under that account.

If there concept of Machine level configuration is introduced, a rules regarding naming collisions would have to be introduced, to decide whether machine or user level settings should win if identically named PSRepos exist on both Machine and User levels. My personal preference would be to have machine level repos prevail on user level. There may, however, be valid scenarios for user level settings to prevail as well (although I can’t think of any), so this behavior should probably be configurable.

One other challenge with machine level settings is repo credentials. What would be the best way to configure those, so that they would survive things like sysprep (on windows), and yet not be stored in a plaintext format? Additionally, once set those credentials should be stored in a way that any user on the machine could use them to access a particular repository. Being able to provide PSRepo credentials would open up the possibility to use cloud based (private) repositories, i.e. VSTS Package Management, etc.

[kilasuit]

@BatmanAMA - whilst this is a workaround that will work to fix the issue, you are adding some unneeded overheard by using this option and this can also be removed by a user that has admin access on a machine.

Ideally I think that the end solution needs to have multiple methods to implement a Machine Level setting that can be via

• Registry Key
• GPO
• Configuration File’s
• PowerShellGet Command’s (Enhance Register-PSRepository & Set-PSRepository functions to include Machine level settings not just user level settings)
• DSC Resource