purplegreen MDM is being prepared for its first pilot. These pages describe the development release.

Apps and managed configurations

Under Apps in the tenant navigation you find two pages: App catalog and Web apps (Web kiosks and launchers).

The App catalog

The catalog lists the apps your profiles can install: icon, title, package name, kind (public, private or web app), latest version, number of managed configurations, the profiles that use it (links), when it was last read from Google and the last error, if any. Every member can see it; only owners and admins see the buttons to add, refresh and remove.

Adding an app

• Add from Google Play opens the managed Google Play view inside the page. Search, pick the app and select it; the app is read from Google and added to the catalog.
• Add by package name: "For admins who know the package, such as com.example.checkin. purplegreen MDM reads the app from Google Play." If Google does not know the package, the message says: "Google Play does not know this package name. Check the spelling (for example com.example.app); a private app must be published to your enterprise first."

Both dialogs carry the Private apps warning: a private app's package name is bound for good to the enterprise it is first uploaded to (see Private apps: the package name is permanent).

Refresh reads the app from Google again (title, icon, versions, managed properties). If that fails, the old details stay and the error is shown until a refresh works. Remove is refused while a profile still uses the app or one of its configurations: "A profile still uses this app or one of its managed configurations. Remove it from those profiles (Apps tab) and save a new version first."

Only Play Store links to https://play.google.com and icons from Google's image servers are shown; anything else is dropped, and the app shows a letter instead of an icon. If Google's view sends an invalid package name, nothing is added: "Google Play sent a package name that is not valid, so nothing was added. Pick the app again, or add it by package name."

Opening the Play view (or the managed configurations view below) may reload the page once: Google's iframe is only allowed on the Apps pages, so the browser loads the page again and the dialog opens by itself.

The app page

Click an app to see its facts (minimum Android API level, latest version code, when it was read from Google, a link to Google Play), its versions, its managed properties (the settings the app declares, as a read-only tree) and its managed configurations.

Managed configurations

Some apps accept settings from the organisation: a server address, a club code, a device name. On the app page, New managed configuration asks for a name (shown in the profile's Apps tab, for example "Club Gent") and how to edit the values:

1. Here, with a form from the app's managed properties. The form follows the app's settings: a checkbox for yes/no, a text field for text (with an Insert variable menu, see below), a number field, a select for a choice, checkboxes for a multiple choice, nested groups, and repeatable groups ("Each item of the list has these fields"). Mistakes are marked with "!" next to the field while you type; the server checks again when you save.
2. An iframe template in Google's managed configurations view: "An iframe template is edited in Google's managed configurations iframe and stored at Google; purplegreen MDM keeps only its id (mcmId). Variables such as $DEVICE_SERIAL_NUMBER$ work only in configurations edited here, not in templates." If the view sends a template id that is not a number, nothing is saved: "The managed configurations iframe sent a template id (mcmId) that is not a number, so nothing was saved. Save the template in the iframe again."

The keys __proto__, constructor and prototype are refused anywhere in a configuration. An app that declares no settings gets a plain JSON editor with the notice Unverified schema: "This app publishes no managed properties, so purplegreen MDM cannot check the keys or value types (unverified_schema). Use the keys the app vendor documents; a wrong key is ignored by the app."

No passwords

Values are stored and shown in clear. When a key looks like a password, token or secret (also kiosk codes such as kioskPin, exitCode, adminCode, unlockCode, a PIN, passcode or one-time code; not postal_code or zipCode), the form shows Looks like a credential: "Managed configuration values are stored and shown in clear text and reach every tablet that runs the profile. A key that looks like a password, token or secret needs your confirmation." Saving needs the checkbox "I understand: these values are stored and shown in clear text"; the confirmation is recorded in the audit log with the key names (not the values). Prefer giving apps their credentials another way (for example by pairing).

A configuration that a profile version still uses cannot be deleted: "A profile version still uses this managed configuration. Pick another configuration in those profiles (Apps tab) and save a new version first."

Variables: one configuration for every tablet

The Insert variable menu adds these placeholders to a text value:

Any other $...$ word is refused.

Names inside web addresses. Tablet, site and profile names are typed by people (a site manager can rename tablets and sites) and are inserted exactly as typed. Inside a web address (for example https://club.example.com/?name=...) use the _URL variant, which encodes spaces and special characters. When a setting whose name or title mentions "url" or "uri" uses a plain name placeholder, the editor warns: "$DEVICE_NAME$ is inserted as typed (untrusted, not URL-encoded); inside a URL use $DEVICE_NAME_URL$". The warning does not block saving. Example: a club check-in app takes club_host, pairing_code, device_serial, device_name and site_name; setting device_serial to $DEVICE_SERIAL_NUMBER$ gives each tablet its own serial.

Choosing a configuration and update mode in a profile

On the profile's Apps tab, the kiosk app and each extra app have:

• Managed configuration: "Settings the app reads at start, from the App catalog. None: the app uses its own defaults." The list shows the configurations of that package; links lead to the catalog or to create a configuration.
• Update mode: "Use the profile default (Updates tab)", Default (inside the maintenance window), High priority (ignores the window) or Postponed (up to 90 days). "Default follows the maintenance window (Updates tab); High priority updates as soon as an update is published, even during opening hours; Postponed waits up to 90 days."

When a selected configuration uses a device variable, the tab shows Per device: "This profile compiles to one policy per device: a device variable ($DEVICE_SERIAL_NUMBER$, $DEVICE_ID$ or $DEVICE_NAME$) differs on every tablet." The compile preview then warns "Device variables filled in per device"; that is expected.

On the device page

The Managed configuration panel shows the kiosk app's configuration of the profile the tablet runs: its name (linking to the app page), the update mode, and "Managed configuration values for this tablet" with the variables filled in for this tablet, the original placeholder shown next to each filled-in value. The filling-in on this page is for display; the tablet gets the values from its policy. Without a configuration the panel says "None (the app uses its own defaults)".

What a per-device policy means

As long as a profile only uses site and organisation placeholders (or none), all tablets of a site share one policy. As soon as one of its configurations uses $DEVICE_SERIAL_NUMBER$, $DEVICE_ID$, $DEVICE_NAME$ or $DEVICE_NAME_URL$, every enrolled tablet gets its own policy (pre-registered tablets that have not enrolled yet use the shared one):

• The device count does not change: Google's device quota counts enrolled tablets, not policies, so 100 tablets are still 100 devices.
• There are as many policies at Google as tablets on that profile, and changing the profile updates each of them. For 100 to 500 tablets this stays well within Google's limits; updates take a little longer because we send at most five at a time.
• Renaming a tablet updates its policy (for $DEVICE_NAME$).
• Limit: at most 200 tablets per organisation can have their own policy (the operator of purplegreen MDM can change the number). A change that would go over it is refused and nothing is saved, with the message "This change would give N enrolled devices their own policy (a managed configuration uses a device variable); the limit is 200 per tenant". This can happen when you activate a version, change a configuration, point a site or the organisation default at another profile, or change, move or retire tablets (also in bulk). What to do: use the device placeholders on fewer tablets (for example only in the profile of the sites that need them), use site placeholders where a per-site value is enough, or ask the operator to raise the limit. If an organisation is already over the limit, the oldest tablets keep their own policy and the newest ones stay on the shared policy until there is room.
• A tablet that is just enrolling first gets the shared policy with the placeholders unfilled, then its own policy a moment later.

Who may do what