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:
- Installations affect the operating system and update it with the application's components, which changes the operating system at both the file and registry levels.
- Because the application may include components that are normally found within the operating system -- for example, system-level dynamic link libraries (DLLs) -- they may cause conflicts with other applications that coexist on the same system.
- Since you need to deploy applications without user interaction, you must package them to automate their installation. In addition, to fully support the application lifecycle, you should integrate these packages with the Windows Installer service, an internal Windows service that is designed to standardize application installations.
- Because applications have a lifecycle that at some point in time reaches its end, they must be removed and retired from the OS they reside on. Once again, this removal process must be performed without user interaction.
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.
 |
|
|
|
|
When Microsoft released the first version of [Windows Installer] several years ago, administrators everywhere thought it would be the end of DLL hell.
|
|
|
|
|
|
|
|
|
|
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 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:
Newly-released applications that conform to all operating system standards.
Legacy applications that were designed for previous versions of operating systems and that may not work properly with newer OSes.
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
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.
ADMIN GUIDE TO APPLICATION VIRTUALIZATION
Application lifecycle management made simple with app virtualization
The problem with traditional application management practices
Centralized app management in Windows Server 2008
Combine app virtualization with streaming
|
| Danielle Ruest and Nelson Ruest are IT professionals specializing in systems administration, migration planning, software management and architecture design. They have written several books and are currently working on the Definitive Guide to Vista Migration for Realtime Publishers as well as the Complete Reference to Windows Server Codenamed "Longhorn" for McGraw-Hill Osborne. They have extensive experience in systems management and operating system migration projects. For more tips, write to them at info@reso-net.com.
|
|
