- What's new
- System requirements
- Onboarding and resource setup
- About XenMobile Service
Certificates and authentication
- NetScaler Gateway and XenMobile
- Domain or domain plus security token authentication
- Client certificate or certificate plus domain authentication
- PKI entities
- Credential providers
- APNs certificates
- SAML for single sign-on with ShareFile
- Single sign in with Azure Active Directory
- Derived credentials for iOS
- User accounts, roles, and enrollment
- ActiveSync Gateway
- Android for Work
- Bulk enrollment of Apple devices
- Bulk enrollment of Windows devices
- Client properties
- Deploy devices through Apple DEP
- Device enrollment limit
- Enroll devices
- Firebase Cloud Messaging
- Google Play credentials
- Integrate with Apple Education features
- Network Access Control
- Samsung KNOX
- Security actions
- Shared devices
- Workspace hub device management
- XenMobile Autodiscovery Service
- AirPlay mirroring device policy
- AirPrint device policy
- Android for Work app restriction policy
- Android for Work app permissions
- APN device policy
- App access device policy
- App attributes device policy
- App configuration device policy
- App inventory device policy
- Application Guard device policy
- App lock device policy
- App network usage device policy
- Apps notifications device policy
- App restrictions device policy
- App tunneling device policy
- App uninstall device policy
- App uninstall restrictions device policy
- BitLocker device policy
- Browser device policy
- Calendar (CalDav) device policy
- Cellular device policy
- Connection scheduling device policy
- Contacts (CardDAV) device policy
- Control OS Updates device policy
- Copy Apps to Samsung Container device policy
- Credentials device policy
- Custom XML device policy
- Defender device policy
- Device Guard device policy
- Device Health Attestation device policy
- Device name device policy
- Education Configuration device policy
- Enterprise Hub device policy
- Exchange device policy
- Files device policy
- FileVault device policy
- Firewall device policy
- Font device policy
- Home screen layout device policy
- Import Device Configuration device policy
- Import iOS & macOS Profile device policy
- Kiosk device policy
- Launcher configuration device policy for Android
- LDAP device policy
- Location device policy
- Lock screen message device policy
- Mail device policy
- Managed bookmarks device policy
- Managed domains device policy
- Maps device policy
- Maximum resident users device policy
- MDM options device policy
- Office device policy
- Organization information device policy
- Passcode device policy
- Passcode lock grace period device policy
- Personal hotspot device policy
- Power management device policy
- Profile Removal device policy
- Provisioning profile device policy
- Provisioning profile removal device policy
- Proxy device policy
- Restrictions device policy
- Roaming device policy
- Samsung MDM license key device policy
- SCEP device policy
- Siri and dictation policies
- SSO account device policy
- Storage encryption device policy
- Store device policy
- Subscribed calendars device policy
- Terms and conditions device policy
- VPN device policy
- Wallpaper device policy
- Web content filter device policy
- Webclip device policy
- WiFi device policy
- Windows Agent device policy
- Windows Hello for Business device policy
- Windows Information Protection device policy
- XenMobile options device policy
- XenMobile uninstall device policy
- Deprecated device policies
- Add apps
- Add media
- Deploy resources
- Automated actions
- Monitor and support
- REST APIs
- XenMobile Mail Manager 10.x
- XenMobile NetScaler Connector
- Management modes
- Device requirements
- Security and user experience
- User communities
- Email strategy
- XenMobile integration
- Integrating with NetScaler Gateway and NetScaler
- SSO and proxy considerations for MDX Apps
- Server properties
- Device and app policies
- User enrollment options
- Tuning XenMobile operations
- App provisioning and deprovisioning
- Dashboard-based operations
- Role-Based Access Control and XenMobile support model
- Systems monitoring
- Citrix support process
- Sending group enrollment invitations in XenMobile
- Configuring certificate-based authentication with EWS for Secure Mail push notifications
- Configuring an on-premises Device Health Attestation server
- XenMobile deployment
You create automated actions in XenMobile to program a reaction to events, user or device properties, or the existence of apps on user devices. When you create an automated action, the triggers defined for the action determine what happens on the user device when it is connected to XenMobile. When an event is triggered, you can send a notification to the user to correct an issue before more serious action is taken.
For example, suppose that you want to detect an app that you previously blacklisted (for example, “Words with Friends”). You can specify a trigger that sets the user device out of compliance when “Words with Friends” is detected on the device. The action then notifies users that they must remove the app to bring their device back into compliance. You can also set a time limit for how long to wait for users to comply. After that time limit, a defined action occurs, such as selectively wiping the device.
In cases in which a user device is put into an out of compliance state, and then the user fixes the device: You must configure a policy to deploy a package that resets the device into a compliant state.
The effects that you set to happen automatically range from the following:
- Fully or selectively wiping the device.
- Setting the device to out of compliance.
- Revoking the device.
- Sending a notification to the user to correct an issue before more severe action is taken.
This article explains how to add, edit, and filter automated actions, and how to configure app lock and app wipe actions for MAM-only mode.
Before you can notify users, you must configure notification servers in the XenMobile settings for SMTP and SMS so that XenMobile can send the messages. For information, see Notifications. Also, set up any notification templates you plan to use before proceeding. For details, see Create and update notification templates.
From the XenMobile console, click Configure > Actions. The Actions page appears.
On the Actions page, do one of the following:
- Click Add to add an action.
- Select an existing action to edit or delete. Click the option you want to use.
The Action Information page appears.
On the Action Information page, enter or modify the following information:
- Name: Type a name to identify the action. This field is required.
- Description: Describe what the action is meant to do.
Click Next. The Action details page appears.
The following example shows how to set up an Event trigger. If you select a different trigger, the resulting options differ from those shown here.
On the Action details page, enter or modify the following information:
In the Trigger list, click the event trigger type for this action. The meaning of each trigger is as follows:
- Event: Reacts to a predefined event.
- Device property: Checks for a device attribute on the device gathered in MDM mode and reacts to it. For more information, see the Device property names and values PDF.
- User property: Reacts to a user attribute, usually from Active Directory.
- Installed app name: Reacts to an app being installed. Doesn’t apply to MAM-only mode. Requires the app inventory policy to be enabled on the device. The app inventory policy is enabled on all platforms by default. For details, see App inventory device policy.
In the next list, click the response to the trigger.
In the Action list, click the action to be performed when the trigger criterion is met. Except for Send notification, you choose a time frame in which users can resolve the issue that caused the trigger. If the issue isn’t resolved within that time frame, the selected action is taken. For a definition of the actions, see Security actions.
If you pick Send notification, use the following steps to send a notification action.
In the next list, select the template to use for the notification. Notification templates relevant to the selected event appear, unless a template doesn’t yet exist for the notification type. In that case, you are prompted to configure a template with the message: No template for this event type. Create template using Notification Template in Settings.
Before you can notify users, you must have configured notification servers in Settings for SMTP and SMS so that XenMobile can send the messages, see Notifications. Also, set up any notification templates you plan to use before proceeding. For details on setting up notification templates, see Create and update notification templates.
After you select the template, you can preview the notification by clicking Preview notification message.
In the following fields, set the delay in days, hours, or minutes before performing the action. Set the interval at which the action repeats until the user addresses the triggering issue.
In Summary, verify that you created the automated action as you intended.
After you configure the action details, you can configure deployment rules for each platform individually. To do so, complete step 13 for each platform you choose.
Configure deployment rules. For general information about configuring deployment rules, see Deploy resources.
For this example:
- Device ownership must be BYOD.
- Device local encryption must be True.
- Device must be passcode compliant.
- Device mobile country code cannot be only Andorra.
When you are done configuring the platform deployment rules for the action, click Next. The Actions assignment page appears, where you assign the action to a delivery group or groups. This step is optional.
Next to Choose delivery groups, type to find a delivery group or select groups in the list. The groups you select appear Delivery groups to receive app assignment list.
Expand Deployment Schedule and then configure the following settings:
Next to Deploy, click ON to schedule deployment or click OFF to prevent deployment. The default option is ON. If you choose OFF, no other options are required.
Next to Deployment schedule, click Now or Later. The default option is Now.
If you click Later, click the calendar icon and then select the date and time for deployment.
Next to Deployment condition, click On every connection or click Only when previous deployment has failed. The default option is On every connection.
Next to Deploy for always-on connection, click ON or OFF. The default option is OFF.
This option applies when you have configured the scheduling background deployment key in Settings > Server Properties. The always-on option is not available for iOS devices.
The deployment schedule you configure is the same for all platforms. Any changes you make apply to all platforms, except for Deploy for always on connection, which does not apply to iOS.
Click Next. The Summary page appears, where you can verify the action configuration.
Click Save to save the action.
You can wipe or lock apps on a device in response to all four categories of triggers listed in the XenMobile console: event, device property, user property, and installed app name.
To configure automatic app wipe or app lock
In the XenMobile console, click Configure > Actions.
On the Actions page, click Add.
On the Action Information page, enter a name for the action and an optional description.
On the Action Details page, select the trigger you want.
In Action, select an action.
For this step, keep the following conditions in mind:
When the trigger type is Event and the value is not Active Directory disabled user, the App wipe and App lock actions don’t appear.
When the trigger type is Device property and the value is MDM lost mode enabled, the following actions don’t appear:
- Selectively wipe the device
- Completely wipe the device
- Revoke the device
For each option, a 1 hour delay is automatically set, but you can select the delay period in minutes, hours or days. The intent of the delay is to give users time to fix an issue before the action occurs. For more information about the App wipe and App lock actions, see Security actions.
If you set the trigger to event, the repeat interval is automatically a minimum of 1 hour. The device must carry out a refresh of the policies to synchronize with the server for the notification to come in. Typically, a device synchronizes with the server when users sign on or manually refresh their policies through Secure Hub.
An extra delay of approximately 1 hour may occur before any action is carried out, to allow the Active Directory database to synchronize with XenMobile.
Configure deployment rules and then click Next.
Configure delivery group assignments and a deployment schedule and then click Next.
To check app lock or app wipe status
Go to Manage > Devices, click a device, and then click Show more.
Scroll to Device App Wipe and Device App Lock.
After a device gets wiped, the user is prompted to enter a PIN code. If the user forgets the code, you can look it up in the Device Details.