A year ago this month I posted a decision matrix I put together listing some of the common issues when trying to sequence applications, it can be seen HERE. I gathered some feedback in the comments. I appreciate all the feedback I can get here. I have since updated the matrix to include the feedback and I also made it look slightly better. Let’s face it, it still looks like a smacked arse! A new addition here though is the fact I included Citrix as a possible end point. I figure it will be relevant to a lot more people out there now. So Again. Any feedback. Please let me know. You’ll need to click on it to enlarge. It got bigger!
All of these considerations listed are based on 4.6SP1 and do not account for the cool new features in App-V 5.0. Some of those features included extended support for Shell extensions\Context Menus, Improved handling for COM objects, Increased File Size Limits etc.
So firstly once again the detail behind each limitation:
Hardcoded licensing. What I mean by this is the kind of licensing that is configured to the machines MAC address. In this instance the licensing can live only for that machine and is not a good candidate to be sequenced.
Middleware. You are free to sequence middleware and then subsequently dynamically suite the middleware with the dependent applications, however you should be aware. If an application you have cannot be sequenced and needs a certain piece of middleware that you decided to sequence all of a sudden you are in a situation in which this app now needs the middleware installed on the local machine because the virtualized middleware is isolated and cannot be seen. My personal preference is to install all shared middleware onto the local machine, any middleware that is a once off or only used by a handful of apps that CAN be sequenced can then be sequenced to accomodate those apps.
Boot Time Services appear in some applications and as per the explanation for Shell extensions APP-V applications exist session based. You could try to see if it’s acceptable for your application to only work on launch and then reconfigure the service to start on launch rather than on startup. Another possibility is to configure the service to start on launch and setup an action to startup the virtual application. I wouldn’t do that though, it does work and I’ve done it before but I don’t like the idea of doing that for performance reasons.