In my previous blog here I provided an overview and “what is” application virtualization and Microsoft App-V. In this post I will attempt to move beyond the basics and try to address the good, the bad and the ugly of application virtualization with Microsoft App-V.
Desktop and Application optimization…
If you read my previous post you should now have an idea what application virtualization and Microsoft App-V is and what it can provide to a computer network. I remember reading somewhere that “a operating system is at it fastest and optimal post a fresh install and before any applications are deployed”. This is something I and I am sure any IT pro will agree with and while we would love to keep our machines in this optimal state usually an application or two is required. Now meet my friend App-V, this neat little application can conceivability keep your machine as close to a fresh install as possible as applications are not installed in the traditional sense.
What do you mean the application is not installed?
Microsoft App-V for example provides a virtual registry and virtual file system. When a sequenced or virtualized application is deployed to a Windows Vista workstation the application does not sit in c:\program files\… or write to [HKLM\Software\Microsoft\…] it is truly sandboxed and held at arms length from the operating system. As far as the application is aware it is installed locally however when it writes to the local registry that application call is redirected to a virtual or “faked” registry, this also hold true for the file system.
What you see is an application laid down on disk but does not “taint” the local operating system with crazy registry entries or participating in DLL hell.
Can I virtualize application xyz?
Now not all applications are created equal and not all applications are a candidate for virtualization, what I mean is not all application will function within a virtual environment or even sequence correctly in the first place. Generally applications that fit the following list may not be candidates however all applications are different and everybody's experiences are different.
- Applications that install a boot time service.
- Applications that use COM+ (check here for more info and workarounds)
- DLL’s that run in Dllhost.exe AKA COM DLL surrogate virtualization.
- MAPI applications check the following link for help.
- Internet Explorer (google or bing :-) this, some believe you can).
- Device drivers or any application that uses them (unless you can install the device driver separately and locally from the sequenced application)
- Applications for example that are tied to a machine or tied to a system’s MAC address.
- Helper applications such as those with a multifunction printer… the root of all evil for any virtual environment :-)
- Operating system hotfixes in any way shape or form.
- most (but not all) antivirus applications that use filter drivers that interact with the operating system directly.
- Some windows services.
So what is actually virtualized?
One of the great things about App-V or application virtualization in general is the ability to uninstall an application and ALL settings, binaries, registry entries, and random configuration files are removed no ugly desktop icons or folders in c:\program files or manually remove
When a file is sequenced the following is a list of what is wrapped up into well… a sequence.
- Files
- Fonts
- Registry entries
- INI files (oh the horror!)
- Namespaces
- Services
- COM/DCOM objects
What methods are available for application virtualization?
There are three methods available for deploying application virtualization when utilising Microsoft App-V, standalone, streaming and full infrastructure.
Standalone – Enables virtual application delivery to businesses that may not have the backend infrastructure to support streaming or the full infrastructure model. The only software required is the sequencer which can sit on a workstation. Applications are sequenced and packaged into a MSI (Microsoft Installer) which contains all the information required to deliver and install the virtual application. This model requires a method of application delivery either manual (CD/DVD or USB) or automatic (SCCM, AD or some other package deployment tool). This model is also best suited to users who are remote or disconnected from the network.
Streaming – Model consists of the streaming server, the sequencer and the App-V client. Applications are placed on the streaming server where they are downloaded or streamed to the client on demand. When streamed a client receives what is called “feature block 1” then obtains further blocks when needed this leads to faster start-up times for applications.
Full Infrastructure – Requires the largest investment in “infrastructure” as it consists of one or more Microsoft System Center Application Virtualization Management Servers and the App-V client on workstations or Terminal Servers.
Allot of IT adman's find the “streaming” model works for them and can easily leverage existing servers and software onsite.
Client considerations…
Always ensure a large enough cache has been provisioned (2GB standard) perhaps 4GB is better. Ensure clients are pre-cached on Terminal Server’s for best performance and user experience, and remember at this stage only 32bit (x86) operating systems are supported. (This will change with App-V 4.6)
Sequencer Considerations…
Provision an isolated and dedicated workstation for application sequencing. Ensure this workstation does not have any background applications or agent software loaded. If you are not sequencing Microsoft Office but it is part of your base workstation image make sure it is also loaded to the sequencing machine. The sequencing machine must have a second drive letter that matches the virtual drive used by the client, this could be a network drive or USB drive for example. The default drive is Q. Deploying to a staging environment is recommended.
My first post on App-V is available here.
Blog, Virtualization, Windows
app-v, virtualization