Just a quick note to say I’ve updated the AppV launcher tool to support Appv 5.
The app-V launcher tool is a self contained executable which lists your installed App-V packages and allows you to launch an executable in that virtual applications environment. This is particularly useful if you or your admins / users are not PowerShell friendly or you would prefer to not publish PowerShell scripts as programs.
You can get a copy of the latest version and/or it’s source code over here.
As an added benefit I’ve included source code for running PowerShell commands in .Net, so if you are interested in trying to do so grab the source code!
App-V user preferences are cleverly tucked away from the file system and registry, which works great for terminal services as you dont want conflicting applications running side by side and sharing registry or file system resources.
The only real problem with this structure comes to light when an application is in need of a reset, and the local c: drive is hidden. This results in the call from the helpdesk coming up the chain of support to the admins with rdp access to the desktop servers.
The users still have access to c: and if they had access to cmd a quick rd /s /q would get them over the issue and into a nice fresh App-V bubble again. So I decided to give the users / helpdesk a tool to manage these preferences themselves without needing access to cmd, or any other potentially elevated access.
I’ve named the tool App-V maint, it simply reads the users datadirectory from the registry, and populates the list box.
The users dont need any elevated priveledges to run it, and it only depends on .net framework 2.0.
To grab a copy head over here and download it.
If it doesnt work for you, or if you would like a similar product for a different folder, just let me know and we’ll work something out for free.
If you like the concept and dont mind getting your hands dirty with visual studio 2010, email me for the source code.
It amazes me in this day and age that something as fundamentally simple as the clipboard in a windows environment can have issues, but it does happen… Especially in a multi user environment.
If you experience clipboard issues with office, Lotus notes and other copy and paste capable programs you may have a session memory issue!
The session View size and pool size have a massive part to play in 32 bit citrix environments, these size options dictate the amount of graphical memory that can be assigned to each session. The ceiling for these options in 32 bit are just 16mb, which rediculously low in modern days.
Taking equal parts of graphically heavy applications like Office 2007 and Known citrix killers like lotus notes, it really isn’t long until these limits spill over into horrible clipboard and copy / paste disasters. Take one step further and implement Microsoft App-V and you are in serious trouble.
If alike me, you run an environment that requires all the above nasties, help is at hand. After 12 months of continued troubleshooting I’ve found a happy medium of 64mb between low limits and too high limits.
To test the same, simply bash these off the following command lines and reboot, waving goodbye to your horrible clipboard issues:
reg add “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management” /v SessionPoolSize /t reg_dword /d 64 /f
reg add “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management” /v SessionViewSize /t reg_dword /d 64 /f
We currently run with 10gb of memory, allowing us to allocate this extra 112mb of memory per user. If you require these options, consider a lower value or upgrade your ram capacity
In our powerfuse environment we came across this problem recently.
When we would try to launch an App-V application the following window would open and remain open for 30 + seconds before finally opening the application:
The problem we discovered was to do with file type associations inside of the RES session, App-V by default will try to associate it’s file type associations for the application being sequenced and store them in the .osd file. The problem was that PowerFuse also controls file associations and this became an issue! PowerFuse has to be associated with the app and not vice versa.
I recommend you specify the file type associations inside of powerfuse and remove the associations inside of the App-V package. To remove the associations, open the .osd file and remove anything between the <FILEEXTENSIONLIST> </FILEEXTENSION>:
After the link is an example.