Silent upgrade and SQL script Authentication

[kissack]

Hello,
this is my constellation: exe bootstrapper, fixed defined multiple instances and want to add automatic upgrades without any UI.
These are my EXE params: /upgrdinst {6741C389-4B66-4ED5-AF4E-7EC661F8EF8A} /exenoui /qn /quiet /norestart

When I run the upgrade with UI, I have no problem, but once I call the exe with /exenoui /qn /quiet /norestart the upgrade fails due to:

MSI (s) (2C:24) [13:17:12:737]: Product: Connect -- Error 4140. There was an error during the SQL script execution process.
Error 4140. There was an error during the SQL script execution process.
CustomAction AI_SqlConfig64 returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

To give more information
I have some SQL scripts in the setup which are to run under Trusted Connection with [LogonUser in full UI mode. With this script I create a SQL sysadmin login that I want to use later for additional scripts and also use this sysadmin login during the silent upgrade.

The problem I am having is that I cannot find a way that this script that creates the sysadmin user runs only when the product is installed for the first time and with full UI mode. Tried combinations of OLDPRODUCTS and UPGRADINGPRODUCTCODE and also UILevel>2.
Nothing seems to work and as soon as I run this upgrade in silent mode, get the 1603 error.

Any hint would be welcomed or different approach as well.

I must confess that I am still on 16.0 version of AI (I know, I know)

Thank you. Hopefully there will be some light shed onto this.

Kissack

[Catalin]

Hello Kissack,

You did not quite mention how you've conditioned the custom action, but here would be a correct one:

Code: Select all

(NOT OLDPRODUCTS) AND UILevel = "5"

NOT OLDPRODUCTS will be true for first time installations

UILevel = "5" will be true for full UI installations

If either of these two is false, considering the "AND" operator, the condition should be false and the custom action should not be executed.

Additionally, please make sure you do not have the custom action to be scheduled in the old package. You should have it setup to run only on "Install".

Hope this helps!

Best regards,
Catalin

[kissack]

Thank you Catalin. Your suggestion helped me to move forward.

[kissack]

hello, one follow up question if I may.

I would like to run the updater.exe from my software. The software is implemented as windows service running under network service account.

I have setup the update, so it install the updater windows service and am able to do update from non admin user prompt. Once I call updater.exe from within network service context, the initial request to the update server is done, but after that nothing happens.

Tried to investigate comparing behavior with process monitor, but there is so much noise, that this did not help me.

Any hint into the right direction would be appreciated. Thank you.

[Catalin]

Hello,

I am glad to hear I was able to assist.

Regarding your new issue, I'm afraid I don't really know why that is happening.

Perhaps you can try to enable the logging and see if the updater logs anything: Advanced Installer Updater

Hope this helps!

Best regards,
Catalin

[kissack]

Hello,

thank you Catalin. Setting the log works for normal user, but not for network service (no log is created, only aiu file.. Does this Process Monitor output give you any hints what might be the issue?

ProcessMonitor.png (235.83 KiB) Viewed 11314 times

Thank you.

[Catalin]

Hello,

The screenshot, I'm afraid, does not give us many details.

However, it is quite clear that this is a permission issue, as we can see "ACCESS DENIED" for most processes.

Best regards,
Catalin

[kissack]

Hello,

well I filtered it only for ACCESS DENIED. I thought maybe the path that is being accessed is something that you know about, that the updater tries to write something to windows temp folder. Does that ring a bell?

[Catalin]

Hello,

Here's how the updater works:

- when you launch it, the first thing would be to download the INI file. This is required for our updater to scan its settings to see things such as the URL to the new package, the expected size, etc.

- after that, the updater will download the resources (e.g. MSI and, if the case, the CAB files) and will launch the MSI for installation

From the previous screenshot you provided, I can see that updater.ini is denied - this would be the updates configuration file which the updater downloads.

Best regards,
Catalin