FileWave Client

Enrolling Devices
Articles about the process to enroll devices in to FileWave.

Desktop / Laptop Client Install and Configure
Use this article to install the FileWave Client on macOS or Windows, or to build a custom installer for larger deployments.
Operating Systems Supported
macOS
Windows 10 & 11
For exact supported versions, check Downloads for the release you are deploying.
Downloading the FileWave client installer
The FileWave Client installer is available as part of the FileWave bundle for the specific operating system. The most current version, as well as selected older versions, of the installer are located on the FileWave KB in Downloads. For the computers mentioned under Legacy Support, you will need to install the most recent client supported on your OS.
You should download all installers you will need for your deployment at the same time. They can be stored on a file server, or on a flash drive in Windows format for cross-platform compatibility (macOS systems can read Windows-formatted drives without additional drivers).
Note: The installer instructions for the Linux server and Booster are also located on the same page of the web site. Server installation instructions are covered in FileWave Server Installation. There is no Linux client.
Installing the FileWave client
Client installers for both macOS and Windows use the same general dialogs. You will need to read and accept the license agreement, and you will be presented with a dialog window asking you for specific information to connect your client. Note: on some Windows computers, the FileWave Client Installer Assistant window is positioned directly behind the installer window, which you need to move to get to the Installer Assistant to complete the installation.
 
Installation Settings
Server address / port - Enter the IP address or FQDN of your FileWave server. Enter the TCP port number for the client to communicate with the server (default is 20015)
Booster address / port - If your client is going to get its Filesets from a Booster, enter the IP address or FQDN of the FileWave Booster. Enter the TCP port number for the client to communicate with the Booster (20013)
Note: More on working with FileWave Boosters in Boosters.
Use Computer Name for Client Name - this box allows you to use the device's computer name as its FileWave client name.
Client Name - enter a valid name based on any criteria you have for your deployment. It is recommended that you do not use special characters in the client name. Dashes, underscores, and slashes are ok.
Client Password / Confirm… - enter a password used by FileWave administrative connections to the client. This does not need to be a local administrator password for that device. Note: You must provide a password in order for the Remote Control/VNC relay to function.
Edit Custom Data…
The custom fields consist of a series of optional Inventory data fields that can be used to provide more detailed information on any Client. This information cannot be set in the automated installer, and must be applied manually. The information provided will be displayed as part of Client Info in the Clients pane of FileWave Central by right-clicking any client and selecting Client Info…, and it can also appear in Inventory Reports (formerly Queries).
Automating installation with a custom client installer
Manual installation works for small deployments. For larger rollouts, build a customized client installer with the connection settings already filled in:
For macOS: https://custom.filewave.com/py/custom_client_mac.py
For Windows: https://custom.filewave.com/py/custom_client_win.py
The customized macOS client is required for MDM/ADE support and must be uploaded in FileWave Central under Mobile preferences.
The form is shown on the next page.
Many fields are required.
Note: The default port setting is 20015. However, SSL is now required, and the system will automatically use port 20017 instead when 20015 is entered. Do not manually set the port to 20017. Always enter 20015, and the system will handle the SSL port change for you.
Advanced Options
The custom installer does not ask the user for any device specific information, and can be distributed through several means:
Apple's Automated Device Enrollment (ADE) uses the custom installer to enroll institutionally purchased devices automatically with your FileWave Server.
Add the custom installer to an image set when doing direct or network mass imaging.
Use a remote installation tool, such as Apple Remote Desktop, to distribute the custom installer to large numbers of existing devices.
Use a 3rd party imaging tool, such as DeployStudio, to build a custom client set.
Note: FileWave provides "recipes" of possible deployment workflows for the custom installer in the KB.

Enrolling Computer Clients into FileWave
Click the New Client toolbar icon to open the Create New Client window. Click Desktop clients to open New Client From Server, where computer clients appear after the FileWave Client on the device checks in with the FileWave Server specified in the client settings. Those settings are either entered manually during client installation or included when a custom client installer is built from the FileWave Support webpage.
For Text File see Importing Computer Clients from a File
Column Name
Notes
Name
The Client Name the computer is attempting to connect with (see Sync Computer Name)
Address
The IP address the client is connecting from. This may be the device's internal address or a NAT address if the computer is connecting from the internet.
Platform
The OS of the client; macOS or Windows
Last Connect
The last time the FileWave Client attempted to check in with the server. The default check-in interval is every 2 minutes.
Status
You will see one of three options:
New Client - A new device with a valid certificate.
Invalid Certificate - The device has no certificate, has a pre-13.1 client certificate, or has an invalid or damaged certificate.
Valid Certificate but a new Enrollment happened - The certificate is valid, but the client's identity has changed.
All three status states can be approved by selecting and adding the client.
See: What is Compatibility Mode?
You can assign clients to a group during enrollment or leave them in the root group. You can also place clones of those clients into other groups later.
To pre-assign new clients to a specific group, select Automatically add all new clients to the selected Group. If you are enrolling clients in batches, you can change this selection between batches.
Related Content
Conflict Resolution
Enrolling Mobile Devices

Mass Deploy Windows FileWave Client
Summary
One of the most irritating bumps in the road towards the administrative freedom of FileWave is installing the FileWave Client on your computers for the first time. Now that we've started using MSI-based installers, you can easily deploy the FileWave WinClient via a domain server or log-on script. This post provides materials to aid in WinClient Mass Deployment.
You can follow this method or possibly a more simple method is outlined here Deploying FileWave Client with Group Policy (GPO) from the eval guide.
Download the latest Windows FileWave Client (it's an exe in version 5.7 and up ) and WinClient Prefs Writer (link at bottom). To convert the exe into an msi installer check the conversion script
generatefwwinclientmsi.vbs.zip
This is an example on how you would run it:
cscript C:\path\generatefwwinclientmsi.vbs C:\path\FileWaveClient.exe
Edit the preferences script to include your settings. I have put in example settings -- you must put your own in and then save the file.
Before:
 
Code:
set serverName=no.server.set  
set serverAddress="no.server.address"  
set clientPassword="filewave"  
set booster1="no.booster.set"  
set booster1Port="0"  
:::  
set clientName=""
After:
Code:
set serverAddress="fwserver.filewave.us"  
set clientPassword="jelly"  
set booster1IP="fwbooster.filewave.us"  
set booster1Port="20013"  
:::  
set clientName=""
Once the script is edited, these are both ready to execute on a computer, either by log-on script or some remote activation. Make sure that the MSI installs before the preferences script runs.
If you install the Client via the command line, add the "/quiet" argument to execute a silent installation. For a comprehensive list of the available arguments for MSI's, run the MSI using the "/?" argument.
 
 
FWClientPrefsWriter.zip
668 B

Apple Notarisation and Custom PKG Installers
Description
Apple has introduced notarisation as a requirement for installation of PKGs on macOS with macOS version 10.15. Notarisation status can be determined in two ways : 
Offline: cryptographically verifying a ticket stapled to the PKG at installer creation time
Online: contacting apples servers to verify an app / installer has been notarised
Information
Custom installers for FileWave Client and Booster will be notarised starting from Version 13.2.2 and upwards, however, the notarisation ticket will not be stapled onto the PKG you download from https://custom.filewave.com at the current time, requiring 'Online' confirmation. 
Provided your macOS machines can reach the required servers outlined in https://support.apple.com/en-us/HT210060 , you can expect everything to work as normal after 10-15 minutes of downloading the custom PKG. 
Hosts
Ports
Protocol
OS
Description
Supports proxies
17.248.128.0/18
443
TCP
macOS only
Ticket delivery
—
17.250.64.0/18
443
TCP
macOS only
Ticket delivery
—
17.248.192.0/19
443
TCP
macOS only
Ticket delivery
—
Custom PKG Version 13.2.2
Version 13.2.2 Custom PKGs created prior to 4th March 2020 will not be notarised and will require re-creating if notarisation is required
Starting in FileWave 16.3, current FileWave binaries and applications are signed as FileWave (USA), Inc. (
UWMR88SA8G) instead of FileWave (Europe) Gmbh (
83S2TRZ3CS). The 
spctl examples below use an older FileWave Client 13.2.2 package, so they still show the previous signing identity. On current 16.3.x builds, expect the signer name and team identifier to reflect the newer FileWave (USA), Inc. identity.
Confirmation
The PKG may be tested for notarisation.  On macOS 10.15.x you may observe the following:
Before notarisation has been completed by Apple:
Unnotarised
% spctl -a -vvv -t install FileWaveClient_13.2.2-fw.filewave.com-20-Feb-2020.pkg
FileWaveClient_13.2.2-fw.filewave.com-20-Feb-2020.pkg: rejected
source=Unnotarized Developer ID
origin=Developer ID Installer: FileWave (Europe) Gmbh (83S2TRZ3CS)
After notarisation has been completed by Apple:
Notarised
% spctl -a -vvv -t install FileWaveClient_13.2.2-fw.filewave.com-20-Feb-2020.pkg
FileWaveClient_13.2.2-fw.filewave.com-20-Feb-2020.pkg: accepted
source=Notarized Developer ID
origin=Developer ID Installer: FileWave (Europe) Gmbh (83S2TRZ3CS)

Apple MDM Enrollment Methods
Description
Enrolling Apple devices involves the installation of an MDM Enrolment Profile.  
 
Installation may be initiated by either the user or the device.  This same distinction also applies to the linking of the enrolment.
Who starts enrollment?
Apple enrollment methods differ in who starts the process and whether management is linked to the device or the user.
Automated Device Enrollment (ADE) is device-driven. During Setup Assistant, an eligible device contacts Apple and receives the FileWave MDM enrollment profile assigned to it.
Account-driven enrollment is user-initiated. The user selects Sign In to Work or School Account in Settings or System Settings. The device then performs service discovery and organization authentication, retrieves the enrollment profile, and requires a Managed Apple Account sign-in to complete enrollment.
User vs Device Enrolment
Automated Device Enrolment links enrolment with the identity of the device; providing the maximum management options available.  The extreme opposite is Bring Your Own Device (BYOD) enrolment.  This is an example of the user's identity linking enrolment and provides the minimum amount of control.
User enrolment cryptographically separates organisational data from user data and limits many features of MDM.  Further details explained in Apple's KB:
Apple: User Enrollment and MDM
Overview
Therefore, the key methods of enrolment can be categorised as:
profile-based device enrolment
account-driven device enrolment
profile-based user enrolment
account-driven user enrolment
Enrolment Methods
Automated Device Enrolment
On startup, the device reaches out to Apple and, where associated, the Enrolment Profile is delivered to the device and installed.  The user is then prompted for authentication (if not configured for no authentication).
OTA Enrolment
This enrolment type potentially has two offerings:
User authenticates to download the Enrolment Profile and then instals the Profile manually.
An Enrolment Profile is provided to the user, for example by email, and the user manually instals the Profile.
BYOD
BYOD also could be described with two possible options:
Enrolment Profile is downloaded and then the user authenticates (deprecated, see below note)
User authenticates in Settings and then approves the subsequently downloaded Profile.
Deprecation
For current iPhone and iPad BYOD enrollment, use Account-Driven User Enrollment. Apple deprecated profile-based User Enrollment in iOS 17 and iPadOS 17 and no longer supports it in iOS 18 and iPadOS 18.
Account-Driven User Enrolment
Although these are personal devices, this enrolment method requires the user to add credentials into Settings which must be a Managed Apple ID.  Federated Authentication links a supported IdP with Apple, matching Managed Apples IDs with IdP usernames and passwords.
Federated Authentication
FileWave 15.5 and later support Account-Driven User Enrollment for iOS and iPadOS. Follow the linked FileWave workflow for the required Apple and identity configuration.
Related Content
Account-Driven User Enrolment for i(Pad)OS
Apple Automated Device Enrolment
Apple Manual Enrolment

User-Approved MDM Enrollment and Legacy Kernel Extensions (macOS)
Current scope
User-approved MDM enrollment was introduced with macOS High Sierra for security-sensitive management. Macs enrolled through Automated Device Enrollment satisfy the approval requirement without a separate user approval step.
For current deployments, identify which extension type the vendor ships before choosing a FileWave payload:
Use a System Extensions payload for modern system extensions.
Use a Kernel Extension Policy payload only when a vendor still requires a legacy kernel extension.
The detailed High Sierra examples below are retained for administrators supporting older software that still uses kernel extensions.
Apple: Enterprise management of legacy system extensions
Check the vendor's current deployment guide.
System Extension, Network Extension, Full Disk Access, and legacy Kernel Extension approvals are separate controls. Deploy only the payloads required by the installed product and test them on the macOS versions in your fleet.
Historical High Sierra kernel-extension behavior
User Approved MDM Enrolment
Currently, User Approved MDM Enrolment relies on the device being enrolled; the method of enrolment does not matter yet but will do in future releases.  At this point, the enrolment must be either:
DEP enrolment (user approval not required)
User installing the enrolment profile manually
User accepts the enrolment profile through System Preferences > Profiles:
You will notice this approval box in 10.13.2, if the method of enrolment was hidden from the user, e.g. scripted.  Devices enrolled on earlier versions and then upgraded will automatically be MDM enrolled as User Approved.
Kernel Extensions
Apple introduced a halfway house with the release of 10.13.  Apple has now released version 10.13.4 which has full implementation of this feature.
How does this affect kernel extensions?
Attempts to install a Kernel Extension with a device that is not enrolled into MDM will be greeted with the following message:
To approve the Kernel Extension will either require MDM enrolment or the user allowing the blocked Extension to run, via System Preferences > Security & Privacy > General:
What happens if I already have kernel extensions installed?
Any extension installed prior to upgrading to 10.13 High Sierra will continue to work, only newly installed kernel extensions will be affected.
Once a particular kernel extension is approved, subsequent upgrades to that kernel extension will automatically be user-approved.
Managing Kernel Extensions through MDM
Prior to version 10.13.4, there is no management beyond having the device enrolled into MDM.  However, with 10.13.4, management is now available through the Kernel Extension Policy payload, allowing extension loading without user consent when enrolled appropriately; the payload can only be delivered with MDM, to devices that are User Approved MDM Enrolled.  This could result in apps relying on kernel extensions to stop functioning properly (e.g. VPN clients, antivirus software).
As of FileWave version 12.7.0, the Kernel Extensions payload was introduced.  To allow Kernel Extensions requires either:
'Team Identifier'
Individually using the 'Kernel Extension bundle ID'.
These values are stored locally on a device after installation.  Therefore, to find these values involves installing them on a device and then reading these values from a file, e.g., for a machine that has VMware Tools installed.  One machine could have all Extensions installed prior to running the command to list all necessary Kernel Extensions.
$ sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy 'select team_id,bundle_id from kext_policy;'
EG7KH642X6|com.vmware.kext.VMwareGfx
EG7KH642X6|com.vmware.kext.vmhgfs
This lists the Team Identifier followed by the Bundle ID for two Kernel Extensions that have been added with the installation of VMware Tools.  Both have the same Team Identifier, but have differing Bundle IDs.
To just use Team Identifier, add the returned Team Identifier from the command for the Kernel Extensions you wish to approve, to the 'Allowed Team Identifiers' whtielist.  All Kernel Extensions with this Team Identifier will be whitelisted.
To only allow certain Kernel Extensions, instead use the 'Allowed Kernel Extensions' whitelist and add both Team Identifier and Bundle ID.  Note, legacy Extensions may not have a Team Identifier.  For those that don't, just supply the Bundle ID and leave the Team Identifier empty.
There is also a community of users that are adding Identifiers and Bundle IDs which could save you having to instal in advance.  
Community Kernel Extensions List
Data in this list is not checked in any way. As this is in place for security reasons and anyone can add information to this file, use with care:
Community Kernel Extensions List
Can I use User Approved Kernel Extension loading without MDM?
Yes.  This however involves booting the computer into recovery mode and using the following command:
$ spctl
See the man page for required options:
https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man8/spctl.8.html
N.B. This is stored in NVRAM.  If you reset the NVRAM, you will lose the ability to use User Approved Kernel Extension loading with this method until the steps are retraced.  A firmware password could be set to prevent unauthorized NVRAM resets.
Extensions Payload
The Extensions payload should not be confused with the Kernel Extensions payload.
https://help.apple.com/profilemanager/mac/5.4/#/apd58550e429
The Extensions payload controls those extensions visible through the Extensions System Preferences and will not affect Kernel Extensions

macOS MDM Enrollment State
DESCRIPTION
macOS devices are unique, in as much as they may be managed by both the FileWave Client and Apple's MDM process.  The MDM Enrollment State is an inventory item which shows the current state of MDM enrollment.
FileWave requires the FileWave Client for basic management of macOS devices.  MDM is an additional extra to expand the management options, as provided by Apple.  There is no MDM only option for macOS devices.
INFORMATION
MDM Enrollment State
The state is a live report of the current status of the device's enrollment; imagine if a device was initially MDM enrolled, but the enrollment profile has been subsequently removed from the device.  Status values include:
Full Enrolled – Device was MDM enrolled and all is good.  This would be usual for DEP or OTA
Server only – Devices was MDM enrolled, but the device no longer has an enrollment profile installed
Device only – Device has an MDM enrollment profile installed, yet the database has no reference of this
Undefined – Device is running a version of FileWave older than 14.3.0 or has not yet reported back its state
Not Enrolled – Device has never been MDM enrolled and is managed purely by the FileWave Client
Preliminary troubleshooting
Before contacting FileWave Support, use the state value to narrow where the mismatch is happening:
Server only: FileWave has a server-side MDM record, but the Mac no longer has the FileWave MDM enrollment profile. Check Profiles/System Settings on the Mac for the FileWave MDM profile and note whether the device was recently archived, retired, wiped, migrated, or manually modified. Removing the MDM profile normally requires an MDM command, such as when a device is archived.
Device only: The Mac still has an MDM enrollment profile, but FileWave does not have the matching server-side record. This usually means enrollment did not complete or the server record no longer matches the device. Check the profile install date, APNs topic, and the custom fields below, then re-enroll the device if the server cannot match it.
Logs: On the FileWave Server, 
/usr/local/filewave/log/filewave_django.log includes MDM communication that can help explain enrollment and profile-removal behavior. DEBUG logging only helps for future actions after it is enabled, so collect the existing server log, the profile install time from the Mac, and any recent archive/re-enrollment actions before escalating.
DIRECTIONS
A query may be used to identify devices that are not in an expected state, for example, identify devices that no longer have an Enrollment Profile installed
An example query could look something like:
Add, edit or remove criteria to meet desired reporting.
ADDITIONAL INFORMATION
To assist identifying why a device may show as 'Device Only', the following Custom Fields may be added, reporting the Server Root Cert Name and the APNs of the enrollment profile:
MDM Server Root Certificate Name
↓ macOS
Enrollment Profile APNs Topic
↓ macOS

Enrolling Mobile Devices into FileWave
Mobile devices can be imported or represented in FileWave before enrollment so administrators can prepare groups, Filesets, and Deployments in advance. Apple mobile devices—including iPhone, iPad, and Apple Vision Pro—can enroll through Automated Device Enrollment (ADE) or the supported manual mobile-enrollment workflow. Android devices use the applicable Android enrollment workflow. After enrollment, the device has the FileWave certificate and MDM profile required for management.
Web-based enrollment - Apple mobile devices
To enroll an iPhone, iPad, or Apple Vision Pro over the Internet, use the URL that points to the FileWave MDM server. In FileWave Central, the existing interface label remains Assistants > Enroll iOS Device; this mobile-enrollment workflow also applies to supported iPadOS and visionOS devices.
You can create a Web Clip with that URL embedded or copy the URL to the Clipboard and email it to your users. When they go to that URL on their mobile device, they will get instructions on how to properly enroll their device with your server. Having your FileWave server linked to your LDAP server allows the users to authenticate as themselves, instead of using a generic user account. This provides the benefit of having the user's LDAP record link its account information to the device. Another result of this is that the user can be automatically invited to link their Apple ID with your FileWave VPP service.
The user is presented with a dialog prompting to install a MDM server certificate, then enroll the device. The second step is when the user will be asked to authenticate - and this is where LDAP integration comes in handy. If not using LDAP, you need to inform users of the generic credential to use, or else they will not be able to proceed with step 2.
Once the user has completed these two steps, the device will display the new profiles that have been installed:
If the user's device is not yet a FileWave Client (no placeholder record previously created), it will need to be captured in FileWave Admin. You will go to the Clients pane, select New Client from the toolbar.
Select Enrolled Mobile Devices and you will get the list of all mobile devices that have performed an online enrollment, or have been activated by Apple Configurator:
The device(s) can be automatically added to an existing client Group, or you can manually add them to a Group, if desired. If you have devices set to be automatically added to a specific Group, then you will just see them appear as members in that Group.
Note: Unless you want all devices that enroll during a specific timeframe to end up in a designated Group, you should leave automatic placement off. You should also think about using Clones instead of the actual device client as members of any Groups. 
Automatic or Forced Enrollment - iOS
Another option for enrollment is using an embedded enrollment profile as part of a mobile device configuration. Apple Configurator allows you to import a FileWave MDM enrollment profile, which will then be used to assign the device to your FileWave MDM server.
Instructions are included here for Apple Configurator v2.2.1.
Single device enrollment
In FileWave Admin, under /Assistants/Enroll iOS Device, you select Device Enrollment:
Apple Configurator v2.2.1
Apple Configurator 2's blueprints let you record actions that can be applied to devices. You add configuration profiles and apps to blueprints, just as you would add them to a physical device. You can prepare a blueprint so it has the MDM data and supervision identify attached. Once you have the blueprint the way you want, you can apply it to a device. For detailed info on how to use Apple Configurator 2, see: http://help.apple.com/configurator/mac/2.0/
To create a blueprint, click 
 in the toolbar, select Edit Blueprints, then click on New in the bottom left corner to create a new blueprint. Perform your edits. When you finish, click Done.
AC2 allows you to configure sets of devices, re-installing iOS, setting up profiles, and assigning to an MDM server.
Apple Configurator 2 supports using an Apple VPP account to assign purchases to attached devices. You should only set this up if you are not going to be using VPP from your FileWave server to associate licensed content, or if you are going to use a separate account to apply specific core content to your iOS devices outside of any FileWave workflows.
Note: You cannot use the same VPP account token you are using on your FileWave server to distribute content!
App Store account
You can sign in to the App Store using the following:
Volume Purchase Program (VPP) account: You log in with the Apple ID associated with your VPP account or the Apple ID associated with a purchaser you specify
Your personal account: This is the iTunes account you use to purchase personal apps
WARNING: If your VPP account is already associated with another instance of Apple Configurator 2 or an MDM solution, all app assignments from those previous associations will be revoked.
Once you have enrolled your mobile devices, and added them as clients in FileWave, you should see a set of installed profiles like the ones below.
Using AC2 for direct assignment of applications allows you to preload your iOS devices with core applications without requiring user interaction. The workflow would create a layer in your deployment model that lets you preconfigure devices that will become FileWave Clients for all day-to-day operations and management; but come equipped with a starting set of tools.
Mass Enrollment for iOS
You can set up Apple Configurator for bulk enrollment of preconfigured iOS devices by using this option in the Enroll iOS Device assistant. The device must be connected to Wi-Fi already before this process will work. If not, then make sure you add a Wi-Fi profile to your Apple Configurator setup. This process is built into AC2 using the steps above, since it already supports setting up multiple devices simultaneously.
In this case, you would just download the MDM Enrollment profile, import it into Apple Configurator, and apply it to a set of iOS devices that were cloned with wireless settings, or a profile, already in place.
FileWave Enterprise App Portal for iOS
Starting with FileWave 8.5, iOS devices running iOS 7+ use a native iOS App Portal (Kiosk) instead of the web clip. iOS 8+ devices must use the App Portal. Instructions on how to deploy the App Portal are covered in Chapter 5 on mobile Filesets. When iOS devices are enrolled, they get the web clip version of the Kiosk. The new Enterprise App Portal automatically replaces the web clip and provides a more robust, responsive self-service tool.
Activation Lock Bypass
Since the introduction of iOS 7, device users have been able to enable a feature known as Activation Lock - which is linked to Find My iPhone. This feature ties a device to a specific Apple ID. In order to activate a device with an Activation Lock after a wipe or reset, the Apple ID credentials of the locking account are required. Where this can become problematical is having a 1:1 deployment where a user sets the Activation Lock on their device, then leaves without de-activating the lock. Prior to iOS 7.1, this issue was limited to unsupervised devices, since supervision inhibited the activation lock. Apple has provided a process now to supervise a device, yet still provide the activation lock - as well as a way to deactivate the lock when necessary.
FileWave Admin contains a new Assistant labeled Activation Lock Management. When an iOS device is enrolled in the FileWave MDM, its activation lock is stored in the FileWave Server.
If a device is sent a remote wipe command, the activation lock can be disabled at the same time.
These lock bypass codes are stored in the FileWave server, and remain even when the device has been un-enrolled. The information concerning devices with bypass codes is even provided in Inventory queries. Best practice is to maintain the codes for institutional devices, regardless of the device's enrollment status, as a safety measure. If the device is no longer used, or taken offline, do NOT delete the device from your FileWave database, just archive the device. Once the device has been deleted, the activation lock information is deleted also.
Note: In order to access the Activation Lock Bypass controls in FileWave Admin, you must login as the superuser (fwadmin).
You can also configure Activation lock in the ADE profile: Working with Apple’s Automated Device Enrollment (ADE)
iOS/tvOS Device Placeholders
Text File (iOS Devices from CSV)
When importing from a CSV file, FileWave Admin will ask for the CSV file first. The following fields are supported:
serial number of the iOS device;
client name; and,
comments (optional).
After opening the file, a dialog opens with the list of parsed devices, allowing you to select which devices to import. The dialog is the same as for importing text files.
Just select any devices and click Add X Clients. After doing that, the new devices will appear in the Clients view. However, there's almost no information provided for them.
It's possible to create associations and manage licenses (VPP for instance) on placeholder records the same way as if the devices had already enrolled. Update the model and any associated Filesets will be deployed automatically when the devices enroll. 
iOS Devices from ADE
A ADE account must be configured in FileWave Admin before being able to pre-import from DEP.
When importing from ADE, FileWave Admin will show the list of ADE accounts and the number of devices associated to that account that are iOS devices and whose serial number are not already used with your FileWave Server.
You check the ADE accounts from which you want to import devices, then click OK. After doing so, placeholders for all devices from the selected account will be created. You can create associations as usual, update the model, and their corresponding Filesets will be deployed when the devices enroll.
Once the device is enrolled, its name in FileWave transitions from the serial number to the actual device name. If there is a ADE naming convention, that will automatically apply. 
See Placeholders for what can be done with the imported devices
Related Content
Conflict Resolution
Enrolling Computer Clients

Enrolling Apple TV into FileWave
You can use Apple Configurator to enroll Apple TV devices into FileWave. The screenshots below show the blueprint-based workflow.
In Apple Configurator, create a new blueprint and set the target to Apple TV.
Newer Apple Configurator versions may change individual dialogs, but the overall process remains similar.
Click the Prepare icon.
The Prepare Devices dialog opens.
Click Next. Select New server... in the server selection box, then click Next.
Enter a server name and the URL for over-the-air enrollment, including the required port number at the end of the URL, then click Next. The server name is only for identification in Apple Configurator and does not need to match DNS.
If Apple Configurator can connect to the FileWave Server, it shows the trust profile and FileWave Root Certificate. For the required enrollment profile, use FileWave Admin's Enroll iOS Device assistant and download the profile from the Apple TV tab.
Click Choose... and select the enrollment profile you downloaded from FileWave Admin.
After the enrollment profile is selected, click Next. In FileWave, create a Wi-Fi profile with the SSID and password the Apple TV needs to join the wireless network. Add that Wi-Fi profile to the blueprint with Choose....
Click Next.
Select the language and diagnostic/usage-data options you want to use, then click Prepare.
The blueprint now has the required pieces and can be applied to a connected Apple TV.
Related Content
Enrolling Devices
Conflict Resolution

Importing Computer Clients from a File
You can import a "tab-delimited" text file (not a CSV file).
See Placeholders for more workflow information. Can be useful for
Network Imaging Guide
Automated Device Enrollment (ADE)
Enrolling Mobile Devices into FileWave
Working with FileWave Clients
The import location is in the Create New Client pane:
The new format looks like this:
Client Name <tab> Comment <tab> Serial or MAC
Name is mandatory
Comment is optional
Serial or MAC is optional if you are going to be adding clients that are already named later; otherwise, you must provide either a serial number or MAC address.
MAC address formats can have colons (:) between octets. For serial numbers, only capital letters (A-Z) and ordinal numbers (0-9) are allowed. Create the text file using a text editor that can save the file in plain text format with Unix or Windows line endings.
Please download the template for more details:
Windows imaging placeholder import example
For Windows imaging placeholders, put the MAC address in the 
Serial or MAC column. Do not use 
Imaging MAC Address as the column header in the import file; FileWave Central parses the placeholder identifier from 
Serial or MAC and then uses it where needed for imaging.
Example tab-delimited import file: filewave-central-placeholder-import-example.tsv
# Name	Serial or MAC	Comment
WIN11-0000	00:00:00:00:00:00	
If the optional 
Comment field is blank, keep the trailing tab at the end of the row. Without that final delimiter, Central may not parse the last empty column as expected.
When creating your own file, remember to include a header row on the first line to define the column names, just like in the template.

FileWave Client Configuration
Essential so devices can contact the FileWave Server, with optional entries, but may require altering.

FileWave Custom Installer
Why
When installing the FileWave client on computers, it is necessary for the client to know certain information, for example, the FileWave Server address, whilst other information may also be useful to include: Boosters, Booster Routing, Enabling/Disabling Remote Connections, etc.
Similarly, when installing Boosters, they also require essential information including the FieWave Server and ports.
For this reason, the FileWave Custom Builder allows details to be entered and then for Clients download an MSI or PKG ready for provisioning devices or with Boosters there is the addition of creating a Debian custom installer.
When
Each of the installers could be used manually on devices, but the custom MSI is particularly useful when imaging Windows onto devices, whilst the custom PKG achieves the zero-touch enrolment for macOS and DEP.
Information
The FilleWave Custom Installer is available via two URLs:
https://custom.filewave.com
https://custom.filewave.ch
Enter the details to match the FileWave Environment, e.g server's FQDN, Client or Booster version, etc.  Once completed, hit the 'Build' button and FileWave will create the custom installer.

Superprefs Fileset
What
When you create a Custom Client installer, the FileWave Client preferences are packaged into that installer: server name, ports, Boosters, and related client settings. That is useful for the base configuration, but one preference set is not always right for every device.
A Superprefs file lets you deploy selected FileWave Client preference changes to macOS or Windows devices after the client is installed. You can use one Superprefs Fileset for a broad change, or multiple Superprefs Filesets for different groups of devices.
Only the settings included in the Superprefs file are changed. Settings that are not included remain untouched on the client.
When to use this
Changing client logging level for troubleshooting
Adjusting Booster or communication preferences for a specific group of devices
Applying a new client preference without rebuilding and redeploying the Custom Client installer
Returning temporary troubleshooting settings back to standard values after testing
Ingredients
FileWave Clients on macOS or Windows
FileWave Superprefs Editor
FileWave Central Admin App
Create the Superprefs plist
The Superprefs Editor is installed with the FileWave Central Admin App:
macOS
/Applications/FileWave/Superprefs Editor.app
Windows
C:\Program Files (x86)\FileWave\FileWaveSuperPrefsEditor.exe
When the editor opens, it may ask you to open an existing plist. Cancel that window if you are creating a new Superprefs file.
Only settings that you add or edit in the Superprefs Editor are written into the plist. This keeps the deployment focused and avoids overwriting unrelated client preferences.
Example: set Debug Level to 99
Debug Level has three common values:
10
Standard logging (default)
99
Debug logging
101
Trace logging
To enable debug logging, open the Superprefs Editor, cancel the Finder or Explorer window if you are creating a new file, go to the Options tab, set Debug Level to 99, and save the file.
The file must be named fwcld.newprefs.plist.
The saved plist should contain only the changed key:
Dict {
    debugLevel = 99
}
Package the plist in a Fileset
The fwcld.newprefs.plist file can be placed in any reasonable path inside the Fileset. A dedicated Superprefs folder makes the purpose clear and lets you keep separate folders for different preference sets.
macOS
/usr/local/etc/Superprefs/debug/fwcld.newprefs.plist
Windows
C:\ProgramData\FileWave\Superprefs\debug\fwcld.newprefs.plist
You can add the file to an existing Fileset, but a dedicated Fileset is usually easier to target, test, and remove later.
From the FileWave Central Admin App:
Create a new Empty Fileset and name it clearly.
Open the Fileset and disable Hide unused folders.
Select or create the desired location for the plist file.
Drag fwcld.newprefs.plist from Finder or Explorer into that location in the Fileset.
Using the debug logging example for macOS, the Fileset could look like this:
When the Fileset activates on a client, Debug Level should switch to 99 and the client log should reflect the change.
Always test with one device or a small pilot group before associating the Superprefs Fileset more broadly.
For temporary troubleshooting, create a matching Superprefs Fileset that returns Debug Level to the standard value of 10 when analysis is complete.
GUI observation
Some Superprefs Editor entries are Boolean values, such as Booster Routing. Boolean entries can be set to True, set to False, or left unset. A dash means the value is not included in the Superprefs file.
The three states appear as:
False
True
Unset
Related Content
FileWave Client Configuration Settings
FileWave Fileset Types
How the FileWave Client Communicates

FileWave Client Configuration Settings
Configuration Settings are found in the Windows registry or macOS plist:
macOS: 
/usr/local/etc/fwcld.plist
Windows FileWave 15.4.2 or lower: 
HKLM\Software\FileWave\WinClient (32bit OS), 
HKLM\Software\FileWave\WOW6432\WinClient (64bit OS)
Windows FileWave 15.5.0 or higher:  
HKLM\Software\FileWave\WOW6432\WinClient 
Please refer to Creating a Superprefs Fileset to find out how to change these settings on any number of clients using a fileset.
The following list shows the default settings in the left row, describes the function and valid alternative settings (native)
Basic/Minimal Configuration
server = "no.server.set"
FileWave server IP or DNS
primaryPort = 20015
FileWave Server Port
fwPassword = ""
Encrypted FileWave Client Password - used for remote configuration through client monitor
fwUser = my.filewave.client.name
FileWave Client name (visible in FileWave Admin)
Note: The default port setting above is 20015. However, SSL is now required, and the system will automatically use port 20017 instead when 20015 is entered. Do not manually set the port to 20017. Always enter 20015, and the system will handle the SSL port change for you.
Booster configuration
booster1 = "no.booster.set"
Booster 1 IP or DNS Address - When clearing the value it should be "no.booster.set"
booster1Port = 20013
Booster 1 Port - Should be 20013 by default when defining a booster
booster2 = "no.booster.set"
Booster 2 IP or DNS Address - When clearing the value it should be "no.booster.set"
booster2Port = 0
Booster 2 Port - Should be 20013 by default when defining a booster
booster3 = "no.booster.set"
Booster 3 IP or DNS Address - When clearing the value it should be "no.booster.set"
booster3Port = 0
Booster 3 Port - Should be 20013 by default when defining a booster
booster4 = "no.booster.set"
Booster 4 IP or DNS Address - When clearing the value it should be "no.booster.set"
booster4Port = 0
Booster 4 Port - Should be 20013 by default when defining a booster
booster5 = "no.booster.set"
Booster 5 IP or DNS Address - When clearing the value it should be "no.booster.set"
booster5Port = 0
Booster 5 Port - Should be 20013 by default when defining a booster
boosterRouting = 0
When set as 1, client connects to server through boosters, only for non HTTPS traffic (e.g. except for inventory / profile deployment ) - 1 is recommended.
connectorProbeAttemptDelay = 3
Number of Seconds the client waits between trying to reach boosters
connectorProbeAttempts = 10
Number of unsuccessful connections that lead to booster being marked "offline"
TeamViewer (was Observe Client)
vncManaged = 0
Controls whether remote connection is allowed:
* Teamviewer – FileWave 14.7+
* FileWave Client (fwcld) prior to 14.8
vncPromptClient = 1
Controls whether end user is prompted to allow remote connection:
* Teamviewer – FileWave 14.7+
* FileWave Client (fwcld) prior to 14.8
Ports the client listens on
 
 
monitorPort = 20010
Client Monitor connects here, over the network
 
* Only on Filewave 15.5.x or lower
kioskPort = 20020
Kiosk / Reboot Dialog connects here, from localhost
Client behaviour
debugLevel = 10
Controls fwcld log verbosity; 10(normal),99(debug),101(trace)
fileCheckInterval = 86400
Number of seconds between verification cycles (default once every 24 hours after launch)
freeSpaceMargin = 2147483648
Minimum Number of free bytes left on disk so filesets can be deployed
setUsersFilesOwner = 1
Set ownership of Users files/folders to appropriate user
syncComputerName = 0
If set to 1, fwcld will query OS to retrieve computer name at startup, and use that as fwUser value
tickleInterval = 120
Number of seconds between attempts to contact FileWave Server for new Commands
Location Related
locationRefreshInterval = 0
If set to >0, number of seconds between querying the OS for location data
deviceState = 3
Client State, e.g.: Missing, Tracked, Untracked
denyPersonalDataCollection = 0
If set to 1, disables Location Services
Obsolete / Unused keys
testMode
desktopOwner
currentFileWaveClientName
niceTime
priority
useSSL
srvPublishPort = 20005
ZeroMQ messaging port (Deprecated from FileWave 14.8+.  Removed from FileWave server 15.0 and notifications from earlier clients (pre 14.8) will no longer work at this point)
vncRelayPort = 20030
Port used to connect towards the filewave server to forward VNC Data (Deprecated from FileWave 14.8+)
vncServerPort = 20031
Local Port VNC Data is relayed to/from (set to 5900 to use builtin VNC service)  (Deprecated from FileWave 14.8+)
booster1PublishPort = 20003
Booster 1 ZeroMQ prior to 14.8
booster2PublishPort = 0
Booster 2 ZeroMQ prior to 14.8
booster3PublishPort = 0
Booster 3 ZeroMQ prior to 14.8
booster4PublishPort = 0
Booster 4 ZeroMQ prior to 14.8
booster5PublishPort = 0
Booster 5 ZeroMQ prior to 14.8

FileWave Firewall Scripts for Windows
Summary
FileWave installers leave Windows Firewall settings untouched by default. This historical article provides scripts that add Windows Firewall rules for FileWave Windows components when needed.
FileWave 15.5 added these firewall changes to the normal client upgrade process. The script remains here as an example and as a fallback if the upgrade Fileset did not add the rule.
FileWave 16.0.0 removed the need for this rule. Use this article only for historical 15.5 firewall remediation or as an example of how to manage Windows Firewall rules with a script.
Procedure
Use the attached .bat file for FileWave 15.4.2 or earlier, or the Fileset for FileWave 15.5.x, to open the firewall for the matching executable at its standard install location. If you installed a FileWave component to a nonstandard path, update the path inside the script first.
Script for FileWave 15.4.2 or lower: fwcld-ports-15.4.2.bat
Fileset for FileWave 15.5.x: FileWave Firewall Settings 15.5.fileset.zip
The scripts allow inbound and outbound connections for the installed FileWave executables and use this basic syntax:
Windows 10 and beyond running FileWave 15.5.x:
netsh advfirewall firewall add rule name="FileWave Client" \
action=allow program="C:\Program Files\FileWave\client\fwcld.exe" \
enable=yes dir=in description="FileWave Client Inbound Access, usually only port 20010 is needed for client monitor connections"
Custom Fields
The following download contains two Custom Fields to report the firewall status of the FileWave Client, for example:
Custom Fields download:
Related Content
Default TCP and UDP Port Usage

Upgrading FileWave Clients
What
FileWave 16.4 provides an integrated upgrade workflow for supported macOS and Windows FileWave Clients that are already running FileWave Client 16.3.0 or later.
The Client Upgrades view is not a complete fleet-version report. Clients running versions earlier than 16.3.0 do not appear in Software Updates > Client Upgrades. An empty view does not prove that every managed client is current.
Choose the upgrade path by current client version
Current client version
Visibility in Client Upgrades
Required path
16.3.0 or later
Eligible for the integrated workflow and shown when an applicable upgrade is available.
Use Software Updates > Client Upgrades.
Earlier than 16.3.0
Not shown in Client Upgrades.
Deploy the applicable macOS or Windows Client Upgrade Fileset to reach at least 16.3.0, then use the integrated workflow for later upgrades.
Unsupported operating system or failed requirements
May not qualify for the target client version.
Review the target release’s platform requirements and the Upgrade Fileset result before assuming the client can be upgraded.
A client already running FileWave Client 16.3.4 appears in Client Upgrades and is eligible for the integrated 16.4.0 upgrade mechanism. Example names and IDs are shown.
Audit the fleet before trusting the upgrade view
Create an Inventory Report that returns Client Name, FileWave Client Version, Platform, OS Version, and Last Connect.
Identify every macOS and Windows client whose FileWave Client version is earlier than 16.3.0.
Deploy the applicable Client Upgrade Fileset to a representative pilot group of those legacy clients.
Confirm the clients check in and report at least version 16.3.0.
Open Software Updates > Client Upgrades and confirm the bridged clients are now eligible for the integrated mechanism.
Continue in controlled batches and rerun the inventory report until no legacy client remains unexplained.
“All Clients Up to Date” means there are no pending upgrades for clients eligible for this view. It does not include clients earlier than 16.3.0. Always reconcile the view against an inventory report before declaring the fleet upgraded.
The empty state says All Clients Up to Date, but clients earlier than 16.3.0 are outside this view and can still require the Upgrade Fileset bridge.
Schedule an integrated client upgrade
Open FileWave Central > Software Updates > Client Upgrades.
Confirm the current version and available target version for the qualifying client or group.
Start with a representative pilot group.
For a normal production upgrade, use the toolbar scheduling action or right-click the selection and choose Schedule Upgrade.
Monitor Schedule Type and Upgrade Status before extending the rollout.
Schedule an Early Access/Beta client upgrade
The toolbar scheduling button is for non-Beta upgrades. When the Server is using Early Access/Beta package sources, select the eligible client or group, right-click it, and choose Schedule Beta Upgrade.
Confirm the client is already running FileWave Client 16.3.0 or later and that an Available Beta Upgrade version is displayed.
Right-click the selected client or group.
Choose Schedule Beta Upgrade. Do not use Schedule All or Schedule Upgrade when the intended target is the Beta build.
Monitor the scheduled target and status before expanding beyond the pilot.
For an Early Access/Beta target, right-click the eligible client or group and choose Schedule Beta Upgrade. The toolbar scheduling action is for non-Beta upgrades.
Upgrade Fileset bridge for clients earlier than 16.3.0
Download the applicable macOS or Windows Client Upgrade Fileset from the target FileWave release’s Downloads page, import it into Central, and deploy it to the legacy-client scope. The FileWave 16.4 Upgrade Filesets include a client-version requirement and are skipped on clients already running 16.3.0 or later.
If the required 16.4 Upgrade Fileset does not support the legacy source version, use the FileWave 16.3 Upgrade Fileset first. After the client reaches 16.3.0 or later and checks in, manage future upgrades through Client Upgrades.
Upgrade Filesets also enforce operating-system requirements. A legacy client on an unsupported operating system may remain on its current FileWave Client version until the operating system or device is remediated.
Related content
FileWave Downloads
Enable Early Access (Beta) Package URLs
Troubleshooting Windows Client Upgrade Fileset Issues
Troubleshooting Deployment Issues with the FileWave Upgrade Fileset

Placeholders
Placeholders
Placeholders for computers and mobile devices are useful in many situations where you need to create a device FileWave has not seen yet, and pre-assign them varying content:
Import new Windows computers and assign them what image you want to put on them (see: Windows Network Imaging - PXE )
Import new devices (mac, Windows, iOS etc) and assign them custom names 
Import iOS or macOS devices and assign them custom fields so DEP can name with with variables (see: DEP Naming)
Import devices (any OS) and assign them custom fields so that smart groups can deploy pre-assigned software immediately upon enrollment
This Article will focus on a situation where you need to import devices and give them custom field values before they are enrolled. This is great for fields like:
Barcode / Asset tag
Location
Use
Warranty information like expiration date
Preparing the Files
We typically start out with one large file; A CSV/excel that looks something like this:
Serial or MAC address
Name
Barcode
Location
Use
AS5D64AS65D4
Lab-A-comp1
321654987
North Campus
Student
Q32WE1WQ3E21
Lab-A-comp2
321654988
North Campus
Student
X9C87ZX9C87ZC
Front-Desk-1
321654989
Main Office
Admin
DF9H51DF95H1
BreakRoom-A
321654990
Break Room
Faculty
We will actually need to import this file two times
To create the placeholders
To Assign the custom fields to the placeholders
Creating the Placeholders
Use the "New Client" UI to import a tab delineated version of just serial number and name column
More detailed instructions:
Windows / macOS : Importing Computer Clients from a File
iOS / tvOS : Enrolling Mobile Devices into FileWave
Create the Custom Fields and import
You can can either import the custom fields file  or follow the create step
Import Custom Fields
Download the custom field file:  FileWave Custom Fields.customfields
Open your (Assistance → Custom Fields → ) "Edit Custom Fields" UI
Press "import" Browse for file
For more see: Importing and Exporting Custom Field Files
Create Custom Fields
Create any needed custom fields and assign them to all devices, or specific devices. 
Open the custom field UI
Create Custom fields for Use, Location, barcode;
Use: Provided: Admin, Type: string, Restricted: True, Values: None (DEFAULT), Faculty, Student, Administration
Location: Provided: Admin, Type: string, Restricted: True, Values: None (Default), Site A, Site B
Barcode: Provided: Admin, Type: string, Restricted: False, Use Default Values: True (Default: None) 
Take note of the "Internal Name" from the custom fields (I.E: barcode, location, use)
More detailed instructions:
Custom Fields
Import Custom Field Values
Once the fields are created and assigned to the proper devices we need to import your file again in the custom fields UI. This time with the serial, barcode, location, use column.
You can actually have FileWave to create a sample CSV file with the proper headings by going to 
(Assistance → Custom Fields → ) "Import Custom Fields" UI
Press "Download Template"
Select the values you want to import (barcode, location and use in our case)
Specify the field to identify clients (for example Serial Number or Client Name)
Save
Edit in a spreadsheet app (excel, numbers, etc) and add the needed vales and bring it back in
Note that you can also set custom field values for placeholders manually by right-clicking if you have only a few to update

Locking Devices
What is it?
Use this article to distinguish Lock / Unlock from Lock Device. They sound similar, but they control different behavior.
The locking behavior is the same for macOS, Windows, iOS, and non-EMM Android.
Answer
Lock / Unlock
Lock binds a FileWave Client to its current model number. During a migration or update, a locked client ignores new manifests from the server until it is unlocked. See Upgrading your On-Premise FileWave Server.
Unlock allows the device to update to the latest model.
Lock Device
Lock Device locks the device screen. The user cannot use the device again until the required passcode, if present, is entered.
Additional information
When a client is locked to the current model, Kiosk is not available to the user. Kiosk can still open, but it displays a message that the user is blocked.
A locked client shows a lock icon or lock text in Client View, Device Info, and Client Monitor:

Location Tracking

Location Tracking Technologies
FileWave location reporting
FileWave location reporting is disabled by default. Before enabling it, confirm that the workflow follows your organization's privacy policy, acceptable use policy, and local requirements. Notify users in advance and test the permission prompt on each platform in scope. See Location Tracking for setup and operating guidance.
How FileWave obtains and displays location
FileWave requests location through the operating system or platform service available on each managed device. The platform decides which sources are available and how precise the reported location can be.
Map display
FileWave displays reported coordinates with map data from Thunderforest.
Platform location sources
macOS and Windows: The FileWave Client uses platform positioning sources through Qt Positioning.
Windows: Available sources are exposed through the Windows Location API and Windows privacy controls.
iOS and iPadOS: Apple Core Location supplies the location allowed by the device and user permissions.
ChromeOS: Google location services supply the location available to the managed Chromebook.
Related Content
Location Tracking

Location Tracking Setup
FileWave Location Tracking
The location reporting feature in FileWave is disabled by default. It is recommended that you; verify that this feature is in accordance with your organization’s policies and AUP (Acceptable Use Policy). Notify your end users before activating location reporting, as enabling the feature will prompt permission for access location information.
Requirements:
FileWave version 10.1+
Location Tracking Enabled - Server/Client
iOS devices require the FileWave IPA App Portal for passive tracking
All devices you want to track are already enrolled into FileWave and currently communicating properly
Supported Operating Systems:
APK Android:  4.1+
iOS 9+
macOS 10.9+
Windows 10+
ChromeOS 43+
Things to consider:
Client State.  For the items: Tracked, Missing and Untracked, the item greyed out is the active state:
Different States of Tracking
Tracked - Tracking is enabled and will update the location at different intervals
Missing - Tracking is enabled and will be updated around every two minutes. The client also sends the location immediately and does not wait for other scans to finish. For supervised iOS devices this option puts the device in Lost mode, has a message/footnote that can set in the FileWave Preferences under the Organization Info tab, and locks the iOS device. The device will become usable again once the missing mode is switched off. 
Not Tracked (DEFAULT)- No location is gathered at any time.
The FileWave IPA App Portal needs to be sent out and opened at least once before you will be prompted and allowed to gather location from the iOS device. Once it is sent out, the old FileWave App Portal that gets installed automatically with enrollment will be removed and the new one will be installed.
For any updated location from your iOS devices, the FileWave App Portal needs to be open, whether that be in the background or the currently active app.
There are two types of location tracking in FileWave, Passive Tracking, and Lost Mode. macOS, Windows, Chromebooks, and Android devices use Passive tracking to gather the location of the device without locking it down. Supervised iOS devices set to Missing mode will put the device in Lost mode, which locks down the device, making it unusable by the end user.
Lost Mode Setup (iOS macOS):
Right Click on your Supervised iOS or MDM-enrolled macOS device(s)
Select Missing from the Client State menu 
Update Model
Once the device checks in it will be in lost mode and report location.
To take it out of lost mode, select "Not Tracked" in the Client State menu
When the iOS device is in Lost Mode, do not reboot it. If the device losses Wifi, you will no longer be able to take the device out of Lost Mode since it will no longer be connecting to FileWave.
When the device is in Lost Mode, a new option in the tools menu is available, "Play Lost Mode Sound (iOS  10.3+)"
Passive Tracking Setup
This is receiving tracking data continuously. 
Check your server license to be sure you have "Allows collection of personal data:" set to Yes.
Make sure Location Services is enabled. On macOS, confirm fwGUI is allowed in Location Services before troubleshooting FileWave tracking.
iOS
macOS
Windows
Android
Prepare the clients
macOS and Windows - Be sure that "Disable Personal Data Collection" option in the client preferences of your clients is not checked.
Client Monitor is no longer a separate app. Use FileWave Central for one-device changes to "Disable personal data collection", or create a Superprefs (Creating a Superprefs Fileset) to change it in bulk.
iOS - The FileWave IPA App Portal automatically deploys to your iOS devices. This used to be manual.
FileWave 15.3+ will auto instal the latest App for you on qualifying devices.  If the App is already open, when configuring the device for tracking, it may be necessary to close and re-open the App after the device has receive the subsequent MDM commands from the Model Update.
Chromebook -  Be sure the Chrome Extension is installed and configured (See Quick Start Guide for Chromebooks)
Android (EMM)
Force enable location tracking server side
By force enabling EMM tracking you are ignoring "Allows collection of personal data" in your license. Even is the license is set to false, this will collect data.
Edit
/usr/local/filewave/django/filewave/settings_custom.py 
add 
settings.EMM['FWCLIENT_FORCE_ALL_DEVICES_TRACKING_ENABLED'] = True
Restart apache 
/usr/local/filewave/apache/bin/apachectl restart
Update Model
Force enable location services on devices (See: Force Location for EMM Android Devices)
Change the state to Normal
Right click on your macOS, Windows, Chromebook, and Android device(s)
For multiple devices use the filter options at the top of the client view, then select all
Select Normal from the "Client State" option.
Update the model
Accept any device prompts
iOS
macOS
Wait a few minutes, can potentially take up to 15 minutes. Then simply right click on your device(s) and select the Show Location(s) option to see the map below. This will be accurate within a few hundred feet for most devices.
Warning: In order to avoid legal issues concerning user location tracking, it is highly recommended that you enable location tracking only on devices when a unique user may authorize the service.
Privacy Policies: Apple/iOS and macOS – Microsoft/Windows – Google/Android
Additional OS Specific Considerations
macOS
Any user can agree to tracking, admin or not. Only an administrator can disable location services and/or FileWave's rights to location, as per Apple Inc. policy..
iOS
Any user can agree to tracking, can disable location services, and revoke FileWave's right to location, as per Apple Inc. policy.
Windows
The Windows operating system does not prompt the local user for access to location. Windows 10+ does have a location service that can be turned off.
Android (APK Client)
Upon installing or upgrading the Android FileWave Client to version 10.1 or greater, the user is requested to approve all rights an application needs. This includes location services, running in the background and several other rights.
Android (EMM Client)
A user can turn off their location tracking at anytime, but you can make a policy fileset that will Force Location for EMM Android Devices
Order of operation
It is important to note the way a client verifies it is able to ask the system for location information.
For example setting the state to "Missing" but it has a Superprefs file telling it the refresh interval is 0 See the flowchart for reference: 
Global Location Reporting Disable
If there are any reasons, legal or otherwise, that you do not wish to enable tracking on a global level within your organization, your FileWave license can be adjusted to enable personal mode. This will disable devices from sending application usage as well as location information.
To verify the current status of personal data collection. From FileWave Admin: Server Menu → "Activation Code..." → There you will see "Allow collection of personal data:" with Yes or No after it. 
To have personal data enabled or disabled on your license, please submit a support ticket with "Personal data License" in the subject.
Only tickets from authorized support agents whose names are on the support contract will be accepted to adjust license personal data settings.

How the FileWave Client Communicates
What
This article explains how the FileWave Client securely communicates with FileWave infrastructure components during enrollment and ongoing operations. It covers certificate-based authentication, transport mechanisms, and platform-specific communication flows so administrators understand what talks to what, how, and why.
A key design principle of FileWave communication is mutual TLS (mTLS), where both client and server authenticate each other using certificates issued by the FileWave Certificate Authority (CA).
When / Why
Understanding FileWave client communication is important when:
Designing network topology (firewalls, proxies, NAT, boosters, NATS)
Troubleshooting enrollment or check-in failures
Auditing security posture (certificate usage, authentication, encryption)
Explaining FileWave behavior to security or infrastructure teams
This knowledge is especially critical in modern deployments where communication is brokered through NATS rather than direct point-to-point HTTP(S) connections.
How
Enrollment
At this point, you have either installed the FileWave client onto a device manually, or the device has received the client automatically (for example via Automated Device Enrollment).
The client uses the configured server address to initiate a connection to the FileWave server.
The client downloads the FileWave CA certificate from the server.
The client generates a unique Client ID.
The client generates a Certificate Signing Request (CSR) and securely stores the private key locally.
The client sends the Client ID, device name, and CSR to the server.
The client polls the server on the tickle/heartbeat interval until a certificate is issued.
The server signs the CSR and returns a client certificate.
The client validates the returned certificate against:
Its locally stored private key
The FileWave CA certificate
The client record is created in FileWave Central:
Auto-add: The client is automatically approved and placed into the configured auto-add group.
Upgraded client: The client is automatically approved and resumes normal operation.
Manual vetting: The client remains pending in Client View → New Clients until approved.
FileWave uses mutual TLS (mTLS) from this point forward. All subsequent communication requires both the client and server to present valid certificates signed by the FileWave CA.
There is no longer a compatibility mode. Legacy documentation such as What is Compatibility Mode? applies only to historical versions and should not be used for modern deployments.
Daily Communication
The FileWave server continuously recalculates models and smart groups. As a result, a client check-in may result in new manifests even when the assigned model itself has not changed.
Modern FileWave deployments use NATS as the primary communication transport for tickle and command signaling.
macOS and Windows
Tickle (Check-in)
The tickle interval expires (configurable via Superprefs).
The client initiates communication via NATS.
A mutual TLS handshake occurs:
The server validates the client certificate.
The client validates the server certificate.
The server responds with the current model number.
If the model number matches, no model manifest is downloaded.
If the model number differs, the client downloads the updated manifest.
The client processes the manifest(s).
The client downloads required Filesets:
From the server directly or via a Booster.
The client validates the Booster certificate against the same FileWave CA.
The Booster validates the client certificate and checks revocation status (CRL).
If certificate validation fails at any stage, the TLS handshake fails and no data is transferred. The failure is reported back to the FileWave server.
Verify
A verification check-in occurs (default: every 24 hours, configurable via Superprefs).
After successful mTLS authentication:
The client verifies Fileset state
Inventory is refreshed
Files are healed according to Fileset verification settings
Verification also occurs when the client service starts (for example after a reboot) and can be triggered manually via Client Monitor, Client Info, or command line.
Android EMM
FileWave Android EMM communication is mediated through Google’s Android Management API (AMAPI).
As of FileWave 16.3, this communication follows Google's recommended API rate limit settings. This is an internal behavior change that reduces the risk of throttling and improves stability for larger Android Enterprise deployments. No administrative action or configuration change is required.
At Model Update
A single manifest is generated from all Android Policy Filesets assigned to the device.
Application assignments and permissions are included.
The manifest is sent to Google via AMAPI.
The Android device retrieves updates from Google.
Ongoing Operation
FileWave polls Google approximately every 5 minutes for device status updates.
Smart group changes trigger regeneration of manifests and updates via AMAPI.
iOS / iPadOS
FileWave communicates with Apple devices using standard MDM push and check-in mechanisms.
At Model Update
A push notification is sent to the device via Apple Push Notification service (APNs).
The device initiates a connection to the FileWave MDM server.
Updated manifest data is delivered to the device.
Ongoing Operation
The inventory interval is reached (default: 24 hours).
FileWave sends an APNs push requesting the device to check in.
The device connects to the FileWave MDM server.
Any updated manifests are delivered.
Related Content
Creating a Superprefs Fileset
Default TCP and UDP Port Usage
Configuring Inventory Preferences
Android EMM Known Issues
Digging Deeper
FileWave’s use of mutual TLS ensures that:
Only trusted clients can communicate with the server
Clients are protected from impersonation or man-in-the-middle attacks
Boosters cannot serve unauthorized devices
The introduction of NATS improves scalability and resilience by decoupling client signaling from traditional request/response patterns. This allows FileWave to efficiently handle large device fleets while maintaining strong security guarantees.
From a security perspective, FileWave’s communication model aligns well with modern Zero Trust principles: authenticate everything, encrypt everything, and assume the network is hostile by default.

Executing a Client-Side Script-Based Verification
What
The "verify" option of the fwGUI client application allows you to run a "verify" from the client programmatically.
When/Why
We are going to use this option whenever we want to get "immediate" feedback from a client.  For instance, as a post-installation script, calling a verify would immediately make the client report updated inventory rather than waiting (up to 24 hours, default) for the next "regular" verify.
How
The verification is called as a command-line option to the fwcld app on either a Windows or macOS client as follows. The first table is for FileWave 16.0.4+ and the second table is for 15.5.x and below. Please note that 16.0.0 through 16.0.3 did not have this command.
 
Windows Client
macOS Client
Path to FileWaveKiosk:
"C:\Program Files\FileWave\client\"
/usr/local/sbin/FileWave.app/Contents/MacOS/
App to call:
fwcld.exe
fwcld
Command Line options:
--verify
Sends a verification w/o user notification
--verify
Sends a verification w/o user notification
Script examples:
Windows Batch Example
@echo off
 
"C:\Program Files\FileWave\client\fwcld.exe" --verify
 
exit 0
macOS Bash Example
#!/bin/bash
 
/usr/local/bin/FileWave.app/Contents/MacOS/fwcld --verify
 
exit 0
On FileWave version 15.5.x or lower these are the paths and executables. This is being left here so to document that the command changed on Windows between 15.4.2 and 15.5.0 and then in 16.0.0 the old Kiosk was removed and so in 16.0.3 the verify command was brought in to the new Kiosk as mentioned above;
 
Windows Client
macOS Client
Path to fwGUI
"C:\Program Files\FileWave\client\kiosk\"
/usr/local/sbin/FileWave.app/Contents/Resources/
App to call:
fwGUI.exe
fwGUI.app
Command Line options:
--verify
Sends a verification (w/dialog by default...useful for troubleshooting)
--verify
Sends a verification (w/dialog by default...useful for troubleshooting)
 
--silent
Used with --verify, sends verification without user dialog
--silent
Used with --verify, sends verification without user dialog
Script examples:
Windows Batch Example (FW 15.5.x)
@echo off
 
"C:\Program Files\FileWave\client\fwGUI.exe" --verify --silent
 
exit 0
macOS Bash Example
#!/bin/bash
 
/usr/local/sbin/FileWave.app/Contents/Resources/fwGUI.app/Contents/MacOS/fwGUI --verify --silent
 
exit 0
Related Content
You can change the default 24h by adjusting the "File Check Interval" in a Superprefs - Creating a Superprefs Fileset

Inventory-only Clients
Management Mode
Management Mode controls whether a computer client is fully managed or inventory only. It has two values: Managed, which is the normal mode, and Inventory only. To change the setting, right-click the client and select Management Mode.
Inventory only
Inventory only clients still report inventory data to FileWave, but they do not install assigned Filesets except for critical Filesets. At this time, the critical Filesets are FileWave upgrade Filesets. Fileset status reports Not installed, client is inventory only when a normal Fileset is blocked by this mode.

Troubleshooting

Apple MDM Missing Enrolment Profile
What
At times, MDM may appear slow or even worse, the MDM Enrolment Profile no longer seems to be apparent, preventing MDM management until re-enrolled. 
Why
Apple observed that osquery can cause such issues, depending upon configuration.
osquery is a tool to describe a device based upon SQL and can be used by management tools or similar, e.g. Malware detection software.  It is a popular tool, as highlighted by a couple of example applications that use osquery: CrowdStrike and Microsoft Defender.
If you use ADE/DEP to enroll the macOS systems you may find that the following command restores the device's belief that it is supervised and in MDM. To run the command you must be logged in on the device as it will launch a notification to click on to re-confirm that the device should be in MDM;
sudo profiles renew -type enrollment
Information
FileWave does not use osquery, so that may appear as if devices managed by FileWave could be immune, however, since other 3rd party software may do so, FileWave device management, as with any MDM, could be impacted.
Consider testing for devices running osquery, where MDM issues may arise or MDM Enrolment Profile is no longer present.  If so, it would be recommended to communicate with the software vendor utilising osquery.  Details imply a reduction in the aggressiveness of osquery should prevent this.  Additionally, Apple were looking into mitigating against this issue.
Related Content
https://www.osquery.io/ 

Technical Bulletin 2026-004: Recover FileWave Client on macOS
Scope: Recovery installs the corrected macOS FileWave Client package that matches the FileWave Server version; it does not require a Server upgrade. Development rebuilt corrected FileWave Client packages from 15.5.0 through 16.4.0, but this procedure covers environments running the generally supported FileWave Server 16.2.x, 16.3.x, and 16.4.x release lines listed below. The corrected package may report the same Client version and revision as the affected package, so neither value alone shows whether recovery has been completed. If the FileWave Server runs a version earlier than 16.2.x, contact FileWave Support before attempting recovery. iOS, iPadOS, tvOS, visionOS, Windows, Android, ChromeOS, and Linux are not affected.
Important: Do not run the recovery command until the corrected macOS FileWave Client package has been prepared in FileWave Central using the version-specific path in Step 1. Running the command first can redeploy the affected package.
Background
Beginning July 30, 2026, macOS may block FileWave Client on managed Macs and warn that the software may be malicious.
This is a code-signing certificate issue, not malicious FileWave software or a broader security compromise. As part of a planned transition coordinated with Apple, FileWave closed its original Apple Developer account. Kiosk-related code distributed with FileWave Client for macOS had not been moved to the replacement signing certificate before that account was closed. macOS treats the affected code as untrusted and may block FileWave Client.
Because Apple MDM communication is independent of the FileWave Client connection, the FileWave Server can use the existing MDM channel to install a corrected client package on affected devices.
Does this recovery procedure apply?
This procedure covers environments running one of these supported FileWave Server versions. A corrected Client package is available to match each listed Server version:
FileWave Server release line
Server versions with matching corrected Client packages
16.2.x
16.2.1, 16.2.2, 16.2.3, 16.2.4, and 16.2.5
16.3.x
16.3.1, 16.3.2, and 16.3.4
16.4.x
16.4.0
Use the corrected Client package that matches the exact FileWave Server version, regardless of the Client versions shown in inventory. The corrected installation may continue to report the same Client version and revision as the affected installation. Use the operational checks under Validate recovery rather than those inventory values alone.
Package preparation by FileWave Server version
Where you prepare the corrected package depends on the FileWave Server version. Prepare the corrected Client package that matches the exact FileWave Server version rather than a separate package for each Client version found in inventory. Use the row that matches your Server:
FileWave Server version
Required action
Earlier than 16.2.x
Corrected Client packages were rebuilt as far back as 15.5.0, but FileWave Server release lines earlier than 16.2.x are unsupported and outside this procedure. Contact FileWave Support before attempting recovery and to plan an upgrade to a supported release.
16.2.x or 16.3.x
No FileWave Server or component upgrade is required. At FileWave Custom Packages, generate the rebuilt Client package that matches the exact FileWave Server version. Upload it in FileWave Central, then continue with the recovery script.
16.4.0
No FileWave Server or component upgrade is required. In FileWave Central, rebuild the macOS client package as version 16.4.0, then continue with the recovery script so the Server pushes the refreshed same-version package. Do not use 
custom.filewave.com for this path.
Before you begin
You need:
Administrative shell access to the FileWave Server for a self-managed environment. FileWave Hosted customers do not need shell access; FileWave Support performs the Server-side commands.
A working Apple MDM connection for the affected Macs.
Any existing macOS Client Upgrade Filesets removed from the FileWave Server. These Filesets may contain a Client package signed with the previous certificate and could redeploy the affected Client. FileWave is rebuilding them and will provide additional guidance in the coming days.
The attached 
send_reinstall_fwcld_apn.py recovery command. FileWave Hosted customers do not need to download this file; FileWave Support installs it on the Hosted Server.
The attached 
fwcheck.sh verification script when you need to validate a corrected macOS Client installer or rebuilt macOS Client Upgrade Fileset on a Mac before deployment.
A corrected macOS FileWave Client package prepared through the version-specific workflow in Step 1.
FileWave Central inventory identifying the intended target Macs by serial number and current check-in status. Do not use the reported Client version or revision alone to decide whether a Mac has already recovered.
The serial number of each target Mac, or a serial-number list, unless you deliberately intend to target every managed Mac.
Confirmation that no other administrator is running this recovery command. Run only one instance at a time.
FileWave Hosted Server checkpoint: Prepare the corrected package and identify the target Macs, then stop before Step 2 and contact FileWave Support. No Server upgrade is required for FileWave Server 16.4.0. Step 2 explains the Hosted responsibilities and execution process.
1. Prepare the corrected macOS client package
Use the path that matches the FileWave Server version. The corrected package must be ready in FileWave Central before you install or run the recovery command.
FileWave Server 16.2.x or 16.3.x
No FileWave Server or other component upgrade is required for this path.
Open FileWave Custom Packages and generate the macOS FileWave Client installer that matches the exact FileWave Server version.
Confirm that the generated package shows the Client version that matches the Server, then download the 
.pkg file. Do not reuse a previously generated or cached installer.
In FileWave Central, open Preferences → Mobile → macOS.
Upload the corrected installer.
Keep the upload dialog open until FileWave Central indicates that the upload is complete. Do not close the dialog before this confirmation appears.
Close the upload dialog and save the preference change.
If you happen to open the downloaded package: macOS may display “Apple could not verify … is free of malware.” For a freshly generated Custom Package, this normally means Apple's online notarization is still pending; it does not mean the package is malicious. You do not need to open the package before uploading it. This dialog does not block the upload to FileWave Central: notarization is not required for FileWave MDM to deploy the PKG and is needed only if you intend to run the PKG manually. Select Done and allow Apple more time to complete notarization. Apple's service may take more than 30 minutes when request volume is high or the service is delayed. The warning remaining for longer does not indicate a problem with the package; it will become notarized when Apple finishes processing. If you try again later, the package opening without this warning confirms that the online notarization check succeeded. Do not bypass Gatekeeper. You do not need to contact FileWave Support only because this dialog remains visible. See Apple Notarisation and Custom PKG Installers.
Use one corrected Client package for the environment: the package that matches the FileWave Server version. If inventory contains Macs on different or older Client versions, do not prepare a separate package for each group. Before each recovery run, confirm that the Server-matching package is configured in FileWave Central and that every targeted Mac is intended to receive it.
FileWave Server 16.4.0
Do not use 
custom.filewave.com with a FileWave 16.4 Server.
In FileWave Central, open Preferences → Mobile → macOS and select Build macOS client package. This integrated workflow is documented under FileWave Server 16.4 or later.
Wait for the build to complete and confirm that the package is ready for enrollment as FileWave Client 16.4.0. Rebuilding refreshes the corrected package but does not change its version number.
If Central reports that the package configuration already exists
FileWave Central 16.4.0 may report “A package with the same configuration already exists.” when you select Build macOS client package.
Select OK, then select Show settings.
Record the current value of a package setting such as Heartbeat Interval, then temporarily change that value.
Select Build macOS client package again and wait for the build to finish.
Restore the original setting value and build the package once more. Wait for that final build to finish before continuing.
Do not continue to Step 2 until the corrected package is configured in FileWave Central. A corrected package rebuilt on FileWave Server 16.4.0 will still display version 16.4.0.
Validate a corrected installer or Upgrade Fileset
Use the attached 
fwcheck.sh on a Mac to validate a corrected macOS Client installer or rebuilt macOS Client Upgrade Fileset before deployment. The script accepts a 
.pkg, a 
.fileset directory, or a 
.fileset.zip archive. Its SHA-256 checksum is:
1ff7c053e1aba034f550f1bb8bc002c2faa7b015697048585dc1a2b90128670d
Run the script with 
/bin/bash and quote the path to the artifact:
/bin/bash ~/Downloads/fwcheck.sh "/path/to/FileWave Client.pkg"
For an Upgrade Fileset, use either the 
.fileset directory or its ZIP archive:
/bin/bash ~/Downloads/fwcheck.sh "/path/to/FileWave_Upgrade_Fileset_macOS_<version>_<rev>.fileset"
/bin/bash ~/Downloads/fwcheck.sh "/path/to/FileWave_Upgrade_Fileset_macOS_<version>_<rev>.fileset.zip"
The artifact meets the FileWave macOS signing remediation policy only when the script exits with status 
0 and ends with:
PASS - meets FileWave macOS signing remediation policy FW-SIGNING-1
       (fwcheck 2026.08.02.1).
Exit status 
1 means the artifact is outdated or invalid; do not deploy it. Generate or rebuild the corrected artifact and run the check again. Exit status 
2 means the input is unsupported or the check could not be completed; confirm the path and file type, then rerun the check on macOS.
fwcheck.sh validates the installer or Fileset artifact before deployment. It does not inspect an already-installed FileWave Client. After deployment, use the checks under Validate recovery to confirm the Client is operating normally on the Mac.
2. Install the recovery command on the FileWave Server
FileWave Hosted customers: After the applicable package-preparation path in Step 1 is complete, identify the intended target devices and contact FileWave Support. Reference Technical Bulletin 2026-004. FileWave Support must install and run the recovery command on the Hosted Server, including the dry run in Step 3 and the approved execution in Step 4. Review the dry-run device count and serial numbers with Support before the command is executed. Afterward, complete the Validate recovery checks in this article.
For a self-managed FileWave Server, run the following one-line command on the Server. It works on macOS and Debian 12 or 13. The command confirms that the FileWave Server management entry point exists, downloads the attached script over HTTPS, verifies its SHA-256 checksum using 
sha256sum or 
shasum, determines the root account's platform-specific primary group (
wheel on macOS or 
root on Debian), creates the custom-command directory if needed, and installs the file with the correct ownership, permissions, path, and filename only after the checksum matches.
sudo sh -c 'set -eu; url="https://kb.filewave.com/attachments/544"; expected="1c16f0375f6c67749bc5012b92e809c6d0a2f2c55e384d1a77bcfd139266efc2"; base="/usr/local/filewave/django"; manage="$base/manage.pyc"; command_dir="$base/filewave/management/commands"; dest="$command_dir/send_reinstall_fwcld_apn.py"; [ -f "$manage" ] || { printf "FileWave Server management entry point not found: %s\n" "$manage" >&2; exit 1; }; tmp=$(mktemp); cleanup() { rm -f "$tmp"; }; trap cleanup EXIT HUP INT TERM; command -v curl >/dev/null 2>&1 || { echo "curl is required." >&2; exit 1; }; curl -fsSL --proto "=https" --tlsv1.2 "$url" -o "$tmp"; if command -v sha256sum >/dev/null 2>&1; then actual=$(sha256sum "$tmp"); elif command -v shasum >/dev/null 2>&1; then actual=$(shasum -a 256 "$tmp"); else echo "sha256sum or shasum is required." >&2; exit 1; fi; actual=${actual%% *}; [ "$actual" = "$expected" ] || { printf "Checksum mismatch: expected %s, got %s\n" "$expected" "$actual" >&2; exit 1; }; root_group=$(id -gn root); install -d -o root -g "$root_group" -m 0755 "$command_dir"; install -o root -g "$root_group" -m 0644 "$tmp" "$dest"; printf "Installed %s (SHA-256 %s)\n" "$dest" "$actual"'
If you are already signed in as 
root on a Debian server where 
sudo is not installed, omit the leading 
sudo. The command exits without installing the file if the download fails or the checksum does not match. A successful run prints the installed path and verified SHA-256 value.
3. Preview the target devices
Run a dry run before queuing anything. A dry run lists matching devices but does not create commands or send APNs. Preview with the same targeting option you plan to use in Step 4. 
--serial or 
--serial-file is the normal path; use 
--all only when you deliberately intend to review every managed MDM Mac.
Targeting check: The recovery command does not filter Macs by their current FileWave Client version or revision. Compare the dry-run serial numbers with FileWave Central inventory and confirm that the corrected package matching the FileWave Server version is configured in Preferences → Mobile → macOS and is intended for every target Mac. Do not exclude a Mac based only on its reported version or revision.
Preview a single Mac by serial number
sudo /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc send_reinstall_fwcld_apn --dry-run --serial SERIAL_NUMBER
Preview Macs from a serial-number file
Create a text file containing one serial number per line, then run:
sudo /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc send_reinstall_fwcld_apn --dry-run --serial-file /path/to/serials.txt
Preview every managed MDM Mac
sudo /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc send_reinstall_fwcld_apn --dry-run --all
Review the output and confirm that the device count and serial numbers match your intended scope.
4. Queue the corrected client installation
Target the smallest scope that covers the affected Macs. For staged recovery, use 
--serial or 
--serial-file. The configured corrected Client package should match the FileWave Server version. If inventory contains Macs on different Client versions, do not switch package versions between groups; instead, confirm that each target Mac is intended to receive the Server-matching package. Reserve 
--all for when every returned Mac should receive that one configured package, and only after validating the dry-run results.
To target a single Mac:
sudo /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc send_reinstall_fwcld_apn --serial SERIAL_NUMBER
To target a list of Macs:
sudo /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc send_reinstall_fwcld_apn --serial-file /path/to/serials.txt
To target every managed MDM Mac returned by the command:
--all deploys the one package currently configured in FileWave Central to every managed MDM Mac returned by the command. This can include Macs running another Client version or Macs that have already received a corrected package. Use it only when deploying that configured package across the full returned scope is deliberate.
sudo /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc send_reinstall_fwcld_apn --all
Use only one targeting option at a time. The script requires 
--all, 
--serial, or 
--serial-file so that it cannot target devices accidentally without an explicit scope.
What the command does
The command:
Finds managed macOS devices matching the selected scope.
Queues an 
InstallApplication command for the FileWave Client package currently configured under Preferences → Mobile → macOS.
Commits all queued commands to the database.
Sends an APN to each selected device through its existing Apple MDM connection.
APNs are sent one device at a time with a brief pause between devices. Large fleets can take significant time to process. If an APN fails for a device, the installation command remains queued and can be received at that device's next natural MDM check-in.
Validate recovery
After the command completes:
Allow online devices time to receive the MDM command and install the corrected package.
In FileWave Central, confirm that recovered Macs resume normal FileWave Client check-ins.
On representative Macs, confirm FileWave Client starts normally and the macOS blocking warning no longer appears.
If your organization uses Kiosk, confirm Kiosk opens normally on a representative device.
On representative Macs, run this command to read the Apple Developer Team Identifier from the installed Kiosk component:
codesign -v -d "/usr/local/sbin/FileWave.app/Contents/MacOS/FileWave Kiosk.app" 2>&1 | grep "TeamIdentifier" | awk -F "=" '{print $2}'
The corrected Kiosk component returns:
UWMR88SA8G
If the command returns a different Team Identifier or no output, the corrected Kiosk component is not confirmed; reinstall the corrected Client package and validate again. If it returns 
UWMR88SA8G but the macOS warning remains, restart the Mac once and check again.
This command reads the signing identity from the Kiosk component. It does not rely on the Client build number or revision and does not perform a deep validation of the full application bundle.
The corrected package may report the same Client version and revision as the affected package. A matching inventory value therefore does not confirm recovery; use the operational and signing-identity checks above.
Troubleshooting
No matching device. Verify the serial number, confirm the device is macOS, and confirm it is enrolled through Apple MDM.
No InstallApplication commands queued. The matching device may not have a linked MDM client. Confirm its MDM enrollment and contact FileWave Support if needed.
macOS reports an 
INS@...: No such file or directory install path. This is the temporary filename used internally by macOS 
install; it means the destination command directory did not exist. Rerun the current one-line installation command, which verifies the FileWave Server management entry point and creates the command directory before installing the file.
APN failures are reported. The installation command is already queued. Allow the device to check in naturally or contact FileWave Support for help with the MDM push. Do not repeatedly run the recovery command without first reviewing the device's command queue.
The blocking warning persists after recovery. Confirm that the package configured under Preferences → Mobile → macOS is the corrected installer, not a cached or previously generated package.
A recovered Mac still reports the same Client version or revision. This is expected because rebuilding the corrected package does not necessarily change either value. Confirm normal Client check-ins, normal Client and Kiosk operation, and the absence of the macOS blocking warning.
You ran the command before preparing the corrected package. Stop and contact FileWave Support before continuing.
Optional cleanup
After all affected Macs have recovered and you no longer need the command, remove the management-command file from the FileWave Server:
sudo rm /usr/local/filewave/django/filewave/management/commands/send_reinstall_fwcld_apn.py
Keep the downloaded attachment with your incident records if your organization requires it.

Clearing FileWave Client Certs
In some situations, you may want to explicitly make the server clear and revoke a client certificate without deleting the client from FileWave, for instance if you are wiping a macOS client or reinstalling an IVS client.
From FileWave Central
For desktop clients, you can right-click the client and choose "Clear Certificate(s)".
Note that the current administrator needs to have write permissions on the clients, and will need to enter credentials.
From the Client
The first way is to use the client (13.1.1) certificate itself to authenticate, which is only possible if the certificate and its private key still exist on the client: 
On macOS, the FileWave Client binary is normally located at 
/usr/local/bin/fwcld. The examples below use the full path so they can be copied into scripts more reliably.
/usr/local/bin/fwcld -clearCertificate [-serverHost <fwserver_address> -serverPort 20445]
This is the equivalent of the following command using curl (replace <fwserver_address> with the address of your FileWave server):
sudo curl --key /private/var/FileWave/client.key --cert /private/var/FileWave/client.crt -X POST https://<fwserver_address>:20445/auth/client/clear_certificate
The client will then be unable to communicate with the server (until a new CSR is created). This command can be used in the activation script of a macOS reinstall fileset to make the server properly clear the old client certificate.
What happens next: Clearing the certificate revokes the existing client identity. It does not reinstall or repair the client by itself. The device must run the FileWave Client again and create a new certificate request before it can communicate with the server. In wipe or reinstall workflows, clear the old certificate before or during the reinstall; if an existing device still cannot check in after clearing, verify the server address and trust settings, then restart or reinstall the client so it can generate and submit a new certificate request.
Note that the command above uses the client certificate itself to identify the client. In case the certificate's private key is already lost, there is an alternative where you can authenticate with an administrator's token rather than with the client certificate: 
/usr/local/bin/fwcld -clearCertificate -token <application_token> [-serverHost <fwserver_address> -serverPort <fwserver_port>]
<fwserver_address>: The FileWave server address (optional)
<fwserver_port> : 20445 by default
<application_token>: An administrator application token, with write permissions on this client. Can be found in the Application Tokens tab of the Manage Administrators dialog (example: {1ca3fe82-a41d-8866-bd4d-f83f9f1a8dd5}).
Alternatively, you can also clear certificates en masse using the inventory superadmin token. In this case, you are allowed to clear the certificate of any client (obviously use with caution):   
curl -X POST https://<fwserver_address>:20445/auth/client/clear_certificates -H 'Authorization: <application_token>' -H 'Content-Type: application/json' -d '["<serial_1>", "<serial_2>", ...]'
Included in 13.1.1 and above are the options to clear with 'MAC address' or 'Device ID':
curl -X POST https://<fwserver_address>:20445/auth/client/clear_certificates?identifier=mac -H 'Authorization: <application_token_base64>' -H 'Content-Type: application/json' -d '["<mac_address_1>", "<mac_address_2>", ...]'
curl -X POST https://<fwserver_address>:20445/auth/client/clear_certificates?identifier=device_id -H 'Authorization: <application_token_base64>' -H 'Content-Type: application/json' -d '["<device_id_1>", "<device_id_2>", ...]'
The identifier parameter is optional, its default value is serial_number.
<fwserver_address>: The FileWave server address.
<serial_1>, ...: serial numbers of clients to revoke. Must match the serial_number field from inventory.
<mac_address_1>, ...:  MAC addresses or clients to revoke.
<device_id_1>, ...: device ids of clients to revoke.
<application_token_base64>: base64-encoded value of an administrator application token, with write permission on this client. Can be found in the Application Tokens tab of the Manage Administrators dialog (example: ezFjYTNmZTgyLWE0MWQtODg2Ni1iZDRkLWY4M2Y5ZjFhOGRkNX0=_).
A dict of lists of clients for: SUCCESS, NOT_FOUND and ERROR statuses is returned.
SUCCESS: the client certificate was successfully revoked.
NOT_FOUND: no certificate was found on the server for this client, or no such client was found. Maybe the certificate was already revoked, or the client had no certificate yet, or the client had not reported its MAC address or serial number yet, if you passed a MAC address or a serial number.
ERROR: an unexpected error occurred. Please check server logs for details.
Potential log entries
2019-06-12 7:12:02.481|main|FATAL|CLIENT|Unable to retrieve the contents of the cached custom field values: Error decrypting data
2019-06-12 7:12:02.833|main|INFO|CLIENT|CRL updated
2019-06-12 7:12:02.834|main|INFO|CLIENT|No certificate private key yet. Sending a certificate signing request to server my.FQDN.com.
2019-06-12 7:12:03.235|main|FATAL|CLIENT|Failed to send enrollment request (and CSR): error 400 a CSR for this client was already sent.
2019-06-12 7:12:03.235|main|INFO|CLIENT|Falling back to no certificate.

FileWave Client notification for zsh running in the background
What
When I upgraded my FileWave Client to 15.3.0 or newer I saw a popup saying "zsh is now running in the background". 
When/Why
This happens once when first going to version 15.3.0 or higher of the client on macOS. There is nothing to do. This popup is because the FileWave client needs permission to run zsh for scripting. It can be ignored and development is going to look at ways to suppress it so that in the future it should not show, but it should only happen 1 time on each machine and then even on newer versions of the clients you should not see it because it should already have the permission.
Related Content
FileWave Version 15.3.1

Rename a FileWave Desktop Client Safely
Renaming a desktop client in FileWave Central updates its Client Name inventory field and turns off Sync Computer Name in the client preferences. This keeps the operating system's computer name from immediately replacing the FileWave name. The Device Name inventory field is not changed.
After the rename, confirm that Sync Computer Name is disabled:
Why the setting changes
The FileWave Client uses its name as part of its identity. See How the FileWave Client Communicates for the connection model.
Sync Computer Name can be changed for one device in Client Monitor or across devices with a Superprefs Fileset. The available preference is documented in FileWave Client Configuration Settings.
In FileWave Central, right-click the desktop client and select Rename. This article is scoped to desktop clients because rename behavior can differ for other device types.

FileWave Client Status Check: How to ask the client what it is doing on macOS and Windows
What
Use 
fwcld -s to ask the FileWave Client what it is currently doing on macOS or Windows. This is useful when you have local access to a device and need a quick status check without waiting for server-side inventory or logs.
When/Why
The command shows client status, Filesets in inventory, Filesets not meeting requirements, and the current worklist.
You might find this feature beneficial when:
You are diagnosing why a Fileset or profile is not applying as expected.
The FileWave Client appears stuck and you want to see its current worklist.
How
Run the command on the device you want to check:
macOS
Open the Terminal application on the macOS device.
Run: 
/usr/local/sbin/FileWave.app/Contents/MacOS/fwcld -s
Windows
Open the Command Prompt on the Windows device.
On current Windows clients, run: 
"C:\Program Files\FileWave\client\fwcld.exe" -s
After running the command, you will see output similar to the example below:
**************************
**FileWave Client Status**
**************************
User ID: 11354
Current Model Number: 660
Filesets in Inventory:
1. Fileset Mac MDM OS Update - macOS Monterey 12.6.3 12.6.3, revision ID 10148, ID 10148, revision ID 10148, version 1 - Apple MDM OS Update is not supported (0)
2. Fileset Mac MDM OS Update - Safari 16.3, revision ID 10149, ID 10149, revision ID 10149, version 1 - Apple MDM OS Update is not supported (0)
3. Fileset FileWave_macOS_Client_14.10.2_df52a47c77, revision ID 10169, ID 10169, revision ID 10169, version 1 - Active (0)
4. Fileset Profile - TeamViewerHost Allow Standard User, revision ID 10173, ID 10173, revision ID 10173, version 1 - Handled via MDM (0)
5. Fileset Profile - Microsoft  Defender - Kernel Extension, revision ID 10190, ID 10190, revision ID 10190, version 1 - Handled via MDM (0)
6. Fileset Profile - Microsoft Defender - Notifications, revision ID 10191, ID 10191, revision ID 10191, version 1 - Handled via MDM (0)
7. Fileset Profile - Microsoft Defender - Web Content Filter, revision ID 10192, ID 10192, revision ID 10192, version 1 - Handled via MDM (0)
8. Fileset Profile - Microsoft Defender - TCC, revision ID 10193, ID 10193, revision ID 10193, version 1 - Handled via MDM (0)
9. Fileset Profile - Microsoft Defender - Data Acceptance, revision ID 10194, ID 10194, revision ID 10194, version 1 - Handled via MDM (0)
10. Fileset Profile - Microsoft  Defender - System Extension, revision ID 10195, ID 10195, revision ID 10195, version 1 - Handled via MDM (0)
11. Fileset Profile - Microsoft  - Background Service, revision ID 10196, ID 10196, revision ID 10196, version 1 - Handled via MDM (0)
12. Fileset MS Defender macOS, revision ID 10197, ID 10197, revision ID 10197, version 1 - Active (0)
Filesets not meeting requirements:
Worklist:
The output provides the following information:
User ID (the FileWave device ID) and Current Model Number
Filesets currently in the device's inventory, including their status
Filesets not meeting requirements
Current worklist
Use this output to confirm what the FileWave Client is processing before you move on to logs or server-side troubleshooting.
Related Content
FileWave Log File Locations
Using PowerShell to Remotely Check the Windows FileWave Client Status

FileWave Windows Network Sweeper
What
FileWave Windows Network Sweeper is a troubleshooting bundle for finding Windows clients that are online but not communicating correctly with the FileWave Server, then attempting a targeted repair. Typical causes include misconfiguration, user intervention, or a previously failed client upgrade.
When/Why
Run this during a normal peak-online window when you want to identify Windows devices that have recently checked in but have since gone quiet. A Group Policy deployment can enforce enrollment and check-in for many environments; the Client Deployment via GPO training gives one example of that approach, and the same general pattern can support other compliance checks.
How
Start with a small test group before running the process against a large exported list.
Prerequisites
Run PowerShell as a user with administrative rights on the target Windows devices, usually a domain admin or an equivalent delegated admin account.
The devices you are trying to catch must be online and reachable on the network.
The process assumes the 
C$ admin share is reachable and that device names resolve correctly. Dynamic DNS needs to be working if you are relying on names instead of IP addresses.
Know the FileWave Server FQDN and have a valid FileWave API token available.
Download and unzip the Windows Network Sweeper bundle:
Windows Network Sweeper
PSTools is included in the download for convenience. You can also download the current PSTools package directly from Microsoft: PSTools download.
Before using the repair script broadly, confirm that the bundled 
FileWaveClient.msi is the client version you intend to install, or replace it with the correct installer for your environment. Also review the expected client version in 
3_Check_Status.ps1 before treating its status output as authoritative.
Process Overview
Create an inventory query for Windows devices that have not checked in recently. A common starting point is OS Type = Windows and Last Connected within the past 30 days but not within the past 7 days. Adjust both date ranges for your environment.
Set the query output to include Device Name only. You can export IP addresses from the client view, but avoid using IP addresses from an inventory query in DHCP-heavy environments because the address may no longer belong to the same device.
Export the query results into the 
offline.txt file included in the ZIP. View > Export Current View is useful for this. Remove the header line that says 
Device Name.
Run 
1_get_online.ps1 to test which exported devices are currently reachable. Reachable devices are written to 
online.txt.
If devices are found, run 
2_repair_clients.ps1 to attempt the repair. This script uses PSExec to copy and run 
fix_fwclient.bat on the target device.
Run 
3_Check_Status.ps1 to double-check repaired devices and identify anything that still needs manual remediation.
Related Content
Client Deployment via GPO
Creating a Superprefs Fileset
Inventory Queries (Reports)
Digging Deeper
The download contains the scripts used in this workflow. Review them before running the bundle in your environment, test against a small set of known devices first, and keep the generated 
online.txt, 
output.txt, 
double_check.txt, and 
still_bad.txt files as your working record for follow-up remediation.

PSExec as a Helper in Troubleshooting
What
Microsoft PsTools includes PsExec, a remote command-line tool that can help troubleshoot a Windows device when the FileWave Client is not responding through normal FileWave channels.
When/Why
Use PsExec when you need an interactive command prompt on a Windows client to inspect services, logs, processes, network state, or user sessions. The examples below focus on FileWave Client troubleshooting, but the same approach is useful for other Windows service issues.
How
Assumptions for the examples below:
1) You downloaded PsTools and unzipped it.
2) You launched Command Prompt as a domain admin or another account with the needed rights on the remote device.
3) You changed into the directory where PsTools is located.
Connect to the remote computer by name in an interactive PsExec shell:
psexec64 \\computername -h cmd
You should end up in a shell like the one below. Type 
exit to leave the remote shell.
From that shell, you can run normal Windows command-line tools on the remote device. These examples are useful when a Windows client is not reporting correctly.
Check the FileWave Client service:
sc query filewavewinclient
Stop the FileWave Client service:
sc stop filewavewinclient
Start the FileWave Client service:
sc start filewavewinclient
If the service will not start or stop, identify and stop the process directly:
Find the FileWave Client process.
tasklist | findstr fwcld
Kill the process by PID.
taskkill /PID 16264 /F
The same pattern can help with a stuck Windows Update agent. When Windows Update hangs and the service will not stop, 
tasklist /svc | findstr wuauserv identifies the process that owns the service. A reboot can also clear the condition, but it interrupts whoever is using the device.
Check the FileWave Client log for entries from today:
type c:\programdata\filewave\fwclient\fwcld.log | findstr mm-dd
Replace 
mm-dd with today's month and day, such as 
05-16.
Get the IP address of the workstation:
ipconfig
Restart the device immediately. This interrupts any active user session, so check before running it on a device in use.
shutdown -r -t 0 -f
Check whether other users are logged in:
quser
Get the last boot time:
Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object LastBootUpTime
Related Content
PS Tools
Windows command-line reference (SS64)
wmic deprecation

Troubleshooting Windows Client Upgrade Fileset Issues
What
The FileWave Windows Client upgrade fileset uses a more orchestrated process than a typical Windows software deployment.
For most Windows software deployments, the 
FileWaveWinClient service runs the installer as the local system account. A client upgrade has an extra challenge: it must remove the existing FileWave Client, install the updated one, and keep the process moving even though the service that normally performs installs has to be stopped and replaced.
To handle this, the upgrade fileset installs a temporary upgrade helper, creates a scheduled task, stops the existing FileWave Client service, runs the new client MSI, starts the upgraded service, and then removes the temporary upgrade pieces. This also helps the device continue the upgrade workflow and report back to FileWave when the upgrade completes.
The example above shows the main upgrade fileset components:
FileWaveWinUpgradeClient.msi: installs the temporary upgrade helper.
scheduleRestart.bat: creates the scheduled task that starts the upgrade process.
upgradeClient.bat: handles most of the upgrade workflow.
FileWaveClient.msi: installs the target FileWave Windows Client version.
When/Why
Use this article when a FileWave Windows Client upgrade fileset does not complete, the client version does not update in inventory, the Windows client service does not restart after an upgrade, or a device is left with a non-functional FileWave Client after an attempted upgrade.
If the issue is that the upgrade fileset did not import correctly, does not show the expected files, or was extracted incorrectly before deployment, start with Troubleshooting Deployment Issues with the FileWave Upgrade Fileset.
This article is also useful before a broad Windows Client upgrade rollout, because most upgrade issues are easier to find and fix during a small pilot than after the fileset has been deployed widely.
How
1. Understand the upgrade flow
The Windows Client upgrade fileset normally works in this order:
FileWaveWinUpgradeClient.msi runs first and installs a temporary upgrade helper.
scheduleRestart.bat creates the 
FileWave Client Upgrade scheduled task.
upgradeClient.bat checks the target version, disables automatic service restart during the upgrade, stops the existing 
FileWaveWinClient service, and starts the client installer.
FileWaveClient.msi installs the new FileWave Windows Client.
The upgrade process removes the scheduled task and temporary upgrade files after the installer completes.
If the old client service is hung, the upgrade script retries the stop process and may need to terminate the service process. That is expected behavior during this upgrade, but it can expose device-specific problems such as a stuck service, pending Windows Installer issue, or previous failed upgrade cleanup.
2. Collect the upgrade logs
Collect these logs before retrying the upgrade or manually cleaning up the device when possible. They are usually the fastest way to tell whether the issue is the upgrade workflow or the Windows MSI installer.
The primary logs are in 
C:\temp:
UpgradeClient.log: shows the upgrade script flow, including version checks, scheduled task behavior, service stop attempts, and cleanup.
FileWaveClientUpgraderUninstall.log: shows removal of the temporary upgrade helper.
FileWaveClient.log: verbose MSI log for the new FileWave Windows Client installer.
Also check the Windows Application log in Event Viewer for Windows Installer errors, such as 
1603 or 
1638. The normal FileWave Client log may be less useful during the upgrade because the client service is intentionally stopped as part of the process.
3. Check the common failure points
Most failed Windows Client upgrades fall into one of these categories:
The existing 
FileWaveWinClient service is hung and does not stop cleanly.
A previous failed upgrade left behind the scheduled task or temporary upgrade helper.
The new 
FileWaveClient.msi launched, but Windows Installer failed to complete the install.
The device has a local Windows issue that would also affect a manual client MSI install, such as a pending reboot, Windows Installer problem, security software interference, or an existing conflicting client install state. In some cases, Windows Installer blocks the new client install until the system restarts, and that condition is not always obvious before the upgrade starts.
If 
FileWaveClient.log shows an MSI failure, troubleshoot it as a Windows Installer/client MSI issue first. In many cases, the same failure would happen if the MSI were run manually on the device.
4. Clean up leftovers from a previous failed upgrade
Use these commands only when the logs or device state indicate that a previous failed upgrade left behind the scheduled task or temporary upgrade helper. Run them from an elevated Command Prompt.
Delete the scheduled task:
schtasks /delete /f /tn "FileWave Client Upgrade"
Remove the temporary upgrade helper:
start /wait msiexec /l*v C:\temp\FileWaveClientUpgraderUninstall.log /qn /norestart /x "{E3DC560D-C698-41DF-8B6C-EEA0BEFC44EF}"
Start the FileWave Windows Client service if it is installed and should be running:
sc start filewavewinclient
After cleanup, retry the upgrade on the affected device or move the device back into a small test group before attempting broader deployment.
5. Isolate MSI installer issues
On a device that has not yet completed the upgrade, run the full 
FileWaveClient.msi manually to test the installer outside of the upgrade fileset workflow.
This removes the scheduled task, temporary helper, and service-stop logic from the test. If the manual MSI install fails the same way, focus on the MSI error, the Windows Application log, and the device state rather than the upgrade fileset.
6. Recover a non-functional client
If the FileWave Client is no longer functional and cannot receive a normal fileset, use remote administrative tools to inspect the device, collect logs, restart services, or run cleanup commands.
For one supported approach, see PSExec as a Helper in Troubleshooting.
7. Roll out upgrades in phases
Deployment warning: Do not deploy a Windows Client upgrade fileset globally as the first test.
Start with a small pilot group. After deployment, run a Verify and confirm that inventory reports the expected FileWave Client version. If that pilot succeeds, expand to a larger test group. Move to broad deployment only after the larger group is also successful.
This takes more time up front, but it is much easier than recovering many Windows clients after a failed broad rollout.
Related Content
PSExec as a Helper in Troubleshooting
Using PsExec to Remotely Restart the FileWaveWinClient Service
Troubleshooting Deployment Issues with the FileWave Upgrade Fileset
Using Native Windows Tools to Troubleshoot

Remotely Restart the FileWave Windows Client Service with PsExec
Use Microsoft PsExec to restart the 
FileWaveWinClient service on a remote Windows device when the Client is not responding through normal FileWave commands. Common cases include a stopped or stuck service, a manual restart required during troubleshooting, or a configuration change that specifically requires the service to restart. Use normal FileWave commands first; do not treat a service restart as a routine fix for an unidentified problem.
Before you start
Download PsExec from Microsoft Sysinternals.
Use an account with local administrator rights on the target device.
Confirm that your Windows firewall, admin shares, and organization security controls permit approved remote administration.
Do not put an administrator password in the command line. The example uses the current administrator context. If an alternate account is required, add 
-u DOMAIN\User and omit the 
-p option entirely so PsExec prompts for the password without displaying it on the command line.
Open a remote shell
From an elevated Command Prompt in the PsTools folder, replace 
computername with the target Windows device:
psexec64 \\computername -h cmd
If your download contains 
PsExec.exe instead of 
PsExec64.exe, use that executable name. Type 
exit when you are finished with the remote shell.
Restart the FileWave Client service
First query the service, request the stop, and query it again:
sc.exe query FileWaveWinClient
sc.exe stop FileWaveWinClient
sc.exe query FileWaveWinClient
Continue only when 
STATE reports 
STOPPED. If the service reports 
STOP_PENDING, wait and run the query again. Do not force-kill the service from this procedure.
After the service is stopped, start it and confirm its state:
sc.exe start FileWaveWinClient
sc.exe query FileWaveWinClient
The final query should report a 
RUNNING state. Exit the remote shell, confirm that the device checks in to FileWave again, and review the Client log if it does not.
If the service does not restart
If PsExec returns Access is denied, verify the account’s rights and the remote-administration prerequisites before retrying.
If security software blocks PsExec, use your organization’s approved remote-management tool instead of weakening endpoint protection.
Review 
C:\ProgramData\FileWave\fwclient\fwcld.log for the service error.
Use 
sc.exe qc FileWaveWinClient to inspect the configured service start type and binary path. Do not change them unless troubleshooting has identified a specific configuration problem.
Related Content
PsExec as a Helper in Troubleshooting
Using PowerShell to Remotely Check the Windows FileWave Client Status
Microsoft: sc.exe query

Network Proxy, Content Filter, and SSL Inspection Troubleshooting
What
FileWave components need reliable network access to the destinations listed in Default TCP and UDP Port Usage. Depending on the workflow, that may include the FileWave Server, FileWave Boosters, FileWave cloud services, vendor services from Apple, Google, or Microsoft, licensing and notification services, remote-control services, cloud Fileset storage, or Kiosk/App Portal download locations. That traffic is encrypted. Proxies, web filters, secure web gateways, firewalls, and content filters can block or alter that traffic, which can cause the affected FileWave feature to fail even when the FileWave Server itself is working correctly.
This can happen with products such as Lightspeed Filter, GoGuardian Admin, Securly Filter, Linewize Filter, ContentKeeper, iboss, Cisco Umbrella, Zscaler Internet Access, Netskope, Fortinet/FortiGate, Palo Alto Networks, Sophos Firewall, WatchGuard, Check Point, and similar proxy or filtering systems. The exact product name is less important than the behavior: if the product blocks the required host, blocks an unknown or uncategorized URL, or performs SSL/TLS inspection on traffic that must remain end-to-end trusted, the FileWave feature that depends on that destination may not be able to communicate.
The Kiosk IPA URL 
https://fw-kiosk-v2-ipas.filewave.cloud/ is one example because blocking it can prevent Kiosk installation. The same principle applies to any FileWave address or vendor address required by the workflow and listed in the port usage article.
When/Why
Use this article when FileWave behavior changes depending on the network, filtering policy, or proxy path. Common examples include:
The FileWave Client checks in on one network but not another.
Devices stop reporting inventory or processing manifests.
The FileWave Kiosk or App Portal does not appear or does not install.
iOS/iPadOS Kiosk installation fails with an error like:
Could not validate manifest..An SSL error has occurred and a secure connection to the server cannot be made.
A content filter shows FileWave URLs as blocked, uncategorized, unknown, newly seen, or unclassified.
Security logs show a FileWave destination from Default TCP and UDP Port Usage being blocked or inspected, such as the FileWave Server hostname, 
*.filewave.cloud, 
fw-kiosk-v2-ipas.filewave.cloud, cloud Fileset storage, notification services, or Apple/Google/Microsoft service endpoints.
FileWave communication relies on encrypted, certificate-based connections. On macOS and Windows, modern FileWave Client communication uses mutual TLS for client/server trust. Apple, Google, Microsoft, and FileWave cloud services also expect valid TLS connections. If a filtering product performs SSL inspection, HTTPS inspection, TLS inspection, SSL decryption, certificate inspection, deep packet inspection, DPI, or a similar feature that replaces the remote certificate with a filtering certificate, the connection may fail because the device is no longer seeing the certificate it expects.
This is not limited to one vendor. Lightspeed is a common example in schools, and Lightspeed environments that block 
Unknown or 
Uncategorized sites may block a FileWave cloud URL until it is recategorized or explicitly allowed. Other web filters and secure web gateways can create the same symptom under different names.
How
1. Map the symptom to the FileWave feature
Before changing proxy or firewall rules, identify which FileWave feature is failing. Then use Default TCP and UDP Port Usage to find the destinations and ports used by that feature.
Symptom
Destinations to check first
Client does not check in, inventory is stale, or manifests do not process
FileWave Client, Server, and Booster destinations/ports. Make sure the device can reach the configured FileWave Server and any Booster it is expected to use.
Kiosk/App Portal does not appear or fails to install
Kiosk/App Portal destinations, the FileWave Server, 
*.filewave.cloud, and any specific Kiosk download host listed or referenced for the installed FileWave version.
Filesets do not download or install
Server/Booster traffic and, for hosted customers using cloud Filesets, the cloud Fileset storage destinations in the port article.
Remote control, notifications, license checks, version checks, AutoPkg, or Central/Anywhere features fail
The service-specific outbound destinations listed for those features in the port article.
Apple, Android, Chromebook, or Windows MDM/EMM workflows fail
The FileWave MDM/EMM ports plus the Apple, Google, or Microsoft service endpoints required by that platform.
A browser test is useful, but it is not the whole test. FileWave background services may run outside the user’s browser session, may not be able to answer a proxy authentication prompt, and may use ports or TLS behavior that a browser test does not exercise.
2. Confirm whether the filter or proxy is involved
Start by comparing a working and failing path.
Test the affected device on a network that does not use the same proxy or content filter, such as a known-good test VLAN or temporary hotspot.
Check the proxy, firewall, or web-filter logs for the affected device at the time of failure.
Look for blocked or inspected traffic to the FileWave Server hostname, FileWave Booster hostname, FileWave cloud URLs, Apple services, Google services, or Microsoft services used by the platform.
If only one network or policy fails, the issue is likely in the network path rather than the FileWave Server itself.
3. Allow the required FileWave destinations
Use Default TCP and UDP Port Usage as the source of truth. Identify which FileWave component, platform, or workflow is failing, then verify every destination and port listed for that area. A blocked Kiosk download host breaks Kiosk installation, but a blocked license, notification, remote-control, cloud Fileset, Apple, Google, Microsoft, Server, or Booster destination can break the feature that depends on that traffic.
Common destinations to review include:
The customer’s FileWave Server hostname or FQDN used by clients and enrolled devices.
Any FileWave Booster hostnames used by clients.
*.filewave.cloud
https://fw-kiosk-v2-ipas.filewave.cloud/
Hosted-customer cloud Fileset storage destinations listed in Default TCP and UDP Port Usage, when applicable.
Apple, Google, and Microsoft endpoints required for the platform being managed.
Do not rely only on a port being open. Category-based filtering can still block an allowed port if the destination is classified as unknown, uncategorized, newly registered, or otherwise not allowed by policy.
Examples: blocking the FileWave Server or Booster can break check-in, inventory, manifests, or Fileset downloads; blocking 
*.filewave.cloud or 
fw-kiosk-v2-ipas.filewave.cloud can break Kiosk/App Portal downloads; blocking cloud Fileset storage can break hosted Fileset delivery; blocking licensing, notification, TeamViewer/remote-control, AutoPkg, or version-check destinations can break those specific services; and blocking Apple, Google, or Microsoft endpoints can break platform enrollment, app management, software updates, or MDM/EMM workflows.
4. Check common proxy/filter failure patterns
Proxies and filters can break FileWave traffic in several different ways. Check for all of these, not just a simple block/allow result:
Category or reputation blocking: the destination is marked unknown, uncategorized, newly seen, or not in an allowed category.
SSL/TLS interception: the filter replaces the real certificate with its own certificate so the device no longer trusts the connection.
Authenticated proxy or captive portal requirements: browser traffic works after a user signs in, but FileWave background services cannot answer the prompt.
Transparent proxy behavior: the proxy handles normal web browsing but not FileWave service traffic, NATS, Booster traffic, or other non-browser connections.
DNS or SNI filtering: the device resolves or reaches a different path than expected, or the filter blocks based on hostname before the connection is established.
Different rules by network, VLAN, device type, user group, time, or off-site/on-site policy.
5. Bypass SSL/TLS inspection for FileWave management traffic
For FileWave Client, Kiosk, MDM, Booster, and FileWave cloud traffic, allow the traffic without certificate replacement or HTTPS decryption. For Apple, Google, and Microsoft services used by managed-device workflows, follow the vendor network guidance and avoid inspection where the vendor requires direct TLS trust.
Depending on the product, this setting may be called:
SSL inspection
SSL decryption
TLS inspection
HTTPS inspection
HTTPS proxy/content inspection
Certificate inspection
Deep packet inspection or DPI
Secure web gateway inspection
Man-in-the-middle inspection
The goal is the same: FileWave-managed devices must see the real certificate presented by the FileWave Server or cloud service, not a substitute certificate generated by the filtering product.
6. Lightspeed-specific example: Unknown or Uncategorized destinations
In Lightspeed environments, check whether the affected URL is listed as 
Unknown or blocked by an 
Unknown / 
Uncategorized category rule. Apply that check to the FileWave and vendor destinations required by the failing workflow. For FileWave Kiosk 15.3.1 and later, one known example is:
https://fw-kiosk-v2-ipas.filewave.cloud/
If Lightspeed is blocking this URL, the Kiosk installation may fail with a manifest validation or SSL error even though other FileWave functions appear normal. If a different FileWave feature is failing, check the corresponding destinations from the port usage article instead of focusing only on the Kiosk URL.
7. Test from the affected network
From macOS or Windows on the same filtered network, test the specific destination that matches the failing workflow. For the Kiosk IPA host, for example:
curl -Iv https://fw-kiosk-v2-ipas.filewave.cloud/
A successful connection should complete a TLS handshake and return an HTTP response from the destination. A failure may show certificate validation errors, proxy-generated certificates, connection resets, block pages, authentication prompts, or timeouts.
For iOS/iPadOS, use the filter logs and a browser test from the same network or policy where possible. The device may not expose the same command-line testing tools, so the proxy/filter logs are often the best evidence.
8. Retest FileWave behavior
After updating allow/bypass rules:
Retry the FileWave Kiosk or App Portal installation.
Force or wait for the FileWave Client to check in.
Confirm inventory, manifests, and Fileset downloads behave normally.
Review filter logs again to verify the FileWave traffic is allowed and not being decrypted.
9. If it still fails, collect evidence before escalating
If the traffic still fails after allow and inspection-bypass rules are updated, collect enough detail to show where the failure occurs:
The affected FileWave feature, platform, and device name or serial number.
The network, VLAN, proxy/filter policy, and whether the same device works on another network.
The timestamp of the failure and the corresponding proxy/firewall log entry.
The blocked destination, category, action, and whether SSL/TLS inspection was applied.
Any command output, such as 
curl -Iv, showing the connection, certificate, block page, reset, timeout, or proxy-generated response.
Relevant FileWave Client, Kiosk/App Portal, or MDM logs for the same time window.
Related Content
Default TCP and UDP Port Usage
How the FileWave Client Communicates
Resolving SSL and Manifest Validation Errors with FileWave Kiosk Installation (15.3+)
Bypassing DPI for Apple Traffic in MDM Communication
Customer Technical Support

Using PowerShell to Remotely Check the Windows FileWave Client Status
What
The Windows FileWave Client runs as a Windows service, so uptime, local changes, crashes, or service problems can affect whether it is available. This article provides a PowerShell example for checking a list of Windows devices for FileWave Client service status, client version, and assigned server address.
When/Why
You probably will not run this every day, but it is useful when you need to sweep a Windows network and find devices where the FileWave Client may be missing, stopped, unreachable, or pointed at the wrong server. Review the assumptions below before using it.
How
Use the script below when you need a remote first pass before visiting devices or opening individual remote sessions.
#import a list of computers
$mypath=$MyInvocation.MyCommand.Path
$mypath=Split-Path $mypath -Parent
try {
    $computers=Get-Content $mypath\computers.txt -ErrorAction Stop
} catch {
    #no computers.txt file found
    write-host "`nTo use this utility, a text file called computers.txt must exist in the same location as the script.  The file should contain one computer name or IP per line"
    break
}
foreach ($computer in $computers) {
    $online=$false
    try{
        #try to resolve the name
        $online = Resolve-DnsName $computer -quicktimeout -ErrorAction Stop
        $online = $true
    }catch{
        #Catching errors...machine offline
        $online= $false
    }
    if (!$online) {
        #device not online...show it in UI so that we see progress, but don't write it to the results file since it isn't actionable
        write-host "$computer, Not online"
    } else {
        #device online, so let's just see if the service is there
        $fw_service=""
        try{
            #Getting service ...sometimes device might not allow collection (if RPC is unavailable for instance)
            $fw_service = Get-Service -ComputerName $computer  -Name 'FilewaveWinClient' -ErrorAction Stop
            $fw_service=$fw_service.Status
        }catch{
            #Catching errors...no filewave service
            $fw_service="no"
        }
        if ($fw_service -eq "no") {
            #no need to look further since we either can't talk to RPC, or there is no FW service
            write-host "$computer, No FW Service or RPC unavailable" 
            Add-Content -Path $mypath\output.txt -Value "$computer, FW Needs Installed or RPC Unavailable"
        } else {
            #fw is there as a service, so let's return status, version, and server address            
            try {
                #using C$ share, which won't require winrm
                $TargetPath = "\\$computer\C$\Program Files (x86)\FileWave\fwcld.exe"
                $fw_version = [System.Diagnostics.FileVersionInfo]::GetVersionInfo($TargetPath)
                $fw_version = $fw_version.ProductVersion       
            } catch {
                #Catching errors
                $fw_version="version not readable"
            }
            #get fw server address from registry
            try {
                #read server address from registry
                #we need remote registry turned on to read, but we'll turn it back off
                #note this does not account for an environment where remote-registry is on by default...if so, comment out the remote registry lines
                Get-Service -ComputerName $computer -Name RemoteRegistry | Set-Service -StartupType Manual -PassThru| Start-Service
                $Reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $computer)
                $RegKey= $Reg.OpenSubKey("SOFTWARE\\WOW6432Node\\FileWave\\WinClient")
                $fw_server = $RegKey.GetValue("Server")
                #turn remote registry back off
                Get-Service -ComputerName $computer -Name RemoteRegistry | Set-Service -StartupType Disabled -PassThru| Stop-Service
                
            } catch {
                #Catching errors...no registry
                $fw_server="server address not readable"
            }
            #write the output
            write-host "$computer, $fw_service, $fw_version, $fw_server"
            Add-Content -Path $mypath\output.txt -Value "$computer, $fw_service, $fw_version, $fw_server"
            
        }
    }
}
Assumptions made in the above code:
1. A text file named computers.txt exists in the same folder as the PowerShell script.
2. computers.txt contains one computer name or IP address per line. Names are better when DNS is dynamic.
3. The PowerShell session runs with domain administrator rights or equivalent remote-service and admin-share access.
4. WinRM is not enabled. If WinRM is available in your environment, you may prefer a remoting-based version of this check.
You can adapt this script to check other services, use a different authentication method, or add remediation. As written, it reports the device name, FileWave service status, FileWave Client version, and assigned FileWave Server address. For corrective action, use your approved remote-management tool; PsExec is one common option in Windows environments.
Related Content
Script Best Practices
Using PsExec to Remotely Restart the FileWaveWinClient Service
FileWave Client Status Check: How to ask the client what it is doing on macOS and Windows
Digging Deeper
If you want to pre-check which devices are online before running the main script, use this shorter example. A filtered list makes the service-status check run faster.
#Let's just look for a list of devices online
#import a list of computers
$mypath=$MyInvocation.MyCommand.Path
$mypath=Split-Path $mypath -Parent
$computers=Get-Content $mypath\online_test.txt
foreach ($computer in $computers) {
    $online=$false
    try{
        #try to resolve 
        $online = Resolve-DnsName $computer -quicktimeout -ErrorAction Stop
        $online = $true
        write-host $computer
    }catch{
        #Catching errors...machine offline
        $online= $false
    }
}

When Does the FileWave Client Run Inventory Scans?
Inventory scan schedule
The FileWave Client collects inventory at three standard times:
when the Client starts;
when an administrator sends Verify to the Client; and
every 24 hours while the Client is running.
Send Verify when you need fresh inventory before the next scheduled scan, then allow time for the Client to check in and upload the result.

Troubleshooting Deployment Issues with the FileWave Upgrade Fileset
If you’re experiencing issues deploying the Upgrade Fileset to devices, the resolution steps depend on the target operating system.
Scope: This article covers upgrade fileset deployment, redeploy, and Windows import/extraction issues. If the Windows upgrade fileset imports and deploys but the client upgrade itself does not complete, the client version does not update in inventory, or the service does not restart, see Troubleshooting Windows Client Upgrade Fileset Issues.
macOS Deployment
Issue: Devices show that the latest FileWave Client is not installed despite deploying the Fileset.
Solutions:
1. Reinstall on Selected Devices:
Navigate to the Upgrade Fileset in FileWave Admin Central.
Select Fileset Report from the top menu.
Highlight all devices listed.
Choose Reinstall on Selected Devices.
2. Alternatively, you can Redeploy the Fileset:
Remove the Fileset Association from all devices, or remove targets from the Deployment.
Perform model update after removing the association/deployment.
Re-add to deployment or recreate association, Update Model.
Cause:
This issue occurs due to the Privacy Preferences Profile (v3) required for the FileWave Client. The profile must install first, but it cannot complete until the FileWave Client is deployed. Redeploying ensures proper installation order.
Note: This should be a one-time occurrence unless a new profile is required with a major macOS update post-Sequoia.
Windows Deployment
Issue: Errors occur when deploying the Fileset due to improper extraction during setup.
Solution:
1. Remove and Recreate the Fileset:
Remove the Fileset association from devices.
Delete the current Fileset from FileWave.
2. Redownload and Extract the Fileset:
Download the Upgrade Fileset again.
Right-click the downloaded file and select Extract All.
Open the extracted folder, which should look like this: ~Upgrade_Fileset_for_Windows.fileset.
Inside, you’ll find another folder with the same name. Drag and drop this inner folder into FileWave to create the new Fileset.
Verification:
After importing the Fileset, ensure its contents are correctly displayed in FileWave.
Examples:
Broken Example:
• Windows fileset: The extracted folder contains only a single ~Upgrade_Fileset_for_Windows.fileset folder containing unusable files.
Working Example:
• Windows fileset: The extracted folder includes only the temp folder, containing scripts/MSI required to update the Client, which is imported into FileWave as the Fileset.
By following these steps and verifying with the examples, you can ensure successful deployment of the FileWave Upgrade Fileset. If further assistance is needed, please contact FileWave Support.

First FileWave Client 15.1.0+ Upgrade Requires Reboot on macOS 14+
What
This article explains why, on macOS 14.0 or higher, a FileWave Client upgrade from a version prior to 15.1.0 to 15.1.0 or higher does not appear to complete until after the next system reboot. This is due to new Apple privacy restrictions (TCC) that block the script responsible for restarting the FileWave Client as part of the upgrade process.
When/Why
This scenario occurs on the first upgrade to FileWave Client 15.1.0 or higher on any Mac running macOS 14.0 or later, if the device is upgrading from a version lower than 15.1.0.
After the upgrade process runs, the previous FileWave Client version continues to operate and check in normally.
The upgraded client is present on disk but will not run until the next reboot.
Once the device is restarted, the new FileWave Client version launches, and—if the device is MDM-enrolled—the necessary TCC profile is deployed automatically. This resolves the restart issue for all future upgrades.
How
Recommended steps for best results:
Upgrade the FileWave Client to 15.1.0 or newer before updating to macOS 14, if possible. This ensures full compatibility and a seamless upgrade experience.
MDM-enroll your macOS devices. FileWave 15.1.0+ will automatically deploy the needed TCC profile through MDM, which allows future upgrades to restart and activate the new client version immediately, even on macOS 14 or higher.
If you have already upgraded to macOS 14 before installing FileWave Client 15.1.0 or newer, no action is needed:
The older client will continue to run until the next system reboot.
After a reboot, the new client will be active, and upgrades going forward will complete as expected.
Related Content
FileWave Release History

Offboarding Clients
Use this chapter as the starting point for removing devices from FileWave management. Start with Retiring a device from FileWave to choose between archiving, deleting, wiping, uninstalling the FileWave Client, or using a platform-specific cleanup path. The sub-pages cover the managed platforms FileWave handles: macOS, Windows, Apple MDM, Android Enterprise, and ChromeOS/Chromebooks.

Archiving Clients
Archive a client when you want to stop active management while keeping the device record and historical inventory in FileWave. Archived clients do not consume a FileWave license, are hidden from normal client views by default, and are removed from the active FileWave Model.
Archive is different from Delete. Delete removes the record from FileWave. Archive keeps the record as an inactive object that can be shown again or reinstated later.
What Archive does
Removes the client from the active FileWave Model.
Stops normal model and inventory updates for the archived record.
Hides the client from normal views unless archived clients are shown.
Frees the FileWave client license used by that record.
Keeps the record available for historical review or later reinstatement.
A Model Update is required after changing client state.
Before you archive
If the device should stop communicating with FileWave permanently, remove the active management path before or during the archive workflow.
For Windows computers, deploy the uninstall Fileset before archiving. See Uninstall the FileWave Client on Windows.
For macOS computers, deploy the uninstall Fileset or run the standalone uninstaller before archiving if the FileWave Client should be removed. See Uninstall the FileWave Client on macOS.
For Apple MDM-enrolled devices, review the MDM enrollment behavior below before archiving.
For Android or ChromeOS devices, use the platform-specific removal article instead of treating the device as a normal FileWave Client. See Removing Android Devices and Removing ChromeOS / Chromebook devices.
Reinstating an archived client
Use Reinstate when a previously archived computer should return to active management. Reinstating only works if the device still has a working FileWave Client or enrollment path. If the FileWave Client was removed, reinstall the client before expecting the device to check in.
Apple MDM enrollment
When an MDM-enrolled Apple device is archived, FileWave may attempt to remove the MDM enrollment profile. Whether FileWave attempts that removal depends on the enrollment type and the setting in Preferences > Mobile.
After an MDM enrollment profile is removed, the device may no longer have a management channel to report success back to FileWave. Treat the command as a best-effort offboarding action and verify the device state separately.
For Automated Device Enrollment devices, Apple generally provides two supported ways to remove a non-removable enrollment profile: send the MDM command that removes the profile, or wipe the device. FileWave can trigger the MDM removal command through the archive workflow when the applicable setting and enrollment state allow it.
If MDM removal does not complete
If an Apple MDM profile is non-removable and the archive command did not reach the device, do not treat manual profile-file removal as a normal offboarding procedure. Wipe the device when appropriate, or contact FileWave Technical Support for guidance on the safest recovery path for that device.
If the goal is to repair a Mac that should still be managed but appears to have lost its MDM enrollment state, see Apple MDM Missing Enrolment Profile before using destructive recovery steps.
Related Content
Retiring a device from FileWave
Uninstall the FileWave Client on Windows
Uninstall the FileWave Client on macOS

Retiring a device from FileWave
Use this article as the starting point when a device is leaving FileWave management, being reassigned, sold, disposed of, or preserved as an inactive record. The key rule is to remove or reset the device's management path before you delete the record from FileWave. If management is still active somewhere else, the device can check back in or be recreated by a platform sync.
If the Delete action is unavailable, confirm that you are viewing the original client record rather than a clone or grouped representation. Use Show Original from the client context menu when it is available, then remove or archive the original record after the relevant platform cleanup is complete.
If you only need to stop managing a device but keep its historical record, archive it instead of deleting it. See Archiving Clients.
Choose the right offboarding path
Device or scenario
Primary cleanup path
Use these articles
macOS computer with FileWave Client
Uninstall the FileWave Client if the Mac should stop checking in. If the Mac is also MDM enrolled, remove the MDM profile or wipe the device as appropriate.
Uninstall the FileWave Client on macOS, Archiving Clients, Wipe Device for macOS
Windows computer with FileWave Client
Uninstall the FileWave Client while the device can still receive Filesets, then delete or archive the record after the uninstall has run.
Uninstall the FileWave Client on Windows
iPhone, iPad, or Apple TV
Remove MDM enrollment or wipe the device. If the device is leaving the organization and is assigned through Apple Business Manager or Apple School Manager, release it from Apple.
Archiving Clients, Apple release links below
Android Enterprise device
Use the Android wipe/removal path and wait for the Google synchronization state before deleting the FileWave record.
Removing Android Devices
ChromeOS / Chromebook
Handle the device in Google Admin Console first. FileWave syncs Chromebook records from Google Admin, so Chromebook offboarding is not a normal FileWave Client uninstall/delete workflow.
Removing ChromeOS / Chromebook devices
Inactive record you may need later
Archive the client instead of deleting it. Archived clients do not consume a FileWave license and are hidden from normal views.
Archiving Clients
Before you delete a device
Decide whether the device should be archived, wiped/reassigned, or permanently removed.
Remove the active management path first. That might mean uninstalling the FileWave Client, removing an MDM profile, wiping the device, deprovisioning a Chromebook, or waiting for an Android/ChromeOS Google synchronization.
If the device is leaving Apple Business Manager or Apple School Manager ownership, release it from Apple before reuse or resale.
After the management path is removed or the wipe command has been sent, delete or archive the FileWave record and run Update Model.
Verify the device does not return after the next check-in or platform synchronization.
Apple Business or School Manager
If devices are enrolled through Apple Business Manager or Apple School Manager and will no longer belong to the organization, release them from Apple. Releasing the device prevents future Automated Device Enrollment assignment by that organization.
Release devices in Apple Business Manager
Release devices in Apple School Manager
After releasing a device, run the relevant FileWave Apple/DEP synchronization so the FileWave view reflects the change. If the device is not released and still has an Automated Device Enrollment profile assignment, wiping it can cause it to enroll again.
Delete from FileWave
Once enrollment, client software, or platform synchronization state has been handled, delete the record from FileWave if you no longer need the historical record.
Open the FileWave Central Admin App.
Select the device or devices in the Clients view.
Right-click and choose Delete.
Run Update Model.
If any enrollment configuration or client software remains active, the device may check back in or be recreated by a platform sync. In that case, fix the platform-specific cleanup first, then delete or archive again.
Related Content
Archiving Clients
Uninstall the FileWave Client on Windows
Uninstall the FileWave Client on macOS
Removing Android Devices
Removing ChromeOS / Chromebook devices

Uninstall the FileWave Client on Windows
Use this Fileset when you need to uninstall the FileWave Client from Windows computers before archiving, deleting, selling, or otherwise removing those devices from FileWave management.
Deploy the uninstaller while the device can still receive Filesets. After the FileWave Client is removed, the device will no longer check in to the FileWave Server through the client.
Before you begin
Test the uninstaller on a small pilot group before broad deployment.
Make sure no required Filesets, scripts, or inventory actions still need to run on the device.
Plan the follow-up state change: archive the client if you need to keep the record, or delete the record if it should be removed from FileWave.
Download
Windows-ClientUninstaller-registry-2026-07-03.fileset.zip
This updated Fileset reads the Windows uninstall registry entries and runs the FileWave Client uninstall command silently. It does not use 
wmic or the 
Win32_Product WMI class.
Directions
Download the attached Fileset and unzip it.
Drag the unzipped Fileset into the root level of the Filesets tab so it is not accidentally deployed from inside another folder.
Associate the Fileset to the Windows computers that should be removed from FileWave management.
Run a Model Update.
Confirm the uninstall has had time to run on the targeted devices.
Archive or delete the FileWave records as appropriate, then run another Model Update.
How the Fileset works
The Fileset uses PowerShell to inspect these uninstall registry locations:
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
When it finds the FileWave Client uninstall entry, it runs the matching MSI uninstall command with quiet/no-restart options. This avoids the deprecated WMIC command-line utility and avoids querying 
Win32_Product, which Microsoft documents as a class that can trigger Windows Installer consistency checks.
After uninstall
Once the FileWave Client is removed, the device cannot receive additional FileWave Client commands. If the record is only being kept for history, archive it. If the device should be removed from FileWave entirely, delete the record and run Update Model.
Related Content
Retiring a device from FileWave
Archiving Clients
Uninstalling Filesets
Microsoft: WMI command line (WMIC) utility deprecation
Microsoft: Win32_Product can trigger Windows Installer reconfiguration checks

Uninstall the FileWave Client on macOS
Use these uninstallers when you need to remove the FileWave Client from macOS computers before archiving, deleting, selling, or otherwise removing those devices from FileWave management.
Remove the client while the Mac can still receive Filesets. After the FileWave Client is removed, the Mac will no longer check in to the FileWave Server through the client.
Before you begin
Test the uninstaller on a small pilot group before broad deployment.
Confirm whether the Mac is also MDM enrolled. Removing the FileWave Client does not remove the MDM enrollment profile.
If the Mac should leave management entirely, handle the MDM enrollment separately. For Automated Device Enrollment devices with a non-removable MDM profile, the local FileWave Client uninstaller cannot remove that profile.
Do not run this on a FileWave Server unless you understand what is installed on that Mac. The script is intended to remove the FileWave Client and client-side data.
Downloads
Option
Download
Use when
Fileset
FileWaveUninstallermacOSv4.1.2-kiosk-process-fix-fileset.zip
You can still deploy Filesets to the Macs being removed.
Standalone script
FileWaveUninstallermacOSv4.1.2.sh.zip
You need to run the uninstaller locally or through another tool.
Version 4.1.2 keeps the version 4.1 behavior for clients that no longer use FileWave VNC, corrects the FileWave Kiosk app path, and terminates the running FileWave Kiosk process before removing the app bundle.
Fileset directions
Download the attached Fileset and unzip it.
Drag the unzipped Fileset into the root level of the Filesets tab so it is not accidentally deployed from inside another folder.
Associate the Fileset to the Macs that should be removed from FileWave management.
Run a Model Update.
Confirm the uninstall has had time to run on the targeted Macs.
Archive or delete the FileWave records as appropriate, then run another Model Update.
Standalone script directions
Download and unzip the standalone script.
Run the script locally as root with 
zsh:
sudo /bin/zsh ./FileWaveUninstallermacOSv4.1.2.sh
Do not run the script with 
sh. The script uses zsh process substitution. Running it with 
sh can produce this error:
syntax error near unexpected token `<'
done< <(pkgutil --files com.filewave.fwcld.pkg)
If you see that error, run the current standalone script again using 
sudo /bin/zsh, not 
sh.
MDM enrollment note
This uninstalls the FileWave Client, but it does not remove an MDM enrollment profile. If the Mac is still MDM enrolled, FileWave may still have an MDM channel to the device, and a configured custom PKG can reinstall the FileWave Client during enrollment or later MDM-driven installation.
If the Mac is enrolled through Apple Business Manager or Apple School Manager using Automated Device Enrollment and the MDM profile is configured as non-removable, the user cannot remove that profile locally. Use one of the supported MDM/ADE offboarding paths instead:
Send the MDM command to remove the enrollment profile while the device is powered on, online, and still enrolled. In FileWave, archiving an applicable Apple MDM device can send that removal command depending on the enrollment state and the setting in Preferences > Mobile.
Wipe the Mac when the profile cannot be removed or when the device is being fully reset.
If the Mac is leaving the organization, release it from Apple Business Manager or Apple School Manager. If it should remain owned by the organization but move to another MDM, change the Automated Device Enrollment assignment before wiping and re-enrolling.
Do not treat SIP-disable/manual profile-store deletion as a normal offboarding method. Use the MDM command, wipe workflow, or FileWave Technical Support for exceptional recovery cases. See Archiving Clients, Wipe Device for macOS, and Apple's device management profile removal guidance.
Uninstaller scope
The macOS uninstaller uses the FileWave Client package receipt, 
com.filewave.fwcld.pkg, to identify installed client components. That works best for a standard FileWave Client installation. It may not perfectly describe devices that were upgraded several times, modified manually, or changed by older upgrade Filesets. Those devices can have files or folders that are newer than the package receipt, or older files that are no longer part of the current client.
The script forgets the FileWave Client package receipt at the end of a successful run. If you run the script again after that, it may report that the package receipt is not found and exit without doing additional work.
You can check which FileWave package receipts macOS currently knows about with:
pkgutil --pkgs | awk '/com.filewave/ {print}'
The client receipt is 
com.filewave.fwcld.pkg. FileWave Server, Booster, Admin, and other FileWave components may have their own package receipts. The uninstaller checks for some shared FileWave components before removing shared resources, but it is still a client uninstaller. Review FileWave Server or multi-role Macs carefully before using it.
If FileWave Kiosk remains visible
Version 4.1.2 removes 
/Applications/FileWave Kiosk.app and also attempts to terminate a running FileWave Kiosk process before removing the app bundle. If a menu bar icon remains immediately after uninstall, confirm that the device ran version 4.1.2 or newer, then log out or restart the Mac to clear any stale menu bar item that was already loaded in the user's session.
If the FileWave Kiosk app bundle or process remains after running version 4.1.2 and restarting, collect the uninstall output and contact FileWave Technical Support.
Related Content
Retiring a device from FileWave
Archiving Clients
Wipe Device for macOS
Apple: Intro to device management profiles

Removing Android Devices
Use this page when an Android Enterprise device should be wiped, reassigned, retired, or removed from FileWave. Android devices are synchronized through Google's Android Enterprise management path, so deleting the FileWave record alone is not enough if Google still considers the device managed.
Choose the right Android removal path
Situation
Recommended path
Device is being retired, sold, disposed of, or fully reset
Send the wipe command, wait for the next Google sync/state change, then delete the device from FileWave and run Update Model.
Device was erased locally or disappeared before FileWave sent a wipe
Do not rely on deleting the FileWave record alone. Google may add it back during synchronization. Resolve the managed device state in Google/FileWave first, then delete it.
Device is being reassigned inside the organization
Wipe/reset the device as appropriate, but keep the management path active if the device should remain managed.
Wipe and remove an Android device
Send the Android wipe command to erase the device.
Run Update Model if the command was sent from FileWave.
Wait for the next Google synchronization. The device should turn red in FileWave when Google reports the changed state.
Delete the device from FileWave.
Run Update Model again.
If the device comes back
If the device is erased locally, the FileWave Client is removed, or the FileWave record is deleted before the Android Enterprise state is cleaned up, FileWave and Google may still consider the device managed. Deleting it from FileWave can look successful at first, but Google can add it back on the next synchronization.
Use the same cleanup path: resolve the Android Enterprise device state, send the wipe command when possible, wait for the Google synchronization state, then delete the device once FileWave shows it is ready to remove.
Related Content
Retiring a device from FileWave
Archiving Clients

Removing ChromeOS / Chromebook devices
Use this page when a Chromebook should be reassigned, retired, sold, disposed of, or removed from FileWave’s ChromeOS management view. ChromeOS devices are different from macOS, Windows, and FileWave Client devices because FileWave syncs Chromebook records from Google Admin Console.
For standard FileWave Client retirement, see Retiring a device from FileWave. For Android Enterprise devices, see Removing Android Devices.
Choose the right ChromeOS removal path
Situation
Use this path
Reassign a Chromebook to another student, staff member, or loaner user
Use Wipe Users when the device should stay enrolled. Use Powerwash / Wipe Device when you need a full reset.
Retire, sell, dispose of, or permanently remove a Chromebook from management
Handle the device in Google Admin Console first, including deprovisioning when it will no longer be managed. FileWave syncs Chromebook records from Google Admin, so do not rely on deleting the record in FileWave alone.
Wipe a device but keep it managed after reset
Review Forcing wiped ChromeOS devices to re-enroll so the Google Admin enrollment setting matches your intent.
Stop ChromeOS management for the whole FileWave environment
Use Disable Chrome OS in FileWave. That removes the Google OAuth token and disables the ChromeOS integration for the environment.
Remove or retire an individual Chromebook
Decide whether the Chromebook should remain managed after the work is complete.
If the device is being reassigned inside the organization, keep it provisioned in Google Admin Console and use Wipe Users or Powerwash as appropriate.
If the device will no longer be managed by the organization, deprovision it in Google Admin Console. Google Admin is the source of truth for ChromeOS device management.
Allow FileWave’s Google Admin sync to update the Chromebook record. If the device keeps returning to FileWave after you delete or reset it, check the Google Admin device state and forced re-enrollment settings.
Update the model in FileWave after any FileWave-side action, such as sending a wipe command.
Important differences from normal client removal
Chromebooks do not uninstall the FileWave Client like macOS or Windows devices.
FileWave syncs Chromebook devices and groups from Google Admin Console, so the Google Admin device state controls whether the Chromebook should remain managed or return to FileWave after a sync.
Powerwash resets the Chromebook. It does not automatically mean the device should leave management.
Forced re-enrollment controls what happens after a wipe. If a Chromebook should not come back under management, deprovision it in Google Admin Console.
Related Content
Chromebook Management
Google Admin Sync Interval for ChromeOS
Powerwash / Wipe Users on ChromeOS (15.3+)
Forcing wiped ChromeOS devices to re-enroll (15.3+)
Disable Chrome OS in FileWave
Retiring a device from FileWave