Application management is one of the most complex activities admins face when working with distributed desktops. Applications embed themselves deep into the operating system when you install them on a computer and because of this, they may cause issues with the system when other apps are installed on the same computer.
In the past, the applications that caused the most concern were those that did not conform to the Windows application development standards. This occurred mostly with applications designed for
Fortunately, those days are mostly over. Independent software vendors (ISVs) and internal programmers now understand the concept of access rights, which they take into account when preparing new applications. After getting the hang of what was needed to program for Windows NT and later for Windows 2000 and XP, Microsoft threw another curve by changing everything with Windows Vista.
Vista now sports the new User Account Control (UAC), an environment where every user, even administrators, run all processes with a standard user token and where access rights elevation requires explicit permissions. Sure, you can turn off UAC through a few Local Security Policy (LSP) changes (see Figure A), but who's going to do that? In this world of viruses and malware, it's a really good idea to know when processes require elevation, and that's despite Apple's funny TV ads.
When programmers became familiar with key Windows folders, such as Program Files, Windows, System32 and Documents and Settings, Microsoft opted to change either the name or the behavior of these folders. For example, Windows Vista now includes a Users folder instead of Documents and Settings. In addition, the Program Files, Windows and System32 folders are completely locked down and protected through Windows Resource Protection -- a feature that automatically repairs key changes to either the file system or the Windows registry. New folders such as ProgramData have been created to store application-specific configuration data. While these changes may be reflected in new applications that are designed for Vista, they won't be evident in applications that were designed before Vista's release, even if they conform to previous Windows development guidelines.
In comes Vista's file and registry virtualization
In order to limit the potential damage that Microsoft's changes to the OS might have on older but compatible applications, the company introduced a new feature to Windows Vista: file and registry virtualization (FRV). It's important not to confuse FRV with application virtualization, which is provided by applications from vendors such as Thinstall (now part of VMware), Citrix (Presentation Server), Microsoft (SoftGrid) and Altiris (Software Virtualization Solution). The latter are true virtualization technologies that abstract operating system components from virtualized applications and ensure the application will work on any Windows platform. FRV, on the other hand, is a subset of functions that are embedded in the Vista operating system. Why Microsoft did not choose to embed true application virtualization in the OS is anyone's guess, but there it stands. If you want true app virtualization, then you must purchase another tool.
FRV is designed to provide compatibility support for pre-Vista applications. When you install an application, it thinks it is writing to the Program Files folder, when, in fact, file virtualization actually redirects it to a User container -- one where the standard user will have full access rights. Of course, this is only for application components, which require read and write access by users during operation.
In the same vein, registry virtualization redirects any read-write application-related operation from HKey_Local_Machine\Software to HKey_Classes_Root\VirtualStore\Machine\Software in the registry. As you can see, both of the features supported by FRV are a far cry from true application virtualization products and are really only intended to provide app support in Vista.
If you're a developer working to create applications for Vista, don't learn to rely on FRV. Microsoft has already stated that future versions of Windows will not include FRV and that it was only included to promote Vista acceptance. Judging by the rate of Vista adoption, this strategy worked really well.
We recommend you do one of two things:
- Write applications according to Vista guidelines, storing all read-write operations in a per-user storage container or in one of the other allowable containers such as ProgramData.
- Use an application virtualization product to package and deliver your software. Agentless app virtualization technologies, such as Thinstall where the virtualization agent is embedded directly within the packaged application, are ideal for this since they require no further action to work.
Preparing and managing applications in a distributed computing world is a daunting task. If there are any ways that would make it simpler for both programmers and systems administrators, then you should take full advantage of them. Who knows, perhaps the next version of Windows will have true application virtualization capabilities embedded within it. Until then, everyone needs to work with the best possible solution, which, no doubt is app virtualization.
ADMIN GUIDE TO APPLICATION VIRTUALIZATION
lifecycle management made simple with app virtualization
- The problem with traditional application management practices
- Can admins rely on built-in Vista features for application support?
- 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. Danielle is Microsoft MVP in Virtualization and Nelson is Microsoft MVP in Windows Server. They are authors of multiple books, including the free Definitive Guide to Vista Migration for Realtime Publishers and Windows Server 2008: The Complete Reference for McGraw-Hill Osborne. For more tips, write to them at firstname.lastname@example.org.
This was first published in February 2008