From 828a9810212c0eb6daa4f3ad4812fe81dd0ec307 Mon Sep 17 00:00:00 2001 From: Justin Chung Date: Thu, 3 Apr 2025 12:38:14 -0500 Subject: [PATCH 01/11] Add initial draft --- .../RFC0066-PowerShell-User-Content-Location | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Draft-Accepted/RFC0066-PowerShell-User-Content-Location diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location new file mode 100644 index 00000000..eb8e4927 --- /dev/null +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location @@ -0,0 +1,66 @@ +--- +RFC: RFC0066 +Author: Justin Chung +Status: Draft +SupercededBy: N/A +Version: 1.0 +Area: Core +Comments Due: 6/30/2022 +Plan to implement: Yes +--- + +# PowerShell User Content Location + +This RFC proposes moving the current PowerShell user content location out of OneDrive to the AppData directory on Windows machines. + +## Motivation + +- PowerShell currently places profile, modules, and configuration files in the user's Documents folder, which is against established conventions for shell configurations and tools. +- PowerShell content files in OneDrive causes unnecessary syncing of configuration files, leading to various issues. +- There is strong community demand for changing this behavior as the current setup is problematic for many users. +- Changing the default location would align PowerShell with other developer tools and improve usability. + + As a user, + I can customize the location of where PowerShell user content is installed, + so that I can choose to sync with OneDrive. + +## User Experience + +- On startup PowerShell will create a directory in AppData and a configuration file. +- In the configuration file the user scoped PSModulePath will point to AppData/PowerShell/Modules. +- Users can opt out of this new location by specifying a desired user scoped module path in the configuration file. + +## Specification + +- This change will only apply to PowerShell on Windows. +- This will be an experimental feature. +- The PowerShell user content folder will be located in the AppData. +- A configuration file in the PowerShell user content folder will determine the location of the user scoped PSModulePath. +- The user will be responsible for specifying thier desired install location using PSResourceGet. +- The location of Modules is configurable +- The location of this folder is not configurable. +- The proposed directory structure: + + C:\Users\UserName\AppData\Local\PowerShell\ + ├── Modules (Configurable) + ├── Scripts (Not Configurable) + ├── Profiles (Not Configurable) + └── PSModulePathConfig.json (Not Configurable) + +- The proposed json file: + + { + "PSModulePath" : "C:\\Users\\chungjustin\\PowerShell" + } + +## Alternate Proposals and Considerations + +- The following functionalities will be affected: + - Secret Management. +- Use the following script to relocate the PowerShell contents folder: + +```pwsh +$newPath = "C:\Custom\PowerShell\Modules" +$currentUserModulePath = [System.Environment]::GetFolderPath('MyDocuments') + "\PowerShell\Modules" +Move-Item -Path $currentUserModulePath -Destination $newPath -Force +``` From 9901f90696a70ebde6da39333fcd649134228ede Mon Sep 17 00:00:00 2001 From: Justin Chung Date: Thu, 3 Apr 2025 13:22:37 -0500 Subject: [PATCH 02/11] Fix date --- Draft-Accepted/RFC0066-PowerShell-User-Content-Location | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location index eb8e4927..66a33fb3 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location @@ -5,7 +5,7 @@ Status: Draft SupercededBy: N/A Version: 1.0 Area: Core -Comments Due: 6/30/2022 +Comments Due: 05/03/2025 Plan to implement: Yes --- From e9808dce41efef810c040342a16a6cc7e8a9c5a5 Mon Sep 17 00:00:00 2001 From: Justin Chung Date: Thu, 3 Apr 2025 14:34:19 -0500 Subject: [PATCH 03/11] Reword motivation and specification --- Draft-Accepted/RFC0066-PowerShell-User-Content-Location | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location index 66a33fb3..11bd5321 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location @@ -16,7 +16,7 @@ This RFC proposes moving the current PowerShell user content location out of One ## Motivation - PowerShell currently places profile, modules, and configuration files in the user's Documents folder, which is against established conventions for shell configurations and tools. -- PowerShell content files in OneDrive causes unnecessary syncing of configuration files, leading to various issues. +- PowerShell content files in OneDrive can lead to unwanted syncing of module files, leading to various issues. - There is strong community demand for changing this behavior as the current setup is problematic for many users. - Changing the default location would align PowerShell with other developer tools and improve usability. @@ -47,7 +47,7 @@ This RFC proposes moving the current PowerShell user content location out of One ├── Profiles (Not Configurable) └── PSModulePathConfig.json (Not Configurable) -- The proposed json file: +- The configuration file: { "PSModulePath" : "C:\\Users\\chungjustin\\PowerShell" From 60ee0ab0228f76a9739a88cb2f5fcd7627bb74d5 Mon Sep 17 00:00:00 2001 From: Justin Chung Date: Fri, 4 Apr 2025 11:47:11 -0500 Subject: [PATCH 04/11] Edits from first revision --- .../RFC0066-PowerShell-User-Content-Location | 36 +++++++++++-------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location index 11bd5321..05d9152a 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location @@ -21,8 +21,8 @@ This RFC proposes moving the current PowerShell user content location out of One - Changing the default location would align PowerShell with other developer tools and improve usability. As a user, - I can customize the location of where PowerShell user content is installed, - so that I can choose to sync with OneDrive. + I can customize the location where PowerShell user content is installed, + so that I can avoid problems created by file sunc solutions like OneDrive. ## User Experience @@ -32,9 +32,10 @@ This RFC proposes moving the current PowerShell user content location out of One ## Specification -- This change will only apply to PowerShell on Windows. +- The content folder location change will only apply to PowerShell on Windows. +- Configurability of the content folder will apply to all systems. - This will be an experimental feature. -- The PowerShell user content folder will be located in the AppData. +- The PowerShell user content folder will be located in the `$env:LOCALAPPDATA\Microsoft\PowerShell`. - A configuration file in the PowerShell user content folder will determine the location of the user scoped PSModulePath. - The user will be responsible for specifying thier desired install location using PSResourceGet. - The location of Modules is configurable @@ -43,24 +44,29 @@ This RFC proposes moving the current PowerShell user content location out of One C:\Users\UserName\AppData\Local\PowerShell\ ├── Modules (Configurable) - ├── Scripts (Not Configurable) - ├── Profiles (Not Configurable) + ├── Scripts (Configurable) + ├── profile.ps1 (Configurable) └── PSModulePathConfig.json (Not Configurable) - The configuration file: - { - "PSModulePath" : "C:\\Users\\chungjustin\\PowerShell" - } + ```json + { + "UserPSContentPath" : "C:\\Users\\User\\PowerShell" + } + ``` ## Alternate Proposals and Considerations - The following functionalities will be affected: - - Secret Management. + - SecretManagement + - SecretManagement extension vaults are registered for the current user context in: + `$env:LOCALAPPDATA\Microsoft\PowerShell\secretmanagement\secretvaultregistry\` + When an extension vault is registered, SecretManagement stores the full path to the extension module in the registry. Moving the PowerShell content to a new location will break the vault registrations. - Use the following script to relocate the PowerShell contents folder: -```pwsh -$newPath = "C:\Custom\PowerShell\Modules" -$currentUserModulePath = [System.Environment]::GetFolderPath('MyDocuments') + "\PowerShell\Modules" -Move-Item -Path $currentUserModulePath -Destination $newPath -Force -``` + ```pwsh + $newPath = "C:\Custom\PowerShell\Modules" + $currentUserModulePath = [System.Environment]::GetFolderPath('MyDocuments') + "\PowerShell\Modules" + Move-Item -Path $currentUserModulePath -Destination $newPath -Force + ``` \ No newline at end of file From 95798e03ffc0d710ab2722bf53f4466d3c024515 Mon Sep 17 00:00:00 2001 From: Justin Chung Date: Mon, 7 Apr 2025 13:15:36 -0500 Subject: [PATCH 05/11] Edits from second revision --- .../RFC0066-PowerShell-User-Content-Location | 21 ++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location index 05d9152a..dcb776c7 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location @@ -22,7 +22,7 @@ This RFC proposes moving the current PowerShell user content location out of One As a user, I can customize the location where PowerShell user content is installed, - so that I can avoid problems created by file sunc solutions like OneDrive. + so that I can avoid problems created by file sync solutions like OneDrive. ## User Experience @@ -43,10 +43,14 @@ This RFC proposes moving the current PowerShell user content location out of One - The proposed directory structure: C:\Users\UserName\AppData\Local\PowerShell\ - ├── Modules (Configurable) - ├── Scripts (Configurable) - ├── profile.ps1 (Configurable) - └── PSModulePathConfig.json (Not Configurable) + ├── PSContent (Configurable) + └── PSModulePathConfig.json (Not Configurable) + + PSContent (Configurable) + ├── Scripts (Not Configurable) + ├── Modules (Not Configurable) + ├── Help (Not Configurable) + └── profile.ps1 (Not Configurable) - The configuration file: @@ -61,8 +65,11 @@ This RFC proposes moving the current PowerShell user content location out of One - The following functionalities will be affected: - SecretManagement - SecretManagement extension vaults are registered for the current user context in: - `$env:LOCALAPPDATA\Microsoft\PowerShell\secretmanagement\secretvaultregistry\` - When an extension vault is registered, SecretManagement stores the full path to the extension module in the registry. Moving the PowerShell content to a new location will break the vault registrations. + `$env:LOCALAPPDATA\Microsoft\PowerShell\secretmanagement\secretvaultregistry\` + + When an extension vault is registered, SecretManagement stores the full path to the extension + module in the registry. Moving the PowerShell content to a new location will break the vault + registrations. - Use the following script to relocate the PowerShell contents folder: ```pwsh From f35150d8aaefea8711c3550d989921ebea51cbb8 Mon Sep 17 00:00:00 2001 From: Justin Chung Date: Tue, 8 Apr 2025 15:09:17 -0500 Subject: [PATCH 06/11] Added .md extension --- ...ent-Location => RFC0066-PowerShell-User-Content-Location.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename Draft-Accepted/{RFC0066-PowerShell-User-Content-Location => RFC0066-PowerShell-User-Content-Location.md} (99%) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md similarity index 99% rename from Draft-Accepted/RFC0066-PowerShell-User-Content-Location rename to Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md index dcb776c7..50d9fbe1 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md @@ -76,4 +76,4 @@ This RFC proposes moving the current PowerShell user content location out of One $newPath = "C:\Custom\PowerShell\Modules" $currentUserModulePath = [System.Environment]::GetFolderPath('MyDocuments') + "\PowerShell\Modules" Move-Item -Path $currentUserModulePath -Destination $newPath -Force - ``` \ No newline at end of file + ``` From e29eb580cf4bd9927ca7d851b6fd421b2a45471e Mon Sep 17 00:00:00 2001 From: Justin Chung <124807742+jshigetomi@users.noreply.github.com> Date: Mon, 16 Jun 2025 14:21:37 -0500 Subject: [PATCH 07/11] Edits from third revision --- ...FC0066-PowerShell-User-Content-Location.md | 113 ++++++++++++------ 1 file changed, 76 insertions(+), 37 deletions(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md index 50d9fbe1..b02325c4 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md @@ -5,62 +5,76 @@ Status: Draft SupercededBy: N/A Version: 1.0 Area: Core -Comments Due: 05/03/2025 +Comments Due: 07/31/2025 Plan to implement: Yes --- # PowerShell User Content Location -This RFC proposes moving the current PowerShell user content location out of OneDrive to the AppData directory on Windows machines. +This RFC proposes moving the current PowerShell user content location out of OneDrive to the +`AppData` directory on Windows machines. ## Motivation -- PowerShell currently places profile, modules, and configuration files in the user's Documents folder, which is against established conventions for shell configurations and tools. -- PowerShell content files in OneDrive can lead to unwanted syncing of module files, leading to various issues. -- There is strong community demand for changing this behavior as the current setup is problematic for many users. -- Changing the default location would align PowerShell with other developer tools and improve usability. - - As a user, - I can customize the location where PowerShell user content is installed, - so that I can avoid problems created by file sync solutions like OneDrive. - -## User Experience - -- On startup PowerShell will create a directory in AppData and a configuration file. -- In the configuration file the user scoped PSModulePath will point to AppData/PowerShell/Modules. -- Users can opt out of this new location by specifying a desired user scoped module path in the configuration file. +``` +As a user, +I can customize the location where PowerShell user content is installed, +so that I can avoid problems created by file sync solutions like OneDrive. +``` + +- PowerShell currently places profile, modules, and configuration files in the user's Documents + folder, which is against established conventions for shell configurations and tools. +- PowerShell content files in OneDrive can lead to unwanted syncing of module files, leading to + various issues. +- There is strong community demand for changing this behavior as the current setup is problematic + for many users. +- Changing the default location would align PowerShell with other developer tools and improve + usability. ## Specification -- The content folder location change will only apply to PowerShell on Windows. -- Configurability of the content folder will apply to all systems. - This will be an experimental feature. -- The PowerShell user content folder will be located in the `$env:LOCALAPPDATA\Microsoft\PowerShell`. -- A configuration file in the PowerShell user content folder will determine the location of the user scoped PSModulePath. -- The user will be responsible for specifying thier desired install location using PSResourceGet. -- The location of Modules is configurable -- The location of this folder is not configurable. +- The content folder location change will only apply to PowerShell on Windows. +- Configurability of the content folder will apply to all platforms. +- A configuration file in the PowerShell user content folder will determine the location of the user + scoped **PSModulePath**. + - By default, the PowerShell user content folder will be located in the + `$env:LOCALAPPDATA\Microsoft\PowerShell`. + - The new location becomes the location used as the `CurrentUser` scope for PSResourceGet. - The proposed directory structure: - C:\Users\UserName\AppData\Local\PowerShell\ - ├── PSContent (Configurable) - └── PSModulePathConfig.json (Not Configurable) + ``` + C:\Users\UserName\AppData\Local\PowerShell\ + ├── powershell.config.json (Not Configurable) + └── (Configurable) + ├── Scripts (Not Configurable) + ├── Modules (Not Configurable) + ├── Help (Not Configurable) + └── <*profile>.ps1 (Not Configurable) + ``` - PSContent (Configurable) - ├── Scripts (Not Configurable) - ├── Modules (Not Configurable) - ├── Help (Not Configurable) - └── profile.ps1 (Not Configurable) +- The following setting is added to the `powershell.config.json` file: -- The configuration file: + **UserPSContentPath** specifies the full path of the content folder. The default value is + `$env:LOCALAPPDATA\PowerShell\PSContent`. The user can change this value to a different path. ```json { - "UserPSContentPath" : "C:\\Users\\User\\PowerShell" + "UserPSContentPath" : "$env:LOCALAPPDATA\\PowerShell\\PSContent", } ``` -## Alternate Proposals and Considerations +## User Experience + +- On startup PowerShell will create a directory in AppData and a configuration file. +- The user scoped **PSModulePath** will point to `Modules` folder under the location specified by + **UserPSContentPath**. +- Users can configure a custom location for PowerShell user content by changing the value of + **UserPSContentPath**. +- Users will need to manually move/copy their existing PowerShell user content from the Documents + folder to the new location after enabling the feature. + +## Other considerations - The following functionalities will be affected: - SecretManagement @@ -70,10 +84,35 @@ This RFC proposes moving the current PowerShell user content location out of One When an extension vault is registered, SecretManagement stores the full path to the extension module in the registry. Moving the PowerShell content to a new location will break the vault registrations. -- Use the following script to relocate the PowerShell contents folder: + - Document instructions on how to re-register vaults after moving the content folder. + - Document the need to keep Modules in the Documents folder to so that SecretManagement + continues to work for multiple installs of PowerShell 7 (stable and preview). + +- Use the following script to copy the PowerShell contents folder: ```pwsh $newPath = "C:\Custom\PowerShell\Modules" - $currentUserModulePath = [System.Environment]::GetFolderPath('MyDocuments') + "\PowerShell\Modules" - Move-Item -Path $currentUserModulePath -Destination $newPath -Force + $currentUserModulePath = [System.Environment]::GetFolderPath('MyDocuments') + "\PowerShell" + Copy-Item -Path $currentUserModulePath -Destination $newPath -Recurse -Force ``` + +- PowerShellGet is hardcoded to install scripts and modules in the user's `Documents` folder. It + will not support this feature. + +## Implementation questions + +- Will the experimental feature be enabled by default? + - Recommendation: No, the user should explicitly enable the feature and copy their existing + PowerShell user content to the new location. + +- How does `$PROFILE` get populated? + - Can profile scripts be moved to `PSContent`? + - The feature needs to update `$PROFILE` to point to profile scripts in the new location. + +- What happens if **UserPSContentPath** is added to the machine-level configuration file in + `$PSHOME/powershell.config.json`? + - Recommendation: Ignore the setting in the machine-level configuration file since this is a user + setting. No error - just ignore it. + +- Will **UserPSContentPath** support environment variables (like `$env:USERNAME` or `%USERNAME%`)? + - This could enable a global configuration scenario if we allowed configuration in `$PSHOME`. From 239989a7d4e4a5b6399438cc2fe0b3a19053bfcf Mon Sep 17 00:00:00 2001 From: Justin Chung <124807742+jshigetomi@users.noreply.github.com> Date: Wed, 2 Jul 2025 11:41:06 -0500 Subject: [PATCH 08/11] Update Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md --- Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md index b02325c4..a232037a 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md @@ -12,7 +12,7 @@ Plan to implement: Yes # PowerShell User Content Location This RFC proposes moving the current PowerShell user content location out of OneDrive to the -`AppData` directory on Windows machines. +`LocalAppData` directory on Windows machines. ## Motivation From 310b1c59c641d4fa0a744ba54c34f5e2942d8d6e Mon Sep 17 00:00:00 2001 From: Justin Chung <124807742+jshigetomi@users.noreply.github.com> Date: Wed, 2 Jul 2025 11:44:14 -0500 Subject: [PATCH 09/11] Update Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md --- Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md index a232037a..3fc2cb1f 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md @@ -39,7 +39,7 @@ so that I can avoid problems created by file sync solutions like OneDrive. - A configuration file in the PowerShell user content folder will determine the location of the user scoped **PSModulePath**. - By default, the PowerShell user content folder will be located in the - `$env:LOCALAPPDATA\Microsoft\PowerShell`. + `$env:LOCALAPPDATA\PowerShell`. - The new location becomes the location used as the `CurrentUser` scope for PSResourceGet. - The proposed directory structure: From 1ea449f56bfcd11c6de2df625b78a18d0fbe248a Mon Sep 17 00:00:00 2001 From: Justin Chung <124807742+jshigetomi@users.noreply.github.com> Date: Mon, 21 Jul 2025 18:08:37 -0500 Subject: [PATCH 10/11] Fourth revision --- ...FC0066-PowerShell-User-Content-Location.md | 41 +++++++++++++------ 1 file changed, 28 insertions(+), 13 deletions(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md index b02325c4..28ffb93d 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md @@ -11,8 +11,8 @@ Plan to implement: Yes # PowerShell User Content Location -This RFC proposes moving the current PowerShell user content location out of OneDrive to the -`AppData` directory on Windows machines. +This RFC proposes moving the current PowerShell user content location out of OneDrive & +default to the `AppData` directory on Windows machines. ## Motivation @@ -20,6 +20,11 @@ This RFC proposes moving the current PowerShell user content location out of One As a user, I can customize the location where PowerShell user content is installed, so that I can avoid problems created by file sync solutions like OneDrive. + +As an Admin, +I must be able to customize the location set for my users either pre/during/post install, +so that I can better manage my environment and better secure and support my users, +to reduce unnecessary support tickets to my IT Team. ``` - PowerShell currently places profile, modules, and configuration files in the user's Documents @@ -46,21 +51,20 @@ so that I can avoid problems created by file sync solutions like OneDrive. ``` C:\Users\UserName\AppData\Local\PowerShell\ ├── powershell.config.json (Not Configurable) - └── (Configurable) - ├── Scripts (Not Configurable) - ├── Modules (Not Configurable) - ├── Help (Not Configurable) - └── <*profile>.ps1 (Not Configurable) + ├── Scripts (Configurable) + ├── Modules (Configurable) + ├── Help (Configurable) + └── <*profile>.ps1 (Configurable) ``` - The following setting is added to the `powershell.config.json` file: **UserPSContentPath** specifies the full path of the content folder. The default value is - `$env:LOCALAPPDATA\PowerShell\PSContent`. The user can change this value to a different path. + `$env:LOCALAPPDATA\PowerShell`. The user can change this value to a different path. ```json { - "UserPSContentPath" : "$env:LOCALAPPDATA\\PowerShell\\PSContent", + "UserPSContentPath" : "$env:LOCALAPPDATA\\PowerShell", } ``` @@ -71,8 +75,11 @@ so that I can avoid problems created by file sync solutions like OneDrive. **UserPSContentPath**. - Users can configure a custom location for PowerShell user content by changing the value of **UserPSContentPath**. -- Users will need to manually move/copy their existing PowerShell user content from the Documents - folder to the new location after enabling the feature. +- Users will initially need to manually move/copy their existing PowerShell user content + from the Documents folder to the new location after enabling the feature. +- We intend to add a new cmdlet to aid this process in a future release shortly + after this work has been completed as part of the work into hopefully the 7.6.0 GA + release or another 7.6.x release. Details on this to follow. ## Other considerations @@ -99,11 +106,19 @@ so that I can avoid problems created by file sync solutions like OneDrive. - PowerShellGet is hardcoded to install scripts and modules in the user's `Documents` folder. It will not support this feature. +- The following are required changes to PowerShell due to the content folder change: + - Profile path will need to use the API to get the content folder path. + - Updateable help path needs to use the API to get the content folder path. + - Scripts path will need to use the API to get the content folder path. + - Module path will ned to use the API to get the content folder path. + ## Implementation questions - Will the experimental feature be enabled by default? - - Recommendation: No, the user should explicitly enable the feature and copy their existing + - No, the user should explicitly enable the feature and copy their existing PowerShell user content to the new location. + - This feature is planned to be available on preview versions first then stable and LTS versions + later. - How does `$PROFILE` get populated? - Can profile scripts be moved to `PSContent`? @@ -111,7 +126,7 @@ so that I can avoid problems created by file sync solutions like OneDrive. - What happens if **UserPSContentPath** is added to the machine-level configuration file in `$PSHOME/powershell.config.json`? - - Recommendation: Ignore the setting in the machine-level configuration file since this is a user + - Ignore the setting in the machine-level configuration file since this is a user setting. No error - just ignore it. - Will **UserPSContentPath** support environment variables (like `$env:USERNAME` or `%USERNAME%`)? From 53e3c891a5ea9971384ece26b5d64c516afa25ee Mon Sep 17 00:00:00 2001 From: Justin Chung <124807742+jshigetomi@users.noreply.github.com> Date: Tue, 29 Jul 2025 14:17:42 -0500 Subject: [PATCH 11/11] Fifth Revision --- ...FC0066-PowerShell-User-Content-Location.md | 26 ++++++++++++++----- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md index a2344ce1..bf63e695 100644 --- a/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md +++ b/Draft-Accepted/RFC0066-PowerShell-User-Content-Location.md @@ -12,7 +12,7 @@ Plan to implement: Yes # PowerShell User Content Location This RFC proposes moving the current PowerShell user content location out of OneDrive & -default to the `AppData` directory on Windows machines. +default to the `LocalAppData` directory on Windows machines. ## Motivation @@ -70,7 +70,7 @@ to reduce unnecessary support tickets to my IT Team. ## User Experience -- On startup PowerShell will create a directory in AppData and a configuration file. +- On startup PowerShell will create a directory in AppData and a configuration file if they don't exist. - The user scoped **PSModulePath** will point to `Modules` folder under the location specified by **UserPSContentPath**. - Users can configure a custom location for PowerShell user content by changing the value of @@ -94,6 +94,7 @@ to reduce unnecessary support tickets to my IT Team. - Document instructions on how to re-register vaults after moving the content folder. - Document the need to keep Modules in the Documents folder to so that SecretManagement continues to work for multiple installs of PowerShell 7 (stable and preview). + - Provide a script to show users what vault modules are registered today and their hardcoded paths. - Use the following script to copy the PowerShell contents folder: @@ -106,11 +107,11 @@ to reduce unnecessary support tickets to my IT Team. - PowerShellGet is hardcoded to install scripts and modules in the user's `Documents` folder. It will not support this feature. -- The following are required changes to PowerShell due to the content folder change: - - Profile path will need to use the API to get the content folder path. - - Updateable help path needs to use the API to get the content folder path. - - Scripts path will need to use the API to get the content folder path. - - Module path will ned to use the API to get the content folder path. +- The following Path changes are required in PowerShell due to the content folder change & will be retrived via the API: + - Profile. + - Updateable Help. + - Scripts. + - Modules. ## Implementation questions @@ -131,3 +132,14 @@ to reduce unnecessary support tickets to my IT Team. - Will **UserPSContentPath** support environment variables (like `$env:USERNAME` or `%USERNAME%`)? - This could enable a global configuration scenario if we allowed configuration in `$PSHOME`. + - The string values will not be evaluated as a PowerShell expression. + +- Should the **UserPSContentPath** be an environmental variable? + +## Out of scope + +- Removal of PowerShellGet & PackageManagement due to being incompatible with this new feature. +- Provide a bypass mechanism for the precedence order of configuration files and allow admins a way of testing this + on managed devices. +- Machine level configurations should move to ProgramData on Windows out of program files. +- Allow separate configurations for Scripts, Modules, Help, and Profile.