Planning for a New Organisation

This article provides a rough checklist of topics that you may need to consider before creating an organisation. This is relevant both for organisations planning to subscribe to the EMM service, and for those planning to provide the service as a master organisation or service vendor. Depending on your business relationship, you may need to define the requirements in detail. In a more flexible relationship, if you believe that the defaults are a safe starting point, you can just rush to create the organisation and then consider these topics as needed.

Most of the plan is realised in creating the organisation, described in Master/Vendor Guide, and in the initial setup, as described in Initial Setup Tasks for New Organisations.

The topics to consider are as follows:

Basic Requirements

The basic information needed for creating an organisation are its name and ID. The organisation ID is most visibly used for logging in to the service portal and it shows up in an EMM client. It should remain the same, so it should be proper, simple, and descriptive.

Other aspects to consider:

• Expiration of the service subscription for the organisation; this is a case of agreement with the service vendor.
• Number of active device licenses
• Should the number of devices for each user be limited?
• Which service features should be enabled?
  • Synchronisation: calendar, address book, file backup, and backup quota
  • Managed Google Play

Regarding service licenses, you also need to decide the number of active device licenses. You should also consider whether to limit the number of devices for each user.

An organisation is created by a service vendor or a master organisation, so making the basic organisation setup is described in Master/Vendor Guide.

Grouping Users and Devices

End users of the EMM service always belong to an organisation. Such an organisation is typically a work organisation, but you could also have individual subscribers, in which case they would need to belong to a virtual organisation.

Much of the planning and service configuration depends on recognising the different groups of users and their special requirements. To group users within an organisation, you can use organisation units. For business organisations, the units could be functional units or job roles, such as management, technical support, sales, etc. Different functional units or roles could need different permissions, applications, and so forth. Organisation units can, however, be used for any grouping of users; another dimensions could be locations, languages, and so forth. Users or actual units could be located in different countries and require different locale settings, applications, contact information, translations of messages, and so forth.

See Organisation Units for further details on configuring them. The purpose of organisation units is to group users, and as such only have very limited settings. More relevant settings are done in user account templates, which can be associated with organisation units. Organisation units can be applied in compliance rules, as well as for selecting users to execute mass operations on them. For example, you could select all the users belonging to an organisation unit and edit their addresses or any other settings.

Further, grouping devices is separate from user grouping through organisation units, and devices have similar device groups. Again, device groups are only used for grouping and actual shared device settings are defined in device templates.

In the following, we look at an example with three dimensions (functional unit, location, and language). For device settings, the office location of a device owner is not considered relevant, but ownership affects many of the settings on the devices. Notice that it is not meaningful to give templates for all possible combinations, only the most common ones, and uncommon cases can be edited manually.

In the example, managers are offered a CYOD model with only Android devices, perhaps with some additional enterprise security requirements. Other workers are allowed a more flexible BYOD model, except for delivery workers, who get COBO devices. See the introduction videos in the Account Templates and Device Templates to see how they are configured, and New User and a Device for how a new user and a device are created from the templates.

Device Ownership Scenarios

What king of device ownership scenario or scenarios will the organisation have? Will the devices be personally owned by the users (BYOD or CYOD) or are they company-owned (COPE or COBO), or both? Would personally owned devices be chosen from a set of allowed devices (CYOD)? For company-issue devices, will using for personal use be allowed (COPE) or not (COBO)?

Will the some or any of the devices even be personally assigned? COBO devices that are assigned to work groups, labs, rooms, or vehicles would not be, and they could rather be managed as tools.

To which extent should the users be managing the devices, that is, what would be the extent of Managing Your Own Device (MYOD)? User access rights for the self-service portal can be used for restricting self-management.

The models are described in the Product and Platform Introduction.

Business-Owned Devices

The lifecycle of business-owned devices begins with provisioning. In the COPE model, users often make personal setup for the device first and then handle provisioning themselves using an installation code or at technical support.

Personal and Work Separation

EMM solutions such as Android for Work (Android EMM) and Samsung KNOX enable separation of personal and work applications and data.

Attributes of Device Owners

You can have different default settings for different types of users, often following the organisation structure and roles, as well as the device ownership model. The settings are defined in user account templates, which may follow the organisation structure, but further define what features are enabled for different types of users.

• Organisation units
• Default portal settings
  • How to handle incorrect logins
  • Language – what languages are supported in different locations
  • Time zone
  • Name policy (whether "Firstname Lastname" or something else)
• Access rights
  • User configuration (name, address, etc)
  • Device management
  • Lock/unlock/wipe device
  • Install applications
  • Access shared files
  • Etc.
• Features
  • Data synchronisation (contacts, calendar, files, etc)
  • Portal UI features
• File sync quotas

See Account Templates for further details, especially the User Editor that describes the various user (device owner) settings.

Who Manages?

An organisation can either be managed by people in the organisation or by the master organisation or service vendor.

If the organisation manages its own configuration and users, it will have at least one organisation manager, although more typically there is more redundancy. The organisation managers can take different roles, such as for registering users at technical support or help desk, and a device installer, whose main job is to provision devices for using the EMM service.

Some management tasks can be given to the device owners themselves, following the Manage Your Own Device (MYOD) model. It typically includes installing and provisioning the device and managing through the self-service portal. The model can even include self-registration in the service, for the user account as well as devices.

See Manager Accounts for further details on configuring the managers.

WLAN/WiFi and Network

EMM is not only device management and synchronisation, but includes how mobile devices connect to mobility infrastructure through mobile phone and company WLAN networks.

For WLAN, you can set up device policies for company access points. They are made in the device settings (see Device Editor, Network→WLAN/WiFi AP). When planning for the organisation, you should consider what its WLAN network structure is

For mobile connectivity, you can consider which mobile networks to enable and their parameters. You will need the APN settings to configure them. This is mostly for the COPE/COBO models, as in BYOD models users generally use their personally subscribed network. You also may consider roaming policies if you want to prohibit different traffic (data, WAP PUSH, synchronisation, or voice calls) when roaming.

Service Integrations

You should consider which service integrations you are going to need.

Email (IMAP, POP)

Used for sending and receiving email. In the BYOD model, the device owners have already set up their personal email accounts, but you can configure additional company email addresses through the device settings. In a COBO model, you can set up the company email in the device settings.

Exchange ActiveSync (EAS)

Used for synchronising contacts, addressbooks, etc. It requires any of EAS service implementations.

LDAP/ADDS

These are often used for user authentication.

VPN

Configure access to company VPNs.

Security Policies

You may need to plan which sort of security policies should be enabled.

Device Policies

Different device brands support different sets of security policies.

In the following we have some policies:

• Password policies – You can set up various requirements for password protection
• Device encryption – You can set up and enforce device encryption
• Location policy – whether GPS or network positioning should be disabled
• Location monitoring – normally location is acquired only on request, but you can configure regular reporting of the location
• Geofencing – whether using the devices should be restricted to a geographical area and locked or wiped if taken outside

Compliance

You can make a number of compliance requirements, which you can check, and enforce if necessary. Enforcing compliance is most typical for COBO models, but you can use the settings also to monitor the devices for possible problems.

Enterprise Requirements

Applications

An organisation may require, offer, or prohibit certain applications. Such applications can be free or commercial, and purchased either by the device owner or the organisation.

For commercial apps on iOS, you may want to opt to the Volume Purchase Programme, which allows purchasing large number of licenses to apps.

For Android, Google Play offers similar options for purchasing apps in bulk. Managed Google Play allows customising Google Play for COBO environments. See Google Play for how it will look like and Setting Up Managed Google Play for how to set it up.