Skip to end of metadata
Go to start of metadata

Purpose

The purpose of this page is to clarify what happens under the cover when a notification is sent from SAP Afaria / Mobile Secure to iOS device.

Overview

Since SAP Afaria 7 Service Pack 15 and Mobile Secure 1606, the process for notification queueing has been improved and better performance and response time are expected especially in large iOS deployments.

Introduction

There are different types of notification including ‘apply policies’, ‘unlock’, ‘remove control’ and ‘wipe device’ but all of them follow the same steps. In fact, preparing a notification means populating the MDM queue, and building the notification payload/message. In particular:

  • Each notification is stored in the MDM queue, i.e. A_IPHONE_MDM_QUEUE table in the Afaria database;
  • Each notification triggers the Apple notification process (sending a payload to Apple) that is identical regardless of the notification type.

Afaria sends two types of messages/payloads to Apple

  • MDM that is forcing the device to connect to the Afaria server and empty the MDM queue;
  • APS that is used for application badging (for example, when an application sends a notification while closed, the user is notified by a red badge on the application icon. As soon as the user open that application, all badges are cleared). In this case, nothing is stored in the Afaria database but all information are in the payload.

.

Afaria processes and database tables involved

 

There are two Afaria processes, XsOutboundServer and XsNotifyClient, that are responsible for the notification process. When a notification request for x number of devices is received (for example, when a user executes ‘Apply Policies’ for x number of devices), the MDM queue is populated and soon after the notification payload for N number of devices is built concurrently using threads (we can think about an APNS queue being created for notifications). All information necessary to send the notification and ‘talk’ to Apple include certificate thumbprint, client/tenant information and actual payload. XsOutboundServer.exe and XsNotifyClient.exe do not send any notification to Apple.

XsQueue.APNS is the process in charge of sending notifications to Apple. There is a process on each Afaria server in the farm and when it detects a notification payload in the queue, it sends it to Apple.
We can expect a latency in this process based on the polling rate configuration. In addition, throttling is active either across the farm (all servers) or per farm server based on configuration.
If a notification fails, it is put temporarily in a ‘retry’ queue (A_Q_APNS_RETRY or A_Q_APNS_PRIORITY_RETRY database table) via a stored procedure called by XsQueue.APNS until it is moved back to the original queue (A_Q_APNS or A_Q_APNS_PRIORITY database table) for normal processing (new attempt to notify Apple). This process ends after a number of retries but it is configurable. All basic configuration data (number of retries, retry interval, polling interval, throttling and so on) for each queue type are store in the A_Q_TYPE table. Specifically for Apple APNS, there are two queue types: APNS (administrator initiated actions including apply policies) and APNS_PRIORITY. These values are stored in the A_Q_TYPE.Name column. APNS_PRIORITY type is used for user initiated actions: if a user wants to install an application deployed using MDM, this request is stored in the priority queue so that it does not need to wait for other requests that are already in the APNS queue and have to be processed.
The only difference between the two APNS queue types is throttling settings that by default is 50 per minute in APNS and not throttled (0 per minute, i.e. process as soon as possible) in APNS_PRIORITY.
The A_SERVICE table stores the services (XsQueue.APNS, XsOutboundServer and XsNotifyClient) that are consumers of queues.
Another important table is A_SERVICE_Q_TYPE that defines relationship between services in A_SERVICE and queue types in A_Q_TYPE.

Settings configuration

For configuring some of the settings we have discussed so far, we use Afaria Administrator console.
In particular, throttling can be configured in Server > Configuration > Outbound Notification > Queue Throttling.
Administrator initiated actions throttling rate refers to the APNS queue type while user initiated actions throttling rate is related to APNS_PRIORITY queue type. The throttling scope checkbox is used to enable throttling per server because by default it is active for all servers in the farm. In other words, by default, 50 notifications a minute are sent across the farm and when ‘Per Server’ option is checked, 50 notifications a minute are sent to each active server in the farm (for example, if there are 2 active servers in the farm, 100 notifications a minute will be sent).



In Server > Configuration > Enrollment Server, we can specify in ‘APNS / Feeedback Configuration’ the APNS domain and port used by the Apple notification process XsQueue.APNS.  Only the System tenant configuration is valid to retrieve the Apple location. Other tenant configurations are ignored.
Both throttling and APNS settings can be changed and they will take up to a minute to become effective in the system without requiring to restart Afaria services.

XsQueue.APNS manages APNS connections. By default, when an APNS notification is sent to Apple, a connection on a particular port is open and it is specific to an Afaria server, an endpoint and a certificate. If the endpoint remains the same, a connection is opened for each unique certificate.
Connections are established on-demand and remain open up to a minute. If unused, connections will be closed. However, if Afaria server deems a connection in an error state (certificate not installed, certificate expired, authentication failure, APNS response, disconnection, destination not reachable), XsQueue.APNS is not going to attempt to re-establish the connection to Apple for a minute, by default. In parallel, the notification is moved to the retry queue.

 

  • No labels