[IMAGE]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.
[IMAGE]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 Windows NT. When programmers made the transition from Windows 3.x (an environment where everyone had all access rights) to Windows NT (the first Microsoft OS that provided true access control), they didn't necessarily move to the new programming model. Lots of programmers made one common mistake -- they developed and tested everything with an administrator account. Then, when it was shipped to an environment where users were locked down, the application wouldn't work.
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.
Figure A
[IMAGE]
When programmers became familiar
To continue reading for free, register below or login
To read more you must become a member of SearchVirtualDesktop.com
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:
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.
[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]
