Understanding FileWave IP Address Inventory
Which IP address should you use in a FileWave Inventory Report? Choose the field based on whether you need the address seen by the server or the addresses reported by the FileWave Client.
Two IP address fields
FileWave provides two distinct IP inventory entries:
- All Devices > IP Address
- Network IP Address > IP Address
All Devices IP
This IP is how the server sees the incoming traffic. As such, it isn't as much device inventory, but inventory of live traffic to the server.
Network IP
The value reported as the Network IP Address, however, is inventory. Each network adapter will be included in the report back to the FileWave Server during the inventory phase; thus multiple entries per device.
Apple mobile devices will have a blank value, since this IP is provided by the FileWave Client
Considerations
All Devices IP
Since the IP for All Devices is actually the IP of incoming traffic, in reality it is the last leg of the communication between devices and the FileWave server.
The last network hop can still be useful. A company NAT address can show that a device is checking in from another location, while a Booster or hosted load balancer can explain why many devices report the same address.
Hosted
Where servers are cloud hosted, the last leg of traffic is from the Load Balancer to the FileWave Server. Since all traffic will be through the Load Balancer, then the reported IP will be the local IP of that Load Balancer.
Booster Routing
This has a similar consequence with Hosted. Since FileWave Client communication is through the Booster, the last leg of traffic (as viewed by the FileWave Server) will be the Booster (the last Booster if cascaded). On face value, this would appear initially as useful as first described. Immediately, it is clear that a client is either reporting directly to the server or through a Booster. In the latter case, which Booster if multiple exist. However, there is an additional complication.
Due to requests, the software was altered to provide the local client IP of devices routing through Boosters, with the intention of improving the experience of the Client Monitor.
When a device using Booster Routing first checks in, the IP actually reported will initially be that of the Booster. From this communication, after a period of time, the value will be updated to reflect the Client IP instead. However, it may be likely that the communication will be re-established at a later date, causing the Booster IP to be reported again. As such, there will be a duration of time where the Booster address will be seen, before the Client local IP is shown instead.
Report one specific interface with a Custom Field
IfA scripted Custom Field can return values that its client-side script can derive. Use that flexibility when you need one address from a specific interface,interface: a Client Script or Client Command Line Custom Field can select thatthe interface and return a single value. Test the script on devices with VPN, Wi-Fi, Ethernet, and multiple adapters before using it for reporting or automation.
Client-script Custom Fields are available for computer devices running macOS or Windows.