VMware AirWatch 9.2 Deep Dive, Part 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

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.

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:ProgramDataAirwatchUnifiedAgentLogs

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.

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

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.

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.

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.

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_MACHINESOFTWAREAdaptivaserver

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

%WINDIR%AdaptivaSetupLogsClientAdaptivaClientMSISetup.log

%WINDIR%AdaptivaSetupLogsClientAdaptivaClientSetup.log

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.

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.

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.

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.

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.

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.

BEST PRACTICE: Due to the sequence of operations, publish AirWatch User Profiles before allowing users to log into Chrome OS devices.

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: Enrollment Types for Android

Configure Enrollment Types for Android

Select the Enrollment Settings tab and set the Work Managed Enrollment Type:

Click Save, when finished.

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

BEST PRACTICE: The customer-level organization group requirement ensures updates push to all registered devices. To test updates on a device subset prior to a full-scale rollout, create a separate organization group for testing.

New! UEM for IPC Rugged 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.