FileWave Server

• FileWave Server System Requirements
• FileWave Server Installation & Upgrade
• FileWave Server Installation
• FileWave Access - Passwords
• FileWave Server On-Premise
• FileWave Server Time
• FileWave Server Upgrades
• Securing FileWave Server on the Internet for Remote Device Management
• FileWave Server Backup and Restore
• FileWave Server Repair Permissions
• FileWave Appliances on an Apple Silicon macOS system
• Your Hosted FileWave Server Has Been Upgraded - What Are Your Next Steps?
• Upgrading your On-Premise FileWave Server
• Reset root password through Webmin (FileWave Appliances Only)
• Migrating your On-Premise FileWave Server to new Hardware
• FileWave Server Pre-Upgrade Backup
• Does FileWave support 2FA / MFA?
• Configuring LDAP authentication
• Maintenance
• Webmin GUI (On-Premise)
• Webmin GUI - Changing the root password (On-Premise)
• Expanding the Disk on a FileWave Appliance - CentOS / Debian
• Set date/time on Virtual Appliances
• Store the FileWave Server/Booster Data on a Separate Volume
• Upgrading to FileWave 13+ from older Versions on Systems where Port 443 is used
• Privacy
• Details of Allowing / Disallowing Collection of Personal data on a License Level
• FileWave Server Analytics Reporting
• Deleting Old FileWave Client or Server Log Data
• Troubleshooting
• How to set FileWave Server components to debug mode
• fwxserver folder relocation in FileWave Server 13.1.4+ on macOS and Linux Platforms
• FileWave Server should not have IPv6 enabled

FileWave Server System Requirements

As of August 2024 v15.4.1, the below are supported for running FileWave Server, but for updated information, always consult the specific release on the Downloads Page. The FileWave Server can also be installed on a Virtual Machine.

• macOS 12, 13 (Intel and Apple Silicon)

• Linux Debian 12.x x86_64

The minimum general guidance on CPU / RAM / Network / Storage is:

• CPU: For physical hardware use, at least the equivalent of an Intel Core i5 or Apple M1. For virtual hardware, use at least 2 virtual processors.

• RAM: Use a minimum of 8Gb of RAM with 16Gb recommended.

• Network: At least 1Gb network connection.

• Storage: 1Tb is a recommended minimum, but this will depend highly on OS updates and Filesets as well as if Windows Imaging is in use.

Make sure you have enough space on your hard disk to store the cached Filesets for your FileWave Clients.

Related Content

• Booster System Requirements
• FileWave Windows Imaging Requirements

FileWave Server Installation & Upgrade

FileWave Server Installation

FileWave Server is the key component to device management.  The setup process will require not only a FileWave Server installation, but basic configuration will require the FileWave Central App (macOS or Windows).  Some additional configuration may also be achieved through the web admin: FileWave Anywhere.

Other appliances not covered in this chapter are:

• Boosters
• IVS

Overall requirements

FileWave server installation.  This can be hosted or on-premise.  For on-premise, FileWave Download pages not only provide the installer, but pre-built VMs are available for quick setup.

Manual Installation

If not using a pre-built VM:

• Download the latest server version and copy to the FileWave Server
• If using a shell, open this to the server, e.g. ssh, putty, etc. and elevate to the root user
• Unzip the download
• Run the installer

Follow the instructions, regarding the commands required, from the matching download pages.

FileWave Server networking

Please review the Default TCP and UDP Port Usage and also review FileWave Server should not have IPv6 enabled.

FileWave Access - Passwords

FileWave Administrator

FileWave installations provide an initial user which has full permissions.  On initial launch, this password should be changed as a matter of security.  The default account is:

• Name: fwadmin
• Password: filewave

The password may be changed in the FileWave Central software application Menus, through:

• Assistants > Manage Administrators

Select the 'fwadmin' account, followed by the 'Set Password' radial button.  Enter the chosen secure password

SSH

SSH is initially enabled and the root account of the default setup has the same password as fwadmin, however, they are not aligned.  Consider immediately changing the root users account password and disable the ability to access SSH to the server from the internet.

Log into a shell on the server as root and run the following command:

passwd

A prompt will require input of the new password and secondary confirmation of this new password.

FileWave Server On-Premise

Where servers are installed in on-premise environments, a couple of basic procedures should follow immediately.

Server Name

Arguably, the local server name need not necessarily matter, but the FileWave Server name is very much something to consider carefully.

When naming the server, always provide a Fully Qualified Domain Name.  This should be a name that could be used externally, even if that is not the initial plan at inception.  Subsequently changing the server name has massive impact or devices already enrolled.  Using a name that could be used at a latter date, provides future-proofing, extensively simplifying workload.

Certificates

A cert will need to be generated with a Subject Alternate Name (SAN) which matches the chosen server name.  Please see our KB pages on certificates:

https://kb.filewave.com/books/certificates

Once a P12 certificate is generated, it may be uploaded to the FileWave Server through the FileWave Central Application.

Naming the Server

The chosen name should be entered into the FileWave Central application's Mobile tab.  For example, for a server called 'demo.filewave.ch':

Server Command Line Configuration

With a certificate and name configured, there is a small amount of input required via the server's command line.

Hosts File

The server's host file should be edited to ensure the FileWave Server name is entered.  Take the following example hosts file:

127.0.0.1	localhost
::1             localhost

From the same above example 'demo.filewave.ch', the hosts file may edited in one of two ways.  Either:

127.0.0.1	localhost demo.filewave.ch
::1             localhost demo.filewave.ch

or

127.0.0.1	localhost
127.0.0.1       demo.filewave.ch
::1             localhost
::1             demo.filewave.ch

It does not matter if the additional entry is space separated on the same line or a new line entry, either method does the same process.

Apache Conf File

This is only required if the local server name does not match the FileWave Server name.

Edit the following file: 

/usr/local/filewave/apache/conf/httpd_custom.conf

Add the following entry for ServerName:

ServerName	demo.filewave.ch

Restart Server Process

After configuration change, the server process should be restarted.  This command should be ran as root.

fwcontrol server restart

FileWave Server Time

Time is critical with servers and acceptance of certificates and communication.  As such, it is imperative that time is kept in sync.  It is possible to run one-off commands to achieve this, but better still, consider enabling automated time sync.

macOS

macOS devices may just have time configured through the System Preferences or Settings

Linux

For linux servers, check out our KB on this topic:

Set date/time on Virtual Appliances

FileWave Server Upgrades

Upgrading for hosted servers will be a matter of communication between FileWave and hosted customers.  However for on-premise, consider the following process

Upgrade Process

1. Download the chosen upgrades from the FileWave Download Pages.  This will be at the very least the FileWave Server and FileWave Central application
2. Copy FileWave server installer to the server
3. Copy FileWave Central installer to a chosen macOS or Windows device
4. Lock all devices, from the right click contextual menu 'Lock' (Mobile and Computer devices can be locked separately from the relevant client View.  Multiple devices may be selected and actioned in one go.)
5. Run an Update Model
6. Run a backup
7. If this is a VM, stop the FileWave Server process and take a snapshot
8. Follow upgrade instructions from the download pages matching the installer version, including updating the server OS.
9. Once completed, instal or upgrade FileWave Central application
10. Connect and test a Model Update
11. Unlock an example, test device and ensure all is well
12. Either test further or once satisfied, unlock all other devices necessary

Before locking clients, confirm none are already locked for an alternate reason.  Once completed and unlocking, these devices may then be targeted to remain locked.

Securing FileWave Server on the Internet for Remote Device Management

What

This article provides guidance on securely exposing and managing your FileWave server on the internet for remote device management.

When/Why

You might need to expose your FileWave server on the internet to manage devices anywhere they might be, including performing actions like remote wipes. However, this must be done carefully to ensure the security of your server.

How

1. Limit Exposed Services: Consider what services are exposed. For instance, on CentOS VM appliances, WebMin runs on port 10000. It's recommended not to expose this to the internet. Similarly, block SSH to prevent unauthorized access.

2. Allow Only Necessary Ports: Only allow the FileWave ports that are necessary. Refer to the TCP and UDP ports KB article for the list of ports used by FileWave.

3. Apply OS Patches Consistently: Ensure that operating system patches are applied consistently. For CentOS, this means running yum update followed by yum upgrade. Reboot the server if a kernel update is applied.

4. Use Complex Passwords: Make sure that the root password on Linux or any passwords for the operating system at all for both macOS and Linux for the FileWave server are complex. This makes it harder for unauthorized users to gain access.

5. Implement Two-Factor Authentication (2FA): Enable two-factor authentication for accessing the FileWave server. This provides an additional layer of security by requiring users to provide a second form of authentication, such as a unique verification code sent to their mobile device. FWAdmin is always present so set that user to an extremely long and complex password.

6. Enable Firewall and Intrusion Detection System (IDS): Configure a firewall to filter incoming and outgoing traffic, allowing only necessary connections. Additionally, set up an intrusion detection system to monitor and alert you about any suspicious activities on your server.

7. Regularly Monitor Server Logs: Continuously monitor the server logs for any signs of unauthorized access attempts or unusual activities. Implement a log management solution to centralize and analyze log data for better security monitoring. This is difficult to do manually, so look at security monitoring tools. 

8. Apply FileWave Upgrades: Keep your FileWave server up to date by applying FileWave upgrades when they are released. These upgrades often contain security updates, especially for third-party open-source software like Apache and OpenSSL, which can include critical updates.

Related Links

• TCP and UDP ports used by FileWave
• Allow External Devices to Connect to the FileWave Server and Boosters
• How to Disable Apache Version Number Disclosure on FileWave Server

Note: As we move to the next Linux distribution, the guidance will remain the same. This article will be updated with additional recommendations as they are identified.

Remember, security is a continuous process. Always monitor your server for suspicious activity, keep your system up to date, and follow best practices to ensure the integrity and confidentiality of your FileWave server.

FileWave Server Backup and Restore

Summary

Backing up your FileWave server is always a good idea. Back in '97, a friend of mine spilled a pot of coffee on our server rack; you never know when bad things can happen to your hardware. Now, it's bad enough to lose the hardware, but think of all the hours represented by those perfected, irreplaceable FileWave Filesets! In order to prevent this disastrous loss, we have created a script to automatically back up your FileWave Server's database and data files, you can also run these scripts manually if you want.

Current Version

Download macOS / Linux - Version 4.5.4 (Jan 24, 2024)

server-backup

If you ever want to see the changes that have been made to this script over time please check out the GitHub repo - jlevitsk/filewave-serverbackup: The script that can backup and restore a FileWave Server (github.com)

Due to the nature of the FileWave databases, using active-backup solutions, such as Time Machine or CrashPlan, can corrupt the FW DB.

Alternate File Systems - Windows and Unix systems treat permissions in completely different ways. If attempting to backup from, for example, a Linux server to a Windows share, data will be backed up successfully, however, permissions will not be preserved. Permissions can and will need to be reset on files after a restore is actioned, and the script to repair permissions is located in the FileWave Server Repair Permissions KB article.

Updating the backup script

If you already have a backup scheduled on macOS or Linux, replace the script you are already using with the new version shown.

First, let's find out where your existing backup script is located:

sudo crontab -l|awk {'print $6'}

The above shows you a line like :

/root/scripts/backup_server_osx_linux.sh

You'll probably want to check if the script is newer than what you are using. Use the below command and replace /path/to/ with the path to your script you found in the prior step. You can see the version number of the latest script at the top of this article. Be aware that we only added the script version to the script in 2024 so if no version comes back or some weird text then you can be certain you need to update.

awk '/version=/' /path/to/backup_server_osx_linux.sh

Now that you are sure you want to update it, the below will show you where to place the file on your server. Please replace '/root/scripts/backup_server_osx_linux.sh' in the last two lines of the instructions below with what was returned to you by the last command before running the following:

wget https://kb.filewave.com/attachments/188 -O backup_server_osx_linux.sh.zip
unzip ./backup_server_osx_linux.sh.zip
# Remember the next 2 lines need to reflect where the script is going...
mv ./backup_server_osx_linux.sh /root/scripts/backup_server_osx_linux.sh
chmod a+x /root/scripts/backup_server_osx_linux.sh

Note: If you move the Data Folder to another network share, please make sure to update the path as well in the Backup Script.

On Mac OS X and Linux

Warning for macOS - With the added security of macOS Catalina (10.15) and beyond, you will need to give Full Disk Access to Cron, the utility used to run the automated backups. To do this drag and drop Cron (/usr/sbin/cron) into System Preferences > Security & Privacy > Privacy > Full Disk Access

Before you start, please ensure that the script has the execution permission (chmod 755).
The script is used to schedule backups or to run a backup manually. The first parameter passed to the script (required parameter) is "setup" or "run"

Automatic Backup

Use the "setup" parameter to schedule a backup task to run either weekly or daily. The second parameter options are [weekly | daily] and the third is the path to the back folder. For Big Sur servers, be sure the Terminal.app and /usr/sbin/cron have Full Disk Access to allow the cron job to complete successfully.

Examples: (Please use the full path to the script)

/path_to_script/backup_server.sh setup daily "/Volumes/backupFolder" 
/path_to_script/backup_server.sh setup weekly "/Volumes/backupFolder"

Manual Backup

Use the "run" parameter to run the backup manually right now. The second parameter is the backup folder, and the third parameter is the task mode "manual". The script has to know that it is running manually and not from a cron job.

Examples:

/path_to_script/backup_server.sh run "/Volumes/backupFolder" manual

Backup log file

The log is saved by default to "/private/var/log/fw_backup.log"
If you want to change the path, edit the script and change the variable "logFile".

Checking Automatic Backups

Please make sure to check your Automated backups periodically to make sure they are still running successfully. The main thing to check is to unzip your most recent zip folder created by the backup and check that inside, you see a “certs” folder, “DB” folder, httpd.conf, httpd_custom.conf, mdm_auth.conf, and a passwords file. You would also want to make sure that inside the DB folder that is created, you see a “mdm-dump.sql” file, and the size of the file is not showing as 0 bytes.

Restoring from Backup

The day may come that you need to restore from backup. This is something you should probably include Technical Support on because if you are at that point then something bad has probably happened. Knowing where to put the files from the backup is easiest found in our Migrating your On-Premise FileWave Server to new Hardware article because it tells you where to move the backup files when restoring and how to bring the database back.

Legacy Backup Script Versions

On Windows

Windows Server is no longer supported but the below is included for migration purposes. Use a legacy version of the backup script available above.

The Windows script takes two parameters, the path to the backup folder and then the frequency, which can one of these three options [ daily | weekly | now ]

Automatic Backup

Here is an example that shows how you can schedule a daily backup task. (Please use the full path to the script)

C:\_path_to_backup_\backup.bat "D:\MyFolder\FileWave Backups" daily

Manual Backup

You can run the backup manually by providing the "now" parameter. This can be useful before you upgrade your FileWave server to a newer version.

Example: (Please use the full path to the script)

C:\_path_to_backup_\backup.bat "D:\MyFolder\FileWave Backups" now

FileWave Server Repair Permissions

What

When migrating a server or simply moving files around or trying to restore from a backup  you can inadvertently set the ownership or permissions incorrectly on the FileWave Server. This can lead to services not starting or the database being inaccessible until it is corrected.

When/Why

You would use the included script when doing any migration or restore process or any time you think you may have changed the permissions. 

How

For the moment there are 2 versions of this script that are current. Over time we will be updating this script and will ideally have a single script to make things more simple. 

When you run this script you must stop the FileWave Server so that none of the files are locked. This is easily done with "sudo fwcontrol server stop" to make sure it is stopped. 

You can copy the link to the file from below and do "wget https://kb.filewave.com/attachments/283" for instance for the Debian script and then just unzip it.  "unzip ./283" to unzip the script. Planned for a release in 2024 there will be a simple management command included with FileWave Server that has this a built in function. 

Fix Permissions FileWave 15+ (Debian)  |  Fix Permissions FileWave 14+ (macOS/CentOS) 

If you are on an older version of FileWave use of these instead:
Fix Permissions v13.1.5+  |  Fix Permissions v13.1.4 or older

You can use wget to download the correct script and then rename it to anything.zip if it didn't get a .zip name and unzip it. You will need to give the script 755 permissions to run it. You will run the command to the path to the script. For the example it is in the current folder we are in so we use ./ before the name.

sudo chmod 755 ./fixfwxserverPermissions15.sh

Then you will need to run the script. 

sudo ./fixfwxserverPermissions15Debian.sh

After it fixes permissions you will want to restart your FileWave Server.

fwcontrol server restart

Related Content

• Migrating your On-Premise FileWave Server to new Hardware
• FileWave Server Backup

FileWave Appliances on an Apple Silicon macOS system

What

You may want to know how to load one of the Debian based FileWave Appliances for Server, Booster, or IVS so that you can test something, but your computer is an Apple Silicon Mac and so the x86 Appliances will not natively run on ARM based computers.

When/Why

Usually, this is for testing purposes. There does not appear to be an emulator that runs on Apple Silicon that also directly supports OVA files like the ones used by VMWare. UTM can emulate x86 hardware and has a tool to convert the hard disk to allow this as explained below.

How

Outline of the work

1. Download the OVA image from Downloads
2. Convert OVA to QCOW2 on your Mac
   • Install Homebrew to get the qemu conversion utility
   • Convert the hard disk image
3. Import the converted disk in to UTM
4. Launch

Download the OVA image from Downloads

This step is simple. Just go to the Downloads page. Go to the most recent version of FileWave, and then download the Debian Server, Booster or IVS image. At the time of writing this the IVS image is not yet published but will be with 15.3.0. 

Convert OVA to QCOW2 on your Mac

Extract the disk image included in ova with the command tar -xvf

tar -xvf FileWave_Server_Debian_15.2.1.ova

Once extracted you will have several files in the same folder as the OVA:

-rw-r--r--@ 1 jlevitsk  staff  2861168640 Dec 12 13:23 FileWave_Server_Debian-disk-0.vmdk
-rw-r--r--@ 1 jlevitsk  staff        8684 Dec 12 13:23 FileWave_Server_Debian-disk-1.nvram
-rw-r--r--@ 1 jlevitsk  staff         320 Dec 12 13:23 FileWave_Server_Debian.mf
-rw-r--r--@ 1 jlevitsk  staff        9185 Dec 12 13:23 FileWave_Server_Debian.ovf
-rw-r--r--@ 1 jlevitsk  staff  2861199360 Jan 12 09:47 FileWave_Server_Debian_15.2.1.ova

Install Homebrew to get the qemu conversion utility

If you've never used Homebrew before then this is an amazing tool you will come to love. Visit their website in case anything has changed but traditionally this command is what you'll want to install it. You will paste the entire line in to Terminal.app. They do now also have a PKG you can download from their Homebrew's latest GitHub release page.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once Homebrew is installed you can install the qemu utilities with this command in Terminal.app:

brew install qemu

Convert the hard disk image

For the next step you'll use the qemu-img command to convert the VMDK disk image over to QCOW2 that is used by UTM. The below command is done in Terminal.app, and you should consider if the file name differs, but it will be the VMDK that you extracted in the earlier step using tar and then the QCOW2 file won't exist until after you do this conversion command.

qemu-img convert -O qcow2 FileWave_Server_Debian-disk-0.vmdk FileWave_Server_Debian-disk-0.qcow2

Import the converted disk in to UTM

1. Press the + button in the upper left corner.
   
   

   
   
   

2.  

   Select Emulate
   
   

   

   
   
3. Select Other
   
   

   

   
   
4. Check Skip ISO boot and then click Continue
   
   

   

   
   
5. On this step the most important thing is to pick x86_64 for the Architecture and to ensure you have at least 8192Mb of RAM. 
   
   

   

   
   
   
6. The size of storage won't matter because we will be deleting it later.
   
   

   

   
   
7. The Shared Directory is not something I've been using. This is up to you but may need some drivers installed for it to work.
   
   

   

   
   
8. Give the VM a name and check the Open VM settings box. Click Save to pick up the VM Setting screen. If you forget to check the box for this to appear then you can right-click the VM and pick Settings to access the same screen.
   
   

   

   
   
9. You need to uncheck UEFI Boot or the appliance will not boot until you do.
   
   

   

   
   
10. Delete the existing IDE Drive. 
    
    

    

    
    
11. Click New... to make a new drive. This is where we will import the QCOW2 file.
    
    

    

    
    
12. When you clicked New... you should put 500 GB for the size and then click Import...
    
    

    

    
    
    
13. Browse to the QCOW2 file from the conversion step and select it. Now you can pick Save on the Settings page to finish.
    

Launch

You'll now have the virtual machine listed and if you pick the play button to start it up it should boot up fully.

Once booted you can login as root / filewave and then you can change the root password or use Webmin to change it.

Related Content

• UTM | Virtual machines for Mac (getutm.app)
• Homebrew — The Missing Package Manager for macOS (or Linux)
• Convert ova to qcow2 and start it with UTM | by Simo | Medium (The source for this article)

Your Hosted FileWave Server Has Been Upgraded - What Are Your Next Steps?

What

The FileWave OPS Team has upgraded your FileWave server; What steps do you need to take to continue managing your devices?

If your FileWave server is on-premise and not hosted by FileWave, you may review the KB article here: Upgrading your On-Premise FileWave Server

When/Why

You will get an email from the FileWave OPS team stating that your FileWave server will be upgraded on a specified day and time. After that upgrade completes, you will need to do the steps outlined here.. While your server is maintained by the FileWave team, you will still need to update your FileWave Central/Admin application and the clients enrolled.

How

Once you have received an email from the FileWave OPS Team, stating that your FileWave server has completed the FileWave server upgrade. You may begin upgrading your FileWave Central application.

1. Upgrading FileWave Central (FileWave Admin Native App)

FileWave Anywhere (Web Admin) is automatically updated with the Server.

To connect to your upgraded server, you will need to use the same version of FileWave Central (FileWave Admin Native) unless stated otherwise on the Downloads page. When you are updating FileWave Central (Admin) simply run the installer for your designated OS.

The installer does not require the old version to be uninstalled and is similar to running a PKG or MSI for any other software. FileWave Central is supported on macOS and Windows. 

Please expand the section that relates to your server OS:

1.1 macOS Central Upgrade

1.2 Windows Central Upgrade

2. Launch FileWave Central (FileWave Admin) to Confirm the Upgrade

3. Upgrading your FileWave Boosters

4. Upgrading the FileWave Client

Upgrading the FileWave client is not required immediately after upgrading the FileWave server but is highly recommended. Older versions of the FileWave client are compatible with newer releases of FileWave. When you are ready to upgrade your FileWave clients, simply deploy the provided Fileset to do so.

Never deploy the Custom Client PKG/MSI to the devices as a way to upgrade them. They are only for devices that are not currently enrolled in FileWave. Only upgrade the client using the Upgrade Fileset.

4.1 Upgrading your macOS clients

4.2. Upgrading your Windows Clients

5. Upgrading the iOS/iPadOS App Portal IPA

6. macOS DEP and Windows MDM: Upgrade Client Packages

Related Content

• Upgrading your On-Premise FileWave Server
• FileWave Downloads

Upgrading your On-Premise FileWave Server

What

Needing to upgrade your on-premise FileWave server? This guide will go over the steps involved in updating your FileWave server for macOS, Linux, and Windows.

If your FileWave server is hosted by FileWave, you may review the KB article here: Your Hosted FileWave Server Has Been Upgraded - What Are Your Next Steps?

When/Why

What steps do you need to take to continue managing your devices? This article will guide you to upgrade your FileWave Central/Admin application and your FileWave clients, boosters along side creating custom installers for your macOS DEP enrolled and Windows MDM devices.

How

This guide will go over the steps involved in updating your FileWave on-premise server for macOS, Linux, and Windows.

Before upgrading, please visit the Known Issues tab of the Known Issues.

For best results, upgrade the FileWave components in the following order: 

1. Lock Desktop and iOS Clients
2. Backup your FileWave server
3. Upgrading the FileWave Server software
4. Upgrading FileWave Central (FileWave Admin Native App)
5. Launch FileWave Central (FileWave Admin) to Confirm the Upgrade
6. Upgrading your FileWave Boosters
7. Upgrading the FileWave Client
8. Upgrading the iOS/iPadOS App Portal IPA
9. macOS DEP and Windows MDM: Upgrade Client Packages

1. Lock Desktop and iOS Clients

It's always a good idea to lock all your client devices before upgrading your FileWave components. That way you can verify that the server is running correctly and not worry about your macOS and Windows clients getting any of the changes.

1. Highlight all of your Desktop devices → right click → select "Lock". 

2. Change the filter to mobile, highlight all iOS devices → right click → select "Lock"

What is a Lock?

See Locking Devices

2. Backup your FileWave server

There are two ways to do so depending on your server. If you are running a Linux or macOS server you need to use the backup script that we provide to backup your server. Please always run a manual backup with the script we offer before starting the upgrade. We offer this knowledge base article for this process and the commands you will need to run as well as a way to check the backup file. 

If you are running a virtual machine for your FileWave server you are still able to use the backup script we offer but are also able to take a snapshot of the server in your virtual environment as a backup. Before taking the snapshot of the server please turn off the virtual machine so that FileWave server services are not running when you are backing up the Virtual Machine. This will prevent any issues with fragmented information in the backup.

If you do not want to stop the VM, you can use the below commands to stop the FileWave services and then take the backup. 

Stop the FileWave Server Services (for VM Snapshot only)

sudo fwcontrol server stop

After the backup is complete, please start the services again using the following command

sudo fwcontrol server start

3. Upgrading the FileWave Server software

Once you have a backup of your FileWave server created you will first Upgrade the FileWave server software before upgrading your FileWave Central (FileWave Admin Native) app, FileWave boosters, or FileWave clients. If you upgrade your FileWave clients' software first before upgrading the server, for example, your clients may break the connection to the server. Upgrading the FileWave server is not as intimidating as it may seem as it is an in-place upgrade and you do not need to uninstall anything first or stop the FileWave server services. Below you will find sections for macOS, Linux, and Windows Server.

3.1 macOS Server Upgrade

3.2 Linux Server Upgrade

3.3 Windows Server Migration

4. Upgrading FileWave Central (FileWave Admin Native App)

FileWave Anywhere (Web Admin) is automatically updated with the Server.

To connect to your upgraded server, you will need to use the same version of FileWave Central (FileWave Admin Native) unless stated otherwise on the Downloads page. When you are updating FileWave Central (Admin) simply run the installer for your designated OS.

The installer does not require the old version to be uninstalled and is similar to running a PKG or MSI for any other software. FileWave Central is supported on macOS and Windows.

4.1 macOS FileWave Central

4.2 Windows FileWave Central

5. Launch FileWave Central (FileWave Admin) to Confirm the Upgrade

6. Upgrading your FileWave Boosters

7. Upgrading the FileWave Client

Upgrading the FileWave client is not required immediately after upgrading the FileWave server but is highly recommended. Older versions of the FileWave client are compatible with newer releases of FileWave. When you are ready to upgrade your FileWave clients, simply deploy the provided Fileset to do so.

Never deploy the Custom Client PKG/MSI to the devices as a way to upgrade them. They are only for devices that are not currently enrolled in FileWave. Only upgrade the client using the Upgrade Fileset.

7.1 Upgrading your macOS clients

7.2 Upgrading your Windows Clients

8. Upgrading the iOS/iPadOS App Portal IPA

9. macOS DEP and Windows MDM: Upgrade Client Packages

If you have upgraded every client, booster, and IVS above FileWave 13.1, you can disable Compatibility Mode: What is Compatibility Mode?

Related Content

• Your Hosted FileWave Server Has Been Upgraded - What Are Your Next Steps?
• FileWave Downloads

Reset root password through Webmin (FileWave Appliances Only)

When you setup a new FileWave instance, you most certainly don't want to leave the password for the root user as filewave.  This document walks you through changing the password using the included Webmin interface (on v 12.x and higher virtual appliances only).

Step-by-step guide

1.  First, we simply need to login to the Webmin interface through your browser of choice.  You'll be able to find the address to use from the VM window itself as shown below:

2.  Now, take that address and place it in your browser.  Note that you'll get a warning about the certificate...this is simply because it is a self-signed cert.  You can ignore that warning and proceed to the site:

Note that the Webmin interface is on port 10000, so that port will have to be open from your workstation to the server for the website to work correctly.

3.  When you first get to the site, you'll be presented with a login window.  The user will be root, and the password will be filewave as the default (or a password you have already changed it to):

4.  Once logged in, we'll go to the System section, and click on the link to Change Passwords:

5.  Then, we'll choose the root user:

6.  Just enter and confirm your new password, then click the Change button:

7.  You'll get a confirmation that the password was successfully changed:

8. That's it! You have successfully reset/changed your FileWave appliance root password.

Migrating your On-Premise FileWave Server to new Hardware

Migration Process

When looking at migrating your FileWave server we recommend contacting our FileWave support team for an explanation of this process if any part of it doesn't make sense. Migrations are safe for you to do as long as you make sure you ensure that you Lock your clients and use the latest Backup script as mentioned in the next sections of this guide. If you'd like to hire Professional Services to do this entire process with you, we have a simple flat rate for migrations. 

Your existing FileWave Server must be version 13.3.1 or higher before you can upgrade to FileWave 14.7.2 and then from 14.7.2 you can upgrade to 15.2.1.  The minimum memory requirement for FileWave 14+ is 8GB and ensure you give at least the same amount of disk space to the new Server. Larger Servers can benefit from more RAM, CPU, and SSD storage.

If you need an older install of FileWave to complete this migration you should be able to find it in Downloads.

The below table gives you an example of the path to get to the latest FileWave running on Debian. Note that you can also run macOS for FileWave Server, and that is included in the steps of this article. As of December 2023, it is preferred to set up a new Server on Debian Linux, and the below table should help you understand how to get there. We are not planning on dropping macOS support for FileWave Server.

1. Lock Desktop Clients

You must Lock all of your Desktop clients before migrating your FileWave server. That way, you can verify that the new server is running correctly and prevent issues with your macOS and Windows Clients if the migration is not successful. To Lock the clients, highlight all of your Desktop devices → right click on them → select "Lock" and then perform a Model Update so that the server database is 1 model ahead of clients.

Locking a device binds that client to the current model number. Meaning, that if something unexpected should happen during a migration or update, a connecting client ignores the new manifests from the server. See: Locking Devices

2. Backup your FileWave server for the migration

The backup you create for your FileWave server is what you will use to migrate your server to your new hardware. For this, you will need to use the backup script that we provide to backup your server. This is the only way to make sure you pull all of the necessary files to your new server and will not lose any information. We offer this knowledge base article for this process and the commands you will need to run as well as information on checking the backup file. 

The backup script is changed. Even if you currently use the script, please check that you are using the latest version.

Ideally, you would download the script and make sure there is enough free space and then run a command like the below one to make a fresh backup folder that has all of your config files and data. 

# Replace "path_to_script" with the actual path to the backup script
# and if you renamed the script then use that new name.
# Also if it doesn't run be sure to "sudo chmod +x /path_to_script/backup_server_osx_linux.sh" to
# make it executable.
sudo /path_to_script/backup_server_osx_linux.sh run /tmp manual

Once you have created the backup folder with the script we offer, shut down the FileWave server services so that you do not make any changes after running the backup that will be used to migrate servers. You would find "fw-backups" in /tmp if all went well. You can choose a different location if that makes sense for your storage setup. If you make changes on the old server after the backup, the changes will not move over during the migration. To stop the services, you can run the below commands. Do not shut off the old server completely, because this Backup file will need to be transferred in the next few steps.

Do not delete or wipe the old server yet! It is always best to keep the old server and just turn it off for a few weeks after the migration just in case you need any information from the server. 

2.1. Stop the FileWave Server

macOS / Linux

sudo fwcontrol server stop

Windows

In an Administrator Command Prompt, run the following command. You can also stop all FileWave Services using the Services tool.

fwcontrol server stop

3. Migrating to the new Server

Once your backup is completed, it is time to start the migration process to your new FileWave server.

If you have any questions about the process or would like assistance on this, please contact our FileWave support team and they will be able to assist you with this. Also, during the process, if you run into any issues or errors, please contact our support team as soon as possible so they can assist you.

3.1. Download FileWave Server for your new hardware or VM

If you want to Migrate to a Linux Virtual Server, we offer a pre-built appliance that you are able to bring up in your Virtual Environment. You would go to the FileWave Management Suite Downloads page. Scroll to the bottom of the software downloads page for the version of FileWave you need, and you will see the links to download a Virtual Server appliance. 

You need to migrate the server to the same version of FileWave that you are currently running. For example, if you are running FileWave 12.1 you must migrate to a FileWave 12.1 server. If you try to migrate from a FileWave 12.1 server to FileWave 12.3 the migration will fail.

If you feel more comfortable installing a clean Debian Linux instance you can also find the .deb installers and instructions on the same download pages. Note that you can run your Linux server in any environment that you like such as Linode or contact Customer Experience about our own hosting solution.

3.2. Setup of the new Server

Initially you will need to have the new Server on a new IP address so that the old Server and the new one can both be online to copy the data over. After the next migration steps there is a step that talks about having the old IP / DNS name on the new Server. For the moment don't make that change. When the replacement server takes on the IP address it should also then be ok for Firewall rules. As a reminder the needed ports are here: Default TCP and UDP Port Usage

For the setup steps of the new server follow this guidance: FileWave Server Setup to ensure that you change the root password and please keep in mind that SSH should not be exposed to the Internet. Once the server is installed on the new host you can continue with the next steps to copy the data and database over to the new host. 

If you find that you need more space in your Linux Appliance then see Expanding the Disk on a FileWave Appliance - CentOS / Debian for the commands to expand the volumes once you set VMWare/HyperV/VirtualBox/UTM to have a larger volume size set.

Also be aware that when you next run apt update and apt upgrade it will clear out /tmp so if you migrate your backup to /tmp on the new server just keep in mind you should not do an OS update until you have completed the migration or you will have to re-copy your data to the new server since /tmp would get emptied before you are ready.

3.3. macOS or Linux server → macOS or Linux Server

This will be the most common migration path moving from macOS or CentOS or even another Debian system to a new Debian Linux system. The folder structure and commands are the same no matter which way you are migrating with these OS. If coming from Windows there is a note on the Database step of restore, but you will almost certainly need help moving from Windows.

If you are using the Virtual Appliance that we offer for Linux you will not need to install the server as it comes pre-installed. Just remember that for a migration the original and new server must be on the same version. If you are migrating to Debian that means upgrading your CentOS or macOS Server to 15.2.0 or higher in order to have a Debian release that aligns with it. For macOS you'll want to consider if the version of FileWave that you are running on the old server is supported on the new one as well.

1. On your workstation go to FileWave Management Suite Downloads Page. (You will select the same release that you are running on your current server. For the screen shots I am migrating to a FileWave 15.2.1 server) 

2. For Linux you will then scroll down on the page until you see "Virtual Appliance Downloads". Follow the steps in FileWave Server Setup to at least get an IP address and change the root password on the new appliance. You would want to use a different IP than your old server for now so that you can copy files from the old server to the new one.  For macOS you can download the FileWave Server from the macOS Downloads section of the page.

   

3. Next step would be to connect to your FileWave server. For this there are a few options you are able to use depending on if you are running a macOS or Windows computer as your workstation or if you have direct keyboard/monitor access to the new server. Two options you are able to do is to use ssh to the server using Terminal on macOS or use putty on a Windows machine. For macOS keep in mind that SSH is not enabled by default so you may want to enable it so that you can scp files over or ssh in to it. You'll want to become root if you are not already:
   

   sudo -s

4. Once the new server is on your network and reachable, you will Stop the FileWave server services that are running on the new server so that you can restore the backup to it. At this point FileWave should not be running on either the old or the new server.

   fwcontrol server stop

5. Now we will copy the FileWave backup that you created previously on your old server to the new server. You are able to do this however you would like. Two ways that are most common is by copying the backup to a network share or using scp command on the server. You will need to copy all of the files created in the "/tmp/fw-backups" folder including the zipped folder, Data Folder, ipa folder and any other contents. We would suggest moving it to the /tmp directory on your new FileWave server to keep things simple. For all example commands we will show from that directory.
   
   

   scp example copying to a new server 192.168.1.10 using root on the remote server. In this example this command is run from the original server and is copying file over to the new server. For macOS remember that root is not enabled by default so use your admin user:

   scp -r /tmp/fw-backups root@192.168.1.10:/tmp

   rsync example copying to a new server 192.168.1.10 using root on the remote server. In this example this command is run from the original server and is copying files over to the new server. For macOS remember that root is not enabled by default so use your admin user:

   rsync -avz /tmp/fw-backups/ root@192.168.1.10:/tmp/fw-backups/

   All command examples will be shown as if the backup is in the /tmp directory
   

   
   

6. Once the backup has been successfully copied to the new server the next step is to unzip the tar.gz file that is inside of the "/tmp/fw-backups" folder. This zip file contains the configuration and Database files that you will be using for the migration.
   
   Run this command to become root if you didn't already on the last step because all of the next steps will need it.
   

   sudo -s

   Move to the location of the backup file. My backup is in the /tmp/ directory of the server.
   

   cd /tmp/fw-backups/

   Then unzip the tar.gz file. The file will be named based on the date it was made.
   

   tar -xf *.tar.gz

   Compare Data Folders
   After the files are transferred and unzipped, compare the size of your Data Folder to the one on the original (old) server. You can see this by navigating to the backup files and running the following command. The Data Folder is located in /usr/local/filewave/fwxserver/ on the original server. They should be the same size. If the transferred Data Folder is considerably smaller than the original, redo the transfer.
   
   Command on original server:

   du -hsx  /usr/local/filewave/fwxserver/Data\ Folder/

   Command on the new server:
   

   sudo -s
   du -hsx  /tmp/fw-backups/Data\ Folder/

    

7. The next step is to start moving files from your backup to locations on your new FileWave server. You will need to replace the files already in the location. For the commands below we will move the file that is at the location of the new server so that you are available to replace it easily with your backup. For the commands below the backup is located in the "/tmp/fw-backups" directory of the new server. The commands will be slightly different on your server depending on your file path and name of the backup folder since it is named by default with the day and time the backup was taken.
   
   Move the default certs folder to be called certs.bak
   

   mv /usr/local/filewave/certs /usr/local/filewave/certs.bak

   Copy the "certs' folder from your backup
   

   cp -r /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/certs /usr/local/filewave/

   Move the default media folder to be called media.bak
   

   mv /usr/local/filewave/media /usr/local/filewave/media.bak

   Copy the "media" folder from your backup - Sometimes this will be empty
   

   cp -r /tmp/fw-backups/media /usr/local/filewave/

   Move the default ipa folder to be called ipa.bak

   mv /usr/local/filewave/ipa /usr/local/filewave/ipa.bak

   Copy the "ipa" folder from your backup - Sometimes this will be empty
   

   cp -r /tmp/fw-backups/ipa /usr/local/filewave/

   Copy the fwxcodes license file from your backup
   

   cp /tmp/fw-backups/fwxserver-Config-DB*/fwxcodes /usr/local/etc/fwxcodes

   Copy the user_postgresql.conf from your backup 

     cp /tmp/fw-backups/fwxserver*/user_postgresql.conf /usr/local/filewave/conf/

   Copy the settings_custom.py file from your backup
   Note: The settings_custom.py file contains tweaks that have been applied to your specific server. You may want to review the contents of this file to ensure that you still want those tweaks in place. 

   cp /tmp/fw-backups/fwxserver-Config-DB*/settings_custom.py /usr/local/filewave/django/filewave/settings_custom.py

   Grafana
   If you use Grafana then you will likely want to copy over your YML files and database. If you do not have any dashboards that you have setup then you can ignore this step.
   

   cp -f /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/grafana.db /usr/local/filewave/instrumentation_data/grafana/
   cp -f /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/prometheus_http_jobs/* /usr/local/etc/filewave/prometheus/conf.d/jobs/http/
   cp -f /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/prometheus_https_jobs/* /usr/local/etc/filewave/prometheus/conf.d/jobs/https/

   fwcld Folder
   Copy the custom MSI or PKG if they exist. If they are not in your backup then you can ignore this step.
   

   cp -f /tmp/fw-backups/fwcld/FileWaveClient.msi /usr/local/filewave/fwcld/
   cp -f /tmp/fw-backups/fwcld/FileWaveClient.pkg /usr/local/filewave/fwcld/

   Data Folder
   

   If you are running FileWave server version 13.1.5 the fwxserver folder has moved to /usr/local/filewave/fwxserver. Please note the server versions differences below:

   
   Backup the default "Data Folder" folder to be called Data Folder.bak
   

   mv /usr/local/filewave/fwxserver/Data\ Folder /usr/local/filewave/fwxserver/Data\ Folder.bak

   Move the "Data Folder" from your backup. Note that if you are moving to FW 13.1.5 or higher this ends up in /usr/local/filewave/fwxserver/ and below that it goes in /fwxserver/ but we are moving the folder so as not to consume all the drive space by having 2 complete copies of it on the new server.
   

   mv  /tmp/fw-backups/Data\ Folder /usr/local/filewave/fwxserver/

   Apache files

   Backup the "httpd_custom.conf" file on the new server

   mv /usr/local/filewave/apache/conf/httpd_custom.conf /usr/local/filewave/apache/conf/httpd_custom.conf.bak

   Copy the "httpd_custom.conf" file from your backup

   cp -r /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/httpd_custom.conf /usr/local/filewave/apache/conf/

   Backup the "mdm_auth.conf" file on the new server

   mv /usr/local/filewave/apache/conf/mdm_auth.conf /usr/local/filewave/apache/conf/mdm_auth.conf.bak

   Copy the "mdm_auth.conf" file from your backup

   cp -r /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/mdm_auth.conf /usr/local/filewave/apache/conf/

   Move the passwd files from the backup to the new server

   Move the "passwords" and "passwords.digest" file from the new server. (You may not have a passwords.digest file. If so you can skip without any issues)

   mv /usr/local/filewave/apache/passwd/passwords /usr/local/filewave/apache/passwd/passwords.bak
   mv /usr/local/filewave/apache/passwd/passwords.digest /usr/local/filewave/apache/passwd/passwords.digest.bak

   Copy the "passwords" and "passwords.digest" file from the new server. (You may not have a passwords.digest file. If so you can skip without any issues)

   cp -r /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/passwords /usr/local/filewave/apache/passwd/
   cp -r /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/passwords.digest /usr/local/filewave/apache/passwd/

   
   

8. The next step is to get the database restored on the new server.
   
   Database restore
   Open a terminal session and give yourself root access for the next commands if you are not already root from the prior steps. After entering the command you will need to type in the admin credentials for the new server. 

   sudo -s

   First, you need to start the postgres process on your new FileWave server. You can do so with the below command.

   FileWave server 13.1.5 and newer:
   

   sudo -u postgres /usr/local/filewave/postgresql/bin/pg_ctl start -w -D /usr/local/filewave/fwxserver/DB/pg_data -m fast

   FileWave server 13.1.3 and below only. Do not use the next command with anything newer:

   sudo -u postgres /usr/local/filewave/postgresql/bin/pg_ctl start -w -D /fwxserver/DB/pg_data -m fast

   Once postgres has been started you will now need to access the Database on the server using the below command. 

   /usr/local/filewave/postgresql/bin/psql postgres postgres

   Then you will need to drop the MDM table of the database

   drop database mdm;

   Create a table you are then able to restore your mdm-dump.sql file to

   create database mdm OWNER postgres ENCODING 'UTF8' TEMPLATE template0;

   Quit out of the Database with the below command:

   \q

   Now you need to run the restore on the mdm-dump.sql file on your new server. You can do so with the below command. For my command the "mdm-dump.sql" file is located in the "/tmp/fw-backups" directory but the command you run will match the location of your backup. This command can take a little while to run. If you see any errors at the end of the output there is most likely an issue with the migration and please contact our FileWave support team for assistance.  If you are migrating from FileWave Server on Windows please see 3.2.2. Windows Server → macOS or Linux before running the next command.

   /usr/local/filewave/postgresql/bin/psql -U postgres mdm < /tmp/fw-backups/fwxserver-Config-DB-Jan-12-18--10-34/DB/mdm-dump.sql

   Once the command finishes we will now need to start running the migration for the Database manually. First migration you will run with the below command. 

   /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc migrate --no-input --fake-initial

   Then we will need to do a server migration which can be done with the command below. 

   /usr/local/sbin/fwxserver -M

    

9. Run the FileWave Server Repair Permissions script with sudo to fix the server's folder permissions and ownerships. If you do not do this step, then your server may not work correctly until you do.
   
   

10. After the permissions repair command finishes you are almost done with migrating the information for the server. The next step is to restart the FileWave services to start checking if the migration has completed successfully. This can be done with the below commands to stop and start the services. 
    
    

    Stop the FileWave services:
    

    fwcontrol server stop

    Start the FileWave services:
    

    fwcontrol server start

    If you find that the fwcontrol control command is not found, you re-create the alias by inputting this command and then try the fwcontrol commands again:
    

    alias fwcontrol='/usr/local/bin/fwcontrol'

11. With the FileWave server services started you are now done with migrating the Data on the FileWave server and Move on to Checking the migration in the FileWave Admin. Do not change your IP or DNS to match that of the old server yet. This will be one of the last things you do so you can make sure everything is correct before having your devices connect to the new server. 

3.4. Windows Server → macOS or Linux

Because of the complexity of moving from Windows Server please connect with Professional Services & Training to get some assistance. The Windows version of FileWave Server is so old that this is a multi-step process involving the migration to CentOS followed by the migration to Debian. 

4. Launch FileWave Central to confirm the Migration

The next step once the migration is complete is to Launch the FileWave Central Admin application to connect to the newly migrated server. After a migration, you always want to connect to the server and verify everything is running and working correctly before you make any changes to the IP or DNS address. Please be sure to open FileWave Central and not the web admin (FileWave Anywhere), then proceed to step 4.1.

If you change the IP address or DNS reservation first before confirming the migration was successful you run the chance of your devices losing Filesets and un-enrolling themselves. Do not hesitate to contact our Support Team quickly if you think there may be an issue so that we can help get you back up and running quickly. 

4.1. Clear the Keys

When you try to log in to FileWave Central Admin, you will likely get an error because the server is not at its original address. There is a simple command to clear the keys that would prevent login that you may need to do when first logging in and then later when you update the server to its final IP/Name which should match the original server.

To clear the keys you will connect via SSH or Terminal to the server and type;

sudo /usr/local/filewave/python/bin/python /usr/local/filewave/django/manage.pyc shell

Next enter the following;

from fwserver import name_value_pair
from filewave.fw_gpb.FWServerMessages_pb2 import MdmServerConfiguration
name_value_pair.set_mdm_server_configuration(MdmServerConfiguration())
 
from filewave.fw_gpb.FWInventoryMessages_pb2 import DjangoServerData
name_value_pair.set_inventory_server_configuration(DjangoServerData())
 
from ios.preferences_manager import PreferencesManager
PreferencesManager.set_shared_key('')

And you should get another prompt where you can type quit() and press return to exit. Below is an image of what this should look like:

After clearing the keys, you will have to restart the FileWave services.

fwcontrol server restart

Now you should have success logging in with FileWave Central.

4.2. Login to FileWave Central

1. Log in to the FileWave admin to your new server. You will need to enter the IP address of the new server as you have not changed any of the DNS or IP information yet. 

2. Once you are logged in you will need to open and close Preferences to save the new keys that were cleared in the previous step. To do so go to FileWave Admin → Preferences → "Mobile" tab → select "OK" to close Preferences. This will save the new keys.

3. First thing to check in the FileWave admin is the warning light in the bottom left hand corner. You are looking for it to say "Everything is OK" as shown below. If you have any warning or errors this may be an issue with the migration but is not necessarily depending on what is giving the error. If you see the light as yellow or red please select the message to view the error. Messages and their severity are listed below the image. 
   

   

   • APN, If you are using iOS and this is anything but green please contact our Support Team

   • Inventory, if this is anything other then green contact our Support Team

   • GCM, if you are using Android or Chromebooks and this is not green contact our Support Team

   • DEP, if this is yellow or red please open FileWave Admin → Preferences → VPP & DEP tab → OK, to close preferences. If it is still giving an error contact our Support Team. 

4. Second thing to check is to make sure Filesets are showing. The easiest way to do this is to select the Filesets tab of FileWave admin and make sure you see your Filesets and structure. If you are having issues contact our Support Team. 

5. If you have iOS devices, Select "iOS Inventory" to make sure you see rows of iOS device information. Also select "Refresh" from the top menu to make sure this information refreshes. The devices will not check in yet since the IP/DNS information has not been changed but you should see rows of information. If you receive any errors or information is not showing please contact our Support team. 

6. Go to the Clients tab of the FileWave Admin and make sure you see your correct group structure and your Clients showing. If you do not please contact our Support team. Remember your FileWave Clients will not check in yet since the IP/DNS information has not been changed on the new server

As long as everything is green and showing correctly you are now ready to move on to changing the IP and DNS information so your devices will see the new server. 

5. Changing the IP / DNS to match that of the old FileWave Server

Now you are able to change the IP or DNS information on the new server to match that of the old FileWave server. You are able to change your IP address on the new server so that it matches the old server or Change your DNS record for your FileWave server to point to your new server's IP address. If your old server was only using IP and not a DNS name you will need to make sure the IP does not change.

5.1. Changing the IP address

5.2. Changing the DNS record

For changing the DNS record to the new FileWave server you would change the DNS entry in your DNS servers and allow the new entry to propagate out to your computers. If you are using the same IP on the new server that you were previously using for your old one then there will be nothing to do here because the DNS record is already associated with that IP. It will also simplify any firewall changes because if you keep using the same IP then your firewall rules should remain the same as well.

6. Checking your FileWave server after the IP address/DNS entry is changed

Steps will be similar to what you checked previously, but now you will point the Admin to the DNS address and make sure your devices are checking in.  Do not hesitate to contact our Support Team quickly if you think there may be an issue so that we can help get you back up and running quickly. 

Unknown User Error?: Refer back to 4.1 Clear the Keys if you get an error when trying to login now that the migrated server is on a new address.

1. Repeat the checks in 4.2. Login to FileWave Central to check that everything is still good.
2. Now you will do an Update Model to ensure that it is functioning before taking the next steps to Unlock Clients.

Model Update is very important at this step before unlocking clients.

7. Unlock Clients

1. Go back to the FileWave client tab and unlock one or two clients that you know are on to make sure they are checking in correctly. We suggest checking a couple machines first before unlocking all of your clients. 
   

   

2. After you make sure the couple of test devices you unlocked first are working correctly you can select all of your devices and unlock them. 
   

8. Completed

You are now done checking the Server after the migration. If you have any issues do not hesitate to contact our FileWave support team as soon as possible so that we are able to assist you. Please do not destroy your old server for 30 days after the migration in case a problem is discovered with the migration. Keep the old server shut down so that you don't find that it comes online again and conflicts with the IP address of the new server or that clients might reach it and become confused.

Please remember to set up FileWave Server Backup on the new server because you will need to configure the script to run automatically. When setting up backups you should have the destination be a volume that is not locally on the server, and does not share the same network storage location. If there is a failure of your disk storage solution you do not want to lose both your FileWave Server as well as the backup information. 

Related Content

• Securing FileWave Server on the Internet for Remote Device Management
• Booster Overview
• Upgrading your On-Premise FileWave Server

FileWave Server Pre-Upgrade Backup

What

In order to ensure data integrity during upgrade, version 14 of FileWave introduces a pre-upgrade backup utility to make doubly sure that the FileWave database and configuration files are protected.

When/Why

This additional layer of security protects us from a catastrophic failure during upgrade, and the backup happens automatically.  Note that the backup copies the database (the very most important item), necessary configuration files and certificates.  It does not however backup filesets (payloads) as those would be far too large to backup, and that content itself is not particularly at risk. 

For best results, always make sure you have a good (preferably off-server) backup of you FileWave installation updated at least weekly.  If you do not do this, and you have a disk failure, you run the risk of having to rebuild and re-enroll all of your devices.  Trust us...that is no fun at all.

How

Given that everything is automatic during the upgrade process, you don't have to worry about doing anything for this backup, but for your own information, these backups are stored in: 

/usr/local/filewave/fwxserver/Data Folder/backups

Does FileWave support 2FA / MFA?

Question

Does FileWave support 2 Factor Authentication (2FA) / Multi-Factor Authentication (MFA) when logging in to the FileWave Central or Anywhere admins? Does FileWave support 2FA/MFA for devices enrolling?

Step-by-step guide

If you follow the steps to set up the FileWave Identity Provider (IdP) Integration with a supported SSO provider then if that provider supports 2FA / MFA you would be able to utilize that for login to both the Native and the Web Admin. For enrollment of devices, you can also use this. You will see in the WebAdmin that there is a checkbox for Enrollment or Admin depending on which you want to use with SSO. In the below image both are selected. 

Related Content

• Identity Provider (IdP) Integration
• IdP Setup: Microsoft Entra ID
• IdP Setup: Okta
• IdP Setup: Google

Configuring LDAP authentication

You can use pre-designated, fixed account names and passwords to enroll devices in MDM, or you can use your existing LDAP (Active Directory, eDirectory, Open Directory) database as the credentials for enrollment. To set this up, you will edit a configuration file on your FileWave server. This can be done at any time during your server setup; as long as it is complete before you begin enrolling MDM clients.
This process consists of:

1. 1. Backing up the current config file;
   2. Editing a new config file to properly read the LDAP structure; and,
   3. Restarting the Apache Process so it reads the new config file.

Getting the files ready

• Open a Terminal Window or use SSH to get into the computer running FileWave Server
• Gain root credentials

sudo -s

• Enter your login password
• Navigate to the FileWave Apache configurations folder:

cd /usr/local/filewave/apache/conf/

• Backup your current mdm_auth.conf by making a copy

cp mdm_auth.conf mdm_auth.conf.bac

• Make a copy of the LDAP example and rename it

cp mdm_auth.conf.example_ldap_auth mdm_auth.conf

• Making the changes
• Open mdm_auth.conf up using your preferred text editor (nano mdm_auth.conf or vi mdm_auth.conf). Make the appropriate changes (the sample file is appropriately commented) and then save the .conf file.

You can also use the Finder to locate the file, then drag a copy to your Desktop and edit it with a text editor, such as TextWrangler.

When done, you will delete the copy in the .../conf/ folder and replace it with your edited copy.)
Note: Active Directory (AD) by default requires you bind to the directory to read. Many people create a read-only directory account.

• Once saved, restart the FileWave Apache process/service:

/usr/local/filewave/apache/bin/apachectl graceful

Now, when a user attempts to enroll a device in your MDM server, he or she will use their LDAP credentials to authenticate.

Related Content

• LDAP Preferences
• Using LDAP to enroll macOS/iOS/Android devices
• LDAP Admin Integration
• Deployments Targeting LDAP Groups

Maintenance

Webmin GUI (On-Premise)

Webmin GUI

For an on-premise installation of FileWave the Webmin GUI can help you set some options on the centOS operating system. Note that this does not exist for servers hosted by FileWave. It’s especially important to set the root password as seen below.

For Webmin on Debian know that you will need to go to Webmin -> Webmin Configuration -> Operating System and Environment and make sure it's set to Debian 12.4 (Or whatever version we are at when you set up your system. You can see this with cat /etc/debian_version on the server.

1. At the login screen note the URL to remotely manage the server, ex: https://myorg.filwave.net:10000

   • If there is no IP address specified because DHCP is not available on the subnet for your FileWave Linux Appliance, login with the username "root" with password "filewave".

   • Run "nmtui" at the command prompt to launch the Network Manager Text UI so you can configure the networking for the FileWave VM appliance. You'll need to reload the IP stack with "service network restart". Skip the network configuration steps later in the Webmin.

2. Browse to this URL and log in with username "root" and password "filewave". We will change this password later.

3. Browse to Hardware > System Time on the left, pick the Change timezone tab on the right, pick your time zone and click Save. North American time zones all start with "America".

4. Switch to the the Time server sync tab, enter "pool.ntp.org" in the Timeserver hostnames or addresses field, set Synchronize on schedule? to "Yes, at times below", and click the Sync and Apply button.

5. Go to System > Change Passwords on the left and select the "root" account on the right from the list of usernames. Enter a new root password, confirm it, and click Change. Note that this will change the default password for the root account used to log into the server from "filewave" to whatever you choose so enter a secure password that is easy for you to remember.

6. Choose Networking > Network Configuration on the left, and Network Interfaces on the right. Click the blue link labeled "ens160" or "ens32" for the Ethernet adapter. Change the IPv4 address settings to "Static configuration", enter a static IP, enter a subnet mask, and click Save and Apply at the bottom_._

7. You will no longer be able to access the Webmin UI for the FileWave servers via its old DHCP IP address. Change the address in your browser's address bar to use the new static IP address for the FileWave server that you configured in the previous step. Browse to Networking > Network Configuration on the left, and Hostname and DNS Client on the right. Enter the IP address for your DNS server and click Save.

8. Select Networking > Network Configuration on the left, and Routing and Gateways on the right. Pick "ens160" or "ens32" from the Default routes pull-down, enter the default gateway address for the subnet the FileWave server is hosted on, and click Save.

9. Go to S_ystem > Bootup and Shutdown_ on the left, scroll to the bottom on the right, and click the Reboot System button. When asked to confirm if you want to reboot the system with "shutdown -r now" click the Reboot System button again.

Related Content

• 1. Installation and Setup

Webmin GUI - Changing the root password (On-Premise)

What

Webmin is included in the FileWave appliances to allow you to easily configure the system. This is only relevant if you run a FileWave server yourself on-premise. For customers who have their server hosted by FileWave you do not need to worry about these steps.

When/Why

The first important thing is to not allow any traffic to TCP 10000 on your server except from networks you will connect to it from. There is no reason to expose this port to the Internet. The second item is to be sure you change the root password on your appliance from the default. This is mentioned in FileWave Server Setup but this step is very important.

How

1. At the login screen note the URL to remotely manage the server, ex: https://myorg.filwave.net:10000

   • If there is no IP address specified because DHCP is not available on the subnet for your FileWave Linux Appliance, log in with the username "root" with the password "filewave".

   • Run "nmtui" at the command prompt to launch the Network Manager Text UI so you can configure the networking for the FileWave VM appliance. You'll need to reload the IP stack with "service network restart". Skip the network configuration steps later in the Webmin.

2. Browse to this URL and log in with username "root" and password "filewave".

3. Go to System > Change Passwords on the left and select the "root" account on the right from the list of usernames. Enter a new root password, confirm it, and click Change. Note that this will change the default password for the root account used to log into the server from "filewave" to whatever you choose so enter a secure password that is easy for you to remember, but it should be a long and complex password or you should take steps to configure SSH to only allow connections with a certificate. The FileWave server is a full Linux OS and can be managed like any other.

Related Content

• Webmin GUI
• FileWave Server Setup

Expanding the Disk on a FileWave Appliance - CentOS / Debian

This article provides steps for extending the root partition residing in a logical volume created with Logical Volume Manager (LVM) in a virtual machine running CentOS or Debian.

Step-by-step guide for CentOS

fdisk -l

fdisk -l

pvcreate /dev/sda3

vgextend centos /dev/sda3
# or newer servers with volume name changes
vgextend centos_filewave /dev/sda3

vgdisplay centos | grep "Free"
# or newer servers with volume name changes
vgdisplay centos_filewave | grep "Free"

lvextend -l +100%FREE /dev/centos/root
# or newer servers with volume name changes
lvextend -l +100%FREE /dev/centos_filewave/root

resize2fs /dev/centos/root
# or newer servers with volume name changes
resize2fs /dev/centos_filewave/root

xfs_growfs /dev/centos/root
# or newer servers with volume name changes
xfs_growfs /dev/centos_filewave/root

df -h /

Step-by-step guide for Debian

apt update && apt install -y cloud-guest-utils
growpart /dev/sda 2 || true
growpart /dev/sda 5 || true
pvresize /dev/sda5
lvextend -l +100%FREE /dev/mapper/filewave--vg-root
resize2fs /dev/mapper/filewave--vg-root

Related Content

• Downloads
• FileWave Server Installation

Set date/time on Virtual Appliances

Description

Virtual Appliances are shipped with a default time zone.  This guide will explain how to change the current time zone and set a NTP server for syncing. This is highly recommended on the Server, Booster, and IVS appliances. Really every server and client you manage should use an NTP solution to keep the time in sync because synchronized time generally is needed for encrypted communications to not have errors.

Ingredients

• One of the virtual appliances, Server, IVS or Booster
• UDP port 123 open between Server and Remote Time Server

Directions

NTP needs to be installed.  This can be checked by doing:

$ yum list installed | grep ^ntp
ntp.x86_64                            4.2.6p5-28.el7.centos            @base    
ntpdate.x86_64                        4.2.6p5-28.el7.centos            @base 

If it is not there, you can install with:

yum -y install ntp

Setting a Time Server

The time may be synced with an NTP server by doing:

ntpdate pool.ntp.org

pool.ntp.org should resolve to the closest server available.  You may be specific though, e.g. for Singapore:

ntpdate sg.pool.ntp.org

For a full list of servers by their country code see: http://support.ntp.org/bin/view/Servers/StratumOneTimeServers

Or if you have your own internal time server, this could be used.

To permanently set a specific time server, edit the ntp.conf file: 

sudo vi /etc/ntp.conf

Either place a # before the current ntp servers set in the file and add the chosen ntp server instead or specify an additional server as a preference.  From the example above:

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
server sg.pool.ntp.org prefer

Start as Service

To start the service and ensure it is on after rebooting:

CentOS 7

systemctl start ntpd
systemctl enable ntpd

Setting the Time Zone

CentOS 7

Current status may be viewed with the following command, which will show amongst other things:

$ timedatectl status
    Time zone: Europe/Zurich (CEST, +0200)
    NTP enabled: yes
    NTP synchronized: yes

In this example, location is set to Zurich.  

All locations can be found with:

timedatectl list-timezones

To change the location involves running the following command with the chosen zone, taking the example of Singapore:

timedatectl set-timezone Asia/Singapore

Confirmation

Once completed, confirm the time and date:

$ date
Wed  5 Sep 17:30:01 +08 2018

Note +08, time difference for, in this case, Singapore

Store the FileWave Server/Booster Data on a Separate Volume

Requirements

• FileWave Server 13.1.5+

• Existing mount the external drive or network share

• Root access to Terminal

Summary

Many customers have asked us if there's a way to store their Server's data on a non-startup volume or on network shares.

Here you will find instructions for linking the Server's Data Folder to another location on macOS/Linux. You may follow these same steps for the Booster, accounting for small differences in folder names.

Having DB folder on a different Volume(symlink) slows the admin performance, please do not move the Database.

Before making any changes, please ensure you have a backup. If you're using a VM, please stop services and take a snapshot of the VM. If you're not able to take a snapshot, use the Backup script. You can find more information, and the script, here: Automated Backup

macOS/Linux

Step One: Stop the FileWave Server

Whenever doing any manipulation of the Server's Data Folder, you will need to stop FileWave's services first. You can do this by using the 'fwcontrol' command-line tool.

Command:

sudo fwcontrol server stop

Step Two: Move your Data Folder to another Volume

Move the Data Folder to your destination/mount point:

Command

sudo mv /usr/local/filewave/fwxserver/Data\ Folder /Path/to/Destination/

For those doing this with a Booster, the Booster data folder is in /var/FileWave/FWBooster.

Step Three: Create a link to your new data folder

Here we're creating a symlink to the recently moved Data Folder back to the original location. The FileWave processes will still look at the original location for the Data Folder and the symlink will redirect it to the new location.

sudo ln -s /Path/To/Destination/Data\ Folder /usr/local/filewave/fwxserver/

Step Four: Check the Link

Now that the link is established, we can check that it was made correctly. First, navigate to the original Data Folder location

cd /usr/local/filewave/fwxserver

Then view details about that destination

ls -lha

You should see the Data Folder symlink, which is the Data Folder directory with an arrow pointing to the 'real' location

For example:

Step Five: Start the Server

Restart FileWave Services

sudo fwcontrol server start

Now you're all set!

Windows Booster

Step One: Stop the Booster Process

Go to Control Panels -> Administrative Tools -> Services. Find the FileWave services and stop all of them.

Step Two: Move the Data Folder

The Booster’s Data Folder is in the following location:

C:\ProgramData\FileWave\FWBooster\Data Folder

Move this folder to the partition that you'd like to store the folder (eg: D: ). Rename/remove the original.

Step Three: Create a Junction

Similar to Mac OS, you can create a junction from the Command Prompt using the "mklink" command.

If you are creating a link to a local volume follow these steps:

1. Run your Command Prompt as Administrator (right-click -> run as Administrator)

2. In your command prompt type: 

   
   

   mklink /j "C:\ProgramData\FileWave\FWBooster\Data Folder" "D:\YOUR_PATH\FWBooster\Data Folder" 

3. Test your Junction by double-clicking the link in "C:\ProgramData\FileWave\FWBooster\Data Folder " and the target folder should be opened.

It is not recommended to create a link to a folder on a network-based share.

Step Four: Start the Server

Go back to the Services panel and start the Booster services back up. You’re all set!

Related Content

• Booster Installation

Upgrading to FileWave 13+ from older Versions on Systems where Port 443 is used

Description

FileWave 13 introduced a Web Admin interface.  By default this uses port 443.  Attempts to install on systems that have another service using this port will prevent the installation of FileWave.

To resolve this, remove or adapt the contending process or FileWave to use a different port.

Directions

Configuring FileWave to use a different port before the upgrade may be archived as follows:

Mac / Linux

Edit the /usr/local/filewave/apache/conf/httpd.conf file as follows : 

# Putting the last character in brackets is a trick to prevent Apache from issuing a warning if the file does not exist.
IncludeOptional conf/httpd_webadmi[n].conf

Create the /usr/local/filewave/apache/conf/httpd_webadmin.conf with the following content : 

Define WEB_ADMIN_PORT 20440

Restart Apache Service 

sudo fwcontrol apache restart

Then Upgrade as normal by running the FileWave Server Installer 13+  

# Putting the last character in brackets is a trick to prevent Apache from issuing a warning if the file does not exist.
IncludeOptional "C:\Program Files (x86)\FileWave\apache\conf\httpd_webadmi[n].conf"

Define WEB_ADMIN_PORT 20440

fwcontrol apache restart

Privacy

Details of Allowing / Disallowing Collection of Personal data on a License Level

Collection of Personal Data

I want to disable the collection of personal data at the FileWave license level. This will ensure that the FileWave client can never collect this data, as the option to do so will not be present in the Client Preferences.

Environment

FileWave Server and Client

Changing Data Collection

By default, FileWave collects personally identifiable data and stores that in inventory. 
The collection of this data can be disabled globally via your FileWave license. To make this change, and if you are a customer located in North America, please email the FileWave Business Office, usadmin@filewave.com  or call 1-888-345-3928, Option 3. If you are located in Europe, please email admin@filewave.com  or call  +41 (0) 71-914-30-80.

When data collection is disabled, the following data is not captured, processed, sent to, or stored inside FileWave inventory:

• geolocation data (the device's last determined location in latitude, longitude format)

• application usage data (how long / often / when has an application been opened / used / closed)

• login data (who logged onto a client machine and when)

When disabling personal data collection, the last submitted geolocation data set is preserved. To remove it, please contact FileWave support. All other data types (login data and application usage data) are erased from the database as soon as the clients become aware of the new configuration and check in with the inventory server.

FileWave Server Analytics Reporting

With FileWave 13.1, server utilization aggregated analytics are sent to FileWave automatically to collect information on Licensing/Version of FileWave, Location Information (of the server), Numbers and Types of enrolled devices, Server Configuration information, and information on the Types and number of Filesets.  This information is being gathered in an effort to help FileWave prioritize our future feature development and to better support our customers' working environments.

Here are some frequently asked questions about this Analytics collection:

Q. Is there any personally identifiable information being collected?
A. No, there is no personal information of any kind gathered

Q. How frequently does the server report this information?
A.  The server reports the information only once per day, or on server restart.

Q. How big is the data transfer?
A.  The data transfer is very small as it is primarily summary information and will be 1k (JSON) and under.

Q. What address and port are used for communication?
A. FileWave Analytics reporting travels outbound on port 443 to logstash.filewave.com.

Q. Can I see an example of the data and data definitions?
A. Yes, please see below:

Example

This is an example of the data reported by analytics:

{
    "license_info": {
        "activation_code": "34876786629e4276bf484a2dc8501ad3",
        "company_name": "FileWave (Europe) GmbH",
        "desktop_clients": {
            "existing": 342,
            "licenses": 1000,
            "license_usage_percentage": 34.2
        },
        "mobile_clients": {
            "existing": 1645,
            "licenses": 5000,
            "license_usage_percentage": 32.9
        },
        "chromebook_clients": {
            "existing": 3,
            "licenses": 20,
            "license_usage_percentage": 15.0
        }
    },
    "hostname": "victorf.filewave.ch",
    "machine_fingerprint": "39ce7228a04f94eab57efbab042554cc66eded68",
    "enrolled_devices": {
        "OSX": 300,
        "WIN": 42,
        "IOS": 1645,
        "LIN": 0,
        "AND": 0,
        "CHR": 3,
        "TOS": 0
    },
    "active_devices": {
        "OSX": 296,
        "WIN": 41,
        "IOS": 1476,
        "LIN": 0,
        "AND": 0,
        "CHR": 0,
        "TOS": 0
    },
    "placeholders": {
        "OSX": 26,
        "WIN": 0,
        "IOS": 0,
        "LIN": 0,
        "AND": 0,
        "CHR": 0,
        "TOS": 0,
        "unknown": 15
    },
    "mdm_enrolled_macs": 258,
    "filesets": {
        "app": 75,
        "profile": 35,
        "legacy_policy": 0,
        "itunes_app": 21,
        "ios_enterprise_app": 3,
        "android_package": 0,
        "ios_hosted_media": 1,
        "osx_image": 0,
        "win_image": 0,
        "win_driver_image": 0,
        "win_master_image": 0,
        "ios_update": 6,
        "policy": 0,
        "google_policy_fragment": 0,
        "play_store_fileset": 0
    },
    "server_version": "13.1.0",
    "server_build": "0d367c15f2",
    "server_os_type": "OSX",
    "server_os_version": "10.14.4",
    "is_ucs_installation": false,
    "disk_space_in_megabytes": {
        "total": 1000346,
        "used": 868800,
        "free": 125402
    },
    "boosters": [
        {
            "version": "13.1.0",
            "build": "0d367c15f2",
            "os_platform": "LIN",
            "os_version": "3.10.0",
            "active": true
        },
        {
            "version": "13.1.0",
            "build": "0d367c15f2",
            "os_platform": "LIN",
            "os_version": "3.10.0",
            "active": true
        }
    ],
    "engage_configured": false,
    "classroom": {
        "enabled": false,
        "image_service_enabled": null
    },
    "sis_source": null,
    "imaging_ivs_count": 0,
    "imaging_associations": 0,
    "fileset_groups": 28,
    "fileset_associations": 12,
    "fileset_groups_associations": 81,
    "clone_groups": 0,
    "clone_groups_associations": 0,
    "model_updates": 2,
    "server_restarts": 1,
    "server_ssl_certificate_type": "root_trusted",
    "client_versions": {
        "13.1.0": 312,
        "13.0.2": 20,
        "12.9.0": 7,
        "12.8.0": 3
    },
    "logging_level": {
        "fwxserver": 10,
        "filewave_in_debug": false,
        "fwone_in_debug": false
    },
    "webui_api_usage": {
        "requests": 6,
        "fileset_reinstalls": 0
    },
    "engage_api_usage": {
        "requests": 4,
        "/engage/gcm_project_number": 3,
        "/engage/profiles": 1
    }
}

Field description

The following fields are reported by each customer's server instance:

{
    "activation_code": "34876786629e4276...",
  "company_name": "FileWave (Europe) GmbH",
  "desktop_clients": {
    "existing": 342,
    "licenses": 1000,
    "license_usage_percentage": 34.2
  },
  "mobile_clients": {
    "existing": 1645,
    "licenses": 5000,
    "license_usage_percentage": 32.9
  },
  "chromebook_clients": {
    "existing": 3,
    "licenses": 20,
    "license_usage_percentage": 15.0
  }
}

{
  "OSX": 300,
  "WIN": 42,
  "IOS": 1645,
  "LIN": 0,
  "AND": 0,
  "CHR": 3,
  "TOS": 0
}

{
  "OSX": 26,
  "WIN": 0,
  "IOS": 0,
  "LIN": 0,
  "AND": 0,
  "CHR": 0,
  "TOS": 0,
  "unknown": 15
}

{
  "app": 75,
  "profile": 35,
  "legacy_policy": 0,
  "itunes_app": 21,
  "ios_enterprise_app": 3,
  "android_package": 0,
  "ios_hosted_media": 1,
  "osx_image": 0,
  "win_image": 0,
  "win_driver_image": 0,
  "win_master_image": 0,
  "ios_update": 6,
  "policy": 0,
  "google_policy_fragment": 0,
  "play_store_fileset": 0
}

{
  "total": 1000346,
  "used": 868800,
  "free": 125402
}

{
  "version": "13.1.0",
  "build": "0d367c15f2",
  "os_platform": "LIN",
  "os_version": "3.10.0",
  "active": true
}

{
  "enabled": false,
  "image_service_enabled": null
}

{
  "13.1.0": 312,
  "13.0.2": 20,
  "12.9.0": 7,
  "12.8.0": 3
}

{
  "fwxserver": 10,
  "filewave_in_debug": false,
  "fwone_in_debug": false
}

{
  "requests": 6,
  "fileset_reinstalls": 0
}

{
  "requests": 4,
  "/engage/gcm_project_number": 3,
  "/engage/profiles": 1
}

These additional fields are added by our cloud (logstash):

"2019-05-02T16:01:06.529Z"

{
  "city_name": "Wil",
  "longitude": 9.1539,
  "region_code": "SG",
  "region_name": "Saint Gallen",
  "continent_code": "EU",
  "postal_code": "9500",
  "timezone": "Europe/Zurich",
  "latitude": 47.2884,
  "country_code3": "CH",
  "country_code2": "CH",
  "location": {
    "lon": 9.1539,
    "lat": 47.2884
  },
  "country_name": "Switzerland",
  "ip": "109.205.200.12"
}

List of operating systems

List of fileset types

Deleting Old FileWave Client or Server Log Data

Description

FileWave stores many different types of logs.  Many of these logs are designed to roll over, either to new files or by removing older entries.  In the majority case, FileWave logs do not store data with GDPR concern, however it is possible that files could be populated with such information, some depending upon use.

Although many log files do roll over, it is possible that log files may become very large.  Since this can be possible and GDPR could be of concern, it may be desirable to remove older log data.

The following provision is designed to remove all log data older than a defined period in days.

Information

The scripts provided will archive the current log files into a locally stored zip file.  On completion the active log files will be emptied.  This will occur on a regular basis as defined by a variable.  On each subsequent execution, a new zip of the current logs will be created and the old zip will be removed.

Log duration should not be too short.  When the logs are archived and the active logs emptied, the archive is the only backup of those original logs.  Since only the latest zip is kept, all old log entries (as intended) will no longer be available.

The zip file could be copied to a more secure location for a greater amount of history.  Consider doing this will the same frequency as the amount of days being kept.

If the chosen amount of time is 10 days, this will provide up to a maximum of 19 to 20 days worth of logs.  10 days within the zip and the next 9 to 10 days of active logs before the script re-runs.

Directions

FileWave Server

By default, the following script will run in a 'Dry Run' mode, only showing the files that would be zipped.  No files will actually be zipped and the original files will remain untouched.  

Download: server_log_archiver.sh.zip

The script has the following flags:

Usage
Optional:
 -d Integer specifying the amount of log days to keep (default 10 days)]
 -c [Add the script to cron]
 -a [Action the script.  Dry run if this option is not specified.  Dry run will echo only]

Options

'-d'

If this option is not supplied, the amount of days to keep will be set as 10.  Use this option to specify an alternative amount of days to keep.  For example, to set this as 7 days:

sudo ./server_log_archiver.sh -a -d 7

'-a'

This option will overrule the Dry Run mode and all files will be zipped and all defined, active logs emptied.

'-c'

This option will add the script to the cronjobs list.  There is no need to specify '-a' when using this option, this will automatically occur.  However, '-d' may still be used to specify the desired amount of days to keep.  Place the script at a desirable location and then run the script with this option.

For example, to add this as a cronjob, specifying 14 days and with the script located in /root/ the following would be entered.:

sudo /root/server_log_archiver.sh -d 14 -c

The zipped archive 'filewave_logs.zip' will be stored in the following directory:

/private/var/log/fwxserver_log_archive/

If this script is used on a FileWave Server and FileWave team members request logs, it may be necessary to provide the zip along with any requested log files, for completeness.

macOS Client

The macOS Script potentially handles both the FileWave Client logs and FileWave Central logs.

Download: client_log_archiver.sh.zip

By default, the following script will run in a 'Dry Run' mode, only showing the files that would be zipped.  No files will actually be zipped and the original files will remain untouched.  The script has the following flags:

Usage

Files included for archive will be not only zipped, but original files will be emptied.

Optional:
  -a [Action the script.  Action a dry run if this option is not specified.  Dry run will echo only]
  -d [Integer specifying the amount of log days to keep (default 10 days)]
  -e [Start from the beginning.  The zip will be erased and the script will run as if first ran]
  -f [Archive Fileset logs from client as well as generic FileWave Client logs.  -g is uneccessary when running this option]
  -g [Archive generic FileWave Client logs (not including Fileset logs).  Fileset logs will remain as is.]
  -r [Rerun the script, but keep zip archive.  Current zip will be presevered and only additional logs included from the above options will be added to the archive if not already zipped]
  -s [Archive FileWave Central logs from computer]
  -x [This options will zip all client logs (same as running -f) and also action the script]

Options

'-a'

This option will overrule the Dry Run mode and all files will be zipped and all defined, active logs emptied.

'-d'

If this option is not supplied, the amount of days to keep will be set as 10.  Use this option to specify an alternate amount of days to keep.  For example, to set this as 7 days:

sudo ./client_log_archiver.sh -a -d 7

'-e'

This option will remove the current zip and act as if this is the first time the script ran.  If this option is not set, any re-running of the script will add or update the current contents of the zip.

If the script is ran again, shortly after running the script initially, the archive will only contain a minimum amount of data, since the last zip of logs.

'-r'

It may be desirable to re-run the script to add logs not previously included, whilst preserving the current zip.  The '-r' option allows for just that situation.

'-x'

Running '-x' is the same as setting both '-a' and '-f' simultaneously.

The next options determine which logs are archived.  '-f' and '-g' should not be used at the same time, since '-f' will overrule '-g'.

'-f'

Zip and replace all FileWave Client Logs.  This will include all generated log files from Filesets, e.g. script logs.

'-g'

The '-g' option zips and replaces all FileWave Client Logs, excluding Fileset logs.  Since Fileset scripts are written by the administrator of FileWave, the contents of those scripts can be controlled and contents known.  As such, it may be desirable to keep these logs.

'-s'

This last option will zip and replace any logs generated by the FileWave Central application.  This option need only be set on computers which run this application.

Examples

To archive only FileWave Central logs:

sudo ./client_log_archiver.sh -a -s

Zip FileWave Client, excluding Fileset logs:

sudo ./client_log_archiver.sh -a -g

If after running the above command the following were to be actioned, the zip would be updated to include Fileset logs, but the other, already zipped Client logs would be left as is:

sudo ./client_log_archiver.sh -a -r -f

Fileset Contents

The script needs to run with the client stopped.  As such, the script cannot be ran through FileWave.  Instead, the Fileset includes a LaunchDaemon to handle the periodic running of the script, as well as the script itself.

If this script is used on FileWave Clients and FileWave team members request logs, it may be necessary to provide the zip along with any requested log files, for completeness.

Windows Client (TBA)

Troubleshooting

How to set FileWave Server components to debug mode

For troubleshooting purposes, it may be useful to set the FileWave server to debug mode. When troubleshooting issues with the FileWave server, booster, LDAP collection and syncing, as well as Software Update catalog issues, debug logging will give you extra information that may help you or the FileWave support team resolve a technical problem. 

Step-by-step guide

In order to set debug logging for fwxserver.log, fwldap.log, fwsu.log:

1. Linux/Mac server - navigate to /usr/local/etc/server.lvl
   
2. Using a simple "echo 99 > /usr/local/etc/server.lvl" on Mac / Linux, the debug log level can be set. Keep in mind that initially, the file "server.lvl" may be an empty file if you have not set the debug level in the past. 

If you do not see the server.lvl file at the location on your server you are able to create the file on the server in a text editor or with "echo 99 > /usr/local/etc/server.lvl" on macOS and Linux servers.

If you are troubleshooting issues with the FileWave server and need the fwxserver.log to be in debug mode, no restart is required after setting the level in the server.lvl file. If you are troubleshooting an issue with any other process (LDAP, Software update, Booster issues), then you will need to restart the FileWave server services / processes. 

Please remember to set the debug log level back to the Standard log level once you have completed troubleshooting the issue at hand.

The logging levels are as follows:

10 : Standard Log Level
99 : Debug Log Level
101: Trace Log Level

In order to set debug logging for the django component (filewave_django.log):

1. Linux/Mac server - navigate to /usr/local/filewave/django/filewave/
   
2. Linux/Mac - edit the settings_custom.py file with the command "vi settings_custom.py" to open the file with the vi editor. 
   
3. Remove the "#" just before "DEBUG = True"
4. Save the file 
5. Restart apache with the command "fwcontrol apache restart"

Please remember to set the debug log level back to the normal by adding the hash (#) back to the "DEBUG = True" line. Restart apache again once you have completed troubleshooting the issue at hand.

fwxserver folder relocation in FileWave Server 13.1.4+ on macOS and Linux Platforms

Does this affect my installation? 

To determine whether action is required from you immediately prior to the installation of 13.1.4, please run the following command as root on your FileWave server : 

if [ ! -z "`mount | grep /fwxserver`" ]; then echo 'Action required' ; else echo 'You are good to go' ; fi

If this command returns "Action required" on your server, you will have to read on and take action right before upgrading to 13.1.4 - if "You are good to go" is returned, please make sure your Backup Script is up to date via Automated Backup, and you're well prepared to continue with the usual upgrade instructions. 

Background Information

On macOS and Linux, FileWave Server up until Version 13.1.3 stores both DB ( postgres Database ) and Data Folder ( FileSet Repository ) in the /fwxserver folder on the root of the filesystem. 

Architectural changes in macOS Catalina make it necessary to move this data to /usr/local/filewave/fwxserver , since the root filesystem will be read-only from macOS Catalina onwards. 

For most installations, the only change that is required is an update to the newest version of the Backup Script to make sure that the new locations are taken into account.  Please refer to Automated Backup for an up to date download. 

FileWave fwxserver 13.1.4 contains an automatic routine to do this migration for you, and if you have not relocated your Data Folder or /fwxserver folder to another volume, this will work without admin intervention. 

If you have followed the following article:  Store the FileWave Server/Booster Data on a Separate Volume , meaning you have moved the Data Folder to another Volume, and then created a Symlink to your alternative Datastore to /fwxserver/Data Folder, all that is going to happen is that the symlink itself is going to be moved, and none of the data is moved. No admin intervention is necessary. 

Manual Intervention in case of Mount Point Utilization

Please note that FileWave support is happy to assist you with this should you feel uncomfortable doing this yourself. Please contact us using https://help.filewave.com in this case, or by calling us. 

Please note that the changes outlined below will make your FileWave Server inoperable with any version below FileWave 13.1.4. If you do not have the FileWave 13.1.4 installer ready to go, please come back to this article when you do.
Please also note that during the time you implement these changes, your FileWave Server services will be offline. The total duration of the change should be less than 10 minutes - after which you can start the usual upgrade procedures.

Step 1 - Server shutdown

sudo fwcontrol server stop

Step 2 - Determining mountpoint(s) related to /fwxserver, and unmounting them 

mount | grep /fwxserver|sed -e 's/.*on \(.*\) type.*/\1/'|xargs -t umount

Step 3 - Moving the mountpoints to their new location in /usr/local/filewave/fwxserver

Linux: Open the /etc/fstab file in a text editor of your choice.  

For each of the lines in the output of Step 2, replace - in the second column - /fwxserver with /usr/local/filewave/fwxserver, i.e.  :

/dev/mapper/centos-fwxserver /fwxserver                       ext4    defaults        1 1

Would Become :

/dev/mapper/centos-fwxserver /usr/local/filewave/fwxserver                       ext4    defaults        1 1

macOS : run 'sudo vifs'

For each of the lines in the output of Step 2, replace - in the second column - /fwxserver with /usr/local/filewave/fwxserver, i.e.  :

UUID=DF000C7E-AE0C-3B15-B730-DFD2EF15CB91 /fwxserver apfs   rw	1	0

would become : 

UUID=DF000C7E-AE0C-3B15-B730-DFD2EF15CB91 /usr/local/filewave/fwxserver apfs   rw	1	0

Step 4 - create the mountpoint, remount the volumes, and verify things are where they should be 

for each of the lines modified, remount the volumes by running "mount", and appending the new path for the mount, for instance:

mkdir /usr/local/filewave/fwxserver
mount /usr/local/filewave/fwxserver

Please verify the presence of your data by running : 

ls -la /usr/local/filewave/fwxserver

and checking if your DB and "Data Folder" folders show. 

Step 5 - You're clear to run the upgrade! 

Please don't attempt to start your server until the upgrade; FileWave Versions lower than 13.1.4 will not be able to run in this state . 

You're now well prepared to continue with the usual upgrade instructions.

FileWave Server should not have IPv6 enabled

What

Enabling IPv6 on FileWave Server, Boosters, or IVS could lead to unexpected networking issues. IPv6 is a complex networking protocol that, while supported on macOS and Linux operating systems, is not optimized for use with FileWave. Therefore, it's recommended to use IPv4 for more stable and predictable behavior.

When/Why

This information is particularly important for organizations looking to avoid networking issues related to the use of IPv6 on the FileWave Server, Boosters, and IVS. While FileWave clients can function correctly with IPv6, best practice dictates that IPv6 should be disabled on the server components to ensure optimal performance and stability.

How

For macOS

To disable IPv6 on macOS, you can execute the following commands in the Terminal:

# Disable IPv6 for a specific network interface (e.g., "en0")
networksetup -setv6off en0

For Linux

On Linux systems, you can disable IPv6 using the following steps:

1. Edit the /etc/sysctl.conf file:

sudo nano /etc/sysctl.conf

2. Add the following lines to the file:

# Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.tun0.disable_ipv6 = 1

3. Save and close the file.

4. Reload the sysctl settings:

sudo sysctl -p

Verify the Configuration

After making these changes, it's advisable to verify that IPv6 has been successfully disabled:

• macOS: Open Terminal and run ifconfig to check the network interfaces.
• Linux: Execute ip a or ifconfig to inspect the network configurations.

Related Links

• FileWave Server Setup
• IPv6 Wikipedia - Background information on IPv6