Security

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.

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

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.

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

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