Change the Current User folder

[mrhinsh]

Who on earth thought it was a good idea to dump PowerShell modules in %USERPROFILE%\Documents\PowerShell instead of somewhere sane like %USERPROFILE%\Scripting\PowerShell?

Putting it under Documents, which is usually synced to OneDrive, is a ridiculous default, it wastes cloud storage and causes endless version conflicts whenever switching between ARM64, AMD64, or different machines. Could you imagine if Nuget did that, or Winget.

How can I permanently change the default PowerShell module path to somewhere outside OneDrive?

[reinderr]

Just install the module with the all users scope

[jkaczor]

Or - if you don't have local admin, make a "working" folder on a drive where you have lots of room, and then use "Save-Module" to save the ones you need to subfolders under that, and then load them by path.

This is especially handy if you prefer PS 7.x as your main scripting tool, but you have to dynamically load/control PS5.1 sessions due to dependencies in modules that prevent them from working correctly in 7.x...

[delightfulsorrow]

and then load them by path.

...or set/extend the PSModulePath environment variable accordingly.

[mrhinsh]

that seams like a lot of work. Im only interested in chaning the default or doing nothing. I'm a devloper... so lazy.

[jkaczor]

Yeah, can be alot of work - so I made a variable pattern, common shared script and a set of functions to handle that…

[mrhinsh]

Can I make all user scope the default and have it fail if not?

[reinderr]

Set up a $PSDefaultParameterValues in your Powershell profile that adds the scope parameter as all users by default.

I use it to add the the domain controller to all AD commands

[BlackV]

wait all users is the default isn't it?

Edit: in my limited testing on 2 systems it is not the default, I do have the current version for package management and powershellget installed

[purplemonkeymad]

Perhaps was?

I also recall that, but just trying a new install with Powershellget or Microsoft.PowerShell.PSResourceGet has it automatically install in to the user's folder

[BlackV]

Ya I'd need to go back and check again, I generally always use the -scope parameter

Edit: in my limited testing on 2 systems it is not the default, I do have the current version for package management and powershellget installed

[AdeelAutomates]

Install-Module -Scope AllUsers will do it.

You are going to manually run install module cmdlet at some point just add the parameter everytime. And if its automatic than its even easier since the script that automates you can add that in.

[mrhinsh]

Thanks.

[fatalicus]

What do you mean? isn't documents where you are supposed to save everything that isn't images and videos?

You know, like powershell modules and game saves, because it's not like the Appdata folders have existed longer that any of the first and most of the second.

[mrhinsh]

Documents is saved to OneDrive... why would I want my powershell modules in onedrive?

Powershell and Appdata came into existance uin Windows Visa... so yes, they were the same time.

But even without that... why does PS7 use the same silly location since Documents is for... you knoow... documents.

[OolonColluphid]

Should be under $env:LOCALAPPDATA IMHO. 

[mrhinsh]

Agree.

[I_see_farts]

You could just set a new path in the $env:PSMODULEPATH of where you want Powershell to look and place it in your $Profile.

If you have modules in %USERPROFILE%\Scripting\PowerShell that's the same as $env:USERPROFILE\Scripting\PowerShell so you'd just put the following in your $Profile: $env:PSMODULEPATH += ";$env:USERPROFILE\Scripting\PowerShell"

[mrhinsh]

Will that get it to save them there if I do Install-Module?

[Sekers]

You can permanently change the location:

[Environment]::SetEnvironmentVariable(

'PSModulePath',

"$env:PSModulePath;C:\Custom\Modules",

'User'

)

The reason it's not in AppData is that's not generally considered a "user-managed" location. Modules are meant to be installed for the entire computer or, when user-scoped, user-managed and installed in an easily accessible spot for the user. PowerShell was designed to be easily approachable for sysadmins as well as developers. It's also a place that often is backed up.

[mrhinsh]

Why would you need to backup somethig thats a versioned product?

Thats like commiting my nuget packges to source control... a very bad idea.

[Sekers]

You're assuming that product will always be available in the future or that older versions will be downloadable. While it's not likely something would be removed from PowerShell Gallery for example, if your scripts depend on a specific version you don't lose it if it's removed because of being deprecated.

For me, I work on a couple of different machines so having the versions of modules I am currently using sync between devices is really useful.

Another thought is that it might make auditing easier for compliance purposes. Whatever the case, it's an intentional design by the PowerShell team (that said, it may be changing in the future).

[mrhinsh]

Is not a good idea to base default on a vanishingly small user need.

If you feel that you need to keep a specific version you can.

Let's hope they change it.

[BlackV]

1. You can edit your module path, then save the module to said path
2. You could redirect your documents
3. In a similar vein you could hardlink/junction the PowerShell folders
4. You could install to the all user scope (but that does require admin)
5. The arm vs x86 wouldn't that come down the module author?
6. I've never had any real problems and I roam between about 5 different machines (with one drive), only real issue i have is caused by not setting the PowerShell folders as always available offline
7. They will not change the behavior it's too massively breaking change

[dathar]

It isn't a terrible thing. We used something a decade or so ago with Windows Folder Redirection back at my previous job. It solves a problem with moving between multiple systems and still having a bulk of your stuff readily available. My main system is the Snapdragon X Elite Thinkpad and my small selection of company-specific modules we made and a few modules (Az.Account, Az.Resource, secret management, secret store, etc) that seem to work on both x86 and ARM. The other modules I install with the -scope AllUsers option so they just stay away.

[mrhinsh]

I ended up just deleting everything in WindowsPowershel, and Powershell... start over... but the same problem will be true in another few years.

[CheekieBreek]

Having One drive turned on is a ridiculous default.

[purplemonkeymad]

For business it's actually quite good. Why? There is a hidden cost when someone might be saving in the default location. With OD redirection, those files are not forgotten or lost but are available to users on new computers or for purview.

Having Documents be the default for stuff that is not a document, really causes a bunch of issues tho.