Multi-identity in the managed Outlook app – Part 2

This blog post will show the behavior of the multi identities in the Microsoft Outlook app, as described in my posts about multi-identity in the managed Outlook app – part 1 and the Microsoft Intune Managed Browser. I’ve made four small movies that will show the behavior of the Microsoft Outlook app. A general note with these movies is that they’ll start to blink and act all funny at the moments that a managed app is opened, or a when a PIN is required.

Part I – Install and configure the Microsoft Outlook app

In this first part I’ll show how the Microsoft Outlook app behaves during the installation and initial configuration. During this movie I’ll go through the following actions:

  • Open the Company Portal app;
  • Install the Microsoft Outlook app;
  • Open the Microsoft Outlook app;
  • Configure the PIN.

Part II – Open URLs in the Microsoft Outlook app

In this second part I’ll show how the Microsoft Outlook app behaves with opening URLs. During this movie I’ll go through the following actions:

  • Open the Microsoft Outlook app;
  • Open a blocked URL from company email;
  • Open an allowed URL from company email;
  • Open an URL from personal email.

Part III – Copy and paste content in the Microsoft Outlook app

In this third part I’ll show how the Microsoft Outlook app behaves with copying and pasting content to different apps. During this movie I’ll go through the following actions:

  • Open the Microsoft Outlook app;
  • Copy content from company email;
  • Paste the content in an unmanaged app;
  • Paste the content in a managed app;
  • Copy content from personal email;
  • Paste the content in any app.

Part IV – Open and save attachments in the Microsoft Outlook app

In this fourth part I’ll show how the Microsoft Outlook app behaves with saving attachments. During this movie I’ll go through the following actions:

  • Open the Microsoft Outlook app;
  • Open an attachment from company email;
  • Save the attachment;
  • Open an attachment from personal email;
  • Save the attachment.

Multi-identity in the managed Outlook app – Part 1

Microsoft_OutlookThis blog post can be seen as a follow up about a previous post about the email profile behavior after retiring a mobile device. During that post I showed the behavior of email profiles in the native mail app and the Outlook app after retiring the mobile device. In this post I’ll dive deeper into the Outlook app. More specifically, the behavior of the managed Outlook app and multi-identities. To be complete, I’ll divide this blog post in two parts. This first part will describe the assumptions, the configuration and the behavior and the second part will show the behavior in a real example.

Assumptions

During this blog post I’ve done four important assumption, about the used environment, that might impact the test results. When these four items are not in place, the results might differ from the results in this blog post. The key is that these four items create a fully managed Outlook app for company email.

  1. Office 365, including Exchange Online, is in place for the company email;
  2. Microsoft Intune hybrid, or standalone, is in place for managing the mobile devices;
  3. Conditional access is used to provide access to the company email;
  4. Application management policies are in place to protect the company email.

Configuration

During this blog post I’ve used the configuration, for the managed Outlook app, as shown in the pictures below. These pictures are taken from a Microsoft Intune hybrid environment, but the settings that can be configured are identical to the settings that can be configured in a Microsoft Intune standalone environment.

iOS Android
iOS_AppManagementPolicy Android_AppManagementPolicy

Behavior

One key takeaway about the behavior is a difference in the behavior of the Outlook app for iOS and the Outlook app for Android.

If a PIN requirement is configured, the Outlook app for iOS will always prompt for a PIN.

It will even prompt for a PIN during the initial startup. On the other hand, if a PIN requirement is configured, the Outlook app for Android will only prompt for a PIN after a company email profile is configured.

Besides that key difference the behavior of the Outlook app for iOS and the Outlook app for Android will be identical. Based on the configured managed application policy the end-user will experience the following behavior.

Setting Company email Personal email
Restrict web content to display in the Managed Browser

The end-user will experience that an URL will open in the Managed Browser.

Note: When the Managed Browser is used with an allow list, the URL has to be part of that list.

The end-user will experience that an URL will open in the default browser.
Prevent Android backups (Android only)1 The end-user will not experience anything special. The end-user will not experience anything special.
Prevent iTunes and iCloud backups (iOS only)1 The end-user will not experience anything special. The end-user will not experience anything special.
Allow app to transfer data to other apps The end-user will experience that data can only be transferred to other managed apps. The end-user will experience that data can be transferred to any other apps.
Allow app to receive data from other apps The end-user will experience that data can be received from all other apps. The end-user will experience that data can be received from all other apps.
Prevent “Save As The end-user will experience that the “Save As” option is missing for attachments. The end-user will experience that the “Save As” option is available for attachments.
Restrict cut, copy, and paste with other apps The end-user will experience that content and attachments can only be copied and pasted to other managed apps. The end-user will experience that content and attachments can be copied and pasted to all other apps.
Require simple PIN for access (including number of attempts before PIN reset) The end-user will experience that a PIN is required for access.

iOS – The end-user will experience that a PIN is required for access.

Android – The end-user will experience that a PIN is not required for access.

Require corporate credentials for access The end-user will experience that corporate credentials are required for access.

iOS – The end-user will experience that corporate credentials are  required for access.

Android – The end-user will experience that corporate credentials are not required for access.

Require device compliance with corporate policy for access The end-user will experience that there is no access when the device is jailbroken (iOS) or rooted (Android). The end-user will experience that there is always access.
Recheck the access requirements after timeout and offline grace period3 The end-user will not experience anything special. The end-user will not experience anything special.
Encrypt app data4 The end-user will not experience anything special. The end-user will not experience anything special.
Block screen capture(Android only) The end-user will experience that the screen capture option can’t be used. The end-user will experience that the screen capture option can be used.

1 This setting would make sure that the backup of the Outlook app is disabled, but, by default, the Outlook app already doesn’t perform online backups.
2 This setting will make sure that the access requirements for the Outlook app are checked again after the specified timeout and grace period.
3 This setting will make sure that all data associated with the Outlook app will be encrypted. On iOS the data is encrypted at rest using the device level encryption of iOS and on Android the data is encrypted during file I/O operations via encryption provided by Microsoft.

More information

For more information about controlling managed apps, please refer to the following links:

Email profile behavior after retiring a mobile device

Microsoft_OutlookThis blog post will be a follow-up on my blog post of last week about the three layers of protection with conditional access for Exchange email. During that post I tried to stress the importance of protecting, and being in control of, company email. In this blog post I will go through different scenarios to show the behavior of company email after retiring a mobile device from Microsoft Intune. I will show the results of these scenarios for both the native email app and the Outlook app.

Scenarios

Before I start with the different scenarios it’s important to mention that, after a mobile device is successfully retired from Microsoft Intune, the user will be able to configure company email on its mobile device. This is due to a default cache on Exchange. It might take up to, somewhere between, 6 and 24 hours before Exchange will re-check the device. For more information about this, please refer to this forum discussion.

Scenario 1: Email profile and the native mail app

In this scenario the Email Profile that’s configured by Microsoft Intune, is used in the native mail app.

Result after retiring mobile device
1 The Email Profile for the native mail app is successfully removed

Scenario 2: Email profile, the native mail app and additional personal email account

In this scenario the Email Profile that’s configured by Microsoft Intune, is used in the native mail app. Besides that, an additional personal email account is manually configured in the native mail app.

Result after retiring mobile device
1 The Email Profile for the native mail app is successfully removed
2 The additional personal email account is still available in the native mail app

Scenario 3: Email profile, the native mail app and the Outlook app

In this scenario the Email Profile that’s configured by Microsoft Intune, is used in the native mail app. Besides that, the same company account is manually configured in the Outlook app.

Result after retiring mobile device
1 The Email Profile for the native mail app is successfully removed
2 The same company account is removed from the managed Outlook app.

Scenario 4: Email profile, the native mail app, the Outlook app and additional company account

In this scenario the Email Profile that’s configured by Microsoft Intune, is used in the native mail app. Besides that, the same company account and an additional company account are manually configured in the Outlook app.

Note: Via the default mail app it’s not possible to configure multiple company accounts. The default mail app will require enrollment of every company account that’s used for configuring company email.

Result after retiring mobile device
1 The Email Profile for the native mail app is successfully removed
2 The same company account is successfully removed from the Outlook app
3 The additional company account is still available in the Outlook app, but will require the device to be re-enrolled

Scenario 5: Email profile, the native mail app, the Outlook app and additional personal account

In this scenario the Email Profile that’s configured by Microsoft Intune, is used in the native mail app. Besides that, the same company account and an additional personal account are manually configured in the Outlook app.

Result after retiring mobile device
1 The Email Profile for the native mail app is successfully removed
2 The same company account is successfully removed from the Outlook app
3 The additional personal account is still available in the Outlook app

Conclusion

I probably could have created even more scenarios to test behavior of company email, after retiring a mobile device from Microsoft Intune, but, as the scenarios show, that I did test, the company email behaves exactly as expected. Basically I can summarize the results in two very simple, but very important, points:

1 The company email won’t be available after retiring the mobile device from Microsoft Intune
2 The personal email will be left untouched after retiring the mobile device from Microsoft Intune


Note
: Even though I state everywhere only Microsoft Intune, this behavior is applicable for Microsoft Intune standalone and Microsoft Intune hybrid.

The three layers of protection with conditional access for Exchange email

In this blog post I would like to write a little about, what I like to call, the three layers of protection with conditional access for Exchange email. No, I don’t mean that a device has to be 1) enrolled in Microsoft Intune, 2) workplace joined and 3) compliant with any Microsoft Intune compliance policies. What I do mean is related to company data, in this case company email, and the protection of it on mobile devices. That means three different layers of protection for Exchange email on mobile devices. From basic protection to almost complete protection.

The first layer of protection

ConditionalAccess_Level1The first, basic, layer of protection is simply using an Exchange Online Policy, or an Exchange On-premises Policy. These policies make it possible to protect Exchange email by blocking the access, via ActiveSync, to Exchange. It, of course, doesn’t block connections via OWA.

By enabling these policies, a mobile device, of an user that’s in a Targeted Group and not in an Exempted Group, will be blocked from ActiveSync when it’s not enrolled in Microsoft Intune, and/or not compliant with any targeted Microsoft Intune compliance policies. When no compliance policy is targeted, the device will automatically be evaluated as compliant. Also, not supported and exempted platforms can be blocked access through these policies.

I like to call this the first layer of protection, as it provides very basic protection, to the Exchange email, on the mobile device, by simply making sure that the mobile device is enrolled in Microsoft Intune. That enrollment makes sure that the connected mobile devices are known by the IT organization.

The second layer of protection

ConditionalAccess_Level2The second layer of protection is adding a few requirements, by using a Conditional Access Policy. A Conditional Access Policy can be used to add additional requirements to the mobile devices that want to connect to Exchange email, via ActiveSync.

These policies can be used to specify additional requirements to the password and encryption of the mobile device. Besides that it’s possible to, in case of iOS, block jailbroken mobile devices and, in case of Android, rooted mobile devices.

I like to call this the second layer of protection, as it already adds another form of protection, to the Exchange email, on the mobile device, by requiring additional configurations to mobile devices.

The third layer of protection

ConditionalAccess_Level3The third layer of protection is adding another, very important, requirement, by using a Conditional Access Policy in combination with an Email Profile.

This is basically nothing more than an additional configuration in the Conditional Access Policy, but it adds a lot more. It requires that the mobile device (currently only iOS) can only connect to Exchange email, via ActiveSync, when it’s using a specific Email Profile that’s configured via Microsoft Intune.

I like to call this the third layer of protection, as it adds almost complete protection to the company email that’s available on the mobile device. As the mobile device can only connect via an Email Profile, configured via Microsoft Intune, the company email will also be removed when the device is removed from Microsoft Intune.

Conclusion

These three layers of protection together make a very powerful combination for protecting company email. Especially by adding the third layer, it ensures that the available company email will also be removed again.

A good thing to know is that the (managed) Microsoft Outlook app can also still connect to Exchange email, via ActiveSync, as long as the mobile device is enrolled and compliant. More about this in my next blog post.

Note: Even though this post only shows Microsoft Intune standalone screenshots, the same is applicable to Microsoft Intune hybrid.

More information

For a lot more information about conditional access and compliance policies, please refer to the following links.