Here is the FlexConfig file I created for Cisco Spark.
Unfortunately due to the nature of Spark, which installs and updates automatically wholly within the user profile, this config will result in large archives (~180 MB) and cannot use DirectFlex. It's the best I could do, Cisco does not support any way of installing Spark for all users. That being said, the config file works great. You can actually create a default settings for UEM to "push" the application to users a well. I haven't done that yet.
# Does not use DirectFlex, since it is actually copying the entire app to the machine on logoff.
HKCU\Software\Cisco Spark Native
We use non-persistent floating pools and started having VDI users utilize the Cisco Spark for Web (Web based) as we couldn't get an All Users installer from Cisco. Having users install it on a daily basis was not an option. Since the Web version is lacking a lot of features that the Cisco Spark client has, we ended up ThinApp'ing Cisco Spark and the users stream it from a network location. Takes ~8-9 seconds to open as a streamed ThinApp and the ThinApp Sandbox will capture all user profile settings for Spark. There are a few random little bugs with it, but it works for us for now.
Hoping Cisco will have an All Users installer in the future, not holding my breath though.
We work with floating pools and auto refresh and thus having problems also with Cisco Spark. Because the program grows in size during use it is not a good option to copy the files either with DirectFlex or with anything else. This is why i have moved the programs folder to "C:\Program Files (86)\Cisco Systems" and this seemed to work pretty well, export the files used for user preferences with UEM and we have a fast working Cisco Spark in the vdi base image. I have completed a test with Cisco Spark successfully for a few different users.
I created a new custom config file in UEM and inlcuded the following:
I installed Cisco Spark as a user and copied the content of "<LocalAppData>\Programs\Cisco Spark" to "C:\Program Files (x86)\Cisco Systems\Cisco Spark".
Then i created a shortcut in UEM to "C:\Program Files (x86)\Cisco Systems\Cisco Spark\CiscoSpark.exe" and done.
The core files are in "<LocalAppData>\Programs\Cisco Spark" and these are the big ones you don't want to copy, therefore I moved it to local disk (this could be any location accessible to the user for read and write). All the user related files are in "<LocalAppData>\CiscoSpark" and in "<LocalAppData>\CiscoSparkLauncher", these files are not that big and can be exported without a huge delay.
If a user logs in and never used the program it simply shows the license agreement and want the user to log in, after that the settings are saved at logoff.
I haven't investigated this yet, as we use the latest app in the base image. Also we have a floating pool with auto refresh so update's would be removed automatically after reboot.
To work around this problem you could move the program folder to a redirected folder so then all files would be updated and auto refresh should not affect this.
There are also a numerous number of reg keys which could be modified, I exported them and replaced the path name with the correct one. Put these also in UEM.
The key's affected are:
"C:\\Program Files (x86)\\Cisco Systems\\Cisco Spark\\"=""
"C:\\Program Files (x86)\\Cisco Systems\\Cisco Spark\\Dictionaries\\"=""
"C:\\Program Files (x86)\\Cisco Systems\\Cisco Spark\\Resources\\"=""
"C:\\Program Files (x86)\\Cisco Systems\\Cisco Spark\\imageformats\\"=""
"C:\\Program Files (x86)\\Cisco Systems\\Cisco Spark\\bearer\\"=""
"C:\\Program Files (x86)\\Cisco Systems\\Cisco Spark\\audio\\"=""
"C:\\Program Files (x86)\\Cisco Systems\\Cisco Spark\\platforms\\"=""
I did some tests and 1 system gave me a message to restart Cisco Spark because there was an update, after the restart i had the new version without writing to <LocalAppData>. On another system though Spark complained about the integration service not being available and kept starting the old version. I then decided to overwrite the programs folder with the files of the new version and it started without complaining about anything, even the aforementioned integration service error was no more.
So to conclude, we have a working version and we can update it, either through auto update or by creating a script that overwrites the old files. And if we install the core files on a redirected folder we don't have to update our base image.
We keep our Master Image very lean as we only have the UEM/Horizon/AppVolumes Agents installed and Office 2013. We don't want to install Spark on the Master Image.
We are having issues with Cisco Spark randomly blowing up and actually killing the Windows 10 desktop (1 out of 3 launches of Spark will do this). We are attempting to use AppVolumes 2.11 with Cisco Spark as we don't want it on the Master Image. We install Spark during provisioning on a non-writable volume and move everything under "<LocalAppData>\Programs\Cisco Spark" to "C:\Program Files (x86)\Cisco Systems\Cisco Spark". And complete provisioning.
Our UEM is setup the same way as yours, that looks good. UEM works fine, everything persists over the non persistent desktops fine.
Has anyone attempted to use AppVolumes with Cisco Spark?
It appears i'm also getting the same results. based on the same way you set it up.
run cisco spark and after authenticating, it kills the desktop.
I'd be interested to see if anyone else has cisco spark working at a stable level on a non-writable appvolume.
We just stopped attempting to make Cisco Spark client work on our non-persistent VDI environment. We are just having users use Cisco Spark Web. We stopped having UEM save any settings for it as that was the cause of it crashing desktops (for the most part).
We sometimes get WebEx (which is an All Users installer under C:\ProgramData) to actually crash desktops as well.
Still waiting on Cisco to make an All Users installer... *not holding my breath*
Our solution that is working extremely well:
We put Cisco Spark in a thinapp have it sandbox to AppData\Cisco Spark. We then use UEM to capture that path. We do this for all applications that are user install apps. We do it for Microsoft Teams and Team Dynamix
The only issue we had was we needed to blacklist the cisco spark.exe as it was crashing with directflex.
<?xml version="1.0" encoding="utf-8"?>
<setting type="blacklist" list="ciscospark.exe|cisco spark.exe" />
To create and manage the BlackList.XML file:
New developments on this.
Years ago when we attempted to make this work as an all users installer they wouldn't support it nor did ALLUSERS=1 work. But this must have been changed recently. See the forum posts from Cisco below. This command did work yesterday for us on the latest MSI from their website. "msiexec /i CiscoSpark_x86.msi TARGETDIR="C:\Program Files" ALLUSERS=1" . It did install under C:\Program Files (x86)\ so it didn't adhere to the TARGETDIR switch, but either way it installed.
Still looking at proper settings for Directflex and such for it.
So far so good on testing. UEM is working great with DirectFlex enabled for "%ProgramFiles%\Cisco Spark\CiscoSpark.exe" (32bit flag enabled).
We set the "Export at logoff" as the Export moment for this one as we found it wasn't saving with a normal default of when the exe is closed. Spark uses several other exe names. So this helped save the settings on logoff. We have it set to not to create backups (Will just take up space for no reason)
Only UEM setting needed for Cisco Spark when its installed:
Very good! thanks for the info. I'll try the switched up MSI and see if that works for us.
i've just about given up and was ready to move over to just the web version on VDI.
FYI, Our network group got a reply from Cisco TAC Support, they don't officially support Cisco Spark in a VDI environment, but they do support the install via ALLUSERS=1. They say Spark running in a VDI environment for messaging will work well but audio/video and features like Proximity do not. This is what we are being told, so take it how you will.