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/  

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

FileWave Client Rename Behavior
Renaming a desktop client in the admin console will now change the Client Name inventory field to match the new name entered and also change the client name "sync" setting in the client's preferences . This ensures that the device is able to connect properly with FileWave instance without duplicated entries.  (The Device Name inventory filed is not modified) 
 So, when a client is renamed, the "Sync Computer Name" settings is turned off: 
 
 Further Details 
 
 The FileWave Client uses its name as part of the identity of the client (see:  How the FileWave Client Communicates  for more) 
 The FileWave Client has a configuration ( FileWave Client Configuration Settings ) to "Sync Computer Name" that can be changed one at a time (Via Client Monitor) or en masse ( Creating a Superprefs Fileset ). 
 Renaming devices in the FW Admin (r-click → rename) has a different behavior depending on the device (see below)

FileWave Client Status Check: How to ask the client what it is doing on macOS and Windows
What 
 The FileWave client, available for both macOS and Windows, allows administrators to verify its status and understand the tasks it's currently handling. This can be accomplished by executing a specific command in the Terminal application on macOS, or the Command Prompt on Windows. This article provides instructions on how to use this feature for troubleshooting purposes. 
 When/Why 
 This feature is especially useful when you have direct access to the device and need to determine what the FileWave client is currently working on. It enables you to view the current status of the FileWave client, the filesets in inventory, and other crucial information. 
 You might find this feature beneficial when: 
 
 
 You're diagnosing issues related to the application of filesets or profiles. 
 
 
 The FileWave client is behaving unpredictably and you want to determine its current state. 
 
 
 How 
 Follow the steps below to check the status of the FileWave client: 
 macOS 
 
 
 Open the Terminal application on the macOS device. 
 
 
 Execute the following command: /usr/local/sbin/FileWave.app/Contents/MacOS/fwcld -s 
 
 
 Windows 
 
 
 Open the Command Prompt on the Windows device. 
 
 
 Depending on the architecture of your Windows OS, execute the appropriate command: 
 
 
 For Windows using FileWave 15.5 or higher 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 and Current Model Number where User ID is really the ID number of the device in FileWave 
 
 
 Filesets currently in the device's inventory, along with their status 
 
 
 Filesets not meeting requirements 
 
 
 Current worklist 
 
 
 This information can assist you in understanding the tasks that the FileWave client is processing and aid in troubleshooting any issues. 
 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 
 The PS Tools from Microsoft (from SysInternals)  are a terrifically powerful tool to help you troubleshoot when all else fails.  In this article we'll look at how you can use PSExec to help troubleshoot an ill-behaving FileWave Client. 
 When/Why 
 From time to time, things don't work right.  None of us would be employed if this weren't the case, so let's look on the bright-side of that!  But what to do if a FileWave client on a Windows device is misbehaving, and you can't communicate through normal FileWave channels?  PSEXEC to the rescue. 
 How 
 Assumptions made in the following: 1) You have download PSTools, and unzipped 2) That you launched a cmd prompt as a domain admin user (makes credentials issue easier to deal with) 3) That you have changed directory into the directory where PSTools is located 
 We'll start by simply connecting to the remote computer by name in an interactive PSEXEC shell: 
 psexec64 \\computername -h cmd 
 You'll end up in a shell like the below ('exit' will allow you to leave that shell) 
 
 Now, what's remarkable about this is that shell is running as your domain admin account, and you can do anything on it you can do from the command line.  This article isn't meant to be a Windows CLI primer, but the following are some examples of things we could do if we assume we have a device that isn't reporting in correctly: 
 
 Check the FileWave Client Service:
 
 
 sc query filewavewinclient 
 
 
 
 Stop the FW Client Service
 
 
 sc stop filewavewinclient 
 
 
 
 Restart the FW Client Service
 
 
 sc start filewavewinclient 
 
 
 
 If the service won't start or stop, maybe we need to kill it forcefully by:
 
 Looking for the client process
 
 
 tasklist | findstr fwcld 
 
 
 
 
 
 
 
 And then killing it by PID
 
 
 taskkill /PID 16264 /F 
 
 
 Note that this same procedure can be very helpful to clear up a misbehaving Windows Update agent.  When Windows Update hangs, the service itself usually won't stop.  Taskkill /SVC | find wuauserv will identify the proper task to stop to correct this.  (A reboot is also corrective for this, but onviously impacts the use of the device) 
 
 
 
 
 
 Check the FW Client Log for entries from today
 
 
 type c:\programdata\filewave\fwclient\fwcld.log | findstr mm-dd 
 
 (where mm-dd is today's date such as 05-16) 
 
 
 Get the IP of the workstation
 
 
 ipconfig 
 
 
 
 Restart the device (which is obviously destructive to any existing user)
 
 
 shutdown -r -t 0 -f 
 
 
 
 Determine if there are other users logged in
 
 
 quser 
 
 
 
 
 Get the last boot time
 
 
 Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object LastBootUpTime 
 
 
 
 
 
 
 
 Related Content 
 
 PS Tools 
 Great reference for Windows CLI commands (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

Using PsExec to Remotely Restart the FileWaveWinClient Service
What 
 Using PsExec to remotely restart the "FileWaveWinClient" Windows service allows you to remotely manage the FileWave client on Windows devices. This can be useful in situations where the client is not functioning properly and needs to be restarted in order to resolve the issue. 
 When/Why 
 There may be a variety of reasons why you would need to remotely restart the FileWaveWinClient service on a Windows device. Some common reasons include: 
 
 
 The service has stopped functioning properly and needs to be restarted in order to resolve the issue 
 
 
 The service needs to be restarted in order to apply a configuration change 
 
 
 The service needs to be restarted as part of a troubleshooting process 
 
 
 How 
 To use PsExec to remotely restart the FileWaveWinClient service, you will first need to download and install PsExec on the device from which you will be initiating the restart. PsExec can be downloaded from the Microsoft TechNet website ( https://docs.microsoft.com/en-us/sysinternals/downloads/psexec ). 
 Once you have PsExec installed, you can use the following command to remotely restart the FileWaveWinClient service: 
 psexec \[remote device] -u [username] -p [password] net start "FileWaveWinClient" 
 Replace [remote device] with the hostname or IP address of the remote device, and [username] and [password] with the appropriate credentials for the remote device. 
 Related Content 
 
 Microsoft TechNet: PsExec ( https://docs.microsoft.com/en-us/sysinternals/downloads/psexec  ) 
 
 Digging Deeper 
 In addition to using PsExec to remotely restart the FileWaveWinClient service, you can also use the "net" and "sc" command-line tools to query and change Windows services. 
 To query a service using "net", you can use the following command: 
 net start [service name] 
 This will display the status of the specified service. 
 To start or stop a service using "net", you can use the following commands: 
 net start [service name] net stop [service name] 
 To change the startup type of a service using "net", you can use the following command: 
 net start [service name] [startup type] 
 Valid startup types include: boot, system, auto, demand, disabled 
 To query a service using "sc", you can use the following command: 
 sc query [service name] 
 This will display detailed information about the specified service, including its status, startup type, and binary path. 
 To start or stop a service using "sc", you can use the following commands: 
 sc start [service name] sc stop [service name] 
 To change the startup type of a service using "sc", you can use the following command: 
 sc config [service name] start=[startup type] 
 Valid startup types include: boot, system, auto, demand, disabled 
 Keep in mind that you will need to have the appropriate permissions on the remote device in order to use these commands. You can also use PsExec to execute these commands remotely, as described in the previous section.

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 FileWave Client on Windows is like any other software service...the service can be impacted by computer uptime, user interference, crashes, etc.  This article gives you a way to INDEPENDENTLY check that a list of devices has the FileWave Client, and it is in working order (or not). 
 When/Why 
 Will you need this frequently?  Unlikely, but all the same, it is a great tool for sweeping a network to look for devices and confirm the FileWave client (for Windows only).  The code here does make some assumptions about your environment, but those are called out below. 
 How 
 So, you think the FileWave client may be broken or missing on some endpoints?  Wouldn't it be great if you could verify that remotely rather than having to confirm the devices by hand.  The following allows you to do just that. 
 #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.  There is a text file called computers.txt in the same location as the Powershell script 2.  That computers.txt file contains a computer name or IP per line (name is better if you have dynamic DNS) 3.  That the Powershell itself is running from a Domain Admin account...this avoids any credential related issues 4.  It is assumed that WinRM is not enabled in your environment (if it is this code could easily be made more elegant) 
 Note that this script could easily be modified to look at other services, to authenticate differently, and to take remediation.  As provided, it simply provides a list of results of device name, FW service status, FW client version, and FW server address assigned.  All very useful information for troubleshooting.  PSEXEC is highly recommended for taking corrective action. 
 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 a resource to pre-sweep the device list for devices that are online separately, you can use the following.  A refined list will just make the above script run a bit 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 inventory client run scans?
Inventory 
 The FileWave Client runs an inventory scan at startup, every time you execute a verify on the client, and every 24 hours.

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