So now I want to talk about start up and shut down scripts in particular.
So let's talk a little bit about the capabilities and the limitations in start up and shutdown scripts.
So the thing to understand about start up and shutdown scripts, they're running per computer, so they're
running before the user is logged in.
And that means that they have to run in some kind of security context.
And as it turns out, they run in the local system context.
Or essentially they run as the machine account.
So this allows you to do pretty much anything you want in a startup script in terms of managing the
configuration or making changes to a Windows computer system.
So what that means is you can change registry keys that the user would normally have permission to.
You can update files that the user wouldn't normally have permissions to.
Any privileged access is available to you within the context of a start up script.
The other thing to recognize is, is that that startup script is trying to access resources on the network.
For example, if you're trying to copy a file from a network share to the local system within a start
up scripture.
Then the context in which that access to the network is happening is essentially the machine account.
So the machine account has to have permissions to the share in order to be able to do that copy.
And that's something that's important to keep in mind.
So again you can these startup scripts and shut down scripts run at boot or it shut shutdown.
And in the case of a startup script, don't require the user to be logged in.
It's pretty self-explanatory, but I just wanted to underscore that.
That in fact the startup script runs before the user even gets their log on prompt to log in.
So what are some of the limitations?
So it does require a reboot or a shut down restart to log on or to generate or to execute a startup
script.
So that reboot is kind of the trigger for executing start up scripts.
Startup scripts in and of themselves don't provide much in the way of logging.
If you run a are soapy report or a results set of policy report, and I talked about that in the earlier
module against a system that has received a start up script.
You only get the last execute time, so you only see what actually happened or when that script actually
ran last.
So at least you can see if it did run.
But the downside is you can't you don't get any logging of what it did because it's a script.
It could be doing anything.
And it will run every time, regardless of whether you needed to.
So in other words, whatever you're doing in that startup script, whether it's doing a file copy or
doing a registry hack, it's going to run every time that system reboots.
And it's going to redo the file copy and redo the registry hack unless you have coding in your script
that tests for the thing you're trying to do to see if it's already been done.
So scripts don't have any intelligence in them other than what you put in that script.
And that's a really important point about all of the script capabilities in group policy.
You need to think about what you're doing in your script.
And ideally you want to add the logging and the testing of whether it needs to run so that it doesn't
do extra work.
And so that if it does have problems, you know what's going on.
So let's look again at the UI and see how this works.
So remember I mentioned that if you hit that show files button that browses to the folder, insists
more, which is the default location to store startup or shutdown scripts.
And the add button will add the reference to the script into the GPO and the script could be in sizzle
in that startup folder, or it could be out on a network share somewhere.
It doesn't really matter.
The advantage of keeping it in the GPL and system is that as long as the GPL is available, the script
is always available to the machine or the user that's executing it.
And from a permissions perspective, you probably have less challenges around managing access to the
script.
With the up and down buttons, you can change the execution order of the script.
So if you have multiple startup script, which is perfectly legitimate, you can change the order in
which they execute based on that up and down button.
And then finally, if you hit the PowerShell Scripts tab, you can add PowerShell scripts.
And these are differentiated from regular scripts just by virtue of the fact that they have a PS1 extension
and they run in the PowerShell engine.
So they're treated differently from a scrips perspective in group policy.
So let's dive in and kind of show you how to deploy a startup script and what it looks like.