Getting started with Microsoft Defender for Endpoint for Android

Microsoft recently declared Microsoft Defender for Endpoint (MDE) for Android – previously known as Microsoft Defender ATP for Android – general available. That’s really good news and also a really good trigger for a new blog post. MDE for Android provides protection against phishing, unsafe network connections, and malicious apps. All events and alerts around those subjects will be available in the Microsoft Defender Security Center and will be used to determine the risk level of the device. To add-on to that, through the connection with Microsoft Intune that risk information can be used to determine the compliance of the device with the company policies and to determine the eventual access of the device to company data.

In this post I want to start with a short introduction about MDE for Android, followed by the required configurations. I’ll end this post by having a look at the experience. That means that the following will be addressed.

Note: At this moment many configurations still refer to Microsoft Defender ATP. This will change over time.

Introduction to Microsoft Defender for Endpoint for Android

Let’s start with a short introduction about MDE for Android. At this moment MDE for Android contains two key capabilities: 1) Web protection and 2) Malware scanning.

The Web protection capability relies on a local/self-looping VPN that does not take traffic outside of the device. That capability helps with addressing the challenge of phishing, by instantly blocking access to unsafe websites (coming from SMS, email, browsers and other apps). It also helps with addressing the challenge of unsafe network connections that some apps automatically make, by immediately blocking access to unsafe network connections. The key service that is leveraged for providing this functionality is Microsoft Defender SmartScreen. Besides that default functionality, an administrator can also configure custom indicators for allowing or blocking access to specific URLs and domains.

The Malware scanning capability fortifies the existing functionality of Google Play Protect and the ability to limit the installation of apps to trusted sources. That’s achieved by using cloud protection for apps and data on the device. When apps are downloaded, scans are instantly performed to detect malware of potentially unwanted applications (PUA).

In addition to those capabilities, MDE can also integrate with Microsoft Intune. That integration can provide information about the device risk to Microsoft Intune. That information about the risk level of the device can be used in a compliance policy in Microsoft Intune, to determine if a device is compliant with the company policies. That compliance state can be used in Conditional Access to determine the access of a device to company apps and data.

Integration of Microsoft Defender for Endpoint with Microsoft Intune

One of the main benefits of using MDE, is the integration with Microsoft Intune. That integration makes sure that the information about the risk level of a device, of any supported platform, can be provided to Microsoft Intune for usage in compliance policies. To achieve that integration, the following two configurations are required.

Enable Microsoft Intune connection in Microsoft Defender Security Center

The connection with Microsoft Intune should be enabled in Microsoft Defender Security Center. This is a generic configuration that is applicable to any supported platform. When this connection is already used for another platform, these actions can be ignored. To enable the Microsoft Intune connection, follow the two steps below.

  1. Open the Microsoft Defender Security Center portal and navigate to Settings Advanced features to open the Settings page for the advanced features
  2. On the Settings page, scroll down to Microsoft Intune connection (as shown in Figure 1) and switch the slider to On

Enable Android devices in Microsoft Endpoint Manager admin center

When the connection between MDE and Microsoft Intune is established, a configuration can be done per platform to use risk information that is provided via the connection. To enable that for Android, follow the two steps below.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Endpoint security > Microsoft Defender for ATP to open the Endpoint security | Microsoft Defender ATP blade
  2. On the Endpoint security | Microsoft Defender ATP blade, navigate to the setting Connect Android devices of version 6.0.0 and above to Microsoft Defender ATP (as shown in Figure 2) and switch the slider to On

Distribution of the Microsoft Defender for Endpoint for Android app

The MDE for Android app can be distributed by using Microsoft Intune. That will help with a smoother adoption of MDE on Android devices. Distribution of that app can be achieved by following the seven steps below.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Apps > All apps > Android to open the Android | Android apps blade
  2. On the Android | Android apps blade, click Add to open the Select app type page
  3. On the Select app type page, select Managed Google Play app as App type and click Select to open the Managed Google Play page
  1. On the Managed Google Play page, search for the Microsoft Defender ATP (Enterprise) app, select the app and click Approve to open the Permissions dialog
  2. On the Permissions dialog, click Approve to open the Approval settings dialog
  3. On the Approval settings dialog, select Keep approved when app requests new permissions click Done
  4. Click Sync (as shown in Figure 3) to synchronize the approved app to Microsoft Intune

After successfully synchronizing the MDE for Android app to Microsoft Intune, assign the app to the required group of users or devices to distribute the app.

Configuration of the Microsoft Defender for Endpoint for Android app

The MDE for Android app can also be configured with a few properties to enabled or disable features and to take away some end-user interaction. The latter, however, can’t be taken away completely, which means that there is still a user interaction required. The configurations that can be achieved are enabling and disabling (a part of) the Web protection capability of MDE for Android. The permissions that can be useful are providing access to the external storage. If needed, those configurations can be achieved by following the seven steps below.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Apps App configuration profiles to open the Apps | App configuration policies blade
  2. On the Apps | App configuration policies blade, click Add > Managed devices to open the Create app configuration policy wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the app configuration policy
  • Description: (Optional) Provide a valid name for the app configuration policy
  • Device enrollment type: (Grayed out) Managed devices
  • Platform: Select Android Enterprise
  • Profile Type: Select All Profile Types, Fully Managed, Dedicated, and Corporate-Owned Work Profile Only or Personally-Owned Work Profile Only depending on the devices that should get this policy assigned
  • Targeted app: Select Microsoft Defender ATP (Enterprise)
  1. On the Settings page, (if needed) provide the following information (as shown in Figure 4) and click Next
  • Permissions
    • Click Add to add External storage (read) and External storage (write) permissions and select Auto grant with the Permission state

Note: These permissions will save the users from manually approving these permissions on their device

  • Configuration Settings
    • Configuration settings format: Select Use configuration designer
    • Click Add to add the Anti-Phishing or VPN configuration key and set the configuration value to 1 (enable) or to 0 (disable).

Note: The Anti-Phishing configuration key only works for fully managed and dedicated devices and both configuration keys influence the Web protection capability.

  1. On the Scope tags page, configure the applicable scope tags and click Next
  2. On the Assignments page, configure the assignment by selecting the applicable group and click Next
  3. On the Review + create page, review the configuration and click Create

Configuration of the device risk compliance policy for Android Enterprise devices

The device compliance policy can be used to actively take advantage of the integration between MDE and Microsoft Intune. That policy can mark a device as noncompliant when the device risk is above the configured score. Eventually, that compliance state can be used with conditional access to determine the access of a device to company apps and data. Creation of such a device compliance policy can be achieved by following the nine steps below.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Device compliance policies to open the Compliance policies | Policies blade
  2. On the Compliance policies | Policies blade, click Create Policy to open the Create a policy page
  3. On the Create a policy page, provide the following information and click Create
  • Platform: Select Android Enterprise
  • Policy type: Select Fully managed, dedicated, and corporate-owned work profile or Personally-owned with work profile depending on the devices that should get this policy assigned
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the device compliance policy
  • Description: (Optional) Provide a valid name for the device compliance policy
  1. On the Compliance settings page, navigate to the Microsoft Defender ATP section, select the risk score with Require the device to be at or under the machine risk score (see also Figure 5) and click Next
  1. On the Actions for noncompliance page, leave the default configuration of Action on Mark device noncompliant with Schedule (days after noncompliance) on Immediately and click Next
  2. On the Scope tags page, configure the applicable scope tags and click Next
  3. On the Assignments page, configure the assignment by selecting the applicable group and click Next
  4. On the Review + create page, review the configuration and click Create

Note: Configure a conditional access policy that requires a compliant device to use this compliance state for verifying access to company apps and data.

Experience with Microsoft Defender for Endpoint for Android

When the integration is configured between MDE and Microsoft Intune, the MDE for Android apps is configured and distributed and the compliance policy is in place, it’s time to look at the experience. Both, from an end-user perspective and from an administrator perspective.

End-user experience with the Microsoft Defender for Endpoint for Android app

When looking at the end-user experience, it starts with the initial start of the MDE for Android app. After the MDE for Android app is installed, users should start it the first time to get it up-and-running. This does require the user to have the correct license (Windows 10 E5/A5, Microsoft 365 E5/A5, or Microsoft 365 E5 Security). When initially starting the MDE for Android app, the user needs to agree with the license agreement and privacy statement, by clicking Get started (as shown in Figure 6). That will bring users to the the wizard that will provide the MDE for Android app with the required permissions locally on the device (see Figure 7). When using the mentioned permissions in the app configuration, the storage permissions will already be in place. Once all the permissions are provided, the MDE for Android app is up-and-running.

For testing the Web protection capability, Microsoft provides the smartscreentestratings2.net site. When navigating to that site, or any other phishing site, the user receives the “Connection blocked” message (as shown in Figure 8). That will be logged in the Microsoft Defender Security Center portal as “Informational“. Once the user ignores the message and continue to the site by clicking on Allow, the action will be logged as “Low“.

For testing the Malware scanning capability, Microsoft refers to the existing test apps in the Google Play store. Those apps simply contain an EICAR test file that should be captured by any antimalware app. For testing purposes my test user installed the first hit in the Google Play store, which is the Test Virus app. That app will immediately be caught by MDE for Android (as shown in Figure 9). When the user now checks the MDE for Android app, the device will be marked as unsafe (see Figure 10). When the user clicks on the notifications, or on the app security, they will be brought to the remediation action to uninstall the app. When the user wants to ignore that, the device will also be marked as noncompliant in Microsoft Intune (as shown in Figure 11). That will eventually block the access for the user to company data and apps. Assuming that conditional access is in place and requires a compliant device.

Note: When using MDE for Android on a device with a Work Profile (personally-owned or corporate-owned), it will only protect everything within the Work Profile.

Administrator experience

When looking at the administrator experience, I want to focus on the information that’s generated by the user. For an overview of the alerts, I’ve opened the Microsoft Defender Security Center portal and navigated to the Alerts of the device of the user. That provides the suspicious activity of visiting the test site and the malware of the test virus app. It also shows the earlier mentioned severity of the different actions.

As the user ignored the information that was provided by MDE for Android, the device will also be marked as noncompliant. For an overview of that message, I’ve opened the Microsoft Endpoint Manager admin center portal and navigate to device compliance policy settings of the compliance policy that was assigned to the user. That provides the current status of the device, based on the device risk.

More information

For more information about MDE for Android, the naming, the availability and the configuration, refer to the following docs.

Getting started with Android Enterprise Corporate-Owned devices with Work Profile

Microsoft has recently declared the Android Enterprise Corporate-Owned devices with Work Profile deployment scenario (sometimes also referred to as management scenario) feature complete. That’s really good news and also a really good trigger for a new blog post. This time I’ll skip the different deployment scenarios and use cases, as I’ve written about those here and here. Just to create a good starting point, I’ll start with a quick summary about the main characteristics of this specific deployment scenario in the table below. These characteristics will help with determining if this deployment scenario will fit on the use case. For a complete overview with the different deployment scenarios, please refer to my previous post around this subject.

Deployment scenarioUse casePersonal usePrivacy guaranteedEnrollment methodManagement reachReset requiredUser affinity
Corporate-Owned devices with Work ProfileCorporate-Owned, Personally Enabled (COPE)YesYesNear Field Communication, Token entry, QR code scanning, or Zero touchProfile owner with device-level settingsYesYes

Note: Keep in mind that the user experience will be similar to personal devices with work profile. That means a strict separation between personal apps and data and work apps and data.

Throughout this post, I want to discuss the main enrollment, configuration and distribution options for the Android Enterprise corporate-owned devices with work profile deployment scenario. I want to achieve that by going through the following subjects and touching the most important points for the different configurations. I’ll simply provide the steps to get to the correct profiles, policies and apps that are applicable to this deployment scenario. I’ll end by providing a quick overview of the end-user experience.

Enrollment profile for corporate-owned devices with work profile

The Android Enterprise corporate-owned devices with work profile deployment scenario starts with the enrollment profile, as the enrollment profile determines the deployment scenario that is used. That enrollment profile contains a unique token that does not expire. There can also be multiple enrollment profiles. Having multiple enrollment profiles can be useful for separating devices in different groups, as the enrollment profile name can be used for creating dynamic device groups. The following five steps walk through the process of creating that enrollment profile.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Android > Android enrolment Corporate-owned devices with work profile to open the Corporate-owned devices with work profile blade
  2. On the Corporate-owned devices with work profile blade, click Create profile to open the Create a profile wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the enrollment profile for corporate-owned devices with work profile
  • Description: (Optional) Provide a valid description for the enrollment profile for corporate-owned devices with work profile
  1. On the Scope tags page, configure the required scope tags click Next
  2. On the Review + create page, verify the configuration and click Create

Note: When not using Zero-touch enrollment, or third-party services like Samsung Knox Mobile Enrollment, the easiest method for enrolling these devices is by using the created QR-code.

Device configuration profiles for corporate-owned devices with work profile

The configuration of devices in the Android Enterprise corporate-owned devices with work profile deployment scenario, is similar to most other Android Enterprise corporate-owned deployment scenarios. The different device configuration profiles can be used for configuring device features, assigning certificates or configuring Wi-Fi or VPN. To create a device configuration profile, focus on the profiles shown under the Fully Managed, Dedicated, and Coporate-Owned Work Profile category. The following three steps walk through the creation of a device configuration profile.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Configuration profiles to open the Devices | Configuration profiles blade
  2. On the Devices | Configuration profiles blade, select Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create
  • Platform: Select Android Enterprise
  • Profile: Depending on the required configuration, select Derived credentials, Device restrictions, SCEP certificate, Trusted certificate, VPN or Wi-Fi in the Fully Managed, Dedicated, and Coporate-Owned Work Profile category

When creating a device restrictions profile, the settings are divided in different categories and in every category there a different headers. Those headers include the applicable deployment scenarios for the settings under the header. Make sure that the header includes “corporate-owned work profile“. In most cases that’s applicable to settings that are available for all deployment scenarios, with the exception of two categories. The Work profile password category (see Figure 1) and the Personal profile category (see Figure 2). Those categories are only applicable to Android Enterprise corporate-owned devices with work profile.

Note: Keep in mind that OEMConfig can also be used for configuring the work profile of these devices, when supported by the vendor.

Device compliance policies for corporate-owned devices with work profile

The compliance of devices in the Android Enterprise corporate-owned devices with work profile deployment scenario, is also similar to most other Android Enterprise corporate-owned deployment scenarios. The device compliance policy settings that are available for the existing corporate-owned deployment scenarios, are also applicable to this deployment scenario. A device compliance policy can be used for verifying the compliance with the device risk, device health, platform version and security settings. The following three steps walk through the creation of such a device compliance policy.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Compliance policies to open the Compliance policies| Policies blade
  2. On the Compliance policies| Policies blade, select Create policy to open the Create a policy page
  3. On the Create a policy page, provide the following information and click Create
  • Platform: Select Android Enterprise
  • Profile: Select Fully managed, dedicated, and coporate-owned work profile

Note: Even though the devices are compliant, I’m currently seeing challenges with device-based Conditional Access, as a certificate should be selected that is not available.

Apps for corporate-owned devices with work profile

The deployment of apps to devices in the Android Enterprise corporate-owned devices with work profile deployment scenario, is the same as for any other Android Enterprise corporate-owned deployment scenario. The different app types can be used for installing store apps, line-of-business apps, web links, built-in apps, and Android Enterprise system apps. The following three steps walk through the process of adding such apps.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Apps All apps to open the Apps | All apps blade
  2. On the Apps | All apps blade, click Add to open the Select app type page
  3. On the Select app type page, provide the following information and click Select
  • App type: Depending on the required app, select Managed Google Play app, Web link, Built-in app, Line-of-business app or Android Enterprise system app

Note: Even though the Android Enterprise system apps are applicable, and will be available, most of those apps can only be used by the owner of the device.

App configuration policies for corporate-owned devices with work profile

The configuration of apps for devices in the Android Enterprise corporate-owned devices with work profile deployment scenario, is the same as for any other Android Enterprise corporate-owned deployment scenario. The app configurations can be configured by using the configuration designer, or JSON data. The following three steps walk through the process of adding such app configuration policies.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Apps App configuration policies to open the Apps | App configuration policies blade
  2. On the Apps | App configuration policies blade, click Add > Managed devices to open the Create app configuration policy wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the app configuration policy
  • Description: (Optional) Provide a valid description for the app configuration policy
  • Device enrollment type: Managed devices already selected
  • Platform: Select Android Enterprise
  • Profile Type: Select Fully Managed, Dedicated and Corporate-Owned Work Profile Only
  • Targeted app: Select the app that should be configured

Note: When possible, stick with the configuration designer, as it simplifies the app configuration.

App protection policies for corporate-owned devices with work profile

The protection of (the data in) apps for devices in the Android Enterprise corporate-owned devices with work profile deployment scenario, is the same as for any other Android Enterprise deployment scenario. The app protection policies can used for creating restrictions for data transfers, requiring encryption, creating access requirement and adding conditional launch requirements. The following four steps walk through the process of adding such app protection policies.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Apps App protection policies to open the Apps | App protection policies blade
  2. On the Apps | App protection policies blade, click Create policy > Android to open the Create policy wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the app protection policy
  • Description: (Optional) Provide a valid description for the app protection policy
  • Platform: Android already selected
  1. On the Apps page, provide at least the following information and click Next
  • Target to apps on all device types: Select Yes, or select No in combination with the following setting
    • Device types: Select at least Android Enterprise
  • Public apps: Select the public apps to which this policy applies
  • Custom apps: Select the custom apps to which this policy applies

Note: Keep in mind that when managed apps are allowed without a managed devices, users can also configure a managed app in their personal container.

Remote actions for corporate-owned devices with work profile

The available remote actions for devices in the Android Enterprise corporate-owned devices with work profile deployment scenario are limited. The remote actions can be used to wipe, delete, remote lock, reset work profile passcode, or restart the device. The following two steps walk through the process of getting to the remote actions.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices All devices to open the Devices | All devices blade
  2. On the Devices | All devices blade, select a specific Android Enterprise corporate-owned device with work profile to open the device Overview

Important: Keep in mind that the Wipe action will factory reset the device and that the factory reset of the device will remove all company apps and data and all personal apps and data.

Tip: The Wipe, Delete and Restart actions can also be performed by using Bulk Device actions.

Note: This figure also provides a nice overview of the combination of a corporate-owned device (see Ownership property) and a work profile (see Reset work profile passcode action).

User experience for corporate-owned devices with work profile

Let’s end this post by having a quick look at the end-user experience for the Android Enterprise corporate-owned devices with work profile deployment scenario. The enrollment process is pretty straight forward, it does take some time, but the steps almost can’t go wrong. That’s why I want to show the user experience for the personal and work profile. Mainly focused on showing the different configuration options and the main difference with personal devices with work profile.

Below in Figure 8 is an example of the personal profile after the enrollment of the device. It doesn’t contain a Company Portal app, as it’s not needed for the enrollment of the device. Below in Figure 9 is an example of the work profile after the enrollment of the device. It does contain the Microsoft Intune app with the device compliance information and the device policy sync option. It also contains multiple apps that are distributed, configured and managed.

Note: As shown in Figure 9, the work profile of my users also contains the Microsoft Tunnel app and I can confirm that Microsoft Tunnel Gateway is also working for my users.

More information

For more information regarding Android Enterprise Corporate-Owned Work Profile, refer to the following articles:

Getting familiar with Microsoft Tunnel Gateway

This week is a follow-up on my post of a few weeks ago about getting started with Microsoft Tunnel Gateway. In that post I’ve showed how to get started with Microsoft Tunnel Gateway and in this post I want to show how to get more familiar with Microsoft Tunnel Gateway. Getting to know the installation location, getting to know the configuration files, getting to know the log files and getting to know a few important commands for more information. All of that will eventually help with getting more familiar with Microsoft Tunnel Gateway. In this post I’ll look a few directories, files, logs and commands. Also in that order.

Directories

Let’s start with a few directories. Actually, one directory and a few sub-directories. After the installation of Microsoft Tunnel Gateway, a few important directories become available. Below are the most important directories, including a short description.

DirectoryDirectory description
/etc/mstunnelThis is the root directory that contains the configuration.
/etc/mstunnel/certsThis is the directory that contains the TLS certificate.
/etc/mstunnel/privateThis is the directory that contains the Intune Agent certificate and the TLS private key.

Tip: When navigating to the root directory, a simple ls command will show all the available directories. Keep in mind that the permissions will be denied for a normal user and that the usage of sudo is required.

Files

Within the mentioned root directory, many files are added during the different stages of the installation of Microsoft Tunnel Gateway. Below are the most important files, including a short description and an example.

FileFile description
AgentSettings.jsonThis file contains the generic server configuration information (name, site, and more).
admin-settings.jsonThis file contains the configuration as configured in the Server configuration in Intune.
agent-info.jsonThis file contains the agent information (Intune tenant Id, Azure AD tenant Id, and more).
Images_configuredThis file contains the hash values of the current images.
ocserv-sec.jsonThis file contains the VPN server configuration information.
ocserv.confThis file contains the VPN server configuration.
oidc.jsonThis file contains the OpenID configuration.
version-info.jsonThis file contains the version information (configuration version, docker version, and more).
env.shThis file contains the environment variables (like the proxy addresses) when used.

Tip: When looking at the files in the directory, a simple cat command will print the content in the terminal. Keep in mind that the permissions will be denied for a normal user and that the usage of sudo is required.

Note: AgentLoggingInfo.json, AgentMonitorLoggingInfo.json, GeneralLoggingInfo.json, JournalLoggingInfo.json, OcservErrorLoggingInfo.json, OcservLoggingInfo.json and VpnLoggingInfo.json only contain the last processed logs date and mstunnel-agent-state and mstunnel-server-state only contains the status of the service.

AgentSetting.json

The AgentSettings.json shows the generic server properties. That includes the id of the site that the server belongs to, the name of the server, the id of the server and the id of the configurations that is applied to the server. Below is an example of an AgentSettings.json file.

{
	"SiteId":"n0tm1n3-da01-4633-9ad4-82bf34a93ab4",
	"ServerName":"cldmtg01",
	"ServerId":"n0tm1n3-3d69-4d8f-bdc0-e0c0e929bb6c",
	"ConfigId":"n0tm1n3-5c3c-43a9-8324-deb553da795b",
	"ServerImageTime":"2020-10-13T20:18:26.2199173+00:00",
	"AgentImageTime":"2020-10-13T20:18:26.1972649+00:00",
	"PatchExpirationDate":"0001-01-01T00:00:00+00:00"
}

admin-settings.json

The admin-settings.json shows the configured properties of the Server configuration. This file should only be adjusted by using Intune and not manually. Below is an example of an agent-settings.json file.

{
  "DisplayName": "Default server configuration",
  "Network": "192.168.50.1/24",
  "DNSServers": [
    "192.168.20.1"
  ],
  "DefaultDomainSuffix": "",
  "RoutesInclude": [],
  "RoutesExclude": [],
  "ListenPort": 443,
  "ConfigVersion": 637370578342241628,
  "SplitDNS": [],
  "AditionalSettings": []
}

agent-info.json

The agent-info.json shows the basic agent properties. That includes the id of the agent, the id of the Intune tenant that the server belongs to, the id of the Azure AD tenant that the server belongs to and the certificate information. Below is an example of an agent-info.json file.

{
  "AgentId": "n0tm1n3-09ff-4e0b-8c0b-0e1b7d6cb5fb",
  "IntuneTenantId": "n0tm1n3-8b8f-428c-a3f6-774ec1f94b6d",
  "AADTenantId": "n0tm1n3-1ce1-41db-8aff-4c59298d4ba9",
  "Type": 8,
  "Certificate": null,
  "RenewalDate": "2021-08-20T10:34:01+00:00"
}

Images_configured

The Images_configured show the hash values of the installed images. That information can be used to identify the version of the installed images. Below is an example of an Images_configured file.

mst_use_custom_image=""
agentImageDigest="sha256:3d888864ecafa1d8c05754e3059519a2cf0d4ca56a234e13f60431cff9ba152b"
serverImageDigest="sha256:525f329010088bd4a27e930e613635dc3cbcadd0611011c6d5d8f5e1d087cb41"

ocserv-sec.json

The ocserv-sec.json shows the VPN server properties. That includes the authentication configuration that is used and the certificate configuration that is used. Below is an example of an ocserv-sec.json file.

{
  "StatsReportTime": 60,
  "StatsResetTime": 3600,
  "MaxClients": 5500,
  "RateLimit": 100,
  "KeepAlive": 32400,
  "AuthTimeout": 40,
  "MinReauthTime": 300,
  "Auth": "oidc[config=/etc/ocserv/oidc.json]",
  "CertPath": "/etc/ocserv/certs/site.crt",
  "KeyPath": "/etc/ocserv/private/site.key",
  "PinPath": null,
  "UseOcctl": true,
  "Rekey": "ssl",
  "PidFile": "/var/run/ocserv.pid",
  "SockeFile": "/var/run/ocserv-socket",
  "RunAsUser": "nobody",
  "RunAsGroup": "nogroup",
  "IsolateWorkers": true,
  "Device": "ma-tun",
  "CookieTimeout": 300,
  "PersistentCookies": true,
  "MobileDpd": 1800,
  "Dpd": 240,
  "TryMtuDiscovery": true,
  "TlsPriorities": "Secure256:-CIPHER-ALL:\u002BAES-256-GCM:-KX-ALL:\u002BECDHE-RSA:-MAC-ALL:\u002BAEAD:-VERS-TLS-ALL:\u002BVERS-TLS1.3:\u002BVERS-TLS1.2:-COMP-ALL",
  "MatchTlsDtlsCiphers": true,
  "DtlsLegacy": false,
  "ConnectScript": "/usr/local/sbin/ocserv-telemetry.sh",
  "DisconnectScript": "/usr/local/sbin/ocserv-telemetry.sh",
  "ServerDrainMs": 15000
}

ocserv.conf

The ocserv.conf shows the VPN server configuration. That includes the network configuration, the authentication configuration and the certificates that are used. Below is an example of an ocserv.conf file.

ipv4-network = 192.168.50.1/24
dns = 192.168.20.1
route = default
tcp-port = 443
udp-port = 443
server-stats-reset-time = 3600
max-clients = 5500
rate-limit-ms = 100
auth = oidc[config=/etc/ocserv/oidc.json]
server-cert = /etc/ocserv/certs/site.crt
server-key = /etc/ocserv/private/site.key
use-occtl = True
rekey-method = ssl
pid-file = /var/run/ocserv.pid
socket-file = /var/run/ocserv-socket
run-as-user = nobody
run-as-group = nogroup
isolate-workers = True
device = ma-tun
cookie-timeout = 300
persistent-cookies = True
mobile-dpd = 1800
dpd = 240
try-mtu-discovery = True
tls-priorities = Secure256:-CIPHER-ALL:+AES-256-GCM:-KX-ALL:+ECDHE-RSA:-MAC-ALL:+AEAD:-VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:-COMP-ALL
match-tls-dtls-ciphers = True
dtls-legacy = False
connect-script = /usr/local/sbin/ocserv-telemetry.sh
disconnect-script = /usr/local/sbin/ocserv-telemetry.sh
server-drain-ms = 15000

oidc.json

The oidc.json shows the OpenID properties. That includes the sts-url that is used and the issuer. Below is an example of the oidc.json file.

{
  "openid_configuration_url": "https://sts.windows.net/n0tm1n3-1ce1-41db-8aff-4c59298d4ba9/v2.0/.well-known/openid-configuration",
  "user_name_claim": "oid",
  "required_claims": {
    "aud": "n0tm1n3-9681-447a-974d-d19f668fcd88",
    "acct": 0,
    "iss": "https://sts.windows.net/n0tm1n3-1ce1-41db-8aff-4c59298d4ba9/"
  }
}

version-info.json

The version-info.json shows the version information of the different components. That includes, the version of the configuration, the version of Docker, the version of the different images and the version of the operating system. Below is an example of the version-info.json file.

{
    "ConfigVersion": 637370578342241628,
    "DockerVersion": "Docker version 19.03.13, build 4484c46d9d",
    "AgentImageHash": "sha256:3d888864ecafa1d8c05754e3059519a2cf0d4ca56a234e13f60431cff9ba152b",
    "AgentCreateDate": "2020-10-09T18:50:54.560584825Z",
    "ServerImageHash": "sha256:525f329010088bd4a27e930e613635dc3cbcadd0611011c6d5d8f5e1d087cb41",
    "ServerCreateDate": "2020-10-09T18:49:24.487117764Z",
    "HostOS": "Ubuntu 20.04.1 LTS",
    "HostKernel":"5.4.0-48-generic"
}

Commands

When looking at the different commands that are available for basic interaction with Microsoft Tunnel Gateway, locally on the Linux server, journalctl is important for querying the journal (the place for logs) and mst-cli is important for actually interacting with Microsoft Tunnel Gateway.

Logs

With the latest update of Microsoft Tunnel Gateway, the logs are logged in the Linux server logs in the syslog format. That also means that the standard journalctl command can be used view the journal (the logs) and that the -t parameter can be used for showing entries with only the specific identifier. When looking at the Microsoft Tunnel Gateway log entries, the identifiers in the table below are important.

IdentifierIdentifier description
ocservThis identifier only displays the VPN server logs.
mstunnel-agentThis identifier only displays the Intune agent logs.
mstunnel_monitorThis identifier only displays the monitoring task logs.

An example for using journalctl for displaying the Intune agent logs, can be found below.

journalctl -t mstunnel_monitor

Tip: When looking at the logs, the -f parameter will follow the log and display a rolling log. For more an overview of all the available parameters, use the -h parameter.

Interface

For local interaction with Microsoft Tunnel Gateway, Microsoft provides the mst-cli command-line tool. This command-line tool is available on the Linux server after the installation of Microsoft Tunnel Gateway and can be found at /usr/sbin/mst-cli. This command-line tool can be used to get some basic interaction with Microsoft Tunnel Gateway, like getting information, restarting the service and server and even uninstalling Microsoft Tunnel Gateway.

Note: Keep in mind that when running the mst-cli command-line tool, the usage of sudo is required.

When looking at the mst-cli command-line tool, the following commands are the first layer of local interaction capabilities with Microsoft Tunnel Gateway.

CommandCommand description
agentOperate commands on the agent component (use the -h command for more command options).
serverOperate commands on the server component (use the -h command for more command options).
uninstallUninstall Microsoft Tunnel Gateway.
eulaShow the EULA that was accepted during the installation of Microsoft Tunnel Gateway.
import_certImport the TLS certificate.

An example for using mst-cli, can be found below. This example will show the accepted EULA.

sudo /usr/sbin/mst-cli eula

Important: Be careful with the uninstall parameter of the mst-cli command-line tool, because at this moment the uninstall will start immediately without verification.

agent parameter

When looking at the agent command, the following commands are the options for interacting with the agent component.

CommandCommand description
statusShows the status of the agent component.
startStart the service of the agent component.
stopStop the service of the agent component.
restartRestart the service of the agent component.

An example for using mst-cli agent, can be found below. This example will show the status of the agent component.

sudo /usr/sbin/mst-cli agent status

server parameter

When looking at the server command, the following commands are options for interacting with the server component.

CommandCommand description
statusShows the status of the server component.
startStart the service of the server component.
stopStop the service of the server component.
restartRestart the service of the server component.
showShow various stats of the server component (use the -h command for more command options). This command can show a lot of stats, including the statistics of the server and the connected users.

An example for using mst-cli server, can be found below. This example will show the status of the server component.

sudo /usr/sbin/mst-cli server status

Tip: For an overview of all the available commands use sudo /usr/sbin/mst-cli -h. For an overview of the available commands for a specific component use something similar to sudo /usr/sbin/mst-cli server show -h.

More information

For more information about the further details about Microsoft Tunnel Gateway, refer to the following docs.

Getting started with Microsoft Tunnel Gateway

This week is all about the just, during Microsoft Ignite 2020, released Microsoft Tunnel Gateway (often referred to as Microsoft Tunnel or Tunnel). Microsoft Tunnel Gateway is a new solution that can provide iOS and Android devices with access to on-premises resources. In other words, Microsoft Tunnel Gateway is a VPN solution. The best part of Microsoft Tunnel Gateway is that it fully integrates with a Microsoft 365 solution and that it’s included in the existing Microsoft Intune license. That integration is also one of the strongest points of Microsoft Tunnel Gateway, as it also provides single sign-on capabilities and even conditional access. All of that with a relatively simple deployment. Also, to work with Microsoft Tunnel Gateway, Microsoft released the Microsoft Tunnel app for iOS and Android. That app can be deployed to users and can be used to provide access via Microsoft Tunnel Gateway. That provides a truly great experience for the user. In this post I want to walk through the prerequisites for Microsoft Tunnel Gateway, followed with the different configurations to configure Microsoft Tunnel Gateway. I’ll end this post by distributing the app and configurations to the user and by looking at the user experience.

Important: At this moment, Microsoft Tunnel Gateway is a solution for iOS and Android only.

Prerequisites for Microsoft Tunnel Gateway

For this post it’s important to start with a list of prerequisites for Microsoft Tunnel Gateway. The main reason for that is that I’ll leave a few subjects out-of-scope for this post, but those subjects are important for getting started with Microsoft Tunnel Gateway. Make sure that the following is in place, before starting with Microsoft Tunnel Gateway.

  • a server with a supported Linux distribution that will be used for hosting Microsoft Tunnel Gateway
  • Docker is installed on the server to support containers on the Microsoft Tunnel Gateway server
  • a (preferably publicly) trusted TSL certificate, that contains the public FQDN of the Microsoft Tunnel Gateway server, is available for securing the connection between the devices and the Microsoft Tunnel Gateway server
  • inbound port 443 (UDP and TCP) is available on the server for a functioning Microsoft Tunnel Gateway
  • outbound port 80 (TCP) and 443 (TCP) is available on the server for interaction with Microsoft Intune
  • add Microsoft Tunnel Gateway as a cloud app to Azure AD to enable the use of Conditional Access

My setup

Also, I thought it would be a good idea for this post to provide some information about the starting point that I’ll use for the configurations that are provided throughout this post. That starting point is described below.

  • a virtual server that is running Ubuntu 20.04
  • Docker is installed on that virtual Ubuntu 20.04 server by using these configuration steps
  • a publicly trusted certificate for *.petervanderwoude.nl is available
  • an A-record is configured for vpn.petervanderwoude.nl
  • a gateway router is used to forward port 443 to the virtual Ubuntu 20.04 server

Create the server configuration

The first Microsoft Intune related configuration is the Server configuration. The Server configuration is used to create a configuration that can be applied to one or multiple Microsoft Tunnel Gateway servers. That contains the configuration that will be used for configuring the Microsoft Tunnel Gateway server. That contains information like the IP address range that is used for devices connecting to Microsoft Tunnel Gateway and the port that the Microsoft Tunnel Gateway server is listening to. This information can also be adjusted when Microsoft Tunnel Gateway is up-and-running, but that would require a restart of the server to apply the new configuration. The following five steps walk through creating the Server configuration.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Tenant administrationMicrosoft Tunnel Gateway (Preview) to open the Tenant admin | Microsoft Tunnel Gateway (Preview) blade
  2. On the Tenant admin | Microsoft Tunnel Gateway (Preview) blade, navigate to Server configurations and click Create new to open the Create server configuration wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the server configuration
  • Description: (Optional) Provide a valid description for the server configuration
  1. On the Settings page, provide the following information and click Next
  • IP address range: Provide an IP address range that is leased to devices that connect to Microsoft Tunnel Gateway
  • DNS servers: Provide DNS server addresses that are used for DNS request from devices that are connected to Microsoft Tunnel Gateway
  • DNS suffix search: (Optional) Provide a DNS suffix that is used as default domain for devices that are connected to Microsoft Tunnel Gateway
  • Split tunneling: (Optional) Provide addresses that are included or excluded from Microsoft Tunnel Gateway
  • Server port: Provide the port that Microsoft Tunnel Gateway listens to
  1. On the Review + create page, verify the information and click Create

Important: The server port will also be used for the configuration of the Microsoft Tunnel app.

Create the site

The second Microsoft Intune related configuration is creating a Site. A Site is used to create a logical group of servers that host Microsoft Tunnel Gateway. A Site contains two important configurations that are applied to all the Microsoft Tunnel Gateway servers in the site and that’s the public address and the Server configuration that should be applied. Make sure that the Site is configured correctly, as it can’t be adjusted afterwards. The following three steps walk through the creation of a Site.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Tenant administrationMicrosoft Tunnel Gateway (Preview) to open the Tenant admin | Microsoft Tunnel Gateway (Preview) blade
  2. On the Tenant admin | Microsoft Tunnel Gateway (Preview) blade, navigate to Sites and servers and click Create > New site to open the Create a site page
  3. On the Create a site page, provide the following information and click Create
  • Name: Provide a valid name for this site
  • Description: (Optional) Provide a valid description for this site
  • Public IP address or FQDN: Provide a public IP address or FQDN that is used by the devices as the connection point to to Microsoft Tunnel Gateway
  • Server configuration: Select the just created server configuration

Note: The IP address or FQDN can point to an individual server or to a load-balancing server. When there is a firewall in between, make sure to create the necessary network adjustments.

Important: The IP address must be publicly routable and the FQDN must be publicly resolvable.

Install Microsoft Tunnel Gateway

After creating the Site and the Server configuration that can be applied to a Microsoft Tunnel Gateway server, it’s time to start with the actual installation of Microsoft Tunnel Gateway on the created Linux server with Docker. The installation is performed by downloading and running the Microsoft Tunnel Gateway installation script on the Linux server with Docker installed. The Microsoft Tunnel Gateway installation script will walk through the different required actions that should be performed to get the Microsoft Tunnel Gateway server up-and-running and interacting with Microsoft Intune. The following seven steps walk through that process.

  1. Connect to the Linux server with Docker and logon
  2. Download the Microsoft Tunnel Gateway installation script by using a command like this
wget https://aka.ms/microsofttunneldownload -O mstunnel-setup
  1. Start the Microsoft Tunnel Gateway installation script by using a command like this
sudo bash mstunnel-setup
  1. When prompted by the Microsoft Tunnel Gateway installation script, accept the license agreement (EULA)
  2. When prompted by the Microsoft Tunnel Gateway installation script, copy the TLS certificate to the specified location

Important: The name of the certificate file(s) is mandatory for the Microsoft Tunnel Gateway installation script to detect the existence of the required certificate file(s).

  1. When prompted by the Microsoft Tunnel Gateway installation script, register Microsoft Tunnel Gateway with Microsoft Intune by opening a browser, navigating to https://microsoft.com/devicelogin and entering the code that was provided by the Microsoft Tunnel Gateway installation script

Tip: The browser action can be performed on a different device.

Note: The Microsoft Tunnel Gateway script will prompt to enter a GUID of the site that this Microsoft Tunnel Gateway server should join, when multiple sites are configuration in Microsoft Intune.

  1. After the Microsoft Tunnel Gateway installation script is finished, the server will show in the Microsoft Endpoint Manager admin center portal when navigating to Tenant administrationMicrosoft Tunnel Gateway (Preview) > Health status as shown below in Figure 3.

Tip: When the Microsoft Tunnel Gateway installation script is stopped, it can be restarted again by using the same installation command. The installation will continue were it was stopped.

Deploy Microsoft Tunnel app

Once Microsoft Tunnel Gateway is up-and-running and online, it’s time to look at the device configurations. The first thing of those configurations is distributing the Microsoft Tunnel app. The Microsoft Tunnel app is required for accessing resources via Microsoft Tunnel Gateway on a mobile device. As the steps differ per platform, the most common options for deploying the Microsoft Tunnel app are described below per platform.

Deploy Microsoft Tunnel app for Android

The following seven steps walk through the process of distributing the Microsoft Tunnel app to the different Android Enterprise managed devices. As this is focused on Android Enterprise, the focus is on the Managed Google Play store.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to AppsAll apps > Android to open the Android | Android apps blade
  2. On the Android | Android apps blade, click Add to open the Select app type blade
  3. On the Select app type blade, select Managed Google Play app as App type and click Select to open the Managed Google Play page
  4. On the Managed Google Play page, search for the Microsoft Tunnel app, select the app (as shown in Figure 4) and click Approve
  5. On the Approval settings dialog, select Keep approved when app requests new permissions click Done
  6. Click Sync to synchronize the approval to Microsoft Intune
  7. Assign the Microsoft Tunnel app to the required users and/or devices

Deploy Microsoft Tunnel app for iOS/iPadOS

The following seven steps walk through the process of distributing the Microsoft Tunnel app to iOS/iPadOS devices. As my lab doesn’t contain Apple Business Manager (ABM), the focus is on the normal App Store.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to AppsAll apps > iOS/iPadOS to open the iOS/iPadOS | iOS/iPadOS apps blade
  2. On the iOS/iPadOS | iOS/iPadOS apps blade, click Add to open the Select app type blade
  3. On the Select app type blade, select iOS store app as App type and click Select to open the Add app wizard
  4. On the App information page, click Search the App Store, select the Microsoft Tunnel app (as shown in Figure 5) and click Select and click Next
  1. On the Scope tags page, click Next
  2. On the Assignments page, configure the assignment to the required users and/or devices and click Next
  3. On the Review + create page, verify the configuration and click Create

Deploy VPN profile

Once Microsoft Tunnel Gateway is up-and-running and online and the Microsoft Tunnel app is deployed to the mobile devices, it’s time to configure and deploy the VPN profile. The VPN profile is used to apply the correct configuration to the Microsoft Tunnel app and to make sure that the device can connect via Microsoft Tunnel Gateway.

Deploy VPN profile on Android

The following eight steps walk through the process of creating a VPN profile for the different Android Enterprise managed devices. Even thought the corporate-owned device and personal device deployment scenarios require a separate VPN profile, the steps below are applicable for both deployment scenarios.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Android > Configuration profiles to open the Android | Configuration profiles blade
  2. On the Android | Configuration profiles blade, select Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create
  • Platform: Android Enteprise
  • Profile: Select Fully Managed, Dedicated, and Corporate-Owned Work Profile > VPN or select Work Profile > VPN, depending on the Android Enterprise deployment scenario to open the VPN wizard
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the VPN profile
  • Description: (Optional) Provide a valid description for the VPN profile
  1. On the Configuration settings page, provide the following information and click Next
  • Connection type: Select Microsoft Tunnel
  • Connection name: Provide a valid name for the VPN profile that will be shown to the user in the Microsoft Tunnel app
  • Microsoft Tunnel site: Select the Site that will be used by this VPN profile

Note: When selecting the Site, the configuration also shows the complete public address that will be used for the Microsoft Tunnel app configuration.

  • Select apps that would trigger this VPN on use: (Optional) Add apps that should use this VPN profile to send app traffic to the tunnel

Note: When adding apps to this VPN profile, this VPN profile will only be used as a per-app VPN.

  • Always-on VPN: (Optional) Select Enable to make sure that the VPN will automatically connect and reconnect
  • Automatic configuration script: (Optional) Configure the location of the automatic configuration script, when a proxy should be used
  • Address: (Optional) Configure the address of the proxy server, when a proxy should be used
  • Port number: (Optional) Configure the port number of the proxy server, when a proxy should be used
  1. On the Scope tags page, click Next
  2. On the Assignments page, configure the assignment to the required users and/or devices and click Next
  3. On the Review + create page, verify the configuration and click Create

Deploy VPN profile on iOS/iPadOS

The following eight steps walk through the process of creating a VPN profile for iOS and iPadOS devices. These steps are nearly identical to the steps for creating a VPN profile for Android Enterprise device, but only the available configurations for per-app VPN, in step 5, are slightly different.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices iOS/iPadOS > Configuration profiles to open the iOS/iPadOS | Configuration profiles blade
  2. On the iOS/iPadOS | Configuration profiles blade, select Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create
  • Platform: iOS/iPadOS
  • Profile: Select VPN to open the VPN wizard
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the VPN profile
  • Description: (Optional) Provide a valid description for the VPN profile
  1. On the Configuration settings page, provide the following information and click Next
  • Connection type: Select Microsoft Tunnel
  • Connection name: Provide a valid name for the VPN profile that will be shown to the user in the Microsoft Tunnel app
  • Microsoft Tunnel site: Select the Site that will be used by this VPN profile

Note: When selecting the Site, the configuration also shows the complete public address that will be used for the Microsoft Tunnel app configuration.

  • Per-app VPN: (Optional) Select Enable when this profile should be used for per-app VPN

Note: When enabling per-app VPN, an app should be specifically associated with the VPN profile.

  • Automatic configuration script: (Optional) Configure the location of the automatic configuration script, when a proxy should be used
  • Address: (Optional) Configure the address of the proxy server, when a proxy should be used
  • Port number: (Optional) Configure the port number of the proxy server, when a proxy should be used
  1. On the Scope tags page, click Next
  2. On the Assignments page, configure the assignment to the required users and/or devices and click Next
  3. On the Review + create page, verify the configuration and click Create

Conditional access reflections

As mentioned in the prerequisites, to facilitate a working Microsoft Tunnel Gateway in combination with Conditional Access, a Microsoft Tunnel Gateway cloud app should be registered in Azure AD. That cloud app can be used in the different Conditional Access rules within an organization. Without adding that cloud app to Azure AD, and assigning Conditional Access rules to all cloud apps, those Conditional Access rules will also be applicable to Microsoft Tunnel Gateway. Of course, that doesn’t have to be a bad thing. However, one scenario to keep in mind is with requiring an approved client app or a requiring an app protection policy. The problem is that the Microsoft Tunnel app is not yet on the list of approved client apps or on the list of app protection policy apps. That means that the Microsoft Tunnel app will be blocked when either one of those settings is applicable to Microsoft Tunnel Gateway. Requiring a compliant device is not a problem.

End-user experience

The best way to end this long post is by looking at the end-user experience. More specifically, a successful end-user experience. Below are three screenshots that are showing a working connection with Microsoft Tunnel Gateway. Figure 8 provides an example of the basic connection information. That contains information about the status. uptime, data sent and received and the name of the connection. The latter can be related to the name in the VPN profile. Figure 9 provides an example about the details of the connection. That contains information about the type of VPN (per-app versus device-wide), if always-on is enabled and also the name and status. All of that information can be related to the configured VPN profile. Figure 10 provides an example of a connection to an internal resource (with internal IP) within my environment. The icons on the top left of the screen show the successful VPN connection that is still on.

Note: An administrator can look at more details about the status of Microsoft Tunnel Gateway, by using the mst-cli command line tool on the Microsoft Tunnel Gateway server. That tool can be used to look at details, like the status, statistics, connected users and much more.

More information

For more information about Microsoft Tunnel Gateway, refer to the following docs

Android Enterprise and Microsoft Intune: And the previously missing use case

This week is all about an addition to my previous post about the device management jungle of Android Enterprise. In that post I already did a brief look at the future and what Android 11 would bring to the table. At that time Microsoft Intune did not yet support a deployment scenario to address the Corporate-Owned, Personally Enabled (COPE) use case. The good news is: that has changed! Microsoft Intune now contains the deployment scenario Corporate-Owned Work Profile, which is currently still in preview, and that deployment scenario can address the COPE use case.

With this blog I want to provide a refreshed overview of the different deployment scenarios and the use cases that are addressed. However, the main focus of this post is the new Corporate-Owned Work Profile deployment scenario. I’ll start this post with the refreshed overview of the different Android Enterprise deployment scenarios in Microsoft Intune, followed with a summery of the main characteristics of the different deployment scenarios. I’ll end this post by focusing on the implementation of the new Corporate-Owned Work Profile deployment scenario.

Updated overview of the Android Enterprise deployment scenarios

Let’s start with a brief overview of the different Android Enterprise deployment scenarios that are available within Microsoft Intune. I’ve discussed these deployment scenarios before, but I thought it would be good to provide another quick overview to clearly differentiate between the deployment scenario and the use case and to address the main characteristics of the different deployment scenarios. Below in Figure 1 is an overview of the different deployment scenarios. As it’s mainly focused on the Android Enterprise capabilities, I’ve skipped the MAM-only scenario. For a first filtering the deployment scenarios are sorted based on the owner of the device and based on the type of workers for the device.

The next step in providing a clearer overview is the table below. That table describes the main characteristics of the different deployment scenarios. It shows important characteristics like the main use cases of a deployment scenario, if personal use is possible, if the privacy can be guaranteed, the management reach and more familiar characteristics.

Deployment scenarioUse casePersonal usePrivacy guaranteedEnrollment methodManagement reachReset requiredUser affinity
Work ProfileBring Your Own Device (BYOD)YesYesCompany Portal appProfile ownerNoYes
Corporate-Owned Work ProfileCorporate-Owned, Personally Enabled (COPE)YesYesNear Field Communication, Token entry, QR code scanning, or Zero touchProfile owner with device-level settingsYesYes
Fully ManagedCorporate-Owned, Business Only (COBO)YesNoNear Field Communication, Token entry, QR code scanning, or Zero touchDevice ownerYesYes
DedicatedCorporate-Owned, Single Use (COSU)NoNoNear Field Communication, Token entry, QR code scanning, or Zero touchDevice ownerYesNo

As a little bit of context with this table, the different collumns are used to provide the following information:

  • Deployment scenario – This column describes the name of the deployment scenario (or some times referred to as management scenario) in Microsoft Intune
  • Use case – This column describes the often used name of the most common use case
  • Personal use – This column describes if the deployment scenario can facilitate personal use (which can be as simple as the option for enabling a personal account for the Google Play store)
  • Privacy guaranteed – This column describes if the deployment scenario can guarantee the privacy of the user (which actually can only be the case when using a work profile)
  • Enrollment method – This column describes the different enrollment methods that are available for the deployment scenario
  • Management reach – This column describes the management reach of the deployment scenario on the device
  • Reset required – This column describes if the deployment scenario requires a reset of the device
  • User affinity – This column describes if the the deployment scenario facilitates user affinity

Android Enterprise Corporate-Owned Work Profile

Now let’s have a look at the previously missing use case, which was the actual trigger of this post, the COPE use case. That use case can now be addressed with the introduction of the Corporate-Owned Work Profile deployment scenario. A long time the public feeling was that Microsoft was missing a use case in Microsoft Intune. Even though the feeling was fair and actually not just a feeling but a simple fact, there was also a fair reason why the deployment scenario for that use case was not available. Microsoft was relying on the Android Management API (AMAPI) and support for the required deployment scenario was not available. That’s changing now.

However, before looking at that deployment scenario in a bit more detail, let’s start with stating that the previous deployment scenario in Android Enterprise, to address the COPE use case, often named Work Profile on Fully Managed Device (WPoFMD), is not going to happen in Microsoft Intune. The support that’s provided via Microsoft Intune by leveraging AMAPI, is focused on the changes coming with Android 11. With Android 11, Google wants to focus more on the privacy of the user. To achieve that, Google wants to further separate the work profile and the personal profile. With the previous implementation there would be two separate Device Policy Controller (DPC) instances running on the device. An instance running as device owner in the personal profile of the user and an instance running as profile owner in the work profile of the user. As you can imagine, that theoretically provides an organization with a lot of control over the personal profile of the user. Besides the level of control, the organization could also potentially see information from the personal profile of the user, like the installed apps. That will also be one of the biggest changes in the new implementation. There will no longer be a work profile on a fully managed device. Instead, the new Corporate-Owned Work Profile deployment scenario will be similar to a normal work profile, but on steroids. Starting with Android 11, there will be a single DPC instance running as profile owner on the corporate owned device of the user. That instance also has the capabilities to do a few device settings. However, there will be no insights in for example the installed apps, or data, in the personal profile on the device. There will be strict separation between the apps and data in the personal profile and the work profile. Similar to the work profile deployment on personal devices. The main difference between the two are the steroids of the DPC instance. On a personal device, the DPC instance is running as profile owner and only has permissions within the work profile. On a corporate device, the DPC instance is also running as profile owner, it has permissions within the work profile and it can manage a few device settings that also affect the personal profile.

When looking from a Microsoft Intune perspective, the nice thing is that the user will have the same usage experience on devices with Android 8 and later, and that the administrators will also have the same management experience for devices with Android 8 and later. That’s achieved by using AMAPI. That will make sure that with a single configuration performed by the administrator, the correct configuration will be applied to the Android device of the user. No matter the specific Android version. As long as it’s Android 8 or later.

More information

For more information regarding Android Enterprise and Android 11, refer to the following articles:

Customizing the Microsoft Intune Company Portal app and website

This week is all about customizing the Microsoft Intune Company Portal app and website. The main trigger for this subject are the recently introduced additional customization options. Besides configuring default branding and support information, the list of actual specific customization configurations is growing and providing more and more options for an organization specific look-and-feel. That includes the option for creating multiple different customization policies. In this post I’ll go through the different customization options and policies. I’ll end this post by having a quick look at the end-user experience.

Company Portal app and website customization options

Now let’s have a look at the Company Portal app and website customization options. To do that, I want to walk through the different customization options and explain the usage. Let’s start with the following steps for editting or creating a customization policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Tenant administration > Customization to open the Tenant admin | Customization page
  2. On the Tenant admin | Customization page, click Edit to edit the Default Policy or click Create to create a new custom policy

Editting the Default Policy will provide the administrator with all the available settings as I’m going through below, while creating a new customization policy will provide the administrator with the Create customization policy wizard that doesn’t contain the Hide features section mentioned below. Either way, the customization options are divided into three categories: 1) Branding customization, 2) Support information customization and 3) Configuration customization.

Branding customization

The first category contains the Branding customization, which enables the administrator to configure customizations related to the branding that is shown to the user via the Company Portal app and website. Below, in Figure 1, is an overview of the Branding customization options and a short explanation of those customization options is described below that figure.

  • Organization name: The organization name field is used for configuring the name of the organization and is limited to 40 characters. The organization name can be displayed in the Company Portal app and website.
  • Color: The color selection is used for configuring a Standard color, which provides the selection of five standard colors, or a Custom color, which provides the option to configure a custom color code.
  • Theme color: The the color field changes based on the initial color selection. The configured theme color is shown in the Company Portal app and website. This can be any color and the text color is automatically adjusted to the selected color.
  • Show in header: The show in header selection is used for configuring the header of the Company Portal app and webiste. The options are self-explaining: the Organization logo and name, the Organization logo only, or the Organization name only.
  • Upload logo: The upload logo field comes in different variations (not shown in Figure 1) and is used to upload a custom logo. That logo can be displayed displayed in the Company Portal app and website.

Support information customization

The second category contains the Support information customization, which enables the administrator to configure customizations related to the support information that is shown to the user via the Company Portal app and website. The information will be displayed on the contact pages in the end-user experience. Below, in Figure 2, is an overview of the Support information customization options and a short explanation of those customization options is described below that figure.

  • Contact name: The contact name field is used for configuring the name of the support contact for users in the Company Portal app and website. The name is limited to 40 characters.
  • Phone number: The phone number field is used for configuring the number of the support contact for users in the Company Portal app and website. The number is limited to 20 characters.
  • Email address: The email address field is used for configuring the email of the support contact for users in the Company Portal app and website. The address is limited to 40 characters.
  • Website name: The website name field is used for configuring the friendly name of the support website in the Company Portal app and website. The name is limited to 40 characters.
  • Website URL: The website URL field is used for configuring the URL of the support website in the Company Portal app and website. The URL is limited to 150 characters.
  • Additional information: The additional information field is used for providing additional support-related information for the users in the Company Portal app and website. The information is limited to 120 characters.

Configuration customization

The third category contains the Configuration customization, which enables the administrator to configure multiple customizations related to the available configuration options via the Company Portal app and website. The Configuration customization options actually change the options and the behavior provided to the user and are divided into five sections: 1) the Enrollment section, 2) the Privacy section, 3) the Device ownership notification section, 4) the App Sources section and 5) the Hide features section.

Enrollment section

The first section contains the Enrollment customization options, which enables the administrator to configure customizations related to the enrollment experience that will be provided to the user via the Company Portal app. Below, in Figure 3, is an overview of the Enrollment customization options and a short explanation of those customization options is described below that figure.

  • Device enrollment: The device enrollment selection is used for specifying if and how users should be prompted in the Company Portal app to enroll their iOS/iPadOS and Android devices. The options are: Available, with prompts, which will prompt the user to enroll the device; Available, no prompts, which will provide the option to enroll the device but will not prompt the user and Unavailable, which will not enable the user to enroll the device.

Privacy section

The second section contains the Privacy customization options, which enables the administrator to configure customizations related to the privacy statement and messages that will be shown to the user via the Company Portal app. Below, in Figure 4, is an overview of the Privacy customization options and a short explanation of those customization options is described below that figure.

  • Privacy statement URL: The privacy statement URL field is used for configuring the URL that links to the privacy statement of the organization in the Company Portal app and website. This URL is limited to 79 characters.
  • Privacy message in Company Portal for iOS/iPadOS: The privacy message selection is used for configuring the privacy message that is shown in the Company Portal app on iOS/iPadOS devices. That can be used to inform the user about what the organization can and cannot see on the device of the user. The options are to use the Default or a Custom message and when using a custom message that message is limited to 520 characters.

Device ownership notification section

The third section contains the Device ownership notification customization options, which enables the administrator to configure customizations related to the push notifications about the device ownership changes that will be automatically sent to the user via the Company Portal app. Below, in Figure 5, is an overview of the Device ownership notification customization options and a short explanation of those customization options is described below that figure.

  • Send a push notification to users when their device ownership type changes from personal to corporate (Android and iOS/iPadOS only): The send push notification selection is used to select whether a push notification should be send to the Company Portal app on Android and iOS/iPadOS devices after changing the device ownership from personal to corporate. The options are Yes or No.

App Sources section

The fourth section contains the App Sources customization options, which enables the administrator to configure customizations related to the additional app sources that will be shown in the Company Portal app and website (currently website only). Below, in Figure 6, is an overview of the App Sources customization options and a short explanation of those customization options is described below that figure.

  • Azure AD Enterprise Applications: The Azure AD enterprise applications selection is used to select whether Azure AD enterprise applications should be shown in the Company Portal app and website (currently website only). The options are Hide and Show.
  • Office Online Applications: The Office online applications selection is used to select whether Office online applications should be shown in the Company Portal app and website (currently website online). The options are Hide and Show.

Hide features section

The fifith section contains the Hide features customization options, which enables the administrator to configure customizations related to the available self-service actions on devices that users can perform via the Company Portal app and website. Below, in Figure 7, is an overview of the Hide features customization options and a short explanation of those customization options is described below that figure.

  • Hide remove button on corporate Windows devices: The hide remove button checkbox is used to select whether the remove button is hidden in the Company Portal app and website for corporate Windows devices.
  • Hide reset button on corporate Windows devices: The hide reset button checkbox is used to select whether the reset button is hidden in the Company Portal app and website for corporate Windows devices.
  • Hide remove button on corporate iOS/iPadOS devices: The hide remove button checkbox is used to select whether the remove button is hidden in the Company Portal app and website for corporate iOS/iPadOS devices.
  • Hide reset button on corporate iOS/iPadOS devices: The hide reset button checkbox is used to select whether the reset button is hidden in the Company Portal app and website for corporate iOS/iPadOS devices.

Company Portal app and website experience

Now let’s end this post by having a look at the end-user experience. I’m not going to show all the branding, support information and configuration customizations, but just a few that really standout. Below, in Figure 8, is a side-by-side of the Company Portal website on the left and the Company Portal app on the right. Both show the same look-and-feel. A few detail that can be spotted are:

  • The branding theme color
  • The branding header of organization logo and name
  • The configuration app sources of Office online apps
  • The configuration hide features of Windows devices

More information

For more information about configuring the Microsoft Intune Company Portal app and website, refer to this article about customizing the Intune Company Portal apps, Company Portal website, and Intune app

Pushing notifications to users on iOS and Android devices

This week is all about the different options in Microsoft Intune to send push notifications to users on iOS (and iPadOS) and Android devices. The trigger of this post is the option to send push notifications as an action for noncompliance, which was introduced with the 2005 service release of Microsoft Intune. Besides that, it was already possible to send custom notifications to a single device, to the devices of a group of users, or as a bulk action to multiple devices. In this post I want to go through the different options for sending push notifications, followed by showing the end-user experience.

Send custom notifications

Custom notifications can be used to push a notification to the users of managed iOS (including iPadOS) and Android devices. These notifications appear as push notifications from the Company Portal app (or Microsoft Intune app) on the device of the user, just as notifications from other apps. A custom notification message includes a title of 50 characters or fewer and a message body of 500 characters or fewer. Besides those message limitations, the following configurations should be in place for a device to be able to receive push notifications.

  • The device must be MDM enrolled.
  • The device must have the Company Portal app (or Microsoft Intune app).
  • The Company Portal app (or Microsoft Intune app) must be allowed to send push notifications.
  • An Android device depends on the Google Play Services.

Send custom notification to a single device

The method for sending a custom notification to a single device is by using device actions. To use device actions for sending a custom notification to a single device, simply follow the three steps below.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > All devices {{select Android or iOS device} to open the Overview page of the specific device
  2. On the Overview page, select the Send Custom Notification device action (when the option is not available, select the  option first from the upper right side of the page) to open the Send Custom Notification pane
  3. On the Send Custom Notification page, specify the following message details and select Send to send the notification to the device
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to a single device can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices('{IntuneDeviceId}')/sendCustomNotificationToCompanyPortal

Send custom notification to a group of devices

There are actual two methods for sending a custom notification to a group of devices. The first method for sending a custom notification to a group of devices is by using the tenant administration. That can be achieved by using the four steps below. The twist is that those steps will enable the administrator to send a notification to a group, which will only target the users of that group. The notification will then only go to all the iOS (and iPadOS) and Android devices that are enrolled by that user.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Teant administration Custom notifications to open the Tenant admin | Custom notifications blade
  2. On the Basics page, specify the following message details and select Next
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the group that should be used to send this notification to and click Next
  2. On the Review + Create page, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to the devices of a group of users can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/sendCustomNotificationToCompanyPortal

The second method for sending a custom notification to a group of devices is by using bulk actions. That can be achieved by using the four steps below. Those steps will enable the administrator to send a notification to multiple selected iOS (and iPadOS) and Android devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices All devicesBulk Device Actions to open the Bulk device actions blade
  2. On the Basics page, specify the following details and select Next
  • OS – Select the platform of the devices that should receive this notification (Android (device administrator), Android (Work Profile), or iOS/iPadOS)
  • Action – Send custom notification
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the devices to send this custom notification to and click Next
  2. On the Review + Create tab, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to multiple selected devices can be achieved by using the executeAction object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction

Send noncompliance notification

Noncompliance notifications can be used to push a notification to a device about the noncompliance state of the device. These notifications appear as push notifications from the Company Portal app on the device of the user, just as notifications from any other app. The notification is pushed to the device, the first time after the device is noncompliant and checks in with Microsoft Intune (depending on the configured schedule of the push notification). The message of the notification contains the details about the noncompliance and can’t be customized. Also, the notification is only pushed a single time. To push multiple notifications, simply add multiple actions. The four steps below show how to add a noncompliance action that will send a push notification to a compliance policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Endpoint security Device compliancePolicies to open the Compliance policies | Policies blade
  2. On the Compliance policies | Policies page, either create a new policy, or edit an existing policy (this example is of editing an existing policy)
  3. On the Actions for noncompliance page, select Send push notification as an additional action
  1. On the Review + save page, click Save

For automation purposes, automating updating a device compliance policy can be achieved by patching the specific deviceCompliancePolicies object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies/{policyId}

End-user experience

Let’s end this post by having a look at the end-user experience. The push notifications will show on the lock screen just as notifications from any other app. Below on the left (Figure 5) is showing an example of the lock screen that contains a custom notification and a noncompliance notification. Below in the middle (Figure 6) is showing an example of a custom notification when the Company Portal app was open. The user will go to the same page in the Company Portal app, when clicking on the custom notification on the lock screen. Below on the right (Figure 7) is showing an example of the page in the Company Portal app, when clicking the noncompliance notification. That will enable the user to immediately take action.

Note: The experience on Android devices is similar. However, keep in mind that on Android devices, other apps might have access to the data in push notifications.

More information

For more information about the different options to send push notifications to users on iOS and Android devices, refer to the following docs:

Android Enterprise and Microsoft Intune

This week is all about the device management jungle of Android Enterprise. I should have discussed this subject a long time ago, but better late than never. Especially when I’m still seeing many question marks when discussing Android Enterprise. With the release of Android 10.0 coming to the different existing Android devices now, the purpose of this post is to create an overview of the different enterprise deployment scenarios of Android Enterprise, including the Microsoft Intune specific additions, and the different related enrollment methods. Everything focussed on providing a good starting point for managing Android devices. The main trigger is the nearing end of Android device administrator with the release of Android 10.0. Earlier I provided the steps for simplifying the migration of Android device administrator to Android Enterprise work profile management with Microsoft Intune, but that was a specific scenario for migrating away of Android device administrator. That doesn’t answer the question if Android Enterprise work profile management is the best deployment solution for your organization.

With this post I hope to provide a better overview of the different deployment scenarios, the requirements and the enrollment methods. All to make a good start with Android Enterprise. Before I’ll dive into Android Enterprise, I’ll start with a little bit of history about Android device administrator. After going through the Android Enterprise deployment scenarios and enrollment methods, I’ll end with a short note about the (crazy) future. I won’t compare or discuss the different configuration options for the different deployment scenarios, as I think that a deployment scenario should be chosen based on the use case first and not directly based on the available configuration options.

A little bit of history

Let’s start with a little trip down memory lane. A long time ago, with Android 2.2, Google introduced the Device Administration API. That API provided device administration features at a device level and allowed organizations to create security-aware apps with elevated administrative permissions on the device. It would enable organizations to perform some basic actions on the device to manage basic components, like email configurations (including remote wipe) and password policies. However, it also introduced many big challenges. One of those challenges was the limited number of configuration options, without a third-party solution like Samsung Knox, and another one of those challenges was the inconsistent level of control across different manufacturers. The more Android device administrator was used, the bigger the scream became for something new.

And something new came. Starting with Android 5.0 and later, Google started with the introduction of Android Enterprise by introducing the managed device (device owner) and work profile (profile owner) modes to provide enhanced privacy, security, and management capabilities. These modes support the different Android Enterprise deployment scenarios (more about those scenarios later) and can be managed by using the Android Management API. That API can be used to configure different enhanced policy settings for the managed devices and the companion app (Android Device Policy) automatically enforces those policy settings on the device. Microsoft Intune has chosen to rely on the API for managing most of the deployment scenarios.

Now only turning off the old management method is left. Starting with Android 9.0, Google has started with decreasing device administrator support in new Android releases, by starting with deprecating specific settings. These settings are mainly related to the camera and password configurations, and these settings are completely removed starting with Android 10.0. That will prevent organizations from being able to adequately manage Android devices by using Android device administrator. A big trigger to move away from Android device administrator. The advise – when using only Microsoft Intune – is to move to Android Enterprise modes and deployment scenarios with the introduction of Android 10.0. Even better, don’t wait until the introduction of Android 10.0 (but that advise might be a bit late now).

Android Enterprise deployment scenarios

The biggest challenge of the Android Enterprise device management jungle is the number of deployment scenarios. When looking specifically at the combination with Microsoft Intune, there is even an additional deployment scenario on top of the standard Android Enterprise deployment scenarios. Below in Figure 1 is an overview of the currently available Android Enterprise deployment scenarios with Microsoft Intune (picture is taken from the slide deck of session BRK3082 at Microsoft Ignite 2019).

Now let’s have a closer look at these different deployment scenarios and the supportability of Microsoft Intune. I’ll do that by zooming in on the different deployment scenarios as shown in Figure 1.

Android APP managed – Android app protection policies (APP) managed app is the least intrusive method for allowing access to company data on personal devices and still making sure that the data remains safe. Also, this method is not Android Enterprise specific. In this scenario, the app is managed with protection policies that will make sure that the company data remains within the app and these protection policies are only applied once the user signs in with a work account. Also, the protection policies are only applied to the work account and the user is still able to use the same app with a personal account. If needed, the IT administrator can remove company data from within the managed app.

AE Work Profile – Android Enterprise work profile is supported with Android 5.0 and later in Microsoft Intune and is focused on providing access to company data on personal devices by using a profile owner mode. In this scenario, the user enrolls the device and after enrollment a separate work profile is created on the device. This separate profile creates the separation between company data and personal data and can be easily identified by the user. The apps that are part of the work profile are marked with a briefcase icon and the company data is protected and contained within the work profile. If needed, the IT administrator can remove the work profile from the device.

AE Dedicated – Android Enterprise dedicated devices – previously known as corporate-owned, single-use (COSU) devices – are supported with Android 6.0 and later in Microsoft Intune and is focused on providing single purpose company-owned devices by using a device owner mode. This is often used for kiosk-style devices (example: devices used for inventory management in a supermarket). In this scenario, these devices are enrolled and locked down to a limited set of apps and web links, all related to the single purpose of the device. These devices are not associated with any specific user and are also not intended for user specific applications (example: email app). If needed, the IT administrator can remove any (company) data of the device.

AE Fully managed – Android Enterprise fully managed devices – previously known as corporate-owned, business-only devices (COBO) devices – are supported with Android 6.0 and later in Microsoft Intune and is focussed on providing company-owned devices, used by a single user exclusively for work, by using a device owner mode. In this scenario, these devices are enrolled and fully managed by the IT organization. To give the user a personal touch, the IT administrator can allow the user to add a personal account for the installation of apps from the Google Play store. However, the device will remain fully managed and there will be no differentiation between company data and personal data. If needed, the IT administrator can remove all (company) data of the device.

AE Fully managed with work profile – Android Enterprise fully managed devices with work profile – previously known as corporate-owned, personally-enabled (COPE) devices – are not yet available with Microsoft Intune, but are eventually focussed on providing company-owned devices used for work and personal purposes, by using a combination of device owner mode and profile owner mode. In this scenario, the IT organization still manages the entire device, but can differentiate between the strength of the configuration depending on the type of profile (example: a stronger configuration set to the work profile and a lightweight configuration set to the personal profile). That should provide the user with a personal space on the device and that should provide the IT administrator with enough capabilities to protect the company data.

For the management of the company-owned devices, Microsoft Intune relies on the Android Management API and Android Device Policy. That enables Microsoft to be able to quickly introduce new features, when introduced in the API. However, that also creates a dependency on Google to introduce new features via the API. A negative example of that dependency is the time it took before the Android Enterprise fully managed devices with work profile deployment scenario became available via the API. At this moment the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune.

Android Enterprise enrollment methods

Once familiar with the Android Enterprise deployment scenarios, it’s good to get familiar with the Android Enterprise enrollment methods. That will enable the IT administrator to get an Android device in the correct mode (device owner, or profile owner) and the correct deployment scenario. The table below provides and overview of the available enrollment methods for the different deployment scenarios. It also provides some details about a few important properties of the deployment scenarios (based on the information about the deployment scenarios). Those properties are: is a reset required to get started with a deployment scenario and is a user affinity applicable with a deployment scenario.

As the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune, the information regarding that deployment scenario is an educated guess, based on the other deployment scenarios. That’s why the information is in grey, as it’s still work in progress. The only thing that I’m sure of is that it would require a new enrollment. There will be no migration path from an Android Enterprise fully managed device to an Android Enterprise fully managed device with work profile. That will require a new enrollment. Keep that in mind with determining an eventual deployment and management strategy.

Deployment scenarioEnrollment methodsReset requiredUser affinity
Android app protection policies managed appManaged appNoNot applicable
Android Enterprise work profile deviceCompany Portal appNoYes
Android Enterprise dedicated deviceNear Field Communication, Token entry, QR code scanning, or Zero touchYesNo
Android Enterprise fully managed deviceNear Field Communication, Token entry, QR code scanning, or Zero touchYesYes
Android Enterprise fully managed device with work profileNear Field Communication, Token entry, QR code scanning, or Zero touchYesYes

Now let’s have a closer look at the different enrollment methods and the supportability within Microsoft Intune. I’ll do that by zooming in on the different enrollment methods as mentioned in the table above.

Managed app – Managed app enrollment is not specific to Android Enterprise and is supported with any platform version that is supported by the specific managed app. With this enrollment method, the user downloads and installs an app that is protected with app protection policies – when using a work account – and adds a work account to that app. After signing in it triggers the app protection policies for the work account. Also, keep in mind that the user would need to have the Company Portal app installed as a broker app.

Company Portal app – Company Portal app enrollment is supported with Android 5.0 and later in Microsoft Intune for Android Enterprise deployment scenarios. With this enrollment method, the user downloads and installs the Company Portal app and signs in with a work account. After signing in the user triggers the enrollment process in the Company Portal app.

Near Field Communication – Near Field Communication (NFC) enrollment is supported with Android 6.0 and later in Microsoft Intune and can make the enrollment of a device as simple as tapping the device on a specially formatted NFC tag. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can simply tap the device on the NFC tag. That tap will automatically start the enrollment process.

Token entry – Token entry enrollment is supported with Android 6.0 and later In Microsoft Intune and enables the enrollment of a device by specifying a specific (enrollment) token. With this enrollment method, once the device is reset, or just out-of-the-box, the administrator, or user, walks through the standard setup wizard and once arrived at the Google sign-in screen provides the afw#setup code to trigger the Android Device Policy. That will enable the token entry to actually start the enrollment process.

QR code scanning – QR code scanning enrollment is supported with Android 7.0 and later in Microsoft Intune and enables the enrollment of a device by simply scanning a QR code. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can multi-tap the screen to enable scanning of a QR code (on Android 7 and 8 that will first prompt for the installation of a QR code reader app). That QR code will automatically start the enrollment process.

Zero touch – Zero touch enrollment is supported with Android 8.0 and later In Microsoft Intune – only with participating manufacturers – and enables the enrollment of a device automatically. Similar to Apple Business Manager and Windows Autopilot. With this enrollment method, on first boot of the device, it will automatically check to see if an enterprise configuration is assigned. If so, the device initiates the provisioning method and downloads Android Device Policy. That download and installation will automatically start the enrollment process.

Note: Besides these standard Android Enterprise enrollment methods, there are also third-party additions (like Samsung Knox enrollment) that can benefit the enrollment process.

What the future brings

Let’s end with a look at the future and some advise. By now it should be obvious that platforms change. However, when looking at the first early signs of Android 11.0 – and specifically at what Android 11.0 brings to the Android Enterprise fully managed devices with work profile deployment scenario – organizations might wonder if change is always for the better. Just when the deployment scenarios of Android Enterprise get more and more traction, new changes are coming. Google recently announced that it will no longer support a work profile on fully managed devices with Android 11.0. Instead enhancements are made to the work profile, to provide a new enhanced work profile deployment scenario. And Android 11.0 will be a hard cut. Existing work profiles on fully managed devices will need to be migrated (to either a fully managed devices or to this new enhanced work profile) when upgrading to Android 11.0. The main driver for Google is the privacy of the user. Jayson Bayton wrote a great article around this subject. Also, when interested in anything around Android and Android Enterprise, I strongly advise to read more of his articles. It’s a great resource!

This change with Android 11.0 makes the future around the Android Enterprise fully managed devices with work profile deployment scenario, especially from a Microsoft Intune perspective, even more challenging. Even before that deployment scenario is available is available within Microsoft Intune. However, this shouldn’t be a reason for waiting even longer with the migration to Android Enterprise. Make sure to be familiar with the Android management requirements within your organization and built the solution and roadmap around those requirements. Often the lifecycle of the device is a good moment to look at a new method for managing the devices. Especially when looking at the supportability of new Android releases on existing devices. Don’t wait until the last moment and make a plan.

I would like to end by mentioning one last time that my advise is not to manage Android 10.0 with Android device administrator and only Microsoft Intune, as those devices will no longer be able to receive password requirements. To add-on to that, and to make my advise even stronger, make sure to be familiar with the upcoming restrictions to the Company Portal app on Android 10.0 devices managed via Android device administrator (see: Decreasing support for Android device administrator). Determine your own migration while you still can!

More information

For more information regarding Android device administrator and Android Enterprise, refer to the following articles:

Android Enterprise fully managed devices and the Google Play store

This week another post about an Android Enterprise configuration. Last week was related to company owned single-use (COSU) devices (also known as dedicated devices), while this week is related to company owned business only (COBO) devices (also known as fully managed devices). More specifically, about adding a personal touch to fully managed devices. Microsoft Intune doesn’t know the company owned personally enabled (COPE) devices, yet, but there is a feature within the fully managed devices configuration that can at least enable some more personal options to the user. That can be achieved with a simple configuration to allow access to all apps in the Google Play store. I’ll start this post with the configuration steps (and a little introduction) and I’ll end this post by having a look at the end-user experience.

Configuration

Let’s start with a quick introduction about the setting that should be configured and the impact of that setting. The setting Allow access to all apps in Google Play store must be set to Allow. Once it’s set to Allow, users get access to all apps in Google Play store. Apps can be sort of blocked by the administrator by assigning an uninstall of the apps to the user (or device). That will simply remove the app (over-and-over) again. When it’s set to Not configured, users are forced to only access the apps the administrator makes available (or required) via the Google Play store.

The following 3 steps walk through the process of creating a device restrictions policy that enables access to the Google Play store for users.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

AEFMD-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Select Android Enterprise
  • Profile type: Select Device Owner > Device restrictions
  • Settings: See step 3b
3b On the Device restrictions blade, select Applications to open the Applications blade; and click OK to return to the Add configuration policy blade;
3c On the Applications blade, select Allow with Allow access to all apps in Google Play store and click OK and OK to return to the Create profile blade;
AEFMD-Applications

Note: This profile can be assigned to user and device groups.

End-user experience

Now let’s end this post by having a look at the end-user experience. Depending on the exact configuration the end-user can end up with one of the three scenarios as shown below.

  1. Below on the left is showing the Google Play store for the work account only, without access to all apps in the Google Play store.
  2. Below in the middle is showing the Google Play store for the work account only, with access to all apps in the Google Play store. Even though my store is in Dutch, the number of items in the menu, and the apps shown in the background, show the difference.
  3. Below on the right is showing the Google Play store for the work account when also a personal account is added (see the purple circle with a “P”). It provides the same options as shown in the middle, but also enables the user to switch between accounts.
Screenshot_20190729-172606_Google Play Store Screenshot_20190729-181300_Google Play Store Screenshot_20190724-210437_Google Play Store

The combination for the user to add a personal account to the device and being able to install apps via the Google Play store, will at least give the user some options to personalize the device.

More information

For more information about the device configuration options for Android Enterprise fully managed devices, please refer to the Device owner section in the documentation about Android Enterprise device settings to allow or restrict features using Intune.

Create a custom multi-app kiosk mode

This week is all about creating a custom multi-app kiosk mode for Android Enterprise dedicated devices. The Android Enterprise dedicated device settings also contains multi-app kiosk settings, but in some scenarios those settings can still be a little bit limiting. To create a multi-app kiosk mode, Microsoft Intune relies on the Managed Home Screen app. The fun part is that the Managed Home Screen app already contains a few more settings that are currently only available via app configuration policies. In this post I’ll start with a quick overview of the app configuration options that exist nowadays, followed by showing an app configuration example for the Managed Home Screen app to add a non-Managed Google Play Store app. Technically speaking I’ll add a single app, using the multi-app configuration option. Really adding multiple apps is more of the same. I’ll end this post by showing the end-user experience.

It’s important to keep in mind that the preferred and advised method to configure multi-app kiosk mode settings is still by using the dedicated device settings.

App configuration options

Let’s start this post by having a look at the app configuration options that are available nowadays. In the early days it was still required to manually configure configuration keys and values. These days Intune can prepopulate configuration keys that are available within the Android apps. Below is a quick overview of the 2 app configuration options that are available :

Configuration designer: The Configuration designer can be used to configure simple settings via the UI. It will automatically populate the available configuration keys within the app and allows the administrator to configure the simple configuration values. As long as the value type is not BundleArray
MSH-ConfigurationDesigner
JSON data: The JSON data can be used to configure all settings via a JSON template. The template will automatically populate the available configuration keys within the app and allows the administrator to configure all the configuration values.

MHS-JSONEditor

Configure the Managed Home Screen app

Now the app configuration options are clear. Let’s have a look at the app configuration of the Managed Home Screen app. As an example I want to use a setting that is only configurable via JSON data, as the value type is a BundleArray. That setting is to add (custom non-Managed Google Play Store) apps to the Managed Home Screen app. The following 3 steps walk through the process of creating an app configuration policy that enables the built-in Settings app to the multi-app kiosk mode.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > App configuration policies to open the Client apps – App configuration policies blade;
2 On the Client apps – App configuration policies blade, click Add to open the Add configuration policy blade;
3a

MHS-AddConfigPolicyOn the Add configuration policy blade, provide the following information and click Add;

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Device enrollment type: Select Managed devices
  • Platform: Select Android
  • Associated app: See step 3b
  • Configuration settings: See step 3c
  • Permissions: See step 3d

Note: The main focus of this post is the configuration around the configuration settings (step 3c). That doesn’t mean that the permission configuration (step 3d) can’t be really useful when the app needs specific permissions. As it’s not the key part of this post, I won’t go into to much details for now.

3b

On the Associated app blade, select Managed Home Screen and click OK to return to the Add configuration policy blade;

Note: When the Managed Home Screen app is not available make sure that that the app is approved and synchronized with Intune.

3c

On the Configuration settings blade, select Enter JSON data with Configuration settings format. Now either click Download JSON template, for offline editing, or use the JSON editor to directly configured the required configuration keys. Before clicking on OK to return to the Add configuration policy blade, go through the following 3 steps (see also the screenshot below):

  1. Navigate to the applications configuration key to add the required apps for the custom multi-app kiosk mode. In my example, I add the Settings app (com.android.settings) to my multi-app kiosk mode. The valueString should be the app package name. To add another app simply copy the complete managedProperty and adjust the valueString.
  2. To be able to save the configuration, make sure to change all the values that need to be configured and still state something like STRING_VALUE. When a setting is not needed it can also be removed.
  3. The red areas on the scrollbar show the locations of values that must be adjusted or removed before the configuration can be saved.

Note: Make sure that the settings in the app configuration policy don’t overlap with settings in the dedicated device configuration.

MHS-JSONEditor-Config
3d On the Permissions blade, click Add to open the Add permissions blade. The Add permissions blade can be used select permissions that should be overridden. Select the required permissions and click OK to return to the Permissions blade and click OK to return to the Add configuration policy blade.

Note: At some point in time these configuration options will probably become available in the multi-app kiosk mode settings for dedicated devices.

End-user experience

Let’s end this post by having a look at the end-user experience. When the device is enrolled and the assigned apps are installed, the device will ask to select a home screen app (the message will actually show after the installation of the Managed Home Screen app). After selecting the Managed Home Screen app, the home screen will show as configured in the app configuration policy.

As shown on the right, I only get the Settings app (Instellingen is the Dutch version of Settings) as app on my home screen. That’s exactly what I wanted. Also, I configured a blue theme and I removed nearly all the other options from the end-user.

Note: The experience might be different from the configuration via the dedicated device settings. The main difference might be that in some cases the end-user might receive a message to configure a home screen app. So make sure to carefully test the end-user experience, to see if it matches the expectations.

Screenshot_20190721-195426

More information

For more information about configuring the Managed Home Screen app, please refer to the documentation about Configure the Microsoft Managed Home Screen app for Android Enterprise .