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
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.