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

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:

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

Post-Association

These settings are covered in detail in the next section on Associations.

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.

Desktop Filesets

Desktop / laptops Filesets are designed for use on macOS and Windows computers. The Fileset types are shown below:

App / Folder Fileset

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 Fileset

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/sh
# 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 Cient. 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 (FW 10+)

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

Import Fileset

The Import Fileset is actually a dialog that allows you to import a previously created Fileset.

MSI / PKG Fileset

The one Fileset that does not store its contents as individual files is the MSI / PKG Fileset. For this Fileset, you select a downloaded installer for either Windows (.msi) or macOS (.pkg and .mpkg). When the Fileset is deployed to the Client, upon activation it will run as an installer with local administrator privileges.

Note: Under FileWave 10+, 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 is as follows:

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.

Software Update Fileset

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.

Profile Fileset

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.
Details on creating and configuring Profile Filesets are in Chapter 7.

App Store Fileset

You can create Filesets for macOS 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 v10, you will 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.

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.

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 ran 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.

 

Mobile Filesets

For your mobile devices, the selection of possible Filesets is much smaller.

App Store Fileset

The App Store Fileset was designed around the BYOD or 1:1 deployment models with iOS devices. This Fileset can be used for two types of distributions - ad hoc or VPP. In an ad hoc distribution, you are sending a link to the application or eBook to the end user. This can be done either directly or by using the Kiosk. The user will then be required to enter his or her Apple ID to purchase and install the item. For a VPP distribution, you are attaching either a code or a license to the Fileset, which will pre-authorize the item for that user. FileWave 10+ supports the ability to associate VPP application Filesets either to an Apple ID, or directly to a device.

You enter either a name or an iTunes ID code to search for the content to be deployed:

Once you have created the Fileset, you can double-click on it to view extra settings, such as setting Kiosk information. This Fileset does not download the item - application or eBook - but maintains a link to the iTunes Store for that item.

Enterprise Fileset

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.

Special Cases - the FileWave Enterprise App Portal (Kiosk) and Engage for iOS

FileWave makes the native iOS App Portal available from FileWave Support for distribution as a Fileset, as well as the Engage for iOS application. There are two methods for sending out these items.
Local distribution puts the app into the FileWave Server as a Fileset. This keeps all the traffic local and works well for small deployments. Remote distribution pulls the app from the FileWave Support servers. This is a best practice for large deployments over a wide geographic region. The local method looks like the first image on the next page:

The remote distribution references the URL of the remote location for the .ipa:

Profile Fileset

The Profile Fileset takes you to the same window you see when you select Profile Fileset in the New Desktop Fileset tool. Profiles supported in FileWave cover iOS versions starting with iOS 7. The specific profiles are broken out into sets based on newer capabilities in more current versions of iOS. Detailed information on Profiles is covered in Chapter 7 of this manual.

Document (iOS 8+) Fileset

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.


Android Fileset

You can add Android devices as Clients and deploy Filesets to them. The process for creating an Android Fileset resembles the Enterprise method. You must locate the application you wish to deploy in .apk format online, download it, then import it into FileWave to make the Fileset.

The Android Fileset can be set to self-heal, scheduled for distribution, and re-installed as needed. All Android Filesets should be designated as Kiosk items.

Imaging Filesets

FileWave Imaging involves creating macOS X and 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.

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:


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.

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.

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:

Properties - Verification settings

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

Fileset Scripts Overview

FileWave 11+ provides the ability to run a script at any of seven stages of Fileset deployment (called Activation States):

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

Related Content

Fileset Scripts

Fileset / Payload Script Exit Code Status

Script Exit Codes

When a script runs, one of the below errors may be the outcome. 

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

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

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

Fileset Scripts

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

  1. Block redundant installations if the app is already present or
  2. Ensure prerequisites are present or
  3. 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 - A Closer Look

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:

Duh8FMEVU5IDJppp-embedded-image-p7qfarhr.png


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.

Filesets - A Closer Look

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

MTZynaxHsr71VM2t-embedded-image-1uw90vue.png

Example 2

fR2iusk3CDO5OzuL-embedded-image-n9o2e0bn.png

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.


8trDiHeGIRZOxvT0-embedded-image-vmjprnvf.png

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.

Filesets - A Closer Look

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.

Ek7EZCtoUXqlOB3S-embedded-image-akmzu4c9.png

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.

Filesets - A Closer Look

Verification

There are three primary verification settings. Each of these settings causes the related file(s) to behave differently once deployed.

Pasted Graphic 1.png

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.

Pasted Graphic 3.png

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.

Filesets - A Closer Look

Windows Registry

Windows registry files may be included within a Filesets and edited within FileWave.

muc1m7BDo5mcTzjI-embedded-image-hvliewyv.png

Filesets - A Closer Look

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.

aevzYFUC6uHu9Vne-embedded-image-bpsgl6rv.png

eBooks may also be delivered:

JlsGEn0Y5mPWI1Lv-embedded-image-myuyh1wq.png

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.


a9XUUbMwXG2L2Ksn-embedded-image-xxthpmnt.png

Configuration

Enhanced App configuration may be applied, where developers have chosen to offer such features, by way of a preference manifest in plist format.

https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html

Suppliers of Apps should provide details if they exist.

Filesets - A Closer Look

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.

image.png

Filesets - A Closer Look

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:

Pasted Graphic 4.png

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.

Filesets - A Closer Look

Android Apps

Android Filesets are created from either the public or private Play Store.  Additionally, Web Apps may be considered.

Pasted Graphic 5.png

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.

 

Pasted Graphic 6.png

Configuration and Permissions should be reviewed, as should any any management properties where they exist, before assignment.

Filesets - A Closer Look

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:

Pasted Graphic 7.png

Example, Apple App Store Details:

Pasted Graphic 8.png

Example, Apple Profile Kiosk:

Pasted Graphic 9.png

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.

Filesets - A Closer Look

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.


Pasted Graphic 10.png

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.

Filesets - A Closer Look

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.  

Pasted Graphic 11.png

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:

Basic Association Workflow

The basic workflow is select a Fileset, link it to a Client/Group, the update the server model.

  1. You choose a Fileset from the upper right pane:

  1. 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.

  1. 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:

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:

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:

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:

Association Distance

Where the same Fileset is associated to a device by more than one path, the device's 'closest' association should win.

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!

Associations to Deployments Strategy Guide

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:

   

image.png

image.png

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.

Associations to Deployments Strategy Guide

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:

  1. The ability to specify Exclusions in a deployment
  2. New targets/payloads can be added to existing deployments and will inherit the options
  3. 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:

image.png

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:

image.png

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:

image.png image.png

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:

image.png

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:

image.png

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:

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?'

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.

image.png

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:

image.png

As such, new Deployments would need to be created to handle the timed Revision changeover. 

Original Deployment

(EyeBrowse Removed)

 Deletion Deployment Activation Deployment

image.png

image.png

image.png

image.png

image.png

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.

Associations to Deployments Strategy Guide

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:

  1. What is the least amount of work for us, the FileWave Administrator, and
  2. The metadata of a deployment:
    1. Licensing options
    2. Timing Options
    3. Delivery Options
    4. Fileset/Payload Revisions
    5. Destination platform

Both of the above questions are broken down in the following articles referenced below.

Associations to Deployments Strategy Guide

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:

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:

image.png

These associations all make good candidates for being combined into one deployment because:

Pro Tip: FIltering by “Type” being Kiosk or Standard is a great way of isolating like elements for combining associations into deployments.

Associations to Deployments Strategy Guide

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?

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.

Associations to Deployments Strategy Guide

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:

image.png

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.

Associations to Deployments Strategy Guide

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:

How

Resolving the conflicts is quite straightforward. Examples are shown below, with corresponding previews that show the changes:

Conflict Type  
Conflicting Installation Type

image.png



Note that you have to choose which installation type you want to have before you can preview

image.png

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)

image.png

Notice though that in preview, we see the “added” payloads to the corresponding groups.
Differences in Timing

image.png


When timing options differ in a new deployment, we zero everything out. If adding to an existing deployment, the original deployment settings win.

 

image.png

Note that timing option changes will show in preview too.
Differing Payload (Fileset) Revisions

image.png



A single deployment can only have one revision of a payload/fileset. In the case of a conflict between revisions, you MUST choose only one.

image.png

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:

Associations to Deployments Strategy Guide

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.

Associations to Deployments Strategy Guide

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”:

image.png

Step 2 allows you to define “the stuff” that the Targets (devices) get:

image.png

And Step 3 allows you to set options for the Deployment. In this case, we’ll publish these filesets to the kiosk:

image.png

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.

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:

image.png

FileWave Anywhere

Through the newly included Payload Settings:

image.png

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.

image.png

 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

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.

image.png

How

To enable the Force Reboot feature in FileWave v14.10.0, you need to follow the below steps:

  1. Highlight the Fileset that you want to enable the Force Reboot feature.
  2. Select Properties.
  3. Check the "Force reboot" box to enable the feature.
  4. 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

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
  1. Make sure you backup your fileset (right click on a fileset and duplicate).
  2. Take the first snapshot.
  3. Install your update and run your application.
  4. Take a second snapshot
  5. In the comparison view, browser your changes and check all modified files and click Continue 

  1. Check "Merge To Fileset" and click the button "Choose" (fig2)
  2. Select your fileset ( use the duplicate fileset ) and click "OK"
  3. Verify that your changes are merged to the fileset.
  4. Test your fileset.

Fileset Revisions

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

Fileset Revisions

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.

Related Content

Fileset 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

Fileset Revisions

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:

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

Fileset Revisions

"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

Fileset Revisions

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

Fileset Revisions

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

 
Fileset Revisions

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

 

Troubleshooting

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:

  1. The file exists with the same name.
  2. The file size matches.
  3. 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:

  1. The Fileset files are set to never overwrite when the Fileset property "Don't overwrite existing files upon deployment" is checked.
  2. 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)

  1. Create the association to Fileset v2, delete the association to Fileset v1 and update the model. (this will start the upgrade immediately)
  2. 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.
Troubleshooting

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

  
  1. Create and associate a fileset to a client
  2. Edit the association to make the files passive in the near future
  3. Update Model
  4. Check Client Info > Filesets Status at time when fileset is to be made passive

6

STATUS_FILESET_DELETED

OK

Deleted

COMPLETED

iOS

Easiest to see with iOS

  1. Create an iOS App Store fileset
  2. Associate the fileset to an iOS client
  3. Update Model
  4. After app installs and Client Info > Filesets Status shows 'Installed Successfully', delete the app from the device
  5. Close and reopen Client Info (triggers MDM commands)
  6. Open Client Info > Filesets Status for the client

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

  
  1. Create a massive dummy file on the client to eat up disk space
    1. Windows: fsutil file createnew FILENAME BYTES
    2. macOS: mkfile -n SIZE[b|k|m|g] FILENAME
  2. Create another massive dummy file on the Admin to use in fileset
  3. Create an Empty fileset and add the dummy file
  4. Associate the fileset to a client
  5. Update Model & perform Verify for client

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)...

  1. Do not sign into iTunes on an iOS client
  2. Create an App Store fileset
  3. Associate the fileset to an iOS client
  4. Update Model
  5. On the client, tap 'Cancel' when prompted to sign into iTunes

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
  1. Create any type of fileset
  2. Associate the fileset to a client
  3. Update Model
  4. Open Client Info > Filesets Status for client before client gets new model

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

  1. Create an APK fileset
  2. Associate the APK with an Android client
  3. Update Model
  4. On the Android device, tap [Cancel] when prompted to install the APK

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

  
  1. Create 2 filesets A and B
  2. In Fileset Properties set fileset A's Installation Priority to Highest, and fileset B's to Lowest
  3. Select fileset A an click the [Scripts] button in Filesets view
  4. Create a script under 'Activation Scripts' that will cause a wait
    1. e.g. for batch, add a PAUSE
  5. Associate filesets A and B with a client
  6. Update Model & perform a Verify for client

98

FILESET_REQUIREMENTS_ARCH_ERROR

INFO

Requirements not met: architecture

COMPLETED

  
  1. Create a fileset that allows setting Requirements
  2. In Fileset Properties > Requirements, check the box for 'Architecture' and (un)select options that would make fileset fail to install on client
  3. Associate fileset to a client
  4. Update Model & perform Verify for client

97

FILESET_REQUIREMENTS_VERSION_ERROR

INFO

Requirements not met: system version

COMPLETED

  
  1. Create a fileset that allows setting Requirements
  2. In Fileset Properties > Requirements, check the box for 'System Version' or 'Platform' and (un)select options that would make fileset fail to install on client
  3. Associate fileset to a client
  4. Update Model & perform Verify for client

96

FILESET_REQUIREMENTS_MEMORY_ERROR

INFO

Requirements not met: insufficient memory

COMPLETED

  
  1. Create a fileset that allows setting Requirements
  2. In Fileset Properties > Requirements, check the box for 'Min. Memory' and set the minimum memory (in MB) to greater than the total memory for a client
  3. Associate fileset to a client
  4. Update Model & perform Verify for client

95

FILESET_REQUIREMENTS_SCRIPT_ERROR

INFO

Requirements not met: script

COMPLETED

  
  1. Create a fileset that allows adding Scripts
  2. Click the Scripts button and Create a script under 'Requirement Scripts'
  3. Have the script exit with a failure (exit 1)
  4. Associate fileset to a client
  5. Update Model & perform Verify for client

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

  
  1. Create 2 Empty filesets, A & B
  2. Make B a dependency of A
  3. Set the Requirements on B such that it will fail
  4. Associate A with a client
  5. Update Model & perform Verify for client

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'.

image.png

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:

image.png

Now consider the release of 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:

image.png

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.