Product Documentation

Configuring Automated Actions

Mar 13, 2014

With Automated Actions, you can configure Device Manager to perform actions based on user or device properties, events, or the existence of applications on devices.

For example, you can configure the following Automated Actions:

  • You can automatically notify users whose iOS or Android devices are jailbroken or rooted that they are in violation of company policy and that the device will be selectively wiped if the device is not brought into compliance.
  • You can automatically enforce a geo-fencing policy, whereby if a user's device leaves a defined geographical perimeter, the device is blocked from accessing your organization's email, is selectively wiped, or is revoked.
  • You can alert users automatically when mobile devices are roaming domestically or internationally and that they may be charged extra for the service.
  • You can wipe a user's device automatically when the user leaves the company, and can disable the user's Active Directory account, so that the user can no longer access your organization's data.
  • You can place a user's device into an Out Of Compliance state automatically if the user installs a blacklisted app, and you can send the user a notification informing them that they have broken the organization's mobile app policy.
Note: Before you can use Automated Actions to send automated notifications, make sure you have configured notification servers for SMTP and SMS so that Device Manager can send the message. For details, see Configuring SMTP Notification Server and Configure SMS Notification Gateway.

How Automated Actions Work

You can configure Automated Actions in Device Manager to trigger an event when a user device is out of compliance. You configure the following settings when you configure Automated Actions:

  • Trigger. The state that must exist to cause the event.
  • Condition. The setting that defines the trigger explicitly.
  • Action. The result that occurs if the trigger conditions are met.
  • Options. The ability to delay an action to notify users of the policy violation and allow time for users to remedy the condition.

Before you start using Automated Actions, consider the following:

  • If devices are shared between two users and you want to reenroll the device to the second user, make sure that you delete the device entry from the Device Manager Devices tab before enrolling the second user.
  • Automated Actions are only triggered when a device connects to Device Manager. For example, a notification is not sent to a device until the device attempts a connection back to the server, Likewise, if any of the managed devices are currently blocked by Secure Mobile Gateway, notifications are not sent to those devices until users initiate an Active Sync activity, such as receiving email or if the device synchronizes with Exchange.
  • You can deploy Automated Actions to anonymous devices if you deploy the package to unauthenticated users. You cannot perform Notify (SMTP/SMS) Automated Actions on unauthenticated users.
  • The only Automated Actions you can perform on unmanaged devices - that is, on devices that are revoked, have been selectively wiped, or are not enrolled - are the Notification and Set as Out Of Compliance actions.
  • The Out Of Compliance action keeps a device in that state until another action explicitly changes the state of the Out of Compliance property.
  • You cannot set the Secure Mobile Gateway block notification on a device that is not enrolled.
  • If you are using an Automated Action to detect when users disable their location servers on an iOS device and you want to send a notification, wipe, or revoke the device, you must enable Report if location services are disabled when you configure an iOS geo-tracking policy. For details, see To configure an iOS geo-tracking policy.
  • If you want to create an Automated Action based upon a user whose Active Directory account is disabled, you can use the Event Trigger named 'AD Disabled User'.
  • If you create custom notification templates of the following type - Out of Compliance and AD Disabled User - you cannot select the templates when you configure an Automated Notification.
  • There is a default one-hour waiting period for event-based triggers. Recurring notifications may be delayed due to the original event that causes the notification to be sent. For example, you configure Device Manager to send a recurring notification every hour, but users do not receive the notifications. The reason for the delay is due to the fact that recurring notifications are not sent until the configured trigger occurs again after the Repeated Wait time expires.

Choosing Automated Actions Trigger Types

Triggers are the states, events, or properties that cause an automated action to occur. There are four categories of triggers: Device Property, User Property, Applications, Event. Each trigger can contain multiple types.

The following table provides a few examples of triggers and trigger events.

Trigger Examples
Device Property Device properties you can use as triggers for automated actions:
  • Jailbroken or Rooted. If users jailbreak their device, you can set an action to notify the user and if the user does not undo the jailbreak in a given amount of time, selectively wipe the device.
  • Out Of Compliance. If a device is put into a state of being out of compliance, you can block that device from the SMG (and thus corporate email) and notify the user.
  • Passcode compliant. If this trigger's condition is false, then you can set the device to Out Of Compliance or selectively wipe the device.
  • Perimeter Breach. If the device leaves the geo-perimeter as defined in an iOS geo-fencing policy, this condition can be set and used to notify the user, wipe the device, and so on.
User Property User properties you can use as triggers for automated actions:
  • Active Directory failed login attempts. If an Active Directory user attempts to log in more times that allowed, you can notify the user that they will have to wait a certain time period before they can try to log in again.
Applications This trigger allows you to specify whether or not an app is installed on a device, by name, and then set an appropriate action, such as notify, or set the device as out of compliance.
Event The following system events can be used as triggers in Automated Actions:
  • Secure Mobile Gateway block. A user's device has been blocked by the Secure Mobile Gateway and the device lost access to your organization's email.
  • Device unmanaged. The device lost its ability to connect to and communicate with (and thus be managed by) the Device Manager server.
  • Device jailbroken. A user broke the iOS user agreement and warranty in order to install unauthorized software.
  • Device not blacklist or whitelist app compliant. If a user's device breaks an app blacklist or whitelist policy, you can choose an action to perform.
  • Device revoked. The device has lost ability to connect to the Device Manager server.
  • Device international roaming. A user's device is roaming internationally.
  • Device domestic roaming. A user's device is roaming domestically.
  • Location perimeter breach. A user's device has gone outside of a defined perimeter.
  • Location services disabled. The location services on a user's device is disabled.
  • Active Directory disabled. If you disable a user's Active Directory account, such as when an employee leaves a company.

Types of Automated Actions

The following list details the types of actions you can configure to occur automatically based on trigger type.

  • Selective Wipe. Clears organizational data from the device while retaining personal information and selected settings. The MDM profiles and all packages pushed by Device Manager to the device are removed. The device can, however, be reenrolled at a future time.
  • Revoke. Revoking a device prohibits any further connection from the device. If the device attempts to connect to Device Manager, the MDM profile and all packages deployed to the device are removed. The device is barred from reenrollment unless it is reauthorized by an administrator.
  • Set as Out Of Compliance. The device is given a property named Out of Compliance and the property is set to True. When a device is out of compliance (has this property set to True), it appears in the Out of Compliance on the Dashboard Alerts widget.

Configuring Location Services Triggers

  1. In the Location Services - Configuration creation dialog box, select Report if location services are disabled and then click Create.
  2. In the New automated actions dialog box, do the following:
    1. In Name, type a name for the automated action.
    2. Under Trigger, in Trigger type, select Event and in Event, select Location services disabled.
  3. Click Create.

Automated Actions Example: Notifications for Blacklisted Apps

This topic is an example procedure that illustrates how you can use Device Manager Automated Actions to set up an automatic notification to inform users when they install a forbidden (also known as blacklisted) app on their device. You can manage user devices to make sure that a work device installs the approved list of apps only, and that the device does not have any forbidden apps installed.

This example shows the following tasks:

  • Configure the notification template you want to send.
  • Create an Applications Access policy to designate an iOS app named Word with Friends for Free as forbidden (blacklisted).
  • Create an Automated Action that sends a notification when a device violates a forbidden Applications Access policy.
  • Deploy the Automated Action and Applications Access policy to your device in a deployment package.
  • Install the Words with Friends for Free on your iOS device.
  • Receive the notification.

To configure a notification template

When users install a forbidden app on their device, you can send the correct notification by using a template for the message that is sent when the non-compliant blacklist or whitelist trigger is correctly configured.

By default, all notification templates are configured to use the ${user.mail} macro, which uses the email address of the device owner who receives the notification. If you want notification emails to be sent to an administrative user; for example, to notify an administrator that a device has been jailbroken, you can enter the administrator email address in the To field.

  1. In Device Manager, click Options.
  2. In the Server Options dialog box, in the left pane expand Notification Templates.
  3. In the right pane, under Notification Templates, click Non Compliant Blacklist / Whitelist.
  4. In the Edit a Notifications Template dialog box, on the Settings tab, in Channels, select the channels of communication you want to use.
  5. Click the SMTP tab and then do the following:
    1. In From, enter the name or email address from whom the notification is sent. This is not a mandatory field, however Citrix recommends adding the name or email address.
    2. In To, leave the command $({user.mail}. If you modify the To field, the email might not be sent correctly.
    3. In Message, you can modify the message except for the macros ${firstnotnull(device.TEL_NUMBER,device.serialNumber)} and ${outofcompliance.reason(whitelist_blacklist_apps_name)}. If you modify or remove the macros, the email might not be sent correctly.
  6. Click Update. When you click Update, the template is ready for the Automated Action.

Next you will create a blacklist for an app, so you can use the blacklisted app as a trigger for your Automated Action later. This example uses the Words with Friends Free app.

To create an Applications Access policy for a forbidden app

  1. In the Device Manager web console, click the Policies tab.
  2. On the left side of the console, under App Policies, Global > Applications Access Policies.
  3. Click New Applications Access Policy.
  4. In the Add a new Applications Access Policy dialog box, type Words with Friends for Free.
  5. In Access policy, click Forbidden (blacklist).
  6. In OS type, select iOS.
  7. Click New app.
  8. In the Add a new application dialog box, enter the following:
    1. In App Name, type the name of the app. For example, type Words with Friends Free.
    2. In App bundle ID, type the bundle name of the app. For example, type com.zynga.WordsWithFriendsFree.
  9. Click Create. This will create the application in the list. The app appears in the list in the Add a new application dialog box.
  10. Click Create again to create the Application Access Policy. Once created, you can add this policy to a deployment package and deploy to the devices you want to manage.

Next, you create an Automated Action that sends a notification email to users when they install a blacklisted app on their device.

To create an Automated Action

  1. In Device Manager, click the Policies tab.
  2. In the left pane, under Global, click Automated Actions and then in the right pane, click New.
  3. In the New automated action dialog box, do the following:
    1. In Name, enter Blacklist Notify.
    2. Under Trigger, in Trigger Type, select Applications and in Name, select Installed.
    3. Under Condition, in Condition, select Is and then in Value, enter WordsWithFriendsFree.
    4. Under Action, in Action, select Notify.
    5. Under Action, in Template, select Non Compliant Blacklist / Whitelist.
    6. Under Options, select Delay and then configure 10 minutes.
    7. Under Options, select Repeat wait and then configure one hour. This option allows you to delay sending the notification message in the event that there is a communication failure between the device and Device Manager.
  4. Click Create.

In the last task, you will create a deployment package that contains Automated Actions and then push that deployment to user devices.

To deploy automated action and Applications Access policy to devices

Once on your device, you install the blacklisted app to trigger both the notification message that your device is out of compliance, and to trigger the Secure Mobile Gateway block on the server.

Citrix recommends that you create separate deployment packages for your Automated Actions and deploy them separately from other packages. Additionally, make sure you configure Deploy to anonymous users in the Groups of users page of the package, to include those users who may have removed their agents, or who have had their Active Directory account disabled.

You run the Create New Package wizard to deploy packages. During the wizard, you select the following:

  • Groups to which the policy is deployed.
  • Resources that include the Automated Actions you created and the Software Inventory resource.
  1. In Device Manager, click the Deployment tab, and then click New Package > New iOS Package.
  2. In the Create New Package wizard, in the Package Name window, enter a name for the package and then click Next.
  3. In the Groups of users window, select a group you want to deploy the policy to and then click Next.
  4. In the Resources to be deployed window, under Available Resources expand the Automated Actions section and then select the two Automated Actions you previously created in the last step. Then, click the right arrow to add the resource to the deployment package.
  5. In the Available Resources list, under Applications Access Policy, select the Forbidden policy you previously created and then click the right arrow button to add it to the package. Click Next.
  6. In the Deployment schedule window, select the If not deployed Start Now option. Click Next.
  7. On the Deployment rules page, click Next.
  8. On the Package summary page, click Finish.
  9. When the wizard is complete, in Device Manager, click Deploy to deploy the packages.

When Device Manager finishes the deployment, select the deployment package, and then click the Details button to see information about the success of the package deployment. When the package shows as deployed, you can install the blacklisted app on your iOS device.

When the users targeted in the deployment install the blacklisted app on their iOS device, Words with Friends Free, users receive a notification message that the app is not allowed.

Changing Device Compliance with Automated Actions

Automated actions allow you to change the status of a device from a state of compliance to a state of non-compliance based upon specific conditions. For example, you can set an Automated Action to change a device to a state of Out Of Compliance=True if the device has been jailbroken or rooted, if the user disabled location services on the device, or if the user installs a blacklisted application.

In cases in which a user's device is put into an out of compliance state, and then the user fixes the device so that the device is in compliance, you will need to configure a policy to deploy a package that resets the device into a compliant state.

As such, the following three compliance policies are ways to change the status of the device by using Device Manager Automated Actions:

  1. Location Services Policy. This policy states that if a user disables location services on their device, the Automated Action should set the Out of Compliance device property to True.
  2. Blacklisted App Policy. This policy states that if a user installs a blacklisted app on their device, the Automated Action should set the Out of Compliance device property to True.
  3. Jailbreak Policy. This policy states that if a user jailbreaks the device, the Automated Action should set the Out of Compliance device property to True.

Naming and Setting the Order of Deployment Packages

Device Manager deploys packages to target devices. When you create Automated Action compliance policies, you need to name your policies in a very specific way, so that they are run in the correct order.

Device Manager deploys packages according to their name, in an alphanumeric order. Thus, you want to make sure that you deploy your Compliance Reset Automated Action package first and that it does not reset any of the other Automated Action packages that are designed to track compliance device compliance.

When you name your policies, make sure that the global compliance reset policies deploy first and then deploy your Automated Action compliance deployment packages.

In the example above, you might want to create three packages to track device compliance, the Geo-fence, Blacklist, and Jailbreak polices. Automated Actions track the devices and set the devices to Out of Compliance=False when the user violates the policy. You also want to be able to reset the devices when the user brings the device back into compliance.

For example, you want to reset the device property when Device Manager detects that the device is out of compliance. You want this policy to run before any other policy. You can provide the name aaa-OOC-Reset so that it will run before the policies that can set a device out of compliance.

You can create an Automated Action by setting the device property to out of compliance if users disable location services on the device. If you want this policy to run after the reset policy, you can give the policy the name aab-location-services-disabled. You can then set the delay for a specific number of minutes so this policy runs after the compliance reset Automated Action that runs before this policy.

You can also create an Automated Action that sets the device property to out of compliance if users install a blacklisted app on their device. You can give the policy the name aac-blacklisted-app and set the delay for four minutes so it runs after the two policies preceding this one.

You can create an Automated Action to set the device property to out of compliance if users jailbreak or root their device. You can give the policy the name aad-jailbreak and set the delay to five minutes so it runs after the three policies preceding this policy.

Setting the Order of Compliance Packages

Your last step is to make sure that your compliance policies run in the correct order. To do so, create deployment packages and use the same names you used for the Automated Actions. You follow the same principles in naming that you use for Automated Actions. When you use this naming convention, you can make sure that the packages deploy in the same order as the Automated Actions.

Viewing Executed Automated Actions in Device Manager

Within the Device Manager web console, you can view all of the automated actions that have executed. To do so, click the Policies tab and then select Show Executions.

Troubleshooting Automated Actions

You can check whether or not an Automated Action notification was sent to a user in the following ways:

  • Check the deployment of the package that contained your Automated Action to make sure the package is deployed.
  • Check the Device Manager Device Event Log and see if any of the events specified in your Automated Actions have run.
  • Check the Device Manager Device Sent Notifications Log and see information about notifications, such as if notifications have been sent, which have failed, who received them, and when they were sent.