Exchange and Exchange Online have had decent mobile management capabilities through ActiveSync policies prior to the March 30th 2015 announcement of new MDM capabilities for Office 365.  For example, using Activesync you could require a pin to unlock a smartphone after a period of inactivity, wipe a device, and a few other options. You could automatically quarantine new devices that attempted to connect to ActiveSync.

This blog post is a review of the newly announced MDM capabilities in O365.

• Conditional Access—You can set up security policies on devices that connect to Office 365 to ensure that Office 365 corporate email and documents can be accessed only on phones and tablets that are managed by your company and are compliant. Behind the scenes, Office 365 leverages Microsoft Intune and the Microsoft Azure Active Directory to deliver this capability. The Conditional Access policies apply to Office applications such as Word, Excel, PowerPoint and other business applications—making management easier for admins while ensuring users can securely work with their preferred productivity applications.
• Device management—You can set and manage security policies such as device-level pin lock and jailbreak detection to help prevent unauthorized users from accessing corporate email and data on a device when it is lost or stolen. Additional settings and rich reporting are also available within the Office 365 admin center so you can gain critical insights about devices accessing your corporate data.
• Selective wipe—You can easily remove Office 365 company data from an employee’s device while leaving their personal data in place. This is an increasingly important requirement as more businesses adopt a “bring your own device” (BYOD) approach to phones and tablets.

Requirements

You can use MDM for Office 365 to manage many types of mobile devices like Windows Phone 8.1, Android version 4+, iOS devices running version 6+.  Management of BlackBerry devices isn’t supported by Mobile Device Management for Office 365, but you can still use the free BlackBerry Business Cloud Services (BBCS) from BlackBerry to manage BlackBerry devices.

To manage mobile devices used by people in your organization, each person must have an applicable Office 365 license and their device must be enrolled in MDM for Office 365.

How it works

The following diagram shows what happens when a user with a new device signs in to an app that supports access control with MDM for Office 365. The user is blocked from accessing Office 365 resources in the app until they enroll their device.

Policies and access rules created in MDM for Office 365 will override Exchange ActiveSync mobile device mailbox policies and device access rules created in the Exchange admin center.

Getting Started

You first need to Activate MDM for your Office 365 Tenant. As of 4/17/2015 – this has not been rolled out to all tenants. You’ll know when your tenant has this capability when you are able to go to Office 365 admin center > Mobile Devices, and then select Get started to kick off the activation process. It may take some time before the service is ready. When it’s done, you’ll see the new Mobile Device Management for Office 365 page.

Update: As of 5/20/15, MDM is starting to appear in Office 365 tenants. Check out Sean McNeil’s blog posts on this topic for a walkthrough:

office365evangelist.com/?p=2487 and office365evangelist.com/?p=2502

Want More?

Microsoft Intune, part of the Microsoft Enterprise Mobility Suite, provides additional capabilities including the ability to restrict the cut, copy, paste and save as functions in the Office Mobile and OneDrive for Business applications.

Intune also provides the ability to provision and manage certificates, Wi-Fi, VPN (device and app-specific), and email profiles automatically for devices that enroll, enabling users to access corporate resources with the appropriate security configurations.

 

Management Capabilities

The Office 365 MDM management capabilities include the following:

• Wipe an entire device or Selectively wipe Corporate Data while leaving personal data intact
• Block unsupported devices from accessing Exchange email using Exchange ActiveSync
• Configure device policies like mobile device password requirements and security settingsView list of blocked devices
• View what policies have been applied to a device
• Unblock noncompliant or unsupported device for a user or group of users
• Generate detailed report to see devices that are not compliant

Summary

The new Office 365 MDM capabilities allow you to manage the “Office Mobile”, “OneDrive for Business” and Exchange Activesync features by requiring a device to be enrolled and compliant with policies.

References:
Overview built-in Mobile Device Management for Office 365

Choose between Microsoft Intune and Built-in MDM for Office 365

I recently was asked to advise on how cloud identities can be converted to federated identities such that when Azure AD Connect is run for the first time, the on-premises Active Directory takes over as the source of authority. The benefit of doing this is the user would have a single username and password, eliminating the need to have a different password for Office 365 when they already have one for Active Directory. This becomes complicated when an existing tenant exists and users have adopted various things like Teams. In my experience, a license bundle is assigned to the user which includes an Exchange Online license, which then creates a mailbox in the cloud, when the user already has one on-premises.

So how do we merge identities between Active Directory and Azure AD? In some cases, Azure AD will automatically match things (this is known as soft match).  However, when attributes do not line up then what ends up happening is a duplicate account gets created during the first synchronization. This is preventable through a technique known as hard matching, where we force the two objects to merge during the first synchronization.

Azure AD Connect will attempt a soft match if the primary email address attribute exists on both sides AND (the immutable ID matches the ObjectGUID on-premises OR the cloud immutableID is empty) <- see note below for an explanation why this matters. This is best documented on MS KB 2641663 and on Stephanie Kahlam’s blog (here).

However, what if the cloud identity is not enabled for Exchange Online? In that case, there is no primary address for a cloud identity to use for soft matching. For example, if the user was only configured for CRM Online or another O365 service. You could then make the UPN the same on both sides, Azure AD Connect will soft match on UPN too. This is explained in Microsoft documentation (here). This is performed in Windows Azure Powershell for Office 365 with this command:
Set-MsolUserPrincipalName -UserPrincipalName [email protected] -NewUserPrincipalName [email protected]

In scenarios where neither of those options work, then the only remaining option is to either blow away the cloud account or force the cloud account to use the same Immutable ID as the on-premises AD ObjectGUID (after it is converted into the proper format). This is known as a “hard match.”

In one case, I don’t know why, I had to make the UPN match on both sides, and the hard match too, otherwise I found a duplicate object was getting created in the cloud.

Hard Match “How TO”

To update the immutableID value of the Office365 object to match the on-prem ObjectGUID, you use the get-Aduser powershell command (this is installed on most Domain Controllers and can be installed on member servers). The format of the ObjectGUID must be converted to Base64. You can download the script I use to perform this (here).

Then once you get the ObjectGUID converted, you can run this in Azure AD PowerShell to perform the hard match:
install-module msonline
connect-msolservice
Set-MsolUser -UserPrincipalName [email protected] -ImmutableId RDHiRneDPkiofrZ2nbYu7Q==

Then force Azure AD Connect to run and that should convert the cloud identity to be sourced from on-premises Active Directory.

If the cloud identity ever pre-existed from a previous synced existence (for example, if prior to an ADMT migration, if the account originated from a separate AD forest than where the account exists presently) then soft match will never work – it will throw a bogus error about duplicate proxy addresses in the MIIS GUI. The only solution is to hard match by updating the cloud identity with the new on-prem ObjectGUID (following conversion from the steps above]

Another tip: if the account was being used heavily for Teams, SharePoint, OneDrive, PowerBI, or other cloud workloads, you may want to only remove the Exchange license, however, that still leaves the MailboxGUID from the account left on the object. The only way to clear that from the cloud user is to connect to Exchange Online PowerShell and run this command:

install-module exchangeonlinemanagement
connect-exchangeonline

Set-User [email protected] –PermanentlyClearPreviousMailboxInfo