Awhile back, I wrote about how Workspace ONE’s Digital Employee Experience (DEEM) can elevate your user experience. Today, we shift to MacOS which is recently GA. We will cover how to deploy and package the MacOS DEEM client, discuss the various dashboard widgets you can use, and show you how some of this data is useful. Let’s get started!
Deploying the MacOS DEEM Client
Deploying the DEEM client for MacOS is relatively simple. You can go out and get the client download from here and use the VMware Admin Assistant to deploy it via Workspace ONE Application Deployments. It’s pretty simple overall.
Feel free to check out the video below to see how the deployment works, but it’s a piece of cake!
I figured it would be useful if you have the uninstall script at your disposal to keep things simple:
#!/bin/bash
#Generate application uninstallers for macOS.
#Parameters
DATE=`date +%Y-%m-%d`
TIME=`date +%H:%M:%S`
LOG_PREFIX="[$DATE $TIME]"
#Functions
log_info() {
echo "${LOG_PREFIX}[INFO]" $1
}
log_warn() {
echo "${LOG_PREFIX}[WARN]" $1
}
log_error() {
echo "${LOG_PREFIX}[ERROR]" $1
}
#Check running user
if (( $EUID != 0 )); then
echo "Please run as root."
exit
fi
echo "Welcome to Application Uninstaller"
echo "The following packages will be REMOVED:"
echo " VMware.Deem-21.12.191"
#Need to replace these with install preparation script
VERSION=21.12.191
PRODUCT=VMware.Deem
echo "Stopping the daemon: deemd"
set -e
/bin/launchctl unload "/Library/LaunchDaemons/com.vmware.deemd.plist"
rm /Library/LaunchDaemons/com.vmware.deemd.plist || true
echo "Application uninstalling process started"
# remove link to shorcut file
find "/usr/local/bin/" -name "deemd" | xargs rm
if [ $? -eq 0 ]
then
echo "[1/4] [DONE] Successfully deleted shortcut links"
else
echo "[1/4] [ERROR] Could not delete shortcut links" >&2
fi
#forget from pkgutil
pkgutil --forget "com.vmware.$PRODUCT.$VERSION" > /dev/null 2>&1
if [ $? -eq 0 ]
then
echo "[2/4] [DONE] Successfully deleted application informations"
else
echo "[2/4] [ERROR] Could not delete application informations" >&2
fi
#remove application source distribution
[ -e "/Library/Application Support/VMware/${PRODUCT}" ] && rm -rf "/Library/Application Support/VMware/${PRODUCT}"
if [ $? -eq 0 ]
then
echo "[3/4] [DONE] Successfully deleted application"
else
echo "[3/4] [ERROR] Could not delete application" >&2
fi
#remove deem log file
[ -e "/Library/Logs/VMware/Deem" ] && rm -rf "/Library/Logs/VMware/Deem"
if [ $? -eq 0 ]
then
echo "[4/4] [DONE] Successfully deleted logs"
else
echo "[4/4] [ERROR] Could not delete logs" >&2
fi
echo "Application uninstall process finished"
exit 0
One thing to keep in mind, the ingestion should be pretty quick.. They say about 10-15m before you start seeing devices in Intelligence. Next, we will cover a breakdown of the DEEM widgets that you can use.
Workspace ONE DEEM Categories
The reason we do all of this is to get information ingested into Workspace ONE to be used to run automations, open help desk tickets, etc. With that in mind, let’s cover the different categories you can leverage and an example of the widgets themselves.
There are 8 categories you can leverage:
- Apps
- Asset Information
- Devices
- Device Performance
- Display
- Services
- Software Updates
- User Actions
You can see an example dashboard below:
Let’s cover the different DEEM categories available for MacOS.
MacOS App Events in DEEM
The Apps Category will capture several data points, which we highlight below:
Characteristic | What is it? |
App Install Path | Where its installed |
Device Serial Number | Device Serial # |
Activation Time | App Start Time |
App Name | Name of the App |
App Version | App Version |
App End Time | App Stop Time |
Create Time | I believe this matches Start Time, but is only captured for some apps like Console |
Duration in MS | The length of app use |
Event Type | The type of event |
OS Information | They capture OS major version, minor version, and name. |
Event ID | Event ID in Intelligence |
Event Received Time/ Event Time | When the Event was created |
Last Sync Time | When the event was last synchronized |
Package Publisher and Version | Collects the Package Publisher and Version if Applicable |
Agent Version | Version of the DEEM Agent |
Platform | Captures the Device Platform |
Process Identifier | The PID |
Source System ID | The System ID of the device |
Event Name | Name of the Event e.g. Application Foreground or Application Start |
Device Make | Device Manufacturer |
Device Model | The Model of the Device |
Device Name | The Name in WS1 |
OS Version | Full OS Version |
Username | Username |
Workspace ONE UEM Device GUID | The Device GUID in the DB |
Just a few notes, the application area is focused on application starts, stops, moves to foreground, etc. I don’t see a huge benefit for automation here on MacOS, whereas on Windows you could run automations based on exit codes, but the information itself is really useful I think when evaluating issues.
MacOS Asset Information in DEEM
Let’s cover Asset Information for DEEM, which I like a bunch because it shows you how many devices are live in your environment:
Now, let’s look at our options:
Characteristic | What is it? |
Device Make | Device Manufacturer |
Device Model | The Model of the Device |
Device Name | The Name in WS1 |
Device Serial Number | Device Serial # |
Agent Version | Version of the DEEM Agent |
Event Received Time/ Event Time | When the Event was created |
Event Type | The type of event |
Last Sync Time | When the event was last synchronized |
OS Information | They capture OS major version, minor version, and name. |
OS Version | Full OS Version |
Platform | Captures the Device Platform |
Source System ID | The System ID of the device |
System Type | The System Architecture e.g. x86_64h |
Time Zone | EST |
Workspace ONE UEM Device GUID | The Device GUID in the DB |
Processor | The Processor Type e.g. Apple M1 |
Physical Memory in Bytes | The RAM Size |
BIOS Version | The BIOS version |
We certainly have fewer options for Asset information, but I think we can use these options way more effectively. Potentially I could see using the device time zones, processors, etc. to run scripts, send notifications, and do some very interesting things. You can see that the major focus on asset information is on the hardware itself. One thing that I could see is missing is some sort of AppleCare integration, but overall very useful.
MacOS Device Events in DEEM
Let’s check out what we can do with device information:
Characteristic | What is it? |
Device Serial Number | Device Serial # |
Agent Version | Version of the DEEM Agent |
End Time | End time of the event |
Event ID | Event ID in Intelligence |
Event Type | The type of event |
Last Sync Time | When the event was last synchronized |
OS Information | They capture OS major version, minor version, and name. |
Platform | Captures the Device Platform |
Result | The result of the event |
Source System ID | The System ID of the device |
Event Name | Name of the Event e.g. Shutdown, Boot |
Device Make | Device Manufacturer |
Device Model | The Model of the Device |
Device Name | The Name in WS1 |
OS Version | Full OS Version |
Event Received Time/ Event Time | When the Event was created |
Event Status | Status of the Event |
Workspace ONE UEM Device GUID | The Device GUID in the DB |
Device Events are certainly an interesting area that focuses on how well people’s apps are running overall. I think some evolution needs to happen here like we are doing with PC to properly evaluate the health and posture of a device based on these events. You can clearly see that this category focuses on devices shutting down and powering up/booting.
MacOS Device Performance Events in DEEM
One of the largest areas is device performance events. Let’s take some time and look at what sort of data it collects:
Characteristic | What is it? |
Device Make | Device Manufacturer |
Device Model | The Model of the Device |
Device Name | The Name in WS1 |
Device Serial Number | Device Serial # |
Agent Version | Version of the DEEM Agent |
Battery Status Remaining Capacity | The number of cycles before you should consider replacing the battery |
Event ID | Event ID in Intelligence |
Event Name | Name of the Event e.g. Performance Counters |
Event Received Time/ Event Time | When the Event was created |
Event Type | The type of event |
GPU Name | Name of the GPU e.g.: Intel UHD Graphics 630 |
GPU 0 Usage | How much the GPU is being used |
Last Sync Time | When the event was last synchronized |
Logical Disk Percentage Free Space | How much HDD space is free |
Memory Committed Bytes in use | How much memory is being used |
Memory Usage Percentage | Percentage of memory being used |
Network Interface Packets Outbound Errors | Count of NIC Packet Outbound Errors |
Network Interface Packets Received Errors | Count of NIC Packet Received Errors |
OS Information | They capture OS major version, minor version, and name. |
OS Version | Full OS Version |
Paging File Usage | How much of the paging file is in use |
Physical Disk Avg Disk Read per sec | The level of physical disk average read per second |
Physical Disk Avg Disk Write per sec | The level of physical disk average write per second |
Platform | Captures the Device Platform |
Processor Total Idle Time | The Processor Idle Time |
Processor Total Privileged Time | The total time the processor spent processing threads spent executing code in privileged mode |
Processor Total Processor Time | The total time the processor spent processing threads |
Processor Total User Time | The total time the processor spent running user application code |
Source System ID | The System ID of the device |
Thermal Zone Information Zone Temperature | The device thermal zone information |
Workspace ONE UEM Device GUID | The Device GUID in the DB |
Device performance is an extremely interesting area. The top automation that I would suggest running here is devices under 500 battery changes to create ServiceNow tickets to replace their battery. You also have other potential things to capture about logical disk free space, and NIC performance. We have some great opportunities here to take advantage of.
MacOS Display Events
Now, we discuss display events, which cover things that impact the display of your device. Let’s cover the characteristics of display!
Characteristic | What is it? |
Device Make | Device Manufacturer |
Device Model | The Model of the Device |
Device Name | The Name in WS1 |
Device Serial Number | Device Serial # |
Agent Version | Version of the DEEM Agent |
Event ID | Event ID in Intelligence |
Event Name | Name of the Event e.g. Screen Saver Off, Sleep, Wake etc. |
Event Received Time/ Event Time | When the Event was created |
Event Status | Status of the Event |
Event Type | The type of event |
Last Sync Time | When the event was last synchronized |
OS Information | They capture OS major version, minor version, and name. |
Platform | Captures the Device Platform |
Source System ID | The System ID of the device |
User | Username |
Workspace ONE UEM Device GUID | The Device GUID in the DB |
This is a category that I think will contribute well to user score, but isn’t super helpful at face value. These events will definitely be useful as we aggregate data overall.
MacOS Services Events
MacOS Services events refer to capturing the installation of services. Similar to a few other categories, I think it will be much more useful when user score is brought in for MacOS.
Characteristic | What is it? |
Device Make | Device Manufacturer |
Device Model | The Model of the Device |
Device Name | The Name in WS1 |
Device Serial Number | Device Serial # |
Agent Version | Version of the DEEM Agent |
Event ID | Event ID in Intelligence |
Event Name | Name of the Event e.g. Service Installed |
Event Received Time/ Event Time | When the Event was created |
Event Status | Status of the Event |
Event Type | The type of event |
Last Sync Time | When the event was last synchronized |
OS Information | They capture OS major version, minor version, and name. |
OS Version | Full OS Version |
Platform | Captures the Device Platform |
Service Name | The name of the service in reverse DNS notation |
Service Path | The path of the service |
Source System ID | The System ID of the device |
Workspace ONE UEM Device GUID | The Device GUID in the DB |
MacOS User Action Events
The final section to cover are user action events. This might be the most important of them all. The best automation is probably for capturing failed logon attempts and using them to generate emails and/or tickets to help out your users as needed when they are struggling. In the final section, we will show you how to build a widget focusing on failed logins.
Characteristic | What is it? |
Device Make | Device Manufacturer |
Device Model | The Model of the Device |
Device Name | The Name in WS1 |
Device Serial Number | Device Serial # |
Agent Version | Version of the DEEM Agent |
Event ID | Event ID in Intelligence |
Event Name | Name of the Event e.g. Lock, Unlock, Logon |
Event Received Time/ Event Time | When the Event was created |
Event Status | Status of the Event |
Event Type | The type of event |
Last Sync Time | When the event was last synchronized |
OS Information | They capture OS major version, minor version, and name. |
OS Version | Full OS Version |
Platform | Captures the Device Platform |
Result | The result of the Event |
Service Name | The name of the service in reverse DNS notation |
Service Path | The path of the service |
Source System ID | The System ID of the device |
User | Username |
Workspace ONE UEM Device GUID | The Device GUID in the DB |
Creating a Widget for Failed Logins
Final Thoughts
I’d like to apologize for hammering you with Table Hell. There is no real good way to bring something like user device data analytics to life. It’s such a subjective technology that only by showing you what potential options you have can you be successful. I think MacOS DEEM is very much in its infancy, but it is getting us off to a good start. MacOS Sensors still have their place in the landscape, but DEEM can definitely provide you with some great “intelligence” to deliver great user experiences.
Once this platform is brought into our DEEM Dashboard, we can definitely feel like this product has arrived like this below:
Data is very useful, but we need some of that fancy Intelligence to analyze and aggregate the information into a user score. User Scores are the wave of the future and the only real objective way to decide if a machine is happy or sad.