[Deep Dive] Unified Endpoint Management in VMware AirWatch 9.2 & FP01
VMware AirWatch unified endpoint management (UEM) empowers the digital workspace to meet business needs. By unifying endpoint management into a single point of reference, the solution delivers a premium user experience that doesn’t compromise enterprise security.
What’s New in AirWatch 9.2 UEM
Today’s post covers the new AirWatch 9.2 release and feature pack (FP01) of UEM features.
Note: The green headers separate the features by platform. The features display in the relevant platform section. Each feature is listed with its own title, which specifies the release version. Where applicable, click arrows at the bottom of the feature’s section to view more information.
New! Windows 10 Management Features
AirWatch 9.2: Dell Auto Enrollment for Windows 10
Eliminate manual configuration of PCs, and drop-ship devices that auto-configure upon first boot straight to end users.
How Dell Auto-Enrollment Works
- Purchase devices from Dell, specifying that these devices Use Provisioning by VMware AirWatch. After purchase, record the devices’ serial numbers.
- Enable Auto-Enrollment in the AirWatch console and register the device serial numbers.
- Dell Custom Factory Image (CFI) provisions the device and ships it out to the end user.
- On first boot, the device checks with AirWatch, enters into provisioning mode and brands the device.
- End user authenticates and completes out-of-box enrollment.
- Profiles and apps push down to the device. Policies can be forced on the device before the end user’s first log on.
Dell Auto-Enrollment for Windows 10 Requirements
- Purchase includes Windows 10 Provisioning by AirWatch: AirWatch licensing is available with Dell OEM SKUs and VMware third-party SKUs. Contact a sales representative for clarification.
- Register device serial numbers in AirWatch console: Use one of three workflows to register serial numbers:
Configure Dell Auto-Enrollment for Windows 10
- After meeting the licensing and registration requirements, log into the AirWatch console.
- In the enrollment organization group, navigate to Groups & Settings > All Settings > Devices & Users > Windows > Windows Desktop > Auto Enrollment.
- Configure the settings:
- Auto Enrollment: Enable to use Windows 10 Provisioning by AirWatch.
- Sync Interval: Select the amount of time between sync attempts between the provisioning AirWatch Agent and the AirWatch console.
- Enforce Policies Before Log In: Select Enable to enforce the device policies before the user logs into the device.
- Maximum Time Before Log In: Select the maximum number of minutes that may pass before a user logs in after completing the out-of-box experience.
- Click Save to push the settings to registered devices.
Troubleshoot Dell Auto-Enrollment for Windows 10
Logging Location: C:\ProgramData\Airwatch\UnifiedAgent\Logs
AirWatch 9.2: Windows 10 Local Account Password Reset
Reset local Windows account passwords to maximize employee productivity without compromising endpoint security. Password reset provides a quick solution for employees locked out of their accounts, and enables IT to reset passwords for security purposes.
AirWatch 9.2: Collect & Display Windows 10 IP & MAC Addresses
Collect and display Windows devices’ IP and MAC address in the AirWatch console. Once collected, use these values to create asset data reports, validate device data during troubleshooting and perform other key tasks.
AirWatch 9.2: BitLocker Enhancements for Windows 10
Manage the full encryption lifecycle for Windows 10 devices. To secure Windows 10 device data with BitLocker, create an Encryption profile. Then, enforce it by configuring a compliance policy that includes encryption status as part of the device’s general security posture.
Troubleshoot Bitlocker for Windows 10
To troubleshoot, check the logs from the most likely, to the least likely source of error.
- On a device that does not have AirWatch installed, attempt to run manage-bde -on C: The error message “TPM not enabled” indicates there was a setup error, and must be corrected before continuing.
- Check the machine’s health in Event Viewer: Microsoft-Windows-BitLocker/BitLocker Management.
- Update the AirWatch logging level to Verbose: %ProgramFiles(x86)%\AirWatch\AgentUI\TaskScheduler.exe.config
- Republish the profile to capture the verbose data.
- Pull the verbose Protection Agent logs: C:\ProgramData\Airwatch\UnifiedAgent\Logs
AirWatch 9.2: Dell BIOS for Windows 10
Enable over-the-air configuration and modification of BIOS settings without requiring physical access to the computer.
Dell BIOS for Windows 10 Requirements
- Deploy the Dell Command | Monitor client to devices using Software Distribution. For more information see Dell Command | Monitor Integration.
- Configure and publish BIOS profile to devices.
Configure a Dell BIOS Profile for Windows 10
- Navigate to Devices > Profiles > List View > Add and select Add Profile.
- Select Windows and then select Windows Desktop.
- Select Device Profile.
- Configure the profile General settings to determine how the profile deploys and who receives it. For more information, see “Add General Profile Settings.”
- Select the BIOS payload and configure the settings.
- Select Save & Publish.
Troubleshoot Dell BIOS for Windows 10
- Communication flow for BIOS profile: Profile > Protection Agent > Dell Command | Monitor. Before pulling protection agent logs, troubleshoot Dell Command | Monitor.
- Pull verbose Protection Agent logs: C:\ProgramData\Airwatch\UnifiedAgent\Logs
AirWatch 9.2 FP01: Peer-to-Peer Distribution for Windows 10 UEM
AirWatch offers a peer distribution system to deploy Win32 applications to enterprise networks. Peer distribution can reduce the time to download large applications to multiple devices in deployments that use a branch office structure.
SaaS Architecture for Windows 10 Peer Distribution
Peer-to-peer distribution (peer distribution) modernizes enterprise-wide software deployments for PCs. Here’s an overview of how it works:
Windows 10 Peer Distribution Core Components
- Peer-to-Peer Server: Maintains the metadata of the Win32 applications but not the actual application packages. It also maintains information about clients, client IP addresses, the number of active clients and the content presently at each client. This component resides in your network, and it must communicate with these components.
- VMware System Enterprise Connector: You can install the server and the VMware System Enterprise Connector on the same machine.
- SQL Database or SQL Server Express
- Peer-to-peer clients on devices
- Peer-to-Peer Client: Distributes application packages between peers, or devices, and receives application metadata from the server. After software setup completes, clients deploy automatically. Each installed client uses one license. This component resides on devices, and it must communicate with these components.
- Software distribution clients on devices
- Peer-to-peer server
Important Considerations for Windows 10 Peer Distribution
- Encryption: Communication between the peer-to-peer server and AirWatch is encrypted. The communication is not encrypted between peer-to-peer clients in the network. This communication uses User Datagram Protocol (UDP), but the package itself is not encrypted between clients. Although the system checks for tampered packages, a best practice is to not send confidential packages with peer-to-peer distribution.
- License Overages: The peer-to-peer system does NOT prevent the assignment of more licenses than purchased. Instead, the system just charges for these. For this reason, use the Peer Distribution list view in the AirWatch console to monitor the number of active licenses.
- Console, Client & Server Versions: You must deploy and use the supported version of the peer-to-peer client and the peer-to-peer server. Update the peer-to-peer server when the AirWatch console includes an update to the peer-to-peer client. If the versions are not supported, the feature does not work.
- Application Metadata: The peer-to-peer system stores and transmits the blob ID (or content ID), the application size and the application hash. It does not store or transfer any other data.
- Initial Downloads: The first download in a peer distribution process takes the longest time. After the initial downloads, and as more devices in the subnet receive the application, download times get faster.
Windows 10 Peer Distribution Configuration Overview
The deployment of applications with the peer-to-peer distribution system requires you to set the listed configurations in the AirWatch console and on devices.
- Meet the Requirements to Deploy Win32 Applications for Software Distribution to enable the software package deployment.
- Configure Peer Distribution Software Setup.
- Configure Peer Distribution Software Setup to install and activate peer-to-peer clients on devices.
- Upload and publish applications to the peer-to-peer server. See Application Lifecycle for Software Distribution.
Windows 10 Peer Distribution Requirements
- SQL Database or SQL Server Express: The peer-to-peer server uses SQL Database to store application metadata and information about the network topology. To meet this requirement, leverage SQL Express or the current SQL Database. To download SQL Server Express, outbound port 443 must be open.
- VMware System Enterprise Connector: Enable VMware System Enterprise Connector with the All Other Components setting enabled. To verify this configuration in the AirWatch console, navigate to Groups & Settings > All Settings > Enterprise Integration > VMware System Enterprise Connector > Advanced > AirWatch Services > All Other Components.
- Software Package Deployment: Enable the Software Package Deployment setting so that AirWatch recognizes application packages deployed through software distribution. Go to Groups & Settings > All Settings > Device & Users > Windows > Windows Desktop > App Deployments and enable the setting.
- File Storage (On-Premises): AirWatch stores Win32 applications on a secure file storage system. Peer-to-peer clients receive application packages from the storage system when clients cannot find other clients with the application package.
Activate Windows 10 Peer Distribution
After the configurations save, the system activates the peer-to-peer server and clients with a license key. During activation, existing Win32 application content publishes to the peer-to-peer server. From this point on, devices that belong to the peer distribution network begin to receive the application download.
By default, if a client fails to check in after 21 days, it is purged from the Adaptiva database and a license is reclaimed. To change the purge threshold:
- Key: HKEY_LOCAL_MACHINE\SOFTWARE\Adaptiva\server
- Value: client_data_manager.inactive_client_duration
- Value Type: REG_SZ
- Value: This is the number of milliseconds the server uses as a threshold for when to deleted clients. The default value is 1814400000 (21 days)
Client Logs for Windows 10 Peer Distribution
Network Topology for Windows 10 Peer Distribution
- In this example, the rendezvous point (RVP) in the central office sends the initial application package to Boston (default) and Lima.
- Following the North American side, the RVPs in the Boston (Wi-Fi), Baltimore and Toronto offices receive the application package from the Boston (default) office.
- The RVP in Miami receives the package from the Baltimore office.
- If a package is not available for any reason, offices receive it from the backup file storage system or content delivery network.
Rendezvous Points (RVPs)
Representing your network as a hierarchy of offices enables the peer distribution system to deploy applications more efficiently. The hierarchy controls the clients and the order downloads occur. It uses devices called rendezvous points, or RVPs, as master clients in an office. The RVP receives downloads and disseminates the applications to peer clients.
- RVP: Rendezvous Point, exists one per subnet.
- Super RVP: Offices with more than one subnet have multiple RVPs. In these cases, one gets designated as the Super RVP. It is responsible for content location when communicating to parent offices.
RVP Election Process
When an RVP is shut down, a new one gets elected using the following criteria:
- Largest actual free space (over 64GB is randomized)
- Identified as preferred, also called RVPs
- Chassis type (desktop has precedent over laptops)
- Operating system type (server has precedence over workstations)
- Longer system up-times
- Largest usable free space
Offices & Subnets
Offices contain one or more subnets can retrieve content from their parent offices, and can distribute to their child offices. Office Types are designated based on the way the office shares data.
- Default: Defines a standard wired LAN. Clients send broadcast discovery requests.
- VPN: Defines an office and subnet range allocated for clients connecting through VPN. Clients within a VPN office do not attempt to share content, but they do send broadcast discovery requests.
- Wi-Fi: Clients within a Wi-Fi office share content, but they do not send broadcast discovery requests.
- Wi-Fi Networks in Default Offices: If you have a physical office with a wired (default) subnet and a Wi-Fi subnet, create an office for each network. Make the Wi-Fi office a child of the wired office so that the Wi-Fi network receives packages from the wired parent office.
- Central Office & the Peer-to-Peer Server: The peer-to-peer server must reside in one of the subnets in the top-tiered Central Office. This placement makes it available to all clients in the hierarchy.
Data Transport in Offices
The system distributes content from a parent to child office once. This behavior limits data sent across wide area network (WAN) links.
- Adaptive Protocol: The adaptive protocol is a proprietary protocol that monitors the length of edge router queues and sends data when queues are nearly empty. This protocol, implemented by an advanced kernel driver, removes the need to throttle bandwidth when deploying applications with peer distribution.
- Within Offices: Data transport within offices uses the LAN, or Foreground protocol. The peer distribution system does not manage this protocol.
- Between Offices: Data transport between offices uses the WAN, or Background protocol. This protocol is also called the Adaptive Protocol. It is designed to protect bandwidth availability on WAN links.
- Between Subnets: Define subnets connected over a WAN link as separate offices. If offices are misconfigured, the LAN protocol might be used over a WAN link, causing saturation of the WAN.
AirWatch 9.2 FP01: Active Directory (AD) to Azure Active Directory (ADD) Integration for Windows 10
Configure custom Lightweight Directory Access Protocol (LDAP) attributes that map active directory users to Azure Active Directory for hybrid use cases. The LDAP attribute searches AirWatch for a match with the Azure ImmutableID. By default, this value is “ObjectGUID” and in binary format. However, this can be customized for organizations with forest domains syncing to Azure as well as other, non-standard configurations.
Configure AD to AAD Integration for Windows 10
- In the AirWatch console, navigate to Groups & Settings > All Settings > Enterprise Integration Directory Services.
- Enable the setting Use Azure AD for Identity Services.
AirWatch 9.2 FP01: Enterprise Wipe Protection for Windows 10
Protect managed and unmanaged Windows devices from unintended enterprise wipes. This provides Windows devices with the same wipe protections as iOS and Android mobile devices.
AirWatch 9.2 FP01: BitLocker Enhancements for Local Enforcement
In Windows Protection Agent 188.8.131.52 and above, BitLocker enforcement no longer depends on network connection or sample intervals. Instead, BitLocker continually enforces encryption, preventing anyone from locally disabling the encryption.
New! Chrome OS Management Features
AirWatch 9.2: UEM for Chrome OS
How UEM for Chrome OS Works
With AirWatch UEM for Chrome OS, physical communication to devices gets handled by Google’s Chrome OS device management infrastructure. This differs from other platforms, such as iOS and Android, where devices communicate directly to the AirWatch Device Services server. However, for all platforms, AirWatch manages the device.
Here’s how it works:
- Devices register into Google’s Chrome OS device management infrastructure.
- AirWatch manages settings, apps and configurations for devices by issuing API calls to the device management infrastructure.
- Device management infrastructure forwards the appropriate settings and profiles to devices.
UEM for Chrome OS Requirements
- Chrome Enterprise License: Enable AirWatch to communicate with Google’s Chrome OS device management infrastructure and manage Chrome OS devices.
- Google Registered Domain Name
- Google Admin Console User Account with Enrollment Permissions: Enrollment permissions available by default for Google Console admins, but not for users. BEST PRACTICE: Instead of enabling Enrollment Permissions for each directory user, deploy devices through a staging user.
- Add Directory Users to the Google Admin Console: Use Google Cloud Directory Sync (GCDS) to sync Active Directory users into the Google Admin Console.
- Add Directory Users to the AirWatch Console: Use AirWatch Directory Services to sync Active Directory users with the AirWatch console. IMPORTANT: The AirWatch console uses this email address to identify the corresponding Google user, and push the appropriate User Profiles to Chrome OS devices. To maintain synchronicity, ensure the two email addresses are identical.
- User Group in AirWatch Console for Chrome OS Devices: Enable Add Group Members Automatically.
Request a Google Service Account
- Send an email to the AirWatch Chrome OS Management Team that contains the following:
- Customer Name: Provide name used in Google Admin Console
- Domain Name: Provide domain registered in Google Admin Console
- After processing the request, the AirWatch Chrome OS Management Team provides the:
- Service Account Email
- Client ID
- Authentication Certificate
Set Up Google Admin Console
- Log into the Google Admin Console.
- Navigate to Security > API Reference > API Access and select Enable API access.
- Navigate to Security Advanced Settings > Manage API client access, and configure the fields:
- Client Name: Enter the Client ID received from the Chrome OS Management Team.
- API Scopes: Copy and paste the following APIs into the field on the same line. Use a comma to separate the entries.
https://www.googleapis.com/auth/chromedevicemanagementapi https://www.googleapis.com/auth/admin.directory.user https://www.googleapis.com/auth/admin.directory.device. chromeos
- Navigate to Device Management > Chrome Management > Device Settings and:
- Scroll to the bottom of the page, and enable the Chrome Device Management – Partner Access setting.
- In the bottom right-hand corner of the page, click SAVE.
- Navigate to Device Management > Chrome Management > User Settings and:
- Scroll to the bottom of the page, and enable the Chrome Device Management – Partner Access setting.
- In the bottom right-hand corner of the page, click SAVE.
Integrate Google’s Chrome OS Device Management Infrastructure with AirWatch
- Log into the AirWatch console, and navigate to Settings > System Settings > Devices & Users > Chrome OS > Configuration.
- Under Chrome Developer Console Settings, enter the Service Account Email, Client ID and Authentication Certificate provided by the Chrome OS Management Team.
UEM Enrollment Workflow for Chrome OS
- Admin User: Adds Chrome OS to Google’s device management infrastructure:
- On the login screen of a new or factory reset device, press Ctl-Alt-e.
- When prompted, enter the Admin user’s email address and password.
- VMware AirWatch Admin: Installs AirWatch Device Profiles on Chrome OS devices:
- Log into the AirWatch console.
- Navigate to Devices > Device settings > Device &Users > Chrome OS > Configuration and select Device Sync.
- Newly enrolled devices receive AirWatch Device Profiles based on smart group membership.
- Employee: Triggers AirWatch User Profiles to install on Chrome OS devices:
- Log into the device.
- Google’s Chrome OS device management infrastructure applies AirWatch User Profiles based on user group assignment.
AirWatch Profiles for Chrome OS UEM
There are two types of profiles that apply to Chrome OS devices: device profiles and user profiles. Device profile assignment is based on the Smart Group the device belongs to. The user profiles assigned to Chrome OS devices are based on the User Group the logged on user belongs to.
The following diagram outlines the available profiles:
How User Profiles Work
User Profile assignment kicks off when a user gets added to the User Group in the AirWatch console. Adding a user triggers AirWatch APIs to send the assigned User Profiles to the appropriate user account in Google’s Chrome OS device management infrastructure.
Once sent, these profiles and settings simply exist within the device management infrastructure until that user logs into a Chrome OS device. Upon login, Google’s Chrome OS device management infrastructure applies the AirWatch user profile to the device.
Application Management for Chrome OS
Application management does not get configured under Apps & Books in the AirWatch console. Instead, to add apps from the Google Play Store and Chrome Web Store, configure the Application Control profile.
AirWatch 9.2 FP01: Network Profile for Chrome OS
The Network profile determines network connection settings for all Chrome OS devices. Configure this profile to establish password-based Wi-Fi for device policies and user policies on Chrome OS devices. To configure the Network profile:
- Navigate to Devices > Profiles & Resources > Profiles > Add > Add Profile > Chrome OS.
- Select Device to deploy settings to the device profile. Select User to deploy settings to the user profile.
- Configure the General profile settings as appropriate. These settings determine how the profile deploys and who receives it. For more information, see Add General Profile Settings.
- Select the Network payload.
- Configure Wi-Fi settings, including:
New! Android Management Features
AirWatch 9.2: Granular Device Assignment for Android
- Override Android for Work at an Organization Group
- Limit Enrollment to a specific Smart Group
Configure Granular Device Assignment for Android
- In the AirWatch console, navigate to Devices & Users > Android > Android for Work.
- Select the Enrollment Restrictions tab and Define devices that are allowed to utilize Android for Work. This limits enrollment to specific device models or operating systems. Select whether to:
- Enroll all compatible devices
- Do not use Android for Work
- Limit Android for Work enrollments to specific smart groups
- Click Save, when finished.
AirWatch 9.2: Enrollment Types for Android
Configure User or Device enrollment types for Android for Work.
Configure Enrollment Types for Android
AirWatch 9.2 FP01: Samsung EFOTA
Use Samsung Enterprise Firmware Over the Air (EFOTA) to review and push Android device updates. With AirWatch UEM, the updates are managed in the AirWatch console. Here’s a quick look at how the AirWatch Console, the device, and the EFOTA server communicate:
EFOTA for Samsung Requirements
- AirWatch Console v9.2.1
- Customer-level organization group
- AirWatch Agent v8.0
- ELM Service v4.0
- Safe v5.7+
- Android 7.0 Nougat+
- EFOTA License purchased from Samsung or authorized re-seller
Configure EFOTA for Samsung
- Register Samsung Enterprise Firmware Over The Air Updates – For the Client ID field in the AirWatch Console, provide the token from Samsung EFOTA.
- Configure Restrictions Profile (Samsung EFOTA) – Enable the restriction Register Enterprise FOTA for feature to work.
- Publish Firmware Updates (Android) – Updates apply to the same devices that the Register Enterprise FOTA restrictions profile applies to.
New! iOS Management Features
AirWatch 9.2: Support for iOS 11
AirWatch 9.2 supports iOS 11 and its features.
iOS 11 Requirements
- Seed Script: AirWatch 9.1 and below requires a seed script. Seed Script Download
- Custom Settings XML: Configure iOS 11 features not available for configuration in the AirWatch console using iOS 11 custom XML. Custom XML Download
- Certificates: Configure a Certificate payload. Then, configure a Custom Settings payload that references the Certificate’s universally unique identifier (UUID).
New! macOS Management Features
AirWatch 9.2: Bootstrap Package Support for macOS
Customize the onboarding experience for macOS using bootstrap packages, which deliver installer packages immediately upon enrollment (during the setup assistant in DEP).
Requirements for macOS Bootstrap Package
- Signed Distribution.pkg Only
- macOS device running v10.12.6 or higher (Older devices may have issues with a bootstrap .pkg.)
Configure macOS Bootstrap Packages
- Log into the AirWatch console.
- Navigate to Apps & Books > Internal > App Application.
- Set Deployment to Auto:
- Newly Enrolled Devices: Automatically install the package
- Existing Enrolled Devices: Do not automatically install the package; require manual initiation.
- For sample code, please read the bootstrap package design document. READ NOW
New! UEM for IPC Rugged Devices
AirWatch 9.2: Support for Infinite Peripherals Corporation (IPC) Devices
AirWatch 9.2 brings support for the IPC line of rugged devices featuring integrated barcode scanners, mag stripe readers and printers. Extending unified endpoint management to IPC devices makes it possible to deploy, secure and manage IPC devices from the same pane of glass as the rest of the mobile device fleet.
How IPC Rugged Device Management Works
AirWatch communicates with IPC devices via InfineaIQ, a cloud-based service. Here’s a basic diagram that shows how IPC rugged device management works:
Co-Authors & Reviewers
- AirWatch 9.2 Console Deep Dive, Part 1
- AirWatch 9.2 Feature Spotlight: Bootstrap Packages for macOS
- VMware & Dell Empower the Digital Workspace