Monthly Archives: April 2015

Reviewing Office 365’s MDM Capabilities

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.


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: and

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


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.

Overview built-in Mobile Device Management for Office 365

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

Dirsync soft matching vs hard matching

I recently was asked to advise on how cloud identities can be converted to federated identities such that when Dirsync is ran, the on-premises Active Directory becomes the new source of authority.

Dirsync 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.

In those cases, the work-around is to use a “hard match” technique. This is performed by updating the cloud identities to use the same user principal name (UPN) as the on-premises AD account. This is performed in Windows Azure Powershell for Office 365 with this command:
Set-MsolUserPrincipalName -UserPrincipalName [email protected] -NewUserPrincipalName [email protected]

Without doing this step, Dirsync will create a duplicate object in the cloud. The second step is to update the immutableID value of the Office365 object to match the on-prem ObjectGUID. This is where it gets interesting. You can find out the ObjectGUID easily enough with the get-Aduser powershell command. However, this is not in the format expected by O365 and therefore must be converted. There is a free script available to perform the conversion available on the Technet Gallery (here). You can also use the Quest Powershell module for Active Directory and follow the steps in this blog post (here).

Now in Windows Azure Powershell for Office 365 you can run this command:
Set-MsolUser -UserPrincipalName [email protected] -ImmutableId RDHiRneDPkiofrZ2nbYu7Q==

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

[Update 1/29/2016 – big lesson learned here is that if the cloud identity ever pre-existed from a previous dirsynced 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]