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 a cases where 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.
For example, let's
say you want to define the following three compliance policies in your
organization by using Device Manager Automated Actions:
Setting the Order of Deployment Packages
deploys packages to target devices. When you create your Automate Action
compliance policies, you need to name your policies in a very specific way, so
that they are run in the correct order.
deploys packages according to their name, deploying those packages 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
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 tracks the
devices and sets 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 the 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
disables 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
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.
Order of Compliance Packages
Your last step 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 Automate
Actions. You follow the same principles in naming that you use for Automated
Actions. When you use this naming conventions, you can make sure that the
packages deploy in the same order as the Automated Actions.