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 has access to a computer managed by FileWave. What you would need to do is locate the original location in the Fileset Contents window, and drag that item into the final distribution location, as shown on the next page:  becomes…  A significant strength of this type of Fileset is that you can make changes to it at any time, update the model, and those changes propagate out to the associated clients, such as adding another document to the set, or replacing one. ### Empty Empty Filesets are best used for placeholders. You get an empty container that you can add content to at any time. This is an excellent Fileset to 'kickstart' the Kiosk on computers (the Kiosk shows up on a managed computer when at least one Fileset designated as a Kiosk item has been associated with that computer Client).  Once created, you can double-click on the Fileset to view the content window and add items as needed. #### Scripts in Filesets Empty Filesets can also be used to deploy scripts. You can create a script, save it as a *shell script* file, for example <myscript>.sh, and place that into a Fileset. The template for any script is simple: ``` #!/bin/zsh # Put any script content here exit 0 ``` You can use any of the common shell dialects, such as **sh, bash, tcsh, or zsh**. By default, the script is executed once, by **root,** when the Fileset is deployed to the Client. You would set a path for the script to be placed in a location that allows the system to access the appropriate controls, such as in **/usr/local/bin/**. Once the script file is added to the Fileset, you can set its permissions and other variables using the **Contents** window, which is accessed by double-clicking the script file inside the Fileset. **Note: You do NOT put the "sudo" command into a script that is used in a Fileset; scripts run as root when executed by FileWave.** #### Superprefs and Empty Filesets One excellent use of the Empty Fileset is for Superprefs files. You can create a Superprefs file (see Section **5.8**) and just drop the file it creates (fwcld.newprefs.plist) into the Properties window. The settings will be activated upon arrival at the Client. #### System Integrity Protection Apple introduced a security policy with OS X v10.11 (El Capitan) that restricts any non-Apple code from running in protected areas of the system. Make sure none of your scripts try to write to, or edit code, in these areas: **/System, /bin, /sbin**, or **/usr**.For more information on SIP, see this Wikipedia article: [https://en.wikipedia.org/wiki/System\_Integrity\_Protection](https://en.wikipedia.org/wiki/System_Integrity_Protection)
### Fileset Magic Sometimes, the content you want to distribute cannot be found in a completely deployable state. Fileset Magic allows you to build a Fileset from system snapshots taken before the installation/configuration of some software and after, resulting in a Fileset that contains the differences between the two snapshots. Fileset Magic on macOS is accessible from FileWave Admin, but you should use the special version of the Admin application - labeled **FileWave Admin (root)** - which runs as a root process in order to capture all possible file system changes needed to build a complete distribution. This is in /Applications/FileWave/ and was installed as part of the administration software. For Windows administrators, Fileset Magic can be accessed from the FileWave Admin login window as well as inside the Admin application. This allows you to run a Fileset Magic snapshot without the FileWave Admin interfering with Registry changes. Note: When using Fileset Magic, you should quit all other running applications besides the required installers or updaters for your custom Fileset.
  Once you have quit all unneeded applications, you create a snapshot of your system. It is a good practice to use a clean system for this process instead of your normal administrator machine. This will ensure that you are working with the files you want to add and avoiding dealing with all the additional files that get created on a production system from normal use. In other words, the snapshotting processes will run faster with a smaller number of files to scan.  Next, you choose the level of scan desired. Depending on what you are installing or modifying, you may need to deep scan the entire system. If you know where the contents are going to be placed, you can narrow down the scan. The **Expert Settings…** button lets you choose exactly what folders/directories you want scanned.     Once the initial scan is complete, you perform your installs and updates as needed. Run the second scan to get a comparison between the two scans, and choose which files you want to keep in your new Fileset. Once you have picked the files you need, you will name the Fileset and save it. You can also choose to move any files that are needed by all users from the local account where they showed up into the **All Users** location in Fileset Contents. This would be general user-level application support files or specific settings for a local user. You can open the Fileset by double-clicking on it and edit / add / delete contents as needed. For Windows systems, you will need to pay close attention to the Registry. Make sure you do not overwrite any Registry items that existed prior to your Fileset creation unless you are absolutely sure those changes are needed. You should also try to disable any virus-scanning software, backup utilities, and other software that might generate unnecessary files or Registry changes during the construction of the Fileset. ### Import The *Import* Fileset is actually a dialog that allows you to import a previously created Fileset. ### Policy The Policy option contains several payloads that help configure FileWave Clients. *Blocker Script:* This policy applies to desktop devices and allows you to suspend management with a script. The script runs every 5 minutes or during verification. If it exits with a non-zero status, the client suspends management; if it exits with 0, management continues or resumes. FileWave reflects suspended management in inventory under the Component type "FileWave Policy" and in the "Policies" tab in the Client Info window. [](https://kb.filewave.com/uploads/images/gallery/2025-09/e3ymZwAKRoDdwyJP-image.png) *Geofencing*: This applies to Android devices and can run an action when a device leaves a geofenced area. More details in [Geofencing](https://kb.filewave.com/books/android/page/geofencing "Geofencing") [](https://kb.filewave.com/uploads/images/gallery/2025-09/AYBubpCkP2h14XNf-image.png) *Kiosk*: This can customize the look of the Kiosk as outlined here [Setting the Primary Colour, Name and Logo in Kiosk/App Portal (16.0+)](https://kb.filewave.com/books/kiosk/page/setting-the-primary-colour-name-and-logo-in-kioskapp-portal-160 "Setting the Primary Colour, Name and Logo in Kiosk/App Portal (16.0+)") [](https://kb.filewave.com/uploads/images/gallery/2025-09/jGN1Do4dVxLoADjU-image.png) *Windows Software Updates*: This can automate the deployment of Windows OS updates as covered here as of FileWave 16.2.0; [Automated Windows OS Updates Policy](https://kb.filewave.com/books/software-updates-windows/page/automated-windows-os-updates-policy "Automated Windows OS Updates Policy") [](https://kb.filewave.com/uploads/images/gallery/2025-09/Bz5vMiK2fHbQLvOm-filewave-admin-2025-09-23-09-22-57.png) ### Software Update FileWave allows you to capture the software updates provided by both Apple and Microsoft through their software update mechanisms and convert those updates to Filesets. The list of software update servers used by both providers is located in the FileWave Preferences under the General settings. These URLs can be edited as changes are made. The updates do not include items that Apple provides only through the iTunes Store or App Store. If you deploy a large number of macOS, iOS, or iPadOS devices, consider using Apple's macOS content caching service on your network. Content caching stores Apple software and iCloud content that local devices have already downloaded so other devices can retrieve it without downloading it again from the internet. See [Apple's content caching deployment guide](https://support.apple.com/guide/deployment/intro-to-content-caching-depde72e125f/web) 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.Note: These updates do not include items from the iTunes or App Store; it shows iOS operating system updates only.
--- ## Apple ### Profile The Profile Fileset contains all of the settings used for both computer and mobile device management on macOS and iOS. The Profile Editor in the Desktop Fileset window is identical to the one in the Mobile Fileset window. ### DDM Asset Think of a DDM Asset as a configuration setting. DDM Assets include Authentication credentials and User identity. ### DDM Configuration Think of a DDM Configuration as a more modern Profile. It has options you can set and then assign. DDM Configurations cover settings such as Passcode Settings, Screen Sharing Connections, and Software Update Settings. The design is similar to Profiles in the FileWave interface, but it uses Apple's declarative device management engine on the client. ### App Store You can create Filesets for Apple Clients using content from the Mac App Store. As with the iOS App Store Fileset, you are not actually storing the application or eBook inside the Fileset; but providing the URL to the content online. Filesets created in this manner can be distributed to a user's computer and require the user to enter their Apple ID in order to access the content, or you can link the Fileset to the Apple VPP store and provide either redeemable codes or managed distribution licenses for the provided content. With FileWave, you have the ability to associate App Store content directly to a device, or to a user's Apple ID as part of a VPP distribution. ### AutoPkg AutoPkg lets you search for and add an AutoPkg-generated installer. You can read more in [AutoPKG](https://kb.filewave.com/books/integrations/page/autopkg-filewave-integrated-v155 "AutoPKG"). ### PKG The two Filesets that do not store their contents as individual files are the PKG Fileset and MSI Fileset. For the PKG Fileset, you select a downloaded installer for macOS (.pkg and .mpkg). When the Fileset is deployed to the Client, upon activation it will run as an installer with local administrator privileges. ### Document With the ability to set "Open in…" characteristics in iOS 8+, you can also create Filesets with document content. This type of Fileset can contain **pdf**, **ePub**, and non-Apple iBookstore **iBooks** formatted items (ones created with *iBooks Author*). They are delivered to the iBooks Library as a **managed document** which means it can be given and taken away.   ### Enterprise The Enterprise Fileset is designed for you to distribute an **internally-created** iOS application. Apple does not condone or support using this type of Fileset to distribute Apple App Store or iTunes Store content. You can easily distribute software you have created with this Fileset by locating the **.ipa** file for the application on your administrator system and adding it to the Fileset list. All of the custom controls and settings are available for use with this distribution. You can select a remote location for the .**ipa** distribution. Normal configuration is to import the **.ipa** into your FileWave Server and wrap it up as a Fileset. The new method allows you to enter a URL to the **.ipa**, such as a web server, where the item can reside. --- ## Microsoft ### MSI Fileset The two Filesets that do not store their contents as individual files are the *MSI* */* *PKG* Filesets. For this Fileset, you select a downloaded installer for Windows (.msi). When the Fileset is deployed to the Client, upon activation it will run as an installer with local administrator privileges.Note: Filesets based on .msi will uninstall the contents when the Fileset is removed/disassociated. Instead of just removing the installer, the Fileset will perform an actual uninstall process.
Windows-based distributions may come pre-packaged in the Microsoft Installer format (MSI). Customizations to MSI files can be made through Microsoft Transform (MST) files. FileWave supports MSI and MST through its Patch Installer feature. The MSI file must have a lower case MSI extension, such as *Application Installer.msi*, for the MSI file to be recognized by the Admin software. MST is supported by modifying a Patch Installer Fileset. An MST file must be copied into the same directory in the Fileset Contents Window as the MSI file. (This location is generally *FileWave\\FileWaveInstallers\\Application.msi*). Additionally, the MST file must be named exactly the same as the MSI file with a lower-case MST extension such as "*Application Installer.mst"*. #### Installations with Setup.exe Installers Complex installations are contained in an executable file often named "*Setup.exe.*" It may be simpler to deploy the executable file and have it run on the local computer rather than creating a Fileset based on snapshots. FileWave's Windows Client and FileWave Admin have features to handle the deployment of Setup.exe style installers. The steps for this kind of deployment are as follows: - Copy the Setup.exe file to the Desktop of the computer where the FileWave Admin program is running connected to a FileWave Server. - Create a New Empty Fileset, give it a name and optional comment. - Open the Fileset & uncheck the "Hide used folders" checkbox. - Create a folder structure of where you would like the EXE file deployed. A good place is *Documents* and *Settings\\All Users\\Application Data\\FileWave\\Installers*. - Copy the Setup.exe file from the Desktop of the Admin's computer into the folder created in the Fileset Contents Window. This will be the folder where the Setup.exe will be delivered to on the client computers. - Select the Setup.exe file in the Fileset Contents Window and click on the Get Info button in the toolbar. - Click on the tab labeled Executable. - Check the checkbox labeled "Execute once when activated." - Add any arguments or options to include as part of the installation process. Sometimes it is preferable to run installers silently. Many Setup.exe installers take a /quiet or /s or /silent argument.Note: If you are unsure about the arguments, try dragging the Setup.exe into a Windows Command Prompt window and pass the /h or /help or /? argument to see a number of argument possibilities.
### Winget WinGet lets you create installers for many Windows-based applications with a single click. More information is located in [Microsoft WinGet Overview](https://kb.filewave.com/books/microsoft-windows-package-manager-winget/page/microsoft-winget-overview "Microsoft WinGet Overview"). Import Image FileWave Imaging involves creating Windows images that are used to image new computers or to re-image current computers. This workflow allows Boosters to act as imaging caches during the imaging process. More information on Imaging is in [Network Imaging / IVS](https://kb.filewave.com/books/network-imaging-ivs "Network Imaging / IVS"). ### Windows Drivers FileWave Imaging involves creating Windows images that are used to image new computers or to re-image current computers. This workflow allows Boosters to act as imaging caches during the imaging process. More information on Imaging is in [Network Imaging / IVS](https://kb.filewave.com/books/network-imaging-ivs "Network Imaging / IVS"). --- ## Google ### Play Store You can use this to create Filesets from the Google Play store. This method also lets you select Private Apps that you have published in the Play store as well in case you need to send an APK to a device that isn't a public application there. ### Policy This is discussed with more detail in [Android EMM Policies and Permissions](https://kb.filewave.com/books/android/page/android-emm-policies-and-permissions "Android EMM Policies and Permissions") but this is a way to set various settings on your EMM enrolled Android devices. # Fileset Groups You can arrange Filesets into Groups for easier deployment workflows. Fileset Groups can be nested into other Fileset Groups, much like Client Groups. Once a Fileset Group is created by clicking the **New Fileset Group** button, existing Filesets may be dragged and dropped into the Group. Filesets and Fileset Groups cannot be cloned, so they can only reside in one Group at a time. Fileset Groups may be associated to a Client or Client Group. # Advanced Fileset Editing - Contents, Properties, Settings, and Dependencies While you can create a Fileset and associate it with a Client without doing any additional steps. However, your ability to customize the Fileset contents, specify its properties, and alter its settings gives you a tremendous amount of flexibility in your deployment models. Once you have created a Fileset, it will appear in the main **Filesets** window. The basic properties of that Fileset are shown in the window menu bar:  - ***Name*** – This is the title of the Fileset you created. - ***Size*** – This is the size of the Fileset in bytes as it is stored on the FileWave server. This can also affect your Boosters in terms of how much storage they will need to handle cached Filesets. - ***Version*** – When a Fileset is first created, it is version "0" until you edit the Fileset and update the server model. As you make changes to the Fileset, its version number will increment. - ***Files*** – This is the total number of files contained in the Fileset. - ***ID*** – This is a unique identifier used by the FileWave server to keep track of your Filesets - ***Comment*** – This is any optional text you enter to add information about the Fileset - ***VPP Token*** – This designates which Apple Volume Purchase Program token is assigned to a particular Fileset. The contents of a Fileset can be edited and altered as desired, depending on the type of Fileset. You can get specific information on items within a Fileset in order to customize its behavior when distributed. By double-clicking on a Fileset, you will see one of three different windows depending on the Fileset type . ## Desktop Fileset contents The Desktop Fileset contents are the specific items to be installed along with their designated paths. Examples are:    You can add items to the contents with the **New Folder** and **Import Folder** buttons. You can also remove any items that you are sure will not be needed in the final Fileset. By double-clicking on a specific item or selecting an item and clicking on the **Get Info** tool, you can inspect file level information. This includes basic file information, permissions, ACLs if any are in use, Verification settings, script Executable details, and Flags that can be set.For Windows systems as of FileWave 16.0.0 it is important to understand that a file will by default inherit the permissions of the directory it is placed within and that C:\\ProgramData\\FileWave\\ and specifically C:\\ProgramData\\FileWave\\FWClient\\ and C:\\ProgramData\\FileWave\\scripts\\ are further restricted to try to prevent end users from manipulation of files.
 ## Verification 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. There are three primary verification settings. Each of these settings causes the related file(s) to behave differently once deployed.  - ***Self Healing*** – A file designated as self-healing will always be repaired or replaced by the FileWave Server if it is altered in any way. If you have items deployed that require their contents remain unchanged and intact at all times, you would set the files to be self-healing. - ***Download if Missing*** – This setting will force a Client to re-download the file if the FileWave Client reports this portion of a Fileset as missing. The file will not be replaced if it has been altered; but only if it is deleted. - ***Ignore At Verify (Left Behind)*** – Some files need to be dropped onto a client and left alone. This setting tells the FileWave Client to ignore any changes in this portion of the Fileset during a verification. - ***Don't overwrite existing files upon deployment*** – This setting can be chosen to go with either the *Download if Missing* or *Ignore At Verify (Left Behind)*. You can tell FileWave to not write over top of any files that already exist when the Fileset is activated. - ***Overwrite only if the existing file is older*** –This setting is a subset of the one above, in that you might choose to allow older files to replaced only by newer versions of the same item.Note: All file comparisons are done by filename and modification date.
## Edit Registry When you are working with Windows Filesets, you may need to explore the Registry entries. Within Fileset Contents, you can select the registry file and edit the contents. If you need to distribute a Registry file, you can add one to an empty Fileset.  - ***Edit Text*** – You can edit many of the text based files in a Fileset directly. In FileWave Admin's Preferences, you will see all of the various file type extensions that are supported. - ***Export Files*** – Any file in a Fileset can be exported for use elsewhere. This capability can be used to open a complex Fileset and export portions of it for use in another Fileset. ## iOS App and Enterprise Fileset contents Filesets for iOS applications are focused more on behavior and end user information than actual file level content. The content consists of three panes: Details; Kiosk; and, Configuration. **Details** contains general application information, management flags, and VPP information. The management flags include the ability to force application removal when the MDM profile is removed, and the ability restrict application data from being backed up in iTunes. A flag introduced in FW 10+ allows you to **take management** of an existing version of this application. If a user has installed an application that needs to be managed; because their device is managed, you can "take over" control of that application. This would allow you to control distribution and settings. VPP shows the connection between a Fileset and a VPP account. A warning is shown (see screenshot on next page) if a VPP token is associated with the application noting that the Fileset cannot be attached to a different VPP account token.  **Kiosk** displays the information from the iTunes Store, online review ratings, and allows you to choose a category for the item when displayed in the Kiosk. You can edit the text of the application title, as well as the description. This allows you to personalize the information for your organization versus using the marketing material provides by the developer to the iTunes/App Store. In FW 10+, you can customize the information with tags, such as **Bold**, and underlined, for readability; plus you can add URLs within the information pane.  The **Configuration** pane allows you to add management settings for a specific application, if that application supports the use of a *preference manifest*. The settings must come from the application developer and will be in the form of a *property list* file (.plist). There is much more information on what these files are and how they are constructed in Apple's Developer site - [https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html](https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html) ## macOS App / iOS eBook Fileset contents Application Filesets for macOS and eBook Filesets contain the same type of content information in the **Details** pane, including the VPP token information. The **Kiosk** pane contains the same information as discussed in the iOS App Fileset contents.  The **Requirements** pane specifies the platforms the eBook can be distributed to and allows you to retroactively change these settings on actively deployed Filesets. Selecting *Apply to Active Filesets* lets you retroactively change Filesets that have been deployed.  **Kiosk** settings are the same across all Fileset types. You can set the category of the item, and edit the title and item description to better match your organizational needs. If you select *Restore Defaults*, the item's title and description will revert to what is posted in the iTunes/App Store online. ## Profile Fileset contents Profile Filesets have a simple contents window. You can view the various payloads that are contained in the profile, edit the payloads, export payloads, and choose the device settings. Settings include **Platform** choices which must match the categories in Profile Editor. The **Installation** choice determines whether the profile will be activated at system level (as a Daemon), which is prior to Login Window, or at user level (as a Launch Agent), which is at Finder launch. You can force the profile to reinstall if the user removes it. Devices that are running OS X 10.6 - 10.9 can have the **legacy install** flag set. This will force the settings that these devices get to be **MCX** **.plist** formatted, if the computers are running a FileWave Client earlier than version 9.   Details on profiles and configuring them are in Chapter **7 (Mobile Device Management)**. ## Android Fileset contents The Fileset created for Android contains only the **.apk** file. The file cannot be relocated, and other files should not be added to the set. The *Get Info* button exposes the permissions and other settings; but those values should not be changed from the defaults.  The Fileset will send the contents to the Android device's Kiosk. From there, the end user can select to install the item, which will place the contents in the Downloads folder for manual installation. ## Fileset Properties Once you have created a Fileset, you can access a wide range of properties that enhance the effectiveness of that Fileset in your deployment. The properties available vary depending on the specific type of Fileset. In most cases, the information presented does not need to be altered or edited; but this information is presented to allow you to understand the depth of control you have over your file level deployments.Note: Making changes to Filesets can result in unexpected behavior, please test on a non-production device prior to mass deployment. Better yet - just test everything on a non-production system first.
## Properties - basic settings The first tab is the primary properties for the Fileset. The basic options are: - ***Require Reboot (with Message)*** – In most cases, you won't need to require the computer to reboot; but software update Filesets usually do. You can provide a message to be displayed for the end user as a warning that software is being installed and a reboot will be required. Once you have configured a Fileset for **reboot**, you can also set a "Reboot deadline" to force the completion of the Fileset installation. This process is covered in the **Associations** section. - ***Ignore Permissions on Existing Folders*** – Normally, the Fileset will overwrite permissions on existing files and folders during a distribution. You can choose to leave permissions in place; but recognize that in some cases, portions of the Fileset may not be installed. - ***Installation Priority*** – When you are working with a Fileset Group or a series of Filesets to be distributed as a single workflow, the deployment often requires certain items installed before others. The Installation Priority lets you assign an order of activation. Highest items first, then lower priorities. When the installation priority is the same, the Fileset ID determines priority with lower ID numbers having the higher priority. - ***Color*** - you can assign colors to your Filesets to differentiate them in the Fileset view. ## Properties - Verification settings - ***Self Healing*** – Use this setting to force the re-distribution of the file if any changes have been made to the existing Fileset files that have this label. This function will repair settings and other files that were accidentally or purposely changed. - ***Download If Missing*** – During verification, if a file is no longer present, it will be replaced from the master Fileset. - ***Ignore At Verify (Left Behind)*** – This setting will tell the verification to ignore anything with this label. This setting is often used in files that are meant to be dropped into a location once, and ignored after that. - ***Don't Overwrite existing files upon deployment*** – This setting is a subset of the two settings above. It allows you to keep any existing files from being overwritten by other files with the same names. - ***Overwrite only if existing file is older*** – This setting is also a subset of *Download if Missing* and *Ignore At Verify (Left Behind)*, and can be activated if the above setting is in effect. It will allow only older versions of the same named files to be replaced. ## Properties - Requirements These settings establish the device definition that will allow the FileWave Client application (fwcld) to download and activate a Fileset. You can choose specific operating system platforms, architectures, memory, and system versions. Selecting *Apply to Active Filesets* will force these settings to be re-applied on deployed Filesets. If a device no longer meets the verification criteria, the Fileset will be dis-associated and removed.  ## Properties - Delete Files Use this tab to provide the paths to files that need to be deleted when this Fileset activates. ## Properties - Kiosk You use this tab to configure the appearance of your Fileset in the Kiosk. You can can change the icon, place the Fileset into a designated category, and edit the title and description of the Fileset. This includes changing the information provided from the iTunes/App Store to be something more oriented toward your deployment needs. With FileWave 10+, you can use Rich Text formatting to improve the look and feel of the Description. ## Properties - Details Details contains general application information, management flags, and VPP information. The management flags include the ability to force application removal when the MDM profile is removed, and the ability restrict application data from being backed up in iTunes. VPP shows the connection between Fileset and a VPP account (what VPP token was used for the item, if applicable). A warning is shown if a VPP token is associated with the application noting that the Fileset cannot be attached to a different VPP account token. It is the same information you would see on that Fileset if you double-clicked on it or selected *Get Info* for that item. Those settings are reserved for Filesets from Apple App Store or iTunes Store content. ## Exporting Filesets Filesets can be exported for transfer to another FileWave server. They can be compressed and stored for future use or archived. iOS Filesets, however, cannot be exported. ## Dependencies (introduced in FW v10) You can designate one of more Filesets that must be activated/installed before another can be activated. If you associate a Fileset that has dependencies, then the other Filesets will automatically get associated and will be applied before the dependent one. It works with multiple, cascading dependencies also. The only Filesets that do not contain the ability to show dependency are the Apple App Store and iTunes Store Filesets. In the Properties of a Fileset that has dependencies, you just click on the \[+\] to add any Fileset that must be activated prior to your dependent Fileset. You can also drag and drop Filesets within the Dependency pane to rearrange them in order of need. The first one to get activated will be at the top of the list. There is also a toggle at the bottom to check and see if there are Filesets dependent upon the Fileset that you are examining.     Starting with FileWave 11, is the ability to see a dependence chain when looking at the Fileset Status report in the Client Info dialog, where dependencies appear as children of the Filesets that require them. # Fileset Scripts # Fileset Scripts Overview FileWave can run scripts at seven stages of Fileset deployment, called **activation states**: - Requirements - Preflight - Activation - Postflight - Verification - Pre-Uninstallation - Post-Uninstallation In FileWave Admin, open the **Filesets** view, select the Fileset you want to edit, and click the **Scripts** toolbar icon. The Scripts dialog shows each script and the activation state where it will run.  Scripts in the same activation state run from top to bottom as shown in the list. Drag scripts to change their execution order. Use the create or import buttons to add scripts. You can also edit a script, or drag a script from Finder into the dialog to import it. Click **OK** to save changes to the Fileset. Click **Cancel** to discard the changes. Double-clicking a script opens the file properties dialog. Most script attributes can be changed in the same way as files in an open Fileset, but some settings are locked because the Fileset workflow depends on them. For example, the Execute flag cannot be cleared. Requirement scripts also cannot be changed between interactive and non-interactive execution because the client must be able to use the script exit code to decide whether the Fileset should download. The checkbox **Re-run requirement scripts on change and uninstall active Fileset if they failed** controls the same internal setting as **Evaluate requirements on change and uninstall active Fileset if they failed** in the Requirements tab of the Fileset properties. When this option is enabled and the Fileset changes, the client re-evaluates the Fileset requirements, including requirement scripts. If any requirement or requirement script fails, the Fileset is uninstalled. ## Fileset script types - ***Requirements Scripts*** – Run before the Fileset or its dependencies are downloaded. If any requirement script returns a non-zero exit code, the Fileset and its dependencies are not downloaded or installed. - ***Preflight Scripts*** – Run after dependencies are installed, but before the Fileset downloads. If any preflight script returns a non-zero exit code, the Fileset is not downloaded or installed. - ***Activation Scripts*** – Run when the Fileset is activated. - ***Postflight Scripts*** – Run after the Fileset installation has completed. - ***Verification Scripts*** – Run after postflight scripts and during each verification of the Fileset. - ***Pre-Uninstallation Scripts*** – Run when a Fileset is inactivated, immediately before the Fileset is uninstalled. Use this state when the script needs access to files that self-healing will remove during uninstall. - ***Post-Uninstallation Scripts*** – Run immediately after the Fileset and its dependencies have been uninstalled or removed from the client. ## Related Content - [Fileset / Payload Script Exit Code Status](https://kb.filewave.com/books/filesets-payloads/page/fileset-payload-script-exit-code-status "Fileset / Payload Script Exit Code Status") - [Script Best Practices](https://kb.filewave.com/books/filewave-general-info/page/script-best-practices "Script Best Practices") - [How the Client Communicates](https://kb.filewave.com/books/filewave-client/page/how-the-filewave-client-communicates) # Fileset / Payload Script Exit Code Status ## Script Exit CodesStatus 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 |
This article reflects the behavior in FileWave 16.0.0+
When deploying Filesets in FileWave; - It’s possible to include a Verification Script that runs every 24 hours (or at system restart) on Windows and macOS. - You might also have a Requirements Script that runs every 2 minutes to test for a condition needed to install something. These scripts are typically used for tasks such as re-applying Group Policy settings—using tools like LGPO.exe on Windows—as an example. However, if an executable (like LGPO.exe) is replaced by a non-administrator, there’s a risk that the malicious replacement could be executed with elevated privileges (SYSTEM on Windows or root on macOS). By default, Filesets benefit from a self-healing mechanism. If an executable is modified, the Fileset will restore the original file before the Verification Script executes. An image below shows this status and picking **Get Info** for a file may be used to change this on a per-file basis. Properties for a Fileset can be used to change the behavior across the entire Fileset as well. [](https://kb.filewave.com/uploads/images/gallery/2025-02/qXzyhyqHfvEn8zaa-image.png) This same protection applies when the executable is deployed and then called by a Custom Field—the Fileset’s verification step precedes the Custom Field execution, thereby mitigating the risk of local privilege escalation. However, there is one scenario where this protection of Self-Healing does not apply: the Blocker Script, which by default runs every 5 minutes. Its more frequent execution window could allow a local user to replace an executable before the next Fileset verification occurs. However this too can be mitigated as we will discuss below. ## When/Why This article is particularly relevant in environments where: - Executable files (e.g., LGPO.exe) are deployed via Filesets that also include a Verification Script or are triggered via Custom Fields. - There is a risk of local users, who lack administrator rights, replacing these executables to attempt privilege escalation. - The deployment involves Blocker Scripts, which run at more frequent intervals (every 5 minutes), thus presenting a window where an attacker might replace a file before it is healed by the Fileset. #### **Why is this important?** Ensuring that only the intended executable is run with elevated privileges is critical for system security. A malicious modification could lead to unauthorized privilege escalation. Mitigating this risk by enforcing strict file ownership and permission settings prevents non-administrative users from replacing or modifying executable files. ## How To mitigate this risk, it is recommended to either pick properties on the file in the Fileset and properly secure it or use a Postflight Script in your Fileset deployment that sets the file permissions so that only SYSTEM (on Windows) or root (on macOS) can modify the file. On Windows systems as of FileWave 16.0.0 the c:\\ProgramData\\FileWave\\ directories like FWClient and the scripts directory are restricted so that a non-Administrator is unable to manipulate files located there. This is one way that FileWave will prevent a local attack by default. Files on Windows will also inherit the permissions of the directory that they are deployed in to which will help for a more consistent permissions experience. For some examples of setting permissions on files please take a look at the below. For the scripts you could have them run as Fileset scripts when deploying the files to adjust permissions to how you'd like. #### **macOS Example (Properties of file in Fileset)** In the below images you can see an example file in a Fileset where **Get Info** has been clicked in the toolbar when viewing the Fileset and the permissions have been adjusted so only root:wheel has access to the file. Make sure you click **Apply** on each screen to make the setting change.  #### **macOS Example (zsh Script)** Below is an example zsh script that sets the ownership to root:wheel and the permissions to 770 for the target executable. ```shell #!/bin/zsh # Define the path to the executable deployed via the Fileset TARGET_FILE="/path/to/executable" # Change the ownership of the file to root:wheel chown root:wheel "$TARGET_FILE" # Set the permissions to 770 (owner and group have full permissions, others have none) chmod 770 "$TARGET_FILE" # Explanation: # - chown root:wheel: sets the file owner to root and group to wheel. # - chmod 770: grants read, write, and execute permissions to the owner and group, # while denying any permissions to others. ``` #### **Windows Example (PowerShell Script)** The following PowerShell script sets the file’s owner to SYSTEM and adjusts the permissions so that only Administrators and SYSTEM have full control. This ensures that no non-administrator can replace the file. ```powershell # Define the path to the executable deployed via the Fileset $TargetFile = "C:\Path\To\executable.exe" # Set the owner of the file to SYSTEM using icacls icacls $TargetFile /setowner "SYSTEM" # Remove inherited permissions to ensure only our defined permissions are in place icacls $TargetFile /inheritance:r # Grant full control (F) to SYSTEM icacls $TargetFile /grant SYSTEM:(F) # Grant full control (F) to Administrators icacls $TargetFile /grant Administrators:(F) # Explanation: # - icacls /setowner "SYSTEM": sets the file owner to SYSTEM. # - icacls /inheritance:r: removes inherited permissions so only our custom permissions apply. # - icacls /grant SYSTEM:(F) and /grant Administrators:(F): # ensures that only SYSTEM and Administrators have full control over the file. ``` ## Related Content - [FileWave Version 16.0.2 Security Notices](https://kb.filewave.com/link/1045#bkmrk-security-notices-the) - [Verification](https://kb.filewave.com/books/filesets-payloads/page/verification "Verification") - [Script Best Practices](https://kb.filewave.com/books/filewave-general-info/page/script-best-practices "Script Best Practices") - [Fileset Scripts Overview](https://kb.filewave.com/books/filesets-payloads/page/fileset-scripts-overview "Fileset Scripts Overview") # Filesets - A Closer Look Contents, Properties, Settings, Revisions and Dependencies # Filesets View Creating a Fileset and deploying to clients can be relatively simplistic, e.g. PKG, MSI or VPP. However, custom configuration through properties, provides tremendous flexibility. The standard Fileset view provides some basic details: [](https://kb.filewave.com/uploads/images/gallery/2024-07/OzIsYoFTS5f9JYtC-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. |
Files may be selected and exported from the Fileset to the local device.
# Desktop PKG and MSI Filesets ## What Special Filesets may be created for PKG and MSI installers. These will automatically instal the software on deployment activation. ## Why It is usual for Admins to just simply require PKGs or MSIs to instal on activation. To simplify the process, FileWave can automatically create a special Fileset to handle this process. ## How Using the New Fileset option within the FileWave Central Admin App, it is possible to choose PKG or MSI Fileset. From the pop-up view, select the installer and FileWave will create this auto installing Fileset.More easily, if a PKG or MSI installer file is dragged into the FileWave Central Fileset view, the same automated Fileset should be created, without the need to use the New Fileset view.
Dragging the installer file onto a desired Fileset Group will cause this new Fileset to be created within that group.
Consider renaming the installer before upload, such that the version number is not included. Instead, add the name and version number to the revision name. The below section on revisions should make this clear why this would be a good idea.
## Information Opening a PKG or MSI Fileset will show the contents similar to the below: [](https://kb.filewave.com/uploads/images/gallery/2025-02/6ojD9S4X0N5yip78-image.png) From creation, this special Fileset is expecting an installer of the named PKG or MSI from initial upload to the server.If manually altering a PKG or MSI Fileset, to upload a newer version of an installer, it is therefore necessary that the replaced installer file MUST have the same name as the installer being replaced.
### Revisions In some ways, revisions simplify the process of updating the Fileset with newer installers. There are two ways to create a new revision: - Drag and drop a new installer onto the existing Fileset - Open the existing Fileset, choose the option to Manage Revisions and from the button to add a new revision, choose to duplicate #### Drag & Drop When dragging a PKG installer onto a current PKG Fileset or an MSI onto a current MSI Fileset, a prompt similar to the below should be shown: [](https://kb.filewave.com/uploads/images/gallery/2025-02/UULkHQ1A5CEXDqHa-image.png) Choosing the option to 'Add revisions to existing' will automatically generate a new revision with this new installer. Assigning this new revision to devices or setting this new revision as the new default should then trigger this new installer to activate on devices.After the new revision is created, consider opening the Fileset to set the name of the new revision, such that the name includes the version number of the installer.
#### Duplication When choosing to Manage Revisions from within the Fileset, there is the option to duplicate a revision of choice. On doing so, everything from the prior Revision can be copied over to this new revision. [](https://kb.filewave.com/uploads/images/gallery/2025-02/jaEvwtaKpwub0doQ-image.png) This is useful when there are multiple additional items added into a PKG or MSI Fileset. However, there is an important consideration when using this method. As highlighted above, when manually replacing a PKG or MSI installer, **the installer name with the Fileset must match**. Hence, duplicating a revision, with the idea of replacing the current installer with a new version, whilst maintaining additional files, forces this requirement.Before creating the first Fileset for a given installer, rename the installer to exclude the version number before uploading. Instead, add the version number into the name of the revision instead.
The name of the installer to be uploaded does not need to match, but the name of the installer within the Fileset must match. If the name of the installer file does not match before upload, 'copy' the name from within the Fileset, upload the new installer into the same folder as the original installer, delete the original installer and rename the new installer using 'paste'.
If the name of the initial installer uploaded includes the version number, when manually altering the revision, since the name must match, the newly uploaded version would have to be misnamed with a version number that does not make sense.
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.
Most installers only handle upgrade, not downgrade. If there is a desire to rollback to an older revision, it is likely the currently installed version on the device will need to be deleted beforehand.
After successful installation, the .msi is removed locally from the machine. If you need to remove the application at a later date, please refer [here](https://kb.filewave.com/books/filesets-payloads/page/uninstalling-filesets) for details on the 'Use MSI uninstaller' checkbox. If you require specific switches or other custom parameters for installation and uninstallation, using an empty fileset may provide better flexibility for deployment.
## Related Content - [Fileset Revisions](https://kb.filewave.com/books/filesets-payloads/chapter/fileset-revisions) - [Uninstalling Filesets](https://kb.filewave.com/books/filesets-payloads/page/uninstalling-filesets) # Verification There are three primary verification settings. Each of these settings causes the related file(s) to behave differently once deployed. | **Self Healing** | Files set as self-healing will be replaced on devices with those within the Fileset, if different, or added if missing. The act of Verification re-confirms all included files. | On disassociation, Files included in the Fileset will be removed from the device |
| **Download if Missing** | Similar to self-healing, however, the file will only be added if the file is missing. After initial deployment, the file may be altered, without repair occurring at Verification | On disassociation, Files included in the Fileset will be removed from the device |
| **Ignore At Verify (Left Behind)** | Once delivered, the file may be altered. | On disassociation, delivered files will remain on the device. |
| **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. |
Any files that already exist between one Fileset and another, will not be transferred between server and client since they already exist as required; with the exception of the overwrite option on initial deployment.
# Windows Registry Windows registry files may be included within a Filesets and edited within FileWave.  # Apple VPP Apps Unlike File Level Filesets, Apple VPP Filesets contain the details of the App from the App Store, including the link to the App, with 3 distinct tabs, Details, Kiosk and Configuration.FileWave does not store Apps from the App Store, devices will pull the Apps directly from the App Store on successful activation.
#### Details Amongst these are some key entries:| **Remove App when MDM profile is removed** | If the device has the MDM enrolment profile removed, this option will force Apps managed by MDM to be removed. |
| **Prevent Data Backup** | Disallow the App from backing up user data |
| **Take management of this app if the user has installed it already** | For Apps already installed, the MDM server will take over management of the App from the user. This is required if you want FileWave to manage deployment behavior, updates, and related settings for that App. |
| **Application update (DDM)** | For supported apps installed through DDM in FileWave 16.3.x, this controls how the App is updated on iOS, iPadOS, and macOS. Choose **Follow Store Settings**, **Always On**, **Always Off**, or **Pin specific version**. If you choose **Pin specific version**, use the version field to target the exact App Store version to install and keep. |
| **User** | Only set when a managed user logs in |
| **System** | Payload settings applied regardless of user logged in. |
Apple allows the management of any amount of directory users for a single device. However, only one local user will be managed. This user will be the first user after enrolment of the device.
Profiles are stored directly within the Fileset and delivered to devices after MDM communication has been established. # Android Apps Android Filesets are created from either the public or private Play Store. Additionally, Web Apps may be considered.  Three tabs are available for a Play Store App Fileset: Configuration, Permissions and Managed Properties. The later will only contain management options, where the developer has chosen to include options. Configuration and Permissions should be reviewed, as should any any management properties where they exist, before assignment.
# Fileset Properties Properties exist for most Filesets, but options displayed will vary depending upon Fileset type. File Level Filesets include:| **Properties** | Additional features, including Reboot (force sub-option), priority and an option to alter the verification for the entire Fileset. Priority offers additional control over the order of Fileset activation. |
| **Requirements** | Settings defining the OS and hardware specific necessities. Only if devices match these, will the Fileset be downloaded and activated. |
| **Dependencies** | Discussed in greater details elsewhere. In essence, the Fileset will only activate if another defined Fileset instals first. |
| **Delete Files** | A Defined list of files to be removed during activation |
| **Kiosk** | Details shown to users via the Kiosk Self-Service menu and system tray item. |
Profiles may only be a dependency in one direction, to prevent unexpected delay of Fileset installations.
FileWave has no control over the MDM protocol, but must rely upon Apple’s process for delivery of MDM items. For this reason, using dependencies, an MDM Fileset, e.g. Profile or VPP App, may be defined to instal after any other non-MDM Fileset type has been activated, but does not allow other Filesets to be reliant on an MDM Fileset.
# Dependencies Dependencies offer a way to associate multiple Filesets with reliance upon other Filesets to be installed first. From the below example image, 2 Fileset Dependency Properties are displayed. - **Left image:** the Fileset which will instal first (should not be associated with devices relying upon this dependency). - **Right image:** the Fileset that will be associated and therefore instal afterwards. It can be seen that the Fileset on the left is shown as a dependency of the Fileset on the right.  Multiple Filesets may be used as dependencies or be the dependent. Dependents of a Fileset may also be a dependency of another Fileset, creating a chain of Fileset installations. # Revisions Previously, updating one version of a software, for example, to a newer version, would require: a new Fileset created, new association or deployment generated and then the prior association removed. Revisions simplifies this process. To prevent associations or deployments being altered, a Fileset becomes a container of multiple revisions.  The version associated with devices may be altered within the Fileset. This allows for efficient update of Filesets on devices, simplified process between testing and mass assignment, whilst at the same time providing an easy method to roll back if found to be necessary; depending upon Fileset Type.Behind the scenes, swapping from one revision to another is the same as actually swapping between two different Filesets. All contents will be reconsidered and any scripts ran, e.g. a post-uninstaller script will run if included in the Fileset Revision that is being unassigned.
# Using Associations with Filesets The **Associations** pane is the primary location where you connect your Filesets to your Clients. The window has three primary sections:  The link between a Fileset and a Client, or client Group, is called an Association. In order to distribute the contents of a Fileset, you *associate* a Fileset to a Client or Group. ## Basic Association Workflow The basic workflow is select a Fileset, link it to a Client/Group, the update the server model. 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 stressNote: If you want to provide custom settings for deployment times to a large number of Filesets, using a Fileset Group is the best way to achieve this goal. Filesets within Fileset Groups that are associated to Clients or Client Groups will all get the same settings you designate with the *Edit Association* pane for that Group.
## Special setting for the Requires Reboot property When you have a Fileset, such as a system software update, that requires a reboot of the client, the user may try to cancel that update to avoid the reboot. In FW 10.1+, a feature was added to the Fileset **Associations** editor window that allows you to set a deadline for the reboot. This editor property can be set for a Group of Filesets, or for a single Fileset. When the deadline comes, the device will reboot automatically in order to complete the installation of the designated Fileset.  ## Association Tools The tools and actions available to associations allow you to see the various aspects of the association: - ***Reveal Client/Group/Clone*** – This displays and highlights the Client/Group/Clone related to this association in the upper-left portion of the window. - ***Show all Associations of this Client/Group/Clone*** – This displays and highlights all associations related to the client/Group/Clone in the lower portion of window. - ***Reveal Fileset*** – This displays and highlights the Fileset in the upper-right portion of window. - ***Open Fileset*** – This displays the contents of the Fileset (same as double-clicking on Fileset in the Filesets view). - ***Open Fileset Report Window*** – This displays the report showing the status of a Fileset, Filesets, or Fileset Group's distribution. - ***Show all Associations of this Fileset*** – This displays all of the Clients associated with this Fileset - ***Delete Association(s)*** – This removes the linkage between the Client/Group and the Fileset. In most cases, this will result in the Fileset contents being removed from the Client/Group. With VPP managed distribution, the license is revoked and added back to the list of available licenses. ## Association Conflict Resolution The algorithm for computing which Client receive which associations is quite complex. As a result, you may end up "double associating" a Fileset to a Client (e.g. if it is cloned into two Groups, both Groups are associated with the same Fileset). We have solved this issue by allowing only one Association-Fileset-Client chain. A Fileset can only be associated to a client via one Association. The chosen Association's commands will be followed, and all other associations ignored. The "winner" association is determined by *association* *distance*. ## Association Distance The FileWave Server resolves conflicting associations by choosing the most direct association. For example, an association directly from a Fileset to a Client is more direct than to its Group, and an association to a Client's direct parent is closer than an association to its grandparent. Clones also increase distance. **Closer** associations always win. **Equidistant** Associations are treated by ID-descending, meaning that new associations (higher ID numbers) beat older ones. This is discussed further in [Fileset Association types and precedence](https://kb.filewave.com/books/filesets-payloads/page/fileset-association-types-and-precedence "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](https://kb.filewave.com/books/network-imaging-ivs "Network Imaging / IVS"). # Fileset Association types and precedence There are several ways Filesets may be associated with devices, and the method used will affect activation. This article shares example associations.It does not matter if this is an Association or a Deployment. Each client has one manifest and the below rules apply, however the link between Fileset and Client is established.
## 1:1 Associations These are direct associations between a Fileset and a device (or clone) ## Standard Association Automatically installed without user intervention  In the above image, one Fileset is associated directly with this device; **Type – Standard** ## Kiosk Associations User initiated installation from the Kiosk Menu Item or System Tray.  In the above image, one Fileset is associated directly with this device; **Type – Kiosk** ## Group Based Associations These are associations between a Fileset and a Client Group. The below image shows the same Fileset associated with two different client groups; one group nested inside another group.  This example demonstrates the Keynote Fileset associated with two Client Groups: Test Group and Nested Test Group. Expected behavior: - Client 'Hilda' will install Keynote without user intervention - Client 'FileWave Support - C02DNSB8Q6L4' will have Keynote available to the user via the Kiosk. The below image provides another more complex example, with more nested groups.  Excel Fileset is associated with three groups: Test Group, Nested Test Group, and Double Nested Test Group. Expected behavior: - Client 'FileWave Support - C02DNSB8Q6L4' will have Excel available via Kiosk. - Client 'James Big Sur 11.2.1', 'Andrew\_macOS\_BigSur' and 'Hilda' will install Excel without user intervention. ## Association Distance Where the same Fileset is associated to a device by more than one path, the device's 'closest' association should win. - Direct Association to devices is closer than a Direct Association to a Clone - Association to a parent group is closer than one if its nested groups - Association to a group is closer than a Clone within that group. Each association is given a score.| Association to... | Score |
| Device | 0 |
| Device Clone | 1 |
| Static/Smart Group | 2 |
| Clone of Static/Smart Group | 2 |
| 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 |
| [](https://kb.filewave.com/uploads/images/gallery/2023-07/2Pyn3vK0VBevFXqE-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/IYO7eI43VFKhQVUg-image.png) |
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: [](https://kb.filewave.com/uploads/images/gallery/2023-07/8uEfcfapMo7iRsYI-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: [](https://kb.filewave.com/uploads/images/gallery/2023-07/qf8cdcSh2aeNIUfM-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:| [](https://kb.filewave.com/uploads/images/gallery/2023-07/q8VXsEOqgTH82eD5-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/imMVbfANNWCB6I2H-image.png) |
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.
### Fileset Timings Deployment timing options show as: [](https://kb.filewave.com/uploads/images/gallery/2023-07/GwnGhI18t2O41l1I-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: - A temporary Deployment would be created to move the Fileset into, returning the Fileset back once re-activation is approved - A permanent new Deployment is created and this one Fileset will now only live within this one new Deployment thereafter - Another Deployment will be created, but the new Deployment will be 'closer' to the target device(s) and set as inactive, until re-activation is required and this new Deployment may then be deleted Associations are handled individually, as such the current association timing may be changed without any other concerns. ### Revisions Each Fileset may have multiple Revisions, but why is this beneficial? Consider the question 'How and, more importantly, when is one Revision going to replace another?' - Associations may have differing Revisions of the same Fileset Associated to the same group of devices - Deployments can only handle a single assignment of a Fileset, regardless of Revisions #### Kiosk By supplying multiple revisions to the Kiosk, users can have the ability to choose between Revisions. With Deployments, a new Deployment would have to be created to allow for each alternate Revision, whilst with Associations, all chosen Revisions may be associated to the same Client Group. #### Timed Revision Updates It is often desirable to transition between two Revisions at a chosen time, for example, out or hours. Achieving this with Associations is much neater. The same group that already has the current Association will receive the Association to the new revision. Within each Association, the time would be altered, one set as Delete and the other set as Activate. When that point in time is reached, the magic happens and the Revision on the devices is replaced. As an example, below are 2 Associations of the macOS EyeBrowse App, both to the All macOS group, but the current version 1.0 is set for Deletion at the same time that version 2.0 is set for Activation. [](https://kb.filewave.com/uploads/images/gallery/2023-07/iUoaOmF3TuSrgbMa-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: [](https://kb.filewave.com/uploads/images/gallery/2023-07/ayDC8ttTwiNl73S6-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 |
| [](https://kb.filewave.com/uploads/images/gallery/2023-07/0Kh8yrdCCDb60mtq-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/KX5haDWhrCG7mLuJ-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/OEgCPOLzTwGpMoRs-image.png) |
| [](https://kb.filewave.com/uploads/images/gallery/2023-07/7fFuz4qpiHZZf4H5-image.png) | [](https://kb.filewave.com/uploads/images/gallery/2023-07/Co5iLxSmxDLASsQK-image.png) |
Pro Tip: FIltering by “Type” being Kiosk or Standard is a great way of isolating like elements for combining associations into deployments.
# Should I create one, or multiple Deployments? ## What We have established in the previous article that you can combine any payloads or destinations into the same deployment if all of the metadata would be the same. For example, I want to deploy Firefox and Chrome to the IT and HR departments starting on Friday at 6 PM. Everything matches, so I can put them in the same deployment…but, should I? ## When/Why We’ll want to very carefully think about how we intend to organize our deployments, and how we’ll want to modify them in future before we can answer the above question. ## How But the answer to the question is “it depends”. It depends on what is easiest for you, the FileWave administrator. Primarily you’ll want to organize deployments based on the payload(s), or based on the destination(s), but not both at the same time. Other key differentiators are going to be the method of delivery (i.e. push vs. pull) and the platform. An example (always) works best: Let’s consider the following table of overall payloads/destinations…| **Payload (Filesets)** | **Destination (Devices)** |
| Google Chrome - PC (Push) | All Windows Devices |
| Google Chrome - macOS (Push) | All macOS Devices |
| Firefox - PC (Kiosk) | All WIndows Devices |
| Firefox - macOS (Kiosk) | All macOS Devices |
| Adobe Acrobat Reader - PC (Push) | All Windows Devices |
| Adobe Acrobat Reader - macOS (Push) | All macOS Devices |
| TeamViewer Host - PC (Push) | All Windows Devices |
| TeamViewer Host - macOS (Push) | All macOS Devices |
Remember: Conversion of association(s) REPLACES them with a deployment. Always test and convert slowly to ensure you get the behavior you expect.
# Resolving Conflicts in Associations Conversion ## What The guidance we have given in other articles is about making sure metadata matches when converting associations. But sometimes, we need to convert items that don’t match in order to “fix” them. This article covers how “conflicts” are handled within conversion. ## When/Why We’ll use the conflict resolution tool to resolve conflicts, and to preview the impact of those conflict resolutions before save to ensure we make the changes we intend. The most likely conflicts are: - changing from Kiosk to Standard deployment (or vice versa) - having more than one target (not technically a conflict, but important to understand) - differences in timing options - differing payload revisions ## How Resolving the conflicts is quite straightforward. Examples are shown below, with corresponding previews that show the changes:| **Conflict Type** | |
| **Conflicting Installation Type** | [](https://kb.filewave.com/uploads/images/gallery/2023-07/4ylnhQjKXctFdw3r-image.png) Note that you have to choose which installation type you want to have before you can preview |
| [](https://kb.filewave.com/uploads/images/gallery/2023-07/iXHgZg4uex0VHthO-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) [](https://kb.filewave.com/uploads/images/gallery/2023-07/E14NGBcOcXWYFgZ5-image.png) Notice though that in preview, we see the “added” payloads to the corresponding groups. |
| **Differences in Timing** | [](https://kb.filewave.com/uploads/images/gallery/2023-07/EEa5AUgVf7edCWPA-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. [](https://kb.filewave.com/uploads/images/gallery/2023-07/41pMy8n5jv6Eyvaq-image.png) Note that timing option changes will show in preview too. |
| **Differing Payload (Fileset) Revisions** | [](https://kb.filewave.com/uploads/images/gallery/2023-07/2ajpsAbFE0x3L22S-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. [](https://kb.filewave.com/uploads/images/gallery/2023-07/gWFf7xQiQsUVE2yY-image.png) In preview then, you will see the changed revision. |
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](https://kb.filewave.com/books/filewave-anywhere-help-menus/chapter/view-deployments "View - Deployments") articles to see how one creates a deployment from scratch, but in the below articles you’ll also see how to use our Associations to Deployments Conversion Tool to create deployments from multiple associations and also look at the benefits of Deployments overall. # Deployments in FileWave Central (v15+) ## What FileWave Deployments (the next generation of *Associations*) are now fully implemented in FileWave Central for creation, edit and deletion. ## When/Why We’ll use a FileWave Deployment to assign content to devices, Deployments are like associations, except the metadata (rules about assignment) are stored within the deployment. This makes it very easy to add yet another app to a deployment, and have it automatically have the same settings as others (available via Kiosk automatically as an example). ## How Deployments work almost identically in FIleWave Central to how they do in FileWave Anywhere, so you might want to check out those detailed articles linked below. Deployments have three steps. Step 1 allows you to Target and Exclude devices…Step 1 defines who gets “the stuff”: [](https://kb.filewave.com/uploads/images/gallery/2023-07/AgU1YRGXS9HYesT3-image.png) Step 2 allows you to define “the stuff” that the Targets (devices) get: [](https://kb.filewave.com/uploads/images/gallery/2023-07/9VSe7N8xMBi7Bhaq-image.png) And Step 3 allows you to set options for the Deployment. In this case, we’ll publish these filesets to the kiosk: [](https://kb.filewave.com/uploads/images/gallery/2023-07/CjxrRXHckFeRQFND-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.   - ***Duplicate*** – You can take a fully-configured Fileset and create an exact Clone with the suffix "copy." This should be done whenever you want to assign a Fileset to more than one administrator for different deployment options, or when using VPP tokens that require different licenses assigned to the same content. - ***Show all Associations of this Fileset*** – This will take you to the **Associations** pane where you can view the Fileset and its assigned Clients. - ***Create Association*** – This brings up a searchable list of Clients to associate with the Fileset. - ***Rename*** – This allows you to change the name of the Fileset after it has been created. - ***Comment*** – This allows you to add a comment that will show in the Fileset view to assist you in managing and keeping track of your Filesets. - ***Delete*** – This deletes the selected Fileset from the database. - ***Set Permissions*** – This allows you to specify the access level of your administrators to a given Fileset or Fileset Group. # Fileset (Payload) Status in Inventory ## What It has long been possible to compile "FileSet Reports" in the FileSet view within the FileWave admin, but it was not possible previously to create Inventory Queries (Reports) using the same info. With FileWave 14.5+, this issue is resolved, and more traditional reports can now be created in the Native and WebAdmin consoles. ## When/Why We'll want to use these new inventory fields whenever we want to report on deployment status. For instance, a report can be used to feed data to the integrated Grafana dashboard, or we may simply want a report of only Office 365 failures. ## How For any new report, you can utilize the data elements shown below for "Fileset deployment status". In the example shown, we are specifically choosing to look at all failures generally, but this report could also be fileset/payload specific of course.  And the report itself:  # Fileset Reports When you select a Fileset, Filesets, or Fileset Group, you can select the **Report** toolbar button to see the status of the selected item(s).  The report will show the Clients that have been associated with the Fileset, the version of the Fileset that is present on the client, its status as to whether it has been installed or is available, and the date-time group of when the Client reported the Fileset as active. The report can be exported in CSV format. If the Fileset includes an installer, such as a .pkg or .msi Fileset, you can review the installer log for that installation. You can also select the Client and force a re-install of the Fileset. # Custom MSI installer parameters ## What Starting with FileWave 15.2.0 it is now possible to add custom parameters to MSI Filesets. This includes Filesets created by MSI files, but not Filesets automatically created based on Windows software updates. ## When/Why Some MSI installers accept custom parameters that will change the way software is installed. For example, many MSI installers allow the software installation path to be defined via an additional option at runtime. Two such examples are:| **Application** | **Instal Path** |
| UltraEdit | TARGETDIR="<my-desired.path>" |
| 7Zip | INSTALLDIR="<my-desired.path>" |
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. [](https://kb.filewave.com/uploads/images/gallery/2023-11/GwnMjpIoK9kaX6GB-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,CUSTOMCONFIGDThe 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)* |
| Count | Argument |
| 1 | /s |
| 2 | /name=MyOrg |
| 3 | /reg |
| 4 | ABC123 |
| Count | Argument |
| 1 | /s |
| 2 | /name="My |
| 3 | Org" |
| 4 | /reg |
| 5 | ABC123 |
| 6 | /l |
| 7 | "c:\\windows\\temp\\My |
| 8 | App\\install.log" |
You do not have to use fileset revisions. If you ignore revisions, filesets continue to work the way they always have. When you do need staged application updates or controlled testing, revisions can make that workflow cleaner.
## Related Content - [Associating a Fileset Revision](https://kb.filewave.com/books/filesets-payloads/page/associating-a-fileset-revision "Associating a Fileset Revision") - [Editing Filesets that have Revisions](https://kb.filewave.com/books/filesets-payloads/page/editing-filesets-that-have-revisions "Editing Filesets that have Revisions") - [Managing Revisions](https://kb.filewave.com/books/filesets-payloads/page/managing-revisions "Managing 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 - ["Default" Revisions](https://kb.filewave.com/books/filesets-payloads/page/default-revisions ""Default" Revisions") - [Associating a Fileset Revision](https://kb.filewave.com/books/filesets-payloads/page/associating-a-fileset-revision "Associating a Fileset Revision") - [Editing Filesets that have Revisions](https://kb.filewave.com/books/filesets-payloads/page/editing-filesets-that-have-revisions "Editing Filesets that have Revisions") - [Managing Revisions](https://kb.filewave.com/books/filesets-payloads/page/managing-revisions "Managing Revisions") # Editing Filesets that have Revisions ## What Of course from time to time you want to edit your pre-existing filesets. How does editing a fileset change if you have multiple revisions? ## When/Why Assume again that we have a Firefox fileset that has two revisions...one v79 and the other v80. Assume that we want to change a file in the v80 fileset, or even change a file in both. How do we know which fileset revision we are changing? ## How In both the fileset editor and the script editor you will now see a new drop down menu that allows you to identify which revision of the fileset you are working on. See below, where we are looking at v79 in the fileset window, and v80 in the script editor:  Switching which fileset you are editing in either window is as simple as changing the value in the drop-down. And, if you just want to do filesets the same way you always have, you can safely ignore that drop-down altogether. ## Related Content - [Associating a Fileset Revision](https://kb.filewave.com/books/filesets-payloads/page/associating-a-fileset-revision "Associating a Fileset Revision") - [Editing Filesets that have Revisions](https://kb.filewave.com/books/filesets-payloads/page/editing-filesets-that-have-revisions "Editing Filesets that have Revisions") - [Managing Revisions](https://kb.filewave.com/books/filesets-payloads/page/managing-revisions "Managing 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: - Editing revisions (different from editing the contents of the revision) allows us to change the names and descriptions of revisions - Creating them allows us to create additional revisions in the current fileset - Deleting a revision, as the name implies, allows us to remove a revision from a fileset - Setting a revision as the "Default" allows us to easily deal with associations for testing and production in different ways ## How The thing that all of the options listed above have in common is they are all accessed in the same way, through the "Manage Revisions" button in the Fileset Editor, the Script Editor, or the Fileset Properties window, as shown below:  Each of the management options is detailed in the articles linked below. ## Related Content - ["Default" Revisions](https://kb.filewave.com/books/filesets-payloads/page/default-revisions ""Default" Revisions") - [Creating a New Revision](https://kb.filewave.com/books/filesets-payloads/page/creating-a-new-revision "Creating a New Revision") - [Editing Fileset Revisions](https://kb.filewave.com/books/filesets-payloads/page/editing-fileset-revisions "Editing Fileset Revisions") - [Removing/Deleting a Revision](https://kb.filewave.com/books/filesets-payloads/page/removingdeleting-a-revision "Removing/Deleting a Revision") # "Default" Revisions ## What What are default revisions? An excellent question indeed. Default revisions are a way of marking a specific revision of a Fileset as the "default", regardless of what it is called. Keep reading, and you'll see how very useful this is, and how our great developers try to make your job easier on an everyday basis. ## When/Why We are going to use our example again of v79 and v80 of Mozilla Firefox. Assume for a moment that we have v79 assigned to all devices right now in two associations as shown below:.:  If you'll look closely, you'll see that the "Production" group has an association to the revision <default> (v79) and the "Beta Testers" group is associated to v79. Effectively, this is exactly the same for both groups...v79 is installed. But, let's take a look below at what happens when we want to upgrade to v80 in the environment. ## How We aren't just going to assign v80 to all devices right away...as always, we want to test first, so with our patch testers group we'll edit their association as follows:  Once we save this association and update the model, all patch testers will get the new version. No deleting of the association or creating a new one is required. Now, assume that all testing goes well, and we are ready to release to production. Now, we could edit the association for "production", but assume for a second that we had ten such associations...would we want to edit all ten of them? In a word, no. But, if you remember, the association above to production was not v79, but rather Default v79...which means the association is just to the "default" revision of the fileset. So, we can simply edit the properties of the fileset itself and change the "default" to v80 instead.  Once we save that change, and update the model, you'll see the change reflected in the association:  And, upon next check-in, all "Production" devices will upgrade to v80.Remember, we take care of the timing of this transition between versions...so you don't have to worry about the transition timing.
## Related Content - [Managing Revisions](https://kb.filewave.com/books/filesets-payloads/page/managing-revisions "Managing Revisions") - ["Default" Revisions](https://kb.filewave.com/books/filesets-payloads/page/default-revisions ""Default" Revisions") - [Creating a New Revision](https://kb.filewave.com/books/filesets-payloads/page/creating-a-new-revision "Creating a New Revision") - [Editing Fileset Revisions](https://kb.filewave.com/books/filesets-payloads/page/editing-fileset-revisions "Editing Fileset Revisions") - [Removing/Deleting a Revision](https://kb.filewave.com/books/filesets-payloads/page/removingdeleting-a-revision "Removing/Deleting a Revision") # Creating a New Revision ## What Creating a new fileset is the same as it always has been, but in some way, shape or fashion we need the ability to create new fileset revisions before we can use them. ## When/Why Typically, we'll want to use fileset revisions whenever we expect to continually upgrade an application...so, in most cases basically. In this case, we'll look at how to create a v81 revision of Firefox. ## How Adding a new revision is done from the "Manage Revisions" view by clicking the plus icon: Note that in this case, we chose "Empty" because we don't want the files from the previous revision. But, if we had custom scripts or anything else like that, we would probably duplicate the previous revision instead. Once the revision is created, you edit it like you would any fileset.When creating a new revision, you can create it as empty, duplicate an earlier revision entirely, or duplicate only the properties of that revision:
Fileset Revisions can also be created by drag and drop operation from the file system onto an existing Fileset. You'll be prompted about making a new Fileset, or adding a revision as shown: If adding a revision, you will also be prompted about setting the default revision: 
## Related Content - [Managing Revisions](https://kb.filewave.com/books/filesets-payloads/page/managing-revisions "Managing Revisions") - ["Default" Revisions](https://kb.filewave.com/books/filesets-payloads/page/default-revisions ""Default" Revisions") - [Creating a New Revision](https://kb.filewave.com/books/filesets-payloads/page/creating-a-new-revision "Creating a New Revision") - [Editing Fileset Revisions](https://kb.filewave.com/books/filesets-payloads/page/editing-fileset-revisions "Editing Fileset Revisions") - [Removing/Deleting a Revision](https://kb.filewave.com/books/filesets-payloads/page/removingdeleting-a-revision "Removing/Deleting a Revision") # Editing Fileset Revisions ## What Revisions themselves have some properties that can be edited: namely the name and the description of the revision. ## When/Why Editing the properties of a revision is also done from the "Manage Revisions" window...we'll use it if we want to edit the name. For instance, every time the first revision is created, it is called "Initial Revision"...which is helpful to know, but not very descriptive. Below is how we change that. ## How First, we'll go into the "Manage Revisions" view for a particular fileset, then choose "Edit" with a revision selected:  There are only two fields to set, but setting them descriptively does help later when creating associations. ## Related Content| **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 |
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'. [](https://kb.filewave.com/uploads/images/gallery/2023-07/OysT2v88N7MTeqN6-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.
It is possible to script the removal instead, by way of the uninstall string. The uninstall strings are stored in the register and can be found using the following PowerShell script. The example is set to return installers with FileWave in their name: ``` # Edit the name of the string to search $Display_Name_Search = "FileWave" Get-ChildItem -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall | Get-ItemProperty | Where-Object {$_.DisplayName -match $Display_Name_Search } | Select-Object -Property DisplayName, UninstallString ``` The output might look something like: [](https://kb.filewave.com/uploads/images/gallery/2025-07/4E3HHnIDcma4eA9n-image.png) One uninstall string for FileWave Admin and another for FileWave Client. The uninstall string may then be used in a Fileset PowerShell Script. EXE on the other hand, do not have such an option. Again, if not developer supplied, one of the above generic methods would need to be considered. Likewise, registry entries would require a method for removal if required, during a disassociation of the Fileset. #### macOS PKG installers have no built-in uninstaller. In some instances, vendors will supply an uninstaller, but all of the considerations mentioned in the generic section would need to be considered. ### How to Uninstall Not so much how, but when. Many example recipes provide an uninstaller within the Fileset. As such, if the Fileset is disassociated, the uninstaller will trigger. However, this may not be ideal. For example. ##### Problem Imagine you have a self-healing Fileset for the new imaginary web app, EyeBrowse version 1.0. Let's assume, that this adds additional files in the user environment when ran. The following might be actioned: - Identify additional files - Script the removal - Add an uninstaller script within the same Fileset [](https://kb.filewave.com/uploads/images/gallery/2023-07/GsbUAraReZt3pLXf-image.png) Now consider the release of version 1.2. - Create a new Fileset, revision or duplicate the original - Edit this Fileset for the version 1.2 When transitioning between these two versions, the original Fileset should become disassociated. However, when this occurs, the uninstaller script will run, removing the identified, user specific files. This is likely to be an unwanted outcome, since the user is still using the software, the intention is for them to have a newer version. ##### Resolution What would be better is to create a Fileset Group. The group would require: - The EyeBrowse App Fileset (holding just the installer and any configuration) - The additional user data removal uninstaller Fileset - The Fileset Group is associated to devices ('EyeBrowse Associated') [](https://kb.filewave.com/uploads/images/gallery/2023-07/Kcx1fpYyYiLeBDf8-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](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.