Hi Daryl,

very useful feedback.

We are also testing best way to run CloudAppLauncher_Installer.exe in a pretty locked CITRIX env.

Whitelisting the Launcher EXE seems unavoidable (in addition to the actual application EXE). We actually needs to deploy the Launcher with Default_Both_WithServiceMulti profile since first installation on CITRIX server must be up to administrator. In this case, the Launcher extracts 2 EXEs to temp folder with different numbers, for example 

%USER%\APPDATA\LOCAL\TEMP\43\{8984CEF2-3E65-4EAC-BE4F-A3C05BBF6285}\LAUNCHERSETUP_WITHOUTSERVICE.EXE

%USER%\APPDATA\LOCAL\TEMP\43\{97BA3DEE-A23F-49CC-B2A5-F538F0D0324B}\LAUNCHERSETUP_WITHSERVICE.EXE

which we added to the exception list.

Trusting the EXEs upon certificate would be more flexible, looking forward to hearing what Appeon answer regarding missing signed files from the extracted bundle.

Best,

.m

Hi Daryl,

For the exe in a random directory issue:
It is InstallShield that releases the temp file. It seems required to be signed with InstallShield certificate, we need more time to figure it out.
BTW, what’s the security software you are using. We tested with a list of mainstream antivirus software and they didn’t block the temp file.

For the bat file issue:
Not like exe, the bat file can not be signed, we will consider removing the bat file in the future.
And the antivirus software we tested with didn’t report any exception with the bat file. Please guide us to reproduce the issue.

For the MSI issue:
I suggest you find another way to push the MSI to the client end and don’t change the link in autodownload.html and manualdownload.html.

Regards,
ZhaoKai

Thanks ZhaoKai,

I've attached the properties of the two different LauncherSetup_withoutservice.exe files.  The one in the random temp directory isn't signed at all.  There are also some other executable files which are extracted (dotnetinstaller.exe and ISBEW64.exe), but they are both signed by Flexera so they are ok.

The installer isn't blocked by anti-virus. Our machines are locked down using application whitelisting implemented as software restriction policies via Group Policy. Essentially nothing can be executed unless we allow it in group policy. It can be allowed based on path, file hash or certificate.  Because they are executing from the temp directory our System Administrator isn't happy allowing them based on the path.  But also, I think the actual directory used is different each time.  It's easy to allow files to execute, but the Cloud App Launcher executes multiple files from different locations, so it's a bit trickier to handle with software restriction policies.

I think we can install the .msi via our central software deployment, but I don't think it's possible to do a silent install (without user interface) because the .msi file always displays the animated gif.  The System Administrator would rather do a silent install because it doesn't give the user a chance to cancel or interrupt the install.