ISInstallPrerequisites custom action is showing clear text passwords in MSI Log.
Hi,
I'm using a dialog to enter in a username and password for services that will be installed. I've been trying to mask passwords in the MSI Log by using the "MsiHiddenProperties" property and changing the Type field in the custom actions table. This has worked fine so far, except for one spot during the installation process. When the "ISInstallPrerequisites" custom action runs in the UI sequence, it displays all the properties including the property that's supposed to be hidden (In this case: IS_NET_API_LOGON_PASSWORD). It's displayed during this entry while "ISInstallPrerequisites" is executing: "InstallShield 16:15:21: Saving properties: ". I disabled the custom action as a test to isolate the issue and the property with the password isn't displayed.
I can't leave the custom action disabled since prerequisites need to be ran when installed on a clean machine. Is this an Installshield bug that can be fixed? Is there a workaround besides disabling the "ISInstallPrerequisties" custom action?
When I ran into this with IS2013 using a suite project type, I was able to do the following: 1. Run my install and use a temporary password. 2. Create a C# custom action that alters the password. 3. Schedule the C# custom action to run after the prerequisites have installed.
I did this for installing SQL Server, and I do not know what you guys are setting up, however, this worked for me.
Can you try the same from a Basic MSI project. While doing from basic msi projects that require pre-requisites those properties are getting listed out in the log. That is the issue here.
I know I'm three years late to the party, but was there ever any resolution to this? I'm seeing the same behavior still and cannot find any other information about it. I've managed to mask the password everywhere else in the log, but nothing I do seems to change this behavior. Basic MSI, ISInstallPrerequisites, "Saving properties" line, same as the original issue.
I raised a case to ask this very question. The repsonse was that this was fixed in Installshield 2016. I haven't upgraded yet, so can't confirm, but was able to get around the issue by moving prereqs from being feature prereqs to product prereqs - appreciate this won't be possible for every situation, but was ok for our installer.
