Trying to find useful information in VMware logs is a nightmare, and often is rather useless. But at least with sensors we can check stuff.
Ok so first up, logs… Where for art thou logs? Well you can find them in c:\ProgramData\Airwatch\UnifiedAgent\Logs
Right, enough Ren and Stimpy you eeeediot, and back to this article…
TaskScedule-{date}.log is the one we are after.
So in my example, I had a previously working sensor I updated with new logic that stopped working, and results were no longer being collected in to UEM.
Luckily the sensor name is included in the logging, so you can search for it. The above image an excerpt of a live log, with the sensor name renamed.
{"@t":"2022-11-09T02:58:05.2260304Z","@mt":"Executing Sensor {definitionName}.","definitionName":"Flakey_Sensor","SourceContext":"VMware.WUA.DeviceSensor.Business.DeviceSensorSampleSender.DeviceSensorPowerShellExecutor","ThreadId":77,"ProcessId":5156,"ProcessName":"TaskScheduler","MachineName":"ComputerName","EnvironmentName":"Production","EnvironmentUserName":"Wsnone\\SYSTEM"}
Ok So we can from the above entry our sensor actually ran. The next few lines in the log tell us the things we want to know.
{"@t":"2022-11-09T02:58:06.5044050Z","@mt":"Parsing powershell output: {outputString}","outputString":"{\"Results\":[],\"ExecutionStatus\":1,\"TerminatingError\":null,\"Errors\":\"\",\"ExecutionTime\":412,\"ResultsProperties\":{},\"ExitCode\":0,\"ErrorCode\":null}","SourceContext":"AW.Win32.Utilities.Powershell.PowershellExecutionHelper","ThreadId":50,"ProcessId":5156,"ProcessName":"TaskScheduler","MachineName":"ComputerName","EnvironmentName":"Production","EnvironmentUserName":"WSNone\\SYSTEM"}
Ok so this is the line we want to look at:
- What is the Exit Code? We want 0.. Yup so its not that.
- Is There a Terminating Error? Nup… Good
- What is Results? Waaaait a minute, why is that Blank? Where is my results?
Ok so going back in to my code, which I’m not going to share, idiot here used Write-Host rather than Write-Output. We aren’t going in to go into how to write sensors, but using Write-Host was wrong, wrong wrong wrongity wrong. /Facepalm
So after fixing the sensor and running it again, what does the log look like now.
{"@t":"2022-11-09T03:14:19.9716513Z","@mt":"Parsing powershell output: {outputString}","outputString":"{\"Results\":[\"Hello I'm a result!"],\"ExecutionStatus\":1,\"TerminatingError\":null,\"Errors\":\"\",\"ExecutionTime\":417,\"ResultsProperties\":{\"Hello I'm a result!\":{\"Length\":\"9\"}},\"ExitCode\":0,\"ErrorCode\":null}","SourceContext":"AW.Win32.Utilities.Powershell.PowershellExecutionHelper","ThreadId":76,"ProcessId":5156,"ProcessName":"TaskScheduler","MachineName":"ComputerName","EnvironmentName":"Production","EnvironmentUserName":"WSNONE\\SYSTEM"}
Ok so we go through our list again:
- Exit Code? 0! Check
- Terminating Errors? Nope… Checkl.
- Results? Heeeeey there it is.
Ok cool! It works.
But what about Exit Codes and Terminating errors?
Exit codes are, or at least should be, the code your script exits with. To be honest I havent experimented with setting non 0 exit codes, because I dont want my script to fail. The return for the sensor is where the failure should be noted.
Terminating errors are a type of error that forces a script to terminate regardless, these tend to show up in the troubleshooting logs if they happen, so you dont have to dumpster dive in the haystack that is VMware client logs. You shouldnt have these if you are coding propery.
Hopefully a somewhat useful article on troubleshooting these things 🙂