Ok this is going to be short and is more of a suggestion based on my own experiences. So, like many of you reading this probably already know, you can publish App-V applications in Citrix XenApp. Recently I sequenced Mozilla Firefox 15.0.1 for use by desktop users. This is something I’ve done quite a bit and I always follow the recipe provided by Aaron Parker https://blog.stealthpuppy.com/virtualisation/sequencing-mozilla-firefox-13-with-app-v-4-6/ I’m not going to go into detail and try to re-invent the whee,l when Aaron has already done all the hard work. When sequencing Firefox for use with XenApp through the Web Interface I noticed a couple of things that I needed to change. So follow the recipe in the link and then make the following changes for use with XenApp if these changes make sense for you.
1.) Change the Downloads path
So the default option sends to the Downloads library folder, which likely you don’t want for your Citrix users. You can change this by modifying a config file, instructions HERE but what I found with sequencing Firefox is that if you really want you can launch and modify the settings you want like this path, which can be found in the options within your Firefox browser, you can then just clear the entire history by going to the Tools menu in Firefox. When you have completed your sequence you should check for your username and ensure there’s no hardcoded username in the virtual registry. I’ve found Firefox is pretty favorable to sequence though and does a good job of clean up when you just perform the clear after making the changes.
2.) Get rid of the WORKINGDIR
In App-V most applications you sequence will set a WORKINGDIR, This is like the traditional Start In within a shortcut. When publishing an application through XenApp by using the instructions I posted HERE ,if your application has a working dir you need to append the sfttray.exe command with [*%] to instruct XenApp that there’s a WORKINGDIR set and to use it, otherwise your app will fail to launch. That’s usually what you’d do but in this case if you do that with Firefox you’ll notice it will launch with two tabs one of which will be pointed to your WORKINGDIR. So what I did was remove the WORKINGDIR value. You can do this by removing the WORKINGDIR tags and replace them with just <WORKINGDIR/> This sets WORKINGDIR to blank. Firefox will now open correctly.
3.) Ensure you do Launch Firefox
You should ensure you launch Firefox and go through the initial wizard and select to not import Internet Explorer favorites. You can do that during the First Use tasks and/or when capturing your Feature Block 1. I actually do this for my desktop version also, but that’s your own preference, it’s up to you. Users can always import their favorites after the fact. The reason I am highlighting this is because if you are launching via the web interface it could try and grab IE favorites from the server it has been published on.
4.) Decide on whether or not you include Plug-ins
If your Citrix XenApp Servers are standardized and consistent you should be pretty safe to just sequence Firefox alone and allow it to use the plug-ins that are installed on the server itself e.g. Flash Player, Java, Silverlight, Shockwave Player etc. However if your XenApp environment is not consistent and maybe some of your servers are used as a stop gap solutions for some applications with issues in your desktop environment, thus you can’t easily predict what versions of plug-ins may be installed then it might a good idea for you to sequence the plug-ins and use Dynamic Suiting Composition to link them all together or you could suite all the application into the one virtual Package, this creates one large application, when plug-ins require to be upgraded, it means upgrading a large application and more bandwidth used when streaming down. If you don’t plan to put the application on many servers it may be a workable solution to just suite them altogether. And just pre-cache the application to speed up the first launch for users.
5.) If you Suited all plug-ins use pre-caching
As stated above if you did go with the option to sequence all plug-in into the same suite, then you should ensure you pre-cache it on the servers so users don’t have to wait for all of them to stream down on first launch. You may already be doing this on servers via a scheduled task using the SFTMIME /LOADALL command if you aren’t you could use a command to either LOADALL application on the server or pass a command for the specific application you want and just use /LOAD with the application as an argument. Or finally you could just go onto the server, ensure the application is pulled down to the servers client (which it has to be so it can be used via the web interface anyway) and then just go into the client, pick the application the Application Window Pane right click and hit load. Let it load and then it’s ready without need to cache on the first launch.
