[IMAGE]Previously, we discussed how application virtualization can be used to simplify lifecycle management. This article will take a look at some of the issues administrators face when dealing with traditional application management.
The problems are a major reason why organizations are turning to application virtualization solutions. When you work with traditional applications, you actually install the application on the operating system. And, because of that, several activities must take place:[IMAGE]
While these are not the only reasons why traditional application management programs can cause headaches for administrators, they make up some of the principal issues admins must deal with when managing applications.
Why DLL Hell is still around
When Microsoft released the first version of the Windows Installer service along with Microsoft Office 2000 several years ago, administrators everywhere thought it would be the end of DLL Hell -- the mixing and matching of conflicting system DLLs through application installations. After all, Windows Installer was designed to manage these potential conflicts. Still, lo and behold almost 10 years later, application conflicts still exist.
To be fair, Windows Installer and OS updates do provide some degree of protection from DLL Hell. For example, they include side-by-side DLL loading in memory and DLL redirection on a per-application basis and they have system protection features, such as Windows Resource Protection. However, conflicts have moved from the DLL level to other application components and, in some cases, to components that are part of the Windows Installer packaging process. Conflicts, for instance, can still arise at the product component, file, registry, INI file and NT service level -- and even product property levels.
This is one reason why traditional application installations must be packaged through sophisticated packaging
To continue reading for free, register below or login
To read more you must become a member of SearchVirtualDesktop.com
tools such as Wise Package Studio (Altiris), AdminStudio (Macrovision) or WinINSTALL (Attachmate). These tools include, among other components, a conflict detection engine that inventories all of the application's components and then detects potential conflicts with other apps packaged with the same tool. They also inventory an OS to include its contents in the conflict detection database, allowing you to see if application components will damage or change these OS elements.
These tools also support the validation of your package against common Windows Installer packaging errors through the application of internal consistency evaluation (ICE) rules. ICE rules evaluate the structure of a package against Windows Installer's logic. Application consistency evaluator (ACE) rules are also applied, which validate the package against other applications.
As you can see, DLL and other conflicts are the bane of all systems administrators.
Other traditional application issues
Organizations must manage different application categories for both commercially-produced and internally-developed applications, such as:
Organizations may also have to deal with custom commercial applications, such as manufacturing or machinery control apps, which are rarely updated by the manufacturer. Each application category has a lifecycle that is based on four phases (see Figure 1).
In essence, organizations must begin with the evaluation of a new application, which leads to the purchase of a commercial application or the internal development of a custom application. Once a company has the application in hand, administrators must then prepare it for implementation by running it through a packaging tool and integrating it to Windows Installer, as well as customizing its installation for the environment. Once the app is deployed, it must be maintained, which requires patches and service packs. Once it has fulfilled its purpose and has become obsolete, the application must then be removed from the system.
Figure 1. The traditional application lifecycle
[IMAGE]
The traditional application lifecycle is rarely applied in full. In fact, few administrators take the time to remove applications from systems even though failing to do so may cause licensing issues. Why? Because so many admins have had system issues with applications not being removed properly that they just don't bother. Instead, they wait until the system is re-imaged or a new OS is deployed at which point all of the applications on the system are erased and then re-installed.
Managing traditional applications is a "make work" project at best and keeps an entire industry at work. This is another reason why application virtualization is such a boon to every organization running applications. Virtualized applications will run on any version of Windows, require packaging only once and do not affect the underlying OS. When you consider all of these factors, it's time to start looking into application virtualization for your app management practices.
[IMAGE]
[IMAGE]ADMIN GUIDE TO APPLICATION VIRTUALIZATION
[IMAGE]
[IMAGE] Application lifecycle management made simple with app virtualization
[IMAGE] The problem with traditional application management practices
[IMAGE] Can admins rely on built-in Vista features for application support?
[IMAGE] Centralized app management in Windows Server 2008
[IMAGE] Combine app virtualization with streaming
[TABLE]
