Self healing on Citrix - problem
I have an application (Summation iBlaze) which is installed on our citrix servers.
The server piece of the software is installed to a share and in doing so it generates the client msi install (also on the share).
After installing the client piece from the share (X:\share\) on our Citrix servers everything seemed to running smoothly. Then when users perform specific actions/launch other applications they get a prompt saying that the resource is unavailable and to choose and alternate path as the X:\share\install.msi cannot be located. It was quite obvious why, drive X:\ wasn't mapped as this is a restricted drive for only a few select users.
After a little digging around it seems that the detection of the component in question (set to 'run from source' with a keypath assigned) could not be located. (It seems that the entire app runs from the server as all most of the components are set this way)
Any idea's how I can stop these prompts from appearing for the users who don't have access to the network resource? My guess it that I could create a transform and unassign the keypaths as they shouldn't really be repairing anything on the server, but I was wondering if anyone else had any suggestions?
Also, why would just launching another app cause this one to check for it's components (seeing that only a few dll's are being written to system32?
The server piece of the software is installed to a share and in doing so it generates the client msi install (also on the share).
After installing the client piece from the share (X:\share\) on our Citrix servers everything seemed to running smoothly. Then when users perform specific actions/launch other applications they get a prompt saying that the resource is unavailable and to choose and alternate path as the X:\share\install.msi cannot be located. It was quite obvious why, drive X:\ wasn't mapped as this is a restricted drive for only a few select users.
After a little digging around it seems that the detection of the component in question (set to 'run from source' with a keypath assigned) could not be located. (It seems that the entire app runs from the server as all most of the components are set this way)
Any idea's how I can stop these prompts from appearing for the users who don't have access to the network resource? My guess it that I could create a transform and unassign the keypaths as they shouldn't really be repairing anything on the server, but I was wondering if anyone else had any suggestions?
Also, why would just launching another app cause this one to check for it's components (seeing that only a few dll's are being written to system32?
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
AngelD
17 years ago
As you may already know a user are not allowed to trigger MSIEXEC.EXE for a repair as normally done on any non-TS operating system. My guessing is that the user is missing some files which should be copied in some other way (non-msi technology). In my days when packaging for TS environments we always had read access for the user to the original database but we never did set components to run from source either. But I must admit that we added security permissions on the program folder instead for group members that would be allowed to run the program. In a login script we removed all existing shortcuts and re-created for the applications they were allowed to.
My guess it that I could create a transform and unassign the keypaths as they shouldn't really be repairing anything on the server, but I was wondering if anyone else had any suggestions?
By removing the component's keypath the directory assigned to the component (Directory column in the Component table) will be used instead and as the user do not have the share mapped a repair will be triggered anyway.
Use Event Viewer and Windows Installer verbose logging to find out which components that are "broken" (triggering the repair) to fix the mess.
Also, why would just launching another app cause this one to check for it's components (seeing that only a few dll's are being written to system32?
A common scenario why this happens is due to shared components between these applications (packages).
My guess it that I could create a transform and unassign the keypaths as they shouldn't really be repairing anything on the server, but I was wondering if anyone else had any suggestions?
By removing the component's keypath the directory assigned to the component (Directory column in the Component table) will be used instead and as the user do not have the share mapped a repair will be triggered anyway.
Use Event Viewer and Windows Installer verbose logging to find out which components that are "broken" (triggering the repair) to fix the mess.
Also, why would just launching another app cause this one to check for it's components (seeing that only a few dll's are being written to system32?
A common scenario why this happens is due to shared components between these applications (packages).
Posted by:
Heinz Treben
17 years ago
Dont package Advertised - and have a look that you get all Userparts (Registry Current User, Userprofile Files) separately..
You could solve this, when you work with batch-Files. Dont start directly the Application, with the Shortcut - start a batchfile, which copy all Files, import CurrentUser Registry, and start afterward the Application from inside the Batchfile...
If you have MSIs with CurrentUser registry and Profile-Files - delete them with a transform - afterwars you have export all needed things
You could solve this, when you work with batch-Files. Dont start directly the Application, with the Shortcut - start a batchfile, which copy all Files, import CurrentUser Registry, and start afterward the Application from inside the Batchfile...
If you have MSIs with CurrentUser registry and Profile-Files - delete them with a transform - afterwars you have export all needed things
Posted by:
AngelD
17 years ago
Having advertise information in the package shouldn't be a problem.
Though it's importent to install as per-machine.
HKCU registry will be populated from the shadow registry which will be written during install when user mode is set to install. So you don't need to remove the registry. But you should verify that any COM component registry information is set under HKCR (per-machine goes into HKLM) or HKLM and not under HKCU as HKCU\Software\Classes is not roamed by default.
But as Heinz mentioned, the files in the user profile will have to go there in some other way
Though it's importent to install as per-machine.
HKCU registry will be populated from the shadow registry which will be written during install when user mode is set to install. So you don't need to remove the registry. But you should verify that any COM component registry information is set under HKCR (per-machine goes into HKLM) or HKLM and not under HKCU as HKCU\Software\Classes is not roamed by default.
But as Heinz mentioned, the files in the user profile will have to go there in some other way
Posted by:
michaelnowell
17 years ago
I think I've got it figured out now. Turns out that the install registers several common dll's and ocx's to the X:\share\... and the other software attempts to use these which is why it's prompting for the network resource. Now I just need to figure out what the common files are and then re-register them back to the local computer.
Thanks for your answers.
Thanks for your answers.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.