Skip to main content

Location Tracking

Decide whether location belongs in your evaluation

Location reporting is optional. It is not needed to enroll a device, deliver software, or read ordinary inventory. Use it only for a documented, approved purpose, with the required user notice, consent, and privacy review. If location is outside your evaluation, return to Inventory Reports.

FileWave requests location from the operating system or platform service. Available Wi-Fi, cellular, GPS, and other positioning sources vary by device. A map pin is a reported position—not a guarantee of a device's present location, accuracy, or recoverability. Do not assume every FileWave-supported platform supports the same tracking workflow.

Keep passive reporting separate from Missing/Lost Mode. Passive reporting requests location without locking the device. On supervised iPhone and iPad, Missing invokes Apple's Managed Lost Mode and locks the user out. Do not choose Missing to make an ordinary location test work.

Before collecting any location data, agree on who may view it, how long it will be retained, and how the pilot will end. Use one approved device whose user understands the exercise. Do not use a fleet selection, change the default tracking state, bypass a privacy restriction, or collect location from a personal device without the required authorization.

Prepare one device for an approved passive-location pilot

The documented desktop route uses the native FileWave Client on macOS or Windows. ChromeOS uses the FileWave Inventory extension and its policy. Read the section for your platform below before changing Client State. The retired iOS/iPadOS Kiosk IPA is not a working passive-location route.

This start/stop exercise requires a device that is initially Untracked (called Not Tracked in some documentation). If it is already Tracked, limit this lesson to observing existing reporting under its approved policy; do not disable or alter that reporting for a demonstration. Do not use a device in Missing mode or with an unclear original state.

  1. Identify one enrolled, communicating pilot device in Clients whose original Client State is Untracked. Confirm its identity and that state with the owner, without copying personal location data into your evaluation notes.
  2. Have the administrator confirm that the license permits personal-data collection and that the device's Client preferences and OS privacy controls permit the approved use. Do not change the license or override a restriction to complete the exercise.
  3. For a desktop Client, check the existing one-device settings in Central. The documented Disable personal data collection setting must not prohibit collection, and a zero location refresh interval disables location querying. Record the original settings; do not deploy a broad Superprefs change or rebuild a fleet installer for this pilot.
  4. Once the platform path, permissions, and cleanup plan are approved, the documented Central action is right-click the single device → Client State → Tracked. Older documentation calls Central “FileWave Admin.” Confirm the label on your supported release; stop if the available options differ. Do not substitute Normal or Missing based on an older article.
  5. Review the selected device and saved changes before committing. A Model Update publishes pending model changes from all administrators, not just this pilot. Coordinate with the other administrators first. The Update Server Model dialog is confirmation only; it does not preview pending work.
  6. After the device communicates and reports location, inspect Position Map in Central's Client Info, or the Location tab in Anywhere's Device Detail. Check the reported timestamp and accuracy where available. An increased model number shows that the commit occurred; it does not show that location was received.

Leave the server-wide tracking default unchanged. Although Central provides a default tracking setting, making every newly enrolled device Tracked is not a one-device evaluation. Selecting one device also does not narrow the scope of a shared Model Update.

Choose Tracked for the approved passive pilot, not Missing. Selecting the menu option does not prove that the device has returned location data.

Use the timestamp and accuracy shown for your authorized pilot. Do not place its coordinates or an identifying map in shared evaluation notes.

Check the result, then end the pilot

Look for a location report from the intended device during the approved test window. Review its timestamp and accuracy to understand what it tells you. The configured interval, OS permissions, connectivity, and platform behavior determine when a report arrives. Do not expect a fixed refresh time.

If no location arrives, stop and check the device's communication, tracking state, license allowance, Client privacy preference, refresh interval, and OS permission. For macOS, check whether fwGUI is allowed in Location Services. Do not respond by enabling global collection, forcing permissions, or selecting Missing. Ask the FileWave owner to confirm the supported route if those prerequisites are unclear.

At the agreed end of this start/stop pilot, return the device to its original Untracked state through the supported control and restore any pilot-only Client settings. Coordinate the required Model Update and verify that the device received the change. Confirm that new reports stop under the agreed observation window. Devices that were already Tracked remain observation-only for this lesson; their existing authorized reporting is not expected to stop. Stopping new collection does not prove previously collected data has been deleted; handle retention through the organization's approved process.

Keep evaluation notes focused on whether reporting started and stopped as agreed, rather than recording a person’s movements.

Show multiple devices on one map—only after a separate review

The older Central action Clients → select devices → Show Location(s) displays reported positions together. Displaying positions together is not a substitute for permission to view each device's location. An old position does not show live movement. Keep the first exercise to one device. Before any later multi-device use, review the selected records, access permissions, purpose, and retention scope; confirm the action's current label with your FileWave owner.

Chromebook location reporting

The documented ChromeOS path uses the FileWave Inventory Chrome extension, with collection timing controlled by its policy JSON. Start with Chromebook Client Pre-Requisites to understand the extension and Google administration requirements. Have the owner confirm the supported extension, location policy, user permissions, and exact Google policy scope before enabling collection. A selected pilot device in Central does not prove that a Google policy change affects only that device. Use the approved policy’s interval when checking the result.

iOS and iPadOS: do not reuse the retired IPA workflow

The enterprise IPA-based FileWave Kiosk / App Portal stopped working on July 30, 2026. No replacement IPA will be issued. FileWave 16.3.0 and later use the App Store Kiosk delivered through Apps and Books / VPP. See the Kiosk IPA end-of-life statement for the transition and iOS and iPadOS Software and Profiles for Kiosk distribution.

Do not assume the App Store app provides the same passive-location collection as the retired IPA. If your evaluation requires iOS/iPadOS passive location, ask the FileWave product owner to confirm the supported Server/app/OS combination, required permissions, reporting timing, and procedure for stopping collection before you collect any location data. Do not install the retired IPA, promise automatic permission approval, or substitute Lost Mode.

Missing/Lost Mode is a separate security action

Apple MDM Lost Mode applies to supervised iPhone and iPad, not macOS. Setting an eligible device to Missing and performing the required Model Update sends the Lost Mode command. Once received, it locks normal device use and can request location even when Location Services are off. This is not a passive test and does not rely on the retired Kiosk IPA.

Use it only under the organization's missing-device procedure, with recovery authority and a network path for both enabling and disabling the mode. Ending Lost Mode requires changing to another approved Client State, such as Untracked, committing the change, and confirming the device received it and is usable again. Apple then notifies the user about the location collection. An offline device cannot receive the exit command. Do not deliberately lock a working device to try this lesson, reboot a locked test device, or replace this workflow with Mac Lock/Erase commands.

Android EMM also has a separate, disruptive Android Lost Mode with its own corporate-ownership, OS, and passcode requirements. It is not a fallback for failed passive reporting.

macOS location reporting

The documented passive-location workflow on macOS uses the native FileWave Client; MDM enrollment alone does not meet that requirement. The Client must permit personal-data collection, have a nonzero location refresh interval, and have OS access to location. The setup reference identifies fwGUI in macOS Location Services. Obtain the required permission from the user and respect a refusal. Do not assume an MDM profile can silently grant location access. Review the existing device configuration rather than assuming that a PKG installation enabled collection.

Windows location reporting

The native FileWave Client uses Windows positioning services. Windows Location Services and applicable privacy controls must allow the approved use, and the Client's collection and interval settings must permit it. Even if no app-specific consent prompt appears, you still need the required consent and must follow your organization's policy. Review the existing device configuration rather than assuming that installing an MSI enabled tracking.

References and return route

No comments to display