This is expected as the docker component is built separately from the rest of the agent. The actual fnms-docker-monitor version can be obtained by running `fnms-docker-monitor.exe -V` from a terminal. This version may or may not change between agent releases depending on whether any changes have been made to the docker component. ... View more

The auto upgrade process does not make any attempts to control feature selection when installing an agent upgrade. This will result in the default feature selection from the agent MSI being used (which is all features to be installed). I've submitted issue FNML-75073 to address this behavior. At this time I don't know when this might be addressed. You can use the msiexec command lines with the REMOVE property to uninstall the docker feature after an agent is installed as outlined in this thread. Alternately, if possible, it would be recommended that third party deployment software be used to work with deploying agents in your environment, as this would allow for the greatest control and flexibility in the deployment process, including working with upgrades. ... View more

The docs for VersionNT64 seem to be clear that the property is not set for x86 installers running on ARM64 machines: For compatibility reasons, the property is also undefined if the Template Summary property indicates the package is for 32-bit Intel systems and the operating system is a 64-bit architecture that is not Intel64 or x64 (such as ARM64). VersionNT64 Property - https://docs.microsoft.com/en-us/windows/desktop/msi/versionnt64 In addition, since InstallShield is mostly built as x86 architecture binaries, the ARM64 version of the OS is going to lie to any code InstallShield has that calls into the system to query for what architecture the system is. The end result is x86 processes on ARM64 Windows appear as if they are running on a 32-bit Intel machine (x86), including most of InstallShield's design, build, and runtime code, as indicated in this Build 2018 session: Windows 10 on ARM for developers - https://channel9.msdn.com/Events/Build/2018/BRK2438 InstallShield's 64-bit additions (for x64 architecture versions of Windows) were added at a time when ARM64 Windows did not exist, so this behavior is expected based on how the x86 emulation layer on ARM64 Windows is intended to function. I don't know what plans InstallShield has to support ARM64 going forward, especially if the platform fails to gain any appreciable traction. The question remains in this case though, in this scenario installing an x86 application on ARM64 versions of Windows, what is the use case for needing to know that the target machine is ARM64 and to access the native registry (i.e. the ARM64 registry) on the machine (when it won't really be usable by the application)? ... View more

InstallScript MSI projects create their own ARP uninstall key which is what is used as the source of the ARP entry (the MSI uninstall key is hidden from ARP). InstallScript MSI uninstall keys are under HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall and are always named 'InstallShield_{ProductCode}'. The uninstall string will always reference the cached setup.exe installed at \InstallShield Installation Information\{ProductCode} to allow the product to uninstall correctly. msiexec.exe can't be used to uninstall an InstallScript MSI project. If this is required a Basic MSI project should be used instead. ... View more

There were some issues caused by what methods we had used to lock down DLL loading in the original release of IS 2016 and the hotfixes for older versions of InstallShield in this KB. While the code used was not specific to a version of Windows, the issues reported to us almost exclusively occurred on Vista/2008 and 7/2008 R2. This came down to how DLL loading is handled on those versions of Windows and what we were using to avoid loading unexpected DLLs. IS 2016 SP1 changes how and what we use to mitigate CVE-2016-2542. This change is also not specific to any version of Windows but is implemented for all versions supported by InstallShield. Most of the hotfixes available here have been updated for more recent versions of InstallShield with the same fix for IS 2016 SP1 to avoid unexpected behavior. These were updated around mid/late-February. You should be able to download an updated version for IS 2013 SP1 that includes the 2016 SP1 changes. ... View more

This error essentially is indicating that the MSI package either has no digital signature, or the certificate used does not terminate in a trusted root. Are there any other digital signing errors in your build log, or any SigningHelper messages? If no such information is present in the log, does the MSI contained in the release Disk1 folder contain a digital signature (right-click the MSI in Windows Explorer, select Properties and look for the Digital Signature tab)? If it does, what state does Windows consider the signature based on the 'Digital Signature Information' field (double-click a listed signature to view it)? ... View more

These parameters are invalid when using DLG_INFO_ALTIMAGE_HIDPI. As the DialogSetInfo documentation states: szInfoString When DLG_INFO_ALTIMAGE_HIDPI is passed in nInfoType, this parameter specifies the file name of a high DPI image to display, optionally including the path. If no path to the file is specific, the file is assumed to be in SUPPORTDIR. If this file does not exist, DialogSetInfo returns ISERR_FILE_NOT_FOUND. nParameter When nInfoType is DLG_INFO_ALTIMAGE_HIDPI, nParameter specifies the DPI scaling percentage. For example, pass 200 for a 200% image scale, 150 for a 150% scale, etc. The minimum supported scaling value is 25. If 0 is passed for this value, no image is displayed. If DLG_INFO_ALTIMAGE_REVERT_IMAGE is passed, the previous image used is displayed. As such, the DialogSetInfo call needs to be something like the following when using DLG_INFO_ALTIMAGE_HIDPI: DialogSetInfo( DLG_INFO_ALTIMAGE_HIDPI, "My.png", 200 ); If my.png is not present in SUPPORTDIR, DialogSetInfo will return an error. ... View more

The expected values passed to the szInfoString and nParameter parameters of DialogSetInfo are treated differently when passing DLG_INFO_ALTIMAGE_HIDPI. szInfoString should be the image file (including the path; SUPPORTDIR is assumed otherwise) to be used, and nParameter should be set to the scaling factor of the image (100, 125, 150, etc.). If these parameters are not valid, DialogSetInfo will return an error. Images should be sized/scaled as expected for the normal dialog header area image (the old InstallShield header image is 180x75 pixels, the new image is considered 200% scale and is 360x150 pixels). Since DLG_INFO_ALTIMAGE_HIDPI was added in a service pack for IS 2015, I don't recall if the parameter information was updated in the DialogSetInfo doc. It is available in the IS 2016 docs here: http://helpnet.flexerasoftware.com/installshield23helplib/installshield23helplib.htm#Subsystems/LangRef/helplibrary/LangrefDialogSetInfo.htm ... View more

At this time we would recommend using IS 2015 SP1 without hotfix IOJ-1745445 installed. This would provide functional parity with the updated setup launchers posted earlier in this thread for IS 2016. ... View more