- After I've worked really hard building a command,
especially when it delivers reports
or does something very useful for my network,
the last thing I wanna do is have to memorize it
or ever type it again.
So, I'm gonna wanna script it.
And before we dive in to scripting,
we need to take a look at some of the
security around scripting.
First of all, PowerShell uses the Windows security model.
So, when you're running a script,
you're running it in, well, whoever you're logged in as.
So, if you have a script
and you're logged in as a regular user,
that may not provide you
with all of the permissions that you need.
That's why you need to be logged in as an administrator.
This is also good news.
It means that a user, if they attempt to run a script,
well, they're only gonna be able to do
whatever their Windows security lets them do.
In other words,
they're not gonna be able to reboot servers
unless you've already given them that security permission.
Now there is a bad news side to that is
you gotta make sure you check on
how your overall Windows security is implemented.
But for the most part,
it's a good safety measure.
Now scripts also don't launch by double-clicking on them.
This was a problem with VB scripts
where you could double-click it and just run it.
Now if you double-click it,
it does open it up in Notepad but it doesn't execute it.
Now, could that be changed?
Yes, if you know how to change
the file associations, you could change that.
Now I don't recommend that you do that as an administrator
and usually users either don't have the authority to do that
or don't know how to do that.
Now, script execution by default has been disabled,
but it is enabled for Server 2012 and above,
and I'll explain more about that in a little bit.
It has the ability to execute scripts.
This is kind of an important concept for everything else.
Clients and servers prior to that,
script execution is disabled.
And we're gonna have to get that script execution turned on
at least for the servers, if not for everything.
So, how do you change the script execution?
I'm gonna show you a manual way
to set your script execution policy
and explain some of the options that are available to you,
but I also want you to take notice
that you can do this through a group policy.
And so, in a normal network environment,
what I would do is implement a group policy
for the servers that would enable the correct
execution policy that I'm gonna show you.
You can also do this for the clients.
It's a much easier way,
rather than running around every single machine
and typing it in.
Let me go to Windows and show you the help file
on the execution policy
and the cmdlets that we can use for it.
First, there is a help file to explain these,
so you don't have to memorize everything that I'm saying.
I'm gonna put in execution* and what you'll see
is two cmdlets;
Get-ExecutionPolicy and Set-ExecutionPolicy,
and we're gonna use those.
That's how you can do it manually
at like your management station.
And then here's the help file about it.
I'm just gonna briefly bring this up
to show you that there are different execution policies.
Now, I'm gonna focus in on the ones that are
the most important,
but you can take a look at all of the different options.
Now, I know this looks like it's a big help file,
but what it does is it goes through and explains
what the execution policies are,
explains how you can do this as a group policy,
and how you can set the execution policies
that I'm gonna show you.
Let me scroll here to where
there's where changing it is.
Up here towards the top, they'll explain
all of the different execution policies.
Now, as I'm gonna show you the list,
there's restricted and that's the default,
and that's what's on my system right now.
I'll show you that.
The ones that we wanna focus on are AllSigned
and RemoteSigned.
And I'm gonna explain those in a second,
but you have some other ones.
Unrestricted, don't use this.
Please don't use this.
This means anything goes.
As a matter of fact, this tells you,
"This risks running malicious scripts."
Bypass, nothing gets blocked.
Usually you don't wanna use that.
You wanna stick to RemoteSigned and AllSigned.
Here's what this means.
RemoteSigned means that any script that gets downloaded from
like the internet, has to be digitally signed.
Now, if it's digitally signed, that's not necessarily
a protection mechanism for you.
What you need to do is, in your own PKI environment
and with the group policies you have in Active Directory,
you need to approve that digital signature.
So the idea is this;
the script was digitally signed from someone that you trust
and that has to be
further configured through group policies.
That's done usually by your security team
who's ever in charge of your PKI,
but there's more to this than just turning on
RemoteSigned to protect you from scripts.
Matter of fact, you know that anybody could sign a script,
so you need to decide who's allowed to run it.
So there's a little bit more to it,
but this is the option that I recommend
that most people start with.
That means that anything you write locally
doesn't have to be signed,
and anything that you download does have to be signed
and you should set up that it's specifically approved.
Now, AllSigned means everything you do has to be signed
and this is the ultimate goal.
Several customers that I work with
always get set up to AllSigned,
where all scripts have to be signed.
They have their own code signing certificate
that they got from their PKI environment.
And their group policies list that
only scripts that have been signed with this certificate
are allowed to be executed on the system.
That's what the protection really is at that point.
Now, if you have a user that happens to download
something from the internet,
even if it's signed, it wouldn't be able to run them.
So, how do you see what you have
and how do you change what you have?
Well, you use get-executionpolicy.
As you can see, I've got Restricted.
Now, I wanna change this.
Don't do what so many people have done
and set this to unrestricted.
That means, anything goes,
anything you download runs.
I'm gonna set this to remotesigned.
At this point, it means that I can run any script
that I want to run and I'm gonna say yes.
This is a change to the security policy on your machine.
It is a registry setting, so I'm gonna say yes.
That's why I got asked, "Are you sure?"
because it's a security change.
Now, here's something kinda interesting.
At this point, I can now run scripts that I create locally
and if I download them if they're already signed.
I'm gonna do something that may seem a little strange.
I'm gonna turn this back to restricted.
Why am I gonna turn it back to restricted?
Because what we're gonna do is
we're gonna create our first script
and I want you to see what it looks like
when it fails because of the wrong policy.
And then we'll fix it by changing it to RemoteSigned
and you can see how it works correctly then.