Using Specops Command

Just as you would handle normal deployments via Group Policy, you simply right-click on the GPO you wish to target and select Edit. Here in the Group Policy Editor MMC, you'll browse to the Specops Command node under "Systems Management" (you can navigate here from under either Computer Configuration or User Configuration depending on your needs.)

Click the "New script assignment" button and you'll be prompted to enter the name of the script assignment along with other parameters of the deployment: the language, the Script, the Undo Script, Target and Schedule.

Script

For testing purposes, I tried to use a script that would pop up a message to the user. It seemed a logical test script so I could easily see when it was being executed. However, it did not work and after some troubleshooting I was informed by support that it is a limitation of PowerShell-- that PowerShell cannot run scripts from a network location that pop up a dialog. Specops plans to offer a custom cmdlet in the future that will help users work around this inherent limitation, but for now it is to be avoided. Knowing that VBScript has no such issue, I rewrote the same code in VBScript and encountered the same problem, but this time for a different reason: Group Policy executes in Session 0 in Vista and as a result any  VBScript that executes attempts to present a message like this not be seen.

A simple script to echo a message ran just fine and I could see the last time it ran on each targeted system from within the Specops Command window within the GPMC by clicking the "Detailed Feedback" button. I also ran scripts to change the state of a service successfully, but I was not successful running a script designed to create a shortcut on the desktop which was provided to me by support. A good real-world test, the problems I encountered helped me to appreciate the feedback mechanism absent from typical GPO deployments.

Undo Script

If this script were inflicting changes on a target system, we would want to populate the "Undo Script" which is intended to be script code you would enter to reverse any changes made by our script. Effectively, this is the "uninstall" for your script deployment. For example, if your script stopped a service you might code the "Undo Script" to start the service back up again.

Target

If you are targeting all systems where the GPO is linked, there is no need to complete this section. However, you can filter those linked targets here by specifying criteria that is checked prior to execution. For example, you may specify it should run only on those systems with a certain registry value, model number, OS version, etc. This is a simple interface to specifying WMI filter information which is supported by Group Policy, and if the criteria you are looking for is not listed, you can of course specify your own WQL query (even using its built-in WMI browser).

Schedule

This is where those familiar with managing deployments via Group Policy can really get excited. However, if you are accustomed to a more robust deployment system you could find the options disappointing.

You can specify how often it is run, but when it comes to when it should be run you are given the option to offer a window of time. The time window should be at least 90 to 120 minutes in size because that is the length of the default group policy refresh window that Specops Command is dependant upon. If your window were too small, you may well end up with target systems that do not refresh during the specified times and therefore will not run. You can run the GPupdate command on the target system to wake it up right away, but under normal circumstances you could have up to an hour and a half wait before you know if the script was successful or not. That said, the typical limitations of script deployment are much more substantial. Without Specops Command you are basically limited to Startup, Logon, Logoff or Shutdown -- forcing users to stop using their computer so you can run a script is less than ideal!

Note: restarting the computer or logging off and back on again does not trigger the Group Policy refresh window on which script assignment is dependant. To force a refresh, GPupdate is the command to run!

[Page 3 of 4]     1 | 2 | 3 | 4