Known issues

Migration from 3.x to 4.x

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:
    starttls: false
    ssl:  false
    ehlo: false

Enabling the store orga feature

store:
  enabled: true
  organizationUniqueName: STORE

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.