The first thing you must do when setting up Prism Deploy is to create a Prism Deploy "Channel." Channels are used as the highest hierarchal level in grouping clients for management. You choose a name for the new Channel and then select which computers you wish to add to the Channel. You can enter the name of the computers to add them manually or you may browse for them. The browsing process is a matter of selecting machines from a Network Neighborhood/Active Directory dialog. Here you may use the shift and control keys to select multiple machines, but with no information collected about the machines, you do not have the option of utilizing queries in this selection process. In a small to medium environment, this is not likely to be much of a problem but those of you in a large environment where you wish to selectively add computers to different groups based on hardware, location, operating system, etc. this may be seem like a tedious task. However, you should think of a Channel as a domain; groups are assigned within this Channel so creating multiple Channels is more likely a broad task that you would only need to perform at a domain level. We will discuss the options available for grouping machines within a Channel later.
The next thing you will need to do, is deploy the Prism Deploy Client to the machines you have assigned to your Channel. You may choose one of two available methods for deployment: A direct installation (for Windows NT and later systems) in which the client installation is handled remotely from the console. The second, which will be required for any Pre-Windows NT clients on your network, is to create a file based installation.
For the direct installation, there is a checkbox where you may enforce the required reboot of the client machine. Careful with this, the installation and reboot was quick with no notification presented to target systems. Like most software requiring a restart, it is best performed after hours (or at least make sure everyone is well prepared.)
In the AppDeploy lab, all Windows 2000 and XP systems installed and rebooted quickly with no problems, returning a success status to the console.
The file option generates a Subscription File,
which is an executable that will install the required client software for Prism
Deploy. It may be sent via email, shared on a web page, network drive, etc.
With so many options for controlling the behavior of the Subscription File, I would like to see an additional option that allows you to control the message presented by the Subscription File. The message it does show is illustrated in Figure 1 below:
This message may be a bit of a confusing message for anyone not familiar with Prism Deploy terminology. A simple "Install Prism Deploy Management Client?" would be a bit friendlier for any users you instruct to run this file. And naturally, when installing a service of this kind, you do require administrative privileges on the system where it is being installed. On 9x clients you are okay, but if you want to use this deployment method on Windows NT and later clients, you will need to address this deployment issue. If you should attempt to install the client package without sufficient access, the installation fails silently presenting no messages to the user (even if the Subscription File is configured to run interactively).
There are two kinds of groups you may create: Organizational Groups and Configuration Groups. Organizational Groups are populated manually by assigning it individual systems, NT groups or Active Directory groups. Configuration groups are dynamically populated based on the configuration rules you specify. When choosing to create a configuration group, you then specify what type of configuration group you wish to create. There are two choices: Predefined Groups and User-defined Groups. Predefined groups are based on a configuration values you chose, and subgroups are automatically created and populated based on your choices. User-defined configuration groups contain one or more subgroups populated using configuration rules you define. From here, each subgroup is defined by a separate configuration rule.
I created a Predefined Configuration Group to be based on the version of the operating system and named it "OS". Under this new "OS" group, subgroups for each operating system on my network were created and populated in a matter of seconds as shown below:
This ability to create groups based on inventory data is a great one, but it does make you wonder why there is no capability to view any of these asset details for clients from the console. When viewing the properties of a client, no asset information is presented. However you can see the groups to which the client belongs. You can therefore create Configuration groups for any asset details you may wish to be aware of from the console.
Creating A Package
Creating a package is also quite easy. While the deployment capabilities are relatively new, the repackaging element of Prism Deploy (also available separately as Prism Pack) has been around for some time. Formerly known as PictureTaker, the filename for the repackager is still named "Pictaker.exe." It uses a simple before/after snapshot process to assemble the delta into its own proprietary package format. You may either deploy it as-is, or you may easily convert it to a Windows Installer MSI package within the Prism Deploy Editor.
To deploy a package, you need to create a task. A task may consist of a package, a command line, or a script file. When selecting a package, it must be a native Prism Deploy package. In testing, Prism Deploy package installed quickly and without any problems. This is certainly the "preferred method" when using Prism Deploy to distribute software.
To push a Windows Installer package, you must use the "command line" action when creating the task. You may then enter a command line installation. I used the following to push an MSI package using a command:
%windir%\system32\msiexec.exe /i "\\dl380\Packages$\WinZip8\WinZip_PrismPack.MSI" /qb
The MSI failed to install due to a legitimate problem with the client (MSI Error 2738, a custom action could not run because the VB runtime was not installed). However, the console recorded the deployment as a success, despite the installation failure. The console is dependant upon the return code from the command executed. Because Windows Installer did not actually return 2738 as an error (this is an MSI error, not a Win32 error code as is normally returned) and instead returned a zero, the console saw the deployment as successful and recorded as such. Realizing this, I tried the following command line for the installation of the MSI Package:
%comspec% /c %windir%\system32\msiexec.exe /i "\\dl380\Packages$\WinZip8\WinZip_PrismPack.MSI" /qb
This returned an error as expected and the console showed it as an Alert instead of a Success in the reports with a description of "Command execution failed".
It is plain to see that someone who knew what they were doing designed the reporting features. All too often generating a meaningful report is either difficult to automate, or very time-consuming to generate manually. Prism Deploy provides very helpful reporting, with a couple of views to choose from. Exactly what you get depends upon the scope of the report, which you dictate by selecting a computer, package or group prior to viewing the reports. When selecting a group reports look as follows:
First is the "Quick View" tab. This provides a list of machines and totals for "assigned, installed, uninstalled, errors, installed with errors, and pending. The next report is shown on the "Summary" tab and provides the status for each task for each machine it was assigned to as well as the time the status was recorded. The "Log" tab of Deployment Reports dialog provides a chronological summary of events and the "Alerts" tab lists only the failures that have occurred and summary information on each. Any of these reports may be exported to a TXT file. The text file is actually formatted as a comma-separated value (CSV) file and may be easily imported to a database or viewed in a spreadsheet program (such as Microsoft Excel).
While not granular, Prism Deploy does provide
limited security in its ability to password protect Channels. This is a single
password that will need to be shared by anyone who requires access. It is for
this reason that you may be more inclined to segment your network into more than
one Channel. Going back to the beginning of this review, you recall that adding
computers to a Channel is a manual process and cannot be based on queries as
Configuration Groups can. Perhaps in a future release, you will be able to move
computers between channels so that you can take advantage of the power provided
by Configuration Groups to help automate Channel membership.
Prism Deploy is a very capable repackaging and
deployment tool. There are few products that actually tackle both packaging and
deployment, and it is nice to see Prism Deploy has taken on this challenge. The
deployment capabilities have definitely improved since the review AppDeploy.com
published for the beta release of Prism Deploy 4.0. While you can generate
MSI packages and deploy them as command line installations, this is not the
"bread and butter" of Prism Deploy. Given that Windows Installer can
often cause as many administrative problems as its complexity helps you to
solve, there are some who have decided to steer clear of Windows Installer (when
possible). If you are not banking on Windows Installer as your deployment
technology of choice, Prism Deploy provides an excellent solution for package
creation, conflict checking and deployment.