Some administrators use snapshot technology, but the trend is to move to installation monitoring. This involves watching the installation and cataloging the information by monitoring the installation and building the new package out of that monitored process.
Snapshots involve taking a pre-snapshot of a target system, installing software, and then a post-snapshot to capture changes to the target system. But the problem is this method is prone to collecting a lot of unusable data. If I had antivirus software installed on a system, it would be changing things on the system. The operating system is also making changes that are being cataloged.
What is happening is you are overloading your packages with data that is not required by the functionality of the application you are packaging.
Though most IT professionals are certainly familiar with application packaging, would you please provide your definition?
When you mention
The reason to repackage is to automate an installation process. Systems administrators want to install the application silently. When users come in the next day, they will have a new application, or an update to an existing application, without knowing that anything happened to their system.
So why is installation monitoring a better deal?
Installation monitoring gives you a more accurate depiction of what is on the target system. It's cleaner; it does not pick up data caused by outside processes. And it's quicker because it's in real time.
Use a centralized system to monitor and control all the personnel process[es], workflows, data and communications involved in the organization's software management process. Centralized systems lead to a better success rate and turnaround time when managing these applications. What kind of information are these systems looking for?
When an application is requested, typically the request contains the name of the application. That's it. The individual packaging the application needs to know whether the application is developed in-house or off the shelf.
Also, what version of the software is the department using? What operating system and service pack? All that information is sent to an administrator so he can mimic the request when packaging the application. A lot of divisions are using old applications that are required by the business unit. What type of installer are you recommending?
Choose a standard, open packaging format that is networking and distribution system agnostic. That's MSI [Microsoft Installer]. The Windows Installer package has several desirable features. One is automatic replacement of damaged and missing files.
MSI is also becoming the standard installation format for many software vendors. Not only are administrators packaging their legacy applications to an MSI, software vendors are creating MSI installations for their software.
Previously, there was no standard way to install software. Vendors had proprietary installation formats. Administrators would receive software packages and become accustomed to one installer, then they would prepare another product and it would perform differently. MSI is an open architecture that lets administrators see exactly what is going to happen to their target machines.
So use installation monitoring, choose a standard installer like MSI, use a centralized management system. What else?
Administrators will benefit by using a virtual machine technology to package and provide quality assurance to the applications they are packaging. This will let you rapidly restore a system back to a known state on which to package an application.
Traditionally, a lengthy process known as "ghosting" is used for imaging a clean system. Using virtual machine restore/revert capabilities when a new application is needed to be packaged cuts the time required to restore systems between packaging and quality assurance (QA).
Administrators should also use a mechanism to check for reusable components between the various packages they are deploying to their environments. I want to know if the application I just packaged will conflict with any other package in my environment. And it's not just the applications, but the operating system. Will it degrade files? Will it overwrite registry keys? Delete other applications or operating file systems?
Use a conflict analysis tool to check applications for consistency across the environment.
Use QA tools. QA is not just a utility that gives guidelines on how to test the package. It can interrogate the packaged applications and present you with the test to perform on the application. So, it discovers the data within the applications that should be tested.
You must test the resultant packages in their intended environment. I can repackage a piece of software and it works great on my test machine, but it should work. I'm the administrator. If I'm deploying thousands of machines, not every machine is set up the same way, nor does it have the same user credentials.
What common mistakes do administrators make when preparing the packages?
One mistake with repackaging applications is the original media comes as a setup.exe, which would indicate to repackage, but the setup.exe may contain an MSI package. To determine if the setup.exe contains an MSI, execute the setup.exe and check the temporary directories of the target system for an MSI extension. If an MSI package is present, instead of repackaging the application, use a 'transform' creation tool to customize the package.
FOR MORE INFORMATION: