Dynamic Packaging - No More Need for Repackaging with Login AM
Why send your application packages through a lengthy packaging process to customize them when you can tailor them yourself quickly on the spot? Software packaging for electronic distribution is a well-established practice in many organizations. No matter if applications are packaged using MSI or virtualized using Microsoft App-V or VMware ThinApp, nobody really seems to stop and think about the necessity of it all. Many do not realize that packaging is one of the most expensive and time consuming parts of an application and desktop lifecycle.
There are two main packaging strategies for handling situations where differentiation is needed. Most commonly, organizations create additional instances of their packages for each specific situation. They might have a deployment package for SAP which is suited for deployment for external contractors on virtual desktops and they might have another deployment package for SAP which is used on regular desktop systems.
The other strategy is to create so called ‘transformations’ for each unique situation. Transformations allow for much greater flexibility. Transformations capture the exceptions for a package that apply to a specific situation. In this case, the previous example would result in 3 files. The original package and 2 transform files: one for SAP on the regular desktop and one for SAP on the virtual desktop.
Like creating and maintaining multiple versions of the same package, the process of creating good transformations and keeping track of them is a specialty that is not mastered by many and needs to be documented meticulously.
Application virtualization is often mentioned as the ultimate solution to make the packaging process easier, but this is not the case. Application virtualization technologies like App-V solve specific interoperability and deployment issues, but they do not address the complexity of packaging. If anything, application virtualization adds an additional layer of complexity and because not every package can be virtualized, organizations are left with a mix of both traditional packaging and application virtualization technologies.
It is important to realize that packaging is the first step in a long, complex and risky deployment process. The further you need to go back into this process, the more risks you are taking and the harder it gets to mitigate or recover from those risks.
Steps for IT and business consumers
Login AM allows for a very flexible just-in-time adaptation of existing packages with easy to use actions. Without the need for in depth scripting or packaging skills, Login AM gives the hosted desktop administrator the tools to adapt packages to his environment without having to create multiple versions of the same package or creating any transformations. Maybe even more important is the fact that these Login AM adaptations are not hidden in some package but are clearly visible.
Disable autoupdate feature in Adobe Reader
Using Login AM, organizations can deploy and maintain virtual desktop environments using the exact same packages and scripts that are also created for the regular desktop without the need for transformations or to build multiple versions of the package. In most cases the virtual desktop administrator can simply use vendor supplied packages, eliminating the need for packaging the applications altogether.
The Login AM approach also allows the virtual desktop administrator to update or ‘fix’ packages more easily after they have already been deployed. Instead of having to pull back the original version and deploying the new version, Login AM administrators simply deploy the update or fix independently of the package. Again skipping some time consuming packaging steps.
I'm curious for your feedback. How do you handle your packaging? How much time does it take you to package your applications and do you experience the same issues as described above? Let us know.