Home » 5.0

Tag: 5.0

App-V 5.0 apps not working when published as seamless applications

Scenario:

Our AppV Applications on Citrix are published globally to the citrix servers computer accounts so the apps are available before the users login. These applications all launch and integrate with AppV either directly calling the AppV exe or by using the /appvve or switch on a hosted Citrix desktop. When the same AppV application is launched seamlessly the app opens but without AppV integration.

Solution:

*UPDATED* – The /Appvve: switch will work if published via Citrix, but only if the Application/s (in APPV) are published to the end user account (not just the computer accounts)

The /appvve switch doesnt work with Citrix published applications. Use the APP-v console to make the applications available for the end user/s or user groups and then script the launch of the app with powershell.

Launch_APP_JAMES.ps1

—— begin script——–

$appvname = get-appvclientpackage “James”
start-appvvirtualprocess -appvclientobject $appvname excel.exe

—— end script——–

I then publish this PS1 script from Citrix in the published app command line:

“C:WindowsSystem32WindowsPowerShellv1.0powershell.exe” -windowstyle hidden “\lonfs001xenapp$AppsSAPLaunch_APPV_JAMES.ps1”

Resources:

There is a myriad of other ways you can integrate or launch apps inside the APPV bubble see below link for more details. We were unable to use the ‘file type associations’ as we want normal excel to load without the APPV integration and add-ins and for select users have this APPV integration be available.

http://support.microsoft.com/kb/2848278

Does App-V 5.0 support Junction points?

YES!

We had an application that was old and a number of its ‘working files’ referenced c:\program files\PROGRAM, but the new version of the app was c:\program files (x86)\PROGRAM

This was embedded in many of the older files that referred to this path directly

During the APP-V sequencing a junction point was created with

mklink /d  “C:\Program Files\PROGRAM”  “C:\Program Files (x86)\PROGRAM”

And when the package launches this directory is ‘linked’ for the users seamlessly, without affecting the underlying server or needing to create the junction point on the server outside of the package.

Citrix Password Manager Single Sign on Registration launching for non members and admin accounts

Problem: All company users to be managed by password manager were added to group DOMAINPWDMGR. Administrators were not members of this group. When administrators logged onto a server / xenapp server with the SSO Agent installed the logon would hang / crash with sshoshell.exe running but with a blank desktop displayed. Terminating teh ssoshell.exe process would release the logon process and administrators could log on.

Situation: We have multiple versions of the old password manager 4.6, 4.8 and for our new project 5.0 installed and upgraded in various states of disarray from the original setup into our AD Central Store.  There was little confidence in the previous configuration (nor was there any documentation) so it was decided that the registration be revoked for all users, and the central store be upgraded.

We seemed to have multiple copies of registration details for the users in AD from various version of password manager and when using the console to revoke or delete a users password manager data – parts of the SSOSecret or SSOConfig for these users remained.

When performing a console delete in our testing environment with brand new users – all SSO* data for each user would be removed in its entirety.

There was little confidence in the previous configuration (nor was there any documentation) so it was decided that the registration be revoked for all users, and the central store be upgraded to 5.0

Solution for Upgrade:

Overall for the upgrade we delete all SSoCitrix and SSOSecret data for all users by selecting their top level OU and running separate AD queries for

(&(&(objectClass=citrix-SSOConfig)))

(&(&(objectClass=citrix-SSOSecret)))

They were then all selected and deleted,

NOTE: be sure NOT to include the central store in this query.

Solution just for Admins:

So even after this – all users would log in ok and get the appropriate ‘re registration’ but when SOME admins logged in the sshoshell would still launch and not continue the desktop login until terminated.

1) We changed pwd manager to run for ALL users (encompasing Admins) – and it was noticed that password manager would then let the admins in – but at a significantly slower logon time (35 seconds +) and then prompt them to ‘verify their identity’

It was obvious then that some admins had registered also for the password manager reset, and finally assumed that although they were not part of the original DOMAINPWDMGR ssoshell.exe was hanging because it could see the ‘registration data’ for these admin accounts from the old version of password manager…

3) revoking the password registraion for these accounts using then New Password Manager console didnt work (all SSOCitrix and SSO Secret details were left for those accounts)

4) finding the user account usign ADSIEDIT and manually deleting all registration entries for that account – worked.

When the admin logged in from then on 1) ssoshell would run and immediately prompt the admin for registration instead or hanging or asking to reverify, 2) we then reverted the User confuguration so it would only run again for DOMAINPWDMGR – and finally the process stopped running for admins.