Having a network profile causes many execution policy issues

[LarnuUK]

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-Icons

Actual 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.0

Visuals

No response

[mklement0]

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 $PROFILE locations without redirecting the well-known Documents folder as a whole; similarly, I think, the same applies to the user-specific target locations for Install-PSResource / Install-Module calls.

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:

• Move $PROFILE.CurrentUser* and friends out of documents #25097

• ... which led to Move PS content out of OneDrive PowerShell-RFC#388

[LarnuUK]

Sounds like, from what you're saying, that effectively PowerShell 7 simply isn't usable in (my) work environment, and many others, @mklement0 . The fact that OneDrive breaks the system should have given given Microsoft the hint. /Sigh

[mklement0]

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 User

What is the currently the preferred location of PowerShell profiles?

I'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...

[LarnuUK]

This isn't about OneDrive though, @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]

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 RemoteSigned yet you cannot execute unsigned *.ps1 files located on network shares, there must be something unusual about those shares (and I'm not the best person to dig deeper there).

[mklement0]

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]

the problem may be the presence of . in your hostname

Exactly, try using the netbios name (without any dots): <netbios>\home$\<user instead, see: Intranet site is identified as an Internet site when you use an FQDN or an IP address

[LarnuUK]

the problem may be the presence of . in your hostname

Exactly, try using the netbios name (without any dots): <netbios>\home$\<user instead, see: Intranet site is identified as an Internet site when you use an FQDN or an IP address

Switching to NetBios isn't an option. The point of the domain.local domain 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]

@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]

@LarnuUK,

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.

[LarnuUK]

Network Admin has tried a few things, including ensure that the <domain>.local path 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 in C:\Users\<username>\AppData or similar, the whole thing would be avoided for people in my position and those who use OneDrive.

[iRon7]

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 to RemoteSigned
• You place a Test.ps1 script (that contains a single command as Write-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 $Profile script (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 Overflow

PowerShell Script digitally signed error

I'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...

[LarnuUK]

Unblock-File doesn'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.