Updates remove customer data and don't retrieve paths of the original installation

[TOD]

Hello,

We are currently experiencing serious problems with our installations and especially updates, produced with Advanced Installer.

1) On RDS servers (Windows Server 2012 or Windows Server 2008 R2, for example) with fairly strict security policies, when we launch the installation from a Windows "administrator" session, choosing an installation "For everyone" And "customized" to indicate UNC paths to directories accessible to all users of our software, the installation does not work and blocks stating that it can not update the rights on the installation directories.
 => I guess this message comes from permission's settings that we've added on some directories.
But what is very strange is that if we choose "Only for me" instead of "For everyone", and we customize the paths to the same paths as before, it works perfectly.
 This is very curious, and suspicious in my opinion.
But we are doing the installations as well at the moment, at our customers' premises, but I fear that this will be a source of error for future updates.

2) When we apply an update, on RDS servers, the update does not find the paths of the initial installation and causes many very serious bugs:
a) The data directory of the previous installation is deleted, although the check box "Remove" is not checked for this directory in the AI ​​project.
This is very serious because this directory contains the database of our customers.

b) The files are installed at the root of AppDir in directories with names of the variables used in the Advanced Installer project.
This problem occurs similarly in our configuration files.
=> All this makes our software unusable!

Could you help us by explaining to us what we are not doing properly?
Thank you in advance.

I attached the 2 corresponding AI projects, , as well as the verbose log of a maj on an RDS server.

Best regards,

Thomas OD

[Catalin]

Hello Thomas,

Unfortunately, I can not say for sure why this issues occur.

In order for me to further investigate this, could you please forward me a download link for both versions of your application (built with the AIP files that you have sent) together with a test-case which I can follow in order to reproduce this issue, by e-mail at support at advancedinstaller dot com?

In addition to that, does this reproduces on Windows machines (e.g. Win 10, Win 8.1) or it reproduces only on Windows Server?

Looking forward to hearing from you.

Best regards,
Catalin

[TOD]

Please excuse me for the delay of my answer.
I have not received notification of the forum so I thought no one answered.

2) In the meantime we have progressed and, presumably, we no longer have the problem of erasing files.
However could you confirm that if I uncheck the box "Remove folder" and I chose for a file the option "Do not overwrite existing files", it will never be overwritten or deleted during an update?
How else should I proceed to get this behavior?

1) We still have this strange behavior between an installation "for everyone" and "for me alone".
Do you have an idea ?

I send you by email the last version produced of our packages and a test-case.
I will also re-check on Windows 8.1 / 10 because I have a doubt.

Have a nice day.
Best regards,

Thomas

[Catalin]

Hello Thomas,

First of all, thank you for the sent files.

Please accept my apologies for the delayed reply, but we do not work over the weekend here and it also took me quite some time to investigate this.

Now please allow me to answer your questions:

2 - If you want your files to not be overwritten during an upgrade, I can confirm that your approach is correct. However, a condition may be used there, e.g.:

OLDPRODUCTS

The above is a property that that is set only during an upgrade and it contains the product code(s) of the previous version(s).

1 - In what regards this, I have to admit that this is really strange, but in the end I was able to replicate the behavior. Now, the explanation may be a bit long, but please bear with me:

So basically, there are two ways in which you can set a folder permissions in Advanced Installer, and both ways are related to the "Keep existing permissions" option (right click your folder --> "Properties" --> "Permissions" tab).

1. if the above option is not selected, the default Windows Installer support is used. Basically, we do not alter the behavior at all.

This is also the case we are currently in. From what I saw in your project, you do not have that option checked.

At first, I thought that there may be some miss-configuration in your project, but then I was able to replicate this in a very simple project. This made me think that this is actually a Windows Installer limitation that does not allow generating new permissions for a folder that previously have no permissions on it, if the installation type is of per-machine. Unfortunately, I really can not tell you why this happens as this makes completely zero sense to me, too.

2. if the above option is selected, we alter the predefined Windows Installer support. Actually, it can not even be called "altered", as we pretty much do it all by ourselves here. As its name suggests, this option allows you to keep the already inherited permissions from the parent folder.

By checking this option, the error you get when installing for all users should be gone. However, from the tests I've performed so far, I could notice the following:

(I also noticed that you want to give the "Users" group Modify, Read&Execute, List Folder Contents, Read and Write permissions)

When the installation type is set to "Everybody (all users)", the above mentioned permission that you are trying to add is not added. I can confirm that this is an issue in what regards Advanced Installer which I have already reported and which hopefully will be fixed in a future version of Advanced Installer.

Until then, as a workaround, we can use a custom approach. For instance, a custom action that will add the permissions for us in case the installation type is of "Everybody (all users)" type. For this, I have created a PowerShell script which does that for you.

Here are few things to be kept in mind:

- first of all, this custom action can be added in your project as a "Run PowerShell inline script"

- this custom action should be scheduled between the "StartServices" and "RegisterUser" standard action (this is where our custom action, that applies the permissions, runs)

By default, the above mentioned standard actions are not displayed in the actions tree. To show them, please proceed as it follows: go to "Custom Actions" page --> under "Install Execution Stage" please right click on any action group --> "Show Standard Actions" --> "Add Resources" --> "Start Services". Now please repeat this step for the "RegisterUser" action as well.

In order to schedule the PowerShell custom action between those two, simply drag and drop it.

- the custom action's "Execution Time" should be set to "When the system is being modified (deferred)", as this is the stage where our predefined custom action would normally run.

I think that this is pretty much it about the custom action. The custom action could look like this:

Code: Select all

# An access control list (ACL) is a list of access control entries (ACE).

# This custom action should be scheduled between StartServices and RegisterUser standard actions (at this stage, our custom action takes place - AI_ConfigPermissions")


$acl = Get-Acl "C:\Users\Catalin\Desktop\MyFolder"
$users = [System.Security.Principal.NTAccount]"Builtin\Users"
$access = [System.Security.AccessControl.FileSystemRights]"FullControl"

# the ACE (access control entry) will be inherited by both container objects and leaf objects (aka both folders and files)
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit,ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]"None"
$type = [System.Security.AccessControl.AccessControlType]"Allow"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($users, $access,$inheritance, $propagation, $type)
$acl.AddAccessRule($rule)
$acl |Set-Acl

Also, for your reference, a screenshot with how the custom action should be configured:

Workaround - PowerShell script.png (190.37 KiB) Viewed 2424 times

Hope this will help.

Best regards,
Catalin

[Catalin]

Hello Thomas,

This has been fixed in Advanced Installer 17.8, released on December 21st, 2020.

Best regards,
Catalin