Filesets / Payloads
Filesets in Central and Payloads in Anywhere are the same thing. As an IT administrator, you use FileWave Filesets to deliver software to devices.
- General Fileset workflow
- FileWave Fileset Types
- Fileset Groups
- Advanced Fileset Editing - Contents, Properties, Settings, and Dependencies
- Fileset Scripts
- Fileset Scripts Overview
- Fileset / Payload Script Exit Code Status
- Windows Requirement Script Examples
- Filesets - A Closer Look
- Filesets View
- Desktop File Level Filesets
- Desktop PKG and MSI Filesets
- Verification
- Windows Registry
- Apple VPP Apps
- Enterprise Filesets and Documents (iOS only)
- Apple Profile Filesets
- Android Apps
- Fileset Properties
- Dependencies
- Revisions
- Using Associations with Filesets
- Fileset Association types and precedence
- Associations to Deployments Strategy Guide
- How Are Deployments Different than Associations?
- What makes Deployments better than Associations?
- How to decide what is included in a single deployment?
- Combining payloads into a singular deployment based on metadata
- Should I create one, or multiple Deployments?
- The FileWave Associations-to-Deployment Conversion Tool
- Resolving Conflicts in Associations Conversion
- Explanation of Clones with Deployments
- Deployments in FileWave Central (v15+)
- Fileset Tools
- Fileset (Payload) Status in Inventory
- Fileset Reports
- Custom MSI installer parameters
- How to Enter Launch Arguments for Windows Setup.exe Installers
- How to Force a Reboot of macOS or Windows Devices after Installing a Fileset in FileWave v14.10+
- Fileset Magic
- Fileset Revisions
- Fileset Revisions Overview
- Associating a Fileset Revision
- Editing Filesets that have Revisions
- Managing Revisions
- "Default" Revisions
- Creating a New Revision
- Editing Fileset Revisions
- Removing/Deleting a Revision
- Troubleshooting
- Uninstalling Filesets
General Fileset workflow
Distributing content with FileWave is done with a simple workflow that can add complexity as needed. All of the information below is discussed in much more detail later in this Chapter. The basic workflow runs as follows:
- Select Fileset type – you choose the type of content (files / folders / profiles / scripts / etc.)
- Configure Fileset or add content – provide settings or assign content to the Fileset
- Associate Fileset to client(s) – you attach or associate a Fileset with a specific Client or Group
- Update server model – you commit the changes to the Server and the Fileset actions are performed by the Client(s)
A more complex model may include some or all of the following additional steps (Some items are specific to computer or mobile Filesets only):
Post-creation
- Specify Details – Settings can include forcing the Fileset to be redeployed if removed and/or causing the deployed application to be removed if the FileWave profile is removed.
- Provide Kiosk information – You can provide information for the user concerning this item.
- Edit Payload – You can open the Profile Editor and make changes to the settings.
- Edit Settings – You can specify the OS and other defaults for this payload.
- Add items – You can add more files / folders to this Fileset.
- Edit files inside Fileset – You can edit files directly within a payload.
Post-Association
These settings are covered in detail in the next section on Associations.
- Specify a download time – You can choose to deploy this Fileset at another time other than immediately after the model is updated.
- Specify an activation time – You can choose to activate the payload at a later time rather than right after the download is complete.
- Specify a deactivation time – You can choose a time to make this payload inactive (but have it remain on the Client), rendering it invisible to the user.
- Specify a deletion time – You can choose a time to remove the payload completely from the client.
- Designate Fileset as a Kiosk item – You can choose to make the Fileset self-installable by the end user; in other words, have it appear in the self-service Kiosk.
- Specify Fileset dependencies – You can specify that a Fileset requires another Fileset in order to function properly.
You have great flexibility with all aspects of Fileset deployment. You can choose to make certain Filesets react to conditions at the Client, specify certain Filesets for deployment at staggered intervals, pre-stage Filesets on Clients, and you can edit Filesets after deployment to add or subtract content as needed. Actions like these, and many more, give you the freedom to control your management at the file level, resulting in lower network loads, faster response times, and built-in self-healing of applications and content for your end users.
FileWave Fileset Types
Filesets in FileWave are content that you want to distribute. They can take several forms, and this article will explain them. To make a new Fileset in Central simply click New Fileset in the toolbar when looking at the Filesets area. This documentation is updated for FileWave 15.5.0 so older versions will have less of these options.
General
The Fileset types in the General section are shown below:
App / Folder
This is the most basic Fileset. You select a file or a folder from your working system; then assign the location for distribution. For example, if you needed to take a set of content files for distribution to every user who logs into a computer. First, you would select the files, in this case "Key Info":
FileWave creates a Fileset from this folder and displays it in the Fileset pane in FileWave Admin.
The "Key Info" Fileset was created from a folder with 3 files inside. Since it is a new Fileset, and the Server model has not been updated, it shows as a modified Fileset. FileWave assigns a database ID to every Fileset.
In order to prepare this Fileset for distribution, you double-click on it. This exposes the contents of the Fileset and allows you to specify the exact location for its distribution.
In order to make sure the files end up where you want them, you uncheck the box for Hide unused folders. FileWave allows you to send files not just to the exact same path you captured the files; but to a special location called All Users.
If you look at the various folders shown above, you will notice that most of them are the standard items that show up on any computer.
The All Users folder is there to allow you to take an item and drag it from the location path where you originally found it into a folder that will be placed into the home directory of every user account on a computer. In this case, we captured the folder item Key Info from the path /Users/johnd/Desktop and we want it to be distributed into the Desktop folder of every user who access to a computer managed by FileWave. What you would need to do is locate the original location in the Fileset Contents window, and drag that item into the final distribution location, as shown on the next page:
becomes…
A significant strength of this type of Fileset is that you can make changes to it at any time, update the model, and those changes propagate out to the associated clients, such as adding another document to the set, or replacing one.
Empty
Empty Filesets are best used for placeholders. You get an empty container that you can add content to at any time. This is an excellent Fileset to 'kickstart' the Kiosk on computers (the Kiosk shows up on a managed computer when at least one Fileset designated as a Kiosk item has been associated with that computer Client).
Once created, you can double-click on the Fileset to view the content window and add items as needed.
Scripts in Filesets
Empty Filesets can also be used to deploy scripts. You can create a script, save it as a shell script file, for example <myscript>.sh, and place that into a Fileset. The template for any script is simple:
#!/bin/zsh
# Put any script content here
exit 0
You can use any of the common shell dialects, such as sh, bash, tsch, or zsh. By default, the script is executed once, by root, when the Fileset is deployed to the Client. You would set a path for the script to be placed in a location that allows the system to access the appropriate controls, such as in /usr/local/bin/. Once the script file is added to the Fileset, you can set its permissions and other variables using the Contents window, which is accessed by double-clicking the script file inside the Fileset. Note: You do NOT put the "sudo" command into a script that is used in a Fileset; scripts run as root when executed by FileWave.
Superprefs and Empty Filesets
One excellent use of the Empty Fileset is for Superprefs files. You can create a Superprefs file (see Section 5.8) and just drop the file it creates (fwcld.newprefs.plist) into the Properties window. The settings will be activated upon arrival at the Client.
System Integrity Protection
Apple introduced a security policy with OS X v10.11 (El Capitan) that restricts any non-Apple code from running in protected areas of the system. Make sure none of your scripts try to write to, or edit code, in these areas:
/System, /bin, /sbin, or /usr.
For more information on SIP, see this WikiPedia article: https://en.wikipedia.org/wiki/System_Integrity_Protection
Fileset Magic
Sometimes, the content you want to distribute cannot be found in a completely deployable state. Fileset Magic allows you to build a Fileset from system snapshots taken before the installation/configuration of some software and after, resulting in a Fileset that contains the differences between the two snapshots.
Fileset Magic on macOS X is accessible from FileWave Admin, but you should use the special version of the Admin application - labeled FileWave Admin (root) - which runs as a root process in order to capture all possible file system changes needed to build a complete distribution. This is in /Applications/FileWave/ and was installed as part of the administration software. For Windows administrators, Fileset Magic can be accessed from the FileWave Admin login window as well as inside the Admin application. This allows you to run a Fileset Magic snapshot without the FileWave Admin interfering with Registry changes.
Note: When using Fileset Magic, you should quit all other running applications besides the required installers or updaters for your custom Fileset.
Once you have quit all unneeded applications, you create a snapshot of your system. It is a good practice to use a clean system for this process instead of your normal administrator machine. This will ensure that you are working with the files you want to add and avoiding dealing with all the additional files that get created on a production system from normal use. In other words, the snapshotting processes will run faster with a smaller number of files to scan.
Next, you choose the level of scan desired. Depending on what you are installing or modifying, you may need to deep scan the entire system. If you know where the contents are going to be placed, you can narrow down the scan. The Expert Settings… button lets you choose exactly what folders/directories you want scanned.
Once the initial scan is complete, you perform your installs and updates as needed. Run the second scan to get a comparison between the two scans, and choose which files you want to keep in your new Fileset. Once you have picked the files you need, you will name the Fileset and save it.
You can also choose to move any files that are needed by all users from the local account where they showed up into the All Users location in Fileset Contents. This would be general user-level application support files or specific settings for a local user. You can open the Fileset by double-clicking on it and edit / add / delete contents as needed.
For Windows systems, you will need to pay close attention to the Registry. Make sure you do not overwrite any Registry items that existed prior to your Fileset creation unless you are absolutely sure those changes are needed. You should also try to disable any virus-scanning software, backup utilities, and other software that might generate unnecessary files or Registry changes during the construction of the Fileset.
Import
The Import Fileset is actually a dialog that allows you to import a previously created Fileset.
Policy
The Policy option contains different option to help configure many accepts of the FileWave Clients. The first policy introduced with 12.7.0 is Blocker Script.
Blocker Script: This policy applies to desktop devices and allows you to suspend management via a script. The script will be run every 5 minutes or at verify and if its exit code is different from 0 the client will suspend its management. If the script finishes with the exit code 0 then the device will continue/restore management. If management is suspended FileWave will reflect this in inventory under the new Component type "FileWave Policy" and also in the new tab "Policies" in the Client Info window for the clients.
Software Update
FileWave allows you to capture the software updates provided by both Apple and Microsoft through their software update mechanisms and convert those updates to Filesets. The list of software update servers used by both providers is located in the FileWave Preferences under the General settings.
These URLs can be edited as changes are made. The updates do not include items that Apple is providing only through the iTunes or Mac App Stores. If you are deploying a large number of macOS computers and/or iOS devices, you should also plan to add one or more macOS servers running the Caching server process. This process caches all requests for Mac Store and iTunes Store content locally as devices request these items. See https://www.apple.com/support/osxserver/cachingservice/ for more information.
Deploying software updates
When you choose to create a Software Update Fileset, you will see a window that shows you either every software update available for the selected OS platform (iOS, macOS, or Windows), or just the updates requested by your Clients. With FileWave Admin, you will be able to capture the updates you want as Filesets.
Once you create a Fileset from any of the updates, you can then select the Clients to associate with that update.
Be careful of manually associating Software Update Filesets with just any Client. You should associate the Filesets with requesting clients only. As always, test any updates on a non-production device before mass deployment. Finally, check all updates for dependency issues. Make sure an update is not going to break any existing software.
You can filter the selections by choosing a specific Group in the Groups window (upper right).
Starting with FileWave 10, is the ability to see iOS updates. The iOS updates will show up here.
Note: These updates do not include items from the iTunes or App Store; it shows iOS operating system updates only.
Apple
Profile
The Profile Fileset contains all of the settings used for both computer and mobile device management on macOS and iOS. The Profile Editor in the Desktop Fileset window is identical to the one in the Mobile Fileset window.
DDM Asset
Added in FileWave 15.5.0, think of a DDM Asset as if it is a configuration setting. The first 2 DDM Assets in FileWave are Authentication credentials, and User identity.
DDM Configuration
Added in FileWave 15.5.0, think of a DDM Configuration as if it is a more modern Profile. It has options you can set and then can be assigned. DDM Configurations exist for things like Passcode Settings, Screen Sharing Connections, and Software Update Settings. The design is very similar to Profiles in our user interface, but it's driven by an all-new client side engine that Apple has in the OS.
App Store
You can create Filesets for Apple Clients using content from the Mac App Store. As with the iOS App Store Fileset, you are not actually storing the application or eBook inside the Fileset; but providing the URL to the content online. Filesets created in this manner can be distributed to a user's computer and require the user to enter their Apple ID in order to access the content, or you can link the Fileset to the Apple VPP store and provide either redeemable codes or managed distribution licenses for the provided content.
With FileWave, you have the ability to associate App Store content directly to a device, or to a user's Apple ID as part of a VPP distribution.
Autopkg
This will allow you to search for and add an Autopkg generated installer. You can read more about this in AutoPKG and this functionality was new in FileWave 15.5.0.
PKG
The two Filesets that do not store its contents as individual files are the PKG Fileset and MSI Fileset. For the PKG Fileset, you select a downloaded installer for macOS (.pkg and .mpkg). When the Fileset is deployed to the Client, upon activation it will run as an installer with local administrator privileges.
Document
With the ability to set "Open in…" characteristics in iOS 8+, you can also create Filesets with document content. This type of Fileset can contain pdf, ePub, and non-Apple iBookstore iBooks formatted items (ones created with iBooks Author). They are delivered to the iBooks Library as a managed document which means it can be given and taken away.
Enterprise
The Enterprise Fileset is designed for you to distribute an internally-created iOS application. Apple does not condone or support using this type of Fileset to distribute Apple App Store or iTunes Store content.
You can easily distribute software you have created with this Fileset by locating the .ipa file for the application on your administrator system and adding it to the Fileset list. All of the custom controls and settings are available for use with this distribution. You can select a remote location for the .ipa distribution. Normal configuration is to import the .ipa into your FileWave Server and wrap it up as a Fileset. The new method allows you to enter a URL to the .ipa, such as a web server, where the item can reside.
Microsoft
MSI Fileset
The two Filesets that do not store its contents as individual files are the MSI / PKG Filesets. For this Fileset, you select a downloaded installer for either Windows (.msi). When the Fileset is deployed to the Client, upon activation it will run as an installer with local administrator privileges.
Note: Filesets based on .msi will uninstall the contents when the Fileset is removed/disassociated. Instead of just removing the installer, the Fileset will perform an actual un-install process.
Windows-based distributions may come pre-packaged in the Microsoft Installer format (MSI). Customizations to MSI files can be made through Microsoft Transform (MST) files. FileWave supports MSI and MST through its Patch Installer feature. The MSI file must have a lower case MSI extension, such as Application Installer.msi, for the MSI file to be recognized by the Admin software. MST is supported by modifying a Patch Installer Fileset. An MST file must be copied into the same directory in the Fileset Contents Window as the MSI file. (This location is generally FileWave\FileWaveInstallers\Application.msi). Additionally, the MST file must be named exactly the same as the MSI file with a lower-case MST extension such as "Application Installer.mst".
Installations with Setup.exe Installers
Complex installations are contained in an executable file often named "Setup.exe." It may be simpler to deploy the executable file and have it run on the local computer rather than creating a Fileset based on snapshots. FileWave's Windows Client and FileWave Admin have features to handle the deployment of Setup.exe style installers.
The steps for this kind of deployment are as follows:
- Copy the Setup.exe file to the Desktop of the computer where the FileWave Admin program is running connected to a FileWave Server.
- Create a New Empty Fileset, give it a name and optional comment.
- Open the Fileset & uncheck the "Hide used folders" checkbox.
- Create a folder structure of where you would like the EXE file deployed. A good place is Documents and Settings\All Users\Application Data\FileWave\Installers.
- Copy the Setup.exe file from the Desktop of the Admin's computer into the folder created in the Fileset Contents Window. This will be the folder where the Setup.exe will be delivered to on the client computers.
- Select the Setup.exe file in the Fileset Contents Window and click on the Get Info button in the toolbar.
- Click on the tab labeled Executable.
- Check the checkbox labeled "Execute once when activated."
- Add any arguments or options to include as part of the installation process. Sometimes it is preferable to run installers silently. Many Setup.exe installers take a /quiet or /s or /silent argument.
Note: If you are unsure about the arguments, try dragging the Setup.exe into a Windows Command Prompt window and pass the /h or /help or /? argument to see a number of argument possibilities.
Winget
Added in FileWave 15.4.0, you can easily create installers for many Windows based applications with a single click. More information is located in Microsoft WinGet Overview.
Import Image
FileWave Imaging involves creating Windows images that are used to image new computers or to re-image current computers. This workflow allows Boosters to act as imaging caches during the imaging process. More information on Imaging is in Network Imaging / IVS.
Windows Drivers
FileWave Imaging involves creating Windows images that are used to image new computers or to re-image current computers. This workflow allows Boosters to act as imaging caches during the imaging process. More information on Imaging is in Network Imaging / IVS.
Play Store
You can use this to create Filesets from the Google Play store. This method also lets you select Private Apps that you have published in the Play store as well in case you need to send an APK to a device that isn't a public application there.
Policy
This is discussed with more detail in Android EMM Policies and Permissions but this is a way to set various settings on your EMM enrolled Android devices.
Fileset Groups
You can arrange Filesets into Groups for easier deployment workflows. Fileset Groups can be nested into other Fileset Groups, much like Client Groups. Once a Fileset Group is created by clicking the New Fileset Group button, existing Filesets may be dragged and dropped into the Group. Filesets and Fileset Groups cannot be cloned, so they can only reside in one Group at a time. Fileset Groups may be associated to a Client or Client Group.
Advanced Fileset Editing - Contents, Properties, Settings, and Dependencies
While you can create a Fileset and associate it with a Client without doing any additional steps. However, your ability to customize the Fileset contents, specify its properties, and alter its settings gives you a tremendous amount of flexibility in your deployment models. Once you have created a Fileset, it will appear in the main Filesets window. The basic properties of that Fileset are shown in the window menu bar:
- Name – This is the title of the Fileset you created.
- Size – This is the size of the Fileset in bytes as it is stored on the FileWave server. This can also affect your Boosters in terms of how much storage they will need to handle cached Filesets.
- Version – When a Fileset is first created, it is version "0" until you edit the Fileset and update the server model. As you make changes to the Fileset, its version number will increment.
- Files – This is the total number of files contained in the Fileset.
- ID – This is a unique identifier used by the FileWave server to keep track of your Filesets
- Comment – This is any optional text you enter to add information about the Fileset
- VPP Token – This designates which Apple Volume Purchase Program token is assigned to a particular Fileset.
The contents of a Fileset can be edited and altered as desired, depending on the type of Fileset. You can get specific information on items within a Fileset in order to customize its behavior when distributed. By double-clicking on a Fileset, you will see one of three different windows depending on the Fileset type .
Desktop Fileset contents
The Desktop Fileset contents are the specific items to be installed along with their designated paths. Examples are:
You can add items to the contents with the New Folder and Import Folder buttons. You can also remove any items that you are sure will not be needed in the final Fileset.
By double-clicking on a specific item or selecting an item and clicking on the Get Info tool, you can inspect file level information. This includes basic file information, permissions, ACLs if any are in use, Verification settings, script Executable details, and Flags that can be set.
FileWave, by default, sets many of these values correctly for the type of Fileset you are distributing. It is important, however, that you understand the Verification settings and how they impact the Fileset.
Verification
There are three primary verification settings. Each of these settings causes the related file(s) to behave differently once deployed.
- Self Healing – A file designated as self-healing will always be repaired or replaced by the FileWave Server if it is altered in any way. If you have items deployed that require their contents remain unchanged and intact at all times, you would set the files to be self-healing.
- Download if Missing – This setting will force a Client to re-download the file if the FileWave Client reports this portion of a Fileset as missing. The file will not be replaced if it has been altered; but only if it is deleted.
- Ignore At Verify (Left Behind) – Some files need to be dropped onto a client and left alone. This setting tells the FileWave Client to ignore any changes in this portion of the Fileset during a verification.
- Don't overwrite existing files upon deployment – This setting can be chosen to go with either the Download if Missing or Ignore At Verify (Left Behind). You can tell FileWave to not write over top of any files that already exist when the Fileset is activated.
- Overwrite only if the existing file is older –This setting is a subset of the one above, in that you might choose to allow older files to replaced only by newer versions of the same item.
Note: All file comparisons are done by filename and modification date.
Edit Registry
When you are working with Windows Filesets, you may need to explore the Registry entries. Within Fileset Contents, you can select the registry file and edit the contents. If you need to distribute a Registry file, you can add one to an empty Fileset.
- Edit Text – You can edit many of the text based files in a Fileset directly. In FileWave Admin's Preferences, you will see all of the various file type extensions that are supported.
- Export Files – Any file in a Fileset can be exported for use elsewhere. This capability can be used to open a complex Fileset and export portions of it for use in another Fileset.
iOS App and Enterprise Fileset contents
Filesets for iOS applications are focused more on behavior and end user information than actual file level content. The content consists of three panes: Details; Kiosk; and, Configuration.
Details contains general application information, management flags, and VPP information. The management flags include the ability to force application removal when the MDM profile is removed, and the ability restrict application data from being backed up in iTunes. A flag introduced in FW 10+ allows you to take management of an existing version of this application. If a user has installed an application that needs to be managed; because their device is managed, you can "take over" control of that application. This would allow you to control distribution and settings.
VPP shows the connection between a Fileset and a VPP account. A warning is shown (see screenshot on next page) if a VPP token is associated with the application noting that the Fileset cannot be attached to a different VPP account token.
Kiosk displays the information from the iTunes Store, online review ratings, and allows you to choose a category for the item when displayed in the Kiosk. You can edit the text of the application title, as well as the description. This allows you to personalize the information for your organization versus using the marketing material provides by the developer to the iTunes/App Store. In FW 10+, you can customize the information with tags, such as Bold, and underlined, for readability; plus you can add URLs within the information pane.
The Configuration pane allows you to add management settings for a specific application, if that application supports the use of a preference manifest. The settings must come from the application developer and will be in the form of a property list file (.plist). There is much more information on what these files are and how they are constructed in Apple's Developer site - https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html
macOS App / iOS eBook Fileset contents
Application Filesets for macOS and eBook Filesets contain the same type of content information in the Details pane, including the VPP token information. The Kiosk pane contains the same information as discussed in the iOS App Fileset contents.
The Requirements pane specifies the platforms the eBook can be distributed to and allows you to retroactively change these settings on actively deployed Filesets. Selecting Apply to Active Filesets lets you retroactively change Filesets that have been deployed.
Kiosk settings are the same across all Fileset types. You can set the category of the item, and edit the title and item description to better match your organizational needs. If you select Restore Defaults, the item's title and description will revert to what is posted in the iTunes/App Store online.
Profile Fileset contents
Profile Filesets have a simple contents window. You can view the various payloads that are contained in the profile, edit the payloads, export payloads, and choose the device settings. Settings include Platform choices which must match the categories in Profile Editor. The Installation choice determines whether the profile will be activated at system level (as a Daemon), which is prior to Login Window, or at user level (as a Launch Agent), which is at Finder launch. You can force the profile to reinstall if the user removes it. Devices that are running OS X 10.6 - 10.9 can have the legacy install flag set. This will force the settings that these devices get to be MCX .plist formatted, if the computers are running a FileWave Client earlier than version 9.
Details on profiles and configuring them are in Chapter 7 (Mobile Device Management).
Android Fileset contents
The Fileset created for Android contains only the .apk file. The file cannot be relocated, and other files should not be added to the set. The Get Info button exposes the permissions and other settings; but those values should not be changed from the defaults.
The Fileset will send the contents to the Android device's Kiosk. From there, the end user can select to install the item, which will place the contents in the Downloads folder for manual installation.
Fileset Properties
Once you have created a Fileset, you can access a wide range of properties that enhance the effectiveness of that Fileset in your deployment. The properties available vary depending on the specific type of Fileset. In most cases, the information presented does not need to be altered or edited; but this information is presented to allow you to understand the depth of control you have over your file level deployments.
Note: Making changes to Filesets can result in unexpected behavior, please test on a non-production device prior to mass deployment. Better yet - just test everything on a non-production system first.
Properties - basic settings
The first tab is the primary properties for the Fileset. The basic options are:
- Require Reboot (with Message) – In most cases, you won't need to require the computer to reboot; but software update Filesets usually do. You can provide a message to be displayed for the end user as a warning that software is being installed and a reboot will be required. Once you have configured a Fileset for reboot, you can also set a "Reboot deadline" to force the completion of the Fileset installation. This process is covered in the Associations section.
- Ignore Permissions on Existing Folders – Normally, the Fileset will overwrite permissions on existing files and folders during a distribution. You can choose to leave permissions in place; but recognize that in some cases, portions of the Fileset may not be installed.
- Installation Priority – When you are working with a Fileset Group or a series of Filesets to be distributed as a single workflow, the deployment often requires certain items installed before others. The Installation Priority lets you assign an order of activation. Highest items first, then lower priorities. When the installation priority is the same, the Fileset ID determines priority with lower ID numbers having the higher priority.
- Color - you can assign colors to your Filesets to differentiate them in the Fileset view.
Properties - Verification settings
- Self Healing – Use this setting to force the re-distribution of the file if any changes have been made to the existing Fileset files that have this label. This function will repair settings and other files that were accidentally or purposely changed.
- Download If Missing – During verification, if a file is no longer present, it will be replaced from the master Fileset.
- Ignore At Verify (Left Behind) – This setting will tell the verification to ignore anything with this label. This setting is often used in files that are meant to be dropped into a location once, and ignored after that.
- Don't Overwrite existing files upon deployment – This setting is a subset of the two settings above. It allows you to keep any existing files from being overwritten by other files with the same names.
- Overwrite only if existing file is older – This setting is also a subset of Download if Missing and Ignore At Verify (Left Behind), and can be activated if the above setting is in effect. It will allow only older versions of the same named files to be replaced.
Properties - Requirements
These settings establish the device definition that will allow the FileWave Client application (fwcld) to download and activate a Fileset. You can choose specific operating system platforms, architectures, memory, and system versions.
Selecting Apply to Active Filesets will force these settings to be re-applied on deployed Filesets. If a device no longer meets the verification criteria, the Fileset will be dis-associated and removed.
Properties - Delete Files
Use this tab to provide the paths to files that need to be deleted when this Fileset activates.
Properties - Kiosk
You use this tab to configure the appearance of your Fileset in the Kiosk. You can can change the icon, place the Fileset into a designated category, and edit the title and description of the Fileset. This includes changing the information provided from the iTunes/App Store to be something more oriented toward your deployment needs. With FileWave 10+, you can use Rich Text formatting to improve the look and feel of the Description.
Properties - Details
Details contains general application information, management flags, and VPP information. The management flags include the ability to force application removal when the MDM profile is removed, and the ability restrict application data from being backed up in iTunes. VPP shows the connection between Fileset and a VPP account (what VPP token was used for the item, if applicable). A warning is shown if a VPP token is associated with the application noting that the Fileset cannot be attached to a different VPP account token.
It is the same information you would see on that Fileset if you double-clicked on it or selected Get Info for that item. Those settings are reserved for Filesets from Apple App Store or iTunes Store content.
Exporting Filesets
Filesets can be exported for transfer to another FileWave server. They can be compressed and stored for future use or archived. iOS Filesets, however, cannot be exported.
Dependencies (introduced in FW v10)
You can designate one of more Filesets that must be activated/installed before another can be activated. If you associate a Fileset that has dependencies, then the other Filesets will automatically get associated and will be applied before the dependent one. It works with multiple, cascading dependencies also. The only Filesets that do not contain the ability to show dependency are the Apple App Store and iTunes Store Filesets.
In the Properties of a Fileset that has dependencies, you just click on the [+] to add any Fileset that must be activated prior to your dependent Fileset. You can also drag and drop Filesets within the Dependency pane to rearrange them in order of need. The first one to get activated will be at the top of the list. There is also a toggle at the bottom to check and see if there are Filesets dependent upon the Fileset that you are examining.
Starting with FileWave 11, is the ability to see a dependence chain when looking at the Fileset Status report in the Client Info dialog, where dependencies appear as children of the Filesets that require them.
Fileset Scripts
Fileset Scripts Overview
FileWave 11+ provides the ability to run a script at any of seven stages of Fileset deployment (called Activation States):
- Requirements
- Preflight
- Activation
- Postflight
- Verification
- Pre-Uninstallation
- Post-Uninstallation
In FileWave Admin, while in the Filesets view, the toolbar now contains a Scripts icon.
When you select a given Fileset, then click on the Scripts icon, the Scripts dialog opens
The dialog shows the scripts that will be executed for the given Fileset and the activation state in which they will be executed. The order in which scripts of the same activation state and Fileset are executed is the same as they appear in the list (i.e. from top to bottom). You can drag & drop scripts in order to change the execution order.
You can create and import scripts by clicking the corresponding buttons. Editing a script is also possible, so is dragging and dropping a script from Finder in order to import it.
Any changes to the Fileset will be applied when you click OK. If you click Cancel, the current changes will be lost and the Fileset will not be modified.
Scripts in the list can be double-clicked, which causes the file property dialog to appear. You can change most of the attributes of the script in the same way as in the open Fileset dialog. There are, however, certain attributes you cannot change. For instance, you cannot unset the Execute flag; therefore, it is disabled. For requirement scripts, it is not possible to change the interactive/non-interactive option, since the exit code of the script is required to decide whether the Fileset should be downloaded. Therefore, this field is also disabled.
The checkbox "Re-run requirement scripts on change and uninstall active Fileset if they failed" controls the same internal setting as the checkbox "Evaluate requirements on change and uninstall active Fileset if they failed" in the Requirements tab of the Fileset properties. If checked, when a Fileset needs to be updated, the Client checks the requirements of the Fileset again. This includes executing requirement scripts. If any of the requirements or requirement scripts fail, the Fileset will be uninstalled.
Fileset Scripts Types
- Requirements Scripts – A requirements script checks the requirement on the Fileset before any dependencies are downloaded. If any requirement script fails (return non-zero), then the Fileset and its dependencies will not be downloaded nor installed.
- Preflight Scripts – A preflight script checks the needs of the Fileset before the Fileset downloads, but after dependencies have been installed. If any preflight script fails (returns non-zero), then the Fileset won't be downloaded or installed.
- Activation Scripts – An activation script is executed upon activation of the Fileset.
- Postflight Scripts – A postflight script is executed after the installation of the Fileset has completed.
- Verification Scripts – A verification script is executed after postflight scripts and upon every "verification of the Fileset."
- Pre-Uninstallation Scripts – A pre-uninstallation script is executed on inactivation of a Fileset and right before a Fileset is uninstalled. (Useful if the script needs to reference a file that will subsequently be removed due to self-healing).
- Post-Uninstallation Scripts – A post-uninstallation script is executed right after uninstalling/removing the Fileset from a client and its dependencies.
Related Content
Fileset / Payload Script Exit Code Status
Script Exit Codes
Status Value
|
Status Description
|
Severity
|
Status Details
|
---|---|---|---|
220 | Failed! (Will Not Retry) | ERROR | Script exited with a failure, do not automatically retry |
210 | Success (Skipped Install) | ERROR | Script exited successfully, report fileset as installed but skip actual installation |
0 | Success | OK | Script exited successfully |
-1000 | Crashed | ERROR | Script crashed during execution |
-1001 | Time Out Exceeded | ERROR | Script execution time took longer than Get Info > Executable > 'Wait for executable to finish' > 'Wait for:' |
-1002 | No Logged In User | ERROR | Script could not run - no user currently logged in |
-1003 | Failed To Start | ERROR | Script could not run - failure to start the script |
Expected behavior
Requirements scripts processing rules
- If any of the requirements scripts returns 220, we stop executing scripts and also stop trying to install the fileset. No further action will be done, unless manually requested by an administrator, or unless a newer version of the fileset is available. The fileset status will be reported as "Requirements Not Met: Will Not Retry".
- If any of the scripts returns non-zero and ≠210, we stop executing scripts. Requirement scripts will be executed again 2 minutes later.
- If any of the scripts returns 210 when all other scripts return 0, the fileset status will be reported as "Skipped". The fileset will not be installed.
- Only if all scripts return 0, then we will install the fileset.
Kiosk
If a requirements script returns 210 or 220, the fileset will not be available in Kiosk.
If the dependency of a fileset has a requirements script that returns 210, it will not affect the availability of the main fileset. However, if it returns 220, the dependencies will fail so the main fileset will not be available in Kiosk.
Dependencies
- If the main fileset is at "Skipped" state, its dependencies will still be processed and installed.
- If a dependency is at "Requirements Not Met: Will Not Retry", that does not propagate up the tree. This means the installation of the main fileset will still fail due to failed requirements, but the main fileset will simply be reported as Download/Activation/Update of dependency fileset failure.
Other scripts
Whenever a requirements script returns 210 or 220, the fileset does not get installed, so other types of scripts (preflight, activation, etc) will not be executed. Only in case the requirements scripts are run again and they change, then the fileset might get installed and in that case other types of scripts will get run as usual.
Inventory
- Filesets in "Skipped" status are reported to inventory, like if they were actually installed.
- Filesets in "Requirements Not Met: Will Not Retry" status are not reported to inventory at all.
Windows Requirement Script Examples
Requirement scripts are executed on client devices with each tickle interval, 2 minutes by default, to check if the installation conditions outlined have been met. For example, it can used to verify if some file, registry key, service, or process is or is not present and decide whether to proceed with fileset activation or not, because you may want to
- Block redundant installations if the app is already present or
- Ensure prerequisites are present or
- Enforce a particular installation order.
If the requirement script returns any other exit code but 0 (e.g. 1 or -1) it is considered a failure and will be reported as a "Requirements Failure: Script" in the Client Info window and Fileset Report. This prevents the contents of the fileset from downloading and installing. As mentioned previously, requirement scripts will be executed every tickle interval and the fileset will be installed only when they all return 0. To check for multiple conditions simply specify multiple requirement scripts.
Below are some sample requirement scripts for Windows that can be customized for your own use. If you want the opposite condition, then flip the exit error codes in the examples.
Install if registry key present
::Replace HKLM\path\to\registry\key with the actual path to the registry key, e.g. HKLM\SOFTWARE\Macromedia\FlashPlayer
reg query "HKLM\path\to\registry\key"
if %ERRORLEVEL% EQU 0 (
exit 0
) else (
exit 1
)
Install if registry value present
::Replace HKLM\path\to\registry\key with the actual path to the registry key containing your value, e.g. HKLM\SOFTWARE\Macromedia\FlashPlayer
::Replace <value> with the actual name of the value, e.g. CurrentVersion in this example
reg query "HKLM\path\to\registry\key" /v <value>
if %ERRORLEVEL% EQU 0 (
exit 0
) else (
exit 1
)
Install if file or folder present
::Replace <drive>:\path\to\file\or\folder with the actual path to the file or folder, e.g. %ProgramFiles(x86)%\Mozilla Firefox\firefox.exe
if exist "<drive>:\path\to\file\or\folder" (
exit 0
) else (
exit 1
)
Install if application present in Programs & Features
::Replace <AppName> with the name of your app, e.g. Adobe Acrobat Reader DC
::Be as specific as possible because partial app names may provide a match when you don't necessarily want it to, e.g. Adobe will match both Adobe Acrobat Reader DC and Adobe Flash
reg export HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall %temp%\applist1.txt
reg export HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall %temp%\applist2.txt
copy %temp%\applist1.txt + %temp%\applist2.txt %temp%\applisttemp.txt
find "DisplayName" %temp%\applisttemp.txt > %temp%\applist.txt
find "<AppName>" %temp%\applist.txt
if %ERRORLEVEL% EQU 0 (
del %temp%\applist*
exit 0
) else (
del %temp%\applist*
exit 1
)
Install if service present
::Replace <service> with the name of your service from the Services control panel, e.g. Adobe Acrobat Update Service
::Be as specific as possible because partial service names may provide a match when you don't necessarily want it to, e.g. FileWave will match both FileWave Client and FileWave UltraVNC Server
sc query | find "DISPLAY_NAME" | find "<service>"
if %ERRORLEVEL% EQU 0 (
exit 0
) else (
exit 1
)
Install if process present
::Replace <process> with the name of your process, e.g. notepad.exe
tasklist /FI "IMAGENAME eq <process>" 2>NUL | find /I /N "<process>"
if %ERRORLEVEL% EQU 0 (
exit 0
) else (
exit 1
)
If you find that you need to delete a requirement script for any reason, right-click that script and choose Reveal in Fileset. That will open the Fileset Contents window with the script file highlighted. Click the Delete icon in the toolbar to delete your script.
Remember to always test your requirement scripts locally first before adding them to a fileset. With the above building blocks as examples, you'll quickly be on your way to taking advantage of requirements scripts for providing conditional intelligence to your Windows filesets.
Filesets - A Closer Look
Contents, Properties, Settings, Revisions and Dependencies
Filesets View
Creating a Fileset and deploying to clients can be relatively simplistic, e.g. PKG, MSI or VPP. However, custom configuration through properties, provides tremendous flexibility.
The standard Fileset view provides some basic details:
Name |
Fileset Title |
Size |
Fileset size, as stored on FileWave Server and Boosters or Clients when transferred. |
Version |
Each update to a Fileset will increment its version number after the Model Update |
Files |
Total number of files stored within the Fileset |
ID |
A unique identifier used by FileWave to track each Fileset |
Comment |
User customisable text for viewing in FileWave Admin software only |
VPP Token |
Apple Volume Purchase Program token name |
Default Revision |
Indicates the default revision to be deployed, where a Fileset contains multiple revisions |
Revision Count |
Highlights the amount of revisions within each Fileset. |
Each Fileset, though, has additional, customisable features, which vary depending upon the Fileset type, e.g. Apple VPP, Windows Registry or File Level, as covered in the other pages of this chapter.
Desktop File Level Filesets
Contents of a file level Fileset will be delivered to devices, with matching permissions and ownership. The entire directory structure of the Fileset will be copied, with any directories created if not yet existing.
Example 1
Example 2
Additional items may be included by way of either the New Folder or Import Folder buttons. Files and folders may also be added by way of drag and drop. Other attributes may be observed and altered through the Get Info button, when an item is selected.
Beyond ownership and permissions, further options are available also, for example, ACLs, Verification and file execution (scripts and EXE files). Verification has its own page in this chapter and is important to understand.
A selected file’s contents may be altered using the Edit Text option. This is particularly useful for scripts, but can apply to many file types, as set within the Preferences > Editor tab.
Files may be selected and exported from the Fileset to the local device.
Desktop PKG and MSI Filesets
Special Filesets may be created for PKG and MSI installers. These will automatically instal the software on deployment activation. Simply dragging and dropping a PKG or MSI directly into the Fileset window view, will generate the necessary Fileset as required, without the need to use the New Fileset button.
File Level Filesets (including PKG and MSI Filesets) can be exported for transfer to another FileWave server. They can also be compressed and stored for future use or archived.
Verification
There are three primary verification settings. Each of these settings causes the related file(s) to behave differently once deployed.
Self Healing |
Files set as self-healing will be replaced on devices with those within the Fileset, if different, or added if missing. The act of Verification re-confirms all included files. |
On disassociation, Files included in the Fileset will be removed from the device |
Download if Missing
|
Similar to self-healing, however, the file will only be added if the file is missing. After initial deployment, the file may be altered, without repair occurring at Verification |
On disassociation, Files included in the Fileset will be removed from the device |
Ignore At Verify (Left Behind) |
Once delivered, the file may be altered. |
On disassociation, delivered files will remain on the device. |
A couple of additional options are available:
Don’t overwrite existing files upon deployment |
If enabled, only deliver the file if it does net exist. |
Overwrite only if the existing file is older |
A sub option to the overwrite option, only replace the current file on the device, if that existing file has an older timestamp than the matching file in the Fileset. |
File comparison is by name and modification date.
Any files that already exist between one Fileset and another, will not be transferred between server and client since they already exist as required; with the exception of the overwrite option on initial deployment.
Windows Registry
Windows registry files may be included within a Filesets and edited within FileWave.
Apple VPP Apps
Unlike File Level Filesets, Apple VPP Filesets contain the details of the App from the App Store, including the link to the App, with 3 distinct tabs, Details, Kiosk and Configuration.
FileWave does not store Apps from the App Store, devices will pull the Apps directly from the App Store on successful activation.
Details
Amongst these are some key entries:
Remove App when MDM profile is removed |
If the device has the MDM enrolment profile removed, this option will force Apps managed by MDM to be removed. |
Prevent Data Backup |
Disallow the App from backing up user data |
Take management of this app if the user has installed it already |
For Apps already installed, the MDM server will take over management of the App from the user. This allows VPP to auto update the App, amongst other things. |
eBooks may also be delivered:
Kiosk
Details to be displayed to the user through the FileWave Kiosk App, including App Store ratings, description, etc. Text may be updated, categories added or removed and icons replaced.
Configuration
Enhanced App configuration may be applied, where developers have chosen to offer such features, by way of a preference manifest in plist format.
Suppliers of Apps should provide details if they exist.
Enterprise Filesets and Documents (iOS only)
Apps developed outside of the App Store may also be delivered to devices, where developer requirements are met. Documents may also be delivered to devices.
These Apps or documents may be stored either locally on FileWave Servers or remotely, with a URL link provided.
Apple Profile Filesets
Profiles utilise Apple’s defined payloads, allowing management or configuration of User and System. FileWave presets User or System correctly where only one option is available for included payloads. Some payloads, though, could be either User or System as shown in the Fileset Settings:
User |
Only set when a managed user logs in |
System |
Payload settings applied regardless of user logged in. |
Apple allows the management of any amount of directory users for a single device. However, only one local user will be managed. This user will be the first user after enrolment of the device.
Profiles are stored directly within the Fileset and delivered to devices after MDM communication has been established.
Android Apps
Android Filesets are created from either the public or private Play Store. Additionally, Web Apps may be considered.
Three tabs are available for a Play Store App Fileset: Configuration, Permissions and Managed Properties. The later will only contain management options, where the developer has chosen to include options.
Configuration and Permissions should be reviewed, as should any any management properties where they exist, before assignment.
Fileset Properties
Properties exist for most Filesets, but options displayed will vary depending upon Fileset type.
File Level Filesets include:
Properties |
Additional features, including Reboot (force sub-option), priority and an option to alter the verification for the entire Fileset. Priority offers additional control over the order of Fileset activation. |
Requirements |
Settings defining the OS and hardware specific necessities. Only if devices match these, will the Fileset be downloaded and activated. |
Dependencies |
Discussed in greater details elsewhere. In essence, the Fileset will only activate if another defined Fileset instals first. |
Delete Files |
A Defined list of files to be removed during activation |
Kiosk |
Details shown to users via the Kiosk Self-Service menu and system tray item. |
Example, File Level Requirements:
Example, Apple App Store Details:
Example, Apple Profile Kiosk:
Profiles may only be a dependency in one direction, to prevent unexpected delay of Fileset installations.
FileWave has no control over the MDM protocol, but must rely upon Apple’s process for delivery of MDM items. For this reason, using dependencies, an MDM Fileset, e.g. Profile or VPP App, may be defined to instal after any other non-MDM Fileset type has been activated, but does not allow other Filesets to be reliant on an MDM Fileset.
Dependencies
Dependencies offer a way to associate multiple Filesets with reliance upon other Filesets to be installed first.
From the below example image, 2 Fileset Dependency Properties are displayed.
- Left image: the Fileset which will instal first (should not be associated with devices relying upon this dependency).
- Right image: the Fileset that will be associated and therefore instal afterwards. It can be seen that the Fileset on the left is shown as a dependency of the Fileset on the right.
Multiple Filesets may be used as dependencies or be the dependent. Dependents of a Fileset may also be a dependency of another Fileset, creating a chain of Fileset installations.
Revisions
Previously, updating one version of a software, for example, to a newer version, would require: a new Fileset created, new association or deployment generated and then the prior association removed. Revisions simplifies this process.
To prevent associations or deployments being altered, a Fileset becomes a container of multiple revisions.
The version associated with devices may be altered within the Fileset. This allows for efficient update of Filesets on devices, simplified process between testing and mass assignment, whilst at the same time providing an easy method to roll back if found to be necessary; depending upon Fileset Type.
Behind the scenes, swapping from one revision to another is the same as actually swapping between two different Filesets. All contents will be reconsidered and any scripts ran, e.g. a post-uninstaller script will run if included in the Fileset Revision that is being unassigned.
Using Associations with Filesets
The Associations pane is the primary location where you connect your Filesets to your Clients. The window has three primary sections:
The link between a Fileset and a Client, or client Group, is called an Association. In order to distribute the contents of a Fileset, you associate a Fileset to a Client or Group.
Basic Association Workflow
The basic workflow is select a Fileset, link it to a Client/Group, the update the server model.
- You choose a Fileset from the upper right pane:
- Click and drag the Fileset to the left into the Clients window and drop it on top of client or client Group you want to associate it to.
- Finally, click on Update Model in the main toolbar, or use Cmd-U (macOS) or Ctrl-U (Win), to lock in the change.
Customizing the Association
The basic workflow will associate a Fileset with a Client. When the Client checks in following the server model update, the Client will get a new Manifest from the Server containing a list of any new Filesets to be associated or changes in existing Fileset associations. The Client compares the Manifest to its Catalog (current state after previous check-in) and build a work list if things have changed, which can include pulling down new Filesets, deactivating existing Filesets, etc
The power of Filesets and associations is that you can enhance the basic workflow with options that provide significant improvement in the deployment process, as well as expanded control of the workflow.
Viewing Associations for a single client / Group
The first improvement over the basic workflow is being able to look at the Filesets that are associated with a specific Client or Group. You do this by right-clicking on the Client or Group in the Clients portion of the Associations window and selecting Show Associated Fileset. This will change the Associations view in the bottom part of the window to
show you all of the Filesets that have been directly associated with that specific Client. We stress directly because you can associate Filesets with Groups of clients also. Those associations would not show up in this view. This concept is important because you may find yourself in a situation where you see something happening to a Client; but you don't see the Fileset that would create the situation in its direct associations. The solution to this situation is to look from the "other side" by selecting a Fileset and asking to view all of its associations. Associations may also be made to Smart Groups and or to Clones in regular Groups.
Viewing clients associated with a single Fileset
If you select a Fileset, you can right-click to view all associations that have been made for that specific Fileset. Doing this can resolve the problem you may have in tracking down how many different places a Fileset has gone.
Searching and filtering the Associations window
Another powerful function is in the Search / Filter window. You can enter any text into the Search window, press Return, then choose the criteria for your view of any association that is active. Your criteria can be to look for a Fileset with that text, a client, Group or Clone, a Fileset ID, of Fileset type (such as Kiosk), or just select All Columns to let the search find every association that has that text in it no matter what it applies to.
Editing the Association
Another capability of the Associations window is the ability to edit Fileset associations. Within this functionality, you have the power to designate the deployment schedule, change the type of Fileset from standard to self-service Kiosk, and choose when the Fileset is deactivated and removed from the client.
There are two Edit windows available, depending on the type of Fileset being deployed. Most computer and Android Filesets have the ability to designate a full range of settings:
- Start downloading at – This tells the Client to start downloading the Fileset at a specific date and time. The Fileset will be downloaded and cached locally, but is inert; i.e., it will have no impact on the Client (other than storage space on the drive) until it is activated. This allows the FileWave administrator to pre-stage Filesets out on clients using a staggered deployment schedule prior to activation. Using a staggered schedule would allow systems administrators to minimize network traffic bottlenecks when distributing large deployment sets. This action can also be used when you have staged a Fileset that is still being tested, and there was a problem with the test results. Instead of having to reset devices, you just delete the Fileset prior to activation.
- Activate files at – This tells the Client when (date and time) to activate the Fileset. Installers will run, shell scripts will execute, and any files will be placed into their proper places. Since this command is only a signal to the client to have the Fileset perform its action, the network traffic is minimal.
- Make files inactive at – This tells the Client to locate and move all components of that Fileset back into the local cache, so that the Fileset no longer has an affect on the operation of the Client computer or device.
- Delete files at – This tells the Client to delete the Fileset at a specific data and time.
- Kiosk Association – This converts the Fileset from a standard distribution to a self-service Kiosk item. Filesets that have been distributed as standard items can be converted to Kiosk mode and vice versa.
iOS Filesets can be installed, deleted, and changed to Kiosk items. Apple iBooks can be installed by time or changed to be Kiosk items. iBooks cannot be deleted - once deployed, they are the property of the end user.
License Distribution (FW 10+)
You have the ability to designate that an Apple Volume Purchase Program "Managed Distribution" license be applied to either an Apple ID that is associated with a macOS computer or iOS device or to the device directly. This applies only to applications controlled by Apple's VPP, with the additional requirement that the application developer configured the application to support direct device assignment. You can see if the application is device assignable in the App Store under the application.
You can set a default value of User or Device assignment in FileWave Admin's Preferences, in the VPP & DEP tab, but can override the default settings on a per-Fileset basis, if both options are supported for the application in the Fileset. As you can see from the example below, one of the chosen applications has the Assign License to Device greyed out, meaning that this specific application must be assigned to a designated Apple ID, because it does not support direct device assignment.
Note: If you want to provide custom settings for deployment times to a large number of Filesets, using a Fileset Group is the best way to achieve this goal. Filesets within Fileset Groups that are associated to Clients or Client Groups will all get the same settings you designate with the Edit Association pane for that Group.
Special setting for the Requires Reboot property
When you have a Fileset, such as a system software update, that requires a reboot of the client, the user may try to cancel that update to avoid the reboot. In FW 10.1+, a feature was added to the Fileset Associations editor window that allows you to set a deadline for the reboot. This editor property can be set for a Group of Filesets, or for a single Fileset. When the deadline comes, the device will reboot automatically in order to complete the installation of the designated Fileset.
Association Tools
The tools and actions available to associations allow you to see the various aspects of the association:
- Reveal Client/Group/Clone – This displays and highlights the Client/Group/Clone related to this association in the upper-left portion of the window.
- Show all Associations of this Client/Group/Clone – This displays and highlights all associations related to the client/Group/Clone in the lower portion of window.
- Reveal Fileset – This displays and highlights the Fileset in the upper-right portion of window.
- Open Fileset – This displays the contents of the Fileset (same as double-clicking on Fileset in the Filesets view).
- Open Fileset Report Window – This displays the report showing the status of a Fileset, Filesets, or Fileset Group's distribution.
- Show all Associations of this Fileset – This displays all of the Clients associated with this Fileset
- Delete Association(s) – This removes the linkage between the Client/Group and the Fileset. In most cases, this will result in the Fileset contents being removed from the Client/Group. With VPP managed distribution, the license is revoked and added back to the list of available licenses.
Association Conflict Resolution
The algorithm for computing which Client receive which associations is quite complex. As a result, you may end up "double associating" a Fileset to a Client (e.g. if it is cloned into two Groups, both Groups are associated with the same Fileset). We have solved this issue by allowing only one Association-Fileset-Client chain. A Fileset can only be associated to a client via one Association. The chosen Association's commands will be followed, and all other associations ignored. The "winner" association is determined by association distance.
Association Distance
The FileWave Server resolves conflicting associations by choosing the most direct association. For example, an association directly from a Fileset to a Client is more direct than to its Group, and an association to a Client's direct parent is closer than an association to its grandparent. Clones also increase distance. Closer associations always win. Equidistant Associations are treated by ID-descending, meaning that new associations (higher ID numbers) beat older ones. This is discussed further in Fileset Association types and precedence.
Smart Groups
Smart Group associations are calculated separately, following the same distance method. However, if a Client is associated by both a Smart Group and a regular association, the regular association will always win. When you view Associations, you will only see the Filesets that are directly associated with that Client or Group. Associations made to a Smart Group will not show up when viewing the Client associations and vice versa.
Imaging associations
Imaging Filesets and their associations are covered in Network Imaging / IVS.
Fileset Association types and precedence
There are several ways Filesets may be associated with devices, and the method used will affect activation. This article shares example associations.
It does not matter if this is an Association or a Deployment. Each client has one manifest and the below rules apply, however the link between Fileset and Client is established.
1:1 Associations
These are direct associations between a Fileset and a device (or clone)
Standard Association
Automatically installed without user intervention
In the above image, one Fileset is associated directly with this device; Type – Standard
Kiosk Associations
User initiated installation from the Kiosk Menu Item or System Tray.
In the above image, one Fileset is associated directly with this device; Type – Kiosk
Group Based Associations
These are associations between a Fileset and a Client Group.
The below image shows the same Fileset associated with two different client groups; one group nested inside another group.
This example demonstrates the Keynote Fileset associated with two Client Groups: Test Group and Nested Test Group.
Expected behavior:
- Client 'Hilda' will install Keynote without user intervention
- Client 'FileWave Support - C02DNSB8Q6L4' will have Keynote available to the user via the Kiosk.
The below image provides another more complex example, with more nested groups.
Excel Fileset is associated with three groups: Test Group, Nested Test Group, and Double Nested Test Group.
Expected behavior:
- Client 'FileWave Support - C02DNSB8Q6L4' will have Excel available via Kiosk.
- Client 'James Big Sur 11.2.1', 'Andrew_macOS_BigSur' and 'Hilda' will install Excel without user intervention.
Association Distance
Where the same Fileset is associated to a device by more than one path, the device's 'closest' association should win.
- Direct Association to devices is closer than a Direct Association to a Clone
- Association to a parent group is closer than one if its nested groups
- Association to a group is closer than a Clone within that group.
Each association is given a score.
Association to... |
Score |
Device |
0 |
Device Clone |
1 |
Static/Smart Group |
2 |
Clone of Static/Smart Group |
2 |
The score is determined starting with the device or clone and working back to the actual association.
Example
Consider the below Tree Structure:
Root
+ Static Group 1 - 2__
|
+ Static Group 2 - 2__
|
+ Static Group 3 - 2__
|
+ Smart Group 1 - 2__
|
+ clone of device - 1
+ Static Group 4 - 2__
|
+ Smart Group 2 - 2__
|
+ clone of device - 1
Total Scores (lowest score wins):
Association to... |
Scoring |
Total |
Static Group 1 |
1 + 2 + 2 + 2 + 2 |
9 |
Static Group 3 |
1 + 2 + 2 |
5 |
Smart Group 1 |
1 + 2 |
3 |
Clone of device in Smart Group 1 |
1 |
1 |
Static Group 4 |
1 + 2 + 2 |
5 |
Smart Group 2 |
1 + 2 |
3 |
As such, an association to Smart Group 1 is closer than Static Group 4.
Matching Score
Closest always wins; however, where the distance is the same, the highest Association ID will win, which should be the last association created.
Hence, if an association of a Fileset was made to Smart Group 2 and then to Smart Group 1, the association to Smart Group 1 would win, as this equidistant association is the latest and hence will have the highest Association ID.
Associations to Deployments Strategy Guide
Deployments are the replacement for Associations as you move forward with FileWave in future. Deployments allow you to set rules for content delivery just as associations do, but deployments also allow you to group “associations” into one place to edit and organize them commonly.
When using the webadmin you will notice that you can not create associations any longer, and will use deployments in their place. But, don’t worry, deployments are easy to understand and use!
How Are Deployments Different than Associations?
What
Deployments are not exactly the same as associations, but they are very, very similar. You can think of them as über-associations, or grouped associations.
When/Why
We’ll use deployments to assign content to devices, just as we would with an association. But, deployments also give us the ability to group multiple associations together in order to create simpler, easier to both find and manage content delivery rules.
How
Reference the View - Deployments article to see how one creates a deployment from scratch, but in the below articles you’ll also see how to use our Associations to Deployments Conversion Tool to create deployments from multiple associations and also look at the benefits of Deployments overall.
Digging Deeper
Deployments contain the same rules for content delivery as Associations do, such as:
- Timing options for installation
- License management (for VPP related content)
- And installation method (such as Kiosk, or direct installation)
But deployments, unlike associations, also allow you to assign those same rules to many different filesets/payloads at the same time. And, when changes are required, a singular change makes the change for all payloads.
What makes Deployments better than Associations?
What
Deployments are new, and will replace Associations entirely eventually. But, does this make them better? Why yes, indeed it does! However there are exceptions where Associations still may be required.
Deployments
First consider deployments.
When/Why
Why Deployments rather than Associations? There are three primary improvements with deployments over associations:
- The ability to specify Exclusions in a deployment
- New targets/payloads can be added to existing deployments and will inherit the options
- Neater Fileset grouping
Exclusions allow you to specify a big target group like “All Windows”, and EXCLUDE from the deployment a subset, perhaps the “Staff Windows” group as an example
Once an Association is converted to a Deployment, the Association will currently still show in FileWave Central, but will no longer be editable as an Association; the Deployment is now managing the assignment of any Filesets included.
How
Let’s look at a case study. If we were to create associations for the following 4 apps to the Windows Computers group:
Then that will result in 4 associations, each with their own properties. And if we want to switch them all to Kiosk, then we must find/edit them together or individually. If we decided to then add the BGInfo payload as well, we’d have to create another association, and edit that one too.
But, the same exact scenario with a deployment is only one entry, with multiple parts:
Therefore, we only need to edit these in one place and one time to change them all to Kiosk. This makes them more efficient, and if we want to add BGInfo to this deployment, then we can do so -- with that installation now inheriting the same rules.
Fileset Grouping
Deployments do not impact Fileset Grouping. Perhaps it is nice to group Filesets by type or by Vendor:
Deployments make it easy to keep Fileset structure, with the assignment of the Fileset contained within the Deployment.
Without Deployments, it would be typical to have something like:
The Default Apps Group, although desirable, has fragmented the Filesets. The latest versions of Adobe Reader DC and Google Chrome are no longer in their respective Fileset Groups. With the addition of multiple default and Kiosk Apps, this fragmentation issue is compounded and makes it harder to keep a neat Fileset structure and to find Filesets.
Digging Deeper
For those who already efficiently use Fileset/Payload groups in associations, you may be asking “Isn’t that the same thing?”. It is, almost…even if you are already efficient with this, Deployments still bring exclusions and the ability to easily find them (by name). So, even then there is an advantage.
Associations
How about Associations?
Associations stand out due to a key feature when working with Fileset timings. Imagine one of the Filesets is chosen to be set for Deletion or to be made Inactive for a period of time, but to be made Activate again later.
It is not possible to change the timings for just one Fileset within a Deployment and so that Fileset will need to be removed from the Deployment.
Associations allow the same Fileset (but differing Revision) to be associated to the same Client Group.
Filset Timings
Deployment timing options show as:
All options apply to all containing Filesets. If there was a requirement to alter one Fileset, to perhaps make it temporarily disabled, with Deployments it would involve either:
- A temporary Deployment would be created to move the Fileset into, returning the Fileset back once re-activation is approved
- A permanent new Deployment is created and this one Fileset will now only live within this one new Deployment thereafter
- Another Deployment will be created, but the new Deployment will be 'closer' to the target device(s) and set as inactive, until re-activation is required and this new Deployment may then be deleted
Associations are handled individually, as such the current association timing may be changed without any other concerns.
Revisions
Each Fileset may have multiple Revisions, but why is this beneficial? Consider the question 'How and, more importantly, when is one Revision going to replace another?'
- Associations may have differing Revisions of the same Fileset Associated to the same group of devices
- Deployments can only handle a single assignment of a Fileset, regardless of Revisions
Kiosk
By supplying multiple revisions to the Kiosk, users can have the ability to choose between Revisions. With Deployments, a new Deployment would have to be created to allow for each alternate Revision, whilst with Associations, all chosen Revisions may be associated to the same Client Group.
Timed Revision Updates
It is often desirable to transition between two Revisions at a chosen time, for example, out or hours. Achieving this with Associations is much neater. The same group that already has the current Association will receive the Association to the new revision. Within each Association, the time would be altered, one set as Delete and the other set as Activate. When that point in time is reached, the magic happens and the Revision on the devices is replaced.
As an example, below are 2 Associations of the macOS EyeBrowse App, both to the All macOS group, but the current version 1.0 is set for Deletion at the same time that version 2.0 is set for Activation.
Again, with Deployments, a new Deployment would need to be created, just for this one new Revision. Actually 2 new Deployments!
Why 2 new Deployments? A single Deployment may only handle one Fileset (regardless of Revision). The original Deployment will have no timings set, nor should it. As such one Deployment needs to be created for the Deletion and another Deployment for the Activation.
Once the target Date and Time have been reached, the additional Deployments themselves could be removed, with the Fileset being reinstated, back into the original Deployment.
If you do this with many Revisions, then the quantity of Deployments becomes unwieldy, with differing Deployments handling differing Revisions.
For this same example, the Eyebrowse App is contained within the Deployment:
As such, new Deployments would need to be created to handle the timed Revision changeover.
Original Deployment (EyeBrowse Removed) |
Deletion Deployment | Activation Deployment |
Neatness
This is a fundamental consideration of the choice between Associations and Deployments.
On the one hand, Deployments are neater. Filesets can be grouped, sensibly by either vendor supplied, Fileset contents type, etc. however seen fit. The Deployment then handles the link between the Filesets and the Clients. Associations causes Fileset grouping to be dictated by the Association instead, fragmenting the Fileset structure.
On the other hand, Associations keep things neat, where Fileset Timings are concerned. One single Client Group can handle all Revisions for any single Fileset or a single Fileset Association's timings can be altered, preventing the need to build out lots of Deployments.
Conclusion
Yes Deployments are better, but currently only in some instances. Each assignment of Filesets to Clients should be considered, with merits given and choices made appropriately, be that Association or Deployment.
Like to see examples in action? Check out the Foundry Onboarding section on Associations and Deployments, which contains a comparison video.
How to decide what is included in a single deployment?
What
So deployments allow us to put together multiple payloads for deployment in an easy way and then edit these deployment rules in bulk. Great! But, which things should I put in the same deployment?
When/Why
The question above applies whether you are creating brand new deployments, or converting existing associations to deployments. In either case, we need to answer the question, “what content belongs together?”
How
And how we evaluate this is to look at two primary things:
- What is the least amount of work for us, the FileWave Administrator, and
- The metadata of a deployment:
- Licensing options
- Timing Options
- Delivery Options
- Fileset/Payload Revisions
- Destination platform
Both of the above questions are broken down in the following articles referenced below.
Combining payloads into a singular deployment based on metadata
What
Every deployment has related metadata about the content being deployed. That is, HOW it should be deployed, WHEN it should be deployed, and what LICENSING options to use.
When/Why
Deployments are only effective for multiple payloads/destinations if ALL of those metadata elements match. See below for examples.
How
So, how do we make a decision here? Generally it is very easy. If ALL of the below are true:
- If all payloads are meant to be installed by Kiosk, or conversely by Direct Installation
- And If the timing options are all the same
- And if the licensing options (i.e. Device Assigned) are all the same
- And if the destination(s) for and the revisions of the payload(s) are all the same
Then, we can combine all of these elements into the same deployment.
For instance, if we want to deploy Firefox by Kiosk to all devices in Accounting and HR, then we can combine those into a singular deployment.
But, if we wanted to install Firefox via Kiosk to Accounting, and via direct installation to HR, then we could NOT combine this payload in the same deployment.
Digging Deeper
Conversion of associations to deployments will follow the same rules…generally, you’ll combine associations into one deployment if the metadata matches, as shown below:
These associations all make good candidates for being combined into one deployment because:
- They are all direct installation (Type: Standard)
- They have common timing (none actually)
- They all have the same destination group/platform
- VPP Apps all have the same license type (Assign to Device)
- And there are no payload revision conflicts
Pro Tip: FIltering by “Type” being Kiosk or Standard is a great way of isolating like elements for combining associations into deployments.
Should I create one, or multiple Deployments?
What
We have established in the previous article that you can combine any payloads or destinations into the same deployment if all of the metadata would be the same. For example, I want to deploy Firefox and Chrome to the IT and HR departments starting on Friday at 6 PM. Everything matches, so I can put them in the same deployment…but, should I?
When/Why
We’ll want to very carefully think about how we intend to organize our deployments, and how we’ll want to modify them in future before we can answer the above question.
How
But the answer to the question is “it depends”. It depends on what is easiest for you, the FileWave administrator. Primarily you’ll want to organize deployments based on the payload(s), or based on the destination(s), but not both at the same time. Other key differentiators are going to be the method of delivery (i.e. push vs. pull) and the platform.
An example (always) works best:
Let’s consider the following table of overall payloads/destinations…
Payload (Filesets) | Destination (Devices) |
Google Chrome - PC (Push) | All Windows Devices |
Google Chrome - macOS (Push) | All macOS Devices |
Firefox - PC (Kiosk) | All WIndows Devices |
Firefox - macOS (Kiosk) | All macOS Devices |
Adobe Acrobat Reader - PC (Push) | All Windows Devices |
Adobe Acrobat Reader - macOS (Push) | All macOS Devices |
TeamViewer Host - PC (Push) | All Windows Devices |
TeamViewer Host - macOS (Push) | All macOS Devices |
So, how would we best create as few deployments as possible?
- We’d likely combine Adobe Acrobat Reader, Chrome, and TeamViewer Host into TWO common deployments, split by platform, and we might call them something like this:
- Standard Apps PC (Push)
- Standard Apps Mac (Push)
- And for Firefox, we would also create two deployments (again because we don’t want to mix platforms), and we’d probably name them something like this:
- Optional Apps PC (Kiosk)
- Optional Apps Mac (Kiosk)
And we arranged them in that way because now we have some excellent base building blocks for adding other apps if the destinations are the same (i.e. the All groups). For instance, if we added a new installer, say MSFT Teams, then we can easily simply add it to the proper deployments, and it would be available to all of the same devices with the same options.
The FileWave Associations-to-Deployment Conversion Tool
What
We’ve covered in other articles what types of content we might put together in a singular deployment, and we’ve discussed best practices for deployments in general. But some of you may be asking: “I have 1000 associations currently, is there a way for me to convert those into deployments instead?”. And the answer, thankfully, is “Yes!”.
When/Why
You'll use the web admin Associations conversion tool whenever you want to convert previously built associations into deployments:
How
Conversion of associations is quite simple…if metadata matches, then you can simply add the associations to an existing (or new) deployment, choose to preview and save. A simple example is shown below:
If metadata does not match, for instance if the timing options, or installation type are different, you’ll need to resolve conflicts to save the deployment. That topic is included in the below linked document.
Remember: Conversion of association(s) REPLACES them with a deployment. Always test and convert slowly to ensure you get the behavior you expect.
Resolving Conflicts in Associations Conversion
What
The guidance we have given in other articles is about making sure metadata matches when converting associations. But sometimes, we need to convert items that don’t match in order to “fix” them. This article covers how “conflicts” are handled within conversion.
When/Why
We’ll use the conflict resolution tool to resolve conflicts, and to preview the impact of those conflict resolutions before save to ensure we make the changes we intend. The most likely conflicts are:
- changing from Kiosk to Standard deployment (or vice versa)
- having more than one target (not technically a conflict, but important to understand)
- differences in timing options
- differing payload revisions
How
Resolving the conflicts is quite straightforward. Examples are shown below, with corresponding previews that show the changes:
Conflict Type | |
Conflicting Installation Type |
Note that you have to choose which installation type you want to have before you can preview |
And the preview shows you which association changed, and how it changed |
|
Mixing targets and/or payloads |
Technically this is not a conflict, as mixing two targets that have differing payloads simply means all payloads will be installed on all targets, so there is nothing to “resolve”. (I.e. If we combined one association of IT/Firefox with HR/Chrome, then all devices will get both Firefox and Chrome) Notice though that in preview, we see the “added” payloads to the corresponding groups. |
Differences in Timing |
Note that timing option changes will show in preview too. |
Differing Payload (Fileset) Revisions |
In preview then, you will see the changed revision. |
Digging Deeper
Important note: If there are timing options in the past with regard to file deletion, those “associations” will automatically become exclusions in the new deployment. You’ll see exclusions identified as an icon with a slash through it.
Some additional notes regarding the preview view:
- You can have a lot of records in this view depending on the scope of changes, you can scroll through to review
- NO changes are made until PUBLISH is chosen from the preview page
- You can cancel a conversion at any point before choosing “Publish” and no changes will be made whatsoever
- There can be 4 types of changes:
- No change at all
- Modification of one element (i.e. timing)
- Addition of an element (i.e. a payload is going to something it wasn’t going to before)
- Deletion of an element (i.e. a payload is no longer going to something that it did prior)
Explanation of Clones with Deployments
What
Clones are a theoretical concept in FileWave. A clone represents a symbolic link to an actual device/device group. This article covers how clones are treated differently in deployments compared to how they are handled in associations.
When/Why
Sometimes clones are either purposefully chosen for an association, or just chosen for convenience sake by an admin. Regardless of the “why” behind this, the result is the same…the payload(s) end up assigned to the device or the device group in the real world.
How
But there is a difference in the way Deployments handle clones compared to Associations. Basically, Associations use the actual clone (i.e. they reference directly the id of the clone itself), but Deployments convert the “clone” into the id of the original object…be it a device or a device group. This conversion in deployments simplifies the content assignment, and makes more logical sense.
This conversion can theoretically have an impact though when converting associations that use clones. The link being changed to the original device/device group may change the formula of the “winning” association…so we suggest you convert this type of association slowly to gauge any potential impact in your environment.
Reference the View - Deployments articles to see how one creates a deployment from scratch, but in the below articles you’ll also see how to use our Associations to Deployments Conversion Tool to create deployments from multiple associations and also look at the benefits of Deployments overall.
Deployments in FileWave Central (v15+)
What
FileWave Deployments (the next generation of Associations) are now fully implemented in FileWave Central for creation, edit and deletion.
When/Why
We’ll use a FileWave Deployment to assign content to devices, Deployments are like associations, except the metadata (rules about assignment) are stored within the deployment. This makes it very easy to add yet another app to a deployment, and have it automatically have the same settings as others (available via Kiosk automatically as an example).
How
Deployments work almost identically in FIleWave Central to how they do in FileWave Anywhere, so you might want to check out those detailed articles linked below. Deployments have three steps. Step 1 allows you to Target and Exclude devices…Step 1 defines who gets “the stuff”:
Step 2 allows you to define “the stuff” that the Targets (devices) get:
And Step 3 allows you to set options for the Deployment. In this case, we’ll publish these filesets to the kiosk:
Once created, deployments are stored by name, and can be edited to add other content/devices.
Fileset Tools
Along with all of the editing and modification capabilities you have with Filesets, there is also a basic set of tools that you can use to make simple changes. These tools support some of the most common tasks you will need to perform as you manage large collections of Clients and Filesets. The Tools are found by selecting the icon in the main toolbar, or right-clicking on any Fileset.
- Duplicate – You can take a fully-configured Fileset and create an exact Clone with the suffix "copy." This should be done whenever you want to assign a Fileset to more than one administrator for different deployment options, or when using VPP tokens that require different licenses assigned to the same content.
- Show all Associations of this Fileset – This will take you to the Associations pane where you can view the Fileset and its assigned Clients.
- Create Association – This brings up a searchable list of Clients to associate with the Fileset.
- Rename – This allows you to change the name of the Fileset after it has been created.
- Comment – This allows you to add a comment that will show in the Fileset view to assist you in managing and keeping track of your Filesets.
- Delete – This deletes the selected Fileset from the database.
- Set Permissions – This allows you to specify the access level of your administrators to a given Fileset or Fileset Group.
Fileset (Payload) Status in Inventory
What
It has long been possible to compile "FileSet Reports" in the FileSet view within the FileWave admin, but it was not possible previously to create Inventory Queries (Reports) using the same info. With FileWave 14.5+, this issue is resolved, and more traditional reports can now be created in the Native and WebAdmin consoles.
When/Why
We'll want to use these new inventory fields whenever we want to report on deployment status. For instance, a report can be used to feed data to the integrated Grafana dashboard, or we may simply want a report of only Office 365 failures.
How
For any new report, you can utilize the data elements shown below for "Fileset deployment status". In the example shown, we are specifically choosing to look at all failures generally, but this report could also be fileset/payload specific of course.
And the report itself:
Fileset Reports
When you select a Fileset, Filesets, or Fileset Group, you can select the Report toolbar button to see the status of the selected item(s).
The report will show the Clients that have been associated with the Fileset, the version of the Fileset that is present on the client, its status as to whether it has been installed or is available, and the date-time group of when the Client reported the Fileset as active. The report can be exported in CSV format. If the Fileset includes an installer, such as a .pkg or .msi Fileset, you can review the installer log for that installation. You can also select the Client and force a re-install of the Fileset.
Custom MSI installer parameters
What
Starting with FileWave 15.2.0 it is now possible to add custom parameters to MSI Filesets. This includes Filesets created by MSI files, but not Filesets automatically created based on Windows software updates.
When/Why
Some MSI installers accept custom parameters that will change the way software is installed. For example, many MSI installers allow the software installation path to be defined via an additional option at runtime. Two such examples are:
Application | Instal Path |
UltraEdit | TARGETDIR="<my-desired.path>" |
7Zip |
INSTALLDIR="<my-desired.path>" |
Typically through FileWave, it may feel necessary to set a silent option, however, FileWave already ensures all MSI are silent.
How
These MSI parameters may be set in two ways.
FileWave Central
Through the newly included Fileset property items:
- "Custom MSI install options"
- "Custom MSI uninstall options"
FileWave Anywhere
Through the newly included Payload Settings:
- "Custom MSI install options"
- "Custom MSI uninstall options"
Multiple Options
Multiple options may be specified at the same time and should be separated by spaces.
For example, to instal TeamViewer Host with multiple properties, this could be achieved with the following: SETTINGSFILE="YOURPATH\yourfilename.tvopt" APITOKEN=xxxxxx CUSTOMCONFIGID=xxxxxx
Parameters
Parameters may be used to define options, including Custom Fields.
Example
For TeamViewer Host, it may be desirable to hide the APITOKEN, but it needs to be supplied to the MSI at installation runtime. As such, a Custom Field could be used to define the value for the APITOKEN.
The Custom MSI Instal Options could then be:
APITOKEN=%teamviewer_api_token%
Note though, parameters may only include properties e.g. SETTINGSFILE, APITOKEN,CUSTOMCONFIGD
The Custom MSI settings may be used to define settings that start with a leading / or special parameters, e.g. ALLUSERS. However, when using Parameters, options specified with a leading / or special parameters like ALLUSERS, will automatically be removed from the options to prevent seemingly hidden settings which could, for example, force a reboot.
In both FileWave Central and Anywhere there are also "Learn More" links directing to this page.
Information
Option definitions:
Custom MSI install options | Options passed to the MSI during Fileset Activation |
Custom MSI uninstall options |
Options passed to the MSI when the Fileset is disassociated. Requires 'Use MSI Uninstaller' to be enabled and that the MSI uninstaller supports this option. (Firefox is an example of an MSI that does not support this feature) |
Related Content
- 7zip (Windows MSI) - Using a custom parameter to install 7zip on Windows
How to Enter Launch Arguments for Windows Setup.exe Installers
When deploying Windows applications using their native installers, command line parameters must typically be passed as launch arguments to the installer executable for a silent installation. If an MSI installer is available it's best to use that to deploy your application because 1) no launch arguments are needed and 2) MSI filesets can be rolled back silently in FileWave should you ever need to uninstall that application.
Legacy Windows installers have traditionally been distributed as a Setup.exe or AppInstaller.exe, which can be deployed silently with command line parameters like /s, /silent, /q, or /quiet. Once you have worked out the correct command line parameters for your installer in a CMD window, click Get Info for the main installer executable, pick the Executable tab, and check Execute once when activated. In the Launch Arguments tab click the plus sign in the lower left to add launch arguments.
Follow this general rule for entering launch arguments - each item after the installer executable name separated by a space needs to be entered as a separate launch argument. In the example below, there are 4 launch arguments.
AppInstaller.exe /s /name=MyOrg /reg ABC123
Count |
Argument |
1 |
/s |
2 |
/name=MyOrg |
3 |
/reg |
4 |
ABC123 |
If there are spaces in a command line parameter it must typically be surrounded by quotes. Note that spaces in a command line parameter may result in a single command line parameter needing to be entered as multiple launch arguments in FileWave. In the example below, there are 8 launch arguments.
AppInstaller.exe /s /name="My Org" /reg ABC123 /l "c:\windows\temp\My App\install.log"
Count |
Argument |
1 |
/s |
2 |
/name="My |
3 |
Org" |
4 |
/reg |
5 |
ABC123 |
6 |
/l |
7 |
"c:\windows\temp\My |
8 |
App\install.log" |
Once you understand the general rules for how to add launch arguments you'll be able to easily take advantage of your existing native installers to deploy Windows applications silently to client PCs.
How to Force a Reboot of macOS or Windows Devices after Installing a Fileset in FileWave v14.10+
What
The Force Reboot feature is a new functionality that is available in FileWave v14.10.0. This feature enables you to force a macOS or Windows device to reboot after installing a Fileset. This feature is helpful in situations where quick and immediate installation of patches is required.
When/Why
The Force Reboot feature in FileWave v14.10.0 should be used when you need to ensure that your environment is patched quickly. This feature is especially useful in situations where there is a need for immediate installation of patches such as Microsoft or Apple OS patching. This feature is available in the properties screen of a Fileset and can be enabled by checking the relevant Force reboot box as seen below.
How
To enable the Force Reboot feature in FileWave v14.10.0, you need to follow the below steps:
- Highlight the Fileset that you want to enable the Force Reboot feature.
- Select Properties.
- Check the "Force reboot" box to enable the feature.
- Save the changes made.
Please note that enabling this feature will result in the device rebooting 2 minutes after the installation of the Fileset. Therefore, it is essential to test the user experience before using this feature.
Related Content
Fileset Magic
Merge updates to a fileset with Fileset Magic
Summary
This knowledge base article describes the steps to use fileset merge feature in Fileset Magic to merge an update directly to the existing fileset. An example of when this might be useful is when you need to deploy a software update for a software package that is currently controlled by FileWave. Deploying software updates to client machines using pkg fileset can cause the changes to revert back if the software fileset files are set to self-heal.
Procedure
First, you need to have a machine with the original (non-updated) software installed on it and run the first snapshot.
Second, run an update and make sure the software is up to date. Now a second snapshot will capture the changes, usually, the comparison
view displays added, modified, and deleted files (modified and deleted are not checked by default). Check all modified files
(keep added files checked) and instead of saving the fileset, click the Merge button and choose the fileset you want to merge
the changes to.
Steps
- Make sure you backup your fileset (right click on a fileset and duplicate).
- Take the first snapshot.
- Install your update and run your application.
- Take a second snapshot
- In the comparison view, browser your changes and check all modified files and click Continue
- Check "Merge To Fileset" and click the button "Choose" (fig2)
- Select your fileset ( use the duplicate fileset ) and click "OK"
- Verify that your changes are merged to the fileset.
- Test your fileset.
Fileset Revisions
Fileset Revisions Overview
What
Fileset (payload) revisions allow you maintain two (or more) different versions of the same fileset within one FileWave fileset object.
When/Why
The above description might not knock your socks off, but we are pretty excited about this, and think you will be too! Consider this scenario:
We are currently deploying Firefox (v79) to all of the devices in the environment. But v80 of Firefox is now out, and we want to upgrade. Previously we had to either duplicate the FileWave fileset and change the content of it, or create a brand new fileset from scratch. Then, when we had to remove the association for v79 from our test devices and add a new association for v80. And, assuming all was good, we then had to remove the old association for all devices, and replace it with the new one. Finally, if we were worried about the possible interruption of service by removal of the old app, we might have had to play a bit of a shell game with the timing to make sure customers weren't impacted by the upgrade.
Not anymore!
How
Fileset revisions allow you put version 80 of Firefox in the very same fileset in which you had v79. Then, rather than removing associations, you would just change the revision the association uses. And, we take care all of that complicated fileset timing stuff for you. In subsequent articles (linked below), we'll go into all of the specifics, but here is a sneak preview of setting a revision in an association:
You may be thinking to yourself: "This sounds complicated, and I don't want to use revisions." There are two responses: First, you absolutely don't have to use them if you don't want to. If you choose to ignore revisions, then everything will continue to work exactly the way it has for you in the past. Rest assured though, Fileset revisions aren't actually complicated, and you may find they really make things easier for you.
Related Content
Associating a Fileset Revision
What
When you attempt to associate a fileset that has revisions, you'll notice a slightly different workflow, where you are asked to select a revision to associate. (Associating a fileset that has no revisions functions as it always has)
When/Why
Assume our same Firefox fileset, containing two revisions for v79 and v80. When we create a new association for this fileset, we need to tell the system which revision (v79 or v80) that we want to use.
How
Selecting the revision we want to do is very simple, since the FileWave admin just asks us which one we want to use as you'll see below:
You may ask yourself, "What is the 'default' option I see in that menu?" That is a great question and we'll talk about that super-helpful option in another article you'll find linked below.
- "Default" Revisions
- Associating a Fileset Revision
- Editing Filesets that have Revisions
- Managing Revisions
Editing Filesets that have Revisions
What
Of course from time to time you want to edit your pre-existing filesets. How does editing a fileset change if you have multiple revisions?
When/Why
Assume again that we have a Firefox fileset that has two revisions...one v79 and the other v80. Assume that we want to change a file in the v80 fileset, or even change a file in both. How do we know which fileset revision we are changing?
How
In both the fileset editor and the script editor you will now see a new drop down menu that allows you to identify which revision of the fileset you are working on. See below, where we are looking at v79 in the fileset window, and v80 in the script editor:
Switching which fileset you are editing in either window is as simple as changing the value in the drop-down. And, if you just want to do filesets the same way you always have, you can safely ignore that drop-down altogether.
Related Content
Managing Revisions
What
There are quite a number of things we can do to "manage" revisions. We can create new revisions, edit them, delete them, and set default revisions.
When/Why
Our management options breakdown as follows:
- Editing revisions (different from editing the contents of the revision) allows us to change the names and descriptions of revisions
- Creating them allows us to create additional revisions in the current fileset
- Deleting a revision, as the name implies, allows us to remove a revision from a fileset
- Setting a revision as the "Default" allows us to easily deal with associations for testing and production in different ways
How
The thing that all of the options listed above have in common is they are all accessed in the same way, through the "Manage Revisions" button in the Fileset Editor, the Script Editor, or the Fileset Properties window, as shown below:
Each of the management options is detailed in the articles linked below.
Related Content
"Default" Revisions
What
What are default revisions? An excellent question indeed. Default revisions are a way of marking a specific revision of a Fileset as the "default", regardless of what it is called. Keep reading, and you'll see how very useful this is, and how our great developers try to make your job easier on an everyday basis.
When/Why
We are going to use our example again of v79 and v80 of Mozilla Firefox. Assume for a moment that we have v79 assigned to all devices right now in two associations as shown below:.:
If you'll look closely, you'll see that the "Production" group has an association to the revision <default> (v79) and the "Beta Testers" group is associated to v79. Effectively, this is exactly the same for both groups...v79 is installed. But, let's take a look below at what happens when we want to upgrade to v80 in the environment.
How
We aren't just going to assign v80 to all devices right away...as always, we want to test first, so with our patch testers group we'll edit their association as follows:
Once we save this association and update the model, all patch testers will get the new version. No deleting of the association or creating a new one is required.
Now, assume that all testing goes well, and we are ready to release to production. Now, we could edit the association for "production", but assume for a second that we had ten such associations...would we want to edit all ten of them? In a word, no. But, if you remember, the association above to production was not v79, but rather Default v79...which means the association is just to the "default" revision of the fileset.
So, we can simply edit the properties of the fileset itself and change the "default" to v80 instead.
Once we save that change, and update the model, you'll see the change reflected in the association:
And, upon next check-in, all "Production" devices will upgrade to v80.
Remember, we take care of the timing of this transition between versions...so you don't have to worry about the transition timing.
Related Content
- Managing Revisions
- "Default" Revisions
- Creating a New Revision
- Editing Fileset Revisions
- Removing/Deleting a Revision
Creating a New Revision
What
Creating a new fileset is the same as it always has been, but in some way, shape or fashion we need the ability to create new fileset revisions before we can use them.
When/Why
Typically, we'll want to use fileset revisions whenever we expect to continually upgrade an application...so, in most cases basically. In this case, we'll look at how to create a v81 revision of Firefox.
How
Adding a new revision is done from the "Manage Revisions" view by clicking the plus icon:
Note that in this case, we chose "Empty" because we don't want the files from the previous revision. But, if we had custom scripts or anything else like that, we would probably duplicate the previous revision instead. Once the revision is created, you edit it like you would any fileset.
When creating a new revision, you can create it as empty, duplicate an earlier revision entirely, or duplicate only the properties of that revision:
Fileset Revisions can also be created by drag and drop operation from the file system onto an existing Fileset. You'll be prompted about making a new Fileset, or adding a revision as shown:
If adding a revision, you will also be prompted about setting the default revision:
Related Content
- Managing Revisions
- "Default" Revisions
- Creating a New Revision
- Editing Fileset Revisions
- Removing/Deleting a Revision
Editing Fileset Revisions
What
Revisions themselves have some properties that can be edited: namely the name and the description of the revision.
When/Why
Editing the properties of a revision is also done from the "Manage Revisions" window...we'll use it if we want to edit the name. For instance, every time the first revision is created, it is called "Initial Revision"...which is helpful to know, but not very descriptive. Below is how we change that.
How
First, we'll go into the "Manage Revisions" view for a particular fileset, then choose "Edit" with a revision selected:
There are only two fields to set, but setting them descriptively does help later when creating associations.
Related Content
- Managing Revisions
- "Default" Revisions
- Creating a New Revision
- Editing Fileset Revisions
- Removing/Deleting a Revision
Removing/Deleting a Revision
Removing/Deleting a Revision (v14+)
What
We can create revisions, so of course we want to be able to delete them as well.
When/Why
We'll usually want to delete revisions whenever the revision is no longer pertinent. We would probably always leave the N-1 version of our fileset, but if we have older revisions, we would certainly want to clean up to save on disk space.
How
If we go into the "Manage Revisions" view, we can select a revision and hit the minus sign to remove it. If no associations exist for that revision, we'll simply get a prompt to confirm:
But, if there is an association, we can choose to remove the association outright, or switch it to another revision:
Related Content
- Managing Revisions
- "Default" Revisions
- Creating a New Revision
- Editing Fileset Revisions
- Removing/Deleting a Revision
Troubleshooting
Intelligent downloader explained
Summary
This KB article will explain the intelligent downloader and give the best practices to upgrade your self-healed software by benefiting from this feature through Filesets / Payloads.
Intelligent Downloader
When a Fileset / Payload is deployed and the time to download has come, the FileWave Client will check for existing exact copies of the Fileset files before it starts the download.
The match is met only if:
- The file exists with the same name.
- The file size matches.
- The file CRC matches.
The client will skip downloading all files that match existing copies on the disk.
The Client will also skip the download in two other cases:
- The Fileset files are set to never overwrite when the Fileset property "Don't overwrite existing files upon deployment" is checked.
- The files creation date is newer than the ones in the server and this Fileset property is checked "Overwrite only if existing file is older".
Note: Symlinks will always be replaced.
Upgrading your Software
There are two scenarios to best upgrade your self-healed software (we assume Fileset v1 is active on the clients)
- Create the association to Fileset v2, delete the association to Fileset v1 and update the model. (this will start the upgrade immediately)
- Create the association to Fileset v2 and set it to activate at some time in the future eg: 06:00PM and then make the Fileset v1 to Delete at 06:01pm (some time after v2 has activated)
Note: If you set the delete time of v1 before activating v2, you end up deleting files that are needed to activate v2 and the missing files will download at verification. So, to best benefit from the intelligent downloader, it is better to go for 2. knowing that deleting Fileset v1 at 06:01PM will not delete common files with v2.
Fileset Status meanings
Fileset Inventory Status
In the stable below are the Fileset status codes that can occur in FileWave and some steps to reproduce some of them.
Code |
Status Type |
Severity |
Fileset Status (Client Info) |
Deployment Status |
Available Platform(s) |
Steps to Reproduce |
0 |
UNKNOWN_ERROR |
WARNING |
Fileset Error |
WARNING |
||
1 |
STATUS_IDLE |
OK |
Idle |
REMAINING |
N/A |
|
2 |
STATUS_FILESET_DOWNLOADING |
ACTIVITY |
Downloading: #% |
REMAINING |
||
3 |
STATUS_FILESET_DOWNLOADED |
OK |
Downloaded |
REMAINING |
||
4 |
STATUS_FILESET_ACTIVATED |
OK |
Installed as dependency Installed via Kiosk Active |
COMPLETED |
macOS Windows |
|
5 |
STATUS_FILESET_MADE_PASSIVE |
OK |
Passive |
COMPLETED |
|
|
6 |
STATUS_FILESET_DELETED |
OK |
Deleted |
COMPLETED |
iOS |
Easiest to see with iOS
|
7 |
STATUS_FILESET_INSTALLED_SUCCESSFULLY |
OK |
Installed successfully |
COMPLETED |
iOS |
|
8 |
STATUS_FILESET_INSTALL_FAILURE |
WARNING |
Install failed |
ERROR |
||
9 |
STATUS_FILESET_DISK_FULL |
WARNING |
Disk full |
ERROR |
|
|
10 |
STATUS_FILESET_INSTALLER_RUNNING |
ACTIVITY |
Installer running now |
REMAINING |
||
11 |
STATUS_FILESET_ERROR |
WARNING |
iOS: Please log in to your iTunes Store account Desktop: Error: 4 |
ERROR |
Now only see "Error: 4" if setting last_status for fileset to 11 manually in admin.user_status table
Steps (iOS)...
|
|
13 |
CANT_LOAD_DATA_FILE_FROM_SERVER_ERROR |
WARNING |
Error while downloading from server |
WARNING |
Note: Only have seen 'Fileset Error' |
|
14 |
STATUS_FILESET_ASSOCIATED |
IGNORE |
Associated |
REMAINING |
macOS Windows Android iOS |
|
15 |
BOOSTER_SERVER_DISK_FULL_STATUS |
ERROR |
Booster/Server disk full |
ERROR |
||
16 |
STATUS_FILESET_INSTALLATION_CANCELLED |
WARNING |
Installation cancelled by the user |
COMPLETED |
Android |
Easiest to see with Android
|
17 |
STATUS_FILESET_INSTALLER_OUTDATED |
WARNING |
Fileset install failed, a more recent version is installed |
ERROR |
||
18 |
STATUS_FILESET_UNINSTALLER_RUNNING |
ACTIVITY |
Uninstaller running now |
REMAINING |
||
19 |
STATUS_FILESET_UNINSTALL_FAILURE |
WARNING |
Uninstall failed |
WARNING |
||
21 |
ACTIVATING_STATUS |
ACTIVITY |
Activating |
REMAINING |
||
22 |
STATUS_FILESET_SCRIPT_FAILED |
WARNING |
Script execution failure |
ERROR |
||
23 |
STATUS_INVENTORY_ONLY_CLIENT |
WARNING |
Not installed: client is inventory only |
COMPLETED |
||
25 |
STATUS_IN_KIOSK_UNINSTALLED |
OK |
Excluded from Kiosk (Dependency) Available in Kiosk |
COMPLETED |
macOS Windows |
|
-52 |
PLEASE_REBOOT_RESULT |
ACTIVITY |
Waiting for user to log out |
REMAINING |
macOS Windows |
|
-51 |
FAILED_TO_LOGOUT_RESULT |
ACTIVITY |
Waiting for user to log out |
REMAINING |
macOS Windows |
|
-50 |
WAITING_FOR_USER_TO_LOGIN_RESULT |
ACTIVITY |
Waiting for user to log in |
REMAINING |
macOS Windows |
|
99 |
FILESET_PRIORITY_ERROR |
ACTIVITY |
Waiting for higher priority filesets |
REMAINING |
|
|
98 |
FILESET_REQUIREMENTS_ARCH_ERROR |
INFO |
Requirements not met: architecture |
COMPLETED |
|
|
97 |
FILESET_REQUIREMENTS_VERSION_ERROR |
INFO |
Requirements not met: system version |
COMPLETED |
|
|
96 |
FILESET_REQUIREMENTS_MEMORY_ERROR |
INFO |
Requirements not met: insufficient memory |
COMPLETED |
|
|
95 |
FILESET_REQUIREMENTS_SCRIPT_ERROR |
INFO |
Requirements not met: script |
COMPLETED |
|
|
666 |
FILESET_REMOTE_WIPE_EXECUTED |
ACTIVITY |
Remote wipe executed |
REMAINING |
||
-5 |
WAITING_FOR_BOOSTER_RESULT |
ACTIVITY |
Waiting for booster |
REMAINING |
||
-32 |
NETWORK_GENERIC_ERROR |
WARNING |
Network error |
ERROR |
||
-149 |
FAILED_CRC_CHECK_ERROR |
ERROR |
Failed CRC validation |
ERROR |
||
101 |
MAC_APP_STORE_FATAL_ERROR |
WARNING |
Mac App Store license fatal error |
ERROR |
||
102 |
MAC_APP_STORE_LICENSE_ASSOCIATED |
IGNORE |
Mac App Store license associated |
REMAINING |
||
103 |
MAC_APP_STORE_NOT_ENOUGH_LICENSES |
WARNING |
Not enough Mac App Store VPP license |
WARNING |
||
104 |
MAC_APP_STORE_VPP_USER_NOT_ASSOCIATED |
WARNING |
User needs to accept the invite to the organization with a valid iTunes account |
REMAINING |
||
105 |
MAC_APP_STORE_NO_LICENSE_NEEDED |
WARNING |
No VPP license associated to this fileset |
REMAINING |
||
106 |
MAC_APP_STORE_NO_VPP_USER |
WARNING |
No VPP user for this application's VPP token associated to the device |
WARNING |
||
107 |
MAC_APP_STORE_VPP_USER_RETIRED |
WARNING |
VPP user is retired |
WARNING |
||
108 |
MAC_APP_STORE_NO_VPP_TOKEN |
WARNING |
No VPP token associated to this fileset |
WARNING |
||
109 |
MAC_APP_STORE_INSTALLED |
OK |
Installed via Mac App Store |
COMPLETED |
||
110 |
MAC_APP_STORE_INSTALLING |
ACTIVITY |
Installing via Mac App Store (can take some time) |
REMAINING |
||
111 |
MAC_APP_STORE_ASSET_NO_DEVICE_ASSIGNABLE |
WARNING |
VPP license for asset can not be assigned to a device |
WARNING |
||
112 |
MAC_APP_STORE_NOT_VPP_APP |
WARNING |
Not a VPP application Fileset Error |
WARNING |
Note: Only have seen 'Fileset Error' |
|
130 |
DEPENDENCIES_DOWNLOAD_FAILED |
WARNING |
Download of dependency fileset failure |
ERROR |
|
|
131 |
DEPENDENCIES_ACTIVATION_FAILED |
WARNING |
Activation of dependency fileset failure |
ERROR |
||
132 |
DEPENDENCIES_PASSIVE_FAILED |
WARNING |
Failed to make dependencies passive |
WARNING |
Note: Only have seen 'Fileset Error' |
|
133 |
DEPENDENCIES_DELETE_FAILED |
WARNING |
Failed to delete dependencies |
WARNING |
Note: Only have seen 'Fileset Error' |
|
134 |
DEPENDENCIES_UPDATE_FAILED |
WARNING |
Update of dependency fileset failure |
ERROR |
||
135 |
DEPENDENCIES_LOGOUT_FAILED |
ACTIVITY |
Waiting for user to log out to install dependency |
REMAINING |
||
136 |
DEPENDENCIES_FAILED |
WARNING |
Dependency fileset failed |
WARNING |
||
210 |
FILESET_REQUIREMENTS_OK_SKIP_INSTALL |
OK |
Skipped |
COMPLETED |
||
220 |
FILESET_REQUIREMENTS_ERROR_STOP_TRYING |
INFO |
Requirements not met: will not retry |
COMPLETED |
||
1024 |
CHECK_REQUIREMENTS_OK |
ACTIVITY |
Requirements met |
REMAINING |
||
2048 |
STATUS_FILESET_INSTALLED_BY_PROFILES_COMMAND |
OK |
Installed |
COMPLETED |
||
2049 |
STATUS_FILESET_INSTALLED_BY_MDM_SERVER |
OK |
Handled via MDM |
COMPLETED |
||
2050 |
STATUS_FILESET_FAILED_TO_INSTALL_BY_PROFILES_COMMAND |
ERROR |
Profile Installation Failure |
ERROR |
Uninstalling Filesets
Uninstalling Filesets
Creating installation Filesets is one of the key aspects to FileWave device management, yet, a somewhat overlooked topic is uninstalling Filesets.
This KB will aim to highlight some considerations in the differing ways this could be approached.
Mobile Devices
iOS and Android devices are in the main more simplistic. App Store Apps come from the vendor store. On disassociation, the relevant app is deleted from the device; likewise for configurations. However, there are some additional considerations.
App data is often stored within the App itself. Unless the App is designed or configured to use cloud based storage, removal of the App will also delete the users App data.
Where configurations are concerned, in the main, very little need be considered, but some Filesets may be integral. If the configuration provides, for example, network connection (by way of a network payload, certificate, VPN, etc), then on removal of that configuration, network connection will also be lost.
Computer Devices
Computer installers can be supplied in multiple methods, including PKG, MSI, EXE, standard file-level Filesets, scripts and registry entries. As such, the topic of uninstalling is somewhat larger.
Ideally, developers will supply some kind of uninstaller, be that another PKG, MSI or EXE or a supplied script. However, this is often not the case.
Generic Filesets
Where Filesets are set to deliver files with installers, self-healing can therefore supply the necessary requirements to ensure files are removed on disassociation. Note though, that during use, applications may create additional files throughout the file system. For a complete removal, if the developer of the App does not supply a pre-configured uninstaller, then these files would need to be identified and also removed.
Note, just because a vendor has provided an uninstaller, does not necessarily mean it is a full uninstaller and some files may still be left behind.
FileWave has a couple of ways that these could be dealt with, once identified.
Script
A script could be created to run removal commands against each of these files or folders
Fileset Files
An additional Fileset could be built to include these extra files and would be set as download if missing. Download if missing does not overwrite files if they exist (even if they differ), but will remove files on dissociation.
Windows
MSI, EXE and registry.
MSI have the potential to removal files based upon the MSI identifier. MSI specific Filesets may use the tick box in the Fileset properties to trigger the uninstaller when disassociated; 'Use MSI uninstaller'.
It is possible to create non-MSI Filesets, e.g create a standard Fileset, add the MSI as file and then use a script to instal the MSI. In this case, the Fileset is unaware of the MSI and as such this method would not work.
EXE on the other hand, do not have such an option. Again, if not developer supplied, one of the above generic methods would need to be considered.
Likewise, registry entries would require a method for removal if required, during a disassociation of the Fileset.
macOS
PKG installers have no built-in uninstaller. In some instances, vendors will supply an uninstaller, but all of the considerations mentioned in the generic section would need to be considered.
How to Uninstall
Not so much how, but when.
Many example recipes provide an uninstaller within the Fileset. As such, if the Fileset is disassociated, the uninstaller will trigger. However, this may not be ideal.
For example.
Problem
Imagine you have a self-healing Fileset for the new imaginary web app, EyeBrowse version 1.0. Let's assume, that this adds additional files in the user environment when ran. The following might be actioned:
- Identify additional files
- Script the removal
- Add an uninstaller script within the same Fileset
Now consider the release of version 1.2.
- Create a new Fileset, revision or duplicate the original
- Edit this Fileset for the version 1.2
When transitioning between these two versions, the original Fileset should become disassociated. However, when this occurs, the uninstaller script will run, removing the identified, user specific files. This is likely to be an unwanted outcome, since the user is still using the software, the intention is for them to have a newer version.
Resolution
What would be better is to create a Fileset Group. The group would require:
- The EyeBrowse App Fileset (holding just the installer and any configuration)
- The additional user data removal uninstaller Fileset
- The Fileset Group is associated to devices ('EyeBrowse Associated')
With the above configuration, when changing between version 1.0 to 1.2 of the App, the EyeBrowse App Fileset would be swapped out of the Fileset group or the revision altered. If the App and all associated files needed to be completely removed, at this point the Fileset Group would be disassociated, which in turn would also cause the uninstaller script to run, from the additional, contained Fileset.
When downloading recipe Filesets with uninstaller included, consider if it is desirable to separate the installer from this Fileset. If so, consider duplicating the supplied Fileset, placing both into one Fileset Group, and removing the installer from one and the uninstaller from the other.
In some instances, it may be desirable to run the uninstaller on each new update, providing a clean instance. Each Fileset should be considered in its own right.
Updating Uninstallers
Installers are forever changing, with point and major releases being offered frequently. This may of course mean Uninstallers also require updating. For vendor supplied ones, check for newer supplied versions, but for self built methods, these should be checked and updated if need be.
Some installers can be downloaded and actioned all in one process. Brew has an example of this:
https://github.com/homebrew/install#uninstall-homebrew
For example:
NONINTERACTIVE=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"
As such, an uninstaller Fileset script could be created, which, in theory, could just include this line.
This is both advantageous and also troublesome.
Pros
The uninstaller actioned will aways be the latest version
Cons
If the version currently installed is not the latest version, but one or move versions older, the script may no longer be appropriate
Consideration
If the uninstaller is downloaded at the same time as the installer, then the two should align. A Fileset uninstaller script could be built to contain the contents of this script and as such, should be the correct uninstaller for the active Fileset. With each update, the uninstaller could also be compared.
Note, there could still be extra checks. Since FileWave runs as 'System' on Windows and 'root' on macOS, any vendor supplied script should be checked for user specific paths and how these paths are addressed, for example.