This really opened a can of worms for me.
I was going to try to do some experiments along these lines.
By default all machines here use AllSigned.
So I had to temporarily set RemoteSigned.
When I tried to do it I got this message.
Set-ExecutionPolicy : Windows PowerShell updated your execution policy
successfully, but the setting is overridden by a policy defined at a
more specific scope. Due to the override, your shell will retain its
ffective execution policy of "AllSigned". For more information, please
see "Get-Help Set-ExecutionPolicy."
The help only mentions VISTA as needing any extra effort to change the
I'm an admin on this XP box.
The policy was set back when I was running V1 but now I've got CTP3
installed and I can't seem to change the policy.
What do I need to do? There is no 'run as admin' in XP.
Alex K. Angelopoulos at wrote:
> the "remote execution" issue I mention is something in this kind of
> scenario. Suppose you have access to a share on a remote system on the same
> LAN, but it's in a separate security domain (for example, two peered
> workstations where you get cross-system access transparently by having
> accounts with the same name and password available on both systems). If you
> have RemoteSigned as the execution policy on Computer 1 and then try to run
> a PowerShell script that physically resides on a visible share on Computer
> 2, I believe PowerShell squawks about it. I haven't tried that in quite a
> while and don't have a VM here to test it, so I may not remember this
> "Larry__Weiss" <lfw@xxxxxx> wrote in message
> > No.
> > I'm just trying to understand the principles of operation involved with
> > Set-ExecutionPolicy RemoteSigned
> > I'm pretty sure I now understand how NTFS participates (and FAT32
> > doesn't).
> > I don't understand what you mean by "remote load and execution".
> > - Larry
> > Alex K. Angelopoulos wrote:
> >> That's correct; PowerShell simply exploits this functionality as an extra
> >> layer of protection. The primary purpose of RemoteSigned, however, is to
> >> prevent remote load and execution across security domains. If you're
> >> trying to guarantee local integrity of files, the best option is to
> >> control the write permissions for the volume or enforce signing.
> >> Given the context, it sounds to me like the issue is that you're trying
> >> to create a secure flash drive with scripts for easy transport for
> >> on-site tech support. Is that what you're after?
> >> "Larry__Weiss" <lfw@xxxxxx> wrote...
> >>> So, if I download a script to a directory on a FAT32 volume,
> >>> this protection is not enforced by PowerShell.exe ?
> >>> Josh Einstein wrote:
> >>>> Microsoft has a convention for adding metadata to a file (through the
> >>>> use of NTFS alternate data streams I believe) that tag a file as having
> >>>> originated from the internet zone. For example, when Internet Explorer
> >>>> downloads a file, it attaches this metadata which is why you get the
> >>>> "always ask before launching this file" prompt when running an
> >>>> installer you downloaded from the internet but not one on a CD.
> >>>> Windows Live Messenger also adds this metadata for files received inIM
> >>>> conversations and I suspect FireFox 3.0 is probably doing it as wellby
> >>>> now. When you right click a file that originated from the internet and
> >>>> click properties, you see a button that says "unblock" and that removes
> >>>> the metadata so the file is treated normally.
> >>>> It's kind of a hacky version of Unix's "execute" file attribute.
> >>>> "Larry__Weiss" <lfw@xxxxxx> wrote...
> >>>>> At
> >>> http://www.microsoft.com/technet/scr...ionpolicy.mspx
> >>>>> it says of
> >>>>> Set-ExecutionPolicy RemoteSigned
> >>>>> RemoteSigned ï¿½ Downloaded scripts must be signed by a trusted
> >>>>> publisher
> >>>>> before they can be run.
> >>>>> How does PowerShell know that a script was downloaded?
> >>>>> What does "downloaded" mean in this context?