Repository navigation
Having a network profile causes many execution policy issues #26121
Description
Activity
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:
In Windows, the location of the Documents folder can be changed by folder redirection or OneDrive.
We don't recommend redirecting the Documents folder to a network share or including it in OneDrive.
Redirecting the folder can cause modules to fail to load and create errors in your profile scripts.
For information about removing the Documents folder from OneDrive management, consult the OneDrive documentation.For efforts to decouple the locations of profile files and modules from the Documents folder, see:
- changed the title
[-]Having a network profile causes many execution poliocy issues[/-][+]Having a network profile causes many execution policy issues[/+]on 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
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
Super UserI've come across this (archived) Blog post on PowerShell profiles. In the learning docs I read a note that the scripts should not be stored on OneDrive. Users probably will use the standard setting...-
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.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).Actually, it's slowly coming back to me: the problem may be the presence of
.in your hostname; see the following:-
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
Reacted by iRon7the problem may be the presence of . in your hostname
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 addressReacted by Michael KlementReacted by Thom Athe problem may be the presence of . in your hostname
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 addressSwitching 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.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.
Before, discussing an possible (acceptable) solutions can you confirm that using a site without dot does indeed resolve the issue or not? 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.
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.
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.Network Admin has tried a few things, including ensure that the .local path is in Internet Options as a local intranet zone, still no joy
So basically, in a new PowerShell 7 session:
- You have the execution policy (
Get-ExecutionPolicy) set toRemoteSigned - You place a
Test.ps1script (that contains a single command asWrite-Host 'Hello world'into the concerned folder:
Set-Content -Path <your remote path without dots>\Test.ps1 -Value 'Write-Host "Hello world"'
- And run the file:
<your remote path without dots>\Test.ps1
You 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:Unblock-File -Path $Profile
Stack OverflowI'm getting an error when I run a PowerShell script: File test_new.ps1 cannot be loaded. The file test_new.ps1 is not digitally signed. I created a CA and a certificate and signed this file using...- You have the execution policy (
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.
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
Prerequisites
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$profilenow cannot be loaded, because the profile file isn't digitally signed.The only way I can see to change the path for
$profileis 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:
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: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
Error details
Environment data
Visuals
No response