The world of Windows 10 and Modern Management in Workspace ONE UEM can be a daunting one. I’ve done some decent writing around Windows 10 like my article on Lessons Learned. One of the areas that I don’t see used nearly enough are Windows 10 Sensors, which Josue Negron/Brooks Peppin and the rest of the Windows team at VMware have done some great work on. Today, we are going to talk about pulling in the base Windows sensors, creating sensors, and troubleshooting sensors. Let’ get started!

What are Windows Sensors Exactly?

I’m sure you are wondering why do we need sensors and how do they actually help me? Sensors are sort of like Windows 10 metadata inside of Workspace ONE. Sensors are all about understanding the story you are trying to tell inside of the digital workspace.

An example would be: “I’m having issues making sure that people have their Office Clients up to date” or “I don’t know what channel users’ Office Clients are on.”

Sensors are basically scripts that will run, take information, and write it into the WS1 Intelligence service. Once that data is there, you can use it to power automated workflows. As an example, if it sees someone is on an older version of the Office client, you could open a ticket in ServiceNow, run a script, etc. This is why Windows sensors are so incredibly powerful.

Importing the Workspace ONE Sample Sensors for Windows 10

When starting with Windows 10 sensors in WS1, I always suggest pulling in the sample sensors as a good starting point. You can grab those here, which let you run a basic PowerShell script like this below to import the sensors into your WS1 environment:

 .\import_sensor_samples.ps1
 -WorkspaceONEServer 'https://as###.awmdm.com'
 -WorkspaceONEAdmin 'administrator' -WorkspaceONEAdminPW 'P@ssw0rd' -WorkspaceONEAPIKey 'YeJtOTx/v2EpXPIEEhFo1GfAWVCfiF6TzTMKAqhTWHc=' 
-OrganizationGroupName 'Digital Workspace Tech Zone' -SmartGroupName 'All Devices'

You will see in the video below, that running that script will pull in your sensors directly into Workspace ONE, assign them out, and get you off to a really solid start:

Building Windows 10 Sensors in Workspace ONE

You can build your own custom sensors in Workspace ONE pretty easily. It simply comes down to you writing some Powershell code that gives you the proper format to send up WS1 Intelligence. Some example code below is this code that I wrote to capture the current version of the Office Client as found on my Github:

Microsoft.Win32.RegistryView]::Registry64)
$subKey = $key.OpenSubKey("SOFTWARE\Microsoft\Office\ClickToRun\Configuration")
$regkey_value = $subKey.GetValue("ClientVersionToReport")
return $regkey_value

Windows sensors can be super helpful in elevating your Modern Management story. In my video above, you saw how I built a Spooler sensor. I am frequently looking at situations that surface and writing new sensors to provide business intelligence proactively. We should always try to show that we IT Security allies, which builds credibility.

Remember, make sure your end result is a string, integer ONLY. That is crucial. Like you can see below:

Troubleshooting Windows 10 Sensors on Workspace ONE UEM

The last part of digging into Windows 10 Sensors is troubleshooting. Honestly, the biggest issue I find with Windows 10 on WS1 UEM is troubleshooting. We tend to spend more time in silly places looking for info than I’ve ever seen. You may win up in the registry or these other strange areas, but I like the info we get on sensors.

Check out the video below to get a small overview and then we will dig in more:

So, let’s check out one of these error logs I pulled out of the Troubleshooting section:

Sensor : os_disk_free_space logs : Sensor Data Name: os_disk_free_space returns 30450212864 is invalid because expected type is Integer; Sensor : bc_hashcache_maxcachesizeasnumberofbytes logs : Sensor Data Name: bc_hashcache_maxcachesizeasnumberofbytes returns 2541727211 is invalid because expected type is Integer; Sensor : bc_datacache_maxcachesizeasnumberofbytes logs : Sensor Data Name: bc_datacache_maxcachesizeasnumberofbytes returns 12708636055 is invalid because expected type is Integer; Sensor : bc_datacache_cachefiledirectorypath logs : Sensor Data Name: bc_datacache_cachefiledirectorypath returns C:\WINDOWS\ServiceProfiles\NetworkService\AppData\Local\PeerDistRepub is invalid because expected type is Integer; Sensor : battery_actual_capacity logs : Sensor Data Name: battery_actual_capacity returns is invalid because expected type is Integer;

We can investigate one of these being “os_disk_free_space.

So from the console, this is the code:

From here, I test out the script:

So it says its an integer, but I think it could be a length issue. Let’s clean this up then. My new code is:

# Returns C: Drive Available Free Space (Bytes)
# Return Type: Integer
# Execution Context: System
 $cdrive=Get-WmiObject -Class Win32_logicaldisk | where DeviceID -eq "C:" | select @{Name="FreeSpace";Expression={[math]::round($_.FreeSpace/1GB, 2)}}
$cdrive = [int]$cdrive.FreeSpace
write-output $cdrive

Once I modified that script, because I’ve found that sensors that return super long values like that can be issues. I prefer to modify most of my sensors to be MB or GB as bytes is a bit silly.

Final Thoughts

To summarize things, Windows Sensors are very powerful as you can see, but they’re also time consuming. I’ve found myself stuck in the weeds sometimes when writing sensors, but it’s more about understanding how they work. Once you grasp the basics, you can build powerful data constructs.

When we invest like we do in a platform like Workspace ONE, we must take advantage of its power. Leveraging sensors, intelligence, and data to automate and simplify is why you buy Workspace ONE over Intune. I’ve learned over the years that people rarely use products like they are intended, but that comes down to poor documentation. I’m a major advocate for empowering engineers so they can push the limits. WS1 UEM sensors are another example of pushing a product to its limits to deliver amazing experiences.