To totally unlock this section you need to Log-in
Login
Logon scripts have been part of IT since the stone age it seems. Eventually we were also given logoff scripts for users as well as startup and shutdown scripts for computers. In the past these scripts were often written in VBScript. But now that we have PowerShell, we have another option.
Many people still use logon scripts, for example, to do things that can now be done as a Group Policy preference such as mapped drives and printers. In fact Group Policy has come so far since the days of Windows 2000 that many organizations don’t really need a logon script. But if you think you do, the only things you should do in the script are those things for which there is no Group Policy setting. In other words, the exceptions.
Requirements
Now before you get to excited realize that your clients must be running at least Windows 7 or Windows Server 2008 R2. And while not a requirement, I’m going to encourage you to be running at least PowerShell 3.0. Remember that logon scripts run under the credential of the current user and it only makes sense that your logon script perform tasks specific to the user. Computer scripts should run under the system context which should give you more leeway. One area you might need to test is if your computer script, e.g. startup or shutdown, needs to access network resources. Credentials may be an issue.
We encourage you to test your scripts interactively first to verify it works. Because the script runs in the background and invisible to the user, we suggest testing your script as a background job. If it runs as a background job the odds are it will run as a Group Policy script.
Finally, I want to point out that Group Policy scripts will always run, regardless of your local script execution policy. Even if your execution policy is restricted Group Policy scripts will still run using a Bypass policy. The assumption is that if you have setup a Group Policy to run a script, you know what the script will do and are taking adequate steps to protect it.
Creating the policy
Let’s create a policy. In the screenshot below you can see we have the Group Policy Management console open. I’ve created an empty GPO called PowerShell Scripts and linked it to the MyTest organizational unit.
Edit the policy and navigate in the User node to the location shown below.
Double-click on the type of script you want to create. We're going to create a logon script which will give you in the next screenshot.
We've highlighted the fact that scripts need at least Windows 7 or Windows Server 2008 R2.
Because it is possible you may have other types of scripts to run as well, you can control when PowerShell scripts are run in the drop down box as seen below.
Control when PowerShell scripts are run
For my test we're going to run PowerShell scripts last. Now we need to add a script. The best approach is to click the Show Files button which will open an Explorer window for the GPO. Open another window with your script folder. Then simply drag and drop the file or files to the GPO as we do in the next screenshot.
The files in the Logon folder will replicate and should be pretty secure. Once the file is copied we can go back to the Logon Properties dialog and click the Add button. We find it easiest to browse.
Browse logon scripts
This opens up the browse window again. Select the script and click Open. If your script requires parameters, you can insert them as well. If all goes well you should end up with the following screenshot.
At this point the policy is complete. If you want to create a computer startup or shutdown script you would follow a similar process except under the Computer node.
Summary
Using PowerShell scripts through Group Policy opens up some tremendous possibilities primarily because you can do so much with a short script. Keep your scripts simple, test thoroughly and enjoy the benefits.
 |  |