We are trying to recycle an old MSI that installed the runtime by installing a series of Merge Modules written by Wise. The issue we are noticing in our new Windows 2003 Citrix environment is that we are having some COM issues. For example when we make a call to cyrstal reports to generate a report from sybase the application fails because cyrstal reports decides to look for the required dll via H:\Windows\.... rather than C:\Windows.

Now to my real question. What is your view as to the best way to install the Crystal Reports Runtime 8.5?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Hi kkaminsk,

Sorry can't help you will with the "best way" question.

But I was thinking of your folder issue. Did you install the msi in install mode (change user /install)?
Is the windows folder redirected or the %windir% env changed to the H:\ drive?
Is the ROOTDRIVE property set to H:\ or is there a set directory CA pointing the WindowsFolder to H:?
Answered 08/02/2006 by: AngelD
Red Belt

Please log in to comment
0
The package was installed through the Citrix Installation manager so it did get installed correctly. The environment variables check out but for fun I did perform an install from the console using ROOTDRIVE=C:\ to see if anything changed. It still failed and if I check the COM registrations in the registry everything looks ok. Man this problem is so much fun!
Answered 08/03/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
try inserting a ResolveSource action with a conditionn "NOT Installed". It should come after the CostFinalize action in the InstallExecuteSequence table.
Answered 08/03/2006 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
I have not tried that yet but I did find out how to get the MSI to work. I have to be logged into the console (console might not be required) and do the old change user /install. I guess there was some wisdom from AngelID. I just assumed that question was for some noob that never worked on a Citrix box before. I am still working to see if I can get this working via Installation Manager but a manual install on the console does work.
Answered 08/08/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
It must be something profile related. If I install the application manually it works up until the point of where I log out and log back in.
Answered 08/08/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
It may be something with the profile as you stated, such as folder redirection from ex. Group Policy. By logging into the console you make sure that no folder is redirected during installation. When I install applications in TS for one of my customers I always do things manual just to be sure during test installation:
Login in to the console locally or remote desktop (mstsc /console)
change user /install
install
change user /execute
verify:
shadow registry: has been correct populated; no hardcoded entry to user specific settings such as the installers profile
any .ini files in the WindowsFolder has been redirected to users home directory
Answered 08/08/2006 by: AngelD
Red Belt

Please log in to comment
0
It looks like I have a workaround. I copied the p2ssyb10.dll to c:\windows\system32 and the application worked. I should have caught this but dependency walker only showed the call to the H:\ drive then I ran into how to temporarily fix the application and thought this was all profile based. It may still be profile based but filemon shows that the application also checks c:\windows, c:\windows\system and c:\windows\system32 for the dll. This might not be the best solution because the application still looks for the dll initially on H: (home drive) and with Citrix the home drive may not be local. I think this solution is good enough but I still may be forced to re-visit this to find a better solution because there are worries that the initial search for the dll on H:\ might cause some lag.
Answered 08/09/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
I have some follow up. It looks like we ran into another issue with our report exports not working. For fun we checked the legacy environment and it looks like one of the MSI packages for that environment is putting all the crystal reports dlls into system32. So it looks like someone saw the same issue I was experiencing on a Win2k environment. It is not a pretty solution but so far I can't find anyone that has identified the root cause of this mess.
Answered 08/22/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
Funny - I had very similar experience repackaging 3rd party vendor software that contained Crystal Reports dlls. I ran InstallShield snapshot (due to 16 bit legacy installer), and used msm's.
H: drive issue came up too.

I ended up fishing for dll's, ocx's, etc., and dumping those into SYSTEM32
Answered 08/22/2006 by: revizor
Third Degree Blue Belt

Please log in to comment
Answer this question or Comment on this question for clarity