Sensors and Saved Questions
Sensors and Saved Questions
A sensor is a read-only script or command that runs on the endpoint and returns a value (or a small set of values) to the question that called it. Sensors may accept parameters (a registry path, a file path, a service name), may be platform-specific, and must be distributed to clients before use. Because a sensor runs on every targeted endpoint each time a question is asked, the design rules are about cost: keep sensors fast, deterministic, and narrow in scope, and avoid heavy disk scans or long-running scripts in questions aimed at the whole fleet.
Sensors collect; they do not change the endpoint. Anything that modifies state - installing, deleting, restarting, editing a registry key - belongs in a package and an action. A very common trap presents a 'sensor' whose script deletes a temp file or writes a configuration value; the correct classification is a package, not a sensor.
Saved questions bundle sensors, filters, and parameters into a reusable, named object. They are the preferred foundation for recurring work because dashboards, Trends, Connect, reporting, and dynamic computer groups all reference saved questions rather than ad-hoc ones. Saving a question whose sensor is parameterized produces a parameterized saved question, and the user is prompted for values each time it is issued - so document the expected parameter values alongside the question.
Rule of thumb: if you will ask the same thing more than once, save it with a descriptive name and documented parameters; and if the script writes anything at all, it is an action, not a sensor.