Specops Command 3.0
by Bob Kelly
|
But wait a minute, Group Policy does not allow for scheduling, reporting or deployment of anything but an MSI setup! If you've seen Specops Deploy you know that it can with the help of a client side extension (CSE) Specops uses to enhance the out-of-the-box capabilities of Group Policy. Specops Command is really a nice way of leveraging the technology behind Specops Deploy with a focus on the managed execution of PowerShell scripts. In this short review, I'll cover the installation, capabilities and use of Specops Command.
|
|
As you might expect, such a solution must have both client and server-side components. The client executes scripts and returns success/failure to the server. The server processes feedback and provides reports. That is essentially all there is to it as the deployment functionality leverages the familiar Group Policy mechanism. Requirements
Installation Overview Server installation requires that you select the database server you wish to use; this can be either a MS SQL Server already in your environment, or you can install a local instance of SQL Server Express. Setup also has you create security groups for accessing feedback on the Specops Command Server (two actually: Specops Command Admins who get full access to everything, and Specops Command Users who get read access to feedback information). The Admin Tools installation lets you install the Specops Command administrative tools. There are no real options here: either they are installed or not. The installation is separated so that you can choose to install the admin tools on other systems, separate from the local installation of the Specops Command Server. There is also a Specops Reporting component you can install which allows for web based reporting which leverages IIS server. This can be installed on the Specops Command server or another server in your environment. That covers the server components, finally we have client deployment. Available as a task within the same setup assistant wizard, you can either ignored the action or use it to get one client up and running quickly for testing. The preferred method of client deployment is (you guessed it) Group Policy. I must report that I did have some issues in rolling the client out via Group Policy and finally resorted to a local installation on my lab systems. While the client rollout may go very smoothly for you, when things do not go so smoothly troubleshooting can be a challenge. It should be noted here that the .NET Framework is installed prior to the client side extension installation. PowerShell is not actually installed until a PowerShell script is assigned to it using Specops Command. If you are troubleshooting client installation you may find this helpful to know. Performing the Installation Start by creating a (or specifying an existing) GPO linked to all computers that should receive the client. You'll also need to choose a file share where the client, .NET Framework and PowerShell installations are offered for installation. You must download PowerShell from Microsoft for yourself (MS does not let vendors distribute PowerShell). Specops Command requires that you download each of the different distributions of PowerShell (both 32-bit and 64-bit installations for Server, XP, and Vista). In the end, the client setup is linked to the GPO and your deployment of Specops Command is ready to go. If this sounds like a lot of work, fear not: the Specops Command Setup Assistant actually makes each task as easy as pushing a button (really).
|
||||
|
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!
|
|
Overall the reporting is quite good. Within the main Specops Command window a quick summary is presented for the selected GPO. A detailed feedback option lets you see a list of script success failure/details on a target by target basis. If a client does not run a script, nothing is reported so it can be difficult to see what targets have not run a script and/or why. In this scenario, it would be nice to see a list of targets that meet the criteria even if they have not processed the script. That said the details reported by the clients who do respond are quite good. Finally, a web based reporting feature is also provided (see image below). I was hopeful to see some generic result reporting such as the recording of standard-out, but the reporting results in the web interface are also limited to success and failure details. However, you can take further advantage of the web reporting via a custom cmdlet available from Specops called Send-Feedback. You simply include the cmdlet in your GPO and pipe any response you want reported to it. For example: get-process | Send-Feedback The above results in a full list of processes being included in the "Feedback" field of the deployment record which is visible via "Detailed Feedback" or web reports. There was an issue with the default installation of the Specops Cmdlets which is known and being addressed by Specops now. Support provided me the procedure to register them manually and what many will consider to be the most valuable feature of Specops Command came to light: The dynamic installation of custom cmdlets (or snap-ins). PowerShell contains dozens of powerful cmdlets which are commands to be used in your writing of scripts. They are written in verb/noun format, such as Get-Date or Set-Variable. PowerShell is very extensible in that you can write your own custom cmdlets and use them just as you would those built in to PowerShell. The problem is that the cmdlets must be installed and registered on any system where they are to be executed which adds another level of complexity to PowerShell. Specops does a great job of addressing this PowerShell headache: when you view your code in the main Specops Command display (either by typing it directly in the window or importing a file) any unknown cmdlets are colored in red. This indicates the custom cmdlet is not accounted for in the script assignment. Once the custom cmdlet is registered on the Specops Server, the custom cmdlet in the code is colored in green. This indicates it has been accounted for. Once a custom cmdlet is locally registered, simply using it causes Specops to include the cmdlet in the deployment with no need for you to do anything at all. It should also be noted that Specops Command itself is ready to be automated thanks to several cmdlets included in the distribution: http://www.specopssoft.com/wiki/index.php/Specopscommand/PowerShellCmdlets Licensing The trial is good for 20 days and unlimited number of seats. Until you disable it, a regular warning is presented during use to warn you of the features that will stop working when the trial period is complete. It warns that the following features will stop working when it reverts to free mode:
This would seem to be about all the features, but if you look closely, even free gets you more than Group Policy alone: in particular, you can run scripts without requiring a logon or restart event and credential elevation is still possible for user scripts. As you may expect, Specops Command is licensed on a per seat basis. The price per seat starts at $20 for between 1-100 computers and goes down from there. Support & Software maintenance is combined (roughly 17-20% of the license cost). Summary It does still feel like a product in its early days, and this is as much fact as it is opinion; the version number appears to follow the more mature Specops Deploy product-- despite a version three branding on the installation, it is a version one release. Below is a quick list of both positive and negative observations I made during my review process. It should be noted that most of what I saw as a problem, can be addressed with the use of some custom cmdlets. Specops Command does a good job of leveraging the technology of Specops Deploy to serve a growing niche of administrators who want to get their PowerShell scripts out with out worrying about cmdlet distribution.
Bob Kelly
|
Comments