Repository navigation
Having a network profile causes many execution policy issues #26121
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
In my work environment, user profiles are stored on a network path, of the format \\<domain>.local\home$\<user name>. As of Powershell 7.5.3 my $profile now cannot be loaded, because the profile file isn't digitally signed.
The only way I can see to change the path for $profile is using the registry, which will impact for that just PowerShell, so isn't a solution.
I've instead tried switching to a different method, and using the following command to start PowerShell:
"C:\Program Files\PowerShell\7\pwsh.exe" -noprofile -noexit -command "invoke-expression '. ''C:\Users\<user name>\Powershell\Microsoft.PowerShell_profile.ps1''' "This, however, doesn't properly solve the problem, as modules are still installed using the path \\<domain>.local\home$\<user name>. This means, for example, that when importing some modules i get errors such as:
Import-Module: File \.local\home$<user name>\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1 cannot be loaded. The file \seib.local\Shares$\Home\tandrews\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1 is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at https://go.microsoft.com/fwlink/?LinkID=135170.
How do I change both the path the profile is stored, without a registry change that will impact other applications, and therefore ensure that my modules can be loaded.
Expected behavior
Import-Module -Name Terminal-IconsActual behavior
Import-Module -Name Terminal-Icons -Force
Import-Module: File \\<domain>.local\home$\<user name>\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1 cannot be loaded. The file \\seib.local\Shares$\Home\tandrews\PowerShell\Modules\Terminal-Icons\0.11.0\Terminal-Icons.psm1 is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at https://go.microsoft.com/fwlink/?LinkID=135170.Error details
Environment data
Name Value
---- -----
PSVersion 7.5.3
PSEdition Core
GitCommitId 7.5.3
OS Microsoft Windows 10.0.26100
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Visuals
No response
Activity
mklement0 commentedon Sep 30, 2025
Note that files on network share are usually treated the same as one stored on a local disk, so the effective execution policy should apply to both location types.
Have you tried
Set-ExecutionPolicy -Scope CurrentUser RemoteSigned -Force, for instance? This should work, unless your system's execution policies are controlled via GPOs.However, there is unfortunately no way to selectively change the
$PROFILElocations without redirecting the well-known Documents folder as a whole; similarly, I think, the same applies to the user-specific target locations forInstall-PSResource/Install-Modulecalls.Note that about_Profiles states:
For efforts to decouple the locations of profile files and modules from the Documents folder, see:
Move
$PROFILE.CurrentUser*and friends out of documents #25097... which led to Move PS content out of OneDrive PowerShell-RFC#388
[-]Having a network profile causes many execution poliocy issues[/-][+]Having a network profile causes many execution policy issues[/+]LarnuUK commentedon Oct 4, 2025
Sounds like, from what you're saying, that effectively PowerShell 7 simply isn't usable in (my) work environment, and many others, Michael Klement (@mklement0) . The fact that OneDrive breaks the system should have given given Microsoft the hint. /Sigh
mklement0 commentedon Oct 4, 2025
I wouldn't draw the same conclusion.
The execution-policy issues sounds unrelated to OneDrive / use of network shares; for general information, see the about_Execution_Policies help topic.
You can configure OneDrive to not manage the Documents folder, as noted; if that's not an option, my sense is that PowerShell will still typically work, albeit potentially with degraded interactive performance (based on the discussion at https://superuser.com/q/1830670/139307; I don't have personal knowledge) and with occasional module troubles due to syncing problems, as mentioned in Let's move PSModulePath out of the documents folder #15552
LarnuUK commentedon Oct 4, 2025
This isn't about OneDrive though, Michael Klement (@mklement0) , it's about that the documents are stored on the network (which OneDtive also does). And no, PowerShell 7 isn't usable as a result; as noted my profile cannot be loaded (my session is set to
RemoteSigned) and modules fail to import as well.mklement0 commentedon Oct 4, 2025
Ah, I got sidetracked by the docs talking about both OneDrive and network shares in general.
However, as noted, UNC network locations aren't normally treated as remote files - the latter only applies to browser-downloaded files from the internet.
So if your effective execution policy is
RemoteSignedyet you cannot execute unsigned*.ps1files located on network shares, there must be something unusual about those shares (and I'm not the best person to dig deeper there).mklement0 commentedon Oct 4, 2025
Actually, it's slowly coming back to me: the problem may be the presence of
.in your hostname; see the following:Execution Policy RemoteSigned interpreted differently in pwsh7.1 / Unblock-File does not work #13869 (comment):
There's a (languishing) up-for-grabs issue for implementing a whitelist for intranet servers: Add ability to configure internet zone server names for execution policy in PS v7 #12336
iRon7 commentedon Oct 5, 2025
Exactly, try using the netbios name (without any dots):
<netbios>\home$\<userinstead, see: Intranet site is identified as an Internet site when you use an FQDN or an IP addressLarnuUK commentedon Oct 6, 2025
Switching to NetBios isn't an option. The point of the
domain.localdomain is so that if the Network Admins move the share from one host to another, they only need update where the share points to. Use\\<hostname>would mean that everyone's settings would have to be updated if the share is moved.iRon7 commentedon Oct 6, 2025
Thom A (@LarnuUK),
Before jumping into any possible (acceptable) solutions can you confirm that using a site without dot does indeed resolve the issue or not? This would confirm whether we are on the right track. For a direction towards a solution, I guess you might simply add the sites to the Local intranet zone or to the Trusted sites zone.
LarnuUK commentedon Oct 6, 2025
Considering that there's no way to change where the PowerShell profile is stored, I have no way of testing if removing the
.or not will fix it; though if I could change where the PowerShell profile is stored I would just place it locally.On the trusted/local zones, I'm going to have a chat with our network admin tomorrow to double check the path is set up in them.
LarnuUK commentedon Oct 9, 2025
Network Admin has tried a few things, including ensure that the
<domain>.localpath is in Internet Options as a local intranet zone, still no joy. The "simple" solution is still what I see everyone say: PowerShell 7 should not be storing its profile is the "Documents" folder; they aren't documents. If this were inC:\Users\<username>\AppDataor similar, the whole thing would be avoided for people in my position and those who use OneDrive.iRon7 commentedon Oct 11, 2025
So basically, in a new PowerShell 7 session:
Get-ExecutionPolicy) set toRemoteSignedTest.ps1script (that contains a single command asWrite-Host 'Hello world'into the concerned folder:<your remote path without dots>\Test.ps1You get an error:
The file <your remote path without dots>\Test.ps1 is not digitally signed.?If not, but do get the error on just the concerned
$Profilescript (and other unsigned module script), make sure that those scripts aren't blocked, see e.g.: https://stackoverflow.com/a/76631885/1701026 in which case you might simply unblock the file:LarnuUK commentedon Oct 18, 2025
Unblock-Filedoesn't work either, iRon7 . I did try this previously and it states I have to be connected to the other host to run the command.As for the rest, using a different file isn't going to help as the profile is still "remote" (it's not). The share is treated, incorrectly, like it's not local. Nothing I've tried works so far; it seems like just a fatal flaw with PowerShell 7 to store it's settings in the Documents folder. As we all know, they aren't documents.
The ability to store the profile somewhere else fixes this; I'm unsure why there seems to be no way to tell PowerShell to store things elsewhere.
nlsdg commentedon Sep 18, 2026
I haven't seen it mentioned in this issue, but setting the ExecutionPolicy to Bypass should allow you to run any script without warning.
Does setting it to Bypass do anything for you?
Set-ExecutionPolicy Bypass ProcessPwsh.exe has a -ExecutionPolicy parameter, so you can start it in that configuration.
Also: what are the defined policies? Might be important to check, since you're not be able to override if they are defined at a higher precedence level. You can get them with the -List switch.
Get-ExecutionPolicy -List