App-V vs. Terminal Services – Which one, when?

Both App-V and Terminal Services/Remote Desktop Services can reduce the amount of time an IT Professional spends installing, managing and troubleshooting applications on desktops. Both technologies allow you to install, upgrade and manage an application in one place (on a server) and allow multiple users access to those applications. And then the similarities start to end.

Terminal Services/RDS is based on session hosting. The users must establish a session with the host server to access the application. Depending on what version of Windows Server you are using, the applications can appear on the desktop seamlessly using either RemoteApp or other 3rd party technologies. While this is great for workers who are located locally in the office or are regularly connected via the Internet from another location, the applications are not accessible when the client machine is working offline.

App-V streams the packaged applications to the client machine, which are then cached locally for use while working on or offline. The applications can be managed and updated on the server side and the client machines receive updates when they reconnect. This allows for better control of the overall software lifecycle and ensures that every client is running the approved version of any given application.
When it comes to support for legacy applications, especially those that will not run on Windows 7, App-V isn’t necessarily going to be the solution. Any application streamed from App-V must be sequenced and packaged for the destination operating system, though I’ve heard of some success with XP-sequenced apps working on Windows 7, so your mileage may vary. App-V requires the applications to interact with the client operating system in order to take advantage the local system resources. This is also important for applications that must interact with each other and with the local drivers on the machine, to deliver an experience similar to having the application installed in the traditional fashion.

If you have an application that won’t run on Windows 7, you’ll have to turn to a solution other than App-V. If you already have a legacy Server 2003 Terminal Services infrastructure in place that can deliver the application, it might be easier and more cost effective to look at using that instead of deploying MED-V. (See my post on TS vs. MED-V in April.)

Legacy applications aside, what if all your applications are Windows 7 ready? Can RDS make more sense than App-V?

First, you have to consider your users. Do the work online or offline? Do you have the RDS infrastructure to support having EVERYONE access applications during the work day? Having everyone access hosted applications is resource intensive on the server. If you currently have an implementation that used for only a few remote workers or for little used applications you’ll have to look closely at how much those servers will be able to support. App-V might be a better fit if you want to take advantage the resources on the local machines instead.

You can also combine App-V with Remote Desktop Services to make better use of server farm resources. Ultimately, there are a lot of different ways to deliver software to your end users and it doesn’t have to involving managing applications on each desktop.

Inside MDOP: MED-V and App-V

Inside the Microsoft Desktop Optimization Pack, you’ll find MED-V and App-V. Both provide ways to deliver applications to your desktop, but they solve different problems.

MED-V is good for resolving incompatibilities between an application and Windows 7. By creating and distributing a full instance of Windows XP from which the application runs, users can access applications that would not run on Windows 7 otherwise. It’s also applicable for websites that must run in a browser like Internet Explorer 6. For example, an IE 6 instance can be launched from within the MED-V managed OS and be controlled with policies to limit the sites that are available from the less secure browser.

In general, a MED-V hosted application is isolated from the primary operating system, though the clipboard can be shared to allow for basic copy/paste functionality between applications and printer redirection can ensure users can print from the MED-V application. If your application is very task specific and does not require direct interactions with other applications on the primary operating system, MED-V can allow you to upgrade to Windows 7 before solving the application compatibility issue.

Application Virtualization (App-V) creates and delivers a single application in a package, instead of a full instance of an operating system like MED-V. The application package is cached on the local machine, but in not installed in the traditional sense. By not installing application files directly and keeping them isolated in their packages, App-V can eliminate conflicts between two applications that might otherwise cause failures when installed on the same machine. An example would be where Office 97 and later versions of Office share DLLs with similar names, but have functionality that doesn’t work with both products.

App-V also eases application upgrades and maintenance by allowing IT to update single packages that are then streamed to users on demand, instead of having to managing multiple local installations of software. Because applications deployed with App-V execute locally on the desktop they utilize the CPU and memory resources of the local machine instead of those on the server. Inter-application communication with other App-V applications and applications installed locally are preserved, allowing for cut and paste, OLE, and all other standard operations. However applications that install their own device driver, like a print driver, may not be suitable for complete virtualization.

In a nutshell, App-V can help you develop a more robust and controlled application management lifecycle, while allowing support for some legacy applications that don’t play well with new versions. MED-V builds a “temporary” bridge between applications that only work on older operating systems, providing some wiggle room so you can potentially upgrade your desktops without having to wait until all your applications are supported.

Depending on the needs of your organization, MED-V or App-V might be just what you need to solve a lingering application compatibility issue.