Office 365 Mobile Device Management – Managing Device Policies

Managing device policies for Office 365 Mobile Device Management is performed in the Unified Compliance Console. If you’re already logged in to the Office 365 admin portal you can navigate to the Mobile section and click the link to “Manage device security policies and access rules.”

Note, before you begin managing device policies should have already performed the initial setup for Office 365 MDM.

In the Device Management view you’ll see a list of device policies that are already configured. There are no default policies created when you enable Office 365 MDM, so if this is your first look at this page then it’s likely you’ll see an empty list.

There are two types of controls that you can apply:

• Organization-wide default policies
• Device policies targeted at groups of users

Office 365 Mobile Device Management policies are targeted at security groups. Before you begin configuring policies I recommend you create security groups in Office 365 to be used for policies.

Configuring Organization-Wide Policies in Office 365 MDM

Click the link to “Manage organization-wide settings for device access management.” Here you can decide whether to allow or block unsupported devices from accessing email when they are targeted by an MDM device policy. If your organization is going to require mobile device management for all connecting devices then may consider configuring this to “Block“.

However, there are always exceptions to these types of rules. Perhaps you are currently in the testing or pilot phase of your Office 365 MDM project, and do not want to enforce a setting that my disrupt other users while you complete your testing. Or perhaps you want to allow your users time to enrol in MDM before cutting off their regular ActiveSync access. In that case you may wish to leave the setting as “Allowed” for now.

In August 2015 Microsoft announced a new user experience for this scenario that will send the user a system-generated email when they are blocked. The email explains why the device was blocked and guide them towards installing the Company Portal app to enrol their device. This feature will be rolling out over a period of several weeks so you may not see the new user experience in your tenant yet.

If you do want to block unsupported devices you might still have some scenarios where a block is not desirable. For example, you might have a VIP user who has received an exemption for their preferred device that happens to be unsupported. In these cases you can specify a group of users who are excluded from access control.

Note that before you can add a group to this exclusion list you need to have created the group in Office 365 already. Also be aware that the group picker will show no groups at first even if you have groups in your Office 365 tenant, and you need to do a search on a keyword before any groups will appear.

Creating a Device Policy in Office 365 MDM

To create a device policy click the “+” icon in the Device Management section of the Compliance Center.

Give the policy a name and description. You may find it makes administration easier if you name the policy to match the name of the security group it will be targeted to.

The first set of policy items will look familiar to anyone who has configured ActiveSync mobile device policies before. They contain the most common settings that organizations worry about such as requiring a PIN/passcode, requiring a minimum length or complexity for the PIN/passcode, inactive lock timeout, and device encryption.

You’ll also notice the setting to “Prevent jail broken or rooted devices from connecting.” This is not available in ActiveSync policies, only in Office 365 MDM device policies, and it is a good idea to enable it.

We also have options for requiring management of the email profile. This is available on iOS only at this stage, and is what enables selective wipe (only wiping the corporate email data, not any personal data). If the user has an existing email profile on the device that profile will stop working and will need to be deleted so that the managed profile can be applied.

The final setting is to choose whether to block or allow access for devices that do not meet the requirements of your policy (for example a PIN/passcode that isn’t long or strong enough). Remember that anybody in the exception group you configured earlier will not be blocked by this setting. Also keep in mind that users will be blocked for any non-compliance with your new policy, no matter how trivial that particular setting may be in the overall scheme of things. If you want to get a sense of how compliant or non-compliant your users’ enrolled devices are before you start blocking the non-compliant devices then you should set the action below to “Allow access and report violation.”

On the next page are additional security policies that you can configure for backups, data leakage, and application installs. Requiring encrypted backups is a common requirement to protect sensitive data that may be backed up to users computers. Blocking screen capture is one method of making copying or data leakage more difficult (but not impossible).

For demonstration purposes I’m going to enable blocking of the application store in this policy.

Next we can decide whether to apply this policy now or later. I’ve chosen to apply the policy now to a group I created earlier. Again, be aware that the group picker will show no groups at first even if you have groups in your Office 365 tenant, you need to do a search on a keyword before any groups will appear.

Click Next to see a summary of your Office 365 MDM device policy and then click Finish.

The new policy will have a status of “Turning on…” for several minutes, before it displays a status of “On” when it is ready.

Seeing an Office 365 Device Policy in Action

Let’s take a brief look at the new policy in action. Back in the Office 365 admin center in Mobile Devices we can see that there are no managed devices at the moment.

I’ve added the user “Mike Ryan” into the “Standard MDM Policy” group that is targeted by my “Standard MDM Policy” policy. Mike uses an iPhone 4S and has his email account set up in the native Mail app as well as the Outlook app, and is using the OneDrive app to connect to his OneDrive for Business to access documents. He has no other Office Mobile apps installed at this time.

Mike’s native Mail app stops receiving new email, and the next time he attempts to use the Outlook app he receives a login error.

After logging in again Mike is presented with a notice that he needs to enrol the device before he can access any corporate data.

Tapping the “Enrol” button takes Mike to an Intune company portal page instructing him to download the Company Portal app if he doesn’t already have it.

Mike can download the Company Portal app from the iTunes Store (the policy targeted at Mike blocks the app store, but he’s not enrolled yet so he can still access the store), open it, and sign in with his company credentials.

The enrolment process takes a few minutes and there’s several steps where interaction by the user is required (mostly just tapping a button to continue). It’s the type of thing that some users will struggle with, so you would need to have prepared them for this with some communication and educational materials, and have your help desk staff trained up and ready to assist as well.

After Mike’s device has been enrolled he can go back to the Outlook app and sign in again to try and access his email. If there are any issues with his device that make it non-compliant a message will be displayed and he can find out what to do about it.

In this particular case the existing email account for the native Mail app is causing the device to be non-compliant, because the device policy requires that the email profile be managed by Office 365.

Removing the email profile from iOS and waiting a few minutes allows Office 365 MDM to install the managed profile, bringing the device into compliance. The Mail app, Outlook app, and OneDrive app are all able to sign in and access corporate data.

However, all of that would not be very intuitive for a typical end user. I can definitely see that there would be some support required to assist users with enrolment and compliance when Office 365 MDM is being rolled out to an organization. It would certainly be worth considering the less aggressive approach to policy deployment of allowing non-compliant devices to connect and using the compliance reports to identify and remediate as many non-compliant devices as possible before turning on the block controls.

As a final note, by blocking application stores with my device policy Mike is now prevented from installing apps to his device from the iTunes App Store. He didn’t already have the other Office Mobile apps such as Word and Excel installed, and now he can’t install them. You can see that the Company Portal app has sections for publishing company apps as well as apps in public marketplaces like the iTunes App Store, however this Mobile Application Management (MAM) capability is not included in the built-in Office 365 MDM. It is available in the full Intune service though.

Summary

As you can see the process for configuring device policies is not particularly complicated, however there are some important decision points that will impact the user enrolment and ongoing experience in various ways. Thorough testing and piloting is recommended before you begin targeting policies at live users, and less aggressive settings of “allow but report” may be preferable for many deployments.