So let's go back onto our Windows machine, and we'll first
retrieve the current execution policy, the one that's applied right now.
We'll then set the default execution policy,
which means it's going to go into the local computer one.
We'll then set a scoped execution policy. And then lastly,
we'll launch a new PowerShell session with a different
execution policy to the scoped and the default.
Okay, so we're back in the PowerShell window,
and this time what we want to be able to do is see
what the current execution policy is.
Now, the last time we went here,
we chose Get‑ExecutionPolicy, and if you remember,
we chose the word list, which gave us what our setting should actually be.
Now if we actually remove the list option and just press Enter,
it will actually return the specific setting for the
execution policy that we have as default,
which will be the local machine. Now, if I wanted
to change that as we did before, I could then say,
Set‑ExecutionPolicy Unrestricted, get the policy,
and it would return that value.
Now of course, as you can see every time I set the value,
it's only updating the local machine option, it isn't
making a change to any of the other scopes,
and that's because when we're defining a policy for a scope,
we actually have to pass the scope in place.
So let's just do Get‑ExecutionPolicy again with the list and we get
our list of Process, CurrentUser, and LocalMachine.
So right now, our default policy is unrestricted.
So I'm going to set this one back Set‑Execution to Restricted and you'll
see that means my local machine is now restricted.
What I'm then going to do is now set a scope level one
instead, so Set‑ExecutionPolicy.
I'm going to say ExecutionPolicy, let's do RemoteSigned, and then I'm going to
set the scope of that to CurrentUser, and then press Enter.
Now I'm going to go back and choose get the list.
Now you can see that we have two different types of
policies associated to two different scopes.
Now remember how we executed the test command, well the test PowerShell script,
what effect does that have now?
So if we say Test.ps1, notice that it executes. Why does it do that?
Because, of course, when we learned about precedence,
it will hit current user before it hits local machine and
it adopts the remote signed option,
which means that we're now able to execute that versus it being restricted.
So let's change that around a little bit.
So let me go back to here, CurrentUser, and we'll change the
ExecutionPolicy, so Restricted, and we'll say Scope is CurrentUser.
Then we'll also run this a little bit differently and we'll then
say Unrestricted ‑Scope LocalMachine. Now,
notice what's happened here.
It says PowerShell updated the policy successfully,
but the setting might be overridden by something else.
So let's have a look at the execution policy that we've got
like so. So now we can see that we have CurrentUser is
Restricted, LocalMachine is Unrestricted.
So now the question would be which one of those will actually happen.
So if we go back to our PowerShell script, notice what
happens, it gets blocked by the current user one,
even though the local machine one is completely
unrestricted so there is a practical example of precedence
of those things that are there. Now, of course,
what we can do is we can also try to run PowerShell with a specific policy.
So what I'm going to do here is just clear this and I'm actually going to go
to the menu here and just choose command prompt because what I want to be able
to do is actually launch PowerShell, so pwsh, and then what I'm going to do
here ExecutionPolicy and Unrestricted.
Now, notice what happened here.
I just told it to launch PowerShell inside a command prompt,
which we've done 1000 times.
Now what I'm going to do here is say get the execution
policy and notice its unrestricted.
Now, bear in mind,
the default policy for the machine was restricted, so for whatever reason,
when I ran it with the execution policy as unrestricted,
it now adopts that, so let's do Get‑ExecutionPolicy and list and
you'll see that process now has a value, current user has a
value, and local machine has a value.
Now, the process one only runs in the context of this kind of tab.
If I go to this tab here, and if I do Get‑ExecutionPolicy and
List, so you can see we have no process defined, so what should
happen is it should be restricted.
So I'm going to say Test,
which it does, but if I go back on this side and say Test,
it will execute.
So it's really important to understand where to assign those policies.
Do you assign them at the process level because it's just
going to work for that specific session,
or do we set them at the current user,
or do we just use the default options and put it as a local machine?
So depending the one that you choose will dictate whether the
script can actually execute or not, but in reality,
it's the same syntax. We're going to choose Get‑ExecutionPolicy to
retrieve the currently enforced one or we're going to do list to get
the list by policy and by scope, and then we can use Set‑ExecutionPolicy to choose what we would need.