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

1. Purchase devices from Dell, specifying that these devices “Use Provisioning by VMware AirWatch.” After purchase, record the devices’ serial numbers.
2. Enable Auto Enrollment in the AirWatch console and register the device serial numbers.
3. Dell Custom Factory Image (CFI) provisions the device and ships it out to the end user.
4. On first boot, the device checks with AirWatch, enters into provisioning mode and brands the device.
5. End user authenticates and completes out-of-box enrollment.
6. 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:
  • Batch Import
  • Add Device
  • Register Device

Configure Dell Auto-Enrollment for Windows 10

1. After meeting the licensing and registration requirements, log into the AirWatch console.
2. In the enrollment organization group, navigate to Groups & Settings > All Settings > Devices & Users > Windows > Windows Desktop >Auto Enrollment.
3. 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.
4. Click Save to push the settings to registered devices.

Troubleshoot Dell Auto-Enrollment for Windows 10

Logging Location: C:ProgramDataAirwatchUnifiedAgentLogs

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.

[Related: Consumer Simple, Enterprise Secure: BitLocker Encryption Lifecycle Management]

Troubleshoot Bitlocker for Windows 10

To troubleshoot, check the logs from the most likely, to the least likely source of error.

1. 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.
2. Check the machine’s health in Event Viewer: Microsoft-Windows-BitLocker/BitLocker Management.
3. Update the AirWatch logging level to Verbose: %ProgramFiles(x86)%AirWatchAgentUITaskScheduler.exe.config
4. Republish the profile to capture the verbose data.
5. Pull the verbose Protection Agent logs: C:ProgramDataAirwatchUnifiedAgentLogs

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

Peer-to-Peer Server Download

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 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.

1. Meet the Requirements to Deploy Win32 Applications for Software Distribution to enable the software package deployment.
2. Configure Peer Distribution Software Setup.
3. Configure Peer Distribution Software Setup to install and activate peer-to-peer clients on devices.
4. 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 DB. 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_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

1. In this example, the rendezvous point (RVP) in the central office sends the initial application package to Boston (default) and Lima.
2. 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.
3. The RVP in Miami receives the package from the Baltimore office.
4. 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 and 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 and 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 SubnetsDefine 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 to Azure Active Directory Integration for Windows 10

Configure custom 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

1. In the AirWatch Console, navigate to Groups & Settings >All SettingsEnterprise Integration Directory Services.
2. Enable the setting Use Azure AD for Identity Services.

AirWatch 9.2: UEM for Chrome OS

How UEM for Chrome OS Works

In 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, VMware AirWatch manages the device.

Here’s how it works:

1. Devices register into Google’s Chrome OS device management infrastructure.
2. AirWatch manages settings, apps and configurations for devices by issuing API calls to the device management infrastructure
3. Device management infrastructure forwards the appropriate settings and profiles to devices.

UEM for Chrome OS Requirements

• Chrome Enterprise License – Enables VMware 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 withEnrollment 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 into 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

1. 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
2. After processing the request, the AirWatch Chrome OS Management Team provides the:
   • Service Account Email
   • Client ID
   • Authentication Certificate

Setup Google Admin Console

1. Log into the Google Admin Console.
2. Navigate to Security> API Reference > API Accessand select Enable API access.
3. Navigate to Security Advanced SettingsManage 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
4. Navigate to Device Management> Chrome ManagementDevice Settings and:
   • Scroll to the bottom of the page, and enable the Chrome Device Management – Partner Accesssetting.
   • In the bottom right-hand corner of the page, click the SAVE link.
5. Navigate to Device Management> Chrome Management > User Settingsand:
   • 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 the SAVE link.

Integrate Google’s Chrome OS Device Management Infrastructure with AirWatch

1. Log into the AirWatch Console, and navigate to Settings System Settings > Devices & Users > Chrome OS > Configuration.
2. 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

1. 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.
2. 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.
3. 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 Webstore, 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.

AirWatch 9.2: Granular Device Assignment for Android

Select which Android devices or users can enroll at a particular organization group:

• Override Android for Work at an Organization Group
• Limit Enrollment to a specific Smart Group

Configure Granular Device Assignment for Android

1. In the AirWatch Console, navigate to Devices & Users > Android > Android for work.
2. 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
3. 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

1. In the AirWatch Console, navigate to Devices & Users > Android > Android for work.
2. Select the Enrollment Settings tab and set the Work Managed Enrollment Type:
3. 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 Unified Endpoint Management, 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.
• 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

1. Register Samsung Enterprise Firmware Over The Air Updates  – For the Client ID field in the AirWatch Console, provide the token from Samsung EFOTA.
2. Configure Restrictions Profile (Samsung EFOTA) – Enable the restriction Register Enterprise FOTA for feature to work.
3. Publish Firmware Updates (Android)  – Updates apply to the same devices that the Register Enterprise FOTA restrictions profile applies to.

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).

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: