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:

Creating a custom look-and-feel across Android Enterprise fully managed devices

This week is all about Android Enterprise fully managed devices. More specifically, this week is all about creating a single look-and-feel across all Android Enterprise fully managed devices by using the Microsoft Launcher app. Similar to working with Android Enterprise dedicated devices and using the Managed Home Screen app. The Microsoft Launcher app provides many configuration options that can be configured by using an app configuration policy. That in combination with the recently introduced feature to configure the Microsoft Launcher app as the default launcher, enables the administrator to create a custom look-and-feel across all Android Enterprise fully managed devices. In this post I’ll show how to add the Microsoft Launcher app, how to configure the Microsoft Launcher app and how to configure the default launcher app. All the required actions for configuring a custom look-and-feel across all Android Enterprise fully managed devices. I’ll end this post by showing the end-user experience.

Configure a custom look-and-feel across Android Enterprise fully managed devices

Let’s start with the steps that are specific to creating a custom look-and-feel across Android Enterprise fully managed devices. For that I will assume that the enrollment of Android Enterprise fully managed devices is already configured and I’ll focus on the steps that are specifically related to configuring that custom look-and-feel. Those steps are: 1) adding the Microsoft Launcher app, 2) creating a custom look-and-feel for the Microsoft Launcher app, and 3) configuring the Microsoft Launcher app as the default launcher. More details of these steps are described below.

Add the Microsoft Launcher app

The first step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to add the Microsoft Launcher app as an app to Microsoft Intune and to assign it to the required users or devices. The Microsoft Launcher app can be set to a specific background and can be configured as the custom launcher on Android Enterprise fully managed devices. The following seven steps walk through the simple process of adding the Microsoft Launcher app as a Managed Google Play store app.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps > Android to open the Android | Android apps page
  2. On the Android | Android apps, click Add to open the Select app type page
  3. On the Select app type page, select Managed Google Play app as the App type and click Select to open the Managed Google Play store
  4. In the Managed Google Play store, search for the Microsoft Launcher app, select the app and click Approve to open the Microsoft Launcher permissions dialog
  5. On the Microsoft Launcher permissions dialog, click Approve to switch to the Notifications tab
  6. On the Notifications tab, select Keep approved when app requests new permissions and click Done to return to the Managed Google Play store
  7. Back in the Managed Google Play store, click Sync to create apps that are added in Managed Google Play when the sync completes

Configure a custom look-and-feel for the Microsoft Launcher app

The second step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to create an app configuration policy for the Microsoft Launcher app that is assigned to the required users or devices. The app configuration policy can be used to configure a custom look-and-feel for the Microsoft Launcher app. The custom look-and-feel in the Microsoft Launcher app can be used to configure a custom look-and-feel across the Android Enterprise fully managed devices. The following steps walk through the process of configuring the Microsoft Launcher app to at least show a custom background across the Android Enterprise fully managed devices. That will help with recognizing company devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps > App configuration policies to open the Apps | App configuration policies page
  2. On the Apps | App configuration policies, 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: (Optionally) Provide a valid description for the app configuration policy
  • Device enrollment type: Managed devices (already greyed out based on the initially selection)
  • Platform: Select Android Enterprise
  • Profile type: Select Device Owner Only
  • Targeted app: Select Microsoft Launcher
  1. a) On the Settings page, configure any additional required permissions by clicking Add as shown below in Figure 1.
  1. b) Also on the Settings page, perform the actual app configuration settings to set a custom device wallpaper in the Microsoft Launcher app by clicking Add and creating something similar as shown below in Figure 2.
  1. On the Scope tags page, configuring any required scope tags and click Next
  2. On the Assignments page, configure the required assignment that contains the applicable users or devices and click Next
  3. On the Review + create page, click Create

Configure the Microsoft Launcher app as the default launcher

The last step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to create a device restrictions policy for configuring the default launcher that is assigned to the required users or devices. The device restrictions policy can be used to configure the Microsoft Launcher app as the default launcher on Android Enterprise fully managed devices. The following steps walk through the process of configuring the Microsoft Launcher app as the default launcher on the Android Enterprise fully managed devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Android > Configuration profiles to open the Android | Configuration profiles page
  2. On the Android | Configuration profiles, click Create profile to open the Create a profile page
  3. On the Create a profile page, select the following information and click Create to open the Device restrictions wizard
  • Platform: Android Enterprise
  • Profile: Device restrictions
  1. On the Basics page, provide a valid name and (optionally) description for the device restriction policy and click Next
  2. On the Configuration settings page, configure at least the following settings in the Device restrictions sections (as shown in Figure 1) and click Next
  • Enrollment profile type: Fully managed
  • Make Microsoft Launcher the default launcher: Enabled
  1. On the Scope tags page, configuring any required scope tags and click Next
  2. On the Assignments page, configure the required assignment that contains the applicable users or devices and click Next
  3. On the Review + create page, click Create

End-user experience

Now let’s end this post by having a look at the end-user experience. This post was mainly focussed on creating a custom look-and-feel across all Android Enterprise fully managed devices by configuring a custom device wallpaper. The result of that configuration and the experience for the end-user, is shown on the right in Figure 4.

It’s good to know that this is just an example of the possibilities that are currently available via the Microsoft Launcher app as a custom launcher. Besides this basic, but most notable adjustment, the Microsoft Launcher app also provides configurations options for more adjustments, like the following:

  • Grid Size – The administrator can define the grid size for apps to be positioned on the home screen.
  • Feed – The administrator can enable the launcher feed on the device when the user swipes to the right on the home screen.
  • Search Bar – The administrator can specify the placement of search bar on the home screen.
  • Dock Mode – The administrator can enable the dock on the device when the user swipes to the right on the home screen.
  • Home Screen Apps – The administrator can define the set of apps that are visible on the home screen from amongst the apps installed on the device. 
  • Home Screen App Order – The administrator can specify the app order on the home screen
  • Home Screen Web Links – The administrator can pin websites to the home screen as quick launch icon.

More information

For more information about configuring the Microsoft Launcher app and configuring the default launcher, refer to the following articles:

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:

Simplifying the migration of Android device administrator to Android Enterprise work profile management

This week is all about a recently introduced feature that will help organizations with their move away from Android device administrator managed devices to Android Enterprise work profile management. That is a very welcome feature as Google is decreasing device administrator support in new Android releases, which makes difficult for Microsoft Intune (and any other MDM-solution) to adequately manage Android device administrator managed devices starting with Android 10. The feature in Microsoft Intune that will help with moving away from Android device administrator managed devices is a compliance setting that will enable organizations to block devices in a structured manner and to provide a direct migration path to Android Enterprise work profile management.

In this post I’ll show how to create and configure a device compliancy policy that will slowly trigger end-users to start the migration to Android Enterprise work profile management, followed by the steps to block the enrollment of Android device administrator managed devices. Together that should help organizations to fully move away from Android device administrator managed devices. I’ll end this post by having a look at the end-user experience.

Configuring the device compliance policy

The first step is preparing a good migration experience, from Android device administrator managed devices to Android Enterprise work profile management, for the end-users. That can be achieved by creating a device compliance policy that eventually will block Android device administrator managed devices. To make sure that the end-user is not immediately being blocked from accessing company resources, I advise to use at least two levels of noncompliance. The first level would be that the end-user receives an email message with the advise to start the migration and the second level would be to actually block access to company resources. That can be after a longer period of noncompliance. The following seven steps walk through the steps for configuring a device compliance policy and provide some guidance for the different configurations. After the creation of the device compliance policy, assign the policy like any other policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices Android > Compliance policies to open the Android | Compliance policies blade
  2. On the Android | Compliance policies blade, click Create Policy to open the Create Policy blade
  3. On the Create Policy blade, provide the following information and click Create
  • Name: Provide a valid name for the device compliance policy
  • Description: (Optional) Provide a description for the device compliance policy
  • Platform: Select Android device administrator
  • Settings: See step 4 and 5
  • Locations: Leave default (for this post)
  • Actions for noncompliance: See step 6
  • Scope (Tags): Leave default (for this post)
  1. On the Android compliance policy blade, select Device Health to open the Device Health blade
  2. On the Device Health blade, select Block with Devices managed with device administrator and click OK to return to the Android compliance policy blade and click OK to return to the Create Policy blade
  3. On the Create Policy blade, select Actions for noncompliance to open the Actions blade
  4. On the Actions blade, add an action to first notify the user via email and make sure to adjust the default action to not mark a device as noncompliant immediately. That will provide the end-user with time to perform the migration before completely being blocked.

Note: The url https://portal.manage.microsoft.com/UpdateSettings.aspx can be used in the email message to launch the Company Portal app directly in the Update device settings page.

For automation purposes, automating the device compliance policy configuration can be achieved by using the deviceCompliancePolicies object in the Graph API.

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

Configuring the device enrollment restrictions

The second step is making sure that new Android device administrator managed devices can no longer be enrolled into Microsoft Intune. That can be achieved by using device enrollment restrictions. The device enrollment restrictions can be used for blocking the enrollment of Android device administrator devices. The following five steps walk through the adjustment of the default enrollment restrictions. Something similar, and often more flexible, can be achieved by using custom enrollment restrictions.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Enroll devices > Enrollment restrictions to open the Enroll devices | Enrollment restrictions blade
  2. On the Enroll devices | Enrollment restrictions blade, select the Default device type restriction and navigate to Properties to open the All Users | Properties blade
  3. On the All Users | Properties blade, navigate to the Platform settings section and click Edit to open the Platform settings page on the Edit restriction blade
  4. On the Platform settings page, select Block with Android device administrator (see example below) and click Review + save to continue to the Review + save page
  5. On the Review + save page, click Save

For automation purposes, automating the device type restriction configuration can be achieved by using the deviceEnrollmentConfigurations object in the Graph API.

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

End-user experience

Now let’s end this post by having a look at the end-user experience, which is the most important part of everything in this post. The end-user experience determines whether this migration process will be adopted by the end-user and whether this migration process is intuitive enough to walk the end-user through this migration process. My personal experience, after performing multiple of these migrations, is very positive. It catches problems and brings the end-user back to the progress in the Company Portal app. Even on an older device, which wasn’t encrypted, I eventually ended up in the Company Portal app.

Figure 4 to Figure 14 below, walk through the migration steps for the end-user when starting with an Android device administrator managed device and moving to Android Enterprise work profile management. Figure 5 is also the starting point when the end-user would click on the provided link in an email and Figure 15 provides an overview of the end result.

Note: In Figure 4 it already shows that the device status is “Not in Compliance“, while in fact the device can still be “In grace period“. Also, in Figure 5 the end-user will receive the message “Unable to resolve” when the enrollment of Android Enterprise (work profile) devices is restricted for the specific end-user.

More information

For more information about moving to Android Enterprise work profile management and enrollment restrictions, refer to the following docs:

Block Android device enrollment for specific device manufacturer

This week is all about restricting the enrollment of Android devices. More specifically, about a very recently introduced feature which is the ability to block Android device enrollment based on the manufacturer of the device. That enables the organization to prevent Android devices of specific manufacturers from enrolling in Microsoft Intune. That can be useful when the organization has a specific policy for allowed device manufacturers. In this post I’ll walk through the configuration steps, followed with the end-user experience.

Starting with this post, I’ll provide both the configuration steps via the Microsoft Endpoint Manager admin center portal and the configuration location in the Graph API (including the related JSON-snippet) as part of the configuration steps.

Configuration steps

Now let’s start by having a look at the configuration steps. These configurations can be achieved by either creating custom device type restrictions or by editting the existing default device type restriction. In the following example I’ll walk through these steps by adjusting the default device type restrictions. The following steps show how to add a device manufacturer to a list of blocked manufacturers.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Enroll devices > Enrollment restrictions to open the Enroll devices – Enrollment restrictions blade
  2. On the Enroll devices – Enrollment restrictions blade, select the Default device type restriction and navigate to Properties to open the All Users – Properties blade
  3. On the All Users – Properties blade, navigate to the Platform settings section and click Edit to open the Platform settings page on the Edit restriction blade
  4. On the Platform settings page, provide the manufacturers to block in the Device manufacturer field (see example below) and click Review + save to continue to the Review + save page

Note: Use a comma-separated list when adding multiple manufacturers.

  1. On the Review + save page, click Save

For automation purposes, it might be better to know how to automate the device type restriction configuration. That can be achieved by using the deviceEnrollmentConfigurations object in the Graph API.

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

However, keep in mind that the required properties are currently only available in the BETA version of the API. Below is an example snippet of a JSON that contains the Android Enterprise configuration with the blocked manufactures configuration, similar to the configuration via the UI.

"androidForWorkRestriction": {
    "platformBlocked": false,
    "personalDeviceEnrollmentBlocked": false,
    "osMinimumVersion": null,
    "osMaximumVersion": null,
    "blockedManufacturers": [
        "Samsung"
    ]
}

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll do that by showing the behavior on a personally-owned Android device that should enroll by using Android Enterprise work profiles to manage corporate data and apps. By default, enrollment of this type of personally-owned devices is enabled. That can be limited by using the enrollment restrictions, as shown in this post, or by simply blocking personally-owned devices.

In this scenario, I’m allowing the enrollment of personally-owned and company-owned Android devices, but I’m blocking any enrollment of Android devices from a specific device manufacturer.

When the end-user downloaded and installed the Company Portal app and started the enrollment process, at some point during the enrollment process the end-user will be blocked. While being blocked, the end-user will receive the message “Couldn’t add your device“. That message, of which an example is shown on the right, includes a clear explanation of why the device couldn’t be added. In my example the end-user is being told that the company needs the end-user to use an Android device manufacturer other then samsung.

Note: Keep in mind that the only reason that I’m using Samsung as an example in this post, is that I’ve got test Android devices of that device manufacturer. I don’t have any reasons that would actually require me to block the enrollment of Android devices from that device manufacturer.

More information

For more information about blocking Android device enrollment for specific device manufacturers, refer to the following docs:

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 .

Android Enterprise fully managed devices and conditional access

This week is all about Android Enterprise fully managed devices. More specifically, the recently introduced functionality to use Android Enterprise fully managed devices in combination with conditional access. To support this functionality Microsoft introduced a new app, named Microsoft Intune app, and a new profile type for device compliancy policies for the Android Enterprise platform. Together these 2 features enable Android Enterprise fully managed devices to be registered as compliant device and to successfully work with conditional access. In this post I’ll provide some information about the Microsoft Intune app and I’ll show how to configure that app, followed by some information about the compliance policy for device owner scenarios and how to configure that policy. I’ll end this post by showing the end-user experience.

Keep in mind that Android Enterprise fully managed devices is still preview functionality. There are still scenarios that will not fully work at this moment. One of those scenarios is related to app protection policies. I specifically mention that scenario, as it can conflict with the scenario in this post. Apps with app protection policies assigned, will still prompt for the Company Portal app.

Microsoft Intune app

The first part in using Android Enterprise fully managed devices in combination with conditional access is the Microsoft Intune app. The Microsoft Intune app is a new modern and light-weight app that will enable the Company Portal app experiences for end-users on fully managed devices. That includes managing compliance for their device. Keep in mind that the Microsoft Intune app is only for the fully managed device scenario. As Android Enterprise fully managed devices require the Managed Google Play Store, the following 4 steps walk through the process of adding the Microsoft Intune app by using the Managed Google Play Store. After that the Microsoft Intune app can be assigned as any other app.

Keep in mind that after the May 2019 service roll out of Microsoft Intune, the Microsoft Intune app will automatically be added to the Intune admin console after connecting the tenant to managed Google Play.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, click Add to open the Add app blade;
3a MIapp-AddAppOn the Add app blade, provide the following information and click Sync;

  • App type: Managed Google Play;
  • Managed Google Play: See step 3b – 3f;
3b On the Search managed Google Play blade, search for the Microsoft Intune app;
MIapp-SearchApp
3c On the Search managed Google Play blade, select the required app and click Approve to open a dialog box with app permissions;
MIapp-ApproveApp
3d

MIapp-ApproveAppDB01On the dialog box with app permissions, click Approve to continue to the selection about handling new app permissions;

Important: Keep in mind that this will accept these permissions on behalf of the organization.

3e

MIapp-ApproveAppDB02On the dialog box about handling new app permissions, select Keep approved when app requests new permissions and click Save to return to the Search managed Google Play blade;

Important: Keep in mind that this decision might impact the future app permissions and/or the future user experience.

3f On the Search managed Google Play blade, click OK;
MIapp-ApproveAppOK
4 Back on the Add app blade, click Sync;

Note: These steps will approve the app in the Managed Google Play store and sync the approved app in to Microsoft Intune..

Compliance policy for device owner

The second part in using Android Enterprise fully managed devices in combination with conditional access is the compliance policies. Since recently it’s possible to create compliance policies for fully managed devices. The list of available compliance settings is smaller than other platforms. The main reason for that is because those settings are only applicable to fully managed devices. And fully managed devices are, as the name already implies, fully managed. In other words, fully managed devices already follow strict configuration policies. The following 5 steps walk through the process of creating a device compliance policy for Android Enterprise fully managed devices. After configuring the device compliance policy assign it to a user group like any other device compliance policy.

1 Open the Azure portal and navigate to Microsoft Intune > Device compliance > Policies to open the Device compliance – Policies blade;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3a

AEfmd-CreatePolicyOn the Create Policy blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Android Enterprise;
  • Profile type: Device owner
  • Settings: See step 3b and 3c;
  • Actions for noncompliance: Leave default (for this post);
  • Scope (Tags): Leave default (for this post);

Note: Configuring non-standard values for Actions for noncompliance and Scope (Tags), is out of scope for this post;

3b

AEfmd-DevicePropertiesOn the Device owner blade, select Device Properties to open the Device Properties blade. On the Device Properties blade, configure the required device properties and click OK to return to the Device owner blade;

3c AEfmd-SystemSecurityBack on the Device owner blade, select System Security to open the System Security blade. On the System Security blade, configure the required system security settings and click OK to return to the Device owner blade;
4 Back on the Device owner blade, click OK to return to the Create Policy;
5 Back on the Create Policy blade, click Create to create the policy.

Note: To take full advantage of this device compliance policy configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Now let’s end this post by looking at the end-user experience. Below, from left to right, is an overview of the different steps in the Microsoft Intune app to get a device from a noncompliant state to a compliant state. When the user has a noncompliant device state, the user can start the process by clicking on “You need to update settings on this device”. That will bring the user to the screen to setup access to resources. On that screen the user can simply continue. The next screen will show the user the settings that need to be updated and by clicking on a setting the user will receive information to resolve the issue. Once all the issues are resolved, the device state will switch to compliant.

AEfmd-Experience01 AEfmd-Experience02 AEfmd-Experience03
AEfmd-Experience04 AEfmd-Experience05

Note: Keep in mind that this is still preview functionality. When using app protection policies, the protected apps will still prompt for the installation of the Intune Company Portal app.

More information

For more information regarding the Microsoft Intune app and Android Enterprise fully managed devices, please refer to the following articles: