Now let's look at log on slash log off scripts.
So very similar to start up and shut down.
Log on and log off.
Scripts run in this case the user's context because the user has to log on in order for log on script
to or a log off script to run.
So it's good for making changes to user settings and data.
So if you need to make a change to HK underscore current underscore user in the registry or you need
to copy a file into the user's profile like a shortcut file or something like that.
It's the right place to do that kind of thing because it's essentially running as the user.
Now it does run of log on and log off.
So it obviously requires the user to log on to execute.
And on the downside, it does require the log on slash log off to run.
So you had that trigger point that that only trigger point is the log on slash log bar cycle.
Again, just like startup scripts, it's up to you to provide logging in your log on scripts just to
find out if they really need to run again or if they've done something wrong.
You know, one thing that you need to be aware of with scripts in general, in group policy is that
there's a default timeout on the script actually executing and completing of 10 minutes.
What that means is that for some reason you've done something in your script that's causing it to hang.
Then your user could be sitting there literally for 10 minutes waiting for the script to execute before
they're able to move on with their desktop.
So that's something to keep in mind.
And really, when you're writing your scripts, it's easy to write a script that just does a dry mapping
or a registry change.
It's a lot harder to write a script that the test to see if those things need to be done and then logs
that they're doing it correctly and then having exception handling in the case that they can't do it
correctly.
And so that's what I always recommend if folks are going to use scripts that you use them correctly
because the downside of scripts is they can cause really bad and hard to troubleshoot delays for the
user.
And again, they'll run every time, regardless of whether they need to, unless you script around that.
So I showed you the UI in startup and shutdown scripts and I showed you the General Scripts tab.
Well, log on slash log off.
Scripts have the same identical UI.
So what I wanted to do in this screenshot is show you the PowerShell Scripts tab.
So if you were going to add a PowerShell reference, you would use that add button and essentially it
would browse you into the CIS fall portion of the GPO, just like it did for the log on scripts.
And or I'm sorry, start up scripts and you be able to add a reference to a dot PS1 file.
You can also set the order of script processing so you can control whether PowerShell scripts run first
or last within this GPO.
And that's in the case of, let's say, you have some scripts that depend on other scripts.
You might have regular scripts that depend on PowerShell scripts or vice versa.
You can control which scripts for specified to run first within this GPO.
And that's useful if you have that scenario.
I don't know that I would necessarily recommend having multiple types of scripts running in a single
GPO, unless you're, like I mentioned earlier, doing a lot of good logging and testing to make sure
that those scripts run properly.
But you do have that flexibility within this tab.
So now let's go and implement a log on script and I'm going to try something different.
I'm going to use a PowerShell based logon on script in my next example.