/build/static/layout/Breadcrumb_cap_w.png

Blog Posts tagged with Product Review

Ask a question

Review of Wise Package Studio Professional 5.0

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

One thing not provided by Package Studio (or any other repackaging product for that matter) is some help deciding what does and does not belong in your deployment package. The exclusion list has been updated for some time and does a great job of helping you to eliminate items that should never be in your package. However, it traditionally takes experience to learn why some items may cause you problems- and what problems. Lessons that can be costly in some environments. A new tool to complement Package Studio and provide this valuable information is now available, called PackageCleaner. It scans and reports on Package Studio MSI/WSI files and tells you which items you may not want, what they are, what may happen if you leave them in, and even situations where you may need to include them.

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

Be the first to comment

Book Review: Microsoft Application Virtualization Advanced Guide

The Author, Augusto Alvarez works as a consultant and has experience writing on the topic fo App-V, having authored a more introductory step-by-step book for the same publisher which covered v4.6 in 2011. The book’s subtitle sums up the lofty goal of the book quite well: “Master Microsoft App-V by taking a deep dive into advanced topics and acquire all the necessary skills to optimize your application virtualization platform”.

Does it pull this off? Yes, yes it does. I’m often disappointed at a book that claims to be “advanced” (especially for a subject area that is arguabley complex already). So to provide a readable summary of what is covered here, I’ll be as brief as possible:

The sequencing of applications and the deployment of itself App-V in “complex environments” each get their own chapters and with another large section dedicated to scripting and command line support is a great sign that this is indeed a book that satisfies the expectations of an “advanced guide”. Design considerations and scaling of App-V implementations and a nice fat section on troubleshooting. It covers SCCM integration and also integrating App-V in an VDI environment. Finally it closes off with a chapter on integrating Sever App-V with private clouds. Finally, there is an appendix includes a brief summary of dozens of Microsoft third-party tools for App-V.

If you know App-V, use App-V and want a good reference for getting the most out of App-V this is the book you’ve been looking for!

http://www.packtpub.com/microsoft-application-virtualization-advanced-guide/book

Note: the chapter on Integrating App-V with SCCM 2012 (yes the very latest) is available free as a sample download chapter at the link above.

 

 

Be the first to comment

What I love most about the Data BOND GUI...

A beautifully simple, intuitive experience across all operations.

Be the first to comment

A closer look at AppTracker

Introduction

I’ve long been a fan of having the right tools to do the job properly. Maybe you are getting your hands dirty with application packaging, or perhaps you’re managing a team of application specialists and need to commit to delivering a certain number of packages to the business on a tight schedule. Either way, you need the right software to be able to do the best job possible. Many of us here at ITNinja have had experience with a few different packaging toolsets over the years ranging from the very simple (free) offerings such as Orca, up to the fully featured, all-encompassing solutions offered by vendors such as Flexera and RayNet.

If you are managing a team of application packagers then, the “right tools for the job” translates to tools to optimise the performance of this team as a whole. For smaller organisations you can certainly use a spreadsheet to plan and execute the work; however for most medium to large organisations there are significant advantages to using Application Lifecycle Management (“ALM”) toolsets. These are designed to optimise the team’s output by providing a centralised portal where all members of the team can be assigned tasks and track their work, raise defects, manage UAT etc. Weekly reports enable management to monitor performance, and it can make proper management of SLAs possible. This results in increased customer satisfaction (that might be the business the IT team are supporting, or an actual end “customer” if you’re a service provider) which can only be a good thing for everyone.

In this post I’m going to take a look at an ALM solution called AppTracker. I first met the AppTracker team at the AppManagEvent in Utrecht in 2013 where one of their founders (Justin Pickup) spoke to me enthusiastically about their offering. I’ve since followed their progress and in their latest release (version 5) I collaborated with the AppTracker team to help implement some ITNinja community integration.

Day-to-day Usage

The tool is designed to accelerate the task of delivering software to customers from both a management and packager’s perspective. Management gets a dashboard where they can get a snapshot of the organization’s application status and quickly see historical QA and UAT results, make sure SLAs are being met and so on.

Senior management may not want to open AppTracker on a regular basis (if ever) so instead we can subscribe them to daily Dashboard emails to keep them up to date with current status. And as you’d expect, the Dashboard is fully customisable (per-user if needed) meaning only relevant Dashboard widgets get sent to each manager.

GstOiE.png

Figure 1. The Dashboard provides a snapshot of the organization’s application status


AppTracker provides an end user portal where one can search the currently supported (i.e. packaged) software titles, and can also raise new requests. Management can then review these requests and either accept them (they are then moved to the main queue) or reject them (they are marked as rejected and go no further).

Once an application has been accepted into the main queue it’s likely it will go through some form of “requirements gathering” process where the installation requirements (OS, middleware, dependencies, etc.) will be recorded, along with any installation and configuration instructions. Licencing details may also be collected here using a customisable form known as a “questionnaire”.

Once an application is ready for packaging or virtualisation the ITNinja integrations comes into play. You can quickly search for tips on each application across the ITNinja software library and then “pin” the relevant ones in AppTracker. When you revisit that application you will get the latest set of tips displayed (they are not stored offline, so any changes or updates are not missed). When it comes to streamlining application packaging, I’ve long been an advocate of checking what community tips exist as part of the process and this integration goes a long way to helping capitalize on this critical step.

BuOuTj.png

Figure 2. ITNinja integration speeds up the packaging process


Once you’ve built a package, the next step for an application is typically Quality Assurance. This effort aims to ensure the application meets internal standards, and prevents those embarrassing moments where an app is presented to the business for the first time in UAT only to find that there is some issue with the way it has been packaged. AppTracker provides a “questionnaire” (custom form) for QA that allows you to setup the checks exactly as you need them. You can even add custom buttons to the form to run PowerShell scripts to make use of automation if you like.

cJTz7F.png

Figure 3. Applications with their QA results


User Acceptance Testing (UAT)

AppTracker is one of the few tools which facilitates UAT. It allows you to setup a “Test” for an application which takes you through a wizard where you can specify who in the business should be doing the UAT, when they will do it, which department/office they will be approving it for, and which machine will be used for the UAT. AppTracker then sends that person an email with a calendar file to add it to their Outlook, it includes and RDP file so they can connect to the test machine, and they get a link to the sign-off page on the AppTracker portal where they can post the results (including screenshots) of the test. Once submitted the full results are viewable by AppTracker administrators.

API

Although I didn’t have time to play with it, the team at AppTracker assured me that the AppTracker API is quite powerful. There are PowerShell cmdlets available to handle automating most tasks in AppTracker, and other systems can be easily integrated by using AppTracker’s event and schedule driven API to call PowerShell scripts. I’m told many customers use the API to do things such as populate Active Directory groups for app deployments.

Hosting

AppTracker is offered as a hosted solution in Microsoft Azure (“AppTracker Cloud”) or can be installed on-premise. Installing locally, it requires a SQL server and an IIS server, a file share (for storing attachments) and an optional SMTP relay for email notifications. If you decide to go for an on-premise installation this is typically handled by an AppTracker consultant but I’m told takes only an hour or so as it is a pretty simple process. I used AppTracker Cloud so don’t have any first-hand experience of the installation.

Customization

It is clear that AppTracker is a highly configurable product; this makes perfect sense as every organisation will have a different set of processes and controls around application management. AppTracker allows you to customise the standard processes each application will pass through (typically something along the lines of Identify, Discover, Packaging, QA, UAT, Deploy, Live) and it supports sub-processes with SLA controls so that a package can sit in “Packaging, On-hold” while we wait for the procurement team to tell us what the licence key is for a product without this impacting its SLA.

7LkgLX.png

Figure 4. Default Application process and sub-processes


Each application has an “App Details” screen where various data fields can be added or removed as required. Here you can also add custom fields in the form of text fields, date fields and drop-down boxes.

Across the product you have the option to show/hide/re-label many of the tabs and fields so that you can tailor the product meet your exact requirements.

Summary

My short time with AppTracker has shown me what a huge amount of functionality is available in a very well presented solution. It’s highly customizable and easily extensible thanks to the API. While not my focus here, it is worth noting that there is a lot of migration management and optimisation capabilities here too, though I didn’t have time to investigate this. It’s well worth taking a look.

More info: www.apptracker.co.uk

View comments (1)
Showing 1 - 4 of 4 results

Top Contributors

Talk About Application Packaging