Hi All,
As the version on this might suggest, I have actually created a few different version of this already, all based on different versions of App-V. Well this iteration is for App-V 5.0 SP2. I made some pretty ballsy changes this time around. I’ll explain in line!
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 (Connection Groups) 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. However, this comes with a slight update. 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.
COM+ for this little bugger, I decided to split this off from DCOM, I previously put DCOM\COM+ together but after more extensive investigating, I decided this should be split. Why? Well, I have yet to find an application with COM+ that works when sequenced, whereas I have found apps with DCOM that do work. Interestingly, I have noticed that the latest Sequencer actually reports on these seperately now. So maybe Microsoft thought the same way that I did. So, if you see COM+ show up in the Sequencers report, I would advise keep it local.
DCOM as I have suggested in the previous paragraph. May or may not work, so I advise sequencing, testing and if it does not work, proceed with keeping this local.
Drivers. Does your application contain Kernel Mode Drivers, if it does unfortunately these cannot be sequenced. Your options here are to either: Don’t sequence any applications that contain drivers or split out the applications. Create an MSI for the drivers and a sequence of the applications minus the drivers. Deploy both to the users and the virtual application should be able to use the driver when installed on the local machine. Nicke Kalle provided a really good article regarding a clever way to do this using the new Deployment Config file which is part of the standard output format in App-V 5.0, I suggest you take a look at this HERE If you follow his instructions, you can deploy both together in pretty seamless manner.
Addins can be virtualized, you can then use RunVirtual (must use Global Publishing) to allow your locally installed Office. Of course, if Office is virtualized in your environment, you can obviouslly use Connection Groups so the Add-ins can be seen and work using the virtual Office. RunVirtual at the moment has seen some mixed success so you will want to test and ensure your Add-ins work as expected, if they do not work or you don’t want to use RunVirtual for some reason, you could always create a shortcut for each Add-in which is pointed to your local Word, Excel etc. But that leads to a slew of shortcuts ,which essentially launch the same application.
For this version, I made the ballsy decision to remove Context Menus\Shell Extensions as thus far with my testing I have successfully been able to virtualize these in all cases. I say it’s ballsy as in one case, the sequencer did not pick up on the context menu automatically, I had to create it through the registry again, but it did work then, so it could be virtualized.
Other issues I’ve found that should be considered also is File Type Assosiations. You should find out what the core applications on the users machine are and request that you be provided with an exclusion list as users may not want a commonly use file type to open in a virtualized application. E.g. you might virtualize Notepad++ and the FTA for .txt is included. Would you really want your user to doube click their text file and Notepad++ stream or load from the APP-V Client. Probably not! Also a point of interest for you, Certain protocols that did not work in previous versions of App-V, now work, such as the mailto protocol.
How will Firewall exceptions be handled? Back in the days of old Windows Firewall you could set exceptions through the registry. That is no longer an option with advanced firewall as the exceptions are created uniquely and so needs to be run for each instance. You could get around this by simply setting your Firewall exceptions centrally using either Group Policy or whatever Firewall Software is at your disposal.
As of this post, there are a few things to be aware of from a sequencing standpoint that were not a concern in previous version. That being the possibility of requiring to set Folder or File permissions for application which require to write or modify to non-writable locations during run-time. Dan Gough has you covered on this if you follow his instructions HERE Also as pointed out to be by Dan, branched upgrades which were possible in previous versions are no longer possible. I believe this one is likely a bug and will hopefully be resolved soon.
Big Thanks to Aaron Parker for his amazing work on updating the design of the decisiom matrix. From the very first version, I have been critical of the look! This version looks sharp. Thanks, Aaron!
