Movere uses the .NET framework to scan each targeted endpoint locally, providing two key benefits:
- Minimal network traffic. By scanning devices locally, communication between the Movere Console and each targeted endpoint is limited to delivery of the Movere scanning engine (< 5MB) and the return of the encrypted output file (typically < 10KB for inventory payloads and 5KB for ARC payloads).
- Minimal memory utilization. The Movere scanning engine only uses resources that are available and does not de-prioritize any existing running application.
Resource utilization by Movere on Linux systems is not governed in the same manner as with Windows systems, (i.e. by .NET). Movere’s Linux binaries contain optimized C++ code to ensure the scans run as efficiently as possible. Movere utilizes built-in Linux features that are thoroughly vetted and come packaged with most distributions to ensure a timely response and minimum usage.
For example, if a scan starts and the targeted endpoint is currently sitting at 80% CPU utilization, Movere will be limited to a maximum of ~10% of the systems total resources (Windows uses a complex algorithm to ensure that it keeps resources available for the operating system itself). If the device has more resources available, then Movere will take advantage of the additional resources, but the .NET framework will make this decision, not Movere.
In addition to this we also need to consider total scan time per device. Movere is able to scans most devices within 30 seconds, which means with only 10% CPU Movere will still be able to complete its scanning in <1 minute, with >10% scan time is reduced even further. Ultimately, all this also depends on what Microsoft products are installed, i.e. a device with SQL Server installed will take longer to inventory than a device without SQL, etc.
If enough resources are not available to complete the scan then Movere will show the following error messages that are explained below:
- Insufficient memory to continue the execution of the program: Movere leverages the .NET framework, which controls the resources it receives and the priority in which they are given. When the target endpoint has insufficient resources, instead of placing the endpoint under further strain, Movere terminates itself.
- Insufficient system resources exist to complete the requested service: Similar to the insufficient memory error, this typically means that the targeted endpoint has insufficient processing power to perform the requested tasks. Once again, Movere will terminate itself to avoid placing further strain on the system.
Are .NET scan files copied to memory or disk?
The inventory binaries sent to each targeted endpoint add up to 4.5MB (Bot2/Bot4/FrameworkVerifier), and if the user chooses to run ARC, this adds an additional 3.3MB (Arc2/Arc4). These binaries are written to disk by copying to the Temp folder in the Admin$ share of the target Windows device(s). For Linux devices, the Movere binaries are copied to the home directory of the user account running the scan.
The output(s) Movere creates are generated in-memory, encrypted, then saved to disk in the same location. At the end of the scan, once the output file has been uploaded to the Movere Console/cloud, Movere self-deletes all files, leaving no trace on the scanned device.
How does the .NET framework throttle resource consumption?
Windows is responsible for how much CPU an application uses. The .NET framework works in tandem with the operating system to allocate resources internally. For example, if a server is consuming little CPU, then the operating system and .NET will give the Movere Inventory/ARC bots as much CPU as needed. Movere sets the thread priority to the lowest available level, so, if there are other applications needing compute cycle, they will be given priority. However, if there are no other applications requesting CPU cycles, the Movere Inventory/ARC Bots will run with whatever the .NET framework deems necessary. This ensures that the Movere Inventory/ARC Bots complete their scans in the shortest amount of time possible (typically < 30 seconds).
Movere ARC bots contain multiple safety checks designed to gracefully exit an ARC scan. Movere ARC bots perform a series of pre-scan checks including process enumeration speed and process level performance counter access. This protects our customers from CPU spikes or performance counter permission issues. When encountering a slow system or a permission denial, Movere ARC bots will still capture macro-level performance metrics, and will skip details such as process level CPU, RAM, Path and Version. This way, Movere can still assess a device’s Actual Resource Consumption (ARC) and size it for the cloud, without negatively impacting system performance.
In addition to pre-scan checks, Movere can also be customized to further reduce resource requirements. For example, a customer not requiring event or SQL performance data can disable these modules, while still being able to collect CPU utilization, memory utilization, storage performance, and network throughput to size for the cloud.
IMPORTANT: The event and SQL modules are disabled by default but can be enabled by the user at any time. For more information, please see Customizing the Actual Resource Consumption (ARC) Bots.