Workspace ONE Sensors Best Practices

Workspace ONE Sensors enable you to collect any custom piece of information from a Windows 10 client that Workspace ONE UEM doesn’t natively collect. This feature was added in version 1905 of WS1 and enhanced in 1910 with 64bit Powershell support. This feature can be used for all kinds of things, but after working with several customers I thought it worthwhile to write up some best practices so that you can avoid some common pitfalls.

One Sensor for One Data Point

This means that you really need to create a sensor to collect a single data point. Think of it like a column in a database: you only want each column to have one piece or type of data. This is for two reasons:

  1. It keeps sensors simple and thus faster to run on the client
  2. The data must be accessed from Workspace ONE intelligence via Reports and this means that each sensor name will become a column. If you have comma separated values it gets harder to read, sort, and consume the data.

If you absolutely must have multiple data points sent in one sensor, I’d recommend setting the output as a string value to a single variable and then returning the variable like this:

[string]$internet = Get-InternetTime
[string]$client = (get-date)
$compare = "Internet:" + $internet + ",Client:" + $client
return $compare

Add Author and Date to Description Field

If you have a larger environment with multiple admins creating and deploying sensors, it’s very important that you train everyone to add their name and a brief description of what the sensor is supposed to do.

Add name, date, and description!

If someone edited or added a sensor and did NOT complete this info, you can check it in Console Events. Go to Monitor > Reports and Analytics > Events > Console Events. Change module to “Device Sensor” to filter it. Don’t forget to adjust the Date Range Filter as well.

Be Mindful of Execution Context and Architecture

Execution Context

System: This runs in “system” context and does not depend on a logged in user. Most sensors should be set to this. If a user is logged out, then sensors will only run on the agent schedule and the Hub will not respond to AWCM commands such as when you manually click Query > Sensors .

User: This runs as the logged-in user context. Keep in mind this has to be the same as the enrolled user. So if Bob logs into my system, but it’s enrolled to me, this user sensor won’t run.

Execution Architecture

Mousing over the information bubble explains it pretty well. Most of the time this should be set to auto, but you can override the bitness if needed. This was recently added in WS1 UEM console version 1910 so double check your sensors to ensure they are set to “Auto” as by default they maybe have been set to 32-bit after the upgrade. Additionally, clients need to be on 1910 agent or higher for the added 64 bit support to work (previously it was 32-bit only).

Align Correct Value Type

Don’t forget to set the correct “Value Type” because you can’t change it later. So whatever you output in your script you need to ensure this matches. I pretty much always set my to “string” and just ensure my output is forced to output a string variable. See my above example on how to do this.

If you have a mismatch, you’ll get an error like this:

If you don’t know what type it is, here are few example on how you can check:

$guid.gettype()     
(write-output (hostname)).gettype()
(write-output (get-date)).gettype()

Understand the Different Triggers

There are 2 different triggers on when sensors run:
Schedule: This runs based off of the Hub check in time. This is located under Devices & Users > Windows > Windows Desktop > Windows Sample Schedule. The “Security Information Sample” is what the schedule runs on. Note: You can only view or change this if you are in a dedicated SaaS or On-Prem environment. If you are in a Shared SaaS then you’ll have to get a SaaS ticket created to change. Default is 12 hours.

You can also trigger manually by clicking Query > Sensors on device details page.

Event: Most of these are self explanatory but here it is:

  • Login – Any user login event. This is NOT actually tied to the enrolled user, but any user that logs in.
  • Logout – Same as above but on logout.
  • Startup – Windows system boot up. Since there is not “user” context here, this only works for ones that are configured to run in System context.
  • User Switch – Doing a user switch instead of full logout.

Sensor Samples

Don’t forget we have a ton of community and VMware created sensor publicly available! Click here to view them as well as a script that can be used to auto-import all of them.

And that’s it for now. Hopefully this helps you be more successfully when using Sensors! Let me know if I missed anything so I can add to this list.

Leave a Reply