InstallShield Knowledge Base

Summary A vulnerability has been reported in the Basic MSI and InstallScript MSI (64-bit) Setups if configured with the options below: The project has Folder and Registry Permissions configured using 'Locked-Down Permissions' option set to 'Custom InstallShield handling' The Self-register option is configured with 'InstallShield Self-Registration table (ISSelfReg)' Note: All supported versions (InstallShield 2023 R2, InstallShield 2022 R2 and InstallShield 2021 R2) are affected by this issue.  This article provides details about this potential vulnerability and the remediation steps available.  Description There is known issue with Windows installer repair that allows a standard user to run MSI repair operations (performed by deferred CA) in NT AUTHORITY\SYSTEM context without requiring administrator credentials. This exploitable nature of MSI repair can present a potential security risk if the file operations from the deferred custom actions are not properly protected from standard user access. If custom handling option is configured, InstallShield extracts an executable named ISBEW64.exe to the writable TEMP folder, which is used to perform additional tasks like setting file and registry permissions and self-registration of COM servers. This misconfiguration of extracting an executable file to a writable folder along with the MSI repair exploitable behavior could potentially lead to a local privilege escalation by replacing ISBEW64.EXE with a malicious one. Workaround The following workaround options are available to remediate this issue:  Set 'Locked-Down Permissions' option to 'Traditional Windows Installer handling' or, Choose 'Windows Installer Self-Registration table (SelfReg)' option Click the links above for more information about each option. Fix Version and Resolution A hotfix for InstallShield 2023 R2 is available for download here: InstallShield MSI Repair-Privilege Escalation using Custom Handling Hotfix Additional Information Thank you to Kravets Vasiliy for identifying this issue and disclosing it to Revenera.

Introduction In this instructional video, Ian Pinawin (Senior Technical Support Engineer, Revenera) demonstrates how to integrate InstallShield with Azure Key Vault. Video Credit: Ian Pinawin, Senior Technical Support Engineer - Revenera More Information Note that in the manual call to azuresigntool.exe to digitally sign an arbitrary file (C:\setup.exe) in the example given in the video and shown below: azuresigntool.exe sign -du "https://www.revenera.com" -fd sha256 –kvu https://myazurekeyvault1224.vault.azure.net -kvi <Client ID of the service principal or the user identity> -kvt <Tenant ID of the service principal or the user identity> -kvs <Secret (token) used to authenticate to Azure Key Vault> -kvc MyTestCertificate1224 -tr http://timestamp.digicert.com -td sha256 -v C:\setup.exe C:\setup.exe is replaced by %1, and this command is placed in a Windows batch file, where %1 is the first argument passed to the batch file. When InstallShield uses the Custom signing type, it calls the batch file and passes the file to sign as an argument. InstallShield repeats this process for each file to be signed by azuresigntool.exe.

Introduction This article discusses preliminary troubleshooting steps for digital signing issues with InstallShield versions prior to InstallShield 2023 R2. Troubleshooting Steps Determine the InstallShield Edition (Express, Professional - renamed to InstallShield Edition, Premier) based on the Help > About InstallShield screen. Determine the InstallShield project type: Basic MSI, InstallScript, InstallScript MSI. Determine which Cloud HSM is storing the digital certificate: AWS Cloud HSM, Azure Key Vault, DigiCert KeyLocker, or a different Cloud HSM. Determine whether you can manually digitally sign an arbitrary file with signtool.exe, azuresigntool.exe, if you're using Azure Key Vault, or smctl.exe, if you're using DigiCert KeyLocker, outside of and without using InstallShield, just as a test. If step# 4 succeeds, the project type is Basic MSI, and the InstallShield Edition is Premier Edition, under the Releases > Release > Events, configure the following Windows Batch file for the Precompression Build Event to digitally sign the MSI: In the Precompression Build Event field, specify the following: C:\InstallShield 2022 Projects\BasicMSIDigitalSigningTest\signMSI.bat​ In the signMSI.bat file, include the following: "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\signtool.exe" sign /fd SHA256 /debug /f "C:\Users\Test\Desktop\MySelfSignedCertXYZ.pfx" /du https://www.revenera.com /t http://timestamp.digicert.com /p "<PFXPassword>" "C:\InstallShield 2022 Projects\BasicMSIDigitalSigningTest\Product Configuration 1\Release 1\DiskImages\DISK1\BasicMSIDigitalSigningTest.msi"​ If the project type is Basic MSI and the InstallShield Edition is Premier Edition, under the Releases > Release > Events, configure the following Windows Batch file for the Postbuild Build Event to digitally sign the setup.exe: In the Postbuild Build Event field, specify the following: C:\InstallShield 2022 Projects\BasicMSIDigitalSigningTest\signSetupEXE.bat​ In the signSetupEXE.bat file, include the following: "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\signtool.exe" sign /fd SHA256 /debug /f "C:\Users\Test\Desktop\MySelfSignedCertXYZ.pfx" /du https://www.revenera.com /t http://timestamp.digicert.com /p "<PFXPassword>" "C:\InstallShield 2022 Projects\BasicMSIDigitalSigningTest\Product Configuration 1\Release 1\DiskImages\DISK1\setup.exe"​ Build an uncompressed release. Outcome If this issue is resolved, the uncompressed .msi file should have a Digital Signatures Tab and list the digital certificate information indicating that the MSI is digitally signed and the uncompressed setup.exe should have a Digital Signatures Tab and list the digital certificate information indicating that the setup.exe is digitally signed. More Information To download the sample project used to test the troubleshooting steps in this article, see the BasicMSIDigitalSigningTest.zip file attached to this article. Note: In the Windows batch files included with the sample project, make sure to change <PFXPassword> to your PFX password for your digital certificate. If this article did not resolve the digital signing issue(s), contact Support. For more information about digital signing with Extended Validation (EV) digital certificates, specific to InstallShield 2023 R2, please review the documentation here.

Introduction This article details the process of generating desktop shortcuts within an MSIX project using the Package Support Framework (PSF). By default, MSIX packages don't inherently support the installation of a desktop shortcut due to Microsoft's limitation on user-driven preferences. Therefore, actions such as creating a Desktop shortcut or pinning it to the Taskbar or Start Menu are beyond the user's direct control. However, if you still need to deploy an application shortcut on a user's Desktop through an MSIX package, there is a option available. In this article, we'll explore that option to accomplish this task. Instructions Configure the MSIX package to support "Application alias" package. To do that, follow the steps below: Create a MSIX project. Add your .exe file under the Files and Folder View > INSTALLDIR. Go to the Applications View and create a shortcut for the newly added .exe file. Select the Key Name field on righthand pane. Rename it to the same name as the shortcut name: Go to Declarations. Right-click then add "New Declaration set." "Declaration Set 1" will be added. Right-click on "Declaration Set 1." Add a "New Custom Declaration." On the righthand pane, select the Namespace field dropdown menu then select  "Xmlns:uap3= , and xmlns:desktop=" as shown below:                   12. Select the XML content field then enter the code below and rename the Executable name  and Executable alias name:     <uap3:Extension Category="windows.appExecutionAlias" Executable="[ExecutableName]" EntryPoint="Windows.FullTrustApplication"> <uap3:AppExecutionAlias> <desktop:ExecutionAlias Alias="[AliasName]" /> </uap3:AppExecutionAlias> </uap3:Extension>                      13. Go to the Application View and select the Declaration field and select the newly added Declaration above:                    14. Save then build the project and install the MSIX package that gets created.                    15. Make sure the shortcut is created in the Start Menu.                    16. Press Win+R then type the application name and check that your application launches successfully, which means the alias exe shortcut was created successfully:                    17. Go to the user's Desktop then right-click and select New --> Shortcut and enter your exe name and click Finish:                   18. A new shortcut with the name, provided in the dialog above, will be created on the user's Desktop.                   19. Right-click the Desktop shortcut then select Properties --> and select the shortcut tab.                   20. Change the target path field and start in field to the LocalAppData path as shown below:                                                   21. Copy your icon file to folder path under LocalAppData --> package --> Roaming where our application folder is created with the product name and random ID. For example: C:\Users\Administrator\AppData\Local\Packages\MSIXTestShortcut_d14rjvjqp047y\LocalCache\Roaming:                   22. Click the change icon button and change the icon from above copied to the LocalAppData Roaming folder path:                                                23. Click OK then Finish and close all dialogs. Now, we have a new Desktop shortcut with an icon created.                      24. Now, we have to automate this process using PowerShell in the Package Support Framework (PSF).                      25. Copy the icon file and the newly created shortcut in to our test data folder as shown below:                                                    26. Add the value copied from above to the project .ism file > INSTALLDIR:                                                                   27. Download the attached ZIP files then extract them and paste them into the same test data folder (the .json file, createshortcut.ps1 file, and the StartingScriptWrapper.ps1 file).                              28. Edit the .json file and change the executable name to your exe name and edit the id and change the shortcut to the "Key Name" field value.                              29. Save then close the jason file.                          30. Now, open our MSIX package's project .ism file then go to the Application View --> Select the shortcut created and select Fixup Type under "Package Support Framework."                          31. Click on the + icon then select Custom Fix Up:                         32. Set Architecture to x86 and the .json path to the test data folder where the .json file was copied to:                            33. Now edit the createshortcut.ps1 file then change the path and name of the file, per the shortcut and .ico file that was created. Save and close the powershell script file:                        34. Go to the Files and Folders View and add both StartingScriptWrapper.ps1 and createshortcut.ps1 in to our project's INSTALLDIR                   35. Select the Root Node (the Destination computer node) then add the JSON file config.json and save the project .ism file:                36. Save and Build the project.                37. Install the newly built MSIX package.                38. Observe a desktop shortcut is created when launching your application, which runs the PowerShell script to create the Desktop shortcut. NOTE: Make sure all machines have the remote execution policy enabled to run a PowerShell script without any issues. The workaround installs a conventional .lnk desktop shortcut rather than a contemporary application entry. The script is triggered only after the application is initiated, allowing the Desktop shortcut to be copied. The MSIX uninstallation process does not include the removal of Desktop shortcuts, necessitating a separate action to address this, which is currently not supported using script as well. Inadvertently deleting the Desktop shortcut won't be resolved by repairing the MSIX package, as it won't automatically restore the shortcut. Reinstallation after uninstallation of the MSIX package is necessary to recover the Desktop shortcut. More Information Click here for Microsoft PSF help link. Click here for Microsoft documentation on how to create a desktop shortcut.

Introduction Microsoft has officially announced deprecating of VBScript language from future versions of Windows. As per Microsoft, it will be an optional feature in future releases and will be preinstalled to allow uninterrupted usage for VBScript customers, while they get opportunity to migrate their scripts to other supported technologies. Microsoft Windows 11 Insider Preview Build released to Canary channel already has this change. Please refer the links in the References section for more information. Solution We recommend our customers who are currently using VBScript to start their migration process to another scripting option before Microsoft announces its complete removal in future releases. In InstallShield, VBScript has been widely used by customers to write automated build scripts and MSI custom actions. As an alternative to VBScript, we suggest using PowerShell or DLL based custom actions based on the customer use cases. Please explore blog posts and knowledge base articles available in InstallShield community for the PowerShell related topics. References InstallShield automation sample scripts using PowerShell: https://community.flexera.com/t5/InstallShield-Knowledge-Base/Use-PowerShell-to-Create-a-Project-and-Add-a-PowerShell-Custom/ta-p/184098 https://www.revenera.com/blog/software-installation/getting-started-with-installshield-automation-and-powershell/   Calling PowerShell custom actions: https://docs.revenera.com/installshield/helplibrary/CAPowerShell.htm Deprecated features list from Microsoft: Resources for deprecated features in the Windows client - What's new in Windows | Microsoft Learn Deprecated features in the Windows client - What's new in Windows | Microsoft Learn

Introduction This article discusses how to successfully activate the InstallShield Standalone Build (SAB) inside a Docker Container with a Cloud License Server (CLS) ID license. Instructions To enable the CLS ID within a Docker container, it's necessary to generate a registry and include the CLS ID by creating a registry key. Once Docker Images are created, log in with the docker run command. Please refer to the Knowledge Base (KB) article in the More Information Section of this article.  Once logged into Docker, run the following command: reg add "HKCU\SOFTWARE\InstallShield\29.0\Professional" /v LicenseServerCLS /t REG_SZ /d "https://flexerasoftware.compliance.flexnetoperations.com/instances/CLSID" Replace CLSID with your CLSID (For example: QXXIAE24EIPJ) and then press enter. Please refer below screenshot. Try to build the project using IsCmdBld.exe and verify that the build is successful.  If the build still fails, please create the following Windows Registry entry to create a Installshield.log: reg add "HKCU\SOFTWARE\InstallShield\29.0\Professional" /v DoVerboseLogging /t REG_DWORD /d 1 Please change the number (see above) 29.0 to match your InstallShield version installed in  Docker (For example, for InstallShield 2022, the version is 28.0 and, for InstallShield 2023, the version is 29.0) Build the project again and a log file will be created under the <InstallShield_Home>\System  folder where <InstallShield_Home> is where InstallShield is installed (For example: C:\Program Files (x86)\InstallShield\2023 SAB\System). A log file named "InstallShield.log" will be created under System folder. Check the failure log details and try the KB article suggestions below if the failure is for an SSH certificate. More Information Click here for more information about installing the InstallShield SAB inside a Docker Container. Click here for more information about running an automation script inside a Docker Container.

Introduction This article discusses how to successfully build in a Docker Container with a Cloud LIcense Server (CLS), especially in a Windows servercore:ltsc2019 image: The build fails due to an SSL certificate not being available or not having been updated inside the Docker Container. 9-28-2023[11:38:12 AM]: CLS - Failed to connect the CLS server - https://flexerasoftware.compliance.flexnetoperations.com/instances/[CLSID]/request: [[1,7e4,7,0[75000001,60,3001025c]] General data transfer failure. SSL peer certificate or SSH remote key was not OK     Instructions To address this problem, the solution involves exporting certificates from the local machine, saving them as an SST file, then importing them into the Docker Container. Export the certificate from your local machine using following PowerShell command in an opened instance of PowerShell ISE: Get-ChildItem -Path cert:\LocalMachine\Root | Export-Certificate -FilePath c:\Test\TrustedRootCertBackup.sst -Type SST​ Copy the backup .sst file to folder shared with the Docker Container. Log into the Docker Container with an active session. Launch the Docker Container in PowerShell Mode using the following command: docker run -it  -v "C:\ISDockerBuild:C:\Test" installshield-sab2023r1 powershell Once the Docker Container is started, run the following command and make sure the .sst file is available in the shared folder. Import the certificate using the following command: Import-Certificate -FilePath C:\test\TrustedRootCertBackup.sst -CertStoreLocation Cert:\LocalMachine\Root  Try to build the project with the build command (ISCmdBld.exe). The build will succeed. More Information Click here for more information about using Dockerfiles on Windows.

Summary A critical vulnerability (CVE-2023-45853) is reported in 1.3 version of zlib component (https://github.com/madler/zlib) This article discusses the impact, if any, on InstallShield. Description MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long filename, comment, or extra field. Upon analysis, InstallShield Basic MSI, InstallScript, InstallScript MSI and Suite project setups are not affected by this vulnerability as these projects do not use MiniZip component. InstallShield MSIX/APPX project flow uses MiniZip, but there are no scenarios that involves the use of comment, extra field and long filenames. Hence InstallShield setups are not impacted by this vulnerability. Resolution As a Defense-in-Depth (DiD) measure, the zlib repository change, which fixes the vulnerability for zlib upstream, has been manually merged into the InstallShield 2023 R2 release.  As the utilized version is based on zlib version 1.3.0.1, security software may still highlight InstallShield Setups as potentially vulnerable; however, this constitutes a false positive and can be safely ignored. We are actively working on migrating zlib to version 1.3.1 to reduce false positive warnings in the future. This page will be updated shortly with hotfix availability details. References NVD - CVE-2023-45853 (nist.gov)        

Introduction This article discusses how an InstallShield user can run a suite installer silently. Instructions Create a suite project. Add then configure Feature1, Feature2, and so forth. Add packages: Package1, Package2, and so forth. Associate each package with a feature. In the Packages View, for each package, configure a Detection Condition (at a minimum) as well as an Eligibility Condition, if appropriate. When the Detection Condition evaluates to true, the package is detected as already being installed, so the suite installer goes into maintenance mode. When the Eligibility Condition evaluates to try, the package is determined to be qualified to be installed on the target machine. Run the suite installer silently with the following command: Setup.exe /silent ISFeatureInstall=Feature1,Feature2 /debuglog"C:\MyLogsFolder\suitedebuglog.txt" /log"C:\MyLogsFolder"   Note: The directory for the /log argument needs to exist prior to running the command. The /log argument will only result in logs being created for each package if logging is enabled in the package-specific settings of each package in the Packages View. Working Suite and Basic MSI sample projects, built with InstallShield 2023 R2, that demonstrate this functionality that was discussed are attached to this article. More Information Advanced UI and Suite/Advanced UI Setup.exe Command-Line Parameters

Introduction This article explains the process of deleting or disabling a scheduled task before installing with a new installer using a Custom Action in an InstallScript project. Instructions When installing with a new installer, if an existing scheduled task is running, the installer will fail to created a new task. In order to create a scheduled task without any issues, first, we should disable or delete the existing scheduled task running on the target machine. Please follow the steps below to delete or disable an existing scheduled task. Create an Installscript project. Add files under the Files and Folders View. Go to the InstallScript View under Behavior and Logic. Select the setup.rul. Select the righthand pane. Add the following InstallScript code:       function OnBegin() STRING szMyPath, szCmdPath, szMyCmd, svProgramData, szMyPath2, szCmdPath2, szMyCmd2; NUMBER nvBufferSize; begin szMyPath2 = "\"" + "for /f %x in ('schtasks /query ^| findstr test') do schtasks /Delete /TN %x /F" + "\""; szCmdPath2 = WINSYSDIR ^ "cmd.exe"; szMyCmd2 = "/c " + szMyPath2; MessageBox("szMyPath2=" + szMyPath2, INFORMATION); MessageBox("szCmdPath2=" + szCmdPath2, INFORMATION); MessageBox("szMyCmd2=" + szMyCmd2, INFORMATION); LAAW_SHELLEXECUTEVERB="runas"; LaunchApplication(szCmdPath2, szMyCmd2, "", SW_HIDE, INFINITE, LAAW_OPTION_USE_SHELLEXECUTE | LAAW_OPTION_WAIT); end;   A working sample project that demonstrates this functionality is attached to this article. More Information Click here to access the InstallScript Language Reference.

Summary A vulnerability has been reported in the Suite Setups built with prior versions of InstallShield 2023 R2. This vulnerability may allow Denial of Service (DoS) escalation when a low privilege user moves secured temporary folder and creates a Symlink Junction during suite setup installation. Description There are two secured temp directories created during the suite installation. In general, a user with standard rights cannot create/modify the contents of this secured directory. However, it was found that a certain move operation violates this condition using the standard credentials. This may allow a low privilege user to move this temp directory to another location during suite setup installation and create a Symbolic Junction (pointing to windows system files) with the same folder name. After the installation, the suite setup process deletes the temp folders along with the Directory Junction and its target contents (including Windows system files). This may affect the Windows operating system initialization once the system is rebooted and may result in Denial of Service (DOS). Fix Version and Resolution This issue has been fixed in InstallShield 2023 R2 release. You can download the release from your Product and License Center (PLC) or from 'Update Product' option within InstallShield IDE. Note: You must have a community login with PLC access or the old product installed to download the InstallShield 2023 R2 release. Additional Information https://www.cve.org/cverecord?id=CVE-2023-29081 

Introduction Below are the different ways of configuring EV USB eToken based code signing in InstallShield. Note that you will need a SafeNet USB Token connected to a machine where InstallShield software is present. You are also required to install the associated eToken management software from a certificate vendor (example SafeNet Authentication Client). Instructions Choosing 'Use a certificate store' option. Choose EV certificate entry from Personal -> User Certificate store. Please note that private key of EV certificate is stored on a separate certified hardware modules like USB tokens or HSMs and it is protected using token password. You will be prompted for a token password during signing process when the certificate is accessed from the USB token. There is also an option called 'Enable single logon' setting that comes with EV client software tool (eg. SafeNet Authentication Client) which helps to limit user interventions per session with only one token password request.  Using Custom Signing Type option. Use this option to select and configure a custom signing solution to digitally sign build-generated files. This helps to automate the scenarios where the Standard signing option is not suitable. This setting is helpful to override the InstallShield default signing flow with the custom signing solution. Choosing this option enables the additional fields where custom signing utility path and arguments can be configured. For example, you would be able to configure Microsoft Sign Tool from Windows SDK folder to take care of signing task. Using Custom Signing option to execute batch file.   Configuring batch file settings in InstallShield Signing Tab: Sample Signing.bat file contents. Use %1 variable as a place holder for the full file path to be signed. Using Custom Signing option to execute VB script. Configuring VB script in InstallShield Signing Tab:   Refer below sample VB script to retrieve the full file path to be signed. Selecting exported public key certificate file (.cer file exported). This option also provides possibility to encrypt and store EV token password in the project file. Open Authentication Client tool associated with USB eToken provider (eg. SafeNet Authentication Client) Find User certificate and click on Export file option as shown below picture. Save it as ev.cer file Go to Release => Signing Tab view in InstallShield and choose the previously exported .cer file as shown below   Configured the below required fields based on the private key properties of a user certificate in EV vendor software. Private Key Properties: Save and Build the project.  InstallShield encrypts and stores an EV token password in the project file. You will get a password prompt from EV vendor if Token Password is not configured.  

Introduction When distributing both 32 and 64-bit files in a single installer, specific files based on the OS should be installed on the machine. When you run the installer on a 32-bit machine, 32-bit files should get installed. When you run the same installer on a 64-bit machine,  64-bit files should be installed. Instructions Open InstallShield and create a Basic MSI Project. Go to the Setup Design view and add a feature and add two components. Name one component 32-bit component and the other 64-bit component. Add a 32-bit file to the 32-bit component and add a 64-bit file to the 64-bit component. Now set a condition for each component.   Select the 32-bit component and apply the condition NOT VersionNT64. Select the 64-bit component and add condition the condition VersionNT64. Now save and build the project. Now run the installer in a 32-bit machine. The 32-bit component files will be installed. Then run the same installer on a 64-bit machine. The 64-bit component files will be installed. Reference See Configuring Component Conditions in the InstallShield User Guide.

Introduction This article will discuss how to create a  shortcut based on user input using a property value and Create a shortcut using installscript and delete the shortcut on uninstall Instructions      This article explains how to  create a shortcut based on user request. This information applies to the following InstallShield project types: Basic MSI Installscript MSI Steps to create a Project: Create Basic MSI Project Add a Feature and add component and files inside component Add exe files to component for which we want to create a shortcut. Go to installscript view and Right and add Setup.rul Copy paste the code at the bottom of this article into setup.rul (Replace shortcut name as per your exe added in components Example: Notepad.exe) Make sure CreateShortCut and DeleteShortCut functions are added Go to CustomAction view and add 2 Installscript Custom Actions and rename it.(CreateShortcut,DeleteShortcut) For Create Shortcut CA select the function CreateShortcut  and for Delete Shortcut CA select the function name as DeleteShortcut from drop down Set the Condition for both Customaction (for EX: Create shortcut add condition NOT installed, and for Delete Shortcut add REMOVE~="ALL") And select Install Exec sequence as required. Go to Dialogs and Add a new Interior Dialog dialog  Go to property manager and add 2 property DESKTOP_SHORTCUT and START_MENU_SHORTCUT Make sure the value column is empty, so that the checkbox is unchecked by default Rename the new dialog (Example: ShortcutDialog) And add 2 checkbox like shown below And set above created 2 property to this 2 checkbox filed Now Sequence the new dialog (ShortcutDialog) BACK and NEXT button as needed under behavior.  EX: BACK --> Customer information , NEXT button to Setup Type Similarly in Customer information Dialog the NEXT Button should be change to ShortcutDialog Save and build the project Install the setup.exe and click NEXT and go to Shortcut checkbox dialog Click NEXT and Complete Installation Check shortcut created under desktop and under Appdata folder (EX: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\CompanyName)         #include "ifx.h" export prototype CreateShortCut(HWND); export prototype DeleteShortCut(HWND); function CreateShortCut(hMSI) STRING szShortcutFolder, szName, szCommandLine, szWorkingDir ; STRING szIconPath, szShortCutKey,szValue,szValue1; STRING szProgram, szParam, szFolderDir,szCmd; NUMBER nIcon, nFlag, nResult, nvBufferSize; begin //Get Supportdir for icon szIconPath = WINDIR ^ "regedit.exe"; //szIconPath = sMySUPPORTDIR +"\\" + "icon32.ico"; szShortcutFolder = FOLDER_DESKTOP; szName = "DesktopShortcut"; szCommandLine = INSTALLDIR ^ "Notepad2.exe"; LongPathToQuote (szCommandLine, TRUE); szWorkingDir = ""; nIcon = 1; szShortCutKey = ""; nFlag = CS_OPTION_FLAG_REPLACE_EXISTING|CS_OPTION_FLAG_RUN_MINIMIZED; MsiGetProperty(hMSI,"DESKTOP_SHORTCUT",szValue,nIcon); if ( szValue == "1") then Delay (2); // Create the folder shortcut, and show the folder it points to. if ( CreateShortcut(szShortcutFolder, szName, szCommandLine,szWorkingDir, szIconPath, nIcon, szShortCutKey,nFlag) < 0) then Delay (1); MessageBox ("DESKTOP Shortcut Not Created.", SEVERE); endif; endif; //Creating StartMenu Shortcut szIconPath = INSTALLDIR ^ "Explorer.exe"; szShortcutFolder = FOLDER_STARTMENU ^ "Programs\\CompanyName"; szName = "StartmenuShortcut"; szCommandLine = INSTALLDIR ^ "Uno.exe"; LongPathToQuote (szCommandLine, TRUE); szWorkingDir = ""; nIcon = 1; szShortCutKey = ""; nFlag = CS_OPTION_FLAG_REPLACE_EXISTING|CS_OPTION_FLAG_RUN_MINIMIZED; MsiGetProperty(hMSI,"START_MENU_SHORTCUT",szValue1,nIcon); if ( szValue1 == "1") then Delay (2); // Create the folder shortcut, and show the folder it points to. if ( CreateShortcut(szShortcutFolder, szName, szCommandLine,szWorkingDir, szIconPath, nIcon, szShortCutKey,nFlag) < 0) then Delay (1); MessageBox ("STARTMENU Shortcut Not Created.", SEVERE); endif; endif; end; //Script to delete shortcut on uninstallation. function DeleteShortCut(hMSI) #define shortcutName "DesktopShortcut" #define shortcutName1 "StartmenuShortcut" STRING szCompany,szStartMenuPath,startMenuShortcut,szDesktop,szDesktopShortcut; STRING nvSMProp,nvDesktopProp; NUMBER nBuffer; begin nBuffer = MAX_PATH + 1; szDesktop = FOLDER_DESKTOP; szDesktopShortcut = INSTALLDIR ^ "Notepad2.exe"; if (Is(FILE_EXISTS, szDesktopShortcut) = FALSE) then Delay (1); DeleteShortcut(szDesktop, shortcutName); else MessageBox("No shortcut to delete", INFORMATION); endif; szCompany = FOLDER_COMMON_APPDATA + "Microsoft\\Windows\\Start Menu\\Programs\\CompanyName\\"; if (Is(FILE_EXISTS, szDesktopShortcut) = FALSE) then Delay (1); DeleteShortcut(szCompany, shortcutName1); else MessageBox("No shortcut to delete", INFORMATION); endif; end;       More Information Click here for installscript help documentation on create shortcut Click here for installscript help documentation on delete shortcut

Intoduction     This article will discuss how to create a  shortcut based on user input using a property value create a shortcut instead of creating by default. Instructions       This article explains how to  create a shortcut based on user request. This information applies to the following InstallShield project types: Basic MSI   Create Basic MSI Project Add a Feature and a Component which contains a shortcut Select the newly added component and add a Condition CUSTOMCHECKBOX=1  If you have multiple shortcuts, create a new component and add condition like shown  above. Go to property Manager and create a property CUSTOMCHECKBOX and CUSTOMCHECKBOX1. Dont add a value yet. If we add value(1) the checkbox will be checked by default at runtime Now go to Dialog view and create a dialog and name it (Example: Checkbox) Add a  checkbox control  as per your shortcut added and add CUSTOMCHECKBOX and CUSTOMCHECKBOX1 in property field for each checkbox  Since we created a new dialog, we need to sequence it properly in order to see the dialog at runtime Select the newly created dialog[checkbox] and select behaviour node and select Back button and change the value to "Customer Information" Select NEXT button and change the Event DialogName to SetupType Select License Agreement dialog and change the NEXT button to "Customer Information" Select SetupType Dialog --> BACK Button change the dialog to Checkbox Save the ism and build the project  Run the installer, At runtime on checkbox dialog select the checkbox Based on select checkbox, specific shortcut will be created on desktop   More Information  Click here for installshield help document for create shortcut.  

Introduction This article will discuss one possible method of Launching a batch file using a custom action. Instructions To Launch a batch file using Custom Action we should follow below steps   Method:1 Launching from INSTALLDIR   Create a Project and Add your batch file in Files and Folder[INSTALLDIR] Create a New EXE Custom Action [ Type: New EXE , Path referencing a directory] Set the Working Directory: SystemFolder File Name and Command Line: cmd.exe /c  "[INSTALLDIR]test.bat" Return Processing: Synchronous (Check Exit code) In-Script Execution: Immediate Execution Set the Install Exec Sequence "After InstallFinalize" Add a condition if  you want to run this action only on installation EX: Not Installed Method:2 Launching from SUPPORTDIR Create a Project and Add your batch file to Behavior And Logic Supportfiles --> Language Independent  Create a New EXE Custom Action [ Type: New EXE , Path referencing a directory] Set the Working Directory: SystemFolder File Name and Command Line: "[SystemFolder]cmd.exe" /c "[SUPPORTDIR]\test.bat" Return Processing: Synchronous (Check Exit code) In-Script Execution: Deferred Execution in System Context Set the Install Exec Sequence "After InstallFinalize" or "After InstallFiles" Add a condition if  you want to run this action only on installation EX: Not Installed   More Information Click here  for details on how to launch batch file using installscript . Additional Information: "[SystemFolder]cmd.exe /c  "[INSTALLDIR]test.bat" This command calls cmd.exe (the executable for the Windows command prompt) from the location stored in the SystemFolder MSI property and passes cmd.exe the path to the batch file. Cmd.exe accepts various parameters. For example, to have the command prompt window close after launching the batch file, use the /c parameter, as in the example above. To have the command prompt window remain open after launching the batch file, use the /k parameter instead. For more information regarding the parameters accepted by cmd.exe, click here cmd exe  

Summary This article describes the steps to generate a verbose log file of the InstallShield Installation Developer Environment (IDE) itself or the InstallShield SAB itself. Synopsis This article describes the steps to generate a verbose log file of the InstallShield Installation Developer Environment (IDE) itself or the InstallShield SAB itself. This log can be useful to assist in troubleshooting InstallShield IDE initialization problems, etc. Discussion To generate the log file, perform the following: For InstallShield 2009 and earlier: Open a Command Prompt Window. Change to the InstallShield installation directory System subdirectory. For InstallShield 2009, the default path is: C:\Program Files\InstallShield\2009\System Enter the following command: isdev.exe -verbose The log will be located in the InstallShield installation directory System subdirectory ( i.e., C:\Program Files (x86)\InstallShield\2014\System). The name of the log file depends on the version of InstallShield: For InstallShield 12 and older, the log file name is: iside.verbose For InstallShield 2008 and newer, the log file name is: InstallShield.log   For InstallShield 2010 and later:   A registry entry is used to control logging. The registry entry is: [HKEY_CURRENT_USER\Software\InstallShield\<InstallShield Version>\Professional] "DoVerboseLogging"=dword:00000001 Where the InstallShield Version is: 16.0 for InstallShield 2010 17.0 for InstallShield 2011 18.0 for InstallShield 2012 19.0 for InstallShield 2012 Spring 20.0 for InstallShield 2013 21.0 for InstallShield 2014 22.0 for InstallShield 2015 23.0 for InstallShield 2016 24.0 for InstallShield 2018 25.0 for InstallShield 2019 26.0 for InstallShield 2020 27.0 for InstallShield 2021 28.0 for InstallShield 2022 29.0 for InstallShield 2023     For your convenience, we have attached .reg files that will update the Windows Registry to enable and disable logging. To use these .reg files, perform the following steps: Make a backup of the Windows Registry. Download the attached isdev_logging.zip file, and uncompress the *Logging.reg files to a folder on the same machine the InstallShield product is installed on. Based on the version of InstallShield, execute the appropriate Enable Logging.reg file to enable verbose logging of the InstallShield IDE startup, etc. (By default, this type of logging is disabled.) For example, to enable logging for InstallShield 2013, from Windows Explorer, double click on the file labeled Enable_IS2013_Logging.reg. When the InstallShield IDE is executed, a log file named InstallShield.log will be generated in the InstallShield product System folder ( For example, the file path for the log generated for InstallShield 2013 will be, "C:\Program Files\InstallShield\2013\System\InstallShield.log"). To disable verbose logging of the InstallShield IDE, based on the version of InstallShield, execute the appropriate Disable Logging.reg file. (For example, to disable logging for InstallShield 2013, execute the file labeled Disable_IS2013_Logging.reg) Related KB Articles Q104807 Q105237 Q110697 Q106849 Additional Information If only the splash screen appears while opening the InstallShield IDE, try manually registering the file "scrrun.dll" in the Windows\System folder. Specific steps on registering a file manually can be found in article titled 'How Do I Manually Register a File?' at the InstallShield Consumer Central site. For information on creating other types of log files, please reference the articles in the Related KB Articles section.

Debugging an Installscript Installation on Any Computer Summary In order to find bugs that are occurring only with certain hardware or software configurations, you may need to debug your installation on a system other than your development machine. In that case, it is not necessary to install InstallShield on that computer. Resolution 1 - On testing machine, install C++ 2012 redistributable x86 2 - Create folder on desktop to have a place to store files 3 - Copy ISDbg.exe and SciLexer.dll (ISdbg.chm is optional)from the InstallShield\System folder to the new folder on the test machine (Be sure to use the same version of the files that the project used, ie a 2021 project will use the files from the 2021 version of InstallShield) 4 - Using an administrative command prompt, register ISDbg.exe using the command below: ISDbg.exe /REGSERVER 5 - Copy the entire project folder from the development machine to the new folder on the test machine 6 - On the command prompt, change directories to the setup.exe and run the command below: setup.exe /d"<Path to Setup.dbg>" (setup.dbg will be found in the "scripts" subfolder of your project) 7 - Walk through your installer until the debugger is triggered. For Basic MSI: Debugging Basic MSI project with InstallScript CustomAction setup.exe /v"ISSCRIPTDEBUG=1 ISSCRIPTDEBUGPATH=\"C:\Debugger\My Project Name-14\Script Files\"" NOTE: From Installshield 2023 onwards to run the IS2023 debugger ISdbg.exe in different machine, we need to install VC2022redist.exe (Please install attached VC2022redist package then try debugging) Reference: Debugging Installscript help  Setup.exe commandline Parameters 

Summary Microsoft Defender Antivirus alerts triggered by false positive finding in ReleasePackager.exe utility. Users should update their Microsoft Defender Antivirus definitions to remove these alerts. Symptoms Microsoft Defender Antivirus is flagging InstallShield ReleasePackager.exe as containing malware [Trojan:Win32/NetSupportRat.CCC!MTB]. This is being reported against InstallShield versions 2022, 2021, and 2020. Microsoft confirmed the triggered alerts are a false positive finding and are updating their database to no longer flag ReleasePackager.exe. Please note while the ReleasePackager.exe file is quarantined in the interim, usage of InstallShield IDE should not be affected. The ReleasePackager.exe is a standalone utility and usage is typically limited; however, if you encounter issues with using the utility, reach out to Revenera Technical Support for assistance. The InstallShield team is working with Microsoft Defender to gather more details and minimize false positive triggers in the future. Fix Version and Resolution We advise updating your Microsoft Defender Antivirus definitions to the latest.

Summary When launching an InstallShield, AdminStudio or the FlexNet Connect Software Manager you may be prompted with Error 13030 / Error 13034. Symptoms When launching an InstallShield or the FlexNet Connect Software Manager you may be prompted with one of the following errors: Error 13030: Result Unsigned The server response could not be verified because it was not digitally signed Error 13034: Result Untrusted (Certificate Expired)The server digitally signed its response with a certificate which is no longer valid. The server response was signed by a certificate which is no longer valid. Would you like to temporarily trust it anyway? (Not recommended) Cause The error is caused by an expired FlexNet Connect Software Manager Certificate Resolution In order to resolve this issue we will need to remove the expired certificate. Once the certificate is removed a new and updated certificate will be downloaded. Open File Explorer and navigate to C:\Users\<USERNAME>\AppData\Roaming\FLEXnet\Connect\Database Delete the file named 'CERXXXX.tmp' (The X's will be a series of random characters) After removing the the .tmp file you should no longer be prompted with the above error messages after restarting the product. Additional Information If you are still having trouble with this after removing the .tmp file, please contact Flexera Technical Support.