This document explains how to use Relution from an administrator’s point of view. It covers the topics Mobile App Management (MAM) and Mobile Device Management (MDM) as well as User Managemement. This document is versioned. You can find the version of this document in the bottom left corner. To get the most recent version of this document please go to latest manual.

1. App Management (MAM)

Relution Mobile App Management enables fast, secure and targeted software distribution for mobile devices, so employees can always keep their mobile software up to date as conveniently as possible – with a company-owned app store.

In this section you will find information on how to use the Enterprise App Store and keep your employees up-to-date with the newest and best apps.

Click on one of the subtopics on the left to navigate to that section.

1.1. User onboarding

Precondition: You are member of the “Administrator” or “Appstore Manager” group.

To enable a mobile user to download apps from the Relution Enterprise App Store (EAS), an administrator has to perform the following steps:

  1. Add a user to the Relution system (see Creating new users)

  2. Make sure this user has at least the “AppStore User” role (see Add users to groups)

  3. Tell the user his login credentials as well as the link to download the Relution App (see Installing the Relution app)

  4. Provide one or more apps in the Relution App Store view (see Uploading an app)

  5. You can use Relution’s powerful App Release Workflow to put apps in specific states (development, test, release, see Creating an app release workflow)

1.1.1. Installing the Relution App

There are two possibilities to install the Relution app for Android, iOS or Windows. The recommended way is to download the app from the public app store.

Alternatively, you can also make the Relution app available for download in Relution. Add the app to the Relution App Store as described in Relution Client Apps. Then, perform the following steps to install Relution on your mobile device:

  1. Open your browser and go to https://live.relution.io or to your custom server URL.

  2. Log in to the Relution App Store with the credentials you received from your administrator.

image

  1. Download the Relution app by tapping the logo shown on the dashboard.

image

  1. After the download has completed, start the installation by confirming the install popup on your device.

image

  1. After the installation has finished, open the app on your device and log in.

  2. Go to the app list. Now you can download available apps.

1.2. App Management

This chapter explaines the app management for MAM scenarios.

1.2.1. Uploading an App

Precondition: You are a member of the “Administrator” or “Appstore Manager” group.

  1. Navigate to Apps > App Store and press the Add button in the left-hand menu.

image

  1. Select the type of app you want to add and press Next.

    • Choose Native app to upload an .ipa (iOS app), .apk (Android app) or *.appx (Windows app) file. Select the file via the file chooser or by using drag & drop.

    • Choose Weblink for adding a link to a custom URL.

    • Choose Google Play Store app, Apple App Store app or Windows Store app for adding an app from one of the public app stores.

image image

  1. Type in additional information for the application like a description, changelog and release status. For native apps, Relution automatically gets some of the required information from the binary like the app’s name, type and version.

image

  1. After having entered all information, press the Save button on the top right corner and your app appears in the app catalog.

The app details page contains general information about the app and all uploaded versions. Also, a History of the app is available which contains information about changes to the details or version changes. The Archive tab holds all old versions of the app which are no longer in one of the three main states.

In the Information tab,you can manage the different versions of the app. Each release state holds one version of the app.

In the Settings tab, you can manage the settings which apply to all versions of the app. Edit the Permissions to configure which groups and/or users see the app in its different release states. For example, you can add users you want to be able to see the “Review” version of the app to the “Reviewer” role.

image

1.2.2. Uploading a new app version

Precondition: You are in the group “Administrator”, “Appstore Manager” or “Device Manager”.

  1. Navigate to Apps > App Store and select the app which should receive a new version. You will be forwarded to the app’s detail page.

  2. Click the Information tab and press the Add new version button in the left-hand menu.

  3. Upload a new version of your app by selecting it via the file chooser or by using drag & drop.

image

  1. If necessary, you can edit your app version’s detail data on the upcoming page or skip this step if no changes are required.

    Please note that by default there can only be one version of an app in each status. Only the “Archive” state is capable of holding multiple app versions.

    If the status of the new app version already contains an app version, the previous version will be automatically moved to the “Archive” state.

image

  1. Press Save.

  2. The new version of your application is now visible under the tab for the configured release state.

image

1.2.3. App permissions

Precondition: You are in the group “Administrator” or “Appstore Manager”.

How to configure which groups and/or users belong to the “Owner”, “Reviewer”, “Developer” and “User” role of an app:

  1. Navigate to Apps > App Store.

  2. Select the app from the list or upload a new one via the Add button. If you upload a new app, you will be redirected to the edit page automatically.

  3. Click on the Settings tab and press the Edit button of the role you want to configure.

image

  1. Select the groups and/or users you want to assign the current role and press Ok to apply the changes.

image

The selected groups and/or users will now be shown for the role.

1.2.4. Releasing an App Version at a Specific Point in Time

The App Release Workflow contains a feature that enables you to release an app at a specific point in time. To use this feature, configure and enable the App Release Workflow in Settings : App Release Workflow and set the Go-Live date of the app version you want to release.

image

As soon as this is done, you’ll see an additional step inside the App Release Workflow of your app version pointing out that it won’t be released before the date you’ve specified.

image

Of course, you have the possibility to change the Go-Live date of app versions in state “Review” to any point in time in the future. Additionally, if the app version is assigned to the “Ready to release” workflow step, you can manually approve the “Ready to release” workflow step to release it immediately.

As soon as the date is reached and all previous workflow steps have been approved, the app version will be moved from “Review” to “Release”.

1.3. App Release Workflow

This chapter explains how to automate the App Release process.

1.3.1. Creating an App Release Workflow

The app review workflow is used to simplify the accountabilities within the approval of a new app for the Relution Enterprise App Store. Administrators can define multiple approval steps which a new app or a new version of an app must pass in order to become available in the EAS. Usually these steps define different responsibilities needed to review and then approve or reject the app based on their own set of criteria. The administrator can define a group of people or single users who are in charge of approving or rejecting a defined step within the workflow.

image

1.3.1.1. Enabling the Workflow and Creating Steps

Start creating the App Review Workflow by navigating to Settings > App Review Workflow. Enable the App Review Workflow with the On/Off switch in the upper right. Depending on the settings of the workflow (which will be explained in this section) all app uploads (new apps and/or updates) will go through this workflow before thay become available to the Relution Enterprise App Store. The review workflow feature becomes active if there is at least one step defined.

To add a new step, press the Add button in the left-hand menu. A new view will be shown to configure this step.

image

The “General” information section allows you to specify a name and a description for this step. You can also set the persons or groups that are responsible for this step. If none is set, the App Owners of the corresponding app are the responsible persons. Only responsible persons are able to approve or reject this step, causing the app to be moved to the next step (if approved) or the archive (if rejected).

Then, define the scope of apps that this step will apply to:

  • Application type: Define the types of applications which will be required to pass this step.

  • Platforms: Choose if this step is only required for applications of the Android or iOS platform, or both.

  • Price type: Specify if this step differs between paid or free applications.

  • App operations: Define if this step is required for new applications or also for updated versions.

  • For certain applications: Select specific applications for which this step is required.

Press Save to save your changes. The step is now active and can be seen in the App Review Workflow overview page. You can change the order in which the applications go through the workflow by using drag & drop to move the individual steps to the desired position.

You can now add more steps until your corporate review guidelines are mapped to the Relution review workflow.

1.3.2. Working with the App Release Workflow

Once you have configured and enabled the App Release Workflow, it will be applied to all new and updated application versions requested. Relution will check for each uploaded version if it matches the ruleset of any workflow review step (e.g. if you have uploaded a web app but your steps are configured to only apply to native applications the review workflow will not apply to the web app).

1.3.2.1. Viewing an App’s Workflow Process

To view and edit the release workflow of an application, go to the details page of the application version in “Review”. Under Release Status, you will find an overview about the necessary steps the application has to pass as configured in the App Release Workflow settings.

image

1.3.2.2. Approving or Rejecting an App Version

Prerequisites: You are logged in with an account that is able to approve or reject the current workflow step.

  • Press the Approve button to move the app to the next workflow step. This will trigger notifications to the person or group responsible for the next workflow step. If the current step is the final step, approving it will publish the app to the Relution Enterprise App Store. That makes it publicly available for all App Store users.

image

  • Press the Reject button to end the review process for this app version. This will move the version to the “Archive” state. The application itself is not deleted, as further versions or requests of the application might exist.

When approving or rejecting an application version, you can enter an optional comment which is displayed under the corresponding step. This allows your collaborators to understand which aspects you have checked, what results you’ve found and why you made that decision.

1.3.3. Releasing an App Version at a Specific Point in Time

The App Release Workflow contains a feature that enables you to release an app at a specific point in time. To use this feature, configure and enable the App Release Workflow in Settings : App Release Workflow and set the Go-Live date of the app version you want to release.

image

As soon as this is done, you’ll see an additional step inside the App Release Workflow of your app version pointing out that it won’t be released before the date you’ve specified.

image

Of course, you have the possibility to change the Go-Live date of app versions in state “Review” to any point in time in the future. Additionally, if the app version is assigned to the “Ready to release” workflow step, you can manually approve the “Ready to release” workflow step to release it immediately.

As soon as the date is reached and all previous workflow steps have been approved, the app version will be moved from “Review” to “Release”.

1.4. App Requests

The App Requests feature allows your users to make a proposal for an application which should be added to your Enterprise App Store (EAS).

The Appstore Manager can review the requests and approve or reject them. If the proposed app is approved, it is moved to “Release” state and made visible for all App Store users.

1.4.1. Requesting a New App

Apps can be requested both from the Relution app and from the administrator portal.

  1. Navigate to Apps > App Store and press the Request App button located in the menu on the left.

  2. Choose the target app store in the prompt and press Next.

  3. Search the desired app by typing its name, select it and press See Details.

image

  1. Optionally, you can provide a reason why you are requesting this app.

image

  1. Confirm your app request by pressing the Request App button. The administrator will be notified about the request and can then review the proposal.

1.4.2. Reviewing App Requests

Prerequisites: Logged in as “Administrator” or “App Store Manager”.

  1. Navigate to Apps > Requests to see all apps that users have requested.

image

  1. Select an app to view its detail page. By default, requested apps are in the “review” state and therefore are only visible to users that have the role “App Reviewer”. You can however change the permissions required to view these apps by pressing the edit button for that status on the app’s settings page.

image

  1. Click on the Requests tab to view all users who have requested the app and their comments.

image

1.4.3. Approving and Rejecting App Requests

The workflow of approving and rejecting app requests depends on the App Release Workflow feature which can be configured in Settings > App Release Workflow.

Without App Release Workflow

If the review workflow feature is disabled you can approve an app by changing the app version from “Review” to “Release”. This allows regular EAS users to see and download the application.

On the other hand, rejecting works similar. You can reject the app by moving its version from “Review” or any other state to “Archive”. This will cause all future user requests to be added to this request. You could also delete the app but this will cause future requests to recreate the entry for the rejected app.

With App Release Workflow

The App Release Workflow is a seperate feature of Relution but can be used in combination with the App Request feature. Requested apps and their version have to pass a configured review process in order to become available to the Enterprise App Store.

1.5. Development-Hub

Introduction

The Development-Hub can be used to manage the development cycle of an app. The Hub contains one or more Development Environments - one for each app under development - which consists of a Git repository and an corresponding build job on a Continuous Integration (CI) server. Changes to the repository trigger builds on the CI server and the resulting apps are automatically uploaded to the Relution store in Development release state. Once inside the store, these apps can be approved or rejected using the review workflow.

To be able to use the Development-Hub, the following requirements must be met and the Relution settings configured accordingly:

Preconditions:

  • The user account is in the “Administrator” or “Appstore Manager” group

  • At least one Repository (provider) must be configured in Relution. Relution currently supports AWS CodeCommit and GitLab as repository providers.

  • Using a continuous integration server with the Relution Development-Hub is optional. Relution currently supports GitLab and Jenkins as a CI server providers.

Prerequisites for using an AWS CodeCommit repository

An Amazon Web Service account is necessary to use AWS CodeCommit, additionally an AWS user must be created having the following policies in order to integrate it with Relution:

  • IAMFullAccess

  • AmazonCodeCommitFullAccess

  • AmazonSNSFullAccess

  • AmazonSQSFullAccess

Amazon recommends to create a group in AWS Identity and Access Management (IAM) that has the above policies attached and to add the user to this group. Please be aware that by adding the IAMFullAccess policy, a user gets permission to manage other users, including itself. This means this user account should be kept secret and not be shared throughout your organization.

If your Relution instance is not running on AWS, you have to create an Access Key for your AWS Account and provide the credentials in the Relution Development Hub settings.

Prerequisites for using a GitLab repository

  • A GitLab server must be available

  • A GitLab user with privileges to create, delete and modify settings, projects, groups and users must be available (preferably with admin rights)

Prerequisites for using GitLab CI

  • The requirements are the same as when using the GitLab repository

Prerequisites for using Jenkins CI

The AWS SQS Build Trigger Plugin ensures that Jenkins is notified when changes are pushed to a Git repository, so a build of the related Jenkins job can be started. This means AWS needs to be configured to provide an Amazon Simple Queue Service (SQS) queue the plugin can interact with.

The Environment Injector Plugin ensures that environment variables can be set inside the build job. This is required for the auto-generated build jobs to work correctly.

The Relution Enterprise Appstore Publisher plugin ensures that the built apps are uploaded to a specified Relution instance and are linked to the corresponding Development Environment.

The YML Plugin ensures that build jobs on Jenkins can be configured using YML configuration files. Relution provides these files inside the Git repository. This allows developers to configure build jobs by changing these files.

Development-Hub Settings

The Development-Hub settings allow to define multiple repository/CI providers by entering a provider name and filling in the required data, like connection credentials. These providers can be used to create environments in the Apps > Development-Hub menu. This menu item is visible to all users which are members of the Developer group. Developers can also upload their public SSH key using the user account menu item in the top right corner. This key is required to access the repository.

NOTE: The managed Development Environments with CI are using a technical user called devHubTechUser to upload build apps into Relution appstore, please do not delete or modify this user in any way.

image image

Development Environments

Users with the Reviewer permission can either link an existing app project as unmanaged Development Environment or request a new managed Development Environment.

Unmanaged Development Environments are created right away by linking an existing project from the repository and fetching its data. Optionally a CI integration can be requested, by selecting a CI provider during the linking process. Relution then creates a merge request (MR), containing YAML files, in the Git repository. After accepting the merge request, the YAML files are used to setup a build job, which enables the Continuous Integration on the server.

Managed Development Environments are created in two steps. First it needs to be request by an Reviewer. After the environment is requested, Appstore Managers will be notified via email and can approve or reject the requested Development Environment. When an environment is approved, a new repository project is created using the repository provider. Optionally, the Continuous Integration is enabled for this project using the configured CI provider. The CI is enabled in a similar way like for the unmanaged Development Environment, but without need to accept any merge request. After the environment is set up, the requesting user is notified and becomes a Development Environment owner. An owner is granted permission to manage their Development Environment, which allows them also to assign developers. To clone the Git repository, developers need to upload their public SSH key to Relution. This key is automatically added to the repository provider, which allows them to access the repository using their private SSH key. Once this is done, Relution displays the necessary information required to access the repository, which depends on the repository provider. For CodeCommit this is the repository URL, including the user’s API access key ID, and for GitLab it is the clone URL. By default, a new build on the Continuous Integration server is triggered when a developer pushes changes to the master branch. The build artifacts (apps) created by a successful build will be uploaded to Relution and are linked to the corresponding Development Environment. Uploaded apps are visible in the Relution App Store or via the Development Hub, by selecting the according Development Environment in the Relution Portal.

Relution provides YAML configuration files for the supported Continuous Integration server. With these files, which are located in the Git repository, developers are able to manage the CI build job and the installed plugins.

A requested Development Environment can also be rejected by the Appstore Managers. The requesting user will be notified via email and will no longer be able to manage the Development Environment.

It is also possible to delete a Development Environment at any time. If it is a managed environment and it has been approved, then the repository project and any files in it will be deleted. THIS DATA CANNOT BE RESTORED. Make sure to create a backup of these files before you delete an environment. Repository project data of an unmanaged environment is not affected by the environment deletion.

image

SSH public keys

App Developers have the possibility to upload their SSH public keys. If they are assigned to a Development Environment, their keys will be uploaded to the respective repository provider. This ensures that they are able to clone and access the corresponding Git repository, and push and pull code changes.

To create your own private/public key pair, follow these steps:

  • Create the keypair

    • On GNU/Linux / macOS:

      ssh-keygen -t rsa -C "MyKeyName" -b 4096

    • On Windows:

      • On Windows, you will need to download and install PuttyGen

      • In PuttyGen, create an SSH-2 RSA key with a length of 4096 bytes.

  • Copy your public key (located at ~/.ssh/id_rsa.pub) to the clipboard

  • Paste it into the Relution SSH key menu (available by clicking on your user name in the top right corner of the portal)

image

Comprehensive instruction on how to a generate private/public key-pair on a *nix systems can be found here. Instructions for Windows can be found here.

1.6. App Publishing

The App Publishing feature can be used to upload approved native apps to 3rd party servers like MDM systems or app stores . Relution currently supports Mobile-Iron, AirWatch and the Apple App Store as publishing providers.

1.6.1. Prerequisites

  • Your user account is in the “Appstore Manager” group.

1.6.2. Creating a new App Publishing target

  1. Login.

  2. Go to “Settings”, select “App Publishing” in the drop down menu and press the “Add” button.

image

  1. Fill in the form with required values, select a provider from the drop down, enter the workspace number (organization/tenant) for “Device Space” (only relevant for MobileIron as provider).

    • If publishing to AirWatch, an Organization ID is required. This can be found by logging in, and navigating to Groups & Settings > Groups > Organization Groups > Organization Group Details. At the very end of the URL will be the numerical Organization ID for your Organization Group. If all else fails, input 0.

image

  1. Press the “Save” button.

image

1.6.3. Automatically Publishing an App

  • Follow the instructions for uploading a new app in the section Uploading an app.

  1. After successfully uploading a new app, go to the “Publishing” tab on the app details page and press the “Add” button.

image

  1. In the drop down menu for a “Provider” select the provider you created earlier.

    • When using “MobileIron”, you can optionally select predefined labels by clicking on the “MobileIron Labels” button. After selecting a label, press the “Ok” button.

    • When using “AirWatch”, you can optionally select predefined smart-groups by clicking on the respective button. After selecting a group, press the “Ok” button.

image

  1. In the drop down menu for “Trigger” options, select the app state which will trigger to automatically deploy your app to the configured app provider store.

image

In the case that “Trigger” is selected as “Review” option from drop down, you must have been enabled “App Release Workflow” feature. Follow the instructions in section Creating an app release workflow to enable Workflow process.

  • Select an option from “Review step” drop down menu.

image

  1. Press the “Save” button in top right corner.

    • If you change app state to “Release”, you can see in the app history view that the publishing step was successful.

image

1.7. iOS App Signing

1.7.1. Introduction

The iOS App Signing feature can be used to “(re-)sign” existing native iOS apps (*.ipa archives) with new signing credentials while changing bundle properties conveniently from Relution. During the process, the existing code signature and properties of the app are replaced and the (re-)signed app version is uploaded back to Relution automatically.

You can configure apps so that they are automatically signed. If enabled, each new version of the app is signed automatically using a configuration defined in the Relution organization settings.

Some possible usage scenarios are:

  • Renewing an expired provisioning profile without having to build the app again

  • Signing an app created by a supplier with the organization’s own signing credentials

  • Replacing the development signature with the production signature during release of a new app version

Note: The signing feature cannot be used for public apps added from the Apple AppStore.

1.7.2. Prerequisites

For the app signing feature to be available for an app version, some prerequisites have to be fulfilled:

  1. The signing feature has to be configured system-wide by the system administrator.

  2. Signing is only available for *native iOS apps*

  3. The user has to have Developer, Reviewer or Owner permissions on the app to be signed.

If all conditions are met, the Re-sign action will be available on the app version’s details page and auto-signing can be configured on the app details page or during app creation.

A valid combination of signing credentials and properties is needed to (re-)sign an iOS app. The signing credentials can be provided as an Apple Enterprise Developer account in the Relution organization settings or provided ad-hoc as a valid combination of signing identity certificate and provisioning profile.

1.7.3. Signing Credentials

1.7.3.1. Automatic Signing

The necessary credentials for app signing can be set in the Relution Settings at Settings > App Signing. The following parameters will be necessary:

  • Platform type: Apple to add a configuration for signing iOS native apps

  • Bundle ID Pattern: This pattern defines which apps the configuration is used for. Apps which have the given bundle identifier or match the identifier using a wildcard (*) at the end will be signed. Each instance of the automatic signing configuration needs to have a unique Bundle ID pattern. When multiple patterns match an app’s bundle identifier, the most specific one, ie. the one with the longest non-wildcard pattern, will take precedence.

  • Apple ID: The Apple ID associated with an Apple Enterprise Developer account

  • Password: The password for the Apple ID. If the ID is protected with two-factor authentication, an app specific password has to be created.

  • Signing Certificate: The distribution signing certificate associated with the developer account as a PCKS 12 archive. This has to be provided as it contains the signing private key which cannot be obtained by Relution via the Apple Developer Portal.

If an automatic signing configuration is used for signing, Relution will do the following things in the given Apple Enterprise Developer Account during the signing process:

  1. Create App Identifiers necessary for signing apps if they are not present already

  2. Create Provisioning Profiles every time an app is signed to have the maximum time until expiration

  3. Create Push Certificates if possible

Important Note: Automatic signing cannot be used with standard Apple Developer accounts

1.7.3.2. Ad-hoc

The credentials can also be provided ad-hoc during signing. The following data has to be provided:

  • Signing Identity Certificate A PCKS 12 archive containing the development team’s signing identity certificate and private key

  • Signing Identity Certificate Passphrase The passphrase to decrypt the archive

  • Provisioning Profile An iOS provisioning profile (*.mobileprovision) matching the signing identity

When credentials are provided ad-hoc, Relution is not able to create app identifiers, provisioning profiles or push certificates.

1.7.4. Signing-Operations

1.7.4.1. Signing uploaded apps

When automatic app signing is enabled, each added version of any app is automatically signed when an app signing configuration with a matching Bundle ID pattern exists. The signed app is uploaded to Relution and then available as a separate app as it has a different bundle identifier

The setting can be enabled when creating a new app or on the app’s details page.

1.7.4.2. Manually signing apps via Relution Portal
  1. Navigate to the app to be signed

image

  1. Choose the app version to be signed and click on Re-sign

image

  1. Select the signing credentials to be used. The switch controls if the automatic signing settings from the organization settings should be used or if the credentials are provided ad-hoc. If properties of the app should be changed expand the section CHANGE PROPERTIES at the bottom and enter new values for the bundle properties which should be changed. Finally confirm by pressign Re-Sign.

image

  1. The app version will then be resigned in the background and an e-mail notification will be sent when the signing process has finished.

image

  1. The new app version is available in Relution. (Depends on the selection of properties, see section Consequences of signing an app version)

image

  1. The existing app version will be available under Archive unless a certain combination of properties are set. (See section Consequences of signing an app version)

image

1.7.4.3. Changing app Properties

The following properties can be changed when signing an iOS App manually

  • Bundle Id (CFBundleIdentifier): The bundle id which the signed app should be set to – has to match the App ID of the provisioning profile

  • Display Name (CFBundleDisplayName): The bundle display name which will be shown for the resigned app

  • Short Version (CFBundleShortVersionString): The desired bundle release version of the resigned app

  • Build Version (CFBundleVersion): The desired bundle build version of the resigned app

1.7.4.4. Push certificates

When an app is signed with Automatic Signing Credentials (upon upload of a new app version), or when triggered manually, a new push configuration is created if there is still room for one and one doesn’t already exist. A PEM file containing the configuration is delivered to Relution together with the signed app, and can be downloaded from the app detail page after the signing has finished.

1.7.4.5. Consequences of signing an app version

Depending on the combination of signing identity and properties the following cases are possible:

  1. Replacing the version which will be signed

  2. Adding a new version to the same app

  3. Creating a new app

  4. Adding a new version to a different, existing app

  5. Replacing a version of a different, existing app

1.7.4.6. Replacing the version which will be signed

This will happen when the bundle identifier and bundle build version are not changed or set identical to the properties of the app version to be resigned. This happens because Relution identifies app versions uniquely by the combination of those two properties. This will lead to the app version to be signed being replaced by the newly signed version.

Important: The existing app version will be deleted

Some example uses are changing an app’s display name or replacing an app’s provisioning profile

Note: The user needs to have sufficient permissions for the app to delete the existing version and to create new versions

1.7.4.7. Adding a new version to the same app

This will happen when the bundle identifier is not changed or set identical to the app version to be signed but the bundle build version is changed. A new, additional version will be added to the same app and the version to be signed will still be present (but could be moved to the archive, see Release status handling).

Some example uses are renewing an app’s expired provisioning profile or changing an app’s shown version.

Note: The user needs to have sufficient permissions on the app to be signed to create new versions

1.7.4.8. Creating a new app

This will happen when the bundle identifier is changed and no app with this bundle identifier is already present in the organization in Relution. This will lead to a new app being created in Relution. The existing app to be signed will remain unchanged.

Some example uses are signing an app created by a supplier with the organization’s own signing credentials for the first time or replacing the development signature with the production signature during the first release of a new app.

Note: The user needs to have sufficient permissions to create new apps

1.7.4.9. Adding a new version to a different, existing app

This will happen when the bundle identifier is changed and an app with this bundle identifier is already present in the organization in Relution but no version with the same bundle build version as the signed app will have. A new, additional version will be added to existing app. The app to be signed will remain unchanged.

Some example uses are signing a new app version created by a supplier with the organization’s own signing credentials or replacing the development signature with the production signature during the an update release of an app version.

Note: The user needs to have sufficient permissions on the existing app to create new versions

1.7.4.10. Replacing a version of a different, existing app

This will happen when the bundle identifier is changed and an app with this bundle identifier is already present in the organization in Relution and it already has a version with the same bundle build version as the signed app will have. The existing version of this app will be replaced. The app to be signed will remain unchanged.

An example use is renewing an expired provisioning profile of an app from a supplier.

Note: The user needs to have sufficient permissions on the existing app to delete the existing version and to create new versions

1.7.4.11. Release status handling

In which release state the new app version is put depends on both the release status of the app version to be signed and the user’s permissions.

  1. The app version to be signed is in Release or Review The new app version will be put into Review if the user has sufficient permissions or else in Development

  2. The app version to be signed is in Development or Archive The new app version will be put into Development if the user has sufficient permissions or else in Review

1.8. MAM Settings

In this chapter, the App Management part of the Relution settings menu is explained.

1.8.1. Adding a new language

Precondition: You are in the group “Administrator”, “Appstore Manager” or “Device Manager”.

How to add an additonal language for support information and app meta data (such as the app name and description):

  1. Navigate to Settings > Languages.

  2. Press the Add button and select the language you want to add. Confirm your selection by pressing Save.

image

  1. Check that the added language appears in the list.

image

  1. If you want to set the new language as default language, press the Make default button.

  2. Update the meta data of your existing apps for the new language.

    1. Navigate to Apps > App Store > Your App > Edit and select the tab for the new language.

    2. Enter the missing data into the fields for the new language.

  3. Update the support information for the new language.

    1. Navigate to Settings > Support.

    2. Follow the instructions in the chapter Customizing support data.

1.8.2. App Categories

Precondition: You are in the group “Administrator” or “Appstore Manager”.

  1. Navigate to Settings > Categories and make sure the On/Off switch in the top right is in the “On” position.

  2. Press the Add button to start adding a new category.

image

  1. Enter a name and a short description for all configured languages.

  2. Press the Save button.

image

  1. You can now select the new category on an app’s edit page.

1.8.3. App Notifications

Precondition: You are in the group “Administrator” or “Appstore Manager”.

This page allows you to enable/disable and configure the app notifications. In this setting you can define a template for each notification type in all configured langauges. The available placeholders are displayed when editing a notification template.

Understanding app notifications of the Enterprise App Store

It can be confusing to know when which user is informed about new apps or app updates via push.

In the following table you will find the conditions when which push message will be delivered:

Notifications for new apps

Required activated portal settings:

  • Notifications for new apps enabled

User action:

  • A new application with one of the following release states is created/uploaded:

Appstore User Reviewer Developer Appstore Manager

RELEASE

yes

yes

yes

yes

REVIEW

no

yes

yes

yes

DEVELOPMENT

no

yes

yes

yes

ARCHIVE

no

no

no

no

Displayed notification:

``A new app `name' is available on the app store'' (or custom template)

If an app already exists on the device when the same app was newly created in the app store, no notification is sent.

Notifications for app updates

Required activated portal settings:

  • Notifications for updated apps enabled

User action:

  • A new version of an existing application with one of the following release states is created/uploaded:

Appstore User Reviewer Developer Appstore Manager

RELEASE

yes

yes

yes

yes

REVIEW

no

yes

yes

yes

DEVELOPMENT

no

yes

yes

yes

ARCHIVE

no

no

no

no

Displayed notification:

"An update for app `name' is available (or custom template)

Special notes for push notifications

Push notifications are sent only for apps that are known & installed on the device. A known & installed app is an installed app, which is also visible in one of the app list in the Relution app. The synchronization of known & installed apps is triggered by a client login and a manual app list refresh.

Android:

If you have installed an app on the device, and the app is moved from a “visible” release status to the Archive release status, and then the app is moved back from the Archive release status to a “visible” release status, the push notification is not sent until another synchronization happens. This is because the device does not see the archived app and therefore it does not recognize it as managed. THe app is not known or installed. After the user initiates a refresh of the app list, the app will be “visible” again and the push notifications will be received again.

iOS:

Works the same way as Android, but notifications are sent only when you move a known & installed app from the Release status to another “visible” status.

App Workflow notifications

image

2. Device Management (MDM)

Relution Mobile Device Management is an easy-to-use system to manage mobile devices. It covers the main aspects of Enterprise Mobility Management, such as inventory management, configuration management, application management, security and monitoring.

This section provides information on how to work with mobile devices in Relution.

2.1. Getting Started

The Relution Portal is the main entry point for managing devices and policies inside of your organisation.

On your first log in to the Relution Portal as an administrator, a guided product tour is shown which explains the functionality.

The “Devices” menu in Relution lets you see and manage all of your devices which you have enrolled.

Device inventory

The inventory list gives you an overview about your devices and lets you perform actions on these devices. On the left, the most important navigation points are displayed. You can enroll devices, apply and remove policies and rule sets, apply actions to devices, delete and withdraw devices. Beneath this you can filter the list of your devices by platform, state, user, group or policy. You can also use the search bar for finding specific devices. Additionally you will find a button for resetting the filter you set before and load the complete list of devices. To view a device’s details, click the arrow button on the right side of each device entry in the list.

image

Enrollments

In the enrollment view, all enrollments can be seen. If you lost the enrollment e-mail you can also see the enrollment passcodes for each enrollment.

image

Policies

The policy view is described in the Policies section.

Workflow

The standard workflow to work with the Relution Mobile Device Management:

Precondition: You are in the group “Administrator” or “Device Manager”.

  1. Navigate to the devices view.

  2. Enroll an iOS, Android or Windows device.

  3. If the device is successfully enrolled, you can test the connectivity by sending an action (e.g. Lock) to the device. If everything is configured correctly, the device will be locked immediately.

  4. Define a policy in the policy view, e.g. a password configuration.

  5. Navigate back to the device view and apply the policy to the device by pressing the “apply policy” button.

  6. Check on the device whether the policy was applied.

2.2. Enrolling a Device

The following chapters show you how to enroll mobile devices. The first chapter describes how to create an enrollment. These steps are the same for all platforms. Once you have created an enrollment, go to the platform specific steps.

Preconditions

  • You are in the group Administrator or Device Manager

  • The user to be enrolled has to be at least in the Device User group

As Administrator

  1. Navigate to Devices > Inventory and click on Enroll.

  2. Click on Select user and select the user for whom you want to enroll a device.

  3. Enter a phone number if you want to send an enrollment SMS to the user.

  4. Choose a device name, the device’s platform and ownership.

  5. Optional:

    1. Select a policy to apply after enrollment.

    2. Select a rule set to apply after enrollment.

  6. Select whether you want to notify the user via email or SMS about the enrollment.

  7. Click on Save to create the enrollment.

Note If you do not see any notification options, they have been disabled in Settings > Notifications. In this case you will have notify the user by other means.

image

Additional hints

  • If you do not set a device name, the device’s name is determined automatically after the device has been enrolled, based on information supplied by the device.

  • If you do not know the device’s platform, do not select any platform to leave it Unknown. Relution will then detect the device’s platform during enrollment.

  • You can apply/change the policy or rule set at any time after the enrollment. It is not required to apply a policy right away.

  • By default an enrollment is valid for seven days. You can change the validity period any way you wish.

2.2.1. Android devices

As an administrator

Before you can enroll an Android device, you need to create an enrollment as described in Enrolling a Device.

As a user

The following steps have to be completed by the user of the mobile device. Depending on the notification options that were set when creating the enrollment, the user will be notified via email or SMS. If you chose not to notify the user automatically, you will have to notify them yourself. If you are a Device Manager, then you can also let them scan the QR code directly on your Relution portal by hovering your mouse over the enrollment’s QR code icon.

image

2.2.1.1. Regular Enrollment

This is the preferred method for enrolling an Android device since it is both faster and easier than a complete manual enrollment.

  1. Make sure the device is connected to the Internet (Wi-Fi or mobile network).

  2. To begin the enrollment:

    1. If you received an enrollment email, either open the email on your mobile device and click on the link, or open the email on another device and scan the QR code using your mobile device.

    2. If you received an enrollment SMS, click on the link in the SMS.

    3. If you did not receive an email or SMS contact your administrator for further instructions.

image

  1. You should see this welcome screen on you mobile device’s browser. Tap on next to continue.

image

  1. You will now be asked to download and install Relution for Android. After you’ve completed the installation, close the Relution app and return to the browser to continue with the enrollment.

    Hint If installation fails, and you are not using the Relution app from the Google Play Store, ensure you’ve allowed installation of third-party apps in your device’s settings (Settings > Security > Unknown Sources).

image

  1. Tap on the Enrollment button to open the Relution app.

image

6. Tap on Get started to continue

image

  1. If your device is running Android 6 or newer, you will be asked to allow Relution to locate your device. If you do not grant this permission, your administrator will not be able to locate your device in case it is stolen or lost.

image

  1. If your device is running Android 6 or newer, you will be asked to allow Relution to read your phone’s state. This is used to share your phone number and IMEI with your administrator. This information is transferred encrypted and is never shared with third parties.

image

  1. You will now be asked to grant Relution administrative privileges. This is required to ensure that your device complies with enterprise requirements, like password policies.

image

Tap on Activate in order to grant administrative permissions. Depending on your device’s manufacturer and Android version the layout of the screen may differ from the screenshot above.

image

On Samsung devices running Android 4.2 or newer, you will also be asked to accept Samsung’s privacy policy. Please confirm this screen as well.

image

  1. Your device will now finish the enrollment process. If you arere enrolling the device manually, continue with step 4 of the manual enrollment.

image

2.2.1.2. Manual Enrollment

If the normal enrollment process does not work for some reason, it is also possible to complete all steps manually.

  1. Make sure the device is connected to the Internet (Wi-Fi or mobile network).

  2. Enter the server URL and your credentials to log in. You can find this information in the enrollment email (except for your password). If you did not get an email or do not know your password, contact your administrator.

image

  1. You should now see the enrollment welcome screen. Follow steps number 6 - 9 of the regular enrollment process.

4. After activating the device administrator you will have to manually enter the enrollment code. This code is also part of the enrollment email. If you did not get an email contact your administrator to get the code.

image

  1. Click on Verify to complete the enrollment process.


2.2.2. iOS devices

As an administrator

  1. Navigate to Devices and click on Enrollment.

  2. Click on the Enroll button.

  3. In this enrollment view choose the user the device belongs to.

  4. Click on the Select User button.

  5. In the window which appears, search for the desired user via the search field on top, or by manually looking.

  6. Click the Ok button.

  7. Enter the device’s phone number if you want to send an enrollment SMS to the user.

  8. (Optional) Choose a device name, the platform and ownership.

  9. Decide how you want to notify the user about their new enrollment.

image

Tips: * The search bar used when selecting a user is case sensitive. It can be used to search by either username or email. * An expiration date for the enrollment can be set at the very bottom of the page. If this value is not set, the enrollment is valid for seven days.

As a user

  1. Click on the link provided you via e-mail or sms or scan the QR code from the e-mail and follow the on-screen instructions.

Note: Use the iOS Camera app to scan the QR code.

  1. Confirm the profile installation several times.

image

  1. After the profile installation, the Relution app is pushed to your device. Confirm the installation of the app when the popup appears.

  2. Open the Relution app and confirm, that relution is allowed to send push messages.

Note: If the user is only in the Device User group but not in the AppStore User group, the activation of push messages is not necessary.

You are now successfully enrolled.


2.2.3. Windows devices

As an administrator

Before you can enroll a Windows device, you need to create an enrollment as described in Enrolling a device.

As a user

  1. Click on the link provided via e-mail or SMS or scan the QR code from the email and follow the on screen instructions.

  2. Click on “Enroll”

  3. Click on “Enrol in device management” (Windows 10 mobile) or “add account” (Windows Phone 8.1)

  4. Provide e-mail address, server (if auto discover is not available) and the enrollment code (Hint: You can copy paste them from the enrollment page).

  5. Click on “Enroll”

  6. You are successfully enrolled if you see the “successful” message.

2.2.4. Managing enrollment notifications

Precondition: You are in the group “Administrator” or “Device Manager”.

This page allows you to enable/disable and configure the enrollment notifications. A user will receive a notification if a new enrollment is created for their account and the checkbox within the enrollment creation for notifying them via email or SMS is checked.

In this setting, you can define a template for each notification type (email/SMS) and each localization of each type (currently DE/EN).

image

Notification placeholders

Within the notification template textbox, you can use special placeholders which are used to dynamically fill in user specific data. (e.g. surname, email, enrollment link, etc.)

Once you enter the edit template area, a list of available placeholders will be available under the template text filed. You can use any of the placeholders in your template.

Please note that providing the link for the enrollment is indispensable. Therefore you should always use the placeholder ${landingPageUrl}.

In order to guarantee a failsafe enrollment procedure, it is recommended to also use the placeholder ${passcode} to give the user the ability to enroll their device even if the automatic enrollment fails.


2.2.5. Auto Enrollments

Auto Enrollments are special types of enrollments which allow many similar devices to be enrolled to Relution much more quickly than their traditional counterparts. Additionally devices can connect to Relution automatically without involvement of an administrator before the devices are handed out. Not all device manufacturers offer auto enrollment methods; those that do and are available in Relution are Apple (iOS) and Samsung (Android KNOX).

In this section, you will find information about various possibilities for auto enrolling your devices, and instructions how to perform them.

Click on one of the subtopics to navigate to the appropriate section.

2.2.5.1. Device Enrollment Program (DEP)

The Apple Device Enrollment Program (DEP) allows for a streamlined device enrollment process, including a customized setup procedure, which eases the deployment of many (similar or identical) devices. DEP enables you to use iOS devices in supervised mode, make enrollments mandatory, protect enrollments from being removed by the user and skip setup steps when setting up the device.

To use DEP within Relution, your organization needs a DEP account and DEP enabled devices. Please refer to the respective Apple documentation to learn more (https://www.apple.com/business/dep/).

Useful links

Apple DEP portal for enterprises https://business.apple.com

Apple DEP portal for schools and educational institutions https://school.apple.com

Apple support document about using device enrollments https://support.apple.com/en-us/HT204142 (German https://support.apple.com/de-de/HT204142)

Configuration

To setup DEP within Relution, open the “Device Enrollment Program” tab in the “Auto Enrollments” in the “Settings” menu. The necessary steps are:

  1. Create an empty Relution-side DEP account first. This is not to be mixed up with your actual DEP account at Apple which is independent from anything configured within Relution.

  2. Download the certificate of your Relution instance.

  3. Login to the Apple DEP portal and create a server definition pointing to your Relution instance.

  4. Upload the certificate for this server.

  5. Download the token the Apple DEP portal creates for you.

  6. Upload this token in Relution.

Your account data then should sucessfully synchronize (possibly a page reload is needed). To check this, navigate to Devices and then Auto-Enrollments.

Fetching device data

Device assignment and removal to/from your Relution server is always done inside the Apple DEP portal. It is not possible to perform these operations through Relution itself. After having one or more devices, open “Auto enrollments” in the “Devices” menu and synchronize the device data. Assigned devices should show up. A new device initially has neither a profile nor a user assigned. You can synchronize devices at any time without having to worry about local data being overwritten; the Relution-specific parts of a device’s configuration (policies and rule sets) are not touched by the process.

Creating and assigning profiles

Before you can actually enroll devices via DEP, you first have to create and assign a device profile to them. You can define as many profiles as you like, but Apple does not allow their deletion. Each device only can have one profile assigned. To create a profile, go to “DEP Profiles” in the “Devices” menu. The most relevant properties of a DEP profile are:

  1. Mandatory configuration - allows to set whether a user can skip automatic configuration through DEP. Most likely you never want to allow this.

  2. MDM removal - whether the user can remove MDM management from the device

  3. Skipping of setup steps - defines which setup steps will be skipped and thus defaulted for a new device. You should skip any steps where the user should not be allowed to configure it to her preferences.

To assign a profile, go to the “Auto enrollments” and edit a device. From the edit screen you can select a profile to be assigned. Note that the actual enrollment of the device only happens when you have assigned both a user and a profile to the device. If the assignment succeeds, you should see a profile status “ASSIGNED” next to the device in the Auto Enrollments view.

You can assign another profile to any device at any time. However, the profile will only be applied upon device activation or reset. It does not affect the current profile of an enrolled device in any way.

Enrolling the device

If the device has a profile and user assigned, you can power it on to start the actual enrollment. If your internal processes allow it you may also hand it to the actual user for activation. Depending on the type of device at some point during the setup procedure (an internet connection has to be provided by the user, either GSM or WiFi) the device will contact the Apple DEP servers in the background to find out whether it has a profile assigned. When the DEP enrollment is optional the user can decide whether the device should be automatically configured. Otherwise, the device will just inform the user that automatic configuration will take place. Depending on which setup steps are defined to be skipped in the DEP profile, the rest of the setup steps have to be performed by the user. Meanwhile the device performs an automatic enrollment procedure with Relution. After setup completes, the Relution app will be automatically pushed to the device. The device’s status in the DEP list should change to “PUSHED” after syncing. The device will now also show up in the Relution device “inventory”.

Removing an enrolled DEP device from Relution

Removing an enrolled device from Relution does not change its state in terms of DEP. Resetting the device afterwards will re-enroll the device with its configured profile. If you want to avoid this, you also have to remove the DEP profile from the device. If you want to take out the device from the DEP process in general you should remove the assignment to your Relution server inside the Apple DEP portal such that it won’t show up in the DEP inventory afterwards. You can re-assign a DEP device to your Relution server again at any time. If it ever had a profile pushed, it will now show up with the profile status “REMOVED”. You can assign a new profile and user to enroll it again.

IMPORTANT NOTICE: Never use the “dismiss device” functionality in the Apple DEP portal unless you have good reasons to do so! Dismissing a device means taking it out of the DEP process forever, so this is a one time operation (or at least a very uncomfortable and time consuming process)!

2.2.5.2. Knox Mobile Enrollment (KME)

With Samsung Knox Mobile Enrollment (KME), Samsung devices can be enrolled in Relution with minimal user interaction. Depending on how the device was purchased, different enrollment options are available.

Enrolling a reseller device

This option is only available for Samsung devices that were bought through an authorized reseller. The reseller can automatically upload these devices to your Samsung Knox account after purchase. Devices can be enrolled as soon as they are turned on for the first time or after a factory reset.

Assigning a profile

Before a device can be enrolled, it needs to be associated with a profile. This profile defines on which Relution server the device is enrolled and which Relution app will be installed. Follow these steps to create a profile and assign it to one or more devices. To complete these steps you need to be device manager or administrator.

  • Sign in to the Relution portal

  • Navigate to Settings > Auto Enrollment

  • Switch to the Knox Mobile Enrollment tab

  • Copy the MDM Server URI to your clipboard

  • Download the x.509 certificate

image

You are now ready to create a profile on the Samsung Knox portal

image

You should now see the Samsung Knox Dashboard

  • Navigate to MDM PROFILES

  • Click on Add

  • Enter the MDM Server URI you copied above

  • Click on Next

  • Enter a name for your profile

  • Upload the x.509 certificate

  • Set other options as desired

  • Click on Save

You should now be able to see the profile you created

  • Navigate to DEVICES > All Devices

  • Select the devices you want to configure

  • Click on Configure

  • Select the MDM profile from the drop down

  • Click on Save

The profile is now assigned to these devices. The profile will be applied when the devices are powered on for the first time or after a factory reset. To ensure devices can be enrolled, continue with the steps below before turning the devices on.

Exporting devices for auto-enrollment

Follow these steps to export your existing devices from the Samsung Knox portal. Importing these devices into Relution allows you to assign users and policies before they are enrolled.

You should now see the Samsung Knox Dashboard

image

  • Navigate to DEVICES > All Devices

  • Click on Download all as CSV file

  • Save the file on your computer’s hard drive

Optional If you assign a user ID to a device that matches a Relution user’s username, thus user will be automatically assigned to the device during import. Otherwise you can manually assign users in the Relution portal. To assign a user ID, select the device before clicking on Configure. Enter a User ID then click on Save.

Importing devices for auto-enrollment

Follow these steps to import your previously exported devices into Relution so you can assign users and policies.

  • Sign in to the Relution portal

  • Navigate to Devices > Auto Enrollments

  • Click on Samsung Knox configuration

  • Click on Select file

  • Find the exported CSV file and click on Open

You should now see the imported devices in the auto enrollments list. You must assign a user to each device. If you do not assign a user, the device will not be able to enroll. If you set user ID’s in the previous step, users will be assigned automatically.

  • Click on a device in the auto enrollments list

  • Click on Select user

  • Select a user that has at least the role Device User

  • Optional: Assign a policy

  • Optional: Assign a ruleset

  • Click on Save

You can now power on the devices for the first time or do a factory reset. Once initial setup of a device completes it will contact Samsung’s servers, receive the assigned profile and start the enrollment process. Follow the on screen instructions to complete the enrollment.

Useing Bluetooth or NFC to enroll devices

This option is available for all Samsung devices that are not yet imported into your Samsung Knox account. Attempting to import a device that has already been imported will cause enrollment to fail. If you wish to repeat this process for an existing device, delete the device from your account before continuing with the steps below.

This process requires at least two Samsung devices, one administrative device and the device to be enrolled. Both devices need to support either Bluetooth and/or NFC (both devices need to support the same technology, obviously). Devices can be enrolled at any time.

Creating a profile

Before a device can be enrolled, it needs to be associated with a profile. This profile defines which Relution server the device needs to be enrolled with and which Relution app is to be installed. Follow these steps to create a profile. To complete these steps you need to be device manager or administrator.

  • Sign in to the Relution portal

  • Navigate to Settings > Auto Enrollment

  • Switch to the Knox Mobile Enrollment tab

  • Copy the MDM Server URI to your clipboard

  • Download the x.509 certificate

You are now ready to create a profile on the Samsung Knox portal

You should now see the Samsung Knox Dashboard

  • Navigate to MDM PROFILES

  • Click on Add

  • Enter the MDM Server URI you copied above

  • Click on Next

  • Enter a name for your profile

  • Upload the x.509 certificate

  • Set other options as desired

  • Click on Save

You should now be able to see the profile you created. The profile is assigned to the device during enrollment.

Assigning the profile and enrolling

Perform the following steps on the administrator’s device.

  • Install the Samsung Knox Deployment app on the administrator’s device

  • Open the Knox Deployment app

  • Sign in with your Samsung Knox account

  • Click on Profile

  • Select the previously created profile

  • Click on Deployment mode

  • Select Bluetooth or NFC

  • Click on Start deployment

The administrator’s device is now set up to enroll one or more devices. Complete the following steps on the devices to be enrolled.

  • Open a browser on the device to be enrolled

  • Go to https://me.samsungknox.com

  • Click on Next to start enrollment

  • Follow the on screen instructions

During enrollment the device is registered on the Samsung Knox portal and a new user and device are created on the Relution server.

2.3. Device inventory

The device inventory list shows all enrolled devices.

2.3.1. Device Compliance

What is compliance?

The compliance state of a device is an indicator thsat shows if a device meets the assigned security policy.

As you may already know, a policy is a set of configurations which enables you to allow or deny certain features or applications on your users devices.

In some cases however, the user or the device is still able to perform operations which are not allowed by your configured policy (primarily possible on Android devices).

The Relution application on the device is able to monitor this security violation and notifies the Relution server when a new violation has occured.

As long as a violation exists on the device, it will remain in a “non-compliant” state.

This can have several effects on the device, e.g. the Relution Secure Mail Gateway denies all connection attempts from this device to the Exchange Gateway or the unavailability of managed applications.

The violation is also visible to the user on their device and if possible the Relution application provides them the possibility to resolve the security violation by pressing a simple button within the application (depending on the violation, only on Android devices)

The word compliance and the compliance status thus represent the conformity of a device according to the permissions you granted it (with the use of a policy).

Getting compliant

Android

In order to resolve compliance violations on the device you need to go to the “Compliance” view inside the Android application. The violated configuration is displayed accordingly and can be viewed in detail by clicking on it. The application provides a button which allows you to resolve the corresponding violation.

image image

iOS

On iOS devices, compliance violations are much more less likely to appear as policies are natively supported by the operating system. Violations on iOS are primarily reported by the operating system due to errors when failing to enforce a policy.

The user cannot produce violations by operating the device or changing its configuration (except jailbraking the device).

Windows

On Windows Phone devices, compliance violations are much more less likely to appear as policies are natively supported by the operating system. Violations on Windows are primarily reported by the operating system due to errors when failing to enforce a policy.

The user cannot produce violations by operating the device or changing its configuration (except hacking the device).

2.3.2. Device states

Device states give you the most basic information about the device, it’s health and current capabilities. You can use it to filter classes of devices and perform various actions on them, therefore it is important to know what a specific state stands for and how you can change it.

A device can be in one of the following states in Relution environment:

  • COMPLIANT

    The device is active, responsive, correctly configured and enforces the configured policy. This is the correct and desired state, when a device is managed without a problem.

  • NONCOMPLIANT

    The device is active, responsive, but it has open violation(s) which has not been resolved yet, hence it does not enforce the configured policy. Some Relution services may not be available to the device as long as the violation exists. Often a manual action is required by the device user or Device Manager, in order to resolve the violation(s) and get back to COMPLIANT state.

  • INACTIVE

    The device has not connected to the server or answered to the availability check of the Relution server for the defined amount of time. The time period for both settings (availability check & inactivity interval) can be configured inside the Device Management section of the settings.

  • WITHDRAW_PENDING

    The device user decided on their own to withdraw the device from the MDM, therefore MDM sent WITHDRAW action to the device, but it was not processed yet. This is a temporary device state. From the MDM point of view, the device behaves like in WITHDRAWN state and cannot be managed any longer. After the WITHDRAW action is confirmed, the device will change to WITHDRAWN state.

    If the device is not responding and it is clear that it can be deleted, the Device Manager can clean-up such device by deleting it once more, but in this case the WITHDRAW action won’t be executed.

    NOTE: WITHDRAW_PENDING is applicable only for certain Android client versions

  • WITHDRAWN

    The device user decided on their own to withdraw the device from the MDM and thus the device cannot be managed any longer. The user can do it by removing the Provisioning Profile (iOS) or by disabling the administration privileges of the Relution Client App (Android). This state is technically equal to DELETED state and Relution Device Manager can only delete such device. If the user wants to be managed again, they have to enroll their device to the MDM once again.

  • DELETION_PENDING

    The Device Manager deleted the device from the MDM, this includes sending a WITHDRAW action to the device. Till the WITHDRAW action is processed, the device stays in this temporary device state. From the MDM point of view, the device behaves like in DELETED state and cannot be managed any longer. After the WITHDRAW action is confirmed, the device will change to DELETED state.

    If the device is not responding and it is clear that it can be deleted, the Device Manager can clean-up such device by deleting it once more, but in this case the WITHDRAW action won’t be executed.

  • DELETED

    The device has been marked as deleted. It is not displayed in the device inventory unless you modify the filter to include deleted devices. Deleted devices will be removed from the database upon a clean up task.

Deletion and withdraw process

As mentioned above, the device can be removed from MDM management in two ways: by device user decision or by manager decision. Please see following diagram for more details.

image

Since the WITHDRAWN and DELETED devices are not managed by MDM, the amount if device information is reduced too. Clear device data step mentioned in the diagram performs following changes:

  • Cancel all unprocessed actions

  • Clear all push information (no push notifications can be sent to the device)

  • Remove ruleset information (it is removed only if the device is changed to DELETED)

  • Remove policy information

  • Clear installed apps

  • Remove all compliance violations

2.3.3. Device details

Precondition: You are in the group “Administrator” or “Device Manager”.

The device details page contains several information about the device and its status.

To view a device’s details, press the arrow button or the name of the device inside the device inventory list.

The displayed data is initially created upon device enrollment. In order to refresh the data the execution of a “refresh device info” action is required.

The device detail page is divided into the following sections:

Note: Information available and displayed about the device can vary depending on the device platform and the device type.

Device information

The device information page displays general information about the device and its compliance status. The menu on the left provides buttons for applying and removing a policy, deleting it from the device inventory, editing its general information and triggering the execution of an action on the device.

image

Networks

Under the networks tab all data concerning cellular, wireless and bluetooth networks and their configuration is collected.

image

System

All data about the configuration and other details about the device itself (hardware/software) is gathered inside the system tab.

image

Security

The security tab allows you to view security relevant information about the device. This includes the root or jailbrake detection, device encryption, etc.

image

Location

This tab is used to display the location of the device on a map. Before the location can be displayed you need to send a “locate device” action. This can be triggered via the regular action workflow or by pressing the “Locate device” button inside the “Location” tab Before you can use the “locate device” action you have to enable this option first in the settings (“device management”).

image

Compliance violations

This view lists all occured policy violations of the selected device. If for example the device user removes the administration rights of Relution, this will be reported in this view. The administrator then can take necessary actions to enforce the compliance of the device again.

image

History

The history tab allows you to trace the actions and policy history of the device. You are able to see if actions have been successfully executed or are still pending. If any errors occur while executing an action their are listed here.

image

Installed apps

The installed apps page holds information about all installed applications on the device. You are able to send a uninstall action to the device by selecting the desired application and pressing the uninstall button. To remotely uninstall applications, there are platform specific limitations:

iOS: The application to remove is a so called managed app. Managed apps are installed either by the user via the Relution app on the device or via the Relution portal by the administrator.

Android: The application is a non-system application.

The possibility of uninstalling an application is displayed by a checkable box in the list.

image

2.3.4. Checking Device Connection

Users and administrators often ask the Relution team why a device did not recieve an action or a policy or why it is not in a desired state. Before calling the help desk or support engineer to ask why a device is not available at the moment, please try to evaluate following points.

General

The most frequent reason is that the network infrastructure is prohibiting a connection to the Relution server.

Problems can be:

  • Does the device have an internet connection via 3G/4G or via wifi?

  • Does the current network infrastructure allow a connection to and from the Relution server? Is there a firewall or are important ports closed? Check the requirements for the network infrastrcuture. You can also check if the Relution server is available from your device, by typing the Relution server URL into the brwoser of the device. For example https://live.relution.io

  • Is the server running and online?

  • If you use the MDM features, please check if the device is correctly enrolled

    • Did you create an enrollment for the correct platform or did you choose the platform “automatic”

    • Did you follow the enrollment instructions under Enroll Android devices or Enroll iOS devices?

    • Does the user, with which you try to login exist? See User settings

    • Is this user activated in the User settings?

    • Does the user has the according role? Does the user have the right to login? To be able to login to the Enterprise App Store, the user has to be in one of the following groups:

      • Organisation Appstore User

      • Organisation App Reviewer

      • Organisation Developer

      • Organisation Appstore Manager

      • Organisation Administrator

    • Login problems could also appear if you use an ActiveDirectory or other LDAP system. Please carefully read the page about LDAP configurations

To quickly check if the device can connect to the Relution server, open the Relution Portal on your Desktop and navigate to Devices→Inventory. Afterwards, choose the problematic device and have a look a the copliance status.

Try to send an action to the device. A non critical action is the “Refresh device info” action. Apply this action to the device and navigate to the device details. Click on History to check if the action was performed correctly. It can take up to a couple of minutes until the action is executed completely. You have to refresh this view, to get the newest information about the action status.

An issue also could be, that you have incompatible versions of the Relution app and the Relution server. Our team always tries to keep all version compatible to each other, but to be safe, make sure the version have the same two version numbers for example 2.6.x.

iOS devices

To check if the device is correctly enrolled, navigate on the device to Settings→General→Device Management and check if a profile of your organisation is installed.

Please also check if the profile is verified and still valid by clicking on the profile on your device.

Android devices

To check if the device is correctly enrolled, open the installed Relution app on the device. If you are enrolled, you will be logged in automatically. If you use the Enterprise App Store, please log in. Open the menu and navigate to Device information. You will see an overview about the Relution version, the user you are using, the server which the device is connected to, the last contact time and also information about the enrollment state. In the Services tab at the top you can check the state of the push service which is necessary to communicate with the device.

Windows devices

To check if the device is correctly enrolled perform a “Refresh device details” action from the Relution portal as device manager. If the action was successfully executed, the communication will be enabled.

2.4. Policies

A policy is a set of settings applied to a device to permit the device to be compliant with the rules of a company.

A device can have one or no policy at a time. A policy can be composed of one or more configurations. Depending on the operating system of the mobile devices there a different configurations that can be set.

A configuration can be infringed by user actions. Such infringements are reported to the administrator by a change of the device state. For example, if an iOS user deletes the MDM profiles on their device (which is needed to apply settings to the device) a compliance violation is reported, because the administrator cannot set actions or policies anymore.

image

Precondition: You are in the group “Administrator” or “Device Manager”.

To create a new policy navigate to “policies” and press the “add” button and type in the policy name and the description. The next step is to define the subpolicies and activate them.

image

The indicator you see on most of the attributes tell you about which attribute will work on which platform or device. A black indicator shows the minimum version of an operating system this attribute will take effect.

image

A red indicator says, that this attribute will explicitely not work on this device type.

image

2.4.1. Android Configurations

2.4.1.1. Passcode

The Android passcode configuration enforces the use of a specific password according to the passcode settings defined by the administrator.

The administrator can configure the desired protection level by choosing from multiple password properties, e.g. length, complexity and the validity period of the passcode.

image

2.4.1.2. App Compliance

The “App compliance” configuration allows the administrator to define which applications are allowed to be run and installed on the user’s device. The applications are identified by their package name which can be looked up via the Google Play Store or by checking the “Installed Applications” tab in the device’s details.

The “App compliance” configuration allows to set two global settings which define if the configuration works with a blacklisting or whitelisting mechanism. You can also define required apps, which needs to be installed by the user to get compliant.

Whitelisting

If you check the “Disable all” button, the configuration works with whitelisting.

This means that once the policy is applied by default every application which is not a native Android or the Relution application is prevented from being executed and seen by the user (in case of KNOX supporting devices).

Alternatively, you can only use the “Revoke internet permission for all” button which prevents applications from accessing the internet. This allows applications to be executed but without access to the internet. This can be useful in some cases but we don’t recommend to use this unless really necessary due to some apps crashing if they are not able to access the internet. Depending on the application this can have a immense impact on the user experience and satisfaction.

By adding a package name to the configuration in whitelisting mode, you can exclude specific applications which are not considered by device when enforcing your application control policy. As seen in the section below you can however add further restrictions to the specific application.

Blacklisting

If you don’t check one or both of these settings, the configuration works as a blacklist.

You can now enter an application’s package name and explicitly set the permissions the app is granted on the device.

Adding an exception

Once a package name was added to the configuration (in black- or whitelisting mode) the following options are displayed:

Block app

This setting prevents the execution of the specified app if it is started by the user. This feature is intented for stock Android devices only as it can be seen as a equivalent for the disable feature of Samsung KNOX devices. Background processes or system apps will not be blocked.

Disable

This setting disables the specified app. The disabled application package is not uninstalled but it can’t be seen and thus executed by the device user. In theory, if disabled application packages are uninstalled and then reinstalled, they would be enabled again. Relution however prevents this by keeping a permanent blacklist and prohibiting the installation.

This feature works only on Samsung KNOX devices.

Stop

This setting stops the application process of the associated package name if it is currently running. It however does not stop the app from being run again by the user. Running downloads and background processes are not affected by this option and will still run. This feature works for Samsung KNOX devices.

Revoke internet permission

This feature revokes the internet permission of the specified app. Using this feature won’t disable or uninstall the application. When an application tries to access the removed internet permission, it won’t be granted to it and a security exception will be thrown by the Android framework. If the application is not able to handle the exception it probably crashes.

The policy will be enforced immediately if the given application is already present in the device. In case if the application is not installed, it will be enforced during the application install time. Also once the policy is applied, it will be enforced all the time (even if the application is uninstalled and reinstalled back).This feature works for Samsung KNOX devices.

Restrict to roaming

If this option is set, the configuration will only be active when the device is in roaming mode.

Allow in WiFi

If this option is set, the configuration will not be active if the device is in roaming mode and is connected to a wifi network.

Whitelisted Apps

List of package names of the apps which are excluded from the options above.

An often used workflow is to set both global options and put the apps you do not want to be affected on the whitelist. In this case you have the highest possible blocking effect. (As seen in picture below)

image

2.4.1.3. Restrictions

The “Restrictions” configuration is used to allow or disallow specific features of the operating system. There are general restrictions, app restrictions and browser restrictions. For example it is possible to disable the camera on the device in the sector “general restriction”. All applications which try to access the camera will not be allowed to use it anymore if the checkbox “Disable camera” is checked.

image

2.4.1.4. Wi-Fi

The “Wi-Fi” configuration allows you to preconfigure the settings of a known wireless network within the Android Wifi manager. You specify the network’s name (SSID), the authentication type and the credentials. Additionally you can set a priority value to the network configuration which Android uses to decide to which network to connect to. (0: default, priority increases with value)

image

2.4.1.5. Exchange

(available for Samsung KNOX devices version 2.1+)

This configuration allows you to distribute exchange configurations on your users devices. You can preconfigure connection, security and synchronization details.

When checking the “Automatically insert …” boxes the corresponding fields will be automatically filled with the user’s data.

Once the policy is applied on the user’s device, they will get a notification to click on which automatically configures their email account and calendar.

2.4.1.6. Kiosk Mode

The “Kiosk Mode” configuration allows you to force the presentation or kiosk mode on the device. The Relution Launcher will be started on the device and you can define if only one or more apps are allowed to be used by the user.

You can define a custom wallpaper, lockscreen image, hide the navigation bar, specify an emergency phone number (KNOX 4.0+) and more.

image

2.4.1.7. Certificate

(available on Samsung KNOX devices version 2.0+)

The “Certificate” configuration allows you to deploy your own certificates (and thus custom trusted Certificate Authorities) on the device.

Prerequisites

In order to add custom certificates to Android native’s certificate manager a passcode must be set on the device. Relution only allows the use of the certificate configuration if a passcode configuration is already existing. You will be prompted to add a passcode configuration if it does not exist when you attempt to add a certificate configuration.

image

To be able to choose your custom certificate in the dropdown list, you need to add it first in the Settings > Certificate area.

Once you’ve chosen your certificate in the configuration you can press “Save” and once the policy gets applied on a device, the certificate is added to the list of trusted authorities within the Android certificate manager.

2.4.2. Android Kiosk Mode

Creating a kiosk policy

This shows how to create a new policy with a kiosk mode configuration. It is also possible to add additional configurations or to add a kiosk mode configuration to an existing policy.

  • Navigate to Devices, Policies

  • Click on Add

  • Select Android as platform

  • Enter a name for the policy

  • Click on Save

You have now created a new policy. You should see the Configurations tab, which currently contains zero configurations.

  • Click on Add

  • Select Kiosk Mode

  • Click on Add details

  • Click on Save

You have now added a default Kiosk Mode configuration to your policy. Note that the configuration does not enable kiosk mode by default (Kiosk is Off). You can now use the Add button to add additional configurations to the policy or click on the Kiosk Mode configuration to customize it.

  • Click on Kiosk Mode to customize the configuration

  • Switch Kiosk to On to enable the configuration

  • Enter “com.mwaysolutions.relution” under apps enabled in kiosk mode

  • Click on Save

  • Click on Publish and confirm

  • Go to Devices with this version

  • Add at least one enrolled device to apply the policy on this device

You have now created and published a policy with a kiosk mode configuration that allows the use of the Relution app in kiosk. You have applied the policy on at least one device. See the following sections for more details how kiosk mode works on different devices.

image

Note It is not required to allow the Relution app in kiosk. The app will never block itself, but the user will not be able to manually start Relution in this case.

Note All options marked with a blue KNOX badge are only applicable on Samsung devices. They will not work on other devices. The number indicates the minimum KNOX version required. You can see a Samsung device’s KNOX version in device details (“Samsung SDK”).

2.4.2.1. Samsung devices

On Samsung devices Relution uses Samsung’s MDM API to enforce kiosk mode. This allows Relution to enter kiosk mode without additional user interaction.

In kiosk mode users are restricted to apps that are allowed by the Kiosk Mode configuration. In the example above the Relution app was allowed in kiosk mode. You should see a launcher that is empty except for the Relution app.

To prevent users from breaking out of kiosk mode it is recommended to add a Restrictions configuration that also disables USB debugging and Safe Boot.

2.4.2.2. Other devices

The Kiosk Mode is a custom launcher that replaces the default launcher of the mobile device. This launcher only shows apps allowed by the Kiosk Mode configuration.

To enable kiosk mode on a device, users need to change their launcher to the Relution launcher. When kiosk mode is applied on the device, Relution will prompt the user to change their launcher. Depending on the Android version Relution will also ask for additional permissions required to enforce kiosk mode.

image

After a policy with a Kiosk Mode configuration is applied a welcome screen is shown to the user. This is typically referred to as onboarding. Users need to tap on Get Started to continue.

image

On Android 6 and above, Relution will ask for permission to draw over other apps. This is required to block access to Android’s settings through notifications. This will also prevent users from accessing their regular notifications. On older Android versions no special permission is required.

Tap on Go to settings to access overlay permissions.

image

Switch the toggle button to the On position, then return to kiosk mode onboarding.

image

On Android 5 and above Relution will ask for permission to access usage stats. This is required to block access to apps outside of kiosk mode. On older Android versions usage stats are unavailable and Relution uses a different mechanism to detect the foreground app.

Tap on Go to settings to access the usage stats permission overview.

image

Tap on Relution to access Relution’s usage stats permissions.

image

Switch the toggle button to the On position, then return to kiosk mode onboarding.

image

Users now need to make Relution their default launcher. Tapping on Enable Kiosk will open Android’s default app switcher dialog.

image

Tap on Relution Kiosk then tap on Always to make Relution the default launcher of the device.

image

The device is now in kiosk mode and shows the apps allowed by the Kiosk Mode configuration. To change the apps that are displayed in the kiosk simply update the policy and add additional package names to allowed apps.

2.4.2.3. Leaving Kiosk Mode

As an “emergency exit”, you can define a passcode in the Kiosk mode configuration. To enter this passcode on the device, tap the background screen in the following order:

2 — 4 — 1 — 3

(meaning 2 taps (pause) 4 taps (pause) 1 tap (pause) 3 taps) The pause has to be longer than 0.5 seconds.

2.4.3. iOS configurations

2.4.3.1. Passcode

The iOS passcode policy forces the user to set a specific password according to the passcode settings defined by the administrator. There are multiple password strengths you can define for the password the users have to set. The minimum passcode quality is the first step. Besides that you can define the minimum length, passcode age, the time to display lock, passcode history and the number of failed attempts until the device is completely wiped and all data is deleted.

image

2.4.3.2. Restrictions

The restrictions configuration is used to allow or disallow some features of the operating system. There are general restriction, app restrictions and browser restrictions. For example it is possible to disable the camera on the device in the sector “general restriction”. All applications which try to access the camera will not be allowed to use it anymore if the checkbox “Disable camera” is checked.

image

2.4.3.3. App Compliance

The App Compliance is used to set a White-/Blacklist on your devices. Those lists will make sure that your users only use the Apps you allowed them to. You can also set a list of Apps that are required to be installed on your devices.

image

2.4.3.4. VPN

The VPN configuration is used to enable VPN usage on the enrolled devices, configure the VPN network and set credentials. For example you can name the connection and set the VPN type.

image

2.4.3.5. E-mail

Here you can configure E-mail accounts and enable them. You can fill in the E-mail address, an account description or name as well as choose IMAP or POP as a type. You also can set the incoming and outgoung mail server configurations like passwords, hostnames and portnumbers.

image

2.4.3.6. Exchange

Here you can enable and configure Exchange accounts and set rights and authentification settings.

image

2.4.3.7. Webclip

Here you can define iOS shortcuts to a specific website that can be created on the iPhone web browser and stored on the iPhone’s home screen. You can upload an icon, set the label and the url to which the webclip refers to.

image

2.4.3.8. Calendar

In the Calendar configuration you can manage CalDAV accounts and their authentification settings.

image

2.4.3.9. Calendar subscription

The Calendar subscription configuration is used to manage calendar subscriptions.

image

2.4.3.10. Contact

Here you can enable and manage cardDAV accounts and their settings.

image

2.4.3.11. Certificates

Here you can define certificates which should be installed on the devices by default.

image

2.4.3.12. Mobile network

The “Mobile network” configuration manages the Access Points configurations such as Proxy Server URL and Proxy Server Port.

image

2.4.3.13. iOS Updates

This configuration manages parameters to configure the scheduling of automatic iOS updates.

The following parameters can be configured:

  • Update action (see Install Update action)

  • Repeats on: The days updates should be performed

  • Start time: The time the updates should be performed on the specified days

  • Time zone: The time zone to be used with respect to the start time

Starting from the server start, it is checked every hour whether an update is to be carried out on the basis of the specified parameters. If the specified time is reached, an Install Update action with the specified update action will be applied for all assigned devices which have an update available.

NOTE:

  • The “Start time” actually means the updates will be carried out within the next hour starting from the specified time (the exact update time is depending on when the server was started)

The assigned iOS devices must:

image

2.4.3.14. Wi-Fi

This configuration manages the WiFi configurations.

image

2.4.3.15. SCEP

Here you can manage the Simple Certificate Enrollment Protocol restrictions.

image

2.4.3.16. Single App Mode

Here you can define an app that will be run in Single App Mode, so that the user cannot leave the app.

First, select an app you want to show in Single App Mode:

image

Then, select the options for this mode (additional restrictions when showing this app):

image

Device controls
  • Deactivate Touch: If set, the touch screen is disabled.

  • Deactivate motion (screen rotation): If set, the device rotation sensing is disabled.

  • Deactivate volume buttons: If set, the volume buttons are disabled.

  • Deactivate side switch: If set, the ringer switch on the side of the device is disabled. When disabled, the ringer behavior depends on what position the switch was in when it was first disabled.

  • Deactivate sleep/wake button: If set, the sleep/wake button is disabled.

  • Deactivate auto-lock: If set, the device will not automatically go to sleep after an idle period.

Assistent systems
  • VoiceOver: If set, allow VoiceOver adjustment.

  • Zoom: If set, allow Zoom adjustment.

  • Invert Colors: If set, allow Invert Colors adjustment.

  • AssistiveTouch: If set, allow AssistiveTouch adjustment.

  • Speak Selection: If set, Speak Selection is turned on.

  • Mono Audio: If set, Mono Audio is turned on.

Accessibility Shortcut
  • Voice Over: If set, Voice Over is turned on. Default is false.

  • Zoom: If set, Zoom is turned on. Default is false.

  • Invert Colors: If set, Invert Colors is turned on. Default is false

  • Assistive Touch: If set, Assistive Touch is turned on. Default is false

2.4.3.17. Relution Shared Device

Here you can configure Relution’s own Shared Device Mode. See this chapter for details:

2.4.4. Relution Shared Device Mode (iOS)

The Relution Shared Device Mode enables the secure use of a device by multiple users. Using Relution’s own authentication mechanism instead of cloud based IDs, it is now possible to share devices in accordance with strict data protection laws. Another advantage is that the Relution Shared Device Mode is activated and deactivated using policies, so that it can be switched on and off dynamically, i.e. for exam use cases.

Requirements

To use the Relution Shared Device Mode, the iOS device has to be running in Supervised Mode.

Functionality

When the Relution Shared Device Mode is enabled on a device, it will show a login screen that cannot be left (i.e. the home button or swipe upwards gesture are disbaled.):

image

The login will accept any User ID / Password combination known to Relution (either local or LDAP/AD users). Once a user logs in, the login success screen will appear and the device will work normally.

image

The apps assigned to that user will be installed dynamically and whitelisted (i.e. all other apps are no longer visible).

When the user logs out, the device will lock again and show the login screen.

The apps that were installed during the login will be removed from the device. The Whitelisting will be disabled so all apps are shown again.

Creating a Relution Shared Device policy

This shows how to create a new policy with a Shared Device Mode configuration. It is also possible to add additional configurations or to add a Shared Device Mode configuration to an existing policy.

  • Navigate to Devices, Policies

  • Click on Add

  • Select iOS as platform

  • Enter a name for the policy

  • Click on Save

You have now created a new policy. You should see the Configurations tab, which currently contains zero configurations.

  • Click on Add

  • Select Relution Shared Device

  • Click on Add details

  • Click on Save

You have now added a default Relution Shared Device Mode configuration to your policy. You can now use the Add button to add additional configurations to the policy or click on the Relution Shared Device Mode configuration to customize it.

  • Click on Relution Shared Device to customize the configuration

  • OPTIONAL: Set the check boxes as desired. No changes are necessary. See Configuration options below for details.

  • Click on Save

  • Click on Publish and confirm

  • Go to Devices with this version

  • Add at least one enrolled device to apply the policy on this device

You have now created and published a policy with a Shared Device Mode configuration. You have applied the policy on at least one device.

2.4.4.1. Configuration options

image

Device controls
  • Deactivate Touch: If set, the touch screen is disabled.

  • Deactivate motion (screen rotation): If set, the device rotation sensing is disabled.

  • Deactivate volume buttons: If set, the volume buttons are disabled.

  • Deactivate side switch: If set, the ringer switch on the side of the device is disabled. When disabled, the ringer behavior depends on what position the switch was in when it was first disabled.

  • Deactivate sleep/wake button: If set, the sleep/wake button is disabled.

  • Deactivate auto-lock: If set, the device will not automatically go to sleep after an idle period.

Assistent systems
  • VoiceOver: If set, allow VoiceOver adjustment.

  • Zoom: If set, allow Zoom adjustment.

  • Invert Colors: If set, allow Invert Colors adjustment.

  • AssistiveTouch: If set, allow AssistiveTouch adjustment.

  • Speak Selection: If set, Speak Selection is turned on.

  • Mono Audio: If set, Mono Audio is turned on.

Accessibility Shortcut
  • Voice Over: If set, Voice Over is turned on. Default is false.

  • Zoom: If set, Zoom is turned on. Default is false.

  • Invert Colors: If set, Invert Colors is turned on. Default is false

  • Assistive Touch: If set, Assistive Touch is turned on. Default is false

2.4.4.2. Managed App Configurations

Push configurations to managed apps. Choose the bundle identifier of the specific app and insert a valid app configuration payload. IOS 7+ is required. In the payload, you can use the placeholders that can be displayed on the bottom of the page. For example, you can configure an eMail client app by using the placeholder \{$user.email} to make the configuration usable by different users. The placeholders will be filled in when the configuration is pushed to the device.

Note
The app has to be installed for this configuration to work. If you install the app in the same policy, make sure the app configuration is executed after installing the app by adding it later in the configuration list.

Here are some examples for managed app configuration payloads:

SecurePIM (com.virtual-solution.securepim-enterprise) for use with Office365:

<?xml version="1.0" ?>
<!DOCTYPE plist PUBLIC "-//Apple Inc//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
 <dict>
  <key>license</key>
    <string>your-license-key</string>
    <key>activeSyncServer</key>
    <string>outlook.office365.com</string>
    <key>userEmail</key>
    <string>${user.email}</string>
    <key>activeSyncUser</key>
    <string>${user.email}</string>
    <key>deviceSerialNumber</key>
    <string>${device.serialnumber}</string>
    <key>recipientCertificateEmail</key>
    <string>${user.email}</string>
    <key>allowTouchIDAuthentication</key>
    <string>true</string>
    <key>callKitEnabled</key>
    <string>true</string>
  </dict>
 </plist>

FileBrowser for Education (com.stratospherix.filebrowsereducation) for accessing an SMB share:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>mdm-enforce</key>
  <integer>1</integer>
  <key>lockdown</key>
  <integer>1</integer>
  <key>1displayname</key>
  <string>My NAS</string>
  <key>1domain</key>
  <string>office.mwaysolutions.com</string>
  <key>1flags</key>
  <integer>1746</integer>
  <key>1machinename</key>
  <string>smb://yoursmbservershare/</string>
  <key>1username</key>
  <string>${user.email}</string>
  <key>1vpntype</key>
  <integer>0</integer>
  <key>waitForSearchButton</key>
  <integer>0</integer>
</dict>
</plist>

IBM Verse client (com.ibm.lotus.traveler):

<?xml version="1.0" ?>
<!DOCTYPE plist PUBLIC "-//Apple Inc//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
 <dict>
 <key>appConfigOnly</key>
   <string>true</string>
 <key>serverType</key>
   <string>onpremise</string>
 <key>serverURL</key>
   <string>server_url_or_ip_address</string>
 <key>user</key>
   <string>${user.name}</string>
 <key>password</key>
   <string></string>
 <key>restrictClipboard</key>
   <string>false</string>
 <key>disableShareMenu</key>
   <string>false</string>
 <key>disableRemoteImages</key>
   <string>false</string>
 <key>mamKey</key>
   <string></string>
 <key>mamKeyMismatchTimeout</key>
   <integer>24</integer>
 <key>disableAttachmentExport</key>
   <string>false</string>
 <key>mailFilterDays</key>
   <integer>3</integer>
  <key>mailFilterDays.lock</key>
   <string>false</string>
 <key>previewLines</key>
   <integer>2</integer>
 <key>previewLines.lock</key>
   <string>false</string>
 <key>confirmDelete</key>
   <string>false</string>
 <key>confirmDelete.lock</key>
   <string>false</string>
 <key>attachmentFilter</key>
   <integer>100</integer>
 <key>attachmentFilter.lock</key>
   <string>false</string>
 <key>mailThreads</key>
   <string>false</string>
 <key>mailThreads.lock</key>
   <string>false</string>
 <key>useMailSignature</key>
   <string>false</string>
 <key>useMailSignature.lock</key>
   <string>false</string>
 <key>mailSignature</key>
   <string></string>
 <key>mailSignature.lock</key>
   <string>false</string>
 <key>bccMyself</key>
   <string>false</string>
 <key>bccMyself.lock</key>
   <string>false</string>
 <key>calendarPastFilterDays</key>
   <integer>14</integer>
 <key>calendarPastFilterDays.lock</key>
   <string>false</string>
 <key>calendarAlarms</key>
   <string>true</string>
 <key>calendarAlarms.lock</key>
   <string>false</string>
 <key>calendarAudioAlarms</key>
   <string>true</string>
 <key>calendarAudioAlarms.lock</key>
   <string>false</string>
 <key>weekStartDay</key>
   <integer>0</integer>
 <key>weekStartDay.lock </key>
   <string>false</string>
 <key>exportContacts</key>
   <string>false</string>
 <key>exportContacts.lock</key>
   <string>false</string>
 <key>searchCorpDirectory</key>
   <string>true</string>
 <key>searchCorpDirectory.lock</key>
   <string>false</string>
 <key>contactSortOrder</key>
   <string>lastfirst</string>
 <key>contactSortOrder.lock</key>
   <string>false</string>
 <key>contactDisplayOrder</key>
   <string>firstlast</string>
 <key>contactDisplayOrder.lock</key>
   <string>false</string>
 <key>appPassword</key>
   <string>false</string>
 <key>appPasswordType</key>
   <string>numeric</string>
 <key>appPasswordMinLetters</key>
   <integer>0</integer>
 <key>appPasswordMinNumeric</key>
   <integer>0</integer>
 <key>appPasswordMinNonLetters</key>
   <integer>0</integer>
 <key>appPasswordMinUppercase</key>
   <integer>0</integer>
 <key>appPasswordMinLowercase</key>
   <integer>0</integer>
 <key>appPasswordMinSymbols</key>
   <integer>0</integer>
 <key>appPasswordMinLength</key>
   <integer>4</integer>
 <key>appPasswordAutolock</key>
   <integer>30</integer>
 <key>appPasswordExpiration</key>
   <integer>0</integer>
 <key>appPasswordHistory</key>
   <integer>0</integer>
 <key>appPasswordWipeFailures</key>
   <integer>0</integer>
 <key>appPasswordProhibitSequences</key>
   <string>false</string>
 <key>appPasswordProhibitTouchID</key>
   <string>false</string>
 </dict>
</plist>

2.4.5. Windows configurations

2.4.5.1. App Compliance

The “App Compliance” configuration is used to set a White-/Blacklist on your devices. Those lists will make sure that your users only use the apps you allowed them to. If you blacklist apps the user won’t be able to install them from any kind of source.

2.4.5.2. E-mail

Here you can configure e-mail accounts and enable them. You can fill in the e-mail address, an account description or name as well as choose IMAP or POP as a type. You also can set the incoming and outgoung mail server configurations like passwords, hostnames, portnumbers and synchronisation settings.

2.4.5.3. Exchange

Here you can enable and configure Exchange accounts and set rights and authentification settings. You can also use the Secure Mail Gateway as an Exchange proxy instead of the actual Exchange server.

2.4.5.4. Passcode Policy

The Windows passcode policy forces the user to set a specific password according to the passcode settings defined by the administrator. There are multiple password strengths you can define for the password the users have to set. The passcode quality is the first step. Besides that you can define the minimum length, passcode age, the time to display lock, passcode history and the number of failed attempts until the device is completely wiped and all data is deleted.

2.4.5.5. Restrictions

The restrictions configuration is used to allow or disallow some features of the operating system. There are a lot of restriction categories like connectivity or security. For example it is possible to disable the camera on the device. All apps which try to access the camera will not be allowed to use it anymore if the checkbox “Allow camera” is unchecked.

2.4.5.6. Wi-Fi

This configuration manages the WiFi configurations on the device.

2.4.6. Policy Placeholders

To easily create policies that work for multiple users, several placeholders are supported.

You can use them in configurations to universally set the apropriate attributes:

${user.fullname}

${user.name}

${user.givenName}

${user.surName}

${user.phone}

${user.salutation}

${user.email}

${user.country}

${user.custom1} - ${user.custom10}

${device.jailbroken} / ${device.rooted}

${device.manufacturer}

${device.model}

${device.name}

${device.osversion}

${device.phonenumber}

${device.platform}

${device.serialnumber}

Important: If you use the custom attribute placeholders, you have to make sure the corresponding custom attribute is set for every user that the policy gets applied to.

2.5. Actions

Precondition: You are in the group “Administrator” or “Device Manager”.

Actions are one time activities which are applied to devices once and executed once. A typical action is a “device lock”. If you send a “lock” action to a device, it will be locked immediately and the user has to type in their password to get it unlocked again (if a password is set).

If you have successfully enrolled an iOS device it will be listed in the inventory list.

image

To perform an action select one or more devices by clicking on the checkbox next to it and press the button “apply action”.

You will see a view with a list of possible actions you can perform on the device.

image

The list of actions can vary depending on the device you have chosen.

Choose an action by clicking on the entry in the list.

Some actions have additional properties which you have to fill out to perform the action.

To apply the chosen action just press the “next” button, review the list of devices which will receive the action and press “apply”.

To check the status of an action you sent, navigate to the “device details” and have a look at the “Actions” tab or click the “Actions” icon (fourth icon in the status column).

2.5.1. Android Actions

2.5.1.1. Alert

This action allows you to send an alert to device. It will play an alarm sound for the duration at full volume, even when in silent mode.

2.5.1.2. Deploy App

If you want to deploy an app to a device select the desired app from the list. Please note that in order to see the app in the list, you first need to upload it to the Relution Enterprise App Store.

Only app versions in state “release” are visible inside the list and are downloaded by the device. It is not possible to deploy app versions in state review or development.

As additional parameters you can specify:

  • If you want the app being deleted when the device gets withdrawn.

  • If you want to deploy the application “silent”, which will install the app on the device without notifying the user. (only on Samsung KNOX devices)

image

2.5.1.3. Lock Device

This action will send a command to the device to turn off the display and lock itself. To unlock the device, the user has to authenticate themself with the configured authentication method (passcode, pin, pattern, …). If no authentication method is set, the device can be unlocked without any authentication.

2.5.1.4. Send Message

This action provides you the possbility to send a message to the device. The user will receive the message as a notification on their device.

In order to send a message to the device you need to provide a title and the content of your message.

2.5.1.5. Refresh Device Information

This action sends a command to the device to refresh the information about itself. The device then gathers all relevent information which can be seen in the device’s detail page and sends it to the server.

2.5.1.6. Remove App

This action allows you to remotely remove an application which is installed on the device.

In order to enable the device identifying the correct application, the package name of the application which should be removed must be provided.

The package name can be found by browsing the “installed apps” tab in the device’s details or by looking the package name up in the Google Play Store (if application is publicly available).

2.5.1.7. Wipe device

This action will reset the device to its factory settings causing all data and configuration to be erased.

Once executed, the data cannot be restored and the device can’t be controlled by Relution anymore!

2.5.1.8. Locate device

This action will locate device if any location service is enabled on the target device. Please make sure you are allowed to perform this action. If you are not sure about it, disable this functionality in Settings –> Device Management.

2.5.1.9. Reset Lock Passcode

Once this action is received on the device a prompt is shown where the user can choose a new passcode. The precondition for this action is, that a passcode is already set on the device. If a passcode is already set, and this action is sent, the user is prompted to type in a new passcode. If there is a passcode policy on the device, the user is prompted to type in the new passcode. The new passcode has to match the current policy. The history will be deleted, so although the passcode policy defines a max. number of history entries, these entries will be deleted, so the user can set the same password as before.

2.5.1.10. Add Shortcut

This action allows the deployment of a shortcut to the device’s homescreen. If the user clicks on the shortcut the default browser will open the url.

You must specify an URL and a title for the shortcut. In addition you can provide an optional icon which should be displayed instead of the default icon for the shortcut.

Note: In order to remove the shortcut again from the device you need to know the title and the URL again.

The URL and title of the shortcut serve as identifier and the title is case-sensitive!

image

2.5.1.11. Remove Shortcut

This action allows to remotely remove a previously created shortcut with the “Add shortcut” action.

In order to remove the shortcut you’ve created earlier you need to provide the exact title and URL so the device can identify the desired shortcut.

Note: The title of the shortcut is case-sensitive.

2.5.1.12. Push file to device

This action is used for deploying files to devices.

The uploaded file will be automatically downloaded by the device into the specified location once it has received the action.

The root folder of the directory is the public space of the device. Common locations for files are for example /Download, /Documents. You can also provide the path to a non-existing folder which will then be created by Relution.

image

2.5.2. iOS Actions

2.5.2.1. Add Shortcut

This action allows the deployment of a shortcut to the device’s homescreen. If the user clicks on the shortcut the default browser will open the url.

You must specify an URL and a title for the shortcut. In addition you can provide an optional icon which should be displayed instead of the default icon for the shortcut.

Note: In order to remove the shortcut again from the device you need to know the title and the URL again.

The URL and title of the shortcut serve as identifier and the title is case-sensitive!

image

2.5.2.2. Deploy app

If you want to deploy an app from the Relution Enterprise App Store to a device select the desired application from the list. Please note that in order to see the app in the list, you first need to upload it to the Relution Enterprise App Store.

Only app versions in state “release” are visible inside the list and downloadable by the device. It is not possible to deploy app versions in state review or development.

Additionally you can specify if you want the app being deleted when the device gets withdrawn.

image

2.5.2.3. Deploy app from Apple App Store

This action allows you to deploy an app to a device from the official Apple App Store.

The dropdown box on the right allows you to search the App Store of a specific country. This is necessary as the availability of applications depends on the country and localization of the used App Store.

After you have chosen the desired country you can search the App Store for the desired app. Once you have found it, proceed as usual by selecting it and clicking next.

Additionally you can specify if you want the app being deleted when the device gets withdrawn.

image

2.5.2.4. Lock Device

This action will send a command to the device to turn off the display and lock itself. To unlock the device, the user has to authenticate himself with the configured authentication method (passcode, pin, pattern, …). If no authentication method is set, the device can be unlocked without any authentication.

2.5.2.5. Refresh Device Information

This action sends a command to the device to refresh the information about itself. The device then gathers all relevant information which can be seen in the device’s detail page and sends it to the server.

2.5.2.6. Remove App

This action allows you to remotely remove an application which is installed on the device.

To enable the device to identify the correct application, the package name of the application which should be removed must be provided.

The package name can be found by browsing the “installed apps” tab in the device’s details or by looking up the package name in the Google Play Store (if the application is publicly available).

2.5.2.7. Reset Lock Passcode

Once this action is received on the device a prompt is shown where the user can choose a new passcode.

2.5.2.8. Wipe device

This action will reset the device to its factory settings causing all data and configuration to be erased.

Once executed, the data cannot be restored and the device can’t be controlled by Relution anymore!

2.5.2.9. Remove Shortcut

This action allows to remotely remove a previously created shortcut with the “Add shortcut” action.

In order to remove the shortcut you have created earlier you need to provide the exact title and URL so the device can identify the desired shortcut.

Note: The title of the shortcut is case-sensitive.

2.5.2.10. Install Update

This action allows to remotely update the operating system (OS) of an iOS device.

To use this action, the iOS device must:

The action is only visible if the device in question has an iOS update available. Whether a device has an update available is queried periodically and is also checked as part of the Refresh Device Information action.

There are several ways to manually execute an Install Update action. In the device details view, as well as in the device inventory view, an icon located beside the current OS version suggests that an update is available. If the device is supervised, the icon will be clickable and lead to the configuration of the action (see below). The OS version column in the device inventory is hidden by default and must first be activated via the table settings.

image image

In addition, the action can also be triggered by selecting the updatable devices in the device inventory and select the “Install Update” action from the “Apply action” menu. This option allows for updating multiple devices at once. If more than one device is selected, the devices must all have the same update available, otherwise the “Install Update” action will not be shown in “Apply action” menu.

The action provides the following three modes:

  • Download and/or install the software update

  • Download the software update without installing it

  • Install an already downloaded software update

image

The action will also ignore the following configurations as part of the Restrictions configuration:

  • Force delayed software updates: When active, delays user visibility of Software Updates.

  • Delay a software update in days: Allows a admin to set how many days a software update on the device will be delayed.

Besides the option to manually trigger an update via the action, it is also possible to automatically update the devices via the iOS Updates configuration.

2.5.3. Windows Actions

2.5.3.1. Alert

This action triggers an alarm on the device, even when the device is set to silent. To stop the alarm push the hardware power button on the device.

2.5.3.2. Deploy app

If you want to deploy an app from the Relution Enterprise App Store to a device select the desired app from the list. Please note that in order to see the app in the list, you first need to upload it to the Relution Enterprise App Store.

Only app versions in state “release” are visible inside the list and downloadable by the device. It is not possible to deploy app versions in state review or development.

Please be aware that apps can be installed only, if the appropriate certificate (so called AET or token) is deployed to the device prio to app installation.

2.5.3.3. Lock Device

This action will send a command to the device to turn off the display and lock itself. To unlock the device, the user has to authenticate themself with the configured authentication method (passcode, pin, pattern, …). If no authentication method is set, the “lock device” action will fail.

2.5.3.4. Refresh Device Information

This action sends a command to the device to refresh the information about itself. The device then gathers all relevent information which can be seen in the device’s detail page and sends it to the server.

2.5.3.5. Remove App

This action allows you to remotely remove an application which is installed on the device. In order to enable the device identifying the correct app, the interna name of the app which should be removed must be provided. The package name can be found by browsing the “Installed apps” tab in the device’s details or by looking the internal name up in the Relution Enterprise App Store.

2.5.3.6. Wipe device

This action will reset the device to its factory settings causing all data and configuration to be erased.

Once executed, the data cannot be restored and the device can’t be controlled by Relution anymore!

2.6. Rules

Rules are little helpers which let the Device Administrator define automatic actions based on defined events. Basically rulesets and rules they are build on the same concept as policies and configuration. You can define a ruleset which consists of single rules and apply the ruleset to one or multiple devices. A rule can consist of a range of attributes which are described below:

image

Here you can define rules like “If event then action executed in duration from the event occurence”.

Possible Events

Name - The name of this rule

Event type: Action status - If an action is in this state, the defined actio will be triggered

Event type: Device status - If a device changs its state to this device status, the defined action will be triggered.

Event type: Compliance violations - If device status NONCOMPLIANT is chosen before, it is possible to define only one commpliance violations as event

Action type: Perform action on device - This action automatically wipes or locks the device, based on the defined event

Action type: Notify administrators - This action automatically informs the administrator via email based on the defined event

User or Group - Choose the administrators to be informed

E-Mail - Adjust the e-mail template which is used to inform the administrators and users

Action type: Notify user - This action automatically informs the user via push message on their device based on the defined event

Execute in - Time when the action will be executed after event occurence (from 9 months to 0 seconds(immediately)

2.7. Secure Mail Gateway

Introduction

The Relution Secure Mail Gateway (SMG) allows to prohibit or allow the synchronization between a mobile device and the Exchange server according to defined rules. It is possible to define the SMG for each organisation seperately on one Relution server.

To use this feature, please make sure, that your Exchange server is securely operated in your internal network (not accessible from outside) and the Relution instance is installed in your DMZ or has a secure connection to your Exchange server.

Usage

Precondition: You are a member of the group “Administrator” or “Device Manager”.

To use the Relution SMG in your organisation, you have to enable it in the settings.

image

To grant the Relution SMG, which works as a proxy, access to your Exchange server, you have to provide the url of your Exchange server and the Exchange domain.

Now you have diverse options on who you want to be able to synchronise their mails, contacts and more.

Following options are available:

Allow devices not supported by Relution: Devices which cannot be enrolled into Relution like non Android or iOS devices, Desktops and Notebooks

Allow “Bring your own devices”: Devices which are marked as BYOD by the administrator

Allow “Corporate owned devices”: Devices which are marked as COD by the administrator

Allow devices with an unknown ownership: Devices which are not marked as COD or BYOD by the administrator

Allow Android devices: Allows Android devices in general or specify which versions are allowed to synchronize

Allow iOS devices: Allows iOS devices in general or specify which versions are allowed to synchronize

Allow Windows devices: Allows Windows devices in general or specify which versions are allowed to synchronize

Allow compliant devices: Allows only devices which are enrolled and currently in the state “compliant”

Allow deleted devices: Allows only devices which are enrolled and currently in the state “deleted”

Allow inactive devices: Allows only devices which are currently in the state “inactive”

Allow non compliant devices: Allows only devices which are enrolled and currently in the state “non compliant”

Allow withdrawn devices: Allows only devices which are currently in the state “withdrawn”

Combinations of these options are possible.

Hint: As authentication method “basic authentication” with username and password is possible. Authentication with client certificates is currently not possible.

2.8. Apple Volume Purchasing Program (VPP)

2.8.1. Preconditions

  1. You are in the group “Administrator” or “Appstore Manager”.

  2. Your iOS Devices are running iOS 9 or later for device based VPP.

2.8.2. Activating the Volume Purchase Program

In order to activate the Volume Purchase Program(VPP) on your Relution server, you need to get a valid secure token from the Apple VPP Store. Download the token (on the Account Summary page) and upload it to Relution (on the Volume Purchase Program page under Settings). To finish the Activation, you also need to type in the correct Account email address and set your current region. Every Token is valid for one year and you will have to upload a new one once the old one becomes invalid.

image

2.8.3. Adding Users to your Volume Purchase Program

Upon Activation you can add Users whom you would like to give licenses to the Volume Purchase Program. Newly added Users will be notified per e-mail if enabled under Notification in your Relution Settings. Those Users will have to register themselves with the link provided in the e-mail. If an user accepts the invitation to participate, their personal Apple ID is linkted to your Relution. Apple manages thoses IDs automatically, not Reltion. Registered User then can be given App licenses. You can delete users from the your Volume Purchase Program with the `Retire User' Button.

2.8.4. Using device based license assignment

For devices with iOS 9 or later, Apps can also be assigned to a single device instead of a VPP user. For most scenarios, this greatly simplifies the App distribution process as it has several advantages:

  • No Apple ID is needed on the target device

  • No VPP user invitation is necessary

  • The App can directly and silently be pushed to the target device

Note: If the same license should be applied to multiple devices, use the traditional user based assignment.

An App must support “device based” assignment. This information can be found in the Apple App Store and is also synchronized into the Relution database for VPP Apps. It is shown in the overview of purchased Apps.

2.8.5. Managing your Licenses

You can manage / distribute your licenses under App Store > Purchased Apps. To get started, buy some licenses (for a free App) using the `Purchase App' Button - this will redirect you to the Apple VPP Store. Purchased Apps will automatically be added to your App Store. After buying licenses from the Apple VPP Store, you will need to sync your licenses with Relution by pressing the respective button. There are four things that will show up with the App.

  • Status: If the App is in Release/Review/Development

  • Device Assignable: Whether licenses for this App can be assigned per device

  • Licenses: How many licenses you have aquired

  • Available: How many licenses are available

  • Used: How many licenses have been distributed.

image

To distribute licenses, click on the arrow button next to the App you want to distribute. Click on `Associate Licenses' to distribute licenses and on `Revoke licenses' to take back already distributed licenses.

image

The Volume Purchase Program only works with the Relution App Store. A User with a license has to access the App via the Relution App Store in order to get it for free.

When removing a user from the Volume Purchase Program, the licenses and installed Apps will be removed from their Device and become available for re-use.

2.9. iOS supervised mode

What is the iOS supervised mode?

The iOS supervised mode is an extension to the standard mobile device management functioanlity provided by iOS and Relution. Additionally to the already seen MDM features, devices in supervised mode can do following:

  • Single App Mode - Force an installed app to stay in the foreground. This app cannot be closed and the user cannot return to their homescreen. This mode can be quit, if you have an extra pin code.

  • Global HTTP Proxy - Allows you to force all internet traffic through a single proxy server.

  • Content Filter - Allows you to configure which URLs can be accessed by the device.

  • Airdrop - Allows you to enable or disable the Airdrop feature.

  • iMessage - Allows you to enable or disable the iMessage feature.

  • Profile installations - You can deny or allow the installation of profiles manualy by the user.

  • Account modifications - Allows changes to the users accounts.

How does it work?

To put the device into supervised mode you have to connect to a Mac OS X device via USB. You will need a software called “Apple configurator” (Link) to setup the device. After you have setup the supervision on the device, Relution is able to apply the extra actions and policies of the supervision mode on to the devices over-the-air. Therefor you have to enroll the supervised device normally into Relution. We are working on more and more supervised features to be included in the next Relution versions.

Important notes

Enabling supervised mode will start a factory reset on the device and all data will be lost. You also have to know, that if you have a lot of iOS devices, every single one of them has to be connected to a Mac OS X device via USB, which is a lot of work, but gives you more options. Up to 30 devices can be configured at a time by tethering via USB connection.

2.10. Automatic App Deployments

2.10.1. Abstract

The App-Deployments function allows the assignment of apps to users and vice versa.

It is meant to be used in an MDM scenario where no App Store (Relution or public) is allowed on the mobile device and all apps are to be auto-assigned (pushed).

This feature is extremely useful in a Relution Shared Device environment, where apps can be dynamically installed and removed based on the current user login.

In an App Store scenario, where users are allwos to download their own apps, this feature is not required.

2.10.2. Assigning apps to a user or group

To assign apps to a user or group, there is a new tab called “Auto-Deployments” in any user’s and group’s details view:

image

In this view, you can add apps by clicking the “Add” button. A list of available apps (that have previously been added to the Relution App Store as either native or VPP/public apps) is shown. Select the desired app(s) and click “Ok” to save your selection:

image

To remove these app assignments from the user or group, select the app(s) from the list and click “Delete”:

image

2.10.3. Assigning users or groups to an app

To assign users or groups to an app, there is a setting called “Auto Deployments” on the Settings page of any app’s details view:

image

To assign a user or group to this app, click the pen icon under “Auto Deployments” and the follwing list appears:

image

Select the user(s) and/or group(s) you want to assign and click “Ok”.

2.11. MDM Settings

In this chapter, the MDM part of the Relution settings menu is explained.

2.11.1. Push Certificates

To work with the Apple APNS service which is responsible for push notifications and profile submission to enrolled iOS devices M-Way Solutions needs a signed MDM Push Certificate. To obtain this certificate from the Apple Push Certificates Portal, you have to follow the steps described in the following section.

Please note: MDM Push Certificates are valid for 365 days and need to be renewed before they expire.

2.11.1.1. Creating new MDM Push Certificates

You need a RSA private key which will be used to generate a CSR (certificate signing request) and later to sign the MDM messages you send. You should only use this private key for this purpose and you should make sure that this key and the corresponding passphrase are backed up. If you do not already have a key you want to use, you can create a new one with the following command via OpenSSL tooling in your console:

$ openssl genrsa -des3 -out customerPrivateKey.pem 2048

You will be asked for the passphrase during the process.

To create a CSR (certificate signing request) based on your private key, please also use OpenSSL tooling. You can create the CSR with the following command:

$ openssl req -new -key customerPrivateKey.pem -out customer.csr

Where customerPrivateKey.pem is the private key you want to use. You will be asked for the passphrase during the process.

Now you need to send the CSR to M-Way Solutions via our helpdesk. M-Way Solutions will then sign the CSR to enable Relution to send MDM pushes.

You will receive a .plist_encoded or .relution file which can be uploaded to the Apple Push Certificates Portal (https://identity.apple.com/pushcert/ – you need an Apple ID). After uploading the file to the portal you can download the created MDM push certificate.

With the certificate, your private key used to generate the CSR and the passphrase you can create the .p12 file which Relution needs. You can use the following openSSL command to create the .p12 file which is needed.

$ openssl pkcs12 -export -out newKeystore.p12
    -inkey myPrivateKey.pem -in myCertFromApple.pem

After creating the file you can upload it to Relution under Settings > Organization > Certificates > Push certificate for MDM.

2.11.1.2. Renewing MDM Push Certificates

As stated before, MDM Push Certificates need to be renewed regularly because they are only valid for 365 days. If you do not renew the certificate before it expires or revoke it you need to create a new certificate and it will be necessary to re-enroll all devices. To renew your MDM Push Certificate you have to follow roughly the same steps as when creating a new certificate.

To create a CSR (certificate signing request) based on your private key, please use OpenSSL tooling. You can create the CSR with the following command:

$ openssl req -new -key customerPrivateKey.pem -out customer.csr

Where customerPrivateKey.pem is the private key you want to use. You should use the same private key you used when creating the certificate. You will be asked for the passphrase during the process.

Now you need to send the CSR to M-Way Solutions via our helpdesk. M-Way Solutions will then sign the CSR to enable Relution to send MDM pushes.

You will receive a .plist_encoded or .relution file which can be uploaded to the Apple Push Certificates Portal (https://identity.apple.com/pushcert/Important: You have to use the same Apple ID which was used to create the certificate) by selecting to Renew the old certificate. It is recommended to download and backup the old certificate before.

After uploading the file to the portal you can download the renewed MDM push certificate.

With the certificate, your private key used to generate the CSR and the passphrase you can create the .p12 file which Relution needs. You can use the following openSSL command to create the .p12 file which is needed.

$ openssl pkcs12 -export -out newKeystore.p12
      -inkey myPrivateKey.pem -in myCertFromApple.pem

After creating the file you can upload it to Relution under Settings > Organization > Certificates > Push certificate for MDM.

2.12. The Relution App

Then Relutuion client app is avaialable for all Relution client environments (iOS, Android and Windows) and is complementary to the Relution server.

2.12.1. Using the Relution Android app

Precondition: You have already downloaded and installed the Relution Android app onto your device.

  1. Login to Relution with your credentials given by your administrator.

image

  1. You can switch to the navigation by pressing the navigation button in the left top corner of your screen or swiping from the left side of your screen. In this navigation you can choose between following navigation items depending on your role:

    • Apps

    • Updates

    • Review

    • Development

    • Search & Request

    • Relution Apps

    • Compliance

    • Logout

    • FAQ

    • Contact

    • Imprint

    • Device information

image

  1. On “Apps” you can see all your available applications inside the Relution Enterprise App Store.

image

  1. “Updates” lists all available updates for your apps which you should install.

image

  1. In “Review” there are all apps which are in the review status.

  2. In “Development” there are all apps which are in the development status. By pressing the “PUBLISH” button and confirming the opened dialogue you can publish the app for all users.

image image

  1. Search & request new app

With this feature you are able to propose a new application from the public app store to your administrator which then can approve the use of this app and add it to the Relution Enterprise App Store making it available for you to download and use.

To initiate a proposal you first have to choose the desired app from the public app store by entering its name into the given form.

image

Pick the intended application and press request after touching the options icon of the list entry.

image

A new form will appear which gives you the chance to argument about the need of this application for your daily work or private use. After pressing the request button, your administrator will receive your request.

The administrator or App Store manager will now check your request and either approve or reject the use of the requested application. If your requested application is rejected you will be notified separately. Otherwise you will receive a notification that your application is now available in the Enterprise App Store.

image

  1. Relution Apps

Web apps are applications which are capable of running on any device with a browser. Relution offers the possibility to not only distribute native applications for the Android and iOS platforms, but can also display and run these web applications inside the Relution application. In this menu entry you can see all web applications which are installed on your device.

By clicking on the icon you can launch the application.

image

If you want to exit the current web application you just need to swipe from the left screen side to the right. This will cause a button to appear which will close the web application when pressed.

  1. You can check your MDM compliance information here.

  2. You can logout of the Relution app by pressing the “Logout” button.

  3. In the Frequently Asked Questions section, there are listed and answered typical questions that may come up by using the relution app.

image

  1. Under “Contact” there are given necessary information like phone number and email adress to get in contact with the M-Way Solutions GmbH support team.

image

  1. Imprint

image

  1. Device information

The device information screen displays information about the account, service and device status.

image

2.12.2. Using the Relution iOS app

Precondition: You have already downloaded and installed the iOS Relution app on your iOS device.

  1. Login to Relution with your credentials given by your administrator.

image

  1. You can switch to the navigation by pressing the navigation button in the left top corner of your screen or swiping from the left side of your screen. In this navigation you can choose from the following depending on your role:

    • Apps

    • Updates

    • Review

    • Development

    • Search & Request

    • Relution Apps

    • Logout

    • FAQ

    • Contact

    • Imprint

image

  1. On “Apps” you can see all your available applications inside the Relution Enterprise App Store.

image

  1. “Updates” lists all available updates for your apps which you should install.

image

  1. In “Review” there are all apps which are in the review status (only available to “App Reviewer”)

  2. In “Development” there are all apps which are in the development status. By pressing the “PUBLISH” button and confirming the opened dialogue you can publish the app for all users (only available to “Developer”)

image image

  1. Search & request new app

With this feature you are able to propose a new application from the public app store to your administrator which then can approve the use of this app and add it to the Relution Enterprise App Store making it available for you to download and use.

To initiate a request you first have to choose the desired app from the public app store by entering its name into the given form.

image

Pick the intended app and press request after touching the options icon of the list entry.

image

A new view will appear which gives you the chance to argument about the need of this application for your daily work. After pressing the request button, your administrator will receive your request.

The administrator or App Store manager will now check your request and either approve or reject the use of the requested application. If your requested application is rejected you will be notified separately. Otherwise you will receive a notification that your application is now available in the Enterprise App Store.

image

  1. Relution Apps

Web-Apps are applications which are capable of running on any device with a browser. Relution offers the possibility to not only distribute native applications for the Android and iOS platforms, but can also display and run these web applications inside the Relution workspace. In this menu entry you can see all web applications which are installed on your device.

By clicking on the icon you can launch the application.

image

If you want to exit the current web application you just need to swipe from the left screen side to the right. This will cause a button to appear which will close the web application when pressed.

  1. Compliance

If you are enrolled in the Relution MDM, you can check your compliance here.

  1. You can logout of the Relution app by pressing the “Logout” button.

  2. In the Frequently Asked Questions section, there are listed and answered typical questions that may come up by using the relution app.

image

  1. Under “Contact” there are given necessary information like phone number and email adress to get in contact with the M-Way Solutions GmbH support team.

image

  1. Imprint

image

2.12.3. Updating the Relution app

This chapter describes how to update the Relution client installed on a mobile device, if the device does not use the app from the platform’s official app store.

If a device uses the app from the official app store no manual update is required. The app installed on the device will be updated automatically when a new version becomes available in the official app store. The point in time at which a device installs the update depends on the individual device’s update settings.

Settings

To verify which app type is installed on enrolled devices by default, log in to the Relution portal with an administrative account.

  • Navigate to Settings > Organization

  • Go to the tab Relution Client Apps

If the toggle for a platform is set to “Use the public Relution client from the Platform app store” devices will use the version available from the official app store. If the toggle is set to “Use Relution Client App from the Relution App Store” devices will use the version available in your Relution app store.

It is inadvisable to change this setting after you’ve started to enroll devices. Otherwise different devices may install the app from a different source, depending on the date they enroll and the date the setting was changed. This will make it more difficult to keep devices on the same app version.

image

Prerequisites

To be able to update a device, the following prerequisites need to be fulfilled:

  • The organization is configured to use the Relution app from the Relution app store

  • The device is enrolled with Relution MDM

  • The device has a previous version of the Relution app installed

  • The device installed the previous version from the Relution app store

2.12.3.1. General information

The current Relution version that is installed on enrolled mobile devices should be available in the Relution app store. The version’s release status should be set to Release. To see which version is currently released, hover your mouse over the green status icon, as shown below.

image

If there is no green status icon shown, it means that no version of the app is currently available in release. An orange icon indicates a version under review, while a blue icon indicates a version in development.

To see which version of the app is installed on a device, navigate to Devices > Inventory. Click on the device you want to check and go to the Installed apps tab. Filter for Relution to see the installed version.

image

Each of the following sections explains how the Relution app is updated to a new version based on the device’s operating system.

2.12.3.2. Updating Relution for Android

To update enrolled devices to a new app version, upload a new Relution for Android version to Release.

  • Navigate to App Store > Apps

  • Click on the Relution app for the Android platform

  • Click on Add new version

  • Upload the new version

  • Ensure that you set the new version to Release

  • This will replace the currently released version with the new version

image

When the new version is saved, a Deploy app action is automatically sent to all enrolled Android devices. To verify this, click on an enrolled device and go to the Actions tab. See the screenshot below for an example.

image

On the device, the user will receive a notification that a new version of Relution is available. This is a sticky notification, so the user cannot swipe the notification away until Relution has been updated. To update the app the user needs to click on the notification and select Install.

image image

Samsung devices

On Samsung devices Relution is able to install updates automatically (“silent install”). The remaining process is identical to the description above, but no user interaction is required to install the update.

This is possible due to Samsung’s proprietary KNOX extensions for the Android platform. The user must have enabled the device administrator and accepted Samsung’s privacy policy (this is also required to be compliant with MDM).

2.12.3.3. Updating Relution for iOS

To update all enrolled iOS devices to a new app version, upload a new Relution for iOS version and set it to the Release state.

  • Navigate to App Store > Apps

  • Click on the Relution app for the iOS platform

  • Click on Add new version

image

  • Upload the new version

  • Ensure that you set the new version to Release

  • This will replace the currently released version with the new version

image

When the new version is saved, a Deploy app action is automatically sent to all enrolled iOS devices. To verify this, click on an enrolled device and go to the Actions tab. See the screenshot below for an example.

image

No user interaction is required because managed apps can be updated automatically.

2.12.3.4. Updating Relution for Windows Phone

To update all enrolled devices to a new app version, upload a new Relution for Windows Phone version to Release.

  • Navigate to App Store > Apps

  • Click on the Relution app for the Windows Phone platform

  • Click on Add new version

image

  • Upload the new version

  • Ensure that you set the new version to Release

  • This will replace the currently released version with the new version

Automatic updates are not yet supported for Windows Phone

  • On the device the Relution app will show available updates

  • Users can use Relution to install the available update

image image

3. Customizing support data

Precondition: You are in the group “Administrator”, “Appstore Manager” or “Device Manager”.

The data you enter here will be shown in the respective menus of the Relution client.

  1. Sign in to Relution as “Administrator”.

  2. Go to “Settings, Support”.

  3. Choose one of the tabs:

    • Information, for general support information for your users

    • FAQ, for frequently asked questions

    • Imprint, for your corporation’s imprint

    • Privacy policy, for your company’s privacy policy

image

  1. Type in your data. You have to fill in data for every language you have selected in “Settings” under “Languages”.

  2. After you have finished press the “Save” button and your data will appear in your client apps.

3.1. General Data Protection Regulations (GDPR)

When an administrator signs in to Relution for the first time, they have to accept the privacy policy of M-Way Solutions GmbH. This policy serves as a contract between the organization, which acts as the data owner, and M-Way Solutions GmbH, which acts as the data processor.

To comply with the EU’s General Data Protection Regulations (GDPR) a company may require their users to accept a similar contract before they can use the Relution web portal or its mobile applications. To do this, fill out and enable the privacy policy in Relution’s support settings:

  1. Sign in to Relution as “Administrator”.

  2. Go to “Settings, Support”

  3. Go to the tab “Privacy policy”

  4. Enter a privacy policy for each language

  5. Make sure “Enable privacy policy” is checked

  6. Save

Note Users have to accept the privacy policy the next time they sign in to Relution via the web portal or a mobile application. Make sure to test custom scripts or tools that access Relution via its REST API. The user account used by these tools also has to accept the privacy policy.

A user’s acceptance of the privacy policy is stored on the server, so users do not have to accept the privacy policy more than once, regardless of the platform that was used to accept the policy. However, if the privacy policy is changed, users have to accept the updated version of privacy policy the next time they sign in.

3.1.1. Android

When a user signs in to the Android app after the privacy policy has been enabled, they have to accept the privacy policy before they can continue. If a user rejects the policy they are signed out again. The user does not have to accept the policy again unless it is updated on the server. In this case the user has to accept the updated version the next time they sign in.

Note The first version of the Relution app for Android that supports this feature is version 3.64. Older versions will report an error during login and users will be unable to sign in. Please make sure users have a current version of the app installed before enabling this feature. As a workaround for older versions, users can sign in to the web portal and accept the privacy policy there before signing in to the app.

3.1.2. iOS

When a user signs in to the iOS app after the privacy policy has been enabled, they have to accept the privacy policy before they can continue. If a user rejects the policy they are signed out again. The user does not have to accept the policy again unless it is updated on the server. In this case the user has to accept the updated version the next time they sign in.

Note The first version of the Relution app for iOS that supports this feature is version 4.2. Older versions will report an error during login and users will be unable to sign in. Please make sure users have a current version of the app installed before enabling this feature. As a workaround for older versions, users can sign in to the web portal and accept the privacy policy there before signing in to the app.

3.1.3. REST API

Custom scripts and tools that access Relution via its REST API may fail in case the user account used by these tools has not accepted the privacy policy. As a workaround, manually sign in with this user account and accept the privacy policy. Alternatively update your tools to handle HTTP status code 451 during sign in.

Example of a curl command that can be used to accept an organization’s privacy policy during sign in. Type and version need to be replaced with the values returned by the server as part of the error response that was the result of the previous sign in attempt. It is possible that future versions return more than one type of policy during sign in, which means all of them have to be accepted before a user can sign in.

curl -X POST \
  ${HOSTNAME}/gofer/security/rest/auth/login \
  -H 'Accept: application/json' \
  -H 'Accept-Charset: UTF-8' \
  -H 'Content-Type: application/json' \
  -d "{
    \"userName\":\"${USERNAME}\",
    \"password\":\"${PASSWORD}\",
    \"acceptedTerms\": [
        {
            \"type\": \"${TYPE}\",
            \"version\": ${VERSION},
            \"action\": \"ACCEPT\"
        }
    ]
  }"

3.1.4. Web portal

When a user signs in to the web portal after the privacy policy has been enabled, they have to accept the privacy policy before they can continue. If a user rejects the policy they are signed out again. The user does not have to accept the policy again unless it is updated on the server. In this case the user has to accept the updated version the next time they sign in.

4. Organization Settings

Precondition: You are in the group “Administrator”, “Appstore Manager” or “Device Manager”.

The Organization Settings provide a way to configure organization wide settings.

  • Log in with an administrative account

  • Navigate to Settings > Organization

  • Press Save before leaving a tab to save your changes

4.1. General

The general settings provide ways to customize the appearence of relution and configure several other organization wide settings.

image

General

The Name field allows you to define a custom name which will be used as the page title.

Optical Adjustments

Custom CSS (DEPRECATED)

This button allows you to upload a custom CSS file to alter colors, fonts, etc. of the Relution portal. You can override any css property from the portal. If you wish to have a custom branded Portal get in touch with us. We will be happy to create a custom stylesheet.

Custom logo

The “Logo” button provides an easy way to upload a custom icon for the Relution portal. The uploaded icon will replace the Relution logo on the top left corner.

4.2. Relution Client Apps

In the Relution Client Apps tab you can configure the default Relution Client App for each platform. This is the application that will be installed during the device management enrollment process.

image

users get to see if the log in to the web portal via a browser.

You can either use the publicly available Relution Client Apps provided by M-Way Solutions through the official app stores or you can specify a custom Relution Client App by choosing it from your own Enterprise App Store.

If you do not have a Relution Client App in your Enterprise App Store, you can add it by downloading the application file required for your platform and adding it to the Enterprise App Store as native application in the state Release.

The latest versions of the Relution Client Apps can be found here:

If you choose to use a Relution Client App from your own Enterprise App Store you have to update the application manually. To do this, download the latest version of the application from the links provided above and upload them to Enterprise App Store in the state Release. Adding a new version in the state Release automatically triggers updates to all enrolled devices.

4.3. Certificates

The Certificates tab is used to configure the certificates for Apples push service APNS. More information can be found in Push Certifiactes.

4.4. Password Policy

The Password Policy tab allows you to configure the password policy for all user accounts of this organization.

image

5. Users & Groups

5.1. Roles & Groups

Following groups are initially created when you successfully run the Relution wizard.

IMPORTANT: Please do not delete these preconfigured groups as they are essential for a correct access control model.

5.2. Organisation Developer

A developer can be for example an In-House Developer, 3rd party developer, department or external. With the role developer you are allowed to:

  • Create, Edit & Delete applications that have no version in state Release and Archive

  • See & Download versions in every state (Release, Review, Development, Archive)

  • Upload, Edit & Delete versions for state Review & Development

  • Request applications with the App Request feature

  • Move versions:

    • Development → Review

    • Development → Archive

    • Archive → Review

    • Archive → Development

5.3. Organisation App Reviewer

A reviewer can be for example a manager or person inside a department.

The purpose of a reviewer is to check the functionality of an app and release the app for the employees or put it back to the “development” state if the application does not fulfill the reviewers requirements or expectations.

With the new feature “Application workflow”, users holding the role App Reviewer can also be assignees for a certain step inside the workflow. If the feature is enabled the capability of moving application versions is restricted as the steps inside the workflow define when an application version is ready to be released (Typically if all steps were passed by the version).

This role allows you to:

  • See & Edit applications

  • See & Download versions in state Release, Review and Development

  • Edit versions for state Review & Release

  • Request applications with the App Request feature

  • Move versions (with disabled workflow feature):

    • Review → Release

    • Review → Development

    • Release → Review

  • Move versions (with enabled workflow feature):

    • Release → Review

5.4. Organisation Appstore Manager

Can be for example a manager or person inside of a department, or the CIO or any IT employee in charge. They are responsible for the whole Appstore and therefore capable of executing any necessary actions within the Enterprise App Store scope.

This role allows you to:

  • Create, read, edit & delete applications

  • Create, read, edit & delete versions in state Release, Review and Development

  • Read, edit & delete versions in state Archive

  • Request applications with the App Request feature

  • Move versions between all states (workflow on or off)

  • Read & modify appstore settings (notifications, customizing, languages, support templates, review workflow)

5.5. Organisation User

A user is a created user in Relution which has no further rights than to login. Normally this role is not needed, because a user should be either a device user or an appstore user.

5.6. Organisation User Manager

A user manager can manage all users and groups of his organisation.

This role allows you to:

  • Create, edit & delete users and groups

5.7. Organisation Administrator

An administrator manages the whole enterprise mobility for his organisation including the enterprise appstore, user management and mobile device management features. This role allows the use and configuration of all features of Relution.

This is the super user role and therefore provides you access to all functionality listed above and below.

5.8. Organisation Device Manager

The Device Manager role allows managing the Mobile Device Management component of Relution. Similar to the Appstore Manager, the Device Manager has the full feature set of the Device Management component accessible. (e.g. Creating, editing, deleting of policies, devices and enrollments)

This role allows you to:

  • Modify device management related settings:

  • Customizing

  • Enrollment notifications

  • Certificates

  • Secure Mail gateway

  • General device management settings

  • Control managed devices:

    • Create, edit & delete enrollments for existing users

    • Enroll with an Android or iOS device

    • Manage enrolled devices

    • Apply actions to devices

    • Edit & delete managed devices

    • Create, edit & delete policies

    • Apply & remove existing policies from devices

5.9. Organisation Device User

This role indicates the use of the Mobile Device Management component of Relution. Only users with this role can be enrolled and managed by the Relution MDM. There is also no access to the Enterprise App Store if this is the only role assigned to the user.

This role allows you to:

  • Enroll with an Android or iOS device. An open enrollment for this user has to exist in order to be able to enroll the device

5.10. Creating new users

  1. Login to Relution as “Administrator” or “User Manager”.

  2. Go to settings and choose “Users” from the drop down menu.

image

  1. Press the “Add” button in the left top corner of your screen.

  2. Paste in your data to the shown form.

4b The custom attributes are optional and can be set freely. They are used in policy configurations where they act as placeholders to easily individualize policy configurations.

  1. Enable the Checkbox “Activated” to immediately activate the user after saving.

  2. Press the “Save” button.

image

  1. The new user should appear in the userlist.

5.11. Manage your profile

  1. Login to Relution

  2. Click on your name at the top right corner and choose “Profile”

In the profile overview, you can

  • Edit your profile

  • Change your password

  • As a “Developer”, “Appstore Manager”, or Administrator you can also manage your API access tokens and your SSH keys.

5.12. Edit your profile

  1. Login to Relution

  2. Click on your name at the top right corner and choose “Profile”

  3. Click on “Edit”

  4. Paste in your data to the shown form.

  5. Press the “Save” button.

5.13. Change your password

  1. Login to Relution

  2. Click on your name at the top right corner and choose “Profile”

  3. Click on “Change password”

  4. Enter your new password. Alternatively Relution can automatically generate a password for you which matches your organisation password requirements.

  5. Press the “Ok” button to confirm your new password.

5.14. Create an API access token

To create an API access token do the following steps:

  1. Login to Relution as “Developer”, “Appstore Manager” or “Administrator”

  2. Click on your name at the top right corner and choose “Profile”

  3. Choose “Access tokens”

  4. Click on “Add”

  5. Set a name for your access token

  6. Click the “OK” button.

  7. Save the generated access token. Relution won’t show it anymore. If you forget your access token, you have to generate a new one.

  8. Close the modal.

5.15. Use an API access token

Requests that require an authentication need to set the HTTP header “X-User-Access-Token” to a valid API token.

Each user which are atleast “Developer”, “Appstore Manager” or “Administrator” can create multiple tokens (see “Create an API access token” section).

5.16. Change your start page

  1. Login to Relution

  2. Navigate to the page, which should be your new start page

  3. Click on your name at the top right corner and choose “My startpage”

  4. When you login the next time into Relution, you will directly start in this view.

5.17. Add users to groups

  1. Login to Relution as “Administrator” or “User Manager”.

  2. Go to “Settings” and select “Groups” from the drop down menu.

image

  1. Press the “Add” button on the left top corner of your screen .

  2. Paste in your data to the shown form.

  3. Press “Save”.

image

  1. The new group should appear in the grouplist

5.18. Add groups to organisation groups

Relution is delivered with predefined organisation groups. These consist of the basic roles you can see under roles & groups. Each of these groups have different rights and possibilities.

Every Group in Relution which is created on your own, has to be part of one of the organization groups.

The following description shows how to add a group to one of the organisation groups.

  1. Login to Relution as “Administrator” or “User Manager”.

  2. Go to to “Settings” and select “Groups”.

  3. Select the organisation group you want from the list. You will recognize the organisation groups by the organisation prefix, e.g. “SALES App Reviewer”.

  4. Press the “arrow” button in the group’s line and then the “edit” button on the left side of the groups detail-view.

image

  1. Press the “n member(s) are selected” button and select your group from the modal.

image image

  1. The members and groups of your selected group will appear in the memberlist of the organisation group.

  2. Hit “Save” and your group will be part of one of the organisation groups.

6. Roles Definition

6.1. Read, Create, Delete Versions

image

6.2. Moving Versions (Workflow Off)

image

6.3. Moving Versions (Workflow On)

image

6.4. Settings & Permissions

image

6.5. FAQ

  • Can Reviewer delete REV version? → no, see table

  • Can Reviewer create REV version? → no, see table

  • Can Developer delete REV version? → yes, see table

  • Can Developer create REV version? → yes, see table

  • Deleting last version means deleting the App, what is the logic in case Reviever/Developer wants to delete REV/DEV version and it is the last version? By default only Manager can delete an App? → Deleting the last version means deleting the whole app. this should be the case every time. No `empty' app objects should be possible. So if a developer deletes the last version (in the states they are allowed to delete it) then the app will be deleted too. Role switches

  • What happens if the administrator changes the role of users from x to y? → make sure that all rights are correctly set

7. Common tasks

Relution is executing several automatic background tasks, which are scheduled as one time jobs or recurring jobs. For example, these tasks can be used to handle the system maintenance or create various reports or notifications.

7.1. Certificate expiration notifications

Certificate expiration is executed for all system keystores (see Relution Configuration > Security > Keysore) and all organization APNS certificates (see Relution Portal > Settings > Organization > Certificates).

For any of the above mentioned certificates a notification e-mail is created:

  • 30 days before expiration

  • 7 days before expiration

  • on the day of the expiration

  • repeatedly each 30 days after expiration

Certificate notification types:

  • System keystores are reported to the Keystore Notification Recipients (see Relution Configuration > Other > Common Relution Configuration), because system keystores are used globally and Relution support should be notified

  • APNS certificates with following UIDs com.mwaysolutions.enterprise.mway.relutionclient, com.mwaysolutions.store.relution, com.apple.mgmt.mway.mwaysolutions are reported to the Keystore Notification Recipients. Additionally Relution support should be notified

  • Custom APNS certificates are reported to the organization administrators, because these certificates are organization specific and the organization needs to take action

If the Keystore Notification Recipients are not defined, then a log entry is created instead of the e-mail.

Notes:

  • Relution Configuration can be found at https://[relutionURL]/gofer/gui/ under Administration → Configuration → Show Advanced

  • Relution Portal can be found at https://[relutionURL]/relution/portal/

8. Relution for Education

Relution for Education is a software system for managing tablets (MDM) and apps (MAM) in educational institutions. Being a “made in Germany” solution, Relution pays particular attention to data privacy compliance, for example by avoiding any cloud dependencies.

In addition, Relution for Education provides the following features that are explained in detail in the Relution Manual:

8.1. Guide for education customers (German only)

This document describes how to use Relution in an educational context from a teacher’s / admin’s perspective.

8.2. Apple Device Enrollment Best Practices

This document describes how to enroll iOS devices in DEP and how to configure DEP in Relution / Apple School Manager / Apple Business Manager.

8.3. The Relution Files App for iOS

This document describes how to access Samba (and WebDAV) resources from an iOS device using the Relution Files App.

8.4. Apple Classroom Guide

This document describes how to configure and use the Apple Classroom App with Relution

9. Further Readings

9.1. Apple’s Volume Purchase Program

Link to Apple’s VPP page: http://www.apple.com/business/vpp/

Overview

Apple VPP Business Guide: http://images.apple.com/business/docs/VPP_Business_Guide_USA_EN_Feb14.pdf - General information from Apple about the VP Program

How it works

  1. Enroll

    Enroll in the Volume Purchase Program by creating an Apple Deployment Programs account. You’ll be asked to create a dedicated Apple ID for administering the program and provide basic information about your business. Enroll now: http://deploy.apple.com/enroll/signup

  2. Set Up Set up program administrators who are responsible for purchasing and distributing content for your organization. A program-specific Apple ID will be created for these new administrators. Sign in: http://deploy.apple.com/

  3. Purchase Purchase through the program in three simple steps. First, log in to the VPP store and search for the content you need. Second, enter the quantity you want to buy. And third, complete the transaction with a corporate credit card or VPP Credit. Log in to the VPP store: http://vpp.itunes.apple.com/us/store

  4. Distribute Distribute content to individual users by providing them with redeemable codes for each app or book. Or streamline company-wide distribution by assigning apps directly to users or groups using an MDM solution. Content can only be distributed to users in the same country or region where the app or book was purchased.

How to Purchase, Distribute, and Manage Content

Enroll

To get started, you’ll need to complete the online enrollment process and create an Apple Deployment Programs account with Apple. You’ll also need to verify that you can act as an agent for the program on behalf of your company before completing the enrollment process. Program agents are responsible for agreeing to the terms and conditions for each program they enroll in. And they are also responsible for setting up additional administrators, as needed, to make purchases on behalf of your company.

To begin the enrollment process, go to deploy.apple.com. You’ll need to provide the following:

  • Phone nr., email adress, business adress

  • D-U-N-S number

  • Tax registration information (VAT registration)

Apple will approve your account then.

Set up:

  • Add administrator(s) to your account after sign in.

  • Select apps from (vpp.itunes.apple.com)

  • Choose the quantity.

  • Choose distribution type

  • Managed Distribution (with Relution)

  • Redeemable Codes

  • Pay with VPP Credit, Click&Buy or a corporate credit card

After purchase, Apple takes a few minutes to prepare your order. Wait until you receive email confirmation before continuing to the next step.

Managed Distribution

Available only for iOS7 and higher

  1. Link your MDM solution, by going to account summary and download a token.

  2. Upload this token to Relution (you need to transfer a new token every year)

  3. Invite users (via Relution) via push or email.

  4. Users accept invitation by clicking on the link sended by Relution (example https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/associateVPPUserWithITSAccount?cc=us&inviteCode=XXXXXXXXXXXXXXXXXXXXX&mt=8) and signing in with their private Apple ID (The private Apple IDs are not visible to the adminsitrators.)

  5. Via Relution it is now possible to assign (push) the apps to the users device.

It is possible to assign and revoke the apps to different users. Users can then choose to save the data or to buy a personal copy if an app has been revoked.

Relution Administrators can immediately uninstall the app from the users devices. The users will be granted a grace period before removing the app completely.

Relution does not support redeemable codes for purchasing.

9.2. Making iOS Apps ready for Relution

Checking for Updates

The list of applications is loaded from the Enterprise App Store every time the application is starting. There are two meta attributes transferred for each application which are not displayed inside the application:

RLA - The encoded unique application identifier of the application

RLV - The encoded unique application identifier of the latest version available on the EAS

These attributes originate from the info.plist file inside the .ipa file which is parsed while it was uploaded to the Enterprise App Store.

The attributes themselve become written into the info.plist file by a script which is triggered within the compile process. (as described in the following section)

A mechanism provided by Apple called “URL schemes” is able to determine if an application is already installed and in which version.

To enable this feature, there must be two links created within the application’s code:

rla\{unique application identifier of the application}*://* rlv\{unique application identifier of the application version}*://*

If the url scheme validation of the rla link fails, it is presumed that the application is not installed and thus the “install” button is displayed inside the Relution app. In case the validation is successful and the Relution client recognizes this application as installed, it continues checking the rlv identifier to determine the installed version of the application. If the identifier does not match the previously received identifier of the latest version, the client recognizes the application as older version and displays the “update” button. In the case the identifiers match, the application is seen as latest version and the “open” button is displayed.

It is important to note that it is not possible to explicitly extract the application version and there is no validation if the application provided by the EAS is really newer than the installed one. So this kind of validation only provides the information that a different version than the installed application exists on the device.

The described validation process is done for every application available in the Enterprise App Store. All applications which can be updated are listed in the update section of the Relution application.

The number of available updates is displayed as badge on the application icon of Relution on the device’s homescreen and next to the update menu entry inside the app (iOS). This ensures that the user is always informed about possible updates available.

Creating the script for RLA and RLV URL schemas

In order to recognize previously installed applications on the device, the presence of two url schemes inside the info.plist file (which is contained in the .ipa file) is necessary.

These schemes can be generated by a script which needs to be added to the compile process inside the Xcode IDE. The script can be found in mcap-server/dev-tools/scripts/add_rla_rlv.sh

To use the script please add the script to your project and add a “build phase” like you can see in the screenshot. Do not add this to your target(s).

Copy the following script here:

if [ -f "$SRCROOT/add_rla_rlv.sh" ]; then
  /bin/sh "$SRCROOT/add_rla_rlv.sh"
fi

(Please check if you do not have any blacklines, whitespaces or linebreaks in this code snippet)

10. Known issues

10.1. Migration from 3.x to 4.x

Note

When migrating from Relution version 3.x to 4.x, the following steps have to be performed once:

  1. Stop the Relution service

  2. Rename the Relution directory (i.e. to Relution3)

  3. Unpack the new Relution directory from the downloaded ZIP file

  4. Copy the CONF/sql.conf file to the new Relution directory (create the CONF subdirectory)

  5. Start the Relution service

This will migrate the old conf file to the new application.yml file. Later updates will work by just calling the update script.

Adding config data to the application.yml file

It may be necessary to manually add some some configuration data to the new application.yml file. It is important to keep the indentation intact:

Setting the iOS SCEP signer certificate to the server’s SSL certificate:

    keyStores:
  iOS Signer Keystore:
    _privateKeyWithCertificates_1_pem_urls: [
      'file:/opt/ios_signer.pem',
      'file:/opt/ios_signer.key'
    ]

(this replaces the hard coded certificate in the application.yml file)

Settings for anonymous SMTP with Exchange

relution:
  mail:
    host: YOUR_SMTP_HOST
port: 25
  smtp:
    ttls: false
    ssl:  false
    ehlo: false

Enabling the store orga feature

store:
   enabled: true
   organizationUniqueName: STORE

10.2. Migration from 2.6 to 2.7

App Compliance Policy

There are known limitations when using the app compliance policy in combination with Android devices running Relution 2.6 and below. These versions do not support new settings added to the app compliance policy with version 2.7. We recommend to update all devices to Relution 2.7 as soon as possible.

The following limitations exist:

Uninstall

Relution for Android version 2.6 and below does not support the Uninstall-flag. This flag will be ignored by devices running Relution version 2.6 and below. To get consistent behavior across all devices we recommend to start using this flag only once all devices have been updated to Relution version 2.7.

Black-/Whitelist

Relution for Android version 2.6 and below does not support the black-/whitelist-setting. If a policy is switched from blacklist to whitelist or vice versa, any fields that are shown as disabled will not have their value reset. Relution 2.6 will treat these fields as if they were enabled.

Example:

A policy is set to whitelist, “disable all apps” is visible and checked. If the policy is set to blacklist this field will be hidden, but its internal state will still be checked. Relution 2.7 will treat this field as unchecked. Relution 2.6 will treat this field as checked, since it doesn’t know the policy has been set to blacklist. To work around this issue, always ensure fields are set as desired before changing the black-/whitelist setting until all devices have been updated to Relution 2.7.