07/25/2007 7223 views
I repackage for a locked down environment, and I am debugging a package for Oracle Application Desktop Integrator 1.7x.

This app creates the key [HKEY_CLASSES_ROOT\oraLangGLDI.TraceCallback] and subkey [HKEY_CLASSES_ROOT\oraLangGLDI.TraceCallback\CLSID] on first launch, so I included this in my transform file. The problem is that even though I have done this, the app (after installing it from via my Wise .msi package) wants to DELETE that key and then re-create it.

I have tried everything I can think of, including having a custom action execute at the end of my package installation that opens up full perms on this key for non-admin users. So this is what ends up happening for a non admin user:

1. They run the program for the first time, and the app self heals as expected.
2. Oracle ADI - for whatever reason - does not accept the existence of this particular key in HKCR
3. Since the non admin user has full perms to this key, it gets deleted.
4. Oracle ADI wants to generate a new key, but since the user does not have full perms to the entire HKCR hive, the application fails to launch correctly.

Has anyone ever run across anything like this, and come up with a brilliant solution?

Craig --<>.
0 Comments   [ + ] Show comments


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

All Answers

In this case I would capture the first launch and see what else it adds as there could be some other resource it triggers the re-creation from.
It could also be that you are installing per-user (HKCR will be located under HKCU\Software\Classes) and the HKCR info is stored under HKLM\SOFTWARE\Classes. If the application verify if it exist under HKLM and finds it missing it removes it from HKCR (HKCU\Software\Classes) and then tries to add under HKLM instead and therefore fails.
Answered 07/25/2007 by: AngelD
Red Belt

Thanks, AngelD.

My base .mst file actually is a capture of first launch, and for this environment I repackage/deploy everything "per machine".

It's still an interesting point you bring up about HKLM\SOFTWARE\Classes. I have audited ADI's launch activities using FileMon and RegMon, but was only looking for "Access Denied" for lockdown purposes. I think I will perform another audit and look for "key not found" and see if that sheds light on anything. You would think though that a "key not found" for a non-admin user would be followed by a "cannot create key" and then an "Access Denied", but who knows.

I'm not optimistic at this point though. I have been repacking for quite a few years and never run into anything this problematic. It's possible I missed something in my initial capture and/or my first launch capture, but it doesn't seem likely.

I could just open rights to the entire HKCR, but that is not far from just making a user an admin.

I'll report back.

Craig --<>.
Answered 07/25/2007 by: craig16229
Third Degree Brown Belt

That's one key thaht we've never run into needing to have on the machines. Granted, my repackage of this POS app includes the keky from the get go and i don't have it in my permissions list as needing additional rights.

What's the error message that it generates?

This app has got to be one o hte worst in the world. Oracle really doesn't support it. They don't support it with any oracle client later than 8 (maybe 9), and they don't support *ANY* type of automated install. We've had nothing but problems with it.
Answered 07/25/2007 by: Chipster
Blue Belt

Chipster (and all),

Are you repackaging for a locked down environment?

Just to make sure I am describing everything clearly, my .msi package installs without issue. When a non-admin goes to run the repackaged version of ADI for the first time, self-heal runs as expected, and also without error. Then when ADI actually starts to execute, it throws a very non-descript error that simply says "error - quitting". It throws this message several times over the course of about 2 minutes, then the ADI interface actually does open.

Now, if an admin runs the app FIRST, subsequent non-admins can run ADI with no problem whatsoever. This is true whether I have installed it from the Oracle Universal Installer or whether I install it from my repackaged .msi. So, it's not like I have a totally worthless .msi, but of course it is not a totally seemless delivery to the end user with this odd issue remaining.

As far as later versions, I am STUCK with 1.73 because of a behind-the-times client. My first desire was to build .rsp file for a silent autoinstall, but of course I found out that ADI 1.73 does not have that functionality that some other Oracle products do.

Craig --<>.
Answered 07/25/2007 by: craig16229
Third Degree Brown Belt

I finally have it working, though it is certainly not the most streamlined package I have ever created.

As I stated before, my baseline .mst was created by performing a capture of first launch and of configuration settings.

Since it seemed that something was still missing, I created a second .mst by performing a capture of the SECOND launch of ADI. Sure enough, there were registry settings created upon second launch that were NOT created on first launch.

My next step was apply the two transforms sequentially, but the second transform was so riddled with errors that I abandoned the "second transform" idea. Instead, I simple created a second .msi from a capture of "second launch" registry settings, and deployed it as a "utility" .msi immediately after the install of my original .msi.

As I said, it's not exactly streamlined, but I found this a perferable solution to giving admin rights to users in an accounting department or to spending another week debugging the second failed transform.

I will copy this information over into the AppDeploy package KB at some point.

After studying Oracle ADI 1.7x via Wise Package Studio, FileMon, and RegMon over the past several days, it now wins my vote for "worst application to repackage ever".

Thanks all for reading. Always helpful when others get you to re-examine what you have all but discounted.

Craig --<>.
Answered 07/26/2007 by: craig16229
Third Degree Brown Belt