Fileset Toggle ("Run" vs. "Install")

[AnEngelsen]

AFAIK, FileWave doesn't have the ability to repeatedly "Run" a script via the FileWave Kiosk.

Can anyone point me to the FileWave resource (written by @Josh Levitsky) that explains how to toggle an "Installed" fileset back to the "Install" state?

Thanks!

[Josh Levitsky]

Hi @AnEngelsen I don't yet have that KB posted, but here's the concept;

• Custom Field - I use a string for this where the field is first set to "new" and then "one" and then "two" to flip/flop devices between 2 smart groups Attached: Elevate Admin Custom Fields.customfields.zip
• Smart Groups - I have 2 smart groups as seen below. They are set to toggle devices between them based on if the field is set

Below is what the "1" smart group looks like. The "2" smart group is the same but looks for a value of "one" on the custom field. 

• Associations - Next you need the stuff you want to send. In my case I have the same Fileset twice. I duplicated it. I associated the first to the "1" smart group and then the "2" to the second smart group. I made them be Kiosk associations so that they wouldn't run over and over. This is meant for a tool that you want to have always available to run. Elevate Permissions (macOS) 1.fileset.zip Elevate Permissions (macOS) 2.fileset.zip

Perhaps take a look at what I have so far and if anyone wants to make this fancier or address any flaws in it I'm happy to get feedback. I also had a framework for a Windows version but it was lost when I made a silly mistake. It basically did the same thing as this macOS Fileset did, but for Windows. I know this is not a perfect solution but it was what I came up with to overcome our lack of a Kiosk option to re-run something. 

 

 

[AnEngelsen]

@Josh Levitsky and @Pierre-Nicolas

Dumb Idea: Does the FileWave API support a function that can send the "Uninstall" fileset command?

If "yes", then a postflight script could be added to any fileset. After the activation script is finished running, the postflight script would transmit an API call that would send the uninstall Fileset command. Correct?
(It might be necessary to include a "sleep 30" command at the start of the script; to ensure that the script doesn't get uninstalled too soon.)

Edited November 16, 2022 by AnEngelsen

[Josh Levitsky]

8 minutes ago, AnEngelsen said:

Does the FileWave API support a function that can send the "Uninstall" fileset command?

Really the trick I was using was to move devices between smart groups based on a custom field value that the API was used for. I do see your angle here because that would make there be 1 fileset needed rather than 2. The way I'd improve it because I don't think there is a way to just via API tell a client to remove a Fileset would be to imagine if the 1 Fileset would be assigned via Smartgroup that includes a Custom Field value being a certain thing and then maybe in the script that runs in the fileset it would have to handle changing that field, sleeping for a little and then setting it again. That's about the closest I could think but it's hard because you'd have to spawn a process that isn't attached to the activation script so that it lives and runs through the sleep and meanwhile Filewave would think the Fileset had completed already. 

In my thinking it through that's how I landed on the 2 Filesets and 2 Smart Groups where you bounce back and forth. 

[AnEngelsen]

Can you explain what happens (in the background) when the end-user clicks the "Uninstall" button (within the FW Kiosk)?

Standard associations can be configured with an "install on" and "removal at" timestamp. However, I never fully understood how Kiosk associations can toggle between two different states.
("Available in Kiosk" vs. "Installed via Kiosk")

[AnEngelsen]

On 11/16/2022 at 2:26 PM, AnEngelsen said:

Can you explain what happens (in the background) when the end-user clicks the "Uninstall" button (within the FW Kiosk)?

@Pierre-Nicolas can you confirm that the FileWave client does not use an API call to install or uninstall kiosk filesets?

[Pierre-Nicolas]

Correct - this is done locally between fwcld (the agent) and fgGUI (the visible kiosk / app portal), and then using the binary protocol (client / booster / server).

fwcld holds a list of fileset that must be installed, and a second list of kiosk fileset. Simplifying the process, when user presses "Install", fwGUI tells fwcld to add the fileset to the "to be installed list" - fwcld will then run the process to make sure the fileset is there and respects verification setting. When the user presses "Uninstall", fwGUI tells fwcld to remove the fileset from the to be installed list, so the fileset will be removed, as if the association would be gone for a non-kiosk fileset.

When a new set of manifests (either due to model update or to smart group membership change) is processes, fwcld will make sure that fwGUI state remains if the fileset is still part of the manifest, and that the winning association is still kiosk.

There is no callback to the server using the http API call - all of this has been in FileWave for more than a decade, way before we added the http API.