Search AppDeploy

Home > Reviews > LANDesk Management Suite 8.0
 

 
Package Creation

The Package Builder application is not installed anywhere by default because LANDesk promotes the idea of establishing a clean machine to perform these actions. The installation files for the Package Builder are provided in a share on the LANDesk server. I went to a clean machine and ran the installation over the network.

Running the Package Builder Wizard takes you through a typical before/after snapshot process which I am assuming you are familiar with already. The process was very simple and streamlined and provided no exclusion lists to verify or package contents. It merely prompted for the name of the application – in this case the Google toolbar.

When choosing to modify the package, you are warned that you must leave the Package Builder Wizard to do so and that you will need to build your package manually using Builder. “Builder” provides a powerful set of features (which I found surprising after witnessing the simplicity of the Builder Wizard). It provides a very intuitive set of form-controlled functions to help you create/modify your installation script.

The Package Builder generates installation packages as EXE files and does not provide an option for generating an MSI package. The only real negative thing I see here is that with the Wizard not providing an exclusion list or simple means of grooming your package after the snapshot, you really need to perform any package “cleaning” in the Builder application. While that in and of itself is not a bad thing, the Builder interface does not lend itself to easily viewing the contents of your package as a simple list of files and registry entries you can quickly delete. It is really more geared to authoring setups, than to modifying that created by the Builder Wizard. Finally, because it does not generate an MSI package, you do not have the ability to identify and remove unwanted items with PackageCleaner or easily import its contents in to any conflict management database you may have invested in.

Package Deployment

Deployment went smoothly in testing. The first step is to create a deployment script- which is really not as complicated as it sounds. A wizard requests the details of the deployment, prompting for an http or UNC path to the package you want to deploy. The script is essentially an INI file, which dictates the parameters of the deployment; you must then use the Scheduler to actually assign the deployment script to machines. Covering things quite well, the deployment script requests the following details about the package deployment:

• Install or Uninstall – As you would expect, this setting determines if the script should be installing or removing a software package.
• Multicast – if yes additional options to control the multicast are presented
• Additional Files – you may specify additional files to be distributed as part of the script
• Dynamic bandwidth throttling – you can choose the percentage of minimum available bandwidth to use on the client (a lower value would give other applications more priority). Additionally, you can specify a delay between packets in milliseconds.
• Distribution Limits – you can choose to use the default or custom distribution limit, which is a value indicating the number of devices to distribute to at a time.
• Feedback options – you can choose how the user will perceive the package installation. You may hide the UI from the user or display progress. Additionally you can choose to display a background screen and control if the user should be able to cancel the package or not.
• Reinstallation/Repair – If the package is already installed on the target client, you can choose what action the distribution should take: heal (repair) the package, perform a full reinstallation or allow the user to decide which of these two options should take place.
• Rebooting – This section allows you to specify if the package should never reboot, always reboot, or reboot only if necessary.
• Deployment Timing – While the time of the distribution will be set in the scheduled task, this allows you to select machine specific parameters. You may choose to delay the action until the next user logon. You may also allow the user to delay the action and specify a custom message to display and a timeout/countdown interval at which the action will take place if no decision is specified.
• Bandwidth – You can specify that a non RAS network connection is required. If you do, you can then specify if any non RAS network connection is to be required, or to only allow high speed network connections.

When the wizard is complete, a summary of items is provided where you may click Finish to create the script or “Back” to make any changes. When scheduled, the Google Toolbar package showed a pending, active and complete list of machines where the target clients would move from list to list as they processed the job. See image at left. Two machines returned no error, and a third reported that it completed but that a reboot was still required (Internet Explorer had been running already at the time of the package installation).

With the Application Healing component installed, whenever an application fails to launch on a client Application Healing detects the problem. It will record it for reporting purposes, or (if the application is listed as one you wish to provide application healing support) the Application Healing agent uses the distribution package to reinstall components of that application. To minimize the use of network bandwidth, the healing process only copies missing, corrupt, or outdated files to the client.

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

 

• Log on
• Register
• Survey Results