QV Desktop 12.70.12100.0 - silent install - broken feature "QlikView"

[mit]

Howdy,

when distributing QV Desktop 12.70.21000.0 silently, the install is broken.

The user will be faced with

The eventlog shows

Erkennung von Produkt "{C55D34F3-398B-497D-AE65-7080190ED2B3}", Feature "QlikView" und Komponente "{D5F226AE-3AF5-47D5-B570-25469464EB5B}" fehlgeschlagen. Die Ressource "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\C:\Program Files\QlikView\Qv.exe" ist nicht vorhanden.

followed by

Erkennung von Produkt "{C55D34F3-398B-497D-AE65-7080190ED2B3}" und Feature "QlikView" fehlgeschlagen beim Anfordern von Komponente "{6250D253-FB97-46C3-A190-E3D51AB0827A}".

Note how this is being run as a system-install and silently, and it goes for HKCU. Already sounds wrong to me.

Here's a diff MSI log from silent install (left) vs interactive (right).

Once the installer has been run interactively, everything is working fine. Which is what we used as a workaround for now.

The result is the same no matter which variant we use.

• SETUP arglist "/S","/v/qn"
• MSI arglist "/i `"${MSI}`"","/qn","/norestart","/log `"${log}`""
  • ALLUSERS=1 doesn't make a difference. That's good as it shouldn't 🙂

Both silent install as well as interactive are called via x64-PS.

The same method(s) have been used on 12.60.20200 and it worked flawlessly there.

The install procedure is always [uninstall all old versions] and only then we go install the new one.

Maybe your internal tests only did inplace-upgrades?

But I'm also happy with any other stuff you might lead me to 🙂

Issue was discovered on 21H2 2022-09 updates and is still present on 22H2 2022-10 updates.

Best regards

Oliver

[Chip_Matejowsky]

Moving thread from Qlik Sense > Deployment & Management forum to QlikView > Administration forum.

Best Regards

[Bill_Britt]

HI,

I have tested with QlikViewDesktop_x64Setup.exe /S /v/qn and I had no issues.

[mit]

*sigh*

Thanks for the detailed response!

...

I debugged it for you.

It occurs when you run the installer as SYSTEM.
Please go talk to your packaging folks.

Go fetch yourself PSExec and run a powershell as proper SYSTEM (NOT a casual admin account, SYSTEM!!)

This will be the result.

If, on the other hand, you run it as a casual admin...

It will work.

The RegKey is written properly during install into HKCU\... (screenshot below is view as SYSTEM HKCU)

We are deploying with Ivanti which actually runs

SYSTEM C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NonInteractive -ExecutionPolicy RemoteSigned -command "& { . 'C:\somepath\install.ps1'; exit $LASTEXITCODE }"

if you were to view it from taskmgr.

This is, like I said, the very same setting we used all the time before.

Something changed on your end.

For debugging, feel free to use the following to countercheck if you are testing in the correct user environment (run in parallel during install).

$what = "powershell.exe"
$procs = @(); $procs = get-ciminstance win32_process -filter "name = '${what}'"
foreach ($proc in $procs)
{ 
$procExec = $proc.ExecutablePath
$procCMD = $proc.CommandLine
$procOwner = Invoke-CimMethod -InputObject $proc -MethodName GetOwner | select -expandproperty user
write-host "Process owner | executable | command line"
write-host "${procOwner} ${procExec} ${procCMD}"
write-host ""
}

[Chip_Matejowsky]

Hi @mit,

Please open a case with Qlik Support so that they can engage with Qlik R&D to address the issue you found. 

Best Regards 

[huu]

This is done to fix the security issue-QV-22734 CWE-379: Creation of Temporary File in Directory with Insecure Permissions with QV.exe installer - Jira (qlikdev.com),   Please run cmd or powershell as Administrator or System , then run command to install the setup silently from there. 

You have to run setup from elevated command prompt. It should not matter whether its run by Admin or System. 

I have checked it and no issues were found.

We will investigate why it's not working for them even though they are running from elevated cmd and schedule the meeting if needed.

[mit · Accepted solution]

Since somehow the moderation team decides what is a accepted answer and what isn't, even though this is my thread... (rofl, really...)

Support is in ongoing communication with us.

The newer versions set a VBS that runs on logon to prepare the env for some DPI scaling settings, where the VBS will set a regkey on user logon.

Since when I'm packaging I don't randomly log out and back in, this was not triggered.

Also, since I'm packaging in a VM, it is not guaranteed to be triggered on logon (depends on if I use RDP or HyperV for example).

So it's not really an installer problem, yet at the same time it is not really an issue in the environment.

But in the constellation "Exe/MSI has finished properly, but VBS didn't yet run" the app will go into repair mode on launch.

And when running the install as as SYSTEM, the regkey would not be set for my user during setup, but in HKCU of SYSTEM - that's why it works when running as admin, but not as SYSTEM.

Currently, R&D is looking for a better alternative since for example in a hardened environment that wouldn't even allow user side executables (VBS BAT PS1 EXE) this wouldn't work AT ALL.
Context: Executable as in "ran from %userprofile%\..", of course users need to be able to run Exes in general.

So basically everything is "as is", just make sure to log off or reboot once the install is through.

Some future version will have better handling for this, may it be a launcher-type exe or a onLogon event that runs a prepareEnv.exe from %programfiles%....a launcher would have the benefit of not relying on logon events.

This doesn't need to be rushed though but can be configured according to QV's needs as well as their customers's needs, and properly tested as well. So don't expect an update here just within a few days 😎