PRQ only runs every other time

[seankeysight]

My company uses a tool called "Thycotic Agent" from a company called Delinea that bypasses UAC requests and processes them according to "policies" that are defined by our IT dept. Yes, it is a royal PIA, but I have no choice but to use it.

Thycotic has a bug that neither our IT dept nor Delinea support can fix to wit, if you are installing or uninstalling something that needs to use DPINST to manipulate kernel drivers, all too often Thycotic will put DPINST into an endless loop, spawning thousands of copies of DPINST. When this occurs, at best a reboot is required to return the machine to usability. At worst, the O/S is hosed requiring a reimage. 

One of our products must install kernel drivers, and it's a roll of the dice whether a given installation will succeed, fail or trash the system. As an R&D org, we can't have this behavior. I is also reasonable to assume that we have customers, somewhere, that also have this Thycotic Agent installed which would lead them to the same state that we are in. We can't have that.

We have a workaround that requires disabling the Thycotic Agent, adding the user temporarily to the Administrator's group, manually installing the product, removing the user from Administrators, and reenabling Thycotic. IT is not happy that they have to allow us to do that, but we simply cannot have dozens of engineers have to reimage their systems each day.

I have written a PowerShell script, fired by an InstallShield prerequisite that detects whether Thycotic Agent is installed and if so, displays a popup informing the user that they need to contact support for help with this process. When the user clicks OK, the install is terminated.

The PRQ "condition" is, "If the file [WindowsFolder]\temp\foo.txt (not the actual file name) is NOT present." The file will NEVER be present and so I expect this PRQ to appear each and every time the installer is launched. However, it only appears every ODD time the installer is run. That is, it fires the first time but not the second. Fires the third time but not the fourth.

The behavior is consistent on as many machines as I've tested it on so it's a real behavior.

Has anyone else seen anything at all like this? Any clues? Is there something in the registry somewhere (undocumented) that I can look for to change the behavior? I really need to have this behave as is documented.

My installer is built with InstallShield 2018 but I have tested it with InstallShield 2024 with no change in behavior.

- Sean

[seankeysight]

Further testing reveals that the issue is somehow related to the temporary folders that IS sets up in %TEMP%. Each invocation of an installer creates a guid-named directory in "%TEMP%. inside that folder something like C:\Users\seank\AppData\Local\Temp\{4835432E-B86D-452D-9F19-120E0C18BC39}\Disk1\ISSetupPrerequisites. Inside the ISSetupPrerequisites folder are yet more guid-named folders, each of which represents the PRQs that need to be installed.

If, when I'm looking at the Prerequisites window, I click "cancel", the setup ends and eventually, some seconds later, the main PRQ folder is deleted. If I follow this pattern, the next launch of the installer shows all of my PRQs, including the custom PRQ that I wrote to detect Thycotic. In the PowerShell script that handles that logic, I am using Stop-Process <pid> where <pid> is the process id of the installer, assuming that it attempts to gracefully terminate the install which, in theory, let it clean up those folders.

Apparently it is not being graceful about it at all, though, and those folders remain, and I think it's these remaining folders that somehow are affecting the next launch of my installer.

It would seem that I need to find a mechanism to send the IS PRQ engine a "cancel" from my PowerShell script. I dare to hope that there is such a mechanism, but  so far I've not found any documentation about how to do so.