Windows Client Pre-Requisites
Prepare one Windows test device
Use this page to prepare a custom FileWave Client MSI for one Windows computer. Then follow Windows Enrollment to install it, approve the device if needed, and inspect its first inventory.
The FileWave Client is Windows software for management tasks such as inventory and Fileset delivery. Installing its MSI does not enroll Windows in MDM. If your goal is Microsoft Entra ID-based enrollment and Windows MDM policies, use the separate Windows MDM prerequisites and Client package setup. Signing in to Windows with Entra ID alone does not complete that setup.
You do not need GPO, LDAP, a Booster, or an Imaging Virtual Server (IVS) for this first Client installation. A Booster can cache FileWave content for later delivery tests. IVS is for a separate Windows imaging exercise that can erase data.
Before you build
Hosted customers can prepare the package in Central. Server installation, shell commands, and changes to hosted-server networking are not part of this exercise. Ask your assigned FileWave SE to coordinate any server-side work with Support.
Build the Windows Client MSI
Choose the build method for the Server the device will enroll with, and use a matching Central version. Do not use an endpoint's Client Version field to identify the Central or Server version.
| FileWave Server version | Where to build |
|---|---|
| 16.4.1 and later | Central: Preferences > Enrollment > Windows |
| 16.4.0 | Central: Preferences > Mobile > Windows |
| Earlier than 16.4.0 | FileWave Custom Installer Builder for Windows, using the release-specific instructions below |
Server 16.4.0 and later: build in Central
- Connect FileWave Central to the intended Server and open the Windows pane shown in the table.
- Select Show settings. Review the Server address, Client naming, Booster/routing, and remote-connection settings. Use your approved configuration, not values from an example image. For a first test without Boosters, do not add Booster addresses or routing unless your environment requires them.
- Select Build Windows client package. In 16.4.1 and later, review or change the settings in the separate configuration dialog, then confirm to build. In 16.4.0, review the expanded settings on the Windows pane before building.
- Wait for Ready for Enrollment and check the displayed package version. If the build fails or the configuration is wrong, stop before distributing the MSI. Save the error details for the environment owner and your assigned SE, who can coordinate with FileWave Support.
- Select Download Windows client package to download the MSI for your test computer.
Central stores the built package. You do not need to upload the downloaded MSI back to Central. Ready for Enrollment confirms package readiness, not that a device has enrolled.
Keep the package up to date is optional. It lets FileWave regenerate the enrollment package after future Server upgrades; it does not schedule upgrades of existing Clients. For the full settings reference, see Build Custom FileWave Client and Booster Installers.
Server earlier than 16.4.0: use the external builder
Use this path only for an older Server release that your environment owner has approved. The external website may offer newer package versions, but for Server 16.4.0 and later, use Central to build Client enrollment packages.
- Open the Windows custom installer builder.
- Set Product Version to your FileWave Server version, enter its FQDN in Server Name, and review the applicable settings below. Sync Computer Name uses the Windows hostname as the Client name and is a useful choice for this test.
- Select Build and wait for the download. Extract the downloaded ZIP to obtain the customized MSI.
- Keep the package version and intended Server details with the MSI so you can identify the correct installer for the test device.
A manual Client installation does not require uploading this MSI to Mobile > Windows. That upload is part of the separate Windows MDM workflow for older versions.
Settings in the external builder
These fields are for the external builder. They are not a required checklist for the integrated Central dialog.
| Setting | What to check |
|---|---|
| Product Version / Server Name | Match the intended Server version and FQDN. |
| Sync Computer Name | Uses the Windows hostname for the Client name. Review Client Name Settings if you turn synchronization off. |
| Server Port | Leave the builder value at 20015. The Client converts it to the required SSL port, 20017; do not substitute 20017 in this field. This is a package setting, not a firewall-opening instruction. |
| Client Password | Not used by FileWave 16.0.0+ Clients. Do not treat it as an enrollment credential for those versions. |
| Is Tracking | Enables the client-side tracking setting; tracking also depends on management mode. Leave location tracking out of this first exercise. |
| Remotecontrol Enabled / Remotecontrol Prompting | Review remote access and end-user consent with the environment owner. Do not copy the older example's checkbox states. |
| Server Certificate | The external builder's certificate upload is for self-signed certificates, not CA-signed certificates. Use the intended Server certificate supplied by its administrator. |
| Tickle Interval | Controls the idle interval before the Client checks for model changes. Keep the environment's approved value rather than shortening it for the test. |
| Booster Settings | Optional addresses and routing for FileWave content caching. See Boosters when planning a later test. |
Use the settings for your approved Server release. Do not copy tracking or remote-control choices from another environment.
Continue with the test device
You are ready for Windows Enrollment when you have the correct custom MSI, one approved Windows computer, and an administrator who has reviewed what could be assigned to it. Install and verify that one device before using the bulk options below.
Optional: deploy with Group Policy after the first test
You can distribute the custom MSI to more computers with an existing software-distribution tool or an Active Directory Group Policy startup script. GPO is not required for Client enrollment. Begin this work only after one manual installation has reached the intended Server and passed the inventory and first-deployment checks.
Have the AD administrator approve the pilot
- Scope the GPO to one test computer in a controlled test OU or equivalent verified security filtering. Review the effective target before linking or enabling the GPO; do not start at the domain root.
- Protect the script, MSI share, and local MSI cache from modification by ordinary users. The target computer account, such as
DOMAIN\COMPUTER$, needs read access through both share and filesystem permissions. Grant only the access the pilot needs, rather than defaulting to every domain computer. - Use an approved script-signing and PowerShell execution-policy configuration. Startup scripts run with high privilege. Do not weaken domain-wide script controls to make an example run.
- Agree on maintenance timing, logging, restart handling, and a tested removal or recovery procedure. Disabling a GPO stops future runs; it does not uninstall an already installed Client.
Startup-script workflow for an approved, tested script
Have your Windows/AD administrator supply a deployment script tested with the chosen MSI and target Windows release before following these steps.
- Prepare the custom MSI using the correct builder for your Server. Configure the approved script's installer share path and verify that the pilot computer account can read that exact MSI.
- In Group Policy Management, create the pilot GPO and open Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown) > Startup.
- Use Show Files… to open that GPO's Startup folder. Place the approved script there. Use the exact filename of the approved script in your GPO.
- Open the PowerShell Scripts tab, select Add… > Browse…, and choose the script. Save the settings.
- Have the AD administrator review Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell > Turn on Script Execution. Use the organization's approved option. If you set the policy to Enabled, also choose and review the permitted script behavior.
- Confirm the one-computer target, link the GPO to that pilot scope, and test startup. Check the installation logs, installed Client version and Server configuration, admission, recent communication, and inventory before expanding the target.
Validate the deployment script before rollout
Have the Windows/AD administrator test installation detection, the intended Client version and Server, missing or unreadable MSI files, copy failures, stale local cache, installation errors, and restart-required results. A running fwcld process alone is not a sufficient installation or enrollment check. The script must stop safely rather than install stale or unverified content.
Protect any local installer cache and logs from unauthorized modification. Do not manually place files in C:\Windows\Installer; Windows manages that cache. Agree on the log locations and restart handling. Windows Installer exit code 3010 means installation succeeded and a restart is required; see Microsoft's Windows Installer return codes. Disabling the GPO does not uninstall the Client.
Optional: Windows imaging
A custom MSI can also be included in a Windows provisioning process. IVS setup, image capture, and image deployment form a separate evaluation that can destroy data. Use only approved, expendable devices and follow that imaging workflow's preparation and validation steps. Imaging is not needed to complete this Client enrollment path.
No comments to display
No comments to display