User context, don't install to `%OneDriveCommercial%` if OneDrive for Business Known Folder Move (KFM) is enabled
See original GitHub issueSummary of the new feature / enhancement
Behavior today
Default install location for PowerShell scripts and modules when specifying user context, is:
- Windows PowerShell:
%USERPROFILE%\Documents\WindowsPowerShell\Modules
- PowerShell Core:
%USERPROFILE%\Documents\PowerShell\Modules
But if you have OneDrive for Business set up with Known Folder Move (KFM), default install location for user context is:
- Windows PowerShell:
%OneDriveCommercial%\Documents\WindowsPowerShell\Modules
- PowerShell Core:
%OneDriveCommercial%\Documents\PowerShell\Modules
Why is it a problem
This is not ideal, as you’ll end up with hundreds or thousands of small files that will be synced up and down to OneDrive, which might cause OneDrive sync issues, and other performance hits.
I currently install all modules to AllUsers scope for this reason. Currently 2.7 GB, 12 617 files, 2 315 folders.
Screenshot
If I did not care about this myself, I’d be using more than 1 / 10 of the capacity / max number of files recommendation for the OneDrive client, just for PowerShell modules.
Proposed technical implementation details
In my opinion, there is no reason to install PowerShell modules from PowerShell Gallery to OneDrive by default when KFM is active. A publicly available PowerShell module is nothing unique that needs to be backed up/ synced.
Option 1 - Don’t follow KFM redirect
It would be great if PowerShellGet just stuck with installing to:
- Windows PowerShell:
%USERPROFILE%\Documents\WindowsPowerShell\Modules
- PowerShell Core:
%USERPROFILE%\Documents\PowerShell\Modules
Option 2 - %LOCALAPPDATA%
Or better in my opinion, default location for user context modules should be:
- Windows PowerShell:
%LOCALAPPDATA%\WindowsPowerShell\Modules
- PowerShell Core:
%LOCALAPPDATA%\PowerShell\Modules
Issue Analytics
- State:
- Created a year ago
- Reactions:4
- Comments:11 (2 by maintainers)
Honestly, whether or not the changes in PowerShell/15552 are made, having a parameter set which gives us the ability to specify the
-InstallPath
instead of a-Scope
when callingInstall-PSResource
would allow users who really want or need to do this to just change their$Env:PSModulePath
and set a$PSDefaultParameterValues
to make it happen – without needing to learn to useSave-PSResource
instead.On company developer laptops, OneDrive routinely causes “Access to the cloud file is denied” errors when trying to upgrade modules there, and starts needlessly mirroring the files back to the cloud, slowing down install even more. Not to mention that every time I remove an old version of Az or Microsoft.Graph it causes that scary warning about how something has deleted thousands of files from my OneDrive…
Thanks @o-l-a-v we are planning to do a deeper dive into these (and other path) issues after our next release