Enable Zextras Mobile Synchronisation for a COS with Zextras Mobile

How to Make Zextras Mobile Available to Every User in a Service Class

Note on the Settings Hierarchy: User-level settings supersede COS-level settings.

Zextras Mobile for a Single User to be Enabled

When you enable the Zextras Mobile Module for a single user, you give them permission to utilise all of the mobile features of the module.

How to Make Zextras Mobile Available to One User

Mobile Passwords and You: The Mobile Password Feature

Global and Delegated Admins can configure an extra password for an account to be used only for Exchange ActiveSync authentications using the mobile password feature.

Using this feature has the following key advantages:

  • Regardless of any other password policies, enforce set-and-forget secure passwords so that you won’t have to reset the password kept on all mobile devices synchronised with an account should the Zimbra password for this account change.
  • Avoid revealing the true password in the event that the device or client is accessed without authorization.

Both the account password and the mobile password will not be accepted for Webmail, POP3, IMAP, or SMTP logins.

How to Create a Mobile Mailbox Password

The Zextras Auth module manages mobile passwords; further details are available in the section Create New Credentials: EAS.

Mobile Provisioning, also known as Mobile Device Management

What is management of mobile devices?

Mobile Device Management (MDM; also known as provisioning) enables an administrator to specify a set of rules and security settings that are applied Over The Air to one or more mobile devices. These settings can include one-time commands like the remote wiping of the entire device as well as PIN policies, Allowed/Blocked app lists, and remote app approval or disapproval lists.

In order to prevent unsafe or incorrect behaviours, MDM effectively enables administrators to control and restrict the usage of corporate mobile devices.

MDM is also an invaluable tool for BYOD corporate policy, enabling individuals to connect their own mobile devices to the company servers while drastically lowering the chance of security breaches.

Available Provisioning Features on Your Client

Not all clients provide all provisioning functions. For more information on the MDM features that the device itself supports, please consult the manufacturer of your device and internet resources.

MDM and the Zextras Suite

Through the Exchange ActiveSync protocol version 14+, Zextras Suite offers sophisticated MDM functionalities.

At the COS and mailbox levels, mobile policies may be configured, enabling both a simple “one for all” setup and user-based customised administration. Mobile Management Options are accessible in both situations from the Mobile tab.

Provisioning Alternatives

There are several provisioning choices available, including:

  • Enable Mobile Device Management: Switch the current user’s or COS’s use of mobile policies on or off.
  • Allow synchronisation of non-provisionable devices: Permit synchronisation of non-provisionable devices.
  • Permit device enforcement of policies in part: Permit any device that doesn’t support one or more applicable rules to be synchronised by the user.

Enforceable Regulations

The following kinds of Enforceable Policies are provided immediately beneath the list of Mobile Devices:

  • Set the synchronisation spans and limitations in the sync settings.
  • Configure your device’s settings to enable or disable functions like the camera, WiFi, external storage, and Bluetooth.
  • Force an unlock code and specify the code’s minimal criteria in the device’s security settings.
  • Configure the device’s programmes, including the browser, the POP/IMAP client, and unsigned apps, by turning them on or off.

Additionally, two lists are offered for managing application whitelists and blacklists:

Application approvals

a list of accepted applications that may be customised.

Application Blocks

a list of prohibited apps that may be customised and which won’t work on the device.

Cell Phone Password

Despite having a theoretically similar design, the mobile password function is independent of mobile device management and works with all EAS protocol versions.

Zextras Mobile with the SyncState by SyncStates
  • A collection of data concerning the synchronisation with a mobile device is retained on the server and is known as the SyncState (short for Synchronisation Status). Each time a device connects to Zextras Mobile, the following processes happen:
  • To synchronise the local Folders with those on the server, the device requests a folderSync operation.
  • If this is the first time the device and server have connected, a single SyncKey with the value ‘0’ is delivered instead of one for each local folder.
  • In response, the server provides a list of accessible directories.
  •  The server sends one SyncKey per folder.
  • To synchronise all due items, the device sends an itemSync operation request.
  •  The synchronised objects are kept on the server in the SyncState.
  • The device sends a ‘ping’ command to maintain the connection after finishing the itemSync operation.
  •  As long as the synced account is unchanged, step 4 is repeated.

The device terminates the current connection (the one kept alive by the ping command) every time a new item is added to the mailbox or an existing item is updated. This process is repeated steps 3 and 4 each time.

The itemIDs saved in step 3 and the SyncKeys saved in step 2 are combined to form the SyncState. According to the userID/deviceID unique pair, the server saves it.

Request for Sync

The actual synchronisation procedure, called a Sync Request, is begun either by Zextras Mobile or by the client. Any changes made to the mailbox since the last request are synced to the device during a sync request, and vice versa.

  • When: A sync request is sent.
  •  The SyncState is modified.
  • Client-side forcing causes a sync.

The device sends a fresh ping once the existing one expires (the client specifies the keepalive duration).

Managing the Zextras Mobile DoS Filter, Advanced Settings, and SyncStates

A specific DoS Filter component is part of Zextras Mobile, which boosts security and stability. When a device consistently connects at a rate higher than the selected limit, the filter will engage and “jail” the device for a certain amount of time, blocking any connections from it.

By restricting clients who are making too many requests owing to defects or malfunctions, this increases stability and security by preventing Denial of Service attacks and freeing up resources for all other customers.


The following characteristics are used to fully setup the Mobile DoS Filter through CLI:

  • mobileAntiDosServiceThe Mobile DoS Filter service is now enabled. standard false;
  • MobileAntiDosServiceJailDuration: The length of the synchronisation “jail” in milliseconds. Standard 600000;
  • Time window used by mobileAntiDosService to compute the connection ratio. If a device submits additional mobileAntiDosServiceMaxRequests requests during this time interval, the prison is activated. Standard 30000 ms;
  • Maximum requests received during mobileAntiDosServiceTimeWindow milliseconds are specified by mobileAntiDosServiceMaxRequests. Standard 150;

With zxsuite config global set|get|clear, all attributes are set globally. The zxsuite config info attribute [propertyname] may be used to access specific information for each property.

Using the Mobile DoS Filter

The system retains the timestamp of the most recent mobileAntiDosMaxRequests requests in memory while the anti-dos service is active and mobileAntiDosMaxRequests is higher than 0. All new requests from this device/account are rejected for mobileAntiDosJailDuration milliseconds if the maximum number of request timestamps have been saved and all of the stored requests are within the time window.

A warning is added to server alerts and an email is sent to the administrator when the rate has been exceeded.

Autodiscover Zextras

Zextras Autodiscover is the Autodiscover protocol’s Zextras implementation, allowing mail clients to automatically specify the proper server parameters without the need for explicit configuration. This feature is incredibly practical and safe because it requires an SSL trustworthy certificate to function.

Enabling Zextras Autodiscover: How to Do It

On each mailstore server, you must make the following changes to the jetty template configuration file located at /opt/zimbra/jetty/etc/jetty.xml.in in order to enable Zextras Autodiscover.

If you use a mobile password, you must make this modification.

With the following command, you can simply alter these settings:

Mobile Performance Tuning by Zextras

Zextras Mobile offers three practical alternatives to customise it in accordance with system performance.

Latency of Notifications

ZxMobile_NotificationsThe number of seconds that pass between an event occurring on the server and a mobile device receiving a notification is known as latency.

Utilise immediate notifications

Instant notifications can be enabled or disabled using ZxMobile_UseInstantNotifications. It also supersedes Notifications Latency if it is true.

Ping Max Heartbeat

The maximum time between ping commands is specified by the ZxMobile_MaxPingHeartbeat constant.

The zxsuite config command in the CLI or the Administration Zimlet both allow editing of every setting.

When Should Performance Tuning Settings Be Edited?

For most instances, the default settings ought to be ideal. Please implement the appropriate remedy if you encounter any of the problems listed below.

Shared Folders, You (and Your Mobile), and Shared Folders

It is possible to sync folders that are not owned by the user themselves to mobile devices using Zextras Suite. You may sync any shared email folder, address book, calendar, or task list to mobile devices because this is true for all item types supported by the Exchange ActiveSync protocol.

Depending on the client being used, certain functionalities that are available on mobile devices may vary.

Syncing a Shared Folder with Your Mobile Devices

Users may pick which shared folders should sync with their mobile devices to provide them more control over the synchronisation process.

A Shared Folder’s Mobile Synchronisation Can Be Enabled

To make a shared folder mobile synchronization-capable:

  • Open the Zimbra Web Client and log in.
  • Right-click the shared folder to sync it.
  • In the drop-down option, choose Folder Sync Settings.
  • Put a tick in the box. Check the box to allow synchronisation for this folder.
  • Input OK.

Any mobile device linked to the account will receive a synchronisation of the new folder.

A Shared Folder’s Mobile Synchronisation Can Be Disabled

Excluding a shared folder from mobile device synchronisation

  • Open the Zimbra Web Client and log in.
  • Right-click the shared folder to sync it.
  • In the drop-down option, choose Folder Sync Settings.
  • Uncheck the box. Check the box to allow synchronisation for this folder.
  • Input OK.


The synchronisation of shared folders is subject to the following limitations:

  • A mountpoint referring to a whole account share cannot be synced.
  • A shared folder’s subfolder cannot be synced since doing so would result in an incomplete folder tree.
  • A read-only share cannot be synchronised because the Exchange ActiveSync protocol does not support the idea of read-only resources. There will be numerous errors and severe discrepancies between the client and the server if a read-only folder is synchronised.

Filters for EAS

The protocol version used for synchronisation in the EAS protocol is set at the initial handshake and is never altered. The client selects a protocol version from a list of all accessible versions presented by the server.

To guarantee that the correct version is utilised, EAS filters can be used to restrict the EAS version that is accessible to a certain group of users or clients.

The getAllEASFilters and doMoveEASFilter commands are described in the section below titled “Managing EAS Filters.” Multiple EAS filters may be configured and will be examined in a sequential manner.

A description of an EAS filter

There are 5 components to an EAS filter:

The kind of the filter rule is defined by type.


the filtering identity, such as an email address or a brand of equipment.


determines whether the programme will present a fixed list or limit the versions that are accessible.

field easversions

contains the protocol versions that the filter has enforced.

Whether further filters are used after the present one has successfully matched is determined by the blocking Boolean value.

Taking care of EAS filters

The four specific commands listed below are used to manage EAS filters using the CLI.

Loggers for mobile accounts
Mobile account loggers are specialised loggers that have a different verbosity than the sync.log and may output all of a user’s EAS logs into a specific logfile. This makes troubleshooting possible more quickly.
The following conditions must be followed while establishing an account logger:
  • the intended customer.
  • The log’s verbosity level, or log_level.
  • a certain log_file.
  • While the logger is active, the window_size should be enforced across all devices synchronising with the account.
Account Logger Management The following commands are the only ones that may be used to manage account loggers through the CLI:
Device control ABQ – Allow/Block/Quarantine service
Mobile devices connected to the server can have their access controlled specifically using the “Allow/Block/Quarantine” option. As a “pre-emptive” security measure, it responds to the first connection to the server and is designed to make sure that only authorised devices may complete synchronisation with the server. A complete administrator is now able to monitor every mobile device connected to their network. Only CLI tools are available for now.
The global Boolean property abq_enabled_at_startup determines whether ABQ and the Zextras Suite will launch simultaneously. Although the property is set to true by default, it is advised to change it to false if it isn’t being utilised to conserve server resources.
Run the following command, then restart mailboxd, to disable the ABQ:
The result of zxsuite mobile getServices should show that ABQ is not operating (i.e., the value for ABQ’s running property should be false) in order to confirm that it has been disabled.
There are three basic logical parts that make up the ABQ feature:
  • Unified Device Control List
  •  authorising engine
  • the CLI toolset
as Permitted.
In an ABQ-enabled environment, whenever an administrator changes a device’s status, the device will be forced to re-sync folders with the server depending on the issued state, causing an immediate re-route to either a Dummy data that will explain what has happened to the user, or to the real mailbox to perform the re-sync.
Modes ABQ
Every time a mobile device tries to synchronise with the server, the ABQ function is activated. It may be configured to one of four potential modes: “Permissive,” “Interactive,” “Strict,” or “Disabled.” This characteristic applies to every cluster and is global.
Since the Authorization Engine is not running, the synchronisation will proceed once the user has been authenticated and has had their account status checked for security reasons. Specific devices can still be restricted, but unblocked devices will always be able to sync.
The Device Control system will verify the “Device ID” given by the device against the list of permitted devices after authenticating the user and confirming their account status for security reasons:
  • The synchronisation will proceed if the device/user couple is in the list of “allowed” devices.
  • The synchronisation will proceed even if the device/user couple is not in the device list but the device is on the list of “allowed” devices.
  • The synchronisation will be halted, a fake email informing the user of the device’s “Quarantine” status will be sent, and the connection will be set to “Quarantine” status if the device is not in the “allowed” list.
Administrators can get emails informing them solely of newly quarantined devices at predetermined intervals. Using the relevant CLI tools, they will then be able to approve or disapprove the synchronisation for each device.
The Device Control system will verify the “Device ID” given by the device against the list of permitted devices after authenticating the user and confirming their account status for security reasons:
  • The synchronisation will proceed if the device/user pair or the device alone is in the “allowed” list.
  • A fake email advising the user of the device’s “Blocked” status will be sent if the device is not on the “allowed” list, putting the synchronisation in the “Blocked” state and preventing any data from being synchronised.
No checks are run, no policies are enforced, and ABQ is deactivated.
Mode Control for ABQ
The following command should be used to check the mode:
The following command can be used to switch the ABQ mode:
False data
The function uses “Dummy emails” and a “Dummy mailbox” to keep devices in place while they wait for authorisation (Interactive Mode) or to warn them that they are “Blocked” (Permissive Mode, Interactive Mode, and Strict Mode).
While this is in the Quarantine or Block status, a virtual mailbox called the Dummy Mailbox, which only has a “Inbox” folder, will be synchronised to the device. Dummy Emails are pre-written email messages that are synced to a device in quarantine or block status to warn the user. These messages are not now localizable but will be in the future. The sync state of a device is reset each time its ABQ status is altered.
This was created to ensure that the user is aware of what is occurring because the alternative was to force the synchronisation to fail without providing the user with a descriptive answer, which would almost certainly result in a huge increase in support calls.
ABQ-specific emails
Using the zxsuite mobile setABQMessage message command, simulated emails may be quarantined and blocked; messages can be tailored at the global or domain level, and different languages can be set.
Email notifications about quarantined devices can be sent to administrators at predetermined intervals determined by the abqNotificationsInterval configuration property, which is represented in milliseconds:
The following command may be used to check the interval:
The following command can be used to modify the interval:
The abqNotificationsInterval is set to 0 by default, which means that no notifications will be sent.
Service Status for ABQ
The following command may be used to verify the status of the ABQ service:
Using the Mobile module’s default service control, the service may be started or stopped:
Devices are always permitted to sync while the mode is Disabled, which prevents the ABQ service from starting automatically.
Three Rule commands (deleteRule, listRules, and setRule) are part of the ABQ’s own set of CLI commands. With the exception of accepting regular expressions that adhere to the Java regex patterns standard (ERE with doubled backslashes), they have the same syntax as their equivalent delete, list, and set commands.
allow A particular command for a device in quarantine that changes the device’s status to Allowed.
A particular command for quarantined devices that changes the status of the device to Blocked.
Delete everything.Rule
Add or remove a device from each list.
This command imports a list of device ids from a file and always needs two inputs: the “status” that the imported device(s) should be set to and an input file containing a list of device ids separated by newlines.
Given the content of the file /tmp/list:
although device SAMSUNG1239862958 can only synchronise the user@example.com account, permits devices Androidc133785981 and Androidc1024711770 to sync completely regardless of the account.
the two listsRules
List the ABQ status of all devices. Only devices with that particular state will be displayed in the list thanks to the “status” argument’s filtering.
Typical output
both setsRule
For each single device (known or unknown), set any status.
Set the time between notifications for newly quarantined devices.
Mobile CLI for Zextras
The index of all zxsuite mobile commands may be found in this section. ZxMobile CLI Commands has a section dedicated to it called Full Reference.
ABQ block ABQ block ABQ block ABQ block ABQ blockimport ABQ list into the ruleABQ rules ABQ rulesNotificationPeriod ABQ setAddressBook add domain Add global AddressBook list domain Add global AddressBook remove domain Remove global Deletedomain deleteABQMessage global doAddAccountLogger doAddEASFilter doDeleteEASFilter doMoveEASFilter doRemoveDevice doRemoveLogger doRestartService doResumeDeviceSync doSimulateSync doResetAccount doResetDevice  doSuspendDeviceSync doStartService doStopService  getABQMessage domain getABQMessage global getAccountLoggers duplicateABQMessage domain getABQMessage global  Obtain All Devices and EAS Filters  getDeviceList and getDeviceInfo  Obtain Property Obtain Provisioning  getServices  beginABQMessage setbeginningABQMessage domainbeginningABQMessage globalProperty setSharedFolderSync setProvisioning

Leave a Reply

Your email address will not be published. Required fields are marked *