hi @Revenera_Ian ... i got it to work now. One more action was needed, the Custom Action name needs to be added to the MsiHiddenProperties.  ps: while doing it I noticed that if there are multiple customactions that needs to be added to the MsiHiddenProperties, in the installation log the masking of the sensitive information is happening for the first customaction alone. A little digging on the issue found that the customaction Type was not getting changed in the CustomAction Table. So I had to manually add 8192 on to the existing value for it to make it hidden (custom-action-hidden-target-option) Hope this helps      ... View more

Hi Ian, It did not work for me. The log output still shows me the sensitive data in plain text. Can you please share a sample ism with your settings defined. I am using InstallShield 2020 R2 version. ... View more

hi @Jenifer  Any update or workaround for this issue? Please let me know. Thankyou. ... View more

Hi @Jenifer, Any update on this bug?? Please let us know. Thanks in advance. ... View more

hi @Jenifer  I am using customactiondata property to pass the property values into the deferred CA. Inorder to hide sensitive information showing up in logs i added the property value to MsiHiddenProperty also updated the CA type to 8192 as mentioned in here my CA is successful in hiding the property, but from the installshields some custom logging that gets into the log file which is exposing the passed in value as show below MSI (s) (B0:64) [06:50:03:945]: Executing op: CustomActionSchedule(Action=testLogging,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********) MSI (s) (B0:60) [06:50:03:945]: Invoking remote custom action. DLL: C:\windows\Installer\MSI912C.tmp, Entrypoint: m5 MSI (s) (B0:5C) [06:50:03:945]: Generating random cookie. MSI (s) (B0:5C) [06:50:03:960]: Created Custom Action Server with PID 336 (0x150). MSI (s) (B0:B8) [06:50:03:976]: Running as a service. MSI (s) (B0:B8) [06:50:03:976]: Hello, I'm your 64bit Elevated Non-remapped custom action server. InstallShield: Attempting to load through CLR 4 APIs... InstallShield: Getting meta host... InstallShield: Enumerating available runtimes... InstallShield: Highest available runtime: v4.0.30319 InstallShield: Trying to use highest runtime... InstallShield: Using highest version runtime... InstallShield: Ignoring CustomActionData substring "1" InstallShield: Deferred action requested property MsiHiddenProperties not provided by CustomActionData InstallShield: Deferred property iiswebsitename="Default" InstallShield: Loading assembly ClrPsHelper from resource 4097 InstallShield: Calling method with parameters [(System.UInt32)1604, (System.String)C:\Users\installshieldadmin\AppData\Local\Temp\3a142f39-62c8-41d2-b7e1-e5beb3d14a31\logger.ps1] PowerShell wrapper: Ignoring CustomActionData substring "1" PowerShell wrapper: Deferred action requested property MsiHiddenProperties not provided by CustomActionData PowerShell wrapper: Deferred property iiswebsitename="Default" PowerShell wrapper: this is a test CA   attached logs from my sample test where the CA is testLogging     ... View more

Kim, Can you try to get the setup bootstrap log to see if anyhitng is getting logged from the setup.exe while launching ? To get the setup.exe boot strapper log try something like this: setup.exe /debuglog"c:\SetupDebug.log" ... View more

There is no extra code to set the MSI handle from the OnLaunchAppAndWaitCallback(). I had tried the same code in InstallShield 2012Spring and it was working properly. When this same code was used in InstallShield 2014 this started to behave differently. As you have rightly mentioned that the msi handle needs to be set in OnLaunchAppAndWaitCallback() otherwise the script engine will initialize it to 0. But why is that initialization NOT happening in 2012Spring? How is that working there? Please share some light on this scenario. I tried having a global variable and using that to set the handle value in the custom action entry point in IS 2014, it started to work. I had tried with setting a pseudo variable ISMSI_HANDLE that also seem to work. Thank you so much for that suggestion. PS: Previously I was using hRecord as OBJECT type and for making it to work in 2014 i changed it to HWND. ... View more

Hello Josh First of all thanks a lot for that reply.... I had tried the piece of code that you had provided. When i sequenced is as per your instructions and called this customaction, it was working fine. I even tried to call this as a immediate CA after installFinalize and it was working fine. But the issue that i am facing is a bit different , what i was trying to say was when this function is called from "OnLaunchAppAndWaitCallback()" that is not getting any interaction with the UI. I am using something like this: function TestMessage(hMSI,szProgram,szCmdline) begin LaunchAppAndWait(szProgram,szCmdline,LAAW_OPTION_WAIT | LAAW_OPTION_HIDDEN | LAAW_OPTION_USE_CALLBACK); end; and function NUMBER OnLaunchAppAndWaitCallback() HWND hMSI; STRING szMsg; NUMBER nReturn; OBJECT hRecord; begin DoProgress(hMSI); end; Can you please try this and see? I have provided the debug log : [CODE]00002888 5:21:14 PM [38440] MSI (s) (28!D8) [17:21:14:837]: Creating MSIHANDLE (404) of type 790531 for thread 38104 00002889 5:21:14 PM [38440] 00002890 5:21:14 PM [36888] MSI (a) (18:D8) [17:21:14:837]: Passing to service: MsiRecordSetInteger(404, 1, 0) 00002891 5:21:14 PM [36888] 00002892 5:21:14 PM [36888] MSI (a) (18:D8) [17:21:14:838]: Passing to service: MsiRecordSetInteger(404, 2, 100) 00002893 5:21:14 PM [36888] 00002894 5:21:14 PM [36888] MSI (a) (18:D8) [17:21:14:838]: Passing to service: MsiRecordSetInteger(404, 3, 0) 00002895 5:21:14 PM [36888] 00002896 5:21:14 PM [36888] MSI (a) (18:D8) [17:21:14:838]: Passing to service: MsiRecordSetInteger(404, 4, 0) 00002897 5:21:14 PM [36888] 00002898 5:21:14 PM [36888] MSI (a) (18:D8) [17:21:14:838]: Passing to service: MsiProcessMessage(0, 167772160, 404) 00002899 5:21:14 PM [36888] 00002900 5:21:14 PM [36888] MSI (a) (18:D8) [17:21:14:838]: Passing to service: MsiCloseHandle(404)[/CODE] It seem to me that the MsiProcessMessage handle is going to 0 when the call is being made from the OnLaunchAppAndWaitCallback(). May be you can provide me more light in this situation. ... View more

Hi DLee65, 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. Mano ... View more

I appreciate the information that you had provided me,but in my case I am resetting the ProgressBar. Then adding my custom ticks say 200 that would give me ample increment in the progressbar. This has been properly working in the previous versions. I don't think its the problem with the MSI. Can you verify this. joshstechnij wrote: We have been able to verify that reporting progress through MsiProcessMessage (either in an MSI DLL or InstallScript custom action) functions correctly. There have been no changes to InstallScript's MSI function wrappers that would have affected this. Windows Installer itself and its APIs will only change according to the Windows version an installation is running on. If you are using a Basic MSI project with InstallScript actions to control the progress bar, how many total ticks are you adding to the progress bar through MsiProcessMessage (assuming the code you are using is not resetting the progress bar)? This will have an impact of how much progress is seen on the progress bar through MsiProcessMessage calls. For example, with an MSI package that does not contain much information, say the total size of the MSI package itself is ~5MB. If a custom action adds 100000 ticks to the total progress of the installation (as is outlined in the Adding Custom Actions to the ProgressBar article on MSDN), then the custom action only accounts for about 2% of the overall movement of the progress bar. A progress increment of 10000 ticks will then only add about 0.2% forward progress to the progress bar. For the progress bar's typical size, this movement may or may not be visible. The larger the MSI package gets the less visible impact a specific custom action has on the progress bar will be seen. In this case, the custom action needs to specify a larger total tick value to remain visible to the progress of the installation. Otherwise, the custom action's percentage of the total progress report (as a function of the installation size) will decrease as the rest of the MSI package increases in size. Generally speaking, this would be expected behavior since the custom action may or may not have increased the amount of data it itself reporting. ... View more

Hi, I installed InstallShield 2014 SP1 and tried the same... the issue is still happening. MsiProcessMessage(hMSI , INSTALLMESSAGE_PROGRESS, hRecord); is NOT at all working ... View more

Hi, while making the minor upgrade for the patch are you proving the base msi in the new release's previous msi option? ... View more

Hello All, Seems like this is a bug from IS side and they had provided a fix for it. Please check this thread. https://community.flexerasoftware.com/showthread.php?206924-SQLLogin-garbage-instance-names Hope someone will add this into the Quick Links ... View more