While most applications can be successfully virtualized for use with SoftGrid, some applications may have certain characteristics that would prevent them from being completely virtualized using the current version of Microsoft SoftGrid.  This includes:

1. Applications that install and rely on a system-level driver, i.e. an application that installs a print driver or a USB device driver. Some applications may allow for the drivers to be installed independent of the other components of the application. As a work around for this scenario, the driver portion of this application could be installed locally on the client system, allowing the other components of the application to be virtualized.

2. Applications that install boot-time services (like RES PowerFuse)

3. Applications that use COM+.

4. MAPI virtualization. For information on SoftGrid and Microsoft Office, see the following article:939796 Prescriptive guidance for sequencing 2007 Office programs in Microsoft SoftGrid http://support.microsoft.com/default.aspx?scid=kb;EN-US;939796.

5. COM DLL surrogate virtualization, i.e. DLL’s that run in Dllhost.exe.

6. Applications with licensing enforcement tied to machine, e.g. the license is tied to the system’s MAC address. (Due to sequencing issues; this just wouldn’t make any sense) 7. Anti-Virus!

Some of the applications that fall into these categories can possibly still be run in Microsoft SoftGrid as long as the component that cannot be virtualized is installed locally on the same machine as the SoftGrid client. This solution may solve the issue but is not a guarantee the applications will properly function. We recommend you test the applications thoroughly to ensure they meet the expected level of functionality.

Check this out too…..

With all the features discussed to this point in this series, you would think that Terminal Services is a solution for all the applications in your environment. Just move every application over to your Terminal Services servers, and your problems are resolved. Users can access applications from anywhere, they do so with the same profile information, and you never need to waste time installing applications locally.

But Terminal Services is no panacea. The limits of physics, your available hardware, and your pocketbook make some applications non-candidates for your Terminal Services environment. There are some good and established rules of thumb in helping identify which apps might not be good for Terminal Services hosting. Consider the following types of applications as those you may not want to host via Terminal Services:

• Applications with high resource usage. Most client/server applications split their processing such that the server does most of the work. Yet some applications require a heavy-duty client for the purposes of crunching data received from the server half. Those high-utilization clients may incur high levels of processor utilization or require high quantities of RAM to accomplish their mission.
• Applications that require full-motion video or high screen frame rates. Although the Citrix platform has an improved capability for supporting full-motion video or high screen frame rates, Terminal Services’ RDP is much different. Applications that require video or internal screen movement do not render well over RDP, a problem that is further exacerbated when the network connection between Terminal Services client and server grows latent. If your application requires this sort of video rendering, consider the use of Citrix or a local installation.
• 16-bit applications. 16-bit applications running atop Terminal Services tend to incur high levels of Context Switches in their processing. These context switches incur a major performance hit on your Terminal Server, affecting other users. This being said, 16-bit applications suffer everywhere in a modern IT environment. So, their hosting via Terminal Services may be a boon simply to get them off individual desktops. If you plan to host 16-bit applications, consider siloing them onto specified Terminal Servers away from other applications.
• Applications that require administrative access. Applications that require Administrator access in order to run are non-starters for Terminal Services environments. This is the case because you are not likely to want to give administrative privileges to standard users on a shared service like Terminal Services.
• Applications that interface with peripherals. Terminal Services’ support of attached peripherals has improved over time. In fact, Terminal Services with Server 2008 now includes add-on support for Point-of-Sale applications and the peripherals that work with those applications. Yet Terminal Services has always lagged behind Citrix in terms of the types of peripherals that can be pulled into a client session.

With these suggestions in mind, the other applications in your environment now become fair game for hosting atop Terminal Services. Keep in mind that the more collocated applications you host on a single Terminal Server, the greater overall resource use you can expect out of that Terminal Server.