InstallAware

I am supporting two separate installs for two products and one of them I have no issues. I use the group policy and it runs with psexec.exe fine and without error.

The other installer gives me a 1603 error and then seems to install fine. When I look at the log file it has a lot of errors with this:
MSI (s) (20:28) [16:42:13:676]: SECREPAIR: Failed to open the file:C:\Users\$(MyUserName)\AppData\Local\Temp\mia10\Win\System\vccorlib110.dll for computing its hash. Error:3

When I run the erroring installer without psexec.exe it works fine.

I am unsure what I am doing wrong. I would guess maybe the system user doesn't have access to my appdata but I don't know why things are getting placed there in the first place

Dear Sol952,

under System Account installations must be executed AS-PER MACHINE (ALLUSERS=TRUE).

Please have a look at the following links where the same argument has been already discussed.
http://www.installaware.com/forums/viewtopic.php?f=2&t=8783&p=32350&hilit=SCCM+system+account#p32350
http://www.installaware.com/forums/viewtopic.php?f=2&t=10656&p=41155&hilit=system+account#p41155
http://www.installaware.com/forums/viewtopic.php?f=2&t=6658&p=33108&hilit=systest#p33108

Regards

So about a month ago a customer contacted me wanting to deploy my software across their network, and I boasted how that would not be a problem and everything will work without any issues; after all we use IA. Then the customer tells me it doesn't work and that the installer is trying to access the desktop folder, which of course doesn't exist under the system account.

I attempted to reproduce problem so that I could diagnose the problem locally, as anyone who writes code for a living we all know things never go as planned and I was not the least bit surprised when the installation worked, because typically this is how things go. I tested with both real machines and virtual machines with a variety of Windows OS versions and flavors.

Troubleshooting this issue over two weeks now and I had hit a brick wall, I couldn't think of anything else to test.

I made a few tweaks to the installer script just in-case and had the customer try the update, same result.

Now awhile back I picked up a low-end Win10 tablet/laptop for the kids as a Christmas present (though now that they've seen it, I need to find replacement), I thought to myself maybe I should test it; why not, every other device I've tried worked maybe this will be the magic we need to solve this problem and allow some of us to get on with our lives.

So I set it up and went through the usual course of windows updates, etc. After everything was done I copied over my installer and tried to run it using PsExec, sure enough it failed with the same error everyone else has been reporting.

Okay great so there is a problem.. I read through some of the forum posts...

using ALLUSERS=TRUE alone does not solve the problem.

To make things easier to test I started using one of the sample projects "Default Project".

It failed with the same error.. So I cloned the project and tried to narrow it down even further.

First I tried by deleting all of the scripting from the project, that worked.
(Unrelated bug, with all regions collapsed if you do a select all in the script editor and then delete everything you are unable to type directly to add a new line of scripting; when you undo the script is restored but everything is now double-spaced.)

Removed everything but the "Show dialogs" and that failed, recalling a post about how someone using the Alpha theme didn't have the problem, so I started testing different dialog themes, After hours of trial and error I narrowed down the issue to the destination form; specifically forms where the PTShellTree component used.

Additional testing has revealed dropping the PTShellList component on a form will also result in the same error.

So now we've narrowed down the problem to the PlasmaTech Shell Pack controls used by IA, It should be somewhat trivial to patch the code used by these components to suppress any and all error messages when the installer is running in silent mode.

I am more than happy to test any changes to confirm that the issue is resolved.

Best Regards,
Charles DeWeese
OpenSight Software LLC

Dear Charles,

what you are reporting is not due a bug with the "ShellList component", but it's just because that control cannot work under a system account context. To solve your problem, you need to replace such control with a more simple "Browse for folder dialog". This is exactly what I done with all my projects and when these needs to run under a System Account Context.

https://www.installaware.com/forums/viewtopic.php?f=2&t=10656&p=41155&hilit=browse#p41155

Then, run the package in silent mode (under system account the installer has to run in silent mode Always ... you cannot browse for folders) as follow;

> psexec -i -s <setup.exe> /s
*With a setup exe is generally not necessary to pass ALLUSERS=TRUE. This should be TRUE by default already.

alternatively if you have a MSi file;

> psexec -i -s msiexec.exe /i <setup.msi> CMDLINE="ALLUSERS=TRUE" /quiet
*With a MSI file is necessary to specify ALLUSERS=TRUE.

Hope this helps you.

Regards

FrancescoT wrote:Dear Charles,

what you are reporting is not due a bug with the "ShellList component", but it's just because that control cannot work under a system account context. To solve your problem, you need to replace such control with a more simple "Browse for folder dialog". This is exactly what I done with all my projects and when these needs to run under a System Account Context.
img.png

I understand your point of view, however I do not entirely agree with you.

I have updated my installers to use the old style select folder logic, doing away with the ShellTree component.

But this situation is an absolute customer support nightmare.

Would you please consider adding this limitation/conflict/issue to the help file in multiple places such as "Setup Command Line Parameters" /s switch and "Dialog Controls"

Now I am very familiar with the PlasmaTech VCL Shell Controls and have used them for well over 10 years. Though I have never encountered this situation because my software would never run under the system account. I am investigating the details to determine exactly what bit of code is causing this error, because suppressing the error message would solve this problem entirely.

There are several ways to work around this situation without touching the Shell Controls and I hope that this is something you can consider, or at least think about addressing in a future update.

1. The ShellTree component has a option ptsoAutoFill which is by default set to true, if you set this to false you can avoid the error when the dialog is created, however now the content must be filled before the dialog is actually shown to the user; with a call to ShellTree.FillItems.. Using the User Interface Editor its possible to set this option to false, but I do not see anyway to change the value or call FillItems via the script engine or otherwise. So it would need to be done by IA, turning off autofill and then filling the items before displaying the form.

2. if SILENT is true then when creating the dialogs don't create any of the Shell components, create a dummy/fake placeholder component in its place if need be and by simply not creating the shell controls the problem can be avoided.

This is where the error is triggered and then the message box is created by the OS due to the failure, in the UPTSHellControls.pas file



A simple hack would be to edit this routine and always pass 0 as the parent handle, this will prevent this function from throwing any UI errors.



But we can do even better... much better.. My proposed fix, this requires a slight change to UPTSHellControls.pas

Take a look at this procedure, this is when the autofill is triggered, we don't want an error while the component is being loaded, worse possible time.


Now we replace it with the following modified code



This fix only addresses the problem in the ShellTree control, additional changes will be needed for the ShellList, and fixing it is a bit more work since it doesn't define the FIgnoreErrors variable and doesn't have any of the ignore logic that is found in the ShellTree.

Dear Charles,

many thanks for reporting this and I'll send a note to our dev team. However at this moment, I am not able to anticipate you if a similar fix can be implemented and eventually, when this could be available.

So for now, the only possible option is the approach that I described previously.

Regards

Dear Charles,

this should be fixed now.
https://www.installaware.com/forums/viewtopic.php?f=2&t=10831

Many thanks for the ideas your shared with this post, as one of them directly contributed to the implementation.

Regards

You're welcome.

This is absolutely great news! you just made my day, I am downloading the update now.

Happy Holidays