Give some way to configure psrepos via GPO or other method

[dotps1]

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

[bmanikm]

@dotps1 You can configure a logon PowerShell script with group policy to register/configure the custom repositories.

Some references on this.

• https://technet.microsoft.com/en-us/library/ee431705(v=ws.10).aspx

• https://blogs.technet.microsoft.com/heyscriptingguy/2011/01/06/use-powershell-and-group-policy-for-your-logon-script/

• https://technet.microsoft.com/en-us/library/cc753404(v=ws.11).aspx

• https://blogs.technet.microsoft.com/heyscriptingguy/2010/08/14/using-group-policy-to-deploy-a-windows-powershell-logon-script/

• http://www.computerperformance.co.uk/powershell/powershell3-logon-script.htm

• https://4sysops.com/archives/configuring-logon-powershell-scripts-with-group-policy/

• https://mcpmag.com/articles/2011/10/25/scripting-a-logon-with-powershell.aspx

• http://serverfault.com/questions/372061/how-do-i-execute-a-powershell-script-via-group-policy

[kilasuit]

Personally this sounds more like a cross org issue, and more specifically an issue that could be alleviated at the machine build time than it being a typical user issue, however you've pointed out the crux of the issue is that PowerShellGet currently only has the support for user settings not machine level settings.

In line with another conversation on customising module configurations like this over at https://github.com/PoshCode/PowerShellPracticeAndStyle/issues/79 , I would be more suggestive with either keeping the current CLIXML implementation and expanding it to be able to take multiple different configurations in a similar manner to how GPO's get applied or better still replace it's implementation with a model similar to what's being discussed in the Issue I've linked to above which also would be a suitable fix for what it is that you are looking for.

Once there is a Machine level configuration available for the PSRepositories then you could easily push a single configuration to all of your machines and not have to worry about a logon script though your would also need to update any machine build configurations that you have which would be simple enough with an additional small DSC Configuration or build task.

[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.

[Stephanevg]

Hi, has anything been done on this one? I am facing the same need as @dotps1

[edyoung]

No, not yet.

[vrdse]

I second that request

[BatmanAMA]

You can configure module repos in the default profile, which is how I do this.

D:\> $profile.AllUsersAllHosts
C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1

[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

[BatmanAMA]

@kilasuit - it also doesn't work if you launch powershell with -noprofile, to be fair. It isn't a security item, so I've never had too big of a problem with it not being perfect. My recommendation wasn't meant to dissuade this feature from being added, mainly I wanted to give an option for those looking to solve the problem now. It has the advantage over your first 2 in that it also works in PSCore on linux.

For a bit deeper detail, we use ansible to make sure the line we want is in the file so that if an admin changes the default profile, it'll just add my desired command to the end. I'd recommend checking out (and perhaps contributing to) the file content DSC project to get the same capability in DSC

- win_lineinfile:
    ensure: present
    create: yes
    path: C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
    line: 'register-psrepository -name internal -Source https://myinternalrepo.com/api/v2'

[sam-bryant]

+1 for this feature

[pkosek]

yes please! this is desparatelly needed.

[Stephanevg]

I agree with @kilasuit It is important that GPO is not the only way of setting a system wide repository to cover cases where machines are for example not in the same domain, or for workgroup machines. (Or any other reason for which admins cannot create / modify GPO's)

Ideally I would see this possible via a function looking somewhat similar to this:

Register-PSRepository -name internal -Source https://myinternalrepo.com/api/v2 -SystemWide

Of course -SystemWide is perhaps not the best name for something like this. But via a single swithc on the Register-PsRepository cmdlet would be really a helpfull feature IMHO.

[mwtrigg]

Of course -SystemWide is perhaps not the best name for something like this. But via a single swithc on the Register-PsRepository cmdlet would be really a helpfull feature IMHO.

Indeed, -Global is the probably the preferred option, to align with other related cmdlets and functions.

[SchulteMK]

any updates during the last two years?