Wise Package Studio Professional 5.0 

by Bob Kelly 

I have been an active user of Wise Package Studio since it was Application Integration Suite (v2.0) but the last review was version 3.02, so there is a lot to be said here! And that really is the problem with reviewing a product like Package Studio- it does so much you’d have to write a book to do it justice. Therefore what I will focus on are the features that Wise Package Studio advertise as exclusive features and naturally a few of those things I think are just too cool to let slip by.

First off, aside from the addition of features there has not been very many “changes” since its earlier versions. Most would agree that Wise got their tools right the first time and there is no need for rewrites or major changes to the way things are. What Wise has done is add to its features- enhancing the functionality and value of this suite. We will cover the following features and capabilities of Package Studio 5.0:

• Project Management and Reporting
• The Wise Software Manager
• Package Meta Data Support
• Package Dependencies Support
• Preflight Deployment
• Mobile Device Package Editor

Then we will wrap things up with overall thoughts and any of my obligatory negative comments.

Project Management and Reporting

One of the features I was impressed with when it first became available is the way you can create and document a process within Package Studio. When you have a team of multiple administrators (particularly when you add someone to the team) it is very valuable to have a documented process- “this is the way WE do things”. The sample project has some good details and adding to the list, tools and inline documentation is pretty straight-forward. Since the introduction of this feature, this too has been significantly enhanced.

Aside from simply checking off a box as you complete each step in the process for a given package, you may also configure the project template to automatically update the project status as you go. Answering questions like “when is my package going to be ready?” becomes much easier when you take advantage of the additional project management data you can maintain. Information you may update includes:

• Estimated Completion Date – Manually specified date on which you expect the project to be completed.
• Current Target Date - As work on the package moves along, if you determine that the project will be completed before or after the estimated completion date, this space is provided to specify an updated target date.
• Actual Completion Date – This field is filled in automatically when the project’s status is set to Completed.
• Estimated Hours – Manually entered number of hours you estimate the project will take to complete.
• Hours Completed – You determine if hours are entered by project or by task. If project, you enter the total number of hours for the project, updating the entry as work on the project progresses. If Task is marked, you enter the actual hours for individual tasks and the total of the task hours is entered automatically.
• Remaining Hours – Initially left blank, when work on the project has begun, use this field to record the actual amount of hours remaining to be done. For example, suppose you originally estimated the project to take 40 hours, and 20 hours have been completed. However, because you know the remaining tasks will take 30 hours to complete, you enter 30 hours here. This provides a more realistic number in the % Completed field:
• % Completed – The percent completed is calculated as follows:
  • If Remaining Hours is blank:
    • % Completed = Hours Completed / Estimated Hours
  • If Remaining Hours has a value:
    • % Completed = Hours Completed / (Hours Completed + Remaining Hours).

A Metrics tab gives you a nice summary of the package and its progress, highlighting the numbers described above. Additionally, if you are using the IIS front end tool for sharing this information via your intranet (Application Gateway), setting a project status to Closed or On Hold in the Project Management tab assigns the same status to the corresponding request in Application Gateway.

Making all this data even more valuable is a highly configurable reports feature that lets you completely control the reports menu in the Workbench application. There are several included reports and you may create your own as .rpt formatted files (Crystal Reports).

Reports may be exported as PDF, html, and any number of spreadsheet and database formats.

Finally, there is a new Management Reports Web application designed to give project leaders, managers, and other non-packaging personnel access to Workbench reports without running Wise Package Studio. This Web application replaces the reports that formerly were available on the Reports tab of Application Gateway.

The Wise Software Manager

The Software Manager lets you import packages and their resources into its Software Manager database, which provides you with a centralized point for managing all applications at any stage of deployment. Once a package is in the Software Manager database, you can view its resources, either on-screen or by running any of the Software Manager reports.

From Software Manager, you set the package's status, which determines whether the package is still in development, available for deployment, or retired. When you set a package as “available” it also moves a copy to an “Available Packages” folder in your Wise Share Point. This is another process related step that can help you when working with others- if the package is not in “Available Packages” you can tell people to leave it alone! Additionally, when a package is available for deployment, you can use the Package Distribution tool from within Software Manager to distribute the package to end users through a distribution system. Wise has partnered with several distribution vendors (not just Altiris) to provide a nice handoff between the package creation and package deployment steps in your process.

For one thing, you can now move an installation directly into a Group Policy Object in Active Directory. Then you can set Active Directory to distribute the installation.

Wise Package Studio - Package Distribution (AD)

Package Studio support distribution to Software Delivery Solution (Altiris), Tivoli (IBM), LANDesk Management suite (more details below), Active Directory, Microsoft SMS (more details below), Radia (Novadigm), ZENworks (Novell), and ON Command MSI Package Wizard. Additionally you may distribute the package to a network share, FTP server or perform an Administrative Installation to a location of your choosing.

Wise Package Studio now supports Microsoft SMS 2003 the same way it currently supports SMS 1.2 and 2.0:

• Using Package Distribution to prepare a package for SMS deployment
• Converting an SMS installation (.IPF) in Legacy Setup Conversion
• Creating an installation for SMS in Windows Installer Editor (Installation Expert > Microsoft SMS page)
• Creating an installation for SMS in WiseScript Editor (Installation Expert > Microsoft SMS page)
• When you change a package's status to Available, and the package has an associated package definition file (.PDF or .SMS) for use in a SMS environment, the .PDF or .SMS file is created in the Available Packages directory along with the final .MSI.

Wise Package Studio also provides special integration capabilities when installed on the same computer as LANDesk Management Suite. You can use the Package Distribution tool to copy the package to a directory accessible by the LANDesk Desktop Manager. After the package is copied, you can create a Distribution Package Script using the LANDesk Desktop Manager console, and then use LANDesk Management Suite to distribute the package to end user computers. Keep an eye out for my upcoming review of LANDesk here at AppDeploy.

Package Meta Data Support

Available in the Professional and Enterprise editions, you can now add package Meta Data to store additional package information that is not otherwise recorded by Wise Package Studio. For example, you can specify the type of license model the software uses or point of contact for the application. You can specify the name and type of value to be a text string, an external link, true/false or yes/no value. You already have a database and central location for managing packages, why not work in as much documentation as possible? There are no “default” meta data types included, you need to create any Meta data fields on your own. Some information will make more sense to your environment than others, but here are some ideas to get you thinking:

• Text such as: Application description, in-house or COTS software, license model and number of licenses, hardware requirements, comments about the package, or internal point of contact for the application.
• Links such as: to installation instructions, repackaging requirements, hardware requirements, original source location and other package related notes or documentation. 

You may define meta data fields in Software Manager (select Setup > Meta Data Fields). This determines the fields that are available for entry and stored in the Software Manager database. They may then be edited for each package in the Package Attributes dialog. This is available in both Software Manager and ConflictManager. Finally, you can view the data in Software Manager in the Package pane or by using its Package Attributes dialog. In ConflictManager, you can view meta data in the Package Attributes dialog. You can even filter the package display by a meta data field.

Package Dependencies Support

In Software Manager, you can define package dependencies. Package dependencies represent the packages that must be installed for a specific package to function and the order in which the dependency packages must be installed.

• When you make a package available, check its dependencies. You might not want to make a package available unless its dependencies are available also.

• Before distributing a package, check its dependencies to see if you first need to distribute any dependency packages.

• Before testing a package, check its dependencies so you can install the dependency packages on the test computer.

• Before installing a package, check its dependencies and install them in the correct order. When a package changes, test the packages that are dependent on the changed package, to make sure they still work.

The fact that Wise bothered to address the issue of package dependencies and ordering shows that they know the needs of administrators. There is a very fine line (that seems to move quite a bit) separating the packaging and deployment processes. Like the other Meta data you can provide in Software Manager, this provides a logical place to document package dependencies. However, I would really like to see this feature taken a step further and support the insertion of custom actions or installation conditions into packages to help actually solve the problem of package dependencies. Also keep in mind that while you can set package dependencies in Package Studio Professional, it does require the Enterprise edition to have this dependency information displayed in a Software Manager pane where it is easily viewed.

Preflight Deployment

The Preflight package installs silently with no prompts- or I should say it “performs its operations” silently with no prompts- for the application does not install. As the name implies, this feature lets you create versions of your package to deploy as a test. The key idea being, that by not actually installing the software- you can test in a live environment.

But wait! If the package doesn't do anything, how does it help me determine a successful deployment?

This is where your thin, moving line between packaging and deployment processes makes all the difference. In an environment where you have a strong deployment and reporting mechanism, Preflight Deployment will be of fairly little value. However, if you do not have a consistent or well-documented baseline you are pushing against, this feature has the potential to become quite valuable.

The Preflight version of your package that is created has no user interface sequence at all, and the remaining actions are primarily custom action calls to a Wise diagnostics DLL. The Preflight package performs the following checks:

• Launch Conditions - Records which launch conditions succeed and which fail.
• .NET Framework - Determines if the .NET Framework is required by this installation, and if so, whether or not the .NET Framework is installed on the target computer.
• Connectivity to URL - Extracts URLs from any Launch Web Page, Download File From Internet, or Post Data to HTTP Server custom actions that are found in the original .MSI. It puts them in a table, which is processed on the target computer.
• Open Document Check - Builds a list of document extensions from any OpenDocument custom actions and saves the list in a table. When the preflight package runs, this test checks the registry for support for each extension.
• File Association Check - Checks that any extensions in the preflight package do not overwrite or reassign those already on the target computer.
• Disk Space Check - Evaluates the disk costing and identifies target computers that don't meet the requirements.
• File Security - For read access, it cycles through the files that are installed and queries the target computer for permissions to access the files. For write access, it cycles through the files that are installed and queries the target computer for permissions to create and update files.
• Registry Security - For read access, it cycles through the registry entries that are installed and queries the target computer for permissions to access them. For write access, it cycles through the registry entries that are installed and queries the target computer for permissions to create and update them.
• File Searching - Cycles through the AppSearch table and evaluates conditions attached to each AppSearch action. It then records if any items items specified in AppSearch exist on the target computer.
• Local File Execution - Evaluates custom actions that launch a file via the command line that is expected to exist on the target computer. 

Even better, the results of the Preflight package are reported to a Preflight Deployment database via an http call to a DLL which Package Studio installs on an IIS server. Then, from within the workbench application, you can use the Preflight Analysis tool to view the results as they are reported by each execution of your package.

Mobile Device Package Editor

The new Mobile Device Package Editor lets you edit or create CAB files directly. Edit the files, registry entries, and shortcuts of a CAB. If you create a new CAB, you can also specify platform and processor support and output multiple CABs. The Mobile Device Package Editor tool is primarily intended for opening and editing an existing CAB file. Use it to make minor changes to an existing CAB, including changes to files, registry entries, and shortcuts. If you open an existing CAB, you cannot change the supported platforms or processors for the CAB or any individual resource within the CAB. You can also use Mobile Device Package Editor to create new CAB files, but it is recommended that you instead use the Mobile Devices page in Installation Expert, which provides full functionality and saving of CAB file definitions. This Mobile Device page creates an .MSI that installs to a desktop computer and then transfers the mobile device software to the mobile device. The Mobile Device Package Editor creates a CAB file installs directly onto a mobile device.

Wise Package Studio 5.0 - Mobile Device Package Editor

Closing

Package Studio has long been the favorite of many administrators, and with good reason: Wise has provided tools made for Administrators for several years and they do an excellent job of it. I still use and recommend Package Studio on a regular basis and get excited about upcoming releases every time I hear they are on the way. Package Studio provides a well-developed set of tools for those who repackage applications and continue to push the envelope of what a repackager can be with the release of version 5.0.

It has become expected of me to say something negative about every product reviewed- after all, no product is perfect and there is nothing more annoying than a review that sounds like a sales pitch. With that in mind, one thing that has annoyed me since early on has been the Wise progress dialogs. They include two frames, “Current Operation” where you are told what is happening now and an “Overall Progress” frame which contains a progress bar that you would expect to reflect the “overall progress”. Instead, this progress bar actually reflects the progress of the “current operation”. Depending upon what you are doing, several operations may be necessary which results in an “Overall Progress” bar that restarts again and again. It is reminiscent of the movie “Office Space” when Peter is trying to quickly shut down his machine to escape his boss at the end of the day. No, it’s not slow- in fact, I have noticed that version 5.0 is noticeably faster than previous releases, but the progress bar should read simply “Progress” and not “Overall Progress”. And with that said, if that is the best criticism I can come up with for Package Studio- I think I’ve found a winner!

Bob Kelly
2/7/2004